From paul at pwsan.com  Mon Apr  1 01:25:11 2013
From: paul at pwsan.com (Paul Walmsley)
Date: Mon, 1 Apr 2013 05:25:11 +0000 (UTC)
Subject: [PATCH] Revert "OMAP/serial: Fix incorrect Rx FIFO threshold setting, 
 LSR validation on Tx, and Tx FIFO IRQ generation"
Message-ID: <alpine.DEB.2.00.1304010519260.28273@utopia.booyaka.com>


This reverts commit 1776fd059c40907297d6c26c51876575d63fd9e2.

Commit 1776fd059c40 causes UART sluggishness on the OMAP37xx EVM.
This can be demonstrated by pasting in a ten-character string, like
"ffffffffff", at the serial console.  The string will be echoed back
two to three characters at a time, with about a one-second pause
between groups.  This causes one of the OMAP PM validation tests to
time out:

http://www.pwsan.com/omap/testlogs/test_v3.9-rc5/20130331205513/pm/37xxevm/37xxevm_log.txt

With commit 1776fd059c40 reverted, the test succeeds:

http://www.pwsan.com/omap/testlogs/serial_fix_37xx_v3.9-rc/20130331230517/pm/37xxevm/37xxevm_log.txt

This problem has been present since v3.9-rc1, but was incorrectly 
suspected to be due to commit 6aa9707099c4b25700940eb3d016f16c4434360d 
("lockdep: check that no locks held at freeze time"), due to limitations
in my local testbed.

Signed-off-by: Paul Walmsley <paul at pwsan.com>
Cc: Alexey Pelykh <alexey.pelykh at gmail.com>
Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
---

Alexey, care to make another attempt for 3.11 at fixing the issue you were 
originally debugging, but one that also works on OMAP37xx EVM?  It would 
be good to cc the <linux-omap at vger.kernel.org> on your OMAP work.  If you 
don't have a 37xx EVM, someone there might be able to help you test.

 drivers/tty/serial/omap-serial.c |    8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 4dc4140..9915e4d 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -59,7 +59,6 @@
 
 /* SCR register bitmasks */
 #define OMAP_UART_SCR_RX_TRIG_GRANU1_MASK		(1 << 7)
-#define OMAP_UART_SCR_TX_TRIG_GRANU1_MASK		(1 << 6)
 #define OMAP_UART_SCR_TX_EMPTY			(1 << 3)
 
 /* FCR register bitmasks */
@@ -321,6 +320,9 @@ static void transmit_chars(struct uart_omap_port *up, unsigned int lsr)
 	struct circ_buf *xmit = &up->port.state->xmit;
 	int count;
 
+	if (!(lsr & UART_LSR_THRE))
+		return;
+
 	if (up->port.x_char) {
 		serial_out(up, UART_TX, up->port.x_char);
 		up->port.icount.tx++;
@@ -862,7 +864,7 @@ serial_omap_set_termios(struct uart_port *port, struct ktermios *termios,
 	serial_out(up, UART_IER, up->ier);
 	serial_out(up, UART_LCR, cval);		/* reset DLAB */
 	up->lcr = cval;
-	up->scr = 0;
+	up->scr = OMAP_UART_SCR_TX_EMPTY;
 
 	/* FIFOs and DMA Settings */
 
@@ -886,6 +888,8 @@ serial_omap_set_termios(struct uart_port *port, struct ktermios *termios,
 	serial_out(up, UART_MCR, up->mcr | UART_MCR_TCRTLR);
 	/* FIFO ENABLE, DMA MODE */
 
+	up->scr |= OMAP_UART_SCR_RX_TRIG_GRANU1_MASK;
+
 	/* Set receive FIFO threshold to 16 characters and
 	 * transmit FIFO threshold to 16 spaces
 	 */
-- 
1.7.10.4



From paul at pwsan.com  Mon Apr  1 01:35:13 2013
From: paul at pwsan.com (Paul Walmsley)
Date: Mon, 1 Apr 2013 05:35:13 +0000 (UTC)
Subject: OMAP baseline test results for v3.9-rc5
Message-ID: <alpine.DEB.2.00.1304010531500.28273@utopia.booyaka.com>


Here are some basic OMAP test results for Linux v3.9-rc5.
Logs and other details at:

    http://www.pwsan.com/omap/testlogs/test_v3.9-rc5/20130331205513/


Test summary
------------

Build:
    FAIL ( 2/16): am33xx_only, omap2plus_defconfig_2430sdp_only
    Pass (14/16): n800_multi_omap2xxx, n800_only_a, omap1_defconfig,
		  omap1_defconfig_1510innovator_only, 
		  omap1_defconfig_5912osk_only,
		  omap2plus_defconfig, omap2plus_defconfig_cpupm,
		  omap2plus_defconfig_no_pm,
		  omap2plus_defconfig_omap2_4_only,
		  omap2plus_defconfig_omap3_4_only,
		  rmk_omap3430_ldp_allnoconfig,
		  rmk_omap3430_ldp_oldconfig,
		  rmk_omap4430_sdp_allnoconfig
		  rmk_omap4430_sdp_oldconfig

Boot to userspace:
    FAIL ( 1/11): am335xbone
    Pass (10/11): 2420n800, 2430sdp, 3517evm, 3530es3beagle,
  	   	  3730beaglexm, 37xxevm, 4430es2panda, 4460pandaes,
		  5912osk, cmt3517

PM ret, suspend:
    FAIL ( 4/ 6): 2430sdp, 37xxevm, 4430es2panda, 4460pandaes
    Pass ( 2/ 6): 3530es3beagle, 3730beaglexm

PM ret, dynamic idle:
    FAIL ( 4/ 6): 2430sdp, 37xxevm, 4430es2panda, 4460pandaes
    Pass ( 2/ 6): 3530es3beagle, 3730beaglexm

PM off, suspend:
    FAIL ( 3/ 5): 37xxevm, 4430es2panda, 4460pandaes
    Pass ( 2/ 5): 3530es3beagle, 3730beaglexm

PM off, dynamic idle:
    FAIL ( 3/ 5): 37xxevm, 4430es2panda, 4460pandaes
    Pass ( 2/ 5): 3530es3beagle, 3730beaglexm


Failing tests: fixed by posted patches
--------------------------------------

Build:

* am33xx_only, omap2plus_defconfig_2430sdp_only: omap-{smp,hotplug}.c link errors
  - Discussion & RFC patch: http://www.spinics.net/lists/arm-kernel/msg230017.html

PM:

* 37xx EVM: UART sluggishness causes timeouts
  - Caused by commit 1776fd059c40907297d6c26c51876575d63fd9e2 
  - http://marc.info/?l=linux-omap&m=136479391601254&w=2

* 4460pandaes: CORE, L3INIT didn't enter target state
  - Caused by 17b7e7d33530e2bbd3bdc90f4db09b91cfdde2bb
    (ARM: OMAP4: clock/hwmod data: start to remove some IP block control
     "clocks")
  - Fixed by "ARM: OMAP4: PM: fix PM regression introduced by recent clock
    cleanup"
    - http://www.spinics.net/lists/arm-kernel/msg224419.html


Failing tests: needing investigation
------------------------------------

Boot tests:

* 3517EVM & CM-T3517: boot hangs with NFS root
  - Likely some Kconfig, board file, and PM issues with EMAC
  - Longstanding bug
  - Not currently part of the automated test suite

Boot warnings:

* CM-T3517: L3 in-band error with IPSS during boot
  - Cause unknown but see http://marc.info/?l=linux-omap&m=134833869730129&w=2
  - Longstanding issue; does not occur on the 3517EVM

PM tests:

* 2430sdp: pwrdm state mismatch(dsp_pwrdm) 0 != 3
  - need to doublecheck wakeup dependencies
  - (am assuming it's still there; userspace problems prevent the test
     from running, probably due to the lock warning)

* 2430sdp: power domains not entering retention
  - Cause unknown
  - (am assuming it's still there; userspace problems prevent the test
     from running, probably due to the lock warning)

* 4430es2panda, 4460pandaes: pwrdm state mismatch on CAM, DSS, ABE

* 4460pandaes: pwrdm state mismatch on IVAHD, TESLA 

* 4430es2panda: CORE, TESLA, IVAHD, L3INIT didn't enter target state
  - Probably due to lack of reset code for M3, DSP, SL2IF, FSUSB
    per discussion with Tero Kristo
  - Likely dependent on the bootloader version
    - fails with 2012.07-00136-g755de79
  - http://marc.info/?l=linux-arm-kernel&m=136432340618226&w=2

* 4460pandaes: chip not entering retention in dynamic idle
  - Presumably 4430es2panda also fails this
  - Suspend-to-RAM enters full chip retention

* 3730 Beagle XM: does not serial wake from off-idle suspend when console
  UART doesn't clock-gate ("debug ignore_loglevel")
  - Cause unknown
  - Not yet part of the automated test suite
  - Re-tested at v3.7; still failing:
    http://www.pwsan.com/omap/transcripts/20121211-3730beaglexm-3.7-pm-offmode-fail-debug.txt

Other:

* 4430es2panda: omap_hwmod: l3_instr: _wait_target_disable failed
  - Unknown cause; could be due to the lack of hierarchical enable/disable
    in hwmod code
  - Jon Hunter and Santosh Shilimkar report this does not appear with
    the same X-loader/bootloader on his 4430ES2.3 Panda, so could be
    ES-level dependent


vmlinux object size
(delta in bytes from test_v3.9-rc4 (8bb9660418e05bb1845ac1a2428444d78e322cc7)):
   text     data      bss    total  kernel
   +711        0        0     +711  n800_multi_omap2xxx
   +695        0        0     +695  n800_only_a
   +809        0        0     +809  omap1_defconfig
   +813        0        0     +813  omap1_defconfig_1510innovator_only
+5583029  +312636  +117376  +6013041  omap1_defconfig_5912osk_only
  +4419      -16        0    +4403  omap2plus_defconfig
   +323       -8        0     +315  omap2plus_defconfig_cpupm
  +1111       -8        0    +1103  omap2plus_defconfig_no_pm
   +323      +24        0     +347  omap2plus_defconfig_omap2_4_only
   +331      -16        0     +315  omap2plus_defconfig_omap3_4_only
  +1024        0      -64     +960  rmk_omap3430_ldp_allnoconfig
   +527      -16        0     +511  rmk_omap3430_ldp_oldconfig
  +1024        0      -64     +960  rmk_omap4430_sdp_allnoconfig
  +1097       -8        0    +1089  rmk_omap4430_sdp_oldconfig




From santosh.shilimkar at ti.com  Mon Apr  1 01:56:24 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Mon, 1 Apr 2013 11:26:24 +0530
Subject: [PATCH 6/8] SERIAL: OMAP: Remove the slave idle handling from
 the driver
In-Reply-To: <alpine.DEB.2.00.1303310140210.6436@utopia.booyaka.com>
References: <1361354444-18230-1-git-send-email-santosh.shilimkar@ti.com>
 <alpine.DEB.2.00.1303310136490.6436@utopia.booyaka.com>
 <alpine.DEB.2.00.1303310140210.6436@utopia.booyaka.com>
Message-ID: <51592188.5000109@ti.com>

On Sunday 31 March 2013 07:10 AM, Paul Walmsley wrote:
> 
> (and also please add Greg's ack when this is reposted)
> 
> 
Yes. His ack is already picked up in the pull request I sent.
Will add a note about DMA support in the commit.

Regards,
Santosh



From deepthi at linux.vnet.ibm.com  Mon Apr  1 02:05:59 2013
From: deepthi at linux.vnet.ibm.com (Deepthi Dharwar)
Date: Mon, 01 Apr 2013 11:35:59 +0530
Subject: How to facilitate the cpuidle drivers to go to the same direction
 (Was: Re: [PATCH 4/9] ARM: OMAP4: cpuidle: fix wrong driver
 initialization)
In-Reply-To: <5155B85F.6030808@linaro.org>
References: <1364553095-25110-1-git-send-email-daniel.lezcano@linaro.org>
 <1364553095-25110-4-git-send-email-daniel.lezcano@linaro.org>
 <51556F1D.5030208@ti.com> <515570DF.5010608@linaro.org>
 <CAP245DX+mYQhhJ-fU6PQdV6V-1P7PGUaOoNo+QdhRFaQR=wiEQ@mail.gmail.com>
 <51558723.1050904@ti.com>
 <CAP245DWAAgQ4co34mdkFgepC5kP9v0n6B954ej2X_y20LE9kSQ@mail.gmail.com>
 <5155AEE7.106@ti.com> <5155B85F.6030808@linaro.org>
Message-ID: <515923C7.8040408@linux.vnet.ibm.com>

On 03/29/2013 09:20 PM, Daniel Lezcano wrote:
> On 03/29/2013 04:10 PM, Santosh Shilimkar wrote:
>> On Friday 29 March 2013 06:20 PM, Amit Kucheria wrote:
>>> On Fri, Mar 29, 2013 at 5:50 PM, Santosh Shilimkar
>>> <santosh.shilimkar at ti.com> wrote:
>>>> On Friday 29 March 2013 05:26 PM, Amit Kucheria wrote:
>>>>> On Fri, Mar 29, 2013 at 4:15 PM, Daniel Lezcano
>>>>> <daniel.lezcano at linaro.org> wrote:
>>>>>> On 03/29/2013 11:38 AM, Santosh Shilimkar wrote:
>>>>>>> On Friday 29 March 2013 04:01 PM, Daniel Lezcano wrote:
>>>>>>>> The driver is initialized several times. This is wrong and if the
>>>>>>>> return code of the function was checked, it will return -EINVAL.
>>>>>>>>
>>>>>>>> Move this initialization out of the loop.
>>>>>>>>
>>>>>>>> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
>>>>>>>> ---
>>>>>>> Fix for this is already and v2 of the patch is here [1]
>>>>>>
>>>>>> Ah, ok. Thanks for reviewing the patch.
>>>>>>
>>>>>> Can we find a solution to have a single entry point to sumbit patches
>>>>>> for all the cpuidle drivers ?
>>>>>>
>>>>>> Otherwise, consolidating them is a pain: a patch for the samsung tree,
>>>>>> another one for the at91 tree, etc ... and wait for all the trees to
>>>>>> sync before continuing to consolidate the code.
>>>>>>
>>>>>> Wouldn't be worth to move these drivers under the PM umbrella instead of
>>>>>> the SoC specific code ?
>>>>>>
>>>>>> Any idea to simplify the cpuidle consolidation and maintenance ?
>>>>>
>>>>> Adding Arnd and Olof to this discussion since atleast the ARM drivers
>>>>> go through their arm-soc tree.
>>>>>
>>>>> Given the work you're putting in to consolidate the drivers, perhaps
>>>>> they can insist that idle drivers get acked by you?
>>>>>
>>>> Not to create controversy but as a general rule there is nothing
>>>> like *insisting* ack on patches for merge apart from the official
>>>> maintainers(gate keepers).
>>>>
>>>> Having said that, its always good to get more reviews and acks so
>>>> that better code gets merged.
>>>>
>>>> This just my personal opinion.
>>>
>>> I'm not asking for special treatment here. :) I'm requesting one set
>>> of maintainers (arm-soc maintainers) to push back on changes that
>>> don't get platform idle drivers in sync with the consolidation work
>>> that is currently ongoing.
>>>
>>> This will speed up the process since it is hard to track every
>>> SoC-specific list for these changes. Some platform maintainers might
>>> not even be aware of it (those that Daniel hasn't modified yet). A
>>> similar approach seems to have worked for common clock, DT, pinmux,
>>> etc.
>>>
>> Every patch gets pulled into arm-soc/arm-core has to be posted on
>> LAKML. So as long as everybody follows that rule, there is no need to
>> track every SoC lists. And what I have seen so far every this rule
>> has been followed well.
> 
> (Added Benjamin, Deepthi and Paul)
> 
> I don't think everybody is following this rule, patches go to the SoC
> maintainer's tree without sometimes going through lakml.
> 
> Furthermore, there is not only ARM, there is also acpi_idle, intel_idle,
> pseries_idle and sh_idle, respectively located in:
> 
> drivers/acpi/processor_idle.c
> drivers/acpi/processor_driver.c
> drivers/idle/intel_idle.c
> 
> These ones above are under linux-pm, that is Rafael, like cpuidle, even
> if it is not marked in the MAINTAINERS file, so that should be ok.
> 
> And there is also:
> 
> arch/sh/kernel/cpu/shmobile/cpuidle.c
> arch/powerpc/platforms/pseries/processor_idle.c
> 
> And hopefully, some others in the right place, calxeda_idle and
> kirwood_idle located in drivers/cpuidle.
> 
> In the maintainer file, there is no information about cpuidle at all.
> 
> For example, if someone modify the cpuidle framework allowing to
> consolidate the code across the different drivers, we have to wait for
> the merge before using the new api into the different drivers.
> If we follow strictly the path of the merge tree we fall into a scenario
> where consolidating the drivers takes a loooooong time.
> 
> From my POV, *all* the cpuidle drivers must go under drivers/cpuidle,
> like cpufreq and pass through a single entry point to apply the patches,
> so the cpuidle framework and the drivers are always synced.

I can very much relate to the above mentioned problem, where code
modifications done as a part of cpuidle framework needs to be
reflected in every arch back-end cpuidle driver.
We do have added advantages in moving
all the back-end drivers into drivers/cpuidle.
This would help us achieve better reviews, easier consolidations
and more importantly maintaining sync btw drivers and framework and
the up-streaming process.

But then, this means we get all the
arch specific code out under drivers/cpuidle
which can be very messy. Also instances where the changes
are specifically tied only to the  architecture of the back-end driver
(SoC specific), it is absolutely necessary to get SoC maintainer's review.

Cheers,
Deepthi

> If everyone agree and we reach this consensus, then we can work to move
> these drivers to a single place.
> 
> I think Amit was suggesting to Cc me in the meantime, so while we are
> moving these drivers to this place, I can help to ensure we go to the
> same direction.
> 
> For example, Arnd Cc'ed me about the zynq cpuidle driver when it has
> been posted and, after review, it appeared it was totally obsolete wrt
> the modifications we did this year.
> 
> I propose first to add an entry in MAINTAINERS:
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 4cf5fd3..5b5ab87 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2206,6 +2206,15 @@ S:       Maintained
>  F:     drivers/cpufreq/
>  F:     include/linux/cpufreq.h
> 
> +CPU IDLE DRIVERS
> +M:      Rafael J. Wysocki <rjw at sisk.pl>
> +L:      cpuidle at vger.kernel.org
> +L:      linux-pm at vger.kernel.org
> +S:      Maintained
> +F:      drivers/cpuidle/
> +F:      include/linux/cpuidle.h
> +
>  CPUID/MSR DRIVER
>  M:     "H. Peter Anvin" <hpa at zytor.com>
>  S:     Maintained
> 
> Does it make sense ?
> 
> Thanks
>   -- Daniel
> 
> 



From nsekhar at ti.com  Mon Apr  1 02:12:17 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Mon, 1 Apr 2013 11:42:17 +0530
Subject: [PATCH] ARM: davinci: use is IS_ENABLED macro
In-Reply-To: <CA+V-a8urWyzaU-nKh7sumr3tbmswixzWsumVHMpis6=fgD3Z+g@mail.gmail.com>
References: <1364210495-7938-1-git-send-email-prabhakar.csengg@gmail.com>
 <20130327214347.f2a573510416b86223c58be1@canb.auug.org.au>
 <CA+V-a8urWyzaU-nKh7sumr3tbmswixzWsumVHMpis6=fgD3Z+g@mail.gmail.com>
Message-ID: <51592541.5080903@ti.com>

On 3/28/2013 10:07 AM, Prabhakar Lad wrote:
> Hi Sekhar,
> 
> On Wed, Mar 27, 2013 at 4:13 PM, Stephen Rothwell <sfr at canb.auug.org.au> wrote:
>> Hi,
>>
>> On Mon, 25 Mar 2013 16:51:35 +0530 Prabhakar lad <prabhakar.csengg at gmail.com> wrote:
>>>
>>> --- a/arch/arm/mach-davinci/board-da830-evm.c
>>> +++ b/arch/arm/mach-davinci/board-da830-evm.c
>>> @@ -298,7 +298,7 @@ static const short da830_evm_emif25_pins[] = {
>>>       -1
>>>  };
>>>
>>> -#if defined(CONFIG_MMC_DAVINCI) || defined(CONFIG_MMC_DAVINCI_MODULE)
>>> +#if IS_ENABLED(CONFIG_MMC_DAVINCI)
>>>  #define HAS_MMC      1
>>>  #else
>>>  #define HAS_MMC      0
>>
>> Why not
>>
>> #define HAS_MMC         IS_ENABLED(CONFIG_MMC_DAVINCI)
>>
>> and similarly in the rest?
>>
> Stephen's suggestion looks good to me, if you haven?t queued it i'll post a v2,
> or if you have already queued it I'll create a patch on top of the
> same patch fixing it.
> lemme know how would you want it.

Please post a v2. I will take that instead.

Thanks,
Sekhar


From shawn.guo at linaro.org  Mon Apr  1 02:23:34 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Mon, 1 Apr 2013 14:23:34 +0800
Subject: [PATCH v6 0/8] Reset controller API to reset IP modules on i.MX5
 and i.MX6
In-Reply-To: <1364488523-20310-1-git-send-email-p.zabel@pengutronix.de>
References: <1364488523-20310-1-git-send-email-p.zabel@pengutronix.de>
Message-ID: <20130401062332.GB1693@S2101-09.ap.freescale.net>

On Thu, Mar 28, 2013 at 05:35:15PM +0100, Philipp Zabel wrote:
> The system reset controller (SRC) on i.MX51, i.MX53, and i.MX6q controls
> reset lines to the GPU, VPU, IPU, and OpenVG IP modules.
> 
> The following patches add a simple API for devices to request being reset
> by separate reset controller hardware and implements the reset signal
> device tree binding proposed by Stephen Warren. Contrary to Tegra hardware,
> the i.MX SRC contains self-deasserting reset registers, so I've included
> both ops to manually assert/deassert a reset line, as well as a "reset"
> operation that is supposed to assert the reset line and wait for it to
> deassert.
> 
> The i.MX SRC is enhanced to provide a reset controller and the IPU driver
> is made to request being reset by calling the device_reset(&pdev->dev)
> convenience wrapper during probing.
> 
> No changes since v5, I just reordered the series.

All applied, thanks.



From shawn.guo at linaro.org  Mon Apr  1 02:31:27 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Mon, 1 Apr 2013 14:31:27 +0800
Subject: [GIT PULL] reset API for 3.10
Message-ID: <20130401063126.GC1693@S2101-09.ap.freescale.net>

Hi Arnd, Olof,

This is the pull request of including reset API for 3.10.  We want to
have it go via arm-soc tree, since we will have platform patches
depending on it.

Thanks,
Shawn

The following changes since commit a937536b868b8369b98967929045f1df54234323:

  Linux 3.9-rc3 (2013-03-17 15:59:32 -0700)

are available in the git repository at:

  git://git.linaro.org/people/shawnguo/linux-2.6.git tags/reset-for-3.10

for you to fetch changes up to 749c6f89e9b1579ca7f00c18dec09e3490d394ec:

  reset: Add driver for gpio-controlled reset pins (2013-03-31 23:03:35 +0800)

----------------------------------------------------------------
It adds a simple API for devices to request being reset by separate
reset controller hardware and implements the reset signal device tree
binding proposed by Stephen Warren.  The immediate user for this API
is i.MX System Reset Controller (SRC).  Tegra and a few other platforms
will also use this API.

----------------------------------------------------------------
Philipp Zabel (2):
      reset: Add reset controller API
      reset: Add driver for gpio-controlled reset pins

Stephen Warren (1):
      dt: describe base reset signal binding

 .../devicetree/bindings/reset/gpio-reset.txt       |   37 +++
 Documentation/devicetree/bindings/reset/reset.txt  |   75 +++++
 drivers/Kconfig                                    |    2 +
 drivers/Makefile                                   |    3 +
 drivers/reset/Kconfig                              |   26 ++
 drivers/reset/Makefile                             |    2 +
 drivers/reset/core.c                               |  297 ++++++++++++++++++++
 drivers/reset/gpio-reset.c                         |  208 ++++++++++++++
 include/linux/reset-controller.h                   |   51 ++++
 include/linux/reset.h                              |   18 ++
 10 files changed, 719 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/reset/gpio-reset.txt
 create mode 100644 Documentation/devicetree/bindings/reset/reset.txt
 create mode 100644 drivers/reset/Kconfig
 create mode 100644 drivers/reset/Makefile
 create mode 100644 drivers/reset/core.c
 create mode 100644 drivers/reset/gpio-reset.c
 create mode 100644 include/linux/reset-controller.h
 create mode 100644 include/linux/reset.h



From shawn.guo at linaro.org  Mon Apr  1 02:42:25 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Mon, 1 Apr 2013 14:42:25 +0800
Subject: MicroSys sbc6x support (i.MX6)
In-Reply-To: <20130331201614.GC25751@amd.pavel.ucw.cz>
References: <20130329185500.GB30029@amd.pavel.ucw.cz>
 <20130330113703.GA21042@amd.pavel.ucw.cz>
 <5156D69E.3050600@gmail.com>
 <20130331201614.GC25751@amd.pavel.ucw.cz>
Message-ID: <20130401064224.GD1693@S2101-09.ap.freescale.net>

On Sun, Mar 31, 2013 at 10:16:14PM +0200, Pavel Machek wrote:
> Add support for MicroSys sbc6x board.
> 
> Signed-off-by: Pavel Machek <pavel at denx.de>
> 
Are you using git send-email?  Why the diff stat is missing here?
Generally, I prefer to have prefix "ARM: dts: ..." put on subject for
such type of dts patches.

Also, please can you rebase the patch on my imx/dt branch below?

  git://git.linaro.org/people/shawnguo/linux-2.6.git imx/dt

> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 9c62558..1590ae9 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -99,7 +99,8 @@ dtb-$(CONFIG_ARCH_MXC) += \
>  	imx6q-arm2.dtb \
>  	imx6q-sabreauto.dtb \
>  	imx6q-sabrelite.dtb \
> -	imx6q-sabresd.dtb
> +	imx6q-sabresd.dtb \
> +	imx6q-sbc6x.dtb
>  dtb-$(CONFIG_ARCH_MXS) += imx23-evk.dtb \
>  	imx23-olinuxino.dtb \
>  	imx23-stmp378x_devb.dtb \
> diff --git a/arch/arm/boot/dts/imx6q-sbc6x.dts b/arch/arm/boot/dts/imx6q-sbc6x.dts
> new file mode 100644
> index 0000000..cca8a46
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx6q-sbc6x.dts
> @@ -0,0 +1,44 @@
> +/*
> + * Copyright 2013 Pavel Machek <pavel at denx.de>
> + *
> + * The code contained herein is licensed under the GNU General Public
> + * License V2.
> + */
> +
> +/dts-v1/;
> +/include/ "imx6q.dtsi"
> +
> +/ {
> +	model = "MicroSys sbc6x board";
> +	compatible = "fsl,imx6q";

We generally have a vendor specific compatible string for custom
boards. 

> +
> +	memory {
> +		reg = <0x10000000 0x80000000>;
> +	};
> +};
> +
> +&uart1 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_uart1_1>;
> +	status = "okay";
> +};
> +
> +&fec {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_enet_1>;
> +	phy-mode = "rgmii";
> +	status = "okay";
> +};
> +
> +&usdhc3 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_usdhc3_2>;
> +	status = "okay";
> +};
> +
> +&usbotg {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_usbotg_1>;
> +	disable-over-current;
> +	status = "okay";
> +};

I'm going to be nit on new board dts files about the node order.  Please
sort them by label name in alphabet order.

	&fec
	&uart1
	&usbotg
	&usdhc3

Shawn



From prabhakar.csengg at gmail.com  Mon Apr  1 03:13:44 2013
From: prabhakar.csengg at gmail.com (Prabhakar lad)
Date: Mon,  1 Apr 2013 12:43:44 +0530
Subject: [PATCH v2] ARM: davinci: use is IS_ENABLED macro
Message-ID: <1364800424-4239-1-git-send-email-prabhakar.csengg@gmail.com>

From: Lad, Prabhakar <prabhakar.csengg at gmail.com>

This patches replaces #if defined() by IS_ENABLED macro, which provides
better readability.

Signed-off-by: Lad, Prabhakar <prabhakar.csengg at gmail.com>
Cc: Sekhar Nori <nsekhar at ti.com>
Cc: Stephen Rothwell <sfr at canb.auug.org.au>
Cc: Randy Dunlap <rdunlap at infradead.org>
---
 Changes for V2:
 1: Fixed review comments pointed by Stephen
    (https://patchwork.kernel.org/patch/2330531/)

 arch/arm/mach-davinci/board-da830-evm.c   |    6 +-----
 arch/arm/mach-davinci/board-da850-evm.c   |    7 +------
 arch/arm/mach-davinci/board-dm644x-evm.c  |   25 +++++--------------------
 arch/arm/mach-davinci/board-dm646x-evm.c  |    7 +------
 arch/arm/mach-davinci/board-neuros-osd2.c |   15 ++-------------
 arch/arm/mach-davinci/devices.c           |    2 +-
 arch/arm/mach-davinci/usb.c               |    2 +-
 7 files changed, 12 insertions(+), 52 deletions(-)

diff --git a/arch/arm/mach-davinci/board-da830-evm.c b/arch/arm/mach-davinci/board-da830-evm.c
index 6da25ee..b348e44 100644
--- a/arch/arm/mach-davinci/board-da830-evm.c
+++ b/arch/arm/mach-davinci/board-da830-evm.c
@@ -298,11 +298,7 @@ static const short da830_evm_emif25_pins[] = {
 	-1
 };
 
-#if defined(CONFIG_MMC_DAVINCI) || defined(CONFIG_MMC_DAVINCI_MODULE)
-#define HAS_MMC	1
-#else
-#define HAS_MMC	0
-#endif
+#define HAS_MMC		IS_ENABLED(CONFIG_MMC_DAVINCI)
 
 #ifdef CONFIG_DA830_UI_NAND
 static struct mtd_partition da830_evm_nand_partitions[] = {
diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c
index c2dfe06..a74dec7 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -335,12 +335,7 @@ static const short da850_evm_nor_pins[] = {
 	-1
 };
 
-#if defined(CONFIG_MMC_DAVINCI) || \
-    defined(CONFIG_MMC_DAVINCI_MODULE)
-#define HAS_MMC 1
-#else
-#define HAS_MMC 0
-#endif
+#define HAS_MMC		IS_ENABLED(CONFIG_MMC_DAVINCI)
 
 static inline void da850_evm_setup_nor_nand(void)
 {
diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c b/arch/arm/mach-davinci/board-dm644x-evm.c
index 71735e7..a042f27 100644
--- a/arch/arm/mach-davinci/board-dm644x-evm.c
+++ b/arch/arm/mach-davinci/board-dm644x-evm.c
@@ -750,26 +750,11 @@ static int davinci_phy_fixup(struct phy_device *phydev)
 	return 0;
 }
 
-#if defined(CONFIG_BLK_DEV_PALMCHIP_BK3710) || \
-    defined(CONFIG_BLK_DEV_PALMCHIP_BK3710_MODULE)
-#define HAS_ATA 1
-#else
-#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
-
-#if defined(CONFIG_MTD_NAND_DAVINCI) || \
-    defined(CONFIG_MTD_NAND_DAVINCI_MODULE)
-#define HAS_NAND 1
-#else
-#define HAS_NAND 0
-#endif
+#define HAS_ATA		IS_ENABLED(CONFIG_BLK_DEV_PALMCHIP_BK3710)
+
+#define HAS_NOR		IS_ENABLED(CONFIG_MTD_PHYSMAP)
+
+#define HAS_NAND	IS_ENABLED(CONFIG_MTD_NAND_DAVINCI)
 
 static __init void davinci_evm_init(void)
 {
diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c b/arch/arm/mach-davinci/board-dm646x-evm.c
index de7adff..03785e0 100644
--- a/arch/arm/mach-davinci/board-dm646x-evm.c
+++ b/arch/arm/mach-davinci/board-dm646x-evm.c
@@ -117,12 +117,7 @@ static struct platform_device davinci_nand_device = {
 	},
 };
 
-#if defined(CONFIG_BLK_DEV_PALMCHIP_BK3710) || \
-    defined(CONFIG_BLK_DEV_PALMCHIP_BK3710_MODULE)
-#define HAS_ATA 1
-#else
-#define HAS_ATA 0
-#endif
+#define HAS_ATA		IS_ENABLED(CONFIG_BLK_DEV_PALMCHIP_BK3710)
 
 /* CPLD Register 0 bits to control ATA */
 #define DM646X_EVM_ATA_RST		BIT(0)
diff --git a/arch/arm/mach-davinci/board-neuros-osd2.c b/arch/arm/mach-davinci/board-neuros-osd2.c
index 1c98107..ea6728b 100644
--- a/arch/arm/mach-davinci/board-neuros-osd2.c
+++ b/arch/arm/mach-davinci/board-neuros-osd2.c
@@ -167,20 +167,9 @@ static struct davinci_mmc_config davinci_ntosd2_mmc_config = {
 	.version	= MMC_CTLR_VERSION_1
 };
 
+#define HAS_ATA		IS_ENABLED(CONFIG_BLK_DEV_PALMCHIP_BK3710)
 
-#if defined(CONFIG_BLK_DEV_PALMCHIP_BK3710) || \
-	defined(CONFIG_BLK_DEV_PALMCHIP_BK3710_MODULE)
-#define HAS_ATA 1
-#else
-#define HAS_ATA 0
-#endif
-
-#if defined(CONFIG_MTD_NAND_DAVINCI) || \
-	defined(CONFIG_MTD_NAND_DAVINCI_MODULE)
-#define HAS_NAND 1
-#else
-#define HAS_NAND 0
-#endif
+#define HAS_NAND	IS_ENABLED(CONFIG_MTD_NAND_DAVINCI)
 
 static __init void davinci_ntosd2_init(void)
 {
diff --git a/arch/arm/mach-davinci/devices.c b/arch/arm/mach-davinci/devices.c
index 4c48a36..df135de 100644
--- a/arch/arm/mach-davinci/devices.c
+++ b/arch/arm/mach-davinci/devices.c
@@ -119,7 +119,7 @@ void __init davinci_init_ide(void)
 	platform_device_register(&ide_device);
 }
 
-#if	defined(CONFIG_MMC_DAVINCI) || defined(CONFIG_MMC_DAVINCI_MODULE)
+#if IS_ENABLED(CONFIG_MMC_DAVINCI)
 
 static u64 mmcsd0_dma_mask = DMA_BIT_MASK(32);
 
diff --git a/arch/arm/mach-davinci/usb.c b/arch/arm/mach-davinci/usb.c
index 34509ff..5764d65 100644
--- a/arch/arm/mach-davinci/usb.c
+++ b/arch/arm/mach-davinci/usb.c
@@ -17,7 +17,7 @@
 #define DA8XX_USB0_BASE 	0x01e00000
 #define DA8XX_USB1_BASE 	0x01e25000
 
-#if defined(CONFIG_USB_MUSB_HDRC) || defined(CONFIG_USB_MUSB_HDRC_MODULE)
+#if IS_ENABLED(CONFIG_USB_MUSB_HDRC)
 static struct musb_hdrc_eps_bits musb_eps[] = {
 	{ "ep1_tx", 8, },
 	{ "ep1_rx", 8, },
-- 
1.7.4.1



From shawn.guo at linaro.org  Mon Apr  1 03:41:09 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Mon, 1 Apr 2013 15:41:09 +0800
Subject: [GIT PULL] reset API for 3.10
In-Reply-To: <20130401063126.GC1693@S2101-09.ap.freescale.net>
References: <20130401063126.GC1693@S2101-09.ap.freescale.net>
Message-ID: <20130401074106.GB27148@S2101-09.ap.freescale.net>

On Mon, Apr 01, 2013 at 02:31:27PM +0800, Shawn Guo wrote:
> Hi Arnd, Olof,
> 
> This is the pull request of including reset API for 3.10.  We want to
> have it go via arm-soc tree, since we will have platform patches
> depending on it.

Please ignore this.  I wasn't aware of that Philipp already sent a pull
request for that.  I will rebuild my IMX branches on that.

Shawn



From agust at denx.de  Mon Apr  1 03:43:58 2013
From: agust at denx.de (Anatolij Gustschin)
Date: Mon, 1 Apr 2013 09:43:58 +0200
Subject: MicroSys sbc6x support (i.MX6)
In-Reply-To: <20130401064224.GD1693@S2101-09.ap.freescale.net>
References: <20130329185500.GB30029@amd.pavel.ucw.cz>
 <20130330113703.GA21042@amd.pavel.ucw.cz>
 <5156D69E.3050600@gmail.com>
 <20130331201614.GC25751@amd.pavel.ucw.cz>
 <20130401064224.GD1693@S2101-09.ap.freescale.net>
Message-ID: <20130401094358.4c313f66@crub>

On Mon, 1 Apr 2013 14:42:25 +0800
Shawn Guo <shawn.guo at linaro.org> wrote:
...
> > +/dts-v1/;
> > +/include/ "imx6q.dtsi"
> > +
> > +/ {
> > +	model = "MicroSys sbc6x board";
> > +	compatible = "fsl,imx6q";
> 
> We generally have a vendor specific compatible string for custom
> boards. 

Couldn't this be a compatible list like

    compatible = "microsys,sbc6x", "fsl,imx6q";

Then, we can test for imx6q compatibility in drivers or
platform code using of_machine_is_compatible(). Or what is the
preferred way to test for SoC compatibility?

Thanks,

Anatolij


From shawn.guo at linaro.org  Mon Apr  1 03:47:45 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Mon, 1 Apr 2013 15:47:45 +0800
Subject: MicroSys sbc6x support (i.MX6)
In-Reply-To: <20130401094358.4c313f66@crub>
References: <20130329185500.GB30029@amd.pavel.ucw.cz>
 <20130330113703.GA21042@amd.pavel.ucw.cz>
 <5156D69E.3050600@gmail.com>
 <20130331201614.GC25751@amd.pavel.ucw.cz>
 <20130401064224.GD1693@S2101-09.ap.freescale.net>
 <20130401094358.4c313f66@crub>
Message-ID: <20130401074743.GC27148@S2101-09.ap.freescale.net>

On Mon, Apr 01, 2013 at 09:43:58AM +0200, Anatolij Gustschin wrote:
> On Mon, 1 Apr 2013 14:42:25 +0800
> Shawn Guo <shawn.guo at linaro.org> wrote:
> ...
> > > +/dts-v1/;
> > > +/include/ "imx6q.dtsi"
> > > +
> > > +/ {
> > > +	model = "MicroSys sbc6x board";
> > > +	compatible = "fsl,imx6q";
> > 
> > We generally have a vendor specific compatible string for custom
> > boards. 
> 
> Couldn't this be a compatible list like
> 
>     compatible = "microsys,sbc6x", "fsl,imx6q";
> 
Yes, this is what I was asking for and every imx board dts file is
doing.  Sorry if I did not make it clear.

Shawn

> Then, we can test for imx6q compatibility in drivers or
> platform code using of_machine_is_compatible(). Or what is the
> preferred way to test for SoC compatibility?
> 
> Thanks,
> 
> Anatolij



From daniel.lezcano at linaro.org  Mon Apr  1 04:26:11 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Mon, 01 Apr 2013 10:26:11 +0200
Subject: How to facilitate the cpuidle drivers to go to the same direction
 (Was: Re: [PATCH 4/9] ARM: OMAP4: cpuidle: fix wrong driver
 initialization)
In-Reply-To: <515923C7.8040408@linux.vnet.ibm.com>
References: <1364553095-25110-1-git-send-email-daniel.lezcano@linaro.org>
 <1364553095-25110-4-git-send-email-daniel.lezcano@linaro.org>
 <51556F1D.5030208@ti.com> <515570DF.5010608@linaro.org>
 <CAP245DX+mYQhhJ-fU6PQdV6V-1P7PGUaOoNo+QdhRFaQR=wiEQ@mail.gmail.com>
 <51558723.1050904@ti.com>
 <CAP245DWAAgQ4co34mdkFgepC5kP9v0n6B954ej2X_y20LE9kSQ@mail.gmail.com>
 <5155AEE7.106@ti.com> <5155B85F.6030808@linaro.org>
 <515923C7.8040408@linux.vnet.ibm.com>
Message-ID: <515944A3.8090100@linaro.org>

On 04/01/2013 08:05 AM, Deepthi Dharwar wrote:
> On 03/29/2013 09:20 PM, Daniel Lezcano wrote:
>> On 03/29/2013 04:10 PM, Santosh Shilimkar wrote:
>>> On Friday 29 March 2013 06:20 PM, Amit Kucheria wrote:
>>>> On Fri, Mar 29, 2013 at 5:50 PM, Santosh Shilimkar
>>>> <santosh.shilimkar at ti.com> wrote:
>>>>> On Friday 29 March 2013 05:26 PM, Amit Kucheria wrote:
>>>>>> On Fri, Mar 29, 2013 at 4:15 PM, Daniel Lezcano
>>>>>> <daniel.lezcano at linaro.org> wrote:
>>>>>>> On 03/29/2013 11:38 AM, Santosh Shilimkar wrote:
>>>>>>>> On Friday 29 March 2013 04:01 PM, Daniel Lezcano wrote:
>>>>>>>>> The driver is initialized several times. This is wrong and if the
>>>>>>>>> return code of the function was checked, it will return -EINVAL.
>>>>>>>>>
>>>>>>>>> Move this initialization out of the loop.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
>>>>>>>>> ---
>>>>>>>> Fix for this is already and v2 of the patch is here [1]
>>>>>>>
>>>>>>> Ah, ok. Thanks for reviewing the patch.
>>>>>>>
>>>>>>> Can we find a solution to have a single entry point to sumbit patches
>>>>>>> for all the cpuidle drivers ?
>>>>>>>
>>>>>>> Otherwise, consolidating them is a pain: a patch for the samsung tree,
>>>>>>> another one for the at91 tree, etc ... and wait for all the trees to
>>>>>>> sync before continuing to consolidate the code.
>>>>>>>
>>>>>>> Wouldn't be worth to move these drivers under the PM umbrella instead of
>>>>>>> the SoC specific code ?
>>>>>>>
>>>>>>> Any idea to simplify the cpuidle consolidation and maintenance ?
>>>>>>
>>>>>> Adding Arnd and Olof to this discussion since atleast the ARM drivers
>>>>>> go through their arm-soc tree.
>>>>>>
>>>>>> Given the work you're putting in to consolidate the drivers, perhaps
>>>>>> they can insist that idle drivers get acked by you?
>>>>>>
>>>>> Not to create controversy but as a general rule there is nothing
>>>>> like *insisting* ack on patches for merge apart from the official
>>>>> maintainers(gate keepers).
>>>>>
>>>>> Having said that, its always good to get more reviews and acks so
>>>>> that better code gets merged.
>>>>>
>>>>> This just my personal opinion.
>>>>
>>>> I'm not asking for special treatment here. :) I'm requesting one set
>>>> of maintainers (arm-soc maintainers) to push back on changes that
>>>> don't get platform idle drivers in sync with the consolidation work
>>>> that is currently ongoing.
>>>>
>>>> This will speed up the process since it is hard to track every
>>>> SoC-specific list for these changes. Some platform maintainers might
>>>> not even be aware of it (those that Daniel hasn't modified yet). A
>>>> similar approach seems to have worked for common clock, DT, pinmux,
>>>> etc.
>>>>
>>> Every patch gets pulled into arm-soc/arm-core has to be posted on
>>> LAKML. So as long as everybody follows that rule, there is no need to
>>> track every SoC lists. And what I have seen so far every this rule
>>> has been followed well.
>>
>> (Added Benjamin, Deepthi and Paul)
>>
>> I don't think everybody is following this rule, patches go to the SoC
>> maintainer's tree without sometimes going through lakml.
>>
>> Furthermore, there is not only ARM, there is also acpi_idle, intel_idle,
>> pseries_idle and sh_idle, respectively located in:
>>
>> drivers/acpi/processor_idle.c
>> drivers/acpi/processor_driver.c
>> drivers/idle/intel_idle.c
>>
>> These ones above are under linux-pm, that is Rafael, like cpuidle, even
>> if it is not marked in the MAINTAINERS file, so that should be ok.
>>
>> And there is also:
>>
>> arch/sh/kernel/cpu/shmobile/cpuidle.c
>> arch/powerpc/platforms/pseries/processor_idle.c
>>
>> And hopefully, some others in the right place, calxeda_idle and
>> kirwood_idle located in drivers/cpuidle.
>>
>> In the maintainer file, there is no information about cpuidle at all.
>>
>> For example, if someone modify the cpuidle framework allowing to
>> consolidate the code across the different drivers, we have to wait for
>> the merge before using the new api into the different drivers.
>> If we follow strictly the path of the merge tree we fall into a scenario
>> where consolidating the drivers takes a loooooong time.
>>
>> From my POV, *all* the cpuidle drivers must go under drivers/cpuidle,
>> like cpufreq and pass through a single entry point to apply the patches,
>> so the cpuidle framework and the drivers are always synced.
> 
> I can very much relate to the above mentioned problem, where code
> modifications done as a part of cpuidle framework needs to be
> reflected in every arch back-end cpuidle driver.
> We do have added advantages in moving
> all the back-end drivers into drivers/cpuidle.
> This would help us achieve better reviews, easier consolidations
> and more importantly maintaining sync btw drivers and framework and
> the up-streaming process.
> 
> But then, this means we get all the
> arch specific code out under drivers/cpuidle
> which can be very messy. Also instances where the changes
> are specifically tied only to the  architecture of the back-end driver
> (SoC specific), it is absolutely necessary to get SoC maintainer's review.

Yes, I agree.

This is why an important work of separating the PM code from the cpuidle
driver must be done in order to achieve this migration.
Some of this has been done for the at91 and u8500 driver.

Thanks
  -- Daniel

> 
> Cheers,
> Deepthi
> 
>> If everyone agree and we reach this consensus, then we can work to move
>> these drivers to a single place.
>>
>> I think Amit was suggesting to Cc me in the meantime, so while we are
>> moving these drivers to this place, I can help to ensure we go to the
>> same direction.
>>
>> For example, Arnd Cc'ed me about the zynq cpuidle driver when it has
>> been posted and, after review, it appeared it was totally obsolete wrt
>> the modifications we did this year.
>>
>> I propose first to add an entry in MAINTAINERS:
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 4cf5fd3..5b5ab87 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -2206,6 +2206,15 @@ S:       Maintained
>>  F:     drivers/cpufreq/
>>  F:     include/linux/cpufreq.h
>>
>> +CPU IDLE DRIVERS
>> +M:      Rafael J. Wysocki <rjw at sisk.pl>
>> +L:      cpuidle at vger.kernel.org
>> +L:      linux-pm at vger.kernel.org
>> +S:      Maintained
>> +F:      drivers/cpuidle/
>> +F:      include/linux/cpuidle.h
>> +
>>  CPUID/MSR DRIVER
>>  M:     "H. Peter Anvin" <hpa at zytor.com>
>>  S:     Maintained
>>
>> Does it make sense ?
>>
>> Thanks
>>   -- Daniel
>>
>>
> 


-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From iamjoonsoo.kim at lge.com  Mon Apr  1 04:28:49 2013
From: iamjoonsoo.kim at lge.com (Joonsoo Kim)
Date: Mon, 1 Apr 2013 17:28:49 +0900
Subject: [RFC PATCH 5/6] ARM, mm: change meaning of max_low_pfn to
 maximum pfn for nobootmem
In-Reply-To: <20130325094816.GO4977@n2100.arm.linux.org.uk>
References: <1364184674-13798-1-git-send-email-iamjoonsoo.kim@lge.com>
 <1364184674-13798-6-git-send-email-iamjoonsoo.kim@lge.com>
 <20130325094816.GO4977@n2100.arm.linux.org.uk>
Message-ID: <20130401082849.GE12015@lge.com>

Hello, Russell.

On Mon, Mar 25, 2013 at 09:48:16AM +0000, Russell King - ARM Linux wrote:
> On Mon, Mar 25, 2013 at 01:11:13PM +0900, Joonsoo Kim wrote:
> > nobootmem use max_low_pfn for computing boundary in free_all_bootmem()
> > So we need proper value to max_low_pfn.
> > 
> > But, there is some difficulty related to max_low_pfn. max_low_pfn is used
> > for two meanings in various architectures. One is for number of pages
> > in lowmem and the other is for maximum lowmem pfn. Now, in ARM, it is used
> > as number of pages in lowmem. You can get more information in below link.
> > http://lwn.net/Articles/543408/
> > http://lwn.net/Articles/543424/
> > 
> > As I investigated, architectures which use max_low_pfn as maximum pfn are
> > more than others, so to change meaning of max_low_pfn to maximum pfn
> > is preferable solution to me. This patch change max_low_pfn as maximum
> > lowmem pfn in ARM. In addition, min_low_pfn, max_pfn is assigned according
> > to this criteria.
> > 
> > There is no real user for max_low_pfn except block/blk-setting.c and
> > blk-setting.c assume that max_low_pfn is maximum lowmem pfn,
> > so this patch may not harm anything.
> 
> This will need some very rigorous testing before it can go into mainline.

There is no attention from others to this patchset. :)
Do you have any plan to test this?
What I can do best is just to run this patchset on my platform.

Would you guide me how to go into mainline for this patchset.

Thanks.

> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/


From alexey.pelykh at gmail.com  Mon Apr  1 04:31:40 2013
From: alexey.pelykh at gmail.com (Alexey Pelykh)
Date: Mon, 1 Apr 2013 11:31:40 +0300
Subject: [PATCH] Revert "OMAP/serial: Fix incorrect Rx FIFO threshold
 setting, LSR validation on Tx, and Tx FIFO IRQ generation"
In-Reply-To: <alpine.DEB.2.00.1304010519260.28273@utopia.booyaka.com>
References: <alpine.DEB.2.00.1304010519260.28273@utopia.booyaka.com>
Message-ID: <CAOmKuSpttQJmrL=Htiz-Zc4voAF7CnG_GQYAO2onKpauwYjtvw@mail.gmail.com>

Actually, I've tested my patch on DM3730, and, at least, can prove
that original settings of UART are incorrect according to TRM of
processor. What settings of UART you were using to reproduce issue?
I'd like to kindly ask you to describe your test environment, since
I've never experiences issues that you've described nor in debug
console, nor in regular UART usage.

On Mon, Apr 1, 2013 at 8:25 AM, Paul Walmsley <paul at pwsan.com> wrote:
>
> This reverts commit 1776fd059c40907297d6c26c51876575d63fd9e2.
>
> Commit 1776fd059c40 causes UART sluggishness on the OMAP37xx EVM.
> This can be demonstrated by pasting in a ten-character string, like
> "ffffffffff", at the serial console.  The string will be echoed back
> two to three characters at a time, with about a one-second pause
> between groups.  This causes one of the OMAP PM validation tests to
> time out:
>
> http://www.pwsan.com/omap/testlogs/test_v3.9-rc5/20130331205513/pm/37xxevm/37xxevm_log.txt
>
> With commit 1776fd059c40 reverted, the test succeeds:
>
> http://www.pwsan.com/omap/testlogs/serial_fix_37xx_v3.9-rc/20130331230517/pm/37xxevm/37xxevm_log.txt
>
> This problem has been present since v3.9-rc1, but was incorrectly
> suspected to be due to commit 6aa9707099c4b25700940eb3d016f16c4434360d
> ("lockdep: check that no locks held at freeze time"), due to limitations
> in my local testbed.
>
> Signed-off-by: Paul Walmsley <paul at pwsan.com>
> Cc: Alexey Pelykh <alexey.pelykh at gmail.com>
> Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
> ---
>
> Alexey, care to make another attempt for 3.11 at fixing the issue you were
> originally debugging, but one that also works on OMAP37xx EVM?  It would
> be good to cc the <linux-omap at vger.kernel.org> on your OMAP work.  If you
> don't have a 37xx EVM, someone there might be able to help you test.
>
>  drivers/tty/serial/omap-serial.c |    8 ++++++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
> index 4dc4140..9915e4d 100644
> --- a/drivers/tty/serial/omap-serial.c
> +++ b/drivers/tty/serial/omap-serial.c
> @@ -59,7 +59,6 @@
>
>  /* SCR register bitmasks */
>  #define OMAP_UART_SCR_RX_TRIG_GRANU1_MASK              (1 << 7)
> -#define OMAP_UART_SCR_TX_TRIG_GRANU1_MASK              (1 << 6)
>  #define OMAP_UART_SCR_TX_EMPTY                 (1 << 3)
>
>  /* FCR register bitmasks */
> @@ -321,6 +320,9 @@ static void transmit_chars(struct uart_omap_port *up, unsigned int lsr)
>         struct circ_buf *xmit = &up->port.state->xmit;
>         int count;
>
> +       if (!(lsr & UART_LSR_THRE))
> +               return;
> +
>         if (up->port.x_char) {
>                 serial_out(up, UART_TX, up->port.x_char);
>                 up->port.icount.tx++;
> @@ -862,7 +864,7 @@ serial_omap_set_termios(struct uart_port *port, struct ktermios *termios,
>         serial_out(up, UART_IER, up->ier);
>         serial_out(up, UART_LCR, cval);         /* reset DLAB */
>         up->lcr = cval;
> -       up->scr = 0;
> +       up->scr = OMAP_UART_SCR_TX_EMPTY;
>
>         /* FIFOs and DMA Settings */
>
> @@ -886,6 +888,8 @@ serial_omap_set_termios(struct uart_port *port, struct ktermios *termios,
>         serial_out(up, UART_MCR, up->mcr | UART_MCR_TCRTLR);
>         /* FIFO ENABLE, DMA MODE */
>
> +       up->scr |= OMAP_UART_SCR_RX_TRIG_GRANU1_MASK;
> +
>         /* Set receive FIFO threshold to 16 characters and
>          * transmit FIFO threshold to 16 spaces
>          */
> --
> 1.7.10.4
>


From santosh.shilimkar at ti.com  Mon Apr  1 04:33:41 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Mon, 1 Apr 2013 14:03:41 +0530
Subject: [PATCH] RX-51: ARM errata 430973 workaround
In-Reply-To: <1364738063-23868-1-git-send-email-pali.rohar@gmail.com>
References: <20130328155803.GT10155@atomide.com>
 <1364738063-23868-1-git-send-email-pali.rohar@gmail.com>
Message-ID: <51594665.1090903@ti.com>

On Sunday 31 March 2013 07:24 PM, Pali Roh?r wrote:
> Closed and signed Nokia X-Loader bootloader stored in RX-51 nand does not set
> IBE bit in ACTLR and starting kernel in non-secure mode. So direct write to
> ACTLR by our kernel does not working and the code for ARM errata 430973 in
> commit 7ce236fcd6fd45b0441a2d49acb2ceb2de2e8a47 that sets IBE bit is a noop.
> 
> In order to have workaround for ARM errata 430973 from non-secure world on
> RX-51 we needs Secure Monitor Call to set IBE BIT in ACTLR.
> 
> This patch adds RX-51 specific SMC support and sets IBE bit in ACTLR during
> board init code for ARM errata 430973 workaround.
> 
> Because all the setup and what arguments are required for SMC are completely
> different from SoC to SoC it is not possible to create generic SMC handling.
> Code in omap-smc.S looks identical but it is not. So RX-51 needs another code.
> 
> ARM errata 430973 workaround is needed for thumb-2 ISA compiled userspace
> binaries. Without this workaround thumb-2 binaries crashing. So with this
> patch it is possible to recompile and run applications/binaries with thumb-2
> ISA on RX-51.
> 
> Signed-off-by: Ivaylo Dimitrov <freemangordon at abv.bg>
> Signed-off-by: Pali Roh?r <pali.rohar at gmail.com>
> ---
>  arch/arm/mach-omap2/Makefile            |    1 +
>  arch/arm/mach-omap2/board-rx51-secure.c |   66 +++++++++++++++++++++++++++++++
>  arch/arm/mach-omap2/board-rx51-secure.h |   36 +++++++++++++++++
>  arch/arm/mach-omap2/board-rx51-smc.S    |   34 ++++++++++++++++
>  arch/arm/mach-omap2/board-rx51.c        |    7 ++++
>  5 files changed, 144 insertions(+)
>  create mode 100644 arch/arm/mach-omap2/board-rx51-secure.c
>  create mode 100644 arch/arm/mach-omap2/board-rx51-secure.h
>  create mode 100644 arch/arm/mach-omap2/board-rx51-smc.S
> 
> diff --git a/arch/arm/mach-omap2/board-rx51-smc.S b/arch/arm/mach-omap2/board-rx51-smc.S
> new file mode 100644
> index 0000000..70e2eb7
> --- /dev/null
> +++ b/arch/arm/mach-omap2/board-rx51-smc.S
> @@ -0,0 +1,34 @@
You can avoid creating board-rx51-smc.S by having rx51_ppa_smc()
part of board-rx51-secure.c using inline asm. You can avoid the
board-rx51-secure.h as well considering the usage is limited to
the rx51 board.

Regards,
Santosh


From benh at kernel.crashing.org  Mon Apr  1 04:29:48 2013
From: benh at kernel.crashing.org (Benjamin Herrenschmidt)
Date: Mon, 01 Apr 2013 10:29:48 +0200
Subject: How to facilitate the cpuidle drivers to go to the same
 direction (Was: Re: [PATCH 4/9] ARM: OMAP4: cpuidle: fix wrong driver
 initialization)
In-Reply-To: <515923C7.8040408@linux.vnet.ibm.com>
References: <1364553095-25110-1-git-send-email-daniel.lezcano@linaro.org>
 <1364553095-25110-4-git-send-email-daniel.lezcano@linaro.org>
 <51556F1D.5030208@ti.com> <515570DF.5010608@linaro.org>
 <CAP245DX+mYQhhJ-fU6PQdV6V-1P7PGUaOoNo+QdhRFaQR=wiEQ@mail.gmail.com>
 <51558723.1050904@ti.com>
 <CAP245DWAAgQ4co34mdkFgepC5kP9v0n6B954ej2X_y20LE9kSQ@mail.gmail.com>
 <5155AEE7.106@ti.com> <5155B85F.6030808@linaro.org>
 <515923C7.8040408@linux.vnet.ibm.com>
Message-ID: <1364804988.32247.3.camel@pasglop>

On Mon, 2013-04-01 at 11:35 +0530, Deepthi Dharwar wrote:
> But then, this means we get all the
> arch specific code out under drivers/cpuidle
> which can be very messy.

Not really no. We already have that here or there in other drivers,
it's not necessarily messy and the stuff like that can generally be made
reasonably self contained.

The main issue is that if I (powerpc) wants a fix in my
some_ppc_box_idle.c driver, especially if it needs to sync with other
arch changes, having to sync/ack with Rafael might complicate things a
bit (though not necessarily a lot).

I would probably keep the liberty of sending to Linus directly urgent
bug/regression fixes to individual cpuidle drivers relating to our archs
without waiting every now and then if for example Rafael is on
vacation :-)

>  Also instances where the changes
> are specifically tied only to the  architecture of the back-end driver
> (SoC specific), it is absolutely necessary to get SoC maintainer's
> review.

Ben.




From rnayak at ti.com  Mon Apr  1 04:39:47 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Mon, 1 Apr 2013 14:09:47 +0530
Subject: [PATCH 2/8] ARM: OMAP2+: hwmod: Cleanup sidle/mstandby programming
In-Reply-To: <alpine.DEB.2.00.1303310053351.6436@utopia.booyaka.com>
References: <1361354272-18089-1-git-send-email-santosh.shilimkar@ti.com>
 <1361354272-18089-3-git-send-email-santosh.shilimkar@ti.com>
 <alpine.DEB.2.00.1303310053351.6436@utopia.booyaka.com>
Message-ID: <515947D3.50904@ti.com>

Paul,

>> _enable_wakeup() and _disable_wakeup() are expected to program the
>> OCP_SYSCONFIG.ENAWAKEUP bit.
> 
> These functions were originally intended to take care of everything needed 
> for the IP block to wake up the chip, including the PRCM WKEN programming.  
> ENAWAKEUP is simply one part of that.
> 
>> Get rid of the additional sidle/mstandby programming in them, as its 
>> confusing (this is expected to be handled elsewhere as part of 
>> _enable_sysc()/__idle_sysc())
> 
> Sorry, why does the expectation exist for the code to enable and disable 
> device wakeup to be part of _enable_sysc()/_idle_sysc(), rather than in 
> functions called by _enable_sysc()/_idle_sysc()?

It all comes down to if SIDLE_SMART_WKUP/MSTANDBY_SMART_WKUP programming
be considered as 'idlemode' programming or 'enwakeup' programming.
If you consider these are being part of 'enwakeup' progrmming, these should
certainly be handled as part of _enable_wakeup() and _disable_wakeup().

Today, in some cases, these are *also* handled as part of _enable_sysc()
and _idle_sysc(). The way _enable_wakeup() is invoked from _enable_sysc()
is also very inconsistent. For instance, for any IP which supports
SYSC_HAS_MIDLEMODE and SYSC_HAS_ENAWAKEUP, we invoke _enable_wakeup()
regardless of the MIDLEMODE programmmed.
While in case of the IP supporting SYSC_HAS_SIDLEMODE, _enable_wakeup() is
invoked only when the SIDLEMODE programmed is SMART or SMART_WKUP.

I understand the cleanups you are suggesting below as part of the movement
of some of these things outside of mach-omap2.
I was more looking at fixing the existing piece so its readable and does
things more consistently.

regards,
Rajendra

> 
>> and unnecessary.
> 
> So here's part of the reason why the module wakeup control functions 
> should remain separate.  When the kernel boots, all the PM features should 
> be disabled.  Then mach-omap2/pm*.c should enables PM features where 
> they're needed.
> 
> Right now, mach-omap2/pm34xx.c sets module WKEN bits.  (These direct 
> register accesses need to be moved as part of the cleanup work, of moving 
> the PM/PRM/CM code into drivers.)  But the list of IP blocks that 
> should be allowed to wake the system is board-dependent.
> 
> So really, what mach-omap2/pm34xx.c should do is to call into the hwmod 
> enable-wakeups code to enable MPU wakeups for all the IP blocks that have 
> some DT property set, something like 'enable-wakeups'.  Then the hwmod 
> code should ensure that the PRM wakeup-enable and GRPSEL bits are 
> programmed (by calling into the PRM driver code) and should then either 
> set the ENAWAKEUP bits or put the module into smart_wkup MSTANDBY/MIDLE.
> 
> Similarly, when the PM driver is unloaded, it should set no-idle on all 
> the IP blocks that were marked as wakeup-capable and disable the PRCM 
> wakeup control bits, by calling some hwmod disable-wakeups code.
> 
>> Well, the _enable_sysc()/_idle_sysc() handled only the mstandby modes
>> correctly. So fix them so they also handle the midle modes correctly
> 
> If there's a fix here, please split that out into a separate patch.
> 
> 
> - Paul
> 



From paul at pwsan.com  Mon Apr  1 05:13:04 2013
From: paul at pwsan.com (Paul Walmsley)
Date: Mon, 1 Apr 2013 09:13:04 +0000 (UTC)
Subject: [PATCH] Revert "OMAP/serial: Fix incorrect Rx FIFO threshold
 setting, LSR validation on Tx, and Tx FIFO IRQ generation"
In-Reply-To: <CAOmKuSpttQJmrL=Htiz-Zc4voAF7CnG_GQYAO2onKpauwYjtvw@mail.gmail.com>
References: <alpine.DEB.2.00.1304010519260.28273@utopia.booyaka.com>
 <CAOmKuSpttQJmrL=Htiz-Zc4voAF7CnG_GQYAO2onKpauwYjtvw@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1304010844100.28273@utopia.booyaka.com>

Hi

On Mon, 1 Apr 2013, Alexey Pelykh wrote:

> Actually, I've tested my patch on DM3730,

What board, bootloader, and test steps did you use?  Can you post a dmesg?

> and, at least, can prove that original settings of UART are incorrect 
> according to TRM of processor. 

The TRM could be buggy or wrong; or your patch could be correct as far as 
the UART goes, but could be triggering a separate bug.  We're reaching the 
end of the v3.9-rc fixes period, so we need to deal with the v3.9-rc 
regression quickly so folks don't wind up with a broken v3.9 kernel.  
Then the issue can be debugged and tested, and the revised fix targeted 
for the v3.11 kernel.

> What settings of UART you were using to reproduce issue? I'd like to 
> kindly ask you to describe your test environment, since I've never 
> experiences issues that you've described nor in debug console, nor in 
> regular UART usage.

Could you be more specific about what information you're looking for, 
beyond what's in:

http://www.pwsan.com/omap/testlogs/test_v3.9-rc5/20130331205513/pm/37xxevm/37xxevm_log.txt 

?  As you can see from the log, it's using UART1 at 115kbps -- init=/bin/sh, 
so no userspace to speak of.

It's also worth mentioning that the 3730 Beagle XM here doesn't fail the 
PM test, UART3 at 230kbps in a "full" userspace:

http://www.pwsan.com/omap/testlogs/test_v3.9-rc5/20130331205513/pm/3730beaglexm/3730beaglexm_log.txt


- Paul


From magnus.damm at gmail.com  Mon Apr  1 05:15:38 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Mon, 1 Apr 2013 18:15:38 +0900
Subject: [GIT PULL v2] Renesas ARM-based SoC board updates for v3.10
In-Reply-To: <201303271137.45652.arnd@arndb.de>
References: <1363659481-5922-1-git-send-email-horms+renesas@verge.net.au>
 <201303221539.39742.arnd@arndb.de>
 <CANqRtoT2gi4vObPwkRNkXkuCLWy0=otRqXedk32Wdgp+WS4vRg@mail.gmail.com>
 <201303271137.45652.arnd@arndb.de>
Message-ID: <CANqRtoSBUt+G-GwBZ01FmOwgm3vp0_GYXBckOdEp-46A6G_LnA@mail.gmail.com>

On Wed, Mar 27, 2013 at 8:37 PM, Arnd Bergmann <arnd at arndb.de> wrote:
>
> On Wednesday 27 March 2013, Magnus Damm wrote:
> > On Sat, Mar 23, 2013 at 12:39 AM, Arnd Bergmann <arnd at arndb.de> wrote:
> > > On Friday 22 March 2013, Simon Horman wrote:
> > > I expect that in 3.10, we will have all ARMv6 and ARMv7 platforms converted,
> > > with the exception of realview, mmp, s5p, msm, and shmobile. I'm sure we
> > > can do realview and mmp for 3.11, possibly also s5p. For shmobile, I think
> > > most of the work would be changing drivers/sh/clk to integrate into the common
> > > clk framework, and you need to find a way to enable ARM_PATCH_PHYS_VIRT and
> > > AUTO_ZRELADDR. Are those things you think can be done for 3.11?
> >
> > Good to hear that most ARM platforms will be converted by v3.10. This
> > is definitely something that I want to make happen for mach-shmobile
> > as well.
> >
> > Our biggest challenge now is the move to common clocks. I suspect that
> > moving all our boards and SoCs to common clocks will take much longer
> > than v3.11 I'm afraid.
>
> Ok, I see. If you think it's not likely to be ready for 3.12, we might
> need to discuss again whether there is another way of making the
> common clk and the sh-clk code coexist. For instance, we could rename
> all if the sh/shmobile specific clk functions and their users from
> clk_* to shclk_*, and provide a thin wrapper around them that integrates
> into common clk.

Yeah, I am not sure if it is likely that we will be able to convert
all platforms at v3.12 timing.

I actually tried to let common clocks and sh-clk coexist when the
common clock framework was under heavy development. I recall it being
far from trivial.

One possible way to develop this could be to force the mach-shmobile
"reference DT" implementations use common clocks and keep the old
boards as-is. Then we can also make sure the "reference DT"
implementations can be used as CONFIG_ARCH_MULTIPLATFORM. So if we
only have "reference DT" code as MULTIPLATFORM and then finally kill
off the old board code one by one.

> > Starting with something smaller like EMEV2 may be a good first step.
> > So somehow I'd like to start converting them one by one, perhaps also
> > moving over the converted SoCs/boards to CONFIG_ARCH_MULTIPLATFORM in
> > an incremental fashion. Do you happen to have any example subarch that
> > has been migrated in an increment fashion already?
>
> We have had a few that were able to do both multiplatform and
> single-platform for some time, but then changed to multiplatform-only.
> I think mvebu and vt8500 are in this category.

Thanks.

> > Regarding ARM_PATCH_PHYS_VIRT and AUTO_ZRELADDR, I believe those
> > should be enabled for the mach-shmobile bits that are used with
> > CONFIG_ARCH_MULTIPLATFORM. Best way forward there is TBD, any
> > recommendations would be very welcome!
>
> Yes, makes sense.
>
> What I think you should do is rename CONFIG_ARCH_SHMOBILE to
> CONFIG_ARCH_SHMOBILE_SINGLE, and add a new symbol in
> arch/arm/mach-shmobile/Kconfig like
>
> config ARCH_SHMOBILE
>         bool "Renesas SH-Mobile / R-Mobile" if ARCH_MULTI_V6_V7
>         default CONFIG_ARCH_SHMOBILE_SINGLE
>         help
>           Support for Renesas's SH-Mobile and R-Mobile ARM platforms.
>
> This way, the platform is a non-exclusive option for the multiplatform
> case, and a hidden enabled option when building CONFIG_ARCH_SHMOBILE_SINGLE.
> Every machine that is not ready for multiplatform can then add "depends on
> CONFIG_ARCH_SHMOBILE_SINGLE".

I see, that makes sense. Thanks.

Since we're on the topic of CONFIG_ARCH_MULTIPLATFORM, do you have any
recommendatoin about LPAE?

Judging by the ARM_LPAE help text it seems that selecting ARM_LPAE
will result in a kernel only working on LPAE hardware:

config ARM_LPAE
[snip]
          Say Y if you have an ARMv7 processor supporting the LPAE page
          table format and you would like to access memory beyond the
          4GB limit. The resulting kernel image will not run on
          processors without the LPA extension.

With the above text it sounds to me like we should not to a "select
ARM_LPAE" on each board in the case of CONFIG_ARCH_MULTIPLATFORM.

I sort of expect LPAE to behave similar to x86 PAE. At least the board
DT file should describe all physical memory available and depending on
kernel configuration (HIGHMEM=y/n, LPAE=y/n) we get different amounts
of usable memory in the kernel. Then if LPAE should be selected or not
is something that the distributions have to decide.

Thanks!

/ magnus


From alexey.pelykh at gmail.com  Mon Apr  1 06:01:44 2013
From: alexey.pelykh at gmail.com (Alexey Pelykh)
Date: Mon, 1 Apr 2013 13:01:44 +0300
Subject: [PATCH] Revert "OMAP/serial: Fix incorrect Rx FIFO threshold
 setting, LSR validation on Tx, and Tx FIFO IRQ generation"
In-Reply-To: <alpine.DEB.2.00.1304010844100.28273@utopia.booyaka.com>
References: <alpine.DEB.2.00.1304010519260.28273@utopia.booyaka.com>
 <CAOmKuSpttQJmrL=Htiz-Zc4voAF7CnG_GQYAO2onKpauwYjtvw@mail.gmail.com>
 <alpine.DEB.2.00.1304010844100.28273@utopia.booyaka.com>
Message-ID: <CAOmKuSrABrPcZ=Yg1+LAHWbh9CdTYR0eUmJ2dd3z91oz0uu21g@mail.gmail.com>

Hi,

On Mon, Apr 1, 2013 at 12:13 PM, Paul Walmsley <paul at pwsan.com> wrote:
> Hi
>
> On Mon, 1 Apr 2013, Alexey Pelykh wrote:
>
>> Actually, I've tested my patch on DM3730,
>
> What board, bootloader, and test steps did you use?  Can you post a dmesg?

I've used LogicPD Torpedo Wireless SoM + DevKit board. Bootloader is
stock from their BSP, u-boot 2011.06 + patches from LogicPD.
I can provide dmesg of 3.8(inital kernel this patch was intented for)
a bit later during the day, and a bit more later same patch rebased
onto latest sources.
Also, I should mention that LogicPD does not support 3.8, so most
LogicPD-specific devices are not working.

And I'd like to point out that after patch gaps I've seen are not gone
completely, ~1 packet out of 200 at 1mbaud is still corrupted, but
only when PM is enabled in kernel,
what gives me a clue that it must be something in PM also. Maybe my
patch just reveals PM-specific issue. Have you tried without PM to
reproduce issues you're experiencing?

>
>> and, at least, can prove that original settings of UART are incorrect
>> according to TRM of processor.
>
> The TRM could be buggy or wrong; or your patch could be correct as far as
> the UART goes, but could be triggering a separate bug.  We're reaching the
> end of the v3.9-rc fixes period, so we need to deal with the v3.9-rc
> regression quickly so folks don't wind up with a broken v3.9 kernel.
> Then the issue can be debugged and tested, and the revised fix targeted
> for the v3.11 kernel.

Indeed, TRMs appear to contain wrong information, but I believe that
in this particular case, bug is somewhere around, but not in these
lines.
I believe if you take a look on related TRM pages, it seems quite
logical that configuration of SCR (before my patch) is not quite
proper:
 - trigger interrupt only when it's entirely empty, not when threshold
level is reached, what is incorrect, in my opinion.
 - (less influencing) Granularity of counter indicates opposite to
what is stated in comments

These issues may have never been experienced by others, since
originally I've hit them on 1mbaud speed, what is not supported by
original driver at all.

>
>> What settings of UART you were using to reproduce issue? I'd like to
>> kindly ask you to describe your test environment, since I've never
>> experiences issues that you've described nor in debug console, nor in
>> regular UART usage.
>
> Could you be more specific about what information you're looking for,
> beyond what's in:
>
> http://www.pwsan.com/omap/testlogs/test_v3.9-rc5/20130331205513/pm/37xxevm/37xxevm_log.txt
>
> ?  As you can see from the log, it's using UART1 at 115kbps -- init=/bin/sh,
> so no userspace to speak of.
>

Sorry, I've missed that file at all. After patch I've never expericed
any issues on 115200 speed of debug console, and it works flawlessly
for me.

> It's also worth mentioning that the 3730 Beagle XM here doesn't fail the
> PM test, UART3 at 230kbps in a "full" userspace:
>
> http://www.pwsan.com/omap/testlogs/test_v3.9-rc5/20130331205513/pm/3730beaglexm/3730beaglexm_log.txt
>
>
> - Paul


From paul at pwsan.com  Mon Apr  1 06:19:04 2013
From: paul at pwsan.com (Paul Walmsley)
Date: Mon, 1 Apr 2013 10:19:04 +0000 (UTC)
Subject: [PATCH] Revert "OMAP/serial: Fix incorrect Rx FIFO threshold
 setting, LSR validation on Tx, and Tx FIFO IRQ generation"
In-Reply-To: <CAOmKuSrABrPcZ=Yg1+LAHWbh9CdTYR0eUmJ2dd3z91oz0uu21g@mail.gmail.com>
References: <alpine.DEB.2.00.1304010519260.28273@utopia.booyaka.com>
 <CAOmKuSpttQJmrL=Htiz-Zc4voAF7CnG_GQYAO2onKpauwYjtvw@mail.gmail.com>
 <alpine.DEB.2.00.1304010844100.28273@utopia.booyaka.com>
 <CAOmKuSrABrPcZ=Yg1+LAHWbh9CdTYR0eUmJ2dd3z91oz0uu21g@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1304011008230.28273@utopia.booyaka.com>

cc Kevin, Felipe

Hi

On Mon, 1 Apr 2013, Alexey Pelykh wrote:

> On Mon, Apr 1, 2013 at 12:13 PM, Paul Walmsley <paul at pwsan.com> wrote:
> > On Mon, 1 Apr 2013, Alexey Pelykh wrote:
> >
> >> Actually, I've tested my patch on DM3730,
> >
> > What board, bootloader, and test steps did you use?  Can you post a dmesg?
> 
> I've used LogicPD Torpedo Wireless SoM + DevKit board. Bootloader is
> stock from their BSP, u-boot 2011.06 + patches from LogicPD.
> I can provide dmesg of 3.8(inital kernel this patch was intented for)
> a bit later during the day, and a bit more later same patch rebased
> onto latest sources.
> Also, I should mention that LogicPD does not support 3.8, so most
> LogicPD-specific devices are not working.

A dmesg from v3.9-rc5 would be ideal, but sounds like it's a non-mainline 
kernel?

Are you using a serial console on that board, and if so, what UART is it 
on?

> And I'd like to point out that after patch gaps I've seen are not gone
> completely, ~1 packet out of 200 at 1mbaud is still corrupted, but
> only when PM is enabled in kernel,

Are you seeing corruption caused by the OMAP UART's receive path, or by 
the transmit path?

When you say "only when PM is enabled" do you mean by enabling CONFIG_PM, 
or do you mean after setting an autosuspend timeout on the serial drivers, 
or something else?

> what gives me a clue that it must be something in PM also. Maybe my
> patch just reveals PM-specific issue. Have you tried without PM to
> reproduce issues you're experiencing?

So I'm using omap2plus_defconfig, which has CONFIG_PM=y, but the issues 
appear before serial autosuspend is enabled.

> Indeed, TRMs appear to contain wrong information, but I believe that
> in this particular case, bug is somewhere around, but not in these
> lines.
> I believe if you take a look on related TRM pages, it seems quite
> logical that configuration of SCR (before my patch) is not quite
> proper:
>  - trigger interrupt only when it's entirely empty, not when threshold
> level is reached, what is incorrect, in my opinion.
>  - (less influencing) Granularity of counter indicates opposite to
> what is stated in comments
> 
> These issues may have never been experienced by others, since
> originally I've hit them on 1mbaud speed, what is not supported by
> original driver at all.

It wouldn't surprise me at all if something is wrong with the 
original driver's FIFO setup.  The challenge at this point is to keep 
the driver working while trying to fix what's wrong with it.


- Paul


From paul at pwsan.com  Mon Apr  1 06:25:29 2013
From: paul at pwsan.com (Paul Walmsley)
Date: Mon, 1 Apr 2013 10:25:29 +0000 (UTC)
Subject: [PATCH] ARM:OMAP2: an issue about curr_pwrst, u8 is never < 0
In-Reply-To: <51415048.6000607@asianux.com>
References: <51415048.6000607@asianux.com>
Message-ID: <alpine.DEB.2.00.1304011024090.28273@utopia.booyaka.com>

Hi,

On Thu, 14 Mar 2013, Chen Gang wrote:

> 
>   if pwrdm_read_pwrst returns negative number, curr_pwrst can not notice it.
>   since really need check curr_pwrst whether is negative,
>     need let the check valid in _pwrdm_save_clkdm_state_and_activate.
>     and also better to check the return value of pwrdm_read_pwrst, firstly.
> 
> Signed-off-by: Chen Gang <gang.chen at asianux.com>

thanks for reporting this and sending a suggested fix.  The following 
patch is what I've queued here, which should deal with the root cause 
without the casts.


- Paul

From: Paul Walmsley <paul at pwsan.com>
Date: Sun, 31 Mar 2013 20:22:22 -0600
Subject: [PATCH] ARM: OMAP2+: powerdomain: avoid testing whether an unsigned
 char is less than 0

_pwrdm_save_clkdm_state_and_activate() tried to test one of its
unsigned arguments to determine whether it was less than zero.  Fix by
moving the error test to the caller.

Reported-by: Chen Gang <gang.chen at asianux.com>
Signed-off-by: Paul Walmsley <paul at pwsan.com>
---
 arch/arm/mach-omap2/powerdomain.c |   18 ++++++++----------
 1 file changed, 8 insertions(+), 10 deletions(-)

diff --git a/arch/arm/mach-omap2/powerdomain.c b/arch/arm/mach-omap2/powerdomain.c
index 8e61d80..89cad4a 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -52,7 +52,6 @@ enum {
 #define ALREADYACTIVE_SWITCH		0
 #define FORCEWAKEUP_SWITCH		1
 #define LOWPOWERSTATE_SWITCH		2
-#define ERROR_SWITCH			3
 
 /* pwrdm_list contains all registered struct powerdomains */
 static LIST_HEAD(pwrdm_list);
@@ -233,10 +232,7 @@ static u8 _pwrdm_save_clkdm_state_and_activate(struct powerdomain *pwrdm,
 {
 	u8 sleep_switch;
 
-	if (curr_pwrst < 0) {
-		WARN_ON(1);
-		sleep_switch = ERROR_SWITCH;
-	} else if (curr_pwrst < PWRDM_POWER_ON) {
+	if (curr_pwrst < PWRDM_POWER_ON) {
 		if (curr_pwrst > pwrst &&
 		    pwrdm->flags & PWRDM_HAS_LOWPOWERSTATECHANGE &&
 		    arch_pwrdm->pwrdm_set_lowpwrstchange) {
@@ -1091,7 +1087,8 @@ int pwrdm_post_transition(struct powerdomain *pwrdm)
  */
 int omap_set_pwrdm_state(struct powerdomain *pwrdm, u8 pwrst)
 {
-	u8 curr_pwrst, next_pwrst, sleep_switch;
+	u8 next_pwrst, sleep_switch;
+	int curr_pwrst;
 	int ret = 0;
 	bool hwsup = false;
 
@@ -1107,16 +1104,17 @@ int omap_set_pwrdm_state(struct powerdomain *pwrdm, u8 pwrst)
 	pwrdm_lock(pwrdm);
 
 	curr_pwrst = pwrdm_read_pwrst(pwrdm);
+	if (curr_pwrst < 0) {
+		ret = -EINVAL;
+		goto osps_out;
+	}
+
 	next_pwrst = pwrdm_read_next_pwrst(pwrdm);
 	if (curr_pwrst == pwrst && next_pwrst == pwrst)
 		goto osps_out;
 
 	sleep_switch = _pwrdm_save_clkdm_state_and_activate(pwrdm, curr_pwrst,
 							    pwrst, &hwsup);
-	if (sleep_switch == ERROR_SWITCH) {
-		ret = -EINVAL;
-		goto osps_out;
-	}
 
 	ret = pwrdm_set_next_pwrst(pwrdm, pwrst);
 	if (ret)
-- 
1.7.10.4



From paul at pwsan.com  Mon Apr  1 06:27:51 2013
From: paul at pwsan.com (Paul Walmsley)
Date: Mon, 1 Apr 2013 10:27:51 +0000 (UTC)
Subject: [PATCH] ARM: OMAP: dpll: enable bypass clock only when attempting
 dpll bypass
In-Reply-To: <1364468381-10560-1-git-send-email-rnayak@ti.com>
References: <1364468381-10560-1-git-send-email-rnayak@ti.com>
Message-ID: <alpine.DEB.2.00.1304010211430.28273@utopia.booyaka.com>

On Thu, 28 Mar 2013, Rajendra Nayak wrote:

> omap3_noncore_dpll_set_rate() attempts an enable of bypass clk as well
> as ref clk for every .set_rate attempt on a noncore DPLL, regardless of
> whether the .set_rate results in the DPLL being locked or put in bypass.
> Early at boot, while some of these DPLLs are programmed and locked
> (using .set_rate for the DPLL), this causes an ordering issue.
> 
> For instance, on OMAP5, the USB DPLL derives its bypass clk from ABE DPLL.
> If a .set_rate of USB DPLL which programmes the M,N and locks it is called
> before the one for ABE, the enable of USB bypass clk (derived from ABE DPLL)
> then attempts to lock the ABE DPLL and fails as the M,N values for ABE
> are yet to be programmed.
> 
> To get rid of this ordering needs, enable bypass clk for a DPLL as part
> of its .set_rate only when its being put in bypass, and only enable the
> ref clk when its locked.
> 
> Reported-by: Roger Quadros <rogerq at ti.com>
> Signed-off-by: Rajendra Nayak <rnayak at ti.com>

Thanks, queued for 3.10.  


- Paul


From hvaibhav at ti.com  Mon Apr  1 06:30:13 2013
From: hvaibhav at ti.com (Hiremath, Vaibhav)
Date: Mon, 1 Apr 2013 10:30:13 +0000
Subject: Query regarding clk framework - from .set_rate api
Message-ID: <79CD15C6BA57404B839C016229A409A83EC3E7C3@DBDE01.ent.ti.com>

Hi Rajendra/Paul/Mike,

I am debugging the issue reported by Michal on AM33xx clock tree
In the context of LCDC driver functionality-

http://www.mail-archive.com/dri-devel at lists.freedesktop.org/msg36102.html

Where, the clk_set_rate() seems to be not working, and that's true
with the current implementation of OMAP/AM33xx clock tree,
as the CLK_SET_RATE_PARENT flag is not set to any of the clock nodes.

Please note that I am using DEFINE_STRUCT_CLK() macro for defining clocks
And which doesn't allow you to specify the flags.

Below is the propagation scenario under discussion:

DISP_DPLL (dpll_disp_ck) ->>
     dpll_disp_m2_ck ->>
           lcd_clk_mux_sel ->>
                 lcd_gclk


Just to make sure that propagation works fine, I hacked the code and 
tested it on AM335x BeagleBone platform without any issues.

Can I create a patch modifying DEFINE_STRUCT_CLK() macro to take
Another argument '.flags" and change all clock-trees accrordingly??

Diff Starts here:
=====================

diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.c
index 7baede1..51fc78b 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -11,6 +11,7 @@
  * it under the terms of the GNU General Public License version 2 as
  * published by the Free Software Foundation.
  */
+#include <linux/clk-private.h>
 #include <linux/io.h>
 #include <linux/of_irq.h>
 #include <linux/of_platform.h>
@@ -100,6 +101,7 @@ exit:
 static void __init omap_generic_init(void)
 {
        struct device_node *np;
+       struct clk *clk;

        omap_sdrc_init(NULL, NULL);

@@ -115,6 +117,15 @@ static void __init omap_generic_init(void)

        if (of_machine_is_compatible("ti,omap5"))
                omap_sata_init();
+
+       clk = clk_get(NULL, "lcd_gclk");
+       if (IS_ERR(clk))
+               printk("Can not get lcd_gclk clock\n");
+
+       printk("%s:%d gclk_rate - %lu\n", __func__, __LINE__, clk_get_rate(clk));
+       clk_set_rate(clk, 300000000);
+       printk("%s:%d clk_rate - %lu\n", __func__, __LINE__, clk_get_rate(clk));
+       clk_put(clk);
 }

 #ifdef CONFIG_SOC_OMAP2420
diff --git a/arch/arm/mach-omap2/cclock33xx_data.c b/arch/arm/mach-omap2/cclock33xx_data.c
index e674e01..d4552db 100644
--- a/arch/arm/mach-omap2/cclock33xx_data.c
+++ b/arch/arm/mach-omap2/cclock33xx_data.c
@@ -284,7 +284,7 @@ DEFINE_STRUCT_CLK(dpll_disp_ck, dpll_core_ck_parents, dpll_ddr_ck_ops);
  * TODO: Add clksel here (sys_clkin, CORE_CLKOUTM6, PER_CLKOUTM2
  * and ALT_CLK1/2)
  */
-DEFINE_CLK_DIVIDER(dpll_disp_m2_ck, "dpll_disp_ck", &dpll_disp_ck, 0x0,
+DEFINE_CLK_DIVIDER(dpll_disp_m2_ck, "dpll_disp_ck", &dpll_disp_ck, CLK_SET_RATE_PARENT,
                   AM33XX_CM_DIV_M2_DPLL_DISP, AM33XX_DPLL_CLKOUT_DIV_SHIFT,
                   AM33XX_DPLL_CLKOUT_DIV_WIDTH, CLK_DIVIDER_ONE_BASED, NULL);

diff --git a/arch/arm/mach-omap2/clock.h b/arch/arm/mach-omap2/clock.h
index 836311f..3830e5b 100644
--- a/arch/arm/mach-omap2/clock.h
+++ b/arch/arm/mach-omap2/clock.h
@@ -64,6 +64,7 @@ struct clockdomain;
                .parent_names = _parent_array_name,             \
                .num_parents = ARRAY_SIZE(_parent_array_name),  \
                .ops = &_clkops_name,                           \
+               .flags = CLK_SET_RATE_PARENT,                   \
        };

 #define DEFINE_STRUCT_CLK_HW_OMAP(_name, _clkdm_name)          \


Thanks,
Vaibhav



From gang.chen at asianux.com  Mon Apr  1 06:41:11 2013
From: gang.chen at asianux.com (Chen Gang)
Date: Mon, 01 Apr 2013 18:41:11 +0800
Subject: [PATCH] ARM:OMAP2: an issue about curr_pwrst, u8 is never < 0
In-Reply-To: <alpine.DEB.2.00.1304011024090.28273@utopia.booyaka.com>
References: <51415048.6000607@asianux.com>
 <alpine.DEB.2.00.1304011024090.28273@utopia.booyaka.com>
Message-ID: <51596447.9070000@asianux.com>

On 2013?04?01? 18:25, Paul Walmsley wrote:
> Hi,
> 
> On Thu, 14 Mar 2013, Chen Gang wrote:
> 
>>
>>   if pwrdm_read_pwrst returns negative number, curr_pwrst can not notice it.
>>   since really need check curr_pwrst whether is negative,
>>     need let the check valid in _pwrdm_save_clkdm_state_and_activate.
>>     and also better to check the return value of pwrdm_read_pwrst, firstly.
>>
>> Signed-off-by: Chen Gang <gang.chen at asianux.com>
> 
> thanks for reporting this and sending a suggested fix.  The following 
> patch is what I've queued here, which should deal with the root cause 
> without the casts.
> 
> 

  yours (patch below) is simpler and clearer than mine.

  thanks.

  :-)


> - Paul
> 
> From: Paul Walmsley <paul at pwsan.com>
> Date: Sun, 31 Mar 2013 20:22:22 -0600
> Subject: [PATCH] ARM: OMAP2+: powerdomain: avoid testing whether an unsigned
>  char is less than 0
> 
> _pwrdm_save_clkdm_state_and_activate() tried to test one of its
> unsigned arguments to determine whether it was less than zero.  Fix by
> moving the error test to the caller.
> 
> Reported-by: Chen Gang <gang.chen at asianux.com>
> Signed-off-by: Paul Walmsley <paul at pwsan.com>
> ---
>  arch/arm/mach-omap2/powerdomain.c |   18 ++++++++----------
>  1 file changed, 8 insertions(+), 10 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/powerdomain.c b/arch/arm/mach-omap2/powerdomain.c
> index 8e61d80..89cad4a 100644
> --- a/arch/arm/mach-omap2/powerdomain.c
> +++ b/arch/arm/mach-omap2/powerdomain.c
> @@ -52,7 +52,6 @@ enum {
>  #define ALREADYACTIVE_SWITCH		0
>  #define FORCEWAKEUP_SWITCH		1
>  #define LOWPOWERSTATE_SWITCH		2
> -#define ERROR_SWITCH			3
>  
>  /* pwrdm_list contains all registered struct powerdomains */
>  static LIST_HEAD(pwrdm_list);
> @@ -233,10 +232,7 @@ static u8 _pwrdm_save_clkdm_state_and_activate(struct powerdomain *pwrdm,
>  {
>  	u8 sleep_switch;
>  
> -	if (curr_pwrst < 0) {
> -		WARN_ON(1);
> -		sleep_switch = ERROR_SWITCH;
> -	} else if (curr_pwrst < PWRDM_POWER_ON) {
> +	if (curr_pwrst < PWRDM_POWER_ON) {
>  		if (curr_pwrst > pwrst &&
>  		    pwrdm->flags & PWRDM_HAS_LOWPOWERSTATECHANGE &&
>  		    arch_pwrdm->pwrdm_set_lowpwrstchange) {
> @@ -1091,7 +1087,8 @@ int pwrdm_post_transition(struct powerdomain *pwrdm)
>   */
>  int omap_set_pwrdm_state(struct powerdomain *pwrdm, u8 pwrst)
>  {
> -	u8 curr_pwrst, next_pwrst, sleep_switch;
> +	u8 next_pwrst, sleep_switch;
> +	int curr_pwrst;
>  	int ret = 0;
>  	bool hwsup = false;
>  
> @@ -1107,16 +1104,17 @@ int omap_set_pwrdm_state(struct powerdomain *pwrdm, u8 pwrst)
>  	pwrdm_lock(pwrdm);
>  
>  	curr_pwrst = pwrdm_read_pwrst(pwrdm);
> +	if (curr_pwrst < 0) {
> +		ret = -EINVAL;
> +		goto osps_out;
> +	}
> +
>  	next_pwrst = pwrdm_read_next_pwrst(pwrdm);
>  	if (curr_pwrst == pwrst && next_pwrst == pwrst)
>  		goto osps_out;
>  
>  	sleep_switch = _pwrdm_save_clkdm_state_and_activate(pwrdm, curr_pwrst,
>  							    pwrst, &hwsup);
> -	if (sleep_switch == ERROR_SWITCH) {
> -		ret = -EINVAL;
> -		goto osps_out;
> -	}
>  
>  	ret = pwrdm_set_next_pwrst(pwrdm, pwrst);
>  	if (ret)
> 


-- 
Chen Gang

Asianux Corporation


From paul at pwsan.com  Mon Apr  1 06:43:44 2013
From: paul at pwsan.com (Paul Walmsley)
Date: Mon, 1 Apr 2013 10:43:44 +0000 (UTC)
Subject: [GIT PULL] ARM: OMAP2+: PRCM fixes for 3.10
Message-ID: <alpine.DEB.2.00.1304011042310.28273@utopia.booyaka.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Tony

The following changes since commit 07961ac7c0ee8b546658717034fe692fd12eefa9:

  Linux 3.9-rc5 (2013-03-31 15:12:43 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git tags/omap-devel-b-for-3.10

for you to fetch changes up to 469d633d20c774ecd34ac615c838193e1e150c62:

  ARM: OMAP: dpll: enable bypass clock only when attempting dpll bypass (2013-03-31 20:43:06 -0600)

- ----------------------------------------------------------------
Some miscellaneous OMAP hwmod, powerdomain, and clock fixes for 3.10.

Basic test logs are here:

http://www.pwsan.com/omap/testlogs/prcm_fixes_a_3.10/20130331205716/

- ----------------------------------------------------------------
vmlinux object size
(delta in bytes from test_v3.9-rc5 (07961ac7c0ee8b546658717034fe692fd12eefa9)):
   text     data      bss    total  kernel
    -36       +8        0      -28  n800_multi_omap2xxx
     -4       +8        0       +4  n800_only_a
      0        0        0        0  omap1_defconfig
      0        0        0        0  omap1_defconfig_1510innovator_only
      0        0        0        0  omap1_defconfig_5912osk_only
    +76      +56        0     +132  omap2plus_defconfig
    +76      +16        0      +92  omap2plus_defconfig_cpupm
    +76      +80        0     +156  omap2plus_defconfig_no_pm
    +60        0        0      +60  omap2plus_defconfig_omap2_4_only
    +80      +80        0     +160  omap2plus_defconfig_omap3_4_only
    +44      +56        0     +100  rmk_omap3430_ldp_allnoconfig
    +48      +16        0      +64  rmk_omap3430_ldp_oldconfig
    +44      +56        0     +100  rmk_omap4430_sdp_allnoconfig
    +16      +16        0      +32  rmk_omap4430_sdp_oldconfig


Paul Walmsley (1):
      ARM: OMAP2+: powerdomain: avoid testing whether an unsigned char is less than 0

Rajendra Nayak (2):
      ARM: OMAP2+: hwmod: Remove unused _HWMOD_WAKEUP_ENABLED flag
      ARM: OMAP: dpll: enable bypass clock only when attempting dpll bypass

Vaibhav Hiremath (2):
      ARM: OMAP2+: AM33xx: hwmod: Add missing sysc definition to wdt1 entry
      ARM: OMAP2+: am335x: Change the wdt1 func clk src to per_32k clk

 arch/arm/mach-omap2/cclock33xx_data.c      |    8 ++++++++
 arch/arm/mach-omap2/dpll3xxx.c             |   19 +++++++++----------
 arch/arm/mach-omap2/omap_hwmod.c           |    4 ----
 arch/arm/mach-omap2/omap_hwmod.h           |    6 ++----
 arch/arm/mach-omap2/omap_hwmod_33xx_data.c |   15 +++++++++++++++
 arch/arm/mach-omap2/powerdomain.c          |   18 ++++++++----------
 6 files changed, 42 insertions(+), 28 deletions(-)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBAgAGBQJRWWSNAAoJEMePsQ0LvSpLMB4P/RzdRMcPLkFBrJaG76uXXmRg
yFHJnaS8nQ5obtpu0yzmgznEhuhU9I4DpmIcqaoiAIFO55jPvsWDK1RkQaJpWzou
8DERbYURBELN33iVpChakTLmCzt9spPYqs2F0Eg9h08CpJWlhsIFj1SqRk57Ze8A
3eY/ayqpDTiRbUKzy/PocpUmbT+kwoXNZFNuguM8WQnbVlFKCC8OTVvm3K9iCGCr
30gF+RKAhbNtOMPpruJodBKkld+8rnUx/lOsvDudCs5ggszw7Kb8x4KyLRwZct1j
zQAp2We4OKluHYZjPUV1ewAQBuD0YbVJM0A7wpDU6avY4Glf849uOhx+3ScCfVR5
E+9HwpBPfDQlVzPIRhick0LaDAmPtj+68n6r+J9FBTUUTONfJDDu9jDAPPt2qn7P
fg8YUiB6tmRInx4lkxfqNuhfHUH96zc+ffQLwNJ1YDFGV460Ltk2j57ienhO/UhX
WDAB8b147rsw/dXcF2YlR6b3UjO5vILbO/eJkEPIMCsUXx7WMX729MNp9q+Hskiv
DpULnXTd3P4T7dj99/rKlhcHQ2rT9fJ2kM7tPss71j87MvihrPecxCnA/4H401p3
YQf1Mt1EpBPPodhOIiOl9TgqslIZno+R0hSDtO1th/ZuZTPrTG/KKeMqau45WYkr
iv4uHjsjFYjgvAhMV43J
=z+VJ
-----END PGP SIGNATURE-----


From rnayak at ti.com  Mon Apr  1 06:44:17 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Mon, 1 Apr 2013 16:14:17 +0530
Subject: Query regarding clk framework - from .set_rate api
In-Reply-To: <79CD15C6BA57404B839C016229A409A83EC3E7C3@DBDE01.ent.ti.com>
References: <79CD15C6BA57404B839C016229A409A83EC3E7C3@DBDE01.ent.ti.com>
Message-ID: <51596501.1020904@ti.com>

> 
> Where, the clk_set_rate() seems to be not working, and that's true
> with the current implementation of OMAP/AM33xx clock tree,
> as the CLK_SET_RATE_PARENT flag is not set to any of the clock nodes.
> 
> Please note that I am using DEFINE_STRUCT_CLK() macro for defining clocks
> And which doesn't allow you to specify the flags.

Use DEFINE_STRUCT_CLK_FLAGS() then. Its already used in AM33xx clock tree.


From alexey.pelykh at gmail.com  Mon Apr  1 06:45:33 2013
From: alexey.pelykh at gmail.com (Alexey Pelykh)
Date: Mon, 1 Apr 2013 13:45:33 +0300
Subject: [PATCH] Revert "OMAP/serial: Fix incorrect Rx FIFO threshold
 setting, LSR validation on Tx, and Tx FIFO IRQ generation"
In-Reply-To: <alpine.DEB.2.00.1304011008230.28273@utopia.booyaka.com>
References: <alpine.DEB.2.00.1304010519260.28273@utopia.booyaka.com>
 <CAOmKuSpttQJmrL=Htiz-Zc4voAF7CnG_GQYAO2onKpauwYjtvw@mail.gmail.com>
 <alpine.DEB.2.00.1304010844100.28273@utopia.booyaka.com>
 <CAOmKuSrABrPcZ=Yg1+LAHWbh9CdTYR0eUmJ2dd3z91oz0uu21g@mail.gmail.com>
 <alpine.DEB.2.00.1304011008230.28273@utopia.booyaka.com>
Message-ID: <CAOmKuSrbDc025Tj9xsqDebJ_KZdp_VnWAOs_OO5UAegV43JcDQ@mail.gmail.com>

On Mon, Apr 1, 2013 at 1:19 PM, Paul Walmsley <paul at pwsan.com> wrote:
> cc Kevin, Felipe
>
> Hi
>
> On Mon, 1 Apr 2013, Alexey Pelykh wrote:
>
>> On Mon, Apr 1, 2013 at 12:13 PM, Paul Walmsley <paul at pwsan.com> wrote:
>> > On Mon, 1 Apr 2013, Alexey Pelykh wrote:
>> >
>> >> Actually, I've tested my patch on DM3730,
>> >
>> > What board, bootloader, and test steps did you use?  Can you post a dmesg?
>>
>> I've used LogicPD Torpedo Wireless SoM + DevKit board. Bootloader is
>> stock from their BSP, u-boot 2011.06 + patches from LogicPD.
>> I can provide dmesg of 3.8(inital kernel this patch was intented for)
>> a bit later during the day, and a bit more later same patch rebased
>> onto latest sources.
>> Also, I should mention that LogicPD does not support 3.8, so most
>> LogicPD-specific devices are not working.
>
> A dmesg from v3.9-rc5 would be ideal, but sounds like it's a non-mainline
> kernel?

It's true, mainline kernel won't run on that board out of the box, but
patches to
support it go only in mach-types.h and board-omap3logic.c

>
> Are you using a serial console on that board, and if so, what UART is it
> on?

Yes, it's serial console port on UART0 (console=ttyO0,115200n8)

>
>> And I'd like to point out that after patch gaps I've seen are not gone
>> completely, ~1 packet out of 200 at 1mbaud is still corrupted, but
>> only when PM is enabled in kernel,
>
> Are you seeing corruption caused by the OMAP UART's receive path, or by
> the transmit path?

Corruption is on Tx path. Without my patch (but with patch to allow 1Mbaud):
Interrupt to refill Tx FIFO is raised only after entire FIFO is
transmitted (that is, no data left in FIFO to be sent),
and it takes kernel 25us to handle interrupt and refill FIFO. Issue is
in condition when UART triggers interrupt.
According to original sources, this interrupt is configured to be
raised only when TX FIFO is (fully) empty, while
ignoring Tx FIFO threshold level completely, although it's being
(almost) properly configured and enabled.
So, what my patch changes is basically when interrupt to refill Tx
FIFO is raised:
 - from "when empty" to "when threshold is reached", refs:
OMAP_UART_SCR_TX_EMPTY flag
   should not be set, and UART_LSR_THRE check is also invalid, since
blocks threshold level situation.
 - setting OMAP_UART_SCR_RX_TRIG_GRANU1_MASK will lead to incorrect
interpretation
   of threshold level settings (inconsistent with comments in driver
sources itself).

>
> When you say "only when PM is enabled" do you mean by enabling CONFIG_PM,
> or do you mean after setting an autosuspend timeout on the serial drivers,
> or something else?
>

I mean that I've seen gap issues both with CONFIG_PM=y and CONFIG_PM=n
After my patch I saw gap issues only several times, and _probably_
that is due to CONFIG_PM=y,
since I've never seen them after that with CONFIG_PM=n

I should point that tests I run are completely user-space, so I've
never tested UARTs
using oscilloscope during kernel boot. But, no issues in serial
console seen, as I've
already pointed out.

>> what gives me a clue that it must be something in PM also. Maybe my
>> patch just reveals PM-specific issue. Have you tried without PM to
>> reproduce issues you're experiencing?
>
> So I'm using omap2plus_defconfig, which has CONFIG_PM=y, but the issues
> appear before serial autosuspend is enabled.
>
>> Indeed, TRMs appear to contain wrong information, but I believe that
>> in this particular case, bug is somewhere around, but not in these
>> lines.
>> I believe if you take a look on related TRM pages, it seems quite
>> logical that configuration of SCR (before my patch) is not quite
>> proper:
>>  - trigger interrupt only when it's entirely empty, not when threshold
>> level is reached, what is incorrect, in my opinion.
>>  - (less influencing) Granularity of counter indicates opposite to
>> what is stated in comments
>>
>> These issues may have never been experienced by others, since
>> originally I've hit them on 1mbaud speed, what is not supported by
>> original driver at all.
>
> It wouldn't surprise me at all if something is wrong with the
> original driver's FIFO setup.  The challenge at this point is to keep
> the driver working while trying to fix what's wrong with it.
>
>
> - Paul


From hvaibhav at ti.com  Mon Apr  1 07:06:59 2013
From: hvaibhav at ti.com (Hiremath, Vaibhav)
Date: Mon, 1 Apr 2013 11:06:59 +0000
Subject: Query regarding clk framework - from .set_rate api
In-Reply-To: <51596501.1020904@ti.com>
References: <79CD15C6BA57404B839C016229A409A83EC3E7C3@DBDE01.ent.ti.com>
 <51596501.1020904@ti.com>
Message-ID: <79CD15C6BA57404B839C016229A409A83EC3E822@DBDE01.ent.ti.com>

> -----Original Message-----
> From: Nayak, Rajendra
> Sent: Monday, April 01, 2013 4:14 PM
> To: Hiremath, Vaibhav
> Cc: mturquette at linaro.org; Paul Walmsley; Tony Lindgren; linux-
> omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org;
> khilman at deeprootsystems.com
> Subject: Re: Query regarding clk framework - from .set_rate api
> 
> >
> > Where, the clk_set_rate() seems to be not working, and that's true
> > with the current implementation of OMAP/AM33xx clock tree,
> > as the CLK_SET_RATE_PARENT flag is not set to any of the clock nodes.
> >
> > Please note that I am using DEFINE_STRUCT_CLK() macro for defining
> clocks
> > And which doesn't allow you to specify the flags.
> 
> Use DEFINE_STRUCT_CLK_FLAGS() then. Its already used in AM33xx clock
> tree.

Its not there in my kernel baseline v3.8.5, that?s why I missed it.
It got merged into v3.9-rc.

I am testing it now, and will update shortly.

Thanks,
Vaibhav


From alexey.pelykh at gmail.com  Mon Apr  1 07:18:44 2013
From: alexey.pelykh at gmail.com (Alexey Pelykh)
Date: Mon, 1 Apr 2013 14:18:44 +0300
Subject: [PATCH] Revert "OMAP/serial: Fix incorrect Rx FIFO threshold
 setting, LSR validation on Tx, and Tx FIFO IRQ generation"
In-Reply-To: <CAOmKuSrbDc025Tj9xsqDebJ_KZdp_VnWAOs_OO5UAegV43JcDQ@mail.gmail.com>
References: <alpine.DEB.2.00.1304010519260.28273@utopia.booyaka.com>
 <CAOmKuSpttQJmrL=Htiz-Zc4voAF7CnG_GQYAO2onKpauwYjtvw@mail.gmail.com>
 <alpine.DEB.2.00.1304010844100.28273@utopia.booyaka.com>
 <CAOmKuSrABrPcZ=Yg1+LAHWbh9CdTYR0eUmJ2dd3z91oz0uu21g@mail.gmail.com>
 <alpine.DEB.2.00.1304011008230.28273@utopia.booyaka.com>
 <CAOmKuSrbDc025Tj9xsqDebJ_KZdp_VnWAOs_OO5UAegV43JcDQ@mail.gmail.com>
Message-ID: <CAOmKuSpbaKutLxbNihBRDz+B0Wt0XiPss-PcEHc-efCTvciNFg@mail.gmail.com>

Paul,

Please, correct me if I'm wrong, you're experiencing issues on Tx, or
Rx direction? You've said that characters are echoed incorrectly, but
haven't mentioned in what direction issue appears?
For reference, I'll quote TI DM3730 Rev.R TRM:
TRM page 2953, LSR_REG
Bit #5: TX_FIFO_E
 0x0 Transmit hold register (TX FIFO) is not empty.
 0x1 Transmit hold register (TX FIFO) is empty. The transmission is
not necessarily complete.

Before my patch: there was a check for TX_FIFO_E to be 0x1 before
filling Tx FIFO
After: If THR interrupt is raised, then there is a space in FIFO and
threshold has reached it's level, no extra check is required

TRM page 2972, SCR_REG
Bit #4: TX_EMPTY_CTL_IT
 0x1 The THR interrupt is generated when TX FIFO and TX shift register
are empty.
 0x0 Normal mode for THR interrupt (see Table 19-33 for details about
UART mode interrupts)

Before: THR interrput is raised only when TX FIFO and TX shift
register are empty, for shortcut "all Tx lane empty"
After: THR interrupt is raised both when Tx lane is empty, or when
size of data in Tx lane falls below Tx threshold level

Bit #7: RX_TRIG_GRANU1
 0x0 Disables the granularity of 1 for TRIGGER RX level
 0x1 Enables the granularity of 1 for TRIGGER RX level

Before: RX FIFO Trigger Level "Defined by the concatenated value of
RX_FIFO_TRIG_DMA and
RX_FIFO_TRIG (from 1 to 63 characters with a granularity of 1 character).
Note: The combination of RX_FIFO_TRIG_DMA = 0x0 and RX_FIFO_TRIG =
0x0 (all zeros) is not supported (minimum 1 character required). All
zeros result
in unpredictable behavior."

After: RX FIFO Trigger Level "Defined by the UARTi.FCR_REG[7:6]
RX_FIFO_TRIG field (8,16, 56, or 60
characters)" (as it should be according to comments in source code)

On Mon, Apr 1, 2013 at 1:45 PM, Alexey Pelykh <alexey.pelykh at gmail.com> wrote:
> On Mon, Apr 1, 2013 at 1:19 PM, Paul Walmsley <paul at pwsan.com> wrote:
>> cc Kevin, Felipe
>>
>> Hi
>>
>> On Mon, 1 Apr 2013, Alexey Pelykh wrote:
>>
>>> On Mon, Apr 1, 2013 at 12:13 PM, Paul Walmsley <paul at pwsan.com> wrote:
>>> > On Mon, 1 Apr 2013, Alexey Pelykh wrote:
>>> >
>>> >> Actually, I've tested my patch on DM3730,
>>> >
>>> > What board, bootloader, and test steps did you use?  Can you post a dmesg?
>>>
>>> I've used LogicPD Torpedo Wireless SoM + DevKit board. Bootloader is
>>> stock from their BSP, u-boot 2011.06 + patches from LogicPD.
>>> I can provide dmesg of 3.8(inital kernel this patch was intented for)
>>> a bit later during the day, and a bit more later same patch rebased
>>> onto latest sources.
>>> Also, I should mention that LogicPD does not support 3.8, so most
>>> LogicPD-specific devices are not working.
>>
>> A dmesg from v3.9-rc5 would be ideal, but sounds like it's a non-mainline
>> kernel?
>
> It's true, mainline kernel won't run on that board out of the box, but
> patches to
> support it go only in mach-types.h and board-omap3logic.c
>
>>
>> Are you using a serial console on that board, and if so, what UART is it
>> on?
>
> Yes, it's serial console port on UART0 (console=ttyO0,115200n8)
>
>>
>>> And I'd like to point out that after patch gaps I've seen are not gone
>>> completely, ~1 packet out of 200 at 1mbaud is still corrupted, but
>>> only when PM is enabled in kernel,
>>
>> Are you seeing corruption caused by the OMAP UART's receive path, or by
>> the transmit path?
>
> Corruption is on Tx path. Without my patch (but with patch to allow 1Mbaud):
> Interrupt to refill Tx FIFO is raised only after entire FIFO is
> transmitted (that is, no data left in FIFO to be sent),
> and it takes kernel 25us to handle interrupt and refill FIFO. Issue is
> in condition when UART triggers interrupt.
> According to original sources, this interrupt is configured to be
> raised only when TX FIFO is (fully) empty, while
> ignoring Tx FIFO threshold level completely, although it's being
> (almost) properly configured and enabled.
> So, what my patch changes is basically when interrupt to refill Tx
> FIFO is raised:
>  - from "when empty" to "when threshold is reached", refs:
> OMAP_UART_SCR_TX_EMPTY flag
>    should not be set, and UART_LSR_THRE check is also invalid, since
> blocks threshold level situation.
>  - setting OMAP_UART_SCR_RX_TRIG_GRANU1_MASK will lead to incorrect
> interpretation
>    of threshold level settings (inconsistent with comments in driver
> sources itself).
>
>>
>> When you say "only when PM is enabled" do you mean by enabling CONFIG_PM,
>> or do you mean after setting an autosuspend timeout on the serial drivers,
>> or something else?
>>
>
> I mean that I've seen gap issues both with CONFIG_PM=y and CONFIG_PM=n
> After my patch I saw gap issues only several times, and _probably_
> that is due to CONFIG_PM=y,
> since I've never seen them after that with CONFIG_PM=n
>
> I should point that tests I run are completely user-space, so I've
> never tested UARTs
> using oscilloscope during kernel boot. But, no issues in serial
> console seen, as I've
> already pointed out.
>
>>> what gives me a clue that it must be something in PM also. Maybe my
>>> patch just reveals PM-specific issue. Have you tried without PM to
>>> reproduce issues you're experiencing?
>>
>> So I'm using omap2plus_defconfig, which has CONFIG_PM=y, but the issues
>> appear before serial autosuspend is enabled.
>>
>>> Indeed, TRMs appear to contain wrong information, but I believe that
>>> in this particular case, bug is somewhere around, but not in these
>>> lines.
>>> I believe if you take a look on related TRM pages, it seems quite
>>> logical that configuration of SCR (before my patch) is not quite
>>> proper:
>>>  - trigger interrupt only when it's entirely empty, not when threshold
>>> level is reached, what is incorrect, in my opinion.
>>>  - (less influencing) Granularity of counter indicates opposite to
>>> what is stated in comments
>>>
>>> These issues may have never been experienced by others, since
>>> originally I've hit them on 1mbaud speed, what is not supported by
>>> original driver at all.
>>
>> It wouldn't surprise me at all if something is wrong with the
>> original driver's FIFO setup.  The challenge at this point is to keep
>> the driver working while trying to fix what's wrong with it.
>>
>>
>> - Paul


From hvaibhav at ti.com  Mon Apr  1 07:20:04 2013
From: hvaibhav at ti.com (Hiremath, Vaibhav)
Date: Mon, 1 Apr 2013 11:20:04 +0000
Subject: Query regarding clk framework - from .set_rate api
References: <79CD15C6BA57404B839C016229A409A83EC3E7C3@DBDE01.ent.ti.com>
 <51596501.1020904@ti.com> 
Message-ID: <79CD15C6BA57404B839C016229A409A83EC3E84A@DBDE01.ent.ti.com>


> -----Original Message-----
> From: Hiremath, Vaibhav
> Sent: Monday, April 01, 2013 4:37 PM
> To: Nayak, Rajendra
> Cc: mturquette at linaro.org; Paul Walmsley; Tony Lindgren; linux-
> omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org;
> khilman at deeprootsystems.com
> Subject: RE: Query regarding clk framework - from .set_rate api
> 
> > -----Original Message-----
> > From: Nayak, Rajendra
> > Sent: Monday, April 01, 2013 4:14 PM
> > To: Hiremath, Vaibhav
> > Cc: mturquette at linaro.org; Paul Walmsley; Tony Lindgren; linux-
> > omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org;
> > khilman at deeprootsystems.com
> > Subject: Re: Query regarding clk framework - from .set_rate api
> >
> > >
> > > Where, the clk_set_rate() seems to be not working, and that's true
> > > with the current implementation of OMAP/AM33xx clock tree,
> > > as the CLK_SET_RATE_PARENT flag is not set to any of the clock
> nodes.
> > >
> > > Please note that I am using DEFINE_STRUCT_CLK() macro for defining
> > clocks
> > > And which doesn't allow you to specify the flags.
> >
> > Use DEFINE_STRUCT_CLK_FLAGS() then. Its already used in AM33xx clock
> > tree.
> 
> Its not there in my kernel baseline v3.8.5, that?s why I missed it.
> It got merged into v3.9-rc.
> 
> I am testing it now, and will update shortly.
> 

And it works fine...

Sorry for the noise, I should have checked mainline status
before drafting this email.

Thanks,
Vaibhav


From prabhakar.csengg at gmail.com  Mon Apr  1 07:33:36 2013
From: prabhakar.csengg at gmail.com (Prabhakar lad)
Date: Mon,  1 Apr 2013 17:03:36 +0530
Subject: [PATCH] ARM: daVinci: remove __init modifier from function declaration
Message-ID: <1364816016-29656-1-git-send-email-prabhakar.csengg@gmail.com>

From: Lad, Prabhakar <prabhakar.csengg at gmail.com>

This patch removes the __init modifier from function declaration
of all the header files for davinci platform.

Signed-off-by: Lad, Prabhakar <prabhakar.csengg at gmail.com>
Cc: Sekhar Nori <nsekhar at ti.com>
---
 arch/arm/mach-davinci/davinci.h                |   28 ++++++++++++------------
 arch/arm/mach-davinci/include/mach/cp_intc.h   |    4 +-
 arch/arm/mach-davinci/include/mach/da8xx.h     |   16 ++++++------
 arch/arm/mach-davinci/include/mach/tnetv107x.h |    6 ++--
 4 files changed, 27 insertions(+), 27 deletions(-)

diff --git a/arch/arm/mach-davinci/davinci.h b/arch/arm/mach-davinci/davinci.h
index 12d544b..97e74ca 100644
--- a/arch/arm/mach-davinci/davinci.h
+++ b/arch/arm/mach-davinci/davinci.h
@@ -70,32 +70,32 @@ void davinci_map_sysmod(void);
 #define DM646X_ASYNC_EMIF_CS2_SPACE_BASE 0x42000000
 
 /* DM355 function declarations */
-void __init dm355_init(void);
+void dm355_init(void);
 void dm355_init_spi0(unsigned chipselect_mask,
 		const struct spi_board_info *info, unsigned len);
-void __init dm355_init_asp1(u32 evt_enable, struct snd_platform_data *pdata);
+void dm355_init_asp1(u32 evt_enable, struct snd_platform_data *pdata);
 void dm355_set_vpfe_config(struct vpfe_config *cfg);
 
 /* DM365 function declarations */
-void __init dm365_init(void);
-void __init dm365_init_asp(struct snd_platform_data *pdata);
-void __init dm365_init_vc(struct snd_platform_data *pdata);
-void __init dm365_init_ks(struct davinci_ks_platform_data *pdata);
-void __init dm365_init_rtc(void);
+void dm365_init(void);
+void dm365_init_asp(struct snd_platform_data *pdata);
+void dm365_init_vc(struct snd_platform_data *pdata);
+void dm365_init_ks(struct davinci_ks_platform_data *pdata);
+void dm365_init_rtc(void);
 void dm365_init_spi0(unsigned chipselect_mask,
 			const struct spi_board_info *info, unsigned len);
 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 *, struct vpbe_config *);
+void dm644x_init(void);
+void dm644x_init_asp(struct snd_platform_data *pdata);
+int dm644x_init_video(struct vpfe_config *, struct vpbe_config *);
 
 /* DM646x function declarations */
-void __init dm646x_init(void);
-void __init dm646x_init_mcasp0(struct snd_platform_data *pdata);
-void __init dm646x_init_mcasp1(struct snd_platform_data *pdata);
-int __init dm646x_init_edma(struct edma_rsv_info *rsv);
+void dm646x_init(void);
+void dm646x_init_mcasp0(struct snd_platform_data *pdata);
+void dm646x_init_mcasp1(struct snd_platform_data *pdata);
+int dm646x_init_edma(struct edma_rsv_info *rsv);
 void dm646x_video_init(void);
 void dm646x_setup_vpif(struct vpif_display_config *,
 		       struct vpif_capture_config *);
diff --git a/arch/arm/mach-davinci/include/mach/cp_intc.h b/arch/arm/mach-davinci/include/mach/cp_intc.h
index d13d8df..827bbe9 100644
--- a/arch/arm/mach-davinci/include/mach/cp_intc.h
+++ b/arch/arm/mach-davinci/include/mach/cp_intc.h
@@ -51,7 +51,7 @@
 #define CP_INTC_HOST_PRIO_VECTOR(n)	(0x1600 + (n << 2))
 #define CP_INTC_VECTOR_ADDR(n)		(0x2000 + (n << 2))
 
-void __init cp_intc_init(void);
-int __init cp_intc_of_init(struct device_node *, struct device_node *);
+void cp_intc_init(void);
+int cp_intc_of_init(struct device_node *, struct device_node *);
 
 #endif	/* __ASM_HARDWARE_CP_INTC_H */
diff --git a/arch/arm/mach-davinci/include/mach/da8xx.h b/arch/arm/mach-davinci/include/mach/da8xx.h
index de439b7..dad6705 100644
--- a/arch/arm/mach-davinci/include/mach/da8xx.h
+++ b/arch/arm/mach-davinci/include/mach/da8xx.h
@@ -76,8 +76,8 @@ extern unsigned int da850_max_speed;
 #define DA8XX_SHARED_RAM_BASE	0x80000000
 #define DA8XX_ARM_RAM_BASE	0xffff0000
 
-void __init da830_init(void);
-void __init da850_init(void);
+void da830_init(void);
+void da850_init(void);
 
 int da830_register_edma(struct edma_rsv_info *rsv);
 int da850_register_edma(struct edma_rsv_info *rsv[2]);
@@ -91,17 +91,17 @@ int da8xx_register_uio_pruss(void);
 int da8xx_register_lcdc(struct da8xx_lcdc_platform_data *pdata);
 int da8xx_register_mmcsd0(struct davinci_mmc_config *config);
 int da850_register_mmcsd1(struct davinci_mmc_config *config);
-void __init da8xx_register_mcasp(int id, struct snd_platform_data *pdata);
+void da8xx_register_mcasp(int id, struct snd_platform_data *pdata);
 int da8xx_register_rtc(void);
 int da850_register_cpufreq(char *async_clk);
 int da8xx_register_cpuidle(void);
-void __iomem * __init da8xx_get_mem_ctlr(void);
+void __iomem *da8xx_get_mem_ctlr(void);
 int da850_register_pm(struct platform_device *pdev);
-int __init da850_register_sata(unsigned long refclkpn);
-int __init da850_register_vpif(void);
-int __init da850_register_vpif_display
+int da850_register_sata(unsigned long refclkpn);
+int da850_register_vpif(void);
+int da850_register_vpif_display
 			(struct vpif_display_config *display_config);
-int __init da850_register_vpif_capture
+int da850_register_vpif_capture
 			(struct vpif_capture_config *capture_config);
 void da8xx_restart(char mode, const char *cmd);
 
diff --git a/arch/arm/mach-davinci/include/mach/tnetv107x.h b/arch/arm/mach-davinci/include/mach/tnetv107x.h
index 1656a02..366e975 100644
--- a/arch/arm/mach-davinci/include/mach/tnetv107x.h
+++ b/arch/arm/mach-davinci/include/mach/tnetv107x.h
@@ -51,9 +51,9 @@ struct tnetv107x_device_info {
 extern struct platform_device tnetv107x_wdt_device;
 extern struct platform_device tnetv107x_serial_device;
 
-extern void __init tnetv107x_init(void);
-extern void __init tnetv107x_devices_init(struct tnetv107x_device_info *);
-extern void __init tnetv107x_irq_init(void);
+extern void tnetv107x_init(void);
+extern void tnetv107x_devices_init(struct tnetv107x_device_info *);
+extern void tnetv107x_irq_init(void);
 void tnetv107x_restart(char mode, const char *cmd);
 
 #endif
-- 
1.7.4.1



From nsekhar at ti.com  Mon Apr  1 07:35:36 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Mon, 1 Apr 2013 17:05:36 +0530
Subject: [PATCH v3 1/3] ARM: davinci: clk framework support for
 enable/disable functionality
In-Reply-To: <1364204268-15010-1-git-send-email-avinashphilip@ti.com>
References: <1364197789-16783-1-git-send-email-avinashphilip@ti.com>
 <1364204268-15010-1-git-send-email-avinashphilip@ti.com>
Message-ID: <51597108.4050706@ti.com>

On 3/25/2013 3:07 PM, Philip Avinash wrote:
> Davinci clock framework currently not supporting clock enable/disable

This is incorrect. We do support enable disable of PSCs in davinci clock
implementation.

> functionality on clock nodes. In Davinci platform, EHRPWM module requires

s/In Davinci platform/On DA850 SoC/

> support for clock enable/disable for TBCLK support. Hence this patch
> adds support for enabling/disabling clocks depends on the availability
> of the functionality.

I reworded the path description as below. Taking care of above and
making some other minor changes:

    DaVinci clock implementation does not support clock enable/disable
    functionality on non-PSC clock nodes.

    On DA850 SoC, EHRPWM module requires support for enable/disable
    of TBCLK controlled using a system module register.

    This patch adds a method for enabling/disabling non-PSC clocks
    into DaVinci clock implementation.

> 
> Signed-off-by: Philip Avinash <avinashphilip at ti.com>
> ---
> Changes since v2:
> 	- start using "usecount" field in clk structure to
> 	  enable/disable clocks.
> 
> Changes since v1:
> 	- Add support for clock enable/disable functionality.
> 
>  arch/arm/mach-davinci/clock.c |   21 ++++++++++++++-------
>  arch/arm/mach-davinci/clock.h |    2 ++
>  2 files changed, 16 insertions(+), 7 deletions(-)
> 
> diff --git a/arch/arm/mach-davinci/clock.c b/arch/arm/mach-davinci/clock.c
> index d458558..960c7a5 100644
> --- a/arch/arm/mach-davinci/clock.c
> +++ b/arch/arm/mach-davinci/clock.c
> @@ -35,19 +35,26 @@ static void __clk_enable(struct clk *clk)
>  {
>  	if (clk->parent)
>  		__clk_enable(clk->parent);
> -	if (clk->usecount++ == 0 && (clk->flags & CLK_PSC))
> -		davinci_psc_config(clk->domain, clk->gpsc, clk->lpsc,
> -				true, clk->flags);
> +	if (clk->usecount++ == 0) {
> +		if (clk->flags & CLK_PSC)
> +			davinci_psc_config(clk->domain, clk->gpsc, clk->lpsc,
> +					true, clk->flags);

This line break can be aligned to open parenthesis. This is reported by
checkpatch --strict. I fixed this locally.

With these changed, I am queuing this patch for v3.10

Thanks,
Sekhar


From nigel at nobiscuit.com  Mon Apr  1 07:39:40 2013
From: nigel at nobiscuit.com (Nigel Roberts)
Date: Mon, 1 Apr 2013 22:39:40 +1100
Subject: [PATCH 2/2] Fix GE0/GE1 init on ix2-200 as GE0 has no PHY
In-Reply-To: <20130331212335.GM13280@titan.lakedaemon.net>
References: <1364703204-14982-1-git-send-email-nigel@nobiscuit.com>
 <1364703204-14982-3-git-send-email-nigel@nobiscuit.com>
 <20130331212335.GM13280@titan.lakedaemon.net>
Message-ID: <B3DDAAD1-914A-40AE-88FA-590FDD7CE6F3@nobiscuit.com>

On 01/04/2013, at 8:23 AM, Jason Cooper <jason at lakedaemon.net> wrote:

> Nigel,
> 
> On Sun, Mar 31, 2013 at 03:13:24PM +1100, Nigel Roberts wrote:
> 
> Please include a description here about the problem and how this fixed
> it.
> 
> Also, please Cc: Alan Butler alanbutty12 at gmail.com, he's the original
> author of the support for this board.  I'd like to know why it
> (hopefully) worked for him, but doesn't work for you.

Thanks Jason. 

With the original version of board-iomega_ix2_200.c provided by Alan, the PHY for GE1 (port 1) is not configured because of the use of MV643XX_ETH_PHY_NONE. The speed and duplex are also forced to 1000/full, which means I can't use a 100mb port on my router. It will work just fine for people who use just 1000Mb switch ports, which is why Alan probably didn't have any problems with it.

If I only attempt to initialise GE01 with the correct address of the PHY without initialising GE00 first, I get a kernel panic. This is probably a bug in arch/arm/plat-orion/common.c, but I haven't figured out how to fix it. I'll keep investigating what other changes I need to make so that initialising only GE1 with the correct PHY address doesn't cause this panic. Maybe this will be fixed once the mv643xx_eth driver works properly with device trees.

[   21.139765] mv643xx_eth: MV-643xx 10/100/1000 ethernet driver version 1.4
[   21.146715] Unable to handle kernel NULL pointer dereference at virtual address 00000008
[   21.154859] pgd = c0004000
[   21.157576] [00000008] *pgd=00000000
[   21.161182] Internal error: Oops: 5 [#1] ARM
[   21.165466] Modules linked in:
[   21.168540] CPU: 0    Not tainted  (3.8.5 #9)
[   21.172924] PC is at mv643xx_eth_probe+0x254/0x67c
[   21.177739] LR is at mv643xx_eth_probe+0x234/0x67c
[   21.182555] pc : [<c021d3a4>]    lr : [<c021d384>]    psr: 20000013
[   21.182555] sp : cf83fe78  ip : 00000000  fp : 00000000
[   21.194080] r10: c0425208  r9 : c0448e2c  r8 : c0458848
[   21.199330] r7 : cf861a80  r6 : c0457b48  r5 : cf814440  r4 : cf814000
[   21.205886] r3 : 00000001  r2 : 0000000b  r1 : 00000000  r0 : 00000000
[   21.212445] Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
[   21.219786] Control: 0005397f  Table: 00004000  DAC: 00000017
[   21.225558] Process swapper (pid: 1, stack limit = 0xcf83e1b8)
[   21.231418] Stack: (0xcf83fe78 to 0xcf840000)
[   21.235798] fe60:                                                       cf805bac c0458858
[   21.244018] fe80: cf861f40 00000000 c045888c c0458858 c045888c c0477e8c c0477e8c 0000003d
[   21.252240] fea0: c0448e2c c0425208 00000000 c01deb64 c01deb50 c01ddc5c 00000000 c0458858
[   21.260454] fec0: c045888c c0477e8c 00000000 c01dddf4 c0477e8c cf83fee0 c01ddd94 c01dc738
[   21.268669] fee0: cf805b8c cf834c90 c0477e8c c0477e8c ceabb300 c0472c00 00000000 c01dd3dc
[   21.276891] ff00: c03a8ca2 c03a8cae c0477e8c c043d724 00000000 c0481240 0000003d c01de0a0
[   21.285106] ff20: c01deb88 00000000 c043d724 00000000 c0481240 0000003d c0425208 c043d740
[   21.293318] ff40: 00000006 c0008598 00000006 00000006 00000000 00000006 c0444a90 00000006
[   21.301534] ff60: c0444a94 c0444a74 c0481240 0000003d c0448e2c c0425890 00000006 00000006
[   21.309747] ff80: c0425208 00000000 00000000 c030083c 00000000 00000000 00000000 00000000
[   21.317962] ffa0: 00000000 c0300844 00000000 c0009110 00000000 00000000 00000000 00000000
[   21.326175] ffc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[   21.334389] ffe0: 00000000 00000000 00000000 00000000 00000013 00000000 00210007 00450000
[   21.342621] [<c021d3a4>] (mv643xx_eth_probe+0x254/0x67c) from [<c01deb64>] (platform_drv_probe+0x14/0x18)
[   21.352236] [<c01deb64>] (platform_drv_probe+0x14/0x18) from [<c01ddc5c>] (driver_probe_device+0xb8/0x1f0)
[   21.361938] [<c01ddc5c>] (driver_probe_device+0xb8/0x1f0) from [<c01dddf4>] (__driver_attach+0x60/0x84)
[   21.371382] [<c01dddf4>] (__driver_attach+0x60/0x84) from [<c01dc738>] (bus_for_each_dev+0x50/0x84)
[   21.380477] [<c01dc738>] (bus_for_each_dev+0x50/0x84) from [<c01dd3dc>] (bus_add_driver+0xa8/0x21c)
[   21.389562] [<c01dd3dc>] (bus_add_driver+0xa8/0x21c) from [<c01de0a0>] (driver_register+0x9c/0x138)
[   21.398653] [<c01de0a0>] (driver_register+0x9c/0x138) from [<c043d740>] (mv643xx_eth_init_module+0x1c/0x3c)
[   21.408445] [<c043d740>] (mv643xx_eth_init_module+0x1c/0x3c) from [<c0008598>] (do_one_initcall+0x90/0x168)
[   21.418242] [<c0008598>] (do_one_initcall+0x90/0x168) from [<c0425890>] (kernel_init_freeable+0x118/0x1e4)
[   21.427948] [<c0425890>] (kernel_init_freeable+0x118/0x1e4) from [<c0300844>] (kernel_init+0x8/0xe4)
[   21.437125] [<c0300844>] (kernel_init+0x8/0xe4) from [<c0009110>] (ret_from_fork+0x14/0x24)
[   21.445518] Code: e3520000 1202201f e5931004 13a03001 (e591b008)
[   21.451690] ---[ end trace 1baf370a96a1315c ]---
[   21.456349] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
[   21.456349]

> 
>> ---
>> arch/arm/mach-kirkwood/board-iomega_ix2_200.c |    7 ++++++-
>> 1 file changed, 6 insertions(+), 1 deletion(-)
>> 
>> diff --git a/arch/arm/mach-kirkwood/board-iomega_ix2_200.c b/arch/arm/mach-kirkwood/board-iomega_ix2_200.c
>> index f655b26..e5f7041 100644
>> --- a/arch/arm/mach-kirkwood/board-iomega_ix2_200.c
>> +++ b/arch/arm/mach-kirkwood/board-iomega_ix2_200.c
>> @@ -20,10 +20,15 @@ static struct mv643xx_eth_platform_data iomega_ix2_200_ge00_data = {
>> 	.duplex         = DUPLEX_FULL,
>> };
>> 
>> +static struct mv643xx_eth_platform_data iomega_ix2_200_ge01_data = {
>> +        .phy_addr       = MV643XX_ETH_PHY_ADDR(11),
>> +};
>> +
>> void __init iomega_ix2_200_init(void)
>> {
>> 	/*
>> 	 * Basic setup. Needs to be called early.
>> 	 */
>> -	kirkwood_ge01_init(&iomega_ix2_200_ge00_data);
>> +	kirkwood_ge00_init(&iomega_ix2_200_ge00_data);
>> +	kirkwood_ge01_init(&iomega_ix2_200_ge01_data);
> 
> This looks a lot more legit, have you tried removing .speed and .duplex
> from ge00?  We see that a lot with boards converted from out-of-tree
> legacy board files, I'm not certain those declarations are necessary.

They're used by mv643xx_eth if you don't specify a PHY address, which is necessary as per the above.

Thanks,
Nigel




From broonie at opensource.wolfsonmicro.com  Mon Apr  1 07:45:19 2013
From: broonie at opensource.wolfsonmicro.com (Mark Brown)
Date: Mon, 1 Apr 2013 12:45:19 +0100
Subject: [PATCH 03/13] ASoC: mxs-saif: remove mach header inclusion
In-Reply-To: <1364547350-30498-4-git-send-email-shawn.guo@linaro.org>
References: <1364547350-30498-1-git-send-email-shawn.guo@linaro.org>
 <1364547350-30498-4-git-send-email-shawn.guo@linaro.org>
Message-ID: <20130401114519.GB18636@opensource.wolfsonmicro.com>

On Fri, Mar 29, 2013 at 04:55:39PM +0800, Shawn Guo wrote:
> The header <mach/hardware.h> is not needed at all, and <mach/mxs.h> is
> needed only for macros MXS_SET_ADDR and MXS_CLR_ADDR.  Define the macros
> and remove the mach header inclusions.

Acked-by: Mark Brown <broonie at opensource.wolfsonmicro.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130401/d2f41cdb/attachment-0001.sig>

From shawn.guo at linaro.org  Mon Apr  1 08:01:13 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Mon, 1 Apr 2013 20:01:13 +0800
Subject: [PATCH] staging: rts5139: device_reset() can be static
Message-ID: <1364817673-21256-1-git-send-email-shawn.guo@linaro.org>

Function device_reset() is only used in rts51x_scsi.c, so make it be
static.  Otherwise, it will have a name collision with the new added
reset API.

Reported-by: kbuild test robot <fengguang.wu at intel.com>
Signed-off-by: Shawn Guo <shawn.guo at linaro.org>
---
 drivers/staging/rts5139/rts51x_scsi.c |    2 +-
 drivers/staging/rts5139/rts51x_scsi.h |    1 -
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/staging/rts5139/rts51x_scsi.c b/drivers/staging/rts5139/rts51x_scsi.c
index 052911c..b58f1df 100644
--- a/drivers/staging/rts5139/rts51x_scsi.c
+++ b/drivers/staging/rts5139/rts51x_scsi.c
@@ -2072,7 +2072,7 @@ int command_abort(struct scsi_cmnd *srb)
 
 /* This invokes the transport reset mechanism to reset the state of the
  * device */
-int device_reset(struct scsi_cmnd *srb)
+static int device_reset(struct scsi_cmnd *srb)
 {
 	int result = 0;
 
diff --git a/drivers/staging/rts5139/rts51x_scsi.h b/drivers/staging/rts5139/rts51x_scsi.h
index cdfe550..3a52136 100644
--- a/drivers/staging/rts5139/rts51x_scsi.h
+++ b/drivers/staging/rts5139/rts51x_scsi.h
@@ -151,7 +151,6 @@ int proc_info(struct Scsi_Host *host, char *buffer,
 	      char **start, off_t offset, int length, int inout);
 int queuecommand(struct Scsi_Host *, struct scsi_cmnd *);
 int command_abort(struct scsi_cmnd *srb);
-int device_reset(struct scsi_cmnd *srb);
 int bus_reset(struct scsi_cmnd *srb);
 
 #endif /* __RTS51X_SCSI_H */
-- 
1.7.9.5




From nigel at nobiscuit.com  Mon Apr  1 08:03:21 2013
From: nigel at nobiscuit.com (Nigel Roberts)
Date: Mon,  1 Apr 2013 23:03:21 +1100
Subject: [PATCH] ARM: Kirkwood: Fix typo in the definition of ix2-200 rebuild
 LED 
Message-ID: <1364817802-7889-1-git-send-email-nigel@nobiscuit.com>

[PATCH] Fix typo in the definition of ix2-200 rebuild LED
 arch/arm/boot/dts/kirkwood-iomega_ix2_200.dts |   14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)


From nigel at nobiscuit.com  Mon Apr  1 08:03:22 2013
From: nigel at nobiscuit.com (Nigel Roberts)
Date: Mon,  1 Apr 2013 23:03:22 +1100
Subject: [PATCH] Fix typo in the definition of ix2-200 rebuild LED
In-Reply-To: <1364817802-7889-1-git-send-email-nigel@nobiscuit.com>
References: <1364817802-7889-1-git-send-email-nigel@nobiscuit.com>
Message-ID: <1364817802-7889-2-git-send-email-nigel@nobiscuit.com>

In the conversion to pinctrl, an error in the pins for the rebuild
LED was introduced. This patch assigns the correct pins and includes
the correct name for the LED in kirkwood-iomega_ix2_200.dts.

Signed-off-by: Nigel Roberts <nigel at nobiscuit.com>
---
 arch/arm/boot/dts/kirkwood-iomega_ix2_200.dts |   14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/arm/boot/dts/kirkwood-iomega_ix2_200.dts b/arch/arm/boot/dts/kirkwood-iomega_ix2_200.dts
index 93c3afb..3694e94 100644
--- a/arch/arm/boot/dts/kirkwood-iomega_ix2_200.dts
+++ b/arch/arm/boot/dts/kirkwood-iomega_ix2_200.dts
@@ -96,11 +96,11 @@
 				marvell,function = "gpio";
 			};
 			pmx_led_rebuild_brt_ctrl_1: pmx-led-rebuild-brt-ctrl-1 {
-				marvell,pins = "mpp44";
+				marvell,pins = "mpp46";
 				marvell,function = "gpio";
 			};
 			pmx_led_rebuild_brt_ctrl_2: pmx-led-rebuild-brt-ctrl-2 {
-				marvell,pins = "mpp45";
+				marvell,pins = "mpp47";
 				marvell,function = "gpio";
 			};
 
@@ -157,14 +157,14 @@
 			gpios = <&gpio0 16 0>;
 			linux,default-trigger = "default-on";
 		};
-		health_led1 {
+		rebuild_led {
+			label = "status:white:rebuild_led";
+			gpios = <&gpio1 4 0>;
+		};
+		health_led {
 			label = "status:red:health_led";
 			gpios = <&gpio1 5 0>;
 		};
-		health_led2 {
-			label = "status:white:health_led";
-			gpios = <&gpio1 4 0>;
-		};
 		backup_led {
 			label = "status:blue:backup_led";
 			gpios = <&gpio0 15 0>;
-- 
1.7.9.5



From shawn.guo at linaro.org  Mon Apr  1 08:10:33 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Mon, 1 Apr 2013 20:10:33 +0800
Subject: [PATCH] reset: make it depend on CONFIG_OF
Message-ID: <1364818233-24102-1-git-send-email-shawn.guo@linaro.org>

The reset API is really designed for device tree users, so make it
depend on CONFIG_OF to fix the compile warning below seen with i386
allyesconfig.

 drivers/reset/gpio-reset.c:187:28: warning: 'gpio_reset_dt_ids' defined but not used [-Wunused-variable]

Signed-off-by: Shawn Guo <shawn.guo at linaro.org>
---
 drivers/reset/Kconfig |    1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index e728d36..324a2b3 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -4,6 +4,7 @@ config ARCH_HAS_RESET_CONTROLLER
 menuconfig RESET_CONTROLLER
 	bool "Reset Controller Support"
 	default y if ARCH_HAS_RESET_CONTROLLER
+	depends on OF
 	help
 	  Generic Reset Controller support.
 
-- 
1.7.9.5




From sergei.shtylyov at cogentembedded.com  Mon Apr  1 08:44:17 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Mon, 01 Apr 2013 16:44:17 +0400
Subject: [PATCH 2/3 v2] ARM: shmobile: r8a7778: add
 r8a7778_init_irq_extpin()
In-Reply-To: <87d2uf56kt.wl%kuninori.morimoto.gx@renesas.com>
References: <87zjxvewko.wl%kuninori.morimoto.gx@renesas.com>
 <87fvzb56n3.wl%kuninori.morimoto.gx@renesas.com>
 <87d2uf56kt.wl%kuninori.morimoto.gx@renesas.com>
Message-ID: <51598121.9010005@cogentembedded.com>

Hello.

On 01-04-2013 6:27, Kuninori Morimoto wrote:

> This patch adds r8a7778_init_irq_extpin() for IRQ0 - IRQ3.
> But this patch doesn't enable DT settings on r8a7778.dts,
> because R8A7778 chip external IRQ depends on
> IRQ0 - IRQ3 pin encoding which came from platform board
> implementation.

> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
[...]

> diff --git a/arch/arm/mach-shmobile/setup-r8a7778.c b/arch/arm/mach-shmobile/setup-r8a7778.c
> index 57d6b0e..2882305 100644
> --- a/arch/arm/mach-shmobile/setup-r8a7778.c
> +++ b/arch/arm/mach-shmobile/setup-r8a7778.c
[...]
> @@ -110,6 +111,49 @@ void __init r8a7778_add_standard_devices(void)
>   	r8a7778_register_tmu(1);
>   }
>
> +static struct renesas_intc_irqpin_config irqpin_platform_data = {
> +	.irq_base = irq_pin(0), /* IRQ0 -> IRQ3 */
> +	.sense_bitfield_width = 2,
> +};
> +
> +static struct resource irqpin_resources[] = {
> +	DEFINE_RES_MEM(0xfe78001c, 4), /* ICR1 */
> +	DEFINE_RES_MEM(0xfe780010, 4), /* INTPRI */
> +	DEFINE_RES_MEM(0xfe780024, 4), /* INTREQ */
> +	DEFINE_RES_MEM(0xfe780044, 4), /* INTMSK0 */
> +	DEFINE_RES_MEM(0xfe780064, 4), /* INTMSKCLR0 */

    Hm, why this can't be passed as a single large memory resource?

> +	DEFINE_RES_IRQ(gic_iid(0x3b)), /* IRQ0 */
> +	DEFINE_RES_IRQ(gic_iid(0x3c)), /* IRQ1 */
> +	DEFINE_RES_IRQ(gic_iid(0x3d)), /* IRQ2 */
> +	DEFINE_RES_IRQ(gic_iid(0x3e)), /* IRQ3 */
> +};
> +
> +void __init r8a7778_init_irq_extpin(int irlm)
> +{
> +	void __iomem *icr0 = ioremap_nocache(0xfe780000, PAGE_SIZE);

    4 bytes seems enough.

> +	unsigned long tmp;
> +
> +	if (!icr0) {
> +		pr_warn("r8a7778: unable to setup external irq pin mode\n");
> +		return;
> +	}
> +
> +	tmp = ioread32(icr0);
> +	if (irlm)
> +		tmp |= 1 << 23; /* IRQ0 -> IRQ3 as individual pins */
> +	else
> +		tmp &= ~(1 << 23); /* IRL mode - not supported */
> +	tmp |= (1 << 21); /* LVLMODE = 1 */

    () not needed here.

WBR, Sergei



From shawn.guo at linaro.org  Mon Apr  1 08:51:16 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Mon, 1 Apr 2013 20:51:16 +0800
Subject: ARM: dts: MicroSys sbc6x support (i.MX6)
In-Reply-To: <20130401122422.GA13982@amd.pavel.ucw.cz>
References: <20130329185500.GB30029@amd.pavel.ucw.cz>
 <20130330113703.GA21042@amd.pavel.ucw.cz>
 <5156D69E.3050600@gmail.com>
 <20130331201614.GC25751@amd.pavel.ucw.cz>
 <20130401064224.GD1693@S2101-09.ap.freescale.net>
 <20130401122422.GA13982@amd.pavel.ucw.cz>
Message-ID: <20130401125114.GA24039@S2101-09.ap.freescale.net>

On Mon, Apr 01, 2013 at 02:24:22PM +0200, Pavel Machek wrote:
> >   git://git.linaro.org/people/shawnguo/linux-2.6.git imx/dt
> 
> I took a look, and it should apply cleanly to that branch.
> 
It can apply cleanly, but it does not work, because all imx dts files
got renamed to support macros.

> Updated patch is below, please apply,

I applied it with some fixup.  Please use git send-email in the future,
so that git am can just work out everything for me.

Shawn

> 								Pavel
> 
> ---
> 
> Add support for MicroSys sbc6x board.
> 
> Signed-off-by: Pavel Machek <pavel at denx.de> 
> 
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 9c62558..1590ae9 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -99,7 +99,8 @@ dtb-$(CONFIG_ARCH_MXC) += \
>  	imx6q-arm2.dtb \
>  	imx6q-sabreauto.dtb \
>  	imx6q-sabrelite.dtb \
> -	imx6q-sabresd.dtb
> +	imx6q-sabresd.dtb \
> +	imx6q-sbc6x.dtb
>  dtb-$(CONFIG_ARCH_MXS) += imx23-evk.dtb \
>  	imx23-olinuxino.dtb \
>  	imx23-stmp378x_devb.dtb \
> diff --git a/arch/arm/boot/dts/imx6q-sbc6x.dts b/arch/arm/boot/dts/imx6q-sbc6x.dts
> new file mode 100644
> index 0000000..0b2ef5f
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx6q-sbc6x.dts
> @@ -0,0 +1,44 @@
> +/*
> + * Copyright 2013 Pavel Machek <pavel at denx.de>
> + *
> + * The code contained herein is licensed under the GNU General Public
> + * License V2.
> + */
> +
> +/dts-v1/;
> +/include/ "imx6q.dtsi"
> +
> +/ {
> +	model = "MicroSys sbc6x board";
> +	compatible = "microsys,sbc6x", "fsl,imx6q";
> +
> +	memory {
> +		reg = <0x10000000 0x80000000>;
> +	};
> +};
> +
> +&fec {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_enet_1>;
> +	phy-mode = "rgmii";
> +	status = "okay";
> +};
> +
> +&uart1 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_uart1_1>;
> +	status = "okay";
> +};
> +
> +&usbotg {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_usbotg_1>;
> +	disable-over-current;
> +	status = "okay";
> +};
> +
> +&usdhc3 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_usdhc3_2>;
> +	status = "okay";
> +};
> 
> -- 
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html



From sergei.shtylyov at cogentembedded.com  Mon Apr  1 08:50:48 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Mon, 01 Apr 2013 16:50:48 +0400
Subject: [PATCH 3/3 v2] ARM: shmobile: bockw: add SMSC ethernet support
In-Reply-To: <87bo9z56k8.wl%kuninori.morimoto.gx@renesas.com>
References: <87zjxvewko.wl%kuninori.morimoto.gx@renesas.com>
 <87fvzb56n3.wl%kuninori.morimoto.gx@renesas.com>
 <87bo9z56k8.wl%kuninori.morimoto.gx@renesas.com>
Message-ID: <515982A8.3090307@cogentembedded.com>

Hello.

On 01-04-2013 6:27, Kuninori Morimoto wrote:

> This patch adds SMSC ethernet support on Bock-W

> Bock-W SMSC needs FPGA settings which enables interrupt.
> This patch does it on bockw_init() function.
> As notes for future, this FPGA settings should be updated,
> since this FPGA is using cascaded interrupt.
> Current code is assuming that this FPGA interrupt user is only SMSC.
> Becouse of these background, this patch doesn't
> have DT settings

> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
> ---
> v1 -> v2

>   - not based on PLATFORM_INFO()

>   arch/arm/boot/dts/r8a7778-bockw.dts  |    2 +-
>   arch/arm/configs/bockw_defconfig     |   34 +++++++++++++++++++++++++++---
>   arch/arm/mach-shmobile/Kconfig       |    1 +
>   arch/arm/mach-shmobile/board-bockw.c |   38 ++++++++++++++++++++++++++++++++++
>   4 files changed, 71 insertions(+), 4 deletions(-)

> diff --git a/arch/arm/boot/dts/r8a7778-bockw.dts b/arch/arm/boot/dts/r8a7778-bockw.dts
> index 735c964..0076b1e 100644
> --- a/arch/arm/boot/dts/r8a7778-bockw.dts
> +++ b/arch/arm/boot/dts/r8a7778-bockw.dts
> @@ -22,7 +22,7 @@
>   	compatible = "renesas,bockw", "renesas,r8a7778";
>
>   	chosen {
> -		bootargs = "console=ttySC0,115200 ignore_loglevel";
> +		bootargs = "console=ttySC0,115200 ignore_loglevel ip=dhcp root=/dev/nfs";
>   	};
>
>   	memory {

    In my opinion, modifying .dts file should be done in a separate patch.

> diff --git a/arch/arm/configs/bockw_defconfig b/arch/arm/configs/bockw_defconfig
> index 6037705..6524cdf 100644
> --- a/arch/arm/configs/bockw_defconfig
> +++ b/arch/arm/configs/bockw_defconfig
> @@ -27,16 +27,40 @@ CONFIG_HIGHMEM=y
>   CONFIG_ZBOOT_ROM_TEXT=0x0
>   CONFIG_ZBOOT_ROM_BSS=0x0
>   CONFIG_ARM_APPENDED_DTB=y
> -CONFIG_CMDLINE="console=ttySC0,115200 ignore_loglevel"
> +CONFIG_CMDLINE="console=ttySC0,115200 ignore_loglevel root=/dev/nfs ip=dhcp"
>   CONFIG_CMDLINE_FORCE=y
>   # CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
>   # CONFIG_SUSPEND is not set
> +CONFIG_NET=y
> +CONFIG_UNIX=y
> +CONFIG_INET=y
> +CONFIG_IP_PNP=y
> +CONFIG_IP_PNP_DHCP=y
> +# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
> +# CONFIG_INET_XFRM_MODE_TUNNEL is not set
> +# CONFIG_INET_XFRM_MODE_BEET is not set
> +# CONFIG_INET_LRO is not set
> +# CONFIG_INET_DIAG is not set
> +# CONFIG_IPV6 is not set
>   CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
>   CONFIG_DEVTMPFS=y
>   CONFIG_DEVTMPFS_MOUNT=y
>   # CONFIG_STANDALONE is not set
>   # CONFIG_PREVENT_FIRMWARE_BUILD is not set
>   # CONFIG_FW_LOADER is not set
> +CONFIG_NETDEVICES=y
> +# CONFIG_NET_CADENCE is not set
> +# CONFIG_NET_VENDOR_BROADCOM is not set
> +# CONFIG_NET_VENDOR_CIRRUS is not set
> +# CONFIG_NET_VENDOR_FARADAY is not set
> +# CONFIG_NET_VENDOR_INTEL is not set
> +# CONFIG_NET_VENDOR_MARVELL is not set
> +# CONFIG_NET_VENDOR_MICREL is not set
> +# CONFIG_NET_VENDOR_NATSEMI is not set
> +# CONFIG_NET_VENDOR_SEEQ is not set
> +CONFIG_SMSC911X=y
> +# CONFIG_NET_VENDOR_STMICRO is not set
> +# CONFIG_NET_VENDOR_WIZNET is not set
>   # CONFIG_INPUT is not set
>   # CONFIG_SERIO is not set
>   # CONFIG_VT is not set
> @@ -55,12 +79,16 @@ CONFIG_UIO_PDRV_GENIRQ=y
>   # CONFIG_INOTIFY_USER is not set
>   CONFIG_TMPFS=y
>   # CONFIG_MISC_FILESYSTEMS is not set
> +CONFIG_NFS_FS=y
> +CONFIG_NFS_V3_ACL=y
> +CONFIG_NFS_V4=y
> +CONFIG_NFS_SWAP=y
> +CONFIG_NFS_V4_1=y
> +CONFIG_ROOT_NFS=y
>   # CONFIG_ENABLE_WARN_DEPRECATED is not set
>   # CONFIG_ENABLE_MUST_CHECK is not set
>   # CONFIG_SCHED_DEBUG is not set
>   # CONFIG_DEBUG_BUGVERBOSE is not set
>   # CONFIG_FTRACE is not set
>   # CONFIG_ARM_UNWIND is not set
> -CONFIG_KEYS=y
> -CONFIG_CRYPTO=y
>   CONFIG_AVERAGE=y

    In my opinion, modifying bockw_defconfig should be done in a separate 
patch. Mixing everything up in a signle patch is a bad practice.

WBR, Sergei



From broonie at opensource.wolfsonmicro.com  Mon Apr  1 08:57:44 2013
From: broonie at opensource.wolfsonmicro.com (Mark Brown)
Date: Mon, 1 Apr 2013 13:57:44 +0100
Subject: [PATCH V3 4/5] spi: s3c64xx: Added provision for dedicated cs pin
In-Reply-To: <1363157014-9615-5-git-send-email-ks.giri@samsung.com>
References: <1363157014-9615-1-git-send-email-ks.giri@samsung.com>
 <1363157014-9615-5-git-send-email-ks.giri@samsung.com>
Message-ID: <20130401125744.GG18636@opensource.wolfsonmicro.com>

On Wed, Mar 13, 2013 at 12:13:33PM +0530, Girish K S wrote:
> From: Girish K S <girishks2000 at gmail.com>
> 
> The existing driver supports gpio based /cs signal.
> For controller's that have one device per controller,
> the slave device's /cs signal might be internally controlled
> by the chip select bit of slave select register. They are not
> externally asserted/deasserted using gpio pin.

Applying this patch breaks my S3C64xx based system (Cragganmore, a
non-DT platform).  It'll break all existing non-DT platforms since...

> + * @cs_gpio: CS line status, 'true' if CS line is asserted by gpio.
> + * 	     'false' if asserted by internal dedicated pin.
>   * @line: Custom 'identity' of the CS line.
>   *
>   * This is per SPI-Slave Chipselect information.
> @@ -25,6 +27,7 @@ struct platform_device;
>   */
>  struct s3c64xx_spi_csinfo {
>  	u8 fb_delay;
> +	bool cs_gpio;
>  	unsigned line;
>  };

...you've added this new cs_gpio field to the platform data but not
updated any of the existing users (including Cragganmore).  It would
seem better to make the default behaviour stay as per the current
default and make the new behaviour optional but at a minimum all
existing in-tree users need to be updated.

It's also a bit odd that we end up checking cs_gpio and then using line
in the code, it'd be more idiomatic if cs_gpio were the GPIO number.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130401/68f4c154/attachment.sig>

From viresh.kumar at linaro.org  Mon Apr  1 08:57:45 2013
From: viresh.kumar at linaro.org (Viresh Kumar)
Date: Mon,  1 Apr 2013 18:27:45 +0530
Subject: [PATCH 5/9] cpufreq: Notify all policy->cpus in
 cpufreq_notify_transition()
In-Reply-To: <cover.1364820620.git.viresh.kumar@linaro.org>
References: <cover.1364820620.git.viresh.kumar@linaro.org>
Message-ID: <83bb6100646c7fdfa3ade46430200f5a3593ae03.1364820620.git.viresh.kumar@linaro.org>

policy->cpus contains all online cpus that have single shared clock line. And
their frequencies are always updated together.

Many SMP system's cpufreq drivers take care of this in individual drivers but
the best place for this code is in cpufreq core.

This patch modifies cpufreq_notify_transition() to notify frequency change for
all cpus in policy->cpus and hence updates all users of this API.

Cc: Sekhar Nori <nsekhar at ti.com>
Cc: Sascha Hauer <kernel at pengutronix.de>
Cc: Eric Miao <eric.y.miao at gmail.com>
Cc: Haojian Zhuang <haojian.zhuang at gmail.com>
Cc: Ben Dooks <ben-linux at fluff.org>
Cc: Kukjin Kim <kgene.kim at samsung.com>
Cc: Stephen Warren <swarren at wwwdotorg.org>
Cc: Haavard Skinnemoen <hskinnemoen at gmail.com>
Cc: Hans-Christian Egtvedt <egtvedt at samfundet.no>
Cc: Mike Frysinger <vapier at gentoo.org>
Cc: Mikael Starvik <starvik at axis.com>
Cc: Jesper Nilsson <jesper.nilsson at axis.com>
Cc: Tony Luck <tony.luck at intel.com>
Cc: Fenghua Yu <fenghua.yu at intel.com>
Cc: Arnd Bergmann <arnd at arndb.de>
Cc: Benjamin Herrenschmidt <benh at kernel.crashing.org>
Cc: Ralf Baechle <ralf at linux-mips.org>
Cc: Paul Mundt <lethal at linux-sh.org>
Cc: David S. Miller <davem at davemloft.net>
Cc: Thomas Renninger <trenn at suse.de>
Cc: Borislav Petkov <bp at alien8.de>
Cc: Guan Xuetao <gxt at mprc.pku.edu.cn>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-cris-kernel at axis.com
Cc: linux-ia64 at vger.kernel.org
Cc: linuxppc-dev at lists.ozlabs.org
Cc: cbe-oss-dev at lists.ozlabs.org
Cc: linux-mips at linux-mips.org
Cc: linux-sh at vger.kernel.org
Cc: sparclinux at vger.kernel.org
Cc: linux-kernel at vger.kernel.org
Signed-off-by: Viresh Kumar <viresh.kumar at linaro.org>
Acked-by: Stephen Warren <swarren at nvidia.com>
Tested-by: Stephen Warren <swarren at nvidia.com>
---
 arch/arm/mach-davinci/cpufreq.c              |  5 +-
 arch/arm/mach-imx/cpufreq.c                  |  5 +-
 arch/arm/mach-integrator/cpu.c               |  6 +--
 arch/arm/mach-pxa/cpufreq-pxa2xx.c           |  5 +-
 arch/arm/mach-pxa/cpufreq-pxa3xx.c           |  5 +-
 arch/arm/mach-s3c24xx/cpufreq.c              |  8 +--
 arch/arm/mach-sa1100/cpu-sa1100.c            |  5 +-
 arch/arm/mach-sa1100/cpu-sa1110.c            |  5 +-
 arch/arm/mach-tegra/cpu-tegra.c              | 15 +++---
 arch/avr32/mach-at32ap/cpufreq.c             |  5 +-
 arch/blackfin/mach-common/cpufreq.c          | 79 ++++++++++++----------------
 arch/cris/arch-v32/mach-a3/cpufreq.c         | 20 +++----
 arch/cris/arch-v32/mach-fs/cpufreq.c         | 17 +++---
 arch/ia64/kernel/cpufreq/acpi-cpufreq.c      | 22 ++++----
 arch/mips/kernel/cpufreq/loongson2_cpufreq.c |  5 +-
 arch/powerpc/platforms/cell/cbe_cpufreq.c    |  5 +-
 arch/powerpc/platforms/pasemi/cpufreq.c      |  5 +-
 arch/powerpc/platforms/powermac/cpufreq_32.c | 14 ++---
 arch/powerpc/platforms/powermac/cpufreq_64.c |  5 +-
 arch/sh/kernel/cpufreq.c                     |  5 +-
 arch/sparc/kernel/us2e_cpufreq.c             | 13 ++---
 arch/sparc/kernel/us3_cpufreq.c              | 13 ++---
 arch/unicore32/kernel/cpu-ucv2.c             |  5 +-
 drivers/cpufreq/acpi-cpufreq.c               | 11 +---
 drivers/cpufreq/cpufreq-cpu0.c               | 12 ++---
 drivers/cpufreq/cpufreq-nforce2.c            |  5 +-
 drivers/cpufreq/cpufreq.c                    | 45 +++++++++-------
 drivers/cpufreq/dbx500-cpufreq.c             |  6 +--
 drivers/cpufreq/e_powersaver.c               | 11 ++--
 drivers/cpufreq/elanfreq.c                   | 10 ++--
 drivers/cpufreq/exynos-cpufreq.c             |  7 +--
 drivers/cpufreq/gx-suspmod.c                 | 11 ++--
 drivers/cpufreq/imx6q-cpufreq.c              | 12 ++---
 drivers/cpufreq/kirkwood-cpufreq.c           | 10 ++--
 drivers/cpufreq/longhaul.c                   | 18 ++++---
 drivers/cpufreq/maple-cpufreq.c              |  5 +-
 drivers/cpufreq/omap-cpufreq.c               | 11 +---
 drivers/cpufreq/p4-clockmod.c                | 10 +---
 drivers/cpufreq/pcc-cpufreq.c                |  5 +-
 drivers/cpufreq/powernow-k6.c                | 12 ++---
 drivers/cpufreq/powernow-k7.c                | 10 ++--
 drivers/cpufreq/powernow-k8.c                | 16 +++---
 drivers/cpufreq/s3c2416-cpufreq.c            |  5 +-
 drivers/cpufreq/s3c64xx-cpufreq.c            |  7 ++-
 drivers/cpufreq/s5pv210-cpufreq.c            |  5 +-
 drivers/cpufreq/sc520_freq.c                 | 10 ++--
 drivers/cpufreq/spear-cpufreq.c              |  7 +--
 drivers/cpufreq/speedstep-centrino.c         | 24 ++-------
 drivers/cpufreq/speedstep-ich.c              | 12 +----
 drivers/cpufreq/speedstep-smi.c              |  5 +-
 include/linux/cpufreq.h                      |  4 +-
 51 files changed, 238 insertions(+), 340 deletions(-)

diff --git a/arch/arm/mach-davinci/cpufreq.c b/arch/arm/mach-davinci/cpufreq.c
index 4729eaa..55eb870 100644
--- a/arch/arm/mach-davinci/cpufreq.c
+++ b/arch/arm/mach-davinci/cpufreq.c
@@ -90,7 +90,6 @@ static int davinci_target(struct cpufreq_policy *policy,
 
 	freqs.old = davinci_getspeed(0);
 	freqs.new = clk_round_rate(armclk, target_freq * 1000) / 1000;
-	freqs.cpu = 0;
 
 	if (freqs.old == freqs.new)
 		return ret;
@@ -102,7 +101,7 @@ static int davinci_target(struct cpufreq_policy *policy,
 	if (ret)
 		return -EINVAL;
 
-	cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);
 
 	/* if moving to higher frequency, up the voltage beforehand */
 	if (pdata->set_voltage && freqs.new > freqs.old) {
@@ -126,7 +125,7 @@ static int davinci_target(struct cpufreq_policy *policy,
 		pdata->set_voltage(idx);
 
 out:
-	cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_POSTCHANGE);
 
 	return ret;
 }
diff --git a/arch/arm/mach-imx/cpufreq.c b/arch/arm/mach-imx/cpufreq.c
index d8c75c3..cfce5e3 100644
--- a/arch/arm/mach-imx/cpufreq.c
+++ b/arch/arm/mach-imx/cpufreq.c
@@ -87,13 +87,12 @@ static int mxc_set_target(struct cpufreq_policy *policy,
 
 	freqs.old = clk_get_rate(cpu_clk) / 1000;
 	freqs.new = freq_Hz / 1000;
-	freqs.cpu = 0;
 	freqs.flags = 0;
-	cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);
 
 	ret = set_cpu_freq(freq_Hz);
 
-	cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_POSTCHANGE);
 
 	return ret;
 }
diff --git a/arch/arm/mach-integrator/cpu.c b/arch/arm/mach-integrator/cpu.c
index 590c192..df863c3 100644
--- a/arch/arm/mach-integrator/cpu.c
+++ b/arch/arm/mach-integrator/cpu.c
@@ -123,14 +123,12 @@ static int integrator_set_target(struct cpufreq_policy *policy,
 	vco = icst_hz_to_vco(&cclk_params, target_freq * 1000);
 	freqs.new = icst_hz(&cclk_params, vco) / 1000;
 
-	freqs.cpu = policy->cpu;
-
 	if (freqs.old == freqs.new) {
 		set_cpus_allowed(current, cpus_allowed);
 		return 0;
 	}
 
-	cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);
 
 	cm_osc = __raw_readl(CM_OSC);
 
@@ -151,7 +149,7 @@ static int integrator_set_target(struct cpufreq_policy *policy,
 	 */
 	set_cpus_allowed(current, cpus_allowed);
 
-	cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_POSTCHANGE);
 
 	return 0;
 }
diff --git a/arch/arm/mach-pxa/cpufreq-pxa2xx.c b/arch/arm/mach-pxa/cpufreq-pxa2xx.c
index 6a7aeab..f1ca4da 100644
--- a/arch/arm/mach-pxa/cpufreq-pxa2xx.c
+++ b/arch/arm/mach-pxa/cpufreq-pxa2xx.c
@@ -311,7 +311,6 @@ static int pxa_set_target(struct cpufreq_policy *policy,
 	new_freq_mem = pxa_freq_settings[idx].membus;
 	freqs.old = policy->cur;
 	freqs.new = new_freq_cpu;
-	freqs.cpu = policy->cpu;
 
 	if (freq_debug)
 		pr_debug("Changing CPU frequency to %d Mhz, (SDRAM %d Mhz)\n",
@@ -327,7 +326,7 @@ static int pxa_set_target(struct cpufreq_policy *policy,
 	 * you should add a notify client with any platform specific
 	 * Vcc changing capability
 	 */
-	cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);
 
 	/* Calculate the next MDREFR.  If we're slowing down the SDRAM clock
 	 * we need to preset the smaller DRI before the change.	 If we're
@@ -382,7 +381,7 @@ static int pxa_set_target(struct cpufreq_policy *policy,
 	 * you should add a notify client with any platform specific
 	 * SDRAM refresh timer adjustments
 	 */
-	cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_POSTCHANGE);
 
 	/*
 	 * Even if voltage setting fails, we don't report it, as the frequency
diff --git a/arch/arm/mach-pxa/cpufreq-pxa3xx.c b/arch/arm/mach-pxa/cpufreq-pxa3xx.c
index b85b4ab..8c45b2b 100644
--- a/arch/arm/mach-pxa/cpufreq-pxa3xx.c
+++ b/arch/arm/mach-pxa/cpufreq-pxa3xx.c
@@ -184,7 +184,6 @@ static int pxa3xx_cpufreq_set(struct cpufreq_policy *policy,
 
 	freqs.old = policy->cur;
 	freqs.new = next->cpufreq_mhz * 1000;
-	freqs.cpu = policy->cpu;
 
 	pr_debug("CPU frequency from %d MHz to %d MHz%s\n",
 			freqs.old / 1000, freqs.new / 1000,
@@ -193,14 +192,14 @@ static int pxa3xx_cpufreq_set(struct cpufreq_policy *policy,
 	if (freqs.old == target_freq)
 		return 0;
 
-	cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);
 
 	local_irq_save(flags);
 	__update_core_freq(next);
 	__update_bus_freq(next);
 	local_irq_restore(flags);
 
-	cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_POSTCHANGE);
 
 	return 0;
 }
diff --git a/arch/arm/mach-s3c24xx/cpufreq.c b/arch/arm/mach-s3c24xx/cpufreq.c
index 5f181e7..3c0e78e 100644
--- a/arch/arm/mach-s3c24xx/cpufreq.c
+++ b/arch/arm/mach-s3c24xx/cpufreq.c
@@ -204,7 +204,6 @@ static int s3c_cpufreq_settarget(struct cpufreq_policy *policy,
 	freqs.old = cpu_cur.freq;
 	freqs.new = cpu_new.freq;
 
-	freqs.freqs.cpu = 0;
 	freqs.freqs.old = cpu_cur.freq.armclk / 1000;
 	freqs.freqs.new = cpu_new.freq.armclk / 1000;
 
@@ -218,9 +217,7 @@ static int s3c_cpufreq_settarget(struct cpufreq_policy *policy,
 	s3c_cpufreq_updateclk(clk_pclk, cpu_new.freq.pclk);
 
 	/* start the frequency change */
-
-	if (policy)
-		cpufreq_notify_transition(&freqs.freqs, CPUFREQ_PRECHANGE);
+	cpufreq_notify_transition(policy, &freqs.freqs, CPUFREQ_PRECHANGE);
 
 	/* If hclk is staying the same, then we do not need to
 	 * re-write the IO or the refresh timings whilst we are changing
@@ -264,8 +261,7 @@ static int s3c_cpufreq_settarget(struct cpufreq_policy *policy,
 	local_irq_restore(flags);
 
 	/* notify everyone we've done this */
-	if (policy)
-		cpufreq_notify_transition(&freqs.freqs, CPUFREQ_POSTCHANGE);
+	cpufreq_notify_transition(policy, &freqs.freqs, CPUFREQ_POSTCHANGE);
 
 	s3c_freq_dbg("%s: finished\n", __func__);
 	return 0;
diff --git a/arch/arm/mach-sa1100/cpu-sa1100.c b/arch/arm/mach-sa1100/cpu-sa1100.c
index e8f4d1e..3268761 100644
--- a/arch/arm/mach-sa1100/cpu-sa1100.c
+++ b/arch/arm/mach-sa1100/cpu-sa1100.c
@@ -201,9 +201,8 @@ static int sa1100_target(struct cpufreq_policy *policy,
 
 	freqs.old = cur;
 	freqs.new = sa11x0_ppcr_to_freq(new_ppcr);
-	freqs.cpu = 0;
 
-	cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);
 
 	if (freqs.new > cur)
 		sa1100_update_dram_timings(cur, freqs.new);
@@ -213,7 +212,7 @@ static int sa1100_target(struct cpufreq_policy *policy,
 	if (freqs.new < cur)
 		sa1100_update_dram_timings(cur, freqs.new);
 
-	cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_POSTCHANGE);
 
 	return 0;
 }
diff --git a/arch/arm/mach-sa1100/cpu-sa1110.c b/arch/arm/mach-sa1100/cpu-sa1110.c
index 48c45b0..38a7733 100644
--- a/arch/arm/mach-sa1100/cpu-sa1110.c
+++ b/arch/arm/mach-sa1100/cpu-sa1110.c
@@ -258,7 +258,6 @@ static int sa1110_target(struct cpufreq_policy *policy,
 
 	freqs.old = sa11x0_getspeed(0);
 	freqs.new = sa11x0_ppcr_to_freq(ppcr);
-	freqs.cpu = 0;
 
 	sdram_calculate_timing(&sd, freqs.new, sdram);
 
@@ -279,7 +278,7 @@ static int sa1110_target(struct cpufreq_policy *policy,
 	sd.mdcas[2] = 0xaaaaaaaa;
 #endif
 
-	cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);
 
 	/*
 	 * The clock could be going away for some time.  Set the SDRAMs
@@ -327,7 +326,7 @@ static int sa1110_target(struct cpufreq_policy *policy,
 	 */
 	sdram_update_refresh(freqs.new, sdram);
 
-	cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_POSTCHANGE);
 
 	return 0;
 }
diff --git a/arch/arm/mach-tegra/cpu-tegra.c b/arch/arm/mach-tegra/cpu-tegra.c
index e3d6e15..11ca730 100644
--- a/arch/arm/mach-tegra/cpu-tegra.c
+++ b/arch/arm/mach-tegra/cpu-tegra.c
@@ -106,7 +106,8 @@ out:
 	return ret;
 }
 
-static int tegra_update_cpu_speed(unsigned long rate)
+static int tegra_update_cpu_speed(struct cpufreq_policy *policy,
+		unsigned long rate)
 {
 	int ret = 0;
 	struct cpufreq_freqs freqs;
@@ -128,8 +129,7 @@ static int tegra_update_cpu_speed(unsigned long rate)
 	else
 		clk_set_rate(emc_clk, 100000000);  /* emc 50Mhz */
 
-	for_each_online_cpu(freqs.cpu)
-		cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);
 
 #ifdef CONFIG_CPU_FREQ_DEBUG
 	printk(KERN_DEBUG "cpufreq-tegra: transition: %u --> %u\n",
@@ -143,8 +143,7 @@ static int tegra_update_cpu_speed(unsigned long rate)
 		return ret;
 	}
 
-	for_each_online_cpu(freqs.cpu)
-		cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_POSTCHANGE);
 
 	return 0;
 }
@@ -181,7 +180,7 @@ static int tegra_target(struct cpufreq_policy *policy,
 
 	target_cpu_speed[policy->cpu] = freq;
 
-	ret = tegra_update_cpu_speed(tegra_cpu_highest_speed());
+	ret = tegra_update_cpu_speed(policy, tegra_cpu_highest_speed());
 
 out:
 	mutex_unlock(&tegra_cpu_lock);
@@ -193,10 +192,12 @@ static int tegra_pm_notify(struct notifier_block *nb, unsigned long event,
 {
 	mutex_lock(&tegra_cpu_lock);
 	if (event == PM_SUSPEND_PREPARE) {
+		struct cpufreq_policy *policy = cpufreq_cpu_get(0);
 		is_suspended = true;
 		pr_info("Tegra cpufreq suspend: setting frequency to %d kHz\n",
 			freq_table[0].frequency);
-		tegra_update_cpu_speed(freq_table[0].frequency);
+		tegra_update_cpu_speed(policy, freq_table[0].frequency);
+		cpufreq_cpu_put(policy);
 	} else if (event == PM_POST_SUSPEND) {
 		is_suspended = false;
 	}
diff --git a/arch/avr32/mach-at32ap/cpufreq.c b/arch/avr32/mach-at32ap/cpufreq.c
index 18b7656..6544887 100644
--- a/arch/avr32/mach-at32ap/cpufreq.c
+++ b/arch/avr32/mach-at32ap/cpufreq.c
@@ -61,7 +61,6 @@ static int at32_set_target(struct cpufreq_policy *policy,
 
 	freqs.old = at32_get_speed(0);
 	freqs.new = (freq + 500) / 1000;
-	freqs.cpu = 0;
 	freqs.flags = 0;
 
 	if (!ref_freq) {
@@ -69,7 +68,7 @@ static int at32_set_target(struct cpufreq_policy *policy,
 		loops_per_jiffy_ref = boot_cpu_data.loops_per_jiffy;
 	}
 
-	cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);
 	if (freqs.old < freqs.new)
 		boot_cpu_data.loops_per_jiffy = cpufreq_scale(
 				loops_per_jiffy_ref, ref_freq, freqs.new);
@@ -77,7 +76,7 @@ static int at32_set_target(struct cpufreq_policy *policy,
 	if (freqs.new < freqs.old)
 		boot_cpu_data.loops_per_jiffy = cpufreq_scale(
 				loops_per_jiffy_ref, ref_freq, freqs.new);
-	cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_POSTCHANGE);
 
 	pr_debug("cpufreq: set frequency %lu Hz\n", freq);
 
diff --git a/arch/blackfin/mach-common/cpufreq.c b/arch/blackfin/mach-common/cpufreq.c
index d88bd31..995511e80 100644
--- a/arch/blackfin/mach-common/cpufreq.c
+++ b/arch/blackfin/mach-common/cpufreq.c
@@ -127,13 +127,13 @@ unsigned long cpu_set_cclk(int cpu, unsigned long new)
 }
 #endif
 
-static int bfin_target(struct cpufreq_policy *poli,
+static int bfin_target(struct cpufreq_policy *policy,
 			unsigned int target_freq, unsigned int relation)
 {
 #ifndef CONFIG_BF60x
 	unsigned int plldiv;
 #endif
-	unsigned int index, cpu;
+	unsigned int index;
 	unsigned long cclk_hz;
 	struct cpufreq_freqs freqs;
 	static unsigned long lpj_ref;
@@ -144,59 +144,48 @@ static int bfin_target(struct cpufreq_policy *poli,
 	cycles_t cycles;
 #endif
 
-	for_each_online_cpu(cpu) {
-		struct cpufreq_policy *policy = cpufreq_cpu_get(cpu);
+	if (cpufreq_frequency_table_target(policy, bfin_freq_table, target_freq,
+				relation, &index))
+		return -EINVAL;
 
-		if (!policy)
-			continue;
+	cclk_hz = bfin_freq_table[index].frequency;
 
-		if (cpufreq_frequency_table_target(policy, bfin_freq_table,
-				 target_freq, relation, &index))
-			return -EINVAL;
+	freqs.old = bfin_getfreq_khz(0);
+	freqs.new = cclk_hz;
 
-		cclk_hz = bfin_freq_table[index].frequency;
+	pr_debug("cpufreq: changing cclk to %lu; target = %u, oldfreq = %u\n",
+			cclk_hz, target_freq, freqs.old);
 
-		freqs.old = bfin_getfreq_khz(0);
-		freqs.new = cclk_hz;
-		freqs.cpu = cpu;
-
-		pr_debug("cpufreq: changing cclk to %lu; target = %u, oldfreq = %u\n",
-			 cclk_hz, target_freq, freqs.old);
-
-		cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
-		if (cpu == CPUFREQ_CPU) {
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);
 #ifndef CONFIG_BF60x
-			plldiv = (bfin_read_PLL_DIV() & SSEL) |
-						dpm_state_table[index].csel;
-			bfin_write_PLL_DIV(plldiv);
+	plldiv = (bfin_read_PLL_DIV() & SSEL) | dpm_state_table[index].csel;
+	bfin_write_PLL_DIV(plldiv);
 #else
-			ret = cpu_set_cclk(cpu, freqs.new * 1000);
-			if (ret != 0) {
-				WARN_ONCE(ret, "cpufreq set freq failed %d\n", ret);
-				break;
-			}
+	ret = cpu_set_cclk(policy->cpu, freqs.new * 1000);
+	if (ret != 0) {
+		WARN_ONCE(ret, "cpufreq set freq failed %d\n", ret);
+		return ret;
+	}
 #endif
-			on_each_cpu(bfin_adjust_core_timer, &index, 1);
+	on_each_cpu(bfin_adjust_core_timer, &index, 1);
 #if defined(CONFIG_CYCLES_CLOCKSOURCE)
-			cycles = get_cycles();
-			SSYNC();
-			cycles += 10; /* ~10 cycles we lose after get_cycles() */
-			__bfin_cycles_off +=
-			    (cycles << __bfin_cycles_mod) - (cycles << index);
-			__bfin_cycles_mod = index;
+	cycles = get_cycles();
+	SSYNC();
+	cycles += 10; /* ~10 cycles we lose after get_cycles() */
+	__bfin_cycles_off += (cycles << __bfin_cycles_mod) - (cycles << index);
+	__bfin_cycles_mod = index;
 #endif
-			if (!lpj_ref_freq) {
-				lpj_ref = loops_per_jiffy;
-				lpj_ref_freq = freqs.old;
-			}
-			if (freqs.new != freqs.old) {
-				loops_per_jiffy = cpufreq_scale(lpj_ref,
-						lpj_ref_freq, freqs.new);
-			}
-		}
-		/* TODO: just test case for cycles clock source, remove later */
-		cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
+	if (!lpj_ref_freq) {
+		lpj_ref = loops_per_jiffy;
+		lpj_ref_freq = freqs.old;
 	}
+	if (freqs.new != freqs.old) {
+		loops_per_jiffy = cpufreq_scale(lpj_ref,
+				lpj_ref_freq, freqs.new);
+	}
+
+	/* TODO: just test case for cycles clock source, remove later */
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_POSTCHANGE);
 
 	pr_debug("cpufreq: done\n");
 	return ret;
diff --git a/arch/cris/arch-v32/mach-a3/cpufreq.c b/arch/cris/arch-v32/mach-a3/cpufreq.c
index ee391ec..ee142c4 100644
--- a/arch/cris/arch-v32/mach-a3/cpufreq.c
+++ b/arch/cris/arch-v32/mach-a3/cpufreq.c
@@ -27,23 +27,17 @@ static unsigned int cris_freq_get_cpu_frequency(unsigned int cpu)
 	return clk_ctrl.pll ? 200000 : 6000;
 }
 
-static void cris_freq_set_cpu_state(unsigned int state)
+static void cris_freq_set_cpu_state(struct cpufreq_policy *policy,
+		unsigned int state)
 {
-	int i = 0;
 	struct cpufreq_freqs freqs;
 	reg_clkgen_rw_clk_ctrl clk_ctrl;
 	clk_ctrl = REG_RD(clkgen, regi_clkgen, rw_clk_ctrl);
 
-#ifdef CONFIG_SMP
-	for_each_present_cpu(i)
-#endif
-	{
-		freqs.old = cris_freq_get_cpu_frequency(i);
-		freqs.new = cris_freq_table[state].frequency;
-		freqs.cpu = i;
-	}
+	freqs.old = cris_freq_get_cpu_frequency(policy->cpu);
+	freqs.new = cris_freq_table[state].frequency;
 
-	cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);
 
 	local_irq_disable();
 
@@ -57,7 +51,7 @@ static void cris_freq_set_cpu_state(unsigned int state)
 
 	local_irq_enable();
 
-	cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_POSTCHANGE);
 };
 
 static int cris_freq_verify(struct cpufreq_policy *policy)
@@ -75,7 +69,7 @@ static int cris_freq_target(struct cpufreq_policy *policy,
 			target_freq, relation, &newstate))
 		return -EINVAL;
 
-	cris_freq_set_cpu_state(newstate);
+	cris_freq_set_cpu_state(policy, newstate);
 
 	return 0;
 }
diff --git a/arch/cris/arch-v32/mach-fs/cpufreq.c b/arch/cris/arch-v32/mach-fs/cpufreq.c
index d92cf70..1295223 100644
--- a/arch/cris/arch-v32/mach-fs/cpufreq.c
+++ b/arch/cris/arch-v32/mach-fs/cpufreq.c
@@ -27,20 +27,17 @@ static unsigned int cris_freq_get_cpu_frequency(unsigned int cpu)
 	return clk_ctrl.pll ? 200000 : 6000;
 }
 
-static void cris_freq_set_cpu_state(unsigned int state)
+static void cris_freq_set_cpu_state(struct cpufreq_policy *policy,
+		unsigned int state)
 {
-	int i;
 	struct cpufreq_freqs freqs;
 	reg_config_rw_clk_ctrl clk_ctrl;
 	clk_ctrl = REG_RD(config, regi_config, rw_clk_ctrl);
 
-	for_each_possible_cpu(i) {
-		freqs.old = cris_freq_get_cpu_frequency(i);
-		freqs.new = cris_freq_table[state].frequency;
-		freqs.cpu = i;
-	}
+	freqs.old = cris_freq_get_cpu_frequency(policy->cpu);
+	freqs.new = cris_freq_table[state].frequency;
 
-	cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);
 
 	local_irq_disable();
 
@@ -54,7 +51,7 @@ static void cris_freq_set_cpu_state(unsigned int state)
 
 	local_irq_enable();
 
-	cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_POSTCHANGE);
 };
 
 static int cris_freq_verify(struct cpufreq_policy *policy)
@@ -71,7 +68,7 @@ static int cris_freq_target(struct cpufreq_policy *policy,
 	    (policy, cris_freq_table, target_freq, relation, &newstate))
 		return -EINVAL;
 
-	cris_freq_set_cpu_state(newstate);
+	cris_freq_set_cpu_state(policy, newstate);
 
 	return 0;
 }
diff --git a/arch/ia64/kernel/cpufreq/acpi-cpufreq.c b/arch/ia64/kernel/cpufreq/acpi-cpufreq.c
index f09b174..4700fef 100644
--- a/arch/ia64/kernel/cpufreq/acpi-cpufreq.c
+++ b/arch/ia64/kernel/cpufreq/acpi-cpufreq.c
@@ -137,7 +137,7 @@ migrate_end:
 static int
 processor_set_freq (
 	struct cpufreq_acpi_io	*data,
-	unsigned int		cpu,
+	struct cpufreq_policy   *policy,
 	int			state)
 {
 	int			ret = 0;
@@ -149,8 +149,8 @@ processor_set_freq (
 	pr_debug("processor_set_freq\n");
 
 	saved_mask = current->cpus_allowed;
-	set_cpus_allowed_ptr(current, cpumask_of(cpu));
-	if (smp_processor_id() != cpu) {
+	set_cpus_allowed_ptr(current, cpumask_of(policy->cpu));
+	if (smp_processor_id() != policy->cpu) {
 		retval = -EAGAIN;
 		goto migrate_end;
 	}
@@ -170,12 +170,11 @@ processor_set_freq (
 		data->acpi_data.state, state);
 
 	/* cpufreq frequency struct */
-	cpufreq_freqs.cpu = cpu;
 	cpufreq_freqs.old = data->freq_table[data->acpi_data.state].frequency;
 	cpufreq_freqs.new = data->freq_table[state].frequency;
 
 	/* notify cpufreq */
-	cpufreq_notify_transition(&cpufreq_freqs, CPUFREQ_PRECHANGE);
+	cpufreq_notify_transition(policy, &cpufreq_freqs, CPUFREQ_PRECHANGE);
 
 	/*
 	 * First we write the target state's 'control' value to the
@@ -189,17 +188,20 @@ processor_set_freq (
 	ret = processor_set_pstate(value);
 	if (ret) {
 		unsigned int tmp = cpufreq_freqs.new;
-		cpufreq_notify_transition(&cpufreq_freqs, CPUFREQ_POSTCHANGE);
+		cpufreq_notify_transition(policy, &cpufreq_freqs,
+				CPUFREQ_POSTCHANGE);
 		cpufreq_freqs.new = cpufreq_freqs.old;
 		cpufreq_freqs.old = tmp;
-		cpufreq_notify_transition(&cpufreq_freqs, CPUFREQ_PRECHANGE);
-		cpufreq_notify_transition(&cpufreq_freqs, CPUFREQ_POSTCHANGE);
+		cpufreq_notify_transition(policy, &cpufreq_freqs,
+				CPUFREQ_PRECHANGE);
+		cpufreq_notify_transition(policy, &cpufreq_freqs,
+				CPUFREQ_POSTCHANGE);
 		printk(KERN_WARNING "Transition failed with error %d\n", ret);
 		retval = -ENODEV;
 		goto migrate_end;
 	}
 
-	cpufreq_notify_transition(&cpufreq_freqs, CPUFREQ_POSTCHANGE);
+	cpufreq_notify_transition(policy, &cpufreq_freqs, CPUFREQ_POSTCHANGE);
 
 	data->acpi_data.state = state;
 
@@ -240,7 +242,7 @@ acpi_cpufreq_target (
 	if (result)
 		return (result);
 
-	result = processor_set_freq(data, policy->cpu, next_state);
+	result = processor_set_freq(data, policy, next_state);
 
 	return (result);
 }
diff --git a/arch/mips/kernel/cpufreq/loongson2_cpufreq.c b/arch/mips/kernel/cpufreq/loongson2_cpufreq.c
index 3237c52..bafda70 100644
--- a/arch/mips/kernel/cpufreq/loongson2_cpufreq.c
+++ b/arch/mips/kernel/cpufreq/loongson2_cpufreq.c
@@ -80,7 +80,6 @@ static int loongson2_cpufreq_target(struct cpufreq_policy *policy,
 
 	pr_debug("cpufreq: requested frequency %u Hz\n", target_freq * 1000);
 
-	freqs.cpu = cpu;
 	freqs.old = loongson2_cpufreq_get(cpu);
 	freqs.new = freq;
 	freqs.flags = 0;
@@ -89,7 +88,7 @@ static int loongson2_cpufreq_target(struct cpufreq_policy *policy,
 		return 0;
 
 	/* notifiers */
-	cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);
 
 	set_cpus_allowed_ptr(current, &cpus_allowed);
 
@@ -97,7 +96,7 @@ static int loongson2_cpufreq_target(struct cpufreq_policy *policy,
 	clk_set_rate(cpuclk, freq);
 
 	/* notifiers */
-	cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_POSTCHANGE);
 
 	pr_debug("cpufreq: set frequency %u kHz\n", freq);
 
diff --git a/arch/powerpc/platforms/cell/cbe_cpufreq.c b/arch/powerpc/platforms/cell/cbe_cpufreq.c
index d4c39e3..718c6a3 100644
--- a/arch/powerpc/platforms/cell/cbe_cpufreq.c
+++ b/arch/powerpc/platforms/cell/cbe_cpufreq.c
@@ -156,10 +156,9 @@ static int cbe_cpufreq_target(struct cpufreq_policy *policy,
 
 	freqs.old = policy->cur;
 	freqs.new = cbe_freqs[cbe_pmode_new].frequency;
-	freqs.cpu = policy->cpu;
 
 	mutex_lock(&cbe_switch_mutex);
-	cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);
 
 	pr_debug("setting frequency for cpu %d to %d kHz, " \
 		 "1/%d of max frequency\n",
@@ -169,7 +168,7 @@ static int cbe_cpufreq_target(struct cpufreq_policy *policy,
 
 	rc = set_pmode(policy->cpu, cbe_pmode_new);
 
-	cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_POSTCHANGE);
 	mutex_unlock(&cbe_switch_mutex);
 
 	return rc;
diff --git a/arch/powerpc/platforms/pasemi/cpufreq.c b/arch/powerpc/platforms/pasemi/cpufreq.c
index 890f30e..be1e795 100644
--- a/arch/powerpc/platforms/pasemi/cpufreq.c
+++ b/arch/powerpc/platforms/pasemi/cpufreq.c
@@ -273,10 +273,9 @@ static int pas_cpufreq_target(struct cpufreq_policy *policy,
 
 	freqs.old = policy->cur;
 	freqs.new = pas_freqs[pas_astate_new].frequency;
-	freqs.cpu = policy->cpu;
 
 	mutex_lock(&pas_switch_mutex);
-	cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);
 
 	pr_debug("setting frequency for cpu %d to %d kHz, 1/%d of max frequency\n",
 		 policy->cpu,
@@ -288,7 +287,7 @@ static int pas_cpufreq_target(struct cpufreq_policy *policy,
 	for_each_online_cpu(i)
 		set_astate(i, pas_astate_new);
 
-	cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_POSTCHANGE);
 	mutex_unlock(&pas_switch_mutex);
 
 	ppc_proc_freq = freqs.new * 1000ul;
diff --git a/arch/powerpc/platforms/powermac/cpufreq_32.c b/arch/powerpc/platforms/powermac/cpufreq_32.c
index 311b804..3104fad 100644
--- a/arch/powerpc/platforms/powermac/cpufreq_32.c
+++ b/arch/powerpc/platforms/powermac/cpufreq_32.c
@@ -335,7 +335,8 @@ static int pmu_set_cpu_speed(int low_speed)
 	return 0;
 }
 
-static int do_set_cpu_speed(int speed_mode, int notify)
+static int do_set_cpu_speed(struct cpufreq_policy *policy, int speed_mode,
+		int notify)
 {
 	struct cpufreq_freqs freqs;
 	unsigned long l3cr;
@@ -343,13 +344,12 @@ static int do_set_cpu_speed(int speed_mode, int notify)
 
 	freqs.old = cur_freq;
 	freqs.new = (speed_mode == CPUFREQ_HIGH) ? hi_freq : low_freq;
-	freqs.cpu = smp_processor_id();
 
 	if (freqs.old == freqs.new)
 		return 0;
 
 	if (notify)
-		cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
+		cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);
 	if (speed_mode == CPUFREQ_LOW &&
 	    cpu_has_feature(CPU_FTR_L3CR)) {
 		l3cr = _get_L3CR();
@@ -366,7 +366,7 @@ static int do_set_cpu_speed(int speed_mode, int notify)
 			_set_L3CR(prev_l3cr);
 	}
 	if (notify)
-		cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
+		cpufreq_notify_transition(policy, &freqs, CPUFREQ_POSTCHANGE);
 	cur_freq = (speed_mode == CPUFREQ_HIGH) ? hi_freq : low_freq;
 
 	return 0;
@@ -393,7 +393,7 @@ static int pmac_cpufreq_target(	struct cpufreq_policy *policy,
 			target_freq, relation, &newstate))
 		return -EINVAL;
 
-	rc = do_set_cpu_speed(newstate, 1);
+	rc = do_set_cpu_speed(policy, newstate, 1);
 
 	ppc_proc_freq = cur_freq * 1000ul;
 	return rc;
@@ -442,7 +442,7 @@ static int pmac_cpufreq_suspend(struct cpufreq_policy *policy)
 	no_schedule = 1;
 	sleep_freq = cur_freq;
 	if (cur_freq == low_freq && !is_pmu_based)
-		do_set_cpu_speed(CPUFREQ_HIGH, 0);
+		do_set_cpu_speed(policy, CPUFREQ_HIGH, 0);
 	return 0;
 }
 
@@ -458,7 +458,7 @@ static int pmac_cpufreq_resume(struct cpufreq_policy *policy)
 	 * is that we force a switch to whatever it was, which is
 	 * probably high speed due to our suspend() routine
 	 */
-	do_set_cpu_speed(sleep_freq == low_freq ?
+	do_set_cpu_speed(policy, sleep_freq == low_freq ?
 			 CPUFREQ_LOW : CPUFREQ_HIGH, 0);
 
 	ppc_proc_freq = cur_freq * 1000ul;
diff --git a/arch/powerpc/platforms/powermac/cpufreq_64.c b/arch/powerpc/platforms/powermac/cpufreq_64.c
index 9650c60..7ba4234 100644
--- a/arch/powerpc/platforms/powermac/cpufreq_64.c
+++ b/arch/powerpc/platforms/powermac/cpufreq_64.c
@@ -339,11 +339,10 @@ static int g5_cpufreq_target(struct cpufreq_policy *policy,
 
 	freqs.old = g5_cpu_freqs[g5_pmode_cur].frequency;
 	freqs.new = g5_cpu_freqs[newstate].frequency;
-	freqs.cpu = 0;
 
-	cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);
 	rc = g5_switch_freq(newstate);
-	cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_POSTCHANGE);
 
 	mutex_unlock(&g5_switch_mutex);
 
diff --git a/arch/sh/kernel/cpufreq.c b/arch/sh/kernel/cpufreq.c
index e68b45b..2c7bd94 100644
--- a/arch/sh/kernel/cpufreq.c
+++ b/arch/sh/kernel/cpufreq.c
@@ -69,15 +69,14 @@ static int sh_cpufreq_target(struct cpufreq_policy *policy,
 
 	dev_dbg(dev, "requested frequency %u Hz\n", target_freq * 1000);
 
-	freqs.cpu	= cpu;
 	freqs.old	= sh_cpufreq_get(cpu);
 	freqs.new	= (freq + 500) / 1000;
 	freqs.flags	= 0;
 
-	cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);
 	set_cpus_allowed_ptr(current, &cpus_allowed);
 	clk_set_rate(cpuclk, freq);
-	cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_POSTCHANGE);
 
 	dev_dbg(dev, "set frequency %lu Hz\n", freq);
 
diff --git a/arch/sparc/kernel/us2e_cpufreq.c b/arch/sparc/kernel/us2e_cpufreq.c
index 489fc15..abe963d 100644
--- a/arch/sparc/kernel/us2e_cpufreq.c
+++ b/arch/sparc/kernel/us2e_cpufreq.c
@@ -248,8 +248,10 @@ static unsigned int us2e_freq_get(unsigned int cpu)
 	return clock_tick / estar_to_divisor(estar);
 }
 
-static void us2e_set_cpu_divider_index(unsigned int cpu, unsigned int index)
+static void us2e_set_cpu_divider_index(struct cpufreq_policy *policy,
+		unsigned int index)
 {
+	unsigned int cpu = policy->cpu;
 	unsigned long new_bits, new_freq;
 	unsigned long clock_tick, divisor, old_divisor, estar;
 	cpumask_t cpus_allowed;
@@ -272,14 +274,13 @@ static void us2e_set_cpu_divider_index(unsigned int cpu, unsigned int index)
 
 	freqs.old = clock_tick / old_divisor;
 	freqs.new = new_freq;
-	freqs.cpu = cpu;
-	cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);
 
 	if (old_divisor != divisor)
 		us2e_transition(estar, new_bits, clock_tick * 1000,
 				old_divisor, divisor);
 
-	cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_POSTCHANGE);
 
 	set_cpus_allowed_ptr(current, &cpus_allowed);
 }
@@ -295,7 +296,7 @@ static int us2e_freq_target(struct cpufreq_policy *policy,
 					   target_freq, relation, &new_index))
 		return -EINVAL;
 
-	us2e_set_cpu_divider_index(policy->cpu, new_index);
+	us2e_set_cpu_divider_index(policy, new_index);
 
 	return 0;
 }
@@ -335,7 +336,7 @@ static int __init us2e_freq_cpu_init(struct cpufreq_policy *policy)
 static int us2e_freq_cpu_exit(struct cpufreq_policy *policy)
 {
 	if (cpufreq_us2e_driver)
-		us2e_set_cpu_divider_index(policy->cpu, 0);
+		us2e_set_cpu_divider_index(policy, 0);
 
 	return 0;
 }
diff --git a/arch/sparc/kernel/us3_cpufreq.c b/arch/sparc/kernel/us3_cpufreq.c
index eb1624b..7ceb9c8 100644
--- a/arch/sparc/kernel/us3_cpufreq.c
+++ b/arch/sparc/kernel/us3_cpufreq.c
@@ -96,8 +96,10 @@ static unsigned int us3_freq_get(unsigned int cpu)
 	return ret;
 }
 
-static void us3_set_cpu_divider_index(unsigned int cpu, unsigned int index)
+static void us3_set_cpu_divider_index(struct cpufreq_policy *policy,
+		unsigned int index)
 {
+	unsigned int cpu = policy->cpu;
 	unsigned long new_bits, new_freq, reg;
 	cpumask_t cpus_allowed;
 	struct cpufreq_freqs freqs;
@@ -131,14 +133,13 @@ static void us3_set_cpu_divider_index(unsigned int cpu, unsigned int index)
 
 	freqs.old = get_current_freq(cpu, reg);
 	freqs.new = new_freq;
-	freqs.cpu = cpu;
-	cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);
 
 	reg &= ~SAFARI_CFG_DIV_MASK;
 	reg |= new_bits;
 	write_safari_cfg(reg);
 
-	cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_POSTCHANGE);
 
 	set_cpus_allowed_ptr(current, &cpus_allowed);
 }
@@ -156,7 +157,7 @@ static int us3_freq_target(struct cpufreq_policy *policy,
 					   &new_index))
 		return -EINVAL;
 
-	us3_set_cpu_divider_index(policy->cpu, new_index);
+	us3_set_cpu_divider_index(policy, new_index);
 
 	return 0;
 }
@@ -192,7 +193,7 @@ static int __init us3_freq_cpu_init(struct cpufreq_policy *policy)
 static int us3_freq_cpu_exit(struct cpufreq_policy *policy)
 {
 	if (cpufreq_us3_driver)
-		us3_set_cpu_divider_index(policy->cpu, 0);
+		us3_set_cpu_divider_index(policy, 0);
 
 	return 0;
 }
diff --git a/arch/unicore32/kernel/cpu-ucv2.c b/arch/unicore32/kernel/cpu-ucv2.c
index 4a99f62..ba5a71c 100644
--- a/arch/unicore32/kernel/cpu-ucv2.c
+++ b/arch/unicore32/kernel/cpu-ucv2.c
@@ -52,15 +52,14 @@ static int ucv2_target(struct cpufreq_policy *policy,
 	struct cpufreq_freqs freqs;
 	struct clk *mclk = clk_get(NULL, "MAIN_CLK");
 
-	cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);
 
 	if (!clk_set_rate(mclk, target_freq * 1000)) {
 		freqs.old = cur;
 		freqs.new = target_freq;
-		freqs.cpu = 0;
 	}
 
-	cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_POSTCHANGE);
 
 	return 0;
 }
diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
index 57a8774..11b8b4b 100644
--- a/drivers/cpufreq/acpi-cpufreq.c
+++ b/drivers/cpufreq/acpi-cpufreq.c
@@ -423,7 +423,6 @@ static int acpi_cpufreq_target(struct cpufreq_policy *policy,
 	struct drv_cmd cmd;
 	unsigned int next_state = 0; /* Index into freq_table */
 	unsigned int next_perf_state = 0; /* Index into perf table */
-	unsigned int i;
 	int result = 0;
 
 	pr_debug("acpi_cpufreq_target %d (%d)\n", target_freq, policy->cpu);
@@ -486,10 +485,7 @@ static int acpi_cpufreq_target(struct cpufreq_policy *policy,
 
 	freqs.old = perf->states[perf->state].core_frequency * 1000;
 	freqs.new = data->freq_table[next_state].frequency;
-	for_each_cpu(i, policy->cpus) {
-		freqs.cpu = i;
-		cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
-	}
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);
 
 	drv_write(&cmd);
 
@@ -502,10 +498,7 @@ static int acpi_cpufreq_target(struct cpufreq_policy *policy,
 		}
 	}
 
-	for_each_cpu(i, policy->cpus) {
-		freqs.cpu = i;
-		cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
-	}
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_POSTCHANGE);
 	perf->state = next_perf_state;
 
 out:
diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c
index a7e51bd..6561853 100644
--- a/drivers/cpufreq/cpufreq-cpu0.c
+++ b/drivers/cpufreq/cpufreq-cpu0.c
@@ -46,7 +46,7 @@ static int cpu0_set_target(struct cpufreq_policy *policy,
 	struct opp *opp;
 	unsigned long volt = 0, volt_old = 0, tol = 0;
 	long freq_Hz;
-	unsigned int index, cpu;
+	unsigned int index;
 	int ret;
 
 	ret = cpufreq_frequency_table_target(policy, freq_table, target_freq,
@@ -66,10 +66,7 @@ static int cpu0_set_target(struct cpufreq_policy *policy,
 	if (freqs.old == freqs.new)
 		return 0;
 
-	for_each_online_cpu(cpu) {
-		freqs.cpu = cpu;
-		cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
-	}
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);
 
 	if (cpu_reg) {
 		rcu_read_lock();
@@ -121,10 +118,7 @@ static int cpu0_set_target(struct cpufreq_policy *policy,
 	}
 
 post_notify:
-	for_each_online_cpu(cpu) {
-		freqs.cpu = cpu;
-		cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
-	}
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_POSTCHANGE);
 
 	return ret;
 }
diff --git a/drivers/cpufreq/cpufreq-nforce2.c b/drivers/cpufreq/cpufreq-nforce2.c
index 13d311e..224a478 100644
--- a/drivers/cpufreq/cpufreq-nforce2.c
+++ b/drivers/cpufreq/cpufreq-nforce2.c
@@ -263,7 +263,6 @@ static int nforce2_target(struct cpufreq_policy *policy,
 
 	freqs.old = nforce2_get(policy->cpu);
 	freqs.new = target_fsb * fid * 100;
-	freqs.cpu = 0;		/* Only one CPU on nForce2 platforms */
 
 	if (freqs.old == freqs.new)
 		return 0;
@@ -271,7 +270,7 @@ static int nforce2_target(struct cpufreq_policy *policy,
 	pr_debug("Old CPU frequency %d kHz, new %d kHz\n",
 	       freqs.old, freqs.new);
 
-	cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);
 
 	/* Disable IRQs */
 	/* local_irq_save(flags); */
@@ -286,7 +285,7 @@ static int nforce2_target(struct cpufreq_policy *policy,
 	/* Enable IRQs */
 	/* local_irq_restore(flags); */
 
-	cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_POSTCHANGE);
 
 	return 0;
 }
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 85963fc..0198cd0 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -249,19 +249,9 @@ static inline void adjust_jiffies(unsigned long val, struct cpufreq_freqs *ci)
 #endif
 
 
-/**
- * cpufreq_notify_transition - call notifier chain and adjust_jiffies
- * on frequency transition.
- *
- * This function calls the transition notifiers and the "adjust_jiffies"
- * function. It is called twice on all CPU frequency changes that have
- * external effects.
- */
-void cpufreq_notify_transition(struct cpufreq_freqs *freqs, unsigned int state)
+void __cpufreq_notify_transition(struct cpufreq_policy *policy,
+		struct cpufreq_freqs *freqs, unsigned int state)
 {
-	struct cpufreq_policy *policy;
-	unsigned long flags;
-
 	BUG_ON(irqs_disabled());
 
 	if (cpufreq_disabled())
@@ -271,10 +261,6 @@ void cpufreq_notify_transition(struct cpufreq_freqs *freqs, unsigned int state)
 	pr_debug("notification %u of frequency transition to %u kHz\n",
 		state, freqs->new);
 
-	read_lock_irqsave(&cpufreq_driver_lock, flags);
-	policy = per_cpu(cpufreq_cpu_data, freqs->cpu);
-	read_unlock_irqrestore(&cpufreq_driver_lock, flags);
-
 	switch (state) {
 
 	case CPUFREQ_PRECHANGE:
@@ -308,6 +294,20 @@ void cpufreq_notify_transition(struct cpufreq_freqs *freqs, unsigned int state)
 		break;
 	}
 }
+/**
+ * cpufreq_notify_transition - call notifier chain and adjust_jiffies
+ * on frequency transition.
+ *
+ * This function calls the transition notifiers and the "adjust_jiffies"
+ * function. It is called twice on all CPU frequency changes that have
+ * external effects.
+ */
+void cpufreq_notify_transition(struct cpufreq_policy *policy,
+		struct cpufreq_freqs *freqs, unsigned int state)
+{
+	for_each_cpu(freqs->cpu, policy->cpus)
+		__cpufreq_notify_transition(policy, freqs, state);
+}
 EXPORT_SYMBOL_GPL(cpufreq_notify_transition);
 
 
@@ -1141,16 +1141,23 @@ static void handle_update(struct work_struct *work)
 static void cpufreq_out_of_sync(unsigned int cpu, unsigned int old_freq,
 				unsigned int new_freq)
 {
+	struct cpufreq_policy *policy;
 	struct cpufreq_freqs freqs;
+	unsigned long flags;
+
 
 	pr_debug("Warning: CPU frequency out of sync: cpufreq and timing "
 	       "core thinks of %u, is %u kHz.\n", old_freq, new_freq);
 
-	freqs.cpu = cpu;
 	freqs.old = old_freq;
 	freqs.new = new_freq;
-	cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
-	cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
+
+	read_lock_irqsave(&cpufreq_driver_lock, flags);
+	policy = per_cpu(cpufreq_cpu_data, cpu);
+	read_unlock_irqrestore(&cpufreq_driver_lock, flags);
+
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_POSTCHANGE);
 }
 
 
diff --git a/drivers/cpufreq/dbx500-cpufreq.c b/drivers/cpufreq/dbx500-cpufreq.c
index 72f0c3e..7192a6d 100644
--- a/drivers/cpufreq/dbx500-cpufreq.c
+++ b/drivers/cpufreq/dbx500-cpufreq.c
@@ -55,8 +55,7 @@ static int dbx500_cpufreq_target(struct cpufreq_policy *policy,
 		return 0;
 
 	/* pre-change notification */
-	for_each_cpu(freqs.cpu, policy->cpus)
-		cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);
 
 	/* update armss clk frequency */
 	ret = clk_set_rate(armss_clk, freqs.new * 1000);
@@ -68,8 +67,7 @@ static int dbx500_cpufreq_target(struct cpufreq_policy *policy,
 	}
 
 	/* post change notification */
-	for_each_cpu(freqs.cpu, policy->cpus)
-		cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_POSTCHANGE);
 
 	return 0;
 }
diff --git a/drivers/cpufreq/e_powersaver.c b/drivers/cpufreq/e_powersaver.c
index 3fffbe6..37380fb 100644
--- a/drivers/cpufreq/e_powersaver.c
+++ b/drivers/cpufreq/e_powersaver.c
@@ -104,7 +104,7 @@ static unsigned int eps_get(unsigned int cpu)
 }
 
 static int eps_set_state(struct eps_cpu_data *centaur,
-			 unsigned int cpu,
+			 struct cpufreq_policy *policy,
 			 u32 dest_state)
 {
 	struct cpufreq_freqs freqs;
@@ -112,10 +112,9 @@ static int eps_set_state(struct eps_cpu_data *centaur,
 	int err = 0;
 	int i;
 
-	freqs.old = eps_get(cpu);
+	freqs.old = eps_get(policy->cpu);
 	freqs.new = centaur->fsb * ((dest_state >> 8) & 0xff);
-	freqs.cpu = cpu;
-	cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);
 
 	/* Wait while CPU is busy */
 	rdmsr(MSR_IA32_PERF_STATUS, lo, hi);
@@ -162,7 +161,7 @@ postchange:
 		current_multiplier);
 	}
 #endif
-	cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_POSTCHANGE);
 	return err;
 }
 
@@ -190,7 +189,7 @@ static int eps_target(struct cpufreq_policy *policy,
 
 	/* Make frequency transition */
 	dest_state = centaur->freq_table[newstate].index & 0xffff;
-	ret = eps_set_state(centaur, cpu, dest_state);
+	ret = eps_set_state(centaur, policy, dest_state);
 	if (ret)
 		printk(KERN_ERR "eps: Timeout!\n");
 	return ret;
diff --git a/drivers/cpufreq/elanfreq.c b/drivers/cpufreq/elanfreq.c
index 960671f..658d860 100644
--- a/drivers/cpufreq/elanfreq.c
+++ b/drivers/cpufreq/elanfreq.c
@@ -117,15 +117,15 @@ static unsigned int elanfreq_get_cpu_frequency(unsigned int cpu)
  *	There is no return value.
  */
 
-static void elanfreq_set_cpu_state(unsigned int state)
+static void elanfreq_set_cpu_state(struct cpufreq_policy *policy,
+		unsigned int state)
 {
 	struct cpufreq_freqs    freqs;
 
 	freqs.old = elanfreq_get_cpu_frequency(0);
 	freqs.new = elan_multiplier[state].clock;
-	freqs.cpu = 0; /* elanfreq.c is UP only driver */
 
-	cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);
 
 	printk(KERN_INFO "elanfreq: attempting to set frequency to %i kHz\n",
 			elan_multiplier[state].clock);
@@ -161,7 +161,7 @@ static void elanfreq_set_cpu_state(unsigned int state)
 	udelay(10000);
 	local_irq_enable();
 
-	cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_POSTCHANGE);
 };
 
 
@@ -188,7 +188,7 @@ static int elanfreq_target(struct cpufreq_policy *policy,
 				target_freq, relation, &newstate))
 		return -EINVAL;
 
-	elanfreq_set_cpu_state(newstate);
+	elanfreq_set_cpu_state(policy, newstate);
 
 	return 0;
 }
diff --git a/drivers/cpufreq/exynos-cpufreq.c b/drivers/cpufreq/exynos-cpufreq.c
index 78057a3..c0c4ce5 100644
--- a/drivers/cpufreq/exynos-cpufreq.c
+++ b/drivers/cpufreq/exynos-cpufreq.c
@@ -70,7 +70,6 @@ static int exynos_cpufreq_scale(unsigned int target_freq)
 
 	freqs.old = policy->cur;
 	freqs.new = target_freq;
-	freqs.cpu = policy->cpu;
 
 	if (freqs.new == freqs.old)
 		goto out;
@@ -105,8 +104,7 @@ static int exynos_cpufreq_scale(unsigned int target_freq)
 	}
 	arm_volt = volt_table[index];
 
-	for_each_cpu(freqs.cpu, policy->cpus)
-		cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);
 
 	/* When the new frequency is higher than current frequency */
 	if ((freqs.new > freqs.old) && !safe_arm_volt) {
@@ -131,8 +129,7 @@ static int exynos_cpufreq_scale(unsigned int target_freq)
 
 	exynos_info->set_freq(old_index, index);
 
-	for_each_cpu(freqs.cpu, policy->cpus)
-		cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_POSTCHANGE);
 
 	/* When the new frequency is lower than current frequency */
 	if ((freqs.new < freqs.old) ||
diff --git a/drivers/cpufreq/gx-suspmod.c b/drivers/cpufreq/gx-suspmod.c
index 456bee0..3dfc99b 100644
--- a/drivers/cpufreq/gx-suspmod.c
+++ b/drivers/cpufreq/gx-suspmod.c
@@ -251,14 +251,13 @@ static unsigned int gx_validate_speed(unsigned int khz, u8 *on_duration,
  * set cpu speed in khz.
  **/
 
-static void gx_set_cpuspeed(unsigned int khz)
+static void gx_set_cpuspeed(struct cpufreq_policy *policy, unsigned int khz)
 {
 	u8 suscfg, pmer1;
 	unsigned int new_khz;
 	unsigned long flags;
 	struct cpufreq_freqs freqs;
 
-	freqs.cpu = 0;
 	freqs.old = gx_get_cpuspeed(0);
 
 	new_khz = gx_validate_speed(khz, &gx_params->on_duration,
@@ -266,11 +265,9 @@ static void gx_set_cpuspeed(unsigned int khz)
 
 	freqs.new = new_khz;
 
-	cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);
 	local_irq_save(flags);
 
-
-
 	if (new_khz != stock_freq) {
 		/* if new khz == 100% of CPU speed, it is special case */
 		switch (gx_params->cs55x0->device) {
@@ -317,7 +314,7 @@ static void gx_set_cpuspeed(unsigned int khz)
 
 	gx_params->pci_suscfg = suscfg;
 
-	cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_POSTCHANGE);
 
 	pr_debug("suspend modulation w/ duration of ON:%d us, OFF:%d us\n",
 		gx_params->on_duration * 32, gx_params->off_duration * 32);
@@ -397,7 +394,7 @@ static int cpufreq_gx_target(struct cpufreq_policy *policy,
 		tmp_freq = gx_validate_speed(tmp_freq, &tmp1, &tmp2);
 	}
 
-	gx_set_cpuspeed(tmp_freq);
+	gx_set_cpuspeed(policy, tmp_freq);
 
 	return 0;
 }
diff --git a/drivers/cpufreq/imx6q-cpufreq.c b/drivers/cpufreq/imx6q-cpufreq.c
index 54e336d..b78bc35 100644
--- a/drivers/cpufreq/imx6q-cpufreq.c
+++ b/drivers/cpufreq/imx6q-cpufreq.c
@@ -50,7 +50,7 @@ static int imx6q_set_target(struct cpufreq_policy *policy,
 	struct cpufreq_freqs freqs;
 	struct opp *opp;
 	unsigned long freq_hz, volt, volt_old;
-	unsigned int index, cpu;
+	unsigned int index;
 	int ret;
 
 	ret = cpufreq_frequency_table_target(policy, freq_table, target_freq,
@@ -68,10 +68,7 @@ static int imx6q_set_target(struct cpufreq_policy *policy,
 	if (freqs.old == freqs.new)
 		return 0;
 
-	for_each_online_cpu(cpu) {
-		freqs.cpu = cpu;
-		cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
-	}
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);
 
 	rcu_read_lock();
 	opp = opp_find_freq_ceil(cpu_dev, &freq_hz);
@@ -166,10 +163,7 @@ static int imx6q_set_target(struct cpufreq_policy *policy,
 		}
 	}
 
-	for_each_online_cpu(cpu) {
-		freqs.cpu = cpu;
-		cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
-	}
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_POSTCHANGE);
 
 	return 0;
 }
diff --git a/drivers/cpufreq/kirkwood-cpufreq.c b/drivers/cpufreq/kirkwood-cpufreq.c
index 6052476..d36ea8d 100644
--- a/drivers/cpufreq/kirkwood-cpufreq.c
+++ b/drivers/cpufreq/kirkwood-cpufreq.c
@@ -55,7 +55,8 @@ static unsigned int kirkwood_cpufreq_get_cpu_frequency(unsigned int cpu)
 	return kirkwood_freq_table[0].frequency;
 }
 
-static void kirkwood_cpufreq_set_cpu_state(unsigned int index)
+static void kirkwood_cpufreq_set_cpu_state(struct cpufreq_policy *policy,
+		unsigned int index)
 {
 	struct cpufreq_freqs freqs;
 	unsigned int state = kirkwood_freq_table[index].index;
@@ -63,9 +64,8 @@ static void kirkwood_cpufreq_set_cpu_state(unsigned int index)
 
 	freqs.old = kirkwood_cpufreq_get_cpu_frequency(0);
 	freqs.new = kirkwood_freq_table[index].frequency;
-	freqs.cpu = 0; /* Kirkwood is UP */
 
-	cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);
 
 	dev_dbg(priv.dev, "Attempting to set frequency to %i KHz\n",
 		kirkwood_freq_table[index].frequency);
@@ -99,7 +99,7 @@ static void kirkwood_cpufreq_set_cpu_state(unsigned int index)
 
 		local_irq_enable();
 	}
-	cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_POSTCHANGE);
 };
 
 static int kirkwood_cpufreq_verify(struct cpufreq_policy *policy)
@@ -117,7 +117,7 @@ static int kirkwood_cpufreq_target(struct cpufreq_policy *policy,
 				target_freq, relation, &index))
 		return -EINVAL;
 
-	kirkwood_cpufreq_set_cpu_state(index);
+	kirkwood_cpufreq_set_cpu_state(policy, index);
 
 	return 0;
 }
diff --git a/drivers/cpufreq/longhaul.c b/drivers/cpufreq/longhaul.c
index 1180d53..b448638 100644
--- a/drivers/cpufreq/longhaul.c
+++ b/drivers/cpufreq/longhaul.c
@@ -242,7 +242,8 @@ static void do_powersaver(int cx_address, unsigned int mults_index,
  * Sets a new clock ratio.
  */
 
-static void longhaul_setstate(unsigned int table_index)
+static void longhaul_setstate(struct cpufreq_policy *policy,
+		unsigned int table_index)
 {
 	unsigned int mults_index;
 	int speed, mult;
@@ -267,9 +268,8 @@ static void longhaul_setstate(unsigned int table_index)
 
 	freqs.old = calc_speed(longhaul_get_cpu_mult());
 	freqs.new = speed;
-	freqs.cpu = 0; /* longhaul.c is UP only driver */
 
-	cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);
 
 	pr_debug("Setting to FSB:%dMHz Mult:%d.%dx (%s)\n",
 			fsb, mult/10, mult%10, print_speed(speed/1000));
@@ -386,7 +386,7 @@ retry_loop:
 		}
 	}
 	/* Report true CPU frequency */
-	cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_POSTCHANGE);
 
 	if (!bm_timeout)
 		printk(KERN_INFO PFX "Warning: Timeout while waiting for "
@@ -648,7 +648,7 @@ static int longhaul_target(struct cpufreq_policy *policy,
 		return 0;
 
 	if (!can_scale_voltage)
-		longhaul_setstate(table_index);
+		longhaul_setstate(policy, table_index);
 	else {
 		/* On test system voltage transitions exceeding single
 		 * step up or down were turning motherboard off. Both
@@ -663,7 +663,7 @@ static int longhaul_target(struct cpufreq_policy *policy,
 		while (i != table_index) {
 			vid = (longhaul_table[i].index >> 8) & 0x1f;
 			if (vid != current_vid) {
-				longhaul_setstate(i);
+				longhaul_setstate(policy, i);
 				current_vid = vid;
 				msleep(200);
 			}
@@ -672,7 +672,7 @@ static int longhaul_target(struct cpufreq_policy *policy,
 			else
 				i--;
 		}
-		longhaul_setstate(table_index);
+		longhaul_setstate(policy, table_index);
 	}
 	longhaul_index = table_index;
 	return 0;
@@ -998,15 +998,17 @@ static int __init longhaul_init(void)
 
 static void __exit longhaul_exit(void)
 {
+	struct cpufreq_policy *policy = cpufreq_cpu_get(0);
 	int i;
 
 	for (i = 0; i < numscales; i++) {
 		if (mults[i] == maxmult) {
-			longhaul_setstate(i);
+			longhaul_setstate(policy, i);
 			break;
 		}
 	}
 
+	cpufreq_cpu_put(policy);
 	cpufreq_unregister_driver(&longhaul_driver);
 	kfree(longhaul_table);
 }
diff --git a/drivers/cpufreq/maple-cpufreq.c b/drivers/cpufreq/maple-cpufreq.c
index d4c4989..cdd6291 100644
--- a/drivers/cpufreq/maple-cpufreq.c
+++ b/drivers/cpufreq/maple-cpufreq.c
@@ -158,11 +158,10 @@ static int maple_cpufreq_target(struct cpufreq_policy *policy,
 
 	freqs.old = maple_cpu_freqs[maple_pmode_cur].frequency;
 	freqs.new = maple_cpu_freqs[newstate].frequency;
-	freqs.cpu = 0;
 
-	cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);
 	rc = maple_scom_switch_freq(newstate);
-	cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_POSTCHANGE);
 
 	mutex_unlock(&maple_switch_mutex);
 
diff --git a/drivers/cpufreq/omap-cpufreq.c b/drivers/cpufreq/omap-cpufreq.c
index 9128c07..b610edd 100644
--- a/drivers/cpufreq/omap-cpufreq.c
+++ b/drivers/cpufreq/omap-cpufreq.c
@@ -88,16 +88,12 @@ static int omap_target(struct cpufreq_policy *policy,
 	}
 
 	freqs.old = omap_getspeed(policy->cpu);
-	freqs.cpu = policy->cpu;
 
 	if (freqs.old == freqs.new && policy->cur == freqs.new)
 		return ret;
 
 	/* notifiers */
-	for_each_cpu(i, policy->cpus) {
-		freqs.cpu = i;
-		cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
-	}
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);
 
 	freq = freqs.new * 1000;
 	ret = clk_round_rate(mpu_clk, freq);
@@ -157,10 +153,7 @@ static int omap_target(struct cpufreq_policy *policy,
 
 done:
 	/* notifiers */
-	for_each_cpu(i, policy->cpus) {
-		freqs.cpu = i;
-		cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
-	}
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_POSTCHANGE);
 
 	return ret;
 }
diff --git a/drivers/cpufreq/p4-clockmod.c b/drivers/cpufreq/p4-clockmod.c
index 827629c9..4b2e773 100644
--- a/drivers/cpufreq/p4-clockmod.c
+++ b/drivers/cpufreq/p4-clockmod.c
@@ -125,10 +125,7 @@ static int cpufreq_p4_target(struct cpufreq_policy *policy,
 		return 0;
 
 	/* notifiers */
-	for_each_cpu(i, policy->cpus) {
-		freqs.cpu = i;
-		cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
-	}
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);
 
 	/* run on each logical CPU,
 	 * see section 13.15.3 of IA32 Intel Architecture Software
@@ -138,10 +135,7 @@ static int cpufreq_p4_target(struct cpufreq_policy *policy,
 		cpufreq_p4_setdc(i, p4clockmod_table[newstate].index);
 
 	/* notifiers */
-	for_each_cpu(i, policy->cpus) {
-		freqs.cpu = i;
-		cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
-	}
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_POSTCHANGE);
 
 	return 0;
 }
diff --git a/drivers/cpufreq/pcc-cpufreq.c b/drivers/cpufreq/pcc-cpufreq.c
index 503996a..0de0008 100644
--- a/drivers/cpufreq/pcc-cpufreq.c
+++ b/drivers/cpufreq/pcc-cpufreq.c
@@ -215,8 +215,7 @@ static int pcc_cpufreq_target(struct cpufreq_policy *policy,
 		(pcch_virt_addr + pcc_cpu_data->input_offset));
 
 	freqs.new = target_freq;
-	freqs.cpu = cpu;
-	cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);
 
 	input_buffer = 0x1 | (((target_freq * 100)
 			       / (ioread32(&pcch_hdr->nominal) * 1000)) << 8);
@@ -237,7 +236,7 @@ static int pcc_cpufreq_target(struct cpufreq_policy *policy,
 	}
 	iowrite16(0, &pcch_hdr->status);
 
-	cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_POSTCHANGE);
 	pr_debug("target: was SUCCESSFUL for cpu %d\n", cpu);
 	spin_unlock(&pcc_lock);
 
diff --git a/drivers/cpufreq/powernow-k6.c b/drivers/cpufreq/powernow-k6.c
index af23e0b..ea0222a 100644
--- a/drivers/cpufreq/powernow-k6.c
+++ b/drivers/cpufreq/powernow-k6.c
@@ -68,7 +68,8 @@ static int powernow_k6_get_cpu_multiplier(void)
  *
  *   Tries to change the PowerNow! multiplier
  */
-static void powernow_k6_set_state(unsigned int best_i)
+static void powernow_k6_set_state(struct cpufreq_policy *policy,
+		unsigned int best_i)
 {
 	unsigned long outvalue = 0, invalue = 0;
 	unsigned long msrval;
@@ -81,9 +82,8 @@ static void powernow_k6_set_state(unsigned int best_i)
 
 	freqs.old = busfreq * powernow_k6_get_cpu_multiplier();
 	freqs.new = busfreq * clock_ratio[best_i].index;
-	freqs.cpu = 0; /* powernow-k6.c is UP only driver */
 
-	cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);
 
 	/* we now need to transform best_i to the BVC format, see AMD#23446 */
 
@@ -98,7 +98,7 @@ static void powernow_k6_set_state(unsigned int best_i)
 	msrval = POWERNOW_IOPORT + 0x0;
 	wrmsr(MSR_K6_EPMR, msrval, 0); /* disable it again */
 
-	cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_POSTCHANGE);
 
 	return;
 }
@@ -136,7 +136,7 @@ static int powernow_k6_target(struct cpufreq_policy *policy,
 				target_freq, relation, &newstate))
 		return -EINVAL;
 
-	powernow_k6_set_state(newstate);
+	powernow_k6_set_state(policy, newstate);
 
 	return 0;
 }
@@ -182,7 +182,7 @@ static int powernow_k6_cpu_exit(struct cpufreq_policy *policy)
 	unsigned int i;
 	for (i = 0; i < 8; i++) {
 		if (i == max_multiplier)
-			powernow_k6_set_state(i);
+			powernow_k6_set_state(policy, i);
 	}
 	cpufreq_frequency_table_put_attr(policy->cpu);
 	return 0;
diff --git a/drivers/cpufreq/powernow-k7.c b/drivers/cpufreq/powernow-k7.c
index 334cc2f..53888da 100644
--- a/drivers/cpufreq/powernow-k7.c
+++ b/drivers/cpufreq/powernow-k7.c
@@ -248,7 +248,7 @@ static void change_VID(int vid)
 }
 
 
-static void change_speed(unsigned int index)
+static void change_speed(struct cpufreq_policy *policy, unsigned int index)
 {
 	u8 fid, vid;
 	struct cpufreq_freqs freqs;
@@ -263,15 +263,13 @@ static void change_speed(unsigned int index)
 	fid = powernow_table[index].index & 0xFF;
 	vid = (powernow_table[index].index & 0xFF00) >> 8;
 
-	freqs.cpu = 0;
-
 	rdmsrl(MSR_K7_FID_VID_STATUS, fidvidstatus.val);
 	cfid = fidvidstatus.bits.CFID;
 	freqs.old = fsb * fid_codes[cfid] / 10;
 
 	freqs.new = powernow_table[index].frequency;
 
-	cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);
 
 	/* Now do the magic poking into the MSRs.  */
 
@@ -292,7 +290,7 @@ static void change_speed(unsigned int index)
 	if (have_a0 == 1)
 		local_irq_enable();
 
-	cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_POSTCHANGE);
 }
 
 
@@ -546,7 +544,7 @@ static int powernow_target(struct cpufreq_policy *policy,
 				relation, &newstate))
 		return -EINVAL;
 
-	change_speed(newstate);
+	change_speed(policy, newstate);
 
 	return 0;
 }
diff --git a/drivers/cpufreq/powernow-k8.c b/drivers/cpufreq/powernow-k8.c
index d13a136..52137a3 100644
--- a/drivers/cpufreq/powernow-k8.c
+++ b/drivers/cpufreq/powernow-k8.c
@@ -928,9 +928,10 @@ static int get_transition_latency(struct powernow_k8_data *data)
 static int transition_frequency_fidvid(struct powernow_k8_data *data,
 		unsigned int index)
 {
+	struct cpufreq_policy *policy;
 	u32 fid = 0;
 	u32 vid = 0;
-	int res, i;
+	int res;
 	struct cpufreq_freqs freqs;
 
 	pr_debug("cpu %d transition to index %u\n", smp_processor_id(), index);
@@ -959,10 +960,10 @@ static int transition_frequency_fidvid(struct powernow_k8_data *data,
 	freqs.old = find_khz_freq_from_fid(data->currfid);
 	freqs.new = find_khz_freq_from_fid(fid);
 
-	for_each_cpu(i, data->available_cores) {
-		freqs.cpu = i;
-		cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
-	}
+	policy = cpufreq_cpu_get(smp_processor_id());
+	cpufreq_cpu_put(policy);
+
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);
 
 	res = transition_fid_vid(data, fid, vid);
 	if (res)
@@ -970,10 +971,7 @@ static int transition_frequency_fidvid(struct powernow_k8_data *data,
 
 	freqs.new = find_khz_freq_from_fid(data->currfid);
 
-	for_each_cpu(i, data->available_cores) {
-		freqs.cpu = i;
-		cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
-	}
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_POSTCHANGE);
 	return res;
 }
 
diff --git a/drivers/cpufreq/s3c2416-cpufreq.c b/drivers/cpufreq/s3c2416-cpufreq.c
index bcc053b..4f1881e 100644
--- a/drivers/cpufreq/s3c2416-cpufreq.c
+++ b/drivers/cpufreq/s3c2416-cpufreq.c
@@ -256,7 +256,6 @@ static int s3c2416_cpufreq_set_target(struct cpufreq_policy *policy,
 		goto out;
 	}
 
-	freqs.cpu = 0;
 	freqs.flags = 0;
 	freqs.old = s3c_freq->is_dvs ? FREQ_DVS
 				     : clk_get_rate(s3c_freq->armclk) / 1000;
@@ -274,7 +273,7 @@ static int s3c2416_cpufreq_set_target(struct cpufreq_policy *policy,
 	if (!to_dvs && freqs.old == freqs.new)
 		goto out;
 
-	cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);
 
 	if (to_dvs) {
 		pr_debug("cpufreq: enter dvs\n");
@@ -287,7 +286,7 @@ static int s3c2416_cpufreq_set_target(struct cpufreq_policy *policy,
 		ret = s3c2416_cpufreq_set_armdiv(s3c_freq, freqs.new);
 	}
 
-	cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_POSTCHANGE);
 
 out:
 	mutex_unlock(&cpufreq_lock);
diff --git a/drivers/cpufreq/s3c64xx-cpufreq.c b/drivers/cpufreq/s3c64xx-cpufreq.c
index 6f9490b..27cacb5 100644
--- a/drivers/cpufreq/s3c64xx-cpufreq.c
+++ b/drivers/cpufreq/s3c64xx-cpufreq.c
@@ -84,7 +84,6 @@ static int s3c64xx_cpufreq_set_target(struct cpufreq_policy *policy,
 	if (ret != 0)
 		return ret;
 
-	freqs.cpu = 0;
 	freqs.old = clk_get_rate(armclk) / 1000;
 	freqs.new = s3c64xx_freq_table[i].frequency;
 	freqs.flags = 0;
@@ -95,7 +94,7 @@ static int s3c64xx_cpufreq_set_target(struct cpufreq_policy *policy,
 
 	pr_debug("Transition %d-%dkHz\n", freqs.old, freqs.new);
 
-	cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);
 
 #ifdef CONFIG_REGULATOR
 	if (vddarm && freqs.new > freqs.old) {
@@ -117,7 +116,7 @@ static int s3c64xx_cpufreq_set_target(struct cpufreq_policy *policy,
 		goto err;
 	}
 
-	cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_POSTCHANGE);
 
 #ifdef CONFIG_REGULATOR
 	if (vddarm && freqs.new < freqs.old) {
@@ -141,7 +140,7 @@ err_clk:
 	if (clk_set_rate(armclk, freqs.old * 1000) < 0)
 		pr_err("Failed to restore original clock rate\n");
 err:
-	cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_POSTCHANGE);
 
 	return ret;
 }
diff --git a/drivers/cpufreq/s5pv210-cpufreq.c b/drivers/cpufreq/s5pv210-cpufreq.c
index a484aae..5c77570 100644
--- a/drivers/cpufreq/s5pv210-cpufreq.c
+++ b/drivers/cpufreq/s5pv210-cpufreq.c
@@ -229,7 +229,6 @@ static int s5pv210_target(struct cpufreq_policy *policy,
 	}
 
 	freqs.new = s5pv210_freq_table[index].frequency;
-	freqs.cpu = 0;
 
 	if (freqs.new == freqs.old)
 		goto exit;
@@ -256,7 +255,7 @@ static int s5pv210_target(struct cpufreq_policy *policy,
 			goto exit;
 	}
 
-	cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);
 
 	/* Check if there need to change PLL */
 	if ((index == L0) || (priv_index == L0))
@@ -468,7 +467,7 @@ static int s5pv210_target(struct cpufreq_policy *policy,
 		}
 	}
 
-	cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_POSTCHANGE);
 
 	if (freqs.new < freqs.old) {
 		regulator_set_voltage(int_regulator,
diff --git a/drivers/cpufreq/sc520_freq.c b/drivers/cpufreq/sc520_freq.c
index e42e073..f740b13 100644
--- a/drivers/cpufreq/sc520_freq.c
+++ b/drivers/cpufreq/sc520_freq.c
@@ -53,7 +53,8 @@ static unsigned int sc520_freq_get_cpu_frequency(unsigned int cpu)
 	}
 }
 
-static void sc520_freq_set_cpu_state(unsigned int state)
+static void sc520_freq_set_cpu_state(struct cpufreq_policy *policy,
+		unsigned int state)
 {
 
 	struct cpufreq_freqs	freqs;
@@ -61,9 +62,8 @@ static void sc520_freq_set_cpu_state(unsigned int state)
 
 	freqs.old = sc520_freq_get_cpu_frequency(0);
 	freqs.new = sc520_freq_table[state].frequency;
-	freqs.cpu = 0; /* AMD Elan is UP */
 
-	cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);
 
 	pr_debug("attempting to set frequency to %i kHz\n",
 			sc520_freq_table[state].frequency);
@@ -75,7 +75,7 @@ static void sc520_freq_set_cpu_state(unsigned int state)
 
 	local_irq_enable();
 
-	cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_POSTCHANGE);
 };
 
 static int sc520_freq_verify(struct cpufreq_policy *policy)
@@ -93,7 +93,7 @@ static int sc520_freq_target(struct cpufreq_policy *policy,
 				target_freq, relation, &newstate))
 		return -EINVAL;
 
-	sc520_freq_set_cpu_state(newstate);
+	sc520_freq_set_cpu_state(policy, newstate);
 
 	return 0;
 }
diff --git a/drivers/cpufreq/spear-cpufreq.c b/drivers/cpufreq/spear-cpufreq.c
index 7e4d773..156829f 100644
--- a/drivers/cpufreq/spear-cpufreq.c
+++ b/drivers/cpufreq/spear-cpufreq.c
@@ -121,7 +121,6 @@ static int spear_cpufreq_target(struct cpufreq_policy *policy,
 				target_freq, relation, &index))
 		return -EINVAL;
 
-	freqs.cpu = policy->cpu;
 	freqs.old = spear_cpufreq_get(0);
 
 	newfreq = spear_cpufreq.freq_tbl[index].frequency * 1000;
@@ -158,8 +157,7 @@ static int spear_cpufreq_target(struct cpufreq_policy *policy,
 	freqs.new = newfreq / 1000;
 	freqs.new /= mult;
 
-	for_each_cpu(freqs.cpu, policy->cpus)
-		cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);
 
 	if (mult == 2)
 		ret = spear1340_set_cpu_rate(srcclk, newfreq);
@@ -172,8 +170,7 @@ static int spear_cpufreq_target(struct cpufreq_policy *policy,
 		freqs.new = clk_get_rate(spear_cpufreq.clk) / 1000;
 	}
 
-	for_each_cpu(freqs.cpu, policy->cpus)
-		cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_POSTCHANGE);
 	return ret;
 }
 
diff --git a/drivers/cpufreq/speedstep-centrino.c b/drivers/cpufreq/speedstep-centrino.c
index 3a953d5..3dbbcc3 100644
--- a/drivers/cpufreq/speedstep-centrino.c
+++ b/drivers/cpufreq/speedstep-centrino.c
@@ -457,7 +457,7 @@ static int centrino_target (struct cpufreq_policy *policy,
 	unsigned int	msr, oldmsr = 0, h = 0, cpu = policy->cpu;
 	struct cpufreq_freqs	freqs;
 	int			retval = 0;
-	unsigned int		j, k, first_cpu, tmp;
+	unsigned int		j, first_cpu, tmp;
 	cpumask_var_t covered_cpus;
 
 	if (unlikely(!zalloc_cpumask_var(&covered_cpus, GFP_KERNEL)))
@@ -522,13 +522,8 @@ static int centrino_target (struct cpufreq_policy *policy,
 			pr_debug("target=%dkHz old=%d new=%d msr=%04x\n",
 				target_freq, freqs.old, freqs.new, msr);
 
-			for_each_cpu(k, policy->cpus) {
-				if (!cpu_online(k))
-					continue;
-				freqs.cpu = k;
-				cpufreq_notify_transition(&freqs,
+			cpufreq_notify_transition(policy, &freqs,
 					CPUFREQ_PRECHANGE);
-			}
 
 			first_cpu = 0;
 			/* all but 16 LSB are reserved, treat them with care */
@@ -544,12 +539,7 @@ static int centrino_target (struct cpufreq_policy *policy,
 		cpumask_set_cpu(j, covered_cpus);
 	}
 
-	for_each_cpu(k, policy->cpus) {
-		if (!cpu_online(k))
-			continue;
-		freqs.cpu = k;
-		cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
-	}
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_POSTCHANGE);
 
 	if (unlikely(retval)) {
 		/*
@@ -565,12 +555,8 @@ static int centrino_target (struct cpufreq_policy *policy,
 		tmp = freqs.new;
 		freqs.new = freqs.old;
 		freqs.old = tmp;
-		for_each_cpu(j, policy->cpus) {
-			if (!cpu_online(j))
-				continue;
-			cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
-			cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
-		}
+		cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);
+		cpufreq_notify_transition(policy, &freqs, CPUFREQ_POSTCHANGE);
 	}
 	retval = 0;
 
diff --git a/drivers/cpufreq/speedstep-ich.c b/drivers/cpufreq/speedstep-ich.c
index e29b59a..e2e5aa9 100644
--- a/drivers/cpufreq/speedstep-ich.c
+++ b/drivers/cpufreq/speedstep-ich.c
@@ -263,7 +263,6 @@ static int speedstep_target(struct cpufreq_policy *policy,
 {
 	unsigned int newstate = 0, policy_cpu;
 	struct cpufreq_freqs freqs;
-	int i;
 
 	if (cpufreq_frequency_table_target(policy, &speedstep_freqs[0],
 				target_freq, relation, &newstate))
@@ -272,7 +271,6 @@ static int speedstep_target(struct cpufreq_policy *policy,
 	policy_cpu = cpumask_any_and(policy->cpus, cpu_online_mask);
 	freqs.old = speedstep_get(policy_cpu);
 	freqs.new = speedstep_freqs[newstate].frequency;
-	freqs.cpu = policy->cpu;
 
 	pr_debug("transiting from %u to %u kHz\n", freqs.old, freqs.new);
 
@@ -280,18 +278,12 @@ static int speedstep_target(struct cpufreq_policy *policy,
 	if (freqs.old == freqs.new)
 		return 0;
 
-	for_each_cpu(i, policy->cpus) {
-		freqs.cpu = i;
-		cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
-	}
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);
 
 	smp_call_function_single(policy_cpu, _speedstep_set_state, &newstate,
 				 true);
 
-	for_each_cpu(i, policy->cpus) {
-		freqs.cpu = i;
-		cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
-	}
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_POSTCHANGE);
 
 	return 0;
 }
diff --git a/drivers/cpufreq/speedstep-smi.c b/drivers/cpufreq/speedstep-smi.c
index 6a457fc..f5a6b70 100644
--- a/drivers/cpufreq/speedstep-smi.c
+++ b/drivers/cpufreq/speedstep-smi.c
@@ -252,14 +252,13 @@ static int speedstep_target(struct cpufreq_policy *policy,
 
 	freqs.old = speedstep_freqs[speedstep_get_state()].frequency;
 	freqs.new = speedstep_freqs[newstate].frequency;
-	freqs.cpu = 0; /* speedstep.c is UP only driver */
 
 	if (freqs.old == freqs.new)
 		return 0;
 
-	cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);
 	speedstep_set_state(newstate);
-	cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_POSTCHANGE);
 
 	return 0;
 }
diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
index 4bbc572..037d36a 100644
--- a/include/linux/cpufreq.h
+++ b/include/linux/cpufreq.h
@@ -278,8 +278,8 @@ int cpufreq_register_driver(struct cpufreq_driver *driver_data);
 int cpufreq_unregister_driver(struct cpufreq_driver *driver_data);
 
 
-void cpufreq_notify_transition(struct cpufreq_freqs *freqs, unsigned int state);
-
+void cpufreq_notify_transition(struct cpufreq_policy *policy,
+		struct cpufreq_freqs *freqs, unsigned int state);
 
 static inline void cpufreq_verify_within_limits(struct cpufreq_policy *policy, unsigned int min, unsigned int max)
 {
-- 
1.7.12.rc2.18.g61b472e



From broonie at opensource.wolfsonmicro.com  Mon Apr  1 09:03:09 2013
From: broonie at opensource.wolfsonmicro.com (Mark Brown)
Date: Mon, 1 Apr 2013 14:03:09 +0100
Subject: [PATCH V3 1/5] spi: s3c64xx: modified error interrupt handling
 and init
In-Reply-To: <1363157014-9615-2-git-send-email-ks.giri@samsung.com>
References: <1363157014-9615-1-git-send-email-ks.giri@samsung.com>
 <1363157014-9615-2-git-send-email-ks.giri@samsung.com>
Message-ID: <20130401130309.GH18636@opensource.wolfsonmicro.com>

On Wed, Mar 13, 2013 at 12:13:30PM +0530, Girish K S wrote:
> From: Girish K S <girishks2000 at gmail.com>
> 
> The status of the interrupt is available in the status register,
> so reading the clear pending register and writing back the same
> value will not actually clear the pending interrupts. This patch
> modifies the interrupt handler to read the status register and
> clear the corresponding pending bit in the clear pending register.

Applied, thanks.

> Signed-off-by: Girish K S <ks.giri at samsung.com>

This and the committer e-mail address (the From: above) really ought to
match up with each other.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130401/da459305/attachment.sig>

From broonie at opensource.wolfsonmicro.com  Mon Apr  1 09:12:07 2013
From: broonie at opensource.wolfsonmicro.com (Mark Brown)
Date: Mon, 1 Apr 2013 14:12:07 +0100
Subject: [PATCH V3 2/5] spi: s3c64xx: added support for polling mode
In-Reply-To: <1363157014-9615-3-git-send-email-ks.giri@samsung.com>
References: <1363157014-9615-1-git-send-email-ks.giri@samsung.com>
 <1363157014-9615-3-git-send-email-ks.giri@samsung.com>
Message-ID: <20130401131207.GI18636@opensource.wolfsonmicro.com>

On Wed, Mar 13, 2013 at 12:13:31PM +0530, Girish K S wrote:

> Some SoC's that adopt this controller might not have have dma
> interface. This patch adds support for complete polling mode
> and gives flexibity for the user to select poll/dma mode.

Ouch, that sounds like a regression.

> @@ -419,6 +422,27 @@ static inline void enable_cs(struct s3c64xx_spi_driver_data *sdd,
>  
>  	cs = spi->controller_data;
>  	gpio_set_value(cs->line, spi->mode & SPI_CS_HIGH ? 1 : 0);
> +
> +	/* Start the signals */
> +	writel(0, sdd->regs + S3C64XX_SPI_SLAVE_SEL);
> +}
> +

This looks odd and not obviously related to the rest of the change -
does it belong as part of some of your other commits adding support for
using the controller /CS functionality?  In general it feels like this
ought to be broken down a bit - there's some refactoring as well as the
new functionality.

> +static u32 wait_for_timeout(struct s3c64xx_spi_driver_data *sdd,
> +					int timeout_ms)
> +{
> +	void __iomem *regs = sdd->regs;
> +	unsigned long val;
> +	u32 status;
> +	/* max fifo depth available */
> +	u32 max_fifo = (FIFO_LVL_MASK(sdd) >> 1) + 1;
> +
> +	val = msecs_to_loops(timeout_ms);
> +	do {
> +		status = readl(regs + S3C64XX_SPI_STATUS);
> +	} while (RX_FIFO_LVL(status, sdd) < max_fifo && --val);
> +
> +	/* return the actual received data length */
> +	return RX_FIFO_LVL(status, sdd);

This is really wait_for_fifo_empty_with_timeout() isn't it?  It feels
like there ought to be at least a cpu_relax() in the busy wait too.

> +		/*
> +		 * If the receive length is bigger than the controller fifo
> +		 * size, calculate the loops and read the fifo as many times.
> +		 * loops = length / max fifo size (calculated by using the
> +		 * fifo mask).
> +		 * For any size less than the fifo size the below code is
> +		 * executed atleast once.
> +		 */
> +		loops = xfer->len / ((FIFO_LVL_MASK(sdd) >> 1) + 1);
> +		buf = xfer->rx_buf;
> +		do{

Coding style.

> -	if (!sdd->pdev->dev.of_node) {
> +	if (!sdd->pdev->dev.of_node && !is_polling(sdd)) {
>  		res = platform_get_resource(pdev, IORESOURCE_DMA,  0);
>  		if (!res) {
>  			dev_err(&pdev->dev, "Unable to get SPI tx dma "

It seems like it'd be sensible to also handle failure to get the DMA
resource by going into polling mode.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130401/ff4ab212/attachment.sig>

From robherring2 at gmail.com  Mon Apr  1 09:13:31 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Mon, 1 Apr 2013 08:13:31 -0500
Subject: [PATCH V2] DMA: PL330: Add check if device tree compatible
In-Reply-To: <20130321093906.GL10326@intel.com>
References: <1362475531-32260-1-git-send-email-padma.v@samsung.com>
 <1362475531-32260-2-git-send-email-padma.v@samsung.com>
 <20130321093906.GL10326@intel.com>
Message-ID: <CAL_Jsq+3bJDiA=rXS=WY3BGuRh5X+nyxxosrqtSD9fx-asbCKQ@mail.gmail.com>

On Thu, Mar 21, 2013 at 4:39 AM, Vinod Koul <vinod.koul at intel.com> wrote:
> On Tue, Mar 05, 2013 at 02:55:31PM +0530, Padmavathi Venna wrote:
>> This patch register the dma controller with generic dma helpers only
>> in DT case. This also adds some extra error handling in the driver.
>>
>> Signed-off-by: Padmavathi Venna <padma.v at samsung.com>
>> Reported-by: Sachin Kamat <sachin.kamat at linaro.org>

What's the status on this? It is needed for 3.9 to fix pl330 on highbank.

Rob

>> ---
>>
>> Based on Vinod Koul next branch.
>>
>> Changes since V1:
>>       - return silently when of_dma_controller_register fails, as
>>         suggested by Arnd.
>>
>>  drivers/dma/pl330.c |   38 +++++++++++++++++++++++++++-----------
>>  1 files changed, 27 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
>> index 7181531..5dbc594 100644
>> --- a/drivers/dma/pl330.c
>> +++ b/drivers/dma/pl330.c
>> @@ -2882,7 +2882,7 @@ pl330_probe(struct amba_device *adev, const struct amba_id *id)
>>  {
>>       struct dma_pl330_platdata *pdat;
>>       struct dma_pl330_dmac *pdmac;
>> -     struct dma_pl330_chan *pch;
>> +     struct dma_pl330_chan *pch, *_p;
>>       struct pl330_info *pi;
>>       struct dma_device *pd;
>>       struct resource *res;
>> @@ -2984,7 +2984,16 @@ pl330_probe(struct amba_device *adev, const struct amba_id *id)
>>       ret = dma_async_device_register(pd);
>>       if (ret) {
>>               dev_err(&adev->dev, "unable to register DMAC\n");
>> -             goto probe_err2;
>> +             goto probe_err3;
>> +     }
>> +
>> +     if (adev->dev.of_node) {
>> +             ret = of_dma_controller_register(adev->dev.of_node,
>> +                                      of_dma_pl330_xlate, pdmac);
>> +             if (ret) {
>> +                     dev_err(&adev->dev,
>> +                     "unable to register DMA to the generic DT DMA helpers\n");
> Indent?
>> +             }
>>       }
>>
>>       dev_info(&adev->dev,
>> @@ -2995,16 +3004,21 @@ pl330_probe(struct amba_device *adev, const struct amba_id *id)
>>               pi->pcfg.data_bus_width / 8, pi->pcfg.num_chan,
>>               pi->pcfg.num_peri, pi->pcfg.num_events);
>>
>> -     ret = of_dma_controller_register(adev->dev.of_node,
>> -                                      of_dma_pl330_xlate, pdmac);
>> -     if (ret) {
>> -             dev_err(&adev->dev,
>> -             "unable to register DMA to the generic DT DMA helpers\n");
>> -             goto probe_err2;
>> -     }
>> -
>>       return 0;
>> +probe_err3:
>> +     amba_set_drvdata(adev, NULL);
>>
>> +     /* Idle the DMAC */
>> +     list_for_each_entry_safe(pch, _p, &pdmac->ddma.channels,
>> +                     chan.device_node) {
>> +
>> +             /* Remove the channel */
>> +             list_del(&pch->chan.device_node);
>> +
>> +             /* Flush the channel */
>> +             pl330_control(&pch->chan, DMA_TERMINATE_ALL, 0);
>> +             pl330_free_chan_resources(&pch->chan);
> free_chan for error handling in probe?
>
>> +     }
>>  probe_err2:
>>       pl330_del(pi);
>>  probe_err1:
>> @@ -3023,8 +3037,10 @@ static int pl330_remove(struct amba_device *adev)
>>       if (!pdmac)
>>               return 0;
>>
>> -     of_dma_controller_free(adev->dev.of_node);
>> +     if (adev->dev.of_node)
>> +             of_dma_controller_free(adev->dev.of_node);
>>
>> +     dma_async_device_unregister(&pdmac->ddma);
>>       amba_set_drvdata(adev, NULL);
>>
>>       /* Idle the DMAC */
>> --
>> 1.7.4.4
>>


From broonie at opensource.wolfsonmicro.com  Mon Apr  1 09:38:33 2013
From: broonie at opensource.wolfsonmicro.com (Mark Brown)
Date: Mon, 1 Apr 2013 14:38:33 +0100
Subject: [PATCH v7 01/14] spi/spi-atmel: detect the capabilities of SPI
 core by reading the VERSION register.
In-Reply-To: <1363678935-3665-1-git-send-email-wenyou.yang@atmel.com>
References: <1363678866-3567-1-git-send-email-wenyou.yang@atmel.com>
 <1363678935-3665-1-git-send-email-wenyou.yang@atmel.com>
Message-ID: <20130401133833.GT18636@opensource.wolfsonmicro.com>

On Tue, Mar 19, 2013 at 03:42:15PM +0800, Wenyou Yang wrote:

> +{
> +	unsigned int version;
> +
> +	version = atmel_get_version(as);
> +	dev_info(&as->pdev->dev, "version: 0x%x\n", version);
> +
> +	as->caps.is_spi2 = (version > 0x121) ? true : false;
> +	as->caps.has_wdrbt = (version >= 0x210) ? true : false;
> +	as->caps.has_dma_support = (version >= 0x212) ? true : false;
> +}
> +

There's absolutely no need for the ternery operators here - your
comparisons are already boolean, the ternery operators just add noise.

I've applied this with the above edited to remove the ? true : false,
thanks.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130401/e96db89b/attachment.sig>

From broonie at opensource.wolfsonmicro.com  Mon Apr  1 09:41:03 2013
From: broonie at opensource.wolfsonmicro.com (Mark Brown)
Date: Mon, 1 Apr 2013 14:41:03 +0100
Subject: [PATCH v7 02/14] spi/spi-atmel: add support transfer on CS1, 2, 3,
 not only on CS0
In-Reply-To: <1363678981-3724-1-git-send-email-wenyou.yang@atmel.com>
References: <1363678866-3567-1-git-send-email-wenyou.yang@atmel.com>
 <1363678981-3724-1-git-send-email-wenyou.yang@atmel.com>
Message-ID: <20130401134103.GU18636@opensource.wolfsonmicro.com>

On Tue, Mar 19, 2013 at 03:43:01PM +0800, Wenyou Yang wrote:
> Signed-off-by: Wenyou Yang <wenyou.yang at atmel.com>

Applied, thanks.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130401/a916dc48/attachment.sig>

From broonie at opensource.wolfsonmicro.com  Mon Apr  1 09:41:47 2013
From: broonie at opensource.wolfsonmicro.com (Mark Brown)
Date: Mon, 1 Apr 2013 14:41:47 +0100
Subject: [PATCH v7 03/14] spi/spi-atmel: add physical base address
In-Reply-To: <1363679016-3761-1-git-send-email-wenyou.yang@atmel.com>
References: <1363678866-3567-1-git-send-email-wenyou.yang@atmel.com>
 <1363679016-3761-1-git-send-email-wenyou.yang@atmel.com>
Message-ID: <20130401134147.GV18636@opensource.wolfsonmicro.com>

On Tue, Mar 19, 2013 at 03:43:36PM +0800, Wenyou Yang wrote:

> +++ b/drivers/spi/spi-atmel.c
> @@ -196,6 +196,7 @@ struct atmel_spi_caps {
>  struct atmel_spi {
>  	spinlock_t		lock;
>  
> +	resource_size_t		phybase;
>  	void __iomem		*regs;
>  	int			irq;
>  	struct clk		*clk;

This looks like the wrong type?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130401/e5c5ddae/attachment-0001.sig>

From broonie at opensource.wolfsonmicro.com  Mon Apr  1 09:43:00 2013
From: broonie at opensource.wolfsonmicro.com (Mark Brown)
Date: Mon, 1 Apr 2013 14:43:00 +0100
Subject: [PATCH v7 04/14] spi/spi-atmel: call unmapping on transfers
 buffers
In-Reply-To: <1363679062-3797-1-git-send-email-wenyou.yang@atmel.com>
References: <1363678866-3567-1-git-send-email-wenyou.yang@atmel.com>
 <1363679062-3797-1-git-send-email-wenyou.yang@atmel.com>
Message-ID: <20130401134259.GW18636@opensource.wolfsonmicro.com>

On Tue, Mar 19, 2013 at 03:44:22PM +0800, Wenyou Yang wrote:
> From: Nicolas Ferre <nicolas.ferre at atmel.com>

Applied, thanks.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130401/068c9875/attachment.sig>

From broonie at opensource.wolfsonmicro.com  Mon Apr  1 09:43:51 2013
From: broonie at opensource.wolfsonmicro.com (Mark Brown)
Date: Mon, 1 Apr 2013 14:43:51 +0100
Subject: [PATCH v7 05/14] spi/spi-atmel: status information passed
 through controller data
In-Reply-To: <1363679101-3834-1-git-send-email-wenyou.yang@atmel.com>
References: <1363678866-3567-1-git-send-email-wenyou.yang@atmel.com>
 <1363679101-3834-1-git-send-email-wenyou.yang@atmel.com>
Message-ID: <20130401134350.GX18636@opensource.wolfsonmicro.com>

On Tue, Mar 19, 2013 at 03:45:01PM +0800, Wenyou Yang wrote:
> From: Nicolas Ferre <nicolas.ferre at atmel.com>
> 
> The status of transfer is stored in controller data structure
> so that it can be used not only by atmel_spi_msg_done() function.
> This will be useful for upcoming dmaengine enabled driver.

Applied, thanks.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130401/404c54dd/attachment.sig>

From broonie at opensource.wolfsonmicro.com  Mon Apr  1 09:46:13 2013
From: broonie at opensource.wolfsonmicro.com (Mark Brown)
Date: Mon, 1 Apr 2013 14:46:13 +0100
Subject: [PATCH v7 06/14] spi/spi-atmel: add flag to controller data for
 lock operations
In-Reply-To: <1363679163-3897-1-git-send-email-wenyou.yang@atmel.com>
References: <1363678866-3567-1-git-send-email-wenyou.yang@atmel.com>
 <1363679163-3897-1-git-send-email-wenyou.yang@atmel.com>
Message-ID: <20130401134613.GY18636@opensource.wolfsonmicro.com>

On Tue, Mar 19, 2013 at 03:46:03PM +0800, Wenyou Yang wrote:

> +static void atmel_spi_lock(struct atmel_spi *as)
> +{
> +		spin_lock_irqsave(&as->lock, as->flags);
> +}

Coding style.

> -	spin_unlock(&as->lock);
> +	atmel_spi_unlock(as);
>  	msg->complete(msg->context);
> -	spin_lock(&as->lock);
> +	atmel_spi_lock(as);

This replaces non-irqsave versions with irqsave versions of the lock.
Is this safe/correct?  If it is I'd have expected some sort of mention
of it in the commit log.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130401/435cb807/attachment.sig>

From broonie at opensource.wolfsonmicro.com  Mon Apr  1 09:51:04 2013
From: broonie at opensource.wolfsonmicro.com (Mark Brown)
Date: Mon, 1 Apr 2013 14:51:04 +0100
Subject: [PATCH v7 08/14] spi/spi-atmel: fix spi-atmel driver to adapt to
 slave_config changes
In-Reply-To: <1363679236-3973-1-git-send-email-wenyou.yang@atmel.com>
References: <1363678866-3567-1-git-send-email-wenyou.yang@atmel.com>
 <1363679236-3973-1-git-send-email-wenyou.yang@atmel.com>
Message-ID: <20130401135104.GZ18636@opensource.wolfsonmicro.com>

On Tue, Mar 19, 2013 at 03:47:16PM +0800, Wenyou Yang wrote:
> From: Richard Genoud <richard.genoud at gmail.com>
> 
> This is the following of the patch e2b35f3dbfc080f15b72834d08f04f0269dbe9be

What is this patch actually doing, shouldn't it be part of the previous
commit?  The changelog really ought to have a plain text version of the
commit description too.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130401/62034ceb/attachment.sig>

From broonie at opensource.wolfsonmicro.com  Mon Apr  1 09:53:08 2013
From: broonie at opensource.wolfsonmicro.com (Mark Brown)
Date: Mon, 1 Apr 2013 14:53:08 +0100
Subject: [PATCH v7 09/14] spi/spi-atmel: correct 16 bits transfers using
 PIO
In-Reply-To: <1363679279-4045-1-git-send-email-wenyou.yang@atmel.com>
References: <1363678866-3567-1-git-send-email-wenyou.yang@atmel.com>
 <1363679279-4045-1-git-send-email-wenyou.yang@atmel.com>
Message-ID: <20130401135308.GA18636@opensource.wolfsonmicro.com>

On Tue, Mar 19, 2013 at 03:47:59PM +0800, Wenyou Yang wrote:
> From: Richard Genoud <richard.genoud at gmail.com>
> 
> Signed-off-by: Richard Genoud <richard.genoud at gmail.com>
> Cc: spi-devel-general at lists.sourceforge.net
> Cc: linux-kernel at vger.kernel.org
> [wenyou.yang at atmel.com: submit the patch]
> Signed-off-by: Wenyou Yang <wenyou.yang at atmel.com>

This looks like a bug fix to the exiting code rather than something new
for dmaengine - it should really have been sent at the start of the
series so it can be applied a bug fix and sent to mainline faster.

Some sort of description of what was wrong and how it got fixed would've
been good in the changelog.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130401/6507b9f4/attachment.sig>

From broonie at opensource.wolfsonmicro.com  Mon Apr  1 09:53:59 2013
From: broonie at opensource.wolfsonmicro.com (Mark Brown)
Date: Mon, 1 Apr 2013 14:53:59 +0100
Subject: [PATCH v7 10/14] spi/spi-atmel: correct 16 bits transfers with DMA
In-Reply-To: <1363679341-4087-1-git-send-email-wenyou.yang@atmel.com>
References: <1363678866-3567-1-git-send-email-wenyou.yang@atmel.com>
 <1363679341-4087-1-git-send-email-wenyou.yang@atmel.com>
Message-ID: <20130401135359.GB18636@opensource.wolfsonmicro.com>

On Tue, Mar 19, 2013 at 03:49:01PM +0800, Wenyou Yang wrote:
> From: Richard Genoud <richard.genoud at gmail.com>
> 
> Signed-off-by: Richard Genoud <richard.genoud at gmail.com>
> Cc: spi-devel-general at lists.sourceforge.net
> Cc: linux-kernel at vger.kernel.org
> [wenyou.yang at atmel.com: submit the patch]
> Signed-off-by: Wenyou Yang <wenyou.yang at atmel.com>

Shouldn't this be squashed into the dmaengine patch?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130401/46da3b0d/attachment.sig>

From stefano.stabellini at eu.citrix.com  Mon Apr  1 10:42:18 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Mon, 1 Apr 2013 15:42:18 +0100
Subject: [PATCH v4 2/2] arm: prefer PSCI for SMP bringup
In-Reply-To: <5155EC28.8050608@gmail.com>
References: <1364575371-8926-2-git-send-email-stefano.stabellini@eu.citrix.com>
 <alpine.LFD.2.03.1303291320580.1372@syhkavp.arg>
 <alpine.DEB.2.02.1303291735080.4430@kaball.uk.xensource.com>
 <alpine.LFD.2.03.1303291349150.1372@syhkavp.arg>
 <5155EC28.8050608@gmail.com>
Message-ID: <alpine.DEB.2.02.1304011541010.5078@kaball.uk.xensource.com>

On Fri, 29 Mar 2013, Rob Herring wrote:
> On 03/29/2013 12:53 PM, Nicolas Pitre wrote:
> > On Fri, 29 Mar 2013, Stefano Stabellini wrote:
> > 
> >> On Fri, 29 Mar 2013, Nicolas Pitre wrote:
> >>> On Fri, 29 Mar 2013, Stefano Stabellini wrote:
> >>>
> >>>> If PSCI initializes correctly and PSCI SMP operations are available, use them.
> >>>> This is required for SMP support in Dom0 on Xen.
> >>>>
> >>>> Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
> >>>> CC: will.deacon at arm.com
> >>>> CC: arnd at arndb.de
> >>>> CC: marc.zyngier at arm.com
> >>>> CC: linux at arm.linux.org.uk
> >>>> CC: nico at linaro.org
> >>>
> >>> I'd suggest you also include in your series the patch I posted earlier 
> >>> providing a runtime mdesc->smp_init method as well.
> >>
> >> OK.
> >>
> >>
> >>> This way the 
> >>> priority order would be:
> >>>
> >>> - If mdesc->smp_init is non null then use that.
> >>>
> >>> - Otherwise, if PSCI is available then use that.
> >>>
> >>> - Otherwise use mdesc->smp.
> >>>
> >>> This way, if the PSCI default has to be overriden (like in the MCPM case 
> >>> because it needs to wrap PSCI itself, or to cover Rob's concern) then 
> >>> this can be achieved at run time on a per mdesc basis.
> >>
> >> Actually that's not a bad idea, it could make everybody happy.
> >> What about the following, in this precise order:
> >>
> >> - if a xen hypervisor node is present on device tree, use PSCI;
> >> - otherwise if mdesc->smp_init is non null then use it;
> >> - otherwise if PSCI is available then use it;
> >> - otherwise use mdesc->smp.
> >>
> >> It's the most practical solution to satisfy everybody's needs.
> > 
> > Maybe I'm missing something obvious, but why can't xen declare a mdesc 
> > of its own?  Given it is going to tweak the DT passed to the kernel 
> > anyway that shouldn't be a problem.
> 
> Xen does have it's own mdesc. It is (or will be) mach-virt, but that is
> only for DomU guests. For Dom0, you still need all the platform specific
> code except smp_ops. However, I'm doubtful this would work without other
> changes on more complicated platforms like OMAP.
> 
> I would say wait to add this until you have platforms that actually need
> the first case.

OK, that is not unreasonable.

What are the platforms that are going to use smp_init? Do we know how do
they intend to use it?


From pavel at ucw.cz  Mon Apr  1 10:43:56 2013
From: pavel at ucw.cz (Pavel Machek)
Date: Mon, 1 Apr 2013 16:43:56 +0200
Subject: ARM: dts: MicroSys sbc6x support (i.MX6)
In-Reply-To: <20130401125114.GA24039@S2101-09.ap.freescale.net>
References: <20130329185500.GB30029@amd.pavel.ucw.cz>
 <20130330113703.GA21042@amd.pavel.ucw.cz>
 <5156D69E.3050600@gmail.com>
 <20130331201614.GC25751@amd.pavel.ucw.cz>
 <20130401064224.GD1693@S2101-09.ap.freescale.net>
 <20130401122422.GA13982@amd.pavel.ucw.cz>
 <20130401125114.GA24039@S2101-09.ap.freescale.net>
Message-ID: <20130401144356.GA19571@amd.pavel.ucw.cz>

On Mon 2013-04-01 20:51:16, Shawn Guo wrote:
> On Mon, Apr 01, 2013 at 02:24:22PM +0200, Pavel Machek wrote:
> > >   git://git.linaro.org/people/shawnguo/linux-2.6.git imx/dt
> > 
> > I took a look, and it should apply cleanly to that branch.
> > 
> It can apply cleanly, but it does not work, because all imx dts files
> got renamed to support macros.

Aha, sorry, I did not realize that :-(.

> > Updated patch is below, please apply,
> 
> I applied it with some fixup.  Please use git send-email in the future,
> so that git am can just work out everything for me.

Thanks!
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


From luis.henriques at canonical.com  Mon Apr  1 11:04:35 2013
From: luis.henriques at canonical.com (Luis Henriques)
Date: Mon,  1 Apr 2013 16:04:35 +0100
Subject: [ 3.5.y.z extended stable ] Patch "clockevents: Don't allow dummy
 broadcast timers" has been added to staging queue
Message-ID: <1364828675-11216-1-git-send-email-luis.henriques@canonical.com>

This is a note to let you know that I have just added a patch titled

    clockevents: Don't allow dummy broadcast timers

to the linux-3.5.y-queue branch of the 3.5.y.z extended stable tree 
which can be found at:

 http://kernel.ubuntu.com/git?p=ubuntu/linux.git;a=shortlog;h=refs/heads/linux-3.5.y-queue

If you, or anyone else, feels it should not be added to this tree, please 
reply to this email.

For more information about the 3.5.y.z tree, see
https://wiki.ubuntu.com/Kernel/Dev/ExtendedStable

Thanks.
-Luis

------

>From 047c562aeae314a54669cc451e4763b0fc22f2b5 Mon Sep 17 00:00:00 2001
From: Mark Rutland <mark.rutland at arm.com>
Date: Thu, 7 Mar 2013 15:09:24 +0000
Subject: [PATCH] clockevents: Don't allow dummy broadcast timers

commit a7dc19b8652c862d5b7c4d2339bd3c428bd29c4a upstream.

Currently tick_check_broadcast_device doesn't reject clock_event_devices
with CLOCK_EVT_FEAT_DUMMY, and may select them in preference to real
hardware if they have a higher rating value. In this situation, the
dummy timer is responsible for broadcasting to itself, and the core
clockevents code may attempt to call non-existent callbacks for
programming the dummy, eventually leading to a panic.

This patch makes tick_check_broadcast_device always reject dummy timers,
preventing this problem.

Signed-off-by: Mark Rutland <mark.rutland at arm.com>
Cc: linux-arm-kernel at lists.infradead.org
Cc: Jon Medhurst (Tixy) <tixy at linaro.org>
Signed-off-by: Thomas Gleixner <tglx at linutronix.de>
Signed-off-by: Luis Henriques <luis.henriques at canonical.com>
---
 kernel/time/tick-broadcast.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/kernel/time/tick-broadcast.c b/kernel/time/tick-broadcast.c
index f113755..a13987a 100644
--- a/kernel/time/tick-broadcast.c
+++ b/kernel/time/tick-broadcast.c
@@ -66,7 +66,8 @@ static void tick_broadcast_start_periodic(struct clock_event_device *bc)
  */
 int tick_check_broadcast_device(struct clock_event_device *dev)
 {
-	if ((tick_broadcast_device.evtdev &&
+	if ((dev->features & CLOCK_EVT_FEAT_DUMMY) ||
+	    (tick_broadcast_device.evtdev &&
 	     tick_broadcast_device.evtdev->rating >= dev->rating) ||
 	     (dev->features & CLOCK_EVT_FEAT_C3STOP))
 		return 0;
--
1.8.1.2



From stern at rowland.harvard.edu  Mon Apr  1 11:27:14 2013
From: stern at rowland.harvard.edu (Alan Stern)
Date: Mon, 1 Apr 2013 11:27:14 -0400 (EDT)
Subject: [PATCH v3 2/7] USB: EHCI: make ehci-spear a separate driver
In-Reply-To: <201303311830.11338.arnd@arndb.de>
Message-ID: <Pine.LNX.4.44L0.1304011126190.1036-100000@iolanthe.rowland.org>

On Sun, 31 Mar 2013, Arnd Bergmann wrote:

> On Saturday 30 March 2013, Arnd Bergmann wrote:
> > > > In V3:
> > > >  -Detailed commit message added here about why this patch is required.
> > > >  -Eliminated ehci_spear_setup routine beacuse hcd registers
> > > >   directly setting in spear_ehci_hcd_drv_probe function.
> > > 
> > > Fix the grammar, please.
> > 
> > Done. I agree some of this is hardly legible.
> > 
> 
> I realized later that the other patches have similarly screwed up
> changelogs. I'll send a new version once you've commented on v4,
> so in case there is anything else I missed I'm not spamming everyone
> another time.

I still haven't checked the details of the last patch in the series 
(the OHCI changes).  However, for patches 1/6 - 5/6:

Acked-by: Alan Stern <stern at rowland.harvard.edu>



From stern at rowland.harvard.edu  Mon Apr  1 11:29:34 2013
From: stern at rowland.harvard.edu (Alan Stern)
Date: Mon, 1 Apr 2013 11:29:34 -0400 (EDT)
Subject: [PATCH v3 7/7] USB: OHCI: avoid conflicting platform drivers
In-Reply-To: <201303301256.19027.arnd@arndb.de>
Message-ID: <Pine.LNX.4.44L0.1304011128110.1036-100000@iolanthe.rowland.org>

On Sat, 30 Mar 2013, Arnd Bergmann wrote:

> > I guess this means the onus is now on me to split up ohci-hcd into a 
> > central library and separate bus drivers, like ehci-hcd...
> 
> The original plan in my teams was that Manjunath would do that after
> he was done with the simple conversion of the EHCI drivers. I think we
> can all agree now that it's better if you at least the groundwork instead.

Yes, it would be better for me to prepare for the general split-up.

> Please let us know if you would like Manjunath to continue with splitting
> out the OHCI back-ends into separate drivers, or if you think that there
> is no point given the quality of the earlier patches.

This is how people learn.  After I have taken care of the initial steps 
and converted a couple of the drivers, Manjunath can work on the rest.

Alan Stern



From tony at atomide.com  Mon Apr  1 11:53:45 2013
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 1 Apr 2013 08:53:45 -0700
Subject: [PATCH] ARM: OMAP1: remove "config MACH_OMAP_HTCWIZARD"
In-Reply-To: <1363901769.1390.159.camel@x61.thuisdomein>
References: <1363901769.1390.159.camel@x61.thuisdomein>
Message-ID: <20130401155345.GD10155@atomide.com>

* Paul Bolle <pebolle at tiscali.nl> [130321 14:40]:
> The Kconfig symbol MACH_OMAP_HTCWIZARD got added in v2.6.30. It has
> never been used. Its entry can safely be removed.
> 
> Signed-off-by: Paul Bolle <pebolle at tiscali.nl>
> ---
> Untested.

Thanks, applying into omap-for-v3.10/fixes-non-critical.

Regards,

Tony
 
>  arch/arm/mach-omap1/Kconfig | 6 ------
>  1 file changed, 6 deletions(-)
> 
> diff --git a/arch/arm/mach-omap1/Kconfig b/arch/arm/mach-omap1/Kconfig
> index 903da8e..cdd05f2 100644
> --- a/arch/arm/mach-omap1/Kconfig
> +++ b/arch/arm/mach-omap1/Kconfig
> @@ -55,12 +55,6 @@ config MACH_OMAP_H3
>  	  TI OMAP 1710 H3 board support. Say Y here if you have such
>  	  a board.
>  
> -config MACH_OMAP_HTCWIZARD
> -	bool "HTC Wizard"
> -	depends on ARCH_OMAP850
> -	help
> -	  HTC Wizard smartphone support (AKA QTEK 9100, ...)
> -
>  config MACH_HERALD
>  	bool "HTC Herald"
>  	depends on ARCH_OMAP850
> -- 
> 1.7.11.7
> 


From tony at atomide.com  Mon Apr  1 11:54:15 2013
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 1 Apr 2013 08:54:15 -0700
Subject: [PATCH] omap: fix typo "CONFIG_BRIDGE_DVFS"
In-Reply-To: <1364254205.1390.307.camel@x61.thuisdomein>
References: <1364254205.1390.307.camel@x61.thuisdomein>
Message-ID: <20130401155414.GE10155@atomide.com>

* Paul Bolle <pebolle at tiscali.nl> [130325 16:34]:
> Commit 90173882ed15a8034d6d162da5f343a2c7d87587 ("omap: add dsp platform
> device") used CONFIG_BRIDGE_DVFS were it obviously meant
> CONFIG_TIDSPBRIDGE_DVFS. Fix that.
> 
> Signed-off-by: Paul Bolle <pebolle at tiscali.nl>
> ---
> Untested. As this typo has been in the tree since v2.6.37, this really
> needs some testing.

Thanks, applying into omap-for-v3.10/fixes-non-critical.

Regards,

Tony
 
>  arch/arm/mach-omap2/dsp.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/dsp.c b/arch/arm/mach-omap2/dsp.c
> index b155500..b8208b4 100644
> --- a/arch/arm/mach-omap2/dsp.c
> +++ b/arch/arm/mach-omap2/dsp.c
> @@ -26,7 +26,7 @@
>  #include "control.h"
>  #include "cm2xxx_3xxx.h"
>  #include "prm2xxx_3xxx.h"
> -#ifdef CONFIG_BRIDGE_DVFS
> +#ifdef CONFIG_TIDSPBRIDGE_DVFS
>  #include "omap-pm.h"
>  #endif
>  
> @@ -35,7 +35,7 @@
>  static struct platform_device *omap_dsp_pdev;
>  
>  static struct omap_dsp_platform_data omap_dsp_pdata __initdata = {
> -#ifdef CONFIG_BRIDGE_DVFS
> +#ifdef CONFIG_TIDSPBRIDGE_DVFS
>  	.dsp_set_min_opp = omap_pm_dsp_set_min_opp,
>  	.dsp_get_opp = omap_pm_dsp_get_opp,
>  	.cpu_set_freq = omap_pm_cpu_set_freq,
> -- 
> 1.7.11.7
> 


From tony at atomide.com  Mon Apr  1 11:55:51 2013
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 1 Apr 2013 08:55:51 -0700
Subject: [GIT PULL] ARM: OMAP2+: PRCM fixes for 3.10
In-Reply-To: <alpine.DEB.2.00.1304011042310.28273@utopia.booyaka.com>
References: <alpine.DEB.2.00.1304011042310.28273@utopia.booyaka.com>
Message-ID: <20130401155551.GF10155@atomide.com>

* Paul Walmsley <paul at pwsan.com> [130401 03:48]:
> Hi Tony
> 
> The following changes since commit 07961ac7c0ee8b546658717034fe692fd12eefa9:
> 
>   Linux 3.9-rc5 (2013-03-31 15:12:43 -0700)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git tags/omap-devel-b-for-3.10
> 
> for you to fetch changes up to 469d633d20c774ecd34ac615c838193e1e150c62:
> 
>   ARM: OMAP: dpll: enable bypass clock only when attempting dpll bypass (2013-03-31 20:43:06 -0600)
> 
> ----------------------------------------------------------------
> Some miscellaneous OMAP hwmod, powerdomain, and clock fixes for 3.10.
> 
> Basic test logs are here:
> 
> http://www.pwsan.com/omap/testlogs/prcm_fixes_a_3.10/20130331205716/

Thanks applying into omap-for-v3.10/fixes-non-critical.

Regards,

Tony


From jason at lakedaemon.net  Mon Apr  1 11:57:24 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Mon, 1 Apr 2013 11:57:24 -0400
Subject: [PATCH] Fix typo in the definition of ix2-200 rebuild LED
In-Reply-To: <1364817802-7889-2-git-send-email-nigel@nobiscuit.com>
References: <1364817802-7889-1-git-send-email-nigel@nobiscuit.com>
 <1364817802-7889-2-git-send-email-nigel@nobiscuit.com>
Message-ID: <20130401155724.GO13280@titan.lakedaemon.net>

On Mon, Apr 01, 2013 at 11:03:22PM +1100, Nigel Roberts wrote:
> In the conversion to pinctrl, an error in the pins for the rebuild
> LED was introduced. This patch assigns the correct pins and includes
> the correct name for the LED in kirkwood-iomega_ix2_200.dts.
> 
> Signed-off-by: Nigel Roberts <nigel at nobiscuit.com>
> ---
>  arch/arm/boot/dts/kirkwood-iomega_ix2_200.dts |   14 +++++++-------
>  1 file changed, 7 insertions(+), 7 deletions(-)

Applied to mvebu/fixes, also flagged it for -stable, v3.8.x

thx,

Jason.


From swarren at wwwdotorg.org  Mon Apr  1 12:08:31 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Mon, 01 Apr 2013 10:08:31 -0600
Subject: [PATCH 1/2] ARM: tegra: move <mach/powergate.h> to
 <linux/tegra-powergate.h>
In-Reply-To: <201303301413.26549.arnd@arndb.de>
References: <1364602790-10759-1-git-send-email-swarren@wwwdotorg.org>
 <201303301413.26549.arnd@arndb.de>
Message-ID: <5159B0FF.2010408@wwwdotorg.org>

On 03/30/2013 08:13 AM, Arnd Bergmann wrote:
> On Saturday 30 March 2013, Stephen Warren wrote:
>> From: Stephen Warren <swarren at nvidia.com>
>>
>> This is required so that code such as Tegra's PCIe and clock drivers
>> can still access this header file once Tegra is converted to
>> multiplatform, and <mach/> no longer exists.
>>
>> Signed-off-by: Stephen Warren <swarren at nvidia.com>
> 
> It sounds like this should be integrated in the reset controller API
> that Philipp Zabel just posted. I'm not blaming you for now knowing
> about it, since I only saw it myself a few days ago, and my interpretation
> could be wrong. Are you able to move to that API before 3.10?

Well, I wrote the binding for it:-)

> If not, we can probably take your patch for now, if you remove it
> again for 3.11.

There are at least a couple of different things in this file:

a) The reset API, which definitely should be converted to the new reset
API. I can't make any promises about which kernel release that will
happen in, but it's definitely something we know we have to do.

b) Power-gating. This should probably be converted to use the
powerdomains code. I believe Joseph Lo is aware of this, but again I
can't promise any specific time-scale at this time.

So is this still OK, without any promises of timescale?


From simon.guinot at sequanux.org  Mon Apr  1 12:33:16 2013
From: simon.guinot at sequanux.org (Simon Guinot)
Date: Mon, 1 Apr 2013 18:33:16 +0200
Subject: [PATCH] ARM: kirkwood: DT board setup for CloudBox
In-Reply-To: <51568B89.1060009@free.fr>
References: <1364555206-5870-1-git-send-email-simon.guinot@sequanux.org>
 <20130329153132.GJ13280@titan.lakedaemon.net>
 <20130329184109.GA16404@kw.sim.vm.gnt> <51568B89.1060009@free.fr>
Message-ID: <20130401163316.GC16404@kw.sim.vm.gnt>

On Sat, Mar 30, 2013 at 07:51:53AM +0100, Chris Moore wrote:
> Hi Simon et al.
> 
> Le 29/03/2013 19:41, Simon Guinot a ?crit :
> >On Fri, Mar 29, 2013 at 11:31:32AM -0400, Jason Cooper wrote:
> >>Neat! another new board!
> >Others are coming :)
> 
> That's great, thank you.

Hi Chris,

It is nice to hear from you :)

> 
> >>On Fri, Mar 29, 2013 at 12:06:46PM +0100, Simon Guinot wrote:
> >>>This patch adds DT board setup for the LaCie NAS CloudBox. The CloudBox
> >>>is a low cost NAS based on the Network Space v2.
> >>>
> >>>Chipset list:
> >>>- CPU MARVELL 88F6702 1Ghz
> >>>- SDRAM memory: 256MB DDR2-800 (2x128MB x8) 400Mhz
> >>>- 1 Ethernet Gigabit port (PHY MARVELL 88E1318)
> >>>- SPI flash, NOR 512KB
> >>>- 1 push button
> >>>- 2 LEDs (red and blue)
> >>>
> >>>+
> >>>+/ {
> >>>+	model = "LaCie CloudBox";
> >>>+	compatible = "lacie,cloudbox", "marvell,kirkwood-88f6702", "marvell,kirkwood";
> >>Is there a more specific string we can add here?  eg
> >>"lacie,cloudbox-MODEL", "lacie,cloudbox", ...
> >Unfortunately no. CloudBox is a product name which is also used by LaCie
> >to name the board and the project.
> >
> 
> I think it really is necessary to have a more specific name.
> I have two, very different, products corresponding to LaCie CloudBox:
> - The first one was a small black one with a 2.5" disk reviewed
> here: http://www.smallnetbuilder.com/cloud/cloud-storage/462-lacie-cloudbox-reviewed
> - The later one is a larger white one with a 3.5" disk described
> here: http://www.smallnetbuilder.com/nas/nas-news/31927-lacie-relaunches-its-cloud-connected-nas
> 
> IIRC the later one was originally called "CloudBox Family" although
> maybe Family was dropped when it was officially released.

Indeed, there is two (or rather one and half) released products called
CloudBox.

The old one (the first smallnetbuilder link) has been first called
Network Space v2 mini, then SafeBox and finally released under the name
Cloudbox. Very very few products have been sold. I don't know any owner
and I suspect you got yours from the LaCie beta test program :)

The new CloudBox is a very different product which has been first named
FamilyBox and then released under the CloudBox name. Because the previous
CloudBox was a really confidential product, the marketing guys have
decided to reuse the name. This was a bad idea and despite the warnings
they did that even so.

Now, the fact is that the new CloudBox is a huge-selling LaCie product.
That's why I propose to keep the names just as they are.

Regards,

Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130401/7cd49eb9/attachment.sig>

From ezequiel.garcia at free-electrons.com  Mon Apr  1 21:37:41 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Mon, 1 Apr 2013 22:37:41 -0300
Subject: [PATCH v2 1/4] thermal: Add driver for Armada 370/XP SoC thermal
 management
In-Reply-To: <1364435017.2275.20.camel@rzhang1-mobl4>
References: <1364292988-8358-1-git-send-email-ezequiel.garcia@free-electrons.com>
 <1364292988-8358-2-git-send-email-ezequiel.garcia@free-electrons.com>
 <1364435017.2275.20.camel@rzhang1-mobl4>
Message-ID: <20130402013740.GA28373@localhost>

Hi Zhang,

On Thu, Mar 28, 2013 at 09:43:37AM +0800, Zhang Rui wrote:
> On Tue, 2013-03-26 at 07:16 -0300, Ezequiel Garcia wrote:
> > This driver supports both Armada 370 and Armada XP SoC
> > thermal management controllers.
> > 
> > Armada 370 has a register to check a valid temperature, whereas
> > Armada XP does not. Each has a different initialization (i.e. calibration)
> > function. The temperature conversion formula is the same for both.
> > 
> > The controller present in each SoC have a very similar feature set,
> > so it corresponds to have one driver to support both of them.
> > 
> > Although this driver may present similarities to Dove and Kirkwood
> > thermal driver, the exact differences and coincidences are not fully
> > known. For this reason, support is given through a separate driver.
> > 
> > Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
> > ---

[...]

> > +static void armadaxp_init_sensor(struct armada_thermal_priv *priv)
> > +{
> > +	unsigned long reg;
> > +
> > +	/* ??? */
> 
> what does this comment mean?
> 

In the case you'd prefer those comments to be removed,
here's a patch that does just that.

Is it possible for you to take it instead of the previous one,
in this form?

------------------------------------8<----------------------------------------
diff --git a/Documentation/devicetree/bindings/thermal/armada-thermal.txt b/Documentation/devicetree/bindings/thermal/armada-thermal.txt
new file mode 100644
index 0000000..fff93d5
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/armada-thermal.txt
@@ -0,0 +1,22 @@
+* Marvell Armada 370/XP thermal management
+
+Required properties:
+
+- compatible:	Should be set to one of the following:
+		marvell,armada370-thermal
+		marvell,armadaxp-thermal
+
+- reg:		Device's register space.
+		Two entries are expected, see the examples below.
+		The first one is required for the sensor register;
+		the second one is required for the control register
+		to be used for sensor initialization (a.k.a. calibration).
+
+Example:
+
+	thermal at d0018300 {
+		compatible = "marvell,armada370-thermal";
+                reg = <0xd0018300 0x4
+		       0xd0018304 0x4>;
+		status = "okay";
+	};
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index a764f16..9eddf74 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -144,6 +144,14 @@ config DB8500_THERMAL
 	  created. Cooling devices can be bound to the trip points to cool this
 	  thermal zone if trip points reached.
 
+config ARMADA_THERMAL
+	tristate "Armada 370/XP thermal management"
+	depends on ARCH_MVEBU
+	depends on OF
+	help
+	  Enable this option if you want to have support for thermal management
+	  controller present in Armada 370 and Armada XP SoC.
+
 config DB8500_CPUFREQ_COOLING
 	tristate "DB8500 cpufreq cooling"
 	depends on ARCH_U8500
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index d3a2b38..7f6509a 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -19,6 +19,7 @@ obj-$(CONFIG_KIRKWOOD_THERMAL)  += kirkwood_thermal.o
 obj-$(CONFIG_EXYNOS_THERMAL)	+= exynos_thermal.o
 obj-$(CONFIG_DOVE_THERMAL)  	+= dove_thermal.o
 obj-$(CONFIG_DB8500_THERMAL)	+= db8500_thermal.o
+obj-$(CONFIG_ARMADA_THERMAL)	+= armada_thermal.o
 obj-$(CONFIG_DB8500_CPUFREQ_COOLING)	+= db8500_cpufreq_cooling.o
 obj-$(CONFIG_INTEL_POWERCLAMP)	+= intel_powerclamp.o
 
diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
new file mode 100644
index 0000000..5b4d75f
--- /dev/null
+++ b/drivers/thermal/armada_thermal.c
@@ -0,0 +1,232 @@
+/*
+ * Marvell Armada 370/XP thermal sensor driver
+ *
+ * Copyright (C) 2013 Marvell
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/of.h>
+#include <linux/module.h>
+#include <linux/delay.h>
+#include <linux/platform_device.h>
+#include <linux/of_device.h>
+#include <linux/thermal.h>
+
+#define THERMAL_VALID_OFFSET		9
+#define THERMAL_VALID_MASK		0x1
+#define THERMAL_TEMP_OFFSET		10
+#define THERMAL_TEMP_MASK		0x1ff
+
+/* Thermal Manager Control and Status Register */
+#define PMU_TDC0_SW_RST_MASK		(0x1 << 1)
+#define PMU_TM_DISABLE_OFFS		0
+#define PMU_TM_DISABLE_MASK		(0x1 << PMU_TM_DISABLE_OFFS)
+#define PMU_TDC0_REF_CAL_CNT_OFFS	11
+#define PMU_TDC0_REF_CAL_CNT_MASK	(0x1ff << PMU_TDC0_REF_CAL_CNT_OFFS)
+#define PMU_TDC0_OTF_CAL_MASK		(0x1 << 30)
+#define PMU_TDC0_START_CAL_MASK		(0x1 << 25)
+
+struct armada_thermal_ops;
+
+/* Marvell EBU Thermal Sensor Dev Structure */
+struct armada_thermal_priv {
+	void __iomem *sensor;
+	void __iomem *control;
+	struct armada_thermal_ops *ops;
+};
+
+struct armada_thermal_ops {
+	/* Initialize the sensor */
+	void (*init_sensor)(struct armada_thermal_priv *);
+
+	/* Test for a valid sensor value (optional) */
+	bool (*is_valid)(struct armada_thermal_priv *);
+};
+
+static void armadaxp_init_sensor(struct armada_thermal_priv *priv)
+{
+	unsigned long reg;
+
+	reg = readl_relaxed(priv->control);
+	reg |= PMU_TDC0_OTF_CAL_MASK;
+	writel(reg, priv->control);
+
+	/* Reference calibration value */
+	reg &= ~PMU_TDC0_REF_CAL_CNT_MASK;
+	reg |= (0xf1 << PMU_TDC0_REF_CAL_CNT_OFFS);
+	writel(reg, priv->control);
+
+	/* Reset the sensor */
+	reg = readl_relaxed(priv->control);
+	writel((reg | PMU_TDC0_SW_RST_MASK), priv->control);
+
+	writel(reg, priv->control);
+
+	/* Enable the sensor */
+	reg = readl_relaxed(priv->sensor);
+	reg &= ~PMU_TM_DISABLE_MASK;
+	writel(reg, priv->sensor);
+}
+
+static void armada370_init_sensor(struct armada_thermal_priv *priv)
+{
+	unsigned long reg;
+
+	reg = readl_relaxed(priv->control);
+	reg |= PMU_TDC0_OTF_CAL_MASK;
+	writel(reg, priv->control);
+
+	/* Reference calibration value */
+	reg &= ~PMU_TDC0_REF_CAL_CNT_MASK;
+	reg |= (0xf1 << PMU_TDC0_REF_CAL_CNT_OFFS);
+	writel(reg, priv->control);
+
+	reg &= ~PMU_TDC0_START_CAL_MASK;
+	writel(reg, priv->control);
+
+	mdelay(10);
+}
+
+static bool armada_is_valid(struct armada_thermal_priv *priv)
+{
+	unsigned long reg = readl_relaxed(priv->sensor);
+
+	return (reg >> THERMAL_VALID_OFFSET) & THERMAL_VALID_MASK;
+}
+
+static int armada_get_temp(struct thermal_zone_device *thermal,
+			  unsigned long *temp)
+{
+	struct armada_thermal_priv *priv = thermal->devdata;
+	unsigned long reg;
+
+	/* Valid check */
+	if (priv->ops->is_valid && !priv->ops->is_valid(priv)) {
+		dev_err(&thermal->device,
+			"Temperature sensor reading not valid\n");
+		return -EIO;
+	}
+
+	reg = readl_relaxed(priv->sensor);
+	reg = (reg >> THERMAL_TEMP_OFFSET) & THERMAL_TEMP_MASK;
+	*temp = (3153000000UL - (10000000UL*reg)) / 13825;
+	return 0;
+}
+
+static struct thermal_zone_device_ops ops = {
+	.get_temp = armada_get_temp,
+};
+
+static const struct armada_thermal_ops armadaxp_ops = {
+	.init_sensor = armadaxp_init_sensor,
+};
+
+static const struct armada_thermal_ops armada370_ops = {
+	.is_valid = armada_is_valid,
+	.init_sensor = armada370_init_sensor,
+};
+
+static const struct of_device_id armada_thermal_id_table[] = {
+	{
+		.compatible = "marvell,armadaxp-thermal",
+		.data       = &armadaxp_ops,
+	},
+	{
+		.compatible = "marvell,armada370-thermal",
+		.data       = &armada370_ops,
+	},
+	{
+		/* sentinel */
+	},
+};
+MODULE_DEVICE_TABLE(of, armada_thermal_id_table);
+
+static int armada_thermal_probe(struct platform_device *pdev)
+{
+	struct thermal_zone_device *thermal;
+	const struct of_device_id *match;
+	struct armada_thermal_priv *priv;
+	struct resource *res;
+
+	match = of_match_device(armada_thermal_id_table, &pdev->dev);
+	if (!match)
+		return -ENODEV;
+
+	priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
+	if (!priv)
+		return -ENOMEM;
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	if (!res) {
+		dev_err(&pdev->dev, "Failed to get platform resource\n");
+		return -ENODEV;
+	}
+
+	priv->sensor = devm_ioremap_resource(&pdev->dev, res);
+	if (IS_ERR(priv->sensor))
+		return PTR_ERR(priv->sensor);
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+	if (!res) {
+		dev_err(&pdev->dev, "Failed to get platform resource\n");
+		return -ENODEV;
+	}
+
+	priv->control = devm_ioremap_resource(&pdev->dev, res);
+	if (IS_ERR(priv->control))
+		return PTR_ERR(priv->control);
+
+	priv->ops = (struct armada_thermal_ops *)match->data;
+	priv->ops->init_sensor(priv);
+
+	thermal = thermal_zone_device_register("armada_thermal", 0, 0,
+					       priv, &ops, NULL, 0, 0);
+	if (IS_ERR(thermal)) {
+		dev_err(&pdev->dev,
+			"Failed to register thermal zone device\n");
+		return PTR_ERR(thermal);
+	}
+
+	platform_set_drvdata(pdev, thermal);
+
+	return 0;
+}
+
+static int armada_thermal_exit(struct platform_device *pdev)
+{
+	struct thermal_zone_device *armada_thermal =
+		platform_get_drvdata(pdev);
+
+	thermal_zone_device_unregister(armada_thermal);
+	platform_set_drvdata(pdev, NULL);
+
+	return 0;
+}
+
+static struct platform_driver armada_thermal_driver = {
+	.probe = armada_thermal_probe,
+	.remove = armada_thermal_exit,
+	.driver = {
+		.name = "armada_thermal",
+		.owner = THIS_MODULE,
+		.of_match_table = of_match_ptr(armada_thermal_id_table),
+	},
+};
+
+module_platform_driver(armada_thermal_driver);
+
+MODULE_AUTHOR("Ezequiel Garcia <ezequiel.garcia at free-electrons.com>");
+MODULE_DESCRIPTION("Armada 370/XP thermal driver");
+MODULE_LICENSE("GPL v2");
------------------------------------>8----------------------------------------

-- 
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com


From chf.fritz at googlemail.com  Mon Apr  1 12:41:48 2013
From: chf.fritz at googlemail.com (Christoph Fritz)
Date: Mon, 01 Apr 2013 18:41:48 +0200
Subject: [RFC][BUG] arm/dts: OMAP3: set #interrupt-cells to two
In-Reply-To: <CAAwP0s35J-edpvFv08xjjpwaezQBYNvMNhhXL-UacsuUtSt4ZA@mail.gmail.com>
References: <1364631689.3767.7.camel@mars>
 <CAAwP0s35J-edpvFv08xjjpwaezQBYNvMNhhXL-UacsuUtSt4ZA@mail.gmail.com>
Message-ID: <1364834508.3939.74.camel@mars>

Hi Javier

On Sat, 2013-03-30 at 14:18 +0100, Javier Martinez Canillas wrote:
> A call to gpio_request() to enable the GPIO bank is needed before
> using a GPIO as an IRQ source, otherwise accesses to the GPIO bank
> registers fails making the kernel to hang.

Yes, that is exactly my problem here. I'm using the GPIO as an IRQ
source.

> Jon's (added as cc)"gpio/omap: warn if bank is not enabled on setting
> irq type" patch [1] fixes the issue by warning and returning -EINVAL.
> 
> This patch will make the kernel to boot but the call to request_irq()
> will fail of course. For now, the only solution is to call
> gpio_request() before request_irq() in your platform code or device
> driver. There is an on going discussion about what's the better way to
> address this but we still haven't found a good solution to this
> problem, you can see the last email for this discussion here [2]
> 
> Also, even when calling gpio_request() before request_irq() this won't
> work. When specifying the trigger/level flags on the second cell for
> an GPIO-IRQ, this is not set on the IORESOURCE_IRQ struct resource.
> The IRQ flag is set on of_irq_to_resource() but it just does:
> 
> r->flags = IORESOURCE_IRQ;
> 
> and then the call stack is irq_to_parse_and_map() ->
> irq_set_irq_type() ->  __irq_set_trigger() -> chip->irq_set_type() ->
> (drivers/gpio/gpio-omap.c) gpio_irq_type().
> 
> So, even when gpio_irq_type() receive the correct flags, this are not
> returned neither stored on the flags member of the IORESOURCE_IRQ
> struct resource that passed to the drivers in their struct
> platform_device.

As a quick-fix (hack) I wrote directly to the registers in gpio_probe()
to enable GPIO banks. I now geht this:

> > [    0.214630] omap_gpio_probe, 1133, CM_CLKSEL_PER 0x48005040: 0x000000ff
> > [    0.214660] omap_gpio_probe, 1136, CM_ICLKEN_PER 0x48005010: 0x0007ffff
> > [    0.214660] omap_gpio_probe, 1139, CM_FCLKEN_PER 0x48005000: 0x0007ffff

And it works for me. _But_ when I do enable regulator twl4030
(CONFIG_REGULATOR_TWL4030=y) in my config these registers get reset:

[    2.935455] smsc911x_open, 1537, CM_CLKSEL_PER 0x48005040: 0x000000ff
[    2.942291] smsc911x_open, 1540, CM_ICLKEN_PER 0x48005010: 0x00040fff
[    2.949066] smsc911x_open, 1543, CM_FCLKEN_PER 0x48005000: 0x00000000

And the IRQ source for the network chip (smsc911x) is disabled :-(

Do you have any idea how to ("quick") fix this?

 Thanks
  -- Christoph



From simon.guinot at sequanux.org  Mon Apr  1 12:44:11 2013
From: simon.guinot at sequanux.org (Simon Guinot)
Date: Mon, 1 Apr 2013 18:44:11 +0200
Subject: [PATCH] ARM: kirkwood: DT board setup for CloudBox
In-Reply-To: <20130330150807.GQ13280@titan.lakedaemon.net>
References: <1364555206-5870-1-git-send-email-simon.guinot@sequanux.org>
 <20130329153132.GJ13280@titan.lakedaemon.net>
 <20130329184109.GA16404@kw.sim.vm.gnt> <51568B89.1060009@free.fr>
 <20130330150807.GQ13280@titan.lakedaemon.net>
Message-ID: <20130401164411.GD16404@kw.sim.vm.gnt>

On Sat, Mar 30, 2013 at 11:08:07AM -0400, Jason Cooper wrote:
> On Sat, Mar 30, 2013 at 07:51:53AM +0100, Chris Moore wrote:
> > Hi Simon et al.
> > 
> > Le 29/03/2013 19:41, Simon Guinot a ?crit :
> > >On Fri, Mar 29, 2013 at 11:31:32AM -0400, Jason Cooper wrote:
> > >>Neat! another new board!
> > >Others are coming :)
> > 
> > That's great, thank you.
> > 
> > >>On Fri, Mar 29, 2013 at 12:06:46PM +0100, Simon Guinot wrote:
> > >>>This patch adds DT board setup for the LaCie NAS CloudBox. The CloudBox
> > >>>is a low cost NAS based on the Network Space v2.
> > >>>
> > >>>Chipset list:
> > >>>- CPU MARVELL 88F6702 1Ghz
> > >>>- SDRAM memory: 256MB DDR2-800 (2x128MB x8) 400Mhz
> > >>>- 1 Ethernet Gigabit port (PHY MARVELL 88E1318)
> > >>>- SPI flash, NOR 512KB
> > >>>- 1 push button
> > >>>- 2 LEDs (red and blue)
> > >>>
> > >>>+
> > >>>+/ {
> > >>>+	model = "LaCie CloudBox";
> > >>>+	compatible = "lacie,cloudbox", "marvell,kirkwood-88f6702", "marvell,kirkwood";
> > >>Is there a more specific string we can add here?  eg
> > >>"lacie,cloudbox-MODEL", "lacie,cloudbox", ...
> > >Unfortunately no. CloudBox is a product name which is also used by LaCie
> > >to name the board and the project.
> > >
> > 
> > I think it really is necessary to have a more specific name.
> > I have two, very different, products corresponding to LaCie CloudBox:
> > - The first one was a small black one with a 2.5" disk reviewed
> > here: http://www.smallnetbuilder.com/cloud/cloud-storage/462-lacie-cloudbox-reviewed
> > - The later one is a larger white one with a 3.5" disk described
> > here: http://www.smallnetbuilder.com/nas/nas-news/31927-lacie-relaunches-its-cloud-connected-nas
> 
> In this case, we usually look for a model number on the back and append
> that to the compatible string.  There are three model numbers listed
> here [1] under specifications, based on capacity.

Hi Jason,

I don't believe this numbers are related with the board. I will check
but IMHO "lacie,cloudbox" is a correct compatible string.

Thanks,

Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130401/5eb8734a/attachment-0001.sig>

From tony at atomide.com  Mon Apr  1 12:47:46 2013
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 1 Apr 2013 09:47:46 -0700
Subject: [GIT PULL] ARM: OMAP5: Generic updates and es2 fixes for 3.10
In-Reply-To: <1363768822-18084-1-git-send-email-santosh.shilimkar@ti.com>
References: <1363768822-18084-1-git-send-email-santosh.shilimkar@ti.com>
Message-ID: <20130401164746.GH10155@atomide.com>

* Santosh Shilimkar <santosh.shilimkar at ti.com> [130320 01:42]:
> Tony,
> 
> Here is the pull request for various OMAP5 generic updates which are posted
> earlier on the list. It contains OMAP5 es2 related updates like idcode,
> RAM base and couple of initialisation fixes.
> 
> The following changes since commit a937536b868b8369b98967929045f1df54234323:
> 
>   Linux 3.9-rc3 (2013-03-17 15:59:32 -0700)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux.git for_3.10/omap5_generic_updates
> 
> for you to fetch changes up to ecf51648c192377ea2830101b12fc3017bfd2b0c:
> 
>   ARM: OMAP5: clock: No Freqsel on OMAP5 devices too (2013-03-19 12:57:03 +0530)

Thanks pulling into omap-for-v3.10/fixes-non-critical.

Regards,

Tony 


From swarren at wwwdotorg.org  Mon Apr  1 12:49:42 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Mon, 01 Apr 2013 10:49:42 -0600
Subject: [PATCHv3 1/6] of: Add support for reading a u32 from a multi-value
 property.
In-Reply-To: <1364451049-2981-2-git-send-email-linux@prisktech.co.nz>
References: <1364451049-2981-1-git-send-email-linux@prisktech.co.nz>
 <1364451049-2981-2-git-send-email-linux@prisktech.co.nz>
Message-ID: <5159BAA6.50706@wwwdotorg.org>

On 03/28/2013 12:10 AM, Tony Prisk wrote:
> This patch adds an of_property_read_u32_index() function to allow
> reading a single indexed u32 value from a property containing multiple
> u32 values.

> diff --git a/drivers/of/base.c b/drivers/of/base.c

> +int of_property_read_u32_index(const struct device_node *np,

> +	if ((index * sizeof(*out_value)) > prop->length)
> +		return -EOVERFLOW;

I think that if should be:

	if (((index + 1) * sizeof(*out_value)) > prop->length)

since the code should check if the last byte of the u32 is out-of-range,
not whether the first byte is.

Aside from that, this patch,
Reviewed-by: Stephen Warren <swarren at nvidia.com>


From tony at atomide.com  Mon Apr  1 13:01:48 2013
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 1 Apr 2013 10:01:48 -0700
Subject: [GIT PULL] ARM: OMAP2+: Serial driver sysc cleanup for 3.10
In-Reply-To: <1363768601-17862-1-git-send-email-santosh.shilimkar@ti.com>
References: <1363768601-17862-1-git-send-email-santosh.shilimkar@ti.com>
Message-ID: <20130401170148.GJ10155@atomide.com>

* Santosh Shilimkar <santosh.shilimkar at ti.com> [130320 01:39]:
> Tony,
> 
> Here is the pull request for OMAP serial driver sysconfig cleanup. The series
> removes all the hackery of sysconfig from UART driver and let runtime backend
> handle it. Without this series serial console is almost un-usable on OMAP5.
> One of the patch touches driver/serial but I got an ack from Greg KH to get
> it queued via OMAP tree.
> 
> 
> The following changes since commit a937536b868b8369b98967929045f1df54234323:
> 
>   Linux 3.9-rc3 (2013-03-17 15:59:32 -0700)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux.git for_3.10/omap_serial_sysc_cleanup
> 
> for you to fetch changes up to 0f78c88b107a25561d0830c7fb695134ac7e8892:
> 
>   ARM: OMAP2+: hwmod: Remove sysc slave idle and auto idle apis (2013-03-19 12:07:49 +0530)

Looks like Paul had some comments and has applied some of these,
so ignoring this one for now.

Regards,

Tony 



From tony at atomide.com  Mon Apr  1 13:05:39 2013
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 1 Apr 2013 10:05:39 -0700
Subject: [GIT PULL] ARM: OMAP5: hwmod, prm/cm data files and updates
 for 3.10
In-Reply-To: <1363768852-18125-1-git-send-email-santosh.shilimkar@ti.com>
References: <1363768852-18125-1-git-send-email-santosh.shilimkar@ti.com>
Message-ID: <20130401170539.GK10155@atomide.com>

* Santosh Shilimkar <santosh.shilimkar at ti.com> [130320 01:43]:
> Tony,
> 
> Here is the pull request for OMAP5 data file patches which are on list from
> last merge window. As aligned on list, I have dropped clock data from the
> series. That means for the boot, one clock data patch needs to be applied.
> It is available on my git tree in 'out_of_tree/omap5_clk_data' branch.
> 
> As discussed already on list, you will notice hwmod data loc has come down
> from ~6000 lines to ~2000 lines becasue of removal of iospace, irq, dma data
> as well as unused hwmods. Few hwmods for which dt conversion is pending are
> not added as well but those would add max ~400 loc in future.
> 
> The following changes since commit a937536b868b8369b98967929045f1df54234323:
> 
>   Linux 3.9-rc3 (2013-03-17 15:59:32 -0700)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux.git for_3.10/omap5_data_files
> 
> for you to fetch changes up to 8a6a32e589a1a2a5a3fb8ebe8fc7426997bc6d89:
> 
>   ARM: OMAP5: Enable build and frameowrk initialisations (2013-03-19 14:09:11 +0530)

Paul, do you have any comments on these?

This branch should be queued separately because of the amount of
LOC it adds. But as you may have other PRCM related patches then it's
probably best that you queue it.

Regards,

Tony
 
> ----------------------------------------------------------------
> Benoit Cousson (7):
>       ARM: OMAP5: PRM: Add OMAP54XX register and bitfield files
>       ARM: OMAP5: CM: Add OMAP54XX register and bitfield files
>       ARM: OMAP5: PRCM: Add OMAP54XX local MPU PRCM registers
>       ARM: OMAP5: SCRM: Add OMAP54XX header file.
>       ARM: OMAP2+: clockdomain data: Add OMAP54XX data and update the header
>       ARM: OMAP5: powerdomain data: Add OMAP54XX data and update the header
>       ARM: OMAP5: hwmod data: Create initial OMAP5 SOC hwmod data
> 
> Santosh Shilimkar (4):
>       ARM: OMAP5: hwmod_data: Fix UART sysc settings
>       ARM: OMAP5: hwmod-data: Add timer clock activity flags
>       ARM: OMAP5: voltagedomain data: Add OMAP5 voltage domain data
>       ARM: OMAP5: Enable build and frameowrk initialisations
> 
>  arch/arm/mach-omap2/Makefile                  |    4 +
>  arch/arm/mach-omap2/clockdomain.h             |    1 +
>  arch/arm/mach-omap2/clockdomains54xx_data.c   |  464 +++++
>  arch/arm/mach-omap2/cm-regbits-54xx.h         | 1737 ++++++++++++++++
>  arch/arm/mach-omap2/cm1_54xx.h                |  216 ++
>  arch/arm/mach-omap2/cm2_54xx.h                |  392 ++++
>  arch/arm/mach-omap2/io.c                      |    7 +
>  arch/arm/mach-omap2/omap_hwmod.h              |    1 +
>  arch/arm/mach-omap2/omap_hwmod_54xx_data.c    | 2151 ++++++++++++++++++++
>  arch/arm/mach-omap2/powerdomain.h             |    1 +
>  arch/arm/mach-omap2/powerdomains54xx_data.c   |  331 +++
>  arch/arm/mach-omap2/prcm44xx.h                |    6 +
>  arch/arm/mach-omap2/prcm_mpu54xx.h            |   92 +
>  arch/arm/mach-omap2/prm-regbits-54xx.h        | 2701 +++++++++++++++++++++++++
>  arch/arm/mach-omap2/prm54xx.h                 |  447 ++++
>  arch/arm/mach-omap2/scrm54xx.h                |  231 +++
>  arch/arm/mach-omap2/voltage.h                 |    1 +
>  arch/arm/mach-omap2/voltagedomains54xx_data.c |  102 +
>  18 files changed, 8885 insertions(+)
>  create mode 100644 arch/arm/mach-omap2/clockdomains54xx_data.c
>  create mode 100644 arch/arm/mach-omap2/cm-regbits-54xx.h
>  create mode 100644 arch/arm/mach-omap2/cm1_54xx.h
>  create mode 100644 arch/arm/mach-omap2/cm2_54xx.h
>  create mode 100644 arch/arm/mach-omap2/omap_hwmod_54xx_data.c
>  create mode 100644 arch/arm/mach-omap2/powerdomains54xx_data.c
>  create mode 100644 arch/arm/mach-omap2/prcm_mpu54xx.h
>  create mode 100644 arch/arm/mach-omap2/prm-regbits-54xx.h
>  create mode 100644 arch/arm/mach-omap2/prm54xx.h
>  create mode 100644 arch/arm/mach-omap2/scrm54xx.h
>  create mode 100644 arch/arm/mach-omap2/voltagedomains54xx_data.c


From swarren at wwwdotorg.org  Mon Apr  1 13:06:00 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Mon, 01 Apr 2013 11:06:00 -0600
Subject: [PATCHv3 3/6] pinctrl: gpio: vt8500: Add pincontrol driver for
 arch-vt8500
In-Reply-To: <1364451049-2981-4-git-send-email-linux@prisktech.co.nz>
References: <1364451049-2981-1-git-send-email-linux@prisktech.co.nz>
 <1364451049-2981-4-git-send-email-linux@prisktech.co.nz>
Message-ID: <5159BE78.5020905@wwwdotorg.org>

On 03/28/2013 12:10 AM, Tony Prisk wrote:
> This patch adds support for the GPIO/pinmux controller found on the VIA
> VT8500 and Wondermedia WM8xxx-series SoCs.
> 
> Each pin within the controller is capable of operating as a GPIO or as
> an alternate function. The pins are numbered according to their control
> bank/bit so that if new pins are added, the existing numbering is maintained.
> 
> All currently supported SoCs are included: VT8500, WM8505, WM8650, WM8750 and
> WM8850.

> diff --git a/drivers/pinctrl/vt8500/pinctrl-wmt.c b/drivers/pinctrl/vt8500/pinctrl-wmt.c

> +static int wmt_pctl_dt_node_to_map_pull(struct wmt_pinctrl_data *data,
> +					struct device_node *np,
> +					u32 pin, u32 pull,
> +					struct pinctrl_map **maps)

> +	configs[0] = 0;

I assume that should be

	configs[0] = pull;

> +static int wmt_pctl_dt_node_to_map(struct pinctrl_dev *pctldev,
> +				   struct device_node *np,
> +				   struct pinctrl_map **map,
> +				   unsigned *num_maps)

> +fail:
> +	kfree(maps);
> +	return err;
> +}

There, I think you also want to iterate over maps[] and free
map->data.configs.config for any PIN_MAP_TYPE_CONFIGS_PIN.

Perhaps just call wmt_pctl_dt_free_map() here, with roughly nmaps =
cur_map - maps?

> +static int wmt_gpio_of_xlate(struct gpio_chip *gc,
> +				const struct of_phandle_args *gpiospec,
> +				u32 *flags)
> +{
> +	if (flags)
> +		*flags = gpiospec->args[1];
> +
> +	return gpiospec->args[0];
> +}

Can't you use of_gpio_simple_xlate(), and hence just not set .of_xlate in:

> +static struct gpio_chip wmt_gpio_chip = {
...
> +	.of_xlate = wmt_gpio_of_xlate,

Aside from that, this patch,

Reviewed-by: Stephen Warren <swarren at nvidia.com>

Although I didn't review pinctrl-*.c other than pinctrl-wmt.c, since
they're just big tables of data. Oh, except that the following could
probably be moved inside wmt_pinctrl_probe()?

> +	struct wmt_pinctrl_data *data;
> +	struct resource *res;
> +
> +	data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
> +	if (!data) {
> +		dev_err(&pdev->dev, "failed to allocate data\n");
> +		return -ENOMEM;
> +	}
> +
> +	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +	data->base = devm_request_and_ioremap(&pdev->dev, res);
> +	if (!data->base) {
> +		dev_err(&pdev->dev, "failed to map memory resource\n");
> +		return -EBUSY;
> +	}



From tony at atomide.com  Mon Apr  1 13:08:12 2013
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 1 Apr 2013 10:08:12 -0700
Subject: [GIT PULL] ARM: OMAP2+: standardize integration for AES &
 SHA/MD5 IP blocks for 3.10
In-Reply-To: <alpine.DEB.2.00.1303302244540.6436@utopia.booyaka.com>
References: <alpine.DEB.2.00.1303302244540.6436@utopia.booyaka.com>
Message-ID: <20130401170811.GL10155@atomide.com>

* Paul Walmsley <paul at pwsan.com> [130330 15:51]:
> Hi Tony,
> 
> The following changes since commit 78e52e026d288aad88b46bff0d94b05e145c4583:
> 
>   ARM: OMAP2+: clock data: Remove CK_* flags (2013-03-18 09:57:39 -0600)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git tags/omap-devel-a-for-3.10
> 
> for you to fetch changes up to 1cb804b93f506dfba5fd684a8ea63706aaa8e709:
> 
>   ARM: AM33XX: hwmod: Update and uncomment AES0 module data (2013-03-30 15:52:17 -0600)
> 
> ----------------------------------------------------------------
> For OMAP2+ SoCs, convert the SHA/MD5 and AES accelerator integration
> code and data to use hwmod and omap_device. This is a prerequisite for
> moving the hwmod code out of arch/arm.
> 
> Basic test logs are available at:
> 
>    http://www.pwsan.com/omap/testlogs/sham_aes_integration_devel_3.10/20130330155313/

Thanks pulling into omap-for-v3.10/crypto.

Regards,

Tony
 


From paul at pwsan.com  Mon Apr  1 13:09:24 2013
From: paul at pwsan.com (Paul Walmsley)
Date: Mon, 1 Apr 2013 17:09:24 +0000 (UTC)
Subject: [PATCH] Revert "OMAP/serial: Fix incorrect Rx FIFO threshold
 setting, LSR validation on Tx, and Tx FIFO IRQ generation"
In-Reply-To: <CAOmKuSpbaKutLxbNihBRDz+B0Wt0XiPss-PcEHc-efCTvciNFg@mail.gmail.com>
References: <alpine.DEB.2.00.1304010519260.28273@utopia.booyaka.com>
 <CAOmKuSpttQJmrL=Htiz-Zc4voAF7CnG_GQYAO2onKpauwYjtvw@mail.gmail.com>
 <alpine.DEB.2.00.1304010844100.28273@utopia.booyaka.com>
 <CAOmKuSrABrPcZ=Yg1+LAHWbh9CdTYR0eUmJ2dd3z91oz0uu21g@mail.gmail.com>
 <alpine.DEB.2.00.1304011008230.28273@utopia.booyaka.com>
 <CAOmKuSrbDc025Tj9xsqDebJ_KZdp_VnWAOs_OO5UAegV43JcDQ@mail.gmail.com>
 <CAOmKuSpbaKutLxbNihBRDz+B0Wt0XiPss-PcEHc-efCTvciNFg@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1304011654520.9148@utopia.booyaka.com>

On Mon, 1 Apr 2013, Alexey Pelykh wrote:

> Please, correct me if I'm wrong, you're experiencing issues on Tx, or
> Rx direction? You've said that characters are echoed incorrectly, but
> haven't mentioned in what direction issue appears?

The problem seems to be on the Rx path.  If I 'cat' a file, it's 
transmitted without hesitation.  But when I paste in this Simpsons quote 
into the serial console via X:

-----
Mr. Burns: A lifetime of working with nuclear power has left me with a healthy green glow... and left me as impotent as a Nevada boxing commissioner. 
-----

... everything up to the end of "boxing" is echoed immediately, and then 
"commissioner." stutters its way across the screen over the next five 
seconds.  


- Paul


From eduardo.valentin at ti.com  Mon Apr  1 13:20:58 2013
From: eduardo.valentin at ti.com (Eduardo Valentin)
Date: Mon, 1 Apr 2013 13:20:58 -0400
Subject: omap cpufreq driver in multi-platform kernels
In-Reply-To: <alpine.DEB.2.00.1303302156180.6436@utopia.booyaka.com>
References: <5152503C.2050503@gmail.com>
 <alpine.DEB.2.00.1303270212110.8161@utopia.booyaka.com>
 <20130327133220.GA30868@kahuna> <5153207A.4050109@gmail.com>
 <20130327170221.GA32231@kahuna> <87d2uk91ai.fsf@linaro.org>
 <20130327175621.GA32693@kahuna>
 <alpine.DEB.2.00.1303302156180.6436@utopia.booyaka.com>
Message-ID: <5159C1FA.8090000@ti.com>

Hey Paul,

On 30-03-2013 18:21, Paul Walmsley wrote:
> Hi folks,
>
> On Wed, 27 Mar 2013, Nishanth Menon wrote:
>
>> On 10:53-20130327, Kevin Hilman wrote:
>>> Nishanth Menon <nm at ti.com> writes:
>>>> On 11:38-20130327, Rob Herring wrote:
>>>>> On 03/27/2013 08:32 AM, Nishanth Menon wrote:
>>>>>> On 02:23-20130327, Paul Walmsley wrote:
>>>>>>> On Tue, 26 Mar 2013, Rob Herring wrote:
>>>>>>>>
>>>>>>>> Converting the driver to a platform driver would be another option.
>>>
>>> I think the platform_device conversion is the way to go.  I think you
>>> should do that instead of PATCH 8/8 of your OMAP conversion to the
>>> generic driver[1].
>>
>> Yep, thinking about this over lunch, I came to the same conclusion that
>> instead of checking on DT node existance, platform_device conversion
>> will solve both parts of the puzzle.
>
> Looked at this a little today.  I see that the platform_driver CPUFreq
> driver approach was taken with several SoCs in mainline. Could someone
> explain the theory behind making the CPUFreq drivers platform_drivers,
> rather than just modules?
>
> The part that doesn't make sense to me is that the existing CPUFreq
> drivers don't represent an actual hardware block.  Conceptually, they
> aren't drivers for the CPU, nor are they drivers for a CPU frequency
> scaling IP block.  One might as well bind a CPUIdle driver or a CPU
> throttling thermal driver to the CPU device.

I do agree with your point. On the other hand, I'd like to make a 
clarification here.

CPU throttling feature not really done as a driver. The feature is 
exported to be used by policies built by other code. Check 
drivers/thermal/cpu_cooling.c.

Thermal drivers are in fact drivers, as they are bound to an actual 
hardware block, a bandgap, a thermal sensor or a thermistor.



>
> Wouldn't it be best to just make them modules?

Thermal policies are built as modules.


>
> Also, noticed that the Highbank CPUFreq driver creates a virtual device in
> its code.  That also doesn't seem right.  Isn't device creation better
> left to DT/ACPI/whatever?
>
>
> regards,
>
> - Paul
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pm" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>



From tony at atomide.com  Mon Apr  1 13:24:00 2013
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 1 Apr 2013 10:24:00 -0700
Subject: OMAP baseline test results for v3.9-rc3
In-Reply-To: <1364375463.3146.9.camel@sokoban>
References: <alpine.DEB.2.00.1303181536230.29332@utopia.booyaka.com>
 <51482707.6020501@ti.com> <1363684373.15426.137.camel@sokoban>
 <alpine.DEB.2.00.1303261829440.23957@utopia.booyaka.com>
 <1364375463.3146.9.camel@sokoban>
Message-ID: <20130401172400.GM10155@atomide.com>

* Tero Kristo <t-kristo at ti.com> [130327 02:15]:
> On Tue, 2013-03-26 at 18:43 +0000, Paul Walmsley wrote:
> > 
> > So what I'd like you to do is:
> > 
> > 1. Determine what devices are remaining to be reset and idled on OMAP4 
> >    with the bootloader that I use.  As far as I know, there are only four 
> >    that block full-chip idle: M3, DSP, SL2IF, FSUSB
> > 
> > 2. Determine what's needed to reset and idle them.  For the M3 and DSP, 
> >    I'd assume this involves pointing the reset vector for those 
> >    processors at a few lines of code that basically enter WFI or the C64x 
> >    equivalent.
> 
> This is the nasty part. We need firmware support for the blocks to do
> this, and this is imo a complete overkill for the task at hand, as it
> will duplicate the DSP + M3 firmware and drivers at least partially. On
> OMAP3, it was easy as you could just setup the boot mode for IVA and get
> over with it. We don't have similar luxury on OMAP4.
> 
> If there was a simple way to do this, don't you think this would have
> been done already a year back when we started to discuss this first
> time? And, a year old bootloader is ancient seeing we didn't have any
> kind of support for OMAP4 core idle in mainline back then and this
> feature was essentially completely untested.... nobody cared about the
> upstream u-boot PM compatibility before that.

You may be able to have an inline function in the DSP and M3 headers
that idles those modules that can also be called from the reset and idle
function in the hwmod code. That way the driver related code stays in
the driver, but can be called from hwmod reset if the driver is not
compiled in.

Of course if the reset and idle of DSP and M3 gets more complex than
just a few lines of code, then we should just determine that the PM is
broken without those drivers and print out a warning.

Regards,

Tony


From jon-hunter at ti.com  Mon Apr  1 13:48:26 2013
From: jon-hunter at ti.com (Jon Hunter)
Date: Mon, 1 Apr 2013 12:48:26 -0500
Subject: [PATCH V3 2/2] dmaengine: OMAP: Register SDMA controller with
 Device Tree DMA driver
In-Reply-To: <20130320163654.GN16413@atomide.com>
References: <1361903244-19837-1-git-send-email-jon-hunter@ti.com>
 <1361903244-19837-3-git-send-email-jon-hunter@ti.com>
 <51488C8B.4010206@ti.com> <20130320163654.GN16413@atomide.com>
Message-ID: <5159C86A.30701@ti.com>

Vinod,

On 03/20/2013 11:36 AM, Tony Lindgren wrote:
> * Jon Hunter <jon-hunter at ti.com> [130319 09:08]:
>> Vinod, Tony, Benoit,
>>
>> On 02/26/2013 12:27 PM, Jon Hunter wrote:
>>> If the device-tree blob is present during boot, then register the SDMA
>>> controller with the device-tree DMA driver so that we can use device-tree
>>> to look-up DMA client information.
>>>
>>> Signed-off-by: Jon Hunter <jon-hunter at ti.com>
>>> Reviewed-by: Felipe Balbi <balbi at ti.com>
>>> Acked-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
>>> Tested-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
>>> ---
>>>  arch/arm/mach-omap2/dma.c |    4 ++++
>>>  drivers/dma/omap-dma.c    |   38 ++++++++++++++++++++++++++++++++++++--
>>>  2 files changed, 40 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-omap2/dma.c b/arch/arm/mach-omap2/dma.c
>>> index dab9fc0..49fd0d5 100644
>>> --- a/arch/arm/mach-omap2/dma.c
>>> +++ b/arch/arm/mach-omap2/dma.c
>>> @@ -28,6 +28,7 @@
>>>  #include <linux/init.h>
>>>  #include <linux/device.h>
>>>  #include <linux/dma-mapping.h>
>>> +#include <linux/of.h>
>>>  #include <linux/omap-dma.h>
>>>  
>>>  #include "soc.h"
>>> @@ -304,6 +305,9 @@ static int __init omap2_system_dma_init(void)
>>>  	if (res)
>>>  		return res;
>>>  
>>> +	if (of_have_populated_dt())
>>> +		return res;
>>> +
>>>  	pdev = platform_device_register_full(&omap_dma_dev_info);
>>>  	if (IS_ERR(pdev))
>>>  		return PTR_ERR(pdev);
> 
> AFAIK we don't currently have anything else touching this file..
> 
>>> diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
>>> index c4b4fd2..2ea3d7e 100644
>>> --- a/drivers/dma/omap-dma.c
>>> +++ b/drivers/dma/omap-dma.c
>>> @@ -16,6 +16,8 @@
>>>  #include <linux/platform_device.h>
>>>  #include <linux/slab.h>
>>>  #include <linux/spinlock.h>
>>> +#include <linux/of_dma.h>
>>> +#include <linux/of_device.h>
>>>  
>>>  #include "virt-dma.h"
>>>  
>>> @@ -67,6 +69,10 @@ static const unsigned es_bytes[] = {
>>>  	[OMAP_DMA_DATA_TYPE_S32] = 4,
>>>  };
>>>  
>>> +static struct of_dma_filter_info omap_dma_info = {
>>> +	.filter_fn = omap_dma_filter_fn,
>>> +};
>>> +
>>>  static inline struct omap_dmadev *to_omap_dma_dev(struct dma_device *d)
>>>  {
>>>  	return container_of(d, struct omap_dmadev, ddev);
>>> @@ -621,8 +627,22 @@ static int omap_dma_probe(struct platform_device *pdev)
>>>  		pr_warn("OMAP-DMA: failed to register slave DMA engine device: %d\n",
>>>  			rc);
>>>  		omap_dma_free(od);
>>> -	} else {
>>> -		platform_set_drvdata(pdev, od);
>>> +		return rc;
>>> +	}
>>> +
>>> +	platform_set_drvdata(pdev, od);
>>> +
>>> +	if (pdev->dev.of_node) {
>>> +		omap_dma_info.dma_cap = od->ddev.cap_mask;
>>> +
>>> +		/* Device-tree DMA controller registration */
>>> +		rc = of_dma_controller_register(pdev->dev.of_node,
>>> +				of_dma_simple_xlate, &omap_dma_info);
>>> +		if (rc) {
>>> +			pr_warn("OMAP-DMA: failed to register DMA controller\n");
>>> +			dma_async_device_unregister(&od->ddev);
>>> +			omap_dma_free(od);
>>> +		}
>>>  	}
>>>  
>>>  	dev_info(&pdev->dev, "OMAP DMA engine driver\n");
>>> @@ -634,18 +654,32 @@ static int omap_dma_remove(struct platform_device *pdev)
>>>  {
>>>  	struct omap_dmadev *od = platform_get_drvdata(pdev);
>>>  
>>> +	if (pdev->dev.of_node)
>>> +		of_dma_controller_free(pdev->dev.of_node);
>>> +
>>>  	dma_async_device_unregister(&od->ddev);
>>>  	omap_dma_free(od);
>>>  
>>>  	return 0;
>>>  }
>>>  
>>> +static const struct of_device_id omap_dma_match[] = {
>>> +	{ .compatible = "ti,omap2420-sdma", },
>>> +	{ .compatible = "ti,omap2430-sdma", },
>>> +	{ .compatible = "ti,omap3430-sdma", },
>>> +	{ .compatible = "ti,omap3630-sdma", },
>>> +	{ .compatible = "ti,omap4430-sdma", },
>>> +	{},
>>> +};
>>> +MODULE_DEVICE_TABLE(of, omap_dma_match);
>>> +
>>>  static struct platform_driver omap_dma_driver = {
>>>  	.probe	= omap_dma_probe,
>>>  	.remove	= omap_dma_remove,
>>>  	.driver = {
>>>  		.name = "omap-dma-engine",
>>>  		.owner = THIS_MODULE,
>>> +		.of_match_table = of_match_ptr(omap_dma_match),
>>>  	},
>>>  };
>>
>> Who's tree does it make most sense for this patch to go through?
>>
>> Benoit has queued up patch 1/2 and so I am not sure if this should go
>> via Benoit tree to Tony or directly via Vinod's tree. What are your
>> thoughts?
> 
> OK
>  
>> It would be great if this could make v3.10.
> 
> I suggest Vinod/Grant/Linus W queue this patch:
> 
> Acked-by: Tony Lindgren <tony at atomide.com>

Can you take this patch with Tony's ACK? Let me know if you want me to
resend with the ACK.

Cheers
Jon



From alexey.pelykh at gmail.com  Mon Apr  1 14:01:55 2013
From: alexey.pelykh at gmail.com (Alexey Pelykh)
Date: Mon, 1 Apr 2013 21:01:55 +0300
Subject: [PATCH] Revert "OMAP/serial: Fix incorrect Rx FIFO threshold
 setting, LSR validation on Tx, and Tx FIFO IRQ generation"
In-Reply-To: <alpine.DEB.2.00.1304011654520.9148@utopia.booyaka.com>
References: <alpine.DEB.2.00.1304010519260.28273@utopia.booyaka.com>
 <CAOmKuSpttQJmrL=Htiz-Zc4voAF7CnG_GQYAO2onKpauwYjtvw@mail.gmail.com>
 <alpine.DEB.2.00.1304010844100.28273@utopia.booyaka.com>
 <CAOmKuSrABrPcZ=Yg1+LAHWbh9CdTYR0eUmJ2dd3z91oz0uu21g@mail.gmail.com>
 <alpine.DEB.2.00.1304011008230.28273@utopia.booyaka.com>
 <CAOmKuSrbDc025Tj9xsqDebJ_KZdp_VnWAOs_OO5UAegV43JcDQ@mail.gmail.com>
 <CAOmKuSpbaKutLxbNihBRDz+B0Wt0XiPss-PcEHc-efCTvciNFg@mail.gmail.com>
 <alpine.DEB.2.00.1304011654520.9148@utopia.booyaka.com>
Message-ID: <CAOmKuSo4onVtk2Ke-i+0_1Ych33KuUYspRy+cySRHf4yWB5XDw@mail.gmail.com>

Paul, can you please try to comment out change related to Rx line
(granulation one). That's only Rx line related change in the patch.

On Mon, Apr 1, 2013 at 8:09 PM, Paul Walmsley <paul at pwsan.com> wrote:
> On Mon, 1 Apr 2013, Alexey Pelykh wrote:
>
>> Please, correct me if I'm wrong, you're experiencing issues on Tx, or
>> Rx direction? You've said that characters are echoed incorrectly, but
>> haven't mentioned in what direction issue appears?
>
> The problem seems to be on the Rx path.  If I 'cat' a file, it's
> transmitted without hesitation.  But when I paste in this Simpsons quote
> into the serial console via X:
>
> -----
> Mr. Burns: A lifetime of working with nuclear power has left me with a healthy green glow... and left me as impotent as a Nevada boxing commissioner.
> -----
>
> ... everything up to the end of "boxing" is echoed immediately, and then
> "commissioner." stutters its way across the screen over the next five
> seconds.
>
>
> - Paul


From linux at roeck-us.net  Mon Apr  1 14:12:24 2013
From: linux at roeck-us.net (Guenter Roeck)
Date: Mon,  1 Apr 2013 11:12:24 -0700
Subject: [PATCH] drm/tilcdc: Disable building as module
Message-ID: <1364839944-4863-1-git-send-email-linux@roeck-us.net>

Attempts to compile tilcdc as module results in:

drivers/gpu/drm/tilcdc/tilcdc_slave.o:(.data+0x54): multiple definition of
`__mod_of_device_table'
drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54): first defined here
drivers/gpu/drm/tilcdc/tilcdc_panel.o:(.data+0x54): multiple definition of
`__mod_of_device_table'
drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54): first defined here
drivers/gpu/drm/tilcdc/tilcdc_drv.o:(.data+0x184): multiple definition of
`__mod_of_device_table'
drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54): first defined here
make[5]: [drivers/gpu/drm/tilcdc/tilcdc.o] Error 1 (ignored)

It appears it was never even tried to build it as module, or the problem
would have been seen. So running this driver as module was never really
tested. Disable it. If really needed, the code wil require some structural
changes and in-depth testing, which can and should be done separately.

Cc: Rob Clark <robdclark at gmail.com>
Signed-off-by: Guenter Roeck <linux at roeck-us.net>
---
 drivers/gpu/drm/tilcdc/Kconfig |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/tilcdc/Kconfig b/drivers/gpu/drm/tilcdc/Kconfig
index d24d040..6ddb729 100644
--- a/drivers/gpu/drm/tilcdc/Kconfig
+++ b/drivers/gpu/drm/tilcdc/Kconfig
@@ -1,5 +1,5 @@
 config DRM_TILCDC
-	tristate "DRM Support for TI LCDC Display Controller"
+	bool "DRM Support for TI LCDC Display Controller"
 	depends on DRM && OF && ARM
 	select DRM_KMS_HELPER
 	select DRM_KMS_CMA_HELPER
-- 
1.7.9.7



From nicolas.pitre at linaro.org  Mon Apr  1 14:20:44 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Mon, 1 Apr 2013 14:20:44 -0400 (EDT)
Subject: [PATCH v4 2/2] arm: prefer PSCI for SMP bringup
In-Reply-To: <alpine.DEB.2.02.1304011541010.5078@kaball.uk.xensource.com>
References: <1364575371-8926-2-git-send-email-stefano.stabellini@eu.citrix.com>
 <alpine.LFD.2.03.1303291320580.1372@syhkavp.arg>
 <alpine.DEB.2.02.1303291735080.4430@kaball.uk.xensource.com>
 <alpine.LFD.2.03.1303291349150.1372@syhkavp.arg> <5155EC28.8050608@gmail.com>
 <alpine.DEB.2.02.1304011541010.5078@kaball.uk.xensource.com>
Message-ID: <alpine.LFD.2.03.1304011412030.1171@syhkavp.arg>

On Mon, 1 Apr 2013, Stefano Stabellini wrote:

> On Fri, 29 Mar 2013, Rob Herring wrote:
> > On 03/29/2013 12:53 PM, Nicolas Pitre wrote:
> > > On Fri, 29 Mar 2013, Stefano Stabellini wrote:
> > > 
> > >> On Fri, 29 Mar 2013, Nicolas Pitre wrote:
> > >>> On Fri, 29 Mar 2013, Stefano Stabellini wrote:
> > >>>
> > >>>> If PSCI initializes correctly and PSCI SMP operations are available, use them.
> > >>>> This is required for SMP support in Dom0 on Xen.
> > >>>>
> > >>>> Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
> > >>>> CC: will.deacon at arm.com
> > >>>> CC: arnd at arndb.de
> > >>>> CC: marc.zyngier at arm.com
> > >>>> CC: linux at arm.linux.org.uk
> > >>>> CC: nico at linaro.org
> > >>>
> > >>> I'd suggest you also include in your series the patch I posted earlier 
> > >>> providing a runtime mdesc->smp_init method as well.
> > >>
> > >> OK.
> > >>
> > >>
> > >>> This way the 
> > >>> priority order would be:
> > >>>
> > >>> - If mdesc->smp_init is non null then use that.
> > >>>
> > >>> - Otherwise, if PSCI is available then use that.
> > >>>
> > >>> - Otherwise use mdesc->smp.
> > >>>
> > >>> This way, if the PSCI default has to be overriden (like in the MCPM case 
> > >>> because it needs to wrap PSCI itself, or to cover Rob's concern) then 
> > >>> this can be achieved at run time on a per mdesc basis.
> > >>
> > >> Actually that's not a bad idea, it could make everybody happy.
> > >> What about the following, in this precise order:
> > >>
> > >> - if a xen hypervisor node is present on device tree, use PSCI;
> > >> - otherwise if mdesc->smp_init is non null then use it;
> > >> - otherwise if PSCI is available then use it;
> > >> - otherwise use mdesc->smp.
> > >>
> > >> It's the most practical solution to satisfy everybody's needs.
> > > 
> > > Maybe I'm missing something obvious, but why can't xen declare a mdesc 
> > > of its own?  Given it is going to tweak the DT passed to the kernel 
> > > anyway that shouldn't be a problem.
> > 
> > Xen does have it's own mdesc. It is (or will be) mach-virt, but that is
> > only for DomU guests. For Dom0, you still need all the platform specific
> > code except smp_ops. However, I'm doubtful this would work without other
> > changes on more complicated platforms like OMAP.
> > 
> > I would say wait to add this until you have platforms that actually need
> > the first case.
> 
> OK, that is not unreasonable.
> 
> What are the platforms that are going to use smp_init? Do we know how do
> they intend to use it?

VExpress for one.  When booting on a big.LITTLE system such as TC2 on 
VExpress, the MCPM layer needs to arbitrate power management operations 
on a per cluster basis.  In that case there is a MCPM specific set of 
SMP ops to be used, even if it may end up calling into PSCI.

But the important point is that we don't know beforehand what to use, 
especially with a kernel that can boot on multiple different VExpress 
configurations.  The decision has to be made at run time, and therefore 
a static default or mdesc->smp ops doesn't cut it.


Nicolas


From mturquette at linaro.org  Mon Apr  1 14:25:22 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Mon, 01 Apr 2013 11:25:22 -0700
Subject: [PATCH RFC] clk: divider: Tolerate 0 divider for one based
 dividers
In-Reply-To: <c9f78c47-4926-4233-8cc3-51e0a4cc9c5e@AM1EHSMHS003.ehs.local>
References: <dbceb80f-0303-4ba0-acd8-336dd85444ae@DB8EHSMHS017.ehs.local>
 <20130322171141.834.32801@quantum>
 <c9f78c47-4926-4233-8cc3-51e0a4cc9c5e@AM1EHSMHS003.ehs.local>
Message-ID: <20130401182522.8177.96562@quantum>

Quoting S?ren Brinkmann (2013-03-22 11:00:15)
> Since some of our dividers have a reset value of 0, I see this warning
> during boot up. My intention here is to get rid of the warning for clocks
> which deem 0 a valid divider value.
> I thought, reusing the ONE_BASED flag might be okay, since all such
> dividers have this redundant 0 state and might handle it similar.
> Otherwise a new flag might be required.
> 

Hi Soren,

A flag will be necessary.  I just checked some documentation for the
divider outputs for OMAP's PLLs and (which use the common clk_divider
type) and programming zero into those dividers is not allowed.  At reset
the divider registers are set to 1.

So it is unsafe to simply reuse the ONE_BASED flag.

Let's keep the current behavior as the default and introduce a new flag
to handle the special case of a zero divider.  Would you like to take a
crack at it?  It might also be nice to update the WARN message with a
hint to take a look at your new flag in case future platforms hit the
same issue as you.

Regards,
Mike

>         S?ren


From soren.brinkmann at xilinx.com  Mon Apr  1 14:31:32 2013
From: soren.brinkmann at xilinx.com (=?utf-8?B?U8O2cmVu?= Brinkmann)
Date: Mon, 1 Apr 2013 11:31:32 -0700
Subject: [PATCH RFC] clk: divider: Tolerate 0 divider for one based
 dividers
In-Reply-To: <20130401182522.8177.96562@quantum>
References: <dbceb80f-0303-4ba0-acd8-336dd85444ae@DB8EHSMHS017.ehs.local>
 <20130322171141.834.32801@quantum>
 <c9f78c47-4926-4233-8cc3-51e0a4cc9c5e@AM1EHSMHS003.ehs.local>
 <20130401182522.8177.96562@quantum>
Message-ID: <edf8905f-2bd1-4a1d-b6a2-85e921365d88@CO1EHSMHS004.ehs.local>

Hi Mike,

On Mon, Apr 01, 2013 at 11:25:22AM -0700, Mike Turquette wrote:
> Quoting S?ren Brinkmann (2013-03-22 11:00:15)
> > Since some of our dividers have a reset value of 0, I see this warning
> > during boot up. My intention here is to get rid of the warning for clocks
> > which deem 0 a valid divider value.
> > I thought, reusing the ONE_BASED flag might be okay, since all such
> > dividers have this redundant 0 state and might handle it similar.
> > Otherwise a new flag might be required.
> > 
> 
> Hi Soren,
> 
> A flag will be necessary.  I just checked some documentation for the
> divider outputs for OMAP's PLLs and (which use the common clk_divider
> type) and programming zero into those dividers is not allowed.  At reset
> the divider registers are set to 1.
> 
> So it is unsafe to simply reuse the ONE_BASED flag.
> 
> Let's keep the current behavior as the default and introduce a new flag
> to handle the special case of a zero divider.  Would you like to take a
> crack at it?  It might also be nice to update the WARN message with a
> hint to take a look at your new flag in case future platforms hit the
> same issue as you.
Okay, sounds good. I should be able to get something ready within this
week.
Does anybody have suggestions for naming the new flag?
CLK_DIVIDER_ZERO_OKAY was my original suggestionn I think.

	S?ren




From dianders at google.com  Mon Apr  1 14:42:31 2013
From: dianders at google.com (Doug Anderson)
Date: Mon, 1 Apr 2013 11:42:31 -0700
Subject: [PATCH] mmc: dwmmc: let device core setup the default pin
 configuration
In-Reply-To: <CAD=FV=Uy1dQMAxgh_ncxfsQVMDp4Da3inLTvgbJFhyhFLjVWrg@mail.gmail.com>
References: <1362571461-14570-1-git-send-email-thomas.abraham@linaro.org>
 <CAD=FV=W8E=0C8_QZ3d44caq6EOvBpTkX0Ng86niQuN4B-cnHiw@mail.gmail.com>
 <CAD=FV=Uy1dQMAxgh_ncxfsQVMDp4Da3inLTvgbJFhyhFLjVWrg@mail.gmail.com>
Message-ID: <CAD=FV=Vxh9+qpAmoLuALCOZJCLTfga0WdCf=P+heOmbkDY=Aww@mail.gmail.com>

Thomas,

On Mon, Mar 25, 2013 at 9:56 AM, Doug Anderson <dianders at google.com> wrote:
> Are you planning on doing this?  I noticed that Chris pulled your
> sdhci-s3c change in recently but apparently skipped this one since it
> had outstanding comments.  Can you address comments and re-send?  This
> is blocking pinmux dts stuff from landing (I think) and that blocks a
> lot of other things from landing.
>
> The comments are pretty trivial, so I could always fix them and
> re-send myself, but it would be better if you could do it...  :)

I didn't hear anything last week and it's getting pretty late in the
process.  I'll post something tomorrow if I don't hear from you...

-Doug


From vinod.koul at intel.com  Mon Apr  1 14:21:51 2013
From: vinod.koul at intel.com (Vinod Koul)
Date: Mon, 1 Apr 2013 23:51:51 +0530
Subject: [PATCH V2] DMA: PL330: Add check if device tree compatible
In-Reply-To: <CAL_Jsq+3bJDiA=rXS=WY3BGuRh5X+nyxxosrqtSD9fx-asbCKQ@mail.gmail.com>
References: <1362475531-32260-1-git-send-email-padma.v@samsung.com>
 <1362475531-32260-2-git-send-email-padma.v@samsung.com>
 <20130321093906.GL10326@intel.com>
 <CAL_Jsq+3bJDiA=rXS=WY3BGuRh5X+nyxxosrqtSD9fx-asbCKQ@mail.gmail.com>
Message-ID: <20130401182151.GH10326@intel.com>

On Mon, Apr 01, 2013 at 08:13:31AM -0500, Rob Herring wrote:
> On Thu, Mar 21, 2013 at 4:39 AM, Vinod Koul <vinod.koul at intel.com> wrote:
> > On Tue, Mar 05, 2013 at 02:55:31PM +0530, Padmavathi Venna wrote:
> >> This patch register the dma controller with generic dma helpers only
> >> in DT case. This also adds some extra error handling in the driver.
> >>
> >> Signed-off-by: Padmavathi Venna <padma.v at samsung.com>
> >> Reported-by: Sachin Kamat <sachin.kamat at linaro.org>
> 
> What's the status on this? It is needed for 3.9 to fix pl330 on highbank.
Well the status is that submitter has been rude. I had few questions and
comments on this patch and they are yet to be addressed.

--
~Vinod
> 
> Rob
> 
> >> ---
> >>
> >> Based on Vinod Koul next branch.
> >>
> >> Changes since V1:
> >>       - return silently when of_dma_controller_register fails, as
> >>         suggested by Arnd.
> >>
> >>  drivers/dma/pl330.c |   38 +++++++++++++++++++++++++++-----------
> >>  1 files changed, 27 insertions(+), 11 deletions(-)
> >>
> >> diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
> >> index 7181531..5dbc594 100644
> >> --- a/drivers/dma/pl330.c
> >> +++ b/drivers/dma/pl330.c
> >> @@ -2882,7 +2882,7 @@ pl330_probe(struct amba_device *adev, const struct amba_id *id)
> >>  {
> >>       struct dma_pl330_platdata *pdat;
> >>       struct dma_pl330_dmac *pdmac;
> >> -     struct dma_pl330_chan *pch;
> >> +     struct dma_pl330_chan *pch, *_p;
> >>       struct pl330_info *pi;
> >>       struct dma_device *pd;
> >>       struct resource *res;
> >> @@ -2984,7 +2984,16 @@ pl330_probe(struct amba_device *adev, const struct amba_id *id)
> >>       ret = dma_async_device_register(pd);
> >>       if (ret) {
> >>               dev_err(&adev->dev, "unable to register DMAC\n");
> >> -             goto probe_err2;
> >> +             goto probe_err3;
> >> +     }
> >> +
> >> +     if (adev->dev.of_node) {
> >> +             ret = of_dma_controller_register(adev->dev.of_node,
> >> +                                      of_dma_pl330_xlate, pdmac);
> >> +             if (ret) {
> >> +                     dev_err(&adev->dev,
> >> +                     "unable to register DMA to the generic DT DMA helpers\n");
> > Indent?
> >> +             }
> >>       }
> >>
> >>       dev_info(&adev->dev,
> >> @@ -2995,16 +3004,21 @@ pl330_probe(struct amba_device *adev, const struct amba_id *id)
> >>               pi->pcfg.data_bus_width / 8, pi->pcfg.num_chan,
> >>               pi->pcfg.num_peri, pi->pcfg.num_events);
> >>
> >> -     ret = of_dma_controller_register(adev->dev.of_node,
> >> -                                      of_dma_pl330_xlate, pdmac);
> >> -     if (ret) {
> >> -             dev_err(&adev->dev,
> >> -             "unable to register DMA to the generic DT DMA helpers\n");
> >> -             goto probe_err2;
> >> -     }
> >> -
> >>       return 0;
> >> +probe_err3:
> >> +     amba_set_drvdata(adev, NULL);
> >>
> >> +     /* Idle the DMAC */
> >> +     list_for_each_entry_safe(pch, _p, &pdmac->ddma.channels,
> >> +                     chan.device_node) {
> >> +
> >> +             /* Remove the channel */
> >> +             list_del(&pch->chan.device_node);
> >> +
> >> +             /* Flush the channel */
> >> +             pl330_control(&pch->chan, DMA_TERMINATE_ALL, 0);
> >> +             pl330_free_chan_resources(&pch->chan);
> > free_chan for error handling in probe?
> >
> >> +     }
> >>  probe_err2:
> >>       pl330_del(pi);
> >>  probe_err1:
> >> @@ -3023,8 +3037,10 @@ static int pl330_remove(struct amba_device *adev)
> >>       if (!pdmac)
> >>               return 0;
> >>
> >> -     of_dma_controller_free(adev->dev.of_node);
> >> +     if (adev->dev.of_node)
> >> +             of_dma_controller_free(adev->dev.of_node);
> >>
> >> +     dma_async_device_unregister(&pdmac->ddma);
> >>       amba_set_drvdata(adev, NULL);
> >>
> >>       /* Idle the DMAC */
> >> --
> >> 1.7.4.4
> >>


From vinod.koul at intel.com  Mon Apr  1 14:26:27 2013
From: vinod.koul at intel.com (Vinod Koul)
Date: Mon, 1 Apr 2013 23:56:27 +0530
Subject: [PATCH V3 2/2] dmaengine: OMAP: Register SDMA controller with
 Device Tree DMA driver
In-Reply-To: <5159C86A.30701@ti.com>
References: <1361903244-19837-1-git-send-email-jon-hunter@ti.com>
 <1361903244-19837-3-git-send-email-jon-hunter@ti.com>
 <51488C8B.4010206@ti.com> <20130320163654.GN16413@atomide.com>
 <5159C86A.30701@ti.com>
Message-ID: <20130401182627.GI10326@intel.com>

On Mon, Apr 01, 2013 at 12:48:26PM -0500, Jon Hunter wrote:
> Vinod,
> 
> On 03/20/2013 11:36 AM, Tony Lindgren wrote:
> > * Jon Hunter <jon-hunter at ti.com> [130319 09:08]:
> >> Vinod, Tony, Benoit,
> >>
> >> On 02/26/2013 12:27 PM, Jon Hunter wrote:
> >>> If the device-tree blob is present during boot, then register the SDMA
> >>> controller with the device-tree DMA driver so that we can use device-tree
> >>> to look-up DMA client information.
> >>>
> >>> Signed-off-by: Jon Hunter <jon-hunter at ti.com>
> >>> Reviewed-by: Felipe Balbi <balbi at ti.com>
> >>> Acked-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
> >>> Tested-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
> >>> ---
> >>>  arch/arm/mach-omap2/dma.c |    4 ++++
> >>>  drivers/dma/omap-dma.c    |   38 ++++++++++++++++++++++++++++++++++++--
> >>>  2 files changed, 40 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/arch/arm/mach-omap2/dma.c b/arch/arm/mach-omap2/dma.c
> >>> index dab9fc0..49fd0d5 100644
> >>> --- a/arch/arm/mach-omap2/dma.c
> >>> +++ b/arch/arm/mach-omap2/dma.c
> >>> @@ -28,6 +28,7 @@
> >>>  #include <linux/init.h>
> >>>  #include <linux/device.h>
> >>>  #include <linux/dma-mapping.h>
> >>> +#include <linux/of.h>
> >>>  #include <linux/omap-dma.h>
> >>>  
> >>>  #include "soc.h"
> >>> @@ -304,6 +305,9 @@ static int __init omap2_system_dma_init(void)
> >>>  	if (res)
> >>>  		return res;
> >>>  
> >>> +	if (of_have_populated_dt())
> >>> +		return res;
> >>> +
> >>>  	pdev = platform_device_register_full(&omap_dma_dev_info);
> >>>  	if (IS_ERR(pdev))
> >>>  		return PTR_ERR(pdev);
> > 
> > AFAIK we don't currently have anything else touching this file..
> > 
> >>> diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
> >>> index c4b4fd2..2ea3d7e 100644
> >>> --- a/drivers/dma/omap-dma.c
> >>> +++ b/drivers/dma/omap-dma.c
> >>> @@ -16,6 +16,8 @@
> >>>  #include <linux/platform_device.h>
> >>>  #include <linux/slab.h>
> >>>  #include <linux/spinlock.h>
> >>> +#include <linux/of_dma.h>
> >>> +#include <linux/of_device.h>
> >>>  
> >>>  #include "virt-dma.h"
> >>>  
> >>> @@ -67,6 +69,10 @@ static const unsigned es_bytes[] = {
> >>>  	[OMAP_DMA_DATA_TYPE_S32] = 4,
> >>>  };
> >>>  
> >>> +static struct of_dma_filter_info omap_dma_info = {
> >>> +	.filter_fn = omap_dma_filter_fn,
> >>> +};
> >>> +
> >>>  static inline struct omap_dmadev *to_omap_dma_dev(struct dma_device *d)
> >>>  {
> >>>  	return container_of(d, struct omap_dmadev, ddev);
> >>> @@ -621,8 +627,22 @@ static int omap_dma_probe(struct platform_device *pdev)
> >>>  		pr_warn("OMAP-DMA: failed to register slave DMA engine device: %d\n",
> >>>  			rc);
> >>>  		omap_dma_free(od);
> >>> -	} else {
> >>> -		platform_set_drvdata(pdev, od);
> >>> +		return rc;
> >>> +	}
> >>> +
> >>> +	platform_set_drvdata(pdev, od);
> >>> +
> >>> +	if (pdev->dev.of_node) {
> >>> +		omap_dma_info.dma_cap = od->ddev.cap_mask;
> >>> +
> >>> +		/* Device-tree DMA controller registration */
> >>> +		rc = of_dma_controller_register(pdev->dev.of_node,
> >>> +				of_dma_simple_xlate, &omap_dma_info);
> >>> +		if (rc) {
> >>> +			pr_warn("OMAP-DMA: failed to register DMA controller\n");
> >>> +			dma_async_device_unregister(&od->ddev);
> >>> +			omap_dma_free(od);
> >>> +		}
> >>>  	}
> >>>  
> >>>  	dev_info(&pdev->dev, "OMAP DMA engine driver\n");
> >>> @@ -634,18 +654,32 @@ static int omap_dma_remove(struct platform_device *pdev)
> >>>  {
> >>>  	struct omap_dmadev *od = platform_get_drvdata(pdev);
> >>>  
> >>> +	if (pdev->dev.of_node)
> >>> +		of_dma_controller_free(pdev->dev.of_node);
> >>> +
> >>>  	dma_async_device_unregister(&od->ddev);
> >>>  	omap_dma_free(od);
> >>>  
> >>>  	return 0;
> >>>  }
> >>>  
> >>> +static const struct of_device_id omap_dma_match[] = {
> >>> +	{ .compatible = "ti,omap2420-sdma", },
> >>> +	{ .compatible = "ti,omap2430-sdma", },
> >>> +	{ .compatible = "ti,omap3430-sdma", },
> >>> +	{ .compatible = "ti,omap3630-sdma", },
> >>> +	{ .compatible = "ti,omap4430-sdma", },
> >>> +	{},
> >>> +};
> >>> +MODULE_DEVICE_TABLE(of, omap_dma_match);
> >>> +
> >>>  static struct platform_driver omap_dma_driver = {
> >>>  	.probe	= omap_dma_probe,
> >>>  	.remove	= omap_dma_remove,
> >>>  	.driver = {
> >>>  		.name = "omap-dma-engine",
> >>>  		.owner = THIS_MODULE,
> >>> +		.of_match_table = of_match_ptr(omap_dma_match),
> >>>  	},
> >>>  };
> >>
> >> Who's tree does it make most sense for this patch to go through?
> >>
> >> Benoit has queued up patch 1/2 and so I am not sure if this should go
> >> via Benoit tree to Tony or directly via Vinod's tree. What are your
> >> thoughts?
> > 
> > OK
> >  
> >> It would be great if this could make v3.10.
> > 
> > I suggest Vinod/Grant/Linus W queue this patch:
> > 
> > Acked-by: Tony Lindgren <tony at atomide.com>
> 
> Can you take this patch with Tony's ACK? Let me know if you want me to
> resend with the ACK.
ahhh due to my vcation/travel looks like this one was skipped, I have
applied it now should show up in linus's tree during next merg window

Sorry for delay

~Vinod
> 
> Cheers
> Jon
> 


From linux at prisktech.co.nz  Mon Apr  1 14:59:55 2013
From: linux at prisktech.co.nz (Tony Prisk)
Date: Tue, 02 Apr 2013 07:59:55 +1300
Subject: [PATCHv3 3/6] pinctrl: gpio: vt8500: Add pincontrol driver for
 arch-vt8500
In-Reply-To: <5159BE78.5020905@wwwdotorg.org>
References: <1364451049-2981-1-git-send-email-linux@prisktech.co.nz>
 <1364451049-2981-4-git-send-email-linux@prisktech.co.nz>
 <5159BE78.5020905@wwwdotorg.org>
Message-ID: <5159D92B.9020401@prisktech.co.nz>

On 02/04/13 06:06, Stephen Warren wrote:
> On 03/28/2013 12:10 AM, Tony Prisk wrote:
>> This patch adds support for the GPIO/pinmux controller found on the VIA
>> VT8500 and Wondermedia WM8xxx-series SoCs.
>>
>> Each pin within the controller is capable of operating as a GPIO or as
>> an alternate function. The pins are numbered according to their control
>> bank/bit so that if new pins are added, the existing numbering is maintained.
>>
>> All currently supported SoCs are included: VT8500, WM8505, WM8650, WM8750 and
>> WM8850.
>> diff --git a/drivers/pinctrl/vt8500/pinctrl-wmt.c b/drivers/pinctrl/vt8500/pinctrl-wmt.c
>> +static int wmt_pctl_dt_node_to_map_pull(struct wmt_pinctrl_data *data,
>> +					struct device_node *np,
>> +					u32 pin, u32 pull,
>> +					struct pinctrl_map **maps)
>> +	configs[0] = 0;
> I assume that should be
>
> 	configs[0] = pull;
Err, yeah. Oops.
>> +static int wmt_pctl_dt_node_to_map(struct pinctrl_dev *pctldev,
>> +				   struct device_node *np,
>> +				   struct pinctrl_map **map,
>> +				   unsigned *num_maps)
>> +fail:
>> +	kfree(maps);
>> +	return err;
>> +}
> There, I think you also want to iterate over maps[] and free
> map->data.configs.config for any PIN_MAP_TYPE_CONFIGS_PIN.
>
> Perhaps just call wmt_pctl_dt_free_map() here, with roughly nmaps =
> cur_map - maps?
I have dropped the kfree() and used devm_kzalloc instead. Makes the fail 
path tidier as well.
>> +static int wmt_gpio_of_xlate(struct gpio_chip *gc,
>> +				const struct of_phandle_args *gpiospec,
>> +				u32 *flags)
>> +{
>> +	if (flags)
>> +		*flags = gpiospec->args[1];
>> +
>> +	return gpiospec->args[0];
>> +}
> Can't you use of_gpio_simple_xlate(), and hence just not set .of_xlate in:
I have dropped this - as you pointed out, ..simple_xlate() is an 
equivalent.
>
>> +static struct gpio_chip wmt_gpio_chip = {
> ...
>> +	.of_xlate = wmt_gpio_of_xlate,
> Aside from that, this patch,
>
> Reviewed-by: Stephen Warren <swarren at nvidia.com>
>
> Although I didn't review pinctrl-*.c other than pinctrl-wmt.c, since
> they're just big tables of data. Oh, except that the following could
> probably be moved inside wmt_pinctrl_probe()?
>
>> +	struct wmt_pinctrl_data *data;
>> +	struct resource *res;
>> +
>> +	data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
>> +	if (!data) {
>> +		dev_err(&pdev->dev, "failed to allocate data\n");
>> +		return -ENOMEM;
>> +	}
>> +
>> +	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> +	data->base = devm_request_and_ioremap(&pdev->dev, res);
>> +	if (!data->base) {
>> +		dev_err(&pdev->dev, "failed to map memory resource\n");
>> +		return -EBUSY;
>> +	}
I have moved the resource-related portion of this code to the common 
init. The data part needs to be here to assign the per-soc variables to.

Thanks for the review.
Regards
Tony P


From swarren at wwwdotorg.org  Mon Apr  1 15:02:52 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Mon, 01 Apr 2013 13:02:52 -0600
Subject: [PATCHv3 3/6] pinctrl: gpio: vt8500: Add pincontrol driver for
 arch-vt8500
In-Reply-To: <5159D92B.9020401@prisktech.co.nz>
References: <1364451049-2981-1-git-send-email-linux@prisktech.co.nz>
 <1364451049-2981-4-git-send-email-linux@prisktech.co.nz>
 <5159BE78.5020905@wwwdotorg.org> <5159D92B.9020401@prisktech.co.nz>
Message-ID: <5159D9DC.9070201@wwwdotorg.org>

On 04/01/2013 12:59 PM, Tony Prisk wrote:
> On 02/04/13 06:06, Stephen Warren wrote:
>> On 03/28/2013 12:10 AM, Tony Prisk wrote:
>>> This patch adds support for the GPIO/pinmux controller found on the VIA
>>> VT8500 and Wondermedia WM8xxx-series SoCs.
>>>
>>> Each pin within the controller is capable of operating as a GPIO or as
>>> an alternate function. The pins are numbered according to their control
>>> bank/bit so that if new pins are added, the existing numbering is
>>> maintained.
>>>
>>> All currently supported SoCs are included: VT8500, WM8505, WM8650,
>>> WM8750 and
>>> WM8850.

>>> diff --git a/drivers/pinctrl/vt8500/pinctrl-wmt.c

>>> +static int wmt_pctl_dt_node_to_map(struct pinctrl_dev *pctldev,
>>> +                   struct device_node *np,
>>> +                   struct pinctrl_map **map,
>>> +                   unsigned *num_maps)
>>> +fail:
>>> +    kfree(maps);
>>> +    return err;
>>> +}
>
>> There, I think you also want to iterate over maps[] and free
>> map->data.configs.config for any PIN_MAP_TYPE_CONFIGS_PIN.
>>
>> Perhaps just call wmt_pctl_dt_free_map() here, with roughly nmaps =
>> cur_map - maps?
>
> I have dropped the kfree() and used devm_kzalloc instead. Makes the fail
> path tidier as well.

Does the pinctrl core guarantee that the map table entries get removed
when unregistering the pincontrol driver? If it does, I guess that
change is safe. If not, perhaps not. I guess it must though.


From nm at ti.com  Mon Apr  1 15:14:36 2013
From: nm at ti.com (Nishanth Menon)
Date: Mon, 1 Apr 2013 14:14:36 -0500
Subject: omap cpufreq driver in multi-platform kernels
In-Reply-To: <5159C1FA.8090000@ti.com>
References: <5152503C.2050503@gmail.com>
 <alpine.DEB.2.00.1303270212110.8161@utopia.booyaka.com>
 <20130327133220.GA30868@kahuna> <5153207A.4050109@gmail.com>
 <20130327170221.GA32231@kahuna> <87d2uk91ai.fsf@linaro.org>
 <20130327175621.GA32693@kahuna>
 <alpine.DEB.2.00.1303302156180.6436@utopia.booyaka.com>
 <5159C1FA.8090000@ti.com>
Message-ID: <CAGo_u6o5iZF_Bs_vh1vr7qOhX_gJ7nXA3u0FWpRpOZO2J15FJQ@mail.gmail.com>

+cpufreq list as it seems most appropriate discussion forum.

discussion thread: http://marc.info/?t=136434901900001&r=1&w=2

On Mon, Apr 1, 2013 at 12:20 PM, Eduardo Valentin
<eduardo.valentin at ti.com> wrote:
> Hey Paul,
>
>
> On 30-03-2013 18:21, Paul Walmsley wrote:
>>
>> Hi folks,
>>
>> On Wed, 27 Mar 2013, Nishanth Menon wrote:
>>
>>> On 10:53-20130327, Kevin Hilman wrote:
>>>>
>>>> Nishanth Menon <nm at ti.com> writes:
>>>>>
>>>>> On 11:38-20130327, Rob Herring wrote:
>>>>>>
>>>>>> On 03/27/2013 08:32 AM, Nishanth Menon wrote:
>>>>>>>
>>>>>>> On 02:23-20130327, Paul Walmsley wrote:
>>>>>>>>
>>>>>>>> On Tue, 26 Mar 2013, Rob Herring wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Converting the driver to a platform driver would be another option.
>>>>
>>>>
>>>> I think the platform_device conversion is the way to go.  I think you
>>>> should do that instead of PATCH 8/8 of your OMAP conversion to the
>>>> generic driver[1].
>>>
>>>
>>> Yep, thinking about this over lunch, I came to the same conclusion that
>>> instead of checking on DT node existance, platform_device conversion
>>> will solve both parts of the puzzle.
>>
>>
>> Looked at this a little today.  I see that the platform_driver CPUFreq
>> driver approach was taken with several SoCs in mainline. Could someone
>> explain the theory behind making the CPUFreq drivers platform_drivers,
>> rather than just modules?
>>
>> The part that doesn't make sense to me is that the existing CPUFreq
>> drivers don't represent an actual hardware block.  Conceptually, they
>> aren't drivers for the CPU, nor are they drivers for a CPU frequency
>> scaling IP block.  One might as well bind a CPUIdle driver or a CPU
>> throttling thermal driver to the CPU device.
>
>
> I do agree with your point. On the other hand, I'd like to make a
> clarification here.
>
> CPU throttling feature not really done as a driver. The feature is exported
> to be used by policies built by other code. Check
> drivers/thermal/cpu_cooling.c.
>
> Thermal drivers are in fact drivers, as they are bound to an actual hardware
> block, a bandgap, a thermal sensor or a thermistor.
>
>
>
>
>>
>> Wouldn't it be best to just make them modules?
>
>
> Thermal policies are built as modules.
>
>
>>
>> Also, noticed that the Highbank CPUFreq driver creates a virtual device in
>> its code.  That also doesn't seem right.  Isn't device creation better
>> left to DT/ACPI/whatever?
>>

Regards,
Nishanth Menon


From paul at pwsan.com  Mon Apr  1 15:27:03 2013
From: paul at pwsan.com (Paul Walmsley)
Date: Mon, 1 Apr 2013 19:27:03 +0000 (UTC)
Subject: omap cpufreq driver in multi-platform kernels
In-Reply-To: <5159C1FA.8090000@ti.com>
References: <5152503C.2050503@gmail.com>
 <alpine.DEB.2.00.1303270212110.8161@utopia.booyaka.com>
 <20130327133220.GA30868@kahuna> <5153207A.4050109@gmail.com>
 <20130327170221.GA32231@kahuna> <87d2uk91ai.fsf@linaro.org>
 <20130327175621.GA32693@kahuna>
 <alpine.DEB.2.00.1303302156180.6436@utopia.booyaka.com>
 <5159C1FA.8090000@ti.com>
Message-ID: <alpine.DEB.2.00.1304011921240.21548@utopia.booyaka.com>

Hi Eduardo,

On Mon, 1 Apr 2013, Eduardo Valentin wrote:

> On 30-03-2013 18:21, Paul Walmsley wrote:
> > On Wed, 27 Mar 2013, Nishanth Menon wrote:
> > 
> > > On 10:53-20130327, Kevin Hilman wrote:
> > > > Nishanth Menon <nm at ti.com> writes:
> > > > > On 11:38-20130327, Rob Herring wrote:
> > > > > > On 03/27/2013 08:32 AM, Nishanth Menon wrote:
> > > > > > > On 02:23-20130327, Paul Walmsley wrote:
> > > > > > > > On Tue, 26 Mar 2013, Rob Herring wrote:
> > > > > > > > > 
> > > > > > > > > Converting the driver to a platform driver would be another
> > > > > > > > > option.
> > > > 
> > > > I think the platform_device conversion is the way to go.  I think you
> > > > should do that instead of PATCH 8/8 of your OMAP conversion to the
> > > > generic driver[1].
> > > 
> > > Yep, thinking about this over lunch, I came to the same conclusion that
> > > instead of checking on DT node existance, platform_device conversion
> > > will solve both parts of the puzzle.
> > 
> > Looked at this a little today.  I see that the platform_driver CPUFreq
> > driver approach was taken with several SoCs in mainline. Could someone
> > explain the theory behind making the CPUFreq drivers platform_drivers,
> > rather than just modules?
> > 
> > The part that doesn't make sense to me is that the existing CPUFreq
> > drivers don't represent an actual hardware block.  Conceptually, they
> > aren't drivers for the CPU, nor are they drivers for a CPU frequency
> > scaling IP block.  One might as well bind a CPUIdle driver or a CPU
> > throttling thermal driver to the CPU device.
> 
> I do agree with your point. On the other hand, I'd like to make a
> clarification here.
> 
> CPU throttling feature not really done as a driver. The feature is exported to
> be used by policies built by other code. Check drivers/thermal/cpu_cooling.c.
> 
> Thermal drivers are in fact drivers, as they are bound to an actual hardware
> block, a bandgap, a thermal sensor or a thermistor.

That might be the case for some or all of what's in mainline for the 
thermal framework.  But I've seen at least one Linux BSP for an ARM SoC 
implement a thermal "cooling device" that isn't directly backed by any 
hardware IP block.  

Anyway, this is kind of a tangent.


- Paul


From sylvester.nawrocki at gmail.com  Mon Apr  1 15:34:47 2013
From: sylvester.nawrocki at gmail.com (Sylwester Nawrocki)
Date: Mon, 01 Apr 2013 21:34:47 +0200
Subject: [PATCH v4 1/6] drivers: phy: add generic PHY framework
In-Reply-To: <1364449408-9510-2-git-send-email-kishon@ti.com>
References: <1364449408-9510-1-git-send-email-kishon@ti.com>
 <1364449408-9510-2-git-send-email-kishon@ti.com>
Message-ID: <5159E157.6000800@gmail.com>

Just couple minor comments...

On 03/28/2013 06:43 AM, Kishon Vijay Abraham I wrote:
> The PHY framework provides a set of APIs for the PHY drivers to
> create/destroy a PHY and APIs for the PHY users to obtain a reference to the
> PHY with or without using phandle. To obtain a reference to the PHY without
> using phandle, the platform specfic intialization code (say from board file)
> should have already called phy_bind with the binding information. The binding
> information consists of phy's device name, phy user device name and an index.
> The index is used when the same phy user binds to mulitple phys.
>
> PHY drivers should create the PHY by passing phy_descriptor that has
> describes the PHY (label, type etc..) and ops like init, exit, suspend, resume,
> poweron, shutdown.
>
> The documentation for the generic PHY framework is added in
> Documentation/phy.txt and the documentation for the sysfs entry is added
> in Documentation/ABI/testing/sysfs-class-phy and the documentation for
> dt binding is can be found at
> Documentation/devicetree/bindings/phy/phy-bindings.txt
>
> Signed-off-by: Kishon Vijay Abraham I<kishon at ti.com>
> ---
[...]
> +/**
> + * phy_put - release the PHY

nit: According to kernel-doc documentation function names should have
parentheses appended to the name. So it would need to be

+ * phy_put() - release the PHY

in this case and it applies to multiple places elsewhere in this patch.

> + * @phy: the phy returned by phy_get()
> + *
> + * Releases a refcount the caller received from phy_get().
> + */
> +void phy_put(struct phy *phy)
> +{
> +	if (phy) {
> +		module_put(phy->ops->owner);
> +		put_device(&phy->dev);
> +	}
> +}
> +EXPORT_SYMBOL_GPL(phy_put);
[...]
> +/**
> + * devm_of_phy_get_byname - lookup and obtain a reference to a phy by name
> + * @dev: device that requests this phy
> + * @string - the phy name as given in the dt data

s/ -/:

> + *
> + * Calls devm_of_phy_get (which associates the device with the phy using devres
> + * on successful phy get) and passes on the return value of devm_of_phy_get.
> + */
> +struct phy *devm_of_phy_get_byname(struct device *dev, const char *string)
> +{
> +	int index;
> +
> +	if (!dev->of_node) {
> +		dev_dbg(dev, "device does not have a device node entry\n");
> +		return ERR_PTR(-EINVAL);
> +	}
> +
> +	index = of_property_match_string(dev->of_node, "phy-names", string);
> +
> +	return devm_of_phy_get(dev, index);
> +}
> +EXPORT_SYMBOL_GPL(devm_of_phy_get_byname);
> +
> +/**
> + * phy_get - lookup and obtain a reference to a phy.
> + * @dev: device that requests this phy
> + * @index: the index of the phy
> + *
> + * Returns the phy driver, after getting a refcount to it; or
> + * -ENODEV if there is no such phy.  The caller is responsible for
> + * calling phy_put() to release that count.
> + */
> +struct phy *phy_get(struct device *dev, int index)
> +{
> +	struct phy *phy = NULL;

Unneeded initialization.

> +	phy = phy_lookup(dev, index);
> +	if (IS_ERR(phy)) {
> +		dev_err(dev, "unable to find phy\n");
> +		goto err0;

Wouldn't it be better to just do:

		return phy;
> +	}
> +
> +	if (!try_module_get(phy->ops->owner)) {
> +		phy = ERR_PTR(-EPROBE_DEFER);

and
		return ERR_PTR(-EPROBE_DEFER);

> +		goto err0;

and to drop this goto and the label below ?

> +	}
> +
> +	get_device(&phy->dev);
> +
> +err0:
> +	return phy;
> +}
> +EXPORT_SYMBOL_GPL(phy_get);

> diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
> new file mode 100644
> index 0000000..0cb2298
> --- /dev/null
> +++ b/include/linux/phy/phy.h
> @@ -0,0 +1,237 @@
> +/*
> + * phy.h -- generic phy header file
[...]
> +#ifndef __DRIVERS_PHY_H
> +#define __DRIVERS_PHY_H
> +
> +#include<linux/err.h>
> +#include<linux/of.h>
> +
> +struct phy

I think you also need to add either

#include <linux/device.h>

or

struct device;

struct device * is used further in this file.

> +/**
> + * struct phy_ops - set of function pointers for performing phy operations
> + * @init: operation to be performed for initializing phy
> + * @exit: operation to be performed while exiting
> + * @suspend: suspending the phy
> + * @resume: resuming the phy

> + * @poweron: powering on the phy
> + * @shutdown: shutting down the phy

Could these be named power_on/power_off ? Looks a bit more symmetric
to me that way.

> + * @owner: the module owner containing the ops
> + */
> +struct phy_ops {
> +	int	(*init)(struct phy *phy);
> +	int	(*exit)(struct phy *phy);
> +	int	(*suspend)(struct phy *phy);
> +	int	(*resume)(struct phy *phy);
> +	int	(*poweron)(struct phy *phy);
> +	int	(*shutdown)(struct phy *phy);
> +	struct module *owner;
> +};

Thanks,
Sylwester


From robherring2 at gmail.com  Mon Apr  1 15:46:07 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Mon, 01 Apr 2013 14:46:07 -0500
Subject: omap cpufreq driver in multi-platform kernels
In-Reply-To: <alpine.DEB.2.00.1303302156180.6436@utopia.booyaka.com>
References: <5152503C.2050503@gmail.com>
 <alpine.DEB.2.00.1303270212110.8161@utopia.booyaka.com>
 <20130327133220.GA30868@kahuna> <5153207A.4050109@gmail.com>
 <20130327170221.GA32231@kahuna> <87d2uk91ai.fsf@linaro.org>
 <20130327175621.GA32693@kahuna>
 <alpine.DEB.2.00.1303302156180.6436@utopia.booyaka.com>
Message-ID: <5159E3FF.4050308@gmail.com>

On 03/30/2013 05:21 PM, Paul Walmsley wrote:
> Hi folks,
> 
> On Wed, 27 Mar 2013, Nishanth Menon wrote:
> 
>> On 10:53-20130327, Kevin Hilman wrote:
>>> Nishanth Menon <nm at ti.com> writes:
>>>> On 11:38-20130327, Rob Herring wrote:
>>>>> On 03/27/2013 08:32 AM, Nishanth Menon wrote:
>>>>>> On 02:23-20130327, Paul Walmsley wrote:
>>>>>>> On Tue, 26 Mar 2013, Rob Herring wrote:
>>>>>>>>
>>>>>>>> Converting the driver to a platform driver would be another option.
>>>
>>> I think the platform_device conversion is the way to go.  I think you
>>> should do that instead of PATCH 8/8 of your OMAP conversion to the
>>> generic driver[1].
>>
>> Yep, thinking about this over lunch, I came to the same conclusion that
>> instead of checking on DT node existance, platform_device conversion
>> will solve both parts of the puzzle.
> 
> Looked at this a little today.  I see that the platform_driver CPUFreq 
> driver approach was taken with several SoCs in mainline. Could someone 
> explain the theory behind making the CPUFreq drivers platform_drivers, 
> rather than just modules?
> 
> The part that doesn't make sense to me is that the existing CPUFreq 
> drivers don't represent an actual hardware block.  Conceptually, they 
> aren't drivers for the CPU, nor are they drivers for a CPU frequency 
> scaling IP block.  One might as well bind a CPUIdle driver or a CPU 
> throttling thermal driver to the CPU device.

It's not really a cpu device, but rather a virtual device. We could have
multiple devices. cpuidle drivers have the same issue.

> Wouldn't it be best to just make them modules?

Then module auto loading doesn't work AFAIK. We will want them to be
built as modules in multi-platform kernels to reduce the kernel size,
but you don't want to just shift the problem to the OS to decide what
modules a given platform needs.

> Also, noticed that the Highbank CPUFreq driver creates a virtual device in 
> its code.  That also doesn't seem right.  Isn't device creation better 
> left to DT/ACPI/whatever?

DT describes the h/w. Creating DT nodes that match the cpufreq drivers
is not describing the h/w, but what Linux wants currently. Cpufreq
drivers either touch parts of multiple h/w blocks, a single shared h/w
block or don't touch h/w directly. The cpufreq-cpu0 driver is the last
case and does use DT. Perhaps we will get to the point that all
low-level interfaces are abstracted and we can have a single cpufreq driver.

I think platform drivers are the right way to go, but I'd like to come
up with a better way to instantiate the devices. The only idea I've come
up with is to do some sort of automatic device creation based machine
compatible property matching.

Rob


From aaro.koskinen at iki.fi  Mon Apr  1 16:03:00 2013
From: aaro.koskinen at iki.fi (Aaro Koskinen)
Date: Mon,  1 Apr 2013 23:03:00 +0300
Subject: [PATCH v2 RESEND] ARM: OMAP1: fix omap_udc registration
Message-ID: <1364846580-5256-1-git-send-email-aaro.koskinen@iki.fi>

omap_udc platform device is not registered properly anymore:
CONFIG_USB_GADGET_OMAP was deleted by 193ab2a6 (usb: gadget: allow
multiple gadgets to be built) already in v3.1.

Fix by using CONFIG_USB_OMAP instead. Tested on Nokia 770 by checking
that omap_udc is probed & working properly when built as a module.

Acked-by: Felipe Balbi <balbi at ti.com>
Signed-off-by: Aaro Koskinen <aaro.koskinen at iki.fi>
---

	Patch history:

	v2: http://marc.info/?t=136266319800006&r=1&w=2
            - use IS_ENABLED()

	v1: http://marc.info/?t=136260886600006&r=1&w=2

 arch/arm/mach-omap1/include/mach/usb.h |    2 +-
 arch/arm/mach-omap1/usb.c              |    6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-omap1/include/mach/usb.h b/arch/arm/mach-omap1/include/mach/usb.h
index 753cd5c..45e5ac7 100644
--- a/arch/arm/mach-omap1/include/mach/usb.h
+++ b/arch/arm/mach-omap1/include/mach/usb.h
@@ -2,7 +2,7 @@
  * FIXME correct answer depends on hmc_mode,
  * as does (on omap1) any nonzero value for config->otg port number
  */
-#ifdef	CONFIG_USB_GADGET_OMAP
+#if IS_ENABLED(CONFIG_USB_OMAP)
 #define	is_usb0_device(config)	1
 #else
 #define	is_usb0_device(config)	0
diff --git a/arch/arm/mach-omap1/usb.c b/arch/arm/mach-omap1/usb.c
index 1a1db59..4118db5 100644
--- a/arch/arm/mach-omap1/usb.c
+++ b/arch/arm/mach-omap1/usb.c
@@ -123,7 +123,7 @@ omap_otg_init(struct omap_usb_config *config)
 	syscon = omap_readl(OTG_SYSCON_1);
 	syscon |= HST_IDLE_EN|DEV_IDLE_EN|OTG_IDLE_EN;
 
-#ifdef	CONFIG_USB_GADGET_OMAP
+#if IS_ENABLED(CONFIG_USB_OMAP)
 	if (config->otg || config->register_dev) {
 		struct platform_device *udc_device = config->udc_device;
 		int status;
@@ -169,7 +169,7 @@ omap_otg_init(struct omap_usb_config *config)
 void omap_otg_init(struct omap_usb_config *config) {}
 #endif
 
-#ifdef	CONFIG_USB_GADGET_OMAP
+#if IS_ENABLED(CONFIG_USB_OMAP)
 
 static struct resource udc_resources[] = {
 	/* order is significant! */
@@ -600,7 +600,7 @@ static void __init omap_1510_usb_init(struct omap_usb_config *config)
 	while (!(omap_readw(ULPD_DPLL_CTRL) & DPLL_LOCK))
 		cpu_relax();
 
-#ifdef	CONFIG_USB_GADGET_OMAP
+#if IS_ENABLED(CONFIG_USB_OMAP)
 	if (config->register_dev) {
 		int status;
 
-- 
1.7.10.4



From aaro.koskinen at iki.fi  Mon Apr  1 16:04:04 2013
From: aaro.koskinen at iki.fi (Aaro Koskinen)
Date: Mon,  1 Apr 2013 23:04:04 +0300
Subject: [PATCH] ARM: OMAP: RX-51: add missing regulator supply definitions
 for lis3lv02d
Message-ID: <1364846644-5302-1-git-send-email-aaro.koskinen@iki.fi>

Add missing regulator definitions for lis3lv02d accelerometer. Fixes
the following probe issue:

[   57.737518] lis3lv02d_i2c 3-001d: Failed to get supply 'Vdd': -517
[   57.747100] i2c 3-001d: Driver lis3lv02d_i2c requests probe deferral

Reported-by: Pali Roh?r <pali.rohar at gmail.com>
Reviewed-by: Mark Brown <broonie at opensource.wolfsonmicro.com>
Signed-off-by: Aaro Koskinen <aaro.koskinen at iki.fi>
---

	The patch was discussed in this thread...

		http://marc.info/?t=136105842400001&r=1&w=2

	...and now sending it to relevant mailing lists.

 arch/arm/mach-omap2/board-rx51-peripherals.c |    4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c b/arch/arm/mach-omap2/board-rx51-peripherals.c
index 3a077df..1a88467 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -547,12 +547,16 @@ static struct regulator_consumer_supply rx51_vio_supplies[] = {
 	REGULATOR_SUPPLY("DVDD", "2-0019"),
 	/* Si4713 IO supply */
 	REGULATOR_SUPPLY("vio", "2-0063"),
+	/* lis3lv02d */
+	REGULATOR_SUPPLY("Vdd_IO", "3-001d"),
 };
 
 static struct regulator_consumer_supply rx51_vaux1_consumers[] = {
 	REGULATOR_SUPPLY("vdds_sdi", "omapdss"),
 	/* Si4713 supply */
 	REGULATOR_SUPPLY("vdd", "2-0063"),
+	/* lis3lv02d */
+	REGULATOR_SUPPLY("Vdd", "3-001d"),
 };
 
 static struct regulator_init_data rx51_vaux1 = {
-- 
1.7.10.4



From martinez.javier at gmail.com  Mon Apr  1 16:05:00 2013
From: martinez.javier at gmail.com (Javier Martinez Canillas)
Date: Mon, 1 Apr 2013 22:05:00 +0200
Subject: [RFC][BUG] arm/dts: OMAP3: set #interrupt-cells to two
In-Reply-To: <1364834508.3939.74.camel@mars>
References: <1364631689.3767.7.camel@mars>
 <CAAwP0s35J-edpvFv08xjjpwaezQBYNvMNhhXL-UacsuUtSt4ZA@mail.gmail.com>
 <1364834508.3939.74.camel@mars>
Message-ID: <CAAwP0s1H9zaBZPMDz9=He-E68UK0Ay3jnxZ2frYH9r1xNeQhxQ@mail.gmail.com>

On Mon, Apr 1, 2013 at 6:41 PM, Christoph Fritz
<chf.fritz at googlemail.com> wrote:
> Hi Javier
>
> On Sat, 2013-03-30 at 14:18 +0100, Javier Martinez Canillas wrote:
>> A call to gpio_request() to enable the GPIO bank is needed before
>> using a GPIO as an IRQ source, otherwise accesses to the GPIO bank
>> registers fails making the kernel to hang.
>
> Yes, that is exactly my problem here. I'm using the GPIO as an IRQ
> source.
>
>> Jon's (added as cc)"gpio/omap: warn if bank is not enabled on setting
>> irq type" patch [1] fixes the issue by warning and returning -EINVAL.
>>
>> This patch will make the kernel to boot but the call to request_irq()
>> will fail of course. For now, the only solution is to call
>> gpio_request() before request_irq() in your platform code or device
>> driver. There is an on going discussion about what's the better way to
>> address this but we still haven't found a good solution to this
>> problem, you can see the last email for this discussion here [2]
>>
>> Also, even when calling gpio_request() before request_irq() this won't
>> work. When specifying the trigger/level flags on the second cell for
>> an GPIO-IRQ, this is not set on the IORESOURCE_IRQ struct resource.
>> The IRQ flag is set on of_irq_to_resource() but it just does:
>>
>> r->flags = IORESOURCE_IRQ;
>>
>> and then the call stack is irq_to_parse_and_map() ->
>> irq_set_irq_type() ->  __irq_set_trigger() -> chip->irq_set_type() ->
>> (drivers/gpio/gpio-omap.c) gpio_irq_type().
>>
>> So, even when gpio_irq_type() receive the correct flags, this are not
>> returned neither stored on the flags member of the IORESOURCE_IRQ
>> struct resource that passed to the drivers in their struct
>> platform_device.
>
> As a quick-fix (hack) I wrote directly to the registers in gpio_probe()
> to enable GPIO banks. I now geht this:
>
>> > [    0.214630] omap_gpio_probe, 1133, CM_CLKSEL_PER 0x48005040: 0x000000ff
>> > [    0.214660] omap_gpio_probe, 1136, CM_ICLKEN_PER 0x48005010: 0x0007ffff
>> > [    0.214660] omap_gpio_probe, 1139, CM_FCLKEN_PER 0x48005000: 0x0007ffff
>
> And it works for me. _But_ when I do enable regulator twl4030
> (CONFIG_REGULATOR_TWL4030=y) in my config these registers get reset:
>
> [    2.935455] smsc911x_open, 1537, CM_CLKSEL_PER 0x48005040: 0x000000ff
> [    2.942291] smsc911x_open, 1540, CM_ICLKEN_PER 0x48005010: 0x00040fff
> [    2.949066] smsc911x_open, 1543, CM_FCLKEN_PER 0x48005000: 0x00000000
>
> And the IRQ source for the network chip (smsc911x) is disabled :-(
>
> Do you have any idea how to ("quick") fix this?
>

A quick hack is to call gpio_request() explicitly before calling to
irq_set_type() is made.
I've this patch just to make it work until we find a clean solution:

diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 90c15ee..d594e1d 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -14,6 +14,7 @@
  */
 #undef DEBUG

+#include <linux/gpio.h>
 #include <linux/irq.h>
 #include <linux/kernel.h>
 #include <linux/init.h>
@@ -1528,6 +1529,11 @@ static int gpmc_probe_dt(struct platform_device *pdev)
                return ret;
        }

+       ret = gpio_request_one(176, GPIOF_IN, "smsc911x irq");
+       if (ret) {
+               pr_err("Failed to request IRQ GPIO%d\n", 176);
+               return ret;
+       }
+
        for_each_node_by_name(child, "nand") {
                ret = gpmc_probe_nand_child(pdev, child);
                if (ret < 0) {

This solves the issue of the non-initialized GPIO bank before that
makes the kernel to hang. Since I've to configure the IRQ polarity as
active low level-sensitive on my board and the flags are not set by
the IRQ core, I've another ugly hack that forces this:

diff --git a/drivers/net/ethernet/smsc/smsc911x.c
b/drivers/net/ethernet/smsc/smsc
index da5cc9a..27e46f9 100644
--- a/drivers/net/ethernet/smsc/smsc911x.c
+++ b/drivers/net/ethernet/smsc/smsc911x.c
@@ -2390,6 +2390,9 @@ static int smsc911x_drv_probe(struct
platform_device *pdev)
        pdata = netdev_priv(dev);
        dev->irq = irq_res->start;
-        irq_flags = irq_res->flags & IRQF_TRIGGER_MASK;
+       irq_flags = IRQF_TRIGGER_LOW;
        pdata->ioaddr = ioremap_nocache(res->start, res_size);

        pdata->dev = dev;

>  Thanks
>   -- Christoph
>

I hope to find some time this week to work on this and at least find a
solution for the second issue (IORESOURCE_IRQ struct resource flags
not being set).

Best regards,
Javier


From khc at pm.waw.pl  Mon Apr  1 16:17:31 2013
From: khc at pm.waw.pl (Krzysztof Halasa)
Date: Mon, 01 Apr 2013 22:17:31 +0200
Subject: [PATCH] Fix IXP4xx coherent allocations
In-Reply-To: <20130330153135.GC17995@n2100.arm.linux.org.uk> (Russell King's
 message of "Sat, 30 Mar 2013 15:31:35 +0000")
References: <m3obe9lxil.fsf@intrepid.localdomain>
 <20130323.195740.2108147521543354261.davem@davemloft.net>
 <1364152267.3620.31.camel@deadeye.wl.decadent.org.uk>
 <m3r4j4sdmv.fsf@intrepid.localdomain>
 <20130330132915.GB17995@n2100.arm.linux.org.uk>
 <m3d2uhdl1l.fsf@intrepid.localdomain>
 <20130330153135.GC17995@n2100.arm.linux.org.uk>
Message-ID: <m3d2uexaxw.fsf@intrepid.localdomain>

Russell King - ARM Linux <linux at arm.linux.org.uk> writes:

> Right, so, the answer is - yes you are talking about platform devices,
> and the reason that these aren't already set is because if you grep for
> ixp4xx_eth or ixp4xx_hss in arch/arm/mach-ixp4xx, you'll notice that
> _none_ of the device declarations set either of the DMA masks at all.
> They don't even set the dev->dma_mask pointer.  That is why the masks
> are zero.  For a device which does DMA, that is wrong.

Well, that's new to me. Please tell me how it should be done.
Should I simply add in platform code (on all platforms):

+++ b/arch/arm/mach-ixp4xx/XXX.c
@@ -380,10 +380,12 @@ static struct platform_device device_eth_tab[] = {
         .name           = "ixp4xx_eth",
         .id         = IXP4XX_ETH_NPEB,
         .dev.platform_data  = eth_plat,
+        .dev.coherent_dma_mask  = DMA_BIT_MASK(32),
     }, {
         .name           = "ixp4xx_eth",
         .id         = IXP4XX_ETH_NPEC,
         .dev.platform_data  = eth_plat + 1,
+        .dev.coherent_dma_mask  = DMA_BIT_MASK(32),
     }
 };

This alone isn't going to work, the problem is coherent DMA mask in
net_dev->dev and not in platform_device. So what do I do in the network
drivers? Copy the masks from platform_device to the actual newly created
net_dev->dev?

Should I use the parent device (net_dev->dev.parent which is the
platform_device) as the argument to the allocator? This would probably
work though I'm not sure of its correctness.

BTW the platform code shouldn't IMHO need to declare the masks as they
aren't platform-specific. They are driver-specific (defined by CPU
design) and setting them in the driver seems clean to me (unlike the
platform code).

Several other device drivers simply set their masks directly. Is it the
recommended way?

> If you look at the PCI code, it pre-initializes the DMA mask to be 4GiB:
> drivers/pci/probe.c:        dev->dev.coherent_dma_mask = 0xffffffffull;
>
> And that is what is missing from the IXP4xx platform code.
>
> However, avoiding the call to dma_set_coherent_mask() from within the
> driver also seems to be questionable as it bypasses the "check if the
> mask is possible" part of the DMA API.

I thought about this for a second but the situation is the mask
is guaranteed to be valid (these are on-chip devices).
-- 
Krzysztof Halasa


From robherring2 at gmail.com  Mon Apr  1 16:58:32 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Mon,  1 Apr 2013 15:58:32 -0500
Subject: [PATCH v2 1/3] ARM: sched_clock: allow changing to higher frequency
 counter
In-Reply-To: <1364849914-26420-1-git-send-email-robherring2@gmail.com>
References: <1364849914-26420-1-git-send-email-robherring2@gmail.com>
Message-ID: <1364849914-26420-2-git-send-email-robherring2@gmail.com>

From: Rob Herring <rob.herring at calxeda.com>

Allow multiple calls to setup_sched_clock and switch to the new counter
if it is higher frequency.

Signed-off-by: Rob Herring <rob.herring at calxeda.com>
---
 arch/arm/kernel/sched_clock.c |    6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/arm/kernel/sched_clock.c b/arch/arm/kernel/sched_clock.c
index bd6f56b..040168e 100644
--- a/arch/arm/kernel/sched_clock.c
+++ b/arch/arm/kernel/sched_clock.c
@@ -20,6 +20,7 @@ struct clock_data {
 	u64 epoch_ns;
 	u32 epoch_cyc;
 	u32 epoch_cyc_copy;
+	unsigned long rate;
 	u32 mult;
 	u32 shift;
 	bool suspended;
@@ -113,11 +114,14 @@ void __init setup_sched_clock(u32 (*read)(void), int bits, unsigned long rate)
 	u64 res, wrap;
 	char r_unit;
 
+	if (cd.rate > rate)
+		return;
+
 	BUG_ON(bits > 32);
 	WARN_ON(!irqs_disabled());
-	WARN_ON(read_sched_clock != jiffy_sched_clock_read);
 	read_sched_clock = read;
 	sched_clock_mask = (1 << bits) - 1;
+	cd.rate = rate;
 
 	/* calculate the mult/shift to convert counter ticks to ns. */
 	clocks_calc_mult_shift(&cd.mult, &cd.shift, rate, NSEC_PER_SEC, 0);
-- 
1.7.10.4



From robherring2 at gmail.com  Mon Apr  1 16:58:33 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Mon,  1 Apr 2013 15:58:33 -0500
Subject: [PATCH v2 2/3] ARM: make sched_clock just call a function pointer
In-Reply-To: <1364849914-26420-1-git-send-email-robherring2@gmail.com>
References: <1364849914-26420-1-git-send-email-robherring2@gmail.com>
Message-ID: <1364849914-26420-3-git-send-email-robherring2@gmail.com>

From: Rob Herring <rob.herring at calxeda.com>

This converts sched_clock to simply a call to a function pointer in order
to allow overriding it. This will allow for use with 64-bit counters where
overflow handling is not needed.

Signed-off-by: Rob Herring <rob.herring at calxeda.com>
---
 arch/arm/include/asm/sched_clock.h |    2 ++
 arch/arm/kernel/sched_clock.c      |    9 ++++++++-
 2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/sched_clock.h b/arch/arm/include/asm/sched_clock.h
index e3f7572..3d520dd 100644
--- a/arch/arm/include/asm/sched_clock.h
+++ b/arch/arm/include/asm/sched_clock.h
@@ -11,4 +11,6 @@
 extern void sched_clock_postinit(void);
 extern void setup_sched_clock(u32 (*read)(void), int bits, unsigned long rate);
 
+extern unsigned long long (*sched_clock_func)(void);
+
 #endif
diff --git a/arch/arm/kernel/sched_clock.c b/arch/arm/kernel/sched_clock.c
index 040168e..8805848 100644
--- a/arch/arm/kernel/sched_clock.c
+++ b/arch/arm/kernel/sched_clock.c
@@ -165,12 +165,19 @@ void __init setup_sched_clock(u32 (*read)(void), int bits, unsigned long rate)
 	pr_debug("Registered %pF as sched_clock source\n", read);
 }
 
-unsigned long long notrace sched_clock(void)
+static unsigned long long notrace sched_clock_32(void)
 {
 	u32 cyc = read_sched_clock();
 	return cyc_to_sched_clock(cyc, sched_clock_mask);
 }
 
+unsigned long long __read_mostly (*sched_clock_func)(void) = sched_clock_32;
+
+unsigned long long notrace sched_clock(void)
+{
+	return sched_clock_func();
+}
+
 void __init sched_clock_postinit(void)
 {
 	/*
-- 
1.7.10.4



From robherring2 at gmail.com  Mon Apr  1 16:58:31 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Mon,  1 Apr 2013 15:58:31 -0500
Subject: [PATCH v2 0/3] ARM sched_clock selection enhancements
Message-ID: <1364849914-26420-1-git-send-email-robherring2@gmail.com>

From: Rob Herring <rob.herring at calxeda.com>

In preparation to move more timer initialization to use CLKSRC_OF and
out of the platforms, a way to select the timer used for sched_clock is
needed. This series makes the ARM sched_clock function override-able and
makes the sched_clock setup code prefer higher frequency counters. This
is sufficient at least on ARM Ltd boards to use the 24MHz counter rather
than sp804 and to always use the 64-bit architected timer when present.
This mechanism can be extended to DT properties if needed for any
non-discoverable h/w feature.

Patch 1 is unchanged from the prior version. Patch 2 is completely
rewritten and more simple than the prior version. It simply converts
sched_clock to a function pointer which can be overridden by the
architected timer init. It seems unlikely we will have other 64-bit
timers or not want to use the architected timer.

Rob

Rob Herring (3):
  ARM: sched_clock: allow changing to higher frequency counter
  ARM: make sched_clock just call a function pointer
  ARM: arch_timer: use full 64-bit counter for sched_clock

 arch/arm/include/asm/sched_clock.h |    2 ++
 arch/arm/kernel/arch_timer.c       |   15 ++++++++++-----
 arch/arm/kernel/sched_clock.c      |   15 +++++++++++++--
 3 files changed, 25 insertions(+), 7 deletions(-)

-- 
1.7.10.4



From robherring2 at gmail.com  Mon Apr  1 16:58:34 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Mon,  1 Apr 2013 15:58:34 -0500
Subject: [PATCH v2 3/3] ARM: arch_timer: use full 64-bit counter for
 sched_clock
In-Reply-To: <1364849914-26420-1-git-send-email-robherring2@gmail.com>
References: <1364849914-26420-1-git-send-email-robherring2@gmail.com>
Message-ID: <1364849914-26420-4-git-send-email-robherring2@gmail.com>

From: Rob Herring <rob.herring at calxeda.com>

Only 32-bits of the arch timer were being used and wrapping was needlessly
being done in s/w. By using the full counter (56-64 bits), we don't need
to deal with wrapping and can simplify the implementation when using
arch timer.

Signed-off-by: Rob Herring <rob.herring at calxeda.com>
---
 arch/arm/kernel/arch_timer.c |   15 ++++++++++-----
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/arch/arm/kernel/arch_timer.c b/arch/arm/kernel/arch_timer.c
index d957a51..a7536d4 100644
--- a/arch/arm/kernel/arch_timer.c
+++ b/arch/arm/kernel/arch_timer.c
@@ -22,9 +22,11 @@ static unsigned long arch_timer_read_counter_long(void)
 	return arch_timer_read_counter();
 }
 
-static u32 arch_timer_read_counter_u32(void)
+static u32 sched_clock_mult __read_mostly;
+
+static unsigned long long notrace arch_timer_sched_clock(void)
 {
-	return arch_timer_read_counter();
+	return arch_timer_read_counter() * sched_clock_mult;
 }
 
 static struct delay_timer arch_delay_timer;
@@ -52,10 +54,13 @@ int __init arch_timer_of_register(void)
 
 int __init arch_timer_sched_clock_init(void)
 {
-	if (arch_timer_get_rate() == 0)
+        u32 arch_timer_rate = arch_timer_get_rate();
+
+	if (arch_timer_rate == 0)
 		return -ENXIO;
 
-	setup_sched_clock(arch_timer_read_counter_u32,
-			  32, arch_timer_get_rate());
+	/* Cache the sched_clock multiplier to save a divide in the hot path. */
+	sched_clock_mult = NSEC_PER_SEC / arch_timer_rate;
+	sched_clock_func = arch_timer_sched_clock;
 	return 0;
 }
-- 
1.7.10.4



From collinsd at codeaurora.org  Mon Apr  1 17:08:48 2013
From: collinsd at codeaurora.org (David Collins)
Date: Mon, 01 Apr 2013 14:08:48 -0700
Subject: How to represent negative values for device tree property
Message-ID: <5159F760.1080605@codeaurora.org>

Hi,

I am working on a thermal driver which needs to be able to read a
temperature threshold from a device tree property.  The hardware supports
thresholds in the range -204.8 to +204.7 C in 0.1 C steps.  I have found,
as I am sure others have as well, that dtc treats a '-' before an integer
in a dtsi file as a syntax error.  Therefore, I need some artificial way
to represent negative numbers in device tree.  Here are the possibilities
that I have thought of so far:

1. Use a second integer to specify the sign of the threshold:
     20000 mC --> <0 20000>
    -20000 mC --> <1 20000>
2. Use a string instead of an integer to specify the threshold and
   then convert it to an integer in the driver software:
     20000 mC --> "20000"
    -20000 mC --> "-20000"
3. Use units of millikelvin instead of millicelcius.  0 mC == 273150 mK
     20000 mC --> <293150>
    -20000 mC --> <253150>
4. Use an arbitrary offset e.g. 0 mC == 1000000
     20000 mC --> <1020000>
    -20000 mC --> <980000>
5. Use the unsigned 32-bit representation for 2?s-compliment
   signed 32-bit integer
     20000 mC --> <20000>
    -20000 mC --> <0xffffb1e0> or <4294947296>

Which of these options would you recommend using?  Is there any better way
to handle negative values that I haven?t listed?  What is the best general
case solution for specifying negative numbers in device tree?

Thanks,
David

-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation


From robherring2 at gmail.com  Mon Apr  1 17:19:34 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Mon, 01 Apr 2013 16:19:34 -0500
Subject: [PATCH] of: Add missing node iteration stubs for disabled
 CONFIG_OF
In-Reply-To: <1362860154-3089-1-git-send-email-tomasz.figa@gmail.com>
References: <1362860154-3089-1-git-send-email-tomasz.figa@gmail.com>
Message-ID: <5159F9E6.50508@gmail.com>

On 03/09/2013 02:15 PM, Tomasz Figa wrote:
> This patch moves several for_each macros out of the #ifdef CONFIG_OF
> block and adds inline stubs for functions used by these macros, compiled
> conditionally when CONFIG_OF is not enabled.
> 
> This eliminates the need to explicitly check for CONFIG_OF in driver
> code using mentioned functions and macros.

Do you have some users of this?

Rob

> 
> Signed-off-by: Tomasz Figa <tomasz.figa at gmail.com>
> ---
>  include/linux/of.h | 92 +++++++++++++++++++++++++++++++++++++-----------------
>  1 file changed, 63 insertions(+), 29 deletions(-)
> 
> diff --git a/include/linux/of.h b/include/linux/of.h
> index a0f1292..7a736b8 100644
> --- a/include/linux/of.h
> +++ b/include/linux/of.h
> @@ -86,6 +86,31 @@ static inline struct device_node *of_node_get(struct device_node *node)
>  static inline void of_node_put(struct device_node *node) { }
>  #endif /* !CONFIG_OF_DYNAMIC */
>  
> +#define for_each_node_by_name(dn, name) \
> +	for (dn = of_find_node_by_name(NULL, name); dn; \
> +	     dn = of_find_node_by_name(dn, name))
> +#define for_each_node_by_type(dn, type) \
> +	for (dn = of_find_node_by_type(NULL, type); dn; \
> +	     dn = of_find_node_by_type(dn, type))
> +#define for_each_compatible_node(dn, type, compatible) \
> +	for (dn = of_find_compatible_node(NULL, type, compatible); dn; \
> +	     dn = of_find_compatible_node(dn, type, compatible))
> +#define for_each_matching_node(dn, matches) \
> +	for (dn = of_find_matching_node(NULL, matches); dn; \
> +	     dn = of_find_matching_node(dn, matches))
> +#define for_each_matching_node_and_match(dn, matches, match) \
> +	for (dn = of_find_matching_node_and_match(NULL, matches, match); \
> +	     dn; dn = of_find_matching_node_and_match(dn, matches, match))
> +#define for_each_child_of_node(parent, child) \
> +	for (child = of_get_next_child(parent, NULL); child != NULL; \
> +	     child = of_get_next_child(parent, child))
> +#define for_each_available_child_of_node(parent, child) \
> +	for (child = of_get_next_available_child(parent, NULL); child != NULL; \
> +	     child = of_get_next_available_child(parent, child))
> +#define for_each_node_with_property(dn, prop_name) \
> +	for (dn = of_find_node_with_property(NULL, prop_name); dn; \
> +	     dn = of_find_node_with_property(dn, prop_name))
> +
>  #ifdef CONFIG_OF
>  
>  /* Pointer for first entry in chain of all nodes. */
> @@ -167,19 +192,10 @@ static inline const char *of_node_full_name(const struct device_node *np)
>  
>  extern struct device_node *of_find_node_by_name(struct device_node *from,
>  	const char *name);
> -#define for_each_node_by_name(dn, name) \
> -	for (dn = of_find_node_by_name(NULL, name); dn; \
> -	     dn = of_find_node_by_name(dn, name))
>  extern struct device_node *of_find_node_by_type(struct device_node *from,
>  	const char *type);
> -#define for_each_node_by_type(dn, type) \
> -	for (dn = of_find_node_by_type(NULL, type); dn; \
> -	     dn = of_find_node_by_type(dn, type))
>  extern struct device_node *of_find_compatible_node(struct device_node *from,
>  	const char *type, const char *compat);
> -#define for_each_compatible_node(dn, type, compatible) \
> -	for (dn = of_find_compatible_node(NULL, type, compatible); dn; \
> -	     dn = of_find_compatible_node(dn, type, compatible))
>  extern struct device_node *of_find_matching_node_and_match(
>  	struct device_node *from,
>  	const struct of_device_id *matches,
> @@ -190,12 +206,6 @@ static inline struct device_node *of_find_matching_node(
>  {
>  	return of_find_matching_node_and_match(from, matches, NULL);
>  }
> -#define for_each_matching_node(dn, matches) \
> -	for (dn = of_find_matching_node(NULL, matches); dn; \
> -	     dn = of_find_matching_node(dn, matches))
> -#define for_each_matching_node_and_match(dn, matches, match) \
> -	for (dn = of_find_matching_node_and_match(NULL, matches, match); \
> -	     dn; dn = of_find_matching_node_and_match(dn, matches, match))
>  extern struct device_node *of_find_node_by_path(const char *path);
>  extern struct device_node *of_find_node_by_phandle(phandle handle);
>  extern struct device_node *of_get_parent(const struct device_node *node);
> @@ -207,14 +217,6 @@ extern struct device_node *of_get_next_available_child(
>  
>  extern struct device_node *of_get_child_by_name(const struct device_node *node,
>  					const char *name);
> -#define for_each_child_of_node(parent, child) \
> -	for (child = of_get_next_child(parent, NULL); child != NULL; \
> -	     child = of_get_next_child(parent, child))
> -
> -#define for_each_available_child_of_node(parent, child) \
> -	for (child = of_get_next_available_child(parent, NULL); child != NULL; \
> -	     child = of_get_next_available_child(parent, child))
> -
>  static inline int of_get_child_count(const struct device_node *np)
>  {
>  	struct device_node *child;
> @@ -228,10 +230,6 @@ static inline int of_get_child_count(const struct device_node *np)
>  
>  extern struct device_node *of_find_node_with_property(
>  	struct device_node *from, const char *prop_name);
> -#define for_each_node_with_property(dn, prop_name) \
> -	for (dn = of_find_node_with_property(NULL, prop_name); dn; \
> -	     dn = of_find_node_with_property(dn, prop_name))
> -
>  extern struct property *of_find_property(const struct device_node *np,
>  					 const char *name,
>  					 int *lenp);
> @@ -353,13 +351,28 @@ static inline struct device_node *of_find_node_by_name(struct device_node *from,
>  	return NULL;
>  }
>  
> +static inline struct device_node *of_find_node_by_type(struct device_node *from,
> +	const char *type)
> +{
> +	return NULL;
> +}
> +
>  static inline bool of_have_populated_dt(void)
>  {
>  	return false;
>  }
>  
> -#define for_each_child_of_node(parent, child) \
> -	while (0)
> +static inline struct device_node *of_get_next_child(const struct device_node *node,
> +					     struct device_node *prev)
> +{
> +	return NULL;
> +}
> +
> +static inline struct device_node *of_get_next_available_child(
> +	const struct device_node *node, struct device_node *prev)
> +{
> +	return NULL;
> +}
>  
>  static inline struct device_node *of_get_child_by_name(
>  					const struct device_node *node,
> @@ -373,6 +386,12 @@ static inline int of_get_child_count(const struct device_node *np)
>  	return 0;
>  }
>  
> +static inline struct device_node *of_find_node_with_property(
> +	struct device_node *from, const char *prop_name)
> +{
> +	return NULL;
> +}
> +
>  static inline int of_device_is_compatible(const struct device_node *device,
>  					  const char *name)
>  {
> @@ -394,6 +413,21 @@ static inline struct device_node *of_find_compatible_node(
>  	return NULL;
>  }
>  
> +static inline struct device_node *of_find_matching_node_and_match(
> +	struct device_node *from,
> +	const struct of_device_id *matches,
> +	const struct of_device_id **match)
> +{
> +	return NULL;
> +}
> +
> +static inline struct device_node *of_find_matching_node(
> +	struct device_node *from,
> +	const struct of_device_id *matches)
> +{
> +	return NULL;
> +}
> +
>  static inline int of_property_read_u8_array(const struct device_node *np,
>  			const char *propname, u8 *out_values, size_t sz)
>  {
> 



From mturquette at linaro.org  Mon Apr  1 17:35:50 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Mon, 01 Apr 2013 14:35:50 -0700
Subject: [PATCH RFC] clk: divider: Tolerate 0 divider for one based
 dividers
In-Reply-To: <edf8905f-2bd1-4a1d-b6a2-85e921365d88@CO1EHSMHS004.ehs.local>
References: <dbceb80f-0303-4ba0-acd8-336dd85444ae@DB8EHSMHS017.ehs.local>
 <20130322171141.834.32801@quantum>
 <c9f78c47-4926-4233-8cc3-51e0a4cc9c5e@AM1EHSMHS003.ehs.local>
 <20130401182522.8177.96562@quantum>
 <edf8905f-2bd1-4a1d-b6a2-85e921365d88@CO1EHSMHS004.ehs.local>
Message-ID: <20130401213550.8177.58990@quantum>

Quoting S?ren Brinkmann (2013-04-01 11:31:32)
> Hi Mike,
> 
> On Mon, Apr 01, 2013 at 11:25:22AM -0700, Mike Turquette wrote:
> > Quoting S?ren Brinkmann (2013-03-22 11:00:15)
> > > Since some of our dividers have a reset value of 0, I see this warning
> > > during boot up. My intention here is to get rid of the warning for clocks
> > > which deem 0 a valid divider value.
> > > I thought, reusing the ONE_BASED flag might be okay, since all such
> > > dividers have this redundant 0 state and might handle it similar.
> > > Otherwise a new flag might be required.
> > > 
> > 
> > Hi Soren,
> > 
> > A flag will be necessary.  I just checked some documentation for the
> > divider outputs for OMAP's PLLs and (which use the common clk_divider
> > type) and programming zero into those dividers is not allowed.  At reset
> > the divider registers are set to 1.
> > 
> > So it is unsafe to simply reuse the ONE_BASED flag.
> > 
> > Let's keep the current behavior as the default and introduce a new flag
> > to handle the special case of a zero divider.  Would you like to take a
> > crack at it?  It might also be nice to update the WARN message with a
> > hint to take a look at your new flag in case future platforms hit the
> > same issue as you.
> Okay, sounds good. I should be able to get something ready within this
> week.
> Does anybody have suggestions for naming the new flag?
> CLK_DIVIDER_ZERO_OKAY was my original suggestionn I think.
> 

CLK_DIVIDER_ALLOW_ZERO sounds betterer to me.

Regards,
Mike

>         S?ren


From rmallon at gmail.com  Mon Apr  1 17:44:10 2013
From: rmallon at gmail.com (Ryan Mallon)
Date: Tue, 02 Apr 2013 08:44:10 +1100
Subject: [PATCH 0/3] add devicetree bindings for rtc-m48t86
In-Reply-To: <1364766971-5914-1-git-send-email-alex@digriz.org.uk>
References: <1364766971-5914-1-git-send-email-alex@digriz.org.uk>
Message-ID: <5159FFAA.5030205@gmail.com>

On 01/04/13 08:56, Alexander Clouter wrote:
> Currently there are two users of rtc-m48t86 (mach-ep93xx/ts72xx.c and
> mach-orion5x/ts78xx-setup.c) and both just use {read,write}b against
> a memory mapped region.  As I am devicetree'ing the TS-7800, this
> driver needs converting and thats what this patchset does.
> 
> The patch does the following:
>  * remove platform specific ops hooks, moving ioremap'ing and
> 	everything into the driver
>  * utilises named resources to indicate index/data ranges
>  * moves the RTC detection routine from ts78xx-setup.c into rtc-m48t86.c
>  * and, of course, enable devicetree hooks and include documentation
> 
> Awkward step, the first patch breaks both boards, the two following
> patches fix them.  Happy to re-work this if folks give me a pointer
> on how to do this in an acceptable way.

Sorry, that's no good. It breaks things like git bisect.

> 
> My vote is to break fast, fix fast, spend the time writing other code :)

The patch series will need to be reworked so that there is no
build/runtime breakage between any of the patches. I'll have a read
through and see if I can suggest something.

~Ryan


> Signed-off-by: Alexander Clouter <alex at digriz.org.uk>
> 
> Alexander Clouter (3):
>   rtc: rtc-m48t86: add devicetree bindings
>   arm: orion5x: fixup ts78xx to be able to use the rtc-m48t86 again.
>   arm: ep93xx: fixup ts72xx to be able to use the rtc-m48t86 again.
> 
>  .../devicetree/bindings/rtc/rtc-m48t86.txt         |   17 ++
>  arch/arm/mach-ep93xx/ts72xx.c                      |   29 +--
>  arch/arm/mach-orion5x/ts78xx-setup.c               |   79 ++----
>  drivers/rtc/rtc-m48t86.c                           |  254 +++++++++++++++-----
>  include/linux/m48t86.h                             |   16 --
>  5 files changed, 239 insertions(+), 156 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/rtc/rtc-m48t86.txt
>  delete mode 100644 include/linux/m48t86.h
> 



From gdavis at mvista.com  Mon Apr  1 17:47:38 2013
From: gdavis at mvista.com (George G. Davis)
Date: Mon, 1 Apr 2013 17:47:38 -0400
Subject: [PATCH 1/2] Allow constructor name selection by architecture.
In-Reply-To: <20120606101253.GM8262@n2100.arm.linux.org.uk>
References: <1338230018-31052-1-git-send-email-vincent.sanders@collabora.co.uk>
 <1338230018-31052-2-git-send-email-vincent.sanders@collabora.co.uk>
 <20120528203005.GA20560@merkur.ravnborg.org>
 <20120529090614.GD12217@n2100.arm.linux.org.uk>
 <20120606101253.GM8262@n2100.arm.linux.org.uk>
Message-ID: <87F2CC87-0FAF-49CB-AE70-423FB063A0E5@mvista.com>

On Jun 6, 2012, at 6:12 AM, Russell King - ARM Linux wrote:
> On Tue, May 29, 2012 at 10:06:14AM +0100, Russell King - ARM Linux wrote:
>> On Mon, May 28, 2012 at 10:30:05PM +0200, Sam Ravnborg wrote:
>>> On Mon, May 28, 2012 at 07:33:37PM +0100, Vincent Sanders wrote:
>>>> From: Vincent Sanders <vince at collabora.co.uk>
>>>> 
>>>> The constructor symbol name is different between platforms. Allow this
>>>> to be selected by configuration and set suitable default values.
>>>> 
>>>> Signed-off-by: Vincent Sanders <vincent.sanders at collabora.co.uk>
>>>> ---
>>>> include/asm-generic/vmlinux.lds.h |    6 +++---
>>>> init/Kconfig                      |    6 ++++++
>>>> kernel/module.c                   |    2 +-
>>>> 3 files changed, 10 insertions(+), 4 deletions(-)
>>>> 
>>>> diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
>>>> index 8aeadf6..fd34808 100644
>>>> --- a/include/asm-generic/vmlinux.lds.h
>>>> +++ b/include/asm-generic/vmlinux.lds.h
>>>> @@ -471,9 +471,9 @@
>>>> 	}
>>>> 
>>>> #ifdef CONFIG_CONSTRUCTORS
>>>> -#define KERNEL_CTORS()	. = ALIGN(8);			   \
>>>> -			VMLINUX_SYMBOL(__ctors_start) = .; \
>>>> -			*(.ctors)			   \
>>>> +#define KERNEL_CTORS()	. = ALIGN(8);					\
>>>> +			VMLINUX_SYMBOL(__ctors_start) = .;		\
>>>> +			*(CONFIG_CONSTRUCTORS_NAME)			\
>>>> 			VMLINUX_SYMBOL(__ctors_end) = .;
>>> 
>>> What is wrong with adding both "standard" names for ctors uncnditionally?
>>> Like this:
>>>> 			*(.ctors)			   \
>>>> +			*(.init_array)			   \
>> 
>> That doesn't get rid of CONFIG_CONSTRUCTORS_NAME, because it's needed
>> in the module code.  Do you have a suggestion to solve that as well?
> 
> Ping.

Pinging this back to life.  I'd like to see GCOV for ARM eABI finally make it upstream.
So, any objections to this?  Should it be resubmitted?

TIA!

--
Regards,
George

From keescook at chromium.org  Mon Apr  1 17:53:09 2013
From: keescook at chromium.org (Kees Cook)
Date: Mon, 1 Apr 2013 14:53:09 -0700
Subject: [PATCH V2 1/3] seccomp: add generic code for jitted seccomp
 filters.
In-Reply-To: <1363618233-6375-2-git-send-email-nschichan@freebox.fr>
References: <1363618233-6375-1-git-send-email-nschichan@freebox.fr>
 <1363618233-6375-2-git-send-email-nschichan@freebox.fr>
Message-ID: <CAGXu5j+jpXrcLDyAV+p81pjapaQeKQTMz4+JXjKj03DV-yoC=w@mail.gmail.com>

On Mon, Mar 18, 2013 at 7:50 AM, Nicolas Schichan <nschichan at freebox.fr> wrote:
> Architecture must select HAVE_SECCOMP_FILTER_JIT and implement
> seccomp_jit_compile() and seccomp_jit_free() if they intend to support
> jitted seccomp filters.
>
> struct seccomp_filter has been moved to <linux/seccomp.h> to make its
> content available to the jit compilation code.
>
> In a way similar to the net BPF, the jit compilation code is expected
> to updates struct seccomp_filter.bpf_func pointer to the generated
> code.
>
> Signed-off-by: Nicolas Schichan <nschichan at freebox.fr>

Acked-by: Kees Cook <keescook at chromium.org>

I'd love to see this for x86 too. I suspect it'd be a small change
after this series lands.

Thanks,

-Kees

-- 
Kees Cook
Chrome OS Security


From achew at nvidia.com  Mon Apr  1 17:53:21 2013
From: achew at nvidia.com (Andrew Chew)
Date: Mon, 1 Apr 2013 14:53:21 -0700
Subject: [PATCH V6 2/9] ARM: S3C24XX: Provide regulator to pwm-backlight
In-Reply-To: <1364853208-32503-1-git-send-email-achew@nvidia.com>
References: <1364853208-32503-1-git-send-email-achew@nvidia.com>
Message-ID: <1364853208-32503-3-git-send-email-achew@nvidia.com>

The pwm-backlight driver now takes a mandatory regulator that is gotten
during driver probe.  Initialize a dummy regulator to satisfy this
requirement.

Signed-off-by: Andrew Chew <achew at nvidia.com>
Acked-by: Alexandre Courbot <acourbot at nvidia.com>
---
 arch/arm/mach-s3c24xx/mach-h1940.c  | 8 ++++++++
 arch/arm/mach-s3c24xx/mach-rx1950.c | 9 +++++++++
 2 files changed, 17 insertions(+)

diff --git a/arch/arm/mach-s3c24xx/mach-h1940.c b/arch/arm/mach-s3c24xx/mach-h1940.c
index 8dd6601..008be7e 100644
--- a/arch/arm/mach-s3c24xx/mach-h1940.c
+++ b/arch/arm/mach-s3c24xx/mach-h1940.c
@@ -24,6 +24,8 @@
 #include <linux/gpio.h>
 #include <linux/input.h>
 #include <linux/gpio_keys.h>
+#include <linux/regulator/machine.h>
+#include <linux/regulator/fixed.h>
 #include <linux/pwm_backlight.h>
 #include <linux/i2c.h>
 #include <linux/leds.h>
@@ -497,6 +499,9 @@ static void h1940_backlight_exit(struct device *dev)
 	gpio_set_value(H1940_LATCH_MAX1698_nSHUTDOWN, 0);
 }
 
+/* Dummy regulator for pwm-backlight driver */
+static struct regulator_consumer_supply backlight_supply =
+	REGULATOR_SUPPLY("power", "pwm-backlight");
 
 static struct platform_pwm_backlight_data backlight_data = {
 	.pwm_id         = 0,
@@ -720,6 +725,9 @@ static void __init h1940_init(void)
 	gpio_request(H1940_LATCH_SD_POWER, "SD power");
 	gpio_direction_output(H1940_LATCH_SD_POWER, 0);
 
+	regulator_register_always_on(-1, "backlight-power",
+				     &backlight_supply, 1, 0);
+
 	platform_add_devices(h1940_devices, ARRAY_SIZE(h1940_devices));
 
 	gpio_request(S3C2410_GPA(1), "Red LED blink");
diff --git a/arch/arm/mach-s3c24xx/mach-rx1950.c b/arch/arm/mach-s3c24xx/mach-rx1950.c
index e4d67a3..f6978b6 100644
--- a/arch/arm/mach-s3c24xx/mach-rx1950.c
+++ b/arch/arm/mach-s3c24xx/mach-rx1950.c
@@ -25,6 +25,8 @@
 #include <linux/gpio_keys.h>
 #include <linux/device.h>
 #include <linux/pda_power.h>
+#include <linux/regulator/machine.h>
+#include <linux/regulator/fixed.h>
 #include <linux/pwm_backlight.h>
 #include <linux/pwm.h>
 #include <linux/s3c_adc_battery.h>
@@ -518,6 +520,10 @@ static int rx1950_backlight_notify(struct device *dev, int brightness)
 	return brightness;
 }
 
+/* Dummy regulator for pwm-backlight driver */
+static struct regulator_consumer_supply backlight_supply =
+	REGULATOR_SUPPLY("power", "pwm-backlight");
+
 static struct platform_pwm_backlight_data rx1950_backlight_data = {
 	.pwm_id = 0,
 	.max_brightness = 24,
@@ -795,6 +801,9 @@ static void __init rx1950_init_machine(void)
 	gpio_direction_output(S3C2410_GPA(4), 0);
 	gpio_direction_output(S3C2410_GPJ(6), 0);
 
+	regulator_register_always_on(-1, "backlight-power",
+				     &backlight_supply, 1, 0);
+
 	platform_add_devices(rx1950_devices, ARRAY_SIZE(rx1950_devices));
 
 	i2c_register_board_info(0, rx1950_i2c_devices,
-- 
1.8.1.5



From achew at nvidia.com  Mon Apr  1 17:53:27 2013
From: achew at nvidia.com (Andrew Chew)
Date: Mon, 1 Apr 2013 14:53:27 -0700
Subject: [PATCH V6 8/9] ARM: tegra: Provide regulator to pwm-backlight
In-Reply-To: <1364853208-32503-1-git-send-email-achew@nvidia.com>
References: <1364853208-32503-1-git-send-email-achew@nvidia.com>
Message-ID: <1364853208-32503-9-git-send-email-achew@nvidia.com>

The pwm-backlight driver now takes a mandatory regulator that is gotten
during driver probe.  Initialize a dummy regulator to satisfy this
requirement.

Signed-off-by: Andrew Chew <achew at nvidia.com>
Acked-by: Alexandre Courbot <acourbot at nvidia.com>
Acked-by: Stephen Warren <swarren at nvidia.com>
---
 arch/arm/boot/dts/tegra20-medcom-wide.dts |  1 +
 arch/arm/boot/dts/tegra20-tamonten.dtsi   | 10 ++++++++++
 2 files changed, 11 insertions(+)

diff --git a/arch/arm/boot/dts/tegra20-medcom-wide.dts b/arch/arm/boot/dts/tegra20-medcom-wide.dts
index a2d6d65..90d665e 100644
--- a/arch/arm/boot/dts/tegra20-medcom-wide.dts
+++ b/arch/arm/boot/dts/tegra20-medcom-wide.dts
@@ -32,6 +32,7 @@
 
 		brightness-levels = <0 4 8 16 32 64 128 255>;
 		default-brightness-level = <6>;
+		power-supply = <&backlight_power_reg>;
 	};
 
 	sound {
diff --git a/arch/arm/boot/dts/tegra20-tamonten.dtsi b/arch/arm/boot/dts/tegra20-tamonten.dtsi
index 6e9d91f..1ea3e42 100644
--- a/arch/arm/boot/dts/tegra20-tamonten.dtsi
+++ b/arch/arm/boot/dts/tegra20-tamonten.dtsi
@@ -485,5 +485,15 @@
 			regulator-max-microvolt = <5000000>;
 			regulator-always-on;
 		};
+
+		backlight_power_reg: regulator at 1 {
+			compatible = "regulator-fixed";
+			reg = <1>;
+			regulator-name = "lcd_bl_en";
+			regulator-min-microvolt = <3300000>;
+			regulator-max-microvolt = <3300000>;
+			gpio = <&gpio 13 0>; /* gpio PB5 */
+			enable-active-high;
+		};
 	};
 };
-- 
1.8.1.5



From achew at nvidia.com  Mon Apr  1 17:53:23 2013
From: achew at nvidia.com (Andrew Chew)
Date: Mon, 1 Apr 2013 14:53:23 -0700
Subject: [PATCH V6 4/9] ARM: EXYNOS: Provide regulator to pwm-backlight
In-Reply-To: <1364853208-32503-1-git-send-email-achew@nvidia.com>
References: <1364853208-32503-1-git-send-email-achew@nvidia.com>
Message-ID: <1364853208-32503-5-git-send-email-achew@nvidia.com>

The pwm-backlight driver now takes a mandatory regulator that is gotten
during driver probe.  Initialize a dummy regulator to satisfy this
requirement.

Signed-off-by: Andrew Chew <achew at nvidia.com>
Acked-by: Alexandre Courbot <acourbot at nvidia.com>
---
 arch/arm/mach-exynos/mach-nuri.c      | 7 +++++++
 arch/arm/plat-samsung/dev-backlight.c | 9 +++++++++
 2 files changed, 16 insertions(+)

diff --git a/arch/arm/mach-exynos/mach-nuri.c b/arch/arm/mach-exynos/mach-nuri.c
index 1ea7973..0223863 100644
--- a/arch/arm/mach-exynos/mach-nuri.c
+++ b/arch/arm/mach-exynos/mach-nuri.c
@@ -294,6 +294,10 @@ static void nuri_bl_exit(struct device *dev)
 	gpio_free(EXYNOS4_GPE2(3));
 }
 
+/* Dummy regulator for pwm-backlight driver */
+static struct regulator_consumer_supply backlight_supply =
+	REGULATOR_SUPPLY("power", "pwm-backlight");
+
 /* nuri pwm backlight */
 static struct platform_pwm_backlight_data nuri_backlight_data = {
 	.pwm_id			= 0,
@@ -1368,6 +1372,9 @@ static void __init nuri_machine_init(void)
 	nuri_ehci_init();
 	s3c_hsotg_set_platdata(&nuri_hsotg_pdata);
 
+	regulator_register_always_on(-1, "backlight-power",
+				     &backlight_supply, 1, 0);
+
 	/* Last */
 	platform_add_devices(nuri_devices, ARRAY_SIZE(nuri_devices));
 }
diff --git a/arch/arm/plat-samsung/dev-backlight.c b/arch/arm/plat-samsung/dev-backlight.c
index 5f197dc..23ce16b 100644
--- a/arch/arm/plat-samsung/dev-backlight.c
+++ b/arch/arm/plat-samsung/dev-backlight.c
@@ -14,12 +14,18 @@
 #include <linux/platform_device.h>
 #include <linux/slab.h>
 #include <linux/io.h>
+#include <linux/regulator/machine.h>
+#include <linux/regulator/fixed.h>
 #include <linux/pwm_backlight.h>
 
 #include <plat/devs.h>
 #include <plat/gpio-cfg.h>
 #include <plat/backlight.h>
 
+/* Dummy regulator for pwm-backlight driver */
+static struct regulator_consumer_supply backlight_supply =
+	REGULATOR_SUPPLY("power", "pwm-backlight");
+
 static int samsung_bl_init(struct device *dev)
 {
 	int ret = 0;
@@ -37,6 +43,9 @@ static int samsung_bl_init(struct device *dev)
 	/* Configure GPIO pin with specific GPIO function for PWM timer */
 	s3c_gpio_cfgpin(bl_gpio_info->no, bl_gpio_info->func);
 
+	regulator_register_always_on(-1, "backlight-power",
+				     &backlight_supply, 1, 0);
+
 	return 0;
 }
 
-- 
1.8.1.5



From achew at nvidia.com  Mon Apr  1 17:53:28 2013
From: achew at nvidia.com (Andrew Chew)
Date: Mon, 1 Apr 2013 14:53:28 -0700
Subject: [PATCH V6 9/9] pwm_bl: Add mandatory backlight power regulator
In-Reply-To: <1364853208-32503-1-git-send-email-achew@nvidia.com>
References: <1364853208-32503-1-git-send-email-achew@nvidia.com>
Message-ID: <1364853208-32503-10-git-send-email-achew@nvidia.com>

Many backlights need to be explicitly powered.  Typically, this is done
with a GPIO.  For flexibility, we generalize the power mechanism to a
regulator.

If a power regulator is not needed, then a dummy fixed regulator can be
given to the backlight driver.  If a GPIO is used to enable the backlight,
then a fixed regulator can be instantiated to control the GPIO.

The backlight power regulator can be specified in the device tree node
for the backlight, or can be done with legacy board setup code in the
usual way.

Signed-off-by: Andrew Chew <achew at nvidia.com>
Reviewed-by: Alexandre Courbot <acourbot at nvidia.com>
Tested-by: Peter Ujfalusi <peter.ujfalusi at ti.com>
---
 .../bindings/video/backlight/pwm-backlight.txt     | 14 +++++
 drivers/video/backlight/pwm_bl.c                   | 59 ++++++++++++++++++----
 2 files changed, 63 insertions(+), 10 deletions(-)

diff --git a/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt b/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt
index 1e4fc72..efbd799 100644
--- a/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt
+++ b/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt
@@ -10,6 +10,11 @@ Required properties:
       last value in the array represents a 100% duty cycle (brightest).
   - default-brightness-level: the default brightness level (index into the
       array defined by the "brightness-levels" property)
+  - power-supply: A phandle to the regulator device tree node. This
+      regulator will be turned on and off as the PWM is enabled and disabled.
+      Many backlights are enabled via a GPIO. In this case, we instantiate
+      a fixed regulator and give that to power-supply. If a regulator
+      is not needed, then provide a dummy fixed regulator.
 
 Optional properties:
   - pwm-names: a list of names for the PWM devices specified in the
@@ -19,10 +24,19 @@ Optional properties:
 
 Example:
 
+	bl_en: fixed-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "bl-en-supply";
+		regulator-boot-on;
+		gpio = <&some_gpio>;
+		enable-active-high;
+	};
+
 	backlight {
 		compatible = "pwm-backlight";
 		pwms = <&pwm 0 5000000>;
 
 		brightness-levels = <0 4 8 16 32 64 128 255>;
 		default-brightness-level = <6>;
+		power-supply = <&bl_en>;
 	};
diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index 1fea627..ddd66d0 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -20,10 +20,13 @@
 #include <linux/pwm.h>
 #include <linux/pwm_backlight.h>
 #include <linux/slab.h>
+#include <linux/regulator/consumer.h>
 
 struct pwm_bl_data {
 	struct pwm_device	*pwm;
 	struct device		*dev;
+	bool			enabled;
+	struct regulator	*power_supply;
 	unsigned int		period;
 	unsigned int		lth_brightness;
 	unsigned int		*levels;
@@ -35,6 +38,42 @@ struct pwm_bl_data {
 	void			(*exit)(struct device *);
 };
 
+static void pwm_backlight_enable(struct backlight_device *bl)
+{
+	struct pwm_bl_data *pb = dev_get_drvdata(&bl->dev);
+	int ret;
+
+	/* Bail if we are already enabled. */
+	if (pb->enabled)
+		return;
+
+	pwm_enable(pb->pwm);
+
+	ret = regulator_enable(pb->power_supply);
+	if (ret)
+		dev_warn(&bl->dev, "Failed to enable regulator: %d", ret);
+
+	pb->enabled = true;
+}
+
+static void pwm_backlight_disable(struct backlight_device *bl)
+{
+	struct pwm_bl_data *pb = dev_get_drvdata(&bl->dev);
+	int ret;
+
+	/* Bail if we are already disabled. */
+	if (!pb->enabled)
+		return;
+
+	ret = regulator_disable(pb->power_supply);
+	if (ret)
+		dev_warn(&bl->dev, "Failed to disable regulator: %d", ret);
+
+	pwm_disable(pb->pwm);
+
+	pb->enabled = false;
+}
+
 static int pwm_backlight_update_status(struct backlight_device *bl)
 {
 	struct pwm_bl_data *pb = bl_get_data(bl);
@@ -51,7 +90,7 @@ static int pwm_backlight_update_status(struct backlight_device *bl)
 
 	if (brightness == 0) {
 		pwm_config(pb->pwm, 0, pb->period);
-		pwm_disable(pb->pwm);
+		pwm_backlight_disable(bl);
 	} else {
 		int duty_cycle;
 
@@ -65,7 +104,7 @@ static int pwm_backlight_update_status(struct backlight_device *bl)
 		duty_cycle = pb->lth_brightness +
 		     (duty_cycle * (pb->period - pb->lth_brightness) / max);
 		pwm_config(pb->pwm, duty_cycle, pb->period);
-		pwm_enable(pb->pwm);
+		pwm_backlight_enable(bl);
 	}
 
 	if (pb->notify_after)
@@ -138,12 +177,6 @@ static int pwm_backlight_parse_dt(struct device *dev,
 		data->max_brightness--;
 	}
 
-	/*
-	 * TODO: Most users of this driver use a number of GPIOs to control
-	 *       backlight power. Support for specifying these needs to be
-	 *       added.
-	 */
-
 	return 0;
 }
 
@@ -206,6 +239,12 @@ static int pwm_backlight_probe(struct platform_device *pdev)
 	pb->exit = data->exit;
 	pb->dev = &pdev->dev;
 
+	pb->power_supply = devm_regulator_get(&pdev->dev, "power");
+	if (IS_ERR(pb->power_supply)) {
+		ret = PTR_ERR(pb->power_supply);
+		goto err_alloc;
+	}
+
 	pb->pwm = devm_pwm_get(&pdev->dev, NULL);
 	if (IS_ERR(pb->pwm)) {
 		dev_err(&pdev->dev, "unable to request PWM, trying legacy API\n");
@@ -268,7 +307,7 @@ static int pwm_backlight_remove(struct platform_device *pdev)
 
 	backlight_device_unregister(bl);
 	pwm_config(pb->pwm, 0, pb->period);
-	pwm_disable(pb->pwm);
+	pwm_backlight_disable(bl);
 	if (pb->exit)
 		pb->exit(&pdev->dev);
 	return 0;
@@ -283,7 +322,7 @@ static int pwm_backlight_suspend(struct device *dev)
 	if (pb->notify)
 		pb->notify(pb->dev, 0);
 	pwm_config(pb->pwm, 0, pb->period);
-	pwm_disable(pb->pwm);
+	pwm_backlight_disable(bl);
 	if (pb->notify_after)
 		pb->notify_after(pb->dev, 0);
 	return 0;
-- 
1.8.1.5



From achew at nvidia.com  Mon Apr  1 17:53:20 2013
From: achew at nvidia.com (Andrew Chew)
Date: Mon, 1 Apr 2013 14:53:20 -0700
Subject: [PATCH V6 1/9] ARM: OMAP: board-4430sdp: Provide regulator to
 pwm-backlight
In-Reply-To: <1364853208-32503-1-git-send-email-achew@nvidia.com>
References: <1364853208-32503-1-git-send-email-achew@nvidia.com>
Message-ID: <1364853208-32503-2-git-send-email-achew@nvidia.com>

The pwm-backlight driver now takes a mandatory regulator that is gotten
during driver probe.  Initialize a dummy regulator to satisfy this
requirement.

Signed-off-by: Andrew Chew <achew at nvidia.com>
Tested-by: Peter Ujfalusi <peter.ujfalusi at ti.com>
Acked-by: Alexandre Courbot <acourbot at nvidia.com>
---
 arch/arm/mach-omap2/board-4430sdp.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c
index 35f3ad0..9b03bbd 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -291,6 +291,10 @@ static struct platform_device sdp4430_leds_pwm = {
 	},
 };
 
+/* Dummy regulator for pwm-backlight driver */
+static struct regulator_consumer_supply backlight_supply =
+	REGULATOR_SUPPLY("power", "pwm-backlight");
+
 static struct platform_pwm_backlight_data sdp4430_backlight_data = {
 	.max_brightness = 127,
 	.dft_brightness = 127,
@@ -718,6 +722,8 @@ static void __init omap_4430sdp_init(void)
 
 	omap4_i2c_init();
 	omap_sfh7741prox_init();
+	regulator_register_always_on(-1, "backlight-power",
+				     &backlight_supply, 1, 0);
 	platform_add_devices(sdp4430_devices, ARRAY_SIZE(sdp4430_devices));
 	omap_serial_init();
 	omap_sdrc_init(NULL, NULL);
-- 
1.8.1.5



From achew at nvidia.com  Mon Apr  1 17:53:26 2013
From: achew at nvidia.com (Andrew Chew)
Date: Mon, 1 Apr 2013 14:53:26 -0700
Subject: [PATCH V6 7/9] ARM: vt8500: Provide regulator to pwm-backlight
In-Reply-To: <1364853208-32503-1-git-send-email-achew@nvidia.com>
References: <1364853208-32503-1-git-send-email-achew@nvidia.com>
Message-ID: <1364853208-32503-8-git-send-email-achew@nvidia.com>

The pwm-backlight driver now takes a mandatory regulator that is gotten
during driver probe.  Initialize a dummy regulator to satisfy this
requirement.

Signed-off-by: Andrew Chew <achew at nvidia.com>
Acked-by: Alexandre Courbot <acourbot at nvidia.com>
Acked-by: Tony Prisk <linux at prisktech.co.nz>
---
 arch/arm/boot/dts/wm8850-w70v2.dts | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/boot/dts/wm8850-w70v2.dts b/arch/arm/boot/dts/wm8850-w70v2.dts
index fcc660c..25c96d0 100644
--- a/arch/arm/boot/dts/wm8850-w70v2.dts
+++ b/arch/arm/boot/dts/wm8850-w70v2.dts
@@ -37,11 +37,20 @@
 		};
 	};
 
+	backlight_power: fixed-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "backlight-power";
+		enable-active-high;
+		regulator-boot-on;
+		gpio = <&gpio 0 7 0>;
+	};
+
 	backlight {
 		compatible = "pwm-backlight";
 		pwms = <&pwm 0 50000 1>;	/* duty inverted */
 
 		brightness-levels = <0 40 60 80 100 130 190 255>;
 		default-brightness-level = <5>;
+		power-supply = <&backlight_power>;
 	};
 };
-- 
1.8.1.5



From achew at nvidia.com  Mon Apr  1 17:53:24 2013
From: achew at nvidia.com (Andrew Chew)
Date: Mon, 1 Apr 2013 14:53:24 -0700
Subject: [PATCH V6 5/9] unicore32: Provide regulator to pwm-backlight
In-Reply-To: <1364853208-32503-1-git-send-email-achew@nvidia.com>
References: <1364853208-32503-1-git-send-email-achew@nvidia.com>
Message-ID: <1364853208-32503-6-git-send-email-achew@nvidia.com>

The pwm-backlight driver now takes a mandatory regulator that is gotten
during driver probe.  Initialize a dummy regulator to satisfy this
requirement.

Signed-off-by: Andrew Chew <achew at nvidia.com>
Acked-by: Alexandre Courbot <acourbot at nvidia.com>
---
 arch/unicore32/kernel/puv3-nb0916.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/arch/unicore32/kernel/puv3-nb0916.c b/arch/unicore32/kernel/puv3-nb0916.c
index 181108b..839b536 100644
--- a/arch/unicore32/kernel/puv3-nb0916.c
+++ b/arch/unicore32/kernel/puv3-nb0916.c
@@ -19,6 +19,8 @@
 #include <linux/reboot.h>
 #include <linux/interrupt.h>
 #include <linux/i2c.h>
+#include <linux/regulator/machine.h>
+#include <linux/regulator/fixed.h>
 #include <linux/pwm_backlight.h>
 #include <linux/gpio.h>
 #include <linux/gpio_keys.h>
@@ -49,6 +51,10 @@ static struct resource puv3_i2c_resources[] = {
 	}
 };
 
+/* Dummy regulator for pwm-backlight driver */
+static struct regulator_consumer_supply backlight_supply =
+	REGULATOR_SUPPLY("power", "pwm-backlight");
+
 static struct platform_pwm_backlight_data nb0916_backlight_data = {
 	.pwm_id		= 0,
 	.max_brightness	= 100,
@@ -111,6 +117,9 @@ int __init mach_nb0916_init(void)
 	platform_device_register_simple("PKUnity-v3-I2C", -1,
 			puv3_i2c_resources, ARRAY_SIZE(puv3_i2c_resources));
 
+	regulator_register_always_on(-1, "backlight-power",
+				     &backlight_supply, 1, 0);
+
 	platform_device_register_data(&platform_bus, "pwm-backlight", -1,
 			&nb0916_backlight_data, sizeof(nb0916_backlight_data));
 
-- 
1.8.1.5



From achew at nvidia.com  Mon Apr  1 17:53:25 2013
From: achew at nvidia.com (Andrew Chew)
Date: Mon, 1 Apr 2013 14:53:25 -0700
Subject: [PATCH V6 6/9] ARM: mxs: Provide regulator to pwm-backlight
In-Reply-To: <1364853208-32503-1-git-send-email-achew@nvidia.com>
References: <1364853208-32503-1-git-send-email-achew@nvidia.com>
Message-ID: <1364853208-32503-7-git-send-email-achew@nvidia.com>

The pwm-backlight driver now takes a mandatory regulator that is gotten
during driver probe.  Initialize a dummy regulator to satisfy this
requirement.

Signed-off-by: Andrew Chew <achew at nvidia.com>
Acked-by: Alexandre Courbot <acourbot at nvidia.com>
Acked-by: Shawn Guo <shawn.guo at linaro.org>
---
 arch/arm/boot/dts/imx23-evk.dts      |  6 ++++++
 arch/arm/boot/dts/imx28-apf28dev.dts |  6 ++++++
 arch/arm/boot/dts/imx28-cfa10049.dts |  6 ++++++
 arch/arm/boot/dts/imx28-evk.dts      |  6 ++++++
 arch/arm/boot/dts/imx28-tx28.dts     | 11 +++++++++++
 5 files changed, 35 insertions(+)

diff --git a/arch/arm/boot/dts/imx23-evk.dts b/arch/arm/boot/dts/imx23-evk.dts
index 035c13f..ce5048e 100644
--- a/arch/arm/boot/dts/imx23-evk.dts
+++ b/arch/arm/boot/dts/imx23-evk.dts
@@ -95,6 +95,11 @@
 			regulator-max-microvolt = <3300000>;
 			gpio = <&gpio1 29 0>;
 		};
+
+		reg_backlight_power: fixed-regulator {
+			compatible = "regulator-fixed";
+			regulator-name = "backlight-power";
+	        };
 	};
 
 	backlight {
@@ -102,5 +107,6 @@
 		pwms = <&pwm 2 5000000>;
 		brightness-levels = <0 4 8 16 32 64 128 255>;
 		default-brightness-level = <6>;
+		power-supply = <&reg_backlight_power>;
 	};
 };
diff --git a/arch/arm/boot/dts/imx28-apf28dev.dts b/arch/arm/boot/dts/imx28-apf28dev.dts
index 6d8865b..e354dc5 100644
--- a/arch/arm/boot/dts/imx28-apf28dev.dts
+++ b/arch/arm/boot/dts/imx28-apf28dev.dts
@@ -132,6 +132,11 @@
 			regulator-max-microvolt = <5000000>;
 			gpio = <&gpio1 23 1>;
 		};
+
+		reg_backlight_power: fixed-regulator {
+			compatible = "regulator-fixed";
+			regulator-name = "backlight-power";
+		};
 	};
 
 	leds {
@@ -150,5 +155,6 @@
 		pwms = <&pwm 3 191000>;
 		brightness-levels = <0 4 8 16 32 64 128 255>;
 		default-brightness-level = <6>;
+		power-supply = <&reg_backlight_power>;
 	};
 };
diff --git a/arch/arm/boot/dts/imx28-cfa10049.dts b/arch/arm/boot/dts/imx28-cfa10049.dts
index a0d3e9f..a6eddd6 100644
--- a/arch/arm/boot/dts/imx28-cfa10049.dts
+++ b/arch/arm/boot/dts/imx28-cfa10049.dts
@@ -205,6 +205,11 @@
 			regulator-max-microvolt = <5000000>;
 			gpio = <&gpio0 7 1>;
 		};
+
+		reg_backlight_power: fixed-regulator {
+			compatible = "regulator-fixed";
+			regulator-name = "backlight-power";
+		};
 	};
 
 	ahb at 80080000 {
@@ -304,5 +309,6 @@
 		pwms = <&pwm 3 5000000>;
 		brightness-levels = <0 4 8 16 32 64 128 255>;
 		default-brightness-level = <6>;
+		power-supply = <&reg_backlight_power>;
 	};
 };
diff --git a/arch/arm/boot/dts/imx28-evk.dts b/arch/arm/boot/dts/imx28-evk.dts
index 2da316e..7ba7216 100644
--- a/arch/arm/boot/dts/imx28-evk.dts
+++ b/arch/arm/boot/dts/imx28-evk.dts
@@ -285,6 +285,11 @@
 			gpio = <&gpio3 8 0>;
 			enable-active-high;
 		};
+
+		reg_backlight_power: fixed-regulator {
+			compatible = "regulator-fixed";
+			regulator-name = "backlight-power";
+		};
 	};
 
 	sound {
@@ -312,5 +317,6 @@
 		pwms = <&pwm 2 5000000>;
 		brightness-levels = <0 4 8 16 32 64 128 255>;
 		default-brightness-level = <6>;
+		power-supply = <&reg_backlight_power>;
 	};
 };
diff --git a/arch/arm/boot/dts/imx28-tx28.dts b/arch/arm/boot/dts/imx28-tx28.dts
index 37be532..7fa5a44 100644
--- a/arch/arm/boot/dts/imx28-tx28.dts
+++ b/arch/arm/boot/dts/imx28-tx28.dts
@@ -97,6 +97,16 @@
 		};
 	};
 
+	regulators {
+		compatible = "simple-bus";
+
+		reg_backlight_power: fixed-regulator {
+			compatible = "regulator-fixed";
+			regulator-name = "backlight-power";
+		};
+	};
+
+
 	leds {
 		compatible = "gpio-leds";
 
@@ -112,5 +122,6 @@
 		pwms = <&pwm 0 5000000>;
 		brightness-levels = <0 4 8 16 32 64 128 255>;
 		default-brightness-level = <6>;
+		power-supply = <&reg_backlight_power>;
 	};
 };
-- 
1.8.1.5



From achew at nvidia.com  Mon Apr  1 17:53:19 2013
From: achew at nvidia.com (Andrew Chew)
Date: Mon, 1 Apr 2013 14:53:19 -0700
Subject: [PATCH V6 0/9] Add mandatory regulator for all users of pwm-backlight.
Message-ID: <1364853208-32503-1-git-send-email-achew@nvidia.com>

Many backlights are enabled via GPIO.  We can generalize the GPIO to a
fixed regulator.

The power regulator needs to be mandatory because there was no good way
to determine the difference between opting out of the regulator, and probe
deferral.

This series of patches is intended to add a dummy regulator (or a GPIO
regulator) for all users of the pwm-backlight.

The last patch in the series will always be the pwm-backlight change to add
this mandatory regulator.  Patches following up to that patch add the
mandatory regulator on a per mach family basis.  Once all users of
pwm-backlight have been patched, this series can be applied in order to
maintain bisectability.

All I did in every case was to provide a dummy fixed regulator to
pwm-backlight.  If your platform actually uses a regulator (or a GPIO)
to power the backlight, please either let me know so that I can make
the modifications and give you something back to test.  Or (better yet),
provide me with a tested, alternate patch that I can fold into this patch
series.

I made sure that where there was a defconfig for an affected board, that it
builds.  I did not test-build the unicore patch.

V6:
Minor formatting and stylistic tweaks to pwm-backlight bindings document.

mach-tegra: Fixed missing reg property, and fleshed out backlight_power_reg
            with some real information.

V5:
Changed the name of the supply from "enable" to "power".  Renamed corresponding
regulator dt nodes and regulators in board setup files.  Backlight regulator
nodes renamed to something less generic.

mach-mxs: Moved backlight power regulator into top-level regulators node.
mach-vt8500: Made the backlight power regulator controlled via <&gpio 0 7 0>.
mach-tegra: Moved the backlight power regulator to tegra20-tamonten.dtsi.

V3 and earlier versions of this series only had the OMAP patch, which I
used for ironing out some early, obvious stuff.  V4 and later is the complete
patch set.

Andrew Chew (9):
  ARM: OMAP: board-4430sdp: Provide regulator to pwm-backlight
  ARM: S3C24XX: Provide regulator to pwm-backlight
  ARM: pxa: Provide regulator to pwm-backlight
  ARM: EXYNOS: Provide regulator to pwm-backlight
  unicore32: Provide regulator to pwm-backlight
  ARM: mxs: Provide regulator to pwm-backlight
  ARM: vt8500: Provide regulator to pwm-backlight
  ARM: tegra: Provide regulator to pwm-backlight
  pwm_bl: Add mandatory backlight power regulator

 .../bindings/video/backlight/pwm-backlight.txt     | 14 +++++
 arch/arm/boot/dts/imx23-evk.dts                    |  6 +++
 arch/arm/boot/dts/imx28-apf28dev.dts               |  6 +++
 arch/arm/boot/dts/imx28-cfa10049.dts               |  6 +++
 arch/arm/boot/dts/imx28-evk.dts                    |  6 +++
 arch/arm/boot/dts/imx28-tx28.dts                   | 11 ++++
 arch/arm/boot/dts/tegra20-medcom-wide.dts          |  1 +
 arch/arm/boot/dts/tegra20-tamonten.dtsi            | 10 ++++
 arch/arm/boot/dts/wm8850-w70v2.dts                 |  9 ++++
 arch/arm/mach-exynos/mach-nuri.c                   |  7 +++
 arch/arm/mach-omap2/board-4430sdp.c                |  6 +++
 arch/arm/mach-pxa/cm-x300.c                        |  7 +++
 arch/arm/mach-pxa/colibri-pxa270-income.c          |  8 +++
 arch/arm/mach-pxa/ezx.c                            |  9 ++++
 arch/arm/mach-pxa/hx4700.c                         |  8 +++
 arch/arm/mach-pxa/lpd270.c                         |  9 ++++
 arch/arm/mach-pxa/magician.c                       |  8 +++
 arch/arm/mach-pxa/mainstone.c                      | 13 ++++-
 arch/arm/mach-pxa/mioa701.c                        |  8 +++
 arch/arm/mach-pxa/palm27x.c                        |  8 +++
 arch/arm/mach-pxa/palmtc.c                         |  8 +++
 arch/arm/mach-pxa/palmte2.c                        |  9 ++++
 arch/arm/mach-pxa/pcm990-baseboard.c               |  8 +++
 arch/arm/mach-pxa/raumfeld.c                       |  6 +++
 arch/arm/mach-pxa/tavorevb.c                       | 11 ++++
 arch/arm/mach-pxa/viper.c                          |  8 +++
 arch/arm/mach-pxa/z2.c                             | 10 ++++
 arch/arm/mach-pxa/zylonite.c                       |  7 +++
 arch/arm/mach-s3c24xx/mach-h1940.c                 |  8 +++
 arch/arm/mach-s3c24xx/mach-rx1950.c                |  9 ++++
 arch/arm/plat-samsung/dev-backlight.c              |  9 ++++
 arch/unicore32/kernel/puv3-nb0916.c                |  9 ++++
 drivers/video/backlight/pwm_bl.c                   | 59 ++++++++++++++++++----
 33 files changed, 310 insertions(+), 11 deletions(-)

-- 
1.8.1.5



From achew at nvidia.com  Mon Apr  1 17:53:22 2013
From: achew at nvidia.com (Andrew Chew)
Date: Mon, 1 Apr 2013 14:53:22 -0700
Subject: [PATCH V6 3/9] ARM: pxa: Provide regulator to pwm-backlight
In-Reply-To: <1364853208-32503-1-git-send-email-achew@nvidia.com>
References: <1364853208-32503-1-git-send-email-achew@nvidia.com>
Message-ID: <1364853208-32503-4-git-send-email-achew@nvidia.com>

The pwm-backlight driver now takes a mandatory regulator that is gotten
during driver probe.  Initialize a dummy regulator to satisfy this
requirement.

Signed-off-by: Andrew Chew <achew at nvidia.com>
Acked-by: Alexandre Courbot <acourbot at nvidia.com>
Reviewed-by: Marek Vasut <marex at denx.de>
---
 arch/arm/mach-pxa/cm-x300.c               |  7 +++++++
 arch/arm/mach-pxa/colibri-pxa270-income.c |  8 ++++++++
 arch/arm/mach-pxa/ezx.c                   |  9 +++++++++
 arch/arm/mach-pxa/hx4700.c                |  8 ++++++++
 arch/arm/mach-pxa/lpd270.c                |  9 +++++++++
 arch/arm/mach-pxa/magician.c              |  8 ++++++++
 arch/arm/mach-pxa/mainstone.c             | 13 ++++++++++++-
 arch/arm/mach-pxa/mioa701.c               |  8 ++++++++
 arch/arm/mach-pxa/palm27x.c               |  8 ++++++++
 arch/arm/mach-pxa/palmtc.c                |  8 ++++++++
 arch/arm/mach-pxa/palmte2.c               |  9 +++++++++
 arch/arm/mach-pxa/pcm990-baseboard.c      |  8 ++++++++
 arch/arm/mach-pxa/raumfeld.c              |  6 ++++++
 arch/arm/mach-pxa/tavorevb.c              | 11 +++++++++++
 arch/arm/mach-pxa/viper.c                 |  8 ++++++++
 arch/arm/mach-pxa/z2.c                    | 10 ++++++++++
 arch/arm/mach-pxa/zylonite.c              |  7 +++++++
 17 files changed, 144 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-pxa/cm-x300.c b/arch/arm/mach-pxa/cm-x300.c
index 8091aac..7e1887a 100644
--- a/arch/arm/mach-pxa/cm-x300.c
+++ b/arch/arm/mach-pxa/cm-x300.c
@@ -34,6 +34,7 @@
 
 #include <linux/mfd/da903x.h>
 #include <linux/regulator/machine.h>
+#include <linux/regulator/fixed.h>
 #include <linux/power_supply.h>
 #include <linux/apm-emulation.h>
 
@@ -305,6 +306,10 @@ static inline void cm_x300_init_lcd(void) {}
 #endif
 
 #if defined(CONFIG_BACKLIGHT_PWM) || defined(CONFIG_BACKLIGHT_PWM_MODULE)
+/* Dummy regulator for pwm-backlight driver */
+static struct regulator_consumer_supply backlight_supply =
+	REGULATOR_SUPPLY("power", "pwm-backlight.0");
+
 static struct platform_pwm_backlight_data cm_x300_backlight_data = {
 	.pwm_id		= 2,
 	.max_brightness	= 100,
@@ -322,6 +327,8 @@ static struct platform_device cm_x300_backlight_device = {
 
 static void cm_x300_init_bl(void)
 {
+	regulator_register_always_on(-1, "backlight-power",
+		&backlight_supply, 1, 0);
 	platform_device_register(&cm_x300_backlight_device);
 }
 #else
diff --git a/arch/arm/mach-pxa/colibri-pxa270-income.c b/arch/arm/mach-pxa/colibri-pxa270-income.c
index 2d4a7b4..108f2a7 100644
--- a/arch/arm/mach-pxa/colibri-pxa270-income.c
+++ b/arch/arm/mach-pxa/colibri-pxa270-income.c
@@ -20,6 +20,8 @@
 #include <linux/ioport.h>
 #include <linux/kernel.h>
 #include <linux/platform_device.h>
+#include <linux/regulator/machine.h>
+#include <linux/regulator/fixed.h>
 #include <linux/pwm_backlight.h>
 #include <linux/i2c/pxa-i2c.h>
 
@@ -184,6 +186,10 @@ static inline void income_lcd_init(void) {}
  * Backlight
  ******************************************************************************/
 #if defined(CONFIG_BACKLIGHT_PWM) || defined(CONFIG_BACKLIGHT_PWM_MODULE)
+/* Dummy regulator for pwm-backlight driver */
+static struct regulator_consumer_supply backlight_supply =
+	REGULATOR_SUPPLY("power", "pwm-backlight.0");
+
 static struct platform_pwm_backlight_data income_backlight_data = {
 	.pwm_id		= 0,
 	.max_brightness	= 0x3ff,
@@ -201,6 +207,8 @@ static struct platform_device income_backlight = {
 
 static void __init income_pwm_init(void)
 {
+	regulator_register_always_on(-1, "backlight-power",
+				     &backlight_supply, 1, 0);
 	platform_device_register(&income_backlight);
 }
 #else
diff --git a/arch/arm/mach-pxa/ezx.c b/arch/arm/mach-pxa/ezx.c
index dca1070..2b39d5f 100644
--- a/arch/arm/mach-pxa/ezx.c
+++ b/arch/arm/mach-pxa/ezx.c
@@ -15,6 +15,8 @@
 #include <linux/init.h>
 #include <linux/platform_device.h>
 #include <linux/delay.h>
+#include <linux/regulator/machine.h>
+#include <linux/regulator/fixed.h>
 #include <linux/pwm_backlight.h>
 #include <linux/input.h>
 #include <linux/gpio.h>
@@ -49,6 +51,10 @@
 #define GPIO19_GEN1_CAM_RST		19
 #define GPIO28_GEN2_CAM_RST		28
 
+/* Dummy regulator for pwm-backlight driver */
+static struct regulator_consumer_supply backlight_supply =
+	REGULATOR_SUPPLY("power", "pwm-backlight.0");
+
 static struct platform_pwm_backlight_data ezx_backlight_data = {
 	.pwm_id		= 0,
 	.max_brightness	= 1023,
@@ -792,6 +798,9 @@ static void __init a780_init(void)
 		platform_device_register(&a780_camera);
 	}
 
+	regulator_register_always_on(-1, "backlight-power",
+				     &backlight_supply, 1, 0);
+
 	platform_add_devices(ARRAY_AND_SIZE(ezx_devices));
 	platform_add_devices(ARRAY_AND_SIZE(a780_devices));
 }
diff --git a/arch/arm/mach-pxa/hx4700.c b/arch/arm/mach-pxa/hx4700.c
index 133109e..b2f444a 100644
--- a/arch/arm/mach-pxa/hx4700.c
+++ b/arch/arm/mach-pxa/hx4700.c
@@ -33,6 +33,7 @@
 #include <linux/regulator/driver.h>
 #include <linux/regulator/gpio-regulator.h>
 #include <linux/regulator/machine.h>
+#include <linux/regulator/fixed.h>
 #include <linux/regulator/max1586.h>
 #include <linux/spi/ads7846.h>
 #include <linux/spi/spi.h>
@@ -556,6 +557,10 @@ static struct platform_device hx4700_lcd = {
  * Backlight
  */
 
+/* Dummy regulator for pwm-backlight driver */
+static struct regulator_consumer_supply backlight_supply =
+	REGULATOR_SUPPLY("power", "pwm-backlight");
+
 static struct platform_pwm_backlight_data backlight_data = {
 	.pwm_id         = -1,	/* Superseded by pwm_lookup */
 	.max_brightness = 200,
@@ -876,6 +881,9 @@ static void __init hx4700_init(void)
 	pxa_set_btuart_info(NULL);
 	pxa_set_stuart_info(NULL);
 
+	regulator_register_always_on(-1, "backlight-power",
+				     &backlight_supply, 1, 0);
+
 	platform_add_devices(devices, ARRAY_SIZE(devices));
 	pwm_add_table(hx4700_pwm_lookup, ARRAY_SIZE(hx4700_pwm_lookup));
 
diff --git a/arch/arm/mach-pxa/lpd270.c b/arch/arm/mach-pxa/lpd270.c
index 1255ee0..985f622 100644
--- a/arch/arm/mach-pxa/lpd270.c
+++ b/arch/arm/mach-pxa/lpd270.c
@@ -23,6 +23,8 @@
 #include <linux/ioport.h>
 #include <linux/mtd/mtd.h>
 #include <linux/mtd/partitions.h>
+#include <linux/regulator/machine.h>
+#include <linux/regulator/fixed.h>
 #include <linux/pwm_backlight.h>
 
 #include <asm/types.h>
@@ -264,6 +266,10 @@ static struct platform_device lpd270_flash_device[2] = {
 	},
 };
 
+/* Dummy regulator for pwm-backlight driver */
+static struct regulator_consumer_supply backlight_supply =
+	REGULATOR_SUPPLY("power", "pwm-backlight.0");
+
 static struct platform_pwm_backlight_data lpd270_backlight_data = {
 	.pwm_id		= 0,
 	.max_brightness	= 1,
@@ -466,6 +472,9 @@ static void __init lpd270_init(void)
 	 */
 	ARB_CNTRL = ARB_CORE_PARK | 0x234;
 
+	regulator_register_always_on(-1, "backlight-power",
+				     &backlight_supply, 1, 0);
+
 	platform_add_devices(platform_devices, ARRAY_SIZE(platform_devices));
 
 	pxa_set_ac97_info(NULL);
diff --git a/arch/arm/mach-pxa/magician.c b/arch/arm/mach-pxa/magician.c
index f44532f..dcae8cc 100644
--- a/arch/arm/mach-pxa/magician.c
+++ b/arch/arm/mach-pxa/magician.c
@@ -27,6 +27,7 @@
 #include <linux/pwm_backlight.h>
 #include <linux/regulator/driver.h>
 #include <linux/regulator/gpio-regulator.h>
+#include <linux/regulator/fixed.h>
 #include <linux/regulator/machine.h>
 #include <linux/usb/gpio_vbus.h>
 #include <linux/i2c/pxa-i2c.h>
@@ -373,6 +374,10 @@ static void magician_backlight_exit(struct device *dev)
 	gpio_free_array(ARRAY_AND_SIZE(magician_bl_gpios));
 }
 
+/* Dummy regulator for pwm-backlight driver */
+static struct regulator_consumer_supply backlight_supply =
+	REGULATOR_SUPPLY("power", "pwm-backlight");
+
 static struct platform_pwm_backlight_data backlight_data = {
 	.pwm_id         = 0,
 	.max_brightness = 272,
@@ -742,6 +747,9 @@ static void __init magician_init(void)
 	pxa_set_btuart_info(NULL);
 	pxa_set_stuart_info(NULL);
 
+	regulator_register_always_on(-1, "backlight-power",
+				     &backlight_supply, 1, 0);
+
 	platform_add_devices(ARRAY_AND_SIZE(devices));
 
 	pxa_set_ficp_info(&magician_ficp_info);
diff --git a/arch/arm/mach-pxa/mainstone.c b/arch/arm/mach-pxa/mainstone.c
index 7a12c1b..c7b13be 100644
--- a/arch/arm/mach-pxa/mainstone.c
+++ b/arch/arm/mach-pxa/mainstone.c
@@ -25,6 +25,8 @@
 #include <linux/mtd/partitions.h>
 #include <linux/input.h>
 #include <linux/gpio_keys.h>
+#include <linux/regulator/machine.h>
+#include <linux/regulator/fixed.h>
 #include <linux/pwm_backlight.h>
 #include <linux/smc91x.h>
 #include <linux/i2c/pxa-i2c.h>
@@ -333,6 +335,10 @@ static struct platform_device mst_flash_device[2] = {
 };
 
 #if defined(CONFIG_FB_PXA) || defined(CONFIG_FB_PXA_MODULE)
+/* Dummy regulator for pwm-backlight driver */
+static struct regulator_consumer_supply backlight_supply =
+	REGULATOR_SUPPLY("power", "pwm-backlight.0");
+
 static struct platform_pwm_backlight_data mainstone_backlight_data = {
 	.pwm_id		= 0,
 	.max_brightness	= 1023,
@@ -350,7 +356,12 @@ static struct platform_device mainstone_backlight_device = {
 
 static void __init mainstone_backlight_register(void)
 {
-	int ret = platform_device_register(&mainstone_backlight_device);
+	int ret;
+
+	regulator_register_always_on(-1, "backlight-power",
+				     &backlight_supply, 1, 0);
+
+	ret = platform_device_register(&mainstone_backlight_device);
 	if (ret)
 		printk(KERN_ERR "mainstone: failed to register backlight device: %d\n", ret);
 }
diff --git a/arch/arm/mach-pxa/mioa701.c b/arch/arm/mach-pxa/mioa701.c
index f8979b9..ba9e1cb 100644
--- a/arch/arm/mach-pxa/mioa701.c
+++ b/arch/arm/mach-pxa/mioa701.c
@@ -37,6 +37,8 @@
 #include <linux/wm97xx.h>
 #include <linux/mtd/physmap.h>
 #include <linux/usb/gpio_vbus.h>
+#include <linux/regulator/machine.h>
+#include <linux/regulator/fixed.h>
 #include <linux/regulator/max1586.h>
 #include <linux/slab.h>
 #include <linux/i2c/pxa-i2c.h>
@@ -179,6 +181,10 @@ static unsigned long mioa701_pin_config[] = {
 	MFP_CFG_OUT(GPIO116, AF0, DRIVE_HIGH),
 };
 
+/* Dummy regulator for pwm-backlight driver */
+static struct regulator_consumer_supply backlight_supply =
+	REGULATOR_SUPPLY("power", "pwm-backlight");
+
 /* LCD Screen and Backlight */
 static struct platform_pwm_backlight_data mioa701_backlight_data = {
 	.pwm_id		= 0,
@@ -739,6 +745,8 @@ static void __init mioa701_machine_init(void)
 	pxa_set_udc_info(&mioa701_udc_info);
 	pxa_set_ac97_info(&mioa701_ac97_info);
 	pm_power_off = mioa701_poweroff;
+	regulator_register_always_on(-1, "backlight-power",
+				     &backlight_supply, 1, 0);
 	platform_add_devices(devices, ARRAY_SIZE(devices));
 	gsm_init();
 
diff --git a/arch/arm/mach-pxa/palm27x.c b/arch/arm/mach-pxa/palm27x.c
index 17d4c53..fc34f2b 100644
--- a/arch/arm/mach-pxa/palm27x.c
+++ b/arch/arm/mach-pxa/palm27x.c
@@ -20,6 +20,8 @@
 #include <linux/wm97xx.h>
 #include <linux/power_supply.h>
 #include <linux/usb/gpio_vbus.h>
+#include <linux/regulator/machine.h>
+#include <linux/regulator/fixed.h>
 #include <linux/regulator/max1586.h>
 #include <linux/i2c/pxa-i2c.h>
 
@@ -317,6 +319,10 @@ static void palm27x_backlight_exit(struct device *dev)
 		gpio_free(palm_lcd_power);
 }
 
+/* Dummy regulator for pwm-backlight driver */
+static struct regulator_consumer_supply backlight_supply =
+	REGULATOR_SUPPLY("power", "pwm-backlight.0");
+
 static struct platform_pwm_backlight_data palm27x_backlight_data = {
 	.pwm_id		= 0,
 	.max_brightness	= 0xfe,
@@ -339,6 +345,8 @@ void __init palm27x_pwm_init(int bl, int lcd)
 {
 	palm_bl_power	= bl;
 	palm_lcd_power	= lcd;
+	regulator_register_always_on(-1, "backlight-power",
+				     &backlight_supply, 1, 0);
 	platform_device_register(&palm27x_backlight);
 }
 #endif
diff --git a/arch/arm/mach-pxa/palmtc.c b/arch/arm/mach-pxa/palmtc.c
index 100b176f..b6b241c 100644
--- a/arch/arm/mach-pxa/palmtc.c
+++ b/arch/arm/mach-pxa/palmtc.c
@@ -18,6 +18,8 @@
 #include <linux/delay.h>
 #include <linux/irq.h>
 #include <linux/input.h>
+#include <linux/regulator/machine.h>
+#include <linux/regulator/fixed.h>
 #include <linux/pwm_backlight.h>
 #include <linux/gpio.h>
 #include <linux/input/matrix_keypad.h>
@@ -197,6 +199,10 @@ static void palmtc_backlight_exit(struct device *dev)
 	gpio_free(GPIO_NR_PALMTC_BL_POWER);
 }
 
+/* Dummy regulator for pwm-backlight driver */
+static struct regulator_consumer_supply backlight_supply =
+	REGULATOR_SUPPLY("power", "pwm-backlight.0");
+
 static struct platform_pwm_backlight_data palmtc_backlight_data = {
 	.pwm_id		= 1,
 	.max_brightness	= PALMTC_MAX_INTENSITY,
@@ -217,6 +223,8 @@ static struct platform_device palmtc_backlight = {
 
 static void __init palmtc_pwm_init(void)
 {
+	regulator_register_always_on(-1, "backlight-power",
+				     &backlight_supply, 1, 0);
 	platform_device_register(&palmtc_backlight);
 }
 #else
diff --git a/arch/arm/mach-pxa/palmte2.c b/arch/arm/mach-pxa/palmte2.c
index 0742721..d181f65 100644
--- a/arch/arm/mach-pxa/palmte2.c
+++ b/arch/arm/mach-pxa/palmte2.c
@@ -21,6 +21,8 @@
 #include <linux/gpio_keys.h>
 #include <linux/input.h>
 #include <linux/pda_power.h>
+#include <linux/regulator/machine.h>
+#include <linux/regulator/fixed.h>
 #include <linux/pwm_backlight.h>
 #include <linux/gpio.h>
 #include <linux/wm97xx.h>
@@ -160,6 +162,10 @@ static void palmte2_backlight_exit(struct device *dev)
 	gpio_free_array(ARRAY_AND_SIZE(palmte_bl_gpios));
 }
 
+/* Dummy regulator for pwm-backlight driver */
+static struct regulator_consumer_supply backlight_supply =
+	REGULATOR_SUPPLY("power", "pwm-backlight.0");
+
 static struct platform_pwm_backlight_data palmte2_backlight_data = {
 	.pwm_id		= 0,
 	.max_brightness	= PALMTE2_MAX_INTENSITY,
@@ -354,6 +360,9 @@ static void __init palmte2_init(void)
 	pxa_set_ac97_info(&palmte2_ac97_pdata);
 	pxa_set_ficp_info(&palmte2_ficp_platform_data);
 
+	regulator_register_always_on(-1, "backlight-power",
+				     &backlight_supply, 1, 0);
+
 	platform_add_devices(devices, ARRAY_SIZE(devices));
 }
 
diff --git a/arch/arm/mach-pxa/pcm990-baseboard.c b/arch/arm/mach-pxa/pcm990-baseboard.c
index fb7f1d1..25c480d 100644
--- a/arch/arm/mach-pxa/pcm990-baseboard.c
+++ b/arch/arm/mach-pxa/pcm990-baseboard.c
@@ -24,6 +24,8 @@
 #include <linux/platform_device.h>
 #include <linux/i2c.h>
 #include <linux/i2c/pxa-i2c.h>
+#include <linux/regulator/machine.h>
+#include <linux/regulator/fixed.h>
 #include <linux/pwm_backlight.h>
 
 #include <media/mt9v022.h>
@@ -148,6 +150,10 @@ static struct pxafb_mach_info pcm990_fbinfo __initdata = {
 };
 #endif
 
+/* Dummy regulator for pwm-backlight driver */
+static struct regulator_consumer_supply backlight_supply =
+	REGULATOR_SUPPLY("power", "pwm-backlight.0");
+
 static struct platform_pwm_backlight_data pcm990_backlight_data = {
 	.pwm_id		= 0,
 	.max_brightness	= 1023,
@@ -539,6 +545,8 @@ void __init pcm990_baseboard_init(void)
 #ifndef CONFIG_PCM990_DISPLAY_NONE
 	pxa_set_fb_info(NULL, &pcm990_fbinfo);
 #endif
+	regulator_register_always_on(-1, "backlight-power",
+				     &backlight_supply, 1, 0);
 	platform_device_register(&pcm990_backlight_device);
 
 	/* MMC */
diff --git a/arch/arm/mach-pxa/raumfeld.c b/arch/arm/mach-pxa/raumfeld.c
index af41888..aff0947 100644
--- a/arch/arm/mach-pxa/raumfeld.c
+++ b/arch/arm/mach-pxa/raumfeld.c
@@ -531,6 +531,10 @@ static void __init raumfeld_w1_init(void)
  * Framebuffer device
  */
 
+/* Dummy regulator for pwm-backlight driver */
+static struct regulator_consumer_supply backlight_supply =
+	REGULATOR_SUPPLY("power", "pwm-backlight.0");
+
 /* PWM controlled backlight */
 static struct platform_pwm_backlight_data raumfeld_pwm_backlight_data = {
 	.pwm_id		= 0,
@@ -617,6 +621,8 @@ static void __init raumfeld_lcd_init(void)
 	} else {
 		mfp_cfg_t raumfeld_pwm_pin_config = GPIO17_PWM0_OUT;
 		pxa3xx_mfp_config(&raumfeld_pwm_pin_config, 1);
+		regulator_register_always_on(-1, "backlight-power",
+					     &backlight_supply, 1, 0);
 		platform_device_register(&raumfeld_pwm_backlight_device);
 	}
 
diff --git a/arch/arm/mach-pxa/tavorevb.c b/arch/arm/mach-pxa/tavorevb.c
index f55979c..db61de5 100644
--- a/arch/arm/mach-pxa/tavorevb.c
+++ b/arch/arm/mach-pxa/tavorevb.c
@@ -18,6 +18,8 @@
 #include <linux/clk.h>
 #include <linux/gpio.h>
 #include <linux/smc91x.h>
+#include <linux/regulator/machine.h>
+#include <linux/regulator/fixed.h>
 #include <linux/pwm_backlight.h>
 
 #include <asm/mach-types.h>
@@ -164,6 +166,12 @@ static inline void tavorevb_init_keypad(void) {}
 #endif /* CONFIG_KEYBOARD_PXA27x || CONFIG_KEYBOARD_PXA27x_MODULE */
 
 #if defined(CONFIG_FB_PXA) || defined(CONFIG_FB_PXA_MODULE)
+/* Dummy regulator for pwm-backlight driver */
+static struct regulator_consumer_supply backlight_supply[] = {
+	REGULATOR_SUPPLY("power", "pwm-backlight.0"),
+	REGULATOR_SUPPLY("power", "pwm-backlight.1"),
+};
+
 static struct platform_pwm_backlight_data tavorevb_backlight_data[] = {
 	[0] = {
 		/* primary backlight */
@@ -464,6 +472,9 @@ static struct pxafb_mach_info tavorevb_lcd_info = {
 
 static void __init tavorevb_init_lcd(void)
 {
+	regulator_register_always_on(-1, "backlight-power",
+				     backlight_supply,
+				     ARRAY_SIZE(backlight_supply), 0);
 	platform_device_register(&tavorevb_backlight_devices[0]);
 	platform_device_register(&tavorevb_backlight_devices[1]);
 	pxa_set_fb_info(NULL, &tavorevb_lcd_info);
diff --git a/arch/arm/mach-pxa/viper.c b/arch/arm/mach-pxa/viper.c
index 9c363c0..ed625d9 100644
--- a/arch/arm/mach-pxa/viper.c
+++ b/arch/arm/mach-pxa/viper.c
@@ -39,6 +39,8 @@
 #include <linux/i2c/pxa-i2c.h>
 #include <linux/serial_8250.h>
 #include <linux/smc91x.h>
+#include <linux/regulator/machine.h>
+#include <linux/regulator/fixed.h>
 #include <linux/pwm_backlight.h>
 #include <linux/usb/isp116x.h>
 #include <linux/mtd/mtd.h>
@@ -396,6 +398,10 @@ static void viper_backlight_exit(struct device *dev)
 	gpio_free(VIPER_BCKLIGHT_EN_GPIO);
 }
 
+/* Dummy regulator for pwm-backlight driver */
+static struct regulator_consumer_supply backlight_supply =
+	REGULATOR_SUPPLY("power", "pwm-backlight.0");
+
 static struct platform_pwm_backlight_data viper_backlight_data = {
 	.pwm_id		= 0,
 	.max_brightness	= 100,
@@ -940,6 +946,8 @@ static void __init viper_init(void)
 		smc91x_device.num_resources--;
 
 	pxa_set_i2c_info(NULL);
+	regulator_register_always_on(-1, "backlight-power",
+				     &backlight_supply, 1, 0);
 	platform_add_devices(viper_devs, ARRAY_SIZE(viper_devs));
 
 	viper_init_vcore_gpios();
diff --git a/arch/arm/mach-pxa/z2.c b/arch/arm/mach-pxa/z2.c
index 989903a..a7ff8a8 100644
--- a/arch/arm/mach-pxa/z2.c
+++ b/arch/arm/mach-pxa/z2.c
@@ -29,6 +29,7 @@
 #include <linux/gpio_keys.h>
 #include <linux/delay.h>
 #include <linux/regulator/machine.h>
+#include <linux/regulator/fixed.h>
 #include <linux/i2c/pxa-i2c.h>
 
 #include <asm/mach-types.h>
@@ -199,6 +200,12 @@ static inline void z2_nor_init(void) {}
  * Backlight
  ******************************************************************************/
 #if defined(CONFIG_BACKLIGHT_PWM) || defined(CONFIG_BACKLIGHT_PWM_MODULE)
+/* Dummy regulator for pwm-backlight driver */
+static struct regulator_consumer_supply backlight_supply[] = {
+	REGULATOR_SUPPLY("power", "pwm-backlight.0"),
+	REGULATOR_SUPPLY("power", "pwm-backlight.1"),
+};
+
 static struct platform_pwm_backlight_data z2_backlight_data[] = {
 	[0] = {
 		/* Keypad Backlight */
@@ -234,6 +241,9 @@ static struct platform_device z2_backlight_devices[2] = {
 };
 static void __init z2_pwm_init(void)
 {
+	regulator_register_always_on(-1, "backlight-power",
+				     backlight_supply,
+				     ARRAY_SIZE(backlight_supply), 0);
 	platform_device_register(&z2_backlight_devices[0]);
 	platform_device_register(&z2_backlight_devices[1]);
 }
diff --git a/arch/arm/mach-pxa/zylonite.c b/arch/arm/mach-pxa/zylonite.c
index 1f00d65..04409f1 100644
--- a/arch/arm/mach-pxa/zylonite.c
+++ b/arch/arm/mach-pxa/zylonite.c
@@ -120,6 +120,10 @@ static inline void zylonite_init_leds(void) {}
 #endif
 
 #if defined(CONFIG_FB_PXA) || defined(CONFIG_FB_PXA_MODULE)
+/* Dummy regulator for pwm-backlight driver */
+static struct regulator_consumer_supply backlight_supply =
+	REGULATOR_SUPPLY("power", "pwm-backlight.0");
+
 static struct platform_pwm_backlight_data zylonite_backlight_data = {
 	.pwm_id		= 3,
 	.max_brightness	= 100,
@@ -205,6 +209,9 @@ static struct pxafb_mach_info zylonite_sharp_lcd_info = {
 
 static void __init zylonite_init_lcd(void)
 {
+	regulator_register_always_on(-1, "backlight-power",
+				     &backlight_supply, 1, 0);
+
 	platform_device_register(&zylonite_backlight_device);
 
 	if (lcd_id & 0x20) {
-- 
1.8.1.5



From paul at pwsan.com  Mon Apr  1 17:58:10 2013
From: paul at pwsan.com (Paul Walmsley)
Date: Mon, 1 Apr 2013 21:58:10 +0000 (UTC)
Subject: omap cpufreq driver in multi-platform kernels
In-Reply-To: <5159E3FF.4050308@gmail.com>
References: <5152503C.2050503@gmail.com>
 <alpine.DEB.2.00.1303270212110.8161@utopia.booyaka.com>
 <20130327133220.GA30868@kahuna> <5153207A.4050109@gmail.com>
 <20130327170221.GA32231@kahuna> <87d2uk91ai.fsf@linaro.org>
 <20130327175621.GA32693@kahuna>
 <alpine.DEB.2.00.1303302156180.6436@utopia.booyaka.com>
 <5159E3FF.4050308@gmail.com>
Message-ID: <alpine.DEB.2.00.1304012154460.21548@utopia.booyaka.com>

Hi

On Mon, 1 Apr 2013, Rob Herring wrote:

> On 03/30/2013 05:21 PM, Paul Walmsley wrote:
> > 
> > Looked at this a little today.  I see that the platform_driver CPUFreq 
> > driver approach was taken with several SoCs in mainline. Could someone 
> > explain the theory behind making the CPUFreq drivers platform_drivers, 
> > rather than just modules?
> > 
> > The part that doesn't make sense to me is that the existing CPUFreq 
> > drivers don't represent an actual hardware block.  Conceptually, they 
> > aren't drivers for the CPU, nor are they drivers for a CPU frequency 
> > scaling IP block.  One might as well bind a CPUIdle driver or a CPU 
> > throttling thermal driver to the CPU device.
> > 
> > Wouldn't it be best to just make them modules?
> 
> Then module auto loading doesn't work AFAIK. We will want them to be
> built as modules in multi-platform kernels to reduce the kernel size,
> but you don't want to just shift the problem to the OS to decide what
> modules a given platform needs.
> 
> > Also, noticed that the Highbank CPUFreq driver creates a virtual device in 
> > its code.  That also doesn't seem right.  Isn't device creation better 
> > left to DT/ACPI/whatever?
> 
> DT describes the h/w. Creating DT nodes that match the cpufreq drivers
> is not describing the h/w, but what Linux wants currently. Cpufreq
> drivers either touch parts of multiple h/w blocks, a single shared h/w
> block or don't touch h/w directly. The cpufreq-cpu0 driver is the last
> case and does use DT. Perhaps we will get to the point that all
> low-level interfaces are abstracted and we can have a single cpufreq driver.
> 
> I think platform drivers are the right way to go, but I'd like to come
> up with a better way to instantiate the devices. The only idea I've come
> up with is to do some sort of automatic device creation based machine
> compatible property matching.

So sounds like DT is expected to be used in a Linux-specific way as a 
/etc/modules replacement.  Why not create a Linux-specific DT node that 
can be used to load any module?  Wouldn't that have the same effect, but 
avoid creating false device nodes that don't exist in the hardware?


- Paul


From sam at ravnborg.org  Mon Apr  1 17:58:34 2013
From: sam at ravnborg.org (Sam Ravnborg)
Date: Mon, 1 Apr 2013 23:58:34 +0200
Subject: [PATCH 1/2] Allow constructor name selection by architecture.
In-Reply-To: <87F2CC87-0FAF-49CB-AE70-423FB063A0E5@mvista.com>
References: <1338230018-31052-1-git-send-email-vincent.sanders@collabora.co.uk>
 <1338230018-31052-2-git-send-email-vincent.sanders@collabora.co.uk>
 <20120528203005.GA20560@merkur.ravnborg.org>
 <20120529090614.GD12217@n2100.arm.linux.org.uk>
 <20120606101253.GM8262@n2100.arm.linux.org.uk>
 <87F2CC87-0FAF-49CB-AE70-423FB063A0E5@mvista.com>
Message-ID: <20130401215834.GA5972@merkur.ravnborg.org>

On Mon, Apr 01, 2013 at 05:47:38PM -0400, George G. Davis wrote:
> On Jun 6, 2012, at 6:12 AM, Russell King - ARM Linux wrote:
> > On Tue, May 29, 2012 at 10:06:14AM +0100, Russell King - ARM Linux wrote:
> >> On Mon, May 28, 2012 at 10:30:05PM +0200, Sam Ravnborg wrote:
> >>> On Mon, May 28, 2012 at 07:33:37PM +0100, Vincent Sanders wrote:
> >>>> From: Vincent Sanders <vince at collabora.co.uk>
> >>>> 
> >>>> The constructor symbol name is different between platforms. Allow this
> >>>> to be selected by configuration and set suitable default values.
> >>>> 
> >>>> Signed-off-by: Vincent Sanders <vincent.sanders at collabora.co.uk>
> >>>> ---
> >>>> include/asm-generic/vmlinux.lds.h |    6 +++---
> >>>> init/Kconfig                      |    6 ++++++
> >>>> kernel/module.c                   |    2 +-
> >>>> 3 files changed, 10 insertions(+), 4 deletions(-)
> >>>> 
> >>>> diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
> >>>> index 8aeadf6..fd34808 100644
> >>>> --- a/include/asm-generic/vmlinux.lds.h
> >>>> +++ b/include/asm-generic/vmlinux.lds.h
> >>>> @@ -471,9 +471,9 @@
> >>>> 	}
> >>>> 
> >>>> #ifdef CONFIG_CONSTRUCTORS
> >>>> -#define KERNEL_CTORS()	. = ALIGN(8);			   \
> >>>> -			VMLINUX_SYMBOL(__ctors_start) = .; \
> >>>> -			*(.ctors)			   \
> >>>> +#define KERNEL_CTORS()	. = ALIGN(8);					\
> >>>> +			VMLINUX_SYMBOL(__ctors_start) = .;		\
> >>>> +			*(CONFIG_CONSTRUCTORS_NAME)			\
> >>>> 			VMLINUX_SYMBOL(__ctors_end) = .;
> >>> 
> >>> What is wrong with adding both "standard" names for ctors uncnditionally?
> >>> Like this:
> >>>> 			*(.ctors)			   \
> >>>> +			*(.init_array)			   \
> >> 
> >> That doesn't get rid of CONFIG_CONSTRUCTORS_NAME, because it's needed
> >> in the module code.  Do you have a suggestion to solve that as well?
> > 
> > Ping.
> 
> Pinging this back to life.  I'd like to see GCOV for ARM eABI finally make it upstream.
> So, any objections to this?  Should it be resubmitted?

Why is CONFIG_CONSTRUCTORS_NAME needed in module code?

	Sam


From swarren at wwwdotorg.org  Mon Apr  1 18:00:47 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Mon, 01 Apr 2013 16:00:47 -0600
Subject: How to represent negative values for device tree property
In-Reply-To: <5159F760.1080605@codeaurora.org>
References: <5159F760.1080605@codeaurora.org>
Message-ID: <515A038F.2090902@wwwdotorg.org>

On 04/01/2013 03:08 PM, David Collins wrote:
> Hi,
> 
> I am working on a thermal driver which needs to be able to read a
> temperature threshold from a device tree property.  The hardware supports
> thresholds in the range -204.8 to +204.7 C in 0.1 C steps.  I have found,
> as I am sure others have as well, that dtc treats a '-' before an integer
> in a dtsi file as a syntax error.  Therefore, I need some artificial way
> to represent negative numbers in device tree.  Here are the possibilities
> that I have thought of so far:

Doesn't the very latest dtc, which contains integer expression support,
allow unary -? I thought that code had been imported into the kernel
(goes and checks) yes it has. What's the error you're seeing;
over/underflow or syntax?

That said, DT cells are supposed to be u32 not s32, so perhaps this
isn't unexpected.


From alex at digriz.org.uk  Mon Apr  1 18:02:04 2013
From: alex at digriz.org.uk (Alexander Clouter)
Date: Mon, 1 Apr 2013 23:02:04 +0100
Subject: [PATCH 0/3] add devicetree bindings for rtc-m48t86
In-Reply-To: <5159FFAA.5030205@gmail.com>
References: <1364766971-5914-1-git-send-email-alex@digriz.org.uk>
 <5159FFAA.5030205@gmail.com>
Message-ID: <20130401220204.GJ1953@edkhil>

On Tue, Apr 02, 2013 at 08:44:10AM +1100, Ryan Mallon wrote:
>On 01/04/13 08:56, Alexander Clouter wrote:
>> Currently there are two users of rtc-m48t86 (mach-ep93xx/ts72xx.c and
>> mach-orion5x/ts78xx-setup.c) and both just use {read,write}b against
>> a memory mapped region.  As I am devicetree'ing the TS-7800, this
>> driver needs converting and thats what this patchset does.
>>
>> The patch does the following:
>>  * remove platform specific ops hooks, moving ioremap'ing and
>> 	everything into the driver
>>  * utilises named resources to indicate index/data ranges
>>  * moves the RTC detection routine from ts78xx-setup.c into rtc-m48t86.c
>>  * and, of course, enable devicetree hooks and include documentation
>>
>> Awkward step, the first patch breaks both boards, the two following
>> patches fix them.  Happy to re-work this if folks give me a pointer
>> on how to do this in an acceptable way.
>
>Sorry, that's no good. It breaks things like git bisect.

Bah :)

>> My vote is to break fast, fix fast, spend the time writing other code :)
>
>The patch series will need to be reworked so that there is no
>build/runtime breakage between any of the patches. I'll have a read
>through and see if I can suggest something.

I am currently working through a new patchset now.  It maintains the original {write,read}byte 
ops but if not defined, and the required named resources are present, it moves to using driver 
side mem mapped regions and what not...

'watch this space'

Cheers

-- 
Alexander Clouter
.sigmonster says: Deflector shields just came on, Captain.


From mturquette at linaro.org  Mon Apr  1 17:56:30 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Mon, 1 Apr 2013 14:56:30 -0700
Subject: [RFC][PATCH 0/5] Introduce .get_voltage callback into voltdm
In-Reply-To: <alpine.DEB.2.00.1303310234110.6436@utopia.booyaka.com>
References: <1349313365-5262-1-git-send-email-mturquette@ti.com>
 <alpine.DEB.2.00.1303310234110.6436@utopia.booyaka.com>
Message-ID: <CAPtuhTgNQShFvfe+AyN-uFJuFL85V1ceT-udWqFMeUUbmjhqmw@mail.gmail.com>

On Sat, Mar 30, 2013 at 7:35 PM, Paul Walmsley <paul at pwsan.com> wrote:
> Hi Mike, Kevin,
>
> On Wed, 3 Oct 2012, Mike Turquette wrote:
>
>> From: Mike Turquette <mturquette at linaro.org>
>>
>> This series creates a new callback for struct voltagedomain,
>> .get_voltage.  This fetches the voltage from hardware, if possible, and
>> returns it to the caller.  We use this call to populate
>> voltdm->nominal_volt at boot time.
>
> Just checking on the status of this series.  Is this superseded by
> Andrii's driver?  Does it need to be reposted for merging?  etc.
>

Hi Paul,

Thanks for resurrecting this thread.  This series is needed if the ABB
transition is triggered by the OMAP VC/VP code.  Andrii's approach
triggers an ABB transition based on the clock rate-change notifiers
but that is still in discussion.

So the short answer is "I don't know yet".

Regards,
Mike

>
> - Paul


From sergei.shtylyov at cogentembedded.com  Mon Apr  1 18:04:54 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Tue, 2 Apr 2013 02:04:54 +0400
Subject: [PATCH 1/2] ARM: shmobile: R8A7779: add Ether support
Message-ID: <201304020204.54546.sergei.shtylyov@cogentembedded.com>

Add Ether clock and platform device for R8A7779 SoC; add a function to register
this device with board-specific platform data.

Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

---
This patch is atop of the 'next' branch of Simon Horman's renesas.git.

 arch/arm/mach-shmobile/clock-r8a7779.c        |    4 ++-
 arch/arm/mach-shmobile/include/mach/r8a7779.h |    1 
 arch/arm/mach-shmobile/setup-r8a7779.c        |   29 +++++++++++++++++++++++++-
 3 files changed, 32 insertions(+), 2 deletions(-)

Index: renesas/arch/arm/mach-shmobile/clock-r8a7779.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/clock-r8a7779.c
+++ renesas/arch/arm/mach-shmobile/clock-r8a7779.c
@@ -93,7 +93,7 @@ static struct clk *main_clks[] = {
 };
 
 enum { MSTP323, MSTP322, MSTP321, MSTP320,
-	MSTP115,
+	MSTP115, MSTP114,
 	MSTP103, MSTP101, MSTP100,
 	MSTP030,
 	MSTP029, MSTP028, MSTP027, MSTP026, MSTP025, MSTP024, MSTP023, MSTP022, MSTP021,
@@ -107,6 +107,7 @@ static struct clk mstp_clks[MSTP_NR] = {
 	[MSTP321] = SH_CLK_MSTP32(&clkp_clk, MSTPCR3, 21, 0), /* SDHI2 */
 	[MSTP320] = SH_CLK_MSTP32(&clkp_clk, MSTPCR3, 20, 0), /* SDHI3 */
 	[MSTP115] = SH_CLK_MSTP32(&clkp_clk, MSTPCR1, 15, 0), /* SATA */
+	[MSTP114] = SH_CLK_MSTP32(&clkp_clk, MSTPCR1, 14, 0), /* Ether */
 	[MSTP103] = SH_CLK_MSTP32(&clks_clk, MSTPCR1,  3, 0), /* DU */
 	[MSTP101] = SH_CLK_MSTP32(&clkp_clk, MSTPCR1,  1, 0), /* USB2 */
 	[MSTP100] = SH_CLK_MSTP32(&clkp_clk, MSTPCR1,  0, 0), /* USB0/1 */
@@ -143,6 +144,7 @@ static struct clk_lookup lookups[] = {
 	/* MSTP32 clocks */
 	CLKDEV_DEV_ID("sata_rcar", &mstp_clks[MSTP115]), /* SATA */
 	CLKDEV_DEV_ID("fc600000.sata", &mstp_clks[MSTP115]), /* SATA w/DT */
+	CLKDEV_DEV_ID("sh-eth", &mstp_clks[MSTP114]), /* Ether */
 	CLKDEV_DEV_ID("ehci-platform.1", &mstp_clks[MSTP101]), /* USB EHCI port2 */
 	CLKDEV_DEV_ID("ohci-platform.1", &mstp_clks[MSTP101]), /* USB OHCI port2 */
 	CLKDEV_DEV_ID("ehci-platform.0", &mstp_clks[MSTP100]), /* USB EHCI port0/1 */
Index: renesas/arch/arm/mach-shmobile/include/mach/r8a7779.h
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/include/mach/r8a7779.h
+++ renesas/arch/arm/mach-shmobile/include/mach/r8a7779.h
@@ -31,6 +31,7 @@ extern void r8a7779_earlytimer_init(void
 extern void r8a7779_add_early_devices(void);
 extern void r8a7779_add_standard_devices(void);
 extern void r8a7779_add_standard_devices_dt(void);
+extern void r8a7779_add_ether_device(void *pdata);
 extern void r8a7779_clock_init(void);
 extern void r8a7779_pinmux_init(void);
 extern void r8a7779_pm_init(void);
Index: renesas/arch/arm/mach-shmobile/setup-r8a7779.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/setup-r8a7779.c
+++ renesas/arch/arm/mach-shmobile/setup-r8a7779.c
@@ -1,8 +1,9 @@
 /*
  * r8a7779 processor support
  *
- * Copyright (C) 2011  Renesas Solutions Corp.
+ * Copyright (C) 2011, 2013  Renesas Solutions Corp.
  * Copyright (C) 2011  Magnus Damm
+ * Copyright (C) 2013  Cogent Embedded, Inc.
  *
  * 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
@@ -369,6 +370,25 @@ static struct platform_device i2c3_devic
 	.num_resources	= ARRAY_SIZE(rcar_i2c3_res),
 };
 
+/* Ether */
+static struct resource ether_resources[] = {
+	{
+		.start	= 0xfde00000,
+		.end	= 0xfde003ff,
+		.flags	= IORESOURCE_MEM,
+	}, {
+		.start	= gic_iid(0xb4),
+		.flags	= IORESOURCE_IRQ,
+	},
+};
+
+static struct platform_device ether_device = {
+	.name		= "sh-eth",
+	.id		= -1,
+	.resource	= ether_resources,
+	.num_resources	= ARRAY_SIZE(ether_resources),
+};
+
 static struct resource sata_resources[] = {
 	[0] = {
 		.name	= "rcar-sata",
@@ -428,6 +448,13 @@ void __init r8a7779_add_standard_devices
 			    ARRAY_SIZE(r8a7779_late_devices));
 }
 
+void __init r8a7779_add_ether_device(void *pdata)
+{
+	ether_device.dev.platform_data = pdata;
+
+	platform_device_register(&ether_device);
+}
+
 /* do nothing for !CONFIG_SMP or !CONFIG_HAVE_TWD */
 void __init __weak r8a7779_register_twd(void) { }
 


From rmallon at gmail.com  Mon Apr  1 18:06:47 2013
From: rmallon at gmail.com (Ryan Mallon)
Date: Tue, 02 Apr 2013 09:06:47 +1100
Subject: [PATCH 1/3] rtc: rtc-m48t86: add devicetree bindings
In-Reply-To: <1364766971-5914-2-git-send-email-alex@digriz.org.uk>
References: <1364766971-5914-1-git-send-email-alex@digriz.org.uk>
 <1364766971-5914-2-git-send-email-alex@digriz.org.uk>
Message-ID: <515A04F7.8000904@gmail.com>

On 01/04/13 08:56, Alexander Clouter wrote:
> This patch allows rtc-m48t86 to be used via devicetree.
> 
> Signed-off-by: Alexander Clouter <alex at digriz.org.uk>
> ---
>  .../devicetree/bindings/rtc/rtc-m48t86.txt         |   17 ++
>  drivers/rtc/rtc-m48t86.c                           |  254 +++++++++++++++-----
>  include/linux/m48t86.h                             |   16 --
>  3 files changed, 213 insertions(+), 74 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/rtc/rtc-m48t86.txt
>  delete mode 100644 include/linux/m48t86.h

Some comments below.

> diff --git a/Documentation/devicetree/bindings/rtc/rtc-m48t86.txt b/Documentation/devicetree/bindings/rtc/rtc-m48t86.txt
> new file mode 100644
> index 0000000..1336c98
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/rtc/rtc-m48t86.txt
> @@ -0,0 +1,17 @@
> +ST M48T86 / Dallas DS12887 RTC driver
> +
> +Required properties:
> +- compatible: "rtc-m48t86"
> +- reg: array of two address ranges of the RTC index and data registers
> +- reg-names: must have "rtc_index" and "rtc_data" present
> +
> +Example:
> +
> +rtc at 808 {
> +	#address-cells = <1>;
> +	#size-cells = <1>;
> +	compatible = "rtc-m48t86";
> +	reg =   <0x808 0x04>,
> +		<0x80c 0x04>;
> +	reg-names = "rtc_index", "rtc_data";
> +};
> diff --git a/drivers/rtc/rtc-m48t86.c b/drivers/rtc/rtc-m48t86.c
> index 2ffbcac..47e9fd1 100644
> --- a/drivers/rtc/rtc-m48t86.c
> +++ b/drivers/rtc/rtc-m48t86.c
> @@ -16,8 +16,10 @@
>  #include <linux/module.h>
>  #include <linux/rtc.h>
>  #include <linux/platform_device.h>
> -#include <linux/m48t86.h>
>  #include <linux/bcd.h>
> +#include <linux/of.h>
> +#include <linux/slab.h>
> +#include <linux/io.h>
>  
>  #define M48T86_REG_SEC		0x00
>  #define M48T86_REG_SECALRM	0x01
> @@ -41,40 +43,61 @@
>  
>  #define DRV_VERSION "0.1"
>  
> +struct m48t86_rtc_private_data {
> +	void __iomem		*io_index;
> +	void __iomem		*io_data;
> +
> +	struct rtc_device	*rtc;
> +};
> +
> +static unsigned char m48t86_rtc_readbyte(
> +			struct m48t86_rtc_private_data *priv,
> +			unsigned long addr)

Line breaks like this are a bit ugly. Breaking after the return type
would be better. You can shorten this by changing 'unsigned char' to
'u8', and 'm48t86_rtc_private_data' to something like 'm48t86_priv'. Why
is addr unsigned long if you are passing it to writeb?

> +{
> +	writeb(addr, priv->io_index);
> +	return readb(priv->io_data);
> +}
> +
> +static void m48t86_rtc_writebyte(
> +			struct m48t86_rtc_private_data *priv,
> +			unsigned char value, unsigned long addr)
> +{
> +	writeb(addr, priv->io_index);
> +	writeb(value, priv->io_data);
> +}
>  
>  static int m48t86_rtc_read_time(struct device *dev, struct rtc_time *tm)
>  {
>  	unsigned char reg;
> -	struct platform_device *pdev = to_platform_device(dev);
> -	struct m48t86_ops *ops = pdev->dev.platform_data;
> +	struct m48t86_rtc_private_data *priv = dev_get_drvdata(dev);
>  
> -	reg = ops->readbyte(M48T86_REG_B);
> +	reg = m48t86_rtc_readbyte(priv, M48T86_REG_B);
>  
>  	if (reg & M48T86_REG_B_DM) {
>  		/* data (binary) mode */
> -		tm->tm_sec	= ops->readbyte(M48T86_REG_SEC);
> -		tm->tm_min	= ops->readbyte(M48T86_REG_MIN);
> -		tm->tm_hour	= ops->readbyte(M48T86_REG_HOUR) & 0x3F;
> -		tm->tm_mday	= ops->readbyte(M48T86_REG_DOM);
> +		tm->tm_sec	= m48t86_rtc_readbyte(priv, M48T86_REG_SEC);
> +		tm->tm_min	= m48t86_rtc_readbyte(priv, M48T86_REG_MIN);
> +		tm->tm_hour	= m48t86_rtc_readbyte(priv, M48T86_REG_HOUR) & 0x3F;
> +		tm->tm_mday	= m48t86_rtc_readbyte(priv, M48T86_REG_DOM);
>  		/* tm_mon is 0-11 */
> -		tm->tm_mon	= ops->readbyte(M48T86_REG_MONTH) - 1;
> -		tm->tm_year	= ops->readbyte(M48T86_REG_YEAR) + 100;
> -		tm->tm_wday	= ops->readbyte(M48T86_REG_DOW);
> +		tm->tm_mon	= m48t86_rtc_readbyte(priv, M48T86_REG_MONTH) - 1;
> +		tm->tm_year	= m48t86_rtc_readbyte(priv, M48T86_REG_YEAR) + 100;
> +		tm->tm_wday	= m48t86_rtc_readbyte(priv, M48T86_REG_DOW);
>  	} else {
>  		/* bcd mode */
> -		tm->tm_sec	= bcd2bin(ops->readbyte(M48T86_REG_SEC));
> -		tm->tm_min	= bcd2bin(ops->readbyte(M48T86_REG_MIN));
> -		tm->tm_hour	= bcd2bin(ops->readbyte(M48T86_REG_HOUR) & 0x3F);
> -		tm->tm_mday	= bcd2bin(ops->readbyte(M48T86_REG_DOM));
> +		tm->tm_sec	= bcd2bin(m48t86_rtc_readbyte(priv, M48T86_REG_SEC));
> +		tm->tm_min	= bcd2bin(m48t86_rtc_readbyte(priv, M48T86_REG_MIN));
> +		tm->tm_hour	= bcd2bin(m48t86_rtc_readbyte(priv, M48T86_REG_HOUR) & 0x3F);
> +		tm->tm_mday	= bcd2bin(m48t86_rtc_readbyte(priv, M48T86_REG_DOM));
>  		/* tm_mon is 0-11 */
> -		tm->tm_mon	= bcd2bin(ops->readbyte(M48T86_REG_MONTH)) - 1;
> -		tm->tm_year	= bcd2bin(ops->readbyte(M48T86_REG_YEAR)) + 100;
> -		tm->tm_wday	= bcd2bin(ops->readbyte(M48T86_REG_DOW));
> +		tm->tm_mon	= bcd2bin(m48t86_rtc_readbyte(priv, M48T86_REG_MONTH)) - 1;
> +		tm->tm_year	= bcd2bin(m48t86_rtc_readbyte(priv, M48T86_REG_YEAR)) + 100;
> +		tm->tm_wday	= bcd2bin(m48t86_rtc_readbyte(priv, M48T86_REG_DOW));
>  	}
>  
>  	/* correct the hour if the clock is in 12h mode */
>  	if (!(reg & M48T86_REG_B_H24))
> -		if (ops->readbyte(M48T86_REG_HOUR) & 0x80)
> +		if (m48t86_rtc_readbyte(priv, M48T86_REG_HOUR) & 0x80)
>  			tm->tm_hour += 12;
>  
>  	return rtc_valid_tm(tm);
> @@ -83,38 +106,37 @@ static int m48t86_rtc_read_time(struct device *dev, struct rtc_time *tm)
>  static int m48t86_rtc_set_time(struct device *dev, struct rtc_time *tm)
>  {
>  	unsigned char reg;
> -	struct platform_device *pdev = to_platform_device(dev);
> -	struct m48t86_ops *ops = pdev->dev.platform_data;
> +	struct m48t86_rtc_private_data *priv = dev_get_drvdata(dev);
>  
> -	reg = ops->readbyte(M48T86_REG_B);
> +	reg = m48t86_rtc_readbyte(priv, M48T86_REG_B);
>  
>  	/* update flag and 24h mode */
>  	reg |= M48T86_REG_B_SET | M48T86_REG_B_H24;
> -	ops->writebyte(reg, M48T86_REG_B);
> +	m48t86_rtc_writebyte(priv, reg, M48T86_REG_B);
>  
>  	if (reg & M48T86_REG_B_DM) {
>  		/* data (binary) mode */
> -		ops->writebyte(tm->tm_sec, M48T86_REG_SEC);
> -		ops->writebyte(tm->tm_min, M48T86_REG_MIN);
> -		ops->writebyte(tm->tm_hour, M48T86_REG_HOUR);
> -		ops->writebyte(tm->tm_mday, M48T86_REG_DOM);
> -		ops->writebyte(tm->tm_mon + 1, M48T86_REG_MONTH);
> -		ops->writebyte(tm->tm_year % 100, M48T86_REG_YEAR);
> -		ops->writebyte(tm->tm_wday, M48T86_REG_DOW);
> +		m48t86_rtc_writebyte(priv, tm->tm_sec, M48T86_REG_SEC);
> +		m48t86_rtc_writebyte(priv, tm->tm_min, M48T86_REG_MIN);
> +		m48t86_rtc_writebyte(priv, tm->tm_hour, M48T86_REG_HOUR);
> +		m48t86_rtc_writebyte(priv, tm->tm_mday, M48T86_REG_DOM);
> +		m48t86_rtc_writebyte(priv, tm->tm_mon + 1, M48T86_REG_MONTH);
> +		m48t86_rtc_writebyte(priv, tm->tm_year % 100, M48T86_REG_YEAR);
> +		m48t86_rtc_writebyte(priv, tm->tm_wday, M48T86_REG_DOW);
>  	} else {
>  		/* bcd mode */
> -		ops->writebyte(bin2bcd(tm->tm_sec), M48T86_REG_SEC);
> -		ops->writebyte(bin2bcd(tm->tm_min), M48T86_REG_MIN);
> -		ops->writebyte(bin2bcd(tm->tm_hour), M48T86_REG_HOUR);
> -		ops->writebyte(bin2bcd(tm->tm_mday), M48T86_REG_DOM);
> -		ops->writebyte(bin2bcd(tm->tm_mon + 1), M48T86_REG_MONTH);
> -		ops->writebyte(bin2bcd(tm->tm_year % 100), M48T86_REG_YEAR);
> -		ops->writebyte(bin2bcd(tm->tm_wday), M48T86_REG_DOW);
> +		m48t86_rtc_writebyte(priv, bin2bcd(tm->tm_sec), M48T86_REG_SEC);
> +		m48t86_rtc_writebyte(priv, bin2bcd(tm->tm_min), M48T86_REG_MIN);
> +		m48t86_rtc_writebyte(priv, bin2bcd(tm->tm_hour), M48T86_REG_HOUR);
> +		m48t86_rtc_writebyte(priv, bin2bcd(tm->tm_mday), M48T86_REG_DOM);
> +		m48t86_rtc_writebyte(priv, bin2bcd(tm->tm_mon + 1), M48T86_REG_MONTH);
> +		m48t86_rtc_writebyte(priv, bin2bcd(tm->tm_year % 100), M48T86_REG_YEAR);
> +		m48t86_rtc_writebyte(priv, bin2bcd(tm->tm_wday), M48T86_REG_DOW);
>  	}
>  
>  	/* update ended */
>  	reg &= ~M48T86_REG_B_SET;
> -	ops->writebyte(reg, M48T86_REG_B);
> +	m48t86_rtc_writebyte(priv, reg, M48T86_REG_B);
>  
>  	return 0;
>  }
> @@ -122,15 +144,14 @@ static int m48t86_rtc_set_time(struct device *dev, struct rtc_time *tm)
>  static int m48t86_rtc_proc(struct device *dev, struct seq_file *seq)
>  {
>  	unsigned char reg;
> -	struct platform_device *pdev = to_platform_device(dev);
> -	struct m48t86_ops *ops = pdev->dev.platform_data;
> +	struct m48t86_rtc_private_data *priv = dev_get_drvdata(dev);
>  
> -	reg = ops->readbyte(M48T86_REG_B);
> +	reg = m48t86_rtc_readbyte(priv, M48T86_REG_B);
>  
>  	seq_printf(seq, "mode\t\t: %s\n",
>  		 (reg & M48T86_REG_B_DM) ? "binary" : "bcd");
>  
> -	reg = ops->readbyte(M48T86_REG_D);
> +	reg = m48t86_rtc_readbyte(priv, M48T86_REG_D);
>  
>  	seq_printf(seq, "battery\t\t: %s\n",
>  		 (reg & M48T86_REG_D_VRT) ? "ok" : "exhausted");
> @@ -144,42 +165,159 @@ static const struct rtc_class_ops m48t86_rtc_ops = {
>  	.proc		= m48t86_rtc_proc,
>  };
>  
> -static int m48t86_rtc_probe(struct platform_device *dev)
> +/*
> + * The RTC chip has 114 bytes upper bytes that can be used as user storage
> + * space which we can use to test if the chip is present; for example it is
> + * an optional feature and not all boards will have it present.
> + *
> + * I've used the method Technologic Systems use in their rtc7800.c example
> + * for the detection.
> + *
> + * TODO: track down a guinea pig without an RTC to see if we can work out a
> + *		better RTC detection routine
> + */
> +static int m48t86_rtc_detect(struct device *dev)
> +{
> +	struct m48t86_rtc_private_data *priv = dev_get_drvdata(dev);
> +
> +	unsigned char tmp_rtc0, tmp_rtc1;
> +
> +	tmp_rtc0 = m48t86_rtc_readbyte(priv, 126);
> +	tmp_rtc1 = m48t86_rtc_readbyte(priv, 127);

These should probably have #defines, even if it is just something like:

  #define REG_SCRATCH_1 126
  #define REG_SCRATCH_2 127

> +
> +	m48t86_rtc_writebyte(priv, 0x00, 126);
> +	m48t86_rtc_writebyte(priv, 0x55, 127);
> +	if (m48t86_rtc_readbyte(priv, 127) == 0x55) {
> +		m48t86_rtc_writebyte(priv, 0xaa, 127);
> +		if (m48t86_rtc_readbyte(priv, 127) == 0xaa
> +				&& m48t86_rtc_readbyte(priv, 126) == 0x00) {
> +			m48t86_rtc_writebyte(priv, tmp_rtc0, 126);
> +			m48t86_rtc_writebyte(priv, tmp_rtc1, 127);
> +
> +			return 0;
> +		}
> +	}
> +
> +	dev_info(dev, "RTC not found\n");

Don't spam the log with stuff like this.

> +	return -ENODEV;
> +}
> +
> +static int m48t86_rtc_probe(struct platform_device *pdev)
>  {
> +	struct m48t86_rtc_private_data *priv;
> +	struct resource *res_index, *res_data;
>  	unsigned char reg;
> -	struct m48t86_ops *ops = dev->dev.platform_data;
> -	struct rtc_device *rtc = rtc_device_register("m48t86",
> -				&dev->dev, &m48t86_rtc_ops, THIS_MODULE);
> +	int err;
> +
> +	res_index = platform_get_resource_byname(
> +				pdev, IORESOURCE_MEM, "rtc_index");

Nitpick - please break lines like this:

	res_index = platform_get_resource_byname(pdev,
						 IO_RESOURCE_MEM,
                                                 "rtc_index");

You can use the double tab stop indent if you want, but please try to
fill the 80 columns before wrapping arguments onto the next line.


> +	if (!res_index)
> +		return -ENXIO;
> +	res_data = platform_get_resource_byname(
> +				pdev, IORESOURCE_MEM, "rtc_data");
> +	if (!res_data)
> +		return -ENXIO;
> +
> +	/* Allocate memory for the device structure (and zero it) */
> +	priv = kzalloc(sizeof(struct m48t86_rtc_private_data), GFP_KERNEL);
> +	if (!priv) {
> +		dev_err(&pdev->dev, "failed to allocate device structure.\n");

Don't need the warning. kalloc failures will automatically print a
warning and stacktrace.

> +		return -ENOMEM;
> +	}
> +
> +	if (!request_mem_region(res_index->start, resource_size(res_index),
> +				dev_name(&pdev->dev))) {
> +		dev_err(&pdev->dev, "request_mem_region failed\n");
> +		err = -EBUSY;
> +		goto out_free;
> +	}
> +	if (!request_mem_region(res_data->start, resource_size(res_data),
> +				dev_name(&pdev->dev))) {
> +		dev_err(&pdev->dev, "request_mem_region failed\n");
> +		err = -EBUSY;
> +		goto out_release_io_index;
> +	}
> +
> +	priv->io_index = ioremap(res_index->start, resource_size(res_index));
> +	if (priv->io_index == NULL) {
> +		dev_err(&pdev->dev, "ioremap failed\n");
> +		err = -EIO;
> +		goto out_release_io_data;
> +	}
> +	priv->io_data = ioremap(res_data->start, resource_size(res_data));
> +	if (priv->io_data == NULL) {
> +		dev_err(&pdev->dev, "ioremap failed\n");
> +		err = -EIO;
> +		goto out_ctrl;
> +	}
> +
> +	platform_set_drvdata(pdev, priv);
>  
> -	if (IS_ERR(rtc))
> -		return PTR_ERR(rtc);
> +	err = m48t86_rtc_detect(&pdev->dev);
> +	if (err)
> +		goto out;
>  
> -	platform_set_drvdata(dev, rtc);
> +	priv->rtc = rtc_device_register("m48t86",
> +				&pdev->dev, &m48t86_rtc_ops, THIS_MODULE);
> +	if (IS_ERR(priv->rtc)) {
> +		err = PTR_ERR(priv->rtc);
> +		goto out;
> +	}
>  
>  	/* read battery status */
> -	reg = ops->readbyte(M48T86_REG_D);
> -	dev_info(&dev->dev, "battery %s\n",
> +	reg = m48t86_rtc_readbyte(priv, M48T86_REG_D);
> +	dev_info(&pdev->dev, "battery %s\n",
>  		(reg & M48T86_REG_D_VRT) ? "ok" : "exhausted");
>  
>  	return 0;
> +
> +out:
> +	platform_set_drvdata(pdev, NULL);

I don't think this is needed.

> +	iounmap(priv->io_data);
> +out_ctrl:
> +	iounmap(priv->io_index);
> +out_release_io_data:
> +	release_mem_region(res_data->start, resource_size(res_data));
> +out_release_io_index:
> +	release_mem_region(res_index->start, resource_size(res_index));
> +out_free:
> +	kfree(priv);
> +	return err;
>  }
>  
> -static int m48t86_rtc_remove(struct platform_device *dev)
> +static int m48t86_rtc_remove(struct platform_device *pdev)
>  {
> -	struct rtc_device *rtc = platform_get_drvdata(dev);
> +	struct m48t86_rtc_private_data *priv = platform_get_drvdata(pdev);
> +	struct resource *res;
> +
> +	rtc_device_unregister(priv->rtc);
>  
> - 	if (rtc)
> -		rtc_device_unregister(rtc);
> +	platform_set_drvdata(pdev, NULL);
>  
> -	platform_set_drvdata(dev, NULL);
> +	iounmap(priv->io_data);
> +	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "rtc_data");
> +	release_mem_region(res->start, resource_size(res));
> +
> +	iounmap(priv->io_index);
> +	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "rtc_index");
> +	release_mem_region(res->start, resource_size(res));
> +
> +	kfree(priv);
>  
>  	return 0;
>  }
>  
> +static const struct of_device_id m48t86_rtc_match[] = {
> +	{ .compatible = "rtc-m48t86" },
> +	{},
> +};
> +MODULE_DEVICE_TABLE(of, m48t86_rtc_match);
> +
>  static struct platform_driver m48t86_rtc_platform_driver = {
>  	.driver		= {
> -		.name	= "rtc-m48t86",
> -		.owner	= THIS_MODULE,
> +		.name		= "rtc-m48t86",
> +		.owner		= THIS_MODULE,
> +		.of_match_table = m48t86_rtc_match,
>  	},
>  	.probe		= m48t86_rtc_probe,
>  	.remove		= m48t86_rtc_remove,
> diff --git a/include/linux/m48t86.h b/include/linux/m48t86.h
> deleted file mode 100644
> index 915d6b4..0000000
> --- a/include/linux/m48t86.h
> +++ /dev/null
> @@ -1,16 +0,0 @@
> -/*
> - * ST M48T86 / Dallas DS12887 RTC driver
> - * Copyright (c) 2006 Tower Technologies
> - *
> - * Author: Alessandro Zummo <a.zummo at towertech.it>
> - *
> - * 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.
> -*/
> -
> -struct m48t86_ops
> -{
> -	void (*writebyte)(unsigned char value, unsigned long addr);
> -	unsigned char (*readbyte)(unsigned long addr);
> -};
> 



From sergei.shtylyov at cogentembedded.com  Mon Apr  1 18:06:51 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Tue, 2 Apr 2013 02:06:51 +0400
Subject: [PATCH 2/2] ARM: shmobile: R8A7778: add Ether support
Message-ID: <201304020206.52313.sergei.shtylyov@cogentembedded.com>

Add Ether clock and platform device for R8A7778 SoC; add a function to register
this device with board-specific platform data.

Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

---
This patch is atop of the 'next' branch of Simon Horman's renesas.git.

 arch/arm/mach-shmobile/clock-r8a7778.c        |    3 +++
 arch/arm/mach-shmobile/include/mach/r8a7778.h |    1 +
 arch/arm/mach-shmobile/setup-r8a7778.c        |   21 +++++++++++++++++++++
 3 files changed, 25 insertions(+)

Index: renesas/arch/arm/mach-shmobile/clock-r8a7778.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/clock-r8a7778.c
+++ renesas/arch/arm/mach-shmobile/clock-r8a7778.c
@@ -58,11 +58,13 @@ static struct clk *main_clks[] = {
 };
 
 enum {
+	MSTP114,
 	MSTP026, MSTP025, MSTP024, MSTP023, MSTP022, MSTP021,
 	MSTP016, MSTP015,
 	MSTP_NR };
 
 static struct clk mstp_clks[MSTP_NR] = {
+	[MSTP114] = SH_CLK_MSTP32(&clkp, MSTPCR1, 14, 0), /* Ether */
 	[MSTP026] = SH_CLK_MSTP32(&clkp, MSTPCR0, 26, 0), /* SCIF0 */
 	[MSTP025] = SH_CLK_MSTP32(&clkp, MSTPCR0, 25, 0), /* SCIF1 */
 	[MSTP024] = SH_CLK_MSTP32(&clkp, MSTPCR0, 24, 0), /* SCIF2 */
@@ -75,6 +77,7 @@ static struct clk mstp_clks[MSTP_NR] = {
 
 static struct clk_lookup lookups[] = {
 	/* MSTP32 clocks */
+	CLKDEV_DEV_ID("sh-eth",	&mstp_clks[MSTP114]), /* Ether */
 	CLKDEV_DEV_ID("sh-sci.0", &mstp_clks[MSTP026]), /* SCIF0 */
 	CLKDEV_DEV_ID("sh-sci.1", &mstp_clks[MSTP025]), /* SCIF1 */
 	CLKDEV_DEV_ID("sh-sci.2", &mstp_clks[MSTP024]), /* SCIF2 */
Index: renesas/arch/arm/mach-shmobile/include/mach/r8a7778.h
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/include/mach/r8a7778.h
+++ renesas/arch/arm/mach-shmobile/include/mach/r8a7778.h
@@ -20,6 +20,7 @@
 
 extern void r8a7778_add_standard_devices(void);
 extern void r8a7778_add_standard_devices_dt(void);
+extern void r8a7778_add_ether_device(void *pdata);
 extern void r8a7778_init_delay(void);
 extern void r8a7778_init_irq(void);
 extern void r8a7778_init_irq_dt(void);
Index: renesas/arch/arm/mach-shmobile/setup-r8a7778.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/setup-r8a7778.c
+++ renesas/arch/arm/mach-shmobile/setup-r8a7778.c
@@ -3,6 +3,7 @@
  *
  * Copyright (C) 2013  Renesas Solutions Corp.
  * Copyright (C) 2013  Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
+ * Copyright (C) 2013  Cogent Embedded, Inc.
  *
  * 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
@@ -78,6 +79,19 @@ static struct sh_timer_config sh_tmu1_pl
 	.clocksource_rating	= 200,
 };
 
+/* Ether */
+static struct resource ether_resources[] = {
+	DEFINE_RES_MEM(0xfde00000, 0x400),
+	DEFINE_RES_IRQ(gic_iid(0x89)),
+};
+
+static struct platform_device ether_device = {
+	.name		= "sh-eth",
+	.id		= -1,
+	.resource	= ether_resources,
+	.num_resources	= ARRAY_SIZE(ether_resources),
+};
+
 #define PLATFORM_INFO(n, i)					\
 {								\
 	.parent		= &platform_bus,			\
@@ -118,6 +132,13 @@ void __init r8a7778_add_standard_devices
 		platform_device_register_full(&platform_devinfo[i]);
 }
 
+void __init r8a7778_add_ether_device(void *pdata)
+{
+	ether_device.dev.platform_data = pdata;
+
+	platform_device_register(&ether_device);
+}
+
 #define INT2SMSKCR0	0x82288 /* 0xfe782288 */
 #define INT2SMSKCR1	0x8228c /* 0xfe78228c */
 


From rmallon at gmail.com  Mon Apr  1 18:12:02 2013
From: rmallon at gmail.com (Ryan Mallon)
Date: Tue, 02 Apr 2013 09:12:02 +1100
Subject: [PATCH 0/3] add devicetree bindings for rtc-m48t86
In-Reply-To: <5159FFAA.5030205@gmail.com>
References: <1364766971-5914-1-git-send-email-alex@digriz.org.uk>
 <5159FFAA.5030205@gmail.com>
Message-ID: <515A0632.3040902@gmail.com>

On 02/04/13 08:44, Ryan Mallon wrote:
> On 01/04/13 08:56, Alexander Clouter wrote:
>> Currently there are two users of rtc-m48t86 (mach-ep93xx/ts72xx.c and
>> mach-orion5x/ts78xx-setup.c) and both just use {read,write}b against
>> a memory mapped region.  As I am devicetree'ing the TS-7800, this
>> driver needs converting and thats what this patchset does.
>>
>> The patch does the following:
>>  * remove platform specific ops hooks, moving ioremap'ing and
>> 	everything into the driver
>>  * utilises named resources to indicate index/data ranges
>>  * moves the RTC detection routine from ts78xx-setup.c into rtc-m48t86.c
>>  * and, of course, enable devicetree hooks and include documentation
>>
>> Awkward step, the first patch breaks both boards, the two following
>> patches fix them.  Happy to re-work this if folks give me a pointer
>> on how to do this in an acceptable way.
> 
> Sorry, that's no good. It breaks things like git bisect.
> 
>>
>> My vote is to break fast, fix fast, spend the time writing other code :)
> 
> The patch series will need to be reworked so that there is no
> build/runtime breakage between any of the patches. I'll have a read
> through and see if I can suggest something.

So looking through the patches, you are going to need to modify the rtc
driver and the platform code in the same patch at least once since you
are changing the interface. You could break the patches down like this:

1) Move the rtc detection from the orion5x board to the rtc driver.
   This adds the detection support for the ep93xx board also.

2) Replace the board read/write ops structure with ioremapped regions.

3) Add the device tree bindings to the rtc driver.

The first two patches could be combined, but will touch both the rtc
driver and the platform code, and do the prep work needed for adding the
dt bindings. The third patch can then stand on its own, and more clearly
just adds the dt bindings.

~Ryan



From davidb at codeaurora.org  Mon Apr  1 18:17:50 2013
From: davidb at codeaurora.org (David Brown)
Date: Mon, 01 Apr 2013 15:17:50 -0700
Subject: [PATCH v3 6/7] USB: EHCI: make ehci-msm a separate driver
In-Reply-To: <201303301249.09239.arnd@arndb.de> (Arnd Bergmann's message of
 "Sat, 30 Mar 2013 12:49:09 +0000")
References: <Pine.LNX.4.44L0.1303291607090.1467-100000@iolanthe.rowland.org>
 <201303301249.09239.arnd@arndb.de>
Message-ID: <8yahajp3ng1.fsf@huya.qualcomm.com>

Arnd Bergmann <arnd at arndb.de> writes:

> On Friday 29 March 2013, Alan Stern wrote:
>> On Thu, 28 Mar 2013, Arnd Bergmann wrote:
>
>> This patch is good.  However the ehci-msm driver itself is not.  While
>> checking through the code, I was struck by the fact that it never calls
>> usb_add_hcd() or usb_remove_hcd().  Obviously the driver cannot work
>> properly.
>> 
>> In addition, it stores the PHY pointer in a global variable.  
>> (ehci-atmel does much the same thing for its clocks.)  This means the
>> driver cannot be used on a system having more than one EHCI controller.  
>> Maybe this doesn't matter, though.
>> 
>> Maybe somebody would like to fix and test it...
>
> I'm not too surprised. The driver was added the last time that the MSM
> maintainers started a serious attempt to get a lot of their code mainlined,
> a little over two years ago. While there is some activity from Qualcomm
> in specific areas of the code every now and then, they literally have
> thousands of patches on top of the kernel that they use in actual
> products and I would not expect a mainline kernel to actually work on
> any recent Qualcomm hardware.

As far as this patch goes, you can have an
  Acked-by: David Brown <davidb at codeaurora.org>
for it.

I'm hoping things are going to get better as far as people working on
things.  EHCI is definitely an important one to get working (as is SD),
but we've got to get clocks and regulators working first.

David


-- 
sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation


From robherring2 at gmail.com  Mon Apr  1 18:21:11 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Mon,  1 Apr 2013 17:21:11 -0500
Subject: [PATCH v2 01/13] ARM: make machine_desc->init_time default to
 clocksource_of_init
In-Reply-To: <1364854883-5961-1-git-send-email-robherring2@gmail.com>
References: <1364854883-5961-1-git-send-email-robherring2@gmail.com>
Message-ID: <1364854883-5961-2-git-send-email-robherring2@gmail.com>

From: Arnd Bergmann <arnd at arndb.de>

Originally from a default machine descriptor patch from Arnd, pull out
just the default call to clocksource_of_init part. This is needed so that
platforms can simply remove .init_time calls as they are converted to use
clocksource_of_init.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Acked-by: Nicolas Pitre <nico at linaro.org>
Acked-by: Olof Johansson <olof at lixom.net>
Signed-off-by: Rob Herring <rob.herring at calxeda.com>
---
 arch/arm/kernel/time.c |    7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/arch/arm/kernel/time.c b/arch/arm/kernel/time.c
index 955d92d..abff4e9 100644
--- a/arch/arm/kernel/time.c
+++ b/arch/arm/kernel/time.c
@@ -22,6 +22,7 @@
 #include <linux/errno.h>
 #include <linux/profile.h>
 #include <linux/timer.h>
+#include <linux/clocksource.h>
 #include <linux/irq.h>
 
 #include <asm/thread_info.h>
@@ -115,6 +116,10 @@ int __init register_persistent_clock(clock_access_fn read_boot,
 
 void __init time_init(void)
 {
-	machine_desc->init_time();
+	if (machine_desc->init_time)
+		machine_desc->init_time();
+	else
+		clocksource_of_init();
+
 	sched_clock_postinit();
 }
-- 
1.7.10.4



From robherring2 at gmail.com  Mon Apr  1 18:21:10 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Mon,  1 Apr 2013 17:21:10 -0500
Subject: [PATCH v2 00/13] ARM arch,
 sp804 and integrator timer CLKSRC_OF support
Message-ID: <1364854883-5961-1-git-send-email-robherring2@gmail.com>

From: Rob Herring <rob.herring at calxeda.com>

This series add device-tree support using CLKSRC_OF for initialization
of arm/arm64 architected timers, integrator ap and cp timers, and sp804
timers. The timer code for integrator and sp804 is moved to
drivers/clocksource. The common DT based initialization of sp804 is
supported on highbank, versatile-ab and vexpress. The DT init support is
newly added for versatile-ab.

This series is dependent on my CLKSRC_OF clean-up in arm-soc and my
sched_clock selection series[1]. The full series is available here:

git://sources.calxeda.com/kernel/linux.git arm-timers
http://sources.calxeda.com/gitweb/?p=kernel/linux.git;a=shortlog;h=refs/heads/arm-timers

Changes in v2:
- Rework sp804 init to be more readable as to which timer is initialized
  for which function (clksrc or clkevt).
- Drop patch removing TIMER_CTRL clearing which is still needed for non-DT
  init cases.
- Add TIMER_CTRL to DT init functions. Even if the timer is unused as
  clksrc or clkevt, it is disabled.
- Extract only clocksource_of_init call from Arnd's default machine desc
  patch

Rob

[1] http://www.spinics.net/lists/arm-kernel/msg234566.html


Arnd Bergmann (1):
  ARM: make machine_desc->init_time default to clocksource_of_init

Haojian Zhuang (1):
  devtree: add binding documentation for sp804

Rob Herring (11):
  ARM: convert arm/arm64 arch timer to use CLKSRC_OF init
  OF: add empty of_device_is_available for !OF
  ARM: timer-sp: convert to use CLKSRC_OF init
  ARM: highbank: use OF init for sp804 timer
  ARM: vexpress: remove sp804 OF init
  ARM: dts: vexpress: disable CA9 core tile sp804 timer
  ARM: vexpress: remove extra timer-sp control register clearing
  ARM: versatile: add versatile dtbs to dtbs target
  ARM: versatile: use OF init for sp804 timer
  ARM: integrator-cp: convert use CLKSRC_OF for timer init
  ARM: move sp804 and integrator timers to drivers/clocksource

 .../devicetree/bindings/timer/arm,sp804.txt        |   29 +++
 arch/arm/Kconfig                                   |    5 -
 arch/arm/boot/dts/Makefile                         |    2 +
 arch/arm/boot/dts/integratorcp.dts                 |    6 +-
 arch/arm/boot/dts/versatile-ab.dts                 |   12 ++
 arch/arm/boot/dts/vexpress-v2p-ca9.dts             |    1 +
 arch/arm/common/Makefile                           |    1 -
 arch/arm/include/asm/arch_timer.h                  |   13 +-
 arch/arm/include/asm/hardware/timer-sp.h           |   15 --
 arch/arm/kernel/arch_timer.c                       |   17 +-
 arch/arm/kernel/time.c                             |    7 +-
 arch/arm/mach-exynos/mach-exynos5-dt.c             |    1 -
 arch/arm/mach-exynos/mct.c                         |    6 -
 arch/arm/mach-highbank/highbank.c                  |   24 +--
 arch/arm/mach-integrator/Kconfig                   |    1 +
 arch/arm/mach-integrator/integrator_ap.c           |  170 +-----------------
 arch/arm/mach-integrator/integrator_cp.c           |   39 +---
 arch/arm/mach-omap2/timer.c                        |    5 +-
 arch/arm/mach-realview/core.c                      |    5 +-
 arch/arm/mach-shmobile/board-kzm9d.c               |    1 -
 arch/arm/mach-shmobile/include/mach/common.h       |    1 -
 arch/arm/mach-shmobile/setup-emev2.c               |    1 -
 arch/arm/mach-shmobile/setup-r8a7740.c             |    1 -
 arch/arm/mach-shmobile/setup-sh7372.c              |    1 -
 arch/arm/mach-shmobile/setup-sh73a0.c              |    1 -
 arch/arm/mach-shmobile/timer.c                     |    6 -
 arch/arm/mach-versatile/core.c                     |   30 ++--
 arch/arm/mach-versatile/versatile_dt.c             |    1 -
 arch/arm/mach-vexpress/ct-ca9x4.c                  |    4 +-
 arch/arm/mach-vexpress/v2m.c                       |   25 +--
 arch/arm/mach-virt/virt.c                          |    9 -
 arch/arm64/include/asm/arch_timer.h                |    5 +
 arch/arm64/kernel/time.c                           |    6 +-
 drivers/clocksource/Kconfig                        |   13 ++
 drivers/clocksource/Makefile                       |    2 +
 drivers/clocksource/arm_arch_timer.c               |   23 +--
 drivers/clocksource/integrator_ap_timer.c          |  189 ++++++++++++++++++++
 .../arm/common => drivers/clocksource}/timer-sp.c  |  144 +++++++++++++--
 include/clocksource/arm_arch_timer.h               |    6 -
 .../hardware => include/clocksource}/arm_timer.h   |    4 +-
 include/clocksource/integrator_ap_timer.h          |    7 +
 include/clocksource/timer-sp.h                     |   23 +++
 include/linux/of.h                                 |    5 +
 43 files changed, 470 insertions(+), 397 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/timer/arm,sp804.txt
 delete mode 100644 arch/arm/include/asm/hardware/timer-sp.h
 create mode 100644 drivers/clocksource/integrator_ap_timer.c
 rename {arch/arm/common => drivers/clocksource}/timer-sp.c (58%)
 rename {arch/arm/include/asm/hardware => include/clocksource}/arm_timer.h (93%)
 create mode 100644 include/clocksource/integrator_ap_timer.h
 create mode 100644 include/clocksource/timer-sp.h

-- 
1.7.10.4



From robherring2 at gmail.com  Mon Apr  1 18:21:13 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Mon,  1 Apr 2013 17:21:13 -0500
Subject: [PATCH v2 03/13] OF: add empty of_device_is_available for !OF
In-Reply-To: <1364854883-5961-1-git-send-email-robherring2@gmail.com>
References: <1364854883-5961-1-git-send-email-robherring2@gmail.com>
Message-ID: <1364854883-5961-4-git-send-email-robherring2@gmail.com>

From: Rob Herring <rob.herring at calxeda.com>

Add an empty version of of_device_is_available.

Signed-off-by: Rob Herring <rob.herring at calxeda.com>
---
 include/linux/of.h |    5 +++++
 1 file changed, 5 insertions(+)

diff --git a/include/linux/of.h b/include/linux/of.h
index a0f1292..95c8583 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -379,6 +379,11 @@ static inline int of_device_is_compatible(const struct device_node *device,
 	return 0;
 }
 
+static inline int of_device_is_available(const struct device_node *device)
+{
+	return 0;
+}
+
 static inline struct property *of_find_property(const struct device_node *np,
 						const char *name,
 						int *lenp)
-- 
1.7.10.4



From robherring2 at gmail.com  Mon Apr  1 18:21:14 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Mon,  1 Apr 2013 17:21:14 -0500
Subject: [PATCH v2 04/13] ARM: timer-sp: convert to use CLKSRC_OF init
In-Reply-To: <1364854883-5961-1-git-send-email-robherring2@gmail.com>
References: <1364854883-5961-1-git-send-email-robherring2@gmail.com>
Message-ID: <1364854883-5961-5-git-send-email-robherring2@gmail.com>

From: Rob Herring <rob.herring at calxeda.com>

This adds CLKSRC_OF based init for sp804 timer. The clock initialization is
refactored to support retrieving the clock(s) from the DT.

Signed-off-by: Rob Herring <rob.herring at calxeda.com>
---
 arch/arm/Kconfig                         |    1 +
 arch/arm/common/timer-sp.c               |  105 +++++++++++++++++++++++++-----
 arch/arm/include/asm/hardware/timer-sp.h |   16 +++--
 3 files changed, 102 insertions(+), 20 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 5bfd584..10e3053 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1173,6 +1173,7 @@ config PLAT_VERSATILE
 config ARM_TIMER_SP804
 	bool
 	select CLKSRC_MMIO
+	select CLKSRC_OF if OF
 	select HAVE_SCHED_CLOCK
 
 source arch/arm/mm/Kconfig
diff --git a/arch/arm/common/timer-sp.c b/arch/arm/common/timer-sp.c
index 9d2d3ba..ded926f 100644
--- a/arch/arm/common/timer-sp.c
+++ b/arch/arm/common/timer-sp.c
@@ -25,33 +25,28 @@
 #include <linux/interrupt.h>
 #include <linux/irq.h>
 #include <linux/io.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
 
 #include <asm/sched_clock.h>
 #include <asm/hardware/arm_timer.h>
 
-static long __init sp804_get_clock_rate(const char *name)
+static long __init sp804_get_clock_rate(struct clk *clk)
 {
-	struct clk *clk;
 	long rate;
 	int err;
 
-	clk = clk_get_sys("sp804", name);
-	if (IS_ERR(clk)) {
-		pr_err("sp804: %s clock not found: %d\n", name,
-			(int)PTR_ERR(clk));
-		return PTR_ERR(clk);
-	}
-
 	err = clk_prepare(clk);
 	if (err) {
-		pr_err("sp804: %s clock failed to prepare: %d\n", name, err);
+		pr_err("sp804: clock failed to prepare: %d\n", err);
 		clk_put(clk);
 		return err;
 	}
 
 	err = clk_enable(clk);
 	if (err) {
-		pr_err("sp804: %s clock failed to enable: %d\n", name, err);
+		pr_err("sp804: clock failed to enable: %d\n", err);
 		clk_unprepare(clk);
 		clk_put(clk);
 		return err;
@@ -59,7 +54,7 @@ static long __init sp804_get_clock_rate(const char *name)
 
 	rate = clk_get_rate(clk);
 	if (rate < 0) {
-		pr_err("sp804: %s clock failed to get rate: %ld\n", name, rate);
+		pr_err("sp804: clock failed to get rate: %ld\n", rate);
 		clk_disable(clk);
 		clk_unprepare(clk);
 		clk_put(clk);
@@ -77,9 +72,21 @@ static u32 sp804_read(void)
 
 void __init __sp804_clocksource_and_sched_clock_init(void __iomem *base,
 						     const char *name,
+						     struct clk *clk,
 						     int use_sched_clock)
 {
-	long rate = sp804_get_clock_rate(name);
+	long rate;
+
+	if (!clk) {
+		clk = clk_get_sys("sp804", name);
+		if (IS_ERR(clk)) {
+			pr_err("sp804: clock not found: %d\n",
+			       (int)PTR_ERR(clk));
+			return;
+		}
+	}
+
+	rate = sp804_get_clock_rate(clk);
 
 	if (rate < 0)
 		return;
@@ -171,12 +178,20 @@ static struct irqaction sp804_timer_irq = {
 	.dev_id		= &sp804_clockevent,
 };
 
-void __init sp804_clockevents_init(void __iomem *base, unsigned int irq,
-	const char *name)
+void __init __sp804_clockevents_init(void __iomem *base, unsigned int irq, struct clk *clk, const char *name)
 {
 	struct clock_event_device *evt = &sp804_clockevent;
-	long rate = sp804_get_clock_rate(name);
+	long rate;
+
+	if (!clk)
+		clk = clk_get_sys("sp804", name);
+	if (IS_ERR(clk)) {
+		pr_err("sp804: %s clock not found: %d\n", name,
+			(int)PTR_ERR(clk));
+		return;
+	}
 
+	rate = sp804_get_clock_rate(clk);
 	if (rate < 0)
 		return;
 
@@ -186,6 +201,64 @@ void __init sp804_clockevents_init(void __iomem *base, unsigned int irq,
 	evt->irq = irq;
 	evt->cpumask = cpu_possible_mask;
 
+	writel(0, base + TIMER_CTRL);
+
 	setup_irq(irq, &sp804_timer_irq);
 	clockevents_config_and_register(evt, rate, 0xf, 0xffffffff);
 }
+
+static void __init sp804_of_init(struct device_node *np)
+{
+	static bool initialized = false;
+	void __iomem *base;
+	int irq;
+	u32 irq_num = 0;
+	struct clk *clk1, *clk2;
+	const char *name = of_get_property(np, "compatible", NULL);
+
+	base = of_iomap(np, 0);
+	if (WARN_ON(!base))
+		return;
+
+	/* Ensure timers are disabled */
+	writel(0, base + TIMER_CTRL);
+	writel(0, base + TIMER_2_BASE + TIMER_CTRL);
+
+	if (initialized || !of_device_is_available(np))
+		goto err;
+
+	clk1 = of_clk_get(np, 0);
+	if (IS_ERR(clk1))
+		clk1 = NULL;
+
+	/* Get the 2nd clock if the timer has 2 timer clocks */
+	if (of_count_phandle_with_args(np, "clocks", "#clock-cells") == 3) {
+		clk2 = of_clk_get(np, 1);
+		if (IS_ERR(clk2)) {
+			pr_err("sp804: %s clock not found: %d\n", np->name,
+				(int)PTR_ERR(clk2));
+			goto err;
+		}
+	} else
+		clk2 = clk1;
+
+	irq = irq_of_parse_and_map(np, 0);
+	if (irq <= 0)
+		goto err;
+
+	of_property_read_u32(np, "arm,sp804-has-irq", &irq_num);
+	if (irq_num == 2) {
+		__sp804_clockevents_init(base + TIMER_2_BASE, irq, clk2, name);
+		__sp804_clocksource_and_sched_clock_init(base, name, clk1, 1);
+	} else {
+		__sp804_clockevents_init(base, irq, clk1 , name);
+		__sp804_clocksource_and_sched_clock_init(base + TIMER_2_BASE,
+							 name, clk2, 1);
+	}
+	initialized = true;
+
+	return;
+err:
+	iounmap(base);
+}
+CLOCKSOURCE_OF_DECLARE(sp804, "arm,sp804", sp804_of_init);
diff --git a/arch/arm/include/asm/hardware/timer-sp.h b/arch/arm/include/asm/hardware/timer-sp.h
index 2dd9d3f..bb28af7 100644
--- a/arch/arm/include/asm/hardware/timer-sp.h
+++ b/arch/arm/include/asm/hardware/timer-sp.h
@@ -1,15 +1,23 @@
+struct clk;
+
 void __sp804_clocksource_and_sched_clock_init(void __iomem *,
-					      const char *, int);
+					      const char *, struct clk *, int);
+void __sp804_clockevents_init(void __iomem *, unsigned int,
+			      struct clk *, const char *);
 
 static inline void sp804_clocksource_init(void __iomem *base, const char *name)
 {
-	__sp804_clocksource_and_sched_clock_init(base, name, 0);
+	__sp804_clocksource_and_sched_clock_init(base, name, NULL, 0);
 }
 
 static inline void sp804_clocksource_and_sched_clock_init(void __iomem *base,
 							  const char *name)
 {
-	__sp804_clocksource_and_sched_clock_init(base, name, 1);
+	__sp804_clocksource_and_sched_clock_init(base, name, NULL, 1);
 }
 
-void sp804_clockevents_init(void __iomem *, unsigned int, const char *);
+static inline void sp804_clockevents_init(void __iomem *base, unsigned int irq, const char *name)
+{
+	__sp804_clockevents_init(base, irq, NULL, name);
+
+}
-- 
1.7.10.4



From robherring2 at gmail.com  Mon Apr  1 18:21:12 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Mon,  1 Apr 2013 17:21:12 -0500
Subject: [PATCH v2 02/13] ARM: convert arm/arm64 arch timer to use CLKSRC_OF
 init
In-Reply-To: <1364854883-5961-1-git-send-email-robherring2@gmail.com>
References: <1364854883-5961-1-git-send-email-robherring2@gmail.com>
Message-ID: <1364854883-5961-3-git-send-email-robherring2@gmail.com>

From: Rob Herring <rob.herring at calxeda.com>

This converts arm and arm64 to use CLKSRC_OF DT based initialization for
the arch timer. A new function arch_timer_arch_init is added to allow for
arch specific setup.

This has a side effect of enabling sched_clock on omap5 and exynos5. There
should not be any reason not to use the arch timers for sched_clock.

Signed-off-by: Rob Herring <rob.herring at calxeda.com>
Cc: Russell King <linux at arm.linux.org.uk>
Cc: Kukjin Kim <kgene.kim at samsung.com>
Cc: Tony Lindgren <tony at atomide.com>
Cc: Simon Horman <horms at verge.net.au>
Cc: Magnus Damm <magnus.damm at gmail.com>
Cc: Catalin Marinas <catalin.marinas at arm.com>
Cc: Will Deacon <will.deacon at arm.com>
Cc: John Stultz <john.stultz at linaro.org>
Cc: Thomas Gleixner <tglx at linutronix.de>
Cc: linux-samsung-soc at vger.kernel.org
Cc: linux-omap at vger.kernel.org
Cc: linux-sh at vger.kernel.org
---
 arch/arm/include/asm/arch_timer.h            |   13 +------------
 arch/arm/kernel/arch_timer.c                 |   17 +++--------------
 arch/arm/mach-exynos/mach-exynos5-dt.c       |    1 -
 arch/arm/mach-exynos/mct.c                   |    6 ------
 arch/arm/mach-highbank/highbank.c            |    5 +----
 arch/arm/mach-omap2/timer.c                  |    5 +----
 arch/arm/mach-shmobile/board-kzm9d.c         |    1 -
 arch/arm/mach-shmobile/include/mach/common.h |    1 -
 arch/arm/mach-shmobile/setup-emev2.c         |    1 -
 arch/arm/mach-shmobile/setup-r8a7740.c       |    1 -
 arch/arm/mach-shmobile/setup-sh7372.c        |    1 -
 arch/arm/mach-shmobile/setup-sh73a0.c        |    1 -
 arch/arm/mach-shmobile/timer.c               |    6 ------
 arch/arm/mach-vexpress/v2m.c                 |    7 ++-----
 arch/arm/mach-virt/virt.c                    |    9 ---------
 arch/arm64/include/asm/arch_timer.h          |    5 +++++
 arch/arm64/kernel/time.c                     |    6 ++++--
 drivers/clocksource/Kconfig                  |    1 +
 drivers/clocksource/arm_arch_timer.c         |   23 +++++++++--------------
 include/clocksource/arm_arch_timer.h         |    6 ------
 20 files changed, 27 insertions(+), 89 deletions(-)

diff --git a/arch/arm/include/asm/arch_timer.h b/arch/arm/include/asm/arch_timer.h
index 7ade91d..7c1bfc0 100644
--- a/arch/arm/include/asm/arch_timer.h
+++ b/arch/arm/include/asm/arch_timer.h
@@ -10,8 +10,7 @@
 #include <clocksource/arm_arch_timer.h>
 
 #ifdef CONFIG_ARM_ARCH_TIMER
-int arch_timer_of_register(void);
-int arch_timer_sched_clock_init(void);
+int arch_timer_arch_init(void);
 
 /*
  * These register accessors are marked inline so the compiler can
@@ -110,16 +109,6 @@ static inline void __cpuinit arch_counter_set_user_access(void)
 
 	asm volatile("mcr p15, 0, %0, c14, c1, 0" : : "r" (cntkctl));
 }
-#else
-static inline int arch_timer_of_register(void)
-{
-	return -ENXIO;
-}
-
-static inline int arch_timer_sched_clock_init(void)
-{
-	return -ENXIO;
-}
 #endif
 
 #endif
diff --git a/arch/arm/kernel/arch_timer.c b/arch/arm/kernel/arch_timer.c
index a7536d4..dc74048 100644
--- a/arch/arm/kernel/arch_timer.c
+++ b/arch/arm/kernel/arch_timer.c
@@ -39,26 +39,15 @@ static void __init arch_timer_delay_timer_register(void)
 	register_current_timer_delay(&arch_delay_timer);
 }
 
-int __init arch_timer_of_register(void)
-{
-	int ret;
-
-	ret = arch_timer_init();
-	if (ret)
-		return ret;
-
-	arch_timer_delay_timer_register();
-
-	return 0;
-}
-
-int __init arch_timer_sched_clock_init(void)
+int __init arch_timer_arch_init(void)
 {
         u32 arch_timer_rate = arch_timer_get_rate();
 
 	if (arch_timer_rate == 0)
 		return -ENXIO;
 
+	arch_timer_delay_timer_register();
+
 	/* Cache the sched_clock multiplier to save a divide in the hot path. */
 	sched_clock_mult = NSEC_PER_SEC / arch_timer_rate;
 	sched_clock_func = arch_timer_sched_clock;
diff --git a/arch/arm/mach-exynos/mach-exynos5-dt.c b/arch/arm/mach-exynos/mach-exynos5-dt.c
index acaeb14..4d97b43 100644
--- a/arch/arm/mach-exynos/mach-exynos5-dt.c
+++ b/arch/arm/mach-exynos/mach-exynos5-dt.c
@@ -216,7 +216,6 @@ DT_MACHINE_START(EXYNOS5_DT, "SAMSUNG EXYNOS5 (Flattened Device Tree)")
 	.map_io		= exynos5_dt_map_io,
 	.init_machine	= exynos5_dt_machine_init,
 	.init_late	= exynos_init_late,
-	.init_time	= exynos4_timer_init,
 	.dt_compat	= exynos5_dt_compat,
 	.restart        = exynos5_restart,
 	.reserve	= exynos5_reserve,
diff --git a/arch/arm/mach-exynos/mct.c b/arch/arm/mach-exynos/mct.c
index c9d6650..04aff6a 100644
--- a/arch/arm/mach-exynos/mct.c
+++ b/arch/arm/mach-exynos/mct.c
@@ -21,7 +21,6 @@
 #include <linux/percpu.h>
 #include <linux/of.h>
 
-#include <asm/arch_timer.h>
 #include <asm/localtimer.h>
 
 #include <plat/cpu.h>
@@ -469,11 +468,6 @@ static void __init exynos4_timer_resources(void)
 
 void __init exynos4_timer_init(void)
 {
-	if (soc_is_exynos5440()) {
-		arch_timer_of_register();
-		return;
-	}
-
 	if ((soc_is_exynos4210()) || (soc_is_exynos5250()))
 		mct_int_type = MCT_INT_SPI;
 	else
diff --git a/arch/arm/mach-highbank/highbank.c b/arch/arm/mach-highbank/highbank.c
index 76c1170..758150e 100644
--- a/arch/arm/mach-highbank/highbank.c
+++ b/arch/arm/mach-highbank/highbank.c
@@ -15,6 +15,7 @@
  */
 #include <linux/clk.h>
 #include <linux/clkdev.h>
+#include <linux/clocksource.h>
 #include <linux/dma-mapping.h>
 #include <linux/io.h>
 #include <linux/irq.h>
@@ -28,7 +29,6 @@
 #include <linux/amba/bus.h>
 #include <linux/clk-provider.h>
 
-#include <asm/arch_timer.h>
 #include <asm/cacheflush.h>
 #include <asm/cputype.h>
 #include <asm/smp_plat.h>
@@ -118,9 +118,6 @@ static void __init highbank_timer_init(void)
 	sp804_clocksource_and_sched_clock_init(timer_base + 0x20, "timer1");
 	sp804_clockevents_init(timer_base, irq, "timer0");
 
-	arch_timer_of_register();
-	arch_timer_sched_clock_init();
-
 	clocksource_of_init();
 }
 
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 4fd8025..7dd6453 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -46,7 +46,6 @@
 #include <asm/smp_twd.h>
 #include <asm/sched_clock.h>
 
-#include <asm/arch_timer.h>
 #include "omap_hwmod.h"
 #include "omap_device.h"
 #include <plat/counter-32k.h>
@@ -624,9 +623,7 @@ void __init omap5_realtime_timer_init(void)
 	omap5_sync32k_timer_init();
 	realtime_counter_init();
 
-	err = arch_timer_of_register();
-	if (err)
-		pr_err("%s: arch_timer_register failed %d\n", __func__, err);
+        clocksource_of_init();
 }
 #endif /* CONFIG_SOC_OMAP5 */
 
diff --git a/arch/arm/mach-shmobile/board-kzm9d.c b/arch/arm/mach-shmobile/board-kzm9d.c
index c254782..c016ccd 100644
--- a/arch/arm/mach-shmobile/board-kzm9d.c
+++ b/arch/arm/mach-shmobile/board-kzm9d.c
@@ -90,6 +90,5 @@ DT_MACHINE_START(KZM9D_DT, "kzm9d")
 	.init_irq	= emev2_init_irq,
 	.init_machine	= kzm9d_add_standard_devices,
 	.init_late	= shmobile_init_late,
-	.init_time	= shmobile_timer_init,
 	.dt_compat	= kzm9d_boards_compat_dt,
 MACHINE_END
diff --git a/arch/arm/mach-shmobile/include/mach/common.h b/arch/arm/mach-shmobile/include/mach/common.h
index e48606d..5efc0f0 100644
--- a/arch/arm/mach-shmobile/include/mach/common.h
+++ b/arch/arm/mach-shmobile/include/mach/common.h
@@ -2,7 +2,6 @@
 #define __ARCH_MACH_COMMON_H
 
 extern void shmobile_earlytimer_init(void);
-extern void shmobile_timer_init(void);
 extern void shmobile_setup_delay(unsigned int max_cpu_core_mhz,
 			 unsigned int mult, unsigned int div);
 struct twd_local_timer;
diff --git a/arch/arm/mach-shmobile/setup-emev2.c b/arch/arm/mach-shmobile/setup-emev2.c
index 47662a5..4e38a66 100644
--- a/arch/arm/mach-shmobile/setup-emev2.c
+++ b/arch/arm/mach-shmobile/setup-emev2.c
@@ -456,7 +456,6 @@ DT_MACHINE_START(EMEV2_DT, "Generic Emma Mobile EV2 (Flattened Device Tree)")
 	.nr_irqs	= NR_IRQS_LEGACY,
 	.init_irq	= irqchip_init,
 	.init_machine	= emev2_add_standard_devices_dt,
-	.init_time	= shmobile_timer_init,
 	.dt_compat	= emev2_boards_compat_dt,
 MACHINE_END
 
diff --git a/arch/arm/mach-shmobile/setup-r8a7740.c b/arch/arm/mach-shmobile/setup-r8a7740.c
index 8b85d4d..104b474 100644
--- a/arch/arm/mach-shmobile/setup-r8a7740.c
+++ b/arch/arm/mach-shmobile/setup-r8a7740.c
@@ -906,7 +906,6 @@ DT_MACHINE_START(R8A7740_DT, "Generic R8A7740 (Flattened Device Tree)")
 	.init_irq	= r8a7740_init_irq,
 	.handle_irq	= shmobile_handle_irq_intc,
 	.init_machine	= r8a7740_add_standard_devices_dt,
-	.init_time	= shmobile_timer_init,
 	.dt_compat	= r8a7740_boards_compat_dt,
 MACHINE_END
 
diff --git a/arch/arm/mach-shmobile/setup-sh7372.c b/arch/arm/mach-shmobile/setup-sh7372.c
index 59c7146..5502d62 100644
--- a/arch/arm/mach-shmobile/setup-sh7372.c
+++ b/arch/arm/mach-shmobile/setup-sh7372.c
@@ -1175,7 +1175,6 @@ DT_MACHINE_START(SH7372_DT, "Generic SH7372 (Flattened Device Tree)")
 	.init_irq	= sh7372_init_irq,
 	.handle_irq	= shmobile_handle_irq_intc,
 	.init_machine	= sh7372_add_standard_devices_dt,
-	.init_time	= shmobile_timer_init,
 	.dt_compat	= sh7372_boards_compat_dt,
 MACHINE_END
 
diff --git a/arch/arm/mach-shmobile/setup-sh73a0.c b/arch/arm/mach-shmobile/setup-sh73a0.c
index bdab575..ea66316 100644
--- a/arch/arm/mach-shmobile/setup-sh73a0.c
+++ b/arch/arm/mach-shmobile/setup-sh73a0.c
@@ -923,7 +923,6 @@ DT_MACHINE_START(SH73A0_DT, "Generic SH73A0 (Flattened Device Tree)")
 	.nr_irqs	= NR_IRQS_LEGACY,
 	.init_irq	= sh73a0_init_irq_dt,
 	.init_machine	= sh73a0_add_standard_devices_dt,
-	.init_time	= shmobile_timer_init,
 	.dt_compat	= sh73a0_boards_compat_dt,
 MACHINE_END
 #endif /* CONFIG_USE_OF */
diff --git a/arch/arm/mach-shmobile/timer.c b/arch/arm/mach-shmobile/timer.c
index 3d16d4d..add2f15 100644
--- a/arch/arm/mach-shmobile/timer.c
+++ b/arch/arm/mach-shmobile/timer.c
@@ -60,9 +60,3 @@ void __init shmobile_earlytimer_init(void)
 {
 	late_time_init = shmobile_late_time_init;
 }
-
-void __init shmobile_timer_init(void)
-{
-	arch_timer_of_register();
-	arch_timer_sched_clock_init();
-}
diff --git a/arch/arm/mach-vexpress/v2m.c b/arch/arm/mach-vexpress/v2m.c
index d0ad789..6215717 100644
--- a/arch/arm/mach-vexpress/v2m.c
+++ b/arch/arm/mach-vexpress/v2m.c
@@ -1,6 +1,7 @@
 /*
  * Versatile Express V2M Motherboard Support
  */
+#include <linux/clocksource.h>
 #include <linux/device.h>
 #include <linux/amba/bus.h>
 #include <linux/amba/mmci.h>
@@ -23,7 +24,6 @@
 #include <linux/regulator/machine.h>
 #include <linux/vexpress.h>
 
-#include <asm/arch_timer.h>
 #include <asm/mach-types.h>
 #include <asm/sizes.h>
 #include <asm/mach/arch.h>
@@ -446,10 +446,7 @@ static void __init v2m_dt_timer_init(void)
 				irq_of_parse_and_map(node, 0));
 	}
 
-	arch_timer_of_register();
-
-	if (arch_timer_sched_clock_init() != 0)
-		versatile_sched_clock_init(vexpress_get_24mhz_clock_base(),
+	versatile_sched_clock_init(vexpress_get_24mhz_clock_base(),
 				24000000);
 }
 
diff --git a/arch/arm/mach-virt/virt.c b/arch/arm/mach-virt/virt.c
index 31666f6..adc0945 100644
--- a/arch/arm/mach-virt/virt.c
+++ b/arch/arm/mach-virt/virt.c
@@ -23,21 +23,13 @@
 #include <linux/of_platform.h>
 #include <linux/smp.h>
 
-#include <asm/arch_timer.h>
 #include <asm/mach/arch.h>
-#include <asm/mach/time.h>
 
 static void __init virt_init(void)
 {
 	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
 }
 
-static void __init virt_timer_init(void)
-{
-	WARN_ON(arch_timer_of_register() != 0);
-	WARN_ON(arch_timer_sched_clock_init() != 0);
-}
-
 static const char *virt_dt_match[] = {
 	"linux,dummy-virt",
 	NULL
@@ -47,7 +39,6 @@ extern struct smp_operations virt_smp_ops;
 
 DT_MACHINE_START(VIRT, "Dummy Virtual Machine")
 	.init_irq	= irqchip_init,
-	.init_time	= virt_timer_init,
 	.init_machine	= virt_init,
 	.smp		= smp_ops(virt_smp_ops),
 	.dt_compat	= virt_dt_match,
diff --git a/arch/arm64/include/asm/arch_timer.h b/arch/arm64/include/asm/arch_timer.h
index 91e2a6a..bf6ab242 100644
--- a/arch/arm64/include/asm/arch_timer.h
+++ b/arch/arm64/include/asm/arch_timer.h
@@ -130,4 +130,9 @@ static inline u64 arch_counter_get_cntvct(void)
 	return cval;
 }
 
+static inline int arch_timer_arch_init(void)
+{
+	return 0;
+}
+
 #endif
diff --git a/arch/arm64/kernel/time.c b/arch/arm64/kernel/time.c
index b0ef18d..a551f88 100644
--- a/arch/arm64/kernel/time.c
+++ b/arch/arm64/kernel/time.c
@@ -32,6 +32,7 @@
 #include <linux/timer.h>
 #include <linux/irq.h>
 #include <linux/delay.h>
+#include <linux/clocksource.h>
 
 #include <clocksource/arm_arch_timer.h>
 
@@ -77,10 +78,11 @@ void __init time_init(void)
 {
 	u32 arch_timer_rate;
 
-	if (arch_timer_init())
-		panic("Unable to initialise architected timer.\n");
+	clocksource_of_init();
 
 	arch_timer_rate = arch_timer_get_rate();
+	if (!arch_timer_rate)
+		panic("Unable to initialise architected timer.\n");
 
 	/* Cache the sched_clock multiplier to save a divide in the hot path. */
 	sched_clock_mult = NSEC_PER_SEC / arch_timer_rate;
diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index e507ab7..d98e7e1 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -62,6 +62,7 @@ config CLKSRC_DBX500_PRCMU_SCHED_CLOCK
 
 config ARM_ARCH_TIMER
 	bool
+	select CLKSRC_OF if OF
 
 config CLKSRC_METAG_GENERIC
 	def_bool y if METAG
diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
index d7ad425..122ff05 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -337,22 +337,14 @@ out:
 	return err;
 }
 
-static const struct of_device_id arch_timer_of_match[] __initconst = {
-	{ .compatible	= "arm,armv7-timer",	},
-	{ .compatible	= "arm,armv8-timer",	},
-	{},
-};
-
-int __init arch_timer_init(void)
+static void __init arch_timer_init(struct device_node *np)
 {
-	struct device_node *np;
 	u32 freq;
 	int i;
 
-	np = of_find_matching_node(NULL, arch_timer_of_match);
-	if (!np) {
-		pr_err("arch_timer: can't find DT node\n");
-		return -ENODEV;
+	if (arch_timer_get_rate()) {
+		pr_warn("arch_timer: multiple nodes in dt, skipping\n");
+		return;
 	}
 
 	/* Try to determine the frequency from the device tree or CNTFRQ */
@@ -378,7 +370,7 @@ int __init arch_timer_init(void)
 		if (!arch_timer_ppi[PHYS_SECURE_PPI] ||
 		    !arch_timer_ppi[PHYS_NONSECURE_PPI]) {
 			pr_warn("arch_timer: No interrupt available, giving up\n");
-			return -EINVAL;
+			return;
 		}
 	}
 
@@ -387,5 +379,8 @@ int __init arch_timer_init(void)
 	else
 		arch_timer_read_counter = arch_counter_get_cntpct;
 
-	return arch_timer_register();
+	arch_timer_register();
+	arch_timer_arch_init();
 }
+CLOCKSOURCE_OF_DECLARE(armv7_arch_timer, "arm,armv7-timer", arch_timer_init);
+CLOCKSOURCE_OF_DECLARE(armv8_arch_timer, "arm,armv8-timer", arch_timer_init);
diff --git a/include/clocksource/arm_arch_timer.h b/include/clocksource/arm_arch_timer.h
index 2603267..e6c9c4c 100644
--- a/include/clocksource/arm_arch_timer.h
+++ b/include/clocksource/arm_arch_timer.h
@@ -31,18 +31,12 @@
 
 #ifdef CONFIG_ARM_ARCH_TIMER
 
-extern int arch_timer_init(void);
 extern u32 arch_timer_get_rate(void);
 extern u64 (*arch_timer_read_counter)(void);
 extern struct timecounter *arch_timer_get_timecounter(void);
 
 #else
 
-static inline int arch_timer_init(void)
-{
-	return -ENXIO;
-}
-
 static inline u32 arch_timer_get_rate(void)
 {
 	return 0;
-- 
1.7.10.4



From robherring2 at gmail.com  Mon Apr  1 18:21:15 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Mon,  1 Apr 2013 17:21:15 -0500
Subject: [PATCH v2 05/13] ARM: highbank: use OF init for sp804 timer
In-Reply-To: <1364854883-5961-1-git-send-email-robherring2@gmail.com>
References: <1364854883-5961-1-git-send-email-robherring2@gmail.com>
Message-ID: <1364854883-5961-6-git-send-email-robherring2@gmail.com>

From: Rob Herring <rob.herring at calxeda.com>

Remove the highbank specific setup for the sp804 timer now that
clocksource_of_init will do it.

Signed-off-by: Rob Herring <rob.herring at calxeda.com>
---
 arch/arm/mach-highbank/highbank.c |   19 -------------------
 1 file changed, 19 deletions(-)

diff --git a/arch/arm/mach-highbank/highbank.c b/arch/arm/mach-highbank/highbank.c
index 758150e..e7df2dd 100644
--- a/arch/arm/mach-highbank/highbank.c
+++ b/arch/arm/mach-highbank/highbank.c
@@ -32,8 +32,6 @@
 #include <asm/cacheflush.h>
 #include <asm/cputype.h>
 #include <asm/smp_plat.h>
-#include <asm/hardware/arm_timer.h>
-#include <asm/hardware/timer-sp.h>
 #include <asm/hardware/cache-l2x0.h>
 #include <asm/mach/arch.h>
 #include <asm/mach/map.h>
@@ -90,33 +88,16 @@ static void __init highbank_init_irq(void)
 #endif
 }
 
-static struct clk_lookup lookup = {
-	.dev_id = "sp804",
-	.con_id = NULL,
-};
-
 static void __init highbank_timer_init(void)
 {
-	int irq;
 	struct device_node *np;
-	void __iomem *timer_base;
 
 	/* Map system registers */
 	np = of_find_compatible_node(NULL, NULL, "calxeda,hb-sregs");
 	sregs_base = of_iomap(np, 0);
 	WARN_ON(!sregs_base);
 
-	np = of_find_compatible_node(NULL, NULL, "arm,sp804");
-	timer_base = of_iomap(np, 0);
-	WARN_ON(!timer_base);
-	irq = irq_of_parse_and_map(np, 0);
-
 	of_clk_init(NULL);
-	lookup.clk = of_clk_get(np, 0);
-	clkdev_add(&lookup);
-
-	sp804_clocksource_and_sched_clock_init(timer_base + 0x20, "timer1");
-	sp804_clockevents_init(timer_base, irq, "timer0");
 
 	clocksource_of_init();
 }
-- 
1.7.10.4



From robherring2 at gmail.com  Mon Apr  1 18:21:16 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Mon,  1 Apr 2013 17:21:16 -0500
Subject: [PATCH v2 06/13] ARM: vexpress: remove sp804 OF init
In-Reply-To: <1364854883-5961-1-git-send-email-robherring2@gmail.com>
References: <1364854883-5961-1-git-send-email-robherring2@gmail.com>
Message-ID: <1364854883-5961-7-git-send-email-robherring2@gmail.com>

From: Rob Herring <rob.herring at calxeda.com>

Remove the vexpress specific setup for the sp804 timer now that
clocksource_of_init will do it.

Signed-off-by: Rob Herring <rob.herring at calxeda.com>
---
 arch/arm/mach-vexpress/v2m.c |   11 -----------
 1 file changed, 11 deletions(-)

diff --git a/arch/arm/mach-vexpress/v2m.c b/arch/arm/mach-vexpress/v2m.c
index 6215717..cdc29d8 100644
--- a/arch/arm/mach-vexpress/v2m.c
+++ b/arch/arm/mach-vexpress/v2m.c
@@ -431,20 +431,9 @@ void __init v2m_dt_init_early(void)
 
 static void __init v2m_dt_timer_init(void)
 {
-	struct device_node *node = NULL;
-
 	vexpress_clk_of_init();
 
 	clocksource_of_init();
-	do {
-		node = of_find_compatible_node(node, NULL, "arm,sp804");
-	} while (node && vexpress_get_site_by_node(node) != VEXPRESS_SITE_MB);
-	if (node) {
-		pr_info("Using SP804 '%s' as a clock & events source\n",
-				node->full_name);
-		v2m_sp804_init(of_iomap(node, 0),
-				irq_of_parse_and_map(node, 0));
-	}
 
 	versatile_sched_clock_init(vexpress_get_24mhz_clock_base(),
 				24000000);
-- 
1.7.10.4



From robherring2 at gmail.com  Mon Apr  1 18:21:17 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Mon,  1 Apr 2013 17:21:17 -0500
Subject: [PATCH v2 07/13] ARM: dts: vexpress: disable CA9 core tile sp804 timer
In-Reply-To: <1364854883-5961-1-git-send-email-robherring2@gmail.com>
References: <1364854883-5961-1-git-send-email-robherring2@gmail.com>
Message-ID: <1364854883-5961-8-git-send-email-robherring2@gmail.com>

From: Rob Herring <rob.herring at calxeda.com>

The motherboard sp804 timer is used, but core tile sp804 timer is not.
According to Russell King, the clock configuration is undocumented and
defaults to 32kHz which is not desireable. So mark core tile sp804 timer
as disabled.

Signed-off-by: Rob Herring <rob.herring at calxeda.com>
---
 arch/arm/boot/dts/vexpress-v2p-ca9.dts |    1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/vexpress-v2p-ca9.dts b/arch/arm/boot/dts/vexpress-v2p-ca9.dts
index 1420bb1..62d9b22 100644
--- a/arch/arm/boot/dts/vexpress-v2p-ca9.dts
+++ b/arch/arm/boot/dts/vexpress-v2p-ca9.dts
@@ -98,6 +98,7 @@
 			     <0 49 4>;
 		clocks = <&oscclk2>, <&oscclk2>;
 		clock-names = "timclk", "apb_pclk";
+		status = "disabled";
 	};
 
 	watchdog at 100e5000 {
-- 
1.7.10.4



From robherring2 at gmail.com  Mon Apr  1 18:21:18 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Mon,  1 Apr 2013 17:21:18 -0500
Subject: [PATCH v2 08/13] ARM: vexpress: remove extra timer-sp control
 register clearing
In-Reply-To: <1364854883-5961-1-git-send-email-robherring2@gmail.com>
References: <1364854883-5961-1-git-send-email-robherring2@gmail.com>
Message-ID: <1364854883-5961-9-git-send-email-robherring2@gmail.com>

From: Rob Herring <rob.herring at calxeda.com>

The timer-sp initialization code clears the control register before
initializing the timers, so every platform doing this is redundant.

Signed-off-by: Rob Herring <rob.herring at calxeda.com>
---
 arch/arm/mach-vexpress/v2m.c |    3 ---
 1 file changed, 3 deletions(-)

diff --git a/arch/arm/mach-vexpress/v2m.c b/arch/arm/mach-vexpress/v2m.c
index cdc29d8..09e571d 100644
--- a/arch/arm/mach-vexpress/v2m.c
+++ b/arch/arm/mach-vexpress/v2m.c
@@ -61,9 +61,6 @@ static void __init v2m_sp804_init(void __iomem *base, unsigned int irq)
 	if (WARN_ON(!base || irq == NO_IRQ))
 		return;
 
-	writel(0, base + TIMER_1_BASE + TIMER_CTRL);
-	writel(0, base + TIMER_2_BASE + TIMER_CTRL);
-
 	sp804_clocksource_init(base + TIMER_2_BASE, "v2m-timer1");
 	sp804_clockevents_init(base + TIMER_1_BASE, irq, "v2m-timer0");
 }
-- 
1.7.10.4



From robherring2 at gmail.com  Mon Apr  1 18:21:19 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Mon,  1 Apr 2013 17:21:19 -0500
Subject: [PATCH v2 09/13] ARM: versatile: add versatile dtbs to dtbs target
In-Reply-To: <1364854883-5961-1-git-send-email-robherring2@gmail.com>
References: <1364854883-5961-1-git-send-email-robherring2@gmail.com>
Message-ID: <1364854883-5961-10-git-send-email-robherring2@gmail.com>

From: Rob Herring <rob.herring at calxeda.com>

Add the versatile platform dtbs to the dtbs make rule.

Signed-off-by: Rob Herring <rob.herring at calxeda.com>
---
 arch/arm/boot/dts/Makefile |    2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 9c62558..08d298d 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -165,6 +165,8 @@ dtb-$(CONFIG_ARCH_TEGRA) += tegra20-harmony.dtb \
 	tegra30-cardhu-a04.dtb \
 	tegra114-dalmore.dtb \
 	tegra114-pluto.dtb
+dtb-$(CONFIG_ARCH_VERSATILE) += versatile-ab.dtb \
+	versatile-pb.dtb
 dtb-$(CONFIG_ARCH_VEXPRESS) += vexpress-v2p-ca5s.dtb \
 	vexpress-v2p-ca9.dtb \
 	vexpress-v2p-ca15-tc1.dtb \
-- 
1.7.10.4



From robherring2 at gmail.com  Mon Apr  1 18:21:20 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Mon,  1 Apr 2013 17:21:20 -0500
Subject: [PATCH v2 10/13] ARM: versatile: use OF init for sp804 timer
In-Reply-To: <1364854883-5961-1-git-send-email-robherring2@gmail.com>
References: <1364854883-5961-1-git-send-email-robherring2@gmail.com>
Message-ID: <1364854883-5961-11-git-send-email-robherring2@gmail.com>

From: Rob Herring <rob.herring at calxeda.com>

Enable DT based init for the sp804 timers on versatile DT platform.

Signed-off-by: Rob Herring <rob.herring at calxeda.com>
---
 arch/arm/boot/dts/versatile-ab.dts     |   12 ++++++++++++
 arch/arm/mach-versatile/core.c         |   26 +++++++++++++-------------
 arch/arm/mach-versatile/versatile_dt.c |    1 -
 3 files changed, 25 insertions(+), 14 deletions(-)

diff --git a/arch/arm/boot/dts/versatile-ab.dts b/arch/arm/boot/dts/versatile-ab.dts
index e2fe319..dde75ae 100644
--- a/arch/arm/boot/dts/versatile-ab.dts
+++ b/arch/arm/boot/dts/versatile-ab.dts
@@ -121,6 +121,18 @@
 			interrupts = <0>;
 		};
 
+		timer at 101e2000 {
+			compatible = "arm,sp804", "arm,primecell";
+			reg = <0x101e2000 0x1000>;
+			interrupts = <4>;
+		};
+
+		timer at 101e3000 {
+			compatible = "arm,sp804", "arm,primecell";
+			reg = <0x101e3000 0x1000>;
+			interrupts = <5>;
+		};
+
 		gpio0: gpio at 101e4000 {
 			compatible = "arm,pl061", "arm,primecell";
 			reg = <0x101e4000 0x1000>;
diff --git a/arch/arm/mach-versatile/core.c b/arch/arm/mach-versatile/core.c
index 25160ae..54bb80b 100644
--- a/arch/arm/mach-versatile/core.c
+++ b/arch/arm/mach-versatile/core.c
@@ -749,12 +749,25 @@ void versatile_restart(char mode, const char *cmd)
 /* Early initializations */
 void __init versatile_init_early(void)
 {
+	u32 val;
 	void __iomem *sys = __io_address(VERSATILE_SYS_BASE);
 
 	osc4_clk.vcoreg	= sys + VERSATILE_SYS_OSCCLCD_OFFSET;
 	clkdev_add_table(lookups, ARRAY_SIZE(lookups));
 
 	versatile_sched_clock_init(sys + VERSATILE_SYS_24MHz_OFFSET, 24000000);
+
+	/*
+	 * set clock frequency:
+	 *	VERSATILE_REFCLK is 32KHz
+	 *	VERSATILE_TIMCLK is 1MHz
+	 */
+	val = readl(__io_address(VERSATILE_SCTL_BASE));
+	writel((VERSATILE_TIMCLK << VERSATILE_TIMER1_EnSel) |
+	       (VERSATILE_TIMCLK << VERSATILE_TIMER2_EnSel) |
+	       (VERSATILE_TIMCLK << VERSATILE_TIMER3_EnSel) |
+	       (VERSATILE_TIMCLK << VERSATILE_TIMER4_EnSel) | val,
+	       __io_address(VERSATILE_SCTL_BASE));
 }
 
 void __init versatile_init(void)
@@ -785,19 +798,6 @@ void __init versatile_init(void)
  */
 void __init versatile_timer_init(void)
 {
-	u32 val;
-
-	/* 
-	 * set clock frequency: 
-	 *	VERSATILE_REFCLK is 32KHz
-	 *	VERSATILE_TIMCLK is 1MHz
-	 */
-	val = readl(__io_address(VERSATILE_SCTL_BASE));
-	writel((VERSATILE_TIMCLK << VERSATILE_TIMER1_EnSel) |
-	       (VERSATILE_TIMCLK << VERSATILE_TIMER2_EnSel) | 
-	       (VERSATILE_TIMCLK << VERSATILE_TIMER3_EnSel) |
-	       (VERSATILE_TIMCLK << VERSATILE_TIMER4_EnSel) | val,
-	       __io_address(VERSATILE_SCTL_BASE));
 
 	/*
 	 * Initialise to a known state (all timers off)
diff --git a/arch/arm/mach-versatile/versatile_dt.c b/arch/arm/mach-versatile/versatile_dt.c
index 2558f2e..3621b00 100644
--- a/arch/arm/mach-versatile/versatile_dt.c
+++ b/arch/arm/mach-versatile/versatile_dt.c
@@ -45,7 +45,6 @@ DT_MACHINE_START(VERSATILE_PB, "ARM-Versatile (Device Tree Support)")
 	.map_io		= versatile_map_io,
 	.init_early	= versatile_init_early,
 	.init_irq	= versatile_init_irq,
-	.init_time	= versatile_timer_init,
 	.init_machine	= versatile_dt_init,
 	.dt_compat	= versatile_dt_match,
 	.restart	= versatile_restart,
-- 
1.7.10.4



From robherring2 at gmail.com  Mon Apr  1 18:21:21 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Mon,  1 Apr 2013 17:21:21 -0500
Subject: [PATCH v2 11/13] ARM: integrator-cp: convert use CLKSRC_OF for timer
 init
In-Reply-To: <1364854883-5961-1-git-send-email-robherring2@gmail.com>
References: <1364854883-5961-1-git-send-email-robherring2@gmail.com>
Message-ID: <1364854883-5961-12-git-send-email-robherring2@gmail.com>

From: Rob Herring <rob.herring at calxeda.com>

Move the integrator-cp timer init to timer-sp.c and use CLKSRC_OF. There is
no reason to use the aliases, so drop them from the init code.

The integrator-cp timers are mistakenly called sp804 timers in the dts, but
in fact they are not sp804 dual timers, but single timers with the same
programming model. Fix the dts to reflect this.

Signed-off-by: Rob Herring <rob.herring at calxeda.com>
Acked-by: Linus Walleij <linus.walleij at linaro.org>
---
 arch/arm/boot/dts/integratorcp.dts       |    6 ++---
 arch/arm/common/timer-sp.c               |   35 ++++++++++++++++++++++++++++++
 arch/arm/mach-integrator/integrator_cp.c |   34 -----------------------------
 3 files changed, 38 insertions(+), 37 deletions(-)

diff --git a/arch/arm/boot/dts/integratorcp.dts b/arch/arm/boot/dts/integratorcp.dts
index 8b11939..ff1aea0 100644
--- a/arch/arm/boot/dts/integratorcp.dts
+++ b/arch/arm/boot/dts/integratorcp.dts
@@ -24,15 +24,15 @@
 	};
 
 	timer0: timer at 13000000 {
-		compatible = "arm,sp804", "arm,primecell";
+		compatible = "arm,integrator-cp-timer";
 	};
 
 	timer1: timer at 13000100 {
-		compatible = "arm,sp804", "arm,primecell";
+		compatible = "arm,integrator-cp-timer";
 	};
 
 	timer2: timer at 13000200 {
-		compatible = "arm,sp804", "arm,primecell";
+		compatible = "arm,integrator-cp-timer";
 	};
 
 	pic: pic at 14000000 {
diff --git a/arch/arm/common/timer-sp.c b/arch/arm/common/timer-sp.c
index ded926f..ddc7407 100644
--- a/arch/arm/common/timer-sp.c
+++ b/arch/arm/common/timer-sp.c
@@ -31,6 +31,7 @@
 
 #include <asm/sched_clock.h>
 #include <asm/hardware/arm_timer.h>
+#include <asm/hardware/timer-sp.h>
 
 static long __init sp804_get_clock_rate(struct clk *clk)
 {
@@ -262,3 +263,37 @@ err:
 	iounmap(base);
 }
 CLOCKSOURCE_OF_DECLARE(sp804, "arm,sp804", sp804_of_init);
+
+static void __init integrator_cp_of_init(struct device_node *np)
+{
+	static int init_count = 0;
+	void __iomem *base;
+	int irq;
+	const char *name = of_get_property(np, "compatible", NULL);
+
+	base = of_iomap(np, 0);
+	if (WARN_ON(!base))
+		return;
+
+	/* Ensure timer is disabled */
+	writel(0, base + TIMER_CTRL);
+
+	if (init_count == 2 || !of_device_is_available(np))
+		goto err;
+
+	if (!init_count)
+		sp804_clocksource_init(base, name);
+	else {
+		irq = irq_of_parse_and_map(np, 0);
+		if (irq <= 0)
+			goto err;
+
+		sp804_clockevents_init(base, irq, name);
+	}
+
+	init_count++;
+	return;
+err:
+	iounmap(base);
+}
+CLOCKSOURCE_OF_DECLARE(intcp, "arm,integrator-cp-timer", integrator_cp_of_init);
diff --git a/arch/arm/mach-integrator/integrator_cp.c b/arch/arm/mach-integrator/integrator_cp.c
index 2b0db82..5781f3c 100644
--- a/arch/arm/mach-integrator/integrator_cp.c
+++ b/arch/arm/mach-integrator/integrator_cp.c
@@ -250,39 +250,6 @@ static void __init intcp_init_early(void)
 }
 
 #ifdef CONFIG_OF
-
-static void __init cp_of_timer_init(void)
-{
-	struct device_node *node;
-	const char *path;
-	void __iomem *base;
-	int err;
-	int irq;
-
-	err = of_property_read_string(of_aliases,
-				"arm,timer-primary", &path);
-	if (WARN_ON(err))
-		return;
-	node = of_find_node_by_path(path);
-	base = of_iomap(node, 0);
-	if (WARN_ON(!base))
-		return;
-	writel(0, base + TIMER_CTRL);
-	sp804_clocksource_init(base, node->name);
-
-	err = of_property_read_string(of_aliases,
-				"arm,timer-secondary", &path);
-	if (WARN_ON(err))
-		return;
-	node = of_find_node_by_path(path);
-	base = of_iomap(node, 0);
-	if (WARN_ON(!base))
-		return;
-	irq = irq_of_parse_and_map(node, 0);
-	writel(0, base + TIMER_CTRL);
-	sp804_clockevents_init(base, irq, node->name);
-}
-
 static const struct of_device_id fpga_irq_of_match[] __initconst = {
 	{ .compatible = "arm,versatile-fpga-irq", .data = fpga_irq_of_init, },
 	{ /* Sentinel */ }
@@ -386,7 +353,6 @@ DT_MACHINE_START(INTEGRATOR_CP_DT, "ARM Integrator/CP (Device Tree)")
 	.init_early	= intcp_init_early,
 	.init_irq	= intcp_init_irq_of,
 	.handle_irq	= fpga_handle_irq,
-	.init_time	= cp_of_timer_init,
 	.init_machine	= intcp_init_of,
 	.restart	= integrator_restart,
 	.dt_compat      = intcp_dt_board_compat,
-- 
1.7.10.4



From gdavis at mvista.com  Mon Apr  1 18:21:51 2013
From: gdavis at mvista.com (George G. Davis)
Date: Mon, 1 Apr 2013 18:21:51 -0400
Subject: [PATCH 1/2] Allow constructor name selection by architecture.
In-Reply-To: <20130401215834.GA5972@merkur.ravnborg.org>
References: <1338230018-31052-1-git-send-email-vincent.sanders@collabora.co.uk>
 <1338230018-31052-2-git-send-email-vincent.sanders@collabora.co.uk>
 <20120528203005.GA20560@merkur.ravnborg.org>
 <20120529090614.GD12217@n2100.arm.linux.org.uk>
 <20120606101253.GM8262@n2100.arm.linux.org.uk>
 <87F2CC87-0FAF-49CB-AE70-423FB063A0E5@mvista.com>
 <20130401215834.GA5972@merkur.ravnborg.org>
Message-ID: <CAE1uF8dCy3m3TO4xa6Cc3i-CM3QYUFADZH_6o+hgy6MSPEWnyQ@mail.gmail.com>

On Mon, Apr 1, 2013 at 5:58 PM, Sam Ravnborg <sam at ravnborg.org> wrote:
> On Mon, Apr 01, 2013 at 05:47:38PM -0400, George G. Davis wrote:
>> On Jun 6, 2012, at 6:12 AM, Russell King - ARM Linux wrote:
>> > On Tue, May 29, 2012 at 10:06:14AM +0100, Russell King - ARM Linux wrote:
>> >> On Mon, May 28, 2012 at 10:30:05PM +0200, Sam Ravnborg wrote:
>> >>> On Mon, May 28, 2012 at 07:33:37PM +0100, Vincent Sanders wrote:
>> >>>> From: Vincent Sanders <vince at collabora.co.uk>
>> >>>>
>> >>>> The constructor symbol name is different between platforms. Allow this
>> >>>> to be selected by configuration and set suitable default values.
>> >>>>
>> >>>> Signed-off-by: Vincent Sanders <vincent.sanders at collabora.co.uk>
>> >>>> ---
>> >>>> include/asm-generic/vmlinux.lds.h |    6 +++---
>> >>>> init/Kconfig                      |    6 ++++++
>> >>>> kernel/module.c                   |    2 +-
>> >>>> 3 files changed, 10 insertions(+), 4 deletions(-)
>> >>>>
>> >>>> diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
>> >>>> index 8aeadf6..fd34808 100644
>> >>>> --- a/include/asm-generic/vmlinux.lds.h
>> >>>> +++ b/include/asm-generic/vmlinux.lds.h
>> >>>> @@ -471,9 +471,9 @@
>> >>>>  }
>> >>>>
>> >>>> #ifdef CONFIG_CONSTRUCTORS
>> >>>> -#define KERNEL_CTORS()  . = ALIGN(8);                      \
>> >>>> -                        VMLINUX_SYMBOL(__ctors_start) = .; \
>> >>>> -                        *(.ctors)                          \
>> >>>> +#define KERNEL_CTORS()  . = ALIGN(8);                                   \
>> >>>> +                        VMLINUX_SYMBOL(__ctors_start) = .;              \
>> >>>> +                        *(CONFIG_CONSTRUCTORS_NAME)                     \
>> >>>>                  VMLINUX_SYMBOL(__ctors_end) = .;
>> >>>
>> >>> What is wrong with adding both "standard" names for ctors uncnditionally?
>> >>> Like this:
>> >>>>                  *(.ctors)                          \
>> >>>> +                        *(.init_array)                     \
>> >>
>> >> That doesn't get rid of CONFIG_CONSTRUCTORS_NAME, because it's needed
>> >> in the module code.  Do you have a suggestion to solve that as well?
>> >
>> > Ping.
>>
>> Pinging this back to life.  I'd like to see GCOV for ARM eABI finally make it upstream.
>> So, any objections to this?  Should it be resubmitted?
>
> Why is CONFIG_CONSTRUCTORS_NAME needed in module code?

Because ARM eABI uses the .init_array section for C++ constructors,
rather than .ctors.
So the patch defined CONFIG_CONSTRUCTORS_NAME to set the correct section name
for ARM eABI while leaving non-ARM-eABI as before, .ctors.  Here are the changes
from the patch for reference:

diff --git a/init/Kconfig b/init/Kconfig
index 6cfd71d..52181a1 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -20,6 +20,12 @@ config CONSTRUCTORS
        bool
        depends on !UML

+config CONSTRUCTORS_NAME
+       string
+       depends on CONSTRUCTORS
+       default ".init_array" if ARM && AEABI
+       default ".ctors"
+
 config HAVE_IRQ_WORK
        bool

diff --git a/kernel/module.c b/kernel/module.c
index 78ac6ec..e5fad5e 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -2600,7 +2600,7 @@ static void find_module_sections(struct module
*mod, struct load_info *info)
        mod->unused_gpl_crcs = section_addr(info, "__kcrctab_unused_gpl");
 #endif
 #ifdef CONFIG_CONSTRUCTORS
-       mod->ctors = section_objs(info, ".ctors",
+       mod->ctors = section_objs(info, CONFIG_CONSTRUCTORS_NAME,
                                  sizeof(*mod->ctors), &mod->num_ctors);
 #endif

W/o the above, GCOV does not work on ARM eABI for kernel modules.
Meanwhile, it still works as before for non-ARM-eABI kernel modules.

Thanks!

--
Regards,
George


From robherring2 at gmail.com  Mon Apr  1 18:21:23 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Mon,  1 Apr 2013 17:21:23 -0500
Subject: [PATCH v2 13/13] devtree: add binding documentation for sp804
In-Reply-To: <1364854883-5961-1-git-send-email-robherring2@gmail.com>
References: <1364854883-5961-1-git-send-email-robherring2@gmail.com>
Message-ID: <1364854883-5961-14-git-send-email-robherring2@gmail.com>

From: Haojian Zhuang <haojian.zhuang at linaro.org>

The sp804 binding is already in use by several platforms. This adds missing
documentation for the binding and also extends the binding to handle some
additional possible interrupt configurations.

Signed-off-by: Haojian Zhuang <haojian.zhuang at linaro.org>
Signed-off-by: Rob Herring <rob.herring at calxeda.com>
---
 .../devicetree/bindings/timer/arm,sp804.txt        |   29 ++++++++++++++++++++
 1 file changed, 29 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/timer/arm,sp804.txt

diff --git a/Documentation/devicetree/bindings/timer/arm,sp804.txt b/Documentation/devicetree/bindings/timer/arm,sp804.txt
new file mode 100644
index 0000000..5cd8eee
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/arm,sp804.txt
@@ -0,0 +1,29 @@
+ARM sp804 Dual Timers
+---------------------------------------
+
+Required properties:
+- compatible: Should be "arm,sp804" & "arm,primecell"
+- interrupts: Should contain the list of Dual Timer interrupts. This is the
+	interrupt for timer 1 and timer 2. In the case of a single entry, it is
+	the combined interrupt or if "arm,sp804-has-irq" is present that
+	specifies which timer interrupt is connected.
+- reg: Should contain location and length for dual timer register.
+- clocks: clocks driving the dual timer hardware. This list should be 1 or 3
+	clocks.	With 3 clocks, the order is timer0 clock, timer1 clock,
+	apb_pclk. A single clock can also be specified if the same clock is
+	used for all clock inputs.
+
+Optional properties:
+- arm,sp804-has-irq = <#>: In the case of only 1 timer irq line connected, this
+	specifies if the irq connection is for timer 1 or timer 2. A value of 1
+	or 2 should be used.
+
+Example:
+
+	timer0: timer at fc800000 {
+		compatible = "arm,sp804", "arm,primecell";
+		reg = <0xfc800000 0x1000>;
+		interrupts = <0 0 4>, <0 1 4>;
+		clocks = <&timclk1 &timclk2 &pclk>;
+		clock-names = "timer1", "timer2", "apb_pclk";
+	};
-- 
1.7.10.4



From robherring2 at gmail.com  Mon Apr  1 18:21:22 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Mon,  1 Apr 2013 17:21:22 -0500
Subject: [PATCH v2 12/13] ARM: move sp804 and integrator timers to
 drivers/clocksource
In-Reply-To: <1364854883-5961-1-git-send-email-robherring2@gmail.com>
References: <1364854883-5961-1-git-send-email-robherring2@gmail.com>
Message-ID: <1364854883-5961-13-git-send-email-robherring2@gmail.com>

From: Rob Herring <rob.herring at calxeda.com>

Move timer-sp and integrator-ap timer code to drivers/clocksource and
update timer-sp.h and arm_timer.h includes.

This adds CLKSRC_OF support for the integrator-ap timer and removes the
use of "arm,timer-primary" and "arm,timer-secondary" aliases. The timer
selection should not be important as all 3 timers are equal capability.

Signed-off-by: Rob Herring <rob.herring at calxeda.com>
Cc: Russell King <linux at arm.linux.org.uk>
Cc: John Stultz <john.stultz at linaro.org>
Cc: Thomas Gleixner <tglx at linutronix.de>
Acked-by: Linus Walleij <linus.walleij at linaro.org>
---
 arch/arm/Kconfig                                   |    6 -
 arch/arm/common/Makefile                           |    1 -
 arch/arm/mach-integrator/Kconfig                   |    1 +
 arch/arm/mach-integrator/integrator_ap.c           |  170 +-----------------
 arch/arm/mach-integrator/integrator_cp.c           |    5 +-
 arch/arm/mach-realview/core.c                      |    5 +-
 arch/arm/mach-versatile/core.c                     |    4 +-
 arch/arm/mach-vexpress/ct-ca9x4.c                  |    4 +-
 arch/arm/mach-vexpress/v2m.c                       |    4 +-
 drivers/clocksource/Kconfig                        |   12 ++
 drivers/clocksource/Makefile                       |    2 +
 drivers/clocksource/integrator_ap_timer.c          |  189 ++++++++++++++++++++
 .../arm/common => drivers/clocksource}/timer-sp.c  |    6 +-
 .../hardware => include/clocksource}/arm_timer.h   |    4 +-
 include/clocksource/integrator_ap_timer.h          |    7 +
 .../hardware => include/clocksource}/timer-sp.h    |    0
 16 files changed, 226 insertions(+), 194 deletions(-)
 create mode 100644 drivers/clocksource/integrator_ap_timer.c
 rename {arch/arm/common => drivers/clocksource}/timer-sp.c (98%)
 rename {arch/arm/include/asm/hardware => include/clocksource}/arm_timer.h (93%)
 create mode 100644 include/clocksource/integrator_ap_timer.h
 rename {arch/arm/include/asm/hardware => include/clocksource}/timer-sp.h (100%)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 10e3053..982076c 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1170,12 +1170,6 @@ config PLAT_PXA
 config PLAT_VERSATILE
 	bool
 
-config ARM_TIMER_SP804
-	bool
-	select CLKSRC_MMIO
-	select CLKSRC_OF if OF
-	select HAVE_SCHED_CLOCK
-
 source arch/arm/mm/Kconfig
 
 config ARM_NR_BANKS
diff --git a/arch/arm/common/Makefile b/arch/arm/common/Makefile
index dc8dd0d..5a4cc1a 100644
--- a/arch/arm/common/Makefile
+++ b/arch/arm/common/Makefile
@@ -10,4 +10,3 @@ obj-$(CONFIG_SHARP_LOCOMO)	+= locomo.o
 obj-$(CONFIG_SHARP_PARAM)	+= sharpsl_param.o
 obj-$(CONFIG_SHARP_SCOOP)	+= scoop.o
 obj-$(CONFIG_PCI_HOST_ITE8152)  += it8152.o
-obj-$(CONFIG_ARM_TIMER_SP804)	+= timer-sp.o
diff --git a/arch/arm/mach-integrator/Kconfig b/arch/arm/mach-integrator/Kconfig
index abeff25..c5e4ff3 100644
--- a/arch/arm/mach-integrator/Kconfig
+++ b/arch/arm/mach-integrator/Kconfig
@@ -5,6 +5,7 @@ menu "Integrator Options"
 config ARCH_INTEGRATOR_AP
 	bool "Support Integrator/AP and Integrator/PP2 platforms"
 	select CLKSRC_MMIO
+	select INTEGRATOR_AP_TIMER
 	select MIGHT_HAVE_PCI
 	select SERIAL_AMBA_PL010
 	select SERIAL_AMBA_PL010_CONSOLE
diff --git a/arch/arm/mach-integrator/integrator_ap.c b/arch/arm/mach-integrator/integrator_ap.c
index ea96144..c364e8e 100644
--- a/arch/arm/mach-integrator/integrator_ap.c
+++ b/arch/arm/mach-integrator/integrator_ap.c
@@ -27,8 +27,6 @@
 #include <linux/syscore_ops.h>
 #include <linux/amba/bus.h>
 #include <linux/amba/kmi.h>
-#include <linux/clocksource.h>
-#include <linux/clockchips.h>
 #include <linux/interrupt.h>
 #include <linux/io.h>
 #include <linux/irqchip/versatile-fpga.h>
@@ -41,15 +39,15 @@
 #include <linux/stat.h>
 #include <linux/sys_soc.h>
 #include <linux/termios.h>
+#include <clocksource/arm_timer.h>
+#include <clocksource/integrator_ap_timer.h>
 #include <video/vga.h>
 
 #include <mach/hardware.h>
 #include <mach/platform.h>
-#include <asm/hardware/arm_timer.h>
 #include <asm/setup.h>
 #include <asm/param.h>		/* HZ */
 #include <asm/mach-types.h>
-#include <asm/sched_clock.h>
 
 #include <mach/lm.h>
 #include <mach/irqs.h>
@@ -58,7 +56,6 @@
 #include <asm/mach/irq.h>
 #include <asm/mach/map.h>
 #include <asm/mach/pci.h>
-#include <asm/mach/time.h>
 
 #include "common.h"
 
@@ -296,174 +293,12 @@ struct amba_pl010_data ap_uart_data = {
 #define TIMER1_VA_BASE __io_address(INTEGRATOR_TIMER1_BASE)
 #define TIMER2_VA_BASE __io_address(INTEGRATOR_TIMER2_BASE)
 
-static unsigned long timer_reload;
-
-static u32 notrace integrator_read_sched_clock(void)
-{
-	return -readl((void __iomem *) TIMER2_VA_BASE + TIMER_VALUE);
-}
-
-static void integrator_clocksource_init(unsigned long inrate,
-					void __iomem *base)
-{
-	u32 ctrl = TIMER_CTRL_ENABLE | TIMER_CTRL_PERIODIC;
-	unsigned long rate = inrate;
-
-	if (rate >= 1500000) {
-		rate /= 16;
-		ctrl |= TIMER_CTRL_DIV16;
-	}
-
-	writel(0xffff, base + TIMER_LOAD);
-	writel(ctrl, base + TIMER_CTRL);
-
-	clocksource_mmio_init(base + TIMER_VALUE, "timer2",
-			rate, 200, 16, clocksource_mmio_readl_down);
-	setup_sched_clock(integrator_read_sched_clock, 16, rate);
-}
-
-static void __iomem * clkevt_base;
-
-/*
- * IRQ handler for the timer
- */
-static irqreturn_t integrator_timer_interrupt(int irq, void *dev_id)
-{
-	struct clock_event_device *evt = dev_id;
-
-	/* clear the interrupt */
-	writel(1, clkevt_base + TIMER_INTCLR);
-
-	evt->event_handler(evt);
-
-	return IRQ_HANDLED;
-}
-
-static void clkevt_set_mode(enum clock_event_mode mode, struct clock_event_device *evt)
-{
-	u32 ctrl = readl(clkevt_base + TIMER_CTRL) & ~TIMER_CTRL_ENABLE;
-
-	/* Disable timer */
-	writel(ctrl, clkevt_base + TIMER_CTRL);
-
-	switch (mode) {
-	case CLOCK_EVT_MODE_PERIODIC:
-		/* Enable the timer and start the periodic tick */
-		writel(timer_reload, clkevt_base + TIMER_LOAD);
-		ctrl |= TIMER_CTRL_PERIODIC | TIMER_CTRL_ENABLE;
-		writel(ctrl, clkevt_base + TIMER_CTRL);
-		break;
-	case CLOCK_EVT_MODE_ONESHOT:
-		/* Leave the timer disabled, .set_next_event will enable it */
-		ctrl &= ~TIMER_CTRL_PERIODIC;
-		writel(ctrl, clkevt_base + TIMER_CTRL);
-		break;
-	case CLOCK_EVT_MODE_UNUSED:
-	case CLOCK_EVT_MODE_SHUTDOWN:
-	case CLOCK_EVT_MODE_RESUME:
-	default:
-		/* Just leave in disabled state */
-		break;
-	}
-
-}
-
-static int clkevt_set_next_event(unsigned long next, struct clock_event_device *evt)
-{
-	unsigned long ctrl = readl(clkevt_base + TIMER_CTRL);
-
-	writel(ctrl & ~TIMER_CTRL_ENABLE, clkevt_base + TIMER_CTRL);
-	writel(next, clkevt_base + TIMER_LOAD);
-	writel(ctrl | TIMER_CTRL_ENABLE, clkevt_base + TIMER_CTRL);
-
-	return 0;
-}
-
-static struct clock_event_device integrator_clockevent = {
-	.name		= "timer1",
-	.features	= CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT,
-	.set_mode	= clkevt_set_mode,
-	.set_next_event	= clkevt_set_next_event,
-	.rating		= 300,
-};
-
-static struct irqaction integrator_timer_irq = {
-	.name		= "timer",
-	.flags		= IRQF_DISABLED | IRQF_TIMER | IRQF_IRQPOLL,
-	.handler	= integrator_timer_interrupt,
-	.dev_id		= &integrator_clockevent,
-};
-
-static void integrator_clockevent_init(unsigned long inrate,
-				void __iomem *base, int irq)
-{
-	unsigned long rate = inrate;
-	unsigned int ctrl = 0;
-
-	clkevt_base = base;
-	/* Calculate and program a divisor */
-	if (rate > 0x100000 * HZ) {
-		rate /= 256;
-		ctrl |= TIMER_CTRL_DIV256;
-	} else if (rate > 0x10000 * HZ) {
-		rate /= 16;
-		ctrl |= TIMER_CTRL_DIV16;
-	}
-	timer_reload = rate / HZ;
-	writel(ctrl, clkevt_base + TIMER_CTRL);
-
-	setup_irq(irq, &integrator_timer_irq);
-	clockevents_config_and_register(&integrator_clockevent,
-					rate,
-					1,
-					0xffffU);
-}
-
 void __init ap_init_early(void)
 {
 }
 
 #ifdef CONFIG_OF
 
-static void __init ap_of_timer_init(void)
-{
-	struct device_node *node;
-	const char *path;
-	void __iomem *base;
-	int err;
-	int irq;
-	struct clk *clk;
-	unsigned long rate;
-
-	clk = clk_get_sys("ap_timer", NULL);
-	BUG_ON(IS_ERR(clk));
-	clk_prepare_enable(clk);
-	rate = clk_get_rate(clk);
-
-	err = of_property_read_string(of_aliases,
-				"arm,timer-primary", &path);
-	if (WARN_ON(err))
-		return;
-	node = of_find_node_by_path(path);
-	base = of_iomap(node, 0);
-	if (WARN_ON(!base))
-		return;
-	writel(0, base + TIMER_CTRL);
-	integrator_clocksource_init(rate, base);
-
-	err = of_property_read_string(of_aliases,
-				"arm,timer-secondary", &path);
-	if (WARN_ON(err))
-		return;
-	node = of_find_node_by_path(path);
-	base = of_iomap(node, 0);
-	if (WARN_ON(!base))
-		return;
-	irq = irq_of_parse_and_map(node, 0);
-	writel(0, base + TIMER_CTRL);
-	integrator_clockevent_init(rate, base, irq);
-}
-
 static const struct of_device_id fpga_irq_of_match[] __initconst = {
 	{ .compatible = "arm,versatile-fpga-irq", .data = fpga_irq_of_init, },
 	{ /* Sentinel */ }
@@ -582,7 +417,6 @@ DT_MACHINE_START(INTEGRATOR_AP_DT, "ARM Integrator/AP (Device Tree)")
 	.init_early	= ap_init_early,
 	.init_irq	= ap_init_irq_of,
 	.handle_irq	= fpga_handle_irq,
-	.init_time	= ap_of_timer_init,
 	.init_machine	= ap_init_of,
 	.restart	= integrator_restart,
 	.dt_compat      = ap_dt_board_compat,
diff --git a/arch/arm/mach-integrator/integrator_cp.c b/arch/arm/mach-integrator/integrator_cp.c
index 5781f3c..19e2497 100644
--- a/arch/arm/mach-integrator/integrator_cp.c
+++ b/arch/arm/mach-integrator/integrator_cp.c
@@ -28,12 +28,13 @@
 #include <linux/of_address.h>
 #include <linux/of_platform.h>
 #include <linux/sys_soc.h>
+#include <clocksource/arm_timer.h>
+#include <clocksource/timer-sp.h>
 
 #include <mach/hardware.h>
 #include <mach/platform.h>
 #include <asm/setup.h>
 #include <asm/mach-types.h>
-#include <asm/hardware/arm_timer.h>
 #include <asm/hardware/icst.h>
 
 #include <mach/cm.h>
@@ -45,8 +46,6 @@
 #include <asm/mach/map.h>
 #include <asm/mach/time.h>
 
-#include <asm/hardware/timer-sp.h>
-
 #include <plat/clcd.h>
 #include <plat/sched_clock.h>
 
diff --git a/arch/arm/mach-realview/core.c b/arch/arm/mach-realview/core.c
index 1d5ee5c..ac59770 100644
--- a/arch/arm/mach-realview/core.c
+++ b/arch/arm/mach-realview/core.c
@@ -31,21 +31,20 @@
 #include <linux/amba/mmci.h>
 #include <linux/gfp.h>
 #include <linux/mtd/physmap.h>
+#include <clocksource/arm_timer.h>
+#include <clocksource/timer-sp.h>
 
 #include <mach/hardware.h>
 #include <asm/irq.h>
 #include <asm/mach-types.h>
-#include <asm/hardware/arm_timer.h>
 #include <asm/hardware/icst.h>
 
 #include <asm/mach/arch.h>
 #include <asm/mach/irq.h>
 #include <asm/mach/map.h>
 
-
 #include <mach/platform.h>
 #include <mach/irqs.h>
-#include <asm/hardware/timer-sp.h>
 
 #include <plat/clcd.h>
 #include <plat/sched_clock.h>
diff --git a/arch/arm/mach-versatile/core.c b/arch/arm/mach-versatile/core.c
index 54bb80b..84f26c7 100644
--- a/arch/arm/mach-versatile/core.c
+++ b/arch/arm/mach-versatile/core.c
@@ -38,9 +38,10 @@
 #include <linux/clkdev.h>
 #include <linux/mtd/physmap.h>
 #include <linux/bitops.h>
+#include <clocksource/arm_timer.h>
+#include <clocksource/timer-sp.h>
 
 #include <asm/irq.h>
-#include <asm/hardware/arm_timer.h>
 #include <asm/hardware/icst.h>
 #include <asm/mach-types.h>
 
@@ -50,7 +51,6 @@
 #include <asm/mach/map.h>
 #include <mach/hardware.h>
 #include <mach/platform.h>
-#include <asm/hardware/timer-sp.h>
 
 #include <plat/clcd.h>
 #include <plat/sched_clock.h>
diff --git a/arch/arm/mach-vexpress/ct-ca9x4.c b/arch/arm/mach-vexpress/ct-ca9x4.c
index 6f34497..8cce326 100644
--- a/arch/arm/mach-vexpress/ct-ca9x4.c
+++ b/arch/arm/mach-vexpress/ct-ca9x4.c
@@ -11,16 +11,14 @@
 #include <linux/clkdev.h>
 #include <linux/vexpress.h>
 #include <linux/irqchip/arm-gic.h>
+#include <clocksource/timer-sp.h>
 
-#include <asm/hardware/arm_timer.h>
 #include <asm/hardware/cache-l2x0.h>
 #include <asm/smp_scu.h>
 #include <asm/smp_twd.h>
 
 #include <mach/ct-ca9x4.h>
 
-#include <asm/hardware/timer-sp.h>
-
 #include <asm/mach/map.h>
 #include <asm/mach/time.h>
 
diff --git a/arch/arm/mach-vexpress/v2m.c b/arch/arm/mach-vexpress/v2m.c
index 09e571d..dc15485 100644
--- a/arch/arm/mach-vexpress/v2m.c
+++ b/arch/arm/mach-vexpress/v2m.c
@@ -23,15 +23,15 @@
 #include <linux/regulator/fixed.h>
 #include <linux/regulator/machine.h>
 #include <linux/vexpress.h>
+#include <clocksource/arm_timer.h>
+#include <clocksource/timer-sp.h>
 
 #include <asm/mach-types.h>
 #include <asm/sizes.h>
 #include <asm/mach/arch.h>
 #include <asm/mach/map.h>
 #include <asm/mach/time.h>
-#include <asm/hardware/arm_timer.h>
 #include <asm/hardware/cache-l2x0.h>
-#include <asm/hardware/timer-sp.h>
 
 #include <mach/ct-ca9x4.h>
 #include <mach/motherboard.h>
diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index d98e7e1..00aa4cd 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -25,6 +25,18 @@ config DW_APB_TIMER_OF
 config ARMADA_370_XP_TIMER
 	bool
 
+config ARM_TIMER_SP804
+	bool
+	depends on ARM
+	select CLKSRC_MMIO
+	select CLKSRC_OF if OF
+	select HAVE_SCHED_CLOCK
+
+config INTEGRATOR_AP_TIMER
+	bool
+	depends on ARM
+	select CLKSRC_OF if OF
+
 config SUNXI_TIMER
 	bool
 
diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index 4d8283a..9f3b62b 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -14,8 +14,10 @@ obj-$(CONFIG_DW_APB_TIMER)	+= dw_apb_timer.o
 obj-$(CONFIG_DW_APB_TIMER_OF)	+= dw_apb_timer_of.o
 obj-$(CONFIG_CLKSRC_NOMADIK_MTU)	+= nomadik-mtu.o
 obj-$(CONFIG_CLKSRC_DBX500_PRCMU)	+= clksrc-dbx500-prcmu.o
+obj-$(CONFIG_ARM_TIMER_SP804)	+= timer-sp.o
 obj-$(CONFIG_ARMADA_370_XP_TIMER)	+= time-armada-370-xp.o
 obj-$(CONFIG_ARCH_BCM2835)	+= bcm2835_timer.o
+obj-$(CONFIG_INTEGRATOR_AP_TIMER)	+= integrator_ap_timer.o
 obj-$(CONFIG_SUNXI_TIMER)	+= sunxi_timer.o
 obj-$(CONFIG_ARCH_TEGRA)	+= tegra20_timer.o
 obj-$(CONFIG_VT8500_TIMER)	+= vt8500_timer.o
diff --git a/drivers/clocksource/integrator_ap_timer.c b/drivers/clocksource/integrator_ap_timer.c
new file mode 100644
index 0000000..05e6204
--- /dev/null
+++ b/drivers/clocksource/integrator_ap_timer.c
@@ -0,0 +1,189 @@
+/*
+ *  Copyright (C) 2000-2003 Deep Blue Solutions Ltd
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+#include <linux/types.h>
+#include <linux/init.h>
+#include <linux/clocksource.h>
+#include <linux/clockchips.h>
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/irq.h>
+#include <linux/clk.h>
+#include <linux/of_irq.h>
+#include <linux/of_address.h>
+#include <linux/of_platform.h>
+#include <clocksource/timer-sp.h>
+#include <clocksource/arm_timer.h>
+
+#include <asm/sched_clock.h>
+
+static unsigned long timer_reload;
+static void __iomem *clksrc_base;
+
+static u32 notrace integrator_read_sched_clock(void)
+{
+	return -readl(clksrc_base + TIMER_VALUE);
+}
+
+void __init integrator_clocksource_init(unsigned long inrate,
+					void __iomem *base)
+{
+	u32 ctrl = TIMER_CTRL_ENABLE | TIMER_CTRL_PERIODIC;
+	unsigned long rate = inrate;
+
+	clksrc_base = base;
+
+	if (rate >= 1500000) {
+		rate /= 16;
+		ctrl |= TIMER_CTRL_DIV16;
+	}
+
+	writel(0xffff, base + TIMER_LOAD);
+	writel(ctrl, base + TIMER_CTRL);
+
+	clocksource_mmio_init(base + TIMER_VALUE, "timer2",
+			rate, 200, 16, clocksource_mmio_readl_down);
+	setup_sched_clock(integrator_read_sched_clock, 16, rate);
+}
+
+static void __iomem * clkevt_base;
+
+/*
+ * IRQ handler for the timer
+ */
+static irqreturn_t integrator_timer_interrupt(int irq, void *dev_id)
+{
+	struct clock_event_device *evt = dev_id;
+
+	/* clear the interrupt */
+	writel(1, clkevt_base + TIMER_INTCLR);
+
+	evt->event_handler(evt);
+
+	return IRQ_HANDLED;
+}
+
+static void clkevt_set_mode(enum clock_event_mode mode, struct clock_event_device *evt)
+{
+	u32 ctrl = readl(clkevt_base + TIMER_CTRL) & ~TIMER_CTRL_ENABLE;
+
+	/* Disable timer */
+	writel(ctrl, clkevt_base + TIMER_CTRL);
+
+	switch (mode) {
+	case CLOCK_EVT_MODE_PERIODIC:
+		/* Enable the timer and start the periodic tick */
+		writel(timer_reload, clkevt_base + TIMER_LOAD);
+		ctrl |= TIMER_CTRL_PERIODIC | TIMER_CTRL_ENABLE;
+		writel(ctrl, clkevt_base + TIMER_CTRL);
+		break;
+	case CLOCK_EVT_MODE_ONESHOT:
+		/* Leave the timer disabled, .set_next_event will enable it */
+		ctrl &= ~TIMER_CTRL_PERIODIC;
+		writel(ctrl, clkevt_base + TIMER_CTRL);
+		break;
+	case CLOCK_EVT_MODE_UNUSED:
+	case CLOCK_EVT_MODE_SHUTDOWN:
+	case CLOCK_EVT_MODE_RESUME:
+	default:
+		/* Just leave in disabled state */
+		break;
+	}
+
+}
+
+static int clkevt_set_next_event(unsigned long next, struct clock_event_device *evt)
+{
+	unsigned long ctrl = readl(clkevt_base + TIMER_CTRL);
+
+	writel(ctrl & ~TIMER_CTRL_ENABLE, clkevt_base + TIMER_CTRL);
+	writel(next, clkevt_base + TIMER_LOAD);
+	writel(ctrl | TIMER_CTRL_ENABLE, clkevt_base + TIMER_CTRL);
+
+	return 0;
+}
+
+static struct clock_event_device integrator_clockevent = {
+	.name		= "timer1",
+	.features	= CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT,
+	.set_mode	= clkevt_set_mode,
+	.set_next_event	= clkevt_set_next_event,
+	.rating		= 300,
+};
+
+static struct irqaction integrator_timer_irq = {
+	.name		= "timer",
+	.flags		= IRQF_DISABLED | IRQF_TIMER | IRQF_IRQPOLL,
+	.handler	= integrator_timer_interrupt,
+	.dev_id		= &integrator_clockevent,
+};
+
+void __init integrator_clockevent_init(unsigned long inrate,
+				       void __iomem *base, int irq)
+{
+	unsigned long rate = inrate;
+	unsigned int ctrl = 0;
+
+	clkevt_base = base;
+	/* Calculate and program a divisor */
+	if (rate > 0x100000 * HZ) {
+		rate /= 256;
+		ctrl |= TIMER_CTRL_DIV256;
+	} else if (rate > 0x10000 * HZ) {
+		rate /= 16;
+		ctrl |= TIMER_CTRL_DIV16;
+	}
+	timer_reload = rate / HZ;
+	writel(ctrl, clkevt_base + TIMER_CTRL);
+
+	setup_irq(irq, &integrator_timer_irq);
+	clockevents_config_and_register(&integrator_clockevent,
+					rate,
+					1,
+					0xffffU);
+}
+
+static void __init ap_of_timer_init(struct device_node *node)
+{
+	void __iomem *base;
+	int irq;
+	struct clk *clk;
+	unsigned long rate;
+
+	clk = clk_get_sys("ap_timer", NULL);
+	BUG_ON(IS_ERR(clk));
+	clk_prepare_enable(clk);
+	rate = clk_get_rate(clk);
+
+	base = of_iomap(node, 0);
+	if (WARN_ON(!base))
+		return;
+
+	writel(0, base + TIMER_CTRL);
+
+	if ((clksrc_base && clkevt_base) || !of_device_is_available(node)) {
+		iounmap(base);
+		return;
+	}
+
+	irq = irq_of_parse_and_map(node, 0);
+	if (!clkevt_base && (irq > 0))
+		integrator_clockevent_init(rate, base, irq);
+	else
+		integrator_clocksource_init(rate, base);
+}
+CLOCKSOURCE_OF_DECLARE(integrator_ap, "integrator-timer", ap_of_timer_init);
diff --git a/arch/arm/common/timer-sp.c b/drivers/clocksource/timer-sp.c
similarity index 98%
rename from arch/arm/common/timer-sp.c
rename to drivers/clocksource/timer-sp.c
index ddc7407..b0fc7f0 100644
--- a/arch/arm/common/timer-sp.c
+++ b/drivers/clocksource/timer-sp.c
@@ -1,6 +1,4 @@
 /*
- *  linux/arch/arm/common/timer-sp.c
- *
  *  Copyright (C) 1999 - 2003 ARM Limited
  *  Copyright (C) 2000 Deep Blue Solutions Ltd
  *
@@ -28,10 +26,10 @@
 #include <linux/of.h>
 #include <linux/of_address.h>
 #include <linux/of_irq.h>
+#include <clocksource/arm_timer.h>
+#include <clocksource/timer-sp.h>
 
 #include <asm/sched_clock.h>
-#include <asm/hardware/arm_timer.h>
-#include <asm/hardware/timer-sp.h>
 
 static long __init sp804_get_clock_rate(struct clk *clk)
 {
diff --git a/arch/arm/include/asm/hardware/arm_timer.h b/include/clocksource/arm_timer.h
similarity index 93%
rename from arch/arm/include/asm/hardware/arm_timer.h
rename to include/clocksource/arm_timer.h
index d6030ff..f4a443a 100644
--- a/arch/arm/include/asm/hardware/arm_timer.h
+++ b/include/clocksource/arm_timer.h
@@ -1,5 +1,5 @@
-#ifndef __ASM_ARM_HARDWARE_ARM_TIMER_H
-#define __ASM_ARM_HARDWARE_ARM_TIMER_H
+#ifndef __CLOCKSOURCE_ARM_TIMER_H
+#define __CLOCKSOURCE_ARM_TIMER_H
 
 /*
  * ARM timer implementation, found in Integrator, Versatile and Realview
diff --git a/include/clocksource/integrator_ap_timer.h b/include/clocksource/integrator_ap_timer.h
new file mode 100644
index 0000000..2f585fc
--- /dev/null
+++ b/include/clocksource/integrator_ap_timer.h
@@ -0,0 +1,7 @@
+#ifndef __CLOCKSOURCE_INTEGRATOR_AP_TIMER
+#define __CLOCKSOURCE_INTEGRATOR_AP_TIMER
+
+void integrator_clocksource_init(unsigned long inrate, void __iomem *base);
+void integrator_clockevent_init(unsigned long inrate, void __iomem *base, int irq);
+
+#endif
diff --git a/arch/arm/include/asm/hardware/timer-sp.h b/include/clocksource/timer-sp.h
similarity index 100%
rename from arch/arm/include/asm/hardware/timer-sp.h
rename to include/clocksource/timer-sp.h
-- 
1.7.10.4



From sylvester.nawrocki at gmail.com  Mon Apr  1 18:27:36 2013
From: sylvester.nawrocki at gmail.com (Sylwester Nawrocki)
Date: Tue, 02 Apr 2013 00:27:36 +0200
Subject: [PATCH v4 1/6] drivers: phy: add generic PHY framework
In-Reply-To: <1364449408-9510-2-git-send-email-kishon@ti.com>
References: <1364449408-9510-1-git-send-email-kishon@ti.com>
 <1364449408-9510-2-git-send-email-kishon@ti.com>
Message-ID: <515A09D8.7040703@gmail.com>

On 03/28/2013 06:43 AM, Kishon Vijay Abraham I wrote:
> diff --git a/Documentation/devicetree/bindings/phy/phy-bindings.txt
>b/Documentation/devicetree/bindings/phy/phy-bindings.txt
> new file mode 100644
> index 0000000..35696b2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/phy-bindings.txt
> @@ -0,0 +1,76 @@
> +This document explains only the dt data binding. For general information about
> +PHY subsystem refer Documentation/phy.txt
> +
> +PHY device node
> +===============
> +
> +Optional Properties:
> +#phy-cells:	Number of cells in a PHY specifier;  The meaning of all those
> +		cells is defined by the binding for the phy node. However
> +		in-order to return the correct PHY, the PHY susbsystem
> +		requires the first cell always refers to the port.
> +
> +This property is optional because it is needed only for the case where a
> +single IP implements multiple PHYs.
> +
> +For example:
> +
> +phys: phy {
> +    compatible = "xxx";
> +    reg1 =<...>;
> +    reg2 =<...>;
> +    reg3 =<...>;
> +    .
> +    .
> +    #phy-cells =<1>;
> +    .
> +    .
> +};
> +
> +That node describes an IP block that implements 3 different PHYs. In order to
> +differentiate between these 3 PHYs, an additonal specifier should be given
> +while trying to get a reference to it. (The PHY subsystem assumes the
> +specifier is port id).
> +
> +PHY user node
> +=============
> +
> +Required Properties:
> +phys : the phandle for the PHY device (used by the PHY subsystem)
> +
> +Optional properties:
> +phy-names : the names of the PHY corresponding to the PHYs present in the
> +	    *phys* phandle
> +
> +example1:
> +phys: phy {
> +    compatible = "xxx";
> +    reg =<...>;
> +    .
> +    .
> +    phys =<&usb2_phy>,<&usb3_phy>;
> +    phy-names = "usb2phy", "usb3phy";
> +    .
> +    .
> +};
> +This node represents a controller that uses two PHYs one for usb2 and one for
> +usb3. The controller driver can get the appropriate PHY either by using
> +devm_of_phy_get/of_phy_get by passing the correct index or by using
> +of_phy_get_byname/devm_of_phy_get_byname by passing the names given in
> +*phy-names*.
> +
> +example2:
> +phys: phy {
> +    compatible = "xxx";
> +    reg =<...>;
> +    .
> +    .
> +    phys =<&phys 1>;
> +    .
> +    .
> +};
> +
> +This node represents a controller that uses one of the PHYs which is defined
> +previously. Note that the phy handle has an additional specifier "1" to
> +differentiate between the three PHYs. For this case, the controller driver
> +should use of_phy_get_with_args/devm_of_phy_get_with_args.

This means a PHY user needs to know indexes at the PHY driver ?

I have been thinking of using this for an IP which has 4 video PHYs: 2 MIPI
CSI-2 and 2 MIPI DSI. The IP has just 2 registers, each of which is shared
between one MIPI CSI-2 DPHY and one MIPI DSI DPHY. So I thought about 
creating
a single device node for this IP and using 4 indexes for the PHYs, e.g. 
0...3.
Then users of each PHY type would use only indexes 0..1 (to select their
corresponding port).

However I fail to see how this could now be represented in the bindings.

I assume struct phy::type could be used to differentiate between CSI-2 
and DSI.
And struct phy::port could be used to select specific CSI-2 or DSI channel
(0, 1). Ideally the phy users should not care about index of a PHY at 
the PHY
device tree node. E.g. there are 2 MIPI CSI-2 receivers and each has only
one PHY assigned to it. I'm just wondering how the binding should look like,
so a PHY could be associated with a receiver automatically by the phy-core,
e.g.

/* DPHY IP node */
video-phy {
	  reg = <0x10000000 8>;
};

/* MIPI DSI nodes */
dsi_0 {
      phys = <&video-phy 0>;
};

dsi_1 {
      phys = <&video-phy 1>;
};

/* MIPI CSI-2 nodes */
csi_0 {
      phys = <&video-phy 2>;
};

csi_1 {
      phys = <&video-phy 3>;
};

I'm not sure if it is not an overkill to use this the PHY framework with
a device which has only 2 registers. Perhaps something less heavy could
be designed for it. However, if the PHY framework is commonly used there
should be no issue wrt enabling the whole big infrastructure for a simple
device like this.


Thanks,
Sylwester


From jason at lakedaemon.net  Mon Apr  1 18:32:36 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Mon, 1 Apr 2013 18:32:36 -0400
Subject: [PATCH 0/3] add devicetree bindings for rtc-m48t86
In-Reply-To: <515A0632.3040902@gmail.com>
References: <1364766971-5914-1-git-send-email-alex@digriz.org.uk>
 <5159FFAA.5030205@gmail.com> <515A0632.3040902@gmail.com>
Message-ID: <20130401223236.GQ13280@titan.lakedaemon.net>

On Tue, Apr 02, 2013 at 09:12:02AM +1100, Ryan Mallon wrote:
> On 02/04/13 08:44, Ryan Mallon wrote:
> > On 01/04/13 08:56, Alexander Clouter wrote:
> >> Currently there are two users of rtc-m48t86 (mach-ep93xx/ts72xx.c and
> >> mach-orion5x/ts78xx-setup.c) and both just use {read,write}b against
> >> a memory mapped region.  As I am devicetree'ing the TS-7800, this
> >> driver needs converting and thats what this patchset does.
> >>
> >> The patch does the following:
> >>  * remove platform specific ops hooks, moving ioremap'ing and
> >> 	everything into the driver
> >>  * utilises named resources to indicate index/data ranges
> >>  * moves the RTC detection routine from ts78xx-setup.c into rtc-m48t86.c
> >>  * and, of course, enable devicetree hooks and include documentation
> >>
> >> Awkward step, the first patch breaks both boards, the two following
> >> patches fix them.  Happy to re-work this if folks give me a pointer
> >> on how to do this in an acceptable way.
> > 
> > Sorry, that's no good. It breaks things like git bisect.
> > 
> >>
> >> My vote is to break fast, fix fast, spend the time writing other code :)
> > 
> > The patch series will need to be reworked so that there is no
> > build/runtime breakage between any of the patches. I'll have a read
> > through and see if I can suggest something.
> 
> So looking through the patches, you are going to need to modify the rtc
> driver and the platform code in the same patch at least once since you
> are changing the interface. You could break the patches down like this:
> 
> 1) Move the rtc detection from the orion5x board to the rtc driver.
>    This adds the detection support for the ep93xx board also.
> 
> 2) Replace the board read/write ops structure with ioremapped regions.
> 
> 3) Add the device tree bindings to the rtc driver.
> 
> The first two patches could be combined, but will touch both the rtc
> driver and the platform code, and do the prep work needed for adding the
> dt bindings. 

Please keep me and Andrew Lunn in the Cc: and once we see the final
series, I'll ack the platform changes for going though the rtc tree.
It's best to keep this series together, and the changes to the platform
code should be pretty isolated from other changes we are doing.

thx,

Jason.


From swarren at wwwdotorg.org  Mon Apr  1 18:38:40 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Mon, 01 Apr 2013 16:38:40 -0600
Subject: [PATCH v4 1/6] drivers: phy: add generic PHY framework
In-Reply-To: <515A09D8.7040703@gmail.com>
References: <1364449408-9510-1-git-send-email-kishon@ti.com>
 <1364449408-9510-2-git-send-email-kishon@ti.com> <515A09D8.7040703@gmail.com>
Message-ID: <515A0C70.90201@wwwdotorg.org>

On 04/01/2013 04:27 PM, Sylwester Nawrocki wrote:
> On 03/28/2013 06:43 AM, Kishon Vijay Abraham I wrote:
>> diff --git a/Documentation/devicetree/bindings/phy/phy-bindings.txt

>> +example2:
>> +phys: phy {
>> +    compatible = "xxx";
>> +    reg =<...>;
>> +    .
>> +    .
>> +    phys =<&phys 1>;
>> +    .
>> +    .
>> +};
>> +
>> +This node represents a controller that uses one of the PHYs which is defined
>> +previously. Note that the phy handle has an additional specifier "1" to
>> +differentiate between the three PHYs. For this case, the controller driver
>> +should use of_phy_get_with_args/devm_of_phy_get_with_args.
> 
> This means a PHY user needs to know indexes at the PHY driver ?

The client node's DT has to specify which of the provider's PHYs it
references, yes. Presumably the device driver for the client node knows
absolutely nothing about this.

> I have been thinking of using this for an IP which has 4 video PHYs: 2 MIPI
> CSI-2 and 2 MIPI DSI. The IP has just 2 registers, each of which is shared
> between one MIPI CSI-2 DPHY and one MIPI DSI DPHY. So I thought about creating
> a single device node for this IP and using 4 indexes for the PHYs, e.g. 0...3.

That sounds right.

> Then users of each PHY type would use only indexes 0..1 (to select their
> corresponding port).

I don't follow that. If the provider exports PHYs 0..3, then the client
nodes would refer to PHYS 0..3 not 0..1.

> However I fail to see how this could now be represented in the bindings.

Exactly like the example you gave below, I would expect.

> I assume struct phy::type could be used to differentiate between CSI-2 and DSI.
> And struct phy::port could be used to select specific CSI-2 or DSI channel
> (0, 1). Ideally the phy users should not care about index of a PHY at the PHY
> device tree node. E.g. there are 2 MIPI CSI-2 receivers and each has only
> one PHY assigned to it. I'm just wondering how the binding should look like,
> so a PHY could be associated with a receiver automatically by the phy-core,
> e.g.

Details such as phy::type and phy::port sounds like internal driver
implementation details which would have no effect on the bindings.

> /* DPHY IP node */
> video-phy {
>       reg = <0x10000000 8>;
> };
> 
> /* MIPI DSI nodes */
> dsi_0 {
>      phys = <&video-phy 0>;
> };
> 
> dsi_1 {
>      phys = <&video-phy 1>;
> };
> 
> /* MIPI CSI-2 nodes */
> csi_0 {
>      phys = <&video-phy 2>;
> };
> 
> csi_1 {
>      phys = <&video-phy 3>;
> };

That looks correct to me.

> I'm not sure if it is not an overkill to use this the PHY framework with
> a device which has only 2 registers. Perhaps something less heavy could
> be designed for it. However, if the PHY framework is commonly used there
> should be no issue wrt enabling the whole big infrastructure for a simple
> device like this.

I don't think the number of registers should really makes any
difference; the whole point of the PHY framework is to decouple to
providers and consumers, so doing anything custom for special cases
would completely destroy the ability of the PHY framework to do that.


From robherring2 at gmail.com  Mon Apr  1 18:40:32 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Mon, 01 Apr 2013 17:40:32 -0500
Subject: [PATCH 08/10] arm: zynq: Add smp support
In-Reply-To: <CAHTX3dLD6gPG-1nzbk9gcsiO=SAq7UKDa7vvOOYHvTHt8zJhUg@mail.gmail.com>
References: <1364219596-4954-1-git-send-email-michal.simek@xilinx.com>
 <1364219596-4954-8-git-send-email-michal.simek@xilinx.com>
 <51505C39.4060507@gmail.com> <51507BCC.2050707@monstr.eu>
 <5150CB64.5030502@gmail.com>
 <CAHTX3dLD6gPG-1nzbk9gcsiO=SAq7UKDa7vvOOYHvTHt8zJhUg@mail.gmail.com>
Message-ID: <515A0CE0.7050401@gmail.com>

On 03/26/2013 02:42 AM, Michal Simek wrote:
> 2013/3/25 Rob Herring <robherring2 at gmail.com>:
>> On 03/25/2013 11:31 AM, Michal Simek wrote:
>>> On 03/25/2013 03:16 PM, Rob Herring wrote:
>>>> On 03/25/2013 08:53 AM, Michal Simek wrote:
>>>>> Zynq is dual core Cortex A9 which starts always
>>>>> at zero. Using simple trampoline ensure long jump
>>>>> to secondary_startup code.

[...]

>>>>> +        slcr_cpu_stop(cpu);
>>>>
>>>> Isn't a secondary cpu already stopped?
>>>
>>> On the normal boot this is really necessary because first stage bootloader
>>> doesn't stop cpu just keep it in loop and without stopping cpu
>>> and starting it again it doesn't work.
>>
>> And there is no way to exit the loop other than a reset?
> 
> You can exit the loop by writing jump address to one location where bootloader
> expect it. Then it jumps to proper function and it was done like that before.
> But this is not suitable for cpu hotplug because that loop is placed
> in OCM (on chip memory)
> and it can be used for different purpose.
> Also there is no way how to return cpu to this mode.

I was asking about the cold boot case, not hotplug. If you are spinning
in the bootloader waiting for a jump address, then why do you need the
slcr_cpu_stop for cold boot? In the hotplug case, you have already
called slcr_cpu_stop in the unplug path, so this shouldn't be needed
there either.

[...]

>>>>> +            __raw_writel(address, phys_to_virt(0x8));
>>
>> This should be a per core address including core 0 if you ever want to
>> do something like cpuidle powergating on one core and hotplug on another.
> 
> That's interesting idea.
> Please correct me if I am wrong, I didn't play with cpuidle.
> 
> Zynq is dual core and hotplug can be done only on cpu1. (not sure if
> in general cpu0
> can be unplugged too. If yes, are you doing that?).

You cannot do hotplug on cpu 0, but that is a current Linux limitation.
I believe support to hotplug cpu 0 was recently added for x86. So this
may change at some point.

What the h/w can support is another issue. Some chips have independent
power domains per core and some have combined domains. I can and do
powergate individual cores including core 0 in cpuidle for highbank. The
main difference to hotplug is whether I set the wake-up address when I
go down (cpuidle) or when I wake the core (hotplug). For hotplug, you
don't want the core to come back before the kernel is ready for it.

> I didn't play with cpuidle code but I am not quite sure if you can use hotplug
> if cpu0 is in idle because this code is for >cpu0.
> 
> I can imagine to be more flexible on quad core where your comment make
> definitely sense.

The next part could be quad core...

Rob



From robherring2 at gmail.com  Mon Apr  1 19:07:10 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Mon,  1 Apr 2013 18:07:10 -0500
Subject: [PATCH v2] ARM: highbank: adapt to use ARM PSCI calls
Message-ID: <1364857630-8099-1-git-send-email-robherring2@gmail.com>

From: Rob Herring <rob.herring at calxeda.com>

This adapts highbank to use the psci_smp_ops. Additionally,
suspend/resume, reset and poweroff are all converted to use PSCI calls.
Doing this removes direct access to the SCU and factors out the A9 vs.
A15 differences.

Signed-off-by: Rob Herring <rob.herring at calxeda.com>
---
v2: Rebase to use Stefano's psci_smp_ops patch:

http://lists.infradead.org/pipermail/linux-arm-kernel/2013-March/159187.html

 arch/arm/mach-highbank/Kconfig    |    2 +-
 arch/arm/mach-highbank/Makefile   |    4 +-
 arch/arm/mach-highbank/core.h     |    7 ----
 arch/arm/mach-highbank/highbank.c |   50 ++++---------------------
 arch/arm/mach-highbank/hotplug.c  |   40 --------------------
 arch/arm/mach-highbank/platsmp.c  |   75 -------------------------------------
 arch/arm/mach-highbank/pm.c       |   25 +++++--------
 arch/arm/mach-highbank/sysregs.h  |   67 ++++++---------------------------
 arch/arm/mach-highbank/system.c   |   32 ----------------
 9 files changed, 30 insertions(+), 272 deletions(-)
 delete mode 100644 arch/arm/mach-highbank/hotplug.c
 delete mode 100644 arch/arm/mach-highbank/platsmp.c
 delete mode 100644 arch/arm/mach-highbank/system.c

diff --git a/arch/arm/mach-highbank/Kconfig b/arch/arm/mach-highbank/Kconfig
index 44b12f9..9dc0c9e 100644
--- a/arch/arm/mach-highbank/Kconfig
+++ b/arch/arm/mach-highbank/Kconfig
@@ -5,13 +5,13 @@ config ARCH_HIGHBANK
 	select ARCH_WANT_OPTIONAL_GPIOLIB
 	select ARM_AMBA
 	select ARM_GIC
+	select ARM_PSCI
 	select ARM_TIMER_SP804
 	select CACHE_L2X0
 	select CLKDEV_LOOKUP
 	select COMMON_CLK
 	select CPU_V7
 	select GENERIC_CLOCKEVENTS
-	select HAVE_ARM_SCU
 	select HAVE_SMP
 	select MAILBOX
 	select PL320_MBOX
diff --git a/arch/arm/mach-highbank/Makefile b/arch/arm/mach-highbank/Makefile
index 8a1ef57..aeabc32 100644
--- a/arch/arm/mach-highbank/Makefile
+++ b/arch/arm/mach-highbank/Makefile
@@ -1,8 +1,6 @@
-obj-y					:= highbank.o system.o smc.o
+obj-y					:= highbank.o smc.o
 
 plus_sec := $(call as-instr,.arch_extension sec,+sec)
 AFLAGS_smc.o				:=-Wa,-march=armv7-a$(plus_sec)
 
-obj-$(CONFIG_SMP)			+= platsmp.o
-obj-$(CONFIG_HOTPLUG_CPU)		+= hotplug.o
 obj-$(CONFIG_PM_SLEEP)			+= pm.o
diff --git a/arch/arm/mach-highbank/core.h b/arch/arm/mach-highbank/core.h
index 3f65206..52b713a 100644
--- a/arch/arm/mach-highbank/core.h
+++ b/arch/arm/mach-highbank/core.h
@@ -1,10 +1,6 @@
 #ifndef __HIGHBANK_CORE_H
 #define __HIGHBANK_CORE_H
 
-extern void highbank_set_cpu_jump(int cpu, void *jump_addr);
-extern void highbank_restart(char, const char *);
-extern void __iomem *scu_base_addr;
-
 #ifdef CONFIG_PM_SLEEP
 extern void highbank_pm_init(void);
 #else
@@ -12,8 +8,5 @@ static inline void highbank_pm_init(void) {}
 #endif
 
 extern void highbank_smc1(int fn, int arg);
-extern void highbank_cpu_die(unsigned int cpu);
-
-extern struct smp_operations highbank_smp_ops;
 
 #endif
diff --git a/arch/arm/mach-highbank/highbank.c b/arch/arm/mach-highbank/highbank.c
index 3a5e62c..87efec6 100644
--- a/arch/arm/mach-highbank/highbank.c
+++ b/arch/arm/mach-highbank/highbank.c
@@ -26,9 +26,6 @@
 #include <linux/clk-provider.h>
 
 #include <asm/arch_timer.h>
-#include <asm/cacheflush.h>
-#include <asm/cputype.h>
-#include <asm/smp_plat.h>
 #include <asm/smp_twd.h>
 #include <asm/hardware/arm_timer.h>
 #include <asm/hardware/timer-sp.h>
@@ -40,50 +37,15 @@
 #include "sysregs.h"
 
 void __iomem *sregs_base;
-void __iomem *scu_base_addr;
-
-static void __init highbank_scu_map_io(void)
-{
-	unsigned long base;
-
-	/* Get SCU base */
-	asm("mrc p15, 4, %0, c15, c0, 0" : "=r" (base));
-
-	scu_base_addr = ioremap(base, SZ_4K);
-}
-
-#define HB_JUMP_TABLE_PHYS(cpu)		(0x40 + (0x10 * (cpu)))
-#define HB_JUMP_TABLE_VIRT(cpu)		phys_to_virt(HB_JUMP_TABLE_PHYS(cpu))
-
-void highbank_set_cpu_jump(int cpu, void *jump_addr)
-{
-	cpu = MPIDR_AFFINITY_LEVEL(cpu_logical_map(cpu), 0);
-	writel(virt_to_phys(jump_addr), HB_JUMP_TABLE_VIRT(cpu));
-	__cpuc_flush_dcache_area(HB_JUMP_TABLE_VIRT(cpu), 16);
-	outer_clean_range(HB_JUMP_TABLE_PHYS(cpu),
-			  HB_JUMP_TABLE_PHYS(cpu) + 15);
-}
-
-#ifdef CONFIG_CACHE_L2X0
-static void highbank_l2x0_disable(void)
-{
-	/* Disable PL310 L2 Cache controller */
-	highbank_smc1(0x102, 0x0);
-}
-#endif
 
 static void __init highbank_init_irq(void)
 {
 	irqchip_init();
 
-	if (of_find_compatible_node(NULL, NULL, "arm,cortex-a9"))
-		highbank_scu_map_io();
-
 #ifdef CONFIG_CACHE_L2X0
 	/* Enable PL310 L2 Cache controller */
 	highbank_smc1(0x102, 0x1);
 	l2x0_of_init(0, ~0UL);
-	outer_cache.disable = highbank_l2x0_disable;
 #endif
 }
 
@@ -123,10 +85,15 @@ static void __init highbank_timer_init(void)
 
 static void highbank_power_off(void)
 {
-	highbank_set_pwr_shutdown();
+	highbank_cpu_off(HB_PWR_SHUTDOWN, 1);
+}
 
-	while (1)
-		cpu_do_idle();
+static void highbank_restart(char mode, const char *cmd)
+{
+	if (mode == 'h')
+		highbank_cpu_off(HB_PWR_HARD_RESET, 1);
+	else
+		highbank_cpu_off(HB_PWR_SOFT_RESET, 1);
 }
 
 static int highbank_platform_notifier(struct notifier_block *nb,
@@ -194,7 +161,6 @@ static const char *highbank_match[] __initconst = {
 };
 
 DT_MACHINE_START(HIGHBANK, "Highbank")
-	.smp		= smp_ops(highbank_smp_ops),
 	.map_io		= debug_ll_io_init,
 	.init_irq	= highbank_init_irq,
 	.init_time	= highbank_timer_init,
diff --git a/arch/arm/mach-highbank/hotplug.c b/arch/arm/mach-highbank/hotplug.c
deleted file mode 100644
index f30c528..0000000
--- a/arch/arm/mach-highbank/hotplug.c
+++ /dev/null
@@ -1,40 +0,0 @@
-/*
- * Copyright 2011 Calxeda, Inc.
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms and conditions of the GNU General Public License,
- * version 2, as published by the Free Software Foundation.
- *
- * This program is distributed in the hope it will be useful, but WITHOUT
- * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
- * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
- * more details.
- *
- * You should have received a copy of the GNU General Public License along with
- * this program.  If not, see <http://www.gnu.org/licenses/>.
- */
-#include <linux/kernel.h>
-
-#include <asm/cacheflush.h>
-
-#include "core.h"
-#include "sysregs.h"
-
-extern void secondary_startup(void);
-
-/*
- * platform-specific code to shutdown a CPU
- *
- */
-void __ref highbank_cpu_die(unsigned int cpu)
-{
-	flush_cache_all();
-
-	highbank_set_cpu_jump(cpu, phys_to_virt(0));
-	highbank_set_core_pwr();
-
-	cpu_do_idle();
-
-	/* We should never return from idle */
-	panic("highbank: cpu %d unexpectedly exit from shutdown\n", cpu);
-}
diff --git a/arch/arm/mach-highbank/platsmp.c b/arch/arm/mach-highbank/platsmp.c
deleted file mode 100644
index 8797a70..0000000
--- a/arch/arm/mach-highbank/platsmp.c
+++ /dev/null
@@ -1,75 +0,0 @@
-/*
- * Copyright 2010-2011 Calxeda, Inc.
- * Based on platsmp.c, Copyright (C) 2002 ARM Ltd.
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms and conditions of the GNU General Public License,
- * version 2, as published by the Free Software Foundation.
- *
- * This program is distributed in the hope it will be useful, but WITHOUT
- * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
- * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
- * more details.
- *
- * You should have received a copy of the GNU General Public License along with
- * this program.  If not, see <http://www.gnu.org/licenses/>.
- */
-#include <linux/init.h>
-#include <linux/smp.h>
-#include <linux/io.h>
-#include <linux/irqchip/arm-gic.h>
-
-#include <asm/smp_scu.h>
-
-#include "core.h"
-
-extern void secondary_startup(void);
-
-static void __cpuinit highbank_secondary_init(unsigned int cpu)
-{
-	gic_secondary_init(0);
-}
-
-static int __cpuinit highbank_boot_secondary(unsigned int cpu, struct task_struct *idle)
-{
-	highbank_set_cpu_jump(cpu, secondary_startup);
-	arch_send_wakeup_ipi_mask(cpumask_of(cpu));
-	return 0;
-}
-
-/*
- * Initialise the CPU possible map early - this describes the CPUs
- * which may be present or become present in the system.
- */
-static void __init highbank_smp_init_cpus(void)
-{
-	unsigned int i, ncores = 4;
-
-	/* sanity check */
-	if (ncores > NR_CPUS) {
-		printk(KERN_WARNING
-		       "highbank: no. of cores (%d) greater than configured "
-		       "maximum of %d - clipping\n",
-		       ncores, NR_CPUS);
-		ncores = NR_CPUS;
-	}
-
-	for (i = 0; i < ncores; i++)
-		set_cpu_possible(i, true);
-}
-
-static void __init highbank_smp_prepare_cpus(unsigned int max_cpus)
-{
-	if (scu_base_addr)
-		scu_enable(scu_base_addr);
-}
-
-struct smp_operations highbank_smp_ops __initdata = {
-	.smp_init_cpus		= highbank_smp_init_cpus,
-	.smp_prepare_cpus	= highbank_smp_prepare_cpus,
-	.smp_secondary_init	= highbank_secondary_init,
-	.smp_boot_secondary	= highbank_boot_secondary,
-#ifdef CONFIG_HOTPLUG_CPU
-	.cpu_die		= highbank_cpu_die,
-#endif
-};
diff --git a/arch/arm/mach-highbank/pm.c b/arch/arm/mach-highbank/pm.c
index 04eddb4..d1f511b 100644
--- a/arch/arm/mach-highbank/pm.c
+++ b/arch/arm/mach-highbank/pm.c
@@ -16,27 +16,21 @@
 
 #include <linux/cpu_pm.h>
 #include <linux/init.h>
-#include <linux/io.h>
 #include <linux/suspend.h>
 
-#include <asm/cacheflush.h>
-#include <asm/proc-fns.h>
 #include <asm/suspend.h>
 
-#include "core.h"
 #include "sysregs.h"
 
 static int highbank_suspend_finish(unsigned long val)
 {
-	outer_flush_all();
-	outer_disable();
+	const struct psci_power_state ps = {
+		.id = HB_PWR_SUSPEND,
+		.type = PSCI_POWER_STATE_TYPE_POWER_DOWN,
+		.affinity_level = 1,
+	};
 
-	highbank_set_pwr_suspend();
-
-	cpu_do_idle();
-
-	highbank_clear_pwr_request();
-	return 0;
+	return psci_ops.cpu_suspend(ps, __pa(cpu_resume));
 }
 
 static int highbank_pm_enter(suspend_state_t state)
@@ -44,15 +38,11 @@ static int highbank_pm_enter(suspend_state_t state)
 	cpu_pm_enter();
 	cpu_cluster_pm_enter();
 
-	highbank_set_cpu_jump(0, cpu_resume);
 	cpu_suspend(0, highbank_suspend_finish);
 
 	cpu_cluster_pm_exit();
 	cpu_pm_exit();
 
-	highbank_smc1(0x102, 0x1);
-	if (scu_base_addr)
-		scu_enable(scu_base_addr);
 	return 0;
 }
 
@@ -63,5 +53,8 @@ static const struct platform_suspend_ops highbank_pm_ops = {
 
 void __init highbank_pm_init(void)
 {
+	if (!psci_ops.cpu_suspend)
+		return;
+
 	suspend_set_ops(&highbank_pm_ops);
 }
diff --git a/arch/arm/mach-highbank/sysregs.h b/arch/arm/mach-highbank/sysregs.h
index 5995df7..38818f3 100644
--- a/arch/arm/mach-highbank/sysregs.h
+++ b/arch/arm/mach-highbank/sysregs.h
@@ -16,71 +16,26 @@
 #ifndef _MACH_HIGHBANK__SYSREGS_H_
 #define _MACH_HIGHBANK__SYSREGS_H_
 
-#include <linux/io.h>
-#include <linux/smp.h>
-#include <asm/smp_plat.h>
-#include <asm/smp_scu.h>
-#include "core.h"
-
-extern void __iomem *sregs_base;
-
-#define HB_SREG_A9_PWR_REQ		0xf00
-#define HB_SREG_A9_BOOT_STAT		0xf04
-#define HB_SREG_A9_BOOT_DATA		0xf08
+#include <linux/err.h>
+#include <asm/psci.h>
 
 #define HB_PWR_SUSPEND			0
 #define HB_PWR_SOFT_RESET		1
 #define HB_PWR_HARD_RESET		2
 #define HB_PWR_SHUTDOWN			3
 
-#define SREG_CPU_PWR_CTRL(c)		(0x200 + ((c) * 4))
-
-static inline void highbank_set_core_pwr(void)
-{
-	int cpu = MPIDR_AFFINITY_LEVEL(cpu_logical_map(smp_processor_id()), 0);
-	if (scu_base_addr)
-		scu_power_mode(scu_base_addr, SCU_PM_POWEROFF);
-	else
-		writel_relaxed(1, sregs_base + SREG_CPU_PWR_CTRL(cpu));
-}
-
-static inline void highbank_clear_core_pwr(void)
+static inline int highbank_cpu_off(int id, int affinity_level)
 {
-	int cpu = MPIDR_AFFINITY_LEVEL(cpu_logical_map(smp_processor_id()), 0);
-	if (scu_base_addr)
-		scu_power_mode(scu_base_addr, SCU_PM_NORMAL);
-	else
-		writel_relaxed(0, sregs_base + SREG_CPU_PWR_CTRL(cpu));
-}
+	struct psci_power_state ps = {
+		.id = id,
+		.type = PSCI_POWER_STATE_TYPE_POWER_DOWN,
+		.affinity_level = affinity_level,
+	};
 
-static inline void highbank_set_pwr_suspend(void)
-{
-	writel(HB_PWR_SUSPEND, sregs_base + HB_SREG_A9_PWR_REQ);
-	highbank_set_core_pwr();
-}
+	if (psci_ops.cpu_off)
+		return psci_ops.cpu_off(ps);
 
-static inline void highbank_set_pwr_shutdown(void)
-{
-	writel(HB_PWR_SHUTDOWN, sregs_base + HB_SREG_A9_PWR_REQ);
-	highbank_set_core_pwr();
-}
-
-static inline void highbank_set_pwr_soft_reset(void)
-{
-	writel(HB_PWR_SOFT_RESET, sregs_base + HB_SREG_A9_PWR_REQ);
-	highbank_set_core_pwr();
-}
-
-static inline void highbank_set_pwr_hard_reset(void)
-{
-	writel(HB_PWR_HARD_RESET, sregs_base + HB_SREG_A9_PWR_REQ);
-	highbank_set_core_pwr();
-}
-
-static inline void highbank_clear_pwr_request(void)
-{
-	writel(~0UL, sregs_base + HB_SREG_A9_PWR_REQ);
-	highbank_clear_core_pwr();
+	return -ENODEV;
 }
 
 #endif
diff --git a/arch/arm/mach-highbank/system.c b/arch/arm/mach-highbank/system.c
deleted file mode 100644
index 37d8384..0000000
--- a/arch/arm/mach-highbank/system.c
+++ /dev/null
@@ -1,32 +0,0 @@
-/*
- * Copyright 2011 Calxeda, Inc.
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms and conditions of the GNU General Public License,
- * version 2, as published by the Free Software Foundation.
- *
- * This program is distributed in the hope it will be useful, but WITHOUT
- * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
- * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
- * more details.
- *
- * You should have received a copy of the GNU General Public License along with
- * this program.  If not, see <http://www.gnu.org/licenses/>.
- */
-#include <linux/io.h>
-#include <asm/proc-fns.h>
-
-#include "core.h"
-#include "sysregs.h"
-
-void highbank_restart(char mode, const char *cmd)
-{
-	if (mode == 'h')
-		highbank_set_pwr_hard_reset();
-	else
-		highbank_set_pwr_soft_reset();
-
-	while (1)
-		cpu_do_idle();
-}
-
-- 
1.7.10.4



From marex at denx.de  Mon Apr  1 19:11:13 2013
From: marex at denx.de (Marek Vasut)
Date: Tue, 2 Apr 2013 01:11:13 +0200
Subject: [PATCH 1/5] spi/mxs: Fix extra CS pulses and read mode in
 multi-transfer messages
In-Reply-To: <1364570381-17605-1-git-send-email-tpiepho@gmail.com>
References: <1364570381-17605-1-git-send-email-tpiepho@gmail.com>
Message-ID: <201304020111.13969.marex@denx.de>

Dear Trent Piepho,

> There are two bits which control the CS line in the CTRL0 register:
> LOCK_CS and IGNORE_CRC.  The latter would be better named DEASSERT_CS
> in SPI mode.
> 
> LOCK_CS keeps CS asserted though the entire transfer.  This should
> always be set.  The DMA code will always set it, explicitly on the
> first segment of the first transfer, and then implicitly on all the
> rest by never clearing the bit from the value read from the ctrl0
> register.
> 
> The only reason to not set LOCK_CS would be to attempt an altered
> protocol where CS pulses between each word.  Though don't get your
> hopes up, as the hardware doesn't appear to do this in any sane
> manner.
> 
> Setting DEASSERT_CS causes CS to be de-asserted at the end of the
> transfer.  It would normally be set on the final segment of the final
> transfer.  The DMA code explicitly sets it in this case, but because
> it never clears the bit from the ctrl0 register is will remain set for
> all transfers in subsequent messages.  This results in a CS pulse
> between transfers.
> 
> There is a similar problem with the read mode bit never being cleared
> in DMA mode.
> 
> The spi transfer "cs_change" flag is ignored by the driver.
> 
> The driver passes a "first" and "last" flag to the transfer functions
> for a message, so they can know how to set these bits.  It does this
> by passing them as pointers.  There is no reason to do this, as the
> flags are not modified in the transfer function.  And since LOCK_CS
> can be set and left that way, there is no need for a "first" flag at
> all.
> 
> This patch fixes DEASSERT_CS and READ being left on in DMA mode,
> eliminates the flags being passed as separate pointers, and adds
> support for the cs_change flag.
> 
> Note that while using the cs_change flag to leave CS asserted after
> the final transfer works, getting the CS to automatically turn off
> when a different slave is addressed might not work.
> 
> Signed-off-by: Trent Piepho <tpiepho at gmail.com>
> Cc: Marek Vasut <marex at denx.de>
> Cc: Fabio Estevam <fabio.estevam at freescale.com>
> Cc: Shawn Guo <shawn.guo at linaro.org>
> ---
>  drivers/spi/spi-mxs.c |   86
> +++++++++++++++++++++---------------------------- 1 file changed, 36
> insertions(+), 50 deletions(-)
> 
> diff --git a/drivers/spi/spi-mxs.c b/drivers/spi/spi-mxs.c
> index 22a0af0..aa77d96b9 100644
> --- a/drivers/spi/spi-mxs.c
> +++ b/drivers/spi/spi-mxs.c
> @@ -58,6 +58,11 @@
> 
>  #define SG_MAXLEN		0xff00
> 
> +/* Flags for txrx functions.  More efficient that using an argument
> register for + * each one. */

Fix the comment please.

/*
 * Multiline comment should really
 * be like this.
 */

> +#define TXRX_WRITE		1	/* This is a write */
> +#define TXRX_DEASSERT_CS	2	/* De-assert CS at end of txrx */

New flags? I'm sure the GCC can optimize function parameters pretty well, esp. 
if you make the bool.

>  struct mxs_spi {
>  	struct mxs_ssp		ssp;
>  	struct completion	c;
> @@ -91,6 +96,8 @@ static int mxs_spi_setup_transfer(struct spi_device *dev,
> 
>  	mxs_ssp_set_clk_rate(ssp, hz);
> 
> +	writel(BM_SSP_CTRL0_LOCK_CS,
> +		ssp->base + HW_SSP_CTRL0 + STMP_OFFSET_REG_SET);
>  	writel(BF_SSP_CTRL1_SSP_MODE(BV_SSP_CTRL1_SSP_MODE__SPI) |
>  		     BF_SSP_CTRL1_WORD_LENGTH
>  		     (BV_SSP_CTRL1_WORD_LENGTH__EIGHT_BITS) |
> @@ -155,26 +162,6 @@ static void mxs_spi_set_cs(struct mxs_spi *spi,
> unsigned cs) writel(select, ssp->base + HW_SSP_CTRL0 +
> STMP_OFFSET_REG_SET);
>  }
> 
> -static inline void mxs_spi_enable(struct mxs_spi *spi)
> -{
> -	struct mxs_ssp *ssp = &spi->ssp;
> -
> -	writel(BM_SSP_CTRL0_LOCK_CS,
> -		ssp->base + HW_SSP_CTRL0 + STMP_OFFSET_REG_SET);
> -	writel(BM_SSP_CTRL0_IGNORE_CRC,
> -		ssp->base + HW_SSP_CTRL0 + STMP_OFFSET_REG_CLR);
> -}
> -
> -static inline void mxs_spi_disable(struct mxs_spi *spi)
> -{
> -	struct mxs_ssp *ssp = &spi->ssp;
> -
> -	writel(BM_SSP_CTRL0_LOCK_CS,
> -		ssp->base + HW_SSP_CTRL0 + STMP_OFFSET_REG_CLR);
> -	writel(BM_SSP_CTRL0_IGNORE_CRC,
> -		ssp->base + HW_SSP_CTRL0 + STMP_OFFSET_REG_SET);
> -}
> -
>  static int mxs_ssp_wait(struct mxs_spi *spi, int offset, int mask, bool
> set) {
>  	const unsigned long timeout = jiffies + msecs_to_jiffies(SSP_TIMEOUT);
> @@ -214,7 +201,7 @@ static irqreturn_t mxs_ssp_irq_handler(int irq, void
> *dev_id)
> 
>  static int mxs_spi_txrx_dma(struct mxs_spi *spi, int cs,
>  			    unsigned char *buf, int len,
> -			    int *first, int *last, int write)
> +			    unsigned int flags)
>  {
>  	struct mxs_ssp *ssp = &spi->ssp;
>  	struct dma_async_tx_descriptor *desc = NULL;
> @@ -241,20 +228,21 @@ static int mxs_spi_txrx_dma(struct mxs_spi *spi, int
> cs, INIT_COMPLETION(spi->c);
> 
>  	ctrl0 = readl(ssp->base + HW_SSP_CTRL0);
> -	ctrl0 &= ~BM_SSP_CTRL0_XFER_COUNT;
> +	ctrl0 &= ~BM_SSP_CTRL0_XFER_COUNT & ~BM_SSP_CTRL0_IGNORE_CRC &
> +		 ~BM_SSP_CTRL0_READ;

Well ... ctrl0 &= ~(FOO | BAR | BAZ); ... won't cut it?

>  	ctrl0 |= BM_SSP_CTRL0_DATA_XFER | mxs_spi_cs_to_reg(cs);
> 
> -	if (*first)
> -		ctrl0 |= BM_SSP_CTRL0_LOCK_CS;

The DMA will overwrite ctrl0 in each turn, did you try very long (>64kB long) 
transfers with your adjustments? To test this, you can try

$ dd if=/dev/mtdN of=/dev/null bs=1M

on sufficiently large SPI flash supporting the FAST_READ opcode.

> -	if (!write)
> +	if (!(flags & TXRX_WRITE))
>  		ctrl0 |= BM_SSP_CTRL0_READ;
> 
>  	/* Queue the DMA data transfer. */
>  	for (sg_count = 0; sg_count < sgs; sg_count++) {
> +		/* Prepare the transfer descriptor. */
>  		min = min(len, desc_len);
> 
> -		/* Prepare the transfer descriptor. */
> -		if ((sg_count + 1 == sgs) && *last)
> +		/* De-assert CS on last segment if flag is set (i.e., no more
> +		 * transfers will follow) */

Wrong multi-line comment. See Documentation/CodingStyle chapter 8.

> +		if ((sg_count + 1 == sgs) && (flags & TXRX_DEASSERT_CS))
>  			ctrl0 |= BM_SSP_CTRL0_IGNORE_CRC;
> 
>  		if (ssp->devid == IMX23_SSP) {
> @@ -279,7 +267,7 @@ static int mxs_spi_txrx_dma(struct mxs_spi *spi, int
> cs,
> 
>  		sg_init_one(&dma_xfer[sg_count].sg, sg_buf, min);
>  		ret = dma_map_sg(ssp->dev, &dma_xfer[sg_count].sg, 1,
> -			write ? DMA_TO_DEVICE : DMA_FROM_DEVICE);
> +			(flags & TXRX_WRITE) ? DMA_TO_DEVICE : DMA_FROM_DEVICE);

I think this is unneeded.

>  		len -= min;
>  		buf += min;
> @@ -299,7 +287,7 @@ static int mxs_spi_txrx_dma(struct mxs_spi *spi, int
> cs,
> 
>  		desc = dmaengine_prep_slave_sg(ssp->dmach,
>  				&dma_xfer[sg_count].sg, 1,
> -				write ? DMA_MEM_TO_DEV : DMA_DEV_TO_MEM,
> +				(flags & TXRX_WRITE) ? DMA_MEM_TO_DEV : 
DMA_DEV_TO_MEM,
>  				DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
> 
>  		if (!desc) {
> @@ -336,7 +324,7 @@ err_vmalloc:
>  	while (--sg_count >= 0) {
>  err_mapped:
>  		dma_unmap_sg(ssp->dev, &dma_xfer[sg_count].sg, 1,
> -			write ? DMA_TO_DEVICE : DMA_FROM_DEVICE);
> +			(flags & TXRX_WRITE) ? DMA_TO_DEVICE : DMA_FROM_DEVICE);
>  	}
> 
>  	kfree(dma_xfer);
> @@ -346,18 +334,20 @@ err_mapped:
> 
>  static int mxs_spi_txrx_pio(struct mxs_spi *spi, int cs,
>  			    unsigned char *buf, int len,
> -			    int *first, int *last, int write)
> +			    unsigned int flags)
>  {
>  	struct mxs_ssp *ssp = &spi->ssp;
> 
> -	if (*first)
> -		mxs_spi_enable(spi);
> +	/* Clear this now, set it on last transfer if needed */
> +	writel(BM_SSP_CTRL0_IGNORE_CRC,
> +	       ssp->base + HW_SSP_CTRL0 + STMP_OFFSET_REG_CLR);
> 
>  	mxs_spi_set_cs(spi, cs);
> 
>  	while (len--) {
> -		if (*last && len == 0)
> -			mxs_spi_disable(spi);
> +		if (len == 0 && (flags & TXRX_DEASSERT_CS))
> +			writel(BM_SSP_CTRL0_IGNORE_CRC,
> +			       ssp->base + HW_SSP_CTRL0 + STMP_OFFSET_REG_SET);

Ok, I'll stop here. You mixed two kinds of changes here:
1) The "fixup" of the flags
2) The adjustments to handling the IGNORE_CRC and LOCK_CS

Split the patch please.


From marex at denx.de  Mon Apr  1 19:13:41 2013
From: marex at denx.de (Marek Vasut)
Date: Tue, 2 Apr 2013 01:13:41 +0200
Subject: [PATCH 2/5] spi/mxs: Fix chip select control bits in DMA mode
In-Reply-To: <1364570381-17605-2-git-send-email-tpiepho@gmail.com>
References: <1364570381-17605-1-git-send-email-tpiepho@gmail.com>
 <1364570381-17605-2-git-send-email-tpiepho@gmail.com>
Message-ID: <201304020113.42124.marex@denx.de>

Dear Trent Piepho,

> In DMA mode the chip select control bits would be ORed into the CTRL0
> register without first clearing the bits.  This means that after
> addressing slave 1 the bit would be still be set when addressing slave
> 0, resulting in slave 1 continuing to be addressed.
> 
> The message handing function would pass the cs value to the txrx
> function, which would re-program the bits on each transfer in the
> message.  The selected cs does not change during a message so this is
> inefficient.  It also means there are two different sets of code for
> selecting the CS, one for PIO that worked and one for DMA that didn't.
> 
> Change the code to set the CS bits in the message transfer function
> once.  Now the DMA and PIO txrx functions don't need to care about CS
> at all.

Ok, lemme ask this one more time -- will the DMA work with long transfers where 
the CTRL0 will be overwritten on each turn? Did you actually test this?

> Signed-off-by: Trent Piepho <tpiepho at gmail.com>
> Cc: Marek Vasut <marex at denx.de>
> Cc: Fabio Estevam <fabio.estevam at freescale.com>
> Cc: Shawn Guo <shawn.guo at linaro.org>
> ---
>  drivers/spi/spi-mxs.c |   40 +++++++++++++++-------------------------
>  1 file changed, 15 insertions(+), 25 deletions(-)
> 
> diff --git a/drivers/spi/spi-mxs.c b/drivers/spi/spi-mxs.c
> index aa77d96b9..5d63b21 100644
> --- a/drivers/spi/spi-mxs.c
> +++ b/drivers/spi/spi-mxs.c
> @@ -130,9 +130,9 @@ static int mxs_spi_setup(struct spi_device *dev)
>  	return err;
>  }
> 
> -static uint32_t mxs_spi_cs_to_reg(unsigned cs)
> +static u32 mxs_spi_cs_to_reg(unsigned cs)
>  {
> -	uint32_t select = 0;
> +	u32 select = 0;

This change is unneeded, remove it.

>  	/*
>  	 * i.MX28 Datasheet: 17.10.1: HW_SSP_CTRL0
> @@ -150,18 +150,6 @@ static uint32_t mxs_spi_cs_to_reg(unsigned cs)
>  	return select;
>  }
> 
> -static void mxs_spi_set_cs(struct mxs_spi *spi, unsigned cs)
> -{
> -	const uint32_t mask =
> -		BM_SSP_CTRL0_WAIT_FOR_CMD | BM_SSP_CTRL0_WAIT_FOR_IRQ;
> -	uint32_t select;
> -	struct mxs_ssp *ssp = &spi->ssp;
> -
> -	writel(mask, ssp->base + HW_SSP_CTRL0 + STMP_OFFSET_REG_CLR);
> -	select = mxs_spi_cs_to_reg(cs);
> -	writel(select, ssp->base + HW_SSP_CTRL0 + STMP_OFFSET_REG_SET);
> -}
> -
>  static int mxs_ssp_wait(struct mxs_spi *spi, int offset, int mask, bool
> set) {
>  	const unsigned long timeout = jiffies + msecs_to_jiffies(SSP_TIMEOUT);
> @@ -199,7 +187,7 @@ static irqreturn_t mxs_ssp_irq_handler(int irq, void
> *dev_id) return IRQ_HANDLED;
>  }
> 
> -static int mxs_spi_txrx_dma(struct mxs_spi *spi, int cs,
> +static int mxs_spi_txrx_dma(struct mxs_spi *spi,
>  			    unsigned char *buf, int len,
>  			    unsigned int flags)
>  {
> @@ -227,10 +215,11 @@ static int mxs_spi_txrx_dma(struct mxs_spi *spi, int
> cs,
> 
>  	INIT_COMPLETION(spi->c);
> 
> +	/* Chip select was already programmed into CTRL0 */
>  	ctrl0 = readl(ssp->base + HW_SSP_CTRL0);
>  	ctrl0 &= ~BM_SSP_CTRL0_XFER_COUNT & ~BM_SSP_CTRL0_IGNORE_CRC &
>  		 ~BM_SSP_CTRL0_READ;
> -	ctrl0 |= BM_SSP_CTRL0_DATA_XFER | mxs_spi_cs_to_reg(cs);
> +	ctrl0 |= BM_SSP_CTRL0_DATA_XFER;
> 
>  	if (!(flags & TXRX_WRITE))
>  		ctrl0 |= BM_SSP_CTRL0_READ;
> @@ -332,7 +321,7 @@ err_mapped:
>  	return ret;
>  }
> 
> -static int mxs_spi_txrx_pio(struct mxs_spi *spi, int cs,
> +static int mxs_spi_txrx_pio(struct mxs_spi *spi,
>  			    unsigned char *buf, int len,
>  			    unsigned int flags)
>  {
> @@ -342,8 +331,6 @@ static int mxs_spi_txrx_pio(struct mxs_spi *spi, int
> cs, writel(BM_SSP_CTRL0_IGNORE_CRC,
>  	       ssp->base + HW_SSP_CTRL0 + STMP_OFFSET_REG_CLR);
> 
> -	mxs_spi_set_cs(spi, cs);
> -
>  	while (len--) {
>  		if (len == 0 && (flags & TXRX_DEASSERT_CS))
>  			writel(BM_SSP_CTRL0_IGNORE_CRC,
> @@ -405,9 +392,12 @@ static int mxs_spi_transfer_one(struct spi_master
> *master, struct spi_transfer *t, *tmp_t;
>  	unsigned int flag;
>  	int status = 0;
> -	int cs;
> 
> -	cs = m->spi->chip_select;
> +	/* Program CS register bits here, it will be used for all transfers. */
> +	writel(BM_SSP_CTRL0_WAIT_FOR_CMD | BM_SSP_CTRL0_WAIT_FOR_IRQ,
> +	       ssp->base + HW_SSP_CTRL0 + STMP_OFFSET_REG_CLR);
> +	writel(mxs_spi_cs_to_reg(m->spi->chip_select),
> +	       ssp->base + HW_SSP_CTRL0 + STMP_OFFSET_REG_SET);
> 
>  	list_for_each_entry_safe(t, tmp_t, &m->transfers, transfer_list) {
> 
> @@ -440,11 +430,11 @@ static int mxs_spi_transfer_one(struct spi_master
> *master, STMP_OFFSET_REG_CLR);
> 
>  			if (t->tx_buf)
> -				status = mxs_spi_txrx_pio(spi, cs,
> +				status = mxs_spi_txrx_pio(spi,
>  						(void *)t->tx_buf,
>  						t->len, flag | TXRX_WRITE);
>  			if (t->rx_buf)
> -				status = mxs_spi_txrx_pio(spi, cs,
> +				status = mxs_spi_txrx_pio(spi,
>  						t->rx_buf, t->len,
>  						flag);
>  		} else {
> @@ -453,11 +443,11 @@ static int mxs_spi_transfer_one(struct spi_master
> *master, STMP_OFFSET_REG_SET);
> 
>  			if (t->tx_buf)
> -				status = mxs_spi_txrx_dma(spi, cs,
> +				status = mxs_spi_txrx_dma(spi,
>  						(void *)t->tx_buf, t->len,
>  						flag | TXRX_WRITE);
>  			if (t->rx_buf)
> -				status = mxs_spi_txrx_dma(spi, cs,
> +				status = mxs_spi_txrx_dma(spi,
>  						t->rx_buf, t->len,
>  						flag);
>  		}

Best regards,
Marek Vasut


From marex at denx.de  Mon Apr  1 19:16:04 2013
From: marex at denx.de (Marek Vasut)
Date: Tue, 2 Apr 2013 01:16:04 +0200
Subject: [PATCH 4/5] spi/mxs: Remove bogus setting of ssp clk rate field
In-Reply-To: <1364570381-17605-4-git-send-email-tpiepho@gmail.com>
References: <1364570381-17605-1-git-send-email-tpiepho@gmail.com>
 <1364570381-17605-4-git-send-email-tpiepho@gmail.com>
Message-ID: <201304020116.04781.marex@denx.de>

Dear Trent Piepho,

> The ssp struct has a clock rate field, to provide the actual value, in Hz,
> of the SSP output clock (the rate of SSP_SCK) after mxs_ssp_set_clk_rate()
> is called.  It should be read-only, except for mxs_ssp_set_clk_rate().
> 
> For some reason the spi-mxs driver decides to write to this field on init,
> and sets it to the value of the SSP input clock (clk_sspN, from the MXS
> clocking block) in kHz.  It shouldn't be setting the value, and certainly
> shouldn't be setting it with the wrong clock in the wrong units.

I suspect this patch should also fix drivers/clk/mxs/clk-ssp.c then?

> Signed-off-by: Trent Piepho <tpiepho at gmail.com>
> Cc: Marek Vasut <marex at denx.de>
> Cc: Fabio Estevam <fabio.estevam at freescale.com>
> Cc: Shawn Guo <shawn.guo at linaro.org>
> ---
>  drivers/spi/spi-mxs.c |    1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/spi/spi-mxs.c b/drivers/spi/spi-mxs.c
> index 7218006..fc52f78 100644
> --- a/drivers/spi/spi-mxs.c
> +++ b/drivers/spi/spi-mxs.c
> @@ -587,7 +587,6 @@ static int mxs_spi_probe(struct platform_device *pdev)
> 
>  	clk_prepare_enable(ssp->clk);
>  	clk_set_rate(ssp->clk, clk_freq);
> -	ssp->clk_rate = clk_get_rate(ssp->clk) / 1000;
> 
>  	stmp_reset_block(ssp->base);

Best regards,
Marek Vasut


From marex at denx.de  Mon Apr  1 19:18:27 2013
From: marex at denx.de (Marek Vasut)
Date: Tue, 2 Apr 2013 01:18:27 +0200
Subject: [PATCH 5/5] spi/mxs: Fix multiple slave bug and don't set clock
 for each xfer
In-Reply-To: <1364570381-17605-5-git-send-email-tpiepho@gmail.com>
References: <1364570381-17605-1-git-send-email-tpiepho@gmail.com>
 <1364570381-17605-5-git-send-email-tpiepho@gmail.com>
Message-ID: <201304020118.27575.marex@denx.de>

Dear Trent Piepho,

> Despite many warnings in the SPI documentation and code, the spi-mxs
> driver sets shared chip registers in the ->setup method.  This method can
> be called when transfers are in progress on other slaves controlled by the
> master.  Setting registers or any other shared state will corrupt those
> transfers.
> 
> So fix mxs_spi_setup() to not call mxs_spi_setup_transfer().
> 
> Now that mxs_spi_setup_transfer() won't be called with a NULL transfer,
> since it's only purpose is to setup a transfer, the code can be
> simplified.
> 
> mxs_spi_setup_transfer() would set the SSP SCK rate every time it was
> called, which is before each transfer.  It is uncommon for the SCK rate to
> change between transfers and this causes unnecessary reprogramming of the
> clock registers.  Changed to only set the rate when it has changed.
> 
> This significantly speeds up short SPI messages, especially messages made
> up of many transfers.  On an iMX287, using spidev with messages that
> consist of 511 transfers of 4 bytes each at an SCK of 48 MHz, the
> effective transfer rate more than doubles from about 290 KB/sec to 600
> KB/sec.

This patch is full of unrelated changes, the relevant parts are not clear. 
Please clean up and resubmit with only the relevant changes.

> Signed-off-by: Trent Piepho <tpiepho at gmail.com>
> Cc: Marek Vasut <marex at denx.de>
> Cc: Fabio Estevam <fabio.estevam at freescale.com>
> Cc: Shawn Guo <shawn.guo at linaro.org>
> ---
>  drivers/spi/spi-mxs.c |   54
> ++++++++++++++++++++++++------------------------- 1 file changed, 26
> insertions(+), 28 deletions(-)
> 
> diff --git a/drivers/spi/spi-mxs.c b/drivers/spi/spi-mxs.c
> index fc52f78..b60baab 100644
> --- a/drivers/spi/spi-mxs.c
> +++ b/drivers/spi/spi-mxs.c
> @@ -66,44 +66,47 @@
>  struct mxs_spi {
>  	struct mxs_ssp		ssp;
>  	struct completion	c;
> +	unsigned int		sck;	/* Rate requested (vs actual) */
>  };
> 
>  static int mxs_spi_setup_transfer(struct spi_device *dev,
> -				struct spi_transfer *t)
> +				  const struct spi_transfer *t)
>  {
>  	struct mxs_spi *spi = spi_master_get_devdata(dev->master);
>  	struct mxs_ssp *ssp = &spi->ssp;
> -	uint8_t bits_per_word;
> -	uint32_t hz = 0;
> -
> -	bits_per_word = dev->bits_per_word;
> -	if (t && t->bits_per_word)
> -		bits_per_word = t->bits_per_word;
> +	const unsigned int bits_per_word = t->bits_per_word ? :
> dev->bits_per_word; +	const unsigned int hz = t->speed_hz ?
> min(dev->max_speed_hz, t->speed_hz) : +					      
dev->max_speed_hz;
> 
>  	if (bits_per_word != 8) {
> -		dev_err(&dev->dev, "%s, unsupported bits_per_word=%d\n",
> -					__func__, bits_per_word);
> +		dev_err(&dev->dev, "Unsupported bits per word of %d\n",
> +			bits_per_word);
>  		return -EINVAL;
>  	}
> 
> -	hz = dev->max_speed_hz;
> -	if (t && t->speed_hz)
> -		hz = min(hz, t->speed_hz);
>  	if (hz == 0) {
> -		dev_err(&dev->dev, "Cannot continue with zero clock\n");
> +		dev_err(&dev->dev, "SPI clock rate of zero not possible\n");
>  		return -EINVAL;
>  	}
> 
> -	mxs_ssp_set_clk_rate(ssp, hz);
> +	if (hz != spi->sck) {
> +		mxs_ssp_set_clk_rate(ssp, hz);
> +		/* Save requested value, not actual value from ssp->clk_rate.
> +		 * Otherwise we would set the rate again each trasfer when
> +		 * actual is not quite the same as requested.  */
> +		spi->sck = hz;
> +		/* Perhaps we should return an error if the actual clock is
> +		 * nowhere close? */
> +	}
> 
>  	writel(BM_SSP_CTRL0_LOCK_CS,
>  		ssp->base + HW_SSP_CTRL0 + STMP_OFFSET_REG_SET);
> +
>  	writel(BF_SSP_CTRL1_SSP_MODE(BV_SSP_CTRL1_SSP_MODE__SPI) |
> -		     BF_SSP_CTRL1_WORD_LENGTH
> -		     (BV_SSP_CTRL1_WORD_LENGTH__EIGHT_BITS) |
> -		     ((dev->mode & SPI_CPOL) ? BM_SSP_CTRL1_POLARITY : 0) |
> -		     ((dev->mode & SPI_CPHA) ? BM_SSP_CTRL1_PHASE : 0),
> -		     ssp->base + HW_SSP_CTRL1(ssp));
> +	       BF_SSP_CTRL1_WORD_LENGTH(BV_SSP_CTRL1_WORD_LENGTH__EIGHT_BITS) |
> +	       ((dev->mode & SPI_CPOL) ? BM_SSP_CTRL1_POLARITY : 0) |
> +	       ((dev->mode & SPI_CPHA) ? BM_SSP_CTRL1_PHASE : 0),
> +	       ssp->base + HW_SSP_CTRL1(ssp));
> 
>  	writel(0x0, ssp->base + HW_SSP_CMD0);
>  	writel(0x0, ssp->base + HW_SSP_CMD1);
> @@ -113,21 +116,16 @@ static int mxs_spi_setup_transfer(struct spi_device
> *dev,
> 
>  static int mxs_spi_setup(struct spi_device *dev)
>  {
> -	int err = 0;
> -
>  	if (!dev->bits_per_word)
>  		dev->bits_per_word = 8;
> 
> -	if (dev->mode & ~(SPI_CPOL | SPI_CPHA))
> +	if (dev->bits_per_word != 8)
>  		return -EINVAL;
> 
> -	err = mxs_spi_setup_transfer(dev, NULL);
> -	if (err) {
> -		dev_err(&dev->dev,
> -			"Failed to setup transfer, error = %d\n", err);
> -	}
> +	if (dev->mode & ~(SPI_CPOL | SPI_CPHA))
> +		return -EINVAL;
> 
> -	return err;
> +	return 0;
>  }
> 
>  static u32 mxs_spi_cs_to_reg(unsigned cs)

Best regards,
Marek Vasut


From alex at digriz.org.uk  Mon Apr  1 19:22:42 2013
From: alex at digriz.org.uk (Alexander Clouter)
Date: Tue,  2 Apr 2013 00:22:42 +0100
Subject: [PATCH 3/6] rtc: rtc-m48t86: add detect method for RTC
In-Reply-To: <1364858565-17192-1-git-send-email-alex@digriz.org.uk>
References: <1364858565-17192-1-git-send-email-alex@digriz.org.uk>
Message-ID: <1364858565-17192-4-git-send-email-alex@digriz.org.uk>

The m48t86 has 114 bytes of user space available, so we can use this
space to detect for the presence of the RTC.

Signed-off-by: Alexander Clouter <alex at digriz.org.uk>
---
 drivers/rtc/rtc-m48t86.c |   43 +++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 43 insertions(+)

diff --git a/drivers/rtc/rtc-m48t86.c b/drivers/rtc/rtc-m48t86.c
index 6f99e64..b8edf73 100644
--- a/drivers/rtc/rtc-m48t86.c
+++ b/drivers/rtc/rtc-m48t86.c
@@ -173,6 +173,41 @@ static const struct rtc_class_ops m48t86_rtc_ops = {
 	.proc		= m48t86_rtc_proc,
 };
 
+/*
+ * The RTC chip has 114 bytes upper bytes that can be used as user storage
+ * space which we can use to test if the chip is present; for example it is
+ * an optional feature and not all boards will have it present.
+ *
+ * I've used the method Technologic Systems use in their rtc7800.c example
+ * for the detection.
+ *
+ * TODO: track down a guinea pig without an RTC to see if we can work out a
+ *	better RTC detection routine
+ */
+static int m48t86_rtc_detect(struct device *dev)
+{
+	unsigned char tmp_rtc0, tmp_rtc1;
+
+	tmp_rtc0 = m48t86_rtc_readbyte(dev, 126);
+	tmp_rtc1 = m48t86_rtc_readbyte(dev, 127);
+
+	m48t86_rtc_writebyte(dev, 0x00, 126);
+	m48t86_rtc_writebyte(dev, 0x55, 127);
+	if (m48t86_rtc_readbyte(dev, 127) == 0x55) {
+		m48t86_rtc_writebyte(dev, 0xaa, 127);
+		if (m48t86_rtc_readbyte(dev, 127) == 0xaa
+				&& m48t86_rtc_readbyte(dev, 126) == 0x00) {
+			m48t86_rtc_writebyte(dev, tmp_rtc0, 126);
+			m48t86_rtc_writebyte(dev, tmp_rtc1, 127);
+
+			return 0;
+		}
+	}
+
+	dev_info(dev, "RTC not found\n");
+	return -ENODEV;
+}
+
 static int m48t86_rtc_probe(struct platform_device *pdev)
 {
 	unsigned char reg;
@@ -232,6 +267,14 @@ static int m48t86_rtc_probe(struct platform_device *pdev)
 	} else
 		priv->ops = pdev->dev.platform_data;
 
+	err = m48t86_rtc_detect(&pdev->dev);
+	if (err) {
+		if (!pdev->dev.platform_data)
+			goto out_io_data;
+		else
+			goto out_free;
+	}
+
 	priv->rtc = rtc_device_register("m48t86",
 				&pdev->dev, &m48t86_rtc_ops, THIS_MODULE);
 	if (IS_ERR(priv->rtc)) {
-- 
1.7.10.4



From alex at digriz.org.uk  Mon Apr  1 19:22:40 2013
From: alex at digriz.org.uk (Alexander Clouter)
Date: Tue,  2 Apr 2013 00:22:40 +0100
Subject: [PATCH 1/6] rtc: rtc-m48t86: move m48t86.h to platform_data
In-Reply-To: <1364858565-17192-1-git-send-email-alex@digriz.org.uk>
References: <1364858565-17192-1-git-send-email-alex@digriz.org.uk>
Message-ID: <1364858565-17192-2-git-send-email-alex@digriz.org.uk>

The header for the rtc-m48t86 platform-data should be in
include/linux/platform_data.

Signed-off-by: Alexander Clouter <alex at digriz.org.uk>
---
 arch/arm/mach-ep93xx/ts72xx.c                          |    2 +-
 arch/arm/mach-orion5x/ts78xx-setup.c                   |    2 +-
 drivers/rtc/rtc-m48t86.c                               |    2 +-
 include/linux/{m48t86.h => platform_data/rtc-m48t86.h} |    0
 4 files changed, 3 insertions(+), 3 deletions(-)
 rename include/linux/{m48t86.h => platform_data/rtc-m48t86.h} (100%)

diff --git a/arch/arm/mach-ep93xx/ts72xx.c b/arch/arm/mach-ep93xx/ts72xx.c
index 61f4b5d..a278639 100644
--- a/arch/arm/mach-ep93xx/ts72xx.c
+++ b/arch/arm/mach-ep93xx/ts72xx.c
@@ -16,7 +16,7 @@
 #include <linux/init.h>
 #include <linux/platform_device.h>
 #include <linux/io.h>
-#include <linux/m48t86.h>
+#include <linux/platform_data/rtc-m48t86.h>
 #include <linux/mtd/nand.h>
 #include <linux/mtd/partitions.h>
 
diff --git a/arch/arm/mach-orion5x/ts78xx-setup.c b/arch/arm/mach-orion5x/ts78xx-setup.c
index e960855..ffe3603 100644
--- a/arch/arm/mach-orion5x/ts78xx-setup.c
+++ b/arch/arm/mach-orion5x/ts78xx-setup.c
@@ -16,7 +16,7 @@
 #include <linux/platform_device.h>
 #include <linux/mv643xx_eth.h>
 #include <linux/ata_platform.h>
-#include <linux/m48t86.h>
+#include <linux/platform_data/rtc-m48t86.h>
 #include <linux/mtd/nand.h>
 #include <linux/mtd/partitions.h>
 #include <linux/timeriomem-rng.h>
diff --git a/drivers/rtc/rtc-m48t86.c b/drivers/rtc/rtc-m48t86.c
index 2ffbcac..25e0116 100644
--- a/drivers/rtc/rtc-m48t86.c
+++ b/drivers/rtc/rtc-m48t86.c
@@ -16,7 +16,7 @@
 #include <linux/module.h>
 #include <linux/rtc.h>
 #include <linux/platform_device.h>
-#include <linux/m48t86.h>
+#include <linux/platform_data/rtc-m48t86.h>
 #include <linux/bcd.h>
 
 #define M48T86_REG_SEC		0x00
diff --git a/include/linux/m48t86.h b/include/linux/platform_data/rtc-m48t86.h
similarity index 100%
rename from include/linux/m48t86.h
rename to include/linux/platform_data/rtc-m48t86.h
-- 
1.7.10.4



From alex at digriz.org.uk  Mon Apr  1 19:22:39 2013
From: alex at digriz.org.uk (Alexander Clouter)
Date: Tue,  2 Apr 2013 00:22:39 +0100
Subject: [PATCHv2 0/6] add devicetree bindings for rtc-m48t86
Message-ID: <1364858565-17192-1-git-send-email-alex@digriz.org.uk>

Currently there are two users of rtc-m48t86 (mach-ep93xx/ts72xx.c and
mach-orion5x/ts78xx-setup.c) and both just use {read,write}b against
a memory mapped region.  As I am devicetree'ing the TS-7800, this
driver needs converting and thats what this patchset does.

The patch does the following:
 * moves m48t86.h to include/linux/platform_data/rtc-m48t86.h
 * adds a new additional interface to rtc-m48t86 via named
	resources that move the ioremap and {read,write}byte
	functionality into the driver (usable by ts7[28]xx)
 * moves the RTC detection routine from ts78xx-setup.c into rtc-m48t86.c
 * converts both ts7[28]xx to use the new interface
 * enable devicetree hooks and include documentation

Alexander Clouter (6):
  rtc: rtc-m48t86: move m48t86.h to platform_data
  rtc: rtc-m48t86: add hooks to support driver side memory mapping
  rtc: rtc-m48t86: add detect method for RTC
  arm: orion5x: move ts78xx to use rtc-m48t86 driver side memory
    interface
  arm: ep93xx: move ts72xx to use rtc-m48t86 driver side memory
    interface
  rtc: rtc-m48t86: add devicetree bindings

 .../devicetree/bindings/rtc/rtc-m48t86.txt         |   17 ++
 arch/arm/mach-ep93xx/ts72xx.c                      |   38 +--
 arch/arm/mach-orion5x/ts78xx-setup.c               |   78 ++----
 drivers/rtc/rtc-m48t86.c                           |  285 ++++++++++++++++----
 .../linux/{m48t86.h => platform_data/rtc-m48t86.h} |    0
 5 files changed, 267 insertions(+), 151 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/rtc/rtc-m48t86.txt
 rename include/linux/{m48t86.h => platform_data/rtc-m48t86.h} (100%)

-- 
1.7.10.4



From alex at digriz.org.uk  Mon Apr  1 19:22:41 2013
From: alex at digriz.org.uk (Alexander Clouter)
Date: Tue,  2 Apr 2013 00:22:41 +0100
Subject: [PATCH 2/6] rtc: rtc-m48t86: add hooks to support driver side memory
 mapping
In-Reply-To: <1364858565-17192-1-git-send-email-alex@digriz.org.uk>
References: <1364858565-17192-1-git-send-email-alex@digriz.org.uk>
Message-ID: <1364858565-17192-3-git-send-email-alex@digriz.org.uk>

If platform_data is not defined (as before), then named memory io
ranges need to be defined ("rtc_index" and "rtc_data").  The driver
then maps those regions and uses them as the RTC index and data
addresses.

Does compile with the following warnings, I cannot see the codepath
affected myself:
----
drivers/rtc/rtc-m48t86.c: In function ?m48t86_rtc_probe?:
drivers/rtc/rtc-m48t86.c:180: warning: ?res_index? may be used uninitialized in this function
drivers/rtc/rtc-m48t86.c:180: warning: ?res_data? may be used uninitialized in this function
----

Signed-off-by: Alexander Clouter <alex at digriz.org.uk>
---
 drivers/rtc/rtc-m48t86.c |  230 ++++++++++++++++++++++++++++++++++------------
 1 file changed, 173 insertions(+), 57 deletions(-)

diff --git a/drivers/rtc/rtc-m48t86.c b/drivers/rtc/rtc-m48t86.c
index 25e0116..6f99e64 100644
--- a/drivers/rtc/rtc-m48t86.c
+++ b/drivers/rtc/rtc-m48t86.c
@@ -18,6 +18,8 @@
 #include <linux/platform_device.h>
 #include <linux/platform_data/rtc-m48t86.h>
 #include <linux/bcd.h>
+#include <linux/slab.h>
+#include <linux/io.h>
 
 #define M48T86_REG_SEC		0x00
 #define M48T86_REG_SECALRM	0x01
@@ -41,40 +43,71 @@
 
 #define DRV_VERSION "0.1"
 
+struct m48t86_rtc_private_data {
+	void __iomem		*io_index;
+	void __iomem		*io_data;
+
+	struct rtc_device	*rtc;
+	struct m48t86_ops	*ops;
+};
+
+static void m48t86_rtc_writebyte(struct device *dev,
+			unsigned char value, unsigned long addr)
+{
+	struct m48t86_rtc_private_data *priv = dev_get_drvdata(dev);
+
+	if (priv->ops) {
+		priv->ops->writebyte(value, addr);
+		return;
+	}
+
+	writeb(addr, priv->io_index);
+	writeb(value, priv->io_data);
+}
+
+static unsigned char m48t86_rtc_readbyte(struct device *dev,
+			unsigned long addr)
+{
+	struct m48t86_rtc_private_data *priv = dev_get_drvdata(dev);
+
+	if (priv->ops)
+		return priv->ops->readbyte(addr);
+
+	writeb(addr, priv->io_index);
+	return readb(priv->io_data);
+}
 
 static int m48t86_rtc_read_time(struct device *dev, struct rtc_time *tm)
 {
 	unsigned char reg;
-	struct platform_device *pdev = to_platform_device(dev);
-	struct m48t86_ops *ops = pdev->dev.platform_data;
 
-	reg = ops->readbyte(M48T86_REG_B);
+	reg = m48t86_rtc_readbyte(dev, M48T86_REG_B);
 
 	if (reg & M48T86_REG_B_DM) {
 		/* data (binary) mode */
-		tm->tm_sec	= ops->readbyte(M48T86_REG_SEC);
-		tm->tm_min	= ops->readbyte(M48T86_REG_MIN);
-		tm->tm_hour	= ops->readbyte(M48T86_REG_HOUR) & 0x3F;
-		tm->tm_mday	= ops->readbyte(M48T86_REG_DOM);
+		tm->tm_sec	= m48t86_rtc_readbyte(dev, M48T86_REG_SEC);
+		tm->tm_min	= m48t86_rtc_readbyte(dev, M48T86_REG_MIN);
+		tm->tm_hour	= m48t86_rtc_readbyte(dev, M48T86_REG_HOUR) & 0x3F;
+		tm->tm_mday	= m48t86_rtc_readbyte(dev, M48T86_REG_DOM);
 		/* tm_mon is 0-11 */
-		tm->tm_mon	= ops->readbyte(M48T86_REG_MONTH) - 1;
-		tm->tm_year	= ops->readbyte(M48T86_REG_YEAR) + 100;
-		tm->tm_wday	= ops->readbyte(M48T86_REG_DOW);
+		tm->tm_mon	= m48t86_rtc_readbyte(dev, M48T86_REG_MONTH) - 1;
+		tm->tm_year	= m48t86_rtc_readbyte(dev, M48T86_REG_YEAR) + 100;
+		tm->tm_wday	= m48t86_rtc_readbyte(dev, M48T86_REG_DOW);
 	} else {
 		/* bcd mode */
-		tm->tm_sec	= bcd2bin(ops->readbyte(M48T86_REG_SEC));
-		tm->tm_min	= bcd2bin(ops->readbyte(M48T86_REG_MIN));
-		tm->tm_hour	= bcd2bin(ops->readbyte(M48T86_REG_HOUR) & 0x3F);
-		tm->tm_mday	= bcd2bin(ops->readbyte(M48T86_REG_DOM));
+		tm->tm_sec	= bcd2bin(m48t86_rtc_readbyte(dev, M48T86_REG_SEC));
+		tm->tm_min	= bcd2bin(m48t86_rtc_readbyte(dev, M48T86_REG_MIN));
+		tm->tm_hour	= bcd2bin(m48t86_rtc_readbyte(dev, M48T86_REG_HOUR) & 0x3F);
+		tm->tm_mday	= bcd2bin(m48t86_rtc_readbyte(dev, M48T86_REG_DOM));
 		/* tm_mon is 0-11 */
-		tm->tm_mon	= bcd2bin(ops->readbyte(M48T86_REG_MONTH)) - 1;
-		tm->tm_year	= bcd2bin(ops->readbyte(M48T86_REG_YEAR)) + 100;
-		tm->tm_wday	= bcd2bin(ops->readbyte(M48T86_REG_DOW));
+		tm->tm_mon	= bcd2bin(m48t86_rtc_readbyte(dev, M48T86_REG_MONTH)) - 1;
+		tm->tm_year	= bcd2bin(m48t86_rtc_readbyte(dev, M48T86_REG_YEAR)) + 100;
+		tm->tm_wday	= bcd2bin(m48t86_rtc_readbyte(dev, M48T86_REG_DOW));
 	}
 
 	/* correct the hour if the clock is in 12h mode */
 	if (!(reg & M48T86_REG_B_H24))
-		if (ops->readbyte(M48T86_REG_HOUR) & 0x80)
+		if (m48t86_rtc_readbyte(dev, M48T86_REG_HOUR) & 0x80)
 			tm->tm_hour += 12;
 
 	return rtc_valid_tm(tm);
@@ -83,38 +116,36 @@ static int m48t86_rtc_read_time(struct device *dev, struct rtc_time *tm)
 static int m48t86_rtc_set_time(struct device *dev, struct rtc_time *tm)
 {
 	unsigned char reg;
-	struct platform_device *pdev = to_platform_device(dev);
-	struct m48t86_ops *ops = pdev->dev.platform_data;
 
-	reg = ops->readbyte(M48T86_REG_B);
+	reg = m48t86_rtc_readbyte(dev, M48T86_REG_B);
 
 	/* update flag and 24h mode */
 	reg |= M48T86_REG_B_SET | M48T86_REG_B_H24;
-	ops->writebyte(reg, M48T86_REG_B);
+	m48t86_rtc_writebyte(dev, reg, M48T86_REG_B);
 
 	if (reg & M48T86_REG_B_DM) {
 		/* data (binary) mode */
-		ops->writebyte(tm->tm_sec, M48T86_REG_SEC);
-		ops->writebyte(tm->tm_min, M48T86_REG_MIN);
-		ops->writebyte(tm->tm_hour, M48T86_REG_HOUR);
-		ops->writebyte(tm->tm_mday, M48T86_REG_DOM);
-		ops->writebyte(tm->tm_mon + 1, M48T86_REG_MONTH);
-		ops->writebyte(tm->tm_year % 100, M48T86_REG_YEAR);
-		ops->writebyte(tm->tm_wday, M48T86_REG_DOW);
+		m48t86_rtc_writebyte(dev, tm->tm_sec, M48T86_REG_SEC);
+		m48t86_rtc_writebyte(dev, tm->tm_min, M48T86_REG_MIN);
+		m48t86_rtc_writebyte(dev, tm->tm_hour, M48T86_REG_HOUR);
+		m48t86_rtc_writebyte(dev, tm->tm_mday, M48T86_REG_DOM);
+		m48t86_rtc_writebyte(dev, tm->tm_mon + 1, M48T86_REG_MONTH);
+		m48t86_rtc_writebyte(dev, tm->tm_year % 100, M48T86_REG_YEAR);
+		m48t86_rtc_writebyte(dev, tm->tm_wday, M48T86_REG_DOW);
 	} else {
 		/* bcd mode */
-		ops->writebyte(bin2bcd(tm->tm_sec), M48T86_REG_SEC);
-		ops->writebyte(bin2bcd(tm->tm_min), M48T86_REG_MIN);
-		ops->writebyte(bin2bcd(tm->tm_hour), M48T86_REG_HOUR);
-		ops->writebyte(bin2bcd(tm->tm_mday), M48T86_REG_DOM);
-		ops->writebyte(bin2bcd(tm->tm_mon + 1), M48T86_REG_MONTH);
-		ops->writebyte(bin2bcd(tm->tm_year % 100), M48T86_REG_YEAR);
-		ops->writebyte(bin2bcd(tm->tm_wday), M48T86_REG_DOW);
+		m48t86_rtc_writebyte(dev, bin2bcd(tm->tm_sec), M48T86_REG_SEC);
+		m48t86_rtc_writebyte(dev, bin2bcd(tm->tm_min), M48T86_REG_MIN);
+		m48t86_rtc_writebyte(dev, bin2bcd(tm->tm_hour), M48T86_REG_HOUR);
+		m48t86_rtc_writebyte(dev, bin2bcd(tm->tm_mday), M48T86_REG_DOM);
+		m48t86_rtc_writebyte(dev, bin2bcd(tm->tm_mon + 1), M48T86_REG_MONTH);
+		m48t86_rtc_writebyte(dev, bin2bcd(tm->tm_year % 100), M48T86_REG_YEAR);
+		m48t86_rtc_writebyte(dev, bin2bcd(tm->tm_wday), M48T86_REG_DOW);
 	}
 
 	/* update ended */
 	reg &= ~M48T86_REG_B_SET;
-	ops->writebyte(reg, M48T86_REG_B);
+	m48t86_rtc_writebyte(dev, reg, M48T86_REG_B);
 
 	return 0;
 }
@@ -122,15 +153,13 @@ static int m48t86_rtc_set_time(struct device *dev, struct rtc_time *tm)
 static int m48t86_rtc_proc(struct device *dev, struct seq_file *seq)
 {
 	unsigned char reg;
-	struct platform_device *pdev = to_platform_device(dev);
-	struct m48t86_ops *ops = pdev->dev.platform_data;
 
-	reg = ops->readbyte(M48T86_REG_B);
+	reg = m48t86_rtc_readbyte(dev, M48T86_REG_B);
 
 	seq_printf(seq, "mode\t\t: %s\n",
 		 (reg & M48T86_REG_B_DM) ? "binary" : "bcd");
 
-	reg = ops->readbyte(M48T86_REG_D);
+	reg = m48t86_rtc_readbyte(dev, M48T86_REG_D);
 
 	seq_printf(seq, "battery\t\t: %s\n",
 		 (reg & M48T86_REG_D_VRT) ? "ok" : "exhausted");
@@ -144,34 +173,121 @@ static const struct rtc_class_ops m48t86_rtc_ops = {
 	.proc		= m48t86_rtc_proc,
 };
 
-static int m48t86_rtc_probe(struct platform_device *dev)
+static int m48t86_rtc_probe(struct platform_device *pdev)
 {
 	unsigned char reg;
-	struct m48t86_ops *ops = dev->dev.platform_data;
-	struct rtc_device *rtc = rtc_device_register("m48t86",
-				&dev->dev, &m48t86_rtc_ops, THIS_MODULE);
-
-	if (IS_ERR(rtc))
-		return PTR_ERR(rtc);
-
-	platform_set_drvdata(dev, rtc);
+	int err;
+	struct resource *res_index, *res_data;
+	struct m48t86_rtc_private_data *priv;
+
+	/* Allocate memory for the device structure (and zero it) */
+	priv = kzalloc(sizeof(struct m48t86_rtc_private_data), GFP_KERNEL);
+	if (!priv)
+		return -ENOMEM;
+
+	platform_set_drvdata(pdev, priv);
+
+	if (!pdev->dev.platform_data) {
+		res_index = platform_get_resource_byname(
+					pdev, IORESOURCE_MEM, "rtc_index");
+		if (!res_index) {
+			err = -ENXIO;
+			goto out_free;
+		}
+
+		res_data = platform_get_resource_byname(
+					pdev, IORESOURCE_MEM, "rtc_data");
+		if (!res_data) {
+			err = -ENXIO;
+			goto out_free;
+		}
+
+		if (!request_mem_region(res_index->start,
+					resource_size(res_index),
+					dev_name(&pdev->dev))) {
+			err = -EBUSY;
+			goto out_free;
+		}
+
+		if (!request_mem_region(res_data->start,
+					resource_size(res_data),
+					dev_name(&pdev->dev))) {
+			err = -EBUSY;
+			goto out_release_index;
+		}
+
+		priv->io_index = ioremap(res_index->start,
+					resource_size(res_index));
+		if (!priv->io_index) {
+			err = -EIO;
+			goto out_release_data;
+		}
+
+		priv->io_data = ioremap(res_data->start,
+					resource_size(res_data));
+		if (!priv->io_data) {
+			err = -EIO;
+			goto out_io_index;
+		}
+	} else
+		priv->ops = pdev->dev.platform_data;
+
+	priv->rtc = rtc_device_register("m48t86",
+				&pdev->dev, &m48t86_rtc_ops, THIS_MODULE);
+	if (IS_ERR(priv->rtc)) {
+		err = PTR_ERR(priv->rtc);
+		if (!pdev->dev.platform_data)
+			goto out_io_data;
+		else
+			goto out_free;
+	}
 
 	/* read battery status */
-	reg = ops->readbyte(M48T86_REG_D);
-	dev_info(&dev->dev, "battery %s\n",
+	reg = m48t86_rtc_readbyte(&pdev->dev, M48T86_REG_D);
+	dev_info(&pdev->dev, "battery %s\n",
 		(reg & M48T86_REG_D_VRT) ? "ok" : "exhausted");
 
 	return 0;
+
+out_io_data:
+	iounmap(priv->io_data);
+out_io_index:
+	iounmap(priv->io_index);
+out_release_data:
+	release_mem_region(res_data->start, resource_size(res_data));
+out_release_index:
+	release_mem_region(res_index->start, resource_size(res_index));
+out_free:
+	platform_set_drvdata(pdev, NULL);
+	kfree(priv);
+	return err;
 }
 
-static int m48t86_rtc_remove(struct platform_device *dev)
+static int m48t86_rtc_remove(struct platform_device *pdev)
 {
-	struct rtc_device *rtc = platform_get_drvdata(dev);
+	struct resource *res;
+	struct m48t86_rtc_private_data *priv = platform_get_drvdata(pdev);
+
+	if (priv->rtc)
+		rtc_device_unregister(priv->rtc);
+
+	if (priv->io_data) {
+		iounmap(priv->io_data);
+		res = platform_get_resource_byname(
+					pdev, IORESOURCE_MEM, "rtc_data");
+		release_mem_region(res->start, resource_size(res));
+	}
+
+	if (priv->io_index) {
+		iounmap(priv->io_index);
+		res = platform_get_resource_byname(
+					pdev, IORESOURCE_MEM, "rtc_index");
+		release_mem_region(res->start, resource_size(res));
+	}
 
- 	if (rtc)
-		rtc_device_unregister(rtc);
+	platform_set_drvdata(pdev, NULL);
 
-	platform_set_drvdata(dev, NULL);
+	kfree(priv);
 
 	return 0;
 }
-- 
1.7.10.4



From alex at digriz.org.uk  Mon Apr  1 19:22:44 2013
From: alex at digriz.org.uk (Alexander Clouter)
Date: Tue,  2 Apr 2013 00:22:44 +0100
Subject: [PATCH 5/6] arm: ep93xx: move ts72xx to use rtc-m48t86 driver side
 memory interface
In-Reply-To: <1364858565-17192-1-git-send-email-alex@digriz.org.uk>
References: <1364858565-17192-1-git-send-email-alex@digriz.org.uk>
Message-ID: <1364858565-17192-6-git-send-email-alex@digriz.org.uk>

Remove platform_data hooks into rtc-m48t86 and use named resource regions.

Signed-off-by: Alexander Clouter <alex at digriz.org.uk>
---
 arch/arm/mach-ep93xx/ts72xx.c |   38 +++++++-------------------------------
 1 file changed, 7 insertions(+), 31 deletions(-)

diff --git a/arch/arm/mach-ep93xx/ts72xx.c b/arch/arm/mach-ep93xx/ts72xx.c
index a278639..baadffd 100644
--- a/arch/arm/mach-ep93xx/ts72xx.c
+++ b/arch/arm/mach-ep93xx/ts72xx.c
@@ -16,7 +16,6 @@
 #include <linux/init.h>
 #include <linux/platform_device.h>
 #include <linux/io.h>
-#include <linux/platform_data/rtc-m48t86.h>
 #include <linux/mtd/nand.h>
 #include <linux/mtd/partitions.h>
 
@@ -45,16 +44,6 @@ static struct map_desc ts72xx_io_desc[] __initdata = {
 		.pfn		= __phys_to_pfn(TS72XX_OPTIONS2_PHYS_BASE),
 		.length		= TS72XX_OPTIONS2_SIZE,
 		.type		= MT_DEVICE,
-	}, {
-		.virtual	= (unsigned long)TS72XX_RTC_INDEX_VIRT_BASE,
-		.pfn		= __phys_to_pfn(TS72XX_RTC_INDEX_PHYS_BASE),
-		.length		= TS72XX_RTC_INDEX_SIZE,
-		.type		= MT_DEVICE,
-	}, {
-		.virtual	= (unsigned long)TS72XX_RTC_DATA_VIRT_BASE,
-		.pfn		= __phys_to_pfn(TS72XX_RTC_DATA_PHYS_BASE),
-		.length		= TS72XX_RTC_DATA_SIZE,
-		.type		= MT_DEVICE,
 	}
 };
 
@@ -179,31 +168,18 @@ static void __init ts72xx_register_flash(void)
 	}
 }
 
-
-static unsigned char ts72xx_rtc_readbyte(unsigned long addr)
-{
-	__raw_writeb(addr, TS72XX_RTC_INDEX_VIRT_BASE);
-	return __raw_readb(TS72XX_RTC_DATA_VIRT_BASE);
-}
-
-static void ts72xx_rtc_writebyte(unsigned char value, unsigned long addr)
-{
-	__raw_writeb(addr, TS72XX_RTC_INDEX_VIRT_BASE);
-	__raw_writeb(value, TS72XX_RTC_DATA_VIRT_BASE);
-}
-
-static struct m48t86_ops ts72xx_rtc_ops = {
-	.readbyte	= ts72xx_rtc_readbyte,
-	.writebyte	= ts72xx_rtc_writebyte,
+static struct resource ts72xx_rtc_resource[] = {
+	DEFINE_RES_NAMED(TS72XX_RTC_INDEX_PHYS_BASE, 4,
+				"rtc_index", IORESOURCE_MEM),
+	DEFINE_RES_NAMED(TS72XX_RTC_DATA_PHYS_BASE, 4,
+				"rtc_data", IORESOURCE_MEM),
 };
 
 static struct platform_device ts72xx_rtc_device = {
 	.name		= "rtc-m48t86",
 	.id		= -1,
-	.dev		= {
-		.platform_data	= &ts72xx_rtc_ops,
-	},
-	.num_resources	= 0,
+	.resource	= ts72xx_rtc_resource,
+	.num_resources	= ARRAY_SIZE(ts72xx_rtc_resource),
 };
 
 static struct resource ts72xx_wdt_resources[] = {
-- 
1.7.10.4



From alex at digriz.org.uk  Mon Apr  1 19:22:43 2013
From: alex at digriz.org.uk (Alexander Clouter)
Date: Tue,  2 Apr 2013 00:22:43 +0100
Subject: [PATCH 4/6] arm: orion5x: move ts78xx to use rtc-m48t86 driver side
 memory interface
In-Reply-To: <1364858565-17192-1-git-send-email-alex@digriz.org.uk>
References: <1364858565-17192-1-git-send-email-alex@digriz.org.uk>
Message-ID: <1364858565-17192-5-git-send-email-alex@digriz.org.uk>

Remove platform_data hooks into rtc-m48t86 and use named resource regions.

Signed-off-by: Alexander Clouter <alex at digriz.org.uk>
---
 arch/arm/mach-orion5x/ts78xx-setup.c |   78 ++++++++--------------------------
 1 file changed, 17 insertions(+), 61 deletions(-)

diff --git a/arch/arm/mach-orion5x/ts78xx-setup.c b/arch/arm/mach-orion5x/ts78xx-setup.c
index ffe3603..613216f 100644
--- a/arch/arm/mach-orion5x/ts78xx-setup.c
+++ b/arch/arm/mach-orion5x/ts78xx-setup.c
@@ -16,7 +16,6 @@
 #include <linux/platform_device.h>
 #include <linux/mv643xx_eth.h>
 #include <linux/ata_platform.h>
-#include <linux/platform_data/rtc-m48t86.h>
 #include <linux/mtd/nand.h>
 #include <linux/mtd/partitions.h>
 #include <linux/timeriomem-rng.h>
@@ -80,78 +79,35 @@ static struct mv_sata_platform_data ts78xx_sata_data = {
 /*****************************************************************************
  * RTC M48T86 - nicked^Wborrowed from arch/arm/mach-ep93xx/ts72xx.c
  ****************************************************************************/
-#define TS_RTC_CTRL	(TS78XX_FPGA_REGS_VIRT_BASE + 0x808)
-#define TS_RTC_DATA	(TS78XX_FPGA_REGS_VIRT_BASE + 0x80c)
+#define TS_RTC_INDEX	(TS78XX_FPGA_REGS_PHYS_BASE + 0x808)
+#define TS_RTC_DATA	(TS78XX_FPGA_REGS_PHYS_BASE + 0x80c)
 
-static unsigned char ts78xx_ts_rtc_readbyte(unsigned long addr)
-{
-	writeb(addr, TS_RTC_CTRL);
-	return readb(TS_RTC_DATA);
-}
-
-static void ts78xx_ts_rtc_writebyte(unsigned char value, unsigned long addr)
-{
-	writeb(addr, TS_RTC_CTRL);
-	writeb(value, TS_RTC_DATA);
-}
-
-static struct m48t86_ops ts78xx_ts_rtc_ops = {
-	.readbyte	= ts78xx_ts_rtc_readbyte,
-	.writebyte	= ts78xx_ts_rtc_writebyte,
+static struct resource ts78xx_ts_rtc_resource[] = {
+	DEFINE_RES_NAMED(TS_RTC_INDEX, 4, "rtc_index", IORESOURCE_MEM),
+	DEFINE_RES_NAMED(TS_RTC_DATA, 4, "rtc_data", IORESOURCE_MEM),
 };
 
 static struct platform_device ts78xx_ts_rtc_device = {
 	.name		= "rtc-m48t86",
 	.id		= -1,
-	.dev		= {
-		.platform_data	= &ts78xx_ts_rtc_ops,
-	},
-	.num_resources	= 0,
+	.resource	= ts78xx_ts_rtc_resource,
+	.num_resources	= ARRAY_SIZE(ts78xx_ts_rtc_resource),
 };
 
-/*
- * TS uses some of the user storage space on the RTC chip so see if it is
- * present; as it's an optional feature at purchase time and not all boards
- * will have it present
- *
- * I've used the method TS use in their rtc7800.c example for the detection
- *
- * TODO: track down a guinea pig without an RTC to see if we can work out a
- *		better RTC detection routine
- */
 static int ts78xx_ts_rtc_load(void)
 {
 	int rc;
-	unsigned char tmp_rtc0, tmp_rtc1;
-
-	tmp_rtc0 = ts78xx_ts_rtc_readbyte(126);
-	tmp_rtc1 = ts78xx_ts_rtc_readbyte(127);
-
-	ts78xx_ts_rtc_writebyte(0x00, 126);
-	ts78xx_ts_rtc_writebyte(0x55, 127);
-	if (ts78xx_ts_rtc_readbyte(127) == 0x55) {
-		ts78xx_ts_rtc_writebyte(0xaa, 127);
-		if (ts78xx_ts_rtc_readbyte(127) == 0xaa
-				&& ts78xx_ts_rtc_readbyte(126) == 0x00) {
-			ts78xx_ts_rtc_writebyte(tmp_rtc0, 126);
-			ts78xx_ts_rtc_writebyte(tmp_rtc1, 127);
-
-			if (ts78xx_fpga.supports.ts_rtc.init == 0) {
-				rc = platform_device_register(&ts78xx_ts_rtc_device);
-				if (!rc)
-					ts78xx_fpga.supports.ts_rtc.init = 1;
-			} else
-				rc = platform_device_add(&ts78xx_ts_rtc_device);
-
-			if (rc)
-				pr_info("RTC could not be registered: %d\n",
-					rc);
-			return rc;
-		}
-	}
 
-	pr_info("RTC not found\n");
-	return -ENODEV;
+	if (ts78xx_fpga.supports.ts_rtc.init == 0) {
+		rc = platform_device_register(&ts78xx_ts_rtc_device);
+		if (!rc)
+			ts78xx_fpga.supports.ts_rtc.init = 1;
+	} else
+		rc = platform_device_add(&ts78xx_ts_rtc_device);
+
+	if (rc)
+		pr_info("RTC could not be registered: %d\n", rc);
+	return rc;
 };
 
 static void ts78xx_ts_rtc_unload(void)
-- 
1.7.10.4



From alex at digriz.org.uk  Mon Apr  1 19:22:45 2013
From: alex at digriz.org.uk (Alexander Clouter)
Date: Tue,  2 Apr 2013 00:22:45 +0100
Subject: [PATCH 6/6] rtc: rtc-m48t86: add devicetree bindings
In-Reply-To: <1364858565-17192-1-git-send-email-alex@digriz.org.uk>
References: <1364858565-17192-1-git-send-email-alex@digriz.org.uk>
Message-ID: <1364858565-17192-7-git-send-email-alex@digriz.org.uk>

Add devicetree bindings (and documentation) for rtc-m48t86.

Signed-off-by: Alexander Clouter <alex at digriz.org.uk>
---
 Documentation/devicetree/bindings/rtc/rtc-m48t86.txt |   17 +++++++++++++++++
 drivers/rtc/rtc-m48t86.c                             |   12 ++++++++++--
 2 files changed, 27 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/rtc/rtc-m48t86.txt

diff --git a/Documentation/devicetree/bindings/rtc/rtc-m48t86.txt b/Documentation/devicetree/bindings/rtc/rtc-m48t86.txt
new file mode 100644
index 0000000..375ea56
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/rtc-m48t86.txt
@@ -0,0 +1,17 @@
+RTC support for the rtc-m48t86 driver
+
+Required properties:
+- compatible : "rtc-m48t86"
+- reg : Array of base physical addresses for the RTC control and data
+- reg-names : must have "rtc_index" and "rtc_data"
+
+Example:
+
+rtc at 808 {
+	#address-cells = <1>;
+	#size-cells = <1>;
+	compatible = "rtc-m48t86";
+	reg =	<0x808 0x04>,
+		<0x80c 0x04>;
+	reg-names = "rtc_index", "rtc_data";
+};
diff --git a/drivers/rtc/rtc-m48t86.c b/drivers/rtc/rtc-m48t86.c
index b8edf73..9395126 100644
--- a/drivers/rtc/rtc-m48t86.c
+++ b/drivers/rtc/rtc-m48t86.c
@@ -20,6 +20,7 @@
 #include <linux/bcd.h>
 #include <linux/slab.h>
 #include <linux/io.h>
+#include <linux/of.h>
 
 #define M48T86_REG_SEC		0x00
 #define M48T86_REG_SECALRM	0x01
@@ -335,10 +336,17 @@ static int m48t86_rtc_remove(struct platform_device *pdev)
 	return 0;
 }
 
+static const struct of_device_id m48t86_rtc_match[] = {
+	{ .compatible = "rtc-m48t86" },
+	{},
+};
+MODULE_DEVICE_TABLE(of, m48t86_rtc_match);
+
 static struct platform_driver m48t86_rtc_platform_driver = {
 	.driver		= {
-		.name	= "rtc-m48t86",
-		.owner	= THIS_MODULE,
+		.name		= "rtc-m48t86",
+		.owner		= THIS_MODULE,
+		.of_match_table	= m48t86_rtc_match,
 	},
 	.probe		= m48t86_rtc_probe,
 	.remove		= m48t86_rtc_remove,
-- 
1.7.10.4



From soren.brinkmann at xilinx.com  Mon Apr  1 19:24:12 2013
From: soren.brinkmann at xilinx.com (=?utf-8?B?U8O2cmVu?= Brinkmann)
Date: Mon, 1 Apr 2013 16:24:12 -0700
Subject: [PATCH] clk: divider: Use DIV_ROUND_CLOSEST
In-Reply-To: <20130327013703.4014.45615@quantum>
References: <20130320001609.8663.21043@quantum>
 <f3ff0545-52cd-4b7b-967e-f81324ba0152@CH1EHSMHS040.ehs.local>
 <20130320185051.GA28349@pengutronix.de>
 <20130321091531.GN20530@pengutronix.de>
 <cffdea50-cadf-4662-a4fb-c61ab853fc4c@VA3EHSMHS014.ehs.local>
 <20130327013703.4014.45615@quantum>
Message-ID: <4b6b9df8-e221-4e52-82d3-efdcd5de9bd1@AM1EHSMHS021.ehs.local>

On Tue, Mar 26, 2013 at 06:37:03PM -0700, Mike Turquette wrote:
> Quoting S?ren Brinkmann (2013-03-26 15:45:22)
> > On Thu, Mar 21, 2013 at 10:15:31AM +0100, Uwe Kleine-K?nig wrote:
> > > Hello,
> > > 
> > > On Wed, Mar 20, 2013 at 07:50:51PM +0100, Sascha Hauer wrote:
> > > > On Wed, Mar 20, 2013 at 09:32:51AM -0700, S?ren Brinkmann wrote:
> > > > > If the caller
> > > > > doesn't like the returned frequency he can request a different one.
> > > > > And he's eventually happy with the return value he calls
> > > > > clk_set_rate() requesting the frequency clk_round_rate() returned.
> > > > > Always rounding down seems a bit odd to me.
> > > > > 
> > > > > Another issue with the current implmentation:
> > > > > clk_divider_round_rate() calls clk_divider_bestdiv(), which uses the ROUND_UP macro, returning a rather low frequency.
> > > > 
> > > > And that is correct. clk_divider_bestdiv is used to calculate the
> > > > maximum parent frequency for which a given divider value does not
> > > > exceed the desired rate.
> > > The reason for that is that the (more?) usual constraint is like: This
> > > mmc card can handle up to 100 MHz. Or this i2c device can handle up to
> > > this and that frequency. Of course there are different constraints, e.g.
> > > for a UART if the target baud speed is 38400 you better run at 38402
> > > than at 19201.
> > > 
> > > I wonder if it depends on the clock if you want "best approximation <=
> > > requested value" or "best approximation" or on the caller. In the former
> > > case a flag for the clock would be the right thing (as suggested in this
> > > thread). If however it's the caller of round_rate who knows better which
> > > rounding is preferred than better extend the clk API.
> > > 
> > > Extending the API could just be a convenience function that doesn't
> > > affect the implementations of the clk API. E.g.:
> > > 
> > >       long clk_round_rate_nearest(struct clk *clk, unsigned long rate)
> > >       {
> > >               long lower_limit = clk_round_rate(clk, rate);
> > >               long upper_limit = clk_round_rate(clk, rate + (rate - lower_limit));
> > > 
> > >               if (rate - lower_limit < upper_limit - rate)
> > >                       return lower_limit;
> > >               else
> > >                       return upper_limit;
> > >       }
> > > 
> > I guess both approaches may work. Anybody has a preference?
> > 
> 
> A dedicated function like the one Uwe defined is better than adding
> subtlety to the existing clk_round_rate via a flag in a clock driver.
I looked at my problem again.

A new API function is probably fine for UART, ethernet drivers and
similar. Although, compared to a flag it would add some redundant
rounding, since clk_set_rate() implicitly also rounds the rate.
	clk_set_rate()
		clk_calc_new_rates()
			clk_round_rate()
But that is true for every driver which doesn't blindly call
clk_set_rate() and checks upfront through clk_round_rate() what
the actual frequency would look like.

So, do we agree to add this additional clk_round_rate_nearest()
function?
And if, should I just make Uwe's proposal another patch, additionally to
the other clk-divider change I'm working on?
Or Uwe, do you prefer to submit it yourself?


For my original problem, though, this is only part of a solution. It
appeared to be a rounding issue, but the actual root cause is the loss
of resolution when OPPs are converted to a frequency table for cpufreq.
I'm not sure how this can be resolved, yet.


	S?ren




From john.stultz at linaro.org  Mon Apr  1 19:26:18 2013
From: john.stultz at linaro.org (John Stultz)
Date: Mon, 01 Apr 2013 16:26:18 -0700
Subject: [PATCH v2 12/13] ARM: move sp804 and integrator timers to
 drivers/clocksource
In-Reply-To: <1364854883-5961-13-git-send-email-robherring2@gmail.com>
References: <1364854883-5961-1-git-send-email-robherring2@gmail.com>
 <1364854883-5961-13-git-send-email-robherring2@gmail.com>
Message-ID: <515A179A.8020800@linaro.org>

On 04/01/2013 03:21 PM, Rob Herring wrote:
> diff --git a/drivers/clocksource/integrator_ap_timer.c b/drivers/clocksource/integrator_ap_timer.c
> new file mode 100644
> index 0000000..05e6204
> --- /dev/null
> +++ b/drivers/clocksource/integrator_ap_timer.c
[snip]
> +static void __iomem * clkevt_base;
> +
> +/*
> + * IRQ handler for the timer
> + */
> +static irqreturn_t integrator_timer_interrupt(int irq, void *dev_id)
> +{
> +	struct clock_event_device *evt = dev_id;
> +
> +	/* clear the interrupt */
> +	writel(1, clkevt_base + TIMER_INTCLR);
> +
> +	evt->event_handler(evt);
> +
> +	return IRQ_HANDLED;
> +}
> +
> +static void clkevt_set_mode(enum clock_event_mode mode, struct clock_event_device *evt)
> +{
> +	u32 ctrl = readl(clkevt_base + TIMER_CTRL) & ~TIMER_CTRL_ENABLE;
> +
> +	/* Disable timer */
> +	writel(ctrl, clkevt_base + TIMER_CTRL);
> +
> +	switch (mode) {
> +	case CLOCK_EVT_MODE_PERIODIC:
> +		/* Enable the timer and start the periodic tick */
> +		writel(timer_reload, clkevt_base + TIMER_LOAD);
> +		ctrl |= TIMER_CTRL_PERIODIC | TIMER_CTRL_ENABLE;
> +		writel(ctrl, clkevt_base + TIMER_CTRL);
> +		break;
> +	case CLOCK_EVT_MODE_ONESHOT:
> +		/* Leave the timer disabled, .set_next_event will enable it */
> +		ctrl &= ~TIMER_CTRL_PERIODIC;
> +		writel(ctrl, clkevt_base + TIMER_CTRL);
> +		break;
> +	case CLOCK_EVT_MODE_UNUSED:
> +	case CLOCK_EVT_MODE_SHUTDOWN:
> +	case CLOCK_EVT_MODE_RESUME:
> +	default:
> +		/* Just leave in disabled state */
> +		break;
> +	}
> +
> +}
> +
> +static int clkevt_set_next_event(unsigned long next, struct clock_event_device *evt)
> +{
> +	unsigned long ctrl = readl(clkevt_base + TIMER_CTRL);
> +
> +	writel(ctrl & ~TIMER_CTRL_ENABLE, clkevt_base + TIMER_CTRL);
> +	writel(next, clkevt_base + TIMER_LOAD);
> +	writel(ctrl | TIMER_CTRL_ENABLE, clkevt_base + TIMER_CTRL);
> +
> +	return 0;
> +}
> +
> +static struct clock_event_device integrator_clockevent = {
> +	.name		= "timer1",
> +	.features	= CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT,
> +	.set_mode	= clkevt_set_mode,
> +	.set_next_event	= clkevt_set_next_event,
> +	.rating		= 300,
> +};
> +
> +static struct irqaction integrator_timer_irq = {
> +	.name		= "timer",
> +	.flags		= IRQF_DISABLED | IRQF_TIMER | IRQF_IRQPOLL,
> +	.handler	= integrator_timer_interrupt,
> +	.dev_id		= &integrator_clockevent,
> +};
> +
> +void __init integrator_clockevent_init(unsigned long inrate,
> +				       void __iomem *base, int irq)
> +{
> +	unsigned long rate = inrate;
> +	unsigned int ctrl = 0;
> +
> +	clkevt_base = base;
> +	/* Calculate and program a divisor */
> +	if (rate > 0x100000 * HZ) {
> +		rate /= 256;
> +		ctrl |= TIMER_CTRL_DIV256;
> +	} else if (rate > 0x10000 * HZ) {
> +		rate /= 16;
> +		ctrl |= TIMER_CTRL_DIV16;
> +	}
> +	timer_reload = rate / HZ;
> +	writel(ctrl, clkevt_base + TIMER_CTRL);
> +
> +	setup_irq(irq, &integrator_timer_irq);
> +	clockevents_config_and_register(&integrator_clockevent,
> +					rate,
> +					1,
> +					0xffffU);
> +}
> +
> +static void __init ap_of_timer_init(struct device_node *node)
> +{
> +	void __iomem *base;
> +	int irq;
> +	struct clk *clk;
> +	unsigned long rate;
> +
> +	clk = clk_get_sys("ap_timer", NULL);
> +	BUG_ON(IS_ERR(clk));
> +	clk_prepare_enable(clk);
> +	rate = clk_get_rate(clk);
> +
> +	base = of_iomap(node, 0);
> +	if (WARN_ON(!base))
> +		return;
> +
> +	writel(0, base + TIMER_CTRL);
> +
> +	if ((clksrc_base && clkevt_base) || !of_device_is_available(node)) {
> +		iounmap(base);
> +		return;
> +	}
> +
> +	irq = irq_of_parse_and_map(node, 0);
> +	if (!clkevt_base && (irq > 0))
> +		integrator_clockevent_init(rate, base, irq);
> +	else
> +		integrator_clocksource_init(rate, base);
> +}
> +CLOCKSOURCE_OF_DECLARE(integrator_ap, "integrator-timer", ap_of_timer_init);

So, most of the code here is really clockevent code and not clocksource 
code. I realize they were combined in the mach directory you're copying 
them from, but if we're going to move all this code out of the arch 
directory and into drivers/, I'd like to propose we not dump it all into 
drivers/clocksource.

For more context here see:
http://www.spinics.net/lists/arm-kernel/msg234074.html

So unless Thomas objects, would you be willing to break this change up 
adding the relevant irq related bits to a new drivers/clockevents 
directory? You can leave the sched_clock bits to clocksource for now, 
since I think that logic should eventually be integrated with the 
clocksource core.

When you resubmit, please also add Daniel Lezcano 
<daniel.lezcano at linaro.org> to the cc.

thanks
-john


From tpiepho at gmail.com  Mon Apr  1 19:27:41 2013
From: tpiepho at gmail.com (Trent Piepho)
Date: Mon, 1 Apr 2013 16:27:41 -0700
Subject: [PATCH 2/5] spi/mxs: Fix chip select control bits in DMA mode
In-Reply-To: <201304020113.42124.marex@denx.de>
References: <1364570381-17605-1-git-send-email-tpiepho@gmail.com>
 <1364570381-17605-2-git-send-email-tpiepho@gmail.com>
 <201304020113.42124.marex@denx.de>
Message-ID: <CA+7tXih2wAVeLpVoYkt4Tmo3h0YtLoZY3vCcv5s8sUD1u8_BVQ@mail.gmail.com>

On Mon, Apr 1, 2013 at 4:13 PM, Marek Vasut <marex at denx.de> wrote:
>>
>> Change the code to set the CS bits in the message transfer function
>> once.  Now the DMA and PIO txrx functions don't need to care about CS
>> at all.
>
> Ok, lemme ask this one more time -- will the DMA work with long transfers where
> the CTRL0 will be overwritten on each turn? Did you actually test this?

I don't have SPI flash, so I can't test SPI flash.  I can test other
spi devices and by capturing the pins with  a logic analyzer.  It does
work after the patch, and does not work before the patch.  The error
should be obvious from looking at the code.

ctrl0 is not overwritten, from scratch, each on transfer.  The ctrl0
value in the PIO part of the DMA is based on the current value of
ctrl0 with additional bits ORed in.   The flaw here is that bits that
should not be set are not masked out.

>>
>> -static uint32_t mxs_spi_cs_to_reg(unsigned cs)
>> +static u32 mxs_spi_cs_to_reg(unsigned cs)
>>  {
>> -     uint32_t select = 0;
>> +     u32 select = 0;

I'll make it a separate patch.


From marex at denx.de  Mon Apr  1 19:29:29 2013
From: marex at denx.de (Marek Vasut)
Date: Tue,  2 Apr 2013 01:29:29 +0200
Subject: [PATCH] ARM: mxs: Slow down the I2C clock speed
Message-ID: <1364858969-17745-1-git-send-email-marex@denx.de>

Slow down the I2C clock speed on M28 and SPS1 as it turns out the
I2C block in i.MX28 can not operate stable enough with the bus
running at 400kHz. Note that the driver used by Freescale runs
the bus at 250kHz when 400kHz speed is selected, but the mainline
Linux kernel runs the bus at actual 400kHz and that's where it is
occasionally unstable. Play safe and run the bus at 100kHz.

Signed-off-by: Marek Vasut <marex at denx.de>
Cc: Fabio Estevam <fabio.estevam at freescale.com>
Cc: Shawn Guo <shawn.guo at linaro.org>
---
 arch/arm/boot/dts/imx28-m28evk.dts |    1 -
 arch/arm/boot/dts/imx28-sps1.dts   |    1 -
 2 files changed, 2 deletions(-)

diff --git a/arch/arm/boot/dts/imx28-m28evk.dts b/arch/arm/boot/dts/imx28-m28evk.dts
index 5f0ba99..5aa44e0 100644
--- a/arch/arm/boot/dts/imx28-m28evk.dts
+++ b/arch/arm/boot/dts/imx28-m28evk.dts
@@ -177,7 +177,6 @@
 			i2c0: i2c at 80058000 {
 				pinctrl-names = "default";
 				pinctrl-0 = <&i2c0_pins_a>;
-				clock-frequency = <400000>;
 				status = "okay";
 
 				sgtl5000: codec at 0a {
diff --git a/arch/arm/boot/dts/imx28-sps1.dts b/arch/arm/boot/dts/imx28-sps1.dts
index e6cde8a..6c6a544 100644
--- a/arch/arm/boot/dts/imx28-sps1.dts
+++ b/arch/arm/boot/dts/imx28-sps1.dts
@@ -70,7 +70,6 @@
 			i2c0: i2c at 80058000 {
 				pinctrl-names = "default";
 				pinctrl-0 = <&i2c0_pins_a>;
-				clock-frequency = <400000>;
 				status = "okay";
 
 				rtc: rtc at 51 {
-- 
1.7.10.4



From marex at denx.de  Mon Apr  1 19:30:51 2013
From: marex at denx.de (Marek Vasut)
Date: Tue, 2 Apr 2013 01:30:51 +0200
Subject: [PATCH 2/5] spi/mxs: Fix chip select control bits in DMA mode
In-Reply-To: <CA+7tXih2wAVeLpVoYkt4Tmo3h0YtLoZY3vCcv5s8sUD1u8_BVQ@mail.gmail.com>
References: <1364570381-17605-1-git-send-email-tpiepho@gmail.com>
 <201304020113.42124.marex@denx.de>
 <CA+7tXih2wAVeLpVoYkt4Tmo3h0YtLoZY3vCcv5s8sUD1u8_BVQ@mail.gmail.com>
Message-ID: <201304020130.51951.marex@denx.de>

Dear Trent Piepho,

> On Mon, Apr 1, 2013 at 4:13 PM, Marek Vasut <marex at denx.de> wrote:
> >> Change the code to set the CS bits in the message transfer function
> >> once.  Now the DMA and PIO txrx functions don't need to care about CS
> >> at all.
> > 
> > Ok, lemme ask this one more time -- will the DMA work with long transfers
> > where the CTRL0 will be overwritten on each turn? Did you actually test
> > this?
> 
> I don't have SPI flash, so I can't test SPI flash.  I can test other
> spi devices and by capturing the pins with  a logic analyzer.  It does
> work after the patch, and does not work before the patch.  The error
> should be obvious from looking at the code.
> 
> ctrl0 is not overwritten, from scratch, each on transfer.  The ctrl0
> value in the PIO part of the DMA is based on the current value of
> ctrl0 with additional bits ORed in.   The flaw here is that bits that
> should not be set are not masked out.
> 
> >> -static uint32_t mxs_spi_cs_to_reg(unsigned cs)
> >> +static u32 mxs_spi_cs_to_reg(unsigned cs)
> >> 
> >>  {
> >> 
> >> -     uint32_t select = 0;
> >> +     u32 select = 0;
> 
> I'll make it a separate patch.

This is completely irrelevant change, please just submit the relevant patches.

Best regards,
Marek Vasut


From tpiepho at gmail.com  Mon Apr  1 19:32:25 2013
From: tpiepho at gmail.com (Trent Piepho)
Date: Mon, 1 Apr 2013 16:32:25 -0700
Subject: [PATCH 4/5] spi/mxs: Remove bogus setting of ssp clk rate field
In-Reply-To: <201304020116.04781.marex@denx.de>
References: <1364570381-17605-1-git-send-email-tpiepho@gmail.com>
 <1364570381-17605-4-git-send-email-tpiepho@gmail.com>
 <201304020116.04781.marex@denx.de>
Message-ID: <CA+7tXihhL2ETT+AgvX5KASZOOgi6bucModE88ztY9Q8U1gDbOQ@mail.gmail.com>

On Mon, Apr 1, 2013 at 4:16 PM, Marek Vasut <marex at denx.de> wrote:
>> The ssp struct has a clock rate field, to provide the actual value, in Hz,
>> of the SSP output clock (the rate of SSP_SCK) after mxs_ssp_set_clk_rate()
>> is called.  It should be read-only, except for mxs_ssp_set_clk_rate().
>>
>> For some reason the spi-mxs driver decides to write to this field on init,
>> and sets it to the value of the SSP input clock (clk_sspN, from the MXS
>> clocking block) in kHz.  It shouldn't be setting the value, and certainly
>> shouldn't be setting it with the wrong clock in the wrong units.
>
> I suspect this patch should also fix drivers/clk/mxs/clk-ssp.c then?

Why do you say that?  I see no problem with clk-ssp.c, as setting the
clk_rate field in the ssp struct to the actual programmed rate makes
sense.  The code in spi-mxs.c just makes no sense.  I suspect it was
added by mistake when porting the driver.


From rmallon at gmail.com  Mon Apr  1 19:36:43 2013
From: rmallon at gmail.com (Ryan Mallon)
Date: Tue, 02 Apr 2013 10:36:43 +1100
Subject: [PATCH 2/6] rtc: rtc-m48t86: add hooks to support driver side
 memory mapping
In-Reply-To: <1364858565-17192-3-git-send-email-alex@digriz.org.uk>
References: <1364858565-17192-1-git-send-email-alex@digriz.org.uk>
 <1364858565-17192-3-git-send-email-alex@digriz.org.uk>
Message-ID: <515A1A0B.8040803@gmail.com>

On 02/04/13 10:22, Alexander Clouter wrote:
> If platform_data is not defined (as before), then named memory io
> ranges need to be defined ("rtc_index" and "rtc_data").  The driver
> then maps those regions and uses them as the RTC index and data
> addresses.
> 
> Does compile with the following warnings, I cannot see the codepath
> affected myself:
> ----
> drivers/rtc/rtc-m48t86.c: In function ?m48t86_rtc_probe?:
> drivers/rtc/rtc-m48t86.c:180: warning: ?res_index? may be used uninitialized in this function
> drivers/rtc/rtc-m48t86.c:180: warning: ?res_data? may be used uninitialized in this function

It is caused by the exit paths. If pdev->dev.platform_data is set, the
res_index and res_data are never initialised, but in the error case you
still for rtc_device_register you jump to out_io_data, which will then
dereference res_index/res_data. You need to make the exit paths
conditional on pdev->dev.platform_data (or init res_index/data to NULL
and make the release_mem_regions conditional on that).

~Ryan

> ----
> 
> Signed-off-by: Alexander Clouter <alex at digriz.org.uk>
> ---
>  drivers/rtc/rtc-m48t86.c |  230 ++++++++++++++++++++++++++++++++++------------
>  1 file changed, 173 insertions(+), 57 deletions(-)
> 
> diff --git a/drivers/rtc/rtc-m48t86.c b/drivers/rtc/rtc-m48t86.c
> index 25e0116..6f99e64 100644
> --- a/drivers/rtc/rtc-m48t86.c
> +++ b/drivers/rtc/rtc-m48t86.c
> @@ -18,6 +18,8 @@
>  #include <linux/platform_device.h>
>  #include <linux/platform_data/rtc-m48t86.h>
>  #include <linux/bcd.h>
> +#include <linux/slab.h>
> +#include <linux/io.h>
>  
>  #define M48T86_REG_SEC		0x00
>  #define M48T86_REG_SECALRM	0x01
> @@ -41,40 +43,71 @@
>  
>  #define DRV_VERSION "0.1"
>  
> +struct m48t86_rtc_private_data {
> +	void __iomem		*io_index;
> +	void __iomem		*io_data;
> +
> +	struct rtc_device	*rtc;
> +	struct m48t86_ops	*ops;
> +};
> +
> +static void m48t86_rtc_writebyte(struct device *dev,
> +			unsigned char value, unsigned long addr)
> +{
> +	struct m48t86_rtc_private_data *priv = dev_get_drvdata(dev);
> +
> +	if (priv->ops) {
> +		priv->ops->writebyte(value, addr);
> +		return;
> +	}
> +
> +	writeb(addr, priv->io_index);
> +	writeb(value, priv->io_data);
> +}
> +
> +static unsigned char m48t86_rtc_readbyte(struct device *dev,
> +			unsigned long addr)
> +{
> +	struct m48t86_rtc_private_data *priv = dev_get_drvdata(dev);
> +
> +	if (priv->ops)
> +		return priv->ops->readbyte(addr);
> +
> +	writeb(addr, priv->io_index);
> +	return readb(priv->io_data);
> +}
>  
>  static int m48t86_rtc_read_time(struct device *dev, struct rtc_time *tm)
>  {
>  	unsigned char reg;
> -	struct platform_device *pdev = to_platform_device(dev);
> -	struct m48t86_ops *ops = pdev->dev.platform_data;
>  
> -	reg = ops->readbyte(M48T86_REG_B);
> +	reg = m48t86_rtc_readbyte(dev, M48T86_REG_B);
>  
>  	if (reg & M48T86_REG_B_DM) {
>  		/* data (binary) mode */
> -		tm->tm_sec	= ops->readbyte(M48T86_REG_SEC);
> -		tm->tm_min	= ops->readbyte(M48T86_REG_MIN);
> -		tm->tm_hour	= ops->readbyte(M48T86_REG_HOUR) & 0x3F;
> -		tm->tm_mday	= ops->readbyte(M48T86_REG_DOM);
> +		tm->tm_sec	= m48t86_rtc_readbyte(dev, M48T86_REG_SEC);
> +		tm->tm_min	= m48t86_rtc_readbyte(dev, M48T86_REG_MIN);
> +		tm->tm_hour	= m48t86_rtc_readbyte(dev, M48T86_REG_HOUR) & 0x3F;
> +		tm->tm_mday	= m48t86_rtc_readbyte(dev, M48T86_REG_DOM);
>  		/* tm_mon is 0-11 */
> -		tm->tm_mon	= ops->readbyte(M48T86_REG_MONTH) - 1;
> -		tm->tm_year	= ops->readbyte(M48T86_REG_YEAR) + 100;
> -		tm->tm_wday	= ops->readbyte(M48T86_REG_DOW);
> +		tm->tm_mon	= m48t86_rtc_readbyte(dev, M48T86_REG_MONTH) - 1;
> +		tm->tm_year	= m48t86_rtc_readbyte(dev, M48T86_REG_YEAR) + 100;
> +		tm->tm_wday	= m48t86_rtc_readbyte(dev, M48T86_REG_DOW);
>  	} else {
>  		/* bcd mode */
> -		tm->tm_sec	= bcd2bin(ops->readbyte(M48T86_REG_SEC));
> -		tm->tm_min	= bcd2bin(ops->readbyte(M48T86_REG_MIN));
> -		tm->tm_hour	= bcd2bin(ops->readbyte(M48T86_REG_HOUR) & 0x3F);
> -		tm->tm_mday	= bcd2bin(ops->readbyte(M48T86_REG_DOM));
> +		tm->tm_sec	= bcd2bin(m48t86_rtc_readbyte(dev, M48T86_REG_SEC));
> +		tm->tm_min	= bcd2bin(m48t86_rtc_readbyte(dev, M48T86_REG_MIN));
> +		tm->tm_hour	= bcd2bin(m48t86_rtc_readbyte(dev, M48T86_REG_HOUR) & 0x3F);
> +		tm->tm_mday	= bcd2bin(m48t86_rtc_readbyte(dev, M48T86_REG_DOM));
>  		/* tm_mon is 0-11 */
> -		tm->tm_mon	= bcd2bin(ops->readbyte(M48T86_REG_MONTH)) - 1;
> -		tm->tm_year	= bcd2bin(ops->readbyte(M48T86_REG_YEAR)) + 100;
> -		tm->tm_wday	= bcd2bin(ops->readbyte(M48T86_REG_DOW));
> +		tm->tm_mon	= bcd2bin(m48t86_rtc_readbyte(dev, M48T86_REG_MONTH)) - 1;
> +		tm->tm_year	= bcd2bin(m48t86_rtc_readbyte(dev, M48T86_REG_YEAR)) + 100;
> +		tm->tm_wday	= bcd2bin(m48t86_rtc_readbyte(dev, M48T86_REG_DOW));
>  	}
>  
>  	/* correct the hour if the clock is in 12h mode */
>  	if (!(reg & M48T86_REG_B_H24))
> -		if (ops->readbyte(M48T86_REG_HOUR) & 0x80)
> +		if (m48t86_rtc_readbyte(dev, M48T86_REG_HOUR) & 0x80)
>  			tm->tm_hour += 12;
>  
>  	return rtc_valid_tm(tm);
> @@ -83,38 +116,36 @@ static int m48t86_rtc_read_time(struct device *dev, struct rtc_time *tm)
>  static int m48t86_rtc_set_time(struct device *dev, struct rtc_time *tm)
>  {
>  	unsigned char reg;
> -	struct platform_device *pdev = to_platform_device(dev);
> -	struct m48t86_ops *ops = pdev->dev.platform_data;
>  
> -	reg = ops->readbyte(M48T86_REG_B);
> +	reg = m48t86_rtc_readbyte(dev, M48T86_REG_B);
>  
>  	/* update flag and 24h mode */
>  	reg |= M48T86_REG_B_SET | M48T86_REG_B_H24;
> -	ops->writebyte(reg, M48T86_REG_B);
> +	m48t86_rtc_writebyte(dev, reg, M48T86_REG_B);
>  
>  	if (reg & M48T86_REG_B_DM) {
>  		/* data (binary) mode */
> -		ops->writebyte(tm->tm_sec, M48T86_REG_SEC);
> -		ops->writebyte(tm->tm_min, M48T86_REG_MIN);
> -		ops->writebyte(tm->tm_hour, M48T86_REG_HOUR);
> -		ops->writebyte(tm->tm_mday, M48T86_REG_DOM);
> -		ops->writebyte(tm->tm_mon + 1, M48T86_REG_MONTH);
> -		ops->writebyte(tm->tm_year % 100, M48T86_REG_YEAR);
> -		ops->writebyte(tm->tm_wday, M48T86_REG_DOW);
> +		m48t86_rtc_writebyte(dev, tm->tm_sec, M48T86_REG_SEC);
> +		m48t86_rtc_writebyte(dev, tm->tm_min, M48T86_REG_MIN);
> +		m48t86_rtc_writebyte(dev, tm->tm_hour, M48T86_REG_HOUR);
> +		m48t86_rtc_writebyte(dev, tm->tm_mday, M48T86_REG_DOM);
> +		m48t86_rtc_writebyte(dev, tm->tm_mon + 1, M48T86_REG_MONTH);
> +		m48t86_rtc_writebyte(dev, tm->tm_year % 100, M48T86_REG_YEAR);
> +		m48t86_rtc_writebyte(dev, tm->tm_wday, M48T86_REG_DOW);
>  	} else {
>  		/* bcd mode */
> -		ops->writebyte(bin2bcd(tm->tm_sec), M48T86_REG_SEC);
> -		ops->writebyte(bin2bcd(tm->tm_min), M48T86_REG_MIN);
> -		ops->writebyte(bin2bcd(tm->tm_hour), M48T86_REG_HOUR);
> -		ops->writebyte(bin2bcd(tm->tm_mday), M48T86_REG_DOM);
> -		ops->writebyte(bin2bcd(tm->tm_mon + 1), M48T86_REG_MONTH);
> -		ops->writebyte(bin2bcd(tm->tm_year % 100), M48T86_REG_YEAR);
> -		ops->writebyte(bin2bcd(tm->tm_wday), M48T86_REG_DOW);
> +		m48t86_rtc_writebyte(dev, bin2bcd(tm->tm_sec), M48T86_REG_SEC);
> +		m48t86_rtc_writebyte(dev, bin2bcd(tm->tm_min), M48T86_REG_MIN);
> +		m48t86_rtc_writebyte(dev, bin2bcd(tm->tm_hour), M48T86_REG_HOUR);
> +		m48t86_rtc_writebyte(dev, bin2bcd(tm->tm_mday), M48T86_REG_DOM);
> +		m48t86_rtc_writebyte(dev, bin2bcd(tm->tm_mon + 1), M48T86_REG_MONTH);
> +		m48t86_rtc_writebyte(dev, bin2bcd(tm->tm_year % 100), M48T86_REG_YEAR);
> +		m48t86_rtc_writebyte(dev, bin2bcd(tm->tm_wday), M48T86_REG_DOW);
>  	}
>  
>  	/* update ended */
>  	reg &= ~M48T86_REG_B_SET;
> -	ops->writebyte(reg, M48T86_REG_B);
> +	m48t86_rtc_writebyte(dev, reg, M48T86_REG_B);
>  
>  	return 0;
>  }
> @@ -122,15 +153,13 @@ static int m48t86_rtc_set_time(struct device *dev, struct rtc_time *tm)
>  static int m48t86_rtc_proc(struct device *dev, struct seq_file *seq)
>  {
>  	unsigned char reg;
> -	struct platform_device *pdev = to_platform_device(dev);
> -	struct m48t86_ops *ops = pdev->dev.platform_data;
>  
> -	reg = ops->readbyte(M48T86_REG_B);
> +	reg = m48t86_rtc_readbyte(dev, M48T86_REG_B);
>  
>  	seq_printf(seq, "mode\t\t: %s\n",
>  		 (reg & M48T86_REG_B_DM) ? "binary" : "bcd");
>  
> -	reg = ops->readbyte(M48T86_REG_D);
> +	reg = m48t86_rtc_readbyte(dev, M48T86_REG_D);
>  
>  	seq_printf(seq, "battery\t\t: %s\n",
>  		 (reg & M48T86_REG_D_VRT) ? "ok" : "exhausted");
> @@ -144,34 +173,121 @@ static const struct rtc_class_ops m48t86_rtc_ops = {
>  	.proc		= m48t86_rtc_proc,
>  };
>  
> -static int m48t86_rtc_probe(struct platform_device *dev)
> +static int m48t86_rtc_probe(struct platform_device *pdev)
>  {
>  	unsigned char reg;
> -	struct m48t86_ops *ops = dev->dev.platform_data;
> -	struct rtc_device *rtc = rtc_device_register("m48t86",
> -				&dev->dev, &m48t86_rtc_ops, THIS_MODULE);
> -
> -	if (IS_ERR(rtc))
> -		return PTR_ERR(rtc);
> -
> -	platform_set_drvdata(dev, rtc);
> +	int err;
> +	struct resource *res_index, *res_data;
> +	struct m48t86_rtc_private_data *priv;
> +
> +	/* Allocate memory for the device structure (and zero it) */
> +	priv = kzalloc(sizeof(struct m48t86_rtc_private_data), GFP_KERNEL);
> +	if (!priv)
> +		return -ENOMEM;
> +
> +	platform_set_drvdata(pdev, priv);
> +
> +	if (!pdev->dev.platform_data) {
> +		res_index = platform_get_resource_byname(
> +					pdev, IORESOURCE_MEM, "rtc_index");
> +		if (!res_index) {
> +			err = -ENXIO;
> +			goto out_free;
> +		}
> +
> +		res_data = platform_get_resource_byname(
> +					pdev, IORESOURCE_MEM, "rtc_data");
> +		if (!res_data) {
> +			err = -ENXIO;
> +			goto out_free;
> +		}
> +
> +		if (!request_mem_region(res_index->start,
> +					resource_size(res_index),
> +					dev_name(&pdev->dev))) {
> +			err = -EBUSY;
> +			goto out_free;
> +		}
> +
> +		if (!request_mem_region(res_data->start,
> +					resource_size(res_data),
> +					dev_name(&pdev->dev))) {
> +			err = -EBUSY;
> +			goto out_release_index;
> +		}
> +
> +		priv->io_index = ioremap(res_index->start,
> +					resource_size(res_index));
> +		if (!priv->io_index) {
> +			err = -EIO;
> +			goto out_release_data;
> +		}
> +
> +		priv->io_data = ioremap(res_data->start,
> +					resource_size(res_data));
> +		if (!priv->io_data) {
> +			err = -EIO;
> +			goto out_io_index;
> +		}
> +	} else
> +		priv->ops = pdev->dev.platform_data;
> +
> +	priv->rtc = rtc_device_register("m48t86",
> +				&pdev->dev, &m48t86_rtc_ops, THIS_MODULE);
> +	if (IS_ERR(priv->rtc)) {
> +		err = PTR_ERR(priv->rtc);
> +		if (!pdev->dev.platform_data)
> +			goto out_io_data;
> +		else
> +			goto out_free;
> +	}
>  
>  	/* read battery status */
> -	reg = ops->readbyte(M48T86_REG_D);
> -	dev_info(&dev->dev, "battery %s\n",
> +	reg = m48t86_rtc_readbyte(&pdev->dev, M48T86_REG_D);
> +	dev_info(&pdev->dev, "battery %s\n",
>  		(reg & M48T86_REG_D_VRT) ? "ok" : "exhausted");
>  
>  	return 0;
> +
> +out_io_data:
> +	iounmap(priv->io_data);
> +out_io_index:
> +	iounmap(priv->io_index);
> +out_release_data:
> +	release_mem_region(res_data->start, resource_size(res_data));
> +out_release_index:
> +	release_mem_region(res_index->start, resource_size(res_index));
> +out_free:
> +	platform_set_drvdata(pdev, NULL);
> +	kfree(priv);
> +	return err;
>  }
>  
> -static int m48t86_rtc_remove(struct platform_device *dev)
> +static int m48t86_rtc_remove(struct platform_device *pdev)
>  {
> -	struct rtc_device *rtc = platform_get_drvdata(dev);
> +	struct resource *res;
> +	struct m48t86_rtc_private_data *priv = platform_get_drvdata(pdev);
> +
> +	if (priv->rtc)
> +		rtc_device_unregister(priv->rtc);
> +
> +	if (priv->io_data) {
> +		iounmap(priv->io_data);
> +		res = platform_get_resource_byname(
> +					pdev, IORESOURCE_MEM, "rtc_data");
> +		release_mem_region(res->start, resource_size(res));
> +	}
> +
> +	if (priv->io_index) {
> +		iounmap(priv->io_index);
> +		res = platform_get_resource_byname(
> +					pdev, IORESOURCE_MEM, "rtc_index");
> +		release_mem_region(res->start, resource_size(res));
> +	}
>  
> - 	if (rtc)
> -		rtc_device_unregister(rtc);
> +	platform_set_drvdata(pdev, NULL);
>  
> -	platform_set_drvdata(dev, NULL);
> +	kfree(priv);
>  
>  	return 0;
>  }
> 



From marex at denx.de  Mon Apr  1 19:37:38 2013
From: marex at denx.de (Marek Vasut)
Date: Tue, 2 Apr 2013 01:37:38 +0200
Subject: [PATCH 4/5] spi/mxs: Remove bogus setting of ssp clk rate field
In-Reply-To: <CA+7tXihhL2ETT+AgvX5KASZOOgi6bucModE88ztY9Q8U1gDbOQ@mail.gmail.com>
References: <1364570381-17605-1-git-send-email-tpiepho@gmail.com>
 <201304020116.04781.marex@denx.de>
 <CA+7tXihhL2ETT+AgvX5KASZOOgi6bucModE88ztY9Q8U1gDbOQ@mail.gmail.com>
Message-ID: <201304020137.39154.marex@denx.de>

Dear Trent Piepho,

> On Mon, Apr 1, 2013 at 4:16 PM, Marek Vasut <marex at denx.de> wrote:
> >> The ssp struct has a clock rate field, to provide the actual value, in
> >> Hz, of the SSP output clock (the rate of SSP_SCK) after
> >> mxs_ssp_set_clk_rate() is called.  It should be read-only, except for
> >> mxs_ssp_set_clk_rate().
> >> 
> >> For some reason the spi-mxs driver decides to write to this field on
> >> init, and sets it to the value of the SSP input clock (clk_sspN, from
> >> the MXS clocking block) in kHz.  It shouldn't be setting the value, and
> >> certainly shouldn't be setting it with the wrong clock in the wrong
> >> units.
> > 
> > I suspect this patch should also fix drivers/clk/mxs/clk-ssp.c then?
> 
> Why do you say that?  I see no problem with clk-ssp.c, as setting the
> clk_rate field in the ssp struct to the actual programmed rate makes
> sense.  The code in spi-mxs.c just makes no sense.  I suspect it was
> added by mistake when porting the driver.

Either remove it altogether if it's unused OR make sure it's inited to some sane 
value from the start.

Best regards,
Marek Vasut


From tpiepho at gmail.com  Mon Apr  1 19:40:37 2013
From: tpiepho at gmail.com (Trent Piepho)
Date: Mon, 1 Apr 2013 16:40:37 -0700
Subject: [PATCH 2/5] spi/mxs: Fix chip select control bits in DMA mode
In-Reply-To: <201304020130.51951.marex@denx.de>
References: <1364570381-17605-1-git-send-email-tpiepho@gmail.com>
 <201304020113.42124.marex@denx.de>
 <CA+7tXih2wAVeLpVoYkt4Tmo3h0YtLoZY3vCcv5s8sUD1u8_BVQ@mail.gmail.com>
 <201304020130.51951.marex@denx.de>
Message-ID: <CA+7tXij_V1iAdPuPoTQ6CK6U5Y-iJprCPsTj=_LHAV1-=CL7gA@mail.gmail.com>

On Mon, Apr 1, 2013 at 4:30 PM, Marek Vasut <marex at denx.de> wrote:

>> >> -static uint32_t mxs_spi_cs_to_reg(unsigned cs)
>> >> +static u32 mxs_spi_cs_to_reg(unsigned cs)
>> >>
>> >>  {
>> >>
>> >> -     uint32_t select = 0;
>> >> +     u32 select = 0;
>>
>> I'll make it a separate patch.
>
> This is completely irrelevant change, please just submit the relevant patches.

Kernel code should use u16, u32, etc. instead of the uint16_t,
uint32_t types.  The rest of the driver uses them.  Why should this
one function use a different type than the rest?  It's ugly and
inconsistent.

And really, it's just as relevant as insisting that multiline patches
use some exact format, which checkpatch.pl doesn't complain about.


From alex at digriz.org.uk  Mon Apr  1 19:42:07 2013
From: alex at digriz.org.uk (Alexander Clouter)
Date: Tue, 2 Apr 2013 00:42:07 +0100
Subject: [PATCH 2/6] rtc: rtc-m48t86: add hooks to support driver side
 memory mapping
In-Reply-To: <515A1A0B.8040803@gmail.com>
References: <1364858565-17192-1-git-send-email-alex@digriz.org.uk>
 <1364858565-17192-3-git-send-email-alex@digriz.org.uk>
 <515A1A0B.8040803@gmail.com>
Message-ID: <20130401234207.GL1953@edkhil>

On Tue, Apr 02, 2013 at 10:36:43AM +1100, Ryan Mallon wrote:
>On 02/04/13 10:22, Alexander Clouter wrote:
>> If platform_data is not defined (as before), then named memory io
>> ranges need to be defined ("rtc_index" and "rtc_data").  The driver
>> then maps those regions and uses them as the RTC index and data
>> addresses.
>>
>> Does compile with the following warnings, I cannot see the codepath
>> affected myself:
>> ----
>> drivers/rtc/rtc-m48t86.c: In function ?m48t86_rtc_probe?:
>> drivers/rtc/rtc-m48t86.c:180: warning: ?res_index? may be used uninitialized in this function
>> drivers/rtc/rtc-m48t86.c:180: warning: ?res_data? may be used uninitialized in this function
>
>It is caused by the exit paths. If pdev->dev.platform_data is set, the
>res_index and res_data are never initialised, but in the error case you
>still for rtc_device_register you jump to out_io_data, which will then
>dereference res_index/res_data. You need to make the exit paths
>conditional on pdev->dev.platform_data (or init res_index/data to NULL
>and make the release_mem_regions conditional on that).

However, the 'goto out_io_data' in the 'IS_ERR(priv->rtc)' is wrapped in a 'if 
(!pdev->dev.platform_data)', else we jump to out_free.

I suspect I am probably missing something *too* obvious here for it to click?

Cheers

>> +	priv->rtc = rtc_device_register("m48t86",
>> +				&pdev->dev, &m48t86_rtc_ops, THIS_MODULE);
>> +	if (IS_ERR(priv->rtc)) {                <--------------
>> +		err = PTR_ERR(priv->rtc);
>> +		if (!pdev->dev.platform_data)   <--------------
>> +			goto out_io_data;
>> +		else
>> +			goto out_free;
>> +	}
>>
>>  	/* read battery status */
>> -	reg = ops->readbyte(M48T86_REG_D);
>> -	dev_info(&dev->dev, "battery %s\n",
>> +	reg = m48t86_rtc_readbyte(&pdev->dev, M48T86_REG_D);
>> +	dev_info(&pdev->dev, "battery %s\n",
>>  		(reg & M48T86_REG_D_VRT) ? "ok" : "exhausted");
>>
>>  	return 0;
>> +
>> +out_io_data:
>> +	iounmap(priv->io_data);
>> +out_io_index:
>> +	iounmap(priv->io_index);
>> +out_release_data:
>> +	release_mem_region(res_data->start, resource_size(res_data));
>> +out_release_index:
>> +	release_mem_region(res_index->start, resource_size(res_index));
>> +out_free:
>> +	platform_set_drvdata(pdev, NULL);
>> +	kfree(priv);
>> +	return err;
>>  }

-- 
Alexander Clouter
.sigmonster says: Zeus gave Leda the bird.


From marex at denx.de  Mon Apr  1 20:02:43 2013
From: marex at denx.de (Marek Vasut)
Date: Tue, 2 Apr 2013 02:02:43 +0200
Subject: [PATCH 2/5] spi/mxs: Fix chip select control bits in DMA mode
In-Reply-To: <CA+7tXij_V1iAdPuPoTQ6CK6U5Y-iJprCPsTj=_LHAV1-=CL7gA@mail.gmail.com>
References: <1364570381-17605-1-git-send-email-tpiepho@gmail.com>
 <201304020130.51951.marex@denx.de>
 <CA+7tXij_V1iAdPuPoTQ6CK6U5Y-iJprCPsTj=_LHAV1-=CL7gA@mail.gmail.com>
Message-ID: <201304020202.43501.marex@denx.de>

Dear Trent Piepho,

> On Mon, Apr 1, 2013 at 4:30 PM, Marek Vasut <marex at denx.de> wrote:
> >> >> -static uint32_t mxs_spi_cs_to_reg(unsigned cs)
> >> >> +static u32 mxs_spi_cs_to_reg(unsigned cs)
> >> >> 
> >> >>  {
> >> >> 
> >> >> -     uint32_t select = 0;
> >> >> +     u32 select = 0;
> >> 
> >> I'll make it a separate patch.
> > 
> > This is completely irrelevant change, please just submit the relevant
> > patches.
> 
> Kernel code should use u16, u32, etc. instead of the uint16_t,
> uint32_t types.  The rest of the driver uses them.  Why should this
> one function use a different type than the rest?  It's ugly and
> inconsistent.

Is this documented somewhere please? I see only a mention about this in chapter 
5 of Documentation/CodingStyle , section (d) . Either way, separate such 
cosmetic change into another series so they're not in the way of relevant stuff.

> And really, it's just as relevant as insisting that multiline patches
> use some exact format, which checkpatch.pl doesn't complain about.

The checkpatch is not almighty tool, Documentation/CodingStyle describes how 
code should be written/annotated/documented.

Best regards,
Marek Vasut


From tpiepho at gmail.com  Mon Apr  1 20:07:42 2013
From: tpiepho at gmail.com (Trent Piepho)
Date: Mon, 1 Apr 2013 17:07:42 -0700
Subject: [PATCH 4/5] spi/mxs: Remove bogus setting of ssp clk rate field
In-Reply-To: <201304020137.39154.marex@denx.de>
References: <1364570381-17605-1-git-send-email-tpiepho@gmail.com>
 <201304020116.04781.marex@denx.de>
 <CA+7tXihhL2ETT+AgvX5KASZOOgi6bucModE88ztY9Q8U1gDbOQ@mail.gmail.com>
 <201304020137.39154.marex@denx.de>
Message-ID: <CA+7tXihfDnmkTJGzk_yvRKYwb5mJzzLJVV+XupCEGnmpQdKDLQ@mail.gmail.com>

On Mon, Apr 1, 2013 at 4:37 PM, Marek Vasut <marex at denx.de> wrote:
>> On Mon, Apr 1, 2013 at 4:16 PM, Marek Vasut <marex at denx.de> wrote:
>> >> The ssp struct has a clock rate field, to provide the actual value, in
>> >> Hz, of the SSP output clock (the rate of SSP_SCK) after
>> >> mxs_ssp_set_clk_rate() is called.  It should be read-only, except for
>> >> mxs_ssp_set_clk_rate().
>> >>
>> >> For some reason the spi-mxs driver decides to write to this field on
>> >> init, and sets it to the value of the SSP input clock (clk_sspN, from
>> >> the MXS clocking block) in kHz.  It shouldn't be setting the value, and
>> >> certainly shouldn't be setting it with the wrong clock in the wrong
>> >> units.
>> >
>> > I suspect this patch should also fix drivers/clk/mxs/clk-ssp.c then?
>>
>> Why do you say that?  I see no problem with clk-ssp.c, as setting the
>> clk_rate field in the ssp struct to the actual programmed rate makes
>> sense.  The code in spi-mxs.c just makes no sense.  I suspect it was
>> added by mistake when porting the driver.
>
> Either remove it altogether if it's unused OR make sure it's inited to some sane
> value from the start.

This field doesn't need to be initted by a user of the common SSP
clock code, as it is not an input to that code.  It is set by the SSP
clock code.  After the SSP clock is programmed, it can be read to find
the true SSP rate.  There is no need for any user of the SSP code to
set the clk_rate field, and other than this one incorrect line, no
user does so.  It's not used currently in the SPI driver at all, but
it certainly could be.  The SSP code is shared with the MMC driver
that can drive an SSP port in SD/MMC mode.  The mxs-mmc code does need
the actual SSP clock and does use the field.  That code does not write
to ssp->clk_rate, because as I have said, it is in output from the SSP
clock code.

Since the ssp struct is part of the spi master device data, it would
be initialized to zero when allocated by spi_master_alloc().  The SPI
clock isn't part of the spi master, but of a spi slave and a spi
transfer.  Thus there is no sensible value to initialize the spi clock
to at the time the spi master is created.  Which is fine.  The code
doesn't try to and other spi drivers don't either.  At the time a spi
slave is created the spi clock could be programmed.  But that would
introduce a race.  The proper thing to do, and what the driver does,
is to program the spi clock with the requested clock for a spi
transfer.


From kuninori.morimoto.gx at renesas.com  Mon Apr  1 20:11:34 2013
From: kuninori.morimoto.gx at renesas.com (Kuninori Morimoto)
Date: Mon, 01 Apr 2013 17:11:34 -0700 (PDT)
Subject: [PATCH 2/3 v2] ARM: shmobile: r8a7778: add
 r8a7778_init_irq_extpin()
In-Reply-To: <51598121.9010005@cogentembedded.com>
References: <87zjxvewko.wl%kuninori.morimoto.gx@renesas.com>
 <87fvzb56n3.wl%kuninori.morimoto.gx@renesas.com>
 <87d2uf56kt.wl%kuninori.morimoto.gx@renesas.com>
 <51598121.9010005@cogentembedded.com>
Message-ID: <871uat7pw1.wl%kuninori.morimoto.gx@renesas.com>


Hi Sergei

> > +static struct resource irqpin_resources[] = {
> > +	DEFINE_RES_MEM(0xfe78001c, 4), /* ICR1 */
> > +	DEFINE_RES_MEM(0xfe780010, 4), /* INTPRI */
> > +	DEFINE_RES_MEM(0xfe780024, 4), /* INTREQ */
> > +	DEFINE_RES_MEM(0xfe780044, 4), /* INTMSK0 */
> > +	DEFINE_RES_MEM(0xfe780064, 4), /* INTMSKCLR0 */
> 
>     Hm, why this can't be passed as a single large memory resource?

see
${LINUX}/drivers/irqchip/irq-renesas-intc-irqpin.c :: intc_irqpin_probe()


Best regards
---
Kuninori Morimoto


From kuninori.morimoto.gx at renesas.com  Mon Apr  1 20:13:10 2013
From: kuninori.morimoto.gx at renesas.com (Kuninori Morimoto)
Date: Mon, 01 Apr 2013 17:13:10 -0700 (PDT)
Subject: [PATCH 3/3 v2] ARM: shmobile: bockw: add SMSC ethernet support
In-Reply-To: <515982A8.3090307@cogentembedded.com>
References: <87zjxvewko.wl%kuninori.morimoto.gx@renesas.com>
 <87fvzb56n3.wl%kuninori.morimoto.gx@renesas.com>
 <87bo9z56k8.wl%kuninori.morimoto.gx@renesas.com>
 <515982A8.3090307@cogentembedded.com>
Message-ID: <87zjxh6b8t.wl%kuninori.morimoto.gx@renesas.com>


Hi Sergei, Simon

> >   	chosen {
> > -		bootargs = "console=ttySC0,115200 ignore_loglevel";
> > +		bootargs = "console=ttySC0,115200 ignore_loglevel ip=dhcp root=/dev/nfs";
> >   	};
> >
> >   	memory {
> 
>     In my opinion, modifying .dts file should be done in a separate patch.
(snip)
> >   # CONFIG_SCHED_DEBUG is not set
> >   # CONFIG_DEBUG_BUGVERBOSE is not set
> >   # CONFIG_FTRACE is not set
> >   # CONFIG_ARM_UNWIND is not set
> > -CONFIG_KEYS=y
> > -CONFIG_CRYPTO=y
> >   CONFIG_AVERAGE=y
> 
>     In my opinion, modifying bockw_defconfig should be done in a separate 
> patch. Mixing everything up in a signle patch is a bad practice.

It depends on LTSI backport / upstreaming I believe.
I need Simon's opinion

Best regards
---
Kuninori Morimoto


From kuninori.morimoto.gx at renesas.com  Mon Apr  1 20:17:38 2013
From: kuninori.morimoto.gx at renesas.com (Kuninori Morimoto)
Date: Mon, 01 Apr 2013 17:17:38 -0700 (PDT)
Subject: [PATCH 1/2] ARM: shmobile: R8A7779: add Ether support
In-Reply-To: <201304020204.54546.sergei.shtylyov@cogentembedded.com>
References: <201304020204.54546.sergei.shtylyov@cogentembedded.com>
Message-ID: <87y5d16b1d.wl%kuninori.morimoto.gx@renesas.com>


Hi Sergei

> +void __init r8a7779_add_ether_device(void *pdata)
> +{
> +	ether_device.dev.platform_data = pdata;
> +
> +	platform_device_register(&ether_device);
> +}

Current ARM SoC is trying to not use platform_device_register()
Please use platform_device_register_xxx()
Same comment for [2/2]

Best regards
---
Kuninori Morimoto


From collinsd at codeaurora.org  Mon Apr  1 20:24:19 2013
From: collinsd at codeaurora.org (David Collins)
Date: Mon, 01 Apr 2013 17:24:19 -0700
Subject: How to represent negative values for device tree property
In-Reply-To: <515A038F.2090902@wwwdotorg.org>
References: <5159F760.1080605@codeaurora.org> <515A038F.2090902@wwwdotorg.org>
Message-ID: <515A2533.8050005@codeaurora.org>

On 04/01/2013 03:00 PM, Stephen Warren wrote:
> On 04/01/2013 03:08 PM, David Collins wrote:
>> Hi,
>>
>> I am working on a thermal driver which needs to be able to read a
>> temperature threshold from a device tree property.  The hardware supports
>> thresholds in the range -204.8 to +204.7 C in 0.1 C steps.  I have found,
>> as I am sure others have as well, that dtc treats a '-' before an integer
>> in a dtsi file as a syntax error.  Therefore, I need some artificial way
>> to represent negative numbers in device tree.  Here are the possibilities
>> that I have thought of so far:
> 
> Doesn't the very latest dtc, which contains integer expression support,
> allow unary -? I thought that code had been imported into the kernel
> (goes and checks) yes it has. What's the error you're seeing;
> over/underflow or syntax?
> 
> That said, DT cells are supposed to be u32 not s32, so perhaps this
> isn't unexpected.

It is likely that my dtc version is out of date.  dtc -v outputs 1.2.0.  I
will try updating to a newer version of dtc.  The error that I currently
get is a syntax error: "FATAL ERROR: Unable to parse input tree".

Does the device tree binary documentation define any format for negative
numbers?  Unsigned 32-bit integers are clearly defined as bytes in
big-endian order.  I suppose that you could assume 32-bit signed integers
are 2's complement with bytes in big-endian order, but that would need to
be well defined somewhere.

Assuming that dtb has no well defined means of holding a negative integer
value, then what is the most elegant workaround to specify a negative value?

-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation


From kuninori.morimoto.gx at renesas.com  Mon Apr  1 20:27:13 2013
From: kuninori.morimoto.gx at renesas.com (Kuninori Morimoto)
Date: Mon, 01 Apr 2013 17:27:13 -0700 (PDT)
Subject: [PATCH 1/2] ARM: shmobile: R8A7779: add Ether support
In-Reply-To: <201304020204.54546.sergei.shtylyov@cogentembedded.com>
References: <201304020204.54546.sergei.shtylyov@cogentembedded.com>
Message-ID: <87wqsl6ale.wl%kuninori.morimoto.gx@renesas.com>


Hi Sergei again

> +void __init r8a7779_add_ether_device(void *pdata)
> +{
> +	ether_device.dev.platform_data = pdata;
> +
> +	platform_device_register(&ether_device);
> +}

We didn't use this style of registration before,
but, it is OK.
Then, this (void *pdata) should be
(struct sh_eth_plat_data *pdata) IMO

Best regards
---
Kuninori Morimoto


From marex at denx.de  Mon Apr  1 20:29:31 2013
From: marex at denx.de (Marek Vasut)
Date: Tue, 2 Apr 2013 02:29:31 +0200
Subject: [PATCH 4/5] spi/mxs: Remove bogus setting of ssp clk rate field
In-Reply-To: <CA+7tXihfDnmkTJGzk_yvRKYwb5mJzzLJVV+XupCEGnmpQdKDLQ@mail.gmail.com>
References: <1364570381-17605-1-git-send-email-tpiepho@gmail.com>
 <201304020137.39154.marex@denx.de>
 <CA+7tXihfDnmkTJGzk_yvRKYwb5mJzzLJVV+XupCEGnmpQdKDLQ@mail.gmail.com>
Message-ID: <201304020229.32078.marex@denx.de>

Dear Trent Piepho,

> On Mon, Apr 1, 2013 at 4:37 PM, Marek Vasut <marex at denx.de> wrote:
> >> On Mon, Apr 1, 2013 at 4:16 PM, Marek Vasut <marex at denx.de> wrote:
> >> >> The ssp struct has a clock rate field, to provide the actual value,
> >> >> in Hz, of the SSP output clock (the rate of SSP_SCK) after
> >> >> mxs_ssp_set_clk_rate() is called.  It should be read-only, except for
> >> >> mxs_ssp_set_clk_rate().
> >> >> 
> >> >> For some reason the spi-mxs driver decides to write to this field on
> >> >> init, and sets it to the value of the SSP input clock (clk_sspN, from
> >> >> the MXS clocking block) in kHz.  It shouldn't be setting the value,
> >> >> and certainly shouldn't be setting it with the wrong clock in the
> >> >> wrong units.
> >> > 
> >> > I suspect this patch should also fix drivers/clk/mxs/clk-ssp.c then?
> >> 
> >> Why do you say that?  I see no problem with clk-ssp.c, as setting the
> >> clk_rate field in the ssp struct to the actual programmed rate makes
> >> sense.  The code in spi-mxs.c just makes no sense.  I suspect it was
> >> added by mistake when porting the driver.
> > 
> > Either remove it altogether if it's unused OR make sure it's inited to
> > some sane value from the start.
> 
> This field doesn't need to be initted by a user of the common SSP
> clock code, as it is not an input to that code.  It is set by the SSP
> clock code.  After the SSP clock is programmed, it can be read to find
> the true SSP rate.  There is no need for any user of the SSP code to
> set the clk_rate field, and other than this one incorrect line, no
> user does so.  It's not used currently in the SPI driver at all, but
> it certainly could be.  The SSP code is shared with the MMC driver
> that can drive an SSP port in SD/MMC mode.  The mxs-mmc code does need
> the actual SSP clock and does use the field.  That code does not write
> to ssp->clk_rate, because as I have said, it is in output from the SSP
> clock code.

If the clk_rate is at least inited to zero, then this patch does makes sense.

[...]

Best regards,
Marek Vasut


From bhutchings at solarflare.com  Mon Apr  1 20:40:43 2013
From: bhutchings at solarflare.com (Ben Hutchings)
Date: Tue, 2 Apr 2013 01:40:43 +0100
Subject: [PATCH] Fix IXP4xx coherent allocations
In-Reply-To: <m3d2uexaxw.fsf@intrepid.localdomain>
References: <m3obe9lxil.fsf@intrepid.localdomain>
 <20130323.195740.2108147521543354261.davem@davemloft.net>
 <1364152267.3620.31.camel@deadeye.wl.decadent.org.uk>
 <m3r4j4sdmv.fsf@intrepid.localdomain>
 <20130330132915.GB17995@n2100.arm.linux.org.uk>
 <m3d2uhdl1l.fsf@intrepid.localdomain>
 <20130330153135.GC17995@n2100.arm.linux.org.uk>
 <m3d2uexaxw.fsf@intrepid.localdomain>
Message-ID: <1364863243.3557.136.camel@deadeye.wl.decadent.org.uk>

On Mon, 2013-04-01 at 22:17 +0200, Krzysztof Halasa wrote:
> Russell King - ARM Linux <linux at arm.linux.org.uk> writes:
> 
> > Right, so, the answer is - yes you are talking about platform devices,
> > and the reason that these aren't already set is because if you grep for
> > ixp4xx_eth or ixp4xx_hss in arch/arm/mach-ixp4xx, you'll notice that
> > _none_ of the device declarations set either of the DMA masks at all.
> > They don't even set the dev->dma_mask pointer.  That is why the masks
> > are zero.  For a device which does DMA, that is wrong.
> 
> Well, that's new to me. Please tell me how it should be done.
> Should I simply add in platform code (on all platforms):
> 
> +++ b/arch/arm/mach-ixp4xx/XXX.c
> @@ -380,10 +380,12 @@ static struct platform_device device_eth_tab[] = {
>          .name           = "ixp4xx_eth",
>          .id         = IXP4XX_ETH_NPEB,
>          .dev.platform_data  = eth_plat,
> +        .dev.coherent_dma_mask  = DMA_BIT_MASK(32),
>      }, {
>          .name           = "ixp4xx_eth",
>          .id         = IXP4XX_ETH_NPEC,
>          .dev.platform_data  = eth_plat + 1,
> +        .dev.coherent_dma_mask  = DMA_BIT_MASK(32),
>      }
>  };
> 
> This alone isn't going to work, the problem is coherent DMA mask in
> net_dev->dev and not in platform_device. So what do I do in the network
> drivers? Copy the masks from platform_device to the actual newly created
> net_dev->dev?
>
> Should I use the parent device (net_dev->dev.parent which is the
> platform_device) as the argument to the allocator? This would probably
> work though I'm not sure of its correctness.
[...]

Passing the parent device to DMA API functions seems to be the right
thing to do.  It's what you would do in a PCI device driver.

Ben.

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.



From mturquette at linaro.org  Mon Apr  1 21:12:36 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Mon, 01 Apr 2013 18:12:36 -0700
Subject: [PATCH] clk: add LP8788 clock driver
In-Reply-To: <A874F61F95741C4A9BA573A70FE3998F82E48E3F@DQHE02.ent.ti.com>
References: <A874F61F95741C4A9BA573A70FE3998F82E48E3F@DQHE02.ent.ti.com>
Message-ID: <20130402011236.8177.88731@quantum>

Quoting Kim, Milo (2013-03-20 17:37:14)
> LP8788 PMU consists of regulator, battery charger, RTC, ADC, backlight driver
> and current sinks.
> Here is additional driver, clock.
> 
> * Clock source
> LP8788 clock is generated by two clock source.
> One is internal oscillator. The other is attached external crystal oscillator.
> LP8788 provides automatic clock source selection through the I2C register.
> This operation is executed in 'prepare' of common clock driver architecture.
> 
> * Clock rate
> LP8788 generates a fixed 32768Hz clock which is used for the system.
> 
> * Supported operation
> .prepare: Before the clock is enabled, automatic clock source selection is done
>           by register access.
> .unprepare: No register for disable or remove the clock source, so do nothing.
> .is_enabled
> .recalc_rate: Fixed clock rate, 32.768KHz.
> 
> * clk_register_fixed_rate() vs devm_clk_register() and clkdev_add()
> Fixed clock driver can be created by common clock helper function but
> but LP8788 should be built as a module.
> Using devm_clk_register() and clkdev_add() is more appropriate method to
> implement LP8788 clock driver.
> 
> Signed-off-by: Milo(Woogyom) Kim <milo.kim at ti.com>
> ---
>  drivers/clk/Kconfig        |    7 ++
>  drivers/clk/Makefile       |    1 +
>  drivers/clk/clk-lp8788.c   |  186 ++++++++++++++++++++++++++++++++++++++++++++
>  drivers/mfd/lp8788.c       |    2 +
>  include/linux/mfd/lp8788.h |    1 +
>  5 files changed, 197 insertions(+)
>  create mode 100644 drivers/clk/clk-lp8788.c
> 
> diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
> index a64caef..4b5109c 100644
> --- a/drivers/clk/Kconfig
> +++ b/drivers/clk/Kconfig
> @@ -71,6 +71,13 @@ config COMMON_CLK_AXI_CLKGEN
>           Support for the Analog Devices axi-clkgen pcore clock generator for Xilinx
>           FPGAs. It is commonly used in Analog Devices' reference designs.
>  
> +config CLK_LP8788
> +       tristate "Clock driver for TI LP8788 PMU"
> +       depends on MFD_LP8788
> +       ---help---
> +         Supports the clock subsystem of TI LP8788. It generates the 32KHz
> +         clock output.
> +
>  endmenu
>  
>  source "drivers/clk/mvebu/Kconfig"
> diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
> index 1c22f9d..06d0763 100644
> --- a/drivers/clk/Makefile
> +++ b/drivers/clk/Makefile
> @@ -35,3 +35,4 @@ obj-$(CONFIG_COMMON_CLK_AXI_CLKGEN) += clk-axi-clkgen.o
>  obj-$(CONFIG_COMMON_CLK_WM831X) += clk-wm831x.o
>  obj-$(CONFIG_COMMON_CLK_MAX77686) += clk-max77686.o
>  obj-$(CONFIG_CLK_TWL6040)      += clk-twl6040.o
> +obj-$(CONFIG_CLK_LP8788)       += clk-lp8788.o
> diff --git a/drivers/clk/clk-lp8788.c b/drivers/clk/clk-lp8788.c
> new file mode 100644
> index 0000000..de56887
> --- /dev/null
> +++ b/drivers/clk/clk-lp8788.c
> @@ -0,0 +1,186 @@
> +/*
> + * TI LP8788 Clock Driver
> + *
> + * Copyright 2013 Texas Instruments
> + *
> + * Author: Milo(Woogyom) Kim <milo.kim at 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/clk.h>
> +#include <linux/clkdev.h>
> +#include <linux/clk-provider.h>
> +#include <linux/mfd/lp8788.h>
> +#include <linux/module.h>
> +#include <linux/slab.h>
> +#include <linux/platform_device.h>
> +
> +/* Registers */
> +#define LP8788_REG_STATUS              0x06
> +#define LP8788_OSC_WORKING             0x10
> +
> +#define LP8788_REG_CLKCTRL             0xA2
> +#define LP8788_CLKMODE_MASK            0x02
> +#define LP8788_CLKMODE_AUTO            0X02
> +
> +#define CLKOUT_32KHZ           32768
> +
> +struct lp8788_clk {
> +       struct lp8788 *lp;
> +       struct clk *clk;
> +       struct clk_hw hw;
> +       struct clk_lookup *lookup;
> +       bool enabled;
> +};
> +
> +static struct lp8788_clk *to_lp8788_clk(struct clk_hw *hw)
> +{
> +       return container_of(hw, struct lp8788_clk, hw);
> +}

Hi Milo,

Just FYI most folks are simply using a macro to do the above.  E.g:

#define to_lp8788_clk(_hw) container_of(_hw, struct lp8788_clk, hw)

> +
> +static int lp8788_clk_prepare(struct clk_hw *hw)
> +{
> +       struct lp8788_clk *pclk = to_lp8788_clk(hw);
> +
> +       /* Automatic oscillator source selection */
> +       return lp8788_update_bits(pclk->lp, LP8788_REG_CLKCTRL,
> +                               LP8788_CLKMODE_MASK, LP8788_CLKMODE_AUTO);
> +}
> +
> +static void lp8788_clk_unprepare(struct clk_hw *hw)
> +{
> +       /* Do nothing */
> +       return;
> +}
> +
> +static int lp8788_clk_is_enabled(struct clk_hw *hw)
> +{
> +       struct lp8788_clk *pclk = to_lp8788_clk(hw);
> +
> +       /*
> +        * Do not use the LP8788 register access here, unsafe locking problem
> +        * may occur during loading the driver. So stored varible is prefered.
> +        */

What unsafe locking problem?

Also have you looked into using the new .is_prepare callback?  See:
https://git.linaro.org/gitweb?p=people/mturquette/linux.git;a=commitdiff;h=3d6ee287a3e341c88eafd0b4620b12d640b3736b;hp=30ee400614385ac49f4c9b4bc03d77ff8f07a61e

> +
> +       return pclk->enabled;

Why provide a .is_enabled callback when there are no .enable or .disable
callbacks?

Regards,
Mike


From horms at verge.net.au  Mon Apr  1 21:13:30 2013
From: horms at verge.net.au (Simon Horman)
Date: Tue, 2 Apr 2013 10:13:30 +0900
Subject: [PATCH] ARM: shmobile: r8a73a4 SoC 64-bit DT support
In-Reply-To: <20130329074556.15428.88694.sendpatchset@w520>
References: <20130329074556.15428.88694.sendpatchset@w520>
Message-ID: <20130402011329.GA19813@verge.net.au>

On Fri, Mar 29, 2013 at 04:45:56PM +0900, Magnus Damm wrote:
> From: Takashi Yoshii <takashi.yoshii.zj at renesas.com>
> 
> The r8a73a4 SoC supports LPAE and has memory window up to
> 0x2ffffffff. Convert to 64-bit addresses by enlarging
> #addr-cells and #size-cells to 2.
> 
> Signed-off-by: Takashi Yoshii <takashi.yoshii.zj at renesas.com>
> Signed-off-by: Magnus Damm <damm at opensource.se>

Thanks, queued up for v3.10 in the soc branch.

> ---
> 
>  Depends on the following series:
>  [PATCH 00/04] ARM: shmobile: r8a73a4 SoC support V3
> 
>  arch/arm/boot/dts/r8a73a4.dtsi |   20 ++++++++++----------
>  1 file changed, 10 insertions(+), 10 deletions(-)
> 
> --- 0001/arch/arm/boot/dts/r8a73a4.dtsi
> +++ work/arch/arm/boot/dts/r8a73a4.dtsi	2013-03-29 16:02:06.000000000 +0900
> @@ -9,11 +9,11 @@
>   * kind, whether express or implied.
>   */
>  
> -/include/ "skeleton.dtsi"
> -
>  / {
>  	compatible = "renesas,r8a73a4";
>  	interrupt-parent = <&gic>;
> +	#address-cells = <2>;
> +	#size-cells = <2>;
>  
>  	cpus {
>  		#address-cells = <1>;
> @@ -32,10 +32,10 @@
>  		#interrupt-cells = <3>;
>  		#address-cells = <0>;
>  		interrupt-controller;
> -		reg = <0xf1001000 0x1000>,
> -			<0xf1002000 0x1000>,
> -			<0xf1004000 0x2000>,
> -			<0xf1006000 0x2000>;
> +		reg = <0 0xf1001000 0 0x1000>,
> +			<0 0xf1002000 0 0x1000>,
> +			<0 0xf1004000 0 0x2000>,
> +			<0 0xf1006000 0 0x2000>;
>  		interrupts = <1 9 0xf04>;
>  
>  		gic-cpuif at 4 {
> @@ -57,7 +57,7 @@
>  		compatible = "renesas,irqc";
>  		#interrupt-cells = <2>;
>  		interrupt-controller;
> -		reg = <0xe61c0000 0x200>;
> +		reg = <0 0xe61c0000 0 0x200>;
>  		interrupt-parent = <&gic>;
>  		interrupts = <0 0 4>, <0 1 4>, <0 2 4>,	<0 3 4>,
>  				<0 4 4>, <0 5 4>, <0 6 4>, <0 7 4>,
> @@ -73,7 +73,7 @@
>  		compatible = "renesas,irqc";
>  		#interrupt-cells = <2>;
>  		interrupt-controller;
> -		reg = <0xe61c0200 0x200>;
> +		reg = <0 0xe61c0200 0 0x200>;
>  		interrupt-parent = <&gic>;
>  		interrupts = <0 32 4>, <0 33 4>, <0 34 4>, <0 35 4>,
>  				<0 36 4>, <0 37 4>, <0 38 4>, <0 39 4>,
> @@ -86,8 +86,8 @@
>  
>  	thermal at e61f0000 {
>  		compatible = "renesas,rcar-thermal";
> -		reg = <0xe61f0000 0x14>, <0xe61f0100 0x38>,
> -			 <0xe61f0200 0x38>, <0xe61f0300 0x38>;
> +		reg = <0 0xe61f0000 0 0x14>, <0 0xe61f0100 0 0x38>,
> +			 <0 0xe61f0200 0 0x38>, <0 0xe61f0300 0 0x38>;
>  		interrupt-parent = <&gic>;
>  		interrupts = <0 69 4>;
>  	};
> 


From horms at verge.net.au  Mon Apr  1 21:13:34 2013
From: horms at verge.net.au (Simon Horman)
Date: Tue, 2 Apr 2013 10:13:34 +0900
Subject: [PATCH 00/03 v4] ARM: shmobile: r8a73a4 APE6EVM board support
In-Reply-To: <20130329075952.15748.6290.sendpatchset@w520>
References: <20130329075952.15748.6290.sendpatchset@w520>
Message-ID: <20130402011333.GB19813@verge.net.au>

On Fri, Mar 29, 2013 at 04:59:52PM +0900, Magnus Damm wrote:
> ARM: shmobile: r8a73a4 APE6EVM board support (V4)
> 
> [PATCH 01/03 v3] ARM: shmobile: APE6EVM base support
> [PATCH 02/03 v2] ARM: shmobile: APE6EVM PFC support
> [PATCH 03/03 v3] ARM: shmobile: APE6EVM LAN9220 support
> 
> This series is V4 of initial support for the APE6EVM board.
> 
> The APE6EVM board makes use of the r8a73a4 SoC and has a
> couple of different I/O devices on board, but with this
> series only support for the SCIFA0 UART and the Ethernet
> chip is included.
> 
> In the future support for more I/O devices will be added as
> incremental feature patches.

Thanks, queued up for v3.10 in the boards branch.


From tpiepho at gmail.com  Mon Apr  1 21:24:41 2013
From: tpiepho at gmail.com (Trent Piepho)
Date: Mon, 1 Apr 2013 18:24:41 -0700
Subject: [PATCH 1/5] spi/mxs: Fix extra CS pulses and read mode in
 multi-transfer messages
In-Reply-To: <201304020111.13969.marex@denx.de>
References: <1364570381-17605-1-git-send-email-tpiepho@gmail.com>
 <201304020111.13969.marex@denx.de>
Message-ID: <CA+7tXigx=qcDDJZGAx7JEX+Y-CDG-B0xyYgs6fHbUZofH7gnKw@mail.gmail.com>

On Mon, Apr 1, 2013 at 4:11 PM, Marek Vasut <marex at denx.de> wrote:
>> +#define TXRX_WRITE           1       /* This is a write */
>> +#define TXRX_DEASSERT_CS     2       /* De-assert CS at end of txrx */
>
> New flags? I'm sure the GCC can optimize function parameters pretty well, esp.
> if you make the bool.

Nope.  I checked the actual compiled code.  Each bool takes another
parameter.  Since the txrx functions are large and called from
multiple sites, they are not inlined.  Gcc is not able to combine all
the bool arguments into one single bitfield argument.

On arm, to check if an argument on the stack is true requires two
instructions.  First an ldr to move the argument into a register and
then a cmp to check it for zero.  Checking for a bit is the basically
the same, first an ldr and then a tst.  So there is no performance
advantage of "if(x)" vs "if(x&32)".  But, if one uses bit flags then
the same flag word can be used for every flag, avoiding the need to
load a different word for each flag.

So using the flags avoids extra instructions in the caller for each
call to place each flag in its own boolean on the stack or in an
argument register (depending on the # of function arguments), and then
avoids extra code in the callee to load any arguments on the stack
into a register.  It can make code in loops faster and smaller by
using fewer register and avoiding a register load inside the loop.

BTW, after converting the code to bool arguments instead of flags:
add/remove: 0/0 grow/shrink: 4/0 up/down: 130/0 (130)
function                                     old     new   delta
mxs_spi_transfer_one                         808     900     +92
mxs_spi_txrx_pio                             492     508     +16
mxs_spi_txrx_dma                            1188    1204     +16
__UNIQUE_ID_vermagic0                         73      79      +6

Bool arguments for each flag is larger than using one argument and bit
flags.  And there are more flags needed to support things like GPIO CS
lines.

>>       ctrl0 = readl(ssp->base + HW_SSP_CTRL0);
>> -     ctrl0 &= ~BM_SSP_CTRL0_XFER_COUNT;
>> +     ctrl0 &= ~BM_SSP_CTRL0_XFER_COUNT & ~BM_SSP_CTRL0_IGNORE_CRC &
>> +              ~BM_SSP_CTRL0_READ;
>
> Well ... ctrl0 &= ~(FOO | BAR | BAZ); ... won't cut it?

Well, by De Morgan's law the two expressions are the same.  And they
are the same number of characters.  And both will produce a compile
time constant and thus the same code.  However, I like the ~FOO & ~BAR
& ~BAR form better as there is greater parallelism between each term
of the expression.

>>       ctrl0 |= BM_SSP_CTRL0_DATA_XFER | mxs_spi_cs_to_reg(cs);
>>
>> -     if (*first)
>> -             ctrl0 |= BM_SSP_CTRL0_LOCK_CS;
>
> The DMA will overwrite ctrl0 in each turn, did you try very long (>64kB long)
> transfers with your adjustments? To test this, you can try
>
> $ dd if=/dev/mtdN of=/dev/null bs=1M
>
> on sufficiently large SPI flash supporting the FAST_READ opcode.

Don't have SPI flash.  I did test with logic analyzer and the current
code is clearly broken and my changes clearly fix it.  It should be
obvious from looking a the code that it is wrong.  The DMA does write
ctrl0 on each segment of each transfer, but look at the previous
paragraph to see where it comes from.  Once READ or IGNORE_CRC are
set, nothing will clear them until PIO mode is used.  It's the same
with the bug fix for 3.9 that clears the XFER_COUNT bits in DMA mode.
Strangely, I didn't notice that bug since all my xfers are the same
length!  But I do switch between slaves, between read and write, and
use messages with multiple transfers, in DMA mode, all of which are
broken in the current driver.

>> +             if ((sg_count + 1 == sgs) && (flags & TXRX_DEASSERT_CS))
>>                       ctrl0 |= BM_SSP_CTRL0_IGNORE_CRC;
>>
>>               if (ssp->devid == IMX23_SSP) {
>> @@ -279,7 +267,7 @@ static int mxs_spi_txrx_dma(struct mxs_spi *spi, int
>> cs,
>>
>>               sg_init_one(&dma_xfer[sg_count].sg, sg_buf, min);
>>               ret = dma_map_sg(ssp->dev, &dma_xfer[sg_count].sg, 1,
>> -                     write ? DMA_TO_DEVICE : DMA_FROM_DEVICE);
>> +                     (flags & TXRX_WRITE) ? DMA_TO_DEVICE : DMA_FROM_DEVICE);
>
> I think this is unneeded.

Whatis ?  Setting the DMA direction or using flags?

Look at it this way:

Existing code that uses the first/last flags is wrong and needs to be
changed.  Therefor code using 'first' and 'last' will be changed.

Passing the flags as pointers is bad practice and makes no sense to
do.  Does it make any sense to re-write code fix the way it uses first
and last, then re-write those same lines a second time to not use
pointers?

If the way the flags are passed should change, then why not do it the
most efficient way.  It isn't any more complicated and produces better
code.  One flag per parameter becomes cumbersome when more flags are
added for additional features.

I'm all for splitting my patches up.  I sent five patches when I bet 9
out 10 developers would have just done one.  But I don't think it
makes any sense to re-write the same line of code over and over again
in successive patches in a series before getting to the final version.
 It just makes more churn to review.

I hate it when I get a series of patches and spot a flaw, take the
time to write up the flaw and how it should be fixed, only to discover
that the flaw is fixed later on in the series and I wasted my time.


From tpiepho at gmail.com  Mon Apr  1 21:58:34 2013
From: tpiepho at gmail.com (Trent Piepho)
Date: Mon, 1 Apr 2013 18:58:34 -0700
Subject: [PATCH 2/5] spi/mxs: Fix chip select control bits in DMA mode
In-Reply-To: <201304020202.43501.marex@denx.de>
References: <1364570381-17605-1-git-send-email-tpiepho@gmail.com>
 <201304020130.51951.marex@denx.de>
 <CA+7tXij_V1iAdPuPoTQ6CK6U5Y-iJprCPsTj=_LHAV1-=CL7gA@mail.gmail.com>
 <201304020202.43501.marex@denx.de>
Message-ID: <CA+7tXihh1boAJTZN_R7hxxPArKYm8Y=bfANU9pvnsDmk6kXixQ@mail.gmail.com>

On Mon, Apr 1, 2013 at 5:02 PM, Marek Vasut <marex at denx.de> wrote:
>> On Mon, Apr 1, 2013 at 4:30 PM, Marek Vasut <marex at denx.de> wrote:
>> >> >> -static uint32_t mxs_spi_cs_to_reg(unsigned cs)
>> >> >> +static u32 mxs_spi_cs_to_reg(unsigned cs)
>> >> >>
>> >> >>  {
>> >> >>
>> >> >> -     uint32_t select = 0;
>> >> >> +     u32 select = 0;
>> >>
>> >> I'll make it a separate patch.
>> >
>> > This is completely irrelevant change, please just submit the relevant
>> > patches.
>>
>> Kernel code should use u16, u32, etc. instead of the uint16_t,
>> uint32_t types.  The rest of the driver uses them.  Why should this
>> one function use a different type than the rest?  It's ugly and
>> inconsistent.
>
> Is this documented somewhere please? I see only a mention about this in chapter
> 5 of Documentation/CodingStyle , section (d) . Either way, separate such
> cosmetic change into another series so they're not in the way of relevant stuff.

It's pretty clearly existing practice:
$ perl -ne '@x=/\buint32_t\b/g;$x+=$#x+1;END{print "$x\n";}' drivers/spi/*.[ch]
9
$ perl -ne '@x=/\bu32\b/g;$x+=$#x+1;END{print "$x\n";}' drivers/spi/*.[ch]
501


From jon-hunter at ti.com  Mon Apr  1 22:10:09 2013
From: jon-hunter at ti.com (Jon Hunter)
Date: Mon, 1 Apr 2013 21:10:09 -0500
Subject: [GIT PULL] ARM: OMAP2+: System timer updates
Message-ID: <515A3E01.1060308@ti.com>

The following changes since commit 2d61aecee8f32259920cdf90a452fa26ffc64e9f:

  Merge commit '6bb27d7349db51b50c40534710fe164ca0d58902' into omap-timer-for-v3.10 (2013-04-01 13:47:29 -0500)

are available in the git repository at:


  git://github.com/jonhunter/linux.git omap-timer-for-v3.10

for you to fetch changes up to 4615943cf3a531bc76f589c22bd366da092b7c0f:

  ARM: OMAP4+: Fix sparse warning in system timers (2013-04-01 13:49:46 -0500)

----------------------------------------------------------------
This series consists mainly of clean-ups for clockevents and
clocksource timers on OMAP2+ devices. The most significant change
in functionality comes from the 5th patch which is changing the
selection of the clocksource timer for OMAP3 and AM335x devices
when gptimers are used for clocksource.

This series is dependent on commit 7185684 (ARM: OMAP: use
consistent error checking) from RMK's clean-up branch and commit
6bb27d7 (ARM: delete struct sys_timer)
----------------------------------------------------------------

Jon Hunter (7):
      ARM: OMAP2+: Display correct system timer name
      ARM: OMAP2+: Remove hard-coded test on timer ID
      ARM: OMAP2+: Simplify system timer clock definitions
      ARM: OMAP2+: Simplify system timers definitions
      ARM: OMAP3: Update clocksource timer selection
      ARM: OMAP2+: Store ID of system timers in timer structure
      ARM: OMAP4+: Fix sparse warning in system timers

 arch/arm/mach-omap2/board-cm-t3517.c |    2 +-
 arch/arm/mach-omap2/board-generic.c  |    2 +-
 arch/arm/mach-omap2/common.h         |    3 +-
 arch/arm/mach-omap2/timer.c          |  121 +++++++++++++++++-----------------
 4 files changed, 65 insertions(+), 63 deletions(-)


From Milo.Kim at ti.com  Mon Apr  1 22:18:32 2013
From: Milo.Kim at ti.com (Kim, Milo)
Date: Tue, 2 Apr 2013 02:18:32 +0000
Subject: [PATCH] clk: add LP8788 clock driver
In-Reply-To: <20130402011236.8177.88731@quantum>
References: <A874F61F95741C4A9BA573A70FE3998F82E48E3F@DQHE02.ent.ti.com>
 <20130402011236.8177.88731@quantum>
Message-ID: <A874F61F95741C4A9BA573A70FE3998F82E4A7F3@DQHE02.ent.ti.com>

> Just FYI most folks are simply using a macro to do the above.  E.g:
> 
> #define to_lp8788_clk(_hw) container_of(_hw, struct lp8788_clk, hw)

OK, thanks! Will be fixed in the 2nd patch.

> > +
> > +static int lp8788_clk_is_enabled(struct clk_hw *hw)
> > +{
> > +       struct lp8788_clk *pclk = to_lp8788_clk(hw);
> > +
> > +       /*
> > +        * Do not use the LP8788 register access here, unsafe locking
> problem
> > +        * may occur during loading the driver. So stored varible is
> prefered.
> > +        */
> 
> What unsafe locking problem?

If I try to get LP8788 clock status via the remap-i2c here, then locking problem
occurs.
The 'enable_lock' is already locked and the MUTEX of REGMAP is used on reading
a register.

[    2.692443] -------------------------------------------------------
[    2.699066] swapper/0/1 is trying to acquire lock:
[    2.704132]  (&map->mutex){+.+...}, at: [<c0374ecc>] regmap_read+0x34/0x5c
[    2.711486] 
[    2.711486] but task is already holding lock:
[    2.717681]  (enable_lock){......}, at: [<c047a6c8>] clk_disable_unused_subtr
ee+0x3c/0xb4
[    2.726379] 
[    2.726379] which lock already depends on the new lock.

That's why lp8788_get_clk_status() is used on _probe().
- Read a register and store the value into local status variable.
Then local variable is used in .is_enabled().

> Also have you looked into using the new .is_prepare callback?  See:
> https://git.linaro.org/gitweb?p=people/mturquette/linux.git;a=commitdif
> f;h=3d6ee287a3e341c88eafd0b4620b12d640b3736b;hp=30ee400614385ac49f4c9b4
> bc03d77ff8f07a61e

Not checked yet, but it looks no caller for this callback at this moment.
Will this be added inside the clk_prepare()?

> > +
> > +       return pclk->enabled;
> 
> Why provide a .is_enabled callback when there are no .enable
> or .disable
> callbacks?

LP8788 Clock is always enabled, so it needs to show the clock status.
However, I think no effect on working the clock operation without is_enabled().
Can I remove it?

Thanks,
Milo


From horms at verge.net.au  Mon Apr  1 22:24:34 2013
From: horms at verge.net.au (Simon Horman)
Date: Tue, 2 Apr 2013 11:24:34 +0900
Subject: [PATCH 3/3 v2] ARM: shmobile: bockw: add SMSC ethernet support
In-Reply-To: <87zjxh6b8t.wl%kuninori.morimoto.gx@renesas.com>
References: <87zjxvewko.wl%kuninori.morimoto.gx@renesas.com>
 <87fvzb56n3.wl%kuninori.morimoto.gx@renesas.com>
 <87bo9z56k8.wl%kuninori.morimoto.gx@renesas.com>
 <515982A8.3090307@cogentembedded.com>
 <87zjxh6b8t.wl%kuninori.morimoto.gx@renesas.com>
Message-ID: <20130402022433.GA4469@verge.net.au>

On Mon, Apr 01, 2013 at 05:13:10PM -0700, Kuninori Morimoto wrote:
> 
> Hi Sergei, Simon
> 
> > >   	chosen {
> > > -		bootargs = "console=ttySC0,115200 ignore_loglevel";
> > > +		bootargs = "console=ttySC0,115200 ignore_loglevel ip=dhcp root=/dev/nfs";
> > >   	};
> > >
> > >   	memory {
> > 
> >     In my opinion, modifying .dts file should be done in a separate patch.
> (snip)
> > >   # CONFIG_SCHED_DEBUG is not set
> > >   # CONFIG_DEBUG_BUGVERBOSE is not set
> > >   # CONFIG_FTRACE is not set
> > >   # CONFIG_ARM_UNWIND is not set
> > > -CONFIG_KEYS=y
> > > -CONFIG_CRYPTO=y
> > >   CONFIG_AVERAGE=y
> > 
> >     In my opinion, modifying bockw_defconfig should be done in a separate 
> > patch. Mixing everything up in a signle patch is a bad practice.
> 
> It depends on LTSI backport / upstreaming I believe.
> I need Simon's opinion

I have no strong opinions on this, but in general breaking up patches
makes my life easier. So long as the individual patches don't are useful
and don't break anything :^)


From swarren at wwwdotorg.org  Mon Apr  1 22:38:44 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Mon, 01 Apr 2013 20:38:44 -0600
Subject: [PATCH] bcm2835: Add Broadcom BCM2835 RNG to the device tree
In-Reply-To: <1364451124-5039-1-git-send-email-lkundrak@v3.sk>
References: <1364135511-26970-1-git-send-email-lkundrak@v3.sk>
 <1364451124-5039-1-git-send-email-lkundrak@v3.sk>
Message-ID: <515A44B4.7070903@wwwdotorg.org>

On 03/28/2013 12:12 AM, Lubomir Rintel wrote:
> This adds a device tree binding for random number generator present on Broadcom
> BCM2835 SoC, used in Raspberry Pi and Roku 2 devices.

FYI, I intend to apply this patch to the bcm2835 tree whenever the RNG
driver itself is applied to the hw_random tree. If you could ping me
when that happens to jog my memory, that'd be great. Thanks.


From padma.kvr at gmail.com  Mon Apr  1 22:58:10 2013
From: padma.kvr at gmail.com (Padma Venkat)
Date: Tue, 2 Apr 2013 08:28:10 +0530
Subject: [PATCH V2] DMA: PL330: Add check if device tree compatible
In-Reply-To: <20130401182151.GH10326@intel.com>
References: <1362475531-32260-1-git-send-email-padma.v@samsung.com>
 <1362475531-32260-2-git-send-email-padma.v@samsung.com>
 <20130321093906.GL10326@intel.com>
 <CAL_Jsq+3bJDiA=rXS=WY3BGuRh5X+nyxxosrqtSD9fx-asbCKQ@mail.gmail.com>
 <20130401182151.GH10326@intel.com>
Message-ID: <CAAgF-BdMgwKaVCaURwCeZcH9-H7nQBpafjZ51zJYi6AXXk72yw@mail.gmail.com>

Hi Vinod,

I apologies for the delayed reply. Last week I was out of station and
no access to mails. I will send another patch addressing your
comments.

Thanks
Padma
On Mon, Apr 1, 2013 at 11:51 PM, Vinod Koul <vinod.koul at intel.com> wrote:
>
> On Mon, Apr 01, 2013 at 08:13:31AM -0500, Rob Herring wrote:
> > On Thu, Mar 21, 2013 at 4:39 AM, Vinod Koul <vinod.koul at intel.com> wrote:
> > > On Tue, Mar 05, 2013 at 02:55:31PM +0530, Padmavathi Venna wrote:
> > >> This patch register the dma controller with generic dma helpers only
> > >> in DT case. This also adds some extra error handling in the driver.
> > >>
> > >> Signed-off-by: Padmavathi Venna <padma.v at samsung.com>
> > >> Reported-by: Sachin Kamat <sachin.kamat at linaro.org>
> >
> > What's the status on this? It is needed for 3.9 to fix pl330 on highbank.
> Well the status is that submitter has been rude. I had few questions and
> comments on this patch and they are yet to be addressed.
>
> --
> ~Vinod
> >
> > Rob
> >
> > >> ---
> > >>
> > >> Based on Vinod Koul next branch.
> > >>
> > >> Changes since V1:
> > >>       - return silently when of_dma_controller_register fails, as
> > >>         suggested by Arnd.
> > >>
> > >>  drivers/dma/pl330.c |   38 +++++++++++++++++++++++++++-----------
> > >>  1 files changed, 27 insertions(+), 11 deletions(-)
> > >>
> > >> diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
> > >> index 7181531..5dbc594 100644
> > >> --- a/drivers/dma/pl330.c
> > >> +++ b/drivers/dma/pl330.c
> > >> @@ -2882,7 +2882,7 @@ pl330_probe(struct amba_device *adev, const struct amba_id *id)
> > >>  {
> > >>       struct dma_pl330_platdata *pdat;
> > >>       struct dma_pl330_dmac *pdmac;
> > >> -     struct dma_pl330_chan *pch;
> > >> +     struct dma_pl330_chan *pch, *_p;
> > >>       struct pl330_info *pi;
> > >>       struct dma_device *pd;
> > >>       struct resource *res;
> > >> @@ -2984,7 +2984,16 @@ pl330_probe(struct amba_device *adev, const struct amba_id *id)
> > >>       ret = dma_async_device_register(pd);
> > >>       if (ret) {
> > >>               dev_err(&adev->dev, "unable to register DMAC\n");
> > >> -             goto probe_err2;
> > >> +             goto probe_err3;
> > >> +     }
> > >> +
> > >> +     if (adev->dev.of_node) {
> > >> +             ret = of_dma_controller_register(adev->dev.of_node,
> > >> +                                      of_dma_pl330_xlate, pdmac);
> > >> +             if (ret) {
> > >> +                     dev_err(&adev->dev,
> > >> +                     "unable to register DMA to the generic DT DMA helpers\n");
> > > Indent?

Okey.
>
> > >> +             }
> > >>       }
> > >>
> > >>       dev_info(&adev->dev,
> > >> @@ -2995,16 +3004,21 @@ pl330_probe(struct amba_device *adev, const struct amba_id *id)
> > >>               pi->pcfg.data_bus_width / 8, pi->pcfg.num_chan,
> > >>               pi->pcfg.num_peri, pi->pcfg.num_events);
> > >>
> > >> -     ret = of_dma_controller_register(adev->dev.of_node,
> > >> -                                      of_dma_pl330_xlate, pdmac);
> > >> -     if (ret) {
> > >> -             dev_err(&adev->dev,
> > >> -             "unable to register DMA to the generic DT DMA helpers\n");
> > >> -             goto probe_err2;
> > >> -     }
> > >> -
> > >>       return 0;
> > >> +probe_err3:
> > >> +     amba_set_drvdata(adev, NULL);
> > >>
> > >> +     /* Idle the DMAC */
> > >> +     list_for_each_entry_safe(pch, _p, &pdmac->ddma.channels,
> > >> +                     chan.device_node) {
> > >> +
> > >> +             /* Remove the channel */
> > >> +             list_del(&pch->chan.device_node);
> > >> +
> > >> +             /* Flush the channel */
> > >> +             pl330_control(&pch->chan, DMA_TERMINATE_ALL, 0);
> > >> +             pl330_free_chan_resources(&pch->chan);
> > > free_chan for error handling in probe?


Will remove this.

> > >
>
> > >> +     }
> > >>  probe_err2:
> > >>       pl330_del(pi);
> > >>  probe_err1:
> > >> @@ -3023,8 +3037,10 @@ static int pl330_remove(struct amba_device *adev)
> > >>       if (!pdmac)
> > >>               return 0;
> > >>
> > >> -     of_dma_controller_free(adev->dev.of_node);
> > >> +     if (adev->dev.of_node)
> > >> +             of_dma_controller_free(adev->dev.of_node);
> > >>
> > >> +     dma_async_device_unregister(&pdmac->ddma);
> > >>       amba_set_drvdata(adev, NULL);
> > >>
> > >>       /* Idle the DMAC */
> > >> --
> > >> 1.7.4.4
> > >>


From kpark3469 at gmail.com  Mon Apr  1 23:04:44 2013
From: kpark3469 at gmail.com (kpark3469 at gmail.com)
Date: Tue,  2 Apr 2013 12:04:44 +0900
Subject: [PATCH] ARM: kprobes: fix test coverage missing failures
Message-ID: <1364871884-28252-1-git-send-email-kpark3469@gmail.com>

From: Sahara <keun-o.park at windriver.com>

If kprobe tests run on ARMv6k or ARMv6, there're a number of test
coverage missing failures like:

FAIL: Register test coverage missing for 0ff000f0 00600090 (04404)
FAIL: Test coverage entry missing for 0ff000f0 00600090
FAIL: Test coverage entry missing for 0f200090 00200090
FAIL: Register test coverage missing for 0fb00000 03000000 (05000)
FAIL: Test coverage entry missing for 0fb00000 03000000
FAIL: Test coverage entry missing for 0fff00ff 03200001
FAIL: Test coverage entry missing for 0fff00ff 03200004
FAIL: Test coverage entry missing for 0fff00fc 03200000
FAIL: Test coverage entry missing for 0fb00010 06000010
FAIL: Test coverage entry missing for 0f8000f0 060000b0
FAIL: Test coverage entry missing for 0f8000f0 060000d0
FAIL: Register test coverage missing for 0f800010 06000010 (55005)
FAIL: Test coverage entry missing for 0f800010 06000010
FAIL: Test coverage entry missing for 0ff000f0 07f000f0
FAIL: Register test coverage missing for 0fa00070 07a00050 (05005)
FAIL: Test coverage entry missing for 0fa00070 07a00050
FAIL: Register test coverage missing for 0fe0007f 07c0001f (05000)
FAIL: Test coverage entry missing for 0fe0007f 07c0001f
FAIL: Register test coverage missing for 0fe00070 07c00010 (05001)
FAIL: Test coverage entry missing for 0fe00070 07c00010

Some instructions (like yield, sev, nop, and so on) are available in
ARMv6k or ARMv7, which we can test by checking the __LINUX_ARM_ARCH__
or checking the CONFIG_CPU_32v6K.
While MLS is excluded on ARMv6, more TEST_UNSUPPORTED coverages for
MLA is needed.
NOP instruction is used in several predefined macros, and these will
lead us to get a lot of INSN_REJECTED errors since the nop instruction
is not included in kprobe_decode_arm_table on ARMv6. By checking the
__LINUX_ARM_ARCH__ or the CONFIG_CPU_32v6K, 'nop' or 'mov r0,r0' will
be selected.

Signed-off-by: Sahara <keun-o.park at windriver.com>
---
 arch/arm/kernel/kprobes-arm.c      |   20 ++++++++++++++++++--
 arch/arm/kernel/kprobes-test-arm.c |    3 +++
 arch/arm/kernel/kprobes-test.c     |    2 +-
 arch/arm/kernel/kprobes-test.h     |   18 ++++++++++++------
 4 files changed, 34 insertions(+), 9 deletions(-)

diff --git a/arch/arm/kernel/kprobes-arm.c b/arch/arm/kernel/kprobes-arm.c
index 8a30c89..324fd22 100644
--- a/arch/arm/kernel/kprobes-arm.c
+++ b/arch/arm/kernel/kprobes-arm.c
@@ -495,10 +495,13 @@ static const union decode_item arm_cccc_0000_____1001_table[] = {
 
 	/* MLA			cccc 0000 0010 xxxx xxxx xxxx 1001 xxxx */
 	/* MLAS			cccc 0000 0011 xxxx xxxx xxxx 1001 xxxx */
-	DECODE_OR	(0x0fe000f0, 0x00200090),
+	DECODE_EMULATEX	(0x0fe000f0, 0x00200090, emulate_rd16rn12rm0rs8_rwflags_nopc,
+						 REGS(NOPC, NOPC, NOPC, 0, NOPC)),
+#if __LINUX_ARM_ARCH__ >= 7
 	/* MLS			cccc 0000 0110 xxxx xxxx xxxx 1001 xxxx */
 	DECODE_EMULATEX	(0x0ff000f0, 0x00600090, emulate_rd16rn12rm0rs8_rwflags_nopc,
 						 REGS(NOPC, NOPC, NOPC, 0, NOPC)),
+#endif
 
 	/* UMAAL		cccc 0000 0100 xxxx xxxx xxxx 1001 xxxx */
 	DECODE_OR	(0x0ff000f0, 0x00400090),
@@ -533,12 +536,14 @@ static const union decode_item arm_cccc_0001_____1001_table[] = {
 static const union decode_item arm_cccc_000x_____1xx1_table[] = {
 	/* Extra load/store instructions				*/
 
+#if __LINUX_ARM_ARCH__ >= 7
 	/* STRHT		cccc 0000 xx10 xxxx xxxx xxxx 1011 xxxx */
 	/* ???			cccc 0000 xx10 xxxx xxxx xxxx 11x1 xxxx */
 	/* LDRHT		cccc 0000 xx11 xxxx xxxx xxxx 1011 xxxx */
 	/* LDRSBT		cccc 0000 xx11 xxxx xxxx xxxx 1101 xxxx */
 	/* LDRSHT		cccc 0000 xx11 xxxx xxxx xxxx 1111 xxxx */
 	DECODE_REJECT	(0x0f200090, 0x00200090),
+#endif
 
 	/* LDRD/STRD lr,pc,{...	cccc 000x x0x0 xxxx 111x xxxx 1101 xxxx */
 	DECODE_REJECT	(0x0e10e0d0, 0x0000e0d0),
@@ -641,11 +646,14 @@ static const union decode_item arm_cccc_000x_table[] = {
 static const union decode_item arm_cccc_001x_table[] = {
 	/* Data-processing (immediate)					*/
 
+#if __LINUX_ARM_ARCH__ >= 7
 	/* MOVW			cccc 0011 0000 xxxx xxxx xxxx xxxx xxxx */
 	/* MOVT			cccc 0011 0100 xxxx xxxx xxxx xxxx xxxx */
 	DECODE_EMULATEX	(0x0fb00000, 0x03000000, emulate_rd12rm0_noflags_nopc,
 						 REGS(0, NOPC, 0, 0, 0)),
+#endif
 
+#if (__LINUX_ARM_ARCH__ >= 7) || defined(CONFIG_CPU_32v6K)
 	/* YIELD		cccc 0011 0010 0000 xxxx xxxx 0000 0001 */
 	DECODE_OR	(0x0fff00ff, 0x03200001),
 	/* SEV			cccc 0011 0010 0000 xxxx xxxx 0000 0100 */
@@ -654,7 +662,9 @@ static const union decode_item arm_cccc_001x_table[] = {
 	/* WFE			cccc 0011 0010 0000 xxxx xxxx 0000 0010 */
 	/* WFI			cccc 0011 0010 0000 xxxx xxxx 0000 0011 */
 	DECODE_SIMULATE	(0x0fff00fc, 0x03200000, kprobe_simulate_nop),
-	/* DBG			cccc 0011 0010 0000 xxxx xxxx ffff xxxx */
+	/* DBG			cccc 0011 0010 0000 xxxx xxxx 1111 xxxx */
+	DECODE_REJECT	(0x0fb000f0, 0x032000f0),
+#endif
 	/* unallocated hints	cccc 0011 0010 0000 xxxx xxxx xxxx xxxx */
 	/* MSR (immediate)	cccc 0011 0x10 xxxx xxxx xxxx xxxx xxxx */
 	DECODE_REJECT	(0x0fb00000, 0x03200000),
@@ -712,6 +722,7 @@ static const union decode_item arm_cccc_0110_____xxx1_table[] = {
 	DECODE_EMULATEX	(0x0fb00070, 0x06b00030, emulate_rd12rm0_noflags_nopc,
 						 REGS(0, NOPC, 0, 0, NOPC)),
 
+#if __LINUX_ARM_ARCH__ >= 7
 	/* ???			cccc 0110 0x00 xxxx xxxx xxxx xxx1 xxxx */
 	DECODE_REJECT	(0x0fb00010, 0x06000010),
 	/* ???			cccc 0110 0xxx xxxx xxxx xxxx 1011 xxxx */
@@ -756,6 +767,7 @@ static const union decode_item arm_cccc_0110_____xxx1_table[] = {
 	/* UHSUB8		cccc 0110 0111 xxxx xxxx xxxx 1111 xxxx */
 	DECODE_EMULATEX	(0x0f800010, 0x06000010, emulate_rd12rn16rm0_rwflags_nopc,
 						 REGS(NOPC, NOPC, 0, 0, NOPC)),
+#endif
 
 	/* PKHBT		cccc 0110 1000 xxxx xxxx xxxx x001 xxxx */
 	/* PKHTB		cccc 0110 1000 xxxx xxxx xxxx x101 xxxx */
@@ -790,8 +802,10 @@ static const union decode_item arm_cccc_0110_____xxx1_table[] = {
 static const union decode_item arm_cccc_0111_____xxx1_table[] = {
 	/* Media instructions						*/
 
+#if __LINUX_ARM_ARCH__ >= 7
 	/* UNDEFINED		cccc 0111 1111 xxxx xxxx xxxx 1111 xxxx */
 	DECODE_REJECT	(0x0ff000f0, 0x07f000f0),
+#endif
 
 	/* SMLALD		cccc 0111 0100 xxxx xxxx xxxx 00x1 xxxx */
 	/* SMLSLD		cccc 0111 0100 xxxx xxxx xxxx 01x1 xxxx */
@@ -820,6 +834,7 @@ static const union decode_item arm_cccc_0111_____xxx1_table[] = {
 	DECODE_EMULATEX	(0x0ff000d0, 0x075000d0, emulate_rd16rn12rm0rs8_rwflags_nopc,
 						 REGS(NOPC, NOPC, NOPC, 0, NOPC)),
 
+#if __LINUX_ARM_ARCH__ >= 7
 	/* SBFX			cccc 0111 101x xxxx xxxx xxxx x101 xxxx */
 	/* UBFX			cccc 0111 111x xxxx xxxx xxxx x101 xxxx */
 	DECODE_EMULATEX	(0x0fa00070, 0x07a00050, emulate_rd12rm0_noflags_nopc,
@@ -832,6 +847,7 @@ static const union decode_item arm_cccc_0111_____xxx1_table[] = {
 	/* BFI			cccc 0111 110x xxxx xxxx xxxx x001 xxxx */
 	DECODE_EMULATEX	(0x0fe00070, 0x07c00010, emulate_rd12rm0_noflags_nopc,
 						 REGS(0, NOPC, 0, 0, NOPCX)),
+#endif
 
 	DECODE_END
 };
diff --git a/arch/arm/kernel/kprobes-test-arm.c b/arch/arm/kernel/kprobes-test-arm.c
index 8393129..850b7b9 100644
--- a/arch/arm/kernel/kprobes-test-arm.c
+++ b/arch/arm/kernel/kprobes-test-arm.c
@@ -353,6 +353,9 @@ void kprobe_arm_test_cases(void)
 	TEST_RRR(    "mlahi	r7, r",8, VAL3,", r",9, VAL1,", r",10, VAL2,"")
 	TEST_RR(     "mla	lr, r",1, VAL2,", r",2, VAL3,", r13")
 	TEST_UNSUPPORTED(".word 0xe02f3291 @ mla pc, r1, r2, r3")
+	TEST_UNSUPPORTED(".word 0xe020329f @ mla r0, pc, r2, r3")
+	TEST_UNSUPPORTED(".word 0xe0203f91 @ mla r0, r1, pc, r3")
+	TEST_UNSUPPORTED(".word 0xe020f291 @ mla r0, r1, r2, pc")
 	TEST_RRR(    "mlas	r0, r",1, VAL1,", r",2, VAL2,", r",3,  VAL3,"")
 	TEST_RRR(    "mlahis	r7, r",8, VAL3,", r",9, VAL1,", r",10, VAL2,"")
 	TEST_RR(     "mlas	lr, r",1, VAL2,", r",2, VAL3,", r13")
diff --git a/arch/arm/kernel/kprobes-test.c b/arch/arm/kernel/kprobes-test.c
index 0cd63d0..0651fd6 100644
--- a/arch/arm/kernel/kprobes-test.c
+++ b/arch/arm/kernel/kprobes-test.c
@@ -478,7 +478,7 @@ static int run_api_tests(long (*func)(long, long))
 static void __naked benchmark_nop(void)
 {
 	__asm__ __volatile__ (
-		"nop		\n\t"
+		NOP"		\n\t"
 		"bx	lr"
 	);
 }
diff --git a/arch/arm/kernel/kprobes-test.h b/arch/arm/kernel/kprobes-test.h
index e28a869..24822f0 100644
--- a/arch/arm/kernel/kprobes-test.h
+++ b/arch/arm/kernel/kprobes-test.h
@@ -144,20 +144,26 @@ struct test_arg_end {
 	".code "TEST_ISA"				\n\t"	\
 	"0:						\n\t"
 
+#if (__LINUX_ARM_ARCH__ >= 7) || defined(CONFIG_CPU_32v6K)
+#define NOP "nop"
+#else
+#define NOP "mov	r0, r0"
+#endif
+
 #define TEST_INSTRUCTION(instruction)				\
-	"50:	nop					\n\t"	\
+	"50:	"NOP"					\n\t"	\
 	"1:	"instruction"				\n\t"	\
-	"	nop					\n\t"
+	"	"NOP"					\n\t"
 
 #define TEST_BRANCH_F(instruction)				\
 	TEST_INSTRUCTION(instruction)				\
 	"	b	99f				\n\t"	\
-	"2:	nop					\n\t"
+	"2:	"NOP"					\n\t"
 
 #define TEST_BRANCH_B(instruction)				\
 	"	b	50f				\n\t"	\
 	"	b	99f				\n\t"	\
-	"2:	nop					\n\t"	\
+	"2:	"NOP"					\n\t"	\
 	"	b	99f				\n\t"	\
 	TEST_INSTRUCTION(instruction)
 
@@ -166,12 +172,12 @@ struct test_arg_end {
 	"	b	99f				\n\t"	\
 	codex"						\n\t"	\
 	"	b	99f				\n\t"	\
-	"2:	nop					\n\t"
+	"2:	"NOP"					\n\t"
 
 #define TEST_BRANCH_BX(instruction, codex)			\
 	"	b	50f				\n\t"	\
 	"	b	99f				\n\t"	\
-	"2:	nop					\n\t"	\
+	"2:	"NOP"					\n\t"	\
 	"	b	99f				\n\t"	\
 	codex"						\n\t"	\
 	TEST_INSTRUCTION(instruction)
-- 
1.7.1



From santosh.shilimkar at ti.com  Mon Apr  1 23:23:58 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Tue, 2 Apr 2013 08:53:58 +0530
Subject: [PATCH v2 02/13] ARM: convert arm/arm64 arch timer to use
 CLKSRC_OF init
In-Reply-To: <1364854883-5961-3-git-send-email-robherring2@gmail.com>
References: <1364854883-5961-1-git-send-email-robherring2@gmail.com>
 <1364854883-5961-3-git-send-email-robherring2@gmail.com>
Message-ID: <515A4F4E.3060107@ti.com>

On Tuesday 02 April 2013 03:51 AM, Rob Herring wrote:
> From: Rob Herring <rob.herring at calxeda.com>
> 
> This converts arm and arm64 to use CLKSRC_OF DT based initialization for
> the arch timer. A new function arch_timer_arch_init is added to allow for
> arch specific setup.
> 
> This has a side effect of enabling sched_clock on omap5 and exynos5. There
> should not be any reason not to use the arch timers for sched_clock.
> 
Absolutely.

> Signed-off-by: Rob Herring <rob.herring at calxeda.com>

[..]

>  arch/arm/mach-omap2/timer.c                  |    5 +----

Acked-by: Santosh Shilimkar <santosh.shilimkar at ti.com>



From kuninori.morimoto.gx at renesas.com  Mon Apr  1 23:25:27 2013
From: kuninori.morimoto.gx at renesas.com (Kuninori Morimoto)
Date: Mon, 01 Apr 2013 20:25:27 -0700 (PDT)
Subject: [PATCH 3/3 v2] ARM: shmobile: bockw: add SMSC ethernet support
In-Reply-To: <20130402022433.GA4469@verge.net.au>
References: <87zjxvewko.wl%kuninori.morimoto.gx@renesas.com>
 <87fvzb56n3.wl%kuninori.morimoto.gx@renesas.com>
 <87bo9z56k8.wl%kuninori.morimoto.gx@renesas.com>
 <515982A8.3090307@cogentembedded.com>
 <87zjxh6b8t.wl%kuninori.morimoto.gx@renesas.com>
 <20130402022433.GA4469@verge.net.au>
Message-ID: <87vc8562cc.wl%kuninori.morimoto.gx@renesas.com>


Hi Simon

> > It depends on LTSI backport / upstreaming I believe.
> > I need Simon's opinion
> 
> I have no strong opinions on this, but in general breaking up patches
> makes my life easier. So long as the individual patches don't are useful
> and don't break anything :^)

OK, I see
I can send v3 patch which are separateed
(= C code/DT/defconfig)


Best regards
---
Kuninori Morimoto


From moore at free.fr  Tue Apr  2 00:17:10 2013
From: moore at free.fr (Chris Moore)
Date: Tue, 02 Apr 2013 06:17:10 +0200
Subject: [PATCH] ARM: kirkwood: DT board setup for CloudBox
In-Reply-To: <20130401163316.GC16404@kw.sim.vm.gnt>
References: <1364555206-5870-1-git-send-email-simon.guinot@sequanux.org>
 <20130329153132.GJ13280@titan.lakedaemon.net>
 <20130329184109.GA16404@kw.sim.vm.gnt> <51568B89.1060009@free.fr>
 <20130401163316.GC16404@kw.sim.vm.gnt>
Message-ID: <515A5BC6.5000007@free.fr>

Hi Simon,

Le 01/04/2013 18:33, Simon Guinot a ?crit :
> On Sat, Mar 30, 2013 at 07:51:53AM +0100, Chris Moore wrote:
>
> Le 29/03/2013 19:41, Simon Guinot a ?crit :
>>> On Fri, Mar 29, 2013 at 11:31:32AM -0400, Jason Cooper wrote
>>>> On Fri, Mar 29, 2013 at 12:06:46PM +0100, Simon Guinot wrote:
>>>>> This patch adds DT board setup for the LaCie NAS CloudBox. The CloudBox
>>>>> is a low cost NAS based on the Network Space v2.
>>>>>
>>>>> Chipset list:
>>>>> - CPU MARVELL 88F6702 1Ghz
>>>>> - SDRAM memory: 256MB DDR2-800 (2x128MB x8) 400Mhz
>>>>> - 1 Ethernet Gigabit port (PHY MARVELL 88E1318)
>>>>> - SPI flash, NOR 512KB
>>>>> - 1 push button
>>>>> - 2 LEDs (red and blue)
>>>>>
>>>>> +
>>>>> +/ {
>>>>> +	model = "LaCie CloudBox";
>>>>> +	compatible = "lacie,cloudbox", "marvell,kirkwood-88f6702", "marvell,kirkwood";
>>>> Is there a more specific string we can add here?  eg
>>>> "lacie,cloudbox-MODEL", "lacie,cloudbox", ...
>>> Unfortunately no. CloudBox is a product name which is also used by LaCie
>>> to name the board and the project.
>>>
>> I think it really is necessary to have a more specific name.
>> I have two, very different, products corresponding to LaCie CloudBox:
>> - The first one was a small black one with a 2.5" disk reviewed
>> here: http://www.smallnetbuilder.com/cloud/cloud-storage/462-lacie-cloudbox-reviewed
>> - The later one is a larger white one with a 3.5" disk described
>> here: http://www.smallnetbuilder.com/nas/nas-news/31927-lacie-relaunches-its-cloud-connected-nas
>>
>> IIRC the later one was originally called "CloudBox Family" although
>> maybe Family was dropped when it was officially released.
> Indeed, there is two (or rather one and half) released products called
> CloudBox.
>
> The old one (the first smallnetbuilder link) has been first called
> Network Space v2 mini, then SafeBox and finally released under the name
> Cloudbox. Very very few products have been sold. I don't know any owner
> and I suspect you got yours from the LaCie beta test program :)
>

Yes, in fact I was given both by LaCie for beta testing :)
Thank you, LaCie ;-)

> The new CloudBox is a very different product which has been first named
> FamilyBox and then released under the CloudBox name. Because the previous
> CloudBox was a really confidential product, the marketing guys have
> decided to reuse the name. This was a bad idea and despite the warnings
> they did that even so.
>
> Now, the fact is that the new CloudBox is a huge-selling LaCie product.
> That's why I propose to keep the names just as they are.
>

That is surprising: I greatly prefer the old black one, mainly because 
it uploads autonomously with the PC powered off.

Are all the new ones white and all the old ones black?
If so, can't we add white to the name or at least specify in Kconfig 
that it is the white version with a 3.5" disk?

Cheers,
Chris



From kuninori.morimoto.gx at renesas.com  Tue Apr  2 00:18:32 2013
From: kuninori.morimoto.gx at renesas.com (Kuninori Morimoto)
Date: Mon, 01 Apr 2013 21:18:32 -0700 (PDT)
Subject: [PATCH 0/5 v3] ARM: shmobile: Add SMSC support on Bock-W
In-Reply-To: <87fvzb56n3.wl%kuninori.morimoto.gx@renesas.com>
References: <87zjxvewko.wl%kuninori.morimoto.gx@renesas.com>
 <87fvzb56n3.wl%kuninori.morimoto.gx@renesas.com>
Message-ID: <87sj395zvv.wl%kuninori.morimoto.gx@renesas.com>


Hi Simon

These patches are v3 of extpin support on r8a7778,
and enable SMSC ether support on Bock-W board

This patch set is based latest simon/next

Kuninori Morimoto (5):
      ARM: shmobile: r8a7778: remove pointless PLATFORM_INFO()
      ARM: shmobile: r8a7778: add r8a7778_init_irq_extpin()
      ARM: shmobile: bockw: add SMSC ethernet support
      ARM: shmobile: bockw: enable network settings on bootargs
      ARM: shmobile: bockw: enable SMSC ethernet on defconfig

 arch/arm/boot/dts/r8a7778-bockw.dts           |    2 +-
 arch/arm/configs/bockw_defconfig              |   34 ++++++++++--
 arch/arm/mach-shmobile/Kconfig                |    1 +
 arch/arm/mach-shmobile/board-bockw.c          |   38 ++++++++++++++
 arch/arm/mach-shmobile/include/mach/r8a7778.h |    1 +
 arch/arm/mach-shmobile/setup-r8a7778.c        |   70 +++++++++++++++++++------
 6 files changed, 125 insertions(+), 21 deletions(-)


From kuninori.morimoto.gx at renesas.com  Tue Apr  2 00:19:17 2013
From: kuninori.morimoto.gx at renesas.com (Kuninori Morimoto)
Date: Mon, 01 Apr 2013 21:19:17 -0700 (PDT)
Subject: [PATCH 1/5 v3] ARM: shmobile: r8a7778: remove pointless
 PLATFORM_INFO()
In-Reply-To: <87sj395zvv.wl%kuninori.morimoto.gx@renesas.com>
References: <87zjxvewko.wl%kuninori.morimoto.gx@renesas.com>
 <87fvzb56n3.wl%kuninori.morimoto.gx@renesas.com>
 <87sj395zvv.wl%kuninori.morimoto.gx@renesas.com>
Message-ID: <87r4it5zum.wl%kuninori.morimoto.gx@renesas.com>

remove pointless PLATFORM_INFO() macro from setup-r8a7778,
and, used original platform_device_register_xxx()

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
---
v2 -> v3

 - no change

 arch/arm/mach-shmobile/setup-r8a7778.c |   26 +++++++++-----------------
 1 file changed, 9 insertions(+), 17 deletions(-)

diff --git a/arch/arm/mach-shmobile/setup-r8a7778.c b/arch/arm/mach-shmobile/setup-r8a7778.c
index 01c62be..57d6b0e 100644
--- a/arch/arm/mach-shmobile/setup-r8a7778.c
+++ b/arch/arm/mach-shmobile/setup-r8a7778.c
@@ -78,21 +78,13 @@ static struct sh_timer_config sh_tmu1_platform_data = {
 	.clocksource_rating	= 200,
 };
 
-#define PLATFORM_INFO(n, i)					\
-{								\
-	.parent		= &platform_bus,			\
-	.name		= #n,					\
-	.id		= i,					\
-	.res		= n ## i ## _resources,			\
-	.num_res	= ARRAY_SIZE(n ## i ##_resources),	\
-	.data		= &n ## i ##_platform_data,		\
-	.size_data	= sizeof(n ## i ## _platform_data),	\
-}
-
-struct platform_device_info platform_devinfo[] = {
-	PLATFORM_INFO(sh_tmu, 0),
-	PLATFORM_INFO(sh_tmu, 1),
-};
+#define r8a7778_register_tmu(idx)			\
+	platform_device_register_resndata(		\
+		&platform_bus, "sh_tmu", idx,		\
+		sh_tmu##idx##_resources,		\
+		ARRAY_SIZE(sh_tmu##idx##_resources),	\
+		&sh_tmu##idx##_platform_data,		\
+		sizeof(sh_tmu##idx##_platform_data))
 
 void __init r8a7778_add_standard_devices(void)
 {
@@ -114,8 +106,8 @@ void __init r8a7778_add_standard_devices(void)
 					      &scif_platform_data[i],
 					      sizeof(struct plat_sci_port));
 
-	for (i = 0; i < ARRAY_SIZE(platform_devinfo); i++)
-		platform_device_register_full(&platform_devinfo[i]);
+	r8a7778_register_tmu(0);
+	r8a7778_register_tmu(1);
 }
 
 #define INT2SMSKCR0	0x82288 /* 0xfe782288 */
-- 
1.7.9.5



From kuninori.morimoto.gx at renesas.com  Tue Apr  2 00:19:37 2013
From: kuninori.morimoto.gx at renesas.com (Kuninori Morimoto)
Date: Mon, 01 Apr 2013 21:19:37 -0700 (PDT)
Subject: [PATCH 2/5 v3] ARM: shmobile: r8a7778: add r8a7778_init_irq_extpin()
In-Reply-To: <87sj395zvv.wl%kuninori.morimoto.gx@renesas.com>
References: <87zjxvewko.wl%kuninori.morimoto.gx@renesas.com>
 <87fvzb56n3.wl%kuninori.morimoto.gx@renesas.com>
 <87sj395zvv.wl%kuninori.morimoto.gx@renesas.com>
Message-ID: <87ppyd5zu2.wl%kuninori.morimoto.gx@renesas.com>

This patch adds r8a7778_init_irq_extpin() for IRQ0 - IRQ3.
But this patch doesn't enable DT settings on r8a7778.dts,
because R8A7778 chip external IRQ depends on
IRQ0 - IRQ3 pin encoding which came from platform board
implementation.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
---
v2 -> v3

 - no change

 arch/arm/mach-shmobile/include/mach/r8a7778.h |    1 +
 arch/arm/mach-shmobile/setup-r8a7778.c        |   44 +++++++++++++++++++++++++
 2 files changed, 45 insertions(+)

diff --git a/arch/arm/mach-shmobile/include/mach/r8a7778.h b/arch/arm/mach-shmobile/include/mach/r8a7778.h
index a755dca..e0c6205 100644
--- a/arch/arm/mach-shmobile/include/mach/r8a7778.h
+++ b/arch/arm/mach-shmobile/include/mach/r8a7778.h
@@ -24,5 +24,6 @@ extern void r8a7778_init_delay(void);
 extern void r8a7778_init_irq(void);
 extern void r8a7778_init_irq_dt(void);
 extern void r8a7778_clock_init(void);
+extern void r8a7778_init_irq_extpin(int irlm);
 
 #endif /* __ASM_R8A7778_H__ */
diff --git a/arch/arm/mach-shmobile/setup-r8a7778.c b/arch/arm/mach-shmobile/setup-r8a7778.c
index 57d6b0e..2882305 100644
--- a/arch/arm/mach-shmobile/setup-r8a7778.c
+++ b/arch/arm/mach-shmobile/setup-r8a7778.c
@@ -23,6 +23,7 @@
 #include <linux/irqchip/arm-gic.h>
 #include <linux/of.h>
 #include <linux/of_platform.h>
+#include <linux/platform_data/irq-renesas-intc-irqpin.h>
 #include <linux/platform_device.h>
 #include <linux/irqchip.h>
 #include <linux/serial_sci.h>
@@ -110,6 +111,49 @@ void __init r8a7778_add_standard_devices(void)
 	r8a7778_register_tmu(1);
 }
 
+static struct renesas_intc_irqpin_config irqpin_platform_data = {
+	.irq_base = irq_pin(0), /* IRQ0 -> IRQ3 */
+	.sense_bitfield_width = 2,
+};
+
+static struct resource irqpin_resources[] = {
+	DEFINE_RES_MEM(0xfe78001c, 4), /* ICR1 */
+	DEFINE_RES_MEM(0xfe780010, 4), /* INTPRI */
+	DEFINE_RES_MEM(0xfe780024, 4), /* INTREQ */
+	DEFINE_RES_MEM(0xfe780044, 4), /* INTMSK0 */
+	DEFINE_RES_MEM(0xfe780064, 4), /* INTMSKCLR0 */
+	DEFINE_RES_IRQ(gic_iid(0x3b)), /* IRQ0 */
+	DEFINE_RES_IRQ(gic_iid(0x3c)), /* IRQ1 */
+	DEFINE_RES_IRQ(gic_iid(0x3d)), /* IRQ2 */
+	DEFINE_RES_IRQ(gic_iid(0x3e)), /* IRQ3 */
+};
+
+void __init r8a7778_init_irq_extpin(int irlm)
+{
+	void __iomem *icr0 = ioremap_nocache(0xfe780000, PAGE_SIZE);
+	unsigned long tmp;
+
+	if (!icr0) {
+		pr_warn("r8a7778: unable to setup external irq pin mode\n");
+		return;
+	}
+
+	tmp = ioread32(icr0);
+	if (irlm)
+		tmp |= 1 << 23; /* IRQ0 -> IRQ3 as individual pins */
+	else
+		tmp &= ~(1 << 23); /* IRL mode - not supported */
+	tmp |= (1 << 21); /* LVLMODE = 1 */
+	iowrite32(tmp, icr0);
+	iounmap(icr0);
+
+	if (irlm)
+		platform_device_register_resndata(
+			&platform_bus, "renesas_intc_irqpin", -1,
+			irqpin_resources, ARRAY_SIZE(irqpin_resources),
+			&irqpin_platform_data, sizeof(irqpin_platform_data));
+}
+
 #define INT2SMSKCR0	0x82288 /* 0xfe782288 */
 #define INT2SMSKCR1	0x8228c /* 0xfe78228c */
 
-- 
1.7.9.5



From kuninori.morimoto.gx at renesas.com  Tue Apr  2 00:20:02 2013
From: kuninori.morimoto.gx at renesas.com (Kuninori Morimoto)
Date: Mon, 01 Apr 2013 21:20:02 -0700 (PDT)
Subject: [PATCH 3/5 v3] ARM: shmobile: bockw: add SMSC ethernet support
In-Reply-To: <87sj395zvv.wl%kuninori.morimoto.gx@renesas.com>
References: <87zjxvewko.wl%kuninori.morimoto.gx@renesas.com>
 <87fvzb56n3.wl%kuninori.morimoto.gx@renesas.com>
 <87sj395zvv.wl%kuninori.morimoto.gx@renesas.com>
Message-ID: <87obdx5ztd.wl%kuninori.morimoto.gx@renesas.com>

This patch adds SMSC ethernet support on Bock-W

Bock-W SMSC needs FPGA settings which enables interrupt.
This patch does it on bockw_init() function.
As notes for future, this FPGA settings should be updated,
since this FPGA is using cascaded interrupt.
Current code is assuming that this FPGA interrupt user is only SMSC.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
---
v2 -> v3

 - C code only

 arch/arm/mach-shmobile/Kconfig       |    1 +
 arch/arm/mach-shmobile/board-bockw.c |   38 ++++++++++++++++++++++++++++++++++
 2 files changed, 39 insertions(+)

diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index 9125e14..b2219bd 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -119,6 +119,7 @@ config MACH_BOCKW
 	bool "BOCK-W platform"
 	depends on ARCH_R8A7778
 	select ARCH_REQUIRE_GPIOLIB
+	select RENESAS_INTC_IRQPIN
 	select USE_OF
 
 config MACH_MARZEN
diff --git a/arch/arm/mach-shmobile/board-bockw.c b/arch/arm/mach-shmobile/board-bockw.c
index 56ab56e..38e5e50 100644
--- a/arch/arm/mach-shmobile/board-bockw.c
+++ b/arch/arm/mach-shmobile/board-bockw.c
@@ -19,14 +19,52 @@
  */
 
 #include <linux/platform_device.h>
+#include <linux/smsc911x.h>
 #include <mach/common.h>
+#include <mach/irqs.h>
 #include <mach/r8a7778.h>
 #include <asm/mach/arch.h>
 
+static struct smsc911x_platform_config smsc911x_data = {
+	.irq_polarity	= SMSC911X_IRQ_POLARITY_ACTIVE_LOW,
+	.irq_type	= SMSC911X_IRQ_TYPE_PUSH_PULL,
+	.flags		= SMSC911X_USE_32BIT,
+	.phy_interface	= PHY_INTERFACE_MODE_MII,
+};
+
+static struct resource smsc911x_resources[] = {
+	DEFINE_RES_MEM(0x18300000, 0x1000),
+	DEFINE_RES_IRQ(irq_pin(0)), /* IRQ 0 */
+};
+
+#define IRQ0MR	0x30
 static void __init bockw_init(void)
 {
+	void __iomem *fpga;
+
 	r8a7778_clock_init();
+	r8a7778_init_irq_extpin(1);
 	r8a7778_add_standard_devices();
+
+	fpga = ioremap_nocache(0x18200000, SZ_1M);
+	if (fpga) {
+		/*
+		 * CAUTION
+		 *
+		 * IRQ0/1 is cascaded interrupt from FPGA.
+		 * it should be cared in the future
+		 * Now, it is assuming IRQ0 was used only from SMSC.
+		 */
+		u16 val = ioread16(fpga + IRQ0MR);
+		val &= ~(1 << 4); /* enable SMSC911x */
+		iowrite16(val, fpga + IRQ0MR);
+		iounmap(fpga);
+
+		platform_device_register_resndata(
+			&platform_bus, "smsc911x", -1,
+			smsc911x_resources, ARRAY_SIZE(smsc911x_resources),
+			&smsc911x_data, sizeof(smsc911x_data));
+	}
 }
 
 static const char *bockw_boards_compat_dt[] __initdata = {
-- 
1.7.9.5



From kuninori.morimoto.gx at renesas.com  Tue Apr  2 00:20:29 2013
From: kuninori.morimoto.gx at renesas.com (Kuninori Morimoto)
Date: Mon, 01 Apr 2013 21:20:29 -0700 (PDT)
Subject: [PATCH 4/5 v3] ARM: shmobile: bockw: enable network settings on
 bootargs
In-Reply-To: <87sj395zvv.wl%kuninori.morimoto.gx@renesas.com>
References: <87zjxvewko.wl%kuninori.morimoto.gx@renesas.com>
 <87fvzb56n3.wl%kuninori.morimoto.gx@renesas.com>
 <87sj395zvv.wl%kuninori.morimoto.gx@renesas.com>
Message-ID: <87mwth5zsm.wl%kuninori.morimoto.gx@renesas.com>

"ip" and "root" settings are useful for development

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
---
v2 -> v3

 - dts only

 arch/arm/boot/dts/r8a7778-bockw.dts |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/r8a7778-bockw.dts b/arch/arm/boot/dts/r8a7778-bockw.dts
index 735c964..0076b1e 100644
--- a/arch/arm/boot/dts/r8a7778-bockw.dts
+++ b/arch/arm/boot/dts/r8a7778-bockw.dts
@@ -22,7 +22,7 @@
 	compatible = "renesas,bockw", "renesas,r8a7778";
 
 	chosen {
-		bootargs = "console=ttySC0,115200 ignore_loglevel";
+		bootargs = "console=ttySC0,115200 ignore_loglevel ip=dhcp root=/dev/nfs";
 	};
 
 	memory {
-- 
1.7.9.5



From kuninori.morimoto.gx at renesas.com  Tue Apr  2 00:20:49 2013
From: kuninori.morimoto.gx at renesas.com (Kuninori Morimoto)
Date: Mon, 01 Apr 2013 21:20:49 -0700 (PDT)
Subject: [PATCH 5/5 v3] ARM: shmobile: bockw: enable SMSC ethernet on defconfig
In-Reply-To: <87sj395zvv.wl%kuninori.morimoto.gx@renesas.com>
References: <87zjxvewko.wl%kuninori.morimoto.gx@renesas.com>
 <87fvzb56n3.wl%kuninori.morimoto.gx@renesas.com>
 <87sj395zvv.wl%kuninori.morimoto.gx@renesas.com>
Message-ID: <87li915zs2.wl%kuninori.morimoto.gx@renesas.com>

This patch adds SMSC ethernet support on Bock-W defconfig

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
---
v2 -> v3

 - defconfig only

 arch/arm/configs/bockw_defconfig |   34 +++++++++++++++++++++++++++++++---
 1 file changed, 31 insertions(+), 3 deletions(-)

diff --git a/arch/arm/configs/bockw_defconfig b/arch/arm/configs/bockw_defconfig
index 6037705..6524cdf 100644
--- a/arch/arm/configs/bockw_defconfig
+++ b/arch/arm/configs/bockw_defconfig
@@ -27,16 +27,40 @@ CONFIG_HIGHMEM=y
 CONFIG_ZBOOT_ROM_TEXT=0x0
 CONFIG_ZBOOT_ROM_BSS=0x0
 CONFIG_ARM_APPENDED_DTB=y
-CONFIG_CMDLINE="console=ttySC0,115200 ignore_loglevel"
+CONFIG_CMDLINE="console=ttySC0,115200 ignore_loglevel root=/dev/nfs ip=dhcp"
 CONFIG_CMDLINE_FORCE=y
 # CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
 # CONFIG_SUSPEND is not set
+CONFIG_NET=y
+CONFIG_UNIX=y
+CONFIG_INET=y
+CONFIG_IP_PNP=y
+CONFIG_IP_PNP_DHCP=y
+# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
+# CONFIG_INET_XFRM_MODE_TUNNEL is not set
+# CONFIG_INET_XFRM_MODE_BEET is not set
+# CONFIG_INET_LRO is not set
+# CONFIG_INET_DIAG is not set
+# CONFIG_IPV6 is not set
 CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
 CONFIG_DEVTMPFS=y
 CONFIG_DEVTMPFS_MOUNT=y
 # CONFIG_STANDALONE is not set
 # CONFIG_PREVENT_FIRMWARE_BUILD is not set
 # CONFIG_FW_LOADER is not set
+CONFIG_NETDEVICES=y
+# CONFIG_NET_CADENCE is not set
+# CONFIG_NET_VENDOR_BROADCOM is not set
+# CONFIG_NET_VENDOR_CIRRUS is not set
+# CONFIG_NET_VENDOR_FARADAY is not set
+# CONFIG_NET_VENDOR_INTEL is not set
+# CONFIG_NET_VENDOR_MARVELL is not set
+# CONFIG_NET_VENDOR_MICREL is not set
+# CONFIG_NET_VENDOR_NATSEMI is not set
+# CONFIG_NET_VENDOR_SEEQ is not set
+CONFIG_SMSC911X=y
+# CONFIG_NET_VENDOR_STMICRO is not set
+# CONFIG_NET_VENDOR_WIZNET is not set
 # CONFIG_INPUT is not set
 # CONFIG_SERIO is not set
 # CONFIG_VT is not set
@@ -55,12 +79,16 @@ CONFIG_UIO_PDRV_GENIRQ=y
 # CONFIG_INOTIFY_USER is not set
 CONFIG_TMPFS=y
 # CONFIG_MISC_FILESYSTEMS is not set
+CONFIG_NFS_FS=y
+CONFIG_NFS_V3_ACL=y
+CONFIG_NFS_V4=y
+CONFIG_NFS_SWAP=y
+CONFIG_NFS_V4_1=y
+CONFIG_ROOT_NFS=y
 # CONFIG_ENABLE_WARN_DEPRECATED is not set
 # CONFIG_ENABLE_MUST_CHECK is not set
 # CONFIG_SCHED_DEBUG is not set
 # CONFIG_DEBUG_BUGVERBOSE is not set
 # CONFIG_FTRACE is not set
 # CONFIG_ARM_UNWIND is not set
-CONFIG_KEYS=y
-CONFIG_CRYPTO=y
 CONFIG_AVERAGE=y
-- 
1.7.9.5



From marex at denx.de  Tue Apr  2 00:22:52 2013
From: marex at denx.de (Marek Vasut)
Date: Tue, 2 Apr 2013 06:22:52 +0200
Subject: [PATCH 1/5] spi/mxs: Fix extra CS pulses and read mode in
 multi-transfer messages
In-Reply-To: <CA+7tXigx=qcDDJZGAx7JEX+Y-CDG-B0xyYgs6fHbUZofH7gnKw@mail.gmail.com>
References: <1364570381-17605-1-git-send-email-tpiepho@gmail.com>
 <201304020111.13969.marex@denx.de>
 <CA+7tXigx=qcDDJZGAx7JEX+Y-CDG-B0xyYgs6fHbUZofH7gnKw@mail.gmail.com>
Message-ID: <201304020622.52429.marex@denx.de>

Dear Trent Piepho,

> On Mon, Apr 1, 2013 at 4:11 PM, Marek Vasut <marex at denx.de> wrote:
> >> +#define TXRX_WRITE           1       /* This is a write */
> >> +#define TXRX_DEASSERT_CS     2       /* De-assert CS at end of txrx */
> > 
> > New flags? I'm sure the GCC can optimize function parameters pretty well,
> > esp. if you make the bool.
> 
> Nope.  I checked the actual compiled code.  Each bool takes another
> parameter.  Since the txrx functions are large and called from
> multiple sites, they are not inlined.  Gcc is not able to combine all
> the bool arguments into one single bitfield argument.

That's pretty poor, oh well.

btw. is it necessary to define new flags or is it possible to reuse some?

[...]

> >>       ctrl0 = readl(ssp->base + HW_SSP_CTRL0);
> >> 
> >> -     ctrl0 &= ~BM_SSP_CTRL0_XFER_COUNT;
> >> +     ctrl0 &= ~BM_SSP_CTRL0_XFER_COUNT & ~BM_SSP_CTRL0_IGNORE_CRC &
> >> +              ~BM_SSP_CTRL0_READ;
> > 
> > Well ... ctrl0 &= ~(FOO | BAR | BAZ); ... won't cut it?
> 
> Well, by De Morgan's law the two expressions are the same.  And they
> are the same number of characters.  And both will produce a compile
> time constant and thus the same code.  However, I like the ~FOO & ~BAR
> & ~BAR form better as there is greater parallelism between each term
> of the expression.

What about the law of readability of code ? ;-)

> >>       ctrl0 |= BM_SSP_CTRL0_DATA_XFER | mxs_spi_cs_to_reg(cs);
> >> 
> >> -     if (*first)
> >> -             ctrl0 |= BM_SSP_CTRL0_LOCK_CS;
> > 
> > The DMA will overwrite ctrl0 in each turn, did you try very long (>64kB
> > long) transfers with your adjustments? To test this, you can try
> > 
> > $ dd if=/dev/mtdN of=/dev/null bs=1M
> > 
> > on sufficiently large SPI flash supporting the FAST_READ opcode.
> 
> Don't have SPI flash.  I did test with logic analyzer and the current
> code is clearly broken and my changes clearly fix it.

Good, but you clearly didn't test it in the most used case. This will clearly 
piss off a lot of people if you break something. And this will clearly not be 
good ;-)

I'm clearly planning to test the code, but only once it's clearly possible to 
tell apart churn from the actual fix (see my other rambling, just reminding 
you). So I'll wait for V2 and give it a go on a large flash.

> It should be obvious from looking a the code that it is wrong.

Sorry, it is not obvious.

> The DMA does write
> ctrl0 on each segment of each transfer, but look at the previous
> paragraph to see where it comes from.  Once READ or IGNORE_CRC are
> set, nothing will clear them until PIO mode is used.

When using a flash, the DMA and PIO mode usage is intermixed. Usually, the PIO 
is used to program the command and then DMA to transmit the payload. It's hardly 
ever PIO only orr DMA only for the whole transfer.

> It's the same
> with the bug fix for 3.9 that clears the XFER_COUNT bits in DMA mode.
> Strangely, I didn't notice that bug since all my xfers are the same
> length!  But I do switch between slaves, between read and write, and
> use messages with multiple transfers, in DMA mode, all of which are
> broken in the current driver.

btw. are you using MX23 or MX28 to test this?

> >> +             if ((sg_count + 1 == sgs) && (flags & TXRX_DEASSERT_CS))
> >> 
> >>                       ctrl0 |= BM_SSP_CTRL0_IGNORE_CRC;
> >>               
> >>               if (ssp->devid == IMX23_SSP) {
> >> 
> >> @@ -279,7 +267,7 @@ static int mxs_spi_txrx_dma(struct mxs_spi *spi, int
> >> cs,
> >> 
> >>               sg_init_one(&dma_xfer[sg_count].sg, sg_buf, min);
> >>               ret = dma_map_sg(ssp->dev, &dma_xfer[sg_count].sg, 1,
> >> 
> >> -                     write ? DMA_TO_DEVICE : DMA_FROM_DEVICE);
> >> +                     (flags & TXRX_WRITE) ? DMA_TO_DEVICE :
> >> DMA_FROM_DEVICE);
> > 
> > I think this is unneeded.
> 
> Whatis ?  Setting the DMA direction or using flags?
> 
> Look at it this way:
> 
> Existing code that uses the first/last flags is wrong and needs to be
> changed.  Therefor code using 'first' and 'last' will be changed.
> 
> Passing the flags as pointers is bad practice and makes no sense to
> do.  Does it make any sense to re-write code fix the way it uses first
> and last, then re-write those same lines a second time to not use
> pointers?

You can always flip it the other way -- first rework the use of flags, then 
apply the fix. It'd make the patch much easier to understand, don't you think?

> If the way the flags are passed should change, then why not do it the
> most efficient way.  It isn't any more complicated and produces better
> code.  One flag per parameter becomes cumbersome when more flags are
> added for additional features.
> 
> I'm all for splitting my patches up.  I sent five patches when I bet 9
> out 10 developers would have just done one.  But I don't think it
> makes any sense to re-write the same line of code over and over again
> in successive patches in a series before getting to the final version.
>  It just makes more churn to review.

Splitting the patchset to make it more understandable is OK though. And I'm 
really getting lost in this patch.

> I hate it when I get a series of patches and spot a flaw, take the
> time to write up the flaw and how it should be fixed, only to discover
> that the flaw is fixed later on in the series and I wasted my time.

Best regards,
Marek Vasut


From horms+renesas at verge.net.au  Tue Apr  2 00:31:33 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue,  2 Apr 2013 13:31:33 +0900
Subject: [PATCH 2/3] ARM: shmobile: marzen: defconfig: enable GPIO LEDs driver
In-Reply-To: <1364877094-1508-1-git-send-email-horms+renesas@verge.net.au>
References: <1364877094-1508-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364877094-1508-3-git-send-email-horms+renesas@verge.net.au>

This enables the code added to the marzen board in
"ARM: shmobile: marzen: Add GPIO LEDs".

Acked-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/configs/marzen_defconfig |    3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/configs/marzen_defconfig b/arch/arm/configs/marzen_defconfig
index 9f65975..494e70a 100644
--- a/arch/arm/configs/marzen_defconfig
+++ b/arch/arm/configs/marzen_defconfig
@@ -93,6 +93,9 @@ CONFIG_USB_OHCI_HCD=y
 CONFIG_USB_OHCI_HCD_PLATFORM=y
 CONFIG_USB_EHCI_HCD_PLATFORM=y
 CONFIG_USB_STORAGE=y
+CONFIG_NEW_LEDS=y
+CONFIG_LEDS_CLASS=y
+CONFIG_LEDS_GPIO=y
 CONFIG_UIO=y
 CONFIG_UIO_PDRV_GENIRQ=y
 # CONFIG_IOMMU_SUPPORT is not set
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 00:31:32 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue,  2 Apr 2013 13:31:32 +0900
Subject: [PATCH 1/3] ARM: shmobile: marzen: defconfig: add GPIO RCAR driver
 support
In-Reply-To: <1364877094-1508-1-git-send-email-horms+renesas@verge.net.au>
References: <1364877094-1508-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364877094-1508-2-git-send-email-horms+renesas@verge.net.au>

This enables the driver added in "gpio: Renesas R-Car GPIO driver V3"

Cc: Magnus Damm <damm at opensource.se>
Acked-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/configs/marzen_defconfig |    1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/marzen_defconfig b/arch/arm/configs/marzen_defconfig
index 8e7329b..9f65975 100644
--- a/arch/arm/configs/marzen_defconfig
+++ b/arch/arm/configs/marzen_defconfig
@@ -79,6 +79,7 @@ CONFIG_I2C_RCAR=y
 CONFIG_SPI=y
 CONFIG_SPI_SH_HSPI=y
 CONFIG_GPIO_SYSFS=y
+CONFIG_GPIO_RCAR=y
 # CONFIG_HWMON is not set
 CONFIG_THERMAL=y
 CONFIG_RCAR_THERMAL=y
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 00:31:31 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue,  2 Apr 2013 13:31:31 +0900
Subject: [GIT PULL] Renesas ARM based SoC defconfig updates for v3.10 #2
Message-ID: <1364877094-1508-1-git-send-email-horms+renesas@verge.net.au>

Hi Arnd, Hi Olof,

The following changes since commit db30abdf3c07c564d4af0f991bb7f38b728f9035:

  ARM: mach-shmobile: marzen: add SATA support (2013-03-14 10:28:07 +0100)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-defconfig2-for-v3.10

for you to fetch changes up to 03d409a5c4f8b590caaebd8c99e8977227c3dee7:

  ARM: shmobile: ape6evm: add defconfig (2013-04-01 17:52:07 +0900)

----------------------------------------------------------------
Second round of Renesas ARM based SoC defconfig updates for v3.10

* Add defconfig for ape6evm board
* GPIO updates for marzen

----------------------------------------------------------------
Simon Horman (3):
      ARM: shmobile: marzen: defconfig: add GPIO RCAR driver support
      ARM: shmobile: marzen: defconfig: enable GPIO LEDs driver
      ARM: shmobile: ape6evm: add defconfig

 arch/arm/configs/ape6evm_defconfig |   95 ++++++++++++++++++++++++++++++++++++
 arch/arm/configs/marzen_defconfig  |    4 ++
 2 files changed, 99 insertions(+)
 create mode 100644 arch/arm/configs/ape6evm_defconfig


From horms+renesas at verge.net.au  Tue Apr  2 00:31:34 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue,  2 Apr 2013 13:31:34 +0900
Subject: [PATCH 3/3] ARM: shmobile: ape6evm: add defconfig
In-Reply-To: <1364877094-1508-1-git-send-email-horms+renesas@verge.net.au>
References: <1364877094-1508-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364877094-1508-4-git-send-email-horms+renesas@verge.net.au>

Add defconfig for ape6evm. This is based loosely
on the kzm9g defconfig with fewer devices enabled.

Acked-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/configs/ape6evm_defconfig |   95 ++++++++++++++++++++++++++++++++++++
 1 file changed, 95 insertions(+)
 create mode 100644 arch/arm/configs/ape6evm_defconfig

diff --git a/arch/arm/configs/ape6evm_defconfig b/arch/arm/configs/ape6evm_defconfig
new file mode 100644
index 0000000..dab5a7d
--- /dev/null
+++ b/arch/arm/configs/ape6evm_defconfig
@@ -0,0 +1,95 @@
+CONFIG_SYSVIPC=y
+CONFIG_POSIX_MQUEUE=y
+CONFIG_NO_HZ=y
+CONFIG_HIGH_RES_TIMERS=y
+CONFIG_BSD_PROCESS_ACCT=y
+CONFIG_IKCONFIG=y
+CONFIG_IKCONFIG_PROC=y
+CONFIG_LOG_BUF_SHIFT=16
+CONFIG_CGROUPS=y
+CONFIG_CGROUP_SCHED=y
+CONFIG_KALLSYMS_ALL=y
+CONFIG_EMBEDDED=y
+CONFIG_PERF_EVENTS=y
+CONFIG_SLAB=y
+# CONFIG_BLOCK is not set
+CONFIG_ARCH_SHMOBILE=y
+CONFIG_ARCH_R8A73A4=y
+CONFIG_MACH_APE6EVM=y
+# CONFIG_ARM_THUMB is not set
+CONFIG_CPU_BPREDICT_DISABLE=y
+CONFIG_PL310_ERRATA_588369=y
+CONFIG_ARM_ERRATA_754322=y
+CONFIG_SMP=y
+CONFIG_SCHED_MC=y
+CONFIG_HAVE_ARM_ARCH_TIMER=y
+CONFIG_NR_CPUS=8
+CONFIG_AEABI=y
+CONFIG_HIGHMEM=y
+CONFIG_HIGHPTE=y
+# CONFIG_HW_PERF_EVENTS is not set
+# CONFIG_COMPACTION is not set
+# CONFIG_CROSS_MEMORY_ATTACH is not set
+CONFIG_ARM_APPENDED_DTB=y
+CONFIG_VFP=y
+CONFIG_NEON=y
+CONFIG_BINFMT_MISC=y
+CONFIG_NET=y
+CONFIG_PACKET=y
+CONFIG_UNIX=y
+CONFIG_XFRM_USER=y
+CONFIG_NET_KEY=y
+CONFIG_NET_KEY_MIGRATE=y
+CONFIG_INET=y
+CONFIG_IP_MULTICAST=y
+CONFIG_IP_PNP=y
+CONFIG_IP_PNP_DHCP=y
+# CONFIG_INET_LRO is not set
+# CONFIG_IPV6_SIT is not set
+CONFIG_NETFILTER=y
+CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
+# CONFIG_FW_LOADER_USER_HELPER is not set
+CONFIG_NETDEVICES=y
+# CONFIG_NET_CADENCE is not set
+CONFIG_SMC91X=y
+CONFIG_SMSC911X=y
+# CONFIG_INPUT_MOUSEDEV is not set
+# CONFIG_INPUT_KEYBOARD is not set
+# CONFIG_INPUT_MOUSE is not set
+# CONFIG_SERIO is not set
+CONFIG_SERIAL_NONSTANDARD=y
+CONFIG_SERIAL_SH_SCI=y
+CONFIG_SERIAL_SH_SCI_NR_UARTS=12
+CONFIG_SERIAL_SH_SCI_CONSOLE=y
+CONFIG_GPIO_SH_PFC=y
+CONFIG_GPIOLIB=y
+# CONFIG_HWMON is not set
+CONFIG_THERMAL=y
+CONFIG_RCAR_THERMAL=y
+CONFIG_REGULATOR=y
+CONFIG_REGULATOR_FIXED_VOLTAGE=y
+CONFIG_REGULATOR_GPIO=y
+# CONFIG_HID is not set
+# CONFIG_USB_SUPPORT is not set
+# CONFIG_IOMMU_SUPPORT is not set
+# CONFIG_DNOTIFY is not set
+CONFIG_TMPFS=y
+# CONFIG_MISC_FILESYSTEMS is not set
+CONFIG_NFS_FS=y
+CONFIG_NFS_V3_ACL=y
+CONFIG_NFS_V4=y
+CONFIG_NFS_V4_1=y
+CONFIG_ROOT_NFS=y
+CONFIG_MAGIC_SYSRQ=y
+CONFIG_ENABLE_DEFAULT_TRACERS=y
+CONFIG_CRYPTO_CBC=y
+CONFIG_CRYPTO_ECB=y
+CONFIG_CRYPTO_MD5=y
+CONFIG_CRYPTO_MICHAEL_MIC=y
+CONFIG_CRYPTO_TWOFISH=y
+CONFIG_CRC_CCITT=y
+CONFIG_CRC16=y
+CONFIG_CRC_T10DIF=y
+CONFIG_CRC_ITU_T=y
+CONFIG_CRC7=y
+CONFIG_LIBCRC32C=y
-- 
1.7.10.4



From horms at verge.net.au  Tue Apr  2 00:33:37 2013
From: horms at verge.net.au (Simon Horman)
Date: Tue, 2 Apr 2013 13:33:37 +0900
Subject: [PATCH] ARM: shmobile: r8a7790 SoC 64-bit DT support
In-Reply-To: <20130329074917.15695.92956.sendpatchset@w520>
References: <20130329074917.15695.92956.sendpatchset@w520>
Message-ID: <20130402043337.GD1696@verge.net.au>

On Fri, Mar 29, 2013 at 04:49:17PM +0900, Magnus Damm wrote:
> From: Takashi Yoshii <takashi.yoshii.zj at renesas.com>
> 
> The r8a7790 SoC supports LPAE and has memory window up to
> 0x2ffffffff. Convert to 64-bit addresses by enlarging
> #addr-cells and #size-cells to 2.
> 
> Signed-off-by: Takashi Yoshii <takashi.yoshii.zj at renesas.com>
> Signed-off-by: Magnus Damm <damm at opensource.se>

Thanks, queued up for v3.10 in the soc branch.


From horms at verge.net.au  Tue Apr  2 00:33:52 2013
From: horms at verge.net.au (Simon Horman)
Date: Tue, 2 Apr 2013 13:33:52 +0900
Subject: [PATCH 00/04 v2] ARM: shmobile: r8a7790 SoC
In-Reply-To: <20130327154925.10876.40575.sendpatchset@w520>
References: <20130327154925.10876.40575.sendpatchset@w520>
Message-ID: <20130402043351.GE1696@verge.net.au>

On Thu, Mar 28, 2013 at 12:49:25AM +0900, Magnus Damm wrote:
> ARM: shmobile: r8a7790 SoC (V2)
> 
> [PATCH 01/04] ARM: shmobile: Initial r8a7790 SoC support
> [PATCH 02/04] ARM: shmobile: r8a7790 SCIF support
> [PATCH 03/04] ARM: shmobile: r8a7790 IRQC support
> [PATCH 04/04] ARM: shmobile: r8a7790 PFC support
> 
> This series is V2 of initial support for the r8a7790 SoC. The SoC
> is known as r8a7790 which is built around Cortex-A15 and makes use
> of SCIF for serial and IRQC interrupt controller for external IRQs.
> 
> Changes in V2:
> - Added PFC platform device
> 
> Future r8a7790 PFC and Lager board series will depend on this one.

Thanks, queued up for v3.10 in the soc branch.


From horms at verge.net.au  Tue Apr  2 00:34:15 2013
From: horms at verge.net.au (Simon Horman)
Date: Tue, 2 Apr 2013 13:34:15 +0900
Subject: [PATCH v2] ARM: shmobile: Initial r8a7790 Lager board support
In-Reply-To: <20130329084937.16365.8698.sendpatchset@w520>
References: <20130329084937.16365.8698.sendpatchset@w520>
Message-ID: <20130402043414.GF1696@verge.net.au>

On Fri, Mar 29, 2013 at 05:49:37PM +0900, Magnus Damm wrote:
> From: Magnus Damm <damm at opensource.se>
> 
> Lager base board support making use of 2 GiB of memory,
> the r8a7790 SoC with the SCIF0 serial port and CA15 with
> ARM architected timer.

Thanks, queued up for v3.10 in the boards branch.


From linux at prisktech.co.nz  Tue Apr  2 00:39:06 2013
From: linux at prisktech.co.nz (Tony Prisk)
Date: Tue,  2 Apr 2013 17:39:06 +1300
Subject: [PATCHv4 2/6] arm: vt8500: Increase available GPIOs on arch-vt8500
In-Reply-To: <1364877550-25921-1-git-send-email-linux@prisktech.co.nz>
References: <1364877550-25921-1-git-send-email-linux@prisktech.co.nz>
Message-ID: <1364877550-25921-3-git-send-email-linux@prisktech.co.nz>

With the inclusion of the pin control driver, more GPIO pins have been
identified on the arch-vt8500 SoCs requiring an increase in the available
GPIOs.

Signed-off-by: Tony Prisk <linux at prisktech.co.nz>
---
 arch/arm/Kconfig |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 13b7394..244c618 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1661,7 +1661,8 @@ config ARCH_NR_GPIO
 	default 1024 if ARCH_SHMOBILE || ARCH_TEGRA
 	default 512 if SOC_OMAP5
 	default 355 if ARCH_U8500
-	default 288 if ARCH_VT8500 || ARCH_SUNXI
+	default 352 if ARCH_VT8500
+	default 288 if ARCH_SUNXI
 	default 264 if MACH_H4700
 	default 0
 	help
-- 
1.7.9.5



From linux at prisktech.co.nz  Tue Apr  2 00:39:08 2013
From: linux at prisktech.co.nz (Tony Prisk)
Date: Tue,  2 Apr 2013 17:39:08 +1300
Subject: [PATCHv4 4/6] arm: dts: vt8500: Update Wondermedia SoC dtsi files for
 pinctrl driver
In-Reply-To: <1364877550-25921-1-git-send-email-linux@prisktech.co.nz>
References: <1364877550-25921-1-git-send-email-linux@prisktech.co.nz>
Message-ID: <1364877550-25921-5-git-send-email-linux@prisktech.co.nz>

This patch adds pinctrl nodes to the VIA VT8500 and Wondermedia SoC dtsi
files to support the pinctrl driver.

Signed-off-by: Tony Prisk <linux at prisktech.co.nz>
---
 arch/arm/boot/dts/vt8500.dtsi |    9 +++++++++
 arch/arm/boot/dts/wm8505.dtsi |    9 +++++++++
 arch/arm/boot/dts/wm8650.dtsi |    9 +++++++++
 arch/arm/boot/dts/wm8850.dtsi |    9 +++++++++
 4 files changed, 36 insertions(+)

diff --git a/arch/arm/boot/dts/vt8500.dtsi b/arch/arm/boot/dts/vt8500.dtsi
index cf31ced..8e87aa9 100644
--- a/arch/arm/boot/dts/vt8500.dtsi
+++ b/arch/arm/boot/dts/vt8500.dtsi
@@ -32,6 +32,15 @@
 			#gpio-cells = <3>;
 		};
 
+		pinctrl: pinctrl at d8110000 {
+			compatible = "via,vt8500-pinctrl";
+			reg = <0xd8110000 0x10000>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			gpio-controller;
+			#gpio-cells = <2>;
+		};
+
 		pmc at d8130000 {
 			compatible = "via,vt8500-pmc";
 			reg = <0xd8130000 0x1000>;
diff --git a/arch/arm/boot/dts/wm8505.dtsi b/arch/arm/boot/dts/wm8505.dtsi
index e74a1c0..e4f768a 100644
--- a/arch/arm/boot/dts/wm8505.dtsi
+++ b/arch/arm/boot/dts/wm8505.dtsi
@@ -47,6 +47,15 @@
 			#gpio-cells = <3>;
 		};
 
+		pinctrl: pinctrl at d8110000 {
+			compatible = "wm,wm8505-pinctrl";
+			reg = <0xd8110000 0x10000>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			gpio-controller;
+			#gpio-cells = <2>;
+		};
+
 		pmc at d8130000 {
 			compatible = "via,vt8500-pmc";
 			reg = <0xd8130000 0x1000>;
diff --git a/arch/arm/boot/dts/wm8650.dtsi b/arch/arm/boot/dts/wm8650.dtsi
index db3c0a1..01b6a8d 100644
--- a/arch/arm/boot/dts/wm8650.dtsi
+++ b/arch/arm/boot/dts/wm8650.dtsi
@@ -41,6 +41,15 @@
 			#gpio-cells = <3>;
 		};
 
+		pinctrl: pinctrl at d8110000 {
+			compatible = "wm,wm8650-pinctrl";
+			reg = <0xd8110000 0x10000>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			gpio-controller;
+			#gpio-cells = <2>;
+		};
+
 		pmc at d8130000 {
 			compatible = "via,vt8500-pmc";
 			reg = <0xd8130000 0x1000>;
diff --git a/arch/arm/boot/dts/wm8850.dtsi b/arch/arm/boot/dts/wm8850.dtsi
index e8cbfdc..297aa05 100644
--- a/arch/arm/boot/dts/wm8850.dtsi
+++ b/arch/arm/boot/dts/wm8850.dtsi
@@ -48,6 +48,15 @@
 			#gpio-cells = <3>;
 		};
 
+		pinctrl: pinctrl at d8110000 {
+			compatible = "wm,wm8850-pinctrl";
+			reg = <0xd8110000 0x10000>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			gpio-controller;
+			#gpio-cells = <2>;
+		};
+
 		pmc at d8130000 {
 			compatible = "via,vt8500-pmc";
 			reg = <0xd8130000 0x1000>;
-- 
1.7.9.5



From linux at prisktech.co.nz  Tue Apr  2 00:39:05 2013
From: linux at prisktech.co.nz (Tony Prisk)
Date: Tue,  2 Apr 2013 17:39:05 +1300
Subject: [PATCHv4 1/6] of: Add support for reading a u32 from a multi-value
 property.
In-Reply-To: <1364877550-25921-1-git-send-email-linux@prisktech.co.nz>
References: <1364877550-25921-1-git-send-email-linux@prisktech.co.nz>
Message-ID: <1364877550-25921-2-git-send-email-linux@prisktech.co.nz>

This patch adds an of_property_read_u32_index() function to allow
reading a single indexed u32 value from a property containing multiple
u32 values.

Signed-off-by: Tony Prisk <linux at prisktech.co.nz>
Reviewed-by: Stephen Warren <swarren at nvidia.com>
---
 drivers/of/base.c  |   33 +++++++++++++++++++++++++++++++++
 include/linux/of.h |    9 +++++++++
 2 files changed, 42 insertions(+)

diff --git a/drivers/of/base.c b/drivers/of/base.c
index 321d3ef..f6c89ed 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -746,6 +746,39 @@ struct device_node *of_find_node_by_phandle(phandle handle)
 EXPORT_SYMBOL(of_find_node_by_phandle);
 
 /**
+ * of_property_read_u32_index - Find and read a u32 from a multi-value property.
+ *
+ * @np:		device node from which the property value is to be read.
+ * @propname:	name of the property to be searched.
+ * @index:	index of the u32 in the list of values
+ * @out_value:	pointer to return value, modified only if no error.
+ *
+ * Search for a property in a device node and read nth 32-bit value from
+ * it. Returns 0 on success, -EINVAL if the property does not exist,
+ * -ENODATA if property does not have a value, and -EOVERFLOW if the
+ * property data isn't large enough.
+ *
+ * The out_value is modified only if a valid u32 value can be decoded.
+ */
+int of_property_read_u32_index(const struct device_node *np,
+				       const char *propname,
+				       u32 index, u32 *out_value)
+{
+	struct property *prop = of_find_property(np, propname, NULL);
+
+	if (!prop)
+		return -EINVAL;
+	if (!prop->value)
+		return -ENODATA;
+	if (((index + 1) * sizeof(*out_value)) > prop->length)
+		return -EOVERFLOW;
+
+	*out_value = be32_to_cpup(((__be32 *)prop->value) + index);
+	return 0;
+}
+EXPORT_SYMBOL_GPL(of_property_read_u32_index);
+
+/**
  * of_property_read_u8_array - Find and read an array of u8 from a property.
  *
  * @np:		device node from which the property value is to be read.
diff --git a/include/linux/of.h b/include/linux/of.h
index a0f1292..c0747a4 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -235,6 +235,9 @@ extern struct device_node *of_find_node_with_property(
 extern struct property *of_find_property(const struct device_node *np,
 					 const char *name,
 					 int *lenp);
+extern int of_property_read_u32_index(const struct device_node *np,
+				       const char *propname,
+				       u32 index, u32 *out_value);
 extern int of_property_read_u8_array(const struct device_node *np,
 			const char *propname, u8 *out_values, size_t sz);
 extern int of_property_read_u16_array(const struct device_node *np,
@@ -394,6 +397,12 @@ static inline struct device_node *of_find_compatible_node(
 	return NULL;
 }
 
+static inline int of_property_read_u32_index(const struct device_node *np,
+			const char *propname, u32 index, u32 *out_value)
+{
+	return -ENOSYS;
+}
+
 static inline int of_property_read_u8_array(const struct device_node *np,
 			const char *propname, u8 *out_values, size_t sz)
 {
-- 
1.7.9.5



From linux at prisktech.co.nz  Tue Apr  2 00:39:04 2013
From: linux at prisktech.co.nz (Tony Prisk)
Date: Tue,  2 Apr 2013 17:39:04 +1300
Subject: [PATCHv4 0/6] arm: vt8500: Add support for pinctrl/gpio module
Message-ID: <1364877550-25921-1-git-send-email-linux@prisktech.co.nz>

v4 changes:
Changed as requested by Stephen Warren:
Corrected the range checking in of_property_read_u32_index().
Fix configs[0] assignment in wmt_pctl_dt_node_to_map_pull().
Remove the kfree(maps) call, and use devm_kzalloc to simplify the fail path.
Drop the custom .of_xlate function and use the default of_gpio_simple_xlate.
Move the platform memory mapping from per-soc to common init.

v3 changes:
Rebased onto v3.9-rc4
Added the missing interrupt-controller info to the relevant dtsi files.
Removed the gpio-vt8500.txt binding along with the gpio driver.

Changes made as requested by Linux Walleij:
Removed the wm,pinmux property which has caused too much confusion, and left the
	open-coded version in arm/arch-vt8500/vt8500.c until a proper solution
	is sorted out.

Changes made as requested by Stephen Warren:
Defined an active-low flag for gpio since its useful and we will have a use-case
	for it with our LCD power-on/off.

v2 changes:
Rebased onto v3.9-rc2

Changes made as requested by Linus Walleij:
Moved the files into drivers/pinctrl/vt8500/ to keep them tidy.
Changed readl/writel to *_relaxed variants.
Comment indentation corrected and remove additional whitespace.
Changed wmt_pctl_find_group_by_pin() error code from -1 to -EINVAL.
Removed OF read indexed-u32 function to OF subsystem.
General code tidy up as requested.

Changes made as requested by Stephen Warren:
Add binding information for interrupt generation.
Move optional properties to correct location in document.


This patch series removes the existing GPIO driver and replaces it with
a combined pinctrl+gpio driver.

Patch 1 - Add an OF function to read the nth u32 value from a property
  listing multiple values.

Patch 2 - Increase the available GPIO space for the newly added gpios.
  Because there is no hardware documentation from Wondermedia we don't know
  how many GPIO's there actually are. New gpio pins have been located since
  the original GPIO driver was written, hence the increase.

Patch 3 - The main pinctrl/gpio driver and the data for the 5 supported SoCs.
  Each SoC is different, and therefore has its own data. This design was
  borrowed from the Tegra pinctrl driver. The pin numbering is based on a
  bank+pin encoding so that when other pin functions are found later on we can
  add them without having to renumber existing pins.

Patch 4 - Update the SoC dts(i) files to support the new pinctrl driver.

Patch 5 - Remove the existing GPIO driver nodes from the dtsi's.

Patch 6 - Remove the existing GPIO driver.

I suspect this series may need to be broken up since there are two arm-soc
patches, and 4 pinctrl/gpio patches.

Patch 1 is required for the new driver to function properly.
Patch 2 is independant, but required for the driver to function properly.
Patches 3-4 are pinctrl/gpio patches.
Patch 5-6 remove the old gpio code which is no longer required.


Patch 2 could go via arm-soc if necessary.

Regards
Tony Prisk

Tony Prisk (6):
  of: Add support for reading a u32 from a multi-value property.
  arm: vt8500: Increase available GPIOs on arch-vt8500
  pinctrl: gpio: vt8500: Add pincontrol driver for arch-vt8500
  arm: dts: vt8500: Update Wondermedia SoC dtsi files for pinctrl
    driver
  arm: vt8500: Remove gpio devicetree nodes
  gpio: vt8500: Remove arch-vt8500 gpio driver

 .../devicetree/bindings/gpio/gpio-vt8500.txt       |   24 -
 .../devicetree/bindings/pinctrl/pinctrl-vt8500.txt |   57 ++
 arch/arm/Kconfig                                   |    3 +-
 arch/arm/boot/dts/vt8500.dtsi                      |   10 +-
 arch/arm/boot/dts/wm8505.dtsi                      |   10 +-
 arch/arm/boot/dts/wm8650.dtsi                      |   10 +-
 arch/arm/boot/dts/wm8850.dtsi                      |   10 +-
 arch/arm/mach-vt8500/Kconfig                       |    1 +
 drivers/gpio/Kconfig                               |    6 -
 drivers/gpio/Makefile                              |    1 -
 drivers/gpio/gpio-vt8500.c                         |  355 -----------
 drivers/of/base.c                                  |   33 ++
 drivers/pinctrl/Kconfig                            |    1 +
 drivers/pinctrl/Makefile                           |    1 +
 drivers/pinctrl/vt8500/Kconfig                     |   52 ++
 drivers/pinctrl/vt8500/Makefile                    |    8 +
 drivers/pinctrl/vt8500/pinctrl-vt8500.c            |  501 ++++++++++++++++
 drivers/pinctrl/vt8500/pinctrl-wm8505.c            |  532 +++++++++++++++++
 drivers/pinctrl/vt8500/pinctrl-wm8650.c            |  370 ++++++++++++
 drivers/pinctrl/vt8500/pinctrl-wm8750.c            |  409 +++++++++++++
 drivers/pinctrl/vt8500/pinctrl-wm8850.c            |  388 ++++++++++++
 drivers/pinctrl/vt8500/pinctrl-wmt.c               |  620 ++++++++++++++++++++
 drivers/pinctrl/vt8500/pinctrl-wmt.h               |   79 +++
 include/linux/of.h                                 |    9 +
 24 files changed, 3087 insertions(+), 403 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/gpio/gpio-vt8500.txt
 create mode 100644 Documentation/devicetree/bindings/pinctrl/pinctrl-vt8500.txt
 delete mode 100644 drivers/gpio/gpio-vt8500.c
 create mode 100644 drivers/pinctrl/vt8500/Kconfig
 create mode 100644 drivers/pinctrl/vt8500/Makefile
 create mode 100644 drivers/pinctrl/vt8500/pinctrl-vt8500.c
 create mode 100644 drivers/pinctrl/vt8500/pinctrl-wm8505.c
 create mode 100644 drivers/pinctrl/vt8500/pinctrl-wm8650.c
 create mode 100644 drivers/pinctrl/vt8500/pinctrl-wm8750.c
 create mode 100644 drivers/pinctrl/vt8500/pinctrl-wm8850.c
 create mode 100644 drivers/pinctrl/vt8500/pinctrl-wmt.c
 create mode 100644 drivers/pinctrl/vt8500/pinctrl-wmt.h

-- 
1.7.9.5



From linux at prisktech.co.nz  Tue Apr  2 00:39:09 2013
From: linux at prisktech.co.nz (Tony Prisk)
Date: Tue,  2 Apr 2013 17:39:09 +1300
Subject: [PATCHv4 5/6] arm: vt8500: Remove gpio devicetree nodes
In-Reply-To: <1364877550-25921-1-git-send-email-linux@prisktech.co.nz>
References: <1364877550-25921-1-git-send-email-linux@prisktech.co.nz>
Message-ID: <1364877550-25921-6-git-send-email-linux@prisktech.co.nz>

Remove the gpio related devicetree nodes as these are no longer required
with the move to a combined pinctrl/gpio driver.

Signed-off-by: Tony Prisk <linux at prisktech.co.nz>
---
 arch/arm/boot/dts/vt8500.dtsi |    7 -------
 arch/arm/boot/dts/wm8505.dtsi |    7 -------
 arch/arm/boot/dts/wm8650.dtsi |    7 -------
 arch/arm/boot/dts/wm8850.dtsi |    7 -------
 4 files changed, 28 deletions(-)

diff --git a/arch/arm/boot/dts/vt8500.dtsi b/arch/arm/boot/dts/vt8500.dtsi
index 8e87aa9..e1c3926 100644
--- a/arch/arm/boot/dts/vt8500.dtsi
+++ b/arch/arm/boot/dts/vt8500.dtsi
@@ -25,13 +25,6 @@
 			#interrupt-cells = <1>;
 		};
 
-		gpio: gpio-controller at d8110000 {
-			compatible = "via,vt8500-gpio";
-			gpio-controller;
-			reg = <0xd8110000 0x10000>;
-			#gpio-cells = <3>;
-		};
-
 		pinctrl: pinctrl at d8110000 {
 			compatible = "via,vt8500-pinctrl";
 			reg = <0xd8110000 0x10000>;
diff --git a/arch/arm/boot/dts/wm8505.dtsi b/arch/arm/boot/dts/wm8505.dtsi
index e4f768a..bb92ef8 100644
--- a/arch/arm/boot/dts/wm8505.dtsi
+++ b/arch/arm/boot/dts/wm8505.dtsi
@@ -40,13 +40,6 @@
 			interrupts = <56 57 58 59 60 61 62 63>;
 		};
 
-		gpio: gpio-controller at d8110000 {
-			compatible = "wm,wm8505-gpio";
-			gpio-controller;
-			reg = <0xd8110000 0x10000>;
-			#gpio-cells = <3>;
-		};
-
 		pinctrl: pinctrl at d8110000 {
 			compatible = "wm,wm8505-pinctrl";
 			reg = <0xd8110000 0x10000>;
diff --git a/arch/arm/boot/dts/wm8650.dtsi b/arch/arm/boot/dts/wm8650.dtsi
index 01b6a8d..bb4af58 100644
--- a/arch/arm/boot/dts/wm8650.dtsi
+++ b/arch/arm/boot/dts/wm8650.dtsi
@@ -34,13 +34,6 @@
 			interrupts = <56 57 58 59 60 61 62 63>;
 		};
 
-		gpio: gpio-controller at d8110000 {
-			compatible = "wm,wm8650-gpio";
-			gpio-controller;
-			reg = <0xd8110000 0x10000>;
-			#gpio-cells = <3>;
-		};
-
 		pinctrl: pinctrl at d8110000 {
 			compatible = "wm,wm8650-pinctrl";
 			reg = <0xd8110000 0x10000>;
diff --git a/arch/arm/boot/dts/wm8850.dtsi b/arch/arm/boot/dts/wm8850.dtsi
index 297aa05..11cd180 100644
--- a/arch/arm/boot/dts/wm8850.dtsi
+++ b/arch/arm/boot/dts/wm8850.dtsi
@@ -41,13 +41,6 @@
 			interrupts = <56 57 58 59 60 61 62 63>;
 		};
 
-		gpio: gpio-controller at d8110000 {
-			compatible = "wm,wm8650-gpio";
-			gpio-controller;
-			reg = <0xd8110000 0x10000>;
-			#gpio-cells = <3>;
-		};
-
 		pinctrl: pinctrl at d8110000 {
 			compatible = "wm,wm8850-pinctrl";
 			reg = <0xd8110000 0x10000>;
-- 
1.7.9.5



From linux at prisktech.co.nz  Tue Apr  2 00:39:10 2013
From: linux at prisktech.co.nz (Tony Prisk)
Date: Tue,  2 Apr 2013 17:39:10 +1300
Subject: [PATCHv4 6/6] gpio: vt8500: Remove arch-vt8500 gpio driver
In-Reply-To: <1364877550-25921-1-git-send-email-linux@prisktech.co.nz>
References: <1364877550-25921-1-git-send-email-linux@prisktech.co.nz>
Message-ID: <1364877550-25921-7-git-send-email-linux@prisktech.co.nz>

With the move to a combined pinctrl/gpio driver, the arch-vt8500
gpio driver is no longer required.

Signed-off-by: Tony Prisk <linux at prisktech.co.nz>
---
 .../devicetree/bindings/gpio/gpio-vt8500.txt       |   24 --
 drivers/gpio/Kconfig                               |    6 -
 drivers/gpio/Makefile                              |    1 -
 drivers/gpio/gpio-vt8500.c                         |  355 --------------------
 4 files changed, 386 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/gpio/gpio-vt8500.txt
 delete mode 100644 drivers/gpio/gpio-vt8500.c

diff --git a/Documentation/devicetree/bindings/gpio/gpio-vt8500.txt b/Documentation/devicetree/bindings/gpio/gpio-vt8500.txt
deleted file mode 100644
index f4dc523..0000000
--- a/Documentation/devicetree/bindings/gpio/gpio-vt8500.txt
+++ /dev/null
@@ -1,24 +0,0 @@
-VIA/Wondermedia VT8500 GPIO Controller
------------------------------------------------------
-
-Required properties:
-- compatible : "via,vt8500-gpio", "wm,wm8505-gpio"
-	or "wm,wm8650-gpio" depending on your SoC
-- reg : Should contain 1 register range (address and length)
-- #gpio-cells : should be <3>.
-	1) bank
-	2) pin number
-	3) flags - should be 0
-
-Example:
-
-	gpio: gpio-controller at d8110000 {
-		compatible = "via,vt8500-gpio";
-		gpio-controller;
-		reg = <0xd8110000 0x10000>;
-		#gpio-cells = <3>;
-	};
-
-	vibrate {
-		gpios = <&gpio 0 1 0>; /* Bank 0, Pin 1, No flags */
-	};
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 93aaadf..b166e30 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -227,12 +227,6 @@ config GPIO_TS5500
 	  blocks of the TS-5500: DIO1, DIO2 and the LCD port, and the TS-5600
 	  LCD port.
 
-config GPIO_VT8500
-	bool "VIA/Wondermedia SoC GPIO Support"
-	depends on ARCH_VT8500
-	help
-	  Say yes here to support the VT8500/WM8505/WM8650 GPIO controller.
-
 config GPIO_XILINX
 	bool "Xilinx GPIO support"
 	depends on PPC_OF || MICROBLAZE
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 22e07bc..a274d7d 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -80,7 +80,6 @@ obj-$(CONFIG_GPIO_TWL6040)	+= gpio-twl6040.o
 obj-$(CONFIG_GPIO_UCB1400)	+= gpio-ucb1400.o
 obj-$(CONFIG_GPIO_VIPERBOARD)	+= gpio-viperboard.o
 obj-$(CONFIG_GPIO_VR41XX)	+= gpio-vr41xx.o
-obj-$(CONFIG_GPIO_VT8500)	+= gpio-vt8500.o
 obj-$(CONFIG_GPIO_VX855)	+= gpio-vx855.o
 obj-$(CONFIG_GPIO_WM831X)	+= gpio-wm831x.o
 obj-$(CONFIG_GPIO_WM8350)	+= gpio-wm8350.o
diff --git a/drivers/gpio/gpio-vt8500.c b/drivers/gpio/gpio-vt8500.c
deleted file mode 100644
index 81683ca..0000000
--- a/drivers/gpio/gpio-vt8500.c
+++ /dev/null
@@ -1,355 +0,0 @@
-/* drivers/gpio/gpio-vt8500.c
- *
- * Copyright (C) 2012 Tony Prisk <linux at prisktech.co.nz>
- * Based on arch/arm/mach-vt8500/gpio.c:
- * - Copyright (C) 2010 Alexey Charkov <alchark at gmail.com>
- *
- * This software is licensed under the terms of the GNU General Public
- * License version 2, as published by the Free Software Foundation, and
- * may be copied, distributed, and modified under those terms.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- */
-
-#include <linux/module.h>
-#include <linux/err.h>
-#include <linux/io.h>
-#include <linux/gpio.h>
-#include <linux/platform_device.h>
-#include <linux/bitops.h>
-#include <linux/of.h>
-#include <linux/of_address.h>
-#include <linux/of_irq.h>
-#include <linux/of_device.h>
-
-/*
-	We handle GPIOs by bank, each bank containing up to 32 GPIOs covered
-	by one set of registers (although not all may be valid).
-
-	Because different SoC's have different register offsets, we pass the
-	register offsets as data in vt8500_gpio_dt_ids[].
-
-	A value of NO_REG is used to indicate that this register is not
-	supported. Only used for ->en at the moment.
-*/
-
-#define NO_REG	0xFFFF
-
-/*
- * struct vt8500_gpio_bank_regoffsets
- * @en: offset to enable register of the bank
- * @dir: offset to direction register of the bank
- * @data_out: offset to the data out register of the bank
- * @data_in: offset to the data in register of the bank
- * @ngpio: highest valid pin in this bank
- */
-
-struct vt8500_gpio_bank_regoffsets {
-	unsigned int	en;
-	unsigned int	dir;
-	unsigned int	data_out;
-	unsigned int	data_in;
-	unsigned char	ngpio;
-};
-
-struct vt8500_gpio_data {
-	unsigned int				num_banks;
-	struct vt8500_gpio_bank_regoffsets	banks[];
-};
-
-#define VT8500_BANK(__en, __dir, __out, __in, __ngpio)		\
-{								\
-	.en = __en,						\
-	.dir = __dir,						\
-	.data_out = __out,					\
-	.data_in = __in,					\
-	.ngpio = __ngpio,					\
-}
-
-static struct vt8500_gpio_data vt8500_data = {
-	.num_banks	= 7,
-	.banks	= {
-		VT8500_BANK(NO_REG, 0x3C, 0x5C, 0x7C, 9),
-		VT8500_BANK(0x00, 0x20, 0x40, 0x60, 26),
-		VT8500_BANK(0x04, 0x24, 0x44, 0x64, 28),
-		VT8500_BANK(0x08, 0x28, 0x48, 0x68, 31),
-		VT8500_BANK(0x0C, 0x2C, 0x4C, 0x6C, 19),
-		VT8500_BANK(0x10, 0x30, 0x50, 0x70, 19),
-		VT8500_BANK(0x14, 0x34, 0x54, 0x74, 23),
-	},
-};
-
-static struct vt8500_gpio_data wm8505_data = {
-	.num_banks	= 10,
-	.banks	= {
-		VT8500_BANK(0x64, 0x8C, 0xB4, 0xDC, 22),
-		VT8500_BANK(0x40, 0x68, 0x90, 0xB8, 8),
-		VT8500_BANK(0x44, 0x6C, 0x94, 0xBC, 32),
-		VT8500_BANK(0x48, 0x70, 0x98, 0xC0, 6),
-		VT8500_BANK(0x4C, 0x74, 0x9C, 0xC4, 16),
-		VT8500_BANK(0x50, 0x78, 0xA0, 0xC8, 25),
-		VT8500_BANK(0x54, 0x7C, 0xA4, 0xCC, 5),
-		VT8500_BANK(0x58, 0x80, 0xA8, 0xD0, 5),
-		VT8500_BANK(0x5C, 0x84, 0xAC, 0xD4, 12),
-		VT8500_BANK(0x60, 0x88, 0xB0, 0xD8, 16),
-		VT8500_BANK(0x500, 0x504, 0x508, 0x50C, 6),
-	},
-};
-
-/*
- * No information about which bits are valid so we just make
- * them all available until its figured out.
- */
-static struct vt8500_gpio_data wm8650_data = {
-	.num_banks	= 9,
-	.banks	= {
-		VT8500_BANK(0x40, 0x80, 0xC0, 0x00, 32),
-		VT8500_BANK(0x44, 0x84, 0xC4, 0x04, 32),
-		VT8500_BANK(0x48, 0x88, 0xC8, 0x08, 32),
-		VT8500_BANK(0x4C, 0x8C, 0xCC, 0x0C, 32),
-		VT8500_BANK(0x50, 0x90, 0xD0, 0x10, 32),
-		VT8500_BANK(0x54, 0x94, 0xD4, 0x14, 32),
-		VT8500_BANK(0x58, 0x98, 0xD8, 0x18, 32),
-		VT8500_BANK(0x5C, 0x9C, 0xDC, 0x1C, 32),
-		VT8500_BANK(0x7C, 0xBC, 0xFC, 0x3C, 32),
-		VT8500_BANK(0x500, 0x504, 0x508, 0x50C, 6),
-	},
-};
-
-struct vt8500_gpio_chip {
-	struct gpio_chip		chip;
-
-	const struct vt8500_gpio_bank_regoffsets *regs;
-	void __iomem	*base;
-};
-
-struct vt8500_data {
-	struct vt8500_gpio_chip *chip;
-	void __iomem *iobase;
-	int num_banks;
-};
-
-
-#define to_vt8500(__chip) container_of(__chip, struct vt8500_gpio_chip, chip)
-
-static int vt8500_gpio_request(struct gpio_chip *chip, unsigned offset)
-{
-	u32 val;
-	struct vt8500_gpio_chip *vt8500_chip = to_vt8500(chip);
-
-	if (vt8500_chip->regs->en == NO_REG)
-		return 0;
-
-	val = readl_relaxed(vt8500_chip->base + vt8500_chip->regs->en);
-	val |= BIT(offset);
-	writel_relaxed(val, vt8500_chip->base + vt8500_chip->regs->en);
-
-	return 0;
-}
-
-static void vt8500_gpio_free(struct gpio_chip *chip, unsigned offset)
-{
-	struct vt8500_gpio_chip *vt8500_chip = to_vt8500(chip);
-	u32 val;
-
-	if (vt8500_chip->regs->en == NO_REG)
-		return;
-
-	val = readl_relaxed(vt8500_chip->base + vt8500_chip->regs->en);
-	val &= ~BIT(offset);
-	writel_relaxed(val, vt8500_chip->base + vt8500_chip->regs->en);
-}
-
-static int vt8500_gpio_direction_input(struct gpio_chip *chip, unsigned offset)
-{
-	struct vt8500_gpio_chip *vt8500_chip = to_vt8500(chip);
-
-	u32 val = readl_relaxed(vt8500_chip->base + vt8500_chip->regs->dir);
-	val &= ~BIT(offset);
-	writel_relaxed(val, vt8500_chip->base + vt8500_chip->regs->dir);
-
-	return 0;
-}
-
-static int vt8500_gpio_direction_output(struct gpio_chip *chip, unsigned offset,
-								int value)
-{
-	struct vt8500_gpio_chip *vt8500_chip = to_vt8500(chip);
-
-	u32 val = readl_relaxed(vt8500_chip->base + vt8500_chip->regs->dir);
-	val |= BIT(offset);
-	writel_relaxed(val, vt8500_chip->base + vt8500_chip->regs->dir);
-
-	if (value) {
-		val = readl_relaxed(vt8500_chip->base +
-						vt8500_chip->regs->data_out);
-		val |= BIT(offset);
-		writel_relaxed(val, vt8500_chip->base +
-						vt8500_chip->regs->data_out);
-	}
-	return 0;
-}
-
-static int vt8500_gpio_get_value(struct gpio_chip *chip, unsigned offset)
-{
-	struct vt8500_gpio_chip *vt8500_chip = to_vt8500(chip);
-
-	return (readl_relaxed(vt8500_chip->base + vt8500_chip->regs->data_in) >>
-								offset) & 1;
-}
-
-static void vt8500_gpio_set_value(struct gpio_chip *chip, unsigned offset,
-								int value)
-{
-	struct vt8500_gpio_chip *vt8500_chip = to_vt8500(chip);
-
-	u32 val = readl_relaxed(vt8500_chip->base +
-						vt8500_chip->regs->data_out);
-	if (value)
-		val |= BIT(offset);
-	else
-		val &= ~BIT(offset);
-
-	writel_relaxed(val, vt8500_chip->base + vt8500_chip->regs->data_out);
-}
-
-static int vt8500_of_xlate(struct gpio_chip *gc,
-			    const struct of_phandle_args *gpiospec, u32 *flags)
-{
-	/* bank if specificed in gpiospec->args[0] */
-	if (flags)
-		*flags = gpiospec->args[2];
-
-	return gpiospec->args[1];
-}
-
-static int vt8500_add_chips(struct platform_device *pdev, void __iomem *base,
-				const struct vt8500_gpio_data *data)
-{
-	struct vt8500_data *priv;
-	struct vt8500_gpio_chip *vtchip;
-	struct gpio_chip *chip;
-	int i;
-	int pin_cnt = 0;
-
-	priv = devm_kzalloc(&pdev->dev, sizeof(struct vt8500_data), GFP_KERNEL);
-	if (!priv) {
-		dev_err(&pdev->dev, "failed to allocate memory\n");
-		return -ENOMEM;
-	}
-
-	priv->chip = devm_kzalloc(&pdev->dev,
-			sizeof(struct vt8500_gpio_chip) * data->num_banks,
-			GFP_KERNEL);
-	if (!priv->chip) {
-		dev_err(&pdev->dev, "failed to allocate chip memory\n");
-		return -ENOMEM;
-	}
-
-	priv->iobase = base;
-	priv->num_banks = data->num_banks;
-	platform_set_drvdata(pdev, priv);
-
-	vtchip = priv->chip;
-
-	for (i = 0; i < data->num_banks; i++) {
-		vtchip[i].base = base;
-		vtchip[i].regs = &data->banks[i];
-
-		chip = &vtchip[i].chip;
-
-		chip->of_xlate = vt8500_of_xlate;
-		chip->of_gpio_n_cells = 3;
-		chip->of_node = pdev->dev.of_node;
-
-		chip->request = vt8500_gpio_request;
-		chip->free = vt8500_gpio_free;
-		chip->direction_input = vt8500_gpio_direction_input;
-		chip->direction_output = vt8500_gpio_direction_output;
-		chip->get = vt8500_gpio_get_value;
-		chip->set = vt8500_gpio_set_value;
-		chip->can_sleep = 0;
-		chip->base = pin_cnt;
-		chip->ngpio = data->banks[i].ngpio;
-
-		pin_cnt += data->banks[i].ngpio;
-
-		gpiochip_add(chip);
-	}
-	return 0;
-}
-
-static struct of_device_id vt8500_gpio_dt_ids[] = {
-	{ .compatible = "via,vt8500-gpio", .data = &vt8500_data, },
-	{ .compatible = "wm,wm8505-gpio", .data = &wm8505_data, },
-	{ .compatible = "wm,wm8650-gpio", .data = &wm8650_data, },
-	{ /* Sentinel */ },
-};
-
-static int vt8500_gpio_probe(struct platform_device *pdev)
-{
-	int ret;
-	void __iomem *gpio_base;
-	struct resource *res;
-	const struct of_device_id *of_id =
-				of_match_device(vt8500_gpio_dt_ids, &pdev->dev);
-
-	if (!of_id) {
-		dev_err(&pdev->dev, "No matching driver data\n");
-		return -ENODEV;
-	}
-
-	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-	if (!res) {
-		dev_err(&pdev->dev, "Unable to get IO resource\n");
-		return -ENODEV;
-	}
-
-	gpio_base = devm_request_and_ioremap(&pdev->dev, res);
-	if (!gpio_base) {
-		dev_err(&pdev->dev, "Unable to map GPIO registers\n");
-		return -ENOMEM;
-	}
-
-	ret = vt8500_add_chips(pdev, gpio_base, of_id->data);
-
-	return ret;
-}
-
-static int vt8500_gpio_remove(struct platform_device *pdev)
-{
-	int i;
-	int ret;
-	struct vt8500_data *priv = platform_get_drvdata(pdev);
-	struct vt8500_gpio_chip *vtchip = priv->chip;
-
-	for (i = 0; i < priv->num_banks; i++) {
-		ret = gpiochip_remove(&vtchip[i].chip);
-		if (ret)
-			dev_warn(&pdev->dev, "gpiochip_remove returned %d\n",
-				 ret);
-	}
-
-	return 0;
-}
-
-static struct platform_driver vt8500_gpio_driver = {
-	.probe		= vt8500_gpio_probe,
-	.remove		= vt8500_gpio_remove,
-	.driver		= {
-		.name	= "vt8500-gpio",
-		.owner	= THIS_MODULE,
-		.of_match_table = vt8500_gpio_dt_ids,
-	},
-};
-
-module_platform_driver(vt8500_gpio_driver);
-
-MODULE_DESCRIPTION("VT8500 GPIO Driver");
-MODULE_AUTHOR("Tony Prisk <linux at prisktech.co.nz>");
-MODULE_LICENSE("GPL v2");
-MODULE_DEVICE_TABLE(of, vt8500_gpio_dt_ids);
-- 
1.7.9.5



From linux at prisktech.co.nz  Tue Apr  2 00:39:07 2013
From: linux at prisktech.co.nz (Tony Prisk)
Date: Tue,  2 Apr 2013 17:39:07 +1300
Subject: [PATCHv4 3/6] pinctrl: gpio: vt8500: Add pincontrol driver for
 arch-vt8500
In-Reply-To: <1364877550-25921-1-git-send-email-linux@prisktech.co.nz>
References: <1364877550-25921-1-git-send-email-linux@prisktech.co.nz>
Message-ID: <1364877550-25921-4-git-send-email-linux@prisktech.co.nz>

This patch adds support for the GPIO/pinmux controller found on the VIA
VT8500 and Wondermedia WM8xxx-series SoCs.

Each pin within the controller is capable of operating as a GPIO or as
an alternate function. The pins are numbered according to their control
bank/bit so that if new pins are added, the existing numbering is maintained.

All currently supported SoCs are included: VT8500, WM8505, WM8650, WM8750 and
WM8850.

Signed-off-by: Tony Prisk <linux at prisktech.co.nz>
Reviewed-by: Stephen Warren <swarren at nvidia.com>
---
 .../devicetree/bindings/pinctrl/pinctrl-vt8500.txt |   57 ++
 arch/arm/mach-vt8500/Kconfig                       |    1 +
 drivers/pinctrl/Kconfig                            |    1 +
 drivers/pinctrl/Makefile                           |    1 +
 drivers/pinctrl/vt8500/Kconfig                     |   52 ++
 drivers/pinctrl/vt8500/Makefile                    |    8 +
 drivers/pinctrl/vt8500/pinctrl-vt8500.c            |  501 ++++++++++++++++
 drivers/pinctrl/vt8500/pinctrl-wm8505.c            |  532 +++++++++++++++++
 drivers/pinctrl/vt8500/pinctrl-wm8650.c            |  370 ++++++++++++
 drivers/pinctrl/vt8500/pinctrl-wm8750.c            |  409 +++++++++++++
 drivers/pinctrl/vt8500/pinctrl-wm8850.c            |  388 ++++++++++++
 drivers/pinctrl/vt8500/pinctrl-wmt.c               |  620 ++++++++++++++++++++
 drivers/pinctrl/vt8500/pinctrl-wmt.h               |   79 +++
 13 files changed, 3019 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pinctrl/pinctrl-vt8500.txt
 create mode 100644 drivers/pinctrl/vt8500/Kconfig
 create mode 100644 drivers/pinctrl/vt8500/Makefile
 create mode 100644 drivers/pinctrl/vt8500/pinctrl-vt8500.c
 create mode 100644 drivers/pinctrl/vt8500/pinctrl-wm8505.c
 create mode 100644 drivers/pinctrl/vt8500/pinctrl-wm8650.c
 create mode 100644 drivers/pinctrl/vt8500/pinctrl-wm8750.c
 create mode 100644 drivers/pinctrl/vt8500/pinctrl-wm8850.c
 create mode 100644 drivers/pinctrl/vt8500/pinctrl-wmt.c
 create mode 100644 drivers/pinctrl/vt8500/pinctrl-wmt.h

diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-vt8500.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-vt8500.txt
new file mode 100644
index 0000000..b3aa90f
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-vt8500.txt
@@ -0,0 +1,57 @@
+VIA VT8500 and Wondermedia WM8xxx-series pinmux/gpio controller
+
+These SoCs contain a combined Pinmux/GPIO module. Each pin may operate as
+either a GPIO in, GPIO out or as an alternate function (I2C, SPI etc).
+
+Required properties:
+- compatible: "via,vt8500-pinctrl", "wm,wm8505-pinctrl", "wm,wm8650-pinctrl",
+	"wm8750-pinctrl" or "wm,wm8850-pinctrl"
+- reg: Should contain the physical address of the module's registers.
+- interrupt-controller: Marks the device node as an interrupt controller.
+- #interrupt-cells: Should be two.
+- gpio-controller: Marks the device node as a GPIO controller.
+- #gpio-cells : Should be two. The first cell is the pin number and the
+  second cell is used to specify optional parameters.
+	bit 0 - active low
+
+Please refer to ../gpio/gpio.txt for a general description of GPIO bindings.
+
+Please refer to pinctrl-bindings.txt in this directory for details of the
+common pinctrl bindings used by client devices, including the meaning of the
+phrase "pin configuration node".
+
+Each pin configuration node lists the pin(s) to which it applies, and one or
+more of the mux functions to select on those pin(s), and pull-up/down
+configuration. Each subnode only affects those parameters that are explicitly
+listed. In other words, a subnode that lists only a mux function implies no
+information about any pull configuration. Similarly, a subnode that lists only
+a pull parameter implies no information about the mux function.
+
+Required subnode-properties:
+- wm,pins: An array of cells. Each cell contains the ID of a pin.
+
+Optional subnode-properties:
+- wm,function: Integer, containing the function to mux to the pin(s):
+  0: GPIO in
+  1: GPIO out
+  2: alternate
+
+- wm,pull: Integer, representing the pull-down/up to apply to the pin(s):
+  0: none
+  1: down
+  2: up
+
+Each of wm,function and wm,pull may contain either a single value which
+will be applied to all pins in wm,pins, or one value for each entry in
+wm,pins.
+
+Example:
+
+	pinctrl: pinctrl {
+		compatible = "wm,wm8505-pinctrl";
+		reg = <0xD8110000 0x10000>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
diff --git a/arch/arm/mach-vt8500/Kconfig b/arch/arm/mach-vt8500/Kconfig
index e3e94b2..9b25293 100644
--- a/arch/arm/mach-vt8500/Kconfig
+++ b/arch/arm/mach-vt8500/Kconfig
@@ -7,6 +7,7 @@ config ARCH_VT8500
 	select GENERIC_CLOCKEVENTS
 	select HAVE_CLK
 	select VT8500_TIMER
+	select PINCTRL
 	help
 	  Support for VIA/WonderMedia VT8500/WM85xx System-on-Chip.
 
diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index 34f51d2..35e9400 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -229,6 +229,7 @@ config PINCTRL_EXYNOS5440
 source "drivers/pinctrl/mvebu/Kconfig"
 source "drivers/pinctrl/sh-pfc/Kconfig"
 source "drivers/pinctrl/spear/Kconfig"
+source "drivers/pinctrl/vt8500/Kconfig"
 
 config PINCTRL_XWAY
 	bool
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index f82cc5b..a5a52c8 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -52,3 +52,4 @@ obj-$(CONFIG_PLAT_ORION)        += mvebu/
 obj-$(CONFIG_ARCH_SHMOBILE)	+= sh-pfc/
 obj-$(CONFIG_SUPERH)		+= sh-pfc/
 obj-$(CONFIG_PLAT_SPEAR)	+= spear/
+obj-$(CONFIG_ARCH_VT8500)	+= vt8500/
diff --git a/drivers/pinctrl/vt8500/Kconfig b/drivers/pinctrl/vt8500/Kconfig
new file mode 100644
index 0000000..55724a7
--- /dev/null
+++ b/drivers/pinctrl/vt8500/Kconfig
@@ -0,0 +1,52 @@
+#
+# VIA/Wondermedia PINCTRL drivers
+#
+
+if ARCH_VT8500
+
+config PINCTRL_WMT
+	bool
+	select PINMUX
+	select GENERIC_PINCONF
+
+config PINCTRL_VT8500
+	bool "VIA VT8500 pin controller driver"
+	depends on ARCH_WM8505
+	select PINCTRL_WMT
+	help
+	  Say yes here to support the gpio/pin control module on
+	  VIA VT8500 SoCs.
+
+config PINCTRL_WM8505
+	bool "Wondermedia WM8505 pin controller driver"
+	depends on ARCH_WM8505
+	select PINCTRL_WMT
+	help
+	  Say yes here to support the gpio/pin control module on
+	  Wondermedia WM8505 SoCs.
+
+config PINCTRL_WM8650
+	bool "Wondermedia WM8650 pin controller driver"
+	depends on ARCH_WM8505
+	select PINCTRL_WMT
+	help
+	  Say yes here to support the gpio/pin control module on
+	  Wondermedia WM8650 SoCs.
+
+config PINCTRL_WM8750
+	bool "Wondermedia WM8750 pin controller driver"
+	depends on ARCH_WM8750
+	select PINCTRL_WMT
+	help
+	  Say yes here to support the gpio/pin control module on
+	  Wondermedia WM8750 SoCs.
+
+config PINCTRL_WM8850
+	bool "Wondermedia WM8850 pin controller driver"
+	depends on ARCH_WM8850
+	select PINCTRL_WMT
+	help
+	  Say yes here to support the gpio/pin control module on
+	  Wondermedia WM8850 SoCs.
+
+endif
diff --git a/drivers/pinctrl/vt8500/Makefile b/drivers/pinctrl/vt8500/Makefile
new file mode 100644
index 0000000..24ec45d
--- /dev/null
+++ b/drivers/pinctrl/vt8500/Makefile
@@ -0,0 +1,8 @@
+# VIA/Wondermedia pinctrl support
+
+obj-$(CONFIG_PINCTRL_WMT)	+= pinctrl-wmt.o
+obj-$(CONFIG_PINCTRL_VT8500)	+= pinctrl-vt8500.o
+obj-$(CONFIG_PINCTRL_WM8505)	+= pinctrl-wm8505.o
+obj-$(CONFIG_PINCTRL_WM8650)	+= pinctrl-wm8650.o
+obj-$(CONFIG_PINCTRL_WM8750)	+= pinctrl-wm8750.o
+obj-$(CONFIG_PINCTRL_WM8850)	+= pinctrl-wm8850.o
diff --git a/drivers/pinctrl/vt8500/pinctrl-vt8500.c b/drivers/pinctrl/vt8500/pinctrl-vt8500.c
new file mode 100644
index 0000000..f2fe9f8
--- /dev/null
+++ b/drivers/pinctrl/vt8500/pinctrl-vt8500.c
@@ -0,0 +1,501 @@
+/*
+ * Pinctrl data for VIA VT8500 SoC
+ *
+ * Copyright (c) 2013 Tony Prisk <linux at prisktech.co.nz>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ */
+
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/pinctrl/pinctrl.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+
+#include "pinctrl-wmt.h"
+
+/*
+ * Describe the register offsets within the GPIO memory space
+ * The dedicated external GPIO's should always be listed in bank 0
+ * so they are exported in the 0..31 range which is what users
+ * expect.
+ *
+ * Do not reorder these banks as it will change the pin numbering
+ */
+static const struct wmt_pinctrl_bank_registers vt8500_banks[] = {
+	WMT_PINCTRL_BANK(NO_REG, 0x3C, 0x5C, 0x7C, NO_REG, NO_REG),	/* 0 */
+	WMT_PINCTRL_BANK(0x00, 0x20, 0x40, 0x60, NO_REG, NO_REG),	/* 1 */
+	WMT_PINCTRL_BANK(0x04, 0x24, 0x44, 0x64, NO_REG, NO_REG),	/* 2 */
+	WMT_PINCTRL_BANK(0x08, 0x28, 0x48, 0x68, NO_REG, NO_REG),	/* 3 */
+	WMT_PINCTRL_BANK(0x0C, 0x2C, 0x4C, 0x6C, NO_REG, NO_REG),	/* 4 */
+	WMT_PINCTRL_BANK(0x10, 0x30, 0x50, 0x70, NO_REG, NO_REG),	/* 5 */
+	WMT_PINCTRL_BANK(0x14, 0x34, 0x54, 0x74, NO_REG, NO_REG),	/* 6 */
+};
+
+/* Please keep sorted by bank/bit */
+#define WMT_PIN_EXTGPIO0	WMT_PIN(0, 0)
+#define WMT_PIN_EXTGPIO1	WMT_PIN(0, 1)
+#define WMT_PIN_EXTGPIO2	WMT_PIN(0, 2)
+#define WMT_PIN_EXTGPIO3	WMT_PIN(0, 3)
+#define WMT_PIN_EXTGPIO4	WMT_PIN(0, 4)
+#define WMT_PIN_EXTGPIO5	WMT_PIN(0, 5)
+#define WMT_PIN_EXTGPIO6	WMT_PIN(0, 6)
+#define WMT_PIN_EXTGPIO7	WMT_PIN(0, 7)
+#define WMT_PIN_EXTGPIO8	WMT_PIN(0, 8)
+#define WMT_PIN_UART0RTS	WMT_PIN(1, 0)
+#define WMT_PIN_UART0TXD	WMT_PIN(1, 1)
+#define WMT_PIN_UART0CTS	WMT_PIN(1, 2)
+#define WMT_PIN_UART0RXD	WMT_PIN(1, 3)
+#define WMT_PIN_UART1RTS	WMT_PIN(1, 4)
+#define WMT_PIN_UART1TXD	WMT_PIN(1, 5)
+#define WMT_PIN_UART1CTS	WMT_PIN(1, 6)
+#define WMT_PIN_UART1RXD	WMT_PIN(1, 7)
+#define WMT_PIN_SPI0CLK		WMT_PIN(1, 8)
+#define WMT_PIN_SPI0SS		WMT_PIN(1, 9)
+#define WMT_PIN_SPI0MISO	WMT_PIN(1, 10)
+#define WMT_PIN_SPI0MOSI	WMT_PIN(1, 11)
+#define WMT_PIN_SPI1CLK		WMT_PIN(1, 12)
+#define WMT_PIN_SPI1SS		WMT_PIN(1, 13)
+#define WMT_PIN_SPI1MISO	WMT_PIN(1, 14)
+#define WMT_PIN_SPI1MOSI	WMT_PIN(1, 15)
+#define WMT_PIN_SPI2CLK		WMT_PIN(1, 16)
+#define WMT_PIN_SPI2SS		WMT_PIN(1, 17)
+#define WMT_PIN_SPI2MISO	WMT_PIN(1, 18)
+#define WMT_PIN_SPI2MOSI	WMT_PIN(1, 19)
+#define WMT_PIN_SDDATA0		WMT_PIN(2, 0)
+#define WMT_PIN_SDDATA1		WMT_PIN(2, 1)
+#define WMT_PIN_SDDATA2		WMT_PIN(2, 2)
+#define WMT_PIN_SDDATA3		WMT_PIN(2, 3)
+#define WMT_PIN_MMCDATA0	WMT_PIN(2, 4)
+#define WMT_PIN_MMCDATA1	WMT_PIN(2, 5)
+#define WMT_PIN_MMCDATA2	WMT_PIN(2, 6)
+#define WMT_PIN_MMCDATA3	WMT_PIN(2, 7)
+#define WMT_PIN_SDCLK		WMT_PIN(2, 8)
+#define WMT_PIN_SDWP		WMT_PIN(2, 9)
+#define WMT_PIN_SDCMD		WMT_PIN(2, 10)
+#define WMT_PIN_MSDATA0		WMT_PIN(2, 16)
+#define WMT_PIN_MSDATA1		WMT_PIN(2, 17)
+#define WMT_PIN_MSDATA2		WMT_PIN(2, 18)
+#define WMT_PIN_MSDATA3		WMT_PIN(2, 19)
+#define WMT_PIN_MSCLK		WMT_PIN(2, 20)
+#define WMT_PIN_MSBS		WMT_PIN(2, 21)
+#define WMT_PIN_MSINS		WMT_PIN(2, 22)
+#define WMT_PIN_I2C0SCL		WMT_PIN(2, 24)
+#define WMT_PIN_I2C0SDA		WMT_PIN(2, 25)
+#define WMT_PIN_I2C1SCL		WMT_PIN(2, 26)
+#define WMT_PIN_I2C1SDA		WMT_PIN(2, 27)
+#define WMT_PIN_MII0RXD0	WMT_PIN(3, 0)
+#define WMT_PIN_MII0RXD1	WMT_PIN(3, 1)
+#define WMT_PIN_MII0RXD2	WMT_PIN(3, 2)
+#define WMT_PIN_MII0RXD3	WMT_PIN(3, 3)
+#define WMT_PIN_MII0RXCLK	WMT_PIN(3, 4)
+#define WMT_PIN_MII0RXDV	WMT_PIN(3, 5)
+#define WMT_PIN_MII0RXERR	WMT_PIN(3, 6)
+#define WMT_PIN_MII0PHYRST	WMT_PIN(3, 7)
+#define WMT_PIN_MII0TXD0	WMT_PIN(3, 8)
+#define WMT_PIN_MII0TXD1	WMT_PIN(3, 9)
+#define WMT_PIN_MII0TXD2	WMT_PIN(3, 10)
+#define WMT_PIN_MII0TXD3	WMT_PIN(3, 11)
+#define WMT_PIN_MII0TXCLK	WMT_PIN(3, 12)
+#define WMT_PIN_MII0TXEN	WMT_PIN(3, 13)
+#define WMT_PIN_MII0TXERR	WMT_PIN(3, 14)
+#define WMT_PIN_MII0PHYPD	WMT_PIN(3, 15)
+#define WMT_PIN_MII0COL		WMT_PIN(3, 16)
+#define WMT_PIN_MII0CRS		WMT_PIN(3, 17)
+#define WMT_PIN_MII0MDIO	WMT_PIN(3, 18)
+#define WMT_PIN_MII0MDC		WMT_PIN(3, 19)
+#define WMT_PIN_SEECS		WMT_PIN(3, 20)
+#define WMT_PIN_SEECK		WMT_PIN(3, 21)
+#define WMT_PIN_SEEDI		WMT_PIN(3, 22)
+#define WMT_PIN_SEEDO		WMT_PIN(3, 23)
+#define WMT_PIN_IDEDREQ0	WMT_PIN(3, 24)
+#define WMT_PIN_IDEDREQ1	WMT_PIN(3, 25)
+#define WMT_PIN_IDEIOW		WMT_PIN(3, 26)
+#define WMT_PIN_IDEIOR		WMT_PIN(3, 27)
+#define WMT_PIN_IDEDACK		WMT_PIN(3, 28)
+#define WMT_PIN_IDEIORDY	WMT_PIN(3, 29)
+#define WMT_PIN_IDEINTRQ	WMT_PIN(3, 30)
+#define WMT_PIN_VDIN0		WMT_PIN(4, 0)
+#define WMT_PIN_VDIN1		WMT_PIN(4, 1)
+#define WMT_PIN_VDIN2		WMT_PIN(4, 2)
+#define WMT_PIN_VDIN3		WMT_PIN(4, 3)
+#define WMT_PIN_VDIN4		WMT_PIN(4, 4)
+#define WMT_PIN_VDIN5		WMT_PIN(4, 5)
+#define WMT_PIN_VDIN6		WMT_PIN(4, 6)
+#define WMT_PIN_VDIN7		WMT_PIN(4, 7)
+#define WMT_PIN_VDOUT0		WMT_PIN(4, 8)
+#define WMT_PIN_VDOUT1		WMT_PIN(4, 9)
+#define WMT_PIN_VDOUT2		WMT_PIN(4, 10)
+#define WMT_PIN_VDOUT3		WMT_PIN(4, 11)
+#define WMT_PIN_VDOUT4		WMT_PIN(4, 12)
+#define WMT_PIN_VDOUT5		WMT_PIN(4, 13)
+#define WMT_PIN_NANDCLE0	WMT_PIN(4, 14)
+#define WMT_PIN_NANDCLE1	WMT_PIN(4, 15)
+#define WMT_PIN_VDOUT6_7	WMT_PIN(4, 16)
+#define WMT_PIN_VHSYNC		WMT_PIN(4, 17)
+#define WMT_PIN_VVSYNC		WMT_PIN(4, 18)
+#define WMT_PIN_TSDIN0		WMT_PIN(5, 8)
+#define WMT_PIN_TSDIN1		WMT_PIN(5, 9)
+#define WMT_PIN_TSDIN2		WMT_PIN(5, 10)
+#define WMT_PIN_TSDIN3		WMT_PIN(5, 11)
+#define WMT_PIN_TSDIN4		WMT_PIN(5, 12)
+#define WMT_PIN_TSDIN5		WMT_PIN(5, 13)
+#define WMT_PIN_TSDIN6		WMT_PIN(5, 14)
+#define WMT_PIN_TSDIN7		WMT_PIN(5, 15)
+#define WMT_PIN_TSSYNC		WMT_PIN(5, 16)
+#define WMT_PIN_TSVALID		WMT_PIN(5, 17)
+#define WMT_PIN_TSCLK		WMT_PIN(5, 18)
+#define WMT_PIN_LCDD0		WMT_PIN(6, 0)
+#define WMT_PIN_LCDD1		WMT_PIN(6, 1)
+#define WMT_PIN_LCDD2		WMT_PIN(6, 2)
+#define WMT_PIN_LCDD3		WMT_PIN(6, 3)
+#define WMT_PIN_LCDD4		WMT_PIN(6, 4)
+#define WMT_PIN_LCDD5		WMT_PIN(6, 5)
+#define WMT_PIN_LCDD6		WMT_PIN(6, 6)
+#define WMT_PIN_LCDD7		WMT_PIN(6, 7)
+#define WMT_PIN_LCDD8		WMT_PIN(6, 8)
+#define WMT_PIN_LCDD9		WMT_PIN(6, 9)
+#define WMT_PIN_LCDD10		WMT_PIN(6, 10)
+#define WMT_PIN_LCDD11		WMT_PIN(6, 11)
+#define WMT_PIN_LCDD12		WMT_PIN(6, 12)
+#define WMT_PIN_LCDD13		WMT_PIN(6, 13)
+#define WMT_PIN_LCDD14		WMT_PIN(6, 14)
+#define WMT_PIN_LCDD15		WMT_PIN(6, 15)
+#define WMT_PIN_LCDD16		WMT_PIN(6, 16)
+#define WMT_PIN_LCDD17		WMT_PIN(6, 17)
+#define WMT_PIN_LCDCLK		WMT_PIN(6, 18)
+#define WMT_PIN_LCDDEN		WMT_PIN(6, 19)
+#define WMT_PIN_LCDLINE		WMT_PIN(6, 20)
+#define WMT_PIN_LCDFRM		WMT_PIN(6, 21)
+#define WMT_PIN_LCDBIAS		WMT_PIN(6, 22)
+
+static const struct pinctrl_pin_desc vt8500_pins[] = {
+	PINCTRL_PIN(WMT_PIN_EXTGPIO0, "extgpio0"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO1, "extgpio1"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO2, "extgpio2"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO3, "extgpio3"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO4, "extgpio4"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO5, "extgpio5"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO6, "extgpio6"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO7, "extgpio7"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO8, "extgpio8"),
+	PINCTRL_PIN(WMT_PIN_UART0RTS, "uart0_rts"),
+	PINCTRL_PIN(WMT_PIN_UART0TXD, "uart0_txd"),
+	PINCTRL_PIN(WMT_PIN_UART0CTS, "uart0_cts"),
+	PINCTRL_PIN(WMT_PIN_UART0RXD, "uart0_rxd"),
+	PINCTRL_PIN(WMT_PIN_UART1RTS, "uart1_rts"),
+	PINCTRL_PIN(WMT_PIN_UART1TXD, "uart1_txd"),
+	PINCTRL_PIN(WMT_PIN_UART1CTS, "uart1_cts"),
+	PINCTRL_PIN(WMT_PIN_UART1RXD, "uart1_rxd"),
+	PINCTRL_PIN(WMT_PIN_SPI0CLK, "spi0_clk"),
+	PINCTRL_PIN(WMT_PIN_SPI0SS, "spi0_ss"),
+	PINCTRL_PIN(WMT_PIN_SPI0MISO, "spi0_miso"),
+	PINCTRL_PIN(WMT_PIN_SPI0MOSI, "spi0_mosi"),
+	PINCTRL_PIN(WMT_PIN_SPI1CLK, "spi1_clk"),
+	PINCTRL_PIN(WMT_PIN_SPI1SS, "spi1_ss"),
+	PINCTRL_PIN(WMT_PIN_SPI1MISO, "spi1_miso"),
+	PINCTRL_PIN(WMT_PIN_SPI1MOSI, "spi1_mosi"),
+	PINCTRL_PIN(WMT_PIN_SPI2CLK, "spi2_clk"),
+	PINCTRL_PIN(WMT_PIN_SPI2SS, "spi2_ss"),
+	PINCTRL_PIN(WMT_PIN_SPI2MISO, "spi2_miso"),
+	PINCTRL_PIN(WMT_PIN_SPI2MOSI, "spi2_mosi"),
+	PINCTRL_PIN(WMT_PIN_SDDATA0, "sd_data0"),
+	PINCTRL_PIN(WMT_PIN_SDDATA1, "sd_data1"),
+	PINCTRL_PIN(WMT_PIN_SDDATA2, "sd_data2"),
+	PINCTRL_PIN(WMT_PIN_SDDATA3, "sd_data3"),
+	PINCTRL_PIN(WMT_PIN_MMCDATA0, "mmc_data0"),
+	PINCTRL_PIN(WMT_PIN_MMCDATA1, "mmc_data1"),
+	PINCTRL_PIN(WMT_PIN_MMCDATA2, "mmc_data2"),
+	PINCTRL_PIN(WMT_PIN_MMCDATA3, "mmc_data3"),
+	PINCTRL_PIN(WMT_PIN_SDCLK, "sd_clk"),
+	PINCTRL_PIN(WMT_PIN_SDWP, "sd_wp"),
+	PINCTRL_PIN(WMT_PIN_SDCMD, "sd_cmd"),
+	PINCTRL_PIN(WMT_PIN_MSDATA0, "ms_data0"),
+	PINCTRL_PIN(WMT_PIN_MSDATA1, "ms_data1"),
+	PINCTRL_PIN(WMT_PIN_MSDATA2, "ms_data2"),
+	PINCTRL_PIN(WMT_PIN_MSDATA3, "ms_data3"),
+	PINCTRL_PIN(WMT_PIN_MSCLK, "ms_clk"),
+	PINCTRL_PIN(WMT_PIN_MSBS, "ms_bs"),
+	PINCTRL_PIN(WMT_PIN_MSINS, "ms_ins"),
+	PINCTRL_PIN(WMT_PIN_I2C0SCL, "i2c0_scl"),
+	PINCTRL_PIN(WMT_PIN_I2C0SDA, "i2c0_sda"),
+	PINCTRL_PIN(WMT_PIN_I2C1SCL, "i2c1_scl"),
+	PINCTRL_PIN(WMT_PIN_I2C1SDA, "i2c1_sda"),
+	PINCTRL_PIN(WMT_PIN_MII0RXD0, "mii0_rxd0"),
+	PINCTRL_PIN(WMT_PIN_MII0RXD1, "mii0_rxd1"),
+	PINCTRL_PIN(WMT_PIN_MII0RXD2, "mii0_rxd2"),
+	PINCTRL_PIN(WMT_PIN_MII0RXD3, "mii0_rxd3"),
+	PINCTRL_PIN(WMT_PIN_MII0RXCLK, "mii0_rxclk"),
+	PINCTRL_PIN(WMT_PIN_MII0RXDV, "mii0_rxdv"),
+	PINCTRL_PIN(WMT_PIN_MII0RXERR, "mii0_rxerr"),
+	PINCTRL_PIN(WMT_PIN_MII0PHYRST, "mii0_phyrst"),
+	PINCTRL_PIN(WMT_PIN_MII0TXD0, "mii0_txd0"),
+	PINCTRL_PIN(WMT_PIN_MII0TXD1, "mii0_txd1"),
+	PINCTRL_PIN(WMT_PIN_MII0TXD2, "mii0_txd2"),
+	PINCTRL_PIN(WMT_PIN_MII0TXD3, "mii0_txd3"),
+	PINCTRL_PIN(WMT_PIN_MII0TXCLK, "mii0_txclk"),
+	PINCTRL_PIN(WMT_PIN_MII0TXEN, "mii0_txen"),
+	PINCTRL_PIN(WMT_PIN_MII0TXERR, "mii0_txerr"),
+	PINCTRL_PIN(WMT_PIN_MII0PHYPD, "mii0_phypd"),
+	PINCTRL_PIN(WMT_PIN_MII0COL, "mii0_col"),
+	PINCTRL_PIN(WMT_PIN_MII0CRS, "mii0_crs"),
+	PINCTRL_PIN(WMT_PIN_MII0MDIO, "mii0_mdio"),
+	PINCTRL_PIN(WMT_PIN_MII0MDC, "mii0_mdc"),
+	PINCTRL_PIN(WMT_PIN_SEECS, "see_cs"),
+	PINCTRL_PIN(WMT_PIN_SEECK, "see_ck"),
+	PINCTRL_PIN(WMT_PIN_SEEDI, "see_di"),
+	PINCTRL_PIN(WMT_PIN_SEEDO, "see_do"),
+	PINCTRL_PIN(WMT_PIN_IDEDREQ0, "ide_dreq0"),
+	PINCTRL_PIN(WMT_PIN_IDEDREQ1, "ide_dreq1"),
+	PINCTRL_PIN(WMT_PIN_IDEIOW, "ide_iow"),
+	PINCTRL_PIN(WMT_PIN_IDEIOR, "ide_ior"),
+	PINCTRL_PIN(WMT_PIN_IDEDACK, "ide_dack"),
+	PINCTRL_PIN(WMT_PIN_IDEIORDY, "ide_iordy"),
+	PINCTRL_PIN(WMT_PIN_IDEINTRQ, "ide_intrq"),
+	PINCTRL_PIN(WMT_PIN_VDIN0, "vdin0"),
+	PINCTRL_PIN(WMT_PIN_VDIN1, "vdin1"),
+	PINCTRL_PIN(WMT_PIN_VDIN2, "vdin2"),
+	PINCTRL_PIN(WMT_PIN_VDIN3, "vdin3"),
+	PINCTRL_PIN(WMT_PIN_VDIN4, "vdin4"),
+	PINCTRL_PIN(WMT_PIN_VDIN5, "vdin5"),
+	PINCTRL_PIN(WMT_PIN_VDIN6, "vdin6"),
+	PINCTRL_PIN(WMT_PIN_VDIN7, "vdin7"),
+	PINCTRL_PIN(WMT_PIN_VDOUT0, "vdout0"),
+	PINCTRL_PIN(WMT_PIN_VDOUT1, "vdout1"),
+	PINCTRL_PIN(WMT_PIN_VDOUT2, "vdout2"),
+	PINCTRL_PIN(WMT_PIN_VDOUT3, "vdout3"),
+	PINCTRL_PIN(WMT_PIN_VDOUT4, "vdout4"),
+	PINCTRL_PIN(WMT_PIN_VDOUT5, "vdout5"),
+	PINCTRL_PIN(WMT_PIN_NANDCLE0, "nand_cle0"),
+	PINCTRL_PIN(WMT_PIN_NANDCLE1, "nand_cle1"),
+	PINCTRL_PIN(WMT_PIN_VDOUT6_7, "vdout6_7"),
+	PINCTRL_PIN(WMT_PIN_VHSYNC, "vhsync"),
+	PINCTRL_PIN(WMT_PIN_VVSYNC, "vvsync"),
+	PINCTRL_PIN(WMT_PIN_TSDIN0, "tsdin0"),
+	PINCTRL_PIN(WMT_PIN_TSDIN1, "tsdin1"),
+	PINCTRL_PIN(WMT_PIN_TSDIN2, "tsdin2"),
+	PINCTRL_PIN(WMT_PIN_TSDIN3, "tsdin3"),
+	PINCTRL_PIN(WMT_PIN_TSDIN4, "tsdin4"),
+	PINCTRL_PIN(WMT_PIN_TSDIN5, "tsdin5"),
+	PINCTRL_PIN(WMT_PIN_TSDIN6, "tsdin6"),
+	PINCTRL_PIN(WMT_PIN_TSDIN7, "tsdin7"),
+	PINCTRL_PIN(WMT_PIN_TSSYNC, "tssync"),
+	PINCTRL_PIN(WMT_PIN_TSVALID, "tsvalid"),
+	PINCTRL_PIN(WMT_PIN_TSCLK, "tsclk"),
+	PINCTRL_PIN(WMT_PIN_LCDD0, "lcd_d0"),
+	PINCTRL_PIN(WMT_PIN_LCDD1, "lcd_d1"),
+	PINCTRL_PIN(WMT_PIN_LCDD2, "lcd_d2"),
+	PINCTRL_PIN(WMT_PIN_LCDD3, "lcd_d3"),
+	PINCTRL_PIN(WMT_PIN_LCDD4, "lcd_d4"),
+	PINCTRL_PIN(WMT_PIN_LCDD5, "lcd_d5"),
+	PINCTRL_PIN(WMT_PIN_LCDD6, "lcd_d6"),
+	PINCTRL_PIN(WMT_PIN_LCDD7, "lcd_d7"),
+	PINCTRL_PIN(WMT_PIN_LCDD8, "lcd_d8"),
+	PINCTRL_PIN(WMT_PIN_LCDD9, "lcd_d9"),
+	PINCTRL_PIN(WMT_PIN_LCDD10, "lcd_d10"),
+	PINCTRL_PIN(WMT_PIN_LCDD11, "lcd_d11"),
+	PINCTRL_PIN(WMT_PIN_LCDD12, "lcd_d12"),
+	PINCTRL_PIN(WMT_PIN_LCDD13, "lcd_d13"),
+	PINCTRL_PIN(WMT_PIN_LCDD14, "lcd_d14"),
+	PINCTRL_PIN(WMT_PIN_LCDD15, "lcd_d15"),
+	PINCTRL_PIN(WMT_PIN_LCDD16, "lcd_d16"),
+	PINCTRL_PIN(WMT_PIN_LCDD17, "lcd_d17"),
+	PINCTRL_PIN(WMT_PIN_LCDCLK, "lcd_clk"),
+	PINCTRL_PIN(WMT_PIN_LCDDEN, "lcd_den"),
+	PINCTRL_PIN(WMT_PIN_LCDLINE, "lcd_line"),
+	PINCTRL_PIN(WMT_PIN_LCDFRM, "lcd_frm"),
+	PINCTRL_PIN(WMT_PIN_LCDBIAS, "lcd_bias"),
+};
+
+/* Order of these names must match the above list */
+static const char * const vt8500_groups[] = {
+	"extgpio0",
+	"extgpio1",
+	"extgpio2",
+	"extgpio3",
+	"extgpio4",
+	"extgpio5",
+	"extgpio6",
+	"extgpio7",
+	"extgpio8",
+	"uart0_rts",
+	"uart0_txd",
+	"uart0_cts",
+	"uart0_rxd",
+	"uart1_rts",
+	"uart1_txd",
+	"uart1_cts",
+	"uart1_rxd",
+	"spi0_clk",
+	"spi0_ss",
+	"spi0_miso",
+	"spi0_mosi",
+	"spi1_clk",
+	"spi1_ss",
+	"spi1_miso",
+	"spi1_mosi",
+	"spi2_clk",
+	"spi2_ss",
+	"spi2_miso",
+	"spi2_mosi",
+	"sd_data0",
+	"sd_data1",
+	"sd_data2",
+	"sd_data3",
+	"mmc_data0",
+	"mmc_data1",
+	"mmc_data2",
+	"mmc_data3",
+	"sd_clk",
+	"sd_wp",
+	"sd_cmd",
+	"ms_data0",
+	"ms_data1",
+	"ms_data2",
+	"ms_data3",
+	"ms_clk",
+	"ms_bs",
+	"ms_ins",
+	"i2c0_scl",
+	"i2c0_sda",
+	"i2c1_scl",
+	"i2c1_sda",
+	"mii0_rxd0",
+	"mii0_rxd1",
+	"mii0_rxd2",
+	"mii0_rxd3",
+	"mii0_rxclk",
+	"mii0_rxdv",
+	"mii0_rxerr",
+	"mii0_phyrst",
+	"mii0_txd0",
+	"mii0_txd1",
+	"mii0_txd2",
+	"mii0_txd3",
+	"mii0_txclk",
+	"mii0_txen",
+	"mii0_txerr",
+	"mii0_phypd",
+	"mii0_col",
+	"mii0_crs",
+	"mii0_mdio",
+	"mii0_mdc",
+	"see_cs",
+	"see_ck",
+	"see_di",
+	"see_do",
+	"ide_dreq0",
+	"ide_dreq1",
+	"ide_iow",
+	"ide_ior",
+	"ide_dack",
+	"ide_iordy",
+	"ide_intrq",
+	"vdin0",
+	"vdin1",
+	"vdin2",
+	"vdin3",
+	"vdin4",
+	"vdin5",
+	"vdin6",
+	"vdin7",
+	"vdout0",
+	"vdout1",
+	"vdout2",
+	"vdout3",
+	"vdout4",
+	"vdout5",
+	"nand_cle0",
+	"nand_cle1",
+	"vdout6_7",
+	"vhsync",
+	"vvsync",
+	"tsdin0",
+	"tsdin1",
+	"tsdin2",
+	"tsdin3",
+	"tsdin4",
+	"tsdin5",
+	"tsdin6",
+	"tsdin7",
+	"tssync",
+	"tsvalid",
+	"tsclk",
+	"lcd_d0",
+	"lcd_d1",
+	"lcd_d2",
+	"lcd_d3",
+	"lcd_d4",
+	"lcd_d5",
+	"lcd_d6",
+	"lcd_d7",
+	"lcd_d8",
+	"lcd_d9",
+	"lcd_d10",
+	"lcd_d11",
+	"lcd_d12",
+	"lcd_d13",
+	"lcd_d14",
+	"lcd_d15",
+	"lcd_d16",
+	"lcd_d17",
+	"lcd_clk",
+	"lcd_den",
+	"lcd_line",
+	"lcd_frm",
+	"lcd_bias",
+};
+
+static int vt8500_pinctrl_probe(struct platform_device *pdev)
+{
+	struct wmt_pinctrl_data *data;
+
+	data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
+	if (!data) {
+		dev_err(&pdev->dev, "failed to allocate data\n");
+		return -ENOMEM;
+	}
+
+	data->banks = vt8500_banks;
+	data->nbanks = ARRAY_SIZE(vt8500_banks);
+	data->pins = vt8500_pins;
+	data->npins = ARRAY_SIZE(vt8500_pins);
+	data->groups = vt8500_groups;
+	data->ngroups = ARRAY_SIZE(vt8500_groups);
+
+	return wmt_pinctrl_probe(pdev, data);
+}
+
+static int vt8500_pinctrl_remove(struct platform_device *pdev)
+{
+	return wmt_pinctrl_remove(pdev);
+}
+
+static struct of_device_id wmt_pinctrl_of_match[] = {
+	{ .compatible = "via,vt8500-pinctrl" },
+	{ /* sentinel */ },
+};
+
+static struct platform_driver wmt_pinctrl_driver = {
+	.probe	= vt8500_pinctrl_probe,
+	.remove	= vt8500_pinctrl_remove,
+	.driver = {
+		.name	= "pinctrl-vt8500",
+		.owner	= THIS_MODULE,
+		.of_match_table	= wmt_pinctrl_of_match,
+	},
+};
+
+module_platform_driver(wmt_pinctrl_driver);
+
+MODULE_AUTHOR("Tony Prisk <linux at prisktech.co.nz>");
+MODULE_DESCRIPTION("VIA VT8500 Pincontrol driver");
+MODULE_LICENSE("GPL v2");
+MODULE_DEVICE_TABLE(of, wmt_pinctrl_of_match);
diff --git a/drivers/pinctrl/vt8500/pinctrl-wm8505.c b/drivers/pinctrl/vt8500/pinctrl-wm8505.c
new file mode 100644
index 0000000..483ba73
--- /dev/null
+++ b/drivers/pinctrl/vt8500/pinctrl-wm8505.c
@@ -0,0 +1,532 @@
+/*
+ * Pinctrl data for Wondermedia WM8505 SoC
+ *
+ * Copyright (c) 2013 Tony Prisk <linux at prisktech.co.nz>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ */
+
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/pinctrl/pinctrl.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+
+#include "pinctrl-wmt.h"
+
+/*
+ * Describe the register offsets within the GPIO memory space
+ * The dedicated external GPIO's should always be listed in bank 0
+ * so they are exported in the 0..31 range which is what users
+ * expect.
+ *
+ * Do not reorder these banks as it will change the pin numbering
+ */
+static const struct wmt_pinctrl_bank_registers wm8505_banks[] = {
+	WMT_PINCTRL_BANK(0x64, 0x8C, 0xB4, 0xDC, NO_REG, NO_REG),	/* 0 */
+	WMT_PINCTRL_BANK(0x40, 0x68, 0x90, 0xB8, NO_REG, NO_REG),	/* 1 */
+	WMT_PINCTRL_BANK(0x44, 0x6C, 0x94, 0xBC, NO_REG, NO_REG),	/* 2 */
+	WMT_PINCTRL_BANK(0x48, 0x70, 0x98, 0xC0, NO_REG, NO_REG),	/* 3 */
+	WMT_PINCTRL_BANK(0x4C, 0x74, 0x9C, 0xC4, NO_REG, NO_REG),	/* 4 */
+	WMT_PINCTRL_BANK(0x50, 0x78, 0xA0, 0xC8, NO_REG, NO_REG),	/* 5 */
+	WMT_PINCTRL_BANK(0x54, 0x7C, 0xA4, 0xD0, NO_REG, NO_REG),	/* 6 */
+	WMT_PINCTRL_BANK(0x58, 0x80, 0xA8, 0xD4, NO_REG, NO_REG),	/* 7 */
+	WMT_PINCTRL_BANK(0x5C, 0x84, 0xAC, 0xD8, NO_REG, NO_REG),	/* 8 */
+	WMT_PINCTRL_BANK(0x60, 0x88, 0xB0, 0xDC, NO_REG, NO_REG),	/* 9 */
+	WMT_PINCTRL_BANK(0x500, 0x504, 0x508, 0x50C, NO_REG, NO_REG),	/* 10 */
+};
+
+/* Please keep sorted by bank/bit */
+#define WMT_PIN_EXTGPIO0	WMT_PIN(0, 0)
+#define WMT_PIN_EXTGPIO1	WMT_PIN(0, 1)
+#define WMT_PIN_EXTGPIO2	WMT_PIN(0, 2)
+#define WMT_PIN_EXTGPIO3	WMT_PIN(0, 3)
+#define WMT_PIN_EXTGPIO4	WMT_PIN(0, 4)
+#define WMT_PIN_EXTGPIO5	WMT_PIN(0, 5)
+#define WMT_PIN_EXTGPIO6	WMT_PIN(0, 6)
+#define WMT_PIN_EXTGPIO7	WMT_PIN(0, 7)
+#define WMT_PIN_WAKEUP0		WMT_PIN(0, 16)
+#define WMT_PIN_WAKEUP1		WMT_PIN(0, 17)
+#define WMT_PIN_WAKEUP2		WMT_PIN(0, 18)
+#define WMT_PIN_WAKEUP3		WMT_PIN(0, 19)
+#define WMT_PIN_SUSGPIO0	WMT_PIN(0, 21)
+#define WMT_PIN_SDDATA0		WMT_PIN(1, 0)
+#define WMT_PIN_SDDATA1		WMT_PIN(1, 1)
+#define WMT_PIN_SDDATA2		WMT_PIN(1, 2)
+#define WMT_PIN_SDDATA3		WMT_PIN(1, 3)
+#define WMT_PIN_MMCDATA0	WMT_PIN(1, 4)
+#define WMT_PIN_MMCDATA1	WMT_PIN(1, 5)
+#define WMT_PIN_MMCDATA2	WMT_PIN(1, 6)
+#define WMT_PIN_MMCDATA3	WMT_PIN(1, 7)
+#define WMT_PIN_VDIN0		WMT_PIN(2, 0)
+#define WMT_PIN_VDIN1		WMT_PIN(2, 1)
+#define WMT_PIN_VDIN2		WMT_PIN(2, 2)
+#define WMT_PIN_VDIN3		WMT_PIN(2, 3)
+#define WMT_PIN_VDIN4		WMT_PIN(2, 4)
+#define WMT_PIN_VDIN5		WMT_PIN(2, 5)
+#define WMT_PIN_VDIN6		WMT_PIN(2, 6)
+#define WMT_PIN_VDIN7		WMT_PIN(2, 7)
+#define WMT_PIN_VDOUT0		WMT_PIN(2, 8)
+#define WMT_PIN_VDOUT1		WMT_PIN(2, 9)
+#define WMT_PIN_VDOUT2		WMT_PIN(2, 10)
+#define WMT_PIN_VDOUT3		WMT_PIN(2, 11)
+#define WMT_PIN_VDOUT4		WMT_PIN(2, 12)
+#define WMT_PIN_VDOUT5		WMT_PIN(2, 13)
+#define WMT_PIN_VDOUT6		WMT_PIN(2, 14)
+#define WMT_PIN_VDOUT7		WMT_PIN(2, 15)
+#define WMT_PIN_VDOUT8		WMT_PIN(2, 16)
+#define WMT_PIN_VDOUT9		WMT_PIN(2, 17)
+#define WMT_PIN_VDOUT10		WMT_PIN(2, 18)
+#define WMT_PIN_VDOUT11		WMT_PIN(2, 19)
+#define WMT_PIN_VDOUT12		WMT_PIN(2, 20)
+#define WMT_PIN_VDOUT13		WMT_PIN(2, 21)
+#define WMT_PIN_VDOUT14		WMT_PIN(2, 22)
+#define WMT_PIN_VDOUT15		WMT_PIN(2, 23)
+#define WMT_PIN_VDOUT16		WMT_PIN(2, 24)
+#define WMT_PIN_VDOUT17		WMT_PIN(2, 25)
+#define WMT_PIN_VDOUT18		WMT_PIN(2, 26)
+#define WMT_PIN_VDOUT19		WMT_PIN(2, 27)
+#define WMT_PIN_VDOUT20		WMT_PIN(2, 28)
+#define WMT_PIN_VDOUT21		WMT_PIN(2, 29)
+#define WMT_PIN_VDOUT22		WMT_PIN(2, 30)
+#define WMT_PIN_VDOUT23		WMT_PIN(2, 31)
+#define WMT_PIN_VHSYNC		WMT_PIN(3, 0)
+#define WMT_PIN_VVSYNC		WMT_PIN(3, 1)
+#define WMT_PIN_VGAHSYNC	WMT_PIN(3, 2)
+#define WMT_PIN_VGAVSYNC	WMT_PIN(3, 3)
+#define WMT_PIN_VDHSYNC		WMT_PIN(3, 4)
+#define WMT_PIN_VDVSYNC		WMT_PIN(3, 5)
+#define WMT_PIN_NORD0		WMT_PIN(4, 0)
+#define WMT_PIN_NORD1		WMT_PIN(4, 1)
+#define WMT_PIN_NORD2		WMT_PIN(4, 2)
+#define WMT_PIN_NORD3		WMT_PIN(4, 3)
+#define WMT_PIN_NORD4		WMT_PIN(4, 4)
+#define WMT_PIN_NORD5		WMT_PIN(4, 5)
+#define WMT_PIN_NORD6		WMT_PIN(4, 6)
+#define WMT_PIN_NORD7		WMT_PIN(4, 7)
+#define WMT_PIN_NORD8		WMT_PIN(4, 8)
+#define WMT_PIN_NORD9		WMT_PIN(4, 9)
+#define WMT_PIN_NORD10		WMT_PIN(4, 10)
+#define WMT_PIN_NORD11		WMT_PIN(4, 11)
+#define WMT_PIN_NORD12		WMT_PIN(4, 12)
+#define WMT_PIN_NORD13		WMT_PIN(4, 13)
+#define WMT_PIN_NORD14		WMT_PIN(4, 14)
+#define WMT_PIN_NORD15		WMT_PIN(4, 15)
+#define WMT_PIN_NORA0		WMT_PIN(5, 0)
+#define WMT_PIN_NORA1		WMT_PIN(5, 1)
+#define WMT_PIN_NORA2		WMT_PIN(5, 2)
+#define WMT_PIN_NORA3		WMT_PIN(5, 3)
+#define WMT_PIN_NORA4		WMT_PIN(5, 4)
+#define WMT_PIN_NORA5		WMT_PIN(5, 5)
+#define WMT_PIN_NORA6		WMT_PIN(5, 6)
+#define WMT_PIN_NORA7		WMT_PIN(5, 7)
+#define WMT_PIN_NORA8		WMT_PIN(5, 8)
+#define WMT_PIN_NORA9		WMT_PIN(5, 9)
+#define WMT_PIN_NORA10		WMT_PIN(5, 10)
+#define WMT_PIN_NORA11		WMT_PIN(5, 11)
+#define WMT_PIN_NORA12		WMT_PIN(5, 12)
+#define WMT_PIN_NORA13		WMT_PIN(5, 13)
+#define WMT_PIN_NORA14		WMT_PIN(5, 14)
+#define WMT_PIN_NORA15		WMT_PIN(5, 15)
+#define WMT_PIN_NORA16		WMT_PIN(5, 16)
+#define WMT_PIN_NORA17		WMT_PIN(5, 17)
+#define WMT_PIN_NORA18		WMT_PIN(5, 18)
+#define WMT_PIN_NORA19		WMT_PIN(5, 19)
+#define WMT_PIN_NORA20		WMT_PIN(5, 20)
+#define WMT_PIN_NORA21		WMT_PIN(5, 21)
+#define WMT_PIN_NORA22		WMT_PIN(5, 22)
+#define WMT_PIN_NORA23		WMT_PIN(5, 23)
+#define WMT_PIN_NORA24		WMT_PIN(5, 24)
+#define WMT_PIN_AC97SDI		WMT_PIN(6, 0)
+#define WMT_PIN_AC97SYNC	WMT_PIN(6, 1)
+#define WMT_PIN_AC97SDO		WMT_PIN(6, 2)
+#define WMT_PIN_AC97BCLK	WMT_PIN(6, 3)
+#define WMT_PIN_AC97RST		WMT_PIN(6, 4)
+#define WMT_PIN_SFDO		WMT_PIN(7, 0)
+#define WMT_PIN_SFCS0		WMT_PIN(7, 1)
+#define WMT_PIN_SFCS1		WMT_PIN(7, 2)
+#define WMT_PIN_SFCLK		WMT_PIN(7, 3)
+#define WMT_PIN_SFDI		WMT_PIN(7, 4)
+#define WMT_PIN_SPI0CLK		WMT_PIN(8, 0)
+#define WMT_PIN_SPI0MISO	WMT_PIN(8, 1)
+#define WMT_PIN_SPI0MOSI	WMT_PIN(8, 2)
+#define WMT_PIN_SPI0SS		WMT_PIN(8, 3)
+#define WMT_PIN_SPI1CLK		WMT_PIN(8, 4)
+#define WMT_PIN_SPI1MISO	WMT_PIN(8, 5)
+#define WMT_PIN_SPI1MOSI	WMT_PIN(8, 6)
+#define WMT_PIN_SPI1SS		WMT_PIN(8, 7)
+#define WMT_PIN_SPI2CLK		WMT_PIN(8, 8)
+#define WMT_PIN_SPI2MISO	WMT_PIN(8, 9)
+#define WMT_PIN_SPI2MOSI	WMT_PIN(8, 10)
+#define WMT_PIN_SPI2SS		WMT_PIN(8, 11)
+#define WMT_PIN_UART0_RTS	WMT_PIN(9, 0)
+#define WMT_PIN_UART0_TXD	WMT_PIN(9, 1)
+#define WMT_PIN_UART0_CTS	WMT_PIN(9, 2)
+#define WMT_PIN_UART0_RXD	WMT_PIN(9, 3)
+#define WMT_PIN_UART1_RTS	WMT_PIN(9, 4)
+#define WMT_PIN_UART1_TXD	WMT_PIN(9, 5)
+#define WMT_PIN_UART1_CTS	WMT_PIN(9, 6)
+#define WMT_PIN_UART1_RXD	WMT_PIN(9, 7)
+#define WMT_PIN_UART2_RTS	WMT_PIN(9, 8)
+#define WMT_PIN_UART2_TXD	WMT_PIN(9, 9)
+#define WMT_PIN_UART2_CTS	WMT_PIN(9, 10)
+#define WMT_PIN_UART2_RXD	WMT_PIN(9, 11)
+#define WMT_PIN_UART3_RTS	WMT_PIN(9, 12)
+#define WMT_PIN_UART3_TXD	WMT_PIN(9, 13)
+#define WMT_PIN_UART3_CTS	WMT_PIN(9, 14)
+#define WMT_PIN_UART3_RXD	WMT_PIN(9, 15)
+#define WMT_PIN_I2C0SCL		WMT_PIN(10, 0)
+#define WMT_PIN_I2C0SDA		WMT_PIN(10, 1)
+#define WMT_PIN_I2C1SCL		WMT_PIN(10, 2)
+#define WMT_PIN_I2C1SDA		WMT_PIN(10, 3)
+#define WMT_PIN_I2C2SCL		WMT_PIN(10, 4)
+#define WMT_PIN_I2C2SDA		WMT_PIN(10, 5)
+
+static const struct pinctrl_pin_desc wm8505_pins[] = {
+	PINCTRL_PIN(WMT_PIN_EXTGPIO0, "extgpio0"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO1, "extgpio1"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO2, "extgpio2"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO3, "extgpio3"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO4, "extgpio4"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO5, "extgpio5"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO6, "extgpio6"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO7, "extgpio7"),
+	PINCTRL_PIN(WMT_PIN_WAKEUP0, "wakeup0"),
+	PINCTRL_PIN(WMT_PIN_WAKEUP1, "wakeup1"),
+	PINCTRL_PIN(WMT_PIN_WAKEUP2, "wakeup2"),
+	PINCTRL_PIN(WMT_PIN_WAKEUP3, "wakeup3"),
+	PINCTRL_PIN(WMT_PIN_SUSGPIO0, "susgpio0"),
+	PINCTRL_PIN(WMT_PIN_SDDATA0, "sd_data0"),
+	PINCTRL_PIN(WMT_PIN_SDDATA1, "sd_data1"),
+	PINCTRL_PIN(WMT_PIN_SDDATA2, "sd_data2"),
+	PINCTRL_PIN(WMT_PIN_SDDATA3, "sd_data3"),
+	PINCTRL_PIN(WMT_PIN_MMCDATA0, "mmc_data0"),
+	PINCTRL_PIN(WMT_PIN_MMCDATA1, "mmc_data1"),
+	PINCTRL_PIN(WMT_PIN_MMCDATA2, "mmc_data2"),
+	PINCTRL_PIN(WMT_PIN_MMCDATA3, "mmc_data3"),
+	PINCTRL_PIN(WMT_PIN_VDIN0, "vdin0"),
+	PINCTRL_PIN(WMT_PIN_VDIN1, "vdin1"),
+	PINCTRL_PIN(WMT_PIN_VDIN2, "vdin2"),
+	PINCTRL_PIN(WMT_PIN_VDIN3, "vdin3"),
+	PINCTRL_PIN(WMT_PIN_VDIN4, "vdin4"),
+	PINCTRL_PIN(WMT_PIN_VDIN5, "vdin5"),
+	PINCTRL_PIN(WMT_PIN_VDIN6, "vdin6"),
+	PINCTRL_PIN(WMT_PIN_VDIN7, "vdin7"),
+	PINCTRL_PIN(WMT_PIN_VDOUT0, "vdout0"),
+	PINCTRL_PIN(WMT_PIN_VDOUT1, "vdout1"),
+	PINCTRL_PIN(WMT_PIN_VDOUT2, "vdout2"),
+	PINCTRL_PIN(WMT_PIN_VDOUT3, "vdout3"),
+	PINCTRL_PIN(WMT_PIN_VDOUT4, "vdout4"),
+	PINCTRL_PIN(WMT_PIN_VDOUT5, "vdout5"),
+	PINCTRL_PIN(WMT_PIN_VDOUT6, "vdout6"),
+	PINCTRL_PIN(WMT_PIN_VDOUT7, "vdout7"),
+	PINCTRL_PIN(WMT_PIN_VDOUT8, "vdout8"),
+	PINCTRL_PIN(WMT_PIN_VDOUT9, "vdout9"),
+	PINCTRL_PIN(WMT_PIN_VDOUT10, "vdout10"),
+	PINCTRL_PIN(WMT_PIN_VDOUT11, "vdout11"),
+	PINCTRL_PIN(WMT_PIN_VDOUT12, "vdout12"),
+	PINCTRL_PIN(WMT_PIN_VDOUT13, "vdout13"),
+	PINCTRL_PIN(WMT_PIN_VDOUT14, "vdout14"),
+	PINCTRL_PIN(WMT_PIN_VDOUT15, "vdout15"),
+	PINCTRL_PIN(WMT_PIN_VDOUT16, "vdout16"),
+	PINCTRL_PIN(WMT_PIN_VDOUT17, "vdout17"),
+	PINCTRL_PIN(WMT_PIN_VDOUT18, "vdout18"),
+	PINCTRL_PIN(WMT_PIN_VDOUT19, "vdout19"),
+	PINCTRL_PIN(WMT_PIN_VDOUT20, "vdout20"),
+	PINCTRL_PIN(WMT_PIN_VDOUT21, "vdout21"),
+	PINCTRL_PIN(WMT_PIN_VDOUT22, "vdout22"),
+	PINCTRL_PIN(WMT_PIN_VDOUT23, "vdout23"),
+	PINCTRL_PIN(WMT_PIN_VHSYNC, "v_hsync"),
+	PINCTRL_PIN(WMT_PIN_VVSYNC, "v_vsync"),
+	PINCTRL_PIN(WMT_PIN_VGAHSYNC, "vga_hsync"),
+	PINCTRL_PIN(WMT_PIN_VGAVSYNC, "vga_vsync"),
+	PINCTRL_PIN(WMT_PIN_VDHSYNC, "vd_hsync"),
+	PINCTRL_PIN(WMT_PIN_VDVSYNC, "vd_vsync"),
+	PINCTRL_PIN(WMT_PIN_NORD0, "nor_d0"),
+	PINCTRL_PIN(WMT_PIN_NORD1, "nor_d1"),
+	PINCTRL_PIN(WMT_PIN_NORD2, "nor_d2"),
+	PINCTRL_PIN(WMT_PIN_NORD3, "nor_d3"),
+	PINCTRL_PIN(WMT_PIN_NORD4, "nor_d4"),
+	PINCTRL_PIN(WMT_PIN_NORD5, "nor_d5"),
+	PINCTRL_PIN(WMT_PIN_NORD6, "nor_d6"),
+	PINCTRL_PIN(WMT_PIN_NORD7, "nor_d7"),
+	PINCTRL_PIN(WMT_PIN_NORD8, "nor_d8"),
+	PINCTRL_PIN(WMT_PIN_NORD9, "nor_d9"),
+	PINCTRL_PIN(WMT_PIN_NORD10, "nor_d10"),
+	PINCTRL_PIN(WMT_PIN_NORD11, "nor_d11"),
+	PINCTRL_PIN(WMT_PIN_NORD12, "nor_d12"),
+	PINCTRL_PIN(WMT_PIN_NORD13, "nor_d13"),
+	PINCTRL_PIN(WMT_PIN_NORD14, "nor_d14"),
+	PINCTRL_PIN(WMT_PIN_NORD15, "nor_d15"),
+	PINCTRL_PIN(WMT_PIN_NORA0, "nor_a0"),
+	PINCTRL_PIN(WMT_PIN_NORA1, "nor_a1"),
+	PINCTRL_PIN(WMT_PIN_NORA2, "nor_a2"),
+	PINCTRL_PIN(WMT_PIN_NORA3, "nor_a3"),
+	PINCTRL_PIN(WMT_PIN_NORA4, "nor_a4"),
+	PINCTRL_PIN(WMT_PIN_NORA5, "nor_a5"),
+	PINCTRL_PIN(WMT_PIN_NORA6, "nor_a6"),
+	PINCTRL_PIN(WMT_PIN_NORA7, "nor_a7"),
+	PINCTRL_PIN(WMT_PIN_NORA8, "nor_a8"),
+	PINCTRL_PIN(WMT_PIN_NORA9, "nor_a9"),
+	PINCTRL_PIN(WMT_PIN_NORA10, "nor_a10"),
+	PINCTRL_PIN(WMT_PIN_NORA11, "nor_a11"),
+	PINCTRL_PIN(WMT_PIN_NORA12, "nor_a12"),
+	PINCTRL_PIN(WMT_PIN_NORA13, "nor_a13"),
+	PINCTRL_PIN(WMT_PIN_NORA14, "nor_a14"),
+	PINCTRL_PIN(WMT_PIN_NORA15, "nor_a15"),
+	PINCTRL_PIN(WMT_PIN_NORA16, "nor_a16"),
+	PINCTRL_PIN(WMT_PIN_NORA17, "nor_a17"),
+	PINCTRL_PIN(WMT_PIN_NORA18, "nor_a18"),
+	PINCTRL_PIN(WMT_PIN_NORA19, "nor_a19"),
+	PINCTRL_PIN(WMT_PIN_NORA20, "nor_a20"),
+	PINCTRL_PIN(WMT_PIN_NORA21, "nor_a21"),
+	PINCTRL_PIN(WMT_PIN_NORA22, "nor_a22"),
+	PINCTRL_PIN(WMT_PIN_NORA23, "nor_a23"),
+	PINCTRL_PIN(WMT_PIN_NORA24, "nor_a24"),
+	PINCTRL_PIN(WMT_PIN_AC97SDI, "ac97_sdi"),
+	PINCTRL_PIN(WMT_PIN_AC97SYNC, "ac97_sync"),
+	PINCTRL_PIN(WMT_PIN_AC97SDO, "ac97_sdo"),
+	PINCTRL_PIN(WMT_PIN_AC97BCLK, "ac97_bclk"),
+	PINCTRL_PIN(WMT_PIN_AC97RST, "ac97_rst"),
+	PINCTRL_PIN(WMT_PIN_SFDO, "sf_do"),
+	PINCTRL_PIN(WMT_PIN_SFCS0, "sf_cs0"),
+	PINCTRL_PIN(WMT_PIN_SFCS1, "sf_cs1"),
+	PINCTRL_PIN(WMT_PIN_SFCLK, "sf_clk"),
+	PINCTRL_PIN(WMT_PIN_SFDI, "sf_di"),
+	PINCTRL_PIN(WMT_PIN_SPI0CLK, "spi0_clk"),
+	PINCTRL_PIN(WMT_PIN_SPI0MISO, "spi0_miso"),
+	PINCTRL_PIN(WMT_PIN_SPI0MOSI, "spi0_mosi"),
+	PINCTRL_PIN(WMT_PIN_SPI0SS, "spi0_ss"),
+	PINCTRL_PIN(WMT_PIN_SPI1CLK, "spi1_clk"),
+	PINCTRL_PIN(WMT_PIN_SPI1MISO, "spi1_miso"),
+	PINCTRL_PIN(WMT_PIN_SPI1MOSI, "spi1_mosi"),
+	PINCTRL_PIN(WMT_PIN_SPI1SS, "spi1_ss"),
+	PINCTRL_PIN(WMT_PIN_SPI2CLK, "spi2_clk"),
+	PINCTRL_PIN(WMT_PIN_SPI2MISO, "spi2_miso"),
+	PINCTRL_PIN(WMT_PIN_SPI2MOSI, "spi2_mosi"),
+	PINCTRL_PIN(WMT_PIN_SPI2SS, "spi2_ss"),
+	PINCTRL_PIN(WMT_PIN_UART0_RTS, "uart0_rts"),
+	PINCTRL_PIN(WMT_PIN_UART0_TXD, "uart0_txd"),
+	PINCTRL_PIN(WMT_PIN_UART0_CTS, "uart0_cts"),
+	PINCTRL_PIN(WMT_PIN_UART0_RXD, "uart0_rxd"),
+	PINCTRL_PIN(WMT_PIN_UART1_RTS, "uart1_rts"),
+	PINCTRL_PIN(WMT_PIN_UART1_TXD, "uart1_txd"),
+	PINCTRL_PIN(WMT_PIN_UART1_CTS, "uart1_cts"),
+	PINCTRL_PIN(WMT_PIN_UART1_RXD, "uart1_rxd"),
+	PINCTRL_PIN(WMT_PIN_UART2_RTS, "uart2_rts"),
+	PINCTRL_PIN(WMT_PIN_UART2_TXD, "uart2_txd"),
+	PINCTRL_PIN(WMT_PIN_UART2_CTS, "uart2_cts"),
+	PINCTRL_PIN(WMT_PIN_UART2_RXD, "uart2_rxd"),
+	PINCTRL_PIN(WMT_PIN_UART3_RTS, "uart3_rts"),
+	PINCTRL_PIN(WMT_PIN_UART3_TXD, "uart3_txd"),
+	PINCTRL_PIN(WMT_PIN_UART3_CTS, "uart3_cts"),
+	PINCTRL_PIN(WMT_PIN_UART3_RXD, "uart3_rxd"),
+	PINCTRL_PIN(WMT_PIN_I2C0SCL, "i2c0_scl"),
+	PINCTRL_PIN(WMT_PIN_I2C0SDA, "i2c0_sda"),
+	PINCTRL_PIN(WMT_PIN_I2C1SCL, "i2c1_scl"),
+	PINCTRL_PIN(WMT_PIN_I2C1SDA, "i2c1_sda"),
+	PINCTRL_PIN(WMT_PIN_I2C2SCL, "i2c2_scl"),
+	PINCTRL_PIN(WMT_PIN_I2C2SDA, "i2c2_sda"),
+};
+
+/* Order of these names must match the above list */
+static const char * const wm8505_groups[] = {
+	"extgpio0",
+	"extgpio1",
+	"extgpio2",
+	"extgpio3",
+	"extgpio4",
+	"extgpio5",
+	"extgpio6",
+	"extgpio7",
+	"wakeup0",
+	"wakeup1",
+	"wakeup2",
+	"wakeup3",
+	"susgpio0",
+	"sd_data0",
+	"sd_data1",
+	"sd_data2",
+	"sd_data3",
+	"mmc_data0",
+	"mmc_data1",
+	"mmc_data2",
+	"mmc_data3",
+	"vdin0",
+	"vdin1",
+	"vdin2",
+	"vdin3",
+	"vdin4",
+	"vdin5",
+	"vdin6",
+	"vdin7",
+	"vdout0",
+	"vdout1",
+	"vdout2",
+	"vdout3",
+	"vdout4",
+	"vdout5",
+	"vdout6",
+	"vdout7",
+	"vdout8",
+	"vdout9",
+	"vdout10",
+	"vdout11",
+	"vdout12",
+	"vdout13",
+	"vdout14",
+	"vdout15",
+	"vdout16",
+	"vdout17",
+	"vdout18",
+	"vdout19",
+	"vdout20",
+	"vdout21",
+	"vdout22",
+	"vdout23",
+	"v_hsync",
+	"v_vsync",
+	"vga_hsync",
+	"vga_vsync",
+	"vd_hsync",
+	"vd_vsync",
+	"nor_d0",
+	"nor_d1",
+	"nor_d2",
+	"nor_d3",
+	"nor_d4",
+	"nor_d5",
+	"nor_d6",
+	"nor_d7",
+	"nor_d8",
+	"nor_d9",
+	"nor_d10",
+	"nor_d11",
+	"nor_d12",
+	"nor_d13",
+	"nor_d14",
+	"nor_d15",
+	"nor_a0",
+	"nor_a1",
+	"nor_a2",
+	"nor_a3",
+	"nor_a4",
+	"nor_a5",
+	"nor_a6",
+	"nor_a7",
+	"nor_a8",
+	"nor_a9",
+	"nor_a10",
+	"nor_a11",
+	"nor_a12",
+	"nor_a13",
+	"nor_a14",
+	"nor_a15",
+	"nor_a16",
+	"nor_a17",
+	"nor_a18",
+	"nor_a19",
+	"nor_a20",
+	"nor_a21",
+	"nor_a22",
+	"nor_a23",
+	"nor_a24",
+	"ac97_sdi",
+	"ac97_sync",
+	"ac97_sdo",
+	"ac97_bclk",
+	"ac97_rst",
+	"sf_do",
+	"sf_cs0",
+	"sf_cs1",
+	"sf_clk",
+	"sf_di",
+	"spi0_clk",
+	"spi0_miso",
+	"spi0_mosi",
+	"spi0_ss",
+	"spi1_clk",
+	"spi1_miso",
+	"spi1_mosi",
+	"spi1_ss",
+	"spi2_clk",
+	"spi2_miso",
+	"spi2_mosi",
+	"spi2_ss",
+	"uart0_rts",
+	"uart0_txd",
+	"uart0_cts",
+	"uart0_rxd",
+	"uart1_rts",
+	"uart1_txd",
+	"uart1_cts",
+	"uart1_rxd",
+	"uart2_rts",
+	"uart2_txd",
+	"uart2_cts",
+	"uart2_rxd",
+	"uart3_rts",
+	"uart3_txd",
+	"uart3_cts",
+	"uart3_rxd",
+	"i2c0_scl",
+	"i2c0_sda",
+	"i2c1_scl",
+	"i2c1_sda",
+	"i2c2_scl",
+	"i2c2_sda",
+};
+
+static int wm8505_pinctrl_probe(struct platform_device *pdev)
+{
+	struct wmt_pinctrl_data *data;
+
+	data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
+	if (!data) {
+		dev_err(&pdev->dev, "failed to allocate data\n");
+		return -ENOMEM;
+	}
+
+	data->banks = wm8505_banks;
+	data->nbanks = ARRAY_SIZE(wm8505_banks);
+	data->pins = wm8505_pins;
+	data->npins = ARRAY_SIZE(wm8505_pins);
+	data->groups = wm8505_groups;
+	data->ngroups = ARRAY_SIZE(wm8505_groups);
+
+	return wmt_pinctrl_probe(pdev, data);
+}
+
+static int wm8505_pinctrl_remove(struct platform_device *pdev)
+{
+	return wmt_pinctrl_remove(pdev);
+}
+
+static struct of_device_id wmt_pinctrl_of_match[] = {
+	{ .compatible = "wm,wm8505-pinctrl" },
+	{ /* sentinel */ },
+};
+
+static struct platform_driver wmt_pinctrl_driver = {
+	.probe	= wm8505_pinctrl_probe,
+	.remove	= wm8505_pinctrl_remove,
+	.driver = {
+		.name	= "pinctrl-wm8505",
+		.owner	= THIS_MODULE,
+		.of_match_table	= wmt_pinctrl_of_match,
+	},
+};
+
+module_platform_driver(wmt_pinctrl_driver);
+
+MODULE_AUTHOR("Tony Prisk <linux at prisktech.co.nz>");
+MODULE_DESCRIPTION("Wondermedia WM8505 Pincontrol driver");
+MODULE_LICENSE("GPL v2");
+MODULE_DEVICE_TABLE(of, wmt_pinctrl_of_match);
diff --git a/drivers/pinctrl/vt8500/pinctrl-wm8650.c b/drivers/pinctrl/vt8500/pinctrl-wm8650.c
new file mode 100644
index 0000000..7de57f0
--- /dev/null
+++ b/drivers/pinctrl/vt8500/pinctrl-wm8650.c
@@ -0,0 +1,370 @@
+/*
+ * Pinctrl data for Wondermedia WM8650 SoC
+ *
+ * Copyright (c) 2013 Tony Prisk <linux at prisktech.co.nz>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ */
+
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/pinctrl/pinctrl.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+
+#include "pinctrl-wmt.h"
+
+/*
+ * Describe the register offsets within the GPIO memory space
+ * The dedicated external GPIO's should always be listed in bank 0
+ * so they are exported in the 0..31 range which is what users
+ * expect.
+ *
+ * Do not reorder these banks as it will change the pin numbering
+ */
+static const struct wmt_pinctrl_bank_registers wm8650_banks[] = {
+	WMT_PINCTRL_BANK(0x40, 0x80, 0xC0, 0x00, 0x480, 0x4C0),		/* 0 */
+	WMT_PINCTRL_BANK(0x44, 0x84, 0xC4, 0x04, 0x484, 0x4C4),		/* 1 */
+	WMT_PINCTRL_BANK(0x48, 0x88, 0xC8, 0x08, 0x488, 0x4C8),		/* 2 */
+	WMT_PINCTRL_BANK(0x4C, 0x8C, 0xCC, 0x0C, 0x48C, 0x4CC),		/* 3 */
+	WMT_PINCTRL_BANK(0x50, 0x90, 0xD0, 0x10, 0x490, 0x4D0),		/* 4 */
+	WMT_PINCTRL_BANK(0x54, 0x94, 0xD4, 0x14, 0x494, 0x4D4),		/* 5 */
+	WMT_PINCTRL_BANK(0x58, 0x98, 0xD8, 0x18, 0x498, 0x4D8),		/* 6 */
+	WMT_PINCTRL_BANK(0x5C, 0x9C, 0xDC, 0x1C, 0x49C, 0x4DC),		/* 7 */
+};
+
+/* Please keep sorted by bank/bit */
+#define WMT_PIN_EXTGPIO0	WMT_PIN(0, 0)
+#define WMT_PIN_EXTGPIO1	WMT_PIN(0, 1)
+#define WMT_PIN_EXTGPIO2	WMT_PIN(0, 2)
+#define WMT_PIN_EXTGPIO3	WMT_PIN(0, 3)
+#define WMT_PIN_EXTGPIO4	WMT_PIN(0, 4)
+#define WMT_PIN_EXTGPIO5	WMT_PIN(0, 5)
+#define WMT_PIN_EXTGPIO6	WMT_PIN(0, 6)
+#define WMT_PIN_EXTGPIO7	WMT_PIN(0, 7)
+#define WMT_PIN_WAKEUP0		WMT_PIN(0, 16)
+#define WMT_PIN_WAKEUP1		WMT_PIN(0, 17)
+#define WMT_PIN_SUSGPIO0	WMT_PIN(0, 21)
+#define WMT_PIN_SD0CD		WMT_PIN(0, 28)
+#define WMT_PIN_SD1CD		WMT_PIN(0, 29)
+#define WMT_PIN_VDOUT0		WMT_PIN(1, 0)
+#define WMT_PIN_VDOUT1		WMT_PIN(1, 1)
+#define WMT_PIN_VDOUT2		WMT_PIN(1, 2)
+#define WMT_PIN_VDOUT3		WMT_PIN(1, 3)
+#define WMT_PIN_VDOUT4		WMT_PIN(1, 4)
+#define WMT_PIN_VDOUT5		WMT_PIN(1, 5)
+#define WMT_PIN_VDOUT6		WMT_PIN(1, 6)
+#define WMT_PIN_VDOUT7		WMT_PIN(1, 7)
+#define WMT_PIN_VDOUT8		WMT_PIN(1, 8)
+#define WMT_PIN_VDOUT9		WMT_PIN(1, 9)
+#define WMT_PIN_VDOUT10		WMT_PIN(1, 10)
+#define WMT_PIN_VDOUT11		WMT_PIN(1, 11)
+#define WMT_PIN_VDOUT12		WMT_PIN(1, 12)
+#define WMT_PIN_VDOUT13		WMT_PIN(1, 13)
+#define WMT_PIN_VDOUT14		WMT_PIN(1, 14)
+#define WMT_PIN_VDOUT15		WMT_PIN(1, 15)
+#define WMT_PIN_VDOUT16		WMT_PIN(1, 16)
+#define WMT_PIN_VDOUT17		WMT_PIN(1, 17)
+#define WMT_PIN_VDOUT18		WMT_PIN(1, 18)
+#define WMT_PIN_VDOUT19		WMT_PIN(1, 19)
+#define WMT_PIN_VDOUT20		WMT_PIN(1, 20)
+#define WMT_PIN_VDOUT21		WMT_PIN(1, 21)
+#define WMT_PIN_VDOUT22		WMT_PIN(1, 22)
+#define WMT_PIN_VDOUT23		WMT_PIN(1, 23)
+#define WMT_PIN_VDIN0		WMT_PIN(2, 0)
+#define WMT_PIN_VDIN1		WMT_PIN(2, 1)
+#define WMT_PIN_VDIN2		WMT_PIN(2, 2)
+#define WMT_PIN_VDIN3		WMT_PIN(2, 3)
+#define WMT_PIN_VDIN4		WMT_PIN(2, 4)
+#define WMT_PIN_VDIN5		WMT_PIN(2, 5)
+#define WMT_PIN_VDIN6		WMT_PIN(2, 6)
+#define WMT_PIN_VDIN7		WMT_PIN(2, 7)
+#define WMT_PIN_I2C1SCL		WMT_PIN(2, 12)
+#define WMT_PIN_I2C1SDA		WMT_PIN(2, 13)
+#define WMT_PIN_SPI0MOSI	WMT_PIN(2, 24)
+#define WMT_PIN_SPI0MISO	WMT_PIN(2, 25)
+#define WMT_PIN_SPI0SS0		WMT_PIN(2, 26)
+#define WMT_PIN_SPI0CLK		WMT_PIN(2, 27)
+#define WMT_PIN_SD0DATA0	WMT_PIN(3, 8)
+#define WMT_PIN_SD0DATA1	WMT_PIN(3, 9)
+#define WMT_PIN_SD0DATA2	WMT_PIN(3, 10)
+#define WMT_PIN_SD0DATA3	WMT_PIN(3, 11)
+#define WMT_PIN_SD0CLK		WMT_PIN(3, 12)
+#define WMT_PIN_SD0WP		WMT_PIN(3, 13)
+#define WMT_PIN_SD0CMD		WMT_PIN(3, 14)
+#define WMT_PIN_SD1DATA0	WMT_PIN(3, 24)
+#define WMT_PIN_SD1DATA1	WMT_PIN(3, 25)
+#define WMT_PIN_SD1DATA2	WMT_PIN(3, 26)
+#define WMT_PIN_SD1DATA3	WMT_PIN(3, 27)
+#define WMT_PIN_SD1DATA4	WMT_PIN(3, 28)
+#define WMT_PIN_SD1DATA5	WMT_PIN(3, 29)
+#define WMT_PIN_SD1DATA6	WMT_PIN(3, 30)
+#define WMT_PIN_SD1DATA7	WMT_PIN(3, 31)
+#define WMT_PIN_I2C0SCL		WMT_PIN(5, 8)
+#define WMT_PIN_I2C0SDA		WMT_PIN(5, 9)
+#define WMT_PIN_UART0RTS	WMT_PIN(5, 16)
+#define WMT_PIN_UART0TXD	WMT_PIN(5, 17)
+#define WMT_PIN_UART0CTS	WMT_PIN(5, 18)
+#define WMT_PIN_UART0RXD	WMT_PIN(5, 19)
+#define WMT_PIN_UART1RTS	WMT_PIN(5, 20)
+#define WMT_PIN_UART1TXD	WMT_PIN(5, 21)
+#define WMT_PIN_UART1CTS	WMT_PIN(5, 22)
+#define WMT_PIN_UART1RXD	WMT_PIN(5, 23)
+#define WMT_PIN_UART2RTS	WMT_PIN(5, 24)
+#define WMT_PIN_UART2TXD	WMT_PIN(5, 25)
+#define WMT_PIN_UART2CTS	WMT_PIN(5, 26)
+#define WMT_PIN_UART2RXD	WMT_PIN(5, 27)
+#define WMT_PIN_UART3RTS	WMT_PIN(5, 28)
+#define WMT_PIN_UART3TXD	WMT_PIN(5, 29)
+#define WMT_PIN_UART3CTS	WMT_PIN(5, 30)
+#define WMT_PIN_UART3RXD	WMT_PIN(5, 31)
+#define WMT_PIN_KPADROW0	WMT_PIN(6, 16)
+#define WMT_PIN_KPADROW1	WMT_PIN(6, 17)
+#define WMT_PIN_KPADCOL0	WMT_PIN(6, 18)
+#define WMT_PIN_KPADCOL1	WMT_PIN(6, 19)
+#define WMT_PIN_SD1CLK		WMT_PIN(7, 0)
+#define WMT_PIN_SD1CMD		WMT_PIN(7, 1)
+#define WMT_PIN_SD1WP		WMT_PIN(7, 13)
+
+static const struct pinctrl_pin_desc wm8650_pins[] = {
+	PINCTRL_PIN(WMT_PIN_EXTGPIO0, "extgpio0"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO1, "extgpio1"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO2, "extgpio2"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO3, "extgpio3"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO4, "extgpio4"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO5, "extgpio5"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO6, "extgpio6"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO7, "extgpio7"),
+	PINCTRL_PIN(WMT_PIN_WAKEUP0, "wakeup0"),
+	PINCTRL_PIN(WMT_PIN_WAKEUP1, "wakeup1"),
+	PINCTRL_PIN(WMT_PIN_SUSGPIO0, "susgpio0"),
+	PINCTRL_PIN(WMT_PIN_SD0CD, "sd0_cd"),
+	PINCTRL_PIN(WMT_PIN_SD1CD, "sd1_cd"),
+	PINCTRL_PIN(WMT_PIN_VDOUT0, "vdout0"),
+	PINCTRL_PIN(WMT_PIN_VDOUT1, "vdout1"),
+	PINCTRL_PIN(WMT_PIN_VDOUT2, "vdout2"),
+	PINCTRL_PIN(WMT_PIN_VDOUT3, "vdout3"),
+	PINCTRL_PIN(WMT_PIN_VDOUT4, "vdout4"),
+	PINCTRL_PIN(WMT_PIN_VDOUT5, "vdout5"),
+	PINCTRL_PIN(WMT_PIN_VDOUT6, "vdout6"),
+	PINCTRL_PIN(WMT_PIN_VDOUT7, "vdout7"),
+	PINCTRL_PIN(WMT_PIN_VDOUT8, "vdout8"),
+	PINCTRL_PIN(WMT_PIN_VDOUT9, "vdout9"),
+	PINCTRL_PIN(WMT_PIN_VDOUT10, "vdout10"),
+	PINCTRL_PIN(WMT_PIN_VDOUT11, "vdout11"),
+	PINCTRL_PIN(WMT_PIN_VDOUT12, "vdout12"),
+	PINCTRL_PIN(WMT_PIN_VDOUT13, "vdout13"),
+	PINCTRL_PIN(WMT_PIN_VDOUT14, "vdout14"),
+	PINCTRL_PIN(WMT_PIN_VDOUT15, "vdout15"),
+	PINCTRL_PIN(WMT_PIN_VDOUT16, "vdout16"),
+	PINCTRL_PIN(WMT_PIN_VDOUT17, "vdout17"),
+	PINCTRL_PIN(WMT_PIN_VDOUT18, "vdout18"),
+	PINCTRL_PIN(WMT_PIN_VDOUT19, "vdout19"),
+	PINCTRL_PIN(WMT_PIN_VDOUT20, "vdout20"),
+	PINCTRL_PIN(WMT_PIN_VDOUT21, "vdout21"),
+	PINCTRL_PIN(WMT_PIN_VDOUT22, "vdout22"),
+	PINCTRL_PIN(WMT_PIN_VDOUT23, "vdout23"),
+	PINCTRL_PIN(WMT_PIN_VDIN0, "vdin0"),
+	PINCTRL_PIN(WMT_PIN_VDIN1, "vdin1"),
+	PINCTRL_PIN(WMT_PIN_VDIN2, "vdin2"),
+	PINCTRL_PIN(WMT_PIN_VDIN3, "vdin3"),
+	PINCTRL_PIN(WMT_PIN_VDIN4, "vdin4"),
+	PINCTRL_PIN(WMT_PIN_VDIN5, "vdin5"),
+	PINCTRL_PIN(WMT_PIN_VDIN6, "vdin6"),
+	PINCTRL_PIN(WMT_PIN_VDIN7, "vdin7"),
+	PINCTRL_PIN(WMT_PIN_I2C1SCL, "i2c1_scl"),
+	PINCTRL_PIN(WMT_PIN_I2C1SDA, "i2c1_sda"),
+	PINCTRL_PIN(WMT_PIN_SPI0MOSI, "spi0_mosi"),
+	PINCTRL_PIN(WMT_PIN_SPI0MISO, "spi0_miso"),
+	PINCTRL_PIN(WMT_PIN_SPI0SS0, "spi0_ss0"),
+	PINCTRL_PIN(WMT_PIN_SPI0CLK, "spi0_clk"),
+	PINCTRL_PIN(WMT_PIN_SD0DATA0, "sd0_data0"),
+	PINCTRL_PIN(WMT_PIN_SD0DATA1, "sd0_data1"),
+	PINCTRL_PIN(WMT_PIN_SD0DATA2, "sd0_data2"),
+	PINCTRL_PIN(WMT_PIN_SD0DATA3, "sd0_data3"),
+	PINCTRL_PIN(WMT_PIN_SD0CLK, "sd0_clk"),
+	PINCTRL_PIN(WMT_PIN_SD0WP, "sd0_wp"),
+	PINCTRL_PIN(WMT_PIN_SD0CMD, "sd0_cmd"),
+	PINCTRL_PIN(WMT_PIN_SD1DATA0, "sd1_data0"),
+	PINCTRL_PIN(WMT_PIN_SD1DATA1, "sd1_data1"),
+	PINCTRL_PIN(WMT_PIN_SD1DATA2, "sd1_data2"),
+	PINCTRL_PIN(WMT_PIN_SD1DATA3, "sd1_data3"),
+	PINCTRL_PIN(WMT_PIN_SD1DATA4, "sd1_data4"),
+	PINCTRL_PIN(WMT_PIN_SD1DATA5, "sd1_data5"),
+	PINCTRL_PIN(WMT_PIN_SD1DATA6, "sd1_data6"),
+	PINCTRL_PIN(WMT_PIN_SD1DATA7, "sd1_data7"),
+	PINCTRL_PIN(WMT_PIN_I2C0SCL, "i2c0_scl"),
+	PINCTRL_PIN(WMT_PIN_I2C0SDA, "i2c0_sda"),
+	PINCTRL_PIN(WMT_PIN_UART0RTS, "uart0_rts"),
+	PINCTRL_PIN(WMT_PIN_UART0TXD, "uart0_txd"),
+	PINCTRL_PIN(WMT_PIN_UART0CTS, "uart0_cts"),
+	PINCTRL_PIN(WMT_PIN_UART0RXD, "uart0_rxd"),
+	PINCTRL_PIN(WMT_PIN_UART1RTS, "uart1_rts"),
+	PINCTRL_PIN(WMT_PIN_UART1TXD, "uart1_txd"),
+	PINCTRL_PIN(WMT_PIN_UART1CTS, "uart1_cts"),
+	PINCTRL_PIN(WMT_PIN_UART1RXD, "uart1_rxd"),
+	PINCTRL_PIN(WMT_PIN_UART2RTS, "uart2_rts"),
+	PINCTRL_PIN(WMT_PIN_UART2TXD, "uart2_txd"),
+	PINCTRL_PIN(WMT_PIN_UART2CTS, "uart2_cts"),
+	PINCTRL_PIN(WMT_PIN_UART2RXD, "uart2_rxd"),
+	PINCTRL_PIN(WMT_PIN_UART3RTS, "uart3_rts"),
+	PINCTRL_PIN(WMT_PIN_UART3TXD, "uart3_txd"),
+	PINCTRL_PIN(WMT_PIN_UART3CTS, "uart3_cts"),
+	PINCTRL_PIN(WMT_PIN_UART3RXD, "uart3_rxd"),
+	PINCTRL_PIN(WMT_PIN_KPADROW0, "kpadrow0"),
+	PINCTRL_PIN(WMT_PIN_KPADROW1, "kpadrow1"),
+	PINCTRL_PIN(WMT_PIN_KPADCOL0, "kpadcol0"),
+	PINCTRL_PIN(WMT_PIN_KPADCOL1, "kpadcol1"),
+	PINCTRL_PIN(WMT_PIN_SD1CLK, "sd1_clk"),
+	PINCTRL_PIN(WMT_PIN_SD1CMD, "sd1_cmd"),
+	PINCTRL_PIN(WMT_PIN_SD1WP, "sd1_wp"),
+};
+
+/* Order of these names must match the above list */
+static const char * const wm8650_groups[] = {
+	"extgpio0",
+	"extgpio1",
+	"extgpio2",
+	"extgpio3",
+	"extgpio4",
+	"extgpio5",
+	"extgpio6",
+	"extgpio7",
+	"wakeup0",
+	"wakeup1",
+	"susgpio0",
+	"sd0_cd",
+	"sd1_cd",
+	"vdout0",
+	"vdout1",
+	"vdout2",
+	"vdout3",
+	"vdout4",
+	"vdout5",
+	"vdout6",
+	"vdout7",
+	"vdout8",
+	"vdout9",
+	"vdout10",
+	"vdout11",
+	"vdout12",
+	"vdout13",
+	"vdout14",
+	"vdout15",
+	"vdout16",
+	"vdout17",
+	"vdout18",
+	"vdout19",
+	"vdout20",
+	"vdout21",
+	"vdout22",
+	"vdout23",
+	"vdin0",
+	"vdin1",
+	"vdin2",
+	"vdin3",
+	"vdin4",
+	"vdin5",
+	"vdin6",
+	"vdin7",
+	"i2c1_scl",
+	"i2c1_sda",
+	"spi0_mosi",
+	"spi0_miso",
+	"spi0_ss0",
+	"spi0_clk",
+	"sd0_data0",
+	"sd0_data1",
+	"sd0_data2",
+	"sd0_data3",
+	"sd0_clk",
+	"sd0_wp",
+	"sd0_cmd",
+	"sd1_data0",
+	"sd1_data1",
+	"sd1_data2",
+	"sd1_data3",
+	"sd1_data4",
+	"sd1_data5",
+	"sd1_data6",
+	"sd1_data7",
+	"i2c0_scl",
+	"i2c0_sda",
+	"uart0_rts",
+	"uart0_txd",
+	"uart0_cts",
+	"uart0_rxd",
+	"uart1_rts",
+	"uart1_txd",
+	"uart1_cts",
+	"uart1_rxd",
+	"uart2_rts",
+	"uart2_txd",
+	"uart2_cts",
+	"uart2_rxd",
+	"uart3_rts",
+	"uart3_txd",
+	"uart3_cts",
+	"uart3_rxd",
+	"kpadrow0",
+	"kpadrow1",
+	"kpadcol0",
+	"kpadcol1",
+	"sd1_clk",
+	"sd1_cmd",
+	"sd1_wp",
+};
+
+static int wm8650_pinctrl_probe(struct platform_device *pdev)
+{
+	struct wmt_pinctrl_data *data;
+
+	data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
+	if (!data) {
+		dev_err(&pdev->dev, "failed to allocate data\n");
+		return -ENOMEM;
+	}
+
+	data->banks = wm8650_banks;
+	data->nbanks = ARRAY_SIZE(wm8650_banks);
+	data->pins = wm8650_pins;
+	data->npins = ARRAY_SIZE(wm8650_pins);
+	data->groups = wm8650_groups;
+	data->ngroups = ARRAY_SIZE(wm8650_groups);
+
+	return wmt_pinctrl_probe(pdev, data);
+}
+
+static int wm8650_pinctrl_remove(struct platform_device *pdev)
+{
+	return wmt_pinctrl_remove(pdev);
+}
+
+static struct of_device_id wmt_pinctrl_of_match[] = {
+	{ .compatible = "wm,wm8650-pinctrl" },
+	{ /* sentinel */ },
+};
+
+static struct platform_driver wmt_pinctrl_driver = {
+	.probe	= wm8650_pinctrl_probe,
+	.remove	= wm8650_pinctrl_remove,
+	.driver = {
+		.name	= "pinctrl-wm8650",
+		.owner	= THIS_MODULE,
+		.of_match_table	= wmt_pinctrl_of_match,
+	},
+};
+
+module_platform_driver(wmt_pinctrl_driver);
+
+MODULE_AUTHOR("Tony Prisk <linux at prisktech.co.nz>");
+MODULE_DESCRIPTION("Wondermedia WM8650 Pincontrol driver");
+MODULE_LICENSE("GPL v2");
+MODULE_DEVICE_TABLE(of, wmt_pinctrl_of_match);
diff --git a/drivers/pinctrl/vt8500/pinctrl-wm8750.c b/drivers/pinctrl/vt8500/pinctrl-wm8750.c
new file mode 100644
index 0000000..b964cc5
--- /dev/null
+++ b/drivers/pinctrl/vt8500/pinctrl-wm8750.c
@@ -0,0 +1,409 @@
+/*
+ * Pinctrl data for Wondermedia WM8750 SoC
+ *
+ * Copyright (c) 2013 Tony Prisk <linux at prisktech.co.nz>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ */
+
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/pinctrl/pinctrl.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+
+#include "pinctrl-wmt.h"
+
+/*
+ * Describe the register offsets within the GPIO memory space
+ * The dedicated external GPIO's should always be listed in bank 0
+ * so they are exported in the 0..31 range which is what users
+ * expect.
+ *
+ * Do not reorder these banks as it will change the pin numbering
+ */
+static const struct wmt_pinctrl_bank_registers wm8750_banks[] = {
+	WMT_PINCTRL_BANK(0x40, 0x80, 0xC0, 0x00, 0x480, 0x4C0),	/* 0 */
+	WMT_PINCTRL_BANK(0x44, 0x84, 0xC4, 0x04, 0x484, 0x4C4),	/* 1 */
+	WMT_PINCTRL_BANK(0x48, 0x88, 0xC8, 0x08, 0x488, 0x4C8),	/* 2 */
+	WMT_PINCTRL_BANK(0x4C, 0x8C, 0xCC, 0x0C, 0x48C, 0x4CC),	/* 3 */
+	WMT_PINCTRL_BANK(0x50, 0x90, 0xD0, 0x10, 0x490, 0x4D0),	/* 4 */
+	WMT_PINCTRL_BANK(0x54, 0x94, 0xD4, 0x14, 0x494, 0x4D4),	/* 5 */
+	WMT_PINCTRL_BANK(0x58, 0x98, 0xD8, 0x18, 0x498, 0x4D8),	/* 6 */
+	WMT_PINCTRL_BANK(0x5C, 0x9C, 0xDC, 0x1C, 0x49C, 0x4DC),	/* 7 */
+	WMT_PINCTRL_BANK(0x60, 0xA0, 0xE0, 0x20, 0x4A0, 0x4E0),	/* 8 */
+	WMT_PINCTRL_BANK(0x70, 0xB0, 0xF0, 0x30, 0x4B0, 0x4F0),	/* 9 */
+	WMT_PINCTRL_BANK(0x7C, 0xBC, 0xDC, 0x3C, 0x4BC, 0x4FC),	/* 10 */
+};
+
+/* Please keep sorted by bank/bit */
+#define WMT_PIN_EXTGPIO0	WMT_PIN(0, 0)
+#define WMT_PIN_EXTGPIO1	WMT_PIN(0, 1)
+#define WMT_PIN_EXTGPIO2	WMT_PIN(0, 2)
+#define WMT_PIN_EXTGPIO3	WMT_PIN(0, 3)
+#define WMT_PIN_EXTGPIO4	WMT_PIN(0, 4)
+#define WMT_PIN_EXTGPIO5	WMT_PIN(0, 5)
+#define WMT_PIN_EXTGPIO6	WMT_PIN(0, 6)
+#define WMT_PIN_EXTGPIO7	WMT_PIN(0, 7)
+#define WMT_PIN_WAKEUP0		WMT_PIN(0, 16)
+#define WMT_PIN_WAKEUP1		WMT_PIN(0, 16)
+#define WMT_PIN_SD0CD		WMT_PIN(0, 28)
+#define WMT_PIN_VDOUT0		WMT_PIN(1, 0)
+#define WMT_PIN_VDOUT1		WMT_PIN(1, 1)
+#define WMT_PIN_VDOUT2		WMT_PIN(1, 2)
+#define WMT_PIN_VDOUT3		WMT_PIN(1, 3)
+#define WMT_PIN_VDOUT4		WMT_PIN(1, 4)
+#define WMT_PIN_VDOUT5		WMT_PIN(1, 5)
+#define WMT_PIN_VDOUT6		WMT_PIN(1, 6)
+#define WMT_PIN_VDOUT7		WMT_PIN(1, 7)
+#define WMT_PIN_VDOUT8		WMT_PIN(1, 8)
+#define WMT_PIN_VDOUT9		WMT_PIN(1, 9)
+#define WMT_PIN_VDOUT10		WMT_PIN(1, 10)
+#define WMT_PIN_VDOUT11		WMT_PIN(1, 11)
+#define WMT_PIN_VDOUT12		WMT_PIN(1, 12)
+#define WMT_PIN_VDOUT13		WMT_PIN(1, 13)
+#define WMT_PIN_VDOUT14		WMT_PIN(1, 14)
+#define WMT_PIN_VDOUT15		WMT_PIN(1, 15)
+#define WMT_PIN_VDOUT16		WMT_PIN(1, 16)
+#define WMT_PIN_VDOUT17		WMT_PIN(1, 17)
+#define WMT_PIN_VDOUT18		WMT_PIN(1, 18)
+#define WMT_PIN_VDOUT19		WMT_PIN(1, 19)
+#define WMT_PIN_VDOUT20		WMT_PIN(1, 20)
+#define WMT_PIN_VDOUT21		WMT_PIN(1, 21)
+#define WMT_PIN_VDOUT22		WMT_PIN(1, 22)
+#define WMT_PIN_VDOUT23		WMT_PIN(1, 23)
+#define WMT_PIN_VDIN0		WMT_PIN(2, 0)
+#define WMT_PIN_VDIN1		WMT_PIN(2, 1)
+#define WMT_PIN_VDIN2		WMT_PIN(2, 2)
+#define WMT_PIN_VDIN3		WMT_PIN(2, 3)
+#define WMT_PIN_VDIN4		WMT_PIN(2, 4)
+#define WMT_PIN_VDIN5		WMT_PIN(2, 5)
+#define WMT_PIN_VDIN6		WMT_PIN(2, 6)
+#define WMT_PIN_VDIN7		WMT_PIN(2, 7)
+#define WMT_PIN_SPI0_MOSI	WMT_PIN(2, 24)
+#define WMT_PIN_SPI0_MISO	WMT_PIN(2, 25)
+#define WMT_PIN_SPI0_SS		WMT_PIN(2, 26)
+#define WMT_PIN_SPI0_CLK	WMT_PIN(2, 27)
+#define WMT_PIN_SPI0_SSB	WMT_PIN(2, 28)
+#define WMT_PIN_SD0CLK		WMT_PIN(3, 17)
+#define WMT_PIN_SD0CMD		WMT_PIN(3, 18)
+#define WMT_PIN_SD0WP		WMT_PIN(3, 19)
+#define WMT_PIN_SD0DATA0	WMT_PIN(3, 20)
+#define WMT_PIN_SD0DATA1	WMT_PIN(3, 21)
+#define WMT_PIN_SD0DATA2	WMT_PIN(3, 22)
+#define WMT_PIN_SD0DATA3	WMT_PIN(3, 23)
+#define WMT_PIN_SD1DATA0	WMT_PIN(3, 24)
+#define WMT_PIN_SD1DATA1	WMT_PIN(3, 25)
+#define WMT_PIN_SD1DATA2	WMT_PIN(3, 26)
+#define WMT_PIN_SD1DATA3	WMT_PIN(3, 27)
+#define WMT_PIN_SD1DATA4	WMT_PIN(3, 28)
+#define WMT_PIN_SD1DATA5	WMT_PIN(3, 29)
+#define WMT_PIN_SD1DATA6	WMT_PIN(3, 30)
+#define WMT_PIN_SD1DATA7	WMT_PIN(3, 31)
+#define WMT_PIN_I2C0_SCL	WMT_PIN(5, 8)
+#define WMT_PIN_I2C0_SDA	WMT_PIN(5, 9)
+#define WMT_PIN_I2C1_SCL	WMT_PIN(5, 10)
+#define WMT_PIN_I2C1_SDA	WMT_PIN(5, 11)
+#define WMT_PIN_I2C2_SCL	WMT_PIN(5, 12)
+#define WMT_PIN_I2C2_SDA	WMT_PIN(5, 13)
+#define WMT_PIN_UART0_RTS	WMT_PIN(5, 16)
+#define WMT_PIN_UART0_TXD	WMT_PIN(5, 17)
+#define WMT_PIN_UART0_CTS	WMT_PIN(5, 18)
+#define WMT_PIN_UART0_RXD	WMT_PIN(5, 19)
+#define WMT_PIN_UART1_RTS	WMT_PIN(5, 20)
+#define WMT_PIN_UART1_TXD	WMT_PIN(5, 21)
+#define WMT_PIN_UART1_CTS	WMT_PIN(5, 22)
+#define WMT_PIN_UART1_RXD	WMT_PIN(5, 23)
+#define WMT_PIN_UART2_RTS	WMT_PIN(5, 24)
+#define WMT_PIN_UART2_TXD	WMT_PIN(5, 25)
+#define WMT_PIN_UART2_CTS	WMT_PIN(5, 26)
+#define WMT_PIN_UART2_RXD	WMT_PIN(5, 27)
+#define WMT_PIN_UART3_RTS	WMT_PIN(5, 28)
+#define WMT_PIN_UART3_TXD	WMT_PIN(5, 29)
+#define WMT_PIN_UART3_CTS	WMT_PIN(5, 30)
+#define WMT_PIN_UART3_RXD	WMT_PIN(5, 31)
+#define WMT_PIN_SD2CD		WMT_PIN(6, 0)
+#define WMT_PIN_SD2DATA3	WMT_PIN(6, 1)
+#define WMT_PIN_SD2DATA0	WMT_PIN(6, 2)
+#define WMT_PIN_SD2WP		WMT_PIN(6, 3)
+#define WMT_PIN_SD2DATA1	WMT_PIN(6, 4)
+#define WMT_PIN_SD2DATA2	WMT_PIN(6, 5)
+#define WMT_PIN_SD2CMD		WMT_PIN(6, 6)
+#define WMT_PIN_SD2CLK		WMT_PIN(6, 7)
+#define WMT_PIN_SD2PWR		WMT_PIN(6, 9)
+#define WMT_PIN_SD1CLK		WMT_PIN(7, 0)
+#define WMT_PIN_SD1CMD		WMT_PIN(7, 1)
+#define WMT_PIN_SD1PWR		WMT_PIN(7, 10)
+#define WMT_PIN_SD1WP		WMT_PIN(7, 11)
+#define WMT_PIN_SD1CD		WMT_PIN(7, 12)
+#define WMT_PIN_SPI0SS3		WMT_PIN(7, 24)
+#define WMT_PIN_SPI0SS2		WMT_PIN(7, 25)
+#define WMT_PIN_PWMOUT1		WMT_PIN(7, 26)
+#define WMT_PIN_PWMOUT0		WMT_PIN(7, 27)
+
+static const struct pinctrl_pin_desc wm8750_pins[] = {
+	PINCTRL_PIN(WMT_PIN_EXTGPIO0, "extgpio0"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO1, "extgpio1"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO2, "extgpio2"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO3, "extgpio3"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO4, "extgpio4"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO5, "extgpio5"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO6, "extgpio6"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO7, "extgpio7"),
+	PINCTRL_PIN(WMT_PIN_WAKEUP0, "wakeup0"),
+	PINCTRL_PIN(WMT_PIN_WAKEUP1, "wakeup1"),
+	PINCTRL_PIN(WMT_PIN_SD0CD, "sd0_cd"),
+	PINCTRL_PIN(WMT_PIN_VDOUT0, "vdout0"),
+	PINCTRL_PIN(WMT_PIN_VDOUT1, "vdout1"),
+	PINCTRL_PIN(WMT_PIN_VDOUT2, "vdout2"),
+	PINCTRL_PIN(WMT_PIN_VDOUT3, "vdout3"),
+	PINCTRL_PIN(WMT_PIN_VDOUT4, "vdout4"),
+	PINCTRL_PIN(WMT_PIN_VDOUT5, "vdout5"),
+	PINCTRL_PIN(WMT_PIN_VDOUT6, "vdout6"),
+	PINCTRL_PIN(WMT_PIN_VDOUT7, "vdout7"),
+	PINCTRL_PIN(WMT_PIN_VDOUT8, "vdout8"),
+	PINCTRL_PIN(WMT_PIN_VDOUT9, "vdout9"),
+	PINCTRL_PIN(WMT_PIN_VDOUT10, "vdout10"),
+	PINCTRL_PIN(WMT_PIN_VDOUT11, "vdout11"),
+	PINCTRL_PIN(WMT_PIN_VDOUT12, "vdout12"),
+	PINCTRL_PIN(WMT_PIN_VDOUT13, "vdout13"),
+	PINCTRL_PIN(WMT_PIN_VDOUT14, "vdout14"),
+	PINCTRL_PIN(WMT_PIN_VDOUT15, "vdout15"),
+	PINCTRL_PIN(WMT_PIN_VDOUT16, "vdout16"),
+	PINCTRL_PIN(WMT_PIN_VDOUT17, "vdout17"),
+	PINCTRL_PIN(WMT_PIN_VDOUT18, "vdout18"),
+	PINCTRL_PIN(WMT_PIN_VDOUT19, "vdout19"),
+	PINCTRL_PIN(WMT_PIN_VDOUT20, "vdout20"),
+	PINCTRL_PIN(WMT_PIN_VDOUT21, "vdout21"),
+	PINCTRL_PIN(WMT_PIN_VDOUT22, "vdout22"),
+	PINCTRL_PIN(WMT_PIN_VDOUT23, "vdout23"),
+	PINCTRL_PIN(WMT_PIN_VDIN0, "vdin0"),
+	PINCTRL_PIN(WMT_PIN_VDIN1, "vdin1"),
+	PINCTRL_PIN(WMT_PIN_VDIN2, "vdin2"),
+	PINCTRL_PIN(WMT_PIN_VDIN3, "vdin3"),
+	PINCTRL_PIN(WMT_PIN_VDIN4, "vdin4"),
+	PINCTRL_PIN(WMT_PIN_VDIN5, "vdin5"),
+	PINCTRL_PIN(WMT_PIN_VDIN6, "vdin6"),
+	PINCTRL_PIN(WMT_PIN_VDIN7, "vdin7"),
+	PINCTRL_PIN(WMT_PIN_SPI0_MOSI, "spi0_mosi"),
+	PINCTRL_PIN(WMT_PIN_SPI0_MISO, "spi0_miso"),
+	PINCTRL_PIN(WMT_PIN_SPI0_SS, "spi0_ss"),
+	PINCTRL_PIN(WMT_PIN_SPI0_CLK, "spi0_clk"),
+	PINCTRL_PIN(WMT_PIN_SPI0_SSB, "spi0_ssb"),
+	PINCTRL_PIN(WMT_PIN_SD0CLK, "sd0_clk"),
+	PINCTRL_PIN(WMT_PIN_SD0CMD, "sd0_cmd"),
+	PINCTRL_PIN(WMT_PIN_SD0WP, "sd0_wp"),
+	PINCTRL_PIN(WMT_PIN_SD0DATA0, "sd0_data0"),
+	PINCTRL_PIN(WMT_PIN_SD0DATA1, "sd0_data1"),
+	PINCTRL_PIN(WMT_PIN_SD0DATA2, "sd0_data2"),
+	PINCTRL_PIN(WMT_PIN_SD0DATA3, "sd0_data3"),
+	PINCTRL_PIN(WMT_PIN_SD1DATA0, "sd1_data0"),
+	PINCTRL_PIN(WMT_PIN_SD1DATA1, "sd1_data1"),
+	PINCTRL_PIN(WMT_PIN_SD1DATA2, "sd1_data2"),
+	PINCTRL_PIN(WMT_PIN_SD1DATA3, "sd1_data3"),
+	PINCTRL_PIN(WMT_PIN_SD1DATA4, "sd1_data4"),
+	PINCTRL_PIN(WMT_PIN_SD1DATA5, "sd1_data5"),
+	PINCTRL_PIN(WMT_PIN_SD1DATA6, "sd1_data6"),
+	PINCTRL_PIN(WMT_PIN_SD1DATA7, "sd1_data7"),
+	PINCTRL_PIN(WMT_PIN_I2C0_SCL, "i2c0_scl"),
+	PINCTRL_PIN(WMT_PIN_I2C0_SDA, "i2c0_sda"),
+	PINCTRL_PIN(WMT_PIN_I2C1_SCL, "i2c1_scl"),
+	PINCTRL_PIN(WMT_PIN_I2C1_SDA, "i2c1_sda"),
+	PINCTRL_PIN(WMT_PIN_I2C2_SCL, "i2c2_scl"),
+	PINCTRL_PIN(WMT_PIN_I2C2_SDA, "i2c2_sda"),
+	PINCTRL_PIN(WMT_PIN_UART0_RTS, "uart0_rts"),
+	PINCTRL_PIN(WMT_PIN_UART0_TXD, "uart0_txd"),
+	PINCTRL_PIN(WMT_PIN_UART0_CTS, "uart0_cts"),
+	PINCTRL_PIN(WMT_PIN_UART0_RXD, "uart0_rxd"),
+	PINCTRL_PIN(WMT_PIN_UART1_RTS, "uart1_rts"),
+	PINCTRL_PIN(WMT_PIN_UART1_TXD, "uart1_txd"),
+	PINCTRL_PIN(WMT_PIN_UART1_CTS, "uart1_cts"),
+	PINCTRL_PIN(WMT_PIN_UART1_RXD, "uart1_rxd"),
+	PINCTRL_PIN(WMT_PIN_UART2_RTS, "uart2_rts"),
+	PINCTRL_PIN(WMT_PIN_UART2_TXD, "uart2_txd"),
+	PINCTRL_PIN(WMT_PIN_UART2_CTS, "uart2_cts"),
+	PINCTRL_PIN(WMT_PIN_UART2_RXD, "uart2_rxd"),
+	PINCTRL_PIN(WMT_PIN_UART3_RTS, "uart3_rts"),
+	PINCTRL_PIN(WMT_PIN_UART3_TXD, "uart3_txd"),
+	PINCTRL_PIN(WMT_PIN_UART3_CTS, "uart3_cts"),
+	PINCTRL_PIN(WMT_PIN_UART3_RXD, "uart3_rxd"),
+	PINCTRL_PIN(WMT_PIN_SD2CD, "sd2_cd"),
+	PINCTRL_PIN(WMT_PIN_SD2DATA3, "sd2_data3"),
+	PINCTRL_PIN(WMT_PIN_SD2DATA0, "sd2_data0"),
+	PINCTRL_PIN(WMT_PIN_SD2WP, "sd2_wp"),
+	PINCTRL_PIN(WMT_PIN_SD2DATA1, "sd2_data1"),
+	PINCTRL_PIN(WMT_PIN_SD2DATA2, "sd2_data2"),
+	PINCTRL_PIN(WMT_PIN_SD2CMD, "sd2_cmd"),
+	PINCTRL_PIN(WMT_PIN_SD2CLK, "sd2_clk"),
+	PINCTRL_PIN(WMT_PIN_SD2PWR, "sd2_pwr"),
+	PINCTRL_PIN(WMT_PIN_SD1CLK, "sd1_clk"),
+	PINCTRL_PIN(WMT_PIN_SD1CMD, "sd1_cmd"),
+	PINCTRL_PIN(WMT_PIN_SD1PWR, "sd1_pwr"),
+	PINCTRL_PIN(WMT_PIN_SD1WP, "sd1_wp"),
+	PINCTRL_PIN(WMT_PIN_SD1CD, "sd1_cd"),
+	PINCTRL_PIN(WMT_PIN_SPI0SS3, "spi0_ss3"),
+	PINCTRL_PIN(WMT_PIN_SPI0SS2, "spi0_ss2"),
+	PINCTRL_PIN(WMT_PIN_PWMOUT1, "pwmout1"),
+	PINCTRL_PIN(WMT_PIN_PWMOUT0, "pwmout0"),
+};
+
+/* Order of these names must match the above list */
+static const char * const wm8750_groups[] = {
+	"extgpio0",
+	"extgpio1",
+	"extgpio2",
+	"extgpio3",
+	"extgpio4",
+	"extgpio5",
+	"extgpio6",
+	"extgpio7",
+	"wakeup0",
+	"wakeup1",
+	"sd0_cd",
+	"vdout0",
+	"vdout1",
+	"vdout2",
+	"vdout3",
+	"vdout4",
+	"vdout5",
+	"vdout6",
+	"vdout7",
+	"vdout8",
+	"vdout9",
+	"vdout10",
+	"vdout11",
+	"vdout12",
+	"vdout13",
+	"vdout14",
+	"vdout15",
+	"vdout16",
+	"vdout17",
+	"vdout18",
+	"vdout19",
+	"vdout20",
+	"vdout21",
+	"vdout22",
+	"vdout23",
+	"vdin0",
+	"vdin1",
+	"vdin2",
+	"vdin3",
+	"vdin4",
+	"vdin5",
+	"vdin6",
+	"vdin7",
+	"spi0_mosi",
+	"spi0_miso",
+	"spi0_ss",
+	"spi0_clk",
+	"spi0_ssb",
+	"sd0_clk",
+	"sd0_cmd",
+	"sd0_wp",
+	"sd0_data0",
+	"sd0_data1",
+	"sd0_data2",
+	"sd0_data3",
+	"sd1_data0",
+	"sd1_data1",
+	"sd1_data2",
+	"sd1_data3",
+	"sd1_data4",
+	"sd1_data5",
+	"sd1_data6",
+	"sd1_data7",
+	"i2c0_scl",
+	"i2c0_sda",
+	"i2c1_scl",
+	"i2c1_sda",
+	"i2c2_scl",
+	"i2c2_sda",
+	"uart0_rts",
+	"uart0_txd",
+	"uart0_cts",
+	"uart0_rxd",
+	"uart1_rts",
+	"uart1_txd",
+	"uart1_cts",
+	"uart1_rxd",
+	"uart2_rts",
+	"uart2_txd",
+	"uart2_cts",
+	"uart2_rxd",
+	"uart3_rts",
+	"uart3_txd",
+	"uart3_cts",
+	"uart3_rxd",
+	"sd2_cd",
+	"sd2_data3",
+	"sd2_data0",
+	"sd2_wp",
+	"sd2_data1",
+	"sd2_data2",
+	"sd2_cmd",
+	"sd2_clk",
+	"sd2_pwr",
+	"sd1_clk",
+	"sd1_cmd",
+	"sd1_pwr",
+	"sd1_wp",
+	"sd1_cd",
+	"spi0_ss3",
+	"spi0_ss2",
+	"pwmout1",
+	"pwmout0",
+};
+
+static int wm8750_pinctrl_probe(struct platform_device *pdev)
+{
+	struct wmt_pinctrl_data *data;
+
+	data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
+	if (!data) {
+		dev_err(&pdev->dev, "failed to allocate data\n");
+		return -ENOMEM;
+	}
+
+	data->banks = wm8750_banks;
+	data->nbanks = ARRAY_SIZE(wm8750_banks);
+	data->pins = wm8750_pins;
+	data->npins = ARRAY_SIZE(wm8750_pins);
+	data->groups = wm8750_groups;
+	data->ngroups = ARRAY_SIZE(wm8750_groups);
+
+	return wmt_pinctrl_probe(pdev, data);
+}
+
+static int wm8750_pinctrl_remove(struct platform_device *pdev)
+{
+	return wmt_pinctrl_remove(pdev);
+}
+
+static struct of_device_id wmt_pinctrl_of_match[] = {
+	{ .compatible = "wm,wm8750-pinctrl" },
+	{ /* sentinel */ },
+};
+
+static struct platform_driver wmt_pinctrl_driver = {
+	.probe	= wm8750_pinctrl_probe,
+	.remove	= wm8750_pinctrl_remove,
+	.driver = {
+		.name	= "pinctrl-wm8750",
+		.owner	= THIS_MODULE,
+		.of_match_table	= wmt_pinctrl_of_match,
+	},
+};
+
+module_platform_driver(wmt_pinctrl_driver);
+
+MODULE_AUTHOR("Tony Prisk <linux at prisktech.co.nz>");
+MODULE_DESCRIPTION("Wondermedia WM8750 Pincontrol driver");
+MODULE_LICENSE("GPL v2");
+MODULE_DEVICE_TABLE(of, wmt_pinctrl_of_match);
diff --git a/drivers/pinctrl/vt8500/pinctrl-wm8850.c b/drivers/pinctrl/vt8500/pinctrl-wm8850.c
new file mode 100644
index 0000000..ecadce9c
--- /dev/null
+++ b/drivers/pinctrl/vt8500/pinctrl-wm8850.c
@@ -0,0 +1,388 @@
+/*
+ * Pinctrl data for Wondermedia WM8850 SoC
+ *
+ * Copyright (c) 2013 Tony Prisk <linux at prisktech.co.nz>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ */
+
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/pinctrl/pinctrl.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+
+#include "pinctrl-wmt.h"
+
+/*
+ * Describe the register offsets within the GPIO memory space
+ * The dedicated external GPIO's should always be listed in bank 0
+ * so they are exported in the 0..31 range which is what users
+ * expect.
+ *
+ * Do not reorder these banks as it will change the pin numbering
+ */
+static const struct wmt_pinctrl_bank_registers wm8850_banks[] = {
+	WMT_PINCTRL_BANK(0x40, 0x80, 0xC0, 0x00, 0x480, 0x4C0),		/* 0 */
+	WMT_PINCTRL_BANK(0x44, 0x84, 0xC4, 0x04, 0x484, 0x4C4),		/* 1 */
+	WMT_PINCTRL_BANK(0x48, 0x88, 0xC8, 0x08, 0x488, 0x4C8),		/* 2 */
+	WMT_PINCTRL_BANK(0x4C, 0x8C, 0xCC, 0x0C, 0x48C, 0x4CC),		/* 3 */
+	WMT_PINCTRL_BANK(0x50, 0x90, 0xD0, 0x10, 0x490, 0x4D0),		/* 4 */
+	WMT_PINCTRL_BANK(0x54, 0x94, 0xD4, 0x14, 0x494, 0x4D4),		/* 5 */
+	WMT_PINCTRL_BANK(0x58, 0x98, 0xD8, 0x18, 0x498, 0x4D8),		/* 6 */
+	WMT_PINCTRL_BANK(0x5C, 0x9C, 0xDC, 0x1C, 0x49C, 0x4DC),		/* 7 */
+	WMT_PINCTRL_BANK(0x60, 0xA0, 0xE0, 0x20, 0x4A0, 0x4E0),		/* 8 */
+	WMT_PINCTRL_BANK(0x70, 0xB0, 0xF0, 0x30, 0x4B0, 0x4F0),		/* 9 */
+	WMT_PINCTRL_BANK(0x7C, 0xBC, 0xDC, 0x3C, 0x4BC, 0x4FC),		/* 10 */
+};
+
+/* Please keep sorted by bank/bit */
+#define WMT_PIN_EXTGPIO0	WMT_PIN(0, 0)
+#define WMT_PIN_EXTGPIO1	WMT_PIN(0, 1)
+#define WMT_PIN_EXTGPIO2	WMT_PIN(0, 2)
+#define WMT_PIN_EXTGPIO3	WMT_PIN(0, 3)
+#define WMT_PIN_EXTGPIO4	WMT_PIN(0, 4)
+#define WMT_PIN_EXTGPIO5	WMT_PIN(0, 5)
+#define WMT_PIN_EXTGPIO6	WMT_PIN(0, 6)
+#define WMT_PIN_EXTGPIO7	WMT_PIN(0, 7)
+#define WMT_PIN_WAKEUP0		WMT_PIN(0, 16)
+#define WMT_PIN_WAKEUP1		WMT_PIN(0, 17)
+#define WMT_PIN_WAKEUP2		WMT_PIN(0, 18)
+#define WMT_PIN_WAKEUP3		WMT_PIN(0, 19)
+#define WMT_PIN_SUSGPIO0	WMT_PIN(0, 21)
+#define WMT_PIN_SUSGPIO1	WMT_PIN(0, 22)
+#define WMT_PIN_SD0CD		WMT_PIN(0, 28)
+#define WMT_PIN_VDOUT0		WMT_PIN(1, 0)
+#define WMT_PIN_VDOUT1		WMT_PIN(1, 1)
+#define WMT_PIN_VDOUT2		WMT_PIN(1, 2)
+#define WMT_PIN_VDOUT3		WMT_PIN(1, 3)
+#define WMT_PIN_VDOUT4		WMT_PIN(1, 4)
+#define WMT_PIN_VDOUT5		WMT_PIN(1, 5)
+#define WMT_PIN_VDOUT6		WMT_PIN(1, 6)
+#define WMT_PIN_VDOUT7		WMT_PIN(1, 7)
+#define WMT_PIN_VDOUT8		WMT_PIN(1, 8)
+#define WMT_PIN_VDOUT9		WMT_PIN(1, 9)
+#define WMT_PIN_VDOUT10		WMT_PIN(1, 10)
+#define WMT_PIN_VDOUT11		WMT_PIN(1, 11)
+#define WMT_PIN_VDOUT12		WMT_PIN(1, 12)
+#define WMT_PIN_VDOUT13		WMT_PIN(1, 13)
+#define WMT_PIN_VDOUT14		WMT_PIN(1, 14)
+#define WMT_PIN_VDOUT15		WMT_PIN(1, 15)
+#define WMT_PIN_VDOUT16		WMT_PIN(1, 16)
+#define WMT_PIN_VDOUT17		WMT_PIN(1, 17)
+#define WMT_PIN_VDOUT18		WMT_PIN(1, 18)
+#define WMT_PIN_VDOUT19		WMT_PIN(1, 19)
+#define WMT_PIN_VDOUT20		WMT_PIN(1, 20)
+#define WMT_PIN_VDOUT21		WMT_PIN(1, 21)
+#define WMT_PIN_VDOUT22		WMT_PIN(1, 22)
+#define WMT_PIN_VDOUT23		WMT_PIN(1, 23)
+#define WMT_PIN_VDIN0		WMT_PIN(2, 0)
+#define WMT_PIN_VDIN1		WMT_PIN(2, 1)
+#define WMT_PIN_VDIN2		WMT_PIN(2, 2)
+#define WMT_PIN_VDIN3		WMT_PIN(2, 3)
+#define WMT_PIN_VDIN4		WMT_PIN(2, 4)
+#define WMT_PIN_VDIN5		WMT_PIN(2, 5)
+#define WMT_PIN_VDIN6		WMT_PIN(2, 6)
+#define WMT_PIN_VDIN7		WMT_PIN(2, 7)
+#define WMT_PIN_SPI0_MOSI	WMT_PIN(2, 24)
+#define WMT_PIN_SPI0_MISO	WMT_PIN(2, 25)
+#define WMT_PIN_SPI0_SS		WMT_PIN(2, 26)
+#define WMT_PIN_SPI0_CLK	WMT_PIN(2, 27)
+#define WMT_PIN_SPI0_SSB	WMT_PIN(2, 28)
+#define WMT_PIN_SD0CLK		WMT_PIN(3, 17)
+#define WMT_PIN_SD0CMD		WMT_PIN(3, 18)
+#define WMT_PIN_SD0WP		WMT_PIN(3, 19)
+#define WMT_PIN_SD0DATA0	WMT_PIN(3, 20)
+#define WMT_PIN_SD0DATA1	WMT_PIN(3, 21)
+#define WMT_PIN_SD0DATA2	WMT_PIN(3, 22)
+#define WMT_PIN_SD0DATA3	WMT_PIN(3, 23)
+#define WMT_PIN_SD1DATA0	WMT_PIN(3, 24)
+#define WMT_PIN_SD1DATA1	WMT_PIN(3, 25)
+#define WMT_PIN_SD1DATA2	WMT_PIN(3, 26)
+#define WMT_PIN_SD1DATA3	WMT_PIN(3, 27)
+#define WMT_PIN_SD1DATA4	WMT_PIN(3, 28)
+#define WMT_PIN_SD1DATA5	WMT_PIN(3, 29)
+#define WMT_PIN_SD1DATA6	WMT_PIN(3, 30)
+#define WMT_PIN_SD1DATA7	WMT_PIN(3, 31)
+#define WMT_PIN_I2C0_SCL	WMT_PIN(5, 8)
+#define WMT_PIN_I2C0_SDA	WMT_PIN(5, 9)
+#define WMT_PIN_I2C1_SCL	WMT_PIN(5, 10)
+#define WMT_PIN_I2C1_SDA	WMT_PIN(5, 11)
+#define WMT_PIN_I2C2_SCL	WMT_PIN(5, 12)
+#define WMT_PIN_I2C2_SDA	WMT_PIN(5, 13)
+#define WMT_PIN_UART0_RTS	WMT_PIN(5, 16)
+#define WMT_PIN_UART0_TXD	WMT_PIN(5, 17)
+#define WMT_PIN_UART0_CTS	WMT_PIN(5, 18)
+#define WMT_PIN_UART0_RXD	WMT_PIN(5, 19)
+#define WMT_PIN_UART1_RTS	WMT_PIN(5, 20)
+#define WMT_PIN_UART1_TXD	WMT_PIN(5, 21)
+#define WMT_PIN_UART1_CTS	WMT_PIN(5, 22)
+#define WMT_PIN_UART1_RXD	WMT_PIN(5, 23)
+#define WMT_PIN_UART2_RTS	WMT_PIN(5, 24)
+#define WMT_PIN_UART2_TXD	WMT_PIN(5, 25)
+#define WMT_PIN_UART2_CTS	WMT_PIN(5, 26)
+#define WMT_PIN_UART2_RXD	WMT_PIN(5, 27)
+#define WMT_PIN_SD2WP		WMT_PIN(6, 3)
+#define WMT_PIN_SD2CMD		WMT_PIN(6, 6)
+#define WMT_PIN_SD2CLK		WMT_PIN(6, 7)
+#define WMT_PIN_SD2PWR		WMT_PIN(6, 9)
+#define WMT_PIN_SD1CLK		WMT_PIN(7, 0)
+#define WMT_PIN_SD1CMD		WMT_PIN(7, 1)
+#define WMT_PIN_SD1PWR		WMT_PIN(7, 10)
+#define WMT_PIN_SD1WP		WMT_PIN(7, 11)
+#define WMT_PIN_SD1CD		WMT_PIN(7, 12)
+#define WMT_PIN_PWMOUT1		WMT_PIN(7, 26)
+#define WMT_PIN_PWMOUT0		WMT_PIN(7, 27)
+
+static const struct pinctrl_pin_desc wm8850_pins[] = {
+	PINCTRL_PIN(WMT_PIN_EXTGPIO0, "extgpio0"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO1, "extgpio1"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO2, "extgpio2"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO3, "extgpio3"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO4, "extgpio4"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO5, "extgpio5"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO6, "extgpio6"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO7, "extgpio7"),
+	PINCTRL_PIN(WMT_PIN_WAKEUP0, "wakeup0"),
+	PINCTRL_PIN(WMT_PIN_WAKEUP1, "wakeup1"),
+	PINCTRL_PIN(WMT_PIN_WAKEUP2, "wakeup2"),
+	PINCTRL_PIN(WMT_PIN_WAKEUP3, "wakeup3"),
+	PINCTRL_PIN(WMT_PIN_SUSGPIO0, "susgpio0"),
+	PINCTRL_PIN(WMT_PIN_SUSGPIO1, "susgpio1"),
+	PINCTRL_PIN(WMT_PIN_SD0CD, "sd0_cd"),
+	PINCTRL_PIN(WMT_PIN_VDOUT0, "vdout0"),
+	PINCTRL_PIN(WMT_PIN_VDOUT1, "vdout1"),
+	PINCTRL_PIN(WMT_PIN_VDOUT2, "vdout2"),
+	PINCTRL_PIN(WMT_PIN_VDOUT3, "vdout3"),
+	PINCTRL_PIN(WMT_PIN_VDOUT4, "vdout4"),
+	PINCTRL_PIN(WMT_PIN_VDOUT5, "vdout5"),
+	PINCTRL_PIN(WMT_PIN_VDOUT6, "vdout6"),
+	PINCTRL_PIN(WMT_PIN_VDOUT7, "vdout7"),
+	PINCTRL_PIN(WMT_PIN_VDOUT8, "vdout8"),
+	PINCTRL_PIN(WMT_PIN_VDOUT9, "vdout9"),
+	PINCTRL_PIN(WMT_PIN_VDOUT10, "vdout10"),
+	PINCTRL_PIN(WMT_PIN_VDOUT11, "vdout11"),
+	PINCTRL_PIN(WMT_PIN_VDOUT12, "vdout12"),
+	PINCTRL_PIN(WMT_PIN_VDOUT13, "vdout13"),
+	PINCTRL_PIN(WMT_PIN_VDOUT14, "vdout14"),
+	PINCTRL_PIN(WMT_PIN_VDOUT15, "vdout15"),
+	PINCTRL_PIN(WMT_PIN_VDOUT16, "vdout16"),
+	PINCTRL_PIN(WMT_PIN_VDOUT17, "vdout17"),
+	PINCTRL_PIN(WMT_PIN_VDOUT18, "vdout18"),
+	PINCTRL_PIN(WMT_PIN_VDOUT19, "vdout19"),
+	PINCTRL_PIN(WMT_PIN_VDOUT20, "vdout20"),
+	PINCTRL_PIN(WMT_PIN_VDOUT21, "vdout21"),
+	PINCTRL_PIN(WMT_PIN_VDOUT22, "vdout22"),
+	PINCTRL_PIN(WMT_PIN_VDOUT23, "vdout23"),
+	PINCTRL_PIN(WMT_PIN_VDIN0, "vdin0"),
+	PINCTRL_PIN(WMT_PIN_VDIN1, "vdin1"),
+	PINCTRL_PIN(WMT_PIN_VDIN2, "vdin2"),
+	PINCTRL_PIN(WMT_PIN_VDIN3, "vdin3"),
+	PINCTRL_PIN(WMT_PIN_VDIN4, "vdin4"),
+	PINCTRL_PIN(WMT_PIN_VDIN5, "vdin5"),
+	PINCTRL_PIN(WMT_PIN_VDIN6, "vdin6"),
+	PINCTRL_PIN(WMT_PIN_VDIN7, "vdin7"),
+	PINCTRL_PIN(WMT_PIN_SPI0_MOSI, "spi0_mosi"),
+	PINCTRL_PIN(WMT_PIN_SPI0_MISO, "spi0_miso"),
+	PINCTRL_PIN(WMT_PIN_SPI0_SS, "spi0_ss"),
+	PINCTRL_PIN(WMT_PIN_SPI0_CLK, "spi0_clk"),
+	PINCTRL_PIN(WMT_PIN_SPI0_SSB, "spi0_ssb"),
+	PINCTRL_PIN(WMT_PIN_SD0CLK, "sd0_clk"),
+	PINCTRL_PIN(WMT_PIN_SD0CMD, "sd0_cmd"),
+	PINCTRL_PIN(WMT_PIN_SD0WP, "sd0_wp"),
+	PINCTRL_PIN(WMT_PIN_SD0DATA0, "sd0_data0"),
+	PINCTRL_PIN(WMT_PIN_SD0DATA1, "sd0_data1"),
+	PINCTRL_PIN(WMT_PIN_SD0DATA2, "sd0_data2"),
+	PINCTRL_PIN(WMT_PIN_SD0DATA3, "sd0_data3"),
+	PINCTRL_PIN(WMT_PIN_SD1DATA0, "sd1_data0"),
+	PINCTRL_PIN(WMT_PIN_SD1DATA1, "sd1_data1"),
+	PINCTRL_PIN(WMT_PIN_SD1DATA2, "sd1_data2"),
+	PINCTRL_PIN(WMT_PIN_SD1DATA3, "sd1_data3"),
+	PINCTRL_PIN(WMT_PIN_SD1DATA4, "sd1_data4"),
+	PINCTRL_PIN(WMT_PIN_SD1DATA5, "sd1_data5"),
+	PINCTRL_PIN(WMT_PIN_SD1DATA6, "sd1_data6"),
+	PINCTRL_PIN(WMT_PIN_SD1DATA7, "sd1_data7"),
+	PINCTRL_PIN(WMT_PIN_I2C0_SCL, "i2c0_scl"),
+	PINCTRL_PIN(WMT_PIN_I2C0_SDA, "i2c0_sda"),
+	PINCTRL_PIN(WMT_PIN_I2C1_SCL, "i2c1_scl"),
+	PINCTRL_PIN(WMT_PIN_I2C1_SDA, "i2c1_sda"),
+	PINCTRL_PIN(WMT_PIN_I2C2_SCL, "i2c2_scl"),
+	PINCTRL_PIN(WMT_PIN_I2C2_SDA, "i2c2_sda"),
+	PINCTRL_PIN(WMT_PIN_UART0_RTS, "uart0_rts"),
+	PINCTRL_PIN(WMT_PIN_UART0_TXD, "uart0_txd"),
+	PINCTRL_PIN(WMT_PIN_UART0_CTS, "uart0_cts"),
+	PINCTRL_PIN(WMT_PIN_UART0_RXD, "uart0_rxd"),
+	PINCTRL_PIN(WMT_PIN_UART1_RTS, "uart1_rts"),
+	PINCTRL_PIN(WMT_PIN_UART1_TXD, "uart1_txd"),
+	PINCTRL_PIN(WMT_PIN_UART1_CTS, "uart1_cts"),
+	PINCTRL_PIN(WMT_PIN_UART1_RXD, "uart1_rxd"),
+	PINCTRL_PIN(WMT_PIN_UART2_RTS, "uart2_rts"),
+	PINCTRL_PIN(WMT_PIN_UART2_TXD, "uart2_txd"),
+	PINCTRL_PIN(WMT_PIN_UART2_CTS, "uart2_cts"),
+	PINCTRL_PIN(WMT_PIN_UART2_RXD, "uart2_rxd"),
+	PINCTRL_PIN(WMT_PIN_SD2WP, "sd2_wp"),
+	PINCTRL_PIN(WMT_PIN_SD2CMD, "sd2_cmd"),
+	PINCTRL_PIN(WMT_PIN_SD2CLK, "sd2_clk"),
+	PINCTRL_PIN(WMT_PIN_SD2PWR, "sd2_pwr"),
+	PINCTRL_PIN(WMT_PIN_SD1CLK, "sd1_clk"),
+	PINCTRL_PIN(WMT_PIN_SD1CMD, "sd1_cmd"),
+	PINCTRL_PIN(WMT_PIN_SD1PWR, "sd1_pwr"),
+	PINCTRL_PIN(WMT_PIN_SD1WP, "sd1_wp"),
+	PINCTRL_PIN(WMT_PIN_SD1CD, "sd1_cd"),
+	PINCTRL_PIN(WMT_PIN_PWMOUT1, "pwmout1"),
+	PINCTRL_PIN(WMT_PIN_PWMOUT0, "pwmout0"),
+};
+
+/* Order of these names must match the above list */
+static const char * const wm8850_groups[] = {
+	"extgpio0",
+	"extgpio1",
+	"extgpio2",
+	"extgpio3",
+	"extgpio4",
+	"extgpio5",
+	"extgpio6",
+	"extgpio7",
+	"wakeup0",
+	"wakeup1",
+	"wakeup2",
+	"wakeup3",
+	"susgpio0",
+	"susgpio1",
+	"sd0_cd",
+	"vdout0",
+	"vdout1",
+	"vdout2",
+	"vdout3",
+	"vdout4",
+	"vdout5",
+	"vdout6",
+	"vdout7",
+	"vdout8",
+	"vdout9",
+	"vdout10",
+	"vdout11",
+	"vdout12",
+	"vdout13",
+	"vdout14",
+	"vdout15",
+	"vdout16",
+	"vdout17",
+	"vdout18",
+	"vdout19",
+	"vdout20",
+	"vdout21",
+	"vdout22",
+	"vdout23",
+	"vdin0",
+	"vdin1",
+	"vdin2",
+	"vdin3",
+	"vdin4",
+	"vdin5",
+	"vdin6",
+	"vdin7",
+	"spi0_mosi",
+	"spi0_miso",
+	"spi0_ss",
+	"spi0_clk",
+	"spi0_ssb",
+	"sd0_clk",
+	"sd0_cmd",
+	"sd0_wp",
+	"sd0_data0",
+	"sd0_data1",
+	"sd0_data2",
+	"sd0_data3",
+	"sd1_data0",
+	"sd1_data1",
+	"sd1_data2",
+	"sd1_data3",
+	"sd1_data4",
+	"sd1_data5",
+	"sd1_data6",
+	"sd1_data7",
+	"i2c0_scl",
+	"i2c0_sda",
+	"i2c1_scl",
+	"i2c1_sda",
+	"i2c2_scl",
+	"i2c2_sda",
+	"uart0_rts",
+	"uart0_txd",
+	"uart0_cts",
+	"uart0_rxd",
+	"uart1_rts",
+	"uart1_txd",
+	"uart1_cts",
+	"uart1_rxd",
+	"uart2_rts",
+	"uart2_txd",
+	"uart2_cts",
+	"uart2_rxd",
+	"sd2_wp",
+	"sd2_cmd",
+	"sd2_clk",
+	"sd2_pwr",
+	"sd1_clk",
+	"sd1_cmd",
+	"sd1_pwr",
+	"sd1_wp",
+	"sd1_cd",
+	"pwmout1",
+	"pwmout0",
+};
+
+static int wm8850_pinctrl_probe(struct platform_device *pdev)
+{
+	struct wmt_pinctrl_data *data;
+
+	data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
+	if (!data) {
+		dev_err(&pdev->dev, "failed to allocate data\n");
+		return -ENOMEM;
+	}
+
+	data->banks = wm8850_banks;
+	data->nbanks = ARRAY_SIZE(wm8850_banks);
+	data->pins = wm8850_pins;
+	data->npins = ARRAY_SIZE(wm8850_pins);
+	data->groups = wm8850_groups;
+	data->ngroups = ARRAY_SIZE(wm8850_groups);
+
+	return wmt_pinctrl_probe(pdev, data);
+}
+
+static int wm8850_pinctrl_remove(struct platform_device *pdev)
+{
+	return wmt_pinctrl_remove(pdev);
+}
+
+static struct of_device_id wmt_pinctrl_of_match[] = {
+	{ .compatible = "wm,wm8850-pinctrl" },
+	{ /* sentinel */ },
+};
+
+static struct platform_driver wmt_pinctrl_driver = {
+	.probe	= wm8850_pinctrl_probe,
+	.remove	= wm8850_pinctrl_remove,
+	.driver = {
+		.name	= "pinctrl-wm8850",
+		.owner	= THIS_MODULE,
+		.of_match_table	= wmt_pinctrl_of_match,
+	},
+};
+
+module_platform_driver(wmt_pinctrl_driver);
+
+MODULE_AUTHOR("Tony Prisk <linux at prisktech.co.nz>");
+MODULE_DESCRIPTION("Wondermedia WM8850 Pincontrol driver");
+MODULE_LICENSE("GPL v2");
+MODULE_DEVICE_TABLE(of, wmt_pinctrl_of_match);
diff --git a/drivers/pinctrl/vt8500/pinctrl-wmt.c b/drivers/pinctrl/vt8500/pinctrl-wmt.c
new file mode 100644
index 0000000..9736d27
--- /dev/null
+++ b/drivers/pinctrl/vt8500/pinctrl-wmt.c
@@ -0,0 +1,620 @@
+/*
+ * Pinctrl driver for the Wondermedia SoC's
+ *
+ * Copyright (c) 2013 Tony Prisk <linux at prisktech.co.nz>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ */
+
+#include <linux/err.h>
+#include <linux/gpio.h>
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/irq.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_irq.h>
+#include <linux/pinctrl/consumer.h>
+#include <linux/pinctrl/machine.h>
+#include <linux/pinctrl/pinconf.h>
+#include <linux/pinctrl/pinconf-generic.h>
+#include <linux/pinctrl/pinctrl.h>
+#include <linux/pinctrl/pinmux.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+
+#include "pinctrl-wmt.h"
+
+static inline void wmt_setbits(struct wmt_pinctrl_data *data, u32 reg,
+				 u32 mask)
+{
+	u32 val;
+
+	val = readl_relaxed(data->base + reg);
+	val |= mask;
+	writel_relaxed(val, data->base + reg);
+}
+
+static inline void wmt_clearbits(struct wmt_pinctrl_data *data, u32 reg,
+				   u32 mask)
+{
+	u32 val;
+
+	val = readl_relaxed(data->base + reg);
+	val &= ~mask;
+	writel_relaxed(val, data->base + reg);
+}
+
+enum wmt_func_sel {
+	WMT_FSEL_GPIO_IN = 0,
+	WMT_FSEL_GPIO_OUT = 1,
+	WMT_FSEL_ALT = 2,
+	WMT_FSEL_COUNT = 3,
+};
+
+static const char * const wmt_functions[WMT_FSEL_COUNT] = {
+	[WMT_FSEL_GPIO_IN] = "gpio_in",
+	[WMT_FSEL_GPIO_OUT] = "gpio_out",
+	[WMT_FSEL_ALT] = "alt",
+};
+
+static int wmt_pmx_get_functions_count(struct pinctrl_dev *pctldev)
+{
+	return WMT_FSEL_COUNT;
+}
+
+static const char *wmt_pmx_get_function_name(struct pinctrl_dev *pctldev,
+					     unsigned selector)
+{
+	return wmt_functions[selector];
+}
+
+static int wmt_pmx_get_function_groups(struct pinctrl_dev *pctldev,
+				       unsigned selector,
+				       const char * const **groups,
+				       unsigned * const num_groups)
+{
+	struct wmt_pinctrl_data *data = pinctrl_dev_get_drvdata(pctldev);
+
+	/* every pin does every function */
+	*groups = data->groups;
+	*num_groups = data->ngroups;
+
+	return 0;
+}
+
+static int wmt_set_pinmux(struct wmt_pinctrl_data *data, unsigned func,
+			  unsigned pin)
+{
+	u32 bank = WMT_BANK_FROM_PIN(pin);
+	u32 bit = WMT_BIT_FROM_PIN(pin);
+	u32 reg_en = data->banks[bank].reg_en;
+	u32 reg_dir = data->banks[bank].reg_dir;
+
+	if (reg_dir == NO_REG) {
+		dev_err(data->dev, "pin:%d no direction register defined\n",
+			pin);
+		return -EINVAL;
+	}
+
+	/*
+	 * If reg_en == NO_REG, we assume it is a dedicated GPIO and cannot be
+	 * disabled (as on VT8500) and that no alternate function is available.
+	 */
+	switch (func) {
+	case WMT_FSEL_GPIO_IN:
+		if (reg_en != NO_REG)
+			wmt_setbits(data, reg_en, BIT(bit));
+		wmt_clearbits(data, reg_dir, BIT(bit));
+		break;
+	case WMT_FSEL_GPIO_OUT:
+		if (reg_en != NO_REG)
+			wmt_setbits(data, reg_en, BIT(bit));
+		wmt_setbits(data, reg_dir, BIT(bit));
+		break;
+	case WMT_FSEL_ALT:
+		if (reg_en == NO_REG) {
+			dev_err(data->dev, "pin:%d no alt function available\n",
+				pin);
+			return -EINVAL;
+		}
+		wmt_clearbits(data, reg_en, BIT(bit));
+	}
+
+	return 0;
+}
+
+static int wmt_pmx_enable(struct pinctrl_dev *pctldev,
+			  unsigned func_selector,
+			  unsigned group_selector)
+{
+	struct wmt_pinctrl_data *data = pinctrl_dev_get_drvdata(pctldev);
+	u32 pinnum = data->pins[group_selector].number;
+
+	return wmt_set_pinmux(data, func_selector, pinnum);
+}
+
+static void wmt_pmx_disable(struct pinctrl_dev *pctldev,
+			    unsigned func_selector,
+			    unsigned group_selector)
+{
+	struct wmt_pinctrl_data *data = pinctrl_dev_get_drvdata(pctldev);
+	u32 pinnum = data->pins[group_selector].number;
+
+	/* disable by setting GPIO_IN */
+	wmt_set_pinmux(data, WMT_FSEL_GPIO_IN, pinnum);
+}
+
+static void wmt_pmx_gpio_disable_free(struct pinctrl_dev *pctldev,
+				      struct pinctrl_gpio_range *range,
+				      unsigned offset)
+{
+	struct wmt_pinctrl_data *data = pinctrl_dev_get_drvdata(pctldev);
+
+	/* disable by setting GPIO_IN */
+	wmt_set_pinmux(data, WMT_FSEL_GPIO_IN, offset);
+}
+
+static int wmt_pmx_gpio_set_direction(struct pinctrl_dev *pctldev,
+				      struct pinctrl_gpio_range *range,
+				      unsigned offset,
+				      bool input)
+{
+	struct wmt_pinctrl_data *data = pinctrl_dev_get_drvdata(pctldev);
+
+	wmt_set_pinmux(data, (input ? WMT_FSEL_GPIO_IN : WMT_FSEL_GPIO_OUT),
+		       offset);
+
+	return 0;
+}
+
+static struct pinmux_ops wmt_pinmux_ops = {
+	.get_functions_count = wmt_pmx_get_functions_count,
+	.get_function_name = wmt_pmx_get_function_name,
+	.get_function_groups = wmt_pmx_get_function_groups,
+	.enable = wmt_pmx_enable,
+	.disable = wmt_pmx_disable,
+	.gpio_disable_free = wmt_pmx_gpio_disable_free,
+	.gpio_set_direction = wmt_pmx_gpio_set_direction,
+};
+
+static int wmt_get_groups_count(struct pinctrl_dev *pctldev)
+{
+	struct wmt_pinctrl_data *data = pinctrl_dev_get_drvdata(pctldev);
+
+	return data->ngroups;
+}
+
+static const char *wmt_get_group_name(struct pinctrl_dev *pctldev,
+				      unsigned selector)
+{
+	struct wmt_pinctrl_data *data = pinctrl_dev_get_drvdata(pctldev);
+
+	return data->groups[selector];
+}
+
+static int wmt_get_group_pins(struct pinctrl_dev *pctldev,
+			      unsigned selector,
+			      const unsigned **pins,
+			      unsigned *num_pins)
+{
+	struct wmt_pinctrl_data *data = pinctrl_dev_get_drvdata(pctldev);
+
+	*pins = &data->pins[selector].number;
+	*num_pins = 1;
+
+	return 0;
+}
+
+static int wmt_pctl_find_group_by_pin(struct wmt_pinctrl_data *data, u32 pin)
+{
+	int i;
+
+	for (i = 0; i < data->npins; i++) {
+		if (data->pins[i].number == pin)
+			return i;
+	}
+
+	return -EINVAL;
+}
+
+static int wmt_pctl_dt_node_to_map_func(struct wmt_pinctrl_data *data,
+					struct device_node *np,
+					u32 pin, u32 fnum,
+					struct pinctrl_map **maps)
+{
+	int group;
+	struct pinctrl_map *map = *maps;
+
+	if (fnum >= ARRAY_SIZE(wmt_functions)) {
+		dev_err(data->dev, "invalid wm,function %d\n", fnum);
+		return -EINVAL;
+	}
+
+	group = wmt_pctl_find_group_by_pin(data, pin);
+	if (group < 0) {
+		dev_err(data->dev, "unable to match pin %d to group\n", pin);
+		return group;
+	}
+
+	map->type = PIN_MAP_TYPE_MUX_GROUP;
+	map->data.mux.group = data->groups[group];
+	map->data.mux.function = wmt_functions[fnum];
+	(*maps)++;
+
+	return 0;
+}
+
+static int wmt_pctl_dt_node_to_map_pull(struct wmt_pinctrl_data *data,
+					struct device_node *np,
+					u32 pin, u32 pull,
+					struct pinctrl_map **maps)
+{
+	int group;
+	unsigned long *configs;
+	struct pinctrl_map *map = *maps;
+
+	if (pull > 2) {
+		dev_err(data->dev, "invalid wm,pull %d\n", pull);
+		return -EINVAL;
+	}
+
+	group = wmt_pctl_find_group_by_pin(data, pin);
+	if (group < 0) {
+		dev_err(data->dev, "unable to match pin %d to group\n", pin);
+		return group;
+	}
+
+	configs = devm_kzalloc(data->dev, sizeof(*configs), GFP_KERNEL);
+	if (!configs)
+		return -ENOMEM;
+
+	configs[0] = pull;
+
+	map->type = PIN_MAP_TYPE_CONFIGS_PIN;
+	map->data.configs.group_or_pin = data->groups[group];
+	map->data.configs.configs = configs;
+	map->data.configs.num_configs = 1;
+	(*maps)++;
+
+	return 0;
+}
+
+static int wmt_pctl_dt_node_to_map(struct pinctrl_dev *pctldev,
+				   struct device_node *np,
+				   struct pinctrl_map **map,
+				   unsigned *num_maps)
+{
+	struct pinctrl_map *maps, *cur_map;
+	struct property *pins, *funcs, *pulls;
+	u32 pin, func, pull;
+	int num_pins, num_funcs, num_pulls, maps_per_pin;
+	int i, err;
+	struct wmt_pinctrl_data *data = pinctrl_dev_get_drvdata(pctldev);
+
+	pins = of_find_property(np, "wm,pins", NULL);
+	if (!pins) {
+		dev_err(data->dev, "missing wmt,pins property\n");
+		return -EINVAL;
+	}
+
+	funcs = of_find_property(np, "wm,function", NULL);
+	pulls = of_find_property(np, "wm,pull", NULL);
+
+	if (!funcs && !pulls) {
+		dev_err(data->dev, "neither wm,function nor wm,pull specified\n");
+		return -EINVAL;
+	}
+
+	/*
+	 * The following lines calculate how many values are defined for each
+	 * of the properties.
+	 */
+	num_pins = pins->length / sizeof(u32);
+	num_funcs = funcs ? (funcs->length / sizeof(u32)) : 0;
+	num_pulls = pulls ? (pulls->length / sizeof(u32)) : 0;
+
+	if (num_funcs > 1 && num_funcs != num_pins) {
+		dev_err(data->dev, "wm,function must have 1 or %d entries\n",
+			num_pins);
+		return -EINVAL;
+	}
+
+	if (num_pulls > 1 && num_pulls != num_pins) {
+		dev_err(data->dev, "wm,pull must have 1 or %d entries\n",
+			num_pins);
+		return -EINVAL;
+	}
+
+	maps_per_pin = 0;
+	if (num_funcs)
+		maps_per_pin++;
+	if (num_pulls)
+		maps_per_pin++;
+
+	cur_map = maps = devm_kzalloc(data->dev,
+				      num_pins * maps_per_pin * sizeof(*maps),
+				      GFP_KERNEL);
+	if (!maps)
+		return -ENOMEM;
+
+	for (i = 0; i < num_pins; i++) {
+		err = of_property_read_u32_index(np, "wm,pins", i, &pin);
+		if (err)
+			return err;
+
+		if (pin >= (data->nbanks * 32)) {
+			dev_err(data->dev, "invalid wm,pins value\n");
+			return -EINVAL;
+		}
+
+		if (num_funcs) {
+			err = of_property_read_u32_index(np, "wm,function",
+						(num_funcs > 1 ? i : 0), &func);
+			if (err)
+				return err;
+
+			err = wmt_pctl_dt_node_to_map_func(data, np, pin, func,
+							   &cur_map);
+			if (err)
+				return err;
+		}
+
+		if (num_pulls) {
+			err = of_property_read_u32_index(np, "wm,pull",
+						(num_pulls > 1 ? i : 0), &pull);
+			if (err)
+				return err;
+
+			err = wmt_pctl_dt_node_to_map_pull(data, np, pin, pull,
+							   &cur_map);
+			if (err)
+				return err;
+		}
+	}
+	*map = maps;
+	*num_maps = num_pins * maps_per_pin;
+	return 0;
+}
+
+static void wmt_pctl_dt_free_map(struct pinctrl_dev *pctldev,
+				 struct pinctrl_map *maps,
+				 unsigned num_maps)
+{
+	int i;
+
+	for (i = 0; i < num_maps; i++)
+		if (maps[i].type == PIN_MAP_TYPE_CONFIGS_PIN)
+			kfree(maps[i].data.configs.configs);
+
+	kfree(maps);
+}
+
+static struct pinctrl_ops wmt_pctl_ops = {
+	.get_groups_count = wmt_get_groups_count,
+	.get_group_name	= wmt_get_group_name,
+	.get_group_pins	= wmt_get_group_pins,
+	.dt_node_to_map = wmt_pctl_dt_node_to_map,
+	.dt_free_map = wmt_pctl_dt_free_map,
+};
+
+static int wmt_pinconf_get(struct pinctrl_dev *pctldev, unsigned pin,
+			   unsigned long *config)
+{
+	return -ENOTSUPP;
+}
+
+static int wmt_pinconf_set(struct pinctrl_dev *pctldev, unsigned pin,
+			   unsigned long config)
+{
+	struct wmt_pinctrl_data *data = pinctrl_dev_get_drvdata(pctldev);
+	enum pin_config_param param = pinconf_to_config_param(config);
+	u16 arg = pinconf_to_config_argument(config);
+	u32 bank = WMT_BANK_FROM_PIN(pin);
+	u32 bit = WMT_BIT_FROM_PIN(pin);
+	u32 reg_pull_en = data->banks[bank].reg_pull_en;
+	u32 reg_pull_cfg = data->banks[bank].reg_pull_cfg;
+
+	if ((reg_pull_en == NO_REG) || (reg_pull_cfg == NO_REG)) {
+		dev_err(data->dev, "bias functions not supported on pin %d\n",
+			pin);
+		return -EINVAL;
+	}
+
+	if ((param == PIN_CONFIG_BIAS_PULL_DOWN) ||
+	    (param == PIN_CONFIG_BIAS_PULL_UP)) {
+		if (arg == 0)
+			param = PIN_CONFIG_BIAS_DISABLE;
+	}
+
+	switch (param) {
+	case PIN_CONFIG_BIAS_DISABLE:
+		wmt_clearbits(data, reg_pull_en, BIT(bit));
+		break;
+	case PIN_CONFIG_BIAS_PULL_DOWN:
+		wmt_clearbits(data, reg_pull_cfg, BIT(bit));
+		wmt_setbits(data, reg_pull_en, BIT(bit));
+		break;
+	case PIN_CONFIG_BIAS_PULL_UP:
+		wmt_setbits(data, reg_pull_cfg, BIT(bit));
+		wmt_setbits(data, reg_pull_en, BIT(bit));
+		break;
+	default:
+		dev_err(data->dev, "unknown pinconf param\n");
+		return -EINVAL;
+	}
+
+	return 0;
+}
+
+static struct pinconf_ops wmt_pinconf_ops = {
+	.pin_config_get = wmt_pinconf_get,
+	.pin_config_set = wmt_pinconf_set,
+};
+
+static struct pinctrl_desc wmt_desc = {
+	.owner = THIS_MODULE,
+	.name = "pinctrl-wmt",
+	.pctlops = &wmt_pctl_ops,
+	.pmxops = &wmt_pinmux_ops,
+	.confops = &wmt_pinconf_ops,
+};
+
+static int wmt_gpio_request(struct gpio_chip *chip, unsigned offset)
+{
+	return pinctrl_request_gpio(chip->base + offset);
+}
+
+static void wmt_gpio_free(struct gpio_chip *chip, unsigned offset)
+{
+	pinctrl_free_gpio(chip->base + offset);
+}
+
+static int wmt_gpio_get_direction(struct gpio_chip *chip, unsigned offset)
+{
+	struct wmt_pinctrl_data *data = dev_get_drvdata(chip->dev);
+	u32 bank = WMT_BANK_FROM_PIN(offset);
+	u32 bit = WMT_BIT_FROM_PIN(offset);
+	u32 reg_dir = data->banks[bank].reg_dir;
+	u32 val;
+
+	val = readl_relaxed(data->base + reg_dir);
+	if (val & BIT(bit))
+		return GPIOF_DIR_OUT;
+	else
+		return GPIOF_DIR_IN;
+}
+
+static int wmt_gpio_direction_input(struct gpio_chip *chip, unsigned offset)
+{
+	return pinctrl_gpio_direction_input(chip->base + offset);
+}
+
+static int wmt_gpio_direction_output(struct gpio_chip *chip, unsigned offset,
+				     int value)
+{
+	return pinctrl_gpio_direction_output(chip->base + offset);
+}
+
+static int wmt_gpio_get_value(struct gpio_chip *chip, unsigned offset)
+{
+	struct wmt_pinctrl_data *data = dev_get_drvdata(chip->dev);
+	u32 bank = WMT_BANK_FROM_PIN(offset);
+	u32 bit = WMT_BIT_FROM_PIN(offset);
+	u32 reg_data_in = data->banks[bank].reg_data_in;
+
+	if (reg_data_in == NO_REG) {
+		dev_err(data->dev, "no data in register defined\n");
+		return -EINVAL;
+	}
+
+	return !!(readl_relaxed(data->base + reg_data_in) & BIT(bit));
+}
+
+static void wmt_gpio_set_value(struct gpio_chip *chip, unsigned offset,
+			       int val)
+{
+	struct wmt_pinctrl_data *data = dev_get_drvdata(chip->dev);
+	u32 bank = WMT_BANK_FROM_PIN(offset);
+	u32 bit = WMT_BIT_FROM_PIN(offset);
+	u32 reg_data_out = data->banks[bank].reg_data_out;
+
+	if (reg_data_out == NO_REG) {
+		dev_err(data->dev, "no data out register defined\n");
+		return;
+	}
+
+	if (val)
+		wmt_setbits(data, reg_data_out, BIT(bit));
+	else
+		wmt_clearbits(data, reg_data_out, BIT(bit));
+}
+
+static struct gpio_chip wmt_gpio_chip = {
+	.label = "gpio-wmt",
+	.owner = THIS_MODULE,
+	.request = wmt_gpio_request,
+	.free = wmt_gpio_free,
+	.get_direction = wmt_gpio_get_direction,
+	.direction_input = wmt_gpio_direction_input,
+	.direction_output = wmt_gpio_direction_output,
+	.get = wmt_gpio_get_value,
+	.set = wmt_gpio_set_value,
+	.can_sleep = 0,
+};
+
+int wmt_pinctrl_probe(struct platform_device *pdev,
+		      struct wmt_pinctrl_data *data)
+{
+	int err;
+	struct resource *res;
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	data->base = devm_request_and_ioremap(&pdev->dev, res);
+	if (!data->base) {
+		dev_err(&pdev->dev, "failed to map memory resource\n");
+		return -EBUSY;
+	}
+
+	wmt_desc.pins = data->pins;
+	wmt_desc.npins = data->npins;
+
+	data->gpio_chip = wmt_gpio_chip;
+	data->gpio_chip.dev = &pdev->dev;
+	data->gpio_chip.of_node = pdev->dev.of_node;
+	data->gpio_chip.ngpio = data->nbanks * 32;
+
+	platform_set_drvdata(pdev, data);
+
+	data->dev = &pdev->dev;
+
+	data->pctl_dev = pinctrl_register(&wmt_desc, &pdev->dev, data);
+	if (IS_ERR(data->pctl_dev)) {
+		dev_err(&pdev->dev, "Failed to register pinctrl\n");
+		return -EINVAL;
+	}
+
+	err = gpiochip_add(&data->gpio_chip);
+	if (err) {
+		dev_err(&pdev->dev, "could not add GPIO chip\n");
+		goto fail_gpio;
+	}
+
+	err = gpiochip_add_pin_range(&data->gpio_chip, dev_name(data->dev),
+				     0, 0, data->nbanks * 32);
+	if (err)
+		goto fail_range;
+
+	dev_info(&pdev->dev, "Pin controller initialized\n");
+
+	return 0;
+
+fail_range:
+	err = gpiochip_remove(&data->gpio_chip);
+	if (err)
+		dev_err(&pdev->dev, "failed to remove gpio chip\n");
+fail_gpio:
+	pinctrl_unregister(data->pctl_dev);
+	return err;
+}
+
+int wmt_pinctrl_remove(struct platform_device *pdev)
+{
+	struct wmt_pinctrl_data *data = platform_get_drvdata(pdev);
+	int err;
+
+	err = gpiochip_remove(&data->gpio_chip);
+	if (err)
+		dev_err(&pdev->dev, "failed to remove gpio chip\n");
+
+	pinctrl_unregister(data->pctl_dev);
+
+	return 0;
+}
diff --git a/drivers/pinctrl/vt8500/pinctrl-wmt.h b/drivers/pinctrl/vt8500/pinctrl-wmt.h
new file mode 100644
index 0000000..41f5f2d
--- /dev/null
+++ b/drivers/pinctrl/vt8500/pinctrl-wmt.h
@@ -0,0 +1,79 @@
+/*
+ * Pinctrl driver for the Wondermedia SoC's
+ *
+ * Copyright (c) 2013 Tony Prisk <linux at prisktech.co.nz>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ */
+
+#include <linux/gpio.h>
+
+/* VT8500 has no enable register in the extgpio bank. */
+#define NO_REG	0xFFFF
+
+#define WMT_PINCTRL_BANK(__en, __dir, __dout, __din, __pen, __pcfg)	\
+{									\
+	.reg_en		= __en,						\
+	.reg_dir	= __dir,					\
+	.reg_data_out	= __dout,					\
+	.reg_data_in	= __din,					\
+	.reg_pull_en	= __pen,					\
+	.reg_pull_cfg	= __pcfg,					\
+}
+
+/* Encode/decode the bank/bit pairs into a pin value */
+#define WMT_PIN(__bank, __offset)	((__bank << 5) | __offset)
+#define WMT_BANK_FROM_PIN(__pin)	(__pin >> 5)
+#define WMT_BIT_FROM_PIN(__pin)		(__pin & 0x1f)
+
+#define WMT_GROUP(__name, __data)		\
+{						\
+	.name = __name,				\
+	.pins = __data,				\
+	.npins = ARRAY_SIZE(__data),		\
+}
+
+struct wmt_pinctrl_bank_registers {
+	u32	reg_en;
+	u32	reg_dir;
+	u32	reg_data_out;
+	u32	reg_data_in;
+
+	u32	reg_pull_en;
+	u32	reg_pull_cfg;
+};
+
+struct wmt_pinctrl_group {
+	const char *name;
+	const unsigned int *pins;
+	const unsigned npins;
+};
+
+struct wmt_pinctrl_data {
+	struct device *dev;
+	struct pinctrl_dev *pctl_dev;
+
+	/* must be initialized before calling wmt_pinctrl_probe */
+	void __iomem *base;
+	const struct wmt_pinctrl_bank_registers *banks;
+	const struct pinctrl_pin_desc *pins;
+	const char * const *groups;
+
+	u32 nbanks;
+	u32 npins;
+	u32 ngroups;
+
+	struct gpio_chip gpio_chip;
+	struct pinctrl_gpio_range gpio_range;
+};
+
+int wmt_pinctrl_probe(struct platform_device *pdev,
+		      struct wmt_pinctrl_data *data);
+int wmt_pinctrl_remove(struct platform_device *pdev);
-- 
1.7.9.5



From linux at prisktech.co.nz  Tue Apr  2 00:40:57 2013
From: linux at prisktech.co.nz (Tony Prisk)
Date: Tue,  2 Apr 2013 17:40:57 +1300
Subject: [PATCHv4 2/6] arm: vt8500: Increase available GPIOs on arch-vt8500
In-Reply-To: <1364877661-26086-1-git-send-email-linux@prisktech.co.nz>
References: <1364877661-26086-1-git-send-email-linux@prisktech.co.nz>
Message-ID: <1364877661-26086-3-git-send-email-linux@prisktech.co.nz>

With the inclusion of the pin control driver, more GPIO pins have been
identified on the arch-vt8500 SoCs requiring an increase in the available
GPIOs.

Signed-off-by: Tony Prisk <linux at prisktech.co.nz>
---
 arch/arm/Kconfig |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 13b7394..244c618 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1661,7 +1661,8 @@ config ARCH_NR_GPIO
 	default 1024 if ARCH_SHMOBILE || ARCH_TEGRA
 	default 512 if SOC_OMAP5
 	default 355 if ARCH_U8500
-	default 288 if ARCH_VT8500 || ARCH_SUNXI
+	default 352 if ARCH_VT8500
+	default 288 if ARCH_SUNXI
 	default 264 if MACH_H4700
 	default 0
 	help
-- 
1.7.9.5



From linux at prisktech.co.nz  Tue Apr  2 00:40:56 2013
From: linux at prisktech.co.nz (Tony Prisk)
Date: Tue,  2 Apr 2013 17:40:56 +1300
Subject: [PATCHv4 1/6] of: Add support for reading a u32 from a multi-value
 property.
In-Reply-To: <1364877661-26086-1-git-send-email-linux@prisktech.co.nz>
References: <1364877661-26086-1-git-send-email-linux@prisktech.co.nz>
Message-ID: <1364877661-26086-2-git-send-email-linux@prisktech.co.nz>

This patch adds an of_property_read_u32_index() function to allow
reading a single indexed u32 value from a property containing multiple
u32 values.

Signed-off-by: Tony Prisk <linux at prisktech.co.nz>
Reviewed-by: Stephen Warren <swarren at nvidia.com>
---
 drivers/of/base.c  |   33 +++++++++++++++++++++++++++++++++
 include/linux/of.h |    9 +++++++++
 2 files changed, 42 insertions(+)

diff --git a/drivers/of/base.c b/drivers/of/base.c
index 321d3ef..f6c89ed 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -746,6 +746,39 @@ struct device_node *of_find_node_by_phandle(phandle handle)
 EXPORT_SYMBOL(of_find_node_by_phandle);
 
 /**
+ * of_property_read_u32_index - Find and read a u32 from a multi-value property.
+ *
+ * @np:		device node from which the property value is to be read.
+ * @propname:	name of the property to be searched.
+ * @index:	index of the u32 in the list of values
+ * @out_value:	pointer to return value, modified only if no error.
+ *
+ * Search for a property in a device node and read nth 32-bit value from
+ * it. Returns 0 on success, -EINVAL if the property does not exist,
+ * -ENODATA if property does not have a value, and -EOVERFLOW if the
+ * property data isn't large enough.
+ *
+ * The out_value is modified only if a valid u32 value can be decoded.
+ */
+int of_property_read_u32_index(const struct device_node *np,
+				       const char *propname,
+				       u32 index, u32 *out_value)
+{
+	struct property *prop = of_find_property(np, propname, NULL);
+
+	if (!prop)
+		return -EINVAL;
+	if (!prop->value)
+		return -ENODATA;
+	if (((index + 1) * sizeof(*out_value)) > prop->length)
+		return -EOVERFLOW;
+
+	*out_value = be32_to_cpup(((__be32 *)prop->value) + index);
+	return 0;
+}
+EXPORT_SYMBOL_GPL(of_property_read_u32_index);
+
+/**
  * of_property_read_u8_array - Find and read an array of u8 from a property.
  *
  * @np:		device node from which the property value is to be read.
diff --git a/include/linux/of.h b/include/linux/of.h
index a0f1292..c0747a4 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -235,6 +235,9 @@ extern struct device_node *of_find_node_with_property(
 extern struct property *of_find_property(const struct device_node *np,
 					 const char *name,
 					 int *lenp);
+extern int of_property_read_u32_index(const struct device_node *np,
+				       const char *propname,
+				       u32 index, u32 *out_value);
 extern int of_property_read_u8_array(const struct device_node *np,
 			const char *propname, u8 *out_values, size_t sz);
 extern int of_property_read_u16_array(const struct device_node *np,
@@ -394,6 +397,12 @@ static inline struct device_node *of_find_compatible_node(
 	return NULL;
 }
 
+static inline int of_property_read_u32_index(const struct device_node *np,
+			const char *propname, u32 index, u32 *out_value)
+{
+	return -ENOSYS;
+}
+
 static inline int of_property_read_u8_array(const struct device_node *np,
 			const char *propname, u8 *out_values, size_t sz)
 {
-- 
1.7.9.5



From linux at prisktech.co.nz  Tue Apr  2 00:40:55 2013
From: linux at prisktech.co.nz (Tony Prisk)
Date: Tue,  2 Apr 2013 17:40:55 +1300
Subject: [PATCHv4 RESEND 0/6] arm: vt8500: Add support for pinctrl/gpio module
Message-ID: <1364877661-26086-1-git-send-email-linux@prisktech.co.nz>

Sorry - got Linus W's email address wrong in first send.

v4 changes:
Changed as requested by Stephen Warren:
Corrected the range checking in of_property_read_u32_index().
Fix configs[0] assignment in wmt_pctl_dt_node_to_map_pull().
Remove the kfree(maps) call, and use devm_kzalloc to simplify the fail path.
Drop the custom .of_xlate function and use the default of_gpio_simple_xlate.
Move the platform memory mapping from per-soc to common init.

v3 changes:
Rebased onto v3.9-rc4
Added the missing interrupt-controller info to the relevant dtsi files.
Removed the gpio-vt8500.txt binding along with the gpio driver.

Changes made as requested by Linux Walleij:
Removed the wm,pinmux property which has caused too much confusion, and left the
	open-coded version in arm/arch-vt8500/vt8500.c until a proper solution
	is sorted out.

Changes made as requested by Stephen Warren:
Defined an active-low flag for gpio since its useful and we will have a use-case
	for it with our LCD power-on/off.

v2 changes:
Rebased onto v3.9-rc2

Changes made as requested by Linus Walleij:
Moved the files into drivers/pinctrl/vt8500/ to keep them tidy.
Changed readl/writel to *_relaxed variants.
Comment indentation corrected and remove additional whitespace.
Changed wmt_pctl_find_group_by_pin() error code from -1 to -EINVAL.
Removed OF read indexed-u32 function to OF subsystem.
General code tidy up as requested.

Changes made as requested by Stephen Warren:
Add binding information for interrupt generation.
Move optional properties to correct location in document.


This patch series removes the existing GPIO driver and replaces it with
a combined pinctrl+gpio driver.

Patch 1 - Add an OF function to read the nth u32 value from a property
  listing multiple values.

Patch 2 - Increase the available GPIO space for the newly added gpios.
  Because there is no hardware documentation from Wondermedia we don't know
  how many GPIO's there actually are. New gpio pins have been located since
  the original GPIO driver was written, hence the increase.

Patch 3 - The main pinctrl/gpio driver and the data for the 5 supported SoCs.
  Each SoC is different, and therefore has its own data. This design was
  borrowed from the Tegra pinctrl driver. The pin numbering is based on a
  bank+pin encoding so that when other pin functions are found later on we can
  add them without having to renumber existing pins.

Patch 4 - Update the SoC dts(i) files to support the new pinctrl driver.

Patch 5 - Remove the existing GPIO driver nodes from the dtsi's.

Patch 6 - Remove the existing GPIO driver.

I suspect this series may need to be broken up since there are two arm-soc
patches, and 4 pinctrl/gpio patches.

Patch 1 is required for the new driver to function properly.
Patch 2 is independant, but required for the driver to function properly.
Patches 3-4 are pinctrl/gpio patches.
Patch 5-6 remove the old gpio code which is no longer required.


Patch 2 could go via arm-soc if necessary.

Regards
Tony Prisk

Tony Prisk (6):
  of: Add support for reading a u32 from a multi-value property.
  arm: vt8500: Increase available GPIOs on arch-vt8500
  pinctrl: gpio: vt8500: Add pincontrol driver for arch-vt8500
  arm: dts: vt8500: Update Wondermedia SoC dtsi files for pinctrl
    driver
  arm: vt8500: Remove gpio devicetree nodes
  gpio: vt8500: Remove arch-vt8500 gpio driver

 .../devicetree/bindings/gpio/gpio-vt8500.txt       |   24 -
 .../devicetree/bindings/pinctrl/pinctrl-vt8500.txt |   57 ++
 arch/arm/Kconfig                                   |    3 +-
 arch/arm/boot/dts/vt8500.dtsi                      |   10 +-
 arch/arm/boot/dts/wm8505.dtsi                      |   10 +-
 arch/arm/boot/dts/wm8650.dtsi                      |   10 +-
 arch/arm/boot/dts/wm8850.dtsi                      |   10 +-
 arch/arm/mach-vt8500/Kconfig                       |    1 +
 drivers/gpio/Kconfig                               |    6 -
 drivers/gpio/Makefile                              |    1 -
 drivers/gpio/gpio-vt8500.c                         |  355 -----------
 drivers/of/base.c                                  |   33 ++
 drivers/pinctrl/Kconfig                            |    1 +
 drivers/pinctrl/Makefile                           |    1 +
 drivers/pinctrl/vt8500/Kconfig                     |   52 ++
 drivers/pinctrl/vt8500/Makefile                    |    8 +
 drivers/pinctrl/vt8500/pinctrl-vt8500.c            |  501 ++++++++++++++++
 drivers/pinctrl/vt8500/pinctrl-wm8505.c            |  532 +++++++++++++++++
 drivers/pinctrl/vt8500/pinctrl-wm8650.c            |  370 ++++++++++++
 drivers/pinctrl/vt8500/pinctrl-wm8750.c            |  409 +++++++++++++
 drivers/pinctrl/vt8500/pinctrl-wm8850.c            |  388 ++++++++++++
 drivers/pinctrl/vt8500/pinctrl-wmt.c               |  620 ++++++++++++++++++++
 drivers/pinctrl/vt8500/pinctrl-wmt.h               |   79 +++
 include/linux/of.h                                 |    9 +
 24 files changed, 3087 insertions(+), 403 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/gpio/gpio-vt8500.txt
 create mode 100644 Documentation/devicetree/bindings/pinctrl/pinctrl-vt8500.txt
 delete mode 100644 drivers/gpio/gpio-vt8500.c
 create mode 100644 drivers/pinctrl/vt8500/Kconfig
 create mode 100644 drivers/pinctrl/vt8500/Makefile
 create mode 100644 drivers/pinctrl/vt8500/pinctrl-vt8500.c
 create mode 100644 drivers/pinctrl/vt8500/pinctrl-wm8505.c
 create mode 100644 drivers/pinctrl/vt8500/pinctrl-wm8650.c
 create mode 100644 drivers/pinctrl/vt8500/pinctrl-wm8750.c
 create mode 100644 drivers/pinctrl/vt8500/pinctrl-wm8850.c
 create mode 100644 drivers/pinctrl/vt8500/pinctrl-wmt.c
 create mode 100644 drivers/pinctrl/vt8500/pinctrl-wmt.h

-- 
1.7.9.5



From linux at prisktech.co.nz  Tue Apr  2 00:40:59 2013
From: linux at prisktech.co.nz (Tony Prisk)
Date: Tue,  2 Apr 2013 17:40:59 +1300
Subject: [PATCHv4 4/6] arm: dts: vt8500: Update Wondermedia SoC dtsi files for
 pinctrl driver
In-Reply-To: <1364877661-26086-1-git-send-email-linux@prisktech.co.nz>
References: <1364877661-26086-1-git-send-email-linux@prisktech.co.nz>
Message-ID: <1364877661-26086-5-git-send-email-linux@prisktech.co.nz>

This patch adds pinctrl nodes to the VIA VT8500 and Wondermedia SoC dtsi
files to support the pinctrl driver.

Signed-off-by: Tony Prisk <linux at prisktech.co.nz>
---
 arch/arm/boot/dts/vt8500.dtsi |    9 +++++++++
 arch/arm/boot/dts/wm8505.dtsi |    9 +++++++++
 arch/arm/boot/dts/wm8650.dtsi |    9 +++++++++
 arch/arm/boot/dts/wm8850.dtsi |    9 +++++++++
 4 files changed, 36 insertions(+)

diff --git a/arch/arm/boot/dts/vt8500.dtsi b/arch/arm/boot/dts/vt8500.dtsi
index cf31ced..8e87aa9 100644
--- a/arch/arm/boot/dts/vt8500.dtsi
+++ b/arch/arm/boot/dts/vt8500.dtsi
@@ -32,6 +32,15 @@
 			#gpio-cells = <3>;
 		};
 
+		pinctrl: pinctrl at d8110000 {
+			compatible = "via,vt8500-pinctrl";
+			reg = <0xd8110000 0x10000>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			gpio-controller;
+			#gpio-cells = <2>;
+		};
+
 		pmc at d8130000 {
 			compatible = "via,vt8500-pmc";
 			reg = <0xd8130000 0x1000>;
diff --git a/arch/arm/boot/dts/wm8505.dtsi b/arch/arm/boot/dts/wm8505.dtsi
index e74a1c0..e4f768a 100644
--- a/arch/arm/boot/dts/wm8505.dtsi
+++ b/arch/arm/boot/dts/wm8505.dtsi
@@ -47,6 +47,15 @@
 			#gpio-cells = <3>;
 		};
 
+		pinctrl: pinctrl at d8110000 {
+			compatible = "wm,wm8505-pinctrl";
+			reg = <0xd8110000 0x10000>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			gpio-controller;
+			#gpio-cells = <2>;
+		};
+
 		pmc at d8130000 {
 			compatible = "via,vt8500-pmc";
 			reg = <0xd8130000 0x1000>;
diff --git a/arch/arm/boot/dts/wm8650.dtsi b/arch/arm/boot/dts/wm8650.dtsi
index db3c0a1..01b6a8d 100644
--- a/arch/arm/boot/dts/wm8650.dtsi
+++ b/arch/arm/boot/dts/wm8650.dtsi
@@ -41,6 +41,15 @@
 			#gpio-cells = <3>;
 		};
 
+		pinctrl: pinctrl at d8110000 {
+			compatible = "wm,wm8650-pinctrl";
+			reg = <0xd8110000 0x10000>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			gpio-controller;
+			#gpio-cells = <2>;
+		};
+
 		pmc at d8130000 {
 			compatible = "via,vt8500-pmc";
 			reg = <0xd8130000 0x1000>;
diff --git a/arch/arm/boot/dts/wm8850.dtsi b/arch/arm/boot/dts/wm8850.dtsi
index e8cbfdc..297aa05 100644
--- a/arch/arm/boot/dts/wm8850.dtsi
+++ b/arch/arm/boot/dts/wm8850.dtsi
@@ -48,6 +48,15 @@
 			#gpio-cells = <3>;
 		};
 
+		pinctrl: pinctrl at d8110000 {
+			compatible = "wm,wm8850-pinctrl";
+			reg = <0xd8110000 0x10000>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			gpio-controller;
+			#gpio-cells = <2>;
+		};
+
 		pmc at d8130000 {
 			compatible = "via,vt8500-pmc";
 			reg = <0xd8130000 0x1000>;
-- 
1.7.9.5



From linux at prisktech.co.nz  Tue Apr  2 00:41:00 2013
From: linux at prisktech.co.nz (Tony Prisk)
Date: Tue,  2 Apr 2013 17:41:00 +1300
Subject: [PATCHv4 5/6] arm: vt8500: Remove gpio devicetree nodes
In-Reply-To: <1364877661-26086-1-git-send-email-linux@prisktech.co.nz>
References: <1364877661-26086-1-git-send-email-linux@prisktech.co.nz>
Message-ID: <1364877661-26086-6-git-send-email-linux@prisktech.co.nz>

Remove the gpio related devicetree nodes as these are no longer required
with the move to a combined pinctrl/gpio driver.

Signed-off-by: Tony Prisk <linux at prisktech.co.nz>
---
 arch/arm/boot/dts/vt8500.dtsi |    7 -------
 arch/arm/boot/dts/wm8505.dtsi |    7 -------
 arch/arm/boot/dts/wm8650.dtsi |    7 -------
 arch/arm/boot/dts/wm8850.dtsi |    7 -------
 4 files changed, 28 deletions(-)

diff --git a/arch/arm/boot/dts/vt8500.dtsi b/arch/arm/boot/dts/vt8500.dtsi
index 8e87aa9..e1c3926 100644
--- a/arch/arm/boot/dts/vt8500.dtsi
+++ b/arch/arm/boot/dts/vt8500.dtsi
@@ -25,13 +25,6 @@
 			#interrupt-cells = <1>;
 		};
 
-		gpio: gpio-controller at d8110000 {
-			compatible = "via,vt8500-gpio";
-			gpio-controller;
-			reg = <0xd8110000 0x10000>;
-			#gpio-cells = <3>;
-		};
-
 		pinctrl: pinctrl at d8110000 {
 			compatible = "via,vt8500-pinctrl";
 			reg = <0xd8110000 0x10000>;
diff --git a/arch/arm/boot/dts/wm8505.dtsi b/arch/arm/boot/dts/wm8505.dtsi
index e4f768a..bb92ef8 100644
--- a/arch/arm/boot/dts/wm8505.dtsi
+++ b/arch/arm/boot/dts/wm8505.dtsi
@@ -40,13 +40,6 @@
 			interrupts = <56 57 58 59 60 61 62 63>;
 		};
 
-		gpio: gpio-controller at d8110000 {
-			compatible = "wm,wm8505-gpio";
-			gpio-controller;
-			reg = <0xd8110000 0x10000>;
-			#gpio-cells = <3>;
-		};
-
 		pinctrl: pinctrl at d8110000 {
 			compatible = "wm,wm8505-pinctrl";
 			reg = <0xd8110000 0x10000>;
diff --git a/arch/arm/boot/dts/wm8650.dtsi b/arch/arm/boot/dts/wm8650.dtsi
index 01b6a8d..bb4af58 100644
--- a/arch/arm/boot/dts/wm8650.dtsi
+++ b/arch/arm/boot/dts/wm8650.dtsi
@@ -34,13 +34,6 @@
 			interrupts = <56 57 58 59 60 61 62 63>;
 		};
 
-		gpio: gpio-controller at d8110000 {
-			compatible = "wm,wm8650-gpio";
-			gpio-controller;
-			reg = <0xd8110000 0x10000>;
-			#gpio-cells = <3>;
-		};
-
 		pinctrl: pinctrl at d8110000 {
 			compatible = "wm,wm8650-pinctrl";
 			reg = <0xd8110000 0x10000>;
diff --git a/arch/arm/boot/dts/wm8850.dtsi b/arch/arm/boot/dts/wm8850.dtsi
index 297aa05..11cd180 100644
--- a/arch/arm/boot/dts/wm8850.dtsi
+++ b/arch/arm/boot/dts/wm8850.dtsi
@@ -41,13 +41,6 @@
 			interrupts = <56 57 58 59 60 61 62 63>;
 		};
 
-		gpio: gpio-controller at d8110000 {
-			compatible = "wm,wm8650-gpio";
-			gpio-controller;
-			reg = <0xd8110000 0x10000>;
-			#gpio-cells = <3>;
-		};
-
 		pinctrl: pinctrl at d8110000 {
 			compatible = "wm,wm8850-pinctrl";
 			reg = <0xd8110000 0x10000>;
-- 
1.7.9.5



From linux at prisktech.co.nz  Tue Apr  2 00:41:01 2013
From: linux at prisktech.co.nz (Tony Prisk)
Date: Tue,  2 Apr 2013 17:41:01 +1300
Subject: [PATCHv4 6/6] gpio: vt8500: Remove arch-vt8500 gpio driver
In-Reply-To: <1364877661-26086-1-git-send-email-linux@prisktech.co.nz>
References: <1364877661-26086-1-git-send-email-linux@prisktech.co.nz>
Message-ID: <1364877661-26086-7-git-send-email-linux@prisktech.co.nz>

With the move to a combined pinctrl/gpio driver, the arch-vt8500
gpio driver is no longer required.

Signed-off-by: Tony Prisk <linux at prisktech.co.nz>
---
 .../devicetree/bindings/gpio/gpio-vt8500.txt       |   24 --
 drivers/gpio/Kconfig                               |    6 -
 drivers/gpio/Makefile                              |    1 -
 drivers/gpio/gpio-vt8500.c                         |  355 --------------------
 4 files changed, 386 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/gpio/gpio-vt8500.txt
 delete mode 100644 drivers/gpio/gpio-vt8500.c

diff --git a/Documentation/devicetree/bindings/gpio/gpio-vt8500.txt b/Documentation/devicetree/bindings/gpio/gpio-vt8500.txt
deleted file mode 100644
index f4dc523..0000000
--- a/Documentation/devicetree/bindings/gpio/gpio-vt8500.txt
+++ /dev/null
@@ -1,24 +0,0 @@
-VIA/Wondermedia VT8500 GPIO Controller
------------------------------------------------------
-
-Required properties:
-- compatible : "via,vt8500-gpio", "wm,wm8505-gpio"
-	or "wm,wm8650-gpio" depending on your SoC
-- reg : Should contain 1 register range (address and length)
-- #gpio-cells : should be <3>.
-	1) bank
-	2) pin number
-	3) flags - should be 0
-
-Example:
-
-	gpio: gpio-controller at d8110000 {
-		compatible = "via,vt8500-gpio";
-		gpio-controller;
-		reg = <0xd8110000 0x10000>;
-		#gpio-cells = <3>;
-	};
-
-	vibrate {
-		gpios = <&gpio 0 1 0>; /* Bank 0, Pin 1, No flags */
-	};
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 93aaadf..b166e30 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -227,12 +227,6 @@ config GPIO_TS5500
 	  blocks of the TS-5500: DIO1, DIO2 and the LCD port, and the TS-5600
 	  LCD port.
 
-config GPIO_VT8500
-	bool "VIA/Wondermedia SoC GPIO Support"
-	depends on ARCH_VT8500
-	help
-	  Say yes here to support the VT8500/WM8505/WM8650 GPIO controller.
-
 config GPIO_XILINX
 	bool "Xilinx GPIO support"
 	depends on PPC_OF || MICROBLAZE
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 22e07bc..a274d7d 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -80,7 +80,6 @@ obj-$(CONFIG_GPIO_TWL6040)	+= gpio-twl6040.o
 obj-$(CONFIG_GPIO_UCB1400)	+= gpio-ucb1400.o
 obj-$(CONFIG_GPIO_VIPERBOARD)	+= gpio-viperboard.o
 obj-$(CONFIG_GPIO_VR41XX)	+= gpio-vr41xx.o
-obj-$(CONFIG_GPIO_VT8500)	+= gpio-vt8500.o
 obj-$(CONFIG_GPIO_VX855)	+= gpio-vx855.o
 obj-$(CONFIG_GPIO_WM831X)	+= gpio-wm831x.o
 obj-$(CONFIG_GPIO_WM8350)	+= gpio-wm8350.o
diff --git a/drivers/gpio/gpio-vt8500.c b/drivers/gpio/gpio-vt8500.c
deleted file mode 100644
index 81683ca..0000000
--- a/drivers/gpio/gpio-vt8500.c
+++ /dev/null
@@ -1,355 +0,0 @@
-/* drivers/gpio/gpio-vt8500.c
- *
- * Copyright (C) 2012 Tony Prisk <linux at prisktech.co.nz>
- * Based on arch/arm/mach-vt8500/gpio.c:
- * - Copyright (C) 2010 Alexey Charkov <alchark at gmail.com>
- *
- * This software is licensed under the terms of the GNU General Public
- * License version 2, as published by the Free Software Foundation, and
- * may be copied, distributed, and modified under those terms.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- */
-
-#include <linux/module.h>
-#include <linux/err.h>
-#include <linux/io.h>
-#include <linux/gpio.h>
-#include <linux/platform_device.h>
-#include <linux/bitops.h>
-#include <linux/of.h>
-#include <linux/of_address.h>
-#include <linux/of_irq.h>
-#include <linux/of_device.h>
-
-/*
-	We handle GPIOs by bank, each bank containing up to 32 GPIOs covered
-	by one set of registers (although not all may be valid).
-
-	Because different SoC's have different register offsets, we pass the
-	register offsets as data in vt8500_gpio_dt_ids[].
-
-	A value of NO_REG is used to indicate that this register is not
-	supported. Only used for ->en at the moment.
-*/
-
-#define NO_REG	0xFFFF
-
-/*
- * struct vt8500_gpio_bank_regoffsets
- * @en: offset to enable register of the bank
- * @dir: offset to direction register of the bank
- * @data_out: offset to the data out register of the bank
- * @data_in: offset to the data in register of the bank
- * @ngpio: highest valid pin in this bank
- */
-
-struct vt8500_gpio_bank_regoffsets {
-	unsigned int	en;
-	unsigned int	dir;
-	unsigned int	data_out;
-	unsigned int	data_in;
-	unsigned char	ngpio;
-};
-
-struct vt8500_gpio_data {
-	unsigned int				num_banks;
-	struct vt8500_gpio_bank_regoffsets	banks[];
-};
-
-#define VT8500_BANK(__en, __dir, __out, __in, __ngpio)		\
-{								\
-	.en = __en,						\
-	.dir = __dir,						\
-	.data_out = __out,					\
-	.data_in = __in,					\
-	.ngpio = __ngpio,					\
-}
-
-static struct vt8500_gpio_data vt8500_data = {
-	.num_banks	= 7,
-	.banks	= {
-		VT8500_BANK(NO_REG, 0x3C, 0x5C, 0x7C, 9),
-		VT8500_BANK(0x00, 0x20, 0x40, 0x60, 26),
-		VT8500_BANK(0x04, 0x24, 0x44, 0x64, 28),
-		VT8500_BANK(0x08, 0x28, 0x48, 0x68, 31),
-		VT8500_BANK(0x0C, 0x2C, 0x4C, 0x6C, 19),
-		VT8500_BANK(0x10, 0x30, 0x50, 0x70, 19),
-		VT8500_BANK(0x14, 0x34, 0x54, 0x74, 23),
-	},
-};
-
-static struct vt8500_gpio_data wm8505_data = {
-	.num_banks	= 10,
-	.banks	= {
-		VT8500_BANK(0x64, 0x8C, 0xB4, 0xDC, 22),
-		VT8500_BANK(0x40, 0x68, 0x90, 0xB8, 8),
-		VT8500_BANK(0x44, 0x6C, 0x94, 0xBC, 32),
-		VT8500_BANK(0x48, 0x70, 0x98, 0xC0, 6),
-		VT8500_BANK(0x4C, 0x74, 0x9C, 0xC4, 16),
-		VT8500_BANK(0x50, 0x78, 0xA0, 0xC8, 25),
-		VT8500_BANK(0x54, 0x7C, 0xA4, 0xCC, 5),
-		VT8500_BANK(0x58, 0x80, 0xA8, 0xD0, 5),
-		VT8500_BANK(0x5C, 0x84, 0xAC, 0xD4, 12),
-		VT8500_BANK(0x60, 0x88, 0xB0, 0xD8, 16),
-		VT8500_BANK(0x500, 0x504, 0x508, 0x50C, 6),
-	},
-};
-
-/*
- * No information about which bits are valid so we just make
- * them all available until its figured out.
- */
-static struct vt8500_gpio_data wm8650_data = {
-	.num_banks	= 9,
-	.banks	= {
-		VT8500_BANK(0x40, 0x80, 0xC0, 0x00, 32),
-		VT8500_BANK(0x44, 0x84, 0xC4, 0x04, 32),
-		VT8500_BANK(0x48, 0x88, 0xC8, 0x08, 32),
-		VT8500_BANK(0x4C, 0x8C, 0xCC, 0x0C, 32),
-		VT8500_BANK(0x50, 0x90, 0xD0, 0x10, 32),
-		VT8500_BANK(0x54, 0x94, 0xD4, 0x14, 32),
-		VT8500_BANK(0x58, 0x98, 0xD8, 0x18, 32),
-		VT8500_BANK(0x5C, 0x9C, 0xDC, 0x1C, 32),
-		VT8500_BANK(0x7C, 0xBC, 0xFC, 0x3C, 32),
-		VT8500_BANK(0x500, 0x504, 0x508, 0x50C, 6),
-	},
-};
-
-struct vt8500_gpio_chip {
-	struct gpio_chip		chip;
-
-	const struct vt8500_gpio_bank_regoffsets *regs;
-	void __iomem	*base;
-};
-
-struct vt8500_data {
-	struct vt8500_gpio_chip *chip;
-	void __iomem *iobase;
-	int num_banks;
-};
-
-
-#define to_vt8500(__chip) container_of(__chip, struct vt8500_gpio_chip, chip)
-
-static int vt8500_gpio_request(struct gpio_chip *chip, unsigned offset)
-{
-	u32 val;
-	struct vt8500_gpio_chip *vt8500_chip = to_vt8500(chip);
-
-	if (vt8500_chip->regs->en == NO_REG)
-		return 0;
-
-	val = readl_relaxed(vt8500_chip->base + vt8500_chip->regs->en);
-	val |= BIT(offset);
-	writel_relaxed(val, vt8500_chip->base + vt8500_chip->regs->en);
-
-	return 0;
-}
-
-static void vt8500_gpio_free(struct gpio_chip *chip, unsigned offset)
-{
-	struct vt8500_gpio_chip *vt8500_chip = to_vt8500(chip);
-	u32 val;
-
-	if (vt8500_chip->regs->en == NO_REG)
-		return;
-
-	val = readl_relaxed(vt8500_chip->base + vt8500_chip->regs->en);
-	val &= ~BIT(offset);
-	writel_relaxed(val, vt8500_chip->base + vt8500_chip->regs->en);
-}
-
-static int vt8500_gpio_direction_input(struct gpio_chip *chip, unsigned offset)
-{
-	struct vt8500_gpio_chip *vt8500_chip = to_vt8500(chip);
-
-	u32 val = readl_relaxed(vt8500_chip->base + vt8500_chip->regs->dir);
-	val &= ~BIT(offset);
-	writel_relaxed(val, vt8500_chip->base + vt8500_chip->regs->dir);
-
-	return 0;
-}
-
-static int vt8500_gpio_direction_output(struct gpio_chip *chip, unsigned offset,
-								int value)
-{
-	struct vt8500_gpio_chip *vt8500_chip = to_vt8500(chip);
-
-	u32 val = readl_relaxed(vt8500_chip->base + vt8500_chip->regs->dir);
-	val |= BIT(offset);
-	writel_relaxed(val, vt8500_chip->base + vt8500_chip->regs->dir);
-
-	if (value) {
-		val = readl_relaxed(vt8500_chip->base +
-						vt8500_chip->regs->data_out);
-		val |= BIT(offset);
-		writel_relaxed(val, vt8500_chip->base +
-						vt8500_chip->regs->data_out);
-	}
-	return 0;
-}
-
-static int vt8500_gpio_get_value(struct gpio_chip *chip, unsigned offset)
-{
-	struct vt8500_gpio_chip *vt8500_chip = to_vt8500(chip);
-
-	return (readl_relaxed(vt8500_chip->base + vt8500_chip->regs->data_in) >>
-								offset) & 1;
-}
-
-static void vt8500_gpio_set_value(struct gpio_chip *chip, unsigned offset,
-								int value)
-{
-	struct vt8500_gpio_chip *vt8500_chip = to_vt8500(chip);
-
-	u32 val = readl_relaxed(vt8500_chip->base +
-						vt8500_chip->regs->data_out);
-	if (value)
-		val |= BIT(offset);
-	else
-		val &= ~BIT(offset);
-
-	writel_relaxed(val, vt8500_chip->base + vt8500_chip->regs->data_out);
-}
-
-static int vt8500_of_xlate(struct gpio_chip *gc,
-			    const struct of_phandle_args *gpiospec, u32 *flags)
-{
-	/* bank if specificed in gpiospec->args[0] */
-	if (flags)
-		*flags = gpiospec->args[2];
-
-	return gpiospec->args[1];
-}
-
-static int vt8500_add_chips(struct platform_device *pdev, void __iomem *base,
-				const struct vt8500_gpio_data *data)
-{
-	struct vt8500_data *priv;
-	struct vt8500_gpio_chip *vtchip;
-	struct gpio_chip *chip;
-	int i;
-	int pin_cnt = 0;
-
-	priv = devm_kzalloc(&pdev->dev, sizeof(struct vt8500_data), GFP_KERNEL);
-	if (!priv) {
-		dev_err(&pdev->dev, "failed to allocate memory\n");
-		return -ENOMEM;
-	}
-
-	priv->chip = devm_kzalloc(&pdev->dev,
-			sizeof(struct vt8500_gpio_chip) * data->num_banks,
-			GFP_KERNEL);
-	if (!priv->chip) {
-		dev_err(&pdev->dev, "failed to allocate chip memory\n");
-		return -ENOMEM;
-	}
-
-	priv->iobase = base;
-	priv->num_banks = data->num_banks;
-	platform_set_drvdata(pdev, priv);
-
-	vtchip = priv->chip;
-
-	for (i = 0; i < data->num_banks; i++) {
-		vtchip[i].base = base;
-		vtchip[i].regs = &data->banks[i];
-
-		chip = &vtchip[i].chip;
-
-		chip->of_xlate = vt8500_of_xlate;
-		chip->of_gpio_n_cells = 3;
-		chip->of_node = pdev->dev.of_node;
-
-		chip->request = vt8500_gpio_request;
-		chip->free = vt8500_gpio_free;
-		chip->direction_input = vt8500_gpio_direction_input;
-		chip->direction_output = vt8500_gpio_direction_output;
-		chip->get = vt8500_gpio_get_value;
-		chip->set = vt8500_gpio_set_value;
-		chip->can_sleep = 0;
-		chip->base = pin_cnt;
-		chip->ngpio = data->banks[i].ngpio;
-
-		pin_cnt += data->banks[i].ngpio;
-
-		gpiochip_add(chip);
-	}
-	return 0;
-}
-
-static struct of_device_id vt8500_gpio_dt_ids[] = {
-	{ .compatible = "via,vt8500-gpio", .data = &vt8500_data, },
-	{ .compatible = "wm,wm8505-gpio", .data = &wm8505_data, },
-	{ .compatible = "wm,wm8650-gpio", .data = &wm8650_data, },
-	{ /* Sentinel */ },
-};
-
-static int vt8500_gpio_probe(struct platform_device *pdev)
-{
-	int ret;
-	void __iomem *gpio_base;
-	struct resource *res;
-	const struct of_device_id *of_id =
-				of_match_device(vt8500_gpio_dt_ids, &pdev->dev);
-
-	if (!of_id) {
-		dev_err(&pdev->dev, "No matching driver data\n");
-		return -ENODEV;
-	}
-
-	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-	if (!res) {
-		dev_err(&pdev->dev, "Unable to get IO resource\n");
-		return -ENODEV;
-	}
-
-	gpio_base = devm_request_and_ioremap(&pdev->dev, res);
-	if (!gpio_base) {
-		dev_err(&pdev->dev, "Unable to map GPIO registers\n");
-		return -ENOMEM;
-	}
-
-	ret = vt8500_add_chips(pdev, gpio_base, of_id->data);
-
-	return ret;
-}
-
-static int vt8500_gpio_remove(struct platform_device *pdev)
-{
-	int i;
-	int ret;
-	struct vt8500_data *priv = platform_get_drvdata(pdev);
-	struct vt8500_gpio_chip *vtchip = priv->chip;
-
-	for (i = 0; i < priv->num_banks; i++) {
-		ret = gpiochip_remove(&vtchip[i].chip);
-		if (ret)
-			dev_warn(&pdev->dev, "gpiochip_remove returned %d\n",
-				 ret);
-	}
-
-	return 0;
-}
-
-static struct platform_driver vt8500_gpio_driver = {
-	.probe		= vt8500_gpio_probe,
-	.remove		= vt8500_gpio_remove,
-	.driver		= {
-		.name	= "vt8500-gpio",
-		.owner	= THIS_MODULE,
-		.of_match_table = vt8500_gpio_dt_ids,
-	},
-};
-
-module_platform_driver(vt8500_gpio_driver);
-
-MODULE_DESCRIPTION("VT8500 GPIO Driver");
-MODULE_AUTHOR("Tony Prisk <linux at prisktech.co.nz>");
-MODULE_LICENSE("GPL v2");
-MODULE_DEVICE_TABLE(of, vt8500_gpio_dt_ids);
-- 
1.7.9.5



From linux at prisktech.co.nz  Tue Apr  2 00:40:58 2013
From: linux at prisktech.co.nz (Tony Prisk)
Date: Tue,  2 Apr 2013 17:40:58 +1300
Subject: [PATCHv4 3/6] pinctrl: gpio: vt8500: Add pincontrol driver for
 arch-vt8500
In-Reply-To: <1364877661-26086-1-git-send-email-linux@prisktech.co.nz>
References: <1364877661-26086-1-git-send-email-linux@prisktech.co.nz>
Message-ID: <1364877661-26086-4-git-send-email-linux@prisktech.co.nz>

This patch adds support for the GPIO/pinmux controller found on the VIA
VT8500 and Wondermedia WM8xxx-series SoCs.

Each pin within the controller is capable of operating as a GPIO or as
an alternate function. The pins are numbered according to their control
bank/bit so that if new pins are added, the existing numbering is maintained.

All currently supported SoCs are included: VT8500, WM8505, WM8650, WM8750 and
WM8850.

Signed-off-by: Tony Prisk <linux at prisktech.co.nz>
Reviewed-by: Stephen Warren <swarren at nvidia.com>
---
 .../devicetree/bindings/pinctrl/pinctrl-vt8500.txt |   57 ++
 arch/arm/mach-vt8500/Kconfig                       |    1 +
 drivers/pinctrl/Kconfig                            |    1 +
 drivers/pinctrl/Makefile                           |    1 +
 drivers/pinctrl/vt8500/Kconfig                     |   52 ++
 drivers/pinctrl/vt8500/Makefile                    |    8 +
 drivers/pinctrl/vt8500/pinctrl-vt8500.c            |  501 ++++++++++++++++
 drivers/pinctrl/vt8500/pinctrl-wm8505.c            |  532 +++++++++++++++++
 drivers/pinctrl/vt8500/pinctrl-wm8650.c            |  370 ++++++++++++
 drivers/pinctrl/vt8500/pinctrl-wm8750.c            |  409 +++++++++++++
 drivers/pinctrl/vt8500/pinctrl-wm8850.c            |  388 ++++++++++++
 drivers/pinctrl/vt8500/pinctrl-wmt.c               |  620 ++++++++++++++++++++
 drivers/pinctrl/vt8500/pinctrl-wmt.h               |   79 +++
 13 files changed, 3019 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pinctrl/pinctrl-vt8500.txt
 create mode 100644 drivers/pinctrl/vt8500/Kconfig
 create mode 100644 drivers/pinctrl/vt8500/Makefile
 create mode 100644 drivers/pinctrl/vt8500/pinctrl-vt8500.c
 create mode 100644 drivers/pinctrl/vt8500/pinctrl-wm8505.c
 create mode 100644 drivers/pinctrl/vt8500/pinctrl-wm8650.c
 create mode 100644 drivers/pinctrl/vt8500/pinctrl-wm8750.c
 create mode 100644 drivers/pinctrl/vt8500/pinctrl-wm8850.c
 create mode 100644 drivers/pinctrl/vt8500/pinctrl-wmt.c
 create mode 100644 drivers/pinctrl/vt8500/pinctrl-wmt.h

diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-vt8500.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-vt8500.txt
new file mode 100644
index 0000000..b3aa90f
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-vt8500.txt
@@ -0,0 +1,57 @@
+VIA VT8500 and Wondermedia WM8xxx-series pinmux/gpio controller
+
+These SoCs contain a combined Pinmux/GPIO module. Each pin may operate as
+either a GPIO in, GPIO out or as an alternate function (I2C, SPI etc).
+
+Required properties:
+- compatible: "via,vt8500-pinctrl", "wm,wm8505-pinctrl", "wm,wm8650-pinctrl",
+	"wm8750-pinctrl" or "wm,wm8850-pinctrl"
+- reg: Should contain the physical address of the module's registers.
+- interrupt-controller: Marks the device node as an interrupt controller.
+- #interrupt-cells: Should be two.
+- gpio-controller: Marks the device node as a GPIO controller.
+- #gpio-cells : Should be two. The first cell is the pin number and the
+  second cell is used to specify optional parameters.
+	bit 0 - active low
+
+Please refer to ../gpio/gpio.txt for a general description of GPIO bindings.
+
+Please refer to pinctrl-bindings.txt in this directory for details of the
+common pinctrl bindings used by client devices, including the meaning of the
+phrase "pin configuration node".
+
+Each pin configuration node lists the pin(s) to which it applies, and one or
+more of the mux functions to select on those pin(s), and pull-up/down
+configuration. Each subnode only affects those parameters that are explicitly
+listed. In other words, a subnode that lists only a mux function implies no
+information about any pull configuration. Similarly, a subnode that lists only
+a pull parameter implies no information about the mux function.
+
+Required subnode-properties:
+- wm,pins: An array of cells. Each cell contains the ID of a pin.
+
+Optional subnode-properties:
+- wm,function: Integer, containing the function to mux to the pin(s):
+  0: GPIO in
+  1: GPIO out
+  2: alternate
+
+- wm,pull: Integer, representing the pull-down/up to apply to the pin(s):
+  0: none
+  1: down
+  2: up
+
+Each of wm,function and wm,pull may contain either a single value which
+will be applied to all pins in wm,pins, or one value for each entry in
+wm,pins.
+
+Example:
+
+	pinctrl: pinctrl {
+		compatible = "wm,wm8505-pinctrl";
+		reg = <0xD8110000 0x10000>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
diff --git a/arch/arm/mach-vt8500/Kconfig b/arch/arm/mach-vt8500/Kconfig
index e3e94b2..9b25293 100644
--- a/arch/arm/mach-vt8500/Kconfig
+++ b/arch/arm/mach-vt8500/Kconfig
@@ -7,6 +7,7 @@ config ARCH_VT8500
 	select GENERIC_CLOCKEVENTS
 	select HAVE_CLK
 	select VT8500_TIMER
+	select PINCTRL
 	help
 	  Support for VIA/WonderMedia VT8500/WM85xx System-on-Chip.
 
diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index 34f51d2..35e9400 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -229,6 +229,7 @@ config PINCTRL_EXYNOS5440
 source "drivers/pinctrl/mvebu/Kconfig"
 source "drivers/pinctrl/sh-pfc/Kconfig"
 source "drivers/pinctrl/spear/Kconfig"
+source "drivers/pinctrl/vt8500/Kconfig"
 
 config PINCTRL_XWAY
 	bool
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index f82cc5b..a5a52c8 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -52,3 +52,4 @@ obj-$(CONFIG_PLAT_ORION)        += mvebu/
 obj-$(CONFIG_ARCH_SHMOBILE)	+= sh-pfc/
 obj-$(CONFIG_SUPERH)		+= sh-pfc/
 obj-$(CONFIG_PLAT_SPEAR)	+= spear/
+obj-$(CONFIG_ARCH_VT8500)	+= vt8500/
diff --git a/drivers/pinctrl/vt8500/Kconfig b/drivers/pinctrl/vt8500/Kconfig
new file mode 100644
index 0000000..55724a7
--- /dev/null
+++ b/drivers/pinctrl/vt8500/Kconfig
@@ -0,0 +1,52 @@
+#
+# VIA/Wondermedia PINCTRL drivers
+#
+
+if ARCH_VT8500
+
+config PINCTRL_WMT
+	bool
+	select PINMUX
+	select GENERIC_PINCONF
+
+config PINCTRL_VT8500
+	bool "VIA VT8500 pin controller driver"
+	depends on ARCH_WM8505
+	select PINCTRL_WMT
+	help
+	  Say yes here to support the gpio/pin control module on
+	  VIA VT8500 SoCs.
+
+config PINCTRL_WM8505
+	bool "Wondermedia WM8505 pin controller driver"
+	depends on ARCH_WM8505
+	select PINCTRL_WMT
+	help
+	  Say yes here to support the gpio/pin control module on
+	  Wondermedia WM8505 SoCs.
+
+config PINCTRL_WM8650
+	bool "Wondermedia WM8650 pin controller driver"
+	depends on ARCH_WM8505
+	select PINCTRL_WMT
+	help
+	  Say yes here to support the gpio/pin control module on
+	  Wondermedia WM8650 SoCs.
+
+config PINCTRL_WM8750
+	bool "Wondermedia WM8750 pin controller driver"
+	depends on ARCH_WM8750
+	select PINCTRL_WMT
+	help
+	  Say yes here to support the gpio/pin control module on
+	  Wondermedia WM8750 SoCs.
+
+config PINCTRL_WM8850
+	bool "Wondermedia WM8850 pin controller driver"
+	depends on ARCH_WM8850
+	select PINCTRL_WMT
+	help
+	  Say yes here to support the gpio/pin control module on
+	  Wondermedia WM8850 SoCs.
+
+endif
diff --git a/drivers/pinctrl/vt8500/Makefile b/drivers/pinctrl/vt8500/Makefile
new file mode 100644
index 0000000..24ec45d
--- /dev/null
+++ b/drivers/pinctrl/vt8500/Makefile
@@ -0,0 +1,8 @@
+# VIA/Wondermedia pinctrl support
+
+obj-$(CONFIG_PINCTRL_WMT)	+= pinctrl-wmt.o
+obj-$(CONFIG_PINCTRL_VT8500)	+= pinctrl-vt8500.o
+obj-$(CONFIG_PINCTRL_WM8505)	+= pinctrl-wm8505.o
+obj-$(CONFIG_PINCTRL_WM8650)	+= pinctrl-wm8650.o
+obj-$(CONFIG_PINCTRL_WM8750)	+= pinctrl-wm8750.o
+obj-$(CONFIG_PINCTRL_WM8850)	+= pinctrl-wm8850.o
diff --git a/drivers/pinctrl/vt8500/pinctrl-vt8500.c b/drivers/pinctrl/vt8500/pinctrl-vt8500.c
new file mode 100644
index 0000000..f2fe9f8
--- /dev/null
+++ b/drivers/pinctrl/vt8500/pinctrl-vt8500.c
@@ -0,0 +1,501 @@
+/*
+ * Pinctrl data for VIA VT8500 SoC
+ *
+ * Copyright (c) 2013 Tony Prisk <linux at prisktech.co.nz>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ */
+
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/pinctrl/pinctrl.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+
+#include "pinctrl-wmt.h"
+
+/*
+ * Describe the register offsets within the GPIO memory space
+ * The dedicated external GPIO's should always be listed in bank 0
+ * so they are exported in the 0..31 range which is what users
+ * expect.
+ *
+ * Do not reorder these banks as it will change the pin numbering
+ */
+static const struct wmt_pinctrl_bank_registers vt8500_banks[] = {
+	WMT_PINCTRL_BANK(NO_REG, 0x3C, 0x5C, 0x7C, NO_REG, NO_REG),	/* 0 */
+	WMT_PINCTRL_BANK(0x00, 0x20, 0x40, 0x60, NO_REG, NO_REG),	/* 1 */
+	WMT_PINCTRL_BANK(0x04, 0x24, 0x44, 0x64, NO_REG, NO_REG),	/* 2 */
+	WMT_PINCTRL_BANK(0x08, 0x28, 0x48, 0x68, NO_REG, NO_REG),	/* 3 */
+	WMT_PINCTRL_BANK(0x0C, 0x2C, 0x4C, 0x6C, NO_REG, NO_REG),	/* 4 */
+	WMT_PINCTRL_BANK(0x10, 0x30, 0x50, 0x70, NO_REG, NO_REG),	/* 5 */
+	WMT_PINCTRL_BANK(0x14, 0x34, 0x54, 0x74, NO_REG, NO_REG),	/* 6 */
+};
+
+/* Please keep sorted by bank/bit */
+#define WMT_PIN_EXTGPIO0	WMT_PIN(0, 0)
+#define WMT_PIN_EXTGPIO1	WMT_PIN(0, 1)
+#define WMT_PIN_EXTGPIO2	WMT_PIN(0, 2)
+#define WMT_PIN_EXTGPIO3	WMT_PIN(0, 3)
+#define WMT_PIN_EXTGPIO4	WMT_PIN(0, 4)
+#define WMT_PIN_EXTGPIO5	WMT_PIN(0, 5)
+#define WMT_PIN_EXTGPIO6	WMT_PIN(0, 6)
+#define WMT_PIN_EXTGPIO7	WMT_PIN(0, 7)
+#define WMT_PIN_EXTGPIO8	WMT_PIN(0, 8)
+#define WMT_PIN_UART0RTS	WMT_PIN(1, 0)
+#define WMT_PIN_UART0TXD	WMT_PIN(1, 1)
+#define WMT_PIN_UART0CTS	WMT_PIN(1, 2)
+#define WMT_PIN_UART0RXD	WMT_PIN(1, 3)
+#define WMT_PIN_UART1RTS	WMT_PIN(1, 4)
+#define WMT_PIN_UART1TXD	WMT_PIN(1, 5)
+#define WMT_PIN_UART1CTS	WMT_PIN(1, 6)
+#define WMT_PIN_UART1RXD	WMT_PIN(1, 7)
+#define WMT_PIN_SPI0CLK		WMT_PIN(1, 8)
+#define WMT_PIN_SPI0SS		WMT_PIN(1, 9)
+#define WMT_PIN_SPI0MISO	WMT_PIN(1, 10)
+#define WMT_PIN_SPI0MOSI	WMT_PIN(1, 11)
+#define WMT_PIN_SPI1CLK		WMT_PIN(1, 12)
+#define WMT_PIN_SPI1SS		WMT_PIN(1, 13)
+#define WMT_PIN_SPI1MISO	WMT_PIN(1, 14)
+#define WMT_PIN_SPI1MOSI	WMT_PIN(1, 15)
+#define WMT_PIN_SPI2CLK		WMT_PIN(1, 16)
+#define WMT_PIN_SPI2SS		WMT_PIN(1, 17)
+#define WMT_PIN_SPI2MISO	WMT_PIN(1, 18)
+#define WMT_PIN_SPI2MOSI	WMT_PIN(1, 19)
+#define WMT_PIN_SDDATA0		WMT_PIN(2, 0)
+#define WMT_PIN_SDDATA1		WMT_PIN(2, 1)
+#define WMT_PIN_SDDATA2		WMT_PIN(2, 2)
+#define WMT_PIN_SDDATA3		WMT_PIN(2, 3)
+#define WMT_PIN_MMCDATA0	WMT_PIN(2, 4)
+#define WMT_PIN_MMCDATA1	WMT_PIN(2, 5)
+#define WMT_PIN_MMCDATA2	WMT_PIN(2, 6)
+#define WMT_PIN_MMCDATA3	WMT_PIN(2, 7)
+#define WMT_PIN_SDCLK		WMT_PIN(2, 8)
+#define WMT_PIN_SDWP		WMT_PIN(2, 9)
+#define WMT_PIN_SDCMD		WMT_PIN(2, 10)
+#define WMT_PIN_MSDATA0		WMT_PIN(2, 16)
+#define WMT_PIN_MSDATA1		WMT_PIN(2, 17)
+#define WMT_PIN_MSDATA2		WMT_PIN(2, 18)
+#define WMT_PIN_MSDATA3		WMT_PIN(2, 19)
+#define WMT_PIN_MSCLK		WMT_PIN(2, 20)
+#define WMT_PIN_MSBS		WMT_PIN(2, 21)
+#define WMT_PIN_MSINS		WMT_PIN(2, 22)
+#define WMT_PIN_I2C0SCL		WMT_PIN(2, 24)
+#define WMT_PIN_I2C0SDA		WMT_PIN(2, 25)
+#define WMT_PIN_I2C1SCL		WMT_PIN(2, 26)
+#define WMT_PIN_I2C1SDA		WMT_PIN(2, 27)
+#define WMT_PIN_MII0RXD0	WMT_PIN(3, 0)
+#define WMT_PIN_MII0RXD1	WMT_PIN(3, 1)
+#define WMT_PIN_MII0RXD2	WMT_PIN(3, 2)
+#define WMT_PIN_MII0RXD3	WMT_PIN(3, 3)
+#define WMT_PIN_MII0RXCLK	WMT_PIN(3, 4)
+#define WMT_PIN_MII0RXDV	WMT_PIN(3, 5)
+#define WMT_PIN_MII0RXERR	WMT_PIN(3, 6)
+#define WMT_PIN_MII0PHYRST	WMT_PIN(3, 7)
+#define WMT_PIN_MII0TXD0	WMT_PIN(3, 8)
+#define WMT_PIN_MII0TXD1	WMT_PIN(3, 9)
+#define WMT_PIN_MII0TXD2	WMT_PIN(3, 10)
+#define WMT_PIN_MII0TXD3	WMT_PIN(3, 11)
+#define WMT_PIN_MII0TXCLK	WMT_PIN(3, 12)
+#define WMT_PIN_MII0TXEN	WMT_PIN(3, 13)
+#define WMT_PIN_MII0TXERR	WMT_PIN(3, 14)
+#define WMT_PIN_MII0PHYPD	WMT_PIN(3, 15)
+#define WMT_PIN_MII0COL		WMT_PIN(3, 16)
+#define WMT_PIN_MII0CRS		WMT_PIN(3, 17)
+#define WMT_PIN_MII0MDIO	WMT_PIN(3, 18)
+#define WMT_PIN_MII0MDC		WMT_PIN(3, 19)
+#define WMT_PIN_SEECS		WMT_PIN(3, 20)
+#define WMT_PIN_SEECK		WMT_PIN(3, 21)
+#define WMT_PIN_SEEDI		WMT_PIN(3, 22)
+#define WMT_PIN_SEEDO		WMT_PIN(3, 23)
+#define WMT_PIN_IDEDREQ0	WMT_PIN(3, 24)
+#define WMT_PIN_IDEDREQ1	WMT_PIN(3, 25)
+#define WMT_PIN_IDEIOW		WMT_PIN(3, 26)
+#define WMT_PIN_IDEIOR		WMT_PIN(3, 27)
+#define WMT_PIN_IDEDACK		WMT_PIN(3, 28)
+#define WMT_PIN_IDEIORDY	WMT_PIN(3, 29)
+#define WMT_PIN_IDEINTRQ	WMT_PIN(3, 30)
+#define WMT_PIN_VDIN0		WMT_PIN(4, 0)
+#define WMT_PIN_VDIN1		WMT_PIN(4, 1)
+#define WMT_PIN_VDIN2		WMT_PIN(4, 2)
+#define WMT_PIN_VDIN3		WMT_PIN(4, 3)
+#define WMT_PIN_VDIN4		WMT_PIN(4, 4)
+#define WMT_PIN_VDIN5		WMT_PIN(4, 5)
+#define WMT_PIN_VDIN6		WMT_PIN(4, 6)
+#define WMT_PIN_VDIN7		WMT_PIN(4, 7)
+#define WMT_PIN_VDOUT0		WMT_PIN(4, 8)
+#define WMT_PIN_VDOUT1		WMT_PIN(4, 9)
+#define WMT_PIN_VDOUT2		WMT_PIN(4, 10)
+#define WMT_PIN_VDOUT3		WMT_PIN(4, 11)
+#define WMT_PIN_VDOUT4		WMT_PIN(4, 12)
+#define WMT_PIN_VDOUT5		WMT_PIN(4, 13)
+#define WMT_PIN_NANDCLE0	WMT_PIN(4, 14)
+#define WMT_PIN_NANDCLE1	WMT_PIN(4, 15)
+#define WMT_PIN_VDOUT6_7	WMT_PIN(4, 16)
+#define WMT_PIN_VHSYNC		WMT_PIN(4, 17)
+#define WMT_PIN_VVSYNC		WMT_PIN(4, 18)
+#define WMT_PIN_TSDIN0		WMT_PIN(5, 8)
+#define WMT_PIN_TSDIN1		WMT_PIN(5, 9)
+#define WMT_PIN_TSDIN2		WMT_PIN(5, 10)
+#define WMT_PIN_TSDIN3		WMT_PIN(5, 11)
+#define WMT_PIN_TSDIN4		WMT_PIN(5, 12)
+#define WMT_PIN_TSDIN5		WMT_PIN(5, 13)
+#define WMT_PIN_TSDIN6		WMT_PIN(5, 14)
+#define WMT_PIN_TSDIN7		WMT_PIN(5, 15)
+#define WMT_PIN_TSSYNC		WMT_PIN(5, 16)
+#define WMT_PIN_TSVALID		WMT_PIN(5, 17)
+#define WMT_PIN_TSCLK		WMT_PIN(5, 18)
+#define WMT_PIN_LCDD0		WMT_PIN(6, 0)
+#define WMT_PIN_LCDD1		WMT_PIN(6, 1)
+#define WMT_PIN_LCDD2		WMT_PIN(6, 2)
+#define WMT_PIN_LCDD3		WMT_PIN(6, 3)
+#define WMT_PIN_LCDD4		WMT_PIN(6, 4)
+#define WMT_PIN_LCDD5		WMT_PIN(6, 5)
+#define WMT_PIN_LCDD6		WMT_PIN(6, 6)
+#define WMT_PIN_LCDD7		WMT_PIN(6, 7)
+#define WMT_PIN_LCDD8		WMT_PIN(6, 8)
+#define WMT_PIN_LCDD9		WMT_PIN(6, 9)
+#define WMT_PIN_LCDD10		WMT_PIN(6, 10)
+#define WMT_PIN_LCDD11		WMT_PIN(6, 11)
+#define WMT_PIN_LCDD12		WMT_PIN(6, 12)
+#define WMT_PIN_LCDD13		WMT_PIN(6, 13)
+#define WMT_PIN_LCDD14		WMT_PIN(6, 14)
+#define WMT_PIN_LCDD15		WMT_PIN(6, 15)
+#define WMT_PIN_LCDD16		WMT_PIN(6, 16)
+#define WMT_PIN_LCDD17		WMT_PIN(6, 17)
+#define WMT_PIN_LCDCLK		WMT_PIN(6, 18)
+#define WMT_PIN_LCDDEN		WMT_PIN(6, 19)
+#define WMT_PIN_LCDLINE		WMT_PIN(6, 20)
+#define WMT_PIN_LCDFRM		WMT_PIN(6, 21)
+#define WMT_PIN_LCDBIAS		WMT_PIN(6, 22)
+
+static const struct pinctrl_pin_desc vt8500_pins[] = {
+	PINCTRL_PIN(WMT_PIN_EXTGPIO0, "extgpio0"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO1, "extgpio1"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO2, "extgpio2"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO3, "extgpio3"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO4, "extgpio4"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO5, "extgpio5"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO6, "extgpio6"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO7, "extgpio7"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO8, "extgpio8"),
+	PINCTRL_PIN(WMT_PIN_UART0RTS, "uart0_rts"),
+	PINCTRL_PIN(WMT_PIN_UART0TXD, "uart0_txd"),
+	PINCTRL_PIN(WMT_PIN_UART0CTS, "uart0_cts"),
+	PINCTRL_PIN(WMT_PIN_UART0RXD, "uart0_rxd"),
+	PINCTRL_PIN(WMT_PIN_UART1RTS, "uart1_rts"),
+	PINCTRL_PIN(WMT_PIN_UART1TXD, "uart1_txd"),
+	PINCTRL_PIN(WMT_PIN_UART1CTS, "uart1_cts"),
+	PINCTRL_PIN(WMT_PIN_UART1RXD, "uart1_rxd"),
+	PINCTRL_PIN(WMT_PIN_SPI0CLK, "spi0_clk"),
+	PINCTRL_PIN(WMT_PIN_SPI0SS, "spi0_ss"),
+	PINCTRL_PIN(WMT_PIN_SPI0MISO, "spi0_miso"),
+	PINCTRL_PIN(WMT_PIN_SPI0MOSI, "spi0_mosi"),
+	PINCTRL_PIN(WMT_PIN_SPI1CLK, "spi1_clk"),
+	PINCTRL_PIN(WMT_PIN_SPI1SS, "spi1_ss"),
+	PINCTRL_PIN(WMT_PIN_SPI1MISO, "spi1_miso"),
+	PINCTRL_PIN(WMT_PIN_SPI1MOSI, "spi1_mosi"),
+	PINCTRL_PIN(WMT_PIN_SPI2CLK, "spi2_clk"),
+	PINCTRL_PIN(WMT_PIN_SPI2SS, "spi2_ss"),
+	PINCTRL_PIN(WMT_PIN_SPI2MISO, "spi2_miso"),
+	PINCTRL_PIN(WMT_PIN_SPI2MOSI, "spi2_mosi"),
+	PINCTRL_PIN(WMT_PIN_SDDATA0, "sd_data0"),
+	PINCTRL_PIN(WMT_PIN_SDDATA1, "sd_data1"),
+	PINCTRL_PIN(WMT_PIN_SDDATA2, "sd_data2"),
+	PINCTRL_PIN(WMT_PIN_SDDATA3, "sd_data3"),
+	PINCTRL_PIN(WMT_PIN_MMCDATA0, "mmc_data0"),
+	PINCTRL_PIN(WMT_PIN_MMCDATA1, "mmc_data1"),
+	PINCTRL_PIN(WMT_PIN_MMCDATA2, "mmc_data2"),
+	PINCTRL_PIN(WMT_PIN_MMCDATA3, "mmc_data3"),
+	PINCTRL_PIN(WMT_PIN_SDCLK, "sd_clk"),
+	PINCTRL_PIN(WMT_PIN_SDWP, "sd_wp"),
+	PINCTRL_PIN(WMT_PIN_SDCMD, "sd_cmd"),
+	PINCTRL_PIN(WMT_PIN_MSDATA0, "ms_data0"),
+	PINCTRL_PIN(WMT_PIN_MSDATA1, "ms_data1"),
+	PINCTRL_PIN(WMT_PIN_MSDATA2, "ms_data2"),
+	PINCTRL_PIN(WMT_PIN_MSDATA3, "ms_data3"),
+	PINCTRL_PIN(WMT_PIN_MSCLK, "ms_clk"),
+	PINCTRL_PIN(WMT_PIN_MSBS, "ms_bs"),
+	PINCTRL_PIN(WMT_PIN_MSINS, "ms_ins"),
+	PINCTRL_PIN(WMT_PIN_I2C0SCL, "i2c0_scl"),
+	PINCTRL_PIN(WMT_PIN_I2C0SDA, "i2c0_sda"),
+	PINCTRL_PIN(WMT_PIN_I2C1SCL, "i2c1_scl"),
+	PINCTRL_PIN(WMT_PIN_I2C1SDA, "i2c1_sda"),
+	PINCTRL_PIN(WMT_PIN_MII0RXD0, "mii0_rxd0"),
+	PINCTRL_PIN(WMT_PIN_MII0RXD1, "mii0_rxd1"),
+	PINCTRL_PIN(WMT_PIN_MII0RXD2, "mii0_rxd2"),
+	PINCTRL_PIN(WMT_PIN_MII0RXD3, "mii0_rxd3"),
+	PINCTRL_PIN(WMT_PIN_MII0RXCLK, "mii0_rxclk"),
+	PINCTRL_PIN(WMT_PIN_MII0RXDV, "mii0_rxdv"),
+	PINCTRL_PIN(WMT_PIN_MII0RXERR, "mii0_rxerr"),
+	PINCTRL_PIN(WMT_PIN_MII0PHYRST, "mii0_phyrst"),
+	PINCTRL_PIN(WMT_PIN_MII0TXD0, "mii0_txd0"),
+	PINCTRL_PIN(WMT_PIN_MII0TXD1, "mii0_txd1"),
+	PINCTRL_PIN(WMT_PIN_MII0TXD2, "mii0_txd2"),
+	PINCTRL_PIN(WMT_PIN_MII0TXD3, "mii0_txd3"),
+	PINCTRL_PIN(WMT_PIN_MII0TXCLK, "mii0_txclk"),
+	PINCTRL_PIN(WMT_PIN_MII0TXEN, "mii0_txen"),
+	PINCTRL_PIN(WMT_PIN_MII0TXERR, "mii0_txerr"),
+	PINCTRL_PIN(WMT_PIN_MII0PHYPD, "mii0_phypd"),
+	PINCTRL_PIN(WMT_PIN_MII0COL, "mii0_col"),
+	PINCTRL_PIN(WMT_PIN_MII0CRS, "mii0_crs"),
+	PINCTRL_PIN(WMT_PIN_MII0MDIO, "mii0_mdio"),
+	PINCTRL_PIN(WMT_PIN_MII0MDC, "mii0_mdc"),
+	PINCTRL_PIN(WMT_PIN_SEECS, "see_cs"),
+	PINCTRL_PIN(WMT_PIN_SEECK, "see_ck"),
+	PINCTRL_PIN(WMT_PIN_SEEDI, "see_di"),
+	PINCTRL_PIN(WMT_PIN_SEEDO, "see_do"),
+	PINCTRL_PIN(WMT_PIN_IDEDREQ0, "ide_dreq0"),
+	PINCTRL_PIN(WMT_PIN_IDEDREQ1, "ide_dreq1"),
+	PINCTRL_PIN(WMT_PIN_IDEIOW, "ide_iow"),
+	PINCTRL_PIN(WMT_PIN_IDEIOR, "ide_ior"),
+	PINCTRL_PIN(WMT_PIN_IDEDACK, "ide_dack"),
+	PINCTRL_PIN(WMT_PIN_IDEIORDY, "ide_iordy"),
+	PINCTRL_PIN(WMT_PIN_IDEINTRQ, "ide_intrq"),
+	PINCTRL_PIN(WMT_PIN_VDIN0, "vdin0"),
+	PINCTRL_PIN(WMT_PIN_VDIN1, "vdin1"),
+	PINCTRL_PIN(WMT_PIN_VDIN2, "vdin2"),
+	PINCTRL_PIN(WMT_PIN_VDIN3, "vdin3"),
+	PINCTRL_PIN(WMT_PIN_VDIN4, "vdin4"),
+	PINCTRL_PIN(WMT_PIN_VDIN5, "vdin5"),
+	PINCTRL_PIN(WMT_PIN_VDIN6, "vdin6"),
+	PINCTRL_PIN(WMT_PIN_VDIN7, "vdin7"),
+	PINCTRL_PIN(WMT_PIN_VDOUT0, "vdout0"),
+	PINCTRL_PIN(WMT_PIN_VDOUT1, "vdout1"),
+	PINCTRL_PIN(WMT_PIN_VDOUT2, "vdout2"),
+	PINCTRL_PIN(WMT_PIN_VDOUT3, "vdout3"),
+	PINCTRL_PIN(WMT_PIN_VDOUT4, "vdout4"),
+	PINCTRL_PIN(WMT_PIN_VDOUT5, "vdout5"),
+	PINCTRL_PIN(WMT_PIN_NANDCLE0, "nand_cle0"),
+	PINCTRL_PIN(WMT_PIN_NANDCLE1, "nand_cle1"),
+	PINCTRL_PIN(WMT_PIN_VDOUT6_7, "vdout6_7"),
+	PINCTRL_PIN(WMT_PIN_VHSYNC, "vhsync"),
+	PINCTRL_PIN(WMT_PIN_VVSYNC, "vvsync"),
+	PINCTRL_PIN(WMT_PIN_TSDIN0, "tsdin0"),
+	PINCTRL_PIN(WMT_PIN_TSDIN1, "tsdin1"),
+	PINCTRL_PIN(WMT_PIN_TSDIN2, "tsdin2"),
+	PINCTRL_PIN(WMT_PIN_TSDIN3, "tsdin3"),
+	PINCTRL_PIN(WMT_PIN_TSDIN4, "tsdin4"),
+	PINCTRL_PIN(WMT_PIN_TSDIN5, "tsdin5"),
+	PINCTRL_PIN(WMT_PIN_TSDIN6, "tsdin6"),
+	PINCTRL_PIN(WMT_PIN_TSDIN7, "tsdin7"),
+	PINCTRL_PIN(WMT_PIN_TSSYNC, "tssync"),
+	PINCTRL_PIN(WMT_PIN_TSVALID, "tsvalid"),
+	PINCTRL_PIN(WMT_PIN_TSCLK, "tsclk"),
+	PINCTRL_PIN(WMT_PIN_LCDD0, "lcd_d0"),
+	PINCTRL_PIN(WMT_PIN_LCDD1, "lcd_d1"),
+	PINCTRL_PIN(WMT_PIN_LCDD2, "lcd_d2"),
+	PINCTRL_PIN(WMT_PIN_LCDD3, "lcd_d3"),
+	PINCTRL_PIN(WMT_PIN_LCDD4, "lcd_d4"),
+	PINCTRL_PIN(WMT_PIN_LCDD5, "lcd_d5"),
+	PINCTRL_PIN(WMT_PIN_LCDD6, "lcd_d6"),
+	PINCTRL_PIN(WMT_PIN_LCDD7, "lcd_d7"),
+	PINCTRL_PIN(WMT_PIN_LCDD8, "lcd_d8"),
+	PINCTRL_PIN(WMT_PIN_LCDD9, "lcd_d9"),
+	PINCTRL_PIN(WMT_PIN_LCDD10, "lcd_d10"),
+	PINCTRL_PIN(WMT_PIN_LCDD11, "lcd_d11"),
+	PINCTRL_PIN(WMT_PIN_LCDD12, "lcd_d12"),
+	PINCTRL_PIN(WMT_PIN_LCDD13, "lcd_d13"),
+	PINCTRL_PIN(WMT_PIN_LCDD14, "lcd_d14"),
+	PINCTRL_PIN(WMT_PIN_LCDD15, "lcd_d15"),
+	PINCTRL_PIN(WMT_PIN_LCDD16, "lcd_d16"),
+	PINCTRL_PIN(WMT_PIN_LCDD17, "lcd_d17"),
+	PINCTRL_PIN(WMT_PIN_LCDCLK, "lcd_clk"),
+	PINCTRL_PIN(WMT_PIN_LCDDEN, "lcd_den"),
+	PINCTRL_PIN(WMT_PIN_LCDLINE, "lcd_line"),
+	PINCTRL_PIN(WMT_PIN_LCDFRM, "lcd_frm"),
+	PINCTRL_PIN(WMT_PIN_LCDBIAS, "lcd_bias"),
+};
+
+/* Order of these names must match the above list */
+static const char * const vt8500_groups[] = {
+	"extgpio0",
+	"extgpio1",
+	"extgpio2",
+	"extgpio3",
+	"extgpio4",
+	"extgpio5",
+	"extgpio6",
+	"extgpio7",
+	"extgpio8",
+	"uart0_rts",
+	"uart0_txd",
+	"uart0_cts",
+	"uart0_rxd",
+	"uart1_rts",
+	"uart1_txd",
+	"uart1_cts",
+	"uart1_rxd",
+	"spi0_clk",
+	"spi0_ss",
+	"spi0_miso",
+	"spi0_mosi",
+	"spi1_clk",
+	"spi1_ss",
+	"spi1_miso",
+	"spi1_mosi",
+	"spi2_clk",
+	"spi2_ss",
+	"spi2_miso",
+	"spi2_mosi",
+	"sd_data0",
+	"sd_data1",
+	"sd_data2",
+	"sd_data3",
+	"mmc_data0",
+	"mmc_data1",
+	"mmc_data2",
+	"mmc_data3",
+	"sd_clk",
+	"sd_wp",
+	"sd_cmd",
+	"ms_data0",
+	"ms_data1",
+	"ms_data2",
+	"ms_data3",
+	"ms_clk",
+	"ms_bs",
+	"ms_ins",
+	"i2c0_scl",
+	"i2c0_sda",
+	"i2c1_scl",
+	"i2c1_sda",
+	"mii0_rxd0",
+	"mii0_rxd1",
+	"mii0_rxd2",
+	"mii0_rxd3",
+	"mii0_rxclk",
+	"mii0_rxdv",
+	"mii0_rxerr",
+	"mii0_phyrst",
+	"mii0_txd0",
+	"mii0_txd1",
+	"mii0_txd2",
+	"mii0_txd3",
+	"mii0_txclk",
+	"mii0_txen",
+	"mii0_txerr",
+	"mii0_phypd",
+	"mii0_col",
+	"mii0_crs",
+	"mii0_mdio",
+	"mii0_mdc",
+	"see_cs",
+	"see_ck",
+	"see_di",
+	"see_do",
+	"ide_dreq0",
+	"ide_dreq1",
+	"ide_iow",
+	"ide_ior",
+	"ide_dack",
+	"ide_iordy",
+	"ide_intrq",
+	"vdin0",
+	"vdin1",
+	"vdin2",
+	"vdin3",
+	"vdin4",
+	"vdin5",
+	"vdin6",
+	"vdin7",
+	"vdout0",
+	"vdout1",
+	"vdout2",
+	"vdout3",
+	"vdout4",
+	"vdout5",
+	"nand_cle0",
+	"nand_cle1",
+	"vdout6_7",
+	"vhsync",
+	"vvsync",
+	"tsdin0",
+	"tsdin1",
+	"tsdin2",
+	"tsdin3",
+	"tsdin4",
+	"tsdin5",
+	"tsdin6",
+	"tsdin7",
+	"tssync",
+	"tsvalid",
+	"tsclk",
+	"lcd_d0",
+	"lcd_d1",
+	"lcd_d2",
+	"lcd_d3",
+	"lcd_d4",
+	"lcd_d5",
+	"lcd_d6",
+	"lcd_d7",
+	"lcd_d8",
+	"lcd_d9",
+	"lcd_d10",
+	"lcd_d11",
+	"lcd_d12",
+	"lcd_d13",
+	"lcd_d14",
+	"lcd_d15",
+	"lcd_d16",
+	"lcd_d17",
+	"lcd_clk",
+	"lcd_den",
+	"lcd_line",
+	"lcd_frm",
+	"lcd_bias",
+};
+
+static int vt8500_pinctrl_probe(struct platform_device *pdev)
+{
+	struct wmt_pinctrl_data *data;
+
+	data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
+	if (!data) {
+		dev_err(&pdev->dev, "failed to allocate data\n");
+		return -ENOMEM;
+	}
+
+	data->banks = vt8500_banks;
+	data->nbanks = ARRAY_SIZE(vt8500_banks);
+	data->pins = vt8500_pins;
+	data->npins = ARRAY_SIZE(vt8500_pins);
+	data->groups = vt8500_groups;
+	data->ngroups = ARRAY_SIZE(vt8500_groups);
+
+	return wmt_pinctrl_probe(pdev, data);
+}
+
+static int vt8500_pinctrl_remove(struct platform_device *pdev)
+{
+	return wmt_pinctrl_remove(pdev);
+}
+
+static struct of_device_id wmt_pinctrl_of_match[] = {
+	{ .compatible = "via,vt8500-pinctrl" },
+	{ /* sentinel */ },
+};
+
+static struct platform_driver wmt_pinctrl_driver = {
+	.probe	= vt8500_pinctrl_probe,
+	.remove	= vt8500_pinctrl_remove,
+	.driver = {
+		.name	= "pinctrl-vt8500",
+		.owner	= THIS_MODULE,
+		.of_match_table	= wmt_pinctrl_of_match,
+	},
+};
+
+module_platform_driver(wmt_pinctrl_driver);
+
+MODULE_AUTHOR("Tony Prisk <linux at prisktech.co.nz>");
+MODULE_DESCRIPTION("VIA VT8500 Pincontrol driver");
+MODULE_LICENSE("GPL v2");
+MODULE_DEVICE_TABLE(of, wmt_pinctrl_of_match);
diff --git a/drivers/pinctrl/vt8500/pinctrl-wm8505.c b/drivers/pinctrl/vt8500/pinctrl-wm8505.c
new file mode 100644
index 0000000..483ba73
--- /dev/null
+++ b/drivers/pinctrl/vt8500/pinctrl-wm8505.c
@@ -0,0 +1,532 @@
+/*
+ * Pinctrl data for Wondermedia WM8505 SoC
+ *
+ * Copyright (c) 2013 Tony Prisk <linux at prisktech.co.nz>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ */
+
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/pinctrl/pinctrl.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+
+#include "pinctrl-wmt.h"
+
+/*
+ * Describe the register offsets within the GPIO memory space
+ * The dedicated external GPIO's should always be listed in bank 0
+ * so they are exported in the 0..31 range which is what users
+ * expect.
+ *
+ * Do not reorder these banks as it will change the pin numbering
+ */
+static const struct wmt_pinctrl_bank_registers wm8505_banks[] = {
+	WMT_PINCTRL_BANK(0x64, 0x8C, 0xB4, 0xDC, NO_REG, NO_REG),	/* 0 */
+	WMT_PINCTRL_BANK(0x40, 0x68, 0x90, 0xB8, NO_REG, NO_REG),	/* 1 */
+	WMT_PINCTRL_BANK(0x44, 0x6C, 0x94, 0xBC, NO_REG, NO_REG),	/* 2 */
+	WMT_PINCTRL_BANK(0x48, 0x70, 0x98, 0xC0, NO_REG, NO_REG),	/* 3 */
+	WMT_PINCTRL_BANK(0x4C, 0x74, 0x9C, 0xC4, NO_REG, NO_REG),	/* 4 */
+	WMT_PINCTRL_BANK(0x50, 0x78, 0xA0, 0xC8, NO_REG, NO_REG),	/* 5 */
+	WMT_PINCTRL_BANK(0x54, 0x7C, 0xA4, 0xD0, NO_REG, NO_REG),	/* 6 */
+	WMT_PINCTRL_BANK(0x58, 0x80, 0xA8, 0xD4, NO_REG, NO_REG),	/* 7 */
+	WMT_PINCTRL_BANK(0x5C, 0x84, 0xAC, 0xD8, NO_REG, NO_REG),	/* 8 */
+	WMT_PINCTRL_BANK(0x60, 0x88, 0xB0, 0xDC, NO_REG, NO_REG),	/* 9 */
+	WMT_PINCTRL_BANK(0x500, 0x504, 0x508, 0x50C, NO_REG, NO_REG),	/* 10 */
+};
+
+/* Please keep sorted by bank/bit */
+#define WMT_PIN_EXTGPIO0	WMT_PIN(0, 0)
+#define WMT_PIN_EXTGPIO1	WMT_PIN(0, 1)
+#define WMT_PIN_EXTGPIO2	WMT_PIN(0, 2)
+#define WMT_PIN_EXTGPIO3	WMT_PIN(0, 3)
+#define WMT_PIN_EXTGPIO4	WMT_PIN(0, 4)
+#define WMT_PIN_EXTGPIO5	WMT_PIN(0, 5)
+#define WMT_PIN_EXTGPIO6	WMT_PIN(0, 6)
+#define WMT_PIN_EXTGPIO7	WMT_PIN(0, 7)
+#define WMT_PIN_WAKEUP0		WMT_PIN(0, 16)
+#define WMT_PIN_WAKEUP1		WMT_PIN(0, 17)
+#define WMT_PIN_WAKEUP2		WMT_PIN(0, 18)
+#define WMT_PIN_WAKEUP3		WMT_PIN(0, 19)
+#define WMT_PIN_SUSGPIO0	WMT_PIN(0, 21)
+#define WMT_PIN_SDDATA0		WMT_PIN(1, 0)
+#define WMT_PIN_SDDATA1		WMT_PIN(1, 1)
+#define WMT_PIN_SDDATA2		WMT_PIN(1, 2)
+#define WMT_PIN_SDDATA3		WMT_PIN(1, 3)
+#define WMT_PIN_MMCDATA0	WMT_PIN(1, 4)
+#define WMT_PIN_MMCDATA1	WMT_PIN(1, 5)
+#define WMT_PIN_MMCDATA2	WMT_PIN(1, 6)
+#define WMT_PIN_MMCDATA3	WMT_PIN(1, 7)
+#define WMT_PIN_VDIN0		WMT_PIN(2, 0)
+#define WMT_PIN_VDIN1		WMT_PIN(2, 1)
+#define WMT_PIN_VDIN2		WMT_PIN(2, 2)
+#define WMT_PIN_VDIN3		WMT_PIN(2, 3)
+#define WMT_PIN_VDIN4		WMT_PIN(2, 4)
+#define WMT_PIN_VDIN5		WMT_PIN(2, 5)
+#define WMT_PIN_VDIN6		WMT_PIN(2, 6)
+#define WMT_PIN_VDIN7		WMT_PIN(2, 7)
+#define WMT_PIN_VDOUT0		WMT_PIN(2, 8)
+#define WMT_PIN_VDOUT1		WMT_PIN(2, 9)
+#define WMT_PIN_VDOUT2		WMT_PIN(2, 10)
+#define WMT_PIN_VDOUT3		WMT_PIN(2, 11)
+#define WMT_PIN_VDOUT4		WMT_PIN(2, 12)
+#define WMT_PIN_VDOUT5		WMT_PIN(2, 13)
+#define WMT_PIN_VDOUT6		WMT_PIN(2, 14)
+#define WMT_PIN_VDOUT7		WMT_PIN(2, 15)
+#define WMT_PIN_VDOUT8		WMT_PIN(2, 16)
+#define WMT_PIN_VDOUT9		WMT_PIN(2, 17)
+#define WMT_PIN_VDOUT10		WMT_PIN(2, 18)
+#define WMT_PIN_VDOUT11		WMT_PIN(2, 19)
+#define WMT_PIN_VDOUT12		WMT_PIN(2, 20)
+#define WMT_PIN_VDOUT13		WMT_PIN(2, 21)
+#define WMT_PIN_VDOUT14		WMT_PIN(2, 22)
+#define WMT_PIN_VDOUT15		WMT_PIN(2, 23)
+#define WMT_PIN_VDOUT16		WMT_PIN(2, 24)
+#define WMT_PIN_VDOUT17		WMT_PIN(2, 25)
+#define WMT_PIN_VDOUT18		WMT_PIN(2, 26)
+#define WMT_PIN_VDOUT19		WMT_PIN(2, 27)
+#define WMT_PIN_VDOUT20		WMT_PIN(2, 28)
+#define WMT_PIN_VDOUT21		WMT_PIN(2, 29)
+#define WMT_PIN_VDOUT22		WMT_PIN(2, 30)
+#define WMT_PIN_VDOUT23		WMT_PIN(2, 31)
+#define WMT_PIN_VHSYNC		WMT_PIN(3, 0)
+#define WMT_PIN_VVSYNC		WMT_PIN(3, 1)
+#define WMT_PIN_VGAHSYNC	WMT_PIN(3, 2)
+#define WMT_PIN_VGAVSYNC	WMT_PIN(3, 3)
+#define WMT_PIN_VDHSYNC		WMT_PIN(3, 4)
+#define WMT_PIN_VDVSYNC		WMT_PIN(3, 5)
+#define WMT_PIN_NORD0		WMT_PIN(4, 0)
+#define WMT_PIN_NORD1		WMT_PIN(4, 1)
+#define WMT_PIN_NORD2		WMT_PIN(4, 2)
+#define WMT_PIN_NORD3		WMT_PIN(4, 3)
+#define WMT_PIN_NORD4		WMT_PIN(4, 4)
+#define WMT_PIN_NORD5		WMT_PIN(4, 5)
+#define WMT_PIN_NORD6		WMT_PIN(4, 6)
+#define WMT_PIN_NORD7		WMT_PIN(4, 7)
+#define WMT_PIN_NORD8		WMT_PIN(4, 8)
+#define WMT_PIN_NORD9		WMT_PIN(4, 9)
+#define WMT_PIN_NORD10		WMT_PIN(4, 10)
+#define WMT_PIN_NORD11		WMT_PIN(4, 11)
+#define WMT_PIN_NORD12		WMT_PIN(4, 12)
+#define WMT_PIN_NORD13		WMT_PIN(4, 13)
+#define WMT_PIN_NORD14		WMT_PIN(4, 14)
+#define WMT_PIN_NORD15		WMT_PIN(4, 15)
+#define WMT_PIN_NORA0		WMT_PIN(5, 0)
+#define WMT_PIN_NORA1		WMT_PIN(5, 1)
+#define WMT_PIN_NORA2		WMT_PIN(5, 2)
+#define WMT_PIN_NORA3		WMT_PIN(5, 3)
+#define WMT_PIN_NORA4		WMT_PIN(5, 4)
+#define WMT_PIN_NORA5		WMT_PIN(5, 5)
+#define WMT_PIN_NORA6		WMT_PIN(5, 6)
+#define WMT_PIN_NORA7		WMT_PIN(5, 7)
+#define WMT_PIN_NORA8		WMT_PIN(5, 8)
+#define WMT_PIN_NORA9		WMT_PIN(5, 9)
+#define WMT_PIN_NORA10		WMT_PIN(5, 10)
+#define WMT_PIN_NORA11		WMT_PIN(5, 11)
+#define WMT_PIN_NORA12		WMT_PIN(5, 12)
+#define WMT_PIN_NORA13		WMT_PIN(5, 13)
+#define WMT_PIN_NORA14		WMT_PIN(5, 14)
+#define WMT_PIN_NORA15		WMT_PIN(5, 15)
+#define WMT_PIN_NORA16		WMT_PIN(5, 16)
+#define WMT_PIN_NORA17		WMT_PIN(5, 17)
+#define WMT_PIN_NORA18		WMT_PIN(5, 18)
+#define WMT_PIN_NORA19		WMT_PIN(5, 19)
+#define WMT_PIN_NORA20		WMT_PIN(5, 20)
+#define WMT_PIN_NORA21		WMT_PIN(5, 21)
+#define WMT_PIN_NORA22		WMT_PIN(5, 22)
+#define WMT_PIN_NORA23		WMT_PIN(5, 23)
+#define WMT_PIN_NORA24		WMT_PIN(5, 24)
+#define WMT_PIN_AC97SDI		WMT_PIN(6, 0)
+#define WMT_PIN_AC97SYNC	WMT_PIN(6, 1)
+#define WMT_PIN_AC97SDO		WMT_PIN(6, 2)
+#define WMT_PIN_AC97BCLK	WMT_PIN(6, 3)
+#define WMT_PIN_AC97RST		WMT_PIN(6, 4)
+#define WMT_PIN_SFDO		WMT_PIN(7, 0)
+#define WMT_PIN_SFCS0		WMT_PIN(7, 1)
+#define WMT_PIN_SFCS1		WMT_PIN(7, 2)
+#define WMT_PIN_SFCLK		WMT_PIN(7, 3)
+#define WMT_PIN_SFDI		WMT_PIN(7, 4)
+#define WMT_PIN_SPI0CLK		WMT_PIN(8, 0)
+#define WMT_PIN_SPI0MISO	WMT_PIN(8, 1)
+#define WMT_PIN_SPI0MOSI	WMT_PIN(8, 2)
+#define WMT_PIN_SPI0SS		WMT_PIN(8, 3)
+#define WMT_PIN_SPI1CLK		WMT_PIN(8, 4)
+#define WMT_PIN_SPI1MISO	WMT_PIN(8, 5)
+#define WMT_PIN_SPI1MOSI	WMT_PIN(8, 6)
+#define WMT_PIN_SPI1SS		WMT_PIN(8, 7)
+#define WMT_PIN_SPI2CLK		WMT_PIN(8, 8)
+#define WMT_PIN_SPI2MISO	WMT_PIN(8, 9)
+#define WMT_PIN_SPI2MOSI	WMT_PIN(8, 10)
+#define WMT_PIN_SPI2SS		WMT_PIN(8, 11)
+#define WMT_PIN_UART0_RTS	WMT_PIN(9, 0)
+#define WMT_PIN_UART0_TXD	WMT_PIN(9, 1)
+#define WMT_PIN_UART0_CTS	WMT_PIN(9, 2)
+#define WMT_PIN_UART0_RXD	WMT_PIN(9, 3)
+#define WMT_PIN_UART1_RTS	WMT_PIN(9, 4)
+#define WMT_PIN_UART1_TXD	WMT_PIN(9, 5)
+#define WMT_PIN_UART1_CTS	WMT_PIN(9, 6)
+#define WMT_PIN_UART1_RXD	WMT_PIN(9, 7)
+#define WMT_PIN_UART2_RTS	WMT_PIN(9, 8)
+#define WMT_PIN_UART2_TXD	WMT_PIN(9, 9)
+#define WMT_PIN_UART2_CTS	WMT_PIN(9, 10)
+#define WMT_PIN_UART2_RXD	WMT_PIN(9, 11)
+#define WMT_PIN_UART3_RTS	WMT_PIN(9, 12)
+#define WMT_PIN_UART3_TXD	WMT_PIN(9, 13)
+#define WMT_PIN_UART3_CTS	WMT_PIN(9, 14)
+#define WMT_PIN_UART3_RXD	WMT_PIN(9, 15)
+#define WMT_PIN_I2C0SCL		WMT_PIN(10, 0)
+#define WMT_PIN_I2C0SDA		WMT_PIN(10, 1)
+#define WMT_PIN_I2C1SCL		WMT_PIN(10, 2)
+#define WMT_PIN_I2C1SDA		WMT_PIN(10, 3)
+#define WMT_PIN_I2C2SCL		WMT_PIN(10, 4)
+#define WMT_PIN_I2C2SDA		WMT_PIN(10, 5)
+
+static const struct pinctrl_pin_desc wm8505_pins[] = {
+	PINCTRL_PIN(WMT_PIN_EXTGPIO0, "extgpio0"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO1, "extgpio1"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO2, "extgpio2"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO3, "extgpio3"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO4, "extgpio4"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO5, "extgpio5"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO6, "extgpio6"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO7, "extgpio7"),
+	PINCTRL_PIN(WMT_PIN_WAKEUP0, "wakeup0"),
+	PINCTRL_PIN(WMT_PIN_WAKEUP1, "wakeup1"),
+	PINCTRL_PIN(WMT_PIN_WAKEUP2, "wakeup2"),
+	PINCTRL_PIN(WMT_PIN_WAKEUP3, "wakeup3"),
+	PINCTRL_PIN(WMT_PIN_SUSGPIO0, "susgpio0"),
+	PINCTRL_PIN(WMT_PIN_SDDATA0, "sd_data0"),
+	PINCTRL_PIN(WMT_PIN_SDDATA1, "sd_data1"),
+	PINCTRL_PIN(WMT_PIN_SDDATA2, "sd_data2"),
+	PINCTRL_PIN(WMT_PIN_SDDATA3, "sd_data3"),
+	PINCTRL_PIN(WMT_PIN_MMCDATA0, "mmc_data0"),
+	PINCTRL_PIN(WMT_PIN_MMCDATA1, "mmc_data1"),
+	PINCTRL_PIN(WMT_PIN_MMCDATA2, "mmc_data2"),
+	PINCTRL_PIN(WMT_PIN_MMCDATA3, "mmc_data3"),
+	PINCTRL_PIN(WMT_PIN_VDIN0, "vdin0"),
+	PINCTRL_PIN(WMT_PIN_VDIN1, "vdin1"),
+	PINCTRL_PIN(WMT_PIN_VDIN2, "vdin2"),
+	PINCTRL_PIN(WMT_PIN_VDIN3, "vdin3"),
+	PINCTRL_PIN(WMT_PIN_VDIN4, "vdin4"),
+	PINCTRL_PIN(WMT_PIN_VDIN5, "vdin5"),
+	PINCTRL_PIN(WMT_PIN_VDIN6, "vdin6"),
+	PINCTRL_PIN(WMT_PIN_VDIN7, "vdin7"),
+	PINCTRL_PIN(WMT_PIN_VDOUT0, "vdout0"),
+	PINCTRL_PIN(WMT_PIN_VDOUT1, "vdout1"),
+	PINCTRL_PIN(WMT_PIN_VDOUT2, "vdout2"),
+	PINCTRL_PIN(WMT_PIN_VDOUT3, "vdout3"),
+	PINCTRL_PIN(WMT_PIN_VDOUT4, "vdout4"),
+	PINCTRL_PIN(WMT_PIN_VDOUT5, "vdout5"),
+	PINCTRL_PIN(WMT_PIN_VDOUT6, "vdout6"),
+	PINCTRL_PIN(WMT_PIN_VDOUT7, "vdout7"),
+	PINCTRL_PIN(WMT_PIN_VDOUT8, "vdout8"),
+	PINCTRL_PIN(WMT_PIN_VDOUT9, "vdout9"),
+	PINCTRL_PIN(WMT_PIN_VDOUT10, "vdout10"),
+	PINCTRL_PIN(WMT_PIN_VDOUT11, "vdout11"),
+	PINCTRL_PIN(WMT_PIN_VDOUT12, "vdout12"),
+	PINCTRL_PIN(WMT_PIN_VDOUT13, "vdout13"),
+	PINCTRL_PIN(WMT_PIN_VDOUT14, "vdout14"),
+	PINCTRL_PIN(WMT_PIN_VDOUT15, "vdout15"),
+	PINCTRL_PIN(WMT_PIN_VDOUT16, "vdout16"),
+	PINCTRL_PIN(WMT_PIN_VDOUT17, "vdout17"),
+	PINCTRL_PIN(WMT_PIN_VDOUT18, "vdout18"),
+	PINCTRL_PIN(WMT_PIN_VDOUT19, "vdout19"),
+	PINCTRL_PIN(WMT_PIN_VDOUT20, "vdout20"),
+	PINCTRL_PIN(WMT_PIN_VDOUT21, "vdout21"),
+	PINCTRL_PIN(WMT_PIN_VDOUT22, "vdout22"),
+	PINCTRL_PIN(WMT_PIN_VDOUT23, "vdout23"),
+	PINCTRL_PIN(WMT_PIN_VHSYNC, "v_hsync"),
+	PINCTRL_PIN(WMT_PIN_VVSYNC, "v_vsync"),
+	PINCTRL_PIN(WMT_PIN_VGAHSYNC, "vga_hsync"),
+	PINCTRL_PIN(WMT_PIN_VGAVSYNC, "vga_vsync"),
+	PINCTRL_PIN(WMT_PIN_VDHSYNC, "vd_hsync"),
+	PINCTRL_PIN(WMT_PIN_VDVSYNC, "vd_vsync"),
+	PINCTRL_PIN(WMT_PIN_NORD0, "nor_d0"),
+	PINCTRL_PIN(WMT_PIN_NORD1, "nor_d1"),
+	PINCTRL_PIN(WMT_PIN_NORD2, "nor_d2"),
+	PINCTRL_PIN(WMT_PIN_NORD3, "nor_d3"),
+	PINCTRL_PIN(WMT_PIN_NORD4, "nor_d4"),
+	PINCTRL_PIN(WMT_PIN_NORD5, "nor_d5"),
+	PINCTRL_PIN(WMT_PIN_NORD6, "nor_d6"),
+	PINCTRL_PIN(WMT_PIN_NORD7, "nor_d7"),
+	PINCTRL_PIN(WMT_PIN_NORD8, "nor_d8"),
+	PINCTRL_PIN(WMT_PIN_NORD9, "nor_d9"),
+	PINCTRL_PIN(WMT_PIN_NORD10, "nor_d10"),
+	PINCTRL_PIN(WMT_PIN_NORD11, "nor_d11"),
+	PINCTRL_PIN(WMT_PIN_NORD12, "nor_d12"),
+	PINCTRL_PIN(WMT_PIN_NORD13, "nor_d13"),
+	PINCTRL_PIN(WMT_PIN_NORD14, "nor_d14"),
+	PINCTRL_PIN(WMT_PIN_NORD15, "nor_d15"),
+	PINCTRL_PIN(WMT_PIN_NORA0, "nor_a0"),
+	PINCTRL_PIN(WMT_PIN_NORA1, "nor_a1"),
+	PINCTRL_PIN(WMT_PIN_NORA2, "nor_a2"),
+	PINCTRL_PIN(WMT_PIN_NORA3, "nor_a3"),
+	PINCTRL_PIN(WMT_PIN_NORA4, "nor_a4"),
+	PINCTRL_PIN(WMT_PIN_NORA5, "nor_a5"),
+	PINCTRL_PIN(WMT_PIN_NORA6, "nor_a6"),
+	PINCTRL_PIN(WMT_PIN_NORA7, "nor_a7"),
+	PINCTRL_PIN(WMT_PIN_NORA8, "nor_a8"),
+	PINCTRL_PIN(WMT_PIN_NORA9, "nor_a9"),
+	PINCTRL_PIN(WMT_PIN_NORA10, "nor_a10"),
+	PINCTRL_PIN(WMT_PIN_NORA11, "nor_a11"),
+	PINCTRL_PIN(WMT_PIN_NORA12, "nor_a12"),
+	PINCTRL_PIN(WMT_PIN_NORA13, "nor_a13"),
+	PINCTRL_PIN(WMT_PIN_NORA14, "nor_a14"),
+	PINCTRL_PIN(WMT_PIN_NORA15, "nor_a15"),
+	PINCTRL_PIN(WMT_PIN_NORA16, "nor_a16"),
+	PINCTRL_PIN(WMT_PIN_NORA17, "nor_a17"),
+	PINCTRL_PIN(WMT_PIN_NORA18, "nor_a18"),
+	PINCTRL_PIN(WMT_PIN_NORA19, "nor_a19"),
+	PINCTRL_PIN(WMT_PIN_NORA20, "nor_a20"),
+	PINCTRL_PIN(WMT_PIN_NORA21, "nor_a21"),
+	PINCTRL_PIN(WMT_PIN_NORA22, "nor_a22"),
+	PINCTRL_PIN(WMT_PIN_NORA23, "nor_a23"),
+	PINCTRL_PIN(WMT_PIN_NORA24, "nor_a24"),
+	PINCTRL_PIN(WMT_PIN_AC97SDI, "ac97_sdi"),
+	PINCTRL_PIN(WMT_PIN_AC97SYNC, "ac97_sync"),
+	PINCTRL_PIN(WMT_PIN_AC97SDO, "ac97_sdo"),
+	PINCTRL_PIN(WMT_PIN_AC97BCLK, "ac97_bclk"),
+	PINCTRL_PIN(WMT_PIN_AC97RST, "ac97_rst"),
+	PINCTRL_PIN(WMT_PIN_SFDO, "sf_do"),
+	PINCTRL_PIN(WMT_PIN_SFCS0, "sf_cs0"),
+	PINCTRL_PIN(WMT_PIN_SFCS1, "sf_cs1"),
+	PINCTRL_PIN(WMT_PIN_SFCLK, "sf_clk"),
+	PINCTRL_PIN(WMT_PIN_SFDI, "sf_di"),
+	PINCTRL_PIN(WMT_PIN_SPI0CLK, "spi0_clk"),
+	PINCTRL_PIN(WMT_PIN_SPI0MISO, "spi0_miso"),
+	PINCTRL_PIN(WMT_PIN_SPI0MOSI, "spi0_mosi"),
+	PINCTRL_PIN(WMT_PIN_SPI0SS, "spi0_ss"),
+	PINCTRL_PIN(WMT_PIN_SPI1CLK, "spi1_clk"),
+	PINCTRL_PIN(WMT_PIN_SPI1MISO, "spi1_miso"),
+	PINCTRL_PIN(WMT_PIN_SPI1MOSI, "spi1_mosi"),
+	PINCTRL_PIN(WMT_PIN_SPI1SS, "spi1_ss"),
+	PINCTRL_PIN(WMT_PIN_SPI2CLK, "spi2_clk"),
+	PINCTRL_PIN(WMT_PIN_SPI2MISO, "spi2_miso"),
+	PINCTRL_PIN(WMT_PIN_SPI2MOSI, "spi2_mosi"),
+	PINCTRL_PIN(WMT_PIN_SPI2SS, "spi2_ss"),
+	PINCTRL_PIN(WMT_PIN_UART0_RTS, "uart0_rts"),
+	PINCTRL_PIN(WMT_PIN_UART0_TXD, "uart0_txd"),
+	PINCTRL_PIN(WMT_PIN_UART0_CTS, "uart0_cts"),
+	PINCTRL_PIN(WMT_PIN_UART0_RXD, "uart0_rxd"),
+	PINCTRL_PIN(WMT_PIN_UART1_RTS, "uart1_rts"),
+	PINCTRL_PIN(WMT_PIN_UART1_TXD, "uart1_txd"),
+	PINCTRL_PIN(WMT_PIN_UART1_CTS, "uart1_cts"),
+	PINCTRL_PIN(WMT_PIN_UART1_RXD, "uart1_rxd"),
+	PINCTRL_PIN(WMT_PIN_UART2_RTS, "uart2_rts"),
+	PINCTRL_PIN(WMT_PIN_UART2_TXD, "uart2_txd"),
+	PINCTRL_PIN(WMT_PIN_UART2_CTS, "uart2_cts"),
+	PINCTRL_PIN(WMT_PIN_UART2_RXD, "uart2_rxd"),
+	PINCTRL_PIN(WMT_PIN_UART3_RTS, "uart3_rts"),
+	PINCTRL_PIN(WMT_PIN_UART3_TXD, "uart3_txd"),
+	PINCTRL_PIN(WMT_PIN_UART3_CTS, "uart3_cts"),
+	PINCTRL_PIN(WMT_PIN_UART3_RXD, "uart3_rxd"),
+	PINCTRL_PIN(WMT_PIN_I2C0SCL, "i2c0_scl"),
+	PINCTRL_PIN(WMT_PIN_I2C0SDA, "i2c0_sda"),
+	PINCTRL_PIN(WMT_PIN_I2C1SCL, "i2c1_scl"),
+	PINCTRL_PIN(WMT_PIN_I2C1SDA, "i2c1_sda"),
+	PINCTRL_PIN(WMT_PIN_I2C2SCL, "i2c2_scl"),
+	PINCTRL_PIN(WMT_PIN_I2C2SDA, "i2c2_sda"),
+};
+
+/* Order of these names must match the above list */
+static const char * const wm8505_groups[] = {
+	"extgpio0",
+	"extgpio1",
+	"extgpio2",
+	"extgpio3",
+	"extgpio4",
+	"extgpio5",
+	"extgpio6",
+	"extgpio7",
+	"wakeup0",
+	"wakeup1",
+	"wakeup2",
+	"wakeup3",
+	"susgpio0",
+	"sd_data0",
+	"sd_data1",
+	"sd_data2",
+	"sd_data3",
+	"mmc_data0",
+	"mmc_data1",
+	"mmc_data2",
+	"mmc_data3",
+	"vdin0",
+	"vdin1",
+	"vdin2",
+	"vdin3",
+	"vdin4",
+	"vdin5",
+	"vdin6",
+	"vdin7",
+	"vdout0",
+	"vdout1",
+	"vdout2",
+	"vdout3",
+	"vdout4",
+	"vdout5",
+	"vdout6",
+	"vdout7",
+	"vdout8",
+	"vdout9",
+	"vdout10",
+	"vdout11",
+	"vdout12",
+	"vdout13",
+	"vdout14",
+	"vdout15",
+	"vdout16",
+	"vdout17",
+	"vdout18",
+	"vdout19",
+	"vdout20",
+	"vdout21",
+	"vdout22",
+	"vdout23",
+	"v_hsync",
+	"v_vsync",
+	"vga_hsync",
+	"vga_vsync",
+	"vd_hsync",
+	"vd_vsync",
+	"nor_d0",
+	"nor_d1",
+	"nor_d2",
+	"nor_d3",
+	"nor_d4",
+	"nor_d5",
+	"nor_d6",
+	"nor_d7",
+	"nor_d8",
+	"nor_d9",
+	"nor_d10",
+	"nor_d11",
+	"nor_d12",
+	"nor_d13",
+	"nor_d14",
+	"nor_d15",
+	"nor_a0",
+	"nor_a1",
+	"nor_a2",
+	"nor_a3",
+	"nor_a4",
+	"nor_a5",
+	"nor_a6",
+	"nor_a7",
+	"nor_a8",
+	"nor_a9",
+	"nor_a10",
+	"nor_a11",
+	"nor_a12",
+	"nor_a13",
+	"nor_a14",
+	"nor_a15",
+	"nor_a16",
+	"nor_a17",
+	"nor_a18",
+	"nor_a19",
+	"nor_a20",
+	"nor_a21",
+	"nor_a22",
+	"nor_a23",
+	"nor_a24",
+	"ac97_sdi",
+	"ac97_sync",
+	"ac97_sdo",
+	"ac97_bclk",
+	"ac97_rst",
+	"sf_do",
+	"sf_cs0",
+	"sf_cs1",
+	"sf_clk",
+	"sf_di",
+	"spi0_clk",
+	"spi0_miso",
+	"spi0_mosi",
+	"spi0_ss",
+	"spi1_clk",
+	"spi1_miso",
+	"spi1_mosi",
+	"spi1_ss",
+	"spi2_clk",
+	"spi2_miso",
+	"spi2_mosi",
+	"spi2_ss",
+	"uart0_rts",
+	"uart0_txd",
+	"uart0_cts",
+	"uart0_rxd",
+	"uart1_rts",
+	"uart1_txd",
+	"uart1_cts",
+	"uart1_rxd",
+	"uart2_rts",
+	"uart2_txd",
+	"uart2_cts",
+	"uart2_rxd",
+	"uart3_rts",
+	"uart3_txd",
+	"uart3_cts",
+	"uart3_rxd",
+	"i2c0_scl",
+	"i2c0_sda",
+	"i2c1_scl",
+	"i2c1_sda",
+	"i2c2_scl",
+	"i2c2_sda",
+};
+
+static int wm8505_pinctrl_probe(struct platform_device *pdev)
+{
+	struct wmt_pinctrl_data *data;
+
+	data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
+	if (!data) {
+		dev_err(&pdev->dev, "failed to allocate data\n");
+		return -ENOMEM;
+	}
+
+	data->banks = wm8505_banks;
+	data->nbanks = ARRAY_SIZE(wm8505_banks);
+	data->pins = wm8505_pins;
+	data->npins = ARRAY_SIZE(wm8505_pins);
+	data->groups = wm8505_groups;
+	data->ngroups = ARRAY_SIZE(wm8505_groups);
+
+	return wmt_pinctrl_probe(pdev, data);
+}
+
+static int wm8505_pinctrl_remove(struct platform_device *pdev)
+{
+	return wmt_pinctrl_remove(pdev);
+}
+
+static struct of_device_id wmt_pinctrl_of_match[] = {
+	{ .compatible = "wm,wm8505-pinctrl" },
+	{ /* sentinel */ },
+};
+
+static struct platform_driver wmt_pinctrl_driver = {
+	.probe	= wm8505_pinctrl_probe,
+	.remove	= wm8505_pinctrl_remove,
+	.driver = {
+		.name	= "pinctrl-wm8505",
+		.owner	= THIS_MODULE,
+		.of_match_table	= wmt_pinctrl_of_match,
+	},
+};
+
+module_platform_driver(wmt_pinctrl_driver);
+
+MODULE_AUTHOR("Tony Prisk <linux at prisktech.co.nz>");
+MODULE_DESCRIPTION("Wondermedia WM8505 Pincontrol driver");
+MODULE_LICENSE("GPL v2");
+MODULE_DEVICE_TABLE(of, wmt_pinctrl_of_match);
diff --git a/drivers/pinctrl/vt8500/pinctrl-wm8650.c b/drivers/pinctrl/vt8500/pinctrl-wm8650.c
new file mode 100644
index 0000000..7de57f0
--- /dev/null
+++ b/drivers/pinctrl/vt8500/pinctrl-wm8650.c
@@ -0,0 +1,370 @@
+/*
+ * Pinctrl data for Wondermedia WM8650 SoC
+ *
+ * Copyright (c) 2013 Tony Prisk <linux at prisktech.co.nz>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ */
+
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/pinctrl/pinctrl.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+
+#include "pinctrl-wmt.h"
+
+/*
+ * Describe the register offsets within the GPIO memory space
+ * The dedicated external GPIO's should always be listed in bank 0
+ * so they are exported in the 0..31 range which is what users
+ * expect.
+ *
+ * Do not reorder these banks as it will change the pin numbering
+ */
+static const struct wmt_pinctrl_bank_registers wm8650_banks[] = {
+	WMT_PINCTRL_BANK(0x40, 0x80, 0xC0, 0x00, 0x480, 0x4C0),		/* 0 */
+	WMT_PINCTRL_BANK(0x44, 0x84, 0xC4, 0x04, 0x484, 0x4C4),		/* 1 */
+	WMT_PINCTRL_BANK(0x48, 0x88, 0xC8, 0x08, 0x488, 0x4C8),		/* 2 */
+	WMT_PINCTRL_BANK(0x4C, 0x8C, 0xCC, 0x0C, 0x48C, 0x4CC),		/* 3 */
+	WMT_PINCTRL_BANK(0x50, 0x90, 0xD0, 0x10, 0x490, 0x4D0),		/* 4 */
+	WMT_PINCTRL_BANK(0x54, 0x94, 0xD4, 0x14, 0x494, 0x4D4),		/* 5 */
+	WMT_PINCTRL_BANK(0x58, 0x98, 0xD8, 0x18, 0x498, 0x4D8),		/* 6 */
+	WMT_PINCTRL_BANK(0x5C, 0x9C, 0xDC, 0x1C, 0x49C, 0x4DC),		/* 7 */
+};
+
+/* Please keep sorted by bank/bit */
+#define WMT_PIN_EXTGPIO0	WMT_PIN(0, 0)
+#define WMT_PIN_EXTGPIO1	WMT_PIN(0, 1)
+#define WMT_PIN_EXTGPIO2	WMT_PIN(0, 2)
+#define WMT_PIN_EXTGPIO3	WMT_PIN(0, 3)
+#define WMT_PIN_EXTGPIO4	WMT_PIN(0, 4)
+#define WMT_PIN_EXTGPIO5	WMT_PIN(0, 5)
+#define WMT_PIN_EXTGPIO6	WMT_PIN(0, 6)
+#define WMT_PIN_EXTGPIO7	WMT_PIN(0, 7)
+#define WMT_PIN_WAKEUP0		WMT_PIN(0, 16)
+#define WMT_PIN_WAKEUP1		WMT_PIN(0, 17)
+#define WMT_PIN_SUSGPIO0	WMT_PIN(0, 21)
+#define WMT_PIN_SD0CD		WMT_PIN(0, 28)
+#define WMT_PIN_SD1CD		WMT_PIN(0, 29)
+#define WMT_PIN_VDOUT0		WMT_PIN(1, 0)
+#define WMT_PIN_VDOUT1		WMT_PIN(1, 1)
+#define WMT_PIN_VDOUT2		WMT_PIN(1, 2)
+#define WMT_PIN_VDOUT3		WMT_PIN(1, 3)
+#define WMT_PIN_VDOUT4		WMT_PIN(1, 4)
+#define WMT_PIN_VDOUT5		WMT_PIN(1, 5)
+#define WMT_PIN_VDOUT6		WMT_PIN(1, 6)
+#define WMT_PIN_VDOUT7		WMT_PIN(1, 7)
+#define WMT_PIN_VDOUT8		WMT_PIN(1, 8)
+#define WMT_PIN_VDOUT9		WMT_PIN(1, 9)
+#define WMT_PIN_VDOUT10		WMT_PIN(1, 10)
+#define WMT_PIN_VDOUT11		WMT_PIN(1, 11)
+#define WMT_PIN_VDOUT12		WMT_PIN(1, 12)
+#define WMT_PIN_VDOUT13		WMT_PIN(1, 13)
+#define WMT_PIN_VDOUT14		WMT_PIN(1, 14)
+#define WMT_PIN_VDOUT15		WMT_PIN(1, 15)
+#define WMT_PIN_VDOUT16		WMT_PIN(1, 16)
+#define WMT_PIN_VDOUT17		WMT_PIN(1, 17)
+#define WMT_PIN_VDOUT18		WMT_PIN(1, 18)
+#define WMT_PIN_VDOUT19		WMT_PIN(1, 19)
+#define WMT_PIN_VDOUT20		WMT_PIN(1, 20)
+#define WMT_PIN_VDOUT21		WMT_PIN(1, 21)
+#define WMT_PIN_VDOUT22		WMT_PIN(1, 22)
+#define WMT_PIN_VDOUT23		WMT_PIN(1, 23)
+#define WMT_PIN_VDIN0		WMT_PIN(2, 0)
+#define WMT_PIN_VDIN1		WMT_PIN(2, 1)
+#define WMT_PIN_VDIN2		WMT_PIN(2, 2)
+#define WMT_PIN_VDIN3		WMT_PIN(2, 3)
+#define WMT_PIN_VDIN4		WMT_PIN(2, 4)
+#define WMT_PIN_VDIN5		WMT_PIN(2, 5)
+#define WMT_PIN_VDIN6		WMT_PIN(2, 6)
+#define WMT_PIN_VDIN7		WMT_PIN(2, 7)
+#define WMT_PIN_I2C1SCL		WMT_PIN(2, 12)
+#define WMT_PIN_I2C1SDA		WMT_PIN(2, 13)
+#define WMT_PIN_SPI0MOSI	WMT_PIN(2, 24)
+#define WMT_PIN_SPI0MISO	WMT_PIN(2, 25)
+#define WMT_PIN_SPI0SS0		WMT_PIN(2, 26)
+#define WMT_PIN_SPI0CLK		WMT_PIN(2, 27)
+#define WMT_PIN_SD0DATA0	WMT_PIN(3, 8)
+#define WMT_PIN_SD0DATA1	WMT_PIN(3, 9)
+#define WMT_PIN_SD0DATA2	WMT_PIN(3, 10)
+#define WMT_PIN_SD0DATA3	WMT_PIN(3, 11)
+#define WMT_PIN_SD0CLK		WMT_PIN(3, 12)
+#define WMT_PIN_SD0WP		WMT_PIN(3, 13)
+#define WMT_PIN_SD0CMD		WMT_PIN(3, 14)
+#define WMT_PIN_SD1DATA0	WMT_PIN(3, 24)
+#define WMT_PIN_SD1DATA1	WMT_PIN(3, 25)
+#define WMT_PIN_SD1DATA2	WMT_PIN(3, 26)
+#define WMT_PIN_SD1DATA3	WMT_PIN(3, 27)
+#define WMT_PIN_SD1DATA4	WMT_PIN(3, 28)
+#define WMT_PIN_SD1DATA5	WMT_PIN(3, 29)
+#define WMT_PIN_SD1DATA6	WMT_PIN(3, 30)
+#define WMT_PIN_SD1DATA7	WMT_PIN(3, 31)
+#define WMT_PIN_I2C0SCL		WMT_PIN(5, 8)
+#define WMT_PIN_I2C0SDA		WMT_PIN(5, 9)
+#define WMT_PIN_UART0RTS	WMT_PIN(5, 16)
+#define WMT_PIN_UART0TXD	WMT_PIN(5, 17)
+#define WMT_PIN_UART0CTS	WMT_PIN(5, 18)
+#define WMT_PIN_UART0RXD	WMT_PIN(5, 19)
+#define WMT_PIN_UART1RTS	WMT_PIN(5, 20)
+#define WMT_PIN_UART1TXD	WMT_PIN(5, 21)
+#define WMT_PIN_UART1CTS	WMT_PIN(5, 22)
+#define WMT_PIN_UART1RXD	WMT_PIN(5, 23)
+#define WMT_PIN_UART2RTS	WMT_PIN(5, 24)
+#define WMT_PIN_UART2TXD	WMT_PIN(5, 25)
+#define WMT_PIN_UART2CTS	WMT_PIN(5, 26)
+#define WMT_PIN_UART2RXD	WMT_PIN(5, 27)
+#define WMT_PIN_UART3RTS	WMT_PIN(5, 28)
+#define WMT_PIN_UART3TXD	WMT_PIN(5, 29)
+#define WMT_PIN_UART3CTS	WMT_PIN(5, 30)
+#define WMT_PIN_UART3RXD	WMT_PIN(5, 31)
+#define WMT_PIN_KPADROW0	WMT_PIN(6, 16)
+#define WMT_PIN_KPADROW1	WMT_PIN(6, 17)
+#define WMT_PIN_KPADCOL0	WMT_PIN(6, 18)
+#define WMT_PIN_KPADCOL1	WMT_PIN(6, 19)
+#define WMT_PIN_SD1CLK		WMT_PIN(7, 0)
+#define WMT_PIN_SD1CMD		WMT_PIN(7, 1)
+#define WMT_PIN_SD1WP		WMT_PIN(7, 13)
+
+static const struct pinctrl_pin_desc wm8650_pins[] = {
+	PINCTRL_PIN(WMT_PIN_EXTGPIO0, "extgpio0"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO1, "extgpio1"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO2, "extgpio2"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO3, "extgpio3"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO4, "extgpio4"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO5, "extgpio5"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO6, "extgpio6"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO7, "extgpio7"),
+	PINCTRL_PIN(WMT_PIN_WAKEUP0, "wakeup0"),
+	PINCTRL_PIN(WMT_PIN_WAKEUP1, "wakeup1"),
+	PINCTRL_PIN(WMT_PIN_SUSGPIO0, "susgpio0"),
+	PINCTRL_PIN(WMT_PIN_SD0CD, "sd0_cd"),
+	PINCTRL_PIN(WMT_PIN_SD1CD, "sd1_cd"),
+	PINCTRL_PIN(WMT_PIN_VDOUT0, "vdout0"),
+	PINCTRL_PIN(WMT_PIN_VDOUT1, "vdout1"),
+	PINCTRL_PIN(WMT_PIN_VDOUT2, "vdout2"),
+	PINCTRL_PIN(WMT_PIN_VDOUT3, "vdout3"),
+	PINCTRL_PIN(WMT_PIN_VDOUT4, "vdout4"),
+	PINCTRL_PIN(WMT_PIN_VDOUT5, "vdout5"),
+	PINCTRL_PIN(WMT_PIN_VDOUT6, "vdout6"),
+	PINCTRL_PIN(WMT_PIN_VDOUT7, "vdout7"),
+	PINCTRL_PIN(WMT_PIN_VDOUT8, "vdout8"),
+	PINCTRL_PIN(WMT_PIN_VDOUT9, "vdout9"),
+	PINCTRL_PIN(WMT_PIN_VDOUT10, "vdout10"),
+	PINCTRL_PIN(WMT_PIN_VDOUT11, "vdout11"),
+	PINCTRL_PIN(WMT_PIN_VDOUT12, "vdout12"),
+	PINCTRL_PIN(WMT_PIN_VDOUT13, "vdout13"),
+	PINCTRL_PIN(WMT_PIN_VDOUT14, "vdout14"),
+	PINCTRL_PIN(WMT_PIN_VDOUT15, "vdout15"),
+	PINCTRL_PIN(WMT_PIN_VDOUT16, "vdout16"),
+	PINCTRL_PIN(WMT_PIN_VDOUT17, "vdout17"),
+	PINCTRL_PIN(WMT_PIN_VDOUT18, "vdout18"),
+	PINCTRL_PIN(WMT_PIN_VDOUT19, "vdout19"),
+	PINCTRL_PIN(WMT_PIN_VDOUT20, "vdout20"),
+	PINCTRL_PIN(WMT_PIN_VDOUT21, "vdout21"),
+	PINCTRL_PIN(WMT_PIN_VDOUT22, "vdout22"),
+	PINCTRL_PIN(WMT_PIN_VDOUT23, "vdout23"),
+	PINCTRL_PIN(WMT_PIN_VDIN0, "vdin0"),
+	PINCTRL_PIN(WMT_PIN_VDIN1, "vdin1"),
+	PINCTRL_PIN(WMT_PIN_VDIN2, "vdin2"),
+	PINCTRL_PIN(WMT_PIN_VDIN3, "vdin3"),
+	PINCTRL_PIN(WMT_PIN_VDIN4, "vdin4"),
+	PINCTRL_PIN(WMT_PIN_VDIN5, "vdin5"),
+	PINCTRL_PIN(WMT_PIN_VDIN6, "vdin6"),
+	PINCTRL_PIN(WMT_PIN_VDIN7, "vdin7"),
+	PINCTRL_PIN(WMT_PIN_I2C1SCL, "i2c1_scl"),
+	PINCTRL_PIN(WMT_PIN_I2C1SDA, "i2c1_sda"),
+	PINCTRL_PIN(WMT_PIN_SPI0MOSI, "spi0_mosi"),
+	PINCTRL_PIN(WMT_PIN_SPI0MISO, "spi0_miso"),
+	PINCTRL_PIN(WMT_PIN_SPI0SS0, "spi0_ss0"),
+	PINCTRL_PIN(WMT_PIN_SPI0CLK, "spi0_clk"),
+	PINCTRL_PIN(WMT_PIN_SD0DATA0, "sd0_data0"),
+	PINCTRL_PIN(WMT_PIN_SD0DATA1, "sd0_data1"),
+	PINCTRL_PIN(WMT_PIN_SD0DATA2, "sd0_data2"),
+	PINCTRL_PIN(WMT_PIN_SD0DATA3, "sd0_data3"),
+	PINCTRL_PIN(WMT_PIN_SD0CLK, "sd0_clk"),
+	PINCTRL_PIN(WMT_PIN_SD0WP, "sd0_wp"),
+	PINCTRL_PIN(WMT_PIN_SD0CMD, "sd0_cmd"),
+	PINCTRL_PIN(WMT_PIN_SD1DATA0, "sd1_data0"),
+	PINCTRL_PIN(WMT_PIN_SD1DATA1, "sd1_data1"),
+	PINCTRL_PIN(WMT_PIN_SD1DATA2, "sd1_data2"),
+	PINCTRL_PIN(WMT_PIN_SD1DATA3, "sd1_data3"),
+	PINCTRL_PIN(WMT_PIN_SD1DATA4, "sd1_data4"),
+	PINCTRL_PIN(WMT_PIN_SD1DATA5, "sd1_data5"),
+	PINCTRL_PIN(WMT_PIN_SD1DATA6, "sd1_data6"),
+	PINCTRL_PIN(WMT_PIN_SD1DATA7, "sd1_data7"),
+	PINCTRL_PIN(WMT_PIN_I2C0SCL, "i2c0_scl"),
+	PINCTRL_PIN(WMT_PIN_I2C0SDA, "i2c0_sda"),
+	PINCTRL_PIN(WMT_PIN_UART0RTS, "uart0_rts"),
+	PINCTRL_PIN(WMT_PIN_UART0TXD, "uart0_txd"),
+	PINCTRL_PIN(WMT_PIN_UART0CTS, "uart0_cts"),
+	PINCTRL_PIN(WMT_PIN_UART0RXD, "uart0_rxd"),
+	PINCTRL_PIN(WMT_PIN_UART1RTS, "uart1_rts"),
+	PINCTRL_PIN(WMT_PIN_UART1TXD, "uart1_txd"),
+	PINCTRL_PIN(WMT_PIN_UART1CTS, "uart1_cts"),
+	PINCTRL_PIN(WMT_PIN_UART1RXD, "uart1_rxd"),
+	PINCTRL_PIN(WMT_PIN_UART2RTS, "uart2_rts"),
+	PINCTRL_PIN(WMT_PIN_UART2TXD, "uart2_txd"),
+	PINCTRL_PIN(WMT_PIN_UART2CTS, "uart2_cts"),
+	PINCTRL_PIN(WMT_PIN_UART2RXD, "uart2_rxd"),
+	PINCTRL_PIN(WMT_PIN_UART3RTS, "uart3_rts"),
+	PINCTRL_PIN(WMT_PIN_UART3TXD, "uart3_txd"),
+	PINCTRL_PIN(WMT_PIN_UART3CTS, "uart3_cts"),
+	PINCTRL_PIN(WMT_PIN_UART3RXD, "uart3_rxd"),
+	PINCTRL_PIN(WMT_PIN_KPADROW0, "kpadrow0"),
+	PINCTRL_PIN(WMT_PIN_KPADROW1, "kpadrow1"),
+	PINCTRL_PIN(WMT_PIN_KPADCOL0, "kpadcol0"),
+	PINCTRL_PIN(WMT_PIN_KPADCOL1, "kpadcol1"),
+	PINCTRL_PIN(WMT_PIN_SD1CLK, "sd1_clk"),
+	PINCTRL_PIN(WMT_PIN_SD1CMD, "sd1_cmd"),
+	PINCTRL_PIN(WMT_PIN_SD1WP, "sd1_wp"),
+};
+
+/* Order of these names must match the above list */
+static const char * const wm8650_groups[] = {
+	"extgpio0",
+	"extgpio1",
+	"extgpio2",
+	"extgpio3",
+	"extgpio4",
+	"extgpio5",
+	"extgpio6",
+	"extgpio7",
+	"wakeup0",
+	"wakeup1",
+	"susgpio0",
+	"sd0_cd",
+	"sd1_cd",
+	"vdout0",
+	"vdout1",
+	"vdout2",
+	"vdout3",
+	"vdout4",
+	"vdout5",
+	"vdout6",
+	"vdout7",
+	"vdout8",
+	"vdout9",
+	"vdout10",
+	"vdout11",
+	"vdout12",
+	"vdout13",
+	"vdout14",
+	"vdout15",
+	"vdout16",
+	"vdout17",
+	"vdout18",
+	"vdout19",
+	"vdout20",
+	"vdout21",
+	"vdout22",
+	"vdout23",
+	"vdin0",
+	"vdin1",
+	"vdin2",
+	"vdin3",
+	"vdin4",
+	"vdin5",
+	"vdin6",
+	"vdin7",
+	"i2c1_scl",
+	"i2c1_sda",
+	"spi0_mosi",
+	"spi0_miso",
+	"spi0_ss0",
+	"spi0_clk",
+	"sd0_data0",
+	"sd0_data1",
+	"sd0_data2",
+	"sd0_data3",
+	"sd0_clk",
+	"sd0_wp",
+	"sd0_cmd",
+	"sd1_data0",
+	"sd1_data1",
+	"sd1_data2",
+	"sd1_data3",
+	"sd1_data4",
+	"sd1_data5",
+	"sd1_data6",
+	"sd1_data7",
+	"i2c0_scl",
+	"i2c0_sda",
+	"uart0_rts",
+	"uart0_txd",
+	"uart0_cts",
+	"uart0_rxd",
+	"uart1_rts",
+	"uart1_txd",
+	"uart1_cts",
+	"uart1_rxd",
+	"uart2_rts",
+	"uart2_txd",
+	"uart2_cts",
+	"uart2_rxd",
+	"uart3_rts",
+	"uart3_txd",
+	"uart3_cts",
+	"uart3_rxd",
+	"kpadrow0",
+	"kpadrow1",
+	"kpadcol0",
+	"kpadcol1",
+	"sd1_clk",
+	"sd1_cmd",
+	"sd1_wp",
+};
+
+static int wm8650_pinctrl_probe(struct platform_device *pdev)
+{
+	struct wmt_pinctrl_data *data;
+
+	data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
+	if (!data) {
+		dev_err(&pdev->dev, "failed to allocate data\n");
+		return -ENOMEM;
+	}
+
+	data->banks = wm8650_banks;
+	data->nbanks = ARRAY_SIZE(wm8650_banks);
+	data->pins = wm8650_pins;
+	data->npins = ARRAY_SIZE(wm8650_pins);
+	data->groups = wm8650_groups;
+	data->ngroups = ARRAY_SIZE(wm8650_groups);
+
+	return wmt_pinctrl_probe(pdev, data);
+}
+
+static int wm8650_pinctrl_remove(struct platform_device *pdev)
+{
+	return wmt_pinctrl_remove(pdev);
+}
+
+static struct of_device_id wmt_pinctrl_of_match[] = {
+	{ .compatible = "wm,wm8650-pinctrl" },
+	{ /* sentinel */ },
+};
+
+static struct platform_driver wmt_pinctrl_driver = {
+	.probe	= wm8650_pinctrl_probe,
+	.remove	= wm8650_pinctrl_remove,
+	.driver = {
+		.name	= "pinctrl-wm8650",
+		.owner	= THIS_MODULE,
+		.of_match_table	= wmt_pinctrl_of_match,
+	},
+};
+
+module_platform_driver(wmt_pinctrl_driver);
+
+MODULE_AUTHOR("Tony Prisk <linux at prisktech.co.nz>");
+MODULE_DESCRIPTION("Wondermedia WM8650 Pincontrol driver");
+MODULE_LICENSE("GPL v2");
+MODULE_DEVICE_TABLE(of, wmt_pinctrl_of_match);
diff --git a/drivers/pinctrl/vt8500/pinctrl-wm8750.c b/drivers/pinctrl/vt8500/pinctrl-wm8750.c
new file mode 100644
index 0000000..b964cc5
--- /dev/null
+++ b/drivers/pinctrl/vt8500/pinctrl-wm8750.c
@@ -0,0 +1,409 @@
+/*
+ * Pinctrl data for Wondermedia WM8750 SoC
+ *
+ * Copyright (c) 2013 Tony Prisk <linux at prisktech.co.nz>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ */
+
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/pinctrl/pinctrl.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+
+#include "pinctrl-wmt.h"
+
+/*
+ * Describe the register offsets within the GPIO memory space
+ * The dedicated external GPIO's should always be listed in bank 0
+ * so they are exported in the 0..31 range which is what users
+ * expect.
+ *
+ * Do not reorder these banks as it will change the pin numbering
+ */
+static const struct wmt_pinctrl_bank_registers wm8750_banks[] = {
+	WMT_PINCTRL_BANK(0x40, 0x80, 0xC0, 0x00, 0x480, 0x4C0),	/* 0 */
+	WMT_PINCTRL_BANK(0x44, 0x84, 0xC4, 0x04, 0x484, 0x4C4),	/* 1 */
+	WMT_PINCTRL_BANK(0x48, 0x88, 0xC8, 0x08, 0x488, 0x4C8),	/* 2 */
+	WMT_PINCTRL_BANK(0x4C, 0x8C, 0xCC, 0x0C, 0x48C, 0x4CC),	/* 3 */
+	WMT_PINCTRL_BANK(0x50, 0x90, 0xD0, 0x10, 0x490, 0x4D0),	/* 4 */
+	WMT_PINCTRL_BANK(0x54, 0x94, 0xD4, 0x14, 0x494, 0x4D4),	/* 5 */
+	WMT_PINCTRL_BANK(0x58, 0x98, 0xD8, 0x18, 0x498, 0x4D8),	/* 6 */
+	WMT_PINCTRL_BANK(0x5C, 0x9C, 0xDC, 0x1C, 0x49C, 0x4DC),	/* 7 */
+	WMT_PINCTRL_BANK(0x60, 0xA0, 0xE0, 0x20, 0x4A0, 0x4E0),	/* 8 */
+	WMT_PINCTRL_BANK(0x70, 0xB0, 0xF0, 0x30, 0x4B0, 0x4F0),	/* 9 */
+	WMT_PINCTRL_BANK(0x7C, 0xBC, 0xDC, 0x3C, 0x4BC, 0x4FC),	/* 10 */
+};
+
+/* Please keep sorted by bank/bit */
+#define WMT_PIN_EXTGPIO0	WMT_PIN(0, 0)
+#define WMT_PIN_EXTGPIO1	WMT_PIN(0, 1)
+#define WMT_PIN_EXTGPIO2	WMT_PIN(0, 2)
+#define WMT_PIN_EXTGPIO3	WMT_PIN(0, 3)
+#define WMT_PIN_EXTGPIO4	WMT_PIN(0, 4)
+#define WMT_PIN_EXTGPIO5	WMT_PIN(0, 5)
+#define WMT_PIN_EXTGPIO6	WMT_PIN(0, 6)
+#define WMT_PIN_EXTGPIO7	WMT_PIN(0, 7)
+#define WMT_PIN_WAKEUP0		WMT_PIN(0, 16)
+#define WMT_PIN_WAKEUP1		WMT_PIN(0, 16)
+#define WMT_PIN_SD0CD		WMT_PIN(0, 28)
+#define WMT_PIN_VDOUT0		WMT_PIN(1, 0)
+#define WMT_PIN_VDOUT1		WMT_PIN(1, 1)
+#define WMT_PIN_VDOUT2		WMT_PIN(1, 2)
+#define WMT_PIN_VDOUT3		WMT_PIN(1, 3)
+#define WMT_PIN_VDOUT4		WMT_PIN(1, 4)
+#define WMT_PIN_VDOUT5		WMT_PIN(1, 5)
+#define WMT_PIN_VDOUT6		WMT_PIN(1, 6)
+#define WMT_PIN_VDOUT7		WMT_PIN(1, 7)
+#define WMT_PIN_VDOUT8		WMT_PIN(1, 8)
+#define WMT_PIN_VDOUT9		WMT_PIN(1, 9)
+#define WMT_PIN_VDOUT10		WMT_PIN(1, 10)
+#define WMT_PIN_VDOUT11		WMT_PIN(1, 11)
+#define WMT_PIN_VDOUT12		WMT_PIN(1, 12)
+#define WMT_PIN_VDOUT13		WMT_PIN(1, 13)
+#define WMT_PIN_VDOUT14		WMT_PIN(1, 14)
+#define WMT_PIN_VDOUT15		WMT_PIN(1, 15)
+#define WMT_PIN_VDOUT16		WMT_PIN(1, 16)
+#define WMT_PIN_VDOUT17		WMT_PIN(1, 17)
+#define WMT_PIN_VDOUT18		WMT_PIN(1, 18)
+#define WMT_PIN_VDOUT19		WMT_PIN(1, 19)
+#define WMT_PIN_VDOUT20		WMT_PIN(1, 20)
+#define WMT_PIN_VDOUT21		WMT_PIN(1, 21)
+#define WMT_PIN_VDOUT22		WMT_PIN(1, 22)
+#define WMT_PIN_VDOUT23		WMT_PIN(1, 23)
+#define WMT_PIN_VDIN0		WMT_PIN(2, 0)
+#define WMT_PIN_VDIN1		WMT_PIN(2, 1)
+#define WMT_PIN_VDIN2		WMT_PIN(2, 2)
+#define WMT_PIN_VDIN3		WMT_PIN(2, 3)
+#define WMT_PIN_VDIN4		WMT_PIN(2, 4)
+#define WMT_PIN_VDIN5		WMT_PIN(2, 5)
+#define WMT_PIN_VDIN6		WMT_PIN(2, 6)
+#define WMT_PIN_VDIN7		WMT_PIN(2, 7)
+#define WMT_PIN_SPI0_MOSI	WMT_PIN(2, 24)
+#define WMT_PIN_SPI0_MISO	WMT_PIN(2, 25)
+#define WMT_PIN_SPI0_SS		WMT_PIN(2, 26)
+#define WMT_PIN_SPI0_CLK	WMT_PIN(2, 27)
+#define WMT_PIN_SPI0_SSB	WMT_PIN(2, 28)
+#define WMT_PIN_SD0CLK		WMT_PIN(3, 17)
+#define WMT_PIN_SD0CMD		WMT_PIN(3, 18)
+#define WMT_PIN_SD0WP		WMT_PIN(3, 19)
+#define WMT_PIN_SD0DATA0	WMT_PIN(3, 20)
+#define WMT_PIN_SD0DATA1	WMT_PIN(3, 21)
+#define WMT_PIN_SD0DATA2	WMT_PIN(3, 22)
+#define WMT_PIN_SD0DATA3	WMT_PIN(3, 23)
+#define WMT_PIN_SD1DATA0	WMT_PIN(3, 24)
+#define WMT_PIN_SD1DATA1	WMT_PIN(3, 25)
+#define WMT_PIN_SD1DATA2	WMT_PIN(3, 26)
+#define WMT_PIN_SD1DATA3	WMT_PIN(3, 27)
+#define WMT_PIN_SD1DATA4	WMT_PIN(3, 28)
+#define WMT_PIN_SD1DATA5	WMT_PIN(3, 29)
+#define WMT_PIN_SD1DATA6	WMT_PIN(3, 30)
+#define WMT_PIN_SD1DATA7	WMT_PIN(3, 31)
+#define WMT_PIN_I2C0_SCL	WMT_PIN(5, 8)
+#define WMT_PIN_I2C0_SDA	WMT_PIN(5, 9)
+#define WMT_PIN_I2C1_SCL	WMT_PIN(5, 10)
+#define WMT_PIN_I2C1_SDA	WMT_PIN(5, 11)
+#define WMT_PIN_I2C2_SCL	WMT_PIN(5, 12)
+#define WMT_PIN_I2C2_SDA	WMT_PIN(5, 13)
+#define WMT_PIN_UART0_RTS	WMT_PIN(5, 16)
+#define WMT_PIN_UART0_TXD	WMT_PIN(5, 17)
+#define WMT_PIN_UART0_CTS	WMT_PIN(5, 18)
+#define WMT_PIN_UART0_RXD	WMT_PIN(5, 19)
+#define WMT_PIN_UART1_RTS	WMT_PIN(5, 20)
+#define WMT_PIN_UART1_TXD	WMT_PIN(5, 21)
+#define WMT_PIN_UART1_CTS	WMT_PIN(5, 22)
+#define WMT_PIN_UART1_RXD	WMT_PIN(5, 23)
+#define WMT_PIN_UART2_RTS	WMT_PIN(5, 24)
+#define WMT_PIN_UART2_TXD	WMT_PIN(5, 25)
+#define WMT_PIN_UART2_CTS	WMT_PIN(5, 26)
+#define WMT_PIN_UART2_RXD	WMT_PIN(5, 27)
+#define WMT_PIN_UART3_RTS	WMT_PIN(5, 28)
+#define WMT_PIN_UART3_TXD	WMT_PIN(5, 29)
+#define WMT_PIN_UART3_CTS	WMT_PIN(5, 30)
+#define WMT_PIN_UART3_RXD	WMT_PIN(5, 31)
+#define WMT_PIN_SD2CD		WMT_PIN(6, 0)
+#define WMT_PIN_SD2DATA3	WMT_PIN(6, 1)
+#define WMT_PIN_SD2DATA0	WMT_PIN(6, 2)
+#define WMT_PIN_SD2WP		WMT_PIN(6, 3)
+#define WMT_PIN_SD2DATA1	WMT_PIN(6, 4)
+#define WMT_PIN_SD2DATA2	WMT_PIN(6, 5)
+#define WMT_PIN_SD2CMD		WMT_PIN(6, 6)
+#define WMT_PIN_SD2CLK		WMT_PIN(6, 7)
+#define WMT_PIN_SD2PWR		WMT_PIN(6, 9)
+#define WMT_PIN_SD1CLK		WMT_PIN(7, 0)
+#define WMT_PIN_SD1CMD		WMT_PIN(7, 1)
+#define WMT_PIN_SD1PWR		WMT_PIN(7, 10)
+#define WMT_PIN_SD1WP		WMT_PIN(7, 11)
+#define WMT_PIN_SD1CD		WMT_PIN(7, 12)
+#define WMT_PIN_SPI0SS3		WMT_PIN(7, 24)
+#define WMT_PIN_SPI0SS2		WMT_PIN(7, 25)
+#define WMT_PIN_PWMOUT1		WMT_PIN(7, 26)
+#define WMT_PIN_PWMOUT0		WMT_PIN(7, 27)
+
+static const struct pinctrl_pin_desc wm8750_pins[] = {
+	PINCTRL_PIN(WMT_PIN_EXTGPIO0, "extgpio0"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO1, "extgpio1"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO2, "extgpio2"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO3, "extgpio3"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO4, "extgpio4"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO5, "extgpio5"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO6, "extgpio6"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO7, "extgpio7"),
+	PINCTRL_PIN(WMT_PIN_WAKEUP0, "wakeup0"),
+	PINCTRL_PIN(WMT_PIN_WAKEUP1, "wakeup1"),
+	PINCTRL_PIN(WMT_PIN_SD0CD, "sd0_cd"),
+	PINCTRL_PIN(WMT_PIN_VDOUT0, "vdout0"),
+	PINCTRL_PIN(WMT_PIN_VDOUT1, "vdout1"),
+	PINCTRL_PIN(WMT_PIN_VDOUT2, "vdout2"),
+	PINCTRL_PIN(WMT_PIN_VDOUT3, "vdout3"),
+	PINCTRL_PIN(WMT_PIN_VDOUT4, "vdout4"),
+	PINCTRL_PIN(WMT_PIN_VDOUT5, "vdout5"),
+	PINCTRL_PIN(WMT_PIN_VDOUT6, "vdout6"),
+	PINCTRL_PIN(WMT_PIN_VDOUT7, "vdout7"),
+	PINCTRL_PIN(WMT_PIN_VDOUT8, "vdout8"),
+	PINCTRL_PIN(WMT_PIN_VDOUT9, "vdout9"),
+	PINCTRL_PIN(WMT_PIN_VDOUT10, "vdout10"),
+	PINCTRL_PIN(WMT_PIN_VDOUT11, "vdout11"),
+	PINCTRL_PIN(WMT_PIN_VDOUT12, "vdout12"),
+	PINCTRL_PIN(WMT_PIN_VDOUT13, "vdout13"),
+	PINCTRL_PIN(WMT_PIN_VDOUT14, "vdout14"),
+	PINCTRL_PIN(WMT_PIN_VDOUT15, "vdout15"),
+	PINCTRL_PIN(WMT_PIN_VDOUT16, "vdout16"),
+	PINCTRL_PIN(WMT_PIN_VDOUT17, "vdout17"),
+	PINCTRL_PIN(WMT_PIN_VDOUT18, "vdout18"),
+	PINCTRL_PIN(WMT_PIN_VDOUT19, "vdout19"),
+	PINCTRL_PIN(WMT_PIN_VDOUT20, "vdout20"),
+	PINCTRL_PIN(WMT_PIN_VDOUT21, "vdout21"),
+	PINCTRL_PIN(WMT_PIN_VDOUT22, "vdout22"),
+	PINCTRL_PIN(WMT_PIN_VDOUT23, "vdout23"),
+	PINCTRL_PIN(WMT_PIN_VDIN0, "vdin0"),
+	PINCTRL_PIN(WMT_PIN_VDIN1, "vdin1"),
+	PINCTRL_PIN(WMT_PIN_VDIN2, "vdin2"),
+	PINCTRL_PIN(WMT_PIN_VDIN3, "vdin3"),
+	PINCTRL_PIN(WMT_PIN_VDIN4, "vdin4"),
+	PINCTRL_PIN(WMT_PIN_VDIN5, "vdin5"),
+	PINCTRL_PIN(WMT_PIN_VDIN6, "vdin6"),
+	PINCTRL_PIN(WMT_PIN_VDIN7, "vdin7"),
+	PINCTRL_PIN(WMT_PIN_SPI0_MOSI, "spi0_mosi"),
+	PINCTRL_PIN(WMT_PIN_SPI0_MISO, "spi0_miso"),
+	PINCTRL_PIN(WMT_PIN_SPI0_SS, "spi0_ss"),
+	PINCTRL_PIN(WMT_PIN_SPI0_CLK, "spi0_clk"),
+	PINCTRL_PIN(WMT_PIN_SPI0_SSB, "spi0_ssb"),
+	PINCTRL_PIN(WMT_PIN_SD0CLK, "sd0_clk"),
+	PINCTRL_PIN(WMT_PIN_SD0CMD, "sd0_cmd"),
+	PINCTRL_PIN(WMT_PIN_SD0WP, "sd0_wp"),
+	PINCTRL_PIN(WMT_PIN_SD0DATA0, "sd0_data0"),
+	PINCTRL_PIN(WMT_PIN_SD0DATA1, "sd0_data1"),
+	PINCTRL_PIN(WMT_PIN_SD0DATA2, "sd0_data2"),
+	PINCTRL_PIN(WMT_PIN_SD0DATA3, "sd0_data3"),
+	PINCTRL_PIN(WMT_PIN_SD1DATA0, "sd1_data0"),
+	PINCTRL_PIN(WMT_PIN_SD1DATA1, "sd1_data1"),
+	PINCTRL_PIN(WMT_PIN_SD1DATA2, "sd1_data2"),
+	PINCTRL_PIN(WMT_PIN_SD1DATA3, "sd1_data3"),
+	PINCTRL_PIN(WMT_PIN_SD1DATA4, "sd1_data4"),
+	PINCTRL_PIN(WMT_PIN_SD1DATA5, "sd1_data5"),
+	PINCTRL_PIN(WMT_PIN_SD1DATA6, "sd1_data6"),
+	PINCTRL_PIN(WMT_PIN_SD1DATA7, "sd1_data7"),
+	PINCTRL_PIN(WMT_PIN_I2C0_SCL, "i2c0_scl"),
+	PINCTRL_PIN(WMT_PIN_I2C0_SDA, "i2c0_sda"),
+	PINCTRL_PIN(WMT_PIN_I2C1_SCL, "i2c1_scl"),
+	PINCTRL_PIN(WMT_PIN_I2C1_SDA, "i2c1_sda"),
+	PINCTRL_PIN(WMT_PIN_I2C2_SCL, "i2c2_scl"),
+	PINCTRL_PIN(WMT_PIN_I2C2_SDA, "i2c2_sda"),
+	PINCTRL_PIN(WMT_PIN_UART0_RTS, "uart0_rts"),
+	PINCTRL_PIN(WMT_PIN_UART0_TXD, "uart0_txd"),
+	PINCTRL_PIN(WMT_PIN_UART0_CTS, "uart0_cts"),
+	PINCTRL_PIN(WMT_PIN_UART0_RXD, "uart0_rxd"),
+	PINCTRL_PIN(WMT_PIN_UART1_RTS, "uart1_rts"),
+	PINCTRL_PIN(WMT_PIN_UART1_TXD, "uart1_txd"),
+	PINCTRL_PIN(WMT_PIN_UART1_CTS, "uart1_cts"),
+	PINCTRL_PIN(WMT_PIN_UART1_RXD, "uart1_rxd"),
+	PINCTRL_PIN(WMT_PIN_UART2_RTS, "uart2_rts"),
+	PINCTRL_PIN(WMT_PIN_UART2_TXD, "uart2_txd"),
+	PINCTRL_PIN(WMT_PIN_UART2_CTS, "uart2_cts"),
+	PINCTRL_PIN(WMT_PIN_UART2_RXD, "uart2_rxd"),
+	PINCTRL_PIN(WMT_PIN_UART3_RTS, "uart3_rts"),
+	PINCTRL_PIN(WMT_PIN_UART3_TXD, "uart3_txd"),
+	PINCTRL_PIN(WMT_PIN_UART3_CTS, "uart3_cts"),
+	PINCTRL_PIN(WMT_PIN_UART3_RXD, "uart3_rxd"),
+	PINCTRL_PIN(WMT_PIN_SD2CD, "sd2_cd"),
+	PINCTRL_PIN(WMT_PIN_SD2DATA3, "sd2_data3"),
+	PINCTRL_PIN(WMT_PIN_SD2DATA0, "sd2_data0"),
+	PINCTRL_PIN(WMT_PIN_SD2WP, "sd2_wp"),
+	PINCTRL_PIN(WMT_PIN_SD2DATA1, "sd2_data1"),
+	PINCTRL_PIN(WMT_PIN_SD2DATA2, "sd2_data2"),
+	PINCTRL_PIN(WMT_PIN_SD2CMD, "sd2_cmd"),
+	PINCTRL_PIN(WMT_PIN_SD2CLK, "sd2_clk"),
+	PINCTRL_PIN(WMT_PIN_SD2PWR, "sd2_pwr"),
+	PINCTRL_PIN(WMT_PIN_SD1CLK, "sd1_clk"),
+	PINCTRL_PIN(WMT_PIN_SD1CMD, "sd1_cmd"),
+	PINCTRL_PIN(WMT_PIN_SD1PWR, "sd1_pwr"),
+	PINCTRL_PIN(WMT_PIN_SD1WP, "sd1_wp"),
+	PINCTRL_PIN(WMT_PIN_SD1CD, "sd1_cd"),
+	PINCTRL_PIN(WMT_PIN_SPI0SS3, "spi0_ss3"),
+	PINCTRL_PIN(WMT_PIN_SPI0SS2, "spi0_ss2"),
+	PINCTRL_PIN(WMT_PIN_PWMOUT1, "pwmout1"),
+	PINCTRL_PIN(WMT_PIN_PWMOUT0, "pwmout0"),
+};
+
+/* Order of these names must match the above list */
+static const char * const wm8750_groups[] = {
+	"extgpio0",
+	"extgpio1",
+	"extgpio2",
+	"extgpio3",
+	"extgpio4",
+	"extgpio5",
+	"extgpio6",
+	"extgpio7",
+	"wakeup0",
+	"wakeup1",
+	"sd0_cd",
+	"vdout0",
+	"vdout1",
+	"vdout2",
+	"vdout3",
+	"vdout4",
+	"vdout5",
+	"vdout6",
+	"vdout7",
+	"vdout8",
+	"vdout9",
+	"vdout10",
+	"vdout11",
+	"vdout12",
+	"vdout13",
+	"vdout14",
+	"vdout15",
+	"vdout16",
+	"vdout17",
+	"vdout18",
+	"vdout19",
+	"vdout20",
+	"vdout21",
+	"vdout22",
+	"vdout23",
+	"vdin0",
+	"vdin1",
+	"vdin2",
+	"vdin3",
+	"vdin4",
+	"vdin5",
+	"vdin6",
+	"vdin7",
+	"spi0_mosi",
+	"spi0_miso",
+	"spi0_ss",
+	"spi0_clk",
+	"spi0_ssb",
+	"sd0_clk",
+	"sd0_cmd",
+	"sd0_wp",
+	"sd0_data0",
+	"sd0_data1",
+	"sd0_data2",
+	"sd0_data3",
+	"sd1_data0",
+	"sd1_data1",
+	"sd1_data2",
+	"sd1_data3",
+	"sd1_data4",
+	"sd1_data5",
+	"sd1_data6",
+	"sd1_data7",
+	"i2c0_scl",
+	"i2c0_sda",
+	"i2c1_scl",
+	"i2c1_sda",
+	"i2c2_scl",
+	"i2c2_sda",
+	"uart0_rts",
+	"uart0_txd",
+	"uart0_cts",
+	"uart0_rxd",
+	"uart1_rts",
+	"uart1_txd",
+	"uart1_cts",
+	"uart1_rxd",
+	"uart2_rts",
+	"uart2_txd",
+	"uart2_cts",
+	"uart2_rxd",
+	"uart3_rts",
+	"uart3_txd",
+	"uart3_cts",
+	"uart3_rxd",
+	"sd2_cd",
+	"sd2_data3",
+	"sd2_data0",
+	"sd2_wp",
+	"sd2_data1",
+	"sd2_data2",
+	"sd2_cmd",
+	"sd2_clk",
+	"sd2_pwr",
+	"sd1_clk",
+	"sd1_cmd",
+	"sd1_pwr",
+	"sd1_wp",
+	"sd1_cd",
+	"spi0_ss3",
+	"spi0_ss2",
+	"pwmout1",
+	"pwmout0",
+};
+
+static int wm8750_pinctrl_probe(struct platform_device *pdev)
+{
+	struct wmt_pinctrl_data *data;
+
+	data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
+	if (!data) {
+		dev_err(&pdev->dev, "failed to allocate data\n");
+		return -ENOMEM;
+	}
+
+	data->banks = wm8750_banks;
+	data->nbanks = ARRAY_SIZE(wm8750_banks);
+	data->pins = wm8750_pins;
+	data->npins = ARRAY_SIZE(wm8750_pins);
+	data->groups = wm8750_groups;
+	data->ngroups = ARRAY_SIZE(wm8750_groups);
+
+	return wmt_pinctrl_probe(pdev, data);
+}
+
+static int wm8750_pinctrl_remove(struct platform_device *pdev)
+{
+	return wmt_pinctrl_remove(pdev);
+}
+
+static struct of_device_id wmt_pinctrl_of_match[] = {
+	{ .compatible = "wm,wm8750-pinctrl" },
+	{ /* sentinel */ },
+};
+
+static struct platform_driver wmt_pinctrl_driver = {
+	.probe	= wm8750_pinctrl_probe,
+	.remove	= wm8750_pinctrl_remove,
+	.driver = {
+		.name	= "pinctrl-wm8750",
+		.owner	= THIS_MODULE,
+		.of_match_table	= wmt_pinctrl_of_match,
+	},
+};
+
+module_platform_driver(wmt_pinctrl_driver);
+
+MODULE_AUTHOR("Tony Prisk <linux at prisktech.co.nz>");
+MODULE_DESCRIPTION("Wondermedia WM8750 Pincontrol driver");
+MODULE_LICENSE("GPL v2");
+MODULE_DEVICE_TABLE(of, wmt_pinctrl_of_match);
diff --git a/drivers/pinctrl/vt8500/pinctrl-wm8850.c b/drivers/pinctrl/vt8500/pinctrl-wm8850.c
new file mode 100644
index 0000000..ecadce9c
--- /dev/null
+++ b/drivers/pinctrl/vt8500/pinctrl-wm8850.c
@@ -0,0 +1,388 @@
+/*
+ * Pinctrl data for Wondermedia WM8850 SoC
+ *
+ * Copyright (c) 2013 Tony Prisk <linux at prisktech.co.nz>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ */
+
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/pinctrl/pinctrl.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+
+#include "pinctrl-wmt.h"
+
+/*
+ * Describe the register offsets within the GPIO memory space
+ * The dedicated external GPIO's should always be listed in bank 0
+ * so they are exported in the 0..31 range which is what users
+ * expect.
+ *
+ * Do not reorder these banks as it will change the pin numbering
+ */
+static const struct wmt_pinctrl_bank_registers wm8850_banks[] = {
+	WMT_PINCTRL_BANK(0x40, 0x80, 0xC0, 0x00, 0x480, 0x4C0),		/* 0 */
+	WMT_PINCTRL_BANK(0x44, 0x84, 0xC4, 0x04, 0x484, 0x4C4),		/* 1 */
+	WMT_PINCTRL_BANK(0x48, 0x88, 0xC8, 0x08, 0x488, 0x4C8),		/* 2 */
+	WMT_PINCTRL_BANK(0x4C, 0x8C, 0xCC, 0x0C, 0x48C, 0x4CC),		/* 3 */
+	WMT_PINCTRL_BANK(0x50, 0x90, 0xD0, 0x10, 0x490, 0x4D0),		/* 4 */
+	WMT_PINCTRL_BANK(0x54, 0x94, 0xD4, 0x14, 0x494, 0x4D4),		/* 5 */
+	WMT_PINCTRL_BANK(0x58, 0x98, 0xD8, 0x18, 0x498, 0x4D8),		/* 6 */
+	WMT_PINCTRL_BANK(0x5C, 0x9C, 0xDC, 0x1C, 0x49C, 0x4DC),		/* 7 */
+	WMT_PINCTRL_BANK(0x60, 0xA0, 0xE0, 0x20, 0x4A0, 0x4E0),		/* 8 */
+	WMT_PINCTRL_BANK(0x70, 0xB0, 0xF0, 0x30, 0x4B0, 0x4F0),		/* 9 */
+	WMT_PINCTRL_BANK(0x7C, 0xBC, 0xDC, 0x3C, 0x4BC, 0x4FC),		/* 10 */
+};
+
+/* Please keep sorted by bank/bit */
+#define WMT_PIN_EXTGPIO0	WMT_PIN(0, 0)
+#define WMT_PIN_EXTGPIO1	WMT_PIN(0, 1)
+#define WMT_PIN_EXTGPIO2	WMT_PIN(0, 2)
+#define WMT_PIN_EXTGPIO3	WMT_PIN(0, 3)
+#define WMT_PIN_EXTGPIO4	WMT_PIN(0, 4)
+#define WMT_PIN_EXTGPIO5	WMT_PIN(0, 5)
+#define WMT_PIN_EXTGPIO6	WMT_PIN(0, 6)
+#define WMT_PIN_EXTGPIO7	WMT_PIN(0, 7)
+#define WMT_PIN_WAKEUP0		WMT_PIN(0, 16)
+#define WMT_PIN_WAKEUP1		WMT_PIN(0, 17)
+#define WMT_PIN_WAKEUP2		WMT_PIN(0, 18)
+#define WMT_PIN_WAKEUP3		WMT_PIN(0, 19)
+#define WMT_PIN_SUSGPIO0	WMT_PIN(0, 21)
+#define WMT_PIN_SUSGPIO1	WMT_PIN(0, 22)
+#define WMT_PIN_SD0CD		WMT_PIN(0, 28)
+#define WMT_PIN_VDOUT0		WMT_PIN(1, 0)
+#define WMT_PIN_VDOUT1		WMT_PIN(1, 1)
+#define WMT_PIN_VDOUT2		WMT_PIN(1, 2)
+#define WMT_PIN_VDOUT3		WMT_PIN(1, 3)
+#define WMT_PIN_VDOUT4		WMT_PIN(1, 4)
+#define WMT_PIN_VDOUT5		WMT_PIN(1, 5)
+#define WMT_PIN_VDOUT6		WMT_PIN(1, 6)
+#define WMT_PIN_VDOUT7		WMT_PIN(1, 7)
+#define WMT_PIN_VDOUT8		WMT_PIN(1, 8)
+#define WMT_PIN_VDOUT9		WMT_PIN(1, 9)
+#define WMT_PIN_VDOUT10		WMT_PIN(1, 10)
+#define WMT_PIN_VDOUT11		WMT_PIN(1, 11)
+#define WMT_PIN_VDOUT12		WMT_PIN(1, 12)
+#define WMT_PIN_VDOUT13		WMT_PIN(1, 13)
+#define WMT_PIN_VDOUT14		WMT_PIN(1, 14)
+#define WMT_PIN_VDOUT15		WMT_PIN(1, 15)
+#define WMT_PIN_VDOUT16		WMT_PIN(1, 16)
+#define WMT_PIN_VDOUT17		WMT_PIN(1, 17)
+#define WMT_PIN_VDOUT18		WMT_PIN(1, 18)
+#define WMT_PIN_VDOUT19		WMT_PIN(1, 19)
+#define WMT_PIN_VDOUT20		WMT_PIN(1, 20)
+#define WMT_PIN_VDOUT21		WMT_PIN(1, 21)
+#define WMT_PIN_VDOUT22		WMT_PIN(1, 22)
+#define WMT_PIN_VDOUT23		WMT_PIN(1, 23)
+#define WMT_PIN_VDIN0		WMT_PIN(2, 0)
+#define WMT_PIN_VDIN1		WMT_PIN(2, 1)
+#define WMT_PIN_VDIN2		WMT_PIN(2, 2)
+#define WMT_PIN_VDIN3		WMT_PIN(2, 3)
+#define WMT_PIN_VDIN4		WMT_PIN(2, 4)
+#define WMT_PIN_VDIN5		WMT_PIN(2, 5)
+#define WMT_PIN_VDIN6		WMT_PIN(2, 6)
+#define WMT_PIN_VDIN7		WMT_PIN(2, 7)
+#define WMT_PIN_SPI0_MOSI	WMT_PIN(2, 24)
+#define WMT_PIN_SPI0_MISO	WMT_PIN(2, 25)
+#define WMT_PIN_SPI0_SS		WMT_PIN(2, 26)
+#define WMT_PIN_SPI0_CLK	WMT_PIN(2, 27)
+#define WMT_PIN_SPI0_SSB	WMT_PIN(2, 28)
+#define WMT_PIN_SD0CLK		WMT_PIN(3, 17)
+#define WMT_PIN_SD0CMD		WMT_PIN(3, 18)
+#define WMT_PIN_SD0WP		WMT_PIN(3, 19)
+#define WMT_PIN_SD0DATA0	WMT_PIN(3, 20)
+#define WMT_PIN_SD0DATA1	WMT_PIN(3, 21)
+#define WMT_PIN_SD0DATA2	WMT_PIN(3, 22)
+#define WMT_PIN_SD0DATA3	WMT_PIN(3, 23)
+#define WMT_PIN_SD1DATA0	WMT_PIN(3, 24)
+#define WMT_PIN_SD1DATA1	WMT_PIN(3, 25)
+#define WMT_PIN_SD1DATA2	WMT_PIN(3, 26)
+#define WMT_PIN_SD1DATA3	WMT_PIN(3, 27)
+#define WMT_PIN_SD1DATA4	WMT_PIN(3, 28)
+#define WMT_PIN_SD1DATA5	WMT_PIN(3, 29)
+#define WMT_PIN_SD1DATA6	WMT_PIN(3, 30)
+#define WMT_PIN_SD1DATA7	WMT_PIN(3, 31)
+#define WMT_PIN_I2C0_SCL	WMT_PIN(5, 8)
+#define WMT_PIN_I2C0_SDA	WMT_PIN(5, 9)
+#define WMT_PIN_I2C1_SCL	WMT_PIN(5, 10)
+#define WMT_PIN_I2C1_SDA	WMT_PIN(5, 11)
+#define WMT_PIN_I2C2_SCL	WMT_PIN(5, 12)
+#define WMT_PIN_I2C2_SDA	WMT_PIN(5, 13)
+#define WMT_PIN_UART0_RTS	WMT_PIN(5, 16)
+#define WMT_PIN_UART0_TXD	WMT_PIN(5, 17)
+#define WMT_PIN_UART0_CTS	WMT_PIN(5, 18)
+#define WMT_PIN_UART0_RXD	WMT_PIN(5, 19)
+#define WMT_PIN_UART1_RTS	WMT_PIN(5, 20)
+#define WMT_PIN_UART1_TXD	WMT_PIN(5, 21)
+#define WMT_PIN_UART1_CTS	WMT_PIN(5, 22)
+#define WMT_PIN_UART1_RXD	WMT_PIN(5, 23)
+#define WMT_PIN_UART2_RTS	WMT_PIN(5, 24)
+#define WMT_PIN_UART2_TXD	WMT_PIN(5, 25)
+#define WMT_PIN_UART2_CTS	WMT_PIN(5, 26)
+#define WMT_PIN_UART2_RXD	WMT_PIN(5, 27)
+#define WMT_PIN_SD2WP		WMT_PIN(6, 3)
+#define WMT_PIN_SD2CMD		WMT_PIN(6, 6)
+#define WMT_PIN_SD2CLK		WMT_PIN(6, 7)
+#define WMT_PIN_SD2PWR		WMT_PIN(6, 9)
+#define WMT_PIN_SD1CLK		WMT_PIN(7, 0)
+#define WMT_PIN_SD1CMD		WMT_PIN(7, 1)
+#define WMT_PIN_SD1PWR		WMT_PIN(7, 10)
+#define WMT_PIN_SD1WP		WMT_PIN(7, 11)
+#define WMT_PIN_SD1CD		WMT_PIN(7, 12)
+#define WMT_PIN_PWMOUT1		WMT_PIN(7, 26)
+#define WMT_PIN_PWMOUT0		WMT_PIN(7, 27)
+
+static const struct pinctrl_pin_desc wm8850_pins[] = {
+	PINCTRL_PIN(WMT_PIN_EXTGPIO0, "extgpio0"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO1, "extgpio1"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO2, "extgpio2"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO3, "extgpio3"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO4, "extgpio4"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO5, "extgpio5"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO6, "extgpio6"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO7, "extgpio7"),
+	PINCTRL_PIN(WMT_PIN_WAKEUP0, "wakeup0"),
+	PINCTRL_PIN(WMT_PIN_WAKEUP1, "wakeup1"),
+	PINCTRL_PIN(WMT_PIN_WAKEUP2, "wakeup2"),
+	PINCTRL_PIN(WMT_PIN_WAKEUP3, "wakeup3"),
+	PINCTRL_PIN(WMT_PIN_SUSGPIO0, "susgpio0"),
+	PINCTRL_PIN(WMT_PIN_SUSGPIO1, "susgpio1"),
+	PINCTRL_PIN(WMT_PIN_SD0CD, "sd0_cd"),
+	PINCTRL_PIN(WMT_PIN_VDOUT0, "vdout0"),
+	PINCTRL_PIN(WMT_PIN_VDOUT1, "vdout1"),
+	PINCTRL_PIN(WMT_PIN_VDOUT2, "vdout2"),
+	PINCTRL_PIN(WMT_PIN_VDOUT3, "vdout3"),
+	PINCTRL_PIN(WMT_PIN_VDOUT4, "vdout4"),
+	PINCTRL_PIN(WMT_PIN_VDOUT5, "vdout5"),
+	PINCTRL_PIN(WMT_PIN_VDOUT6, "vdout6"),
+	PINCTRL_PIN(WMT_PIN_VDOUT7, "vdout7"),
+	PINCTRL_PIN(WMT_PIN_VDOUT8, "vdout8"),
+	PINCTRL_PIN(WMT_PIN_VDOUT9, "vdout9"),
+	PINCTRL_PIN(WMT_PIN_VDOUT10, "vdout10"),
+	PINCTRL_PIN(WMT_PIN_VDOUT11, "vdout11"),
+	PINCTRL_PIN(WMT_PIN_VDOUT12, "vdout12"),
+	PINCTRL_PIN(WMT_PIN_VDOUT13, "vdout13"),
+	PINCTRL_PIN(WMT_PIN_VDOUT14, "vdout14"),
+	PINCTRL_PIN(WMT_PIN_VDOUT15, "vdout15"),
+	PINCTRL_PIN(WMT_PIN_VDOUT16, "vdout16"),
+	PINCTRL_PIN(WMT_PIN_VDOUT17, "vdout17"),
+	PINCTRL_PIN(WMT_PIN_VDOUT18, "vdout18"),
+	PINCTRL_PIN(WMT_PIN_VDOUT19, "vdout19"),
+	PINCTRL_PIN(WMT_PIN_VDOUT20, "vdout20"),
+	PINCTRL_PIN(WMT_PIN_VDOUT21, "vdout21"),
+	PINCTRL_PIN(WMT_PIN_VDOUT22, "vdout22"),
+	PINCTRL_PIN(WMT_PIN_VDOUT23, "vdout23"),
+	PINCTRL_PIN(WMT_PIN_VDIN0, "vdin0"),
+	PINCTRL_PIN(WMT_PIN_VDIN1, "vdin1"),
+	PINCTRL_PIN(WMT_PIN_VDIN2, "vdin2"),
+	PINCTRL_PIN(WMT_PIN_VDIN3, "vdin3"),
+	PINCTRL_PIN(WMT_PIN_VDIN4, "vdin4"),
+	PINCTRL_PIN(WMT_PIN_VDIN5, "vdin5"),
+	PINCTRL_PIN(WMT_PIN_VDIN6, "vdin6"),
+	PINCTRL_PIN(WMT_PIN_VDIN7, "vdin7"),
+	PINCTRL_PIN(WMT_PIN_SPI0_MOSI, "spi0_mosi"),
+	PINCTRL_PIN(WMT_PIN_SPI0_MISO, "spi0_miso"),
+	PINCTRL_PIN(WMT_PIN_SPI0_SS, "spi0_ss"),
+	PINCTRL_PIN(WMT_PIN_SPI0_CLK, "spi0_clk"),
+	PINCTRL_PIN(WMT_PIN_SPI0_SSB, "spi0_ssb"),
+	PINCTRL_PIN(WMT_PIN_SD0CLK, "sd0_clk"),
+	PINCTRL_PIN(WMT_PIN_SD0CMD, "sd0_cmd"),
+	PINCTRL_PIN(WMT_PIN_SD0WP, "sd0_wp"),
+	PINCTRL_PIN(WMT_PIN_SD0DATA0, "sd0_data0"),
+	PINCTRL_PIN(WMT_PIN_SD0DATA1, "sd0_data1"),
+	PINCTRL_PIN(WMT_PIN_SD0DATA2, "sd0_data2"),
+	PINCTRL_PIN(WMT_PIN_SD0DATA3, "sd0_data3"),
+	PINCTRL_PIN(WMT_PIN_SD1DATA0, "sd1_data0"),
+	PINCTRL_PIN(WMT_PIN_SD1DATA1, "sd1_data1"),
+	PINCTRL_PIN(WMT_PIN_SD1DATA2, "sd1_data2"),
+	PINCTRL_PIN(WMT_PIN_SD1DATA3, "sd1_data3"),
+	PINCTRL_PIN(WMT_PIN_SD1DATA4, "sd1_data4"),
+	PINCTRL_PIN(WMT_PIN_SD1DATA5, "sd1_data5"),
+	PINCTRL_PIN(WMT_PIN_SD1DATA6, "sd1_data6"),
+	PINCTRL_PIN(WMT_PIN_SD1DATA7, "sd1_data7"),
+	PINCTRL_PIN(WMT_PIN_I2C0_SCL, "i2c0_scl"),
+	PINCTRL_PIN(WMT_PIN_I2C0_SDA, "i2c0_sda"),
+	PINCTRL_PIN(WMT_PIN_I2C1_SCL, "i2c1_scl"),
+	PINCTRL_PIN(WMT_PIN_I2C1_SDA, "i2c1_sda"),
+	PINCTRL_PIN(WMT_PIN_I2C2_SCL, "i2c2_scl"),
+	PINCTRL_PIN(WMT_PIN_I2C2_SDA, "i2c2_sda"),
+	PINCTRL_PIN(WMT_PIN_UART0_RTS, "uart0_rts"),
+	PINCTRL_PIN(WMT_PIN_UART0_TXD, "uart0_txd"),
+	PINCTRL_PIN(WMT_PIN_UART0_CTS, "uart0_cts"),
+	PINCTRL_PIN(WMT_PIN_UART0_RXD, "uart0_rxd"),
+	PINCTRL_PIN(WMT_PIN_UART1_RTS, "uart1_rts"),
+	PINCTRL_PIN(WMT_PIN_UART1_TXD, "uart1_txd"),
+	PINCTRL_PIN(WMT_PIN_UART1_CTS, "uart1_cts"),
+	PINCTRL_PIN(WMT_PIN_UART1_RXD, "uart1_rxd"),
+	PINCTRL_PIN(WMT_PIN_UART2_RTS, "uart2_rts"),
+	PINCTRL_PIN(WMT_PIN_UART2_TXD, "uart2_txd"),
+	PINCTRL_PIN(WMT_PIN_UART2_CTS, "uart2_cts"),
+	PINCTRL_PIN(WMT_PIN_UART2_RXD, "uart2_rxd"),
+	PINCTRL_PIN(WMT_PIN_SD2WP, "sd2_wp"),
+	PINCTRL_PIN(WMT_PIN_SD2CMD, "sd2_cmd"),
+	PINCTRL_PIN(WMT_PIN_SD2CLK, "sd2_clk"),
+	PINCTRL_PIN(WMT_PIN_SD2PWR, "sd2_pwr"),
+	PINCTRL_PIN(WMT_PIN_SD1CLK, "sd1_clk"),
+	PINCTRL_PIN(WMT_PIN_SD1CMD, "sd1_cmd"),
+	PINCTRL_PIN(WMT_PIN_SD1PWR, "sd1_pwr"),
+	PINCTRL_PIN(WMT_PIN_SD1WP, "sd1_wp"),
+	PINCTRL_PIN(WMT_PIN_SD1CD, "sd1_cd"),
+	PINCTRL_PIN(WMT_PIN_PWMOUT1, "pwmout1"),
+	PINCTRL_PIN(WMT_PIN_PWMOUT0, "pwmout0"),
+};
+
+/* Order of these names must match the above list */
+static const char * const wm8850_groups[] = {
+	"extgpio0",
+	"extgpio1",
+	"extgpio2",
+	"extgpio3",
+	"extgpio4",
+	"extgpio5",
+	"extgpio6",
+	"extgpio7",
+	"wakeup0",
+	"wakeup1",
+	"wakeup2",
+	"wakeup3",
+	"susgpio0",
+	"susgpio1",
+	"sd0_cd",
+	"vdout0",
+	"vdout1",
+	"vdout2",
+	"vdout3",
+	"vdout4",
+	"vdout5",
+	"vdout6",
+	"vdout7",
+	"vdout8",
+	"vdout9",
+	"vdout10",
+	"vdout11",
+	"vdout12",
+	"vdout13",
+	"vdout14",
+	"vdout15",
+	"vdout16",
+	"vdout17",
+	"vdout18",
+	"vdout19",
+	"vdout20",
+	"vdout21",
+	"vdout22",
+	"vdout23",
+	"vdin0",
+	"vdin1",
+	"vdin2",
+	"vdin3",
+	"vdin4",
+	"vdin5",
+	"vdin6",
+	"vdin7",
+	"spi0_mosi",
+	"spi0_miso",
+	"spi0_ss",
+	"spi0_clk",
+	"spi0_ssb",
+	"sd0_clk",
+	"sd0_cmd",
+	"sd0_wp",
+	"sd0_data0",
+	"sd0_data1",
+	"sd0_data2",
+	"sd0_data3",
+	"sd1_data0",
+	"sd1_data1",
+	"sd1_data2",
+	"sd1_data3",
+	"sd1_data4",
+	"sd1_data5",
+	"sd1_data6",
+	"sd1_data7",
+	"i2c0_scl",
+	"i2c0_sda",
+	"i2c1_scl",
+	"i2c1_sda",
+	"i2c2_scl",
+	"i2c2_sda",
+	"uart0_rts",
+	"uart0_txd",
+	"uart0_cts",
+	"uart0_rxd",
+	"uart1_rts",
+	"uart1_txd",
+	"uart1_cts",
+	"uart1_rxd",
+	"uart2_rts",
+	"uart2_txd",
+	"uart2_cts",
+	"uart2_rxd",
+	"sd2_wp",
+	"sd2_cmd",
+	"sd2_clk",
+	"sd2_pwr",
+	"sd1_clk",
+	"sd1_cmd",
+	"sd1_pwr",
+	"sd1_wp",
+	"sd1_cd",
+	"pwmout1",
+	"pwmout0",
+};
+
+static int wm8850_pinctrl_probe(struct platform_device *pdev)
+{
+	struct wmt_pinctrl_data *data;
+
+	data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
+	if (!data) {
+		dev_err(&pdev->dev, "failed to allocate data\n");
+		return -ENOMEM;
+	}
+
+	data->banks = wm8850_banks;
+	data->nbanks = ARRAY_SIZE(wm8850_banks);
+	data->pins = wm8850_pins;
+	data->npins = ARRAY_SIZE(wm8850_pins);
+	data->groups = wm8850_groups;
+	data->ngroups = ARRAY_SIZE(wm8850_groups);
+
+	return wmt_pinctrl_probe(pdev, data);
+}
+
+static int wm8850_pinctrl_remove(struct platform_device *pdev)
+{
+	return wmt_pinctrl_remove(pdev);
+}
+
+static struct of_device_id wmt_pinctrl_of_match[] = {
+	{ .compatible = "wm,wm8850-pinctrl" },
+	{ /* sentinel */ },
+};
+
+static struct platform_driver wmt_pinctrl_driver = {
+	.probe	= wm8850_pinctrl_probe,
+	.remove	= wm8850_pinctrl_remove,
+	.driver = {
+		.name	= "pinctrl-wm8850",
+		.owner	= THIS_MODULE,
+		.of_match_table	= wmt_pinctrl_of_match,
+	},
+};
+
+module_platform_driver(wmt_pinctrl_driver);
+
+MODULE_AUTHOR("Tony Prisk <linux at prisktech.co.nz>");
+MODULE_DESCRIPTION("Wondermedia WM8850 Pincontrol driver");
+MODULE_LICENSE("GPL v2");
+MODULE_DEVICE_TABLE(of, wmt_pinctrl_of_match);
diff --git a/drivers/pinctrl/vt8500/pinctrl-wmt.c b/drivers/pinctrl/vt8500/pinctrl-wmt.c
new file mode 100644
index 0000000..9736d27
--- /dev/null
+++ b/drivers/pinctrl/vt8500/pinctrl-wmt.c
@@ -0,0 +1,620 @@
+/*
+ * Pinctrl driver for the Wondermedia SoC's
+ *
+ * Copyright (c) 2013 Tony Prisk <linux at prisktech.co.nz>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ */
+
+#include <linux/err.h>
+#include <linux/gpio.h>
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/irq.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_irq.h>
+#include <linux/pinctrl/consumer.h>
+#include <linux/pinctrl/machine.h>
+#include <linux/pinctrl/pinconf.h>
+#include <linux/pinctrl/pinconf-generic.h>
+#include <linux/pinctrl/pinctrl.h>
+#include <linux/pinctrl/pinmux.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+
+#include "pinctrl-wmt.h"
+
+static inline void wmt_setbits(struct wmt_pinctrl_data *data, u32 reg,
+				 u32 mask)
+{
+	u32 val;
+
+	val = readl_relaxed(data->base + reg);
+	val |= mask;
+	writel_relaxed(val, data->base + reg);
+}
+
+static inline void wmt_clearbits(struct wmt_pinctrl_data *data, u32 reg,
+				   u32 mask)
+{
+	u32 val;
+
+	val = readl_relaxed(data->base + reg);
+	val &= ~mask;
+	writel_relaxed(val, data->base + reg);
+}
+
+enum wmt_func_sel {
+	WMT_FSEL_GPIO_IN = 0,
+	WMT_FSEL_GPIO_OUT = 1,
+	WMT_FSEL_ALT = 2,
+	WMT_FSEL_COUNT = 3,
+};
+
+static const char * const wmt_functions[WMT_FSEL_COUNT] = {
+	[WMT_FSEL_GPIO_IN] = "gpio_in",
+	[WMT_FSEL_GPIO_OUT] = "gpio_out",
+	[WMT_FSEL_ALT] = "alt",
+};
+
+static int wmt_pmx_get_functions_count(struct pinctrl_dev *pctldev)
+{
+	return WMT_FSEL_COUNT;
+}
+
+static const char *wmt_pmx_get_function_name(struct pinctrl_dev *pctldev,
+					     unsigned selector)
+{
+	return wmt_functions[selector];
+}
+
+static int wmt_pmx_get_function_groups(struct pinctrl_dev *pctldev,
+				       unsigned selector,
+				       const char * const **groups,
+				       unsigned * const num_groups)
+{
+	struct wmt_pinctrl_data *data = pinctrl_dev_get_drvdata(pctldev);
+
+	/* every pin does every function */
+	*groups = data->groups;
+	*num_groups = data->ngroups;
+
+	return 0;
+}
+
+static int wmt_set_pinmux(struct wmt_pinctrl_data *data, unsigned func,
+			  unsigned pin)
+{
+	u32 bank = WMT_BANK_FROM_PIN(pin);
+	u32 bit = WMT_BIT_FROM_PIN(pin);
+	u32 reg_en = data->banks[bank].reg_en;
+	u32 reg_dir = data->banks[bank].reg_dir;
+
+	if (reg_dir == NO_REG) {
+		dev_err(data->dev, "pin:%d no direction register defined\n",
+			pin);
+		return -EINVAL;
+	}
+
+	/*
+	 * If reg_en == NO_REG, we assume it is a dedicated GPIO and cannot be
+	 * disabled (as on VT8500) and that no alternate function is available.
+	 */
+	switch (func) {
+	case WMT_FSEL_GPIO_IN:
+		if (reg_en != NO_REG)
+			wmt_setbits(data, reg_en, BIT(bit));
+		wmt_clearbits(data, reg_dir, BIT(bit));
+		break;
+	case WMT_FSEL_GPIO_OUT:
+		if (reg_en != NO_REG)
+			wmt_setbits(data, reg_en, BIT(bit));
+		wmt_setbits(data, reg_dir, BIT(bit));
+		break;
+	case WMT_FSEL_ALT:
+		if (reg_en == NO_REG) {
+			dev_err(data->dev, "pin:%d no alt function available\n",
+				pin);
+			return -EINVAL;
+		}
+		wmt_clearbits(data, reg_en, BIT(bit));
+	}
+
+	return 0;
+}
+
+static int wmt_pmx_enable(struct pinctrl_dev *pctldev,
+			  unsigned func_selector,
+			  unsigned group_selector)
+{
+	struct wmt_pinctrl_data *data = pinctrl_dev_get_drvdata(pctldev);
+	u32 pinnum = data->pins[group_selector].number;
+
+	return wmt_set_pinmux(data, func_selector, pinnum);
+}
+
+static void wmt_pmx_disable(struct pinctrl_dev *pctldev,
+			    unsigned func_selector,
+			    unsigned group_selector)
+{
+	struct wmt_pinctrl_data *data = pinctrl_dev_get_drvdata(pctldev);
+	u32 pinnum = data->pins[group_selector].number;
+
+	/* disable by setting GPIO_IN */
+	wmt_set_pinmux(data, WMT_FSEL_GPIO_IN, pinnum);
+}
+
+static void wmt_pmx_gpio_disable_free(struct pinctrl_dev *pctldev,
+				      struct pinctrl_gpio_range *range,
+				      unsigned offset)
+{
+	struct wmt_pinctrl_data *data = pinctrl_dev_get_drvdata(pctldev);
+
+	/* disable by setting GPIO_IN */
+	wmt_set_pinmux(data, WMT_FSEL_GPIO_IN, offset);
+}
+
+static int wmt_pmx_gpio_set_direction(struct pinctrl_dev *pctldev,
+				      struct pinctrl_gpio_range *range,
+				      unsigned offset,
+				      bool input)
+{
+	struct wmt_pinctrl_data *data = pinctrl_dev_get_drvdata(pctldev);
+
+	wmt_set_pinmux(data, (input ? WMT_FSEL_GPIO_IN : WMT_FSEL_GPIO_OUT),
+		       offset);
+
+	return 0;
+}
+
+static struct pinmux_ops wmt_pinmux_ops = {
+	.get_functions_count = wmt_pmx_get_functions_count,
+	.get_function_name = wmt_pmx_get_function_name,
+	.get_function_groups = wmt_pmx_get_function_groups,
+	.enable = wmt_pmx_enable,
+	.disable = wmt_pmx_disable,
+	.gpio_disable_free = wmt_pmx_gpio_disable_free,
+	.gpio_set_direction = wmt_pmx_gpio_set_direction,
+};
+
+static int wmt_get_groups_count(struct pinctrl_dev *pctldev)
+{
+	struct wmt_pinctrl_data *data = pinctrl_dev_get_drvdata(pctldev);
+
+	return data->ngroups;
+}
+
+static const char *wmt_get_group_name(struct pinctrl_dev *pctldev,
+				      unsigned selector)
+{
+	struct wmt_pinctrl_data *data = pinctrl_dev_get_drvdata(pctldev);
+
+	return data->groups[selector];
+}
+
+static int wmt_get_group_pins(struct pinctrl_dev *pctldev,
+			      unsigned selector,
+			      const unsigned **pins,
+			      unsigned *num_pins)
+{
+	struct wmt_pinctrl_data *data = pinctrl_dev_get_drvdata(pctldev);
+
+	*pins = &data->pins[selector].number;
+	*num_pins = 1;
+
+	return 0;
+}
+
+static int wmt_pctl_find_group_by_pin(struct wmt_pinctrl_data *data, u32 pin)
+{
+	int i;
+
+	for (i = 0; i < data->npins; i++) {
+		if (data->pins[i].number == pin)
+			return i;
+	}
+
+	return -EINVAL;
+}
+
+static int wmt_pctl_dt_node_to_map_func(struct wmt_pinctrl_data *data,
+					struct device_node *np,
+					u32 pin, u32 fnum,
+					struct pinctrl_map **maps)
+{
+	int group;
+	struct pinctrl_map *map = *maps;
+
+	if (fnum >= ARRAY_SIZE(wmt_functions)) {
+		dev_err(data->dev, "invalid wm,function %d\n", fnum);
+		return -EINVAL;
+	}
+
+	group = wmt_pctl_find_group_by_pin(data, pin);
+	if (group < 0) {
+		dev_err(data->dev, "unable to match pin %d to group\n", pin);
+		return group;
+	}
+
+	map->type = PIN_MAP_TYPE_MUX_GROUP;
+	map->data.mux.group = data->groups[group];
+	map->data.mux.function = wmt_functions[fnum];
+	(*maps)++;
+
+	return 0;
+}
+
+static int wmt_pctl_dt_node_to_map_pull(struct wmt_pinctrl_data *data,
+					struct device_node *np,
+					u32 pin, u32 pull,
+					struct pinctrl_map **maps)
+{
+	int group;
+	unsigned long *configs;
+	struct pinctrl_map *map = *maps;
+
+	if (pull > 2) {
+		dev_err(data->dev, "invalid wm,pull %d\n", pull);
+		return -EINVAL;
+	}
+
+	group = wmt_pctl_find_group_by_pin(data, pin);
+	if (group < 0) {
+		dev_err(data->dev, "unable to match pin %d to group\n", pin);
+		return group;
+	}
+
+	configs = devm_kzalloc(data->dev, sizeof(*configs), GFP_KERNEL);
+	if (!configs)
+		return -ENOMEM;
+
+	configs[0] = pull;
+
+	map->type = PIN_MAP_TYPE_CONFIGS_PIN;
+	map->data.configs.group_or_pin = data->groups[group];
+	map->data.configs.configs = configs;
+	map->data.configs.num_configs = 1;
+	(*maps)++;
+
+	return 0;
+}
+
+static int wmt_pctl_dt_node_to_map(struct pinctrl_dev *pctldev,
+				   struct device_node *np,
+				   struct pinctrl_map **map,
+				   unsigned *num_maps)
+{
+	struct pinctrl_map *maps, *cur_map;
+	struct property *pins, *funcs, *pulls;
+	u32 pin, func, pull;
+	int num_pins, num_funcs, num_pulls, maps_per_pin;
+	int i, err;
+	struct wmt_pinctrl_data *data = pinctrl_dev_get_drvdata(pctldev);
+
+	pins = of_find_property(np, "wm,pins", NULL);
+	if (!pins) {
+		dev_err(data->dev, "missing wmt,pins property\n");
+		return -EINVAL;
+	}
+
+	funcs = of_find_property(np, "wm,function", NULL);
+	pulls = of_find_property(np, "wm,pull", NULL);
+
+	if (!funcs && !pulls) {
+		dev_err(data->dev, "neither wm,function nor wm,pull specified\n");
+		return -EINVAL;
+	}
+
+	/*
+	 * The following lines calculate how many values are defined for each
+	 * of the properties.
+	 */
+	num_pins = pins->length / sizeof(u32);
+	num_funcs = funcs ? (funcs->length / sizeof(u32)) : 0;
+	num_pulls = pulls ? (pulls->length / sizeof(u32)) : 0;
+
+	if (num_funcs > 1 && num_funcs != num_pins) {
+		dev_err(data->dev, "wm,function must have 1 or %d entries\n",
+			num_pins);
+		return -EINVAL;
+	}
+
+	if (num_pulls > 1 && num_pulls != num_pins) {
+		dev_err(data->dev, "wm,pull must have 1 or %d entries\n",
+			num_pins);
+		return -EINVAL;
+	}
+
+	maps_per_pin = 0;
+	if (num_funcs)
+		maps_per_pin++;
+	if (num_pulls)
+		maps_per_pin++;
+
+	cur_map = maps = devm_kzalloc(data->dev,
+				      num_pins * maps_per_pin * sizeof(*maps),
+				      GFP_KERNEL);
+	if (!maps)
+		return -ENOMEM;
+
+	for (i = 0; i < num_pins; i++) {
+		err = of_property_read_u32_index(np, "wm,pins", i, &pin);
+		if (err)
+			return err;
+
+		if (pin >= (data->nbanks * 32)) {
+			dev_err(data->dev, "invalid wm,pins value\n");
+			return -EINVAL;
+		}
+
+		if (num_funcs) {
+			err = of_property_read_u32_index(np, "wm,function",
+						(num_funcs > 1 ? i : 0), &func);
+			if (err)
+				return err;
+
+			err = wmt_pctl_dt_node_to_map_func(data, np, pin, func,
+							   &cur_map);
+			if (err)
+				return err;
+		}
+
+		if (num_pulls) {
+			err = of_property_read_u32_index(np, "wm,pull",
+						(num_pulls > 1 ? i : 0), &pull);
+			if (err)
+				return err;
+
+			err = wmt_pctl_dt_node_to_map_pull(data, np, pin, pull,
+							   &cur_map);
+			if (err)
+				return err;
+		}
+	}
+	*map = maps;
+	*num_maps = num_pins * maps_per_pin;
+	return 0;
+}
+
+static void wmt_pctl_dt_free_map(struct pinctrl_dev *pctldev,
+				 struct pinctrl_map *maps,
+				 unsigned num_maps)
+{
+	int i;
+
+	for (i = 0; i < num_maps; i++)
+		if (maps[i].type == PIN_MAP_TYPE_CONFIGS_PIN)
+			kfree(maps[i].data.configs.configs);
+
+	kfree(maps);
+}
+
+static struct pinctrl_ops wmt_pctl_ops = {
+	.get_groups_count = wmt_get_groups_count,
+	.get_group_name	= wmt_get_group_name,
+	.get_group_pins	= wmt_get_group_pins,
+	.dt_node_to_map = wmt_pctl_dt_node_to_map,
+	.dt_free_map = wmt_pctl_dt_free_map,
+};
+
+static int wmt_pinconf_get(struct pinctrl_dev *pctldev, unsigned pin,
+			   unsigned long *config)
+{
+	return -ENOTSUPP;
+}
+
+static int wmt_pinconf_set(struct pinctrl_dev *pctldev, unsigned pin,
+			   unsigned long config)
+{
+	struct wmt_pinctrl_data *data = pinctrl_dev_get_drvdata(pctldev);
+	enum pin_config_param param = pinconf_to_config_param(config);
+	u16 arg = pinconf_to_config_argument(config);
+	u32 bank = WMT_BANK_FROM_PIN(pin);
+	u32 bit = WMT_BIT_FROM_PIN(pin);
+	u32 reg_pull_en = data->banks[bank].reg_pull_en;
+	u32 reg_pull_cfg = data->banks[bank].reg_pull_cfg;
+
+	if ((reg_pull_en == NO_REG) || (reg_pull_cfg == NO_REG)) {
+		dev_err(data->dev, "bias functions not supported on pin %d\n",
+			pin);
+		return -EINVAL;
+	}
+
+	if ((param == PIN_CONFIG_BIAS_PULL_DOWN) ||
+	    (param == PIN_CONFIG_BIAS_PULL_UP)) {
+		if (arg == 0)
+			param = PIN_CONFIG_BIAS_DISABLE;
+	}
+
+	switch (param) {
+	case PIN_CONFIG_BIAS_DISABLE:
+		wmt_clearbits(data, reg_pull_en, BIT(bit));
+		break;
+	case PIN_CONFIG_BIAS_PULL_DOWN:
+		wmt_clearbits(data, reg_pull_cfg, BIT(bit));
+		wmt_setbits(data, reg_pull_en, BIT(bit));
+		break;
+	case PIN_CONFIG_BIAS_PULL_UP:
+		wmt_setbits(data, reg_pull_cfg, BIT(bit));
+		wmt_setbits(data, reg_pull_en, BIT(bit));
+		break;
+	default:
+		dev_err(data->dev, "unknown pinconf param\n");
+		return -EINVAL;
+	}
+
+	return 0;
+}
+
+static struct pinconf_ops wmt_pinconf_ops = {
+	.pin_config_get = wmt_pinconf_get,
+	.pin_config_set = wmt_pinconf_set,
+};
+
+static struct pinctrl_desc wmt_desc = {
+	.owner = THIS_MODULE,
+	.name = "pinctrl-wmt",
+	.pctlops = &wmt_pctl_ops,
+	.pmxops = &wmt_pinmux_ops,
+	.confops = &wmt_pinconf_ops,
+};
+
+static int wmt_gpio_request(struct gpio_chip *chip, unsigned offset)
+{
+	return pinctrl_request_gpio(chip->base + offset);
+}
+
+static void wmt_gpio_free(struct gpio_chip *chip, unsigned offset)
+{
+	pinctrl_free_gpio(chip->base + offset);
+}
+
+static int wmt_gpio_get_direction(struct gpio_chip *chip, unsigned offset)
+{
+	struct wmt_pinctrl_data *data = dev_get_drvdata(chip->dev);
+	u32 bank = WMT_BANK_FROM_PIN(offset);
+	u32 bit = WMT_BIT_FROM_PIN(offset);
+	u32 reg_dir = data->banks[bank].reg_dir;
+	u32 val;
+
+	val = readl_relaxed(data->base + reg_dir);
+	if (val & BIT(bit))
+		return GPIOF_DIR_OUT;
+	else
+		return GPIOF_DIR_IN;
+}
+
+static int wmt_gpio_direction_input(struct gpio_chip *chip, unsigned offset)
+{
+	return pinctrl_gpio_direction_input(chip->base + offset);
+}
+
+static int wmt_gpio_direction_output(struct gpio_chip *chip, unsigned offset,
+				     int value)
+{
+	return pinctrl_gpio_direction_output(chip->base + offset);
+}
+
+static int wmt_gpio_get_value(struct gpio_chip *chip, unsigned offset)
+{
+	struct wmt_pinctrl_data *data = dev_get_drvdata(chip->dev);
+	u32 bank = WMT_BANK_FROM_PIN(offset);
+	u32 bit = WMT_BIT_FROM_PIN(offset);
+	u32 reg_data_in = data->banks[bank].reg_data_in;
+
+	if (reg_data_in == NO_REG) {
+		dev_err(data->dev, "no data in register defined\n");
+		return -EINVAL;
+	}
+
+	return !!(readl_relaxed(data->base + reg_data_in) & BIT(bit));
+}
+
+static void wmt_gpio_set_value(struct gpio_chip *chip, unsigned offset,
+			       int val)
+{
+	struct wmt_pinctrl_data *data = dev_get_drvdata(chip->dev);
+	u32 bank = WMT_BANK_FROM_PIN(offset);
+	u32 bit = WMT_BIT_FROM_PIN(offset);
+	u32 reg_data_out = data->banks[bank].reg_data_out;
+
+	if (reg_data_out == NO_REG) {
+		dev_err(data->dev, "no data out register defined\n");
+		return;
+	}
+
+	if (val)
+		wmt_setbits(data, reg_data_out, BIT(bit));
+	else
+		wmt_clearbits(data, reg_data_out, BIT(bit));
+}
+
+static struct gpio_chip wmt_gpio_chip = {
+	.label = "gpio-wmt",
+	.owner = THIS_MODULE,
+	.request = wmt_gpio_request,
+	.free = wmt_gpio_free,
+	.get_direction = wmt_gpio_get_direction,
+	.direction_input = wmt_gpio_direction_input,
+	.direction_output = wmt_gpio_direction_output,
+	.get = wmt_gpio_get_value,
+	.set = wmt_gpio_set_value,
+	.can_sleep = 0,
+};
+
+int wmt_pinctrl_probe(struct platform_device *pdev,
+		      struct wmt_pinctrl_data *data)
+{
+	int err;
+	struct resource *res;
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	data->base = devm_request_and_ioremap(&pdev->dev, res);
+	if (!data->base) {
+		dev_err(&pdev->dev, "failed to map memory resource\n");
+		return -EBUSY;
+	}
+
+	wmt_desc.pins = data->pins;
+	wmt_desc.npins = data->npins;
+
+	data->gpio_chip = wmt_gpio_chip;
+	data->gpio_chip.dev = &pdev->dev;
+	data->gpio_chip.of_node = pdev->dev.of_node;
+	data->gpio_chip.ngpio = data->nbanks * 32;
+
+	platform_set_drvdata(pdev, data);
+
+	data->dev = &pdev->dev;
+
+	data->pctl_dev = pinctrl_register(&wmt_desc, &pdev->dev, data);
+	if (IS_ERR(data->pctl_dev)) {
+		dev_err(&pdev->dev, "Failed to register pinctrl\n");
+		return -EINVAL;
+	}
+
+	err = gpiochip_add(&data->gpio_chip);
+	if (err) {
+		dev_err(&pdev->dev, "could not add GPIO chip\n");
+		goto fail_gpio;
+	}
+
+	err = gpiochip_add_pin_range(&data->gpio_chip, dev_name(data->dev),
+				     0, 0, data->nbanks * 32);
+	if (err)
+		goto fail_range;
+
+	dev_info(&pdev->dev, "Pin controller initialized\n");
+
+	return 0;
+
+fail_range:
+	err = gpiochip_remove(&data->gpio_chip);
+	if (err)
+		dev_err(&pdev->dev, "failed to remove gpio chip\n");
+fail_gpio:
+	pinctrl_unregister(data->pctl_dev);
+	return err;
+}
+
+int wmt_pinctrl_remove(struct platform_device *pdev)
+{
+	struct wmt_pinctrl_data *data = platform_get_drvdata(pdev);
+	int err;
+
+	err = gpiochip_remove(&data->gpio_chip);
+	if (err)
+		dev_err(&pdev->dev, "failed to remove gpio chip\n");
+
+	pinctrl_unregister(data->pctl_dev);
+
+	return 0;
+}
diff --git a/drivers/pinctrl/vt8500/pinctrl-wmt.h b/drivers/pinctrl/vt8500/pinctrl-wmt.h
new file mode 100644
index 0000000..41f5f2d
--- /dev/null
+++ b/drivers/pinctrl/vt8500/pinctrl-wmt.h
@@ -0,0 +1,79 @@
+/*
+ * Pinctrl driver for the Wondermedia SoC's
+ *
+ * Copyright (c) 2013 Tony Prisk <linux at prisktech.co.nz>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ */
+
+#include <linux/gpio.h>
+
+/* VT8500 has no enable register in the extgpio bank. */
+#define NO_REG	0xFFFF
+
+#define WMT_PINCTRL_BANK(__en, __dir, __dout, __din, __pen, __pcfg)	\
+{									\
+	.reg_en		= __en,						\
+	.reg_dir	= __dir,					\
+	.reg_data_out	= __dout,					\
+	.reg_data_in	= __din,					\
+	.reg_pull_en	= __pen,					\
+	.reg_pull_cfg	= __pcfg,					\
+}
+
+/* Encode/decode the bank/bit pairs into a pin value */
+#define WMT_PIN(__bank, __offset)	((__bank << 5) | __offset)
+#define WMT_BANK_FROM_PIN(__pin)	(__pin >> 5)
+#define WMT_BIT_FROM_PIN(__pin)		(__pin & 0x1f)
+
+#define WMT_GROUP(__name, __data)		\
+{						\
+	.name = __name,				\
+	.pins = __data,				\
+	.npins = ARRAY_SIZE(__data),		\
+}
+
+struct wmt_pinctrl_bank_registers {
+	u32	reg_en;
+	u32	reg_dir;
+	u32	reg_data_out;
+	u32	reg_data_in;
+
+	u32	reg_pull_en;
+	u32	reg_pull_cfg;
+};
+
+struct wmt_pinctrl_group {
+	const char *name;
+	const unsigned int *pins;
+	const unsigned npins;
+};
+
+struct wmt_pinctrl_data {
+	struct device *dev;
+	struct pinctrl_dev *pctl_dev;
+
+	/* must be initialized before calling wmt_pinctrl_probe */
+	void __iomem *base;
+	const struct wmt_pinctrl_bank_registers *banks;
+	const struct pinctrl_pin_desc *pins;
+	const char * const *groups;
+
+	u32 nbanks;
+	u32 npins;
+	u32 ngroups;
+
+	struct gpio_chip gpio_chip;
+	struct pinctrl_gpio_range gpio_range;
+};
+
+int wmt_pinctrl_probe(struct platform_device *pdev,
+		      struct wmt_pinctrl_data *data);
+int wmt_pinctrl_remove(struct platform_device *pdev);
-- 
1.7.9.5



From linux at prisktech.co.nz  Tue Apr  2 00:49:57 2013
From: linux at prisktech.co.nz (Tony Prisk)
Date: Tue,  2 Apr 2013 17:49:57 +1300
Subject: [PATCHv2 3/6] video: vt8500: Correct descriptions in video/Kconfig
In-Reply-To: <1364878200-26343-1-git-send-email-linux@prisktech.co.nz>
References: <1364878200-26343-1-git-send-email-linux@prisktech.co.nz>
Message-ID: <1364878200-26343-4-git-send-email-linux@prisktech.co.nz>

This patch corrects the descriptions for the VIA VT8500 and
Wondermedia WM8xxx-series framebuffer drivers to correctly reflect
which hardware they support.

Signed-off-by: Tony Prisk <linux at prisktech.co.nz>
Reviewed-by: Jean-Christophe Plagniol-Villard <plagnioj at jcrosoft.com>
---
 drivers/video/Kconfig |   11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 661aa54..ad762ed 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -1789,7 +1789,7 @@ config FB_AU1200
 	  option au1200fb:panel=<name>.
 
 config FB_VT8500
-	bool "VT8500 LCD Driver"
+	bool "VIA VT8500 framebuffer support"
 	depends on (FB = y) && ARM && ARCH_VT8500
 	select FB_SYS_FILLRECT if (!FB_WMT_GE_ROPS)
 	select FB_SYS_COPYAREA if (!FB_WMT_GE_ROPS)
@@ -1799,17 +1799,18 @@ config FB_VT8500
 	  controller.
 
 config FB_WM8505
-	bool "WM8505 frame buffer support"
+	bool "Wondermedia WM8xxx-series frame buffer support"
 	depends on (FB = y) && ARM && ARCH_VT8500
 	select FB_SYS_FILLRECT if (!FB_WMT_GE_ROPS)
 	select FB_SYS_COPYAREA if (!FB_WMT_GE_ROPS)
 	select FB_SYS_IMAGEBLIT
 	help
-	  This is the framebuffer driver for WonderMedia WM8505/WM8650
-	  integrated LCD controller.
+	  This is the framebuffer driver for WonderMedia WM8xxx-series
+	  integrated LCD controller. This driver covers the WM8505, WM8650
+	  and WM8850 SoCs.
 
 config FB_WMT_GE_ROPS
-	bool "VT8500/WM85xx accelerated raster ops support"
+	bool "VT8500/WM8xxx accelerated raster ops support"
 	depends on (FB = y) && (FB_VT8500 || FB_WM8505)
 	default n
 	help
-- 
1.7.9.5



From linux at prisktech.co.nz  Tue Apr  2 00:49:58 2013
From: linux at prisktech.co.nz (Tony Prisk)
Date: Tue,  2 Apr 2013 17:49:58 +1300
Subject: [PATCHv2 4/6] drivers/video/wm8505fb.c: use devm_ functions
In-Reply-To: <1364878200-26343-1-git-send-email-linux@prisktech.co.nz>
References: <1364878200-26343-1-git-send-email-linux@prisktech.co.nz>
Message-ID: <1364878200-26343-5-git-send-email-linux@prisktech.co.nz>

From: Julia Lawall <Julia.Lawall at lip6.fr>

The various devm_ functions allocate memory that is released when a driver
detaches.  This patch uses these functions for data that is allocated in
the probe function of a platform device and is only freed in the remove
function.

The patch makes some other cleanups.  First, the original code used
devm_kzalloc, but kfree.  This would lead to a double free.  The problem
was found using the following semantic match (http://coccinelle.lip6.fr/):

// <smpl>
@@
expression x,e;
@@
x = devm_kzalloc(...)
... when != x = e
?-kfree(x,...);
// </smpl>

The error-handing code of devm_request_and_ioremap does not print any
warning message, because devm_request_and_ioremap does this.

The call to dma_alloc_coherent is converted to its devm equivalent,
dmam_alloc_coherent.  This implicitly introduces a call to
dmam_free_coherent, which was completly missing in the original code.

A semicolon is removed at the end of the error-handling code for the call
to dma_alloc_coherent.

The block of code calling fb_alloc_cmap is moved below the block of code
calling wm8505fb_set_par, so that the error-handing code of the call to
wm8505fb_set_par can just return ret.  This way there is only one block of
error-handling code that needs to call fb_dealloc_cmap, and so this is
moved up to the place where it is needed, eliminating the need for all
gotos and labels in the function.  This was suggested by Tony Prisk.

The initializations of fbi and ret at the beginning of the function are not
necessary and are removed.  The call platform_set_drvdata(pdev, NULL); at
the end of the function is also removed.

Signed-off-by: Julia Lawall <Julia.Lawall at lip6.fr>
Signed-off-by: Tony Prisk <linux at prisktech.co.nz>
Reviewed-by: Jean-Christophe Plagniol-Villard <plagnioj at jcrosoft.com>
---
 drivers/video/wm8505fb.c |   79 +++++++++++-----------------------------------
 1 file changed, 19 insertions(+), 60 deletions(-)

diff --git a/drivers/video/wm8505fb.c b/drivers/video/wm8505fb.c
index ce23a00..b94ebc9 100644
--- a/drivers/video/wm8505fb.c
+++ b/drivers/video/wm8505fb.c
@@ -287,15 +287,11 @@ static int wm8505fb_probe(struct platform_device *pdev)
 	unsigned long fb_mem_len;
 	void *fb_mem_virt;
 
-	ret = -ENOMEM;
-	fbi = NULL;
-
 	fbi = devm_kzalloc(&pdev->dev, sizeof(struct wm8505fb_info) +
 			sizeof(u32) * 16, GFP_KERNEL);
 	if (!fbi) {
 		dev_err(&pdev->dev, "Failed to initialize framebuffer device\n");
-		ret = -ENOMEM;
-		goto failed;
+		return -ENOMEM;
 	}
 
 	strcpy(fbi->fb.fix.id, DRIVER_NAME);
@@ -321,31 +317,14 @@ static int wm8505fb_probe(struct platform_device *pdev)
 	fbi->fb.pseudo_palette	= addr;
 
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-	if (res == NULL) {
-		dev_err(&pdev->dev, "no I/O memory resource defined\n");
-		ret = -ENODEV;
-		goto failed_fbi;
-	}
-
-	res = request_mem_region(res->start, resource_size(res), DRIVER_NAME);
-	if (res == NULL) {
-		dev_err(&pdev->dev, "failed to request I/O memory\n");
-		ret = -EBUSY;
-		goto failed_fbi;
-	}
-
-	fbi->regbase = ioremap(res->start, resource_size(res));
-	if (fbi->regbase == NULL) {
-		dev_err(&pdev->dev, "failed to map I/O memory\n");
-		ret = -EBUSY;
-		goto failed_free_res;
-	}
+	fbi->regbase = devm_request_and_ioremap(&pdev->dev, res);
+	if (fbi->regbase == NULL)
+		return -EBUSY;
 
 	np = of_parse_phandle(pdev->dev.of_node, "default-mode", 0);
 	if (!np) {
 		pr_err("%s: No display description in Device Tree\n", __func__);
-		ret = -EINVAL;
-		goto failed_free_res;
+		return -EINVAL;
 	}
 
 	/*
@@ -364,7 +343,7 @@ static int wm8505fb_probe(struct platform_device *pdev)
 	ret |= of_property_read_u32(np, "bpp", &bpp);
 	if (ret) {
 		pr_err("%s: Unable to read display properties\n", __func__);
-		goto failed_free_res;
+		return -EINVAL;
 	}
 
 	of_mode.vmode = FB_VMODE_NONINTERLACED;
@@ -378,12 +357,12 @@ static int wm8505fb_probe(struct platform_device *pdev)
 
 	/* try allocating the framebuffer */
 	fb_mem_len = of_mode.xres * of_mode.yres * 2 * (bpp / 8);
-	fb_mem_virt = dma_alloc_coherent(&pdev->dev, fb_mem_len, &fb_mem_phys,
+	fb_mem_virt = dmam_alloc_coherent(&pdev->dev, fb_mem_len, &fb_mem_phys,
 				GFP_KERNEL);
 	if (!fb_mem_virt) {
 		pr_err("%s: Failed to allocate framebuffer\n", __func__);
 		return -ENOMEM;
-	};
+	}
 
 	fbi->fb.var.xres_virtual	= of_mode.xres;
 	fbi->fb.var.yres_virtual	= of_mode.yres * 2;
@@ -394,28 +373,29 @@ static int wm8505fb_probe(struct platform_device *pdev)
 	fbi->fb.screen_base		= fb_mem_virt;
 	fbi->fb.screen_size		= fb_mem_len;
 
-	if (fb_alloc_cmap(&fbi->fb.cmap, 256, 0) < 0) {
-		dev_err(&pdev->dev, "Failed to allocate color map\n");
-		ret = -ENOMEM;
-		goto failed_free_io;
-	}
-
-	wm8505fb_init_hw(&fbi->fb);
-
 	fbi->contrast = 0x80;
 	ret = wm8505fb_set_par(&fbi->fb);
 	if (ret) {
 		dev_err(&pdev->dev, "Failed to set parameters\n");
-		goto failed_free_cmap;
+		return ret;
 	}
 
+	if (fb_alloc_cmap(&fbi->fb.cmap, 256, 0) < 0) {
+		dev_err(&pdev->dev, "Failed to allocate color map\n");
+		return -ENOMEM;
+	}
+
+	wm8505fb_init_hw(&fbi->fb);
+
 	platform_set_drvdata(pdev, fbi);
 
 	ret = register_framebuffer(&fbi->fb);
 	if (ret < 0) {
 		dev_err(&pdev->dev,
 			"Failed to register framebuffer device: %d\n", ret);
-		goto failed_free_cmap;
+		if (fbi->fb.cmap.len)
+			fb_dealloc_cmap(&fbi->fb.cmap);
+		return ret;
 	}
 
 	ret = device_create_file(&pdev->dev, &dev_attr_contrast);
@@ -429,25 +409,11 @@ static int wm8505fb_probe(struct platform_device *pdev)
 	       fbi->fb.fix.smem_start + fbi->fb.fix.smem_len - 1);
 
 	return 0;
-
-failed_free_cmap:
-	if (fbi->fb.cmap.len)
-		fb_dealloc_cmap(&fbi->fb.cmap);
-failed_free_io:
-	iounmap(fbi->regbase);
-failed_free_res:
-	release_mem_region(res->start, resource_size(res));
-failed_fbi:
-	platform_set_drvdata(pdev, NULL);
-	kfree(fbi);
-failed:
-	return ret;
 }
 
 static int wm8505fb_remove(struct platform_device *pdev)
 {
 	struct wm8505fb_info *fbi = platform_get_drvdata(pdev);
-	struct resource *res;
 
 	device_remove_file(&pdev->dev, &dev_attr_contrast);
 
@@ -458,13 +424,6 @@ static int wm8505fb_remove(struct platform_device *pdev)
 	if (fbi->fb.cmap.len)
 		fb_dealloc_cmap(&fbi->fb.cmap);
 
-	iounmap(fbi->regbase);
-
-	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-	release_mem_region(res->start, resource_size(res));
-
-	kfree(fbi);
-
 	return 0;
 }
 
-- 
1.7.9.5



From linux at prisktech.co.nz  Tue Apr  2 00:49:54 2013
From: linux at prisktech.co.nz (Tony Prisk)
Date: Tue,  2 Apr 2013 17:49:54 +1300
Subject: [PATCHv2 0/6] fb: vt8500: patches for 3.10
Message-ID: <1364878200-26343-1-git-send-email-linux@prisktech.co.nz>

V2 Changes:
Split the SoC and board portions of the binding into their respective files.
Removed the forced non-interlaced code from wm8505fb.c and vt8500lcdfb.c

Julia Lawall (1):
  drivers/video/wm8505fb.c: use devm_ functions

Tony Prisk (5):
  video: vt8500: Make wmt_ge_rops optional
  video: vt8500: Remove unused platform_data/video-vt8500lcdfb.h
  video: vt8500: Correct descriptions in video/Kconfig
  video: vt8500: Adjust contrast in wm8505 framebuffer driver.
  video: fb: vt8500: Convert framebuffer drivers to standardized
    binding

 .../devicetree/bindings/video/via,vt8500-fb.txt    |   48 ++----
 .../devicetree/bindings/video/wm,wm8505-fb.txt     |   32 ++--
 arch/arm/boot/dts/vt8500-bv07.dts                  |   34 ++---
 arch/arm/boot/dts/vt8500.dtsi                      |    4 +-
 arch/arm/boot/dts/wm8505-ref.dts                   |   34 ++---
 arch/arm/boot/dts/wm8505.dtsi                      |    4 +-
 arch/arm/boot/dts/wm8650-mid.dts                   |   36 +++--
 arch/arm/boot/dts/wm8650.dtsi                      |    4 +-
 arch/arm/boot/dts/wm8850-w70v2.dts                 |   40 +++--
 arch/arm/boot/dts/wm8850.dtsi                      |    4 +-
 drivers/video/Kconfig                              |   37 +++--
 drivers/video/vt8500lcdfb.c                        |   70 ++++-----
 drivers/video/wm8505fb.c                           |  159 ++++++++------------
 include/linux/platform_data/video-vt8500lcdfb.h    |   31 ----
 14 files changed, 218 insertions(+), 319 deletions(-)
 delete mode 100644 include/linux/platform_data/video-vt8500lcdfb.h

-- 
1.7.9.5



From linux at prisktech.co.nz  Tue Apr  2 00:49:56 2013
From: linux at prisktech.co.nz (Tony Prisk)
Date: Tue,  2 Apr 2013 17:49:56 +1300
Subject: [PATCHv2 2/6] video: vt8500: Remove unused
 platform_data/video-vt8500lcdfb.h
In-Reply-To: <1364878200-26343-1-git-send-email-linux@prisktech.co.nz>
References: <1364878200-26343-1-git-send-email-linux@prisktech.co.nz>
Message-ID: <1364878200-26343-3-git-send-email-linux@prisktech.co.nz>

With the conversion to devicetree only for arch-vt8500, this
header is no longer required. This patch removes the #include
from the two framebuffer drivers that used it, and the header file.

Signed-off-by: Tony Prisk <linux at prisktech.co.nz>
Reviewed-by: Jean-Christophe Plagniol-Villard <plagnioj at jcrosoft.com>
---
 drivers/video/vt8500lcdfb.c                     |    2 --
 drivers/video/wm8505fb.c                        |    2 --
 include/linux/platform_data/video-vt8500lcdfb.h |   31 -----------------------
 3 files changed, 35 deletions(-)
 delete mode 100644 include/linux/platform_data/video-vt8500lcdfb.h

diff --git a/drivers/video/vt8500lcdfb.c b/drivers/video/vt8500lcdfb.c
index d8cc1f6..1c34821 100644
--- a/drivers/video/vt8500lcdfb.c
+++ b/drivers/video/vt8500lcdfb.c
@@ -30,8 +30,6 @@
 #include <linux/platform_device.h>
 #include <linux/wait.h>
 
-#include <linux/platform_data/video-vt8500lcdfb.h>
-
 #include "vt8500lcdfb.h"
 
 #ifdef CONFIG_FB_WMT_GE_ROPS
diff --git a/drivers/video/wm8505fb.c b/drivers/video/wm8505fb.c
index db49803..ce23a00 100644
--- a/drivers/video/wm8505fb.c
+++ b/drivers/video/wm8505fb.c
@@ -32,8 +32,6 @@
 #include <linux/of_fdt.h>
 #include <linux/memblock.h>
 
-#include <linux/platform_data/video-vt8500lcdfb.h>
-
 #include "wm8505fb_regs.h"
 
 #ifdef CONFIG_FB_WMT_GE_ROPS
diff --git a/include/linux/platform_data/video-vt8500lcdfb.h b/include/linux/platform_data/video-vt8500lcdfb.h
deleted file mode 100644
index 7f399c3..0000000
--- a/include/linux/platform_data/video-vt8500lcdfb.h
+++ /dev/null
@@ -1,31 +0,0 @@
-/*
- *  VT8500/WM8505 Frame Buffer platform data definitions
- *
- *  Copyright (C) 2010 Ed Spiridonov <edo.rus at gmail.com>
- *
- * This software is licensed under the terms of the GNU General Public
- * License version 2, as published by the Free Software Foundation, and
- * may be copied, distributed, and modified under those terms.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- */
-
-#ifndef _VT8500FB_H
-#define _VT8500FB_H
-
-#include <linux/fb.h>
-
-struct vt8500fb_platform_data {
-	struct fb_videomode	mode;
-	u32			xres_virtual;
-	u32			yres_virtual;
-	u32			bpp;
-	unsigned long		video_mem_phys;
-	void			*video_mem_virt;
-	unsigned long		video_mem_len;
-};
-
-#endif /* _VT8500FB_H */
-- 
1.7.9.5



From linux at prisktech.co.nz  Tue Apr  2 00:49:59 2013
From: linux at prisktech.co.nz (Tony Prisk)
Date: Tue,  2 Apr 2013 17:49:59 +1300
Subject: [PATCHv2 5/6] video: vt8500: Adjust contrast in wm8505 framebuffer
 driver.
In-Reply-To: <1364878200-26343-1-git-send-email-linux@prisktech.co.nz>
References: <1364878200-26343-1-git-send-email-linux@prisktech.co.nz>
Message-ID: <1364878200-26343-6-git-send-email-linux@prisktech.co.nz>

The contrast value was typo'd on the original commit (0x80 instead of
0x08). Following feedback from an enduser, a value of 0x10 seems more
suitable due to the default backlight being <100%.

Signed-off-by: Tony Prisk <linux at prisktech.co.nz>
Reviewed-by: Jean-Christophe Plagniol-Villard <plagnioj at jcrosoft.com>
---
 drivers/video/wm8505fb.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/wm8505fb.c b/drivers/video/wm8505fb.c
index b94ebc9..5057457 100644
--- a/drivers/video/wm8505fb.c
+++ b/drivers/video/wm8505fb.c
@@ -373,7 +373,7 @@ static int wm8505fb_probe(struct platform_device *pdev)
 	fbi->fb.screen_base		= fb_mem_virt;
 	fbi->fb.screen_size		= fb_mem_len;
 
-	fbi->contrast = 0x80;
+	fbi->contrast = 0x10;
 	ret = wm8505fb_set_par(&fbi->fb);
 	if (ret) {
 		dev_err(&pdev->dev, "Failed to set parameters\n");
-- 
1.7.9.5



From linux at prisktech.co.nz  Tue Apr  2 00:49:55 2013
From: linux at prisktech.co.nz (Tony Prisk)
Date: Tue,  2 Apr 2013 17:49:55 +1300
Subject: [PATCHv2 1/6] video: vt8500: Make wmt_ge_rops optional
In-Reply-To: <1364878200-26343-1-git-send-email-linux@prisktech.co.nz>
References: <1364878200-26343-1-git-send-email-linux@prisktech.co.nz>
Message-ID: <1364878200-26343-2-git-send-email-linux@prisktech.co.nz>

wmt_ge_rops is a seperate driver to vt8500/wm8505 framebuffer
driver but is currently a required option. This patch makes
accelerated raster ops optional.

Signed-off-by: Tony Prisk <linux at prisktech.co.nz>
Reviewed-by: Jean-Christophe Plagniol-Villard <plagnioj at jcrosoft.com>
---
 drivers/video/Kconfig       |   22 ++++++++++++----------
 drivers/video/vt8500lcdfb.c |   15 +++++++++++++++
 drivers/video/wm8505fb.c    |   15 +++++++++++++++
 3 files changed, 42 insertions(+), 10 deletions(-)

diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 4c1546f..661aa54 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -212,14 +212,6 @@ config FB_SYS_FOPS
        depends on FB
        default n
 
-config FB_WMT_GE_ROPS
-	tristate
-	depends on FB
-	default n
-	---help---
-	  Include functions for accelerated rectangle filling and area
-	  copying using WonderMedia Graphics Engine operations.
-
 config FB_DEFERRED_IO
 	bool
 	depends on FB
@@ -1799,7 +1791,8 @@ config FB_AU1200
 config FB_VT8500
 	bool "VT8500 LCD Driver"
 	depends on (FB = y) && ARM && ARCH_VT8500
-	select FB_WMT_GE_ROPS
+	select FB_SYS_FILLRECT if (!FB_WMT_GE_ROPS)
+	select FB_SYS_COPYAREA if (!FB_WMT_GE_ROPS)
 	select FB_SYS_IMAGEBLIT
 	help
 	  This is the framebuffer driver for VIA VT8500 integrated LCD
@@ -1808,12 +1801,21 @@ config FB_VT8500
 config FB_WM8505
 	bool "WM8505 frame buffer support"
 	depends on (FB = y) && ARM && ARCH_VT8500
-	select FB_WMT_GE_ROPS
+	select FB_SYS_FILLRECT if (!FB_WMT_GE_ROPS)
+	select FB_SYS_COPYAREA if (!FB_WMT_GE_ROPS)
 	select FB_SYS_IMAGEBLIT
 	help
 	  This is the framebuffer driver for WonderMedia WM8505/WM8650
 	  integrated LCD controller.
 
+config FB_WMT_GE_ROPS
+	bool "VT8500/WM85xx accelerated raster ops support"
+	depends on (FB = y) && (FB_VT8500 || FB_WM8505)
+	default n
+	help
+	  This adds support for accelerated raster operations on the
+	  VIA VT8500 and Wondermedia 85xx series SoCs.
+
 source "drivers/video/geode/Kconfig"
 
 config FB_HIT
diff --git a/drivers/video/vt8500lcdfb.c b/drivers/video/vt8500lcdfb.c
index aa2579c..d8cc1f6 100644
--- a/drivers/video/vt8500lcdfb.c
+++ b/drivers/video/vt8500lcdfb.c
@@ -33,7 +33,10 @@
 #include <linux/platform_data/video-vt8500lcdfb.h>
 
 #include "vt8500lcdfb.h"
+
+#ifdef CONFIG_FB_WMT_GE_ROPS
 #include "wmt_ge_rops.h"
+#endif
 
 #ifdef CONFIG_OF
 #include <linux/of.h>
@@ -249,12 +252,24 @@ static int vt8500lcd_blank(int blank, struct fb_info *info)
 	return 0;
 }
 
+#ifndef CONFIG_FB_WMT_GE_ROPS
+static int wmt_ge_sync(struct fb_info *p)
+{
+	return 0;
+}
+#endif
+
 static struct fb_ops vt8500lcd_ops = {
 	.owner		= THIS_MODULE,
 	.fb_set_par	= vt8500lcd_set_par,
 	.fb_setcolreg	= vt8500lcd_setcolreg,
+#ifdef CONFIG_FB_WMT_GE_ROPS
 	.fb_fillrect	= wmt_ge_fillrect,
 	.fb_copyarea	= wmt_ge_copyarea,
+#else
+	.fb_fillrect	= sys_fillrect,
+	.fb_copyarea	= sys_copyarea,
+#endif
 	.fb_imageblit	= sys_imageblit,
 	.fb_sync	= wmt_ge_sync,
 	.fb_ioctl	= vt8500lcd_ioctl,
diff --git a/drivers/video/wm8505fb.c b/drivers/video/wm8505fb.c
index 4dd0580..db49803 100644
--- a/drivers/video/wm8505fb.c
+++ b/drivers/video/wm8505fb.c
@@ -35,7 +35,10 @@
 #include <linux/platform_data/video-vt8500lcdfb.h>
 
 #include "wm8505fb_regs.h"
+
+#ifdef CONFIG_FB_WMT_GE_ROPS
 #include "wmt_ge_rops.h"
+#endif
 
 #define DRIVER_NAME "wm8505-fb"
 
@@ -248,12 +251,24 @@ static int wm8505fb_blank(int blank, struct fb_info *info)
 	return 0;
 }
 
+#ifndef CONFIG_FB_WMT_GE_ROPS
+static int wmt_ge_sync(struct fb_info *p)
+{
+	return 0;
+}
+#endif
+
 static struct fb_ops wm8505fb_ops = {
 	.owner		= THIS_MODULE,
 	.fb_set_par	= wm8505fb_set_par,
 	.fb_setcolreg	= wm8505fb_setcolreg,
+#ifdef CONFIG_FB_WMT_GE_ROPS
 	.fb_fillrect	= wmt_ge_fillrect,
 	.fb_copyarea	= wmt_ge_copyarea,
+#else
+	.fb_fillrect	= sys_fillrect,
+	.fb_copyarea	= sys_copyarea,
+#endif
 	.fb_imageblit	= sys_imageblit,
 	.fb_sync	= wmt_ge_sync,
 	.fb_pan_display	= wm8505fb_pan_display,
-- 
1.7.9.5



From linux at prisktech.co.nz  Tue Apr  2 00:50:00 2013
From: linux at prisktech.co.nz (Tony Prisk)
Date: Tue,  2 Apr 2013 17:50:00 +1300
Subject: [PATCHv2 6/6] video: fb: vt8500: Convert framebuffer drivers to
 standardized binding
In-Reply-To: <1364878200-26343-1-git-send-email-linux@prisktech.co.nz>
References: <1364878200-26343-1-git-send-email-linux@prisktech.co.nz>
Message-ID: <1364878200-26343-7-git-send-email-linux@prisktech.co.nz>

Now that a display timing binding is available, convert our almost identical
binding to use the standard binding.

This patch converts the vt8500 and wm8505 framebuffer drivers and
associated dts/dtsi files to use the standard binding as defined in
bindings/video/display-timing.txt.

There are two side-effects of making this conversion:

1) The fb node should now be in the board file, rather than the soc file as
the display-timing node is a child of the fb node.

2) We still require a bits per pixel property to initialize the framebuffer
for the different lcd panels. Rather than including this as part of the
display timing, it is moved into the framebuffer node.

I have also taken the opportunity to alphabetise the includes of each
driver to avoid double-ups.

Signed-off-by: Tony Prisk <linux at prisktech.co.nz>
Reviewed-by: Jean-Christophe Plagniol-Villard <plagnioj at jcrosoft.com>
---
 .../devicetree/bindings/video/via,vt8500-fb.txt    |   48 ++++----------
 .../devicetree/bindings/video/wm,wm8505-fb.txt     |   32 ++++++----
 arch/arm/boot/dts/vt8500-bv07.dts                  |   34 +++++-----
 arch/arm/boot/dts/vt8500.dtsi                      |    4 +-
 arch/arm/boot/dts/wm8505-ref.dts                   |   34 +++++-----
 arch/arm/boot/dts/wm8505.dtsi                      |    4 +-
 arch/arm/boot/dts/wm8650-mid.dts                   |   36 +++++------
 arch/arm/boot/dts/wm8650.dtsi                      |    4 +-
 arch/arm/boot/dts/wm8850-w70v2.dts                 |   40 ++++++------
 arch/arm/boot/dts/wm8850.dtsi                      |    4 +-
 drivers/video/Kconfig                              |    6 ++
 drivers/video/vt8500lcdfb.c                        |   53 ++++++----------
 drivers/video/wm8505fb.c                           |   67 ++++++++------------
 13 files changed, 154 insertions(+), 212 deletions(-)

diff --git a/Documentation/devicetree/bindings/video/via,vt8500-fb.txt b/Documentation/devicetree/bindings/video/via,vt8500-fb.txt
index c870b64..2871e21 100644
--- a/Documentation/devicetree/bindings/video/via,vt8500-fb.txt
+++ b/Documentation/devicetree/bindings/video/via,vt8500-fb.txt
@@ -5,58 +5,32 @@ Required properties:
 - compatible : "via,vt8500-fb"
 - reg : Should contain 1 register ranges(address and length)
 - interrupts : framebuffer controller interrupt
-- display: a phandle pointing to the display node
+- bits-per-pixel : bit depth of framebuffer (16 or 32)
 
-Required nodes:
-- display: a display node is required to initialize the lcd panel
-	This should be in the board dts.
-- default-mode: a videomode within the display with timing parameters
-	as specified below.
+Required subnodes:
+- display-timings: see display-timing.txt for information
 
 Example:
 
-	fb at d800e400 {
+	fb at d8050800 {
 		compatible = "via,vt8500-fb";
 		reg = <0xd800e400 0x400>;
 		interrupts = <12>;
-		display = <&display>;
-		default-mode = <&mode0>;
-	};
-
-VIA VT8500 Display
------------------------------------------------------
-Required properties (as per of_videomode_helper):
-
- - hactive, vactive: Display resolution
- - hfront-porch, hback-porch, hsync-len: Horizontal Display timing parameters
-   in pixels
-   vfront-porch, vback-porch, vsync-len: Vertical display timing parameters in
-   lines
- - clock: displayclock in Hz
- - bpp: lcd panel bit-depth.
-	<16> for RGB565, <32> for RGB888
-
-Optional properties (as per of_videomode_helper):
- - width-mm, height-mm: Display dimensions in mm
- - hsync-active-high (bool): Hsync pulse is active high
- - vsync-active-high (bool): Vsync pulse is active high
- - interlaced (bool): This is an interlaced mode
- - doublescan (bool): This is a doublescan mode
+		bits-per-pixel = <16>;
 
-Example:
-	display: display at 0 {
-		modes {
-			mode0: mode at 0 {
+		display-timings {
+			native-mode = <&timing0>;
+			timing0: 800x480 {
+				clock-frequency = <0>; /* unused but required */
 				hactive = <800>;
 				vactive = <480>;
-				hback-porch = <88>;
 				hfront-porch = <40>;
+				hback-porch = <88>;
 				hsync-len = <0>;
 				vback-porch = <32>;
 				vfront-porch = <11>;
 				vsync-len = <1>;
-				clock = <0>;	/* unused but required */
-				bpp = <16>;	/* non-standard but required */
 			};
 		};
 	};
+
diff --git a/Documentation/devicetree/bindings/video/wm,wm8505-fb.txt b/Documentation/devicetree/bindings/video/wm,wm8505-fb.txt
index 3d325e1..0bcadb2 100644
--- a/Documentation/devicetree/bindings/video/wm,wm8505-fb.txt
+++ b/Documentation/devicetree/bindings/video/wm,wm8505-fb.txt
@@ -4,20 +4,30 @@ Wondermedia WM8505 Framebuffer
 Required properties:
 - compatible : "wm,wm8505-fb"
 - reg : Should contain 1 register ranges(address and length)
-- via,display: a phandle pointing to the display node
+- bits-per-pixel : bit depth of framebuffer (16 or 32)
 
-Required nodes:
-- display: a display node is required to initialize the lcd panel
-	This should be in the board dts. See definition in
-	Documentation/devicetree/bindings/video/via,vt8500-fb.txt
-- default-mode: a videomode node as specified in
-	Documentation/devicetree/bindings/video/via,vt8500-fb.txt
+Required subnodes:
+- display-timings: see display-timing.txt for information
 
 Example:
 
-	fb at d8050800 {
+	fb at d8051700 {
 		compatible = "wm,wm8505-fb";
-		reg = <0xd8050800 0x200>;
-		display = <&display>;
-		default-mode = <&mode0>;
+		reg = <0xd8051700 0x200>;
+		bits-per-pixel = <16>;
+
+		display-timings {
+			native-mode = <&timing0>;
+			timing0: 800x480 {
+				clock-frequency = <0>; /* unused but required */
+				hactive = <800>;
+				vactive = <480>;
+				hfront-porch = <40>;
+				hback-porch = <88>;
+				hsync-len = <0>;
+				vback-porch = <32>;
+				vfront-porch = <11>;
+				vsync-len = <1>;
+			};
+		};
 	};
diff --git a/arch/arm/boot/dts/vt8500-bv07.dts b/arch/arm/boot/dts/vt8500-bv07.dts
index 567cf4e..877b33a 100644
--- a/arch/arm/boot/dts/vt8500-bv07.dts
+++ b/arch/arm/boot/dts/vt8500-bv07.dts
@@ -11,26 +11,22 @@
 
 / {
 	model = "Benign BV07 Netbook";
+};
 
-	/*
-	 * Display node is based on Sascha Hauer's patch on dri-devel.
-	 * Added a bpp property to calculate the size of the framebuffer
-	 * until the binding is formalized.
-	 */
-	display: display at 0 {
-		modes {
-			mode0: mode at 0 {
-				hactive = <800>;
-				vactive = <480>;
-				hback-porch = <88>;
-				hfront-porch = <40>;
-				hsync-len = <0>;
-				vback-porch = <32>;
-				vfront-porch = <11>;
-				vsync-len = <1>;
-				clock = <0>;	/* unused but required */
-				bpp = <16>;	/* non-standard but required */
-			};
+&fb {
+	bits-per-pixel = <16>;
+	display-timings {
+		native-mode = <&timing0>;
+		timing0: 800x480 {
+			clock-frequency = <0>; /* unused but required */
+			hactive = <800>;
+			vactive = <480>;
+			hfront-porch = <40>;
+			hback-porch = <88>;
+			hsync-len = <0>;
+			vback-porch = <32>;
+			vfront-porch = <11>;
+			vsync-len = <1>;
 		};
 	};
 };
diff --git a/arch/arm/boot/dts/vt8500.dtsi b/arch/arm/boot/dts/vt8500.dtsi
index cf31ced..68c8dc6 100644
--- a/arch/arm/boot/dts/vt8500.dtsi
+++ b/arch/arm/boot/dts/vt8500.dtsi
@@ -98,12 +98,10 @@
 			interrupts = <43>;
 		};
 
-		fb at d800e400 {
+		fb: fb at d8050800 {
 			compatible = "via,vt8500-fb";
 			reg = <0xd800e400 0x400>;
 			interrupts = <12>;
-			display = <&display>;
-			default-mode = <&mode0>;
 		};
 
 		ge_rops at d8050400 {
diff --git a/arch/arm/boot/dts/wm8505-ref.dts b/arch/arm/boot/dts/wm8505-ref.dts
index fd4e248..edd2cec 100644
--- a/arch/arm/boot/dts/wm8505-ref.dts
+++ b/arch/arm/boot/dts/wm8505-ref.dts
@@ -11,26 +11,22 @@
 
 / {
 	model = "Wondermedia WM8505 Netbook";
+};
 
-	/*
-	 * Display node is based on Sascha Hauer's patch on dri-devel.
-	 * Added a bpp property to calculate the size of the framebuffer
-	 * until the binding is formalized.
-	 */
-	display: display at 0 {
-		modes {
-			mode0: mode at 0 {
-				hactive = <800>;
-				vactive = <480>;
-				hback-porch = <88>;
-				hfront-porch = <40>;
-				hsync-len = <0>;
-				vback-porch = <32>;
-				vfront-porch = <11>;
-				vsync-len = <1>;
-				clock = <0>;	/* unused but required */
-				bpp = <32>;	/* non-standard but required */
-			};
+&fb {
+	bits-per-pixel = <32>;
+	display-timings {
+		native-mode = <&timing0>;
+		timing0: 800x480 {
+			clock-frequency = <0>; /* unused but required */
+			hactive = <800>;
+			vactive = <480>;
+			hfront-porch = <40>;
+			hback-porch = <88>;
+			hsync-len = <0>;
+			vback-porch = <32>;
+			vfront-porch = <11>;
+			vsync-len = <1>;
 		};
 	};
 };
diff --git a/arch/arm/boot/dts/wm8505.dtsi b/arch/arm/boot/dts/wm8505.dtsi
index e74a1c0..bcf668d 100644
--- a/arch/arm/boot/dts/wm8505.dtsi
+++ b/arch/arm/boot/dts/wm8505.dtsi
@@ -128,11 +128,9 @@
 			interrupts = <0>;
 		};
 
-		fb at d8050800 {
+		fb: fb at d8050800 {
 			compatible = "wm,wm8505-fb";
 			reg = <0xd8050800 0x200>;
-			display = <&display>;
-			default-mode = <&mode0>;
 		};
 
 		ge_rops at d8050400 {
diff --git a/arch/arm/boot/dts/wm8650-mid.dts b/arch/arm/boot/dts/wm8650-mid.dts
index cefd938..61671a0 100644
--- a/arch/arm/boot/dts/wm8650-mid.dts
+++ b/arch/arm/boot/dts/wm8650-mid.dts
@@ -11,26 +11,24 @@
 
 / {
 	model = "Wondermedia WM8650-MID Tablet";
+};
+
+&fb {
+	bits-per-pixel = <16>;
 
-	/*
-	 * Display node is based on Sascha Hauer's patch on dri-devel.
-	 * Added a bpp property to calculate the size of the framebuffer
-	 * until the binding is formalized.
-	 */
-	display: display at 0 {
-		modes {
-			mode0: mode at 0 {
-				hactive = <800>;
-				vactive = <480>;
-				hback-porch = <88>;
-				hfront-porch = <40>;
-				hsync-len = <0>;
-				vback-porch = <32>;
-				vfront-porch = <11>;
-				vsync-len = <1>;
-				clock = <0>;	/* unused but required */
-				bpp = <16>;	/* non-standard but required */
-			};
+	display-timings {
+		native-mode = <&timing0>;
+		timing0: 800x480 {
+			clock-frequency = <0>; /* unused but required */
+			hactive = <800>;
+			vactive = <480>;
+			hfront-porch = <40>;
+			hback-porch = <88>;
+			hsync-len = <0>;
+			vback-porch = <32>;
+			vfront-porch = <11>;
+			vsync-len = <1>;
 		};
 	};
 };
+
diff --git a/arch/arm/boot/dts/wm8650.dtsi b/arch/arm/boot/dts/wm8650.dtsi
index db3c0a1..9313407 100644
--- a/arch/arm/boot/dts/wm8650.dtsi
+++ b/arch/arm/boot/dts/wm8650.dtsi
@@ -128,11 +128,9 @@
 			interrupts = <43>;
 		};
 
-		fb at d8050800 {
+		fb: fb at d8050800 {
 			compatible = "wm,wm8505-fb";
 			reg = <0xd8050800 0x200>;
-			display = <&display>;
-			default-mode = <&mode0>;
 		};
 
 		ge_rops at d8050400 {
diff --git a/arch/arm/boot/dts/wm8850-w70v2.dts b/arch/arm/boot/dts/wm8850-w70v2.dts
index fcc660c..32d2253 100644
--- a/arch/arm/boot/dts/wm8850-w70v2.dts
+++ b/arch/arm/boot/dts/wm8850-w70v2.dts
@@ -15,28 +15,6 @@
 / {
 	model = "Wondermedia WM8850-W70v2 Tablet";
 
-	/*
-	 * Display node is based on Sascha Hauer's patch on dri-devel.
-	 * Added a bpp property to calculate the size of the framebuffer
-	 * until the binding is formalized.
-	 */
-	display: display at 0 {
-		modes {
-			mode0: mode at 0 {
-				hactive = <800>;
-				vactive = <480>;
-				hback-porch = <88>;
-				hfront-porch = <40>;
-				hsync-len = <0>;
-				vback-porch = <32>;
-				vfront-porch = <11>;
-				vsync-len = <1>;
-				clock = <0>;	/* unused but required */
-				bpp = <16>;	/* non-standard but required */
-			};
-		};
-	};
-
 	backlight {
 		compatible = "pwm-backlight";
 		pwms = <&pwm 0 50000 1>;	/* duty inverted */
@@ -45,3 +23,21 @@
 		default-brightness-level = <5>;
 	};
 };
+
+&fb {
+	bits-per-pixel = <16>;
+	display-timings {
+		native-mode = <&timing0>;
+		timing0: 800x480 {
+			clock-frequency = <0>; /* unused but required */
+			hactive = <800>;
+			vactive = <480>;
+			hfront-porch = <40>;
+			hback-porch = <88>;
+			hsync-len = <0>;
+			vback-porch = <32>;
+			vfront-porch = <11>;
+			vsync-len = <1>;
+		};
+	};
+};
diff --git a/arch/arm/boot/dts/wm8850.dtsi b/arch/arm/boot/dts/wm8850.dtsi
index e8cbfdc..7149cd1 100644
--- a/arch/arm/boot/dts/wm8850.dtsi
+++ b/arch/arm/boot/dts/wm8850.dtsi
@@ -135,11 +135,9 @@
 			};
 		};
 
-		fb at d8051700 {
+		fb: fb at d8051700 {
 			compatible = "wm,wm8505-fb";
 			reg = <0xd8051700 0x200>;
-			display = <&display>;
-			default-mode = <&mode0>;
 		};
 
 		ge_rops at d8050400 {
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index ad762ed..d0c932a 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -1794,6 +1794,9 @@ config FB_VT8500
 	select FB_SYS_FILLRECT if (!FB_WMT_GE_ROPS)
 	select FB_SYS_COPYAREA if (!FB_WMT_GE_ROPS)
 	select FB_SYS_IMAGEBLIT
+	select FB_MODE_HELPERS
+	select OF_DISPLAY_TIMING
+	select OF_VIDEOMODE
 	help
 	  This is the framebuffer driver for VIA VT8500 integrated LCD
 	  controller.
@@ -1804,6 +1807,9 @@ config FB_WM8505
 	select FB_SYS_FILLRECT if (!FB_WMT_GE_ROPS)
 	select FB_SYS_COPYAREA if (!FB_WMT_GE_ROPS)
 	select FB_SYS_IMAGEBLIT
+	select FB_MODE_HELPERS
+	select OF_DISPLAY_TIMING
+	select OF_VIDEOMODE
 	help
 	  This is the framebuffer driver for WonderMedia WM8xxx-series
 	  integrated LCD controller. This driver covers the WM8505, WM8650
diff --git a/drivers/video/vt8500lcdfb.c b/drivers/video/vt8500lcdfb.c
index 1c34821..6bba262 100644
--- a/drivers/video/vt8500lcdfb.c
+++ b/drivers/video/vt8500lcdfb.c
@@ -15,20 +15,21 @@
  * GNU General Public License for more details.
  */
 
-#include <linux/module.h>
-#include <linux/kernel.h>
-#include <linux/errno.h>
-#include <linux/string.h>
-#include <linux/mm.h>
-#include <linux/slab.h>
 #include <linux/delay.h>
+#include <linux/dma-mapping.h>
+#include <linux/errno.h>
 #include <linux/fb.h>
 #include <linux/init.h>
 #include <linux/interrupt.h>
 #include <linux/io.h>
-#include <linux/dma-mapping.h>
+#include <linux/kernel.h>
+#include <linux/mm.h>
+#include <linux/module.h>
 #include <linux/platform_device.h>
+#include <linux/slab.h>
+#include <linux/string.h>
 #include <linux/wait.h>
+#include <video/of_display_timing.h>
 
 #include "vt8500lcdfb.h"
 
@@ -290,11 +291,11 @@ static int vt8500lcd_probe(struct platform_device *pdev)
 {
 	struct vt8500lcd_info *fbi;
 	struct resource *res;
+	struct display_timings *disp_timing;
 	void *addr;
 	int irq, ret;
 
 	struct fb_videomode	of_mode;
-	struct device_node	*np;
 	u32			bpp;
 	dma_addr_t fb_mem_phys;
 	unsigned long fb_mem_len;
@@ -359,32 +360,18 @@ static int vt8500lcd_probe(struct platform_device *pdev)
 		goto failed_free_res;
 	}
 
-	np = of_parse_phandle(pdev->dev.of_node, "default-mode", 0);
-	if (!np) {
-		pr_err("%s: No display description in Device Tree\n", __func__);
-		ret = -EINVAL;
-		goto failed_free_res;
-	}
+	disp_timing = of_get_display_timings(pdev->dev.of_node);
+	if (!disp_timing)
+		return -EINVAL;
 
-	/*
-	 * This code is copied from Sascha Hauer's of_videomode helper
-	 * and can be replaced with a call to the helper once mainlined
-	 */
-	ret = 0;
-	ret |= of_property_read_u32(np, "hactive", &of_mode.xres);
-	ret |= of_property_read_u32(np, "vactive", &of_mode.yres);
-	ret |= of_property_read_u32(np, "hback-porch", &of_mode.left_margin);
-	ret |= of_property_read_u32(np, "hfront-porch", &of_mode.right_margin);
-	ret |= of_property_read_u32(np, "hsync-len", &of_mode.hsync_len);
-	ret |= of_property_read_u32(np, "vback-porch", &of_mode.upper_margin);
-	ret |= of_property_read_u32(np, "vfront-porch", &of_mode.lower_margin);
-	ret |= of_property_read_u32(np, "vsync-len", &of_mode.vsync_len);
-	ret |= of_property_read_u32(np, "bpp", &bpp);
-	if (ret) {
-		pr_err("%s: Unable to read display properties\n", __func__);
-		goto failed_free_res;
-	}
-	of_mode.vmode = FB_VMODE_NONINTERLACED;
+	ret = of_get_fb_videomode(pdev->dev.of_node, &of_mode,
+							OF_USE_NATIVE_MODE);
+	if (ret)
+		return ret;
+
+	ret = of_property_read_u32(pdev->dev.of_node, "bits-per-pixel", &bpp);
+	if (ret)
+		return ret;
 
 	/* try allocating the framebuffer */
 	fb_mem_len = of_mode.xres * of_mode.yres * 2 * (bpp / 8);
diff --git a/drivers/video/wm8505fb.c b/drivers/video/wm8505fb.c
index 5057457..d571723 100644
--- a/drivers/video/wm8505fb.c
+++ b/drivers/video/wm8505fb.c
@@ -14,23 +14,24 @@
  * GNU General Public License for more details.
  */
 
-#include <linux/module.h>
-#include <linux/kernel.h>
-#include <linux/errno.h>
-#include <linux/string.h>
-#include <linux/mm.h>
-#include <linux/slab.h>
 #include <linux/delay.h>
+#include <linux/dma-mapping.h>
 #include <linux/fb.h>
+#include <linux/errno.h>
 #include <linux/init.h>
 #include <linux/interrupt.h>
 #include <linux/io.h>
-#include <linux/dma-mapping.h>
-#include <linux/platform_device.h>
-#include <linux/wait.h>
+#include <linux/kernel.h>
+#include <linux/memblock.h>
+#include <linux/mm.h>
+#include <linux/module.h>
 #include <linux/of.h>
 #include <linux/of_fdt.h>
-#include <linux/memblock.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+#include <linux/string.h>
+#include <linux/wait.h>
+#include <video/of_display_timing.h>
 
 #include "wm8505fb_regs.h"
 
@@ -276,12 +277,12 @@ static struct fb_ops wm8505fb_ops = {
 static int wm8505fb_probe(struct platform_device *pdev)
 {
 	struct wm8505fb_info	*fbi;
-	struct resource		*res;
+	struct resource	*res;
+	struct display_timings *disp_timing;
 	void			*addr;
 	int ret;
 
-	struct fb_videomode	of_mode;
-	struct device_node	*np;
+	struct fb_videomode	mode;
 	u32			bpp;
 	dma_addr_t fb_mem_phys;
 	unsigned long fb_mem_len;
@@ -321,33 +322,19 @@ static int wm8505fb_probe(struct platform_device *pdev)
 	if (fbi->regbase == NULL)
 		return -EBUSY;
 
-	np = of_parse_phandle(pdev->dev.of_node, "default-mode", 0);
-	if (!np) {
-		pr_err("%s: No display description in Device Tree\n", __func__);
+	disp_timing = of_get_display_timings(pdev->dev.of_node);
+	if (!disp_timing)
 		return -EINVAL;
-	}
 
-	/*
-	 * This code is copied from Sascha Hauer's of_videomode helper
-	 * and can be replaced with a call to the helper once mainlined
-	 */
-	ret = 0;
-	ret |= of_property_read_u32(np, "hactive", &of_mode.xres);
-	ret |= of_property_read_u32(np, "vactive", &of_mode.yres);
-	ret |= of_property_read_u32(np, "hback-porch", &of_mode.left_margin);
-	ret |= of_property_read_u32(np, "hfront-porch", &of_mode.right_margin);
-	ret |= of_property_read_u32(np, "hsync-len", &of_mode.hsync_len);
-	ret |= of_property_read_u32(np, "vback-porch", &of_mode.upper_margin);
-	ret |= of_property_read_u32(np, "vfront-porch", &of_mode.lower_margin);
-	ret |= of_property_read_u32(np, "vsync-len", &of_mode.vsync_len);
-	ret |= of_property_read_u32(np, "bpp", &bpp);
-	if (ret) {
-		pr_err("%s: Unable to read display properties\n", __func__);
-		return -EINVAL;
-	}
+	ret = of_get_fb_videomode(pdev->dev.of_node, &mode, OF_USE_NATIVE_MODE);
+	if (ret)
+		return ret;
+
+	ret = of_property_read_u32(pdev->dev.of_node, "bits-per-pixel", &bpp);
+	if (ret)
+		return ret;
 
-	of_mode.vmode = FB_VMODE_NONINTERLACED;
-	fb_videomode_to_var(&fbi->fb.var, &of_mode);
+	fb_videomode_to_var(&fbi->fb.var, &mode);
 
 	fbi->fb.var.nonstd		= 0;
 	fbi->fb.var.activate		= FB_ACTIVATE_NOW;
@@ -356,7 +343,7 @@ static int wm8505fb_probe(struct platform_device *pdev)
 	fbi->fb.var.width		= -1;
 
 	/* try allocating the framebuffer */
-	fb_mem_len = of_mode.xres * of_mode.yres * 2 * (bpp / 8);
+	fb_mem_len = mode.xres * mode.yres * 2 * (bpp / 8);
 	fb_mem_virt = dmam_alloc_coherent(&pdev->dev, fb_mem_len, &fb_mem_phys,
 				GFP_KERNEL);
 	if (!fb_mem_virt) {
@@ -364,8 +351,8 @@ static int wm8505fb_probe(struct platform_device *pdev)
 		return -ENOMEM;
 	}
 
-	fbi->fb.var.xres_virtual	= of_mode.xres;
-	fbi->fb.var.yres_virtual	= of_mode.yres * 2;
+	fbi->fb.var.xres_virtual	= mode.xres;
+	fbi->fb.var.yres_virtual	= mode.yres * 2;
 	fbi->fb.var.bits_per_pixel	= bpp;
 
 	fbi->fb.fix.smem_start		= fb_mem_phys;
-- 
1.7.9.5



From horms+renesas at verge.net.au  Tue Apr  2 01:07:00 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue,  2 Apr 2013 14:07:00 +0900
Subject: [PATCH 04/30] ARM: shmobile: r8a73a4 PFC support
In-Reply-To: <1364879246-9470-1-git-send-email-horms+renesas@verge.net.au>
References: <1364879246-9470-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364879246-9470-5-git-send-email-horms+renesas@verge.net.au>

From: Magnus Damm <damm at opensource.se>

Add a platform device for the r8a73a4 PFC.

Signed-off-by: Magnus Damm <damm at opensource.se>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/Kconfig                |    1 +
 arch/arm/mach-shmobile/include/mach/r8a73a4.h |    1 +
 arch/arm/mach-shmobile/setup-r8a73a4.c        |   10 ++++++++++
 3 files changed, 12 insertions(+)

diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index 17a59cd..0e4a820 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -20,6 +20,7 @@ config ARCH_SH73A0
 
 config ARCH_R8A73A4
 	bool "R-Mobile APE6 (R8A73A40)"
+	select ARCH_WANT_OPTIONAL_GPIOLIB
 	select ARM_GIC
 	select CPU_V7
 	select ARM_ARCH_TIMER
diff --git a/arch/arm/mach-shmobile/include/mach/r8a73a4.h b/arch/arm/mach-shmobile/include/mach/r8a73a4.h
index 6db3495..f043103 100644
--- a/arch/arm/mach-shmobile/include/mach/r8a73a4.h
+++ b/arch/arm/mach-shmobile/include/mach/r8a73a4.h
@@ -3,5 +3,6 @@
 
 void r8a73a4_add_standard_devices(void);
 void r8a73a4_clock_init(void);
+void r8a73a4_pinmux_init(void);
 
 #endif /* __ASM_R8A73A4_H__ */
diff --git a/arch/arm/mach-shmobile/setup-r8a73a4.c b/arch/arm/mach-shmobile/setup-r8a73a4.c
index da5ae16..c2d86f3 100644
--- a/arch/arm/mach-shmobile/setup-r8a73a4.c
+++ b/arch/arm/mach-shmobile/setup-r8a73a4.c
@@ -28,6 +28,16 @@
 #include <mach/r8a73a4.h>
 #include <asm/mach/arch.h>
 
+static const struct resource pfc_resources[] = {
+	DEFINE_RES_MEM(0xe6050000, 0x9000),
+};
+
+void __init r8a73a4_pinmux_init(void)
+{
+	platform_device_register_simple("pfc-r8a73a4", -1, pfc_resources,
+					ARRAY_SIZE(pfc_resources));
+}
+
 #define SCIF_COMMON(scif_type, baseaddr, irq)			\
 	.type		= scif_type,				\
 	.mapbase	= baseaddr,				\
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 01:06:58 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue,  2 Apr 2013 14:06:58 +0900
Subject: [PATCH 02/30] ARM: shmobile: r8a73a4 SCIF support V3
In-Reply-To: <1364879246-9470-1-git-send-email-horms+renesas@verge.net.au>
References: <1364879246-9470-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364879246-9470-3-git-send-email-horms+renesas@verge.net.au>

From: Magnus Damm <damm at opensource.se>

V3 of SCIF serial port support for the r8a73a4 SoC.
This is done by adding platform devices for SCIFA0
-> SCIFA1 as well as SCIFB0 -> SCIFB3 together with
clock bindings. DT device description is excluded at
this point since such bindings are still under
development.

Signed-off-by: Magnus Damm <damm at opensource.se>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/clock-r8a73a4.c |   15 ++++++++++-
 arch/arm/mach-shmobile/setup-r8a73a4.c |   43 ++++++++++++++++++++++++++++++++
 2 files changed, 57 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-shmobile/clock-r8a73a4.c b/arch/arm/mach-shmobile/clock-r8a73a4.c
index 15d479d..037713b 100644
--- a/arch/arm/mach-shmobile/clock-r8a73a4.c
+++ b/arch/arm/mach-shmobile/clock-r8a73a4.c
@@ -28,6 +28,7 @@
 #define CPG_LEN 0x270
 
 #define MPCKCR 0xe6150080
+#define SMSTPCR2 0xe6150138
 
 static struct clk_mapping cpg_mapping = {
 	.phys   = CPG_BASE,
@@ -55,11 +56,23 @@ static struct clk *main_clks[] = {
 	&extal2_clk,
 };
 
-enum { MSTP_NR };
+enum { MSTP217, MSTP216, MSTP207, MSTP206, MSTP204, MSTP203, MSTP_NR };
 static struct clk mstp_clks[MSTP_NR] = {
+	[MSTP204] = SH_CLK_MSTP32(&extal2_clk, SMSTPCR2, 4, 0), /* SCIFA0 */
+	[MSTP203] = SH_CLK_MSTP32(&extal2_clk, SMSTPCR2, 3, 0), /* SCIFA1 */
+	[MSTP206] = SH_CLK_MSTP32(&extal2_clk, SMSTPCR2, 6, 0), /* SCIFB0 */
+	[MSTP207] = SH_CLK_MSTP32(&extal2_clk, SMSTPCR2, 7, 0), /* SCIFB1 */
+	[MSTP216] = SH_CLK_MSTP32(&extal2_clk, SMSTPCR2, 16, 0), /* SCIFB2 */
+	[MSTP217] = SH_CLK_MSTP32(&extal2_clk, SMSTPCR2, 17, 0), /* SCIFB3 */
 };
 
 static struct clk_lookup lookups[] = {
+	CLKDEV_DEV_ID("sh-sci.0", &mstp_clks[MSTP204]),
+	CLKDEV_DEV_ID("sh-sci.1", &mstp_clks[MSTP203]),
+	CLKDEV_DEV_ID("sh-sci.2", &mstp_clks[MSTP206]),
+	CLKDEV_DEV_ID("sh-sci.3", &mstp_clks[MSTP207]),
+	CLKDEV_DEV_ID("sh-sci.4", &mstp_clks[MSTP216]),
+	CLKDEV_DEV_ID("sh-sci.5", &mstp_clks[MSTP217]),
 };
 
 void __init r8a73a4_clock_init(void)
diff --git a/arch/arm/mach-shmobile/setup-r8a73a4.c b/arch/arm/mach-shmobile/setup-r8a73a4.c
index 69156bc..746a3dc 100644
--- a/arch/arm/mach-shmobile/setup-r8a73a4.c
+++ b/arch/arm/mach-shmobile/setup-r8a73a4.c
@@ -21,13 +21,56 @@
 #include <linux/irqchip.h>
 #include <linux/kernel.h>
 #include <linux/of_platform.h>
+#include <linux/serial_sci.h>
 #include <mach/common.h>
 #include <mach/irqs.h>
 #include <mach/r8a73a4.h>
 #include <asm/mach/arch.h>
 
+#define SCIF_COMMON(scif_type, baseaddr, irq)			\
+	.type		= scif_type,				\
+	.mapbase	= baseaddr,				\
+	.flags		= UPF_BOOT_AUTOCONF | UPF_IOREMAP,	\
+	.scbrr_algo_id	= SCBRR_ALGO_4,				\
+	.irqs		= SCIx_IRQ_MUXED(irq)
+
+#define SCIFA_DATA(index, baseaddr, irq)		\
+[index] = {						\
+	SCIF_COMMON(PORT_SCIFA, baseaddr, irq),		\
+	.scscr = SCSCR_RE | SCSCR_TE | SCSCR_CKE0,	\
+}
+
+#define SCIFB_DATA(index, baseaddr, irq)	\
+[index] = {					\
+	SCIF_COMMON(PORT_SCIFB, baseaddr, irq),	\
+	.scscr = SCSCR_RE | SCSCR_TE,		\
+}
+
+enum { SCIFA0, SCIFA1, SCIFB0, SCIFB1, SCIFB2, SCIFB3 };
+
+static const struct plat_sci_port scif[] = {
+	SCIFA_DATA(SCIFA0, 0xe6c40000, gic_spi(144)), /* SCIFA0 */
+	SCIFA_DATA(SCIFA1, 0xe6c50000, gic_spi(145)), /* SCIFA1 */
+	SCIFB_DATA(SCIFB0, 0xe6c50000, gic_spi(145)), /* SCIFB0 */
+	SCIFB_DATA(SCIFB1, 0xe6c30000, gic_spi(149)), /* SCIFB1 */
+	SCIFB_DATA(SCIFB2, 0xe6ce0000, gic_spi(150)), /* SCIFB2 */
+	SCIFB_DATA(SCIFB3, 0xe6cf0000, gic_spi(151)), /* SCIFB3 */
+};
+
+static inline void r8a73a4_register_scif(int idx)
+{
+	platform_device_register_data(&platform_bus, "sh-sci", idx, &scif[idx],
+				      sizeof(struct plat_sci_port));
+}
+
 void __init r8a73a4_add_standard_devices(void)
 {
+	r8a73a4_register_scif(SCIFA0);
+	r8a73a4_register_scif(SCIFA1);
+	r8a73a4_register_scif(SCIFB0);
+	r8a73a4_register_scif(SCIFB1);
+	r8a73a4_register_scif(SCIFB2);
+	r8a73a4_register_scif(SCIFB3);
 }
 
 #ifdef CONFIG_USE_OF
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 01:06:56 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue,  2 Apr 2013 14:06:56 +0900
Subject: [GIT PULL] Renesas ARM SoC updates for v3.10 #2
Message-ID: <1364879246-9470-1-git-send-email-horms+renesas@verge.net.au>

Hi Arnd, Hi Olof,

The following changes since commit 4c82e452732784419fd616cf1acf2bc9b004aae1:

  Merge tag 'renesas-intc-external-irq2-for-v3.10' into soc-base (2013-04-02 10:55:57 +0900)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-soc2-for-v3.10

for you to fetch changes up to 8585deb18580d04209a2986430aa0959ef38fce2:

  ARM: shmobile: r8a7790 SoC 64-bit DT support (2013-04-02 11:02:21 +0900)

----------------------------------------------------------------
Second round of Renesas ARM SoC updates for v3.10

Some Highlights:

* Add r8a7790 SoC
* Add r8a73a4 SoC
* Migrate r8a7740 SoC from INTC to GIC
* Add thermal driver support to r8a73a4 SoC
* Add irqpin DT nodes to sh73a0 SoC
* Add SCIF support to r8a7778 SoC

This pull request is based on a merge of:
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas renesas-soc-for-v3.10
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas renesas-intc-external-irq2-for-v3.10

----------------------------------------------------------------
Bastian Hecht (1):
      ARM: shmobile: r8a7740: Migrate from INTC to GIC

Guennadi Liakhovetski (3):
      ARM: shmobile: sh73a0: wait for completion when kicking the clock
      ARM: shmobile: sh73a0: add irqpin DT nodes
      ARM: shmobile: sh73a0: add a TWD clock

Kuninori Morimoto (15):
      ARM: shmobile: add R8A7778 basis support
      ARM: shmobile: r8a7778 SCIF support
      ARM: shmobile: r8a73a4: add thermal driver support
      ARM: shmobile: sh73a0: remove DIV4_ZT* clocks
      ARM: shmobile: sh7372: remove DIV4_ZT* clocks
      ARM: shmobile: add struct clk_ratio and fixed ratio clock macro
      ARM: shmobile: sh7372: use fixed ratio clock
      ARM: shmobile: sh73a0: use fixed ratio clock
      ARM: shmobile: r8a7740: tidyup comment/implementation mismatch
      ARM: shmobile: r8a7740: use fixed ratio clock
      ARM: shmobile: r8a7779: remove DIV4 clocks and use fixed ratio clock
      ARM: shmobile: sh7372: move global functions to sh7372.h
      ARM: shmobile: sh73a0: move global functions to sh73a0.h
      ARM: shmobile: r8a7740: move global functions to r8a7740.h
      ARM: shmobile: r8a7779: move global functions to r8a7779.h

Magnus Damm (9):
      ARM: shmobile: Initial r8a73a4 SoC support V3
      ARM: shmobile: r8a73a4 SCIF support V3
      ARM: shmobile: r8a73a4 IRQC support V2
      ARM: shmobile: r8a73a4 PFC support
      ARM: shmobile: Disallow PINCTRL without GPIOLIB
      ARM: shmobile: Initial r8a7790 SoC support
      ARM: shmobile: r8a7790 SCIF support
      ARM: shmobile: r8a7790 IRQC support
      ARM: shmobile: r8a7790 PFC support

Takashi YOSHII (2):
      ARM: shmobile: r8a73a4 SoC 64-bit DT support
      ARM: shmobile: r8a7790 SoC 64-bit DT support

 arch/arm/Kconfig                               |    2 +-
 arch/arm/boot/dts/r8a73a4.dtsi                 |   94 ++++
 arch/arm/boot/dts/r8a7778.dtsi                 |   35 ++
 arch/arm/boot/dts/r8a7790.dtsi                 |   63 +++
 arch/arm/boot/dts/sh73a0.dtsi                  |   81 +++
 arch/arm/mach-shmobile/Kconfig                 |   26 +
 arch/arm/mach-shmobile/Makefile                |    3 +
 arch/arm/mach-shmobile/board-armadillo800eva.c |   35 +-
 arch/arm/mach-shmobile/clock-r8a73a4.c         |  115 +++++
 arch/arm/mach-shmobile/clock-r8a7740.c         |  114 ++---
 arch/arm/mach-shmobile/clock-r8a7778.c         |  104 ++++
 arch/arm/mach-shmobile/clock-r8a7779.c         |  196 ++++----
 arch/arm/mach-shmobile/clock-r8a7790.c         |   93 ++++
 arch/arm/mach-shmobile/clock-sh7372.c          |   50 +-
 arch/arm/mach-shmobile/clock-sh73a0.c          |  115 ++---
 arch/arm/mach-shmobile/clock.c                 |   13 +
 arch/arm/mach-shmobile/include/mach/clock.h    |   39 ++
 arch/arm/mach-shmobile/include/mach/common.h   |   54 --
 arch/arm/mach-shmobile/include/mach/r8a73a4.h  |    8 +
 arch/arm/mach-shmobile/include/mach/r8a7740.h  |    9 +
 arch/arm/mach-shmobile/include/mach/r8a7778.h  |   28 ++
 arch/arm/mach-shmobile/include/mach/r8a7779.h  |   13 +
 arch/arm/mach-shmobile/include/mach/r8a7790.h  |    8 +
 arch/arm/mach-shmobile/include/mach/sh7372.h   |   12 +
 arch/arm/mach-shmobile/include/mach/sh73a0.h   |   15 +
 arch/arm/mach-shmobile/intc-r8a7740.c          |  641 ++----------------------
 arch/arm/mach-shmobile/setup-r8a73a4.c         |  202 ++++++++
 arch/arm/mach-shmobile/setup-r8a7740.c         |  192 +++++--
 arch/arm/mach-shmobile/setup-r8a7778.c         |  193 +++++++
 arch/arm/mach-shmobile/setup-r8a7790.c         |  137 +++++
 drivers/pinctrl/sh-pfc/pfc-r8a7740.c           |   64 +--
 31 files changed, 1732 insertions(+), 1022 deletions(-)
 create mode 100644 arch/arm/boot/dts/r8a73a4.dtsi
 create mode 100644 arch/arm/boot/dts/r8a7778.dtsi
 create mode 100644 arch/arm/boot/dts/r8a7790.dtsi
 create mode 100644 arch/arm/mach-shmobile/clock-r8a73a4.c
 create mode 100644 arch/arm/mach-shmobile/clock-r8a7778.c
 create mode 100644 arch/arm/mach-shmobile/clock-r8a7790.c
 create mode 100644 arch/arm/mach-shmobile/include/mach/clock.h
 create mode 100644 arch/arm/mach-shmobile/include/mach/r8a73a4.h
 create mode 100644 arch/arm/mach-shmobile/include/mach/r8a7778.h
 create mode 100644 arch/arm/mach-shmobile/include/mach/r8a7790.h
 create mode 100644 arch/arm/mach-shmobile/setup-r8a73a4.c
 create mode 100644 arch/arm/mach-shmobile/setup-r8a7778.c
 create mode 100644 arch/arm/mach-shmobile/setup-r8a7790.c


From horms+renesas at verge.net.au  Tue Apr  2 01:06:59 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue,  2 Apr 2013 14:06:59 +0900
Subject: [PATCH 03/30] ARM: shmobile: r8a73a4 IRQC support V2
In-Reply-To: <1364879246-9470-1-git-send-email-horms+renesas@verge.net.au>
References: <1364879246-9470-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364879246-9470-4-git-send-email-horms+renesas@verge.net.au>

From: Magnus Damm <damm at opensource.se>

Add IRQC interrupt controller support to r8a73a4 by
hooking up two IRQC instances to handle 58 external
IRQ signals. There IRQC controllers are tied to SPIs
of the GIC. On r8a73a4 exact IRQ pin routing is handled
by the PFC which is excluded from this patch.

Both platform devices and DT devices are added in this
patch. The platform device versions are used to provide
a static interrupt map configuration for board code
written in C.

Signed-off-by: Magnus Damm <damm at opensource.se>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a73a4.dtsi         |   32 ++++++++++++
 arch/arm/mach-shmobile/Kconfig         |    1 +
 arch/arm/mach-shmobile/setup-r8a73a4.c |   84 ++++++++++++++++++++++++++++++++
 3 files changed, 117 insertions(+)

diff --git a/arch/arm/boot/dts/r8a73a4.dtsi b/arch/arm/boot/dts/r8a73a4.dtsi
index 72c58c1..4c68ba1 100644
--- a/arch/arm/boot/dts/r8a73a4.dtsi
+++ b/arch/arm/boot/dts/r8a73a4.dtsi
@@ -52,4 +52,36 @@
 				<1 11 0xf08>,
 				<1 10 0xf08>;
 	};
+
+	irqc0: interrupt-controller at e61c0000 {
+		compatible = "renesas,irqc";
+		#interrupt-cells = <2>;
+		interrupt-controller;
+		reg = <0xe61c0000 0x200>;
+		interrupt-parent = <&gic>;
+		interrupts = <0 0 4>, <0 1 4>, <0 2 4>,	<0 3 4>,
+				<0 4 4>, <0 5 4>, <0 6 4>, <0 7 4>,
+				<0 8 4>, <0 9 4>, <0 10 4>, <0 11 4>,
+				<0 12 4>, <0 13 4>, <0 14 4>, <0 15 4>,
+				<0 16 4>, <0 17 4>, <0 18 4>, <0 19 4>,
+				<0 20 4>, <0 21 4>, <0 22 4>, <0 23 4>,
+				<0 24 4>, <0 25 4>, <0 26 4>, <0 27 4>,
+				<0 28 4>, <0 29 4>, <0 30 4>, <0 31 4>;
+	};
+
+	irqc1: interrupt-controller at e61c0200 {
+		compatible = "renesas,irqc";
+		#interrupt-cells = <2>;
+		interrupt-controller;
+		reg = <0xe61c0200 0x200>;
+		interrupt-parent = <&gic>;
+		interrupts = <0 32 4>, <0 33 4>, <0 34 4>, <0 35 4>,
+				<0 36 4>, <0 37 4>, <0 38 4>, <0 39 4>,
+				<0 40 4>, <0 41 4>, <0 42 4>, <0 43 4>,
+				<0 44 4>, <0 45 4>, <0 46 4>, <0 47 4>,
+				<0 48 4>, <0 49 4>, <0 50 4>, <0 51 4>,
+				<0 52 4>, <0 53 4>, <0 54 4>, <0 55 4>,
+				<0 56 4>, <0 57 4>;
+	};
+
 };
diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index 663d27b..17a59cd 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -24,6 +24,7 @@ config ARCH_R8A73A4
 	select CPU_V7
 	select ARM_ARCH_TIMER
 	select SH_CLK_CPG
+	select RENESAS_IRQC
 
 config ARCH_R8A7740
 	bool "R-Mobile A1 (R8A77400)"
diff --git a/arch/arm/mach-shmobile/setup-r8a73a4.c b/arch/arm/mach-shmobile/setup-r8a73a4.c
index 746a3dc..da5ae16 100644
--- a/arch/arm/mach-shmobile/setup-r8a73a4.c
+++ b/arch/arm/mach-shmobile/setup-r8a73a4.c
@@ -21,6 +21,7 @@
 #include <linux/irqchip.h>
 #include <linux/kernel.h>
 #include <linux/of_platform.h>
+#include <linux/platform_data/irq-renesas-irqc.h>
 #include <linux/serial_sci.h>
 #include <mach/common.h>
 #include <mach/irqs.h>
@@ -63,6 +64,87 @@ static inline void r8a73a4_register_scif(int idx)
 				      sizeof(struct plat_sci_port));
 }
 
+static const struct renesas_irqc_config irqc0_data = {
+	.irq_base = irq_pin(0), /* IRQ0 -> IRQ31 */
+};
+
+static const struct resource irqc0_resources[] = {
+	DEFINE_RES_MEM(0xe61c0000, 0x200), /* IRQC Event Detector Block_0 */
+	DEFINE_RES_IRQ(gic_spi(0)), /* IRQ0 */
+	DEFINE_RES_IRQ(gic_spi(1)), /* IRQ1 */
+	DEFINE_RES_IRQ(gic_spi(2)), /* IRQ2 */
+	DEFINE_RES_IRQ(gic_spi(3)), /* IRQ3 */
+	DEFINE_RES_IRQ(gic_spi(4)), /* IRQ4 */
+	DEFINE_RES_IRQ(gic_spi(5)), /* IRQ5 */
+	DEFINE_RES_IRQ(gic_spi(6)), /* IRQ6 */
+	DEFINE_RES_IRQ(gic_spi(7)), /* IRQ7 */
+	DEFINE_RES_IRQ(gic_spi(8)), /* IRQ8 */
+	DEFINE_RES_IRQ(gic_spi(9)), /* IRQ9 */
+	DEFINE_RES_IRQ(gic_spi(10)), /* IRQ10 */
+	DEFINE_RES_IRQ(gic_spi(11)), /* IRQ11 */
+	DEFINE_RES_IRQ(gic_spi(12)), /* IRQ12 */
+	DEFINE_RES_IRQ(gic_spi(13)), /* IRQ13 */
+	DEFINE_RES_IRQ(gic_spi(14)), /* IRQ14 */
+	DEFINE_RES_IRQ(gic_spi(15)), /* IRQ15 */
+	DEFINE_RES_IRQ(gic_spi(16)), /* IRQ16 */
+	DEFINE_RES_IRQ(gic_spi(17)), /* IRQ17 */
+	DEFINE_RES_IRQ(gic_spi(18)), /* IRQ18 */
+	DEFINE_RES_IRQ(gic_spi(19)), /* IRQ19 */
+	DEFINE_RES_IRQ(gic_spi(20)), /* IRQ20 */
+	DEFINE_RES_IRQ(gic_spi(21)), /* IRQ21 */
+	DEFINE_RES_IRQ(gic_spi(22)), /* IRQ22 */
+	DEFINE_RES_IRQ(gic_spi(23)), /* IRQ23 */
+	DEFINE_RES_IRQ(gic_spi(24)), /* IRQ24 */
+	DEFINE_RES_IRQ(gic_spi(25)), /* IRQ25 */
+	DEFINE_RES_IRQ(gic_spi(26)), /* IRQ26 */
+	DEFINE_RES_IRQ(gic_spi(27)), /* IRQ27 */
+	DEFINE_RES_IRQ(gic_spi(28)), /* IRQ28 */
+	DEFINE_RES_IRQ(gic_spi(29)), /* IRQ29 */
+	DEFINE_RES_IRQ(gic_spi(30)), /* IRQ30 */
+	DEFINE_RES_IRQ(gic_spi(31)), /* IRQ31 */
+};
+
+static const struct renesas_irqc_config irqc1_data = {
+	.irq_base = irq_pin(32), /* IRQ32 -> IRQ57 */
+};
+
+static const struct resource irqc1_resources[] = {
+	DEFINE_RES_MEM(0xe61c0200, 0x200), /* IRQC Event Detector Block_1 */
+	DEFINE_RES_IRQ(gic_spi(32)), /* IRQ32 */
+	DEFINE_RES_IRQ(gic_spi(33)), /* IRQ33 */
+	DEFINE_RES_IRQ(gic_spi(34)), /* IRQ34 */
+	DEFINE_RES_IRQ(gic_spi(35)), /* IRQ35 */
+	DEFINE_RES_IRQ(gic_spi(36)), /* IRQ36 */
+	DEFINE_RES_IRQ(gic_spi(37)), /* IRQ37 */
+	DEFINE_RES_IRQ(gic_spi(38)), /* IRQ38 */
+	DEFINE_RES_IRQ(gic_spi(39)), /* IRQ39 */
+	DEFINE_RES_IRQ(gic_spi(40)), /* IRQ40 */
+	DEFINE_RES_IRQ(gic_spi(41)), /* IRQ41 */
+	DEFINE_RES_IRQ(gic_spi(42)), /* IRQ42 */
+	DEFINE_RES_IRQ(gic_spi(43)), /* IRQ43 */
+	DEFINE_RES_IRQ(gic_spi(44)), /* IRQ44 */
+	DEFINE_RES_IRQ(gic_spi(45)), /* IRQ45 */
+	DEFINE_RES_IRQ(gic_spi(46)), /* IRQ46 */
+	DEFINE_RES_IRQ(gic_spi(47)), /* IRQ47 */
+	DEFINE_RES_IRQ(gic_spi(48)), /* IRQ48 */
+	DEFINE_RES_IRQ(gic_spi(49)), /* IRQ49 */
+	DEFINE_RES_IRQ(gic_spi(50)), /* IRQ50 */
+	DEFINE_RES_IRQ(gic_spi(51)), /* IRQ51 */
+	DEFINE_RES_IRQ(gic_spi(52)), /* IRQ52 */
+	DEFINE_RES_IRQ(gic_spi(53)), /* IRQ53 */
+	DEFINE_RES_IRQ(gic_spi(54)), /* IRQ54 */
+	DEFINE_RES_IRQ(gic_spi(55)), /* IRQ55 */
+	DEFINE_RES_IRQ(gic_spi(56)), /* IRQ56 */
+	DEFINE_RES_IRQ(gic_spi(57)), /* IRQ57 */
+};
+
+#define r8a73a4_register_irqc(idx)					\
+	platform_device_register_resndata(&platform_bus, "renesas_irqc", \
+					  idx, irqc##idx##_resources,	\
+					  ARRAY_SIZE(irqc##idx##_resources), \
+					  &irqc##idx##_data,		\
+					  sizeof(struct renesas_irqc_config))
+
 void __init r8a73a4_add_standard_devices(void)
 {
 	r8a73a4_register_scif(SCIFA0);
@@ -71,6 +153,8 @@ void __init r8a73a4_add_standard_devices(void)
 	r8a73a4_register_scif(SCIFB1);
 	r8a73a4_register_scif(SCIFB2);
 	r8a73a4_register_scif(SCIFB3);
+	r8a73a4_register_irqc(0);
+	r8a73a4_register_irqc(1);
 }
 
 #ifdef CONFIG_USE_OF
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 01:07:04 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue,  2 Apr 2013 14:07:04 +0900
Subject: [PATCH 08/30] ARM: shmobile: sh73a0: add irqpin DT nodes
In-Reply-To: <1364879246-9470-1-git-send-email-horms+renesas@verge.net.au>
References: <1364879246-9470-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364879246-9470-9-git-send-email-horms+renesas@verge.net.au>

From: Guennadi Liakhovetski <g.liakhovetski at gmx.de>

Add DT nodes for the 4 irqpin interrupt controllers on sh73a0. We add them
to sh73a0.dtsi, which is also used by configurations, doing all their
device instantiation from board the .c code. We rely on the fact, that
such configurations don't instantiate devices from the device-tree.

Signed-off-by: Guennadi Liakhovetski <g.liakhovetski at gmx.de>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/sh73a0.dtsi |   81 +++++++++++++++++++++++++++++++++++++++++
 1 file changed, 81 insertions(+)

diff --git a/arch/arm/boot/dts/sh73a0.dtsi b/arch/arm/boot/dts/sh73a0.dtsi
index 8a59465..7e71e3a 100644
--- a/arch/arm/boot/dts/sh73a0.dtsi
+++ b/arch/arm/boot/dts/sh73a0.dtsi
@@ -38,6 +38,87 @@
 		      <0xf0000100 0x100>;
 	};
 
+	irqpin0: irqpin at e6900000 {
+		compatible = "renesas,intc-irqpin";
+		#interrupt-cells = <2>;
+		interrupt-controller;
+		reg = <0xe6900000 4>,
+			<0xe6900010 4>,
+			<0xe6900020 1>,
+			<0xe6900040 1>,
+			<0xe6900060 1>;
+		interrupt-parent = <&gic>;
+		interrupts = <0 1 0x4
+			      0 2 0x4
+			      0 3 0x4
+			      0 4 0x4
+			      0 5 0x4
+			      0 6 0x4
+			      0 7 0x4
+			      0 8 0x4>;
+	};
+
+	irqpin1: irqpin at e6900004 {
+		compatible = "renesas,intc-irqpin";
+		#interrupt-cells = <2>;
+		interrupt-controller;
+		reg = <0xe6900004 4>,
+			<0xe6900014 4>,
+			<0xe6900024 1>,
+			<0xe6900044 1>,
+			<0xe6900064 1>;
+		interrupt-parent = <&gic>;
+		interrupts = <0 9 0x4
+			      0 10 0x4
+			      0 11 0x4
+			      0 12 0x4
+			      0 13 0x4
+			      0 14 0x4
+			      0 15 0x4
+			      0 16 0x4>;
+		control-parent;
+	};
+
+	irqpin2: irqpin at e6900008 {
+		compatible = "renesas,intc-irqpin";
+		#interrupt-cells = <2>;
+		interrupt-controller;
+		reg = <0xe6900008 4>,
+			<0xe6900018 4>,
+			<0xe6900028 1>,
+			<0xe6900048 1>,
+			<0xe6900068 1>;
+		interrupt-parent = <&gic>;
+		interrupts = <0 17 0x4
+			      0 18 0x4
+			      0 19 0x4
+			      0 20 0x4
+			      0 21 0x4
+			      0 22 0x4
+			      0 23 0x4
+			      0 24 0x4>;
+	};
+
+	irqpin3: irqpin at e690000c {
+		compatible = "renesas,intc-irqpin";
+		#interrupt-cells = <2>;
+		interrupt-controller;
+		reg = <0xe690000c 4>,
+			<0xe690001c 4>,
+			<0xe690002c 1>,
+			<0xe690004c 1>,
+			<0xe690006c 1>;
+		interrupt-parent = <&gic>;
+		interrupts = <0 25 0x4
+			      0 26 0x4
+			      0 27 0x4
+			      0 28 0x4
+			      0 29 0x4
+			      0 30 0x4
+			      0 31 0x4
+			      0 32 0x4>;
+	};
+
 	i2c0: i2c at 0xe6820000 {
 		#address-cells = <1>;
 		#size-cells = <0>;
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 01:07:01 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue,  2 Apr 2013 14:07:01 +0900
Subject: [PATCH 05/30] ARM: shmobile: sh73a0: wait for completion when kicking
 the clock
In-Reply-To: <1364879246-9470-1-git-send-email-horms+renesas@verge.net.au>
References: <1364879246-9470-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364879246-9470-6-git-send-email-horms+renesas@verge.net.au>

From: Guennadi Liakhovetski <g.liakhovetski at gmx.de>

To reconfigure clocks, controlled by FRQCRA and FRQCRB, a kick bit has to
be set and to make sure the setting has taken effect, it has to be read
back repeatedly until it is cleared by the hardware. This patch adds the
waiting part, that was missing until now.

Signed-off-by: Guennadi Liakhovetski <g.liakhovetski at gmx.de>
Acked-by: Magnus Damm <damm at opensource.se
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/clock-sh73a0.c |   23 +++++++++++++++++------
 1 file changed, 17 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-shmobile/clock-sh73a0.c b/arch/arm/mach-shmobile/clock-sh73a0.c
index 71843dd..34b5c5a 100644
--- a/arch/arm/mach-shmobile/clock-sh73a0.c
+++ b/arch/arm/mach-shmobile/clock-sh73a0.c
@@ -21,6 +21,7 @@
 #include <linux/io.h>
 #include <linux/sh_clk.h>
 #include <linux/clkdev.h>
+#include <asm/processor.h>
 #include <mach/common.h>
 
 #define FRQCRA		IOMEM(0xe6150000)
@@ -234,14 +235,24 @@ static struct clk *main_clks[] = {
 	&sh73a0_extalr_clk,
 };
 
-static void div4_kick(struct clk *clk)
+static int frqcr_kick(void)
 {
-	unsigned long value;
+	int i;
+
+	/* set KICK bit in FRQCRB to update hardware setting, check success */
+	__raw_writel(__raw_readl(FRQCRB) | (1 << 31), FRQCRB);
+	for (i = 1000; i; i--)
+		if (__raw_readl(FRQCRB) & (1 << 31))
+			cpu_relax();
+		else
+			return i;
+
+	return -ETIMEDOUT;
+}
 
-	/* set KICK bit in FRQCRB to update hardware setting */
-	value = __raw_readl(FRQCRB);
-	value |= (1 << 31);
-	__raw_writel(value, FRQCRB);
+static void div4_kick(struct clk *clk)
+{
+	frqcr_kick();
 }
 
 static int divisors[] = { 2, 3, 4, 6, 8, 12, 16, 18,
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 01:06:57 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue,  2 Apr 2013 14:06:57 +0900
Subject: [PATCH 01/30] ARM: shmobile: Initial r8a73a4 SoC support V3
In-Reply-To: <1364879246-9470-1-git-send-email-horms+renesas@verge.net.au>
References: <1364879246-9470-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364879246-9470-2-git-send-email-horms+renesas@verge.net.au>

From: Magnus Damm <damm at opensource.se>

V3 of initial support for the r8a73a4 SoC including:
 - Single Cortex-A15 CPU Core
 - GIC
 - Architecture timer

No static virtual mappings are used, all the components
make use of ioremap(). DT_MACHINE_START is still wrapped
in CONFIG_USE_OF to match other mach-shmobile code.

Signed-off-by: Magnus Damm <damm at opensource.se>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a73a4.dtsi                |   55 +++++++++++++++
 arch/arm/mach-shmobile/Kconfig                |    7 ++
 arch/arm/mach-shmobile/Makefile               |    1 +
 arch/arm/mach-shmobile/clock-r8a73a4.c        |   91 +++++++++++++++++++++++++
 arch/arm/mach-shmobile/include/mach/r8a73a4.h |    7 ++
 arch/arm/mach-shmobile/setup-r8a73a4.c        |   50 ++++++++++++++
 6 files changed, 211 insertions(+)
 create mode 100644 arch/arm/boot/dts/r8a73a4.dtsi
 create mode 100644 arch/arm/mach-shmobile/clock-r8a73a4.c
 create mode 100644 arch/arm/mach-shmobile/include/mach/r8a73a4.h
 create mode 100644 arch/arm/mach-shmobile/setup-r8a73a4.c

diff --git a/arch/arm/boot/dts/r8a73a4.dtsi b/arch/arm/boot/dts/r8a73a4.dtsi
new file mode 100644
index 0000000..72c58c1
--- /dev/null
+++ b/arch/arm/boot/dts/r8a73a4.dtsi
@@ -0,0 +1,55 @@
+/*
+ * Device Tree Source for the r8a73a4 SoC
+ *
+ * Copyright (C) 2013 Renesas Solutions Corp.
+ * Copyright (C) 2013 Magnus Damm
+ *
+ * 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/ "skeleton.dtsi"
+
+/ {
+	compatible = "renesas,r8a73a4";
+	interrupt-parent = <&gic>;
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		cpu0: cpu at 0 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a15";
+			reg = <0>;
+			clock-frequency = <1500000000>;
+		};
+	};
+
+	gic: interrupt-controller at f1001000 {
+		compatible = "arm,cortex-a15-gic";
+		#interrupt-cells = <3>;
+		#address-cells = <0>;
+		interrupt-controller;
+		reg = <0xf1001000 0x1000>,
+			<0xf1002000 0x1000>,
+			<0xf1004000 0x2000>,
+			<0xf1006000 0x2000>;
+		interrupts = <1 9 0xf04>;
+
+		gic-cpuif at 4 {
+			compatible = "arm,gic-cpuif";
+			cpuif-id = <4>;
+			cpu = <&cpu0>;
+		};
+	};
+
+	timer {
+		compatible = "arm,armv7-timer";
+		interrupts = <1 13 0xf08>,
+				<1 14 0xf08>,
+				<1 11 0xf08>,
+				<1 10 0xf08>;
+	};
+};
diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index 75d413c..663d27b 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -18,6 +18,13 @@ config ARCH_SH73A0
 	select SH_CLK_CPG
 	select RENESAS_INTC_IRQPIN
 
+config ARCH_R8A73A4
+	bool "R-Mobile APE6 (R8A73A40)"
+	select ARM_GIC
+	select CPU_V7
+	select ARM_ARCH_TIMER
+	select SH_CLK_CPG
+
 config ARCH_R8A7740
 	bool "R-Mobile A1 (R8A77400)"
 	select ARCH_WANT_OPTIONAL_GPIOLIB
diff --git a/arch/arm/mach-shmobile/Makefile b/arch/arm/mach-shmobile/Makefile
index b646ff4..c5a43ef 100644
--- a/arch/arm/mach-shmobile/Makefile
+++ b/arch/arm/mach-shmobile/Makefile
@@ -8,6 +8,7 @@ obj-y				:= timer.o console.o clock.o
 # CPU objects
 obj-$(CONFIG_ARCH_SH7372)	+= setup-sh7372.o clock-sh7372.o intc-sh7372.o
 obj-$(CONFIG_ARCH_SH73A0)	+= setup-sh73a0.o clock-sh73a0.o intc-sh73a0.o
+obj-$(CONFIG_ARCH_R8A73A4)	+= setup-r8a73a4.o clock-r8a73a4.o
 obj-$(CONFIG_ARCH_R8A7740)	+= setup-r8a7740.o clock-r8a7740.o intc-r8a7740.o
 obj-$(CONFIG_ARCH_R8A7779)	+= setup-r8a7779.o clock-r8a7779.o intc-r8a7779.o
 obj-$(CONFIG_ARCH_EMEV2)	+= setup-emev2.o clock-emev2.o
diff --git a/arch/arm/mach-shmobile/clock-r8a73a4.c b/arch/arm/mach-shmobile/clock-r8a73a4.c
new file mode 100644
index 0000000..15d479d
--- /dev/null
+++ b/arch/arm/mach-shmobile/clock-r8a73a4.c
@@ -0,0 +1,91 @@
+/*
+ * r8a73a4 clock framework support
+ *
+ * Copyright (C) 2013  Renesas Solutions Corp.
+ * Copyright (C) 2013  Magnus Damm
+ *
+ * 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; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
+ */
+#include <linux/init.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/sh_clk.h>
+#include <linux/clkdev.h>
+#include <mach/common.h>
+
+#define CPG_BASE 0xe6150000
+#define CPG_LEN 0x270
+
+#define MPCKCR 0xe6150080
+
+static struct clk_mapping cpg_mapping = {
+	.phys   = CPG_BASE,
+	.len    = CPG_LEN,
+};
+
+static struct clk extalr_clk = {
+	.rate	= 32768,
+	.mapping	= &cpg_mapping,
+};
+
+static struct clk extal1_clk = {
+	.rate	= 26000000,
+	.mapping	= &cpg_mapping,
+};
+
+static struct clk extal2_clk = {
+	.rate	= 48000000,
+	.mapping	= &cpg_mapping,
+};
+
+static struct clk *main_clks[] = {
+	&extalr_clk,
+	&extal1_clk,
+	&extal2_clk,
+};
+
+enum { MSTP_NR };
+static struct clk mstp_clks[MSTP_NR] = {
+};
+
+static struct clk_lookup lookups[] = {
+};
+
+void __init r8a73a4_clock_init(void)
+{
+	void __iomem *cpg_base, *reg;
+	int k, ret = 0;
+
+	/* fix MPCLK to EXTAL2 for now.
+	 * this is needed until more detailed clock topology is supported
+	 */
+	cpg_base = ioremap_nocache(CPG_BASE, CPG_LEN);
+	BUG_ON(!cpg_base);
+	reg = cpg_base + (MPCKCR - CPG_BASE);
+	iowrite32(ioread32(reg) | 1 << 7 | 0x0c, reg); /* set CKSEL */
+	iounmap(cpg_base);
+
+	for (k = 0; !ret && (k < ARRAY_SIZE(main_clks)); k++)
+		ret = clk_register(main_clks[k]);
+
+	if (!ret)
+		ret = sh_clk_mstp_register(mstp_clks, MSTP_NR);
+
+	clkdev_add_table(lookups, ARRAY_SIZE(lookups));
+
+	if (!ret)
+		shmobile_clk_init();
+	else
+		panic("failed to setup r8a73a4 clocks\n");
+}
diff --git a/arch/arm/mach-shmobile/include/mach/r8a73a4.h b/arch/arm/mach-shmobile/include/mach/r8a73a4.h
new file mode 100644
index 0000000..6db3495
--- /dev/null
+++ b/arch/arm/mach-shmobile/include/mach/r8a73a4.h
@@ -0,0 +1,7 @@
+#ifndef __ASM_R8A73A4_H__
+#define __ASM_R8A73A4_H__
+
+void r8a73a4_add_standard_devices(void);
+void r8a73a4_clock_init(void);
+
+#endif /* __ASM_R8A73A4_H__ */
diff --git a/arch/arm/mach-shmobile/setup-r8a73a4.c b/arch/arm/mach-shmobile/setup-r8a73a4.c
new file mode 100644
index 0000000..69156bc
--- /dev/null
+++ b/arch/arm/mach-shmobile/setup-r8a73a4.c
@@ -0,0 +1,50 @@
+/*
+ * r8a73a4 processor support
+ *
+ * Copyright (C) 2013  Renesas Solutions Corp.
+ * Copyright (C) 2013  Magnus Damm
+ *
+ * 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; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
+ */
+#include <linux/irq.h>
+#include <linux/irqchip.h>
+#include <linux/kernel.h>
+#include <linux/of_platform.h>
+#include <mach/common.h>
+#include <mach/irqs.h>
+#include <mach/r8a73a4.h>
+#include <asm/mach/arch.h>
+
+void __init r8a73a4_add_standard_devices(void)
+{
+}
+
+#ifdef CONFIG_USE_OF
+void __init r8a73a4_add_standard_devices_dt(void)
+{
+	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
+}
+
+static const char *r8a73a4_boards_compat_dt[] __initdata = {
+	"renesas,r8a73a4",
+	NULL,
+};
+
+DT_MACHINE_START(R8A73A4_DT, "Generic R8A73A4 (Flattened Device Tree)")
+	.init_irq	= irqchip_init,
+	.init_machine	= r8a73a4_add_standard_devices_dt,
+	.init_time	= shmobile_timer_init,
+	.dt_compat	= r8a73a4_boards_compat_dt,
+MACHINE_END
+#endif /* CONFIG_USE_OF */
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 01:07:05 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue,  2 Apr 2013 14:07:05 +0900
Subject: [PATCH 09/30] ARM: shmobile: Disallow PINCTRL without GPIOLIB
In-Reply-To: <1364879246-9470-1-git-send-email-horms+renesas@verge.net.au>
References: <1364879246-9470-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364879246-9470-10-git-send-email-horms+renesas@verge.net.au>

From: Magnus Damm <damm at opensource.se>

Modify mach-shmobile to only select PINCTRL in case of
ARCH_WANT_OPTIONAL_GPIOLIB is set.

This fixes a build error triggered when adding a new SoC
lacking GPIO software support (ARCH_WANT_OPTIONAL_GPIOLIB=n):

 CC      drivers/tty/vt/keyboard.o
In file included from drivers/pinctrl/core.c:30:0:
include/asm-generic/gpio.h: In function 'gpio_get_value_cansleep':
include/asm-generic/gpio.h:270:2: error: implicit declaration of function '__gpio_get_value'
include/asm-generic/gpio.h: In function 'gpio_set_value_cansleep':
include/asm-generic/gpio.h:276:2: error: implicit declaration of function '__gpio_set_value'
drivers/pinctrl/core.c: In function 'pinctrl_ready_for_gpio_range':
drivers/pinctrl/core.c:297:9: error: implicit declaration of function 'gpio_to_chip'
drivers/pinctrl/core.c:297:27: warning: initialization makes pointer from integer without a cast
drivers/pinctrl/core.c:304:45: error: dereferencing pointer to incomplete type
drivers/pinctrl/core.c:305:26: error: dereferencing pointer to incomplete type
drivers/pinctrl/core.c:305:39: error: dereferencing pointer to incomplete type
make[2]: *** [drivers/pinctrl/core.o] Error 1
make[1]: *** [drivers/pinctrl] Error 2
make[1]: *** Waiting for unfinished jobs....
  LD      drivers/sh/built-in.o

Signed-off-by: Magnus Damm <damm at opensource.se>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/Kconfig |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 5b71469..b63902e 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -725,7 +725,7 @@ config ARCH_SHMOBILE
 	select MULTI_IRQ_HANDLER
 	select NEED_MACH_MEMORY_H
 	select NO_IOPORT
-	select PINCTRL
+	select PINCTRL if ARCH_WANT_OPTIONAL_GPIOLIB
 	select PM_GENERIC_DOMAINS if PM
 	select SPARSE_IRQ
 	help
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 01:07:08 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue,  2 Apr 2013 14:07:08 +0900
Subject: [PATCH 12/30] ARM: shmobile: sh73a0: add a TWD clock
In-Reply-To: <1364879246-9470-1-git-send-email-horms+renesas@verge.net.au>
References: <1364879246-9470-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364879246-9470-13-git-send-email-horms+renesas@verge.net.au>

From: Guennadi Liakhovetski <g.liakhovetski at gmx.de>

Add a TWD clock on sh73a0 for the smp_twd driver to properly update the
clock's frequency upon cpufreq events.

Signed-off-by: Guennadi Liakhovetski <g.liakhovetski at gmx.de>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/clock-sh73a0.c |   16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/arch/arm/mach-shmobile/clock-sh73a0.c b/arch/arm/mach-shmobile/clock-sh73a0.c
index 34b5c5a..a57ec15 100644
--- a/arch/arm/mach-shmobile/clock-sh73a0.c
+++ b/arch/arm/mach-shmobile/clock-sh73a0.c
@@ -288,6 +288,20 @@ static struct clk div4_clks[DIV4_NR] = {
 	[DIV4_HP] = DIV4(FRQCRB, 4, 0xdff, 0),
 };
 
+static unsigned long twd_recalc(struct clk *clk)
+{
+	return clk_get_rate(clk->parent) / 4;
+}
+
+static struct sh_clk_ops twd_clk_ops = {
+	.recalc = twd_recalc,
+};
+
+static struct clk twd_clk = {
+	.parent = &div4_clks[DIV4_Z],
+	.ops = &twd_clk_ops,
+};
+
 enum { DIV6_VCK1, DIV6_VCK2, DIV6_VCK3, DIV6_ZB1,
 	DIV6_FLCTL, DIV6_SDHI0, DIV6_SDHI1, DIV6_SDHI2,
 	DIV6_FSIA, DIV6_FSIB, DIV6_SUB,
@@ -482,6 +496,7 @@ static struct clk dsi1phy_clk = {
 static struct clk *late_main_clks[] = {
 	&dsi0phy_clk,
 	&dsi1phy_clk,
+	&twd_clk,
 };
 
 enum { MSTP001,
@@ -546,6 +561,7 @@ static struct clk mstp_clks[MSTP_NR] = {
 static struct clk_lookup lookups[] = {
 	/* main clocks */
 	CLKDEV_CON_ID("r_clk", &r_clk),
+	CLKDEV_DEV_ID("smp_twd", &twd_clk), /* smp_twd */
 
 	/* DIV6 clocks */
 	CLKDEV_CON_ID("vck1_clk", &div6_clks[DIV6_VCK1]),
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 01:07:03 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue,  2 Apr 2013 14:07:03 +0900
Subject: [PATCH 07/30] ARM: shmobile: r8a7778 SCIF support
In-Reply-To: <1364879246-9470-1-git-send-email-horms+renesas@verge.net.au>
References: <1364879246-9470-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364879246-9470-8-git-send-email-horms+renesas@verge.net.au>

From: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>

Add SCIF serial port support to the r8a7778 SoC by
adding platform devices together with clock bindings.
DT device description is excluded at this point since
such bindings are still under development.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Acked-by: Magnus Damm <damm at opensource.se>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/clock-r8a7778.c |   13 +++++++++++++
 arch/arm/mach-shmobile/setup-r8a7778.c |   26 ++++++++++++++++++++++++++
 2 files changed, 39 insertions(+)

diff --git a/arch/arm/mach-shmobile/clock-r8a7778.c b/arch/arm/mach-shmobile/clock-r8a7778.c
index 387e3b7..f1277f4 100644
--- a/arch/arm/mach-shmobile/clock-r8a7778.c
+++ b/arch/arm/mach-shmobile/clock-r8a7778.c
@@ -58,16 +58,29 @@ static struct clk *main_clks[] = {
 };
 
 enum {
+	MSTP026, MSTP025, MSTP024, MSTP023, MSTP022, MSTP021,
 	MSTP016, MSTP015,
 	MSTP_NR };
 
 static struct clk mstp_clks[MSTP_NR] = {
+	[MSTP026] = SH_CLK_MSTP32(&clkp, MSTPCR0, 26, 0), /* SCIF0 */
+	[MSTP025] = SH_CLK_MSTP32(&clkp, MSTPCR0, 25, 0), /* SCIF1 */
+	[MSTP024] = SH_CLK_MSTP32(&clkp, MSTPCR0, 24, 0), /* SCIF2 */
+	[MSTP023] = SH_CLK_MSTP32(&clkp, MSTPCR0, 23, 0), /* SCIF3 */
+	[MSTP022] = SH_CLK_MSTP32(&clkp, MSTPCR0, 22, 0), /* SCIF4 */
+	[MSTP021] = SH_CLK_MSTP32(&clkp, MSTPCR0, 21, 0), /* SCIF5 */
 	[MSTP016] = SH_CLK_MSTP32(&clkp, MSTPCR0, 16, 0), /* TMU0 */
 	[MSTP015] = SH_CLK_MSTP32(&clkp, MSTPCR0, 15, 0), /* TMU1 */
 };
 
 static struct clk_lookup lookups[] = {
 	/* MSTP32 clocks */
+	CLKDEV_DEV_ID("sh-sci.0", &mstp_clks[MSTP026]), /* SCIF0 */
+	CLKDEV_DEV_ID("sh-sci.1", &mstp_clks[MSTP025]), /* SCIF1 */
+	CLKDEV_DEV_ID("sh-sci.2", &mstp_clks[MSTP024]), /* SCIF2 */
+	CLKDEV_DEV_ID("sh-sci.3", &mstp_clks[MSTP023]), /* SCIF3 */
+	CLKDEV_DEV_ID("sh-sci.4", &mstp_clks[MSTP022]), /* SCIF4 */
+	CLKDEV_DEV_ID("sh-sci.5", &mstp_clks[MSTP021]), /* SCIF6 */
 	CLKDEV_DEV_ID("sh_tmu.0", &mstp_clks[MSTP016]), /* TMU00 */
 	CLKDEV_DEV_ID("sh_tmu.1", &mstp_clks[MSTP015]), /* TMU01 */
 };
diff --git a/arch/arm/mach-shmobile/setup-r8a7778.c b/arch/arm/mach-shmobile/setup-r8a7778.c
index 811ccf3..01c62be 100644
--- a/arch/arm/mach-shmobile/setup-r8a7778.c
+++ b/arch/arm/mach-shmobile/setup-r8a7778.c
@@ -25,6 +25,7 @@
 #include <linux/of_platform.h>
 #include <linux/platform_device.h>
 #include <linux/irqchip.h>
+#include <linux/serial_sci.h>
 #include <linux/sh_timer.h>
 #include <mach/irqs.h>
 #include <mach/r8a7778.h>
@@ -32,6 +33,26 @@
 #include <asm/mach/arch.h>
 #include <asm/hardware/cache-l2x0.h>
 
+/* SCIF */
+#define SCIF_INFO(baseaddr, irq)				\
+{								\
+	.mapbase	= baseaddr,				\
+	.flags		= UPF_BOOT_AUTOCONF | UPF_IOREMAP,	\
+	.scscr		= SCSCR_RE | SCSCR_TE | SCSCR_CKE1,	\
+	.scbrr_algo_id	= SCBRR_ALGO_2,				\
+	.type		= PORT_SCIF,				\
+	.irqs		= SCIx_IRQ_MUXED(irq),			\
+}
+
+static struct plat_sci_port scif_platform_data[] = {
+	SCIF_INFO(0xffe40000, gic_iid(0x66)),
+	SCIF_INFO(0xffe41000, gic_iid(0x67)),
+	SCIF_INFO(0xffe42000, gic_iid(0x68)),
+	SCIF_INFO(0xffe43000, gic_iid(0x69)),
+	SCIF_INFO(0xffe44000, gic_iid(0x6a)),
+	SCIF_INFO(0xffe45000, gic_iid(0x6b)),
+};
+
 /* TMU */
 static struct resource sh_tmu0_resources[] = {
 	DEFINE_RES_MEM(0xffd80008, 12),
@@ -88,6 +109,11 @@ void __init r8a7778_add_standard_devices(void)
 	}
 #endif
 
+	for (i = 0; i < ARRAY_SIZE(scif_platform_data); i++)
+		platform_device_register_data(&platform_bus, "sh-sci", i,
+					      &scif_platform_data[i],
+					      sizeof(struct plat_sci_port));
+
 	for (i = 0; i < ARRAY_SIZE(platform_devinfo); i++)
 		platform_device_register_full(&platform_devinfo[i]);
 }
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 01:07:09 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue,  2 Apr 2013 14:07:09 +0900
Subject: [PATCH 13/30] ARM: shmobile: sh73a0: remove DIV4_ZT* clocks
In-Reply-To: <1364879246-9470-1-git-send-email-horms+renesas@verge.net.au>
References: <1364879246-9470-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364879246-9470-14-git-send-email-horms+renesas@verge.net.au>

From: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>

DIV4_ZT* clocks are for debugging and trace bus clock.
It is not necessary to control it from Linux/Software.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Acked-by: Magnus Damm <damm at opensource.se>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/clock-sh73a0.c |    4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/arch/arm/mach-shmobile/clock-sh73a0.c b/arch/arm/mach-shmobile/clock-sh73a0.c
index a57ec15..26a5803 100644
--- a/arch/arm/mach-shmobile/clock-sh73a0.c
+++ b/arch/arm/mach-shmobile/clock-sh73a0.c
@@ -269,7 +269,7 @@ static struct clk_div4_table div4_table = {
 };
 
 enum { DIV4_I, DIV4_ZG, DIV4_M3, DIV4_B, DIV4_M1, DIV4_M2,
-	DIV4_Z, DIV4_ZTR, DIV4_ZT, DIV4_ZX, DIV4_HP, DIV4_NR };
+	DIV4_Z, DIV4_ZX, DIV4_HP, DIV4_NR };
 
 #define DIV4(_reg, _bit, _mask, _flags) \
 	SH_CLK_DIV4(&pll1_clk, _reg, _bit, _mask, _flags)
@@ -282,8 +282,6 @@ static struct clk div4_clks[DIV4_NR] = {
 	[DIV4_M1] = DIV4(FRQCRA, 4, 0x1dff, 0),
 	[DIV4_M2] = DIV4(FRQCRA, 0, 0x1dff, 0),
 	[DIV4_Z] = SH_CLK_DIV4(&pll0_clk, FRQCRB, 24, 0x97f, 0),
-	[DIV4_ZTR] = DIV4(FRQCRB, 20, 0xdff, 0),
-	[DIV4_ZT] = DIV4(FRQCRB, 16, 0xdff, 0),
 	[DIV4_ZX] = DIV4(FRQCRB, 12, 0xdff, 0),
 	[DIV4_HP] = DIV4(FRQCRB, 4, 0xdff, 0),
 };
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 01:07:06 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue,  2 Apr 2013 14:07:06 +0900
Subject: [PATCH 10/30] ARM: shmobile: r8a73a4: add thermal driver support
In-Reply-To: <1364879246-9470-1-git-send-email-horms+renesas@verge.net.au>
References: <1364879246-9470-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364879246-9470-11-git-send-email-horms+renesas@verge.net.au>

From: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>

You can get current thermal by
> cat /sys/class/thermal/thermal_zone?/temp

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Acked-by: Magnus Damm <damm at opensource.se>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a73a4.dtsi         |    7 +++++++
 arch/arm/mach-shmobile/clock-r8a73a4.c |   13 ++++++++++++-
 arch/arm/mach-shmobile/setup-r8a73a4.c |   15 +++++++++++++++
 3 files changed, 34 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/r8a73a4.dtsi b/arch/arm/boot/dts/r8a73a4.dtsi
index 4c68ba1..7db5b50 100644
--- a/arch/arm/boot/dts/r8a73a4.dtsi
+++ b/arch/arm/boot/dts/r8a73a4.dtsi
@@ -84,4 +84,11 @@
 				<0 56 4>, <0 57 4>;
 	};
 
+	thermal at e61f0000 {
+		compatible = "renesas,rcar-thermal";
+		reg = <0xe61f0000 0x14>, <0xe61f0100 0x38>,
+			 <0xe61f0200 0x38>, <0xe61f0300 0x38>;
+		interrupt-parent = <&gic>;
+		interrupts = <0 69 4>;
+	};
 };
diff --git a/arch/arm/mach-shmobile/clock-r8a73a4.c b/arch/arm/mach-shmobile/clock-r8a73a4.c
index 037713b..e710c00 100644
--- a/arch/arm/mach-shmobile/clock-r8a73a4.c
+++ b/arch/arm/mach-shmobile/clock-r8a73a4.c
@@ -29,6 +29,7 @@
 
 #define MPCKCR 0xe6150080
 #define SMSTPCR2 0xe6150138
+#define SMSTPCR5 0xe6150144
 
 static struct clk_mapping cpg_mapping = {
 	.phys   = CPG_BASE,
@@ -56,7 +57,12 @@ static struct clk *main_clks[] = {
 	&extal2_clk,
 };
 
-enum { MSTP217, MSTP216, MSTP207, MSTP206, MSTP204, MSTP203, MSTP_NR };
+enum {
+	MSTP217, MSTP216, MSTP207, MSTP206, MSTP204, MSTP203,
+	MSTP522,
+	MSTP_NR
+};
+
 static struct clk mstp_clks[MSTP_NR] = {
 	[MSTP204] = SH_CLK_MSTP32(&extal2_clk, SMSTPCR2, 4, 0), /* SCIFA0 */
 	[MSTP203] = SH_CLK_MSTP32(&extal2_clk, SMSTPCR2, 3, 0), /* SCIFA1 */
@@ -64,6 +70,7 @@ static struct clk mstp_clks[MSTP_NR] = {
 	[MSTP207] = SH_CLK_MSTP32(&extal2_clk, SMSTPCR2, 7, 0), /* SCIFB1 */
 	[MSTP216] = SH_CLK_MSTP32(&extal2_clk, SMSTPCR2, 16, 0), /* SCIFB2 */
 	[MSTP217] = SH_CLK_MSTP32(&extal2_clk, SMSTPCR2, 17, 0), /* SCIFB3 */
+	[MSTP522] = SH_CLK_MSTP32(&extal2_clk, SMSTPCR5, 22, 0), /* Thermal */
 };
 
 static struct clk_lookup lookups[] = {
@@ -73,6 +80,10 @@ static struct clk_lookup lookups[] = {
 	CLKDEV_DEV_ID("sh-sci.3", &mstp_clks[MSTP207]),
 	CLKDEV_DEV_ID("sh-sci.4", &mstp_clks[MSTP216]),
 	CLKDEV_DEV_ID("sh-sci.5", &mstp_clks[MSTP217]),
+	CLKDEV_DEV_ID("rcar_thermal", &mstp_clks[MSTP522]),
+
+	/* for DT */
+	CLKDEV_DEV_ID("e61f0000.thermal", &mstp_clks[MSTP522]),
 };
 
 void __init r8a73a4_clock_init(void)
diff --git a/arch/arm/mach-shmobile/setup-r8a73a4.c b/arch/arm/mach-shmobile/setup-r8a73a4.c
index c2d86f3..c5a75a7 100644
--- a/arch/arm/mach-shmobile/setup-r8a73a4.c
+++ b/arch/arm/mach-shmobile/setup-r8a73a4.c
@@ -155,6 +155,20 @@ static const struct resource irqc1_resources[] = {
 					  &irqc##idx##_data,		\
 					  sizeof(struct renesas_irqc_config))
 
+/* Thermal0 -> Thermal2 */
+static const struct resource thermal0_resources[] = {
+	DEFINE_RES_MEM(0xe61f0000, 0x14),
+	DEFINE_RES_MEM(0xe61f0100, 0x38),
+	DEFINE_RES_MEM(0xe61f0200, 0x38),
+	DEFINE_RES_MEM(0xe61f0300, 0x38),
+	DEFINE_RES_IRQ(gic_spi(69)),
+};
+
+#define r8a73a4_register_thermal()					\
+	platform_device_register_simple("rcar_thermal", -1,		\
+					thermal0_resources,		\
+					ARRAY_SIZE(thermal0_resources))
+
 void __init r8a73a4_add_standard_devices(void)
 {
 	r8a73a4_register_scif(SCIFA0);
@@ -165,6 +179,7 @@ void __init r8a73a4_add_standard_devices(void)
 	r8a73a4_register_scif(SCIFB3);
 	r8a73a4_register_irqc(0);
 	r8a73a4_register_irqc(1);
+	r8a73a4_register_thermal();
 }
 
 #ifdef CONFIG_USE_OF
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 01:07:10 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue,  2 Apr 2013 14:07:10 +0900
Subject: [PATCH 14/30] ARM: shmobile: sh7372: remove DIV4_ZT* clocks
In-Reply-To: <1364879246-9470-1-git-send-email-horms+renesas@verge.net.au>
References: <1364879246-9470-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364879246-9470-15-git-send-email-horms+renesas@verge.net.au>

From: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>

DIV4_ZT* clocks are for debugging and trace bus clock.
It is not necessary to control it from Linux/Software.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Acked-by: Magnus Damm <damm at opensource.se>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/clock-sh7372.c |    6 +-----
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/arch/arm/mach-shmobile/clock-sh7372.c b/arch/arm/mach-shmobile/clock-sh7372.c
index 45d21fe..6c23e3f 100644
--- a/arch/arm/mach-shmobile/clock-sh7372.c
+++ b/arch/arm/mach-shmobile/clock-sh7372.c
@@ -342,7 +342,7 @@ static struct clk_div4_table div4_table = {
 };
 
 enum { DIV4_I, DIV4_ZG, DIV4_B, DIV4_M1, DIV4_CSIR,
-       DIV4_ZTR, DIV4_ZT, DIV4_ZX, DIV4_HP,
+       DIV4_ZX, DIV4_HP,
        DIV4_ISPB, DIV4_S, DIV4_ZB, DIV4_ZB3, DIV4_CP,
        DIV4_DDRP, DIV4_NR };
 
@@ -355,8 +355,6 @@ static struct clk div4_clks[DIV4_NR] = {
 	[DIV4_B] = DIV4(FRQCRA, 8, 0x6fff, CLK_ENABLE_ON_INIT),
 	[DIV4_M1] = DIV4(FRQCRA, 4, 0x6fff, CLK_ENABLE_ON_INIT),
 	[DIV4_CSIR] = DIV4(FRQCRA, 0, 0x6fff, 0),
-	[DIV4_ZTR] = DIV4(FRQCRB, 20, 0x6fff, 0),
-	[DIV4_ZT] = DIV4(FRQCRB, 16, 0x6fff, 0),
 	[DIV4_ZX] = DIV4(FRQCRB, 12, 0x6fff, 0),
 	[DIV4_HP] = DIV4(FRQCRB, 4, 0x6fff, 0),
 	[DIV4_ISPB] = DIV4(FRQCRC, 20, 0x6fff, 0),
@@ -516,8 +514,6 @@ static struct clk_lookup lookups[] = {
 	CLKDEV_CON_ID("b_clk", &div4_clks[DIV4_B]),
 	CLKDEV_CON_ID("m1_clk", &div4_clks[DIV4_M1]),
 	CLKDEV_CON_ID("csir_clk", &div4_clks[DIV4_CSIR]),
-	CLKDEV_CON_ID("ztr_clk", &div4_clks[DIV4_ZTR]),
-	CLKDEV_CON_ID("zt_clk", &div4_clks[DIV4_ZT]),
 	CLKDEV_CON_ID("zx_clk", &div4_clks[DIV4_ZX]),
 	CLKDEV_CON_ID("hp_clk", &div4_clks[DIV4_HP]),
 	CLKDEV_CON_ID("ispb_clk", &div4_clks[DIV4_ISPB]),
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 01:07:12 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue,  2 Apr 2013 14:07:12 +0900
Subject: [PATCH 16/30] ARM: shmobile: sh7372: use fixed ratio clock
In-Reply-To: <1364879246-9470-1-git-send-email-horms+renesas@verge.net.au>
References: <1364879246-9470-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364879246-9470-17-git-send-email-horms+renesas@verge.net.au>

From: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>

Current clock-sh7372 is using own implement
for each divX clocks.
This patch switches to use fixed ratio clock,
and was tesed on mackerel board.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Acked-by: Magnus Damm <damm at opensource.se>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/clock-sh7372.c |   44 ++++++---------------------------
 1 file changed, 7 insertions(+), 37 deletions(-)

diff --git a/arch/arm/mach-shmobile/clock-sh7372.c b/arch/arm/mach-shmobile/clock-sh7372.c
index 6c23e3f..7e10593 100644
--- a/arch/arm/mach-shmobile/clock-sh7372.c
+++ b/arch/arm/mach-shmobile/clock-sh7372.c
@@ -21,6 +21,7 @@
 #include <linux/io.h>
 #include <linux/sh_clk.h>
 #include <linux/clkdev.h>
+#include <mach/clock.h>
 #include <mach/common.h>
 
 /* SH7372 registers */
@@ -83,39 +84,12 @@ struct clk sh7372_extal2_clk = {
 	.rate		= 48000000,
 };
 
-/* A fixed divide-by-2 block */
-static unsigned long div2_recalc(struct clk *clk)
-{
-	return clk->parent->rate / 2;
-}
-
-static struct sh_clk_ops div2_clk_ops = {
-	.recalc		= div2_recalc,
-};
+SH_CLK_RATIO(div2, 1, 2);
 
-/* Divide dv_clki by two */
-struct clk sh7372_dv_clki_div2_clk = {
-	.ops		= &div2_clk_ops,
-	.parent		= &sh7372_dv_clki_clk,
-};
-
-/* Divide extal1 by two */
-static struct clk extal1_div2_clk = {
-	.ops		= &div2_clk_ops,
-	.parent		= &sh7372_extal1_clk,
-};
-
-/* Divide extal2 by two */
-static struct clk extal2_div2_clk = {
-	.ops		= &div2_clk_ops,
-	.parent		= &sh7372_extal2_clk,
-};
-
-/* Divide extal2 by four */
-static struct clk extal2_div4_clk = {
-	.ops		= &div2_clk_ops,
-	.parent		= &extal2_div2_clk,
-};
+SH_FIXED_RATIO_CLKg(sh7372_dv_clki_div2_clk,	sh7372_dv_clki_clk,	div2);
+SH_FIXED_RATIO_CLK(extal1_div2_clk,		sh7372_extal1_clk,	div2);
+SH_FIXED_RATIO_CLK(extal2_div2_clk,		sh7372_extal2_clk,	div2);
+SH_FIXED_RATIO_CLK(extal2_div4_clk,		extal2_div2_clk,	div2);
 
 /* PLLC0 and PLLC1 */
 static unsigned long pllc01_recalc(struct clk *clk)
@@ -147,10 +121,7 @@ static struct clk pllc1_clk = {
 };
 
 /* Divide PLLC1 by two */
-static struct clk pllc1_div2_clk = {
-	.ops		= &div2_clk_ops,
-	.parent		= &pllc1_clk,
-};
+SH_FIXED_RATIO_CLK(pllc1_div2_clk,	pllc1_clk,	div2);
 
 /* PLLC2 */
 
@@ -650,5 +621,4 @@ void __init sh7372_clock_init(void)
 		shmobile_clk_init();
 	else
 		panic("failed to setup sh7372 clocks\n");
-
 }
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 01:07:11 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue,  2 Apr 2013 14:07:11 +0900
Subject: [PATCH 15/30] ARM: shmobile: add struct clk_ratio and fixed ratio
 clock macro
In-Reply-To: <1364879246-9470-1-git-send-email-horms+renesas@verge.net.au>
References: <1364879246-9470-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364879246-9470-16-git-send-email-horms+renesas@verge.net.au>

From: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>

Renesas chip has many clocks inside,
and some of them are using fixed ratio via parent clock.
Current shmobile clock code is using own divX_recalc function
and divX_clk_ops.
This patch can reduce these code

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Acked-by: Magnus Damm <damm at opensource.se>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/clock.c              |   13 +++++++++
 arch/arm/mach-shmobile/include/mach/clock.h |   39 +++++++++++++++++++++++++++
 2 files changed, 52 insertions(+)
 create mode 100644 arch/arm/mach-shmobile/include/mach/clock.h

diff --git a/arch/arm/mach-shmobile/clock.c b/arch/arm/mach-shmobile/clock.c
index e816ca9..ad7df62 100644
--- a/arch/arm/mach-shmobile/clock.c
+++ b/arch/arm/mach-shmobile/clock.c
@@ -23,6 +23,19 @@
 #include <linux/init.h>
 #include <linux/sh_clk.h>
 #include <linux/export.h>
+#include <mach/clock.h>
+#include <mach/common.h>
+
+unsigned long shmobile_fixed_ratio_clk_recalc(struct clk *clk)
+{
+	struct clk_ratio *p = clk->priv;
+
+	return clk->parent->rate / p->div * p->mul;
+};
+
+struct sh_clk_ops shmobile_fixed_ratio_clk_ops = {
+	.recalc	= shmobile_fixed_ratio_clk_recalc,
+};
 
 int __init shmobile_clk_init(void)
 {
diff --git a/arch/arm/mach-shmobile/include/mach/clock.h b/arch/arm/mach-shmobile/include/mach/clock.h
new file mode 100644
index 0000000..76ac612
--- /dev/null
+++ b/arch/arm/mach-shmobile/include/mach/clock.h
@@ -0,0 +1,39 @@
+#ifndef CLOCK_H
+#define CLOCK_H
+
+unsigned long shmobile_fixed_ratio_clk_recalc(struct clk *clk);
+extern struct sh_clk_ops shmobile_fixed_ratio_clk_ops;
+
+/* clock ratio */
+struct clk_ratio {
+	int mul;
+	int div;
+};
+
+#define SH_CLK_RATIO(name, m, d)		\
+static struct clk_ratio name ##_ratio = {	\
+	.mul = m,				\
+	.div = d,				\
+}
+
+#define SH_FIXED_RATIO_CLKg(name, p, r)	\
+struct clk name = {			\
+	.parent	= &p,				\
+	.ops	= &shmobile_fixed_ratio_clk_ops,\
+	.priv	= &r ## _ratio,			\
+}
+
+#define SH_FIXED_RATIO_CLK(name, p, r)		\
+static SH_FIXED_RATIO_CLKg(name, p, r);
+
+#define SH_FIXED_RATIO_CLK_SET(name, p, m, d)	\
+	SH_CLK_RATIO(name, m, d);		\
+	SH_FIXED_RATIO_CLK(name, p, name);
+
+#define SH_CLK_SET_RATIO(p, m, d)	\
+{			\
+	(p)->mul = m;	\
+	(p)->div = d;	\
+}
+
+#endif
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 01:07:02 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue,  2 Apr 2013 14:07:02 +0900
Subject: [PATCH 06/30] ARM: shmobile: add R8A7778 basis support
In-Reply-To: <1364879246-9470-1-git-send-email-horms+renesas@verge.net.au>
References: <1364879246-9470-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364879246-9470-7-git-send-email-horms+renesas@verge.net.au>

From: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>

Add initial support for the R8A7778 R-Car M1A SoC.
No static virtual mappings are used, all the components
make use of ioremap().
DT_MACHINE_START is still wrapped
in CONFIG_USE_OF to match other mach-shmobile code.

It is based on v1.0 datasheet

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Acked-by: Magnus Damm <damm at opensource.se>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7778.dtsi                |   35 ++++++
 arch/arm/mach-shmobile/Kconfig                |    6 +
 arch/arm/mach-shmobile/Makefile               |    1 +
 arch/arm/mach-shmobile/clock-r8a7778.c        |   91 ++++++++++++++
 arch/arm/mach-shmobile/include/mach/r8a7778.h |   28 +++++
 arch/arm/mach-shmobile/setup-r8a7778.c        |  167 +++++++++++++++++++++++++
 6 files changed, 328 insertions(+)
 create mode 100644 arch/arm/boot/dts/r8a7778.dtsi
 create mode 100644 arch/arm/mach-shmobile/clock-r8a7778.c
 create mode 100644 arch/arm/mach-shmobile/include/mach/r8a7778.h
 create mode 100644 arch/arm/mach-shmobile/setup-r8a7778.c

diff --git a/arch/arm/boot/dts/r8a7778.dtsi b/arch/arm/boot/dts/r8a7778.dtsi
new file mode 100644
index 0000000..4743735
--- /dev/null
+++ b/arch/arm/boot/dts/r8a7778.dtsi
@@ -0,0 +1,35 @@
+/*
+ * Device Tree Source for Renesas r8a7778
+ *
+ * Copyright (C) 2013  Renesas Solutions Corp.
+ * Copyright (C) 2013  Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
+ *
+ * based on r8a7779
+ *
+ * Copyright (C) 2013 Renesas Solutions Corp.
+ * Copyright (C) 2013 Simon Horman
+ *
+ * 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/ "skeleton.dtsi"
+
+/ {
+	compatible = "renesas,r8a7778";
+
+	cpus {
+		cpu at 0 {
+			compatible = "arm,cortex-a9";
+		};
+	};
+
+	gic: interrupt-controller at fe438000 {
+		compatible = "arm,cortex-a9-gic";
+		#interrupt-cells = <3>;
+		interrupt-controller;
+		reg = <0xfe438000 0x1000>,
+		      <0xfe430000 0x100>;
+	};
+};
diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index 0e4a820..49cba4a 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -33,6 +33,12 @@ config ARCH_R8A7740
 	select CPU_V7
 	select SH_CLK_CPG
 
+config ARCH_R8A7778
+	bool "R-Car M1 (R8A77780)"
+	select CPU_V7
+	select SH_CLK_CPG
+	select ARM_GIC
+
 config ARCH_R8A7779
 	bool "R-Car H1 (R8A77790)"
 	select ARCH_WANT_OPTIONAL_GPIOLIB
diff --git a/arch/arm/mach-shmobile/Makefile b/arch/arm/mach-shmobile/Makefile
index c5a43ef..2d42de4 100644
--- a/arch/arm/mach-shmobile/Makefile
+++ b/arch/arm/mach-shmobile/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_ARCH_SH7372)	+= setup-sh7372.o clock-sh7372.o intc-sh7372.o
 obj-$(CONFIG_ARCH_SH73A0)	+= setup-sh73a0.o clock-sh73a0.o intc-sh73a0.o
 obj-$(CONFIG_ARCH_R8A73A4)	+= setup-r8a73a4.o clock-r8a73a4.o
 obj-$(CONFIG_ARCH_R8A7740)	+= setup-r8a7740.o clock-r8a7740.o intc-r8a7740.o
+obj-$(CONFIG_ARCH_R8A7778)	+= setup-r8a7778.o clock-r8a7778.o
 obj-$(CONFIG_ARCH_R8A7779)	+= setup-r8a7779.o clock-r8a7779.o intc-r8a7779.o
 obj-$(CONFIG_ARCH_EMEV2)	+= setup-emev2.o clock-emev2.o
 
diff --git a/arch/arm/mach-shmobile/clock-r8a7778.c b/arch/arm/mach-shmobile/clock-r8a7778.c
new file mode 100644
index 0000000..387e3b7
--- /dev/null
+++ b/arch/arm/mach-shmobile/clock-r8a7778.c
@@ -0,0 +1,91 @@
+/*
+ * r8a7778 clock framework support
+ *
+ * Copyright (C) 2013  Renesas Solutions Corp.
+ * Copyright (C) 2013  Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
+ *
+ * based on r8a7779
+ *
+ * Copyright (C) 2011  Renesas Solutions Corp.
+ * Copyright (C) 2011  Magnus Damm
+ *
+ * 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
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+
+#include <linux/io.h>
+#include <linux/sh_clk.h>
+#include <linux/clkdev.h>
+#include <mach/common.h>
+
+#define MSTPCR0		IOMEM(0xffc80030)
+#define MSTPCR1		IOMEM(0xffc80034)
+#define MSTPCR3		IOMEM(0xffc8003c)
+#define MSTPSR1		IOMEM(0xffc80044)
+#define MSTPSR4		IOMEM(0xffc80048)
+#define MSTPSR6		IOMEM(0xffc8004c)
+#define MSTPCR4		IOMEM(0xffc80050)
+#define MSTPCR5		IOMEM(0xffc80054)
+#define MSTPCR6		IOMEM(0xffc80058)
+
+/* ioremap() through clock mapping mandatory to avoid
+ * collision with ARM coherent DMA virtual memory range.
+ */
+
+static struct clk_mapping cpg_mapping = {
+	.phys	= 0xffc80000,
+	.len	= 0x80,
+};
+
+static struct clk clkp = {
+	.rate   = 62500000, /* FIXME: shortcut */
+	.flags  = CLK_ENABLE_ON_INIT,
+	.mapping = &cpg_mapping,
+};
+
+static struct clk *main_clks[] = {
+	&clkp,
+};
+
+enum {
+	MSTP016, MSTP015,
+	MSTP_NR };
+
+static struct clk mstp_clks[MSTP_NR] = {
+	[MSTP016] = SH_CLK_MSTP32(&clkp, MSTPCR0, 16, 0), /* TMU0 */
+	[MSTP015] = SH_CLK_MSTP32(&clkp, MSTPCR0, 15, 0), /* TMU1 */
+};
+
+static struct clk_lookup lookups[] = {
+	/* MSTP32 clocks */
+	CLKDEV_DEV_ID("sh_tmu.0", &mstp_clks[MSTP016]), /* TMU00 */
+	CLKDEV_DEV_ID("sh_tmu.1", &mstp_clks[MSTP015]), /* TMU01 */
+};
+
+void __init r8a7778_clock_init(void)
+{
+	int k, ret = 0;
+
+	for (k = 0; !ret && (k < ARRAY_SIZE(main_clks)); k++)
+		ret = clk_register(main_clks[k]);
+
+	if (!ret)
+		ret = sh_clk_mstp_register(mstp_clks, MSTP_NR);
+
+	clkdev_add_table(lookups, ARRAY_SIZE(lookups));
+
+	if (!ret)
+		shmobile_clk_init();
+	else
+		panic("failed to setup r8a7778 clocks\n");
+}
diff --git a/arch/arm/mach-shmobile/include/mach/r8a7778.h b/arch/arm/mach-shmobile/include/mach/r8a7778.h
new file mode 100644
index 0000000..a755dca
--- /dev/null
+++ b/arch/arm/mach-shmobile/include/mach/r8a7778.h
@@ -0,0 +1,28 @@
+/*
+ * Copyright (C) 2013  Renesas Solutions Corp.
+ * Copyright (C) 2013  Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
+ *
+ * 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; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
+ */
+#ifndef __ASM_R8A7778_H__
+#define __ASM_R8A7778_H__
+
+extern void r8a7778_add_standard_devices(void);
+extern void r8a7778_add_standard_devices_dt(void);
+extern void r8a7778_init_delay(void);
+extern void r8a7778_init_irq(void);
+extern void r8a7778_init_irq_dt(void);
+extern void r8a7778_clock_init(void);
+
+#endif /* __ASM_R8A7778_H__ */
diff --git a/arch/arm/mach-shmobile/setup-r8a7778.c b/arch/arm/mach-shmobile/setup-r8a7778.c
new file mode 100644
index 0000000..811ccf3
--- /dev/null
+++ b/arch/arm/mach-shmobile/setup-r8a7778.c
@@ -0,0 +1,167 @@
+/*
+ * r8a7778 processor support
+ *
+ * Copyright (C) 2013  Renesas Solutions Corp.
+ * Copyright (C) 2013  Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
+ *
+ * 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; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
+ */
+
+#include <linux/kernel.h>
+#include <linux/io.h>
+#include <linux/irqchip/arm-gic.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+#include <linux/irqchip.h>
+#include <linux/sh_timer.h>
+#include <mach/irqs.h>
+#include <mach/r8a7778.h>
+#include <mach/common.h>
+#include <asm/mach/arch.h>
+#include <asm/hardware/cache-l2x0.h>
+
+/* TMU */
+static struct resource sh_tmu0_resources[] = {
+	DEFINE_RES_MEM(0xffd80008, 12),
+	DEFINE_RES_IRQ(gic_iid(0x40)),
+};
+
+static struct sh_timer_config sh_tmu0_platform_data = {
+	.name			= "TMU00",
+	.channel_offset		= 0x4,
+	.timer_bit		= 0,
+	.clockevent_rating	= 200,
+};
+
+static struct resource sh_tmu1_resources[] = {
+	DEFINE_RES_MEM(0xffd80014, 12),
+	DEFINE_RES_IRQ(gic_iid(0x41)),
+};
+
+static struct sh_timer_config sh_tmu1_platform_data = {
+	.name			= "TMU01",
+	.channel_offset		= 0x10,
+	.timer_bit		= 1,
+	.clocksource_rating	= 200,
+};
+
+#define PLATFORM_INFO(n, i)					\
+{								\
+	.parent		= &platform_bus,			\
+	.name		= #n,					\
+	.id		= i,					\
+	.res		= n ## i ## _resources,			\
+	.num_res	= ARRAY_SIZE(n ## i ##_resources),	\
+	.data		= &n ## i ##_platform_data,		\
+	.size_data	= sizeof(n ## i ## _platform_data),	\
+}
+
+struct platform_device_info platform_devinfo[] = {
+	PLATFORM_INFO(sh_tmu, 0),
+	PLATFORM_INFO(sh_tmu, 1),
+};
+
+void __init r8a7778_add_standard_devices(void)
+{
+	int i;
+
+#ifdef CONFIG_CACHE_L2X0
+	void __iomem *base = ioremap_nocache(0xf0100000, 0x1000);
+	if (base) {
+		/*
+		 * Early BRESP enable, Shared attribute override enable, 64K*16way
+		 * don't call iounmap(base)
+		 */
+		l2x0_init(base, 0x40470000, 0x82000fff);
+	}
+#endif
+
+	for (i = 0; i < ARRAY_SIZE(platform_devinfo); i++)
+		platform_device_register_full(&platform_devinfo[i]);
+}
+
+#define INT2SMSKCR0	0x82288 /* 0xfe782288 */
+#define INT2SMSKCR1	0x8228c /* 0xfe78228c */
+
+#define INT2NTSR0	0x00018 /* 0xfe700018 */
+#define INT2NTSR1	0x0002c /* 0xfe70002c */
+static void __init r8a7778_init_irq_common(void)
+{
+	void __iomem *base = ioremap_nocache(0xfe700000, 0x00100000);
+
+	BUG_ON(!base);
+
+	/* route all interrupts to ARM */
+	__raw_writel(0x73ffffff, base + INT2NTSR0);
+	__raw_writel(0xffffffff, base + INT2NTSR1);
+
+	/* unmask all known interrupts in INTCS2 */
+	__raw_writel(0x08330773, base + INT2SMSKCR0);
+	__raw_writel(0x00311110, base + INT2SMSKCR1);
+
+	iounmap(base);
+}
+
+void __init r8a7778_init_irq(void)
+{
+	void __iomem *gic_dist_base;
+	void __iomem *gic_cpu_base;
+
+	gic_dist_base = ioremap_nocache(0xfe438000, PAGE_SIZE);
+	gic_cpu_base  = ioremap_nocache(0xfe430000, PAGE_SIZE);
+	BUG_ON(!gic_dist_base || !gic_cpu_base);
+
+	/* use GIC to handle interrupts */
+	gic_init(0, 29, gic_dist_base, gic_cpu_base);
+
+	r8a7778_init_irq_common();
+}
+
+void __init r8a7778_init_delay(void)
+{
+	shmobile_setup_delay(800, 1, 3); /* Cortex-A9 @ 800MHz */
+}
+
+#ifdef CONFIG_USE_OF
+void __init r8a7778_init_irq_dt(void)
+{
+	irqchip_init();
+	r8a7778_init_irq_common();
+}
+
+static const struct of_dev_auxdata r8a7778_auxdata_lookup[] __initconst = {
+	{},
+};
+
+void __init r8a7778_add_standard_devices_dt(void)
+{
+	of_platform_populate(NULL, of_default_bus_match_table,
+			     r8a7778_auxdata_lookup, NULL);
+}
+
+static const char *r8a7778_compat_dt[] __initdata = {
+	"renesas,r8a7778",
+	NULL,
+};
+
+DT_MACHINE_START(R8A7778_DT, "Generic R8A7778 (Flattened Device Tree)")
+	.init_early	= r8a7778_init_delay,
+	.init_irq	= r8a7778_init_irq_dt,
+	.init_machine	= r8a7778_add_standard_devices_dt,
+	.init_time	= shmobile_timer_init,
+	.dt_compat	= r8a7778_compat_dt,
+MACHINE_END
+
+#endif /* CONFIG_USE_OF */
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 01:07:17 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue,  2 Apr 2013 14:07:17 +0900
Subject: [PATCH 21/30] ARM: shmobile: sh7372: move global functions to sh7372.h
In-Reply-To: <1364879246-9470-1-git-send-email-horms+renesas@verge.net.au>
References: <1364879246-9470-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364879246-9470-22-git-send-email-horms+renesas@verge.net.au>

From: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>

There is no reason each CPU's own function has to exist in common.h.
sh7372_xxx() go to sh7372.h

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Acked-by: Magnus Damm <damm at opensource.se>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/include/mach/common.h |   15 ---------------
 arch/arm/mach-shmobile/include/mach/sh7372.h |   12 ++++++++++++
 2 files changed, 12 insertions(+), 15 deletions(-)

diff --git a/arch/arm/mach-shmobile/include/mach/common.h b/arch/arm/mach-shmobile/include/mach/common.h
index 03f73de..d01a551 100644
--- a/arch/arm/mach-shmobile/include/mach/common.h
+++ b/arch/arm/mach-shmobile/include/mach/common.h
@@ -19,21 +19,6 @@ extern int shmobile_enter_wfi(struct cpuidle_device *dev,
 			      struct cpuidle_driver *drv, int index);
 extern void shmobile_cpuidle_set_driver(struct cpuidle_driver *drv);
 
-extern void sh7372_init_irq(void);
-extern void sh7372_map_io(void);
-extern void sh7372_earlytimer_init(void);
-extern void sh7372_add_early_devices(void);
-extern void sh7372_add_standard_devices(void);
-extern void sh7372_add_early_devices_dt(void);
-extern void sh7372_add_standard_devices_dt(void);
-extern void sh7372_clock_init(void);
-extern void sh7372_pinmux_init(void);
-extern void sh7372_pm_init(void);
-extern void sh7372_resume_core_standby_sysc(void);
-extern int sh7372_do_idle_sysc(unsigned long sleep_mode);
-extern struct clk sh7372_extal1_clk;
-extern struct clk sh7372_extal2_clk;
-
 extern void sh73a0_init_delay(void);
 extern void sh73a0_init_irq(void);
 extern void sh73a0_init_irq_dt(void);
diff --git a/arch/arm/mach-shmobile/include/mach/sh7372.h b/arch/arm/mach-shmobile/include/mach/sh7372.h
index b582fac..f0ea60d 100644
--- a/arch/arm/mach-shmobile/include/mach/sh7372.h
+++ b/arch/arm/mach-shmobile/include/mach/sh7372.h
@@ -478,6 +478,18 @@ extern struct clk sh7372_dv_clki_clk;
 extern struct clk sh7372_dv_clki_div2_clk;
 extern struct clk sh7372_pllc2_clk;
 
+extern void sh7372_init_irq(void);
+extern void sh7372_map_io(void);
+extern void sh7372_earlytimer_init(void);
+extern void sh7372_add_early_devices(void);
+extern void sh7372_add_standard_devices(void);
+extern void sh7372_add_early_devices_dt(void);
+extern void sh7372_add_standard_devices_dt(void);
+extern void sh7372_clock_init(void);
+extern void sh7372_pinmux_init(void);
+extern void sh7372_pm_init(void);
+extern void sh7372_resume_core_standby_sysc(void);
+extern int  sh7372_do_idle_sysc(unsigned long sleep_mode);
 extern void sh7372_intcs_suspend(void);
 extern void sh7372_intcs_resume(void);
 extern void sh7372_intca_suspend(void);
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 01:07:19 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue,  2 Apr 2013 14:07:19 +0900
Subject: [PATCH 23/30] ARM: shmobile: r8a7740: move global functions to
 r8a7740.h
In-Reply-To: <1364879246-9470-1-git-send-email-horms+renesas@verge.net.au>
References: <1364879246-9470-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364879246-9470-24-git-send-email-horms+renesas@verge.net.au>

From: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>

There is no reason each CPU's own function has to exist in common.h.
r8a7740_xxx() go to r8a7740.h

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Acked-by: Magnus Damm <damm at opensource.se>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/include/mach/common.h  |    9 ---------
 arch/arm/mach-shmobile/include/mach/r8a7740.h |    9 +++++++++
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/arch/arm/mach-shmobile/include/mach/common.h b/arch/arm/mach-shmobile/include/mach/common.h
index 48eeca9..4d5410d 100644
--- a/arch/arm/mach-shmobile/include/mach/common.h
+++ b/arch/arm/mach-shmobile/include/mach/common.h
@@ -19,15 +19,6 @@ extern int shmobile_enter_wfi(struct cpuidle_device *dev,
 			      struct cpuidle_driver *drv, int index);
 extern void shmobile_cpuidle_set_driver(struct cpuidle_driver *drv);
 
-extern void r8a7740_meram_workaround(void);
-extern void r8a7740_init_irq(void);
-extern void r8a7740_map_io(void);
-extern void r8a7740_add_early_devices(void);
-extern void r8a7740_add_standard_devices(void);
-extern void r8a7740_clock_init(u8 md_ck);
-extern void r8a7740_pinmux_init(void);
-extern void r8a7740_pm_init(void);
-
 extern void r8a7779_init_delay(void);
 extern void r8a7779_init_irq(void);
 extern void r8a7779_init_irq_extpin(int irlm);
diff --git a/arch/arm/mach-shmobile/include/mach/r8a7740.h b/arch/arm/mach-shmobile/include/mach/r8a7740.h
index 59d252f..5a879bb 100644
--- a/arch/arm/mach-shmobile/include/mach/r8a7740.h
+++ b/arch/arm/mach-shmobile/include/mach/r8a7740.h
@@ -606,6 +606,15 @@ enum {
 	SHDMA_SLAVE_USBHS_RX,
 };
 
+extern void r8a7740_meram_workaround(void);
+extern void r8a7740_init_irq(void);
+extern void r8a7740_map_io(void);
+extern void r8a7740_add_early_devices(void);
+extern void r8a7740_add_standard_devices(void);
+extern void r8a7740_clock_init(u8 md_ck);
+extern void r8a7740_pinmux_init(void);
+extern void r8a7740_pm_init(void);
+
 #ifdef CONFIG_PM
 extern void __init r8a7740_init_pm_domains(void);
 #else
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 01:07:18 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue,  2 Apr 2013 14:07:18 +0900
Subject: [PATCH 22/30] ARM: shmobile: sh73a0: move global functions to sh73a0.h
In-Reply-To: <1364879246-9470-1-git-send-email-horms+renesas@verge.net.au>
References: <1364879246-9470-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364879246-9470-23-git-send-email-horms+renesas@verge.net.au>

From: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>

There is no reason each CPU's own function has to exist in common.h.
sh73a0_xxx() go to sh73a0.h

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Acked-by: Magnus Damm <damm at opensource.se>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/include/mach/common.h |   16 ----------------
 arch/arm/mach-shmobile/include/mach/sh73a0.h |   15 +++++++++++++++
 2 files changed, 15 insertions(+), 16 deletions(-)

diff --git a/arch/arm/mach-shmobile/include/mach/common.h b/arch/arm/mach-shmobile/include/mach/common.h
index d01a551..48eeca9 100644
--- a/arch/arm/mach-shmobile/include/mach/common.h
+++ b/arch/arm/mach-shmobile/include/mach/common.h
@@ -19,22 +19,6 @@ extern int shmobile_enter_wfi(struct cpuidle_device *dev,
 			      struct cpuidle_driver *drv, int index);
 extern void shmobile_cpuidle_set_driver(struct cpuidle_driver *drv);
 
-extern void sh73a0_init_delay(void);
-extern void sh73a0_init_irq(void);
-extern void sh73a0_init_irq_dt(void);
-extern void sh73a0_map_io(void);
-extern void sh73a0_earlytimer_init(void);
-extern void sh73a0_add_early_devices(void);
-extern void sh73a0_add_standard_devices(void);
-extern void sh73a0_add_standard_devices_dt(void);
-extern void sh73a0_clock_init(void);
-extern void sh73a0_pinmux_init(void);
-extern void sh73a0_pm_init(void);
-extern struct clk sh73a0_extal1_clk;
-extern struct clk sh73a0_extal2_clk;
-extern struct clk sh73a0_extcki_clk;
-extern struct clk sh73a0_extalr_clk;
-
 extern void r8a7740_meram_workaround(void);
 extern void r8a7740_init_irq(void);
 extern void r8a7740_map_io(void);
diff --git a/arch/arm/mach-shmobile/include/mach/sh73a0.h b/arch/arm/mach-shmobile/include/mach/sh73a0.h
index 606d31d..936da1b 100644
--- a/arch/arm/mach-shmobile/include/mach/sh73a0.h
+++ b/arch/arm/mach-shmobile/include/mach/sh73a0.h
@@ -557,6 +557,21 @@ enum {
 #define SH73A0_PINT0_IRQ(irq) ((irq) + 700)
 #define SH73A0_PINT1_IRQ(irq) ((irq) + 732)
 
+extern void sh73a0_init_delay(void);
+extern void sh73a0_init_irq(void);
+extern void sh73a0_init_irq_dt(void);
+extern void sh73a0_map_io(void);
+extern void sh73a0_earlytimer_init(void);
+extern void sh73a0_add_early_devices(void);
+extern void sh73a0_add_standard_devices(void);
+extern void sh73a0_add_standard_devices_dt(void);
+extern void sh73a0_clock_init(void);
+extern void sh73a0_pinmux_init(void);
+extern void sh73a0_pm_init(void);
+extern struct clk sh73a0_extal1_clk;
+extern struct clk sh73a0_extal2_clk;
+extern struct clk sh73a0_extcki_clk;
+extern struct clk sh73a0_extalr_clk;
 extern struct smp_operations sh73a0_smp_ops;
 
 #endif /* __ASM_SH73A0_H__ */
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 01:07:14 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue,  2 Apr 2013 14:07:14 +0900
Subject: [PATCH 18/30] ARM: shmobile: r8a7740: tidyup comment/implementation
 mismatch
In-Reply-To: <1364879246-9470-1-git-send-email-horms+renesas@verge.net.au>
References: <1364879246-9470-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364879246-9470-19-git-send-email-horms+renesas@verge.net.au>

From: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>

Current clock-r8a7740's DIV4/DIV6/MSTP implemented area and
its comment are mismatching.
This patch tidyup its comment/implementation area.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Acked-by: Magnus Damm <damm at opensource.se>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/clock-r8a7740.c |   60 +++++++++++++++++---------------
 1 file changed, 31 insertions(+), 29 deletions(-)

diff --git a/arch/arm/mach-shmobile/clock-r8a7740.c b/arch/arm/mach-shmobile/clock-r8a7740.c
index 1feb9a2..161e128 100644
--- a/arch/arm/mach-shmobile/clock-r8a7740.c
+++ b/arch/arm/mach-shmobile/clock-r8a7740.c
@@ -323,6 +323,7 @@ struct clk *main_clks[] = {
 	&fsibck_clk,
 };
 
+/* DIV4 clocks */
 static void div4_kick(struct clk *clk)
 {
 	unsigned long value;
@@ -346,6 +347,26 @@ static struct clk_div4_table div4_table = {
 	.kick = div4_kick,
 };
 
+enum {
+	DIV4_I, DIV4_ZG, DIV4_B, DIV4_M1, DIV4_HP,
+	DIV4_HPP, DIV4_USBP, DIV4_S, DIV4_ZB, DIV4_M3, DIV4_CP,
+	DIV4_NR
+};
+
+struct clk div4_clks[DIV4_NR] = {
+	[DIV4_I]	= SH_CLK_DIV4(&pllc1_clk, FRQCRA, 20, 0x6fff, CLK_ENABLE_ON_INIT),
+	[DIV4_ZG]	= SH_CLK_DIV4(&pllc1_clk, FRQCRA, 16, 0x6fff, CLK_ENABLE_ON_INIT),
+	[DIV4_B]	= SH_CLK_DIV4(&pllc1_clk, FRQCRA,  8, 0x6fff, CLK_ENABLE_ON_INIT),
+	[DIV4_M1]	= SH_CLK_DIV4(&pllc1_clk, FRQCRA,  4, 0x6fff, CLK_ENABLE_ON_INIT),
+	[DIV4_HP]	= SH_CLK_DIV4(&pllc1_clk, FRQCRB,  4, 0x6fff, 0),
+	[DIV4_HPP]	= SH_CLK_DIV4(&pllc1_clk, FRQCRC, 20, 0x6fff, 0),
+	[DIV4_USBP]	= SH_CLK_DIV4(&pllc1_clk, FRQCRC, 16, 0x6fff, 0),
+	[DIV4_S]	= SH_CLK_DIV4(&pllc1_clk, FRQCRC, 12, 0x6fff, 0),
+	[DIV4_ZB]	= SH_CLK_DIV4(&pllc1_clk, FRQCRC,  8, 0x6fff, 0),
+	[DIV4_M3]	= SH_CLK_DIV4(&pllc1_clk, FRQCRC,  4, 0x6fff, 0),
+	[DIV4_CP]	= SH_CLK_DIV4(&pllc1_clk, FRQCRC,  0, 0x6fff, 0),
+};
+
 /* DIV6 reparent */
 enum {
 	DIV6_HDMI,
@@ -391,6 +412,16 @@ static struct clk div6_reparent_clks[DIV6_REPARENT_NR] = {
 				      fsib_parents, ARRAY_SIZE(fsib_parents), 6, 2),
 };
 
+/* DIV6 clocks */
+enum {
+	DIV6_SUB,
+	DIV6_NR
+};
+
+static struct clk div6_clks[DIV6_NR] = {
+	[DIV6_SUB]	= SH_CLK_DIV6(&pllc1_div2_clk, SUBCKCR, 0),
+};
+
 /* HDMI1/2 clock */
 static unsigned long hdmi12_recalc(struct clk *clk)
 {
@@ -456,35 +487,6 @@ static struct clk fsidivs[] = {
 
 /* MSTP */
 enum {
-	DIV4_I, DIV4_ZG, DIV4_B, DIV4_M1, DIV4_HP,
-	DIV4_HPP, DIV4_USBP, DIV4_S, DIV4_ZB, DIV4_M3, DIV4_CP,
-	DIV4_NR
-};
-
-struct clk div4_clks[DIV4_NR] = {
-	[DIV4_I]	= SH_CLK_DIV4(&pllc1_clk, FRQCRA, 20, 0x6fff, CLK_ENABLE_ON_INIT),
-	[DIV4_ZG]	= SH_CLK_DIV4(&pllc1_clk, FRQCRA, 16, 0x6fff, CLK_ENABLE_ON_INIT),
-	[DIV4_B]	= SH_CLK_DIV4(&pllc1_clk, FRQCRA,  8, 0x6fff, CLK_ENABLE_ON_INIT),
-	[DIV4_M1]	= SH_CLK_DIV4(&pllc1_clk, FRQCRA,  4, 0x6fff, CLK_ENABLE_ON_INIT),
-	[DIV4_HP]	= SH_CLK_DIV4(&pllc1_clk, FRQCRB,  4, 0x6fff, 0),
-	[DIV4_HPP]	= SH_CLK_DIV4(&pllc1_clk, FRQCRC, 20, 0x6fff, 0),
-	[DIV4_USBP]	= SH_CLK_DIV4(&pllc1_clk, FRQCRC, 16, 0x6fff, 0),
-	[DIV4_S]	= SH_CLK_DIV4(&pllc1_clk, FRQCRC, 12, 0x6fff, 0),
-	[DIV4_ZB]	= SH_CLK_DIV4(&pllc1_clk, FRQCRC,  8, 0x6fff, 0),
-	[DIV4_M3]	= SH_CLK_DIV4(&pllc1_clk, FRQCRC,  4, 0x6fff, 0),
-	[DIV4_CP]	= SH_CLK_DIV4(&pllc1_clk, FRQCRC,  0, 0x6fff, 0),
-};
-
-enum {
-	DIV6_SUB,
-	DIV6_NR
-};
-
-static struct clk div6_clks[DIV6_NR] = {
-	[DIV6_SUB]	= SH_CLK_DIV6(&pllc1_div2_clk, SUBCKCR, 0),
-};
-
-enum {
 	MSTP128, MSTP127, MSTP125,
 	MSTP116, MSTP111, MSTP100, MSTP117,
 
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 01:07:24 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue,  2 Apr 2013 14:07:24 +0900
Subject: [PATCH 28/30] ARM: shmobile: r8a7790 PFC support
In-Reply-To: <1364879246-9470-1-git-send-email-horms+renesas@verge.net.au>
References: <1364879246-9470-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364879246-9470-29-git-send-email-horms+renesas@verge.net.au>

From: Magnus Damm <damm at opensource.se>

Add a platform device for the r8a7790 PFC.

Signed-off-by: Magnus Damm <damm at opensource.se>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/Kconfig                |    1 +
 arch/arm/mach-shmobile/include/mach/r8a7790.h |    1 +
 arch/arm/mach-shmobile/setup-r8a7790.c        |   10 ++++++++++
 3 files changed, 12 insertions(+)

diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index ccaea6a..ff674c5 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -53,6 +53,7 @@ config ARCH_R8A7779
 
 config ARCH_R8A7790
 	bool "R-Car H2 (R8A77900)"
+	select ARCH_WANT_OPTIONAL_GPIOLIB
 	select ARM_GIC
 	select CPU_V7
 	select ARM_ARCH_TIMER
diff --git a/arch/arm/mach-shmobile/include/mach/r8a7790.h b/arch/arm/mach-shmobile/include/mach/r8a7790.h
index f38ded6..9bd6f5c 100644
--- a/arch/arm/mach-shmobile/include/mach/r8a7790.h
+++ b/arch/arm/mach-shmobile/include/mach/r8a7790.h
@@ -3,5 +3,6 @@
 
 void r8a7790_add_standard_devices(void);
 void r8a7790_clock_init(void);
+void r8a7790_pinmux_init(void);
 
 #endif /* __ASM_R8A7790_H__ */
diff --git a/arch/arm/mach-shmobile/setup-r8a7790.c b/arch/arm/mach-shmobile/setup-r8a7790.c
index 9b4ccd7..481201a 100644
--- a/arch/arm/mach-shmobile/setup-r8a7790.c
+++ b/arch/arm/mach-shmobile/setup-r8a7790.c
@@ -29,6 +29,16 @@
 #include <mach/r8a7790.h>
 #include <asm/mach/arch.h>
 
+static const struct resource pfc_resources[] = {
+	DEFINE_RES_MEM(0xe6060000, 0x250),
+};
+
+void __init r8a7790_pinmux_init(void)
+{
+	platform_device_register_simple("pfc-r8a7790", -1, pfc_resources,
+					ARRAY_SIZE(pfc_resources));
+}
+
 #define SCIF_COMMON(scif_type, baseaddr, irq)			\
 	.type		= scif_type,				\
 	.mapbase	= baseaddr,				\
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 01:07:21 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue,  2 Apr 2013 14:07:21 +0900
Subject: [PATCH 25/30] ARM: shmobile: Initial r8a7790 SoC support
In-Reply-To: <1364879246-9470-1-git-send-email-horms+renesas@verge.net.au>
References: <1364879246-9470-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364879246-9470-26-git-send-email-horms+renesas@verge.net.au>

From: Magnus Damm <damm at opensource.se>

Add initial support for the r8a7790 SoC including:
 - Single Cortex-A15 CPU Core
 - GIC
 - Architecture timer

No static virtual mappings are used, all the components
make use of ioremap(). DT_MACHINE_START is still wrapped
in CONFIG_USE_OF to match other mach-shmobile code.

Signed-off-by: Magnus Damm <damm at opensource.se>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7790.dtsi                |   54 ++++++++++++++++++++++
 arch/arm/mach-shmobile/Kconfig                |    7 +++
 arch/arm/mach-shmobile/Makefile               |    1 +
 arch/arm/mach-shmobile/clock-r8a7790.c        |   61 +++++++++++++++++++++++++
 arch/arm/mach-shmobile/include/mach/r8a7790.h |    7 +++
 arch/arm/mach-shmobile/setup-r8a7790.c        |   51 +++++++++++++++++++++
 6 files changed, 181 insertions(+)
 create mode 100644 arch/arm/boot/dts/r8a7790.dtsi
 create mode 100644 arch/arm/mach-shmobile/clock-r8a7790.c
 create mode 100644 arch/arm/mach-shmobile/include/mach/r8a7790.h
 create mode 100644 arch/arm/mach-shmobile/setup-r8a7790.c

diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
new file mode 100644
index 0000000..1c58ffb
--- /dev/null
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -0,0 +1,54 @@
+/*
+ * Device Tree Source for the r8a7790 SoC
+ *
+ * Copyright (C) 2013 Renesas Solutions Corp.
+ *
+ * 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/ "skeleton.dtsi"
+
+/ {
+	compatible = "renesas,r8a7790";
+	interrupt-parent = <&gic>;
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		cpu0: cpu at 0 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a15";
+			reg = <0>;
+			clock-frequency = <1300000000>;
+		};
+	};
+
+	gic: interrupt-controller at f1001000 {
+		compatible = "arm,cortex-a15-gic";
+		#interrupt-cells = <3>;
+		#address-cells = <0>;
+		interrupt-controller;
+		reg = <0xf1001000 0x1000>,
+			<0xf1002000 0x1000>,
+			<0xf1004000 0x2000>,
+			<0xf1006000 0x2000>;
+		interrupts = <1 9 0xf04>;
+
+		gic-cpuif at 4 {
+			compatible = "arm,gic-cpuif";
+			cpuif-id = <4>;
+			cpu = <&cpu0>;
+		};
+	};
+
+	timer {
+		compatible = "arm,armv7-timer";
+		interrupts = <1 13 0xf08>,
+				<1 14 0xf08>,
+				<1 11 0xf08>,
+				<1 10 0xf08>;
+	};
+};
diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index d569c34..749dfb4 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -51,6 +51,13 @@ config ARCH_R8A7779
 	select USB_ARCH_HAS_OHCI
 	select RENESAS_INTC_IRQPIN
 
+config ARCH_R8A7790
+	bool "R-Car H2 (R8A77900)"
+	select ARM_GIC
+	select CPU_V7
+	select ARM_ARCH_TIMER
+	select SH_CLK_CPG
+
 config ARCH_EMEV2
 	bool "Emma Mobile EV2"
 	select ARCH_WANT_OPTIONAL_GPIOLIB
diff --git a/arch/arm/mach-shmobile/Makefile b/arch/arm/mach-shmobile/Makefile
index 2d42de4..709b9b4 100644
--- a/arch/arm/mach-shmobile/Makefile
+++ b/arch/arm/mach-shmobile/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_ARCH_R8A73A4)	+= setup-r8a73a4.o clock-r8a73a4.o
 obj-$(CONFIG_ARCH_R8A7740)	+= setup-r8a7740.o clock-r8a7740.o intc-r8a7740.o
 obj-$(CONFIG_ARCH_R8A7778)	+= setup-r8a7778.o clock-r8a7778.o
 obj-$(CONFIG_ARCH_R8A7779)	+= setup-r8a7779.o clock-r8a7779.o intc-r8a7779.o
+obj-$(CONFIG_ARCH_R8A7790)	+= setup-r8a7790.o clock-r8a7790.o
 obj-$(CONFIG_ARCH_EMEV2)	+= setup-emev2.o clock-emev2.o
 
 # SMP objects
diff --git a/arch/arm/mach-shmobile/clock-r8a7790.c b/arch/arm/mach-shmobile/clock-r8a7790.c
new file mode 100644
index 0000000..6869798
--- /dev/null
+++ b/arch/arm/mach-shmobile/clock-r8a7790.c
@@ -0,0 +1,61 @@
+/*
+ * r8a7790 clock framework support
+ *
+ * Copyright (C) 2013  Renesas Solutions Corp.
+ * Copyright (C) 2013  Magnus Damm
+ *
+ * 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; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
+ */
+#include <linux/init.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/sh_clk.h>
+#include <linux/clkdev.h>
+#include <mach/common.h>
+
+#define CPG_BASE 0xe6150000
+#define CPG_LEN 0x1000
+
+static struct clk_mapping cpg_mapping = {
+	.phys   = CPG_BASE,
+	.len    = CPG_LEN,
+};
+
+static struct clk *main_clks[] = {
+};
+
+enum { MSTP_NR };
+static struct clk mstp_clks[MSTP_NR] = {
+};
+
+static struct clk_lookup lookups[] = {
+};
+
+void __init r8a7790_clock_init(void)
+{
+	int k, ret = 0;
+
+	for (k = 0; !ret && (k < ARRAY_SIZE(main_clks)); k++)
+		ret = clk_register(main_clks[k]);
+
+	if (!ret)
+		ret = sh_clk_mstp_register(mstp_clks, MSTP_NR);
+
+	clkdev_add_table(lookups, ARRAY_SIZE(lookups));
+
+	if (!ret)
+		shmobile_clk_init();
+	else
+		panic("failed to setup r8a7790 clocks\n");
+}
diff --git a/arch/arm/mach-shmobile/include/mach/r8a7790.h b/arch/arm/mach-shmobile/include/mach/r8a7790.h
new file mode 100644
index 0000000..f38ded6
--- /dev/null
+++ b/arch/arm/mach-shmobile/include/mach/r8a7790.h
@@ -0,0 +1,7 @@
+#ifndef __ASM_R8A7790_H__
+#define __ASM_R8A7790_H__
+
+void r8a7790_add_standard_devices(void);
+void r8a7790_clock_init(void);
+
+#endif /* __ASM_R8A7790_H__ */
diff --git a/arch/arm/mach-shmobile/setup-r8a7790.c b/arch/arm/mach-shmobile/setup-r8a7790.c
new file mode 100644
index 0000000..af432ba
--- /dev/null
+++ b/arch/arm/mach-shmobile/setup-r8a7790.c
@@ -0,0 +1,51 @@
+/*
+ * r8a7790 processor support
+ *
+ * Copyright (C) 2013  Renesas Solutions Corp.
+ * Copyright (C) 2013  Magnus Damm
+ *
+ * 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; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
+ */
+
+#include <linux/irq.h>
+#include <linux/irqchip.h>
+#include <linux/kernel.h>
+#include <linux/of_platform.h>
+#include <mach/common.h>
+#include <mach/irqs.h>
+#include <mach/r8a7790.h>
+#include <asm/mach/arch.h>
+
+void __init r8a7790_add_standard_devices(void)
+{
+}
+
+#ifdef CONFIG_USE_OF
+void __init r8a7790_add_standard_devices_dt(void)
+{
+	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
+}
+
+static const char *r8a7790_boards_compat_dt[] __initdata = {
+	"renesas,r8a7790",
+	NULL,
+};
+
+DT_MACHINE_START(R8A7790_DT, "Generic R8A7790 (Flattened Device Tree)")
+	.init_irq	= irqchip_init,
+	.init_machine	= r8a7790_add_standard_devices_dt,
+	.init_time	= shmobile_timer_init,
+	.dt_compat	= r8a7790_boards_compat_dt,
+MACHINE_END
+#endif /* CONFIG_USE_OF */
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 01:07:25 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue,  2 Apr 2013 14:07:25 +0900
Subject: [PATCH 29/30] ARM: shmobile: r8a73a4 SoC 64-bit DT support
In-Reply-To: <1364879246-9470-1-git-send-email-horms+renesas@verge.net.au>
References: <1364879246-9470-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364879246-9470-30-git-send-email-horms+renesas@verge.net.au>

From: Takashi Yoshii <takashi.yoshii.zj at renesas.com>

The r8a73a4 SoC supports LPAE and has memory window up to
0x2ffffffff. Convert to 64-bit addresses by enlarging
#addr-cells and #size-cells to 2.

Signed-off-by: Takashi Yoshii <takashi.yoshii.zj at renesas.com>
Signed-off-by: Magnus Damm <damm at opensource.se>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a73a4.dtsi |   20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/arch/arm/boot/dts/r8a73a4.dtsi b/arch/arm/boot/dts/r8a73a4.dtsi
index 7db5b50..fde2a33 100644
--- a/arch/arm/boot/dts/r8a73a4.dtsi
+++ b/arch/arm/boot/dts/r8a73a4.dtsi
@@ -9,11 +9,11 @@
  * kind, whether express or implied.
  */
 
-/include/ "skeleton.dtsi"
-
 / {
 	compatible = "renesas,r8a73a4";
 	interrupt-parent = <&gic>;
+	#address-cells = <2>;
+	#size-cells = <2>;
 
 	cpus {
 		#address-cells = <1>;
@@ -32,10 +32,10 @@
 		#interrupt-cells = <3>;
 		#address-cells = <0>;
 		interrupt-controller;
-		reg = <0xf1001000 0x1000>,
-			<0xf1002000 0x1000>,
-			<0xf1004000 0x2000>,
-			<0xf1006000 0x2000>;
+		reg = <0 0xf1001000 0 0x1000>,
+			<0 0xf1002000 0 0x1000>,
+			<0 0xf1004000 0 0x2000>,
+			<0 0xf1006000 0 0x2000>;
 		interrupts = <1 9 0xf04>;
 
 		gic-cpuif at 4 {
@@ -57,7 +57,7 @@
 		compatible = "renesas,irqc";
 		#interrupt-cells = <2>;
 		interrupt-controller;
-		reg = <0xe61c0000 0x200>;
+		reg = <0 0xe61c0000 0 0x200>;
 		interrupt-parent = <&gic>;
 		interrupts = <0 0 4>, <0 1 4>, <0 2 4>,	<0 3 4>,
 				<0 4 4>, <0 5 4>, <0 6 4>, <0 7 4>,
@@ -73,7 +73,7 @@
 		compatible = "renesas,irqc";
 		#interrupt-cells = <2>;
 		interrupt-controller;
-		reg = <0xe61c0200 0x200>;
+		reg = <0 0xe61c0200 0 0x200>;
 		interrupt-parent = <&gic>;
 		interrupts = <0 32 4>, <0 33 4>, <0 34 4>, <0 35 4>,
 				<0 36 4>, <0 37 4>, <0 38 4>, <0 39 4>,
@@ -86,8 +86,8 @@
 
 	thermal at e61f0000 {
 		compatible = "renesas,rcar-thermal";
-		reg = <0xe61f0000 0x14>, <0xe61f0100 0x38>,
-			 <0xe61f0200 0x38>, <0xe61f0300 0x38>;
+		reg = <0 0xe61f0000 0 0x14>, <0 0xe61f0100 0 0x38>,
+			 <0 0xe61f0200 0 0x38>, <0 0xe61f0300 0 0x38>;
 		interrupt-parent = <&gic>;
 		interrupts = <0 69 4>;
 	};
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 01:07:20 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue,  2 Apr 2013 14:07:20 +0900
Subject: [PATCH 24/30] ARM: shmobile: r8a7779: move global functions to
 r8a7779.h
In-Reply-To: <1364879246-9470-1-git-send-email-horms+renesas@verge.net.au>
References: <1364879246-9470-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364879246-9470-25-git-send-email-horms+renesas@verge.net.au>

From: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>

There is no reason each CPU's own function has to exist in common.h.
r8a7779_xxx() go to r8a7779.h

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Acked-by: Magnus Damm <damm at opensource.se>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/include/mach/common.h  |   14 --------------
 arch/arm/mach-shmobile/include/mach/r8a7779.h |   13 +++++++++++++
 2 files changed, 13 insertions(+), 14 deletions(-)

diff --git a/arch/arm/mach-shmobile/include/mach/common.h b/arch/arm/mach-shmobile/include/mach/common.h
index 4d5410d..e002cfd 100644
--- a/arch/arm/mach-shmobile/include/mach/common.h
+++ b/arch/arm/mach-shmobile/include/mach/common.h
@@ -19,20 +19,6 @@ extern int shmobile_enter_wfi(struct cpuidle_device *dev,
 			      struct cpuidle_driver *drv, int index);
 extern void shmobile_cpuidle_set_driver(struct cpuidle_driver *drv);
 
-extern void r8a7779_init_delay(void);
-extern void r8a7779_init_irq(void);
-extern void r8a7779_init_irq_extpin(int irlm);
-extern void r8a7779_init_irq_dt(void);
-extern void r8a7779_map_io(void);
-extern void r8a7779_earlytimer_init(void);
-extern void r8a7779_add_early_devices(void);
-extern void r8a7779_add_standard_devices(void);
-extern void r8a7779_add_standard_devices_dt(void);
-extern void r8a7779_clock_init(void);
-extern void r8a7779_pinmux_init(void);
-extern void r8a7779_pm_init(void);
-extern void r8a7779_register_twd(void);
-
 #ifdef CONFIG_SUSPEND
 int shmobile_suspend_init(void);
 #else
diff --git a/arch/arm/mach-shmobile/include/mach/r8a7779.h b/arch/arm/mach-shmobile/include/mach/r8a7779.h
index 8ab0cd6..af38750 100644
--- a/arch/arm/mach-shmobile/include/mach/r8a7779.h
+++ b/arch/arm/mach-shmobile/include/mach/r8a7779.h
@@ -343,6 +343,19 @@ static inline struct r8a7779_pm_ch *to_r8a7779_ch(struct generic_pm_domain *d)
 	return &container_of(d, struct r8a7779_pm_domain, genpd)->ch;
 }
 
+extern void r8a7779_init_delay(void);
+extern void r8a7779_init_irq(void);
+extern void r8a7779_init_irq_extpin(int irlm);
+extern void r8a7779_init_irq_dt(void);
+extern void r8a7779_map_io(void);
+extern void r8a7779_earlytimer_init(void);
+extern void r8a7779_add_early_devices(void);
+extern void r8a7779_add_standard_devices(void);
+extern void r8a7779_add_standard_devices_dt(void);
+extern void r8a7779_clock_init(void);
+extern void r8a7779_pinmux_init(void);
+extern void r8a7779_pm_init(void);
+extern void r8a7779_register_twd(void);
 extern int r8a7779_sysc_power_down(struct r8a7779_pm_ch *r8a7779_ch);
 extern int r8a7779_sysc_power_up(struct r8a7779_pm_ch *r8a7779_ch);
 
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 01:07:15 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue,  2 Apr 2013 14:07:15 +0900
Subject: [PATCH 19/30] ARM: shmobile: r8a7740: use fixed ratio clock
In-Reply-To: <1364879246-9470-1-git-send-email-horms+renesas@verge.net.au>
References: <1364879246-9470-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364879246-9470-20-git-send-email-horms+renesas@verge.net.au>

From: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>

Current clock-r8a7740 is using own implement
for each divX clocks.
This patch switches to use fixed ratio clock,
and was tesed on armadillo board.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Acked-by: Magnus Damm <damm at opensource.se>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/clock-r8a7740.c |   54 ++++++--------------------------
 1 file changed, 9 insertions(+), 45 deletions(-)

diff --git a/arch/arm/mach-shmobile/clock-r8a7740.c b/arch/arm/mach-shmobile/clock-r8a7740.c
index 161e128..c0d39aa 100644
--- a/arch/arm/mach-shmobile/clock-r8a7740.c
+++ b/arch/arm/mach-shmobile/clock-r8a7740.c
@@ -22,6 +22,7 @@
 #include <linux/io.h>
 #include <linux/sh_clk.h>
 #include <linux/clkdev.h>
+#include <mach/clock.h>
 #include <mach/common.h>
 #include <mach/r8a7740.h>
 
@@ -97,42 +98,13 @@ static struct clk dv_clk = {
 	.rate	= 27000000,
 };
 
-static unsigned long div_recalc(struct clk *clk)
-{
-	return clk->parent->rate / (int)(clk->priv);
-}
-
-static struct sh_clk_ops div_clk_ops = {
-	.recalc	= div_recalc,
-};
+SH_CLK_RATIO(div2,	1, 2);
+SH_CLK_RATIO(div1k,	1, 1024);
 
-/* extal1 / 2 */
-static struct clk extal1_div2_clk = {
-	.ops	= &div_clk_ops,
-	.priv	= (void *)2,
-	.parent	= &extal1_clk,
-};
-
-/* extal1 / 1024 */
-static struct clk extal1_div1024_clk = {
-	.ops	= &div_clk_ops,
-	.priv	= (void *)1024,
-	.parent	= &extal1_clk,
-};
-
-/* extal1 / 2 / 1024 */
-static struct clk extal1_div2048_clk = {
-	.ops	= &div_clk_ops,
-	.priv	= (void *)1024,
-	.parent	= &extal1_div2_clk,
-};
-
-/* extal2 / 2 */
-static struct clk extal2_div2_clk = {
-	.ops	= &div_clk_ops,
-	.priv	= (void *)2,
-	.parent	= &extal2_clk,
-};
+SH_FIXED_RATIO_CLK(extal1_div2_clk,	extal1_clk,		div2);
+SH_FIXED_RATIO_CLK(extal1_div1024_clk,	extal1_clk,		div1k);
+SH_FIXED_RATIO_CLK(extal1_div2048_clk,	extal1_div2_clk,	div1k);
+SH_FIXED_RATIO_CLK(extal2_div2_clk,	extal2_clk,		div2);
 
 static struct sh_clk_ops followparent_clk_ops = {
 	.recalc	= followparent_recalc,
@@ -143,11 +115,7 @@ static struct clk system_clk = {
 	.ops	= &followparent_clk_ops,
 };
 
-static struct clk system_div2_clk = {
-	.ops	= &div_clk_ops,
-	.priv	= (void *)2,
-	.parent	= &system_clk,
-};
+SH_FIXED_RATIO_CLK(system_div2_clk, system_clk,	div2);
 
 /* r_clk */
 static struct clk r_clk = {
@@ -184,11 +152,7 @@ static struct clk pllc1_clk = {
 };
 
 /* PLLC1 / 2 */
-static struct clk pllc1_div2_clk = {
-	.ops		= &div_clk_ops,
-	.priv		= (void *)2,
-	.parent		= &pllc1_clk,
-};
+SH_FIXED_RATIO_CLK(pllc1_div2_clk, pllc1_clk, div2);
 
 /* USB clock */
 /*
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 01:07:26 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue,  2 Apr 2013 14:07:26 +0900
Subject: [PATCH 30/30] ARM: shmobile: r8a7790 SoC 64-bit DT support
In-Reply-To: <1364879246-9470-1-git-send-email-horms+renesas@verge.net.au>
References: <1364879246-9470-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364879246-9470-31-git-send-email-horms+renesas@verge.net.au>

From: Takashi Yoshii <takashi.yoshii.zj at renesas.com>

The r8a7790 SoC supports LPAE and has memory window up to
0x2ffffffff. Convert to 64-bit addresses by enlarging
#addr-cells and #size-cells to 2.

Signed-off-by: Takashi Yoshii <takashi.yoshii.zj at renesas.com>
Signed-off-by: Magnus Damm <damm at opensource.se>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7790.dtsi |   14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index a1e0e0c..7a17110 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -8,11 +8,11 @@
  * kind, whether express or implied.
  */
 
-/include/ "skeleton.dtsi"
-
 / {
 	compatible = "renesas,r8a7790";
 	interrupt-parent = <&gic>;
+	#address-cells = <2>;
+	#size-cells = <2>;
 
 	cpus {
 		#address-cells = <1>;
@@ -31,10 +31,10 @@
 		#interrupt-cells = <3>;
 		#address-cells = <0>;
 		interrupt-controller;
-		reg = <0xf1001000 0x1000>,
-			<0xf1002000 0x1000>,
-			<0xf1004000 0x2000>,
-			<0xf1006000 0x2000>;
+		reg = <0 0xf1001000 0 0x1000>,
+			<0 0xf1002000 0 0x1000>,
+			<0 0xf1004000 0 0x2000>,
+			<0 0xf1006000 0 0x2000>;
 		interrupts = <1 9 0xf04>;
 
 		gic-cpuif at 4 {
@@ -56,7 +56,7 @@
 		compatible = "renesas,irqc";
 		#interrupt-cells = <2>;
 		interrupt-controller;
-		reg = <0xe61c0000 0x200>;
+		reg = <0 0xe61c0000 0 0x200>;
 		interrupt-parent = <&gic>;
 		interrupts = <0 0 4>, <0 1 4>, <0 2 4>,	<0 3 4>;
 	};
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 01:07:13 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue,  2 Apr 2013 14:07:13 +0900
Subject: [PATCH 17/30] ARM: shmobile: sh73a0: use fixed ratio clock
In-Reply-To: <1364879246-9470-1-git-send-email-horms+renesas@verge.net.au>
References: <1364879246-9470-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364879246-9470-18-git-send-email-horms+renesas@verge.net.au>

From: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>

Current clock-sh73a0 is using own implement
for each divX clocks.
This patch switches to use fixed ratio clock,
and was tesed on kzm9g board.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Acked-by: Magnus Damm <damm at opensource.se>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/clock-sh73a0.c |   72 ++++++---------------------------
 1 file changed, 12 insertions(+), 60 deletions(-)

diff --git a/arch/arm/mach-shmobile/clock-sh73a0.c b/arch/arm/mach-shmobile/clock-sh73a0.c
index 26a5803..784fbaa 100644
--- a/arch/arm/mach-shmobile/clock-sh73a0.c
+++ b/arch/arm/mach-shmobile/clock-sh73a0.c
@@ -22,6 +22,7 @@
 #include <linux/sh_clk.h>
 #include <linux/clkdev.h>
 #include <asm/processor.h>
+#include <mach/clock.h>
 #include <mach/common.h>
 
 #define FRQCRA		IOMEM(0xe6150000)
@@ -83,61 +84,16 @@ struct clk sh73a0_extal2_clk = {
 	.rate		= 48000000,
 };
 
-/* A fixed divide-by-2 block */
-static unsigned long div2_recalc(struct clk *clk)
-{
-	return clk->parent->rate / 2;
-}
-
-static struct sh_clk_ops div2_clk_ops = {
-	.recalc		= div2_recalc,
-};
-
-static unsigned long div7_recalc(struct clk *clk)
-{
-	return clk->parent->rate / 7;
-}
-
-static struct sh_clk_ops div7_clk_ops = {
-	.recalc		= div7_recalc,
-};
-
-static unsigned long div13_recalc(struct clk *clk)
-{
-	return clk->parent->rate / 13;
-}
-
-static struct sh_clk_ops div13_clk_ops = {
-	.recalc		= div13_recalc,
-};
-
-/* Divide extal1 by two */
-static struct clk extal1_div2_clk = {
-	.ops		= &div2_clk_ops,
-	.parent		= &sh73a0_extal1_clk,
-};
-
-/* Divide extal2 by two */
-static struct clk extal2_div2_clk = {
-	.ops		= &div2_clk_ops,
-	.parent		= &sh73a0_extal2_clk,
-};
-
 static struct sh_clk_ops main_clk_ops = {
 	.recalc		= followparent_recalc,
 };
 
 /* Main clock */
 static struct clk main_clk = {
+	/* .parent wll be set on sh73a0_clock_init() */
 	.ops		= &main_clk_ops,
 };
 
-/* Divide Main clock by two */
-static struct clk main_div2_clk = {
-	.ops		= &div2_clk_ops,
-	.parent		= &main_clk,
-};
-
 /* PLL0, PLL1, PLL2, PLL3 */
 static unsigned long pll_recalc(struct clk *clk)
 {
@@ -193,21 +149,17 @@ static struct clk pll3_clk = {
 	.enable_bit	= 3,
 };
 
-/* Divide PLL */
-static struct clk pll1_div2_clk = {
-	.ops		= &div2_clk_ops,
-	.parent		= &pll1_clk,
-};
-
-static struct clk pll1_div7_clk = {
-	.ops		= &div7_clk_ops,
-	.parent		= &pll1_clk,
-};
+/* A fixed divide block */
+SH_CLK_RATIO(div2,  1, 2);
+SH_CLK_RATIO(div7,  1, 7);
+SH_CLK_RATIO(div13, 1, 13);
 
-static struct clk pll1_div13_clk = {
-	.ops		= &div13_clk_ops,
-	.parent		= &pll1_clk,
-};
+SH_FIXED_RATIO_CLK(extal1_div2_clk,	sh73a0_extal1_clk,	div2);
+SH_FIXED_RATIO_CLK(extal2_div2_clk,	sh73a0_extal2_clk,	div2);
+SH_FIXED_RATIO_CLK(main_div2_clk,	main_clk,		div2);
+SH_FIXED_RATIO_CLK(pll1_div2_clk,	pll1_clk,		div2);
+SH_FIXED_RATIO_CLK(pll1_div7_clk,	pll1_clk,		div7);
+SH_FIXED_RATIO_CLK(pll1_div13_clk,	pll1_clk,		div13);
 
 /* External input clock */
 struct clk sh73a0_extcki_clk = {
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 01:07:22 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue,  2 Apr 2013 14:07:22 +0900
Subject: [PATCH 26/30] ARM: shmobile: r8a7790 SCIF support
In-Reply-To: <1364879246-9470-1-git-send-email-horms+renesas@verge.net.au>
References: <1364879246-9470-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364879246-9470-27-git-send-email-horms+renesas@verge.net.au>

From: Magnus Damm <damm at opensource.se>

Add SCIF serial port support to the r8a7790 SoC by
adding platform devices for SCIFA0 -> SCIFA2 as well
as SCIFB0 -> SCIFB2 and SCIF0 -> SCIF1 together with
clock bindings. DT device description is excluded at
this point since such bindings are still under
development.

Signed-off-by: Magnus Damm <damm at opensource.se>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/clock-r8a7790.c |   34 +++++++++++++++++++-
 arch/arm/mach-shmobile/setup-r8a7790.c |   55 ++++++++++++++++++++++++++++++++
 2 files changed, 88 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-shmobile/clock-r8a7790.c b/arch/arm/mach-shmobile/clock-r8a7790.c
index 6869798..bad9bf2 100644
--- a/arch/arm/mach-shmobile/clock-r8a7790.c
+++ b/arch/arm/mach-shmobile/clock-r8a7790.c
@@ -27,19 +27,51 @@
 #define CPG_BASE 0xe6150000
 #define CPG_LEN 0x1000
 
+#define SMSTPCR2 0xe6150138
+#define SMSTPCR7 0xe615014c
+
 static struct clk_mapping cpg_mapping = {
 	.phys   = CPG_BASE,
 	.len    = CPG_LEN,
 };
 
+static struct clk p_clk = {
+	.rate	= 65000000, /* shortcut for now */
+	.mapping	= &cpg_mapping,
+};
+
+static struct clk mp_clk = {
+	.rate	= 52000000,  /* shortcut for now */
+	.mapping	= &cpg_mapping,
+};
+
 static struct clk *main_clks[] = {
+	&p_clk,
+	&mp_clk,
 };
 
-enum { MSTP_NR };
+enum { MSTP721, MSTP720,
+	MSTP216, MSTP207, MSTP206, MSTP204, MSTP203, MSTP202, MSTP_NR };
 static struct clk mstp_clks[MSTP_NR] = {
+	[MSTP721] = SH_CLK_MSTP32(&p_clk, SMSTPCR7, 21, 0), /* SCIF0 */
+	[MSTP720] = SH_CLK_MSTP32(&p_clk, SMSTPCR7, 20, 0), /* SCIF1 */
+	[MSTP216] = SH_CLK_MSTP32(&mp_clk, SMSTPCR2, 16, 0), /* SCIFB2 */
+	[MSTP207] = SH_CLK_MSTP32(&mp_clk, SMSTPCR2, 7, 0), /* SCIFB1 */
+	[MSTP206] = SH_CLK_MSTP32(&mp_clk, SMSTPCR2, 6, 0), /* SCIFB0 */
+	[MSTP204] = SH_CLK_MSTP32(&mp_clk, SMSTPCR2, 4, 0), /* SCIFA0 */
+	[MSTP203] = SH_CLK_MSTP32(&mp_clk, SMSTPCR2, 3, 0), /* SCIFA1 */
+	[MSTP202] = SH_CLK_MSTP32(&mp_clk, SMSTPCR2, 2, 0), /* SCIFA2 */
 };
 
 static struct clk_lookup lookups[] = {
+	CLKDEV_DEV_ID("sh-sci.0", &mstp_clks[MSTP204]),
+	CLKDEV_DEV_ID("sh-sci.1", &mstp_clks[MSTP203]),
+	CLKDEV_DEV_ID("sh-sci.2", &mstp_clks[MSTP206]),
+	CLKDEV_DEV_ID("sh-sci.3", &mstp_clks[MSTP207]),
+	CLKDEV_DEV_ID("sh-sci.4", &mstp_clks[MSTP216]),
+	CLKDEV_DEV_ID("sh-sci.5", &mstp_clks[MSTP202]),
+	CLKDEV_DEV_ID("sh-sci.6", &mstp_clks[MSTP721]),
+	CLKDEV_DEV_ID("sh-sci.7", &mstp_clks[MSTP720]),
 };
 
 void __init r8a7790_clock_init(void)
diff --git a/arch/arm/mach-shmobile/setup-r8a7790.c b/arch/arm/mach-shmobile/setup-r8a7790.c
index af432ba..3bb5bf1 100644
--- a/arch/arm/mach-shmobile/setup-r8a7790.c
+++ b/arch/arm/mach-shmobile/setup-r8a7790.c
@@ -22,13 +22,68 @@
 #include <linux/irqchip.h>
 #include <linux/kernel.h>
 #include <linux/of_platform.h>
+#include <linux/serial_sci.h>
 #include <mach/common.h>
 #include <mach/irqs.h>
 #include <mach/r8a7790.h>
 #include <asm/mach/arch.h>
 
+#define SCIF_COMMON(scif_type, baseaddr, irq)			\
+	.type		= scif_type,				\
+	.mapbase	= baseaddr,				\
+	.flags		= UPF_BOOT_AUTOCONF | UPF_IOREMAP,	\
+	.irqs		= SCIx_IRQ_MUXED(irq)
+
+#define SCIFA_DATA(index, baseaddr, irq)		\
+[index] = {						\
+	SCIF_COMMON(PORT_SCIFA, baseaddr, irq),		\
+	.scbrr_algo_id	= SCBRR_ALGO_4,			\
+	.scscr = SCSCR_RE | SCSCR_TE | SCSCR_CKE0,	\
+}
+
+#define SCIFB_DATA(index, baseaddr, irq)	\
+[index] = {					\
+	SCIF_COMMON(PORT_SCIFB, baseaddr, irq),	\
+	.scbrr_algo_id	= SCBRR_ALGO_4,		\
+	.scscr = SCSCR_RE | SCSCR_TE,		\
+}
+
+#define SCIF_DATA(index, baseaddr, irq)		\
+[index] = {						\
+	SCIF_COMMON(PORT_SCIF, baseaddr, irq),		\
+	.scbrr_algo_id	= SCBRR_ALGO_2,			\
+	.scscr = SCSCR_RE | SCSCR_TE | SCSCR_CKE1,	\
+}
+
+enum { SCIFA0, SCIFA1, SCIFB0, SCIFB1, SCIFB2, SCIFA2, SCIF0, SCIF1 };
+
+static const struct plat_sci_port scif[] = {
+	SCIFA_DATA(SCIFA0, 0xe6c40000, gic_spi(144)), /* SCIFA0 */
+	SCIFA_DATA(SCIFA1, 0xe6c50000, gic_spi(145)), /* SCIFA1 */
+	SCIFB_DATA(SCIFB0, 0xe6c20000, gic_spi(148)), /* SCIFB0 */
+	SCIFB_DATA(SCIFB1, 0xe6c30000, gic_spi(149)), /* SCIFB1 */
+	SCIFB_DATA(SCIFB2, 0xe6ce0000, gic_spi(150)), /* SCIFB2 */
+	SCIFA_DATA(SCIFA2, 0xe6c60000, gic_spi(151)), /* SCIFA2 */
+	SCIF_DATA(SCIF0, 0xe6e60000, gic_spi(152)), /* SCIF0 */
+	SCIF_DATA(SCIF1, 0xe6e68000, gic_spi(153)), /* SCIF1 */
+};
+
+static inline void r8a7790_register_scif(int idx)
+{
+	platform_device_register_data(&platform_bus, "sh-sci", idx, &scif[idx],
+				      sizeof(struct plat_sci_port));
+}
+
 void __init r8a7790_add_standard_devices(void)
 {
+	r8a7790_register_scif(SCIFA0);
+	r8a7790_register_scif(SCIFA1);
+	r8a7790_register_scif(SCIFB0);
+	r8a7790_register_scif(SCIFB1);
+	r8a7790_register_scif(SCIFB2);
+	r8a7790_register_scif(SCIFA2);
+	r8a7790_register_scif(SCIF0);
+	r8a7790_register_scif(SCIF1);
 }
 
 #ifdef CONFIG_USE_OF
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 01:07:23 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue,  2 Apr 2013 14:07:23 +0900
Subject: [PATCH 27/30] ARM: shmobile: r8a7790 IRQC support
In-Reply-To: <1364879246-9470-1-git-send-email-horms+renesas@verge.net.au>
References: <1364879246-9470-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364879246-9470-28-git-send-email-horms+renesas@verge.net.au>

From: Magnus Damm <damm at opensource.se>

Add IRQC interrupt controller support to r8a7790 by
hooking up a single IRQC instances to handle 4 external
IRQ signals. The IRQC controller is tied to SPIs of
the GIC. On r8a7790 the external IRQ pins routing is
handled by the PFC which is excluded from this patch.

Both platform devices and DT devices are added in this
patch. The platform device versions are used to provide
a static interrupt map configuration for board code
written in C.

Signed-off-by: Magnus Damm <damm at opensource.se>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7790.dtsi         |    9 +++++++++
 arch/arm/mach-shmobile/Kconfig         |    1 +
 arch/arm/mach-shmobile/setup-r8a7790.c |   21 +++++++++++++++++++++
 3 files changed, 31 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index 1c58ffb..a1e0e0c 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -51,4 +51,13 @@
 				<1 11 0xf08>,
 				<1 10 0xf08>;
 	};
+
+	irqc0: interrupt-controller at e61c0000 {
+		compatible = "renesas,irqc";
+		#interrupt-cells = <2>;
+		interrupt-controller;
+		reg = <0xe61c0000 0x200>;
+		interrupt-parent = <&gic>;
+		interrupts = <0 0 4>, <0 1 4>, <0 2 4>,	<0 3 4>;
+	};
 };
diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index 749dfb4..ccaea6a 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -57,6 +57,7 @@ config ARCH_R8A7790
 	select CPU_V7
 	select ARM_ARCH_TIMER
 	select SH_CLK_CPG
+	select RENESAS_IRQC
 
 config ARCH_EMEV2
 	bool "Emma Mobile EV2"
diff --git a/arch/arm/mach-shmobile/setup-r8a7790.c b/arch/arm/mach-shmobile/setup-r8a7790.c
index 3bb5bf1..9b4ccd7 100644
--- a/arch/arm/mach-shmobile/setup-r8a7790.c
+++ b/arch/arm/mach-shmobile/setup-r8a7790.c
@@ -23,6 +23,7 @@
 #include <linux/kernel.h>
 #include <linux/of_platform.h>
 #include <linux/serial_sci.h>
+#include <linux/platform_data/irq-renesas-irqc.h>
 #include <mach/common.h>
 #include <mach/irqs.h>
 #include <mach/r8a7790.h>
@@ -74,6 +75,25 @@ static inline void r8a7790_register_scif(int idx)
 				      sizeof(struct plat_sci_port));
 }
 
+static struct renesas_irqc_config irqc0_data = {
+	.irq_base = irq_pin(0), /* IRQ0 -> IRQ3 */
+};
+
+static struct resource irqc0_resources[] = {
+	DEFINE_RES_MEM(0xe61c0000, 0x200), /* IRQC Event Detector Block_0 */
+	DEFINE_RES_IRQ(gic_spi(0)), /* IRQ0 */
+	DEFINE_RES_IRQ(gic_spi(1)), /* IRQ1 */
+	DEFINE_RES_IRQ(gic_spi(2)), /* IRQ2 */
+	DEFINE_RES_IRQ(gic_spi(3)), /* IRQ3 */
+};
+
+#define r8a7790_register_irqc(idx)					\
+	platform_device_register_resndata(&platform_bus, "renesas_irqc", \
+					  idx, irqc##idx##_resources,	\
+					  ARRAY_SIZE(irqc##idx##_resources), \
+					  &irqc##idx##_data,		\
+					  sizeof(struct renesas_irqc_config))
+
 void __init r8a7790_add_standard_devices(void)
 {
 	r8a7790_register_scif(SCIFA0);
@@ -84,6 +104,7 @@ void __init r8a7790_add_standard_devices(void)
 	r8a7790_register_scif(SCIFA2);
 	r8a7790_register_scif(SCIF0);
 	r8a7790_register_scif(SCIF1);
+	r8a7790_register_irqc(0);
 }
 
 #ifdef CONFIG_USE_OF
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 01:07:16 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue,  2 Apr 2013 14:07:16 +0900
Subject: [PATCH 20/30] ARM: shmobile: r8a7779: remove DIV4 clocks and use
 fixed ratio clock
In-Reply-To: <1364879246-9470-1-git-send-email-horms+renesas@verge.net.au>
References: <1364879246-9470-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364879246-9470-21-git-send-email-horms+renesas@verge.net.au>

From: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>

R-Car H1 has many clocks, and it is possible to read/use clock ratio
of these clocks from FRQMRx as DIV4 clocks.
But, these ratio are fixed value and these are decided
by MD pin status.
This means that we can use fixed ratio clock via MD pin status,
instead of DIV4 clocks.

This patch reads MD pin status, and sets PLLA clock (= root clock),
and used fixed ratio clock for other clocks.
It was tesed on marzen board.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Acked-by: Magnus Damm <damm at opensource.se>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/clock-r8a7779.c |  196 ++++++++++++++++++--------------
 1 file changed, 109 insertions(+), 87 deletions(-)

diff --git a/arch/arm/mach-shmobile/clock-r8a7779.c b/arch/arm/mach-shmobile/clock-r8a7779.c
index d9edeaf..7d86bfb 100644
--- a/arch/arm/mach-shmobile/clock-r8a7779.c
+++ b/arch/arm/mach-shmobile/clock-r8a7779.c
@@ -17,13 +17,17 @@
  * along with this program; if not, write to the Free Software
  * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
  */
+#include <linux/bitops.h>
 #include <linux/init.h>
 #include <linux/kernel.h>
 #include <linux/io.h>
 #include <linux/sh_clk.h>
 #include <linux/clkdev.h>
+#include <mach/clock.h>
 #include <mach/common.h>
 
+#define MD(nr)	BIT(nr)
+
 #define FRQMR		IOMEM(0xffc80014)
 #define MSTPCR0		IOMEM(0xffc80030)
 #define MSTPCR1		IOMEM(0xffc80034)
@@ -36,6 +40,9 @@
 #define MSTPCR6		IOMEM(0xffc80058)
 #define MSTPCR7		IOMEM(0xffc80040)
 
+#define MODEMR		0xffcc0020
+
+
 /* ioremap() through clock mapping mandatory to avoid
  * collision with ARM coherent DMA virtual memory range.
  */
@@ -50,40 +57,39 @@ static struct clk_mapping cpg_mapping = {
  * from the platform code.
  */
 static struct clk plla_clk = {
-	.rate		= 1500000000,
+	/* .rate will be updated on r8a7779_clock_init() */
 	.mapping	= &cpg_mapping,
 };
 
+/*
+ * clock ratio of these clock will be updated
+ * on r8a7779_clock_init()
+ */
+SH_FIXED_RATIO_CLK_SET(clkz_clk,	plla_clk, 1, 1);
+SH_FIXED_RATIO_CLK_SET(clkzs_clk,	plla_clk, 1, 1);
+SH_FIXED_RATIO_CLK_SET(clki_clk,	plla_clk, 1, 1);
+SH_FIXED_RATIO_CLK_SET(clks_clk,	plla_clk, 1, 1);
+SH_FIXED_RATIO_CLK_SET(clks1_clk,	plla_clk, 1, 1);
+SH_FIXED_RATIO_CLK_SET(clks3_clk,	plla_clk, 1, 1);
+SH_FIXED_RATIO_CLK_SET(clks4_clk,	plla_clk, 1, 1);
+SH_FIXED_RATIO_CLK_SET(clkb_clk,	plla_clk, 1, 1);
+SH_FIXED_RATIO_CLK_SET(clkout_clk,	plla_clk, 1, 1);
+SH_FIXED_RATIO_CLK_SET(clkp_clk,	plla_clk, 1, 1);
+SH_FIXED_RATIO_CLK_SET(clkg_clk,	plla_clk, 1, 1);
+
 static struct clk *main_clks[] = {
 	&plla_clk,
-};
-
-static int divisors[] = { 0, 0, 0, 6, 8, 12, 16, 0, 24, 32, 36, 0, 0, 0, 0, 0 };
-
-static struct clk_div_mult_table div4_div_mult_table = {
-	.divisors = divisors,
-	.nr_divisors = ARRAY_SIZE(divisors),
-};
-
-static struct clk_div4_table div4_table = {
-	.div_mult_table = &div4_div_mult_table,
-};
-
-enum { DIV4_S, DIV4_OUT, DIV4_S4, DIV4_S3, DIV4_S1, DIV4_P, DIV4_NR };
-
-static struct clk div4_clks[DIV4_NR] = {
-	[DIV4_S]	= SH_CLK_DIV4(&plla_clk, FRQMR, 20,
-				      0x0018, CLK_ENABLE_ON_INIT),
-	[DIV4_OUT]	= SH_CLK_DIV4(&plla_clk, FRQMR, 16,
-				      0x0700, CLK_ENABLE_ON_INIT),
-	[DIV4_S4]	= SH_CLK_DIV4(&plla_clk, FRQMR, 12,
-				      0x0040, CLK_ENABLE_ON_INIT),
-	[DIV4_S3]	= SH_CLK_DIV4(&plla_clk, FRQMR, 8,
-				      0x0010, CLK_ENABLE_ON_INIT),
-	[DIV4_S1]	= SH_CLK_DIV4(&plla_clk, FRQMR, 4,
-				      0x0060, CLK_ENABLE_ON_INIT),
-	[DIV4_P]	= SH_CLK_DIV4(&plla_clk, FRQMR, 0,
-				      0x0300, CLK_ENABLE_ON_INIT),
+	&clkz_clk,
+	&clkzs_clk,
+	&clki_clk,
+	&clks_clk,
+	&clks1_clk,
+	&clks3_clk,
+	&clks4_clk,
+	&clkb_clk,
+	&clkout_clk,
+	&clkp_clk,
+	&clkg_clk,
 };
 
 enum { MSTP323, MSTP322, MSTP321, MSTP320,
@@ -96,52 +102,28 @@ enum { MSTP323, MSTP322, MSTP321, MSTP320,
 	MSTP_NR };
 
 static struct clk mstp_clks[MSTP_NR] = {
-	[MSTP323] = SH_CLK_MSTP32(&div4_clks[DIV4_P], MSTPCR3, 23, 0), /* SDHI0 */
-	[MSTP322] = SH_CLK_MSTP32(&div4_clks[DIV4_P], MSTPCR3, 22, 0), /* SDHI1 */
-	[MSTP321] = SH_CLK_MSTP32(&div4_clks[DIV4_P], MSTPCR3, 21, 0), /* SDHI2 */
-	[MSTP320] = SH_CLK_MSTP32(&div4_clks[DIV4_P], MSTPCR3, 20, 0), /* SDHI3 */
-	[MSTP115] = SH_CLK_MSTP32(&div4_clks[DIV4_P], MSTPCR1, 15, 0), /* SATA */
-	[MSTP103] = SH_CLK_MSTP32(&div4_clks[DIV4_S], MSTPCR1,  3, 0), /* DU */
-	[MSTP101] = SH_CLK_MSTP32(&div4_clks[DIV4_P], MSTPCR1,  1, 0), /* USB2 */
-	[MSTP100] = SH_CLK_MSTP32(&div4_clks[DIV4_P], MSTPCR1,  0, 0), /* USB0/1 */
-	[MSTP030] = SH_CLK_MSTP32(&div4_clks[DIV4_P], MSTPCR0, 30, 0), /* I2C0 */
-	[MSTP029] = SH_CLK_MSTP32(&div4_clks[DIV4_P], MSTPCR0, 29, 0), /* I2C1 */
-	[MSTP028] = SH_CLK_MSTP32(&div4_clks[DIV4_P], MSTPCR0, 28, 0), /* I2C2 */
-	[MSTP027] = SH_CLK_MSTP32(&div4_clks[DIV4_P], MSTPCR0, 27, 0), /* I2C3 */
-	[MSTP026] = SH_CLK_MSTP32(&div4_clks[DIV4_P], MSTPCR0, 26, 0), /* SCIF0 */
-	[MSTP025] = SH_CLK_MSTP32(&div4_clks[DIV4_P], MSTPCR0, 25, 0), /* SCIF1 */
-	[MSTP024] = SH_CLK_MSTP32(&div4_clks[DIV4_P], MSTPCR0, 24, 0), /* SCIF2 */
-	[MSTP023] = SH_CLK_MSTP32(&div4_clks[DIV4_P], MSTPCR0, 23, 0), /* SCIF3 */
-	[MSTP022] = SH_CLK_MSTP32(&div4_clks[DIV4_P], MSTPCR0, 22, 0), /* SCIF4 */
-	[MSTP021] = SH_CLK_MSTP32(&div4_clks[DIV4_P], MSTPCR0, 21, 0), /* SCIF5 */
-	[MSTP016] = SH_CLK_MSTP32(&div4_clks[DIV4_P], MSTPCR0, 16, 0), /* TMU0 */
-	[MSTP015] = SH_CLK_MSTP32(&div4_clks[DIV4_P], MSTPCR0, 15, 0), /* TMU1 */
-	[MSTP014] = SH_CLK_MSTP32(&div4_clks[DIV4_P], MSTPCR0, 14, 0), /* TMU2 */
-	[MSTP007] = SH_CLK_MSTP32(&div4_clks[DIV4_S], MSTPCR0,  7, 0), /* HSPI */
-};
-
-static unsigned long mul4_recalc(struct clk *clk)
-{
-	return clk->parent->rate * 4;
-}
-
-static struct sh_clk_ops mul4_clk_ops = {
-	.recalc		= mul4_recalc,
-};
-
-struct clk clkz_clk = {
-	.ops		= &mul4_clk_ops,
-	.parent		= &div4_clks[DIV4_S],
-};
-
-struct clk clkzs_clk = {
-	/* clks x 4 / 4 = clks */
-	.parent		= &div4_clks[DIV4_S],
-};
-
-static struct clk *late_main_clks[] = {
-	&clkz_clk,
-	&clkzs_clk,
+	[MSTP323] = SH_CLK_MSTP32(&clkp_clk, MSTPCR3, 23, 0), /* SDHI0 */
+	[MSTP322] = SH_CLK_MSTP32(&clkp_clk, MSTPCR3, 22, 0), /* SDHI1 */
+	[MSTP321] = SH_CLK_MSTP32(&clkp_clk, MSTPCR3, 21, 0), /* SDHI2 */
+	[MSTP320] = SH_CLK_MSTP32(&clkp_clk, MSTPCR3, 20, 0), /* SDHI3 */
+	[MSTP115] = SH_CLK_MSTP32(&clkp_clk, MSTPCR1, 15, 0), /* SATA */
+	[MSTP103] = SH_CLK_MSTP32(&clks_clk, MSTPCR1,  3, 0), /* DU */
+	[MSTP101] = SH_CLK_MSTP32(&clkp_clk, MSTPCR1,  1, 0), /* USB2 */
+	[MSTP100] = SH_CLK_MSTP32(&clkp_clk, MSTPCR1,  0, 0), /* USB0/1 */
+	[MSTP030] = SH_CLK_MSTP32(&clkp_clk, MSTPCR0, 30, 0), /* I2C0 */
+	[MSTP029] = SH_CLK_MSTP32(&clkp_clk, MSTPCR0, 29, 0), /* I2C1 */
+	[MSTP028] = SH_CLK_MSTP32(&clkp_clk, MSTPCR0, 28, 0), /* I2C2 */
+	[MSTP027] = SH_CLK_MSTP32(&clkp_clk, MSTPCR0, 27, 0), /* I2C3 */
+	[MSTP026] = SH_CLK_MSTP32(&clkp_clk, MSTPCR0, 26, 0), /* SCIF0 */
+	[MSTP025] = SH_CLK_MSTP32(&clkp_clk, MSTPCR0, 25, 0), /* SCIF1 */
+	[MSTP024] = SH_CLK_MSTP32(&clkp_clk, MSTPCR0, 24, 0), /* SCIF2 */
+	[MSTP023] = SH_CLK_MSTP32(&clkp_clk, MSTPCR0, 23, 0), /* SCIF3 */
+	[MSTP022] = SH_CLK_MSTP32(&clkp_clk, MSTPCR0, 22, 0), /* SCIF4 */
+	[MSTP021] = SH_CLK_MSTP32(&clkp_clk, MSTPCR0, 21, 0), /* SCIF5 */
+	[MSTP016] = SH_CLK_MSTP32(&clkp_clk, MSTPCR0, 16, 0), /* TMU0 */
+	[MSTP015] = SH_CLK_MSTP32(&clkp_clk, MSTPCR0, 15, 0), /* TMU1 */
+	[MSTP014] = SH_CLK_MSTP32(&clkp_clk, MSTPCR0, 14, 0), /* TMU2 */
+	[MSTP007] = SH_CLK_MSTP32(&clks_clk, MSTPCR0,  7, 0), /* HSPI */
 };
 
 static struct clk_lookup lookups[] = {
@@ -151,12 +133,12 @@ static struct clk_lookup lookups[] = {
 	CLKDEV_CON_ID("clkzs_clk", &clkzs_clk),
 
 	/* DIV4 clocks */
-	CLKDEV_CON_ID("shyway_clk",	&div4_clks[DIV4_S]),
-	CLKDEV_CON_ID("bus_clk",	&div4_clks[DIV4_OUT]),
-	CLKDEV_CON_ID("shyway4_clk",	&div4_clks[DIV4_S4]),
-	CLKDEV_CON_ID("shyway3_clk",	&div4_clks[DIV4_S3]),
-	CLKDEV_CON_ID("shyway1_clk",	&div4_clks[DIV4_S1]),
-	CLKDEV_CON_ID("peripheral_clk",	&div4_clks[DIV4_P]),
+	CLKDEV_CON_ID("shyway_clk",	&clks_clk),
+	CLKDEV_CON_ID("bus_clk",	&clkout_clk),
+	CLKDEV_CON_ID("shyway4_clk",	&clks4_clk),
+	CLKDEV_CON_ID("shyway3_clk",	&clks3_clk),
+	CLKDEV_CON_ID("shyway1_clk",	&clks1_clk),
+	CLKDEV_CON_ID("peripheral_clk",	&clkp_clk),
 
 	/* MSTP32 clocks */
 	CLKDEV_DEV_ID("sata_rcar", &mstp_clks[MSTP115]), /* SATA */
@@ -190,20 +172,60 @@ static struct clk_lookup lookups[] = {
 
 void __init r8a7779_clock_init(void)
 {
+	void __iomem *modemr = ioremap_nocache(MODEMR, PAGE_SIZE);
+	u32 mode;
 	int k, ret = 0;
 
+	BUG_ON(!modemr);
+	mode = ioread32(modemr);
+	iounmap(modemr);
+
+	if (mode & MD(1)) {
+		plla_clk.rate = 1500000000;
+
+		SH_CLK_SET_RATIO(&clkz_clk_ratio,	2, 3);
+		SH_CLK_SET_RATIO(&clkzs_clk_ratio,	1, 6);
+		SH_CLK_SET_RATIO(&clki_clk_ratio,	1, 2);
+		SH_CLK_SET_RATIO(&clks_clk_ratio,	1, 6);
+		SH_CLK_SET_RATIO(&clks1_clk_ratio,	1, 12);
+		SH_CLK_SET_RATIO(&clks3_clk_ratio,	1, 8);
+		SH_CLK_SET_RATIO(&clks4_clk_ratio,	1, 16);
+		SH_CLK_SET_RATIO(&clkp_clk_ratio,	1, 24);
+		SH_CLK_SET_RATIO(&clkg_clk_ratio,	1, 24);
+		if (mode & MD(2)) {
+			SH_CLK_SET_RATIO(&clkb_clk_ratio,	1, 36);
+			SH_CLK_SET_RATIO(&clkout_clk_ratio,	1, 36);
+		} else {
+			SH_CLK_SET_RATIO(&clkb_clk_ratio,	1, 24);
+			SH_CLK_SET_RATIO(&clkout_clk_ratio,	1, 24);
+		}
+	} else {
+		plla_clk.rate = 1600000000;
+
+		SH_CLK_SET_RATIO(&clkz_clk_ratio,	1, 2);
+		SH_CLK_SET_RATIO(&clkzs_clk_ratio,	1, 8);
+		SH_CLK_SET_RATIO(&clki_clk_ratio,	1, 2);
+		SH_CLK_SET_RATIO(&clks_clk_ratio,	1, 8);
+		SH_CLK_SET_RATIO(&clks1_clk_ratio,	1, 16);
+		SH_CLK_SET_RATIO(&clks3_clk_ratio,	1, 8);
+		SH_CLK_SET_RATIO(&clks4_clk_ratio,	1, 16);
+		SH_CLK_SET_RATIO(&clkp_clk_ratio,	1, 32);
+		SH_CLK_SET_RATIO(&clkg_clk_ratio,	1, 24);
+		if (mode & MD(2)) {
+			SH_CLK_SET_RATIO(&clkb_clk_ratio,	1, 32);
+			SH_CLK_SET_RATIO(&clkout_clk_ratio,	1, 32);
+		} else {
+			SH_CLK_SET_RATIO(&clkb_clk_ratio,	1, 24);
+			SH_CLK_SET_RATIO(&clkout_clk_ratio,	1, 24);
+		}
+	}
+
 	for (k = 0; !ret && (k < ARRAY_SIZE(main_clks)); k++)
 		ret = clk_register(main_clks[k]);
 
 	if (!ret)
-		ret = sh_clk_div4_register(div4_clks, DIV4_NR, &div4_table);
-
-	if (!ret)
 		ret = sh_clk_mstp_register(mstp_clks, MSTP_NR);
 
-	for (k = 0; !ret && (k < ARRAY_SIZE(late_main_clks)); k++)
-		ret = clk_register(late_main_clks[k]);
-
 	clkdev_add_table(lookups, ARRAY_SIZE(lookups));
 
 	if (!ret)
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 01:07:07 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue,  2 Apr 2013 14:07:07 +0900
Subject: [PATCH 11/30] ARM: shmobile: r8a7740: Migrate from INTC to GIC
In-Reply-To: <1364879246-9470-1-git-send-email-horms+renesas@verge.net.au>
References: <1364879246-9470-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364879246-9470-12-git-send-email-horms+renesas@verge.net.au>

From: Bastian Hecht <hechtb at gmail.com>

With the added capabilty of the intc_irqpin driver to handle shared
external IRQs, all prerequisites are fulfilled and we are ready to
migrate completely to GIC. This includes the following steps:

- Kconfig:	select ARM_GIC and RENESAS_INTC_IRQPIN
- intc-r8a7740: Throw out all legacy INTC code and init the GIC. We need
  		to mask out all shared IRQs as it is needed by the
		shared intc_irqpin driver.
- setup-r8a7740: Add 4 irqpin devices to handle external IRQs and update
		all IRQ numbers to point to the GIC SPI.
- board-armadillo: Update all IRQ numbers to point to the GIC SPI.
- pfc-r8a7740:	Update all IRQ numbers of the GPIOs to point to the GIC
		SPI.

Signed-off-by: Bastian Hecht <hechtb+renesas at gmail.com>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/Kconfig                 |    2 +
 arch/arm/mach-shmobile/board-armadillo800eva.c |   35 +-
 arch/arm/mach-shmobile/intc-r8a7740.c          |  641 ++----------------------
 arch/arm/mach-shmobile/setup-r8a7740.c         |  192 +++++--
 drivers/pinctrl/sh-pfc/pfc-r8a7740.c           |   64 +--
 5 files changed, 239 insertions(+), 695 deletions(-)

diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index 49cba4a..d569c34 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -30,8 +30,10 @@ config ARCH_R8A73A4
 config ARCH_R8A7740
 	bool "R-Mobile A1 (R8A77400)"
 	select ARCH_WANT_OPTIONAL_GPIOLIB
+	select ARM_GIC
 	select CPU_V7
 	select SH_CLK_CPG
+	select RENESAS_INTC_IRQPIN
 
 config ARCH_R8A7778
 	bool "R-Car M1 (R8A77780)"
diff --git a/arch/arm/mach-shmobile/board-armadillo800eva.c b/arch/arm/mach-shmobile/board-armadillo800eva.c
index f2ec077..e451327 100644
--- a/arch/arm/mach-shmobile/board-armadillo800eva.c
+++ b/arch/arm/mach-shmobile/board-armadillo800eva.c
@@ -145,7 +145,7 @@
  * see
  *	usbhsf_power_ctrl()
  */
-#define IRQ7		evt2irq(0x02e0)
+#define IRQ7		irq_pin(7)
 #define USBCR1		IOMEM(0xe605810a)
 #define USBH		0xC6700000
 #define USBH_USBCTR	0x10834
@@ -330,7 +330,7 @@ static struct resource usbhsf_resources[] = {
 		.flags	= IORESOURCE_MEM,
 	},
 	{
-		.start	= evt2irq(0x0A20),
+		.start	= gic_spi(51),
 		.flags	= IORESOURCE_IRQ,
 	},
 };
@@ -363,7 +363,7 @@ static struct resource sh_eth_resources[] = {
 		.end	= 0xe9a02000 - 1,
 		.flags	= IORESOURCE_MEM,
 	}, {
-		.start	= evt2irq(0x0500),
+		.start	= gic_spi(110),
 		.flags	= IORESOURCE_IRQ,
 	},
 };
@@ -417,7 +417,7 @@ static struct resource lcdc0_resources[] = {
 		.flags	= IORESOURCE_MEM,
 	},
 	[1] = {
-		.start	= intcs_evt2irq(0x580),
+		.start	= gic_spi(177),
 		.flags	= IORESOURCE_IRQ,
 	},
 };
@@ -452,7 +452,7 @@ static struct resource hdmi_resources[] = {
 		.flags	= IORESOURCE_MEM,
 	},
 	[1] = {
-		.start	= evt2irq(0x1700),
+		.start	= gic_spi(131),
 		.flags	= IORESOURCE_IRQ,
 	},
 	[2] = {
@@ -514,7 +514,7 @@ static struct resource hdmi_lcdc_resources[] = {
 		.flags	= IORESOURCE_MEM,
 	},
 	[1] = {
-		.start	= intcs_evt2irq(0x1780),
+		.start	= gic_spi(178),
 		.flags	= IORESOURCE_IRQ,
 	},
 };
@@ -574,7 +574,7 @@ static struct regulator_consumer_supply fixed3v3_power_consumers[] =
  * We can use IRQ31 as card detect irq,
  * but it needs chattering removal operation
  */
-#define IRQ31	evt2irq(0x33E0)
+#define IRQ31	irq_pin(31)
 static struct sh_mobile_sdhi_info sdhi0_info = {
 	.dma_slave_tx	= SHDMA_SLAVE_SDHI0_TX,
 	.dma_slave_rx	= SHDMA_SLAVE_SDHI0_RX,
@@ -596,12 +596,12 @@ static struct resource sdhi0_resources[] = {
 	 */
 	{
 		.name	= SH_MOBILE_SDHI_IRQ_SDCARD,
-		.start	= evt2irq(0x0E20),
+		.start	= gic_spi(118),
 		.flags	= IORESOURCE_IRQ,
 	},
 	{
 		.name	= SH_MOBILE_SDHI_IRQ_SDIO,
-		.start	= evt2irq(0x0E40),
+		.start	= gic_spi(119),
 		.flags	= IORESOURCE_IRQ,
 	},
 };
@@ -633,15 +633,15 @@ static struct resource sdhi1_resources[] = {
 		.flags	= IORESOURCE_MEM,
 	},
 	[1] = {
-		.start	= evt2irq(0x0E80),
+		.start	= gic_spi(121),
 		.flags	= IORESOURCE_IRQ,
 	},
 	[2] = {
-		.start	= evt2irq(0x0EA0),
+		.start	= gic_spi(122),
 		.flags	= IORESOURCE_IRQ,
 	},
 	[3] = {
-		.start	= evt2irq(0x0EC0),
+		.start	= gic_spi(123),
 		.flags	= IORESOURCE_IRQ,
 	},
 };
@@ -674,12 +674,12 @@ static struct resource sh_mmcif_resources[] = {
 	},
 	[1] = {
 		/* MMC ERR */
-		.start	= evt2irq(0x1AC0),
+		.start	= gic_spi(56),
 		.flags	= IORESOURCE_IRQ,
 	},
 	[2] = {
 		/* MMC NOR */
-		.start	= evt2irq(0x1AE0),
+		.start	= gic_spi(57),
 		.flags	= IORESOURCE_IRQ,
 	},
 };
@@ -756,7 +756,7 @@ static struct resource ceu0_resources[] = {
 		.flags	= IORESOURCE_MEM,
 	},
 	[1] = {
-		.start  = intcs_evt2irq(0x0500),
+		.start  = gic_spi(160),
 		.flags  = IORESOURCE_IRQ,
 	},
 	[2] = {
@@ -798,7 +798,7 @@ static struct resource fsi_resources[] = {
 		.flags	= IORESOURCE_MEM,
 	},
 	[1] = {
-		.start  = evt2irq(0x1840),
+		.start  = gic_spi(9),
 		.flags  = IORESOURCE_IRQ,
 	},
 };
@@ -881,7 +881,7 @@ static struct platform_device i2c_gpio_device = {
 static struct i2c_board_info i2c0_devices[] = {
 	{
 		I2C_BOARD_INFO("st1232-ts", 0x55),
-		.irq = evt2irq(0x0340),
+		.irq = irq_pin(10),
 	},
 	{
 		I2C_BOARD_INFO("wm8978", 0x1a),
@@ -1207,7 +1207,6 @@ DT_MACHINE_START(ARMADILLO800EVA_DT, "armadillo800eva")
 	.map_io		= r8a7740_map_io,
 	.init_early	= eva_add_early_devices,
 	.init_irq	= r8a7740_init_irq,
-	.handle_irq	= shmobile_handle_irq_intc,
 	.init_machine	= eva_init,
 	.init_late	= shmobile_init_late,
 	.init_time	= eva_earlytimer_init,
diff --git a/arch/arm/mach-shmobile/intc-r8a7740.c b/arch/arm/mach-shmobile/intc-r8a7740.c
index 9a69a31..b741c84 100644
--- a/arch/arm/mach-shmobile/intc-r8a7740.c
+++ b/arch/arm/mach-shmobile/intc-r8a7740.c
@@ -18,620 +18,39 @@
  * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
  */
 
-#include <linux/kernel.h>
 #include <linux/init.h>
-#include <linux/interrupt.h>
-#include <linux/irq.h>
 #include <linux/io.h>
-#include <linux/sh_intc.h>
-#include <mach/intc.h>
-#include <mach/irqs.h>
-#include <asm/mach-types.h>
-#include <asm/mach/arch.h>
-
-/*
- *		INTCA
- */
-enum {
-	UNUSED_INTCA = 0,
-
-	/* interrupt sources INTCA */
-	DIRC,
-	ATAPI,
-	IIC1_ALI, IIC1_TACKI, IIC1_WAITI, IIC1_DTEI,
-	AP_ARM_COMMTX, AP_ARM_COMMRX,
-	MFI, MFIS,
-	BBIF1, BBIF2,
-	USBHSDMAC,
-	USBF_OUL_SOF, USBF_IXL_INT,
-	SGX540,
-	CMT1_0, CMT1_1, CMT1_2, CMT1_3,
-	CMT2,
-	CMT3,
-	KEYSC,
-	SCIFA0, SCIFA1, SCIFA2, SCIFA3,
-	MSIOF2, MSIOF1,
-	SCIFA4, SCIFA5, SCIFB,
-	FLCTL_FLSTEI, FLCTL_FLTENDI, FLCTL_FLTREQ0I, FLCTL_FLTREQ1I,
-	SDHI0_0, SDHI0_1, SDHI0_2, SDHI0_3,
-	SDHI1_0, SDHI1_1, SDHI1_2, SDHI1_3,
-	AP_ARM_L2CINT,
-	IRDA,
-	TPU0,
-	SCIFA6, SCIFA7,
-	GbEther,
-	ICBS0,
-	DDM,
-	SDHI2_0, SDHI2_1, SDHI2_2, SDHI2_3,
-	RWDT0,
-	DMAC1_1_DEI0, DMAC1_1_DEI1, DMAC1_1_DEI2, DMAC1_1_DEI3,
-	DMAC1_2_DEI4, DMAC1_2_DEI5, DMAC1_2_DADERR,
-	DMAC2_1_DEI0, DMAC2_1_DEI1, DMAC2_1_DEI2, DMAC2_1_DEI3,
-	DMAC2_2_DEI4, DMAC2_2_DEI5, DMAC2_2_DADERR,
-	DMAC3_1_DEI0, DMAC3_1_DEI1, DMAC3_1_DEI2, DMAC3_1_DEI3,
-	DMAC3_2_DEI4, DMAC3_2_DEI5, DMAC3_2_DADERR,
-	SHWYSTAT_RT, SHWYSTAT_HS, SHWYSTAT_COM,
-	HDMI,
-	USBH_INT, USBH_OHCI, USBH_EHCI, USBH_PME, USBH_BIND,
-	RSPI_OVRF, RSPI_SPTEF, RSPI_SPRF,
-	SPU2_0, SPU2_1,
-	FSI, FMSI,
-	HDMI_SSS, HDMI_KEY,
-	IPMMU,
-	AP_ARM_CTIIRQ, AP_ARM_PMURQ,
-	MFIS2,
-	CPORTR2S,
-	CMT14, CMT15,
-	MMCIF_0, MMCIF_1, MMCIF_2,
-	SIM_ERI, SIM_RXI, SIM_TXI, SIM_TEI,
-	STPRO_0, STPRO_1, STPRO_2, STPRO_3, STPRO_4,
-
-	/* interrupt groups INTCA */
-	DMAC1_1, DMAC1_2,
-	DMAC2_1, DMAC2_2,
-	DMAC3_1, DMAC3_2,
-	AP_ARM1, AP_ARM2,
-	SDHI0, SDHI1, SDHI2,
-	SHWYSTAT,
-	USBF, USBH1, USBH2,
-	RSPI, SPU2, FLCTL, IIC1,
-};
-
-static struct intc_vect intca_vectors[] __initdata = {
-	INTC_VECT(DIRC,			0x0560),
-	INTC_VECT(ATAPI,		0x05E0),
-	INTC_VECT(IIC1_ALI,		0x0780),
-	INTC_VECT(IIC1_TACKI,		0x07A0),
-	INTC_VECT(IIC1_WAITI,		0x07C0),
-	INTC_VECT(IIC1_DTEI,		0x07E0),
-	INTC_VECT(AP_ARM_COMMTX,	0x0840),
-	INTC_VECT(AP_ARM_COMMRX,	0x0860),
-	INTC_VECT(MFI,			0x0900),
-	INTC_VECT(MFIS,			0x0920),
-	INTC_VECT(BBIF1,		0x0940),
-	INTC_VECT(BBIF2,		0x0960),
-	INTC_VECT(USBHSDMAC,		0x0A00),
-	INTC_VECT(USBF_OUL_SOF,		0x0A20),
-	INTC_VECT(USBF_IXL_INT,		0x0A40),
-	INTC_VECT(SGX540,		0x0A60),
-	INTC_VECT(CMT1_0,		0x0B00),
-	INTC_VECT(CMT1_1,		0x0B20),
-	INTC_VECT(CMT1_2,		0x0B40),
-	INTC_VECT(CMT1_3,		0x0B60),
-	INTC_VECT(CMT2,			0x0B80),
-	INTC_VECT(CMT3,			0x0BA0),
-	INTC_VECT(KEYSC,		0x0BE0),
-	INTC_VECT(SCIFA0,		0x0C00),
-	INTC_VECT(SCIFA1,		0x0C20),
-	INTC_VECT(SCIFA2,		0x0C40),
-	INTC_VECT(SCIFA3,		0x0C60),
-	INTC_VECT(MSIOF2,		0x0C80),
-	INTC_VECT(MSIOF1,		0x0D00),
-	INTC_VECT(SCIFA4,		0x0D20),
-	INTC_VECT(SCIFA5,		0x0D40),
-	INTC_VECT(SCIFB,		0x0D60),
-	INTC_VECT(FLCTL_FLSTEI,		0x0D80),
-	INTC_VECT(FLCTL_FLTENDI,	0x0DA0),
-	INTC_VECT(FLCTL_FLTREQ0I,	0x0DC0),
-	INTC_VECT(FLCTL_FLTREQ1I,	0x0DE0),
-	INTC_VECT(SDHI0_0,		0x0E00),
-	INTC_VECT(SDHI0_1,		0x0E20),
-	INTC_VECT(SDHI0_2,		0x0E40),
-	INTC_VECT(SDHI0_3,		0x0E60),
-	INTC_VECT(SDHI1_0,		0x0E80),
-	INTC_VECT(SDHI1_1,		0x0EA0),
-	INTC_VECT(SDHI1_2,		0x0EC0),
-	INTC_VECT(SDHI1_3,		0x0EE0),
-	INTC_VECT(AP_ARM_L2CINT,	0x0FA0),
-	INTC_VECT(IRDA,			0x0480),
-	INTC_VECT(TPU0,			0x04A0),
-	INTC_VECT(SCIFA6,		0x04C0),
-	INTC_VECT(SCIFA7,		0x04E0),
-	INTC_VECT(GbEther,		0x0500),
-	INTC_VECT(ICBS0,		0x0540),
-	INTC_VECT(DDM,			0x1140),
-	INTC_VECT(SDHI2_0,		0x1200),
-	INTC_VECT(SDHI2_1,		0x1220),
-	INTC_VECT(SDHI2_2,		0x1240),
-	INTC_VECT(SDHI2_3,		0x1260),
-	INTC_VECT(RWDT0,		0x1280),
-	INTC_VECT(DMAC1_1_DEI0,		0x2000),
-	INTC_VECT(DMAC1_1_DEI1,		0x2020),
-	INTC_VECT(DMAC1_1_DEI2,		0x2040),
-	INTC_VECT(DMAC1_1_DEI3,		0x2060),
-	INTC_VECT(DMAC1_2_DEI4,		0x2080),
-	INTC_VECT(DMAC1_2_DEI5,		0x20A0),
-	INTC_VECT(DMAC1_2_DADERR,	0x20C0),
-	INTC_VECT(DMAC2_1_DEI0,		0x2100),
-	INTC_VECT(DMAC2_1_DEI1,		0x2120),
-	INTC_VECT(DMAC2_1_DEI2,		0x2140),
-	INTC_VECT(DMAC2_1_DEI3,		0x2160),
-	INTC_VECT(DMAC2_2_DEI4,		0x2180),
-	INTC_VECT(DMAC2_2_DEI5,		0x21A0),
-	INTC_VECT(DMAC2_2_DADERR,	0x21C0),
-	INTC_VECT(DMAC3_1_DEI0,		0x2200),
-	INTC_VECT(DMAC3_1_DEI1,		0x2220),
-	INTC_VECT(DMAC3_1_DEI2,		0x2240),
-	INTC_VECT(DMAC3_1_DEI3,		0x2260),
-	INTC_VECT(DMAC3_2_DEI4,		0x2280),
-	INTC_VECT(DMAC3_2_DEI5,		0x22A0),
-	INTC_VECT(DMAC3_2_DADERR,	0x22C0),
-	INTC_VECT(SHWYSTAT_RT,		0x1300),
-	INTC_VECT(SHWYSTAT_HS,		0x1320),
-	INTC_VECT(SHWYSTAT_COM,		0x1340),
-	INTC_VECT(USBH_INT,		0x1540),
-	INTC_VECT(USBH_OHCI,		0x1560),
-	INTC_VECT(USBH_EHCI,		0x1580),
-	INTC_VECT(USBH_PME,		0x15A0),
-	INTC_VECT(USBH_BIND,		0x15C0),
-	INTC_VECT(HDMI,			0x1700),
-	INTC_VECT(RSPI_OVRF,		0x1780),
-	INTC_VECT(RSPI_SPTEF,		0x17A0),
-	INTC_VECT(RSPI_SPRF,		0x17C0),
-	INTC_VECT(SPU2_0,		0x1800),
-	INTC_VECT(SPU2_1,		0x1820),
-	INTC_VECT(FSI,			0x1840),
-	INTC_VECT(FMSI,			0x1860),
-	INTC_VECT(HDMI_SSS,		0x18A0),
-	INTC_VECT(HDMI_KEY,		0x18C0),
-	INTC_VECT(IPMMU,		0x1920),
-	INTC_VECT(AP_ARM_CTIIRQ,	0x1980),
-	INTC_VECT(AP_ARM_PMURQ,		0x19A0),
-	INTC_VECT(MFIS2,		0x1A00),
-	INTC_VECT(CPORTR2S,		0x1A20),
-	INTC_VECT(CMT14,		0x1A40),
-	INTC_VECT(CMT15,		0x1A60),
-	INTC_VECT(MMCIF_0,		0x1AA0),
-	INTC_VECT(MMCIF_1,		0x1AC0),
-	INTC_VECT(MMCIF_2,		0x1AE0),
-	INTC_VECT(SIM_ERI,		0x1C00),
-	INTC_VECT(SIM_RXI,		0x1C20),
-	INTC_VECT(SIM_TXI,		0x1C40),
-	INTC_VECT(SIM_TEI,		0x1C60),
-	INTC_VECT(STPRO_0,		0x1C80),
-	INTC_VECT(STPRO_1,		0x1CA0),
-	INTC_VECT(STPRO_2,		0x1CC0),
-	INTC_VECT(STPRO_3,		0x1CE0),
-	INTC_VECT(STPRO_4,		0x1D00),
-};
-
-static struct intc_group intca_groups[] __initdata = {
-	INTC_GROUP(DMAC1_1,
-		   DMAC1_1_DEI0, DMAC1_1_DEI1, DMAC1_1_DEI2, DMAC1_1_DEI3),
-	INTC_GROUP(DMAC1_2,
-		   DMAC1_2_DEI4, DMAC1_2_DEI5, DMAC1_2_DADERR),
-	INTC_GROUP(DMAC2_1,
-		   DMAC2_1_DEI0, DMAC2_1_DEI1, DMAC2_1_DEI2, DMAC2_1_DEI3),
-	INTC_GROUP(DMAC2_2,
-		   DMAC2_2_DEI4, DMAC2_2_DEI5, DMAC2_2_DADERR),
-	INTC_GROUP(DMAC3_1,
-		   DMAC3_1_DEI0, DMAC3_1_DEI1, DMAC3_1_DEI2, DMAC3_1_DEI3),
-	INTC_GROUP(DMAC3_2,
-		   DMAC3_2_DEI4, DMAC3_2_DEI5, DMAC3_2_DADERR),
-	INTC_GROUP(AP_ARM1,
-		   AP_ARM_COMMTX, AP_ARM_COMMRX),
-	INTC_GROUP(AP_ARM2,
-		   AP_ARM_CTIIRQ, AP_ARM_PMURQ),
-	INTC_GROUP(USBF,
-		   USBF_OUL_SOF, USBF_IXL_INT),
-	INTC_GROUP(SDHI0,
-		   SDHI0_0, SDHI0_1, SDHI0_2, SDHI0_3),
-	INTC_GROUP(SDHI1,
-		   SDHI1_0, SDHI1_1, SDHI1_2, SDHI1_3),
-	INTC_GROUP(SDHI2,
-		   SDHI2_0, SDHI2_1, SDHI2_2, SDHI2_3),
-	INTC_GROUP(SHWYSTAT,
-		   SHWYSTAT_RT, SHWYSTAT_HS, SHWYSTAT_COM),
-	INTC_GROUP(USBH1, /* FIXME */
-		   USBH_INT, USBH_OHCI),
-	INTC_GROUP(USBH2, /* FIXME */
-		   USBH_EHCI,
-		   USBH_PME, USBH_BIND),
-	INTC_GROUP(RSPI,
-		   RSPI_OVRF, RSPI_SPTEF, RSPI_SPRF),
-	INTC_GROUP(SPU2,
-		   SPU2_0, SPU2_1),
-	INTC_GROUP(FLCTL,
-		   FLCTL_FLSTEI, FLCTL_FLTENDI, FLCTL_FLTREQ0I, FLCTL_FLTREQ1I),
-	INTC_GROUP(IIC1,
-		   IIC1_ALI, IIC1_TACKI, IIC1_WAITI, IIC1_DTEI),
-};
-
-static struct intc_mask_reg intca_mask_registers[] __initdata = {
-	{ /* IMR0A / IMCR0A */ 0xe6940080, 0xe69400c0, 8,
-	  { DMAC2_1_DEI3, DMAC2_1_DEI2, DMAC2_1_DEI1, DMAC2_1_DEI0,
-	    0, 0, AP_ARM_COMMTX, AP_ARM_COMMRX } },
-	{ /* IMR1A / IMCR1A */ 0xe6940084, 0xe69400c4, 8,
-	  { ATAPI, 0, DIRC, 0,
-	    DMAC1_1_DEI3, DMAC1_1_DEI2, DMAC1_1_DEI1, DMAC1_1_DEI0 } },
-	{ /* IMR2A / IMCR2A */ 0xe6940088, 0xe69400c8, 8,
-	  { 0, 0, 0, 0,
-	    BBIF1, BBIF2, MFIS, MFI } },
-	{ /* IMR3A / IMCR3A */ 0xe694008c, 0xe69400cc, 8,
-	  { DMAC3_1_DEI3, DMAC3_1_DEI2, DMAC3_1_DEI1, DMAC3_1_DEI0,
-	    DMAC3_2_DADERR, DMAC3_2_DEI5, DMAC3_2_DEI4, IRDA } },
-	{ /* IMR4A / IMCR4A */ 0xe6940090, 0xe69400d0, 8,
-	  { DDM, 0, 0, 0,
-	    0, 0, 0, 0 } },
-	{ /* IMR5A / IMCR5A */ 0xe6940094, 0xe69400d4, 8,
-	  { KEYSC, DMAC1_2_DADERR, DMAC1_2_DEI5, DMAC1_2_DEI4,
-	    SCIFA3, SCIFA2, SCIFA1, SCIFA0 } },
-	{ /* IMR6A / IMCR6A */ 0xe6940098, 0xe69400d8, 8,
-	  { SCIFB, SCIFA5, SCIFA4, MSIOF1,
-	    0, 0, MSIOF2, 0 } },
-	{ /* IMR7A / IMCR7A */ 0xe694009c, 0xe69400dc, 8,
-	  { SDHI0_3, SDHI0_2, SDHI0_1, SDHI0_0,
-	    FLCTL_FLTREQ1I, FLCTL_FLTREQ0I, FLCTL_FLTENDI, FLCTL_FLSTEI } },
-	{ /* IMR8A / IMCR8A */ 0xe69400a0, 0xe69400e0, 8,
-	  { SDHI1_3, SDHI1_2, SDHI1_1, SDHI1_0,
-	    0, USBHSDMAC, 0, AP_ARM_L2CINT } },
-	{ /* IMR9A / IMCR9A */ 0xe69400a4, 0xe69400e4, 8,
-	  { CMT1_3, CMT1_2, CMT1_1, CMT1_0,
-	    CMT2, USBF_IXL_INT, USBF_OUL_SOF, SGX540 } },
-	{ /* IMR10A / IMCR10A */ 0xe69400a8, 0xe69400e8, 8,
-	  { 0, DMAC2_2_DADERR, DMAC2_2_DEI5, DMAC2_2_DEI4,
-	    0, 0, 0, 0 } },
-	{ /* IMR11A / IMCR11A */ 0xe69400ac, 0xe69400ec, 8,
-	  { IIC1_DTEI, IIC1_WAITI, IIC1_TACKI, IIC1_ALI,
-	    ICBS0, 0, 0, 0 } },
-	{ /* IMR12A / IMCR12A */ 0xe69400b0, 0xe69400f0, 8,
-	  { 0, 0, TPU0, SCIFA6,
-	    SCIFA7, GbEther, 0, 0 } },
-	{ /* IMR13A / IMCR13A */ 0xe69400b4, 0xe69400f4, 8,
-	  { SDHI2_3, SDHI2_2, SDHI2_1, SDHI2_0,
-	    0, CMT3, 0, RWDT0 } },
-	{ /* IMR0A3 / IMCR0A3 */ 0xe6950080, 0xe69500c0, 8,
-	  { SHWYSTAT_RT, SHWYSTAT_HS, SHWYSTAT_COM, 0,
-	    0, 0, 0, 0 } },
-	  /* IMR1A3 / IMCR1A3 */
-	{ /* IMR2A3 / IMCR2A3 */ 0xe6950088, 0xe69500c8, 8,
-	  { 0, 0, USBH_INT, USBH_OHCI,
-	    USBH_EHCI, USBH_PME, USBH_BIND, 0 } },
-	  /* IMR3A3 / IMCR3A3 */
-	{ /* IMR4A3 / IMCR4A3 */ 0xe6950090, 0xe69500d0, 8,
-	  { HDMI, 0, 0, 0,
-	    RSPI_OVRF, RSPI_SPTEF, RSPI_SPRF, 0 } },
-	{ /* IMR5A3 / IMCR5A3 */ 0xe6950094, 0xe69500d4, 8,
-	  { SPU2_0, SPU2_1, FSI, FMSI,
-	    0, HDMI_SSS, HDMI_KEY, 0 } },
-	{ /* IMR6A3 / IMCR6A3 */ 0xe6950098, 0xe69500d8, 8,
-	  { 0, IPMMU, 0, 0,
-	    AP_ARM_CTIIRQ, AP_ARM_PMURQ, 0, 0 } },
-	{ /* IMR7A3 / IMCR7A3 */ 0xe695009c, 0xe69500dc, 8,
-	  { MFIS2, CPORTR2S, CMT14, CMT15,
-	    0, MMCIF_0, MMCIF_1, MMCIF_2 } },
-	  /* IMR8A3 / IMCR8A3 */
-	{ /* IMR9A3 / IMCR9A3 */ 0xe69500a4, 0xe69500e4, 8,
-	  { SIM_ERI, SIM_RXI, SIM_TXI, SIM_TEI,
-	    STPRO_0, STPRO_1, STPRO_2, STPRO_3 } },
-	{ /* IMR10A3 / IMCR10A3 */ 0xe69500a8, 0xe69500e8, 8,
-	  { STPRO_4, 0, 0, 0,
-	    0, 0, 0, 0 } },
-};
-
-static struct intc_prio_reg intca_prio_registers[] __initdata = {
-	{ 0xe6940000, 0, 16, 4, /* IPRAA */ { DMAC3_1, DMAC3_2, CMT2, ICBS0 } },
-	{ 0xe6940004, 0, 16, 4, /* IPRBA */ { IRDA, 0, BBIF1, BBIF2 } },
-	{ 0xe6940008, 0, 16, 4, /* IPRCA */ { ATAPI, 0, CMT1_1, AP_ARM1 } },
-	{ 0xe694000c, 0, 16, 4, /* IPRDA */ { 0, 0, CMT1_2, 0 } },
-	{ 0xe6940010, 0, 16, 4, /* IPREA */ { DMAC1_1, MFIS, MFI, USBF } },
-	{ 0xe6940014, 0, 16, 4, /* IPRFA */ { KEYSC, DMAC1_2,
-					      SGX540, CMT1_0 } },
-	{ 0xe6940018, 0, 16, 4, /* IPRGA */ { SCIFA0, SCIFA1,
-					      SCIFA2, SCIFA3 } },
-	{ 0xe694001c, 0, 16, 4, /* IPRGH */ { MSIOF2, USBHSDMAC,
-					      FLCTL, SDHI0 } },
-	{ 0xe6940020, 0, 16, 4, /* IPRIA */ { MSIOF1, SCIFA4, 0, IIC1 } },
-	{ 0xe6940024, 0, 16, 4, /* IPRJA */ { DMAC2_1, DMAC2_2,
-					      AP_ARM_L2CINT, 0 } },
-	{ 0xe6940028, 0, 16, 4, /* IPRKA */ { 0, CMT1_3, 0, SDHI1 } },
-	{ 0xe694002c, 0, 16, 4, /* IPRLA */ { TPU0, SCIFA6,
-					      SCIFA7, GbEther } },
-	{ 0xe6940030, 0, 16, 4, /* IPRMA */ { 0, CMT3, 0, RWDT0 } },
-	{ 0xe6940034, 0, 16, 4, /* IPRNA */ { SCIFB, SCIFA5, 0, DDM } },
-	{ 0xe6940038, 0, 16, 4, /* IPROA */ { 0, 0, DIRC, SDHI2 } },
-	{ 0xe6950000, 0, 16, 4, /* IPRAA3 */ { SHWYSTAT, 0, 0, 0 } },
-				/* IPRBA3 */
-				/* IPRCA3 */
-				/* IPRDA3 */
-	{ 0xe6950010, 0, 16, 4, /* IPREA3 */ { USBH1, 0, 0, 0 } },
-	{ 0xe6950014, 0, 16, 4, /* IPRFA3 */ { USBH2, 0, 0, 0 } },
-				/* IPRGA3 */
-				/* IPRHA3 */
-	{ 0xe6950020, 0, 16, 4, /* IPRIA3 */ { HDMI, 0, 0, 0 } },
-	{ 0xe6950024, 0, 16, 4, /* IPRJA3 */ { RSPI, 0, 0, 0 } },
-	{ 0xe6950028, 0, 16, 4, /* IPRKA3 */ { SPU2, 0, FSI, FMSI } },
-	{ 0xe695002c, 0, 16, 4, /* IPRLA3 */ { 0, HDMI_SSS, HDMI_KEY, 0 } },
-	{ 0xe6950030, 0, 16, 4, /* IPRMA3 */ { IPMMU, 0, 0, 0 } },
-	{ 0xe6950034, 0, 16, 4, /* IPRNA3 */ { AP_ARM2, 0, 0, 0 } },
-	{ 0xe6950038, 0, 16, 4, /* IPROA3 */ { MFIS2, CPORTR2S,
-					       CMT14, CMT15 } },
-	{ 0xe695003c, 0, 16, 4, /* IPRPA3 */ { 0, MMCIF_0, MMCIF_1, MMCIF_2 } },
-				/* IPRQA3 */
-				/* IPRRA3 */
-	{ 0xe6950048, 0, 16, 4, /* IPRSA3 */ { SIM_ERI, SIM_RXI,
-					       SIM_TXI, SIM_TEI } },
-	{ 0xe695004c, 0, 16, 4, /* IPRTA3 */ { STPRO_0, STPRO_1,
-					       STPRO_2, STPRO_3 } },
-	{ 0xe6950050, 0, 16, 4, /* IPRUA3 */ { STPRO_4, 0, 0, 0 } },
-};
-
-static DECLARE_INTC_DESC(intca_desc, "r8a7740-intca",
-			 intca_vectors, intca_groups,
-			 intca_mask_registers, intca_prio_registers,
-			 NULL);
-
-INTC_IRQ_PINS_32(intca_irq_pins, 0xe6900000,
-		 INTC_VECT, "r8a7740-intca-irq-pins");
-
-
-/*
- *		INTCS
- */
-enum {
-	UNUSED_INTCS = 0,
-
-	INTCS,
-
-	/* interrupt sources INTCS */
-
-	/* HUDI */
-	/* STPRO */
-	/* RTDMAC(1) */
-	VPU5HA2,
-	_2DG_TRAP, _2DG_GPM_INT, _2DG_CER_INT,
-	/* MFI */
-	/* BBIF2 */
-	VPU5F,
-	_2DG_BRK_INT,
-	/* SGX540 */
-	/* 2DDMAC */
-	/* IPMMU */
-	/* RTDMAC 2 */
-	/* KEYSC */
-	/* MSIOF */
-	IIC0_ALI, IIC0_TACKI, IIC0_WAITI, IIC0_DTEI,
-	TMU0_0, TMU0_1, TMU0_2,
-	CMT0,
-	/* CMT2 */
-	LMB,
-	CTI,
-	VOU,
-	/* RWDT0 */
-	ICB,
-	VIO6C,
-	CEU20, CEU21,
-	JPU,
-	LCDC0,
-	LCRC,
-	/* RTDMAC2(1) */
-	/* RTDMAC2(2) */
-	LCDC1,
-	/* SPU2 */
-	/* FSI */
-	/* FMSI */
-	TMU1_0, TMU1_1, TMU1_2,
-	CMT4,
-	DISP,
-	DSRV,
-	/* MFIS2 */
-	CPORTS2R,
-
-	/* interrupt groups INTCS */
-	_2DG1,
-	IIC0, TMU1,
-};
-
-static struct intc_vect intcs_vectors[] = {
-	/* HUDI */
-	/* STPRO */
-	/* RTDMAC(1) */
-	INTCS_VECT(VPU5HA2,		0x0880),
-	INTCS_VECT(_2DG_TRAP,		0x08A0),
-	INTCS_VECT(_2DG_GPM_INT,	0x08C0),
-	INTCS_VECT(_2DG_CER_INT,	0x08E0),
-	/* MFI */
-	/* BBIF2 */
-	INTCS_VECT(VPU5F,		0x0980),
-	INTCS_VECT(_2DG_BRK_INT,	0x09A0),
-	/* SGX540 */
-	/* 2DDMAC */
-	/* IPMMU */
-	/* RTDMAC(2) */
-	/* KEYSC */
-	/* MSIOF */
-	INTCS_VECT(IIC0_ALI,		0x0E00),
-	INTCS_VECT(IIC0_TACKI,		0x0E20),
-	INTCS_VECT(IIC0_WAITI,		0x0E40),
-	INTCS_VECT(IIC0_DTEI,		0x0E60),
-	INTCS_VECT(TMU0_0,		0x0E80),
-	INTCS_VECT(TMU0_1,		0x0EA0),
-	INTCS_VECT(TMU0_2,		0x0EC0),
-	INTCS_VECT(CMT0,		0x0F00),
-	/* CMT2 */
-	INTCS_VECT(LMB,			0x0F60),
-	INTCS_VECT(CTI,			0x0400),
-	INTCS_VECT(VOU,			0x0420),
-	/* RWDT0 */
-	INTCS_VECT(ICB,			0x0480),
-	INTCS_VECT(VIO6C,		0x04E0),
-	INTCS_VECT(CEU20,		0x0500),
-	INTCS_VECT(CEU21,		0x0520),
-	INTCS_VECT(JPU,			0x0560),
-	INTCS_VECT(LCDC0,		0x0580),
-	INTCS_VECT(LCRC,		0x05A0),
-	/* RTDMAC2(1) */
-	/* RTDMAC2(2) */
-	INTCS_VECT(LCDC1,		0x1780),
-	/* SPU2 */
-	/* FSI */
-	/* FMSI */
-	INTCS_VECT(TMU1_0,		0x1900),
-	INTCS_VECT(TMU1_1,		0x1920),
-	INTCS_VECT(TMU1_2,		0x1940),
-	INTCS_VECT(CMT4,		0x1980),
-	INTCS_VECT(DISP,		0x19A0),
-	INTCS_VECT(DSRV,		0x19C0),
-	/* MFIS2 */
-	INTCS_VECT(CPORTS2R,		0x1A20),
-
-	INTC_VECT(INTCS,		0xf80),
-};
-
-static struct intc_group intcs_groups[] __initdata = {
-	INTC_GROUP(_2DG1, /*FIXME*/
-		   _2DG_CER_INT, _2DG_GPM_INT, _2DG_TRAP),
-	INTC_GROUP(IIC0,
-		   IIC0_DTEI, IIC0_WAITI, IIC0_TACKI, IIC0_ALI),
-	INTC_GROUP(TMU1,
-		   TMU1_0, TMU1_1, TMU1_2),
-};
-
-static struct intc_mask_reg intcs_mask_registers[] = {
-	  /* IMR0SA / IMCR0SA */ /* all 0 */
-	{ /* IMR1SA / IMCR1SA */ 0xffd20184, 0xffd201c4, 8,
-	  { _2DG_CER_INT, _2DG_GPM_INT, _2DG_TRAP, VPU5HA2,
-	    0, 0, 0, 0 /*STPRO*/ } },
-	{ /* IMR2SA / IMCR2SA */ 0xffd20188, 0xffd201c8, 8,
-	  { 0/*STPRO*/, 0, CEU21, VPU5F,
-	    0/*BBIF2*/, 0, 0, 0/*MFI*/ } },
-	{ /* IMR3SA / IMCR3SA */ 0xffd2018c, 0xffd201cc, 8,
-	  { 0, 0, 0, 0, /*2DDMAC*/
-	    VIO6C, 0, 0, ICB } },
-	{ /* IMR4SA / IMCR4SA */ 0xffd20190, 0xffd201d0, 8,
-	  { 0, 0, VOU, CTI,
-	    JPU, 0, LCRC, LCDC0 } },
-	  /* IMR5SA / IMCR5SA */ /*KEYSC/RTDMAC2/RTDMAC1*/
-	  /* IMR6SA / IMCR6SA */ /*MSIOF/SGX540*/
-	{ /* IMR7SA / IMCR7SA */ 0xffd2019c, 0xffd201dc, 8,
-	  { 0, TMU0_2, TMU0_1, TMU0_0,
-	    0, 0, 0, 0 } },
-	{ /* IMR8SA / IMCR8SA */ 0xffd201a0, 0xffd201e0, 8,
-	  { 0, 0, 0, 0,
-	    CEU20, 0, 0, 0 } },
-	{ /* IMR9SA / IMCR9SA */ 0xffd201a4, 0xffd201e4, 8,
-	  { 0, 0/*RWDT0*/, 0/*CMT2*/, CMT0,
-	    0, 0, 0, 0 } },
-	  /* IMR10SA / IMCR10SA */ /*IPMMU*/
-	{ /* IMR11SA / IMCR11SA */ 0xffd201ac, 0xffd201ec, 8,
-	  { IIC0_DTEI, IIC0_WAITI, IIC0_TACKI, IIC0_ALI,
-	    0, _2DG_BRK_INT, LMB, 0 } },
-	  /* IMR12SA / IMCR12SA */
-	  /* IMR13SA / IMCR13SA */
-	  /* IMR0SA3 / IMCR0SA3 */ /*RTDMAC2(1)/RTDMAC2(2)*/
-	  /* IMR1SA3 / IMCR1SA3 */
-	  /* IMR2SA3 / IMCR2SA3 */
-	  /* IMR3SA3 / IMCR3SA3 */
-	{ /* IMR4SA3 / IMCR4SA3 */ 0xffd50190, 0xffd501d0, 8,
-	  { 0, 0, 0, 0,
-	    LCDC1, 0, 0, 0 } },
-	  /* IMR5SA3 / IMCR5SA3 */ /* SPU2/FSI/FMSI */
-	{ /* IMR6SA3 / IMCR6SA3 */ 0xffd50198, 0xffd501d8, 8,
-	  { TMU1_0, TMU1_1, TMU1_2, 0,
-	    CMT4, DISP, DSRV, 0 } },
-	{ /* IMR7SA3 / IMCR7SA3 */ 0xffd5019c, 0xffd501dc, 8,
-	  { 0/*MFIS2*/, CPORTS2R, 0, 0,
-	    0, 0, 0, 0 } },
-	{ /* INTAMASK */ 0xffd20104, 0, 16,
-	  { 0, 0, 0, 0, 0, 0, 0, 0,
-	    0, 0, 0, 0, 0, 0, 0, INTCS } },
-};
-
-/* Priority is needed for INTCA to receive the INTCS interrupt */
-static struct intc_prio_reg intcs_prio_registers[] = {
-	{ 0xffd20000, 0, 16, 4, /* IPRAS */ { CTI, VOU, 0/*2DDMAC*/, ICB } },
-	{ 0xffd20004, 0, 16, 4, /* IPRBS */ { JPU, LCDC0, 0, LCRC } },
-				/* IPRCS */ /*BBIF2*/
-				/* IPRDS */
-	{ 0xffd20010, 0, 16, 4, /* IPRES */ { 0/*RTDMAC(1)*/, VPU5HA2,
-					      0/*MFI*/, VPU5F } },
-	{ 0xffd20014, 0, 16, 4, /* IPRFS */ { 0/*KEYSC*/, 0/*RTDMAC(2)*/,
-					      0/*CMT2*/, CMT0 } },
-	{ 0xffd20018, 0, 16, 4, /* IPRGS */ { TMU0_0, TMU0_1,
-					      TMU0_2, _2DG1 } },
-	{ 0xffd2001c, 0, 16, 4, /* IPRHS */ { 0, 0/*STPRO*/, 0/*STPRO*/,
-					      _2DG_BRK_INT/*FIXME*/ } },
-	{ 0xffd20020, 0, 16, 4, /* IPRIS */ { 0, 0/*MSIOF*/, 0, IIC0 } },
-	{ 0xffd20024, 0, 16, 4, /* IPRJS */ { CEU20, 0/*SGX540*/, 0, 0 } },
-	{ 0xffd20028, 0, 16, 4, /* IPRKS */ { VIO6C, 0, LMB, 0 } },
-	{ 0xffd2002c, 0, 16, 4, /* IPRLS */ { 0/*IPMMU*/, 0, CEU21, 0 } },
-				/* IPRMS */ /*RWDT0*/
-				/* IPRAS3 */ /*RTDMAC2(1)*/
-				/* IPRBS3 */ /*RTDMAC2(2)*/
-				/* IPRCS3 */
-				/* IPRDS3 */
-				/* IPRES3 */
-				/* IPRFS3 */
-				/* IPRGS3 */
-				/* IPRHS3 */
-				/* IPRIS3 */
-	{ 0xffd50024, 0, 16, 4, /* IPRJS3 */ { LCDC1, 0, 0, 0 } },
-				/* IPRKS3 */ /*SPU2/FSI/FMSi*/
-				/* IPRLS3 */
-	{ 0xffd50030, 0, 16, 4, /* IPRMS3 */ { TMU1, 0, 0, 0 } },
-	{ 0xffd50034, 0, 16, 4, /* IPRNS3 */ { CMT4, DISP, DSRV, 0 } },
-	{ 0xffd50038, 0, 16, 4, /* IPROS3 */ { 0/*MFIS2*/, CPORTS2R, 0, 0 } },
-				/* IPRPS3 */
-};
-
-static struct resource intcs_resources[] __initdata = {
-	[0] = {
-		.start	= 0xffd20000,
-		.end	= 0xffd201ff,
-		.flags	= IORESOURCE_MEM,
-	},
-	[1] = {
-		.start	= 0xffd50000,
-		.end	= 0xffd501ff,
-		.flags	= IORESOURCE_MEM,
-	}
-};
-
-static struct intc_desc intcs_desc __initdata = {
-	.name = "r8a7740-intcs",
-	.resource = intcs_resources,
-	.num_resources = ARRAY_SIZE(intcs_resources),
-	.hw = INTC_HW_DESC(intcs_vectors, intcs_groups, intcs_mask_registers,
-			   intcs_prio_registers, NULL, NULL),
-};
-
-static void intcs_demux(unsigned int irq, struct irq_desc *desc)
-{
-	void __iomem *reg = (void *)irq_get_handler_data(irq);
-	unsigned int evtcodeas = ioread32(reg);
-
-	generic_handle_irq(intcs_evt2irq(evtcodeas));
-}
+#include <linux/irqchip/arm-gic.h>
 
 void __init r8a7740_init_irq(void)
 {
-	void __iomem *intevtsa = ioremap_nocache(0xffd20100, PAGE_SIZE);
-
-	register_intc_controller(&intca_desc);
-	register_intc_controller(&intca_irq_pins_desc);
-	register_intc_controller(&intcs_desc);
-
-	/* demux using INTEVTSA */
-	irq_set_handler_data(evt2irq(0xf80), (void *)intevtsa);
-	irq_set_chained_handler(evt2irq(0xf80), intcs_demux);
+	void __iomem *gic_dist_base = ioremap_nocache(0xc2800000, 0x1000);
+	void __iomem *gic_cpu_base = ioremap_nocache(0xc2000000, 0x1000);
+	void __iomem *intc_prio_base = ioremap_nocache(0xe6900010, 0x10);
+	void __iomem *intc_msk_base = ioremap_nocache(0xe6900040, 0x10);
+	void __iomem *pfc_inta_ctrl = ioremap_nocache(0xe605807c, 0x4);
+
+	/* initialize the Generic Interrupt Controller PL390 r0p0 */
+	gic_init(0, 29, gic_dist_base, gic_cpu_base);
+
+	/* route signals to GIC */
+	iowrite32(0x0, pfc_inta_ctrl);
+
+	/*
+	 * To mask the shared interrupt to SPI 149 we must ensure to set
+	 * PRIO *and* MASK. Else we run into IRQ floods when registering
+	 * the intc_irqpin devices
+	 */
+	iowrite32(0x0, intc_prio_base + 0x0);
+	iowrite32(0x0, intc_prio_base + 0x4);
+	iowrite32(0x0, intc_prio_base + 0x8);
+	iowrite32(0x0, intc_prio_base + 0xc);
+	iowrite8(0xff, intc_msk_base + 0x0);
+	iowrite8(0xff, intc_msk_base + 0x4);
+	iowrite8(0xff, intc_msk_base + 0x8);
+	iowrite8(0xff, intc_msk_base + 0xc);
+
+	iounmap(intc_prio_base);
+	iounmap(intc_msk_base);
+	iounmap(pfc_inta_ctrl);
 }
diff --git a/arch/arm/mach-shmobile/setup-r8a7740.c b/arch/arm/mach-shmobile/setup-r8a7740.c
index 8b85d4d..228d7ab 100644
--- a/arch/arm/mach-shmobile/setup-r8a7740.c
+++ b/arch/arm/mach-shmobile/setup-r8a7740.c
@@ -22,6 +22,7 @@
 #include <linux/kernel.h>
 #include <linux/init.h>
 #include <linux/io.h>
+#include <linux/platform_data/irq-renesas-intc-irqpin.h>
 #include <linux/platform_device.h>
 #include <linux/of_platform.h>
 #include <linux/serial_sci.h>
@@ -94,6 +95,126 @@ void __init r8a7740_pinmux_init(void)
 	platform_device_register(&r8a7740_pfc_device);
 }
 
+static struct renesas_intc_irqpin_config irqpin0_platform_data = {
+	.irq_base = irq_pin(0), /* IRQ0 -> IRQ7 */
+};
+
+static struct resource irqpin0_resources[] = {
+	DEFINE_RES_MEM(0xe6900000, 4), /* ICR1A */
+	DEFINE_RES_MEM(0xe6900010, 4), /* INTPRI00A */
+	DEFINE_RES_MEM(0xe6900020, 1), /* INTREQ00A */
+	DEFINE_RES_MEM(0xe6900040, 1), /* INTMSK00A */
+	DEFINE_RES_MEM(0xe6900060, 1), /* INTMSKCLR00A */
+	DEFINE_RES_IRQ(gic_spi(149)), /* IRQ0 */
+	DEFINE_RES_IRQ(gic_spi(149)), /* IRQ1 */
+	DEFINE_RES_IRQ(gic_spi(149)), /* IRQ2 */
+	DEFINE_RES_IRQ(gic_spi(149)), /* IRQ3 */
+	DEFINE_RES_IRQ(gic_spi(149)), /* IRQ4 */
+	DEFINE_RES_IRQ(gic_spi(149)), /* IRQ5 */
+	DEFINE_RES_IRQ(gic_spi(149)), /* IRQ6 */
+	DEFINE_RES_IRQ(gic_spi(149)), /* IRQ7 */
+};
+
+static struct platform_device irqpin0_device = {
+	.name		= "renesas_intc_irqpin",
+	.id		= 0,
+	.resource	= irqpin0_resources,
+	.num_resources	= ARRAY_SIZE(irqpin0_resources),
+	.dev		= {
+		.platform_data  = &irqpin0_platform_data,
+	},
+};
+
+static struct renesas_intc_irqpin_config irqpin1_platform_data = {
+	.irq_base = irq_pin(8), /* IRQ8 -> IRQ15 */
+};
+
+static struct resource irqpin1_resources[] = {
+	DEFINE_RES_MEM(0xe6900004, 4), /* ICR2A */
+	DEFINE_RES_MEM(0xe6900014, 4), /* INTPRI10A */
+	DEFINE_RES_MEM(0xe6900024, 1), /* INTREQ10A */
+	DEFINE_RES_MEM(0xe6900044, 1), /* INTMSK10A */
+	DEFINE_RES_MEM(0xe6900064, 1), /* INTMSKCLR10A */
+	DEFINE_RES_IRQ(gic_spi(149)), /* IRQ8 */
+	DEFINE_RES_IRQ(gic_spi(149)), /* IRQ9 */
+	DEFINE_RES_IRQ(gic_spi(149)), /* IRQ10 */
+	DEFINE_RES_IRQ(gic_spi(149)), /* IRQ11 */
+	DEFINE_RES_IRQ(gic_spi(149)), /* IRQ12 */
+	DEFINE_RES_IRQ(gic_spi(149)), /* IRQ13 */
+	DEFINE_RES_IRQ(gic_spi(149)), /* IRQ14 */
+	DEFINE_RES_IRQ(gic_spi(149)), /* IRQ15 */
+};
+
+static struct platform_device irqpin1_device = {
+	.name		= "renesas_intc_irqpin",
+	.id		= 1,
+	.resource	= irqpin1_resources,
+	.num_resources	= ARRAY_SIZE(irqpin1_resources),
+	.dev		= {
+		.platform_data  = &irqpin1_platform_data,
+	},
+};
+
+static struct renesas_intc_irqpin_config irqpin2_platform_data = {
+	.irq_base = irq_pin(16), /* IRQ16 -> IRQ23 */
+};
+
+static struct resource irqpin2_resources[] = {
+	DEFINE_RES_MEM(0xe6900008, 4), /* ICR3A */
+	DEFINE_RES_MEM(0xe6900018, 4), /* INTPRI30A */
+	DEFINE_RES_MEM(0xe6900028, 1), /* INTREQ30A */
+	DEFINE_RES_MEM(0xe6900048, 1), /* INTMSK30A */
+	DEFINE_RES_MEM(0xe6900068, 1), /* INTMSKCLR30A */
+	DEFINE_RES_IRQ(gic_spi(149)), /* IRQ16 */
+	DEFINE_RES_IRQ(gic_spi(149)), /* IRQ17 */
+	DEFINE_RES_IRQ(gic_spi(149)), /* IRQ18 */
+	DEFINE_RES_IRQ(gic_spi(149)), /* IRQ19 */
+	DEFINE_RES_IRQ(gic_spi(149)), /* IRQ20 */
+	DEFINE_RES_IRQ(gic_spi(149)), /* IRQ21 */
+	DEFINE_RES_IRQ(gic_spi(149)), /* IRQ22 */
+	DEFINE_RES_IRQ(gic_spi(149)), /* IRQ23 */
+};
+
+static struct platform_device irqpin2_device = {
+	.name		= "renesas_intc_irqpin",
+	.id		= 2,
+	.resource	= irqpin2_resources,
+	.num_resources	= ARRAY_SIZE(irqpin2_resources),
+	.dev		= {
+		.platform_data  = &irqpin2_platform_data,
+	},
+};
+
+static struct renesas_intc_irqpin_config irqpin3_platform_data = {
+	.irq_base = irq_pin(24), /* IRQ24 -> IRQ31 */
+};
+
+static struct resource irqpin3_resources[] = {
+	DEFINE_RES_MEM(0xe690000c, 4), /* ICR3A */
+	DEFINE_RES_MEM(0xe690001c, 4), /* INTPRI30A */
+	DEFINE_RES_MEM(0xe690002c, 1), /* INTREQ30A */
+	DEFINE_RES_MEM(0xe690004c, 1), /* INTMSK30A */
+	DEFINE_RES_MEM(0xe690006c, 1), /* INTMSKCLR30A */
+	DEFINE_RES_IRQ(gic_spi(149)), /* IRQ24 */
+	DEFINE_RES_IRQ(gic_spi(149)), /* IRQ25 */
+	DEFINE_RES_IRQ(gic_spi(149)), /* IRQ26 */
+	DEFINE_RES_IRQ(gic_spi(149)), /* IRQ27 */
+	DEFINE_RES_IRQ(gic_spi(149)), /* IRQ28 */
+	DEFINE_RES_IRQ(gic_spi(149)), /* IRQ29 */
+	DEFINE_RES_IRQ(gic_spi(149)), /* IRQ30 */
+	DEFINE_RES_IRQ(gic_spi(149)), /* IRQ31 */
+};
+
+static struct platform_device irqpin3_device = {
+	.name		= "renesas_intc_irqpin",
+	.id		= 3,
+	.resource	= irqpin3_resources,
+	.num_resources	= ARRAY_SIZE(irqpin3_resources),
+	.dev		= {
+		.platform_data  = &irqpin3_platform_data,
+	},
+};
+
 /* SCIFA0 */
 static struct plat_sci_port scif0_platform_data = {
 	.mapbase	= 0xe6c40000,
@@ -101,7 +222,7 @@ static struct plat_sci_port scif0_platform_data = {
 	.scscr		= SCSCR_RE | SCSCR_TE,
 	.scbrr_algo_id	= SCBRR_ALGO_4,
 	.type		= PORT_SCIFA,
-	.irqs		= SCIx_IRQ_MUXED(evt2irq(0x0c00)),
+	.irqs		= SCIx_IRQ_MUXED(gic_spi(100)),
 };
 
 static struct platform_device scif0_device = {
@@ -119,7 +240,7 @@ static struct plat_sci_port scif1_platform_data = {
 	.scscr		= SCSCR_RE | SCSCR_TE,
 	.scbrr_algo_id	= SCBRR_ALGO_4,
 	.type		= PORT_SCIFA,
-	.irqs		= SCIx_IRQ_MUXED(evt2irq(0x0c20)),
+	.irqs		= SCIx_IRQ_MUXED(gic_spi(101)),
 };
 
 static struct platform_device scif1_device = {
@@ -137,7 +258,7 @@ static struct plat_sci_port scif2_platform_data = {
 	.scscr		= SCSCR_RE | SCSCR_TE,
 	.scbrr_algo_id	= SCBRR_ALGO_4,
 	.type		= PORT_SCIFA,
-	.irqs		= SCIx_IRQ_MUXED(evt2irq(0x0c40)),
+	.irqs		= SCIx_IRQ_MUXED(gic_spi(102)),
 };
 
 static struct platform_device scif2_device = {
@@ -155,7 +276,7 @@ static struct plat_sci_port scif3_platform_data = {
 	.scscr		= SCSCR_RE | SCSCR_TE,
 	.scbrr_algo_id	= SCBRR_ALGO_4,
 	.type		= PORT_SCIFA,
-	.irqs		= SCIx_IRQ_MUXED(evt2irq(0x0c60)),
+	.irqs		= SCIx_IRQ_MUXED(gic_spi(103)),
 };
 
 static struct platform_device scif3_device = {
@@ -173,7 +294,7 @@ static struct plat_sci_port scif4_platform_data = {
 	.scscr		= SCSCR_RE | SCSCR_TE,
 	.scbrr_algo_id	= SCBRR_ALGO_4,
 	.type		= PORT_SCIFA,
-	.irqs		= SCIx_IRQ_MUXED(evt2irq(0x0d20)),
+	.irqs		= SCIx_IRQ_MUXED(gic_spi(104)),
 };
 
 static struct platform_device scif4_device = {
@@ -191,7 +312,7 @@ static struct plat_sci_port scif5_platform_data = {
 	.scscr		= SCSCR_RE | SCSCR_TE,
 	.scbrr_algo_id	= SCBRR_ALGO_4,
 	.type		= PORT_SCIFA,
-	.irqs		= SCIx_IRQ_MUXED(evt2irq(0x0d40)),
+	.irqs		= SCIx_IRQ_MUXED(gic_spi(105)),
 };
 
 static struct platform_device scif5_device = {
@@ -209,7 +330,7 @@ static struct plat_sci_port scif6_platform_data = {
 	.scscr		= SCSCR_RE | SCSCR_TE,
 	.scbrr_algo_id	= SCBRR_ALGO_4,
 	.type		= PORT_SCIFA,
-	.irqs		= SCIx_IRQ_MUXED(evt2irq(0x04c0)),
+	.irqs		= SCIx_IRQ_MUXED(gic_spi(106)),
 };
 
 static struct platform_device scif6_device = {
@@ -227,7 +348,7 @@ static struct plat_sci_port scif7_platform_data = {
 	.scscr		= SCSCR_RE | SCSCR_TE,
 	.scbrr_algo_id	= SCBRR_ALGO_4,
 	.type		= PORT_SCIFA,
-	.irqs		= SCIx_IRQ_MUXED(evt2irq(0x04e0)),
+	.irqs		= SCIx_IRQ_MUXED(gic_spi(107)),
 };
 
 static struct platform_device scif7_device = {
@@ -245,7 +366,7 @@ static struct plat_sci_port scifb_platform_data = {
 	.scscr		= SCSCR_RE | SCSCR_TE,
 	.scbrr_algo_id	= SCBRR_ALGO_4,
 	.type		= PORT_SCIFB,
-	.irqs		= SCIx_IRQ_MUXED(evt2irq(0x0d60)),
+	.irqs		= SCIx_IRQ_MUXED(gic_spi(108)),
 };
 
 static struct platform_device scifb_device = {
@@ -273,7 +394,7 @@ static struct resource cmt10_resources[] = {
 		.flags	= IORESOURCE_MEM,
 	},
 	[1] = {
-		.start	= evt2irq(0x0b00),
+		.start	= gic_spi(58),
 		.flags	= IORESOURCE_IRQ,
 	},
 };
@@ -304,7 +425,7 @@ static struct resource tmu00_resources[] = {
 		.flags	= IORESOURCE_MEM,
 	},
 	[1] = {
-		.start	= intcs_evt2irq(0xe80),
+		.start	= gic_spi(198),
 		.flags	= IORESOURCE_IRQ,
 	},
 };
@@ -334,7 +455,7 @@ static struct resource tmu01_resources[] = {
 		.flags	= IORESOURCE_MEM,
 	},
 	[1] = {
-		.start	= intcs_evt2irq(0xea0),
+		.start	= gic_spi(199),
 		.flags	= IORESOURCE_IRQ,
 	},
 };
@@ -364,7 +485,7 @@ static struct resource tmu02_resources[] = {
 		.flags	= IORESOURCE_MEM,
 	},
 	[1] = {
-		.start	= intcs_evt2irq(0xec0),
+		.start	= gic_spi(200),
 		.flags	= IORESOURCE_IRQ,
 	},
 };
@@ -411,6 +532,10 @@ static struct platform_device ipmmu_device = {
 };
 
 static struct platform_device *r8a7740_early_devices[] __initdata = {
+	&irqpin0_device,
+	&irqpin1_device,
+	&irqpin2_device,
+	&irqpin3_device,
 	&scif0_device,
 	&scif1_device,
 	&scif2_device,
@@ -525,14 +650,14 @@ static struct resource r8a7740_dmae0_resources[] = {
 	},
 	{
 		.name	= "error_irq",
-		.start	= evt2irq(0x20c0),
-		.end	= evt2irq(0x20c0),
+		.start	= gic_spi(34),
+		.end	= gic_spi(34),
 		.flags	= IORESOURCE_IRQ,
 	},
 	{
 		/* IRQ for channels 0-5 */
-		.start	= evt2irq(0x2000),
-		.end	= evt2irq(0x20a0),
+		.start	= gic_spi(28),
+		.end	= gic_spi(33),
 		.flags	= IORESOURCE_IRQ,
 	},
 };
@@ -553,14 +678,14 @@ static struct resource r8a7740_dmae1_resources[] = {
 	},
 	{
 		.name	= "error_irq",
-		.start	= evt2irq(0x21c0),
-		.end	= evt2irq(0x21c0),
+		.start	= gic_spi(41),
+		.end	= gic_spi(41),
 		.flags	= IORESOURCE_IRQ,
 	},
 	{
 		/* IRQ for channels 0-5 */
-		.start	= evt2irq(0x2100),
-		.end	= evt2irq(0x21a0),
+		.start	= gic_spi(35),
+		.end	= gic_spi(40),
 		.flags	= IORESOURCE_IRQ,
 	},
 };
@@ -581,14 +706,14 @@ static struct resource r8a7740_dmae2_resources[] = {
 	},
 	{
 		.name	= "error_irq",
-		.start	= evt2irq(0x22c0),
-		.end	= evt2irq(0x22c0),
+		.start	= gic_spi(48),
+		.end	= gic_spi(48),
 		.flags	= IORESOURCE_IRQ,
 	},
 	{
 		/* IRQ for channels 0-5 */
-		.start	= evt2irq(0x2200),
-		.end	= evt2irq(0x22a0),
+		.start	= gic_spi(42),
+		.end	= gic_spi(47),
 		.flags	= IORESOURCE_IRQ,
 	},
 };
@@ -677,8 +802,8 @@ static struct resource r8a7740_usb_dma_resources[] = {
 	},
 	{
 		/* IRQ for channels */
-		.start	= evt2irq(0x0a00),
-		.end	= evt2irq(0x0a00),
+		.start	= gic_spi(49),
+		.end	= gic_spi(49),
 		.flags	= IORESOURCE_IRQ,
 	},
 };
@@ -702,8 +827,8 @@ static struct resource i2c0_resources[] = {
 		.flags	= IORESOURCE_MEM,
 	},
 	[1] = {
-		.start	= intcs_evt2irq(0xe00),
-		.end	= intcs_evt2irq(0xe60),
+		.start	= gic_spi(201),
+		.end	= gic_spi(204),
 		.flags	= IORESOURCE_IRQ,
 	},
 };
@@ -716,8 +841,8 @@ static struct resource i2c1_resources[] = {
 		.flags	= IORESOURCE_MEM,
 	},
 	[1] = {
-		.start  = evt2irq(0x780), /* IIC1_ALI1 */
-		.end    = evt2irq(0x7e0), /* IIC1_DTEI1 */
+		.start  = gic_spi(70), /* IIC1_ALI1 */
+		.end    = gic_spi(73), /* IIC1_DTEI1 */
 		.flags	= IORESOURCE_IRQ,
 	},
 };
@@ -738,8 +863,8 @@ static struct platform_device i2c1_device = {
 
 static struct resource pmu_resources[] = {
 	[0] = {
-		.start	= evt2irq(0x19a0),
-		.end	= evt2irq(0x19a0),
+		.start	= gic_spi(83),
+		.end	= gic_spi(83),
 		.flags  = IORESOURCE_IRQ,
 	},
 };
@@ -904,7 +1029,6 @@ DT_MACHINE_START(R8A7740_DT, "Generic R8A7740 (Flattened Device Tree)")
 	.map_io		= r8a7740_map_io,
 	.init_early	= r8a7740_add_early_devices_dt,
 	.init_irq	= r8a7740_init_irq,
-	.handle_irq	= shmobile_handle_irq_intc,
 	.init_machine	= r8a7740_add_standard_devices_dt,
 	.init_time	= shmobile_timer_init,
 	.dt_compat	= r8a7740_boards_compat_dt,
diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a7740.c b/drivers/pinctrl/sh-pfc/pfc-r8a7740.c
index 214788c..2b52828 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a7740.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a7740.c
@@ -2545,38 +2545,38 @@ static struct pinmux_data_reg pinmux_data_regs[] = {
 };
 
 static struct pinmux_irq pinmux_irqs[] = {
-	PINMUX_IRQ(evt2irq(0x0200), PORT2_FN0,	 PORT13_FN0),	/* IRQ0A */
-	PINMUX_IRQ(evt2irq(0x0220), PORT20_FN0),		/* IRQ1A */
-	PINMUX_IRQ(evt2irq(0x0240), PORT11_FN0,	 PORT12_FN0),	/* IRQ2A */
-	PINMUX_IRQ(evt2irq(0x0260), PORT10_FN0,	 PORT14_FN0),	/* IRQ3A */
-	PINMUX_IRQ(evt2irq(0x0280), PORT15_FN0,	 PORT172_FN0),	/* IRQ4A */
-	PINMUX_IRQ(evt2irq(0x02A0), PORT0_FN0,	 PORT1_FN0),	/* IRQ5A */
-	PINMUX_IRQ(evt2irq(0x02C0), PORT121_FN0, PORT173_FN0),	/* IRQ6A */
-	PINMUX_IRQ(evt2irq(0x02E0), PORT120_FN0, PORT209_FN0),	/* IRQ7A */
-	PINMUX_IRQ(evt2irq(0x0300), PORT119_FN0),		/* IRQ8A */
-	PINMUX_IRQ(evt2irq(0x0320), PORT118_FN0, PORT210_FN0),	/* IRQ9A */
-	PINMUX_IRQ(evt2irq(0x0340), PORT19_FN0),		/* IRQ10A */
-	PINMUX_IRQ(evt2irq(0x0360), PORT104_FN0),		/* IRQ11A */
-	PINMUX_IRQ(evt2irq(0x0380), PORT42_FN0,	 PORT97_FN0),	/* IRQ12A */
-	PINMUX_IRQ(evt2irq(0x03A0), PORT64_FN0,	 PORT98_FN0),	/* IRQ13A */
-	PINMUX_IRQ(evt2irq(0x03C0), PORT63_FN0,	 PORT99_FN0),	/* IRQ14A */
-	PINMUX_IRQ(evt2irq(0x03E0), PORT62_FN0,	 PORT100_FN0),	/* IRQ15A */
-	PINMUX_IRQ(evt2irq(0x3200), PORT68_FN0,	 PORT211_FN0),	/* IRQ16A */
-	PINMUX_IRQ(evt2irq(0x3220), PORT69_FN0),		/* IRQ17A */
-	PINMUX_IRQ(evt2irq(0x3240), PORT70_FN0),		/* IRQ18A */
-	PINMUX_IRQ(evt2irq(0x3260), PORT71_FN0),		/* IRQ19A */
-	PINMUX_IRQ(evt2irq(0x3280), PORT67_FN0),		/* IRQ20A */
-	PINMUX_IRQ(evt2irq(0x32A0), PORT202_FN0),		/* IRQ21A */
-	PINMUX_IRQ(evt2irq(0x32C0), PORT95_FN0),		/* IRQ22A */
-	PINMUX_IRQ(evt2irq(0x32E0), PORT96_FN0),		/* IRQ23A */
-	PINMUX_IRQ(evt2irq(0x3300), PORT180_FN0),		/* IRQ24A */
-	PINMUX_IRQ(evt2irq(0x3320), PORT38_FN0),		/* IRQ25A */
-	PINMUX_IRQ(evt2irq(0x3340), PORT58_FN0,	 PORT81_FN0),	/* IRQ26A */
-	PINMUX_IRQ(evt2irq(0x3360), PORT57_FN0,	 PORT168_FN0),	/* IRQ27A */
-	PINMUX_IRQ(evt2irq(0x3380), PORT56_FN0,	 PORT169_FN0),	/* IRQ28A */
-	PINMUX_IRQ(evt2irq(0x33A0), PORT50_FN0,	 PORT170_FN0),	/* IRQ29A */
-	PINMUX_IRQ(evt2irq(0x33C0), PORT49_FN0,	 PORT171_FN0),	/* IRQ30A */
-	PINMUX_IRQ(evt2irq(0x33E0), PORT41_FN0,	 PORT167_FN0),	/* IRQ31A */
+	PINMUX_IRQ(irq_pin(0), GPIO_PORT2,   GPIO_PORT13),	/* IRQ0A */
+	PINMUX_IRQ(irq_pin(1), GPIO_PORT20),		/* IRQ1A */
+	PINMUX_IRQ(irq_pin(2), GPIO_PORT11,  GPIO_PORT12),	/* IRQ2A */
+	PINMUX_IRQ(irq_pin(3), GPIO_PORT10,  GPIO_PORT14),	/* IRQ3A */
+	PINMUX_IRQ(irq_pin(4), GPIO_PORT15,  GPIO_PORT172),/* IRQ4A */
+	PINMUX_IRQ(irq_pin(5), GPIO_PORT0,   GPIO_PORT1),	/* IRQ5A */
+	PINMUX_IRQ(irq_pin(6), GPIO_PORT121, GPIO_PORT173),/* IRQ6A */
+	PINMUX_IRQ(irq_pin(7), GPIO_PORT120, GPIO_PORT209),/* IRQ7A */
+	PINMUX_IRQ(irq_pin(8), GPIO_PORT119),		/* IRQ8A */
+	PINMUX_IRQ(irq_pin(9), GPIO_PORT118, GPIO_PORT210),/* IRQ9A */
+	PINMUX_IRQ(irq_pin(10), GPIO_PORT19),		/* IRQ10A */
+	PINMUX_IRQ(irq_pin(11), GPIO_PORT104),		/* IRQ11A */
+	PINMUX_IRQ(irq_pin(12), GPIO_PORT42,  GPIO_PORT97),	/* IRQ12A */
+	PINMUX_IRQ(irq_pin(13), GPIO_PORT64,  GPIO_PORT98),	/* IRQ13A */
+	PINMUX_IRQ(irq_pin(14), GPIO_PORT63,  GPIO_PORT99),	/* IRQ14A */
+	PINMUX_IRQ(irq_pin(15), GPIO_PORT62,  GPIO_PORT100),/* IRQ15A */
+	PINMUX_IRQ(irq_pin(16), GPIO_PORT68,  GPIO_PORT211),/* IRQ16A */
+	PINMUX_IRQ(irq_pin(17), GPIO_PORT69),		/* IRQ17A */
+	PINMUX_IRQ(irq_pin(18), GPIO_PORT70),		/* IRQ18A */
+	PINMUX_IRQ(irq_pin(19), GPIO_PORT71),		/* IRQ19A */
+	PINMUX_IRQ(irq_pin(20), GPIO_PORT67),		/* IRQ20A */
+	PINMUX_IRQ(irq_pin(21), GPIO_PORT202),		/* IRQ21A */
+	PINMUX_IRQ(irq_pin(22), GPIO_PORT95),		/* IRQ22A */
+	PINMUX_IRQ(irq_pin(23), GPIO_PORT96),		/* IRQ23A */
+	PINMUX_IRQ(irq_pin(24), GPIO_PORT180),		/* IRQ24A */
+	PINMUX_IRQ(irq_pin(25), GPIO_PORT38),		/* IRQ25A */
+	PINMUX_IRQ(irq_pin(26), GPIO_PORT58,  GPIO_PORT81),	/* IRQ26A */
+	PINMUX_IRQ(irq_pin(27), GPIO_PORT57,  GPIO_PORT168),/* IRQ27A */
+	PINMUX_IRQ(irq_pin(28), GPIO_PORT56,  GPIO_PORT169),/* IRQ28A */
+	PINMUX_IRQ(irq_pin(29), GPIO_PORT50,  GPIO_PORT170),/* IRQ29A */
+	PINMUX_IRQ(irq_pin(30), GPIO_PORT49,  GPIO_PORT171),/* IRQ30A */
+	PINMUX_IRQ(irq_pin(31), GPIO_PORT41,  GPIO_PORT167),/* IRQ31A */
 };
 
 struct sh_pfc_soc_info r8a7740_pinmux_info = {
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 01:09:10 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue,  2 Apr 2013 14:09:10 +0900
Subject: [PATCH 02/28] sh: sh7269: Fix compilation by adding missing includes
In-Reply-To: <1364879376-10020-1-git-send-email-horms+renesas@verge.net.au>
References: <1364879376-10020-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364879376-10020-3-git-send-email-horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

struct resource is defined in linux/ioport.h. Include it.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/sh/kernel/cpu/sh2a/pinmux-sh7269.c |    2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/sh/kernel/cpu/sh2a/pinmux-sh7269.c b/arch/sh/kernel/cpu/sh2a/pinmux-sh7269.c
index 1825b0b..4c17fb6 100644
--- a/arch/sh/kernel/cpu/sh2a/pinmux-sh7269.c
+++ b/arch/sh/kernel/cpu/sh2a/pinmux-sh7269.c
@@ -9,7 +9,9 @@
  * for more details.
  */
 
+#include <linux/bug.h>
 #include <linux/init.h>
+#include <linux/ioport.h>
 #include <linux/kernel.h>
 #include <cpu/pfc.h>
 
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 01:09:09 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue,  2 Apr 2013 14:09:09 +0900
Subject: [PATCH 01/28] sh-pfc: Fix compiler warning when BUG()
In-Reply-To: <1364879376-10020-1-git-send-email-horms+renesas@verge.net.au>
References: <1364879376-10020-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364879376-10020-2-git-send-email-horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

The sh_pfc_phys_to_virt() function ends with a BUG() statement without a
return. When CONFIG_BUG isn't set the function will thus have no return
value. Fix it.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 drivers/pinctrl/sh-pfc/core.c |    1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/pinctrl/sh-pfc/core.c b/drivers/pinctrl/sh-pfc/core.c
index feef897..97e6ea3 100644
--- a/drivers/pinctrl/sh-pfc/core.c
+++ b/drivers/pinctrl/sh-pfc/core.c
@@ -72,6 +72,7 @@ static void __iomem *sh_pfc_phys_to_virt(struct sh_pfc *pfc,
 	}
 
 	BUG();
+	return NULL;
 }
 
 int sh_pfc_get_pin_index(struct sh_pfc *pfc, unsigned int pin)
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 01:09:08 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue,  2 Apr 2013 14:09:08 +0900
Subject: [GIT PULL] Renesas ARM and SH based SoC pinmux updates for v3.10 #2
Message-ID: <1364879376-10020-1-git-send-email-horms+renesas@verge.net.au>

Hi Arnd, Hi Olof,

The following changes since commit 809609a5d8427b0025304dbb69a84a692d11c4f9:

  Merge branch 'soc' into pinmux-base (2013-04-02 11:08:34 +0900)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-pinmux2-for-v3.10

for you to fetch changes up to bae8c3e07e37c7a8106435fbfe62bd3d7ec2212a:

  sh-pfc: r8a73a4: Remove unused GPIO bias data (2013-04-02 11:11:16 +0900)

----------------------------------------------------------------
Second round of Renesas ARM and SH based SoC pinmux updates for v3.10

Highlights:

* Compilation fixes for sh7269 and for when CONFIG_BUG is not set
* sh-pfc Support for r8a73a4 SoC
* Move GPIOs handling from the PFC device to separate GPIO devices
  on the r8a7779 SoC

This pull request is based on a merge of:
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas renesas-pinmux-for-v3.10
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas renesas-soc2-for-v3.10

----------------------------------------------------------------
Laurent Pinchart (14):
      sh-pfc: Fix compiler warning when BUG()
      sh: sh7269: Fix compilation by adding missing includes
      sh-pfc: r8a7779: Remove function GPIOs
      sh-pfc: r8a7779: Don't use GPIO enum entries
      ARM: shmobile: r8a7779: Remove all GPIOs
      gpio-rcar: Add pinctrl support
      ARM: shmobile: marzen: Add GPIO LEDs
      sh-pfc: Make function GPIOs support optional
      sh-pfc: Make GPIO support optional
      sh-pfc: Skip gpiochip registration when no GPIO resource is found
      sh-pfc: Configure pins as GPIOs at request time when handled externally
      ARM: shmobile: r8a7779: Register GPIO devices
      sh-pfc: r8a7779: Remove GPIO data
      sh-pfc: r8a7779: Split DU input and output pixel clocks

Magnus Damm (14):
      gpio: Renesas R-Car GPIO driver V3
      sh-pfc: Add r8a73a4 pinmux support
      sh-pfc: r8a73a4: Support sparse GPIO numbers
      sh-pfc: r8a73a4: GPIO IRQ support
      sh-pfc: r8a73a4: Add bias (pull-up/down) pinconf support
      sh-pfc: r8a73a4: Add SCIF pin groups and functions
      sh-pfc: r8a73a4: Add IRQC pin groups and functions
      sh-pfc: r8a73a4: Remove SCIF function GPIOS
      sh-pfc: r8a73a4: Remove IRQC function GPIOS
      ARM: shmobile: r8a73a4: Remove SCIF function GPIOs
      ARM: shmobile: r8a73a4: Remove IRQC function GPIOs
      sh-pfc: r8a73a4: Remove function GPIOs
      ARM: shmobile: r8a73a4: Remove all GPIO enums
      sh-pfc: r8a73a4: Remove unused GPIO bias data

 arch/arm/mach-shmobile/board-marzen.c         |   32 +
 arch/arm/mach-shmobile/include/mach/r8a7779.h |  317 ---
 arch/arm/mach-shmobile/setup-r8a7779.c        |   58 +-
 arch/sh/kernel/cpu/sh2a/pinmux-sh7269.c       |    2 +
 drivers/gpio/Kconfig                          |    6 +
 drivers/gpio/Makefile                         |    1 +
 drivers/gpio/gpio-rcar.c                      |  396 ++++
 drivers/pinctrl/sh-pfc/Kconfig                |    5 +
 drivers/pinctrl/sh-pfc/Makefile               |    1 +
 drivers/pinctrl/sh-pfc/core.c                 |   41 +-
 drivers/pinctrl/sh-pfc/core.h                 |    1 +
 drivers/pinctrl/sh-pfc/gpio.c                 |   45 +-
 drivers/pinctrl/sh-pfc/pfc-r8a73a4.c          | 2587 +++++++++++++++++++++++++
 drivers/pinctrl/sh-pfc/pfc-r8a7779.c          |  479 +----
 drivers/pinctrl/sh-pfc/pinctrl.c              |   11 +
 include/linux/platform_data/gpio-rcar.h       |   26 +
 16 files changed, 3274 insertions(+), 734 deletions(-)
 create mode 100644 drivers/gpio/gpio-rcar.c
 create mode 100644 drivers/pinctrl/sh-pfc/pfc-r8a73a4.c
 create mode 100644 include/linux/platform_data/gpio-rcar.h


From horms+renesas at verge.net.au  Tue Apr  2 01:09:16 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue,  2 Apr 2013 14:09:16 +0900
Subject: [PATCH 08/28] ARM: shmobile: marzen: Add GPIO LEDs
In-Reply-To: <1364879376-10020-1-git-send-email-horms+renesas@verge.net.au>
References: <1364879376-10020-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364879376-10020-9-git-send-email-horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

The board has 3 LEDs connected to GPIOs. Add a led-gpio device to
support them.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/board-marzen.c |   32 ++++++++++++++++++++++++++++++++
 1 file changed, 32 insertions(+)

diff --git a/arch/arm/mach-shmobile/board-marzen.c b/arch/arm/mach-shmobile/board-marzen.c
index 5852331..a88f7f3 100644
--- a/arch/arm/mach-shmobile/board-marzen.c
+++ b/arch/arm/mach-shmobile/board-marzen.c
@@ -25,6 +25,7 @@
 #include <linux/platform_device.h>
 #include <linux/delay.h>
 #include <linux/io.h>
+#include <linux/leds.h>
 #include <linux/dma-mapping.h>
 #include <linux/pinctrl/machine.h>
 #include <linux/regulator/fixed.h>
@@ -168,12 +169,43 @@ static struct platform_device usb_phy_device = {
 	.num_resources	= ARRAY_SIZE(usb_phy_resources),
 };
 
+/* LEDS */
+static struct gpio_led marzen_leds[] = {
+	{
+		.name		= "led2",
+		.gpio		= 157,
+		.default_state	= LEDS_GPIO_DEFSTATE_ON,
+	}, {
+		.name		= "led3",
+		.gpio		= 158,
+		.default_state	= LEDS_GPIO_DEFSTATE_ON,
+	}, {
+		.name		= "led4",
+		.gpio		= 159,
+		.default_state	= LEDS_GPIO_DEFSTATE_ON,
+	},
+};
+
+static struct gpio_led_platform_data marzen_leds_pdata = {
+	.leds		= marzen_leds,
+	.num_leds	= ARRAY_SIZE(marzen_leds),
+};
+
+static struct platform_device leds_device = {
+	.name	= "leds-gpio",
+	.id	= 0,
+	.dev	= {
+		.platform_data  = &marzen_leds_pdata,
+	},
+};
+
 static struct platform_device *marzen_devices[] __initdata = {
 	&eth_device,
 	&sdhi0_device,
 	&thermal_device,
 	&hspi_device,
 	&usb_phy_device,
+	&leds_device,
 };
 
 /* USB */
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 01:09:15 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue,  2 Apr 2013 14:09:15 +0900
Subject: [PATCH 07/28] gpio-rcar: Add pinctrl support
In-Reply-To: <1364879376-10020-1-git-send-email-horms+renesas@verge.net.au>
References: <1364879376-10020-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364879376-10020-8-git-send-email-horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

Register the GPIO pin range, and request and free GPIO pins using the
pinctrl API.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Acked-by: Linus Walleij <linus.walleij at linaro.org>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 drivers/gpio/gpio-rcar.c                |   23 +++++++++++++++++++++++
 include/linux/platform_data/gpio-rcar.h |    1 +
 2 files changed, 24 insertions(+)

diff --git a/drivers/gpio/gpio-rcar.c b/drivers/gpio/gpio-rcar.c
index 581ba56..b4ca450 100644
--- a/drivers/gpio/gpio-rcar.c
+++ b/drivers/gpio/gpio-rcar.c
@@ -22,6 +22,7 @@
 #include <linux/irq.h>
 #include <linux/irqdomain.h>
 #include <linux/module.h>
+#include <linux/pinctrl/consumer.h>
 #include <linux/platform_data/gpio-rcar.h>
 #include <linux/platform_device.h>
 #include <linux/spinlock.h>
@@ -190,6 +191,21 @@ static void gpio_rcar_config_general_input_output_mode(struct gpio_chip *chip,
 	spin_unlock_irqrestore(&p->lock, flags);
 }
 
+static int gpio_rcar_request(struct gpio_chip *chip, unsigned offset)
+{
+	return pinctrl_request_gpio(chip->base + offset);
+}
+
+static void gpio_rcar_free(struct gpio_chip *chip, unsigned offset)
+{
+	pinctrl_free_gpio(chip->base + offset);
+
+	/* Set the GPIO as an input to ensure that the next GPIO request won't
+	 * drive the GPIO pin as an output.
+	 */
+	gpio_rcar_config_general_input_output_mode(chip, offset, false);
+}
+
 static int gpio_rcar_direction_input(struct gpio_chip *chip, unsigned offset)
 {
 	gpio_rcar_config_general_input_output_mode(chip, offset, false);
@@ -285,6 +301,8 @@ static int gpio_rcar_probe(struct platform_device *pdev)
 	}
 
 	gpio_chip = &p->gpio_chip;
+	gpio_chip->request = gpio_rcar_request;
+	gpio_chip->free = gpio_rcar_free;
 	gpio_chip->direction_input = gpio_rcar_direction_input;
 	gpio_chip->get = gpio_rcar_get;
 	gpio_chip->direction_output = gpio_rcar_direction_output;
@@ -337,6 +355,11 @@ static int gpio_rcar_probe(struct platform_device *pdev)
 				 p->config.irq_base, ret);
 	}
 
+	ret = gpiochip_add_pin_range(gpio_chip, p->config.pctl_name, 0,
+				     gpio_chip->base, gpio_chip->ngpio);
+	if (ret < 0)
+		dev_warn(&pdev->dev, "failed to add pin range\n");
+
 	return 0;
 
 err1:
diff --git a/include/linux/platform_data/gpio-rcar.h b/include/linux/platform_data/gpio-rcar.h
index bebfcd8..b253f77 100644
--- a/include/linux/platform_data/gpio-rcar.h
+++ b/include/linux/platform_data/gpio-rcar.h
@@ -20,6 +20,7 @@ struct gpio_rcar_config {
 	unsigned int gpio_base;
 	unsigned int irq_base;
 	unsigned int number_of_pins;
+	const char *pctl_name;
 };
 
 #endif /* __GPIO_RCAR_H__ */
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 01:09:18 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue,  2 Apr 2013 14:09:18 +0900
Subject: [PATCH 10/28] sh-pfc: Make GPIO support optional
In-Reply-To: <1364879376-10020-1-git-send-email-horms+renesas@verge.net.au>
References: <1364879376-10020-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364879376-10020-11-git-send-email-horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

When implemented as a separate IP block, GPIOs should be handled by a
separate driver. To make this possible GPIO support needs to be optional
in the sh-pfc driver.

If no GPIO data registers are supplied in the SoC information structure
skip registration of the gpiochip.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Acked-by: Linus Walleij <linus.walleij at linaro.org>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 drivers/pinctrl/sh-pfc/gpio.c |    3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/pinctrl/sh-pfc/gpio.c b/drivers/pinctrl/sh-pfc/gpio.c
index 7a54ec7..317cebb 100644
--- a/drivers/pinctrl/sh-pfc/gpio.c
+++ b/drivers/pinctrl/sh-pfc/gpio.c
@@ -354,6 +354,9 @@ int sh_pfc_register_gpiochip(struct sh_pfc *pfc)
 	unsigned int i;
 	int ret;
 
+	if (pfc->info->data_regs == NULL)
+		return 0;
+
 	/* Register the real GPIOs chip. */
 	chip = sh_pfc_add_gpiochip(pfc, gpio_pin_setup);
 	if (IS_ERR(chip))
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 01:09:12 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue,  2 Apr 2013 14:09:12 +0900
Subject: [PATCH 04/28] sh-pfc: r8a7779: Don't use GPIO enum entries
In-Reply-To: <1364879376-10020-1-git-send-email-horms+renesas@verge.net.au>
References: <1364879376-10020-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364879376-10020-5-git-send-email-horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

Refactor the GPIO macro magic to use GPIO numbers directly instead of
the GPIO_GP_x_y enum entries. This will allow removing the GPIO enum
entries from the mach/r8a7779.h header.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Acked-by: Linus Walleij <linus.walleij at linaro.org>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 drivers/pinctrl/sh-pfc/pfc-r8a7779.c |  104 ++++++++++++++++++++++++----------
 1 file changed, 74 insertions(+), 30 deletions(-)

diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a7779.c b/drivers/pinctrl/sh-pfc/pfc-r8a7779.c
index 4db9944..41d8bda 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a7779.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a7779.c
@@ -19,39 +19,83 @@
  */
 
 #include <linux/kernel.h>
-#include <mach/r8a7779.h>
 
 #include "sh_pfc.h"
 
-#define CPU_32_PORT6(fn, pfx, sfx)				\
-	PORT_1(fn, pfx##0, sfx), PORT_1(fn, pfx##1, sfx),	\
-	PORT_1(fn, pfx##2, sfx), PORT_1(fn, pfx##3, sfx),	\
-	PORT_1(fn, pfx##4, sfx), PORT_1(fn, pfx##5, sfx),	\
-	PORT_1(fn, pfx##6, sfx), PORT_1(fn, pfx##7, sfx),	\
-	PORT_1(fn, pfx##8, sfx)
-
-#define CPU_ALL_PORT(fn, pfx, sfx)				\
-	PORT_32(fn, pfx##_0_, sfx),				\
-	PORT_32(fn, pfx##_1_, sfx),				\
-	PORT_32(fn, pfx##_2_, sfx),				\
-	PORT_32(fn, pfx##_3_, sfx),				\
-	PORT_32(fn, pfx##_4_, sfx),				\
-	PORT_32(fn, pfx##_5_, sfx),				\
-	CPU_32_PORT6(fn, pfx##_6_, sfx)
-
-#define _GP_GPIO(pfx, sfx) PINMUX_GPIO(GPIO_GP##pfx, GP##pfx##_DATA)
-#define _GP_DATA(pfx, sfx) PINMUX_DATA(GP##pfx##_DATA, GP##pfx##_FN,	\
-				       GP##pfx##_IN, GP##pfx##_OUT)
-
-#define _GP_INOUTSEL(pfx, sfx) GP##pfx##_IN, GP##pfx##_OUT
-#define _GP_INDT(pfx, sfx) GP##pfx##_DATA
-
-#define GP_ALL(str)	CPU_ALL_PORT(_PORT_ALL, GP, str)
-#define PINMUX_GPIO_GP_ALL()	CPU_ALL_PORT(_GP_GPIO, , unused)
-#define PINMUX_DATA_GP_ALL()	CPU_ALL_PORT(_GP_DATA, , unused)
-
-#define GP_INOUTSEL(bank) PORT_32_REV(_GP_INOUTSEL, _##bank##_, unused)
-#define GP_INDT(bank) PORT_32_REV(_GP_INDT, _##bank##_, unused)
+#define PORT_GP_1(bank, pin, fn, sfx) fn(bank, pin, GP_##bank##_##pin, sfx)
+
+#define PORT_GP_32(bank, fn, sfx)					\
+	PORT_GP_1(bank, 0,  fn, sfx), PORT_GP_1(bank, 1,  fn, sfx),	\
+	PORT_GP_1(bank, 2,  fn, sfx), PORT_GP_1(bank, 3,  fn, sfx),	\
+	PORT_GP_1(bank, 4,  fn, sfx), PORT_GP_1(bank, 5,  fn, sfx),	\
+	PORT_GP_1(bank, 6,  fn, sfx), PORT_GP_1(bank, 7,  fn, sfx),	\
+	PORT_GP_1(bank, 8,  fn, sfx), PORT_GP_1(bank, 9,  fn, sfx),	\
+	PORT_GP_1(bank, 10, fn, sfx), PORT_GP_1(bank, 11, fn, sfx),	\
+	PORT_GP_1(bank, 12, fn, sfx), PORT_GP_1(bank, 13, fn, sfx),	\
+	PORT_GP_1(bank, 14, fn, sfx), PORT_GP_1(bank, 15, fn, sfx),	\
+	PORT_GP_1(bank, 16, fn, sfx), PORT_GP_1(bank, 17, fn, sfx),	\
+	PORT_GP_1(bank, 18, fn, sfx), PORT_GP_1(bank, 19, fn, sfx),	\
+	PORT_GP_1(bank, 20, fn, sfx), PORT_GP_1(bank, 21, fn, sfx),	\
+	PORT_GP_1(bank, 22, fn, sfx), PORT_GP_1(bank, 23, fn, sfx),	\
+	PORT_GP_1(bank, 24, fn, sfx), PORT_GP_1(bank, 25, fn, sfx),	\
+	PORT_GP_1(bank, 26, fn, sfx), PORT_GP_1(bank, 27, fn, sfx),	\
+	PORT_GP_1(bank, 28, fn, sfx), PORT_GP_1(bank, 29, fn, sfx),	\
+	PORT_GP_1(bank, 30, fn, sfx), PORT_GP_1(bank, 31, fn, sfx)
+
+#define PORT_GP_32_9(bank, fn, sfx)					\
+	PORT_GP_1(bank, 0, fn, sfx), PORT_GP_1(bank, 1, fn, sfx),	\
+	PORT_GP_1(bank, 2, fn, sfx), PORT_GP_1(bank, 3, fn, sfx),	\
+	PORT_GP_1(bank, 4, fn, sfx), PORT_GP_1(bank, 5, fn, sfx),	\
+	PORT_GP_1(bank, 6, fn, sfx), PORT_GP_1(bank, 7, fn, sfx),	\
+	PORT_GP_1(bank, 8, fn, sfx)
+
+#define PORT_GP_32_REV(bank, fn, sfx)					\
+	PORT_GP_1(bank, 31, fn, sfx), PORT_GP_1(bank, 30, fn, sfx),	\
+	PORT_GP_1(bank, 29, fn, sfx), PORT_GP_1(bank, 28, fn, sfx),	\
+	PORT_GP_1(bank, 27, fn, sfx), PORT_GP_1(bank, 26, fn, sfx),	\
+	PORT_GP_1(bank, 25, fn, sfx), PORT_GP_1(bank, 24, fn, sfx),	\
+	PORT_GP_1(bank, 23, fn, sfx), PORT_GP_1(bank, 22, fn, sfx),	\
+	PORT_GP_1(bank, 21, fn, sfx), PORT_GP_1(bank, 20, fn, sfx),	\
+	PORT_GP_1(bank, 19, fn, sfx), PORT_GP_1(bank, 18, fn, sfx),	\
+	PORT_GP_1(bank, 17, fn, sfx), PORT_GP_1(bank, 16, fn, sfx),	\
+	PORT_GP_1(bank, 15, fn, sfx), PORT_GP_1(bank, 14, fn, sfx),	\
+	PORT_GP_1(bank, 13, fn, sfx), PORT_GP_1(bank, 12, fn, sfx),	\
+	PORT_GP_1(bank, 11, fn, sfx), PORT_GP_1(bank, 10, fn, sfx),	\
+	PORT_GP_1(bank, 9,  fn, sfx), PORT_GP_1(bank, 8,  fn, sfx),	\
+	PORT_GP_1(bank, 7,  fn, sfx), PORT_GP_1(bank, 6,  fn, sfx),	\
+	PORT_GP_1(bank, 5,  fn, sfx), PORT_GP_1(bank, 4,  fn, sfx),	\
+	PORT_GP_1(bank, 3,  fn, sfx), PORT_GP_1(bank, 2,  fn, sfx),	\
+	PORT_GP_1(bank, 1,  fn, sfx), PORT_GP_1(bank, 0,  fn, sfx)
+
+#define CPU_ALL_PORT(fn, sfx)						\
+	PORT_GP_32(0, fn, sfx),						\
+	PORT_GP_32(1, fn, sfx),						\
+	PORT_GP_32(2, fn, sfx),						\
+	PORT_GP_32(3, fn, sfx),						\
+	PORT_GP_32(4, fn, sfx),						\
+	PORT_GP_32(5, fn, sfx),						\
+	PORT_GP_32_9(6, fn, sfx)
+
+#define _GP_PORT_ALL(bank, pin, name, sfx)	name##_##sfx
+
+#define _GP_GPIO(bank, pin, _name, sfx)					\
+	[(bank * 32) + pin] = {						\
+		.name = __stringify(_name),				\
+		.enum_id = _name##_DATA,				\
+	}
+
+#define _GP_DATA(bank, pin, name, sfx)					\
+	PINMUX_DATA(name##_DATA, name##_FN, name##_IN, name##_OUT)
+
+#define _GP_INOUTSEL(bank, pin, name, sfx)	name##_IN, name##_OUT
+#define _GP_INDT(bank, pin, name, sfx)		name##_DATA
+
+#define GP_ALL(str)		CPU_ALL_PORT(_GP_PORT_ALL, str)
+#define PINMUX_GPIO_GP_ALL()	CPU_ALL_PORT(_GP_GPIO, unused)
+#define PINMUX_DATA_GP_ALL()	CPU_ALL_PORT(_GP_DATA, unused)
+
+#define GP_INOUTSEL(bank) PORT_GP_32_REV(bank, _GP_INOUTSEL, unused)
+#define GP_INDT(bank) PORT_GP_32_REV(bank, _GP_INDT, unused)
 
 #define PINMUX_IPSR_DATA(ipsr, fn) PINMUX_DATA(fn##_MARK, FN_##ipsr, FN_##fn)
 #define PINMUX_IPSR_MODSEL_DATA(ipsr, fn, ms) PINMUX_DATA(fn##_MARK, FN_##ms, \
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 01:09:17 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue,  2 Apr 2013 14:09:17 +0900
Subject: [PATCH 09/28] sh-pfc: Make function GPIOs support optional
In-Reply-To: <1364879376-10020-1-git-send-email-horms+renesas@verge.net.au>
References: <1364879376-10020-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364879376-10020-10-git-send-email-horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

The target is to get rid of function GPIOs completely. To reach this,
make function GPIOs support optional by skipping the function GPIO chip
registration if no function GPIOS are defined in SoC data.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Acked-by: Linus Walleij <linus.walleij at linaro.org>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 drivers/pinctrl/sh-pfc/gpio.c |    3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/pinctrl/sh-pfc/gpio.c b/drivers/pinctrl/sh-pfc/gpio.c
index d7acb06..7a54ec7 100644
--- a/drivers/pinctrl/sh-pfc/gpio.c
+++ b/drivers/pinctrl/sh-pfc/gpio.c
@@ -384,6 +384,9 @@ int sh_pfc_register_gpiochip(struct sh_pfc *pfc)
 	}
 
 	/* Register the function GPIOs chip. */
+	if (pfc->info->nr_func_gpios == 0)
+		return 0;
+
 	chip = sh_pfc_add_gpiochip(pfc, gpio_function_setup);
 	if (IS_ERR(chip))
 		return PTR_ERR(chip);
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 01:09:11 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue,  2 Apr 2013 14:09:11 +0900
Subject: [PATCH 03/28] sh-pfc: r8a7779: Remove function GPIOs
In-Reply-To: <1364879376-10020-1-git-send-email-horms+renesas@verge.net.au>
References: <1364879376-10020-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364879376-10020-4-git-send-email-horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

All r8a7779 platforms use the pinctrl API to control functions. Function
GPIOs are unused and unneeded, remove them.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Acked-by: Linus Walleij <linus.walleij at linaro.org>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 drivers/pinctrl/sh-pfc/pfc-r8a7779.c |  271 ----------------------------------
 1 file changed, 271 deletions(-)

diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a7779.c b/drivers/pinctrl/sh-pfc/pfc-r8a7779.c
index 1d7b0df..4db9944 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a7779.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a7779.c
@@ -2670,274 +2670,6 @@ static const struct sh_pfc_function pinmux_functions[] = {
 	SH_PFC_FUNCTION(usb2),
 };
 
-#define PINMUX_FN_BASE	ARRAY_SIZE(pinmux_pins)
-
-static const struct pinmux_func pinmux_func_gpios[] = {
-	GPIO_FN(AVS1), GPIO_FN(AVS2), GPIO_FN(A17), GPIO_FN(A18),
-	GPIO_FN(A19),
-
-	/* IPSR0 */
-	GPIO_FN(PWM1), GPIO_FN(PWMFSW0),
-	GPIO_FN(SCIF_CLK), GPIO_FN(TCLK0_C), GPIO_FN(BS),
-	GPIO_FN(FD2), GPIO_FN(ATADIR0), GPIO_FN(SDSELF),
-	GPIO_FN(HCTS1), GPIO_FN(A0),
-	GPIO_FN(FD3), GPIO_FN(A20),
-	GPIO_FN(A21),
-	GPIO_FN(A22),
-	GPIO_FN(VI1_R0), GPIO_FN(A23), GPIO_FN(FCLE),
-	GPIO_FN(VI1_R1), GPIO_FN(A24),
-	GPIO_FN(FD4),	GPIO_FN(VI1_R2),
-	GPIO_FN(SSI_WS78_B), GPIO_FN(A25),
-	GPIO_FN(FD5), GPIO_FN(VI1_R3),
-	GPIO_FN(SSI_SDATA7_B), GPIO_FN(CLKOUT),
-	GPIO_FN(PWM0_B),
-	GPIO_FN(SDSELF_B), GPIO_FN(RD_WR), GPIO_FN(FWE), GPIO_FN(ATAG0),
-	GPIO_FN(VI1_R7), GPIO_FN(HRTS1),
-
-	/* IPSR1 */
-	GPIO_FN(FD6), GPIO_FN(FD7),
-	GPIO_FN(FALE),
-	GPIO_FN(ATACS00),
-	GPIO_FN(FRE), GPIO_FN(ATACS10), GPIO_FN(VI1_R4),
-	GPIO_FN(HSCK1), GPIO_FN(SSI_SDATA8_B),
-	GPIO_FN(SSI_SDATA9),
-	GPIO_FN(FD0), GPIO_FN(ATARD0), GPIO_FN(VI1_R5),
-	GPIO_FN(HTX1),
-	GPIO_FN(SSI_SCK9),
-	GPIO_FN(FD1),	GPIO_FN(ATAWR0), GPIO_FN(VI1_R6),
-	GPIO_FN(HRX1), GPIO_FN(SSI_WS9),
-	GPIO_FN(MLB_CLK), GPIO_FN(PWM2), GPIO_FN(MLB_SIG),
-	GPIO_FN(PWM3), GPIO_FN(MLB_DAT), GPIO_FN(PWM4),
-	GPIO_FN(HTX0), GPIO_FN(SDATA),
-	GPIO_FN(SUB_TCK), GPIO_FN(CC5_STATE2),
-	GPIO_FN(CC5_STATE10), GPIO_FN(CC5_STATE18), GPIO_FN(CC5_STATE26),
-	GPIO_FN(CC5_STATE34),
-
-	/* IPSR2 */
-	GPIO_FN(HRX0), GPIO_FN(SCKZ),
-	GPIO_FN(SUB_TDI), GPIO_FN(CC5_STATE3), GPIO_FN(CC5_STATE11),
-	GPIO_FN(CC5_STATE19), GPIO_FN(CC5_STATE27), GPIO_FN(CC5_STATE35),
-	GPIO_FN(HSCK0), GPIO_FN(MTS), GPIO_FN(PWM5),
-	GPIO_FN(SSI_SDATA9_B), GPIO_FN(SUB_TDO),
-	GPIO_FN(CC5_STATE0), GPIO_FN(CC5_STATE8), GPIO_FN(CC5_STATE16),
-	GPIO_FN(CC5_STATE24), GPIO_FN(CC5_STATE32), GPIO_FN(HCTS0),
-	GPIO_FN(STM), GPIO_FN(PWM0_D),
-	GPIO_FN(SCIF_CLK_C), GPIO_FN(SUB_TRST), GPIO_FN(TCLK1_B),
-	GPIO_FN(CC5_OSCOUT), GPIO_FN(HRTS0),
-	GPIO_FN(MDATA), GPIO_FN(SUB_TMS), GPIO_FN(CC5_STATE1),
-	GPIO_FN(CC5_STATE9), GPIO_FN(CC5_STATE17), GPIO_FN(CC5_STATE25),
-	GPIO_FN(CC5_STATE33), GPIO_FN(LCDOUT0),
-	GPIO_FN(DREQ0), GPIO_FN(GPS_CLK_B), GPIO_FN(AUDATA0),
-	GPIO_FN(LCDOUT1), GPIO_FN(DACK0),
-	GPIO_FN(DRACK0), GPIO_FN(GPS_SIGN_B), GPIO_FN(AUDATA1),
-	GPIO_FN(LCDOUT2), GPIO_FN(LCDOUT3),
-	GPIO_FN(LCDOUT4), GPIO_FN(LCDOUT5),
-	GPIO_FN(LCDOUT6), GPIO_FN(LCDOUT7),
-	GPIO_FN(LCDOUT8), GPIO_FN(DREQ1), GPIO_FN(SCL2),
-	GPIO_FN(AUDATA2),
-
-	/* IPSR3 */
-	GPIO_FN(LCDOUT9), GPIO_FN(DACK1), GPIO_FN(SDA2),
-	GPIO_FN(AUDATA3), GPIO_FN(LCDOUT10),
-	GPIO_FN(LCDOUT11),
-	GPIO_FN(LCDOUT12), GPIO_FN(LCDOUT13),
-	GPIO_FN(LCDOUT14),
-	GPIO_FN(LCDOUT15), GPIO_FN(LCDOUT16),
-	GPIO_FN(EX_WAIT1), GPIO_FN(SCL1), GPIO_FN(TCLK1), GPIO_FN(AUDATA4),
-	GPIO_FN(LCDOUT17), GPIO_FN(EX_WAIT2), GPIO_FN(SDA1),
-	GPIO_FN(GPS_MAG_B), GPIO_FN(AUDATA5),
-	GPIO_FN(LCDOUT18),
-	GPIO_FN(LCDOUT19), GPIO_FN(LCDOUT20),
-	GPIO_FN(LCDOUT21),
-	GPIO_FN(LCDOUT22), GPIO_FN(LCDOUT23),
-	GPIO_FN(QSTVA_QVS),
-	GPIO_FN(SCL3_B), GPIO_FN(QCLK),
-	GPIO_FN(QSTVB_QVE),
-	GPIO_FN(SDA3_B), GPIO_FN(SDA2_C), GPIO_FN(DACK0_B), GPIO_FN(DRACK0_B),
-	GPIO_FN(QSTH_QHS),
-	GPIO_FN(QSTB_QHE),
-	GPIO_FN(QCPV_QDE),
-	GPIO_FN(CAN1_TX), GPIO_FN(SCL2_C), GPIO_FN(REMOCON),
-
-	/* IPSR4 */
-	GPIO_FN(QPOLA), GPIO_FN(CAN_CLK_C),
-	GPIO_FN(QPOLB), GPIO_FN(CAN1_RX),
-	GPIO_FN(DREQ0_B), GPIO_FN(SSI_SCK78_B),
-	GPIO_FN(VI2_DATA0_VI2_B0), GPIO_FN(PWM6),
-	GPIO_FN(AUDCK),
-	GPIO_FN(PWMFSW0_B), GPIO_FN(VI2_DATA1_VI2_B1),
-	GPIO_FN(PWM0),
-	GPIO_FN(AUDSYNC), GPIO_FN(VI2_G0),
-	GPIO_FN(VI2_G1), GPIO_FN(VI2_G2),
-	GPIO_FN(VI2_G3), GPIO_FN(VI2_G4),
-	GPIO_FN(VI2_G5),
-	GPIO_FN(VI2_DATA2_VI2_B2), GPIO_FN(SCL1_B),
-	GPIO_FN(AUDATA6),
-	GPIO_FN(VI2_DATA3_VI2_B3), GPIO_FN(SDA1_B),
-	GPIO_FN(AUDATA7),
-	GPIO_FN(VI2_G6), GPIO_FN(VI2_G7),
-	GPIO_FN(VI2_R0), GPIO_FN(VI2_R1),
-	GPIO_FN(VI2_R2), GPIO_FN(VI2_R3),
-	GPIO_FN(VI2_DATA4_VI2_B4), GPIO_FN(SCL2_B),
-
-	/* IPSR5 */
-	GPIO_FN(VI2_DATA5_VI2_B5), GPIO_FN(SDA2_B),
-	GPIO_FN(VI2_R4), GPIO_FN(VI2_R5),
-	GPIO_FN(VI2_R6), GPIO_FN(VI2_R7),
-	GPIO_FN(SCL2_D), GPIO_FN(SDA2_D),
-	GPIO_FN(VI2_CLKENB),
-	GPIO_FN(SCL1_D), GPIO_FN(VI2_FIELD),
-	GPIO_FN(SDA1_D), GPIO_FN(VI2_HSYNC),
-	GPIO_FN(VI3_HSYNC), GPIO_FN(VI2_VSYNC),
-	GPIO_FN(VI3_VSYNC),
-	GPIO_FN(VI2_CLK),
-	GPIO_FN(VI1_CLKENB), GPIO_FN(VI3_CLKENB),
-	GPIO_FN(AUDIO_CLKC), GPIO_FN(SPEEDIN),
-	GPIO_FN(GPS_SIGN_D), GPIO_FN(VI2_DATA6_VI2_B6),
-	GPIO_FN(TCLK0), GPIO_FN(QSTVA_B_QVS_B),
-	GPIO_FN(AUDIO_CLKOUT_B), GPIO_FN(GPS_MAG_D),
-	GPIO_FN(VI2_DATA7_VI2_B7),
-	GPIO_FN(VI1_FIELD),
-	GPIO_FN(VI3_FIELD), GPIO_FN(AUDIO_CLKOUT),
-	GPIO_FN(GPS_CLK_C), GPIO_FN(GPS_CLK_D), GPIO_FN(AUDIO_CLKA),
-	GPIO_FN(CAN_TXCLK), GPIO_FN(AUDIO_CLKB),
-	GPIO_FN(CAN_DEBUGOUT0), GPIO_FN(MOUT0),
-
-	/* IPSR6 */
-	GPIO_FN(SSI_SCK0129), GPIO_FN(CAN_DEBUGOUT1), GPIO_FN(MOUT1),
-	GPIO_FN(SSI_WS0129), GPIO_FN(CAN_DEBUGOUT2), GPIO_FN(MOUT2),
-	GPIO_FN(SSI_SDATA0), GPIO_FN(CAN_DEBUGOUT3), GPIO_FN(MOUT5),
-	GPIO_FN(SSI_SDATA1), GPIO_FN(CAN_DEBUGOUT4), GPIO_FN(MOUT6),
-	GPIO_FN(SSI_SDATA2), GPIO_FN(CAN_DEBUGOUT5), GPIO_FN(SSI_SCK34),
-	GPIO_FN(CAN_DEBUGOUT6), GPIO_FN(CAN0_TX_B), GPIO_FN(IERX),
-	GPIO_FN(SSI_SCK9_C), GPIO_FN(SSI_WS34), GPIO_FN(CAN_DEBUGOUT7),
-	GPIO_FN(CAN0_RX_B), GPIO_FN(IETX), GPIO_FN(SSI_WS9_C),
-	GPIO_FN(SSI_SDATA3), GPIO_FN(PWM0_C), GPIO_FN(CAN_DEBUGOUT8),
-	GPIO_FN(CAN_CLK_B), GPIO_FN(IECLK), GPIO_FN(SCIF_CLK_B),
-	GPIO_FN(TCLK0_B), GPIO_FN(SSI_SDATA4), GPIO_FN(CAN_DEBUGOUT9),
-	GPIO_FN(SSI_SDATA9_C), GPIO_FN(SSI_SCK5), GPIO_FN(ADICLK),
-	GPIO_FN(CAN_DEBUGOUT10), GPIO_FN(TCLK0_D),
-	GPIO_FN(SSI_WS5), GPIO_FN(ADICS_SAMP), GPIO_FN(CAN_DEBUGOUT11),
-	GPIO_FN(SSI_SDATA5), GPIO_FN(ADIDATA),
-	GPIO_FN(CAN_DEBUGOUT12), GPIO_FN(SSI_SCK6),
-	GPIO_FN(ADICHS0), GPIO_FN(CAN0_TX), GPIO_FN(IERX_B),
-
-	/* IPSR7 */
-	GPIO_FN(SSI_WS6), GPIO_FN(ADICHS1), GPIO_FN(CAN0_RX), GPIO_FN(IETX_B),
-	GPIO_FN(SSI_SDATA6), GPIO_FN(ADICHS2), GPIO_FN(CAN_CLK),
-	GPIO_FN(IECLK_B), GPIO_FN(SSI_SCK78), GPIO_FN(CAN_DEBUGOUT13),
-	GPIO_FN(SSI_SCK9_B),
-	GPIO_FN(SSI_WS78), GPIO_FN(CAN_DEBUGOUT14),
-	GPIO_FN(SSI_WS9_B), GPIO_FN(SSI_SDATA7),
-	GPIO_FN(CAN_DEBUGOUT15), GPIO_FN(TCLK1_C),
-	GPIO_FN(SSI_SDATA8), GPIO_FN(VSP),
-	GPIO_FN(ATACS01), GPIO_FN(ATACS11),
-	GPIO_FN(CC5_TDO), GPIO_FN(ATADIR1),
-	GPIO_FN(CC5_TRST), GPIO_FN(ATAG1),
-	GPIO_FN(CC5_TMS), GPIO_FN(ATARD1),
-	GPIO_FN(CC5_TCK), GPIO_FN(ATAWR1),
-	GPIO_FN(CC5_TDI), GPIO_FN(DREQ2),
-	GPIO_FN(DACK2),
-
-	/* IPSR8 */
-	GPIO_FN(AD_CLK),
-	GPIO_FN(CC5_STATE4), GPIO_FN(CC5_STATE12), GPIO_FN(CC5_STATE20),
-	GPIO_FN(CC5_STATE28), GPIO_FN(CC5_STATE36),
-	GPIO_FN(AD_DI),
-	GPIO_FN(CC5_STATE5), GPIO_FN(CC5_STATE13), GPIO_FN(CC5_STATE21),
-	GPIO_FN(CC5_STATE29), GPIO_FN(CC5_STATE37),
-	GPIO_FN(CAN_DEBUG_HW_TRIGGER), GPIO_FN(AD_DO),
-	GPIO_FN(CC5_STATE6), GPIO_FN(CC5_STATE14), GPIO_FN(CC5_STATE22),
-	GPIO_FN(CC5_STATE30), GPIO_FN(CC5_STATE38),
-	GPIO_FN(CAN_STEP0), GPIO_FN(AD_NCS), GPIO_FN(CC5_STATE7),
-	GPIO_FN(CC5_STATE15), GPIO_FN(CC5_STATE23), GPIO_FN(CC5_STATE31),
-	GPIO_FN(CC5_STATE39), GPIO_FN(FMCLK), GPIO_FN(RDS_CLK), GPIO_FN(PCMOE),
-	GPIO_FN(BPFCLK), GPIO_FN(PCMWE), GPIO_FN(FMIN), GPIO_FN(RDS_DATA),
-	GPIO_FN(VI0_CLK), GPIO_FN(VI0_CLKENB),
-	GPIO_FN(HTX1_B), GPIO_FN(MT1_SYNC),
-	GPIO_FN(VI0_FIELD), GPIO_FN(HRX1_B),
-	GPIO_FN(VI0_HSYNC), GPIO_FN(VI0_DATA0_B_VI0_B0_B),
-	GPIO_FN(HSCK1_B),
-	GPIO_FN(VI0_VSYNC), GPIO_FN(VI0_DATA1_B_VI0_B1_B),
-	GPIO_FN(PWMFSW0_C),
-
-	/* IPSR9 */
-	GPIO_FN(VI0_DATA0_VI0_B0), GPIO_FN(HRTS1_B), GPIO_FN(MT1_VCXO),
-	GPIO_FN(VI0_DATA1_VI0_B1), GPIO_FN(HCTS1_B), GPIO_FN(MT1_PWM),
-	GPIO_FN(VI0_DATA2_VI0_B2), GPIO_FN(VI0_DATA3_VI0_B3),
-	GPIO_FN(VI0_DATA4_VI0_B4),
-	GPIO_FN(VI0_DATA5_VI0_B5), GPIO_FN(VI0_DATA6_VI0_B6),
-	GPIO_FN(ARM_TRACEDATA_0), GPIO_FN(VI0_DATA7_VI0_B7),
-	GPIO_FN(ARM_TRACEDATA_1), GPIO_FN(VI0_G0),
-	GPIO_FN(SSI_SCK78_C), GPIO_FN(ARM_TRACEDATA_2),
-	GPIO_FN(VI0_G1), GPIO_FN(SSI_WS78_C),
-	GPIO_FN(ARM_TRACEDATA_3), GPIO_FN(VI0_G2), GPIO_FN(ETH_TXD1),
-	GPIO_FN(ARM_TRACEDATA_4), GPIO_FN(TS_SPSYNC0),
-	GPIO_FN(VI0_G3), GPIO_FN(ETH_CRS_DV),
-	GPIO_FN(ARM_TRACEDATA_5), GPIO_FN(TS_SDAT0), GPIO_FN(VI0_G4),
-	GPIO_FN(ETH_TX_EN), GPIO_FN(ARM_TRACEDATA_6),
-	GPIO_FN(VI0_G5), GPIO_FN(ETH_RX_ER),
-	GPIO_FN(ARM_TRACEDATA_7), GPIO_FN(VI0_G6), GPIO_FN(ETH_RXD0),
-	GPIO_FN(ARM_TRACEDATA_8), GPIO_FN(VI0_G7),
-	GPIO_FN(ETH_RXD1), GPIO_FN(ARM_TRACEDATA_9),
-
-	/* IPSR10 */
-	GPIO_FN(VI0_R0), GPIO_FN(SSI_SDATA7_C),
-	GPIO_FN(DREQ1_B), GPIO_FN(ARM_TRACEDATA_10), GPIO_FN(DREQ0_C),
-	GPIO_FN(VI0_R1), GPIO_FN(SSI_SDATA8_C), GPIO_FN(DACK1_B),
-	GPIO_FN(ARM_TRACEDATA_11), GPIO_FN(DACK0_C), GPIO_FN(DRACK0_C),
-	GPIO_FN(VI0_R2), GPIO_FN(ETH_LINK),
-	GPIO_FN(ARM_TRACEDATA_12), GPIO_FN(VI0_R3), GPIO_FN(ETH_MAGIC),
-	GPIO_FN(ARM_TRACEDATA_13),
-	GPIO_FN(VI0_R4), GPIO_FN(ETH_REFCLK),
-	GPIO_FN(ARM_TRACEDATA_14), GPIO_FN(MT1_CLK),
-	GPIO_FN(TS_SCK0), GPIO_FN(VI0_R5), GPIO_FN(ETH_TXD0),
-	GPIO_FN(ARM_TRACEDATA_15),
-	GPIO_FN(MT1_D), GPIO_FN(TS_SDEN0), GPIO_FN(VI0_R6), GPIO_FN(ETH_MDC),
-	GPIO_FN(DREQ2_C), GPIO_FN(TRACECLK),
-	GPIO_FN(MT1_BEN), GPIO_FN(PWMFSW0_D), GPIO_FN(VI0_R7),
-	GPIO_FN(ETH_MDIO), GPIO_FN(DACK2_C),
-	GPIO_FN(SCIF_CLK_D), GPIO_FN(TRACECTL), GPIO_FN(MT1_PEN),
-	GPIO_FN(VI1_CLK), GPIO_FN(SIM_D), GPIO_FN(SDA3), GPIO_FN(VI1_HSYNC),
-	GPIO_FN(VI3_CLK), GPIO_FN(SSI_SCK4), GPIO_FN(GPS_SIGN_C),
-	GPIO_FN(PWMFSW0_E), GPIO_FN(VI1_VSYNC), GPIO_FN(AUDIO_CLKOUT_C),
-	GPIO_FN(SSI_WS4), GPIO_FN(SIM_CLK), GPIO_FN(GPS_MAG_C),
-	GPIO_FN(SPV_TRST), GPIO_FN(SCL3),
-
-	/* IPSR11 */
-	GPIO_FN(VI1_DATA0_VI1_B0), GPIO_FN(SIM_RST),
-	GPIO_FN(SPV_TCK), GPIO_FN(ADICLK_B), GPIO_FN(VI1_DATA1_VI1_B1),
-	GPIO_FN(MT0_CLK), GPIO_FN(SPV_TMS),
-	GPIO_FN(ADICS_B_SAMP_B), GPIO_FN(VI1_DATA2_VI1_B2),
-	GPIO_FN(MT0_D), GPIO_FN(SPVTDI), GPIO_FN(ADIDATA_B),
-	GPIO_FN(VI1_DATA3_VI1_B3), GPIO_FN(MT0_BEN),
-	GPIO_FN(SPV_TDO), GPIO_FN(ADICHS0_B), GPIO_FN(VI1_DATA4_VI1_B4),
-	GPIO_FN(MT0_PEN), GPIO_FN(SPA_TRST),
-	GPIO_FN(ADICHS1_B), GPIO_FN(VI1_DATA5_VI1_B5),
-	GPIO_FN(MT0_SYNC), GPIO_FN(SPA_TCK),
-	GPIO_FN(ADICHS2_B), GPIO_FN(VI1_DATA6_VI1_B6),
-	GPIO_FN(MT0_VCXO), GPIO_FN(SPA_TMS),
-	GPIO_FN(VI1_DATA7_VI1_B7),
-	GPIO_FN(MT0_PWM), GPIO_FN(SPA_TDI),
-	GPIO_FN(VI1_G0), GPIO_FN(VI3_DATA0),
-	GPIO_FN(TS_SCK1), GPIO_FN(DREQ2_B), GPIO_FN(SPA_TDO),
-	GPIO_FN(HCTS0_B), GPIO_FN(VI1_G1), GPIO_FN(VI3_DATA1),
-	GPIO_FN(SSI_SCK1), GPIO_FN(TS_SDEN1), GPIO_FN(DACK2_B),
-	GPIO_FN(HRTS0_B),
-
-	/* IPSR12 */
-	GPIO_FN(VI1_G2), GPIO_FN(VI3_DATA2), GPIO_FN(SSI_WS1),
-	GPIO_FN(TS_SPSYNC1), GPIO_FN(HSCK0_B), GPIO_FN(VI1_G3),
-	GPIO_FN(VI3_DATA3), GPIO_FN(SSI_SCK2), GPIO_FN(TS_SDAT1),
-	GPIO_FN(SCL1_C), GPIO_FN(HTX0_B), GPIO_FN(VI1_G4), GPIO_FN(VI3_DATA4),
-	GPIO_FN(SSI_WS2), GPIO_FN(SDA1_C), GPIO_FN(SIM_RST_B),
-	GPIO_FN(HRX0_B), GPIO_FN(VI1_G5), GPIO_FN(VI3_DATA5),
-	GPIO_FN(GPS_CLK), GPIO_FN(FSE), GPIO_FN(SIM_D_B),
-	GPIO_FN(VI1_G6), GPIO_FN(VI3_DATA6), GPIO_FN(GPS_SIGN), GPIO_FN(FRB),
-	GPIO_FN(SIM_CLK_B), GPIO_FN(VI1_G7),
-	GPIO_FN(VI3_DATA7), GPIO_FN(GPS_MAG), GPIO_FN(FCE),
-};
-
 static const struct pinmux_cfg_reg pinmux_config_regs[] = {
 	{ PINMUX_CFG_REG("GPSR0", 0xfffc0004, 32, 1) {
 		GP_0_31_FN, FN_IP3_31_29,
@@ -3831,9 +3563,6 @@ const struct sh_pfc_soc_info r8a7779_pinmux_info = {
 	.functions = pinmux_functions,
 	.nr_functions = ARRAY_SIZE(pinmux_functions),
 
-	.func_gpios = pinmux_func_gpios,
-	.nr_func_gpios = ARRAY_SIZE(pinmux_func_gpios),
-
 	.cfg_regs = pinmux_config_regs,
 	.data_regs = pinmux_data_regs,
 
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 01:09:20 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue,  2 Apr 2013 14:09:20 +0900
Subject: [PATCH 12/28] sh-pfc: Configure pins as GPIOs at request time when
 handled externally
In-Reply-To: <1364879376-10020-1-git-send-email-horms+renesas@verge.net.au>
References: <1364879376-10020-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364879376-10020-13-git-send-email-horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

When a GPIO is handled by a separate driver the pinmux
gpio_set_direction() handler won't be called. The pin mux type then need
to be configured to GPIO at request time.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 drivers/pinctrl/sh-pfc/core.c    |   37 ++++++++++++++++---------------------
 drivers/pinctrl/sh-pfc/pinctrl.c |   11 +++++++++++
 2 files changed, 27 insertions(+), 21 deletions(-)

diff --git a/drivers/pinctrl/sh-pfc/core.c b/drivers/pinctrl/sh-pfc/core.c
index 97e6ea3..ced9a95 100644
--- a/drivers/pinctrl/sh-pfc/core.c
+++ b/drivers/pinctrl/sh-pfc/core.c
@@ -268,7 +268,7 @@ int sh_pfc_config_mux(struct sh_pfc *pfc, unsigned mark, int pinmux_type)
 	int ret;
 
 	switch (pinmux_type) {
-
+	case PINMUX_TYPE_GPIO:
 	case PINMUX_TYPE_FUNCTION:
 		range = NULL;
 		break;
@@ -297,6 +297,8 @@ int sh_pfc_config_mux(struct sh_pfc *pfc, unsigned mark, int pinmux_type)
 	enum_id = 0;
 	field = 0;
 	value = 0;
+
+	/* Iterate over all the configuration fields we need to update. */
 	while (1) {
 		pos = sh_pfc_mark_to_enum(pfc, mark, pos, &enum_id);
 		if (pos < 0)
@@ -305,18 +307,20 @@ int sh_pfc_config_mux(struct sh_pfc *pfc, unsigned mark, int pinmux_type)
 		if (!enum_id)
 			break;
 
-		/* first check if this is a function enum */
+		/* Check if the configuration field selects a function. If it
+		 * doesn't, skip the field if it's not applicable to the
+		 * requested pinmux type.
+		 */
 		in_range = sh_pfc_enum_in_range(enum_id, &pfc->info->function);
 		if (!in_range) {
-			/* not a function enum */
-			if (range) {
-				/*
-				 * other range exists, so this pin is
-				 * a regular GPIO pin that now is being
-				 * bound to a specific direction.
-				 *
-				 * for this case we only allow function enums
-				 * and the enums that match the other range.
+			if (pinmux_type == PINMUX_TYPE_FUNCTION) {
+				/* Functions are allowed to modify all
+				 * fields.
+				 */
+				in_range = 1;
+			} else if (pinmux_type != PINMUX_TYPE_GPIO) {
+				/* Input/output types can only modify fields
+				 * that correspond to their respective ranges.
 				 */
 				in_range = sh_pfc_enum_in_range(enum_id, range);
 
@@ -327,17 +331,8 @@ int sh_pfc_config_mux(struct sh_pfc *pfc, unsigned mark, int pinmux_type)
 				 */
 				if (in_range && enum_id == range->force)
 					continue;
-			} else {
-				/*
-				 * no other range exists, so this pin
-				 * must then be of the function type.
-				 *
-				 * allow function type pins to select
-				 * any combination of function/in/out
-				 * in their MARK lists.
-				 */
-				in_range = 1;
 			}
+			/* GPIOs are only allowed to modify function fields. */
 		}
 
 		if (!in_range)
diff --git a/drivers/pinctrl/sh-pfc/pinctrl.c b/drivers/pinctrl/sh-pfc/pinctrl.c
index aef268b..3492ec9 100644
--- a/drivers/pinctrl/sh-pfc/pinctrl.c
+++ b/drivers/pinctrl/sh-pfc/pinctrl.c
@@ -182,6 +182,17 @@ static int sh_pfc_gpio_request_enable(struct pinctrl_dev *pctldev,
 		goto done;
 	}
 
+	if (!pfc->gpio) {
+		/* If GPIOs are handled externally the pin mux type need to be
+		 * set to GPIO here.
+		 */
+		const struct sh_pfc_pin *pin = &pfc->info->pins[idx];
+
+		ret = sh_pfc_config_mux(pfc, pin->enum_id, PINMUX_TYPE_GPIO);
+		if (ret < 0)
+			goto done;
+	}
+
 	cfg->type = PINMUX_TYPE_GPIO;
 
 	ret = 0;
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 01:09:19 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue,  2 Apr 2013 14:09:19 +0900
Subject: [PATCH 11/28] sh-pfc: Skip gpiochip registration when no GPIO
 resource is found
In-Reply-To: <1364879376-10020-1-git-send-email-horms+renesas@verge.net.au>
References: <1364879376-10020-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364879376-10020-12-git-send-email-horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

Boards/platforms that register dedicated GPIO devices will not supply a
memory resource for GPIOs. Try to locate the GPIO memory resource at
initialization time, and skip registration of the gpiochip if the
resource can't be found.

This is a temporary modification to ease the transition to separate GPIO
drivers. It should be reverted when all boards and platforms will have
been moved.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Acked-by: Linus Walleij <linus.walleij at linaro.org>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 drivers/pinctrl/sh-pfc/gpio.c |   39 +++++++++++++++++++++------------------
 1 file changed, 21 insertions(+), 18 deletions(-)

diff --git a/drivers/pinctrl/sh-pfc/gpio.c b/drivers/pinctrl/sh-pfc/gpio.c
index 317cebb..d37efa7 100644
--- a/drivers/pinctrl/sh-pfc/gpio.c
+++ b/drivers/pinctrl/sh-pfc/gpio.c
@@ -101,24 +101,9 @@ static void gpio_setup_data_reg(struct sh_pfc_chip *chip, unsigned gpio)
 static int gpio_setup_data_regs(struct sh_pfc_chip *chip)
 {
 	struct sh_pfc *pfc = chip->pfc;
-	unsigned long addr = pfc->info->data_regs[0].reg;
 	const struct pinmux_data_reg *dreg;
 	unsigned int i;
 
-	/* Find the window that contain the GPIO registers. */
-	for (i = 0; i < pfc->num_windows; ++i) {
-		struct sh_pfc_window *window = &pfc->window[i];
-
-		if (addr >= window->phys && addr < window->phys + window->size)
-			break;
-	}
-
-	if (i == pfc->num_windows)
-		return -EINVAL;
-
-	/* GPIO data registers must be in the first memory resource. */
-	chip->mem = &pfc->window[i];
-
 	/* Count the number of data registers, allocate memory and initialize
 	 * them.
 	 */
@@ -319,7 +304,8 @@ static int gpio_function_setup(struct sh_pfc_chip *chip)
  */
 
 static struct sh_pfc_chip *
-sh_pfc_add_gpiochip(struct sh_pfc *pfc, int(*setup)(struct sh_pfc_chip *))
+sh_pfc_add_gpiochip(struct sh_pfc *pfc, int(*setup)(struct sh_pfc_chip *),
+		    struct sh_pfc_window *mem)
 {
 	struct sh_pfc_chip *chip;
 	int ret;
@@ -328,6 +314,7 @@ sh_pfc_add_gpiochip(struct sh_pfc *pfc, int(*setup)(struct sh_pfc_chip *))
 	if (unlikely(!chip))
 		return ERR_PTR(-ENOMEM);
 
+	chip->mem = mem;
 	chip->pfc = pfc;
 
 	ret = setup(chip);
@@ -357,8 +344,24 @@ int sh_pfc_register_gpiochip(struct sh_pfc *pfc)
 	if (pfc->info->data_regs == NULL)
 		return 0;
 
+	/* Find the memory window that contain the GPIO registers. Boards that
+	 * register a separate GPIO device will not supply a memory resource
+	 * that covers the data registers. In that case don't try to handle
+	 * GPIOs.
+	 */
+	for (i = 0; i < pfc->num_windows; ++i) {
+		struct sh_pfc_window *window = &pfc->window[i];
+
+		if (pfc->info->data_regs[0].reg >= window->phys &&
+		    pfc->info->data_regs[0].reg < window->phys + window->size)
+			break;
+	}
+
+	if (i == pfc->num_windows)
+		return 0;
+
 	/* Register the real GPIOs chip. */
-	chip = sh_pfc_add_gpiochip(pfc, gpio_pin_setup);
+	chip = sh_pfc_add_gpiochip(pfc, gpio_pin_setup, &pfc->window[i]);
 	if (IS_ERR(chip))
 		return PTR_ERR(chip);
 
@@ -390,7 +393,7 @@ int sh_pfc_register_gpiochip(struct sh_pfc *pfc)
 	if (pfc->info->nr_func_gpios == 0)
 		return 0;
 
-	chip = sh_pfc_add_gpiochip(pfc, gpio_function_setup);
+	chip = sh_pfc_add_gpiochip(pfc, gpio_function_setup, NULL);
 	if (IS_ERR(chip))
 		return PTR_ERR(chip);
 
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 01:09:25 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue,  2 Apr 2013 14:09:25 +0900
Subject: [PATCH 17/28] sh-pfc: r8a73a4: Support sparse GPIO numbers
In-Reply-To: <1364879376-10020-1-git-send-email-horms+renesas@verge.net.au>
References: <1364879376-10020-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364879376-10020-18-git-send-email-horms+renesas@verge.net.au>

From: Magnus Damm <damm at opensource.se>

The r8a73a4 SoC has sparse GPIO numbers. Declare ranges for pin numbers
in the PFC SoC data. Pin numbers shall be used with the GPIO API from
this point on.

Signed-off-by: Magnus Damm <damm at opensource.se>
Acked-by: Linus Walleij <linus.walleij at linaro.org>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/include/mach/r8a73a4.h |    2 +-
 drivers/pinctrl/sh-pfc/pfc-r8a73a4.c          |   16 ++++++++++++++++
 2 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-shmobile/include/mach/r8a73a4.h b/arch/arm/mach-shmobile/include/mach/r8a73a4.h
index f0b1b4a..2d4af4a 100644
--- a/arch/arm/mach-shmobile/include/mach/r8a73a4.h
+++ b/arch/arm/mach-shmobile/include/mach/r8a73a4.h
@@ -86,7 +86,7 @@ enum {
 	GPIO_PORT325, GPIO_PORT326, GPIO_PORT327, GPIO_PORT328, GPIO_PORT329,
 
 	/* Port0 */
-	GPIO_FN_LCDD0,
+	GPIO_FN_LCDD0 = 330,
 	GPIO_FN_PDM2_CLK_0,
 	GPIO_FN_DU0_DR0,
 	GPIO_FN_IRQ0,
diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a73a4.c b/drivers/pinctrl/sh-pfc/pfc-r8a73a4.c
index 47d75d5..5dd68fb9 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a73a4.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a73a4.c
@@ -1424,6 +1424,20 @@ static struct sh_pfc_pin pinmux_pins[] = {
 	GPIO_PORT_ALL(),
 };
 
+static const struct pinmux_range pinmux_ranges[] = {
+	{.begin = 0, .end = 30,},
+	{.begin = 32, .end = 40,},
+	{.begin = 64, .end = 85,},
+	{.begin = 96, .end = 126,},
+	{.begin = 128, .end = 134,},
+	{.begin = 160, .end = 178,},
+	{.begin = 192, .end = 222,},
+	{.begin = 224, .end = 250,},
+	{.begin = 256, .end = 283,},
+	{.begin = 288, .end = 308,},
+	{.begin = 320, .end = 329,},
+};
+
 #define PINMUX_FN_BASE	ARRAY_SIZE(pinmux_pins)
 
 static const struct pinmux_func pinmux_func_gpios[] = {
@@ -2815,6 +2829,8 @@ const struct sh_pfc_soc_info r8a73a4_pinmux_info = {
 
 	.pins = pinmux_pins,
 	.nr_pins = ARRAY_SIZE(pinmux_pins),
+	.ranges = pinmux_ranges,
+	.nr_ranges = ARRAY_SIZE(pinmux_ranges),
 	.func_gpios = pinmux_func_gpios,
 	.nr_func_gpios = ARRAY_SIZE(pinmux_func_gpios),
 
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 01:09:21 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue,  2 Apr 2013 14:09:21 +0900
Subject: [PATCH 13/28] ARM: shmobile: r8a7779: Register GPIO devices
In-Reply-To: <1364879376-10020-1-git-send-email-horms+renesas@verge.net.au>
References: <1364879376-10020-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364879376-10020-14-git-send-email-horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

Move GPIOs handling from the PFC device to separate GPIO devices.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/setup-r8a7779.c |   58 ++++++++++++++++++++++++++++----
 1 file changed, 52 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-shmobile/setup-r8a7779.c b/arch/arm/mach-shmobile/setup-r8a7779.c
index 042df35..a460ba3 100644
--- a/arch/arm/mach-shmobile/setup-r8a7779.c
+++ b/arch/arm/mach-shmobile/setup-r8a7779.c
@@ -22,6 +22,7 @@
 #include <linux/interrupt.h>
 #include <linux/irq.h>
 #include <linux/of_platform.h>
+#include <linux/platform_data/gpio-rcar.h>
 #include <linux/platform_device.h>
 #include <linux/delay.h>
 #include <linux/input.h>
@@ -68,11 +69,6 @@ static struct resource r8a7779_pfc_resources[] = {
 		.end	= 0xfffc023b,
 		.flags	= IORESOURCE_MEM,
 	},
-	[1] = {
-		.start	= 0xffc40000,
-		.end	= 0xffc46fff,
-		.flags	= IORESOURCE_MEM,
-	}
 };
 
 static struct platform_device r8a7779_pfc_device = {
@@ -82,9 +78,59 @@ static struct platform_device r8a7779_pfc_device = {
 	.num_resources	= ARRAY_SIZE(r8a7779_pfc_resources),
 };
 
+#define R8A7779_GPIO(idx, npins) \
+static struct resource r8a7779_gpio##idx##_resources[] = {		\
+	[0] = {								\
+		.start	= 0xffc40000 + 0x1000 * (idx),			\
+		.end	= 0xffc4002b + 0x1000 * (idx),			\
+		.flags	= IORESOURCE_MEM,				\
+	},								\
+	[1] = {								\
+		.start	= gic_iid(0xad + (idx)),			\
+		.flags	= IORESOURCE_IRQ,				\
+	}								\
+};									\
+									\
+static struct gpio_rcar_config r8a7779_gpio##idx##_platform_data = {	\
+	.gpio_base	= 32 * (idx),					\
+	.irq_base	= 0,						\
+	.number_of_pins	= npins,					\
+	.pctl_name	= "pfc-r8a7779",				\
+};									\
+									\
+static struct platform_device r8a7779_gpio##idx##_device = {		\
+	.name		= "gpio_rcar",					\
+	.id		= idx,						\
+	.resource	= r8a7779_gpio##idx##_resources,		\
+	.num_resources	= ARRAY_SIZE(r8a7779_gpio##idx##_resources),	\
+	.dev		= {						\
+		.platform_data	= &r8a7779_gpio##idx##_platform_data,	\
+	},								\
+}
+
+R8A7779_GPIO(0, 32);
+R8A7779_GPIO(1, 32);
+R8A7779_GPIO(2, 32);
+R8A7779_GPIO(3, 32);
+R8A7779_GPIO(4, 32);
+R8A7779_GPIO(5, 32);
+R8A7779_GPIO(6, 9);
+
+static struct platform_device *r8a7779_pinctrl_devices[] __initdata = {
+	&r8a7779_pfc_device,
+	&r8a7779_gpio0_device,
+	&r8a7779_gpio1_device,
+	&r8a7779_gpio2_device,
+	&r8a7779_gpio3_device,
+	&r8a7779_gpio4_device,
+	&r8a7779_gpio5_device,
+	&r8a7779_gpio6_device,
+};
+
 void __init r8a7779_pinmux_init(void)
 {
-	platform_device_register(&r8a7779_pfc_device);
+	platform_add_devices(r8a7779_pinctrl_devices,
+			    ARRAY_SIZE(r8a7779_pinctrl_devices));
 }
 
 static struct plat_sci_port scif0_platform_data = {
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 01:09:14 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue,  2 Apr 2013 14:09:14 +0900
Subject: [PATCH 06/28] gpio: Renesas R-Car GPIO driver V3
In-Reply-To: <1364879376-10020-1-git-send-email-horms+renesas@verge.net.au>
References: <1364879376-10020-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364879376-10020-7-git-send-email-horms+renesas@verge.net.au>

From: Magnus Damm <damm at opensource.se>

This patch is V3 of a GPIO driver for the R-Car series of
SoCs from Renesas. This driver is designed to be reusable
between multiple SoCs that share the same basic building block,
but so far it has only been used on R-Car H1 (r8a7779).

Each driver instance handles 32 GPIOs with individually
maskable IRQs. The driver operates on a single I/O memory
range and the 32 GPIOs are hooked up a single interrupt.

In the case of R-Car H1 either external IRQ pins or GPIOs
with interrupts can be used for on-board interupts. For
external IRQs 4 pins are supported, and in the case of GPIO
there are 202 GPIOS as 202 interrupts hooked up via 6 driver
instances and to the GIC and the Cortex-A9 Quad.

At this point this driver is interfacing as a regular
platform device driver. In the future DT support will be
submitted as an incremental feature patch.

Signed-off-by: Magnus Damm <damm at opensource.se>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 drivers/gpio/Kconfig                    |    6 +
 drivers/gpio/Makefile                   |    1 +
 drivers/gpio/gpio-rcar.c                |  373 +++++++++++++++++++++++++++++++
 include/linux/platform_data/gpio-rcar.h |   25 +++
 4 files changed, 405 insertions(+)
 create mode 100644 drivers/gpio/gpio-rcar.c
 create mode 100644 include/linux/platform_data/gpio-rcar.h

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 93aaadf..d766e3c 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -204,6 +204,12 @@ config GPIO_PXA
 	help
 	  Say yes here to support the PXA GPIO device
 
+config GPIO_RCAR
+	tristate "Renesas R-Car GPIO"
+	depends on ARM
+	help
+	  Say yes here to support GPIO on Renesas R-Car SoCs.
+
 config GPIO_SPEAR_SPICS
 	bool "ST SPEAr13xx SPI Chip Select as GPIO support"
 	depends on PLAT_SPEAR
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 22e07bc..b41c74d 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -57,6 +57,7 @@ obj-$(CONFIG_GPIO_PL061)	+= gpio-pl061.o
 obj-$(CONFIG_GPIO_PXA)		+= gpio-pxa.o
 obj-$(CONFIG_GPIO_RC5T583)	+= gpio-rc5t583.o
 obj-$(CONFIG_GPIO_RDC321X)	+= gpio-rdc321x.o
+obj-$(CONFIG_GPIO_RCAR)		+= gpio-rcar.o
 obj-$(CONFIG_PLAT_SAMSUNG)	+= gpio-samsung.o
 obj-$(CONFIG_ARCH_SA1100)	+= gpio-sa1100.o
 obj-$(CONFIG_GPIO_SCH)		+= gpio-sch.o
diff --git a/drivers/gpio/gpio-rcar.c b/drivers/gpio/gpio-rcar.c
new file mode 100644
index 0000000..581ba56
--- /dev/null
+++ b/drivers/gpio/gpio-rcar.c
@@ -0,0 +1,373 @@
+/*
+ * Renesas R-Car GPIO Support
+ *
+ *  Copyright (C) 2013 Magnus Damm
+ *
+ * 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
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/err.h>
+#include <linux/gpio.h>
+#include <linux/init.h>
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/ioport.h>
+#include <linux/irq.h>
+#include <linux/irqdomain.h>
+#include <linux/module.h>
+#include <linux/platform_data/gpio-rcar.h>
+#include <linux/platform_device.h>
+#include <linux/spinlock.h>
+#include <linux/slab.h>
+
+struct gpio_rcar_priv {
+	void __iomem *base;
+	spinlock_t lock;
+	struct gpio_rcar_config config;
+	struct platform_device *pdev;
+	struct gpio_chip gpio_chip;
+	struct irq_chip irq_chip;
+	struct irq_domain *irq_domain;
+};
+
+#define IOINTSEL 0x00
+#define INOUTSEL 0x04
+#define OUTDT 0x08
+#define INDT 0x0c
+#define INTDT 0x10
+#define INTCLR 0x14
+#define INTMSK 0x18
+#define MSKCLR 0x1c
+#define POSNEG 0x20
+#define EDGLEVEL 0x24
+#define FILONOFF 0x28
+
+static inline u32 gpio_rcar_read(struct gpio_rcar_priv *p, int offs)
+{
+	return ioread32(p->base + offs);
+}
+
+static inline void gpio_rcar_write(struct gpio_rcar_priv *p, int offs,
+				   u32 value)
+{
+	iowrite32(value, p->base + offs);
+}
+
+static void gpio_rcar_modify_bit(struct gpio_rcar_priv *p, int offs,
+				 int bit, bool value)
+{
+	u32 tmp = gpio_rcar_read(p, offs);
+
+	if (value)
+		tmp |= BIT(bit);
+	else
+		tmp &= ~BIT(bit);
+
+	gpio_rcar_write(p, offs, tmp);
+}
+
+static void gpio_rcar_irq_disable(struct irq_data *d)
+{
+	struct gpio_rcar_priv *p = irq_data_get_irq_chip_data(d);
+
+	gpio_rcar_write(p, INTMSK, ~BIT(irqd_to_hwirq(d)));
+}
+
+static void gpio_rcar_irq_enable(struct irq_data *d)
+{
+	struct gpio_rcar_priv *p = irq_data_get_irq_chip_data(d);
+
+	gpio_rcar_write(p, MSKCLR, BIT(irqd_to_hwirq(d)));
+}
+
+static void gpio_rcar_config_interrupt_input_mode(struct gpio_rcar_priv *p,
+						  unsigned int hwirq,
+						  bool active_high_rising_edge,
+						  bool level_trigger)
+{
+	unsigned long flags;
+
+	/* follow steps in the GPIO documentation for
+	 * "Setting Edge-Sensitive Interrupt Input Mode" and
+	 * "Setting Level-Sensitive Interrupt Input Mode"
+	 */
+
+	spin_lock_irqsave(&p->lock, flags);
+
+	/* Configure postive or negative logic in POSNEG */
+	gpio_rcar_modify_bit(p, POSNEG, hwirq, !active_high_rising_edge);
+
+	/* Configure edge or level trigger in EDGLEVEL */
+	gpio_rcar_modify_bit(p, EDGLEVEL, hwirq, !level_trigger);
+
+	/* Select "Interrupt Input Mode" in IOINTSEL */
+	gpio_rcar_modify_bit(p, IOINTSEL, hwirq, true);
+
+	/* Write INTCLR in case of edge trigger */
+	if (!level_trigger)
+		gpio_rcar_write(p, INTCLR, BIT(hwirq));
+
+	spin_unlock_irqrestore(&p->lock, flags);
+}
+
+static int gpio_rcar_irq_set_type(struct irq_data *d, unsigned int type)
+{
+	struct gpio_rcar_priv *p = irq_data_get_irq_chip_data(d);
+	unsigned int hwirq = irqd_to_hwirq(d);
+
+	dev_dbg(&p->pdev->dev, "sense irq = %d, type = %d\n", hwirq, type);
+
+	switch (type & IRQ_TYPE_SENSE_MASK) {
+	case IRQ_TYPE_LEVEL_HIGH:
+		gpio_rcar_config_interrupt_input_mode(p, hwirq, true, true);
+		break;
+	case IRQ_TYPE_LEVEL_LOW:
+		gpio_rcar_config_interrupt_input_mode(p, hwirq, false, true);
+		break;
+	case IRQ_TYPE_EDGE_RISING:
+		gpio_rcar_config_interrupt_input_mode(p, hwirq, true, false);
+		break;
+	case IRQ_TYPE_EDGE_FALLING:
+		gpio_rcar_config_interrupt_input_mode(p, hwirq, false, false);
+		break;
+	default:
+		return -EINVAL;
+	}
+	return 0;
+}
+
+static irqreturn_t gpio_rcar_irq_handler(int irq, void *dev_id)
+{
+	struct gpio_rcar_priv *p = dev_id;
+	u32 pending;
+	unsigned int offset, irqs_handled = 0;
+
+	while ((pending = gpio_rcar_read(p, INTDT))) {
+		offset = __ffs(pending);
+		gpio_rcar_write(p, INTCLR, BIT(offset));
+		generic_handle_irq(irq_find_mapping(p->irq_domain, offset));
+		irqs_handled++;
+	}
+
+	return irqs_handled ? IRQ_HANDLED : IRQ_NONE;
+}
+
+static inline struct gpio_rcar_priv *gpio_to_priv(struct gpio_chip *chip)
+{
+	return container_of(chip, struct gpio_rcar_priv, gpio_chip);
+}
+
+static void gpio_rcar_config_general_input_output_mode(struct gpio_chip *chip,
+						       unsigned int gpio,
+						       bool output)
+{
+	struct gpio_rcar_priv *p = gpio_to_priv(chip);
+	unsigned long flags;
+
+	/* follow steps in the GPIO documentation for
+	 * "Setting General Output Mode" and
+	 * "Setting General Input Mode"
+	 */
+
+	spin_lock_irqsave(&p->lock, flags);
+
+	/* Configure postive logic in POSNEG */
+	gpio_rcar_modify_bit(p, POSNEG, gpio, false);
+
+	/* Select "General Input/Output Mode" in IOINTSEL */
+	gpio_rcar_modify_bit(p, IOINTSEL, gpio, false);
+
+	/* Select Input Mode or Output Mode in INOUTSEL */
+	gpio_rcar_modify_bit(p, INOUTSEL, gpio, output);
+
+	spin_unlock_irqrestore(&p->lock, flags);
+}
+
+static int gpio_rcar_direction_input(struct gpio_chip *chip, unsigned offset)
+{
+	gpio_rcar_config_general_input_output_mode(chip, offset, false);
+	return 0;
+}
+
+static int gpio_rcar_get(struct gpio_chip *chip, unsigned offset)
+{
+	return (int)(gpio_rcar_read(gpio_to_priv(chip), INDT) & BIT(offset));
+}
+
+static void gpio_rcar_set(struct gpio_chip *chip, unsigned offset, int value)
+{
+	struct gpio_rcar_priv *p = gpio_to_priv(chip);
+	unsigned long flags;
+
+	spin_lock_irqsave(&p->lock, flags);
+	gpio_rcar_modify_bit(p, OUTDT, offset, value);
+	spin_unlock_irqrestore(&p->lock, flags);
+}
+
+static int gpio_rcar_direction_output(struct gpio_chip *chip, unsigned offset,
+				      int value)
+{
+	/* write GPIO value to output before selecting output mode of pin */
+	gpio_rcar_set(chip, offset, value);
+	gpio_rcar_config_general_input_output_mode(chip, offset, true);
+	return 0;
+}
+
+static int gpio_rcar_to_irq(struct gpio_chip *chip, unsigned offset)
+{
+	return irq_create_mapping(gpio_to_priv(chip)->irq_domain, offset);
+}
+
+static int gpio_rcar_irq_domain_map(struct irq_domain *h, unsigned int virq,
+				 irq_hw_number_t hw)
+{
+	struct gpio_rcar_priv *p = h->host_data;
+
+	dev_dbg(&p->pdev->dev, "map hw irq = %d, virq = %d\n", (int)hw, virq);
+
+	irq_set_chip_data(virq, h->host_data);
+	irq_set_chip_and_handler(virq, &p->irq_chip, handle_level_irq);
+	set_irq_flags(virq, IRQF_VALID); /* kill me now */
+	return 0;
+}
+
+static struct irq_domain_ops gpio_rcar_irq_domain_ops = {
+	.map	= gpio_rcar_irq_domain_map,
+};
+
+static int gpio_rcar_probe(struct platform_device *pdev)
+{
+	struct gpio_rcar_config *pdata = pdev->dev.platform_data;
+	struct gpio_rcar_priv *p;
+	struct resource *io, *irq;
+	struct gpio_chip *gpio_chip;
+	struct irq_chip *irq_chip;
+	const char *name = dev_name(&pdev->dev);
+	int ret;
+
+	p = devm_kzalloc(&pdev->dev, sizeof(*p), GFP_KERNEL);
+	if (!p) {
+		dev_err(&pdev->dev, "failed to allocate driver data\n");
+		ret = -ENOMEM;
+		goto err0;
+	}
+
+	/* deal with driver instance configuration */
+	if (pdata)
+		p->config = *pdata;
+
+	p->pdev = pdev;
+	platform_set_drvdata(pdev, p);
+	spin_lock_init(&p->lock);
+
+	io = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
+
+	if (!io || !irq) {
+		dev_err(&pdev->dev, "missing IRQ or IOMEM\n");
+		ret = -EINVAL;
+		goto err0;
+	}
+
+	p->base = devm_ioremap_nocache(&pdev->dev, io->start,
+				       resource_size(io));
+	if (!p->base) {
+		dev_err(&pdev->dev, "failed to remap I/O memory\n");
+		ret = -ENXIO;
+		goto err0;
+	}
+
+	gpio_chip = &p->gpio_chip;
+	gpio_chip->direction_input = gpio_rcar_direction_input;
+	gpio_chip->get = gpio_rcar_get;
+	gpio_chip->direction_output = gpio_rcar_direction_output;
+	gpio_chip->set = gpio_rcar_set;
+	gpio_chip->to_irq = gpio_rcar_to_irq;
+	gpio_chip->label = name;
+	gpio_chip->owner = THIS_MODULE;
+	gpio_chip->base = p->config.gpio_base;
+	gpio_chip->ngpio = p->config.number_of_pins;
+
+	irq_chip = &p->irq_chip;
+	irq_chip->name = name;
+	irq_chip->irq_mask = gpio_rcar_irq_disable;
+	irq_chip->irq_unmask = gpio_rcar_irq_enable;
+	irq_chip->irq_enable = gpio_rcar_irq_enable;
+	irq_chip->irq_disable = gpio_rcar_irq_disable;
+	irq_chip->irq_set_type = gpio_rcar_irq_set_type;
+	irq_chip->flags	= IRQCHIP_SKIP_SET_WAKE | IRQCHIP_SET_TYPE_MASKED;
+
+	p->irq_domain = irq_domain_add_simple(pdev->dev.of_node,
+					      p->config.number_of_pins,
+					      p->config.irq_base,
+					      &gpio_rcar_irq_domain_ops, p);
+	if (!p->irq_domain) {
+		ret = -ENXIO;
+		dev_err(&pdev->dev, "cannot initialize irq domain\n");
+		goto err1;
+	}
+
+	if (devm_request_irq(&pdev->dev, irq->start,
+			     gpio_rcar_irq_handler, 0, name, p)) {
+		dev_err(&pdev->dev, "failed to request IRQ\n");
+		ret = -ENOENT;
+		goto err1;
+	}
+
+	ret = gpiochip_add(gpio_chip);
+	if (ret) {
+		dev_err(&pdev->dev, "failed to add GPIO controller\n");
+		goto err1;
+	}
+
+	dev_info(&pdev->dev, "driving %d GPIOs\n", p->config.number_of_pins);
+
+	/* warn in case of mismatch if irq base is specified */
+	if (p->config.irq_base) {
+		ret = irq_find_mapping(p->irq_domain, 0);
+		if (p->config.irq_base != ret)
+			dev_warn(&pdev->dev, "irq base mismatch (%u/%u)\n",
+				 p->config.irq_base, ret);
+	}
+
+	return 0;
+
+err1:
+	irq_domain_remove(p->irq_domain);
+err0:
+	return ret;
+}
+
+static int gpio_rcar_remove(struct platform_device *pdev)
+{
+	struct gpio_rcar_priv *p = platform_get_drvdata(pdev);
+	int ret;
+
+	ret = gpiochip_remove(&p->gpio_chip);
+	if (ret)
+		return ret;
+
+	irq_domain_remove(p->irq_domain);
+	return 0;
+}
+
+static struct platform_driver gpio_rcar_device_driver = {
+	.probe		= gpio_rcar_probe,
+	.remove		= gpio_rcar_remove,
+	.driver		= {
+		.name	= "gpio_rcar",
+	}
+};
+
+module_platform_driver(gpio_rcar_device_driver);
+
+MODULE_AUTHOR("Magnus Damm");
+MODULE_DESCRIPTION("Renesas R-Car GPIO Driver");
+MODULE_LICENSE("GPL v2");
diff --git a/include/linux/platform_data/gpio-rcar.h b/include/linux/platform_data/gpio-rcar.h
new file mode 100644
index 0000000..bebfcd8
--- /dev/null
+++ b/include/linux/platform_data/gpio-rcar.h
@@ -0,0 +1,25 @@
+/*
+ * Renesas R-Car GPIO Support
+ *
+ *  Copyright (C) 2013 Magnus Damm
+ *
+ * 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
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef __GPIO_RCAR_H__
+#define __GPIO_RCAR_H__
+
+struct gpio_rcar_config {
+	unsigned int gpio_base;
+	unsigned int irq_base;
+	unsigned int number_of_pins;
+};
+
+#endif /* __GPIO_RCAR_H__ */
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 01:09:13 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue,  2 Apr 2013 14:09:13 +0900
Subject: [PATCH 05/28] ARM: shmobile: r8a7779: Remove all GPIOs
In-Reply-To: <1364879376-10020-1-git-send-email-horms+renesas@verge.net.au>
References: <1364879376-10020-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364879376-10020-6-git-send-email-horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

Function GPIOs are not used anymore, and all code use the GPIO numbers
directly. Remove the GPIOs enumeration.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Acked-by: Linus Walleij <linus.walleij at linaro.org>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/include/mach/r8a7779.h |  317 -------------------------
 1 file changed, 317 deletions(-)

diff --git a/arch/arm/mach-shmobile/include/mach/r8a7779.h b/arch/arm/mach-shmobile/include/mach/r8a7779.h
index 68c3b2d..945299e 100644
--- a/arch/arm/mach-shmobile/include/mach/r8a7779.h
+++ b/arch/arm/mach-shmobile/include/mach/r8a7779.h
@@ -4,323 +4,6 @@
 #include <linux/sh_clk.h>
 #include <linux/pm_domain.h>
 
-/* Pin Function Controller:
- * GPIO_FN_xx - GPIO used to select pin function
- * GPIO_GP_x_x - GPIO mapped to real I/O pin on CPU
- */
-enum {
-	GPIO_GP_0_0, GPIO_GP_0_1, GPIO_GP_0_2, GPIO_GP_0_3,
-	GPIO_GP_0_4, GPIO_GP_0_5, GPIO_GP_0_6, GPIO_GP_0_7,
-	GPIO_GP_0_8, GPIO_GP_0_9, GPIO_GP_0_10, GPIO_GP_0_11,
-	GPIO_GP_0_12, GPIO_GP_0_13, GPIO_GP_0_14, GPIO_GP_0_15,
-	GPIO_GP_0_16, GPIO_GP_0_17, GPIO_GP_0_18, GPIO_GP_0_19,
-	GPIO_GP_0_20, GPIO_GP_0_21, GPIO_GP_0_22, GPIO_GP_0_23,
-	GPIO_GP_0_24, GPIO_GP_0_25, GPIO_GP_0_26, GPIO_GP_0_27,
-	GPIO_GP_0_28, GPIO_GP_0_29, GPIO_GP_0_30, GPIO_GP_0_31,
-
-	GPIO_GP_1_0, GPIO_GP_1_1, GPIO_GP_1_2, GPIO_GP_1_3,
-	GPIO_GP_1_4, GPIO_GP_1_5, GPIO_GP_1_6, GPIO_GP_1_7,
-	GPIO_GP_1_8, GPIO_GP_1_9, GPIO_GP_1_10, GPIO_GP_1_11,
-	GPIO_GP_1_12, GPIO_GP_1_13, GPIO_GP_1_14, GPIO_GP_1_15,
-	GPIO_GP_1_16, GPIO_GP_1_17, GPIO_GP_1_18, GPIO_GP_1_19,
-	GPIO_GP_1_20, GPIO_GP_1_21, GPIO_GP_1_22, GPIO_GP_1_23,
-	GPIO_GP_1_24, GPIO_GP_1_25, GPIO_GP_1_26, GPIO_GP_1_27,
-	GPIO_GP_1_28, GPIO_GP_1_29, GPIO_GP_1_30, GPIO_GP_1_31,
-
-	GPIO_GP_2_0, GPIO_GP_2_1, GPIO_GP_2_2, GPIO_GP_2_3,
-	GPIO_GP_2_4, GPIO_GP_2_5, GPIO_GP_2_6, GPIO_GP_2_7,
-	GPIO_GP_2_8, GPIO_GP_2_9, GPIO_GP_2_10, GPIO_GP_2_11,
-	GPIO_GP_2_12, GPIO_GP_2_13, GPIO_GP_2_14, GPIO_GP_2_15,
-	GPIO_GP_2_16, GPIO_GP_2_17, GPIO_GP_2_18, GPIO_GP_2_19,
-	GPIO_GP_2_20, GPIO_GP_2_21, GPIO_GP_2_22, GPIO_GP_2_23,
-	GPIO_GP_2_24, GPIO_GP_2_25, GPIO_GP_2_26, GPIO_GP_2_27,
-	GPIO_GP_2_28, GPIO_GP_2_29, GPIO_GP_2_30, GPIO_GP_2_31,
-
-	GPIO_GP_3_0, GPIO_GP_3_1, GPIO_GP_3_2, GPIO_GP_3_3,
-	GPIO_GP_3_4, GPIO_GP_3_5, GPIO_GP_3_6, GPIO_GP_3_7,
-	GPIO_GP_3_8, GPIO_GP_3_9, GPIO_GP_3_10, GPIO_GP_3_11,
-	GPIO_GP_3_12, GPIO_GP_3_13, GPIO_GP_3_14, GPIO_GP_3_15,
-	GPIO_GP_3_16, GPIO_GP_3_17, GPIO_GP_3_18, GPIO_GP_3_19,
-	GPIO_GP_3_20, GPIO_GP_3_21, GPIO_GP_3_22, GPIO_GP_3_23,
-	GPIO_GP_3_24, GPIO_GP_3_25, GPIO_GP_3_26, GPIO_GP_3_27,
-	GPIO_GP_3_28, GPIO_GP_3_29, GPIO_GP_3_30, GPIO_GP_3_31,
-
-	GPIO_GP_4_0, GPIO_GP_4_1, GPIO_GP_4_2, GPIO_GP_4_3,
-	GPIO_GP_4_4, GPIO_GP_4_5, GPIO_GP_4_6, GPIO_GP_4_7,
-	GPIO_GP_4_8, GPIO_GP_4_9, GPIO_GP_4_10, GPIO_GP_4_11,
-	GPIO_GP_4_12, GPIO_GP_4_13, GPIO_GP_4_14, GPIO_GP_4_15,
-	GPIO_GP_4_16, GPIO_GP_4_17, GPIO_GP_4_18, GPIO_GP_4_19,
-	GPIO_GP_4_20, GPIO_GP_4_21, GPIO_GP_4_22, GPIO_GP_4_23,
-	GPIO_GP_4_24, GPIO_GP_4_25, GPIO_GP_4_26, GPIO_GP_4_27,
-	GPIO_GP_4_28, GPIO_GP_4_29, GPIO_GP_4_30, GPIO_GP_4_31,
-
-	GPIO_GP_5_0, GPIO_GP_5_1, GPIO_GP_5_2, GPIO_GP_5_3,
-	GPIO_GP_5_4, GPIO_GP_5_5, GPIO_GP_5_6, GPIO_GP_5_7,
-	GPIO_GP_5_8, GPIO_GP_5_9, GPIO_GP_5_10, GPIO_GP_5_11,
-	GPIO_GP_5_12, GPIO_GP_5_13, GPIO_GP_5_14, GPIO_GP_5_15,
-	GPIO_GP_5_16, GPIO_GP_5_17, GPIO_GP_5_18, GPIO_GP_5_19,
-	GPIO_GP_5_20, GPIO_GP_5_21, GPIO_GP_5_22, GPIO_GP_5_23,
-	GPIO_GP_5_24, GPIO_GP_5_25, GPIO_GP_5_26, GPIO_GP_5_27,
-	GPIO_GP_5_28, GPIO_GP_5_29, GPIO_GP_5_30, GPIO_GP_5_31,
-
-	GPIO_GP_6_0, GPIO_GP_6_1, GPIO_GP_6_2, GPIO_GP_6_3,
-	GPIO_GP_6_4, GPIO_GP_6_5, GPIO_GP_6_6, GPIO_GP_6_7,
-	GPIO_GP_6_8,
-
-	GPIO_FN_AVS1, GPIO_FN_AVS2, GPIO_FN_A17, GPIO_FN_A18,
-	GPIO_FN_A19,
-
-	/* IPSR0 */
-	GPIO_FN_PWM1, GPIO_FN_PWMFSW0,
-	GPIO_FN_SCIF_CLK, GPIO_FN_TCLK0_C, GPIO_FN_BS,
-	GPIO_FN_FD2, GPIO_FN_ATADIR0, GPIO_FN_SDSELF,
-	GPIO_FN_HCTS1, GPIO_FN_A0,
-	GPIO_FN_FD3, GPIO_FN_A20,
-	GPIO_FN_A21,
-	GPIO_FN_A22, GPIO_FN_VI1_R0,
-	GPIO_FN_A23, GPIO_FN_FCLE, GPIO_FN_VI1_R1,
-	GPIO_FN_A24, GPIO_FN_FD4,
-	GPIO_FN_VI1_R2, GPIO_FN_SSI_WS78_B, GPIO_FN_A25,
-	GPIO_FN_FD5,
-	GPIO_FN_VI1_R3, GPIO_FN_SSI_SDATA7_B,
-	GPIO_FN_CLKOUT, GPIO_FN_PWM0_B,
-	GPIO_FN_SDSELF_B, GPIO_FN_RD_WR, GPIO_FN_FWE, GPIO_FN_ATAG0,
-	GPIO_FN_VI1_R7, GPIO_FN_HRTS1,
-
-	/* IPSR1 */
-	GPIO_FN_FD6, GPIO_FN_FD7,
-	GPIO_FN_FALE,
-	GPIO_FN_ATACS00,
-	GPIO_FN_FRE, GPIO_FN_ATACS10, GPIO_FN_VI1_R4,
-	GPIO_FN_HSCK1, GPIO_FN_SSI_SDATA8_B,
-	GPIO_FN_SSI_SDATA9,
-	GPIO_FN_FD0, GPIO_FN_ATARD0, GPIO_FN_VI1_R5,
-	GPIO_FN_HTX1, GPIO_FN_SSI_SCK9,
-	GPIO_FN_FD1,
-	GPIO_FN_ATAWR0, GPIO_FN_VI1_R6, GPIO_FN_HRX1,
-	GPIO_FN_SSI_WS9, GPIO_FN_MLB_CLK, GPIO_FN_PWM2,
-	GPIO_FN_MLB_SIG, GPIO_FN_PWM3,
-	GPIO_FN_MLB_DAT, GPIO_FN_PWM4, GPIO_FN_HTX0,
-	GPIO_FN_SDATA, GPIO_FN_SUB_TCK,
-	GPIO_FN_CC5_STATE2, GPIO_FN_CC5_STATE10, GPIO_FN_CC5_STATE18,
-	GPIO_FN_CC5_STATE26, GPIO_FN_CC5_STATE34,
-
-	/* IPSR2 */
-	GPIO_FN_HRX0, GPIO_FN_SCKZ,
-	GPIO_FN_SUB_TDI, GPIO_FN_CC5_STATE3, GPIO_FN_CC5_STATE11,
-	GPIO_FN_CC5_STATE19, GPIO_FN_CC5_STATE27, GPIO_FN_CC5_STATE35,
-	GPIO_FN_HSCK0, GPIO_FN_MTS, GPIO_FN_PWM5,
-	GPIO_FN_SSI_SDATA9_B, GPIO_FN_SUB_TDO,
-	GPIO_FN_CC5_STATE0, GPIO_FN_CC5_STATE8, GPIO_FN_CC5_STATE16,
-	GPIO_FN_CC5_STATE24, GPIO_FN_CC5_STATE32, GPIO_FN_HCTS0,
-	GPIO_FN_STM, GPIO_FN_PWM0_D, GPIO_FN_SCIF_CLK_C,
-	GPIO_FN_SUB_TRST, GPIO_FN_TCLK1_B, GPIO_FN_CC5_OSCOUT, GPIO_FN_HRTS0,
-	GPIO_FN_MDATA, GPIO_FN_SUB_TMS,
-	GPIO_FN_CC5_STATE1, GPIO_FN_CC5_STATE9, GPIO_FN_CC5_STATE17,
-	GPIO_FN_CC5_STATE25, GPIO_FN_CC5_STATE33,
-	GPIO_FN_LCDOUT0, GPIO_FN_DREQ0, GPIO_FN_GPS_CLK_B, GPIO_FN_AUDATA0,
-	GPIO_FN_LCDOUT1, GPIO_FN_DACK0,
-	GPIO_FN_DRACK0, GPIO_FN_GPS_SIGN_B, GPIO_FN_AUDATA1,
-	GPIO_FN_LCDOUT2, GPIO_FN_LCDOUT3,
-	GPIO_FN_LCDOUT4, GPIO_FN_LCDOUT5,
-	GPIO_FN_LCDOUT6, GPIO_FN_LCDOUT7,
-	GPIO_FN_LCDOUT8, GPIO_FN_DREQ1, GPIO_FN_SCL2,
-	GPIO_FN_AUDATA2,
-
-	/* IPSR3 */
-	GPIO_FN_LCDOUT9, GPIO_FN_DACK1, GPIO_FN_SDA2,
-	GPIO_FN_AUDATA3, GPIO_FN_LCDOUT10,
-	GPIO_FN_LCDOUT11, GPIO_FN_LCDOUT12,
-	GPIO_FN_LCDOUT13, GPIO_FN_LCDOUT14,
-	GPIO_FN_LCDOUT15, GPIO_FN_LCDOUT16, GPIO_FN_EX_WAIT1,
-	GPIO_FN_SCL1, GPIO_FN_TCLK1, GPIO_FN_AUDATA4,
-	GPIO_FN_LCDOUT17, GPIO_FN_EX_WAIT2, GPIO_FN_SDA1, GPIO_FN_GPS_MAG_B,
-	GPIO_FN_AUDATA5, GPIO_FN_LCDOUT18,
-	GPIO_FN_LCDOUT19, GPIO_FN_LCDOUT20,
-	GPIO_FN_LCDOUT21, GPIO_FN_LCDOUT22,
-	GPIO_FN_LCDOUT23,
-	GPIO_FN_QSTVA_QVS, GPIO_FN_SCL3_B,
-	GPIO_FN_QCLK,
-	GPIO_FN_QSTVB_QVE, GPIO_FN_SDA3_B,
-	GPIO_FN_SDA2_C, GPIO_FN_DACK0_B, GPIO_FN_DRACK0_B,
-	GPIO_FN_QSTH_QHS,
-	GPIO_FN_QSTB_QHE,
-	GPIO_FN_QCPV_QDE,
-	GPIO_FN_CAN1_TX, GPIO_FN_SCL2_C, GPIO_FN_REMOCON,
-
-	/* IPSR4 */
-	GPIO_FN_QPOLA, GPIO_FN_CAN_CLK_C,
-	GPIO_FN_QPOLB, GPIO_FN_CAN1_RX,
-	GPIO_FN_DREQ0_B, GPIO_FN_SSI_SCK78_B,
-	GPIO_FN_VI2_DATA0_VI2_B0, GPIO_FN_PWM6,
-	GPIO_FN_AUDCK, GPIO_FN_PWMFSW0_B,
-	GPIO_FN_VI2_DATA1_VI2_B1, GPIO_FN_PWM0,
-	GPIO_FN_AUDSYNC,
-	GPIO_FN_VI2_G0,
-	GPIO_FN_VI2_G1, GPIO_FN_VI2_G2,
-	GPIO_FN_VI2_G3, GPIO_FN_VI2_G4,
-	GPIO_FN_VI2_G5, GPIO_FN_VI2_DATA2_VI2_B2,
-	GPIO_FN_SCL1_B, GPIO_FN_AUDATA6,
-	GPIO_FN_VI2_DATA3_VI2_B3,
-	GPIO_FN_SDA1_B, GPIO_FN_AUDATA7,
-	GPIO_FN_VI2_G6,
-	GPIO_FN_VI2_G7, GPIO_FN_VI2_R0,
-	GPIO_FN_VI2_R1, GPIO_FN_VI2_R2,
-	GPIO_FN_VI2_R3, GPIO_FN_VI2_DATA4_VI2_B4,
-	GPIO_FN_SCL2_B,
-
-	/* IPSR5 */
-	GPIO_FN_VI2_DATA5_VI2_B5, GPIO_FN_SDA2_B,
-	GPIO_FN_VI2_R4, GPIO_FN_VI2_R5,
-	GPIO_FN_VI2_R6, GPIO_FN_VI2_R7,
-	GPIO_FN_SCL2_D, GPIO_FN_SDA2_D,
-	GPIO_FN_VI2_CLKENB,
-	GPIO_FN_SCL1_D, GPIO_FN_VI2_FIELD,
-	GPIO_FN_SDA1_D, GPIO_FN_VI2_HSYNC,
-	GPIO_FN_VI3_HSYNC, GPIO_FN_VI2_VSYNC,
-	GPIO_FN_VI3_VSYNC,
-	GPIO_FN_VI2_CLK,
-	GPIO_FN_VI1_CLKENB, GPIO_FN_VI3_CLKENB,
-	GPIO_FN_AUDIO_CLKC, GPIO_FN_SPEEDIN,
-	GPIO_FN_GPS_SIGN_D, GPIO_FN_VI2_DATA6_VI2_B6,
-	GPIO_FN_TCLK0, GPIO_FN_QSTVA_B_QVS_B,
-	GPIO_FN_AUDIO_CLKOUT_B, GPIO_FN_GPS_MAG_D,
-	GPIO_FN_VI2_DATA7_VI2_B7,
-	GPIO_FN_VI1_FIELD, GPIO_FN_VI3_FIELD,
-	GPIO_FN_AUDIO_CLKOUT, GPIO_FN_GPS_CLK_C,
-	GPIO_FN_GPS_CLK_D, GPIO_FN_AUDIO_CLKA, GPIO_FN_CAN_TXCLK,
-	GPIO_FN_AUDIO_CLKB, GPIO_FN_CAN_DEBUGOUT0,
-	GPIO_FN_MOUT0,
-
-	/* IPSR6 */
-	GPIO_FN_SSI_SCK0129, GPIO_FN_CAN_DEBUGOUT1, GPIO_FN_MOUT1,
-	GPIO_FN_SSI_WS0129, GPIO_FN_CAN_DEBUGOUT2, GPIO_FN_MOUT2,
-	GPIO_FN_SSI_SDATA0, GPIO_FN_CAN_DEBUGOUT3, GPIO_FN_MOUT5,
-	GPIO_FN_SSI_SDATA1, GPIO_FN_CAN_DEBUGOUT4, GPIO_FN_MOUT6,
-	GPIO_FN_SSI_SDATA2, GPIO_FN_CAN_DEBUGOUT5, GPIO_FN_SSI_SCK34,
-	GPIO_FN_CAN_DEBUGOUT6, GPIO_FN_CAN0_TX_B, GPIO_FN_IERX,
-	GPIO_FN_SSI_SCK9_C, GPIO_FN_SSI_WS34, GPIO_FN_CAN_DEBUGOUT7,
-	GPIO_FN_CAN0_RX_B, GPIO_FN_IETX, GPIO_FN_SSI_WS9_C,
-	GPIO_FN_SSI_SDATA3, GPIO_FN_PWM0_C, GPIO_FN_CAN_DEBUGOUT8,
-	GPIO_FN_CAN_CLK_B, GPIO_FN_IECLK, GPIO_FN_SCIF_CLK_B, GPIO_FN_TCLK0_B,
-	GPIO_FN_SSI_SDATA4, GPIO_FN_CAN_DEBUGOUT9, GPIO_FN_SSI_SDATA9_C,
-	GPIO_FN_SSI_SCK5, GPIO_FN_ADICLK, GPIO_FN_CAN_DEBUGOUT10,
-	GPIO_FN_TCLK0_D, GPIO_FN_SSI_WS5, GPIO_FN_ADICS_SAMP,
-	GPIO_FN_CAN_DEBUGOUT11, GPIO_FN_SSI_SDATA5,
-	GPIO_FN_ADIDATA, GPIO_FN_CAN_DEBUGOUT12,
-	GPIO_FN_SSI_SCK6, GPIO_FN_ADICHS0, GPIO_FN_CAN0_TX, GPIO_FN_IERX_B,
-
-	/* IPSR7 */
-	GPIO_FN_SSI_WS6, GPIO_FN_ADICHS1, GPIO_FN_CAN0_RX, GPIO_FN_IETX_B,
-	GPIO_FN_SSI_SDATA6, GPIO_FN_ADICHS2, GPIO_FN_CAN_CLK, GPIO_FN_IECLK_B,
-	GPIO_FN_SSI_SCK78, GPIO_FN_CAN_DEBUGOUT13,
-	GPIO_FN_SSI_SCK9_B, GPIO_FN_SSI_WS78,
-	GPIO_FN_CAN_DEBUGOUT14, GPIO_FN_SSI_WS9_B,
-	GPIO_FN_SSI_SDATA7, GPIO_FN_CAN_DEBUGOUT15,
-	GPIO_FN_TCLK1_C,
-	GPIO_FN_SSI_SDATA8, GPIO_FN_VSP,
-	GPIO_FN_ATACS01,
-	GPIO_FN_ATACS11, GPIO_FN_CC5_TDO,
-	GPIO_FN_ATADIR1, GPIO_FN_CC5_TRST,
-	GPIO_FN_ATAG1, GPIO_FN_CC5_TMS,
-	GPIO_FN_ATARD1,	GPIO_FN_CC5_TCK,
-	GPIO_FN_ATAWR1,	GPIO_FN_CC5_TDI,
-	GPIO_FN_DREQ2,	GPIO_FN_DACK2,
-
-	/* IPSR8 */
-	GPIO_FN_AD_CLK,
-	GPIO_FN_CC5_STATE4, GPIO_FN_CC5_STATE12, GPIO_FN_CC5_STATE20,
-	GPIO_FN_CC5_STATE28, GPIO_FN_CC5_STATE36,
-	GPIO_FN_AD_DI,
-	GPIO_FN_CC5_STATE5, GPIO_FN_CC5_STATE13, GPIO_FN_CC5_STATE21,
-	GPIO_FN_CC5_STATE29, GPIO_FN_CC5_STATE37,
-	GPIO_FN_CAN_DEBUG_HW_TRIGGER, GPIO_FN_AD_DO,
-	GPIO_FN_CC5_STATE6, GPIO_FN_CC5_STATE14, GPIO_FN_CC5_STATE22,
-	GPIO_FN_CC5_STATE30, GPIO_FN_CC5_STATE38,
-	GPIO_FN_CAN_STEP0, GPIO_FN_AD_NCS, GPIO_FN_CC5_STATE7,
-	GPIO_FN_CC5_STATE15, GPIO_FN_CC5_STATE23, GPIO_FN_CC5_STATE31,
-	GPIO_FN_CC5_STATE39, GPIO_FN_FMCLK, GPIO_FN_RDS_CLK, GPIO_FN_PCMOE,
-	GPIO_FN_BPFCLK, GPIO_FN_PCMWE, GPIO_FN_FMIN, GPIO_FN_RDS_DATA,
-	GPIO_FN_VI0_CLK, GPIO_FN_VI0_CLKENB,
-	GPIO_FN_HTX1_B, GPIO_FN_MT1_SYNC, GPIO_FN_VI0_FIELD,
-	GPIO_FN_HRX1_B, GPIO_FN_VI0_HSYNC, GPIO_FN_VI0_DATA0_B_VI0_B0_B,
-	GPIO_FN_HSCK1_B,
-	GPIO_FN_VI0_VSYNC, GPIO_FN_VI0_DATA1_B_VI0_B1_B,
-	GPIO_FN_PWMFSW0_C,
-
-	/* IPSR9 */
-	GPIO_FN_VI0_DATA0_VI0_B0, GPIO_FN_HRTS1_B, GPIO_FN_MT1_VCXO,
-	GPIO_FN_VI0_DATA1_VI0_B1, GPIO_FN_HCTS1_B, GPIO_FN_MT1_PWM,
-	GPIO_FN_VI0_DATA2_VI0_B2, GPIO_FN_VI0_DATA3_VI0_B3,
-	GPIO_FN_VI0_DATA4_VI0_B4,
-	GPIO_FN_VI0_DATA5_VI0_B5, GPIO_FN_VI0_DATA6_VI0_B6,
-	GPIO_FN_ARM_TRACEDATA_0, GPIO_FN_VI0_DATA7_VI0_B7,
-	GPIO_FN_ARM_TRACEDATA_1, GPIO_FN_VI0_G0,
-	GPIO_FN_SSI_SCK78_C, GPIO_FN_ARM_TRACEDATA_2,
-	GPIO_FN_VI0_G1, GPIO_FN_SSI_WS78_C,
-	GPIO_FN_ARM_TRACEDATA_3, GPIO_FN_VI0_G2, GPIO_FN_ETH_TXD1,
-	GPIO_FN_ARM_TRACEDATA_4, GPIO_FN_TS_SPSYNC0,
-	GPIO_FN_VI0_G3, GPIO_FN_ETH_CRS_DV,
-	GPIO_FN_ARM_TRACEDATA_5, GPIO_FN_TS_SDAT0, GPIO_FN_VI0_G4,
-	GPIO_FN_ETH_TX_EN, GPIO_FN_ARM_TRACEDATA_6,
-	GPIO_FN_VI0_G5,	GPIO_FN_ETH_RX_ER,
-	GPIO_FN_ARM_TRACEDATA_7, GPIO_FN_VI0_G6, GPIO_FN_ETH_RXD0,
-	GPIO_FN_ARM_TRACEDATA_8, GPIO_FN_VI0_G7,
-	GPIO_FN_ETH_RXD1, GPIO_FN_ARM_TRACEDATA_9,
-
-	/* IPSR10 */
-	GPIO_FN_VI0_R0, GPIO_FN_SSI_SDATA7_C, GPIO_FN_DREQ1_B,
-	GPIO_FN_ARM_TRACEDATA_10, GPIO_FN_DREQ0_C, GPIO_FN_VI0_R1,
-	GPIO_FN_SSI_SDATA8_C, GPIO_FN_DACK1_B, GPIO_FN_ARM_TRACEDATA_11,
-	GPIO_FN_DACK0_C, GPIO_FN_DRACK0_C, GPIO_FN_VI0_R2, GPIO_FN_ETH_LINK,
-	GPIO_FN_ARM_TRACEDATA_12,
-	GPIO_FN_VI0_R3, GPIO_FN_ETH_MAGIC,
-	GPIO_FN_ARM_TRACEDATA_13, GPIO_FN_VI0_R4, GPIO_FN_ETH_REFCLK,
-	GPIO_FN_ARM_TRACEDATA_14,
-	GPIO_FN_MT1_CLK, GPIO_FN_TS_SCK0, GPIO_FN_VI0_R5, GPIO_FN_ETH_TXD0,
-	GPIO_FN_ARM_TRACEDATA_15,
-	GPIO_FN_MT1_D, GPIO_FN_TS_SDEN0, GPIO_FN_VI0_R6, GPIO_FN_ETH_MDC,
-	GPIO_FN_DREQ2_C, GPIO_FN_TRACECLK,
-	GPIO_FN_MT1_BEN, GPIO_FN_PWMFSW0_D, GPIO_FN_VI0_R7, GPIO_FN_ETH_MDIO,
-	GPIO_FN_DACK2_C, GPIO_FN_SCIF_CLK_D,
-	GPIO_FN_TRACECTL, GPIO_FN_MT1_PEN, GPIO_FN_VI1_CLK, GPIO_FN_SIM_D,
-	GPIO_FN_SDA3, GPIO_FN_VI1_HSYNC, GPIO_FN_VI3_CLK, GPIO_FN_SSI_SCK4,
-	GPIO_FN_GPS_SIGN_C, GPIO_FN_PWMFSW0_E, GPIO_FN_VI1_VSYNC,
-	GPIO_FN_AUDIO_CLKOUT_C, GPIO_FN_SSI_WS4, GPIO_FN_SIM_CLK,
-	GPIO_FN_GPS_MAG_C, GPIO_FN_SPV_TRST, GPIO_FN_SCL3,
-
-	/* IPSR11 */
-	GPIO_FN_VI1_DATA0_VI1_B0, GPIO_FN_SIM_RST,
-	GPIO_FN_SPV_TCK, GPIO_FN_ADICLK_B, GPIO_FN_VI1_DATA1_VI1_B1,
-	GPIO_FN_MT0_CLK, GPIO_FN_SPV_TMS,
-	GPIO_FN_ADICS_B_SAMP_B, GPIO_FN_VI1_DATA2_VI1_B2,
-	GPIO_FN_MT0_D, GPIO_FN_SPVTDI, GPIO_FN_ADIDATA_B,
-	GPIO_FN_VI1_DATA3_VI1_B3, GPIO_FN_MT0_BEN,
-	GPIO_FN_SPV_TDO, GPIO_FN_ADICHS0_B, GPIO_FN_VI1_DATA4_VI1_B4,
-	GPIO_FN_MT0_PEN, GPIO_FN_SPA_TRST,
-	GPIO_FN_ADICHS1_B, GPIO_FN_VI1_DATA5_VI1_B5,
-	GPIO_FN_MT0_SYNC, GPIO_FN_SPA_TCK,
-	GPIO_FN_ADICHS2_B, GPIO_FN_VI1_DATA6_VI1_B6,
-	GPIO_FN_MT0_VCXO, GPIO_FN_SPA_TMS,
-	GPIO_FN_VI1_DATA7_VI1_B7, GPIO_FN_MT0_PWM,
-	GPIO_FN_SPA_TDI, GPIO_FN_VI1_G0, GPIO_FN_VI3_DATA0,
-	GPIO_FN_TS_SCK1, GPIO_FN_DREQ2_B,
-	GPIO_FN_SPA_TDO, GPIO_FN_HCTS0_B, GPIO_FN_VI1_G1, GPIO_FN_VI3_DATA1,
-	GPIO_FN_SSI_SCK1, GPIO_FN_TS_SDEN1, GPIO_FN_DACK2_B,
-	GPIO_FN_HRTS0_B,
-
-	/* IPSR12 */
-	GPIO_FN_VI1_G2, GPIO_FN_VI3_DATA2, GPIO_FN_SSI_WS1, GPIO_FN_TS_SPSYNC1,
-	GPIO_FN_HSCK0_B, GPIO_FN_VI1_G3, GPIO_FN_VI3_DATA3,
-	GPIO_FN_SSI_SCK2, GPIO_FN_TS_SDAT1, GPIO_FN_SCL1_C, GPIO_FN_HTX0_B,
-	GPIO_FN_VI1_G4, GPIO_FN_VI3_DATA4, GPIO_FN_SSI_WS2, GPIO_FN_SDA1_C,
-	GPIO_FN_SIM_RST_B, GPIO_FN_HRX0_B, GPIO_FN_VI1_G5, GPIO_FN_VI3_DATA5,
-	GPIO_FN_GPS_CLK, GPIO_FN_FSE, GPIO_FN_SIM_D_B,
-	GPIO_FN_VI1_G6, GPIO_FN_VI3_DATA6, GPIO_FN_GPS_SIGN, GPIO_FN_FRB,
-	GPIO_FN_SIM_CLK_B, GPIO_FN_VI1_G7, GPIO_FN_VI3_DATA7,
-	GPIO_FN_GPS_MAG, GPIO_FN_FCE,
-};
-
 struct platform_device;
 
 struct r8a7779_pm_ch {
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 01:09:22 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue,  2 Apr 2013 14:09:22 +0900
Subject: [PATCH 14/28] sh-pfc: r8a7779: Remove GPIO data
In-Reply-To: <1364879376-10020-1-git-send-email-horms+renesas@verge.net.au>
References: <1364879376-10020-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364879376-10020-15-git-send-email-horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

GPIOs are now handled by a separate driver, remove GPIO data from the
SoC information structure.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Acked-by: Linus Walleij <linus.walleij at linaro.org>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 drivers/pinctrl/sh-pfc/pfc-r8a7779.c |   58 +---------------------------------
 1 file changed, 1 insertion(+), 57 deletions(-)

diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a7779.c b/drivers/pinctrl/sh-pfc/pfc-r8a7779.c
index 41d8bda..e448ff1 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a7779.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a7779.c
@@ -85,18 +85,12 @@
 	}
 
 #define _GP_DATA(bank, pin, name, sfx)					\
-	PINMUX_DATA(name##_DATA, name##_FN, name##_IN, name##_OUT)
-
-#define _GP_INOUTSEL(bank, pin, name, sfx)	name##_IN, name##_OUT
-#define _GP_INDT(bank, pin, name, sfx)		name##_DATA
+	PINMUX_DATA(name##_DATA, name##_FN)
 
 #define GP_ALL(str)		CPU_ALL_PORT(_GP_PORT_ALL, str)
 #define PINMUX_GPIO_GP_ALL()	CPU_ALL_PORT(_GP_GPIO, unused)
 #define PINMUX_DATA_GP_ALL()	CPU_ALL_PORT(_GP_DATA, unused)
 
-#define GP_INOUTSEL(bank) PORT_GP_32_REV(bank, _GP_INOUTSEL, unused)
-#define GP_INDT(bank) PORT_GP_32_REV(bank, _GP_INDT, unused)
-
 #define PINMUX_IPSR_DATA(ipsr, fn) PINMUX_DATA(fn##_MARK, FN_##ipsr, FN_##fn)
 #define PINMUX_IPSR_MODSEL_DATA(ipsr, fn, ms) PINMUX_DATA(fn##_MARK, FN_##ms, \
 							  FN_##ipsr, FN_##fn)
@@ -108,14 +102,6 @@ enum {
 	GP_ALL(DATA), /* GP_0_0_DATA -> GP_6_8_DATA */
 	PINMUX_DATA_END,
 
-	PINMUX_INPUT_BEGIN,
-	GP_ALL(IN), /* GP_0_0_IN -> GP_6_8_IN */
-	PINMUX_INPUT_END,
-
-	PINMUX_OUTPUT_BEGIN,
-	GP_ALL(OUT), /* GP_0_0_OUT -> GP_6_8_OUT */
-	PINMUX_OUTPUT_END,
-
 	PINMUX_FUNCTION_BEGIN,
 	GP_ALL(FN), /* GP_0_0_FN -> GP_6_8_FN */
 
@@ -3549,45 +3535,6 @@ static const struct pinmux_cfg_reg pinmux_config_regs[] = {
 	    /* SEL_I2C1 [2] */
 	    FN_SEL_I2C1_0, FN_SEL_I2C1_1, FN_SEL_I2C1_2, FN_SEL_I2C1_3 }
 	},
-	{ PINMUX_CFG_REG("INOUTSEL0", 0xffc40004, 32, 1) { GP_INOUTSEL(0) } },
-	{ PINMUX_CFG_REG("INOUTSEL1", 0xffc41004, 32, 1) { GP_INOUTSEL(1) } },
-	{ PINMUX_CFG_REG("INOUTSEL2", 0xffc42004, 32, 1) { GP_INOUTSEL(2) } },
-	{ PINMUX_CFG_REG("INOUTSEL3", 0xffc43004, 32, 1) { GP_INOUTSEL(3) } },
-	{ PINMUX_CFG_REG("INOUTSEL4", 0xffc44004, 32, 1) { GP_INOUTSEL(4) } },
-	{ PINMUX_CFG_REG("INOUTSEL5", 0xffc45004, 32, 1) { GP_INOUTSEL(5) } },
-	{ PINMUX_CFG_REG("INOUTSEL6", 0xffc46004, 32, 1) {
-		0, 0, 0, 0, 0, 0, 0, 0,	0, 0, 0, 0, 0, 0, 0, 0,
-		0, 0, 0, 0, 0, 0, 0, 0,	0, 0, 0, 0, 0, 0, 0, 0,
-		0, 0, 0, 0, 0, 0, 0, 0,
-		0, 0,
-		0, 0,
-		0, 0,
-		GP_6_8_IN, GP_6_8_OUT,
-		GP_6_7_IN, GP_6_7_OUT,
-		GP_6_6_IN, GP_6_6_OUT,
-		GP_6_5_IN, GP_6_5_OUT,
-		GP_6_4_IN, GP_6_4_OUT,
-		GP_6_3_IN, GP_6_3_OUT,
-		GP_6_2_IN, GP_6_2_OUT,
-		GP_6_1_IN, GP_6_1_OUT,
-		GP_6_0_IN, GP_6_0_OUT, }
-	},
-	{ },
-};
-
-static const struct pinmux_data_reg pinmux_data_regs[] = {
-	{ PINMUX_DATA_REG("INDT0", 0xffc40008, 32) { GP_INDT(0) } },
-	{ PINMUX_DATA_REG("INDT1", 0xffc41008, 32) { GP_INDT(1) } },
-	{ PINMUX_DATA_REG("INDT2", 0xffc42008, 32) { GP_INDT(2) } },
-	{ PINMUX_DATA_REG("INDT3", 0xffc43008, 32) { GP_INDT(3) } },
-	{ PINMUX_DATA_REG("INDT4", 0xffc44008, 32) { GP_INDT(4) } },
-	{ PINMUX_DATA_REG("INDT5", 0xffc45008, 32) { GP_INDT(5) } },
-	{ PINMUX_DATA_REG("INDT6", 0xffc46008, 32) {
-		0, 0, 0, 0, 0, 0, 0, 0,	0, 0, 0, 0, 0, 0, 0, 0,
-		0, 0, 0, 0, 0, 0, 0, GP_6_8_DATA,
-		GP_6_7_DATA, GP_6_6_DATA, GP_6_5_DATA, GP_6_4_DATA,
-		GP_6_3_DATA, GP_6_2_DATA, GP_6_1_DATA, GP_6_0_DATA }
-	},
 	{ },
 };
 
@@ -3596,8 +3543,6 @@ const struct sh_pfc_soc_info r8a7779_pinmux_info = {
 
 	.unlock_reg = 0xfffc0000, /* PMMR */
 
-	.input = { PINMUX_INPUT_BEGIN, PINMUX_INPUT_END },
-	.output = { PINMUX_OUTPUT_BEGIN, PINMUX_OUTPUT_END },
 	.function = { PINMUX_FUNCTION_BEGIN, PINMUX_FUNCTION_END },
 
 	.pins = pinmux_pins,
@@ -3608,7 +3553,6 @@ const struct sh_pfc_soc_info r8a7779_pinmux_info = {
 	.nr_functions = ARRAY_SIZE(pinmux_functions),
 
 	.cfg_regs = pinmux_config_regs,
-	.data_regs = pinmux_data_regs,
 
 	.gpio_data = pinmux_data,
 	.gpio_data_size = ARRAY_SIZE(pinmux_data),
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 01:09:23 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue,  2 Apr 2013 14:09:23 +0900
Subject: [PATCH 15/28] sh-pfc: r8a7779: Split DU input and output pixel clocks
In-Reply-To: <1364879376-10020-1-git-send-email-horms+renesas@verge.net.au>
References: <1364879376-10020-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364879376-10020-16-git-send-email-horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

The output pixel clocks can be used without the input pixel clocks.
Split them in different groups.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 drivers/pinctrl/sh-pfc/pfc-r8a7779.c |   60 ++++++++++++++++++++++------------
 1 file changed, 39 insertions(+), 21 deletions(-)

diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a7779.c b/drivers/pinctrl/sh-pfc/pfc-r8a7779.c
index e448ff1..62dcdcd 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a7779.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a7779.c
@@ -1498,19 +1498,26 @@ static const unsigned int du0_rgb888_mux[] = {
 	DU0_DB7_MARK, DU0_DB6_MARK, DU0_DB5_MARK, DU0_DB4_MARK,
 	DU0_DB3_MARK, DU0_DB2_MARK, DU0_DB1_MARK, DU0_DB0_MARK,
 };
-static const unsigned int du0_clk_0_pins[] = {
-	/* CLKIN, CLKOUT */
-	29, 180,
+static const unsigned int du0_clk_in_pins[] = {
+	/* CLKIN */
+	29,
 };
-static const unsigned int du0_clk_0_mux[] = {
-	DU0_DOTCLKIN_MARK, DU0_DOTCLKOUT0_MARK,
+static const unsigned int du0_clk_in_mux[] = {
+	DU0_DOTCLKIN_MARK,
 };
-static const unsigned int du0_clk_1_pins[] = {
-	/* CLKIN, CLKOUT */
-	29, 30,
+static const unsigned int du0_clk_out_0_pins[] = {
+	/* CLKOUT */
+	180,
 };
-static const unsigned int du0_clk_1_mux[] = {
-	DU0_DOTCLKIN_MARK, DU0_DOTCLKOUT1_MARK,
+static const unsigned int du0_clk_out_0_mux[] = {
+	DU0_DOTCLKOUT0_MARK,
+};
+static const unsigned int du0_clk_out_1_pins[] = {
+	/* CLKOUT */
+	30,
+};
+static const unsigned int du0_clk_out_1_mux[] = {
+	DU0_DOTCLKOUT1_MARK,
 };
 static const unsigned int du0_sync_0_pins[] = {
 	/* VSYNC, HSYNC, DISP */
@@ -1571,12 +1578,19 @@ static const unsigned int du1_rgb888_mux[] = {
 	DU1_DB7_MARK, DU1_DB6_MARK, DU1_DB5_MARK, DU1_DB4_MARK,
 	DU1_DB3_MARK, DU1_DB2_MARK, DU1_DB1_MARK, DU1_DB0_MARK,
 };
-static const unsigned int du1_clk_pins[] = {
-	/* CLKIN, CLKOUT */
-	58, 59,
+static const unsigned int du1_clk_in_pins[] = {
+	/* CLKIN */
+	58,
+};
+static const unsigned int du1_clk_in_mux[] = {
+	DU1_DOTCLKIN_MARK,
+};
+static const unsigned int du1_clk_out_pins[] = {
+	/* CLKOUT */
+	59,
 };
-static const unsigned int du1_clk_mux[] = {
-	DU1_DOTCLKIN_MARK, DU1_DOTCLKOUT_MARK,
+static const unsigned int du1_clk_out_mux[] = {
+	DU1_DOTCLKOUT_MARK,
 };
 static const unsigned int du1_sync_0_pins[] = {
 	/* VSYNC, HSYNC, DISP */
@@ -2369,15 +2383,17 @@ static const unsigned int usb2_mux[] = {
 static const struct sh_pfc_pin_group pinmux_groups[] = {
 	SH_PFC_PIN_GROUP(du0_rgb666),
 	SH_PFC_PIN_GROUP(du0_rgb888),
-	SH_PFC_PIN_GROUP(du0_clk_0),
-	SH_PFC_PIN_GROUP(du0_clk_1),
+	SH_PFC_PIN_GROUP(du0_clk_in),
+	SH_PFC_PIN_GROUP(du0_clk_out_0),
+	SH_PFC_PIN_GROUP(du0_clk_out_1),
 	SH_PFC_PIN_GROUP(du0_sync_0),
 	SH_PFC_PIN_GROUP(du0_sync_1),
 	SH_PFC_PIN_GROUP(du0_oddf),
 	SH_PFC_PIN_GROUP(du0_cde),
 	SH_PFC_PIN_GROUP(du1_rgb666),
 	SH_PFC_PIN_GROUP(du1_rgb888),
-	SH_PFC_PIN_GROUP(du1_clk),
+	SH_PFC_PIN_GROUP(du1_clk_in),
+	SH_PFC_PIN_GROUP(du1_clk_out),
 	SH_PFC_PIN_GROUP(du1_sync_0),
 	SH_PFC_PIN_GROUP(du1_sync_1),
 	SH_PFC_PIN_GROUP(du1_oddf),
@@ -2492,8 +2508,9 @@ static const struct sh_pfc_pin_group pinmux_groups[] = {
 static const char * const du0_groups[] = {
 	"du0_rgb666",
 	"du0_rgb888",
-	"du0_clk_0",
-	"du0_clk_1",
+	"du0_clk_in",
+	"du0_clk_out_0",
+	"du0_clk_out_1",
 	"du0_sync_0",
 	"du0_sync_1",
 	"du0_oddf",
@@ -2503,7 +2520,8 @@ static const char * const du0_groups[] = {
 static const char * const du1_groups[] = {
 	"du1_rgb666",
 	"du1_rgb888",
-	"du1_clk",
+	"du1_clk_in",
+	"du1_clk_out",
 	"du1_sync_0",
 	"du1_sync_1",
 	"du1_oddf",
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 01:09:26 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue,  2 Apr 2013 14:09:26 +0900
Subject: [PATCH 18/28] sh-pfc: r8a73a4: GPIO IRQ support
In-Reply-To: <1364879376-10020-1-git-send-email-horms+renesas@verge.net.au>
References: <1364879376-10020-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364879376-10020-19-git-send-email-horms+renesas@verge.net.au>

From: Magnus Damm <damm at opensource.se>

V2 of code to add GPIO -> IRQ mappings to the
PFC table for the r8a73a4 SoC. Requires the IRQs
to be mapped at a fixed location in Linux IRQ
space. The actual IRQs are not handled by the
PFC, instead IRQC is used on r8a73a4.

Signed-off-by: Magnus Damm <damm at opensource.se>
Acked-by: Linus Walleij <linus.walleij at linaro.org>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 drivers/pinctrl/sh-pfc/pfc-r8a73a4.c |   63 ++++++++++++++++++++++++++++++++++
 1 file changed, 63 insertions(+)

diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a73a4.c b/drivers/pinctrl/sh-pfc/pfc-r8a73a4.c
index 5dd68fb9..0177329 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a73a4.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a73a4.c
@@ -2818,6 +2818,66 @@ static const struct pinmux_data_reg pinmux_data_regs[] = {
 	{ },
 };
 
+static const struct pinmux_irq pinmux_irqs[] = {
+	PINMUX_IRQ(irq_pin(0), 0),
+	PINMUX_IRQ(irq_pin(1), 1),
+	PINMUX_IRQ(irq_pin(2), 2),
+	PINMUX_IRQ(irq_pin(3), 3),
+	PINMUX_IRQ(irq_pin(4), 4),
+	PINMUX_IRQ(irq_pin(5), 5),
+	PINMUX_IRQ(irq_pin(6), 6),
+	PINMUX_IRQ(irq_pin(7), 7),
+	PINMUX_IRQ(irq_pin(8), 8),
+	PINMUX_IRQ(irq_pin(9), 9),
+	PINMUX_IRQ(irq_pin(10), 10),
+	PINMUX_IRQ(irq_pin(11), 11),
+	PINMUX_IRQ(irq_pin(12), 12),
+	PINMUX_IRQ(irq_pin(13), 13),
+	PINMUX_IRQ(irq_pin(14), 14),
+	PINMUX_IRQ(irq_pin(15), 15),
+	PINMUX_IRQ(irq_pin(16), 320),
+	PINMUX_IRQ(irq_pin(17), 321),
+	PINMUX_IRQ(irq_pin(18), 85),
+	PINMUX_IRQ(irq_pin(19), 84),
+	PINMUX_IRQ(irq_pin(20), 160),
+	PINMUX_IRQ(irq_pin(21), 161),
+	PINMUX_IRQ(irq_pin(22), 162),
+	PINMUX_IRQ(irq_pin(23), 163),
+	PINMUX_IRQ(irq_pin(24), 175),
+	PINMUX_IRQ(irq_pin(25), 176),
+	PINMUX_IRQ(irq_pin(26), 177),
+	PINMUX_IRQ(irq_pin(27), 178),
+	PINMUX_IRQ(irq_pin(28), 322),
+	PINMUX_IRQ(irq_pin(29), 323),
+	PINMUX_IRQ(irq_pin(30), 324),
+	PINMUX_IRQ(irq_pin(31), 192),
+	PINMUX_IRQ(irq_pin(32), 193),
+	PINMUX_IRQ(irq_pin(33), 194),
+	PINMUX_IRQ(irq_pin(34), 195),
+	PINMUX_IRQ(irq_pin(35), 196),
+	PINMUX_IRQ(irq_pin(36), 197),
+	PINMUX_IRQ(irq_pin(37), 198),
+	PINMUX_IRQ(irq_pin(38), 199),
+	PINMUX_IRQ(irq_pin(39), 200),
+	PINMUX_IRQ(irq_pin(40), 66),
+	PINMUX_IRQ(irq_pin(41), 102),
+	PINMUX_IRQ(irq_pin(42), 103),
+	PINMUX_IRQ(irq_pin(43), 109),
+	PINMUX_IRQ(irq_pin(44), 110),
+	PINMUX_IRQ(irq_pin(45), 111),
+	PINMUX_IRQ(irq_pin(46), 112),
+	PINMUX_IRQ(irq_pin(47), 113),
+	PINMUX_IRQ(irq_pin(48), 114),
+	PINMUX_IRQ(irq_pin(49), 115),
+	PINMUX_IRQ(irq_pin(50), 301),
+	PINMUX_IRQ(irq_pin(51), 290),
+	PINMUX_IRQ(irq_pin(52), 296),
+	PINMUX_IRQ(irq_pin(53), 325),
+	PINMUX_IRQ(irq_pin(54), 326),
+	PINMUX_IRQ(irq_pin(55), 327),
+	PINMUX_IRQ(irq_pin(56), 328),
+	PINMUX_IRQ(irq_pin(57), 329),
+};
 const struct sh_pfc_soc_info r8a73a4_pinmux_info = {
 	.name		= "r8a73a4_pfc",
 
@@ -2839,4 +2899,7 @@ const struct sh_pfc_soc_info r8a73a4_pinmux_info = {
 
 	.gpio_data	= pinmux_data,
 	.gpio_data_size	= ARRAY_SIZE(pinmux_data),
+
+	.gpio_irq = pinmux_irqs,
+	.gpio_irq_size = ARRAY_SIZE(pinmux_irqs),
 };
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 01:09:30 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue,  2 Apr 2013 14:09:30 +0900
Subject: [PATCH 22/28] sh-pfc: r8a73a4: Remove SCIF function GPIOS
In-Reply-To: <1364879376-10020-1-git-send-email-horms+renesas@verge.net.au>
References: <1364879376-10020-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364879376-10020-23-git-send-email-horms+renesas@verge.net.au>

From: Magnus Damm <damm at opensource.se>

The r8a73a4 board support will use the pinctrl API to control the SCIF
pins, remove the corresponding unused function GPIOS.

Signed-off-by: Magnus Damm <damm at opensource.se>
Acked-by: Linus Walleij <linus.walleij at linaro.org>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 drivers/pinctrl/sh-pfc/pfc-r8a73a4.c |   45 ----------------------------------
 1 file changed, 45 deletions(-)

diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a73a4.c b/drivers/pinctrl/sh-pfc/pfc-r8a73a4.c
index 8a5288c..470b18f 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a73a4.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a73a4.c
@@ -2160,55 +2160,45 @@ static const struct pinmux_func pinmux_func_gpios[] = {
 
 	/* Port19 */
 	GPIO_FN(LCDD19),
-	GPIO_FN(SCIFB3_RTS_19),
 	GPIO_FN(DU0_DB3),
 
 	/* Port20 */
 	GPIO_FN(LCDD20),
-	GPIO_FN(SCIFB3_CTS_20),
 	GPIO_FN(DU0_DB4),
 
 	/* Port21 */
 	GPIO_FN(LCDD21),
-	GPIO_FN(SCIFB3_TXD_21),
 	GPIO_FN(DU0_DB5),
 
 	/* Port22 */
 	GPIO_FN(LCDD22),
-	GPIO_FN(SCIFB3_RXD_22),
 	GPIO_FN(DU0_DB6),
 
 	/* Port23 */
 	GPIO_FN(LCDD23),
-	GPIO_FN(SCIFB3_SCK_23),
 	GPIO_FN(DU0_DB7),
 
 	/* Port24 */
 	GPIO_FN(LCDHSYN),
 	GPIO_FN(LCDCS),
-	GPIO_FN(SCIFB1_RTS_24),
 	GPIO_FN(DU0_EXHSYNC_N_CSYNC_N_HSYNC_N),
 
 	/* Port25 */
 	GPIO_FN(LCDVSYN),
-	GPIO_FN(SCIFB1_CTS_25),
 	GPIO_FN(DU0_EXVSYNC_N_VSYNC_N_CSYNC_N),
 
 	/* Port26 */
 	GPIO_FN(LCDDCK),
 	GPIO_FN(LCDWR),
-	GPIO_FN(SCIFB1_TXD_26),
 	GPIO_FN(DU0_DOTCLKIN),
 
 	/* Port27 */
 	GPIO_FN(LCDDISP),
 	GPIO_FN(LCDRS),
-	GPIO_FN(SCIFB1_RXD_27),
 	GPIO_FN(DU0_DOTCLKOUT),
 
 	/* Port28 */
 	GPIO_FN(LCDRD_N),
-	GPIO_FN(SCIFB1_SCK_28),
 	GPIO_FN(DU0_DOTCLKOUTB),
 
 	/* Port29 */
@@ -2222,48 +2212,36 @@ static const struct pinmux_func pinmux_func_gpios[] = {
 	GPIO_FN(DU0_ODDF_N_CLAMP),
 
 	/* Port32 */
-	GPIO_FN(SCIFA0_RTS),
 	GPIO_FN(SIM0_DET),
 	GPIO_FN(CSCIF0_RTS),
 
 	/* Port33 */
-	GPIO_FN(SCIFA0_CTS),
 	GPIO_FN(SIM1_DET),
 	GPIO_FN(CSCIF0_CTS),
 
 	/* Port34 */
-	GPIO_FN(SCIFA0_SCK),
 	GPIO_FN(SIM0_PWRON),
 	GPIO_FN(CSCIF0_SCK),
 
 	/* Port35 */
-	GPIO_FN(SCIFA1_RTS),
 	GPIO_FN(CSCIF1_RTS),
 
 	/* Port36 */
-	GPIO_FN(SCIFA1_CTS),
 	GPIO_FN(CSCIF1_CTS),
 
 	/* Port37 */
-	GPIO_FN(SCIFA1_SCK),
 	GPIO_FN(CSCIF1_SCK),
 
 	/* Port38 */
-	GPIO_FN(SCIFB0_RTS),
 	GPIO_FN(TPU0TO1),
-	GPIO_FN(SCIFB3_RTS_38),
 	GPIO_FN(CHSCIF0_HRTS),
 
 	/* Port39 */
-	GPIO_FN(SCIFB0_CTS),
 	GPIO_FN(TPU0TO2),
-	GPIO_FN(SCIFB3_CTS_39),
 	GPIO_FN(CHSCIF0_HCTS),
 
 	/* Port40 */
-	GPIO_FN(SCIFB0_SCK),
 	GPIO_FN(TPU0TO3),
-	GPIO_FN(SCIFB3_SCK_40),
 	GPIO_FN(CHSCIF0_HSCK),
 
 	/* Port64 */
@@ -2274,52 +2252,44 @@ static const struct pinmux_func pinmux_func_gpios[] = {
 
 	/* Port66 */
 	GPIO_FN(HSI_RX_WAKE),
-	GPIO_FN(SCIFB2_CTS_66),
 	GPIO_FN(MSIOF3_SYNC),
 	GPIO_FN(GenIO4),
 	GPIO_FN(IRQ40),
 
 	/* Port67 */
 	GPIO_FN(HSI_RX_READY),
-	GPIO_FN(SCIFB1_TXD_67),
 	GPIO_FN(GIO_OUT3_67),
 	GPIO_FN(CHSCIF1_HTX),
 
 	/* Port68 */
 	GPIO_FN(HSI_RX_FLAG),
-	GPIO_FN(SCIFB2_TXD_68),
 	GPIO_FN(MSIOF3_TXD),
 	GPIO_FN(GIO_OUT4_68),
 
 	/* Port69 */
 	GPIO_FN(HSI_RX_DATA),
-	GPIO_FN(SCIFB2_RXD_69),
 	GPIO_FN(MSIOF3_RXD),
 	GPIO_FN(GIO_OUT5_69),
 
 	/* Port70 */
 	GPIO_FN(HSI_TX_FLAG),
-	GPIO_FN(SCIFB1_RTS_70),
 	GPIO_FN(GIO_OUT1_70),
 	GPIO_FN(HSIC_TSTCLK0),
 	GPIO_FN(CHSCIF1_HRTS),
 
 	/* Port71 */
 	GPIO_FN(HSI_TX_DATA),
-	GPIO_FN(SCIFB1_CTS_71),
 	GPIO_FN(GIO_OUT2_71),
 	GPIO_FN(HSIC_TSTCLK1),
 	GPIO_FN(CHSCIF1_HCTS),
 
 	/* Port72 */
 	GPIO_FN(HSI_TX_WAKE),
-	GPIO_FN(SCIFB1_RXD_72),
 	GPIO_FN(GenIO8),
 	GPIO_FN(CHSCIF1_HRX),
 
 	/* Port73 */
 	GPIO_FN(HSI_TX_READY),
-	GPIO_FN(SCIFB2_RTS_73),
 	GPIO_FN(MSIOF3_SCK),
 	GPIO_FN(GIO_OUT0_73),
 
@@ -2398,36 +2368,28 @@ static const struct pinmux_func pinmux_func_gpios[] = {
 	GPIO_FN(IRQ49),
 
 	/* Port116 */
-	GPIO_FN(SCIFA0_TXD),
 	GPIO_FN(CSCIF0_TX),
 
 	/* Port117 */
-	GPIO_FN(SCIFA0_RXD),
 	GPIO_FN(CSCIF0_RX),
 
 	/* Port118 */
-	GPIO_FN(SCIFA1_TXD),
 	GPIO_FN(CSCIF1_TX),
 
 	/* Port119 */
-	GPIO_FN(SCIFA1_RXD),
 	GPIO_FN(CSCIF1_RX),
 
 	/* Port120 */
 	GPIO_FN(SF_PORT_1_120),
-	GPIO_FN(SCIFB3_RXD_120),
 	GPIO_FN(DU0_CDE),
 
 	/* Port121 */
 	GPIO_FN(SF_PORT_0_121),
-	GPIO_FN(SCIFB3_TXD_121),
 
 	/* Port122 */
-	GPIO_FN(SCIFB0_TXD),
 	GPIO_FN(CHSCIF0_HTX),
 
 	/* Port123 */
-	GPIO_FN(SCIFB0_RXD),
 	GPIO_FN(CHSCIF0_HRX),
 
 	/* Port124 */
@@ -2721,11 +2683,9 @@ static const struct pinmux_func pinmux_func_gpios[] = {
 	GPIO_FN(MSIOF0_TXD),
 
 	/* Port261 */
-	GPIO_FN(SCIFB1_SCK_261),
 	GPIO_FN(CHSCIF1_HSCK),
 
 	/* Port262 */
-	GPIO_FN(SCIFB2_SCK_262),
 
 	/* Port263 - Port266 FN1 */
 	GPIO_FN(MSIOF1_SS2),
@@ -2809,7 +2769,6 @@ static const struct pinmux_func pinmux_func_gpios[] = {
 	/* Port295 */
 	GPIO_FN(SDHID2_0),
 	GPIO_FN(MSIOF4_TXD),
-	GPIO_FN(SCIFB2_TXD_295),
 	GPIO_FN(MSIOF6_TXD),
 
 	/* Port296 */
@@ -2830,10 +2789,6 @@ static const struct pinmux_func pinmux_func_gpios[] = {
 	GPIO_FN(MSIOF4_SS1),
 
 	/* Port297 - Port300 FN3 */
-	GPIO_FN(SCIFB2_RXD_297),
-	GPIO_FN(SCIFB2_CTS_298),
-	GPIO_FN(SCIFB2_SCK_299),
-	GPIO_FN(SCIFB2_RTS_300),
 
 	/* Port297 - Port300 FN4 */
 	GPIO_FN(MSIOF6_RXD),
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 01:09:28 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue,  2 Apr 2013 14:09:28 +0900
Subject: [PATCH 20/28] sh-pfc: r8a73a4: Add SCIF pin groups and functions
In-Reply-To: <1364879376-10020-1-git-send-email-horms+renesas@verge.net.au>
References: <1364879376-10020-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364879376-10020-21-git-send-email-horms+renesas@verge.net.au>

From: Magnus Damm <damm at opensource.se>

Add PINCTRL support for r8a73a4 SCIF ports SCIFA0->SCIFA1 and
SCIFB0->SCIFB3.

Signed-off-by: Magnus Damm <damm at opensource.se>
Acked-by: Linus Walleij <linus.walleij at linaro.org>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 drivers/pinctrl/sh-pfc/pfc-r8a73a4.c |  287 ++++++++++++++++++++++++++++++++++
 1 file changed, 287 insertions(+)

diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a73a4.c b/drivers/pinctrl/sh-pfc/pfc-r8a73a4.c
index 86a5fd3..cd5c5fd 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a73a4.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a73a4.c
@@ -1576,6 +1576,286 @@ static const struct pinmux_range pinmux_ranges[] = {
 	{.begin = 320, .end = 329,},
 };
 
+/* - SCIFA0 ----------------------------------------------------------------- */
+static const unsigned int scifa0_data_pins[] = {
+	/* SCIFA0_RXD, SCIFA0_TXD */
+	117, 116,
+};
+static const unsigned int scifa0_data_mux[] = {
+	SCIFA0_RXD_MARK, SCIFA0_TXD_MARK,
+};
+static const unsigned int scifa0_clk_pins[] = {
+	/* SCIFA0_SCK */
+	34,
+};
+static const unsigned int scifa0_clk_mux[] = {
+	SCIFA0_SCK_MARK,
+};
+static const unsigned int scifa0_ctrl_pins[] = {
+	/* SCIFA0_RTS, SCIFA0_CTS */
+	32, 33,
+};
+static const unsigned int scifa0_ctrl_mux[] = {
+	SCIFA0_RTS_MARK, SCIFA0_CTS_MARK,
+};
+/* - SCIFA1 ----------------------------------------------------------------- */
+static const unsigned int scifa1_data_pins[] = {
+	/* SCIFA1_RXD, SCIFA1_TXD */
+	119, 118,
+};
+static const unsigned int scifa1_data_mux[] = {
+	SCIFA1_RXD_MARK, SCIFA1_TXD_MARK,
+};
+static const unsigned int scifa1_clk_pins[] = {
+	/* SCIFA1_SCK */
+	37,
+};
+static const unsigned int scifa1_clk_mux[] = {
+	SCIFA1_SCK_MARK,
+};
+static const unsigned int scifa1_ctrl_pins[] = {
+	/* SCIFA1_RTS, SCIFA1_CTS */
+	35, 36,
+};
+static const unsigned int scifa1_ctrl_mux[] = {
+	SCIFA1_RTS_MARK, SCIFA1_CTS_MARK,
+};
+/* - SCIFB0 ----------------------------------------------------------------- */
+static const unsigned int scifb0_data_pins[] = {
+	/* SCIFB0_RXD, SCIFB0_TXD */
+	123, 122,
+};
+static const unsigned int scifb0_data_mux[] = {
+	SCIFB0_RXD_MARK, SCIFB0_TXD_MARK,
+};
+static const unsigned int scifb0_clk_pins[] = {
+	/* SCIFB0_SCK */
+	40,
+};
+static const unsigned int scifb0_clk_mux[] = {
+	SCIFB0_SCK_MARK,
+};
+static const unsigned int scifb0_ctrl_pins[] = {
+	/* SCIFB0_RTS, SCIFB0_CTS */
+	38, 39,
+};
+static const unsigned int scifb0_ctrl_mux[] = {
+	SCIFB0_RTS_MARK, SCIFB0_CTS_MARK,
+};
+/* - SCIFB1 ----------------------------------------------------------------- */
+static const unsigned int scifb1_data_pins[] = {
+	/* SCIFB1_RXD, SCIFB1_TXD */
+	27, 26,
+};
+static const unsigned int scifb1_data_mux[] = {
+	SCIFB1_RXD_27_MARK, SCIFB1_TXD_26_MARK,
+};
+static const unsigned int scifb1_clk_pins[] = {
+	/* SCIFB1_SCK */
+	28,
+};
+static const unsigned int scifb1_clk_mux[] = {
+	SCIFB1_SCK_28_MARK,
+};
+static const unsigned int scifb1_ctrl_pins[] = {
+	/* SCIFB1_RTS, SCIFB1_CTS */
+	24, 25,
+};
+static const unsigned int scifb1_ctrl_mux[] = {
+	SCIFB1_RTS_24_MARK, SCIFB1_CTS_25_MARK,
+};
+static const unsigned int scifb1_data_b_pins[] = {
+	/* SCIFB1_RXD, SCIFB1_TXD */
+	72, 67,
+};
+static const unsigned int scifb1_data_b_mux[] = {
+	SCIFB1_RXD_72_MARK, SCIFB1_TXD_67_MARK,
+};
+static const unsigned int scifb1_clk_b_pins[] = {
+	/* SCIFB1_SCK */
+	261,
+};
+static const unsigned int scifb1_clk_b_mux[] = {
+	SCIFB1_SCK_261_MARK,
+};
+static const unsigned int scifb1_ctrl_b_pins[] = {
+	/* SCIFB1_RTS, SCIFB1_CTS */
+	70, 71,
+};
+static const unsigned int scifb1_ctrl_b_mux[] = {
+	SCIFB1_RTS_70_MARK, SCIFB1_CTS_71_MARK,
+};
+/* - SCIFB2 ----------------------------------------------------------------- */
+static const unsigned int scifb2_data_pins[] = {
+	/* SCIFB2_RXD, SCIFB2_TXD */
+	69, 68,
+};
+static const unsigned int scifb2_data_mux[] = {
+	SCIFB2_RXD_69_MARK, SCIFB2_TXD_68_MARK,
+};
+static const unsigned int scifb2_clk_pins[] = {
+	/* SCIFB2_SCK */
+	262,
+};
+static const unsigned int scifb2_clk_mux[] = {
+	SCIFB2_SCK_262_MARK,
+};
+static const unsigned int scifb2_ctrl_pins[] = {
+	/* SCIFB2_RTS, SCIFB2_CTS */
+	73, 66,
+};
+static const unsigned int scifb2_ctrl_mux[] = {
+	SCIFB2_RTS_73_MARK, SCIFB2_CTS_66_MARK,
+};
+static const unsigned int scifb2_data_b_pins[] = {
+	/* SCIFB2_RXD, SCIFB2_TXD */
+	297, 295,
+};
+static const unsigned int scifb2_data_b_mux[] = {
+	SCIFB2_RXD_297_MARK, SCIFB2_TXD_295_MARK,
+};
+static const unsigned int scifb2_clk_b_pins[] = {
+	/* SCIFB2_SCK */
+	299,
+};
+static const unsigned int scifb2_clk_b_mux[] = {
+	SCIFB2_SCK_299_MARK,
+};
+static const unsigned int scifb2_ctrl_b_pins[] = {
+	/* SCIFB2_RTS, SCIFB2_CTS */
+	300, 298,
+};
+static const unsigned int scifb2_ctrl_b_mux[] = {
+	SCIFB2_RTS_300_MARK, SCIFB2_CTS_298_MARK,
+};
+/* - SCIFB3 ----------------------------------------------------------------- */
+static const unsigned int scifb3_data_pins[] = {
+	/* SCIFB3_RXD, SCIFB3_TXD */
+	22, 21,
+};
+static const unsigned int scifb3_data_mux[] = {
+	SCIFB3_RXD_22_MARK, SCIFB3_TXD_21_MARK,
+};
+static const unsigned int scifb3_clk_pins[] = {
+	/* SCIFB3_SCK */
+	23,
+};
+static const unsigned int scifb3_clk_mux[] = {
+	SCIFB3_SCK_23_MARK,
+};
+static const unsigned int scifb3_ctrl_pins[] = {
+	/* SCIFB3_RTS, SCIFB3_CTS */
+	19, 20,
+};
+static const unsigned int scifb3_ctrl_mux[] = {
+	SCIFB3_RTS_19_MARK, SCIFB3_CTS_20_MARK,
+};
+static const unsigned int scifb3_data_b_pins[] = {
+	/* SCIFB3_RXD, SCIFB3_TXD */
+	120, 121,
+};
+static const unsigned int scifb3_data_b_mux[] = {
+	SCIFB3_RXD_120_MARK, SCIFB3_TXD_121_MARK,
+};
+static const unsigned int scifb3_clk_b_pins[] = {
+	/* SCIFB3_SCK */
+	40,
+};
+static const unsigned int scifb3_clk_b_mux[] = {
+	SCIFB3_SCK_40_MARK,
+};
+static const unsigned int scifb3_ctrl_b_pins[] = {
+	/* SCIFB3_RTS, SCIFB3_CTS */
+	38, 39,
+};
+static const unsigned int scifb3_ctrl_b_mux[] = {
+	SCIFB3_RTS_38_MARK, SCIFB3_CTS_39_MARK,
+};
+
+static const struct sh_pfc_pin_group pinmux_groups[] = {
+	SH_PFC_PIN_GROUP(scifa0_data),
+	SH_PFC_PIN_GROUP(scifa0_clk),
+	SH_PFC_PIN_GROUP(scifa0_ctrl),
+	SH_PFC_PIN_GROUP(scifa1_data),
+	SH_PFC_PIN_GROUP(scifa1_clk),
+	SH_PFC_PIN_GROUP(scifa1_ctrl),
+	SH_PFC_PIN_GROUP(scifb0_data),
+	SH_PFC_PIN_GROUP(scifb0_clk),
+	SH_PFC_PIN_GROUP(scifb0_ctrl),
+	SH_PFC_PIN_GROUP(scifb1_data),
+	SH_PFC_PIN_GROUP(scifb1_clk),
+	SH_PFC_PIN_GROUP(scifb1_ctrl),
+	SH_PFC_PIN_GROUP(scifb1_data_b),
+	SH_PFC_PIN_GROUP(scifb1_clk_b),
+	SH_PFC_PIN_GROUP(scifb1_ctrl_b),
+	SH_PFC_PIN_GROUP(scifb2_data),
+	SH_PFC_PIN_GROUP(scifb2_clk),
+	SH_PFC_PIN_GROUP(scifb2_ctrl),
+	SH_PFC_PIN_GROUP(scifb2_data_b),
+	SH_PFC_PIN_GROUP(scifb2_clk_b),
+	SH_PFC_PIN_GROUP(scifb2_ctrl_b),
+	SH_PFC_PIN_GROUP(scifb3_data),
+	SH_PFC_PIN_GROUP(scifb3_clk),
+	SH_PFC_PIN_GROUP(scifb3_ctrl),
+	SH_PFC_PIN_GROUP(scifb3_data_b),
+	SH_PFC_PIN_GROUP(scifb3_clk_b),
+	SH_PFC_PIN_GROUP(scifb3_ctrl_b),
+};
+
+static const char * const scifa0_groups[] = {
+	"scifa0_data",
+	"scifa0_clk",
+	"scifa0_ctrl",
+};
+
+static const char * const scifa1_groups[] = {
+	"scifa1_data",
+	"scifa1_clk",
+	"scifa1_ctrl",
+};
+
+static const char * const scifb0_groups[] = {
+	"scifb0_data",
+	"scifb0_clk",
+	"scifb0_ctrl",
+};
+
+static const char * const scifb1_groups[] = {
+	"scifb1_data",
+	"scifb1_clk",
+	"scifb1_ctrl",
+	"scifb1_data_b",
+	"scifb1_clk_b",
+	"scifb1_ctrl_b",
+};
+
+static const char * const scifb2_groups[] = {
+	"scifb2_data",
+	"scifb2_clk",
+	"scifb2_ctrl",
+	"scifb2_data_b",
+	"scifb2_clk_b",
+	"scifb2_ctrl_b",
+};
+
+static const char * const scifb3_groups[] = {
+	"scifb3_data",
+	"scifb3_clk",
+	"scifb3_ctrl",
+	"scifb3_data_b",
+	"scifb3_clk_b",
+	"scifb3_ctrl_b",
+};
+
+static const struct sh_pfc_function pinmux_functions[] = {
+	SH_PFC_FUNCTION(scifa0),
+	SH_PFC_FUNCTION(scifa1),
+	SH_PFC_FUNCTION(scifb0),
+	SH_PFC_FUNCTION(scifb1),
+	SH_PFC_FUNCTION(scifb2),
+	SH_PFC_FUNCTION(scifb3),
+};
+
 #define PINMUX_FN_BASE	ARRAY_SIZE(pinmux_pins)
 
 static const struct pinmux_func pinmux_func_gpios[] = {
@@ -3084,8 +3364,15 @@ const struct sh_pfc_soc_info r8a73a4_pinmux_info = {
 
 	.pins = pinmux_pins,
 	.nr_pins = ARRAY_SIZE(pinmux_pins),
+
 	.ranges = pinmux_ranges,
 	.nr_ranges = ARRAY_SIZE(pinmux_ranges),
+
+	.groups = pinmux_groups,
+	.nr_groups = ARRAY_SIZE(pinmux_groups),
+	.functions = pinmux_functions,
+	.nr_functions = ARRAY_SIZE(pinmux_functions),
+
 	.func_gpios = pinmux_func_gpios,
 	.nr_func_gpios = ARRAY_SIZE(pinmux_func_gpios),
 
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 01:09:31 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue,  2 Apr 2013 14:09:31 +0900
Subject: [PATCH 23/28] sh-pfc: r8a73a4: Remove IRQC function GPIOS
In-Reply-To: <1364879376-10020-1-git-send-email-horms+renesas@verge.net.au>
References: <1364879376-10020-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364879376-10020-24-git-send-email-horms+renesas@verge.net.au>

From: Magnus Damm <damm at opensource.se>

The r8a73a4 board support will use the pinctrl API to control the
external IRQ pins so remove the unused function GPIOS.

Signed-off-by: Magnus Damm <damm at opensource.se>
Acked-by: Linus Walleij <linus.walleij at linaro.org>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 drivers/pinctrl/sh-pfc/pfc-r8a73a4.c |   58 ----------------------------------
 1 file changed, 58 deletions(-)

diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a73a4.c b/drivers/pinctrl/sh-pfc/pfc-r8a73a4.c
index 470b18f..66fc747 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a73a4.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a73a4.c
@@ -2049,99 +2049,83 @@ static const struct pinmux_func pinmux_func_gpios[] = {
 	GPIO_FN(LCDD0),
 	GPIO_FN(PDM2_CLK_0),
 	GPIO_FN(DU0_DR0),
-	GPIO_FN(IRQ0),
 
 	/* Port1 */
 	GPIO_FN(LCDD1),
 	GPIO_FN(PDM2_DATA_1),
 	GPIO_FN(DU0_DR19),
-	GPIO_FN(IRQ1),
 
 	/* Port2 */
 	GPIO_FN(LCDD2),
 	GPIO_FN(PDM3_CLK_2),
 	GPIO_FN(DU0_DR2),
-	GPIO_FN(IRQ2),
 
 	/* Port3 */
 	GPIO_FN(LCDD3),
 	GPIO_FN(PDM3_DATA_3),
 	GPIO_FN(DU0_DR3),
-	GPIO_FN(IRQ3),
 
 	/* Port4 */
 	GPIO_FN(LCDD4),
 	GPIO_FN(PDM4_CLK_4),
 	GPIO_FN(DU0_DR4),
-	GPIO_FN(IRQ4),
 
 	/* Port5 */
 	GPIO_FN(LCDD5),
 	GPIO_FN(PDM4_DATA_5),
 	GPIO_FN(DU0_DR5),
-	GPIO_FN(IRQ5),
 
 	/* Port6 */
 	GPIO_FN(LCDD6),
 	GPIO_FN(PDM0_OUTCLK_6),
 	GPIO_FN(DU0_DR6),
-	GPIO_FN(IRQ6),
 
 	/* Port7 */
 	GPIO_FN(LCDD7),
 	GPIO_FN(PDM0_OUTDATA_7),
 	GPIO_FN(DU0_DR7),
-	GPIO_FN(IRQ7),
 
 	/* Port8 */
 	GPIO_FN(LCDD8),
 	GPIO_FN(PDM1_OUTCLK_8),
 	GPIO_FN(DU0_DG0),
-	GPIO_FN(IRQ8),
 
 	/* Port9 */
 	GPIO_FN(LCDD9),
 	GPIO_FN(PDM1_OUTDATA_9),
 	GPIO_FN(DU0_DG1),
-	GPIO_FN(IRQ9),
 
 	/* Port10 */
 	GPIO_FN(LCDD10),
 	GPIO_FN(FSICCK),
 	GPIO_FN(DU0_DG2),
-	GPIO_FN(IRQ10),
 
 	/* Port11 */
 	GPIO_FN(LCDD11),
 	GPIO_FN(FSICISLD),
 	GPIO_FN(DU0_DG3),
-	GPIO_FN(IRQ11),
 
 	/* Port12 */
 	GPIO_FN(LCDD12),
 	GPIO_FN(FSICOMC),
 	GPIO_FN(DU0_DG4),
-	GPIO_FN(IRQ12),
 
 	/* Port13 */
 	GPIO_FN(LCDD13),
 	GPIO_FN(FSICOLR),
 	GPIO_FN(FSICILR),
 	GPIO_FN(DU0_DG5),
-	GPIO_FN(IRQ13),
 
 	/* Port14 */
 	GPIO_FN(LCDD14),
 	GPIO_FN(FSICOBT),
 	GPIO_FN(FSICIBT),
 	GPIO_FN(DU0_DG6),
-	GPIO_FN(IRQ14),
 
 	/* Port15 */
 	GPIO_FN(LCDD15),
 	GPIO_FN(FSICOSLD),
 	GPIO_FN(DU0_DG7),
-	GPIO_FN(IRQ15),
 
 	/* Port16 */
 	GPIO_FN(LCDD16),
@@ -2254,7 +2238,6 @@ static const struct pinmux_func pinmux_func_gpios[] = {
 	GPIO_FN(HSI_RX_WAKE),
 	GPIO_FN(MSIOF3_SYNC),
 	GPIO_FN(GenIO4),
-	GPIO_FN(IRQ40),
 
 	/* Port67 */
 	GPIO_FN(HSI_RX_READY),
@@ -2304,8 +2287,6 @@ static const struct pinmux_func pinmux_func_gpios[] = {
 	GPIO_FN(TXP2),
 	GPIO_FN(COEX_0),
 	GPIO_FN(COEX_1),
-	GPIO_FN(IRQ19),
-	GPIO_FN(IRQ18),
 
 	/* Port96 - Port101 */
 	GPIO_FN(KEYIN0),
@@ -2317,11 +2298,9 @@ static const struct pinmux_func pinmux_func_gpios[] = {
 
 	/* Port102 */
 	GPIO_FN(KEYIN6),
-	GPIO_FN(IRQ41),
 
 	/* Port103 */
 	GPIO_FN(KEYIN7),
-	GPIO_FN(IRQ42),
 
 	/* Port104 - Port108 */
 	GPIO_FN(KEYOUT0),
@@ -2332,40 +2311,33 @@ static const struct pinmux_func pinmux_func_gpios[] = {
 
 	/* Port109 */
 	GPIO_FN(KEYOUT5),
-	GPIO_FN(IRQ43),
 
 	/* Port110 */
 	GPIO_FN(KEYOUT6),
-	GPIO_FN(IRQ44),
 
 	/* Port111 */
 	GPIO_FN(KEYOUT7),
 	GPIO_FN(RFANAEN),
-	GPIO_FN(IRQ45),
 
 	/* Port112 */
 	GPIO_FN(KEYIN8),
 	GPIO_FN(KEYOUT8),
 	GPIO_FN(SF_IRQ_04),
-	GPIO_FN(IRQ46),
 
 	/* Port113 */
 	GPIO_FN(KEYIN9),
 	GPIO_FN(KEYOUT9),
 	GPIO_FN(SF_IRQ_05),
-	GPIO_FN(IRQ47),
 
 	/* Port114 */
 	GPIO_FN(KEYIN10),
 	GPIO_FN(KEYOUT10),
 	GPIO_FN(SF_IRQ_06),
-	GPIO_FN(IRQ48),
 
 	/* Port115 */
 	GPIO_FN(KEYIN11),
 	GPIO_FN(KEYOUT11),
 	GPIO_FN(SF_IRQ_07),
-	GPIO_FN(IRQ49),
 
 	/* Port116 */
 	GPIO_FN(CSCIF0_TX),
@@ -2444,10 +2416,6 @@ static const struct pinmux_func pinmux_func_gpios[] = {
 	GPIO_FN(STP_ISD_1),
 
 	/* Port160 - Port178 */
-	GPIO_FN(IRQ20),
-	GPIO_FN(IRQ21),
-	GPIO_FN(IRQ22),
-	GPIO_FN(IRQ23),
 	GPIO_FN(MMCD0_0),
 	GPIO_FN(MMCD0_1),
 	GPIO_FN(MMCD0_2),
@@ -2459,10 +2427,6 @@ static const struct pinmux_func pinmux_func_gpios[] = {
 	GPIO_FN(MMCCMD0),
 	GPIO_FN(MMCCLK0),
 	GPIO_FN(MMCRST),
-	GPIO_FN(IRQ24),
-	GPIO_FN(IRQ25),
-	GPIO_FN(IRQ26),
-	GPIO_FN(IRQ27),
 
 	/* Port192 - Port200 FN1 */
 	GPIO_FN(A10),
@@ -2487,15 +2451,6 @@ static const struct pinmux_func pinmux_func_gpios[] = {
 	GPIO_FN(MMCCMD1),
 
 	/* Port192 - Port200 IRQ */
-	GPIO_FN(IRQ31),
-	GPIO_FN(IRQ32),
-	GPIO_FN(IRQ33),
-	GPIO_FN(IRQ34),
-	GPIO_FN(IRQ35),
-	GPIO_FN(IRQ36),
-	GPIO_FN(IRQ37),
-	GPIO_FN(IRQ38),
-	GPIO_FN(IRQ39),
 
 	/* Port201 */
 	GPIO_FN(A1),
@@ -2752,7 +2707,6 @@ static const struct pinmux_func pinmux_func_gpios[] = {
 	/* Port290 */
 	GPIO_FN(SDHID1_1),
 	GPIO_FN(STMDATA1_2),
-	GPIO_FN(IRQ51),
 
 	/* Port291 - Port294 FN1 */
 	GPIO_FN(SDHID1_2),
@@ -2774,7 +2728,6 @@ static const struct pinmux_func pinmux_func_gpios[] = {
 	/* Port296 */
 	GPIO_FN(SDHID2_1),
 	GPIO_FN(MSIOF6_SS2),
-	GPIO_FN(IRQ52),
 
 	/* Port297 - Port300 FN1 */
 	GPIO_FN(SDHID2_2),
@@ -2798,7 +2751,6 @@ static const struct pinmux_func pinmux_func_gpios[] = {
 
 	/* Port301 */
 	GPIO_FN(SDHICD0),
-	GPIO_FN(IRQ50),
 
 	/* Port302 - Port306 FN1 */
 	GPIO_FN(SDHID0_0),
@@ -2822,16 +2774,6 @@ static const struct pinmux_func pinmux_func_gpios[] = {
 	GPIO_FN(STMCLK_1),
 
 	/* Port320 - Port329 */
-	GPIO_FN(IRQ16),
-	GPIO_FN(IRQ17),
-	GPIO_FN(IRQ28),
-	GPIO_FN(IRQ29),
-	GPIO_FN(IRQ30),
-	GPIO_FN(IRQ53),
-	GPIO_FN(IRQ54),
-	GPIO_FN(IRQ55),
-	GPIO_FN(IRQ56),
-	GPIO_FN(IRQ57),
 };
 
 static const struct pinmux_cfg_reg pinmux_config_regs[] = {
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 01:09:27 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue,  2 Apr 2013 14:09:27 +0900
Subject: [PATCH 19/28] sh-pfc: r8a73a4: Add bias (pull-up/down) pinconf support
In-Reply-To: <1364879376-10020-1-git-send-email-horms+renesas@verge.net.au>
References: <1364879376-10020-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364879376-10020-20-git-send-email-horms+renesas@verge.net.au>

From: Magnus Damm <damm at opensource.se>

Implement pull-up/down support for r8a73a4 similar to the implementation
for sh73a0.

Signed-off-by: Magnus Damm <damm at opensource.se>
Acked-by: Linus Walleij <linus.walleij at linaro.org>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 drivers/pinctrl/sh-pfc/pfc-r8a73a4.c |  197 +++++++++++++++++++++++++++++++++-
 1 file changed, 196 insertions(+), 1 deletion(-)

diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a73a4.c b/drivers/pinctrl/sh-pfc/pfc-r8a73a4.c
index 0177329..86a5fd3 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a73a4.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a73a4.c
@@ -17,10 +17,13 @@
  * along with this program; if not, write to the Free Software
  * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
  */
+#include <linux/io.h>
 #include <linux/kernel.h>
+#include <linux/pinctrl/pinconf-generic.h>
 #include <mach/irqs.h>
 #include <mach/r8a73a4.h>
 
+#include "core.h"
 #include "sh_pfc.h"
 
 #define CPU_ALL_PORT(fn, pfx, sfx)					\
@@ -1420,8 +1423,143 @@ static const pinmux_enum_t pinmux_data[] = {
 	PINMUX_DATA(IRQ57_MARK,			PORT329_FN0),
 };
 
+#define R8A73A4_PIN(pin, cfgs)			\
+	{					\
+		.name = __stringify(PORT##pin),	\
+		.enum_id = PORT##pin##_DATA,	\
+		.configs = cfgs,		\
+	}
+
+#define __O	(SH_PFC_PIN_CFG_OUTPUT)
+#define __IO	(SH_PFC_PIN_CFG_INPUT | SH_PFC_PIN_CFG_OUTPUT)
+#define __PUD	(SH_PFC_PIN_CFG_PULL_DOWN | SH_PFC_PIN_CFG_PULL_UP)
+
+#define R8A73A4_PIN_IO_PU_PD(pin)       R8A73A4_PIN(pin, __IO | __PUD)
+#define R8A73A4_PIN_O(pin)              R8A73A4_PIN(pin, __O)
+
 static struct sh_pfc_pin pinmux_pins[] = {
-	GPIO_PORT_ALL(),
+	R8A73A4_PIN_IO_PU_PD(0), R8A73A4_PIN_IO_PU_PD(1),
+	R8A73A4_PIN_IO_PU_PD(2), R8A73A4_PIN_IO_PU_PD(3),
+	R8A73A4_PIN_IO_PU_PD(4), R8A73A4_PIN_IO_PU_PD(5),
+	R8A73A4_PIN_IO_PU_PD(6), R8A73A4_PIN_IO_PU_PD(7),
+	R8A73A4_PIN_IO_PU_PD(8), R8A73A4_PIN_IO_PU_PD(9),
+	R8A73A4_PIN_IO_PU_PD(10), R8A73A4_PIN_IO_PU_PD(11),
+	R8A73A4_PIN_IO_PU_PD(12), R8A73A4_PIN_IO_PU_PD(13),
+	R8A73A4_PIN_IO_PU_PD(14), R8A73A4_PIN_IO_PU_PD(15),
+	R8A73A4_PIN_IO_PU_PD(16), R8A73A4_PIN_IO_PU_PD(17),
+	R8A73A4_PIN_IO_PU_PD(18), R8A73A4_PIN_IO_PU_PD(19),
+	R8A73A4_PIN_IO_PU_PD(20), R8A73A4_PIN_IO_PU_PD(21),
+	R8A73A4_PIN_IO_PU_PD(22), R8A73A4_PIN_IO_PU_PD(23),
+	R8A73A4_PIN_IO_PU_PD(24), R8A73A4_PIN_IO_PU_PD(25),
+	R8A73A4_PIN_IO_PU_PD(26), R8A73A4_PIN_IO_PU_PD(27),
+	R8A73A4_PIN_IO_PU_PD(28), R8A73A4_PIN_IO_PU_PD(29),
+	R8A73A4_PIN_IO_PU_PD(30),
+	R8A73A4_PIN_IO_PU_PD(32), R8A73A4_PIN_IO_PU_PD(33),
+	R8A73A4_PIN_IO_PU_PD(34), R8A73A4_PIN_IO_PU_PD(35),
+	R8A73A4_PIN_IO_PU_PD(36), R8A73A4_PIN_IO_PU_PD(37),
+	R8A73A4_PIN_IO_PU_PD(38), R8A73A4_PIN_IO_PU_PD(39),
+	R8A73A4_PIN_IO_PU_PD(40),
+	R8A73A4_PIN_IO_PU_PD(64), R8A73A4_PIN_IO_PU_PD(65),
+	R8A73A4_PIN_IO_PU_PD(66), R8A73A4_PIN_IO_PU_PD(67),
+	R8A73A4_PIN_IO_PU_PD(68), R8A73A4_PIN_IO_PU_PD(69),
+	R8A73A4_PIN_IO_PU_PD(70), R8A73A4_PIN_IO_PU_PD(71),
+	R8A73A4_PIN_IO_PU_PD(72), R8A73A4_PIN_IO_PU_PD(73),
+	R8A73A4_PIN_O(74), R8A73A4_PIN_IO_PU_PD(75),
+	R8A73A4_PIN_IO_PU_PD(76), R8A73A4_PIN_IO_PU_PD(77),
+	R8A73A4_PIN_IO_PU_PD(78), R8A73A4_PIN_IO_PU_PD(79),
+	R8A73A4_PIN_IO_PU_PD(80), R8A73A4_PIN_IO_PU_PD(81),
+	R8A73A4_PIN_IO_PU_PD(82), R8A73A4_PIN_IO_PU_PD(83),
+	R8A73A4_PIN_IO_PU_PD(84), R8A73A4_PIN_IO_PU_PD(85),
+	R8A73A4_PIN_IO_PU_PD(96), R8A73A4_PIN_IO_PU_PD(97),
+	R8A73A4_PIN_IO_PU_PD(98), R8A73A4_PIN_IO_PU_PD(99),
+	R8A73A4_PIN_IO_PU_PD(100), R8A73A4_PIN_IO_PU_PD(101),
+	R8A73A4_PIN_IO_PU_PD(102), R8A73A4_PIN_IO_PU_PD(103),
+	R8A73A4_PIN_IO_PU_PD(104), R8A73A4_PIN_IO_PU_PD(105),
+	R8A73A4_PIN_IO_PU_PD(106), R8A73A4_PIN_IO_PU_PD(107),
+	R8A73A4_PIN_IO_PU_PD(108), R8A73A4_PIN_IO_PU_PD(109),
+	R8A73A4_PIN_IO_PU_PD(110), R8A73A4_PIN_IO_PU_PD(111),
+	R8A73A4_PIN_IO_PU_PD(112), R8A73A4_PIN_IO_PU_PD(113),
+	R8A73A4_PIN_IO_PU_PD(114), R8A73A4_PIN_IO_PU_PD(115),
+	R8A73A4_PIN_IO_PU_PD(116), R8A73A4_PIN_IO_PU_PD(117),
+	R8A73A4_PIN_IO_PU_PD(118), R8A73A4_PIN_IO_PU_PD(119),
+	R8A73A4_PIN_IO_PU_PD(120), R8A73A4_PIN_IO_PU_PD(121),
+	R8A73A4_PIN_IO_PU_PD(122), R8A73A4_PIN_IO_PU_PD(123),
+	R8A73A4_PIN_IO_PU_PD(124), R8A73A4_PIN_IO_PU_PD(125),
+	R8A73A4_PIN_IO_PU_PD(126),
+	R8A73A4_PIN_IO_PU_PD(128), R8A73A4_PIN_IO_PU_PD(129),
+	R8A73A4_PIN_IO_PU_PD(130), R8A73A4_PIN_IO_PU_PD(131),
+	R8A73A4_PIN_IO_PU_PD(132), R8A73A4_PIN_IO_PU_PD(133),
+	R8A73A4_PIN_IO_PU_PD(134),
+	R8A73A4_PIN_IO_PU_PD(160), R8A73A4_PIN_IO_PU_PD(161),
+	R8A73A4_PIN_IO_PU_PD(162), R8A73A4_PIN_IO_PU_PD(163),
+	R8A73A4_PIN_IO_PU_PD(164), R8A73A4_PIN_IO_PU_PD(165),
+	R8A73A4_PIN_IO_PU_PD(166), R8A73A4_PIN_IO_PU_PD(167),
+	R8A73A4_PIN_IO_PU_PD(168), R8A73A4_PIN_IO_PU_PD(169),
+	R8A73A4_PIN_IO_PU_PD(170), R8A73A4_PIN_IO_PU_PD(171),
+	R8A73A4_PIN_IO_PU_PD(172), R8A73A4_PIN_IO_PU_PD(173),
+	R8A73A4_PIN_IO_PU_PD(174), R8A73A4_PIN_IO_PU_PD(175),
+	R8A73A4_PIN_IO_PU_PD(176), R8A73A4_PIN_IO_PU_PD(177),
+	R8A73A4_PIN_IO_PU_PD(178),
+	R8A73A4_PIN_IO_PU_PD(192), R8A73A4_PIN_IO_PU_PD(193),
+	R8A73A4_PIN_IO_PU_PD(194), R8A73A4_PIN_IO_PU_PD(195),
+	R8A73A4_PIN_IO_PU_PD(196), R8A73A4_PIN_IO_PU_PD(197),
+	R8A73A4_PIN_IO_PU_PD(198), R8A73A4_PIN_IO_PU_PD(199),
+	R8A73A4_PIN_IO_PU_PD(200), R8A73A4_PIN_IO_PU_PD(201),
+	R8A73A4_PIN_IO_PU_PD(202), R8A73A4_PIN_IO_PU_PD(203),
+	R8A73A4_PIN_IO_PU_PD(204), R8A73A4_PIN_IO_PU_PD(205),
+	R8A73A4_PIN_IO_PU_PD(206), R8A73A4_PIN_IO_PU_PD(207),
+	R8A73A4_PIN_IO_PU_PD(208), R8A73A4_PIN_IO_PU_PD(209),
+	R8A73A4_PIN_IO_PU_PD(210), R8A73A4_PIN_IO_PU_PD(211),
+	R8A73A4_PIN_IO_PU_PD(212), R8A73A4_PIN_IO_PU_PD(213),
+	R8A73A4_PIN_IO_PU_PD(214), R8A73A4_PIN_IO_PU_PD(215),
+	R8A73A4_PIN_IO_PU_PD(216), R8A73A4_PIN_IO_PU_PD(217),
+	R8A73A4_PIN_IO_PU_PD(218), R8A73A4_PIN_IO_PU_PD(219),
+	R8A73A4_PIN_IO_PU_PD(220), R8A73A4_PIN_IO_PU_PD(221),
+	R8A73A4_PIN_IO_PU_PD(222),
+	R8A73A4_PIN_IO_PU_PD(224), R8A73A4_PIN_IO_PU_PD(225),
+	R8A73A4_PIN_IO_PU_PD(226), R8A73A4_PIN_IO_PU_PD(227),
+	R8A73A4_PIN_IO_PU_PD(228), R8A73A4_PIN_IO_PU_PD(229),
+	R8A73A4_PIN_IO_PU_PD(230), R8A73A4_PIN_IO_PU_PD(231),
+	R8A73A4_PIN_IO_PU_PD(232), R8A73A4_PIN_IO_PU_PD(233),
+	R8A73A4_PIN_IO_PU_PD(234), R8A73A4_PIN_IO_PU_PD(235),
+	R8A73A4_PIN_IO_PU_PD(236), R8A73A4_PIN_IO_PU_PD(237),
+	R8A73A4_PIN_IO_PU_PD(238), R8A73A4_PIN_IO_PU_PD(239),
+	R8A73A4_PIN_IO_PU_PD(240), R8A73A4_PIN_IO_PU_PD(241),
+	R8A73A4_PIN_IO_PU_PD(242), R8A73A4_PIN_IO_PU_PD(243),
+	R8A73A4_PIN_IO_PU_PD(244), R8A73A4_PIN_IO_PU_PD(245),
+	R8A73A4_PIN_IO_PU_PD(246), R8A73A4_PIN_IO_PU_PD(247),
+	R8A73A4_PIN_IO_PU_PD(248), R8A73A4_PIN_IO_PU_PD(249),
+	R8A73A4_PIN_IO_PU_PD(250),
+	R8A73A4_PIN_IO_PU_PD(256), R8A73A4_PIN_IO_PU_PD(257),
+	R8A73A4_PIN_IO_PU_PD(258), R8A73A4_PIN_IO_PU_PD(259),
+	R8A73A4_PIN_IO_PU_PD(260), R8A73A4_PIN_IO_PU_PD(261),
+	R8A73A4_PIN_IO_PU_PD(262), R8A73A4_PIN_IO_PU_PD(263),
+	R8A73A4_PIN_IO_PU_PD(264), R8A73A4_PIN_IO_PU_PD(265),
+	R8A73A4_PIN_IO_PU_PD(266), R8A73A4_PIN_IO_PU_PD(267),
+	R8A73A4_PIN_IO_PU_PD(268), R8A73A4_PIN_IO_PU_PD(269),
+	R8A73A4_PIN_IO_PU_PD(270), R8A73A4_PIN_IO_PU_PD(271),
+	R8A73A4_PIN_IO_PU_PD(272), R8A73A4_PIN_IO_PU_PD(273),
+	R8A73A4_PIN_IO_PU_PD(274), R8A73A4_PIN_IO_PU_PD(275),
+	R8A73A4_PIN_IO_PU_PD(276), R8A73A4_PIN_IO_PU_PD(277),
+	R8A73A4_PIN_IO_PU_PD(278), R8A73A4_PIN_IO_PU_PD(279),
+	R8A73A4_PIN_IO_PU_PD(280), R8A73A4_PIN_IO_PU_PD(281),
+	R8A73A4_PIN_IO_PU_PD(282), R8A73A4_PIN_IO_PU_PD(283),
+	R8A73A4_PIN_O(288), R8A73A4_PIN_IO_PU_PD(289),
+	R8A73A4_PIN_IO_PU_PD(290), R8A73A4_PIN_IO_PU_PD(291),
+	R8A73A4_PIN_IO_PU_PD(292), R8A73A4_PIN_IO_PU_PD(293),
+	R8A73A4_PIN_IO_PU_PD(294), R8A73A4_PIN_IO_PU_PD(295),
+	R8A73A4_PIN_IO_PU_PD(296), R8A73A4_PIN_IO_PU_PD(297),
+	R8A73A4_PIN_IO_PU_PD(298), R8A73A4_PIN_IO_PU_PD(299),
+	R8A73A4_PIN_IO_PU_PD(300), R8A73A4_PIN_IO_PU_PD(301),
+	R8A73A4_PIN_IO_PU_PD(302), R8A73A4_PIN_IO_PU_PD(303),
+	R8A73A4_PIN_IO_PU_PD(304), R8A73A4_PIN_IO_PU_PD(305),
+	R8A73A4_PIN_IO_PU_PD(306), R8A73A4_PIN_IO_PU_PD(307),
+	R8A73A4_PIN_IO_PU_PD(308),
+	R8A73A4_PIN_IO_PU_PD(320), R8A73A4_PIN_IO_PU_PD(321),
+	R8A73A4_PIN_IO_PU_PD(322), R8A73A4_PIN_IO_PU_PD(323),
+	R8A73A4_PIN_IO_PU_PD(324), R8A73A4_PIN_IO_PU_PD(325),
+	R8A73A4_PIN_IO_PU_PD(326), R8A73A4_PIN_IO_PU_PD(327),
+	R8A73A4_PIN_IO_PU_PD(328), R8A73A4_PIN_IO_PU_PD(329),
 };
 
 static const struct pinmux_range pinmux_ranges[] = {
@@ -2878,8 +3016,65 @@ static const struct pinmux_irq pinmux_irqs[] = {
 	PINMUX_IRQ(irq_pin(56), 328),
 	PINMUX_IRQ(irq_pin(57), 329),
 };
+
+#define PORTCR_PULMD_OFF (0 << 6)
+#define PORTCR_PULMD_DOWN (2 << 6)
+#define PORTCR_PULMD_UP (3 << 6)
+#define PORTCR_PULMD_MASK (3 << 6)
+
+static const unsigned int r8a73a4_portcr_offsets[] = {
+	0x00000000, 0x00001000, 0x00000000, 0x00001000,
+	0x00001000, 0x00002000, 0x00002000, 0x00002000,
+	0x00002000, 0x00003000, 0x00003000,
+};
+
+static unsigned int r8a73a4_pinmux_get_bias(struct sh_pfc *pfc,
+					    unsigned int pin)
+{
+	void __iomem *addr;
+
+	addr = pfc->window->virt + r8a73a4_portcr_offsets[pin >> 5] + pin;
+
+	switch (ioread8(addr) & PORTCR_PULMD_MASK) {
+	case PORTCR_PULMD_UP:
+		return PIN_CONFIG_BIAS_PULL_UP;
+	case PORTCR_PULMD_DOWN:
+		return PIN_CONFIG_BIAS_PULL_DOWN;
+	case PORTCR_PULMD_OFF:
+	default:
+		return PIN_CONFIG_BIAS_DISABLE;
+	}
+}
+
+static void r8a73a4_pinmux_set_bias(struct sh_pfc *pfc, unsigned int pin,
+				   unsigned int bias)
+{
+	void __iomem *addr;
+	u32 value;
+
+	addr = pfc->window->virt + r8a73a4_portcr_offsets[pin >> 5] + pin;
+	value = ioread8(addr) & ~PORTCR_PULMD_MASK;
+
+	switch (bias) {
+	case PIN_CONFIG_BIAS_PULL_UP:
+		value |= PORTCR_PULMD_UP;
+		break;
+	case PIN_CONFIG_BIAS_PULL_DOWN:
+		value |= PORTCR_PULMD_DOWN;
+		break;
+	}
+
+	iowrite8(value, addr);
+}
+
+static const struct sh_pfc_soc_operations r8a73a4_pinmux_ops = {
+	.get_bias = r8a73a4_pinmux_get_bias,
+	.set_bias = r8a73a4_pinmux_set_bias,
+};
+
 const struct sh_pfc_soc_info r8a73a4_pinmux_info = {
 	.name		= "r8a73a4_pfc",
+	.ops		= &r8a73a4_pinmux_ops,
 
 	.input = { PINMUX_INPUT_BEGIN, PINMUX_INPUT_END },
 	.input_pu = { PINMUX_INPUT_PULLUP_BEGIN, PINMUX_INPUT_PULLUP_END },
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 01:09:36 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue,  2 Apr 2013 14:09:36 +0900
Subject: [PATCH 28/28] sh-pfc: r8a73a4: Remove unused GPIO bias data
In-Reply-To: <1364879376-10020-1-git-send-email-horms+renesas@verge.net.au>
References: <1364879376-10020-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364879376-10020-29-git-send-email-horms+renesas@verge.net.au>

From: Magnus Damm <damm at opensource.se>

Remove unused pull-up/down data from the r8a73a4 PFC code.

Signed-off-by: Magnus Damm <damm at opensource.se>
Acked-by: Linus Walleij <linus.walleij at linaro.org>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 drivers/pinctrl/sh-pfc/pfc-r8a73a4.c |  176 +++-------------------------------
 1 file changed, 15 insertions(+), 161 deletions(-)

diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a73a4.c b/drivers/pinctrl/sh-pfc/pfc-r8a73a4.c
index 464c5f9..bbff559 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a73a4.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a73a4.c
@@ -115,16 +115,6 @@ enum {
 	PORT_ALL(IN),
 	PINMUX_INPUT_END,
 
-	/* PORT0_IN_PU -> PORT329_IN_PU */
-	PINMUX_INPUT_PULLUP_BEGIN,
-	PORT_ALL(IN_PU),
-	PINMUX_INPUT_PULLUP_END,
-
-	/* PORT0_IN_PD -> PORT329_IN_PD */
-	PINMUX_INPUT_PULLDOWN_BEGIN,
-	PORT_ALL(IN_PD),
-	PINMUX_INPUT_PULLDOWN_END,
-
 	/* PORT0_OUT -> PORT329_OUT */
 	PINMUX_OUTPUT_BEGIN,
 	PORT_ALL(OUT),
@@ -438,156 +428,12 @@ enum {
 	PINMUX_MARK_END,
 };
 
+#define _PORT_DATA(pfx, sfx)	PORT_DATA_IO(pfx)
+#define PINMUX_DATA_ALL()    CPU_ALL_PORT(_PORT_DATA, , unused)
+
 static const pinmux_enum_t pinmux_data[] = {
 	/* specify valid pin states for each pin in GPIO mode */
-
-	PORT_DATA_IO_PU_PD(0), PORT_DATA_IO_PU_PD(1),
-	PORT_DATA_IO_PU_PD(2), PORT_DATA_IO_PU_PD(3),
-	PORT_DATA_IO_PU_PD(4), PORT_DATA_IO_PU_PD(5),
-	PORT_DATA_IO_PU_PD(6), PORT_DATA_IO_PU_PD(7),
-	PORT_DATA_IO_PU_PD(8), PORT_DATA_IO_PU_PD(9),
-
-	PORT_DATA_IO_PU_PD(10), PORT_DATA_IO_PU_PD(11),
-	PORT_DATA_IO_PU_PD(12), PORT_DATA_IO_PU_PD(13),
-	PORT_DATA_IO_PU_PD(14),	PORT_DATA_IO_PU_PD(15),
-	PORT_DATA_IO_PU_PD(16), PORT_DATA_IO_PU_PD(17),
-	PORT_DATA_IO_PU_PD(18), PORT_DATA_IO_PU_PD(19),
-
-	PORT_DATA_IO_PU_PD(20), PORT_DATA_IO_PU_PD(21),
-	PORT_DATA_IO_PU_PD(22), PORT_DATA_IO_PU_PD(23),
-	PORT_DATA_IO_PU_PD(24),	PORT_DATA_IO_PU_PD(25),
-	PORT_DATA_IO_PU_PD(26), PORT_DATA_IO_PU_PD(27),
-	PORT_DATA_IO_PU_PD(28), PORT_DATA_IO_PU_PD(29),
-
-	PORT_DATA_IO_PU_PD(30), PORT_DATA_IO_PU_PD(32),
-	PORT_DATA_IO_PU_PD(33), PORT_DATA_IO_PU_PD(34),
-	PORT_DATA_IO_PU_PD(35), PORT_DATA_IO_PU_PD(36),
-	PORT_DATA_IO_PU_PD(37), PORT_DATA_IO_PU_PD(38),
-	PORT_DATA_IO_PU_PD(39), PORT_DATA_IO_PU_PD(40),
-
-	PORT_DATA_IO_PU_PD(64),	PORT_DATA_IO_PU_PD(65),
-	PORT_DATA_IO_PU_PD(66), PORT_DATA_IO_PU_PD(67),
-	PORT_DATA_IO_PU_PD(68), PORT_DATA_IO_PU_PD(69),
-
-	PORT_DATA_IO_PU_PD(70), PORT_DATA_IO_PU_PD(71),
-	PORT_DATA_IO_PU_PD(72), PORT_DATA_IO_PU_PD(73),
-	PORT_DATA_O(74), PORT_DATA_IO_PU_PD(75),
-	PORT_DATA_IO_PU_PD(76), PORT_DATA_IO_PU_PD(77),
-	PORT_DATA_IO_PU_PD(78), PORT_DATA_IO_PU_PD(79),
-
-	PORT_DATA_IO_PU_PD(80), PORT_DATA_IO_PU_PD(81),
-	PORT_DATA_IO_PU_PD(82), PORT_DATA_IO_PU_PD(83),
-	PORT_DATA_IO_PU_PD(84), PORT_DATA_IO_PU_PD(85),
-
-	PORT_DATA_IO_PU_PD(96), PORT_DATA_IO_PU_PD(97),
-	PORT_DATA_IO_PU_PD(98), PORT_DATA_IO_PU_PD(99),
-
-	PORT_DATA_IO_PU_PD(100), PORT_DATA_IO_PU_PD(101),
-	PORT_DATA_IO_PU_PD(102), PORT_DATA_IO_PU_PD(103),
-	PORT_DATA_IO_PU_PD(104), PORT_DATA_IO_PU_PD(105),
-	PORT_DATA_IO_PU_PD(106), PORT_DATA_IO_PU_PD(107),
-	PORT_DATA_IO_PU_PD(108), PORT_DATA_IO_PU_PD(109),
-
-	PORT_DATA_IO_PU_PD(110), PORT_DATA_IO_PU_PD(111),
-	PORT_DATA_IO_PU_PD(112), PORT_DATA_IO_PU_PD(113),
-	PORT_DATA_IO_PU_PD(114), PORT_DATA_IO_PU_PD(115),
-	PORT_DATA_IO_PU_PD(116), PORT_DATA_IO_PU_PD(117),
-	PORT_DATA_IO_PU_PD(118), PORT_DATA_IO_PU_PD(119),
-
-	PORT_DATA_IO_PU_PD(120), PORT_DATA_IO_PU_PD(121),
-	PORT_DATA_IO_PU_PD(122), PORT_DATA_IO_PU_PD(123),
-	PORT_DATA_IO_PU_PD(124), PORT_DATA_IO_PU_PD(125),
-	PORT_DATA_IO_PU_PD(126),
-	PORT_DATA_IO_PU_PD(128), PORT_DATA_IO_PU_PD(129),
-
-	PORT_DATA_IO_PU_PD(130), PORT_DATA_IO_PU_PD(131),
-	PORT_DATA_IO_PU_PD(132), PORT_DATA_IO_PU_PD(133),
-	PORT_DATA_IO_PU_PD(134),
-
-	PORT_DATA_IO_PU_PD(160), PORT_DATA_IO_PU_PD(161),
-	PORT_DATA_IO_PU_PD(162), PORT_DATA_IO_PU_PD(163),
-	PORT_DATA_IO_PU_PD(164), PORT_DATA_IO_PU_PD(165),
-	PORT_DATA_IO_PU_PD(166), PORT_DATA_IO_PU_PD(167),
-	PORT_DATA_IO_PU_PD(168), PORT_DATA_IO_PU_PD(169),
-
-	PORT_DATA_IO_PU_PD(170), PORT_DATA_IO_PU_PD(171),
-	PORT_DATA_IO_PU_PD(172), PORT_DATA_IO_PU_PD(173),
-	PORT_DATA_IO_PU_PD(174), PORT_DATA_IO_PU_PD(175),
-	PORT_DATA_IO_PU_PD(176), PORT_DATA_IO_PU_PD(177),
-	PORT_DATA_IO_PU_PD(178),
-
-	PORT_DATA_IO_PU_PD(192), PORT_DATA_IO_PU_PD(193),
-	PORT_DATA_IO_PU_PD(194), PORT_DATA_IO_PU_PD(195),
-	PORT_DATA_IO_PU_PD(196), PORT_DATA_IO_PU_PD(197),
-	PORT_DATA_IO_PU_PD(198), PORT_DATA_IO_PU_PD(199),
-
-	PORT_DATA_IO_PU_PD(200), PORT_DATA_IO_PU_PD(201),
-	PORT_DATA_IO_PU_PD(202), PORT_DATA_IO_PU_PD(203),
-	PORT_DATA_IO_PU_PD(204), PORT_DATA_IO_PU_PD(205),
-	PORT_DATA_IO_PU_PD(206), PORT_DATA_IO_PU_PD(207),
-	PORT_DATA_IO_PU_PD(208), PORT_DATA_IO_PU_PD(209),
-
-	PORT_DATA_IO_PU_PD(210), PORT_DATA_IO_PU_PD(211),
-	PORT_DATA_IO_PU_PD(212), PORT_DATA_IO_PU_PD(213),
-	PORT_DATA_IO_PU_PD(214), PORT_DATA_IO_PU_PD(215),
-	PORT_DATA_IO_PU_PD(216), PORT_DATA_IO_PU_PD(217),
-	PORT_DATA_IO_PU_PD(218), PORT_DATA_IO_PU_PD(219),
-
-	PORT_DATA_IO_PU_PD(220), PORT_DATA_IO_PU_PD(221),
-	PORT_DATA_IO_PU_PD(222), PORT_DATA_IO_PU_PD(224),
-	PORT_DATA_IO_PU_PD(225), PORT_DATA_IO_PU_PD(226),
-	PORT_DATA_IO_PU_PD(227), PORT_DATA_IO_PU_PD(228),
-	PORT_DATA_IO_PU_PD(229),
-
-	PORT_DATA_IO_PU_PD(230), PORT_DATA_IO_PU_PD(231),
-	PORT_DATA_IO_PU_PD(232), PORT_DATA_IO_PU_PD(233),
-	PORT_DATA_IO_PU_PD(234), PORT_DATA_IO_PU_PD(235),
-	PORT_DATA_IO_PU_PD(236), PORT_DATA_IO_PU_PD(237),
-	PORT_DATA_IO_PU_PD(238), PORT_DATA_IO_PU_PD(239),
-
-	PORT_DATA_IO_PU_PD(240), PORT_DATA_IO_PU_PD(241),
-	PORT_DATA_IO_PU_PD(242), PORT_DATA_IO_PU_PD(243),
-	PORT_DATA_IO_PU_PD(244), PORT_DATA_IO_PU_PD(245),
-	PORT_DATA_IO_PU_PD(246), PORT_DATA_IO_PU_PD(247),
-	PORT_DATA_IO_PU_PD(248), PORT_DATA_IO_PU_PD(249),
-
-	PORT_DATA_IO_PU_PD(250),
-	PORT_DATA_IO_PU_PD(256), PORT_DATA_IO_PU_PD(257),
-	PORT_DATA_IO_PU_PD(258), PORT_DATA_IO_PU_PD(259),
-
-	PORT_DATA_IO_PU_PD(260), PORT_DATA_IO_PU_PD(261),
-	PORT_DATA_IO_PU_PD(262), PORT_DATA_IO_PU_PD(263),
-	PORT_DATA_IO_PU_PD(264), PORT_DATA_IO_PU_PD(265),
-	PORT_DATA_IO_PU_PD(266), PORT_DATA_IO_PU_PD(267),
-	PORT_DATA_IO_PU_PD(268), PORT_DATA_IO_PU_PD(269),
-
-	PORT_DATA_IO_PU_PD(270), PORT_DATA_IO_PU_PD(271),
-	PORT_DATA_IO_PU_PD(272), PORT_DATA_IO_PU_PD(273),
-	PORT_DATA_IO_PU_PD(274), PORT_DATA_IO_PU_PD(275),
-	PORT_DATA_IO_PU_PD(276), PORT_DATA_IO_PU_PD(277),
-	PORT_DATA_IO_PU_PD(278), PORT_DATA_IO_PU_PD(279),
-
-	PORT_DATA_IO_PU_PD(280), PORT_DATA_IO_PU_PD(281),
-	PORT_DATA_IO_PU_PD(282), PORT_DATA_IO_PU_PD(283),
-	PORT_DATA_O(288), PORT_DATA_IO_PU_PD(289),
-
-	PORT_DATA_IO_PU_PD(290), PORT_DATA_IO_PU_PD(291),
-	PORT_DATA_IO_PU_PD(292), PORT_DATA_IO_PU_PD(293),
-	PORT_DATA_IO_PU_PD(294), PORT_DATA_IO_PU_PD(295),
-	PORT_DATA_IO_PU_PD(296), PORT_DATA_IO_PU_PD(297),
-	PORT_DATA_IO_PU_PD(298), PORT_DATA_IO_PU_PD(299),
-
-	PORT_DATA_IO_PU_PD(300), PORT_DATA_IO_PU_PD(301),
-	PORT_DATA_IO_PU_PD(302), PORT_DATA_IO_PU_PD(303),
-	PORT_DATA_IO_PU_PD(304), PORT_DATA_IO_PU_PD(305),
-	PORT_DATA_IO_PU_PD(306), PORT_DATA_IO_PU_PD(307),
-	PORT_DATA_IO_PU_PD(308),
-
-	PORT_DATA_IO_PU_PD(320), PORT_DATA_IO_PU_PD(321),
-	PORT_DATA_IO_PU_PD(322), PORT_DATA_IO_PU_PD(323),
-	PORT_DATA_IO_PU_PD(324), PORT_DATA_IO_PU_PD(325),
-	PORT_DATA_IO_PU_PD(326), PORT_DATA_IO_PU_PD(327),
-	PORT_DATA_IO_PU_PD(328), PORT_DATA_IO_PU_PD(329),
+	PINMUX_DATA_ALL(),
 
 	/* Port0 */
 	PINMUX_DATA(LCDD0_MARK,		PORT0_FN1),
@@ -2042,8 +1888,18 @@ static const struct sh_pfc_function pinmux_functions[] = {
 	SH_PFC_FUNCTION(scifb3),
 };
 
-static const struct pinmux_cfg_reg pinmux_config_regs[] = {
+#undef PORTCR
+#define PORTCR(nr, reg)							\
+	{								\
+		PINMUX_CFG_REG("PORT" nr "CR", reg, 8, 4) {		\
+			_PCRH(PORT##nr##_IN, 0, 0, PORT##nr##_OUT),	\
+				PORT##nr##_FN0, PORT##nr##_FN1,		\
+				PORT##nr##_FN2, PORT##nr##_FN3,		\
+				PORT##nr##_FN4, PORT##nr##_FN5,		\
+				PORT##nr##_FN6, PORT##nr##_FN7 }	\
+	}
 
+static const struct pinmux_cfg_reg pinmux_config_regs[] = {
 	PORTCR(0, 0xe6050000),
 	PORTCR(1, 0xe6050001),
 	PORTCR(2, 0xe6050002),
@@ -2706,8 +2562,6 @@ const struct sh_pfc_soc_info r8a73a4_pinmux_info = {
 	.ops		= &r8a73a4_pinmux_ops,
 
 	.input = { PINMUX_INPUT_BEGIN, PINMUX_INPUT_END },
-	.input_pu = { PINMUX_INPUT_PULLUP_BEGIN, PINMUX_INPUT_PULLUP_END },
-	.input_pd = { PINMUX_INPUT_PULLDOWN_BEGIN, PINMUX_INPUT_PULLDOWN_END },
 	.output = { PINMUX_OUTPUT_BEGIN, PINMUX_OUTPUT_END },
 	.function = { PINMUX_FUNCTION_BEGIN, PINMUX_FUNCTION_END },
 
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 01:09:33 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue,  2 Apr 2013 14:09:33 +0900
Subject: [PATCH 25/28] ARM: shmobile: r8a73a4: Remove IRQC function GPIOs
In-Reply-To: <1364879376-10020-1-git-send-email-horms+renesas@verge.net.au>
References: <1364879376-10020-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364879376-10020-26-git-send-email-horms+renesas@verge.net.au>

From: Magnus Damm <damm at opensource.se>

Remove IRQ pin function GPIOs that have been deprecated by the pinctrl
API.

Signed-off-by: Magnus Damm <damm at opensource.se>
Acked-by: Linus Walleij <linus.walleij at linaro.org>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/include/mach/r8a73a4.h |   58 -------------------------
 1 file changed, 58 deletions(-)

diff --git a/arch/arm/mach-shmobile/include/mach/r8a73a4.h b/arch/arm/mach-shmobile/include/mach/r8a73a4.h
index 703387a..9162e86 100644
--- a/arch/arm/mach-shmobile/include/mach/r8a73a4.h
+++ b/arch/arm/mach-shmobile/include/mach/r8a73a4.h
@@ -89,99 +89,83 @@ enum {
 	GPIO_FN_LCDD0 = 330,
 	GPIO_FN_PDM2_CLK_0,
 	GPIO_FN_DU0_DR0,
-	GPIO_FN_IRQ0,
 
 	/* Port1 */
 	GPIO_FN_LCDD1,
 	GPIO_FN_PDM2_DATA_1,
 	GPIO_FN_DU0_DR19,
-	GPIO_FN_IRQ1,
 
 	/* Port2 */
 	GPIO_FN_LCDD2,
 	GPIO_FN_PDM3_CLK_2,
 	GPIO_FN_DU0_DR2,
-	GPIO_FN_IRQ2,
 
 	/* Port3 */
 	GPIO_FN_LCDD3,
 	GPIO_FN_PDM3_DATA_3,
 	GPIO_FN_DU0_DR3,
-	GPIO_FN_IRQ3,
 
 	/* Port4 */
 	GPIO_FN_LCDD4,
 	GPIO_FN_PDM4_CLK_4,
 	GPIO_FN_DU0_DR4,
-	GPIO_FN_IRQ4,
 
 	/* Port5 */
 	GPIO_FN_LCDD5,
 	GPIO_FN_PDM4_DATA_5,
 	GPIO_FN_DU0_DR5,
-	GPIO_FN_IRQ5,
 
 	/* Port6 */
 	GPIO_FN_LCDD6,
 	GPIO_FN_PDM0_OUTCLK_6,
 	GPIO_FN_DU0_DR6,
-	GPIO_FN_IRQ6,
 
 	/* Port7 */
 	GPIO_FN_LCDD7,
 	GPIO_FN_PDM0_OUTDATA_7,
 	GPIO_FN_DU0_DR7,
-	GPIO_FN_IRQ7,
 
 	/* Port8 */
 	GPIO_FN_LCDD8,
 	GPIO_FN_PDM1_OUTCLK_8,
 	GPIO_FN_DU0_DG0,
-	GPIO_FN_IRQ8,
 
 	/* Port9 */
 	GPIO_FN_LCDD9,
 	GPIO_FN_PDM1_OUTDATA_9,
 	GPIO_FN_DU0_DG1,
-	GPIO_FN_IRQ9,
 
 	/* Port10 */
 	GPIO_FN_LCDD10,
 	GPIO_FN_FSICCK,
 	GPIO_FN_DU0_DG2,
-	GPIO_FN_IRQ10,
 
 	/* Port11 */
 	GPIO_FN_LCDD11,
 	GPIO_FN_FSICISLD,
 	GPIO_FN_DU0_DG3,
-	GPIO_FN_IRQ11,
 
 	/* Port12 */
 	GPIO_FN_LCDD12,
 	GPIO_FN_FSICOMC,
 	GPIO_FN_DU0_DG4,
-	GPIO_FN_IRQ12,
 
 	/* Port13 */
 	GPIO_FN_LCDD13,
 	GPIO_FN_FSICOLR,
 	GPIO_FN_FSICILR,
 	GPIO_FN_DU0_DG5,
-	GPIO_FN_IRQ13,
 
 	/* Port14 */
 	GPIO_FN_LCDD14,
 	GPIO_FN_FSICOBT,
 	GPIO_FN_FSICIBT,
 	GPIO_FN_DU0_DG6,
-	GPIO_FN_IRQ14,
 
 	/* Port15 */
 	GPIO_FN_LCDD15,
 	GPIO_FN_FSICOSLD,
 	GPIO_FN_DU0_DG7,
-	GPIO_FN_IRQ15,
 
 	/* Port16 */
 	GPIO_FN_LCDD16,
@@ -294,7 +278,6 @@ enum {
 	GPIO_FN_HSI_RX_WAKE,
 	GPIO_FN_MSIOF3_SYNC,
 	GPIO_FN_GenIO4,
-	GPIO_FN_IRQ40,
 
 	/* Port67 */
 	GPIO_FN_HSI_RX_READY,
@@ -344,8 +327,6 @@ enum {
 	GPIO_FN_TXP2,
 	GPIO_FN_COEX_0,
 	GPIO_FN_COEX_1,
-	GPIO_FN_IRQ19,
-	GPIO_FN_IRQ18,
 
 	/* Port96 - Port101 */
 	GPIO_FN_KEYIN0,
@@ -357,11 +338,9 @@ enum {
 
 	/* Port102 */
 	GPIO_FN_KEYIN6,
-	GPIO_FN_IRQ41,
 
 	/* Port103 */
 	GPIO_FN_KEYIN7,
-	GPIO_FN_IRQ42,
 
 	/* Port104 - Port108 */
 	GPIO_FN_KEYOUT0,
@@ -372,40 +351,33 @@ enum {
 
 	/* Port109 */
 	GPIO_FN_KEYOUT5,
-	GPIO_FN_IRQ43,
 
 	/* Port110 */
 	GPIO_FN_KEYOUT6,
-	GPIO_FN_IRQ44,
 
 	/* Port111 */
 	GPIO_FN_KEYOUT7,
 	GPIO_FN_RFANAEN,
-	GPIO_FN_IRQ45,
 
 	/* Port112 */
 	GPIO_FN_KEYIN8,
 	GPIO_FN_KEYOUT8,
 	GPIO_FN_SF_IRQ_04,
-	GPIO_FN_IRQ46,
 
 	/* Port113 */
 	GPIO_FN_KEYIN9,
 	GPIO_FN_KEYOUT9,
 	GPIO_FN_SF_IRQ_05,
-	GPIO_FN_IRQ47,
 
 	/* Port114 */
 	GPIO_FN_KEYIN10,
 	GPIO_FN_KEYOUT10,
 	GPIO_FN_SF_IRQ_06,
-	GPIO_FN_IRQ48,
 
 	/* Port115 */
 	GPIO_FN_KEYIN11,
 	GPIO_FN_KEYOUT11,
 	GPIO_FN_SF_IRQ_07,
-	GPIO_FN_IRQ49,
 
 	/* Port116 */
 	GPIO_FN_CSCIF0_TX,
@@ -484,10 +456,6 @@ enum {
 	GPIO_FN_STP_ISD_1,
 
 	/* Port160 - Port178 */
-	GPIO_FN_IRQ20,
-	GPIO_FN_IRQ21,
-	GPIO_FN_IRQ22,
-	GPIO_FN_IRQ23,
 	GPIO_FN_MMCD0_0,
 	GPIO_FN_MMCD0_1,
 	GPIO_FN_MMCD0_2,
@@ -499,10 +467,6 @@ enum {
 	GPIO_FN_MMCCMD0,
 	GPIO_FN_MMCCLK0,
 	GPIO_FN_MMCRST,
-	GPIO_FN_IRQ24,
-	GPIO_FN_IRQ25,
-	GPIO_FN_IRQ26,
-	GPIO_FN_IRQ27,
 
 	/* Port192 - Port200 FN1 */
 	GPIO_FN_A10,
@@ -527,15 +491,6 @@ enum {
 	GPIO_FN_MMCCMD1,
 
 	/* Port192 - Port200 IRQ */
-	GPIO_FN_IRQ31,
-	GPIO_FN_IRQ32,
-	GPIO_FN_IRQ33,
-	GPIO_FN_IRQ34,
-	GPIO_FN_IRQ35,
-	GPIO_FN_IRQ36,
-	GPIO_FN_IRQ37,
-	GPIO_FN_IRQ38,
-	GPIO_FN_IRQ39,
 
 	/* Port201 */
 	GPIO_FN_A1,
@@ -792,7 +747,6 @@ enum {
 	/* Port290 */
 	GPIO_FN_SDHID1_1,
 	GPIO_FN_STMDATA1_2,
-	GPIO_FN_IRQ51,
 
 	/* Port291 - Port294 FN1 */
 	GPIO_FN_SDHID1_2,
@@ -814,7 +768,6 @@ enum {
 	/* Port296 */
 	GPIO_FN_SDHID2_1,
 	GPIO_FN_MSIOF6_SS2,
-	GPIO_FN_IRQ52,
 
 	/* Port297 - Port300 FN1 */
 	GPIO_FN_SDHID2_2,
@@ -838,7 +791,6 @@ enum {
 
 	/* Port301 */
 	GPIO_FN_SDHICD0,
-	GPIO_FN_IRQ50,
 
 	/* Port302 - Port306 FN1 */
 	GPIO_FN_SDHID0_0,
@@ -862,16 +814,6 @@ enum {
 	GPIO_FN_STMCLK_1,
 
 	/* Port320 - Port329 */
-	GPIO_FN_IRQ16,
-	GPIO_FN_IRQ17,
-	GPIO_FN_IRQ28,
-	GPIO_FN_IRQ29,
-	GPIO_FN_IRQ30,
-	GPIO_FN_IRQ53,
-	GPIO_FN_IRQ54,
-	GPIO_FN_IRQ55,
-	GPIO_FN_IRQ56,
-	GPIO_FN_IRQ57,
 };
 
 void r8a73a4_add_standard_devices(void);
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 01:09:29 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue,  2 Apr 2013 14:09:29 +0900
Subject: [PATCH 21/28] sh-pfc: r8a73a4: Add IRQC pin groups and functions
In-Reply-To: <1364879376-10020-1-git-send-email-horms+renesas@verge.net.au>
References: <1364879376-10020-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364879376-10020-22-git-send-email-horms+renesas@verge.net.au>

From: Magnus Damm <damm at opensource.se>

V2 of PINCTRL support for r8a73a4 IRQC hardware
and in particular the external pins IRQ0 -> IRQ57.

Signed-off-by: Magnus Damm <damm at opensource.se>
Acked-by: Linus Walleij <linus.walleij at linaro.org>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 drivers/pinctrl/sh-pfc/pfc-r8a73a4.c |  186 ++++++++++++++++++++++++++++++++++
 1 file changed, 186 insertions(+)

diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a73a4.c b/drivers/pinctrl/sh-pfc/pfc-r8a73a4.c
index cd5c5fd..8a5288c 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a73a4.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a73a4.c
@@ -1576,6 +1576,72 @@ static const struct pinmux_range pinmux_ranges[] = {
 	{.begin = 320, .end = 329,},
 };
 
+/* - IRQC ------------------------------------------------------------------- */
+#define IRQC_PINS_MUX(pin, irq_mark)				\
+static const unsigned int irqc_irq##irq_mark##_pins[] = {	\
+	pin,							\
+};								\
+static const unsigned int irqc_irq##irq_mark##_mux[] = {	\
+	IRQ##irq_mark##_MARK,					\
+}
+IRQC_PINS_MUX(0, 0);
+IRQC_PINS_MUX(1, 1);
+IRQC_PINS_MUX(2, 2);
+IRQC_PINS_MUX(3, 3);
+IRQC_PINS_MUX(4, 4);
+IRQC_PINS_MUX(5, 5);
+IRQC_PINS_MUX(6, 6);
+IRQC_PINS_MUX(7, 7);
+IRQC_PINS_MUX(8, 8);
+IRQC_PINS_MUX(9, 9);
+IRQC_PINS_MUX(10, 10);
+IRQC_PINS_MUX(11, 11);
+IRQC_PINS_MUX(12, 12);
+IRQC_PINS_MUX(13, 13);
+IRQC_PINS_MUX(14, 14);
+IRQC_PINS_MUX(15, 15);
+IRQC_PINS_MUX(66, 40);
+IRQC_PINS_MUX(84, 19);
+IRQC_PINS_MUX(85, 18);
+IRQC_PINS_MUX(102, 41);
+IRQC_PINS_MUX(103, 42);
+IRQC_PINS_MUX(109, 43);
+IRQC_PINS_MUX(110, 44);
+IRQC_PINS_MUX(111, 45);
+IRQC_PINS_MUX(112, 46);
+IRQC_PINS_MUX(113, 47);
+IRQC_PINS_MUX(114, 48);
+IRQC_PINS_MUX(115, 49);
+IRQC_PINS_MUX(160, 20);
+IRQC_PINS_MUX(161, 21);
+IRQC_PINS_MUX(162, 22);
+IRQC_PINS_MUX(163, 23);
+IRQC_PINS_MUX(175, 24);
+IRQC_PINS_MUX(176, 25);
+IRQC_PINS_MUX(177, 26);
+IRQC_PINS_MUX(178, 27);
+IRQC_PINS_MUX(192, 31);
+IRQC_PINS_MUX(193, 32);
+IRQC_PINS_MUX(194, 33);
+IRQC_PINS_MUX(195, 34);
+IRQC_PINS_MUX(196, 35);
+IRQC_PINS_MUX(197, 36);
+IRQC_PINS_MUX(198, 37);
+IRQC_PINS_MUX(199, 38);
+IRQC_PINS_MUX(200, 39);
+IRQC_PINS_MUX(290, 51);
+IRQC_PINS_MUX(296, 52);
+IRQC_PINS_MUX(301, 50);
+IRQC_PINS_MUX(320, 16);
+IRQC_PINS_MUX(321, 17);
+IRQC_PINS_MUX(322, 28);
+IRQC_PINS_MUX(323, 29);
+IRQC_PINS_MUX(324, 30);
+IRQC_PINS_MUX(325, 53);
+IRQC_PINS_MUX(326, 54);
+IRQC_PINS_MUX(327, 55);
+IRQC_PINS_MUX(328, 56);
+IRQC_PINS_MUX(329, 57);
 /* - SCIFA0 ----------------------------------------------------------------- */
 static const unsigned int scifa0_data_pins[] = {
 	/* SCIFA0_RXD, SCIFA0_TXD */
@@ -1773,6 +1839,64 @@ static const unsigned int scifb3_ctrl_b_mux[] = {
 };
 
 static const struct sh_pfc_pin_group pinmux_groups[] = {
+	SH_PFC_PIN_GROUP(irqc_irq0),
+	SH_PFC_PIN_GROUP(irqc_irq1),
+	SH_PFC_PIN_GROUP(irqc_irq2),
+	SH_PFC_PIN_GROUP(irqc_irq3),
+	SH_PFC_PIN_GROUP(irqc_irq4),
+	SH_PFC_PIN_GROUP(irqc_irq5),
+	SH_PFC_PIN_GROUP(irqc_irq6),
+	SH_PFC_PIN_GROUP(irqc_irq7),
+	SH_PFC_PIN_GROUP(irqc_irq8),
+	SH_PFC_PIN_GROUP(irqc_irq9),
+	SH_PFC_PIN_GROUP(irqc_irq10),
+	SH_PFC_PIN_GROUP(irqc_irq11),
+	SH_PFC_PIN_GROUP(irqc_irq12),
+	SH_PFC_PIN_GROUP(irqc_irq13),
+	SH_PFC_PIN_GROUP(irqc_irq14),
+	SH_PFC_PIN_GROUP(irqc_irq15),
+	SH_PFC_PIN_GROUP(irqc_irq16),
+	SH_PFC_PIN_GROUP(irqc_irq17),
+	SH_PFC_PIN_GROUP(irqc_irq18),
+	SH_PFC_PIN_GROUP(irqc_irq19),
+	SH_PFC_PIN_GROUP(irqc_irq20),
+	SH_PFC_PIN_GROUP(irqc_irq21),
+	SH_PFC_PIN_GROUP(irqc_irq22),
+	SH_PFC_PIN_GROUP(irqc_irq23),
+	SH_PFC_PIN_GROUP(irqc_irq24),
+	SH_PFC_PIN_GROUP(irqc_irq25),
+	SH_PFC_PIN_GROUP(irqc_irq26),
+	SH_PFC_PIN_GROUP(irqc_irq27),
+	SH_PFC_PIN_GROUP(irqc_irq28),
+	SH_PFC_PIN_GROUP(irqc_irq29),
+	SH_PFC_PIN_GROUP(irqc_irq30),
+	SH_PFC_PIN_GROUP(irqc_irq31),
+	SH_PFC_PIN_GROUP(irqc_irq32),
+	SH_PFC_PIN_GROUP(irqc_irq33),
+	SH_PFC_PIN_GROUP(irqc_irq34),
+	SH_PFC_PIN_GROUP(irqc_irq35),
+	SH_PFC_PIN_GROUP(irqc_irq36),
+	SH_PFC_PIN_GROUP(irqc_irq37),
+	SH_PFC_PIN_GROUP(irqc_irq38),
+	SH_PFC_PIN_GROUP(irqc_irq39),
+	SH_PFC_PIN_GROUP(irqc_irq40),
+	SH_PFC_PIN_GROUP(irqc_irq41),
+	SH_PFC_PIN_GROUP(irqc_irq42),
+	SH_PFC_PIN_GROUP(irqc_irq43),
+	SH_PFC_PIN_GROUP(irqc_irq44),
+	SH_PFC_PIN_GROUP(irqc_irq45),
+	SH_PFC_PIN_GROUP(irqc_irq46),
+	SH_PFC_PIN_GROUP(irqc_irq47),
+	SH_PFC_PIN_GROUP(irqc_irq48),
+	SH_PFC_PIN_GROUP(irqc_irq49),
+	SH_PFC_PIN_GROUP(irqc_irq50),
+	SH_PFC_PIN_GROUP(irqc_irq51),
+	SH_PFC_PIN_GROUP(irqc_irq52),
+	SH_PFC_PIN_GROUP(irqc_irq53),
+	SH_PFC_PIN_GROUP(irqc_irq54),
+	SH_PFC_PIN_GROUP(irqc_irq55),
+	SH_PFC_PIN_GROUP(irqc_irq56),
+	SH_PFC_PIN_GROUP(irqc_irq57),
 	SH_PFC_PIN_GROUP(scifa0_data),
 	SH_PFC_PIN_GROUP(scifa0_clk),
 	SH_PFC_PIN_GROUP(scifa0_ctrl),
@@ -1802,6 +1926,67 @@ static const struct sh_pfc_pin_group pinmux_groups[] = {
 	SH_PFC_PIN_GROUP(scifb3_ctrl_b),
 };
 
+static const char * const irqc_groups[] = {
+	"irqc_irq0",
+	"irqc_irq1",
+	"irqc_irq2",
+	"irqc_irq3",
+	"irqc_irq4",
+	"irqc_irq5",
+	"irqc_irq6",
+	"irqc_irq7",
+	"irqc_irq8",
+	"irqc_irq9",
+	"irqc_irq10",
+	"irqc_irq11",
+	"irqc_irq12",
+	"irqc_irq13",
+	"irqc_irq14",
+	"irqc_irq15",
+	"irqc_irq16",
+	"irqc_irq17",
+	"irqc_irq18",
+	"irqc_irq19",
+	"irqc_irq20",
+	"irqc_irq21",
+	"irqc_irq22",
+	"irqc_irq23",
+	"irqc_irq24",
+	"irqc_irq25",
+	"irqc_irq26",
+	"irqc_irq27",
+	"irqc_irq28",
+	"irqc_irq29",
+	"irqc_irq30",
+	"irqc_irq31",
+	"irqc_irq32",
+	"irqc_irq33",
+	"irqc_irq34",
+	"irqc_irq35",
+	"irqc_irq36",
+	"irqc_irq37",
+	"irqc_irq38",
+	"irqc_irq39",
+	"irqc_irq40",
+	"irqc_irq41",
+	"irqc_irq42",
+	"irqc_irq43",
+	"irqc_irq44",
+	"irqc_irq45",
+	"irqc_irq46",
+	"irqc_irq47",
+	"irqc_irq48",
+	"irqc_irq49",
+	"irqc_irq50",
+	"irqc_irq51",
+	"irqc_irq52",
+	"irqc_irq53",
+	"irqc_irq54",
+	"irqc_irq55",
+	"irqc_irq56",
+	"irqc_irq57",
+};
+
 static const char * const scifa0_groups[] = {
 	"scifa0_data",
 	"scifa0_clk",
@@ -1848,6 +2033,7 @@ static const char * const scifb3_groups[] = {
 };
 
 static const struct sh_pfc_function pinmux_functions[] = {
+	SH_PFC_FUNCTION(irqc),
 	SH_PFC_FUNCTION(scifa0),
 	SH_PFC_FUNCTION(scifa1),
 	SH_PFC_FUNCTION(scifb0),
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 01:09:32 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue,  2 Apr 2013 14:09:32 +0900
Subject: [PATCH 24/28] ARM: shmobile: r8a73a4: Remove SCIF function GPIOs
In-Reply-To: <1364879376-10020-1-git-send-email-horms+renesas@verge.net.au>
References: <1364879376-10020-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364879376-10020-25-git-send-email-horms+renesas@verge.net.au>

From: Magnus Damm <damm at opensource.se>

Remove SCIF function GPIOs that have been deprecated by the pinctrl API.

Signed-off-by: Magnus Damm <damm at opensource.se>
Acked-by: Linus Walleij <linus.walleij at linaro.org>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/include/mach/r8a73a4.h |   45 -------------------------
 1 file changed, 45 deletions(-)

diff --git a/arch/arm/mach-shmobile/include/mach/r8a73a4.h b/arch/arm/mach-shmobile/include/mach/r8a73a4.h
index 2d4af4a..703387a 100644
--- a/arch/arm/mach-shmobile/include/mach/r8a73a4.h
+++ b/arch/arm/mach-shmobile/include/mach/r8a73a4.h
@@ -200,55 +200,45 @@ enum {
 
 	/* Port19 */
 	GPIO_FN_LCDD19,
-	GPIO_FN_SCIFB3_RTS_19,
 	GPIO_FN_DU0_DB3,
 
 	/* Port20 */
 	GPIO_FN_LCDD20,
-	GPIO_FN_SCIFB3_CTS_20,
 	GPIO_FN_DU0_DB4,
 
 	/* Port21 */
 	GPIO_FN_LCDD21,
-	GPIO_FN_SCIFB3_TXD_21,
 	GPIO_FN_DU0_DB5,
 
 	/* Port22 */
 	GPIO_FN_LCDD22,
-	GPIO_FN_SCIFB3_RXD_22,
 	GPIO_FN_DU0_DB6,
 
 	/* Port23 */
 	GPIO_FN_LCDD23,
-	GPIO_FN_SCIFB3_SCK_23,
 	GPIO_FN_DU0_DB7,
 
 	/* Port24 */
 	GPIO_FN_LCDHSYN,
 	GPIO_FN_LCDCS,
-	GPIO_FN_SCIFB1_RTS_24,
 	GPIO_FN_DU0_EXHSYNC_N_CSYNC_N_HSYNC_N,
 
 	/* Port25 */
 	GPIO_FN_LCDVSYN,
-	GPIO_FN_SCIFB1_CTS_25,
 	GPIO_FN_DU0_EXVSYNC_N_VSYNC_N_CSYNC_N,
 
 	/* Port26 */
 	GPIO_FN_LCDDCK,
 	GPIO_FN_LCDWR,
-	GPIO_FN_SCIFB1_TXD_26,
 	GPIO_FN_DU0_DOTCLKIN,
 
 	/* Port27 */
 	GPIO_FN_LCDDISP,
 	GPIO_FN_LCDRS,
-	GPIO_FN_SCIFB1_RXD_27,
 	GPIO_FN_DU0_DOTCLKOUT,
 
 	/* Port28 */
 	GPIO_FN_LCDRD_N,
-	GPIO_FN_SCIFB1_SCK_28,
 	GPIO_FN_DU0_DOTCLKOUTB,
 
 	/* Port29 */
@@ -262,48 +252,36 @@ enum {
 	GPIO_FN_DU0_ODDF_N_CLAMP,
 
 	/* Port32 */
-	GPIO_FN_SCIFA0_RTS,
 	GPIO_FN_SIM0_DET,
 	GPIO_FN_CSCIF0_RTS,
 
 	/* Port33 */
-	GPIO_FN_SCIFA0_CTS,
 	GPIO_FN_SIM1_DET,
 	GPIO_FN_CSCIF0_CTS,
 
 	/* Port34 */
-	GPIO_FN_SCIFA0_SCK,
 	GPIO_FN_SIM0_PWRON,
 	GPIO_FN_CSCIF0_SCK,
 
 	/* Port35 */
-	GPIO_FN_SCIFA1_RTS,
 	GPIO_FN_CSCIF1_RTS,
 
 	/* Port36 */
-	GPIO_FN_SCIFA1_CTS,
 	GPIO_FN_CSCIF1_CTS,
 
 	/* Port37 */
-	GPIO_FN_SCIFA1_SCK,
 	GPIO_FN_CSCIF1_SCK,
 
 	/* Port38 */
-	GPIO_FN_SCIFB0_RTS,
 	GPIO_FN_TPU0TO1,
-	GPIO_FN_SCIFB3_RTS_38,
 	GPIO_FN_CHSCIF0_HRTS,
 
 	/* Port39 */
-	GPIO_FN_SCIFB0_CTS,
 	GPIO_FN_TPU0TO2,
-	GPIO_FN_SCIFB3_CTS_39,
 	GPIO_FN_CHSCIF0_HCTS,
 
 	/* Port40 */
-	GPIO_FN_SCIFB0_SCK,
 	GPIO_FN_TPU0TO3,
-	GPIO_FN_SCIFB3_SCK_40,
 	GPIO_FN_CHSCIF0_HSCK,
 
 	/* Port64 */
@@ -314,52 +292,44 @@ enum {
 
 	/* Port66 */
 	GPIO_FN_HSI_RX_WAKE,
-	GPIO_FN_SCIFB2_CTS_66,
 	GPIO_FN_MSIOF3_SYNC,
 	GPIO_FN_GenIO4,
 	GPIO_FN_IRQ40,
 
 	/* Port67 */
 	GPIO_FN_HSI_RX_READY,
-	GPIO_FN_SCIFB1_TXD_67,
 	GPIO_FN_GIO_OUT3_67,
 	GPIO_FN_CHSCIF1_HTX,
 
 	/* Port68 */
 	GPIO_FN_HSI_RX_FLAG,
-	GPIO_FN_SCIFB2_TXD_68,
 	GPIO_FN_MSIOF3_TXD,
 	GPIO_FN_GIO_OUT4_68,
 
 	/* Port69 */
 	GPIO_FN_HSI_RX_DATA,
-	GPIO_FN_SCIFB2_RXD_69,
 	GPIO_FN_MSIOF3_RXD,
 	GPIO_FN_GIO_OUT5_69,
 
 	/* Port70 */
 	GPIO_FN_HSI_TX_FLAG,
-	GPIO_FN_SCIFB1_RTS_70,
 	GPIO_FN_GIO_OUT1_70,
 	GPIO_FN_HSIC_TSTCLK0,
 	GPIO_FN_CHSCIF1_HRTS,
 
 	/* Port71 */
 	GPIO_FN_HSI_TX_DATA,
-	GPIO_FN_SCIFB1_CTS_71,
 	GPIO_FN_GIO_OUT2_71,
 	GPIO_FN_HSIC_TSTCLK1,
 	GPIO_FN_CHSCIF1_HCTS,
 
 	/* Port72 */
 	GPIO_FN_HSI_TX_WAKE,
-	GPIO_FN_SCIFB1_RXD_72,
 	GPIO_FN_GenIO8,
 	GPIO_FN_CHSCIF1_HRX,
 
 	/* Port73 */
 	GPIO_FN_HSI_TX_READY,
-	GPIO_FN_SCIFB2_RTS_73,
 	GPIO_FN_MSIOF3_SCK,
 	GPIO_FN_GIO_OUT0_73,
 
@@ -438,36 +408,28 @@ enum {
 	GPIO_FN_IRQ49,
 
 	/* Port116 */
-	GPIO_FN_SCIFA0_TXD,
 	GPIO_FN_CSCIF0_TX,
 
 	/* Port117 */
-	GPIO_FN_SCIFA0_RXD,
 	GPIO_FN_CSCIF0_RX,
 
 	/* Port118 */
-	GPIO_FN_SCIFA1_TXD,
 	GPIO_FN_CSCIF1_TX,
 
 	/* Port119 */
-	GPIO_FN_SCIFA1_RXD,
 	GPIO_FN_CSCIF1_RX,
 
 	/* Port120 */
 	GPIO_FN_SF_PORT_1_120,
-	GPIO_FN_SCIFB3_RXD_120,
 	GPIO_FN_DU0_CDE,
 
 	/* Port121 */
 	GPIO_FN_SF_PORT_0_121,
-	GPIO_FN_SCIFB3_TXD_121,
 
 	/* Port122 */
-	GPIO_FN_SCIFB0_TXD,
 	GPIO_FN_CHSCIF0_HTX,
 
 	/* Port123 */
-	GPIO_FN_SCIFB0_RXD,
 	GPIO_FN_CHSCIF0_HRX,
 
 	/* Port124 */
@@ -761,11 +723,9 @@ enum {
 	GPIO_FN_MSIOF0_TXD,
 
 	/* Port261 */
-	GPIO_FN_SCIFB1_SCK_261,
 	GPIO_FN_CHSCIF1_HSCK,
 
 	/* Port262 */
-	GPIO_FN_SCIFB2_SCK_262,
 
 	/* Port263 - Port266 FN1 */
 	GPIO_FN_MSIOF1_SS2,
@@ -849,7 +809,6 @@ enum {
 	/* Port295 */
 	GPIO_FN_SDHID2_0,
 	GPIO_FN_MSIOF4_TXD,
-	GPIO_FN_SCIFB2_TXD_295,
 	GPIO_FN_MSIOF6_TXD,
 
 	/* Port296 */
@@ -870,10 +829,6 @@ enum {
 	GPIO_FN_MSIOF4_SS1,
 
 	/* Port297 - Port300 FN3 */
-	GPIO_FN_SCIFB2_RXD_297,
-	GPIO_FN_SCIFB2_CTS_298,
-	GPIO_FN_SCIFB2_SCK_299,
-	GPIO_FN_SCIFB2_RTS_300,
 
 	/* Port297 - Port300 FN4 */
 	GPIO_FN_MSIOF6_RXD,
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 01:09:34 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue,  2 Apr 2013 14:09:34 +0900
Subject: [PATCH 26/28] sh-pfc: r8a73a4: Remove function GPIOs
In-Reply-To: <1364879376-10020-1-git-send-email-horms+renesas@verge.net.au>
References: <1364879376-10020-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364879376-10020-27-git-send-email-horms+renesas@verge.net.au>

From: Magnus Damm <damm at opensource.se>

All r8a73a4 platforms use the pinctrl API to control pin functions.
Function GPIOs are no longer needed.

Signed-off-by: Magnus Damm <damm at opensource.se>
Acked-by: Linus Walleij <linus.walleij at linaro.org>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 drivers/pinctrl/sh-pfc/pfc-r8a73a4.c |  737 ----------------------------------
 1 file changed, 737 deletions(-)

diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a73a4.c b/drivers/pinctrl/sh-pfc/pfc-r8a73a4.c
index 66fc747..464c5f9 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a73a4.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a73a4.c
@@ -2042,740 +2042,6 @@ static const struct sh_pfc_function pinmux_functions[] = {
 	SH_PFC_FUNCTION(scifb3),
 };
 
-#define PINMUX_FN_BASE	ARRAY_SIZE(pinmux_pins)
-
-static const struct pinmux_func pinmux_func_gpios[] = {
-	/* Port0 */
-	GPIO_FN(LCDD0),
-	GPIO_FN(PDM2_CLK_0),
-	GPIO_FN(DU0_DR0),
-
-	/* Port1 */
-	GPIO_FN(LCDD1),
-	GPIO_FN(PDM2_DATA_1),
-	GPIO_FN(DU0_DR19),
-
-	/* Port2 */
-	GPIO_FN(LCDD2),
-	GPIO_FN(PDM3_CLK_2),
-	GPIO_FN(DU0_DR2),
-
-	/* Port3 */
-	GPIO_FN(LCDD3),
-	GPIO_FN(PDM3_DATA_3),
-	GPIO_FN(DU0_DR3),
-
-	/* Port4 */
-	GPIO_FN(LCDD4),
-	GPIO_FN(PDM4_CLK_4),
-	GPIO_FN(DU0_DR4),
-
-	/* Port5 */
-	GPIO_FN(LCDD5),
-	GPIO_FN(PDM4_DATA_5),
-	GPIO_FN(DU0_DR5),
-
-	/* Port6 */
-	GPIO_FN(LCDD6),
-	GPIO_FN(PDM0_OUTCLK_6),
-	GPIO_FN(DU0_DR6),
-
-	/* Port7 */
-	GPIO_FN(LCDD7),
-	GPIO_FN(PDM0_OUTDATA_7),
-	GPIO_FN(DU0_DR7),
-
-	/* Port8 */
-	GPIO_FN(LCDD8),
-	GPIO_FN(PDM1_OUTCLK_8),
-	GPIO_FN(DU0_DG0),
-
-	/* Port9 */
-	GPIO_FN(LCDD9),
-	GPIO_FN(PDM1_OUTDATA_9),
-	GPIO_FN(DU0_DG1),
-
-	/* Port10 */
-	GPIO_FN(LCDD10),
-	GPIO_FN(FSICCK),
-	GPIO_FN(DU0_DG2),
-
-	/* Port11 */
-	GPIO_FN(LCDD11),
-	GPIO_FN(FSICISLD),
-	GPIO_FN(DU0_DG3),
-
-	/* Port12 */
-	GPIO_FN(LCDD12),
-	GPIO_FN(FSICOMC),
-	GPIO_FN(DU0_DG4),
-
-	/* Port13 */
-	GPIO_FN(LCDD13),
-	GPIO_FN(FSICOLR),
-	GPIO_FN(FSICILR),
-	GPIO_FN(DU0_DG5),
-
-	/* Port14 */
-	GPIO_FN(LCDD14),
-	GPIO_FN(FSICOBT),
-	GPIO_FN(FSICIBT),
-	GPIO_FN(DU0_DG6),
-
-	/* Port15 */
-	GPIO_FN(LCDD15),
-	GPIO_FN(FSICOSLD),
-	GPIO_FN(DU0_DG7),
-
-	/* Port16 */
-	GPIO_FN(LCDD16),
-	GPIO_FN(TPU1TO1),
-	GPIO_FN(DU0_DB0),
-
-	/* Port17 */
-	GPIO_FN(LCDD17),
-	GPIO_FN(SF_IRQ_00),
-	GPIO_FN(DU0_DB1),
-
-	/* Port18 */
-	GPIO_FN(LCDD18),
-	GPIO_FN(SF_IRQ_01),
-	GPIO_FN(DU0_DB2),
-
-	/* Port19 */
-	GPIO_FN(LCDD19),
-	GPIO_FN(DU0_DB3),
-
-	/* Port20 */
-	GPIO_FN(LCDD20),
-	GPIO_FN(DU0_DB4),
-
-	/* Port21 */
-	GPIO_FN(LCDD21),
-	GPIO_FN(DU0_DB5),
-
-	/* Port22 */
-	GPIO_FN(LCDD22),
-	GPIO_FN(DU0_DB6),
-
-	/* Port23 */
-	GPIO_FN(LCDD23),
-	GPIO_FN(DU0_DB7),
-
-	/* Port24 */
-	GPIO_FN(LCDHSYN),
-	GPIO_FN(LCDCS),
-	GPIO_FN(DU0_EXHSYNC_N_CSYNC_N_HSYNC_N),
-
-	/* Port25 */
-	GPIO_FN(LCDVSYN),
-	GPIO_FN(DU0_EXVSYNC_N_VSYNC_N_CSYNC_N),
-
-	/* Port26 */
-	GPIO_FN(LCDDCK),
-	GPIO_FN(LCDWR),
-	GPIO_FN(DU0_DOTCLKIN),
-
-	/* Port27 */
-	GPIO_FN(LCDDISP),
-	GPIO_FN(LCDRS),
-	GPIO_FN(DU0_DOTCLKOUT),
-
-	/* Port28 */
-	GPIO_FN(LCDRD_N),
-	GPIO_FN(DU0_DOTCLKOUTB),
-
-	/* Port29 */
-	GPIO_FN(LCDLCLK),
-	GPIO_FN(SF_IRQ_02),
-	GPIO_FN(DU0_DISP_CSYNC_N_DE),
-
-	/* Port30 */
-	GPIO_FN(LCDDON),
-	GPIO_FN(SF_IRQ_03),
-	GPIO_FN(DU0_ODDF_N_CLAMP),
-
-	/* Port32 */
-	GPIO_FN(SIM0_DET),
-	GPIO_FN(CSCIF0_RTS),
-
-	/* Port33 */
-	GPIO_FN(SIM1_DET),
-	GPIO_FN(CSCIF0_CTS),
-
-	/* Port34 */
-	GPIO_FN(SIM0_PWRON),
-	GPIO_FN(CSCIF0_SCK),
-
-	/* Port35 */
-	GPIO_FN(CSCIF1_RTS),
-
-	/* Port36 */
-	GPIO_FN(CSCIF1_CTS),
-
-	/* Port37 */
-	GPIO_FN(CSCIF1_SCK),
-
-	/* Port38 */
-	GPIO_FN(TPU0TO1),
-	GPIO_FN(CHSCIF0_HRTS),
-
-	/* Port39 */
-	GPIO_FN(TPU0TO2),
-	GPIO_FN(CHSCIF0_HCTS),
-
-	/* Port40 */
-	GPIO_FN(TPU0TO3),
-	GPIO_FN(CHSCIF0_HSCK),
-
-	/* Port64 */
-	GPIO_FN(PDM0_DATA),
-
-	/* Port65 */
-	GPIO_FN(PDM1_DATA),
-
-	/* Port66 */
-	GPIO_FN(HSI_RX_WAKE),
-	GPIO_FN(MSIOF3_SYNC),
-	GPIO_FN(GenIO4),
-
-	/* Port67 */
-	GPIO_FN(HSI_RX_READY),
-	GPIO_FN(GIO_OUT3_67),
-	GPIO_FN(CHSCIF1_HTX),
-
-	/* Port68 */
-	GPIO_FN(HSI_RX_FLAG),
-	GPIO_FN(MSIOF3_TXD),
-	GPIO_FN(GIO_OUT4_68),
-
-	/* Port69 */
-	GPIO_FN(HSI_RX_DATA),
-	GPIO_FN(MSIOF3_RXD),
-	GPIO_FN(GIO_OUT5_69),
-
-	/* Port70 */
-	GPIO_FN(HSI_TX_FLAG),
-	GPIO_FN(GIO_OUT1_70),
-	GPIO_FN(HSIC_TSTCLK0),
-	GPIO_FN(CHSCIF1_HRTS),
-
-	/* Port71 */
-	GPIO_FN(HSI_TX_DATA),
-	GPIO_FN(GIO_OUT2_71),
-	GPIO_FN(HSIC_TSTCLK1),
-	GPIO_FN(CHSCIF1_HCTS),
-
-	/* Port72 */
-	GPIO_FN(HSI_TX_WAKE),
-	GPIO_FN(GenIO8),
-	GPIO_FN(CHSCIF1_HRX),
-
-	/* Port73 */
-	GPIO_FN(HSI_TX_READY),
-	GPIO_FN(MSIOF3_SCK),
-	GPIO_FN(GIO_OUT0_73),
-
-	/* Port74 - Port85 */
-	GPIO_FN(IRDA_OUT),
-	GPIO_FN(IRDA_IN),
-	GPIO_FN(IRDA_FIRSEL),
-	GPIO_FN(TPU0TO0),
-	GPIO_FN(DIGRFEN),
-	GPIO_FN(GPS_TIMESTAMP),
-	GPIO_FN(TXP),
-	GPIO_FN(TXP2),
-	GPIO_FN(COEX_0),
-	GPIO_FN(COEX_1),
-
-	/* Port96 - Port101 */
-	GPIO_FN(KEYIN0),
-	GPIO_FN(KEYIN1),
-	GPIO_FN(KEYIN2),
-	GPIO_FN(KEYIN3),
-	GPIO_FN(KEYIN4),
-	GPIO_FN(KEYIN5),
-
-	/* Port102 */
-	GPIO_FN(KEYIN6),
-
-	/* Port103 */
-	GPIO_FN(KEYIN7),
-
-	/* Port104 - Port108 */
-	GPIO_FN(KEYOUT0),
-	GPIO_FN(KEYOUT1),
-	GPIO_FN(KEYOUT2),
-	GPIO_FN(KEYOUT3),
-	GPIO_FN(KEYOUT4),
-
-	/* Port109 */
-	GPIO_FN(KEYOUT5),
-
-	/* Port110 */
-	GPIO_FN(KEYOUT6),
-
-	/* Port111 */
-	GPIO_FN(KEYOUT7),
-	GPIO_FN(RFANAEN),
-
-	/* Port112 */
-	GPIO_FN(KEYIN8),
-	GPIO_FN(KEYOUT8),
-	GPIO_FN(SF_IRQ_04),
-
-	/* Port113 */
-	GPIO_FN(KEYIN9),
-	GPIO_FN(KEYOUT9),
-	GPIO_FN(SF_IRQ_05),
-
-	/* Port114 */
-	GPIO_FN(KEYIN10),
-	GPIO_FN(KEYOUT10),
-	GPIO_FN(SF_IRQ_06),
-
-	/* Port115 */
-	GPIO_FN(KEYIN11),
-	GPIO_FN(KEYOUT11),
-	GPIO_FN(SF_IRQ_07),
-
-	/* Port116 */
-	GPIO_FN(CSCIF0_TX),
-
-	/* Port117 */
-	GPIO_FN(CSCIF0_RX),
-
-	/* Port118 */
-	GPIO_FN(CSCIF1_TX),
-
-	/* Port119 */
-	GPIO_FN(CSCIF1_RX),
-
-	/* Port120 */
-	GPIO_FN(SF_PORT_1_120),
-	GPIO_FN(DU0_CDE),
-
-	/* Port121 */
-	GPIO_FN(SF_PORT_0_121),
-
-	/* Port122 */
-	GPIO_FN(CHSCIF0_HTX),
-
-	/* Port123 */
-	GPIO_FN(CHSCIF0_HRX),
-
-	/* Port124 */
-	GPIO_FN(ISP_STROBE_124),
-
-	/* Port125 */
-	GPIO_FN(STP_ISD_0),
-	GPIO_FN(PDM4_CLK_125),
-	GPIO_FN(MSIOF2_TXD),
-	GPIO_FN(SIM0_VOLTSEL0),
-
-	/* Port126 */
-	GPIO_FN(TS_SDEN),
-	GPIO_FN(MSIOF7_SYNC),
-	GPIO_FN(STP_ISEN_1),
-
-	/* Port128 */
-	GPIO_FN(STP_ISEN_0),
-	GPIO_FN(PDM1_OUTDATA_128),
-	GPIO_FN(MSIOF2_SYNC),
-	GPIO_FN(SIM1_VOLTSEL1),
-
-	/* Port129 */
-	GPIO_FN(TS_SPSYNC),
-	GPIO_FN(MSIOF7_RXD),
-	GPIO_FN(STP_ISSYNC_1),
-
-	/* Port130 */
-	GPIO_FN(STP_ISSYNC_0),
-	GPIO_FN(PDM4_DATA_130),
-	GPIO_FN(MSIOF2_RXD),
-	GPIO_FN(SIM0_VOLTSEL1),
-
-	/* Port131 */
-	GPIO_FN(STP_OPWM_0),
-	GPIO_FN(SIM1_PWRON),
-
-	/* Port132 */
-	GPIO_FN(TS_SCK),
-	GPIO_FN(MSIOF7_SCK),
-	GPIO_FN(STP_ISCLK_1),
-
-	/* Port133 */
-	GPIO_FN(STP_ISCLK_0),
-	GPIO_FN(PDM1_OUTCLK_133),
-	GPIO_FN(MSIOF2_SCK),
-	GPIO_FN(SIM1_VOLTSEL0),
-
-	/* Port134 */
-	GPIO_FN(TS_SDAT),
-	GPIO_FN(MSIOF7_TXD),
-	GPIO_FN(STP_ISD_1),
-
-	/* Port160 - Port178 */
-	GPIO_FN(MMCD0_0),
-	GPIO_FN(MMCD0_1),
-	GPIO_FN(MMCD0_2),
-	GPIO_FN(MMCD0_3),
-	GPIO_FN(MMCD0_4),
-	GPIO_FN(MMCD0_5),
-	GPIO_FN(MMCD0_6),
-	GPIO_FN(MMCD0_7),
-	GPIO_FN(MMCCMD0),
-	GPIO_FN(MMCCLK0),
-	GPIO_FN(MMCRST),
-
-	/* Port192 - Port200 FN1 */
-	GPIO_FN(A10),
-	GPIO_FN(A9),
-	GPIO_FN(A8),
-	GPIO_FN(A7),
-	GPIO_FN(A6),
-	GPIO_FN(A5),
-	GPIO_FN(A4),
-	GPIO_FN(A3),
-	GPIO_FN(A2),
-
-	/* Port192 - Port200 FN2 */
-	GPIO_FN(MMCD1_7),
-	GPIO_FN(MMCD1_6),
-	GPIO_FN(MMCD1_5),
-	GPIO_FN(MMCD1_4),
-	GPIO_FN(MMCD1_3),
-	GPIO_FN(MMCD1_2),
-	GPIO_FN(MMCD1_1),
-	GPIO_FN(MMCD1_0),
-	GPIO_FN(MMCCMD1),
-
-	/* Port192 - Port200 IRQ */
-
-	/* Port201 */
-	GPIO_FN(A1),
-
-	/* Port202 */
-	GPIO_FN(A0),
-	GPIO_FN(BS),
-
-	/* Port203 */
-	GPIO_FN(CKO),
-	GPIO_FN(MMCCLK1),
-
-	/* Port204 */
-	GPIO_FN(CS0_N),
-	GPIO_FN(SIM0_GPO1),
-
-	/* Port205 */
-	GPIO_FN(CS2_N),
-	GPIO_FN(SIM0_GPO2),
-
-	/* Port206 */
-	GPIO_FN(CS4_N),
-	GPIO_FN(VIO_VD),
-	GPIO_FN(SIM1_GPO0),
-
-	/* Port207 - Port212 FN1 */
-	GPIO_FN(D15),
-	GPIO_FN(D14),
-	GPIO_FN(D13),
-	GPIO_FN(D12),
-	GPIO_FN(D11),
-	GPIO_FN(D10),
-
-	/* Port207 - Port212 FN5 */
-	GPIO_FN(GIO_OUT15),
-	GPIO_FN(GIO_OUT14),
-	GPIO_FN(GIO_OUT13),
-	GPIO_FN(GIO_OUT12),
-	GPIO_FN(WGM_TXP2),
-	GPIO_FN(WGM_GPS_TIMEM_ASK_RFCLK),
-
-	/* Port213 - Port222 FN1 */
-	GPIO_FN(D9),
-	GPIO_FN(D8),
-	GPIO_FN(D7),
-	GPIO_FN(D6),
-	GPIO_FN(D5),
-	GPIO_FN(D4),
-	GPIO_FN(D3),
-	GPIO_FN(D2),
-	GPIO_FN(D1),
-	GPIO_FN(D0),
-
-	/* Port213 - Port222 FN2 */
-	GPIO_FN(VIO_D9),
-	GPIO_FN(VIO_D8),
-	GPIO_FN(VIO_D7),
-	GPIO_FN(VIO_D6),
-	GPIO_FN(VIO_D5),
-	GPIO_FN(VIO_D4),
-	GPIO_FN(VIO_D3),
-	GPIO_FN(VIO_D2),
-	GPIO_FN(VIO_D1),
-	GPIO_FN(VIO_D0),
-
-	/* Port213 - Port222 FN5 */
-	GPIO_FN(GIO_OUT9),
-	GPIO_FN(GIO_OUT8),
-	GPIO_FN(GIO_OUT7),
-	GPIO_FN(GIO_OUT6),
-	GPIO_FN(GIO_OUT5_217),
-	GPIO_FN(GIO_OUT4_218),
-	GPIO_FN(GIO_OUT3_219),
-	GPIO_FN(GIO_OUT2_220),
-	GPIO_FN(GIO_OUT1_221),
-	GPIO_FN(GIO_OUT0_222),
-
-	/* Port224 */
-	GPIO_FN(RDWR_224),
-	GPIO_FN(VIO_HD),
-	GPIO_FN(SIM1_GPO2),
-
-	/* Port225 */
-	GPIO_FN(RD_N),
-
-	/* Port226 */
-	GPIO_FN(WAIT_N),
-	GPIO_FN(VIO_CLK),
-	GPIO_FN(SIM1_GPO1),
-
-	/* Port227 */
-	GPIO_FN(WE0_N),
-	GPIO_FN(RDWR_227),
-
-	/* Port228 */
-	GPIO_FN(WE1_N),
-	GPIO_FN(SIM0_GPO0),
-
-	/* Port229 */
-	GPIO_FN(PWMO),
-	GPIO_FN(VIO_CKO1_229),
-
-	/* Port230 */
-	GPIO_FN(SLIM_CLK),
-	GPIO_FN(VIO_CKO4_230),
-
-	/* Port231 */
-	GPIO_FN(SLIM_DATA),
-	GPIO_FN(VIO_CKO5_231),
-
-	/* Port232 */
-	GPIO_FN(VIO_CKO2_232),
-	GPIO_FN(SF_PORT_0_232),
-
-	/* Port233 */
-	GPIO_FN(VIO_CKO3_233),
-	GPIO_FN(SF_PORT_1_233),
-
-	/* Port234 */
-	GPIO_FN(FSIACK),
-	GPIO_FN(PDM3_CLK_234),
-	GPIO_FN(ISP_IRIS1_234),
-
-	/* Port235 */
-	GPIO_FN(FSIAISLD),
-	GPIO_FN(PDM3_DATA_235),
-
-	/* Port236 */
-	GPIO_FN(FSIAOMC),
-	GPIO_FN(PDM0_OUTCLK_236),
-	GPIO_FN(ISP_IRIS0_236),
-
-	/* Port237 */
-	GPIO_FN(FSIAOLR),
-	GPIO_FN(FSIAILR),
-
-	/* Port238 */
-	GPIO_FN(FSIAOBT),
-	GPIO_FN(FSIAIBT),
-
-	/* Port239 */
-	GPIO_FN(FSIAOSLD),
-	GPIO_FN(PDM0_OUTDATA_239),
-
-	/* Port240 */
-	GPIO_FN(FSIBISLD),
-
-	/* Port241 */
-	GPIO_FN(FSIBOLR),
-	GPIO_FN(FSIBILR),
-
-	/* Port242 */
-	GPIO_FN(FSIBOMC),
-	GPIO_FN(ISP_SHUTTER1_242),
-
-	/* Port243 */
-	GPIO_FN(FSIBOBT),
-	GPIO_FN(FSIBIBT),
-
-	/* Port244 */
-	GPIO_FN(FSIBOSLD),
-	GPIO_FN(FSIASPDIF),
-
-	/* Port245 */
-	GPIO_FN(FSIBCK),
-	GPIO_FN(ISP_SHUTTER0_245),
-
-	/* Port246 - Port250 FN1 */
-	GPIO_FN(ISP_IRIS1_246),
-	GPIO_FN(ISP_IRIS0_247),
-	GPIO_FN(ISP_SHUTTER1_248),
-	GPIO_FN(ISP_SHUTTER0_249),
-	GPIO_FN(ISP_STROBE_250),
-
-	/* Port256 - Port258 */
-	GPIO_FN(MSIOF0_SYNC),
-	GPIO_FN(MSIOF0_RXD),
-	GPIO_FN(MSIOF0_SCK),
-
-	/* Port259 */
-	GPIO_FN(MSIOF0_SS2),
-	GPIO_FN(VIO_CKO3_259),
-
-	/* Port260 */
-	GPIO_FN(MSIOF0_TXD),
-
-	/* Port261 */
-	GPIO_FN(CHSCIF1_HSCK),
-
-	/* Port262 */
-
-	/* Port263 - Port266 FN1 */
-	GPIO_FN(MSIOF1_SS2),
-	GPIO_FN(MSIOF1_TXD),
-	GPIO_FN(MSIOF1_RXD),
-	GPIO_FN(MSIOF1_SS1),
-
-	/* Port263 - Port266 FN4 */
-	GPIO_FN(MSIOF5_SS2),
-	GPIO_FN(MSIOF5_TXD),
-	GPIO_FN(MSIOF5_RXD),
-	GPIO_FN(MSIOF5_SS1),
-
-	/* Port267 */
-	GPIO_FN(MSIOF0_SS1),
-
-	/* Port268 */
-	GPIO_FN(MSIOF1_SCK),
-	GPIO_FN(MSIOF5_SCK),
-
-	/* Port269 */
-	GPIO_FN(MSIOF1_SYNC),
-	GPIO_FN(MSIOF5_SYNC),
-
-	/* Port270 - Port273 FN1 */
-	GPIO_FN(MSIOF2_SS1),
-	GPIO_FN(MSIOF2_SS2),
-	GPIO_FN(MSIOF3_SS2),
-	GPIO_FN(MSIOF3_SS1),
-
-	/* Port270 - Port273 FN3 */
-	GPIO_FN(VIO_CKO5_270),
-	GPIO_FN(VIO_CKO2_271),
-	GPIO_FN(VIO_CKO1_272),
-	GPIO_FN(VIO_CKO4_273),
-
-	/* Port274 */
-	GPIO_FN(MSIOF4_SS2),
-	GPIO_FN(TPU1TO0),
-
-	/* Port275 - Port280 */
-	GPIO_FN(IC_DP),
-	GPIO_FN(SIM0_RST),
-	GPIO_FN(IC_DM),
-	GPIO_FN(SIM0_BSICOMP),
-	GPIO_FN(SIM0_CLK),
-	GPIO_FN(SIM0_IO),
-
-	/* Port281 */
-	GPIO_FN(SIM1_IO),
-	GPIO_FN(PDM2_DATA_281),
-
-	/* Port282 */
-	GPIO_FN(SIM1_CLK),
-	GPIO_FN(PDM2_CLK_282),
-
-	/* Port283 */
-	GPIO_FN(SIM1_RST),
-
-	/* Port289 */
-	GPIO_FN(SDHID1_0),
-	GPIO_FN(STMDATA0_2),
-
-	/* Port290 */
-	GPIO_FN(SDHID1_1),
-	GPIO_FN(STMDATA1_2),
-
-	/* Port291 - Port294 FN1 */
-	GPIO_FN(SDHID1_2),
-	GPIO_FN(SDHID1_3),
-	GPIO_FN(SDHICLK1),
-	GPIO_FN(SDHICMD1),
-
-	/* Port291 - Port294 FN3 */
-	GPIO_FN(STMDATA2_2),
-	GPIO_FN(STMDATA3_2),
-	GPIO_FN(STMCLK_2),
-	GPIO_FN(STMSIDI_2),
-
-	/* Port295 */
-	GPIO_FN(SDHID2_0),
-	GPIO_FN(MSIOF4_TXD),
-	GPIO_FN(MSIOF6_TXD),
-
-	/* Port296 */
-	GPIO_FN(SDHID2_1),
-	GPIO_FN(MSIOF6_SS2),
-
-	/* Port297 - Port300 FN1 */
-	GPIO_FN(SDHID2_2),
-	GPIO_FN(SDHID2_3),
-	GPIO_FN(SDHICLK2),
-	GPIO_FN(SDHICMD2),
-
-	/* Port297 - Port300 FN2 */
-	GPIO_FN(MSIOF4_RXD),
-	GPIO_FN(MSIOF4_SYNC),
-	GPIO_FN(MSIOF4_SCK),
-	GPIO_FN(MSIOF4_SS1),
-
-	/* Port297 - Port300 FN3 */
-
-	/* Port297 - Port300 FN4 */
-	GPIO_FN(MSIOF6_RXD),
-	GPIO_FN(MSIOF6_SYNC),
-	GPIO_FN(MSIOF6_SCK),
-	GPIO_FN(MSIOF6_SS1),
-
-	/* Port301 */
-	GPIO_FN(SDHICD0),
-
-	/* Port302 - Port306 FN1 */
-	GPIO_FN(SDHID0_0),
-	GPIO_FN(SDHID0_1),
-	GPIO_FN(SDHID0_2),
-	GPIO_FN(SDHID0_3),
-	GPIO_FN(SDHICMD0),
-
-	/* Port302 - Port306 FN3 */
-	GPIO_FN(STMDATA0_1),
-	GPIO_FN(STMDATA1_1),
-	GPIO_FN(STMDATA2_1),
-	GPIO_FN(STMDATA3_1),
-	GPIO_FN(STMSIDI_1),
-
-	/* Port307 */
-	GPIO_FN(SDHIWP0),
-
-	/* Port308 */
-	GPIO_FN(SDHICLK0),
-	GPIO_FN(STMCLK_1),
-
-	/* Port320 - Port329 */
-};
-
 static const struct pinmux_cfg_reg pinmux_config_regs[] = {
 
 	PORTCR(0, 0xe6050000),
@@ -3456,9 +2722,6 @@ const struct sh_pfc_soc_info r8a73a4_pinmux_info = {
 	.functions = pinmux_functions,
 	.nr_functions = ARRAY_SIZE(pinmux_functions),
 
-	.func_gpios = pinmux_func_gpios,
-	.nr_func_gpios = ARRAY_SIZE(pinmux_func_gpios),
-
 	.cfg_regs	= pinmux_config_regs,
 	.data_regs	= pinmux_data_regs,
 
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 01:09:35 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue,  2 Apr 2013 14:09:35 +0900
Subject: [PATCH 27/28] ARM: shmobile: r8a73a4: Remove all GPIO enums
In-Reply-To: <1364879376-10020-1-git-send-email-horms+renesas@verge.net.au>
References: <1364879376-10020-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364879376-10020-28-git-send-email-horms+renesas@verge.net.au>

From: Magnus Damm <damm at opensource.se>

Function GPIOs are not used anymore, and all code use the GPIO numbers
directly. Remove the GPIOs enumeration.

Signed-off-by: Magnus Damm <damm at opensource.se>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/include/mach/r8a73a4.h |  815 -------------------------
 1 file changed, 815 deletions(-)

diff --git a/arch/arm/mach-shmobile/include/mach/r8a73a4.h b/arch/arm/mach-shmobile/include/mach/r8a73a4.h
index 9162e86..f043103 100644
--- a/arch/arm/mach-shmobile/include/mach/r8a73a4.h
+++ b/arch/arm/mach-shmobile/include/mach/r8a73a4.h
@@ -1,821 +1,6 @@
 #ifndef __ASM_R8A73A4_H__
 #define __ASM_R8A73A4_H__
 
-/*
- * Pin Function Controller:
- *	GPIO_FN_xx - GPIO used to select pin function
- *	GPIO_PORTxx - GPIO mapped to real I/O pin on CPU
- */
-enum {
-
-	/* PORT */
-	GPIO_PORT0, GPIO_PORT1, GPIO_PORT2, GPIO_PORT3, GPIO_PORT4,
-	GPIO_PORT5, GPIO_PORT6, GPIO_PORT7, GPIO_PORT8, GPIO_PORT9,
-
-	GPIO_PORT10, GPIO_PORT11, GPIO_PORT12, GPIO_PORT13, GPIO_PORT14,
-	GPIO_PORT15, GPIO_PORT16, GPIO_PORT17, GPIO_PORT18, GPIO_PORT19,
-
-	GPIO_PORT20, GPIO_PORT21, GPIO_PORT22, GPIO_PORT23, GPIO_PORT24,
-	GPIO_PORT25, GPIO_PORT26, GPIO_PORT27, GPIO_PORT28, GPIO_PORT29,
-
-	GPIO_PORT30, GPIO_PORT32, GPIO_PORT33, GPIO_PORT34,
-	GPIO_PORT35, GPIO_PORT36, GPIO_PORT37, GPIO_PORT38, GPIO_PORT39,
-
-	GPIO_PORT40, GPIO_PORT64,
-	GPIO_PORT65, GPIO_PORT66, GPIO_PORT67, GPIO_PORT68, GPIO_PORT69,
-
-	GPIO_PORT70, GPIO_PORT71, GPIO_PORT72, GPIO_PORT73, GPIO_PORT74,
-	GPIO_PORT75, GPIO_PORT76, GPIO_PORT77, GPIO_PORT78, GPIO_PORT79,
-
-	GPIO_PORT80, GPIO_PORT81, GPIO_PORT82, GPIO_PORT83, GPIO_PORT84,
-	GPIO_PORT85, GPIO_PORT96, GPIO_PORT97, GPIO_PORT98, GPIO_PORT99,
-
-	GPIO_PORT100, GPIO_PORT101, GPIO_PORT102, GPIO_PORT103, GPIO_PORT104,
-	GPIO_PORT105, GPIO_PORT106, GPIO_PORT107, GPIO_PORT108, GPIO_PORT109,
-
-	GPIO_PORT110, GPIO_PORT111, GPIO_PORT112, GPIO_PORT113, GPIO_PORT114,
-	GPIO_PORT115, GPIO_PORT116, GPIO_PORT117, GPIO_PORT118, GPIO_PORT119,
-
-	GPIO_PORT120, GPIO_PORT121, GPIO_PORT122, GPIO_PORT123, GPIO_PORT124,
-	GPIO_PORT125, GPIO_PORT126, GPIO_PORT128, GPIO_PORT129,
-
-	GPIO_PORT130, GPIO_PORT131, GPIO_PORT132, GPIO_PORT133, GPIO_PORT134,
-
-	GPIO_PORT160, GPIO_PORT161, GPIO_PORT162, GPIO_PORT163, GPIO_PORT164,
-	GPIO_PORT165, GPIO_PORT166, GPIO_PORT167, GPIO_PORT168, GPIO_PORT169,
-
-	GPIO_PORT170, GPIO_PORT171, GPIO_PORT172, GPIO_PORT173, GPIO_PORT174,
-	GPIO_PORT175, GPIO_PORT176, GPIO_PORT177, GPIO_PORT178,
-
-	GPIO_PORT192, GPIO_PORT193, GPIO_PORT194,
-	GPIO_PORT195, GPIO_PORT196, GPIO_PORT197, GPIO_PORT198, GPIO_PORT199,
-
-	GPIO_PORT200, GPIO_PORT201, GPIO_PORT202, GPIO_PORT203, GPIO_PORT204,
-	GPIO_PORT205, GPIO_PORT206, GPIO_PORT207, GPIO_PORT208, GPIO_PORT209,
-
-	GPIO_PORT210, GPIO_PORT211, GPIO_PORT212, GPIO_PORT213, GPIO_PORT214,
-	GPIO_PORT215, GPIO_PORT216, GPIO_PORT217, GPIO_PORT218, GPIO_PORT219,
-
-	GPIO_PORT220, GPIO_PORT221, GPIO_PORT222, GPIO_PORT224,
-	GPIO_PORT225, GPIO_PORT226, GPIO_PORT227, GPIO_PORT228, GPIO_PORT229,
-
-	GPIO_PORT230, GPIO_PORT231, GPIO_PORT232, GPIO_PORT233, GPIO_PORT234,
-	GPIO_PORT235, GPIO_PORT236, GPIO_PORT237, GPIO_PORT238, GPIO_PORT239,
-
-	GPIO_PORT240, GPIO_PORT241, GPIO_PORT242, GPIO_PORT243, GPIO_PORT244,
-	GPIO_PORT245, GPIO_PORT246, GPIO_PORT247, GPIO_PORT248, GPIO_PORT249,
-
-	GPIO_PORT250, GPIO_PORT256, GPIO_PORT257, GPIO_PORT258, GPIO_PORT259,
-
-	GPIO_PORT260, GPIO_PORT261, GPIO_PORT262, GPIO_PORT263, GPIO_PORT264,
-	GPIO_PORT265, GPIO_PORT266, GPIO_PORT267, GPIO_PORT268, GPIO_PORT269,
-
-	GPIO_PORT270, GPIO_PORT271, GPIO_PORT272, GPIO_PORT273, GPIO_PORT274,
-	GPIO_PORT275, GPIO_PORT276, GPIO_PORT277, GPIO_PORT278, GPIO_PORT279,
-
-	GPIO_PORT280, GPIO_PORT281, GPIO_PORT282, GPIO_PORT283,
-	GPIO_PORT288, GPIO_PORT289,
-
-	GPIO_PORT290, GPIO_PORT291, GPIO_PORT292, GPIO_PORT293, GPIO_PORT294,
-	GPIO_PORT295, GPIO_PORT296, GPIO_PORT297, GPIO_PORT298, GPIO_PORT299,
-
-	GPIO_PORT300, GPIO_PORT301, GPIO_PORT302, GPIO_PORT303, GPIO_PORT304,
-	GPIO_PORT305, GPIO_PORT306, GPIO_PORT307, GPIO_PORT308,
-
-	GPIO_PORT320, GPIO_PORT321, GPIO_PORT322, GPIO_PORT323, GPIO_PORT324,
-	GPIO_PORT325, GPIO_PORT326, GPIO_PORT327, GPIO_PORT328, GPIO_PORT329,
-
-	/* Port0 */
-	GPIO_FN_LCDD0 = 330,
-	GPIO_FN_PDM2_CLK_0,
-	GPIO_FN_DU0_DR0,
-
-	/* Port1 */
-	GPIO_FN_LCDD1,
-	GPIO_FN_PDM2_DATA_1,
-	GPIO_FN_DU0_DR19,
-
-	/* Port2 */
-	GPIO_FN_LCDD2,
-	GPIO_FN_PDM3_CLK_2,
-	GPIO_FN_DU0_DR2,
-
-	/* Port3 */
-	GPIO_FN_LCDD3,
-	GPIO_FN_PDM3_DATA_3,
-	GPIO_FN_DU0_DR3,
-
-	/* Port4 */
-	GPIO_FN_LCDD4,
-	GPIO_FN_PDM4_CLK_4,
-	GPIO_FN_DU0_DR4,
-
-	/* Port5 */
-	GPIO_FN_LCDD5,
-	GPIO_FN_PDM4_DATA_5,
-	GPIO_FN_DU0_DR5,
-
-	/* Port6 */
-	GPIO_FN_LCDD6,
-	GPIO_FN_PDM0_OUTCLK_6,
-	GPIO_FN_DU0_DR6,
-
-	/* Port7 */
-	GPIO_FN_LCDD7,
-	GPIO_FN_PDM0_OUTDATA_7,
-	GPIO_FN_DU0_DR7,
-
-	/* Port8 */
-	GPIO_FN_LCDD8,
-	GPIO_FN_PDM1_OUTCLK_8,
-	GPIO_FN_DU0_DG0,
-
-	/* Port9 */
-	GPIO_FN_LCDD9,
-	GPIO_FN_PDM1_OUTDATA_9,
-	GPIO_FN_DU0_DG1,
-
-	/* Port10 */
-	GPIO_FN_LCDD10,
-	GPIO_FN_FSICCK,
-	GPIO_FN_DU0_DG2,
-
-	/* Port11 */
-	GPIO_FN_LCDD11,
-	GPIO_FN_FSICISLD,
-	GPIO_FN_DU0_DG3,
-
-	/* Port12 */
-	GPIO_FN_LCDD12,
-	GPIO_FN_FSICOMC,
-	GPIO_FN_DU0_DG4,
-
-	/* Port13 */
-	GPIO_FN_LCDD13,
-	GPIO_FN_FSICOLR,
-	GPIO_FN_FSICILR,
-	GPIO_FN_DU0_DG5,
-
-	/* Port14 */
-	GPIO_FN_LCDD14,
-	GPIO_FN_FSICOBT,
-	GPIO_FN_FSICIBT,
-	GPIO_FN_DU0_DG6,
-
-	/* Port15 */
-	GPIO_FN_LCDD15,
-	GPIO_FN_FSICOSLD,
-	GPIO_FN_DU0_DG7,
-
-	/* Port16 */
-	GPIO_FN_LCDD16,
-	GPIO_FN_TPU1TO1,
-	GPIO_FN_DU0_DB0,
-
-	/* Port17 */
-	GPIO_FN_LCDD17,
-	GPIO_FN_SF_IRQ_00,
-	GPIO_FN_DU0_DB1,
-
-	/* Port18 */
-	GPIO_FN_LCDD18,
-	GPIO_FN_SF_IRQ_01,
-	GPIO_FN_DU0_DB2,
-
-	/* Port19 */
-	GPIO_FN_LCDD19,
-	GPIO_FN_DU0_DB3,
-
-	/* Port20 */
-	GPIO_FN_LCDD20,
-	GPIO_FN_DU0_DB4,
-
-	/* Port21 */
-	GPIO_FN_LCDD21,
-	GPIO_FN_DU0_DB5,
-
-	/* Port22 */
-	GPIO_FN_LCDD22,
-	GPIO_FN_DU0_DB6,
-
-	/* Port23 */
-	GPIO_FN_LCDD23,
-	GPIO_FN_DU0_DB7,
-
-	/* Port24 */
-	GPIO_FN_LCDHSYN,
-	GPIO_FN_LCDCS,
-	GPIO_FN_DU0_EXHSYNC_N_CSYNC_N_HSYNC_N,
-
-	/* Port25 */
-	GPIO_FN_LCDVSYN,
-	GPIO_FN_DU0_EXVSYNC_N_VSYNC_N_CSYNC_N,
-
-	/* Port26 */
-	GPIO_FN_LCDDCK,
-	GPIO_FN_LCDWR,
-	GPIO_FN_DU0_DOTCLKIN,
-
-	/* Port27 */
-	GPIO_FN_LCDDISP,
-	GPIO_FN_LCDRS,
-	GPIO_FN_DU0_DOTCLKOUT,
-
-	/* Port28 */
-	GPIO_FN_LCDRD_N,
-	GPIO_FN_DU0_DOTCLKOUTB,
-
-	/* Port29 */
-	GPIO_FN_LCDLCLK,
-	GPIO_FN_SF_IRQ_02,
-	GPIO_FN_DU0_DISP_CSYNC_N_DE,
-
-	/* Port30 */
-	GPIO_FN_LCDDON,
-	GPIO_FN_SF_IRQ_03,
-	GPIO_FN_DU0_ODDF_N_CLAMP,
-
-	/* Port32 */
-	GPIO_FN_SIM0_DET,
-	GPIO_FN_CSCIF0_RTS,
-
-	/* Port33 */
-	GPIO_FN_SIM1_DET,
-	GPIO_FN_CSCIF0_CTS,
-
-	/* Port34 */
-	GPIO_FN_SIM0_PWRON,
-	GPIO_FN_CSCIF0_SCK,
-
-	/* Port35 */
-	GPIO_FN_CSCIF1_RTS,
-
-	/* Port36 */
-	GPIO_FN_CSCIF1_CTS,
-
-	/* Port37 */
-	GPIO_FN_CSCIF1_SCK,
-
-	/* Port38 */
-	GPIO_FN_TPU0TO1,
-	GPIO_FN_CHSCIF0_HRTS,
-
-	/* Port39 */
-	GPIO_FN_TPU0TO2,
-	GPIO_FN_CHSCIF0_HCTS,
-
-	/* Port40 */
-	GPIO_FN_TPU0TO3,
-	GPIO_FN_CHSCIF0_HSCK,
-
-	/* Port64 */
-	GPIO_FN_PDM0_DATA,
-
-	/* Port65 */
-	GPIO_FN_PDM1_DATA,
-
-	/* Port66 */
-	GPIO_FN_HSI_RX_WAKE,
-	GPIO_FN_MSIOF3_SYNC,
-	GPIO_FN_GenIO4,
-
-	/* Port67 */
-	GPIO_FN_HSI_RX_READY,
-	GPIO_FN_GIO_OUT3_67,
-	GPIO_FN_CHSCIF1_HTX,
-
-	/* Port68 */
-	GPIO_FN_HSI_RX_FLAG,
-	GPIO_FN_MSIOF3_TXD,
-	GPIO_FN_GIO_OUT4_68,
-
-	/* Port69 */
-	GPIO_FN_HSI_RX_DATA,
-	GPIO_FN_MSIOF3_RXD,
-	GPIO_FN_GIO_OUT5_69,
-
-	/* Port70 */
-	GPIO_FN_HSI_TX_FLAG,
-	GPIO_FN_GIO_OUT1_70,
-	GPIO_FN_HSIC_TSTCLK0,
-	GPIO_FN_CHSCIF1_HRTS,
-
-	/* Port71 */
-	GPIO_FN_HSI_TX_DATA,
-	GPIO_FN_GIO_OUT2_71,
-	GPIO_FN_HSIC_TSTCLK1,
-	GPIO_FN_CHSCIF1_HCTS,
-
-	/* Port72 */
-	GPIO_FN_HSI_TX_WAKE,
-	GPIO_FN_GenIO8,
-	GPIO_FN_CHSCIF1_HRX,
-
-	/* Port73 */
-	GPIO_FN_HSI_TX_READY,
-	GPIO_FN_MSIOF3_SCK,
-	GPIO_FN_GIO_OUT0_73,
-
-	/* Port74 - Port85 */
-	GPIO_FN_IRDA_OUT,
-	GPIO_FN_IRDA_IN,
-	GPIO_FN_IRDA_FIRSEL,
-	GPIO_FN_TPU0TO0,
-	GPIO_FN_DIGRFEN,
-	GPIO_FN_GPS_TIMESTAMP,
-	GPIO_FN_TXP,
-	GPIO_FN_TXP2,
-	GPIO_FN_COEX_0,
-	GPIO_FN_COEX_1,
-
-	/* Port96 - Port101 */
-	GPIO_FN_KEYIN0,
-	GPIO_FN_KEYIN1,
-	GPIO_FN_KEYIN2,
-	GPIO_FN_KEYIN3,
-	GPIO_FN_KEYIN4,
-	GPIO_FN_KEYIN5,
-
-	/* Port102 */
-	GPIO_FN_KEYIN6,
-
-	/* Port103 */
-	GPIO_FN_KEYIN7,
-
-	/* Port104 - Port108 */
-	GPIO_FN_KEYOUT0,
-	GPIO_FN_KEYOUT1,
-	GPIO_FN_KEYOUT2,
-	GPIO_FN_KEYOUT3,
-	GPIO_FN_KEYOUT4,
-
-	/* Port109 */
-	GPIO_FN_KEYOUT5,
-
-	/* Port110 */
-	GPIO_FN_KEYOUT6,
-
-	/* Port111 */
-	GPIO_FN_KEYOUT7,
-	GPIO_FN_RFANAEN,
-
-	/* Port112 */
-	GPIO_FN_KEYIN8,
-	GPIO_FN_KEYOUT8,
-	GPIO_FN_SF_IRQ_04,
-
-	/* Port113 */
-	GPIO_FN_KEYIN9,
-	GPIO_FN_KEYOUT9,
-	GPIO_FN_SF_IRQ_05,
-
-	/* Port114 */
-	GPIO_FN_KEYIN10,
-	GPIO_FN_KEYOUT10,
-	GPIO_FN_SF_IRQ_06,
-
-	/* Port115 */
-	GPIO_FN_KEYIN11,
-	GPIO_FN_KEYOUT11,
-	GPIO_FN_SF_IRQ_07,
-
-	/* Port116 */
-	GPIO_FN_CSCIF0_TX,
-
-	/* Port117 */
-	GPIO_FN_CSCIF0_RX,
-
-	/* Port118 */
-	GPIO_FN_CSCIF1_TX,
-
-	/* Port119 */
-	GPIO_FN_CSCIF1_RX,
-
-	/* Port120 */
-	GPIO_FN_SF_PORT_1_120,
-	GPIO_FN_DU0_CDE,
-
-	/* Port121 */
-	GPIO_FN_SF_PORT_0_121,
-
-	/* Port122 */
-	GPIO_FN_CHSCIF0_HTX,
-
-	/* Port123 */
-	GPIO_FN_CHSCIF0_HRX,
-
-	/* Port124 */
-	GPIO_FN_ISP_STROBE_124,
-
-	/* Port125 */
-	GPIO_FN_STP_ISD_0,
-	GPIO_FN_PDM4_CLK_125,
-	GPIO_FN_MSIOF2_TXD,
-	GPIO_FN_SIM0_VOLTSEL0,
-
-	/* Port126 */
-	GPIO_FN_TS_SDEN,
-	GPIO_FN_MSIOF7_SYNC,
-	GPIO_FN_STP_ISEN_1,
-
-	/* Port128 */
-	GPIO_FN_STP_ISEN_0,
-	GPIO_FN_PDM1_OUTDATA_128,
-	GPIO_FN_MSIOF2_SYNC,
-	GPIO_FN_SIM1_VOLTSEL1,
-
-	/* Port129 */
-	GPIO_FN_TS_SPSYNC,
-	GPIO_FN_MSIOF7_RXD,
-	GPIO_FN_STP_ISSYNC_1,
-
-	/* Port130 */
-	GPIO_FN_STP_ISSYNC_0,
-	GPIO_FN_PDM4_DATA_130,
-	GPIO_FN_MSIOF2_RXD,
-	GPIO_FN_SIM0_VOLTSEL1,
-
-	/* Port131 */
-	GPIO_FN_STP_OPWM_0,
-	GPIO_FN_SIM1_PWRON,
-
-	/* Port132 */
-	GPIO_FN_TS_SCK,
-	GPIO_FN_MSIOF7_SCK,
-	GPIO_FN_STP_ISCLK_1,
-
-	/* Port133 */
-	GPIO_FN_STP_ISCLK_0,
-	GPIO_FN_PDM1_OUTCLK_133,
-	GPIO_FN_MSIOF2_SCK,
-	GPIO_FN_SIM1_VOLTSEL0,
-
-	/* Port134 */
-	GPIO_FN_TS_SDAT,
-	GPIO_FN_MSIOF7_TXD,
-	GPIO_FN_STP_ISD_1,
-
-	/* Port160 - Port178 */
-	GPIO_FN_MMCD0_0,
-	GPIO_FN_MMCD0_1,
-	GPIO_FN_MMCD0_2,
-	GPIO_FN_MMCD0_3,
-	GPIO_FN_MMCD0_4,
-	GPIO_FN_MMCD0_5,
-	GPIO_FN_MMCD0_6,
-	GPIO_FN_MMCD0_7,
-	GPIO_FN_MMCCMD0,
-	GPIO_FN_MMCCLK0,
-	GPIO_FN_MMCRST,
-
-	/* Port192 - Port200 FN1 */
-	GPIO_FN_A10,
-	GPIO_FN_A9,
-	GPIO_FN_A8,
-	GPIO_FN_A7,
-	GPIO_FN_A6,
-	GPIO_FN_A5,
-	GPIO_FN_A4,
-	GPIO_FN_A3,
-	GPIO_FN_A2,
-
-	/* Port192 - Port200 FN2 */
-	GPIO_FN_MMCD1_7,
-	GPIO_FN_MMCD1_6,
-	GPIO_FN_MMCD1_5,
-	GPIO_FN_MMCD1_4,
-	GPIO_FN_MMCD1_3,
-	GPIO_FN_MMCD1_2,
-	GPIO_FN_MMCD1_1,
-	GPIO_FN_MMCD1_0,
-	GPIO_FN_MMCCMD1,
-
-	/* Port192 - Port200 IRQ */
-
-	/* Port201 */
-	GPIO_FN_A1,
-
-	/* Port202 */
-	GPIO_FN_A0,
-	GPIO_FN_BS,
-
-	/* Port203 */
-	GPIO_FN_CKO,
-	GPIO_FN_MMCCLK1,
-
-	/* Port204 */
-	GPIO_FN_CS0_N,
-	GPIO_FN_SIM0_GPO1,
-
-	/* Port205 */
-	GPIO_FN_CS2_N,
-	GPIO_FN_SIM0_GPO2,
-
-	/* Port206 */
-	GPIO_FN_CS4_N,
-	GPIO_FN_VIO_VD,
-	GPIO_FN_SIM1_GPO0,
-
-	/* Port207 - Port212 FN1 */
-	GPIO_FN_D15,
-	GPIO_FN_D14,
-	GPIO_FN_D13,
-	GPIO_FN_D12,
-	GPIO_FN_D11,
-	GPIO_FN_D10,
-
-	/* Port207 - Port212 FN5 */
-	GPIO_FN_GIO_OUT15,
-	GPIO_FN_GIO_OUT14,
-	GPIO_FN_GIO_OUT13,
-	GPIO_FN_GIO_OUT12,
-	GPIO_FN_WGM_TXP2,
-	GPIO_FN_WGM_GPS_TIMEM_ASK_RFCLK,
-
-	/* Port213 - Port222 FN1 */
-	GPIO_FN_D9,
-	GPIO_FN_D8,
-	GPIO_FN_D7,
-	GPIO_FN_D6,
-	GPIO_FN_D5,
-	GPIO_FN_D4,
-	GPIO_FN_D3,
-	GPIO_FN_D2,
-	GPIO_FN_D1,
-	GPIO_FN_D0,
-
-	/* Port213 - Port222 FN2 */
-	GPIO_FN_VIO_D9,
-	GPIO_FN_VIO_D8,
-	GPIO_FN_VIO_D7,
-	GPIO_FN_VIO_D6,
-	GPIO_FN_VIO_D5,
-	GPIO_FN_VIO_D4,
-	GPIO_FN_VIO_D3,
-	GPIO_FN_VIO_D2,
-	GPIO_FN_VIO_D1,
-	GPIO_FN_VIO_D0,
-
-	/* Port213 - Port222 FN5 */
-	GPIO_FN_GIO_OUT9,
-	GPIO_FN_GIO_OUT8,
-	GPIO_FN_GIO_OUT7,
-	GPIO_FN_GIO_OUT6,
-	GPIO_FN_GIO_OUT5_217,
-	GPIO_FN_GIO_OUT4_218,
-	GPIO_FN_GIO_OUT3_219,
-	GPIO_FN_GIO_OUT2_220,
-	GPIO_FN_GIO_OUT1_221,
-	GPIO_FN_GIO_OUT0_222,
-
-	/* Port224 */
-	GPIO_FN_RDWR_224,
-	GPIO_FN_VIO_HD,
-	GPIO_FN_SIM1_GPO2,
-
-	/* Port225 */
-	GPIO_FN_RD_N,
-
-	/* Port226 */
-	GPIO_FN_WAIT_N,
-	GPIO_FN_VIO_CLK,
-	GPIO_FN_SIM1_GPO1,
-
-	/* Port227 */
-	GPIO_FN_WE0_N,
-	GPIO_FN_RDWR_227,
-
-	/* Port228 */
-	GPIO_FN_WE1_N,
-	GPIO_FN_SIM0_GPO0,
-
-	/* Port229 */
-	GPIO_FN_PWMO,
-	GPIO_FN_VIO_CKO1_229,
-
-	/* Port230 */
-	GPIO_FN_SLIM_CLK,
-	GPIO_FN_VIO_CKO4_230,
-
-	/* Port231 */
-	GPIO_FN_SLIM_DATA,
-	GPIO_FN_VIO_CKO5_231,
-
-	/* Port232 */
-	GPIO_FN_VIO_CKO2_232,
-	GPIO_FN_SF_PORT_0_232,
-
-	/* Port233 */
-	GPIO_FN_VIO_CKO3_233,
-	GPIO_FN_SF_PORT_1_233,
-
-	/* Port234 */
-	GPIO_FN_FSIACK,
-	GPIO_FN_PDM3_CLK_234,
-	GPIO_FN_ISP_IRIS1_234,
-
-	/* Port235 */
-	GPIO_FN_FSIAISLD,
-	GPIO_FN_PDM3_DATA_235,
-
-	/* Port236 */
-	GPIO_FN_FSIAOMC,
-	GPIO_FN_PDM0_OUTCLK_236,
-	GPIO_FN_ISP_IRIS0_236,
-
-	/* Port237 */
-	GPIO_FN_FSIAOLR,
-	GPIO_FN_FSIAILR,
-
-	/* Port238 */
-	GPIO_FN_FSIAOBT,
-	GPIO_FN_FSIAIBT,
-
-	/* Port239 */
-	GPIO_FN_FSIAOSLD,
-	GPIO_FN_PDM0_OUTDATA_239,
-
-	/* Port240 */
-	GPIO_FN_FSIBISLD,
-
-	/* Port241 */
-	GPIO_FN_FSIBOLR,
-	GPIO_FN_FSIBILR,
-
-	/* Port242 */
-	GPIO_FN_FSIBOMC,
-	GPIO_FN_ISP_SHUTTER1_242,
-
-	/* Port243 */
-	GPIO_FN_FSIBOBT,
-	GPIO_FN_FSIBIBT,
-
-	/* Port244 */
-	GPIO_FN_FSIBOSLD,
-	GPIO_FN_FSIASPDIF,
-
-	/* Port245 */
-	GPIO_FN_FSIBCK,
-	GPIO_FN_ISP_SHUTTER0_245,
-
-	/* Port246 - Port250 FN1 */
-	GPIO_FN_ISP_IRIS1_246,
-	GPIO_FN_ISP_IRIS0_247,
-	GPIO_FN_ISP_SHUTTER1_248,
-	GPIO_FN_ISP_SHUTTER0_249,
-	GPIO_FN_ISP_STROBE_250,
-
-	/* Port256 - Port258 */
-	GPIO_FN_MSIOF0_SYNC,
-	GPIO_FN_MSIOF0_RXD,
-	GPIO_FN_MSIOF0_SCK,
-
-	/* Port259 */
-	GPIO_FN_MSIOF0_SS2,
-	GPIO_FN_VIO_CKO3_259,
-
-	/* Port260 */
-	GPIO_FN_MSIOF0_TXD,
-
-	/* Port261 */
-	GPIO_FN_CHSCIF1_HSCK,
-
-	/* Port262 */
-
-	/* Port263 - Port266 FN1 */
-	GPIO_FN_MSIOF1_SS2,
-	GPIO_FN_MSIOF1_TXD,
-	GPIO_FN_MSIOF1_RXD,
-	GPIO_FN_MSIOF1_SS1,
-
-	/* Port263 - Port266 FN4 */
-	GPIO_FN_MSIOF5_SS2,
-	GPIO_FN_MSIOF5_TXD,
-	GPIO_FN_MSIOF5_RXD,
-	GPIO_FN_MSIOF5_SS1,
-
-	/* Port267 */
-	GPIO_FN_MSIOF0_SS1,
-
-	/* Port268 */
-	GPIO_FN_MSIOF1_SCK,
-	GPIO_FN_MSIOF5_SCK,
-
-	/* Port269 */
-	GPIO_FN_MSIOF1_SYNC,
-	GPIO_FN_MSIOF5_SYNC,
-
-	/* Port270 - Port273 FN1 */
-	GPIO_FN_MSIOF2_SS1,
-	GPIO_FN_MSIOF2_SS2,
-	GPIO_FN_MSIOF3_SS2,
-	GPIO_FN_MSIOF3_SS1,
-
-	/* Port270 - Port273 FN3 */
-	GPIO_FN_VIO_CKO5_270,
-	GPIO_FN_VIO_CKO2_271,
-	GPIO_FN_VIO_CKO1_272,
-	GPIO_FN_VIO_CKO4_273,
-
-	/* Port274 */
-	GPIO_FN_MSIOF4_SS2,
-	GPIO_FN_TPU1TO0,
-
-	/* Port275 - Port280 */
-	GPIO_FN_IC_DP,
-	GPIO_FN_SIM0_RST,
-	GPIO_FN_IC_DM,
-	GPIO_FN_SIM0_BSICOMP,
-	GPIO_FN_SIM0_CLK,
-	GPIO_FN_SIM0_IO,
-
-	/* Port281 */
-	GPIO_FN_SIM1_IO,
-	GPIO_FN_PDM2_DATA_281,
-
-	/* Port282 */
-	GPIO_FN_SIM1_CLK,
-	GPIO_FN_PDM2_CLK_282,
-
-	/* Port283 */
-	GPIO_FN_SIM1_RST,
-
-	/* Port289 */
-	GPIO_FN_SDHID1_0,
-	GPIO_FN_STMDATA0_2,
-
-	/* Port290 */
-	GPIO_FN_SDHID1_1,
-	GPIO_FN_STMDATA1_2,
-
-	/* Port291 - Port294 FN1 */
-	GPIO_FN_SDHID1_2,
-	GPIO_FN_SDHID1_3,
-	GPIO_FN_SDHICLK1,
-	GPIO_FN_SDHICMD1,
-
-	/* Port291 - Port294 FN3 */
-	GPIO_FN_STMDATA2_2,
-	GPIO_FN_STMDATA3_2,
-	GPIO_FN_STMCLK_2,
-	GPIO_FN_STMSIDI_2,
-
-	/* Port295 */
-	GPIO_FN_SDHID2_0,
-	GPIO_FN_MSIOF4_TXD,
-	GPIO_FN_MSIOF6_TXD,
-
-	/* Port296 */
-	GPIO_FN_SDHID2_1,
-	GPIO_FN_MSIOF6_SS2,
-
-	/* Port297 - Port300 FN1 */
-	GPIO_FN_SDHID2_2,
-	GPIO_FN_SDHID2_3,
-	GPIO_FN_SDHICLK2,
-	GPIO_FN_SDHICMD2,
-
-	/* Port297 - Port300 FN2 */
-	GPIO_FN_MSIOF4_RXD,
-	GPIO_FN_MSIOF4_SYNC,
-	GPIO_FN_MSIOF4_SCK,
-	GPIO_FN_MSIOF4_SS1,
-
-	/* Port297 - Port300 FN3 */
-
-	/* Port297 - Port300 FN4 */
-	GPIO_FN_MSIOF6_RXD,
-	GPIO_FN_MSIOF6_SYNC,
-	GPIO_FN_MSIOF6_SCK,
-	GPIO_FN_MSIOF6_SS1,
-
-	/* Port301 */
-	GPIO_FN_SDHICD0,
-
-	/* Port302 - Port306 FN1 */
-	GPIO_FN_SDHID0_0,
-	GPIO_FN_SDHID0_1,
-	GPIO_FN_SDHID0_2,
-	GPIO_FN_SDHID0_3,
-	GPIO_FN_SDHICMD0,
-
-	/* Port302 - Port306 FN3 */
-	GPIO_FN_STMDATA0_1,
-	GPIO_FN_STMDATA1_1,
-	GPIO_FN_STMDATA2_1,
-	GPIO_FN_STMDATA3_1,
-	GPIO_FN_STMSIDI_1,
-
-	/* Port307 */
-	GPIO_FN_SDHIWP0,
-
-	/* Port308 */
-	GPIO_FN_SDHICLK0,
-	GPIO_FN_STMCLK_1,
-
-	/* Port320 - Port329 */
-};
-
 void r8a73a4_add_standard_devices(void);
 void r8a73a4_clock_init(void);
 void r8a73a4_pinmux_init(void);
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 01:09:24 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue,  2 Apr 2013 14:09:24 +0900
Subject: [PATCH 16/28] sh-pfc: Add r8a73a4 pinmux support
In-Reply-To: <1364879376-10020-1-git-send-email-horms+renesas@verge.net.au>
References: <1364879376-10020-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364879376-10020-17-git-send-email-horms+renesas@verge.net.au>

From: Magnus Damm <damm at opensource.se>

Add initial PFC support for the r8a73a4 SoC.

At this point only GPIO interface is supported, move to newer interfaces
planned as incremental changes.

Original authors are Morimoto-san with help from Yoshii-san, thanks to
them for the heavy lifting. Adjusted by Magnus to work together with
updated code in drivers/pinctrl.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Signed-off-by: Takashi Yoshii <takashi.yoshii.zj at renesas.com>
Signed-off-by: Magnus Damm <damm at opensource.se>
Acked-by: Linus Walleij <linus.walleij at linaro.org>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/include/mach/r8a73a4.h |  918 ++++++++
 drivers/pinctrl/sh-pfc/Kconfig                |    5 +
 drivers/pinctrl/sh-pfc/Makefile               |    1 +
 drivers/pinctrl/sh-pfc/core.c                 |    3 +
 drivers/pinctrl/sh-pfc/core.h                 |    1 +
 drivers/pinctrl/sh-pfc/pfc-r8a73a4.c          | 2826 +++++++++++++++++++++++++
 6 files changed, 3754 insertions(+)
 create mode 100644 drivers/pinctrl/sh-pfc/pfc-r8a73a4.c

diff --git a/arch/arm/mach-shmobile/include/mach/r8a73a4.h b/arch/arm/mach-shmobile/include/mach/r8a73a4.h
index f043103..f0b1b4a 100644
--- a/arch/arm/mach-shmobile/include/mach/r8a73a4.h
+++ b/arch/arm/mach-shmobile/include/mach/r8a73a4.h
@@ -1,6 +1,924 @@
 #ifndef __ASM_R8A73A4_H__
 #define __ASM_R8A73A4_H__
 
+/*
+ * Pin Function Controller:
+ *	GPIO_FN_xx - GPIO used to select pin function
+ *	GPIO_PORTxx - GPIO mapped to real I/O pin on CPU
+ */
+enum {
+
+	/* PORT */
+	GPIO_PORT0, GPIO_PORT1, GPIO_PORT2, GPIO_PORT3, GPIO_PORT4,
+	GPIO_PORT5, GPIO_PORT6, GPIO_PORT7, GPIO_PORT8, GPIO_PORT9,
+
+	GPIO_PORT10, GPIO_PORT11, GPIO_PORT12, GPIO_PORT13, GPIO_PORT14,
+	GPIO_PORT15, GPIO_PORT16, GPIO_PORT17, GPIO_PORT18, GPIO_PORT19,
+
+	GPIO_PORT20, GPIO_PORT21, GPIO_PORT22, GPIO_PORT23, GPIO_PORT24,
+	GPIO_PORT25, GPIO_PORT26, GPIO_PORT27, GPIO_PORT28, GPIO_PORT29,
+
+	GPIO_PORT30, GPIO_PORT32, GPIO_PORT33, GPIO_PORT34,
+	GPIO_PORT35, GPIO_PORT36, GPIO_PORT37, GPIO_PORT38, GPIO_PORT39,
+
+	GPIO_PORT40, GPIO_PORT64,
+	GPIO_PORT65, GPIO_PORT66, GPIO_PORT67, GPIO_PORT68, GPIO_PORT69,
+
+	GPIO_PORT70, GPIO_PORT71, GPIO_PORT72, GPIO_PORT73, GPIO_PORT74,
+	GPIO_PORT75, GPIO_PORT76, GPIO_PORT77, GPIO_PORT78, GPIO_PORT79,
+
+	GPIO_PORT80, GPIO_PORT81, GPIO_PORT82, GPIO_PORT83, GPIO_PORT84,
+	GPIO_PORT85, GPIO_PORT96, GPIO_PORT97, GPIO_PORT98, GPIO_PORT99,
+
+	GPIO_PORT100, GPIO_PORT101, GPIO_PORT102, GPIO_PORT103, GPIO_PORT104,
+	GPIO_PORT105, GPIO_PORT106, GPIO_PORT107, GPIO_PORT108, GPIO_PORT109,
+
+	GPIO_PORT110, GPIO_PORT111, GPIO_PORT112, GPIO_PORT113, GPIO_PORT114,
+	GPIO_PORT115, GPIO_PORT116, GPIO_PORT117, GPIO_PORT118, GPIO_PORT119,
+
+	GPIO_PORT120, GPIO_PORT121, GPIO_PORT122, GPIO_PORT123, GPIO_PORT124,
+	GPIO_PORT125, GPIO_PORT126, GPIO_PORT128, GPIO_PORT129,
+
+	GPIO_PORT130, GPIO_PORT131, GPIO_PORT132, GPIO_PORT133, GPIO_PORT134,
+
+	GPIO_PORT160, GPIO_PORT161, GPIO_PORT162, GPIO_PORT163, GPIO_PORT164,
+	GPIO_PORT165, GPIO_PORT166, GPIO_PORT167, GPIO_PORT168, GPIO_PORT169,
+
+	GPIO_PORT170, GPIO_PORT171, GPIO_PORT172, GPIO_PORT173, GPIO_PORT174,
+	GPIO_PORT175, GPIO_PORT176, GPIO_PORT177, GPIO_PORT178,
+
+	GPIO_PORT192, GPIO_PORT193, GPIO_PORT194,
+	GPIO_PORT195, GPIO_PORT196, GPIO_PORT197, GPIO_PORT198, GPIO_PORT199,
+
+	GPIO_PORT200, GPIO_PORT201, GPIO_PORT202, GPIO_PORT203, GPIO_PORT204,
+	GPIO_PORT205, GPIO_PORT206, GPIO_PORT207, GPIO_PORT208, GPIO_PORT209,
+
+	GPIO_PORT210, GPIO_PORT211, GPIO_PORT212, GPIO_PORT213, GPIO_PORT214,
+	GPIO_PORT215, GPIO_PORT216, GPIO_PORT217, GPIO_PORT218, GPIO_PORT219,
+
+	GPIO_PORT220, GPIO_PORT221, GPIO_PORT222, GPIO_PORT224,
+	GPIO_PORT225, GPIO_PORT226, GPIO_PORT227, GPIO_PORT228, GPIO_PORT229,
+
+	GPIO_PORT230, GPIO_PORT231, GPIO_PORT232, GPIO_PORT233, GPIO_PORT234,
+	GPIO_PORT235, GPIO_PORT236, GPIO_PORT237, GPIO_PORT238, GPIO_PORT239,
+
+	GPIO_PORT240, GPIO_PORT241, GPIO_PORT242, GPIO_PORT243, GPIO_PORT244,
+	GPIO_PORT245, GPIO_PORT246, GPIO_PORT247, GPIO_PORT248, GPIO_PORT249,
+
+	GPIO_PORT250, GPIO_PORT256, GPIO_PORT257, GPIO_PORT258, GPIO_PORT259,
+
+	GPIO_PORT260, GPIO_PORT261, GPIO_PORT262, GPIO_PORT263, GPIO_PORT264,
+	GPIO_PORT265, GPIO_PORT266, GPIO_PORT267, GPIO_PORT268, GPIO_PORT269,
+
+	GPIO_PORT270, GPIO_PORT271, GPIO_PORT272, GPIO_PORT273, GPIO_PORT274,
+	GPIO_PORT275, GPIO_PORT276, GPIO_PORT277, GPIO_PORT278, GPIO_PORT279,
+
+	GPIO_PORT280, GPIO_PORT281, GPIO_PORT282, GPIO_PORT283,
+	GPIO_PORT288, GPIO_PORT289,
+
+	GPIO_PORT290, GPIO_PORT291, GPIO_PORT292, GPIO_PORT293, GPIO_PORT294,
+	GPIO_PORT295, GPIO_PORT296, GPIO_PORT297, GPIO_PORT298, GPIO_PORT299,
+
+	GPIO_PORT300, GPIO_PORT301, GPIO_PORT302, GPIO_PORT303, GPIO_PORT304,
+	GPIO_PORT305, GPIO_PORT306, GPIO_PORT307, GPIO_PORT308,
+
+	GPIO_PORT320, GPIO_PORT321, GPIO_PORT322, GPIO_PORT323, GPIO_PORT324,
+	GPIO_PORT325, GPIO_PORT326, GPIO_PORT327, GPIO_PORT328, GPIO_PORT329,
+
+	/* Port0 */
+	GPIO_FN_LCDD0,
+	GPIO_FN_PDM2_CLK_0,
+	GPIO_FN_DU0_DR0,
+	GPIO_FN_IRQ0,
+
+	/* Port1 */
+	GPIO_FN_LCDD1,
+	GPIO_FN_PDM2_DATA_1,
+	GPIO_FN_DU0_DR19,
+	GPIO_FN_IRQ1,
+
+	/* Port2 */
+	GPIO_FN_LCDD2,
+	GPIO_FN_PDM3_CLK_2,
+	GPIO_FN_DU0_DR2,
+	GPIO_FN_IRQ2,
+
+	/* Port3 */
+	GPIO_FN_LCDD3,
+	GPIO_FN_PDM3_DATA_3,
+	GPIO_FN_DU0_DR3,
+	GPIO_FN_IRQ3,
+
+	/* Port4 */
+	GPIO_FN_LCDD4,
+	GPIO_FN_PDM4_CLK_4,
+	GPIO_FN_DU0_DR4,
+	GPIO_FN_IRQ4,
+
+	/* Port5 */
+	GPIO_FN_LCDD5,
+	GPIO_FN_PDM4_DATA_5,
+	GPIO_FN_DU0_DR5,
+	GPIO_FN_IRQ5,
+
+	/* Port6 */
+	GPIO_FN_LCDD6,
+	GPIO_FN_PDM0_OUTCLK_6,
+	GPIO_FN_DU0_DR6,
+	GPIO_FN_IRQ6,
+
+	/* Port7 */
+	GPIO_FN_LCDD7,
+	GPIO_FN_PDM0_OUTDATA_7,
+	GPIO_FN_DU0_DR7,
+	GPIO_FN_IRQ7,
+
+	/* Port8 */
+	GPIO_FN_LCDD8,
+	GPIO_FN_PDM1_OUTCLK_8,
+	GPIO_FN_DU0_DG0,
+	GPIO_FN_IRQ8,
+
+	/* Port9 */
+	GPIO_FN_LCDD9,
+	GPIO_FN_PDM1_OUTDATA_9,
+	GPIO_FN_DU0_DG1,
+	GPIO_FN_IRQ9,
+
+	/* Port10 */
+	GPIO_FN_LCDD10,
+	GPIO_FN_FSICCK,
+	GPIO_FN_DU0_DG2,
+	GPIO_FN_IRQ10,
+
+	/* Port11 */
+	GPIO_FN_LCDD11,
+	GPIO_FN_FSICISLD,
+	GPIO_FN_DU0_DG3,
+	GPIO_FN_IRQ11,
+
+	/* Port12 */
+	GPIO_FN_LCDD12,
+	GPIO_FN_FSICOMC,
+	GPIO_FN_DU0_DG4,
+	GPIO_FN_IRQ12,
+
+	/* Port13 */
+	GPIO_FN_LCDD13,
+	GPIO_FN_FSICOLR,
+	GPIO_FN_FSICILR,
+	GPIO_FN_DU0_DG5,
+	GPIO_FN_IRQ13,
+
+	/* Port14 */
+	GPIO_FN_LCDD14,
+	GPIO_FN_FSICOBT,
+	GPIO_FN_FSICIBT,
+	GPIO_FN_DU0_DG6,
+	GPIO_FN_IRQ14,
+
+	/* Port15 */
+	GPIO_FN_LCDD15,
+	GPIO_FN_FSICOSLD,
+	GPIO_FN_DU0_DG7,
+	GPIO_FN_IRQ15,
+
+	/* Port16 */
+	GPIO_FN_LCDD16,
+	GPIO_FN_TPU1TO1,
+	GPIO_FN_DU0_DB0,
+
+	/* Port17 */
+	GPIO_FN_LCDD17,
+	GPIO_FN_SF_IRQ_00,
+	GPIO_FN_DU0_DB1,
+
+	/* Port18 */
+	GPIO_FN_LCDD18,
+	GPIO_FN_SF_IRQ_01,
+	GPIO_FN_DU0_DB2,
+
+	/* Port19 */
+	GPIO_FN_LCDD19,
+	GPIO_FN_SCIFB3_RTS_19,
+	GPIO_FN_DU0_DB3,
+
+	/* Port20 */
+	GPIO_FN_LCDD20,
+	GPIO_FN_SCIFB3_CTS_20,
+	GPIO_FN_DU0_DB4,
+
+	/* Port21 */
+	GPIO_FN_LCDD21,
+	GPIO_FN_SCIFB3_TXD_21,
+	GPIO_FN_DU0_DB5,
+
+	/* Port22 */
+	GPIO_FN_LCDD22,
+	GPIO_FN_SCIFB3_RXD_22,
+	GPIO_FN_DU0_DB6,
+
+	/* Port23 */
+	GPIO_FN_LCDD23,
+	GPIO_FN_SCIFB3_SCK_23,
+	GPIO_FN_DU0_DB7,
+
+	/* Port24 */
+	GPIO_FN_LCDHSYN,
+	GPIO_FN_LCDCS,
+	GPIO_FN_SCIFB1_RTS_24,
+	GPIO_FN_DU0_EXHSYNC_N_CSYNC_N_HSYNC_N,
+
+	/* Port25 */
+	GPIO_FN_LCDVSYN,
+	GPIO_FN_SCIFB1_CTS_25,
+	GPIO_FN_DU0_EXVSYNC_N_VSYNC_N_CSYNC_N,
+
+	/* Port26 */
+	GPIO_FN_LCDDCK,
+	GPIO_FN_LCDWR,
+	GPIO_FN_SCIFB1_TXD_26,
+	GPIO_FN_DU0_DOTCLKIN,
+
+	/* Port27 */
+	GPIO_FN_LCDDISP,
+	GPIO_FN_LCDRS,
+	GPIO_FN_SCIFB1_RXD_27,
+	GPIO_FN_DU0_DOTCLKOUT,
+
+	/* Port28 */
+	GPIO_FN_LCDRD_N,
+	GPIO_FN_SCIFB1_SCK_28,
+	GPIO_FN_DU0_DOTCLKOUTB,
+
+	/* Port29 */
+	GPIO_FN_LCDLCLK,
+	GPIO_FN_SF_IRQ_02,
+	GPIO_FN_DU0_DISP_CSYNC_N_DE,
+
+	/* Port30 */
+	GPIO_FN_LCDDON,
+	GPIO_FN_SF_IRQ_03,
+	GPIO_FN_DU0_ODDF_N_CLAMP,
+
+	/* Port32 */
+	GPIO_FN_SCIFA0_RTS,
+	GPIO_FN_SIM0_DET,
+	GPIO_FN_CSCIF0_RTS,
+
+	/* Port33 */
+	GPIO_FN_SCIFA0_CTS,
+	GPIO_FN_SIM1_DET,
+	GPIO_FN_CSCIF0_CTS,
+
+	/* Port34 */
+	GPIO_FN_SCIFA0_SCK,
+	GPIO_FN_SIM0_PWRON,
+	GPIO_FN_CSCIF0_SCK,
+
+	/* Port35 */
+	GPIO_FN_SCIFA1_RTS,
+	GPIO_FN_CSCIF1_RTS,
+
+	/* Port36 */
+	GPIO_FN_SCIFA1_CTS,
+	GPIO_FN_CSCIF1_CTS,
+
+	/* Port37 */
+	GPIO_FN_SCIFA1_SCK,
+	GPIO_FN_CSCIF1_SCK,
+
+	/* Port38 */
+	GPIO_FN_SCIFB0_RTS,
+	GPIO_FN_TPU0TO1,
+	GPIO_FN_SCIFB3_RTS_38,
+	GPIO_FN_CHSCIF0_HRTS,
+
+	/* Port39 */
+	GPIO_FN_SCIFB0_CTS,
+	GPIO_FN_TPU0TO2,
+	GPIO_FN_SCIFB3_CTS_39,
+	GPIO_FN_CHSCIF0_HCTS,
+
+	/* Port40 */
+	GPIO_FN_SCIFB0_SCK,
+	GPIO_FN_TPU0TO3,
+	GPIO_FN_SCIFB3_SCK_40,
+	GPIO_FN_CHSCIF0_HSCK,
+
+	/* Port64 */
+	GPIO_FN_PDM0_DATA,
+
+	/* Port65 */
+	GPIO_FN_PDM1_DATA,
+
+	/* Port66 */
+	GPIO_FN_HSI_RX_WAKE,
+	GPIO_FN_SCIFB2_CTS_66,
+	GPIO_FN_MSIOF3_SYNC,
+	GPIO_FN_GenIO4,
+	GPIO_FN_IRQ40,
+
+	/* Port67 */
+	GPIO_FN_HSI_RX_READY,
+	GPIO_FN_SCIFB1_TXD_67,
+	GPIO_FN_GIO_OUT3_67,
+	GPIO_FN_CHSCIF1_HTX,
+
+	/* Port68 */
+	GPIO_FN_HSI_RX_FLAG,
+	GPIO_FN_SCIFB2_TXD_68,
+	GPIO_FN_MSIOF3_TXD,
+	GPIO_FN_GIO_OUT4_68,
+
+	/* Port69 */
+	GPIO_FN_HSI_RX_DATA,
+	GPIO_FN_SCIFB2_RXD_69,
+	GPIO_FN_MSIOF3_RXD,
+	GPIO_FN_GIO_OUT5_69,
+
+	/* Port70 */
+	GPIO_FN_HSI_TX_FLAG,
+	GPIO_FN_SCIFB1_RTS_70,
+	GPIO_FN_GIO_OUT1_70,
+	GPIO_FN_HSIC_TSTCLK0,
+	GPIO_FN_CHSCIF1_HRTS,
+
+	/* Port71 */
+	GPIO_FN_HSI_TX_DATA,
+	GPIO_FN_SCIFB1_CTS_71,
+	GPIO_FN_GIO_OUT2_71,
+	GPIO_FN_HSIC_TSTCLK1,
+	GPIO_FN_CHSCIF1_HCTS,
+
+	/* Port72 */
+	GPIO_FN_HSI_TX_WAKE,
+	GPIO_FN_SCIFB1_RXD_72,
+	GPIO_FN_GenIO8,
+	GPIO_FN_CHSCIF1_HRX,
+
+	/* Port73 */
+	GPIO_FN_HSI_TX_READY,
+	GPIO_FN_SCIFB2_RTS_73,
+	GPIO_FN_MSIOF3_SCK,
+	GPIO_FN_GIO_OUT0_73,
+
+	/* Port74 - Port85 */
+	GPIO_FN_IRDA_OUT,
+	GPIO_FN_IRDA_IN,
+	GPIO_FN_IRDA_FIRSEL,
+	GPIO_FN_TPU0TO0,
+	GPIO_FN_DIGRFEN,
+	GPIO_FN_GPS_TIMESTAMP,
+	GPIO_FN_TXP,
+	GPIO_FN_TXP2,
+	GPIO_FN_COEX_0,
+	GPIO_FN_COEX_1,
+	GPIO_FN_IRQ19,
+	GPIO_FN_IRQ18,
+
+	/* Port96 - Port101 */
+	GPIO_FN_KEYIN0,
+	GPIO_FN_KEYIN1,
+	GPIO_FN_KEYIN2,
+	GPIO_FN_KEYIN3,
+	GPIO_FN_KEYIN4,
+	GPIO_FN_KEYIN5,
+
+	/* Port102 */
+	GPIO_FN_KEYIN6,
+	GPIO_FN_IRQ41,
+
+	/* Port103 */
+	GPIO_FN_KEYIN7,
+	GPIO_FN_IRQ42,
+
+	/* Port104 - Port108 */
+	GPIO_FN_KEYOUT0,
+	GPIO_FN_KEYOUT1,
+	GPIO_FN_KEYOUT2,
+	GPIO_FN_KEYOUT3,
+	GPIO_FN_KEYOUT4,
+
+	/* Port109 */
+	GPIO_FN_KEYOUT5,
+	GPIO_FN_IRQ43,
+
+	/* Port110 */
+	GPIO_FN_KEYOUT6,
+	GPIO_FN_IRQ44,
+
+	/* Port111 */
+	GPIO_FN_KEYOUT7,
+	GPIO_FN_RFANAEN,
+	GPIO_FN_IRQ45,
+
+	/* Port112 */
+	GPIO_FN_KEYIN8,
+	GPIO_FN_KEYOUT8,
+	GPIO_FN_SF_IRQ_04,
+	GPIO_FN_IRQ46,
+
+	/* Port113 */
+	GPIO_FN_KEYIN9,
+	GPIO_FN_KEYOUT9,
+	GPIO_FN_SF_IRQ_05,
+	GPIO_FN_IRQ47,
+
+	/* Port114 */
+	GPIO_FN_KEYIN10,
+	GPIO_FN_KEYOUT10,
+	GPIO_FN_SF_IRQ_06,
+	GPIO_FN_IRQ48,
+
+	/* Port115 */
+	GPIO_FN_KEYIN11,
+	GPIO_FN_KEYOUT11,
+	GPIO_FN_SF_IRQ_07,
+	GPIO_FN_IRQ49,
+
+	/* Port116 */
+	GPIO_FN_SCIFA0_TXD,
+	GPIO_FN_CSCIF0_TX,
+
+	/* Port117 */
+	GPIO_FN_SCIFA0_RXD,
+	GPIO_FN_CSCIF0_RX,
+
+	/* Port118 */
+	GPIO_FN_SCIFA1_TXD,
+	GPIO_FN_CSCIF1_TX,
+
+	/* Port119 */
+	GPIO_FN_SCIFA1_RXD,
+	GPIO_FN_CSCIF1_RX,
+
+	/* Port120 */
+	GPIO_FN_SF_PORT_1_120,
+	GPIO_FN_SCIFB3_RXD_120,
+	GPIO_FN_DU0_CDE,
+
+	/* Port121 */
+	GPIO_FN_SF_PORT_0_121,
+	GPIO_FN_SCIFB3_TXD_121,
+
+	/* Port122 */
+	GPIO_FN_SCIFB0_TXD,
+	GPIO_FN_CHSCIF0_HTX,
+
+	/* Port123 */
+	GPIO_FN_SCIFB0_RXD,
+	GPIO_FN_CHSCIF0_HRX,
+
+	/* Port124 */
+	GPIO_FN_ISP_STROBE_124,
+
+	/* Port125 */
+	GPIO_FN_STP_ISD_0,
+	GPIO_FN_PDM4_CLK_125,
+	GPIO_FN_MSIOF2_TXD,
+	GPIO_FN_SIM0_VOLTSEL0,
+
+	/* Port126 */
+	GPIO_FN_TS_SDEN,
+	GPIO_FN_MSIOF7_SYNC,
+	GPIO_FN_STP_ISEN_1,
+
+	/* Port128 */
+	GPIO_FN_STP_ISEN_0,
+	GPIO_FN_PDM1_OUTDATA_128,
+	GPIO_FN_MSIOF2_SYNC,
+	GPIO_FN_SIM1_VOLTSEL1,
+
+	/* Port129 */
+	GPIO_FN_TS_SPSYNC,
+	GPIO_FN_MSIOF7_RXD,
+	GPIO_FN_STP_ISSYNC_1,
+
+	/* Port130 */
+	GPIO_FN_STP_ISSYNC_0,
+	GPIO_FN_PDM4_DATA_130,
+	GPIO_FN_MSIOF2_RXD,
+	GPIO_FN_SIM0_VOLTSEL1,
+
+	/* Port131 */
+	GPIO_FN_STP_OPWM_0,
+	GPIO_FN_SIM1_PWRON,
+
+	/* Port132 */
+	GPIO_FN_TS_SCK,
+	GPIO_FN_MSIOF7_SCK,
+	GPIO_FN_STP_ISCLK_1,
+
+	/* Port133 */
+	GPIO_FN_STP_ISCLK_0,
+	GPIO_FN_PDM1_OUTCLK_133,
+	GPIO_FN_MSIOF2_SCK,
+	GPIO_FN_SIM1_VOLTSEL0,
+
+	/* Port134 */
+	GPIO_FN_TS_SDAT,
+	GPIO_FN_MSIOF7_TXD,
+	GPIO_FN_STP_ISD_1,
+
+	/* Port160 - Port178 */
+	GPIO_FN_IRQ20,
+	GPIO_FN_IRQ21,
+	GPIO_FN_IRQ22,
+	GPIO_FN_IRQ23,
+	GPIO_FN_MMCD0_0,
+	GPIO_FN_MMCD0_1,
+	GPIO_FN_MMCD0_2,
+	GPIO_FN_MMCD0_3,
+	GPIO_FN_MMCD0_4,
+	GPIO_FN_MMCD0_5,
+	GPIO_FN_MMCD0_6,
+	GPIO_FN_MMCD0_7,
+	GPIO_FN_MMCCMD0,
+	GPIO_FN_MMCCLK0,
+	GPIO_FN_MMCRST,
+	GPIO_FN_IRQ24,
+	GPIO_FN_IRQ25,
+	GPIO_FN_IRQ26,
+	GPIO_FN_IRQ27,
+
+	/* Port192 - Port200 FN1 */
+	GPIO_FN_A10,
+	GPIO_FN_A9,
+	GPIO_FN_A8,
+	GPIO_FN_A7,
+	GPIO_FN_A6,
+	GPIO_FN_A5,
+	GPIO_FN_A4,
+	GPIO_FN_A3,
+	GPIO_FN_A2,
+
+	/* Port192 - Port200 FN2 */
+	GPIO_FN_MMCD1_7,
+	GPIO_FN_MMCD1_6,
+	GPIO_FN_MMCD1_5,
+	GPIO_FN_MMCD1_4,
+	GPIO_FN_MMCD1_3,
+	GPIO_FN_MMCD1_2,
+	GPIO_FN_MMCD1_1,
+	GPIO_FN_MMCD1_0,
+	GPIO_FN_MMCCMD1,
+
+	/* Port192 - Port200 IRQ */
+	GPIO_FN_IRQ31,
+	GPIO_FN_IRQ32,
+	GPIO_FN_IRQ33,
+	GPIO_FN_IRQ34,
+	GPIO_FN_IRQ35,
+	GPIO_FN_IRQ36,
+	GPIO_FN_IRQ37,
+	GPIO_FN_IRQ38,
+	GPIO_FN_IRQ39,
+
+	/* Port201 */
+	GPIO_FN_A1,
+
+	/* Port202 */
+	GPIO_FN_A0,
+	GPIO_FN_BS,
+
+	/* Port203 */
+	GPIO_FN_CKO,
+	GPIO_FN_MMCCLK1,
+
+	/* Port204 */
+	GPIO_FN_CS0_N,
+	GPIO_FN_SIM0_GPO1,
+
+	/* Port205 */
+	GPIO_FN_CS2_N,
+	GPIO_FN_SIM0_GPO2,
+
+	/* Port206 */
+	GPIO_FN_CS4_N,
+	GPIO_FN_VIO_VD,
+	GPIO_FN_SIM1_GPO0,
+
+	/* Port207 - Port212 FN1 */
+	GPIO_FN_D15,
+	GPIO_FN_D14,
+	GPIO_FN_D13,
+	GPIO_FN_D12,
+	GPIO_FN_D11,
+	GPIO_FN_D10,
+
+	/* Port207 - Port212 FN5 */
+	GPIO_FN_GIO_OUT15,
+	GPIO_FN_GIO_OUT14,
+	GPIO_FN_GIO_OUT13,
+	GPIO_FN_GIO_OUT12,
+	GPIO_FN_WGM_TXP2,
+	GPIO_FN_WGM_GPS_TIMEM_ASK_RFCLK,
+
+	/* Port213 - Port222 FN1 */
+	GPIO_FN_D9,
+	GPIO_FN_D8,
+	GPIO_FN_D7,
+	GPIO_FN_D6,
+	GPIO_FN_D5,
+	GPIO_FN_D4,
+	GPIO_FN_D3,
+	GPIO_FN_D2,
+	GPIO_FN_D1,
+	GPIO_FN_D0,
+
+	/* Port213 - Port222 FN2 */
+	GPIO_FN_VIO_D9,
+	GPIO_FN_VIO_D8,
+	GPIO_FN_VIO_D7,
+	GPIO_FN_VIO_D6,
+	GPIO_FN_VIO_D5,
+	GPIO_FN_VIO_D4,
+	GPIO_FN_VIO_D3,
+	GPIO_FN_VIO_D2,
+	GPIO_FN_VIO_D1,
+	GPIO_FN_VIO_D0,
+
+	/* Port213 - Port222 FN5 */
+	GPIO_FN_GIO_OUT9,
+	GPIO_FN_GIO_OUT8,
+	GPIO_FN_GIO_OUT7,
+	GPIO_FN_GIO_OUT6,
+	GPIO_FN_GIO_OUT5_217,
+	GPIO_FN_GIO_OUT4_218,
+	GPIO_FN_GIO_OUT3_219,
+	GPIO_FN_GIO_OUT2_220,
+	GPIO_FN_GIO_OUT1_221,
+	GPIO_FN_GIO_OUT0_222,
+
+	/* Port224 */
+	GPIO_FN_RDWR_224,
+	GPIO_FN_VIO_HD,
+	GPIO_FN_SIM1_GPO2,
+
+	/* Port225 */
+	GPIO_FN_RD_N,
+
+	/* Port226 */
+	GPIO_FN_WAIT_N,
+	GPIO_FN_VIO_CLK,
+	GPIO_FN_SIM1_GPO1,
+
+	/* Port227 */
+	GPIO_FN_WE0_N,
+	GPIO_FN_RDWR_227,
+
+	/* Port228 */
+	GPIO_FN_WE1_N,
+	GPIO_FN_SIM0_GPO0,
+
+	/* Port229 */
+	GPIO_FN_PWMO,
+	GPIO_FN_VIO_CKO1_229,
+
+	/* Port230 */
+	GPIO_FN_SLIM_CLK,
+	GPIO_FN_VIO_CKO4_230,
+
+	/* Port231 */
+	GPIO_FN_SLIM_DATA,
+	GPIO_FN_VIO_CKO5_231,
+
+	/* Port232 */
+	GPIO_FN_VIO_CKO2_232,
+	GPIO_FN_SF_PORT_0_232,
+
+	/* Port233 */
+	GPIO_FN_VIO_CKO3_233,
+	GPIO_FN_SF_PORT_1_233,
+
+	/* Port234 */
+	GPIO_FN_FSIACK,
+	GPIO_FN_PDM3_CLK_234,
+	GPIO_FN_ISP_IRIS1_234,
+
+	/* Port235 */
+	GPIO_FN_FSIAISLD,
+	GPIO_FN_PDM3_DATA_235,
+
+	/* Port236 */
+	GPIO_FN_FSIAOMC,
+	GPIO_FN_PDM0_OUTCLK_236,
+	GPIO_FN_ISP_IRIS0_236,
+
+	/* Port237 */
+	GPIO_FN_FSIAOLR,
+	GPIO_FN_FSIAILR,
+
+	/* Port238 */
+	GPIO_FN_FSIAOBT,
+	GPIO_FN_FSIAIBT,
+
+	/* Port239 */
+	GPIO_FN_FSIAOSLD,
+	GPIO_FN_PDM0_OUTDATA_239,
+
+	/* Port240 */
+	GPIO_FN_FSIBISLD,
+
+	/* Port241 */
+	GPIO_FN_FSIBOLR,
+	GPIO_FN_FSIBILR,
+
+	/* Port242 */
+	GPIO_FN_FSIBOMC,
+	GPIO_FN_ISP_SHUTTER1_242,
+
+	/* Port243 */
+	GPIO_FN_FSIBOBT,
+	GPIO_FN_FSIBIBT,
+
+	/* Port244 */
+	GPIO_FN_FSIBOSLD,
+	GPIO_FN_FSIASPDIF,
+
+	/* Port245 */
+	GPIO_FN_FSIBCK,
+	GPIO_FN_ISP_SHUTTER0_245,
+
+	/* Port246 - Port250 FN1 */
+	GPIO_FN_ISP_IRIS1_246,
+	GPIO_FN_ISP_IRIS0_247,
+	GPIO_FN_ISP_SHUTTER1_248,
+	GPIO_FN_ISP_SHUTTER0_249,
+	GPIO_FN_ISP_STROBE_250,
+
+	/* Port256 - Port258 */
+	GPIO_FN_MSIOF0_SYNC,
+	GPIO_FN_MSIOF0_RXD,
+	GPIO_FN_MSIOF0_SCK,
+
+	/* Port259 */
+	GPIO_FN_MSIOF0_SS2,
+	GPIO_FN_VIO_CKO3_259,
+
+	/* Port260 */
+	GPIO_FN_MSIOF0_TXD,
+
+	/* Port261 */
+	GPIO_FN_SCIFB1_SCK_261,
+	GPIO_FN_CHSCIF1_HSCK,
+
+	/* Port262 */
+	GPIO_FN_SCIFB2_SCK_262,
+
+	/* Port263 - Port266 FN1 */
+	GPIO_FN_MSIOF1_SS2,
+	GPIO_FN_MSIOF1_TXD,
+	GPIO_FN_MSIOF1_RXD,
+	GPIO_FN_MSIOF1_SS1,
+
+	/* Port263 - Port266 FN4 */
+	GPIO_FN_MSIOF5_SS2,
+	GPIO_FN_MSIOF5_TXD,
+	GPIO_FN_MSIOF5_RXD,
+	GPIO_FN_MSIOF5_SS1,
+
+	/* Port267 */
+	GPIO_FN_MSIOF0_SS1,
+
+	/* Port268 */
+	GPIO_FN_MSIOF1_SCK,
+	GPIO_FN_MSIOF5_SCK,
+
+	/* Port269 */
+	GPIO_FN_MSIOF1_SYNC,
+	GPIO_FN_MSIOF5_SYNC,
+
+	/* Port270 - Port273 FN1 */
+	GPIO_FN_MSIOF2_SS1,
+	GPIO_FN_MSIOF2_SS2,
+	GPIO_FN_MSIOF3_SS2,
+	GPIO_FN_MSIOF3_SS1,
+
+	/* Port270 - Port273 FN3 */
+	GPIO_FN_VIO_CKO5_270,
+	GPIO_FN_VIO_CKO2_271,
+	GPIO_FN_VIO_CKO1_272,
+	GPIO_FN_VIO_CKO4_273,
+
+	/* Port274 */
+	GPIO_FN_MSIOF4_SS2,
+	GPIO_FN_TPU1TO0,
+
+	/* Port275 - Port280 */
+	GPIO_FN_IC_DP,
+	GPIO_FN_SIM0_RST,
+	GPIO_FN_IC_DM,
+	GPIO_FN_SIM0_BSICOMP,
+	GPIO_FN_SIM0_CLK,
+	GPIO_FN_SIM0_IO,
+
+	/* Port281 */
+	GPIO_FN_SIM1_IO,
+	GPIO_FN_PDM2_DATA_281,
+
+	/* Port282 */
+	GPIO_FN_SIM1_CLK,
+	GPIO_FN_PDM2_CLK_282,
+
+	/* Port283 */
+	GPIO_FN_SIM1_RST,
+
+	/* Port289 */
+	GPIO_FN_SDHID1_0,
+	GPIO_FN_STMDATA0_2,
+
+	/* Port290 */
+	GPIO_FN_SDHID1_1,
+	GPIO_FN_STMDATA1_2,
+	GPIO_FN_IRQ51,
+
+	/* Port291 - Port294 FN1 */
+	GPIO_FN_SDHID1_2,
+	GPIO_FN_SDHID1_3,
+	GPIO_FN_SDHICLK1,
+	GPIO_FN_SDHICMD1,
+
+	/* Port291 - Port294 FN3 */
+	GPIO_FN_STMDATA2_2,
+	GPIO_FN_STMDATA3_2,
+	GPIO_FN_STMCLK_2,
+	GPIO_FN_STMSIDI_2,
+
+	/* Port295 */
+	GPIO_FN_SDHID2_0,
+	GPIO_FN_MSIOF4_TXD,
+	GPIO_FN_SCIFB2_TXD_295,
+	GPIO_FN_MSIOF6_TXD,
+
+	/* Port296 */
+	GPIO_FN_SDHID2_1,
+	GPIO_FN_MSIOF6_SS2,
+	GPIO_FN_IRQ52,
+
+	/* Port297 - Port300 FN1 */
+	GPIO_FN_SDHID2_2,
+	GPIO_FN_SDHID2_3,
+	GPIO_FN_SDHICLK2,
+	GPIO_FN_SDHICMD2,
+
+	/* Port297 - Port300 FN2 */
+	GPIO_FN_MSIOF4_RXD,
+	GPIO_FN_MSIOF4_SYNC,
+	GPIO_FN_MSIOF4_SCK,
+	GPIO_FN_MSIOF4_SS1,
+
+	/* Port297 - Port300 FN3 */
+	GPIO_FN_SCIFB2_RXD_297,
+	GPIO_FN_SCIFB2_CTS_298,
+	GPIO_FN_SCIFB2_SCK_299,
+	GPIO_FN_SCIFB2_RTS_300,
+
+	/* Port297 - Port300 FN4 */
+	GPIO_FN_MSIOF6_RXD,
+	GPIO_FN_MSIOF6_SYNC,
+	GPIO_FN_MSIOF6_SCK,
+	GPIO_FN_MSIOF6_SS1,
+
+	/* Port301 */
+	GPIO_FN_SDHICD0,
+	GPIO_FN_IRQ50,
+
+	/* Port302 - Port306 FN1 */
+	GPIO_FN_SDHID0_0,
+	GPIO_FN_SDHID0_1,
+	GPIO_FN_SDHID0_2,
+	GPIO_FN_SDHID0_3,
+	GPIO_FN_SDHICMD0,
+
+	/* Port302 - Port306 FN3 */
+	GPIO_FN_STMDATA0_1,
+	GPIO_FN_STMDATA1_1,
+	GPIO_FN_STMDATA2_1,
+	GPIO_FN_STMDATA3_1,
+	GPIO_FN_STMSIDI_1,
+
+	/* Port307 */
+	GPIO_FN_SDHIWP0,
+
+	/* Port308 */
+	GPIO_FN_SDHICLK0,
+	GPIO_FN_STMCLK_1,
+
+	/* Port320 - Port329 */
+	GPIO_FN_IRQ16,
+	GPIO_FN_IRQ17,
+	GPIO_FN_IRQ28,
+	GPIO_FN_IRQ29,
+	GPIO_FN_IRQ30,
+	GPIO_FN_IRQ53,
+	GPIO_FN_IRQ54,
+	GPIO_FN_IRQ55,
+	GPIO_FN_IRQ56,
+	GPIO_FN_IRQ57,
+};
+
 void r8a73a4_add_standard_devices(void);
 void r8a73a4_clock_init(void);
 void r8a73a4_pinmux_init(void);
diff --git a/drivers/pinctrl/sh-pfc/Kconfig b/drivers/pinctrl/sh-pfc/Kconfig
index af16f8f..0e1f99c 100644
--- a/drivers/pinctrl/sh-pfc/Kconfig
+++ b/drivers/pinctrl/sh-pfc/Kconfig
@@ -22,6 +22,11 @@ config GPIO_SH_PFC
 	  This enables support for GPIOs within the SoC's pin function
 	  controller.
 
+config PINCTRL_PFC_R8A73A4
+	def_bool y
+	depends on ARCH_R8A73A4
+	select PINCTRL_SH_PFC
+
 config PINCTRL_PFC_R8A7740
 	def_bool y
 	depends on ARCH_R8A7740
diff --git a/drivers/pinctrl/sh-pfc/Makefile b/drivers/pinctrl/sh-pfc/Makefile
index e8b9562..211cd8e 100644
--- a/drivers/pinctrl/sh-pfc/Makefile
+++ b/drivers/pinctrl/sh-pfc/Makefile
@@ -3,6 +3,7 @@ ifeq ($(CONFIG_GPIO_SH_PFC),y)
 sh-pfc-objs			+= gpio.o
 endif
 obj-$(CONFIG_PINCTRL_SH_PFC)	+= sh-pfc.o
+obj-$(CONFIG_PINCTRL_PFC_R8A73A4)	+= pfc-r8a73a4.o
 obj-$(CONFIG_PINCTRL_PFC_R8A7740)	+= pfc-r8a7740.o
 obj-$(CONFIG_PINCTRL_PFC_R8A7779)	+= pfc-r8a7779.o
 obj-$(CONFIG_PINCTRL_PFC_SH7203)	+= pfc-sh7203.o
diff --git a/drivers/pinctrl/sh-pfc/core.c b/drivers/pinctrl/sh-pfc/core.c
index ced9a95..b551336 100644
--- a/drivers/pinctrl/sh-pfc/core.c
+++ b/drivers/pinctrl/sh-pfc/core.c
@@ -418,6 +418,9 @@ static int sh_pfc_remove(struct platform_device *pdev)
 }
 
 static const struct platform_device_id sh_pfc_id_table[] = {
+#ifdef CONFIG_PINCTRL_PFC_R8A73A4
+	{ "pfc-r8a73a4", (kernel_ulong_t)&r8a73a4_pinmux_info },
+#endif
 #ifdef CONFIG_PINCTRL_PFC_R8A7740
 	{ "pfc-r8a7740", (kernel_ulong_t)&r8a7740_pinmux_info },
 #endif
diff --git a/drivers/pinctrl/sh-pfc/core.h b/drivers/pinctrl/sh-pfc/core.h
index 763d717..89cb428 100644
--- a/drivers/pinctrl/sh-pfc/core.h
+++ b/drivers/pinctrl/sh-pfc/core.h
@@ -54,6 +54,7 @@ void sh_pfc_write_raw_reg(void __iomem *mapped_reg, unsigned long reg_width,
 int sh_pfc_get_pin_index(struct sh_pfc *pfc, unsigned int pin);
 int sh_pfc_config_mux(struct sh_pfc *pfc, unsigned mark, int pinmux_type);
 
+extern const struct sh_pfc_soc_info r8a73a4_pinmux_info;
 extern const struct sh_pfc_soc_info r8a7740_pinmux_info;
 extern const struct sh_pfc_soc_info r8a7779_pinmux_info;
 extern const struct sh_pfc_soc_info sh7203_pinmux_info;
diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a73a4.c b/drivers/pinctrl/sh-pfc/pfc-r8a73a4.c
new file mode 100644
index 0000000..47d75d5
--- /dev/null
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a73a4.c
@@ -0,0 +1,2826 @@
+/*
+ * Copyright (C) 2012-2013  Renesas Solutions Corp.
+ * Copyright (C) 2013  Magnus Damm
+ * Copyright (C) 2012  Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
+ *
+ * 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; version 2 of the
+ * License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
+ */
+#include <linux/kernel.h>
+#include <mach/irqs.h>
+#include <mach/r8a73a4.h>
+
+#include "sh_pfc.h"
+
+#define CPU_ALL_PORT(fn, pfx, sfx)					\
+	/*  Port0 - Port30 */						\
+	PORT_10(fn, pfx, sfx),						\
+	PORT_10(fn, pfx##1, sfx),					\
+	PORT_10(fn, pfx##2, sfx),					\
+	PORT_1(fn,  pfx##30, sfx),					\
+	/* Port32 - Port40 */						\
+	PORT_1(fn,  pfx##32, sfx),	PORT_1(fn,  pfx##33, sfx),	\
+	PORT_1(fn,  pfx##34, sfx),	PORT_1(fn,  pfx##35, sfx),	\
+	PORT_1(fn,  pfx##36, sfx),	PORT_1(fn,  pfx##37, sfx),	\
+	PORT_1(fn,  pfx##38, sfx),	PORT_1(fn,  pfx##39, sfx),	\
+	PORT_1(fn,  pfx##40, sfx),					\
+	/* Port64  - Port85 */						\
+	PORT_1(fn, pfx##64, sfx),	PORT_1(fn, pfx##65, sfx),	\
+	PORT_1(fn, pfx##66, sfx),	PORT_1(fn, pfx##67, sfx),	\
+	PORT_1(fn, pfx##68, sfx),	PORT_1(fn, pfx##69, sfx),	\
+	PORT_10(fn, pfx##7, sfx),					\
+	PORT_1(fn, pfx##80, sfx),	PORT_1(fn, pfx##81, sfx),	\
+	PORT_1(fn, pfx##82, sfx),	PORT_1(fn, pfx##83, sfx),	\
+	PORT_1(fn, pfx##84, sfx),	PORT_1(fn, pfx##85, sfx),	\
+	/* Port96  - Port126 */						\
+	PORT_1(fn, pfx##96, sfx),	PORT_1(fn, pfx##97, sfx),	\
+	PORT_1(fn, pfx##98, sfx),	PORT_1(fn, pfx##99, sfx),	\
+	PORT_10(fn, pfx##10, sfx),					\
+	PORT_10(fn, pfx##11, sfx),					\
+	PORT_1(fn, pfx##120, sfx),	PORT_1(fn, pfx##121, sfx),	\
+	PORT_1(fn, pfx##122, sfx),	PORT_1(fn, pfx##123, sfx),	\
+	PORT_1(fn, pfx##124, sfx),	PORT_1(fn, pfx##125, sfx),	\
+	PORT_1(fn, pfx##126, sfx),					\
+	/* Port128 - Port134 */						\
+	PORT_1(fn, pfx##128, sfx),	PORT_1(fn, pfx##129, sfx),	\
+	PORT_1(fn, pfx##130, sfx),	PORT_1(fn, pfx##131, sfx),	\
+	PORT_1(fn, pfx##132, sfx),	PORT_1(fn, pfx##133, sfx),	\
+	PORT_1(fn, pfx##134, sfx),					\
+	/* Port160 - Port178 */						\
+	PORT_10(fn, pfx##16, sfx),					\
+	PORT_1(fn, pfx##170, sfx),	PORT_1(fn, pfx##171, sfx),	\
+	PORT_1(fn, pfx##172, sfx),	PORT_1(fn, pfx##173, sfx),	\
+	PORT_1(fn, pfx##174, sfx),	PORT_1(fn, pfx##175, sfx),	\
+	PORT_1(fn, pfx##176, sfx),	PORT_1(fn, pfx##177, sfx),	\
+	PORT_1(fn, pfx##178, sfx),					\
+	/* Port192 - Port222 */						\
+	PORT_1(fn, pfx##192, sfx),	PORT_1(fn, pfx##193, sfx),	\
+	PORT_1(fn, pfx##194, sfx),	PORT_1(fn, pfx##195, sfx),	\
+	PORT_1(fn, pfx##196, sfx),	PORT_1(fn, pfx##197, sfx),	\
+	PORT_1(fn, pfx##198, sfx),	PORT_1(fn, pfx##199, sfx),	\
+	PORT_10(fn, pfx##20, sfx),					\
+	PORT_10(fn, pfx##21, sfx),					\
+	PORT_1(fn, pfx##220, sfx),	PORT_1(fn, pfx##221, sfx),	\
+	PORT_1(fn, pfx##222, sfx),					\
+	/* Port224 - Port250 */						\
+	PORT_1(fn, pfx##224, sfx),	PORT_1(fn, pfx##225, sfx),	\
+	PORT_1(fn, pfx##226, sfx),	PORT_1(fn, pfx##227, sfx),	\
+	PORT_1(fn, pfx##228, sfx),	PORT_1(fn, pfx##229, sfx),	\
+	PORT_10(fn, pfx##23, sfx),					\
+	PORT_10(fn, pfx##24, sfx),					\
+	PORT_1(fn, pfx##250, sfx),					\
+	/* Port256 - Port283 */						\
+	PORT_1(fn, pfx##256, sfx),	PORT_1(fn, pfx##257, sfx),	\
+	PORT_1(fn, pfx##258, sfx),	PORT_1(fn, pfx##259, sfx),	\
+	PORT_10(fn, pfx##26, sfx),					\
+	PORT_10(fn, pfx##27, sfx),					\
+	PORT_1(fn, pfx##280, sfx),	PORT_1(fn, pfx##281, sfx),	\
+	PORT_1(fn, pfx##282, sfx),	PORT_1(fn, pfx##283, sfx),	\
+	/* Port288 - Port308 */						\
+	PORT_1(fn, pfx##288, sfx),	PORT_1(fn, pfx##289, sfx),	\
+	PORT_10(fn, pfx##29, sfx),					\
+	PORT_1(fn, pfx##300, sfx),	PORT_1(fn, pfx##301, sfx),	\
+	PORT_1(fn, pfx##302, sfx),	PORT_1(fn, pfx##303, sfx),	\
+	PORT_1(fn, pfx##304, sfx),	PORT_1(fn, pfx##305, sfx),	\
+	PORT_1(fn, pfx##306, sfx),	PORT_1(fn, pfx##307, sfx),	\
+	PORT_1(fn, pfx##308, sfx),					\
+	/* Port320 - Port329 */						\
+	PORT_10(fn, pfx##32, sfx)
+
+
+enum {
+	PINMUX_RESERVED = 0,
+
+	/* PORT0_DATA -> PORT329_DATA */
+	PINMUX_DATA_BEGIN,
+	PORT_ALL(DATA),
+	PINMUX_DATA_END,
+
+	/* PORT0_IN -> PORT329_IN */
+	PINMUX_INPUT_BEGIN,
+	PORT_ALL(IN),
+	PINMUX_INPUT_END,
+
+	/* PORT0_IN_PU -> PORT329_IN_PU */
+	PINMUX_INPUT_PULLUP_BEGIN,
+	PORT_ALL(IN_PU),
+	PINMUX_INPUT_PULLUP_END,
+
+	/* PORT0_IN_PD -> PORT329_IN_PD */
+	PINMUX_INPUT_PULLDOWN_BEGIN,
+	PORT_ALL(IN_PD),
+	PINMUX_INPUT_PULLDOWN_END,
+
+	/* PORT0_OUT -> PORT329_OUT */
+	PINMUX_OUTPUT_BEGIN,
+	PORT_ALL(OUT),
+	PINMUX_OUTPUT_END,
+
+	PINMUX_FUNCTION_BEGIN,
+	PORT_ALL(FN_IN), /* PORT0_FN_IN -> PORT329_FN_IN */
+	PORT_ALL(FN_OUT), /* PORT0_FN_OUT -> PORT329_FN_OUT */
+	PORT_ALL(FN0), /* PORT0_FN0 -> PORT329_FN0 */
+	PORT_ALL(FN1), /* PORT0_FN1 -> PORT329_FN1 */
+	PORT_ALL(FN2), /* PORT0_FN2 -> PORT329_FN2 */
+	PORT_ALL(FN3), /* PORT0_FN3 -> PORT329_FN3 */
+	PORT_ALL(FN4), /* PORT0_FN4 -> PORT329_FN4 */
+	PORT_ALL(FN5), /* PORT0_FN5 -> PORT329_FN5 */
+	PORT_ALL(FN6), /* PORT0_FN6 -> PORT329_FN6 */
+	PORT_ALL(FN7), /* PORT0_FN7 -> PORT329_FN7 */
+
+	MSEL1CR_31_0, MSEL1CR_31_1,
+	MSEL1CR_27_0, MSEL1CR_27_1,
+	MSEL1CR_25_0, MSEL1CR_25_1,
+	MSEL1CR_24_0, MSEL1CR_24_1,
+	MSEL1CR_22_0, MSEL1CR_22_1,
+	MSEL1CR_21_0, MSEL1CR_21_1,
+	MSEL1CR_20_0, MSEL1CR_20_1,
+	MSEL1CR_19_0, MSEL1CR_19_1,
+	MSEL1CR_18_0, MSEL1CR_18_1,
+	MSEL1CR_17_0, MSEL1CR_17_1,
+	MSEL1CR_16_0, MSEL1CR_16_1,
+	MSEL1CR_15_0, MSEL1CR_15_1,
+	MSEL1CR_14_0, MSEL1CR_14_1,
+	MSEL1CR_13_0, MSEL1CR_13_1,
+	MSEL1CR_12_0, MSEL1CR_12_1,
+	MSEL1CR_11_0, MSEL1CR_11_1,
+	MSEL1CR_10_0, MSEL1CR_10_1,
+	MSEL1CR_09_0, MSEL1CR_09_1,
+	MSEL1CR_08_0, MSEL1CR_08_1,
+	MSEL1CR_07_0, MSEL1CR_07_1,
+	MSEL1CR_06_0, MSEL1CR_06_1,
+	MSEL1CR_05_0, MSEL1CR_05_1,
+	MSEL1CR_04_0, MSEL1CR_04_1,
+	MSEL1CR_03_0, MSEL1CR_03_1,
+	MSEL1CR_02_0, MSEL1CR_02_1,
+	MSEL1CR_01_0, MSEL1CR_01_1,
+	MSEL1CR_00_0, MSEL1CR_00_1,
+
+	MSEL3CR_31_0, MSEL3CR_31_1,
+	MSEL3CR_28_0, MSEL3CR_28_1,
+	MSEL3CR_27_0, MSEL3CR_27_1,
+	MSEL3CR_26_0, MSEL3CR_26_1,
+	MSEL3CR_23_0, MSEL3CR_23_1,
+	MSEL3CR_22_0, MSEL3CR_22_1,
+	MSEL3CR_21_0, MSEL3CR_21_1,
+	MSEL3CR_20_0, MSEL3CR_20_1,
+	MSEL3CR_19_0, MSEL3CR_19_1,
+	MSEL3CR_18_0, MSEL3CR_18_1,
+	MSEL3CR_17_0, MSEL3CR_17_1,
+	MSEL3CR_16_0, MSEL3CR_16_1,
+	MSEL3CR_15_0, MSEL3CR_15_1,
+	MSEL3CR_12_0, MSEL3CR_12_1,
+	MSEL3CR_11_0, MSEL3CR_11_1,
+	MSEL3CR_10_0, MSEL3CR_10_1,
+	MSEL3CR_09_0, MSEL3CR_09_1,
+	MSEL3CR_06_0, MSEL3CR_06_1,
+	MSEL3CR_03_0, MSEL3CR_03_1,
+	MSEL3CR_01_0, MSEL3CR_01_1,
+	MSEL3CR_00_0, MSEL3CR_00_1,
+
+	MSEL4CR_30_0, MSEL4CR_30_1,
+	MSEL4CR_29_0, MSEL4CR_29_1,
+	MSEL4CR_28_0, MSEL4CR_28_1,
+	MSEL4CR_27_0, MSEL4CR_27_1,
+	MSEL4CR_26_0, MSEL4CR_26_1,
+	MSEL4CR_25_0, MSEL4CR_25_1,
+	MSEL4CR_24_0, MSEL4CR_24_1,
+	MSEL4CR_23_0, MSEL4CR_23_1,
+	MSEL4CR_22_0, MSEL4CR_22_1,
+	MSEL4CR_21_0, MSEL4CR_21_1,
+	MSEL4CR_20_0, MSEL4CR_20_1,
+	MSEL4CR_19_0, MSEL4CR_19_1,
+	MSEL4CR_18_0, MSEL4CR_18_1,
+	MSEL4CR_17_0, MSEL4CR_17_1,
+	MSEL4CR_16_0, MSEL4CR_16_1,
+	MSEL4CR_15_0, MSEL4CR_15_1,
+	MSEL4CR_14_0, MSEL4CR_14_1,
+	MSEL4CR_13_0, MSEL4CR_13_1,
+	MSEL4CR_12_0, MSEL4CR_12_1,
+	MSEL4CR_11_0, MSEL4CR_11_1,
+	MSEL4CR_10_0, MSEL4CR_10_1,
+	MSEL4CR_09_0, MSEL4CR_09_1,
+	MSEL4CR_07_0, MSEL4CR_07_1,
+	MSEL4CR_04_0, MSEL4CR_04_1,
+	MSEL4CR_01_0, MSEL4CR_01_1,
+
+	MSEL5CR_31_0, MSEL5CR_31_1,
+	MSEL5CR_30_0, MSEL5CR_30_1,
+	MSEL5CR_29_0, MSEL5CR_29_1,
+	MSEL5CR_28_0, MSEL5CR_28_1,
+	MSEL5CR_27_0, MSEL5CR_27_1,
+	MSEL5CR_26_0, MSEL5CR_26_1,
+	MSEL5CR_25_0, MSEL5CR_25_1,
+	MSEL5CR_24_0, MSEL5CR_24_1,
+	MSEL5CR_23_0, MSEL5CR_23_1,
+	MSEL5CR_22_0, MSEL5CR_22_1,
+	MSEL5CR_21_0, MSEL5CR_21_1,
+	MSEL5CR_20_0, MSEL5CR_20_1,
+	MSEL5CR_19_0, MSEL5CR_19_1,
+	MSEL5CR_18_0, MSEL5CR_18_1,
+	MSEL5CR_17_0, MSEL5CR_17_1,
+	MSEL5CR_16_0, MSEL5CR_16_1,
+	MSEL5CR_15_0, MSEL5CR_15_1,
+	MSEL5CR_14_0, MSEL5CR_14_1,
+	MSEL5CR_13_0, MSEL5CR_13_1,
+	MSEL5CR_12_0, MSEL5CR_12_1,
+	MSEL5CR_11_0, MSEL5CR_11_1,
+	MSEL5CR_10_0, MSEL5CR_10_1,
+	MSEL5CR_09_0, MSEL5CR_09_1,
+	MSEL5CR_08_0, MSEL5CR_08_1,
+	MSEL5CR_07_0, MSEL5CR_07_1,
+	MSEL5CR_06_0, MSEL5CR_06_1,
+
+	MSEL8CR_16_0, MSEL8CR_16_1,
+	MSEL8CR_01_0, MSEL8CR_01_1,
+	MSEL8CR_00_0, MSEL8CR_00_1,
+
+	PINMUX_FUNCTION_END,
+
+	PINMUX_MARK_BEGIN,
+
+
+#define F1(a)	a##_MARK
+#define F2(a)	a##_MARK
+#define F3(a)	a##_MARK
+#define F4(a)	a##_MARK
+#define F5(a)	a##_MARK
+#define F6(a)	a##_MARK
+#define F7(a)	a##_MARK
+#define IRQ(a)	IRQ##a##_MARK
+
+	F1(LCDD0), F3(PDM2_CLK_0), F7(DU0_DR0), IRQ(0), /* Port0 */
+	F1(LCDD1), F3(PDM2_DATA_1), F7(DU0_DR19), IRQ(1),
+	F1(LCDD2), F3(PDM3_CLK_2), F7(DU0_DR2), IRQ(2),
+	F1(LCDD3), F3(PDM3_DATA_3), F7(DU0_DR3), IRQ(3),
+	F1(LCDD4), F3(PDM4_CLK_4), F7(DU0_DR4), IRQ(4),
+	F1(LCDD5), F3(PDM4_DATA_5), F7(DU0_DR5), IRQ(5),
+	F1(LCDD6), F3(PDM0_OUTCLK_6), F7(DU0_DR6), IRQ(6),
+	F1(LCDD7), F3(PDM0_OUTDATA_7), F7(DU0_DR7), IRQ(7),
+	F1(LCDD8), F3(PDM1_OUTCLK_8), F7(DU0_DG0), IRQ(8),
+	F1(LCDD9), F3(PDM1_OUTDATA_9), F7(DU0_DG1), IRQ(9),
+	F1(LCDD10), F3(FSICCK), F7(DU0_DG2), IRQ(10), /* Port10 */
+	F1(LCDD11), F3(FSICISLD), F7(DU0_DG3), IRQ(11),
+	F1(LCDD12), F3(FSICOMC), F7(DU0_DG4), IRQ(12),
+	F1(LCDD13), F3(FSICOLR), F4(FSICILR), F7(DU0_DG5), IRQ(13),
+	F1(LCDD14), F3(FSICOBT), F4(FSICIBT), F7(DU0_DG6), IRQ(14),
+	F1(LCDD15), F3(FSICOSLD), F7(DU0_DG7), IRQ(15),
+	F1(LCDD16), F4(TPU1TO1), F7(DU0_DB0),
+	F1(LCDD17), F4(SF_IRQ_00), F7(DU0_DB1),
+	F1(LCDD18), F4(SF_IRQ_01), F7(DU0_DB2),
+	F1(LCDD19), F3(SCIFB3_RTS_19), F7(DU0_DB3),
+	F1(LCDD20), F3(SCIFB3_CTS_20), F7(DU0_DB4), /* Port20 */
+	F1(LCDD21), F3(SCIFB3_TXD_21), F7(DU0_DB5),
+	F1(LCDD22), F3(SCIFB3_RXD_22), F7(DU0_DB6),
+	F1(LCDD23), F3(SCIFB3_SCK_23), F7(DU0_DB7),
+	F1(LCDHSYN), F2(LCDCS), F3(SCIFB1_RTS_24),
+	F7(DU0_EXHSYNC_N_CSYNC_N_HSYNC_N),
+	F1(LCDVSYN), F3(SCIFB1_CTS_25), F7(DU0_EXVSYNC_N_VSYNC_N_CSYNC_N),
+	F1(LCDDCK), F2(LCDWR), F3(SCIFB1_TXD_26), F7(DU0_DOTCLKIN),
+	F1(LCDDISP), F2(LCDRS), F3(SCIFB1_RXD_27), F7(DU0_DOTCLKOUT),
+	F1(LCDRD_N), F3(SCIFB1_SCK_28), F7(DU0_DOTCLKOUTB),
+	F1(LCDLCLK), F4(SF_IRQ_02), F7(DU0_DISP_CSYNC_N_DE),
+	F1(LCDDON), F4(SF_IRQ_03), F7(DU0_ODDF_N_CLAMP), /* Port30 */
+
+	F1(SCIFA0_RTS), F5(SIM0_DET), F7(CSCIF0_RTS), /* Port32 */
+	F1(SCIFA0_CTS), F5(SIM1_DET), F7(CSCIF0_CTS),
+	F1(SCIFA0_SCK), F5(SIM0_PWRON), F7(CSCIF0_SCK),
+	F1(SCIFA1_RTS), F7(CSCIF1_RTS),
+	F1(SCIFA1_CTS), F7(CSCIF1_CTS),
+	F1(SCIFA1_SCK), F7(CSCIF1_SCK),
+	F1(SCIFB0_RTS), F3(TPU0TO1), F4(SCIFB3_RTS_38), F7(CHSCIF0_HRTS),
+	F1(SCIFB0_CTS), F3(TPU0TO2), F4(SCIFB3_CTS_39), F7(CHSCIF0_HCTS),
+	F1(SCIFB0_SCK), F3(TPU0TO3), F4(SCIFB3_SCK_40),
+	F7(CHSCIF0_HSCK), /* Port40 */
+
+	F1(PDM0_DATA), /* Port64 */
+	F1(PDM1_DATA),
+	F1(HSI_RX_WAKE), F2(SCIFB2_CTS_66), F3(MSIOF3_SYNC), F5(GenIO4),
+	IRQ(40),
+	F1(HSI_RX_READY), F2(SCIFB1_TXD_67), F5(GIO_OUT3_67), F7(CHSCIF1_HTX),
+	F1(HSI_RX_FLAG), F2(SCIFB2_TXD_68), F3(MSIOF3_TXD), F5(GIO_OUT4_68),
+	F1(HSI_RX_DATA), F2(SCIFB2_RXD_69), F3(MSIOF3_RXD), F5(GIO_OUT5_69),
+	F1(HSI_TX_FLAG), F2(SCIFB1_RTS_70), F5(GIO_OUT1_70), F6(HSIC_TSTCLK0),
+	F7(CHSCIF1_HRTS), /* Port70 */
+	F1(HSI_TX_DATA), F2(SCIFB1_CTS_71), F5(GIO_OUT2_71), F6(HSIC_TSTCLK1),
+	F7(CHSCIF1_HCTS),
+	F1(HSI_TX_WAKE), F2(SCIFB1_RXD_72), F5(GenIO8), F7(CHSCIF1_HRX),
+	F1(HSI_TX_READY), F2(SCIFB2_RTS_73), F3(MSIOF3_SCK), F5(GIO_OUT0_73),
+	F1(IRDA_OUT), F1(IRDA_IN), F1(IRDA_FIRSEL), F1(TPU0TO0),
+	F1(DIGRFEN), F1(GPS_TIMESTAMP), F1(TXP), /* Port80 */
+	F1(TXP2), F1(COEX_0), F1(COEX_1), IRQ(19), IRQ(18), /* Port85 */
+
+	F1(KEYIN0), /* Port96 */
+	F1(KEYIN1), F1(KEYIN2), F1(KEYIN3), F1(KEYIN4), /* Port100 */
+	F1(KEYIN5), F1(KEYIN6), IRQ(41), F1(KEYIN7), IRQ(42),
+	F2(KEYOUT0), F2(KEYOUT1), F2(KEYOUT2), F2(KEYOUT3),
+	F2(KEYOUT4), F2(KEYOUT5), IRQ(43), F2(KEYOUT6), IRQ(44), /* Port110 */
+	F2(KEYOUT7), F5(RFANAEN), IRQ(45),
+	F1(KEYIN8), F2(KEYOUT8), F4(SF_IRQ_04), IRQ(46),
+	F1(KEYIN9), F2(KEYOUT9), F4(SF_IRQ_05), IRQ(47),
+	F1(KEYIN10), F2(KEYOUT10), F4(SF_IRQ_06), IRQ(48),
+	F1(KEYIN11), F2(KEYOUT11), F4(SF_IRQ_07), IRQ(49),
+	F1(SCIFA0_TXD), F7(CSCIF0_TX), F1(SCIFA0_RXD), F7(CSCIF0_RX),
+	F1(SCIFA1_TXD), F7(CSCIF1_TX), F1(SCIFA1_RXD), F7(CSCIF1_RX),
+	F3(SF_PORT_1_120), F4(SCIFB3_RXD_120), F7(DU0_CDE), /* Port120 */
+	F3(SF_PORT_0_121), F4(SCIFB3_TXD_121),
+	F1(SCIFB0_TXD), F7(CHSCIF0_HTX),
+	F1(SCIFB0_RXD), F7(CHSCIF0_HRX), F3(ISP_STROBE_124),
+	F1(STP_ISD_0), F2(PDM4_CLK_125), F3(MSIOF2_TXD), F5(SIM0_VOLTSEL0),
+	F1(TS_SDEN), F2(MSIOF7_SYNC), F3(STP_ISEN_1),
+	F1(STP_ISEN_0), F2(PDM1_OUTDATA_128), F3(MSIOF2_SYNC),
+	F5(SIM1_VOLTSEL1), F1(TS_SPSYNC), F2(MSIOF7_RXD), F3(STP_ISSYNC_1),
+	F1(STP_ISSYNC_0), F2(PDM4_DATA_130), F3(MSIOF2_RXD),
+	F5(SIM0_VOLTSEL1), /* Port130 */
+	F1(STP_OPWM_0), F5(SIM1_PWRON), F1(TS_SCK), F2(MSIOF7_SCK),
+	F3(STP_ISCLK_1), F1(STP_ISCLK_0), F2(PDM1_OUTCLK_133), F3(MSIOF2_SCK),
+	F5(SIM1_VOLTSEL0), F1(TS_SDAT), F2(MSIOF7_TXD), F3(STP_ISD_1),
+	IRQ(20), /* Port160 */
+	IRQ(21), IRQ(22), IRQ(23),
+	F1(MMCD0_0), F1(MMCD0_1), F1(MMCD0_2), F1(MMCD0_3),
+	F1(MMCD0_4), F1(MMCD0_5), F1(MMCD0_6), /* Port170 */
+	F1(MMCD0_7), F1(MMCCMD0), F1(MMCCLK0), F1(MMCRST),
+	IRQ(24), IRQ(25), IRQ(26), IRQ(27),
+	F1(A10), F2(MMCD1_7), IRQ(31), /* Port192 */
+	F1(A9), F2(MMCD1_6), IRQ(32),
+	F1(A8), F2(MMCD1_5), IRQ(33),
+	F1(A7), F2(MMCD1_4), IRQ(34),
+	F1(A6), F2(MMCD1_3), IRQ(35),
+	F1(A5), F2(MMCD1_2), IRQ(36),
+	F1(A4), F2(MMCD1_1), IRQ(37),
+	F1(A3), F2(MMCD1_0), IRQ(38),
+	F1(A2), F2(MMCCMD1), IRQ(39), /* Port200 */
+	F1(A1),
+	F1(A0), F2(BS),
+	F1(CKO), F2(MMCCLK1),
+	F1(CS0_N), F5(SIM0_GPO1),
+	F1(CS2_N), F5(SIM0_GPO2),
+	F1(CS4_N), F2(VIO_VD), F5(SIM1_GPO0),
+	F1(D15), F5(GIO_OUT15),
+	F1(D14), F5(GIO_OUT14),
+	F1(D13), F5(GIO_OUT13),
+	F1(D12), F5(GIO_OUT12), /* Port210 */
+	F1(D11), F5(WGM_TXP2),
+	F1(D10), F5(WGM_GPS_TIMEM_ASK_RFCLK),
+	F1(D9), F2(VIO_D9), F5(GIO_OUT9),
+	F1(D8), F2(VIO_D8), F5(GIO_OUT8),
+	F1(D7), F2(VIO_D7), F5(GIO_OUT7),
+	F1(D6), F2(VIO_D6), F5(GIO_OUT6),
+	F1(D5), F2(VIO_D5), F5(GIO_OUT5_217),
+	F1(D4), F2(VIO_D4), F5(GIO_OUT4_218),
+	F1(D3), F2(VIO_D3), F5(GIO_OUT3_219),
+	F1(D2), F2(VIO_D2), F5(GIO_OUT2_220), /* Port220 */
+	F1(D1), F2(VIO_D1), F5(GIO_OUT1_221),
+	F1(D0), F2(VIO_D0), F5(GIO_OUT0_222),
+	F1(RDWR_224), F2(VIO_HD), F5(SIM1_GPO2),
+	F1(RD_N), F1(WAIT_N), F2(VIO_CLK), F5(SIM1_GPO1),
+	F1(WE0_N), F2(RDWR_227),
+	F1(WE1_N), F5(SIM0_GPO0),
+	F1(PWMO), F2(VIO_CKO1_229),
+	F1(SLIM_CLK), F2(VIO_CKO4_230), /* Port230 */
+	F1(SLIM_DATA), F2(VIO_CKO5_231), F2(VIO_CKO2_232), F4(SF_PORT_0_232),
+	F2(VIO_CKO3_233), F4(SF_PORT_1_233),
+	F1(FSIACK), F2(PDM3_CLK_234), F3(ISP_IRIS1_234),
+	F1(FSIAISLD), F2(PDM3_DATA_235),
+	F1(FSIAOMC), F2(PDM0_OUTCLK_236), F3(ISP_IRIS0_236),
+	F1(FSIAOLR), F2(FSIAILR), F1(FSIAOBT), F2(FSIAIBT),
+	F1(FSIAOSLD), F2(PDM0_OUTDATA_239),
+	F1(FSIBISLD), /* Port240 */
+	F1(FSIBOLR), F2(FSIBILR), F1(FSIBOMC), F3(ISP_SHUTTER1_242),
+	F1(FSIBOBT), F2(FSIBIBT), F1(FSIBOSLD), F2(FSIASPDIF),
+	F1(FSIBCK), F3(ISP_SHUTTER0_245),
+	F1(ISP_IRIS1_246), F1(ISP_IRIS0_247), F1(ISP_SHUTTER1_248),
+	F1(ISP_SHUTTER0_249), F1(ISP_STROBE_250), /* Port250 */
+	F1(MSIOF0_SYNC), F1(MSIOF0_RXD), F1(MSIOF0_SCK), F1(MSIOF0_SS2),
+	F3(VIO_CKO3_259), F1(MSIOF0_TXD), /* Port260 */
+	F2(SCIFB1_SCK_261), F7(CHSCIF1_HSCK), F2(SCIFB2_SCK_262),
+	F1(MSIOF1_SS2), F4(MSIOF5_SS2), F1(MSIOF1_TXD), F4(MSIOF5_TXD),
+	F1(MSIOF1_RXD), F4(MSIOF5_RXD), F1(MSIOF1_SS1), F4(MSIOF5_SS1),
+	F1(MSIOF0_SS1), F1(MSIOF1_SCK), F4(MSIOF5_SCK),
+	F1(MSIOF1_SYNC), F4(MSIOF5_SYNC),
+	F1(MSIOF2_SS1), F3(VIO_CKO5_270), /* Port270 */
+	F1(MSIOF2_SS2), F3(VIO_CKO2_271), F1(MSIOF3_SS2), F3(VIO_CKO1_272),
+	F1(MSIOF3_SS1), F3(VIO_CKO4_273), F1(MSIOF4_SS2), F4(TPU1TO0),
+	F1(IC_DP), F1(SIM0_RST), F1(IC_DM), F1(SIM0_BSICOMP),
+	F1(SIM0_CLK), F1(SIM0_IO), /* Port280 */
+	F1(SIM1_IO), F2(PDM2_DATA_281), F1(SIM1_CLK), F2(PDM2_CLK_282),
+	F1(SIM1_RST), F1(SDHID1_0), F3(STMDATA0_2),
+	F1(SDHID1_1), F3(STMDATA1_2), IRQ(51), /* Port290 */
+	F1(SDHID1_2), F3(STMDATA2_2), F1(SDHID1_3), F3(STMDATA3_2),
+	F1(SDHICLK1), F3(STMCLK_2), F1(SDHICMD1), F3(STMSIDI_2),
+	F1(SDHID2_0), F2(MSIOF4_TXD), F3(SCIFB2_TXD_295), F4(MSIOF6_TXD),
+	F1(SDHID2_1), F4(MSIOF6_SS2), IRQ(52),
+	F1(SDHID2_2), F2(MSIOF4_RXD), F3(SCIFB2_RXD_297), F4(MSIOF6_RXD),
+	F1(SDHID2_3), F2(MSIOF4_SYNC), F3(SCIFB2_CTS_298), F4(MSIOF6_SYNC),
+	F1(SDHICLK2), F2(MSIOF4_SCK), F3(SCIFB2_SCK_299), F4(MSIOF6_SCK),
+	F1(SDHICMD2), F2(MSIOF4_SS1), F3(SCIFB2_RTS_300),
+	F4(MSIOF6_SS1), /* Port300 */
+	F1(SDHICD0), IRQ(50), F1(SDHID0_0), F3(STMDATA0_1),
+	F1(SDHID0_1), F3(STMDATA1_1), F1(SDHID0_2), F3(STMDATA2_1),
+	F1(SDHID0_3), F3(STMDATA3_1), F1(SDHICMD0), F3(STMSIDI_1),
+	F1(SDHIWP0), F1(SDHICLK0), F3(STMCLK_1), IRQ(16), /* Port320 */
+	IRQ(17), IRQ(28), IRQ(29), IRQ(30), IRQ(53), IRQ(54),
+	IRQ(55), IRQ(56), IRQ(57),
+	PINMUX_MARK_END,
+};
+
+static const pinmux_enum_t pinmux_data[] = {
+	/* specify valid pin states for each pin in GPIO mode */
+
+	PORT_DATA_IO_PU_PD(0), PORT_DATA_IO_PU_PD(1),
+	PORT_DATA_IO_PU_PD(2), PORT_DATA_IO_PU_PD(3),
+	PORT_DATA_IO_PU_PD(4), PORT_DATA_IO_PU_PD(5),
+	PORT_DATA_IO_PU_PD(6), PORT_DATA_IO_PU_PD(7),
+	PORT_DATA_IO_PU_PD(8), PORT_DATA_IO_PU_PD(9),
+
+	PORT_DATA_IO_PU_PD(10), PORT_DATA_IO_PU_PD(11),
+	PORT_DATA_IO_PU_PD(12), PORT_DATA_IO_PU_PD(13),
+	PORT_DATA_IO_PU_PD(14),	PORT_DATA_IO_PU_PD(15),
+	PORT_DATA_IO_PU_PD(16), PORT_DATA_IO_PU_PD(17),
+	PORT_DATA_IO_PU_PD(18), PORT_DATA_IO_PU_PD(19),
+
+	PORT_DATA_IO_PU_PD(20), PORT_DATA_IO_PU_PD(21),
+	PORT_DATA_IO_PU_PD(22), PORT_DATA_IO_PU_PD(23),
+	PORT_DATA_IO_PU_PD(24),	PORT_DATA_IO_PU_PD(25),
+	PORT_DATA_IO_PU_PD(26), PORT_DATA_IO_PU_PD(27),
+	PORT_DATA_IO_PU_PD(28), PORT_DATA_IO_PU_PD(29),
+
+	PORT_DATA_IO_PU_PD(30), PORT_DATA_IO_PU_PD(32),
+	PORT_DATA_IO_PU_PD(33), PORT_DATA_IO_PU_PD(34),
+	PORT_DATA_IO_PU_PD(35), PORT_DATA_IO_PU_PD(36),
+	PORT_DATA_IO_PU_PD(37), PORT_DATA_IO_PU_PD(38),
+	PORT_DATA_IO_PU_PD(39), PORT_DATA_IO_PU_PD(40),
+
+	PORT_DATA_IO_PU_PD(64),	PORT_DATA_IO_PU_PD(65),
+	PORT_DATA_IO_PU_PD(66), PORT_DATA_IO_PU_PD(67),
+	PORT_DATA_IO_PU_PD(68), PORT_DATA_IO_PU_PD(69),
+
+	PORT_DATA_IO_PU_PD(70), PORT_DATA_IO_PU_PD(71),
+	PORT_DATA_IO_PU_PD(72), PORT_DATA_IO_PU_PD(73),
+	PORT_DATA_O(74), PORT_DATA_IO_PU_PD(75),
+	PORT_DATA_IO_PU_PD(76), PORT_DATA_IO_PU_PD(77),
+	PORT_DATA_IO_PU_PD(78), PORT_DATA_IO_PU_PD(79),
+
+	PORT_DATA_IO_PU_PD(80), PORT_DATA_IO_PU_PD(81),
+	PORT_DATA_IO_PU_PD(82), PORT_DATA_IO_PU_PD(83),
+	PORT_DATA_IO_PU_PD(84), PORT_DATA_IO_PU_PD(85),
+
+	PORT_DATA_IO_PU_PD(96), PORT_DATA_IO_PU_PD(97),
+	PORT_DATA_IO_PU_PD(98), PORT_DATA_IO_PU_PD(99),
+
+	PORT_DATA_IO_PU_PD(100), PORT_DATA_IO_PU_PD(101),
+	PORT_DATA_IO_PU_PD(102), PORT_DATA_IO_PU_PD(103),
+	PORT_DATA_IO_PU_PD(104), PORT_DATA_IO_PU_PD(105),
+	PORT_DATA_IO_PU_PD(106), PORT_DATA_IO_PU_PD(107),
+	PORT_DATA_IO_PU_PD(108), PORT_DATA_IO_PU_PD(109),
+
+	PORT_DATA_IO_PU_PD(110), PORT_DATA_IO_PU_PD(111),
+	PORT_DATA_IO_PU_PD(112), PORT_DATA_IO_PU_PD(113),
+	PORT_DATA_IO_PU_PD(114), PORT_DATA_IO_PU_PD(115),
+	PORT_DATA_IO_PU_PD(116), PORT_DATA_IO_PU_PD(117),
+	PORT_DATA_IO_PU_PD(118), PORT_DATA_IO_PU_PD(119),
+
+	PORT_DATA_IO_PU_PD(120), PORT_DATA_IO_PU_PD(121),
+	PORT_DATA_IO_PU_PD(122), PORT_DATA_IO_PU_PD(123),
+	PORT_DATA_IO_PU_PD(124), PORT_DATA_IO_PU_PD(125),
+	PORT_DATA_IO_PU_PD(126),
+	PORT_DATA_IO_PU_PD(128), PORT_DATA_IO_PU_PD(129),
+
+	PORT_DATA_IO_PU_PD(130), PORT_DATA_IO_PU_PD(131),
+	PORT_DATA_IO_PU_PD(132), PORT_DATA_IO_PU_PD(133),
+	PORT_DATA_IO_PU_PD(134),
+
+	PORT_DATA_IO_PU_PD(160), PORT_DATA_IO_PU_PD(161),
+	PORT_DATA_IO_PU_PD(162), PORT_DATA_IO_PU_PD(163),
+	PORT_DATA_IO_PU_PD(164), PORT_DATA_IO_PU_PD(165),
+	PORT_DATA_IO_PU_PD(166), PORT_DATA_IO_PU_PD(167),
+	PORT_DATA_IO_PU_PD(168), PORT_DATA_IO_PU_PD(169),
+
+	PORT_DATA_IO_PU_PD(170), PORT_DATA_IO_PU_PD(171),
+	PORT_DATA_IO_PU_PD(172), PORT_DATA_IO_PU_PD(173),
+	PORT_DATA_IO_PU_PD(174), PORT_DATA_IO_PU_PD(175),
+	PORT_DATA_IO_PU_PD(176), PORT_DATA_IO_PU_PD(177),
+	PORT_DATA_IO_PU_PD(178),
+
+	PORT_DATA_IO_PU_PD(192), PORT_DATA_IO_PU_PD(193),
+	PORT_DATA_IO_PU_PD(194), PORT_DATA_IO_PU_PD(195),
+	PORT_DATA_IO_PU_PD(196), PORT_DATA_IO_PU_PD(197),
+	PORT_DATA_IO_PU_PD(198), PORT_DATA_IO_PU_PD(199),
+
+	PORT_DATA_IO_PU_PD(200), PORT_DATA_IO_PU_PD(201),
+	PORT_DATA_IO_PU_PD(202), PORT_DATA_IO_PU_PD(203),
+	PORT_DATA_IO_PU_PD(204), PORT_DATA_IO_PU_PD(205),
+	PORT_DATA_IO_PU_PD(206), PORT_DATA_IO_PU_PD(207),
+	PORT_DATA_IO_PU_PD(208), PORT_DATA_IO_PU_PD(209),
+
+	PORT_DATA_IO_PU_PD(210), PORT_DATA_IO_PU_PD(211),
+	PORT_DATA_IO_PU_PD(212), PORT_DATA_IO_PU_PD(213),
+	PORT_DATA_IO_PU_PD(214), PORT_DATA_IO_PU_PD(215),
+	PORT_DATA_IO_PU_PD(216), PORT_DATA_IO_PU_PD(217),
+	PORT_DATA_IO_PU_PD(218), PORT_DATA_IO_PU_PD(219),
+
+	PORT_DATA_IO_PU_PD(220), PORT_DATA_IO_PU_PD(221),
+	PORT_DATA_IO_PU_PD(222), PORT_DATA_IO_PU_PD(224),
+	PORT_DATA_IO_PU_PD(225), PORT_DATA_IO_PU_PD(226),
+	PORT_DATA_IO_PU_PD(227), PORT_DATA_IO_PU_PD(228),
+	PORT_DATA_IO_PU_PD(229),
+
+	PORT_DATA_IO_PU_PD(230), PORT_DATA_IO_PU_PD(231),
+	PORT_DATA_IO_PU_PD(232), PORT_DATA_IO_PU_PD(233),
+	PORT_DATA_IO_PU_PD(234), PORT_DATA_IO_PU_PD(235),
+	PORT_DATA_IO_PU_PD(236), PORT_DATA_IO_PU_PD(237),
+	PORT_DATA_IO_PU_PD(238), PORT_DATA_IO_PU_PD(239),
+
+	PORT_DATA_IO_PU_PD(240), PORT_DATA_IO_PU_PD(241),
+	PORT_DATA_IO_PU_PD(242), PORT_DATA_IO_PU_PD(243),
+	PORT_DATA_IO_PU_PD(244), PORT_DATA_IO_PU_PD(245),
+	PORT_DATA_IO_PU_PD(246), PORT_DATA_IO_PU_PD(247),
+	PORT_DATA_IO_PU_PD(248), PORT_DATA_IO_PU_PD(249),
+
+	PORT_DATA_IO_PU_PD(250),
+	PORT_DATA_IO_PU_PD(256), PORT_DATA_IO_PU_PD(257),
+	PORT_DATA_IO_PU_PD(258), PORT_DATA_IO_PU_PD(259),
+
+	PORT_DATA_IO_PU_PD(260), PORT_DATA_IO_PU_PD(261),
+	PORT_DATA_IO_PU_PD(262), PORT_DATA_IO_PU_PD(263),
+	PORT_DATA_IO_PU_PD(264), PORT_DATA_IO_PU_PD(265),
+	PORT_DATA_IO_PU_PD(266), PORT_DATA_IO_PU_PD(267),
+	PORT_DATA_IO_PU_PD(268), PORT_DATA_IO_PU_PD(269),
+
+	PORT_DATA_IO_PU_PD(270), PORT_DATA_IO_PU_PD(271),
+	PORT_DATA_IO_PU_PD(272), PORT_DATA_IO_PU_PD(273),
+	PORT_DATA_IO_PU_PD(274), PORT_DATA_IO_PU_PD(275),
+	PORT_DATA_IO_PU_PD(276), PORT_DATA_IO_PU_PD(277),
+	PORT_DATA_IO_PU_PD(278), PORT_DATA_IO_PU_PD(279),
+
+	PORT_DATA_IO_PU_PD(280), PORT_DATA_IO_PU_PD(281),
+	PORT_DATA_IO_PU_PD(282), PORT_DATA_IO_PU_PD(283),
+	PORT_DATA_O(288), PORT_DATA_IO_PU_PD(289),
+
+	PORT_DATA_IO_PU_PD(290), PORT_DATA_IO_PU_PD(291),
+	PORT_DATA_IO_PU_PD(292), PORT_DATA_IO_PU_PD(293),
+	PORT_DATA_IO_PU_PD(294), PORT_DATA_IO_PU_PD(295),
+	PORT_DATA_IO_PU_PD(296), PORT_DATA_IO_PU_PD(297),
+	PORT_DATA_IO_PU_PD(298), PORT_DATA_IO_PU_PD(299),
+
+	PORT_DATA_IO_PU_PD(300), PORT_DATA_IO_PU_PD(301),
+	PORT_DATA_IO_PU_PD(302), PORT_DATA_IO_PU_PD(303),
+	PORT_DATA_IO_PU_PD(304), PORT_DATA_IO_PU_PD(305),
+	PORT_DATA_IO_PU_PD(306), PORT_DATA_IO_PU_PD(307),
+	PORT_DATA_IO_PU_PD(308),
+
+	PORT_DATA_IO_PU_PD(320), PORT_DATA_IO_PU_PD(321),
+	PORT_DATA_IO_PU_PD(322), PORT_DATA_IO_PU_PD(323),
+	PORT_DATA_IO_PU_PD(324), PORT_DATA_IO_PU_PD(325),
+	PORT_DATA_IO_PU_PD(326), PORT_DATA_IO_PU_PD(327),
+	PORT_DATA_IO_PU_PD(328), PORT_DATA_IO_PU_PD(329),
+
+	/* Port0 */
+	PINMUX_DATA(LCDD0_MARK,		PORT0_FN1),
+	PINMUX_DATA(PDM2_CLK_0_MARK,	PORT0_FN3),
+	PINMUX_DATA(DU0_DR0_MARK,	PORT0_FN7),
+	PINMUX_DATA(IRQ0_MARK,		PORT0_FN0),
+
+	/* Port1 */
+	PINMUX_DATA(LCDD1_MARK,		PORT1_FN1),
+	PINMUX_DATA(PDM2_DATA_1_MARK,	PORT1_FN3,	MSEL3CR_12_0),
+	PINMUX_DATA(DU0_DR19_MARK,	PORT1_FN7),
+	PINMUX_DATA(IRQ1_MARK,		PORT1_FN0),
+
+	/* Port2 */
+	PINMUX_DATA(LCDD2_MARK,		PORT2_FN1),
+	PINMUX_DATA(PDM3_CLK_2_MARK,	PORT2_FN3),
+	PINMUX_DATA(DU0_DR2_MARK,	PORT2_FN7),
+	PINMUX_DATA(IRQ2_MARK,		PORT2_FN0),
+
+	/* Port3 */
+	PINMUX_DATA(LCDD3_MARK,		PORT3_FN1),
+	PINMUX_DATA(PDM3_DATA_3_MARK,	PORT3_FN3,	MSEL3CR_12_0),
+	PINMUX_DATA(DU0_DR3_MARK,	PORT3_FN7),
+	PINMUX_DATA(IRQ3_MARK,		PORT3_FN0),
+
+	/* Port4 */
+	PINMUX_DATA(LCDD4_MARK,		PORT4_FN1),
+	PINMUX_DATA(PDM4_CLK_4_MARK,	PORT4_FN3),
+	PINMUX_DATA(DU0_DR4_MARK,	PORT4_FN7),
+	PINMUX_DATA(IRQ4_MARK,		PORT4_FN0),
+
+	/* Port5 */
+	PINMUX_DATA(LCDD5_MARK,		PORT5_FN1),
+	PINMUX_DATA(PDM4_DATA_5_MARK,	PORT5_FN3,	MSEL3CR_12_0),
+	PINMUX_DATA(DU0_DR5_MARK,	PORT5_FN7),
+	PINMUX_DATA(IRQ5_MARK,		PORT5_FN0),
+
+	/* Port6 */
+	PINMUX_DATA(LCDD6_MARK,		PORT6_FN1),
+	PINMUX_DATA(PDM0_OUTCLK_6_MARK,	PORT6_FN3),
+	PINMUX_DATA(DU0_DR6_MARK,	PORT6_FN7),
+	PINMUX_DATA(IRQ6_MARK,		PORT6_FN0),
+
+	/* Port7 */
+	PINMUX_DATA(LCDD7_MARK,			PORT7_FN1),
+	PINMUX_DATA(PDM0_OUTDATA_7_MARK,	PORT7_FN3),
+	PINMUX_DATA(DU0_DR7_MARK,		PORT7_FN7),
+	PINMUX_DATA(IRQ7_MARK,			PORT7_FN0),
+
+	/* Port8 */
+	PINMUX_DATA(LCDD8_MARK,		PORT8_FN1),
+	PINMUX_DATA(PDM1_OUTCLK_8_MARK,	PORT8_FN3),
+	PINMUX_DATA(DU0_DG0_MARK,	PORT8_FN7),
+	PINMUX_DATA(IRQ8_MARK,		PORT8_FN0),
+
+	/* Port9 */
+	PINMUX_DATA(LCDD9_MARK,		PORT9_FN1),
+	PINMUX_DATA(PDM1_OUTDATA_9_MARK, PORT9_FN3),
+	PINMUX_DATA(DU0_DG1_MARK,	PORT9_FN7),
+	PINMUX_DATA(IRQ9_MARK,		PORT9_FN0),
+
+	/* Port10 */
+	PINMUX_DATA(LCDD10_MARK,		PORT10_FN1),
+	PINMUX_DATA(FSICCK_MARK,		PORT10_FN3),
+	PINMUX_DATA(DU0_DG2_MARK,		PORT10_FN7),
+	PINMUX_DATA(IRQ10_MARK,			PORT10_FN0),
+
+	/* Port11 */
+	PINMUX_DATA(LCDD11_MARK,		PORT11_FN1),
+	PINMUX_DATA(FSICISLD_MARK,		PORT11_FN3),
+	PINMUX_DATA(DU0_DG3_MARK,		PORT11_FN7),
+	PINMUX_DATA(IRQ11_MARK,			PORT11_FN0),
+
+	/* Port12 */
+	PINMUX_DATA(LCDD12_MARK,		PORT12_FN1),
+	PINMUX_DATA(FSICOMC_MARK,		PORT12_FN3),
+	PINMUX_DATA(DU0_DG4_MARK,		PORT12_FN7),
+	PINMUX_DATA(IRQ12_MARK,			PORT12_FN0),
+
+	/* Port13 */
+	PINMUX_DATA(LCDD13_MARK,		PORT13_FN1),
+	PINMUX_DATA(FSICOLR_MARK,		PORT13_FN3),
+	PINMUX_DATA(FSICILR_MARK,		PORT13_FN4),
+	PINMUX_DATA(DU0_DG5_MARK,		PORT13_FN7),
+	PINMUX_DATA(IRQ13_MARK,			PORT13_FN0),
+
+	/* Port14 */
+	PINMUX_DATA(LCDD14_MARK,		PORT14_FN1),
+	PINMUX_DATA(FSICOBT_MARK,		PORT14_FN3),
+	PINMUX_DATA(FSICIBT_MARK,		PORT14_FN4),
+	PINMUX_DATA(DU0_DG6_MARK,		PORT14_FN7),
+	PINMUX_DATA(IRQ14_MARK,			PORT14_FN0),
+
+	/* Port15 */
+	PINMUX_DATA(LCDD15_MARK,		PORT15_FN1),
+	PINMUX_DATA(FSICOSLD_MARK,		PORT15_FN3),
+	PINMUX_DATA(DU0_DG7_MARK,		PORT15_FN7),
+	PINMUX_DATA(IRQ15_MARK,			PORT15_FN0),
+
+	/* Port16 */
+	PINMUX_DATA(LCDD16_MARK,		PORT16_FN1),
+	PINMUX_DATA(TPU1TO1_MARK,		PORT16_FN4),
+	PINMUX_DATA(DU0_DB0_MARK,		PORT16_FN7),
+
+	/* Port17 */
+	PINMUX_DATA(LCDD17_MARK,		PORT17_FN1),
+	PINMUX_DATA(SF_IRQ_00_MARK,		PORT17_FN4),
+	PINMUX_DATA(DU0_DB1_MARK,		PORT17_FN7),
+
+	/* Port18 */
+	PINMUX_DATA(LCDD18_MARK,		PORT18_FN1),
+	PINMUX_DATA(SF_IRQ_01_MARK,		PORT18_FN4),
+	PINMUX_DATA(DU0_DB2_MARK,		PORT18_FN7),
+
+	/* Port19 */
+	PINMUX_DATA(LCDD19_MARK,		PORT19_FN1),
+	PINMUX_DATA(SCIFB3_RTS_19_MARK,		PORT19_FN3),
+	PINMUX_DATA(DU0_DB3_MARK,		PORT19_FN7),
+
+	/* Port20 */
+	PINMUX_DATA(LCDD20_MARK,		PORT20_FN1),
+	PINMUX_DATA(SCIFB3_CTS_20_MARK,		PORT20_FN3,	MSEL3CR_09_0),
+	PINMUX_DATA(DU0_DB4_MARK,		PORT20_FN7),
+
+	/* Port21 */
+	PINMUX_DATA(LCDD21_MARK,		PORT21_FN1),
+	PINMUX_DATA(SCIFB3_TXD_21_MARK,		PORT21_FN3,	MSEL3CR_09_0),
+	PINMUX_DATA(DU0_DB5_MARK,		PORT21_FN7),
+
+	/* Port22 */
+	PINMUX_DATA(LCDD22_MARK,		PORT22_FN1),
+	PINMUX_DATA(SCIFB3_RXD_22_MARK,		PORT22_FN3,	MSEL3CR_09_0),
+	PINMUX_DATA(DU0_DB6_MARK,		PORT22_FN7),
+
+	/* Port23 */
+	PINMUX_DATA(LCDD23_MARK,		PORT23_FN1),
+	PINMUX_DATA(SCIFB3_SCK_23_MARK,		PORT23_FN3),
+	PINMUX_DATA(DU0_DB7_MARK,		PORT23_FN7),
+
+	/* Port24 */
+	PINMUX_DATA(LCDHSYN_MARK,			PORT24_FN1),
+	PINMUX_DATA(LCDCS_MARK,				PORT24_FN2),
+	PINMUX_DATA(SCIFB1_RTS_24_MARK,			PORT24_FN3),
+	PINMUX_DATA(DU0_EXHSYNC_N_CSYNC_N_HSYNC_N_MARK,	PORT24_FN7),
+
+	/* Port25 */
+	PINMUX_DATA(LCDVSYN_MARK,			PORT25_FN1),
+	PINMUX_DATA(SCIFB1_CTS_25_MARK, PORT25_FN3, MSEL3CR_11_0),
+	PINMUX_DATA(DU0_EXVSYNC_N_VSYNC_N_CSYNC_N_MARK,	PORT25_FN7),
+
+	/* Port26 */
+	PINMUX_DATA(LCDDCK_MARK,		PORT26_FN1),
+	PINMUX_DATA(LCDWR_MARK,			PORT26_FN2),
+	PINMUX_DATA(SCIFB1_TXD_26_MARK,		PORT26_FN3,	MSEL3CR_11_0),
+	PINMUX_DATA(DU0_DOTCLKIN_MARK,		PORT26_FN7),
+
+	/* Port27 */
+	PINMUX_DATA(LCDDISP_MARK,		PORT27_FN1),
+	PINMUX_DATA(LCDRS_MARK,			PORT27_FN2),
+	PINMUX_DATA(SCIFB1_RXD_27_MARK,		PORT27_FN3,	MSEL3CR_11_0),
+	PINMUX_DATA(DU0_DOTCLKOUT_MARK,		PORT27_FN7),
+
+	/* Port28 */
+	PINMUX_DATA(LCDRD_N_MARK,		PORT28_FN1),
+	PINMUX_DATA(SCIFB1_SCK_28_MARK,		PORT28_FN3),
+	PINMUX_DATA(DU0_DOTCLKOUTB_MARK,	PORT28_FN7),
+
+	/* Port29 */
+	PINMUX_DATA(LCDLCLK_MARK,		PORT29_FN1),
+	PINMUX_DATA(SF_IRQ_02_MARK,		PORT29_FN4),
+	PINMUX_DATA(DU0_DISP_CSYNC_N_DE_MARK,	PORT29_FN7),
+
+	/* Port30 */
+	PINMUX_DATA(LCDDON_MARK,		PORT30_FN1),
+	PINMUX_DATA(SF_IRQ_03_MARK,		PORT30_FN4),
+	PINMUX_DATA(DU0_ODDF_N_CLAMP_MARK,	PORT30_FN7),
+
+	/* Port32 */
+	PINMUX_DATA(SCIFA0_RTS_MARK,		PORT32_FN1),
+	PINMUX_DATA(SIM0_DET_MARK,		PORT32_FN5),
+	PINMUX_DATA(CSCIF0_RTS_MARK,		PORT32_FN7),
+
+	/* Port33 */
+	PINMUX_DATA(SCIFA0_CTS_MARK,		PORT33_FN1),
+	PINMUX_DATA(SIM1_DET_MARK,		PORT33_FN5),
+	PINMUX_DATA(CSCIF0_CTS_MARK,		PORT33_FN7),
+
+	/* Port34 */
+	PINMUX_DATA(SCIFA0_SCK_MARK,		PORT34_FN1),
+	PINMUX_DATA(SIM0_PWRON_MARK,		PORT34_FN5),
+	PINMUX_DATA(CSCIF0_SCK_MARK,		PORT34_FN7),
+
+	/* Port35 */
+	PINMUX_DATA(SCIFA1_RTS_MARK,		PORT35_FN1),
+	PINMUX_DATA(CSCIF1_RTS_MARK,		PORT35_FN7),
+
+	/* Port36 */
+	PINMUX_DATA(SCIFA1_CTS_MARK,		PORT36_FN1),
+	PINMUX_DATA(CSCIF1_CTS_MARK,		PORT36_FN7),
+
+	/* Port37 */
+	PINMUX_DATA(SCIFA1_SCK_MARK,		PORT37_FN1),
+	PINMUX_DATA(CSCIF1_SCK_MARK,		PORT37_FN7),
+
+	/* Port38 */
+	PINMUX_DATA(SCIFB0_RTS_MARK,		PORT38_FN1),
+	PINMUX_DATA(TPU0TO1_MARK,		PORT38_FN3),
+	PINMUX_DATA(SCIFB3_RTS_38_MARK,		PORT38_FN4),
+	PINMUX_DATA(CHSCIF0_HRTS_MARK,		PORT38_FN7),
+
+	/* Port39 */
+	PINMUX_DATA(SCIFB0_CTS_MARK,		PORT39_FN1),
+	PINMUX_DATA(TPU0TO2_MARK,		PORT39_FN3),
+	PINMUX_DATA(SCIFB3_CTS_39_MARK,		PORT39_FN4,	MSEL3CR_09_1),
+	PINMUX_DATA(CHSCIF0_HCTS_MARK,		PORT39_FN7),
+
+	/* Port40 */
+	PINMUX_DATA(SCIFB0_SCK_MARK,		PORT40_FN1),
+	PINMUX_DATA(TPU0TO3_MARK,		PORT40_FN3),
+	PINMUX_DATA(SCIFB3_SCK_40_MARK,		PORT40_FN4),
+	PINMUX_DATA(CHSCIF0_HSCK_MARK,		PORT40_FN7),
+
+	/* Port64 */
+	PINMUX_DATA(PDM0_DATA_MARK,		PORT64_FN1),
+
+	/* Port65 */
+	PINMUX_DATA(PDM1_DATA_MARK,		PORT65_FN1),
+
+	/* Port66 */
+	PINMUX_DATA(HSI_RX_WAKE_MARK,		PORT66_FN1),
+	PINMUX_DATA(SCIFB2_CTS_66_MARK,		PORT66_FN2,	MSEL3CR_10_0),
+	PINMUX_DATA(MSIOF3_SYNC_MARK,		PORT66_FN3),
+	PINMUX_DATA(GenIO4_MARK,		PORT66_FN5),
+	PINMUX_DATA(IRQ40_MARK,			PORT66_FN0),
+
+	/* Port67 */
+	PINMUX_DATA(HSI_RX_READY_MARK,		PORT67_FN1),
+	PINMUX_DATA(SCIFB1_TXD_67_MARK,		PORT67_FN2,	MSEL3CR_11_1),
+	PINMUX_DATA(GIO_OUT3_67_MARK,		PORT67_FN5),
+	PINMUX_DATA(CHSCIF1_HTX_MARK,		PORT67_FN7),
+
+	/* Port68 */
+	PINMUX_DATA(HSI_RX_FLAG_MARK,		PORT68_FN1),
+	PINMUX_DATA(SCIFB2_TXD_68_MARK,		PORT68_FN2,	MSEL3CR_10_0),
+	PINMUX_DATA(MSIOF3_TXD_MARK,		PORT68_FN3),
+	PINMUX_DATA(GIO_OUT4_68_MARK,		PORT68_FN5),
+
+	/* Port69 */
+	PINMUX_DATA(HSI_RX_DATA_MARK,		PORT69_FN1),
+	PINMUX_DATA(SCIFB2_RXD_69_MARK,		PORT69_FN2,	MSEL3CR_10_0),
+	PINMUX_DATA(MSIOF3_RXD_MARK,		PORT69_FN3),
+	PINMUX_DATA(GIO_OUT5_69_MARK,		PORT69_FN5),
+
+	/* Port70 */
+	PINMUX_DATA(HSI_TX_FLAG_MARK,		PORT70_FN1),
+	PINMUX_DATA(SCIFB1_RTS_70_MARK,		PORT70_FN2),
+	PINMUX_DATA(GIO_OUT1_70_MARK,		PORT70_FN5),
+	PINMUX_DATA(HSIC_TSTCLK0_MARK,		PORT70_FN6),
+	PINMUX_DATA(CHSCIF1_HRTS_MARK,		PORT70_FN7),
+
+	/* Port71 */
+	PINMUX_DATA(HSI_TX_DATA_MARK,		PORT71_FN1),
+	PINMUX_DATA(SCIFB1_CTS_71_MARK,		PORT71_FN2,	MSEL3CR_11_1),
+	PINMUX_DATA(GIO_OUT2_71_MARK,		PORT71_FN5),
+	PINMUX_DATA(HSIC_TSTCLK1_MARK,		PORT71_FN6),
+	PINMUX_DATA(CHSCIF1_HCTS_MARK,		PORT71_FN7),
+
+	/* Port72 */
+	PINMUX_DATA(HSI_TX_WAKE_MARK,		PORT72_FN1),
+	PINMUX_DATA(SCIFB1_RXD_72_MARK,		PORT72_FN2,	MSEL3CR_11_1),
+	PINMUX_DATA(GenIO8_MARK,		PORT72_FN5),
+	PINMUX_DATA(CHSCIF1_HRX_MARK,		PORT72_FN7),
+
+	/* Port73 */
+	PINMUX_DATA(HSI_TX_READY_MARK,		PORT73_FN1),
+	PINMUX_DATA(SCIFB2_RTS_73_MARK,		PORT73_FN2),
+	PINMUX_DATA(MSIOF3_SCK_MARK,		PORT73_FN3),
+	PINMUX_DATA(GIO_OUT0_73_MARK,		PORT73_FN5),
+
+	/* Port74 - Port85 */
+	PINMUX_DATA(IRDA_OUT_MARK,		PORT74_FN1),
+	PINMUX_DATA(IRDA_IN_MARK,		PORT75_FN1),
+	PINMUX_DATA(IRDA_FIRSEL_MARK,		PORT76_FN1),
+	PINMUX_DATA(TPU0TO0_MARK,		PORT77_FN1),
+	PINMUX_DATA(DIGRFEN_MARK,		PORT78_FN1),
+	PINMUX_DATA(GPS_TIMESTAMP_MARK,		PORT79_FN1),
+	PINMUX_DATA(TXP_MARK,			PORT80_FN1),
+	PINMUX_DATA(TXP2_MARK,			PORT81_FN1),
+	PINMUX_DATA(COEX_0_MARK,		PORT82_FN1),
+	PINMUX_DATA(COEX_1_MARK,		PORT83_FN1),
+	PINMUX_DATA(IRQ19_MARK,			PORT84_FN0),
+	PINMUX_DATA(IRQ18_MARK,			PORT85_FN0),
+
+	/* Port96 - Port101 */
+	PINMUX_DATA(KEYIN0_MARK,		PORT96_FN1),
+	PINMUX_DATA(KEYIN1_MARK,		PORT97_FN1),
+	PINMUX_DATA(KEYIN2_MARK,		PORT98_FN1),
+	PINMUX_DATA(KEYIN3_MARK,		PORT99_FN1),
+	PINMUX_DATA(KEYIN4_MARK,		PORT100_FN1),
+	PINMUX_DATA(KEYIN5_MARK,		PORT101_FN1),
+
+	/* Port102 */
+	PINMUX_DATA(KEYIN6_MARK,		PORT102_FN1),
+	PINMUX_DATA(IRQ41_MARK,			PORT102_FN0),
+
+	/* Port103 */
+	PINMUX_DATA(KEYIN7_MARK,		PORT103_FN1),
+	PINMUX_DATA(IRQ42_MARK,			PORT103_FN0),
+
+	/* Port104 - Port108 */
+	PINMUX_DATA(KEYOUT0_MARK,		PORT104_FN2),
+	PINMUX_DATA(KEYOUT1_MARK,		PORT105_FN2),
+	PINMUX_DATA(KEYOUT2_MARK,		PORT106_FN2),
+	PINMUX_DATA(KEYOUT3_MARK,		PORT107_FN2),
+	PINMUX_DATA(KEYOUT4_MARK,		PORT108_FN2),
+
+	/* Port109 */
+	PINMUX_DATA(KEYOUT5_MARK,		PORT109_FN2),
+	PINMUX_DATA(IRQ43_MARK,			PORT109_FN0),
+
+	/* Port110 */
+	PINMUX_DATA(KEYOUT6_MARK,		PORT110_FN2),
+	PINMUX_DATA(IRQ44_MARK,			PORT110_FN0),
+
+	/* Port111 */
+	PINMUX_DATA(KEYOUT7_MARK,		PORT111_FN2),
+	PINMUX_DATA(RFANAEN_MARK,		PORT111_FN5),
+	PINMUX_DATA(IRQ45_MARK,			PORT111_FN0),
+
+	/* Port112 */
+	PINMUX_DATA(KEYIN8_MARK,		PORT112_FN1),
+	PINMUX_DATA(KEYOUT8_MARK,		PORT112_FN2),
+	PINMUX_DATA(SF_IRQ_04_MARK,		PORT112_FN4),
+	PINMUX_DATA(IRQ46_MARK,			PORT112_FN0),
+
+	/* Port113 */
+	PINMUX_DATA(KEYIN9_MARK,		PORT113_FN1),
+	PINMUX_DATA(KEYOUT9_MARK,		PORT113_FN2),
+	PINMUX_DATA(SF_IRQ_05_MARK,		PORT113_FN4),
+	PINMUX_DATA(IRQ47_MARK,			PORT113_FN0),
+
+	/* Port114 */
+	PINMUX_DATA(KEYIN10_MARK,		PORT114_FN1),
+	PINMUX_DATA(KEYOUT10_MARK,		PORT114_FN2),
+	PINMUX_DATA(SF_IRQ_06_MARK,		PORT114_FN4),
+	PINMUX_DATA(IRQ48_MARK,			PORT114_FN0),
+
+	/* Port115 */
+	PINMUX_DATA(KEYIN11_MARK,		PORT115_FN1),
+	PINMUX_DATA(KEYOUT11_MARK,		PORT115_FN2),
+	PINMUX_DATA(SF_IRQ_07_MARK,		PORT115_FN4),
+	PINMUX_DATA(IRQ49_MARK,			PORT115_FN0),
+
+	/* Port116 */
+	PINMUX_DATA(SCIFA0_TXD_MARK,		PORT116_FN1),
+	PINMUX_DATA(CSCIF0_TX_MARK,		PORT116_FN7),
+
+	/* Port117 */
+	PINMUX_DATA(SCIFA0_RXD_MARK,		PORT117_FN1),
+	PINMUX_DATA(CSCIF0_RX_MARK,		PORT117_FN7),
+
+	/* Port118 */
+	PINMUX_DATA(SCIFA1_TXD_MARK,		PORT118_FN1),
+	PINMUX_DATA(CSCIF1_TX_MARK,		PORT118_FN7),
+
+	/* Port119 */
+	PINMUX_DATA(SCIFA1_RXD_MARK,		PORT119_FN1),
+	PINMUX_DATA(CSCIF1_RX_MARK,		PORT119_FN7),
+
+	/* Port120 */
+	PINMUX_DATA(SF_PORT_1_120_MARK,		PORT120_FN3),
+	PINMUX_DATA(SCIFB3_RXD_120_MARK,	PORT120_FN4,	MSEL3CR_09_1),
+	PINMUX_DATA(DU0_CDE_MARK,		PORT120_FN7),
+
+	/* Port121 */
+	PINMUX_DATA(SF_PORT_0_121_MARK,		PORT121_FN3),
+	PINMUX_DATA(SCIFB3_TXD_121_MARK,	PORT121_FN4,	MSEL3CR_09_1),
+
+	/* Port122 */
+	PINMUX_DATA(SCIFB0_TXD_MARK,		PORT122_FN1),
+	PINMUX_DATA(CHSCIF0_HTX_MARK,		PORT122_FN7),
+
+	/* Port123 */
+	PINMUX_DATA(SCIFB0_RXD_MARK,		PORT123_FN1),
+	PINMUX_DATA(CHSCIF0_HRX_MARK,		PORT123_FN7),
+
+	/* Port124 */
+	PINMUX_DATA(ISP_STROBE_124_MARK,	PORT124_FN3),
+
+	/* Port125 */
+	PINMUX_DATA(STP_ISD_0_MARK,		PORT125_FN1),
+	PINMUX_DATA(PDM4_CLK_125_MARK,		PORT125_FN2),
+	PINMUX_DATA(MSIOF2_TXD_MARK,		PORT125_FN3),
+	PINMUX_DATA(SIM0_VOLTSEL0_MARK,		PORT125_FN5),
+
+	/* Port126 */
+	PINMUX_DATA(TS_SDEN_MARK,		PORT126_FN1),
+	PINMUX_DATA(MSIOF7_SYNC_MARK,		PORT126_FN2),
+	PINMUX_DATA(STP_ISEN_1_MARK,		PORT126_FN3),
+
+	/* Port128 */
+	PINMUX_DATA(STP_ISEN_0_MARK,		PORT128_FN1),
+	PINMUX_DATA(PDM1_OUTDATA_128_MARK,	PORT128_FN2),
+	PINMUX_DATA(MSIOF2_SYNC_MARK,		PORT128_FN3),
+	PINMUX_DATA(SIM1_VOLTSEL1_MARK,		PORT128_FN5),
+
+	/* Port129 */
+	PINMUX_DATA(TS_SPSYNC_MARK,		PORT129_FN1),
+	PINMUX_DATA(MSIOF7_RXD_MARK,		PORT129_FN2),
+	PINMUX_DATA(STP_ISSYNC_1_MARK,		PORT129_FN3),
+
+	/* Port130 */
+	PINMUX_DATA(STP_ISSYNC_0_MARK,		PORT130_FN1),
+	PINMUX_DATA(PDM4_DATA_130_MARK,		PORT130_FN2,	MSEL3CR_12_1),
+	PINMUX_DATA(MSIOF2_RXD_MARK,		PORT130_FN3),
+	PINMUX_DATA(SIM0_VOLTSEL1_MARK,		PORT130_FN5),
+
+	/* Port131 */
+	PINMUX_DATA(STP_OPWM_0_MARK,		PORT131_FN1),
+	PINMUX_DATA(SIM1_PWRON_MARK,		PORT131_FN5),
+
+	/* Port132 */
+	PINMUX_DATA(TS_SCK_MARK,		PORT132_FN1),
+	PINMUX_DATA(MSIOF7_SCK_MARK,		PORT132_FN2),
+	PINMUX_DATA(STP_ISCLK_1_MARK,		PORT132_FN3),
+
+	/* Port133 */
+	PINMUX_DATA(STP_ISCLK_0_MARK,		PORT133_FN1),
+	PINMUX_DATA(PDM1_OUTCLK_133_MARK,	PORT133_FN2),
+	PINMUX_DATA(MSIOF2_SCK_MARK,		PORT133_FN3),
+	PINMUX_DATA(SIM1_VOLTSEL0_MARK,		PORT133_FN5),
+
+	/* Port134 */
+	PINMUX_DATA(TS_SDAT_MARK,		PORT134_FN1),
+	PINMUX_DATA(MSIOF7_TXD_MARK,		PORT134_FN2),
+	PINMUX_DATA(STP_ISD_1_MARK,		PORT134_FN3),
+
+	/* Port160 - Port178 */
+	PINMUX_DATA(IRQ20_MARK,			PORT160_FN0),
+	PINMUX_DATA(IRQ21_MARK,			PORT161_FN0),
+	PINMUX_DATA(IRQ22_MARK,			PORT162_FN0),
+	PINMUX_DATA(IRQ23_MARK,			PORT163_FN0),
+	PINMUX_DATA(MMCD0_0_MARK,		PORT164_FN1),
+	PINMUX_DATA(MMCD0_1_MARK,		PORT165_FN1),
+	PINMUX_DATA(MMCD0_2_MARK,		PORT166_FN1),
+	PINMUX_DATA(MMCD0_3_MARK,		PORT167_FN1),
+	PINMUX_DATA(MMCD0_4_MARK,		PORT168_FN1),
+	PINMUX_DATA(MMCD0_5_MARK,		PORT169_FN1),
+	PINMUX_DATA(MMCD0_6_MARK,		PORT170_FN1),
+	PINMUX_DATA(MMCD0_7_MARK,		PORT171_FN1),
+	PINMUX_DATA(MMCCMD0_MARK,		PORT172_FN1),
+	PINMUX_DATA(MMCCLK0_MARK,		PORT173_FN1),
+	PINMUX_DATA(MMCRST_MARK,		PORT174_FN1),
+	PINMUX_DATA(IRQ24_MARK,			PORT175_FN0),
+	PINMUX_DATA(IRQ25_MARK,			PORT176_FN0),
+	PINMUX_DATA(IRQ26_MARK,			PORT177_FN0),
+	PINMUX_DATA(IRQ27_MARK,			PORT178_FN0),
+
+	/* Port192 - Port200 FN1 */
+	PINMUX_DATA(A10_MARK,		PORT192_FN1),
+	PINMUX_DATA(A9_MARK,		PORT193_FN1),
+	PINMUX_DATA(A8_MARK,		PORT194_FN1),
+	PINMUX_DATA(A7_MARK,		PORT195_FN1),
+	PINMUX_DATA(A6_MARK,		PORT196_FN1),
+	PINMUX_DATA(A5_MARK,		PORT197_FN1),
+	PINMUX_DATA(A4_MARK,		PORT198_FN1),
+	PINMUX_DATA(A3_MARK,		PORT199_FN1),
+	PINMUX_DATA(A2_MARK,		PORT200_FN1),
+
+	/* Port192 - Port200 FN2 */
+	PINMUX_DATA(MMCD1_7_MARK,		PORT192_FN2),
+	PINMUX_DATA(MMCD1_6_MARK,		PORT193_FN2),
+	PINMUX_DATA(MMCD1_5_MARK,		PORT194_FN2),
+	PINMUX_DATA(MMCD1_4_MARK,		PORT195_FN2),
+	PINMUX_DATA(MMCD1_3_MARK,		PORT196_FN2),
+	PINMUX_DATA(MMCD1_2_MARK,		PORT197_FN2),
+	PINMUX_DATA(MMCD1_1_MARK,		PORT198_FN2),
+	PINMUX_DATA(MMCD1_0_MARK,		PORT199_FN2),
+	PINMUX_DATA(MMCCMD1_MARK,		PORT200_FN2),
+
+	/* Port192 - Port200 IRQ */
+	PINMUX_DATA(IRQ31_MARK,			PORT192_FN0),
+	PINMUX_DATA(IRQ32_MARK,			PORT193_FN0),
+	PINMUX_DATA(IRQ33_MARK,			PORT194_FN0),
+	PINMUX_DATA(IRQ34_MARK,			PORT195_FN0),
+	PINMUX_DATA(IRQ35_MARK,			PORT196_FN0),
+	PINMUX_DATA(IRQ36_MARK,			PORT197_FN0),
+	PINMUX_DATA(IRQ37_MARK,			PORT198_FN0),
+	PINMUX_DATA(IRQ38_MARK,			PORT199_FN0),
+	PINMUX_DATA(IRQ39_MARK,			PORT200_FN0),
+
+	/* Port201 */
+	PINMUX_DATA(A1_MARK,		PORT201_FN1),
+
+	/* Port202 */
+	PINMUX_DATA(A0_MARK,		PORT202_FN1),
+	PINMUX_DATA(BS_MARK,		PORT202_FN2),
+
+	/* Port203 */
+	PINMUX_DATA(CKO_MARK,		PORT203_FN1),
+	PINMUX_DATA(MMCCLK1_MARK,	PORT203_FN2),
+
+	/* Port204 */
+	PINMUX_DATA(CS0_N_MARK,		PORT204_FN1),
+	PINMUX_DATA(SIM0_GPO1_MARK,	PORT204_FN5),
+
+	/* Port205 */
+	PINMUX_DATA(CS2_N_MARK,		PORT205_FN1),
+	PINMUX_DATA(SIM0_GPO2_MARK,	PORT205_FN5),
+
+	/* Port206 */
+	PINMUX_DATA(CS4_N_MARK,		PORT206_FN1),
+	PINMUX_DATA(VIO_VD_MARK,	PORT206_FN2),
+	PINMUX_DATA(SIM1_GPO0_MARK,	PORT206_FN5),
+
+	/* Port207 - Port212 FN1 */
+	PINMUX_DATA(D15_MARK,		PORT207_FN1),
+	PINMUX_DATA(D14_MARK,		PORT208_FN1),
+	PINMUX_DATA(D13_MARK,		PORT209_FN1),
+	PINMUX_DATA(D12_MARK,		PORT210_FN1),
+	PINMUX_DATA(D11_MARK,		PORT211_FN1),
+	PINMUX_DATA(D10_MARK,		PORT212_FN1),
+
+	/* Port207 - Port212 FN5 */
+	PINMUX_DATA(GIO_OUT15_MARK,			PORT207_FN5),
+	PINMUX_DATA(GIO_OUT14_MARK,			PORT208_FN5),
+	PINMUX_DATA(GIO_OUT13_MARK,			PORT209_FN5),
+	PINMUX_DATA(GIO_OUT12_MARK,			PORT210_FN5),
+	PINMUX_DATA(WGM_TXP2_MARK,			PORT211_FN5),
+	PINMUX_DATA(WGM_GPS_TIMEM_ASK_RFCLK_MARK,	PORT212_FN5),
+
+	/* Port213 - Port222 FN1 */
+	PINMUX_DATA(D9_MARK,		PORT213_FN1),
+	PINMUX_DATA(D8_MARK,		PORT214_FN1),
+	PINMUX_DATA(D7_MARK,		PORT215_FN1),
+	PINMUX_DATA(D6_MARK,		PORT216_FN1),
+	PINMUX_DATA(D5_MARK,		PORT217_FN1),
+	PINMUX_DATA(D4_MARK,		PORT218_FN1),
+	PINMUX_DATA(D3_MARK,		PORT219_FN1),
+	PINMUX_DATA(D2_MARK,		PORT220_FN1),
+	PINMUX_DATA(D1_MARK,		PORT221_FN1),
+	PINMUX_DATA(D0_MARK,		PORT222_FN1),
+
+	/* Port213 - Port222 FN2 */
+	PINMUX_DATA(VIO_D9_MARK,	PORT213_FN2),
+	PINMUX_DATA(VIO_D8_MARK,	PORT214_FN2),
+	PINMUX_DATA(VIO_D7_MARK,	PORT215_FN2),
+	PINMUX_DATA(VIO_D6_MARK,	PORT216_FN2),
+	PINMUX_DATA(VIO_D5_MARK,	PORT217_FN2),
+	PINMUX_DATA(VIO_D4_MARK,	PORT218_FN2),
+	PINMUX_DATA(VIO_D3_MARK,	PORT219_FN2),
+	PINMUX_DATA(VIO_D2_MARK,	PORT220_FN2),
+	PINMUX_DATA(VIO_D1_MARK,	PORT221_FN2),
+	PINMUX_DATA(VIO_D0_MARK,	PORT222_FN2),
+
+	/* Port213 - Port222 FN5 */
+	PINMUX_DATA(GIO_OUT9_MARK,	PORT213_FN5),
+	PINMUX_DATA(GIO_OUT8_MARK,	PORT214_FN5),
+	PINMUX_DATA(GIO_OUT7_MARK,	PORT215_FN5),
+	PINMUX_DATA(GIO_OUT6_MARK,	PORT216_FN5),
+	PINMUX_DATA(GIO_OUT5_217_MARK,	PORT217_FN5),
+	PINMUX_DATA(GIO_OUT4_218_MARK,	PORT218_FN5),
+	PINMUX_DATA(GIO_OUT3_219_MARK,	PORT219_FN5),
+	PINMUX_DATA(GIO_OUT2_220_MARK,	PORT220_FN5),
+	PINMUX_DATA(GIO_OUT1_221_MARK,	PORT221_FN5),
+	PINMUX_DATA(GIO_OUT0_222_MARK,	PORT222_FN5),
+
+	/* Port224 */
+	PINMUX_DATA(RDWR_224_MARK,	PORT224_FN1),
+	PINMUX_DATA(VIO_HD_MARK,	PORT224_FN2),
+	PINMUX_DATA(SIM1_GPO2_MARK,	PORT224_FN5),
+
+	/* Port225 */
+	PINMUX_DATA(RD_N_MARK,		PORT225_FN1),
+
+	/* Port226 */
+	PINMUX_DATA(WAIT_N_MARK,	PORT226_FN1),
+	PINMUX_DATA(VIO_CLK_MARK,	PORT226_FN2),
+	PINMUX_DATA(SIM1_GPO1_MARK,	PORT226_FN5),
+
+	/* Port227 */
+	PINMUX_DATA(WE0_N_MARK,		PORT227_FN1),
+	PINMUX_DATA(RDWR_227_MARK,	PORT227_FN2),
+
+	/* Port228 */
+	PINMUX_DATA(WE1_N_MARK,		PORT228_FN1),
+	PINMUX_DATA(SIM0_GPO0_MARK,	PORT228_FN5),
+
+	/* Port229 */
+	PINMUX_DATA(PWMO_MARK,		PORT229_FN1),
+	PINMUX_DATA(VIO_CKO1_229_MARK,	PORT229_FN2),
+
+	/* Port230 */
+	PINMUX_DATA(SLIM_CLK_MARK,	PORT230_FN1),
+	PINMUX_DATA(VIO_CKO4_230_MARK,	PORT230_FN2),
+
+	/* Port231 */
+	PINMUX_DATA(SLIM_DATA_MARK,	PORT231_FN1),
+	PINMUX_DATA(VIO_CKO5_231_MARK,	PORT231_FN2),
+
+	/* Port232 */
+	PINMUX_DATA(VIO_CKO2_232_MARK,	PORT232_FN2),
+	PINMUX_DATA(SF_PORT_0_232_MARK,	PORT232_FN4),
+
+	/* Port233 */
+	PINMUX_DATA(VIO_CKO3_233_MARK,	PORT233_FN2),
+	PINMUX_DATA(SF_PORT_1_233_MARK,	PORT233_FN4),
+
+	/* Port234 */
+	PINMUX_DATA(FSIACK_MARK,	PORT234_FN1),
+	PINMUX_DATA(PDM3_CLK_234_MARK,	PORT234_FN2),
+	PINMUX_DATA(ISP_IRIS1_234_MARK,	PORT234_FN3),
+
+	/* Port235 */
+	PINMUX_DATA(FSIAISLD_MARK,	PORT235_FN1),
+	PINMUX_DATA(PDM3_DATA_235_MARK,	PORT235_FN2,	MSEL3CR_12_1),
+
+	/* Port236 */
+	PINMUX_DATA(FSIAOMC_MARK,		PORT236_FN1),
+	PINMUX_DATA(PDM0_OUTCLK_236_MARK,	PORT236_FN2),
+	PINMUX_DATA(ISP_IRIS0_236_MARK,		PORT236_FN3),
+
+	/* Port237 */
+	PINMUX_DATA(FSIAOLR_MARK,	PORT237_FN1),
+	PINMUX_DATA(FSIAILR_MARK,	PORT237_FN2),
+
+	/* Port238 */
+	PINMUX_DATA(FSIAOBT_MARK,	PORT238_FN1),
+	PINMUX_DATA(FSIAIBT_MARK,	PORT238_FN2),
+
+	/* Port239 */
+	PINMUX_DATA(FSIAOSLD_MARK,		PORT239_FN1),
+	PINMUX_DATA(PDM0_OUTDATA_239_MARK,	PORT239_FN2),
+
+	/* Port240 */
+	PINMUX_DATA(FSIBISLD_MARK,	PORT240_FN1),
+
+	/* Port241 */
+	PINMUX_DATA(FSIBOLR_MARK,	PORT241_FN1),
+	PINMUX_DATA(FSIBILR_MARK,	PORT241_FN2),
+
+	/* Port242 */
+	PINMUX_DATA(FSIBOMC_MARK,		PORT242_FN1),
+	PINMUX_DATA(ISP_SHUTTER1_242_MARK,	PORT242_FN3),
+
+	/* Port243 */
+	PINMUX_DATA(FSIBOBT_MARK,	PORT243_FN1),
+	PINMUX_DATA(FSIBIBT_MARK,	PORT243_FN2),
+
+	/* Port244 */
+	PINMUX_DATA(FSIBOSLD_MARK,	PORT244_FN1),
+	PINMUX_DATA(FSIASPDIF_MARK,	PORT244_FN2),
+
+	/* Port245 */
+	PINMUX_DATA(FSIBCK_MARK,		PORT245_FN1),
+	PINMUX_DATA(ISP_SHUTTER0_245_MARK,	PORT245_FN3),
+
+	/* Port246 - Port250 FN1 */
+	PINMUX_DATA(ISP_IRIS1_246_MARK,		PORT246_FN1),
+	PINMUX_DATA(ISP_IRIS0_247_MARK,		PORT247_FN1),
+	PINMUX_DATA(ISP_SHUTTER1_248_MARK,	PORT248_FN1),
+	PINMUX_DATA(ISP_SHUTTER0_249_MARK,	PORT249_FN1),
+	PINMUX_DATA(ISP_STROBE_250_MARK,	PORT250_FN1),
+
+	/* Port256 - Port258 */
+	PINMUX_DATA(MSIOF0_SYNC_MARK,		PORT256_FN1),
+	PINMUX_DATA(MSIOF0_RXD_MARK,		PORT257_FN1),
+	PINMUX_DATA(MSIOF0_SCK_MARK,		PORT258_FN1),
+
+	/* Port259 */
+	PINMUX_DATA(MSIOF0_SS2_MARK,		PORT259_FN1),
+	PINMUX_DATA(VIO_CKO3_259_MARK,		PORT259_FN3),
+
+	/* Port260 */
+	PINMUX_DATA(MSIOF0_TXD_MARK,		PORT260_FN1),
+
+	/* Port261 */
+	PINMUX_DATA(SCIFB1_SCK_261_MARK,	PORT261_FN2),
+	PINMUX_DATA(CHSCIF1_HSCK_MARK,		PORT261_FN7),
+
+	/* Port262 */
+	PINMUX_DATA(SCIFB2_SCK_262_MARK,	PORT262_FN2),
+
+	/* Port263 - Port266 FN1 */
+	PINMUX_DATA(MSIOF1_SS2_MARK,		PORT263_FN1),
+	PINMUX_DATA(MSIOF1_TXD_MARK,		PORT264_FN1),
+	PINMUX_DATA(MSIOF1_RXD_MARK,		PORT265_FN1),
+	PINMUX_DATA(MSIOF1_SS1_MARK,		PORT266_FN1),
+
+	/* Port263 - Port266 FN4 */
+	PINMUX_DATA(MSIOF5_SS2_MARK,		PORT263_FN4),
+	PINMUX_DATA(MSIOF5_TXD_MARK,		PORT264_FN4),
+	PINMUX_DATA(MSIOF5_RXD_MARK,		PORT265_FN4),
+	PINMUX_DATA(MSIOF5_SS1_MARK,		PORT266_FN4),
+
+	/* Port267 */
+	PINMUX_DATA(MSIOF0_SS1_MARK,		PORT267_FN1),
+
+	/* Port268 */
+	PINMUX_DATA(MSIOF1_SCK_MARK,		PORT268_FN1),
+	PINMUX_DATA(MSIOF5_SCK_MARK,		PORT268_FN4),
+
+	/* Port269 */
+	PINMUX_DATA(MSIOF1_SYNC_MARK,		PORT269_FN1),
+	PINMUX_DATA(MSIOF5_SYNC_MARK,		PORT269_FN4),
+
+	/* Port270 - Port273 FN1 */
+	PINMUX_DATA(MSIOF2_SS1_MARK,		PORT270_FN1),
+	PINMUX_DATA(MSIOF2_SS2_MARK,		PORT271_FN1),
+	PINMUX_DATA(MSIOF3_SS2_MARK,		PORT272_FN1),
+	PINMUX_DATA(MSIOF3_SS1_MARK,		PORT273_FN1),
+
+	/* Port270 - Port273 FN3 */
+	PINMUX_DATA(VIO_CKO5_270_MARK,		PORT270_FN3),
+	PINMUX_DATA(VIO_CKO2_271_MARK,		PORT271_FN3),
+	PINMUX_DATA(VIO_CKO1_272_MARK,		PORT272_FN3),
+	PINMUX_DATA(VIO_CKO4_273_MARK,		PORT273_FN3),
+
+	/* Port274 */
+	PINMUX_DATA(MSIOF4_SS2_MARK,		PORT274_FN1),
+	PINMUX_DATA(TPU1TO0_MARK,		PORT274_FN4),
+
+	/* Port275 - Port280 */
+	PINMUX_DATA(IC_DP_MARK,			PORT275_FN1),
+	PINMUX_DATA(SIM0_RST_MARK,		PORT276_FN1),
+	PINMUX_DATA(IC_DM_MARK,			PORT277_FN1),
+	PINMUX_DATA(SIM0_BSICOMP_MARK,		PORT278_FN1),
+	PINMUX_DATA(SIM0_CLK_MARK,		PORT279_FN1),
+	PINMUX_DATA(SIM0_IO_MARK,		PORT280_FN1),
+
+	/* Port281 */
+	PINMUX_DATA(SIM1_IO_MARK,		PORT281_FN1),
+	PINMUX_DATA(PDM2_DATA_281_MARK,		PORT281_FN2,	MSEL3CR_12_1),
+
+	/* Port282 */
+	PINMUX_DATA(SIM1_CLK_MARK,		PORT282_FN1),
+	PINMUX_DATA(PDM2_CLK_282_MARK,		PORT282_FN2),
+
+	/* Port283 */
+	PINMUX_DATA(SIM1_RST_MARK,		PORT283_FN1),
+
+	/* Port289 */
+	PINMUX_DATA(SDHID1_0_MARK,		PORT289_FN1),
+	PINMUX_DATA(STMDATA0_2_MARK,		PORT289_FN3),
+
+	/* Port290 */
+	PINMUX_DATA(SDHID1_1_MARK,		PORT290_FN1),
+	PINMUX_DATA(STMDATA1_2_MARK,		PORT290_FN3),
+	PINMUX_DATA(IRQ51_MARK,			PORT290_FN0),
+
+	/* Port291 - Port294 FN1 */
+	PINMUX_DATA(SDHID1_2_MARK,		PORT291_FN1),
+	PINMUX_DATA(SDHID1_3_MARK,		PORT292_FN1),
+	PINMUX_DATA(SDHICLK1_MARK,		PORT293_FN1),
+	PINMUX_DATA(SDHICMD1_MARK,		PORT294_FN1),
+
+	/* Port291 - Port294 FN3 */
+	PINMUX_DATA(STMDATA2_2_MARK,		PORT291_FN3),
+	PINMUX_DATA(STMDATA3_2_MARK,		PORT292_FN3),
+	PINMUX_DATA(STMCLK_2_MARK,		PORT293_FN3),
+	PINMUX_DATA(STMSIDI_2_MARK,		PORT294_FN3),
+
+	/* Port295 */
+	PINMUX_DATA(SDHID2_0_MARK,		PORT295_FN1),
+	PINMUX_DATA(MSIOF4_TXD_MARK,		PORT295_FN2),
+	PINMUX_DATA(SCIFB2_TXD_295_MARK,	PORT295_FN3,	MSEL3CR_10_1),
+	PINMUX_DATA(MSIOF6_TXD_MARK,		PORT295_FN4),
+
+	/* Port296 */
+	PINMUX_DATA(SDHID2_1_MARK,		PORT296_FN1),
+	PINMUX_DATA(MSIOF6_SS2_MARK,		PORT296_FN4),
+	PINMUX_DATA(IRQ52_MARK,			PORT296_FN0),
+
+	/* Port297 - Port300 FN1 */
+	PINMUX_DATA(SDHID2_2_MARK,		PORT297_FN1),
+	PINMUX_DATA(SDHID2_3_MARK,		PORT298_FN1),
+	PINMUX_DATA(SDHICLK2_MARK,		PORT299_FN1),
+	PINMUX_DATA(SDHICMD2_MARK,		PORT300_FN1),
+
+	/* Port297 - Port300 FN2 */
+	PINMUX_DATA(MSIOF4_RXD_MARK,		PORT297_FN2),
+	PINMUX_DATA(MSIOF4_SYNC_MARK,		PORT298_FN2),
+	PINMUX_DATA(MSIOF4_SCK_MARK,		PORT299_FN2),
+	PINMUX_DATA(MSIOF4_SS1_MARK,		PORT300_FN2),
+
+	/* Port297 - Port300 FN3 */
+	PINMUX_DATA(SCIFB2_RXD_297_MARK,	PORT297_FN3,	MSEL3CR_10_1),
+	PINMUX_DATA(SCIFB2_CTS_298_MARK,	PORT298_FN3,	MSEL3CR_10_1),
+	PINMUX_DATA(SCIFB2_SCK_299_MARK,	PORT299_FN3),
+	PINMUX_DATA(SCIFB2_RTS_300_MARK,	PORT300_FN3),
+
+	/* Port297 - Port300 FN4 */
+	PINMUX_DATA(MSIOF6_RXD_MARK,		PORT297_FN4),
+	PINMUX_DATA(MSIOF6_SYNC_MARK,		PORT298_FN4),
+	PINMUX_DATA(MSIOF6_SCK_MARK,		PORT299_FN4),
+	PINMUX_DATA(MSIOF6_SS1_MARK,		PORT300_FN4),
+
+	/* Port301 */
+	PINMUX_DATA(SDHICD0_MARK,		PORT301_FN1),
+	PINMUX_DATA(IRQ50_MARK,			PORT301_FN0),
+
+	/* Port302 - Port306 FN1 */
+	PINMUX_DATA(SDHID0_0_MARK,		PORT302_FN1),
+	PINMUX_DATA(SDHID0_1_MARK,		PORT303_FN1),
+	PINMUX_DATA(SDHID0_2_MARK,		PORT304_FN1),
+	PINMUX_DATA(SDHID0_3_MARK,		PORT305_FN1),
+	PINMUX_DATA(SDHICMD0_MARK,		PORT306_FN1),
+
+	/* Port302 - Port306 FN3 */
+	PINMUX_DATA(STMDATA0_1_MARK,		PORT302_FN3),
+	PINMUX_DATA(STMDATA1_1_MARK,		PORT303_FN3),
+	PINMUX_DATA(STMDATA2_1_MARK,		PORT304_FN3),
+	PINMUX_DATA(STMDATA3_1_MARK,		PORT305_FN3),
+	PINMUX_DATA(STMSIDI_1_MARK,		PORT306_FN3),
+
+	/* Port307 */
+	PINMUX_DATA(SDHIWP0_MARK,		PORT307_FN1),
+
+	/* Port308 */
+	PINMUX_DATA(SDHICLK0_MARK,		PORT308_FN1),
+	PINMUX_DATA(STMCLK_1_MARK,		PORT308_FN3),
+
+	/* Port320 - Port329 */
+	PINMUX_DATA(IRQ16_MARK,			PORT320_FN0),
+	PINMUX_DATA(IRQ17_MARK,			PORT321_FN0),
+	PINMUX_DATA(IRQ28_MARK,			PORT322_FN0),
+	PINMUX_DATA(IRQ29_MARK,			PORT323_FN0),
+	PINMUX_DATA(IRQ30_MARK,			PORT324_FN0),
+	PINMUX_DATA(IRQ53_MARK,			PORT325_FN0),
+	PINMUX_DATA(IRQ54_MARK,			PORT326_FN0),
+	PINMUX_DATA(IRQ55_MARK,			PORT327_FN0),
+	PINMUX_DATA(IRQ56_MARK,			PORT328_FN0),
+	PINMUX_DATA(IRQ57_MARK,			PORT329_FN0),
+};
+
+static struct sh_pfc_pin pinmux_pins[] = {
+	GPIO_PORT_ALL(),
+};
+
+#define PINMUX_FN_BASE	ARRAY_SIZE(pinmux_pins)
+
+static const struct pinmux_func pinmux_func_gpios[] = {
+	/* Port0 */
+	GPIO_FN(LCDD0),
+	GPIO_FN(PDM2_CLK_0),
+	GPIO_FN(DU0_DR0),
+	GPIO_FN(IRQ0),
+
+	/* Port1 */
+	GPIO_FN(LCDD1),
+	GPIO_FN(PDM2_DATA_1),
+	GPIO_FN(DU0_DR19),
+	GPIO_FN(IRQ1),
+
+	/* Port2 */
+	GPIO_FN(LCDD2),
+	GPIO_FN(PDM3_CLK_2),
+	GPIO_FN(DU0_DR2),
+	GPIO_FN(IRQ2),
+
+	/* Port3 */
+	GPIO_FN(LCDD3),
+	GPIO_FN(PDM3_DATA_3),
+	GPIO_FN(DU0_DR3),
+	GPIO_FN(IRQ3),
+
+	/* Port4 */
+	GPIO_FN(LCDD4),
+	GPIO_FN(PDM4_CLK_4),
+	GPIO_FN(DU0_DR4),
+	GPIO_FN(IRQ4),
+
+	/* Port5 */
+	GPIO_FN(LCDD5),
+	GPIO_FN(PDM4_DATA_5),
+	GPIO_FN(DU0_DR5),
+	GPIO_FN(IRQ5),
+
+	/* Port6 */
+	GPIO_FN(LCDD6),
+	GPIO_FN(PDM0_OUTCLK_6),
+	GPIO_FN(DU0_DR6),
+	GPIO_FN(IRQ6),
+
+	/* Port7 */
+	GPIO_FN(LCDD7),
+	GPIO_FN(PDM0_OUTDATA_7),
+	GPIO_FN(DU0_DR7),
+	GPIO_FN(IRQ7),
+
+	/* Port8 */
+	GPIO_FN(LCDD8),
+	GPIO_FN(PDM1_OUTCLK_8),
+	GPIO_FN(DU0_DG0),
+	GPIO_FN(IRQ8),
+
+	/* Port9 */
+	GPIO_FN(LCDD9),
+	GPIO_FN(PDM1_OUTDATA_9),
+	GPIO_FN(DU0_DG1),
+	GPIO_FN(IRQ9),
+
+	/* Port10 */
+	GPIO_FN(LCDD10),
+	GPIO_FN(FSICCK),
+	GPIO_FN(DU0_DG2),
+	GPIO_FN(IRQ10),
+
+	/* Port11 */
+	GPIO_FN(LCDD11),
+	GPIO_FN(FSICISLD),
+	GPIO_FN(DU0_DG3),
+	GPIO_FN(IRQ11),
+
+	/* Port12 */
+	GPIO_FN(LCDD12),
+	GPIO_FN(FSICOMC),
+	GPIO_FN(DU0_DG4),
+	GPIO_FN(IRQ12),
+
+	/* Port13 */
+	GPIO_FN(LCDD13),
+	GPIO_FN(FSICOLR),
+	GPIO_FN(FSICILR),
+	GPIO_FN(DU0_DG5),
+	GPIO_FN(IRQ13),
+
+	/* Port14 */
+	GPIO_FN(LCDD14),
+	GPIO_FN(FSICOBT),
+	GPIO_FN(FSICIBT),
+	GPIO_FN(DU0_DG6),
+	GPIO_FN(IRQ14),
+
+	/* Port15 */
+	GPIO_FN(LCDD15),
+	GPIO_FN(FSICOSLD),
+	GPIO_FN(DU0_DG7),
+	GPIO_FN(IRQ15),
+
+	/* Port16 */
+	GPIO_FN(LCDD16),
+	GPIO_FN(TPU1TO1),
+	GPIO_FN(DU0_DB0),
+
+	/* Port17 */
+	GPIO_FN(LCDD17),
+	GPIO_FN(SF_IRQ_00),
+	GPIO_FN(DU0_DB1),
+
+	/* Port18 */
+	GPIO_FN(LCDD18),
+	GPIO_FN(SF_IRQ_01),
+	GPIO_FN(DU0_DB2),
+
+	/* Port19 */
+	GPIO_FN(LCDD19),
+	GPIO_FN(SCIFB3_RTS_19),
+	GPIO_FN(DU0_DB3),
+
+	/* Port20 */
+	GPIO_FN(LCDD20),
+	GPIO_FN(SCIFB3_CTS_20),
+	GPIO_FN(DU0_DB4),
+
+	/* Port21 */
+	GPIO_FN(LCDD21),
+	GPIO_FN(SCIFB3_TXD_21),
+	GPIO_FN(DU0_DB5),
+
+	/* Port22 */
+	GPIO_FN(LCDD22),
+	GPIO_FN(SCIFB3_RXD_22),
+	GPIO_FN(DU0_DB6),
+
+	/* Port23 */
+	GPIO_FN(LCDD23),
+	GPIO_FN(SCIFB3_SCK_23),
+	GPIO_FN(DU0_DB7),
+
+	/* Port24 */
+	GPIO_FN(LCDHSYN),
+	GPIO_FN(LCDCS),
+	GPIO_FN(SCIFB1_RTS_24),
+	GPIO_FN(DU0_EXHSYNC_N_CSYNC_N_HSYNC_N),
+
+	/* Port25 */
+	GPIO_FN(LCDVSYN),
+	GPIO_FN(SCIFB1_CTS_25),
+	GPIO_FN(DU0_EXVSYNC_N_VSYNC_N_CSYNC_N),
+
+	/* Port26 */
+	GPIO_FN(LCDDCK),
+	GPIO_FN(LCDWR),
+	GPIO_FN(SCIFB1_TXD_26),
+	GPIO_FN(DU0_DOTCLKIN),
+
+	/* Port27 */
+	GPIO_FN(LCDDISP),
+	GPIO_FN(LCDRS),
+	GPIO_FN(SCIFB1_RXD_27),
+	GPIO_FN(DU0_DOTCLKOUT),
+
+	/* Port28 */
+	GPIO_FN(LCDRD_N),
+	GPIO_FN(SCIFB1_SCK_28),
+	GPIO_FN(DU0_DOTCLKOUTB),
+
+	/* Port29 */
+	GPIO_FN(LCDLCLK),
+	GPIO_FN(SF_IRQ_02),
+	GPIO_FN(DU0_DISP_CSYNC_N_DE),
+
+	/* Port30 */
+	GPIO_FN(LCDDON),
+	GPIO_FN(SF_IRQ_03),
+	GPIO_FN(DU0_ODDF_N_CLAMP),
+
+	/* Port32 */
+	GPIO_FN(SCIFA0_RTS),
+	GPIO_FN(SIM0_DET),
+	GPIO_FN(CSCIF0_RTS),
+
+	/* Port33 */
+	GPIO_FN(SCIFA0_CTS),
+	GPIO_FN(SIM1_DET),
+	GPIO_FN(CSCIF0_CTS),
+
+	/* Port34 */
+	GPIO_FN(SCIFA0_SCK),
+	GPIO_FN(SIM0_PWRON),
+	GPIO_FN(CSCIF0_SCK),
+
+	/* Port35 */
+	GPIO_FN(SCIFA1_RTS),
+	GPIO_FN(CSCIF1_RTS),
+
+	/* Port36 */
+	GPIO_FN(SCIFA1_CTS),
+	GPIO_FN(CSCIF1_CTS),
+
+	/* Port37 */
+	GPIO_FN(SCIFA1_SCK),
+	GPIO_FN(CSCIF1_SCK),
+
+	/* Port38 */
+	GPIO_FN(SCIFB0_RTS),
+	GPIO_FN(TPU0TO1),
+	GPIO_FN(SCIFB3_RTS_38),
+	GPIO_FN(CHSCIF0_HRTS),
+
+	/* Port39 */
+	GPIO_FN(SCIFB0_CTS),
+	GPIO_FN(TPU0TO2),
+	GPIO_FN(SCIFB3_CTS_39),
+	GPIO_FN(CHSCIF0_HCTS),
+
+	/* Port40 */
+	GPIO_FN(SCIFB0_SCK),
+	GPIO_FN(TPU0TO3),
+	GPIO_FN(SCIFB3_SCK_40),
+	GPIO_FN(CHSCIF0_HSCK),
+
+	/* Port64 */
+	GPIO_FN(PDM0_DATA),
+
+	/* Port65 */
+	GPIO_FN(PDM1_DATA),
+
+	/* Port66 */
+	GPIO_FN(HSI_RX_WAKE),
+	GPIO_FN(SCIFB2_CTS_66),
+	GPIO_FN(MSIOF3_SYNC),
+	GPIO_FN(GenIO4),
+	GPIO_FN(IRQ40),
+
+	/* Port67 */
+	GPIO_FN(HSI_RX_READY),
+	GPIO_FN(SCIFB1_TXD_67),
+	GPIO_FN(GIO_OUT3_67),
+	GPIO_FN(CHSCIF1_HTX),
+
+	/* Port68 */
+	GPIO_FN(HSI_RX_FLAG),
+	GPIO_FN(SCIFB2_TXD_68),
+	GPIO_FN(MSIOF3_TXD),
+	GPIO_FN(GIO_OUT4_68),
+
+	/* Port69 */
+	GPIO_FN(HSI_RX_DATA),
+	GPIO_FN(SCIFB2_RXD_69),
+	GPIO_FN(MSIOF3_RXD),
+	GPIO_FN(GIO_OUT5_69),
+
+	/* Port70 */
+	GPIO_FN(HSI_TX_FLAG),
+	GPIO_FN(SCIFB1_RTS_70),
+	GPIO_FN(GIO_OUT1_70),
+	GPIO_FN(HSIC_TSTCLK0),
+	GPIO_FN(CHSCIF1_HRTS),
+
+	/* Port71 */
+	GPIO_FN(HSI_TX_DATA),
+	GPIO_FN(SCIFB1_CTS_71),
+	GPIO_FN(GIO_OUT2_71),
+	GPIO_FN(HSIC_TSTCLK1),
+	GPIO_FN(CHSCIF1_HCTS),
+
+	/* Port72 */
+	GPIO_FN(HSI_TX_WAKE),
+	GPIO_FN(SCIFB1_RXD_72),
+	GPIO_FN(GenIO8),
+	GPIO_FN(CHSCIF1_HRX),
+
+	/* Port73 */
+	GPIO_FN(HSI_TX_READY),
+	GPIO_FN(SCIFB2_RTS_73),
+	GPIO_FN(MSIOF3_SCK),
+	GPIO_FN(GIO_OUT0_73),
+
+	/* Port74 - Port85 */
+	GPIO_FN(IRDA_OUT),
+	GPIO_FN(IRDA_IN),
+	GPIO_FN(IRDA_FIRSEL),
+	GPIO_FN(TPU0TO0),
+	GPIO_FN(DIGRFEN),
+	GPIO_FN(GPS_TIMESTAMP),
+	GPIO_FN(TXP),
+	GPIO_FN(TXP2),
+	GPIO_FN(COEX_0),
+	GPIO_FN(COEX_1),
+	GPIO_FN(IRQ19),
+	GPIO_FN(IRQ18),
+
+	/* Port96 - Port101 */
+	GPIO_FN(KEYIN0),
+	GPIO_FN(KEYIN1),
+	GPIO_FN(KEYIN2),
+	GPIO_FN(KEYIN3),
+	GPIO_FN(KEYIN4),
+	GPIO_FN(KEYIN5),
+
+	/* Port102 */
+	GPIO_FN(KEYIN6),
+	GPIO_FN(IRQ41),
+
+	/* Port103 */
+	GPIO_FN(KEYIN7),
+	GPIO_FN(IRQ42),
+
+	/* Port104 - Port108 */
+	GPIO_FN(KEYOUT0),
+	GPIO_FN(KEYOUT1),
+	GPIO_FN(KEYOUT2),
+	GPIO_FN(KEYOUT3),
+	GPIO_FN(KEYOUT4),
+
+	/* Port109 */
+	GPIO_FN(KEYOUT5),
+	GPIO_FN(IRQ43),
+
+	/* Port110 */
+	GPIO_FN(KEYOUT6),
+	GPIO_FN(IRQ44),
+
+	/* Port111 */
+	GPIO_FN(KEYOUT7),
+	GPIO_FN(RFANAEN),
+	GPIO_FN(IRQ45),
+
+	/* Port112 */
+	GPIO_FN(KEYIN8),
+	GPIO_FN(KEYOUT8),
+	GPIO_FN(SF_IRQ_04),
+	GPIO_FN(IRQ46),
+
+	/* Port113 */
+	GPIO_FN(KEYIN9),
+	GPIO_FN(KEYOUT9),
+	GPIO_FN(SF_IRQ_05),
+	GPIO_FN(IRQ47),
+
+	/* Port114 */
+	GPIO_FN(KEYIN10),
+	GPIO_FN(KEYOUT10),
+	GPIO_FN(SF_IRQ_06),
+	GPIO_FN(IRQ48),
+
+	/* Port115 */
+	GPIO_FN(KEYIN11),
+	GPIO_FN(KEYOUT11),
+	GPIO_FN(SF_IRQ_07),
+	GPIO_FN(IRQ49),
+
+	/* Port116 */
+	GPIO_FN(SCIFA0_TXD),
+	GPIO_FN(CSCIF0_TX),
+
+	/* Port117 */
+	GPIO_FN(SCIFA0_RXD),
+	GPIO_FN(CSCIF0_RX),
+
+	/* Port118 */
+	GPIO_FN(SCIFA1_TXD),
+	GPIO_FN(CSCIF1_TX),
+
+	/* Port119 */
+	GPIO_FN(SCIFA1_RXD),
+	GPIO_FN(CSCIF1_RX),
+
+	/* Port120 */
+	GPIO_FN(SF_PORT_1_120),
+	GPIO_FN(SCIFB3_RXD_120),
+	GPIO_FN(DU0_CDE),
+
+	/* Port121 */
+	GPIO_FN(SF_PORT_0_121),
+	GPIO_FN(SCIFB3_TXD_121),
+
+	/* Port122 */
+	GPIO_FN(SCIFB0_TXD),
+	GPIO_FN(CHSCIF0_HTX),
+
+	/* Port123 */
+	GPIO_FN(SCIFB0_RXD),
+	GPIO_FN(CHSCIF0_HRX),
+
+	/* Port124 */
+	GPIO_FN(ISP_STROBE_124),
+
+	/* Port125 */
+	GPIO_FN(STP_ISD_0),
+	GPIO_FN(PDM4_CLK_125),
+	GPIO_FN(MSIOF2_TXD),
+	GPIO_FN(SIM0_VOLTSEL0),
+
+	/* Port126 */
+	GPIO_FN(TS_SDEN),
+	GPIO_FN(MSIOF7_SYNC),
+	GPIO_FN(STP_ISEN_1),
+
+	/* Port128 */
+	GPIO_FN(STP_ISEN_0),
+	GPIO_FN(PDM1_OUTDATA_128),
+	GPIO_FN(MSIOF2_SYNC),
+	GPIO_FN(SIM1_VOLTSEL1),
+
+	/* Port129 */
+	GPIO_FN(TS_SPSYNC),
+	GPIO_FN(MSIOF7_RXD),
+	GPIO_FN(STP_ISSYNC_1),
+
+	/* Port130 */
+	GPIO_FN(STP_ISSYNC_0),
+	GPIO_FN(PDM4_DATA_130),
+	GPIO_FN(MSIOF2_RXD),
+	GPIO_FN(SIM0_VOLTSEL1),
+
+	/* Port131 */
+	GPIO_FN(STP_OPWM_0),
+	GPIO_FN(SIM1_PWRON),
+
+	/* Port132 */
+	GPIO_FN(TS_SCK),
+	GPIO_FN(MSIOF7_SCK),
+	GPIO_FN(STP_ISCLK_1),
+
+	/* Port133 */
+	GPIO_FN(STP_ISCLK_0),
+	GPIO_FN(PDM1_OUTCLK_133),
+	GPIO_FN(MSIOF2_SCK),
+	GPIO_FN(SIM1_VOLTSEL0),
+
+	/* Port134 */
+	GPIO_FN(TS_SDAT),
+	GPIO_FN(MSIOF7_TXD),
+	GPIO_FN(STP_ISD_1),
+
+	/* Port160 - Port178 */
+	GPIO_FN(IRQ20),
+	GPIO_FN(IRQ21),
+	GPIO_FN(IRQ22),
+	GPIO_FN(IRQ23),
+	GPIO_FN(MMCD0_0),
+	GPIO_FN(MMCD0_1),
+	GPIO_FN(MMCD0_2),
+	GPIO_FN(MMCD0_3),
+	GPIO_FN(MMCD0_4),
+	GPIO_FN(MMCD0_5),
+	GPIO_FN(MMCD0_6),
+	GPIO_FN(MMCD0_7),
+	GPIO_FN(MMCCMD0),
+	GPIO_FN(MMCCLK0),
+	GPIO_FN(MMCRST),
+	GPIO_FN(IRQ24),
+	GPIO_FN(IRQ25),
+	GPIO_FN(IRQ26),
+	GPIO_FN(IRQ27),
+
+	/* Port192 - Port200 FN1 */
+	GPIO_FN(A10),
+	GPIO_FN(A9),
+	GPIO_FN(A8),
+	GPIO_FN(A7),
+	GPIO_FN(A6),
+	GPIO_FN(A5),
+	GPIO_FN(A4),
+	GPIO_FN(A3),
+	GPIO_FN(A2),
+
+	/* Port192 - Port200 FN2 */
+	GPIO_FN(MMCD1_7),
+	GPIO_FN(MMCD1_6),
+	GPIO_FN(MMCD1_5),
+	GPIO_FN(MMCD1_4),
+	GPIO_FN(MMCD1_3),
+	GPIO_FN(MMCD1_2),
+	GPIO_FN(MMCD1_1),
+	GPIO_FN(MMCD1_0),
+	GPIO_FN(MMCCMD1),
+
+	/* Port192 - Port200 IRQ */
+	GPIO_FN(IRQ31),
+	GPIO_FN(IRQ32),
+	GPIO_FN(IRQ33),
+	GPIO_FN(IRQ34),
+	GPIO_FN(IRQ35),
+	GPIO_FN(IRQ36),
+	GPIO_FN(IRQ37),
+	GPIO_FN(IRQ38),
+	GPIO_FN(IRQ39),
+
+	/* Port201 */
+	GPIO_FN(A1),
+
+	/* Port202 */
+	GPIO_FN(A0),
+	GPIO_FN(BS),
+
+	/* Port203 */
+	GPIO_FN(CKO),
+	GPIO_FN(MMCCLK1),
+
+	/* Port204 */
+	GPIO_FN(CS0_N),
+	GPIO_FN(SIM0_GPO1),
+
+	/* Port205 */
+	GPIO_FN(CS2_N),
+	GPIO_FN(SIM0_GPO2),
+
+	/* Port206 */
+	GPIO_FN(CS4_N),
+	GPIO_FN(VIO_VD),
+	GPIO_FN(SIM1_GPO0),
+
+	/* Port207 - Port212 FN1 */
+	GPIO_FN(D15),
+	GPIO_FN(D14),
+	GPIO_FN(D13),
+	GPIO_FN(D12),
+	GPIO_FN(D11),
+	GPIO_FN(D10),
+
+	/* Port207 - Port212 FN5 */
+	GPIO_FN(GIO_OUT15),
+	GPIO_FN(GIO_OUT14),
+	GPIO_FN(GIO_OUT13),
+	GPIO_FN(GIO_OUT12),
+	GPIO_FN(WGM_TXP2),
+	GPIO_FN(WGM_GPS_TIMEM_ASK_RFCLK),
+
+	/* Port213 - Port222 FN1 */
+	GPIO_FN(D9),
+	GPIO_FN(D8),
+	GPIO_FN(D7),
+	GPIO_FN(D6),
+	GPIO_FN(D5),
+	GPIO_FN(D4),
+	GPIO_FN(D3),
+	GPIO_FN(D2),
+	GPIO_FN(D1),
+	GPIO_FN(D0),
+
+	/* Port213 - Port222 FN2 */
+	GPIO_FN(VIO_D9),
+	GPIO_FN(VIO_D8),
+	GPIO_FN(VIO_D7),
+	GPIO_FN(VIO_D6),
+	GPIO_FN(VIO_D5),
+	GPIO_FN(VIO_D4),
+	GPIO_FN(VIO_D3),
+	GPIO_FN(VIO_D2),
+	GPIO_FN(VIO_D1),
+	GPIO_FN(VIO_D0),
+
+	/* Port213 - Port222 FN5 */
+	GPIO_FN(GIO_OUT9),
+	GPIO_FN(GIO_OUT8),
+	GPIO_FN(GIO_OUT7),
+	GPIO_FN(GIO_OUT6),
+	GPIO_FN(GIO_OUT5_217),
+	GPIO_FN(GIO_OUT4_218),
+	GPIO_FN(GIO_OUT3_219),
+	GPIO_FN(GIO_OUT2_220),
+	GPIO_FN(GIO_OUT1_221),
+	GPIO_FN(GIO_OUT0_222),
+
+	/* Port224 */
+	GPIO_FN(RDWR_224),
+	GPIO_FN(VIO_HD),
+	GPIO_FN(SIM1_GPO2),
+
+	/* Port225 */
+	GPIO_FN(RD_N),
+
+	/* Port226 */
+	GPIO_FN(WAIT_N),
+	GPIO_FN(VIO_CLK),
+	GPIO_FN(SIM1_GPO1),
+
+	/* Port227 */
+	GPIO_FN(WE0_N),
+	GPIO_FN(RDWR_227),
+
+	/* Port228 */
+	GPIO_FN(WE1_N),
+	GPIO_FN(SIM0_GPO0),
+
+	/* Port229 */
+	GPIO_FN(PWMO),
+	GPIO_FN(VIO_CKO1_229),
+
+	/* Port230 */
+	GPIO_FN(SLIM_CLK),
+	GPIO_FN(VIO_CKO4_230),
+
+	/* Port231 */
+	GPIO_FN(SLIM_DATA),
+	GPIO_FN(VIO_CKO5_231),
+
+	/* Port232 */
+	GPIO_FN(VIO_CKO2_232),
+	GPIO_FN(SF_PORT_0_232),
+
+	/* Port233 */
+	GPIO_FN(VIO_CKO3_233),
+	GPIO_FN(SF_PORT_1_233),
+
+	/* Port234 */
+	GPIO_FN(FSIACK),
+	GPIO_FN(PDM3_CLK_234),
+	GPIO_FN(ISP_IRIS1_234),
+
+	/* Port235 */
+	GPIO_FN(FSIAISLD),
+	GPIO_FN(PDM3_DATA_235),
+
+	/* Port236 */
+	GPIO_FN(FSIAOMC),
+	GPIO_FN(PDM0_OUTCLK_236),
+	GPIO_FN(ISP_IRIS0_236),
+
+	/* Port237 */
+	GPIO_FN(FSIAOLR),
+	GPIO_FN(FSIAILR),
+
+	/* Port238 */
+	GPIO_FN(FSIAOBT),
+	GPIO_FN(FSIAIBT),
+
+	/* Port239 */
+	GPIO_FN(FSIAOSLD),
+	GPIO_FN(PDM0_OUTDATA_239),
+
+	/* Port240 */
+	GPIO_FN(FSIBISLD),
+
+	/* Port241 */
+	GPIO_FN(FSIBOLR),
+	GPIO_FN(FSIBILR),
+
+	/* Port242 */
+	GPIO_FN(FSIBOMC),
+	GPIO_FN(ISP_SHUTTER1_242),
+
+	/* Port243 */
+	GPIO_FN(FSIBOBT),
+	GPIO_FN(FSIBIBT),
+
+	/* Port244 */
+	GPIO_FN(FSIBOSLD),
+	GPIO_FN(FSIASPDIF),
+
+	/* Port245 */
+	GPIO_FN(FSIBCK),
+	GPIO_FN(ISP_SHUTTER0_245),
+
+	/* Port246 - Port250 FN1 */
+	GPIO_FN(ISP_IRIS1_246),
+	GPIO_FN(ISP_IRIS0_247),
+	GPIO_FN(ISP_SHUTTER1_248),
+	GPIO_FN(ISP_SHUTTER0_249),
+	GPIO_FN(ISP_STROBE_250),
+
+	/* Port256 - Port258 */
+	GPIO_FN(MSIOF0_SYNC),
+	GPIO_FN(MSIOF0_RXD),
+	GPIO_FN(MSIOF0_SCK),
+
+	/* Port259 */
+	GPIO_FN(MSIOF0_SS2),
+	GPIO_FN(VIO_CKO3_259),
+
+	/* Port260 */
+	GPIO_FN(MSIOF0_TXD),
+
+	/* Port261 */
+	GPIO_FN(SCIFB1_SCK_261),
+	GPIO_FN(CHSCIF1_HSCK),
+
+	/* Port262 */
+	GPIO_FN(SCIFB2_SCK_262),
+
+	/* Port263 - Port266 FN1 */
+	GPIO_FN(MSIOF1_SS2),
+	GPIO_FN(MSIOF1_TXD),
+	GPIO_FN(MSIOF1_RXD),
+	GPIO_FN(MSIOF1_SS1),
+
+	/* Port263 - Port266 FN4 */
+	GPIO_FN(MSIOF5_SS2),
+	GPIO_FN(MSIOF5_TXD),
+	GPIO_FN(MSIOF5_RXD),
+	GPIO_FN(MSIOF5_SS1),
+
+	/* Port267 */
+	GPIO_FN(MSIOF0_SS1),
+
+	/* Port268 */
+	GPIO_FN(MSIOF1_SCK),
+	GPIO_FN(MSIOF5_SCK),
+
+	/* Port269 */
+	GPIO_FN(MSIOF1_SYNC),
+	GPIO_FN(MSIOF5_SYNC),
+
+	/* Port270 - Port273 FN1 */
+	GPIO_FN(MSIOF2_SS1),
+	GPIO_FN(MSIOF2_SS2),
+	GPIO_FN(MSIOF3_SS2),
+	GPIO_FN(MSIOF3_SS1),
+
+	/* Port270 - Port273 FN3 */
+	GPIO_FN(VIO_CKO5_270),
+	GPIO_FN(VIO_CKO2_271),
+	GPIO_FN(VIO_CKO1_272),
+	GPIO_FN(VIO_CKO4_273),
+
+	/* Port274 */
+	GPIO_FN(MSIOF4_SS2),
+	GPIO_FN(TPU1TO0),
+
+	/* Port275 - Port280 */
+	GPIO_FN(IC_DP),
+	GPIO_FN(SIM0_RST),
+	GPIO_FN(IC_DM),
+	GPIO_FN(SIM0_BSICOMP),
+	GPIO_FN(SIM0_CLK),
+	GPIO_FN(SIM0_IO),
+
+	/* Port281 */
+	GPIO_FN(SIM1_IO),
+	GPIO_FN(PDM2_DATA_281),
+
+	/* Port282 */
+	GPIO_FN(SIM1_CLK),
+	GPIO_FN(PDM2_CLK_282),
+
+	/* Port283 */
+	GPIO_FN(SIM1_RST),
+
+	/* Port289 */
+	GPIO_FN(SDHID1_0),
+	GPIO_FN(STMDATA0_2),
+
+	/* Port290 */
+	GPIO_FN(SDHID1_1),
+	GPIO_FN(STMDATA1_2),
+	GPIO_FN(IRQ51),
+
+	/* Port291 - Port294 FN1 */
+	GPIO_FN(SDHID1_2),
+	GPIO_FN(SDHID1_3),
+	GPIO_FN(SDHICLK1),
+	GPIO_FN(SDHICMD1),
+
+	/* Port291 - Port294 FN3 */
+	GPIO_FN(STMDATA2_2),
+	GPIO_FN(STMDATA3_2),
+	GPIO_FN(STMCLK_2),
+	GPIO_FN(STMSIDI_2),
+
+	/* Port295 */
+	GPIO_FN(SDHID2_0),
+	GPIO_FN(MSIOF4_TXD),
+	GPIO_FN(SCIFB2_TXD_295),
+	GPIO_FN(MSIOF6_TXD),
+
+	/* Port296 */
+	GPIO_FN(SDHID2_1),
+	GPIO_FN(MSIOF6_SS2),
+	GPIO_FN(IRQ52),
+
+	/* Port297 - Port300 FN1 */
+	GPIO_FN(SDHID2_2),
+	GPIO_FN(SDHID2_3),
+	GPIO_FN(SDHICLK2),
+	GPIO_FN(SDHICMD2),
+
+	/* Port297 - Port300 FN2 */
+	GPIO_FN(MSIOF4_RXD),
+	GPIO_FN(MSIOF4_SYNC),
+	GPIO_FN(MSIOF4_SCK),
+	GPIO_FN(MSIOF4_SS1),
+
+	/* Port297 - Port300 FN3 */
+	GPIO_FN(SCIFB2_RXD_297),
+	GPIO_FN(SCIFB2_CTS_298),
+	GPIO_FN(SCIFB2_SCK_299),
+	GPIO_FN(SCIFB2_RTS_300),
+
+	/* Port297 - Port300 FN4 */
+	GPIO_FN(MSIOF6_RXD),
+	GPIO_FN(MSIOF6_SYNC),
+	GPIO_FN(MSIOF6_SCK),
+	GPIO_FN(MSIOF6_SS1),
+
+	/* Port301 */
+	GPIO_FN(SDHICD0),
+	GPIO_FN(IRQ50),
+
+	/* Port302 - Port306 FN1 */
+	GPIO_FN(SDHID0_0),
+	GPIO_FN(SDHID0_1),
+	GPIO_FN(SDHID0_2),
+	GPIO_FN(SDHID0_3),
+	GPIO_FN(SDHICMD0),
+
+	/* Port302 - Port306 FN3 */
+	GPIO_FN(STMDATA0_1),
+	GPIO_FN(STMDATA1_1),
+	GPIO_FN(STMDATA2_1),
+	GPIO_FN(STMDATA3_1),
+	GPIO_FN(STMSIDI_1),
+
+	/* Port307 */
+	GPIO_FN(SDHIWP0),
+
+	/* Port308 */
+	GPIO_FN(SDHICLK0),
+	GPIO_FN(STMCLK_1),
+
+	/* Port320 - Port329 */
+	GPIO_FN(IRQ16),
+	GPIO_FN(IRQ17),
+	GPIO_FN(IRQ28),
+	GPIO_FN(IRQ29),
+	GPIO_FN(IRQ30),
+	GPIO_FN(IRQ53),
+	GPIO_FN(IRQ54),
+	GPIO_FN(IRQ55),
+	GPIO_FN(IRQ56),
+	GPIO_FN(IRQ57),
+};
+
+static const struct pinmux_cfg_reg pinmux_config_regs[] = {
+
+	PORTCR(0, 0xe6050000),
+	PORTCR(1, 0xe6050001),
+	PORTCR(2, 0xe6050002),
+	PORTCR(3, 0xe6050003),
+	PORTCR(4, 0xe6050004),
+	PORTCR(5, 0xe6050005),
+	PORTCR(6, 0xe6050006),
+	PORTCR(7, 0xe6050007),
+	PORTCR(8, 0xe6050008),
+	PORTCR(9, 0xe6050009),
+	PORTCR(10, 0xe605000A),
+	PORTCR(11, 0xe605000B),
+	PORTCR(12, 0xe605000C),
+	PORTCR(13, 0xe605000D),
+	PORTCR(14, 0xe605000E),
+	PORTCR(15, 0xe605000F),
+	PORTCR(16, 0xe6050010),
+	PORTCR(17, 0xe6050011),
+	PORTCR(18, 0xe6050012),
+	PORTCR(19, 0xe6050013),
+	PORTCR(20, 0xe6050014),
+	PORTCR(21, 0xe6050015),
+	PORTCR(22, 0xe6050016),
+	PORTCR(23, 0xe6050017),
+	PORTCR(24, 0xe6050018),
+	PORTCR(25, 0xe6050019),
+	PORTCR(26, 0xe605001A),
+	PORTCR(27, 0xe605001B),
+	PORTCR(28, 0xe605001C),
+	PORTCR(29, 0xe605001D),
+	PORTCR(30, 0xe605001E),
+	PORTCR(32, 0xe6051020),
+	PORTCR(33, 0xe6051021),
+	PORTCR(34, 0xe6051022),
+	PORTCR(35, 0xe6051023),
+	PORTCR(36, 0xe6051024),
+	PORTCR(37, 0xe6051025),
+	PORTCR(38, 0xe6051026),
+	PORTCR(39, 0xe6051027),
+	PORTCR(40, 0xe6051028),
+	PORTCR(64, 0xe6050040),
+	PORTCR(65, 0xe6050041),
+	PORTCR(66, 0xe6050042),
+	PORTCR(67, 0xe6050043),
+	PORTCR(68, 0xe6050044),
+	PORTCR(69, 0xe6050045),
+	PORTCR(70, 0xe6050046),
+	PORTCR(71, 0xe6050047),
+	PORTCR(72, 0xe6050048),
+	PORTCR(73, 0xe6050049),
+	PORTCR(74, 0xe605004A),
+	PORTCR(75, 0xe605004B),
+	PORTCR(76, 0xe605004C),
+	PORTCR(77, 0xe605004D),
+	PORTCR(78, 0xe605004E),
+	PORTCR(79, 0xe605004F),
+	PORTCR(80, 0xe6050050),
+	PORTCR(81, 0xe6050051),
+	PORTCR(82, 0xe6050052),
+	PORTCR(83, 0xe6050053),
+	PORTCR(84, 0xe6050054),
+	PORTCR(85, 0xe6050055),
+	PORTCR(96, 0xe6051060),
+	PORTCR(97, 0xe6051061),
+	PORTCR(98, 0xe6051062),
+	PORTCR(99, 0xe6051063),
+	PORTCR(100, 0xe6051064),
+	PORTCR(101, 0xe6051065),
+	PORTCR(102, 0xe6051066),
+	PORTCR(103, 0xe6051067),
+	PORTCR(104, 0xe6051068),
+	PORTCR(105, 0xe6051069),
+	PORTCR(106, 0xe605106A),
+	PORTCR(107, 0xe605106B),
+	PORTCR(108, 0xe605106C),
+	PORTCR(109, 0xe605106D),
+	PORTCR(110, 0xe605106E),
+	PORTCR(111, 0xe605106F),
+	PORTCR(112, 0xe6051070),
+	PORTCR(113, 0xe6051071),
+	PORTCR(114, 0xe6051072),
+	PORTCR(115, 0xe6051073),
+	PORTCR(116, 0xe6051074),
+	PORTCR(117, 0xe6051075),
+	PORTCR(118, 0xe6051076),
+	PORTCR(119, 0xe6051077),
+	PORTCR(120, 0xe6051078),
+	PORTCR(121, 0xe6051079),
+	PORTCR(122, 0xe605107A),
+	PORTCR(123, 0xe605107B),
+	PORTCR(124, 0xe605107C),
+	PORTCR(125, 0xe605107D),
+	PORTCR(126, 0xe605107E),
+	PORTCR(128, 0xe6051080),
+	PORTCR(129, 0xe6051081),
+	PORTCR(130, 0xe6051082),
+	PORTCR(131, 0xe6051083),
+	PORTCR(132, 0xe6051084),
+	PORTCR(133, 0xe6051085),
+	PORTCR(134, 0xe6051086),
+	PORTCR(160, 0xe60520A0),
+	PORTCR(161, 0xe60520A1),
+	PORTCR(162, 0xe60520A2),
+	PORTCR(163, 0xe60520A3),
+	PORTCR(164, 0xe60520A4),
+	PORTCR(165, 0xe60520A5),
+	PORTCR(166, 0xe60520A6),
+	PORTCR(167, 0xe60520A7),
+	PORTCR(168, 0xe60520A8),
+	PORTCR(169, 0xe60520A9),
+	PORTCR(170, 0xe60520AA),
+	PORTCR(171, 0xe60520AB),
+	PORTCR(172, 0xe60520AC),
+	PORTCR(173, 0xe60520AD),
+	PORTCR(174, 0xe60520AE),
+	PORTCR(175, 0xe60520AF),
+	PORTCR(176, 0xe60520B0),
+	PORTCR(177, 0xe60520B1),
+	PORTCR(178, 0xe60520B2),
+	PORTCR(192, 0xe60520C0),
+	PORTCR(193, 0xe60520C1),
+	PORTCR(194, 0xe60520C2),
+	PORTCR(195, 0xe60520C3),
+	PORTCR(196, 0xe60520C4),
+	PORTCR(197, 0xe60520C5),
+	PORTCR(198, 0xe60520C6),
+	PORTCR(199, 0xe60520C7),
+	PORTCR(200, 0xe60520C8),
+	PORTCR(201, 0xe60520C9),
+	PORTCR(202, 0xe60520CA),
+	PORTCR(203, 0xe60520CB),
+	PORTCR(204, 0xe60520CC),
+	PORTCR(205, 0xe60520CD),
+	PORTCR(206, 0xe60520CE),
+	PORTCR(207, 0xe60520CF),
+	PORTCR(208, 0xe60520D0),
+	PORTCR(209, 0xe60520D1),
+	PORTCR(210, 0xe60520D2),
+	PORTCR(211, 0xe60520D3),
+	PORTCR(212, 0xe60520D4),
+	PORTCR(213, 0xe60520D5),
+	PORTCR(214, 0xe60520D6),
+	PORTCR(215, 0xe60520D7),
+	PORTCR(216, 0xe60520D8),
+	PORTCR(217, 0xe60520D9),
+	PORTCR(218, 0xe60520DA),
+	PORTCR(219, 0xe60520DB),
+	PORTCR(220, 0xe60520DC),
+	PORTCR(221, 0xe60520DD),
+	PORTCR(222, 0xe60520DE),
+	PORTCR(224, 0xe60520E0),
+	PORTCR(225, 0xe60520E1),
+	PORTCR(226, 0xe60520E2),
+	PORTCR(227, 0xe60520E3),
+	PORTCR(228, 0xe60520E4),
+	PORTCR(229, 0xe60520E5),
+	PORTCR(230, 0xe60520e6),
+	PORTCR(231, 0xe60520E7),
+	PORTCR(232, 0xe60520E8),
+	PORTCR(233, 0xe60520E9),
+	PORTCR(234, 0xe60520EA),
+	PORTCR(235, 0xe60520EB),
+	PORTCR(236, 0xe60520EC),
+	PORTCR(237, 0xe60520ED),
+	PORTCR(238, 0xe60520EE),
+	PORTCR(239, 0xe60520EF),
+	PORTCR(240, 0xe60520F0),
+	PORTCR(241, 0xe60520F1),
+	PORTCR(242, 0xe60520F2),
+	PORTCR(243, 0xe60520F3),
+	PORTCR(244, 0xe60520F4),
+	PORTCR(245, 0xe60520F5),
+	PORTCR(246, 0xe60520F6),
+	PORTCR(247, 0xe60520F7),
+	PORTCR(248, 0xe60520F8),
+	PORTCR(249, 0xe60520F9),
+	PORTCR(250, 0xe60520FA),
+	PORTCR(256, 0xe6052100),
+	PORTCR(257, 0xe6052101),
+	PORTCR(258, 0xe6052102),
+	PORTCR(259, 0xe6052103),
+	PORTCR(260, 0xe6052104),
+	PORTCR(261, 0xe6052105),
+	PORTCR(262, 0xe6052106),
+	PORTCR(263, 0xe6052107),
+	PORTCR(264, 0xe6052108),
+	PORTCR(265, 0xe6052109),
+	PORTCR(266, 0xe605210A),
+	PORTCR(267, 0xe605210B),
+	PORTCR(268, 0xe605210C),
+	PORTCR(269, 0xe605210D),
+	PORTCR(270, 0xe605210E),
+	PORTCR(271, 0xe605210F),
+	PORTCR(272, 0xe6052110),
+	PORTCR(273, 0xe6052111),
+	PORTCR(274, 0xe6052112),
+	PORTCR(275, 0xe6052113),
+	PORTCR(276, 0xe6052114),
+	PORTCR(277, 0xe6052115),
+	PORTCR(278, 0xe6052116),
+	PORTCR(279, 0xe6052117),
+	PORTCR(280, 0xe6052118),
+	PORTCR(281, 0xe6052119),
+	PORTCR(282, 0xe605211A),
+	PORTCR(283, 0xe605211B),
+	PORTCR(288, 0xe6053120),
+	PORTCR(289, 0xe6053121),
+	PORTCR(290, 0xe6053122),
+	PORTCR(291, 0xe6053123),
+	PORTCR(292, 0xe6053124),
+	PORTCR(293, 0xe6053125),
+	PORTCR(294, 0xe6053126),
+	PORTCR(295, 0xe6053127),
+	PORTCR(296, 0xe6053128),
+	PORTCR(297, 0xe6053129),
+	PORTCR(298, 0xe605312A),
+	PORTCR(299, 0xe605312B),
+	PORTCR(300, 0xe605312C),
+	PORTCR(301, 0xe605312D),
+	PORTCR(302, 0xe605312E),
+	PORTCR(303, 0xe605312F),
+	PORTCR(304, 0xe6053130),
+	PORTCR(305, 0xe6053131),
+	PORTCR(306, 0xe6053132),
+	PORTCR(307, 0xe6053133),
+	PORTCR(308, 0xe6053134),
+	PORTCR(320, 0xe6053140),
+	PORTCR(321, 0xe6053141),
+	PORTCR(322, 0xe6053142),
+	PORTCR(323, 0xe6053143),
+	PORTCR(324, 0xe6053144),
+	PORTCR(325, 0xe6053145),
+	PORTCR(326, 0xe6053146),
+	PORTCR(327, 0xe6053147),
+	PORTCR(328, 0xe6053148),
+	PORTCR(329, 0xe6053149),
+
+	{ PINMUX_CFG_REG("MSEL1CR", 0xe605800c, 32, 1) {
+			MSEL1CR_31_0, MSEL1CR_31_1,
+			0, 0,
+			0, 0,
+			0, 0,
+			MSEL1CR_27_0, MSEL1CR_27_1,
+			0, 0,
+			MSEL1CR_25_0, MSEL1CR_25_1,
+			MSEL1CR_24_0, MSEL1CR_24_1,
+			0, 0,
+			MSEL1CR_22_0, MSEL1CR_22_1,
+			MSEL1CR_21_0, MSEL1CR_21_1,
+			MSEL1CR_20_0, MSEL1CR_20_1,
+			MSEL1CR_19_0, MSEL1CR_19_1,
+			MSEL1CR_18_0, MSEL1CR_18_1,
+			MSEL1CR_17_0, MSEL1CR_17_1,
+			MSEL1CR_16_0, MSEL1CR_16_1,
+			MSEL1CR_15_0, MSEL1CR_15_1,
+			MSEL1CR_14_0, MSEL1CR_14_1,
+			MSEL1CR_13_0, MSEL1CR_13_1,
+			MSEL1CR_12_0, MSEL1CR_12_1,
+			MSEL1CR_11_0, MSEL1CR_11_1,
+			MSEL1CR_10_0, MSEL1CR_10_1,
+			MSEL1CR_09_0, MSEL1CR_09_1,
+			MSEL1CR_08_0, MSEL1CR_08_1,
+			MSEL1CR_07_0, MSEL1CR_07_1,
+			MSEL1CR_06_0, MSEL1CR_06_1,
+			MSEL1CR_05_0, MSEL1CR_05_1,
+			MSEL1CR_04_0, MSEL1CR_04_1,
+			MSEL1CR_03_0, MSEL1CR_03_1,
+			MSEL1CR_02_0, MSEL1CR_02_1,
+			MSEL1CR_01_0, MSEL1CR_01_1,
+			MSEL1CR_00_0, MSEL1CR_00_1,
+		}
+	},
+	{ PINMUX_CFG_REG("MSEL3CR", 0xe6058020, 32, 1) {
+			MSEL3CR_31_0, MSEL3CR_31_1,
+			0, 0,
+			0, 0,
+			MSEL3CR_28_0, MSEL3CR_28_1,
+			MSEL3CR_27_0, MSEL3CR_27_1,
+			MSEL3CR_26_0, MSEL3CR_26_1,
+			0, 0,
+			0, 0,
+			MSEL3CR_23_0, MSEL3CR_23_1,
+			MSEL3CR_22_0, MSEL3CR_22_1,
+			MSEL3CR_21_0, MSEL3CR_21_1,
+			MSEL3CR_20_0, MSEL3CR_20_1,
+			MSEL3CR_19_0, MSEL3CR_19_1,
+			MSEL3CR_18_0, MSEL3CR_18_1,
+			MSEL3CR_17_0, MSEL3CR_17_1,
+			MSEL3CR_16_0, MSEL3CR_16_1,
+			MSEL3CR_15_0, MSEL3CR_15_1,
+			0, 0,
+			0, 0,
+			MSEL3CR_12_0, MSEL3CR_12_1,
+			MSEL3CR_11_0, MSEL3CR_11_1,
+			MSEL3CR_10_0, MSEL3CR_10_1,
+			MSEL3CR_09_0, MSEL3CR_09_1,
+			0, 0,
+			0, 0,
+			MSEL3CR_06_0, MSEL3CR_06_1,
+			0, 0,
+			0, 0,
+			MSEL3CR_03_0, MSEL3CR_03_1,
+			0, 0,
+			MSEL3CR_01_0, MSEL3CR_01_1,
+			MSEL3CR_00_0, MSEL3CR_00_1,
+			}
+	},
+	{ PINMUX_CFG_REG("MSEL4CR", 0xe6058024, 32, 1) {
+			0, 0,
+			MSEL4CR_30_0, MSEL4CR_30_1,
+			MSEL4CR_29_0, MSEL4CR_29_1,
+			MSEL4CR_28_0, MSEL4CR_28_1,
+			MSEL4CR_27_0, MSEL4CR_27_1,
+			MSEL4CR_26_0, MSEL4CR_26_1,
+			MSEL4CR_25_0, MSEL4CR_25_1,
+			MSEL4CR_24_0, MSEL4CR_24_1,
+			MSEL4CR_23_0, MSEL4CR_23_1,
+			MSEL4CR_22_0, MSEL4CR_22_1,
+			MSEL4CR_21_0, MSEL4CR_21_1,
+			MSEL4CR_20_0, MSEL4CR_20_1,
+			MSEL4CR_19_0, MSEL4CR_19_1,
+			MSEL4CR_18_0, MSEL4CR_18_1,
+			MSEL4CR_17_0, MSEL4CR_17_1,
+			MSEL4CR_16_0, MSEL4CR_16_1,
+			MSEL4CR_15_0, MSEL4CR_15_1,
+			MSEL4CR_14_0, MSEL4CR_14_1,
+			MSEL4CR_13_0, MSEL4CR_13_1,
+			MSEL4CR_12_0, MSEL4CR_12_1,
+			MSEL4CR_11_0, MSEL4CR_11_1,
+			MSEL4CR_10_0, MSEL4CR_10_1,
+			MSEL4CR_09_0, MSEL4CR_09_1,
+			0, 0,
+			MSEL4CR_07_0, MSEL4CR_07_1,
+			0, 0,
+			0, 0,
+			MSEL4CR_04_0, MSEL4CR_04_1,
+			0, 0,
+			0, 0,
+			MSEL4CR_01_0, MSEL4CR_01_1,
+			0, 0,
+		}
+	},
+	{ PINMUX_CFG_REG("MSEL5CR", 0xe6058028, 32, 1) {
+			MSEL5CR_31_0, MSEL5CR_31_1,
+			MSEL5CR_30_0, MSEL5CR_30_1,
+			MSEL5CR_29_0, MSEL5CR_29_1,
+			MSEL5CR_28_0, MSEL5CR_28_1,
+			MSEL5CR_27_0, MSEL5CR_27_1,
+			MSEL5CR_26_0, MSEL5CR_26_1,
+			MSEL5CR_25_0, MSEL5CR_25_1,
+			MSEL5CR_24_0, MSEL5CR_24_1,
+			MSEL5CR_23_0, MSEL5CR_23_1,
+			MSEL5CR_22_0, MSEL5CR_22_1,
+			MSEL5CR_21_0, MSEL5CR_21_1,
+			MSEL5CR_20_0, MSEL5CR_20_1,
+			MSEL5CR_19_0, MSEL5CR_19_1,
+			MSEL5CR_18_0, MSEL5CR_18_1,
+			MSEL5CR_17_0, MSEL5CR_17_1,
+			MSEL5CR_16_0, MSEL5CR_16_1,
+			MSEL5CR_15_0, MSEL5CR_15_1,
+			MSEL5CR_14_0, MSEL5CR_14_1,
+			MSEL5CR_13_0, MSEL5CR_13_1,
+			MSEL5CR_12_0, MSEL5CR_12_1,
+			MSEL5CR_11_0, MSEL5CR_11_1,
+			MSEL5CR_10_0, MSEL5CR_10_1,
+			MSEL5CR_09_0, MSEL5CR_09_1,
+			MSEL5CR_08_0, MSEL5CR_08_1,
+			MSEL5CR_07_0, MSEL5CR_07_1,
+			MSEL5CR_06_0, MSEL5CR_06_1,
+			0, 0,
+			0, 0,
+			0, 0,
+			0, 0,
+			0, 0,
+			0, 0,
+		}
+	},
+	{ PINMUX_CFG_REG("MSEL8CR", 0xe6058034, 32, 1) {
+			0, 0,
+			0, 0,
+			0, 0,
+			0, 0,
+			0, 0,
+			0, 0,
+			0, 0,
+			0, 0,
+			0, 0,
+			0, 0,
+			0, 0,
+			0, 0,
+			0, 0,
+			0, 0,
+			0, 0,
+			MSEL8CR_16_0, MSEL8CR_16_1,
+			0, 0,
+			0, 0,
+			0, 0,
+			0, 0,
+			0, 0,
+			0, 0,
+			0, 0,
+			0, 0,
+			0, 0,
+			0, 0,
+			0, 0,
+			0, 0,
+			0, 0,
+			0, 0,
+			MSEL8CR_01_0, MSEL8CR_01_1,
+			MSEL8CR_00_0, MSEL8CR_00_1,
+		}
+	},
+	{ },
+};
+
+static const struct pinmux_data_reg pinmux_data_regs[] = {
+
+	{ PINMUX_DATA_REG("PORTL031_000DR", 0xe6054000, 32) {
+			0, PORT30_DATA, PORT29_DATA, PORT28_DATA,
+			PORT27_DATA, PORT26_DATA, PORT25_DATA, PORT24_DATA,
+			PORT23_DATA, PORT22_DATA, PORT21_DATA, PORT20_DATA,
+			PORT19_DATA, PORT18_DATA, PORT17_DATA, PORT16_DATA,
+			PORT15_DATA, PORT14_DATA, PORT13_DATA, PORT12_DATA,
+			PORT11_DATA, PORT10_DATA, PORT9_DATA, PORT8_DATA,
+			PORT7_DATA, PORT6_DATA, PORT5_DATA, PORT4_DATA,
+			PORT3_DATA, PORT2_DATA, PORT1_DATA, PORT0_DATA,
+		}
+	},
+	{ PINMUX_DATA_REG("PORTD063_032DR", 0xe6055000, 32) {
+			0, 0, 0, 0,
+			0, 0, 0, 0,
+			0, 0, 0, 0,
+			0, 0, 0, 0,
+			0, 0, 0, 0,
+			0, 0, 0, PORT40_DATA,
+			PORT39_DATA, PORT38_DATA, PORT37_DATA, PORT36_DATA,
+			PORT35_DATA, PORT34_DATA, PORT33_DATA, PORT32_DATA,
+		}
+	},
+	{ PINMUX_DATA_REG("PORTL095_064DR", 0xe6054004, 32) {
+			0, 0, 0, 0,
+			0, 0, 0, 0,
+			0, 0, PORT85_DATA, PORT84_DATA,
+			PORT83_DATA, PORT82_DATA, PORT81_DATA, PORT80_DATA,
+			PORT79_DATA, PORT78_DATA, PORT77_DATA, PORT76_DATA,
+			PORT75_DATA, PORT74_DATA, PORT73_DATA, PORT72_DATA,
+			PORT71_DATA, PORT70_DATA, PORT69_DATA, PORT68_DATA,
+			PORT67_DATA, PORT66_DATA, PORT65_DATA, PORT64_DATA,
+		}
+	},
+	{ PINMUX_DATA_REG("PORTD127_096DR", 0xe6055004, 32) {
+			0, PORT126_DATA, PORT125_DATA, PORT124_DATA,
+			PORT123_DATA, PORT122_DATA, PORT121_DATA, PORT120_DATA,
+			PORT119_DATA, PORT118_DATA, PORT117_DATA, PORT116_DATA,
+			PORT115_DATA, PORT114_DATA, PORT113_DATA, PORT112_DATA,
+			PORT111_DATA, PORT110_DATA, PORT109_DATA, PORT108_DATA,
+			PORT107_DATA, PORT106_DATA, PORT105_DATA, PORT104_DATA,
+			PORT103_DATA, PORT102_DATA, PORT101_DATA, PORT100_DATA,
+			PORT99_DATA, PORT98_DATA, PORT97_DATA, PORT96_DATA,
+		}
+	},
+	{ PINMUX_DATA_REG("PORTD159_128DR", 0xe6055008, 32) {
+			0, 0, 0, 0,
+			0, 0, 0, 0,
+			0, 0, 0, 0,
+			0, 0, 0, 0,
+			0, 0, 0, 0,
+			0, 0, 0, 0,
+			0, PORT134_DATA, PORT133_DATA, PORT132_DATA,
+			PORT131_DATA, PORT130_DATA, PORT129_DATA, PORT128_DATA,
+		}
+	},
+	{ PINMUX_DATA_REG("PORTR191_160DR", 0xe6056000, 32) {
+			0, 0, 0, 0,
+			0, 0, 0, 0,
+			0, 0, 0, 0,
+			0, PORT178_DATA, PORT177_DATA, PORT176_DATA,
+			PORT175_DATA, PORT174_DATA, PORT173_DATA, PORT172_DATA,
+			PORT171_DATA, PORT170_DATA, PORT169_DATA, PORT168_DATA,
+			PORT167_DATA, PORT166_DATA, PORT165_DATA, PORT164_DATA,
+			PORT163_DATA, PORT162_DATA, PORT161_DATA, PORT160_DATA,
+		}
+	},
+	{ PINMUX_DATA_REG("PORTR223_192DR", 0xe6056004, 32) {
+			0, PORT222_DATA, PORT221_DATA, PORT220_DATA,
+			PORT219_DATA, PORT218_DATA, PORT217_DATA, PORT216_DATA,
+			PORT215_DATA, PORT214_DATA, PORT213_DATA, PORT212_DATA,
+			PORT211_DATA, PORT210_DATA, PORT209_DATA, PORT208_DATA,
+			PORT207_DATA, PORT206_DATA, PORT205_DATA, PORT204_DATA,
+			PORT203_DATA, PORT202_DATA, PORT201_DATA, PORT200_DATA,
+			PORT199_DATA, PORT198_DATA, PORT197_DATA, PORT196_DATA,
+			PORT195_DATA, PORT194_DATA, PORT193_DATA, PORT192_DATA,
+		}
+	},
+	{ PINMUX_DATA_REG("PORTR255_224DR", 0xe6056008, 32) {
+			0, 0, 0, 0,
+			0, PORT250_DATA, PORT249_DATA, PORT248_DATA,
+			PORT247_DATA, PORT246_DATA, PORT245_DATA, PORT244_DATA,
+			PORT243_DATA, PORT242_DATA, PORT241_DATA, PORT240_DATA,
+			PORT239_DATA, PORT238_DATA, PORT237_DATA, PORT236_DATA,
+			PORT235_DATA, PORT234_DATA, PORT233_DATA, PORT232_DATA,
+			PORT231_DATA, PORT230_DATA, PORT229_DATA, PORT228_DATA,
+			PORT227_DATA, PORT226_DATA, PORT225_DATA, PORT224_DATA,
+		}
+	},
+	{ PINMUX_DATA_REG("PORTR287_256DR", 0xe605600C, 32) {
+			0, 0, 0, 0,
+			PORT283_DATA, PORT282_DATA, PORT281_DATA, PORT280_DATA,
+			PORT279_DATA, PORT278_DATA, PORT277_DATA, PORT276_DATA,
+			PORT275_DATA, PORT274_DATA, PORT273_DATA, PORT272_DATA,
+			PORT271_DATA, PORT270_DATA, PORT269_DATA, PORT268_DATA,
+			PORT267_DATA, PORT266_DATA, PORT265_DATA, PORT264_DATA,
+			PORT263_DATA, PORT262_DATA, PORT261_DATA, PORT260_DATA,
+			PORT259_DATA, PORT258_DATA, PORT257_DATA, PORT256_DATA,
+		}
+	},
+	{ PINMUX_DATA_REG("PORTU319_288DR", 0xe6057000, 32) {
+			0, 0, 0, 0,
+			0, 0, 0, 0,
+			0, 0, 0, PORT308_DATA,
+			PORT307_DATA, PORT306_DATA, PORT305_DATA, PORT304_DATA,
+			PORT303_DATA, PORT302_DATA, PORT301_DATA, PORT300_DATA,
+			PORT299_DATA, PORT298_DATA, PORT297_DATA, PORT296_DATA,
+			PORT295_DATA, PORT294_DATA, PORT293_DATA, PORT292_DATA,
+			PORT291_DATA, PORT290_DATA, PORT289_DATA, PORT288_DATA,
+		}
+	},
+	{ PINMUX_DATA_REG("PORTU351_320DR", 0xe6057004, 32) {
+			0, 0, 0, 0,
+			0, 0, 0, 0,
+			0, 0, 0, 0,
+			0, 0, 0, 0,
+			0, 0, 0, 0,
+			0, 0, PORT329_DATA, PORT328_DATA,
+			PORT327_DATA, PORT326_DATA, PORT325_DATA, PORT324_DATA,
+			PORT323_DATA, PORT322_DATA, PORT321_DATA, PORT320_DATA,
+		}
+	},
+	{ },
+};
+
+const struct sh_pfc_soc_info r8a73a4_pinmux_info = {
+	.name		= "r8a73a4_pfc",
+
+	.input = { PINMUX_INPUT_BEGIN, PINMUX_INPUT_END },
+	.input_pu = { PINMUX_INPUT_PULLUP_BEGIN, PINMUX_INPUT_PULLUP_END },
+	.input_pd = { PINMUX_INPUT_PULLDOWN_BEGIN, PINMUX_INPUT_PULLDOWN_END },
+	.output = { PINMUX_OUTPUT_BEGIN, PINMUX_OUTPUT_END },
+	.function = { PINMUX_FUNCTION_BEGIN, PINMUX_FUNCTION_END },
+
+	.pins = pinmux_pins,
+	.nr_pins = ARRAY_SIZE(pinmux_pins),
+	.func_gpios = pinmux_func_gpios,
+	.nr_func_gpios = ARRAY_SIZE(pinmux_func_gpios),
+
+	.cfg_regs	= pinmux_config_regs,
+	.data_regs	= pinmux_data_regs,
+
+	.gpio_data	= pinmux_data,
+	.gpio_data_size	= ARRAY_SIZE(pinmux_data),
+};
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 01:11:14 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue,  2 Apr 2013 14:11:14 +0900
Subject: [PATCH 02/11] ARM: shmobile: kzm9g-reference: add ethernet support
In-Reply-To: <1364879483-11144-1-git-send-email-horms+renesas@verge.net.au>
References: <1364879483-11144-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364879483-11144-3-git-send-email-horms+renesas@verge.net.au>

From: Guennadi Liakhovetski <g.liakhovetski at gmx.de>

Add a DT node for the SMSC 9221 ethernet chip, found on kzm9g, to its
reference implementation.

Signed-off-by: Guennadi Liakhovetski <g.liakhovetski at gmx.de>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/sh73a0-kzm9g-reference.dts |   13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/arch/arm/boot/dts/sh73a0-kzm9g-reference.dts b/arch/arm/boot/dts/sh73a0-kzm9g-reference.dts
index f33b5cc..5972abb 100644
--- a/arch/arm/boot/dts/sh73a0-kzm9g-reference.dts
+++ b/arch/arm/boot/dts/sh73a0-kzm9g-reference.dts
@@ -44,6 +44,19 @@
 		regulator-always-on;
 		regulator-boot-on;
 	};
+
+	lan9220 at 10000000 {
+		compatible = "smsc,lan9220", "smsc,lan9115";
+		reg = <0x10000000 0x100>;
+		phy-mode = "mii";
+		interrupt-parent = <&irqpin0>;
+		interrupts = <3 0>;	/* active low */
+		reg-io-width = <4>;
+		smsc,irq-push-pull;
+		smsc,save-mac-address;
+		vddvario-supply = <&reg_1p8v>;
+		vdd33a-supply = <&reg_3p3v>;
+	};
 };
 
 &mmcif {
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 01:11:12 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue,  2 Apr 2013 14:11:12 +0900
Subject: Renesas ARM SoC board updates for v3.10 #3
Message-ID: <1364879483-11144-1-git-send-email-horms+renesas@verge.net.au>

Hi Arnd, Hi Olof,

The following changes since commit df16da03fc60fcfbc7f4b0cb849f9c1fc956a991:

  Merge branch 'pinmux' into boards-base (2013-04-02 13:21:54 +0900)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-boards3-for-v3.10

for you to fetch changes up to b9a2f94954622b8fab222b1029fbfcdbed558b44:

  ARM: shmobile: mackerel: clean up MMCIF vs. SDHI1 selection (2013-04-02 13:22:54 +0900)

----------------------------------------------------------------
Third round of  Renesas ARM SoC board updates for v3.10

Highlights:

* Add Lager board support
* Add ape6evm board support
* Add Bock-W board support
* Mackerel MMCIF/SDHI clean ups
* Add ethernet support to kzm9g-reference

This pull request is based on a merge of:

git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas renesas-pinmux2-for-v3.10
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas renesas-boards2-for-v3.10

----------------------------------------------------------------
Guennadi Liakhovetski (6):
      ARM: shmobile: kzm9g-reference: add ethernet support
      ARM: shmobile: mackerel: SDHI resources do not have to be numbered
      ARM: shmobile: mackerel: remove OCR masks, where regulators are used
      ARM: shmobile: mackerel: switch SDHI and MMCIF interfaces to slot-gpio
      ARM: shmobile: mackerel: add interrupt names for SDHI0
      ARM: shmobile: mackerel: clean up MMCIF vs. SDHI1 selection

Kuninori Morimoto (1):
      ARM: shmobile: add R-Car M1A Bock-W platform support

Magnus Damm (4):
      ARM: shmobile: APE6EVM base support
      ARM: shmobile: APE6EVM PFC support
      ARM: shmobile: APE6EVM LAN9220 support
      ARM: shmobile: Initial r8a7790 Lager board support

 arch/arm/boot/dts/Makefile                   |    3 +
 arch/arm/boot/dts/r8a73a4-ape6evm.dts        |   52 ++++++++++++
 arch/arm/boot/dts/r8a7778-bockw.dts          |   32 ++++++++
 arch/arm/boot/dts/r8a7790-lager.dts          |   31 +++++++
 arch/arm/boot/dts/sh73a0-kzm9g-reference.dts |   13 +++
 arch/arm/configs/bockw_defconfig             |   66 +++++++++++++++
 arch/arm/mach-shmobile/Kconfig               |   21 ++++-
 arch/arm/mach-shmobile/Makefile              |    3 +
 arch/arm/mach-shmobile/board-ape6evm.c       |   94 ++++++++++++++++++++++
 arch/arm/mach-shmobile/board-bockw.c         |   43 ++++++++++
 arch/arm/mach-shmobile/board-lager.c         |   46 +++++++++++
 arch/arm/mach-shmobile/board-mackerel.c      |  111 ++++++++++----------------
 12 files changed, 443 insertions(+), 72 deletions(-)
 create mode 100644 arch/arm/boot/dts/r8a73a4-ape6evm.dts
 create mode 100644 arch/arm/boot/dts/r8a7778-bockw.dts
 create mode 100644 arch/arm/boot/dts/r8a7790-lager.dts
 create mode 100644 arch/arm/configs/bockw_defconfig
 create mode 100644 arch/arm/mach-shmobile/board-ape6evm.c
 create mode 100644 arch/arm/mach-shmobile/board-bockw.c
 create mode 100644 arch/arm/mach-shmobile/board-lager.c


From horms+renesas at verge.net.au  Tue Apr  2 01:11:16 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue,  2 Apr 2013 14:11:16 +0900
Subject: [PATCH 04/11] ARM: shmobile: APE6EVM PFC support
In-Reply-To: <1364879483-11144-1-git-send-email-horms+renesas@verge.net.au>
References: <1364879483-11144-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364879483-11144-5-git-send-email-horms+renesas@verge.net.au>

From: Magnus Damm <damm at opensource.se>

Start using the r8a73a4 PFC on the APE6EVM board
and configure the SCIFA0 console signals in the
PFC via PINCTRL.

Signed-off-by: Magnus Damm <damm at opensource.se>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/board-ape6evm.c |   10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/mach-shmobile/board-ape6evm.c b/arch/arm/mach-shmobile/board-ape6evm.c
index 9234d4f..33a8a62 100644
--- a/arch/arm/mach-shmobile/board-ape6evm.c
+++ b/arch/arm/mach-shmobile/board-ape6evm.c
@@ -21,15 +21,25 @@
 #include <linux/interrupt.h>
 #include <linux/irqchip.h>
 #include <linux/kernel.h>
+#include <linux/pinctrl/machine.h>
 #include <linux/platform_device.h>
 #include <mach/common.h>
 #include <mach/r8a73a4.h>
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
 
+static const struct pinctrl_map ape6evm_pinctrl_map[] = {
+	/* SCIFA0 console */
+	PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.0", "pfc-r8a73a4",
+				  "scifa0_data", "scifa0"),
+};
+
 static void __init ape6evm_add_standard_devices(void)
 {
 	r8a73a4_clock_init();
+	pinctrl_register_mappings(ape6evm_pinctrl_map,
+				  ARRAY_SIZE(ape6evm_pinctrl_map));
+	r8a73a4_pinmux_init();
 	r8a73a4_add_standard_devices();
 }
 
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 01:11:19 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue,  2 Apr 2013 14:11:19 +0900
Subject: [PATCH 07/11] ARM: shmobile: mackerel: SDHI resources do not have to
 be numbered
In-Reply-To: <1364879483-11144-1-git-send-email-horms+renesas@verge.net.au>
References: <1364879483-11144-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364879483-11144-8-git-send-email-horms+renesas@verge.net.au>

From: Guennadi Liakhovetski <g.liakhovetski at gmx.de>

The SDHI driver doesn't care about platform resource order, explicit
resource numbering is redundant.

Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas at gmail.com>
Acked-by: Magnus Damm <damm at opensource.se>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/board-mackerel.c |   33 +++++++++++--------------------
 1 file changed, 12 insertions(+), 21 deletions(-)

diff --git a/arch/arm/mach-shmobile/board-mackerel.c b/arch/arm/mach-shmobile/board-mackerel.c
index 1a9c753..c4f80d4 100644
--- a/arch/arm/mach-shmobile/board-mackerel.c
+++ b/arch/arm/mach-shmobile/board-mackerel.c
@@ -982,21 +982,18 @@ static struct sh_mobile_sdhi_info sdhi0_info = {
 };
 
 static struct resource sdhi0_resources[] = {
-	[0] = {
+	{
 		.name	= "SDHI0",
 		.start	= 0xe6850000,
 		.end	= 0xe68500ff,
 		.flags	= IORESOURCE_MEM,
-	},
-	[1] = {
+	}, {
 		.start	= evt2irq(0x0e00) /* SDHI0_SDHI0I0 */,
 		.flags	= IORESOURCE_IRQ,
-	},
-	[2] = {
+	}, {
 		.start	= evt2irq(0x0e20) /* SDHI0_SDHI0I1 */,
 		.flags	= IORESOURCE_IRQ,
-	},
-	[3] = {
+	}, {
 		.start	= evt2irq(0x0e40) /* SDHI0_SDHI0I2 */,
 		.flags	= IORESOURCE_IRQ,
 	},
@@ -1025,23 +1022,20 @@ static struct sh_mobile_sdhi_info sdhi1_info = {
 };
 
 static struct resource sdhi1_resources[] = {
-	[0] = {
+	{
 		.name	= "SDHI1",
 		.start	= 0xe6860000,
 		.end	= 0xe68600ff,
 		.flags	= IORESOURCE_MEM,
-	},
-	[1] = {
+	}, {
 		.name	= SH_MOBILE_SDHI_IRQ_CARD_DETECT,
 		.start	= evt2irq(0x0e80), /* SDHI1_SDHI1I0 */
 		.flags	= IORESOURCE_IRQ,
-	},
-	[2] = {
+	}, {
 		.name	= SH_MOBILE_SDHI_IRQ_SDCARD,
 		.start	= evt2irq(0x0ea0), /* SDHI1_SDHI1I1 */
 		.flags	= IORESOURCE_IRQ,
-	},
-	[3] = {
+	}, {
 		.name	= SH_MOBILE_SDHI_IRQ_SDIO,
 		.start	= evt2irq(0x0ec0), /* SDHI1_SDHI1I2 */
 		.flags	= IORESOURCE_IRQ,
@@ -1079,23 +1073,20 @@ static struct sh_mobile_sdhi_info sdhi2_info = {
 };
 
 static struct resource sdhi2_resources[] = {
-	[0] = {
+	{
 		.name	= "SDHI2",
 		.start	= 0xe6870000,
 		.end	= 0xe68700ff,
 		.flags	= IORESOURCE_MEM,
-	},
-	[1] = {
+	}, {
 		.name	= SH_MOBILE_SDHI_IRQ_CARD_DETECT,
 		.start	= evt2irq(0x1200), /* SDHI2_SDHI2I0 */
 		.flags	= IORESOURCE_IRQ,
-	},
-	[2] = {
+	}, {
 		.name	= SH_MOBILE_SDHI_IRQ_SDCARD,
 		.start	= evt2irq(0x1220), /* SDHI2_SDHI2I1 */
 		.flags	= IORESOURCE_IRQ,
-	},
-	[3] = {
+	}, {
 		.name	= SH_MOBILE_SDHI_IRQ_SDIO,
 		.start	= evt2irq(0x1240), /* SDHI2_SDHI2I2 */
 		.flags	= IORESOURCE_IRQ,
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 01:11:15 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue,  2 Apr 2013 14:11:15 +0900
Subject: [PATCH 03/11] ARM: shmobile: APE6EVM base support
In-Reply-To: <1364879483-11144-1-git-send-email-horms+renesas@verge.net.au>
References: <1364879483-11144-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364879483-11144-4-git-send-email-horms+renesas@verge.net.au>

From: Magnus Damm <damm at opensource.se>

V3 of APE6EVM base board support making use of
1 GiB of memory, the SCIFA0 serial port and
ARM architected timer.

Signed-off-by: Magnus Damm <damm at opensource.se>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/Makefile             |    1 +
 arch/arm/boot/dts/r8a73a4-ape6evm.dts  |   31 +++++++++++++++++++++
 arch/arm/mach-shmobile/Kconfig         |    8 +++++-
 arch/arm/mach-shmobile/Makefile        |    1 +
 arch/arm/mach-shmobile/board-ape6evm.c |   46 ++++++++++++++++++++++++++++++++
 5 files changed, 86 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/r8a73a4-ape6evm.dts
 create mode 100644 arch/arm/mach-shmobile/board-ape6evm.c

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 363fa507..a99b0f7 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -140,6 +140,7 @@ dtb-$(CONFIG_ARCH_SHMOBILE) += emev2-kzm9d.dtb \
 	r8a7779-marzen-reference.dtb \
 	sh73a0-kzm9g.dtb \
 	sh73a0-kzm9g-reference.dtb \
+	r8a73a4-ape6evm.dtb \
 	sh7372-mackerel.dtb
 dtb-$(CONFIG_ARCH_SOCFPGA) += socfpga_cyclone5.dtb \
 	socfpga_vt.dtb
diff --git a/arch/arm/boot/dts/r8a73a4-ape6evm.dts b/arch/arm/boot/dts/r8a73a4-ape6evm.dts
new file mode 100644
index 0000000..833f703
--- /dev/null
+++ b/arch/arm/boot/dts/r8a73a4-ape6evm.dts
@@ -0,0 +1,31 @@
+/*
+ * Device Tree Source for the APE6EVM board
+ *
+ * Copyright (C) 2013 Renesas Solutions Corp.
+ *
+ * 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.
+ */
+
+/dts-v1/;
+/include/ "r8a73a4.dtsi"
+
+/ {
+	model = "APE6EVM";
+	compatible = "renesas,ape6evm", "renesas,r8a73a4";
+
+	chosen {
+		bootargs = "console=ttySC0,115200 ignore_loglevel";
+	};
+
+	memory at 40000000 {
+		device_type = "memory";
+		reg = <0 0x40000000 0 0x40000000>;
+	};
+
+	lbsc {
+		#address-cells = <1>;
+		#size-cells = <1>;
+	};
+};
diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index 18712ad..c0da6af 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -96,6 +96,11 @@ config MACH_AG5EVM
 	select REGULATOR_FIXED_VOLTAGE if REGULATOR
 	select SH_LCD_MIPI_DSI
 
+config MACH_APE6EVM
+	bool "APE6EVM board"
+	depends on ARCH_R8A73A4
+	select USE_OF
+
 config MACH_MACKEREL
 	bool "mackerel board"
 	depends on ARCH_SH7372
@@ -189,7 +194,7 @@ config MEMORY_START
 	hex "Physical memory start address"
 	default "0x40000000" if MACH_AP4EVB || MACH_AG5EVM || \
 				MACH_MACKEREL || MACH_BONITO || \
-				MACH_ARMADILLO800EVA
+				MACH_ARMADILLO800EVA || MACH_APE6EVM
 	default "0x41000000" if MACH_KOTA2
 	default "0x00000000"
 	---help---
@@ -199,6 +204,7 @@ config MEMORY_START
 
 config MEMORY_SIZE
 	hex "Physical memory size"
+	default "0x40000000" if MACH_APE6EVM
 	default "0x20000000" if MACH_AG5EVM || MACH_BONITO || \
 				MACH_ARMADILLO800EVA
 	default "0x1e000000" if MACH_KOTA2
diff --git a/arch/arm/mach-shmobile/Makefile b/arch/arm/mach-shmobile/Makefile
index 5eada96..ec2524e 100644
--- a/arch/arm/mach-shmobile/Makefile
+++ b/arch/arm/mach-shmobile/Makefile
@@ -37,6 +37,7 @@ obj-$(CONFIG_ARCH_SH73A0)	+= pm-sh73a0.o
 # Board objects
 obj-$(CONFIG_MACH_AP4EVB)	+= board-ap4evb.o
 obj-$(CONFIG_MACH_AG5EVM)	+= board-ag5evm.o
+obj-$(CONFIG_MACH_APE6EVM)	+= board-ape6evm.o
 obj-$(CONFIG_MACH_MACKEREL)	+= board-mackerel.o
 obj-$(CONFIG_MACH_KOTA2)	+= board-kota2.o
 obj-$(CONFIG_MACH_BONITO)	+= board-bonito.o
diff --git a/arch/arm/mach-shmobile/board-ape6evm.c b/arch/arm/mach-shmobile/board-ape6evm.c
new file mode 100644
index 0000000..9234d4f
--- /dev/null
+++ b/arch/arm/mach-shmobile/board-ape6evm.c
@@ -0,0 +1,46 @@
+/*
+ * APE6EVM board support
+ *
+ * Copyright (C) 2013  Renesas Solutions Corp.
+ * Copyright (C) 2013  Magnus Damm
+ *
+ * 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; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
+ */
+
+#include <linux/interrupt.h>
+#include <linux/irqchip.h>
+#include <linux/kernel.h>
+#include <linux/platform_device.h>
+#include <mach/common.h>
+#include <mach/r8a73a4.h>
+#include <asm/mach-types.h>
+#include <asm/mach/arch.h>
+
+static void __init ape6evm_add_standard_devices(void)
+{
+	r8a73a4_clock_init();
+	r8a73a4_add_standard_devices();
+}
+
+static const char *ape6evm_boards_compat_dt[] __initdata = {
+	"renesas,ape6evm",
+	NULL,
+};
+
+DT_MACHINE_START(APE6EVM_DT, "ape6evm")
+	.init_irq	= irqchip_init,
+	.init_time	= shmobile_timer_init,
+	.init_machine	= ape6evm_add_standard_devices,
+	.dt_compat	= ape6evm_boards_compat_dt,
+MACHINE_END
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 01:11:17 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue,  2 Apr 2013 14:11:17 +0900
Subject: [PATCH 05/11] ARM: shmobile: APE6EVM LAN9220 support
In-Reply-To: <1364879483-11144-1-git-send-email-horms+renesas@verge.net.au>
References: <1364879483-11144-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364879483-11144-6-git-send-email-horms+renesas@verge.net.au>

From: Magnus Damm <damm at opensource.se>

Add LAN9220 support to the APE6EVM board using C and DT.
At this point the PFC driver lacks DT bindings so to
configure the PFC we use PINCTRL in C board code.

Signed-off-by: Magnus Damm <damm at opensource.se>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a73a4-ape6evm.dts  |   23 ++++++++++++++++++-
 arch/arm/mach-shmobile/board-ape6evm.c |   38 ++++++++++++++++++++++++++++++++
 2 files changed, 60 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/r8a73a4-ape6evm.dts b/arch/arm/boot/dts/r8a73a4-ape6evm.dts
index 833f703..f603c69 100644
--- a/arch/arm/boot/dts/r8a73a4-ape6evm.dts
+++ b/arch/arm/boot/dts/r8a73a4-ape6evm.dts
@@ -16,7 +16,7 @@
 	compatible = "renesas,ape6evm", "renesas,r8a73a4";
 
 	chosen {
-		bootargs = "console=ttySC0,115200 ignore_loglevel";
+		bootargs = "console=ttySC0,115200 ignore_loglevel root=/dev/nfs ip=dhcp";
 	};
 
 	memory at 40000000 {
@@ -24,8 +24,29 @@
 		reg = <0 0x40000000 0 0x40000000>;
 	};
 
+	ape6evm_fixed_3v3: fixedregulator at 0 {
+		compatible = "regulator-fixed";
+		regulator-name = "3V3";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		regulator-always-on;
+	};
+
 	lbsc {
 		#address-cells = <1>;
 		#size-cells = <1>;
+
+		ethernet at 8000000 {
+			compatible = "smsc,lan9118", "smsc,lan9115";
+			reg = <0x08000000 0x1000>;
+			interrupt-parent = <&irqc1>;
+			interrupts = <8 0x4>;
+			phy-mode = "mii";
+			reg-io-width = <4>;
+			smsc,irq-active-high;
+			smsc,irq-push-pull;
+			vdd33a-supply = <&ape6evm_fixed_3v3>;
+			vddvario-supply = <&ape6evm_fixed_3v3>;
+		};
 	};
 };
diff --git a/arch/arm/mach-shmobile/board-ape6evm.c b/arch/arm/mach-shmobile/board-ape6evm.c
index 33a8a62..55b8c9f 100644
--- a/arch/arm/mach-shmobile/board-ape6evm.c
+++ b/arch/arm/mach-shmobile/board-ape6evm.c
@@ -18,20 +18,49 @@
  * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
  */
 
+#include <linux/gpio.h>
 #include <linux/interrupt.h>
 #include <linux/irqchip.h>
 #include <linux/kernel.h>
 #include <linux/pinctrl/machine.h>
 #include <linux/platform_device.h>
+#include <linux/regulator/fixed.h>
+#include <linux/regulator/machine.h>
+#include <linux/smsc911x.h>
 #include <mach/common.h>
+#include <mach/irqs.h>
 #include <mach/r8a73a4.h>
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
 
+/* Dummy supplies, where voltage doesn't matter */
+static struct regulator_consumer_supply dummy_supplies[] = {
+	REGULATOR_SUPPLY("vddvario", "smsc911x"),
+	REGULATOR_SUPPLY("vdd33a", "smsc911x"),
+};
+
+/* SMSC LAN9220 */
+static const struct resource lan9220_res[] = {
+	DEFINE_RES_MEM(0x08000000, 0x1000),
+	{
+		.start	= irq_pin(40), /* IRQ40 */
+		.flags	= IORESOURCE_IRQ | IRQF_TRIGGER_HIGH,
+	},
+};
+
+static const struct smsc911x_platform_config lan9220_data = {
+	.flags		= SMSC911X_USE_32BIT,
+	.irq_type	= SMSC911X_IRQ_TYPE_PUSH_PULL,
+	.irq_polarity	= SMSC911X_IRQ_POLARITY_ACTIVE_HIGH,
+};
+
 static const struct pinctrl_map ape6evm_pinctrl_map[] = {
 	/* SCIFA0 console */
 	PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.0", "pfc-r8a73a4",
 				  "scifa0_data", "scifa0"),
+	/* SMSC */
+	PIN_MAP_MUX_GROUP_DEFAULT("smsc911x", "pfc-r8a73a4",
+				  "irqc_irq40", "irqc"),
 };
 
 static void __init ape6evm_add_standard_devices(void)
@@ -41,6 +70,15 @@ static void __init ape6evm_add_standard_devices(void)
 				  ARRAY_SIZE(ape6evm_pinctrl_map));
 	r8a73a4_pinmux_init();
 	r8a73a4_add_standard_devices();
+
+	/* LAN9220 ethernet */
+	gpio_request_one(270, GPIOF_OUT_INIT_HIGH, NULL); /* smsc9220 RESET */
+
+	regulator_register_fixed(0, dummy_supplies, ARRAY_SIZE(dummy_supplies));
+
+	platform_device_register_resndata(&platform_bus, "smsc911x", -1,
+					  lan9220_res, ARRAY_SIZE(lan9220_res),
+					  &lan9220_data, sizeof(lan9220_data));
 }
 
 static const char *ape6evm_boards_compat_dt[] __initdata = {
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 01:11:13 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue,  2 Apr 2013 14:11:13 +0900
Subject: [PATCH 01/11] ARM: shmobile: add R-Car M1A Bock-W platform support
In-Reply-To: <1364879483-11144-1-git-send-email-horms+renesas@verge.net.au>
References: <1364879483-11144-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364879483-11144-2-git-send-email-horms+renesas@verge.net.au>

From: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>

Add basic Bock-W board support

More devices will be added on top of this patch after
PICNTRL and clock framework are in better shape.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Acked-by: Magnus Damm <damm at opensource.se>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/Makefile           |    1 +
 arch/arm/boot/dts/r8a7778-bockw.dts  |   32 +++++++++++++++++
 arch/arm/configs/bockw_defconfig     |   66 ++++++++++++++++++++++++++++++++++
 arch/arm/mach-shmobile/Kconfig       |    6 ++++
 arch/arm/mach-shmobile/Makefile      |    1 +
 arch/arm/mach-shmobile/board-bockw.c |   43 ++++++++++++++++++++++
 6 files changed, 149 insertions(+)
 create mode 100644 arch/arm/boot/dts/r8a7778-bockw.dts
 create mode 100644 arch/arm/configs/bockw_defconfig
 create mode 100644 arch/arm/mach-shmobile/board-bockw.c

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index ee9fbe4..363fa507 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -136,6 +136,7 @@ dtb-$(CONFIG_ARCH_U8500) += snowball.dtb \
 	ccu9540.dtb
 dtb-$(CONFIG_ARCH_SHMOBILE) += emev2-kzm9d.dtb \
 	r8a7740-armadillo800eva.dtb \
+	r8a7778-bockw.dtb \
 	r8a7779-marzen-reference.dtb \
 	sh73a0-kzm9g.dtb \
 	sh73a0-kzm9g-reference.dtb \
diff --git a/arch/arm/boot/dts/r8a7778-bockw.dts b/arch/arm/boot/dts/r8a7778-bockw.dts
new file mode 100644
index 0000000..735c964
--- /dev/null
+++ b/arch/arm/boot/dts/r8a7778-bockw.dts
@@ -0,0 +1,32 @@
+/*
+ * Reference Device Tree Source for the Bock-W board
+ *
+ * Copyright (C) 2013  Renesas Solutions Corp.
+ * Copyright (C) 2013  Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
+ *
+ * based on r8a7779
+ *
+ * Copyright (C) 2013 Renesas Solutions Corp.
+ * Copyright (C) 2013 Simon Horman
+ *
+ * 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.
+ */
+
+/dts-v1/;
+/include/ "r8a7778.dtsi"
+
+/ {
+	model = "bockw";
+	compatible = "renesas,bockw", "renesas,r8a7778";
+
+	chosen {
+		bootargs = "console=ttySC0,115200 ignore_loglevel";
+	};
+
+	memory {
+		device_type = "memory";
+		reg = <0x60000000 0x10000000>;
+	};
+};
diff --git a/arch/arm/configs/bockw_defconfig b/arch/arm/configs/bockw_defconfig
new file mode 100644
index 0000000..6037705
--- /dev/null
+++ b/arch/arm/configs/bockw_defconfig
@@ -0,0 +1,66 @@
+# CONFIG_ARM_PATCH_PHYS_VIRT is not set
+CONFIG_KERNEL_LZMA=y
+CONFIG_NO_HZ=y
+CONFIG_IKCONFIG=y
+CONFIG_IKCONFIG_PROC=y
+CONFIG_LOG_BUF_SHIFT=16
+CONFIG_SYSCTL_SYSCALL=y
+CONFIG_EMBEDDED=y
+CONFIG_SLAB=y
+# CONFIG_IOSCHED_CFQ is not set
+CONFIG_ARCH_SHMOBILE=y
+CONFIG_ARCH_R8A7778=y
+CONFIG_MACH_BOCKW=y
+CONFIG_MEMORY_START=0x60000000
+CONFIG_MEMORY_SIZE=0x10000000
+CONFIG_SHMOBILE_TIMER_HZ=1024
+# CONFIG_SH_TIMER_CMT is not set
+# CONFIG_EM_TIMER_STI is not set
+CONFIG_ARM_ERRATA_430973=y
+CONFIG_ARM_ERRATA_458693=y
+CONFIG_ARM_ERRATA_460075=y
+CONFIG_ARM_ERRATA_743622=y
+CONFIG_ARM_ERRATA_754322=y
+CONFIG_AEABI=y
+# CONFIG_OABI_COMPAT is not set
+CONFIG_HIGHMEM=y
+CONFIG_ZBOOT_ROM_TEXT=0x0
+CONFIG_ZBOOT_ROM_BSS=0x0
+CONFIG_ARM_APPENDED_DTB=y
+CONFIG_CMDLINE="console=ttySC0,115200 ignore_loglevel"
+CONFIG_CMDLINE_FORCE=y
+# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
+# CONFIG_SUSPEND is not set
+CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
+CONFIG_DEVTMPFS=y
+CONFIG_DEVTMPFS_MOUNT=y
+# CONFIG_STANDALONE is not set
+# CONFIG_PREVENT_FIRMWARE_BUILD is not set
+# CONFIG_FW_LOADER is not set
+# CONFIG_INPUT is not set
+# CONFIG_SERIO is not set
+# CONFIG_VT is not set
+# CONFIG_LEGACY_PTYS is not set
+# CONFIG_DEVKMEM is not set
+CONFIG_SERIAL_SH_SCI=y
+CONFIG_SERIAL_SH_SCI_NR_UARTS=6
+CONFIG_SERIAL_SH_SCI_CONSOLE=y
+# CONFIG_HW_RANDOM is not set
+# CONFIG_HWMON is not set
+# CONFIG_USB_SUPPORT is not set
+CONFIG_UIO=y
+CONFIG_UIO_PDRV_GENIRQ=y
+# CONFIG_IOMMU_SUPPORT is not set
+# CONFIG_DNOTIFY is not set
+# CONFIG_INOTIFY_USER is not set
+CONFIG_TMPFS=y
+# CONFIG_MISC_FILESYSTEMS is not set
+# CONFIG_ENABLE_WARN_DEPRECATED is not set
+# CONFIG_ENABLE_MUST_CHECK is not set
+# CONFIG_SCHED_DEBUG is not set
+# CONFIG_DEBUG_BUGVERBOSE is not set
+# CONFIG_FTRACE is not set
+# CONFIG_ARM_UNWIND is not set
+CONFIG_KEYS=y
+CONFIG_CRYPTO=y
+CONFIG_AVERAGE=y
diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index 3933a31..18712ad 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -124,6 +124,12 @@ config MACH_ARMADILLO800EVA
 	select SND_SOC_WM8978 if SND_SIMPLE_CARD
 	select USE_OF
 
+config MACH_BOCKW
+	bool "BOCK-W platform"
+	depends on ARCH_R8A7778
+	select ARCH_REQUIRE_GPIOLIB
+	select USE_OF
+
 config MACH_MARZEN
 	bool "MARZEN board"
 	depends on ARCH_R8A7779
diff --git a/arch/arm/mach-shmobile/Makefile b/arch/arm/mach-shmobile/Makefile
index 0c9a290..5eada96 100644
--- a/arch/arm/mach-shmobile/Makefile
+++ b/arch/arm/mach-shmobile/Makefile
@@ -40,6 +40,7 @@ obj-$(CONFIG_MACH_AG5EVM)	+= board-ag5evm.o
 obj-$(CONFIG_MACH_MACKEREL)	+= board-mackerel.o
 obj-$(CONFIG_MACH_KOTA2)	+= board-kota2.o
 obj-$(CONFIG_MACH_BONITO)	+= board-bonito.o
+obj-$(CONFIG_MACH_BOCKW)	+= board-bockw.o
 obj-$(CONFIG_MACH_MARZEN)	+= board-marzen.o
 obj-$(CONFIG_MACH_MARZEN_REFERENCE)	+= board-marzen-reference.o
 obj-$(CONFIG_MACH_ARMADILLO800EVA)	+= board-armadillo800eva.o
diff --git a/arch/arm/mach-shmobile/board-bockw.c b/arch/arm/mach-shmobile/board-bockw.c
new file mode 100644
index 0000000..56ab56e
--- /dev/null
+++ b/arch/arm/mach-shmobile/board-bockw.c
@@ -0,0 +1,43 @@
+/*
+ * Bock-W board support
+ *
+ * Copyright (C) 2013  Renesas Solutions Corp.
+ * Copyright (C) 2013  Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
+ *
+ * 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; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
+ */
+
+#include <linux/platform_device.h>
+#include <mach/common.h>
+#include <mach/r8a7778.h>
+#include <asm/mach/arch.h>
+
+static void __init bockw_init(void)
+{
+	r8a7778_clock_init();
+	r8a7778_add_standard_devices();
+}
+
+static const char *bockw_boards_compat_dt[] __initdata = {
+	"renesas,bockw",
+	NULL,
+};
+
+DT_MACHINE_START(BOCKW_DT, "bockw")
+	.init_early	= r8a7778_init_delay,
+	.init_irq	= r8a7778_init_irq_dt,
+	.init_machine	= bockw_init,
+	.init_time	= shmobile_timer_init,
+	.dt_compat	= bockw_boards_compat_dt,
+MACHINE_END
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 01:11:20 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue,  2 Apr 2013 14:11:20 +0900
Subject: [PATCH 08/11] ARM: shmobile: mackerel: remove OCR masks,
 where regulators are used
In-Reply-To: <1364879483-11144-1-git-send-email-horms+renesas@verge.net.au>
References: <1364879483-11144-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364879483-11144-9-git-send-email-horms+renesas@verge.net.au>

From: Guennadi Liakhovetski <g.liakhovetski at gmx.de>

Both SDHI and MMCIF drivers ignore their OCR platform values, when
available voltages can be retrieved from regulators.

Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas at gmail.com>
Acked-by: Magnus Damm <damm at opensource.se>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/board-mackerel.c |    2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/arm/mach-shmobile/board-mackerel.c b/arch/arm/mach-shmobile/board-mackerel.c
index c4f80d4..734565d 100644
--- a/arch/arm/mach-shmobile/board-mackerel.c
+++ b/arch/arm/mach-shmobile/board-mackerel.c
@@ -1014,7 +1014,6 @@ static struct platform_device sdhi0_device = {
 static struct sh_mobile_sdhi_info sdhi1_info = {
 	.dma_slave_tx	= SHDMA_SLAVE_SDHI1_TX,
 	.dma_slave_rx	= SHDMA_SLAVE_SDHI1_RX,
-	.tmio_ocr_mask	= MMC_VDD_165_195,
 	.tmio_flags	= TMIO_MMC_WRPROTECT_DISABLE,
 	.tmio_caps	= MMC_CAP_SD_HIGHSPEED | MMC_CAP_SDIO_IRQ |
 			  MMC_CAP_NEEDS_POLL,
@@ -1125,7 +1124,6 @@ static struct resource sh_mmcif_resources[] = {
 
 static struct sh_mmcif_plat_data sh_mmcif_plat = {
 	.sup_pclk	= 0,
-	.ocr		= MMC_VDD_165_195 | MMC_VDD_32_33 | MMC_VDD_33_34,
 	.caps		= MMC_CAP_4_BIT_DATA |
 			  MMC_CAP_8_BIT_DATA |
 			  MMC_CAP_NEEDS_POLL,
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 01:11:22 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue,  2 Apr 2013 14:11:22 +0900
Subject: [PATCH 10/11] ARM: shmobile: mackerel: add interrupt names for SDHI0
In-Reply-To: <1364879483-11144-1-git-send-email-horms+renesas@verge.net.au>
References: <1364879483-11144-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364879483-11144-11-git-send-email-horms+renesas@verge.net.au>

From: Guennadi Liakhovetski <g.liakhovetski at gmx.de>

To unify with SDHI1 also use named IRQs for SDHI0. This also clarifies
which specific IRQs are used.

Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas at gmail.com>
Acked-by: Magnus Damm <damm at opensource.se>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/board-mackerel.c |    9 ++-------
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/arch/arm/mach-shmobile/board-mackerel.c b/arch/arm/mach-shmobile/board-mackerel.c
index a47a1116..b976ad6 100644
--- a/arch/arm/mach-shmobile/board-mackerel.c
+++ b/arch/arm/mach-shmobile/board-mackerel.c
@@ -979,12 +979,11 @@ static struct resource sdhi0_resources[] = {
 		.end	= 0xe68500ff,
 		.flags	= IORESOURCE_MEM,
 	}, {
-		.start	= evt2irq(0x0e00) /* SDHI0_SDHI0I0 */,
-		.flags	= IORESOURCE_IRQ,
-	}, {
+		.name	= SH_MOBILE_SDHI_IRQ_SDCARD,
 		.start	= evt2irq(0x0e20) /* SDHI0_SDHI0I1 */,
 		.flags	= IORESOURCE_IRQ,
 	}, {
+		.name	= SH_MOBILE_SDHI_IRQ_SDIO,
 		.start	= evt2irq(0x0e40) /* SDHI0_SDHI0I2 */,
 		.flags	= IORESOURCE_IRQ,
 	},
@@ -1020,10 +1019,6 @@ static struct resource sdhi1_resources[] = {
 		.end	= 0xe68600ff,
 		.flags	= IORESOURCE_MEM,
 	}, {
-		.name	= SH_MOBILE_SDHI_IRQ_CARD_DETECT,
-		.start	= evt2irq(0x0e80), /* SDHI1_SDHI1I0 */
-		.flags	= IORESOURCE_IRQ,
-	}, {
 		.name	= SH_MOBILE_SDHI_IRQ_SDCARD,
 		.start	= evt2irq(0x0ea0), /* SDHI1_SDHI1I1 */
 		.flags	= IORESOURCE_IRQ,
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 01:11:21 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue,  2 Apr 2013 14:11:21 +0900
Subject: [PATCH 09/11] ARM: shmobile: mackerel: switch SDHI and MMCIF
 interfaces to slot-gpio
In-Reply-To: <1364879483-11144-1-git-send-email-horms+renesas@verge.net.au>
References: <1364879483-11144-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364879483-11144-10-git-send-email-horms+renesas@verge.net.au>

From: Guennadi Liakhovetski <g.liakhovetski at gmx.de>

Both SDHI and MMCIF drivers can use the standard slot-gpio card-detection
functions. Switch mackerel to using them instead of platform callbacks.

Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas at gmail.com>
Acked-by: Magnus Damm <damm at opensource.se>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/board-mackerel.c |   39 ++++++++++---------------------
 1 file changed, 12 insertions(+), 27 deletions(-)

diff --git a/arch/arm/mach-shmobile/board-mackerel.c b/arch/arm/mach-shmobile/board-mackerel.c
index 734565d..a47a1116 100644
--- a/arch/arm/mach-shmobile/board-mackerel.c
+++ b/arch/arm/mach-shmobile/board-mackerel.c
@@ -963,15 +963,6 @@ static struct platform_device nand_flash_device = {
 	},
 };
 
-/*
- * The card detect pin of the top SD/MMC slot (CN7) is active low and is
- * connected to GPIO A22 of SH7372 (GPIO 41).
- */
-static int slot_cn7_get_cd(struct platform_device *pdev)
-{
-	return !gpio_get_value(41);
-}
-
 /* SDHI0 */
 static struct sh_mobile_sdhi_info sdhi0_info = {
 	.dma_slave_tx	= SHDMA_SLAVE_SDHI0_TX,
@@ -1011,13 +1002,15 @@ static struct platform_device sdhi0_device = {
 
 #if !defined(CONFIG_MMC_SH_MMCIF) && !defined(CONFIG_MMC_SH_MMCIF_MODULE)
 /* SDHI1 */
+
+/* GPIO 41 can trigger IRQ8, but it is used by USBHS1, we have to poll */
 static struct sh_mobile_sdhi_info sdhi1_info = {
 	.dma_slave_tx	= SHDMA_SLAVE_SDHI1_TX,
 	.dma_slave_rx	= SHDMA_SLAVE_SDHI1_RX,
-	.tmio_flags	= TMIO_MMC_WRPROTECT_DISABLE,
+	.tmio_flags	= TMIO_MMC_WRPROTECT_DISABLE | TMIO_MMC_USE_GPIO_CD,
 	.tmio_caps	= MMC_CAP_SD_HIGHSPEED | MMC_CAP_SDIO_IRQ |
 			  MMC_CAP_NEEDS_POLL,
-	.get_cd		= slot_cn7_get_cd,
+	.cd_gpio	= 41,
 };
 
 static struct resource sdhi1_resources[] = {
@@ -1052,23 +1045,19 @@ static struct platform_device sdhi1_device = {
 };
 #endif
 
+/* SDHI2 */
+
 /*
  * The card detect pin of the top SD/MMC slot (CN23) is active low and is
- * connected to GPIO SCIFB_SCK of SH7372 (162).
+ * connected to GPIO SCIFB_SCK of SH7372 (GPIO 162).
  */
-static int slot_cn23_get_cd(struct platform_device *pdev)
-{
-	return !gpio_get_value(162);
-}
-
-/* SDHI2 */
 static struct sh_mobile_sdhi_info sdhi2_info = {
 	.dma_slave_tx	= SHDMA_SLAVE_SDHI2_TX,
 	.dma_slave_rx	= SHDMA_SLAVE_SDHI2_RX,
-	.tmio_flags	= TMIO_MMC_WRPROTECT_DISABLE,
+	.tmio_flags	= TMIO_MMC_WRPROTECT_DISABLE | TMIO_MMC_USE_GPIO_CD,
 	.tmio_caps	= MMC_CAP_SD_HIGHSPEED | MMC_CAP_SDIO_IRQ |
 			  MMC_CAP_NEEDS_POLL,
-	.get_cd		= slot_cn23_get_cd,
+	.cd_gpio	= 162,
 };
 
 static struct resource sdhi2_resources[] = {
@@ -1127,7 +1116,9 @@ static struct sh_mmcif_plat_data sh_mmcif_plat = {
 	.caps		= MMC_CAP_4_BIT_DATA |
 			  MMC_CAP_8_BIT_DATA |
 			  MMC_CAP_NEEDS_POLL,
-	.get_cd		= slot_cn7_get_cd,
+	.use_cd_gpio	= true,
+	/* card detect pin for SD/MMC slot (CN7) */
+	.cd_gpio	= 41,
 	.slave_id_tx	= SHDMA_SLAVE_MMCIF_TX,
 	.slave_id_rx	= SHDMA_SLAVE_MMCIF_RX,
 };
@@ -1475,12 +1466,6 @@ static void __init mackerel_init(void)
 	/* SDHI0 PORT172 card-detect IRQ26 */
 	gpio_request(GPIO_FN_IRQ26_172, NULL);
 
-	/* card detect pin for MMC slot (CN7) */
-	gpio_request_one(41, GPIOF_IN, NULL);
-
-	/* card detect pin for microSD slot (CN23) */
-	gpio_request_one(162, GPIOF_IN, NULL);
-
 	/* FLCTL */
 	gpio_request(GPIO_FN_D0_NAF0, NULL);
 	gpio_request(GPIO_FN_D1_NAF1, NULL);
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 01:11:18 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue,  2 Apr 2013 14:11:18 +0900
Subject: [PATCH 06/11] ARM: shmobile: Initial r8a7790 Lager board support
In-Reply-To: <1364879483-11144-1-git-send-email-horms+renesas@verge.net.au>
References: <1364879483-11144-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364879483-11144-7-git-send-email-horms+renesas@verge.net.au>

From: Magnus Damm <damm at opensource.se>

Lager base board support making use of 2 GiB of memory,
the r8a7790 SoC with the SCIF0 serial port and CA15 with
ARM architected timer.

Signed-off-by: Magnus Damm <damm at opensource.se>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/Makefile           |    1 +
 arch/arm/boot/dts/r8a7790-lager.dts  |   31 +++++++++++++++++++++++
 arch/arm/mach-shmobile/Kconfig       |    9 ++++++-
 arch/arm/mach-shmobile/Makefile      |    1 +
 arch/arm/mach-shmobile/board-lager.c |   46 ++++++++++++++++++++++++++++++++++
 5 files changed, 87 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/r8a7790-lager.dts
 create mode 100644 arch/arm/mach-shmobile/board-lager.c

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index a99b0f7..47b6be7 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -138,6 +138,7 @@ dtb-$(CONFIG_ARCH_SHMOBILE) += emev2-kzm9d.dtb \
 	r8a7740-armadillo800eva.dtb \
 	r8a7778-bockw.dtb \
 	r8a7779-marzen-reference.dtb \
+	r8a7790-lager.dtb \
 	sh73a0-kzm9g.dtb \
 	sh73a0-kzm9g-reference.dtb \
 	r8a73a4-ape6evm.dtb \
diff --git a/arch/arm/boot/dts/r8a7790-lager.dts b/arch/arm/boot/dts/r8a7790-lager.dts
new file mode 100644
index 0000000..09a84fc
--- /dev/null
+++ b/arch/arm/boot/dts/r8a7790-lager.dts
@@ -0,0 +1,31 @@
+/*
+ * Device Tree Source for the Lager board
+ *
+ * Copyright (C) 2013 Renesas Solutions Corp.
+ *
+ * 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.
+ */
+
+/dts-v1/;
+/include/ "r8a7790.dtsi"
+
+/ {
+	model = "Lager";
+	compatible = "renesas,lager", "renesas,r8a7790";
+
+	chosen {
+		bootargs = "console=ttySC6,115200 ignore_loglevel";
+	};
+
+	memory at 40000000 {
+		device_type = "memory";
+		reg = <0 0x40000000 0 0x80000000>;
+	};
+
+	lbsc {
+		#address-cells = <1>;
+		#size-cells = <1>;
+	};
+};
diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index c0da6af..549e059 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -154,6 +154,11 @@ config MACH_MARZEN_REFERENCE
 
 	   This is intended to aid developers
 
+config MACH_LAGER
+	bool "Lager board"
+	depends on ARCH_R8A7790
+	select USE_OF
+
 config MACH_KZM9D
 	bool "KZM9D board"
 	depends on ARCH_EMEV2
@@ -194,7 +199,8 @@ config MEMORY_START
 	hex "Physical memory start address"
 	default "0x40000000" if MACH_AP4EVB || MACH_AG5EVM || \
 				MACH_MACKEREL || MACH_BONITO || \
-				MACH_ARMADILLO800EVA || MACH_APE6EVM
+				MACH_ARMADILLO800EVA || MACH_APE6EVM || \
+				MACH_LAGER
 	default "0x41000000" if MACH_KOTA2
 	default "0x00000000"
 	---help---
@@ -204,6 +210,7 @@ config MEMORY_START
 
 config MEMORY_SIZE
 	hex "Physical memory size"
+	default "0x80000000" if MACH_LAGER
 	default "0x40000000" if MACH_APE6EVM
 	default "0x20000000" if MACH_AG5EVM || MACH_BONITO || \
 				MACH_ARMADILLO800EVA
diff --git a/arch/arm/mach-shmobile/Makefile b/arch/arm/mach-shmobile/Makefile
index ec2524e..068f1da 100644
--- a/arch/arm/mach-shmobile/Makefile
+++ b/arch/arm/mach-shmobile/Makefile
@@ -44,6 +44,7 @@ obj-$(CONFIG_MACH_BONITO)	+= board-bonito.o
 obj-$(CONFIG_MACH_BOCKW)	+= board-bockw.o
 obj-$(CONFIG_MACH_MARZEN)	+= board-marzen.o
 obj-$(CONFIG_MACH_MARZEN_REFERENCE)	+= board-marzen-reference.o
+obj-$(CONFIG_MACH_LAGER)	+= board-lager.o
 obj-$(CONFIG_MACH_ARMADILLO800EVA)	+= board-armadillo800eva.o
 obj-$(CONFIG_MACH_KZM9D)	+= board-kzm9d.o
 obj-$(CONFIG_MACH_KZM9G)	+= board-kzm9g.o
diff --git a/arch/arm/mach-shmobile/board-lager.c b/arch/arm/mach-shmobile/board-lager.c
new file mode 100644
index 0000000..ea6f9e5
--- /dev/null
+++ b/arch/arm/mach-shmobile/board-lager.c
@@ -0,0 +1,46 @@
+/*
+ * Lager board support
+ *
+ * Copyright (C) 2013  Renesas Solutions Corp.
+ * Copyright (C) 2013  Magnus Damm
+ *
+ * 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; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
+ */
+
+#include <linux/interrupt.h>
+#include <linux/irqchip.h>
+#include <linux/kernel.h>
+#include <linux/platform_device.h>
+#include <mach/common.h>
+#include <mach/r8a7790.h>
+#include <asm/mach-types.h>
+#include <asm/mach/arch.h>
+
+static void __init lager_add_standard_devices(void)
+{
+	r8a7790_clock_init();
+	r8a7790_add_standard_devices();
+}
+
+static const char *lager_boards_compat_dt[] __initdata = {
+	"renesas,lager",
+	NULL,
+};
+
+DT_MACHINE_START(LAGER_DT, "lager")
+	.init_irq	= irqchip_init,
+	.init_time	= shmobile_timer_init,
+	.init_machine	= lager_add_standard_devices,
+	.dt_compat	= lager_boards_compat_dt,
+MACHINE_END
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 01:11:23 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue,  2 Apr 2013 14:11:23 +0900
Subject: [PATCH 11/11] ARM: shmobile: mackerel: clean up MMCIF vs. SDHI1
 selection
In-Reply-To: <1364879483-11144-1-git-send-email-horms+renesas@verge.net.au>
References: <1364879483-11144-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364879483-11144-12-git-send-email-horms+renesas@verge.net.au>

From: Guennadi Liakhovetski <g.liakhovetski at gmx.de>

MMCIF and SDHI1 share the same slot on mackerel. One of them is selected
by a jumper, which cannot be queried from software. Currently in software
one of the two interfaces is selected, depending whether or not the MMCIF
driver is enabled. This is not optimal, since the kernel has to be rebuilt
to switch from one interface to another. Still, so far there isn't a
better option. At least make this selection consistent.

Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas at gmail.com>
Acked-by: Magnus Damm <damm at opensource.se>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/board-mackerel.c |   34 +++++++++++++++----------------
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/arch/arm/mach-shmobile/board-mackerel.c b/arch/arm/mach-shmobile/board-mackerel.c
index b976ad6..5b452e1 100644
--- a/arch/arm/mach-shmobile/board-mackerel.c
+++ b/arch/arm/mach-shmobile/board-mackerel.c
@@ -999,7 +999,7 @@ static struct platform_device sdhi0_device = {
 	},
 };
 
-#if !defined(CONFIG_MMC_SH_MMCIF) && !defined(CONFIG_MMC_SH_MMCIF_MODULE)
+#if !IS_ENABLED(CONFIG_MMC_SH_MMCIF)
 /* SDHI1 */
 
 /* GPIO 41 can trigger IRQ8, but it is used by USBHS1, we have to poll */
@@ -1062,10 +1062,6 @@ static struct resource sdhi2_resources[] = {
 		.end	= 0xe68700ff,
 		.flags	= IORESOURCE_MEM,
 	}, {
-		.name	= SH_MOBILE_SDHI_IRQ_CARD_DETECT,
-		.start	= evt2irq(0x1200), /* SDHI2_SDHI2I0 */
-		.flags	= IORESOURCE_IRQ,
-	}, {
 		.name	= SH_MOBILE_SDHI_IRQ_SDCARD,
 		.start	= evt2irq(0x1220), /* SDHI2_SDHI2I1 */
 		.flags	= IORESOURCE_IRQ,
@@ -1087,6 +1083,7 @@ static struct platform_device sdhi2_device = {
 };
 
 /* SH_MMCIF */
+#if IS_ENABLED(CONFIG_MMC_SH_MMCIF)
 static struct resource sh_mmcif_resources[] = {
 	[0] = {
 		.name	= "MMCIF",
@@ -1118,7 +1115,7 @@ static struct sh_mmcif_plat_data sh_mmcif_plat = {
 	.slave_id_rx	= SHDMA_SLAVE_MMCIF_RX,
 };
 
-static struct platform_device sh_mmcif_device __maybe_unused = {
+static struct platform_device sh_mmcif_device = {
 	.name		= "sh_mmcif",
 	.id		= 0,
 	.dev		= {
@@ -1129,7 +1126,7 @@ static struct platform_device sh_mmcif_device __maybe_unused = {
 	.num_resources	= ARRAY_SIZE(sh_mmcif_resources),
 	.resource	= sh_mmcif_resources,
 };
-
+#endif
 
 static int mackerel_camera_add(struct soc_camera_device *icd);
 static void mackerel_camera_del(struct soc_camera_device *icd);
@@ -1236,11 +1233,12 @@ static struct platform_device *mackerel_devices[] __initdata = {
 	&fsi_hdmi_device,
 	&nand_flash_device,
 	&sdhi0_device,
-#if !defined(CONFIG_MMC_SH_MMCIF) && !defined(CONFIG_MMC_SH_MMCIF_MODULE)
+#if !IS_ENABLED(CONFIG_MMC_SH_MMCIF)
 	&sdhi1_device,
+#else
+	&sh_mmcif_device,
 #endif
 	&sdhi2_device,
-	&sh_mmcif_device,
 	&ceu_device,
 	&mackerel_camera,
 	&hdmi_device,
@@ -1305,11 +1303,6 @@ static struct i2c_board_info i2c1_devices[] = {
 };
 
 static const struct pinctrl_map mackerel_pinctrl_map[] = {
-	/* MMCIF */
-	PIN_MAP_MUX_GROUP_DEFAULT("sh_mmcif.0", "pfc-sh7372",
-				  "mmc0_data8_0", "mmc0"),
-	PIN_MAP_MUX_GROUP_DEFAULT("sh_mmcif.0", "pfc-sh7372",
-				  "mmc0_ctrl_0", "mmc0"),
 	/* SDHI0 */
 	PIN_MAP_MUX_GROUP_DEFAULT("sh_mobile_sdhi.0", "pfc-sh7372",
 				  "sdhi0_data4", "sdhi0"),
@@ -1318,11 +1311,17 @@ static const struct pinctrl_map mackerel_pinctrl_map[] = {
 	PIN_MAP_MUX_GROUP_DEFAULT("sh_mobile_sdhi.0", "pfc-sh7372",
 				  "sdhi0_wp", "sdhi0"),
 	/* SDHI1 */
-#if !defined(CONFIG_MMC_SH_MMCIF) && !defined(CONFIG_MMC_SH_MMCIF_MODULE)
+#if !IS_ENABLED(CONFIG_MMC_SH_MMCIF)
 	PIN_MAP_MUX_GROUP_DEFAULT("sh_mobile_sdhi.1", "pfc-sh7372",
 				  "sdhi1_data4", "sdhi1"),
 	PIN_MAP_MUX_GROUP_DEFAULT("sh_mobile_sdhi.1", "pfc-sh7372",
 				  "sdhi1_ctrl", "sdhi1"),
+#else
+	/* MMCIF */
+	PIN_MAP_MUX_GROUP_DEFAULT("sh_mmcif.0", "pfc-sh7372",
+				  "mmc0_data8_0", "mmc0"),
+	PIN_MAP_MUX_GROUP_DEFAULT("sh_mmcif.0", "pfc-sh7372",
+				  "mmc0_ctrl_0", "mmc0"),
 #endif
 	/* SDHI2 */
 	PIN_MAP_MUX_GROUP_DEFAULT("sh_mobile_sdhi.2", "pfc-sh7372",
@@ -1347,10 +1346,11 @@ static void __init mackerel_init(void)
 		{ "A3SP", &usbhs0_device, },
 		{ "A3SP", &usbhs1_device, },
 		{ "A3SP", &nand_flash_device, },
-		{ "A3SP", &sh_mmcif_device, },
 		{ "A3SP", &sdhi0_device, },
-#if !defined(CONFIG_MMC_SH_MMCIF) && !defined(CONFIG_MMC_SH_MMCIF_MODULE)
+#if !IS_ENABLED(CONFIG_MMC_SH_MMCIF)
 		{ "A3SP", &sdhi1_device, },
+#else
+		{ "A3SP", &sh_mmcif_device, },
 #endif
 		{ "A3SP", &sdhi2_device, },
 		{ "A4R", &ceu_device, },
-- 
1.7.10.4



From rmallon at gmail.com  Tue Apr  2 01:34:07 2013
From: rmallon at gmail.com (Ryan Mallon)
Date: Tue, 02 Apr 2013 16:34:07 +1100
Subject: [PATCH 2/6] rtc: rtc-m48t86: add hooks to support driver side
 memory mapping
In-Reply-To: <1364858565-17192-3-git-send-email-alex@digriz.org.uk>
References: <1364858565-17192-1-git-send-email-alex@digriz.org.uk>
 <1364858565-17192-3-git-send-email-alex@digriz.org.uk>
Message-ID: <515A6DCF.1080902@gmail.com>

On 02/04/13 10:22, Alexander Clouter wrote:
> If platform_data is not defined (as before), then named memory io
> ranges need to be defined ("rtc_index" and "rtc_data").  The driver
> then maps those regions and uses them as the RTC index and data
> addresses.
> 
> Does compile with the following warnings, I cannot see the codepath
> affected myself:
> ----
> drivers/rtc/rtc-m48t86.c: In function ?m48t86_rtc_probe?:
> drivers/rtc/rtc-m48t86.c:180: warning: ?res_index? may be used uninitialized in this function
> drivers/rtc/rtc-m48t86.c:180: warning: ?res_data? may be used uninitialized in this function
> ----
> 
> Signed-off-by: Alexander Clouter <alex at digriz.org.uk>
> ---
>  drivers/rtc/rtc-m48t86.c |  230 ++++++++++++++++++++++++++++++++++------------
>  1 file changed, 173 insertions(+), 57 deletions(-)
> 
> diff --git a/drivers/rtc/rtc-m48t86.c b/drivers/rtc/rtc-m48t86.c
> index 25e0116..6f99e64 100644
> --- a/drivers/rtc/rtc-m48t86.c
> +++ b/drivers/rtc/rtc-m48t86.c
> @@ -18,6 +18,8 @@
>  #include <linux/platform_device.h>
>  #include <linux/platform_data/rtc-m48t86.h>
>  #include <linux/bcd.h>
> +#include <linux/slab.h>
> +#include <linux/io.h>
>  
>  #define M48T86_REG_SEC		0x00
>  #define M48T86_REG_SECALRM	0x01
> @@ -41,40 +43,71 @@
>  
>  #define DRV_VERSION "0.1"
>  
> +struct m48t86_rtc_private_data {
> +	void __iomem		*io_index;
> +	void __iomem		*io_data;
> +
> +	struct rtc_device	*rtc;
> +	struct m48t86_ops	*ops;
> +};
> +
> +static void m48t86_rtc_writebyte(struct device *dev,
> +			unsigned char value, unsigned long addr)
> +{
> +	struct m48t86_rtc_private_data *priv = dev_get_drvdata(dev);
> +
> +	if (priv->ops) {
> +		priv->ops->writebyte(value, addr);
> +		return;
> +	}
> +
> +	writeb(addr, priv->io_index);
> +	writeb(value, priv->io_data);
> +}
> +
> +static unsigned char m48t86_rtc_readbyte(struct device *dev,
> +			unsigned long addr)

The read/writebyte functions should return a u8 and take a u8 for the
address (since you are using readb/writeb). For the temporary step which
still has the ops structure, you can explicitly cast addr to unsigned
long if you want to make it obvious that the old api was silly.

~Ryan



From rmallon at gmail.com  Tue Apr  2 01:37:36 2013
From: rmallon at gmail.com (Ryan Mallon)
Date: Tue, 02 Apr 2013 16:37:36 +1100
Subject: [PATCH 2/6] rtc: rtc-m48t86: add hooks to support driver side
 memory mapping
In-Reply-To: <20130401234207.GL1953@edkhil>
References: <1364858565-17192-1-git-send-email-alex@digriz.org.uk>
 <1364858565-17192-3-git-send-email-alex@digriz.org.uk>
 <515A1A0B.8040803@gmail.com> <20130401234207.GL1953@edkhil>
Message-ID: <515A6EA0.1010700@gmail.com>

On 02/04/13 10:42, Alexander Clouter wrote:
> On Tue, Apr 02, 2013 at 10:36:43AM +1100, Ryan Mallon wrote:
>> On 02/04/13 10:22, Alexander Clouter wrote:
>>> If platform_data is not defined (as before), then named memory io
>>> ranges need to be defined ("rtc_index" and "rtc_data").  The driver
>>> then maps those regions and uses them as the RTC index and data
>>> addresses.
>>>
>>> Does compile with the following warnings, I cannot see the codepath
>>> affected myself:
>>> ----
>>> drivers/rtc/rtc-m48t86.c: In function ?m48t86_rtc_probe?:
>>> drivers/rtc/rtc-m48t86.c:180: warning: ?res_index? may be used
>>> uninitialized in this function
>>> drivers/rtc/rtc-m48t86.c:180: warning: ?res_data? may be used
>>> uninitialized in this function
>>
>> It is caused by the exit paths. If pdev->dev.platform_data is set, the
>> res_index and res_data are never initialised, but in the error case you
>> still for rtc_device_register you jump to out_io_data, which will then
>> dereference res_index/res_data. You need to make the exit paths
>> conditional on pdev->dev.platform_data (or init res_index/data to NULL
>> and make the release_mem_regions conditional on that).
> 
> However, the 'goto out_io_data' in the 'IS_ERR(priv->rtc)' is wrapped in
> a 'if (!pdev->dev.platform_data)', else we jump to out_free.

Ah right, I missed that. In that case, I can't see the problem either :-/.

> 
> I suspect I am probably missing something *too* obvious here for it to
> click?

It could be gcc being dumb, though this does seem a straight-forward
enough case for gcc to get it correct. It would be nice to get rid of
the warning though. Doing:

  struct resource *res_index = NULL; /* Avoid GCC warning */

Isn't too costly.

~Ryan



From Wenyou.Yang at atmel.com  Tue Apr  2 01:45:48 2013
From: Wenyou.Yang at atmel.com (Yang, Wenyou)
Date: Tue, 2 Apr 2013 05:45:48 +0000
Subject: [PATCH v7 08/14] spi/spi-atmel: fix spi-atmel driver to adapt
 to slave_config changes
In-Reply-To: <20130401135104.GZ18636@opensource.wolfsonmicro.com>
References: <1363678866-3567-1-git-send-email-wenyou.yang@atmel.com>
 <1363679236-3973-1-git-send-email-wenyou.yang@atmel.com>
 <20130401135104.GZ18636@opensource.wolfsonmicro.com>
Message-ID: <B256D81BAE5131468A838E5D7A24364150E8A2ED@penmbx01>

Hi, Mark,

> -----Original Message-----
> From: Mark Brown [mailto:broonie at opensource.wolfsonmicro.com]
> Sent: 2013?4?1? 21:51
> To: Yang, Wenyou
> Cc: linux-arm-kernel at lists.infradead.org; grant.likely at secretlab.ca;
> richard.genoud at gmail.com; plagnioj at jcrosoft.com; Ferre, Nicolas; Lin, JM;
> spi-devel-general at lists.sourceforge.net; linux-kernel at vger.kernel.org
> Subject: Re: [PATCH v7 08/14] spi/spi-atmel: fix spi-atmel driver to adapt to
> slave_config changes
> 
> On Tue, Mar 19, 2013 at 03:47:16PM +0800, Wenyou Yang wrote:
> > From: Richard Genoud <richard.genoud at gmail.com>
> >
> > This is the following of the patch
> > e2b35f3dbfc080f15b72834d08f04f0269dbe9be
> 
> What is this patch actually doing, shouldn't it be part of the previous commit?
> The changelog really ought to have a plain text version of the commit
> description too.
You are right, it isn't the part of the previous commit.
I will squash it into the dmaengine patch.

Best Regards,
Wenyou Yang

From Wenyou.Yang at atmel.com  Tue Apr  2 01:46:50 2013
From: Wenyou.Yang at atmel.com (Yang, Wenyou)
Date: Tue, 2 Apr 2013 05:46:50 +0000
Subject: [PATCH v7 10/14] spi/spi-atmel: correct 16 bits transfers with DMA
In-Reply-To: <20130401135359.GB18636@opensource.wolfsonmicro.com>
References: <1363678866-3567-1-git-send-email-wenyou.yang@atmel.com>
 <1363679341-4087-1-git-send-email-wenyou.yang@atmel.com>
 <20130401135359.GB18636@opensource.wolfsonmicro.com>
Message-ID: <B256D81BAE5131468A838E5D7A24364150E8B304@penmbx01>

Hi, Mark,

> -----Original Message-----
> From: Mark Brown [mailto:broonie at opensource.wolfsonmicro.com]
> Sent: 2013?4?1? 21:54
> To: Yang, Wenyou
> Cc: linux-arm-kernel at lists.infradead.org; grant.likely at secretlab.ca;
> richard.genoud at gmail.com; plagnioj at jcrosoft.com; Ferre, Nicolas; Lin, JM;
> spi-devel-general at lists.sourceforge.net; linux-kernel at vger.kernel.org
> Subject: Re: [PATCH v7 10/14] spi/spi-atmel: correct 16 bits transfers with DMA
> 
> On Tue, Mar 19, 2013 at 03:49:01PM +0800, Wenyou Yang wrote:
> > From: Richard Genoud <richard.genoud at gmail.com>
> >
> > Signed-off-by: Richard Genoud <richard.genoud at gmail.com>
> > Cc: spi-devel-general at lists.sourceforge.net
> > Cc: linux-kernel at vger.kernel.org
> > [wenyou.yang at atmel.com: submit the patch]
> > Signed-off-by: Wenyou Yang <wenyou.yang at atmel.com>
> 
> Shouldn't this be squashed into the dmaengine patch?
OK, I will squash it into the dmaengine patch

Best Regards,
Wenyou Yang

From Wenyou.Yang at atmel.com  Tue Apr  2 01:49:50 2013
From: Wenyou.Yang at atmel.com (Yang, Wenyou)
Date: Tue, 2 Apr 2013 05:49:50 +0000
Subject: [PATCH v7 03/14] spi/spi-atmel: add physical base address
In-Reply-To: <20130401134147.GV18636@opensource.wolfsonmicro.com>
References: <1363678866-3567-1-git-send-email-wenyou.yang@atmel.com>
 <1363679016-3761-1-git-send-email-wenyou.yang@atmel.com>
 <20130401134147.GV18636@opensource.wolfsonmicro.com>
Message-ID: <B256D81BAE5131468A838E5D7A24364150E8B33C@penmbx01>

Hi, Mark,

> -----Original Message-----
> From: Mark Brown [mailto:broonie at opensource.wolfsonmicro.com]
> Sent: 2013?4?1? 21:42
> To: Yang, Wenyou
> Cc: linux-arm-kernel at lists.infradead.org; grant.likely at secretlab.ca;
> richard.genoud at gmail.com; plagnioj at jcrosoft.com; Ferre, Nicolas; Lin, JM;
> spi-devel-general at lists.sourceforge.net; linux-kernel at vger.kernel.org
> Subject: Re: [PATCH v7 03/14] spi/spi-atmel: add physical base address
> 
> On Tue, Mar 19, 2013 at 03:43:36PM +0800, Wenyou Yang wrote:
> 
> > +++ b/drivers/spi/spi-atmel.c
> > @@ -196,6 +196,7 @@ struct atmel_spi_caps {  struct atmel_spi {
> >  	spinlock_t		lock;
> >
> > +	resource_size_t		phybase;
> >  	void __iomem		*regs;
> >  	int			irq;
> >  	struct clk		*clk;
> 
> This looks like the wrong type?

I double checked.

The type ' resource_size_t ' is defined in include/linux/ types.h as below,

typedef phys_addr_t resource_size_t;

I think it is OK.

Best Regards,
Wenyou Yang

From thomas.abraham at linaro.org  Tue Apr  2 02:09:59 2013
From: thomas.abraham at linaro.org (Thomas Abraham)
Date: Tue, 02 Apr 2013 11:39:59 +0530
Subject: [PATCH v2] mmc: dwmmc: let device core setup the default pin
 configuration
Message-ID: <1364882999-31670-1-git-send-email-thomas.abraham@linaro.org>

With device core now able to setup the default pin configuration,
the pin configuration code based on the deprecated Samsung specific
gpio bindings is removed.

Signed-off-by: Thomas Abraham <thomas.abraham at linaro.org>
Acked-by: Linus Walleij <linus.walleij at linaro.org>
Reviewed-by: Doug Anderson <dianders at chromium.org>
Tested-by: Doug Anderson <dianders at chromium.org>
---

Hi Doug, Seungwon,

I apologize for the delaying in following up on the review comment.
The setup_bus callback support has been removed in this patch. I did
intend to retain the support for setup_bus callback in the previous
version of this patch since any new platform that might use this
driver and need such a callback would have this callback ready for
use. But it seems removing the setup_bus callback is preferred, so
I am fine with it.

Thomas.

 drivers/mmc/host/dw_mmc-exynos.c |   38 --------------------------------------
 drivers/mmc/host/dw_mmc.c        |   14 +-------------
 drivers/mmc/host/dw_mmc.h        |    3 ---
 3 files changed, 1 insertions(+), 54 deletions(-)

diff --git a/drivers/mmc/host/dw_mmc-exynos.c b/drivers/mmc/host/dw_mmc-exynos.c
index 72fd0f2..467d043 100644
--- a/drivers/mmc/host/dw_mmc-exynos.c
+++ b/drivers/mmc/host/dw_mmc-exynos.c
@@ -152,43 +152,6 @@ static int dw_mci_exynos_parse_dt(struct dw_mci *host)
 	return 0;
 }
 
-static int dw_mci_exynos_setup_bus(struct dw_mci *host,
-				struct device_node *slot_np, u8 bus_width)
-{
-	int idx, gpio, ret;
-
-	if (!slot_np)
-		return -EINVAL;
-
-	/* cmd + clock + bus-width pins */
-	for (idx = 0; idx < NUM_PINS(bus_width); idx++) {
-		gpio = of_get_gpio(slot_np, idx);
-		if (!gpio_is_valid(gpio)) {
-			dev_err(host->dev, "invalid gpio: %d\n", gpio);
-			return -EINVAL;
-		}
-
-		ret = devm_gpio_request(host->dev, gpio, "dw-mci-bus");
-		if (ret) {
-			dev_err(host->dev, "gpio [%d] request failed\n", gpio);
-			return -EBUSY;
-		}
-	}
-
-	if (host->pdata->quirks & DW_MCI_QUIRK_BROKEN_CARD_DETECTION)
-		return 0;
-
-	gpio = of_get_named_gpio(slot_np, "samsung,cd-pinmux-gpio", 0);
-	if (gpio_is_valid(gpio)) {
-		if (devm_gpio_request(host->dev, gpio, "dw-mci-cd"))
-			dev_err(host->dev, "gpio [%d] request failed\n", gpio);
-	} else {
-		dev_info(host->dev, "cd gpio not available");
-	}
-
-	return 0;
-}
-
 /* Exynos5250 controller specific capabilities */
 static unsigned long exynos5250_dwmmc_caps[4] = {
 	MMC_CAP_UHS_DDR50 | MMC_CAP_1_8V_DDR |
@@ -205,7 +168,6 @@ static const struct dw_mci_drv_data exynos5250_drv_data = {
 	.prepare_command	= dw_mci_exynos_prepare_command,
 	.set_ios		= dw_mci_exynos_set_ios,
 	.parse_dt		= dw_mci_exynos_parse_dt,
-	.setup_bus		= dw_mci_exynos_setup_bus,
 };
 
 static const struct of_device_id dw_mci_exynos_match[] = {
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 9834221..adb1b7d 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -1878,7 +1878,7 @@ static int dw_mci_init_slot(struct dw_mci *host, unsigned int id)
 	struct mmc_host *mmc;
 	struct dw_mci_slot *slot;
 	const struct dw_mci_drv_data *drv_data = host->drv_data;
-	int ctrl_id, ret;
+	int ctrl_id;
 	u8 bus_width;
 
 	mmc = mmc_alloc_host(sizeof(struct dw_mci_slot), host->dev);
@@ -1935,14 +1935,6 @@ static int dw_mci_init_slot(struct dw_mci *host, unsigned int id)
 	else
 		bus_width = 1;
 
-	if (drv_data && drv_data->setup_bus) {
-		struct device_node *slot_np;
-		slot_np = dw_mci_of_find_slot_node(host->dev, slot->id);
-		ret = drv_data->setup_bus(host, slot_np, bus_width);
-		if (ret)
-			goto err_setup_bus;
-	}
-
 	switch (bus_width) {
 	case 8:
 		mmc->caps |= MMC_CAP_8_BIT_DATA;
@@ -2006,10 +1998,6 @@ static int dw_mci_init_slot(struct dw_mci *host, unsigned int id)
 	queue_work(host->card_workqueue, &host->card_work);
 
 	return 0;
-
-err_setup_bus:
-	mmc_free_host(mmc);
-	return -EINVAL;
 }
 
 static void dw_mci_cleanup_slot(struct dw_mci_slot *slot, unsigned int id)
diff --git a/drivers/mmc/host/dw_mmc.h b/drivers/mmc/host/dw_mmc.h
index 53b8fd9..0b74189 100644
--- a/drivers/mmc/host/dw_mmc.h
+++ b/drivers/mmc/host/dw_mmc.h
@@ -190,7 +190,6 @@ extern int dw_mci_resume(struct dw_mci *host);
  * @prepare_command: handle CMD register extensions.
  * @set_ios: handle bus specific extensions.
  * @parse_dt: parse implementation specific device tree properties.
- * @setup_bus: initialize io-interface
  *
  * Provide controller implementation specific extensions. The usage of this
  * data structure is fully optional and usage of each member in this structure
@@ -203,7 +202,5 @@ struct dw_mci_drv_data {
 	void		(*prepare_command)(struct dw_mci *host, u32 *cmdr);
 	void		(*set_ios)(struct dw_mci *host, struct mmc_ios *ios);
 	int		(*parse_dt)(struct dw_mci *host);
-	int		(*setup_bus)(struct dw_mci *host,
-				struct device_node *slot_np, u8 bus_width);
 };
 #endif /* _DW_MMC_H_ */
-- 
1.6.6.rc2



From marex at denx.de  Tue Apr  2 02:04:02 2013
From: marex at denx.de (Marek Vasut)
Date: Tue,  2 Apr 2013 08:04:02 +0200
Subject: [PATCH] pinctrl: imx5: fix SD2_DATA1 pad AUDMUX_AUD4 configuration
Message-ID: <1364882642-25574-1-git-send-email-marex@denx.de>

The IOMUXC_AUDMUX_P4_INPUT_TXCLK_AMX_SELECT_INPUT must be configured as 1
instead of 0 to have AUD4 muxed on SD2 pins working.

Signed-off-by: Marek Vasut <marex at denx.de>
Cc: Fabio Estevam <fabio.estevam at freescale.com>
Cc: Linus Walleij <linus.walleij at linaro.org>
Cc: Philipp Zabel <p.zabel at pengutronix.de>
Cc: Shawn Guo <shawn.guo at linaro.org>
---
 drivers/pinctrl/pinctrl-imx53.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

NOTE: Shawn, we might want this in -stable too ?

diff --git a/drivers/pinctrl/pinctrl-imx53.c b/drivers/pinctrl/pinctrl-imx53.c
index 2c9c8e2..85f401c 100644
--- a/drivers/pinctrl/pinctrl-imx53.c
+++ b/drivers/pinctrl/pinctrl-imx53.c
@@ -1287,7 +1287,7 @@ static struct imx_pin_reg imx53_pin_regs[] = {
 	IMX_PIN_REG(MX53_PAD_SD2_DATA1, 0x698, 0x30C, 0, 0x000, 0), /* MX53_PAD_SD2_DATA1__ESDHC2_DAT1 */
 	IMX_PIN_REG(MX53_PAD_SD2_DATA1, 0x698, 0x30C, 1, 0x000, 0), /* MX53_PAD_SD2_DATA1__GPIO1_14 */
 	IMX_PIN_REG(MX53_PAD_SD2_DATA1, 0x698, 0x30C, 2, 0x848, 1), /* MX53_PAD_SD2_DATA1__KPP_COL_7 */
-	IMX_PIN_REG(MX53_PAD_SD2_DATA1, 0x698, 0x30C, 3, 0x744, 0), /* MX53_PAD_SD2_DATA1__AUDMUX_AUD4_TXFS */
+	IMX_PIN_REG(MX53_PAD_SD2_DATA1, 0x698, 0x30C, 3, 0x744, 1), /* MX53_PAD_SD2_DATA1__AUDMUX_AUD4_TXFS */
 	IMX_PIN_REG(MX53_PAD_SD2_DATA1, 0x698, 0x30C, 5, 0x78C, 4), /* MX53_PAD_SD2_DATA1__CSPI_SS0 */
 	IMX_PIN_REG(MX53_PAD_SD2_DATA1, 0x698, 0x30C, 7, 0x000, 0), /* MX53_PAD_SD2_DATA1__RTIC_SEC_VIO */
 	IMX_PIN_REG(MX53_PAD_SD2_DATA0, 0x69C, 0x310, 0, 0x000, 0), /* MX53_PAD_SD2_DATA0__ESDHC2_DAT0 */
-- 
1.7.10.4



From Wenyou.Yang at atmel.com  Tue Apr  2 02:17:06 2013
From: Wenyou.Yang at atmel.com (Yang, Wenyou)
Date: Tue, 2 Apr 2013 06:17:06 +0000
Subject: [PATCH v7 03/14] spi/spi-atmel: add physical base address
References: <1363678866-3567-1-git-send-email-wenyou.yang@atmel.com>
 <1363679016-3761-1-git-send-email-wenyou.yang@atmel.com>
 <20130401134147.GV18636@opensource.wolfsonmicro.com> 
Message-ID: <B256D81BAE5131468A838E5D7A24364150E8B3B7@penmbx01>

Hi, Mark,

> -----Original Message-----
> From: Yang, Wenyou
> Sent: 2013?4?2? 13:50
> To: 'Mark Brown'
> Cc: linux-arm-kernel at lists.infradead.org; grant.likely at secretlab.ca;
> richard.genoud at gmail.com; plagnioj at jcrosoft.com; Ferre, Nicolas; Lin, JM;
> spi-devel-general at lists.sourceforge.net; linux-kernel at vger.kernel.org
> Subject: RE: [PATCH v7 03/14] spi/spi-atmel: add physical base address
> 
> Hi, Mark,
> 
> > -----Original Message-----
> > From: Mark Brown [mailto:broonie at opensource.wolfsonmicro.com]
> > Sent: 2013?4?1? 21:42
> > To: Yang, Wenyou
> > Cc: linux-arm-kernel at lists.infradead.org; grant.likely at secretlab.ca;
> > richard.genoud at gmail.com; plagnioj at jcrosoft.com; Ferre, Nicolas; Lin, JM;
> > spi-devel-general at lists.sourceforge.net; linux-kernel at vger.kernel.org
> > Subject: Re: [PATCH v7 03/14] spi/spi-atmel: add physical base address
> >
> > On Tue, Mar 19, 2013 at 03:43:36PM +0800, Wenyou Yang wrote:
> >
> > > +++ b/drivers/spi/spi-atmel.c
> > > @@ -196,6 +196,7 @@ struct atmel_spi_caps {  struct atmel_spi {
> > >  	spinlock_t		lock;
> > >
> > > +	resource_size_t		phybase;
> > >  	void __iomem		*regs;
> > >  	int			irq;
> > >  	struct clk		*clk;
> >
> > This looks like the wrong type?
> 
I got it, you are right, you mean It should be used " phys_addr_t " type.

	phys_addr_t	phybase;

Thanks.

Best Regards,
Wenyou Yang.

> I double checked.
> 
> The type ' resource_size_t ' is defined in include/linux/ types.h as below,
> 
> typedef phys_addr_t resource_size_t;
> 
> I think it is OK.
> 
> Best Regards,
> Wenyou Yang

From santosh.shilimkar at ti.com  Tue Apr  2 02:19:54 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Tue, 2 Apr 2013 11:49:54 +0530
Subject: [GIT PULL] ARM: OMAP5: Generic updates and es2 fixes for 3.10
In-Reply-To: <20130401164746.GH10155@atomide.com>
References: <1363768822-18084-1-git-send-email-santosh.shilimkar@ti.com>
 <20130401164746.GH10155@atomide.com>
Message-ID: <515A788A.1050601@ti.com>

On Monday 01 April 2013 10:17 PM, Tony Lindgren wrote:
> * Santosh Shilimkar <santosh.shilimkar at ti.com> [130320 01:42]:
>> Tony,
>>
>> Here is the pull request for various OMAP5 generic updates which are posted
>> earlier on the list. It contains OMAP5 es2 related updates like idcode,
>> RAM base and couple of initialisation fixes.
>>
>> The following changes since commit a937536b868b8369b98967929045f1df54234323:
>>
>>   Linux 3.9-rc3 (2013-03-17 15:59:32 -0700)
>>
>> are available in the git repository at:
>>
>>   git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux.git for_3.10/omap5_generic_updates
>>
>> for you to fetch changes up to ecf51648c192377ea2830101b12fc3017bfd2b0c:
>>
>>   ARM: OMAP5: clock: No Freqsel on OMAP5 devices too (2013-03-19 12:57:03 +0530)
> 
> Thanks pulling into omap-for-v3.10/fixes-non-critical.
> 
Thanks Tony !!



From santosh.shilimkar at ti.com  Tue Apr  2 02:22:03 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Tue, 2 Apr 2013 11:52:03 +0530
Subject: [GIT PULL] ARM: OMAP2+: Serial driver sysc cleanup for 3.10
In-Reply-To: <20130401170148.GJ10155@atomide.com>
References: <1363768601-17862-1-git-send-email-santosh.shilimkar@ti.com>
 <20130401170148.GJ10155@atomide.com>
Message-ID: <515A790B.60301@ti.com>

On Monday 01 April 2013 10:31 PM, Tony Lindgren wrote:
> * Santosh Shilimkar <santosh.shilimkar at ti.com> [130320 01:39]:
>> Tony,
>>
>> Here is the pull request for OMAP serial driver sysconfig cleanup. The series
>> removes all the hackery of sysconfig from UART driver and let runtime backend
>> handle it. Without this series serial console is almost un-usable on OMAP5.
>> One of the patch touches driver/serial but I got an ack from Greg KH to get
>> it queued via OMAP tree.
>>
>>
>> The following changes since commit a937536b868b8369b98967929045f1df54234323:
>>
>>   Linux 3.9-rc3 (2013-03-17 15:59:32 -0700)
>>
>> are available in the git repository at:
>>
>>   git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux.git for_3.10/omap_serial_sysc_cleanup
>>
>> for you to fetch changes up to 0f78c88b107a25561d0830c7fb695134ac7e8892:
>>
>>   ARM: OMAP2+: hwmod: Remove sysc slave idle and auto idle apis (2013-03-19 12:07:49 +0530)
> 
> Looks like Paul had some comments and has applied some of these,
> so ignoring this one for now.
> 
Paul is picked one patch for now. Hope we can quickly sort out this for
merge window.

Regards,
Santosh



From david at gibson.dropbear.id.au  Tue Apr  2 02:17:47 2013
From: david at gibson.dropbear.id.au (David Gibson)
Date: Tue, 2 Apr 2013 17:17:47 +1100
Subject: How to represent negative values for device tree property
In-Reply-To: <5159F760.1080605@codeaurora.org>
References: <5159F760.1080605@codeaurora.org>
Message-ID: <20130402061747.GI7426@truffula.fritz.box>

On Mon, Apr 01, 2013 at 02:08:48PM -0700, David Collins wrote:
> Hi,
> 
> I am working on a thermal driver which needs to be able to read a
> temperature threshold from a device tree property.  The hardware supports
> thresholds in the range -204.8 to +204.7 C in 0.1 C steps.  I have found,
> as I am sure others have as well, that dtc treats a '-' before an integer
> in a dtsi file as a syntax error.  Therefore, I need some artificial way
> to represent negative numbers in device tree.  Here are the possibilities
> that I have thought of so far:

So, as a later posted suggests, dtc does now have integer expression
support, including unary -.  The catch is you have to put your
expression in parentheses, so < (-200) > should work where < -200 >
does not.  The reason for this is that otherwise something like
	<500 -300>
is ambiguous.  It could either mean <(500 -300)> == <200> or it could
mean <(500) (-300)>.

It's a bit of a pain, but there's not really any way of fixing it that
doesn't cause more pain along the way.

Well.. while writing that I realised its a bit more complicated.  We
could allow negative literals (similar but different in parsing from
unary -).  But that causes lexing/parsing problems since then
(500-300) (no spaces) would, without extra fiddling, get lexed as:
	"(" LITERAL(500) LITERAL(-300) ")"
whereas the parser would need to see it as
	"(" LITERAL(500) "-" LITERAL(300) ")"
So, maybe there's a way but I haven't thought of it yet.


> 1. Use a second integer to specify the sign of the threshold:
>      20000 mC --> <0 20000>
>     -20000 mC --> <1 20000>
> 2. Use a string instead of an integer to specify the threshold and
>    then convert it to an integer in the driver software:
>      20000 mC --> "20000"
>     -20000 mC --> "-20000"
> 3. Use units of millikelvin instead of millicelcius.  0 mC == 273150 mK
>      20000 mC --> <293150>
>     -20000 mC --> <253150>

There's always something to be said for using SI units, regardless of
any other considerations.

> 4. Use an arbitrary offset e.g. 0 mC == 1000000
>      20000 mC --> <1020000>
>     -20000 mC --> <980000>
> 5. Use the unsigned 32-bit representation for 2?s-compliment
>    signed 32-bit integer
>      20000 mC --> <20000>
>     -20000 mC --> <0xffffb1e0> or <4294947296>

This is effectively what use of unary - in dtc will do.

> Which of these options would you recommend using?  Is there any better way
> to handle negative values that I haven?t listed?  What is the best general
> case solution for specifying negative numbers in device tree?

In short both (3) and (5) are reasonable, and dtc will help you with
(5).  For the love of god, don't do (1), (2) or (4).

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130402/10434b1e/attachment-0001.sig>

From david at gibson.dropbear.id.au  Tue Apr  2 02:29:25 2013
From: david at gibson.dropbear.id.au (David Gibson)
Date: Tue, 2 Apr 2013 17:29:25 +1100
Subject: How to represent negative values for device tree property
In-Reply-To: <515A2533.8050005@codeaurora.org>
References: <5159F760.1080605@codeaurora.org> <515A038F.2090902@wwwdotorg.org>
 <515A2533.8050005@codeaurora.org>
Message-ID: <20130402062925.GJ7426@truffula.fritz.box>

On Mon, Apr 01, 2013 at 05:24:19PM -0700, David Collins wrote:
> On 04/01/2013 03:00 PM, Stephen Warren wrote:
> > On 04/01/2013 03:08 PM, David Collins wrote:
> >> Hi,
> >>
> >> I am working on a thermal driver which needs to be able to read a
> >> temperature threshold from a device tree property.  The hardware supports
> >> thresholds in the range -204.8 to +204.7 C in 0.1 C steps.  I have found,
> >> as I am sure others have as well, that dtc treats a '-' before an integer
> >> in a dtsi file as a syntax error.  Therefore, I need some artificial way
> >> to represent negative numbers in device tree.  Here are the possibilities
> >> that I have thought of so far:
> > 
> > Doesn't the very latest dtc, which contains integer expression support,
> > allow unary -? I thought that code had been imported into the kernel
> > (goes and checks) yes it has. What's the error you're seeing;
> > over/underflow or syntax?
> > 
> > That said, DT cells are supposed to be u32 not s32, so perhaps this
> > isn't unexpected.

That's.. sort of true, but misleading.  As far as the dtb format is
concerned, properties are just a bag of bytes.  Individual device
bindings define how software should interpret those bytes.

The dtc data "types" are really just convenient ways to enter various
sorts of commonly used bytestrings.  Some of the dtc code treats cells
as u32 because that works for its purposes (and in particular avoids
some nasty C standard gotchas where signed overflows may have
undefined results), but there's no reason you can't treat it as an
s32.  On dtc versions recent enough to have arithmetic, unary minus
and subtractive overflow will use 2's complement, as you'd expect.

> It is likely that my dtc version is out of date.  dtc -v outputs 1.2.0.  I
> will try updating to a newer version of dtc.  The error that I currently
> get is a syntax error: "FATAL ERROR: Unable to parse input tree".
> 
> Does the device tree binary documentation define any format for negative
> numbers?  Unsigned 32-bit integers are clearly defined as bytes in
> big-endian order.  I suppose that you could assume 32-bit signed integers
> are 2's complement with bytes in big-endian order, but that would need to
> be well defined somewhere.

Yes, it should be defined somewhere, but that only needs to be the
binding for your specific device, not anywhere more general.

> Assuming that dtb has no well defined means of holding a negative integer
> value, then what is the most elegant workaround to specify a negative value?

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130402/d6b9d463/attachment.sig>

From sfr at canb.auug.org.au  Tue Apr  2 02:55:57 2013
From: sfr at canb.auug.org.au (Stephen Rothwell)
Date: Tue, 2 Apr 2013 17:55:57 +1100
Subject: linux-next: manual merge of the imx-mxs tree with the arm-soc tree
Message-ID: <20130402175557.e44f384205d2d32dcd95be1d@canb.auug.org.au>

Hi Shawn,

Today's linux-next merge of the imx-mxs tree got a conflict in
arch/arm/Kconfig.debug between commit 266c347924f5 ("ARM: nomadik: move
debugmacro to debug includes") from the arm-soc tree and commit
11c6f861cf3a ("ARM: mxs: rename debug-macro.S for multiplatform build")
from the imx-mxs tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr at canb.auug.org.au

diff --cc arch/arm/Kconfig.debug
index d212ae0,057601e..0000000
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@@ -611,10 -591,9 +611,11 @@@ config DEBUG_LL_INCLUD
  				 DEBUG_IMX6Q_UART
  	default "debug/highbank.S" if DEBUG_HIGHBANK_UART
  	default "debug/mvebu.S" if DEBUG_MVEBU_UART
 +	default "debug/nomadik.S" if DEBUG_NOMADIK_UART
+ 	default "debug/mxs.S" if DEBUG_IMX23_UART || DEBUG_IMX28_UART
  	default "debug/omap2plus.S" if DEBUG_OMAP2PLUS_UART
  	default "debug/picoxcell.S" if DEBUG_PICOXCELL_UART
 +	default "debug/sirf.S" if DEBUG_SIRFPRIMA2_UART1 || DEBUG_SIRFMARCO_UART1
  	default "debug/socfpga.S" if DEBUG_SOCFPGA_UART
  	default "debug/sunxi.S" if DEBUG_SUNXI_UART0 || DEBUG_SUNXI_UART1
  	default "debug/vexpress.S" if DEBUG_VEXPRESS_UART0_DETECT || \
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130402/a3f6c36b/attachment.sig>

From sfr at canb.auug.org.au  Tue Apr  2 02:57:52 2013
From: sfr at canb.auug.org.au (Stephen Rothwell)
Date: Tue, 2 Apr 2013 17:57:52 +1100
Subject: linux-next: manual merge of the imx-mxs tree with the arm-soc tree
Message-ID: <20130402175752.b6ff90247b873b67111d31ad@canb.auug.org.au>

Hi Shawn,

Today's linux-next merge of the imx-mxs tree got a conflict in
drivers/clocksource/Makefile between commit 275786b71d42 ("ARM: sirf: use
clocksource_of infrastructure") from the arm-soc tree and commit
c74512bf83f3 ("ARM: mxs: move timer driver into drivers/clocksource")
from the imx-mxs tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr at canb.auug.org.au

diff --cc drivers/clocksource/Makefile
index 5e2176f,89c5adc..0000000
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@@ -16,8 -16,7 +16,9 @@@ obj-$(CONFIG_CLKSRC_NOMADIK_MTU)	+= nom
  obj-$(CONFIG_CLKSRC_DBX500_PRCMU)	+= clksrc-dbx500-prcmu.o
  obj-$(CONFIG_ARMADA_370_XP_TIMER)	+= time-armada-370-xp.o
  obj-$(CONFIG_ARCH_BCM2835)	+= bcm2835_timer.o
 +obj-$(CONFIG_ARCH_MARCO)	+= timer-marco.o
 +obj-$(CONFIG_ARCH_PRIMA2)	+= timer-prima2.o
+ obj-$(CONFIG_ARCH_MXS)		+= mxs_timer.o
  obj-$(CONFIG_SUNXI_TIMER)	+= sunxi_timer.o
  obj-$(CONFIG_ARCH_TEGRA)	+= tegra20_timer.o
  obj-$(CONFIG_VT8500_TIMER)	+= vt8500_timer.o
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130402/011cc601/attachment.sig>

From tpiepho at gmail.com  Tue Apr  2 03:11:11 2013
From: tpiepho at gmail.com (Trent Piepho)
Date: Tue, 2 Apr 2013 00:11:11 -0700
Subject: [PATCH 1/5] spi/mxs: Fix extra CS pulses and read mode in
 multi-transfer messages
In-Reply-To: <201304020622.52429.marex@denx.de>
References: <1364570381-17605-1-git-send-email-tpiepho@gmail.com>
 <201304020111.13969.marex@denx.de>
 <CA+7tXigx=qcDDJZGAx7JEX+Y-CDG-B0xyYgs6fHbUZofH7gnKw@mail.gmail.com>
 <201304020622.52429.marex@denx.de>
Message-ID: <CA+7tXigvg+5k0Baa12CVwP5Ar7HUsJ8ihB19xrav4CNA6ZMFiA@mail.gmail.com>

On Mon, Apr 1, 2013 at 9:22 PM, Marek Vasut <marex at denx.de> wrote:
>> On Mon, Apr 1, 2013 at 4:11 PM, Marek Vasut <marex at denx.de> wrote:
>> >> +#define TXRX_WRITE           1       /* This is a write */
>> >> +#define TXRX_DEASSERT_CS     2       /* De-assert CS at end of txrx */
>
> btw. is it necessary to define new flags or is it possible to reuse some?

I don't see any others that would make sense.  The driver doesn't
define any flags at all.  The spi layer doesn't have ones that match.
And this is for a private static interface inside the driver.  It
wouldn't be right to co-opt flags defined for some other purpose.

>> >>       ctrl0 = readl(ssp->base + HW_SSP_CTRL0);
>> >>
>> >> -     ctrl0 &= ~BM_SSP_CTRL0_XFER_COUNT;
>> >> +     ctrl0 &= ~BM_SSP_CTRL0_XFER_COUNT & ~BM_SSP_CTRL0_IGNORE_CRC &
>> >> +              ~BM_SSP_CTRL0_READ;
>> >
>> > Well ... ctrl0 &= ~(FOO | BAR | BAZ); ... won't cut it?
>>
>> Well, by De Morgan's law the two expressions are the same.  And they
>> are the same number of characters.  And both will produce a compile
>> time constant and thus the same code.  However, I like the ~FOO & ~BAR
>> & ~BAR form better as there is greater parallelism between each term
>> of the expression.
>
> What about the law of readability of code ? ;-)

Don't see anything in CodingStyle that one should be preferred over
the other.  I think this way is more readable than the other.
Generally you can think of masking off bits via bitwise-and and
setting bits with bitwise-or.  So if you want to do a sequence of
masks, then using a sequence of bitwise-ands is the most readable and
straightforward code IMHO.  Combing bits to mask with bitwise-or, then
inverting the set and masking with that seems like a less clear way of
doing the same thing.  And this way the existing tokens aren't
modified, so there is less churn!

>> The DMA does write
>> ctrl0 on each segment of each transfer, but look at the previous
>> paragraph to see where it comes from.  Once READ or IGNORE_CRC are
>> set, nothing will clear them until PIO mode is used.
>
> When using a flash, the DMA and PIO mode usage is intermixed. Usually, the PIO
> is used to program the command and then DMA to transmit the payload. It's hardly
> ever PIO only orr DMA only for the whole transfer.

Probably why the problem hasn't been noticed.  It's obvious from a
cursory examination of the driver that bits in ctrl0 are only SET in
the DMA code, never cleared.  The PIO code does clear them.

>> It's the same
>> with the bug fix for 3.9 that clears the XFER_COUNT bits in DMA mode.
>> Strangely, I didn't notice that bug since all my xfers are the same
>> length!  But I do switch between slaves, between read and write, and
>> use messages with multiple transfers, in DMA mode, all of which are
>> broken in the current driver.
>
> btw. are you using MX23 or MX28 to test this?

IMX28.

>> Existing code that uses the first/last flags is wrong and needs to be
>> changed.  Therefor code using 'first' and 'last' will be changed.
>>
>> Passing the flags as pointers is bad practice and makes no sense to
>> do.  Does it make any sense to re-write code fix the way it uses first
>> and last, then re-write those same lines a second time to not use
>> pointers?
>
> You can always flip it the other way -- first rework the use of flags, then
> apply the fix. It'd make the patch much easier to understand, don't you think?

So I should change 'first' to not be a pointer to an integer in one
patch, then delete the flag entirely in another patch?  What's the
point of changing code just to delete it immediately afterward?  I'd
call that useless churn.

It also makes a patch series a PITA to deal with, as a change to
intermediate patch 1 creates a conflict when trying to apply
intermediate patch 2, 3, 4 and so on.  Instead of spending 5 mins
creating V2 of one patch that needs a change, you have to speed an
hour fixing V2 of an entire series.  And that problem is only caused
by trying to create the extra intermediate stages, that no one
actually cares about and will never use, with various known flaws that
are already fixed.


From s.hauer at pengutronix.de  Tue Apr  2 03:18:00 2013
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Tue, 2 Apr 2013 09:18:00 +0200
Subject: [PATCH] cpuimx27 and mbimx27: prepend CONFIG_ to Kconfig macro
In-Reply-To: <1363911302.1390.167.camel@x61.thuisdomein>
References: <1363911302.1390.167.camel@x61.thuisdomein>
Message-ID: <20130402071800.GI1906@pengutronix.de>

Eric,

Any comment to this one? It looks like an obvious bugfix, but since this
is quite old and was never noticed I wonder if there's something else
wrong aswell?

Sascha

On Fri, Mar 22, 2013 at 01:15:02AM +0100, Paul Bolle wrote:
> Commit 2d66c7803595da0d4bcd949825d598575f5de9e6 ("cpuimx27 and mbimx27:
> allow fine control of UART4 and SDHC2 usage") added the Kconfig symbol
> MACH_EUKREA_CPUIMX27_USEUART4. But it forgot to prepend CONFIG_ to the
> use of its macro. Add that prefix now.
> 
> Signed-off-by: Paul Bolle <pebolle at tiscali.nl>
> ---
> Untested. This needs testing, obviously. Or a rethink, because these
> typos have been in the tree since v2.6.36!
> 
>  arch/arm/mach-imx/eukrea_mbimx27-baseboard.c | 4 ++--
>  arch/arm/mach-imx/mach-cpuimx27.c            | 4 ++--
>  2 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm/mach-imx/eukrea_mbimx27-baseboard.c b/arch/arm/mach-imx/eukrea_mbimx27-baseboard.c
> index b4c7002..b2f08bf 100644
> --- a/arch/arm/mach-imx/eukrea_mbimx27-baseboard.c
> +++ b/arch/arm/mach-imx/eukrea_mbimx27-baseboard.c
> @@ -46,7 +46,7 @@ static const int eukrea_mbimx27_pins[] __initconst = {
>  	PE10_PF_UART3_CTS,
>  	PE11_PF_UART3_RTS,
>  	/* UART4 */
> -#if !defined(MACH_EUKREA_CPUIMX27_USEUART4)
> +#if !defined(CONFIG_MACH_EUKREA_CPUIMX27_USEUART4)
>  	PB26_AF_UART4_RTS,
>  	PB28_AF_UART4_TXD,
>  	PB29_AF_UART4_CTS,
> @@ -306,7 +306,7 @@ void __init eukrea_mbimx27_baseboard_init(void)
>  
>  	imx27_add_imx_uart1(&uart_pdata);
>  	imx27_add_imx_uart2(&uart_pdata);
> -#if !defined(MACH_EUKREA_CPUIMX27_USEUART4)
> +#if !defined(CONFIG_MACH_EUKREA_CPUIMX27_USEUART4)
>  	imx27_add_imx_uart3(&uart_pdata);
>  #endif
>  
> diff --git a/arch/arm/mach-imx/mach-cpuimx27.c b/arch/arm/mach-imx/mach-cpuimx27.c
> index 1465593..ea50870 100644
> --- a/arch/arm/mach-imx/mach-cpuimx27.c
> +++ b/arch/arm/mach-imx/mach-cpuimx27.c
> @@ -48,7 +48,7 @@ static const int eukrea_cpuimx27_pins[] __initconst = {
>  	PE14_PF_UART1_CTS,
>  	PE15_PF_UART1_RTS,
>  	/* UART4 */
> -#if defined(MACH_EUKREA_CPUIMX27_USEUART4)
> +#if defined(CONFIG_MACH_EUKREA_CPUIMX27_USEUART4)
>  	PB26_AF_UART4_RTS,
>  	PB28_AF_UART4_TXD,
>  	PB29_AF_UART4_CTS,
> @@ -272,7 +272,7 @@ static void __init eukrea_cpuimx27_init(void)
>  	/* SDHC2 can be used for Wifi */
>  	imx27_add_mxc_mmc(1, NULL);
>  #endif
> -#if defined(MACH_EUKREA_CPUIMX27_USEUART4)
> +#if defined(CONFIG_MACH_EUKREA_CPUIMX27_USEUART4)
>  	/* in which case UART4 is also used for Bluetooth */
>  	imx27_add_imx_uart3(&uart_pdata);
>  #endif
> -- 
> 1.7.11.7
> 
> 

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From s.hauer at pengutronix.de  Tue Apr  2 03:22:41 2013
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Tue, 2 Apr 2013 09:22:41 +0200
Subject: [PATCH] ARM: i.MX53 Add the cko1, cko2 clock outputs.
In-Reply-To: <20130319165701.27591.1287.stgit@localhost>
References: <20130319165701.27591.1287.stgit@localhost>
Message-ID: <20130402072241.GJ1906@pengutronix.de>

On Tue, Mar 19, 2013 at 05:57:01PM +0100, Martin Fuzzey wrote:
> These two clocks connect to external pins and can be muxed to
> various internal clocks.
> They are typically used either for debugging or to provide
> clocks to external chips (eg audio codecs).
> 
> Currently only the selectable clocks that already exist in the clock tree
> have been added.
> 
> Signed-off-by: Martin Fuzzey <mfuzzey at parkeon.com>

Acked-by: Sascha Hauer <s.hauer at pengutronix.de>

Sascha

> ---
>  .../devicetree/bindings/clock/imx5-clock.txt       |    6 ++++
>  arch/arm/mach-imx/clk-imx51-imx53.c                |   34 ++++++++++++++++++++
>  2 files changed, 40 insertions(+), 0 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/clock/imx5-clock.txt b/Documentation/devicetree/bindings/clock/imx5-clock.txt
> index 2a0c904..959d495 100644
> --- a/Documentation/devicetree/bindings/clock/imx5-clock.txt
> +++ b/Documentation/devicetree/bindings/clock/imx5-clock.txt
> @@ -172,6 +172,12 @@ clocks and IDs.
>  	can1_serial_gate	157
>  	can1_ipg_gate		158
>  	owire_gate		159
> +	cko1_sel		160
> +	cko1_podf		161
> +	cko1			162
> +	cko2_sel		163
> +	cko2_podf		164
> +	cko2			165
>  
>  Examples (for mx53):
>  
> diff --git a/arch/arm/mach-imx/clk-imx51-imx53.c b/arch/arm/mach-imx/clk-imx51-imx53.c
> index 0f39f8c..872a7bc 100644
> --- a/arch/arm/mach-imx/clk-imx51-imx53.c
> +++ b/arch/arm/mach-imx/clk-imx51-imx53.c
> @@ -49,6 +49,28 @@ static const char *tve_sel[] = { "tve_pred", "tve_ext_sel", };
>  static const char *ipu_sel[] = { "axi_a", "axi_b", "emi_slow_gate", "ahb", };
>  static const char *vpu_sel[] = { "axi_a", "axi_b", "emi_slow_gate", "ahb", };
>  static const char *mx53_can_sel[] = { "ipg", "ckih1", "ckih2", "lp_apm", };
> +static const char *mx53_cko1_sel[] = {
> +	"cpu_podf", "pll1_sw", "pll2_sw", "pll3_sw",
> +	"emi_slow_podf", "pll4_sw", "nfc_podf", "dummy",
> +	"di_pred", "dummy", "dummy", "ahb",
> +	"ipg", "per_root", "ckil", "dummy",};
> +static const char *mx53_cko2_sel[] = {
> +	"dummy"/* dptc_core */, "dummy"/* dptc_perich */,
> +	"dummy", "esdhc_a_podf",
> +	"usboh3_podf", "dummy"/* wrck_clk_root */,
> +	"ecspi_podf", "dummy"/* pll1_ref_clk */,
> +	"esdhc_b_podf", "dummy"/* ddr_clk_root */,
> +	"dummy"/* arm_axi_clk_root */, "dummy"/* usb_phy_out */,
> +	"vpu_sel", "ipu_sel",
> +	"osc", "ckih1",
> +	"dummy", "esdhc_c_sel",
> +	"ssi1_root_podf", "ssi2_root_podf",
> +	"dummy", "dummy",
> +	"dummy"/* lpsr_clk_root */, "dummy"/* pgc_clk_root */,
> +	"dummy"/* tve_out */, "usb_phy_sel",
> +	"tve_sel", "lp_apm",
> +	"uart_root", "dummy"/* spdif0_clk_root */,
> +	"dummy", "dummy", };
>  
>  enum imx5_clks {
>  	dummy, ckil, osc, ckih1, ckih2, ahb, ipg, axi_a, axi_b, uart_pred,
> @@ -84,6 +106,8 @@ enum imx5_clks {
>  	epit1_ipg_gate, epit1_hf_gate, epit2_ipg_gate, epit2_hf_gate,
>  	can_sel, can1_serial_gate, can1_ipg_gate,
>  	owire_gate,
> +	cko1_sel, cko1_podf, cko1,
> +	cko2_sel, cko2_podf, cko2,
>  	clk_max
>  };
>  
> @@ -456,6 +480,16 @@ int __init mx53_clocks_init(unsigned long rate_ckil, unsigned long rate_osc,
>  	clk[can2_ipg_gate] = imx_clk_gate2("can2_ipg_gate", "ipg", MXC_CCM_CCGR4, 6);
>  	clk[i2c3_gate] = imx_clk_gate2("i2c3_gate", "per_root", MXC_CCM_CCGR1, 22);
>  
> +	clk[cko1_sel] = imx_clk_mux("cko1_sel", MXC_CCM_CCOSR, 0, 4,
> +				mx53_cko1_sel, ARRAY_SIZE(mx53_cko1_sel));
> +	clk[cko1_podf] = imx_clk_divider("cko1_podf", "cko1_sel", MXC_CCM_CCOSR, 4, 3);
> +	clk[cko1] = imx_clk_gate2("cko1", "cko1_podf", MXC_CCM_CCOSR, 7);
> +
> +	clk[cko2_sel] = imx_clk_mux("cko2_sel", MXC_CCM_CCOSR, 16, 5,
> +				mx53_cko2_sel, ARRAY_SIZE(mx53_cko2_sel));
> +	clk[cko2_podf] = imx_clk_divider("cko2_podf", "cko2_sel", MXC_CCM_CCOSR, 21, 3);
> +	clk[cko2] = imx_clk_gate2("cko2", "cko2_podf", MXC_CCM_CCOSR, 24);
> +
>  	for (i = 0; i < ARRAY_SIZE(clk); i++)
>  		if (IS_ERR(clk[i]))
>  			pr_err("i.MX53 clk %d: register failed with %ld\n",
> 
> 

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From eric at eukrea.com  Tue Apr  2 03:23:10 2013
From: eric at eukrea.com (Eric =?UTF-8?B?QsOpbmFyZA==?=)
Date: Tue, 2 Apr 2013 09:23:10 +0200
Subject: [PATCH] cpuimx27 and mbimx27: prepend CONFIG_ to Kconfig macro
In-Reply-To: <20130402071800.GI1906@pengutronix.de>
References: <1363911302.1390.167.camel@x61.thuisdomein>
 <20130402071800.GI1906@pengutronix.de>
Message-ID: <20130402092310.57307d13@e6520eb>

Hi Sascha,

Le Tue, 2 Apr 2013 09:18:00 +0200,
Sascha Hauer <s.hauer at pengutronix.de> a ?crit :
> Any comment to this one? It looks like an obvious bugfix, but since this
> is quite old and was never noticed I wonder if there's something else
> wrong aswell?
> 
the patch seems OK.

Acked-by: Eric B?nard <eric at eukrea.com> 

Thanks,
Eric

> 
> On Fri, Mar 22, 2013 at 01:15:02AM +0100, Paul Bolle wrote:
> > Commit 2d66c7803595da0d4bcd949825d598575f5de9e6 ("cpuimx27 and mbimx27:
> > allow fine control of UART4 and SDHC2 usage") added the Kconfig symbol
> > MACH_EUKREA_CPUIMX27_USEUART4. But it forgot to prepend CONFIG_ to the
> > use of its macro. Add that prefix now.
> > 
> > Signed-off-by: Paul Bolle <pebolle at tiscali.nl>
> > ---
> > Untested. This needs testing, obviously. Or a rethink, because these
> > typos have been in the tree since v2.6.36!
> > 
> >  arch/arm/mach-imx/eukrea_mbimx27-baseboard.c | 4 ++--
> >  arch/arm/mach-imx/mach-cpuimx27.c            | 4 ++--
> >  2 files changed, 4 insertions(+), 4 deletions(-)
> > 
> > diff --git a/arch/arm/mach-imx/eukrea_mbimx27-baseboard.c b/arch/arm/mach-imx/eukrea_mbimx27-baseboard.c
> > index b4c7002..b2f08bf 100644
> > --- a/arch/arm/mach-imx/eukrea_mbimx27-baseboard.c
> > +++ b/arch/arm/mach-imx/eukrea_mbimx27-baseboard.c
> > @@ -46,7 +46,7 @@ static const int eukrea_mbimx27_pins[] __initconst = {
> >  	PE10_PF_UART3_CTS,
> >  	PE11_PF_UART3_RTS,
> >  	/* UART4 */
> > -#if !defined(MACH_EUKREA_CPUIMX27_USEUART4)
> > +#if !defined(CONFIG_MACH_EUKREA_CPUIMX27_USEUART4)
> >  	PB26_AF_UART4_RTS,
> >  	PB28_AF_UART4_TXD,
> >  	PB29_AF_UART4_CTS,
> > @@ -306,7 +306,7 @@ void __init eukrea_mbimx27_baseboard_init(void)
> >  
> >  	imx27_add_imx_uart1(&uart_pdata);
> >  	imx27_add_imx_uart2(&uart_pdata);
> > -#if !defined(MACH_EUKREA_CPUIMX27_USEUART4)
> > +#if !defined(CONFIG_MACH_EUKREA_CPUIMX27_USEUART4)
> >  	imx27_add_imx_uart3(&uart_pdata);
> >  #endif
> >  
> > diff --git a/arch/arm/mach-imx/mach-cpuimx27.c b/arch/arm/mach-imx/mach-cpuimx27.c
> > index 1465593..ea50870 100644
> > --- a/arch/arm/mach-imx/mach-cpuimx27.c
> > +++ b/arch/arm/mach-imx/mach-cpuimx27.c
> > @@ -48,7 +48,7 @@ static const int eukrea_cpuimx27_pins[] __initconst = {
> >  	PE14_PF_UART1_CTS,
> >  	PE15_PF_UART1_RTS,
> >  	/* UART4 */
> > -#if defined(MACH_EUKREA_CPUIMX27_USEUART4)
> > +#if defined(CONFIG_MACH_EUKREA_CPUIMX27_USEUART4)
> >  	PB26_AF_UART4_RTS,
> >  	PB28_AF_UART4_TXD,
> >  	PB29_AF_UART4_CTS,
> > @@ -272,7 +272,7 @@ static void __init eukrea_cpuimx27_init(void)
> >  	/* SDHC2 can be used for Wifi */
> >  	imx27_add_mxc_mmc(1, NULL);
> >  #endif
> > -#if defined(MACH_EUKREA_CPUIMX27_USEUART4)
> > +#if defined(CONFIG_MACH_EUKREA_CPUIMX27_USEUART4)
> >  	/* in which case UART4 is also used for Bluetooth */
> >  	imx27_add_imx_uart3(&uart_pdata);
> >  #endif
> > -- 
> > 1.7.11.7
> > 
> > 
> 



From tomasz.figa at gmail.com  Tue Apr  2 04:00:03 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Tue, 02 Apr 2013 10:00:03 +0200
Subject: [PATCH 0/6] pinctrl: Add support for pin control on S3C64xx
In-Reply-To: <1363642315-10331-1-git-send-email-tomasz.figa@gmail.com>
References: <1363642315-10331-1-git-send-email-tomasz.figa@gmail.com>
Message-ID: <1441305.zvZX7Ed4lY@flatron>

Hi,

On Monday 18 of March 2013 22:31:49 Tomasz Figa wrote:
> This series makes necessary preparations to add support for pin
> controller available on Samsung S3C64xx using pinctrl-samsung driver
> and then adds pinctrl-s3c64xx driver which implements SoC-specific part
> of the code.
> 
> It has been tested on a tiny6410 (mini6410-compatible) board with my
> patches for samsung-time cleanup and S3C64xx Device Tree support:
>  - http://thread.gmane.org/gmane.linux.kernel.samsung-soc/16664
>  -
> http://www.mail-archive.com/linux-samsung-soc at vger.kernel.org/msg16325.
> html
> 
> Just the driver is added for now, as this is the part that can safely go
> through Linus' pinctrl tree. I will post appropriate enablement patches
> after all the dependencies get merged to Kgene's tree.
> 
> See particular patches for more detailed description of all changes.
> 
> Tomasz Figa (6):
>   pinctrl: samsung: Protect bank registers with a spinlock
>   pinctrl: samsung: Include pinctrl-exynos driver data conditionally
>   pinctrl: samsung: Split pin bank description into two structures
>   pinctrl: samsung: Remove hardcoded register offsets
>   pinctrl: samsung: Handle banks with two configuration registers
>   pinctrl: Add pinctrl-s3c64xx driver
> 
>  .../bindings/pinctrl/samsung-pinctrl.txt           |   3 +
>  drivers/pinctrl/Kconfig                            |   5 +
>  drivers/pinctrl/Makefile                           |   1 +
>  drivers/pinctrl/pinctrl-exynos.c                   |  36 +-
>  drivers/pinctrl/pinctrl-exynos.h                   |  16 +-
>  drivers/pinctrl/pinctrl-s3c64xx.c                  | 817
> +++++++++++++++++++++ drivers/pinctrl/pinctrl-samsung.c                
>  |  99 ++-
>  drivers/pinctrl/pinctrl-samsung.h                  |  42 +-
>  8 files changed, 947 insertions(+), 72 deletions(-)
>  create mode 100644 drivers/pinctrl/pinctrl-s3c64xx.c

Any comments about this series?

Best regards,
Tomasz



From balbi at ti.com  Tue Apr  2 04:02:52 2013
From: balbi at ti.com (Felipe Balbi)
Date: Tue, 2 Apr 2013 11:02:52 +0300
Subject: [PATCH 3/5] USB chipidea: introduce dual role mode pdata flags
In-Reply-To: <87obe3irxl.fsf@ashishki-desk.ger.corp.intel.com>
References: <1362049024-11383-1-git-send-email-mkl@pengutronix.de>
 <1362049024-11383-4-git-send-email-mkl@pengutronix.de>
 <20130308163300.GF32368@arwen.pp.htv.fi>
 <CAB7JpEGP4HXrbGs539pV8ruPrS2ZOT0EYhGR74vvFDtHM4GsQg@mail.gmail.com>
 <513A1743.8070102@pengutronix.de>
 <CAB7JpEE8L+NR109+tnO_dueWtXBPnQVjegojsQNBUgBHPyk5eg@mail.gmail.com>
 <20130310143734.GA9804@arwen.pp.htv.fi>
 <87y5d7ixqb.fsf@ashishki-desk.ger.corp.intel.com>
 <20130328114417.GA23223@arwen.pp.htv.fi>
 <87obe3irxl.fsf@ashishki-desk.ger.corp.intel.com>
Message-ID: <20130402080252.GB30286@arwen.pp.htv.fi>

Hi,

On Thu, Mar 28, 2013 at 03:18:14PM +0200, Alexander Shishkin wrote:
> >> >> >>>> +     dr_mode = ci->platdata->dr_mode;
> >> >> >>>> +     if (dr_mode == USB_DR_MODE_UNKNOWN || dr_mode == USB_DR_MODE_DUAL_ROLE)
> >> >> >>>> +             dr_mode = USB_DR_MODE_OTG;
> >> >> >>>> +
> >> >> >>>>       /* initialize role(s) before the interrupt is requested */
> >> >> >>>> -     ret = ci_hdrc_host_init(ci);
> >> >> >>>> -     if (ret)
> >> >> >>>> -             dev_info(dev, "doesn't support host\n");
> >> >> >>>> +     if (dr_mode == USB_DR_MODE_OTG || dr_mode == USB_DR_MODE_HOST) {
> >> >> >>>
> >> >> >>> this is not something you should be passing via pdata; chipidea core
> >> >> >>> should know how to read this data by itself. Meaning that chipidea core
> >> >> >>> should be taught about devicetree. But make it optional since now all
> >> >> >>> users use DT.
> >> >> >>
> >> >> >> And I don't think I like the idea of chipidea core calling into device
> >> >> >> tree code directly.
> >> >> >
> >> >> > Hmmm....this means draw :)
> >> >> 
> >> >> Well, we could go for something like
> >> >> 
> >> >> ci_hdrc-$(CONFIG_OF) += of.o
> >> >> 
> >> >> and try to contain the damage there, maybe? Ideas? I would very much
> >> >> like to keep the clutter away from the core probe if possible.
> >> >
> >> > damage, what damage ? DeviceTree is quite real and drivers need to cope
> >> > with it. If not all platforms support devicetree, make it optional. It's
> >> > easy enough to make the choice based on device.of_node being valid or
> >> > not.
> >> 
> >> We have dr_mode and phy_mode (so far). The latter is simple, but the
> >> former one needs to see some special cases, based on its setting. Now,
> >> if we're a pci device, for example, we don't have phandles and stuff and
> >> we will still get this information via platform data.
> >
> > fair enough:
> >
> > if (pdev->dev.of_node)
> > 	chipidea_init_from_dt(ci);
> > else
> > 	chipidea_init_from_pdata(ci);
> 
> You mean, you want to have two instances of the similar logic? Don't
> forget that they might fail to fetch certain phandles and still
> continue, but failing to fetch other phandles will be fatal for
> probe(). The above snipped can also be shortened to
> 
>   chipidea_just_do_the_right_thing(ci); /* I'd like that, btw */
> 
> The devil is in the details.
> 
> Then, I hate to bring it up, but what do you do for acpi devices? PnP
> devices? PCMCIA devices?

those look like PCI devices right ? What's the problem with them ?

> Right now, the core is a platform driver. It gets all the information
> from platform data. That's all it needs for its purpose, and all the
> platform specific details are abstracted away. It's the purpose of the
> glue layer's existance to fetch all the relevant bits from the glue
> driver knows where and supply it in a *consistent* manner to the core.

I still that e.g. requesting regulators in glue and passing a regulator
pointer through platform_data is really, really wrong.

> Note, it's totally different for regulators or clocks or phys. It is
> totally unacceptable to pass objects around between glue and core and
> glue shouldn't have to deal with those. And, of course, you can request
> all those in the core code in a platform-agnostic manner.

how ? If your regulator is bound to the glue, how will you
regulator_get() from core driver ?

> >> So, what we'll end up with is some glue drivers (that don't have device
> >> tree) passing all sorts of stuff via platform data and others just
> >> expecting the chipidea to take care of it. That's inconsistent at best.
> >
> > it's not inconsistent at all.
> >
> > Some drivers pass data through DT and some pass data through pdata.
> >
> > Regardless of which driver type you have, chipidea core still needs to
> > fetch the data, either by of_property_*() calls or by reading
> > pdata->$field.
> >
> > I wouldn't call it inconsistency, it's just coping with both ways of
> > receiving data.
> >
> >> > At the end of the day, it's the chipidea IP which needs dr_mode, not the
> >> > glue. Passing the responsability of decoding dr_mode to the glue is
> >> > moronic. It's just like asking the glue to control chipidea's clocks.
> >> 
> >> Now, now. There's something to be said about stuffing core drivers with
> >> support for all sorts of resource management protocols du jour, but
> >> we'll leave that for another day.
> >> 
> >> As for the clocks, if they are external to chipidea controller, the
> >> latter has no business messing with them. It's like asking chipidea to
> >
> > heh, that's not what I said...
> >
> >> do power management on your SoC for you. :)
> >
> > right, asking other layers to do your work is stupid, that's exactly
> > what I said. Shuving DT knowledge in glue layer just so chipidea core
> > only understands pdata is stupid.
> 
> Why? Especially if the glue drivers have to fetch stuff for their own
> needs from DT anyway. Might easily happen.

why ? Because it's poor encapsulation. Why would you give another entity
knowledge about yourself ?

> > You end up allocating memory twice to
> > hold the same data (once for DT and once for the pdata copies of it).
> 
> It would have been one valid reason for teaching chipidea core about DT,
> if we could duplicate *all* of the pdata fields in DT. Otherwise we
> still need pdata. And supposing that we can (which we can't) do that,
> and supposing that extra 32 bytes of memory actually matter, it still
> doesn't justify the extra code in the core to deal with DT. I'm still
> not convinced.

fair enough, it's your headache in the end of the day anyway. When you
get bug reports such as one we saw recently of clocks being left on even
though probe failed, you'll understand.

You have worked with MUSB before and should already know that giving too
much knowledge to your glue layers is a recipe for disaster.

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130402/43647640/attachment.sig>

From balbi at ti.com  Tue Apr  2 04:07:06 2013
From: balbi at ti.com (Felipe Balbi)
Date: Tue, 2 Apr 2013 11:07:06 +0300
Subject: [PATCH 1/2] ARM: imx_v6_v7_defconfig: add CONFIG_USB_PHY
In-Reply-To: <1364133966-22373-1-git-send-email-shawn.guo@linaro.org>
References: <1364133966-22373-1-git-send-email-shawn.guo@linaro.org>
Message-ID: <20130402080706.GC30286@arwen.pp.htv.fi>

On Sun, Mar 24, 2013 at 10:06:04PM +0800, Shawn Guo wrote:
> Commit edc7cb2 (usb: phy: make it a menuconfig) makes USB_MXS_PHY
> be a sub-item of menuconfig symbol USB_PHY.  This change gets the
> selection of CONFIG_USB_MXS_PHY in imx_v6_v7_defconfig lost.  Hence the
> boot stops at the point below.
> 
>   ci_hdrc ci_hdrc.0: doesn't support gadget
>   ci_hdrc ci_hdrc.0: EHCI Host Controller
>   ci_hdrc ci_hdrc.0: new USB bus registered, assigned bus number 1
> 
> Add CONFIG_USB_PHY to have the CONFIG_USB_MXS_PHY selection back to
> work.
> 
> Signed-off-by: Shawn Guo <shawn.guo at linaro.org>

should I take this or will Russell queue it during -rc ?

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130402/365ce622/attachment.sig>

From peter.ujfalusi at ti.com  Tue Apr  2 04:14:10 2013
From: peter.ujfalusi at ti.com (Peter Ujfalusi)
Date: Tue, 2 Apr 2013 10:14:10 +0200
Subject: [RFC] dmaengine: omap-dma: Start DMA without delay
In-Reply-To: <20130329173100.GV30923@n2100.arm.linux.org.uk>
References: <1364566323-24144-1-git-send-email-peter.ujfalusi@ti.com>
 <20130329173100.GV30923@n2100.arm.linux.org.uk>
Message-ID: <515A9352.5060702@ti.com>

Russell,

On 03/29/2013 06:31 PM, Russell King - ARM Linux wrote:
> On Fri, Mar 29, 2013 at 03:12:03PM +0100, Peter Ujfalusi wrote:
>> Remove the use of a tasklet to start the DMA channel when issue_pending is
>> called.
>> The use of tasklet delays the DMA start which can cause issues at drivers,
>> for example the audio drivers expect that the DMA is started right away.
>>
>> Signed-off-by: Peter Ujfalusi <peter.ujfalusi at ti.com>
>> ---
>> Hi Russell,
>>
>> I know you are against removing the tasklet since you have planed to move the
>> omap-dma to use runtime/dynamic DMA channel use.
>> I have looked at the amba-pl08x.c driver which is doing that exactly (as you
>> pointed out that to me). AMBA did not use tasklet either and I'm sure we can
>> change the omap-dma driver to do the same in a same way as we could have done it
>> with the tasklet use.
> 
> It's rather sad that you're ignoring what I'm saying, and going by what
> another DMA engine driver - which is self contained - is doing, rather
> than listening to my arguments against that approach.

The reason I send this as RFC to start a discussion to find out how we should
handle this. I were to ignore what you were saying I would have just sent a
PATCH instead.

I don't think that the tasklet is the solution for the runtime DMA channel
selection. We can do it in a same way as AMBA has been doing. In this way we
can handle all cases with the same code.
The pre-allocating of channels and starting the DMA right away is different issue.

What need to be done anyway is to convert the remaining drivers to use dmaengine:
drivers/usb/musb/tusb6010_omap.c
drivers/usb/gadget/omap_udc.c
drivers/mtd/onenand/omap2.c
drivers/media/platform/omap3isp/isphist.c
drivers/media/platform/soc_camera/omap1_camera.c
drivers/media/platform/omap/omap_vout_vrfb.c

When that is done we can remove the arch/arm/plat-omap/dma.c and migrate the
code under dmaengine to restructure it and finally we can have runtime channel
allocation.

-- 
P?ter


From balbi at ti.com  Tue Apr  2 04:14:49 2013
From: balbi at ti.com (Felipe Balbi)
Date: Tue, 2 Apr 2013 11:14:49 +0300
Subject: [PATCH V2 6/6] usb: mv_usb: remove clock name from pdata
In-Reply-To: <1364195217-1226-7-git-send-email-chao.xie@marvell.com>
References: <1364195217-1226-1-git-send-email-chao.xie@marvell.com>
 <1364195217-1226-7-git-send-email-chao.xie@marvell.com>
Message-ID: <20130402081449.GD30286@arwen.pp.htv.fi>

Hi,

On Mon, Mar 25, 2013 at 03:06:57AM -0400, Chao Xie wrote:
> Using pdata to pass clock name is not correct.
> Directly get clock from usb drivers.
> 
> Signed-off-by: Chao Xie <chao.xie at marvell.com>
> ---
>  include/linux/platform_data/mv_usb.h |    2 --
>  1 files changed, 0 insertions(+), 2 deletions(-)
> 
> diff --git a/include/linux/platform_data/mv_usb.h b/include/linux/platform_data/mv_usb.h
> index 944b01d..98b7925 100644
> --- a/include/linux/platform_data/mv_usb.h
> +++ b/include/linux/platform_data/mv_usb.h
> @@ -34,8 +34,6 @@ struct mv_usb_addon_irq {
>  };
>  
>  struct mv_usb_platform_data {
> -	unsigned int		clknum;
> -	char			**clkname;

this patch breaks mv_u3d_core.c, I have added another patch to the
series (see below), let me know if this isn't the right fix.

From 49c1bfb43cbd1228abfffbc8d0ebb2e510b93bd7 Mon Sep 17 00:00:00 2001
From: Felipe Balbi <balbi at ti.com>
Date: Tue, 2 Apr 2013 11:12:11 +0300
Subject: [PATCH] usb: gadget: mv_u3d_core: remove unused clock

The origianl understanding of clock is wrong. The UDC controller
only have one clock input.
Passing clock name by pdata is wrong. The clock is defined by device
iteself.

Cc: Chao Xie <chao.xie at marvell.com>
Cc: Yu Xu <yuxu at marvell.com>
Signed-off-by: Felipe Balbi <balbi at ti.com>
---
 drivers/usb/gadget/mv_u3d_core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/mv_u3d_core.c b/drivers/usb/gadget/mv_u3d_core.c
index 9675227..58288e9 100644
--- a/drivers/usb/gadget/mv_u3d_core.c
+++ b/drivers/usb/gadget/mv_u3d_core.c
@@ -1821,7 +1821,7 @@ static int mv_u3d_probe(struct platform_device *dev)
 	u3d->dev = &dev->dev;
 	u3d->vbus = pdata->vbus;
 
-	u3d->clk = clk_get(&dev->dev, pdata->clkname[0]);
+	u3d->clk = clk_get(&dev->dev, NULL);
 	if (IS_ERR(u3d->clk)) {
 		retval = PTR_ERR(u3d->clk);
 		goto err_get_clk;
-- 
1.8.2

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130402/7a99e4ac/attachment.sig>

From nsekhar at ti.com  Tue Apr  2 04:16:05 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Tue, 2 Apr 2013 13:46:05 +0530
Subject: [PATCH v3 2/3] arm: davinci: clock node support for ECAP & EHRPWM
In-Reply-To: <1364197789-16783-3-git-send-email-avinashphilip@ti.com>
References: <1364197789-16783-1-git-send-email-avinashphilip@ti.com>
 <1364197789-16783-3-git-send-email-avinashphilip@ti.com>
Message-ID: <515A93C5.4040009@ti.com>

On 3/25/2013 1:19 PM, Philip Avinash wrote:
> Add clock node support for ECAP and EHRPWM modules.
> Also adds TBCLK for EHRWPM TBCLK to comply with pwm-tiehrpwm
> driver.
> 
> Signed-off-by: Philip Avinash <avinashphilip at ti.com>

Queuing this for v3.10

Thanks,
Sekhar


From kgene.kim at samsung.com  Tue Apr  2 04:17:00 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Tue, 02 Apr 2013 17:17:00 +0900
Subject: [PATCH v6 0/7] move s3c24xx-irq to drivers/irqchip and add dt
 support
In-Reply-To: <201303262212.31283.arnd@arndb.de>
References: <201303262305.49725.heiko@sntech.de>
 <201303262212.31283.arnd@arndb.de>
Message-ID: <22c901ce2f7a$731fe9f0$595fbdd0$%kim@samsung.com>

Arnd Bergmann wrote:
> 
> On Tuesday 26 March 2013, Heiko St?bner wrote:
> > This v6 addresses more comments from Arnd Bergmann, setting the
> compatible
> > property to the first supported SoC (s3c2410) instead of using the
> s3c24xx
> > wildcard. It also switches the parent-irq and controller irq in the dt
> > irq descriptor bringing it to a format of
> >
> >   <ctrl_num parent_irq ctrl_irq type>
> 
> Entire series
> 
> Acked-by: Arnd Bergmann <arnd at arndb.de>

Thanks.

Applied this whole series.

- Kukjin



From kgene.kim at samsung.com  Tue Apr  2 04:17:42 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Tue, 02 Apr 2013 17:17:42 +0900
Subject: [PATCH v6 7/7] irqchip: s3c24xx: add devicetree support
In-Reply-To: <51536B85.1070205@gmail.com>
References: <201303262305.49725.heiko@sntech.de>
 <201303262310.35354.heiko@sntech.de> <51536B85.1070205@gmail.com>
Message-ID: <22ca01ce2f7a$8c17d210$a4477630$%kim@samsung.com>

Rob Herring wrote:
> 
> On 03/26/2013 05:10 PM, Heiko St?bner wrote:
> > Add the necessary code to initialize the interrupt controller
> > thru devicetree data using the irqchip infrastructure.
> >
> > Signed-off-by: Heiko Stuebner <heiko at sntech.de>
> 
> Acked-by: Rob Herring <rob.herring at calxeda.com>
> 
Rob, thanks for your ack.

Applied with your ack.

- Kukjin



From rogerq at ti.com  Tue Apr  2 04:23:39 2013
From: rogerq at ti.com (Roger Quadros)
Date: Tue, 2 Apr 2013 11:23:39 +0300
Subject: [PATCH v2] ARM: OMAP4: clock: Add device tree support for AUXCLKs
In-Reply-To: <1364293408-20677-1-git-send-email-rogerq@ti.com>
References: <1363703220-4777-2-git-send-email-rogerq@ti.com>
 <1364293408-20677-1-git-send-email-rogerq@ti.com>
Message-ID: <515A958B.5080905@ti.com>

+ Paul

On 03/26/2013 12:23 PM, Roger Quadros wrote:
> Register a device tree clock provider for the clocks
> on the OMAP4 SoC. Also provide the binding information.
> 
> For now we only provide AUXCLKs.
> 
> Signed-off-by: Roger Quadros <rogerq at ti.com>
> ---
>  .../devicetree/bindings/clock/omap4-clock.txt      |   33 ++++++++++++++++
>  arch/arm/boot/dts/omap4.dtsi                       |    5 ++
>  arch/arm/mach-omap2/cclock44xx_data.c              |   41 ++++++++++++++++++++
>  3 files changed, 79 insertions(+), 0 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/clock/omap4-clock.txt
> 
> diff --git a/Documentation/devicetree/bindings/clock/omap4-clock.txt b/Documentation/devicetree/bindings/clock/omap4-clock.txt
> new file mode 100644
> index 0000000..2845a3f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/omap4-clock.txt
> @@ -0,0 +1,33 @@
> +* Clock bindings for Texas Instruments OMAP4 clocks
> +
> +Required properties:
> +- compatible: Should be "ti,omap4-clock"
> +- #clock-cells: Should be <1>
> +
> +The clock consumer should specify the desired clock by having the clock
> +ID in its "clocks" phandle cell.  The following is a list of OMAP4 clocks
> +and IDs.
> +
> +	Clock		ID
> +	------------------
> +	auxclk0_ck	0
> +	auxclk1_ck	1
> +	auxclk2_ck	2
> +	auxclk3_ck	3
> +	auxclk4_ck	4
> +	auxclk5_ck	5
> +
> +Example:
> +
> +aux_clks: scrmclks {
> +	compatible = "ti,omap4-clock";
> +	#clock-cells = <1>;
> +};
> +
> +hsusb1_phy: hsusb1_phy {
> +	compatible = "usb-nop-xceiv";
> +	reset-supply = <&hsusb1_reset>;
> +	clocks = <&aux_clks 3>;
> +	clock-names = "main_clk";
> +	clock-frequency = <19200000>;
> +};
> diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
> index 739bb79..f27548a 100644
> --- a/arch/arm/boot/dts/omap4.dtsi
> +++ b/arch/arm/boot/dts/omap4.dtsi
> @@ -101,6 +101,11 @@
>  			ti,hwmods = "counter_32k";
>  		};
>  
> +		clks: clocks {
> +			compatible = "ti,omap4-clock";
> +			#clock-cells = <1>;
> +		};
> +
>  		omap4_pmx_core: pinmux at 4a100040 {
>  			compatible = "ti,omap4-padconf", "pinctrl-single";
>  			reg = <0x4a100040 0x0196>;
> diff --git a/arch/arm/mach-omap2/cclock44xx_data.c b/arch/arm/mach-omap2/cclock44xx_data.c
> index 3d58f33..a93617b 100644
> --- a/arch/arm/mach-omap2/cclock44xx_data.c
> +++ b/arch/arm/mach-omap2/cclock44xx_data.c
> @@ -27,6 +27,7 @@
>  #include <linux/clk-private.h>
>  #include <linux/clkdev.h>
>  #include <linux/io.h>
> +#include <linux/of.h>
>  
>  #include "soc.h"
>  #include "iomap.h"
> @@ -1663,6 +1664,44 @@ static struct omap_clk omap44xx_clks[] = {
>  	CLK(NULL,	"cpufreq_ck",	&dpll_mpu_ck,	CK_443X),
>  };
>  
> +/*
> + * List of clocks that can be referenced in device tree
> + * Must match with Documentation/devicetree/bindings/clock/omap4-clock.txt
> + */
> +static struct clk *dt_clks[] = {
> +	&auxclk0_ck,
> +	&auxclk1_ck,
> +	&auxclk2_ck,
> +	&auxclk3_ck,
> +	&auxclk4_ck,
> +	&auxclk5_ck,
> +};
> +
> +static struct clk_onecell_data clock_data;
> +
> +#ifdef CONFIG_OF
> +int __init omap4_clk_init_dt(void)
> +{
> +	struct device_node *np;
> +
> +	np = of_find_compatible_node(NULL, NULL, "ti,omap4-clock");
> +	if (np) {
> +		clock_data.clks = dt_clks;
> +		clock_data.clk_num = ARRAY_SIZE(dt_clks);
> +		of_clk_add_provider(np, of_clk_src_onecell_get,	&clock_data);
> +	}
> +
> +	return 0;
> +}
> +
> +#else
> +
> +int __init omap4_clk_init_dt(void)
> +{
> +	return 0;
> +}
> +#endif /* CONFIG_OF */
> +
>  int __init omap4xxx_clk_init(void)
>  {
>  	u32 cpu_clkflg;
> @@ -1693,6 +1732,8 @@ int __init omap4xxx_clk_init(void)
>  
>  	omap2_clk_disable_autoidle_all();
>  
> +	omap4_clk_init_dt();
> +
>  	/*
>  	 * On OMAP4460 the ABE DPLL fails to turn on if in idle low-power
>  	 * state when turning the ABE clock domain. Workaround this by
> 



From linus.walleij at linaro.org  Tue Apr  2 04:26:12 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Tue, 2 Apr 2013 10:26:12 +0200
Subject: [PATCH] ARM: ux500: update V-INTCORE constraints
In-Reply-To: <1364397694-14126-1-git-send-email-fabio.baltieri@linaro.org>
References: <1364397694-14126-1-git-send-email-fabio.baltieri@linaro.org>
Message-ID: <CACRpkdYgCxf9R1aU2QdPUBxErhK=E2tM=6L-yMLA_L3+ntj3nQ@mail.gmail.com>

On Wed, Mar 27, 2013 at 4:21 PM, Fabio Baltieri
<fabio.baltieri at linaro.org> wrote:

> Update V-INTCORE regulator constraints to allow voltage and
> configuration changes from consumer drivers.
>
> Signed-off-by: Fabio Baltieri <fabio.baltieri at linaro.org>
> ---
> Hi Linus,
>
> this patch adds the regulators bits I'm missing for ux500-musb patches.
> Without this I just get a runtime warning like:
>
> V-INTCORE: operation not allowed
>
> but the driver works anyway and there are no build dependencies, so I
> think this can safely go in the arm-soc tree on its own, and the whole
> thing should work happily in -next.

Reviewed-by: Linus Walleij <linus.walleij at linaro.org>

I know that Lee's been sending off a large set of regulator patches
lately, some include alterations to this platform config.

Maybe it's better to take this patch into the regulator tree if these
machine configs will come in that way? Also like Lee to have a
look at this...

Yours,
Linus Walleij


From tushar.behera at linaro.org  Tue Apr  2 04:29:36 2013
From: tushar.behera at linaro.org (Tushar Behera)
Date: Tue, 02 Apr 2013 13:59:36 +0530
Subject: [PATCH] ARM: EXYNOS: Use wfi macro in platform_do_lowpower
In-Reply-To: <1362740988-16483-1-git-send-email-tushar.behera@linaro.org>
References: <1362740988-16483-1-git-send-email-tushar.behera@linaro.org>
Message-ID: <515A96F0.2090504@linaro.org>

Ping !!!

On 03/08/2013 04:39 PM, Tushar Behera wrote:
> As per commit b3377d186572 ("ARM: 7064/1: vexpress: Use wfi macro
> in platform_do_lowpower."), wfi macro should be used instead
> of the hardcoded WFI instruction.
> 
> This fixes following oops when the kernel is compiled in Thumb-2 mode
> on EXYNOS5. (Tested on EXYNOS5250 based Arndale board)
> 
> $ reboot
> Disabling non-boot CPUs ...
> IRQ153 no longer affine to CPU1
> CPU1: shutdown
> Internal error: Oops - undefined instruction: 0 [#1] PREEMPT SMP THUMB2
> Modules linked in:
> CPU: 1    Not tainted  (3.9.0-rc1-00015-gce76372 #1)
> PC is at 0xc065858e
> LR is at exynos_cpu_die+0x53/0xc0
> 
> Signed-off-by: Tushar Behera <tushar.behera at linaro.org>
> ---
>  arch/arm/mach-exynos/hotplug.c |    8 +-------
>  1 files changed, 1 insertions(+), 7 deletions(-)
> 
> diff --git a/arch/arm/mach-exynos/hotplug.c b/arch/arm/mach-exynos/hotplug.c
> index c3f825b..d9712fe 100644
> --- a/arch/arm/mach-exynos/hotplug.c
> +++ b/arch/arm/mach-exynos/hotplug.c
> @@ -99,13 +99,7 @@ static inline void platform_do_lowpower(unsigned int cpu, int *spurious)
>  		if (cpu == 1)
>  			__raw_writel(0, S5P_ARM_CORE1_CONFIGURATION);
>  
> -		/*
> -		 * here's the WFI
> -		 */
> -		asm(".word	0xe320f003\n"
> -		    :
> -		    :
> -		    : "memory", "cc");
> +		wfi();
>  
>  		if (pen_release == cpu_logical_map(cpu)) {
>  			/*
> 


-- 
Tushar Behera


From kgene.kim at samsung.com  Tue Apr  2 04:30:39 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Tue, 02 Apr 2013 17:30:39 +0900
Subject: [PATCH 00/21] Various fixes and extensions to Exynos4 clock driver
In-Reply-To: <1496108.NDegb7PXrt@flatron>
References: <1364382178-25248-1-git-send-email-t.figa@samsung.com>
 <CAJuYYwQap4pZ6qTgBPGeSWbMFm-ZhqLfv7wBMVYjK1v0YHr_kQ@mail.gmail.com>
 <1496108.NDegb7PXrt@flatron>
Message-ID: <22e101ce2f7c$5b6a0cd0$123e2670$%kim@samsung.com>

Tomasz Figa wrote:
> 
> On Saturday 30 of March 2013 15:33:00 Thomas Abraham wrote:
> > Hi Tomasz,
> >
> > On 27 March 2013 16:32, Tomasz Figa <t.figa at samsung.com> wrote:
> > > This series is a collection of various fixes and extensions to Exynos4
> > > clock driver, which improve coverage of clocks present on Exynos4 SoCs
> > > and fix problems discovered during our internal work and testing.
> >
> > Nice series. Thanks for the improvements and fixes. Looking at the
> > second patch in this series, I crossed checked again with the
> > Exynos4412 user manual that I have. Your modifications are different
> > from what the manual has listed. I suspect, you have a newer copy of
> > the manual.
> 
> Right. I have checked revisions 0.0, 0.1 and 1.1 of the manual and indeed
> there are differences in clock layout between 0.1 and 1.1. My patches are
> based on revision 1.1.
> 
Correct...hmm...

> > For this series:
> > Reviewed-by: Thomas Abraham <thomas.abraham at linaro.org>
> 
Yes, looks good to me but would be better if I could get Mike's ack on this
series.

Thanks.

- Kukjin



From nsekhar at ti.com  Tue Apr  2 04:33:34 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Tue, 2 Apr 2013 14:03:34 +0530
Subject: [PATCH v3 3/3] ARM: davinci: da850: add EHRPWM & ECAP DT node
In-Reply-To: <1364197789-16783-4-git-send-email-avinashphilip@ti.com>
References: <1364197789-16783-1-git-send-email-avinashphilip@ti.com>
 <1364197789-16783-4-git-send-email-avinashphilip@ti.com>
Message-ID: <515A97DE.1080403@ti.com>

On 3/25/2013 1:19 PM, Philip Avinash wrote:
> Add da850 EHRPWM & ECAP DT node.
> Also adds OF_DEV_AUXDATA for EHRPWM & ECAP driver to use EHRPWM & ECAP
> clock.

This looks fine to me but I will wait for the bindings to get accepted
before taking this one.

Thanks,
Sekhar


From nsekhar at ti.com  Tue Apr  2 04:35:09 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Tue, 2 Apr 2013 14:05:09 +0530
Subject: [PATCH v3 0/3] Platform support for EHRPWM & ECAP devices in
 DAVINCI.
In-Reply-To: <1364197789-16783-1-git-send-email-avinashphilip@ti.com>
References: <1364197789-16783-1-git-send-email-avinashphilip@ti.com>
Message-ID: <515A983D.8040907@ti.com>

On 3/25/2013 1:19 PM, Philip Avinash wrote:
> Add platform support for EHRPWM and ECAP by providing clock nodes and
> device tree nodes.
> This series depends on [1] and [2] and is available for testing at [3].
> Tested for back light support in da850 EVM with EHRPWM PWM device.
> 
> [1] http://gitorious.org/linux-davinci/linux-davinci/trees/davinci-for-v3.9/dt-2
> [2] https://gitorious.org/linux-pwm/linux-pwm/trees/for-next
> [3] https://github.com/avinashphilip/am335x_linux/tree/davinci-for-v3.9_soc_pwm
> 
> Note:
> DT support for EHRPWM backlight has not been added in da850-evm.dts as there is
> conflicting pin-mux requirement with SPI flash.

Can you check if this is really true even in newer boards (have a look
at the latest schematics)? I remember this used to be a problem in very
early versions but was fixed later.

Thanks,
Sekhar


From kishon at ti.com  Tue Apr  2 04:37:07 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Tue, 2 Apr 2013 14:07:07 +0530
Subject: [PATCH v4 1/6] drivers: phy: add generic PHY framework
In-Reply-To: <5154658A.3080209@wwwdotorg.org>
References: <1364449408-9510-1-git-send-email-kishon@ti.com>
 <1364449408-9510-2-git-send-email-kishon@ti.com>
 <5154658A.3080209@wwwdotorg.org>
Message-ID: <515A98B3.7090405@ti.com>

Hi,

On Thursday 28 March 2013 09:15 PM, Stephen Warren wrote:
> On 03/27/2013 11:43 PM, Kishon Vijay Abraham I wrote:
>> The PHY framework provides a set of APIs for the PHY drivers to
>> create/destroy a PHY and APIs for the PHY users to obtain a reference to the
>
>> diff --git a/Documentation/devicetree/bindings/phy/phy-bindings.txt b/Documentation/devicetree/bindings/phy/phy-bindings.txt
>
>> +This document explains only the dt data binding. For general information about
>> +PHY subsystem refer Documentation/phy.txt
>> +
>> +PHY device node
>> +===============
>> +
>> +Optional Properties:
>> +#phy-cells:	Number of cells in a PHY specifier;  The meaning of all those
>> +		cells is defined by the binding for the phy node. However
>> +		in-order to return the correct PHY, the PHY susbsystem
>> +		requires the first cell always refers to the port.
>
> Why impose that restriction? Other DT bindings do not.
>
> This is typically implemented by having each provider driver implement a
> .of_xlate() operation, which parses all of the specifier cells, and
> returns the ID of the object it represents. This allows bindings to use
> whatever arbitrary representation they want.

Do you mean something like this

struct phy *of_phy_get(struct device *dev, int index)
{
	struct phy *phy = NULL;
	struct phy_bind *phy_map = NULL;
	struct of_phandle_args args;
	struct device_node *node;

	if (!dev->of_node) {
		dev_dbg(dev, "device does not have a device node entry\n");
		return ERR_PTR(-EINVAL);
	}

	ret = of_parse_phandle_with_args(dev->of_node, "phys", "#phy-cells",
		index, &args);
	if (ret) {
		dev_dbg(dev, "failed to get phy in %s node\n",
			dev->of_node->full_name);
		return ERR_PTR(-ENODEV);
	}

//Here we have to get a reference to the phy in order to call of_xlate 
which seems a little hacky to me. I'm not sure how else can we call the 
provider driver :-(
	phy = of_phy_lookup(dev, node);
	if (IS_ERR(phy) || !try_module_get(phy->ops->owner)) {
		phy = ERR_PTR(-EPROBE_DEFER);
		goto err0;
	}

//here we are checking if the phy has additional specifiers and if so 
call of_xlate using the phy we just obtained. The provider driver should 
check the args and return the appropriate *phy in this case.
	if (args.args_count > 0) {
		phy = phy->of_xlate(&args);
		if (IS_ERR(phy))
			goto err0;
	}

	phy_map = phy_bind(dev_name(dev), index, dev_name(&phy->dev));
	if (!IS_ERR(phy_map)) {
		phy_map->phy = phy;
		phy_map->auto_bind = true;
	}

	get_device(&phy->dev);

err0:
	of_node_put(node);

	return phy;
}
EXPORT_SYMBOL_GPL(of_phy_get);
>
> For the common/simple cases where #phy-cells==0, or #phy-cells==1 and
> directly represents the PHY ID, the PHY core can provide an
> implementation of that common .of_xlate() function, which PHY provider
> drivers can simply plug in as their .of_xlate() function.
>
>> +This property is optional because it is needed only for the case where a
>> +single IP implements multiple PHYs.
>
> The property should always exist so that the DT-parsing code in the PHY
> core can always validate exactly how many cells are present in the PHY
> specifier.
>
>> +
>> +For example:
>> +
>> +phys: phy {
>> +    compatible = "xxx";
>> +    reg1 = <...>;
>> +    reg2 = <...>;
>> +    reg3 = <...>;
>
> 3 separate reg values should be 3 separate entries in a single reg
> property, not 3 separate reg properties, with non-standard names.
>
>> +    .
>> +    .
>> +    #phy-cells = <1>;
>> +    .
>> +    .
>> +};
>> +
>> +That node describes an IP block that implements 3 different PHYs. In order to
>> +differentiate between these 3 PHYs, an additonal specifier should be given
>> +while trying to get a reference to it. (The PHY subsystem assumes the
>> +specifier is port id).
>
> A single DT node would typically represent a single HW IP block, and
> hence typically have a single reg property. If there are 3 separate HW
> IP blocks, and their register aren't interleaved, and hence can be
> represented by 3 separate reg values, then I'd typically expect to see 3
> separate DT nodes, one for each independent register range.
>
> The only case where I'd expect a single DT node to provide multipe PHYs,
> is when a single HW IP block actually implements multiple PHYs /and/ the
> registers for those 3 PHYs are interleaved (or share bits in the same
> registers) such that each PHY can't be represented by a separate
> non-overlapping reg property.
>
>> +example1:
>> +phys: phy {
>
> How about:
>
> Example 1:
>
> usb1: usb at xxx {
>
>> +};
>> +This node represents a controller that uses two PHYs one for usb2 and one for
>
> Blank line after }?
>
>> +usb3. The controller driver can get the appropriate PHY either by using
>> +devm_of_phy_get/of_phy_get by passing the correct index or by using
>> +of_phy_get_byname/devm_of_phy_get_byname by passing the names given in
>> +*phy-names*.
>
> Discussions of Linux-specific driver APIs should be in the Linux API
> documentation, not the DT binding documentation, which is supposed to be
> OS-agnostic. Instead, perhaps say:
>
> Individual bindings must specify the required set of entries the phys
> property. Bindings must also specify either a required order for those
> entries in the phys property, or specify required set of names that must
> be present in the phy-names property, in which case the order is arbitrary.
>
>> +example2:
>> +phys: phy {
>
> How about:
>
> Example 2:
>
> usb2: usb at yyy {
>
>> +This node represents a controller that uses one of the PHYs which is defined
>> +previously. Note that the phy handle has an additional specifier "1" to
>> +differentiate between the three PHYs. For this case, the controller driver
>> +should use of_phy_get_with_args/devm_of_phy_get_with_args.
>
> I think tha last sentence should be removed, and perhaps the previous
> sentence extended with:
>
> , as required by #phy-cells = <1> in the PHY provider node.
>
>> diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
>
>> +subsys_initcall(phy_core_init);
>
> Why not make that module_init(); device probe() ordering should be
> handled using -EPROBE_DEFER these days, so the exact initcall used
> doesn't really matter, and hence it'd be best to use the most common one
> rather than something unusual.

hmm.. ok.

Thanks
Kishon


From broonie at opensource.wolfsonmicro.com  Tue Apr  2 04:38:30 2013
From: broonie at opensource.wolfsonmicro.com (Mark Brown)
Date: Tue, 2 Apr 2013 09:38:30 +0100
Subject: [PATCH] ARM: ux500: update V-INTCORE constraints
In-Reply-To: <CACRpkdYgCxf9R1aU2QdPUBxErhK=E2tM=6L-yMLA_L3+ntj3nQ@mail.gmail.com>
References: <1364397694-14126-1-git-send-email-fabio.baltieri@linaro.org>
 <CACRpkdYgCxf9R1aU2QdPUBxErhK=E2tM=6L-yMLA_L3+ntj3nQ@mail.gmail.com>
Message-ID: <20130402083829.GB23065@opensource.wolfsonmicro.com>

On Tue, Apr 02, 2013 at 10:26:12AM +0200, Linus Walleij wrote:

> I know that Lee's been sending off a large set of regulator patches
> lately, some include alterations to this platform config.

> Maybe it's better to take this patch into the regulator tree if these
> machine configs will come in that way? Also like Lee to have a
> look at this...

If it's touching the board constraints it's likely to have conflicts
with Lee's stuff, yes.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130402/1decce6c/attachment-0001.sig>

From nsekhar at ti.com  Tue Apr  2 04:39:29 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Tue, 2 Apr 2013 14:09:29 +0530
Subject: [PATCH v7 1/5] mmc: davinci: allow driver to work without DMA
 resource
In-Reply-To: <1364476211-14322-2-git-send-email-prakash.pm@ti.com>
References: <1364476211-14322-1-git-send-email-prakash.pm@ti.com>
 <1364476211-14322-2-git-send-email-prakash.pm@ti.com>
Message-ID: <515A9941.9030708@ti.com>

On 3/28/2013 6:40 PM, Manjunathappa, Prakash wrote:
> Do not return probe failure with missing DMA resources,
> allow driver to work in PIO mode.
> Tested on da850-evm by mounting partition followed by
> file creation and deletion.
> 
> Signed-off-by: Manjunathappa, Prakash <prakash.pm at ti.com>
> Tested-by: Sekhar Nori <nsekhar at ti.com>

Chris accepted this patch on March 22nd. You should have dropped this
from this series.

Thanks,
Sekhar


From kishon at ti.com  Tue Apr  2 04:39:21 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Tue, 2 Apr 2013 14:09:21 +0530
Subject: [PATCH v4 1/6] drivers: phy: add generic PHY framework
In-Reply-To: <5159E157.6000800@gmail.com>
References: <1364449408-9510-1-git-send-email-kishon@ti.com>
 <1364449408-9510-2-git-send-email-kishon@ti.com> <5159E157.6000800@gmail.com>
Message-ID: <515A9939.40406@ti.com>

Hi,

On Tuesday 02 April 2013 01:04 AM, Sylwester Nawrocki wrote:
> Just couple minor comments...
>
> On 03/28/2013 06:43 AM, Kishon Vijay Abraham I wrote:
>> The PHY framework provides a set of APIs for the PHY drivers to
>> create/destroy a PHY and APIs for the PHY users to obtain a reference
>> to the
>> PHY with or without using phandle. To obtain a reference to the PHY
>> without
>> using phandle, the platform specfic intialization code (say from board
>> file)
>> should have already called phy_bind with the binding information. The
>> binding
>> information consists of phy's device name, phy user device name and an
>> index.
>> The index is used when the same phy user binds to mulitple phys.
>>
>> PHY drivers should create the PHY by passing phy_descriptor that has
>> describes the PHY (label, type etc..) and ops like init, exit,
>> suspend, resume,
>> poweron, shutdown.
>>
>> The documentation for the generic PHY framework is added in
>> Documentation/phy.txt and the documentation for the sysfs entry is added
>> in Documentation/ABI/testing/sysfs-class-phy and the documentation for
>> dt binding is can be found at
>> Documentation/devicetree/bindings/phy/phy-bindings.txt
>>
>> Signed-off-by: Kishon Vijay Abraham I<kishon at ti.com>
>> ---
> [...]
>> +/**
>> + * phy_put - release the PHY
>
> nit: According to kernel-doc documentation function names should have
> parentheses appended to the name. So it would need to be
>
> + * phy_put() - release the PHY
>
> in this case and it applies to multiple places elsewhere in this patch.

Will fix it.
>
>> + * @phy: the phy returned by phy_get()
>> + *
>> + * Releases a refcount the caller received from phy_get().
>> + */
>> +void phy_put(struct phy *phy)
>> +{
>> +    if (phy) {
>> +        module_put(phy->ops->owner);
>> +        put_device(&phy->dev);
>> +    }
>> +}
>> +EXPORT_SYMBOL_GPL(phy_put);
> [...]
>> +/**
>> + * devm_of_phy_get_byname - lookup and obtain a reference to a phy by
>> name
>> + * @dev: device that requests this phy
>> + * @string - the phy name as given in the dt data
>
> s/ -/:

Ok.
>
>> + *
>> + * Calls devm_of_phy_get (which associates the device with the phy
>> using devres
>> + * on successful phy get) and passes on the return value of
>> devm_of_phy_get.
>> + */
>> +struct phy *devm_of_phy_get_byname(struct device *dev, const char
>> *string)
>> +{
>> +    int index;
>> +
>> +    if (!dev->of_node) {
>> +        dev_dbg(dev, "device does not have a device node entry\n");
>> +        return ERR_PTR(-EINVAL);
>> +    }
>> +
>> +    index = of_property_match_string(dev->of_node, "phy-names", string);
>> +
>> +    return devm_of_phy_get(dev, index);
>> +}
>> +EXPORT_SYMBOL_GPL(devm_of_phy_get_byname);
>> +
>> +/**
>> + * phy_get - lookup and obtain a reference to a phy.
>> + * @dev: device that requests this phy
>> + * @index: the index of the phy
>> + *
>> + * Returns the phy driver, after getting a refcount to it; or
>> + * -ENODEV if there is no such phy.  The caller is responsible for
>> + * calling phy_put() to release that count.
>> + */
>> +struct phy *phy_get(struct device *dev, int index)
>> +{
>> +    struct phy *phy = NULL;
>
> Unneeded initialization.
>
>> +    phy = phy_lookup(dev, index);
>> +    if (IS_ERR(phy)) {
>> +        dev_err(dev, "unable to find phy\n");
>> +        goto err0;
>
> Wouldn't it be better to just do:

Indeed.
>
>          return phy;
>> +    }
>> +
>> +    if (!try_module_get(phy->ops->owner)) {
>> +        phy = ERR_PTR(-EPROBE_DEFER);
>
> and
>          return ERR_PTR(-EPROBE_DEFER);
>
>> +        goto err0;
>
> and to drop this goto and the label below ?
>
>> +    }
>> +
>> +    get_device(&phy->dev);
>> +
>> +err0:
>> +    return phy;
>> +}
>> +EXPORT_SYMBOL_GPL(phy_get);
>
>> diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
>> new file mode 100644
>> index 0000000..0cb2298
>> --- /dev/null
>> +++ b/include/linux/phy/phy.h
>> @@ -0,0 +1,237 @@
>> +/*
>> + * phy.h -- generic phy header file
> [...]
>> +#ifndef __DRIVERS_PHY_H
>> +#define __DRIVERS_PHY_H
>> +
>> +#include<linux/err.h>
>> +#include<linux/of.h>
>> +
>> +struct phy
>
> I think you also need to add either
>
> #include <linux/device.h>
>
> or
>
> struct device;
>
> struct device * is used further in this file.

Ok.
>
>> +/**
>> + * struct phy_ops - set of function pointers for performing phy
>> operations
>> + * @init: operation to be performed for initializing phy
>> + * @exit: operation to be performed while exiting
>> + * @suspend: suspending the phy
>> + * @resume: resuming the phy
>
>> + * @poweron: powering on the phy
>> + * @shutdown: shutting down the phy
>
> Could these be named power_on/power_off ? Looks a bit more symmetric
> to me that way.

Ok. Will have it that way.

Thanks
Kishon


From mark.rutland at arm.com  Tue Apr  2 04:41:39 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Tue, 2 Apr 2013 09:41:39 +0100
Subject: [PATCHv3 03/10] ARM: smp_twd: Divorce smp_twd from local timer API
In-Reply-To: <5154A37B.1070407@codeaurora.org>
References: <1363198676-30417-1-git-send-email-sboyd@codeaurora.org>
 <1363198676-30417-4-git-send-email-sboyd@codeaurora.org>
 <20130328152255.GD30477@e106331-lin.cambridge.arm.com>
 <5154A37B.1070407@codeaurora.org>
Message-ID: <20130402084138.GG30477@e106331-lin.cambridge.arm.com>

On Thu, Mar 28, 2013 at 08:09:31PM +0000, Stephen Boyd wrote:
> On 03/28/13 08:22, Mark Rutland wrote:
> > This works on my A9x4 coretile, bringing CPUs up and down via
> > /sys/devices/system/cpu/*/online, so:
> >
> > Tested-by: Mark Rutland <mark.rutland at arm.com>
> 
> Thanks. I still need to resolve patch #1 though.
> 
> >
> > Otherwise, is there any reason we couldn't now use the twd driver on a UP
> > system? Or would the overhead of handling frequency change make this pointless?
> 
> I don't see why not but I don't have any interest in pursuing it.

Ok.

> 
> >
> > On Wed, Mar 13, 2013 at 06:17:49PM +0000, Stephen Boyd wrote:
> >> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> >> index 5b71469..5ad2ccf 100644
> >> --- a/arch/arm/Kconfig
> >> +++ b/arch/arm/Kconfig
> >> @@ -1527,6 +1527,7 @@ config SMP
> >>  	depends on HAVE_SMP
> >>  	depends on MMU
> >>  	select HAVE_ARM_SCU if !ARCH_MSM_SCORPIONMP
> >> +	select HAVE_ARM_TWD if (!ARCH_MSM_SCORPIONMP && !EXYNOS4_MCT)
> > Could you not depend on your "Push selects for TWD/SCU into machine entries"
> > for this?
> 
> Right now the patches don't depend on the push down patch. Are you
> saying it would be better to depend on that patch?

It just seemed odd to me that the two series should conflict (though
trivially) here.

Mark.


From fabio.baltieri at linaro.org  Tue Apr  2 04:44:46 2013
From: fabio.baltieri at linaro.org (Fabio Baltieri)
Date: Tue, 2 Apr 2013 10:44:46 +0200
Subject: [PATCH] ARM: ux500: update V-INTCORE constraints
In-Reply-To: <20130402083829.GB23065@opensource.wolfsonmicro.com>
References: <1364397694-14126-1-git-send-email-fabio.baltieri@linaro.org>
 <CACRpkdYgCxf9R1aU2QdPUBxErhK=E2tM=6L-yMLA_L3+ntj3nQ@mail.gmail.com>
 <20130402083829.GB23065@opensource.wolfsonmicro.com>
Message-ID: <20130402084446.GA6850@balto.lan>

Hi Mark, Linus,

On Tue, Apr 02, 2013 at 09:38:30AM +0100, Mark Brown wrote:
> On Tue, Apr 02, 2013 at 10:26:12AM +0200, Linus Walleij wrote:
> 
> > I know that Lee's been sending off a large set of regulator patches
> > lately, some include alterations to this platform config.
> 
> > Maybe it's better to take this patch into the regulator tree if these
> > machine configs will come in that way? Also like Lee to have a
> > look at this...
> 
> If it's touching the board constraints it's likely to have conflicts
> with Lee's stuff, yes.

Lee's patches are on -next and should not conflict with this one
(tested again on today's tree), but it may be nice anyway to have this
in the regulator framework with the others.

Mark, would you consider taking this one in your tree?

Thanks,
Fabio

-- 
Fabio Baltieri


From broonie at opensource.wolfsonmicro.com  Tue Apr  2 04:46:58 2013
From: broonie at opensource.wolfsonmicro.com (Mark Brown)
Date: Tue, 2 Apr 2013 09:46:58 +0100
Subject: [PATCH] ARM: ux500: update V-INTCORE constraints
In-Reply-To: <20130402084446.GA6850@balto.lan>
References: <1364397694-14126-1-git-send-email-fabio.baltieri@linaro.org>
 <CACRpkdYgCxf9R1aU2QdPUBxErhK=E2tM=6L-yMLA_L3+ntj3nQ@mail.gmail.com>
 <20130402083829.GB23065@opensource.wolfsonmicro.com>
 <20130402084446.GA6850@balto.lan>
Message-ID: <20130402084658.GD23065@opensource.wolfsonmicro.com>

On Tue, Apr 02, 2013 at 10:44:46AM +0200, Fabio Baltieri wrote:

> Mark, would you consider taking this one in your tree?

If someone sends me the patch...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130402/f47d75a2/attachment.sig>

From ulf.hansson at linaro.org  Tue Apr  2 04:51:23 2013
From: ulf.hansson at linaro.org (Ulf Hansson)
Date: Tue, 2 Apr 2013 10:51:23 +0200
Subject: [PATCH V3 2/3] clk: Fixup errorhandling for clk_set_parent
In-Reply-To: <CA+Z25wV03YSu1wfTew8XN+z5WZ2BMWNQ-sj5PTv0Zog3b1bzbA@mail.gmail.com>
References: <1364377825-6171-1-git-send-email-ulf.hansson@stericsson.com>
 <1364377825-6171-3-git-send-email-ulf.hansson@stericsson.com>
 <CA+Z25wV03YSu1wfTew8XN+z5WZ2BMWNQ-sj5PTv0Zog3b1bzbA@mail.gmail.com>
Message-ID: <CAPDyKFpJAB6P+DWmL2J1cr=T6h9F63n28sMFNUyB7Z5sxxcvRg@mail.gmail.com>

On 28 March 2013 11:13, Rajagopal Venkat <rajagopal.venkat at linaro.org> wrote:
> On 27 March 2013 15:20, Ulf Hansson <ulf.hansson at stericsson.com> wrote:
>> From: Ulf Hansson <ulf.hansson at linaro.org>
>>
>> Fixup the broken feature of allowing reparent of a clk to the
>> orhpan list and vice verse. When operating on a single-parent
>> clk, the .set_parent callback for the clk hw is optional to
>> implement, but for a multi-parent clk it is mandatory.
>>
>> Moreover improve the errorhandling by verifying the prerequisites
>> before triggering clk notifiers. This will prevent unnecessary
>> rollback with ABORT_RATE_CHANGE.
>>
>> Signed-off-by: Ulf Hansson <ulf.hansson at linaro.org>
>> Cc: Rajagopal Venkat <rajagopal.venkat at linaro.org>
>> ---
>>  drivers/clk/clk.c |   56 ++++++++++++++++++++++++++++++++++-------------------
>>  1 file changed, 36 insertions(+), 20 deletions(-)
>>
>> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
>> index 97d681b..6fa301b 100644
>> --- a/drivers/clk/clk.c
>> +++ b/drivers/clk/clk.c
>> @@ -1269,15 +1269,10 @@ void __clk_reparent(struct clk *clk, struct clk *new_parent)
>>         __clk_recalc_rates(clk, POST_RATE_CHANGE);
>>  }
>>
>> -static int __clk_set_parent(struct clk *clk, struct clk *parent)
>> +static u8 clk_fetch_parent_index(struct clk *clk, struct clk *parent)
>>  {
>> -       struct clk *old_parent;
>> -       unsigned long flags;
>> -       int ret = -EINVAL;
>>         u8 i;
>>
>> -       old_parent = clk->parent;
>> -
>>         if (!clk->parents)
>>                 clk->parents = kzalloc((sizeof(struct clk*) * clk->num_parents),
>>                                                                 GFP_KERNEL);
>> @@ -1297,11 +1292,14 @@ static int __clk_set_parent(struct clk *clk, struct clk *parent)
>>                 }
>>         }
>>
>> -       if (i == clk->num_parents) {
>> -               pr_debug("%s: clock %s is not a possible parent of clock %s\n",
>> -                               __func__, parent->name, clk->name);
>> -               goto out;
>> -       }
>> +       return i;
>> +}
>> +
>> +static int __clk_set_parent(struct clk *clk, struct clk *parent, u8 p_index)
>> +{
>> +       unsigned long flags;
>> +       int ret = 0;
>> +       struct clk *old_parent = clk->parent;
>>
>>         /* migrate prepare and enable */
>>         if (clk->prepare_count)
>> @@ -1314,7 +1312,8 @@ static int __clk_set_parent(struct clk *clk, struct clk *parent)
>>         spin_unlock_irqrestore(&enable_lock, flags);
>>
>>         /* change clock input source */
>> -       ret = clk->ops->set_parent(clk->hw, i);
>> +       if (parent && clk->ops->set_parent)
>> +               ret = clk->ops->set_parent(clk->hw, p_index);
>
> What if clk->ops->set_parent() fails? should this clk undefined state
> be handled?

It must be handled, but it is not possible to do it unless the race
with locking issue is solved as well. Therefore the error handling is
added in the patch below instead, which is the next patch in this
patchset.

"clk: Fixup locking issues for clk_set_parent"

>
>>
>>         /* clean up old prepare and enable */
>>         spin_lock_irqsave(&enable_lock, flags);
>> @@ -1325,7 +1324,6 @@ static int __clk_set_parent(struct clk *clk, struct clk *parent)
>>         if (clk->prepare_count)
>>                 __clk_unprepare(old_parent);
>>
>> -out:
>>         return ret;
>>  }
>>
>> @@ -1344,11 +1342,14 @@ out:
>>  int clk_set_parent(struct clk *clk, struct clk *parent)
>>  {
>>         int ret = 0;
>> +       u8 p_index = 0;
>> +       unsigned long p_rate = 0;
>>
>>         if (!clk || !clk->ops)
>>                 return -EINVAL;
>>
>> -       if (!clk->ops->set_parent)
>> +       /* verify ops for for multi-parent clks */
>> +       if ((clk->num_parents > 1) && (!clk->ops->set_parent))
>>                 return -ENOSYS;
>
> Should this check be moved to clk registration path? clk ops
> validation is done in __clk_init().

I was thinking of doing that, but I would suggest to do this in a
separate patch instead. What to you think?

Right now there is no validation for any constraints for .set_parents
callbacks at all at clk init, well except that .get_parent and
.set_parent must exist together. I did not want to change too much in
this patchset, which is why I kept it as is.

>
>>
>>         /* prevent racing with updates to the clock topology */
>> @@ -1357,19 +1358,34 @@ int clk_set_parent(struct clk *clk, struct clk *parent)
>>         if (clk->parent == parent)
>>                 goto out;
>>
>> +       /* check that we are allowed to re-parent if the clock is in use */
>> +       if ((clk->flags & CLK_SET_PARENT_GATE) && clk->prepare_count) {
>> +               ret = -EBUSY;
>> +               goto out;
>> +       }
>> +
>> +       /* try finding the new parent index */
>> +       if (parent) {
>> +               p_index = clk_fetch_parent_index(clk, parent);
>> +               p_rate = parent->rate;
>> +               if (p_index == clk->num_parents) {
>> +                       pr_debug("%s: clk %s can not be parent of clk %s\n",
>> +                                       __func__, parent->name, clk->name);
>> +                       ret = -EINVAL;
>> +                       goto out;
>> +               }
>> +       }
>> +
>>         /* propagate PRE_RATE_CHANGE notifications */
>>         if (clk->notifier_count)
>> -               ret = __clk_speculate_rates(clk, parent->rate);
>> +               ret = __clk_speculate_rates(clk, p_rate);
>>
>>         /* abort if a driver objects */
>>         if (ret == NOTIFY_STOP)
>>                 goto out;
>>
>> -       /* only re-parent if the clock is not in use */
>> -       if ((clk->flags & CLK_SET_PARENT_GATE) && clk->prepare_count)
>> -               ret = -EBUSY;
>> -       else
>> -               ret = __clk_set_parent(clk, parent);
>> +       /* do the re-parent */
>> +       ret = __clk_set_parent(clk, parent, p_index);
>>
>>         /* propagate ABORT_RATE_CHANGE if .set_parent failed */
>>         if (ret) {
>> --
>> 1.7.10
>>
> In addition, this fix is required to allow reparenting of clk to orphan list.
>

This happens to be fixed by the patch prior this one in the this patchset.

clk: Restructure code for __clk_reparent


> ---
>  drivers/clk/clk.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index fb5d08a..ec436e0 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -1221,7 +1221,7 @@ void __clk_reparent(struct clk *clk, struct clk
> *new_parent)
>         struct dentry *new_parent_d;
>  #endif
>
> -       if (!clk || !new_parent)
> +       if (!clk)
>                 return;
>
>         hlist_del(&clk->child_node);
> --
> 1.7.10.4
>
>
> --
> Regards,
> Rajagopal

Kind regards
Ulf Hansson


From fabio.baltieri at linaro.org  Tue Apr  2 04:51:56 2013
From: fabio.baltieri at linaro.org (Fabio Baltieri)
Date: Tue,  2 Apr 2013 10:51:56 +0200
Subject: [PATCH RESEND] ARM: ux500: update V-INTCORE constraints
In-Reply-To: <20130402084658.GD23065@opensource.wolfsonmicro.com>
References: <20130402084658.GD23065@opensource.wolfsonmicro.com>
Message-ID: <1364892716-25505-1-git-send-email-fabio.baltieri@linaro.org>

Update V-INTCORE regulator constraints to allow voltage and
configuration changes from consumer drivers.

Signed-off-by: Fabio Baltieri <fabio.baltieri at linaro.org>
---
 arch/arm/mach-ux500/board-mop500-regulators.c | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-ux500/board-mop500-regulators.c b/arch/arm/mach-ux500/board-mop500-regulators.c
index 2a17bc5..0a428db 100644
--- a/arch/arm/mach-ux500/board-mop500-regulators.c
+++ b/arch/arm/mach-ux500/board-mop500-regulators.c
@@ -392,7 +392,15 @@ struct regulator_init_data ab8500_regulators[AB8500_NUM_REGULATORS] = {
 	[AB8500_LDO_INTCORE] = {
 		.constraints = {
 			.name = "V-INTCORE",
-			.valid_ops_mask = REGULATOR_CHANGE_STATUS,
+			.min_uV = 1250000,
+			.max_uV = 1350000,
+			.input_uV = 1800000,
+			.valid_ops_mask = REGULATOR_CHANGE_VOLTAGE |
+					  REGULATOR_CHANGE_STATUS |
+					  REGULATOR_CHANGE_MODE |
+					  REGULATOR_CHANGE_DRMS,
+			.valid_modes_mask = REGULATOR_MODE_NORMAL |
+					    REGULATOR_MODE_IDLE,
 		},
 		.num_consumer_supplies = ARRAY_SIZE(ab8500_vintcore_consumers),
 		.consumer_supplies = ab8500_vintcore_consumers,
-- 
1.8.1.3



From yuxu at marvell.com  Tue Apr  2 04:42:09 2013
From: yuxu at marvell.com (Yu Xu)
Date: Tue, 2 Apr 2013 01:42:09 -0700
Subject: [PATCH V2 6/6] usb: mv_usb: remove clock name from pdata
In-Reply-To: <20130402081449.GD30286@arwen.pp.htv.fi>
References: <1364195217-1226-1-git-send-email-chao.xie@marvell.com>
 <1364195217-1226-7-git-send-email-chao.xie@marvell.com>
 <20130402081449.GD30286@arwen.pp.htv.fi>
Message-ID: <4737A960563B524DA805CA602BE04B3069CB36D772@SC-VEXCH2.marvell.com>

Hi,

> -----Original Message-----
> From: Felipe Balbi [mailto:balbi at ti.com]
> Sent: 2013?4?2? 16:15
> To: Chao Xie
> Cc: linux-usb at vger.kernel.org; linux-arm-kernel at lists.infradead.org;
> haojian.zhuang at gmail.com; balbi at ti.com; xiechao.mail at gmail.com; Yu Xu
> Subject: Re: [PATCH V2 6/6] usb: mv_usb: remove clock name from pdata
> 
> Hi,
> 
> On Mon, Mar 25, 2013 at 03:06:57AM -0400, Chao Xie wrote:
> > Using pdata to pass clock name is not correct.
> > Directly get clock from usb drivers.
> >
> > Signed-off-by: Chao Xie <chao.xie at marvell.com>
> > ---
> >  include/linux/platform_data/mv_usb.h |    2 --
> >  1 files changed, 0 insertions(+), 2 deletions(-)
> >
> > diff --git a/include/linux/platform_data/mv_usb.h
> > b/include/linux/platform_data/mv_usb.h
> > index 944b01d..98b7925 100644
> > --- a/include/linux/platform_data/mv_usb.h
> > +++ b/include/linux/platform_data/mv_usb.h
> > @@ -34,8 +34,6 @@ struct mv_usb_addon_irq {  };
> >
> >  struct mv_usb_platform_data {
> > -	unsigned int		clknum;
> > -	char			**clkname;
> 
> this patch breaks mv_u3d_core.c, I have added another patch to the
> series (see below), let me know if this isn't the right fix.
> 
> From 49c1bfb43cbd1228abfffbc8d0ebb2e510b93bd7 Mon Sep 17 00:00:00 2001
> From: Felipe Balbi <balbi at ti.com>
> Date: Tue, 2 Apr 2013 11:12:11 +0300
> Subject: [PATCH] usb: gadget: mv_u3d_core: remove unused clock
> 
> The origianl understanding of clock is wrong. The UDC controller only
> have one clock input.
> Passing clock name by pdata is wrong. The clock is defined by device
> iteself.
> 
> Cc: Chao Xie <chao.xie at marvell.com>
> Cc: Yu Xu <yuxu at marvell.com>
> Signed-off-by: Felipe Balbi <balbi at ti.com>
> ---
>  drivers/usb/gadget/mv_u3d_core.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/gadget/mv_u3d_core.c
> b/drivers/usb/gadget/mv_u3d_core.c
> index 9675227..58288e9 100644
> --- a/drivers/usb/gadget/mv_u3d_core.c
> +++ b/drivers/usb/gadget/mv_u3d_core.c
> @@ -1821,7 +1821,7 @@ static int mv_u3d_probe(struct platform_device
> *dev)
>  	u3d->dev = &dev->dev;
>  	u3d->vbus = pdata->vbus;
> 
> -	u3d->clk = clk_get(&dev->dev, pdata->clkname[0]);
> +	u3d->clk = clk_get(&dev->dev, NULL);
>  	if (IS_ERR(u3d->clk)) {
>  		retval = PTR_ERR(u3d->clk);
>  		goto err_get_clk;
> --
> 1.8.2
> 
> --
> balbi

Acked-by: Yu Xu <yuxu at marvell.com>

Regards,
Yu Xu



From lee.jones at linaro.org  Tue Apr  2 05:23:05 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Tue, 2 Apr 2013 10:23:05 +0100
Subject: [PATCH RESEND] ARM: ux500: update V-INTCORE constraints
In-Reply-To: <1364892716-25505-1-git-send-email-fabio.baltieri@linaro.org>
References: <20130402084658.GD23065@opensource.wolfsonmicro.com>
 <1364892716-25505-1-git-send-email-fabio.baltieri@linaro.org>
Message-ID: <20130402092305.GA4375@gmail.com>

On Tue, 02 Apr 2013, Fabio Baltieri wrote:

> Update V-INTCORE regulator constraints to allow voltage and
> configuration changes from consumer drivers.
> 
> Signed-off-by: Fabio Baltieri <fabio.baltieri at linaro.org>
> ---
>  arch/arm/mach-ux500/board-mop500-regulators.c | 10 +++++++++-
>  1 file changed, 9 insertions(+), 1 deletion(-)

I already have this queued.

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From ulf.hansson at linaro.org  Tue Apr  2 05:23:47 2013
From: ulf.hansson at linaro.org (Ulf Hansson)
Date: Tue, 2 Apr 2013 11:23:47 +0200
Subject: [PATCH 1/2] clk: abstract locking out into helper functions
In-Reply-To: <1364504343-12635-2-git-send-email-mturquette@linaro.org>
References: <1364445958-2999-1-git-send-email-mturquette@linaro.org>
 <1364504343-12635-1-git-send-email-mturquette@linaro.org>
 <1364504343-12635-2-git-send-email-mturquette@linaro.org>
Message-ID: <CAPDyKFphM60Z=W9PNR3=gSXF61_0eTPWYqcKubnzQSFeYabvRg@mail.gmail.com>

On 28 March 2013 21:59, Mike Turquette <mturquette at linaro.org> wrote:
> Create locking helpers for the global mutex and global spinlock.  The
> definitions of these helpers will be expanded upon in the next patch
> which introduces reentrancy into the locking scheme.
>
> Signed-off-by: Mike Turquette <mturquette at linaro.org>
> Cc: Rajagopal Venkat <rajagopal.venkat at linaro.org>
> Cc: David Brown <davidb at codeaurora.org>
> Cc: Ulf Hansson <ulf.hansson at linaro.org>
> Tested-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
> Reviewed-by: Thomas Gleixner <tglx at linutronix.de>
> ---
> Changes since v5:
>  * pass flags by value instead of by reference in clk_enable_{un}lock
>
>  drivers/clk/clk.c |   99 +++++++++++++++++++++++++++++++++--------------------
>  1 file changed, 61 insertions(+), 38 deletions(-)
>
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index 5e8ffff..0b5d612 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -27,6 +27,29 @@ static HLIST_HEAD(clk_root_list);
>  static HLIST_HEAD(clk_orphan_list);
>  static LIST_HEAD(clk_notifier_list);
>
> +/***           locking             ***/
> +static void clk_prepare_lock(void)
> +{
> +       mutex_lock(&prepare_lock);
> +}
> +
> +static void clk_prepare_unlock(void)
> +{
> +       mutex_unlock(&prepare_lock);
> +}
> +
> +static unsigned long clk_enable_lock(void)
> +{
> +       unsigned long flags;
> +       spin_lock_irqsave(&enable_lock, flags);
> +       return flags;
> +}
> +
> +static void clk_enable_unlock(unsigned long flags)
> +{
> +       spin_unlock_irqrestore(&enable_lock, flags);
> +}
> +
>  /***        debugfs support        ***/
>
>  #ifdef CONFIG_COMMON_CLK_DEBUG
> @@ -69,7 +92,7 @@ static int clk_summary_show(struct seq_file *s, void *data)
>         seq_printf(s, "   clock                        enable_cnt  prepare_cnt  rate\n");
>         seq_printf(s, "---------------------------------------------------------------------\n");
>
> -       mutex_lock(&prepare_lock);
> +       clk_prepare_lock();
>
>         hlist_for_each_entry(c, &clk_root_list, child_node)
>                 clk_summary_show_subtree(s, c, 0);
> @@ -77,7 +100,7 @@ static int clk_summary_show(struct seq_file *s, void *data)
>         hlist_for_each_entry(c, &clk_orphan_list, child_node)
>                 clk_summary_show_subtree(s, c, 0);
>
> -       mutex_unlock(&prepare_lock);
> +       clk_prepare_unlock();
>
>         return 0;
>  }
> @@ -130,7 +153,7 @@ static int clk_dump(struct seq_file *s, void *data)
>
>         seq_printf(s, "{");
>
> -       mutex_lock(&prepare_lock);
> +       clk_prepare_lock();
>
>         hlist_for_each_entry(c, &clk_root_list, child_node) {
>                 if (!first_node)
> @@ -144,7 +167,7 @@ static int clk_dump(struct seq_file *s, void *data)
>                 clk_dump_subtree(s, c, 0);
>         }
>
> -       mutex_unlock(&prepare_lock);
> +       clk_prepare_unlock();
>
>         seq_printf(s, "}");
>         return 0;
> @@ -316,7 +339,7 @@ static int __init clk_debug_init(void)
>         if (!orphandir)
>                 return -ENOMEM;
>
> -       mutex_lock(&prepare_lock);
> +       clk_prepare_lock();
>
>         hlist_for_each_entry(clk, &clk_root_list, child_node)
>                 clk_debug_create_subtree(clk, rootdir);
> @@ -326,7 +349,7 @@ static int __init clk_debug_init(void)
>
>         inited = 1;
>
> -       mutex_unlock(&prepare_lock);
> +       clk_prepare_unlock();
>
>         return 0;
>  }
> @@ -372,7 +395,7 @@ static void clk_disable_unused_subtree(struct clk *clk)
>         hlist_for_each_entry(child, &clk->children, child_node)
>                 clk_disable_unused_subtree(child);
>
> -       spin_lock_irqsave(&enable_lock, flags);
> +       flags = clk_enable_lock();
>
>         if (clk->enable_count)
>                 goto unlock_out;
> @@ -393,7 +416,7 @@ static void clk_disable_unused_subtree(struct clk *clk)
>         }
>
>  unlock_out:
> -       spin_unlock_irqrestore(&enable_lock, flags);
> +       clk_enable_unlock(flags);
>
>  out:
>         return;
> @@ -403,7 +426,7 @@ static int clk_disable_unused(void)
>  {
>         struct clk *clk;
>
> -       mutex_lock(&prepare_lock);
> +       clk_prepare_lock();
>
>         hlist_for_each_entry(clk, &clk_root_list, child_node)
>                 clk_disable_unused_subtree(clk);
> @@ -417,7 +440,7 @@ static int clk_disable_unused(void)
>         hlist_for_each_entry(clk, &clk_orphan_list, child_node)
>                 clk_unprepare_unused_subtree(clk);
>
> -       mutex_unlock(&prepare_lock);
> +       clk_prepare_unlock();
>
>         return 0;
>  }
> @@ -600,9 +623,9 @@ void __clk_unprepare(struct clk *clk)
>   */
>  void clk_unprepare(struct clk *clk)
>  {
> -       mutex_lock(&prepare_lock);
> +       clk_prepare_lock();
>         __clk_unprepare(clk);
> -       mutex_unlock(&prepare_lock);
> +       clk_prepare_unlock();
>  }
>  EXPORT_SYMBOL_GPL(clk_unprepare);
>
> @@ -648,9 +671,9 @@ int clk_prepare(struct clk *clk)
>  {
>         int ret;
>
> -       mutex_lock(&prepare_lock);
> +       clk_prepare_lock();
>         ret = __clk_prepare(clk);
> -       mutex_unlock(&prepare_lock);
> +       clk_prepare_unlock();
>
>         return ret;
>  }
> @@ -692,9 +715,9 @@ void clk_disable(struct clk *clk)
>  {
>         unsigned long flags;
>
> -       spin_lock_irqsave(&enable_lock, flags);
> +       flags = clk_enable_lock();
>         __clk_disable(clk);
> -       spin_unlock_irqrestore(&enable_lock, flags);
> +       clk_enable_unlock(flags);
>  }
>  EXPORT_SYMBOL_GPL(clk_disable);
>
> @@ -745,9 +768,9 @@ int clk_enable(struct clk *clk)
>         unsigned long flags;
>         int ret;
>
> -       spin_lock_irqsave(&enable_lock, flags);
> +       flags = clk_enable_lock();
>         ret = __clk_enable(clk);
> -       spin_unlock_irqrestore(&enable_lock, flags);
> +       clk_enable_unlock(flags);
>
>         return ret;
>  }
> @@ -792,9 +815,9 @@ long clk_round_rate(struct clk *clk, unsigned long rate)
>  {
>         unsigned long ret;
>
> -       mutex_lock(&prepare_lock);
> +       clk_prepare_lock();
>         ret = __clk_round_rate(clk, rate);
> -       mutex_unlock(&prepare_lock);
> +       clk_prepare_unlock();
>
>         return ret;
>  }
> @@ -889,13 +912,13 @@ unsigned long clk_get_rate(struct clk *clk)
>  {
>         unsigned long rate;
>
> -       mutex_lock(&prepare_lock);
> +       clk_prepare_lock();
>
>         if (clk && (clk->flags & CLK_GET_RATE_NOCACHE))
>                 __clk_recalc_rates(clk, 0);
>
>         rate = __clk_get_rate(clk);
> -       mutex_unlock(&prepare_lock);
> +       clk_prepare_unlock();
>
>         return rate;
>  }
> @@ -1100,7 +1123,7 @@ int clk_set_rate(struct clk *clk, unsigned long rate)
>         int ret = 0;
>
>         /* prevent racing with updates to the clock topology */
> -       mutex_lock(&prepare_lock);
> +       clk_prepare_lock();
>
>         /* bail early if nothing to do */
>         if (rate == clk->rate)
> @@ -1132,7 +1155,7 @@ int clk_set_rate(struct clk *clk, unsigned long rate)
>         clk_change_rate(top);
>
>  out:
> -       mutex_unlock(&prepare_lock);
> +       clk_prepare_unlock();
>
>         return ret;
>  }
> @@ -1148,9 +1171,9 @@ struct clk *clk_get_parent(struct clk *clk)
>  {
>         struct clk *parent;
>
> -       mutex_lock(&prepare_lock);
> +       clk_prepare_lock();
>         parent = __clk_get_parent(clk);
> -       mutex_unlock(&prepare_lock);
> +       clk_prepare_unlock();
>
>         return parent;
>  }
> @@ -1294,19 +1317,19 @@ static int __clk_set_parent(struct clk *clk, struct clk *parent)
>                 __clk_prepare(parent);
>
>         /* FIXME replace with clk_is_enabled(clk) someday */
> -       spin_lock_irqsave(&enable_lock, flags);
> +       flags = clk_enable_lock();
>         if (clk->enable_count)
>                 __clk_enable(parent);
> -       spin_unlock_irqrestore(&enable_lock, flags);
> +       clk_enable_unlock(flags);
>
>         /* change clock input source */
>         ret = clk->ops->set_parent(clk->hw, i);
>
>         /* clean up old prepare and enable */
> -       spin_lock_irqsave(&enable_lock, flags);
> +       flags = clk_enable_lock();
>         if (clk->enable_count)
>                 __clk_disable(old_parent);
> -       spin_unlock_irqrestore(&enable_lock, flags);
> +       clk_enable_unlock(flags);
>
>         if (clk->prepare_count)
>                 __clk_unprepare(old_parent);
> @@ -1338,7 +1361,7 @@ int clk_set_parent(struct clk *clk, struct clk *parent)
>                 return -ENOSYS;
>
>         /* prevent racing with updates to the clock topology */
> -       mutex_lock(&prepare_lock);
> +       clk_prepare_lock();
>
>         if (clk->parent == parent)
>                 goto out;
> @@ -1367,7 +1390,7 @@ int clk_set_parent(struct clk *clk, struct clk *parent)
>         __clk_reparent(clk, parent);
>
>  out:
> -       mutex_unlock(&prepare_lock);
> +       clk_prepare_unlock();
>
>         return ret;
>  }
> @@ -1390,7 +1413,7 @@ int __clk_init(struct device *dev, struct clk *clk)
>         if (!clk)
>                 return -EINVAL;
>
> -       mutex_lock(&prepare_lock);
> +       clk_prepare_lock();
>
>         /* check to see if a clock with this name is already registered */
>         if (__clk_lookup(clk->name)) {
> @@ -1514,7 +1537,7 @@ int __clk_init(struct device *dev, struct clk *clk)
>         clk_debug_register(clk);
>
>  out:
> -       mutex_unlock(&prepare_lock);
> +       clk_prepare_unlock();
>
>         return ret;
>  }
> @@ -1748,7 +1771,7 @@ int clk_notifier_register(struct clk *clk, struct notifier_block *nb)
>         if (!clk || !nb)
>                 return -EINVAL;
>
> -       mutex_lock(&prepare_lock);
> +       clk_prepare_lock();
>
>         /* search the list of notifiers for this clk */
>         list_for_each_entry(cn, &clk_notifier_list, node)
> @@ -1772,7 +1795,7 @@ int clk_notifier_register(struct clk *clk, struct notifier_block *nb)
>         clk->notifier_count++;
>
>  out:
> -       mutex_unlock(&prepare_lock);
> +       clk_prepare_unlock();
>
>         return ret;
>  }
> @@ -1797,7 +1820,7 @@ int clk_notifier_unregister(struct clk *clk, struct notifier_block *nb)
>         if (!clk || !nb)
>                 return -EINVAL;
>
> -       mutex_lock(&prepare_lock);
> +       clk_prepare_lock();
>
>         list_for_each_entry(cn, &clk_notifier_list, node)
>                 if (cn->clk == clk)
> @@ -1818,7 +1841,7 @@ int clk_notifier_unregister(struct clk *clk, struct notifier_block *nb)
>                 ret = -ENOENT;
>         }
>
> -       mutex_unlock(&prepare_lock);
> +       clk_prepare_unlock();
>
>         return ret;
>  }
> --
> 1.7.10.4
>

Reviewed-by: Ulf Hansson <ulf.hansson at linaro.org>


From lee.jones at linaro.org  Tue Apr  2 05:24:46 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Tue, 2 Apr 2013 10:24:46 +0100
Subject: [PATCH] ARM: ux500: update V-INTCORE constraints
In-Reply-To: <20130402084446.GA6850@balto.lan>
References: <1364397694-14126-1-git-send-email-fabio.baltieri@linaro.org>
 <CACRpkdYgCxf9R1aU2QdPUBxErhK=E2tM=6L-yMLA_L3+ntj3nQ@mail.gmail.com>
 <20130402083829.GB23065@opensource.wolfsonmicro.com>
 <20130402084446.GA6850@balto.lan>
Message-ID: <20130402092446.GB4375@gmail.com>

> > > I know that Lee's been sending off a large set of regulator patches
> > > lately, some include alterations to this platform config.
> > 
> > > Maybe it's better to take this patch into the regulator tree if these
> > > machine configs will come in that way? Also like Lee to have a
> > > look at this...
> > 
> > If it's touching the board constraints it's likely to have conflicts
> > with Lee's stuff, yes.
> 
> Lee's patches are on -next

Not all of them are on -next, but all are on the MLs.

I'm currently fixing up some of Mark's review comments in order to
re-submit the remainder.

> and should not conflict with this one
> (tested again on today's tree), but it may be nice anyway to have this
> in the regulator framework with the others.

> Mark, would you consider taking this one in your tree?

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From fabio.baltieri at linaro.org  Tue Apr  2 05:34:06 2013
From: fabio.baltieri at linaro.org (Fabio Baltieri)
Date: Tue, 2 Apr 2013 11:34:06 +0200
Subject: [PATCH RESEND] ARM: ux500: update V-INTCORE constraints
In-Reply-To: <20130402092305.GA4375@gmail.com>
References: <20130402084658.GD23065@opensource.wolfsonmicro.com>
 <1364892716-25505-1-git-send-email-fabio.baltieri@linaro.org>
 <20130402092305.GA4375@gmail.com>
Message-ID: <20130402093406.GA16789@balto.lan>

On Tue, Apr 02, 2013 at 10:23:05AM +0100, Lee Jones wrote:
> On Tue, 02 Apr 2013, Fabio Baltieri wrote:
> 
> > Update V-INTCORE regulator constraints to allow voltage and
> > configuration changes from consumer drivers.
> > 
> > Signed-off-by: Fabio Baltieri <fabio.baltieri at linaro.org>
> > ---
> >  arch/arm/mach-ux500/board-mop500-regulators.c | 10 +++++++++-
> >  1 file changed, 9 insertions(+), 1 deletion(-)
> 
> I already have this queued.

Ok, that was part of another yet to be merged series.

Mark, please ignore this one, sorry for the added noise.

Fabio

-- 
Fabio Baltieri


From ulf.hansson at linaro.org  Tue Apr  2 05:35:46 2013
From: ulf.hansson at linaro.org (Ulf Hansson)
Date: Tue, 2 Apr 2013 11:35:46 +0200
Subject: [PATCH 2/2] clk: allow reentrant calls into the clk framework
In-Reply-To: <1364504343-12635-3-git-send-email-mturquette@linaro.org>
References: <1364445958-2999-1-git-send-email-mturquette@linaro.org>
 <1364504343-12635-1-git-send-email-mturquette@linaro.org>
 <1364504343-12635-3-git-send-email-mturquette@linaro.org>
Message-ID: <CAPDyKFrNT9fUku-L_Djp-2NO_MSVpAKJ0ivT3Pf2Lht0FrzDeQ@mail.gmail.com>

On 28 March 2013 21:59, Mike Turquette <mturquette at linaro.org> wrote:
> Reentrancy into the clock framework is necessary for clock operations
> that result in nested calls to the clk api.  A common example is a clock
> that is prepared via an i2c transaction, such as a clock inside of a
> discrete audio chip or a power management IC.  The i2c subsystem itself
> will use the clk api resulting in a deadlock:
>
> clk_prepare(audio_clk)
>         i2c_transfer(..)
>                 clk_prepare(i2c_controller_clk)
>
> The ability to reenter the clock framework prevents this deadlock.
>
> Other use cases exist such as allowing .set_rate callbacks to call
> clk_set_parent to achieve the best rate, or to save power in certain
> configurations.  Yet another example is performing pinctrl operations
> from a clk_ops callback.  Calls into the pinctrl subsystem may call
> clk_{un}prepare on an unrelated clock.  Allowing for nested calls to
> reenter the clock framework enables both of these use cases.
>
> Reentrancy is implemented by two global pointers that track the owner
> currently holding a global lock.  One pointer tracks the owner during
> sleepable, mutex-protected operations and the other one tracks the owner
> during non-interruptible, spinlock-protected operations.
>
> When the clk framework is entered we try to hold the global lock.  If it
> is held we compare the current task against the current owner; a match
> implies a nested call and we reenter.  If the values do not match then
> we block on the lock until it is released.
>
> Signed-off-by: Mike Turquette <mturquette at linaro.org>
> Cc: Rajagopal Venkat <rajagopal.venkat at linaro.org>
> Cc: David Brown <davidb at codeaurora.org>
> Cc: Ulf Hansson <ulf.hansson at linaro.org>
> Tested-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
> Reviewed-by: Thomas Gleixner <tglx at linutronix.de>
> ---
> Changes since v5:
>  * fixed up typo in changelog
>
> Changes since v4:
>  * remove uneccesary atomic operations
>  * remove casting bugs
>  * place reentrancy logic into locking helper functions
>  * improve debugging with reference counting and WARNs
>
>  drivers/clk/clk.c |   44 ++++++++++++++++++++++++++++++++++++++++++--
>  1 file changed, 42 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index 0b5d612..0230c9d 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -19,10 +19,17 @@
>  #include <linux/of.h>
>  #include <linux/device.h>
>  #include <linux/init.h>
> +#include <linux/sched.h>
>
>  static DEFINE_SPINLOCK(enable_lock);
>  static DEFINE_MUTEX(prepare_lock);
>
> +static struct task_struct *prepare_owner;
> +static struct task_struct *enable_owner;
> +
> +static int prepare_refcnt;
> +static int enable_refcnt;
> +
>  static HLIST_HEAD(clk_root_list);
>  static HLIST_HEAD(clk_orphan_list);
>  static LIST_HEAD(clk_notifier_list);
> @@ -30,23 +37,56 @@ static LIST_HEAD(clk_notifier_list);
>  /***           locking             ***/
>  static void clk_prepare_lock(void)
>  {
> -       mutex_lock(&prepare_lock);
> +       if (!mutex_trylock(&prepare_lock)) {
> +               if (prepare_owner == current) {
> +                       prepare_refcnt++;
> +                       return;
> +               }
> +               mutex_lock(&prepare_lock);
> +       }
> +       WARN_ON_ONCE(prepare_owner != NULL);
> +       WARN_ON_ONCE(prepare_refcnt != 0);
> +       prepare_owner = current;
> +       prepare_refcnt = 1;
>  }
>
>  static void clk_prepare_unlock(void)
>  {
> +       WARN_ON_ONCE(prepare_owner != current);
> +       WARN_ON_ONCE(prepare_refcnt == 0);
> +
> +       if (--prepare_refcnt)
> +               return;
> +       prepare_owner = NULL;
>         mutex_unlock(&prepare_lock);
>  }
>
>  static unsigned long clk_enable_lock(void)
>  {
>         unsigned long flags;
> -       spin_lock_irqsave(&enable_lock, flags);
> +
> +       if (!spin_trylock_irqsave(&enable_lock, flags)) {
> +               if (enable_owner == current) {
> +                       enable_refcnt++;
> +                       return flags;
> +               }
> +               spin_lock_irqsave(&enable_lock, flags);
> +       }
> +       WARN_ON_ONCE(enable_owner != NULL);
> +       WARN_ON_ONCE(enable_refcnt != 0);
> +       enable_owner = current;
> +       enable_refcnt = 1;
>         return flags;
>  }
>
>  static void clk_enable_unlock(unsigned long flags)
>  {
> +       WARN_ON_ONCE(enable_owner != current);
> +       WARN_ON_ONCE(enable_refcnt == 0);
> +
> +       if (--enable_refcnt)
> +               return;
> +       enable_owner = NULL;
>         spin_unlock_irqrestore(&enable_lock, flags);
>  }
>
> --
> 1.7.10.4
>

Great piece of work!

Reviewed-by: Ulf Hansson <ulf.hansson at linaro.org>


From kgene.kim at samsung.com  Tue Apr  2 05:39:14 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Tue, 02 Apr 2013 18:39:14 +0900
Subject: [PATCH 1/2] ARM: S3C64XX: Clear DMA flags on channel request
In-Reply-To: <1364469746-5026-1-git-send-email-broonie@opensource.wolfsonmicro.com>
References: <1364469746-5026-1-git-send-email-broonie@opensource.wolfsonmicro.com>
Message-ID: <234801ce2f85$efe2d820$cfa88860$%kim@samsung.com>

Mark Brown wrote:
> 
> From: Charles Keepax <ckeepax at opensource.wolfsonmicro.com>
> 
> This patch clears the DMA flags when a DMA channel is requested. This is
> necessary because otherwise the channel may inherit incompatible
> settings from its last usage.
> 
> Signed-off-by: Charles Keepax <ckeepax at opensource.wolfsonmicro.com>
> Signed-off-by: Mark Brown <broonie at opensource.wolfsonmicro.com>
> ---
>  arch/arm/mach-s3c64xx/dma.c |    1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/mach-s3c64xx/dma.c b/arch/arm/mach-s3c64xx/dma.c
> index 6af1aa1..759846c 100644
> --- a/arch/arm/mach-s3c64xx/dma.c
> +++ b/arch/arm/mach-s3c64xx/dma.c
> @@ -509,6 +509,7 @@ int s3c2410_dma_request(enum dma_ch channel,
>  	chan->client = client;
>  	chan->in_use = 1;
>  	chan->peripheral = channel;
> +	chan->flags = 0;
> 
>  	local_irq_restore(flags);
> 
> --
> 1.7.10.4

Applied, thanks.

- Kukjin



From kgene.kim at samsung.com  Tue Apr  2 05:39:43 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Tue, 02 Apr 2013 18:39:43 +0900
Subject: [PATCH 2/2] ARM: S3C64XX: Slow down mic detection rate for wm5102
In-Reply-To: <1364469746-5026-2-git-send-email-broonie@opensource.wolfsonmicro.com>
References: <1364469746-5026-1-git-send-email-broonie@opensource.wolfsonmicro.com>
 <1364469746-5026-2-git-send-email-broonie@opensource.wolfsonmicro.com>
Message-ID: <234901ce2f86$01b22ba0$051682e0$%kim@samsung.com>

Mark Brown wrote:
> 
> From: Charles Keepax <ckeepax at opensource.wolfsonmicro.com>
> 
> A slightly slower rate provides more reliable jack detection during
> slower insertions.
> 
> Signed-off-by: Charles Keepax <ckeepax at opensource.wolfsonmicro.com>
> Signed-off-by: Mark Brown <broonie at opensource.wolfsonmicro.com>
> ---
>  arch/arm/mach-s3c64xx/mach-crag6410-module.c |    1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/mach-s3c64xx/mach-crag6410-module.c b/arch/arm/mach-
> s3c64xx/mach-crag6410-module.c
> index bf3d1c0..a946b75 100644
> --- a/arch/arm/mach-s3c64xx/mach-crag6410-module.c
> +++ b/arch/arm/mach-s3c64xx/mach-crag6410-module.c
> @@ -210,6 +210,7 @@ static struct arizona_pdata wm5102_reva_pdata = {
>  	.gpio_base = CODEC_GPIO_BASE,
>  	.irq_active_high = true,
>  	.micd_pol_gpio = CODEC_GPIO_BASE + 4,
> +	.micd_rate = 6,
>  	.gpio_defaults = {
>  		[2] = 0x10000, /* AIF3TXLRCLK */
>  		[3] = 0x4,     /* OPCLK */
> --
> 1.7.10.4

Applied, thanks.

- Kukjin



From kgene.kim at samsung.com  Tue Apr  2 05:50:29 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Tue, 02 Apr 2013 18:50:29 +0900
Subject: [PATCH] ARM: S5P64X0: Fix typo "CONFIG_S5P64X0_SETUP_SDHCI"
In-Reply-To: <1364637279.1345.115.camel@x61.thuisdomein>
References: <1364637279.1345.115.camel@x61.thuisdomein>
Message-ID: <237901ce2f87$826635b0$8732a110$%kim@samsung.com>

Paul Bolle wrote:
> 
> Commit ebc433c2890f8ecad2da39fe2dbf2b6e7b309afa ("ARM: S5P64X0: Add
> HSMMC setup for host Controller") added the Kconfig symbol
> S5P64X0_SETUP_SDHCI_GPIO. By accident it also used a macro
> CONFIG_S5P64X0_SETUP_SDHCI. Fix that typo.
> 
> Signed-off-by: Paul Bolle <pebolle at tiscali.nl>
> ---
> Untested. Since this typo has been in the tree since v3.3, and some code
> has therefore (basically) been compiled out ever since, this does need
> testing.
> 
>  arch/arm/plat-samsung/include/plat/sdhci.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/plat-samsung/include/plat/sdhci.h b/arch/arm/plat-
> samsung/include/plat/sdhci.h
> index 9b87f38..5560586 100644
> --- a/arch/arm/plat-samsung/include/plat/sdhci.h
> +++ b/arch/arm/plat-samsung/include/plat/sdhci.h
> @@ -206,7 +206,7 @@ static inline void s3c6400_default_sdhci2(void) { }
> 
>  /* S5P64X0 SDHCI setup */
> 
> -#ifdef CONFIG_S5P64X0_SETUP_SDHCI
> +#ifdef CONFIG_S5P64X0_SETUP_SDHCI_GPIO
>  static inline void s5p64x0_default_sdhci0(void)
>  {
>  #ifdef CONFIG_S3C_DEV_HSMMC
> @@ -241,7 +241,7 @@ static inline void s5p64x0_default_sdhci1(void) { }
>  static inline void s5p6440_default_sdhci2(void) { }
>  static inline void s5p6450_default_sdhci2(void) { }
> 
> -#endif /* CONFIG_S5P64X0_SETUP_SDHCI */
> +#endif /* CONFIG_S5P64X0_SETUP_SDHCI_GPIO */
> 
>  /* S5PC100 SDHCI setup */
> 
> --
> 1.7.11.7

Applied, thanks.

- Kukjin



From pdeschrijver at nvidia.com  Tue Apr  2 05:53:51 2013
From: pdeschrijver at nvidia.com (Peter De Schrijver)
Date: Tue, 2 Apr 2013 12:53:51 +0300
Subject: [PATCH 1/1] clk: Add notifier support in clk_prepare/clk_unprepare
In-Reply-To: <20130328220109.13785.58488@quantum>
References: <1363699712-8124-1-git-send-email-bilhuang@nvidia.com>
 <20130319170140.8663.93388@quantum>
 <1363748149.8815.16.camel@bilhuang-vm1>
 <20130320033142.11073.30097@quantum>
 <1363754384.8815.42.camel@bilhuang-vm1>
 <20130320144752.11073.653@quantum>
 <CAPDyKFr+Hqi8Dge3Hn55JXbqEP358F3Eq1OHdYy=2JxucJHtJg@mail.gmail.com>
 <20130321223619.834.31998@quantum>
 <CAMbhsRSSknsEX_gwAzPtV8b8kGdZyTpLEoT2uXaDKoCbpr3cJg@mail.gmail.com>
 <20130328220109.13785.58488@quantum>
Message-ID: <20130402095351.GA18519@tbergstrom-lnx.Nvidia.com>

On Thu, Mar 28, 2013 at 11:01:09PM +0100, Mike Turquette wrote:
> Quoting Colin Cross (2013-03-21 17:06:25)
> > On Thu, Mar 21, 2013 at 3:36 PM, Mike Turquette <mturquette at linaro.org> wrote:
> > > To my knowledge, devfreq performs one task: implements an algorithm
> > > (typically one that loops/polls) and applies this heuristic towards a
> > > dvfs transition.
> > >
> > > It is a policy layer, a high level layer.  It should not be used as a
> > > lower-level mechanism.  Please correct me if my understanding is wrong.
> > >
> > > I think the very idea of the clk framework calling into devfreq is
> > > backwards.  Ideally a devfreq driver would call clk_set_rate as part of
> > > it's target callback.  This is analogous to a cpufreq .target callback
> > > which calls clk_set_rate and regulator_set_voltage.  Can you imagine the
> > > clock framework cross-calling into cpufreq when clk_set_rate is called?
> > > I think that would be strange.
> > >
> > > I think that all of this discussion highlights the fact that there is a
> > > missing piece of infrastructure.  It isn't devfreq or clock rate-change
> > > notifiers.  It is that there is not a dvfs mechanism which neatly builds
> > > on top of these lower-level frameworks (clocks & regulators).  Clearly
> > > some higher-level abstraction layer is needed.
> > 
> > I went through all of this on Tegra2.  For a while I had a
> > dvfs_set_rate api for drivers that needed to modify the voltage when
> > they updated a clock, but I ended up dropping it.  Drivers rarely care
> > about the voltage, all they want to do is set their clock rate.  The
> > voltage necessary to support that clock is an implementation detail of
> > the silicon that is irrelevant to the driver
> 
> Hi Colin,
> 
> I agree about voltage scaling being an implementation detail,  but I
> think that drivers similarly do not care about enabling clocks, clock
> domains, power domains, voltage domains, etc.  The just want to say
> "give me what I need to turn on and run", and "I'm done with that stuff
> now, lazily turn off if you want to".  Runtime pm gives drivers that
> abstraction layer today.
> 
> There is a need for a similar abstraction layer for dvfs or, more
> generically, an abstraction layer for performance.  It is true that a
> driver doesn't care about scaling it's voltage, but it also might not
> care that its functional clock is changing rate, or that memory needs to
> run faster, or that an async bridge or interface clock needs to change
> it's rate.
> 

Drivers are the ones which need to indicate their performance constraints.
A single voltage domain can contain many blocks and also the clock can be
shared (eg. all graphics on Tegra20 and Tegra30 run from the same PLL, even
though there is a per block postdivider, we still want to vary the PLL
depending on load). The only realistic way of stating this kind of constraints
is using the clockrate I think. I don't see which other 'metric' would be
useful across different IP blocks.

Cheers,

Peter.


From kgene.kim at samsung.com  Tue Apr  2 05:55:08 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Tue, 02 Apr 2013 18:55:08 +0900
Subject: [PATCH] ARM: S3C64XX: remove obsolete Makefile line
In-Reply-To: <1364597502.1345.103.camel@x61.thuisdomein>
References: <1364597502.1345.103.camel@x61.thuisdomein>
Message-ID: <237a01ce2f88$28edbd90$7ac938b0$%kim@samsung.com>

Paul Bolle wrote:
> 
> Commit a07613a54d700a974f3a4a657da78ef5d097315d ("Merge branch
> 'samsung/dt' into samsung/cleanup") added this line to
> arch/arm/mach-s3c64xx/Makefile:
>     obj-$(CONFIG_S3C64XX_DEV_SPI)	+= dev-spi.o
> 
> But at that time CONFIG_S3C64XX_DEV_SPI wasn't a valid Kconfig macro
> anymore and arch/arm/mach-s3c64xx/dev-spi.c was already removed. So we
> can remove this line.
> 
Yes, the dev-spi.c has been removed with Consolidation work of SPI platform devices.

> Signed-off-by: Paul Bolle <pebolle at tiscali.nl>
> ---
> Untested.
> 
>  arch/arm/mach-s3c64xx/Makefile | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/arch/arm/mach-s3c64xx/Makefile b/arch/arm/mach-
> s3c64xx/Makefile
> index f9ce1dc..31d0c91 100644
> --- a/arch/arm/mach-s3c64xx/Makefile
> +++ b/arch/arm/mach-s3c64xx/Makefile
> @@ -32,7 +32,6 @@ obj-$(CONFIG_S3C64XX_DMA)	+= dma.o
> 
>  obj-y				+= dev-uart.o
>  obj-y				+= dev-audio.o
> -obj-$(CONFIG_S3C64XX_DEV_SPI)	+= dev-spi.o
> 
>  # Device setup
> 
> --
> 1.7.11.7
> 
Looks OK to me, applied.

Thanks.

- Kukjin



From prakash.pm at ti.com  Tue Apr  2 05:55:59 2013
From: prakash.pm at ti.com (Manjunathappa, Prakash)
Date: Tue, 2 Apr 2013 09:55:59 +0000
Subject: [PATCH v7 1/5] mmc: davinci: allow driver to work without DMA
 resource
In-Reply-To: <515A9941.9030708@ti.com>
References: <1364476211-14322-1-git-send-email-prakash.pm@ti.com>
 <1364476211-14322-2-git-send-email-prakash.pm@ti.com>
 <515A9941.9030708@ti.com>
Message-ID: <A73F36158E33644199EB82C5EC81C7BC3EA4BEAE@DBDE01.ent.ti.com>

On Tue, Apr 02, 2013 at 14:09:29, Nori, Sekhar wrote:
> On 3/28/2013 6:40 PM, Manjunathappa, Prakash wrote:
> > Do not return probe failure with missing DMA resources,
> > allow driver to work in PIO mode.
> > Tested on da850-evm by mounting partition followed by
> > file creation and deletion.
> > 
> > Signed-off-by: Manjunathappa, Prakash <prakash.pm at ti.com>
> > Tested-by: Sekhar Nori <nsekhar at ti.com>
> 
> Chris accepted this patch on March 22nd. You should have dropped this
> from this series.
> 

Thanks Sekhar, I missed Chris's reply somehow.

Chris,
Please ignore this patch.

Regards,
Prakash


From nsekhar at ti.com  Tue Apr  2 05:57:28 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Tue, 2 Apr 2013 15:27:28 +0530
Subject: [PATCH v7 0/5] Add DT support for davinci_mmc driver
In-Reply-To: <1364476211-14322-1-git-send-email-prakash.pm@ti.com>
References: <1364476211-14322-1-git-send-email-prakash.pm@ti.com>
Message-ID: <515AAB88.3030406@ti.com>

Hi Chris,

On 3/28/2013 6:40 PM, Manjunathappa, Prakash wrote:
> Patch set adds DT support for davinci_mmc driver and is
> verified on da850-evm without card_detect/write_protect and
> EDMA support. Also takecare to derive controller IP version from
> platform_device_id table, remove version specification in pdata.

> Manjunathappa, Prakash (5):
>   mmc: davinci: allow driver to work without DMA resource
>   ARM: davinci: mmc: derive version information from device name
>   mmc: davinci_mmc: add DT support
>   ARM: davinci: da850: add mmc DT entries
>   ARM: davinci: da850: override mmc DT node device name
> 
>  .../devicetree/bindings/mmc/davinci_mmc.txt        |   33 +++++++
>  arch/arm/boot/dts/da850-evm.dts                    |    7 ++
>  arch/arm/boot/dts/da850.dtsi                       |   15 +++
>  arch/arm/mach-davinci/board-da830-evm.c            |    1 -
>  arch/arm/mach-davinci/board-da850-evm.c            |    2 -
>  arch/arm/mach-davinci/board-dm355-evm.c            |    1 -
>  arch/arm/mach-davinci/board-dm365-evm.c            |    1 -
>  arch/arm/mach-davinci/board-dm644x-evm.c           |    1 -
>  arch/arm/mach-davinci/board-neuros-osd2.c          |    1 -
>  arch/arm/mach-davinci/board-omapl138-hawk.c        |    1 -
>  arch/arm/mach-davinci/board-tnetv107x-evm.c        |    1 -
>  arch/arm/mach-davinci/da830.c                      |    2 +-
>  arch/arm/mach-davinci/da850.c                      |    4 +-
>  arch/arm/mach-davinci/da8xx-dt.c                   |    1 +
>  arch/arm/mach-davinci/devices-da8xx.c              |    4 +-
>  arch/arm/mach-davinci/devices-tnetv107x.c          |    4 +-
>  arch/arm/mach-davinci/devices.c                    |    6 +-
>  arch/arm/mach-davinci/dm355.c                      |    4 +-
>  arch/arm/mach-davinci/dm365.c                      |    4 +-
>  arch/arm/mach-davinci/dm644x.c                     |    2 +-
>  arch/arm/mach-davinci/tnetv107x.c                  |    4 +-
>  drivers/mmc/host/davinci_mmc.c                     |   98 ++++++++++++++++++--
>  include/linux/platform_data/mmc-davinci.h          |    3 -
>  23 files changed, 163 insertions(+), 37 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/mmc/davinci_mmc.txt

I would like to take this series through DaVinci tree to manage the
dependencies with mach-davinci. I need your ack on the driver part and
the DT binding. Can you please provide your ack?

Thanks,
Sekhar


From nsekhar at ti.com  Tue Apr  2 06:02:05 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Tue, 2 Apr 2013 15:32:05 +0530
Subject: [PATCH v2] ARM: davinci: use is IS_ENABLED macro
In-Reply-To: <1364800424-4239-1-git-send-email-prabhakar.csengg@gmail.com>
References: <1364800424-4239-1-git-send-email-prabhakar.csengg@gmail.com>
Message-ID: <515AAC9D.4010001@ti.com>

On 4/1/2013 12:43 PM, Prabhakar lad wrote:
> From: Lad, Prabhakar <prabhakar.csengg at gmail.com>
> 
> This patches replaces #if defined() by IS_ENABLED macro, which provides
> better readability.
> 
> Signed-off-by: Lad, Prabhakar <prabhakar.csengg at gmail.com>
> Cc: Sekhar Nori <nsekhar at ti.com>
> Cc: Stephen Rothwell <sfr at canb.auug.org.au>
> Cc: Randy Dunlap <rdunlap at infradead.org>

I dropped earlier version of this patch and queued this one instead.

Thanks,
Sekhar


From kgene.kim at samsung.com  Tue Apr  2 06:04:35 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Tue, 02 Apr 2013 19:04:35 +0900
Subject: [PATCH] ARM: Fix typo "CONFIG_SAMSUNG_DEV_RTC"
In-Reply-To: <1364570435.1345.82.camel@x61.thuisdomein>
References: <1364570435.1345.82.camel@x61.thuisdomein>
Message-ID: <237b01ce2f89$7af00b60$70d02220$%kim@samsung.com>

Paul Bolle wrote:
> 
> s3c_rtc_setname() tests for CONFIG_SAMSUNG_DEV_RTC or
> CONFIG_PLAT_S3C24XX. But of these two macros only CONFIG_PLAT_S3C24XX
> actually exists. Now we can see that s3c_device_rtc is only defined if
> either CONFIG_PLAT_S3C24XX or CONFIG_S3C_DEV_RTC are defined. So,
> apparently, it was intended to use CONFIG_S3C_DEV_RTC here.
> 
> Signed-off-by: Paul Bolle <pebolle at tiscali.nl>
> ---
> 0) Untested.
> 
> 1) Introduced in commit commit b2994d318dc78c9a4a43605629f00217335ada28
> ("ARM: S3C2443/S3C2416: add s3c_rtc_setname and rename rtc devices"),
> which shipped in v3.4. Should this go to stable too (after testing)?
> 
Let me check again, and if required, I will add Cc to stable.

>  arch/arm/plat-samsung/include/plat/rtc-core.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/plat-samsung/include/plat/rtc-core.h
> b/arch/arm/plat-samsung/include/plat/rtc-core.h
> index 21d8594..7b542f7 100644
> --- a/arch/arm/plat-samsung/include/plat/rtc-core.h
> +++ b/arch/arm/plat-samsung/include/plat/rtc-core.h
> @@ -19,7 +19,7 @@
>  /* re-define device name depending on support. */
>  static inline void s3c_rtc_setname(char *name)
>  {
> -#if defined(CONFIG_SAMSUNG_DEV_RTC) || defined(CONFIG_PLAT_S3C24XX)
> +#if defined(CONFIG_S3C_DEV_RTC) || defined(CONFIG_PLAT_S3C24XX)

Yes, according to devs.c file in plat-samsung, SAMSUNG_DEV_RTC should be changed to S3C_DEV_RTC.

>  	s3c_device_rtc.name = name;
>  #endif
>  }
> --
> 1.7.11.7

Will apply after checking about stable, thanks.

- Kukjin



From nsekhar at ti.com  Tue Apr  2 06:08:22 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Tue, 2 Apr 2013 15:38:22 +0530
Subject: [PATCH] ARM: davinci: remove test for undefined Kconfig macro
In-Reply-To: <1364560405.1345.67.camel@x61.thuisdomein>
References: <1364557655.1345.58.camel@x61.thuisdomein>
 <1364560405.1345.67.camel@x61.thuisdomein>
Message-ID: <515AAE16.4080200@ti.com>

On 3/29/2013 6:03 PM, Paul Bolle wrote:
> [Dropped Kevin Hilman, because Kevin's address bounces.]

Use khilman at deeprootsystems.com as updated in MAINTAINERS.

> 
> On Fri, 2013-03-29 at 12:47 +0100, Paul Bolle wrote:
>> The DaVinci debugging macro contains a check for
>> CONFIG_DEBUG_DAVINCI_DA8XX_UART0. But there's corresponding Kconfig
> 
>                                   [...] there's no corresponding [...]
> 
>> symbol, so this test will always evaluate to false. That Kconfig symbol
>> is not needed because, as __arch_decomp_setup() shows, there are no
>> DaVinci DA8XX boards that use UART0 for debugging. We can remove two
>> lines of unneeded code.

Queuing this for v3.10 with updated commit text indicated above.

Thanks,
Sekhar


From arnd at arndb.de  Mon Apr  1 13:14:50 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 1 Apr 2013 17:14:50 +0000
Subject: [PATCH 1/2] ARM: tegra: move <mach/powergate.h> to
 <linux/tegra-powergate.h>
In-Reply-To: <5159B0FF.2010408@wwwdotorg.org>
References: <1364602790-10759-1-git-send-email-swarren@wwwdotorg.org>
 <201303301413.26549.arnd@arndb.de> <5159B0FF.2010408@wwwdotorg.org>
Message-ID: <201304011714.50703.arnd@arndb.de>

On Monday 01 April 2013, Stephen Warren wrote:
> On 03/30/2013 08:13 AM, Arnd Bergmann wrote:
> > On Saturday 30 March 2013, Stephen Warren wrote:

> > If not, we can probably take your patch for now, if you remove it
> > again for 3.11.
> 
> There are at least a couple of different things in this file:
> 
> a) The reset API, which definitely should be converted to the new reset
> API. I can't make any promises about which kernel release that will
> happen in, but it's definitely something we know we have to do.
> 
> b) Power-gating. This should probably be converted to use the
> powerdomains code. I believe Joseph Lo is aware of this, but again I
> can't promise any specific time-scale at this time.
> 
> So is this still OK, without any promises of timescale?
> 

Yes, sounds good.

	Arnd


From arnd at arndb.de  Tue Apr  2 06:09:34 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 2 Apr 2013 10:09:34 +0000
Subject: [GIT PULL v2] Renesas ARM-based SoC board updates for v3.10
In-Reply-To: <CANqRtoSBUt+G-GwBZ01FmOwgm3vp0_GYXBckOdEp-46A6G_LnA@mail.gmail.com>
References: <1363659481-5922-1-git-send-email-horms+renesas@verge.net.au>
 <201303271137.45652.arnd@arndb.de>
 <CANqRtoSBUt+G-GwBZ01FmOwgm3vp0_GYXBckOdEp-46A6G_LnA@mail.gmail.com>
Message-ID: <201304021009.35161.arnd@arndb.de>

On Monday 01 April 2013, Magnus Damm wrote:
> On Wed, Mar 27, 2013 at 8:37 PM, Arnd Bergmann <arnd at arndb.de> wrote:

> > Ok, I see. If you think it's not likely to be ready for 3.12, we might
> > need to discuss again whether there is another way of making the
> > common clk and the sh-clk code coexist. For instance, we could rename
> > all if the sh/shmobile specific clk functions and their users from
> > clk_* to shclk_*, and provide a thin wrapper around them that integrates
> > into common clk.
> 
> Yeah, I am not sure if it is likely that we will be able to convert
> all platforms at v3.12 timing.
> 
> I actually tried to let common clocks and sh-clk coexist when the
> common clock framework was under heavy development. I recall it being
> far from trivial.
> 
> One possible way to develop this could be to force the mach-shmobile
> "reference DT" implementations use common clocks and keep the old
> boards as-is. Then we can also make sure the "reference DT"
> implementations can be used as CONFIG_ARCH_MULTIPLATFORM. So if we
> only have "reference DT" code as MULTIPLATFORM and then finally kill
> off the old board code one by one.

Works for me, but wouldn't that mean that half the shmobile boards
become incompatible with the other half, forcing you to build two
separate kernels if you want to run on all the machines?

Maybe that's not a problem for you, since you tend to have per-soc
defconfigs  anyway, and it will only be temporary.

> Since we're on the topic of CONFIG_ARCH_MULTIPLATFORM, do you have any
> recommendatoin about LPAE?
> 
> Judging by the ARM_LPAE help text it seems that selecting ARM_LPAE
> will result in a kernel only working on LPAE hardware:
> 
> config ARM_LPAE
> [snip]
>           Say Y if you have an ARMv7 processor supporting the LPAE page
>           table format and you would like to access memory beyond the
>           4GB limit. The resulting kernel image will not run on
>           processors without the LPA extension.
> 
> With the above text it sounds to me like we should not to a "select
> ARM_LPAE" on each board in the case of CONFIG_ARCH_MULTIPLATFORM.

Correct.

> I sort of expect LPAE to behave similar to x86 PAE. At least the board
> DT file should describe all physical memory available and depending on
> kernel configuration (HIGHMEM=y/n, LPAE=y/n) we get different amounts
> of usable memory in the kernel. Then if LPAE should be selected or not
> is something that the distributions have to decide.

Yes. I believe all distros are planning to build one non-LPAE nd one
LPAE kernel. There will have to be a way to enable all LPAE-capable
platforms in Kconfig, but I don't know if that exists already.

Presumably, the LPAE kernel will also be using THUMB2 in the kernel,
while the non-LPAE kernel may get built with ARMv6 platform support
enabled, which rules out THUMB2.

Also, we could enable KVM support in the non-LPAE kernel, but since 
all KVM capable CPU cores (Cortex-A7 and Cortex-A15) so far also
come with LPAE, that's not even necessary.

You can always use #address-cells=<2> in the DT root node if that
helps, and you can also keep your peripherals using #address-cells=<1>
with an appropriate ranges property in the soc bus node.

	Arnd


From nsekhar at ti.com  Tue Apr  2 06:11:05 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Tue, 2 Apr 2013 15:41:05 +0530
Subject: [PATCH v4 0/5] Enable SPI flash support on da850-evm DT kernel
In-Reply-To: <51499A18.5020901@ti.com>
References: <1363776419-10563-1-git-send-email-prakash.pm@ti.com>
 <51499A18.5020901@ti.com>
Message-ID: <515AAEB9.7030602@ti.com>

On 3/20/2013 4:44 PM, Sekhar Nori wrote:
> Grant,
> 
> On 3/20/2013 4:16 PM, Manjunathappa, Prakash wrote:
>> Patch enables support for m25p64 SPI flash support on
>> da850-EVM.
> 
> With your ack, I would like to merge this series through davinci tree
> for v3.10. This will help manage dependencies for DT files.

Ping?

Thanks,
Sekhar


From s.nawrocki at samsung.com  Tue Apr  2 06:15:57 2013
From: s.nawrocki at samsung.com (Sylwester Nawrocki)
Date: Tue, 02 Apr 2013 12:15:57 +0200
Subject: EXYNOS will support only DT from v3.10
In-Reply-To: <17a501ce2948$17037610$450a6230$%kim@samsung.com>
References: <17a501ce2948$17037610$450a6230$%kim@samsung.com>
Message-ID: <515AAFDD.1060204@samsung.com>

On 03/25/2013 12:01 PM, Kukjin Kim wrote:
> Hi all,
> 
> As we discussed before, it's time to decide to support non-DT for EXYNOS
> SoCs.
> 
> If everybody else agrees to drop non-DT support from v3.10, I will. Feel
> free to talk your opinion about that.

I'm fine with supporting Exynos as dt-only from 3.10. We just need to
resolve some issues with samsung pwm/timers to get DT board support for
Universal_c210 working. Currently Tomasz Figa is working on it. Hopefully
it all can be finished this week.

I'll see if I can find some spare time and help out with porting S5PV210
to DT.


Regards,
Sylwester



From tomi.valkeinen at ti.com  Tue Apr  2 06:25:45 2013
From: tomi.valkeinen at ti.com (Tomi Valkeinen)
Date: Tue, 2 Apr 2013 13:25:45 +0300
Subject: [PATCHv2 6/6] video: fb: vt8500: Convert framebuffer drivers
 to standardized binding
In-Reply-To: <1364878200-26343-7-git-send-email-linux@prisktech.co.nz>
References: <1364878200-26343-1-git-send-email-linux@prisktech.co.nz>
 <1364878200-26343-7-git-send-email-linux@prisktech.co.nz>
Message-ID: <515AB229.4050204@ti.com>

On 2013-04-02 07:50, Tony Prisk wrote:
> Now that a display timing binding is available, convert our almost identical
> binding to use the standard binding.
> 
> This patch converts the vt8500 and wm8505 framebuffer drivers and
> associated dts/dtsi files to use the standard binding as defined in
> bindings/video/display-timing.txt.
> 
> There are two side-effects of making this conversion:
> 
> 1) The fb node should now be in the board file, rather than the soc file as
> the display-timing node is a child of the fb node.
> 
> 2) We still require a bits per pixel property to initialize the framebuffer
> for the different lcd panels. Rather than including this as part of the
> display timing, it is moved into the framebuffer node.

This means that the boards using the current DT bindings won't work with
a kernel with these patches, right? Is that ok?

I don't have any idea how strict we should be with DT bindings in
keeping compatibility...

 Tomi


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130402/d22482fd/attachment.sig>

From marex at denx.de  Tue Apr  2 06:32:12 2013
From: marex at denx.de (Marek Vasut)
Date: Tue, 2 Apr 2013 12:32:12 +0200
Subject: [PATCH 1/5] spi/mxs: Fix extra CS pulses and read mode in
 multi-transfer messages
In-Reply-To: <CA+7tXigvg+5k0Baa12CVwP5Ar7HUsJ8ihB19xrav4CNA6ZMFiA@mail.gmail.com>
References: <1364570381-17605-1-git-send-email-tpiepho@gmail.com>
 <201304020622.52429.marex@denx.de>
 <CA+7tXigvg+5k0Baa12CVwP5Ar7HUsJ8ihB19xrav4CNA6ZMFiA@mail.gmail.com>
Message-ID: <201304021232.12736.marex@denx.de>

Dear Trent Piepho,

> On Mon, Apr 1, 2013 at 9:22 PM, Marek Vasut <marex at denx.de> wrote:
> >> On Mon, Apr 1, 2013 at 4:11 PM, Marek Vasut <marex at denx.de> wrote:
> >> >> +#define TXRX_WRITE           1       /* This is a write */
> >> >> +#define TXRX_DEASSERT_CS     2       /* De-assert CS at end of txrx
> >> >> */
> > 
> > btw. is it necessary to define new flags or is it possible to reuse some?
> 
> I don't see any others that would make sense.  The driver doesn't
> define any flags at all.  The spi layer doesn't have ones that match.
> And this is for a private static interface inside the driver.  It
> wouldn't be right to co-opt flags defined for some other purpose.

Ok, makes sense then.

btw. if defining bitfield flags, it makes more sense to use (1 << n) notation to 
make it more readable and also less prone to people using the actual flag value 
as a bitshift argument.

> >> >>       ctrl0 = readl(ssp->base + HW_SSP_CTRL0);
> >> >> 
> >> >> -     ctrl0 &= ~BM_SSP_CTRL0_XFER_COUNT;
> >> >> +     ctrl0 &= ~BM_SSP_CTRL0_XFER_COUNT & ~BM_SSP_CTRL0_IGNORE_CRC &
> >> >> +              ~BM_SSP_CTRL0_READ;
> >> > 
> >> > Well ... ctrl0 &= ~(FOO | BAR | BAZ); ... won't cut it?
> >> 
> >> Well, by De Morgan's law the two expressions are the same.  And they
> >> are the same number of characters.  And both will produce a compile
> >> time constant and thus the same code.  However, I like the ~FOO & ~BAR
> >> & ~BAR form better as there is greater parallelism between each term
> >> of the expression.
> > 
> > What about the law of readability of code ? ;-)
> 
> Don't see anything in CodingStyle that one should be preferred over
> the other.

There ain't any I'm aware of, but to paraphrase you, let's keep the format 
that's already used in the driver ;-) :

114         if (dev->mode & ~(SPI_CPOL | SPI_CPHA))

> I think this way is more readable than the other.
> Generally you can think of masking off bits via bitwise-and and
> setting bits with bitwise-or.  So if you want to do a sequence of
> masks, then using a sequence of bitwise-ands is the most readable and
> straightforward code IMHO.  Combing bits to mask with bitwise-or, then
> inverting the set and masking with that seems like a less clear way of
> doing the same thing.  And this way the existing tokens aren't
> modified, so there is less churn!
> 
> >> The DMA does write
> >> ctrl0 on each segment of each transfer, but look at the previous
> >> paragraph to see where it comes from.  Once READ or IGNORE_CRC are
> >> set, nothing will clear them until PIO mode is used.
> > 
> > When using a flash, the DMA and PIO mode usage is intermixed. Usually,
> > the PIO is used to program the command and then DMA to transmit the
> > payload. It's hardly ever PIO only orr DMA only for the whole transfer.
> 
> Probably why the problem hasn't been noticed.  It's obvious from a
> cursory examination of the driver that bits in ctrl0 are only SET in
> the DMA code, never cleared.  The PIO code does clear them.
> 
> >> It's the same
> >> with the bug fix for 3.9 that clears the XFER_COUNT bits in DMA mode.
> >> Strangely, I didn't notice that bug since all my xfers are the same
> >> length!  But I do switch between slaves, between read and write, and
> >> use messages with multiple transfers, in DMA mode, all of which are
> >> broken in the current driver.
> > 
> > btw. are you using MX23 or MX28 to test this?
> 
> IMX28.

Is that any mainline board?

> >> Existing code that uses the first/last flags is wrong and needs to be
> >> changed.  Therefor code using 'first' and 'last' will be changed.
> >> 
> >> Passing the flags as pointers is bad practice and makes no sense to
> >> do.  Does it make any sense to re-write code fix the way it uses first
> >> and last, then re-write those same lines a second time to not use
> >> pointers?
> > 
> > You can always flip it the other way -- first rework the use of flags,
> > then apply the fix. It'd make the patch much easier to understand, don't
> > you think?
> 
> So I should change 'first' to not be a pointer to an integer in one
> patch, then delete the flag entirely in another patch?

I'd say make a patch (0001) that implements the transition to using your newly 
defined flags and then make a patch (0002) that "Fix extra CS pulses and read 
mode in multi-transfer messages". One patch shall do one thing, that's the usual 
rule of the thumb. Obviously keep them in a series if these patches shall go in 
together. And why doesn't squashing them all together work you might ask -- 
because reviewing the result is hard.

[...]

Best regards,
Marek Vasut


From prabhakar.csengg at gmail.com  Tue Apr  2 06:35:16 2013
From: prabhakar.csengg at gmail.com (Prabhakar Lad)
Date: Tue, 2 Apr 2013 16:05:16 +0530
Subject: [Query] PM runtime API
Message-ID: <CA+V-a8su4DDRudniqf8zAEb8Vmcbk4U6gtVLUOmOAm+n3t-PvQ@mail.gmail.com>

Hi Kevin/Sekhar,

I am porting the VPSS davinci driver to pm runtime API. This driver uses two
clocks vpss_master and vpss_slave. The driver was initially using common clock
framework, now when migrated i see only one clock enabled.

1: Does pm runtime match only with the device id to enable the clock ?

 2:
    	CLK("vpss", "master", &vpss_master_clk),
	CLK("vpss", "slave", &vpss_slave_clk),
     If I provide above two clock lookups pm runtime doesnt enable
them, but If I set
     the connection id as NULL then only the master clock gets enabled.

My understanding is that pm runtime matches upon the device id for the
first entry and only enables it.

Any inputs/suggestion how to handle it.

Regards,
--Prabhakar


From kgene.kim at samsung.com  Tue Apr  2 06:37:32 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Tue, 02 Apr 2013 19:37:32 +0900
Subject: [PATCH] ARM: EXYNOS5440: DTS: Add virtual GIC DT bindings
In-Reply-To: <1363858839-13578-1-git-send-email-giridhar.maruthy@linaro.org>
References: <1363858839-13578-1-git-send-email-giridhar.maruthy@linaro.org>
Message-ID: <239601ce2f8e$154b9720$3fe2c560$%kim@samsung.com>

Giridhar Maruthy wrote:
> 
> Exynos5440 has GIC which has virtualization support
> in them. These are used by KVM.
> 
> Signed-off-by: Giridhar Maruthy <giridhar.m at samsung.com>
> ---
>  arch/arm/boot/dts/exynos5440.dtsi |    6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/exynos5440.dtsi
> b/arch/arm/boot/dts/exynos5440.dtsi
> index c374a31..25c6134 100644
> --- a/arch/arm/boot/dts/exynos5440.dtsi
> +++ b/arch/arm/boot/dts/exynos5440.dtsi
> @@ -26,7 +26,11 @@
>  		compatible = "arm,cortex-a15-gic";
>  		#interrupt-cells = <3>;
>  		interrupt-controller;
> -		reg = <0x2E1000 0x1000>, <0x2E2000 0x1000>;
> +		reg =	<0x2E1000 0x1000>,
> +			<0x2E2000 0x1000>,
> +			<0x2E4000 0x2000>,
> +			<0x2E6000 0x2000>;
> +		interrupts = <1 9 0xf04>;
>  	};
> 
>  	cpus {
> --
> 1.7.9.5

Looks ok to me, applied.

Thanks.

- Kukjin



From nsekhar at ti.com  Tue Apr  2 06:40:06 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Tue, 2 Apr 2013 16:10:06 +0530
Subject: [Query] PM runtime API
In-Reply-To: <CA+V-a8su4DDRudniqf8zAEb8Vmcbk4U6gtVLUOmOAm+n3t-PvQ@mail.gmail.com>
References: <CA+V-a8su4DDRudniqf8zAEb8Vmcbk4U6gtVLUOmOAm+n3t-PvQ@mail.gmail.com>
Message-ID: <515AB586.1090100@ti.com>

On 4/2/2013 4:05 PM, Prabhakar Lad wrote:
> Hi Kevin/Sekhar,
> 
> I am porting the VPSS davinci driver to pm runtime API. This driver uses two
> clocks vpss_master and vpss_slave. The driver was initially using common clock
> framework, now when migrated i see only one clock enabled.
> 
> 1: Does pm runtime match only with the device id to enable the clock ?
> 
>  2:
>     	CLK("vpss", "master", &vpss_master_clk),
> 	CLK("vpss", "slave", &vpss_slave_clk),
>      If I provide above two clock lookups pm runtime doesnt enable
> them, but If I set
>      the connection id as NULL then only the master clock gets enabled.
> 
> My understanding is that pm runtime matches upon the device id for the
> first entry and only enables it.
> 
> Any inputs/suggestion how to handle it.

I think you need to tell pm_runtime about the con_ids. See the
initialization of pm_clk_notifier_block in
arch/arm/mach-davinci/pm_domain.c. There is a list of known con_ids that
need to passed.

Thanks,
Sekhar


From alchark at gmail.com  Tue Apr  2 06:41:47 2013
From: alchark at gmail.com (Alexey Charkov)
Date: Tue, 2 Apr 2013 14:41:47 +0400
Subject: [PATCHv2 6/6] video: fb: vt8500: Convert framebuffer drivers to
 standardized binding
In-Reply-To: <515AB229.4050204@ti.com>
References: <1364878200-26343-1-git-send-email-linux@prisktech.co.nz>
 <1364878200-26343-7-git-send-email-linux@prisktech.co.nz>
 <515AB229.4050204@ti.com>
Message-ID: <CABjd4Yx7zBAR+o-X7u9K9+iUeMq5qc=8n70qx1EoKPBT1JMR4A@mail.gmail.com>

2013/4/2 Tomi Valkeinen <tomi.valkeinen at ti.com>:
> On 2013-04-02 07:50, Tony Prisk wrote:
>> Now that a display timing binding is available, convert our almost identical
>> binding to use the standard binding.
>>
>> This patch converts the vt8500 and wm8505 framebuffer drivers and
>> associated dts/dtsi files to use the standard binding as defined in
>> bindings/video/display-timing.txt.
>>
>> There are two side-effects of making this conversion:
>>
>> 1) The fb node should now be in the board file, rather than the soc file as
>> the display-timing node is a child of the fb node.
>>
>> 2) We still require a bits per pixel property to initialize the framebuffer
>> for the different lcd panels. Rather than including this as part of the
>> display timing, it is moved into the framebuffer node.
>
> This means that the boards using the current DT bindings won't work with
> a kernel with these patches, right? Is that ok?

There are no known products shipping any DT-enabled firmware with
these chips in the wild. The only way to run modern kernels on
VIA/WonderMedia chips so far is by using the "appended DTB"
workaround, and the instructions that have been posted to Wiki's and
mailing list discussions imply that a fresh DTB is compiled from
current kernel sources to produce a bootable image.

Thus, it seems that this change should not really break anything
major, as the user base is quite small and those who use new code are
most likely to use new DTB as well.

Best,
Alexey


From kgene.kim at samsung.com  Tue Apr  2 06:44:22 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Tue, 02 Apr 2013 19:44:22 +0900
Subject: [PATCH 3/3] ARM: EXYNOS5250: Register architected timers
In-Reply-To: <1363222742-15220-4-git-send-email-agraf@suse.de>
References: <1363222742-15220-1-git-send-email-agraf@suse.de>
 <1363222742-15220-4-git-send-email-agraf@suse.de>
Message-ID: <239701ce2f8f$093a2f40$1bae8dc0$%kim@samsung.com>

Alexander Graf wrote:
> 
> When running on an exynos 5250 SoC, we don't initialize the architected
> timers. The chip however supports architected timers.
> 
Yes, exynos5250 can support, mct(multi core timer) is used though.

> When we don't initialize them, KVM will try to access them and run into
> NULL pointer dereferences attempting to do so.
> 
Yes, right.

> This patch is really more of a hack than a real fix, but does get me
> working with KVM on Arndale.
> 
Hmm, if you think, this is _really_ a hack, you need to add some comments
about that for clearance, and since the mct.c file has been moved into
drivers/clocksource/, this should be re-worked.

BTW, I discussed about this with Thomas and Giridhar just now, we reached
this 3rd patch could be dropped because the correct way is to add a dts
node for arch timer which patch 2nd is already doing after 3.9-rc1 because
of CLOCKSOURCE_OF_DECLARE macro.

So if you' OK above, let me know so that I can take only 1st and 2nd
patches to support KVM on exynos5250.

Thanks.

- Kukjin

> Signed-off-by: Alexander Graf <agraf at suse.de>
> ---
>  arch/arm/mach-exynos/mct.c |    4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/arch/arm/mach-exynos/mct.c b/arch/arm/mach-exynos/mct.c
> index c9d6650..eefb8af 100644
> --- a/arch/arm/mach-exynos/mct.c
> +++ b/arch/arm/mach-exynos/mct.c
> @@ -482,4 +482,8 @@ void __init exynos4_timer_init(void)
>  	exynos4_timer_resources();
>  	exynos4_clocksource_init();
>  	exynos4_clockevent_init();
> +
> +	if (soc_is_exynos5250()) {
> +		arch_timer_of_register();
> +	}
>  }
> --
> 1.7.10.4



From plagnioj at jcrosoft.com  Tue Apr  2 06:32:20 2013
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Tue, 2 Apr 2013 12:32:20 +0200
Subject: [PATCHv2 1/6] video: vt8500: Make wmt_ge_rops optional
In-Reply-To: <1364878200-26343-2-git-send-email-linux@prisktech.co.nz>
References: <1364878200-26343-1-git-send-email-linux@prisktech.co.nz>
 <1364878200-26343-2-git-send-email-linux@prisktech.co.nz>
Message-ID: <20130402103220.GK20693@game.jcrosoft.org>

On 17:49 Tue 02 Apr     , Tony Prisk wrote:
> wmt_ge_rops is a seperate driver to vt8500/wm8505 framebuffer
> driver but is currently a required option. This patch makes
> accelerated raster ops optional.
> 
> Signed-off-by: Tony Prisk <linux at prisktech.co.nz>
> Reviewed-by: Jean-Christophe Plagniol-Villard <plagnioj at jcrosoft.com>
> ---
>  drivers/video/Kconfig       |   22 ++++++++++++----------
>  drivers/video/vt8500lcdfb.c |   15 +++++++++++++++
>  drivers/video/wm8505fb.c    |   15 +++++++++++++++
>  3 files changed, 42 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> index 4c1546f..661aa54 100644
> --- a/drivers/video/Kconfig
> +++ b/drivers/video/Kconfig
> @@ -212,14 +212,6 @@ config FB_SYS_FOPS
>         depends on FB
>         default n
>  
> -config FB_WMT_GE_ROPS
> -	tristate
> -	depends on FB
> -	default n
> -	---help---
> -	  Include functions for accelerated rectangle filling and area
> -	  copying using WonderMedia Graphics Engine operations.
> -
>  config FB_DEFERRED_IO
>  	bool
>  	depends on FB
> @@ -1799,7 +1791,8 @@ config FB_AU1200
>  config FB_VT8500
>  	bool "VT8500 LCD Driver"
>  	depends on (FB = y) && ARM && ARCH_VT8500
> -	select FB_WMT_GE_ROPS
> +	select FB_SYS_FILLRECT if (!FB_WMT_GE_ROPS)
> +	select FB_SYS_COPYAREA if (!FB_WMT_GE_ROPS)
>  	select FB_SYS_IMAGEBLIT
>  	help
>  	  This is the framebuffer driver for VIA VT8500 integrated LCD
> @@ -1808,12 +1801,21 @@ config FB_VT8500
>  config FB_WM8505
>  	bool "WM8505 frame buffer support"
>  	depends on (FB = y) && ARM && ARCH_VT8500
> -	select FB_WMT_GE_ROPS
> +	select FB_SYS_FILLRECT if (!FB_WMT_GE_ROPS)
> +	select FB_SYS_COPYAREA if (!FB_WMT_GE_ROPS)
>  	select FB_SYS_IMAGEBLIT
>  	help
>  	  This is the framebuffer driver for WonderMedia WM8505/WM8650
>  	  integrated LCD controller.
>  
> +config FB_WMT_GE_ROPS
> +	bool "VT8500/WM85xx accelerated raster ops support"
> +	depends on (FB = y) && (FB_VT8500 || FB_WM8505)
> +	default n
> +	help
> +	  This adds support for accelerated raster operations on the
> +	  VIA VT8500 and Wondermedia 85xx series SoCs.
> +
>  source "drivers/video/geode/Kconfig"
>  
>  config FB_HIT
> diff --git a/drivers/video/vt8500lcdfb.c b/drivers/video/vt8500lcdfb.c
> index aa2579c..d8cc1f6 100644
> --- a/drivers/video/vt8500lcdfb.c
> +++ b/drivers/video/vt8500lcdfb.c
> @@ -33,7 +33,10 @@
>  #include <linux/platform_data/video-vt8500lcdfb.h>
>  
>  #include "vt8500lcdfb.h"
> +
> +#ifdef CONFIG_FB_WMT_GE_ROPS
>  #include "wmt_ge_rops.h"
> +#endif
no drop the ifdef
>  
>  #ifdef CONFIG_OF
>  #include <linux/of.h>
> @@ -249,12 +252,24 @@ static int vt8500lcd_blank(int blank, struct fb_info *info)
>  	return 0;
>  }
>  
> +#ifndef CONFIG_FB_WMT_GE_ROPS
> +static int wmt_ge_sync(struct fb_info *p)
> +{
> +	return 0;
> +}
> +#endif
put this in the header as inline

and put this too
#ifndef CONFIG_FB_WMT_GE_ROPS
static inline int wmt_ge_fillrect(struct fb_info *p, const struct fb_fillrect *rect)
{
	return sys_fillrectp, rect);
}

static inline void wmt_ge_copyarea(struct fb_info *p, const struct fb_copyarea *area)
{
	sys_copyarea(p, area);
}
#endif

> +
>  static struct fb_ops vt8500lcd_ops = {
>  	.owner		= THIS_MODULE,
>  	.fb_set_par	= vt8500lcd_set_par,
>  	.fb_setcolreg	= vt8500lcd_setcolreg,
> +#ifdef CONFIG_FB_WMT_GE_ROPS
>  	.fb_fillrect	= wmt_ge_fillrect,
>  	.fb_copyarea	= wmt_ge_copyarea,
> +#else
> +	.fb_fillrect	= sys_fillrect,
> +	.fb_copyarea	= sys_copyarea,
> +#endif
so here you can drop the ifdef
>  	.fb_imageblit	= sys_imageblit,
>  	.fb_sync	= wmt_ge_sync,
>  	.fb_ioctl	= vt8500lcd_ioctl,
> diff --git a/drivers/video/wm8505fb.c b/drivers/video/wm8505fb.c
> index 4dd0580..db49803 100644
> --- a/drivers/video/wm8505fb.c
> +++ b/drivers/video/wm8505fb.c
> @@ -35,7 +35,10 @@
>  #include <linux/platform_data/video-vt8500lcdfb.h>
>  
>  #include "wm8505fb_regs.h"
> +
> +#ifdef CONFIG_FB_WMT_GE_ROPS
>  #include "wmt_ge_rops.h"
> +#endif
here too drop the ifdef
>  
>  #define DRIVER_NAME "wm8505-fb"
>  
> @@ -248,12 +251,24 @@ static int wm8505fb_blank(int blank, struct fb_info *info)
>  	return 0;
>  }
>  
> +#ifndef CONFIG_FB_WMT_GE_ROPS
> +static int wmt_ge_sync(struct fb_info *p)
> +{
> +	return 0;
> +}
> +#endif
> +
>  static struct fb_ops wm8505fb_ops = {
>  	.owner		= THIS_MODULE,
>  	.fb_set_par	= wm8505fb_set_par,
>  	.fb_setcolreg	= wm8505fb_setcolreg,
> +#ifdef CONFIG_FB_WMT_GE_ROPS
>  	.fb_fillrect	= wmt_ge_fillrect,
>  	.fb_copyarea	= wmt_ge_copyarea,
> +#else
> +	.fb_fillrect	= sys_fillrect,
> +	.fb_copyarea	= sys_copyarea,
> +#endif
ditto
>  	.fb_imageblit	= sys_imageblit,
>  	.fb_sync	= wmt_ge_sync,
>  	.fb_pan_display	= wm8505fb_pan_display,
> -- 
> 1.7.9.5
> 


From prabhakar.csengg at gmail.com  Tue Apr  2 06:52:16 2013
From: prabhakar.csengg at gmail.com (Prabhakar Lad)
Date: Tue, 2 Apr 2013 16:22:16 +0530
Subject: [Query] PM runtime API
In-Reply-To: <515AB586.1090100@ti.com>
References: <CA+V-a8su4DDRudniqf8zAEb8Vmcbk4U6gtVLUOmOAm+n3t-PvQ@mail.gmail.com>
 <515AB586.1090100@ti.com>
Message-ID: <CA+V-a8s4yCE1HEuu0QMsmQ9jCm7guDDL22et7xpVzg+r2Gx64A@mail.gmail.com>

Hi Sekhar,

On Tue, Apr 2, 2013 at 4:10 PM, Sekhar Nori <nsekhar at ti.com> wrote:
> On 4/2/2013 4:05 PM, Prabhakar Lad wrote:
>> Hi Kevin/Sekhar,
>>
>> I am porting the VPSS davinci driver to pm runtime API. This driver uses two
>> clocks vpss_master and vpss_slave. The driver was initially using common clock
>> framework, now when migrated i see only one clock enabled.
>>
>> 1: Does pm runtime match only with the device id to enable the clock ?
>>
>>  2:
>>       CLK("vpss", "master", &vpss_master_clk),
>>       CLK("vpss", "slave", &vpss_slave_clk),
>>      If I provide above two clock lookups pm runtime doesnt enable
>> them, but If I set
>>      the connection id as NULL then only the master clock gets enabled.
>>
>> My understanding is that pm runtime matches upon the device id for the
>> first entry and only enables it.
>>
>> Any inputs/suggestion how to handle it.
>
> I think you need to tell pm_runtime about the con_ids. See the
> initialization of pm_clk_notifier_block in
> arch/arm/mach-davinci/pm_domain.c. There is a list of known con_ids that
> need to passed.
>
This helps!. Now looks like this con_ids is generic , I have added two
con_ids "master" and "slave" does that sound good to you or
should i add something to driver specific like "vpss_master" and "vpss_slave" ?

Regards,
--Prabhakar

> Thanks,
> Sekhar


From nsekhar at ti.com  Tue Apr  2 06:56:25 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Tue, 2 Apr 2013 16:26:25 +0530
Subject: [Query] PM runtime API
In-Reply-To: <CA+V-a8s4yCE1HEuu0QMsmQ9jCm7guDDL22et7xpVzg+r2Gx64A@mail.gmail.com>
References: <CA+V-a8su4DDRudniqf8zAEb8Vmcbk4U6gtVLUOmOAm+n3t-PvQ@mail.gmail.com>
 <515AB586.1090100@ti.com>
 <CA+V-a8s4yCE1HEuu0QMsmQ9jCm7guDDL22et7xpVzg+r2Gx64A@mail.gmail.com>
Message-ID: <515AB959.80306@ti.com>



On 4/2/2013 4:22 PM, Prabhakar Lad wrote:
> Hi Sekhar,
> 
> On Tue, Apr 2, 2013 at 4:10 PM, Sekhar Nori <nsekhar at ti.com> wrote:
>> On 4/2/2013 4:05 PM, Prabhakar Lad wrote:
>>> Hi Kevin/Sekhar,
>>>
>>> I am porting the VPSS davinci driver to pm runtime API. This driver uses two
>>> clocks vpss_master and vpss_slave. The driver was initially using common clock
>>> framework, now when migrated i see only one clock enabled.
>>>
>>> 1: Does pm runtime match only with the device id to enable the clock ?
>>>
>>>  2:
>>>       CLK("vpss", "master", &vpss_master_clk),
>>>       CLK("vpss", "slave", &vpss_slave_clk),
>>>      If I provide above two clock lookups pm runtime doesnt enable
>>> them, but If I set
>>>      the connection id as NULL then only the master clock gets enabled.
>>>
>>> My understanding is that pm runtime matches upon the device id for the
>>> first entry and only enables it.
>>>
>>> Any inputs/suggestion how to handle it.
>>
>> I think you need to tell pm_runtime about the con_ids. See the
>> initialization of pm_clk_notifier_block in
>> arch/arm/mach-davinci/pm_domain.c. There is a list of known con_ids that
>> need to passed.
>>
> This helps!. Now looks like this con_ids is generic , I have added two
> con_ids "master" and "slave" does that sound good to you or

That is good.

Thanks,
Sekhar

> should i add something to driver specific like "vpss_master" and "vpss_slave" ?



From moinejf at free.fr  Tue Apr  2 07:02:36 2013
From: moinejf at free.fr (Jean-Francois Moine)
Date: Tue, 2 Apr 2013 13:02:36 +0200
Subject: [PATCH] ARM: mvebu: Use common of_clk_init() function
Message-ID: <20130402130236.683fa734@armhf>

The use common of_clk_init() function simplifies the clock initialization
and adds handling of the DT "fixed-clock".

Signed-off-by: Jean-Francois Moine <moinejf at free.fr>
---
 drivers/clk/mvebu/clk-cpu.c |   17 ++---------------
 drivers/clk/mvebu/clk-cpu.h |   22 ----------------------
 drivers/clk/mvebu/clk.c     |    6 +-----
 3 files changed, 3 insertions(+), 42 deletions(-)
 delete mode 100644 drivers/clk/mvebu/clk-cpu.h

diff --git a/drivers/clk/mvebu/clk-cpu.c b/drivers/clk/mvebu/clk-cpu.c
index 9dd2551..b0fbc07 100644
--- a/drivers/clk/mvebu/clk-cpu.c
+++ b/drivers/clk/mvebu/clk-cpu.c
@@ -16,7 +16,6 @@
 #include <linux/io.h>
 #include <linux/of.h>
 #include <linux/delay.h>
-#include "clk-cpu.h"
 
 #define SYS_CTRL_CLK_DIVIDER_CTRL_OFFSET    0x0
 #define SYS_CTRL_CLK_DIVIDER_VALUE_OFFSET   0xC
@@ -173,17 +172,5 @@ clks_out:
 	kfree(cpuclk);
 }
 
-static const __initconst struct of_device_id clk_cpu_match[] = {
-	{
-		.compatible = "marvell,armada-xp-cpu-clock",
-		.data = of_cpu_clk_setup,
-	},
-	{
-		/* sentinel */
-	},
-};
-
-void __init mvebu_cpu_clk_init(void)
-{
-	of_clk_init(clk_cpu_match);
-}
+CLK_OF_DECLARE(armada_xp_cpu_clock, "marvell,armada-xp-cpu-clock",
+					 of_cpu_clk_setup);
diff --git a/drivers/clk/mvebu/clk-cpu.h b/drivers/clk/mvebu/clk-cpu.h
deleted file mode 100644
index 08e2aff..0000000
--- a/drivers/clk/mvebu/clk-cpu.h
+++ /dev/null
@@ -1,22 +0,0 @@
-/*
- * Marvell MVEBU CPU clock handling.
- *
- * Copyright (C) 2012 Marvell
- *
- * Gregory CLEMENT <gregory.clement at free-electrons.com>
- *
- * 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.
- */
-
-#ifndef __MVEBU_CLK_CPU_H
-#define __MVEBU_CLK_CPU_H
-
-#ifdef CONFIG_MVEBU_CLK_CPU
-void __init mvebu_cpu_clk_init(void);
-#else
-static inline void mvebu_cpu_clk_init(void) {}
-#endif
-
-#endif
diff --git a/drivers/clk/mvebu/clk.c b/drivers/clk/mvebu/clk.c
index 855681b..29f10fb 100644
--- a/drivers/clk/mvebu/clk.c
+++ b/drivers/clk/mvebu/clk.c
@@ -10,18 +10,14 @@
  * warranty of any kind, whether express or implied.
  */
 #include <linux/kernel.h>
-#include <linux/clk.h>
 #include <linux/clk-provider.h>
-#include <linux/of_address.h>
-#include <linux/clk/mvebu.h>
 #include <linux/of.h>
 #include "clk-core.h"
-#include "clk-cpu.h"
 #include "clk-gating-ctrl.h"
 
 void __init mvebu_clocks_init(void)
 {
 	mvebu_core_clk_init();
 	mvebu_gating_clk_init();
-	mvebu_cpu_clk_init();
+	of_clk_init(NULL);
 }
-- 
1.7.10.4



From will.deacon at arm.com  Tue Apr  2 07:02:55 2013
From: will.deacon at arm.com (Will Deacon)
Date: Tue, 2 Apr 2013 12:02:55 +0100
Subject: [PATCH v4 1/2] arm: introduce psci_smp_ops
In-Reply-To: <1364575371-8926-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <1364575371-8926-1-git-send-email-stefano.stabellini@eu.citrix.com>
Message-ID: <20130402110255.GA26949@mudshark.cambridge.arm.com>

Hi Stefano,

On Fri, Mar 29, 2013 at 04:42:49PM +0000, Stefano Stabellini wrote:
> Rename virt_smp_ops to psci_smp_ops and move them to arch/arm/kernel/psci_smp.c.
> Remove mach-virt/platsmp.c, now unused.
> Compile psci_smp if CONFIG_ARM_PSCI and CONFIG_SMP.
> 
> Add a cpu_die smp_op based on psci_ops.cpu_off.
> 
> Initialize PSCI before setting smp_ops in setup_arch.
> Use psci_smp_ops if the platform doesn't provide its own smp_ops.
> 
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
> CC: will.deacon at arm.com
> CC: arnd at arndb.de
> CC: marc.zyngier at arm.com
> CC: linux at arm.linux.org.uk
> CC: nico at linaro.org
> ---
>  arch/arm/include/asm/psci.h  |    9 +++++
>  arch/arm/kernel/Makefile     |    5 ++-
>  arch/arm/kernel/psci.c       |    3 +-
>  arch/arm/kernel/psci_smp.c   |   67 ++++++++++++++++++++++++++++++++++++++++++
>  arch/arm/kernel/setup.c      |    7 ++++-
>  arch/arm/mach-virt/Makefile  |    1 -
>  arch/arm/mach-virt/platsmp.c |   58 ------------------------------------
>  arch/arm/mach-virt/virt.c    |    3 --
>  8 files changed, 87 insertions(+), 66 deletions(-)
>  create mode 100644 arch/arm/kernel/psci_smp.c
>  delete mode 100644 arch/arm/mach-virt/platsmp.c
> 
> diff --git a/arch/arm/include/asm/psci.h b/arch/arm/include/asm/psci.h
> index ce0dbe7..4134dda 100644
> --- a/arch/arm/include/asm/psci.h
> +++ b/arch/arm/include/asm/psci.h
> @@ -32,5 +32,14 @@ struct psci_operations {
>  };
>  
>  extern struct psci_operations psci_ops;
> +extern struct smp_operations psci_smp_ops;
>  
> +#ifdef CONFIG_ARM_PSCI
> +int psci_init(void);
> +bool psci_smp_available(void);
> +#else
> +static inline int psci_init(void) { return -ENODEV; }
> +static inline bool psci_smp_available(void) { return false; }

You can probably make psci_init return void now that it's no longer an
initcall (you're not checking it's return value anyway).

> diff --git a/arch/arm/kernel/psci_smp.c b/arch/arm/kernel/psci_smp.c
> new file mode 100644
> index 0000000..66b0f77
> --- /dev/null
> +++ b/arch/arm/kernel/psci_smp.c
> @@ -0,0 +1,67 @@
> +/*
> + * 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.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * Copyright (C) 2012 ARM Limited
> + *
> + * Author: Will Deacon <will.deacon at arm.com>
> + */
> +
> +#include <linux/init.h>
> +#include <linux/irqchip/arm-gic.h>
> +#include <linux/smp.h>
> +#include <linux/of.h>
> +
> +#include <asm/psci.h>
> +#include <asm/smp_plat.h>
> +
> +extern void secondary_startup(void);
> +
> +static int __cpuinit psci_boot_secondary(unsigned int cpu,
> +					 struct task_struct *idle)
> +{
> +	if (psci_ops.cpu_on)
> +		return psci_ops.cpu_on(cpu_logical_map(cpu),
> +				       __pa(secondary_startup));
> +	return -ENODEV;
> +}

Since this code is now likely to be shared, it could be worth a comment
before each function to describe the expected semantics (e.g. mpidr is used
as the CPUID, additional power state information is zero).

Cheers,

Will


From simon.guinot at sequanux.org  Tue Apr  2 07:04:26 2013
From: simon.guinot at sequanux.org (Simon Guinot)
Date: Tue, 2 Apr 2013 13:04:26 +0200
Subject: [PATCH] ARM: kirkwood: DT board setup for CloudBox
In-Reply-To: <515A5BC6.5000007@free.fr>
References: <1364555206-5870-1-git-send-email-simon.guinot@sequanux.org>
 <20130329153132.GJ13280@titan.lakedaemon.net>
 <20130329184109.GA16404@kw.sim.vm.gnt> <51568B89.1060009@free.fr>
 <20130401163316.GC16404@kw.sim.vm.gnt> <515A5BC6.5000007@free.fr>
Message-ID: <20130402110426.GG16404@kw.sim.vm.gnt>

On Tue, Apr 02, 2013 at 06:17:10AM +0200, Chris Moore wrote:
> Hi Simon,
> 
> Le 01/04/2013 18:33, Simon Guinot a ?crit :
> >On Sat, Mar 30, 2013 at 07:51:53AM +0100, Chris Moore wrote:
> >
> >Le 29/03/2013 19:41, Simon Guinot a ?crit :
> >>>On Fri, Mar 29, 2013 at 11:31:32AM -0400, Jason Cooper wrote
> >>>>On Fri, Mar 29, 2013 at 12:06:46PM +0100, Simon Guinot wrote:
> >>>>>This patch adds DT board setup for the LaCie NAS CloudBox. The CloudBox
> >>>>>is a low cost NAS based on the Network Space v2.
> >>>>>
> >>>>>Chipset list:
> >>>>>- CPU MARVELL 88F6702 1Ghz
> >>>>>- SDRAM memory: 256MB DDR2-800 (2x128MB x8) 400Mhz
> >>>>>- 1 Ethernet Gigabit port (PHY MARVELL 88E1318)
> >>>>>- SPI flash, NOR 512KB
> >>>>>- 1 push button
> >>>>>- 2 LEDs (red and blue)
> >>>>>
> >>>>>+
> >>>>>+/ {
> >>>>>+	model = "LaCie CloudBox";
> >>>>>+	compatible = "lacie,cloudbox", "marvell,kirkwood-88f6702", "marvell,kirkwood";
> >>>>Is there a more specific string we can add here?  eg
> >>>>"lacie,cloudbox-MODEL", "lacie,cloudbox", ...
> >>>Unfortunately no. CloudBox is a product name which is also used by LaCie
> >>>to name the board and the project.
> >>>
> >>I think it really is necessary to have a more specific name.
> >>I have two, very different, products corresponding to LaCie CloudBox:
> >>- The first one was a small black one with a 2.5" disk reviewed
> >>here: http://www.smallnetbuilder.com/cloud/cloud-storage/462-lacie-cloudbox-reviewed
> >>- The later one is a larger white one with a 3.5" disk described
> >>here: http://www.smallnetbuilder.com/nas/nas-news/31927-lacie-relaunches-its-cloud-connected-nas
> >>
> >>IIRC the later one was originally called "CloudBox Family" although
> >>maybe Family was dropped when it was officially released.
> >Indeed, there is two (or rather one and half) released products called
> >CloudBox.
> >
> >The old one (the first smallnetbuilder link) has been first called
> >Network Space v2 mini, then SafeBox and finally released under the name
> >Cloudbox. Very very few products have been sold. I don't know any owner
> >and I suspect you got yours from the LaCie beta test program :)
> >
> 
> Yes, in fact I was given both by LaCie for beta testing :)
> Thank you, LaCie ;-)
> 
> >The new CloudBox is a very different product which has been first named
> >FamilyBox and then released under the CloudBox name. Because the previous
> >CloudBox was a really confidential product, the marketing guys have
> >decided to reuse the name. This was a bad idea and despite the warnings
> >they did that even so.
> >
> >Now, the fact is that the new CloudBox is a huge-selling LaCie product.
> >That's why I propose to keep the names just as they are.
> >
> 
> That is surprising: I greatly prefer the old black one, mainly
> because it uploads autonomously with the PC powered off.

I suspect the problem was the disk capacity, 200GB only. The product
price was the same as 1|2TB NASes. Despite the fashioned cloud effect,
maybe this was a little bit over expensive...

> 
> Are all the new ones white and all the old ones black?

Arf. I don't think we can trust the color case. Indeed, the old ones
are black but there is still no guarantee that the new ones will stay
white.

> If so, can't we add white to the name or at least specify in Kconfig
> that it is the white version with a 3.5" disk?

Maybe we could append some suffixes with version:
netspace_mini_v2 -> cloudbox_v1
cloudbox         -> cloudbox_v2

But again, I am quite reluctant to do this change. I think this would
be confusing for the users.

Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130402/1dd2fcb2/attachment.sig>

From alex at digriz.org.uk  Tue Apr  2 07:04:35 2013
From: alex at digriz.org.uk (Alexander Clouter)
Date: Tue,  2 Apr 2013 12:04:35 +0100
Subject: [PATCHv2 2/6] rtc: rtc-m48t86: add hooks to support driver side
 memory mapping
In-Reply-To: <1364858565-17192-3-git-send-email-alex@digriz.org.uk>
References: <1364858565-17192-3-git-send-email-alex@digriz.org.uk>
Message-ID: <1364900675-9632-1-git-send-email-alex@digriz.org.uk>

If platform_data is not defined (as before), then named memory io
ranges need to be defined ("rtc_index" and "rtc_data").  The driver
then maps those regions and uses them as the RTC index and data
addresses.

Changelog:
 v2 - mute GCC warnings (seems to be GCC being dumb)
    - amend the {read,write}byte driver functions to use u8

Signed-off-by: Alexander Clouter <alex at digriz.org.uk>
---
 drivers/rtc/rtc-m48t86.c |  230 ++++++++++++++++++++++++++++++++++------------
 1 file changed, 173 insertions(+), 57 deletions(-)

diff --git a/drivers/rtc/rtc-m48t86.c b/drivers/rtc/rtc-m48t86.c
index 25e0116..b2cabf9 100644
--- a/drivers/rtc/rtc-m48t86.c
+++ b/drivers/rtc/rtc-m48t86.c
@@ -18,6 +18,8 @@
 #include <linux/platform_device.h>
 #include <linux/platform_data/rtc-m48t86.h>
 #include <linux/bcd.h>
+#include <linux/slab.h>
+#include <linux/io.h>
 
 #define M48T86_REG_SEC		0x00
 #define M48T86_REG_SECALRM	0x01
@@ -41,40 +43,70 @@
 
 #define DRV_VERSION "0.1"
 
+struct m48t86_rtc_private_data {
+	void __iomem		*io_index;
+	void __iomem		*io_data;
+
+	struct rtc_device	*rtc;
+	struct m48t86_ops	*ops;
+};
+
+static void m48t86_rtc_writebyte(struct device *dev, u8 value, u8 reg)
+{
+	struct m48t86_rtc_private_data *priv = dev_get_drvdata(dev);
+
+	if (priv->ops) {
+		priv->ops->writebyte((unsigned char)value,
+					(unsigned long)reg);
+		return;
+	}
+
+	writeb(reg, priv->io_index);
+	writeb(value, priv->io_data);
+}
+
+static u8 m48t86_rtc_readbyte(struct device *dev, u8 reg)
+{
+	struct m48t86_rtc_private_data *priv = dev_get_drvdata(dev);
+
+	if (priv->ops)
+		return priv->ops->readbyte((unsigned long)reg);
+
+	writeb(reg, priv->io_index);
+	return readb(priv->io_data);
+}
 
 static int m48t86_rtc_read_time(struct device *dev, struct rtc_time *tm)
 {
 	unsigned char reg;
-	struct platform_device *pdev = to_platform_device(dev);
-	struct m48t86_ops *ops = pdev->dev.platform_data;
 
-	reg = ops->readbyte(M48T86_REG_B);
+	reg = m48t86_rtc_readbyte(dev, M48T86_REG_B);
 
 	if (reg & M48T86_REG_B_DM) {
 		/* data (binary) mode */
-		tm->tm_sec	= ops->readbyte(M48T86_REG_SEC);
-		tm->tm_min	= ops->readbyte(M48T86_REG_MIN);
-		tm->tm_hour	= ops->readbyte(M48T86_REG_HOUR) & 0x3F;
-		tm->tm_mday	= ops->readbyte(M48T86_REG_DOM);
+		tm->tm_sec	= m48t86_rtc_readbyte(dev, M48T86_REG_SEC);
+		tm->tm_min	= m48t86_rtc_readbyte(dev, M48T86_REG_MIN);
+		tm->tm_hour	= m48t86_rtc_readbyte(dev, M48T86_REG_HOUR) & 0x3F;
+		tm->tm_mday	= m48t86_rtc_readbyte(dev, M48T86_REG_DOM);
 		/* tm_mon is 0-11 */
-		tm->tm_mon	= ops->readbyte(M48T86_REG_MONTH) - 1;
-		tm->tm_year	= ops->readbyte(M48T86_REG_YEAR) + 100;
-		tm->tm_wday	= ops->readbyte(M48T86_REG_DOW);
+		tm->tm_mon	= m48t86_rtc_readbyte(dev, M48T86_REG_MONTH) - 1;
+		tm->tm_year	= m48t86_rtc_readbyte(dev, M48T86_REG_YEAR) + 100;
+		tm->tm_wday	= m48t86_rtc_readbyte(dev, M48T86_REG_DOW);
 	} else {
 		/* bcd mode */
-		tm->tm_sec	= bcd2bin(ops->readbyte(M48T86_REG_SEC));
-		tm->tm_min	= bcd2bin(ops->readbyte(M48T86_REG_MIN));
-		tm->tm_hour	= bcd2bin(ops->readbyte(M48T86_REG_HOUR) & 0x3F);
-		tm->tm_mday	= bcd2bin(ops->readbyte(M48T86_REG_DOM));
+		tm->tm_sec	= bcd2bin(m48t86_rtc_readbyte(dev, M48T86_REG_SEC));
+		tm->tm_min	= bcd2bin(m48t86_rtc_readbyte(dev, M48T86_REG_MIN));
+		tm->tm_hour	= bcd2bin(m48t86_rtc_readbyte(dev, M48T86_REG_HOUR) & 0x3F);
+		tm->tm_mday	= bcd2bin(m48t86_rtc_readbyte(dev, M48T86_REG_DOM));
 		/* tm_mon is 0-11 */
-		tm->tm_mon	= bcd2bin(ops->readbyte(M48T86_REG_MONTH)) - 1;
-		tm->tm_year	= bcd2bin(ops->readbyte(M48T86_REG_YEAR)) + 100;
-		tm->tm_wday	= bcd2bin(ops->readbyte(M48T86_REG_DOW));
+		tm->tm_mon	= bcd2bin(m48t86_rtc_readbyte(dev, M48T86_REG_MONTH)) - 1;
+		tm->tm_year	= bcd2bin(m48t86_rtc_readbyte(dev, M48T86_REG_YEAR)) + 100;
+		tm->tm_wday	= bcd2bin(m48t86_rtc_readbyte(dev, M48T86_REG_DOW));
 	}
 
 	/* correct the hour if the clock is in 12h mode */
 	if (!(reg & M48T86_REG_B_H24))
-		if (ops->readbyte(M48T86_REG_HOUR) & 0x80)
+		if (m48t86_rtc_readbyte(dev, M48T86_REG_HOUR) & 0x80)
 			tm->tm_hour += 12;
 
 	return rtc_valid_tm(tm);
@@ -83,38 +115,36 @@ static int m48t86_rtc_read_time(struct device *dev, struct rtc_time *tm)
 static int m48t86_rtc_set_time(struct device *dev, struct rtc_time *tm)
 {
 	unsigned char reg;
-	struct platform_device *pdev = to_platform_device(dev);
-	struct m48t86_ops *ops = pdev->dev.platform_data;
 
-	reg = ops->readbyte(M48T86_REG_B);
+	reg = m48t86_rtc_readbyte(dev, M48T86_REG_B);
 
 	/* update flag and 24h mode */
 	reg |= M48T86_REG_B_SET | M48T86_REG_B_H24;
-	ops->writebyte(reg, M48T86_REG_B);
+	m48t86_rtc_writebyte(dev, reg, M48T86_REG_B);
 
 	if (reg & M48T86_REG_B_DM) {
 		/* data (binary) mode */
-		ops->writebyte(tm->tm_sec, M48T86_REG_SEC);
-		ops->writebyte(tm->tm_min, M48T86_REG_MIN);
-		ops->writebyte(tm->tm_hour, M48T86_REG_HOUR);
-		ops->writebyte(tm->tm_mday, M48T86_REG_DOM);
-		ops->writebyte(tm->tm_mon + 1, M48T86_REG_MONTH);
-		ops->writebyte(tm->tm_year % 100, M48T86_REG_YEAR);
-		ops->writebyte(tm->tm_wday, M48T86_REG_DOW);
+		m48t86_rtc_writebyte(dev, tm->tm_sec, M48T86_REG_SEC);
+		m48t86_rtc_writebyte(dev, tm->tm_min, M48T86_REG_MIN);
+		m48t86_rtc_writebyte(dev, tm->tm_hour, M48T86_REG_HOUR);
+		m48t86_rtc_writebyte(dev, tm->tm_mday, M48T86_REG_DOM);
+		m48t86_rtc_writebyte(dev, tm->tm_mon + 1, M48T86_REG_MONTH);
+		m48t86_rtc_writebyte(dev, tm->tm_year % 100, M48T86_REG_YEAR);
+		m48t86_rtc_writebyte(dev, tm->tm_wday, M48T86_REG_DOW);
 	} else {
 		/* bcd mode */
-		ops->writebyte(bin2bcd(tm->tm_sec), M48T86_REG_SEC);
-		ops->writebyte(bin2bcd(tm->tm_min), M48T86_REG_MIN);
-		ops->writebyte(bin2bcd(tm->tm_hour), M48T86_REG_HOUR);
-		ops->writebyte(bin2bcd(tm->tm_mday), M48T86_REG_DOM);
-		ops->writebyte(bin2bcd(tm->tm_mon + 1), M48T86_REG_MONTH);
-		ops->writebyte(bin2bcd(tm->tm_year % 100), M48T86_REG_YEAR);
-		ops->writebyte(bin2bcd(tm->tm_wday), M48T86_REG_DOW);
+		m48t86_rtc_writebyte(dev, bin2bcd(tm->tm_sec), M48T86_REG_SEC);
+		m48t86_rtc_writebyte(dev, bin2bcd(tm->tm_min), M48T86_REG_MIN);
+		m48t86_rtc_writebyte(dev, bin2bcd(tm->tm_hour), M48T86_REG_HOUR);
+		m48t86_rtc_writebyte(dev, bin2bcd(tm->tm_mday), M48T86_REG_DOM);
+		m48t86_rtc_writebyte(dev, bin2bcd(tm->tm_mon + 1), M48T86_REG_MONTH);
+		m48t86_rtc_writebyte(dev, bin2bcd(tm->tm_year % 100), M48T86_REG_YEAR);
+		m48t86_rtc_writebyte(dev, bin2bcd(tm->tm_wday), M48T86_REG_DOW);
 	}
 
 	/* update ended */
 	reg &= ~M48T86_REG_B_SET;
-	ops->writebyte(reg, M48T86_REG_B);
+	m48t86_rtc_writebyte(dev, reg, M48T86_REG_B);
 
 	return 0;
 }
@@ -122,15 +152,13 @@ static int m48t86_rtc_set_time(struct device *dev, struct rtc_time *tm)
 static int m48t86_rtc_proc(struct device *dev, struct seq_file *seq)
 {
 	unsigned char reg;
-	struct platform_device *pdev = to_platform_device(dev);
-	struct m48t86_ops *ops = pdev->dev.platform_data;
 
-	reg = ops->readbyte(M48T86_REG_B);
+	reg = m48t86_rtc_readbyte(dev, M48T86_REG_B);
 
 	seq_printf(seq, "mode\t\t: %s\n",
 		 (reg & M48T86_REG_B_DM) ? "binary" : "bcd");
 
-	reg = ops->readbyte(M48T86_REG_D);
+	reg = m48t86_rtc_readbyte(dev, M48T86_REG_D);
 
 	seq_printf(seq, "battery\t\t: %s\n",
 		 (reg & M48T86_REG_D_VRT) ? "ok" : "exhausted");
@@ -144,34 +172,122 @@ static const struct rtc_class_ops m48t86_rtc_ops = {
 	.proc		= m48t86_rtc_proc,
 };
 
-static int m48t86_rtc_probe(struct platform_device *dev)
+static int m48t86_rtc_probe(struct platform_device *pdev)
 {
 	unsigned char reg;
-	struct m48t86_ops *ops = dev->dev.platform_data;
-	struct rtc_device *rtc = rtc_device_register("m48t86",
-				&dev->dev, &m48t86_rtc_ops, THIS_MODULE);
-
-	if (IS_ERR(rtc))
-		return PTR_ERR(rtc);
-
-	platform_set_drvdata(dev, rtc);
+	int err;
+	struct m48t86_rtc_private_data *priv;
+	struct resource *res_index = NULL;	/* Avoid GCC warning */
+	struct resource *res_data = NULL;	/* Avoid GCC warning */
+
+	/* Allocate memory for the device structure (and zero it) */
+	priv = kzalloc(sizeof(struct m48t86_rtc_private_data), GFP_KERNEL);
+	if (!priv)
+		return -ENOMEM;
+
+	platform_set_drvdata(pdev, priv);
+
+	if (!pdev->dev.platform_data) {
+		res_index = platform_get_resource_byname(
+					pdev, IORESOURCE_MEM, "rtc_index");
+		if (!res_index) {
+			err = -ENXIO;
+			goto out_free;
+		}
+
+		res_data = platform_get_resource_byname(
+					pdev, IORESOURCE_MEM, "rtc_data");
+		if (!res_data) {
+			err = -ENXIO;
+			goto out_free;
+		}
+
+		if (!request_mem_region(res_index->start,
+					resource_size(res_index),
+					dev_name(&pdev->dev))) {
+			err = -EBUSY;
+			goto out_free;
+		}
+
+		if (!request_mem_region(res_data->start,
+					resource_size(res_data),
+					dev_name(&pdev->dev))) {
+			err = -EBUSY;
+			goto out_release_index;
+		}
+
+		priv->io_index = ioremap(res_index->start,
+					resource_size(res_index));
+		if (!priv->io_index) {
+			err = -EIO;
+			goto out_release_data;
+		}
+
+		priv->io_data = ioremap(res_data->start,
+					resource_size(res_data));
+		if (!priv->io_data) {
+			err = -EIO;
+			goto out_io_index;
+		}
+	} else
+		priv->ops = pdev->dev.platform_data;
+
+	priv->rtc = rtc_device_register("m48t86",
+				&pdev->dev, &m48t86_rtc_ops, THIS_MODULE);
+	if (IS_ERR(priv->rtc)) {
+		err = PTR_ERR(priv->rtc);
+		if (!pdev->dev.platform_data)
+			goto out_io_data;
+		else
+			goto out_free;
+	}
 
 	/* read battery status */
-	reg = ops->readbyte(M48T86_REG_D);
-	dev_info(&dev->dev, "battery %s\n",
+	reg = m48t86_rtc_readbyte(&pdev->dev, M48T86_REG_D);
+	dev_info(&pdev->dev, "battery %s\n",
 		(reg & M48T86_REG_D_VRT) ? "ok" : "exhausted");
 
 	return 0;
+
+out_io_data:
+	iounmap(priv->io_data);
+out_io_index:
+	iounmap(priv->io_index);
+out_release_data:
+	release_mem_region(res_data->start, resource_size(res_data));
+out_release_index:
+	release_mem_region(res_index->start, resource_size(res_index));
+out_free:
+	platform_set_drvdata(pdev, NULL);
+	kfree(priv);
+	return err;
 }
 
-static int m48t86_rtc_remove(struct platform_device *dev)
+static int m48t86_rtc_remove(struct platform_device *pdev)
 {
-	struct rtc_device *rtc = platform_get_drvdata(dev);
+	struct resource *res;
+	struct m48t86_rtc_private_data *priv = platform_get_drvdata(pdev);
+
+	if (priv->rtc)
+		rtc_device_unregister(priv->rtc);
+
+	if (priv->io_data) {
+		iounmap(priv->io_data);
+		res = platform_get_resource_byname(
+					pdev, IORESOURCE_MEM, "rtc_data");
+		release_mem_region(res->start, resource_size(res));
+	}
+
+	if (priv->io_index) {
+		iounmap(priv->io_index);
+		res = platform_get_resource_byname(
+					pdev, IORESOURCE_MEM, "rtc_index");
+		release_mem_region(res->start, resource_size(res));
+	}
 
- 	if (rtc)
-		rtc_device_unregister(rtc);
+	platform_set_drvdata(pdev, NULL);
 
-	platform_set_drvdata(dev, NULL);
+	kfree(priv);
 
 	return 0;
 }
-- 
1.7.10.4



From shawn.guo at linaro.org  Tue Apr  2 07:12:47 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 2 Apr 2013 19:12:47 +0800
Subject: [PATCH 1/2] ARM: imx_v6_v7_defconfig: add CONFIG_USB_PHY
In-Reply-To: <20130402080706.GC30286@arwen.pp.htv.fi>
References: <1364133966-22373-1-git-send-email-shawn.guo@linaro.org>
 <20130402080706.GC30286@arwen.pp.htv.fi>
Message-ID: <20130402111245.GC24039@S2101-09.ap.freescale.net>

On Tue, Apr 02, 2013 at 11:07:06AM +0300, Felipe Balbi wrote:
> On Sun, Mar 24, 2013 at 10:06:04PM +0800, Shawn Guo wrote:
> > Commit edc7cb2 (usb: phy: make it a menuconfig) makes USB_MXS_PHY
> > be a sub-item of menuconfig symbol USB_PHY.  This change gets the
> > selection of CONFIG_USB_MXS_PHY in imx_v6_v7_defconfig lost.  Hence the
> > boot stops at the point below.
> > 
> >   ci_hdrc ci_hdrc.0: doesn't support gadget
> >   ci_hdrc ci_hdrc.0: EHCI Host Controller
> >   ci_hdrc ci_hdrc.0: new USB bus registered, assigned bus number 1
> > 
> > Add CONFIG_USB_PHY to have the CONFIG_USB_MXS_PHY selection back to
> > work.
> > 
> > Signed-off-by: Shawn Guo <shawn.guo at linaro.org>
> 
> should I take this or will Russell queue it during -rc ?

Though I can send it via arm-soc tree when your patches land on
mainline, I think the easier way is that you take both patches via
your tree.

Shawn



From padma.v at samsung.com  Tue Apr  2 07:16:45 2013
From: padma.v at samsung.com (Padmavathi Venna)
Date: Tue, 02 Apr 2013 16:46:45 +0530
Subject: [PATCH V3] DMA: PL330: Add check if device tree compatible
Message-ID: <1364901405-16541-1-git-send-email-padma.v@samsung.com>

This patch register the dma controller with generic dma helpers only
in DT case. This also adds some extra error handling in the driver.

Signed-off-by: Padmavathi Venna <padma.v at samsung.com>
Reported-by: Sachin Kamat <sachin.kamat at linaro.org>
---

Based on Vinod Koul next branch.

Changes since V2:
	- Removed pl330_free_chan_resources for error handling in probe. 

Changes since V1:
	- return silently when of_dma_controller_register fails, as
	  suggested by Arnd.

 drivers/dma/pl330.c |   33 ++++++++++++++++++++++-----------
 1 files changed, 22 insertions(+), 11 deletions(-)

diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index 345e2a1..fa388c1c 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -2882,7 +2882,7 @@ pl330_probe(struct amba_device *adev, const struct amba_id *id)
 {
 	struct dma_pl330_platdata *pdat;
 	struct dma_pl330_dmac *pdmac;
-	struct dma_pl330_chan *pch;
+	struct dma_pl330_chan *pch, *_p;
 	struct pl330_info *pi;
 	struct dma_device *pd;
 	struct resource *res;
@@ -2984,7 +2984,17 @@ pl330_probe(struct amba_device *adev, const struct amba_id *id)
 	ret = dma_async_device_register(pd);
 	if (ret) {
 		dev_err(&adev->dev, "unable to register DMAC\n");
-		goto probe_err2;
+		goto probe_err3;
+	}
+
+	if (adev->dev.of_node) {
+		ret = of_dma_controller_register(adev->dev.of_node,
+					 of_dma_pl330_xlate, pdmac);
+		if (ret) {
+			dev_err(&adev->dev,
+				"unable to register DMA to the generic"
+				"DT DMA helpers\n");
+		}
 	}
 
 	dev_info(&adev->dev,
@@ -2995,16 +3005,15 @@ pl330_probe(struct amba_device *adev, const struct amba_id *id)
 		pi->pcfg.data_bus_width / 8, pi->pcfg.num_chan,
 		pi->pcfg.num_peri, pi->pcfg.num_events);
 
-	ret = of_dma_controller_register(adev->dev.of_node,
-					 of_dma_pl330_xlate, pdmac);
-	if (ret) {
-		dev_err(&adev->dev,
-		"unable to register DMA to the generic DT DMA helpers\n");
-		goto probe_err2;
-	}
-
 	return 0;
+probe_err3:
+	amba_set_drvdata(adev, NULL);
 
+	/* Idle the DMAC */
+	list_for_each_entry_safe(pch, _p, &pdmac->ddma.channels,
+			chan.device_node)
+		/* Remove the channel */
+		list_del(&pch->chan.device_node);
 probe_err2:
 	pl330_del(pi);
 probe_err1:
@@ -3023,8 +3032,10 @@ static int pl330_remove(struct amba_device *adev)
 	if (!pdmac)
 		return 0;
 
-	of_dma_controller_free(adev->dev.of_node);
+	if (adev->dev.of_node)
+		of_dma_controller_free(adev->dev.of_node);
 
+	dma_async_device_unregister(&pdmac->ddma);
 	amba_set_drvdata(adev, NULL);
 
 	/* Idle the DMAC */
-- 
1.7.4.4



From tixy at linaro.org  Tue Apr  2 07:19:19 2013
From: tixy at linaro.org (Jon Medhurst (Tixy))
Date: Tue, 02 Apr 2013 12:19:19 +0100
Subject: [BUG] mod/file2alias: build error in devicetable-offsets.c
 [was: asm/types.h Header file wont get generated while building uImage ?]
In-Reply-To: <m2ip48d62f.fsf@igel.home>
References: <CA+V-a8vYsBLVH-3Bm35Sv9K9ZMTcMB4_P_V3kBjyuEKDozPi5w@mail.gmail.com>
 <1363949290.3528.37.camel@linaro1.home> <m2ip48d62f.fsf@igel.home>
Message-ID: <1364901559.3650.12.camel@linaro1.home>

On Sat, 2013-03-30 at 20:46 +0100, Andreas Schwab wrote:
> "Jon Medhurst (Tixy)" <tixy at linaro.org> writes:
> 
> > For builds which succeed I see this order:
> >
> >   WRAP    arch/arm/include/generated/asm/types.h
> >   [...]
> >   GEN     include/generated/asm-offsets.h
> >
> > and for those which fail:
> >
> >   CC      scripts/mod/devicetable-offsets.s
> >   In file included from include/linux/types.h:5:0,
> >                    from include/linux/mod_devicetable.h:11,
> >                    from scripts/mod/devicetable-offsets.c:2:
> >   include/uapi/linux/types.h:4:23: fatal error: asm/types.h: No such file or directory
> >   [...]
> >   WRAP    arch/arm/include/generated/asm/types.h
> 
> Does that help?

It's rather difficult to be certain as I've only seen it in our daily
automated builds but I forced the failure on my local PC by adding
'sleep 2' to the rules in scripts/Makefile.asm-generic and doing a build
with -j4. Then after applying the below fix I couldn't reproduce the
failure. I'll add the fix to the trees our automated builds use and
report if I see any other issues but I don't anticipate any.

Thanks for looking at this.


> diff --git a/Makefile b/Makefile
> index a5f3203..2a484db 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -512,7 +512,8 @@ ifeq ($(KBUILD_EXTMOD),)
>  # Carefully list dependencies so we do not try to build scripts twice
>  # in parallel
>  PHONY += scripts
> -scripts: scripts_basic include/config/auto.conf include/config/tristate.conf
> +scripts: scripts_basic include/config/auto.conf include/config/tristate.conf \
> +	 asm-generic
>  	$(Q)$(MAKE) $(build)=$(@)
>  
>  # Objects we will link into vmlinux / subdirs we need to visit
> 
> Andreas.
> 

-- 
Tixy



From josephl at nvidia.com  Tue Apr  2 07:19:40 2013
From: josephl at nvidia.com (Joseph Lo)
Date: Tue, 2 Apr 2013 19:19:40 +0800
Subject: [PATCH V3 0/3] ARM: tegra: add clock source for PMC
Message-ID: <1364901583-24867-1-git-send-email-josephl@nvidia.com>

This series was original introduced to clean up the PM related code after
the system suspending support series. The information about the origianl
patch set is below.

[1/3] ARM: tegra: moving the CPU power timer function to PMC driver
[2/3] ARM: tegra: refactor the pmc_pm_set function
[3/3] ARM: tegra: cpuidle: remove redundant parameters for powered-down mode

I split them up in V2. The [1/3] is integrated into this series. And should
be merged before the system suspending support series.

The [2/3] is squashed into the system suspending support v4 series.

The [3/3] become a stand alone clean up patah right after the system suspending
support series.

V3:
* add the DT bindings for the clock source of PMC
* getting the clock from DT

Joseph Lo (3):
  ARM: tegra: get PMC clock source from DT
  ARM: dts: tegra: add clock source for PMC
  ARM: tegra: moving the CPU power timer function to PMC driver

 .../bindings/arm/tegra/nvidia,tegra20-pmc.txt      | 23 ++++++++++++++
 arch/arm/boot/dts/tegra20-colibri-512.dtsi         | 13 ++++++++
 arch/arm/boot/dts/tegra20-harmony.dts              | 13 ++++++++
 arch/arm/boot/dts/tegra20-paz00.dts                | 13 ++++++++
 arch/arm/boot/dts/tegra20-seaboard.dts             | 13 ++++++++
 arch/arm/boot/dts/tegra20-tamonten.dtsi            | 13 ++++++++
 arch/arm/boot/dts/tegra20-trimslice.dts            | 13 ++++++++
 arch/arm/boot/dts/tegra20-ventana.dts              | 13 ++++++++
 arch/arm/boot/dts/tegra20-whistler.dts             | 13 ++++++++
 arch/arm/boot/dts/tegra20.dtsi                     |  2 ++
 arch/arm/boot/dts/tegra30-beaver.dts               | 13 ++++++++
 arch/arm/boot/dts/tegra30-cardhu.dtsi              | 13 ++++++++
 arch/arm/boot/dts/tegra30.dtsi                     |  2 ++
 arch/arm/mach-tegra/common.c                       |  2 +-
 arch/arm/mach-tegra/pm.c                           | 37 +---------------------
 arch/arm/mach-tegra/pmc.c                          | 36 +++++++++++++++++++++
 arch/arm/mach-tegra/pmc.h                          |  4 +++
 17 files changed, 199 insertions(+), 37 deletions(-)

-- 
1.8.2



From josephl at nvidia.com  Tue Apr  2 07:19:41 2013
From: josephl at nvidia.com (Joseph Lo)
Date: Tue, 2 Apr 2013 19:19:41 +0800
Subject: [PATCH V3 1/3] ARM: tegra: get PMC clock source from DT
In-Reply-To: <1364901583-24867-1-git-send-email-josephl@nvidia.com>
References: <1364901583-24867-1-git-send-email-josephl@nvidia.com>
Message-ID: <1364901583-24867-2-git-send-email-josephl@nvidia.com>

Adding the bindings of the clock source of PMC in DT. And getting
the clock from DT.

Signed-off-by: Joseph Lo <josephl at nvidia.com>
---
V3:
* add binding document for the clock source of PMC
* get the clock from DT by of_get_clk_by_name()
* fix WARN_ON_ONCE to WARN_ON when there is no clock define in DT
V2:
* new in this series
---
 .../bindings/arm/tegra/nvidia,tegra20-pmc.txt      | 23 ++++++++++++++++++++++
 arch/arm/mach-tegra/common.c                       |  2 +-
 arch/arm/mach-tegra/pmc.c                          |  4 ++++
 3 files changed, 28 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt
index b5846e2..1cb8f6b 100644
--- a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt
+++ b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt
@@ -9,11 +9,34 @@ Properties:
   signal is fed into the PMC. This signal is optionally inverted, and then
   fed into the ARM GIC. The PMC is not involved in the detection or
   handling of this interrupt signal, merely its inversion.
+- clocks : the source clock of PMC
+- clock-names : the name of source clock of PMC
 
 Example:
 
+/ SoC dts including file
 pmc at 7000f400 {
 	compatible = "nvidia,tegra20-pmc";
 	reg = <0x7000e400 0x400>;
 	nvidia,invert-interrupt;
+	clocks = <&tegra_car 110>, <&clk32k_in>;
+	clock-names = "pclk", "clk32k_in";
 };
+
+/ Tegra board dts file
+{
+	...
+	clocks {
+		compatible = "simple-bus";
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		clk32k_in: clock at 0 {
+			compatible = "fixed-clock";
+			reg=<0>;
+			#clock-cells = <0>;
+			clock-frequency = <32768>;
+		};
+	};
+	...
+}
diff --git a/arch/arm/mach-tegra/common.c b/arch/arm/mach-tegra/common.c
index f0315c9..b02ebe7 100644
--- a/arch/arm/mach-tegra/common.c
+++ b/arch/arm/mach-tegra/common.c
@@ -61,6 +61,7 @@ u32 tegra_uart_config[4] = {
 void __init tegra_dt_init_irq(void)
 {
 	tegra_clocks_init();
+	tegra_pmc_init();
 	tegra_init_irq();
 	irqchip_init();
 }
@@ -100,7 +101,6 @@ void __init tegra_init_early(void)
 	tegra_apb_io_init();
 	tegra_init_fuse();
 	tegra_init_cache();
-	tegra_pmc_init();
 	tegra_powergate_init();
 	tegra_hotplug_init();
 }
diff --git a/arch/arm/mach-tegra/pmc.c b/arch/arm/mach-tegra/pmc.c
index b30e921..dbe2577 100644
--- a/arch/arm/mach-tegra/pmc.c
+++ b/arch/arm/mach-tegra/pmc.c
@@ -19,6 +19,7 @@
 #include <linux/io.h>
 #include <linux/of.h>
 #include <linux/of_address.h>
+#include <linux/clk.h>
 
 #define PMC_CTRL			0x0
 #define PMC_CTRL_INTR_LOW		(1 << 17)
@@ -43,6 +44,7 @@ static DEFINE_SPINLOCK(tegra_powergate_lock);
 
 static void __iomem *tegra_pmc_base;
 static bool tegra_pmc_invert_interrupt;
+static struct clk *tegra_pclk;
 
 static inline u32 tegra_pmc_readl(u32 reg)
 {
@@ -151,6 +153,8 @@ static void tegra_pmc_parse_dt(void)
 
 	tegra_pmc_invert_interrupt = of_property_read_bool(np,
 				     "nvidia,invert-interrupt");
+	tegra_pclk = of_clk_get_by_name(np, "pclk");
+	WARN_ON(IS_ERR(tegra_pclk));
 }
 
 void __init tegra_pmc_init(void)
-- 
1.8.2



From josephl at nvidia.com  Tue Apr  2 07:19:42 2013
From: josephl at nvidia.com (Joseph Lo)
Date: Tue, 2 Apr 2013 19:19:42 +0800
Subject: [PATCH V3 2/3] ARM: dts: tegra: add clock source for PMC
In-Reply-To: <1364901583-24867-1-git-send-email-josephl@nvidia.com>
References: <1364901583-24867-1-git-send-email-josephl@nvidia.com>
Message-ID: <1364901583-24867-3-git-send-email-josephl@nvidia.com>

Adding the clock sources of PMC into DTS for Tegra20 and Tegra30.

Signed-off-by: Joseph Lo <josephl at nvidia.com>
---
V3:
* add clk32k_in as one of the PMC clock source.
* add a fixed clock of clk32k_in for Tegra20 & Tegra30
V2:
* new in this change
---
 arch/arm/boot/dts/tegra20-colibri-512.dtsi | 13 +++++++++++++
 arch/arm/boot/dts/tegra20-harmony.dts      | 13 +++++++++++++
 arch/arm/boot/dts/tegra20-paz00.dts        | 13 +++++++++++++
 arch/arm/boot/dts/tegra20-seaboard.dts     | 13 +++++++++++++
 arch/arm/boot/dts/tegra20-tamonten.dtsi    | 13 +++++++++++++
 arch/arm/boot/dts/tegra20-trimslice.dts    | 13 +++++++++++++
 arch/arm/boot/dts/tegra20-ventana.dts      | 13 +++++++++++++
 arch/arm/boot/dts/tegra20-whistler.dts     | 13 +++++++++++++
 arch/arm/boot/dts/tegra20.dtsi             |  2 ++
 arch/arm/boot/dts/tegra30-beaver.dts       | 13 +++++++++++++
 arch/arm/boot/dts/tegra30-cardhu.dtsi      | 13 +++++++++++++
 arch/arm/boot/dts/tegra30.dtsi             |  2 ++
 12 files changed, 134 insertions(+)

diff --git a/arch/arm/boot/dts/tegra20-colibri-512.dtsi b/arch/arm/boot/dts/tegra20-colibri-512.dtsi
index cb73e62..4c107e6 100644
--- a/arch/arm/boot/dts/tegra20-colibri-512.dtsi
+++ b/arch/arm/boot/dts/tegra20-colibri-512.dtsi
@@ -8,6 +8,19 @@
 		reg = <0x00000000 0x20000000>;
 	};
 
+	clocks {
+		compatible = "simple-bus";
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		clk32k_in: clock {
+			compatible = "fixed-clock";
+			reg=<0>;
+			#clock-cells = <0>;
+			clock-frequency = <32768>;
+		};
+	};
+
 	host1x {
 		hdmi {
 			vdd-supply = <&hdmi_vdd_reg>;
diff --git a/arch/arm/boot/dts/tegra20-harmony.dts b/arch/arm/boot/dts/tegra20-harmony.dts
index 5fb0888..6e6899a 100644
--- a/arch/arm/boot/dts/tegra20-harmony.dts
+++ b/arch/arm/boot/dts/tegra20-harmony.dts
@@ -10,6 +10,19 @@
 		reg = <0x00000000 0x40000000>;
 	};
 
+	clocks {
+		compatible = "simple-bus";
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		clk32k_in: clock {
+			compatible = "fixed-clock";
+			reg=<0>;
+			#clock-cells = <0>;
+			clock-frequency = <32768>;
+		};
+	};
+
 	host1x {
 		hdmi {
 			status = "okay";
diff --git a/arch/arm/boot/dts/tegra20-paz00.dts b/arch/arm/boot/dts/tegra20-paz00.dts
index 43fd28b..54b05b2 100644
--- a/arch/arm/boot/dts/tegra20-paz00.dts
+++ b/arch/arm/boot/dts/tegra20-paz00.dts
@@ -10,6 +10,19 @@
 		reg = <0x00000000 0x20000000>;
 	};
 
+	clocks {
+		compatible = "simple-bus";
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		clk32k_in: clock {
+			compatible = "fixed-clock";
+			reg=<0>;
+			#clock-cells = <0>;
+			clock-frequency = <32768>;
+		};
+	};
+
 	host1x {
 		hdmi {
 			status = "okay";
diff --git a/arch/arm/boot/dts/tegra20-seaboard.dts b/arch/arm/boot/dts/tegra20-seaboard.dts
index 4f810a5..3b347b8 100644
--- a/arch/arm/boot/dts/tegra20-seaboard.dts
+++ b/arch/arm/boot/dts/tegra20-seaboard.dts
@@ -10,6 +10,19 @@
 		reg = <0x00000000 0x40000000>;
 	};
 
+	clocks {
+		compatible = "simple-bus";
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		clk32k_in: clock {
+			compatible = "fixed-clock";
+			reg=<0>;
+			#clock-cells = <0>;
+			clock-frequency = <32768>;
+		};
+	};
+
 	host1x {
 		hdmi {
 			status = "okay";
diff --git a/arch/arm/boot/dts/tegra20-tamonten.dtsi b/arch/arm/boot/dts/tegra20-tamonten.dtsi
index 6e9d91f..0c7bc18 100644
--- a/arch/arm/boot/dts/tegra20-tamonten.dtsi
+++ b/arch/arm/boot/dts/tegra20-tamonten.dtsi
@@ -8,6 +8,19 @@
 		reg = <0x00000000 0x20000000>;
 	};
 
+	clocks {
+		compatible = "simple-bus";
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		clk32k_in: clock {
+			compatible = "fixed-clock";
+			reg=<0>;
+			#clock-cells = <0>;
+			clock-frequency = <32768>;
+		};
+	};
+
 	host1x {
 		hdmi {
 			vdd-supply = <&hdmi_vdd_reg>;
diff --git a/arch/arm/boot/dts/tegra20-trimslice.dts b/arch/arm/boot/dts/tegra20-trimslice.dts
index 955bf49..b265ebd 100644
--- a/arch/arm/boot/dts/tegra20-trimslice.dts
+++ b/arch/arm/boot/dts/tegra20-trimslice.dts
@@ -10,6 +10,19 @@
 		reg = <0x00000000 0x40000000>;
 	};
 
+	clocks {
+		compatible = "simple-bus";
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		clk32k_in: clock {
+			compatible = "fixed-clock";
+			reg=<0>;
+			#clock-cells = <0>;
+			clock-frequency = <32768>;
+		};
+	};
+
 	host1x {
 		hdmi {
 			status = "okay";
diff --git a/arch/arm/boot/dts/tegra20-ventana.dts b/arch/arm/boot/dts/tegra20-ventana.dts
index 3f8ae10..157a2cd 100644
--- a/arch/arm/boot/dts/tegra20-ventana.dts
+++ b/arch/arm/boot/dts/tegra20-ventana.dts
@@ -10,6 +10,19 @@
 		reg = <0x00000000 0x40000000>;
 	};
 
+	clocks {
+		compatible = "simple-bus";
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		clk32k_in: clock {
+			compatible = "fixed-clock";
+			reg=<0>;
+			#clock-cells = <0>;
+			clock-frequency = <32768>;
+		};
+	};
+
 	host1x {
 		hdmi {
 			status = "okay";
diff --git a/arch/arm/boot/dts/tegra20-whistler.dts b/arch/arm/boot/dts/tegra20-whistler.dts
index 87e2d85..87632df 100644
--- a/arch/arm/boot/dts/tegra20-whistler.dts
+++ b/arch/arm/boot/dts/tegra20-whistler.dts
@@ -10,6 +10,19 @@
 		reg = <0x00000000 0x20000000>;
 	};
 
+	clocks {
+		compatible = "simple-bus";
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		clk32k_in: clock {
+			compatible = "fixed-clock";
+			reg=<0>;
+			#clock-cells = <0>;
+			clock-frequency = <32768>;
+		};
+	};
+
 	host1x {
 		hdmi {
 			status = "okay";
diff --git a/arch/arm/boot/dts/tegra20.dtsi b/arch/arm/boot/dts/tegra20.dtsi
index 26c1134..5fc661d 100644
--- a/arch/arm/boot/dts/tegra20.dtsi
+++ b/arch/arm/boot/dts/tegra20.dtsi
@@ -419,6 +419,8 @@
 	pmc {
 		compatible = "nvidia,tegra20-pmc";
 		reg = <0x7000e400 0x400>;
+		clocks = <&tegra_car 110>, <&clk32k_in>;
+		clock-names = "pclk", "clk32k_in";
 	};
 
 	memory-controller at 7000f000 {
diff --git a/arch/arm/boot/dts/tegra30-beaver.dts b/arch/arm/boot/dts/tegra30-beaver.dts
index 0a2cd24..c3e0f25 100644
--- a/arch/arm/boot/dts/tegra30-beaver.dts
+++ b/arch/arm/boot/dts/tegra30-beaver.dts
@@ -10,6 +10,19 @@
 		reg = <0x80000000 0x80000000>;
 	};
 
+	clocks {
+		compatible = "simple-bus";
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		clk32k_in: clock {
+			compatible = "fixed-clock";
+			reg=<0>;
+			#clock-cells = <0>;
+			clock-frequency = <32768>;
+		};
+	};
+
 	pinmux {
 		pinctrl-names = "default";
 		pinctrl-0 = <&state_default>;
diff --git a/arch/arm/boot/dts/tegra30-cardhu.dtsi b/arch/arm/boot/dts/tegra30-cardhu.dtsi
index 11204e1..eeea511 100644
--- a/arch/arm/boot/dts/tegra30-cardhu.dtsi
+++ b/arch/arm/boot/dts/tegra30-cardhu.dtsi
@@ -31,6 +31,19 @@
 		reg = <0x80000000 0x40000000>;
 	};
 
+	clocks {
+		compatible = "simple-bus";
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		clk32k_in: clock {
+			compatible = "fixed-clock";
+			reg=<0>;
+			#clock-cells = <0>;
+			clock-frequency = <32768>;
+		};
+	};
+
 	pinmux {
 		pinctrl-names = "default";
 		pinctrl-0 = <&state_default>;
diff --git a/arch/arm/boot/dts/tegra30.dtsi b/arch/arm/boot/dts/tegra30.dtsi
index 6042cc1..15ded60 100644
--- a/arch/arm/boot/dts/tegra30.dtsi
+++ b/arch/arm/boot/dts/tegra30.dtsi
@@ -428,6 +428,8 @@
 	pmc {
 		compatible = "nvidia,tegra30-pmc";
 		reg = <0x7000e400 0x400>;
+		clocks = <&tegra_car 218>, <&clk32k_in>;
+		clock-names = "pclk", "clk32k_in";
 	};
 
 	memory-controller {
-- 
1.8.2



From josephl at nvidia.com  Tue Apr  2 07:19:43 2013
From: josephl at nvidia.com (Joseph Lo)
Date: Tue, 2 Apr 2013 19:19:43 +0800
Subject: [PATCH V3 3/3] ARM: tegra: moving the CPU power timer function to PMC
 driver
In-Reply-To: <1364901583-24867-1-git-send-email-josephl@nvidia.com>
References: <1364901583-24867-1-git-send-email-josephl@nvidia.com>
Message-ID: <1364901583-24867-4-git-send-email-josephl@nvidia.com>

The CPU power timer set up fucntion was related to PMC register. Now moving
it to PMC driver. And it also help to clean up the PM related code later.

Signed-off-by: Joseph Lo <josephl at nvidia.com>
---
V3:
* no change
V2:
* the PCLK is from DT not hard code
---
 arch/arm/mach-tegra/pm.c  | 37 +------------------------------------
 arch/arm/mach-tegra/pmc.c | 32 ++++++++++++++++++++++++++++++++
 arch/arm/mach-tegra/pmc.h |  4 ++++
 3 files changed, 37 insertions(+), 36 deletions(-)

diff --git a/arch/arm/mach-tegra/pm.c b/arch/arm/mach-tegra/pm.c
index acacbe8..ef12c0d 100644
--- a/arch/arm/mach-tegra/pm.c
+++ b/arch/arm/mach-tegra/pm.c
@@ -22,7 +22,6 @@
 #include <linux/cpumask.h>
 #include <linux/delay.h>
 #include <linux/cpu_pm.h>
-#include <linux/clk.h>
 #include <linux/err.h>
 #include <linux/clk/tegra.h>
 
@@ -37,52 +36,18 @@
 #include "reset.h"
 #include "flowctrl.h"
 #include "fuse.h"
+#include "pmc.h"
 #include "sleep.h"
 
 #define TEGRA_POWER_CPU_PWRREQ_OE	(1 << 16)  /* CPU pwr req enable */
 
 #define PMC_CTRL		0x0
-#define PMC_CPUPWRGOOD_TIMER	0xc8
-#define PMC_CPUPWROFF_TIMER	0xcc
 
 #ifdef CONFIG_PM_SLEEP
 static DEFINE_SPINLOCK(tegra_lp2_lock);
 static void __iomem *pmc = IO_ADDRESS(TEGRA_PMC_BASE);
-static struct clk *tegra_pclk;
 void (*tegra_tear_down_cpu)(void);
 
-static void set_power_timers(unsigned long us_on, unsigned long us_off)
-{
-	unsigned long long ticks;
-	unsigned long long pclk;
-	unsigned long rate;
-	static unsigned long tegra_last_pclk;
-
-	if (tegra_pclk == NULL) {
-		tegra_pclk = clk_get_sys(NULL, "pclk");
-		WARN_ON(IS_ERR(tegra_pclk));
-	}
-
-	rate = clk_get_rate(tegra_pclk);
-
-	if (WARN_ON_ONCE(rate <= 0))
-		pclk = 100000000;
-	else
-		pclk = rate;
-
-	if ((rate != tegra_last_pclk)) {
-		ticks = (us_on * pclk) + 999999ull;
-		do_div(ticks, 1000000);
-		writel((unsigned long)ticks, pmc + PMC_CPUPWRGOOD_TIMER);
-
-		ticks = (us_off * pclk) + 999999ull;
-		do_div(ticks, 1000000);
-		writel((unsigned long)ticks, pmc + PMC_CPUPWROFF_TIMER);
-		wmb();
-	}
-	tegra_last_pclk = pclk;
-}
-
 /*
  * restore_cpu_complex
  *
diff --git a/arch/arm/mach-tegra/pmc.c b/arch/arm/mach-tegra/pmc.c
index dbe2577..8abf02f 100644
--- a/arch/arm/mach-tegra/pmc.c
+++ b/arch/arm/mach-tegra/pmc.c
@@ -28,6 +28,9 @@
 #define PMC_REMOVE_CLAMPING		0x34
 #define PMC_PWRGATE_STATUS		0x38
 
+#define PMC_CPUPWRGOOD_TIMER	0xc8
+#define PMC_CPUPWROFF_TIMER	0xcc
+
 #define TEGRA_POWERGATE_PCIE	3
 #define TEGRA_POWERGATE_VDEC	4
 #define TEGRA_POWERGATE_CPU1	9
@@ -135,6 +138,35 @@ int tegra_pmc_cpu_remove_clamping(int cpuid)
 	return tegra_pmc_powergate_remove_clamping(id);
 }
 
+#ifdef CONFIG_PM_SLEEP
+void set_power_timers(unsigned long us_on, unsigned long us_off)
+{
+	unsigned long long ticks;
+	unsigned long long pclk;
+	unsigned long rate;
+	static unsigned long tegra_last_pclk;
+
+	rate = clk_get_rate(tegra_pclk);
+
+	if (WARN_ON_ONCE(rate <= 0))
+		pclk = 100000000;
+	else
+		pclk = rate;
+
+	if ((rate != tegra_last_pclk)) {
+		ticks = (us_on * pclk) + 999999ull;
+		do_div(ticks, 1000000);
+		tegra_pmc_writel((unsigned long)ticks, PMC_CPUPWRGOOD_TIMER);
+
+		ticks = (us_off * pclk) + 999999ull;
+		do_div(ticks, 1000000);
+		tegra_pmc_writel((unsigned long)ticks, PMC_CPUPWROFF_TIMER);
+		wmb();
+	}
+	tegra_last_pclk = pclk;
+}
+#endif
+
 static const struct of_device_id matches[] __initconst = {
 	{ .compatible = "nvidia,tegra114-pmc" },
 	{ .compatible = "nvidia,tegra30-pmc" },
diff --git a/arch/arm/mach-tegra/pmc.h b/arch/arm/mach-tegra/pmc.h
index 7d44710..22f16c9 100644
--- a/arch/arm/mach-tegra/pmc.h
+++ b/arch/arm/mach-tegra/pmc.h
@@ -18,6 +18,10 @@
 #ifndef __MACH_TEGRA_PMC_H
 #define __MACH_TEGRA_PMC_H
 
+#ifdef CONFIG_PM_SLEEP
+void set_power_timers(unsigned long us_on, unsigned long us_off);
+#endif
+
 bool tegra_pmc_cpu_is_powered(int cpuid);
 int tegra_pmc_cpu_power_on(int cpuid);
 int tegra_pmc_cpu_remove_clamping(int cpuid);
-- 
1.8.2



From josephl at nvidia.com  Tue Apr  2 07:20:04 2013
From: josephl at nvidia.com (Joseph Lo)
Date: Tue, 2 Apr 2013 19:20:04 +0800
Subject: [PATCH V5 0/9] ARM: tegra: add platform suspend support
Message-ID: <1364901613-25080-1-git-send-email-josephl@nvidia.com>

This series introduces a basic functionality for Tegra to support the
platform suspend and resume.

Note: This series only adds the support for Tegra20 and Tegra30. The
Tegra114 will be supported later.

Verified on Seaboard and Cardhu.

V5:
* some fixes from V4's review comments

V4:
* add tegra_pm_validate_suspend_mode() to validate the suspend mode config
  from DT
* squash the patch below into [4/9] to avoid churn after this series
  [2/3] ARM: tegra: refactor the pmc_pm_set function

V3:
* fix the PMC DT configurations for paz00 board
* add a protection for only support LP2 suspend mode

V2:
* re-order the patch sequence to make sure the suspend function can be
  enabled well after the last patch be merged
* squash the patches that defined the PM bindings for PMC and the
  implementation


Joseph Lo (9):
  gpio: tegra: add gpio wakeup source handling
  ARM: tegra: irq: add wake up handling
  ARM: dt: tegra: add bindings of power management configurations for
    PMC
  ARM: tegra: pm: add platform suspend support
  ARM: dts: tegra: add power gpio keys to DT
  ARM: dts: tegra: whistler: add wakeup source for KBC
  ARM: dts: tegra: add non-removable and keep-power-in-suspend property
    for MMC
  ARM: tegra: config: defconfig update
  ARM: dts: tegra: add the PM configurations of PMC

 .../bindings/arm/tegra/nvidia,tegra20-pmc.txt      |  42 ++++++-
 arch/arm/boot/dts/tegra20-harmony.dts              |  17 +++
 arch/arm/boot/dts/tegra20-paz00.dts                |   7 ++
 arch/arm/boot/dts/tegra20-seaboard.dts             |   8 ++
 arch/arm/boot/dts/tegra20-trimslice.dts            |  20 +++
 arch/arm/boot/dts/tegra20-ventana.dts              |  19 +++
 arch/arm/boot/dts/tegra20-whistler.dts             |  10 ++
 arch/arm/boot/dts/tegra30-beaver.dts               |   8 ++
 arch/arm/boot/dts/tegra30-cardhu-a02.dts           |   1 +
 arch/arm/boot/dts/tegra30-cardhu-a04.dts           |   1 +
 arch/arm/boot/dts/tegra30-cardhu.dtsi              |   8 ++
 arch/arm/configs/tegra_defconfig                   |   1 +
 arch/arm/mach-tegra/common.c                       |   3 +
 arch/arm/mach-tegra/irq.c                          |  96 ++++++++++++++-
 arch/arm/mach-tegra/irq.h                          |   6 +
 arch/arm/mach-tegra/pm.c                           |  93 ++++++++++++--
 arch/arm/mach-tegra/pm.h                           |  15 +++
 arch/arm/mach-tegra/pmc.c                          | 134 ++++++++++++++++++++-
 arch/arm/mach-tegra/pmc.h                          |  12 +-
 drivers/gpio/gpio-tegra.c                          |  21 +++-
 20 files changed, 500 insertions(+), 22 deletions(-)

-- 
1.8.2



From josephl at nvidia.com  Tue Apr  2 07:20:05 2013
From: josephl at nvidia.com (Joseph Lo)
Date: Tue, 2 Apr 2013 19:20:05 +0800
Subject: [PATCH V5 1/9] gpio: tegra: add gpio wakeup source handling
In-Reply-To: <1364901613-25080-1-git-send-email-josephl@nvidia.com>
References: <1364901613-25080-1-git-send-email-josephl@nvidia.com>
Message-ID: <1364901613-25080-2-git-send-email-josephl@nvidia.com>

This patch add the gpio wakeup source handling for the Tegra platform. It
was be done by enabling the irq for the gpio in the gpio controller and
enabling the bank irq of the gpio in the Tegra legacy irq controller when
the system going to suspend.

Based on the work by:
Varun Wadekar <vwadekar at nvidia.com>

Cc: Grant Likely <grant.likely at secretlab.ca>
Cc: Linus Walleij <linus.walleij at linaro.org>
Signed-off-by: Joseph Lo <josephl at nvidia.com>
Acked-by: Linus Walleij <linus.walleij at linaro.org>
---
V5:
* no change
V4:
* no change
V3:
* no change
V2:
* no change
---
 drivers/gpio/gpio-tegra.c | 21 +++++++++++++++++++--
 1 file changed, 19 insertions(+), 2 deletions(-)

diff --git a/drivers/gpio/gpio-tegra.c b/drivers/gpio/gpio-tegra.c
index a78a81f..2f1b265 100644
--- a/drivers/gpio/gpio-tegra.c
+++ b/drivers/gpio/gpio-tegra.c
@@ -72,6 +72,7 @@ struct tegra_gpio_bank {
 	u32 oe[4];
 	u32 int_enb[4];
 	u32 int_lvl[4];
+	u32 wake_enb[4];
 #endif
 };
 
@@ -333,15 +334,31 @@ static int tegra_gpio_suspend(struct device *dev)
 			bank->oe[p] = tegra_gpio_readl(GPIO_OE(gpio));
 			bank->int_enb[p] = tegra_gpio_readl(GPIO_INT_ENB(gpio));
 			bank->int_lvl[p] = tegra_gpio_readl(GPIO_INT_LVL(gpio));
+
+			/* Enable gpio irq for wake up source */
+			tegra_gpio_writel(bank->wake_enb[p],
+					  GPIO_INT_ENB(gpio));
 		}
 	}
 	local_irq_restore(flags);
 	return 0;
 }
 
-static int tegra_gpio_wake_enable(struct irq_data *d, unsigned int enable)
+static int tegra_gpio_irq_set_wake(struct irq_data *d, unsigned int enable)
 {
 	struct tegra_gpio_bank *bank = irq_data_get_irq_chip_data(d);
+	int gpio = d->hwirq;
+	u32 port, bit, mask;
+
+	port = GPIO_PORT(gpio);
+	bit = GPIO_BIT(gpio);
+	mask = BIT(bit);
+
+	if (enable)
+		bank->wake_enb[port] |= mask;
+	else
+		bank->wake_enb[port] &= ~mask;
+
 	return irq_set_irq_wake(bank->irq, enable);
 }
 #endif
@@ -353,7 +370,7 @@ static struct irq_chip tegra_gpio_irq_chip = {
 	.irq_unmask	= tegra_gpio_irq_unmask,
 	.irq_set_type	= tegra_gpio_irq_set_type,
 #ifdef CONFIG_PM_SLEEP
-	.irq_set_wake	= tegra_gpio_wake_enable,
+	.irq_set_wake	= tegra_gpio_irq_set_wake,
 #endif
 };
 
-- 
1.8.2



From josephl at nvidia.com  Tue Apr  2 07:20:06 2013
From: josephl at nvidia.com (Joseph Lo)
Date: Tue, 2 Apr 2013 19:20:06 +0800
Subject: [PATCH V5 2/9] ARM: tegra: irq: add wake up handling
In-Reply-To: <1364901613-25080-1-git-send-email-josephl@nvidia.com>
References: <1364901613-25080-1-git-send-email-josephl@nvidia.com>
Message-ID: <1364901613-25080-3-git-send-email-josephl@nvidia.com>

Add the wake up handling for legacy irq controller, and using
IRQCHIP_MASK_ON_SUSPEND for wake irq handling.

Based on the work by:
Varun Wadekar <vwadekar at nvidia.com>

Signed-off-by: Joseph Lo <josephl at nvidia.com>
---
V5:
* don't use BUG_ON when irq_nr is not correct in set_wake function
V4:
* no change
V3:
* no change
V2:
* no change
---
 arch/arm/mach-tegra/common.c |  2 +
 arch/arm/mach-tegra/irq.c    | 96 +++++++++++++++++++++++++++++++++++++++++++-
 arch/arm/mach-tegra/irq.h    |  6 +++
 3 files changed, 103 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-tegra/common.c b/arch/arm/mach-tegra/common.c
index b02ebe7..c84505c 100644
--- a/arch/arm/mach-tegra/common.c
+++ b/arch/arm/mach-tegra/common.c
@@ -33,6 +33,7 @@
 #include "common.h"
 #include "fuse.h"
 #include "iomap.h"
+#include "irq.h"
 #include "pmc.h"
 #include "apbio.h"
 #include "sleep.h"
@@ -64,6 +65,7 @@ void __init tegra_dt_init_irq(void)
 	tegra_pmc_init();
 	tegra_init_irq();
 	irqchip_init();
+	tegra_legacy_irq_syscore_init();
 }
 #endif
 
diff --git a/arch/arm/mach-tegra/irq.c b/arch/arm/mach-tegra/irq.c
index 1952e82..0de4eed 100644
--- a/arch/arm/mach-tegra/irq.c
+++ b/arch/arm/mach-tegra/irq.c
@@ -4,7 +4,7 @@
  * Author:
  *	Colin Cross <ccross at android.com>
  *
- * Copyright (C) 2010, NVIDIA Corporation
+ * Copyright (C) 2010,2013, NVIDIA Corporation
  *
  * This software is licensed under the terms of the GNU General Public
  * License version 2, as published by the Free Software Foundation, and
@@ -23,6 +23,7 @@
 #include <linux/io.h>
 #include <linux/of.h>
 #include <linux/irqchip/arm-gic.h>
+#include <linux/syscore_ops.h>
 
 #include "board.h"
 #include "iomap.h"
@@ -43,6 +44,7 @@
 #define ICTLR_COP_IEP_CLASS	0x3c
 
 #define FIRST_LEGACY_IRQ 32
+#define TEGRA_MAX_NUM_ICTLRS	5
 
 #define SGI_MASK 0xFFFF
 
@@ -56,6 +58,15 @@ static void __iomem *ictlr_reg_base[] = {
 	IO_ADDRESS(TEGRA_QUINARY_ICTLR_BASE),
 };
 
+#ifdef CONFIG_PM_SLEEP
+static u32 cop_ier[TEGRA_MAX_NUM_ICTLRS];
+static u32 cop_iep[TEGRA_MAX_NUM_ICTLRS];
+static u32 cpu_ier[TEGRA_MAX_NUM_ICTLRS];
+static u32 cpu_iep[TEGRA_MAX_NUM_ICTLRS];
+
+static u32 ictlr_wake_mask[TEGRA_MAX_NUM_ICTLRS];
+#endif
+
 bool tegra_pending_sgi(void)
 {
 	u32 pending_set;
@@ -125,6 +136,87 @@ static int tegra_retrigger(struct irq_data *d)
 	return 1;
 }
 
+#ifdef CONFIG_PM_SLEEP
+static int tegra_set_wake(struct irq_data *d, unsigned int enable)
+{
+	u32 irq = d->irq;
+	u32 index, mask;
+
+	if (irq < FIRST_LEGACY_IRQ ||
+		irq >= FIRST_LEGACY_IRQ + num_ictlrs * 32)
+		return -EINVAL;
+
+	index = ((irq - FIRST_LEGACY_IRQ) / 32);
+	mask = BIT((irq - FIRST_LEGACY_IRQ) % 32);
+	if (enable)
+		ictlr_wake_mask[index] |= mask;
+	else
+		ictlr_wake_mask[index] &= ~mask;
+
+	return 0;
+}
+
+static int tegra_legacy_irq_suspend(void)
+{
+	unsigned long flags;
+	int i;
+
+	local_irq_save(flags);
+	for (i = 0; i < num_ictlrs; i++) {
+		void __iomem *ictlr = ictlr_reg_base[i];
+		/* Save interrupt state */
+		cpu_ier[i] = readl_relaxed(ictlr + ICTLR_CPU_IER);
+		cpu_iep[i] = readl_relaxed(ictlr + ICTLR_CPU_IEP_CLASS);
+		cop_ier[i] = readl_relaxed(ictlr + ICTLR_COP_IER);
+		cop_iep[i] = readl_relaxed(ictlr + ICTLR_COP_IEP_CLASS);
+
+		/* Disable COP interrupts */
+		writel_relaxed(~0ul, ictlr + ICTLR_COP_IER_CLR);
+
+		/* Disable CPU interrupts */
+		writel_relaxed(~0ul, ictlr + ICTLR_CPU_IER_CLR);
+
+		/* Enable the wakeup sources of ictlr */
+		writel_relaxed(ictlr_wake_mask[i], ictlr + ICTLR_CPU_IER_SET);
+	}
+	local_irq_restore(flags);
+
+	return 0;
+}
+
+static void tegra_legacy_irq_resume(void)
+{
+	unsigned long flags;
+	int i;
+
+	local_irq_save(flags);
+	for (i = 0; i < num_ictlrs; i++) {
+		void __iomem *ictlr = ictlr_reg_base[i];
+		writel_relaxed(cpu_iep[i], ictlr + ICTLR_CPU_IEP_CLASS);
+		writel_relaxed(~0ul, ictlr + ICTLR_CPU_IER_CLR);
+		writel_relaxed(cpu_ier[i], ictlr + ICTLR_CPU_IER_SET);
+		writel_relaxed(cop_iep[i], ictlr + ICTLR_COP_IEP_CLASS);
+		writel_relaxed(~0ul, ictlr + ICTLR_COP_IER_CLR);
+		writel_relaxed(cop_ier[i], ictlr + ICTLR_COP_IER_SET);
+	}
+	local_irq_restore(flags);
+}
+
+static struct syscore_ops tegra_legacy_irq_syscore_ops = {
+	.suspend = tegra_legacy_irq_suspend,
+	.resume = tegra_legacy_irq_resume,
+};
+
+int tegra_legacy_irq_syscore_init(void)
+{
+	register_syscore_ops(&tegra_legacy_irq_syscore_ops);
+
+	return 0;
+}
+#else
+#define tegra_set_wake NULL
+#endif
+
 void __init tegra_init_irq(void)
 {
 	int i;
@@ -150,6 +242,8 @@ void __init tegra_init_irq(void)
 	gic_arch_extn.irq_mask = tegra_mask;
 	gic_arch_extn.irq_unmask = tegra_unmask;
 	gic_arch_extn.irq_retrigger = tegra_retrigger;
+	gic_arch_extn.irq_set_wake = tegra_set_wake;
+	gic_arch_extn.flags = IRQCHIP_MASK_ON_SUSPEND;
 
 	/*
 	 * Check if there is a devicetree present, since the GIC will be
diff --git a/arch/arm/mach-tegra/irq.h b/arch/arm/mach-tegra/irq.h
index 5142649..bc05ce5 100644
--- a/arch/arm/mach-tegra/irq.h
+++ b/arch/arm/mach-tegra/irq.h
@@ -19,4 +19,10 @@
 
 bool tegra_pending_sgi(void);
 
+#ifdef CONFIG_PM_SLEEP
+int tegra_legacy_irq_syscore_init(void);
+#else
+static inline int tegra_legacy_irq_syscore_init(void) { return 0; }
+#endif
+
 #endif
-- 
1.8.2



From josephl at nvidia.com  Tue Apr  2 07:20:08 2013
From: josephl at nvidia.com (Joseph Lo)
Date: Tue, 2 Apr 2013 19:20:08 +0800
Subject: [PATCH V5 4/9] ARM: tegra: pm: add platform suspend support
In-Reply-To: <1364901613-25080-1-git-send-email-josephl@nvidia.com>
References: <1364901613-25080-1-git-send-email-josephl@nvidia.com>
Message-ID: <1364901613-25080-5-git-send-email-josephl@nvidia.com>

Adding suspend to RAM support for Tegra platform. There are three suspend
mode for Tegra. The difference were below.

* LP2: CPU voltage off
* LP1: CPU voltage off, DRAM in self-refresh
* LP0: CPU + Core voltage off, DRAM in self-refresh

After this patch, the LP2 suspend mode will be supported.

Signed-off-by: Joseph Lo <josephl at nvidia.com>
---
V5:
* move tegra_init_suspend() to tegra_init_late()
* remove useless BUG_ON for the polarity of CPU power request
V4:
* add tegra_pm_validate_suspend_mode() to validate the suspend mode config
  from DT
* squash the patch below that origianl being introduced after this series
  to clean up some PM related code
  [2/3] ARM: tegra: refactor the pmc_pm_set function
V3:
* add a protection for only support LP2 suspend mode
V2:
* add the PM_SLEEP protection for "tegra_init_suspend"
* remove "tegra_suspend_{enter/exit}_lp2"
* refactor the "tegra_pmc_pm_set" for non-used parameter
* replace "unsigned long" with "u32" for tegra_pmc_get_cpu_time
---
 arch/arm/mach-tegra/common.c |  1 +
 arch/arm/mach-tegra/pm.c     | 93 +++++++++++++++++++++++++++++++++++++-------
 arch/arm/mach-tegra/pm.h     | 15 +++++++
 arch/arm/mach-tegra/pmc.c    | 51 ++++++++++++++++++++++--
 arch/arm/mach-tegra/pmc.h    |  4 +-
 5 files changed, 146 insertions(+), 18 deletions(-)

diff --git a/arch/arm/mach-tegra/common.c b/arch/arm/mach-tegra/common.c
index c84505c..eb1f3c8 100644
--- a/arch/arm/mach-tegra/common.c
+++ b/arch/arm/mach-tegra/common.c
@@ -109,5 +109,6 @@ void __init tegra_init_early(void)
 
 void __init tegra_init_late(void)
 {
+	tegra_init_suspend();
 	tegra_powergate_debugfs_init();
 }
diff --git a/arch/arm/mach-tegra/pm.c b/arch/arm/mach-tegra/pm.c
index ef12c0d..14957ff 100644
--- a/arch/arm/mach-tegra/pm.c
+++ b/arch/arm/mach-tegra/pm.c
@@ -22,6 +22,7 @@
 #include <linux/cpumask.h>
 #include <linux/delay.h>
 #include <linux/cpu_pm.h>
+#include <linux/suspend.h>
 #include <linux/err.h>
 #include <linux/clk/tegra.h>
 
@@ -38,14 +39,10 @@
 #include "fuse.h"
 #include "pmc.h"
 #include "sleep.h"
-
-#define TEGRA_POWER_CPU_PWRREQ_OE	(1 << 16)  /* CPU pwr req enable */
-
-#define PMC_CTRL		0x0
+#include "pmc.h"
 
 #ifdef CONFIG_PM_SLEEP
 static DEFINE_SPINLOCK(tegra_lp2_lock);
-static void __iomem *pmc = IO_ADDRESS(TEGRA_PMC_BASE);
 void (*tegra_tear_down_cpu)(void);
 
 /*
@@ -140,14 +137,7 @@ static int tegra_sleep_cpu(unsigned long v2p)
 
 void tegra_idle_lp2_last(u32 cpu_on_time, u32 cpu_off_time)
 {
-	u32 mode;
-
-	/* Only the last cpu down does the final suspend steps */
-	mode = readl(pmc + PMC_CTRL);
-	mode |= TEGRA_POWER_CPU_PWRREQ_OE;
-	writel(mode, pmc + PMC_CTRL);
-
-	set_power_timers(cpu_on_time, cpu_off_time);
+	tegra_pmc_pm_set(TEGRA_SUSPEND_LP2);
 
 	cpu_cluster_pm_enter();
 	suspend_cpu_complex();
@@ -157,4 +147,81 @@ void tegra_idle_lp2_last(u32 cpu_on_time, u32 cpu_off_time)
 	restore_cpu_complex();
 	cpu_cluster_pm_exit();
 }
+
+enum tegra_suspend_mode tegra_pm_validate_suspend_mode(
+				enum tegra_suspend_mode mode)
+{
+	/* Tegra114 didn't support any suspending mode yet. */
+	if (tegra_chip_id == TEGRA114)
+		return TEGRA_SUSPEND_NONE;
+
+	/*
+	 * The Tegra devices only support suspending to LP2 currently.
+	 */
+	if (mode > TEGRA_SUSPEND_LP2)
+		return TEGRA_SUSPEND_LP2;
+
+	return mode;
+}
+
+static const char *lp_state[TEGRA_MAX_SUSPEND_MODE] = {
+	[TEGRA_SUSPEND_NONE] = "none",
+	[TEGRA_SUSPEND_LP2] = "LP2",
+	[TEGRA_SUSPEND_LP1] = "LP1",
+	[TEGRA_SUSPEND_LP0] = "LP0",
+};
+
+static int __cpuinit tegra_suspend_enter(suspend_state_t state)
+{
+	enum tegra_suspend_mode mode = tegra_pmc_get_suspend_mode();
+
+	if (WARN_ON(mode < TEGRA_SUSPEND_NONE ||
+		    mode >= TEGRA_MAX_SUSPEND_MODE))
+		return -EINVAL;
+
+	pr_info("Entering suspend state %s\n", lp_state[mode]);
+
+	tegra_pmc_pm_set(mode);
+
+	local_fiq_disable();
+
+	suspend_cpu_complex();
+	switch (mode) {
+	case TEGRA_SUSPEND_LP2:
+		tegra_set_cpu_in_lp2(0);
+		break;
+	default:
+		break;
+	}
+
+	cpu_suspend(PHYS_OFFSET - PAGE_OFFSET, &tegra_sleep_cpu);
+
+	switch (mode) {
+	case TEGRA_SUSPEND_LP2:
+		tegra_clear_cpu_in_lp2(0);
+		break;
+	default:
+		break;
+	}
+	restore_cpu_complex();
+
+	local_fiq_enable();
+
+	return 0;
+}
+
+static const struct platform_suspend_ops tegra_suspend_ops = {
+	.valid		= suspend_valid_only_mem,
+	.enter		= tegra_suspend_enter,
+};
+
+void __init tegra_init_suspend(void)
+{
+	if (tegra_pmc_get_suspend_mode() == TEGRA_SUSPEND_NONE)
+		return;
+
+	tegra_pmc_suspend_init();
+
+	suspend_set_ops(&tegra_suspend_ops);
+}
 #endif
diff --git a/arch/arm/mach-tegra/pm.h b/arch/arm/mach-tegra/pm.h
index 787335c..73a45f1 100644
--- a/arch/arm/mach-tegra/pm.h
+++ b/arch/arm/mach-tegra/pm.h
@@ -21,6 +21,8 @@
 #ifndef _MACH_TEGRA_PM_H_
 #define _MACH_TEGRA_PM_H_
 
+#include "pmc.h"
+
 extern unsigned long l2x0_saved_regs_addr;
 
 void save_cpu_arch_register(void);
@@ -32,4 +34,17 @@ bool tegra_set_cpu_in_lp2(int phy_cpu_id);
 void tegra_idle_lp2_last(u32 cpu_on_time, u32 cpu_off_time);
 extern void (*tegra_tear_down_cpu)(void);
 
+#ifdef CONFIG_PM_SLEEP
+enum tegra_suspend_mode tegra_pm_validate_suspend_mode(
+				enum tegra_suspend_mode mode);
+void tegra_init_suspend(void);
+#else
+enum tegra_suspend_mode tegra_pm_validate_suspend_mode(
+				enum tegra_suspend_mode mode)
+{
+	return TEGRA_SUSPEND_NONE;
+}
+static inline void tegra_init_suspend(void) {}
+#endif
+
 #endif /* _MACH_TEGRA_PM_H_ */
diff --git a/arch/arm/mach-tegra/pmc.c b/arch/arm/mach-tegra/pmc.c
index 5323bca..0d50d34 100644
--- a/arch/arm/mach-tegra/pmc.c
+++ b/arch/arm/mach-tegra/pmc.c
@@ -21,7 +21,14 @@
 #include <linux/of_address.h>
 #include <linux/clk.h>
 
+#include "fuse.h"
+#include "pm.h"
 #include "pmc.h"
+#include "sleep.h"
+
+#define TEGRA_POWER_EFFECT_LP0		(1 << 14)  /* LP0 when CPU pwr gated */
+#define TEGRA_POWER_CPU_PWRREQ_POLARITY	(1 << 15)  /* CPU pwr req polarity */
+#define TEGRA_POWER_CPU_PWRREQ_OE	(1 << 16)  /* CPU pwr req enable */
 
 #define PMC_CTRL			0x0
 #define PMC_CTRL_INTR_LOW		(1 << 17)
@@ -157,15 +164,12 @@ int tegra_pmc_cpu_remove_clamping(int cpuid)
 }
 
 #ifdef CONFIG_PM_SLEEP
-void set_power_timers(unsigned long us_on, unsigned long us_off)
+static void set_power_timers(u32 us_on, u32 us_off, unsigned long rate)
 {
 	unsigned long long ticks;
 	unsigned long long pclk;
-	unsigned long rate;
 	static unsigned long tegra_last_pclk;
 
-	rate = clk_get_rate(tegra_pclk);
-
 	if (WARN_ON_ONCE(rate <= 0))
 		pclk = 100000000;
 	else
@@ -183,6 +187,44 @@ void set_power_timers(unsigned long us_on, unsigned long us_off)
 	}
 	tegra_last_pclk = pclk;
 }
+
+enum tegra_suspend_mode tegra_pmc_get_suspend_mode(void)
+{
+	return pmc_pm_data.suspend_mode;
+}
+
+void tegra_pmc_pm_set(enum tegra_suspend_mode mode)
+{
+	u32 reg;
+	unsigned long rate = 0;
+
+	reg = tegra_pmc_readl(PMC_CTRL);
+	reg |= TEGRA_POWER_CPU_PWRREQ_OE;
+	reg &= ~TEGRA_POWER_EFFECT_LP0;
+
+	switch (mode) {
+	case TEGRA_SUSPEND_LP2:
+		rate = clk_get_rate(tegra_pclk);
+		break;
+	default:
+		break;
+	}
+
+	set_power_timers(pmc_pm_data.cpu_good_time, pmc_pm_data.cpu_off_time,
+			 rate);
+
+	tegra_pmc_writel(reg, PMC_CTRL);
+}
+
+void tegra_pmc_suspend_init(void)
+{
+	u32 reg;
+
+	/* Always enable CPU power request */
+	reg = tegra_pmc_readl(PMC_CTRL);
+	reg |= TEGRA_POWER_CPU_PWRREQ_OE;
+	tegra_pmc_writel(reg, PMC_CTRL);
+}
 #endif
 
 static const struct of_device_id matches[] __initconst = {
@@ -229,6 +271,7 @@ static void tegra_pmc_parse_dt(void)
 			break;
 		}
 	}
+	suspend_mode = tegra_pm_validate_suspend_mode(suspend_mode);
 
 	if (of_property_read_u32(np, "nvidia,cpu-pwr-good-time", &prop))
 		suspend_mode = TEGRA_SUSPEND_NONE;
diff --git a/arch/arm/mach-tegra/pmc.h b/arch/arm/mach-tegra/pmc.h
index 6bc0fc09..e1c2df2 100644
--- a/arch/arm/mach-tegra/pmc.h
+++ b/arch/arm/mach-tegra/pmc.h
@@ -27,7 +27,9 @@ enum tegra_suspend_mode {
 };
 
 #ifdef CONFIG_PM_SLEEP
-void set_power_timers(unsigned long us_on, unsigned long us_off);
+enum tegra_suspend_mode tegra_pmc_get_suspend_mode(void);
+void tegra_pmc_pm_set(enum tegra_suspend_mode mode);
+void tegra_pmc_suspend_init(void);
 #endif
 
 bool tegra_pmc_cpu_is_powered(int cpuid);
-- 
1.8.2



From josephl at nvidia.com  Tue Apr  2 07:20:09 2013
From: josephl at nvidia.com (Joseph Lo)
Date: Tue, 2 Apr 2013 19:20:09 +0800
Subject: [PATCH V5 5/9] ARM: dts: tegra: add power gpio keys to DT
In-Reply-To: <1364901613-25080-1-git-send-email-josephl@nvidia.com>
References: <1364901613-25080-1-git-send-email-josephl@nvidia.com>
Message-ID: <1364901613-25080-6-git-send-email-josephl@nvidia.com>

This adds the power gpio key to DT and enable the wakeup of the gpio key
for the device. The Seaboard and paz00 already had the power gpio key
binding and the power key of Whistler was on KBC. So these boards' device
tree didn't include in this patch.

Signed-off-by: Joseph Lo <josephl at nvidia.com>
---
V5:
* no change
V4:
* no change
V3:
* no change
V2:
* no change
---
 arch/arm/boot/dts/tegra20-harmony.dts   | 11 +++++++++++
 arch/arm/boot/dts/tegra20-trimslice.dts | 11 +++++++++++
 arch/arm/boot/dts/tegra20-ventana.dts   | 11 +++++++++++
 3 files changed, 33 insertions(+)

diff --git a/arch/arm/boot/dts/tegra20-harmony.dts b/arch/arm/boot/dts/tegra20-harmony.dts
index 6e6899a..4f08521 100644
--- a/arch/arm/boot/dts/tegra20-harmony.dts
+++ b/arch/arm/boot/dts/tegra20-harmony.dts
@@ -581,6 +581,17 @@
 				0x1F0400D6>;	/* KEY_QUESTION */
 	};
 
+	gpio-keys {
+		compatible = "gpio-keys";
+
+		power {
+			label = "Power";
+			gpios = <&gpio 170 1>; /* gpio PV2, active low */
+			linux,code = <116>; /* KEY_POWER */
+			gpio-key,wakeup;
+		};
+	};
+
 	regulators {
 		compatible = "simple-bus";
 		#address-cells = <1>;
diff --git a/arch/arm/boot/dts/tegra20-trimslice.dts b/arch/arm/boot/dts/tegra20-trimslice.dts
index b265ebd..8e8d4f6 100644
--- a/arch/arm/boot/dts/tegra20-trimslice.dts
+++ b/arch/arm/boot/dts/tegra20-trimslice.dts
@@ -348,6 +348,17 @@
 		gpios = <&gpio 191 1>; /* gpio PX7, active low */
 	};
 
+	gpio-keys {
+		compatible = "gpio-keys";
+
+		power {
+			label = "Power";
+			gpios = <&gpio 190 1>; /* gpio PX6, active low */
+			linux,code = <116>; /* KEY_POWER */
+			gpio-key,wakeup;
+		};
+	};
+
 	regulators {
 		compatible = "simple-bus";
 		#address-cells = <1>;
diff --git a/arch/arm/boot/dts/tegra20-ventana.dts b/arch/arm/boot/dts/tegra20-ventana.dts
index 157a2cd..112ef5c 100644
--- a/arch/arm/boot/dts/tegra20-ventana.dts
+++ b/arch/arm/boot/dts/tegra20-ventana.dts
@@ -544,6 +544,17 @@
 		bus-width = <8>;
 	};
 
+	gpio-keys {
+		compatible = "gpio-keys";
+
+		power {
+			label = "Power";
+			gpios = <&gpio 170 1>; /* gpio PV2, active low */
+			linux,code = <116>; /* KEY_POWER */
+			gpio-key,wakeup;
+		};
+	};
+
 	regulators {
 		compatible = "simple-bus";
 		#address-cells = <1>;
-- 
1.8.2



From josephl at nvidia.com  Tue Apr  2 07:20:10 2013
From: josephl at nvidia.com (Joseph Lo)
Date: Tue, 2 Apr 2013 19:20:10 +0800
Subject: [PATCH V5 6/9] ARM: dts: tegra: whistler: add wakeup source for KBC
In-Reply-To: <1364901613-25080-1-git-send-email-josephl@nvidia.com>
References: <1364901613-25080-1-git-send-email-josephl@nvidia.com>
Message-ID: <1364901613-25080-7-git-send-email-josephl@nvidia.com>

Adding KBC as a wakeup source for Whistler board.

Signed-off-by: Joseph Lo <josephl at nvidia.com>
---
V5:
* no change
V4:
* no change
V3:
* no change
V2:
* no change
---
 arch/arm/boot/dts/tegra20-whistler.dts | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/tegra20-whistler.dts b/arch/arm/boot/dts/tegra20-whistler.dts
index 87632df..0b04262 100644
--- a/arch/arm/boot/dts/tegra20-whistler.dts
+++ b/arch/arm/boot/dts/tegra20-whistler.dts
@@ -539,6 +539,7 @@
 		nvidia,repeat-delay-ms = <160>;
 		nvidia,kbc-row-pins = <0 1 2>;
 		nvidia,kbc-col-pins = <16 17>;
+		nvidia,wakeup-source;
 		linux,keymap = <0x00000074	/* KEY_POWER */
 				0x01000066	/* KEY_HOME */
 				0x0101009E	/* KEY_BACK */
-- 
1.8.2



From josephl at nvidia.com  Tue Apr  2 07:20:07 2013
From: josephl at nvidia.com (Joseph Lo)
Date: Tue, 2 Apr 2013 19:20:07 +0800
Subject: [PATCH V5 3/9] ARM: dt: tegra: add bindings of power management
 configurations for PMC
In-Reply-To: <1364901613-25080-1-git-send-email-josephl@nvidia.com>
References: <1364901613-25080-1-git-send-email-josephl@nvidia.com>
Message-ID: <1364901613-25080-4-git-send-email-josephl@nvidia.com>

The PMC mostly controls the entry and exit of the system from different
sleep modes. Different platform or system may have different configurations.
The power management configurations of PMC is represented as some properties.
The system needs to define the properties when the system supports deep sleep
mode (i.e. suspend).

Cc: Grant Likely <grant.likely at secretlab.ca>
Cc: Rob Herring <rob.herring at calxeda.com>
Cc: devicetree-discuss at lists.ozlabs.org
Signed-off-by: Joseph Lo <josephl at nvidia.com>
---
V5:
* fix typos
V4:
* no change
V3:
* fix typos
V2:
* squash the patches that defined the PM bindings for PMC and the
  implementation
* replace the "unsigned long" with "u32" for the variables that are parsed
  from DT
---
 .../bindings/arm/tegra/nvidia,tegra20-pmc.txt      | 42 ++++++++++-
 arch/arm/mach-tegra/pmc.c                          | 83 ++++++++++++++++++++++
 arch/arm/mach-tegra/pmc.h                          |  8 +++
 3 files changed, 132 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt
index 1cb8f6b..79b8390 100644
--- a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt
+++ b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt
@@ -1,9 +1,15 @@
 NVIDIA Tegra Power Management Controller (PMC)
 
-Properties:
+The PMC block interacts with an external Power Management Unit. The PMC
+mostly controls the entry and exit of the system from different sleep
+modes. It provides power-gating controllers for SoC and CPU power-islands.
+
+Required properties:
 - name : Should be pmc
 - compatible : Should contain "nvidia,tegra<chip>-pmc".
 - reg : Offset and length of the register set for the device
+
+Optional properties:
 - nvidia,invert-interrupt : If present, inverts the PMU interrupt signal.
   The PMU is an external Power Management Unit, whose interrupt output
   signal is fed into the PMC. This signal is optionally inverted, and then
@@ -11,6 +17,32 @@ Properties:
   handling of this interrupt signal, merely its inversion.
 - clocks : the source clock of PMC
 - clock-names : the name of source clock of PMC
+- nvidia,suspend-mode : The suspend mode that the platform should use.
+  Valid values are 0, 1 and 2:
+  0 (LP0): CPU + Core voltage off and DRAM in self-refresh
+  1 (LP1): CPU voltage off and DRAM in self-refresh
+  2 (LP2): CPU voltage off
+- nvidia,core-power-req-active-high : Boolean, core power request active-high
+- nvidia,sys-clock-req-active-high : Boolean, system clock request active-high
+- nvidia,combined-power-req : Boolean, combined power request for CPU & Core
+- nvidia,cpu-pwr-good-en : Boolean, CPU power good signal (from PMIC to PMC)
+			   is enabled.
+
+Required properties when nvidia,suspend-mode is specified:
+- nvidia,cpu-pwr-good-time : CPU power good time in uS.
+- nvidia,cpu-pwr-off-time : CPU power off time in uS.
+- nvidia,core-pwr-good-time : <Oscillator-stable-time Power-stable-time>
+			      Core power good time in uS.
+- nvidia,core-pwr-off-time : Core power off time in uS.
+
+Required properties when nvidia,suspend-mode=<0>:
+- nvidia,lp0-vec : <start length> Starting address and length of LP0 vector
+  The LP0 vector contains the warm boot code that is executed by AVP when
+  resuming from the LP0 state. The AVP (Audio-Video Processor) is an ARM7
+  processor and always being the first boot processor when chip is power on
+  or resume from deep sleep mode. When the system is resumed from the deep
+  sleep mode, the warm boot code will restore some PLLs, clocks and then
+  bring up CPU0 for resuming the system.
 
 Example:
 
@@ -21,6 +53,14 @@ pmc at 7000f400 {
 	nvidia,invert-interrupt;
 	clocks = <&tegra_car 110>, <&clk32k_in>;
 	clock-names = "pclk", "clk32k_in";
+	nvidia,suspend-mode = <1>;
+	nvidia,cpu-pwr-good-time = <2000>;
+	nvidia,cpu-pwr-off-time = <100>;
+	nvidia,core-pwr-good-time = <3845 3845>;
+	nvidia,core-pwr-off-time = <458>;
+	nvidia,core-power-req-active-high;
+	nvidia,sys-clock-req-active-high;
+	nvidia,lp0-vec = <0xbdffd000 0x2000>;
 };
 
 / Tegra board dts file
diff --git a/arch/arm/mach-tegra/pmc.c b/arch/arm/mach-tegra/pmc.c
index 8abf02f..5323bca 100644
--- a/arch/arm/mach-tegra/pmc.c
+++ b/arch/arm/mach-tegra/pmc.c
@@ -21,6 +21,8 @@
 #include <linux/of_address.h>
 #include <linux/clk.h>
 
+#include "pmc.h"
+
 #define PMC_CTRL			0x0
 #define PMC_CTRL_INTR_LOW		(1 << 17)
 #define PMC_PWRGATE_TOGGLE		0x30
@@ -49,6 +51,22 @@ static void __iomem *tegra_pmc_base;
 static bool tegra_pmc_invert_interrupt;
 static struct clk *tegra_pclk;
 
+struct pmc_pm_data {
+	u32 cpu_good_time;	/* CPU power good time in uS */
+	u32 cpu_off_time;	/* CPU power off time in uS */
+	u32 core_osc_time;	/* Core power good osc time in uS */
+	u32 core_pmu_time;	/* Core power good pmu time in uS */
+	u32 core_off_time;	/* Core power off time in uS */
+	bool corereq_high;	/* Core power request active-high */
+	bool sysclkreq_high;	/* System clock request active-high */
+	bool combined_req;	/* Combined pwr req for CPU & Core */
+	bool cpu_pwr_good_en;	/* CPU power good signal is enabled */
+	u32 lp0_vec_phy_addr;	/* The phy addr of LP0 warm boot code */
+	u32 lp0_vec_size;	/* The size of LP0 warm boot code */
+	enum tegra_suspend_mode suspend_mode;
+};
+static struct pmc_pm_data pmc_pm_data;
+
 static inline u32 tegra_pmc_readl(u32 reg)
 {
 	return readl(tegra_pmc_base + reg);
@@ -177,6 +195,10 @@ static const struct of_device_id matches[] __initconst = {
 static void tegra_pmc_parse_dt(void)
 {
 	struct device_node *np;
+	u32 prop;
+	enum tegra_suspend_mode suspend_mode;
+	u32 core_good_time[2] = {0, 0};
+	u32 lp0_vec[2] = {0, 0};
 
 	np = of_find_matching_node(NULL, matches);
 	BUG_ON(!np);
@@ -187,6 +209,67 @@ static void tegra_pmc_parse_dt(void)
 				     "nvidia,invert-interrupt");
 	tegra_pclk = of_clk_get_by_name(np, "pclk");
 	WARN_ON(IS_ERR(tegra_pclk));
+
+	/* Grabbing the power management configurations */
+	if (of_property_read_u32(np, "nvidia,suspend-mode", &prop)) {
+		suspend_mode = TEGRA_SUSPEND_NONE;
+	} else {
+		switch (prop) {
+		case 0:
+			suspend_mode = TEGRA_SUSPEND_LP0;
+			break;
+		case 1:
+			suspend_mode = TEGRA_SUSPEND_LP1;
+			break;
+		case 2:
+			suspend_mode = TEGRA_SUSPEND_LP2;
+			break;
+		default:
+			suspend_mode = TEGRA_SUSPEND_NONE;
+			break;
+		}
+	}
+
+	if (of_property_read_u32(np, "nvidia,cpu-pwr-good-time", &prop))
+		suspend_mode = TEGRA_SUSPEND_NONE;
+	pmc_pm_data.cpu_good_time = prop;
+
+	if (of_property_read_u32(np, "nvidia,cpu-pwr-off-time", &prop))
+		suspend_mode = TEGRA_SUSPEND_NONE;
+	pmc_pm_data.cpu_off_time = prop;
+
+	if (of_property_read_u32_array(np, "nvidia,core-pwr-good-time",
+			core_good_time, ARRAY_SIZE(core_good_time)))
+		suspend_mode = TEGRA_SUSPEND_NONE;
+	pmc_pm_data.core_osc_time = core_good_time[0];
+	pmc_pm_data.core_pmu_time = core_good_time[1];
+
+	if (of_property_read_u32(np, "nvidia,core-pwr-off-time",
+				 &prop))
+		suspend_mode = TEGRA_SUSPEND_NONE;
+	pmc_pm_data.core_off_time = prop;
+
+	pmc_pm_data.corereq_high = of_property_read_bool(np,
+				"nvidia,core-power-req-active-high");
+
+	pmc_pm_data.sysclkreq_high = of_property_read_bool(np,
+				"nvidia,sys-clock-req-active-high");
+
+	pmc_pm_data.combined_req = of_property_read_bool(np,
+				"nvidia,combined-power-req");
+
+	pmc_pm_data.cpu_pwr_good_en = of_property_read_bool(np,
+				"nvidia,cpu-pwr-good-en");
+
+	if (of_property_read_u32_array(np, "nvidia,lp0-vec", lp0_vec,
+				       ARRAY_SIZE(lp0_vec)))
+		if (suspend_mode == TEGRA_SUSPEND_LP0)
+			suspend_mode = TEGRA_SUSPEND_LP1;
+
+	pmc_pm_data.lp0_vec_phy_addr = lp0_vec[0];
+	pmc_pm_data.lp0_vec_size = lp0_vec[1];
+
+	pmc_pm_data.suspend_mode = suspend_mode;
 }
 
 void __init tegra_pmc_init(void)
diff --git a/arch/arm/mach-tegra/pmc.h b/arch/arm/mach-tegra/pmc.h
index 22f16c9..6bc0fc09 100644
--- a/arch/arm/mach-tegra/pmc.h
+++ b/arch/arm/mach-tegra/pmc.h
@@ -18,6 +18,14 @@
 #ifndef __MACH_TEGRA_PMC_H
 #define __MACH_TEGRA_PMC_H
 
+enum tegra_suspend_mode {
+	TEGRA_SUSPEND_NONE = 0,
+	TEGRA_SUSPEND_LP2,	/* CPU voltage off */
+	TEGRA_SUSPEND_LP1,	/* CPU voltage off, DRAM self-refresh */
+	TEGRA_SUSPEND_LP0,      /* CPU + core voltage off, DRAM self-refresh */
+	TEGRA_MAX_SUSPEND_MODE,
+};
+
 #ifdef CONFIG_PM_SLEEP
 void set_power_timers(unsigned long us_on, unsigned long us_off);
 #endif
-- 
1.8.2



From josephl at nvidia.com  Tue Apr  2 07:20:12 2013
From: josephl at nvidia.com (Joseph Lo)
Date: Tue, 2 Apr 2013 19:20:12 +0800
Subject: [PATCH V5 8/9] ARM: tegra: config: defconfig update
In-Reply-To: <1364901613-25080-1-git-send-email-josephl@nvidia.com>
References: <1364901613-25080-1-git-send-email-josephl@nvidia.com>
Message-ID: <1364901613-25080-9-git-send-email-josephl@nvidia.com>

KEYBOARD_GPIO:
* Enable gpio-key driver

Signed-off-by: Joseph Lo <josephl at nvidia.com>
---
V5:
* no change
V4:
* no change
V3:
* no change
V2:
* no change
---
 arch/arm/configs/tegra_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/tegra_defconfig b/arch/arm/configs/tegra_defconfig
index 2b42a2c..a5f0485 100644
--- a/arch/arm/configs/tegra_defconfig
+++ b/arch/arm/configs/tegra_defconfig
@@ -106,6 +106,7 @@ CONFIG_RT2X00=y
 CONFIG_RT2800USB=m
 CONFIG_INPUT_EVDEV=y
 CONFIG_KEYBOARD_TEGRA=y
+CONFIG_KEYBOARD_GPIO=y
 CONFIG_INPUT_MISC=y
 CONFIG_INPUT_MPU3050=y
 # CONFIG_LEGACY_PTYS is not set
-- 
1.8.2



From josephl at nvidia.com  Tue Apr  2 07:20:11 2013
From: josephl at nvidia.com (Joseph Lo)
Date: Tue, 2 Apr 2013 19:20:11 +0800
Subject: [PATCH V5 7/9] ARM: dts: tegra: add non-removable and
 keep-power-in-suspend property for MMC
In-Reply-To: <1364901613-25080-1-git-send-email-josephl@nvidia.com>
References: <1364901613-25080-1-git-send-email-josephl@nvidia.com>
Message-ID: <1364901613-25080-8-git-send-email-josephl@nvidia.com>

This patch adds "non-removable" property of MMC host where the eMMC device
is for Tegra platform.

And the "keep-power-in-suspend" property was used for the SDIO device that
need this to go into suspend mode (e.g. BRCM43xx series).

Signed-off-by: Joseph Lo <josephl at nvidia.com>
---
V5:
* no change
V4:
* no change
V3:
* no change
V2:
* no change
---
 arch/arm/boot/dts/tegra20-paz00.dts      | 1 +
 arch/arm/boot/dts/tegra20-seaboard.dts   | 2 ++
 arch/arm/boot/dts/tegra20-ventana.dts    | 2 ++
 arch/arm/boot/dts/tegra20-whistler.dts   | 1 +
 arch/arm/boot/dts/tegra30-beaver.dts     | 1 +
 arch/arm/boot/dts/tegra30-cardhu-a02.dts | 1 +
 arch/arm/boot/dts/tegra30-cardhu-a04.dts | 1 +
 arch/arm/boot/dts/tegra30-cardhu.dtsi    | 1 +
 8 files changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/tegra20-paz00.dts b/arch/arm/boot/dts/tegra20-paz00.dts
index 54b05b2..c55e062 100644
--- a/arch/arm/boot/dts/tegra20-paz00.dts
+++ b/arch/arm/boot/dts/tegra20-paz00.dts
@@ -458,6 +458,7 @@
 	sdhci at c8000600 {
 		status = "okay";
 		bus-width = <8>;
+		non-removable;
 	};
 
 	gpio-keys {
diff --git a/arch/arm/boot/dts/tegra20-seaboard.dts b/arch/arm/boot/dts/tegra20-seaboard.dts
index 3b347b8..5572ee7 100644
--- a/arch/arm/boot/dts/tegra20-seaboard.dts
+++ b/arch/arm/boot/dts/tegra20-seaboard.dts
@@ -593,6 +593,7 @@
 		status = "okay";
 		power-gpios = <&gpio 86 0>; /* gpio PK6 */
 		bus-width = <4>;
+		keep-power-in-suspend;
 	};
 
 	sdhci at c8000400 {
@@ -606,6 +607,7 @@
 	sdhci at c8000600 {
 		status = "okay";
 		bus-width = <8>;
+		non-removable;
 	};
 
 	gpio-keys {
diff --git a/arch/arm/boot/dts/tegra20-ventana.dts b/arch/arm/boot/dts/tegra20-ventana.dts
index 112ef5c..4363764 100644
--- a/arch/arm/boot/dts/tegra20-ventana.dts
+++ b/arch/arm/boot/dts/tegra20-ventana.dts
@@ -529,6 +529,7 @@
 		status = "okay";
 		power-gpios = <&gpio 86 0>; /* gpio PK6 */
 		bus-width = <4>;
+		keep-power-in-suspend;
 	};
 
 	sdhci at c8000400 {
@@ -542,6 +543,7 @@
 	sdhci at c8000600 {
 		status = "okay";
 		bus-width = <8>;
+		non-removable;
 	};
 
 	gpio-keys {
diff --git a/arch/arm/boot/dts/tegra20-whistler.dts b/arch/arm/boot/dts/tegra20-whistler.dts
index 0b04262..878790e 100644
--- a/arch/arm/boot/dts/tegra20-whistler.dts
+++ b/arch/arm/boot/dts/tegra20-whistler.dts
@@ -531,6 +531,7 @@
 	sdhci at c8000600 {
 		status = "okay";
 		bus-width = <8>;
+		non-removable;
 	};
 
 	kbc {
diff --git a/arch/arm/boot/dts/tegra30-beaver.dts b/arch/arm/boot/dts/tegra30-beaver.dts
index c3e0f25..772e6cf 100644
--- a/arch/arm/boot/dts/tegra30-beaver.dts
+++ b/arch/arm/boot/dts/tegra30-beaver.dts
@@ -279,6 +279,7 @@
 	sdhci at 78000600 {
 		status = "okay";
 		bus-width = <8>;
+		non-removable;
 	};
 
 	regulators {
diff --git a/arch/arm/boot/dts/tegra30-cardhu-a02.dts b/arch/arm/boot/dts/tegra30-cardhu-a02.dts
index adc88aa..e392bd2 100644
--- a/arch/arm/boot/dts/tegra30-cardhu-a02.dts
+++ b/arch/arm/boot/dts/tegra30-cardhu-a02.dts
@@ -88,6 +88,7 @@
 		status = "okay";
 		power-gpios = <&gpio 28 0>; /* gpio PD4 */
 		bus-width = <4>;
+		keep-power-in-suspend;
 	};
 };
 
diff --git a/arch/arm/boot/dts/tegra30-cardhu-a04.dts b/arch/arm/boot/dts/tegra30-cardhu-a04.dts
index 08163e1..d0db6c7 100644
--- a/arch/arm/boot/dts/tegra30-cardhu-a04.dts
+++ b/arch/arm/boot/dts/tegra30-cardhu-a04.dts
@@ -100,5 +100,6 @@
 		status = "okay";
 		power-gpios = <&gpio 27 0>; /* gpio PD3 */
 		bus-width = <4>;
+		keep-power-in-suspend;
 	};
 };
diff --git a/arch/arm/boot/dts/tegra30-cardhu.dtsi b/arch/arm/boot/dts/tegra30-cardhu.dtsi
index eeea511..053913f 100644
--- a/arch/arm/boot/dts/tegra30-cardhu.dtsi
+++ b/arch/arm/boot/dts/tegra30-cardhu.dtsi
@@ -333,6 +333,7 @@
 	sdhci at 78000600 {
 		status = "okay";
 		bus-width = <8>;
+		non-removable;
 	};
 
 	regulators {
-- 
1.8.2



From josephl at nvidia.com  Tue Apr  2 07:20:13 2013
From: josephl at nvidia.com (Joseph Lo)
Date: Tue, 2 Apr 2013 19:20:13 +0800
Subject: [PATCH V5 9/9] ARM: dts: tegra: add the PM configurations of PMC
In-Reply-To: <1364901613-25080-1-git-send-email-josephl@nvidia.com>
References: <1364901613-25080-1-git-send-email-josephl@nvidia.com>
Message-ID: <1364901613-25080-10-git-send-email-josephl@nvidia.com>

Adding the PM configuration of PMC when the platform support suspend
function.

Signed-off-by: Joseph Lo <josephl at nvidia.com>
---
V5:
* no change
V4:
* no change
V3:
* fix the configuration for paz00 board
V2:
* no change
---
 arch/arm/boot/dts/tegra20-harmony.dts   | 6 ++++++
 arch/arm/boot/dts/tegra20-paz00.dts     | 6 ++++++
 arch/arm/boot/dts/tegra20-seaboard.dts  | 6 ++++++
 arch/arm/boot/dts/tegra20-trimslice.dts | 9 +++++++++
 arch/arm/boot/dts/tegra20-ventana.dts   | 6 ++++++
 arch/arm/boot/dts/tegra20-whistler.dts  | 8 ++++++++
 arch/arm/boot/dts/tegra30-beaver.dts    | 7 +++++++
 arch/arm/boot/dts/tegra30-cardhu.dtsi   | 7 +++++++
 8 files changed, 55 insertions(+)

diff --git a/arch/arm/boot/dts/tegra20-harmony.dts b/arch/arm/boot/dts/tegra20-harmony.dts
index 4f08521..7904eb4 100644
--- a/arch/arm/boot/dts/tegra20-harmony.dts
+++ b/arch/arm/boot/dts/tegra20-harmony.dts
@@ -429,6 +429,12 @@
 
 	pmc {
 		nvidia,invert-interrupt;
+		nvidia,suspend-mode = <2>;
+		nvidia,cpu-pwr-good-time = <5000>;
+		nvidia,cpu-pwr-off-time = <5000>;
+		nvidia,core-pwr-good-time = <3845 3845>;
+		nvidia,core-pwr-off-time = <3875>;
+		nvidia,sys-clock-req-active-high;
 	};
 
 	usb at c5000000 {
diff --git a/arch/arm/boot/dts/tegra20-paz00.dts b/arch/arm/boot/dts/tegra20-paz00.dts
index c55e062..680eeeb 100644
--- a/arch/arm/boot/dts/tegra20-paz00.dts
+++ b/arch/arm/boot/dts/tegra20-paz00.dts
@@ -428,6 +428,12 @@
 
 	pmc {
 		nvidia,invert-interrupt;
+		nvidia,suspend-mode = <2>;
+		nvidia,cpu-pwr-good-time = <2000>;
+		nvidia,cpu-pwr-off-time = <0>;
+		nvidia,core-pwr-good-time = <3845 3845>;
+		nvidia,core-pwr-off-time = <0>;
+		nvidia,sys-clock-req-active-high;
 	};
 
 	usb at c5000000 {
diff --git a/arch/arm/boot/dts/tegra20-seaboard.dts b/arch/arm/boot/dts/tegra20-seaboard.dts
index 5572ee7..2ff92c9 100644
--- a/arch/arm/boot/dts/tegra20-seaboard.dts
+++ b/arch/arm/boot/dts/tegra20-seaboard.dts
@@ -530,6 +530,12 @@
 
 	pmc {
 		nvidia,invert-interrupt;
+		nvidia,suspend-mode = <2>;
+		nvidia,cpu-pwr-good-time = <5000>;
+		nvidia,cpu-pwr-off-time = <5000>;
+		nvidia,core-pwr-good-time = <3845 3845>;
+		nvidia,core-pwr-off-time = <3875>;
+		nvidia,sys-clock-req-active-high;
 	};
 
 	memory-controller at 7000f400 {
diff --git a/arch/arm/boot/dts/tegra20-trimslice.dts b/arch/arm/boot/dts/tegra20-trimslice.dts
index 8e8d4f6..7760b67 100644
--- a/arch/arm/boot/dts/tegra20-trimslice.dts
+++ b/arch/arm/boot/dts/tegra20-trimslice.dts
@@ -313,6 +313,15 @@
 		};
 	};
 
+	pmc {
+		nvidia,suspend-mode = <2>;
+		nvidia,cpu-pwr-good-time = <5000>;
+		nvidia,cpu-pwr-off-time = <5000>;
+		nvidia,core-pwr-good-time = <3845 3845>;
+		nvidia,core-pwr-off-time = <3875>;
+		nvidia,sys-clock-req-active-high;
+	};
+
 	usb at c5000000 {
 		status = "okay";
 		nvidia,vbus-gpio = <&gpio 170 0>; /* gpio PV2 */
diff --git a/arch/arm/boot/dts/tegra20-ventana.dts b/arch/arm/boot/dts/tegra20-ventana.dts
index 4363764..98a1eae 100644
--- a/arch/arm/boot/dts/tegra20-ventana.dts
+++ b/arch/arm/boot/dts/tegra20-ventana.dts
@@ -506,6 +506,12 @@
 
 	pmc {
 		nvidia,invert-interrupt;
+		nvidia,suspend-mode = <2>;
+		nvidia,cpu-pwr-good-time = <2000>;
+		nvidia,cpu-pwr-off-time = <100>;
+		nvidia,core-pwr-good-time = <3845 3845>;
+		nvidia,core-pwr-off-time = <458>;
+		nvidia,sys-clock-req-active-high;
 	};
 
 	usb at c5000000 {
diff --git a/arch/arm/boot/dts/tegra20-whistler.dts b/arch/arm/boot/dts/tegra20-whistler.dts
index 878790e..ff74be7 100644
--- a/arch/arm/boot/dts/tegra20-whistler.dts
+++ b/arch/arm/boot/dts/tegra20-whistler.dts
@@ -509,6 +509,14 @@
 
 	pmc {
 		nvidia,invert-interrupt;
+		nvidia,suspend-mode = <2>;
+		nvidia,cpu-pwr-good-time = <2000>;
+		nvidia,cpu-pwr-off-time = <1000>;
+		nvidia,core-pwr-good-time = <0 3845>;
+		nvidia,core-pwr-off-time = <93727>;
+		nvidia,core-power-req-active-high;
+		nvidia,sys-clock-req-active-high;
+		nvidia,combined-power-req;
 	};
 
 	usb at c5000000 {
diff --git a/arch/arm/boot/dts/tegra30-beaver.dts b/arch/arm/boot/dts/tegra30-beaver.dts
index 772e6cf..f17deb0 100644
--- a/arch/arm/boot/dts/tegra30-beaver.dts
+++ b/arch/arm/boot/dts/tegra30-beaver.dts
@@ -266,6 +266,13 @@
 	pmc {
 		status = "okay";
 		nvidia,invert-interrupt;
+		nvidia,suspend-mode = <2>;
+		nvidia,cpu-pwr-good-time = <2000>;
+		nvidia,cpu-pwr-off-time = <200>;
+		nvidia,core-pwr-good-time = <3845 3845>;
+		nvidia,core-pwr-off-time = <0>;
+		nvidia,core-power-req-active-high;
+		nvidia,sys-clock-req-active-high;
 	};
 
 	sdhci at 78000000 {
diff --git a/arch/arm/boot/dts/tegra30-cardhu.dtsi b/arch/arm/boot/dts/tegra30-cardhu.dtsi
index 053913f..9171834 100644
--- a/arch/arm/boot/dts/tegra30-cardhu.dtsi
+++ b/arch/arm/boot/dts/tegra30-cardhu.dtsi
@@ -320,6 +320,13 @@
 	pmc {
 		status = "okay";
 		nvidia,invert-interrupt;
+		nvidia,suspend-mode = <2>;
+		nvidia,cpu-pwr-good-time = <2000>;
+		nvidia,cpu-pwr-off-time = <200>;
+		nvidia,core-pwr-good-time = <3845 3845>;
+		nvidia,core-pwr-off-time = <0>;
+		nvidia,core-power-req-active-high;
+		nvidia,sys-clock-req-active-high;
 	};
 
 	sdhci at 78000000 {
-- 
1.8.2



From josephl at nvidia.com  Tue Apr  2 07:20:50 2013
From: josephl at nvidia.com (Joseph Lo)
Date: Tue, 2 Apr 2013 19:20:50 +0800
Subject: [PATCH V3] ARM: tegra: cpuidle: remove redundant parameters for
 powered-down mode
Message-ID: <1364901650-25335-1-git-send-email-josephl@nvidia.com>

After the patch series for system suspending support, tegra_idle_lp2_last()
no longer uses its parameters cpu_on_time or cpu_off_time, so remove them.

Signed-off-by: Joseph Lo <josephl at nvidia.com>
---
V3:
* no change
V2:
* rebased on the top of "ARM: tegra: add clock source for PMC" and "ARM:
  tegra: add platform suspend support"
* no physical change from V1
---
 arch/arm/mach-tegra/cpuidle-tegra20.c | 6 +-----
 arch/arm/mach-tegra/cpuidle-tegra30.c | 6 +-----
 arch/arm/mach-tegra/pm.c              | 2 +-
 arch/arm/mach-tegra/pm.h              | 2 +-
 4 files changed, 4 insertions(+), 12 deletions(-)

diff --git a/arch/arm/mach-tegra/cpuidle-tegra20.c b/arch/arm/mach-tegra/cpuidle-tegra20.c
index 825ced4..8bbbdeb 100644
--- a/arch/arm/mach-tegra/cpuidle-tegra20.c
+++ b/arch/arm/mach-tegra/cpuidle-tegra20.c
@@ -130,10 +130,6 @@ static bool tegra20_cpu_cluster_power_down(struct cpuidle_device *dev,
 					   struct cpuidle_driver *drv,
 					   int index)
 {
-	struct cpuidle_state *state = &drv->states[index];
-	u32 cpu_on_time = state->exit_latency;
-	u32 cpu_off_time = state->target_residency - state->exit_latency;
-
 	while (tegra20_cpu_is_resettable_soon())
 		cpu_relax();
 
@@ -142,7 +138,7 @@ static bool tegra20_cpu_cluster_power_down(struct cpuidle_device *dev,
 
 	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &dev->cpu);
 
-	tegra_idle_lp2_last(cpu_on_time, cpu_off_time);
+	tegra_idle_lp2_last();
 
 	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &dev->cpu);
 
diff --git a/arch/arm/mach-tegra/cpuidle-tegra30.c b/arch/arm/mach-tegra/cpuidle-tegra30.c
index 80445ed..c0931c8 100644
--- a/arch/arm/mach-tegra/cpuidle-tegra30.c
+++ b/arch/arm/mach-tegra/cpuidle-tegra30.c
@@ -72,10 +72,6 @@ static bool tegra30_cpu_cluster_power_down(struct cpuidle_device *dev,
 					   struct cpuidle_driver *drv,
 					   int index)
 {
-	struct cpuidle_state *state = &drv->states[index];
-	u32 cpu_on_time = state->exit_latency;
-	u32 cpu_off_time = state->target_residency - state->exit_latency;
-
 	/* All CPUs entering LP2 is not working.
 	 * Don't let CPU0 enter LP2 when any secondary CPU is online.
 	 */
@@ -86,7 +82,7 @@ static bool tegra30_cpu_cluster_power_down(struct cpuidle_device *dev,
 
 	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &dev->cpu);
 
-	tegra_idle_lp2_last(cpu_on_time, cpu_off_time);
+	tegra_idle_lp2_last();
 
 	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &dev->cpu);
 
diff --git a/arch/arm/mach-tegra/pm.c b/arch/arm/mach-tegra/pm.c
index 14957ff..6ce6beb 100644
--- a/arch/arm/mach-tegra/pm.c
+++ b/arch/arm/mach-tegra/pm.c
@@ -135,7 +135,7 @@ static int tegra_sleep_cpu(unsigned long v2p)
 	return 0;
 }
 
-void tegra_idle_lp2_last(u32 cpu_on_time, u32 cpu_off_time)
+void tegra_idle_lp2_last(void)
 {
 	tegra_pmc_pm_set(TEGRA_SUSPEND_LP2);
 
diff --git a/arch/arm/mach-tegra/pm.h b/arch/arm/mach-tegra/pm.h
index 73a45f1..9d2d038 100644
--- a/arch/arm/mach-tegra/pm.h
+++ b/arch/arm/mach-tegra/pm.h
@@ -31,7 +31,7 @@ void restore_cpu_arch_register(void);
 void tegra_clear_cpu_in_lp2(int phy_cpu_id);
 bool tegra_set_cpu_in_lp2(int phy_cpu_id);
 
-void tegra_idle_lp2_last(u32 cpu_on_time, u32 cpu_off_time);
+void tegra_idle_lp2_last(void);
 extern void (*tegra_tear_down_cpu)(void);
 
 #ifdef CONFIG_PM_SLEEP
-- 
1.8.2



From padma.v at samsung.com  Tue Apr  2 07:23:01 2013
From: padma.v at samsung.com (Padmavathi Venna)
Date: Tue, 02 Apr 2013 16:53:01 +0530
Subject: [PATCH 1/2] ASoC: Samsung: return error if drvdata is not set
Message-ID: <1364901782-16619-1-git-send-email-padma.v@samsung.com>

From: Prathyush K <prathyush.k at samsung.com>

This patch fixes a possible crash in case drvdata for the secondary
device is not set.

Signed-off-by: Prathyush K <prathyush.k at samsung.com>
Signed-off-by: Padmavathi Venna <padma.v at samsung.com>
---

Based on Kukjin for-next branch

 sound/soc/samsung/i2s.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/sound/soc/samsung/i2s.c b/sound/soc/samsung/i2s.c
index d7231e3..f1fc064 100644
--- a/sound/soc/samsung/i2s.c
+++ b/sound/soc/samsung/i2s.c
@@ -1107,6 +1107,10 @@ static int samsung_i2s_probe(struct platform_device *pdev)
 
 	if (samsung_dai_type == TYPE_SEC) {
 		sec_dai = dev_get_drvdata(&pdev->dev);
+		if (!sec_dai) {
+			dev_err(&pdev->dev, "Unable to get drvdata\n");
+			return -EFAULT;
+		}
 		snd_soc_register_dai(&sec_dai->pdev->dev,
 			&sec_dai->i2s_dai_drv);
 		asoc_dma_platform_register(&pdev->dev);
-- 
1.7.4.4



From padma.v at samsung.com  Tue Apr  2 07:23:02 2013
From: padma.v at samsung.com (Padmavathi Venna)
Date: Tue, 02 Apr 2013 16:53:02 +0530
Subject: [PATCH 2/2] ASoC: Samsung: set drvdata before adding secondary device
In-Reply-To: <1364901782-16619-1-git-send-email-padma.v@samsung.com>
References: <1364901782-16619-1-git-send-email-padma.v@samsung.com>
Message-ID: <1364901782-16619-2-git-send-email-padma.v@samsung.com>

From: Prathyush K <prathyush.k at samsung.com>

Currently, a new platform device is created for secondary device
by calling platform_device_register_resndata and then the drvdata
is set for this device.

The following patch has been added to driver core:
"driver core: fix possible missing of device probe".

This results in the added device getting probed immediately but
the drvdata for the secondary device is not yet set.
This patch removes the platform_device_register_resndata call and
instead calls platform_device_alloc, platform_set_drvdata and
platform_device_add which fixes the above issue.

Signed-off-by: Prathyush K <prathyush.k at samsung.com>
Signed-off-by: Padmavathi Venna <padma.v at samsung.com>
---

Based on Kukjin for-next branch

 sound/soc/samsung/i2s.c |   13 ++++++++-----
 1 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/sound/soc/samsung/i2s.c b/sound/soc/samsung/i2s.c
index f1fc064..6bbeb0b 100644
--- a/sound/soc/samsung/i2s.c
+++ b/sound/soc/samsung/i2s.c
@@ -972,6 +972,7 @@ static const struct snd_soc_dai_ops samsung_i2s_dai_ops = {
 static struct i2s_dai *i2s_alloc_dai(struct platform_device *pdev, bool sec)
 {
 	struct i2s_dai *i2s;
+	int ret;
 
 	i2s = devm_kzalloc(&pdev->dev, sizeof(struct i2s_dai), GFP_KERNEL);
 	if (i2s == NULL)
@@ -996,15 +997,17 @@ static struct i2s_dai *i2s_alloc_dai(struct platform_device *pdev, bool sec)
 		i2s->i2s_dai_drv.capture.channels_max = 2;
 		i2s->i2s_dai_drv.capture.rates = SAMSUNG_I2S_RATES;
 		i2s->i2s_dai_drv.capture.formats = SAMSUNG_I2S_FMTS;
+		dev_set_drvdata(&i2s->pdev->dev, i2s);
 	} else {	/* Create a new platform_device for Secondary */
-		i2s->pdev = platform_device_register_resndata(NULL,
-				"samsung-i2s-sec", -1, NULL, 0, NULL, 0);
+		i2s->pdev = platform_device_alloc("samsung-i2s-sec", -1);
 		if (IS_ERR(i2s->pdev))
 			return NULL;
-	}
 
-	/* Pre-assign snd_soc_dai_set_drvdata */
-	dev_set_drvdata(&i2s->pdev->dev, i2s);
+		platform_set_drvdata(i2s->pdev, i2s);
+		ret = platform_device_add(i2s->pdev);
+		if (ret < 0)
+			return NULL;
+	}
 
 	return i2s;
 }
-- 
1.7.4.4



From shawn.guo at linaro.org  Tue Apr  2 07:28:52 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 2 Apr 2013 19:28:52 +0800
Subject: [PATCH] ARM: mxs: Slow down the I2C clock speed
In-Reply-To: <1364858969-17745-1-git-send-email-marex@denx.de>
References: <1364858969-17745-1-git-send-email-marex@denx.de>
Message-ID: <20130402112850.GD24039@S2101-09.ap.freescale.net>

Marek,

On Tue, Apr 02, 2013 at 01:29:29AM +0200, Marek Vasut wrote:
> Slow down the I2C clock speed on M28 and SPS1 as it turns out the
> I2C block in i.MX28 can not operate stable enough with the bus
> running at 400kHz. Note that the driver used by Freescale runs
> the bus at 250kHz when 400kHz speed is selected, but the mainline
> Linux kernel runs the bus at actual 400kHz and that's where it is
> occasionally unstable. Play safe and run the bus at 100kHz.
> 
> Signed-off-by: Marek Vasut <marex at denx.de>

You consider it a fix for 3.9 or just material for 3.10?

Shawn



From padma.v at samsung.com  Tue Apr  2 07:30:39 2013
From: padma.v at samsung.com (Padmavathi Venna)
Date: Tue, 02 Apr 2013 17:00:39 +0530
Subject: [PATCH RESEND] ARM: SAMSUNG: dma: Remove unnecessary code
Message-ID: <1364902239-16704-1-git-send-email-padma.v@samsung.com>

This patch removes the usage of DMACH_DT_PROP and dt_dmach_prop
from dma code as the new generic dma dt binding support has been
added.

Signed-off-by: Padmavathi Venna <padma.v at samsung.com>
Acked-by: Arnd Bergmann <arnd at arndb.de>
---
 arch/arm/mach-s3c24xx/include/mach/dma.h       |    1 -
 arch/arm/mach-s3c64xx/include/mach/dma.h       |    1 -
 arch/arm/plat-samsung/dma-ops.c                |   10 +---------
 arch/arm/plat-samsung/include/plat/dma-ops.h   |    1 -
 arch/arm/plat-samsung/include/plat/dma-pl330.h |    1 -
 5 files changed, 1 insertions(+), 13 deletions(-)

diff --git a/arch/arm/mach-s3c24xx/include/mach/dma.h b/arch/arm/mach-s3c24xx/include/mach/dma.h
index 6b72d5a..b55da1d 100644
--- a/arch/arm/mach-s3c24xx/include/mach/dma.h
+++ b/arch/arm/mach-s3c24xx/include/mach/dma.h
@@ -24,7 +24,6 @@
 */
 
 enum dma_ch {
-	DMACH_DT_PROP = -1,	/* not yet supported, do not use */
 	DMACH_XD0 = 0,
 	DMACH_XD1,
 	DMACH_SDI,
diff --git a/arch/arm/mach-s3c64xx/include/mach/dma.h b/arch/arm/mach-s3c64xx/include/mach/dma.h
index 57b1ff4..fe1a98c 100644
--- a/arch/arm/mach-s3c64xx/include/mach/dma.h
+++ b/arch/arm/mach-s3c64xx/include/mach/dma.h
@@ -21,7 +21,6 @@
  */
 enum dma_ch {
 	/* DMA0/SDMA0 */
-	DMACH_DT_PROP = -1, /* not yet supported, do not use */
 	DMACH_UART0 = 0,
 	DMACH_UART0_SRC2,
 	DMACH_UART1,
diff --git a/arch/arm/plat-samsung/dma-ops.c b/arch/arm/plat-samsung/dma-ops.c
index 71d58dd..ec0d731 100644
--- a/arch/arm/plat-samsung/dma-ops.c
+++ b/arch/arm/plat-samsung/dma-ops.c
@@ -23,23 +23,15 @@ static unsigned samsung_dmadev_request(enum dma_ch dma_ch,
 				struct device *dev, char *ch_name)
 {
 	dma_cap_mask_t mask;
-	void *filter_param;
 
 	dma_cap_zero(mask);
 	dma_cap_set(param->cap, mask);
 
-	/*
-	 * If a dma channel property of a device node from device tree is
-	 * specified, use that as the fliter parameter.
-	 */
-	filter_param = (dma_ch == DMACH_DT_PROP) ?
-		(void *)param->dt_dmach_prop : (void *)dma_ch;
-
 	if (dev->of_node)
 		return (unsigned)dma_request_slave_channel(dev, ch_name);
 	else
 		return (unsigned)dma_request_channel(mask, pl330_filter,
-							filter_param);
+							(void *)dma_ch);
 }
 
 static int samsung_dmadev_release(unsigned ch, void *param)
diff --git a/arch/arm/plat-samsung/include/plat/dma-ops.h b/arch/arm/plat-samsung/include/plat/dma-ops.h
index 1141782..ce6d763 100644
--- a/arch/arm/plat-samsung/include/plat/dma-ops.h
+++ b/arch/arm/plat-samsung/include/plat/dma-ops.h
@@ -18,7 +18,6 @@
 
 struct samsung_dma_req {
 	enum dma_transaction_type cap;
-	struct property *dt_dmach_prop;
 	struct s3c2410_dma_client *client;
 };
 
diff --git a/arch/arm/plat-samsung/include/plat/dma-pl330.h b/arch/arm/plat-samsung/include/plat/dma-pl330.h
index d384a80..abe07fa 100644
--- a/arch/arm/plat-samsung/include/plat/dma-pl330.h
+++ b/arch/arm/plat-samsung/include/plat/dma-pl330.h
@@ -21,7 +21,6 @@
  * use these just as IDs.
  */
 enum dma_ch {
-	DMACH_DT_PROP = -1,
 	DMACH_UART0_RX = 0,
 	DMACH_UART0_TX,
 	DMACH_UART1_RX,
-- 
1.7.4.4



From linus.walleij at linaro.org  Tue Apr  2 07:36:26 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Tue, 2 Apr 2013 13:36:26 +0200
Subject: [PATCHv7 00/17] PCIe support for the Armada 370 and Armada XP SoCs
In-Reply-To: <1364395234-11195-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1364395234-11195-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <CACRpkdb77h+7FCjEbc3Jy9+3M5KdCEk3ktsuTHOT1W6AKToJZw@mail.gmail.com>

On Wed, Mar 27, 2013 at 3:40 PM, Thomas Petazzoni
<thomas.petazzoni at free-electrons.com> wrote:

> As we are approaching 3.10, I would now like to get formal Acked-by,
> or disagreements from the following maintainers/developers :
>
>  * Grant Likely, as the OF maintainer, for patches 1, 2 and 3
>
>    [PATCH v5 01/17] of/pci: Provide support for parsing PCI DT ranges
>    [PATCH v5 02/17] of/pci: Add of_pci_get_devfn() function
>    [PATCH v5 03/17] of/pci: Add of_pci_parse_bus_range() function

I think Rob Herring can help out in reviewing this, as comaintainer
of devicetree stuff.

Yours,
Linus Walleij


From shawn.guo at linaro.org  Tue Apr  2 07:43:25 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 2 Apr 2013 19:43:25 +0800
Subject: [PATCH] pinctrl: imx5: fix SD2_DATA1 pad AUDMUX_AUD4 configuration
In-Reply-To: <1364882642-25574-1-git-send-email-marex@denx.de>
References: <1364882642-25574-1-git-send-email-marex@denx.de>
Message-ID: <20130402114323.GE24039@S2101-09.ap.freescale.net>

Marek,

On Tue, Apr 02, 2013 at 08:04:02AM +0200, Marek Vasut wrote:
> The IOMUXC_AUDMUX_P4_INPUT_TXCLK_AMX_SELECT_INPUT must be configured as 1
> instead of 0 to have AUD4 muxed on SD2 pins working.
> 
> Signed-off-by: Marek Vasut <marex at denx.de>
> Cc: Fabio Estevam <fabio.estevam at freescale.com>
> Cc: Linus Walleij <linus.walleij at linaro.org>
> Cc: Philipp Zabel <p.zabel at pengutronix.de>
> Cc: Shawn Guo <shawn.guo at linaro.org>
> ---
>  drivers/pinctrl/pinctrl-imx53.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> NOTE: Shawn, we might want this in -stable too ?

I have queued patch b466af3 (pinctrl: imx: move hard-coding data into
device tree) on my imx/dt branch to remove these tables from pinctrl
drivers.

Since there is no in-tree users for MX53_PAD_SD2_DATA1__AUDMUX_AUD4_TXFS,
and we're moving away from it, can we just patch
arch/arm/boot/dts/imx53-pinfunc.h instead?

Shawn

> 
> diff --git a/drivers/pinctrl/pinctrl-imx53.c b/drivers/pinctrl/pinctrl-imx53.c
> index 2c9c8e2..85f401c 100644
> --- a/drivers/pinctrl/pinctrl-imx53.c
> +++ b/drivers/pinctrl/pinctrl-imx53.c
> @@ -1287,7 +1287,7 @@ static struct imx_pin_reg imx53_pin_regs[] = {
>  	IMX_PIN_REG(MX53_PAD_SD2_DATA1, 0x698, 0x30C, 0, 0x000, 0), /* MX53_PAD_SD2_DATA1__ESDHC2_DAT1 */
>  	IMX_PIN_REG(MX53_PAD_SD2_DATA1, 0x698, 0x30C, 1, 0x000, 0), /* MX53_PAD_SD2_DATA1__GPIO1_14 */
>  	IMX_PIN_REG(MX53_PAD_SD2_DATA1, 0x698, 0x30C, 2, 0x848, 1), /* MX53_PAD_SD2_DATA1__KPP_COL_7 */
> -	IMX_PIN_REG(MX53_PAD_SD2_DATA1, 0x698, 0x30C, 3, 0x744, 0), /* MX53_PAD_SD2_DATA1__AUDMUX_AUD4_TXFS */
> +	IMX_PIN_REG(MX53_PAD_SD2_DATA1, 0x698, 0x30C, 3, 0x744, 1), /* MX53_PAD_SD2_DATA1__AUDMUX_AUD4_TXFS */
>  	IMX_PIN_REG(MX53_PAD_SD2_DATA1, 0x698, 0x30C, 5, 0x78C, 4), /* MX53_PAD_SD2_DATA1__CSPI_SS0 */
>  	IMX_PIN_REG(MX53_PAD_SD2_DATA1, 0x698, 0x30C, 7, 0x000, 0), /* MX53_PAD_SD2_DATA1__RTIC_SEC_VIO */
>  	IMX_PIN_REG(MX53_PAD_SD2_DATA0, 0x69C, 0x310, 0, 0x000, 0), /* MX53_PAD_SD2_DATA0__ESDHC2_DAT0 */
> -- 
> 1.7.10.4
> 



From prabhakar.csengg at gmail.com  Tue Apr  2 07:44:01 2013
From: prabhakar.csengg at gmail.com (Prabhakar lad)
Date: Tue,  2 Apr 2013 17:14:01 +0530
Subject: [PATCH v2 0/3] davinci: vpss: clock cleanup
Message-ID: <1364903044-13752-1-git-send-email-prabhakar.csengg@gmail.com>

From: Lad, Prabhakar <prabhakar.csengg at gmail.com>

This patch series cleanup's the VPSS clock enabling.
The first patch removes vpss clock enabling from the capture
drivers and moves it to the VPSS driver itself.
The second patch moves the venc_enable_vpss_clock() to the driver
which was being done in platform code.

Changes for v2:
1: Used PM runtime API for clock handling and nit's pointed by Sekhar.

Lad, Prabhakar (3):
  media: davinci: vpss: enable vpss clocks
  media: davinci: vpbe: venc: move the enabling of vpss clocks to
    driver
  davinic: vpss: trivial cleanup

 arch/arm/mach-davinci/dm355.c                |    7 +---
 arch/arm/mach-davinci/dm365.c                |   11 +++++--
 arch/arm/mach-davinci/dm644x.c               |    9 +----
 arch/arm/mach-davinci/pm_domain.c            |    2 +-
 drivers/media/platform/davinci/dm355_ccdc.c  |   39 +----------------------
 drivers/media/platform/davinci/dm644x_ccdc.c |   44 --------------------------
 drivers/media/platform/davinci/isif.c        |   28 ++--------------
 drivers/media/platform/davinci/vpbe_venc.c   |   25 ++++++++++++++
 drivers/media/platform/davinci/vpss.c        |   36 ++++++++++++++++-----
 9 files changed, 71 insertions(+), 130 deletions(-)

-- 
1.7.4.1



From prabhakar.csengg at gmail.com  Tue Apr  2 07:44:02 2013
From: prabhakar.csengg at gmail.com (Prabhakar lad)
Date: Tue,  2 Apr 2013 17:14:02 +0530
Subject: [PATCH v2 1/3] media: davinci: vpss: enable vpss clocks
In-Reply-To: <1364903044-13752-1-git-send-email-prabhakar.csengg@gmail.com>
References: <1364903044-13752-1-git-send-email-prabhakar.csengg@gmail.com>
Message-ID: <1364903044-13752-2-git-send-email-prabhakar.csengg@gmail.com>

From: Lad, Prabhakar <prabhakar.csengg at gmail.com>

By default the VPSS clocks were enabled in capture driver
for davinci family which creates duplicates for dm355/dm365/dm644x.
This patch adds support to enable the VPSS clocks in VPSS driver,
which avoids duplication of code and also adding clock aliases.

This patch uses PM runtime API to enable/disable instead common clock
framework. con_ids for master and slave clocks of vpss is added in pm_domain
for pm runtime to clock handling.

This patch cleanups the VPSS clock enabling in the capture driver,
and also removes the clock alias in machine file. Along side adds
a vpss slave clock for DM365 as mentioned by Sekhar
(https://patchwork.kernel.org/patch/1221261/).

The Suspend/Resume in dm644x_ccdc.c which enabled/disabled the VPSS clock
is now implemented as part of the VPSS driver.

Signed-off-by: Lad, Prabhakar <prabhakar.csengg at gmail.com>
---
 arch/arm/mach-davinci/dm355.c                |    7 +---
 arch/arm/mach-davinci/dm365.c                |   11 +++++--
 arch/arm/mach-davinci/dm644x.c               |    9 +----
 arch/arm/mach-davinci/pm_domain.c            |    2 +-
 drivers/media/platform/davinci/dm355_ccdc.c  |   39 +----------------------
 drivers/media/platform/davinci/dm644x_ccdc.c |   44 --------------------------
 drivers/media/platform/davinci/isif.c        |   28 ++--------------
 drivers/media/platform/davinci/vpss.c        |   25 ++++++++++++++
 8 files changed, 43 insertions(+), 122 deletions(-)

diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index b49c3b7..8e98bb0 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -345,8 +345,8 @@ static struct clk_lookup dm355_clks[] = {
 	CLK(NULL, "pll1_aux", &pll1_aux_clk),
 	CLK(NULL, "pll1_sysclkbp", &pll1_sysclkbp),
 	CLK(NULL, "vpss_dac", &vpss_dac_clk),
-	CLK(NULL, "vpss_master", &vpss_master_clk),
-	CLK(NULL, "vpss_slave", &vpss_slave_clk),
+	CLK("vpss", "master", &vpss_master_clk),
+	CLK("vpss", "slave", &vpss_slave_clk),
 	CLK(NULL, "clkout1", &clkout1_clk),
 	CLK(NULL, "clkout2", &clkout2_clk),
 	CLK(NULL, "pll2", &pll2_clk),
@@ -873,9 +873,6 @@ static int __init dm355_init_devices(void)
 	if (!cpu_is_davinci_dm355())
 		return 0;
 
-	/* Add ccdc clock aliases */
-	clk_add_alias("master", dm355_ccdc_dev.name, "vpss_master", NULL);
-	clk_add_alias("slave", dm355_ccdc_dev.name, "vpss_master", NULL);
 	davinci_cfg_reg(DM355_INT_EDMA_CC);
 	platform_device_register(&dm355_edma_device);
 	platform_device_register(&dm355_vpss_device);
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index 6c39805..c61dd94 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -257,6 +257,12 @@ static struct clk vpss_master_clk = {
 	.flags		= CLK_PSC,
 };
 
+static struct clk vpss_slave_clk = {
+	.name		= "vpss_slave",
+	.parent		= &pll1_sysclk5,
+	.lpsc		= DAVINCI_LPSC_VPSSSLV,
+};
+
 static struct clk arm_clk = {
 	.name		= "arm_clk",
 	.parent		= &pll2_sysclk2,
@@ -449,7 +455,8 @@ static struct clk_lookup dm365_clks[] = {
 	CLK(NULL, "pll2_sysclk8", &pll2_sysclk8),
 	CLK(NULL, "pll2_sysclk9", &pll2_sysclk9),
 	CLK(NULL, "vpss_dac", &vpss_dac_clk),
-	CLK(NULL, "vpss_master", &vpss_master_clk),
+	CLK("vpss", "master", &vpss_master_clk),
+	CLK("vpss", "slave", &vpss_slave_clk),
 	CLK(NULL, "arm", &arm_clk),
 	CLK(NULL, "uart0", &uart0_clk),
 	CLK(NULL, "uart1", &uart1_clk),
@@ -1239,8 +1246,6 @@ static int __init dm365_init_devices(void)
 	clk_add_alias(NULL, dev_name(&dm365_mdio_device.dev),
 		      NULL, &dm365_emac_device.dev);
 
-	/* Add isif clock alias */
-	clk_add_alias("master", dm365_isif_dev.name, "vpss_master", NULL);
 	platform_device_register(&dm365_vpss_device);
 	platform_device_register(&dm365_isif_dev);
 	platform_device_register(&vpfe_capture_dev);
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index ee0e994..c2a9273 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -300,8 +300,8 @@ static struct clk_lookup dm644x_clks[] = {
 	CLK(NULL, "dsp", &dsp_clk),
 	CLK(NULL, "arm", &arm_clk),
 	CLK(NULL, "vicp", &vicp_clk),
-	CLK(NULL, "vpss_master", &vpss_master_clk),
-	CLK(NULL, "vpss_slave", &vpss_slave_clk),
+	CLK("vpss", "master", &vpss_master_clk),
+	CLK("vpss", "slave", &vpss_slave_clk),
 	CLK(NULL, "arm", &arm_clk),
 	CLK(NULL, "uart0", &uart0_clk),
 	CLK(NULL, "uart1", &uart1_clk),
@@ -901,11 +901,6 @@ int __init dm644x_init_video(struct vpfe_config *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) {
diff --git a/arch/arm/mach-davinci/pm_domain.c b/arch/arm/mach-davinci/pm_domain.c
index c90250e..445b10b 100644
--- a/arch/arm/mach-davinci/pm_domain.c
+++ b/arch/arm/mach-davinci/pm_domain.c
@@ -53,7 +53,7 @@ static struct dev_pm_domain davinci_pm_domain = {
 
 static struct pm_clk_notifier_block platform_bus_notifier = {
 	.pm_domain = &davinci_pm_domain,
-	.con_ids = { "fck", NULL, },
+	.con_ids = { "fck", "master", "slave", NULL, },
 };
 
 static int __init davinci_pm_runtime_init(void)
diff --git a/drivers/media/platform/davinci/dm355_ccdc.c b/drivers/media/platform/davinci/dm355_ccdc.c
index 2364dba..05f8fb7 100644
--- a/drivers/media/platform/davinci/dm355_ccdc.c
+++ b/drivers/media/platform/davinci/dm355_ccdc.c
@@ -37,7 +37,6 @@
 #include <linux/platform_device.h>
 #include <linux/uaccess.h>
 #include <linux/videodev2.h>
-#include <linux/clk.h>
 #include <linux/err.h>
 #include <linux/module.h>
 
@@ -59,10 +58,6 @@ static struct ccdc_oper_config {
 	struct ccdc_params_raw bayer;
 	/* YCbCr configuration */
 	struct ccdc_params_ycbcr ycbcr;
-	/* Master clock */
-	struct clk *mclk;
-	/* slave clock */
-	struct clk *sclk;
 	/* ccdc base address */
 	void __iomem *base_addr;
 } ccdc_cfg = {
@@ -997,32 +992,10 @@ static int dm355_ccdc_probe(struct platform_device *pdev)
 		goto fail_nomem;
 	}
 
-	/* Get and enable Master clock */
-	ccdc_cfg.mclk = clk_get(&pdev->dev, "master");
-	if (IS_ERR(ccdc_cfg.mclk)) {
-		status = PTR_ERR(ccdc_cfg.mclk);
-		goto fail_nomap;
-	}
-	if (clk_prepare_enable(ccdc_cfg.mclk)) {
-		status = -ENODEV;
-		goto fail_mclk;
-	}
-
-	/* Get and enable Slave clock */
-	ccdc_cfg.sclk = clk_get(&pdev->dev, "slave");
-	if (IS_ERR(ccdc_cfg.sclk)) {
-		status = PTR_ERR(ccdc_cfg.sclk);
-		goto fail_mclk;
-	}
-	if (clk_prepare_enable(ccdc_cfg.sclk)) {
-		status = -ENODEV;
-		goto fail_sclk;
-	}
-
 	/* Platform data holds setup_pinmux function ptr */
 	if (NULL == pdev->dev.platform_data) {
 		status = -ENODEV;
-		goto fail_sclk;
+		goto fail_nomap;
 	}
 	setup_pinmux = pdev->dev.platform_data;
 	/*
@@ -1033,12 +1006,6 @@ static int dm355_ccdc_probe(struct platform_device *pdev)
 	ccdc_cfg.dev = &pdev->dev;
 	printk(KERN_NOTICE "%s is registered with vpfe.\n", ccdc_hw_dev.name);
 	return 0;
-fail_sclk:
-	clk_disable_unprepare(ccdc_cfg.sclk);
-	clk_put(ccdc_cfg.sclk);
-fail_mclk:
-	clk_disable_unprepare(ccdc_cfg.mclk);
-	clk_put(ccdc_cfg.mclk);
 fail_nomap:
 	iounmap(ccdc_cfg.base_addr);
 fail_nomem:
@@ -1052,10 +1019,6 @@ static int dm355_ccdc_remove(struct platform_device *pdev)
 {
 	struct resource	*res;
 
-	clk_disable_unprepare(ccdc_cfg.sclk);
-	clk_disable_unprepare(ccdc_cfg.mclk);
-	clk_put(ccdc_cfg.mclk);
-	clk_put(ccdc_cfg.sclk);
 	iounmap(ccdc_cfg.base_addr);
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 	if (res)
diff --git a/drivers/media/platform/davinci/dm644x_ccdc.c b/drivers/media/platform/davinci/dm644x_ccdc.c
index 971d639..30fa084 100644
--- a/drivers/media/platform/davinci/dm644x_ccdc.c
+++ b/drivers/media/platform/davinci/dm644x_ccdc.c
@@ -38,7 +38,6 @@
 #include <linux/uaccess.h>
 #include <linux/videodev2.h>
 #include <linux/gfp.h>
-#include <linux/clk.h>
 #include <linux/err.h>
 #include <linux/module.h>
 
@@ -60,10 +59,6 @@ static struct ccdc_oper_config {
 	struct ccdc_params_raw bayer;
 	/* YCbCr configuration */
 	struct ccdc_params_ycbcr ycbcr;
-	/* Master clock */
-	struct clk *mclk;
-	/* slave clock */
-	struct clk *sclk;
 	/* ccdc base address */
 	void __iomem *base_addr;
 } ccdc_cfg = {
@@ -991,38 +986,9 @@ static int dm644x_ccdc_probe(struct platform_device *pdev)
 		goto fail_nomem;
 	}
 
-	/* Get and enable Master clock */
-	ccdc_cfg.mclk = clk_get(&pdev->dev, "master");
-	if (IS_ERR(ccdc_cfg.mclk)) {
-		status = PTR_ERR(ccdc_cfg.mclk);
-		goto fail_nomap;
-	}
-	if (clk_prepare_enable(ccdc_cfg.mclk)) {
-		status = -ENODEV;
-		goto fail_mclk;
-	}
-
-	/* Get and enable Slave clock */
-	ccdc_cfg.sclk = clk_get(&pdev->dev, "slave");
-	if (IS_ERR(ccdc_cfg.sclk)) {
-		status = PTR_ERR(ccdc_cfg.sclk);
-		goto fail_mclk;
-	}
-	if (clk_prepare_enable(ccdc_cfg.sclk)) {
-		status = -ENODEV;
-		goto fail_sclk;
-	}
 	ccdc_cfg.dev = &pdev->dev;
 	printk(KERN_NOTICE "%s is registered with vpfe.\n", ccdc_hw_dev.name);
 	return 0;
-fail_sclk:
-	clk_disable_unprepare(ccdc_cfg.sclk);
-	clk_put(ccdc_cfg.sclk);
-fail_mclk:
-	clk_disable_unprepare(ccdc_cfg.mclk);
-	clk_put(ccdc_cfg.mclk);
-fail_nomap:
-	iounmap(ccdc_cfg.base_addr);
 fail_nomem:
 	release_mem_region(res->start, resource_size(res));
 fail_nores:
@@ -1034,10 +1000,6 @@ static int dm644x_ccdc_remove(struct platform_device *pdev)
 {
 	struct resource	*res;
 
-	clk_disable_unprepare(ccdc_cfg.mclk);
-	clk_disable_unprepare(ccdc_cfg.sclk);
-	clk_put(ccdc_cfg.mclk);
-	clk_put(ccdc_cfg.sclk);
 	iounmap(ccdc_cfg.base_addr);
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 	if (res)
@@ -1052,18 +1014,12 @@ static int dm644x_ccdc_suspend(struct device *dev)
 	ccdc_save_context();
 	/* Disable CCDC */
 	ccdc_enable(0);
-	/* Disable both master and slave clock */
-	clk_disable_unprepare(ccdc_cfg.mclk);
-	clk_disable_unprepare(ccdc_cfg.sclk);
 
 	return 0;
 }
 
 static int dm644x_ccdc_resume(struct device *dev)
 {
-	/* Enable both master and slave clock */
-	clk_prepare_enable(ccdc_cfg.mclk);
-	clk_prepare_enable(ccdc_cfg.sclk);
 	/* Restore CCDC context */
 	ccdc_restore_context();
 
diff --git a/drivers/media/platform/davinci/isif.c b/drivers/media/platform/davinci/isif.c
index abc3ae3..3332cca 100644
--- a/drivers/media/platform/davinci/isif.c
+++ b/drivers/media/platform/davinci/isif.c
@@ -32,7 +32,6 @@
 #include <linux/uaccess.h>
 #include <linux/io.h>
 #include <linux/videodev2.h>
-#include <linux/clk.h>
 #include <linux/err.h>
 #include <linux/module.h>
 
@@ -88,8 +87,6 @@ static struct isif_oper_config {
 	struct isif_ycbcr_config ycbcr;
 	struct isif_params_raw bayer;
 	enum isif_data_pack data_pack;
-	/* Master clock */
-	struct clk *mclk;
 	/* ISIF base address */
 	void __iomem *base_addr;
 	/* ISIF Linear Table 0 */
@@ -1039,6 +1036,10 @@ static int isif_probe(struct platform_device *pdev)
 	void *__iomem addr;
 	int status = 0, i;
 
+	/* Platform data holds setup_pinmux function ptr */
+	if (!pdev->dev.platform_data)
+		return -ENODEV;
+
 	/*
 	 * first try to register with vpfe. If not correct platform, then we
 	 * don't have to iomap
@@ -1047,22 +1048,6 @@ static int isif_probe(struct platform_device *pdev)
 	if (status < 0)
 		return status;
 
-	/* Get and enable Master clock */
-	isif_cfg.mclk = clk_get(&pdev->dev, "master");
-	if (IS_ERR(isif_cfg.mclk)) {
-		status = PTR_ERR(isif_cfg.mclk);
-		goto fail_mclk;
-	}
-	if (clk_prepare_enable(isif_cfg.mclk)) {
-		status = -ENODEV;
-		goto fail_mclk;
-	}
-
-	/* Platform data holds setup_pinmux function ptr */
-	if (NULL == pdev->dev.platform_data) {
-		status = -ENODEV;
-		goto fail_mclk;
-	}
 	setup_pinmux = pdev->dev.platform_data;
 	/*
 	 * setup Mux configuration for ccdc which may be different for
@@ -1124,9 +1109,6 @@ fail_nobase_res:
 		release_mem_region(res->start, resource_size(res));
 		i--;
 	}
-fail_mclk:
-	clk_disable_unprepare(isif_cfg.mclk);
-	clk_put(isif_cfg.mclk);
 	vpfe_unregister_ccdc_device(&isif_hw_dev);
 	return status;
 }
@@ -1146,8 +1128,6 @@ static int isif_remove(struct platform_device *pdev)
 		i++;
 	}
 	vpfe_unregister_ccdc_device(&isif_hw_dev);
-	clk_disable_unprepare(isif_cfg.mclk);
-	clk_put(isif_cfg.mclk);
 	return 0;
 }
 
diff --git a/drivers/media/platform/davinci/vpss.c b/drivers/media/platform/davinci/vpss.c
index a19c552..d36429d 100644
--- a/drivers/media/platform/davinci/vpss.c
+++ b/drivers/media/platform/davinci/vpss.c
@@ -25,6 +25,8 @@
 #include <linux/spinlock.h>
 #include <linux/compiler.h>
 #include <linux/io.h>
+#include <linux/pm_runtime.h>
+
 #include <media/davinci/vpss.h>
 
 MODULE_LICENSE("GPL");
@@ -490,6 +492,10 @@ static int vpss_probe(struct platform_device *pdev)
 	} else
 		oper_cfg.hw_ops.clear_wbl_overflow = dm644x_clear_wbl_overflow;
 
+	pm_runtime_enable(&pdev->dev);
+
+	pm_runtime_get(&pdev->dev);
+
 	spin_lock_init(&oper_cfg.vpss_lock);
 	dev_info(&pdev->dev, "%s vpss probe success\n", platform_name);
 	return 0;
@@ -507,6 +513,7 @@ static int vpss_remove(struct platform_device *pdev)
 {
 	struct resource		*res;
 
+	pm_runtime_disable(&pdev->dev);
 	iounmap(oper_cfg.vpss_regs_base0);
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 	release_mem_region(res->start, resource_size(res));
@@ -518,10 +525,28 @@ static int vpss_remove(struct platform_device *pdev)
 	return 0;
 }
 
+static int vpss_suspend(struct device *dev)
+{
+	pm_runtime_put(dev);
+	return 0;
+}
+
+static int vpss_resume(struct device *dev)
+{
+	pm_runtime_get(dev);
+	return 0;
+}
+
+static const struct dev_pm_ops vpss_pm_ops = {
+	.suspend = vpss_suspend,
+	.resume = vpss_resume,
+};
+
 static struct platform_driver vpss_driver = {
 	.driver = {
 		.name	= "vpss",
 		.owner = THIS_MODULE,
+		.pm = &vpss_pm_ops,
 	},
 	.remove = vpss_remove,
 	.probe = vpss_probe,
-- 
1.7.4.1



From prabhakar.csengg at gmail.com  Tue Apr  2 07:44:03 2013
From: prabhakar.csengg at gmail.com (Prabhakar lad)
Date: Tue,  2 Apr 2013 17:14:03 +0530
Subject: [PATCH v2 2/3] media: davinci: vpbe: venc: move the enabling of vpss
 clocks to driver
In-Reply-To: <1364903044-13752-1-git-send-email-prabhakar.csengg@gmail.com>
References: <1364903044-13752-1-git-send-email-prabhakar.csengg@gmail.com>
Message-ID: <1364903044-13752-3-git-send-email-prabhakar.csengg@gmail.com>

From: Lad, Prabhakar <prabhakar.csengg at gmail.com>

The vpss clocks were enabled by calling a exported function from a driver
in a machine code. calling driver code from platform code is incorrect way.

This patch fixes this issue and calls the function from driver code itself.

Signed-off-by: Lad, Prabhakar <prabhakar.csengg at gmail.com>
---
 drivers/media/platform/davinci/vpbe_venc.c |   25 +++++++++++++++++++++++++
 1 files changed, 25 insertions(+), 0 deletions(-)

diff --git a/drivers/media/platform/davinci/vpbe_venc.c b/drivers/media/platform/davinci/vpbe_venc.c
index f15f211..91d0272 100644
--- a/drivers/media/platform/davinci/vpbe_venc.c
+++ b/drivers/media/platform/davinci/vpbe_venc.c
@@ -202,6 +202,25 @@ static void venc_enabledigitaloutput(struct v4l2_subdev *sd, int benable)
 	}
 }
 
+static void
+venc_enable_vpss_clock(int venc_type,
+		       enum vpbe_enc_timings_type type,
+		       unsigned int pclock)
+{
+	if (venc_type == VPBE_VERSION_1)
+		return;
+
+	if (venc_type == VPBE_VERSION_2 && (type == VPBE_ENC_STD ||
+	    (type == VPBE_ENC_DV_TIMINGS && pclock <= 27000000))) {
+		vpss_enable_clock(VPSS_VENC_CLOCK_SEL, 1);
+		vpss_enable_clock(VPSS_VPBE_CLOCK, 1);
+		return;
+	}
+
+	if (venc_type == VPBE_VERSION_3 && type == VPBE_ENC_STD)
+		vpss_enable_clock(VPSS_VENC_CLOCK_SEL, 0);
+}
+
 #define VDAC_CONFIG_SD_V3	0x0E21A6B6
 #define VDAC_CONFIG_SD_V2	0x081141CF
 /*
@@ -220,6 +239,7 @@ static int venc_set_ntsc(struct v4l2_subdev *sd)
 	if (pdata->setup_clock(VPBE_ENC_STD, V4L2_STD_525_60) < 0)
 		return -EINVAL;
 
+	venc_enable_vpss_clock(venc->venc_type, VPBE_ENC_STD, V4L2_STD_525_60);
 	venc_enabledigitaloutput(sd, 0);
 
 	if (venc->venc_type == VPBE_VERSION_3) {
@@ -265,6 +285,7 @@ static int venc_set_pal(struct v4l2_subdev *sd)
 	if (venc->pdata->setup_clock(VPBE_ENC_STD, V4L2_STD_625_50) < 0)
 		return -EINVAL;
 
+	venc_enable_vpss_clock(venc->venc_type, VPBE_ENC_STD, V4L2_STD_625_50);
 	venc_enabledigitaloutput(sd, 0);
 
 	if (venc->venc_type == VPBE_VERSION_3) {
@@ -319,6 +340,7 @@ static int venc_set_480p59_94(struct v4l2_subdev *sd)
 	if (pdata->setup_clock(VPBE_ENC_DV_TIMINGS, 27000000) < 0)
 		return -EINVAL;
 
+	venc_enable_vpss_clock(venc->venc_type, VPBE_ENC_DV_TIMINGS, 27000000);
 	venc_enabledigitaloutput(sd, 0);
 
 	if (venc->venc_type == VPBE_VERSION_2)
@@ -366,6 +388,7 @@ static int venc_set_576p50(struct v4l2_subdev *sd)
 	if (pdata->setup_clock(VPBE_ENC_DV_TIMINGS, 27000000) < 0)
 		return -EINVAL;
 
+	venc_enable_vpss_clock(venc->venc_type, VPBE_ENC_DV_TIMINGS, 27000000);
 	venc_enabledigitaloutput(sd, 0);
 
 	if (venc->venc_type == VPBE_VERSION_2)
@@ -406,6 +429,7 @@ static int venc_set_720p60_internal(struct v4l2_subdev *sd)
 	if (pdata->setup_clock(VPBE_ENC_DV_TIMINGS, 74250000) < 0)
 		return -EINVAL;
 
+	venc_enable_vpss_clock(venc->venc_type, VPBE_ENC_DV_TIMINGS, 74250000);
 	venc_enabledigitaloutput(sd, 0);
 
 	venc_write(sd, VENC_OSDCLK0, 0);
@@ -434,6 +458,7 @@ static int venc_set_1080i30_internal(struct v4l2_subdev *sd)
 	if (pdata->setup_clock(VPBE_ENC_DV_TIMINGS, 74250000) < 0)
 		return -EINVAL;
 
+	venc_enable_vpss_clock(venc->venc_type, VPBE_ENC_DV_TIMINGS, 74250000);
 	venc_enabledigitaloutput(sd, 0);
 
 	venc_write(sd, VENC_OSDCLK0, 0);
-- 
1.7.4.1



From prabhakar.csengg at gmail.com  Tue Apr  2 07:44:04 2013
From: prabhakar.csengg at gmail.com (Prabhakar lad)
Date: Tue,  2 Apr 2013 17:14:04 +0530
Subject: [PATCH v2 3/3] davinic: vpss: trivial cleanup
In-Reply-To: <1364903044-13752-1-git-send-email-prabhakar.csengg@gmail.com>
References: <1364903044-13752-1-git-send-email-prabhakar.csengg@gmail.com>
Message-ID: <1364903044-13752-4-git-send-email-prabhakar.csengg@gmail.com>

From: Lad, Prabhakar <prabhakar.csengg at gmail.com>

this patch removes unnecessary header file inclusions and
fixes the typo's.

Signed-off-by: Lad, Prabhakar <prabhakar.csengg at gmail.com>
---
 drivers/media/platform/davinci/vpss.c |   11 +++--------
 1 files changed, 3 insertions(+), 8 deletions(-)

diff --git a/drivers/media/platform/davinci/vpss.c b/drivers/media/platform/davinci/vpss.c
index d36429d..8a2f01e 100644
--- a/drivers/media/platform/davinci/vpss.c
+++ b/drivers/media/platform/davinci/vpss.c
@@ -17,13 +17,8 @@
  *
  * common vpss system module platform driver for all video drivers.
  */
-#include <linux/kernel.h>
-#include <linux/sched.h>
-#include <linux/init.h>
 #include <linux/module.h>
 #include <linux/platform_device.h>
-#include <linux/spinlock.h>
-#include <linux/compiler.h>
 #include <linux/io.h>
 #include <linux/pm_runtime.h>
 
@@ -101,7 +96,7 @@ enum vpss_platform_type {
 
 /*
  * vpss operations. Depends on platform. Not all functions are available
- * on all platforms. The api, first check if a functio is available before
+ * on all platforms. The api, first check if a function is available before
  * invoking it. In the probe, the function ptrs are initialized based on
  * vpss name. vpss name can be "dm355_vpss", "dm644x_vpss" etc.
  */
@@ -116,7 +111,7 @@ struct vpss_hw_ops {
 	void (*set_sync_pol)(struct vpss_sync_pol);
 	/* set the PG_FRAME_SIZE register*/
 	void (*set_pg_frame_size)(struct vpss_pg_frame_size);
-	/* check and clear interrupt if occured */
+	/* check and clear interrupt if occurred */
 	int (*dma_complete_interrupt)(void);
 };
 
@@ -235,7 +230,7 @@ EXPORT_SYMBOL(vpss_clear_wbl_overflow);
 
 /*
  *  dm355_enable_clock - Enable VPSS Clock
- *  @clock_sel: CLock to be enabled/disabled
+ *  @clock_sel: Clock to be enabled/disabled
  *  @en: enable/disable flag
  *
  *  This is called to enable or disable a vpss clock
-- 
1.7.4.1



From jason at lakedaemon.net  Tue Apr  2 07:45:35 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Tue, 2 Apr 2013 07:45:35 -0400
Subject: [PATCH] ARM: kirkwood: DT board setup for CloudBox
In-Reply-To: <515A5BC6.5000007@free.fr>
References: <1364555206-5870-1-git-send-email-simon.guinot@sequanux.org>
 <20130329153132.GJ13280@titan.lakedaemon.net>
 <20130329184109.GA16404@kw.sim.vm.gnt> <51568B89.1060009@free.fr>
 <20130401163316.GC16404@kw.sim.vm.gnt> <515A5BC6.5000007@free.fr>
Message-ID: <20130402114535.GR13280@titan.lakedaemon.net>

On Tue, Apr 02, 2013 at 06:17:10AM +0200, Chris Moore wrote:
> Le 01/04/2013 18:33, Simon Guinot a ?crit :
...
> >The new CloudBox is a very different product which has been first named
> >FamilyBox and then released under the CloudBox name.

The question really comes down to, are there *any* differences on the
_board_?

If there are hardware differences, we need two dts files and two
compatibility strings.  Preferably appending the baseline model number
to each.  If they unwisely chose the same model number, we should append
'-db' or '-dev-board' to the compatibility string of the first board.

Although, in this case, there is a netspace_mini_v2 already in the
kernel (kirkwood-ns2mini.dts).  Is this the development version you were
speaking of?

> Are all the new ones white and all the old ones black?
> If so, can't we add white to the name or at least specify in Kconfig
> that it is the white version with a 3.5" disk?

No.  Colors don't tell us squat about the hardware differences.  Colors
change at the whim of marketing/management/region/time-of-year.  Model
numbers also aren't perfect, but they're much more reliable for
determining which board you have.

Also, the individual Kconfig board entries are going away.  So I
wouldn't encode anything in there you want kept around for the life of
the board.  A comment in the dts file would be better.

thx,

Jason.


From sergei.shtylyov at cogentembedded.com  Tue Apr  2 07:45:12 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Tue, 02 Apr 2013 15:45:12 +0400
Subject: [PATCH 1/2] ARM: shmobile: R8A7779: add Ether support
In-Reply-To: <87y5d16b1d.wl%kuninori.morimoto.gx@renesas.com>
References: <201304020204.54546.sergei.shtylyov@cogentembedded.com>
 <87y5d16b1d.wl%kuninori.morimoto.gx@renesas.com>
Message-ID: <515AC4C8.1080803@cogentembedded.com>

Hello.

On 02-04-2013 4:17, Kuninori Morimoto wrote:

>> +void __init r8a7779_add_ether_device(void *pdata)
>> +{
>> +	ether_device.dev.platform_data = pdata;
>> +
>> +	platform_device_register(&ether_device);
>> +}

> Current ARM SoC is trying to not use platform_device_register()
> Please use platform_device_register_xxx()
> Same comment for [2/2]

    Is there some rationale to it? I don't find platform_device_register_xxx()
especially handy to use.

WBR, Sergei



From agraf at suse.de  Tue Apr  2 07:45:39 2013
From: agraf at suse.de (Alexander Graf)
Date: Tue, 02 Apr 2013 13:45:39 +0200
Subject: [PATCH 3/3] ARM: EXYNOS5250: Register architected timers
In-Reply-To: <239701ce2f8f$093a2f40$1bae8dc0$%kim@samsung.com>
References: <1363222742-15220-1-git-send-email-agraf@suse.de>
 <1363222742-15220-4-git-send-email-agraf@suse.de>
 <239701ce2f8f$093a2f40$1bae8dc0$%kim@samsung.com>
Message-ID: <515AC4E3.2070508@suse.de>

On 04/02/2013 12:44 PM, Kukjin Kim wrote:
> Alexander Graf wrote:
>> When running on an exynos 5250 SoC, we don't initialize the architected
>> timers. The chip however supports architected timers.
>>
> Yes, exynos5250 can support, mct(multi core timer) is used though.
>
>> When we don't initialize them, KVM will try to access them and run into
>> NULL pointer dereferences attempting to do so.
>>
> Yes, right.
>
>> This patch is really more of a hack than a real fix, but does get me
>> working with KVM on Arndale.
>>
> Hmm, if you think, this is _really_ a hack, you need to add some comments
> about that for clearance, and since the mct.c file has been moved into
> drivers/clocksource/, this should be re-worked.
>
> BTW, I discussed about this with Thomas and Giridhar just now, we reached
> this 3rd patch could be dropped because the correct way is to add a dts
> node for arch timer which patch 2nd is already doing after 3.9-rc1 because
> of CLOCKSOURCE_OF_DECLARE macro.
>
> So if you' OK above, let me know so that I can take only 1st and 2nd
> patches to support KVM on exynos5250.

I'd say go ahead and take them and I'll verify whether things work on
your tree :).

What's the git repo of your branch?


Alex



From sergei.shtylyov at cogentembedded.com  Tue Apr  2 07:47:18 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Tue, 02 Apr 2013 15:47:18 +0400
Subject: [PATCH 1/2] ARM: shmobile: R8A7779: add Ether support
In-Reply-To: <87wqsl6ale.wl%kuninori.morimoto.gx@renesas.com>
References: <201304020204.54546.sergei.shtylyov@cogentembedded.com>
 <87wqsl6ale.wl%kuninori.morimoto.gx@renesas.com>
Message-ID: <515AC546.90905@cogentembedded.com>

Hello.

On 02-04-2013 4:27, Kuninori Morimoto wrote:

>> +void __init r8a7779_add_ether_device(void *pdata)
>> +{
>> +	ether_device.dev.platform_data = pdata;
>> +
>> +	platform_device_register(&ether_device);
>> +}

> We didn't use this style of registration before,
> but, it is OK.

     Se the DU support patches, I'm copying the approach from them.

> Then, this (void *pdata) should be
> (struct sh_eth_plat_data *pdata) IMO

    ether_device.dev.platform_data is 'void *'. I didn't want to bring in 
extra header for the little use.

WBR, Sergei



From jason at lakedaemon.net  Tue Apr  2 07:50:51 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Tue, 2 Apr 2013 07:50:51 -0400
Subject: [PATCH 4/6] arm: orion5x: move ts78xx to use rtc-m48t86 driver
 side memory interface
In-Reply-To: <1364858565-17192-5-git-send-email-alex@digriz.org.uk>
References: <1364858565-17192-1-git-send-email-alex@digriz.org.uk>
 <1364858565-17192-5-git-send-email-alex@digriz.org.uk>
Message-ID: <20130402115051.GS13280@titan.lakedaemon.net>

On Tue, Apr 02, 2013 at 12:22:43AM +0100, Alexander Clouter wrote:
> Remove platform_data hooks into rtc-m48t86 and use named resource regions.
> 
> Signed-off-by: Alexander Clouter <alex at digriz.org.uk>
> ---
>  arch/arm/mach-orion5x/ts78xx-setup.c |   78 ++++++++--------------------------
>  1 file changed, 17 insertions(+), 61 deletions(-)

Acked-by: Jason Cooper <jason at lakedaemon.net>

thx,

Jason.


From shawn.guo at linaro.org  Tue Apr  2 07:52:45 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 2 Apr 2013 19:52:45 +0800
Subject: [PATCH] ARM: i.MX53 Add the cko1, cko2 clock outputs.
In-Reply-To: <20130319165701.27591.1287.stgit@localhost>
References: <20130319165701.27591.1287.stgit@localhost>
Message-ID: <20130402115242.GD27148@S2101-09.ap.freescale.net>

On Tue, Mar 19, 2013 at 05:57:01PM +0100, Martin Fuzzey wrote:
> These two clocks connect to external pins and can be muxed to
> various internal clocks.
> They are typically used either for debugging or to provide
> clocks to external chips (eg audio codecs).
> 
> Currently only the selectable clocks that already exist in the clock tree
> have been added.
> 
> Signed-off-by: Martin Fuzzey <mfuzzey at parkeon.com>

Applied, thanks.



From plagnioj at jcrosoft.com  Tue Apr  2 07:50:14 2013
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Tue, 2 Apr 2013 13:50:14 +0200
Subject: [PATCHv2 6/6] video: fb: vt8500: Convert framebuffer drivers
 to standardized binding
In-Reply-To: <CABjd4Yx7zBAR+o-X7u9K9+iUeMq5qc=8n70qx1EoKPBT1JMR4A@mail.gmail.com>
References: <1364878200-26343-1-git-send-email-linux@prisktech.co.nz>
 <1364878200-26343-7-git-send-email-linux@prisktech.co.nz>
 <515AB229.4050204@ti.com>
 <CABjd4Yx7zBAR+o-X7u9K9+iUeMq5qc=8n70qx1EoKPBT1JMR4A@mail.gmail.com>
Message-ID: <20130402115014.GL20693@game.jcrosoft.org>

On 14:41 Tue 02 Apr     , Alexey Charkov wrote:
> 2013/4/2 Tomi Valkeinen <tomi.valkeinen at ti.com>:
> > On 2013-04-02 07:50, Tony Prisk wrote:
> >> Now that a display timing binding is available, convert our almost identical
> >> binding to use the standard binding.
> >>
> >> This patch converts the vt8500 and wm8505 framebuffer drivers and
> >> associated dts/dtsi files to use the standard binding as defined in
> >> bindings/video/display-timing.txt.
> >>
> >> There are two side-effects of making this conversion:
> >>
> >> 1) The fb node should now be in the board file, rather than the soc file as
> >> the display-timing node is a child of the fb node.
> >>
> >> 2) We still require a bits per pixel property to initialize the framebuffer
> >> for the different lcd panels. Rather than including this as part of the
> >> display timing, it is moved into the framebuffer node.
> >
> > This means that the boards using the current DT bindings won't work with
> > a kernel with these patches, right? Is that ok?
> 
> There are no known products shipping any DT-enabled firmware with
> these chips in the wild. The only way to run modern kernels on
> VIA/WonderMedia chips so far is by using the "appended DTB"
> workaround, and the instructions that have been posted to Wiki's and
> mailing list discussions imply that a fresh DTB is compiled from
> current kernel sources to produce a bootable image.
> 
> Thus, it seems that this change should not really break anything
> major, as the user base is quite small and those who use new code are
> most likely to use new DTB as well.
I usually disagree but ok

Best Regards,
J.


From prabhakar.csengg at gmail.com  Tue Apr  2 07:54:39 2013
From: prabhakar.csengg at gmail.com (Prabhakar lad)
Date: Tue,  2 Apr 2013 17:24:39 +0530
Subject: [PATCH v8 0/2] ARM: davinci: add support for dm365 vpbe display
Message-ID: <1364903681-13914-1-git-send-email-prabhakar.csengg@gmail.com>

From: Lad, Prabhakar <prabhakar.csengg at gmail.com>

This patch series enables VPBE display driver on DM365.

Changes for v8:
1: Fixed nits pointed by Sekhar.

Changes for v7:
1: Fixed nits pointed by Sekhar.

Changes for v6:
1: Fixed review comments pointed by Sekhar.

Changes for v5:
1: pass different platform names to handle different ip's.
2: Fixed review comments pointed by Sekhar.

Changes for v4:
1: Replaced the obsolete preset API by timings API.

Changes for v3:
1: Removed VPSS clock alias for master and slave which was
   sent for VPSS driver. since this patch was dependent on
   patch[1]. I will revist this patch once MC(captrure driver)
   goes into mainline.
[1] http://www.spinics.net/lists/linux-media/msg50562.html

Changes for v2:
1: Added VPSS clock so that capture and display
   can work independent.

Lad, Prabhakar (2):
  ARM: davinci: dm365: add support for v4l2 video display
  ARM: davinci: dm365 EVM: add support for VPBE display

 arch/arm/mach-davinci/board-dm365-evm.c |  166 +++++++++++++++++++++++++++-
 arch/arm/mach-davinci/davinci.h         |    7 +-
 arch/arm/mach-davinci/dm365.c           |  185 +++++++++++++++++++++++++++++--
 3 files changed, 346 insertions(+), 12 deletions(-)

-- 
1.7.4.1



From prabhakar.csengg at gmail.com  Tue Apr  2 07:54:40 2013
From: prabhakar.csengg at gmail.com (Prabhakar lad)
Date: Tue,  2 Apr 2013 17:24:40 +0530
Subject: [PATCH v8 1/2] ARM: davinci: dm365: add support for v4l2 video display
In-Reply-To: <1364903681-13914-1-git-send-email-prabhakar.csengg@gmail.com>
References: <1364903681-13914-1-git-send-email-prabhakar.csengg@gmail.com>
Message-ID: <1364903681-13914-2-git-send-email-prabhakar.csengg@gmail.com>

From: Lad, Prabhakar <prabhakar.csengg at gmail.com>

Create platform devices for various video modules like venc,osd,
vpbe and v4l2 driver for dm365.

Signed-off-by: Lad, Prabhakar <prabhakar.csengg at gmail.com>
---
 arch/arm/mach-davinci/board-dm365-evm.c |    4 +-
 arch/arm/mach-davinci/davinci.h         |    7 +-
 arch/arm/mach-davinci/dm365.c           |  185 +++++++++++++++++++++++++++++--
 3 files changed, 184 insertions(+), 12 deletions(-)

diff --git a/arch/arm/mach-davinci/board-dm365-evm.c b/arch/arm/mach-davinci/board-dm365-evm.c
index c2d4958..cf77c46 100644
--- a/arch/arm/mach-davinci/board-dm365-evm.c
+++ b/arch/arm/mach-davinci/board-dm365-evm.c
@@ -564,8 +564,6 @@ static struct davinci_uart_config uart_config __initdata = {
 
 static void __init dm365_evm_map_io(void)
 {
-	/* setup input configuration for VPFE input devices */
-	dm365_set_vpfe_config(&vpfe_cfg);
 	dm365_init();
 }
 
@@ -597,6 +595,8 @@ static __init void dm365_evm_init(void)
 
 	davinci_setup_mmc(0, &dm365evm_mmc_config);
 
+	dm365_init_video(&vpfe_cfg, NULL);
+
 	/* maybe setup mmc1/etc ... _after_ mmc0 */
 	evm_init_cpld();
 
diff --git a/arch/arm/mach-davinci/davinci.h b/arch/arm/mach-davinci/davinci.h
index 12d544b..a9de512 100644
--- a/arch/arm/mach-davinci/davinci.h
+++ b/arch/arm/mach-davinci/davinci.h
@@ -36,8 +36,13 @@
 #include <media/davinci/vpbe_osd.h>
 
 #define DAVINCI_SYSTEM_MODULE_BASE	0x01c40000
+#define SYSMOD_VDAC_CONFIG		0x2c
 #define SYSMOD_VIDCLKCTL		0x38
 #define SYSMOD_VPSS_CLKCTL		0x44
+#define VPSS_VENCCLKEN_ENABLE		BIT(3)
+#define VPSS_DACCLKEN_ENABLE		BIT(4)
+#define VPSS_PLLC2SYSCLK5_ENABLE	BIT(5)
+
 #define SYSMOD_VDD3P3VPWDN		0x48
 #define SYSMOD_VSCLKDIS			0x6c
 #define SYSMOD_PUPDCTL1			0x7c
@@ -84,7 +89,7 @@ void __init dm365_init_ks(struct davinci_ks_platform_data *pdata);
 void __init dm365_init_rtc(void);
 void dm365_init_spi0(unsigned chipselect_mask,
 			const struct spi_board_info *info, unsigned len);
-void dm365_set_vpfe_config(struct vpfe_config *cfg);
+int dm365_init_video(struct vpfe_config *, struct vpbe_config *);
 
 /* DM644x function declarations */
 void __init dm644x_init(void);
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index c61dd94..786c860 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -40,10 +40,14 @@
 
 #define DM365_REF_FREQ		24000000	/* 24 MHz on the DM365 EVM */
 
+#define DM365_RTC_BASE			0x01c69000
+
 /* Base of key scan register bank */
 #define DM365_KEYSCAN_BASE		0x01c69400
 
-#define DM365_RTC_BASE			0x01c69000
+#define DM365_OSD_BASE			0x01c71c00
+
+#define DM365_VENC_BASE			0x01c71e00
 
 #define DAVINCI_DM365_VC_BASE		0x01d0c000
 #define DAVINCI_DMA_VC_TX		2
@@ -1233,6 +1237,177 @@ static struct platform_device dm365_isif_dev = {
 	},
 };
 
+static struct resource dm365_osd_resources[] = {
+	{
+		.start = DM365_OSD_BASE,
+		.end   = DM365_OSD_BASE + 0xff,
+		.flags = IORESOURCE_MEM,
+	},
+};
+
+static u64 dm365_video_dma_mask = DMA_BIT_MASK(32);
+
+static struct platform_device dm365_osd_dev = {
+	.name		= DM365_VPBE_OSD_SUBDEV_NAME,
+	.id		= -1,
+	.num_resources	= ARRAY_SIZE(dm365_osd_resources),
+	.resource	= dm365_osd_resources,
+	.dev		= {
+		.dma_mask		= &dm365_video_dma_mask,
+		.coherent_dma_mask	= DMA_BIT_MASK(32),
+	},
+};
+
+static struct resource dm365_venc_resources[] = {
+	{
+		.start = IRQ_VENCINT,
+		.end   = IRQ_VENCINT,
+		.flags = IORESOURCE_IRQ,
+	},
+	/* venc registers io space */
+	{
+		.start = DM365_VENC_BASE,
+		.end   = DM365_VENC_BASE + 0x177,
+		.flags = IORESOURCE_MEM,
+	},
+	/* vdaccfg registers io space */
+	{
+		.start = DAVINCI_SYSTEM_MODULE_BASE + SYSMOD_VDAC_CONFIG,
+		.end   = DAVINCI_SYSTEM_MODULE_BASE + SYSMOD_VDAC_CONFIG + 3,
+		.flags = IORESOURCE_MEM,
+	},
+};
+
+static struct resource dm365_v4l2_disp_resources[] = {
+	{
+		.start = IRQ_VENCINT,
+		.end   = IRQ_VENCINT,
+		.flags = IORESOURCE_IRQ,
+	},
+	/* venc registers io space */
+	{
+		.start = DM365_VENC_BASE,
+		.end   = DM365_VENC_BASE + 0x177,
+		.flags = IORESOURCE_MEM,
+	},
+};
+
+static int dm365_vpbe_setup_pinmux(enum v4l2_mbus_pixelcode if_type,
+			    int field)
+{
+	switch (if_type) {
+	case V4L2_MBUS_FMT_SGRBG8_1X8:
+		davinci_cfg_reg(DM365_VOUT_FIELD_G81);
+		davinci_cfg_reg(DM365_VOUT_COUTL_EN);
+		davinci_cfg_reg(DM365_VOUT_COUTH_EN);
+		break;
+
+	case V4L2_MBUS_FMT_YUYV10_1X20:
+		if (field)
+			davinci_cfg_reg(DM365_VOUT_FIELD);
+		else
+			davinci_cfg_reg(DM365_VOUT_FIELD_G81);
+		davinci_cfg_reg(DM365_VOUT_COUTL_EN);
+		davinci_cfg_reg(DM365_VOUT_COUTH_EN);
+		break;
+
+	default:
+		return -EINVAL;
+	}
+
+	return 0;
+}
+
+static int dm365_venc_setup_clock(enum vpbe_enc_timings_type type,
+				  unsigned int pclock)
+{
+	void __iomem *vpss_clkctl_reg;
+	u32 val;
+
+	vpss_clkctl_reg = DAVINCI_SYSMOD_VIRT(SYSMOD_VPSS_CLKCTL);
+
+	switch (type) {
+	case VPBE_ENC_STD:
+		val = VPSS_VENCCLKEN_ENABLE | VPSS_DACCLKEN_ENABLE;
+		break;
+
+	case VPBE_ENC_DV_TIMINGS:
+		if (pclock <= 27000000) {
+			val = VPSS_VENCCLKEN_ENABLE | VPSS_DACCLKEN_ENABLE;
+		} else {
+			/* set sysclk4 to output 74.25 MHz from pll1 */
+			val = VPSS_PLLC2SYSCLK5_ENABLE | VPSS_DACCLKEN_ENABLE |
+			      VPSS_VENCCLKEN_ENABLE;
+		}
+		break;
+
+	default:
+		return -EINVAL;
+	}
+	writel(val, vpss_clkctl_reg);
+
+	return 0;
+}
+
+static struct platform_device dm365_vpbe_display = {
+	.name		= "vpbe-v4l2",
+	.id		= -1,
+	.num_resources  = ARRAY_SIZE(dm365_v4l2_disp_resources),
+	.resource	= dm365_v4l2_disp_resources,
+	.dev		= {
+		.dma_mask		= &dm365_video_dma_mask,
+		.coherent_dma_mask	= DMA_BIT_MASK(32),
+	},
+};
+
+struct venc_platform_data dm365_venc_pdata = {
+	.setup_pinmux	= dm365_vpbe_setup_pinmux,
+	.setup_clock	= dm365_venc_setup_clock,
+};
+
+static struct platform_device dm365_venc_dev = {
+	.name		= DM365_VPBE_VENC_SUBDEV_NAME,
+	.id		= -1,
+	.num_resources	= ARRAY_SIZE(dm365_venc_resources),
+	.resource	= dm365_venc_resources,
+	.dev		= {
+		.dma_mask		= &dm365_video_dma_mask,
+		.coherent_dma_mask	= DMA_BIT_MASK(32),
+		.platform_data		= (void *)&dm365_venc_pdata,
+	},
+};
+
+static struct platform_device dm365_vpbe_dev = {
+	.name		= "vpbe_controller",
+	.id		= -1,
+	.dev		= {
+		.dma_mask		= &dm365_video_dma_mask,
+		.coherent_dma_mask	= DMA_BIT_MASK(32),
+	},
+};
+
+int __init dm365_init_video(struct vpfe_config *vpfe_cfg,
+				struct vpbe_config *vpbe_cfg)
+{
+	if (vpfe_cfg || vpbe_cfg)
+		platform_device_register(&dm365_vpss_device);
+
+	if (vpfe_cfg) {
+		vpfe_capture_dev.dev.platform_data = vpfe_cfg;
+		platform_device_register(&dm365_isif_dev);
+		platform_device_register(&vpfe_capture_dev);
+	}
+	if (vpbe_cfg) {
+		dm365_vpbe_dev.dev.platform_data = vpbe_cfg;
+		platform_device_register(&dm365_osd_dev);
+		platform_device_register(&dm365_venc_dev);
+		platform_device_register(&dm365_vpbe_dev);
+		platform_device_register(&dm365_vpbe_display);
+	}
+
+	return 0;
+}
+
 static int __init dm365_init_devices(void)
 {
 	if (!cpu_is_davinci_dm365())
@@ -1246,14 +1421,6 @@ static int __init dm365_init_devices(void)
 	clk_add_alias(NULL, dev_name(&dm365_mdio_device.dev),
 		      NULL, &dm365_emac_device.dev);
 
-	platform_device_register(&dm365_vpss_device);
-	platform_device_register(&dm365_isif_dev);
-	platform_device_register(&vpfe_capture_dev);
 	return 0;
 }
 postcore_initcall(dm365_init_devices);
-
-void dm365_set_vpfe_config(struct vpfe_config *cfg)
-{
-       vpfe_capture_dev.dev.platform_data = cfg;
-}
-- 
1.7.4.1



From prabhakar.csengg at gmail.com  Tue Apr  2 07:54:41 2013
From: prabhakar.csengg at gmail.com (Prabhakar lad)
Date: Tue,  2 Apr 2013 17:24:41 +0530
Subject: [PATCH v8 2/2] ARM: davinci: dm365 EVM: add support for VPBE display
In-Reply-To: <1364903681-13914-1-git-send-email-prabhakar.csengg@gmail.com>
References: <1364903681-13914-1-git-send-email-prabhakar.csengg@gmail.com>
Message-ID: <1364903681-13914-3-git-send-email-prabhakar.csengg@gmail.com>

From: Lad, Prabhakar <prabhakar.csengg at gmail.com>

add support for V4L2 video display to DM365 EVM.
Support for SD and ED modes is provided, along with Composite
and Component outputs.

Signed-off-by: Lad, Prabhakar <prabhakar.csengg at gmail.com>
---
 arch/arm/mach-davinci/board-dm365-evm.c |  164 ++++++++++++++++++++++++++++++-
 1 files changed, 163 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-davinci/board-dm365-evm.c b/arch/arm/mach-davinci/board-dm365-evm.c
index cf77c46..0518ce5 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/v4l2-dv-timings.h>
 
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
@@ -39,6 +40,7 @@
 #include <linux/platform_data/mtd-davinci.h>
 #include <linux/platform_data/keyscan-davinci.h>
 
+#include <media/ths7303.h>
 #include <media/tvp514x.h>
 
 #include "davinci.h"
@@ -374,6 +376,166 @@ static struct vpfe_config vpfe_cfg = {
 	.ccdc = "ISIF",
 };
 
+/* venc standards timings */
+static struct vpbe_enc_mode_info dm365evm_enc_std_timing[] = {
+	{
+		.name		= "ntsc",
+		.timings_type	= VPBE_ENC_STD,
+		.std_id		= 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,
+		.std_id		= V4L2_STD_625_50,
+		.interlaced	= 1,
+		.xres		= 720,
+		.yres		= 576,
+		.aspect		= {54, 59},
+		.fps		= {25, 1},
+		.left_margin	= 0x7E,
+		.upper_margin	= 0x16,
+	},
+};
+
+/* venc dv timings */
+static struct vpbe_enc_mode_info dm365evm_enc_preset_timing[] = {
+	{
+		.name		= "480p59_94",
+		.timings_type	= VPBE_ENC_DV_TIMINGS,
+		.dv_timings	= V4L2_DV_BT_CEA_720X480P59_94,
+		.interlaced	= 0,
+		.xres		= 720,
+		.yres		= 480,
+		.aspect		= {1, 1},
+		.fps		= {5994, 100},
+		.left_margin	= 0x8F,
+		.upper_margin	= 0x2D,
+	},
+	{
+		.name		= "576p50",
+		.timings_type	= VPBE_ENC_DV_TIMINGS,
+		.dv_timings	= V4L2_DV_BT_CEA_720X576P50,
+		.interlaced	= 0,
+		.xres		= 720,
+		.yres		= 576,
+		.aspect		= {1, 1},
+		.fps		= {50, 1},
+		.left_margin	= 0x8C,
+		.upper_margin   = 0x36,
+	},
+	{
+		.name		= "720p60",
+		.timings_type	= VPBE_ENC_DV_TIMINGS,
+		.dv_timings	= V4L2_DV_BT_CEA_1280X720P60,
+		.interlaced	= 0,
+		.xres		= 1280,
+		.yres		= 720,
+		.aspect		= {1, 1},
+		.fps		= {60, 1},
+		.left_margin	= 0x117,
+		.right_margin	= 70,
+		.upper_margin	= 38,
+		.lower_margin	= 3,
+		.hsync_len	= 80,
+		.vsync_len	= 5,
+	},
+	{
+		.name		= "1080i60",
+		.timings_type	= VPBE_ENC_DV_TIMINGS,
+		.dv_timings	= V4L2_DV_BT_CEA_1920X1080I60,
+		.interlaced	= 1,
+		.xres		= 1920,
+		.yres		= 1080,
+		.aspect		= {1, 1},
+		.fps		= {30, 1},
+		.left_margin	= 0xc9,
+		.right_margin	= 80,
+		.upper_margin	= 30,
+		.lower_margin	= 3,
+		.hsync_len	= 88,
+		.vsync_len	= 5,
+	},
+};
+
+#define VENC_STD_ALL	(V4L2_STD_NTSC | V4L2_STD_PAL)
+
+/*
+ * The outputs available from VPBE + ecnoders. Keep the
+ * 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 dm365evm_vpbe_outputs[] = {
+	{
+		.output		= {
+			.index		= 0,
+			.name		= "Composite",
+			.type		= V4L2_OUTPUT_TYPE_ANALOG,
+			.std		= VENC_STD_ALL,
+			.capabilities	= V4L2_OUT_CAP_STD,
+		},
+		.subdev_name	= DM365_VPBE_VENC_SUBDEV_NAME,
+		.default_mode	= "ntsc",
+		.num_modes	= ARRAY_SIZE(dm365evm_enc_std_timing),
+		.modes		= dm365evm_enc_std_timing,
+		.if_params	= V4L2_MBUS_FMT_FIXED,
+	},
+	{
+		.output		= {
+			.index		= 1,
+			.name		= "Component",
+			.type		= V4L2_OUTPUT_TYPE_ANALOG,
+			.capabilities	= V4L2_OUT_CAP_DV_TIMINGS,
+		},
+		.subdev_name	= DM365_VPBE_VENC_SUBDEV_NAME,
+		.default_mode	= "480p59_94",
+		.num_modes	= ARRAY_SIZE(dm365evm_enc_preset_timing),
+		.modes		= dm365evm_enc_preset_timing,
+		.if_params	= V4L2_MBUS_FMT_FIXED,
+	},
+};
+
+/*
+ * Amplifiers on the board
+ */
+struct ths7303_platform_data ths7303_pdata = {
+	.ch_1 = 3,
+	.ch_2 = 3,
+	.ch_3 = 3,
+	.init_enable = 1,
+};
+
+static struct amp_config_info vpbe_amp = {
+	.module_name	= "ths7303",
+	.is_i2c		= 1,
+	.board_info	= {
+		I2C_BOARD_INFO("ths7303", 0x2c),
+		.platform_data = &ths7303_pdata,
+	}
+};
+
+static struct vpbe_config dm365evm_display_cfg = {
+	.module_name	= "dm365-vpbe-display",
+	.i2c_adapter_id	= 1,
+	.amp		= &vpbe_amp,
+	.osd		= {
+		.module_name	= DM365_VPBE_OSD_SUBDEV_NAME,
+	},
+	.venc		= {
+		.module_name	= DM365_VPBE_VENC_SUBDEV_NAME,
+	},
+	.num_outputs	= ARRAY_SIZE(dm365evm_vpbe_outputs),
+	.outputs	= dm365evm_vpbe_outputs,
+};
+
 static void __init evm_init_i2c(void)
 {
 	davinci_init_i2c(&i2c_pdata);
@@ -595,7 +757,7 @@ static __init void dm365_evm_init(void)
 
 	davinci_setup_mmc(0, &dm365evm_mmc_config);
 
-	dm365_init_video(&vpfe_cfg, NULL);
+	dm365_init_video(&vpfe_cfg, &dm365evm_display_cfg);
 
 	/* maybe setup mmc1/etc ... _after_ mmc0 */
 	evm_init_cpld();
-- 
1.7.4.1



From ning.n.jiang at gmail.com  Tue Apr  2 08:01:00 2013
From: ning.n.jiang at gmail.com (Ning Jiang)
Date: Tue, 2 Apr 2013 20:01:00 +0800
Subject: [PATCH] ARM: timer: Shutdown clock event device when stopping
 local timer
In-Reply-To: <CAH3Oq6SZHjjMDLbYNrgzZazsBXW61Z8_MjCoG7nwYNOe=eerPw@mail.gmail.com>
References: <1364549049-29278-1-git-send-email-ning.n.jiang@gmail.com>
 <5158C9B8.3070208@linaro.org>
 <CAH3Oq6SZHjjMDLbYNrgzZazsBXW61Z8_MjCoG7nwYNOe=eerPw@mail.gmail.com>
Message-ID: <CAH3Oq6Q=dQ732w0EqK1yG8WwSiG6O6dpB7cXYj2QKH5MfAPRow@mail.gmail.com>

2013/4/1 Ning Jiang <ning.n.jiang at gmail.com>:
> 2013/4/1 Daniel Lezcano <daniel.lezcano at linaro.org>:
>> On 03/29/2013 10:24 AM, ning.n.jiang at gmail.com wrote:
>>> From: Ning Jiang <ning.n.jiang at gmail.com>
>>>
>>> Currently there are two problems when we try to stop local timer.
>>> First, it calls set_mode function directly so mode state is not
>>> updated for the clock event device. Second, it makes the device
>>> unused instead of shutdown.
>>>
>>> A subtle error will happen because of it. When a cpu is plugged out
>>> it will stop the local timer. It will call tick_nohz_idle_enter()
>>> in idle thread afterwards. It will cancel the sched timer and try
>>> to reprogram the next event. This is wrong since the local timer
>>> is supposed to be stopped.
>>>
>>> The right way to stop the local timer is to shutdown it by calling
>>> clockevents_set_mode(). Thus when we try to reprogram the clock
>>> event device, it will return directly without doing anything since
>>> the clock mode is CLOCK_EVT_MODE_SHUTDOWN.
>>>
>>> Signed-off-by: Ning Jiang <ning.n.jiang at gmail.com>
>>> ---
>>>  arch/arm/kernel/smp_twd.c                |    2 +-
>>>  arch/arm/mach-exynos/mct.c               |    2 +-
>>>  arch/arm/mach-msm/timer.c                |    2 +-
>>>  drivers/clocksource/arm_arch_timer.c     |    2 +-
>>>  drivers/clocksource/time-armada-370-xp.c |    2 +-
>>>  5 files changed, 5 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/arch/arm/kernel/smp_twd.c b/arch/arm/kernel/smp_twd.c
>>> index 3f25650..c1d4ab4 100644
>>> --- a/arch/arm/kernel/smp_twd.c
>>> +++ b/arch/arm/kernel/smp_twd.c
>>> @@ -92,7 +92,7 @@ static int twd_timer_ack(void)
>>>
>>>  static void twd_timer_stop(struct clock_event_device *clk)
>>>  {
>>> -     twd_set_mode(CLOCK_EVT_MODE_UNUSED, clk);
>>> +     clockevents_set_mode(clk, CLOCK_EVT_MODE_SHUTDOWN);
>>>       disable_percpu_irq(clk->irq);
>>
>> Wouldn't be clockevents_shutdown more adequate here ? The next event
>> will be also set.
>
> You're right. clockevents_shutdown seems more appropriate here. I'll
> submit a revised patch for it.
>

Here attached the revised patch. Any more comments?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-ARM-timer-Shutdown-clock-event-device-when-stopping-.patch
Type: application/octet-stream
Size: 3765 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130402/5312debc/attachment.obj>

From chanho61.park at samsung.com  Tue Apr  2 08:01:14 2013
From: chanho61.park at samsung.com (Chanho Park)
Date: Tue, 02 Apr 2013 21:01:14 +0900
Subject: [PATCH 0/2] Support device_prep_dma_sg for pl330
Message-ID: <1364904076-3130-1-git-send-email-chanho61.park@samsung.com>

This patchset support device_prep_dma_sg functionality for pl330 dmaengine
driver. The prep_dma_sg function prepares descriptors to transfer between src
and dest memory which consists of scatter/gather list. The patchset contains
code clean-up to eliminate duplications.

Chanho Park (2):
  dma: pl330: split off common code to give back descriptors
  dma: pl330: add pl330_prep_dma_sg to transfer from sglist to sglist

 drivers/dma/pl330.c |  209 ++++++++++++++++++++++++++++++++++++++-------------
 1 file changed, 157 insertions(+), 52 deletions(-)

-- 
1.7.9.5



From chanho61.park at samsung.com  Tue Apr  2 08:01:15 2013
From: chanho61.park at samsung.com (Chanho Park)
Date: Tue, 02 Apr 2013 21:01:15 +0900
Subject: [PATCH 1/2] dma: pl330: split off common code to give back descriptors
In-Reply-To: <1364904076-3130-1-git-send-email-chanho61.park@samsung.com>
References: <1364904076-3130-1-git-send-email-chanho61.park@samsung.com>
Message-ID: <1364904076-3130-2-git-send-email-chanho61.park@samsung.com>

This patch adds __pl330_giveback_descs which give back descriptors when fails
allocating descriptors. It requires to eliminate duplication for
pl330_prep_dma_sg which will be added later.

Signed-off-by: Chanho Park <chanho61.park at samsung.com>
Signed-off-by: Myungjoo Ham <myungjoo.ham at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
---
 drivers/dma/pl330.c |   38 +++++++++++++++++++++++---------------
 1 file changed, 23 insertions(+), 15 deletions(-)

diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index 7181531..47ed13f 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -2795,6 +2795,28 @@ pl330_prep_dma_memcpy(struct dma_chan *chan, dma_addr_t dst,
 	return &desc->txd;
 }
 
+static void __pl330_giveback_desc(struct dma_pl330_dmac *pdmac,
+				  struct dma_pl330_desc *first)
+{
+	unsigned long flags;
+	struct dma_pl330_desc *desc;
+
+	if (!first)
+		return;
+
+	spin_lock_irqsave(&pdmac->pool_lock, flags);
+
+	while (!list_empty(&first->node)) {
+		desc = list_entry(first->node.next,
+				struct dma_pl330_desc, node);
+		list_move_tail(&desc->node, &pdmac->desc_pool);
+	}
+
+	list_move_tail(&first->node, &pdmac->desc_pool);
+
+	spin_unlock_irqrestore(&pdmac->pool_lock, flags);
+}
+
 static struct dma_async_tx_descriptor *
 pl330_prep_slave_sg(struct dma_chan *chan, struct scatterlist *sgl,
 		unsigned int sg_len, enum dma_transfer_direction direction,
@@ -2803,7 +2825,6 @@ pl330_prep_slave_sg(struct dma_chan *chan, struct scatterlist *sgl,
 	struct dma_pl330_desc *first, *desc = NULL;
 	struct dma_pl330_chan *pch = to_pchan(chan);
 	struct scatterlist *sg;
-	unsigned long flags;
 	int i;
 	dma_addr_t addr;
 
@@ -2823,20 +2844,7 @@ pl330_prep_slave_sg(struct dma_chan *chan, struct scatterlist *sgl,
 			dev_err(pch->dmac->pif.dev,
 				"%s:%d Unable to fetch desc\n",
 				__func__, __LINE__);
-			if (!first)
-				return NULL;
-
-			spin_lock_irqsave(&pdmac->pool_lock, flags);
-
-			while (!list_empty(&first->node)) {
-				desc = list_entry(first->node.next,
-						struct dma_pl330_desc, node);
-				list_move_tail(&desc->node, &pdmac->desc_pool);
-			}
-
-			list_move_tail(&first->node, &pdmac->desc_pool);
-
-			spin_unlock_irqrestore(&pdmac->pool_lock, flags);
+			__pl330_giveback_desc(pdmac, first);
 
 			return NULL;
 		}
-- 
1.7.9.5



From chanho61.park at samsung.com  Tue Apr  2 08:01:16 2013
From: chanho61.park at samsung.com (Chanho Park)
Date: Tue, 02 Apr 2013 21:01:16 +0900
Subject: [PATCH 2/2] dma: pl330: add pl330_prep_dma_sg to transfer from sglist
 to sglist
In-Reply-To: <1364904076-3130-1-git-send-email-chanho61.park@samsung.com>
References: <1364904076-3130-1-git-send-email-chanho61.park@samsung.com>
Message-ID: <1364904076-3130-3-git-send-email-chanho61.park@samsung.com>

This patch adds prep_dma_sg function to transfer memory to memory which mapped
in scatter/gather list. The patch move get_burst_len to upwards to call in the
__pl330_prep_dma_mecpy. Some duplicated code was splitted off from
prep_dma_memcpy.

Signed-off-by: Chanho Park <chanho61.park at samsung.com>
Signed-off-by: Myungjoo Ham <myungjoo.ham at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
---
 drivers/dma/pl330.c |  179 +++++++++++++++++++++++++++++++++++++++------------
 1 file changed, 138 insertions(+), 41 deletions(-)

diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index 47ed13f..4c1e301 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -2654,9 +2654,33 @@ static inline void fill_px(struct pl330_xfer *px,
 	px->src_addr = src;
 }
 
+/* Call after fixing burst size */
+static inline int get_burst_len(struct dma_pl330_desc *desc, size_t len)
+{
+	struct dma_pl330_chan *pch = desc->pchan;
+	struct pl330_info *pi = &pch->dmac->pif;
+	int burst_len;
+
+	burst_len = pi->pcfg.data_bus_width / 8;
+	burst_len *= pi->pcfg.data_buf_dep;
+	burst_len >>= desc->rqcfg.brst_size;
+
+	/* src/dst_burst_len can't be more than 16 */
+	if (burst_len > 16)
+		burst_len = 16;
+
+	while (burst_len > 1) {
+		if (!(len % (burst_len << desc->rqcfg.brst_size)))
+			break;
+		burst_len--;
+	}
+
+	return burst_len;
+}
+
 static struct dma_pl330_desc *
 __pl330_prep_dma_memcpy(struct dma_pl330_chan *pch, dma_addr_t dst,
-		dma_addr_t src, size_t len)
+		dma_addr_t src, size_t len, int burst)
 {
 	struct dma_pl330_desc *desc = pl330_get_desc(pch);
 
@@ -2678,31 +2702,23 @@ __pl330_prep_dma_memcpy(struct dma_pl330_chan *pch, dma_addr_t dst,
 	 */
 	fill_px(&desc->px, dst, src, len);
 
-	return desc;
-}
-
-/* Call after fixing burst size */
-static inline int get_burst_len(struct dma_pl330_desc *desc, size_t len)
-{
-	struct dma_pl330_chan *pch = desc->pchan;
-	struct pl330_info *pi = &pch->dmac->pif;
-	int burst_len;
-
-	burst_len = pi->pcfg.data_bus_width / 8;
-	burst_len *= pi->pcfg.data_buf_dep;
-	burst_len >>= desc->rqcfg.brst_size;
-
-	/* src/dst_burst_len can't be more than 16 */
-	if (burst_len > 16)
-		burst_len = 16;
+	desc->rqcfg.src_inc = 1;
+	desc->rqcfg.dst_inc = 1;
+	desc->req.rqtype = MEMTOMEM;
 
-	while (burst_len > 1) {
-		if (!(len % (burst_len << desc->rqcfg.brst_size)))
+	while (burst > 1) {
+		if (!(len % burst))
 			break;
-		burst_len--;
+		burst /= 2;
 	}
 
-	return burst_len;
+	desc->rqcfg.brst_size = 0;
+	while (burst != (1 << desc->rqcfg.brst_size))
+		desc->rqcfg.brst_size++;
+
+	desc->rqcfg.brst_len = get_burst_len(desc, len);
+
+	return desc;
 }
 
 static struct dma_async_tx_descriptor *pl330_prep_dma_cyclic(
@@ -2767,28 +2783,12 @@ pl330_prep_dma_memcpy(struct dma_chan *chan, dma_addr_t dst,
 
 	pi = &pch->dmac->pif;
 
-	desc = __pl330_prep_dma_memcpy(pch, dst, src, len);
-	if (!desc)
-		return NULL;
-
-	desc->rqcfg.src_inc = 1;
-	desc->rqcfg.dst_inc = 1;
-	desc->req.rqtype = MEMTOMEM;
-
 	/* Select max possible burst size */
 	burst = pi->pcfg.data_bus_width / 8;
 
-	while (burst > 1) {
-		if (!(len % burst))
-			break;
-		burst /= 2;
-	}
-
-	desc->rqcfg.brst_size = 0;
-	while (burst != (1 << desc->rqcfg.brst_size))
-		desc->rqcfg.brst_size++;
-
-	desc->rqcfg.brst_len = get_burst_len(desc, len);
+	desc = __pl330_prep_dma_memcpy(pch, dst, src, len, burst);
+	if (!desc)
+		return NULL;
 
 	desc->txd.flags = flags;
 
@@ -2818,6 +2818,102 @@ static void __pl330_giveback_desc(struct dma_pl330_dmac *pdmac,
 }
 
 static struct dma_async_tx_descriptor *
+pl330_prep_dma_sg(struct dma_chan *chan,
+	struct scatterlist *dst_sg, unsigned int dst_nents,
+	struct scatterlist *src_sg, unsigned int src_nents,
+	unsigned long flags)
+{
+	struct dma_pl330_desc *first, *desc = NULL;
+	struct dma_pl330_chan *pch = to_pchan(chan);
+	struct pl330_info *pi;
+	dma_addr_t src, dst;
+	size_t len, dst_len = 0, src_len = 0;
+	int burst;
+
+	if (unlikely(!pch))
+		return NULL;
+
+	pi = &pch->dmac->pif;
+
+	/* basic sanity checks */
+	if (dst_nents == 0 || src_nents == 0)
+		return NULL;
+
+	if (dst_sg == NULL || src_sg == NULL)
+		return NULL;
+
+	first = NULL;
+
+	/* Select max possible burst size */
+	burst = pi->pcfg.data_bus_width / 8;
+
+	/* get prepared for the loop */
+	dst_len = sg_dma_len(dst_sg);
+	src_len = sg_dma_len(src_sg);
+
+	while (true) {
+		len = min_t(size_t, src_len, dst_len);
+
+		if (len == 0)
+			goto fetch;
+
+		dst = sg_dma_address(dst_sg) + sg_dma_len(dst_sg) - dst_len;
+		src = sg_dma_address(src_sg) + sg_dma_len(src_sg) - src_len;
+
+		desc = __pl330_prep_dma_memcpy(pch, dst, src, len, burst);
+		if (!desc) {
+			struct dma_pl330_dmac *pdmac = pch->dmac;
+
+			dev_err(pdmac->pif.dev,
+				"%s:%d Unable to fetch desc\n",
+				__func__, __LINE__);
+
+			__pl330_giveback_desc(pdmac, first);
+
+			return NULL;
+		}
+		if (!first)
+			first = desc;
+		else
+			list_add_tail(&desc->node, &first->node);
+
+		desc->txd.flags = flags;
+
+		dst_len -= len;
+		src_len -= len;
+
+fetch:
+		/* fetch the next dst scatterlist entry */
+		if (dst_len == 0) {
+			/* no more entries: we're done */
+			if (dst_nents == 0)
+				break;
+			/* fetch the next entry: if there are no more: done */
+			dst_sg = sg_next(dst_sg);
+			if (dst_sg == NULL)
+				break;
+			dst_nents--;
+			dst_len = sg_dma_len(dst_sg);
+		}
+
+		/* fetch the next src scatterlist entry */
+		if (src_len == 0) {
+			/* no more entries: we're done */
+			if (src_nents == 0)
+				break;
+			/* fetch the next entry: if there are no more: done */
+			src_sg = sg_next(src_sg);
+			if (src_sg == NULL)
+				break;
+			src_nents--;
+			src_len = sg_dma_len(src_sg);
+		}
+	}
+
+	return &first->txd;
+}
+
+static struct dma_async_tx_descriptor *
 pl330_prep_slave_sg(struct dma_chan *chan, struct scatterlist *sgl,
 		unsigned int sg_len, enum dma_transfer_direction direction,
 		unsigned long flg, void *context)
@@ -2983,6 +3079,7 @@ pl330_probe(struct amba_device *adev, const struct amba_id *id)
 	pd->device_alloc_chan_resources = pl330_alloc_chan_resources;
 	pd->device_free_chan_resources = pl330_free_chan_resources;
 	pd->device_prep_dma_memcpy = pl330_prep_dma_memcpy;
+	pd->device_prep_dma_sg = pl330_prep_dma_sg;
 	pd->device_prep_dma_cyclic = pl330_prep_dma_cyclic;
 	pd->device_tx_status = pl330_tx_status;
 	pd->device_prep_slave_sg = pl330_prep_slave_sg;
-- 
1.7.9.5



From sergei.shtylyov at cogentembedded.com  Tue Apr  2 08:17:10 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Tue, 02 Apr 2013 16:17:10 +0400
Subject: [PATCH 16/30] ARM: shmobile: sh7372: use fixed ratio clock
In-Reply-To: <1364879246-9470-17-git-send-email-horms+renesas@verge.net.au>
References: <1364879246-9470-1-git-send-email-horms+renesas@verge.net.au>
 <1364879246-9470-17-git-send-email-horms+renesas@verge.net.au>
Message-ID: <515ACC46.9020402@cogentembedded.com>

Hello.

On 02-04-2013 9:07, Simon Horman wrote:

> From: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>

> Current clock-sh7372 is using own implement
> for each divX clocks.
> This patch switches to use fixed ratio clock,
> and was tesed on mackerel board.
>
> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
> Acked-by: Magnus Damm <damm at opensource.se>
> Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
> ---
>   arch/arm/mach-shmobile/clock-sh7372.c |   44 ++++++---------------------------
>   1 file changed, 7 insertions(+), 37 deletions(-)

> diff --git a/arch/arm/mach-shmobile/clock-sh7372.c b/arch/arm/mach-shmobile/clock-sh7372.c
> index 6c23e3f..7e10593 100644
> --- a/arch/arm/mach-shmobile/clock-sh7372.c
> +++ b/arch/arm/mach-shmobile/clock-sh7372.c
[...]
> @@ -83,39 +84,12 @@ struct clk sh7372_extal2_clk = {
[...]
> +SH_FIXED_RATIO_CLKg(sh7372_dv_clki_div2_clk,	sh7372_dv_clki_clk,	div2);
> +SH_FIXED_RATIO_CLK(extal1_div2_clk,		sh7372_extal1_clk,	div2);
> +SH_FIXED_RATIO_CLK(extal2_div2_clk,		sh7372_extal2_clk,	div2);
> +SH_FIXED_RATIO_CLK(extal2_div4_clk,		extal2_div2_clk,	div2);

    Note that SH_FIXED_RATIO_CLK() definition already includes ; -- it 
probably should be removed from there.

WBR, Sergei



From tpiepho at gmail.com  Tue Apr  2 08:19:45 2013
From: tpiepho at gmail.com (Trent Piepho)
Date: Tue,  2 Apr 2013 05:19:45 -0700
Subject: [PATCH V2 02/12] spi/mxs: Remove mxs_spi_enable and mxs_spi_disable
In-Reply-To: <1364905195-24286-1-git-send-email-tpiepho@gmail.com>
References: <1364905195-24286-1-git-send-email-tpiepho@gmail.com>
Message-ID: <1364905195-24286-2-git-send-email-tpiepho@gmail.com>

These functions do nothing but one single writel call and are only
called in once.  And the names really aren't accurate or clear, since
they don't enable or disble SPI.  Rather they set the bit that
controls the state of CS at the end of transfer.  It easier to follow
the code to just set this bit with a writel() along with all the other
bits.

Signed-off-by: Trent Piepho <tpiepho at gmail.com>
Cc: Marek Vasut <marex at denx.de>
Cc: Fabio Estevam <fabio.estevam at freescale.com>
Cc: Shawn Guo <shawn.guo at linaro.org>
---
 drivers/spi/spi-mxs.c |   24 +++++-------------------
 1 file changed, 5 insertions(+), 19 deletions(-)

diff --git a/drivers/spi/spi-mxs.c b/drivers/spi/spi-mxs.c
index 9334167..7eb4bc9 100644
--- a/drivers/spi/spi-mxs.c
+++ b/drivers/spi/spi-mxs.c
@@ -157,22 +157,6 @@ static void mxs_spi_set_cs(struct mxs_spi *spi, unsigned cs)
 	writel(select, ssp->base + HW_SSP_CTRL0 + STMP_OFFSET_REG_SET);
 }
 
-static inline void mxs_spi_enable(struct mxs_spi *spi)
-{
-	struct mxs_ssp *ssp = &spi->ssp;
-
-	writel(BM_SSP_CTRL0_IGNORE_CRC,
-		ssp->base + HW_SSP_CTRL0 + STMP_OFFSET_REG_CLR);
-}
-
-static inline void mxs_spi_disable(struct mxs_spi *spi)
-{
-	struct mxs_ssp *ssp = &spi->ssp;
-
-	writel(BM_SSP_CTRL0_IGNORE_CRC,
-		ssp->base + HW_SSP_CTRL0 + STMP_OFFSET_REG_SET);
-}
-
 static int mxs_ssp_wait(struct mxs_spi *spi, int offset, int mask, bool set)
 {
 	const unsigned long timeout = jiffies + msecs_to_jiffies(SSP_TIMEOUT);
@@ -346,14 +330,16 @@ static int mxs_spi_txrx_pio(struct mxs_spi *spi, int cs,
 {
 	struct mxs_ssp *ssp = &spi->ssp;
 
-	if (*first)
-		mxs_spi_enable(spi);
+	/* Clear this now, set it on last transfer if needed */
+	writel(BM_SSP_CTRL0_IGNORE_CRC,
+	       ssp->base + HW_SSP_CTRL0 + STMP_OFFSET_REG_CLR);
 
 	mxs_spi_set_cs(spi, cs);
 
 	while (len--) {
 		if (*last && len == 0)
-			mxs_spi_disable(spi);
+			writel(BM_SSP_CTRL0_IGNORE_CRC,
+			       ssp->base + HW_SSP_CTRL0 + STMP_OFFSET_REG_SET);
 
 		if (ssp->devid == IMX23_SSP) {
 			writel(BM_SSP_CTRL0_XFER_COUNT,
-- 
1.7.10.4



From tpiepho at gmail.com  Tue Apr  2 08:19:44 2013
From: tpiepho at gmail.com (Trent Piepho)
Date: Tue,  2 Apr 2013 05:19:44 -0700
Subject: [PATCH V2 01/12] spi/mxs: Always set LOCK_CS
Message-ID: <1364905195-24286-1-git-send-email-tpiepho@gmail.com>

There are two bits which control the CS line in the CTRL0 register:
LOCK_CS and IGNORE_CRC.  The latter would be better named DEASSERT_CS
in SPI mode.

LOCK_CS keeps CS asserted though the entire transfer.  This should
always be set.  The DMA code will always set it, explicitly on the
first segment of the first transfer, and then implicitly on all the
rest by never clearing the bit from the value read from the ctrl0
register.

The only reason to not set LOCK_CS would be to attempt an altered
protocol where CS pulses between each word.  Though don't get your
hopes up if you want to do this, as the hardware doesn't appear to do
this in any sane manner.

The code can be simplified by just setting LOCK_CS once and then not
needing to deal with it in the PIO and DMA transfer functions.

Signed-off-by: Trent Piepho <tpiepho at gmail.com>
Cc: Marek Vasut <marex at denx.de>
Cc: Fabio Estevam <fabio.estevam at freescale.com>
Cc: Shawn Guo <shawn.guo at linaro.org>
---
 drivers/spi/spi-mxs.c |    8 ++------
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/spi/spi-mxs.c b/drivers/spi/spi-mxs.c
index 22a0af0..9334167 100644
--- a/drivers/spi/spi-mxs.c
+++ b/drivers/spi/spi-mxs.c
@@ -91,6 +91,8 @@ static int mxs_spi_setup_transfer(struct spi_device *dev,
 
 	mxs_ssp_set_clk_rate(ssp, hz);
 
+	writel(BM_SSP_CTRL0_LOCK_CS,
+		ssp->base + HW_SSP_CTRL0 + STMP_OFFSET_REG_SET);
 	writel(BF_SSP_CTRL1_SSP_MODE(BV_SSP_CTRL1_SSP_MODE__SPI) |
 		     BF_SSP_CTRL1_WORD_LENGTH
 		     (BV_SSP_CTRL1_WORD_LENGTH__EIGHT_BITS) |
@@ -159,8 +161,6 @@ static inline void mxs_spi_enable(struct mxs_spi *spi)
 {
 	struct mxs_ssp *ssp = &spi->ssp;
 
-	writel(BM_SSP_CTRL0_LOCK_CS,
-		ssp->base + HW_SSP_CTRL0 + STMP_OFFSET_REG_SET);
 	writel(BM_SSP_CTRL0_IGNORE_CRC,
 		ssp->base + HW_SSP_CTRL0 + STMP_OFFSET_REG_CLR);
 }
@@ -169,8 +169,6 @@ static inline void mxs_spi_disable(struct mxs_spi *spi)
 {
 	struct mxs_ssp *ssp = &spi->ssp;
 
-	writel(BM_SSP_CTRL0_LOCK_CS,
-		ssp->base + HW_SSP_CTRL0 + STMP_OFFSET_REG_CLR);
 	writel(BM_SSP_CTRL0_IGNORE_CRC,
 		ssp->base + HW_SSP_CTRL0 + STMP_OFFSET_REG_SET);
 }
@@ -244,8 +242,6 @@ static int mxs_spi_txrx_dma(struct mxs_spi *spi, int cs,
 	ctrl0 &= ~BM_SSP_CTRL0_XFER_COUNT;
 	ctrl0 |= BM_SSP_CTRL0_DATA_XFER | mxs_spi_cs_to_reg(cs);
 
-	if (*first)
-		ctrl0 |= BM_SSP_CTRL0_LOCK_CS;
 	if (!write)
 		ctrl0 |= BM_SSP_CTRL0_READ;
 
-- 
1.7.10.4



From tpiepho at gmail.com  Tue Apr  2 08:19:46 2013
From: tpiepho at gmail.com (Trent Piepho)
Date: Tue,  2 Apr 2013 05:19:46 -0700
Subject: [PATCH V2 03/12] spi/mxs: Change flag arguments in txrx functions to
 bit flags
In-Reply-To: <1364905195-24286-1-git-send-email-tpiepho@gmail.com>
References: <1364905195-24286-1-git-send-email-tpiepho@gmail.com>
Message-ID: <1364905195-24286-3-git-send-email-tpiepho@gmail.com>

There are three flag arguments to the PIO and DMA txrx functions.  Two
are passed as pointers to integers, even though they are input only
and not modified, which makes no sense to do.  The third is passed as
an integer.

The compiler must use an argument register or stack variable for each
flag this way.  By using bitflags in a single flag argument more
efficient and smaller code is produced since all the flags can fit in
a single register.  And all the flag arguments get cumbersome,
especially when more are added for things like GPIO chipselects.

The "first" flag is never used, so can just be deleted.

The "last" flag is renamed to DEASSERT_CS, since that's really what it
does.  The spi_transfer cs_change flag means that CS might be
de-asserted on a transfer which is not last and not de-assert on the
last transfer, so it is not which transfer is the last we need to know
but rather the transfers which after which CS should be de-asserted.

This also extends the driver to not ignore cs_change when setting the
DEASSERT_CS nee "last" flag.

Signed-off-by: Trent Piepho <tpiepho at gmail.com>
Cc: Marek Vasut <marex at denx.de>
Cc: Fabio Estevam <fabio.estevam at freescale.com>
Cc: Shawn Guo <shawn.guo at linaro.org>
---
 drivers/spi/spi-mxs.c |   55 ++++++++++++++++++++++++++++---------------------
 1 file changed, 31 insertions(+), 24 deletions(-)

diff --git a/drivers/spi/spi-mxs.c b/drivers/spi/spi-mxs.c
index 7eb4bc9..3064304 100644
--- a/drivers/spi/spi-mxs.c
+++ b/drivers/spi/spi-mxs.c
@@ -58,6 +58,13 @@
 
 #define SG_MAXLEN		0xff00
 
+/*
+ * Flags for txrx functions.  More efficient that using an argument register for
+ * each one.
+ */
+#define TXRX_WRITE		1	/* This is a write */
+#define TXRX_DEASSERT_CS	2	/* De-assert CS at end of txrx */
+
 struct mxs_spi {
 	struct mxs_ssp		ssp;
 	struct completion	c;
@@ -196,7 +203,7 @@ static irqreturn_t mxs_ssp_irq_handler(int irq, void *dev_id)
 
 static int mxs_spi_txrx_dma(struct mxs_spi *spi, int cs,
 			    unsigned char *buf, int len,
-			    int *first, int *last, int write)
+			    unsigned int flags)
 {
 	struct mxs_ssp *ssp = &spi->ssp;
 	struct dma_async_tx_descriptor *desc = NULL;
@@ -226,15 +233,19 @@ static int mxs_spi_txrx_dma(struct mxs_spi *spi, int cs,
 	ctrl0 &= ~BM_SSP_CTRL0_XFER_COUNT;
 	ctrl0 |= BM_SSP_CTRL0_DATA_XFER | mxs_spi_cs_to_reg(cs);
 
-	if (!write)
+	if (!(flags & TXRX_WRITE))
 		ctrl0 |= BM_SSP_CTRL0_READ;
 
 	/* Queue the DMA data transfer. */
 	for (sg_count = 0; sg_count < sgs; sg_count++) {
+		/* Prepare the transfer descriptor. */
 		min = min(len, desc_len);
 
-		/* Prepare the transfer descriptor. */
-		if ((sg_count + 1 == sgs) && *last)
+		/*
+		 * De-assert CS on last segment if flag is set (i.e., no more
+		 * transfers will follow)
+		 */
+		if ((sg_count + 1 == sgs) && (flags & TXRX_DEASSERT_CS))
 			ctrl0 |= BM_SSP_CTRL0_IGNORE_CRC;
 
 		if (ssp->devid == IMX23_SSP) {
@@ -259,7 +270,7 @@ static int mxs_spi_txrx_dma(struct mxs_spi *spi, int cs,
 
 		sg_init_one(&dma_xfer[sg_count].sg, sg_buf, min);
 		ret = dma_map_sg(ssp->dev, &dma_xfer[sg_count].sg, 1,
-			write ? DMA_TO_DEVICE : DMA_FROM_DEVICE);
+			(flags & TXRX_WRITE) ? DMA_TO_DEVICE : DMA_FROM_DEVICE);
 
 		len -= min;
 		buf += min;
@@ -279,7 +290,7 @@ static int mxs_spi_txrx_dma(struct mxs_spi *spi, int cs,
 
 		desc = dmaengine_prep_slave_sg(ssp->dmach,
 				&dma_xfer[sg_count].sg, 1,
-				write ? DMA_MEM_TO_DEV : DMA_DEV_TO_MEM,
+				(flags & TXRX_WRITE) ? DMA_MEM_TO_DEV : DMA_DEV_TO_MEM,
 				DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
 
 		if (!desc) {
@@ -316,7 +327,7 @@ err_vmalloc:
 	while (--sg_count >= 0) {
 err_mapped:
 		dma_unmap_sg(ssp->dev, &dma_xfer[sg_count].sg, 1,
-			write ? DMA_TO_DEVICE : DMA_FROM_DEVICE);
+			(flags & TXRX_WRITE) ? DMA_TO_DEVICE : DMA_FROM_DEVICE);
 	}
 
 	kfree(dma_xfer);
@@ -326,7 +337,7 @@ err_mapped:
 
 static int mxs_spi_txrx_pio(struct mxs_spi *spi, int cs,
 			    unsigned char *buf, int len,
-			    int *first, int *last, int write)
+			    unsigned int flags)
 {
 	struct mxs_ssp *ssp = &spi->ssp;
 
@@ -337,7 +348,7 @@ static int mxs_spi_txrx_pio(struct mxs_spi *spi, int cs,
 	mxs_spi_set_cs(spi, cs);
 
 	while (len--) {
-		if (*last && len == 0)
+		if (len == 0 && (flags & TXRX_DEASSERT_CS))
 			writel(BM_SSP_CTRL0_IGNORE_CRC,
 			       ssp->base + HW_SSP_CTRL0 + STMP_OFFSET_REG_SET);
 
@@ -350,7 +361,7 @@ static int mxs_spi_txrx_pio(struct mxs_spi *spi, int cs,
 			writel(1, ssp->base + HW_SSP_XFER_SIZE);
 		}
 
-		if (write)
+		if (flags & TXRX_WRITE)
 			writel(BM_SSP_CTRL0_READ,
 				ssp->base + HW_SSP_CTRL0 + STMP_OFFSET_REG_CLR);
 		else
@@ -363,13 +374,13 @@ static int mxs_spi_txrx_pio(struct mxs_spi *spi, int cs,
 		if (mxs_ssp_wait(spi, HW_SSP_CTRL0, BM_SSP_CTRL0_RUN, 1))
 			return -ETIMEDOUT;
 
-		if (write)
+		if (flags & TXRX_WRITE)
 			writel(*buf, ssp->base + HW_SSP_DATA(ssp));
 
 		writel(BM_SSP_CTRL0_DATA_XFER,
 			     ssp->base + HW_SSP_CTRL0 + STMP_OFFSET_REG_SET);
 
-		if (!write) {
+		if (!(flags & TXRX_WRITE)) {
 			if (mxs_ssp_wait(spi, HW_SSP_STATUS(ssp),
 						BM_SSP_STATUS_FIFO_EMPTY, 0))
 				return -ETIMEDOUT;
@@ -394,13 +405,11 @@ static int mxs_spi_transfer_one(struct spi_master *master,
 {
 	struct mxs_spi *spi = spi_master_get_devdata(master);
 	struct mxs_ssp *ssp = &spi->ssp;
-	int first, last;
 	struct spi_transfer *t, *tmp_t;
+	unsigned int flag;
 	int status = 0;
 	int cs;
 
-	first = last = 0;
-
 	cs = m->spi->chip_select;
 
 	list_for_each_entry_safe(t, tmp_t, &m->transfers, transfer_list) {
@@ -409,10 +418,9 @@ static int mxs_spi_transfer_one(struct spi_master *master,
 		if (status)
 			break;
 
-		if (&t->transfer_list == m->transfers.next)
-			first = 1;
-		if (&t->transfer_list == m->transfers.prev)
-			last = 1;
+		/* De-assert on last transfer, inverted by cs_change flag */
+		flag = (&t->transfer_list == m->transfers.prev) ^ t->cs_change ?
+		       TXRX_DEASSERT_CS : 0;
 		if ((t->rx_buf && t->tx_buf) || (t->rx_dma && t->tx_dma)) {
 			dev_err(ssp->dev,
 				"Cannot send and receive simultaneously\n");
@@ -437,11 +445,11 @@ static int mxs_spi_transfer_one(struct spi_master *master,
 			if (t->tx_buf)
 				status = mxs_spi_txrx_pio(spi, cs,
 						(void *)t->tx_buf,
-						t->len, &first, &last, 1);
+						t->len, flag | TXRX_WRITE);
 			if (t->rx_buf)
 				status = mxs_spi_txrx_pio(spi, cs,
 						t->rx_buf, t->len,
-						&first, &last, 0);
+						flag);
 		} else {
 			writel(BM_SSP_CTRL1_DMA_ENABLE,
 				ssp->base + HW_SSP_CTRL1(ssp) +
@@ -450,11 +458,11 @@ static int mxs_spi_transfer_one(struct spi_master *master,
 			if (t->tx_buf)
 				status = mxs_spi_txrx_dma(spi, cs,
 						(void *)t->tx_buf, t->len,
-						&first, &last, 1);
+						flag | TXRX_WRITE);
 			if (t->rx_buf)
 				status = mxs_spi_txrx_dma(spi, cs,
 						t->rx_buf, t->len,
-						&first, &last, 0);
+						flag);
 		}
 
 		if (status) {
@@ -463,7 +471,6 @@ static int mxs_spi_transfer_one(struct spi_master *master,
 		}
 
 		m->actual_length += t->len;
-		first = last = 0;
 	}
 
 	m->status = status;
-- 
1.7.10.4



From tpiepho at gmail.com  Tue Apr  2 08:19:47 2013
From: tpiepho at gmail.com (Trent Piepho)
Date: Tue,  2 Apr 2013 05:19:47 -0700
Subject: [PATCH V2 04/12] spi/mxs: Fix extra CS pulses and read mode in
 multi-transfer messages
In-Reply-To: <1364905195-24286-1-git-send-email-tpiepho@gmail.com>
References: <1364905195-24286-1-git-send-email-tpiepho@gmail.com>
Message-ID: <1364905195-24286-4-git-send-email-tpiepho@gmail.com>

There are two bits which control the CS line in the CTRL0 register:
LOCK_CS and IGNORE_CRC.  The latter would be better named DEASSERT_CS
in SPI mode.

Setting DEASSERT_CS causes CS to be de-asserted at the end of the
transfer.  It would normally be set on the final segment of the final
transfer.  The DMA code explicitly sets it in this case, but because
it never clears the bit from the ctrl0 register is will remain set for
all transfers in subsequent messages.  This results in a CS pulse
between transfers.

There is a similar problem with the read mode bit never being cleared
in DMA mode.

This patch fixes DEASSERT_CS and READ being left on in DMA mode.

Signed-off-by: Trent Piepho <tpiepho at gmail.com>
Cc: Marek Vasut <marex at denx.de>
Cc: Fabio Estevam <fabio.estevam at freescale.com>
Cc: Shawn Guo <shawn.guo at linaro.org>
---
 drivers/spi/spi-mxs.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/spi/spi-mxs.c b/drivers/spi/spi-mxs.c
index 3064304..86a714b 100644
--- a/drivers/spi/spi-mxs.c
+++ b/drivers/spi/spi-mxs.c
@@ -230,7 +230,8 @@ static int mxs_spi_txrx_dma(struct mxs_spi *spi, int cs,
 	INIT_COMPLETION(spi->c);
 
 	ctrl0 = readl(ssp->base + HW_SSP_CTRL0);
-	ctrl0 &= ~BM_SSP_CTRL0_XFER_COUNT;
+	ctrl0 &= ~(BM_SSP_CTRL0_XFER_COUNT | BM_SSP_CTRL0_IGNORE_CRC |
+		 BM_SSP_CTRL0_READ);
 	ctrl0 |= BM_SSP_CTRL0_DATA_XFER | mxs_spi_cs_to_reg(cs);
 
 	if (!(flags & TXRX_WRITE))
-- 
1.7.10.4



From tpiepho at gmail.com  Tue Apr  2 08:19:48 2013
From: tpiepho at gmail.com (Trent Piepho)
Date: Tue,  2 Apr 2013 05:19:48 -0700
Subject: [PATCH V2 05/12] spi/mxs: Fix chip select control bits in DMA mode
In-Reply-To: <1364905195-24286-1-git-send-email-tpiepho@gmail.com>
References: <1364905195-24286-1-git-send-email-tpiepho@gmail.com>
Message-ID: <1364905195-24286-5-git-send-email-tpiepho@gmail.com>

In DMA mode the chip select control bits would be ORed into the CTRL0
register without first clearing the bits.  This means that after
addressing slave 1 the bit would be still be set when addressing slave
0, resulting in slave 1 continuing to be addressed.

The message handing function would pass the cs value to the txrx
function, which would re-program the bits on each transfer in the
message.  The selected cs does not change during a message so this is
inefficient.  It also means there are two different sets of code for
selecting the CS, one for PIO that worked and one for DMA that didn't.

Change the code to set the CS bits in the message transfer function
once.  Now the DMA and PIO txrx functions don't need to care about CS
at all.

Signed-off-by: Trent Piepho <tpiepho at gmail.com>
Cc: Marek Vasut <marex at denx.de>
Cc: Fabio Estevam <fabio.estevam at freescale.com>
Cc: Shawn Guo <shawn.guo at linaro.org>
---
 drivers/spi/spi-mxs.c |   36 +++++++++++++-----------------------
 1 file changed, 13 insertions(+), 23 deletions(-)

diff --git a/drivers/spi/spi-mxs.c b/drivers/spi/spi-mxs.c
index 86a714b..ad3fd9c 100644
--- a/drivers/spi/spi-mxs.c
+++ b/drivers/spi/spi-mxs.c
@@ -152,18 +152,6 @@ static uint32_t mxs_spi_cs_to_reg(unsigned cs)
 	return select;
 }
 
-static void mxs_spi_set_cs(struct mxs_spi *spi, unsigned cs)
-{
-	const uint32_t mask =
-		BM_SSP_CTRL0_WAIT_FOR_CMD | BM_SSP_CTRL0_WAIT_FOR_IRQ;
-	uint32_t select;
-	struct mxs_ssp *ssp = &spi->ssp;
-
-	writel(mask, ssp->base + HW_SSP_CTRL0 + STMP_OFFSET_REG_CLR);
-	select = mxs_spi_cs_to_reg(cs);
-	writel(select, ssp->base + HW_SSP_CTRL0 + STMP_OFFSET_REG_SET);
-}
-
 static int mxs_ssp_wait(struct mxs_spi *spi, int offset, int mask, bool set)
 {
 	const unsigned long timeout = jiffies + msecs_to_jiffies(SSP_TIMEOUT);
@@ -201,7 +189,7 @@ static irqreturn_t mxs_ssp_irq_handler(int irq, void *dev_id)
 	return IRQ_HANDLED;
 }
 
-static int mxs_spi_txrx_dma(struct mxs_spi *spi, int cs,
+static int mxs_spi_txrx_dma(struct mxs_spi *spi,
 			    unsigned char *buf, int len,
 			    unsigned int flags)
 {
@@ -229,10 +217,11 @@ static int mxs_spi_txrx_dma(struct mxs_spi *spi, int cs,
 
 	INIT_COMPLETION(spi->c);
 
+	/* Chip select was already programmed into CTRL0 */
 	ctrl0 = readl(ssp->base + HW_SSP_CTRL0);
 	ctrl0 &= ~(BM_SSP_CTRL0_XFER_COUNT | BM_SSP_CTRL0_IGNORE_CRC |
 		 BM_SSP_CTRL0_READ);
-	ctrl0 |= BM_SSP_CTRL0_DATA_XFER | mxs_spi_cs_to_reg(cs);
+	ctrl0 |= BM_SSP_CTRL0_DATA_XFER;
 
 	if (!(flags & TXRX_WRITE))
 		ctrl0 |= BM_SSP_CTRL0_READ;
@@ -336,7 +325,7 @@ err_mapped:
 	return ret;
 }
 
-static int mxs_spi_txrx_pio(struct mxs_spi *spi, int cs,
+static int mxs_spi_txrx_pio(struct mxs_spi *spi,
 			    unsigned char *buf, int len,
 			    unsigned int flags)
 {
@@ -346,8 +335,6 @@ static int mxs_spi_txrx_pio(struct mxs_spi *spi, int cs,
 	writel(BM_SSP_CTRL0_IGNORE_CRC,
 	       ssp->base + HW_SSP_CTRL0 + STMP_OFFSET_REG_CLR);
 
-	mxs_spi_set_cs(spi, cs);
-
 	while (len--) {
 		if (len == 0 && (flags & TXRX_DEASSERT_CS))
 			writel(BM_SSP_CTRL0_IGNORE_CRC,
@@ -409,9 +396,12 @@ static int mxs_spi_transfer_one(struct spi_master *master,
 	struct spi_transfer *t, *tmp_t;
 	unsigned int flag;
 	int status = 0;
-	int cs;
 
-	cs = m->spi->chip_select;
+	/* Program CS register bits here, it will be used for all transfers. */
+	writel(BM_SSP_CTRL0_WAIT_FOR_CMD | BM_SSP_CTRL0_WAIT_FOR_IRQ,
+	       ssp->base + HW_SSP_CTRL0 + STMP_OFFSET_REG_CLR);
+	writel(mxs_spi_cs_to_reg(m->spi->chip_select),
+	       ssp->base + HW_SSP_CTRL0 + STMP_OFFSET_REG_SET);
 
 	list_for_each_entry_safe(t, tmp_t, &m->transfers, transfer_list) {
 
@@ -444,11 +434,11 @@ static int mxs_spi_transfer_one(struct spi_master *master,
 				STMP_OFFSET_REG_CLR);
 
 			if (t->tx_buf)
-				status = mxs_spi_txrx_pio(spi, cs,
+				status = mxs_spi_txrx_pio(spi,
 						(void *)t->tx_buf,
 						t->len, flag | TXRX_WRITE);
 			if (t->rx_buf)
-				status = mxs_spi_txrx_pio(spi, cs,
+				status = mxs_spi_txrx_pio(spi,
 						t->rx_buf, t->len,
 						flag);
 		} else {
@@ -457,11 +447,11 @@ static int mxs_spi_transfer_one(struct spi_master *master,
 				STMP_OFFSET_REG_SET);
 
 			if (t->tx_buf)
-				status = mxs_spi_txrx_dma(spi, cs,
+				status = mxs_spi_txrx_dma(spi,
 						(void *)t->tx_buf, t->len,
 						flag | TXRX_WRITE);
 			if (t->rx_buf)
-				status = mxs_spi_txrx_dma(spi, cs,
+				status = mxs_spi_txrx_dma(spi,
 						t->rx_buf, t->len,
 						flag);
 		}
-- 
1.7.10.4



From tpiepho at gmail.com  Tue Apr  2 08:19:49 2013
From: tpiepho at gmail.com (Trent Piepho)
Date: Tue,  2 Apr 2013 05:19:49 -0700
Subject: [PATCH V2 06/12] spi/mxs: Remove full duplex check,
 spi core already does it
In-Reply-To: <1364905195-24286-1-git-send-email-tpiepho@gmail.com>
References: <1364905195-24286-1-git-send-email-tpiepho@gmail.com>
Message-ID: <1364905195-24286-6-git-send-email-tpiepho@gmail.com>

Because the driver sets the SPI_MASTER_HALF_DUPLEX flag, the spi core
will check transfers to insure they are not full duplex.  It's not
necessary to check that in the mxs driver as well.

Signed-off-by: Trent Piepho <tpiepho at gmail.com>
Cc: Marek Vasut <marex at denx.de>
Cc: Fabio Estevam <fabio.estevam at freescale.com>
Cc: Shawn Guo <shawn.guo at linaro.org>
---
 drivers/spi/spi-mxs.c |    6 ------
 1 file changed, 6 deletions(-)

diff --git a/drivers/spi/spi-mxs.c b/drivers/spi/spi-mxs.c
index ad3fd9c..208de97 100644
--- a/drivers/spi/spi-mxs.c
+++ b/drivers/spi/spi-mxs.c
@@ -412,12 +412,6 @@ static int mxs_spi_transfer_one(struct spi_master *master,
 		/* De-assert on last transfer, inverted by cs_change flag */
 		flag = (&t->transfer_list == m->transfers.prev) ^ t->cs_change ?
 		       TXRX_DEASSERT_CS : 0;
-		if ((t->rx_buf && t->tx_buf) || (t->rx_dma && t->tx_dma)) {
-			dev_err(ssp->dev,
-				"Cannot send and receive simultaneously\n");
-			status = -EINVAL;
-			break;
-		}
 
 		/*
 		 * Small blocks can be transfered via PIO.
-- 
1.7.10.4



From tpiepho at gmail.com  Tue Apr  2 08:19:50 2013
From: tpiepho at gmail.com (Trent Piepho)
Date: Tue,  2 Apr 2013 05:19:50 -0700
Subject: [PATCH V2 07/12] spi/mxs: Remove bogus setting of ssp clk rate field
In-Reply-To: <1364905195-24286-1-git-send-email-tpiepho@gmail.com>
References: <1364905195-24286-1-git-send-email-tpiepho@gmail.com>
Message-ID: <1364905195-24286-7-git-send-email-tpiepho@gmail.com>

The ssp struct has a clock rate field, to provide the actual value, in Hz,
of the SSP output clock (the rate of SSP_SCK) after mxs_ssp_set_clk_rate()
is called.  It should be read-only, except for mxs_ssp_set_clk_rate().

For some reason the spi-mxs driver decides to write to this field on init,
and sets it to the value of the SSP input clock (clk_sspN, from the MXS
clocking block) in kHz.  It shouldn't be setting the value, and certainly
shouldn't be setting it with the wrong clock in the wrong units.

Signed-off-by: Trent Piepho <tpiepho at gmail.com>
Cc: Marek Vasut <marex at denx.de>
Cc: Fabio Estevam <fabio.estevam at freescale.com>
Cc: Shawn Guo <shawn.guo at linaro.org>
---
 drivers/spi/spi-mxs.c |    1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/spi/spi-mxs.c b/drivers/spi/spi-mxs.c
index 208de97..103c478 100644
--- a/drivers/spi/spi-mxs.c
+++ b/drivers/spi/spi-mxs.c
@@ -591,7 +591,6 @@ static int mxs_spi_probe(struct platform_device *pdev)
 
 	clk_prepare_enable(ssp->clk);
 	clk_set_rate(ssp->clk, clk_freq);
-	ssp->clk_rate = clk_get_rate(ssp->clk) / 1000;
 
 	stmp_reset_block(ssp->base);
 
-- 
1.7.10.4



From tpiepho at gmail.com  Tue Apr  2 08:19:51 2013
From: tpiepho at gmail.com (Trent Piepho)
Date: Tue,  2 Apr 2013 05:19:51 -0700
Subject: [PATCH V2 08/12] spi/mxs: Fix race in setup method
In-Reply-To: <1364905195-24286-1-git-send-email-tpiepho@gmail.com>
References: <1364905195-24286-1-git-send-email-tpiepho@gmail.com>
Message-ID: <1364905195-24286-8-git-send-email-tpiepho@gmail.com>

Despite many warnings in the SPI documentation and code, the spi-mxs
driver sets shared chip registers in the ->setup method.  This method can
be called when transfers are in progress on other slaves controlled by the
master.  Setting registers or any other shared state will corrupt those
transfers.

So fix mxs_spi_setup() to not call mxs_spi_setup_transfer().

Signed-off-by: Trent Piepho <tpiepho at gmail.com>
Cc: Marek Vasut <marex at denx.de>
Cc: Fabio Estevam <fabio.estevam at freescale.com>
Cc: Shawn Guo <shawn.guo at linaro.org>
---
 drivers/spi/spi-mxs.c |   11 +++--------
 1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/drivers/spi/spi-mxs.c b/drivers/spi/spi-mxs.c
index 103c478..2a2147a 100644
--- a/drivers/spi/spi-mxs.c
+++ b/drivers/spi/spi-mxs.c
@@ -115,21 +115,16 @@ static int mxs_spi_setup_transfer(struct spi_device *dev,
 
 static int mxs_spi_setup(struct spi_device *dev)
 {
-	int err = 0;
-
 	if (!dev->bits_per_word)
 		dev->bits_per_word = 8;
 
 	if (dev->mode & ~(SPI_CPOL | SPI_CPHA))
 		return -EINVAL;
 
-	err = mxs_spi_setup_transfer(dev, NULL);
-	if (err) {
-		dev_err(&dev->dev,
-			"Failed to setup transfer, error = %d\n", err);
-	}
+	if (dev->bits_per_word != 8)
+		return -EINVAL;
 
-	return err;
+	return 0;
 }
 
 static uint32_t mxs_spi_cs_to_reg(unsigned cs)
-- 
1.7.10.4



From tpiepho at gmail.com  Tue Apr  2 08:19:52 2013
From: tpiepho at gmail.com (Trent Piepho)
Date: Tue,  2 Apr 2013 05:19:52 -0700
Subject: [PATCH V2 09/12] spi/mxs: Remove check of spi mode bits
In-Reply-To: <1364905195-24286-1-git-send-email-tpiepho@gmail.com>
References: <1364905195-24286-1-git-send-email-tpiepho@gmail.com>
Message-ID: <1364905195-24286-9-git-send-email-tpiepho@gmail.com>

The spi core already checks for a slave setting mode bits that we
didn't list as supported when the master was registered.  There is no
need to do it again in the master driver.

Signed-off-by: Trent Piepho <tpiepho at gmail.com>
Cc: Marek Vasut <marex at denx.de>
Cc: Fabio Estevam <fabio.estevam at freescale.com>
Cc: Shawn Guo <shawn.guo at linaro.org>
---
 drivers/spi/spi-mxs.c |    3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/spi/spi-mxs.c b/drivers/spi/spi-mxs.c
index 2a2147a..d71029e 100644
--- a/drivers/spi/spi-mxs.c
+++ b/drivers/spi/spi-mxs.c
@@ -118,9 +118,6 @@ static int mxs_spi_setup(struct spi_device *dev)
 	if (!dev->bits_per_word)
 		dev->bits_per_word = 8;
 
-	if (dev->mode & ~(SPI_CPOL | SPI_CPHA))
-		return -EINVAL;
-
 	if (dev->bits_per_word != 8)
 		return -EINVAL;
 
-- 
1.7.10.4



From tpiepho at gmail.com  Tue Apr  2 08:19:53 2013
From: tpiepho at gmail.com (Trent Piepho)
Date: Tue,  2 Apr 2013 05:19:53 -0700
Subject: [PATCH V2 10/12] spi/mxs: Clean up setup_transfer function
In-Reply-To: <1364905195-24286-1-git-send-email-tpiepho@gmail.com>
References: <1364905195-24286-1-git-send-email-tpiepho@gmail.com>
Message-ID: <1364905195-24286-10-git-send-email-tpiepho@gmail.com>

It can't be called with a NULL transfer anymore so it can be
simplified to not check for that.

Change printouts to more closely match what the spi core would print.
I.e., don't print function names.  Try to make them clearer.

Fix indention of line-wrapped code to Linux standard.

The transfer pointer can be const.

It's not necessary to check if the spi_transfer's bit per word is
zero.  The spi core automatically inserts the spi_device's bits per
word in that case.

It's not necessary to check if the spi_transfer's speed_hz is zero, as
the spi core also fills it in from the spi_device.  However, the spi
core does not check if spi_device's speed is zero so we have to do
that still.

Signed-off-by: Trent Piepho <tpiepho at gmail.com>
Cc: Marek Vasut <marex at denx.de>
Cc: Fabio Estevam <fabio.estevam at freescale.com>
Cc: Shawn Guo <shawn.guo at linaro.org>
---
 drivers/spi/spi-mxs.c |   30 +++++++++++-------------------
 1 file changed, 11 insertions(+), 19 deletions(-)

diff --git a/drivers/spi/spi-mxs.c b/drivers/spi/spi-mxs.c
index d71029e..a7d5f85 100644
--- a/drivers/spi/spi-mxs.c
+++ b/drivers/spi/spi-mxs.c
@@ -71,28 +71,20 @@ struct mxs_spi {
 };
 
 static int mxs_spi_setup_transfer(struct spi_device *dev,
-				struct spi_transfer *t)
+				  const struct spi_transfer *t)
 {
 	struct mxs_spi *spi = spi_master_get_devdata(dev->master);
 	struct mxs_ssp *ssp = &spi->ssp;
-	uint8_t bits_per_word;
-	uint32_t hz = 0;
+	const unsigned int hz = min(dev->max_speed_hz, t->speed_hz);
 
-	bits_per_word = dev->bits_per_word;
-	if (t && t->bits_per_word)
-		bits_per_word = t->bits_per_word;
-
-	if (bits_per_word != 8) {
-		dev_err(&dev->dev, "%s, unsupported bits_per_word=%d\n",
-					__func__, bits_per_word);
+	if (t->bits_per_word != 8) {
+		dev_err(&dev->dev, "Unsupported bits per word of %d\n",
+			t->bits_per_word);
 		return -EINVAL;
 	}
 
-	hz = dev->max_speed_hz;
-	if (t && t->speed_hz)
-		hz = min(hz, t->speed_hz);
 	if (hz == 0) {
-		dev_err(&dev->dev, "Cannot continue with zero clock\n");
+		dev_err(&dev->dev, "SPI clock rate of zero not possible\n");
 		return -EINVAL;
 	}
 
@@ -100,12 +92,12 @@ static int mxs_spi_setup_transfer(struct spi_device *dev,
 
 	writel(BM_SSP_CTRL0_LOCK_CS,
 		ssp->base + HW_SSP_CTRL0 + STMP_OFFSET_REG_SET);
+
 	writel(BF_SSP_CTRL1_SSP_MODE(BV_SSP_CTRL1_SSP_MODE__SPI) |
-		     BF_SSP_CTRL1_WORD_LENGTH
-		     (BV_SSP_CTRL1_WORD_LENGTH__EIGHT_BITS) |
-		     ((dev->mode & SPI_CPOL) ? BM_SSP_CTRL1_POLARITY : 0) |
-		     ((dev->mode & SPI_CPHA) ? BM_SSP_CTRL1_PHASE : 0),
-		     ssp->base + HW_SSP_CTRL1(ssp));
+	       BF_SSP_CTRL1_WORD_LENGTH(BV_SSP_CTRL1_WORD_LENGTH__EIGHT_BITS) |
+	       ((dev->mode & SPI_CPOL) ? BM_SSP_CTRL1_POLARITY : 0) |
+	       ((dev->mode & SPI_CPHA) ? BM_SSP_CTRL1_PHASE : 0),
+	       ssp->base + HW_SSP_CTRL1(ssp));
 
 	writel(0x0, ssp->base + HW_SSP_CMD0);
 	writel(0x0, ssp->base + HW_SSP_CMD1);
-- 
1.7.10.4



From tpiepho at gmail.com  Tue Apr  2 08:19:54 2013
From: tpiepho at gmail.com (Trent Piepho)
Date: Tue,  2 Apr 2013 05:19:54 -0700
Subject: [PATCH V2 11/12] spi/mxs: Don't set clock for each xfer
In-Reply-To: <1364905195-24286-1-git-send-email-tpiepho@gmail.com>
References: <1364905195-24286-1-git-send-email-tpiepho@gmail.com>
Message-ID: <1364905195-24286-11-git-send-email-tpiepho@gmail.com>

mxs_spi_setup_transfer() would set the SSP SCK rate every time it was
called, which is before each transfer.  It is uncommon for the SCK rate to
change between transfers and this causes unnecessary reprogramming of the
clock registers.  Changed to only set the rate when it has changed.

This significantly speeds up short SPI messages, especially messages made
up of many transfers.  On an iMX287, using spidev with messages that
consist of 511 transfers of 4 bytes each at an SCK of 48 MHz, the
effective transfer rate more than doubles from about 290 KB/sec to 600
KB/sec.

Signed-off-by: Trent Piepho <tpiepho at gmail.com>
Cc: Marek Vasut <marex at denx.de>
Cc: Fabio Estevam <fabio.estevam at freescale.com>
Cc: Shawn Guo <shawn.guo at linaro.org>
---
 drivers/spi/spi-mxs.c |   15 ++++++++++++++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/drivers/spi/spi-mxs.c b/drivers/spi/spi-mxs.c
index a7d5f85..12794ea 100644
--- a/drivers/spi/spi-mxs.c
+++ b/drivers/spi/spi-mxs.c
@@ -68,6 +68,7 @@
 struct mxs_spi {
 	struct mxs_ssp		ssp;
 	struct completion	c;
+	unsigned int		sck;	/* Rate requested (vs actual) */
 };
 
 static int mxs_spi_setup_transfer(struct spi_device *dev,
@@ -88,7 +89,19 @@ static int mxs_spi_setup_transfer(struct spi_device *dev,
 		return -EINVAL;
 	}
 
-	mxs_ssp_set_clk_rate(ssp, hz);
+	if (hz != spi->sck) {
+		mxs_ssp_set_clk_rate(ssp, hz);
+		/*
+		 * Save requested value, not actual value from ssp->clk_rate.
+		 * Otherwise we would set the rate again each trasfer when
+		 * actual is not quite the same as requested.
+		 */
+		spi->sck = hz;
+		/*
+		 * Perhaps we should return an error if the actual clock is
+		 * nowhere close to what was requested?
+		 */
+	}
 
 	writel(BM_SSP_CTRL0_LOCK_CS,
 		ssp->base + HW_SSP_CTRL0 + STMP_OFFSET_REG_SET);
-- 
1.7.10.4



From tpiepho at gmail.com  Tue Apr  2 08:19:55 2013
From: tpiepho at gmail.com (Trent Piepho)
Date: Tue,  2 Apr 2013 05:19:55 -0700
Subject: [PATCH V2 12/12] spi/mxs: Use u32 instead of uint32_t
In-Reply-To: <1364905195-24286-1-git-send-email-tpiepho@gmail.com>
References: <1364905195-24286-1-git-send-email-tpiepho@gmail.com>
Message-ID: <1364905195-24286-12-git-send-email-tpiepho@gmail.com>

It's consistent with all the other spi drivers that way.

Signed-off-by: Trent Piepho <tpiepho at gmail.com>
Cc: Marek Vasut <marex at denx.de>
Cc: Fabio Estevam <fabio.estevam at freescale.com>
Cc: Shawn Guo <shawn.guo at linaro.org>
---
 drivers/spi/spi-mxs.c |   10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/spi/spi-mxs.c b/drivers/spi/spi-mxs.c
index 12794ea..aafd069 100644
--- a/drivers/spi/spi-mxs.c
+++ b/drivers/spi/spi-mxs.c
@@ -129,9 +129,9 @@ static int mxs_spi_setup(struct spi_device *dev)
 	return 0;
 }
 
-static uint32_t mxs_spi_cs_to_reg(unsigned cs)
+static u32 mxs_spi_cs_to_reg(unsigned cs)
 {
-	uint32_t select = 0;
+	u32 select = 0;
 
 	/*
 	 * i.MX28 Datasheet: 17.10.1: HW_SSP_CTRL0
@@ -153,7 +153,7 @@ static int mxs_ssp_wait(struct mxs_spi *spi, int offset, int mask, bool set)
 {
 	const unsigned long timeout = jiffies + msecs_to_jiffies(SSP_TIMEOUT);
 	struct mxs_ssp *ssp = &spi->ssp;
-	uint32_t reg;
+	u32 reg;
 
 	do {
 		reg = readl_relaxed(ssp->base + offset);
@@ -197,11 +197,11 @@ static int mxs_spi_txrx_dma(struct mxs_spi *spi,
 	const int sgs = DIV_ROUND_UP(len, desc_len);
 	int sg_count;
 	int min, ret;
-	uint32_t ctrl0;
+	u32 ctrl0;
 	struct page *vm_page;
 	void *sg_buf;
 	struct {
-		uint32_t		pio[4];
+		u32			pio[4];
 		struct scatterlist	sg;
 	} *dma_xfer;
 
-- 
1.7.10.4



From tpiepho at gmail.com  Tue Apr  2 08:40:48 2013
From: tpiepho at gmail.com (Trent Piepho)
Date: Tue, 2 Apr 2013 05:40:48 -0700
Subject: [PATCH 1/5] spi/mxs: Fix extra CS pulses and read mode in
 multi-transfer messages
In-Reply-To: <201304021232.12736.marex@denx.de>
References: <1364570381-17605-1-git-send-email-tpiepho@gmail.com>
 <201304020622.52429.marex@denx.de>
 <CA+7tXigvg+5k0Baa12CVwP5Ar7HUsJ8ihB19xrav4CNA6ZMFiA@mail.gmail.com>
 <201304021232.12736.marex@denx.de>
Message-ID: <CA+7tXii8xhZQeKU2dTN26LxySNXhJT9NgRXcJ21cOX64qYj1NA@mail.gmail.com>

On Tue, Apr 2, 2013 at 3:32 AM, Marek Vasut <marex at denx.de> wrote:
>>
>> Don't see anything in CodingStyle that one should be preferred over
>> the other.
>
> There ain't any I'm aware of, but to paraphrase you, let's keep the format
> that's already used in the driver ;-) :
>
> 114         if (dev->mode & ~(SPI_CPOL | SPI_CPHA))

Thanks for pointing that out, as that code can be deleted.  Which
means I don't need to be consistent with it anymore and can create a
new standard, to be followed henceforth, now and forever.

But it looks like the or method is more common in the kernel code.  So
I'll change it in V2.

>> > btw. are you using MX23 or MX28 to test this?
>>
>> IMX28.
>
> Is that any mainline board?

Nope, custom hardware.

>> >> Existing code that uses the first/last flags is wrong and needs to be
>> >> changed.  Therefor code using 'first' and 'last' will be changed.
>> >>
>> >> Passing the flags as pointers is bad practice and makes no sense to
>> >> do.  Does it make any sense to re-write code fix the way it uses first
>> >> and last, then re-write those same lines a second time to not use
>> >> pointers?
>> >
>> > You can always flip it the other way -- first rework the use of flags,
>> > then apply the fix. It'd make the patch much easier to understand, don't
>> > you think?
>>
>> So I should change 'first' to not be a pointer to an integer in one
>> patch, then delete the flag entirely in another patch?
>
> I'd say make a patch (0001) that implements the transition to using your newly
> defined flags and then make a patch (0002) that "Fix extra CS pulses and read
> mode in multi-transfer messages". One patch shall do one thing, that's the usual
> rule of the thumb. Obviously keep them in a series if these patches shall go in
> together. And why doesn't squashing them all together work you might ask --
> because reviewing the result is hard.

5 patches have now been split into 12.


From balbi at ti.com  Tue Apr  2 08:44:07 2013
From: balbi at ti.com (Felipe Balbi)
Date: Tue, 2 Apr 2013 15:44:07 +0300
Subject: [PATCH 1/2] ARM: imx_v6_v7_defconfig: add CONFIG_USB_PHY
In-Reply-To: <20130402111245.GC24039@S2101-09.ap.freescale.net>
References: <1364133966-22373-1-git-send-email-shawn.guo@linaro.org>
 <20130402080706.GC30286@arwen.pp.htv.fi>
 <20130402111245.GC24039@S2101-09.ap.freescale.net>
Message-ID: <20130402124407.GE9488@arwen.pp.htv.fi>

Hi,

On Tue, Apr 02, 2013 at 07:12:47PM +0800, Shawn Guo wrote:
> On Tue, Apr 02, 2013 at 11:07:06AM +0300, Felipe Balbi wrote:
> > On Sun, Mar 24, 2013 at 10:06:04PM +0800, Shawn Guo wrote:
> > > Commit edc7cb2 (usb: phy: make it a menuconfig) makes USB_MXS_PHY
> > > be a sub-item of menuconfig symbol USB_PHY.  This change gets the
> > > selection of CONFIG_USB_MXS_PHY in imx_v6_v7_defconfig lost.  Hence the
> > > boot stops at the point below.
> > > 
> > >   ci_hdrc ci_hdrc.0: doesn't support gadget
> > >   ci_hdrc ci_hdrc.0: EHCI Host Controller
> > >   ci_hdrc ci_hdrc.0: new USB bus registered, assigned bus number 1
> > > 
> > > Add CONFIG_USB_PHY to have the CONFIG_USB_MXS_PHY selection back to
> > > work.
> > > 
> > > Signed-off-by: Shawn Guo <shawn.guo at linaro.org>
> > 
> > should I take this or will Russell queue it during -rc ?
> 
> Though I can send it via arm-soc tree when your patches land on
> mainline, I think the easier way is that you take both patches via
> your tree.

alright, in that case can you rebase on next branch ? patch 2 didn't
apply.

thank you

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130402/b81cf143/attachment.sig>

From prabhakar.csengg at gmail.com  Tue Apr  2 08:45:09 2013
From: prabhakar.csengg at gmail.com (Prabhakar Lad)
Date: Tue, 2 Apr 2013 18:15:09 +0530
Subject: [BUG] mod/file2alias: build error in devicetable-offsets.c [was:
 asm/types.h Header file wont get generated while building uImage ?]
In-Reply-To: <m2ip48d62f.fsf@igel.home>
References: <CA+V-a8vYsBLVH-3Bm35Sv9K9ZMTcMB4_P_V3kBjyuEKDozPi5w@mail.gmail.com>
 <1363949290.3528.37.camel@linaro1.home> <m2ip48d62f.fsf@igel.home>
Message-ID: <CA+V-a8s+Wrt7756gd44e4BtqtHymPN2bFbow0brnEcOWVA1yBQ@mail.gmail.com>

Hi Andreas,

On Sun, Mar 31, 2013 at 1:16 AM, Andreas Schwab <schwab at linux-m68k.org> wrote:
> "Jon Medhurst (Tixy)" <tixy at linaro.org> writes:
>
>> For builds which succeed I see this order:
>>
>>   WRAP    arch/arm/include/generated/asm/types.h
>>   [...]
>>   GEN     include/generated/asm-offsets.h
>>
>> and for those which fail:
>>
>>   CC      scripts/mod/devicetable-offsets.s
>>   In file included from include/linux/types.h:5:0,
>>                    from include/linux/mod_devicetable.h:11,
>>                    from scripts/mod/devicetable-offsets.c:2:
>>   include/uapi/linux/types.h:4:23: fatal error: asm/types.h: No such file or directory
>>   [...]
>>   WRAP    arch/arm/include/generated/asm/types.h
>
> Does that help?
>
> diff --git a/Makefile b/Makefile
> index a5f3203..2a484db 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -512,7 +512,8 @@ ifeq ($(KBUILD_EXTMOD),)
>  # Carefully list dependencies so we do not try to build scripts twice
>  # in parallel
>  PHONY += scripts
> -scripts: scripts_basic include/config/auto.conf include/config/tristate.conf
> +scripts: scripts_basic include/config/auto.conf include/config/tristate.conf \
> +        asm-generic
>         $(Q)$(MAKE) $(build)=$(@)
>
>  # Objects we will link into vmlinux / subdirs we need to visit
>
This works thanks for the patch!

Reported-by: Lad, Prabhakar <prabhakar.csengg at gmail.com>
Tested-by: Lad, Prabhakar <prabhakar.csengg at gmail.com>

Regards,
--Prabhakar

> Andreas.
>
> --
> Andreas Schwab, schwab at linux-m68k.org
> GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
> "And now for something completely different."


From tixy at linaro.org  Tue Apr  2 08:50:37 2013
From: tixy at linaro.org (Jon Medhurst (Tixy))
Date: Tue, 02 Apr 2013 13:50:37 +0100
Subject: RFC: right way to conditional-ize some macros for LTO
In-Reply-To: <5155E28A.30509@am.sony.com>
References: <5155E28A.30509@am.sony.com>
Message-ID: <1364907037.3650.54.camel@linaro1.home>

On Fri, 2013-03-29 at 11:50 -0700, Tim Bird wrote:
> Hi all,
> 
> A while ago I was working on supporting link-time optimization
> for ARM, and I'm just now getting around to submitting some of
> the patches from my work.  I'll explain more below, but the
> executive summary is this: Andi Kleen's LTO patches for Linux
> almost work on ARM.  I ran into one issue in
> arch/arm/include/asm/unified.h where various 'it'-related
> macros are expanding multiple times, in C context, and causing
> build errors.
> 
> As near as I can tell, these macros are not used except by
> arch/arm/kernel/kprobes-test-thumb.c (and most are not used
> at all).
> 
> When compiling with CONFIG_LTO=y, in Andi's 3.7.0 tree with LTO
> patches, I got the messages below:
> -----------------------------------------------
> ...
>   LD      drivers/tty/built-in.o
>   LD      drivers/built-in.o
>   LINK    vmlinux
>   GEN     .version
>   CHK     include/generated/compile.h
>   UPD     include/generated/compile.h
>   CC      init/version.o
>   LD      init/built-in.o
>   LDFINAL vmlinux.o
> [Leaving LTRANS /tmp/ccsIMbQT.args]
> [Leaving LTRANS vmlinux.o.ltrans.out]
> In file included from /a/home/tbird/work/auto-reduce/lto-work/linux-misc-andi-kleen/include/uapi/linux/swab.h:269:0,
>                  from :872:
> /a/home/tbird/work/auto-reduce/lto-work/linux-misc-andi-kleen/crypto/wp512.c: In function 'wp512_process_buffer':
> /a/home/tbird/work/auto-reduce/lto-work/linux-misc-andi-kleen/crypto/wp512.c:987:1: warning: the frame size of 1160 bytes is larger than 1024 bytes [-Wframe-larger-than=]
> vmlinux.o.ltrans0.s: Assembler messages:
> vmlinux.o.ltrans0.s:408: Error: Macro `it' was already defined
> vmlinux.o.ltrans0.s:410: Error: Macro `itt' was already defined
> vmlinux.o.ltrans0.s:412: Error: Macro `ite' was already defined
> vmlinux.o.ltrans0.s:414: Error: Macro `ittt' was already defined
> vmlinux.o.ltrans0.s:416: Error: Macro `itte' was already defined
> vmlinux.o.ltrans0.s:418: Error: Macro `itet' was already defined
> vmlinux.o.ltrans0.s:420: Error: Macro `itee' was already defined
> vmlinux.o.ltrans0.s:422: Error: Macro `itttt' was already defined
> vmlinux.o.ltrans0.s:424: Error: Macro `ittte' was already defined
> vmlinux.o.ltrans0.s:426: Error: Macro `ittet' was already defined
> vmlinux.o.ltrans0.s:428: Error: Macro `ittee' was already defined
> vmlinux.o.ltrans0.s:430: Error: Macro `itett' was already defined
> vmlinux.o.ltrans0.s:432: Error: Macro `itete' was already defined
> vmlinux.o.ltrans0.s:434: Error: Macro `iteet' was already defined
> vmlinux.o.ltrans0.s:436: Error: Macro `iteee' was already defined
> vmlinux.o.ltrans0.s:968: Error: Macro `it' was already defined
> vmlinux.o.ltrans0.s:970: Error: Macro `itt' was already defined
> vmlinux.o.ltrans0.s:972: Error: Macro `ite' was already defined
> vmlinux.o.ltrans0.s:974: Error: Macro `ittt' was already defined
> vmlinux.o.ltrans0.s:976: Error: Macro `itte' was already defined
> ...
> [Leaving LTRANS vmlinux.o.ltrans30.ltrans.o]
> [Leaving LTRANS vmlinux.o.ltrans31.o]
> [Leaving LTRANS vmlinux.o.ltrans31.ltrans.o]
> /a/home/tbird/work/auto-reduce/sony-yocto/lto-build2/tmp/sysroots/x86_64-linux/usr/libexec/armv5te-sony-linux-gnueabi/gcc/arm-sony-linux-gnueabi/4.7.3/arm-sony-linux-gnueabi-ld: lto-wrapper failed
> collect2: error: ld returned 1 exit status
> make[1]: *** [vmlinux] Error 1
> make: *** [sub-make] Error 2
> 
> Error: Bad result 512, running "make -j 8 KALLSYMS_EXTRA_PASS=1 bzImage": (output follows)
> Error:
> ---------------------------------------------
> 
> The messages are repeated thousands of times (I'm guessing for every object
> file after the first that included arch/arm/include/asm/unified.h)
> 
> Recognizing that LTO is currently incompatible with kprobes, and (so far)
> finding that only kprobes appeared to use these macros, I did the following hack:
> 
> diff --git a/arch/arm/include/asm/unified.h b/arch/arm/include/asm/unified.h
> index f5989f4..5179c13 100644
> --- a/arch/arm/include/asm/unified.h
> +++ b/arch/arm/include/asm/unified.h
> @@ -92,6 +92,7 @@
>  	.macro	iteee, cond
>  	.endm
>  #else	/* !__ASSEMBLY__ */
> +#ifndef CONFIG_LTO
>  __asm__(
>  "	.macro	it, cond\n"
>  "	.endm\n"
> @@ -123,6 +124,7 @@ __asm__(
>  "	.endm\n"
>  "	.macro	iteee, cond\n"
>  "	.endm\n");
> +#endif  /* ! CONFIG_LTO */
>  #endif	/* __ASSEMBLY__ */
> 
>  #endif	/* CONFIG_ARM_ASM_UNIFIED */
> 
> This the macros thus removed, I had no problems building the kernel
> and running it on target.
> 
> While this works to remove the build error, it doesn't seem robust and I'd
> like to either 1) find a better way to make these macro definitions conditional,
> or 2) eliminate them completely.
> 
> The macros themselves seem empty.  Can someone tell me what they do?
> What is the status of these macros?  Are they even needed?

The names of the macros are for Thumb2 instructions which are redundant
when building for the ARM instruction set. Newer toolchains which
support the unified assembler syntax will effectively ignore them and I
guess these empty macros are there so people can write assembler which
will compile with older toolchains.

> Could they be
> made conditional on something like NEED_IT_MACROS, and then have that set only
> in the arch/arm/kernel/kprobes-test-thumb.c, before the unified.h is included?

That file needs the real Thumb2 instructions, not empty macros, and
indeed it doesn't use them, because it is only compiled when
CONFIG_THUMB2_KERNEL=y and that selects CONFIG_ARM_ASM_UNIFIED and those
'it' macro's are guarded by #ifndef CONFIG_ARM_ASM_UNIFIED.

Note, there are other files which use the 'it' instructions, e.g.
arch/arm/include/asm/futex.h.

> I would like get this minor issue resolved in mainline, to make it easier for Andi
> to get his LTO work upstream and have it work with ARM.
> 
> Any suggestions are welcome.

If your toolchain supports the unified assembler syntax, you could try
enabling CONFIG_ARM_ASM_UNIFIED in ARM builds.

-- 
Tixy





From simon.guinot at sequanux.org  Tue Apr  2 08:54:11 2013
From: simon.guinot at sequanux.org (Simon Guinot)
Date: Tue, 2 Apr 2013 14:54:11 +0200
Subject: [PATCH] ARM: kirkwood: DT board setup for CloudBox
In-Reply-To: <20130402114535.GR13280@titan.lakedaemon.net>
References: <1364555206-5870-1-git-send-email-simon.guinot@sequanux.org>
 <20130329153132.GJ13280@titan.lakedaemon.net>
 <20130329184109.GA16404@kw.sim.vm.gnt> <51568B89.1060009@free.fr>
 <20130401163316.GC16404@kw.sim.vm.gnt> <515A5BC6.5000007@free.fr>
 <20130402114535.GR13280@titan.lakedaemon.net>
Message-ID: <20130402125408.GH16404@kw.sim.vm.gnt>

On Tue, Apr 02, 2013 at 07:45:35AM -0400, Jason Cooper wrote:
> On Tue, Apr 02, 2013 at 06:17:10AM +0200, Chris Moore wrote:
> > Le 01/04/2013 18:33, Simon Guinot a ?crit :
> ...
> > >The new CloudBox is a very different product which has been first named
> > >FamilyBox and then released under the CloudBox name.
> 
> The question really comes down to, are there *any* differences on the
> _board_?
> 
> If there are hardware differences, we need two dts files and two
> compatibility strings.  Preferably appending the baseline model number
> to each.  If they unwisely chose the same model number, we should append
> '-db' or '-dev-board' to the compatibility string of the first board.
> 
> Although, in this case, there is a netspace_mini_v2 already in the
> kernel (kirkwood-ns2mini.dts).  Is this the development version you were
> speaking of?

I think that I am not clear in my explanations :)

There is two different LaCie boards. There is no relations between this
boards except their final product name (which is quite silly).

From a LaCie point, there is no board but only product naming. Here are
the different names used by LaCie for this two boards/products:

1: netspace_mini_v2 -> SafeBox -> CloudBox
2: FamilyBox -> CloudBox

"1" is the oldest board.

Under Linux, with my patch we are using the following names:

1: netspace_mini_v2
2: cloudbox

The problem raised by Chris is that the cloudbox name could be
confusing because one could try a "cloudbox" dtb on the board "1". For
my part I don't think it is an issue because "1" is rather confidential
(and it is an euphemism). It would be more confusing for users if the
kernel name for "2" is not cloudbox but cloudbox_{color,number,...} or
even familybox. Moreover netspace_mini_v2 is a correct name for "1".

IMHO, we could let things as they are. Additionally, I could either
extend the Kconfig description and add a some comments in the dts files,
in order to to prevent any misunderstanding...

Let me know if you agree or not.

Thanks.

Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130402/91320f80/attachment.sig>

From rui.zhang at intel.com  Tue Apr  2 09:05:10 2013
From: rui.zhang at intel.com (Zhang Rui)
Date: Tue, 02 Apr 2013 21:05:10 +0800
Subject: [PATCH v2 1/4] thermal: Add driver for Armada 370/XP SoC
 thermal management
In-Reply-To: <20130402013740.GA28373@localhost>
References: <1364292988-8358-1-git-send-email-ezequiel.garcia@free-electrons.com>
 <1364292988-8358-2-git-send-email-ezequiel.garcia@free-electrons.com>
 <1364435017.2275.20.camel@rzhang1-mobl4> <20130402013740.GA28373@localhost>
Message-ID: <1364907910.2190.37.camel@rzhang1-mobl4>

On Mon, 2013-04-01 at 22:37 -0300, Ezequiel Garcia wrote:
> Hi Zhang,
> 
> On Thu, Mar 28, 2013 at 09:43:37AM +0800, Zhang Rui wrote:
> > On Tue, 2013-03-26 at 07:16 -0300, Ezequiel Garcia wrote:
> > > This driver supports both Armada 370 and Armada XP SoC
> > > thermal management controllers.
> > > 
> > > Armada 370 has a register to check a valid temperature, whereas
> > > Armada XP does not. Each has a different initialization (i.e. calibration)
> > > function. The temperature conversion formula is the same for both.
> > > 
> > > The controller present in each SoC have a very similar feature set,
> > > so it corresponds to have one driver to support both of them.
> > > 
> > > Although this driver may present similarities to Dove and Kirkwood
> > > thermal driver, the exact differences and coincidences are not fully
> > > known. For this reason, support is given through a separate driver.
> > > 
> > > Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>

patch applied.

thanks,
rui
> > > ---
> 
> [...]
> 
> > > +static void armadaxp_init_sensor(struct armada_thermal_priv *priv)
> > > +{
> > > +	unsigned long reg;
> > > +
> > > +	/* ??? */
> > 
> > what does this comment mean?
> > 
> 
> In the case you'd prefer those comments to be removed,
> here's a patch that does just that.
> 
> Is it possible for you to take it instead of the previous one,
> in this form?
> 
> ------------------------------------8<----------------------------------------
> diff --git a/Documentation/devicetree/bindings/thermal/armada-thermal.txt b/Documentation/devicetree/bindings/thermal/armada-thermal.txt
> new file mode 100644
> index 0000000..fff93d5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/thermal/armada-thermal.txt
> @@ -0,0 +1,22 @@
> +* Marvell Armada 370/XP thermal management
> +
> +Required properties:
> +
> +- compatible:	Should be set to one of the following:
> +		marvell,armada370-thermal
> +		marvell,armadaxp-thermal
> +
> +- reg:		Device's register space.
> +		Two entries are expected, see the examples below.
> +		The first one is required for the sensor register;
> +		the second one is required for the control register
> +		to be used for sensor initialization (a.k.a. calibration).
> +
> +Example:
> +
> +	thermal at d0018300 {
> +		compatible = "marvell,armada370-thermal";
> +                reg = <0xd0018300 0x4
> +		       0xd0018304 0x4>;
> +		status = "okay";
> +	};
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> index a764f16..9eddf74 100644
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -144,6 +144,14 @@ config DB8500_THERMAL
>  	  created. Cooling devices can be bound to the trip points to cool this
>  	  thermal zone if trip points reached.
>  
> +config ARMADA_THERMAL
> +	tristate "Armada 370/XP thermal management"
> +	depends on ARCH_MVEBU
> +	depends on OF
> +	help
> +	  Enable this option if you want to have support for thermal management
> +	  controller present in Armada 370 and Armada XP SoC.
> +
>  config DB8500_CPUFREQ_COOLING
>  	tristate "DB8500 cpufreq cooling"
>  	depends on ARCH_U8500
> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
> index d3a2b38..7f6509a 100644
> --- a/drivers/thermal/Makefile
> +++ b/drivers/thermal/Makefile
> @@ -19,6 +19,7 @@ obj-$(CONFIG_KIRKWOOD_THERMAL)  += kirkwood_thermal.o
>  obj-$(CONFIG_EXYNOS_THERMAL)	+= exynos_thermal.o
>  obj-$(CONFIG_DOVE_THERMAL)  	+= dove_thermal.o
>  obj-$(CONFIG_DB8500_THERMAL)	+= db8500_thermal.o
> +obj-$(CONFIG_ARMADA_THERMAL)	+= armada_thermal.o
>  obj-$(CONFIG_DB8500_CPUFREQ_COOLING)	+= db8500_cpufreq_cooling.o
>  obj-$(CONFIG_INTEL_POWERCLAMP)	+= intel_powerclamp.o
>  
> diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
> new file mode 100644
> index 0000000..5b4d75f
> --- /dev/null
> +++ b/drivers/thermal/armada_thermal.c
> @@ -0,0 +1,232 @@
> +/*
> + * Marvell Armada 370/XP thermal sensor driver
> + *
> + * Copyright (C) 2013 Marvell
> + *
> + * This software is licensed under the terms of the GNU General Public
> + * License version 2, as published by the Free Software Foundation, and
> + * may be copied, distributed, and modified under those terms.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + */
> +#include <linux/device.h>
> +#include <linux/err.h>
> +#include <linux/io.h>
> +#include <linux/kernel.h>
> +#include <linux/of.h>
> +#include <linux/module.h>
> +#include <linux/delay.h>
> +#include <linux/platform_device.h>
> +#include <linux/of_device.h>
> +#include <linux/thermal.h>
> +
> +#define THERMAL_VALID_OFFSET		9
> +#define THERMAL_VALID_MASK		0x1
> +#define THERMAL_TEMP_OFFSET		10
> +#define THERMAL_TEMP_MASK		0x1ff
> +
> +/* Thermal Manager Control and Status Register */
> +#define PMU_TDC0_SW_RST_MASK		(0x1 << 1)
> +#define PMU_TM_DISABLE_OFFS		0
> +#define PMU_TM_DISABLE_MASK		(0x1 << PMU_TM_DISABLE_OFFS)
> +#define PMU_TDC0_REF_CAL_CNT_OFFS	11
> +#define PMU_TDC0_REF_CAL_CNT_MASK	(0x1ff << PMU_TDC0_REF_CAL_CNT_OFFS)
> +#define PMU_TDC0_OTF_CAL_MASK		(0x1 << 30)
> +#define PMU_TDC0_START_CAL_MASK		(0x1 << 25)
> +
> +struct armada_thermal_ops;
> +
> +/* Marvell EBU Thermal Sensor Dev Structure */
> +struct armada_thermal_priv {
> +	void __iomem *sensor;
> +	void __iomem *control;
> +	struct armada_thermal_ops *ops;
> +};
> +
> +struct armada_thermal_ops {
> +	/* Initialize the sensor */
> +	void (*init_sensor)(struct armada_thermal_priv *);
> +
> +	/* Test for a valid sensor value (optional) */
> +	bool (*is_valid)(struct armada_thermal_priv *);
> +};
> +
> +static void armadaxp_init_sensor(struct armada_thermal_priv *priv)
> +{
> +	unsigned long reg;
> +
> +	reg = readl_relaxed(priv->control);
> +	reg |= PMU_TDC0_OTF_CAL_MASK;
> +	writel(reg, priv->control);
> +
> +	/* Reference calibration value */
> +	reg &= ~PMU_TDC0_REF_CAL_CNT_MASK;
> +	reg |= (0xf1 << PMU_TDC0_REF_CAL_CNT_OFFS);
> +	writel(reg, priv->control);
> +
> +	/* Reset the sensor */
> +	reg = readl_relaxed(priv->control);
> +	writel((reg | PMU_TDC0_SW_RST_MASK), priv->control);
> +
> +	writel(reg, priv->control);
> +
> +	/* Enable the sensor */
> +	reg = readl_relaxed(priv->sensor);
> +	reg &= ~PMU_TM_DISABLE_MASK;
> +	writel(reg, priv->sensor);
> +}
> +
> +static void armada370_init_sensor(struct armada_thermal_priv *priv)
> +{
> +	unsigned long reg;
> +
> +	reg = readl_relaxed(priv->control);
> +	reg |= PMU_TDC0_OTF_CAL_MASK;
> +	writel(reg, priv->control);
> +
> +	/* Reference calibration value */
> +	reg &= ~PMU_TDC0_REF_CAL_CNT_MASK;
> +	reg |= (0xf1 << PMU_TDC0_REF_CAL_CNT_OFFS);
> +	writel(reg, priv->control);
> +
> +	reg &= ~PMU_TDC0_START_CAL_MASK;
> +	writel(reg, priv->control);
> +
> +	mdelay(10);
> +}
> +
> +static bool armada_is_valid(struct armada_thermal_priv *priv)
> +{
> +	unsigned long reg = readl_relaxed(priv->sensor);
> +
> +	return (reg >> THERMAL_VALID_OFFSET) & THERMAL_VALID_MASK;
> +}
> +
> +static int armada_get_temp(struct thermal_zone_device *thermal,
> +			  unsigned long *temp)
> +{
> +	struct armada_thermal_priv *priv = thermal->devdata;
> +	unsigned long reg;
> +
> +	/* Valid check */
> +	if (priv->ops->is_valid && !priv->ops->is_valid(priv)) {
> +		dev_err(&thermal->device,
> +			"Temperature sensor reading not valid\n");
> +		return -EIO;
> +	}
> +
> +	reg = readl_relaxed(priv->sensor);
> +	reg = (reg >> THERMAL_TEMP_OFFSET) & THERMAL_TEMP_MASK;
> +	*temp = (3153000000UL - (10000000UL*reg)) / 13825;
> +	return 0;
> +}
> +
> +static struct thermal_zone_device_ops ops = {
> +	.get_temp = armada_get_temp,
> +};
> +
> +static const struct armada_thermal_ops armadaxp_ops = {
> +	.init_sensor = armadaxp_init_sensor,
> +};
> +
> +static const struct armada_thermal_ops armada370_ops = {
> +	.is_valid = armada_is_valid,
> +	.init_sensor = armada370_init_sensor,
> +};
> +
> +static const struct of_device_id armada_thermal_id_table[] = {
> +	{
> +		.compatible = "marvell,armadaxp-thermal",
> +		.data       = &armadaxp_ops,
> +	},
> +	{
> +		.compatible = "marvell,armada370-thermal",
> +		.data       = &armada370_ops,
> +	},
> +	{
> +		/* sentinel */
> +	},
> +};
> +MODULE_DEVICE_TABLE(of, armada_thermal_id_table);
> +
> +static int armada_thermal_probe(struct platform_device *pdev)
> +{
> +	struct thermal_zone_device *thermal;
> +	const struct of_device_id *match;
> +	struct armada_thermal_priv *priv;
> +	struct resource *res;
> +
> +	match = of_match_device(armada_thermal_id_table, &pdev->dev);
> +	if (!match)
> +		return -ENODEV;
> +
> +	priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
> +	if (!priv)
> +		return -ENOMEM;
> +
> +	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +	if (!res) {
> +		dev_err(&pdev->dev, "Failed to get platform resource\n");
> +		return -ENODEV;
> +	}
> +
> +	priv->sensor = devm_ioremap_resource(&pdev->dev, res);
> +	if (IS_ERR(priv->sensor))
> +		return PTR_ERR(priv->sensor);
> +
> +	res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> +	if (!res) {
> +		dev_err(&pdev->dev, "Failed to get platform resource\n");
> +		return -ENODEV;
> +	}
> +
> +	priv->control = devm_ioremap_resource(&pdev->dev, res);
> +	if (IS_ERR(priv->control))
> +		return PTR_ERR(priv->control);
> +
> +	priv->ops = (struct armada_thermal_ops *)match->data;
> +	priv->ops->init_sensor(priv);
> +
> +	thermal = thermal_zone_device_register("armada_thermal", 0, 0,
> +					       priv, &ops, NULL, 0, 0);
> +	if (IS_ERR(thermal)) {
> +		dev_err(&pdev->dev,
> +			"Failed to register thermal zone device\n");
> +		return PTR_ERR(thermal);
> +	}
> +
> +	platform_set_drvdata(pdev, thermal);
> +
> +	return 0;
> +}
> +
> +static int armada_thermal_exit(struct platform_device *pdev)
> +{
> +	struct thermal_zone_device *armada_thermal =
> +		platform_get_drvdata(pdev);
> +
> +	thermal_zone_device_unregister(armada_thermal);
> +	platform_set_drvdata(pdev, NULL);
> +
> +	return 0;
> +}
> +
> +static struct platform_driver armada_thermal_driver = {
> +	.probe = armada_thermal_probe,
> +	.remove = armada_thermal_exit,
> +	.driver = {
> +		.name = "armada_thermal",
> +		.owner = THIS_MODULE,
> +		.of_match_table = of_match_ptr(armada_thermal_id_table),
> +	},
> +};
> +
> +module_platform_driver(armada_thermal_driver);
> +
> +MODULE_AUTHOR("Ezequiel Garcia <ezequiel.garcia at free-electrons.com>");
> +MODULE_DESCRIPTION("Armada 370/XP thermal driver");
> +MODULE_LICENSE("GPL v2");
> ------------------------------------>8----------------------------------------
> 




From nicolas.ferre at atmel.com  Tue Apr  2 09:06:47 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Tue, 2 Apr 2013 15:06:47 +0200
Subject: [RFC PATCH] rtc: rtc-at91rm9200: manage IMR depending on revision
In-Reply-To: <1364573029-19346-5-git-send-email-jhovold@gmail.com>
References: <1364573029-19346-5-git-send-email-jhovold@gmail.com>
Message-ID: <1364908007-5150-1-git-send-email-nicolas.ferre@atmel.com>

Signed-off-by: Nicolas Ferre <nicolas.ferre at atmel.com>
---
Hi all,

The funny thing is that I was writing exactly the same code as Johan's
when he posted his series.

So, here is my single patch, with the comment about the readback stolen from
Johan's, but without the way to determine with IP is buggy and which one is
not...
After having dug the possibility to read the IP revision, I discovered that it
is not possible to use this information ("version" register offset changing
according to... IP version number: well done!).
In conclusion, I guess that the only way to determine if we need the workaround
is to use the DT.
One remark though: if we use the compatibility string for this purpose, I fear
that we would twist the meaning of this information: SoC using an
"atmel,at91sam9x5-rtc" compatible RTC will not necessarily be touched by the
"non responding IMR" bug: at91sam9n12 or upcoming sama5d3 are not affected for
instance, and we need to cling to "atmel,at91rm9200-rtc" for them...
I think that we can use this method for the moment and move to another
compatibility string later if it is needed.

Thanks for your help, best regards.

 drivers/rtc/rtc-at91rm9200.c | 75 ++++++++++++++++++++++++++++++++++++++++++++
 drivers/rtc/rtc-at91rm9200.h |  1 +
 2 files changed, 76 insertions(+)

diff --git a/drivers/rtc/rtc-at91rm9200.c b/drivers/rtc/rtc-at91rm9200.c
index 29b92e4..4960d42 100644
--- a/drivers/rtc/rtc-at91rm9200.c
+++ b/drivers/rtc/rtc-at91rm9200.c
@@ -25,6 +25,7 @@
 #include <linux/rtc.h>
 #include <linux/bcd.h>
 #include <linux/interrupt.h>
+#include <linux/spinlock.h>
 #include <linux/ioctl.h>
 #include <linux/completion.h>
 #include <linux/io.h>
@@ -47,6 +48,74 @@ static unsigned int at91_alarm_year = AT91_RTC_EPOCH;
 static void __iomem *at91_rtc_regs;
 static int irq;
 static u32 at91_rtc_imr;
+static DEFINE_SPINLOCK(lock);
+static void (*at91_rtc_set_irq)(u32 irq_mask);
+static void (*at91_rtc_clear_irq)(u32 irq_mask);
+static u32 (*at91_rtc_read_imr)(void);
+
+static inline unsigned int at91_rtc_get_version(void)
+{
+	return at91_rtc_read(AT91_RTC_VERSION) & 0x00000fff;
+}
+
+static void at91_rtc_set_irq_simple(u32 irq_mask)
+{
+	at91_rtc_write(AT91_RTC_IER, irq_mask);
+}
+
+static void at91_rtc_clear_irq_simple(u32 irq_mask)
+{
+	at91_rtc_write(AT91_RTC_IDR, irq_mask);
+}
+
+static u32 at91_rtc_read_imr_simple(void)
+{
+	return at91_rtc_read(AT91_RTC_IMR);
+}
+
+static void at91_rtc_set_irq_brokenimr(u32 irq_mask)
+{
+	unsigned long flags;
+
+	spin_lock_irqsave(&lock, flags);
+	at91_rtc_imr |= irq_mask;
+	at91_rtc_write(AT91_RTC_IER, irq_mask);
+	spin_unlock_irqrestore(&lock, flags);
+}
+
+static void at91_rtc_clear_irq_brokenimr(u32 irq_mask)
+{
+	unsigned long flags;
+
+	spin_lock_irqsave(&lock, flags);
+	at91_rtc_write(AT91_RTC_IDR, irq_mask);
+	/*
+	 * Register read back (of any RTC-register) needed to make sure
+	 * IDR-register write has reached the peripheral before updating
+	 * shadow mask.
+	 *
+	 * Note that there is still a possibility that the mask is updated
+	 * before interrupts have actually been disabled in hardware. The only
+	 * way to be certain would be to poll the IMR-register, which is is
+	 * the very register we are trying to emulate. The register read back
+	 * is a reasonable heuristic.
+	 */
+	at91_rtc_read(AT91_RTC_SR);
+	at91_rtc_imr &= ~irq_mask;
+	spin_unlock_irqrestore(&lock, flags);
+}
+
+static u32 at91_rtc_read_imr_brokenimr(void)
+{
+	unsigned long flags;
+	u32 shadow_imr;
+
+	spin_lock_irqsave(&lock, flags);
+	shadow_imr = at91_rtc_imr;
+	spin_unlock_irqrestore(&lock, flags);
+
+	return shadow_imr;
+}
 
 /*
  * Decode time/date into rtc_time structure
@@ -300,6 +369,12 @@ static int __init at91_rtc_probe(struct platform_device *pdev)
 					AT91_RTC_SECEV | AT91_RTC_TIMEV |
 					AT91_RTC_CALEV);
 	at91_rtc_imr = 0;
+	spin_lock_init(&lock);
+
+	/* Choose IMR access functions */
+	at91_rtc_set_irq = at91_rtc_set_irq_simple;
+	at91_rtc_clear_irq = at91_rtc_clear_irq_simple;
+	at91_rtc_read_imr = at91_rtc_read_imr_simple;
 
 	ret = request_irq(irq, at91_rtc_interrupt,
 				IRQF_SHARED,
diff --git a/drivers/rtc/rtc-at91rm9200.h b/drivers/rtc/rtc-at91rm9200.h
index 5f940b6..da1945e 100644
--- a/drivers/rtc/rtc-at91rm9200.h
+++ b/drivers/rtc/rtc-at91rm9200.h
@@ -64,6 +64,7 @@
 #define	AT91_RTC_SCCR		0x1c			/* Status Clear Command Register */
 #define	AT91_RTC_IER		0x20			/* Interrupt Enable Register */
 #define	AT91_RTC_IDR		0x24			/* Interrupt Disable Register */
+#define	AT91_RTC_IMR		0x28			/* Interrupt Mask Register */
 
 #define	AT91_RTC_VER		0x2c			/* Valid Entry Register */
 #define		AT91_RTC_NVTIM		(1 <<  0)		/* Non valid Time */
-- 
1.8.0



From s.nawrocki at samsung.com  Tue Apr  2 09:08:07 2013
From: s.nawrocki at samsung.com (Sylwester Nawrocki)
Date: Tue, 02 Apr 2013 15:08:07 +0200
Subject: [PATCH 10/23] [media] exynos: remove unnecessary header inclusions
In-Reply-To: <1362505353-8873-11-git-send-email-arnd@arndb.de>
References: <1362505353-8873-1-git-send-email-arnd@arndb.de>
 <1362505353-8873-11-git-send-email-arnd@arndb.de>
Message-ID: <515AD837.1060106@samsung.com>

On 03/05/2013 06:42 PM, Arnd Bergmann wrote:
> In multiplatform configurations, we cannot include headers
> provided by only the exynos platform. Fortunately a number
> of drivers that include those headers do not actually need
> them, so we can just remove the inclusions.
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> ---
>  drivers/media/platform/exynos-gsc/gsc-regs.c | 1 -
>  drivers/media/platform/s5p-tv/sii9234_drv.c  | 3 ---

Cc: linux-media at vger.kernel.org

Thanks Arnd. I have applied this patch to my tree for 3.10.

>  2 files changed, 4 deletions(-)
> 
> diff --git a/drivers/media/platform/exynos-gsc/gsc-regs.c b/drivers/media/platform/exynos-gsc/gsc-regs.c
> index 6f5b5a4..e22d147 100644
> --- a/drivers/media/platform/exynos-gsc/gsc-regs.c
> +++ b/drivers/media/platform/exynos-gsc/gsc-regs.c
> @@ -12,7 +12,6 @@
>  
>  #include <linux/io.h>
>  #include <linux/delay.h>
> -#include <mach/map.h>
>  
>  #include "gsc-core.h"
>  
> diff --git a/drivers/media/platform/s5p-tv/sii9234_drv.c b/drivers/media/platform/s5p-tv/sii9234_drv.c
> index d90d228..39b77d2 100644
> --- a/drivers/media/platform/s5p-tv/sii9234_drv.c
> +++ b/drivers/media/platform/s5p-tv/sii9234_drv.c
> @@ -23,9 +23,6 @@
>  #include <linux/regulator/machine.h>
>  #include <linux/slab.h>
>  
> -#include <mach/gpio.h>
> -#include <plat/gpio-cfg.h>
> -
>  #include <media/sii9234.h>
>  #include <media/v4l2-subdev.h>

--

Regards,
Sylwester


From prabhakar.csengg at gmail.com  Tue Apr  2 09:15:02 2013
From: prabhakar.csengg at gmail.com (Prabhakar lad)
Date: Tue,  2 Apr 2013 18:45:02 +0530
Subject: [PATCH v7 0/2] ARM: davinci: dm355: add support for vpbe display
Message-ID: <1364908504-14232-1-git-send-email-prabhakar.csengg@gmail.com>

From: Lad, Prabhakar <prabhakar.csengg at gmail.com>

This patch series enables VPBE display driver on DM355.

This patch series is dependent on VPSS clock cleanup patches
(http://www.mail-archive.com/davinci-linux-open-source at linux.davincidsp.com/msg25613.html)
posted.

Changes for v7:
1: Fixed nits pointed by Sekhar for DM365 series.

Changes for v6:
1: Fixed nits pointed by Sekhar.

Changes for v5:
1: Rebased on 3.9, fix review comments pointed by Sekhar for DM365 series.

Changes for v4:
1: pass different platform names to handle different ip's.

Changes for v3:
1: Replaced obsolete preset API by timings API.

Changes for v2:
1: Removed VPSS clock alias for master and slave which was
   sent for VPSS driver. since this patch was dependent on
   patch[1]. I will revist this patch once MC(captrure driver)
   goes into mainline.
[1] http://www.spinics.net/lists/linux-media/msg50562.html

Lad, Prabhakar (2):
  ARM: davinci: dm355: add support for v4l2 video display
  ARM: davinci: dm355 EVM: add support for VPBE display

 arch/arm/mach-davinci/board-dm355-evm.c |   71 ++++++++++++-
 arch/arm/mach-davinci/davinci.h         |    3 +-
 arch/arm/mach-davinci/dm355.c           |  173 ++++++++++++++++++++++++++++++-
 3 files changed, 239 insertions(+), 8 deletions(-)

-- 
1.7.4.1



From prabhakar.csengg at gmail.com  Tue Apr  2 09:15:03 2013
From: prabhakar.csengg at gmail.com (Prabhakar lad)
Date: Tue,  2 Apr 2013 18:45:03 +0530
Subject: [PATCH v7 1/2] ARM: davinci: dm355: add support for v4l2 video display
In-Reply-To: <1364908504-14232-1-git-send-email-prabhakar.csengg@gmail.com>
References: <1364908504-14232-1-git-send-email-prabhakar.csengg@gmail.com>
Message-ID: <1364908504-14232-2-git-send-email-prabhakar.csengg@gmail.com>

From: Lad, Prabhakar <prabhakar.csengg at gmail.com>

Create platform devices for various video modules like venc,osd,
vpbe and v4l2 driver for dm355.

Signed-off-by: Lad, Prabhakar <prabhakar.csengg at gmail.com>
---
 arch/arm/mach-davinci/board-dm355-evm.c |    4 +-
 arch/arm/mach-davinci/davinci.h         |    3 +-
 arch/arm/mach-davinci/dm355.c           |  173 ++++++++++++++++++++++++++++++-
 3 files changed, 172 insertions(+), 8 deletions(-)

diff --git a/arch/arm/mach-davinci/board-dm355-evm.c b/arch/arm/mach-davinci/board-dm355-evm.c
index 147b8e1..37d12cc 100644
--- a/arch/arm/mach-davinci/board-dm355-evm.c
+++ b/arch/arm/mach-davinci/board-dm355-evm.c
@@ -253,8 +253,6 @@ static struct davinci_uart_config uart_config __initdata = {
 
 static void __init dm355_evm_map_io(void)
 {
-	/* setup input configuration for VPFE input devices */
-	dm355_set_vpfe_config(&vpfe_cfg);
 	dm355_init();
 }
 
@@ -344,6 +342,8 @@ static __init void dm355_evm_init(void)
 	davinci_setup_mmc(0, &dm355evm_mmc_config);
 	davinci_setup_mmc(1, &dm355evm_mmc_config);
 
+	dm355_init_video(&vpfe_cfg, NULL);
+
 	dm355_init_spi0(BIT(0), dm355_evm_spi_info,
 			ARRAY_SIZE(dm355_evm_spi_info));
 
diff --git a/arch/arm/mach-davinci/davinci.h b/arch/arm/mach-davinci/davinci.h
index a9de512..5402592 100644
--- a/arch/arm/mach-davinci/davinci.h
+++ b/arch/arm/mach-davinci/davinci.h
@@ -39,6 +39,7 @@
 #define SYSMOD_VDAC_CONFIG		0x2c
 #define SYSMOD_VIDCLKCTL		0x38
 #define SYSMOD_VPSS_CLKCTL		0x44
+#define VPSS_MUXSEL_EXTCLK_ENABLE	BIT(1)
 #define VPSS_VENCCLKEN_ENABLE		BIT(3)
 #define VPSS_DACCLKEN_ENABLE		BIT(4)
 #define VPSS_PLLC2SYSCLK5_ENABLE	BIT(5)
@@ -79,7 +80,7 @@ void __init dm355_init(void);
 void dm355_init_spi0(unsigned chipselect_mask,
 		const struct spi_board_info *info, unsigned len);
 void __init dm355_init_asp1(u32 evt_enable, struct snd_platform_data *pdata);
-void dm355_set_vpfe_config(struct vpfe_config *cfg);
+int __init dm355_init_video(struct vpfe_config *, struct vpbe_config *);
 
 /* DM365 function declarations */
 void __init dm365_init(void);
diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index 8e98bb0..174ad02 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -36,6 +36,10 @@
 
 #define DM355_UART2_BASE	(IO_PHYS + 0x206000)
 
+#define DM355_OSD_BASE			0x01c70200
+
+#define DM355_VENC_BASE			0x01c70400
+
 /*
  * Device specific clocks
  */
@@ -744,11 +748,150 @@ static struct platform_device vpfe_capture_dev = {
 	},
 };
 
-void dm355_set_vpfe_config(struct vpfe_config *cfg)
+static struct resource dm355_osd_resources[] = {
+	{
+		.start	= DM355_OSD_BASE,
+		.end	= DM355_OSD_BASE + 0x17f,
+		.flags	= IORESOURCE_MEM,
+	},
+};
+
+static struct platform_device dm355_osd_dev = {
+	.name		= DM355_VPBE_OSD_SUBDEV_NAME,
+	.id		= -1,
+	.num_resources	= ARRAY_SIZE(dm355_osd_resources),
+	.resource	= dm355_osd_resources,
+	.dev		= {
+		.dma_mask		= &vpfe_capture_dma_mask,
+		.coherent_dma_mask	= DMA_BIT_MASK(32),
+	},
+};
+
+static struct resource dm355_venc_resources[] = {
+	{
+		.start	= IRQ_VENCINT,
+		.end	= IRQ_VENCINT,
+		.flags	= IORESOURCE_IRQ,
+	},
+	/* venc registers io space */
+	{
+		.start	= DM355_VENC_BASE,
+		.end	= DM355_VENC_BASE + 0x17f,
+		.flags	= IORESOURCE_MEM,
+	},
+	/* VDAC config register io space */
+	{
+		.start	= DAVINCI_SYSTEM_MODULE_BASE + SYSMOD_VDAC_CONFIG,
+		.end	= DAVINCI_SYSTEM_MODULE_BASE + SYSMOD_VDAC_CONFIG + 3,
+		.flags	= IORESOURCE_MEM,
+	},
+};
+
+static struct resource dm355_v4l2_disp_resources[] = {
+	{
+		.start	= IRQ_VENCINT,
+		.end	= IRQ_VENCINT,
+		.flags	= IORESOURCE_IRQ,
+	},
+	/* venc registers io space */
+	{
+		.start	= DM355_VENC_BASE,
+		.end	= DM355_VENC_BASE + 0x17f,
+		.flags	= IORESOURCE_MEM,
+	},
+};
+
+static int dm355_vpbe_setup_pinmux(enum v4l2_mbus_pixelcode if_type,
+			    int field)
 {
-	vpfe_capture_dev.dev.platform_data = cfg;
+	switch (if_type) {
+	case V4L2_MBUS_FMT_SGRBG8_1X8:
+		davinci_cfg_reg(DM355_VOUT_FIELD_G70);
+		break;
+
+	case V4L2_MBUS_FMT_YUYV10_1X20:
+		if (field)
+			davinci_cfg_reg(DM355_VOUT_FIELD);
+		else
+			davinci_cfg_reg(DM355_VOUT_FIELD_G70);
+		break;
+
+	default:
+		return -EINVAL;
+	}
+
+	davinci_cfg_reg(DM355_VOUT_COUTL_EN);
+	davinci_cfg_reg(DM355_VOUT_COUTH_EN);
+
+	return 0;
+}
+
+static int dm355_venc_setup_clock(enum vpbe_enc_timings_type type,
+				   unsigned int pclock)
+{
+	void __iomem *vpss_clk_ctrl_reg;
+
+	vpss_clk_ctrl_reg = DAVINCI_SYSMOD_VIRT(SYSMOD_VPSS_CLKCTL);
+
+	switch (type) {
+	case VPBE_ENC_STD:
+		writel(VPSS_DACCLKEN_ENABLE |
+		       VPSS_VENCCLKEN_ENABLE, vpss_clk_ctrl_reg);
+		break;
+
+	case VPBE_ENC_DV_TIMINGS:
+		if (pclock > 27000000)
+			/*
+			 * For HD, use external clock source since we cannot
+			 * support HD mode with internal clocks.
+			 */
+			writel(VPSS_MUXSEL_EXTCLK_ENABLE, vpss_clk_ctrl_reg);
+		break;
+
+	default:
+		return -EINVAL;
+	}
+
+	return 0;
 }
 
+static struct platform_device dm355_vpbe_display = {
+	.name		= "vpbe-v4l2",
+	.id		= -1,
+	.num_resources	= ARRAY_SIZE(dm355_v4l2_disp_resources),
+	.resource	= dm355_v4l2_disp_resources,
+	.dev		= {
+		.dma_mask		= &vpfe_capture_dma_mask,
+		.coherent_dma_mask	= DMA_BIT_MASK(32),
+	},
+};
+
+struct venc_platform_data dm355_venc_pdata = {
+	.setup_pinmux	= dm355_vpbe_setup_pinmux,
+	.setup_clock	= dm355_venc_setup_clock,
+};
+
+static struct platform_device dm355_venc_dev = {
+	.name		= DM355_VPBE_VENC_SUBDEV_NAME,
+	.id		= -1,
+	.num_resources	= ARRAY_SIZE(dm355_venc_resources),
+	.resource	= dm355_venc_resources,
+	.dev		= {
+		.dma_mask		= &vpfe_capture_dma_mask,
+		.coherent_dma_mask	= DMA_BIT_MASK(32),
+		.platform_data		= (void *)&dm355_venc_pdata,
+	},
+};
+
+static struct platform_device dm355_vpbe_dev = {
+	.name		= "vpbe_controller",
+	.id		= -1,
+	.dev		= {
+		.dma_mask		= &vpfe_capture_dma_mask,
+		.coherent_dma_mask	= DMA_BIT_MASK(32),
+	},
+};
+
 /*----------------------------------------------------------------------*/
 
 static struct map_desc dm355_io_desc[] = {
@@ -868,6 +1011,29 @@ void __init dm355_init(void)
 	davinci_map_sysmod();
 }
 
+int __init dm355_init_video(struct vpfe_config *vpfe_cfg,
+				struct vpbe_config *vpbe_cfg)
+{
+	if (vpfe_cfg || vpbe_cfg)
+		platform_device_register(&dm355_vpss_device);
+
+	if (vpfe_cfg) {
+		vpfe_capture_dev.dev.platform_data = vpfe_cfg;
+		platform_device_register(&dm355_ccdc_dev);
+		platform_device_register(&vpfe_capture_dev);
+	}
+
+	if (vpbe_cfg) {
+		dm355_vpbe_dev.dev.platform_data = vpbe_cfg;
+		platform_device_register(&dm355_osd_dev);
+		platform_device_register(&dm355_venc_dev);
+		platform_device_register(&dm355_vpbe_dev);
+		platform_device_register(&dm355_vpbe_display);
+	}
+
+	return 0;
+}
+
 static int __init dm355_init_devices(void)
 {
 	if (!cpu_is_davinci_dm355())
@@ -875,9 +1041,6 @@ static int __init dm355_init_devices(void)
 
 	davinci_cfg_reg(DM355_INT_EDMA_CC);
 	platform_device_register(&dm355_edma_device);
-	platform_device_register(&dm355_vpss_device);
-	platform_device_register(&dm355_ccdc_dev);
-	platform_device_register(&vpfe_capture_dev);
 
 	return 0;
 }
-- 
1.7.4.1



From prabhakar.csengg at gmail.com  Tue Apr  2 09:15:04 2013
From: prabhakar.csengg at gmail.com (Prabhakar lad)
Date: Tue,  2 Apr 2013 18:45:04 +0530
Subject: [PATCH v7 2/2] ARM: davinci: dm355 EVM: add support for VPBE display
In-Reply-To: <1364908504-14232-1-git-send-email-prabhakar.csengg@gmail.com>
References: <1364908504-14232-1-git-send-email-prabhakar.csengg@gmail.com>
Message-ID: <1364908504-14232-3-git-send-email-prabhakar.csengg@gmail.com>

From: Lad, Prabhakar <prabhakar.csengg at gmail.com>

add support for V4L2 video display to DM355 EVM.
Support for SD modes is provided, along with Composite
output

Signed-off-by: Lad, Prabhakar <prabhakar.csengg at gmail.com>
---
 arch/arm/mach-davinci/board-dm355-evm.c |   69 ++++++++++++++++++++++++++++++-
 1 files changed, 68 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-davinci/board-dm355-evm.c b/arch/arm/mach-davinci/board-dm355-evm.c
index 37d12cc..1043506 100644
--- a/arch/arm/mach-davinci/board-dm355-evm.c
+++ b/arch/arm/mach-davinci/board-dm355-evm.c
@@ -242,6 +242,73 @@ static struct vpfe_config vpfe_cfg = {
 	.ccdc = "DM355 CCDC",
 };
 
+/* venc standards timings */
+static struct vpbe_enc_mode_info dm355evm_enc_preset_timing[] = {
+	{
+		.name		= "ntsc",
+		.timings_type	= VPBE_ENC_STD,
+		.std_id		= 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,
+		.std_id		= V4L2_STD_625_50,
+		.interlaced	= 1,
+		.xres		= 720,
+		.yres		= 576,
+		.aspect		= {54, 59},
+		.fps		= {25, 1},
+		.left_margin	= 0x7E,
+		.upper_margin	= 0x16
+	},
+};
+
+#define VENC_STD_ALL	(V4L2_STD_NTSC | V4L2_STD_PAL)
+
+/*
+ * The outputs available from VPBE + ecnoders. Keep the
+ * 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 dm355evm_vpbe_outputs[] = {
+	{
+		.output		= {
+			.index		= 0,
+			.name		= "Composite",
+			.type		= V4L2_OUTPUT_TYPE_ANALOG,
+			.std		= VENC_STD_ALL,
+			.capabilities	= V4L2_OUT_CAP_STD,
+		},
+		.subdev_name	= DM355_VPBE_VENC_SUBDEV_NAME,
+		.default_mode	= "ntsc",
+		.num_modes	= ARRAY_SIZE(dm355evm_enc_preset_timing),
+		.modes		= dm355evm_enc_preset_timing,
+		.if_params	= V4L2_MBUS_FMT_FIXED,
+	},
+};
+
+static struct vpbe_config dm355evm_display_cfg = {
+	.module_name	= "dm355-vpbe-display",
+	.i2c_adapter_id	= 1,
+	.osd		= {
+		.module_name	= DM355_VPBE_OSD_SUBDEV_NAME,
+	},
+	.venc		= {
+		.module_name	= DM355_VPBE_VENC_SUBDEV_NAME,
+	},
+	.num_outputs	= ARRAY_SIZE(dm355evm_vpbe_outputs),
+	.outputs	= dm355evm_vpbe_outputs,
+};
+
 static struct platform_device *davinci_evm_devices[] __initdata = {
 	&dm355evm_dm9000,
 	&davinci_nand_device,
@@ -342,7 +409,7 @@ static __init void dm355_evm_init(void)
 	davinci_setup_mmc(0, &dm355evm_mmc_config);
 	davinci_setup_mmc(1, &dm355evm_mmc_config);
 
-	dm355_init_video(&vpfe_cfg, NULL);
+	dm355_init_video(&vpfe_cfg, &dm355evm_display_cfg);
 
 	dm355_init_spi0(BIT(0), dm355_evm_spi_info,
 			ARRAY_SIZE(dm355_evm_spi_info));
-- 
1.7.4.1



From shawn.guo at linaro.org  Tue Apr  2 09:16:33 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 2 Apr 2013 21:16:33 +0800
Subject: [PATCH] ARM: imx1: mm: add call to mxc_device_init
In-Reply-To: <20130325140940.GH1906@pengutronix.de>
References: <1363448999-3936-1-git-send-email-gwenhael.goavec-merou@armadeus.com>
 <20130325140940.GH1906@pengutronix.de>
Message-ID: <20130402131630.GE27148@S2101-09.ap.freescale.net>

Sascha,

On Mon, Mar 25, 2013 at 03:09:40PM +0100, Sascha Hauer wrote:
> On Sat, Mar 16, 2013 at 04:49:59PM +0100, Gwenhael Goavec-Merou wrote:
> > mxc_device_init() is mandatory for mxc_aips and mxc_ahb bus registration, needed 
> > as parents, at least, for gpio and dma.
> > 
> > Signed-off-by: Gwenhael Goavec-Merou <gwenhael.goavec-merou at armadeus.com>
> 
> Applied, thanks

I did not see this patch in those you ask me to handle.  Has it been
handled or just missed?

Shawn



From lee.jones at linaro.org  Tue Apr  2 09:21:48 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Tue,  2 Apr 2013 14:21:48 +0100
Subject: [PATCH 1/9] ARM: ux500: Increase the size of the PRCMU's TCPM size
Message-ID: <1364908916-29803-1-git-send-email-lee.jones@linaro.org>

The Tightly Coupled Program Memory location is actually 32kB in
size, rather than the originally depicted 4kB.

Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/mach-ux500/devices-db8500.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-ux500/devices-db8500.c b/arch/arm/mach-ux500/devices-db8500.c
index f3d9419..afa5b04 100644
--- a/arch/arm/mach-ux500/devices-db8500.c
+++ b/arch/arm/mach-ux500/devices-db8500.c
@@ -225,7 +225,7 @@ static struct resource db8500_prcmu_res[] = {
 	{
 		.name  = "prcmu-tcpm",
 		.start = U8500_PRCMU_TCPM_BASE,
-		.end   = U8500_PRCMU_TCPM_BASE + SZ_4K - 1,
+		.end   = U8500_PRCMU_TCPM_BASE + SZ_32K - 1,
 		.flags = IORESOURCE_MEM,
 	},
 };
-- 
1.7.10.4



From lee.jones at linaro.org  Tue Apr  2 09:21:49 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Tue,  2 Apr 2013 14:21:49 +0100
Subject: [PATCH 2/9] ARM: ux500: Remove incorrect DB9540 PRCMU TCDM base
 location
In-Reply-To: <1364908916-29803-1-git-send-email-lee.jones@linaro.org>
References: <1364908916-29803-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1364908916-29803-2-git-send-email-lee.jones@linaro.org>

The Tightly Coupled Data Memory for the DB9540 is actually in the
same place as the DB8500's. This definition is just plain wrong.

Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/mach-ux500/include/mach/db8500-regs.h |    1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/mach-ux500/include/mach/db8500-regs.h b/arch/arm/mach-ux500/include/mach/db8500-regs.h
index 1530d49..856e584 100644
--- a/arch/arm/mach-ux500/include/mach/db8500-regs.h
+++ b/arch/arm/mach-ux500/include/mach/db8500-regs.h
@@ -102,7 +102,6 @@
 #define U8500_PRCMU_BASE	(U8500_PER4_BASE + 0x07000)
 #define U9540_DMC1_BASE		(U8500_PER4_BASE + 0x0A000)
 #define U8500_PRCMU_TCDM_BASE	(U8500_PER4_BASE + 0x68000)
-#define U9540_PRCMU_TCDM_BASE	(U8500_PER4_BASE + 0x6A000)
 #define U8500_PRCMU_TCPM_BASE   (U8500_PER4_BASE + 0x60000)
 #define U8500_PRCMU_TIMER_3_BASE (U8500_PER4_BASE + 0x07338)
 #define U8500_PRCMU_TIMER_4_BASE (U8500_PER4_BASE + 0x07450)
-- 
1.7.10.4



From lee.jones at linaro.org  Tue Apr  2 09:21:50 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Tue,  2 Apr 2013 14:21:50 +0100
Subject: [PATCH 3/9] ARM: ux500: Supply a DTS file for the u8540 platform
In-Reply-To: <1364908916-29803-1-git-send-email-lee.jones@linaro.org>
References: <1364908916-29803-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1364908916-29803-3-git-send-email-lee.jones@linaro.org>

This is a skeleton DTS file which only enables serial. Just using
this simple file yields a terminal when booting u8540.

Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/boot/dts/u8540.dts |   36 ++++++++++++++++++++++++++++++++++++
 1 file changed, 36 insertions(+)
 create mode 100644 arch/arm/boot/dts/u8540.dts

diff --git a/arch/arm/boot/dts/u8540.dts b/arch/arm/boot/dts/u8540.dts
new file mode 100644
index 0000000..02e8e1a
--- /dev/null
+++ b/arch/arm/boot/dts/u8540.dts
@@ -0,0 +1,36 @@
+/*
+ * Copyright 2013 ST-Ericsson AB
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+/dts-v1/;
+/include/ "dbx5x0.dtsi"
+
+/ {
+	model = "ST-Ericsson U8540 platform with Device Tree";
+	compatible = "st-ericsson,u8540";
+
+	memory {
+		reg = <0x00000000 0x20000000>;
+	};
+
+	soc-u9500 {
+		uart at 80120000 {
+			status = "okay";
+		};
+
+		uart at 80121000 {
+			status = "okay";
+		};
+
+		uart at 80007000 {
+			status = "okay";
+		};
+	};
+};
-- 
1.7.10.4



From lee.jones at linaro.org  Tue Apr  2 09:21:52 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Tue,  2 Apr 2013 14:21:52 +0100
Subject: [PATCH 5/9] ARM: ux500: Over-ride TCDM size when booting the DB8540
 platform
In-Reply-To: <1364908916-29803-1-git-send-email-lee.jones@linaro.org>
References: <1364908916-29803-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1364908916-29803-5-git-send-email-lee.jones@linaro.org>

The PRCMU's Tightly Coupled Data Memory on the DB8540 platform is
8kB larger than it's predecessor's. We need to reflect that in its
Device Tree. By re-specifying the address and size of the device
we effectively over-ride the previous values with more accurate
ones.

Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/boot/dts/u8540.dts |    5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/u8540.dts b/arch/arm/boot/dts/u8540.dts
index 02e8e1a..f829689 100644
--- a/arch/arm/boot/dts/u8540.dts
+++ b/arch/arm/boot/dts/u8540.dts
@@ -21,6 +21,11 @@
 	};
 
 	soc-u9500 {
+		prcmu at 80157000 {
+			reg = <0x80157000 0x2000>, <0x801b0000 0x8000>, <0x801b8000 0x3000>;
+			reg-names = "prcmu", "prcmu-tcpm-per4", "prcmu-tcdm-per4";
+		};
+
 		uart at 80120000 {
 			status = "okay";
 		};
-- 
1.7.10.4



From lee.jones at linaro.org  Tue Apr  2 09:21:51 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Tue,  2 Apr 2013 14:21:51 +0100
Subject: [PATCH 4/9] ARM: ux500: Move Snowball's thermal DT node into existing
 PRCMU one
In-Reply-To: <1364908916-29803-1-git-send-email-lee.jones@linaro.org>
References: <1364908916-29803-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1364908916-29803-4-git-send-email-lee.jones@linaro.org>

When the thermal DT node was inserted a new PRCMU node was created;
however, one already exists in the Snowball DTS file. Here we
amalgamate the two into a single consolidated node.

Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/boot/dts/snowball.dts |   53 +++++++++++++++++++---------------------
 1 file changed, 25 insertions(+), 28 deletions(-)

diff --git a/arch/arm/boot/dts/snowball.dts b/arch/arm/boot/dts/snowball.dts
index d3ec32f..cc99447 100644
--- a/arch/arm/boot/dts/snowball.dts
+++ b/arch/arm/boot/dts/snowball.dts
@@ -99,33 +99,6 @@
 			status = "okay";
 		};
 
-		prcmu at 80157000 {
-			thermal at 801573c0 {
-				num-trips = <4>;
-
-				trip0-temp = <70000>;
-				trip0-type = "active";
-				trip0-cdev-num = <1>;
-				trip0-cdev-name0 = "thermal-cpufreq-0";
-
-				trip1-temp = <75000>;
-				trip1-type = "active";
-				trip1-cdev-num = <1>;
-				trip1-cdev-name0 = "thermal-cpufreq-0";
-
-				trip2-temp = <80000>;
-				trip2-type = "active";
-				trip2-cdev-num = <1>;
-				trip2-cdev-name0 = "thermal-cpufreq-0";
-
-				trip3-temp = <85000>;
-				trip3-type = "critical";
-				trip3-cdev-num = <0>;
-
-				status = "okay";
-			 };
-		};
-
 		external-bus at 50000000 {
 			status = "okay";
 
@@ -296,7 +269,31 @@
 				db8500_esram34_ret_reg: db8500_esram34_ret {
 					regulator-name = "db8500-esram34-ret";
 				};
-			};
+
+			thermal at 801573c0 {
+				num-trips = <4>;
+
+				trip0-temp = <70000>;
+				trip0-type = "active";
+				trip0-cdev-num = <1>;
+				trip0-cdev-name0 = "thermal-cpufreq-0";
+
+				trip1-temp = <75000>;
+				trip1-type = "active";
+				trip1-cdev-num = <1>;
+				trip1-cdev-name0 = "thermal-cpufreq-0";
+
+				trip2-temp = <80000>;
+				trip2-type = "active";
+				trip2-cdev-num = <1>;
+				trip2-cdev-name0 = "thermal-cpufreq-0";
+
+				trip3-temp = <85000>;
+				trip3-type = "critical";
+				trip3-cdev-num = <0>;
+
+				status = "okay";
+			 };
 
 			ab8500 {
 				ab8500-regulators {
-- 
1.7.10.4



From lee.jones at linaro.org  Tue Apr  2 09:21:54 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Tue,  2 Apr 2013 14:21:54 +0100
Subject: [PATCH 7/9] ARM: ux500: Add a VQMMC (level-shifting) regulator DT
 node for Snowball
In-Reply-To: <1364908916-29803-1-git-send-email-lee.jones@linaro.org>
References: <1364908916-29803-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1364908916-29803-7-git-send-email-lee.jones@linaro.org>

Until recently platform code took care of all MMCI level-shifting by
way of an ios_handler() call-back. Now it is the driver's responsibility
to handle. In order to so that we need to provide the VQMMC regulator
reference in Device Tree. This patch takes care of that.

Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/boot/dts/snowball.dts |    8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/snowball.dts b/arch/arm/boot/dts/snowball.dts
index cc99447..6b4f8b9 100644
--- a/arch/arm/boot/dts/snowball.dts
+++ b/arch/arm/boot/dts/snowball.dts
@@ -119,6 +119,13 @@
 			};
 		};
 
+		vmmci: regulator-gpio {
+			gpios = <&gpio6 25 0x4>;
+			enable-gpio = <&gpio7 4 0x4>;
+
+			status = "okay";
+		};
+
 		// External Micro SD slot
 		sdi0_per1 at 80126000 {
 			arm,primecell-periphid = <0x10480180>;
@@ -126,6 +133,7 @@
 			bus-width = <4>;
 			mmc-cap-mmc-highspeed;
 			vmmc-supply = <&ab8500_ldo_aux3_reg>;
+			vqmmc-supply = <&vmmci>;
 
 			cd-gpios  = <&gpio6 26 0x4>; // 218
 			cd-inverted;
-- 
1.7.10.4



From lee.jones at linaro.org  Tue Apr  2 09:21:53 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Tue,  2 Apr 2013 14:21:53 +0100
Subject: [PATCH 6/9] ARM: ux500: Create a new of_dev_auxdata structure for
 u8540 enablement
In-Reply-To: <1364908916-29803-1-git-send-email-lee.jones@linaro.org>
References: <1364908916-29803-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1364908916-29803-6-git-send-email-lee.jones@linaro.org>

If we attempt to use the existing u8500 of_dev_auxdata struct to boot
the u8540, we fail to obtain a console, due to a lack of DMA support
on the platform.

Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/mach-ux500/cpu-db8500.c |   19 +++++++++++++++++--
 1 file changed, 17 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-ux500/cpu-db8500.c b/arch/arm/mach-ux500/cpu-db8500.c
index f1a5818..e027865 100644
--- a/arch/arm/mach-ux500/cpu-db8500.c
+++ b/arch/arm/mach-ux500/cpu-db8500.c
@@ -297,6 +297,16 @@ static struct of_dev_auxdata u8500_auxdata_lookup[] __initdata = {
 	{},
 };
 
+static struct of_dev_auxdata u8540_auxdata_lookup[] __initdata = {
+	/* Requires DMA bindings. */
+	OF_DEV_AUXDATA("arm,pl011", 0x80120000, "uart0", NULL),
+	OF_DEV_AUXDATA("arm,pl011", 0x80121000, "uart1", NULL),
+	OF_DEV_AUXDATA("arm,pl011", 0x80007000, "uart2", NULL),
+	OF_DEV_AUXDATA("stericsson,db8500-prcmu", 0x80157000, "db8500-prcmu",
+			&db8500_prcmu_pdata),
+	{},
+};
+
 static const struct of_device_id u8500_local_bus_nodes[] = {
 	/* only create devices below soc node */
 	{ .compatible = "stericsson,db8500", },
@@ -323,8 +333,13 @@ static void __init u8500_init_machine(void)
 	/* TODO: Export SoC, USB, cpu-freq and DMA40 */
 	parent = u8500_of_init_devices();
 
-	/* automatically probe child nodes of db8500 device */
-	of_platform_populate(NULL, u8500_local_bus_nodes, u8500_auxdata_lookup, parent);
+	/* automatically probe child nodes of dbx5x0 devices */
+	if (of_machine_is_compatible("st-ericsson,u8540"))
+		of_platform_populate(NULL, u8500_local_bus_nodes,
+				     u8540_auxdata_lookup, parent);
+	else
+		of_platform_populate(NULL, u8500_local_bus_nodes,
+				     u8500_auxdata_lookup, parent);
 }
 
 static const char * stericsson_dt_platform_compat[] = {
-- 
1.7.10.4



From lee.jones at linaro.org  Tue Apr  2 09:21:56 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Tue,  2 Apr 2013 14:21:56 +0100
Subject: [PATCH 9/9] mfd: db8500-prcmu: Support platform dependant device
 selection
In-Reply-To: <1364908916-29803-1-git-send-email-lee.jones@linaro.org>
References: <1364908916-29803-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1364908916-29803-9-git-send-email-lee.jones@linaro.org>

The main aim for this cycle is to have the u8540 booting to a
console. However, the u8540 doesn't support all of the u8500
platform devices yet. After this stage is complete we can then
fill in the inadequacies, such as specific clock support at a
later date. To achieve this we're placing devices supported by
all platforms into a common device structure and the remaining
ones into a platform specific one.

Cc: Samuel Ortiz <sameo at linux.intel.com>
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 drivers/mfd/db8500-prcmu.c |   45 ++++++++++++++++++++++++++++----------------
 1 file changed, 29 insertions(+), 16 deletions(-)

diff --git a/drivers/mfd/db8500-prcmu.c b/drivers/mfd/db8500-prcmu.c
index 1c4edbf8..5a03b5d 100644
--- a/drivers/mfd/db8500-prcmu.c
+++ b/drivers/mfd/db8500-prcmu.c
@@ -3107,19 +3107,7 @@ static struct ux500_wdt_data db8500_wdt_pdata = {
 	.has_28_bits_resolution = true,
 };
 
-static struct mfd_cell db8500_prcmu_devs[] = {
-	{
-		.name = "db8500-prcmu-regulators",
-		.of_compatible = "stericsson,db8500-prcmu-regulator",
-		.platform_data = &db8500_regulators,
-		.pdata_size = sizeof(db8500_regulators),
-	},
-	{
-		.name = "cpufreq-ux500",
-		.of_compatible = "stericsson,cpufreq-ux500",
-		.platform_data = &db8500_cpufreq_table,
-		.pdata_size = sizeof(db8500_cpufreq_table),
-	},
+static struct mfd_cell common_prcmu_devs[] = {
 	{
 		.name = "ux500_wdt",
 		.platform_data = &db8500_wdt_pdata,
@@ -3135,6 +3123,21 @@ static struct mfd_cell db8500_prcmu_devs[] = {
 	},
 };
 
+static struct mfd_cell db8500_prcmu_devs[] = {
+	{
+		.name = "db8500-prcmu-regulators",
+		.of_compatible = "stericsson,db8500-prcmu-regulator",
+		.platform_data = &db8500_regulators,
+		.pdata_size = sizeof(db8500_regulators),
+	},
+	{
+		.name = "cpufreq-ux500",
+		.of_compatible = "stericsson,cpufreq-ux500",
+		.platform_data = &db8500_cpufreq_table,
+		.pdata_size = sizeof(db8500_cpufreq_table),
+	},
+};
+
 static void db8500_prcmu_update_cpufreq(void)
 {
 	if (prcmu_has_arm_maxopp()) {
@@ -3184,7 +3187,7 @@ static int db8500_prcmu_probe(struct platform_device *pdev)
 
 	db8500_irq_init(np);
 
-	for (i = 0; i < ARRAY_SIZE(db8500_prcmu_devs); i++) {
+	for (i = 0; i < ARRAY_SIZE(common_prcmu_devs); i++) {
 		if (!strcmp(db8500_prcmu_devs[i].name, "ab8500-core")) {
 			db8500_prcmu_devs[i].platform_data = pdata->ab_platdata;
 			db8500_prcmu_devs[i].pdata_size = sizeof(struct ab8500_platform_data);
@@ -3195,13 +3198,23 @@ static int db8500_prcmu_probe(struct platform_device *pdev)
 
 	db8500_prcmu_update_cpufreq();
 
-	err = mfd_add_devices(&pdev->dev, 0, db8500_prcmu_devs,
-			      ARRAY_SIZE(db8500_prcmu_devs), NULL, 0, NULL);
+	err = mfd_add_devices(&pdev->dev, 0, common_prcmu_devs,
+			      ARRAY_SIZE(common_prcmu_devs), NULL, 0, NULL);
 	if (err) {
 		pr_err("prcmu: Failed to add subdevices\n");
 		return err;
 	}
 
+	/* TODO: Remove restriction when clk definitions are available. */
+	if (!of_machine_is_compatible("st-ericsson,u8540")) {
+		err = mfd_add_devices(&pdev->dev, 0, db8500_prcmu_devs,
+				      ARRAY_SIZE(db8500_prcmu_devs), NULL, 0, NULL);
+		if (err) {
+			pr_err("prcmu: Failed to add subdevices\n");
+			return err;
+		}
+	}
+
 	pr_info("DB8500 PRCMU initialized\n");
 
 no_irq_return:
-- 
1.7.10.4



From lee.jones at linaro.org  Tue Apr  2 09:21:55 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Tue,  2 Apr 2013 14:21:55 +0100
Subject: [PATCH 8/9] mfd: db8500-prcmu: Return early if the TCPM cannot be
 located
In-Reply-To: <1364908916-29803-1-git-send-email-lee.jones@linaro.org>
References: <1364908916-29803-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1364908916-29803-8-git-send-email-lee.jones@linaro.org>

Currently we check to see if we obtained the Tightly Coupled Program
Memory (TCPM) base and only execute the code within the check if we
have it. It's more traditional to return early if we don't have it.
This way we can flatten most of the function's code down to a single
tab spacing.

Cc: Samuel Ortiz <sameo at linux.intel.com>
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 drivers/mfd/db8500-prcmu.c |   40 +++++++++++++++++++++-------------------
 1 file changed, 21 insertions(+), 19 deletions(-)

diff --git a/drivers/mfd/db8500-prcmu.c b/drivers/mfd/db8500-prcmu.c
index 21f261b..1c4edbf8 100644
--- a/drivers/mfd/db8500-prcmu.c
+++ b/drivers/mfd/db8500-prcmu.c
@@ -2794,6 +2794,7 @@ static void dbx500_fw_version_init(struct platform_device *pdev,
 {
 	struct resource *res;
 	void __iomem *tcpm_base;
+	u32 version;
 
 	res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
 					   "prcmu-tcpm");
@@ -2803,26 +2804,27 @@ static void dbx500_fw_version_init(struct platform_device *pdev,
 		return;
 	}
 	tcpm_base = ioremap(res->start, resource_size(res));
-	if (tcpm_base != NULL) {
-		u32 version;
-
-		version = readl(tcpm_base + version_offset);
-		fw_info.version.project = (version & 0xFF);
-		fw_info.version.api_version = (version >> 8) & 0xFF;
-		fw_info.version.func_version = (version >> 16) & 0xFF;
-		fw_info.version.errata = (version >> 24) & 0xFF;
-		strncpy(fw_info.version.project_name,
-			fw_project_name(fw_info.version.project),
-			PRCMU_FW_PROJECT_NAME_LEN);
-		fw_info.valid = true;
-		pr_info("PRCMU firmware: %s(%d), version %d.%d.%d\n",
-			fw_info.version.project_name,
-			fw_info.version.project,
-			fw_info.version.api_version,
-			fw_info.version.func_version,
-			fw_info.version.errata);
-		iounmap(tcpm_base);
+	if (!tcpm_base) {
+		dev_err(&pdev->dev, "no prcmu tcpm mem region provided\n");
+		return;
 	}
+
+	version = readl(tcpm_base + version_offset);
+	fw_info.version.project = (version & 0xFF);
+	fw_info.version.api_version = (version >> 8) & 0xFF;
+	fw_info.version.func_version = (version >> 16) & 0xFF;
+	fw_info.version.errata = (version >> 24) & 0xFF;
+	strncpy(fw_info.version.project_name,
+		fw_project_name(fw_info.version.project),
+		PRCMU_FW_PROJECT_NAME_LEN);
+	fw_info.valid = true;
+	pr_info("PRCMU firmware: %s(%d), version %d.%d.%d\n",
+		fw_info.version.project_name,
+		fw_info.version.project,
+		fw_info.version.api_version,
+		fw_info.version.func_version,
+		fw_info.version.errata);
+	iounmap(tcpm_base);
 }
 
 void __init db8500_prcmu_early_init(void)
-- 
1.7.10.4



From marc.zyngier at arm.com  Tue Apr  2 09:25:11 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Tue,  2 Apr 2013 14:25:11 +0100
Subject: [PATCH 3/7] ARM: KVM: move to a KVM provided HYP idmap
In-Reply-To: <1364909115-3810-1-git-send-email-marc.zyngier@arm.com>
References: <1364909115-3810-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1364909115-3810-4-git-send-email-marc.zyngier@arm.com>

After the HYP page table rework, it is pretty easy to let the KVM
code provide its own idmap, rather than expecting the kernel to
provide it. It takes actually less code to do so.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm/include/asm/idmap.h   |  1 -
 arch/arm/include/asm/kvm_mmu.h |  1 -
 arch/arm/kvm/mmu.c             | 24 +++++++++++++++++++++++-
 arch/arm/mm/idmap.c            | 31 +------------------------------
 4 files changed, 24 insertions(+), 33 deletions(-)

diff --git a/arch/arm/include/asm/idmap.h b/arch/arm/include/asm/idmap.h
index 1a66f907..bf863ed 100644
--- a/arch/arm/include/asm/idmap.h
+++ b/arch/arm/include/asm/idmap.h
@@ -8,7 +8,6 @@
 #define __idmap __section(.idmap.text) noinline notrace
 
 extern pgd_t *idmap_pgd;
-extern pgd_t *hyp_pgd;
 
 void setup_mm_for_reboot(void);
 
diff --git a/arch/arm/include/asm/kvm_mmu.h b/arch/arm/include/asm/kvm_mmu.h
index 970f3b5..3c71a1d 100644
--- a/arch/arm/include/asm/kvm_mmu.h
+++ b/arch/arm/include/asm/kvm_mmu.h
@@ -21,7 +21,6 @@
 
 #include <asm/cacheflush.h>
 #include <asm/pgalloc.h>
-#include <asm/idmap.h>
 
 /*
  * We directly use the kernel VA for the HYP, as we can directly share
diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
index eb4f8fa..7d23480 100644
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@ -32,6 +32,7 @@
 
 extern char  __hyp_idmap_text_start[], __hyp_idmap_text_end[];
 
+static pgd_t *hyp_pgd;
 static DEFINE_MUTEX(kvm_hyp_pgd_mutex);
 
 static void kvm_tlb_flush_vmid_ipa(struct kvm *kvm, phys_addr_t ipa)
@@ -715,12 +716,33 @@ phys_addr_t kvm_mmu_get_httbr(void)
 
 int kvm_mmu_init(void)
 {
+	unsigned long hyp_idmap_start = virt_to_phys(__hyp_idmap_text_start);
+	unsigned long hyp_idmap_end = virt_to_phys(__hyp_idmap_text_end);
+	int err;
+
+	hyp_pgd = kzalloc(PTRS_PER_PGD * sizeof(pgd_t), GFP_KERNEL);
 	if (!hyp_pgd) {
 		kvm_err("Hyp mode PGD not allocated\n");
-		return -ENOMEM;
+		err = -ENOMEM;
+		goto out;
+	}
+
+	/* Create the idmap in the boot page tables */
+	err = 	__create_hyp_mappings(boot_hyp_pgd,
+				      hyp_idmap_start, hyp_idmap_end,
+				      __phys_to_pfn(hyp_idmap_start),
+				      PAGE_HYP);
+
+	if (err) {
+		kvm_err("Failed to idmap %lx-%lx\n",
+			hyp_idmap_start, hyp_idmap_end);
+		goto out;
 	}
 
 	return 0;
+out:
+	kfree(hyp_pgd);
+	return err;
 }
 
 /**
diff --git a/arch/arm/mm/idmap.c b/arch/arm/mm/idmap.c
index 5ee505c..9c467d0 100644
--- a/arch/arm/mm/idmap.c
+++ b/arch/arm/mm/idmap.c
@@ -83,37 +83,10 @@ static void identity_mapping_add(pgd_t *pgd, const char *text_start,
 	} while (pgd++, addr = next, addr != end);
 }
 
-#if defined(CONFIG_ARM_VIRT_EXT) && defined(CONFIG_ARM_LPAE)
-pgd_t *hyp_pgd;
-
-extern char  __hyp_idmap_text_start[], __hyp_idmap_text_end[];
-
-static int __init init_static_idmap_hyp(void)
-{
-	hyp_pgd = kzalloc(PTRS_PER_PGD * sizeof(pgd_t), GFP_KERNEL);
-	if (!hyp_pgd)
-		return -ENOMEM;
-
-	pr_info("Setting up static HYP identity map for 0x%p - 0x%p\n",
-		__hyp_idmap_text_start, __hyp_idmap_text_end);
-	identity_mapping_add(hyp_pgd, __hyp_idmap_text_start,
-			     __hyp_idmap_text_end, PMD_SECT_AP1);
-
-	return 0;
-}
-#else
-static int __init init_static_idmap_hyp(void)
-{
-	return 0;
-}
-#endif
-
 extern char  __idmap_text_start[], __idmap_text_end[];
 
 static int __init init_static_idmap(void)
 {
-	int ret;
-
 	idmap_pgd = pgd_alloc(&init_mm);
 	if (!idmap_pgd)
 		return -ENOMEM;
@@ -123,12 +96,10 @@ static int __init init_static_idmap(void)
 	identity_mapping_add(idmap_pgd, __idmap_text_start,
 			     __idmap_text_end, 0);
 
-	ret = init_static_idmap_hyp();
-
 	/* Flush L1 for the hardware to see this page table content */
 	flush_cache_louis();
 
-	return ret;
+	return 0;
 }
 early_initcall(init_static_idmap);
 
-- 
1.8.1.4




From marc.zyngier at arm.com  Tue Apr  2 09:25:13 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Tue,  2 Apr 2013 14:25:13 +0100
Subject: [PATCH 5/7] ARM: KVM: parametrize HYP page table freeing
In-Reply-To: <1364909115-3810-1-git-send-email-marc.zyngier@arm.com>
References: <1364909115-3810-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1364909115-3810-6-git-send-email-marc.zyngier@arm.com>

In order to prepare for having to deal with multiple HYP page tables,
pass the PGD parameter to the function performing the freeing of the
page tables.

Also move the freeing of the PGD itself there, and rename the
free_hyp_pmds to free_hyp_pgds.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm/include/asm/kvm_mmu.h |  2 +-
 arch/arm/kvm/arm.c             |  2 +-
 arch/arm/kvm/mmu.c             | 30 +++++++++++++++++-------------
 3 files changed, 19 insertions(+), 15 deletions(-)

diff --git a/arch/arm/include/asm/kvm_mmu.h b/arch/arm/include/asm/kvm_mmu.h
index 3c71a1d..92eb20d 100644
--- a/arch/arm/include/asm/kvm_mmu.h
+++ b/arch/arm/include/asm/kvm_mmu.h
@@ -32,7 +32,7 @@
 
 int create_hyp_mappings(void *from, void *to);
 int create_hyp_io_mappings(void *from, void *to, phys_addr_t);
-void free_hyp_pmds(void);
+void free_hyp_pgds(void);
 
 int kvm_alloc_stage2_pgd(struct kvm *kvm);
 void kvm_free_stage2_pgd(struct kvm *kvm);
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index 2ce90bb..6eba879 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -936,7 +936,7 @@ static int init_hyp_mode(void)
 out_free_context:
 	free_percpu(kvm_host_cpu_state);
 out_free_mappings:
-	free_hyp_pmds();
+	free_hyp_pgds();
 out_free_stack_pages:
 	for_each_possible_cpu(cpu)
 		free_page(per_cpu(kvm_arm_hyp_stack_page, cpu));
diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
index 7d23480..85b3553 100644
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@ -86,42 +86,46 @@ static void free_ptes(pmd_t *pmd, unsigned long addr)
 	}
 }
 
-static void free_hyp_pgd_entry(unsigned long addr)
+static void free_hyp_pgd_entry(pgd_t *pgdp, unsigned long addr)
 {
 	pgd_t *pgd;
 	pud_t *pud;
 	pmd_t *pmd;
-	unsigned long hyp_addr = KERN_TO_HYP(addr);
 
-	pgd = hyp_pgd + pgd_index(hyp_addr);
-	pud = pud_offset(pgd, hyp_addr);
+	pgd = pgdp + pgd_index(addr);
+	pud = pud_offset(pgd, addr);
 
 	if (pud_none(*pud))
 		return;
 	BUG_ON(pud_bad(*pud));
 
-	pmd = pmd_offset(pud, hyp_addr);
+	pmd = pmd_offset(pud, addr);
 	free_ptes(pmd, addr);
 	pmd_free(NULL, pmd);
 	pud_clear(pud);
 }
 
 /**
- * free_hyp_pmds - free a Hyp-mode level-2 tables and child level-3 tables
+ * free_hyp_pgds - free Hyp-mode page tables
  *
- * Assumes this is a page table used strictly in Hyp-mode and therefore contains
+ * Assumes hyp_pgd is a page table used strictly in Hyp-mode and therefore contains
  * either mappings in the kernel memory area (above PAGE_OFFSET), or
  * device mappings in the vmalloc range (from VMALLOC_START to VMALLOC_END).
  */
-void free_hyp_pmds(void)
+void free_hyp_pgds(void)
 {
 	unsigned long addr;
 
 	mutex_lock(&kvm_hyp_pgd_mutex);
-	for (addr = PAGE_OFFSET; virt_addr_valid(addr); addr += PGDIR_SIZE)
-		free_hyp_pgd_entry(addr);
-	for (addr = VMALLOC_START; is_vmalloc_addr((void*)addr); addr += PGDIR_SIZE)
-		free_hyp_pgd_entry(addr);
+
+	if (hyp_pgd) {
+		for (addr = PAGE_OFFSET; virt_addr_valid(addr); addr += PGDIR_SIZE)
+			free_hyp_pgd_entry(hyp_pgd, KERN_TO_HYP(addr));
+		for (addr = VMALLOC_START; is_vmalloc_addr((void*)addr); addr += PGDIR_SIZE)
+			free_hyp_pgd_entry(hyp_pgd, KERN_TO_HYP(addr));
+		kfree(hyp_pgd);
+	}
+
 	mutex_unlock(&kvm_hyp_pgd_mutex);
 }
 
@@ -741,7 +745,7 @@ int kvm_mmu_init(void)
 
 	return 0;
 out:
-	kfree(hyp_pgd);
+	free_hyp_pgds();
 	return err;
 }
 
-- 
1.8.1.4




From marc.zyngier at arm.com  Tue Apr  2 09:25:12 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Tue,  2 Apr 2013 14:25:12 +0100
Subject: [PATCH 4/7] ARM: KVM: enforce page alignment for identity mapped code
In-Reply-To: <1364909115-3810-1-git-send-email-marc.zyngier@arm.com>
References: <1364909115-3810-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1364909115-3810-5-git-send-email-marc.zyngier@arm.com>

We're about to move to a init procedure where we rely on the
fact that the init code fits in a single page. Make sure we
align the idmap text on a page boundary, and that the code is
not bigger than a single page.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm/kernel/vmlinux.lds.S | 2 +-
 arch/arm/kvm/init.S           | 7 +++++++
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
index b571484..d9dd265 100644
--- a/arch/arm/kernel/vmlinux.lds.S
+++ b/arch/arm/kernel/vmlinux.lds.S
@@ -20,7 +20,7 @@
 	VMLINUX_SYMBOL(__idmap_text_start) = .;				\
 	*(.idmap.text)							\
 	VMLINUX_SYMBOL(__idmap_text_end) = .;				\
-	ALIGN_FUNCTION();						\
+	. = ALIGN(PAGE_SIZE);						\
 	VMLINUX_SYMBOL(__hyp_idmap_text_start) = .;			\
 	*(.hyp.idmap.text)						\
 	VMLINUX_SYMBOL(__hyp_idmap_text_end) = .;
diff --git a/arch/arm/kvm/init.S b/arch/arm/kvm/init.S
index 9f37a79..35a463f 100644
--- a/arch/arm/kvm/init.S
+++ b/arch/arm/kvm/init.S
@@ -111,4 +111,11 @@ __do_hyp_init:
 	.globl __kvm_hyp_init_end
 __kvm_hyp_init_end:
 
+	/*
+	 * The above code *must* fit in a single page for the trampoline
+	 * madness to work. Whoever decides to change it must make sure
+	 * we map the right amount of memory for the trampoline to work.
+	 * The line below ensures any breakage will get noticed.
+	 */
+	.org	__kvm_hyp_init + PAGE_SIZE
 	.popsection
-- 
1.8.1.4




From marc.zyngier at arm.com  Tue Apr  2 09:25:10 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Tue,  2 Apr 2013 14:25:10 +0100
Subject: [PATCH 2/7] ARM: KVM: fix HYP mapping limitations around zero
In-Reply-To: <1364909115-3810-1-git-send-email-marc.zyngier@arm.com>
References: <1364909115-3810-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1364909115-3810-3-git-send-email-marc.zyngier@arm.com>

The current code for creating HYP mapping doesn't like to wrap
around zero, which prevents from mapping anything into the last
page of the virtual address space.

It doesn't take much effort to remove this limitation, making
the code more consistent with the rest of the kernel in the process.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm/kvm/mmu.c | 21 ++++++++++-----------
 1 file changed, 10 insertions(+), 11 deletions(-)

diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
index 24811d1..eb4f8fa 100644
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@ -131,11 +131,12 @@ static void create_hyp_pte_mappings(pmd_t *pmd, unsigned long start,
 	pte_t *pte;
 	unsigned long addr;
 
-	for (addr = start; addr < end; addr += PAGE_SIZE) {
+	addr = start;
+	do {
 		pte = pte_offset_kernel(pmd, addr);
 		kvm_set_pte(pte, pfn_pte(pfn, prot));
 		pfn++;
-	}
+	} while (addr += PAGE_SIZE, addr != end);
 }
 
 static int create_hyp_pmd_mappings(pud_t *pud, unsigned long start,
@@ -146,7 +147,8 @@ static int create_hyp_pmd_mappings(pud_t *pud, unsigned long start,
 	pte_t *pte;
 	unsigned long addr, next;
 
-	for (addr = start; addr < end; addr = next) {
+	addr = start;
+	do {
 		pmd = pmd_offset(pud, addr);
 
 		BUG_ON(pmd_sect(*pmd));
@@ -164,7 +166,7 @@ static int create_hyp_pmd_mappings(pud_t *pud, unsigned long start,
 
 		create_hyp_pte_mappings(pmd, addr, next, pfn, prot);
 		pfn += (next - addr) >> PAGE_SHIFT;
-	}
+	} while (addr = next, addr != end);
 
 	return 0;
 }
@@ -179,11 +181,10 @@ static int __create_hyp_mappings(pgd_t *pgdp,
 	unsigned long addr, next;
 	int err = 0;
 
-	if (start >= end)
-		return -EINVAL;
-
 	mutex_lock(&kvm_hyp_pgd_mutex);
-	for (addr = start & PAGE_MASK; addr < end; addr = next) {
+	addr = start & PAGE_MASK;
+	end = PAGE_ALIGN(end);
+	do {
 		pgd = pgdp + pgd_index(addr);
 		pud = pud_offset(pgd, addr);
 
@@ -202,7 +203,7 @@ static int __create_hyp_mappings(pgd_t *pgdp,
 		if (err)
 			goto out;
 		pfn += (next - addr) >> PAGE_SHIFT;
-	}
+	} while (addr = next, addr != end);
 out:
 	mutex_unlock(&kvm_hyp_pgd_mutex);
 	return err;
@@ -216,8 +217,6 @@ out:
  * The same virtual address as the kernel virtual address is also used
  * in Hyp-mode mapping (modulo HYP_PAGE_OFFSET) to the same underlying
  * physical pages.
- *
- * Note: Wrapping around zero in the "to" address is not supported.
  */
 int create_hyp_mappings(void *from, void *to)
 {
-- 
1.8.1.4




From marc.zyngier at arm.com  Tue Apr  2 09:25:15 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Tue,  2 Apr 2013 14:25:15 +0100
Subject: [PATCH 7/7] ARM: KVM: perform HYP initilization for hotplugged CPUs
In-Reply-To: <1364909115-3810-1-git-send-email-marc.zyngier@arm.com>
References: <1364909115-3810-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1364909115-3810-8-git-send-email-marc.zyngier@arm.com>

Now that we have the necessary infrastructure to boot a hotplugged CPU
at any point in time, wire a CPU notifier that will perform the HYP
init for the incoming CPU.

Note that this depends on the platform code and/or firmware to boot the
incoming CPU with HYP mode enabled and return to the kernel by following
the normal boot path (HYP stub installed).

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm/kvm/arm.c | 47 +++++++++++++++++++++++++++++++----------------
 1 file changed, 31 insertions(+), 16 deletions(-)

diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index f0f3290..6cc076e 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -793,8 +793,9 @@ long kvm_arch_vm_ioctl(struct file *filp,
 	}
 }
 
-static void cpu_init_hyp_mode(void *vector)
+static void cpu_init_hyp_mode(void *dummy)
 {
+	phys_addr_t init_vector_addr = virt_to_phys(__kvm_hyp_init);
 	unsigned long long boot_pgd_ptr;
 	unsigned long long pgd_ptr;
 	unsigned long hyp_stack_ptr;
@@ -802,7 +803,7 @@ static void cpu_init_hyp_mode(void *vector)
 	unsigned long vector_ptr;
 
 	/* Switch from the HYP stub to our own HYP init vector */
-	__hyp_set_vectors((unsigned long)vector);
+	__hyp_set_vectors(init_vector_addr);
 
 	boot_pgd_ptr = (unsigned long long)kvm_mmu_get_boot_httbr();
 	pgd_ptr = (unsigned long long)kvm_mmu_get_httbr();
@@ -813,12 +814,28 @@ static void cpu_init_hyp_mode(void *vector)
 	__cpu_init_hyp_mode(boot_pgd_ptr, pgd_ptr, hyp_stack_ptr, vector_ptr);
 }
 
+static int hyp_init_cpu_notify(struct notifier_block *self,
+			       unsigned long action, void *cpu)
+{
+	switch (action) {
+	case CPU_STARTING:
+	case CPU_STARTING_FROZEN:
+		cpu_init_hyp_mode(NULL);
+		break;
+	}
+
+	return NOTIFY_OK;
+}
+
+static struct notifier_block hyp_init_cpu_nb = {
+	.notifier_call = hyp_init_cpu_notify,
+};
+
 /**
  * Inits Hyp-mode on all online CPUs
  */
 static int init_hyp_mode(void)
 {
-	phys_addr_t init_phys_addr;
 	int cpu;
 	int err = 0;
 
@@ -851,19 +868,6 @@ static int init_hyp_mode(void)
 	}
 
 	/*
-	 * Execute the init code on each CPU.
-	 *
-	 * Note: The stack is not mapped yet, so don't do anything else than
-	 * initializing the hypervisor mode on each CPU using a local stack
-	 * space for temporary storage.
-	 */
-	init_phys_addr = virt_to_phys(__kvm_hyp_init);
-	for_each_online_cpu(cpu) {
-		smp_call_function_single(cpu, cpu_init_hyp_mode,
-					 (void *)(long)init_phys_addr, 1);
-	}
-
-	/*
 	 * Map the Hyp-code called directly from the host
 	 */
 	err = create_hyp_mappings(__kvm_hyp_code_start, __kvm_hyp_code_end);
@@ -908,6 +912,11 @@ static int init_hyp_mode(void)
 	}
 
 	/*
+	 * Execute the init code on each CPU.
+	 */
+	on_each_cpu(cpu_init_hyp_mode, NULL, 1);
+
+	/*
 	 * Init HYP view of VGIC
 	 */
 	err = kvm_vgic_hyp_init();
@@ -963,6 +972,12 @@ int kvm_arch_init(void *opaque)
 	if (err)
 		goto out_err;
 
+	err = register_cpu_notifier(&hyp_init_cpu_nb);
+	if (err) {
+		kvm_err("Cannot register HYP init CPU notifier (%d)\n", err);
+		goto out_err;
+	}
+
 	kvm_coproc_table_init();
 	return 0;
 out_err:
-- 
1.8.1.4




From marc.zyngier at arm.com  Tue Apr  2 09:25:09 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Tue,  2 Apr 2013 14:25:09 +0100
Subject: [PATCH 1/7] ARM: KVM: simplify HYP mapping population
In-Reply-To: <1364909115-3810-1-git-send-email-marc.zyngier@arm.com>
References: <1364909115-3810-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1364909115-3810-2-git-send-email-marc.zyngier@arm.com>

The way we populate HYP mappings is a bit convoluted, to say the least.
Passing a pointer around to keep track of the current PFN is quite
odd, and we end-up having two different PTE accessors for no good
reason.

Simplify the whole thing by unifying the two PTE accessors, passing
a pgprot_t around, and moving the various validity checks to the
upper layers.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm/kvm/mmu.c | 100 ++++++++++++++++++++++-------------------------------
 1 file changed, 41 insertions(+), 59 deletions(-)

diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
index 2f12e40..24811d1 100644
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@ -125,54 +125,34 @@ void free_hyp_pmds(void)
 }
 
 static void create_hyp_pte_mappings(pmd_t *pmd, unsigned long start,
-				    unsigned long end)
+				    unsigned long end, unsigned long pfn,
+				    pgprot_t prot)
 {
 	pte_t *pte;
 	unsigned long addr;
-	struct page *page;
 
-	for (addr = start & PAGE_MASK; addr < end; addr += PAGE_SIZE) {
-		unsigned long hyp_addr = KERN_TO_HYP(addr);
-
-		pte = pte_offset_kernel(pmd, hyp_addr);
-		BUG_ON(!virt_addr_valid(addr));
-		page = virt_to_page(addr);
-		kvm_set_pte(pte, mk_pte(page, PAGE_HYP));
-	}
-}
-
-static void create_hyp_io_pte_mappings(pmd_t *pmd, unsigned long start,
-				       unsigned long end,
-				       unsigned long *pfn_base)
-{
-	pte_t *pte;
-	unsigned long addr;
-
-	for (addr = start & PAGE_MASK; addr < end; addr += PAGE_SIZE) {
-		unsigned long hyp_addr = KERN_TO_HYP(addr);
-
-		pte = pte_offset_kernel(pmd, hyp_addr);
-		BUG_ON(pfn_valid(*pfn_base));
-		kvm_set_pte(pte, pfn_pte(*pfn_base, PAGE_HYP_DEVICE));
-		(*pfn_base)++;
+	for (addr = start; addr < end; addr += PAGE_SIZE) {
+		pte = pte_offset_kernel(pmd, addr);
+		kvm_set_pte(pte, pfn_pte(pfn, prot));
+		pfn++;
 	}
 }
 
 static int create_hyp_pmd_mappings(pud_t *pud, unsigned long start,
-				   unsigned long end, unsigned long *pfn_base)
+				   unsigned long end, unsigned long pfn,
+				   pgprot_t prot)
 {
 	pmd_t *pmd;
 	pte_t *pte;
 	unsigned long addr, next;
 
 	for (addr = start; addr < end; addr = next) {
-		unsigned long hyp_addr = KERN_TO_HYP(addr);
-		pmd = pmd_offset(pud, hyp_addr);
+		pmd = pmd_offset(pud, addr);
 
 		BUG_ON(pmd_sect(*pmd));
 
 		if (pmd_none(*pmd)) {
-			pte = pte_alloc_one_kernel(NULL, hyp_addr);
+			pte = pte_alloc_one_kernel(NULL, addr);
 			if (!pte) {
 				kvm_err("Cannot allocate Hyp pte\n");
 				return -ENOMEM;
@@ -182,25 +162,17 @@ static int create_hyp_pmd_mappings(pud_t *pud, unsigned long start,
 
 		next = pmd_addr_end(addr, end);
 
-		/*
-		 * If pfn_base is NULL, we map kernel pages into HYP with the
-		 * virtual address. Otherwise, this is considered an I/O
-		 * mapping and we map the physical region starting at
-		 * *pfn_base to [start, end[.
-		 */
-		if (!pfn_base)
-			create_hyp_pte_mappings(pmd, addr, next);
-		else
-			create_hyp_io_pte_mappings(pmd, addr, next, pfn_base);
+		create_hyp_pte_mappings(pmd, addr, next, pfn, prot);
+		pfn += (next - addr) >> PAGE_SHIFT;
 	}
 
 	return 0;
 }
 
-static int __create_hyp_mappings(void *from, void *to, unsigned long *pfn_base)
+static int __create_hyp_mappings(pgd_t *pgdp,
+				 unsigned long start, unsigned long end,
+				 unsigned long pfn, pgprot_t prot)
 {
-	unsigned long start = (unsigned long)from;
-	unsigned long end = (unsigned long)to;
 	pgd_t *pgd;
 	pud_t *pud;
 	pmd_t *pmd;
@@ -209,21 +181,14 @@ static int __create_hyp_mappings(void *from, void *to, unsigned long *pfn_base)
 
 	if (start >= end)
 		return -EINVAL;
-	/* Check for a valid kernel memory mapping */
-	if (!pfn_base && (!virt_addr_valid(from) || !virt_addr_valid(to - 1)))
-		return -EINVAL;
-	/* Check for a valid kernel IO mapping */
-	if (pfn_base && (!is_vmalloc_addr(from) || !is_vmalloc_addr(to - 1)))
-		return -EINVAL;
 
 	mutex_lock(&kvm_hyp_pgd_mutex);
-	for (addr = start; addr < end; addr = next) {
-		unsigned long hyp_addr = KERN_TO_HYP(addr);
-		pgd = hyp_pgd + pgd_index(hyp_addr);
-		pud = pud_offset(pgd, hyp_addr);
+	for (addr = start & PAGE_MASK; addr < end; addr = next) {
+		pgd = pgdp + pgd_index(addr);
+		pud = pud_offset(pgd, addr);
 
 		if (pud_none_or_clear_bad(pud)) {
-			pmd = pmd_alloc_one(NULL, hyp_addr);
+			pmd = pmd_alloc_one(NULL, addr);
 			if (!pmd) {
 				kvm_err("Cannot allocate Hyp pmd\n");
 				err = -ENOMEM;
@@ -233,9 +198,10 @@ static int __create_hyp_mappings(void *from, void *to, unsigned long *pfn_base)
 		}
 
 		next = pgd_addr_end(addr, end);
-		err = create_hyp_pmd_mappings(pud, addr, next, pfn_base);
+		err = create_hyp_pmd_mappings(pud, addr, next, pfn, prot);
 		if (err)
 			goto out;
+		pfn += (next - addr) >> PAGE_SHIFT;
 	}
 out:
 	mutex_unlock(&kvm_hyp_pgd_mutex);
@@ -255,7 +221,16 @@ out:
  */
 int create_hyp_mappings(void *from, void *to)
 {
-	return __create_hyp_mappings(from, to, NULL);
+	unsigned long phys_addr = virt_to_phys(from);
+	unsigned long start = KERN_TO_HYP((unsigned long)from);
+	unsigned long end = KERN_TO_HYP((unsigned long)to);
+
+	/* Check for a valid kernel memory mapping */
+	if (!virt_addr_valid(from) || !virt_addr_valid(to - 1))
+		return -EINVAL;
+
+	return __create_hyp_mappings(hyp_pgd, start, end,
+				     __phys_to_pfn(phys_addr), PAGE_HYP);
 }
 
 /**
@@ -267,10 +242,17 @@ int create_hyp_mappings(void *from, void *to)
  * The resulting HYP VA is the same as the kernel VA, modulo
  * HYP_PAGE_OFFSET.
  */
-int create_hyp_io_mappings(void *from, void *to, phys_addr_t addr)
+int create_hyp_io_mappings(void *from, void *to, phys_addr_t phys_addr)
 {
-	unsigned long pfn = __phys_to_pfn(addr);
-	return __create_hyp_mappings(from, to, &pfn);
+	unsigned long start = KERN_TO_HYP((unsigned long)from);
+	unsigned long end = KERN_TO_HYP((unsigned long)to);
+
+	/* Check for a valid kernel IO mapping */
+	if (!is_vmalloc_addr(from) || !is_vmalloc_addr(to - 1))
+		return -EINVAL;
+
+	return __create_hyp_mappings(hyp_pgd, start, end,
+				     __phys_to_pfn(phys_addr), PAGE_HYP_DEVICE);
 }
 
 /**
-- 
1.8.1.4




From marc.zyngier at arm.com  Tue Apr  2 09:25:14 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Tue,  2 Apr 2013 14:25:14 +0100
Subject: [PATCH 6/7] ARM: KVM: switch to a dual-step HYP init code
In-Reply-To: <1364909115-3810-1-git-send-email-marc.zyngier@arm.com>
References: <1364909115-3810-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1364909115-3810-7-git-send-email-marc.zyngier@arm.com>

Our HYP init code suffers from two major design issues:
- it cannot support CPU hotplug, as we tear down the idmap very early
- it cannot perform a TLB invalidation when switching from init to
  runtime mappings, as pages are manipulated from PL1 exclusively

The hotplug problem mandates that we keep two sets of page tables
(boot and runtime). The TLB problem mandates that we're able to
transition from one PGD to another while in HYP, invalidating the TLBs
in the process.

To be able to do this, we need to share a page between the two page
tables. A page that will have the same VA in both configurations. All we
need is a VA that has the following properties:
- This VA can't be used to represent a kernel mapping.
- This VA will not conflict with the physical address of the kernel text

The vectors page seems to satisfy this requirement:
- The kernel never maps anything else there
- The kernel text being copied at the beginning of the physical memory,
  it is unlikely to use the last 64kB (I doubt we'll ever support KVM
  on a system with something like 4MB of RAM, but patches are very
  welcome).

Let's call this VA the trampoline VA.

Now, we map our init page at 3 locations:
- idmap in the boot pgd
- trampoline VA in the boot pgd
- trampoline VA in the runtime pgd

The init scenario is now the following:
- We jump in HYP with four parameters: boot HYP pgd, runtime HYP pgd,
  runtime stack, runtime vectors
- Enable the MMU with the boot pgd
- Jump to a target into the trampoline page (remember, this is the same
  physical page!)
- Now switch to the runtime pgd (same VA, and still the same physical
  page!)
- Invalidate TLBs
- Set stack and vectors
- Profit! (or eret, if you only care about the code).

Note that we keep the boot mapping permanently (it is not strictly an
idmap anymore) to allow for CPU hotplug in later patches.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm/include/asm/kvm_host.h | 18 ++++++++---
 arch/arm/include/asm/kvm_mmu.h  | 21 ++++++++++--
 arch/arm/kvm/arm.c              |  9 ++----
 arch/arm/kvm/init.S             | 29 +++++++++++++++--
 arch/arm/kvm/mmu.c              | 71 ++++++++++++++++++++++-------------------
 5 files changed, 101 insertions(+), 47 deletions(-)

diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
index a7a0bb5..3556684 100644
--- a/arch/arm/include/asm/kvm_host.h
+++ b/arch/arm/include/asm/kvm_host.h
@@ -190,22 +190,32 @@ int kvm_arm_coproc_set_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *);
 int handle_exit(struct kvm_vcpu *vcpu, struct kvm_run *run,
 		int exception_index);
 
-static inline void __cpu_init_hyp_mode(unsigned long long pgd_ptr,
+static inline void __cpu_init_hyp_mode(unsigned long long boot_pgd_ptr,
+				       unsigned long long pgd_ptr,
 				       unsigned long hyp_stack_ptr,
 				       unsigned long vector_ptr)
 {
 	unsigned long pgd_low, pgd_high;
 
-	pgd_low = (pgd_ptr & ((1ULL << 32) - 1));
-	pgd_high = (pgd_ptr >> 32ULL);
+	pgd_low = (boot_pgd_ptr & ((1ULL << 32) - 1));
+	pgd_high = (boot_pgd_ptr >> 32ULL);
 
 	/*
 	 * Call initialization code, and switch to the full blown
 	 * HYP code. The init code doesn't need to preserve these registers as
-	 * r1-r3 and r12 are already callee save according to the AAPCS.
+	 * r1-r3 and r12 are already callee saved according to the AAPCS.
 	 * Note that we slightly misuse the prototype by casing the pgd_low to
 	 * a void *.
+	 *
+	 * We don't have enough registers to perform the full init in one go.
+	 * Install the boot PGD first, and then install the runtime PGD,
+	 * stack pointer and vectors.
 	 */
+	kvm_call_hyp((void *)pgd_low, pgd_high, 0, 0);
+
+	pgd_low = (pgd_ptr & ((1ULL << 32) - 1));
+	pgd_high = (pgd_ptr >> 32ULL);
+
 	kvm_call_hyp((void *)pgd_low, pgd_high, hyp_stack_ptr, vector_ptr);
 }
 
diff --git a/arch/arm/include/asm/kvm_mmu.h b/arch/arm/include/asm/kvm_mmu.h
index 92eb20d..3567a49 100644
--- a/arch/arm/include/asm/kvm_mmu.h
+++ b/arch/arm/include/asm/kvm_mmu.h
@@ -19,17 +19,29 @@
 #ifndef __ARM_KVM_MMU_H__
 #define __ARM_KVM_MMU_H__
 
-#include <asm/cacheflush.h>
-#include <asm/pgalloc.h>
+#include <asm/memory.h>
+#include <asm/page.h>
 
 /*
  * We directly use the kernel VA for the HYP, as we can directly share
  * the mapping (HTTBR "covers" TTBR1).
  */
-#define HYP_PAGE_OFFSET_MASK	(~0UL)
+#define HYP_PAGE_OFFSET_MASK	UL(~0)
 #define HYP_PAGE_OFFSET		PAGE_OFFSET
 #define KERN_TO_HYP(kva)	(kva)
 
+/*
+ * Our virtual mapping for the boot-time MMU-enable code. Must be
+ * shared across all the page-tables. Conveniently, we use the vectors
+ * page, where no kernel data will ever be shared with HYP.
+ */
+#define TRAMPOLINE_VA		UL(CONFIG_VECTORS_BASE)
+
+#ifndef __ASSEMBLY__
+
+#include <asm/cacheflush.h>
+#include <asm/pgalloc.h>
+
 int create_hyp_mappings(void *from, void *to);
 int create_hyp_io_mappings(void *from, void *to, phys_addr_t);
 void free_hyp_pgds(void);
@@ -44,6 +56,7 @@ int kvm_handle_guest_abort(struct kvm_vcpu *vcpu, struct kvm_run *run);
 void kvm_mmu_free_memory_caches(struct kvm_vcpu *vcpu);
 
 phys_addr_t kvm_mmu_get_httbr(void);
+phys_addr_t kvm_mmu_get_boot_httbr(void);
 int kvm_mmu_init(void);
 void kvm_clear_hyp_idmap(void);
 
@@ -113,4 +126,6 @@ static inline void coherent_icache_guest_page(struct kvm *kvm, gfn_t gfn)
 	}
 }
 
+#endif	/* !__ASSEMBLY__ */
+
 #endif /* __ARM_KVM_MMU_H__ */
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index 6eba879..f0f3290 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -795,6 +795,7 @@ long kvm_arch_vm_ioctl(struct file *filp,
 
 static void cpu_init_hyp_mode(void *vector)
 {
+	unsigned long long boot_pgd_ptr;
 	unsigned long long pgd_ptr;
 	unsigned long hyp_stack_ptr;
 	unsigned long stack_page;
@@ -803,12 +804,13 @@ static void cpu_init_hyp_mode(void *vector)
 	/* Switch from the HYP stub to our own HYP init vector */
 	__hyp_set_vectors((unsigned long)vector);
 
+	boot_pgd_ptr = (unsigned long long)kvm_mmu_get_boot_httbr();
 	pgd_ptr = (unsigned long long)kvm_mmu_get_httbr();
 	stack_page = __get_cpu_var(kvm_arm_hyp_stack_page);
 	hyp_stack_ptr = stack_page + PAGE_SIZE;
 	vector_ptr = (unsigned long)__kvm_hyp_vector;
 
-	__cpu_init_hyp_mode(pgd_ptr, hyp_stack_ptr, vector_ptr);
+	__cpu_init_hyp_mode(boot_pgd_ptr, pgd_ptr, hyp_stack_ptr, vector_ptr);
 }
 
 /**
@@ -862,11 +864,6 @@ static int init_hyp_mode(void)
 	}
 
 	/*
-	 * Unmap the identity mapping
-	 */
-	kvm_clear_hyp_idmap();
-
-	/*
 	 * Map the Hyp-code called directly from the host
 	 */
 	err = create_hyp_mappings(__kvm_hyp_code_start, __kvm_hyp_code_end);
diff --git a/arch/arm/kvm/init.S b/arch/arm/kvm/init.S
index 35a463f..b2c6967 100644
--- a/arch/arm/kvm/init.S
+++ b/arch/arm/kvm/init.S
@@ -21,6 +21,7 @@
 #include <asm/asm-offsets.h>
 #include <asm/kvm_asm.h>
 #include <asm/kvm_arm.h>
+#include <asm/kvm_mmu.h>
 
 /********************************************************************
  * Hypervisor initialization
@@ -47,6 +48,9 @@ __kvm_hyp_init:
 	W(b)	.
 
 __do_hyp_init:
+	cmp	r2, #0			@ We have a SP?
+	bne	phase2			@ Yes, second stage init
+
 	@ Set the HTTBR to point to the hypervisor PGD pointer passed
 	mcrr	p15, 4, r0, r1, c2
 
@@ -96,14 +100,35 @@ __do_hyp_init:
 	orr	r0, r0, r1
 	isb
 	mcr	p15, 4, r0, c1, c0, 0	@ HSCR
-	isb
 
-	@ Set stack pointer and return to the kernel
+	eret
+
+phase2:
+	@ Set stack pointer
 	mov	sp, r2
 
 	@ Set HVBAR to point to the HYP vectors
 	mcr	p15, 4, r3, c12, c0, 0	@ HVBAR
 
+	@ Jump to the trampoline page
+	ldr	r2, =#PAGE_MASK
+	adr	r3, target
+	bic	r3, r3, r2
+	ldr	r2, =#TRAMPOLINE_VA
+	add	r3, r3, r2
+	mov	pc, r3
+
+	nop
+
+target:	@ We're now in the trampoline code, switch page tables
+	mcrr	p15, 4, r0, r1, c2
+	isb
+
+	@ Invalidate the old TLBs
+	mcr	p15, 4, r0, c8, c7, 0	@ TLBIALLH
+	dsb
+	isb
+
 	eret
 
 	.ltorg
diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
index 85b3553..ed5587f 100644
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@ -32,6 +32,7 @@
 
 extern char  __hyp_idmap_text_start[], __hyp_idmap_text_end[];
 
+static pgd_t *boot_hyp_pgd;
 static pgd_t *hyp_pgd;
 static DEFINE_MUTEX(kvm_hyp_pgd_mutex);
 
@@ -111,6 +112,8 @@ static void free_hyp_pgd_entry(pgd_t *pgdp, unsigned long addr)
  * Assumes hyp_pgd is a page table used strictly in Hyp-mode and therefore contains
  * either mappings in the kernel memory area (above PAGE_OFFSET), or
  * device mappings in the vmalloc range (from VMALLOC_START to VMALLOC_END).
+ *
+ * boot_hyp_pgd should only map two pages for the init code.
  */
 void free_hyp_pgds(void)
 {
@@ -118,6 +121,12 @@ void free_hyp_pgds(void)
 
 	mutex_lock(&kvm_hyp_pgd_mutex);
 
+	if (boot_hyp_pgd) {
+		free_hyp_pgd_entry(boot_hyp_pgd, virt_to_phys(__hyp_idmap_text_start));
+		free_hyp_pgd_entry(boot_hyp_pgd, TRAMPOLINE_VA);
+		kfree(boot_hyp_pgd);
+	}
+
 	if (hyp_pgd) {
 		for (addr = PAGE_OFFSET; virt_addr_valid(addr); addr += PGDIR_SIZE)
 			free_hyp_pgd_entry(hyp_pgd, KERN_TO_HYP(addr));
@@ -718,6 +727,12 @@ phys_addr_t kvm_mmu_get_httbr(void)
 	return virt_to_phys(hyp_pgd);
 }
 
+phys_addr_t kvm_mmu_get_boot_httbr(void)
+{
+	VM_BUG_ON(!virt_addr_valid(boot_hyp_pgd));
+	return virt_to_phys(boot_hyp_pgd);
+}
+
 int kvm_mmu_init(void)
 {
 	unsigned long hyp_idmap_start = virt_to_phys(__hyp_idmap_text_start);
@@ -725,7 +740,8 @@ int kvm_mmu_init(void)
 	int err;
 
 	hyp_pgd = kzalloc(PTRS_PER_PGD * sizeof(pgd_t), GFP_KERNEL);
-	if (!hyp_pgd) {
+	boot_hyp_pgd = kzalloc(PTRS_PER_PGD * sizeof(pgd_t), GFP_KERNEL);
+	if (!hyp_pgd || !boot_hyp_pgd) {
 		kvm_err("Hyp mode PGD not allocated\n");
 		err = -ENOMEM;
 		goto out;
@@ -743,39 +759,30 @@ int kvm_mmu_init(void)
 		goto out;
 	}
 
+	/* Map the very same page at the trampoline VA */
+	err = 	__create_hyp_mappings(boot_hyp_pgd,
+				      TRAMPOLINE_VA, TRAMPOLINE_VA + PAGE_SIZE,
+				      __phys_to_pfn(hyp_idmap_start),
+				      PAGE_HYP);
+	if (err) {
+		kvm_err("Failed to map trampoline @%lx into boot HYP pgd\n",
+			TRAMPOLINE_VA);
+		goto out;
+	}
+
+	/* Map the same page again into the runtime page tables */
+	err = 	__create_hyp_mappings(hyp_pgd,
+				      TRAMPOLINE_VA, TRAMPOLINE_VA + PAGE_SIZE,
+				      __phys_to_pfn(hyp_idmap_start),
+				      PAGE_HYP);
+	if (err) {
+		kvm_err("Failed to map trampoline @%lx into runtime HYP pgd\n",
+			TRAMPOLINE_VA);
+		goto out;
+	}
+
 	return 0;
 out:
 	free_hyp_pgds();
 	return err;
 }
-
-/**
- * kvm_clear_idmap - remove all idmaps from the hyp pgd
- *
- * Free the underlying pmds for all pgds in range and clear the pgds (but
- * don't free them) afterwards.
- */
-void kvm_clear_hyp_idmap(void)
-{
-	unsigned long addr, end;
-	unsigned long next;
-	pgd_t *pgd = hyp_pgd;
-	pud_t *pud;
-	pmd_t *pmd;
-
-	addr = virt_to_phys(__hyp_idmap_text_start);
-	end = virt_to_phys(__hyp_idmap_text_end);
-
-	pgd += pgd_index(addr);
-	do {
-		next = pgd_addr_end(addr, end);
-		if (pgd_none_or_clear_bad(pgd))
-			continue;
-		pud = pud_offset(pgd, addr);
-		pmd = pmd_offset(pud, addr);
-
-		pud_clear(pud);
-		kvm_clean_pmd_entry(pmd);
-		pmd_free(NULL, (pmd_t *)((unsigned long)pmd & PAGE_MASK));
-	} while (pgd++, addr = next, addr < end);
-}
-- 
1.8.1.4




From marc.zyngier at arm.com  Tue Apr  2 09:25:08 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Tue,  2 Apr 2013 14:25:08 +0100
Subject: [PATCH 0/7] ARM: KVM: Revamping the HYP init code for fun and profit
Message-ID: <1364909115-3810-1-git-send-email-marc.zyngier@arm.com>

Over the past few weeks, I've gradually realized how broken our HYP
idmap code is. Badly broken.

The main problem is about supporting CPU hotplug. Imagine a CPU being
initialized normally, running VMs, and then being powered down. So
far, so good. Now mentally bring it back online. The CPU will come
back via the secondary CPU boot path, and then what? We cannot use it
anymore, because we need an idmap which is long gone, and because our
page tables are now live, containing the world-switch code, VM
structures, and other bits and pieces.

Another fun issue is that we don't have any TLB invalidation in the
HYP init code. And guess what? we cannot do it! HYP TLB invalidation
has to occur in HYP, and once we've installed the runtime page tables,
it is already too late. It is actually fairly easy to construct a
scenario where idmap and runtime pages have colliding translations.

The nail on the coffin was provided by Catalin Marinas who told me how
much he disliked the arm64 HYP idmap code, and made me realize that we
already have all the necessary code in arch/arm/kvm/mmu.c. It just
needs a tiny bit of care and affection. With a chainsaw.

The solution to the first two issues is a bit tricky, but doesn't
involve a lot of code. The hotplug problem mandates that we keep two
sets of page tables (boot and runtime). The TLB problem mandates that
we're able to transition from one PGD to another while in HYP,
invalidating the TLBs in the process.

To be able to do this, we need to share a page between the two page
tables. A page that will have the same VA in both configurations. All
we need is a VA that has the following properties:
- This VA can't be used to represent a kernel mapping.
- This VA will not conflict with the physical address of the kernel
  text

The vectors page VA seems to satisfy this requirement:
- The kernel never maps anything else there
- The kernel text being copied at the beginning of the physical
  memory, it is unlikely to use the last 64kB (I doubt we'll ever
  support KVM on a system with something like 4MB of RAM, but patches
  are very welcome).

Let's call this VA the trampoline VA.

Now, we map our init page at 3 locations:
- idmap in the boot pgd
- trampoline VA in the boot pgd
- trampoline VA in the runtime pgd

The init scenario is now the following:
- We jump in HYP with four parameters: boot HYP pgd, runtime HYP pgd,
  runtime stack, runtime vectors
- Enable the MMU with the boot pgd
- Jump to a target into the trampoline page (remember, this is the
  same physical page!)
- Now switch to the runtime pgd (same VA, and still the same physical
  page!)
- Invalidate TLBs
- Set stack and vectors
- Profit! (or eret, if you only care about the code).

Once we have this infrastructure in place, supporting CPU hot-plug is
a piece of cake. Just wire a cpu-notifier in the existing code.

This has been tested on both arm (VE TC2) and arm64 (Foundation Model).

Marc Zyngier (7):
  ARM: KVM: simplify HYP mapping population
  ARM: KVM: fix HYP mapping limitations around zero
  ARM: KVM: move to a KVM provided HYP idmap
  ARM: KVM: enforce page alignment for identity mapped code
  ARM: KVM: parametrize HYP page table freeing
  ARM: KVM: switch to a dual-step HYP init code
  ARM: KVM: perform HYP initilization for hotplugged CPUs

 arch/arm/include/asm/idmap.h    |   1 -
 arch/arm/include/asm/kvm_host.h |  18 +++-
 arch/arm/include/asm/kvm_mmu.h  |  24 ++++-
 arch/arm/kernel/vmlinux.lds.S   |   2 +-
 arch/arm/kvm/arm.c              |  58 ++++++----
 arch/arm/kvm/init.S             |  36 ++++++-
 arch/arm/kvm/mmu.c              | 232 +++++++++++++++++++++-------------------
 arch/arm/mm/idmap.c             |  31 +-----
 8 files changed, 227 insertions(+), 175 deletions(-)

-- 
1.8.1.4




From mark.rutland at arm.com  Tue Apr  2 09:28:04 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Tue, 2 Apr 2013 14:28:04 +0100
Subject: [PATCH 4/5] arm: fix up ARM_ARCH_TIMER selects
In-Reply-To: <51534CB4.20009@wwwdotorg.org>
References: <1364404312-4427-1-git-send-email-mark.rutland@arm.com>
 <1364404312-4427-5-git-send-email-mark.rutland@arm.com>
 <51534CB4.20009@wwwdotorg.org>
Message-ID: <20130402132804.GB4021@e106331-lin.cambridge.arm.com>

On Wed, Mar 27, 2013 at 07:47:00PM +0000, Stephen Warren wrote:
> On 03/27/2013 11:11 AM, Mark Rutland wrote:
> > In 8a4da6e: "arm: arch_timer: move core to drivers/clocksource", the
> > selection of ARM_ARCH_TIMER was indirected via HAVE_ARM_ARCH_TIMER,
> > though mach-exynos's selection of ARM_ARCH_TIMER was missed, and since
> > then mach-virt and mach-tegra have begun selecting ARM_ARCH_TIMER. This
> > can lead to architected timer support erroneously appearing to not be
> > selected in menuconfig.
> > 
> > This patch fixes up the Kconfigs for those platforms to select
> > HAVE_ARM_ARCH_TIMER.
> 
> Acked-by: Stephen Warren <swarren at nvidia.com>

Cheers.

> 
> I assume you'll take this patch through some tree of yours.
> 

Yup, that's the plan.

Mark.


From mark.rutland at arm.com  Tue Apr  2 09:29:12 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Tue, 2 Apr 2013 14:29:12 +0100
Subject: [PATCH 0/5] arm: arch_timer cleanups and niceties for 3.10
In-Reply-To: <515331A8.3080101@ti.com>
References: <1364404312-4427-1-git-send-email-mark.rutland@arm.com>
 <515331A8.3080101@ti.com>
Message-ID: <20130402132912.GC4021@e106331-lin.cambridge.arm.com>

On Wed, Mar 27, 2013 at 05:51:36PM +0000, Santosh Shilimkar wrote:
> Mark,
> 
> On Wednesday 27 March 2013 10:41 PM, Mark Rutland wrote:
> > The following patches clean up some (harmless) fallout from the changes
> > in 3.9, and make the driver always use the virtual counter, eliminating
> > problems relating to choosing which counters to use (racy
> > initialisation, branches in hot paths).
> > 
> > The patches are based on  v3.9-rc4, and have been tested on a TC2 with
> > KVM.
> > 
> > The patches can also be found in my public git tree:
> > git://linux-arm.org/git/linux-mr.git clocks/arch-timer-cleanups
> > 
> > Rob, patch 3 "clocksource: arch_timer: use virtual counters" clashes
> > with your CLKSRC_OF patches, but only by the fact nearby lines are
> > alterered. The resolution is trivial and I'm happy to rebase this series
> > as necessary.
> > 
> After scanning the patches, most of them I see as fixes rather than
> clean-up. Patches as such looks fine to me.
> FWIW,
> Acked-by: Santosh Shilimkar <santosh.shilimkar at ti.com>

Cheers.

Mark.


From shawn.guo at linaro.org  Tue Apr  2 09:46:29 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 2 Apr 2013 21:46:29 +0800
Subject: [GIT PULL] imx fixes for 3.9, take 5
Message-ID: <20130402134627.GF24039@S2101-09.ap.freescale.net>

The following changes since commit 07961ac7c0ee8b546658717034fe692fd12eefa9:

  Linux 3.9-rc5 (2013-03-31 15:12:43 -0700)

are available in the git repository at:

  git://git.linaro.org/people/shawnguo/linux-2.6.git tags/imx-fixes-3.9-5

for you to fetch changes up to 710b213d3f1cdb0451fa2d5a71faa2b1f510e3ad:

  ARM: imx35 Bugfix admux clock (2013-04-02 21:05:40 +0800)

----------------------------------------------------------------
The imx fixes for 3.9, take 5:
 - One fix for the typo in use of Kconfig symbol
   MACH_EUKREA_CPUIMX27_USEUART4.  It's been there for a long time
   and got caught by code inspection recently.  It hasn't been noticed
   earlier probably because it does not cause any problem in real.
 - A couple of fixes on imx35 clock driver to have audmux functional
   and iomux pad configurable after a reboot.

----------------------------------------------------------------
Markus Pargmann (2):
      ARM: clk-imx35: Bugfix iomux clock
      ARM: imx35 Bugfix admux clock

Paul Bolle (1):
      cpuimx27 and mbimx27: prepend CONFIG_ to Kconfig macro

 arch/arm/mach-imx/clk-imx35.c                |    2 ++
 arch/arm/mach-imx/eukrea_mbimx27-baseboard.c |    4 ++--
 arch/arm/mach-imx/mach-cpuimx27.c            |    4 ++--
 3 files changed, 6 insertions(+), 4 deletions(-)



From shawn.guo at linaro.org  Tue Apr  2 09:54:21 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 2 Apr 2013 21:54:21 +0800
Subject: [PATCH] ARM: imx: remove Makefile.boot
Message-ID: <1364910861-19178-1-git-send-email-shawn.guo@linaro.org>

Since we have converted IMX to multiplatform build, Makefile.boot is not
used anyway.  Remove it.

Signed-off-by: Shawn Guo <shawn.guo at linaro.org>
---
 arch/arm/mach-imx/Makefile.boot |   35 -----------------------------------
 1 file changed, 35 deletions(-)
 delete mode 100644 arch/arm/mach-imx/Makefile.boot

diff --git a/arch/arm/mach-imx/Makefile.boot b/arch/arm/mach-imx/Makefile.boot
deleted file mode 100644
index 41ba1bb..0000000
--- a/arch/arm/mach-imx/Makefile.boot
+++ /dev/null
@@ -1,35 +0,0 @@
-zreladdr-$(CONFIG_SOC_IMX1)	+= 0x08008000
-params_phys-$(CONFIG_SOC_IMX1)	:= 0x08000100
-initrd_phys-$(CONFIG_SOC_IMX1)	:= 0x08800000
-
-zreladdr-$(CONFIG_SOC_IMX21)	+= 0xC0008000
-params_phys-$(CONFIG_SOC_IMX21)	:= 0xC0000100
-initrd_phys-$(CONFIG_SOC_IMX21)	:= 0xC0800000
-
-zreladdr-$(CONFIG_SOC_IMX25)	+= 0x80008000
-params_phys-$(CONFIG_SOC_IMX25)	:= 0x80000100
-initrd_phys-$(CONFIG_SOC_IMX25)	:= 0x80800000
-
-zreladdr-$(CONFIG_SOC_IMX27)	+= 0xA0008000
-params_phys-$(CONFIG_SOC_IMX27)	:= 0xA0000100
-initrd_phys-$(CONFIG_SOC_IMX27)	:= 0xA0800000
-
-zreladdr-$(CONFIG_SOC_IMX31)	+= 0x80008000
-params_phys-$(CONFIG_SOC_IMX31)	:= 0x80000100
-initrd_phys-$(CONFIG_SOC_IMX31)	:= 0x80800000
-
-zreladdr-$(CONFIG_SOC_IMX35)	+= 0x80008000
-params_phys-$(CONFIG_SOC_IMX35)	:= 0x80000100
-initrd_phys-$(CONFIG_SOC_IMX35)	:= 0x80800000
-
-zreladdr-$(CONFIG_SOC_IMX51)	+= 0x90008000
-params_phys-$(CONFIG_SOC_IMX51)	:= 0x90000100
-initrd_phys-$(CONFIG_SOC_IMX51)	:= 0x90800000
-
-zreladdr-$(CONFIG_SOC_IMX53)	+= 0x70008000
-params_phys-$(CONFIG_SOC_IMX53)	:= 0x70000100
-initrd_phys-$(CONFIG_SOC_IMX53)	:= 0x70800000
-
-zreladdr-$(CONFIG_SOC_IMX6Q)	+= 0x10008000
-params_phys-$(CONFIG_SOC_IMX6Q)	:= 0x10000100
-initrd_phys-$(CONFIG_SOC_IMX6Q)	:= 0x10800000
-- 
1.7.9.5




From javier.martinez at collabora.co.uk  Tue Apr  2 09:57:33 2013
From: javier.martinez at collabora.co.uk (Javier Martinez Canillas)
Date: Tue,  2 Apr 2013 15:57:33 +0200
Subject: [RFC 1/1] of/irq: store IRQ trigger/level in struct resource flags
Message-ID: <1364911053-27442-1-git-send-email-javier.martinez@collabora.co.uk>

According to Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
the "#interrupt-cells" property of an "interrupt-controller" is used
to define the number of cells needed to specify a single interrupt.

A commonly used variant is two cell on which #interrupt-cells = <2>
and the first cell defines the index of the interrupt in the controller
and the second cell is used to specify any of the following flags:

    - bits[3:0] trigger type and level flags
        1 = low-to-high edge triggered
        2 = high-to-low edge triggered
        4 = active high level-sensitive
        8 = active low level-sensitive

An example of an interrupt controller which use the two cell format is
the OMAP GPIO controller that allows GPIO lines to be used as IRQ
(Documentation/devicetree/bindings/gpio/gpio-omap.txt)

But setting #interrupt-cells = <2> on the OMAP GPIO device node and
specifying the GPIO-IRQ type and level flags on the second cell does not
store this value on the populated IORESOURCE_IRQ struct resource.

This is because when using an IRQ from an interrupt controller and
setting both cells (e.g:)

	interrupt-parent = <&gpio6>;
	interrupts = <16 8>;

A call to of_irq_to_resource() is made and this function calls to
irq_of_parse_and_map_type() to get the virtual IRQ mapped to the real
index for this interrupt controller. This IRQ number is populated on
the struct resource:

int of_irq_to_resource(struct device_node *dev, int index, struct resource *r)
{
	int irq = irq_of_parse_and_map(dev, index);
	..
	r->start = r->end = irq;
}

irq_of_parse_and_map() calls to irq_create_of_mapping() which calls to
the correct xlate function handler according to "#interrupt-cells"
(irq_domain_xlate_onecell or irq_domain_xlate_twocell) and to
irq_set_irq_type() to set the IRQ type.

But the type is never returned so it can't be saved on the IRQ struct
resource flags member.

This means that drivers that need the IRQ type/level flags defined in
the DT won't be able to get it.

Signed-off-by: Javier Martinez Canillas <javier.martinez at collabora.co.uk>
---

Hello,

This is a RFC since I don't know if this is the best approach to solve
the issue. I've tested this patch a TI OMAP3 DM3735 SoC board and his
working correctly both with and without DeviceTrees.

I've added an indirection level to keep the patch as small as possible
instead of changing dozens of files to update the callers. I think this
make it easier to review the change.

If you agree with this patch I can send a v2 that juse add a type param
to irq_of_parse_and_map() and irq_create_of_mapping(), updating all the
callers of this functions as well.

Thanks a lot and best regards,

 drivers/of/irq.c       |   30 ++++++++++++++++++++++++------
 include/linux/of_irq.h |    4 ++++
 kernel/irq/irqdomain.c |   14 ++++++++++++--
 3 files changed, 40 insertions(+), 8 deletions(-)

diff --git a/drivers/of/irq.c b/drivers/of/irq.c
index a3c1c5a..6f6aa75 100644
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -27,22 +27,39 @@
 #include <linux/slab.h>
 
 /**
- * irq_of_parse_and_map - Parse and map an interrupt into linux virq space
+ * irq_of_parse_and_map_type - Parse and map an interrupt into linux virq space
  * @device: Device node of the device whose interrupt is to be mapped
  * @index: Index of the interrupt to map
+ * @type: Interrupt trigger type and level flags filled by this function
  *
  * This function is a wrapper that chains of_irq_map_one() and
  * irq_create_of_mapping() to make things easier to callers
  */
-unsigned int irq_of_parse_and_map(struct device_node *dev, int index)
+static unsigned int irq_of_parse_and_map_type(struct device_node *dev,
+					      int index, unsigned int *type)
 {
 	struct of_irq oirq;
+	unsigned int virq;
 
 	if (of_irq_map_one(dev, index, &oirq))
 		return 0;
 
-	return irq_create_of_mapping(oirq.controller, oirq.specifier,
-				     oirq.size);
+	virq = irq_create_of_mapping_type(oirq.controller, oirq.specifier,
+					  oirq.size, type);
+	return virq;
+}
+
+/**
+ * irq_of_parse_and_map - Parse and map an interrupt into linux virq space
+ * @device: Device node of the device whose interrupt is to be mapped
+ * @index: Index of the interrupt to map
+ *
+ * This function is a wrapper of irq_of_parse_and_map_type() when the IRQ
+ * type and level flags are not needed
+ */
+unsigned int irq_of_parse_and_map(struct device_node *dev, int index)
+{
+	return irq_of_parse_and_map_type(dev, index, NULL);
 }
 EXPORT_SYMBOL_GPL(irq_of_parse_and_map);
 
@@ -338,7 +355,8 @@ EXPORT_SYMBOL_GPL(of_irq_map_one);
  */
 int of_irq_to_resource(struct device_node *dev, int index, struct resource *r)
 {
-	int irq = irq_of_parse_and_map(dev, index);
+	int type = IRQ_TYPE_NONE;
+	int irq = irq_of_parse_and_map_type(dev, index, &type);
 
 	/* Only dereference the resource if both the
 	 * resource and the irq are valid. */
@@ -353,7 +371,7 @@ int of_irq_to_resource(struct device_node *dev, int index, struct resource *r)
 					      &name);
 
 		r->start = r->end = irq;
-		r->flags = IORESOURCE_IRQ;
+		r->flags = (IORESOURCE_IRQ | type);
 		r->name = name ? name : dev->full_name;
 	}
 
diff --git a/include/linux/of_irq.h b/include/linux/of_irq.h
index 535cecf..98aec57 100644
--- a/include/linux/of_irq.h
+++ b/include/linux/of_irq.h
@@ -66,6 +66,10 @@ extern int of_irq_map_one(struct device_node *device, int index,
 extern unsigned int irq_create_of_mapping(struct device_node *controller,
 					  const u32 *intspec,
 					  unsigned int intsize);
+extern unsigned int irq_create_of_mapping_type(struct device_node *controller,
+					       const u32 *intspec,
+					       unsigned int intsize,
+					       unsigned int *otype);
 extern int of_irq_to_resource(struct device_node *dev, int index,
 			      struct resource *r);
 extern int of_irq_count(struct device_node *dev);
diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index 96f3a1d..4a2f222 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -636,8 +636,9 @@ int irq_create_strict_mappings(struct irq_domain *domain, unsigned int irq_base,
 }
 EXPORT_SYMBOL_GPL(irq_create_strict_mappings);
 
-unsigned int irq_create_of_mapping(struct device_node *controller,
-				   const u32 *intspec, unsigned int intsize)
+unsigned int irq_create_of_mapping_type(struct device_node *controller,
+					const u32 *intspec, unsigned int intsize,
+					unsigned int *otype)
 {
 	struct irq_domain *domain;
 	irq_hw_number_t hwirq;
@@ -681,8 +682,17 @@ unsigned int irq_create_of_mapping(struct device_node *controller,
 	if (type != IRQ_TYPE_NONE &&
 	    type != (irqd_get_trigger_type(irq_get_irq_data(virq))))
 		irq_set_irq_type(virq, type);
+	if (otype)
+		*otype = type;
 	return virq;
 }
+EXPORT_SYMBOL_GPL(irq_create_of_mapping_type);
+
+unsigned int irq_create_of_mapping(struct device_node *controller,
+				   const u32 *intspec, unsigned int intsize)
+{
+	return irq_create_of_mapping_type(controller, intspec, intsize, NULL);
+}
 EXPORT_SYMBOL_GPL(irq_create_of_mapping);
 
 /**
-- 
1.7.7.6



From s.hauer at pengutronix.de  Tue Apr  2 09:59:19 2013
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Tue, 2 Apr 2013 15:59:19 +0200
Subject: [PATCH] ARM: imx1: mm: add call to mxc_device_init
In-Reply-To: <20130402131630.GE27148@S2101-09.ap.freescale.net>
References: <1363448999-3936-1-git-send-email-gwenhael.goavec-merou@armadeus.com>
 <20130325140940.GH1906@pengutronix.de>
 <20130402131630.GE27148@S2101-09.ap.freescale.net>
Message-ID: <20130402135919.GO1906@pengutronix.de>

On Tue, Apr 02, 2013 at 09:16:33PM +0800, Shawn Guo wrote:
> Sascha,
> 
> On Mon, Mar 25, 2013 at 03:09:40PM +0100, Sascha Hauer wrote:
> > On Sat, Mar 16, 2013 at 04:49:59PM +0100, Gwenhael Goavec-Merou wrote:
> > > mxc_device_init() is mandatory for mxc_aips and mxc_ahb bus registration, needed 
> > > as parents, at least, for gpio and dma.
> > > 
> > > Signed-off-by: Gwenhael Goavec-Merou <gwenhael.goavec-merou at armadeus.com>
> > 
> > Applied, thanks
> 
> I did not see this patch in those you ask me to handle.  Has it been
> handled or just missed?

I seem to have lost it, although I'm pretty sure I really applied it and
not just said so.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From shawn.guo at linaro.org  Tue Apr  2 10:07:35 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 2 Apr 2013 22:07:35 +0800
Subject: [PATCH] ARM: imx: remove mx6q.h
Message-ID: <1364911655-22609-1-git-send-email-shawn.guo@linaro.org>

Those stuff defined in mx6q.h is used nowhere now.  Remove the header.

Signed-off-by: Shawn Guo <shawn.guo at linaro.org>
---
 arch/arm/mach-imx/hardware.h |    1 -
 arch/arm/mach-imx/mx6q.h     |   31 -------------------------------
 2 files changed, 32 deletions(-)
 delete mode 100644 arch/arm/mach-imx/mx6q.h

diff --git a/arch/arm/mach-imx/hardware.h b/arch/arm/mach-imx/hardware.h
index 911e9b3..356131f 100644
--- a/arch/arm/mach-imx/hardware.h
+++ b/arch/arm/mach-imx/hardware.h
@@ -102,7 +102,6 @@
 
 #include "mxc.h"
 
-#include "mx6q.h"
 #include "mx51.h"
 #include "mx53.h"
 #include "mx3x.h"
diff --git a/arch/arm/mach-imx/mx6q.h b/arch/arm/mach-imx/mx6q.h
deleted file mode 100644
index 19d3f54..0000000
--- a/arch/arm/mach-imx/mx6q.h
+++ /dev/null
@@ -1,31 +0,0 @@
-/*
- * Copyright 2011 Freescale Semiconductor, Inc. All Rights Reserved.
- * Copyright 2011 Linaro Ltd.
- *
- * The code contained herein is licensed under the GNU General Public
- * License. You may obtain a copy of the GNU General Public License
- * Version 2 or later at the following locations:
- *
- * http://www.opensource.org/licenses/gpl-license.html
- * http://www.gnu.org/copyleft/gpl.html
- */
-
-#ifndef __MACH_MX6Q_H__
-#define __MACH_MX6Q_H__
-
-#define MX6Q_IO_P2V(x)			IMX_IO_P2V(x)
-#define MX6Q_IO_ADDRESS(x)		IOMEM(MX6Q_IO_P2V(x))
-
-/*
- * The following are the blocks that need to be statically mapped.
- * For other blocks, the base address really should be retrieved from
- * device tree.
- */
-#define MX6Q_SCU_BASE_ADDR		0x00a00000
-#define MX6Q_SCU_SIZE			0x1000
-#define MX6Q_CCM_BASE_ADDR		0x020c4000
-#define MX6Q_CCM_SIZE			0x4000
-#define MX6Q_ANATOP_BASE_ADDR		0x020c8000
-#define MX6Q_ANATOP_SIZE		0x1000
-
-#endif	/* __MACH_MX6Q_H__ */
-- 
1.7.9.5




From shawn.guo at linaro.org  Tue Apr  2 10:19:11 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 2 Apr 2013 22:19:11 +0800
Subject: [PATCH 1/2] ARM: imx_v6_v7_defconfig: add CONFIG_USB_PHY
In-Reply-To: <20130402124407.GE9488@arwen.pp.htv.fi>
References: <1364133966-22373-1-git-send-email-shawn.guo@linaro.org>
 <20130402080706.GC30286@arwen.pp.htv.fi>
 <20130402111245.GC24039@S2101-09.ap.freescale.net>
 <20130402124407.GE9488@arwen.pp.htv.fi>
Message-ID: <20130402141909.GH24039@S2101-09.ap.freescale.net>

On Tue, Apr 02, 2013 at 03:44:07PM +0300, Felipe Balbi wrote:
> alright, in that case can you rebase on next branch ? patch 2 didn't
> apply.

Have you tried "git am -3"?

Shawn



From tixy at linaro.org  Tue Apr  2 10:19:13 2013
From: tixy at linaro.org (Jon Medhurst (Tixy))
Date: Tue, 02 Apr 2013 15:19:13 +0100
Subject: [PATCH] ARM: kprobes: fix test coverage missing failures
In-Reply-To: <1364871884-28252-1-git-send-email-kpark3469@gmail.com>
References: <1364871884-28252-1-git-send-email-kpark3469@gmail.com>
Message-ID: <1364912353.3650.91.camel@linaro1.home>

On Tue, 2013-04-02 at 12:04 +0900, kpark3469 at gmail.com wrote:
> From: Sahara <keun-o.park at windriver.com>
> 
> If kprobe tests run on ARMv6k or ARMv6, there're a number of test
> coverage missing failures like:

The tests only fail (return an error code) for the coverage tests when
compiled for ARMv7 because, obviously, that's the only architecture that
can cover all the combinations of instructions. Perhaps we should just
disabled the coverage tests pre-ARMv7 kernels to avoid the noisy output
you see.

I think the best way to look at it is that the coverage tests are test
code for the test code, and should only be of concern to people updating
the test code.

If we go down the route that this patch follows of conditional
compilation then we are making the main kernel code more messy in order
to support test code and I'm not sure that is a good idea. It will be
much worse should someone want to do the same for ARMv5.

There is also the problem that once you #ifdef things for ARMv6 then you
need an ARMv6 system to test that combination of data structures,
whereas at the moment an ARMv7 board will cover everything.

-- 
Tixy

> FAIL: Register test coverage missing for 0ff000f0 00600090 (04404)
> FAIL: Test coverage entry missing for 0ff000f0 00600090
> FAIL: Test coverage entry missing for 0f200090 00200090
> FAIL: Register test coverage missing for 0fb00000 03000000 (05000)
> FAIL: Test coverage entry missing for 0fb00000 03000000
> FAIL: Test coverage entry missing for 0fff00ff 03200001
> FAIL: Test coverage entry missing for 0fff00ff 03200004
> FAIL: Test coverage entry missing for 0fff00fc 03200000
> FAIL: Test coverage entry missing for 0fb00010 06000010
> FAIL: Test coverage entry missing for 0f8000f0 060000b0
> FAIL: Test coverage entry missing for 0f8000f0 060000d0
> FAIL: Register test coverage missing for 0f800010 06000010 (55005)
> FAIL: Test coverage entry missing for 0f800010 06000010
> FAIL: Test coverage entry missing for 0ff000f0 07f000f0
> FAIL: Register test coverage missing for 0fa00070 07a00050 (05005)
> FAIL: Test coverage entry missing for 0fa00070 07a00050
> FAIL: Register test coverage missing for 0fe0007f 07c0001f (05000)
> FAIL: Test coverage entry missing for 0fe0007f 07c0001f
> FAIL: Register test coverage missing for 0fe00070 07c00010 (05001)
> FAIL: Test coverage entry missing for 0fe00070 07c00010
> 
> Some instructions (like yield, sev, nop, and so on) are available in
> ARMv6k or ARMv7, which we can test by checking the __LINUX_ARM_ARCH__
> or checking the CONFIG_CPU_32v6K.
> While MLS is excluded on ARMv6, more TEST_UNSUPPORTED coverages for
> MLA is needed.
> NOP instruction is used in several predefined macros, and these will
> lead us to get a lot of INSN_REJECTED errors since the nop instruction
> is not included in kprobe_decode_arm_table on ARMv6. By checking the
> __LINUX_ARM_ARCH__ or the CONFIG_CPU_32v6K, 'nop' or 'mov r0,r0' will
> be selected.
> 
> Signed-off-by: Sahara <keun-o.park at windriver.com>
> ---
>  arch/arm/kernel/kprobes-arm.c      |   20 ++++++++++++++++++--
>  arch/arm/kernel/kprobes-test-arm.c |    3 +++
>  arch/arm/kernel/kprobes-test.c     |    2 +-
>  arch/arm/kernel/kprobes-test.h     |   18 ++++++++++++------
>  4 files changed, 34 insertions(+), 9 deletions(-)
> 
> diff --git a/arch/arm/kernel/kprobes-arm.c b/arch/arm/kernel/kprobes-arm.c
> index 8a30c89..324fd22 100644
> --- a/arch/arm/kernel/kprobes-arm.c
> +++ b/arch/arm/kernel/kprobes-arm.c
> @@ -495,10 +495,13 @@ static const union decode_item arm_cccc_0000_____1001_table[] = {
>  
>  	/* MLA			cccc 0000 0010 xxxx xxxx xxxx 1001 xxxx */
>  	/* MLAS			cccc 0000 0011 xxxx xxxx xxxx 1001 xxxx */
> -	DECODE_OR	(0x0fe000f0, 0x00200090),
> +	DECODE_EMULATEX	(0x0fe000f0, 0x00200090, emulate_rd16rn12rm0rs8_rwflags_nopc,
> +						 REGS(NOPC, NOPC, NOPC, 0, NOPC)),
> +#if __LINUX_ARM_ARCH__ >= 7
>  	/* MLS			cccc 0000 0110 xxxx xxxx xxxx 1001 xxxx */
>  	DECODE_EMULATEX	(0x0ff000f0, 0x00600090, emulate_rd16rn12rm0rs8_rwflags_nopc,
>  						 REGS(NOPC, NOPC, NOPC, 0, NOPC)),
> +#endif
>  
>  	/* UMAAL		cccc 0000 0100 xxxx xxxx xxxx 1001 xxxx */
>  	DECODE_OR	(0x0ff000f0, 0x00400090),
> @@ -533,12 +536,14 @@ static const union decode_item arm_cccc_0001_____1001_table[] = {
>  static const union decode_item arm_cccc_000x_____1xx1_table[] = {
>  	/* Extra load/store instructions				*/
>  
> +#if __LINUX_ARM_ARCH__ >= 7
>  	/* STRHT		cccc 0000 xx10 xxxx xxxx xxxx 1011 xxxx */
>  	/* ???			cccc 0000 xx10 xxxx xxxx xxxx 11x1 xxxx */
>  	/* LDRHT		cccc 0000 xx11 xxxx xxxx xxxx 1011 xxxx */
>  	/* LDRSBT		cccc 0000 xx11 xxxx xxxx xxxx 1101 xxxx */
>  	/* LDRSHT		cccc 0000 xx11 xxxx xxxx xxxx 1111 xxxx */
>  	DECODE_REJECT	(0x0f200090, 0x00200090),
> +#endif
>  
>  	/* LDRD/STRD lr,pc,{...	cccc 000x x0x0 xxxx 111x xxxx 1101 xxxx */
>  	DECODE_REJECT	(0x0e10e0d0, 0x0000e0d0),
> @@ -641,11 +646,14 @@ static const union decode_item arm_cccc_000x_table[] = {
>  static const union decode_item arm_cccc_001x_table[] = {
>  	/* Data-processing (immediate)					*/
>  
> +#if __LINUX_ARM_ARCH__ >= 7
>  	/* MOVW			cccc 0011 0000 xxxx xxxx xxxx xxxx xxxx */
>  	/* MOVT			cccc 0011 0100 xxxx xxxx xxxx xxxx xxxx */
>  	DECODE_EMULATEX	(0x0fb00000, 0x03000000, emulate_rd12rm0_noflags_nopc,
>  						 REGS(0, NOPC, 0, 0, 0)),
> +#endif
>  
> +#if (__LINUX_ARM_ARCH__ >= 7) || defined(CONFIG_CPU_32v6K)
>  	/* YIELD		cccc 0011 0010 0000 xxxx xxxx 0000 0001 */
>  	DECODE_OR	(0x0fff00ff, 0x03200001),
>  	/* SEV			cccc 0011 0010 0000 xxxx xxxx 0000 0100 */
> @@ -654,7 +662,9 @@ static const union decode_item arm_cccc_001x_table[] = {
>  	/* WFE			cccc 0011 0010 0000 xxxx xxxx 0000 0010 */
>  	/* WFI			cccc 0011 0010 0000 xxxx xxxx 0000 0011 */
>  	DECODE_SIMULATE	(0x0fff00fc, 0x03200000, kprobe_simulate_nop),
> -	/* DBG			cccc 0011 0010 0000 xxxx xxxx ffff xxxx */
> +	/* DBG			cccc 0011 0010 0000 xxxx xxxx 1111 xxxx */
> +	DECODE_REJECT	(0x0fb000f0, 0x032000f0),
> +#endif
>  	/* unallocated hints	cccc 0011 0010 0000 xxxx xxxx xxxx xxxx */
>  	/* MSR (immediate)	cccc 0011 0x10 xxxx xxxx xxxx xxxx xxxx */
>  	DECODE_REJECT	(0x0fb00000, 0x03200000),
> @@ -712,6 +722,7 @@ static const union decode_item arm_cccc_0110_____xxx1_table[] = {
>  	DECODE_EMULATEX	(0x0fb00070, 0x06b00030, emulate_rd12rm0_noflags_nopc,
>  						 REGS(0, NOPC, 0, 0, NOPC)),
>  
> +#if __LINUX_ARM_ARCH__ >= 7
>  	/* ???			cccc 0110 0x00 xxxx xxxx xxxx xxx1 xxxx */
>  	DECODE_REJECT	(0x0fb00010, 0x06000010),
>  	/* ???			cccc 0110 0xxx xxxx xxxx xxxx 1011 xxxx */
> @@ -756,6 +767,7 @@ static const union decode_item arm_cccc_0110_____xxx1_table[] = {
>  	/* UHSUB8		cccc 0110 0111 xxxx xxxx xxxx 1111 xxxx */
>  	DECODE_EMULATEX	(0x0f800010, 0x06000010, emulate_rd12rn16rm0_rwflags_nopc,
>  						 REGS(NOPC, NOPC, 0, 0, NOPC)),
> +#endif
>  
>  	/* PKHBT		cccc 0110 1000 xxxx xxxx xxxx x001 xxxx */
>  	/* PKHTB		cccc 0110 1000 xxxx xxxx xxxx x101 xxxx */
> @@ -790,8 +802,10 @@ static const union decode_item arm_cccc_0110_____xxx1_table[] = {
>  static const union decode_item arm_cccc_0111_____xxx1_table[] = {
>  	/* Media instructions						*/
>  
> +#if __LINUX_ARM_ARCH__ >= 7
>  	/* UNDEFINED		cccc 0111 1111 xxxx xxxx xxxx 1111 xxxx */
>  	DECODE_REJECT	(0x0ff000f0, 0x07f000f0),
> +#endif
>  
>  	/* SMLALD		cccc 0111 0100 xxxx xxxx xxxx 00x1 xxxx */
>  	/* SMLSLD		cccc 0111 0100 xxxx xxxx xxxx 01x1 xxxx */
> @@ -820,6 +834,7 @@ static const union decode_item arm_cccc_0111_____xxx1_table[] = {
>  	DECODE_EMULATEX	(0x0ff000d0, 0x075000d0, emulate_rd16rn12rm0rs8_rwflags_nopc,
>  						 REGS(NOPC, NOPC, NOPC, 0, NOPC)),
>  
> +#if __LINUX_ARM_ARCH__ >= 7
>  	/* SBFX			cccc 0111 101x xxxx xxxx xxxx x101 xxxx */
>  	/* UBFX			cccc 0111 111x xxxx xxxx xxxx x101 xxxx */
>  	DECODE_EMULATEX	(0x0fa00070, 0x07a00050, emulate_rd12rm0_noflags_nopc,
> @@ -832,6 +847,7 @@ static const union decode_item arm_cccc_0111_____xxx1_table[] = {
>  	/* BFI			cccc 0111 110x xxxx xxxx xxxx x001 xxxx */
>  	DECODE_EMULATEX	(0x0fe00070, 0x07c00010, emulate_rd12rm0_noflags_nopc,
>  						 REGS(0, NOPC, 0, 0, NOPCX)),
> +#endif
>  
>  	DECODE_END
>  };
> diff --git a/arch/arm/kernel/kprobes-test-arm.c b/arch/arm/kernel/kprobes-test-arm.c
> index 8393129..850b7b9 100644
> --- a/arch/arm/kernel/kprobes-test-arm.c
> +++ b/arch/arm/kernel/kprobes-test-arm.c
> @@ -353,6 +353,9 @@ void kprobe_arm_test_cases(void)
>  	TEST_RRR(    "mlahi	r7, r",8, VAL3,", r",9, VAL1,", r",10, VAL2,"")
>  	TEST_RR(     "mla	lr, r",1, VAL2,", r",2, VAL3,", r13")
>  	TEST_UNSUPPORTED(".word 0xe02f3291 @ mla pc, r1, r2, r3")
> +	TEST_UNSUPPORTED(".word 0xe020329f @ mla r0, pc, r2, r3")
> +	TEST_UNSUPPORTED(".word 0xe0203f91 @ mla r0, r1, pc, r3")
> +	TEST_UNSUPPORTED(".word 0xe020f291 @ mla r0, r1, r2, pc")
>  	TEST_RRR(    "mlas	r0, r",1, VAL1,", r",2, VAL2,", r",3,  VAL3,"")
>  	TEST_RRR(    "mlahis	r7, r",8, VAL3,", r",9, VAL1,", r",10, VAL2,"")
>  	TEST_RR(     "mlas	lr, r",1, VAL2,", r",2, VAL3,", r13")
> diff --git a/arch/arm/kernel/kprobes-test.c b/arch/arm/kernel/kprobes-test.c
> index 0cd63d0..0651fd6 100644
> --- a/arch/arm/kernel/kprobes-test.c
> +++ b/arch/arm/kernel/kprobes-test.c
> @@ -478,7 +478,7 @@ static int run_api_tests(long (*func)(long, long))
>  static void __naked benchmark_nop(void)
>  {
>  	__asm__ __volatile__ (
> -		"nop		\n\t"
> +		NOP"		\n\t"
>  		"bx	lr"
>  	);
>  }
> diff --git a/arch/arm/kernel/kprobes-test.h b/arch/arm/kernel/kprobes-test.h
> index e28a869..24822f0 100644
> --- a/arch/arm/kernel/kprobes-test.h
> +++ b/arch/arm/kernel/kprobes-test.h
> @@ -144,20 +144,26 @@ struct test_arg_end {
>  	".code "TEST_ISA"				\n\t"	\
>  	"0:						\n\t"
>  
> +#if (__LINUX_ARM_ARCH__ >= 7) || defined(CONFIG_CPU_32v6K)
> +#define NOP "nop"
> +#else
> +#define NOP "mov	r0, r0"
> +#endif
> +
>  #define TEST_INSTRUCTION(instruction)				\
> -	"50:	nop					\n\t"	\
> +	"50:	"NOP"					\n\t"	\
>  	"1:	"instruction"				\n\t"	\
> -	"	nop					\n\t"
> +	"	"NOP"					\n\t"
>  
>  #define TEST_BRANCH_F(instruction)				\
>  	TEST_INSTRUCTION(instruction)				\
>  	"	b	99f				\n\t"	\
> -	"2:	nop					\n\t"
> +	"2:	"NOP"					\n\t"
>  
>  #define TEST_BRANCH_B(instruction)				\
>  	"	b	50f				\n\t"	\
>  	"	b	99f				\n\t"	\
> -	"2:	nop					\n\t"	\
> +	"2:	"NOP"					\n\t"	\
>  	"	b	99f				\n\t"	\
>  	TEST_INSTRUCTION(instruction)
>  
> @@ -166,12 +172,12 @@ struct test_arg_end {
>  	"	b	99f				\n\t"	\
>  	codex"						\n\t"	\
>  	"	b	99f				\n\t"	\
> -	"2:	nop					\n\t"
> +	"2:	"NOP"					\n\t"
>  
>  #define TEST_BRANCH_BX(instruction, codex)			\
>  	"	b	50f				\n\t"	\
>  	"	b	99f				\n\t"	\
> -	"2:	nop					\n\t"	\
> +	"2:	"NOP"					\n\t"	\
>  	"	b	99f				\n\t"	\
>  	codex"						\n\t"	\
>  	TEST_INSTRUCTION(instruction)




From arnd at arndb.de  Tue Apr  2 10:21:02 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 2 Apr 2013 14:21:02 +0000
Subject: [GIT PULL] ARM: cns3xxx: v3.9-rc1_cns3xxx_fixes
In-Reply-To: <20130330201753.GA15370@lizard>
References: <20130330201753.GA15370@lizard>
Message-ID: <201304021421.02822.arnd@arndb.de>

On Saturday 30 March 2013, Anton Vorontsov wrote:
> Hello Arnd,
> 
> Please pull v3.9-rc1_cns3xxx_fixes tag from the cns3xxx git tree, the tag
> includes Mac Lin's work to revive CNS3xxx booting:
> 
>  "Since commit 0536bdf33faf (ARM: move iotable mappings within the vmalloc
>  region), [...] the pre-defined iotable mappings is not in the vmalloc
>  region. [...] move the iotable mappings into the vmalloc region, and
>  merge the MPCore private memory region (containing the SCU, the GIC and
>  the TWD) as a single region."
> 
> Plus there is a small cosmetic fix, also from Mac Lin.

Given that we're pretty late for 3.9 now, I've only merged the first patch
into the fixes branch but left the second for the next release and merged
it into next/fixes-non-critical.

Thanks to everyone involved getting it to work again!

	Arnd


From stefano.stabellini at eu.citrix.com  Tue Apr  2 10:28:18 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Tue, 2 Apr 2013 15:28:18 +0100
Subject: [PATCH v4 2/2] arm: prefer PSCI for SMP bringup
In-Reply-To: <alpine.LFD.2.03.1304011412030.1171@syhkavp.arg>
References: <1364575371-8926-2-git-send-email-stefano.stabellini@eu.citrix.com>
 <alpine.LFD.2.03.1303291320580.1372@syhkavp.arg>
 <alpine.DEB.2.02.1303291735080.4430@kaball.uk.xensource.com>
 <alpine.LFD.2.03.1303291349150.1372@syhkavp.arg> <5155EC28.8050608@gmail.com>
 <alpine.DEB.2.02.1304011541010.5078@kaball.uk.xensource.com>
 <alpine.LFD.2.03.1304011412030.1171@syhkavp.arg>
Message-ID: <alpine.DEB.2.02.1304021522230.5078@kaball.uk.xensource.com>

On Mon, 1 Apr 2013, Nicolas Pitre wrote:
> On Mon, 1 Apr 2013, Stefano Stabellini wrote:
> 
> > On Fri, 29 Mar 2013, Rob Herring wrote:
> > > On 03/29/2013 12:53 PM, Nicolas Pitre wrote:
> > > > On Fri, 29 Mar 2013, Stefano Stabellini wrote:
> > > > 
> > > >> On Fri, 29 Mar 2013, Nicolas Pitre wrote:
> > > >>> On Fri, 29 Mar 2013, Stefano Stabellini wrote:
> > > >>>
> > > >>>> If PSCI initializes correctly and PSCI SMP operations are available, use them.
> > > >>>> This is required for SMP support in Dom0 on Xen.
> > > >>>>
> > > >>>> Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
> > > >>>> CC: will.deacon at arm.com
> > > >>>> CC: arnd at arndb.de
> > > >>>> CC: marc.zyngier at arm.com
> > > >>>> CC: linux at arm.linux.org.uk
> > > >>>> CC: nico at linaro.org
> > > >>>
> > > >>> I'd suggest you also include in your series the patch I posted earlier 
> > > >>> providing a runtime mdesc->smp_init method as well.
> > > >>
> > > >> OK.
> > > >>
> > > >>
> > > >>> This way the 
> > > >>> priority order would be:
> > > >>>
> > > >>> - If mdesc->smp_init is non null then use that.
> > > >>>
> > > >>> - Otherwise, if PSCI is available then use that.
> > > >>>
> > > >>> - Otherwise use mdesc->smp.
> > > >>>
> > > >>> This way, if the PSCI default has to be overriden (like in the MCPM case 
> > > >>> because it needs to wrap PSCI itself, or to cover Rob's concern) then 
> > > >>> this can be achieved at run time on a per mdesc basis.
> > > >>
> > > >> Actually that's not a bad idea, it could make everybody happy.
> > > >> What about the following, in this precise order:
> > > >>
> > > >> - if a xen hypervisor node is present on device tree, use PSCI;
> > > >> - otherwise if mdesc->smp_init is non null then use it;
> > > >> - otherwise if PSCI is available then use it;
> > > >> - otherwise use mdesc->smp.
> > > >>
> > > >> It's the most practical solution to satisfy everybody's needs.
> > > > 
> > > > Maybe I'm missing something obvious, but why can't xen declare a mdesc 
> > > > of its own?  Given it is going to tweak the DT passed to the kernel 
> > > > anyway that shouldn't be a problem.
> > > 
> > > Xen does have it's own mdesc. It is (or will be) mach-virt, but that is
> > > only for DomU guests. For Dom0, you still need all the platform specific
> > > code except smp_ops. However, I'm doubtful this would work without other
> > > changes on more complicated platforms like OMAP.
> > > 
> > > I would say wait to add this until you have platforms that actually need
> > > the first case.
> > 
> > OK, that is not unreasonable.
> > 
> > What are the platforms that are going to use smp_init? Do we know how do
> > they intend to use it?
> 
> VExpress for one.  When booting on a big.LITTLE system such as TC2 on 
> VExpress, the MCPM layer needs to arbitrate power management operations 
> on a per cluster basis.  In that case there is a MCPM specific set of 
> SMP ops to be used, even if it may end up calling into PSCI.
> 
> But the important point is that we don't know beforehand what to use, 
> especially with a kernel that can boot on multiple different VExpress 
> configurations.  The decision has to be made at run time, and therefore 
> a static default or mdesc->smp ops doesn't cut it.

I certainly like the principle and I am in favor of anything that moves
the decisions at runtime. I have pulled the patch in the series, it's
going to be in the next version.

However I am concerned that these platform specific operations won't
work with Xen at all.
I am getting increasingly certain that we need a Xen specific check in
setup_arch to bump up of the priority of PSCI over anything else if Xen
is running. 


From shawn.guo at linaro.org  Tue Apr  2 10:31:15 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 2 Apr 2013 22:31:15 +0800
Subject: [PATCH 2/6] pinctrl: add pinctrl driver for imx6sl
In-Reply-To: <1364913079-26039-1-git-send-email-shawn.guo@linaro.org>
References: <1364913079-26039-1-git-send-email-shawn.guo@linaro.org>
Message-ID: <1364913079-26039-3-git-send-email-shawn.guo@linaro.org>

Add a pinctrl driver for i.MX6 SoloLite based on pinctrl-imx core
driver.

Signed-off-by: Shawn Guo <shawn.guo at linaro.org>
---
 .../bindings/pinctrl/fsl,imx6sl-pinctrl.txt        |   39 +
 arch/arm/boot/dts/imx6sl-pinfunc.h                 | 1077 ++++++++++++++++++++
 drivers/pinctrl/Kconfig                            |    8 +
 drivers/pinctrl/pinctrl-imx6sl.c                   |  365 +++++++
 4 files changed, 1489 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pinctrl/fsl,imx6sl-pinctrl.txt
 create mode 100644 arch/arm/boot/dts/imx6sl-pinfunc.h
 create mode 100644 drivers/pinctrl/pinctrl-imx6sl.c

diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx6sl-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/fsl,imx6sl-pinctrl.txt
new file mode 100644
index 0000000..e5f6d1f
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx6sl-pinctrl.txt
@@ -0,0 +1,39 @@
+* Freescale IMX6 SoloLite IOMUX Controller
+
+Please refer to fsl,imx-pinctrl.txt in this directory for common binding part
+and usage.
+
+Required properties:
+- compatible: "fsl,imx6sl-iomuxc"
+- fsl,pins: two integers array, represents a group of pins mux and config
+  setting. The format is fsl,pins = <PIN_FUNC_ID CONFIG>, PIN_FUNC_ID is a
+  pin working on a specific function, CONFIG is the pad setting value like
+  pull-up for this pin. Please refer to imx6sl datasheet for the valid pad
+  config settings.
+
+CONFIG bits definition:
+PAD_CTL_LVE                     (1 << 22)
+PAD_CTL_HYS                     (1 << 16)
+PAD_CTL_PUS_100K_DOWN           (0 << 14)
+PAD_CTL_PUS_47K_UP              (1 << 14)
+PAD_CTL_PUS_100K_UP             (2 << 14)
+PAD_CTL_PUS_22K_UP              (3 << 14)
+PAD_CTL_PUE                     (1 << 13)
+PAD_CTL_PKE                     (1 << 12)
+PAD_CTL_ODE                     (1 << 11)
+PAD_CTL_SPEED_LOW               (1 << 6)
+PAD_CTL_SPEED_MED               (2 << 6)
+PAD_CTL_SPEED_HIGH              (3 << 6)
+PAD_CTL_DSE_DISABLE             (0 << 3)
+PAD_CTL_DSE_240ohm              (1 << 3)
+PAD_CTL_DSE_120ohm              (2 << 3)
+PAD_CTL_DSE_80ohm               (3 << 3)
+PAD_CTL_DSE_60ohm               (4 << 3)
+PAD_CTL_DSE_48ohm               (5 << 3)
+PAD_CTL_DSE_40ohm               (6 << 3)
+PAD_CTL_DSE_34ohm               (7 << 3)
+PAD_CTL_SRE_FAST                (1 << 0)
+PAD_CTL_SRE_SLOW                (0 << 0)
+
+Refer to imx6sl-pinfunc.h in device tree source folder for all available
+imx6sl PIN_FUNC_ID.
diff --git a/arch/arm/boot/dts/imx6sl-pinfunc.h b/arch/arm/boot/dts/imx6sl-pinfunc.h
new file mode 100644
index 0000000..77b17bc
--- /dev/null
+++ b/arch/arm/boot/dts/imx6sl-pinfunc.h
@@ -0,0 +1,1077 @@
+/*
+ * Copyright 2013 Freescale Semiconductor, Inc.
+ *
+ * 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.
+ *
+ */
+
+#ifndef __DTS_IMX6SL_PINFUNC_H
+#define __DTS_IMX6SL_PINFUNC_H
+
+/*
+ * The pin function ID is a tuple of
+ * <mux_reg conf_reg input_reg mux_mode input_val>
+ */
+#define MX6SL_PAD_AUD_MCLK__AUDIO_CLK_OUT          0x04c 0x2a4 0x000 0x0 0x0
+#define MX6SL_PAD_AUD_MCLK__PWM4_OUT               0x04c 0x2a4 0x000 0x1 0x0
+#define MX6SL_PAD_AUD_MCLK__ECSPI3_RDY             0x04c 0x2a4 0x6b4 0x2 0x0
+#define MX6SL_PAD_AUD_MCLK__FEC_MDC                0x04c 0x2a4 0x000 0x3 0x0
+#define MX6SL_PAD_AUD_MCLK__WDOG2_RESET_B_DEB      0x04c 0x2a4 0x000 0x4 0x0
+#define MX6SL_PAD_AUD_MCLK__GPIO1_IO06             0x04c 0x2a4 0x000 0x5 0x0
+#define MX6SL_PAD_AUD_MCLK__SPDIF_EXT_CLK          0x04c 0x2a4 0x7f4 0x6 0x0
+#define MX6SL_PAD_AUD_RXC__AUD3_RXC                0x050 0x2a8 0x000 0x0 0x0
+#define MX6SL_PAD_AUD_RXC__I2C1_SDA                0x050 0x2a8 0x720 0x1 0x0
+#define MX6SL_PAD_AUD_RXC__UART3_TX_DATA           0x050 0x2a8 0x000 0x2 0x0
+#define MX6SL_PAD_AUD_RXC__UART3_RX_DATA           0x050 0x2a8 0x80c 0x2 0x0
+#define MX6SL_PAD_AUD_RXC__FEC_TX_CLK              0x050 0x2a8 0x70c 0x3 0x0
+#define MX6SL_PAD_AUD_RXC__I2C3_SDA                0x050 0x2a8 0x730 0x4 0x0
+#define MX6SL_PAD_AUD_RXC__GPIO1_IO01              0x050 0x2a8 0x000 0x5 0x0
+#define MX6SL_PAD_AUD_RXC__ECSPI3_SS1              0x050 0x2a8 0x6c4 0x6 0x0
+#define MX6SL_PAD_AUD_RXD__AUD3_RXD                0x054 0x2ac 0x000 0x0 0x0
+#define MX6SL_PAD_AUD_RXD__ECSPI3_MOSI             0x054 0x2ac 0x6bc 0x1 0x0
+#define MX6SL_PAD_AUD_RXD__UART4_RX_DATA           0x054 0x2ac 0x814 0x2 0x0
+#define MX6SL_PAD_AUD_RXD__UART4_TX_DATA           0x054 0x2ac 0x000 0x2 0x0
+#define MX6SL_PAD_AUD_RXD__FEC_RX_ER               0x054 0x2ac 0x708 0x3 0x0
+#define MX6SL_PAD_AUD_RXD__SD1_LCTL                0x054 0x2ac 0x000 0x4 0x0
+#define MX6SL_PAD_AUD_RXD__GPIO1_IO02              0x054 0x2ac 0x000 0x5 0x0
+#define MX6SL_PAD_AUD_RXFS__AUD3_RXFS              0x058 0x2b0 0x000 0x0 0x0
+#define MX6SL_PAD_AUD_RXFS__I2C1_SCL               0x058 0x2b0 0x71c 0x1 0x0
+#define MX6SL_PAD_AUD_RXFS__UART3_RX_DATA          0x058 0x2b0 0x80c 0x2 0x1
+#define MX6SL_PAD_AUD_RXFS__UART3_TX_DATA          0x058 0x2b0 0x000 0x2 0x0
+#define MX6SL_PAD_AUD_RXFS__FEC_MDIO               0x058 0x2b0 0x6f4 0x3 0x0
+#define MX6SL_PAD_AUD_RXFS__I2C3_SCL               0x058 0x2b0 0x72c 0x4 0x0
+#define MX6SL_PAD_AUD_RXFS__GPIO1_IO00             0x058 0x2b0 0x000 0x5 0x0
+#define MX6SL_PAD_AUD_RXFS__ECSPI3_SS0             0x058 0x2b0 0x6c0 0x6 0x0
+#define MX6SL_PAD_AUD_TXC__AUD3_TXC                0x05c 0x2b4 0x000 0x0 0x0
+#define MX6SL_PAD_AUD_TXC__ECSPI3_MISO             0x05c 0x2b4 0x6b8 0x1 0x0
+#define MX6SL_PAD_AUD_TXC__UART4_TX_DATA           0x05c 0x2b4 0x000 0x2 0x0
+#define MX6SL_PAD_AUD_TXC__UART4_RX_DATA           0x05c 0x2b4 0x814 0x2 0x1
+#define MX6SL_PAD_AUD_TXC__FEC_RX_DV               0x05c 0x2b4 0x704 0x3 0x0
+#define MX6SL_PAD_AUD_TXC__SD2_LCTL                0x05c 0x2b4 0x000 0x4 0x0
+#define MX6SL_PAD_AUD_TXC__GPIO1_IO03              0x05c 0x2b4 0x000 0x5 0x0
+#define MX6SL_PAD_AUD_TXD__AUD3_TXD                0x060 0x2b8 0x000 0x0 0x0
+#define MX6SL_PAD_AUD_TXD__ECSPI3_SCLK             0x060 0x2b8 0x6b0 0x1 0x0
+#define MX6SL_PAD_AUD_TXD__UART4_CTS_B             0x060 0x2b8 0x000 0x2 0x0
+#define MX6SL_PAD_AUD_TXD__UART4_RTS_B             0x060 0x2b8 0x810 0x2 0x0
+#define MX6SL_PAD_AUD_TXD__FEC_TX_DATA0            0x060 0x2b8 0x000 0x3 0x0
+#define MX6SL_PAD_AUD_TXD__SD4_LCTL                0x060 0x2b8 0x000 0x4 0x0
+#define MX6SL_PAD_AUD_TXD__GPIO1_IO05              0x060 0x2b8 0x000 0x5 0x0
+#define MX6SL_PAD_AUD_TXFS__AUD3_TXFS              0x064 0x2bc 0x000 0x0 0x0
+#define MX6SL_PAD_AUD_TXFS__PWM3_OUT               0x064 0x2bc 0x000 0x1 0x0
+#define MX6SL_PAD_AUD_TXFS__UART4_RTS_B            0x064 0x2bc 0x810 0x2 0x1
+#define MX6SL_PAD_AUD_TXFS__UART4_CTS_B            0x064 0x2bc 0x000 0x2 0x0
+#define MX6SL_PAD_AUD_TXFS__FEC_RX_DATA1           0x064 0x2bc 0x6fc 0x3 0x0
+#define MX6SL_PAD_AUD_TXFS__SD3_LCTL               0x064 0x2bc 0x000 0x4 0x0
+#define MX6SL_PAD_AUD_TXFS__GPIO1_IO04             0x064 0x2bc 0x000 0x5 0x0
+#define MX6SL_PAD_ECSPI1_MISO__ECSPI1_MISO         0x068 0x358 0x684 0x0 0x0
+#define MX6SL_PAD_ECSPI1_MISO__AUD4_TXFS           0x068 0x358 0x5f8 0x1 0x0
+#define MX6SL_PAD_ECSPI1_MISO__UART5_RTS_B         0x068 0x358 0x818 0x2 0x0
+#define MX6SL_PAD_ECSPI1_MISO__UART5_CTS_B         0x068 0x358 0x000 0x2 0x0
+#define MX6SL_PAD_ECSPI1_MISO__EPDC_BDR0           0x068 0x358 0x000 0x3 0x0
+#define MX6SL_PAD_ECSPI1_MISO__SD2_WP              0x068 0x358 0x834 0x4 0x0
+#define MX6SL_PAD_ECSPI1_MISO__GPIO4_IO10          0x068 0x358 0x000 0x5 0x0
+#define MX6SL_PAD_ECSPI1_MOSI__ECSPI1_MOSI         0x06c 0x35c 0x688 0x0 0x0
+#define MX6SL_PAD_ECSPI1_MOSI__AUD4_TXC            0x06c 0x35c 0x5f4 0x1 0x0
+#define MX6SL_PAD_ECSPI1_MOSI__UART5_TX_DATA       0x06c 0x35c 0x000 0x2 0x0
+#define MX6SL_PAD_ECSPI1_MOSI__UART5_RX_DATA       0x06c 0x35c 0x81c 0x2 0x0
+#define MX6SL_PAD_ECSPI1_MOSI__EPDC_VCOM1          0x06c 0x35c 0x000 0x3 0x0
+#define MX6SL_PAD_ECSPI1_MOSI__SD2_VSELECT         0x06c 0x35c 0x000 0x4 0x0
+#define MX6SL_PAD_ECSPI1_MOSI__GPIO4_IO09          0x06c 0x35c 0x000 0x5 0x0
+#define MX6SL_PAD_ECSPI1_SCLK__ECSPI1_SCLK         0x070 0x360 0x67c 0x0 0x0
+#define MX6SL_PAD_ECSPI1_SCLK__AUD4_TXD            0x070 0x360 0x5e8 0x1 0x0
+#define MX6SL_PAD_ECSPI1_SCLK__UART5_RX_DATA       0x070 0x360 0x81c 0x2 0x1
+#define MX6SL_PAD_ECSPI1_SCLK__UART5_TX_DATA       0x070 0x360 0x000 0x2 0x0
+#define MX6SL_PAD_ECSPI1_SCLK__EPDC_VCOM0          0x070 0x360 0x000 0x3 0x0
+#define MX6SL_PAD_ECSPI1_SCLK__SD2_RESET           0x070 0x360 0x000 0x4 0x0
+#define MX6SL_PAD_ECSPI1_SCLK__GPIO4_IO08          0x070 0x360 0x000 0x5 0x0
+#define MX6SL_PAD_ECSPI1_SCLK__USB_OTG2_OC         0x070 0x360 0x820 0x6 0x0
+#define MX6SL_PAD_ECSPI1_SS0__ECSPI1_SS0           0x074 0x364 0x68c 0x0 0x0
+#define MX6SL_PAD_ECSPI1_SS0__AUD4_RXD             0x074 0x364 0x5e4 0x1 0x0
+#define MX6SL_PAD_ECSPI1_SS0__UART5_CTS_B          0x074 0x364 0x000 0x2 0x0
+#define MX6SL_PAD_ECSPI1_SS0__UART5_RTS_B          0x074 0x364 0x818 0x2 0x1
+#define MX6SL_PAD_ECSPI1_SS0__EPDC_BDR1            0x074 0x364 0x000 0x3 0x0
+#define MX6SL_PAD_ECSPI1_SS0__SD2_CD_B             0x074 0x364 0x830 0x4 0x0
+#define MX6SL_PAD_ECSPI1_SS0__GPIO4_IO11           0x074 0x364 0x000 0x5 0x0
+#define MX6SL_PAD_ECSPI1_SS0__USB_OTG2_PWR         0x074 0x364 0x000 0x6 0x0
+#define MX6SL_PAD_ECSPI2_MISO__ECSPI2_MISO         0x078 0x368 0x6a0 0x0 0x0
+#define MX6SL_PAD_ECSPI2_MISO__SDMA_EXT_EVENT0     0x078 0x368 0x000 0x1 0x0
+#define MX6SL_PAD_ECSPI2_MISO__UART3_RTS_B         0x078 0x368 0x808 0x2 0x0
+#define MX6SL_PAD_ECSPI2_MISO__UART3_CTS_B         0x078 0x368 0x000 0x2 0x0
+#define MX6SL_PAD_ECSPI2_MISO__CSI_MCLK            0x078 0x368 0x000 0x3 0x0
+#define MX6SL_PAD_ECSPI2_MISO__SD1_WP              0x078 0x368 0x82c 0x4 0x0
+#define MX6SL_PAD_ECSPI2_MISO__GPIO4_IO14          0x078 0x368 0x000 0x5 0x0
+#define MX6SL_PAD_ECSPI2_MISO__USB_OTG1_OC         0x078 0x368 0x824 0x6 0x0
+#define MX6SL_PAD_ECSPI2_MOSI__ECSPI2_MOSI         0x07c 0x36c 0x6a4 0x0 0x0
+#define MX6SL_PAD_ECSPI2_MOSI__SDMA_EXT_EVENT1     0x07c 0x36c 0x000 0x1 0x0
+#define MX6SL_PAD_ECSPI2_MOSI__UART3_TX_DATA       0x07c 0x36c 0x000 0x2 0x0
+#define MX6SL_PAD_ECSPI2_MOSI__UART3_RX_DATA       0x07c 0x36c 0x80c 0x2 0x2
+#define MX6SL_PAD_ECSPI2_MOSI__CSI_HSYNC           0x07c 0x36c 0x670 0x3 0x0
+#define MX6SL_PAD_ECSPI2_MOSI__SD1_VSELECT         0x07c 0x36c 0x000 0x4 0x0
+#define MX6SL_PAD_ECSPI2_MOSI__GPIO4_IO13          0x07c 0x36c 0x000 0x5 0x0
+#define MX6SL_PAD_ECSPI2_SCLK__ECSPI2_SCLK         0x080 0x370 0x69c 0x0 0x0
+#define MX6SL_PAD_ECSPI2_SCLK__SPDIF_EXT_CLK       0x080 0x370 0x7f4 0x1 0x1
+#define MX6SL_PAD_ECSPI2_SCLK__UART3_RX_DATA       0x080 0x370 0x80c 0x2 0x3
+#define MX6SL_PAD_ECSPI2_SCLK__UART3_TX_DATA       0x080 0x370 0x000 0x2 0x0
+#define MX6SL_PAD_ECSPI2_SCLK__CSI_PIXCLK          0x080 0x370 0x674 0x3 0x0
+#define MX6SL_PAD_ECSPI2_SCLK__SD1_RESET           0x080 0x370 0x000 0x4 0x0
+#define MX6SL_PAD_ECSPI2_SCLK__GPIO4_IO12          0x080 0x370 0x000 0x5 0x0
+#define MX6SL_PAD_ECSPI2_SCLK__USB_OTG2_OC         0x080 0x370 0x820 0x6 0x1
+#define MX6SL_PAD_ECSPI2_SS0__ECSPI2_SS0           0x084 0x374 0x6a8 0x0 0x0
+#define MX6SL_PAD_ECSPI2_SS0__ECSPI1_SS3           0x084 0x374 0x698 0x1 0x0
+#define MX6SL_PAD_ECSPI2_SS0__UART3_CTS_B          0x084 0x374 0x000 0x2 0x0
+#define MX6SL_PAD_ECSPI2_SS0__UART3_RTS_B          0x084 0x374 0x808 0x2 0x1
+#define MX6SL_PAD_ECSPI2_SS0__CSI_VSYNC            0x084 0x374 0x678 0x3 0x0
+#define MX6SL_PAD_ECSPI2_SS0__SD1_CD_B             0x084 0x374 0x828 0x4 0x0
+#define MX6SL_PAD_ECSPI2_SS0__GPIO4_IO15           0x084 0x374 0x000 0x5 0x0
+#define MX6SL_PAD_ECSPI2_SS0__USB_OTG1_PWR         0x084 0x374 0x000 0x6 0x0
+#define MX6SL_PAD_EPDC_BDR0__EPDC_BDR0             0x088 0x378 0x000 0x0 0x0
+#define MX6SL_PAD_EPDC_BDR0__SD4_CLK               0x088 0x378 0x850 0x1 0x0
+#define MX6SL_PAD_EPDC_BDR0__UART3_RTS_B           0x088 0x378 0x808 0x2 0x2
+#define MX6SL_PAD_EPDC_BDR0__UART3_CTS_B           0x088 0x378 0x000 0x2 0x0
+#define MX6SL_PAD_EPDC_BDR0__EIM_ADDR26            0x088 0x378 0x000 0x3 0x0
+#define MX6SL_PAD_EPDC_BDR0__SPDC_RL               0x088 0x378 0x000 0x4 0x0
+#define MX6SL_PAD_EPDC_BDR0__GPIO2_IO05            0x088 0x378 0x000 0x5 0x0
+#define MX6SL_PAD_EPDC_BDR0__EPDC_SDCE7            0x088 0x378 0x000 0x6 0x0
+#define MX6SL_PAD_EPDC_BDR1__EPDC_BDR1             0x08c 0x37c 0x000 0x0 0x0
+#define MX6SL_PAD_EPDC_BDR1__SD4_CMD               0x08c 0x37c 0x858 0x1 0x0
+#define MX6SL_PAD_EPDC_BDR1__UART3_CTS_B           0x08c 0x37c 0x000 0x2 0x0
+#define MX6SL_PAD_EPDC_BDR1__UART3_RTS_B           0x08c 0x37c 0x808 0x2 0x3
+#define MX6SL_PAD_EPDC_BDR1__EIM_CRE               0x08c 0x37c 0x000 0x3 0x0
+#define MX6SL_PAD_EPDC_BDR1__SPDC_UD               0x08c 0x37c 0x000 0x4 0x0
+#define MX6SL_PAD_EPDC_BDR1__GPIO2_IO06            0x08c 0x37c 0x000 0x5 0x0
+#define MX6SL_PAD_EPDC_BDR1__EPDC_SDCE8            0x08c 0x37c 0x000 0x6 0x0
+#define MX6SL_PAD_EPDC_D0__EPDC_DATA00             0x090 0x380 0x000 0x0 0x0
+#define MX6SL_PAD_EPDC_D0__ECSPI4_MOSI             0x090 0x380 0x6d8 0x1 0x0
+#define MX6SL_PAD_EPDC_D0__LCD_DATA24              0x090 0x380 0x000 0x2 0x0
+#define MX6SL_PAD_EPDC_D0__CSI_DATA00              0x090 0x380 0x630 0x3 0x0
+#define MX6SL_PAD_EPDC_D0__SPDC_DATA00             0x090 0x380 0x000 0x4 0x0
+#define MX6SL_PAD_EPDC_D0__GPIO1_IO07              0x090 0x380 0x000 0x5 0x0
+#define MX6SL_PAD_EPDC_D1__EPDC_DATA01             0x094 0x384 0x000 0x0 0x0
+#define MX6SL_PAD_EPDC_D1__ECSPI4_MISO             0x094 0x384 0x6d4 0x1 0x0
+#define MX6SL_PAD_EPDC_D1__LCD_DATA25              0x094 0x384 0x000 0x2 0x0
+#define MX6SL_PAD_EPDC_D1__CSI_DATA01              0x094 0x384 0x634 0x3 0x0
+#define MX6SL_PAD_EPDC_D1__SPDC_DATA01             0x094 0x384 0x000 0x4 0x0
+#define MX6SL_PAD_EPDC_D1__GPIO1_IO08              0x094 0x384 0x000 0x5 0x0
+#define MX6SL_PAD_EPDC_D10__EPDC_DATA10            0x098 0x388 0x000 0x0 0x0
+#define MX6SL_PAD_EPDC_D10__ECSPI3_SS0             0x098 0x388 0x6c0 0x1 0x1
+#define MX6SL_PAD_EPDC_D10__EPDC_PWR_CTRL2         0x098 0x388 0x000 0x2 0x0
+#define MX6SL_PAD_EPDC_D10__EIM_ADDR18             0x098 0x388 0x000 0x3 0x0
+#define MX6SL_PAD_EPDC_D10__SPDC_DATA10            0x098 0x388 0x000 0x4 0x0
+#define MX6SL_PAD_EPDC_D10__GPIO1_IO17             0x098 0x388 0x000 0x5 0x0
+#define MX6SL_PAD_EPDC_D10__SD4_WP                 0x098 0x388 0x87c 0x6 0x0
+#define MX6SL_PAD_EPDC_D11__EPDC_DATA11            0x09c 0x38c 0x000 0x0 0x0
+#define MX6SL_PAD_EPDC_D11__ECSPI3_SCLK            0x09c 0x38c 0x6b0 0x1 0x1
+#define MX6SL_PAD_EPDC_D11__EPDC_PWR_CTRL3         0x09c 0x38c 0x000 0x2 0x0
+#define MX6SL_PAD_EPDC_D11__EIM_ADDR19             0x09c 0x38c 0x000 0x3 0x0
+#define MX6SL_PAD_EPDC_D11__SPDC_DATA11            0x09c 0x38c 0x000 0x4 0x0
+#define MX6SL_PAD_EPDC_D11__GPIO1_IO18             0x09c 0x38c 0x000 0x5 0x0
+#define MX6SL_PAD_EPDC_D11__SD4_CD_B               0x09c 0x38c 0x854 0x6 0x0
+#define MX6SL_PAD_EPDC_D12__EPDC_DATA12            0x0a0 0x390 0x000 0x0 0x0
+#define MX6SL_PAD_EPDC_D12__UART2_RX_DATA          0x0a0 0x390 0x804 0x1 0x0
+#define MX6SL_PAD_EPDC_D12__UART2_TX_DATA          0x0a0 0x390 0x000 0x1 0x0
+#define MX6SL_PAD_EPDC_D12__EPDC_PWR_COM           0x0a0 0x390 0x000 0x2 0x0
+#define MX6SL_PAD_EPDC_D12__EIM_ADDR20             0x0a0 0x390 0x000 0x3 0x0
+#define MX6SL_PAD_EPDC_D12__SPDC_DATA12            0x0a0 0x390 0x000 0x4 0x0
+#define MX6SL_PAD_EPDC_D12__GPIO1_IO19             0x0a0 0x390 0x000 0x5 0x0
+#define MX6SL_PAD_EPDC_D12__ECSPI3_SS1             0x0a0 0x390 0x6c4 0x6 0x1
+#define MX6SL_PAD_EPDC_D13__EPDC_DATA13            0x0a4 0x394 0x000 0x0 0x0
+#define MX6SL_PAD_EPDC_D13__UART2_TX_DATA          0x0a4 0x394 0x000 0x1 0x0
+#define MX6SL_PAD_EPDC_D13__UART2_RX_DATA          0x0a4 0x394 0x804 0x1 0x1
+#define MX6SL_PAD_EPDC_D13__EPDC_PWR_IRQ           0x0a4 0x394 0x6e8 0x2 0x0
+#define MX6SL_PAD_EPDC_D13__EIM_ADDR21             0x0a4 0x394 0x000 0x3 0x0
+#define MX6SL_PAD_EPDC_D13__SPDC_DATA13            0x0a4 0x394 0x000 0x4 0x0
+#define MX6SL_PAD_EPDC_D13__GPIO1_IO20             0x0a4 0x394 0x000 0x5 0x0
+#define MX6SL_PAD_EPDC_D13__ECSPI3_SS2             0x0a4 0x394 0x6c8 0x6 0x0
+#define MX6SL_PAD_EPDC_D14__EPDC_DATA14            0x0a8 0x398 0x000 0x0 0x0
+#define MX6SL_PAD_EPDC_D14__UART2_RTS_B            0x0a8 0x398 0x800 0x1 0x0
+#define MX6SL_PAD_EPDC_D14__UART2_CTS_B            0x0a8 0x398 0x000 0x1 0x0
+#define MX6SL_PAD_EPDC_D14__EPDC_PWR_STAT          0x0a8 0x398 0x6ec 0x2 0x0
+#define MX6SL_PAD_EPDC_D14__EIM_ADDR22             0x0a8 0x398 0x000 0x3 0x0
+#define MX6SL_PAD_EPDC_D14__SPDC_DATA14            0x0a8 0x398 0x000 0x4 0x0
+#define MX6SL_PAD_EPDC_D14__GPIO1_IO21             0x0a8 0x398 0x000 0x5 0x0
+#define MX6SL_PAD_EPDC_D14__ECSPI3_SS3             0x0a8 0x398 0x6cc 0x6 0x0
+#define MX6SL_PAD_EPDC_D15__EPDC_DATA15            0x0ac 0x39c 0x000 0x0 0x0
+#define MX6SL_PAD_EPDC_D15__UART2_CTS_B            0x0ac 0x39c 0x000 0x1 0x0
+#define MX6SL_PAD_EPDC_D15__UART2_RTS_B            0x0ac 0x39c 0x800 0x1 0x1
+#define MX6SL_PAD_EPDC_D15__EPDC_PWR_WAKE          0x0ac 0x39c 0x000 0x2 0x0
+#define MX6SL_PAD_EPDC_D15__EIM_ADDR23             0x0ac 0x39c 0x000 0x3 0x0
+#define MX6SL_PAD_EPDC_D15__SPDC_DATA15            0x0ac 0x39c 0x000 0x4 0x0
+#define MX6SL_PAD_EPDC_D15__GPIO1_IO22             0x0ac 0x39c 0x000 0x5 0x0
+#define MX6SL_PAD_EPDC_D15__ECSPI3_RDY             0x0ac 0x39c 0x6b4 0x6 0x1
+#define MX6SL_PAD_EPDC_D2__EPDC_DATA02             0x0b0 0x3a0 0x000 0x0 0x0
+#define MX6SL_PAD_EPDC_D2__ECSPI4_SS0              0x0b0 0x3a0 0x6dc 0x1 0x0
+#define MX6SL_PAD_EPDC_D2__LCD_DATA26              0x0b0 0x3a0 0x000 0x2 0x0
+#define MX6SL_PAD_EPDC_D2__CSI_DATA02              0x0b0 0x3a0 0x638 0x3 0x0
+#define MX6SL_PAD_EPDC_D2__SPDC_DATA02             0x0b0 0x3a0 0x000 0x4 0x0
+#define MX6SL_PAD_EPDC_D2__GPIO1_IO09              0x0b0 0x3a0 0x000 0x5 0x0
+#define MX6SL_PAD_EPDC_D3__EPDC_DATA03             0x0b4 0x3a4 0x000 0x0 0x0
+#define MX6SL_PAD_EPDC_D3__ECSPI4_SCLK             0x0b4 0x3a4 0x6d0 0x1 0x0
+#define MX6SL_PAD_EPDC_D3__LCD_DATA27              0x0b4 0x3a4 0x000 0x2 0x0
+#define MX6SL_PAD_EPDC_D3__CSI_DATA03              0x0b4 0x3a4 0x63c 0x3 0x0
+#define MX6SL_PAD_EPDC_D3__SPDC_DATA03             0x0b4 0x3a4 0x000 0x4 0x0
+#define MX6SL_PAD_EPDC_D3__GPIO1_IO10              0x0b4 0x3a4 0x000 0x5 0x0
+#define MX6SL_PAD_EPDC_D4__EPDC_DATA04             0x0b8 0x3a8 0x000 0x0 0x0
+#define MX6SL_PAD_EPDC_D4__ECSPI4_SS1              0x0b8 0x3a8 0x6e0 0x1 0x0
+#define MX6SL_PAD_EPDC_D4__LCD_DATA28              0x0b8 0x3a8 0x000 0x2 0x0
+#define MX6SL_PAD_EPDC_D4__CSI_DATA04              0x0b8 0x3a8 0x640 0x3 0x0
+#define MX6SL_PAD_EPDC_D4__SPDC_DATA04             0x0b8 0x3a8 0x000 0x4 0x0
+#define MX6SL_PAD_EPDC_D4__GPIO1_IO11              0x0b8 0x3a8 0x000 0x5 0x0
+#define MX6SL_PAD_EPDC_D5__EPDC_DATA05             0x0bc 0x3ac 0x000 0x0 0x0
+#define MX6SL_PAD_EPDC_D5__ECSPI4_SS2              0x0bc 0x3ac 0x6e4 0x1 0x0
+#define MX6SL_PAD_EPDC_D5__LCD_DATA29              0x0bc 0x3ac 0x000 0x2 0x0
+#define MX6SL_PAD_EPDC_D5__CSI_DATA05              0x0bc 0x3ac 0x644 0x3 0x0
+#define MX6SL_PAD_EPDC_D5__SPDC_DATA05             0x0bc 0x3ac 0x000 0x4 0x0
+#define MX6SL_PAD_EPDC_D5__GPIO1_IO12              0x0bc 0x3ac 0x000 0x5 0x0
+#define MX6SL_PAD_EPDC_D6__EPDC_DATA06             0x0c0 0x3b0 0x000 0x0 0x0
+#define MX6SL_PAD_EPDC_D6__ECSPI4_SS3              0x0c0 0x3b0 0x000 0x1 0x0
+#define MX6SL_PAD_EPDC_D6__LCD_DATA30              0x0c0 0x3b0 0x000 0x2 0x0
+#define MX6SL_PAD_EPDC_D6__CSI_DATA06              0x0c0 0x3b0 0x648 0x3 0x0
+#define MX6SL_PAD_EPDC_D6__SPDC_DATA06             0x0c0 0x3b0 0x000 0x4 0x0
+#define MX6SL_PAD_EPDC_D6__GPIO1_IO13              0x0c0 0x3b0 0x000 0x5 0x0
+#define MX6SL_PAD_EPDC_D7__EPDC_DATA07             0x0c4 0x3b4 0x000 0x0 0x0
+#define MX6SL_PAD_EPDC_D7__ECSPI4_RDY              0x0c4 0x3b4 0x000 0x1 0x0
+#define MX6SL_PAD_EPDC_D7__LCD_DATA31              0x0c4 0x3b4 0x000 0x2 0x0
+#define MX6SL_PAD_EPDC_D7__CSI_DATA07              0x0c4 0x3b4 0x64c 0x3 0x0
+#define MX6SL_PAD_EPDC_D7__SPDC_DATA07             0x0c4 0x3b4 0x000 0x4 0x0
+#define MX6SL_PAD_EPDC_D7__GPIO1_IO14              0x0c4 0x3b4 0x000 0x5 0x0
+#define MX6SL_PAD_EPDC_D8__EPDC_DATA08             0x0c8 0x3b8 0x000 0x0 0x0
+#define MX6SL_PAD_EPDC_D8__ECSPI3_MOSI             0x0c8 0x3b8 0x6bc 0x1 0x1
+#define MX6SL_PAD_EPDC_D8__EPDC_PWR_CTRL0          0x0c8 0x3b8 0x000 0x2 0x0
+#define MX6SL_PAD_EPDC_D8__EIM_ADDR16              0x0c8 0x3b8 0x000 0x3 0x0
+#define MX6SL_PAD_EPDC_D8__SPDC_DATA08             0x0c8 0x3b8 0x000 0x4 0x0
+#define MX6SL_PAD_EPDC_D8__GPIO1_IO15              0x0c8 0x3b8 0x000 0x5 0x0
+#define MX6SL_PAD_EPDC_D8__SD4_RESET               0x0c8 0x3b8 0x000 0x6 0x0
+#define MX6SL_PAD_EPDC_D9__EPDC_DATA09             0x0cc 0x3bc 0x000 0x0 0x0
+#define MX6SL_PAD_EPDC_D9__ECSPI3_MISO             0x0cc 0x3bc 0x6b8 0x1 0x1
+#define MX6SL_PAD_EPDC_D9__EPDC_PWR_CTRL1          0x0cc 0x3bc 0x000 0x2 0x0
+#define MX6SL_PAD_EPDC_D9__EIM_ADDR17              0x0cc 0x3bc 0x000 0x3 0x0
+#define MX6SL_PAD_EPDC_D9__SPDC_DATA09             0x0cc 0x3bc 0x000 0x4 0x0
+#define MX6SL_PAD_EPDC_D9__GPIO1_IO16              0x0cc 0x3bc 0x000 0x5 0x0
+#define MX6SL_PAD_EPDC_D9__SD4_VSELECT             0x0cc 0x3bc 0x000 0x6 0x0
+#define MX6SL_PAD_EPDC_GDCLK__EPDC_GDCLK           0x0d0 0x3c0 0x000 0x0 0x0
+#define MX6SL_PAD_EPDC_GDCLK__ECSPI2_SS2           0x0d0 0x3c0 0x000 0x1 0x0
+#define MX6SL_PAD_EPDC_GDCLK__SPDC_YCKR            0x0d0 0x3c0 0x000 0x2 0x0
+#define MX6SL_PAD_EPDC_GDCLK__CSI_PIXCLK           0x0d0 0x3c0 0x674 0x3 0x1
+#define MX6SL_PAD_EPDC_GDCLK__SPDC_YCKL            0x0d0 0x3c0 0x000 0x4 0x0
+#define MX6SL_PAD_EPDC_GDCLK__GPIO1_IO31           0x0d0 0x3c0 0x000 0x5 0x0
+#define MX6SL_PAD_EPDC_GDCLK__SD2_RESET            0x0d0 0x3c0 0x000 0x6 0x0
+#define MX6SL_PAD_EPDC_GDOE__EPDC_GDOE             0x0d4 0x3c4 0x000 0x0 0x0
+#define MX6SL_PAD_EPDC_GDOE__ECSPI2_SS3            0x0d4 0x3c4 0x000 0x1 0x0
+#define MX6SL_PAD_EPDC_GDOE__SPDC_YOER             0x0d4 0x3c4 0x000 0x2 0x0
+#define MX6SL_PAD_EPDC_GDOE__CSI_HSYNC             0x0d4 0x3c4 0x670 0x3 0x1
+#define MX6SL_PAD_EPDC_GDOE__SPDC_YOEL             0x0d4 0x3c4 0x000 0x4 0x0
+#define MX6SL_PAD_EPDC_GDOE__GPIO2_IO00            0x0d4 0x3c4 0x000 0x5 0x0
+#define MX6SL_PAD_EPDC_GDOE__SD2_VSELECT           0x0d4 0x3c4 0x000 0x6 0x0
+#define MX6SL_PAD_EPDC_GDRL__EPDC_GDRL             0x0d8 0x3c8 0x000 0x0 0x0
+#define MX6SL_PAD_EPDC_GDRL__ECSPI2_RDY            0x0d8 0x3c8 0x000 0x1 0x0
+#define MX6SL_PAD_EPDC_GDRL__SPDC_YDIOUR           0x0d8 0x3c8 0x000 0x2 0x0
+#define MX6SL_PAD_EPDC_GDRL__CSI_MCLK              0x0d8 0x3c8 0x000 0x3 0x0
+#define MX6SL_PAD_EPDC_GDRL__SPDC_YDIOUL           0x0d8 0x3c8 0x000 0x4 0x0
+#define MX6SL_PAD_EPDC_GDRL__GPIO2_IO01            0x0d8 0x3c8 0x000 0x5 0x0
+#define MX6SL_PAD_EPDC_GDRL__SD2_WP                0x0d8 0x3c8 0x834 0x6 0x1
+#define MX6SL_PAD_EPDC_GDSP__EPDC_GDSP             0x0dc 0x3cc 0x000 0x0 0x0
+#define MX6SL_PAD_EPDC_GDSP__PWM4_OUT              0x0dc 0x3cc 0x000 0x1 0x0
+#define MX6SL_PAD_EPDC_GDSP__SPDC_YDIODR           0x0dc 0x3cc 0x000 0x2 0x0
+#define MX6SL_PAD_EPDC_GDSP__CSI_VSYNC             0x0dc 0x3cc 0x678 0x3 0x1
+#define MX6SL_PAD_EPDC_GDSP__SPDC_YDIODL           0x0dc 0x3cc 0x000 0x4 0x0
+#define MX6SL_PAD_EPDC_GDSP__GPIO2_IO02            0x0dc 0x3cc 0x000 0x5 0x0
+#define MX6SL_PAD_EPDC_GDSP__SD2_CD_B              0x0dc 0x3cc 0x830 0x6 0x1
+#define MX6SL_PAD_EPDC_PWRCOM__EPDC_PWR_COM        0x0e0 0x3d0 0x000 0x0 0x0
+#define MX6SL_PAD_EPDC_PWRCOM__SD4_DATA0           0x0e0 0x3d0 0x85c 0x1 0x0
+#define MX6SL_PAD_EPDC_PWRCOM__LCD_DATA20          0x0e0 0x3d0 0x7c8 0x2 0x0
+#define MX6SL_PAD_EPDC_PWRCOM__EIM_BCLK            0x0e0 0x3d0 0x000 0x3 0x0
+#define MX6SL_PAD_EPDC_PWRCOM__USB_OTG1_ID         0x0e0 0x3d0 0x5dc 0x4 0x0
+#define MX6SL_PAD_EPDC_PWRCOM__GPIO2_IO11          0x0e0 0x3d0 0x000 0x5 0x0
+#define MX6SL_PAD_EPDC_PWRCOM__SD3_RESET           0x0e0 0x3d0 0x000 0x6 0x0
+#define MX6SL_PAD_EPDC_PWRCTRL0__EPDC_PWR_CTRL0    0x0e4 0x3d4 0x000 0x0 0x0
+#define MX6SL_PAD_EPDC_PWRCTRL0__AUD5_RXC          0x0e4 0x3d4 0x604 0x1 0x0
+#define MX6SL_PAD_EPDC_PWRCTRL0__LCD_DATA16        0x0e4 0x3d4 0x7b8 0x2 0x0
+#define MX6SL_PAD_EPDC_PWRCTRL0__EIM_RW            0x0e4 0x3d4 0x000 0x3 0x0
+#define MX6SL_PAD_EPDC_PWRCTRL0__SPDC_YCKL         0x0e4 0x3d4 0x000 0x4 0x0
+#define MX6SL_PAD_EPDC_PWRCTRL0__GPIO2_IO07        0x0e4 0x3d4 0x000 0x5 0x0
+#define MX6SL_PAD_EPDC_PWRCTRL0__SD4_RESET         0x0e4 0x3d4 0x000 0x6 0x0
+#define MX6SL_PAD_EPDC_PWRCTRL1__EPDC_PWR_CTRL1    0x0e8 0x3d8 0x000 0x0 0x0
+#define MX6SL_PAD_EPDC_PWRCTRL1__AUD5_TXFS         0x0e8 0x3d8 0x610 0x1 0x0
+#define MX6SL_PAD_EPDC_PWRCTRL1__LCD_DATA17        0x0e8 0x3d8 0x7bc 0x2 0x0
+#define MX6SL_PAD_EPDC_PWRCTRL1__EIM_OE_B          0x0e8 0x3d8 0x000 0x3 0x0
+#define MX6SL_PAD_EPDC_PWRCTRL1__SPDC_YOEL         0x0e8 0x3d8 0x000 0x4 0x0
+#define MX6SL_PAD_EPDC_PWRCTRL1__GPIO2_IO08        0x0e8 0x3d8 0x000 0x5 0x0
+#define MX6SL_PAD_EPDC_PWRCTRL1__SD4_VSELECT       0x0e8 0x3d8 0x000 0x6 0x0
+#define MX6SL_PAD_EPDC_PWRCTRL2__EPDC_PWR_CTRL2    0x0ec 0x3dc 0x000 0x0 0x0
+#define MX6SL_PAD_EPDC_PWRCTRL2__AUD5_TXD          0x0ec 0x3dc 0x600 0x1 0x0
+#define MX6SL_PAD_EPDC_PWRCTRL2__LCD_DATA18        0x0ec 0x3dc 0x7c0 0x2 0x0
+#define MX6SL_PAD_EPDC_PWRCTRL2__EIM_CS0_B         0x0ec 0x3dc 0x000 0x3 0x0
+#define MX6SL_PAD_EPDC_PWRCTRL2__SPDC_YDIOUL       0x0ec 0x3dc 0x000 0x4 0x0
+#define MX6SL_PAD_EPDC_PWRCTRL2__GPIO2_IO09        0x0ec 0x3dc 0x000 0x5 0x0
+#define MX6SL_PAD_EPDC_PWRCTRL2__SD4_WP            0x0ec 0x3dc 0x87c 0x6 0x1
+#define MX6SL_PAD_EPDC_PWRCTRL3__EPDC_PWR_CTRL3    0x0f0 0x3e0 0x000 0x0 0x0
+#define MX6SL_PAD_EPDC_PWRCTRL3__AUD5_TXC          0x0f0 0x3e0 0x60c 0x1 0x0
+#define MX6SL_PAD_EPDC_PWRCTRL3__LCD_DATA19        0x0f0 0x3e0 0x7c4 0x2 0x0
+#define MX6SL_PAD_EPDC_PWRCTRL3__EIM_CS1_B         0x0f0 0x3e0 0x000 0x3 0x0
+#define MX6SL_PAD_EPDC_PWRCTRL3__SPDC_YDIODL       0x0f0 0x3e0 0x000 0x4 0x0
+#define MX6SL_PAD_EPDC_PWRCTRL3__GPIO2_IO10        0x0f0 0x3e0 0x000 0x5 0x0
+#define MX6SL_PAD_EPDC_PWRCTRL3__SD4_CD_B          0x0f0 0x3e0 0x854 0x6 0x1
+#define MX6SL_PAD_EPDC_PWRINT__EPDC_PWR_IRQ        0x0f4 0x3e4 0x6e8 0x0 0x1
+#define MX6SL_PAD_EPDC_PWRINT__SD4_DATA1           0x0f4 0x3e4 0x860 0x1 0x0
+#define MX6SL_PAD_EPDC_PWRINT__LCD_DATA21          0x0f4 0x3e4 0x7cc 0x2 0x0
+#define MX6SL_PAD_EPDC_PWRINT__EIM_ACLK_FREERUN    0x0f4 0x3e4 0x000 0x3 0x0
+#define MX6SL_PAD_EPDC_PWRINT__USB_OTG2_ID         0x0f4 0x3e4 0x5e0 0x4 0x0
+#define MX6SL_PAD_EPDC_PWRINT__GPIO2_IO12          0x0f4 0x3e4 0x000 0x5 0x0
+#define MX6SL_PAD_EPDC_PWRINT__SD3_VSELECT         0x0f4 0x3e4 0x000 0x6 0x0
+#define MX6SL_PAD_EPDC_PWRSTAT__EPDC_PWR_STAT      0x0f8 0x3e8 0x6ec 0x0 0x1
+#define MX6SL_PAD_EPDC_PWRSTAT__SD4_DATA2          0x0f8 0x3e8 0x864 0x1 0x0
+#define MX6SL_PAD_EPDC_PWRSTAT__LCD_DATA22         0x0f8 0x3e8 0x7d0 0x2 0x0
+#define MX6SL_PAD_EPDC_PWRSTAT__EIM_WAIT_B         0x0f8 0x3e8 0x884 0x3 0x0
+#define MX6SL_PAD_EPDC_PWRSTAT__ARM_EVENTI         0x0f8 0x3e8 0x000 0x4 0x0
+#define MX6SL_PAD_EPDC_PWRSTAT__GPIO2_IO13         0x0f8 0x3e8 0x000 0x5 0x0
+#define MX6SL_PAD_EPDC_PWRSTAT__SD3_WP             0x0f8 0x3e8 0x84c 0x6 0x0
+#define MX6SL_PAD_EPDC_PWRWAKEUP__EPDC_PWR_WAKE    0x0fc 0x3ec 0x000 0x0 0x0
+#define MX6SL_PAD_EPDC_PWRWAKEUP__SD4_DATA3        0x0fc 0x3ec 0x868 0x1 0x0
+#define MX6SL_PAD_EPDC_PWRWAKEUP__LCD_DATA23       0x0fc 0x3ec 0x7d4 0x2 0x0
+#define MX6SL_PAD_EPDC_PWRWAKEUP__EIM_DTACK_B      0x0fc 0x3ec 0x880 0x3 0x0
+#define MX6SL_PAD_EPDC_PWRWAKEUP__ARM_EVENTO       0x0fc 0x3ec 0x000 0x4 0x0
+#define MX6SL_PAD_EPDC_PWRWAKEUP__GPIO2_IO14       0x0fc 0x3ec 0x000 0x5 0x0
+#define MX6SL_PAD_EPDC_PWRWAKEUP__SD3_CD_B         0x0fc 0x3ec 0x838 0x6 0x0
+#define MX6SL_PAD_EPDC_SDCE0__EPDC_SDCE0           0x100 0x3f0 0x000 0x0 0x0
+#define MX6SL_PAD_EPDC_SDCE0__ECSPI2_SS1           0x100 0x3f0 0x6ac 0x1 0x0
+#define MX6SL_PAD_EPDC_SDCE0__PWM3_OUT             0x100 0x3f0 0x000 0x2 0x0
+#define MX6SL_PAD_EPDC_SDCE0__EIM_CS2_B            0x100 0x3f0 0x000 0x3 0x0
+#define MX6SL_PAD_EPDC_SDCE0__SPDC_YCKR            0x100 0x3f0 0x000 0x4 0x0
+#define MX6SL_PAD_EPDC_SDCE0__GPIO1_IO27           0x100 0x3f0 0x000 0x5 0x0
+#define MX6SL_PAD_EPDC_SDCE1__EPDC_SDCE1           0x104 0x3f4 0x000 0x0 0x0
+#define MX6SL_PAD_EPDC_SDCE1__WDOG2_B              0x104 0x3f4 0x000 0x1 0x0
+#define MX6SL_PAD_EPDC_SDCE1__PWM4_OUT             0x104 0x3f4 0x000 0x2 0x0
+#define MX6SL_PAD_EPDC_SDCE1__EIM_LBA_B            0x104 0x3f4 0x000 0x3 0x0
+#define MX6SL_PAD_EPDC_SDCE1__SPDC_YOER            0x104 0x3f4 0x000 0x4 0x0
+#define MX6SL_PAD_EPDC_SDCE1__GPIO1_IO28           0x104 0x3f4 0x000 0x5 0x0
+#define MX6SL_PAD_EPDC_SDCE2__EPDC_SDCE2           0x108 0x3f8 0x000 0x0 0x0
+#define MX6SL_PAD_EPDC_SDCE2__I2C3_SCL             0x108 0x3f8 0x72c 0x1 0x1
+#define MX6SL_PAD_EPDC_SDCE2__PWM1_OUT             0x108 0x3f8 0x000 0x2 0x0
+#define MX6SL_PAD_EPDC_SDCE2__EIM_EB0_B            0x108 0x3f8 0x000 0x3 0x0
+#define MX6SL_PAD_EPDC_SDCE2__SPDC_YDIOUR          0x108 0x3f8 0x000 0x4 0x0
+#define MX6SL_PAD_EPDC_SDCE2__GPIO1_IO29           0x108 0x3f8 0x000 0x5 0x0
+#define MX6SL_PAD_EPDC_SDCE3__EPDC_SDCE3           0x10c 0x3fc 0x000 0x0 0x0
+#define MX6SL_PAD_EPDC_SDCE3__I2C3_SDA             0x10c 0x3fc 0x730 0x1 0x1
+#define MX6SL_PAD_EPDC_SDCE3__PWM2_OUT             0x10c 0x3fc 0x000 0x2 0x0
+#define MX6SL_PAD_EPDC_SDCE3__EIM_EB1_B            0x10c 0x3fc 0x000 0x3 0x0
+#define MX6SL_PAD_EPDC_SDCE3__SPDC_YDIODR          0x10c 0x3fc 0x000 0x4 0x0
+#define MX6SL_PAD_EPDC_SDCE3__GPIO1_IO30           0x10c 0x3fc 0x000 0x5 0x0
+#define MX6SL_PAD_EPDC_SDCLK__EPDC_SDCLK_P         0x110 0x400 0x000 0x0 0x0
+#define MX6SL_PAD_EPDC_SDCLK__ECSPI2_MOSI          0x110 0x400 0x6a4 0x1 0x1
+#define MX6SL_PAD_EPDC_SDCLK__I2C2_SCL             0x110 0x400 0x724 0x2 0x0
+#define MX6SL_PAD_EPDC_SDCLK__CSI_DATA08           0x110 0x400 0x650 0x3 0x0
+#define MX6SL_PAD_EPDC_SDCLK__SPDC_CL              0x110 0x400 0x000 0x4 0x0
+#define MX6SL_PAD_EPDC_SDCLK__GPIO1_IO23           0x110 0x400 0x000 0x5 0x0
+#define MX6SL_PAD_EPDC_SDLE__EPDC_SDLE             0x114 0x404 0x000 0x0 0x0
+#define MX6SL_PAD_EPDC_SDLE__ECSPI2_MISO           0x114 0x404 0x6a0 0x1 0x1
+#define MX6SL_PAD_EPDC_SDLE__I2C2_SDA              0x114 0x404 0x728 0x2 0x0
+#define MX6SL_PAD_EPDC_SDLE__CSI_DATA09            0x114 0x404 0x654 0x3 0x0
+#define MX6SL_PAD_EPDC_SDLE__SPDC_LD               0x114 0x404 0x000 0x4 0x0
+#define MX6SL_PAD_EPDC_SDLE__GPIO1_IO24            0x114 0x404 0x000 0x5 0x0
+#define MX6SL_PAD_EPDC_SDOE__EPDC_SDOE             0x118 0x408 0x000 0x0 0x0
+#define MX6SL_PAD_EPDC_SDOE__ECSPI2_SS0            0x118 0x408 0x6a8 0x1 0x1
+#define MX6SL_PAD_EPDC_SDOE__SPDC_XDIOR            0x118 0x408 0x000 0x2 0x0
+#define MX6SL_PAD_EPDC_SDOE__CSI_DATA10            0x118 0x408 0x658 0x3 0x0
+#define MX6SL_PAD_EPDC_SDOE__SPDC_XDIOL            0x118 0x408 0x000 0x4 0x0
+#define MX6SL_PAD_EPDC_SDOE__GPIO1_IO25            0x118 0x408 0x000 0x5 0x0
+#define MX6SL_PAD_EPDC_SDSHR__EPDC_SDSHR           0x11c 0x40c 0x000 0x0 0x0
+#define MX6SL_PAD_EPDC_SDSHR__ECSPI2_SCLK          0x11c 0x40c 0x69c 0x1 0x1
+#define MX6SL_PAD_EPDC_SDSHR__EPDC_SDCE4           0x11c 0x40c 0x000 0x2 0x0
+#define MX6SL_PAD_EPDC_SDSHR__CSI_DATA11           0x11c 0x40c 0x65c 0x3 0x0
+#define MX6SL_PAD_EPDC_SDSHR__SPDC_XDIOR           0x11c 0x40c 0x000 0x4 0x0
+#define MX6SL_PAD_EPDC_SDSHR__GPIO1_IO26           0x11c 0x40c 0x000 0x5 0x0
+#define MX6SL_PAD_EPDC_VCOM0__EPDC_VCOM0           0x120 0x410 0x000 0x0 0x0
+#define MX6SL_PAD_EPDC_VCOM0__AUD5_RXFS            0x120 0x410 0x608 0x1 0x0
+#define MX6SL_PAD_EPDC_VCOM0__UART3_RX_DATA        0x120 0x410 0x80c 0x2 0x4
+#define MX6SL_PAD_EPDC_VCOM0__UART3_TX_DATA        0x120 0x410 0x000 0x2 0x0
+#define MX6SL_PAD_EPDC_VCOM0__EIM_ADDR24           0x120 0x410 0x000 0x3 0x0
+#define MX6SL_PAD_EPDC_VCOM0__SPDC_VCOM0           0x120 0x410 0x000 0x4 0x0
+#define MX6SL_PAD_EPDC_VCOM0__GPIO2_IO03           0x120 0x410 0x000 0x5 0x0
+#define MX6SL_PAD_EPDC_VCOM0__EPDC_SDCE5           0x120 0x410 0x000 0x6 0x0
+#define MX6SL_PAD_EPDC_VCOM1__EPDC_VCOM1           0x124 0x414 0x000 0x0 0x0
+#define MX6SL_PAD_EPDC_VCOM1__AUD5_RXD             0x124 0x414 0x5fc 0x1 0x0
+#define MX6SL_PAD_EPDC_VCOM1__UART3_TX_DATA        0x124 0x414 0x000 0x2 0x0
+#define MX6SL_PAD_EPDC_VCOM1__UART3_RX_DATA        0x124 0x414 0x80c 0x2 0x5
+#define MX6SL_PAD_EPDC_VCOM1__EIM_ADDR25           0x124 0x414 0x000 0x3 0x0
+#define MX6SL_PAD_EPDC_VCOM1__SPDC_VCOM1           0x124 0x414 0x000 0x4 0x0
+#define MX6SL_PAD_EPDC_VCOM1__GPIO2_IO04           0x124 0x414 0x000 0x5 0x0
+#define MX6SL_PAD_EPDC_VCOM1__EPDC_SDCE6           0x124 0x414 0x000 0x6 0x0
+#define MX6SL_PAD_FEC_CRS_DV__FEC_RX_DV            0x128 0x418 0x704 0x0 0x1
+#define MX6SL_PAD_FEC_CRS_DV__SD4_DATA1            0x128 0x418 0x860 0x1 0x1
+#define MX6SL_PAD_FEC_CRS_DV__AUD6_TXC             0x128 0x418 0x624 0x2 0x0
+#define MX6SL_PAD_FEC_CRS_DV__ECSPI4_MISO          0x128 0x418 0x6d4 0x3 0x1
+#define MX6SL_PAD_FEC_CRS_DV__GPT_COMPARE2         0x128 0x418 0x000 0x4 0x0
+#define MX6SL_PAD_FEC_CRS_DV__GPIO4_IO25           0x128 0x418 0x000 0x5 0x0
+#define MX6SL_PAD_FEC_CRS_DV__ARM_TRACE31          0x128 0x418 0x000 0x6 0x0
+#define MX6SL_PAD_FEC_MDC__FEC_MDC                 0x12c 0x41c 0x000 0x0 0x0
+#define MX6SL_PAD_FEC_MDC__SD4_DATA4               0x12c 0x41c 0x86c 0x1 0x0
+#define MX6SL_PAD_FEC_MDC__AUDIO_CLK_OUT           0x12c 0x41c 0x000 0x2 0x0
+#define MX6SL_PAD_FEC_MDC__SD1_RESET               0x12c 0x41c 0x000 0x3 0x0
+#define MX6SL_PAD_FEC_MDC__SD3_RESET               0x12c 0x41c 0x000 0x4 0x0
+#define MX6SL_PAD_FEC_MDC__GPIO4_IO23              0x12c 0x41c 0x000 0x5 0x0
+#define MX6SL_PAD_FEC_MDC__ARM_TRACE29             0x12c 0x41c 0x000 0x6 0x0
+#define MX6SL_PAD_FEC_MDIO__FEC_MDIO               0x130 0x420 0x6f4 0x0 0x1
+#define MX6SL_PAD_FEC_MDIO__SD4_CLK                0x130 0x420 0x850 0x1 0x1
+#define MX6SL_PAD_FEC_MDIO__AUD6_RXFS              0x130 0x420 0x620 0x2 0x0
+#define MX6SL_PAD_FEC_MDIO__ECSPI4_SS0             0x130 0x420 0x6dc 0x3 0x1
+#define MX6SL_PAD_FEC_MDIO__GPT_CAPTURE1           0x130 0x420 0x710 0x4 0x0
+#define MX6SL_PAD_FEC_MDIO__GPIO4_IO20             0x130 0x420 0x000 0x5 0x0
+#define MX6SL_PAD_FEC_MDIO__ARM_TRACE26            0x130 0x420 0x000 0x6 0x0
+#define MX6SL_PAD_FEC_REF_CLK__FEC_REF_OUT         0x134 0x424 0x000 0x0 0x0
+#define MX6SL_PAD_FEC_REF_CLK__SD4_RESET           0x134 0x424 0x000 0x1 0x0
+#define MX6SL_PAD_FEC_REF_CLK__WDOG1_B             0x134 0x424 0x000 0x2 0x0
+#define MX6SL_PAD_FEC_REF_CLK__PWM4_OUT            0x134 0x424 0x000 0x3 0x0
+#define MX6SL_PAD_FEC_REF_CLK__CCM_PMIC_READY      0x134 0x424 0x62c 0x4 0x0
+#define MX6SL_PAD_FEC_REF_CLK__GPIO4_IO26          0x134 0x424 0x000 0x5 0x0
+#define MX6SL_PAD_FEC_REF_CLK__SPDIF_EXT_CLK       0x134 0x424 0x7f4 0x6 0x2
+#define MX6SL_PAD_FEC_RX_ER__FEC_RX_ER             0x138 0x428 0x708 0x0 0x1
+#define MX6SL_PAD_FEC_RX_ER__SD4_DATA0             0x138 0x428 0x85c 0x1 0x1
+#define MX6SL_PAD_FEC_RX_ER__AUD6_RXD              0x138 0x428 0x614 0x2 0x0
+#define MX6SL_PAD_FEC_RX_ER__ECSPI4_MOSI           0x138 0x428 0x6d8 0x3 0x1
+#define MX6SL_PAD_FEC_RX_ER__GPT_COMPARE1          0x138 0x428 0x000 0x4 0x0
+#define MX6SL_PAD_FEC_RX_ER__GPIO4_IO19            0x138 0x428 0x000 0x5 0x0
+#define MX6SL_PAD_FEC_RX_ER__ARM_TRACE25           0x138 0x428 0x000 0x6 0x0
+#define MX6SL_PAD_FEC_RXD0__FEC_RX_DATA0           0x13c 0x42c 0x6f8 0x0 0x0
+#define MX6SL_PAD_FEC_RXD0__SD4_DATA5              0x13c 0x42c 0x870 0x1 0x0
+#define MX6SL_PAD_FEC_RXD0__USB_OTG1_ID            0x13c 0x42c 0x5dc 0x2 0x1
+#define MX6SL_PAD_FEC_RXD0__SD1_VSELECT            0x13c 0x42c 0x000 0x3 0x0
+#define MX6SL_PAD_FEC_RXD0__SD3_VSELECT            0x13c 0x42c 0x000 0x4 0x0
+#define MX6SL_PAD_FEC_RXD0__GPIO4_IO17             0x13c 0x42c 0x000 0x5 0x0
+#define MX6SL_PAD_FEC_RXD0__ARM_TRACE24            0x13c 0x42c 0x000 0x6 0x0
+#define MX6SL_PAD_FEC_RXD1__FEC_RX_DATA1           0x140 0x430 0x6fc 0x0 0x1
+#define MX6SL_PAD_FEC_RXD1__SD4_DATA2              0x140 0x430 0x864 0x1 0x1
+#define MX6SL_PAD_FEC_RXD1__AUD6_TXFS              0x140 0x430 0x628 0x2 0x0
+#define MX6SL_PAD_FEC_RXD1__ECSPI4_SS1             0x140 0x430 0x6e0 0x3 0x1
+#define MX6SL_PAD_FEC_RXD1__GPT_COMPARE3           0x140 0x430 0x000 0x4 0x0
+#define MX6SL_PAD_FEC_RXD1__GPIO4_IO18             0x140 0x430 0x000 0x5 0x0
+#define MX6SL_PAD_FEC_RXD1__FEC_COL                0x140 0x430 0x6f0 0x6 0x0
+#define MX6SL_PAD_FEC_TX_CLK__FEC_TX_CLK           0x144 0x434 0x70c 0x0 0x1
+#define MX6SL_PAD_FEC_TX_CLK__SD4_CMD              0x144 0x434 0x858 0x1 0x1
+#define MX6SL_PAD_FEC_TX_CLK__AUD6_RXC             0x144 0x434 0x61c 0x2 0x0
+#define MX6SL_PAD_FEC_TX_CLK__ECSPI4_SCLK          0x144 0x434 0x6d0 0x3 0x1
+#define MX6SL_PAD_FEC_TX_CLK__GPT_CAPTURE2         0x144 0x434 0x714 0x4 0x0
+#define MX6SL_PAD_FEC_TX_CLK__GPIO4_IO21           0x144 0x434 0x000 0x5 0x0
+#define MX6SL_PAD_FEC_TX_CLK__ARM_TRACE27          0x144 0x434 0x000 0x6 0x0
+#define MX6SL_PAD_FEC_TX_EN__FEC_TX_EN             0x148 0x438 0x000 0x0 0x0
+#define MX6SL_PAD_FEC_TX_EN__SD4_DATA6             0x148 0x438 0x874 0x1 0x0
+#define MX6SL_PAD_FEC_TX_EN__SPDIF_IN              0x148 0x438 0x7f0 0x2 0x0
+#define MX6SL_PAD_FEC_TX_EN__SD1_WP                0x148 0x438 0x82c 0x3 0x1
+#define MX6SL_PAD_FEC_TX_EN__SD3_WP                0x148 0x438 0x84c 0x4 0x1
+#define MX6SL_PAD_FEC_TX_EN__GPIO4_IO22            0x148 0x438 0x000 0x5 0x0
+#define MX6SL_PAD_FEC_TX_EN__ARM_TRACE28           0x148 0x438 0x000 0x6 0x0
+#define MX6SL_PAD_FEC_TXD0__FEC_TX_DATA0           0x14c 0x43c 0x000 0x0 0x0
+#define MX6SL_PAD_FEC_TXD0__SD4_DATA3              0x14c 0x43c 0x868 0x1 0x1
+#define MX6SL_PAD_FEC_TXD0__AUD6_TXD               0x14c 0x43c 0x618 0x2 0x0
+#define MX6SL_PAD_FEC_TXD0__ECSPI4_SS2             0x14c 0x43c 0x6e4 0x3 0x1
+#define MX6SL_PAD_FEC_TXD0__GPT_CLKIN              0x14c 0x43c 0x718 0x4 0x0
+#define MX6SL_PAD_FEC_TXD0__GPIO4_IO24             0x14c 0x43c 0x000 0x5 0x0
+#define MX6SL_PAD_FEC_TXD0__ARM_TRACE30            0x14c 0x43c 0x000 0x6 0x0
+#define MX6SL_PAD_FEC_TXD1__FEC_TX_DATA1           0x150 0x440 0x000 0x0 0x0
+#define MX6SL_PAD_FEC_TXD1__SD4_DATA7              0x150 0x440 0x878 0x1 0x0
+#define MX6SL_PAD_FEC_TXD1__SPDIF_OUT              0x150 0x440 0x000 0x2 0x0
+#define MX6SL_PAD_FEC_TXD1__SD1_CD_B               0x150 0x440 0x828 0x3 0x1
+#define MX6SL_PAD_FEC_TXD1__SD3_CD_B               0x150 0x440 0x838 0x4 0x1
+#define MX6SL_PAD_FEC_TXD1__GPIO4_IO16             0x150 0x440 0x000 0x5 0x0
+#define MX6SL_PAD_FEC_TXD1__FEC_RX_CLK             0x150 0x440 0x700 0x6 0x0
+#define MX6SL_PAD_HSIC_DAT__USB_H_DATA             0x154 0x444 0x000 0x0 0x0
+#define MX6SL_PAD_HSIC_DAT__I2C1_SCL               0x154 0x444 0x71c 0x1 0x1
+#define MX6SL_PAD_HSIC_DAT__PWM1_OUT               0x154 0x444 0x000 0x2 0x0
+#define MX6SL_PAD_HSIC_DAT__XTALOSC_REF_CLK_24M    0x154 0x444 0x000 0x3 0x0
+#define MX6SL_PAD_HSIC_DAT__GPIO3_IO19             0x154 0x444 0x000 0x5 0x0
+#define MX6SL_PAD_HSIC_STROBE__USB_H_STROBE        0x158 0x448 0x000 0x0 0x0
+#define MX6SL_PAD_HSIC_STROBE__I2C1_SDA            0x158 0x448 0x720 0x1 0x1
+#define MX6SL_PAD_HSIC_STROBE__PWM2_OUT            0x158 0x448 0x000 0x2 0x0
+#define MX6SL_PAD_HSIC_STROBE__XTALOSC_REF_CLK_32K 0x158 0x448 0x000 0x3 0x0
+#define MX6SL_PAD_HSIC_STROBE__GPIO3_IO20          0x158 0x448 0x000 0x5 0x0
+#define MX6SL_PAD_I2C1_SCL__I2C1_SCL               0x15c 0x44c 0x71c 0x0 0x2
+#define MX6SL_PAD_I2C1_SCL__UART1_RTS_B            0x15c 0x44c 0x7f8 0x1 0x0
+#define MX6SL_PAD_I2C1_SCL__UART1_CTS_B            0x15c 0x44c 0x000 0x1 0x0
+#define MX6SL_PAD_I2C1_SCL__ECSPI3_SS2             0x15c 0x44c 0x6c8 0x2 0x1
+#define MX6SL_PAD_I2C1_SCL__FEC_RX_DATA0           0x15c 0x44c 0x6f8 0x3 0x1
+#define MX6SL_PAD_I2C1_SCL__SD3_RESET              0x15c 0x44c 0x000 0x4 0x0
+#define MX6SL_PAD_I2C1_SCL__GPIO3_IO12             0x15c 0x44c 0x000 0x5 0x0
+#define MX6SL_PAD_I2C1_SCL__ECSPI1_SS1             0x15c 0x44c 0x690 0x6 0x0
+#define MX6SL_PAD_I2C1_SDA__I2C1_SDA               0x160 0x450 0x720 0x0 0x2
+#define MX6SL_PAD_I2C1_SDA__UART1_CTS_B            0x160 0x450 0x000 0x1 0x0
+#define MX6SL_PAD_I2C1_SDA__UART1_RTS_B            0x160 0x450 0x7f8 0x1 0x1
+#define MX6SL_PAD_I2C1_SDA__ECSPI3_SS3             0x160 0x450 0x6cc 0x2 0x1
+#define MX6SL_PAD_I2C1_SDA__FEC_TX_EN              0x160 0x450 0x000 0x3 0x0
+#define MX6SL_PAD_I2C1_SDA__SD3_VSELECT            0x160 0x450 0x000 0x4 0x0
+#define MX6SL_PAD_I2C1_SDA__GPIO3_IO13             0x160 0x450 0x000 0x5 0x0
+#define MX6SL_PAD_I2C1_SDA__ECSPI1_SS2             0x160 0x450 0x694 0x6 0x0
+#define MX6SL_PAD_I2C2_SCL__I2C2_SCL               0x164 0x454 0x724 0x0 0x1
+#define MX6SL_PAD_I2C2_SCL__AUD4_RXFS              0x164 0x454 0x5f0 0x1 0x0
+#define MX6SL_PAD_I2C2_SCL__SPDIF_IN               0x164 0x454 0x7f0 0x2 0x1
+#define MX6SL_PAD_I2C2_SCL__FEC_TX_DATA1           0x164 0x454 0x000 0x3 0x0
+#define MX6SL_PAD_I2C2_SCL__SD3_WP                 0x164 0x454 0x84c 0x4 0x2
+#define MX6SL_PAD_I2C2_SCL__GPIO3_IO14             0x164 0x454 0x000 0x5 0x0
+#define MX6SL_PAD_I2C2_SCL__ECSPI1_RDY             0x164 0x454 0x680 0x6 0x0
+#define MX6SL_PAD_I2C2_SDA__I2C2_SDA               0x168 0x458 0x728 0x0 0x1
+#define MX6SL_PAD_I2C2_SDA__AUD4_RXC               0x168 0x458 0x5ec 0x1 0x0
+#define MX6SL_PAD_I2C2_SDA__SPDIF_OUT              0x168 0x458 0x000 0x2 0x0
+#define MX6SL_PAD_I2C2_SDA__FEC_REF_OUT            0x168 0x458 0x000 0x3 0x0
+#define MX6SL_PAD_I2C2_SDA__SD3_CD_B               0x168 0x458 0x838 0x4 0x2
+#define MX6SL_PAD_I2C2_SDA__GPIO3_IO15             0x168 0x458 0x000 0x5 0x0
+#define MX6SL_PAD_KEY_COL0__KEY_COL0               0x16c 0x474 0x734 0x0 0x0
+#define MX6SL_PAD_KEY_COL0__I2C2_SCL               0x16c 0x474 0x724 0x1 0x2
+#define MX6SL_PAD_KEY_COL0__LCD_DATA00             0x16c 0x474 0x778 0x2 0x0
+#define MX6SL_PAD_KEY_COL0__EIM_AD00               0x16c 0x474 0x000 0x3 0x0
+#define MX6SL_PAD_KEY_COL0__SD1_CD_B               0x16c 0x474 0x828 0x4 0x2
+#define MX6SL_PAD_KEY_COL0__GPIO3_IO24             0x16c 0x474 0x000 0x5 0x0
+#define MX6SL_PAD_KEY_COL1__KEY_COL1               0x170 0x478 0x738 0x0 0x0
+#define MX6SL_PAD_KEY_COL1__ECSPI4_MOSI            0x170 0x478 0x6d8 0x1 0x2
+#define MX6SL_PAD_KEY_COL1__LCD_DATA02             0x170 0x478 0x780 0x2 0x0
+#define MX6SL_PAD_KEY_COL1__EIM_AD02               0x170 0x478 0x000 0x3 0x0
+#define MX6SL_PAD_KEY_COL1__SD3_DATA4              0x170 0x478 0x83c 0x4 0x0
+#define MX6SL_PAD_KEY_COL1__GPIO3_IO26             0x170 0x478 0x000 0x5 0x0
+#define MX6SL_PAD_KEY_COL2__KEY_COL2               0x174 0x47c 0x73c 0x0 0x0
+#define MX6SL_PAD_KEY_COL2__ECSPI4_SS0             0x174 0x47c 0x6dc 0x1 0x2
+#define MX6SL_PAD_KEY_COL2__LCD_DATA04             0x174 0x47c 0x788 0x2 0x0
+#define MX6SL_PAD_KEY_COL2__EIM_AD04               0x174 0x47c 0x000 0x3 0x0
+#define MX6SL_PAD_KEY_COL2__SD3_DATA6              0x174 0x47c 0x844 0x4 0x0
+#define MX6SL_PAD_KEY_COL2__GPIO3_IO28             0x174 0x47c 0x000 0x5 0x0
+#define MX6SL_PAD_KEY_COL3__KEY_COL3               0x178 0x480 0x740 0x0 0x0
+#define MX6SL_PAD_KEY_COL3__AUD6_RXFS              0x178 0x480 0x620 0x1 0x1
+#define MX6SL_PAD_KEY_COL3__LCD_DATA06             0x178 0x480 0x790 0x2 0x0
+#define MX6SL_PAD_KEY_COL3__EIM_AD06               0x178 0x480 0x000 0x3 0x0
+#define MX6SL_PAD_KEY_COL3__SD4_DATA6              0x178 0x480 0x874 0x4 0x1
+#define MX6SL_PAD_KEY_COL3__GPIO3_IO30             0x178 0x480 0x000 0x5 0x0
+#define MX6SL_PAD_KEY_COL3__SD1_RESET              0x178 0x480 0x000 0x6 0x0
+#define MX6SL_PAD_KEY_COL4__KEY_COL4               0x17c 0x484 0x744 0x0 0x0
+#define MX6SL_PAD_KEY_COL4__AUD6_RXD               0x17c 0x484 0x614 0x1 0x1
+#define MX6SL_PAD_KEY_COL4__LCD_DATA08             0x17c 0x484 0x798 0x2 0x0
+#define MX6SL_PAD_KEY_COL4__EIM_AD08               0x17c 0x484 0x000 0x3 0x0
+#define MX6SL_PAD_KEY_COL4__SD4_CLK                0x17c 0x484 0x850 0x4 0x2
+#define MX6SL_PAD_KEY_COL4__GPIO4_IO00             0x17c 0x484 0x000 0x5 0x0
+#define MX6SL_PAD_KEY_COL4__USB_OTG1_PWR           0x17c 0x484 0x000 0x6 0x0
+#define MX6SL_PAD_KEY_COL5__KEY_COL5               0x180 0x488 0x748 0x0 0x0
+#define MX6SL_PAD_KEY_COL5__AUD6_TXFS              0x180 0x488 0x628 0x1 0x1
+#define MX6SL_PAD_KEY_COL5__LCD_DATA10             0x180 0x488 0x7a0 0x2 0x0
+#define MX6SL_PAD_KEY_COL5__EIM_AD10               0x180 0x488 0x000 0x3 0x0
+#define MX6SL_PAD_KEY_COL5__SD4_DATA0              0x180 0x488 0x85c 0x4 0x2
+#define MX6SL_PAD_KEY_COL5__GPIO4_IO02             0x180 0x488 0x000 0x5 0x0
+#define MX6SL_PAD_KEY_COL5__USB_OTG2_PWR           0x180 0x488 0x000 0x6 0x0
+#define MX6SL_PAD_KEY_COL6__KEY_COL6               0x184 0x48c 0x74c 0x0 0x0
+#define MX6SL_PAD_KEY_COL6__UART4_RX_DATA          0x184 0x48c 0x814 0x1 0x2
+#define MX6SL_PAD_KEY_COL6__UART4_TX_DATA          0x184 0x48c 0x000 0x1 0x0
+#define MX6SL_PAD_KEY_COL6__LCD_DATA12             0x184 0x48c 0x7a8 0x2 0x0
+#define MX6SL_PAD_KEY_COL6__EIM_AD12               0x184 0x48c 0x000 0x3 0x0
+#define MX6SL_PAD_KEY_COL6__SD4_DATA2              0x184 0x48c 0x864 0x4 0x2
+#define MX6SL_PAD_KEY_COL6__GPIO4_IO04             0x184 0x48c 0x000 0x5 0x0
+#define MX6SL_PAD_KEY_COL6__SD3_RESET              0x184 0x48c 0x000 0x6 0x0
+#define MX6SL_PAD_KEY_COL7__KEY_COL7               0x188 0x490 0x750 0x0 0x0
+#define MX6SL_PAD_KEY_COL7__UART4_RTS_B            0x188 0x490 0x810 0x1 0x2
+#define MX6SL_PAD_KEY_COL7__UART4_CTS_B            0x188 0x490 0x000 0x1 0x0
+#define MX6SL_PAD_KEY_COL7__LCD_DATA14             0x188 0x490 0x7b0 0x2 0x0
+#define MX6SL_PAD_KEY_COL7__EIM_AD14               0x188 0x490 0x000 0x3 0x0
+#define MX6SL_PAD_KEY_COL7__SD4_DATA4              0x188 0x490 0x86c 0x4 0x1
+#define MX6SL_PAD_KEY_COL7__GPIO4_IO06             0x188 0x490 0x000 0x5 0x0
+#define MX6SL_PAD_KEY_COL7__SD1_WP                 0x188 0x490 0x82c 0x6 0x2
+#define MX6SL_PAD_KEY_ROW0__KEY_ROW0               0x18c 0x494 0x754 0x0 0x0
+#define MX6SL_PAD_KEY_ROW0__I2C2_SDA               0x18c 0x494 0x728 0x1 0x2
+#define MX6SL_PAD_KEY_ROW0__LCD_DATA01             0x18c 0x494 0x77c 0x2 0x0
+#define MX6SL_PAD_KEY_ROW0__EIM_AD01               0x18c 0x494 0x000 0x3 0x0
+#define MX6SL_PAD_KEY_ROW0__SD1_WP                 0x18c 0x494 0x82c 0x4 0x3
+#define MX6SL_PAD_KEY_ROW0__GPIO3_IO25             0x18c 0x494 0x000 0x5 0x0
+#define MX6SL_PAD_KEY_ROW1__KEY_ROW1               0x190 0x498 0x758 0x0 0x0
+#define MX6SL_PAD_KEY_ROW1__ECSPI4_MISO            0x190 0x498 0x6d4 0x1 0x2
+#define MX6SL_PAD_KEY_ROW1__LCD_DATA03             0x190 0x498 0x784 0x2 0x0
+#define MX6SL_PAD_KEY_ROW1__EIM_AD03               0x190 0x498 0x000 0x3 0x0
+#define MX6SL_PAD_KEY_ROW1__SD3_DATA5              0x190 0x498 0x840 0x4 0x0
+#define MX6SL_PAD_KEY_ROW1__GPIO3_IO27             0x190 0x498 0x000 0x5 0x0
+#define MX6SL_PAD_KEY_ROW2__KEY_ROW2               0x194 0x49c 0x75c 0x0 0x0
+#define MX6SL_PAD_KEY_ROW2__ECSPI4_SCLK            0x194 0x49c 0x6d0 0x1 0x2
+#define MX6SL_PAD_KEY_ROW2__LCD_DATA05             0x194 0x49c 0x78c 0x2 0x0
+#define MX6SL_PAD_KEY_ROW2__EIM_AD05               0x194 0x49c 0x000 0x3 0x0
+#define MX6SL_PAD_KEY_ROW2__SD3_DATA7              0x194 0x49c 0x848 0x4 0x0
+#define MX6SL_PAD_KEY_ROW2__GPIO3_IO29             0x194 0x49c 0x000 0x5 0x0
+#define MX6SL_PAD_KEY_ROW3__KEY_ROW3               0x198 0x4a0 0x760 0x0 0x0
+#define MX6SL_PAD_KEY_ROW3__AUD6_RXC               0x198 0x4a0 0x61c 0x1 0x1
+#define MX6SL_PAD_KEY_ROW3__LCD_DATA07             0x198 0x4a0 0x794 0x2 0x0
+#define MX6SL_PAD_KEY_ROW3__EIM_AD07               0x198 0x4a0 0x000 0x3 0x0
+#define MX6SL_PAD_KEY_ROW3__SD4_DATA7              0x198 0x4a0 0x878 0x4 0x1
+#define MX6SL_PAD_KEY_ROW3__GPIO3_IO31             0x198 0x4a0 0x000 0x5 0x0
+#define MX6SL_PAD_KEY_ROW3__SD1_VSELECT            0x198 0x4a0 0x000 0x6 0x0
+#define MX6SL_PAD_KEY_ROW4__KEY_ROW4               0x19c 0x4a4 0x764 0x0 0x0
+#define MX6SL_PAD_KEY_ROW4__AUD6_TXC               0x19c 0x4a4 0x624 0x1 0x1
+#define MX6SL_PAD_KEY_ROW4__LCD_DATA09             0x19c 0x4a4 0x79c 0x2 0x0
+#define MX6SL_PAD_KEY_ROW4__EIM_AD09               0x19c 0x4a4 0x000 0x3 0x0
+#define MX6SL_PAD_KEY_ROW4__SD4_CMD                0x19c 0x4a4 0x858 0x4 0x2
+#define MX6SL_PAD_KEY_ROW4__GPIO4_IO01             0x19c 0x4a4 0x000 0x5 0x0
+#define MX6SL_PAD_KEY_ROW4__USB_OTG1_OC            0x19c 0x4a4 0x824 0x6 0x1
+#define MX6SL_PAD_KEY_ROW5__KEY_ROW5               0x1a0 0x4a8 0x768 0x0 0x0
+#define MX6SL_PAD_KEY_ROW5__AUD6_TXD               0x1a0 0x4a8 0x618 0x1 0x1
+#define MX6SL_PAD_KEY_ROW5__LCD_DATA11             0x1a0 0x4a8 0x7a4 0x2 0x0
+#define MX6SL_PAD_KEY_ROW5__EIM_AD11               0x1a0 0x4a8 0x000 0x3 0x0
+#define MX6SL_PAD_KEY_ROW5__SD4_DATA1              0x1a0 0x4a8 0x860 0x4 0x2
+#define MX6SL_PAD_KEY_ROW5__GPIO4_IO03             0x1a0 0x4a8 0x000 0x5 0x0
+#define MX6SL_PAD_KEY_ROW5__USB_OTG2_OC            0x1a0 0x4a8 0x820 0x6 0x2
+#define MX6SL_PAD_KEY_ROW6__KEY_ROW6               0x1a4 0x4ac 0x76c 0x0 0x0
+#define MX6SL_PAD_KEY_ROW6__UART4_TX_DATA          0x1a4 0x4ac 0x000 0x1 0x0
+#define MX6SL_PAD_KEY_ROW6__UART4_RX_DATA          0x1a4 0x4ac 0x814 0x1 0x3
+#define MX6SL_PAD_KEY_ROW6__LCD_DATA13             0x1a4 0x4ac 0x7ac 0x2 0x0
+#define MX6SL_PAD_KEY_ROW6__EIM_AD13               0x1a4 0x4ac 0x000 0x3 0x0
+#define MX6SL_PAD_KEY_ROW6__SD4_DATA3              0x1a4 0x4ac 0x868 0x4 0x2
+#define MX6SL_PAD_KEY_ROW6__GPIO4_IO05             0x1a4 0x4ac 0x000 0x5 0x0
+#define MX6SL_PAD_KEY_ROW6__SD3_VSELECT            0x1a4 0x4ac 0x000 0x6 0x0
+#define MX6SL_PAD_KEY_ROW7__KEY_ROW7               0x1a8 0x4b0 0x770 0x0 0x0
+#define MX6SL_PAD_KEY_ROW7__UART4_CTS_B            0x1a8 0x4b0 0x000 0x1 0x0
+#define MX6SL_PAD_KEY_ROW7__UART4_RTS_B            0x1a8 0x4b0 0x810 0x1 0x3
+#define MX6SL_PAD_KEY_ROW7__LCD_DATA15             0x1a8 0x4b0 0x7b4 0x2 0x0
+#define MX6SL_PAD_KEY_ROW7__EIM_AD15               0x1a8 0x4b0 0x000 0x3 0x0
+#define MX6SL_PAD_KEY_ROW7__SD4_DATA5              0x1a8 0x4b0 0x870 0x4 0x1
+#define MX6SL_PAD_KEY_ROW7__GPIO4_IO07             0x1a8 0x4b0 0x000 0x5 0x0
+#define MX6SL_PAD_KEY_ROW7__SD1_CD_B               0x1a8 0x4b0 0x828 0x6 0x3
+#define MX6SL_PAD_LCD_CLK__LCD_CLK                 0x1ac 0x4b4 0x000 0x0 0x0
+#define MX6SL_PAD_LCD_CLK__SD4_DATA4               0x1ac 0x4b4 0x86c 0x1 0x2
+#define MX6SL_PAD_LCD_CLK__LCD_WR_RWN              0x1ac 0x4b4 0x000 0x2 0x0
+#define MX6SL_PAD_LCD_CLK__EIM_RW                  0x1ac 0x4b4 0x000 0x3 0x0
+#define MX6SL_PAD_LCD_CLK__PWM4_OUT                0x1ac 0x4b4 0x000 0x4 0x0
+#define MX6SL_PAD_LCD_CLK__GPIO2_IO15              0x1ac 0x4b4 0x000 0x5 0x0
+#define MX6SL_PAD_LCD_DAT0__LCD_DATA00             0x1b0 0x4b8 0x778 0x0 0x1
+#define MX6SL_PAD_LCD_DAT0__ECSPI1_MOSI            0x1b0 0x4b8 0x688 0x1 0x1
+#define MX6SL_PAD_LCD_DAT0__USB_OTG2_ID            0x1b0 0x4b8 0x5e0 0x2 0x1
+#define MX6SL_PAD_LCD_DAT0__PWM1_OUT               0x1b0 0x4b8 0x000 0x3 0x0
+#define MX6SL_PAD_LCD_DAT0__UART5_DTR_B            0x1b0 0x4b8 0x000 0x4 0x0
+#define MX6SL_PAD_LCD_DAT0__GPIO2_IO20             0x1b0 0x4b8 0x000 0x5 0x0
+#define MX6SL_PAD_LCD_DAT0__ARM_TRACE00            0x1b0 0x4b8 0x000 0x6 0x0
+#define MX6SL_PAD_LCD_DAT0__SRC_BOOT_CFG00         0x1b0 0x4b8 0x000 0x7 0x0
+#define MX6SL_PAD_LCD_DAT1__LCD_DATA01             0x1b4 0x4bc 0x77c 0x0 0x1
+#define MX6SL_PAD_LCD_DAT1__ECSPI1_MISO            0x1b4 0x4bc 0x684 0x1 0x1
+#define MX6SL_PAD_LCD_DAT1__USB_OTG1_ID            0x1b4 0x4bc 0x5dc 0x2 0x2
+#define MX6SL_PAD_LCD_DAT1__PWM2_OUT               0x1b4 0x4bc 0x000 0x3 0x0
+#define MX6SL_PAD_LCD_DAT1__AUD4_RXFS              0x1b4 0x4bc 0x5f0 0x4 0x1
+#define MX6SL_PAD_LCD_DAT1__GPIO2_IO21             0x1b4 0x4bc 0x000 0x5 0x0
+#define MX6SL_PAD_LCD_DAT1__ARM_TRACE01            0x1b4 0x4bc 0x000 0x6 0x0
+#define MX6SL_PAD_LCD_DAT1__SRC_BOOT_CFG01         0x1b4 0x4bc 0x000 0x7 0x0
+#define MX6SL_PAD_LCD_DAT10__LCD_DATA10            0x1b8 0x4c0 0x7a0 0x0 0x1
+#define MX6SL_PAD_LCD_DAT10__KEY_COL1              0x1b8 0x4c0 0x738 0x1 0x1
+#define MX6SL_PAD_LCD_DAT10__CSI_DATA07            0x1b8 0x4c0 0x64c 0x2 0x1
+#define MX6SL_PAD_LCD_DAT10__EIM_DATA04            0x1b8 0x4c0 0x000 0x3 0x0
+#define MX6SL_PAD_LCD_DAT10__ECSPI2_MISO           0x1b8 0x4c0 0x6a0 0x4 0x2
+#define MX6SL_PAD_LCD_DAT10__GPIO2_IO30            0x1b8 0x4c0 0x000 0x5 0x0
+#define MX6SL_PAD_LCD_DAT10__ARM_TRACE10           0x1b8 0x4c0 0x000 0x6 0x0
+#define MX6SL_PAD_LCD_DAT10__SRC_BOOT_CFG10        0x1b8 0x4c0 0x000 0x7 0x0
+#define MX6SL_PAD_LCD_DAT11__LCD_DATA11            0x1bc 0x4c4 0x7a4 0x0 0x1
+#define MX6SL_PAD_LCD_DAT11__KEY_ROW1              0x1bc 0x4c4 0x758 0x1 0x1
+#define MX6SL_PAD_LCD_DAT11__CSI_DATA06            0x1bc 0x4c4 0x648 0x2 0x1
+#define MX6SL_PAD_LCD_DAT11__EIM_DATA05            0x1bc 0x4c4 0x000 0x3 0x0
+#define MX6SL_PAD_LCD_DAT11__ECSPI2_SS1            0x1bc 0x4c4 0x6ac 0x4 0x1
+#define MX6SL_PAD_LCD_DAT11__GPIO2_IO31            0x1bc 0x4c4 0x000 0x5 0x0
+#define MX6SL_PAD_LCD_DAT11__ARM_TRACE11           0x1bc 0x4c4 0x000 0x6 0x0
+#define MX6SL_PAD_LCD_DAT11__SRC_BOOT_CFG11        0x1bc 0x4c4 0x000 0x7 0x0
+#define MX6SL_PAD_LCD_DAT12__LCD_DATA12            0x1c0 0x4c8 0x7a8 0x0 0x1
+#define MX6SL_PAD_LCD_DAT12__KEY_COL2              0x1c0 0x4c8 0x73c 0x1 0x1
+#define MX6SL_PAD_LCD_DAT12__CSI_DATA05            0x1c0 0x4c8 0x644 0x2 0x1
+#define MX6SL_PAD_LCD_DAT12__EIM_DATA06            0x1c0 0x4c8 0x000 0x3 0x0
+#define MX6SL_PAD_LCD_DAT12__UART5_RTS_B           0x1c0 0x4c8 0x818 0x4 0x2
+#define MX6SL_PAD_LCD_DAT12__UART5_CTS_B           0x1c0 0x4c8 0x000 0x4 0x0
+#define MX6SL_PAD_LCD_DAT12__GPIO3_IO00            0x1c0 0x4c8 0x000 0x5 0x0
+#define MX6SL_PAD_LCD_DAT12__ARM_TRACE12           0x1c0 0x4c8 0x000 0x6 0x0
+#define MX6SL_PAD_LCD_DAT12__SRC_BOOT_CFG12        0x1c0 0x4c8 0x000 0x7 0x0
+#define MX6SL_PAD_LCD_DAT13__LCD_DATA13            0x1c4 0x4cc 0x7ac 0x0 0x1
+#define MX6SL_PAD_LCD_DAT13__KEY_ROW2              0x1c4 0x4cc 0x75c 0x1 0x1
+#define MX6SL_PAD_LCD_DAT13__CSI_DATA04            0x1c4 0x4cc 0x640 0x2 0x1
+#define MX6SL_PAD_LCD_DAT13__EIM_DATA07            0x1c4 0x4cc 0x000 0x3 0x0
+#define MX6SL_PAD_LCD_DAT13__UART5_CTS_B           0x1c4 0x4cc 0x000 0x4 0x0
+#define MX6SL_PAD_LCD_DAT13__UART5_RTS_B           0x1c4 0x4cc 0x818 0x4 0x3
+#define MX6SL_PAD_LCD_DAT13__GPIO3_IO01            0x1c4 0x4cc 0x000 0x5 0x0
+#define MX6SL_PAD_LCD_DAT13__ARM_TRACE13           0x1c4 0x4cc 0x000 0x6 0x0
+#define MX6SL_PAD_LCD_DAT13__SRC_BOOT_CFG13        0x1c4 0x4cc 0x000 0x7 0x0
+#define MX6SL_PAD_LCD_DAT14__LCD_DATA14            0x1c8 0x4d0 0x7b0 0x0 0x1
+#define MX6SL_PAD_LCD_DAT14__KEY_COL3              0x1c8 0x4d0 0x740 0x1 0x1
+#define MX6SL_PAD_LCD_DAT14__CSI_DATA03            0x1c8 0x4d0 0x63c 0x2 0x1
+#define MX6SL_PAD_LCD_DAT14__EIM_DATA08            0x1c8 0x4d0 0x000 0x3 0x0
+#define MX6SL_PAD_LCD_DAT14__UART5_RX_DATA         0x1c8 0x4d0 0x81c 0x4 0x2
+#define MX6SL_PAD_LCD_DAT14__UART5_TX_DATA         0x1c8 0x4d0 0x000 0x4 0x0
+#define MX6SL_PAD_LCD_DAT14__GPIO3_IO02            0x1c8 0x4d0 0x000 0x5 0x0
+#define MX6SL_PAD_LCD_DAT14__ARM_TRACE14           0x1c8 0x4d0 0x000 0x6 0x0
+#define MX6SL_PAD_LCD_DAT14__SRC_BOOT_CFG14        0x1c8 0x4d0 0x000 0x7 0x0
+#define MX6SL_PAD_LCD_DAT15__LCD_DATA15            0x1cc 0x4d4 0x7b4 0x0 0x1
+#define MX6SL_PAD_LCD_DAT15__KEY_ROW3              0x1cc 0x4d4 0x760 0x1 0x1
+#define MX6SL_PAD_LCD_DAT15__CSI_DATA02            0x1cc 0x4d4 0x638 0x2 0x1
+#define MX6SL_PAD_LCD_DAT15__EIM_DATA09            0x1cc 0x4d4 0x000 0x3 0x0
+#define MX6SL_PAD_LCD_DAT15__UART5_TX_DATA         0x1cc 0x4d4 0x000 0x4 0x0
+#define MX6SL_PAD_LCD_DAT15__UART5_RX_DATA         0x1cc 0x4d4 0x81c 0x4 0x3
+#define MX6SL_PAD_LCD_DAT15__GPIO3_IO03            0x1cc 0x4d4 0x000 0x5 0x0
+#define MX6SL_PAD_LCD_DAT15__ARM_TRACE15           0x1cc 0x4d4 0x000 0x6 0x0
+#define MX6SL_PAD_LCD_DAT15__SRC_BOOT_CFG15        0x1cc 0x4d4 0x000 0x7 0x0
+#define MX6SL_PAD_LCD_DAT16__LCD_DATA16            0x1d0 0x4d8 0x7b8 0x0 0x1
+#define MX6SL_PAD_LCD_DAT16__KEY_COL4              0x1d0 0x4d8 0x744 0x1 0x1
+#define MX6SL_PAD_LCD_DAT16__CSI_DATA01            0x1d0 0x4d8 0x634 0x2 0x1
+#define MX6SL_PAD_LCD_DAT16__EIM_DATA10            0x1d0 0x4d8 0x000 0x3 0x0
+#define MX6SL_PAD_LCD_DAT16__I2C2_SCL              0x1d0 0x4d8 0x724 0x4 0x3
+#define MX6SL_PAD_LCD_DAT16__GPIO3_IO04            0x1d0 0x4d8 0x000 0x5 0x0
+#define MX6SL_PAD_LCD_DAT16__ARM_TRACE16           0x1d0 0x4d8 0x000 0x6 0x0
+#define MX6SL_PAD_LCD_DAT16__SRC_BOOT_CFG24        0x1d0 0x4d8 0x000 0x7 0x0
+#define MX6SL_PAD_LCD_DAT17__LCD_DATA17            0x1d4 0x4dc 0x7bc 0x0 0x1
+#define MX6SL_PAD_LCD_DAT17__KEY_ROW4              0x1d4 0x4dc 0x764 0x1 0x1
+#define MX6SL_PAD_LCD_DAT17__CSI_DATA00            0x1d4 0x4dc 0x630 0x2 0x1
+#define MX6SL_PAD_LCD_DAT17__EIM_DATA11            0x1d4 0x4dc 0x000 0x3 0x0
+#define MX6SL_PAD_LCD_DAT17__I2C2_SDA              0x1d4 0x4dc 0x728 0x4 0x3
+#define MX6SL_PAD_LCD_DAT17__GPIO3_IO05            0x1d4 0x4dc 0x000 0x5 0x0
+#define MX6SL_PAD_LCD_DAT17__ARM_TRACE17           0x1d4 0x4dc 0x000 0x6 0x0
+#define MX6SL_PAD_LCD_DAT17__SRC_BOOT_CFG25        0x1d4 0x4dc 0x000 0x7 0x0
+#define MX6SL_PAD_LCD_DAT18__LCD_DATA18            0x1d8 0x4e0 0x7c0 0x0 0x1
+#define MX6SL_PAD_LCD_DAT18__KEY_COL5              0x1d8 0x4e0 0x748 0x1 0x1
+#define MX6SL_PAD_LCD_DAT18__CSI_DATA15            0x1d8 0x4e0 0x66c 0x2 0x0
+#define MX6SL_PAD_LCD_DAT18__EIM_DATA12            0x1d8 0x4e0 0x000 0x3 0x0
+#define MX6SL_PAD_LCD_DAT18__GPT_CAPTURE1          0x1d8 0x4e0 0x710 0x4 0x1
+#define MX6SL_PAD_LCD_DAT18__GPIO3_IO06            0x1d8 0x4e0 0x000 0x5 0x0
+#define MX6SL_PAD_LCD_DAT18__ARM_TRACE18           0x1d8 0x4e0 0x000 0x6 0x0
+#define MX6SL_PAD_LCD_DAT18__SRC_BOOT_CFG26        0x1d8 0x4e0 0x000 0x7 0x0
+#define MX6SL_PAD_LCD_DAT19__LCD_DATA19            0x1dc 0x4e4 0x7c4 0x0 0x1
+#define MX6SL_PAD_LCD_DAT19__KEY_ROW5              0x1dc 0x4e4 0x768 0x1 0x1
+#define MX6SL_PAD_LCD_DAT19__CSI_DATA14            0x1dc 0x4e4 0x668 0x2 0x0
+#define MX6SL_PAD_LCD_DAT19__EIM_DATA13            0x1dc 0x4e4 0x000 0x3 0x0
+#define MX6SL_PAD_LCD_DAT19__GPT_CAPTURE2          0x1dc 0x4e4 0x714 0x4 0x1
+#define MX6SL_PAD_LCD_DAT19__GPIO3_IO07            0x1dc 0x4e4 0x000 0x5 0x0
+#define MX6SL_PAD_LCD_DAT19__ARM_TRACE19           0x1dc 0x4e4 0x000 0x6 0x0
+#define MX6SL_PAD_LCD_DAT19__SRC_BOOT_CFG27        0x1dc 0x4e4 0x000 0x7 0x0
+#define MX6SL_PAD_LCD_DAT2__LCD_DATA02             0x1e0 0x4e8 0x780 0x0 0x1
+#define MX6SL_PAD_LCD_DAT2__ECSPI1_SS0             0x1e0 0x4e8 0x68c 0x1 0x1
+#define MX6SL_PAD_LCD_DAT2__EPIT2_OUT              0x1e0 0x4e8 0x000 0x2 0x0
+#define MX6SL_PAD_LCD_DAT2__PWM3_OUT               0x1e0 0x4e8 0x000 0x3 0x0
+#define MX6SL_PAD_LCD_DAT2__AUD4_RXC               0x1e0 0x4e8 0x5ec 0x4 0x1
+#define MX6SL_PAD_LCD_DAT2__GPIO2_IO22             0x1e0 0x4e8 0x000 0x5 0x0
+#define MX6SL_PAD_LCD_DAT2__ARM_TRACE02            0x1e0 0x4e8 0x000 0x6 0x0
+#define MX6SL_PAD_LCD_DAT2__SRC_BOOT_CFG02         0x1e0 0x4e8 0x000 0x7 0x0
+#define MX6SL_PAD_LCD_DAT20__LCD_DATA20            0x1e4 0x4ec 0x7c8 0x0 0x1
+#define MX6SL_PAD_LCD_DAT20__KEY_COL6              0x1e4 0x4ec 0x74c 0x1 0x1
+#define MX6SL_PAD_LCD_DAT20__CSI_DATA13            0x1e4 0x4ec 0x664 0x2 0x0
+#define MX6SL_PAD_LCD_DAT20__EIM_DATA14            0x1e4 0x4ec 0x000 0x3 0x0
+#define MX6SL_PAD_LCD_DAT20__GPT_COMPARE1          0x1e4 0x4ec 0x000 0x4 0x0
+#define MX6SL_PAD_LCD_DAT20__GPIO3_IO08            0x1e4 0x4ec 0x000 0x5 0x0
+#define MX6SL_PAD_LCD_DAT20__ARM_TRACE20           0x1e4 0x4ec 0x000 0x6 0x0
+#define MX6SL_PAD_LCD_DAT20__SRC_BOOT_CFG28        0x1e4 0x4ec 0x000 0x7 0x0
+#define MX6SL_PAD_LCD_DAT21__LCD_DATA21            0x1e8 0x4f0 0x7cc 0x0 0x1
+#define MX6SL_PAD_LCD_DAT21__KEY_ROW6              0x1e8 0x4f0 0x76c 0x1 0x1
+#define MX6SL_PAD_LCD_DAT21__CSI_DATA12            0x1e8 0x4f0 0x660 0x2 0x0
+#define MX6SL_PAD_LCD_DAT21__EIM_DATA15            0x1e8 0x4f0 0x000 0x3 0x0
+#define MX6SL_PAD_LCD_DAT21__GPT_COMPARE2          0x1e8 0x4f0 0x000 0x4 0x0
+#define MX6SL_PAD_LCD_DAT21__GPIO3_IO09            0x1e8 0x4f0 0x000 0x5 0x0
+#define MX6SL_PAD_LCD_DAT21__ARM_TRACE21           0x1e8 0x4f0 0x000 0x6 0x0
+#define MX6SL_PAD_LCD_DAT21__SRC_BOOT_CFG29        0x1e8 0x4f0 0x000 0x7 0x0
+#define MX6SL_PAD_LCD_DAT22__LCD_DATA22            0x1ec 0x4f4 0x7d0 0x0 0x1
+#define MX6SL_PAD_LCD_DAT22__KEY_COL7              0x1ec 0x4f4 0x750 0x1 0x1
+#define MX6SL_PAD_LCD_DAT22__CSI_DATA11            0x1ec 0x4f4 0x65c 0x2 0x1
+#define MX6SL_PAD_LCD_DAT22__EIM_EB3_B             0x1ec 0x4f4 0x000 0x3 0x0
+#define MX6SL_PAD_LCD_DAT22__GPT_COMPARE3          0x1ec 0x4f4 0x000 0x4 0x0
+#define MX6SL_PAD_LCD_DAT22__GPIO3_IO10            0x1ec 0x4f4 0x000 0x5 0x0
+#define MX6SL_PAD_LCD_DAT22__ARM_TRACE22           0x1ec 0x4f4 0x000 0x6 0x0
+#define MX6SL_PAD_LCD_DAT22__SRC_BOOT_CFG30        0x1ec 0x4f4 0x000 0x7 0x0
+#define MX6SL_PAD_LCD_DAT23__LCD_DATA23            0x1f0 0x4f8 0x7d4 0x0 0x1
+#define MX6SL_PAD_LCD_DAT23__KEY_ROW7              0x1f0 0x4f8 0x770 0x1 0x1
+#define MX6SL_PAD_LCD_DAT23__CSI_DATA10            0x1f0 0x4f8 0x658 0x2 0x1
+#define MX6SL_PAD_LCD_DAT23__EIM_EB2_B             0x1f0 0x4f8 0x000 0x3 0x0
+#define MX6SL_PAD_LCD_DAT23__GPT_CLKIN             0x1f0 0x4f8 0x718 0x4 0x1
+#define MX6SL_PAD_LCD_DAT23__GPIO3_IO11            0x1f0 0x4f8 0x000 0x5 0x0
+#define MX6SL_PAD_LCD_DAT23__ARM_TRACE23           0x1f0 0x4f8 0x000 0x6 0x0
+#define MX6SL_PAD_LCD_DAT23__SRC_BOOT_CFG31        0x1f0 0x4f8 0x000 0x7 0x0
+#define MX6SL_PAD_LCD_DAT3__LCD_DATA03             0x1f4 0x4fc 0x784 0x0 0x1
+#define MX6SL_PAD_LCD_DAT3__ECSPI1_SCLK            0x1f4 0x4fc 0x67c 0x1 0x1
+#define MX6SL_PAD_LCD_DAT3__UART5_DSR_B            0x1f4 0x4fc 0x000 0x2 0x0
+#define MX6SL_PAD_LCD_DAT3__PWM4_OUT               0x1f4 0x4fc 0x000 0x3 0x0
+#define MX6SL_PAD_LCD_DAT3__AUD4_RXD               0x1f4 0x4fc 0x5e4 0x4 0x1
+#define MX6SL_PAD_LCD_DAT3__GPIO2_IO23             0x1f4 0x4fc 0x000 0x5 0x0
+#define MX6SL_PAD_LCD_DAT3__ARM_TRACE03            0x1f4 0x4fc 0x000 0x6 0x0
+#define MX6SL_PAD_LCD_DAT3__SRC_BOOT_CFG03         0x1f4 0x4fc 0x000 0x7 0x0
+#define MX6SL_PAD_LCD_DAT4__LCD_DATA04             0x1f8 0x500 0x788 0x0 0x1
+#define MX6SL_PAD_LCD_DAT4__ECSPI1_SS1             0x1f8 0x500 0x690 0x1 0x1
+#define MX6SL_PAD_LCD_DAT4__CSI_VSYNC              0x1f8 0x500 0x678 0x2 0x2
+#define MX6SL_PAD_LCD_DAT4__WDOG2_RESET_B_DEB      0x1f8 0x500 0x000 0x3 0x0
+#define MX6SL_PAD_LCD_DAT4__AUD4_TXC               0x1f8 0x500 0x5f4 0x4 0x1
+#define MX6SL_PAD_LCD_DAT4__GPIO2_IO24             0x1f8 0x500 0x000 0x5 0x0
+#define MX6SL_PAD_LCD_DAT4__ARM_TRACE04            0x1f8 0x500 0x000 0x6 0x0
+#define MX6SL_PAD_LCD_DAT4__SRC_BOOT_CFG04         0x1f8 0x500 0x000 0x7 0x0
+#define MX6SL_PAD_LCD_DAT5__LCD_DATA05             0x1fc 0x504 0x78c 0x0 0x1
+#define MX6SL_PAD_LCD_DAT5__ECSPI1_SS2             0x1fc 0x504 0x694 0x1 0x1
+#define MX6SL_PAD_LCD_DAT5__CSI_HSYNC              0x1fc 0x504 0x670 0x2 0x2
+#define MX6SL_PAD_LCD_DAT5__EIM_CS3_B              0x1fc 0x504 0x000 0x3 0x0
+#define MX6SL_PAD_LCD_DAT5__AUD4_TXFS              0x1fc 0x504 0x5f8 0x4 0x1
+#define MX6SL_PAD_LCD_DAT5__GPIO2_IO25             0x1fc 0x504 0x000 0x5 0x0
+#define MX6SL_PAD_LCD_DAT5__ARM_TRACE05            0x1fc 0x504 0x000 0x6 0x0
+#define MX6SL_PAD_LCD_DAT5__SRC_BOOT_CFG05         0x1fc 0x504 0x000 0x7 0x0
+#define MX6SL_PAD_LCD_DAT6__LCD_DATA06             0x200 0x508 0x790 0x0 0x1
+#define MX6SL_PAD_LCD_DAT6__ECSPI1_SS3             0x200 0x508 0x698 0x1 0x1
+#define MX6SL_PAD_LCD_DAT6__CSI_PIXCLK             0x200 0x508 0x674 0x2 0x2
+#define MX6SL_PAD_LCD_DAT6__EIM_DATA00             0x200 0x508 0x000 0x3 0x0
+#define MX6SL_PAD_LCD_DAT6__AUD4_TXD               0x200 0x508 0x5e8 0x4 0x1
+#define MX6SL_PAD_LCD_DAT6__GPIO2_IO26             0x200 0x508 0x000 0x5 0x0
+#define MX6SL_PAD_LCD_DAT6__ARM_TRACE06            0x200 0x508 0x000 0x6 0x0
+#define MX6SL_PAD_LCD_DAT6__SRC_BOOT_CFG06         0x200 0x508 0x000 0x7 0x0
+#define MX6SL_PAD_LCD_DAT7__LCD_DATA07             0x204 0x50c 0x794 0x0 0x1
+#define MX6SL_PAD_LCD_DAT7__ECSPI1_RDY             0x204 0x50c 0x680 0x1 0x1
+#define MX6SL_PAD_LCD_DAT7__CSI_MCLK               0x204 0x50c 0x000 0x2 0x0
+#define MX6SL_PAD_LCD_DAT7__EIM_DATA01             0x204 0x50c 0x000 0x3 0x0
+#define MX6SL_PAD_LCD_DAT7__AUDIO_CLK_OUT          0x204 0x50c 0x000 0x4 0x0
+#define MX6SL_PAD_LCD_DAT7__GPIO2_IO27             0x204 0x50c 0x000 0x5 0x0
+#define MX6SL_PAD_LCD_DAT7__ARM_TRACE07            0x204 0x50c 0x000 0x6 0x0
+#define MX6SL_PAD_LCD_DAT7__SRC_BOOT_CFG07         0x204 0x50c 0x000 0x7 0x0
+#define MX6SL_PAD_LCD_DAT8__LCD_DATA08             0x208 0x510 0x798 0x0 0x1
+#define MX6SL_PAD_LCD_DAT8__KEY_COL0               0x208 0x510 0x734 0x1 0x1
+#define MX6SL_PAD_LCD_DAT8__CSI_DATA09             0x208 0x510 0x654 0x2 0x1
+#define MX6SL_PAD_LCD_DAT8__EIM_DATA02             0x208 0x510 0x000 0x3 0x0
+#define MX6SL_PAD_LCD_DAT8__ECSPI2_SCLK            0x208 0x510 0x69c 0x4 0x2
+#define MX6SL_PAD_LCD_DAT8__GPIO2_IO28             0x208 0x510 0x000 0x5 0x0
+#define MX6SL_PAD_LCD_DAT8__ARM_TRACE08            0x208 0x510 0x000 0x6 0x0
+#define MX6SL_PAD_LCD_DAT8__SRC_BOOT_CFG08         0x208 0x510 0x000 0x7 0x0
+#define MX6SL_PAD_LCD_DAT9__LCD_DATA09             0x20c 0x514 0x79c 0x0 0x1
+#define MX6SL_PAD_LCD_DAT9__KEY_ROW0               0x20c 0x514 0x754 0x1 0x1
+#define MX6SL_PAD_LCD_DAT9__CSI_DATA08             0x20c 0x514 0x650 0x2 0x1
+#define MX6SL_PAD_LCD_DAT9__EIM_DATA03             0x20c 0x514 0x000 0x3 0x0
+#define MX6SL_PAD_LCD_DAT9__ECSPI2_MOSI            0x20c 0x514 0x6a4 0x4 0x2
+#define MX6SL_PAD_LCD_DAT9__GPIO2_IO29             0x20c 0x514 0x000 0x5 0x0
+#define MX6SL_PAD_LCD_DAT9__ARM_TRACE09            0x20c 0x514 0x000 0x6 0x0
+#define MX6SL_PAD_LCD_DAT9__SRC_BOOT_CFG09         0x20c 0x514 0x000 0x7 0x0
+#define MX6SL_PAD_LCD_ENABLE__LCD_ENABLE           0x210 0x518 0x000 0x0 0x0
+#define MX6SL_PAD_LCD_ENABLE__SD4_DATA5            0x210 0x518 0x870 0x1 0x2
+#define MX6SL_PAD_LCD_ENABLE__LCD_RD_E             0x210 0x518 0x000 0x2 0x0
+#define MX6SL_PAD_LCD_ENABLE__EIM_OE_B             0x210 0x518 0x000 0x3 0x0
+#define MX6SL_PAD_LCD_ENABLE__UART2_RX_DATA        0x210 0x518 0x804 0x4 0x2
+#define MX6SL_PAD_LCD_ENABLE__UART2_TX_DATA        0x210 0x518 0x000 0x4 0x0
+#define MX6SL_PAD_LCD_ENABLE__GPIO2_IO16           0x210 0x518 0x000 0x5 0x0
+#define MX6SL_PAD_LCD_HSYNC__LCD_HSYNC             0x214 0x51c 0x774 0x0 0x0
+#define MX6SL_PAD_LCD_HSYNC__SD4_DATA6             0x214 0x51c 0x874 0x1 0x2
+#define MX6SL_PAD_LCD_HSYNC__LCD_CS                0x214 0x51c 0x000 0x2 0x0
+#define MX6SL_PAD_LCD_HSYNC__EIM_CS0_B             0x214 0x51c 0x000 0x3 0x0
+#define MX6SL_PAD_LCD_HSYNC__UART2_TX_DATA         0x214 0x51c 0x000 0x4 0x0
+#define MX6SL_PAD_LCD_HSYNC__UART2_RX_DATA         0x214 0x51c 0x804 0x4 0x3
+#define MX6SL_PAD_LCD_HSYNC__GPIO2_IO17            0x214 0x51c 0x000 0x5 0x0
+#define MX6SL_PAD_LCD_HSYNC__ARM_TRACE_CLK         0x214 0x51c 0x000 0x6 0x0
+#define MX6SL_PAD_LCD_RESET__LCD_RESET             0x218 0x520 0x000 0x0 0x0
+#define MX6SL_PAD_LCD_RESET__EIM_DTACK_B           0x218 0x520 0x880 0x1 0x1
+#define MX6SL_PAD_LCD_RESET__LCD_BUSY              0x218 0x520 0x774 0x2 0x1
+#define MX6SL_PAD_LCD_RESET__EIM_WAIT_B            0x218 0x520 0x884 0x3 0x1
+#define MX6SL_PAD_LCD_RESET__UART2_CTS_B           0x218 0x520 0x000 0x4 0x0
+#define MX6SL_PAD_LCD_RESET__UART2_RTS_B           0x218 0x520 0x800 0x4 0x2
+#define MX6SL_PAD_LCD_RESET__GPIO2_IO19            0x218 0x520 0x000 0x5 0x0
+#define MX6SL_PAD_LCD_RESET__CCM_PMIC_READY        0x218 0x520 0x62c 0x6 0x1
+#define MX6SL_PAD_LCD_VSYNC__LCD_VSYNC             0x21c 0x524 0x000 0x0 0x0
+#define MX6SL_PAD_LCD_VSYNC__SD4_DATA7             0x21c 0x524 0x878 0x1 0x2
+#define MX6SL_PAD_LCD_VSYNC__LCD_RS                0x21c 0x524 0x000 0x2 0x0
+#define MX6SL_PAD_LCD_VSYNC__EIM_CS1_B             0x21c 0x524 0x000 0x3 0x0
+#define MX6SL_PAD_LCD_VSYNC__UART2_RTS_B           0x21c 0x524 0x800 0x4 0x3
+#define MX6SL_PAD_LCD_VSYNC__UART2_CTS_B           0x21c 0x524 0x000 0x4 0x0
+#define MX6SL_PAD_LCD_VSYNC__GPIO2_IO18            0x21c 0x524 0x000 0x5 0x0
+#define MX6SL_PAD_LCD_VSYNC__ARM_TRACE_CTL         0x21c 0x524 0x000 0x6 0x0
+#define MX6SL_PAD_PWM1__PWM1_OUT                   0x220 0x528 0x000 0x0 0x0
+#define MX6SL_PAD_PWM1__CCM_CLKO                   0x220 0x528 0x000 0x1 0x0
+#define MX6SL_PAD_PWM1__AUDIO_CLK_OUT              0x220 0x528 0x000 0x2 0x0
+#define MX6SL_PAD_PWM1__FEC_REF_OUT                0x220 0x528 0x000 0x3 0x0
+#define MX6SL_PAD_PWM1__CSI_MCLK                   0x220 0x528 0x000 0x4 0x0
+#define MX6SL_PAD_PWM1__GPIO3_IO23                 0x220 0x528 0x000 0x5 0x0
+#define MX6SL_PAD_PWM1__EPIT1_OUT                  0x220 0x528 0x000 0x6 0x0
+#define MX6SL_PAD_REF_CLK_24M__XTALOSC_REF_CLK_24M 0x224 0x52c 0x000 0x0 0x0
+#define MX6SL_PAD_REF_CLK_24M__I2C3_SCL            0x224 0x52c 0x72c 0x1 0x2
+#define MX6SL_PAD_REF_CLK_24M__PWM3_OUT            0x224 0x52c 0x000 0x2 0x0
+#define MX6SL_PAD_REF_CLK_24M__USB_OTG2_ID         0x224 0x52c 0x5e0 0x3 0x2
+#define MX6SL_PAD_REF_CLK_24M__CCM_PMIC_READY      0x224 0x52c 0x62c 0x4 0x2
+#define MX6SL_PAD_REF_CLK_24M__GPIO3_IO21          0x224 0x52c 0x000 0x5 0x0
+#define MX6SL_PAD_REF_CLK_24M__SD3_WP              0x224 0x52c 0x84c 0x6 0x3
+#define MX6SL_PAD_REF_CLK_32K__XTALOSC_REF_CLK_32K 0x228 0x530 0x000 0x0 0x0
+#define MX6SL_PAD_REF_CLK_32K__I2C3_SDA            0x228 0x530 0x730 0x1 0x2
+#define MX6SL_PAD_REF_CLK_32K__PWM4_OUT            0x228 0x530 0x000 0x2 0x0
+#define MX6SL_PAD_REF_CLK_32K__USB_OTG1_ID         0x228 0x530 0x5dc 0x3 0x3
+#define MX6SL_PAD_REF_CLK_32K__SD1_LCTL            0x228 0x530 0x000 0x4 0x0
+#define MX6SL_PAD_REF_CLK_32K__GPIO3_IO22          0x228 0x530 0x000 0x5 0x0
+#define MX6SL_PAD_REF_CLK_32K__SD3_CD_B            0x228 0x530 0x838 0x6 0x3
+#define MX6SL_PAD_SD1_CLK__SD1_CLK                 0x22c 0x534 0x000 0x0 0x0
+#define MX6SL_PAD_SD1_CLK__FEC_MDIO                0x22c 0x534 0x6f4 0x1 0x2
+#define MX6SL_PAD_SD1_CLK__KEY_COL0                0x22c 0x534 0x734 0x2 0x2
+#define MX6SL_PAD_SD1_CLK__EPDC_SDCE4              0x22c 0x534 0x000 0x3 0x0
+#define MX6SL_PAD_SD1_CLK__GPIO5_IO15              0x22c 0x534 0x000 0x5 0x0
+#define MX6SL_PAD_SD1_CMD__SD1_CMD                 0x230 0x538 0x000 0x0 0x0
+#define MX6SL_PAD_SD1_CMD__FEC_TX_CLK              0x230 0x538 0x70c 0x1 0x2
+#define MX6SL_PAD_SD1_CMD__KEY_ROW0                0x230 0x538 0x754 0x2 0x2
+#define MX6SL_PAD_SD1_CMD__EPDC_SDCE5              0x230 0x538 0x000 0x3 0x0
+#define MX6SL_PAD_SD1_CMD__GPIO5_IO14              0x230 0x538 0x000 0x5 0x0
+#define MX6SL_PAD_SD1_DAT0__SD1_DATA0              0x234 0x53c 0x000 0x0 0x0
+#define MX6SL_PAD_SD1_DAT0__FEC_RX_ER              0x234 0x53c 0x708 0x1 0x2
+#define MX6SL_PAD_SD1_DAT0__KEY_COL1               0x234 0x53c 0x738 0x2 0x2
+#define MX6SL_PAD_SD1_DAT0__EPDC_SDCE6             0x234 0x53c 0x000 0x3 0x0
+#define MX6SL_PAD_SD1_DAT0__GPIO5_IO11             0x234 0x53c 0x000 0x5 0x0
+#define MX6SL_PAD_SD1_DAT1__SD1_DATA1              0x238 0x540 0x000 0x0 0x0
+#define MX6SL_PAD_SD1_DAT1__FEC_RX_DV              0x238 0x540 0x704 0x1 0x2
+#define MX6SL_PAD_SD1_DAT1__KEY_ROW1               0x238 0x540 0x758 0x2 0x2
+#define MX6SL_PAD_SD1_DAT1__EPDC_SDCE7             0x238 0x540 0x000 0x3 0x0
+#define MX6SL_PAD_SD1_DAT1__GPIO5_IO08             0x238 0x540 0x000 0x5 0x0
+#define MX6SL_PAD_SD1_DAT2__SD1_DATA2              0x23c 0x544 0x000 0x0 0x0
+#define MX6SL_PAD_SD1_DAT2__FEC_RX_DATA1           0x23c 0x544 0x6fc 0x1 0x2
+#define MX6SL_PAD_SD1_DAT2__KEY_COL2               0x23c 0x544 0x73c 0x2 0x2
+#define MX6SL_PAD_SD1_DAT2__EPDC_SDCE8             0x23c 0x544 0x000 0x3 0x0
+#define MX6SL_PAD_SD1_DAT2__GPIO5_IO13             0x23c 0x544 0x000 0x5 0x0
+#define MX6SL_PAD_SD1_DAT3__SD1_DATA3              0x240 0x548 0x000 0x0 0x0
+#define MX6SL_PAD_SD1_DAT3__FEC_TX_DATA0           0x240 0x548 0x000 0x1 0x0
+#define MX6SL_PAD_SD1_DAT3__KEY_ROW2               0x240 0x548 0x75c 0x2 0x2
+#define MX6SL_PAD_SD1_DAT3__EPDC_SDCE9             0x240 0x548 0x000 0x3 0x0
+#define MX6SL_PAD_SD1_DAT3__GPIO5_IO06             0x240 0x548 0x000 0x5 0x0
+#define MX6SL_PAD_SD1_DAT4__SD1_DATA4              0x244 0x54c 0x000 0x0 0x0
+#define MX6SL_PAD_SD1_DAT4__FEC_MDC                0x244 0x54c 0x000 0x1 0x0
+#define MX6SL_PAD_SD1_DAT4__KEY_COL3               0x244 0x54c 0x740 0x2 0x2
+#define MX6SL_PAD_SD1_DAT4__EPDC_SDCLK_N           0x244 0x54c 0x000 0x3 0x0
+#define MX6SL_PAD_SD1_DAT4__UART4_RX_DATA          0x244 0x54c 0x814 0x4 0x4
+#define MX6SL_PAD_SD1_DAT4__UART4_TX_DATA          0x244 0x54c 0x000 0x4 0x0
+#define MX6SL_PAD_SD1_DAT4__GPIO5_IO12             0x244 0x54c 0x000 0x5 0x0
+#define MX6SL_PAD_SD1_DAT5__SD1_DATA5              0x248 0x550 0x000 0x0 0x0
+#define MX6SL_PAD_SD1_DAT5__FEC_RX_DATA0           0x248 0x550 0x6f8 0x1 0x2
+#define MX6SL_PAD_SD1_DAT5__KEY_ROW3               0x248 0x550 0x760 0x2 0x2
+#define MX6SL_PAD_SD1_DAT5__EPDC_SDOED             0x248 0x550 0x000 0x3 0x0
+#define MX6SL_PAD_SD1_DAT5__UART4_TX_DATA          0x248 0x550 0x000 0x4 0x0
+#define MX6SL_PAD_SD1_DAT5__UART4_RX_DATA          0x248 0x550 0x814 0x4 0x5
+#define MX6SL_PAD_SD1_DAT5__GPIO5_IO09             0x248 0x550 0x000 0x5 0x0
+#define MX6SL_PAD_SD1_DAT6__SD1_DATA6              0x24c 0x554 0x000 0x0 0x0
+#define MX6SL_PAD_SD1_DAT6__FEC_TX_EN              0x24c 0x554 0x000 0x1 0x0
+#define MX6SL_PAD_SD1_DAT6__KEY_COL4               0x24c 0x554 0x744 0x2 0x2
+#define MX6SL_PAD_SD1_DAT6__EPDC_SDOEZ             0x24c 0x554 0x000 0x3 0x0
+#define MX6SL_PAD_SD1_DAT6__UART4_RTS_B            0x24c 0x554 0x810 0x4 0x4
+#define MX6SL_PAD_SD1_DAT6__UART4_CTS_B            0x24c 0x554 0x000 0x4 0x0
+#define MX6SL_PAD_SD1_DAT6__GPIO5_IO07             0x24c 0x554 0x000 0x5 0x0
+#define MX6SL_PAD_SD1_DAT7__SD1_DATA7              0x250 0x558 0x000 0x0 0x0
+#define MX6SL_PAD_SD1_DAT7__FEC_TX_DATA1           0x250 0x558 0x000 0x1 0x0
+#define MX6SL_PAD_SD1_DAT7__KEY_ROW4               0x250 0x558 0x764 0x2 0x2
+#define MX6SL_PAD_SD1_DAT7__CCM_PMIC_READY         0x250 0x558 0x62c 0x3 0x3
+#define MX6SL_PAD_SD1_DAT7__UART4_CTS_B            0x250 0x558 0x000 0x4 0x0
+#define MX6SL_PAD_SD1_DAT7__UART4_RTS_B            0x250 0x558 0x810 0x4 0x5
+#define MX6SL_PAD_SD1_DAT7__GPIO5_IO10             0x250 0x558 0x000 0x5 0x0
+#define MX6SL_PAD_SD2_CLK__SD2_CLK                 0x254 0x55c 0x000 0x0 0x0
+#define MX6SL_PAD_SD2_CLK__AUD4_RXFS               0x254 0x55c 0x5f0 0x1 0x2
+#define MX6SL_PAD_SD2_CLK__ECSPI3_SCLK             0x254 0x55c 0x6b0 0x2 0x2
+#define MX6SL_PAD_SD2_CLK__CSI_DATA00              0x254 0x55c 0x630 0x3 0x2
+#define MX6SL_PAD_SD2_CLK__GPIO5_IO05              0x254 0x55c 0x000 0x5 0x0
+#define MX6SL_PAD_SD2_CMD__SD2_CMD                 0x258 0x560 0x000 0x0 0x0
+#define MX6SL_PAD_SD2_CMD__AUD4_RXC                0x258 0x560 0x5ec 0x1 0x2
+#define MX6SL_PAD_SD2_CMD__ECSPI3_SS0              0x258 0x560 0x6c0 0x2 0x2
+#define MX6SL_PAD_SD2_CMD__CSI_DATA01              0x258 0x560 0x634 0x3 0x2
+#define MX6SL_PAD_SD2_CMD__EPIT1_OUT               0x258 0x560 0x000 0x4 0x0
+#define MX6SL_PAD_SD2_CMD__GPIO5_IO04              0x258 0x560 0x000 0x5 0x0
+#define MX6SL_PAD_SD2_DAT0__SD2_DATA0              0x25c 0x564 0x000 0x0 0x0
+#define MX6SL_PAD_SD2_DAT0__AUD4_RXD               0x25c 0x564 0x5e4 0x1 0x2
+#define MX6SL_PAD_SD2_DAT0__ECSPI3_MOSI            0x25c 0x564 0x6bc 0x2 0x2
+#define MX6SL_PAD_SD2_DAT0__CSI_DATA02             0x25c 0x564 0x638 0x3 0x2
+#define MX6SL_PAD_SD2_DAT0__UART5_RTS_B            0x25c 0x564 0x818 0x4 0x4
+#define MX6SL_PAD_SD2_DAT0__UART5_CTS_B            0x25c 0x564 0x000 0x4 0x0
+#define MX6SL_PAD_SD2_DAT0__GPIO5_IO01             0x25c 0x564 0x000 0x5 0x0
+#define MX6SL_PAD_SD2_DAT1__SD2_DATA1              0x260 0x568 0x000 0x0 0x0
+#define MX6SL_PAD_SD2_DAT1__AUD4_TXC               0x260 0x568 0x5f4 0x1 0x2
+#define MX6SL_PAD_SD2_DAT1__ECSPI3_MISO            0x260 0x568 0x6b8 0x2 0x2
+#define MX6SL_PAD_SD2_DAT1__CSI_DATA03             0x260 0x568 0x63c 0x3 0x2
+#define MX6SL_PAD_SD2_DAT1__UART5_CTS_B            0x260 0x568 0x000 0x4 0x0
+#define MX6SL_PAD_SD2_DAT1__UART5_RTS_B            0x260 0x568 0x818 0x4 0x5
+#define MX6SL_PAD_SD2_DAT1__GPIO4_IO30             0x260 0x568 0x000 0x5 0x0
+#define MX6SL_PAD_SD2_DAT2__SD2_DATA2              0x264 0x56c 0x000 0x0 0x0
+#define MX6SL_PAD_SD2_DAT2__AUD4_TXFS              0x264 0x56c 0x5f8 0x1 0x2
+#define MX6SL_PAD_SD2_DAT2__FEC_COL                0x264 0x56c 0x6f0 0x2 0x1
+#define MX6SL_PAD_SD2_DAT2__CSI_DATA04             0x264 0x56c 0x640 0x3 0x2
+#define MX6SL_PAD_SD2_DAT2__UART5_RX_DATA          0x264 0x56c 0x81c 0x4 0x4
+#define MX6SL_PAD_SD2_DAT2__UART5_TX_DATA          0x264 0x56c 0x000 0x4 0x0
+#define MX6SL_PAD_SD2_DAT2__GPIO5_IO03             0x264 0x56c 0x000 0x5 0x0
+#define MX6SL_PAD_SD2_DAT3__SD2_DATA3              0x268 0x570 0x000 0x0 0x0
+#define MX6SL_PAD_SD2_DAT3__AUD4_TXD               0x268 0x570 0x5e8 0x1 0x2
+#define MX6SL_PAD_SD2_DAT3__FEC_RX_CLK             0x268 0x570 0x700 0x2 0x1
+#define MX6SL_PAD_SD2_DAT3__CSI_DATA05             0x268 0x570 0x644 0x3 0x2
+#define MX6SL_PAD_SD2_DAT3__UART5_TX_DATA          0x268 0x570 0x000 0x4 0x0
+#define MX6SL_PAD_SD2_DAT3__UART5_RX_DATA          0x268 0x570 0x81c 0x4 0x5
+#define MX6SL_PAD_SD2_DAT3__GPIO4_IO28             0x268 0x570 0x000 0x5 0x0
+#define MX6SL_PAD_SD2_DAT4__SD2_DATA4              0x26c 0x574 0x000 0x0 0x0
+#define MX6SL_PAD_SD2_DAT4__SD3_DATA4              0x26c 0x574 0x83c 0x1 0x1
+#define MX6SL_PAD_SD2_DAT4__UART2_RX_DATA          0x26c 0x574 0x804 0x2 0x4
+#define MX6SL_PAD_SD2_DAT4__UART2_TX_DATA          0x26c 0x574 0x000 0x2 0x0
+#define MX6SL_PAD_SD2_DAT4__CSI_DATA06             0x26c 0x574 0x648 0x3 0x2
+#define MX6SL_PAD_SD2_DAT4__SPDIF_OUT              0x26c 0x574 0x000 0x4 0x0
+#define MX6SL_PAD_SD2_DAT4__GPIO5_IO02             0x26c 0x574 0x000 0x5 0x0
+#define MX6SL_PAD_SD2_DAT5__SD2_DATA5              0x270 0x578 0x000 0x0 0x0
+#define MX6SL_PAD_SD2_DAT5__SD3_DATA5              0x270 0x578 0x840 0x1 0x1
+#define MX6SL_PAD_SD2_DAT5__UART2_TX_DATA          0x270 0x578 0x000 0x2 0x0
+#define MX6SL_PAD_SD2_DAT5__UART2_RX_DATA          0x270 0x578 0x804 0x2 0x5
+#define MX6SL_PAD_SD2_DAT5__CSI_DATA07             0x270 0x578 0x64c 0x3 0x2
+#define MX6SL_PAD_SD2_DAT5__SPDIF_IN               0x270 0x578 0x7f0 0x4 0x2
+#define MX6SL_PAD_SD2_DAT5__GPIO4_IO31             0x270 0x578 0x000 0x5 0x0
+#define MX6SL_PAD_SD2_DAT6__SD2_DATA6              0x274 0x57c 0x000 0x0 0x0
+#define MX6SL_PAD_SD2_DAT6__SD3_DATA6              0x274 0x57c 0x844 0x1 0x1
+#define MX6SL_PAD_SD2_DAT6__UART2_RTS_B            0x274 0x57c 0x800 0x2 0x4
+#define MX6SL_PAD_SD2_DAT6__UART2_CTS_B            0x274 0x57c 0x000 0x2 0x0
+#define MX6SL_PAD_SD2_DAT6__CSI_DATA08             0x274 0x57c 0x650 0x3 0x2
+#define MX6SL_PAD_SD2_DAT6__SD2_WP                 0x274 0x57c 0x834 0x4 0x2
+#define MX6SL_PAD_SD2_DAT6__GPIO4_IO29             0x274 0x57c 0x000 0x5 0x0
+#define MX6SL_PAD_SD2_DAT7__SD2_DATA7              0x278 0x580 0x000 0x0 0x0
+#define MX6SL_PAD_SD2_DAT7__SD3_DATA7              0x278 0x580 0x848 0x1 0x1
+#define MX6SL_PAD_SD2_DAT7__UART2_CTS_B            0x278 0x580 0x000 0x2 0x0
+#define MX6SL_PAD_SD2_DAT7__UART2_RTS_B            0x278 0x580 0x800 0x2 0x5
+#define MX6SL_PAD_SD2_DAT7__CSI_DATA09             0x278 0x580 0x654 0x3 0x2
+#define MX6SL_PAD_SD2_DAT7__SD2_CD_B               0x278 0x580 0x830 0x4 0x2
+#define MX6SL_PAD_SD2_DAT7__GPIO5_IO00             0x278 0x580 0x000 0x5 0x0
+#define MX6SL_PAD_SD2_RST__SD2_RESET               0x27c 0x584 0x000 0x0 0x0
+#define MX6SL_PAD_SD2_RST__FEC_REF_OUT             0x27c 0x584 0x000 0x1 0x0
+#define MX6SL_PAD_SD2_RST__WDOG2_B                 0x27c 0x584 0x000 0x2 0x0
+#define MX6SL_PAD_SD2_RST__SPDIF_OUT               0x27c 0x584 0x000 0x3 0x0
+#define MX6SL_PAD_SD2_RST__CSI_MCLK                0x27c 0x584 0x000 0x4 0x0
+#define MX6SL_PAD_SD2_RST__GPIO4_IO27              0x27c 0x584 0x000 0x5 0x0
+#define MX6SL_PAD_SD3_CLK__SD3_CLK                 0x280 0x588 0x000 0x0 0x0
+#define MX6SL_PAD_SD3_CLK__AUD5_RXFS               0x280 0x588 0x608 0x1 0x1
+#define MX6SL_PAD_SD3_CLK__KEY_COL5                0x280 0x588 0x748 0x2 0x2
+#define MX6SL_PAD_SD3_CLK__CSI_DATA10              0x280 0x588 0x658 0x3 0x2
+#define MX6SL_PAD_SD3_CLK__WDOG1_RESET_B_DEB       0x280 0x588 0x000 0x4 0x0
+#define MX6SL_PAD_SD3_CLK__GPIO5_IO18              0x280 0x588 0x000 0x5 0x0
+#define MX6SL_PAD_SD3_CLK__USB_OTG1_PWR            0x280 0x588 0x000 0x6 0x0
+#define MX6SL_PAD_SD3_CMD__SD3_CMD                 0x284 0x58c 0x000 0x0 0x0
+#define MX6SL_PAD_SD3_CMD__AUD5_RXC                0x284 0x58c 0x604 0x1 0x1
+#define MX6SL_PAD_SD3_CMD__KEY_ROW5                0x284 0x58c 0x768 0x2 0x2
+#define MX6SL_PAD_SD3_CMD__CSI_DATA11              0x284 0x58c 0x65c 0x3 0x2
+#define MX6SL_PAD_SD3_CMD__USB_OTG2_ID             0x284 0x58c 0x5e0 0x4 0x3
+#define MX6SL_PAD_SD3_CMD__GPIO5_IO21              0x284 0x58c 0x000 0x5 0x0
+#define MX6SL_PAD_SD3_CMD__USB_OTG2_PWR            0x284 0x58c 0x000 0x6 0x0
+#define MX6SL_PAD_SD3_DAT0__SD3_DATA0              0x288 0x590 0x000 0x0 0x0
+#define MX6SL_PAD_SD3_DAT0__AUD5_RXD               0x288 0x590 0x5fc 0x1 0x1
+#define MX6SL_PAD_SD3_DAT0__KEY_COL6               0x288 0x590 0x74c 0x2 0x2
+#define MX6SL_PAD_SD3_DAT0__CSI_DATA12             0x288 0x590 0x660 0x3 0x1
+#define MX6SL_PAD_SD3_DAT0__USB_OTG1_ID            0x288 0x590 0x5dc 0x4 0x4
+#define MX6SL_PAD_SD3_DAT0__GPIO5_IO19             0x288 0x590 0x000 0x5 0x0
+#define MX6SL_PAD_SD3_DAT1__SD3_DATA1              0x28c 0x594 0x000 0x0 0x0
+#define MX6SL_PAD_SD3_DAT1__AUD5_TXC               0x28c 0x594 0x60c 0x1 0x1
+#define MX6SL_PAD_SD3_DAT1__KEY_ROW6               0x28c 0x594 0x76c 0x2 0x2
+#define MX6SL_PAD_SD3_DAT1__CSI_DATA13             0x28c 0x594 0x664 0x3 0x1
+#define MX6SL_PAD_SD3_DAT1__SD1_VSELECT            0x28c 0x594 0x000 0x4 0x0
+#define MX6SL_PAD_SD3_DAT1__GPIO5_IO20             0x28c 0x594 0x000 0x5 0x0
+#define MX6SL_PAD_SD3_DAT1__JTAG_DE_B              0x28c 0x594 0x000 0x6 0x0
+#define MX6SL_PAD_SD3_DAT2__SD3_DATA2              0x290 0x598 0x000 0x0 0x0
+#define MX6SL_PAD_SD3_DAT2__AUD5_TXFS              0x290 0x598 0x610 0x1 0x1
+#define MX6SL_PAD_SD3_DAT2__KEY_COL7               0x290 0x598 0x750 0x2 0x2
+#define MX6SL_PAD_SD3_DAT2__CSI_DATA14             0x290 0x598 0x668 0x3 0x1
+#define MX6SL_PAD_SD3_DAT2__EPIT1_OUT              0x290 0x598 0x000 0x4 0x0
+#define MX6SL_PAD_SD3_DAT2__GPIO5_IO16             0x290 0x598 0x000 0x5 0x0
+#define MX6SL_PAD_SD3_DAT2__USB_OTG2_OC            0x290 0x598 0x820 0x6 0x3
+#define MX6SL_PAD_SD3_DAT3__SD3_DATA3              0x294 0x59c 0x000 0x0 0x0
+#define MX6SL_PAD_SD3_DAT3__AUD5_TXD               0x294 0x59c 0x600 0x1 0x1
+#define MX6SL_PAD_SD3_DAT3__KEY_ROW7               0x294 0x59c 0x770 0x2 0x2
+#define MX6SL_PAD_SD3_DAT3__CSI_DATA15             0x294 0x59c 0x66c 0x3 0x1
+#define MX6SL_PAD_SD3_DAT3__EPIT2_OUT              0x294 0x59c 0x000 0x4 0x0
+#define MX6SL_PAD_SD3_DAT3__GPIO5_IO17             0x294 0x59c 0x000 0x5 0x0
+#define MX6SL_PAD_SD3_DAT3__USB_OTG1_OC            0x294 0x59c 0x824 0x6 0x2
+#define MX6SL_PAD_UART1_RXD__UART1_RX_DATA         0x298 0x5a0 0x7fc 0x0 0x0
+#define MX6SL_PAD_UART1_RXD__UART1_TX_DATA         0x298 0x5a0 0x000 0x0 0x0
+#define MX6SL_PAD_UART1_RXD__PWM1_OUT              0x298 0x5a0 0x000 0x1 0x0
+#define MX6SL_PAD_UART1_RXD__UART4_RX_DATA         0x298 0x5a0 0x814 0x2 0x6
+#define MX6SL_PAD_UART1_RXD__UART4_TX_DATA         0x298 0x5a0 0x000 0x2 0x0
+#define MX6SL_PAD_UART1_RXD__FEC_COL               0x298 0x5a0 0x6f0 0x3 0x2
+#define MX6SL_PAD_UART1_RXD__UART5_RX_DATA         0x298 0x5a0 0x81c 0x4 0x6
+#define MX6SL_PAD_UART1_RXD__UART5_TX_DATA         0x298 0x5a0 0x000 0x4 0x0
+#define MX6SL_PAD_UART1_RXD__GPIO3_IO16            0x298 0x5a0 0x000 0x5 0x0
+#define MX6SL_PAD_UART1_TXD__UART1_TX_DATA         0x29c 0x5a4 0x000 0x0 0x0
+#define MX6SL_PAD_UART1_TXD__UART1_RX_DATA         0x29c 0x5a4 0x7fc 0x0 0x1
+#define MX6SL_PAD_UART1_TXD__PWM2_OUT              0x29c 0x5a4 0x000 0x1 0x0
+#define MX6SL_PAD_UART1_TXD__UART4_TX_DATA         0x29c 0x5a4 0x000 0x2 0x0
+#define MX6SL_PAD_UART1_TXD__UART4_RX_DATA         0x29c 0x5a4 0x814 0x2 0x7
+#define MX6SL_PAD_UART1_TXD__FEC_RX_CLK            0x29c 0x5a4 0x700 0x3 0x2
+#define MX6SL_PAD_UART1_TXD__UART5_TX_DATA         0x29c 0x5a4 0x000 0x4 0x0
+#define MX6SL_PAD_UART1_TXD__UART5_RX_DATA         0x29c 0x5a4 0x81c 0x4 0x7
+#define MX6SL_PAD_UART1_TXD__GPIO3_IO17            0x29c 0x5a4 0x000 0x5 0x0
+#define MX6SL_PAD_UART1_TXD__UART5_DCD_B           0x29c 0x5a4 0x000 0x7 0x0
+#define MX6SL_PAD_WDOG_B__WDOG1_B                  0x2a0 0x5a8 0x000 0x0 0x0
+#define MX6SL_PAD_WDOG_B__WDOG1_RESET_B_DEB        0x2a0 0x5a8 0x000 0x1 0x0
+#define MX6SL_PAD_WDOG_B__UART5_RI_B               0x2a0 0x5a8 0x000 0x2 0x0
+#define MX6SL_PAD_WDOG_B__GPIO3_IO18               0x2a0 0x5a8 0x000 0x5 0x0
+
+#endif /* __DTS_IMX6SL_PINFUNC_H */
diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index e8a564a..f06df07 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -100,6 +100,14 @@ config PINCTRL_IMX6Q
 	help
 	  Say Y here to enable the imx6q/dl pinctrl driver
 
+config PINCTRL_IMX6SL
+	bool "IMX6SL pinctrl driver"
+	depends on OF
+	depends on SOC_IMX6SL
+	select PINCTRL_IMX
+	help
+	  Say Y here to enable the imx6sl pinctrl driver
+
 config PINCTRL_LANTIQ
 	bool
 	depends on LANTIQ
diff --git a/drivers/pinctrl/pinctrl-imx6sl.c b/drivers/pinctrl/pinctrl-imx6sl.c
new file mode 100644
index 0000000..cac184d
--- /dev/null
+++ b/drivers/pinctrl/pinctrl-imx6sl.c
@@ -0,0 +1,365 @@
+/*
+ * Copyright (C) 2013 Freescale Semiconductor, Inc.
+ *
+ * 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/err.h>
+#include <linux/init.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/pinctrl/pinctrl.h>
+
+#include "pinctrl-imx.h"
+
+enum imx6sl_pads {
+	MX6SL_PAD_AUD_MCLK = 19,
+	MX6SL_PAD_AUD_RXC = 20,
+	MX6SL_PAD_AUD_RXD = 21,
+	MX6SL_PAD_AUD_RXFS = 22,
+	MX6SL_PAD_AUD_TXC = 23,
+	MX6SL_PAD_AUD_TXD = 24,
+	MX6SL_PAD_AUD_TXFS = 25,
+	MX6SL_PAD_ECSPI1_MISO = 26,
+	MX6SL_PAD_ECSPI1_MOSI = 27,
+	MX6SL_PAD_ECSPI1_SCLK = 28,
+	MX6SL_PAD_ECSPI1_SS0 = 29,
+	MX6SL_PAD_ECSPI2_MISO = 30,
+	MX6SL_PAD_ECSPI2_MOSI = 31,
+	MX6SL_PAD_ECSPI2_SCLK = 32,
+	MX6SL_PAD_ECSPI2_SS0 = 33,
+	MX6SL_PAD_EPDC_BDR0 = 34,
+	MX6SL_PAD_EPDC_BDR1 = 35,
+	MX6SL_PAD_EPDC_D0 = 36,
+	MX6SL_PAD_EPDC_D1 = 37,
+	MX6SL_PAD_EPDC_D10 = 38,
+	MX6SL_PAD_EPDC_D11 = 39,
+	MX6SL_PAD_EPDC_D12 = 40,
+	MX6SL_PAD_EPDC_D13 = 41,
+	MX6SL_PAD_EPDC_D14 = 42,
+	MX6SL_PAD_EPDC_D15 = 43,
+	MX6SL_PAD_EPDC_D2 = 44,
+	MX6SL_PAD_EPDC_D3 = 45,
+	MX6SL_PAD_EPDC_D4 = 46,
+	MX6SL_PAD_EPDC_D5 = 47,
+	MX6SL_PAD_EPDC_D6 = 48,
+	MX6SL_PAD_EPDC_D7 = 49,
+	MX6SL_PAD_EPDC_D8 = 50,
+	MX6SL_PAD_EPDC_D9 = 51,
+	MX6SL_PAD_EPDC_GDCLK = 52,
+	MX6SL_PAD_EPDC_GDOE = 53,
+	MX6SL_PAD_EPDC_GDRL = 54,
+	MX6SL_PAD_EPDC_GDSP = 55,
+	MX6SL_PAD_EPDC_PWRCOM = 56,
+	MX6SL_PAD_EPDC_PWRCTRL0 = 57,
+	MX6SL_PAD_EPDC_PWRCTRL1 = 58,
+	MX6SL_PAD_EPDC_PWRCTRL2 = 59,
+	MX6SL_PAD_EPDC_PWRCTRL3 = 60,
+	MX6SL_PAD_EPDC_PWRINT = 61,
+	MX6SL_PAD_EPDC_PWRSTAT = 62,
+	MX6SL_PAD_EPDC_PWRWAKEUP = 63,
+	MX6SL_PAD_EPDC_SDCE0 = 64,
+	MX6SL_PAD_EPDC_SDCE1 = 65,
+	MX6SL_PAD_EPDC_SDCE2 = 66,
+	MX6SL_PAD_EPDC_SDCE3 = 67,
+	MX6SL_PAD_EPDC_SDCLK = 68,
+	MX6SL_PAD_EPDC_SDLE = 69,
+	MX6SL_PAD_EPDC_SDOE = 70,
+	MX6SL_PAD_EPDC_SDSHR = 71,
+	MX6SL_PAD_EPDC_VCOM0 = 72,
+	MX6SL_PAD_EPDC_VCOM1 = 73,
+	MX6SL_PAD_FEC_CRS_DV = 74,
+	MX6SL_PAD_FEC_MDC = 75,
+	MX6SL_PAD_FEC_MDIO = 76,
+	MX6SL_PAD_FEC_REF_CLK = 77,
+	MX6SL_PAD_FEC_RX_ER = 78,
+	MX6SL_PAD_FEC_RXD0 = 79,
+	MX6SL_PAD_FEC_RXD1 = 80,
+	MX6SL_PAD_FEC_TX_CLK = 81,
+	MX6SL_PAD_FEC_TX_EN = 82,
+	MX6SL_PAD_FEC_TXD0 = 83,
+	MX6SL_PAD_FEC_TXD1 = 84,
+	MX6SL_PAD_HSIC_DAT = 85,
+	MX6SL_PAD_HSIC_STROBE = 86,
+	MX6SL_PAD_I2C1_SCL = 87,
+	MX6SL_PAD_I2C1_SDA = 88,
+	MX6SL_PAD_I2C2_SCL = 89,
+	MX6SL_PAD_I2C2_SDA = 90,
+	MX6SL_PAD_KEY_COL0 = 91,
+	MX6SL_PAD_KEY_COL1 = 92,
+	MX6SL_PAD_KEY_COL2 = 93,
+	MX6SL_PAD_KEY_COL3 = 94,
+	MX6SL_PAD_KEY_COL4 = 95,
+	MX6SL_PAD_KEY_COL5 = 96,
+	MX6SL_PAD_KEY_COL6 = 97,
+	MX6SL_PAD_KEY_COL7 = 98,
+	MX6SL_PAD_KEY_ROW0 = 99,
+	MX6SL_PAD_KEY_ROW1 = 100,
+	MX6SL_PAD_KEY_ROW2 = 101,
+	MX6SL_PAD_KEY_ROW3 = 102,
+	MX6SL_PAD_KEY_ROW4 = 103,
+	MX6SL_PAD_KEY_ROW5 = 104,
+	MX6SL_PAD_KEY_ROW6 = 105,
+	MX6SL_PAD_KEY_ROW7 = 106,
+	MX6SL_PAD_LCD_CLK = 107,
+	MX6SL_PAD_LCD_DAT0 = 108,
+	MX6SL_PAD_LCD_DAT1 = 109,
+	MX6SL_PAD_LCD_DAT10 = 110,
+	MX6SL_PAD_LCD_DAT11 = 111,
+	MX6SL_PAD_LCD_DAT12 = 112,
+	MX6SL_PAD_LCD_DAT13 = 113,
+	MX6SL_PAD_LCD_DAT14 = 114,
+	MX6SL_PAD_LCD_DAT15 = 115,
+	MX6SL_PAD_LCD_DAT16 = 116,
+	MX6SL_PAD_LCD_DAT17 = 117,
+	MX6SL_PAD_LCD_DAT18 = 118,
+	MX6SL_PAD_LCD_DAT19 = 119,
+	MX6SL_PAD_LCD_DAT2 = 120,
+	MX6SL_PAD_LCD_DAT20 = 121,
+	MX6SL_PAD_LCD_DAT21 = 122,
+	MX6SL_PAD_LCD_DAT22 = 123,
+	MX6SL_PAD_LCD_DAT23 = 124,
+	MX6SL_PAD_LCD_DAT3 = 125,
+	MX6SL_PAD_LCD_DAT4 = 126,
+	MX6SL_PAD_LCD_DAT5 = 127,
+	MX6SL_PAD_LCD_DAT6 = 128,
+	MX6SL_PAD_LCD_DAT7 = 129,
+	MX6SL_PAD_LCD_DAT8 = 130,
+	MX6SL_PAD_LCD_DAT9 = 131,
+	MX6SL_PAD_LCD_ENABLE = 132,
+	MX6SL_PAD_LCD_HSYNC = 133,
+	MX6SL_PAD_LCD_RESET = 134,
+	MX6SL_PAD_LCD_VSYNC = 135,
+	MX6SL_PAD_PWM1 = 136,
+	MX6SL_PAD_REF_CLK_24M = 137,
+	MX6SL_PAD_REF_CLK_32K = 138,
+	MX6SL_PAD_SD1_CLK = 139,
+	MX6SL_PAD_SD1_CMD = 140,
+	MX6SL_PAD_SD1_DAT0 = 141,
+	MX6SL_PAD_SD1_DAT1 = 142,
+	MX6SL_PAD_SD1_DAT2 = 143,
+	MX6SL_PAD_SD1_DAT3 = 144,
+	MX6SL_PAD_SD1_DAT4 = 145,
+	MX6SL_PAD_SD1_DAT5 = 146,
+	MX6SL_PAD_SD1_DAT6 = 147,
+	MX6SL_PAD_SD1_DAT7 = 148,
+	MX6SL_PAD_SD2_CLK = 149,
+	MX6SL_PAD_SD2_CMD = 150,
+	MX6SL_PAD_SD2_DAT0 = 151,
+	MX6SL_PAD_SD2_DAT1 = 152,
+	MX6SL_PAD_SD2_DAT2 = 153,
+	MX6SL_PAD_SD2_DAT3 = 154,
+	MX6SL_PAD_SD2_DAT4 = 155,
+	MX6SL_PAD_SD2_DAT5 = 156,
+	MX6SL_PAD_SD2_DAT6 = 157,
+	MX6SL_PAD_SD2_DAT7 = 158,
+	MX6SL_PAD_SD2_RST = 159,
+	MX6SL_PAD_SD3_CLK = 160,
+	MX6SL_PAD_SD3_CMD = 161,
+	MX6SL_PAD_SD3_DAT0 = 162,
+	MX6SL_PAD_SD3_DAT1 = 163,
+	MX6SL_PAD_SD3_DAT2 = 164,
+	MX6SL_PAD_SD3_DAT3 = 165,
+	MX6SL_PAD_UART1_RXD = 166,
+	MX6SL_PAD_UART1_TXD = 167,
+	MX6SL_PAD_WDOG_B = 168,
+};
+
+/* Pad names for the pinmux subsystem */
+static const struct pinctrl_pin_desc imx6sl_pinctrl_pads[] = {
+	IMX_PINCTRL_PIN(MX6SL_PAD_AUD_MCLK),
+	IMX_PINCTRL_PIN(MX6SL_PAD_AUD_RXC),
+	IMX_PINCTRL_PIN(MX6SL_PAD_AUD_RXD),
+	IMX_PINCTRL_PIN(MX6SL_PAD_AUD_RXFS),
+	IMX_PINCTRL_PIN(MX6SL_PAD_AUD_TXC),
+	IMX_PINCTRL_PIN(MX6SL_PAD_AUD_TXD),
+	IMX_PINCTRL_PIN(MX6SL_PAD_AUD_TXFS),
+	IMX_PINCTRL_PIN(MX6SL_PAD_ECSPI1_MISO),
+	IMX_PINCTRL_PIN(MX6SL_PAD_ECSPI1_MOSI),
+	IMX_PINCTRL_PIN(MX6SL_PAD_ECSPI1_SCLK),
+	IMX_PINCTRL_PIN(MX6SL_PAD_ECSPI1_SS0),
+	IMX_PINCTRL_PIN(MX6SL_PAD_ECSPI2_MISO),
+	IMX_PINCTRL_PIN(MX6SL_PAD_ECSPI2_MOSI),
+	IMX_PINCTRL_PIN(MX6SL_PAD_ECSPI2_SCLK),
+	IMX_PINCTRL_PIN(MX6SL_PAD_ECSPI2_SS0),
+	IMX_PINCTRL_PIN(MX6SL_PAD_EPDC_BDR0),
+	IMX_PINCTRL_PIN(MX6SL_PAD_EPDC_BDR1),
+	IMX_PINCTRL_PIN(MX6SL_PAD_EPDC_D0),
+	IMX_PINCTRL_PIN(MX6SL_PAD_EPDC_D1),
+	IMX_PINCTRL_PIN(MX6SL_PAD_EPDC_D10),
+	IMX_PINCTRL_PIN(MX6SL_PAD_EPDC_D11),
+	IMX_PINCTRL_PIN(MX6SL_PAD_EPDC_D12),
+	IMX_PINCTRL_PIN(MX6SL_PAD_EPDC_D13),
+	IMX_PINCTRL_PIN(MX6SL_PAD_EPDC_D14),
+	IMX_PINCTRL_PIN(MX6SL_PAD_EPDC_D15),
+	IMX_PINCTRL_PIN(MX6SL_PAD_EPDC_D2),
+	IMX_PINCTRL_PIN(MX6SL_PAD_EPDC_D3),
+	IMX_PINCTRL_PIN(MX6SL_PAD_EPDC_D4),
+	IMX_PINCTRL_PIN(MX6SL_PAD_EPDC_D5),
+	IMX_PINCTRL_PIN(MX6SL_PAD_EPDC_D6),
+	IMX_PINCTRL_PIN(MX6SL_PAD_EPDC_D7),
+	IMX_PINCTRL_PIN(MX6SL_PAD_EPDC_D8),
+	IMX_PINCTRL_PIN(MX6SL_PAD_EPDC_D9),
+	IMX_PINCTRL_PIN(MX6SL_PAD_EPDC_GDCLK),
+	IMX_PINCTRL_PIN(MX6SL_PAD_EPDC_GDOE),
+	IMX_PINCTRL_PIN(MX6SL_PAD_EPDC_GDRL),
+	IMX_PINCTRL_PIN(MX6SL_PAD_EPDC_GDSP),
+	IMX_PINCTRL_PIN(MX6SL_PAD_EPDC_PWRCOM),
+	IMX_PINCTRL_PIN(MX6SL_PAD_EPDC_PWRCTRL0),
+	IMX_PINCTRL_PIN(MX6SL_PAD_EPDC_PWRCTRL1),
+	IMX_PINCTRL_PIN(MX6SL_PAD_EPDC_PWRCTRL2),
+	IMX_PINCTRL_PIN(MX6SL_PAD_EPDC_PWRCTRL3),
+	IMX_PINCTRL_PIN(MX6SL_PAD_EPDC_PWRINT),
+	IMX_PINCTRL_PIN(MX6SL_PAD_EPDC_PWRSTAT),
+	IMX_PINCTRL_PIN(MX6SL_PAD_EPDC_PWRWAKEUP),
+	IMX_PINCTRL_PIN(MX6SL_PAD_EPDC_SDCE0),
+	IMX_PINCTRL_PIN(MX6SL_PAD_EPDC_SDCE1),
+	IMX_PINCTRL_PIN(MX6SL_PAD_EPDC_SDCE2),
+	IMX_PINCTRL_PIN(MX6SL_PAD_EPDC_SDCE3),
+	IMX_PINCTRL_PIN(MX6SL_PAD_EPDC_SDCLK),
+	IMX_PINCTRL_PIN(MX6SL_PAD_EPDC_SDLE),
+	IMX_PINCTRL_PIN(MX6SL_PAD_EPDC_SDOE),
+	IMX_PINCTRL_PIN(MX6SL_PAD_EPDC_SDSHR),
+	IMX_PINCTRL_PIN(MX6SL_PAD_EPDC_VCOM0),
+	IMX_PINCTRL_PIN(MX6SL_PAD_EPDC_VCOM1),
+	IMX_PINCTRL_PIN(MX6SL_PAD_FEC_CRS_DV),
+	IMX_PINCTRL_PIN(MX6SL_PAD_FEC_MDC),
+	IMX_PINCTRL_PIN(MX6SL_PAD_FEC_MDIO),
+	IMX_PINCTRL_PIN(MX6SL_PAD_FEC_REF_CLK),
+	IMX_PINCTRL_PIN(MX6SL_PAD_FEC_RX_ER),
+	IMX_PINCTRL_PIN(MX6SL_PAD_FEC_RXD0),
+	IMX_PINCTRL_PIN(MX6SL_PAD_FEC_RXD1),
+	IMX_PINCTRL_PIN(MX6SL_PAD_FEC_TX_CLK),
+	IMX_PINCTRL_PIN(MX6SL_PAD_FEC_TX_EN),
+	IMX_PINCTRL_PIN(MX6SL_PAD_FEC_TXD0),
+	IMX_PINCTRL_PIN(MX6SL_PAD_FEC_TXD1),
+	IMX_PINCTRL_PIN(MX6SL_PAD_HSIC_DAT),
+	IMX_PINCTRL_PIN(MX6SL_PAD_HSIC_STROBE),
+	IMX_PINCTRL_PIN(MX6SL_PAD_I2C1_SCL),
+	IMX_PINCTRL_PIN(MX6SL_PAD_I2C1_SDA),
+	IMX_PINCTRL_PIN(MX6SL_PAD_I2C2_SCL),
+	IMX_PINCTRL_PIN(MX6SL_PAD_I2C2_SDA),
+	IMX_PINCTRL_PIN(MX6SL_PAD_KEY_COL0),
+	IMX_PINCTRL_PIN(MX6SL_PAD_KEY_COL1),
+	IMX_PINCTRL_PIN(MX6SL_PAD_KEY_COL2),
+	IMX_PINCTRL_PIN(MX6SL_PAD_KEY_COL3),
+	IMX_PINCTRL_PIN(MX6SL_PAD_KEY_COL4),
+	IMX_PINCTRL_PIN(MX6SL_PAD_KEY_COL5),
+	IMX_PINCTRL_PIN(MX6SL_PAD_KEY_COL6),
+	IMX_PINCTRL_PIN(MX6SL_PAD_KEY_COL7),
+	IMX_PINCTRL_PIN(MX6SL_PAD_KEY_ROW0),
+	IMX_PINCTRL_PIN(MX6SL_PAD_KEY_ROW1),
+	IMX_PINCTRL_PIN(MX6SL_PAD_KEY_ROW2),
+	IMX_PINCTRL_PIN(MX6SL_PAD_KEY_ROW3),
+	IMX_PINCTRL_PIN(MX6SL_PAD_KEY_ROW4),
+	IMX_PINCTRL_PIN(MX6SL_PAD_KEY_ROW5),
+	IMX_PINCTRL_PIN(MX6SL_PAD_KEY_ROW6),
+	IMX_PINCTRL_PIN(MX6SL_PAD_KEY_ROW7),
+	IMX_PINCTRL_PIN(MX6SL_PAD_LCD_CLK),
+	IMX_PINCTRL_PIN(MX6SL_PAD_LCD_DAT0),
+	IMX_PINCTRL_PIN(MX6SL_PAD_LCD_DAT1),
+	IMX_PINCTRL_PIN(MX6SL_PAD_LCD_DAT10),
+	IMX_PINCTRL_PIN(MX6SL_PAD_LCD_DAT11),
+	IMX_PINCTRL_PIN(MX6SL_PAD_LCD_DAT12),
+	IMX_PINCTRL_PIN(MX6SL_PAD_LCD_DAT13),
+	IMX_PINCTRL_PIN(MX6SL_PAD_LCD_DAT14),
+	IMX_PINCTRL_PIN(MX6SL_PAD_LCD_DAT15),
+	IMX_PINCTRL_PIN(MX6SL_PAD_LCD_DAT16),
+	IMX_PINCTRL_PIN(MX6SL_PAD_LCD_DAT17),
+	IMX_PINCTRL_PIN(MX6SL_PAD_LCD_DAT18),
+	IMX_PINCTRL_PIN(MX6SL_PAD_LCD_DAT19),
+	IMX_PINCTRL_PIN(MX6SL_PAD_LCD_DAT2),
+	IMX_PINCTRL_PIN(MX6SL_PAD_LCD_DAT20),
+	IMX_PINCTRL_PIN(MX6SL_PAD_LCD_DAT21),
+	IMX_PINCTRL_PIN(MX6SL_PAD_LCD_DAT22),
+	IMX_PINCTRL_PIN(MX6SL_PAD_LCD_DAT23),
+	IMX_PINCTRL_PIN(MX6SL_PAD_LCD_DAT3),
+	IMX_PINCTRL_PIN(MX6SL_PAD_LCD_DAT4),
+	IMX_PINCTRL_PIN(MX6SL_PAD_LCD_DAT5),
+	IMX_PINCTRL_PIN(MX6SL_PAD_LCD_DAT6),
+	IMX_PINCTRL_PIN(MX6SL_PAD_LCD_DAT7),
+	IMX_PINCTRL_PIN(MX6SL_PAD_LCD_DAT8),
+	IMX_PINCTRL_PIN(MX6SL_PAD_LCD_DAT9),
+	IMX_PINCTRL_PIN(MX6SL_PAD_LCD_ENABLE),
+	IMX_PINCTRL_PIN(MX6SL_PAD_LCD_HSYNC),
+	IMX_PINCTRL_PIN(MX6SL_PAD_LCD_RESET),
+	IMX_PINCTRL_PIN(MX6SL_PAD_LCD_VSYNC),
+	IMX_PINCTRL_PIN(MX6SL_PAD_PWM1),
+	IMX_PINCTRL_PIN(MX6SL_PAD_REF_CLK_24M),
+	IMX_PINCTRL_PIN(MX6SL_PAD_REF_CLK_32K),
+	IMX_PINCTRL_PIN(MX6SL_PAD_SD1_CLK),
+	IMX_PINCTRL_PIN(MX6SL_PAD_SD1_CMD),
+	IMX_PINCTRL_PIN(MX6SL_PAD_SD1_DAT0),
+	IMX_PINCTRL_PIN(MX6SL_PAD_SD1_DAT1),
+	IMX_PINCTRL_PIN(MX6SL_PAD_SD1_DAT2),
+	IMX_PINCTRL_PIN(MX6SL_PAD_SD1_DAT3),
+	IMX_PINCTRL_PIN(MX6SL_PAD_SD1_DAT4),
+	IMX_PINCTRL_PIN(MX6SL_PAD_SD1_DAT5),
+	IMX_PINCTRL_PIN(MX6SL_PAD_SD1_DAT6),
+	IMX_PINCTRL_PIN(MX6SL_PAD_SD1_DAT7),
+	IMX_PINCTRL_PIN(MX6SL_PAD_SD2_CLK),
+	IMX_PINCTRL_PIN(MX6SL_PAD_SD2_CMD),
+	IMX_PINCTRL_PIN(MX6SL_PAD_SD2_DAT0),
+	IMX_PINCTRL_PIN(MX6SL_PAD_SD2_DAT1),
+	IMX_PINCTRL_PIN(MX6SL_PAD_SD2_DAT2),
+	IMX_PINCTRL_PIN(MX6SL_PAD_SD2_DAT3),
+	IMX_PINCTRL_PIN(MX6SL_PAD_SD2_DAT4),
+	IMX_PINCTRL_PIN(MX6SL_PAD_SD2_DAT5),
+	IMX_PINCTRL_PIN(MX6SL_PAD_SD2_DAT6),
+	IMX_PINCTRL_PIN(MX6SL_PAD_SD2_DAT7),
+	IMX_PINCTRL_PIN(MX6SL_PAD_SD2_RST),
+	IMX_PINCTRL_PIN(MX6SL_PAD_SD3_CLK),
+	IMX_PINCTRL_PIN(MX6SL_PAD_SD3_CMD),
+	IMX_PINCTRL_PIN(MX6SL_PAD_SD3_DAT0),
+	IMX_PINCTRL_PIN(MX6SL_PAD_SD3_DAT1),
+	IMX_PINCTRL_PIN(MX6SL_PAD_SD3_DAT2),
+	IMX_PINCTRL_PIN(MX6SL_PAD_SD3_DAT3),
+	IMX_PINCTRL_PIN(MX6SL_PAD_UART1_RXD),
+	IMX_PINCTRL_PIN(MX6SL_PAD_UART1_TXD),
+	IMX_PINCTRL_PIN(MX6SL_PAD_WDOG_B),
+};
+
+static struct imx_pinctrl_soc_info imx6sl_pinctrl_info = {
+	.pins = imx6sl_pinctrl_pads,
+	.npins = ARRAY_SIZE(imx6sl_pinctrl_pads),
+};
+
+static struct of_device_id imx6sl_pinctrl_of_match[] = {
+	{ .compatible = "fsl,imx6sl-iomuxc", },
+	{ /* sentinel */ }
+};
+
+static int imx6sl_pinctrl_probe(struct platform_device *pdev)
+{
+	return imx_pinctrl_probe(pdev, &imx6sl_pinctrl_info);
+}
+
+static struct platform_driver imx6sl_pinctrl_driver = {
+	.driver = {
+		.name = "imx6sl-pinctrl",
+		.owner = THIS_MODULE,
+		.of_match_table = of_match_ptr(imx6sl_pinctrl_of_match),
+	},
+	.probe = imx6sl_pinctrl_probe,
+	.remove = imx_pinctrl_remove,
+};
+
+static int __init imx6sl_pinctrl_init(void)
+{
+	return platform_driver_register(&imx6sl_pinctrl_driver);
+}
+arch_initcall(imx6sl_pinctrl_init);
+
+static void __exit imx6sl_pinctrl_exit(void)
+{
+	platform_driver_unregister(&imx6sl_pinctrl_driver);
+}
+module_exit(imx6sl_pinctrl_exit);
+
+MODULE_AUTHOR("Shawn Guo <shawn.guo at linaro.org>");
+MODULE_DESCRIPTION("Freescale imx6sl pinctrl driver");
+MODULE_LICENSE("GPL v2");
-- 
1.7.9.5




From shawn.guo at linaro.org  Tue Apr  2 10:31:13 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 2 Apr 2013 22:31:13 +0800
Subject: [PATCH 0/6] Add initial imx6dl support
Message-ID: <1364913079-26039-1-git-send-email-shawn.guo@linaro.org>

The i.MX6 DualLite/Solo (imx6dl) is a derivative of i.MX6 Quad/Dual
(imx6q).  These two chips are highly compatible.  The series adds the
initial imx6dl support based on imx6q base.

Linus,

The first two patches has dependency on patch "pinctrl: imx: move
hard-coding data into device tree", which is sitting on IMX tree.  So
can you please give your ACK for me to take them through the same tree?

Thanks,
Shawn

Shawn Guo (6):
  pinctrl: add pinctrl driver for imx6dl
  pinctrl: add pinctrl driver for imx6sl
  ARM: imx: add initial imx6dl support
  ARM: dts: imx: make sabreauto and sabresd common
  ARM: dts: imx: add initial imx6dl-sabresd support
  ARM: dts: imx: add initial imx6dl-sabreauto support

 .../bindings/pinctrl/fsl,imx6dl-pinctrl.txt        |   38 +
 .../bindings/pinctrl/fsl,imx6sl-pinctrl.txt        |   39 +
 arch/arm/Kconfig.debug                             |    4 +-
 arch/arm/boot/dts/Makefile                         |    2 +
 arch/arm/boot/dts/imx6dl-pinfunc.h                 | 1085 ++++++++++++++++++++
 arch/arm/boot/dts/imx6dl-sabreauto.dtsp            |   31 +
 arch/arm/boot/dts/imx6dl-sabresd.dtsp              |   35 +
 arch/arm/boot/dts/imx6dl.dtsip                     |  114 +-
 arch/arm/boot/dts/imx6q-sabreauto.dtsp             |   27 +-
 arch/arm/boot/dts/imx6q-sabresd.dtsp               |   78 +-
 arch/arm/boot/dts/imx6qdl-sabreauto.dtsip          |   38 +
 arch/arm/boot/dts/imx6qdl-sabresd.dtsip            |   87 ++
 arch/arm/boot/dts/imx6sl-pinfunc.h                 | 1077 +++++++++++++++++++
 arch/arm/mach-imx/Kconfig                          |    2 +-
 arch/arm/mach-imx/clk-imx6q.c                      |    2 +-
 arch/arm/mach-imx/mach-imx6q.c                     |   30 +-
 arch/arm/mach-imx/mxc.h                            |   11 +
 drivers/pinctrl/Kconfig                            |   12 +-
 drivers/pinctrl/Makefile                           |    1 +
 drivers/pinctrl/pinctrl-imx6dl.c                   |  459 +++++++++
 drivers/pinctrl/pinctrl-imx6sl.c                   |  365 +++++++
 21 files changed, 3421 insertions(+), 116 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/pinctrl/fsl,imx6dl-pinctrl.txt
 create mode 100644 Documentation/devicetree/bindings/pinctrl/fsl,imx6sl-pinctrl.txt
 create mode 100644 arch/arm/boot/dts/imx6dl-pinfunc.h
 create mode 100644 arch/arm/boot/dts/imx6dl-sabreauto.dtsp
 create mode 100644 arch/arm/boot/dts/imx6dl-sabresd.dtsp
 create mode 100644 arch/arm/boot/dts/imx6qdl-sabreauto.dtsip
 create mode 100644 arch/arm/boot/dts/imx6qdl-sabresd.dtsip
 create mode 100644 arch/arm/boot/dts/imx6sl-pinfunc.h
 create mode 100644 drivers/pinctrl/pinctrl-imx6dl.c
 create mode 100644 drivers/pinctrl/pinctrl-imx6sl.c

-- 
1.7.9.5




From shawn.guo at linaro.org  Tue Apr  2 10:31:17 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 2 Apr 2013 22:31:17 +0800
Subject: [PATCH 4/6] ARM: dts: imx: make sabreauto and sabresd common
In-Reply-To: <1364913079-26039-1-git-send-email-shawn.guo@linaro.org>
References: <1364913079-26039-1-git-send-email-shawn.guo@linaro.org>
Message-ID: <1364913079-26039-5-git-send-email-shawn.guo@linaro.org>

The sabreauto and sabresd boards are common for imx6q and imx6dl.
Create imx6qdl-sabreauto.dtsip and imx6qdl-sabresd.dtsip for those
common parts.

Signed-off-by: Shawn Guo <shawn.guo at linaro.org>
---
 arch/arm/boot/dts/imx6q-sabreauto.dtsp    |   27 +--------
 arch/arm/boot/dts/imx6q-sabresd.dtsp      |   78 +-------------------------
 arch/arm/boot/dts/imx6qdl-sabreauto.dtsip |   38 +++++++++++++
 arch/arm/boot/dts/imx6qdl-sabresd.dtsip   |   87 +++++++++++++++++++++++++++++
 4 files changed, 130 insertions(+), 100 deletions(-)
 create mode 100644 arch/arm/boot/dts/imx6qdl-sabreauto.dtsip
 create mode 100644 arch/arm/boot/dts/imx6qdl-sabresd.dtsip

diff --git a/arch/arm/boot/dts/imx6q-sabreauto.dtsp b/arch/arm/boot/dts/imx6q-sabreauto.dtsp
index 23c602a..99ba364 100644
--- a/arch/arm/boot/dts/imx6q-sabreauto.dtsp
+++ b/arch/arm/boot/dts/imx6q-sabreauto.dtsp
@@ -11,15 +11,13 @@
  */
 
 /dts-v1/;
+
 #include "imx6q.dtsip"
+#include "imx6qdl-sabreauto.dtsip"
 
 / {
 	model = "Freescale i.MX6 Quad SABRE Automotive Board";
 	compatible = "fsl,imx6q-sabreauto", "fsl,imx6q";
-
-	memory {
-		reg = <0x10000000 0x80000000>;
-	};
 };
 
 &iomuxc {
@@ -35,24 +33,3 @@
 		};
 	};
 };
-
-&uart4 {
-	pinctrl-names = "default";
-	pinctrl-0 = <&pinctrl_uart4_1>;
-	status = "okay";
-};
-
-&fec {
-	pinctrl-names = "default";
-	pinctrl-0 = <&pinctrl_enet_2>;
-	phy-mode = "rgmii";
-	status = "okay";
-};
-
-&usdhc3 {
-	pinctrl-names = "default";
-	pinctrl-0 = <&pinctrl_usdhc3_1>;
-	cd-gpios = <&gpio6 15 0>;
-	wp-gpios = <&gpio1 13 0>;
-	status = "okay";
-};
diff --git a/arch/arm/boot/dts/imx6q-sabresd.dtsp b/arch/arm/boot/dts/imx6q-sabresd.dtsp
index 5534a6f..05f6fbd 100644
--- a/arch/arm/boot/dts/imx6q-sabresd.dtsp
+++ b/arch/arm/boot/dts/imx6q-sabresd.dtsp
@@ -11,50 +11,13 @@
  */
 
 /dts-v1/;
+
 #include "imx6q.dtsip"
+#include "imx6qdl-sabresd.dtsip"
 
 / {
-	model = "Freescale i.MX6Q SABRE Smart Device Board";
+	model = "Freescale i.MX6 Quad SABRE Smart Device Board";
 	compatible = "fsl,imx6q-sabresd", "fsl,imx6q";
-
-	memory {
-		reg = <0x10000000 0x40000000>;
-	};
-
-	regulators {
-		compatible = "simple-bus";
-
-		reg_usb_otg_vbus: usb_otg_vbus {
-			compatible = "regulator-fixed";
-			regulator-name = "usb_otg_vbus";
-			regulator-min-microvolt = <5000000>;
-			regulator-max-microvolt = <5000000>;
-			gpio = <&gpio3 22 0>;
-			enable-active-high;
-		};
-	};
-
-	gpio-keys {
-		compatible = "gpio-keys";
-
-		volume-up {
-			label = "Volume Up";
-			gpios = <&gpio1 4 0>;
-			linux,code = <115>; /* KEY_VOLUMEUP */
-		};
-
-		volume-down {
-			label = "Volume Down";
-			gpios = <&gpio1 5 0>;
-			linux,code = <114>; /* KEY_VOLUMEDOWN */
-		};
-	};
-};
-
-&uart1 {
-	pinctrl-names = "default";
-	pinctrl-0 = <&pinctrl_uart1_1>;
-	status = "okay";
 };
 
 &iomuxc {
@@ -74,38 +37,3 @@
 		};
 	};
 };
-
-&usbotg {
-	vbus-supply = <&reg_usb_otg_vbus>;
-	pinctrl-names = "default";
-	pinctrl-0 = <&pinctrl_usbotg_2>;
-	disable-over-current;
-	status = "okay";
-};
-
-&usbh1 {
-	status = "okay";
-};
-
-&fec {
-	pinctrl-names = "default";
-	pinctrl-0 = <&pinctrl_enet_1>;
-	phy-mode = "rgmii";
-	status = "okay";
-};
-
-&usdhc2 {
-	pinctrl-names = "default";
-	pinctrl-0 = <&pinctrl_usdhc2_1>;
-	cd-gpios = <&gpio2 2 0>;
-	wp-gpios = <&gpio2 3 0>;
-	status = "okay";
-};
-
-&usdhc3 {
-	pinctrl-names = "default";
-	pinctrl-0 = <&pinctrl_usdhc3_1>;
-	cd-gpios = <&gpio2 0 0>;
-	wp-gpios = <&gpio2 1 0>;
-	status = "okay";
-};
diff --git a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsip b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsip
new file mode 100644
index 0000000..4d237cf
--- /dev/null
+++ b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsip
@@ -0,0 +1,38 @@
+/*
+ * Copyright 2012 Freescale Semiconductor, Inc.
+ * Copyright 2011 Linaro Ltd.
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+/ {
+	memory {
+		reg = <0x10000000 0x80000000>;
+	};
+};
+
+&fec {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_enet_2>;
+	phy-mode = "rgmii";
+	status = "okay";
+};
+
+&uart4 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_uart4_1>;
+	status = "okay";
+};
+
+&usdhc3 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_usdhc3_1>;
+	cd-gpios = <&gpio6 15 0>;
+	wp-gpios = <&gpio1 13 0>;
+	status = "okay";
+};
diff --git a/arch/arm/boot/dts/imx6qdl-sabresd.dtsip b/arch/arm/boot/dts/imx6qdl-sabresd.dtsip
new file mode 100644
index 0000000..e21f6a8
--- /dev/null
+++ b/arch/arm/boot/dts/imx6qdl-sabresd.dtsip
@@ -0,0 +1,87 @@
+/*
+ * Copyright 2012 Freescale Semiconductor, Inc.
+ * Copyright 2011 Linaro Ltd.
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+/ {
+	memory {
+		reg = <0x10000000 0x40000000>;
+	};
+
+	regulators {
+		compatible = "simple-bus";
+
+		reg_usb_otg_vbus: usb_otg_vbus {
+			compatible = "regulator-fixed";
+			regulator-name = "usb_otg_vbus";
+			regulator-min-microvolt = <5000000>;
+			regulator-max-microvolt = <5000000>;
+			gpio = <&gpio3 22 0>;
+			enable-active-high;
+		};
+	};
+
+	gpio-keys {
+		compatible = "gpio-keys";
+
+		volume-up {
+			label = "Volume Up";
+			gpios = <&gpio1 4 0>;
+			linux,code = <115>; /* KEY_VOLUMEUP */
+		};
+
+		volume-down {
+			label = "Volume Down";
+			gpios = <&gpio1 5 0>;
+			linux,code = <114>; /* KEY_VOLUMEDOWN */
+		};
+	};
+};
+
+&fec {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_enet_1>;
+	phy-mode = "rgmii";
+	status = "okay";
+};
+
+&uart1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_uart1_1>;
+	status = "okay";
+};
+
+&usbh1 {
+	status = "okay";
+};
+
+&usbotg {
+	vbus-supply = <&reg_usb_otg_vbus>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_usbotg_2>;
+	disable-over-current;
+	status = "okay";
+};
+
+&usdhc2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_usdhc2_1>;
+	cd-gpios = <&gpio2 2 0>;
+	wp-gpios = <&gpio2 3 0>;
+	status = "okay";
+};
+
+&usdhc3 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_usdhc3_1>;
+	cd-gpios = <&gpio2 0 0>;
+	wp-gpios = <&gpio2 1 0>;
+	status = "okay";
+};
-- 
1.7.9.5




From shawn.guo at linaro.org  Tue Apr  2 10:31:19 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 2 Apr 2013 22:31:19 +0800
Subject: [PATCH 6/6] ARM: dts: imx: add initial imx6dl-sabreauto support
In-Reply-To: <1364913079-26039-1-git-send-email-shawn.guo@linaro.org>
References: <1364913079-26039-1-git-send-email-shawn.guo@linaro.org>
Message-ID: <1364913079-26039-7-git-send-email-shawn.guo@linaro.org>

Add initial imx6dl-sabreauto support based on the common stuff already
in imx6qdl-sabreauto.dtsip.

Signed-off-by: Shawn Guo <shawn.guo at linaro.org>
---
 arch/arm/boot/dts/Makefile              |    1 +
 arch/arm/boot/dts/imx6dl-sabreauto.dtsp |   31 +++++++++++++++++++++++++++++++
 arch/arm/boot/dts/imx6dl.dtsip          |   29 +++++++++++++++++++++++++++++
 3 files changed, 61 insertions(+)
 create mode 100644 arch/arm/boot/dts/imx6dl-sabreauto.dtsp

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 38d19b0..5345ac1 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -98,6 +98,7 @@ dtb-$(CONFIG_ARCH_MXC) += \
 	imx53-mba53.dtb \
 	imx53-qsb.dtb \
 	imx53-smd.dtb \
+	imx6dl-sabreauto.dtb \
 	imx6dl-sabresd.dtb \
 	imx6q-arm2.dtb \
 	imx6q-sabreauto.dtb \
diff --git a/arch/arm/boot/dts/imx6dl-sabreauto.dtsp b/arch/arm/boot/dts/imx6dl-sabreauto.dtsp
new file mode 100644
index 0000000..53033be
--- /dev/null
+++ b/arch/arm/boot/dts/imx6dl-sabreauto.dtsp
@@ -0,0 +1,31 @@
+/*
+ * Copyright (C) 2013 Freescale Semiconductor, Inc.
+ *
+ * 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.
+ */
+
+/dts-v1/;
+
+#include "imx6dl.dtsip"
+#include "imx6qdl-sabreauto.dtsip"
+
+/ {
+	model = "Freescale i.MX6 DualLite/Solo SABRE Automotive Board";
+	compatible = "fsl,imx6dl-sabreauto", "fsl,imx6dl";
+};
+
+&iomuxc {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_hog>;
+
+	hog {
+		pinctrl_hog: hoggrp {
+			fsl,pins = <
+				MX6DL_PAD_NANDF_CS2__GPIO6_IO15 0x80000000
+				MX6DL_PAD_SD2_DAT2__GPIO1_IO13  0x80000000
+			>;
+		};
+	};
+};
diff --git a/arch/arm/boot/dts/imx6dl.dtsip b/arch/arm/boot/dts/imx6dl.dtsip
index b9112677..951ba53 100644
--- a/arch/arm/boot/dts/imx6dl.dtsip
+++ b/arch/arm/boot/dts/imx6dl.dtsip
@@ -56,6 +56,26 @@
 							MX6DL_PAD_GPIO_16__ENET_REF_CLK      0x4001b0a8
 						>;
 					};
+
+					pinctrl_enet_2: enetgrp-2 {
+						fsl,pins = <
+							MX6DL_PAD_KEY_COL1__ENET_MDIO        0x1b0b0
+							MX6DL_PAD_KEY_COL2__ENET_MDC         0x1b0b0
+							MX6DL_PAD_RGMII_TXC__RGMII_TXC       0x1b0b0
+							MX6DL_PAD_RGMII_TD0__RGMII_TD0       0x1b0b0
+							MX6DL_PAD_RGMII_TD1__RGMII_TD1       0x1b0b0
+							MX6DL_PAD_RGMII_TD2__RGMII_TD2       0x1b0b0
+							MX6DL_PAD_RGMII_TD3__RGMII_TD3       0x1b0b0
+							MX6DL_PAD_RGMII_TX_CTL__RGMII_TX_CTL 0x1b0b0
+							MX6DL_PAD_ENET_REF_CLK__ENET_TX_CLK  0x1b0b0
+							MX6DL_PAD_RGMII_RXC__RGMII_RXC       0x1b0b0
+							MX6DL_PAD_RGMII_RD0__RGMII_RD0       0x1b0b0
+							MX6DL_PAD_RGMII_RD1__RGMII_RD1       0x1b0b0
+							MX6DL_PAD_RGMII_RD2__RGMII_RD2       0x1b0b0
+							MX6DL_PAD_RGMII_RD3__RGMII_RD3       0x1b0b0
+							MX6DL_PAD_RGMII_RX_CTL__RGMII_RX_CTL 0x1b0b0
+						>;
+					};
 				};
 
 				uart1 {
@@ -67,6 +87,15 @@
 					};
 				};
 
+				uart4 {
+					pinctrl_uart4_1: uart4grp-1 {
+						fsl,pins = <
+							MX6DL_PAD_KEY_COL0__UART4_TX_DATA 0x1b0b1
+							MX6DL_PAD_KEY_ROW0__UART4_RX_DATA 0x1b0b1
+						>;
+					};
+				};
+
 				usbotg {
 					pinctrl_usbotg_2: usbotggrp-2 {
 						fsl,pins = <
-- 
1.7.9.5




From shawn.guo at linaro.org  Tue Apr  2 10:31:16 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 2 Apr 2013 22:31:16 +0800
Subject: [PATCH 3/6] ARM: imx: add initial imx6dl support
In-Reply-To: <1364913079-26039-1-git-send-email-shawn.guo@linaro.org>
References: <1364913079-26039-1-git-send-email-shawn.guo@linaro.org>
Message-ID: <1364913079-26039-4-git-send-email-shawn.guo@linaro.org>

The i.MX6 DualLite/Solo is another i.MX6 family SoC, which is highly
compatible with i.MX6 Quad/Dual.  And that's why we choose to support
it using imx6q code with cpu_is_imx6dl() check when necessary.

Signed-off-by: Shawn Guo <shawn.guo at linaro.org>
---
 arch/arm/Kconfig.debug         |    4 ++--
 arch/arm/mach-imx/Kconfig      |    2 +-
 arch/arm/mach-imx/clk-imx6q.c  |    2 +-
 arch/arm/mach-imx/mach-imx6q.c |   30 +++++++++++++++++++++---------
 arch/arm/mach-imx/mxc.h        |   11 +++++++++++
 5 files changed, 36 insertions(+), 13 deletions(-)

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 9b31f43..7e911fd 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -234,11 +234,11 @@ choice
 		  on i.MX53.
 
 	config DEBUG_IMX6Q_UART
-		bool "i.MX6Q Debug UART"
+		bool "i.MX6Q/DL Debug UART"
 		depends on SOC_IMX6Q
 		help
 		  Say Y here if you want kernel low-level debugging support
-		  on i.MX6Q.
+		  on i.MX6Q/DL.
 
 	config DEBUG_MMP_UART2
 		bool "Kernel low-level debugging message via MMP UART2"
diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index ca24f2c..355d55c 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -810,7 +810,7 @@ config	SOC_IMX53
 	  This enables support for Freescale i.MX53 processor.
 
 config SOC_IMX6Q
-	bool "i.MX6 Quad support"
+	bool "i.MX6 Quad/DualLite support"
 	select ARCH_HAS_CPUFREQ
 	select ARCH_HAS_OPP
 	select ARM_CPU_SUSPEND if PM
diff --git a/arch/arm/mach-imx/clk-imx6q.c b/arch/arm/mach-imx/clk-imx6q.c
index 92b2aa5..65319d5 100644
--- a/arch/arm/mach-imx/clk-imx6q.c
+++ b/arch/arm/mach-imx/clk-imx6q.c
@@ -296,7 +296,7 @@ int __init mx6q_clocks_init(void)
 	WARN_ON(!base);
 
 	/* Audio/video PLL post dividers do not work on i.MX6q revision 1.0 */
-	if (imx6q_revision() == IMX_CHIP_REVISION_1_0) {
+	if (cpu_is_imx6q() && imx6q_revision() == IMX_CHIP_REVISION_1_0) {
 		post_div_table[1].div = 1;
 		post_div_table[2].div = 1;
 		video_div_table[1].div = 1;
diff --git a/arch/arm/mach-imx/mach-imx6q.c b/arch/arm/mach-imx/mach-imx6q.c
index 221f319..8aa9d90 100644
--- a/arch/arm/mach-imx/mach-imx6q.c
+++ b/arch/arm/mach-imx/mach-imx6q.c
@@ -39,23 +39,32 @@
 #include "cpuidle.h"
 #include "hardware.h"
 
+static u32 chip_revision;
+
 int imx6q_revision(void)
 {
-	static u32 rev;
+	return chip_revision;
+}
 
-	if (!rev)
-		rev = imx_anatop_get_digprog();
+static void __init imx6q_init_revision(void)
+{
+	u32 rev = imx_anatop_get_digprog();
 
 	switch (rev & 0xff) {
 	case 0:
-		return IMX_CHIP_REVISION_1_0;
+		chip_revision = IMX_CHIP_REVISION_1_0;
+		break;
 	case 1:
-		return IMX_CHIP_REVISION_1_1;
+		chip_revision = IMX_CHIP_REVISION_1_1;
+		break;
 	case 2:
-		return IMX_CHIP_REVISION_1_2;
+		chip_revision = IMX_CHIP_REVISION_1_2;
+		break;
 	default:
-		return IMX_CHIP_REVISION_UNKNOWN;
+		chip_revision = IMX_CHIP_REVISION_UNKNOWN;
 	}
+
+	mxc_set_cpu_type(rev >> 16 & 0xff);
 }
 
 void imx6q_restart(char mode, const char *cmd)
@@ -247,6 +256,7 @@ static void __init imx6q_map_io(void)
 
 static void __init imx6q_init_irq(void)
 {
+	imx6q_init_revision();
 	l2x0_of_init(0, ~0UL);
 	imx_src_init();
 	imx_gpc_init();
@@ -257,15 +267,17 @@ static void __init imx6q_timer_init(void)
 {
 	mx6q_clocks_init();
 	twd_local_timer_of_register();
-	imx_print_silicon_rev("i.MX6Q", imx6q_revision());
+	imx_print_silicon_rev(cpu_is_imx6dl() ? "i.MX6DL" : "i.MX6Q",
+			      imx6q_revision());
 }
 
 static const char *imx6q_dt_compat[] __initdata = {
+	"fsl,imx6dl",
 	"fsl,imx6q",
 	NULL,
 };
 
-DT_MACHINE_START(IMX6Q, "Freescale i.MX6 Quad (Device Tree)")
+DT_MACHINE_START(IMX6Q, "Freescale i.MX6 Quad/DualLite (Device Tree)")
 	.smp		= smp_ops(imx_smp_ops),
 	.map_io		= imx6q_map_io,
 	.init_irq	= imx6q_init_irq,
diff --git a/arch/arm/mach-imx/mxc.h b/arch/arm/mach-imx/mxc.h
index 7dce17a..8629e5b 100644
--- a/arch/arm/mach-imx/mxc.h
+++ b/arch/arm/mach-imx/mxc.h
@@ -34,6 +34,8 @@
 #define MXC_CPU_MX35		35
 #define MXC_CPU_MX51		51
 #define MXC_CPU_MX53		53
+#define MXC_CPU_IMX6DL		0x61
+#define MXC_CPU_IMX6Q		0x63
 
 #define IMX_CHIP_REVISION_1_0		0x10
 #define IMX_CHIP_REVISION_1_1		0x11
@@ -150,6 +152,15 @@ extern unsigned int __mxc_cpu_type;
 #endif
 
 #ifndef __ASSEMBLY__
+static inline bool cpu_is_imx6dl(void)
+{
+	return __mxc_cpu_type == MXC_CPU_IMX6DL;
+}
+
+static inline bool cpu_is_imx6q(void)
+{
+	return __mxc_cpu_type == MXC_CPU_IMX6Q;
+}
 
 struct cpu_op {
 	u32 cpu_rate;
-- 
1.7.9.5




From shawn.guo at linaro.org  Tue Apr  2 10:31:18 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 2 Apr 2013 22:31:18 +0800
Subject: [PATCH 5/6] ARM: dts: imx: add initial imx6dl-sabresd support
In-Reply-To: <1364913079-26039-1-git-send-email-shawn.guo@linaro.org>
References: <1364913079-26039-1-git-send-email-shawn.guo@linaro.org>
Message-ID: <1364913079-26039-6-git-send-email-shawn.guo@linaro.org>

Add initial imx6dl-sabresd support based on the common stuff already in
imx6qdl-sabresd.dtsip.

Signed-off-by: Shawn Guo <shawn.guo at linaro.org>
---
 arch/arm/boot/dts/Makefile            |    1 +
 arch/arm/boot/dts/imx6dl-sabresd.dtsp |   35 ++++++++++++++
 arch/arm/boot/dts/imx6dl.dtsip        |   85 ++++++++++++++++++++++++++++++++-
 3 files changed, 120 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/imx6dl-sabresd.dtsp

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 0254495..38d19b0 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -98,6 +98,7 @@ dtb-$(CONFIG_ARCH_MXC) += \
 	imx53-mba53.dtb \
 	imx53-qsb.dtb \
 	imx53-smd.dtb \
+	imx6dl-sabresd.dtb \
 	imx6q-arm2.dtb \
 	imx6q-sabreauto.dtb \
 	imx6q-sabrelite.dtb \
diff --git a/arch/arm/boot/dts/imx6dl-sabresd.dtsp b/arch/arm/boot/dts/imx6dl-sabresd.dtsp
new file mode 100644
index 0000000..77ef55c
--- /dev/null
+++ b/arch/arm/boot/dts/imx6dl-sabresd.dtsp
@@ -0,0 +1,35 @@
+/*
+ * Copyright (C) 2013 Freescale Semiconductor, Inc.
+ *
+ * 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.
+ */
+
+/dts-v1/;
+
+#include "imx6dl.dtsip"
+#include "imx6qdl-sabresd.dtsip"
+
+/ {
+	model = "Freescale i.MX6 DualLite SABRE Smart Device Board";
+	compatible = "fsl,imx6dl-sabresd", "fsl,imx6dl";
+};
+
+&iomuxc {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_hog>;
+
+	hog {
+		pinctrl_hog: hoggrp {
+			fsl,pins = <
+				MX6DL_PAD_GPIO_4__GPIO1_IO04   0x80000000
+				MX6DL_PAD_GPIO_5__GPIO1_IO05   0x80000000
+				MX6DL_PAD_NANDF_D0__GPIO2_IO00 0x80000000
+				MX6DL_PAD_NANDF_D1__GPIO2_IO01 0x80000000
+				MX6DL_PAD_NANDF_D2__GPIO2_IO02 0x80000000
+				MX6DL_PAD_NANDF_D3__GPIO2_IO03 0x80000000
+			>;
+		};
+	};
+};
diff --git a/arch/arm/boot/dts/imx6dl.dtsip b/arch/arm/boot/dts/imx6dl.dtsip
index 63fafe2..b9112677 100644
--- a/arch/arm/boot/dts/imx6dl.dtsip
+++ b/arch/arm/boot/dts/imx6dl.dtsip
@@ -1,3 +1,4 @@
+
 /*
  * Copyright 2013 Freescale Semiconductor, Inc.
  *
@@ -7,7 +8,8 @@
  *
  */
 
-/include/ "imx6qdl.dtsi"
+#include "imx6qdl.dtsip"
+#include "imx6dl-pinfunc.h"
 
 / {
 	cpus {
@@ -29,6 +31,87 @@
 
 	soc {
 		aips1: aips-bus at 02000000 {
+			iomuxc: iomuxc at 020e0000 {
+				compatible = "fsl,imx6dl-iomuxc";
+				reg = <0x020e0000 0x4000>;
+
+				enet {
+					pinctrl_enet_1: enetgrp-1 {
+						fsl,pins = <
+							MX6DL_PAD_ENET_MDIO__ENET_MDIO       0x1b0b0
+							MX6DL_PAD_ENET_MDC__ENET_MDC         0x1b0b0
+							MX6DL_PAD_RGMII_TXC__RGMII_TXC       0x1b0b0
+							MX6DL_PAD_RGMII_TD0__RGMII_TD0       0x1b0b0
+							MX6DL_PAD_RGMII_TD1__RGMII_TD1       0x1b0b0
+							MX6DL_PAD_RGMII_TD2__RGMII_TD2       0x1b0b0
+							MX6DL_PAD_RGMII_TD3__RGMII_TD3       0x1b0b0
+							MX6DL_PAD_RGMII_TX_CTL__RGMII_TX_CTL 0x1b0b0
+							MX6DL_PAD_ENET_REF_CLK__ENET_TX_CLK  0x1b0b0
+							MX6DL_PAD_RGMII_RXC__RGMII_RXC       0x1b0b0
+							MX6DL_PAD_RGMII_RD0__RGMII_RD0       0x1b0b0
+							MX6DL_PAD_RGMII_RD1__RGMII_RD1       0x1b0b0
+							MX6DL_PAD_RGMII_RD2__RGMII_RD2       0x1b0b0
+							MX6DL_PAD_RGMII_RD3__RGMII_RD3       0x1b0b0
+							MX6DL_PAD_RGMII_RX_CTL__RGMII_RX_CTL 0x1b0b0
+							MX6DL_PAD_GPIO_16__ENET_REF_CLK      0x4001b0a8
+						>;
+					};
+				};
+
+				uart1 {
+					pinctrl_uart1_1: uart1grp-1 {
+						fsl,pins = <
+							MX6DL_PAD_CSI0_DAT10__UART1_TX_DATA 0x1b0b1
+							MX6DL_PAD_CSI0_DAT11__UART1_RX_DATA 0x1b0b1
+						>;
+					};
+				};
+
+				usbotg {
+					pinctrl_usbotg_2: usbotggrp-2 {
+						fsl,pins = <
+							MX6DL_PAD_ENET_RX_ER__USB_OTG_ID 0x17059
+						>;
+					};
+				};
+
+				usdhc2 {
+					pinctrl_usdhc2_1: usdhc2grp-1 {
+						fsl,pins = <
+							MX6DL_PAD_SD2_CMD__SD2_CMD    0x17059
+							MX6DL_PAD_SD2_CLK__SD2_CLK    0x10059
+							MX6DL_PAD_SD2_DAT0__SD2_DATA0 0x17059
+							MX6DL_PAD_SD2_DAT1__SD2_DATA1 0x17059
+							MX6DL_PAD_SD2_DAT2__SD2_DATA2 0x17059
+							MX6DL_PAD_SD2_DAT3__SD2_DATA3 0x17059
+							MX6DL_PAD_NANDF_D4__SD2_DATA4 0x17059
+							MX6DL_PAD_NANDF_D5__SD2_DATA5 0x17059
+							MX6DL_PAD_NANDF_D6__SD2_DATA6 0x17059
+							MX6DL_PAD_NANDF_D7__SD2_DATA7 0x17059
+						>;
+					};
+				};
+
+				usdhc3 {
+					pinctrl_usdhc3_1: usdhc3grp-1 {
+						fsl,pins = <
+							MX6DL_PAD_SD3_CMD__SD3_CMD    0x17059
+							MX6DL_PAD_SD3_CLK__SD3_CLK    0x10059
+							MX6DL_PAD_SD3_DAT0__SD3_DATA0 0x17059
+							MX6DL_PAD_SD3_DAT1__SD3_DATA1 0x17059
+							MX6DL_PAD_SD3_DAT2__SD3_DATA2 0x17059
+							MX6DL_PAD_SD3_DAT3__SD3_DATA3 0x17059
+							MX6DL_PAD_SD3_DAT4__SD3_DATA4 0x17059
+							MX6DL_PAD_SD3_DAT5__SD3_DATA5 0x17059
+							MX6DL_PAD_SD3_DAT6__SD3_DATA6 0x17059
+							MX6DL_PAD_SD3_DAT7__SD3_DATA7 0x17059
+						>;
+					};
+				};
+
+
+			};
+
 			pxp: pxp at 020f0000 {
 				reg = <0x020f0000 0x4000>;
 				interrupts = <0 98 0x04>;
-- 
1.7.9.5




From shawn.guo at linaro.org  Tue Apr  2 10:32:26 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 2 Apr 2013 22:32:26 +0800
Subject: [PATCH] ARM: imx: do not bring up unavailable cores
Message-ID: <1364913146-26084-1-git-send-email-shawn.guo@linaro.org>

The i.MX6 Quad can be fused as i.MX6 Dual chip, and similarly i.MX6
DualLite can be fused as i.MX6 Solo.  The actual number of available
cores can be found out from SCU.

Since we do not reflect the fusing thing in device tree, the function
arm_dt_init_cpu_maps() will always call set_cpu_possible(true) for 4
cores on i.MX6 Quad/Dual and 2 cores for i.MX6 DualLite/Solo.  This
causes failures when kernel tries to bring those unavailable cores
online.  For example, the following failure message will be seen when
booting an i.MX6 Solo chip.

  CPU1: failed to come online

Though kernel will still boot fine, the message is somehow annoying.
Let's get rid of it by calling set_cpu_possible(false) on those
unavailable cores.

While at it, the set_cpu_possible(true) for available cores is removed,
since it's already been done in arm_dt_init_cpu_maps().

Signed-off-by: Shawn Guo <shawn.guo at linaro.org>
---
 arch/arm/mach-imx/platsmp.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-imx/platsmp.c b/arch/arm/mach-imx/platsmp.c
index 7c0b03f..7061bde 100644
--- a/arch/arm/mach-imx/platsmp.c
+++ b/arch/arm/mach-imx/platsmp.c
@@ -79,8 +79,8 @@ static void __init imx_smp_init_cpus(void)
 
 	ncores = scu_get_core_count(scu_base);
 
-	for (i = 0; i < ncores; i++)
-		set_cpu_possible(i, true);
+	for (i = ncores; i < NR_CPUS; i++)
+		set_cpu_possible(i, false);
 }
 
 void imx_smp_prepare(void)
-- 
1.7.9.5




From stefano.stabellini at eu.citrix.com  Tue Apr  2 11:09:38 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Tue, 2 Apr 2013 16:09:38 +0100
Subject: [PATCH v4 1/2] arm: introduce psci_smp_ops
In-Reply-To: <20130402110255.GA26949@mudshark.cambridge.arm.com>
References: <1364575371-8926-1-git-send-email-stefano.stabellini@eu.citrix.com>
 <20130402110255.GA26949@mudshark.cambridge.arm.com>
Message-ID: <alpine.DEB.2.02.1304021535420.5078@kaball.uk.xensource.com>

On Tue, 2 Apr 2013, Will Deacon wrote:
> > diff --git a/arch/arm/include/asm/psci.h b/arch/arm/include/asm/psci.h
> > index ce0dbe7..4134dda 100644
> > --- a/arch/arm/include/asm/psci.h
> > +++ b/arch/arm/include/asm/psci.h
> > @@ -32,5 +32,14 @@ struct psci_operations {
> >  };
> >  
> >  extern struct psci_operations psci_ops;
> > +extern struct smp_operations psci_smp_ops;
> >  
> > +#ifdef CONFIG_ARM_PSCI
> > +int psci_init(void);
> > +bool psci_smp_available(void);
> > +#else
> > +static inline int psci_init(void) { return -ENODEV; }
> > +static inline bool psci_smp_available(void) { return false; }
> 
> You can probably make psci_init return void now that it's no longer an
> initcall (you're not checking it's return value anyway).

Sure.


> > diff --git a/arch/arm/kernel/psci_smp.c b/arch/arm/kernel/psci_smp.c
> > new file mode 100644
> > index 0000000..66b0f77
> > --- /dev/null
> > +++ b/arch/arm/kernel/psci_smp.c
> > @@ -0,0 +1,67 @@
> > +/*
> > + * 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.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > + * GNU General Public License for more details.
> > + *
> > + * Copyright (C) 2012 ARM Limited
> > + *
> > + * Author: Will Deacon <will.deacon at arm.com>
> > + */
> > +
> > +#include <linux/init.h>
> > +#include <linux/irqchip/arm-gic.h>
> > +#include <linux/smp.h>
> > +#include <linux/of.h>
> > +
> > +#include <asm/psci.h>
> > +#include <asm/smp_plat.h>
> > +
> > +extern void secondary_startup(void);
> > +
> > +static int __cpuinit psci_boot_secondary(unsigned int cpu,
> > +					 struct task_struct *idle)
> > +{
> > +	if (psci_ops.cpu_on)
> > +		return psci_ops.cpu_on(cpu_logical_map(cpu),
> > +				       __pa(secondary_startup));
> > +	return -ENODEV;
> > +}
> 
> Since this code is now likely to be shared, it could be worth a comment
> before each function to describe the expected semantics (e.g. mpidr is used
> as the CPUID, additional power state information is zero).

OK. I'll document psci_operations in psci.h.


From will.deacon at arm.com  Tue Apr  2 11:17:15 2013
From: will.deacon at arm.com (Will Deacon)
Date: Tue, 2 Apr 2013 16:17:15 +0100
Subject: [PATCH] ARM: imx: do not bring up unavailable cores
In-Reply-To: <1364913146-26084-1-git-send-email-shawn.guo@linaro.org>
References: <1364913146-26084-1-git-send-email-shawn.guo@linaro.org>
Message-ID: <20130402151715.GB6608@mudshark.cambridge.arm.com>

On Tue, Apr 02, 2013 at 03:32:26PM +0100, Shawn Guo wrote:
> The i.MX6 Quad can be fused as i.MX6 Dual chip, and similarly i.MX6
> DualLite can be fused as i.MX6 Solo.  The actual number of available
> cores can be found out from SCU.
> 
> Since we do not reflect the fusing thing in device tree, the function
> arm_dt_init_cpu_maps() will always call set_cpu_possible(true) for 4
> cores on i.MX6 Quad/Dual and 2 cores for i.MX6 DualLite/Solo.  This
> causes failures when kernel tries to bring those unavailable cores
> online.  For example, the following failure message will be seen when
> booting an i.MX6 Solo chip.
> 
>   CPU1: failed to come online
> 
> Though kernel will still boot fine, the message is somehow annoying.
> Let's get rid of it by calling set_cpu_possible(false) on those
> unavailable cores.
> 
> While at it, the set_cpu_possible(true) for available cores is removed,
> since it's already been done in arm_dt_init_cpu_maps().
> 
> Signed-off-by: Shawn Guo <shawn.guo at linaro.org>
> ---
>  arch/arm/mach-imx/platsmp.c |    4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/mach-imx/platsmp.c b/arch/arm/mach-imx/platsmp.c
> index 7c0b03f..7061bde 100644
> --- a/arch/arm/mach-imx/platsmp.c
> +++ b/arch/arm/mach-imx/platsmp.c
> @@ -79,8 +79,8 @@ static void __init imx_smp_init_cpus(void)
>  
>  	ncores = scu_get_core_count(scu_base);
>  
> -	for (i = 0; i < ncores; i++)
> -		set_cpu_possible(i, true);
> +	for (i = ncores; i < NR_CPUS; i++)
> +		set_cpu_possible(i, false);
>  }

So you're passing the wrong DT to the kernel and then getting annoyed about
some warnings in the dmesg? Assuming the bootloader knows how many CPUs
there are, shouldn't that be sorting out the CPU nodes before passing the
dtb to the kernel?

Will


From arnd at arndb.de  Tue Apr  2 11:26:48 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 2 Apr 2013 15:26:48 +0000
Subject: [GIT PULL] arm-soc fixes for 3.9-rc5
Message-ID: <201304021526.48872.arnd@arndb.de>

The following changes since commit 8bb9660418e05bb1845ac1a2428444d78e322cc7:

  Linux 3.9-rc4 (2013-03-23 16:52:44 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/fixes

for you to fetch changes up to 06d1d8c85700884940346f20d10b3a22c331b5e9:

  Merge tag 'v3.9-rc1_cns3xxx_fixes' of git://git.infradead.org/users/cbou/linux-cns3xxx into fixes (2013-04-02 16:09:45 +0200)

----------------------------------------------------------------

arm-soc: bug fixes for 3.9-rc5

After a quiet set of fixes for 3.9-rc4, a lot of people woke up and sent
urgent fixes for 3.9. I pushed back on a number of them that got
deferred to 3.10, but these are the ones that seemed important.

Regression in 3.9:

- Multiple regressions in OMAP2+ clock cleanup
- SH-Mobile frame buffer bug fix that merged here because of maintainer MIA
- ux500 prcmu changes broke DT booting
- MMCI duplicated regulator setup on ux500
- New ux500 clock driver broke ethernet on snowball
- Local interrupt driver for mvebu broke ethernet
- MVEBU GPIO driver did not get set up right on Orion DT
- incorrect interrupt number on Orion crypto for DT

Long-standing bugs, including candidates for stable:

- Kirkwood MMC needs to disable invalid card detect pins
- MV SDIO pinmux was wrong on Mirabox
- GoFlex Net board file needs to set NAND chip delay
- MSM timer restart race
- ep93xx early debug code broke in 3.7
- i.MX CPU hotplug race
- Incorrect clock setup for OMAP1 USB
- Workaround for bad clock setup by some old OMAP4 boot loaders
- Static I/O mappings on cns3xxx since 3.2

----------------------------------------------------------------
Aaro Koskinen (1):
      ARM: OMAP1: fix USB host on 1710

Alexander Clouter (2):
      arm: orion5x: fix orion5x.dtsi gpio parameters
      arm: orion5x: correct IRQ used in dtsi for mv_cesa

Arnd Bergmann (8):
      Merge tag 'msm-fix-3.9' of git://git.kernel.org/.../davidb/linux-msm into fixes
      Merge tag 'renesas-fbdev-fixes-for-v3.9' of git://git.kernel.org/.../horms/renesas into fixes
      Merge tag 'omap-for-v3.9-rc3/fixes-signed' of git://git.kernel.org/.../tmlind/linux-omap into fixes
      Merge tag 'ux500-fixes-for-v3.9' of git://git.kernel.org/.../linusw/linux-stericsson into fixes
      Merge tag 'imx-fixes-3.9-4' of git://git.linaro.org/people/shawnguo/linux-2.6 into fixes
      Merge tag 'ep93xx-fixes-for-3.9-rc5' of git://github.com/RyanMallon/linux-ep93xx into fixes
      Merge tag 'mvebu_fixes_for_v3.9_round2' of git://git.infradead.org/users/jcooper/linux into fixes
      Merge tag 'v3.9-rc1_cns3xxx_fixes' of git://git.infradead.org/users/cbou/linux-cns3xxx into fixes

Eric Hutter (1):
      ARM: kirkwood: Fix chip-delay for GoFlex Net

Grazvydas Ignotas (1):
      ARM: OMAP3: hwmod data: keep MIDLEMODE in force-standby for musb

Gregory CLEMENT (1):
      arm: mvebu: Use local interrupt only for the timer 0

H Hartley Sweeten (1):
      ARM: ep93xx: Fix wait for UART FIFO to be empty

Jon Hunter (1):
      ARM: OMAP4: clock data: lock USB DPLL on boot

Kuninori Morimoto (1):
      fbdev: sh_mobile_lcdc: fixup B side hsync adjust settings

Lee Jones (3):
      ARM: ux500: Apply the TCPM and TCDM locations and sizes to dbx5x0 DT
      ARM: ux500: Stop passing ios_handler() as an MMCI power controlling call-back
      ARM: ux500: Enable the clock controlling Ethernet on Snowball

Mac Lin (1):
      ARM: cns3xxx: fix mapping of private memory region

Paul Walmsley (1):
      ARM: OMAP4: PM: fix PM regression introduced by recent clock cleanup

Rajendra Nayak (1):
      ARM: OMAP: clocks: Delay clk inits atleast until slab is initialized

Ryan Press (1):
      arm: mvebu: Fix pinctrl for Armada 370 Mirabox SDIO port.

Sebastian Hesselbarth (1):
      ARM: Kirkwood: fix unused mvsdio gpio pins

Shawn Guo (2):
      ARM: imx: add dependency check for DEBUG_IMX_UART_PORT
      ARM: imx: fix sync issue between imx_cpu_die and imx_cpu_kill

Stephen Boyd (1):
      ARM: msm: Stop counting before reprogramming clockevent

Tony Lindgren (1):
      Merge tag 'omap-fixes-a-for-3.9-rc' of git://git.kernel.org/.../pjw/omap-pending into omap-for-v3.9-rc3/fixes

 arch/arm/Kconfig.debug                         |  1 +
 arch/arm/boot/dts/armada-370-mirabox.dts       |  2 +-
 arch/arm/boot/dts/armada-370.dtsi              |  6 ++++++
 arch/arm/boot/dts/dbx5x0.dtsi                  |  4 ++--
 arch/arm/boot/dts/kirkwood-goflexnet.dts       |  1 +
 arch/arm/boot/dts/orion5x.dtsi                 |  9 +++++++--
 arch/arm/mach-cns3xxx/core.c                   | 16 +++-------------
 arch/arm/mach-cns3xxx/include/mach/cns3xxx.h   | 16 ++++++++--------
 arch/arm/mach-ep93xx/include/mach/uncompress.h | 10 +++++++---
 arch/arm/mach-imx/common.h                     |  2 ++
 arch/arm/mach-imx/hotplug.c                    | 12 ++++++++++++
 arch/arm/mach-imx/src.c                        | 12 ++++++++++++
 arch/arm/mach-kirkwood/guruplug-setup.c        |  2 ++
 arch/arm/mach-kirkwood/openrd-setup.c          |  1 +
 arch/arm/mach-kirkwood/rd88f6281-setup.c       |  1 +
 arch/arm/mach-msm/timer.c                      |  5 ++++-
 arch/arm/mach-mvebu/irq-armada-370-xp.c        |  8 +++++---
 arch/arm/mach-omap1/clock_data.c               | 12 +-----------
 arch/arm/mach-omap2/cclock44xx_data.c          | 20 ++++++++++++++++++++
 arch/arm/mach-omap2/common.h                   |  3 +++
 arch/arm/mach-omap2/io.c                       | 18 ++++++++++++------
 arch/arm/mach-omap2/omap_hwmod.c               |  7 +++++--
 arch/arm/mach-omap2/omap_hwmod.h               |  9 +++++++--
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c     |  7 ++++++-
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c     |  6 ++++++
 arch/arm/mach-omap2/timer.c                    |  4 ++++
 arch/arm/mach-ux500/board-mop500-sdi.c         |  1 -
 arch/arm/mach-ux500/board-mop500.c             | 12 ++++++++++++
 arch/arm/mach-ux500/board-mop500.h             |  1 +
 arch/arm/mach-ux500/cpu-db8500.c               |  5 +++--
 drivers/video/sh_mobile_lcdcfb.c               |  1 +
 31 files changed, 156 insertions(+), 58 deletions(-)


From dgilbert at interlog.com  Tue Apr  2 11:32:27 2013
From: dgilbert at interlog.com (Douglas Gilbert)
Date: Tue, 02 Apr 2013 11:32:27 -0400
Subject: [RFC PATCH] rtc: rtc-at91rm9200: manage IMR depending on revision
In-Reply-To: <1364908007-5150-1-git-send-email-nicolas.ferre@atmel.com>
References: <1364573029-19346-5-git-send-email-jhovold@gmail.com>
 <1364908007-5150-1-git-send-email-nicolas.ferre@atmel.com>
Message-ID: <515AFA0B.7020509@interlog.com>

On 13-04-02 09:06 AM, Nicolas Ferre wrote:
> Signed-off-by: Nicolas Ferre <nicolas.ferre at atmel.com>
> ---
> Hi all,
>
> The funny thing is that I was writing exactly the same code as Johan's
> when he posted his series.
>
> So, here is my single patch, with the comment about the readback stolen from
> Johan's, but without the way to determine with IP is buggy and which one is
> not...
> After having dug the possibility to read the IP revision, I discovered that it
> is not possible to use this information ("version" register offset changing
> according to... IP version number: well done!).
> In conclusion, I guess that the only way to determine if we need the workaround
> is to use the DT.
> One remark though: if we use the compatibility string for this purpose, I fear
> that we would twist the meaning of this information: SoC using an
> "atmel,at91sam9x5-rtc" compatible RTC will not necessarily be touched by the
> "non responding IMR" bug: at91sam9n12 or upcoming sama5d3 are not affected for
> instance, and we need to cling to "atmel,at91rm9200-rtc" for them...
> I think that we can use this method for the moment and move to another
> compatibility string later if it is needed.

Rather than have so many people working on rtc-at91rm9200.c,
how about someone bring its "RTT" sibling into the DT
world. I'm talking about drivers/rtc/rtc-at91sam9.c ...

Doug Gilbert



From swarren at wwwdotorg.org  Tue Apr  2 11:36:14 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Tue, 02 Apr 2013 09:36:14 -0600
Subject: How to represent negative values for device tree property
In-Reply-To: <20130402062925.GJ7426@truffula.fritz.box>
References: <5159F760.1080605@codeaurora.org> <515A038F.2090902@wwwdotorg.org>
 <515A2533.8050005@codeaurora.org> <20130402062925.GJ7426@truffula.fritz.box>
Message-ID: <515AFAEE.4050300@wwwdotorg.org>

On 04/02/2013 12:29 AM, David Gibson wrote:
> On Mon, Apr 01, 2013 at 05:24:19PM -0700, David Collins wrote:
>> On 04/01/2013 03:00 PM, Stephen Warren wrote:
>>> On 04/01/2013 03:08 PM, David Collins wrote:
>>>> Hi,
>>>> 
>>>> I am working on a thermal driver which needs to be able to
>>>> read a temperature threshold from a device tree property.
>>>> The hardware supports thresholds in the range -204.8 to
>>>> +204.7 C in 0.1 C steps.  I have found, as I am sure others
>>>> have as well, that dtc treats a '-' before an integer in a
>>>> dtsi file as a syntax error.  Therefore, I need some
>>>> artificial way to represent negative numbers in device tree.
>>>> Here are the possibilities that I have thought of so far:
>>> 
>>> Doesn't the very latest dtc, which contains integer expression
>>> support, allow unary -? I thought that code had been imported
>>> into the kernel (goes and checks) yes it has. What's the error
>>> you're seeing; over/underflow or syntax?
>>> 
>>> That said, DT cells are supposed to be u32 not s32, so perhaps
>>> this isn't unexpected.
> 
> That's.. sort of true, but misleading.  As far as the dtb format
> is concerned, properties are just a bag of bytes.  Individual
> device bindings define how software should interpret those bytes.
> 
> The dtc data "types" are really just convenient ways to enter
> various sorts of commonly used bytestrings.  Some of the dtc code
> treats cells as u32 because that works for its purposes (and in
> particular avoids some nasty C standard gotchas where signed
> overflows may have undefined results), but there's no reason you
> can't treat it as an s32.  On dtc versions recent enough to have
> arithmetic, unary minus and subtractive overflow will use 2's
> complement, as you'd expect.

OK, perhaps I was extrapolating too far from the fact that all the
DT-related code in the kernel (just happens to) only read integers as
u32. It sounds like it'd be fine to add e.g. of_property_read_s32()
alongside the existing of_property_read_u32() then. I imagine that
would be quite useful.


From dianders at chromium.org  Tue Apr  2 11:37:35 2013
From: dianders at chromium.org (Doug Anderson)
Date: Tue, 2 Apr 2013 08:37:35 -0700
Subject: [PATCH v2] mmc: dwmmc: let device core setup the default pin
 configuration
In-Reply-To: <1364882999-31670-1-git-send-email-thomas.abraham@linaro.org>
References: <1364882999-31670-1-git-send-email-thomas.abraham@linaro.org>
Message-ID: <CAD=FV=Xck5XW3LPmvkMfP=dfmnDH+kG4VYkRetW+SJ-bAz7SqQ@mail.gmail.com>

Thomas,

On Mon, Apr 1, 2013 at 11:09 PM, Thomas Abraham
<thomas.abraham at linaro.org> wrote:
> With device core now able to setup the default pin configuration,
> the pin configuration code based on the deprecated Samsung specific
> gpio bindings is removed.
>
> Signed-off-by: Thomas Abraham <thomas.abraham at linaro.org>
> Acked-by: Linus Walleij <linus.walleij at linaro.org>
> Reviewed-by: Doug Anderson <dianders at chromium.org>
> Tested-by: Doug Anderson <dianders at chromium.org>

You missed Seungwon's other feedback.  Please change the title from
"mmc: dwmmc: let device core setup the default pin configuration" to
"mmc: dw_mmc: let device core setup the default pin configuration".
He requested that the tag have the underscore in it for consistency.

If you're resending, it also seems like it might be nice to rebase this atop:

0f6e73d mmc: dw_mmc: Add MSHC compatible for Exynos4412

...just to avoid the simple merge conflict when applying?

Otherwise everything here looks great...

-Doug


From swarren at wwwdotorg.org  Tue Apr  2 11:40:54 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Tue, 02 Apr 2013 09:40:54 -0600
Subject: [PATCH v4 1/6] drivers: phy: add generic PHY framework
In-Reply-To: <515A98B3.7090405@ti.com>
References: <1364449408-9510-1-git-send-email-kishon@ti.com>
 <1364449408-9510-2-git-send-email-kishon@ti.com>
 <5154658A.3080209@wwwdotorg.org> <515A98B3.7090405@ti.com>
Message-ID: <515AFC06.8000502@wwwdotorg.org>

On 04/02/2013 02:37 AM, Kishon Vijay Abraham I wrote:
> Hi,
> 
> On Thursday 28 March 2013 09:15 PM, Stephen Warren wrote:
>> On 03/27/2013 11:43 PM, Kishon Vijay Abraham I wrote:
>>> The PHY framework provides a set of APIs for the PHY drivers to
>>> create/destroy a PHY and APIs for the PHY users to obtain a reference
>>> to the
>>
>>> diff --git a/Documentation/devicetree/bindings/phy/phy-bindings.txt

>>> +PHY subsystem refer Documentation/phy.txt
>>> +
>>> +PHY device node
>>> +===============
>>> +
>>> +Optional Properties:
>>> +#phy-cells:    Number of cells in a PHY specifier;  The meaning of all those
>>> +        cells is defined by the binding for the phy node. However
>>> +        in-order to return the correct PHY, the PHY susbsystem
>>> +        requires the first cell always refers to the port.
>>
>> Why impose that restriction? Other DT bindings do not.
>>
>> This is typically implemented by having each provider driver implement a
>> .of_xlate() operation, which parses all of the specifier cells, and
>> returns the ID of the object it represents. This allows bindings to use
>> whatever arbitrary representation they want.
> 
> Do you mean something like this
> 
> struct phy *of_phy_get(struct device *dev, int index)
> {
>     struct phy *phy = NULL;
>     struct phy_bind *phy_map = NULL;
>     struct of_phandle_args args;
>     struct device_node *node;
> 
>     if (!dev->of_node) {
>         dev_dbg(dev, "device does not have a device node entry\n");
>         return ERR_PTR(-EINVAL);
>     }
> 
>     ret = of_parse_phandle_with_args(dev->of_node, "phys", "#phy-cells",
>         index, &args);
>     if (ret) {
>         dev_dbg(dev, "failed to get phy in %s node\n",
>             dev->of_node->full_name);
>         return ERR_PTR(-ENODEV);
>     }

Looks good.

> //Here we have to get a reference to the phy in order to call of_xlate
> which seems a little hacky to me. I'm not sure how else can we call the
> provider driver :-(
>     phy = of_phy_lookup(dev, node);
>     if (IS_ERR(phy) || !try_module_get(phy->ops->owner)) {
>         phy = ERR_PTR(-EPROBE_DEFER);
>         goto err0;
>     }

I think the concept of a "PHY provider" and a "PHY instance" are different.

of_xlate should be called on a "PHY provider", and return a "PHY
instance". Hence, above you want to only look up a "PHY provider", so
there's no hackiness involved.

> //here we are checking if the phy has additional specifiers and if so
> call of_xlate using the phy we just obtained. The provider driver should
> check the args and return the appropriate *phy in this case.
>     if (args.args_count > 0) {

It's probably simplest to always call of_xlate; that way, you're always
calling it on a "PHY provider" and getting back a "PHY instance". For
providers that only provide 1 instance, the implementation should be
simple:-)

>         phy = phy->of_xlate(&args);
>         if (IS_ERR(phy))
>             goto err0;
>     }
> 
>     phy_map = phy_bind(dev_name(dev), index, dev_name(&phy->dev));
>     if (!IS_ERR(phy_map)) {
>         phy_map->phy = phy;
>         phy_map->auto_bind = true;
>     }
> 
>     get_device(&phy->dev);
> 
> err0:
>     of_node_put(node);
> 
>     return phy;
> }
> EXPORT_SYMBOL_GPL(of_phy_get);



From arnd at arndb.de  Tue Apr  2 11:41:52 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 2 Apr 2013 15:41:52 +0000
Subject: [PATCH 16/30] ARM: shmobile: sh7372: use fixed ratio clock
In-Reply-To: <515ACC46.9020402@cogentembedded.com>
References: <1364879246-9470-1-git-send-email-horms+renesas@verge.net.au>
 <1364879246-9470-17-git-send-email-horms+renesas@verge.net.au>
 <515ACC46.9020402@cogentembedded.com>
Message-ID: <201304021541.52531.arnd@arndb.de>

On Tuesday 02 April 2013, Sergei Shtylyov wrote:
> > @@ -83,39 +84,12 @@ struct clk sh7372_extal2_clk = {
> [...]
> > +SH_FIXED_RATIO_CLKg(sh7372_dv_clki_div2_clk, sh7372_dv_clki_clk,     div2);
> > +SH_FIXED_RATIO_CLK(extal1_div2_clk,          sh7372_extal1_clk,      div2);
> > +SH_FIXED_RATIO_CLK(extal2_div2_clk,          sh7372_extal2_clk,      div2);
> > +SH_FIXED_RATIO_CLK(extal2_div4_clk,          extal2_div2_clk,        div2);
> 
>     Note that SH_FIXED_RATIO_CLK() definition already includes ; -- it 
> probably should be removed from there.

Most macros that we have in the kernel like this don't include the semicolon,
which seems better since it is harder to misuse (the compiler will complain
about a missing semicolon but not always about an extranous one) and gives
a more consistent syntax overall.

It's probably not worth changing it now for the shmobile clock code, since
that is getting changed over to common clock in the future, but you may
want to remember this for future macro definitions.

	Arnd


From chf.fritz at googlemail.com  Tue Apr  2 11:55:24 2013
From: chf.fritz at googlemail.com (Christoph Fritz)
Date: Tue, 02 Apr 2013 17:55:24 +0200
Subject: [RFC][BUG] arm/dts: OMAP3: set #interrupt-cells to two
In-Reply-To: <CAAwP0s1H9zaBZPMDz9=He-E68UK0Ay3jnxZ2frYH9r1xNeQhxQ@mail.gmail.com>
References: <1364631689.3767.7.camel@mars>
 <CAAwP0s35J-edpvFv08xjjpwaezQBYNvMNhhXL-UacsuUtSt4ZA@mail.gmail.com>
 <1364834508.3939.74.camel@mars>
 <CAAwP0s1H9zaBZPMDz9=He-E68UK0Ay3jnxZ2frYH9r1xNeQhxQ@mail.gmail.com>
Message-ID: <1364918124.5935.145.camel@mars>

On Mon, 2013-04-01 at 22:05 +0200, Javier Martinez Canillas wrote:

> > As a quick-fix (hack) I wrote directly to the registers in gpio_probe()
> > to enable GPIO banks. I now geht this:
> >
> >> > [    0.214630] omap_gpio_probe, 1133, CM_CLKSEL_PER 0x48005040: 0x000000ff
> >> > [    0.214660] omap_gpio_probe, 1136, CM_ICLKEN_PER 0x48005010: 0x0007ffff
> >> > [    0.214660] omap_gpio_probe, 1139, CM_FCLKEN_PER 0x48005000: 0x0007ffff

to be more specific on this point, this is the patch to enable the
gpio-clocks:

--
Subject: [PATCH] HACK: enable gpio-clocks in gpio-omap probe()

Without this patch setting trigger value from #interrupt-cell two
(smsc911x) fails.
---
 drivers/gpio/gpio-omap.c |   12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 159f5c5..720b2e6 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -1098,6 +1098,7 @@ static int omap_gpio_probe(struct platform_device *pdev)
 	struct resource *res;
 	struct gpio_bank *bank;
 	int ret = 0;
+	void __iomem *tmp;
 
 	match = of_match_device(of_match_ptr(omap_gpio_match), dev);
 
@@ -1117,6 +1118,17 @@ static int omap_gpio_probe(struct platform_device *pdev)
 		return -ENODEV;
 	}
 
+	// TRM: Table 3-242. PER_CM Register Summary
+	tmp = ioremap(0x48005040, 4); //CM_CLKSEL_PER, GPT2 = sys clk
+	writel(0xFF, tmp);
+	iounmap(tmp);
+	tmp = ioremap(0x48005010, 4); //CM_ICLKEN_PER, ICKen GPT2
+	writel(0x7FFFF, tmp);
+	iounmap(tmp);
+	tmp = ioremap(0x48005000, 4); //CM_FCLKEN_PER, GPIOX functional clock is enabled
+	writel(0x7FFFF, tmp);
+	iounmap(tmp);
+
 	bank->irq = res->start;
 	bank->dev = dev;
 	bank->dbck_flag = pdata->dbck_flag;
-- 
1.7.10.4

Is there a better way to do this?


> >
> > And it works for me. _But_ when I do enable regulator twl4030
> > (CONFIG_REGULATOR_TWL4030=y) in my config these registers get reset:
> >
> > [    2.935455] smsc911x_open, 1537, CM_CLKSEL_PER 0x48005040: 0x000000ff
> > [    2.942291] smsc911x_open, 1540, CM_ICLKEN_PER 0x48005010: 0x00040fff
> > [    2.949066] smsc911x_open, 1543, CM_FCLKEN_PER 0x48005000: 0x00000000
> >
> > And the IRQ source for the network chip (smsc911x) is disabled :-(

CONFIG_REGULATOR_TWL4030=y  disables the gpio-clocks. Why is that?

> >
> > Do you have any idea how to ("quick") fix this?
> >
> 
> A quick hack is to call gpio_request() explicitly before calling to
> irq_set_type() is made.
> I've this patch just to make it work until we find a clean solution:
> 
> diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
> index 90c15ee..d594e1d 100644
> --- a/arch/arm/mach-omap2/gpmc.c
> +++ b/arch/arm/mach-omap2/gpmc.c
> @@ -14,6 +14,7 @@
>   */
>  #undef DEBUG
> 
> +#include <linux/gpio.h>
>  #include <linux/irq.h>
>  #include <linux/kernel.h>
>  #include <linux/init.h>
> @@ -1528,6 +1529,11 @@ static int gpmc_probe_dt(struct platform_device *pdev)
>                 return ret;
>         }
> 
> +       ret = gpio_request_one(176, GPIOF_IN, "smsc911x irq");
> +       if (ret) {
> +               pr_err("Failed to request IRQ GPIO%d\n", 176);
> +               return ret;
> +       }
> +
>         for_each_node_by_name(child, "nand") {
>                 ret = gpmc_probe_nand_child(pdev, child);
>                 if (ret < 0) {
> 
> This solves the issue of the non-initialized GPIO bank before that
> makes the kernel to hang.

Here it does not. A printk shows that I'm not using gpmc at all.
So I added a gpmc node:

+       gpmc: gpmc at 0x6E000000 {
+               compatible = "ti,omap3430-gpmc";
+               ti,hwmods = "ti,gpmc";
+               reg = <0x6E000000 0x2000>;
+               gpmc,num-cs = <8>;
+               gpmc,num-waitpins = <2>;
+               #address-cells = <2>;
+               #size-cells = <1>;
+               ranges = <0 0 0x0 0x3FFFFFFF>;
+
+       };

But still, gpmc_probe_dt() isn't called. I maybe have to define some
child nodes but currently I do configure the gpmc in u-boot and try to
avoid kernel-gpmc-config.

>  Since I've to configure the IRQ polarity as
> active low level-sensitive on my board and the flags are not set by
> the IRQ core, I've another ugly hack that forces this:
> 
> diff --git a/drivers/net/ethernet/smsc/smsc911x.c
> b/drivers/net/ethernet/smsc/smsc
> index da5cc9a..27e46f9 100644
> --- a/drivers/net/ethernet/smsc/smsc911x.c
> +++ b/drivers/net/ethernet/smsc/smsc911x.c
> @@ -2390,6 +2390,9 @@ static int smsc911x_drv_probe(struct
> platform_device *pdev)
>         pdata = netdev_priv(dev);
>         dev->irq = irq_res->start;
> -        irq_flags = irq_res->flags & IRQF_TRIGGER_MASK;
> +       irq_flags = IRQF_TRIGGER_LOW;
>         pdata->ioaddr = ioremap_nocache(res->start, res_size);
> 
>         pdata->dev = dev;

I already did something like that with this patch:

---
Subject: [PATCH] net: smsc911x: adopt pinctrl support

This patch is derived from 2d4b4520a "i2c: omap: adopt pinctrl support":
Some GPIO expanders need some early pin control muxing. Due to
legacy boards sometimes the driver uses subsys_initcall instead of
module_init. This patch takes advantage of defer probe feature
and pin control in order to wait until pin control probing before
GPIO driver probing.

---
 drivers/net/ethernet/smsc/smsc911x.c |   15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/drivers/net/ethernet/smsc/smsc911x.c b/drivers/net/ethernet/smsc/smsc911x.c
index da5cc9a..3e3547c 100644
--- a/drivers/net/ethernet/smsc/smsc911x.c
+++ b/drivers/net/ethernet/smsc/smsc911x.c
@@ -59,6 +59,7 @@
 #include <linux/of_device.h>
 #include <linux/of_gpio.h>
 #include <linux/of_net.h>
+#include <linux/pinctrl/consumer.h>
 #include "smsc911x.h"
 
 #define SMSC_CHIPNAME		"smsc911x"
@@ -144,6 +145,8 @@ struct smsc911x_data {
 
 	/* regulators */
 	struct regulator_bulk_data supplies[SMSC911X_NUM_SUPPLIES];
+
+	struct pinctrl *pins;
 };
 
 /* Easy access to information */
@@ -2433,6 +2436,18 @@ static int smsc911x_drv_probe(struct platform_device *pdev)
 	if (retval < 0)
 		goto out_disable_resources;
 
+	pdata->pins = devm_pinctrl_get_select_default(&pdev->dev);
+	if (IS_ERR(pdata->pins)) {
+		if (PTR_ERR(pdata->pins) == -EPROBE_DEFER) {
+			retval = -EPROBE_DEFER;
+			goto out_disable_resources;
+		}
+
+		dev_warn(&pdev->dev, "No pins for smsc911x error: %li\n",
+			 PTR_ERR(pdata->pins));
+		pdata->pins = NULL;
+	}
+
 	/* configure irq polarity and type before connecting isr */
 	if (pdata->config.irq_polarity == SMSC911X_IRQ_POLARITY_ACTIVE_HIGH)
 		intcfg |= INT_CFG_IRQ_POL_;
-- 
1.7.10.4

Now I can specify the "IRQF_TRIGGER_LOW" (which is 0x2) in the device
tree thanks to the first patch in this thread:

        lan9221 at 15000000 {
                compatible = "smsc,lan9221", "smsc,lan9115";
                reg = <0x15000000 0x400>;
                phy-mode = "mii";
                interrupt-parent = <&gpio5>;
                interrupts = <1 0x2>;   /* gpio_129, trigger: falling-edge */
                reg-io-width = <4>;
                vdd33a-supply = <&reg_vcc3>;
                vddvario-supply = <&reg_vcc3>;
                pinctrl-names = "default";
                pinctrl-0 = <&lan9221_pins>;
        };


 Thanks
  -- Christoph




From swarren at wwwdotorg.org  Tue Apr  2 11:57:32 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Tue, 02 Apr 2013 09:57:32 -0600
Subject: [PATCH 1/2] ARM: tegra: move <mach/powergate.h> to
 <linux/tegra-powergate.h>
In-Reply-To: <1364602790-10759-1-git-send-email-swarren@wwwdotorg.org>
References: <1364602790-10759-1-git-send-email-swarren@wwwdotorg.org>
Message-ID: <515AFFEC.1000609@wwwdotorg.org>

On 03/29/2013 06:19 PM, Stephen Warren wrote:
> From: Stephen Warren <swarren at nvidia.com>
> 
> This is required so that code such as Tegra's PCIe and clock drivers
> can still access this header file once Tegra is converted to
> multiplatform, and <mach/> no longer exists.

The series applied to Tegra's for-3.10/multiplatform branch.


From marc.zyngier at arm.com  Tue Apr  2 11:58:05 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Tue,  2 Apr 2013 16:58:05 +0100
Subject: [PATCH v2] ARM: KVM: promote vfp_host pointer to generic host cpu
 context
Message-ID: <1364918285-26625-1-git-send-email-marc.zyngier@arm.com>

We use the vfp_host pointer to store the host VFP context, should
the guest start using VFP itself.

Actually, we can use this pointer in a more generic way to store
CPU speficic data, and arm64 is using it to dump the whole host
state before switching to the guest.

Simply rename the vfp_host field to host_cpu_context, and the
corresponding type to kvm_cpu_context_t. No change in functionnality.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm/include/asm/kvm_host.h |  8 +++++---
 arch/arm/kernel/asm-offsets.c   |  2 +-
 arch/arm/kvm/arm.c              | 28 ++++++++++++++--------------
 3 files changed, 20 insertions(+), 18 deletions(-)

diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
index 78813b8..a7a0bb5 100644
--- a/arch/arm/include/asm/kvm_host.h
+++ b/arch/arm/include/asm/kvm_host.h
@@ -87,7 +87,7 @@ struct kvm_vcpu_fault_info {
 	u32 hyp_pc;		/* PC when exception was taken from Hyp mode */
 };
 
-typedef struct vfp_hard_struct kvm_kernel_vfp_t;
+typedef struct vfp_hard_struct kvm_cpu_context_t;
 
 struct kvm_vcpu_arch {
 	struct kvm_regs regs;
@@ -105,8 +105,10 @@ struct kvm_vcpu_arch {
 	struct kvm_vcpu_fault_info fault;
 
 	/* Floating point registers (VFP and Advanced SIMD/NEON) */
-	kvm_kernel_vfp_t vfp_guest;
-	kvm_kernel_vfp_t *vfp_host;
+	struct vfp_hard_struct vfp_guest;
+
+	/* Host FP context */
+	kvm_cpu_context_t *host_cpu_context;
 
 	/* VGIC state */
 	struct vgic_cpu vgic_cpu;
diff --git a/arch/arm/kernel/asm-offsets.c b/arch/arm/kernel/asm-offsets.c
index ee1ac39..92562a2 100644
--- a/arch/arm/kernel/asm-offsets.c
+++ b/arch/arm/kernel/asm-offsets.c
@@ -154,7 +154,7 @@ int main(void)
   DEFINE(VCPU_MIDR,		offsetof(struct kvm_vcpu, arch.midr));
   DEFINE(VCPU_CP15,		offsetof(struct kvm_vcpu, arch.cp15));
   DEFINE(VCPU_VFP_GUEST,	offsetof(struct kvm_vcpu, arch.vfp_guest));
-  DEFINE(VCPU_VFP_HOST,		offsetof(struct kvm_vcpu, arch.vfp_host));
+  DEFINE(VCPU_VFP_HOST,		offsetof(struct kvm_vcpu, arch.host_cpu_context));
   DEFINE(VCPU_REGS,		offsetof(struct kvm_vcpu, arch.regs));
   DEFINE(VCPU_USR_REGS,		offsetof(struct kvm_vcpu, arch.regs.usr_regs));
   DEFINE(VCPU_SVC_REGS,		offsetof(struct kvm_vcpu, arch.regs.svc_regs));
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index e821c37..2ce90bb 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -48,7 +48,7 @@ __asm__(".arch_extension	virt");
 #endif
 
 static DEFINE_PER_CPU(unsigned long, kvm_arm_hyp_stack_page);
-static kvm_kernel_vfp_t __percpu *kvm_host_vfp_state;
+static kvm_cpu_context_t __percpu *kvm_host_cpu_state;
 static unsigned long hyp_default_vectors;
 
 /* Per-CPU variable containing the currently running vcpu. */
@@ -325,7 +325,7 @@ void kvm_arch_vcpu_uninit(struct kvm_vcpu *vcpu)
 void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
 {
 	vcpu->cpu = cpu;
-	vcpu->arch.vfp_host = this_cpu_ptr(kvm_host_vfp_state);
+	vcpu->arch.host_cpu_context = this_cpu_ptr(kvm_host_cpu_state);
 
 	/*
 	 * Check whether this vcpu requires the cache to be flushed on
@@ -889,24 +889,24 @@ static int init_hyp_mode(void)
 	}
 
 	/*
-	 * Map the host VFP structures
+	 * Map the host CPU structures
 	 */
-	kvm_host_vfp_state = alloc_percpu(kvm_kernel_vfp_t);
-	if (!kvm_host_vfp_state) {
+	kvm_host_cpu_state = alloc_percpu(kvm_cpu_context_t);
+	if (!kvm_host_cpu_state) {
 		err = -ENOMEM;
-		kvm_err("Cannot allocate host VFP state\n");
+		kvm_err("Cannot allocate host CPU state\n");
 		goto out_free_mappings;
 	}
 
 	for_each_possible_cpu(cpu) {
-		kvm_kernel_vfp_t *vfp;
+		kvm_cpu_context_t *cpu_ctxt;
 
-		vfp = per_cpu_ptr(kvm_host_vfp_state, cpu);
-		err = create_hyp_mappings(vfp, vfp + 1);
+		cpu_ctxt = per_cpu_ptr(kvm_host_cpu_state, cpu);
+		err = create_hyp_mappings(cpu_ctxt, cpu_ctxt + 1);
 
 		if (err) {
-			kvm_err("Cannot map host VFP state: %d\n", err);
-			goto out_free_vfp;
+			kvm_err("Cannot map host CPU state: %d\n", err);
+			goto out_free_context;
 		}
 	}
 
@@ -915,7 +915,7 @@ static int init_hyp_mode(void)
 	 */
 	err = kvm_vgic_hyp_init();
 	if (err)
-		goto out_free_vfp;
+		goto out_free_context;
 
 #ifdef CONFIG_KVM_ARM_VGIC
 		vgic_present = true;
@@ -933,8 +933,8 @@ static int init_hyp_mode(void)
 	kvm_info("Hyp mode initialized successfully\n");
 
 	return 0;
-out_free_vfp:
-	free_percpu(kvm_host_vfp_state);
+out_free_context:
+	free_percpu(kvm_host_cpu_state);
 out_free_mappings:
 	free_hyp_pmds();
 out_free_stack_pages:
-- 
1.8.1.4




From olof at lixom.net  Tue Apr  2 11:58:17 2013
From: olof at lixom.net (Olof Johansson)
Date: Tue, 2 Apr 2013 08:58:17 -0700
Subject: [PATCH] ARM: LPC32xx: changed lpc23xx_restart to lpc32xx_restart
In-Reply-To: <1362601138-16550-1-git-send-email-martinknoll@me.com>
References: <1362601138-16550-1-git-send-email-martinknoll@me.com>
Message-ID: <20130402155817.GA25867@quad.lixom.net>

On Wed, Mar 06, 2013 at 09:18:58PM +0100, Martin Knoll wrote:
> This function has an odd name. This is probably a typo.

You should cc the platform maintainer on these kind of patches (Roland Stigge).
But it seems that he's not actually listed in MAINTAINERS.

Roland, can you send a patch adding yourself as LPC32XX maintainer so these
kind of patches don't get dropped? Thanks!


-Olof


From cjb at laptop.org  Tue Apr  2 12:01:18 2013
From: cjb at laptop.org (Chris Ball)
Date: Tue, 02 Apr 2013 12:01:18 -0400
Subject: [PATCH v7 0/5] Add DT support for davinci_mmc driver
In-Reply-To: <515AAB88.3030406@ti.com> (Sekhar Nori's message of "Tue, 2 Apr
 2013 15:27:28 +0530")
References: <1364476211-14322-1-git-send-email-prakash.pm@ti.com>
 <515AAB88.3030406@ti.com>
Message-ID: <87wqskx6pd.fsf@octavius.laptop.org>

Hi,

On Tue, Apr 02 2013, Sekhar Nori wrote:
> I would like to take this series through DaVinci tree to manage the
> dependencies with mach-davinci. I need your ack on the driver part and
> the DT binding. Can you please provide your ack?

Acked-by: Chris Ball <cjb at laptop.org>

Thanks,

- Chris.
-- 
Chris Ball   <cjb at laptop.org>   <http://printf.net/>
One Laptop Per Child


From nicolas.pitre at linaro.org  Tue Apr  2 12:11:25 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Tue, 2 Apr 2013 12:11:25 -0400 (EDT)
Subject: [PATCH v4 2/2] arm: prefer PSCI for SMP bringup
In-Reply-To: <alpine.DEB.2.02.1304021522230.5078@kaball.uk.xensource.com>
References: <1364575371-8926-2-git-send-email-stefano.stabellini@eu.citrix.com>
 <alpine.LFD.2.03.1303291320580.1372@syhkavp.arg>
 <alpine.DEB.2.02.1303291735080.4430@kaball.uk.xensource.com>
 <alpine.LFD.2.03.1303291349150.1372@syhkavp.arg> <5155EC28.8050608@gmail.com>
 <alpine.DEB.2.02.1304011541010.5078@kaball.uk.xensource.com>
 <alpine.LFD.2.03.1304011412030.1171@syhkavp.arg>
 <alpine.DEB.2.02.1304021522230.5078@kaball.uk.xensource.com>
Message-ID: <alpine.LFD.2.03.1304021202520.1171@syhkavp.arg>

On Tue, 2 Apr 2013, Stefano Stabellini wrote:

> On Mon, 1 Apr 2013, Nicolas Pitre wrote:
> > On Mon, 1 Apr 2013, Stefano Stabellini wrote:
> > > What are the platforms that are going to use smp_init? Do we know how do
> > > they intend to use it?
> > 
> > VExpress for one.  When booting on a big.LITTLE system such as TC2 on 
> > VExpress, the MCPM layer needs to arbitrate power management operations 
> > on a per cluster basis.  In that case there is a MCPM specific set of 
> > SMP ops to be used, even if it may end up calling into PSCI.
> > 
> > But the important point is that we don't know beforehand what to use, 
> > especially with a kernel that can boot on multiple different VExpress 
> > configurations.  The decision has to be made at run time, and therefore 
> > a static default or mdesc->smp ops doesn't cut it.
> 
> I certainly like the principle and I am in favor of anything that moves
> the decisions at runtime. I have pulled the patch in the series, it's
> going to be in the next version.
> 
> However I am concerned that these platform specific operations won't
> work with Xen at all.
> I am getting increasingly certain that we need a Xen specific check in
> setup_arch to bump up of the priority of PSCI over anything else if Xen
> is running. 

I'm concerned about mixing big.LITTLE and Xen as well.  I don't think 
this is going to make an easy match.  KVM might have an easier fit here.

But, in any case, even if the MCPM layer gets involved, if Xen is there 
then PSCI will end up being the ultimate interface anyway.

But let's cross that bridge when we get to it.  For now this is still a 
non existing problem.


Nicolas


From stefano.stabellini at eu.citrix.com  Tue Apr  2 12:16:03 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Tue, 2 Apr 2013 17:16:03 +0100
Subject: [PATCH 0/3 v5] arm: introduce psci_smp_ops and use them on Xen
Message-ID: <alpine.DEB.2.02.1304021700380.5078@kaball.uk.xensource.com>

Hi all,
this is the fifth version of the patch series to move virt_smp_ops out of
mach-virt and make it a generic set of reusable PSCI based smp_ops.
I added a patch to introduce smp_init to this series.
In the last patch I am using smp_init to switch to psci_smp_ops if Xen
is detected on the platform.


Jon Medhurst (1):
      ARM: Enable selection of SMP operations at boot time

Stefano Stabellini (2):
      arm: introduce psci_smp_ops
      xen/arm: introduce xen_early_init, use PSCI on xen

 arch/arm/Kconfig                      |    1 +
 arch/arm/include/asm/mach/arch.h      |    3 +
 arch/arm/include/asm/psci.h           |   29 ++++++++++++++
 arch/arm/include/asm/xen/hypervisor.h |    6 +++
 arch/arm/kernel/Makefile              |    5 ++-
 arch/arm/kernel/psci.c                |    7 +--
 arch/arm/kernel/psci_smp.c            |   67 +++++++++++++++++++++++++++++++++
 arch/arm/kernel/setup.c               |   12 +++++-
 arch/arm/mach-virt/Makefile           |    1 -
 arch/arm/mach-virt/platsmp.c          |   58 ----------------------------
 arch/arm/mach-virt/virt.c             |    3 -
 arch/arm/xen/enlighten.c              |   27 ++++++++++---
 12 files changed, 144 insertions(+), 75 deletions(-)


A branch based on "xen/arm: move to mach-virt and support SMP" and
3.9-rc3 is available here:

git://xenbits.xen.org/people/sstabellini/linux-pvhvm.git 3.9-rc3-smp-5


Cheers,

Stefano


From stefano.stabellini at eu.citrix.com  Tue Apr  2 12:16:13 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Tue, 2 Apr 2013 17:16:13 +0100
Subject: [PATCH v5 2/3] ARM: Enable selection of SMP operations at boot time
In-Reply-To: <alpine.DEB.2.02.1304021700380.5078@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1304021700380.5078@kaball.uk.xensource.com>
Message-ID: <1364919374-7836-2-git-send-email-stefano.stabellini@eu.citrix.com>

From: Jon Medhurst <tixy at linaro.org>

Add a new 'smp_init' hook to machine_desc so platforms can specify a
function to be used to setup smp ops instead of having a statically
defined value.

Signed-off-by: Jon Medhurst <tixy at linaro.org>
Signed-off-by: Nicolas Pitre <nicolas.pitre at linaro.org>
Reviewed-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
---
 arch/arm/include/asm/mach/arch.h |    3 +++
 arch/arm/kernel/setup.c          |    4 +++-
 2 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/arch/arm/include/asm/mach/arch.h b/arch/arm/include/asm/mach/arch.h
index 308ad7d..c01bf53 100644
--- a/arch/arm/include/asm/mach/arch.h
+++ b/arch/arm/include/asm/mach/arch.h
@@ -16,8 +16,10 @@ struct pt_regs;
 struct smp_operations;
 #ifdef CONFIG_SMP
 #define smp_ops(ops) (&(ops))
+#define smp_init_ops(ops) (&(ops))
 #else
 #define smp_ops(ops) (struct smp_operations *)NULL
+#define smp_init_ops(ops) (void (*)(void))NULL
 #endif
 
 struct machine_desc {
@@ -41,6 +43,7 @@ struct machine_desc {
 	unsigned char		reserve_lp2 :1;	/* never has lp2	*/
 	char			restart_mode;	/* default restart mode	*/
 	struct smp_operations	*smp;		/* SMP operations	*/
+	void			(*smp_init)(void);
 	void			(*fixup)(struct tag *, char **,
 					 struct meminfo *);
 	void			(*reserve)(void);/* reserve mem blocks	*/
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 341efaa..7e193df 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -770,7 +770,9 @@ void __init setup_arch(char **cmdline_p)
 	psci_init();
 #ifdef CONFIG_SMP
 	if (is_smp()) {
-		if (mdesc->smp)
+		if (mdesc->smp_init)
+			(*mdesc->smp_init)();
+		else if (mdesc->smp)
 			smp_set_ops(mdesc->smp);
 		else if (psci_smp_available())
 			smp_set_ops(&psci_smp_ops);
-- 
1.7.2.5



From stefano.stabellini at eu.citrix.com  Tue Apr  2 12:16:14 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Tue, 2 Apr 2013 17:16:14 +0100
Subject: [PATCH v5 3/3] xen/arm: introduce xen_early_init, use PSCI on xen
In-Reply-To: <alpine.DEB.2.02.1304021700380.5078@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1304021700380.5078@kaball.uk.xensource.com>
Message-ID: <1364919374-7836-3-git-send-email-stefano.stabellini@eu.citrix.com>

Split xen_guest_init in two functions, one of them (xen_early_init) is
going to be called very early from setup_arch.

Change machine_desc->smp_init to xen_smp_init if Xen is present on the
platform. xen_smp_init just sets smp_ops to psci_smp_ops.

Introduce a dependency for ARM_PSCI in XEN.

Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
---
 arch/arm/Kconfig                      |    1 +
 arch/arm/include/asm/xen/hypervisor.h |    6 ++++++
 arch/arm/kernel/setup.c               |    3 +++
 arch/arm/xen/enlighten.c              |   27 ++++++++++++++++++++-------
 4 files changed, 30 insertions(+), 7 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 2c3bdce..66658d3 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1891,6 +1891,7 @@ config XEN
 	bool "Xen guest support on ARM (EXPERIMENTAL)"
 	depends on ARM && AEABI && OF
 	depends on CPU_V7 && !CPU_V6
+	depends on ARM_PSCI
 	depends on !GENERIC_ATOMIC64
 	help
 	  Say Y if you want to run Linux in a Virtual Machine on Xen on ARM.
diff --git a/arch/arm/include/asm/xen/hypervisor.h b/arch/arm/include/asm/xen/hypervisor.h
index d7ab99a..17b3ea2 100644
--- a/arch/arm/include/asm/xen/hypervisor.h
+++ b/arch/arm/include/asm/xen/hypervisor.h
@@ -16,4 +16,10 @@ static inline enum paravirt_lazy_mode paravirt_get_lazy_mode(void)
 	return PARAVIRT_LAZY_NONE;
 }
 
+#ifdef CONFIG_XEN
+void xen_early_init(void);
+#else
+static inline void xen_early_init(void) { return; }
+#endif
+
 #endif /* _ASM_ARM_XEN_HYPERVISOR_H */
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 7e193df..67d911f 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -55,6 +55,8 @@
 #include <asm/unwind.h>
 #include <asm/memblock.h>
 #include <asm/virt.h>
+#include <asm/xen/hypervisor.h>
+#include <xen/xen.h>
 
 #include "atags.h"
 #include "tcm.h"
@@ -768,6 +770,7 @@ void __init setup_arch(char **cmdline_p)
 
 	arm_dt_init_cpu_maps();
 	psci_init();
+	xen_early_init();
 #ifdef CONFIG_SMP
 	if (is_smp()) {
 		if (mdesc->smp_init)
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index b002822..ee09357 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -11,6 +11,8 @@
 #include <xen/xenbus.h>
 #include <xen/page.h>
 #include <xen/xen-ops.h>
+#include <asm/mach/arch.h>
+#include <asm/psci.h>
 #include <asm/xen/hypervisor.h>
 #include <asm/xen/hypercall.h>
 #include <linux/interrupt.h>
@@ -176,27 +178,30 @@ static int __init xen_secondary_init(unsigned int cpu)
 	return 0;
 }
 
+static void __init xen_smp_init(void)
+{
+	if (psci_smp_available())
+		smp_set_ops(&psci_smp_ops);
+}
+
 /*
  * see Documentation/devicetree/bindings/arm/xen.txt for the
  * documentation of the Xen Device Tree format.
  */
 #define GRANT_TABLE_PHYSADDR 0
-static int __init xen_guest_init(void)
+void __init xen_early_init(void)
 {
-	struct xen_add_to_physmap xatp;
-	static struct shared_info *shared_info_page = 0;
 	struct device_node *node;
 	int len;
 	const char *s = NULL;
 	const char *version = NULL;
 	const char *xen_prefix = "xen,xen-";
 	struct resource res;
-	int i;
 
 	node = of_find_compatible_node(NULL, NULL, "xen,xen");
 	if (!node) {
 		pr_debug("No Xen support\n");
-		return 0;
+		return;
 	}
 	s = of_get_property(node, "compatible", &len);
 	if (strlen(xen_prefix) + 3  < len &&
@@ -204,15 +209,23 @@ static int __init xen_guest_init(void)
 		version = s + strlen(xen_prefix);
 	if (version == NULL) {
 		pr_debug("Xen version not found\n");
-		return 0;
+		return;
 	}
 	if (of_address_to_resource(node, GRANT_TABLE_PHYSADDR, &res))
-		return 0;
+		return;
 	xen_hvm_resume_frames = res.start >> PAGE_SHIFT;
 	xen_events_irq = irq_of_parse_and_map(node, 0);
 	pr_info("Xen %s support found, events_irq=%d gnttab_frame_pfn=%lx\n",
 			version, xen_events_irq, xen_hvm_resume_frames);
 	xen_domain_type = XEN_HVM_DOMAIN;
+	machine_desc->smp_init = xen_smp_init;
+}
+
+static int __init xen_guest_init(void)
+{
+	struct xen_add_to_physmap xatp;
+	static struct shared_info *shared_info_page = 0;
+	int i;
 
 	xen_setup_features();
 	if (xen_feature(XENFEAT_dom0))
-- 
1.7.2.5



From stefano.stabellini at eu.citrix.com  Tue Apr  2 12:16:12 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Tue, 2 Apr 2013 17:16:12 +0100
Subject: [PATCH v5 1/3] arm: introduce psci_smp_ops
In-Reply-To: <alpine.DEB.2.02.1304021700380.5078@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1304021700380.5078@kaball.uk.xensource.com>
Message-ID: <1364919374-7836-1-git-send-email-stefano.stabellini@eu.citrix.com>

Rename virt_smp_ops to psci_smp_ops and move them to arch/arm/kernel/psci_smp.c.
Remove mach-virt/platsmp.c, now unused.
Compile psci_smp if CONFIG_ARM_PSCI and CONFIG_SMP.

Add a cpu_die smp_op based on psci_ops.cpu_off.

Initialize PSCI before setting smp_ops in setup_arch.
Use psci_smp_ops if the platform doesn't provide its own smp_ops.


Changes in v5:
- document psci_operations;
- psci_init returns NULL.


Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
Acked-by: Nicolas Pitre <nico at linaro.org>
Acked-by: Rob Herring <rob.herring at calxeda.com>

CC: will.deacon at arm.com
CC: arnd at arndb.de
CC: marc.zyngier at arm.com
CC: linux at arm.linux.org.uk
CC: nico at linaro.org
---
 arch/arm/include/asm/psci.h  |   29 ++++++++++++++++++
 arch/arm/kernel/Makefile     |    5 ++-
 arch/arm/kernel/psci.c       |    7 ++--
 arch/arm/kernel/psci_smp.c   |   67 ++++++++++++++++++++++++++++++++++++++++++
 arch/arm/kernel/setup.c      |    7 ++++-
 arch/arm/mach-virt/Makefile  |    1 -
 arch/arm/mach-virt/platsmp.c |   58 ------------------------------------
 arch/arm/mach-virt/virt.c    |    3 --
 8 files changed, 109 insertions(+), 68 deletions(-)
 create mode 100644 arch/arm/kernel/psci_smp.c
 delete mode 100644 arch/arm/mach-virt/platsmp.c

diff --git a/arch/arm/include/asm/psci.h b/arch/arm/include/asm/psci.h
index ce0dbe7..fd94ce2 100644
--- a/arch/arm/include/asm/psci.h
+++ b/arch/arm/include/asm/psci.h
@@ -23,6 +23,26 @@ struct psci_power_state {
 	u8	affinity_level;
 };
 
+/*
+ * cpu_suspend   Suspend the execution on a CPU
+ * @state        we don't currently describe affinity levels, so just pass 0.
+ * @entry_point  the first instruction to be executed on return
+ * returns 0  success, < 0 on failure
+ *
+ * cpu_off       Power down a CPU
+ * @state        we don't currently describe affinity levels, so just pass 0.
+ * no return on successful call
+ *
+ * cpu_on        Power up a CPU
+ * @cpuid        cpuid of target CPU, as from MPIDR
+ * @entry_point  the first instruction to be executed on return
+ * returns 0  success, < 0 on failure
+ *
+ * migrate       Migrate the context to a different CPU
+ * @cpuid        cpuid of target CPU, as from MPIDR
+ * returns 0  success, < 0 on failure
+ *
+ */
 struct psci_operations {
 	int (*cpu_suspend)(struct psci_power_state state,
 			   unsigned long entry_point);
@@ -32,5 +52,14 @@ struct psci_operations {
 };
 
 extern struct psci_operations psci_ops;
+extern struct smp_operations psci_smp_ops;
+
+#ifdef CONFIG_ARM_PSCI
+void psci_init(void);
+bool psci_smp_available(void);
+#else
+static inline void psci_init(void) { return -ENODEV; }
+static inline bool psci_smp_available(void) { return false; }
+#endif
 
 #endif /* __ASM_ARM_PSCI_H */
diff --git a/arch/arm/kernel/Makefile b/arch/arm/kernel/Makefile
index 5f3338e..dd9d90a 100644
--- a/arch/arm/kernel/Makefile
+++ b/arch/arm/kernel/Makefile
@@ -82,6 +82,9 @@ obj-$(CONFIG_DEBUG_LL)	+= debug.o
 obj-$(CONFIG_EARLY_PRINTK)	+= early_printk.o
 
 obj-$(CONFIG_ARM_VIRT_EXT)	+= hyp-stub.o
-obj-$(CONFIG_ARM_PSCI)		+= psci.o
+ifeq ($(CONFIG_ARM_PSCI),y)
+obj-y				+= psci.o
+obj-$(CONFIG_SMP)		+= psci_smp.o
+endif
 
 extra-y := $(head-y) vmlinux.lds
diff --git a/arch/arm/kernel/psci.c b/arch/arm/kernel/psci.c
index 3653164..4693188 100644
--- a/arch/arm/kernel/psci.c
+++ b/arch/arm/kernel/psci.c
@@ -158,7 +158,7 @@ static const struct of_device_id psci_of_match[] __initconst = {
 	{},
 };
 
-static int __init psci_init(void)
+void __init psci_init(void)
 {
 	struct device_node *np;
 	const char *method;
@@ -166,7 +166,7 @@ static int __init psci_init(void)
 
 	np = of_find_matching_node(NULL, psci_of_match);
 	if (!np)
-		return 0;
+		return;
 
 	pr_info("probing function IDs from device-tree\n");
 
@@ -206,6 +206,5 @@ static int __init psci_init(void)
 
 out_put_node:
 	of_node_put(np);
-	return 0;
+	return;
 }
-early_initcall(psci_init);
diff --git a/arch/arm/kernel/psci_smp.c b/arch/arm/kernel/psci_smp.c
new file mode 100644
index 0000000..66b0f77
--- /dev/null
+++ b/arch/arm/kernel/psci_smp.c
@@ -0,0 +1,67 @@
+/*
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Copyright (C) 2012 ARM Limited
+ *
+ * Author: Will Deacon <will.deacon at arm.com>
+ */
+
+#include <linux/init.h>
+#include <linux/irqchip/arm-gic.h>
+#include <linux/smp.h>
+#include <linux/of.h>
+
+#include <asm/psci.h>
+#include <asm/smp_plat.h>
+
+extern void secondary_startup(void);
+
+static int __cpuinit psci_boot_secondary(unsigned int cpu,
+					 struct task_struct *idle)
+{
+	if (psci_ops.cpu_on)
+		return psci_ops.cpu_on(cpu_logical_map(cpu),
+				       __pa(secondary_startup));
+	return -ENODEV;
+}
+
+static void __cpuinit psci_secondary_init(unsigned int cpu)
+{
+	gic_secondary_init(0);
+}
+
+#ifdef CONFIG_HOTPLUG_CPU
+void __ref psci_cpu_die(unsigned int cpu)
+{
+       const struct psci_power_state ps = {
+               .type = PSCI_POWER_STATE_TYPE_POWER_DOWN,
+       };
+
+       if (psci_ops.cpu_off)
+               psci_ops.cpu_off(ps);
+
+       /* We should never return */
+       panic("psci: cpu %d failed to shutdown\n", cpu);
+}
+#else
+#define psci_cpu_die NULL
+#endif
+
+bool __init psci_smp_available(void)
+{
+	/* is cpu_on available at least? */
+	return (psci_ops.cpu_on != NULL);
+}
+
+struct smp_operations __initdata psci_smp_ops = {
+	.smp_secondary_init	= psci_secondary_init,
+	.smp_boot_secondary	= psci_boot_secondary,
+	.cpu_die		= psci_cpu_die,
+};
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 3f6cbb2..341efaa 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -36,6 +36,7 @@
 #include <asm/cputype.h>
 #include <asm/elf.h>
 #include <asm/procinfo.h>
+#include <asm/psci.h>
 #include <asm/sections.h>
 #include <asm/setup.h>
 #include <asm/smp_plat.h>
@@ -766,9 +767,13 @@ void __init setup_arch(char **cmdline_p)
 	unflatten_device_tree();
 
 	arm_dt_init_cpu_maps();
+	psci_init();
 #ifdef CONFIG_SMP
 	if (is_smp()) {
-		smp_set_ops(mdesc->smp);
+		if (mdesc->smp)
+			smp_set_ops(mdesc->smp);
+		else if (psci_smp_available())
+			smp_set_ops(&psci_smp_ops);
 		smp_init_cpus();
 	}
 #endif
diff --git a/arch/arm/mach-virt/Makefile b/arch/arm/mach-virt/Makefile
index 042afc1..7ddbfa6 100644
--- a/arch/arm/mach-virt/Makefile
+++ b/arch/arm/mach-virt/Makefile
@@ -3,4 +3,3 @@
 #
 
 obj-y					:= virt.o
-obj-$(CONFIG_SMP)			+= platsmp.o
diff --git a/arch/arm/mach-virt/platsmp.c b/arch/arm/mach-virt/platsmp.c
deleted file mode 100644
index 8badaab..0000000
--- a/arch/arm/mach-virt/platsmp.c
+++ /dev/null
@@ -1,58 +0,0 @@
-/*
- * Dummy Virtual Machine - does what it says on the tin.
- *
- * Copyright (C) 2012 ARM Ltd
- * Author: Will Deacon <will.deacon at arm.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.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program.  If not, see <http://www.gnu.org/licenses/>.
- */
-
-#include <linux/init.h>
-#include <linux/smp.h>
-#include <linux/of.h>
-
-#include <linux/irqchip/arm-gic.h>
-
-#include <asm/psci.h>
-#include <asm/smp_plat.h>
-
-extern void secondary_startup(void);
-
-static void __init virt_smp_init_cpus(void)
-{
-}
-
-static void __init virt_smp_prepare_cpus(unsigned int max_cpus)
-{
-}
-
-static int __cpuinit virt_boot_secondary(unsigned int cpu,
-					 struct task_struct *idle)
-{
-	if (psci_ops.cpu_on)
-		return psci_ops.cpu_on(cpu_logical_map(cpu),
-				       __pa(secondary_startup));
-	return -ENODEV;
-}
-
-static void __cpuinit virt_secondary_init(unsigned int cpu)
-{
-	gic_secondary_init(0);
-}
-
-struct smp_operations __initdata virt_smp_ops = {
-	.smp_init_cpus		= virt_smp_init_cpus,
-	.smp_prepare_cpus	= virt_smp_prepare_cpus,
-	.smp_secondary_init	= virt_secondary_init,
-	.smp_boot_secondary	= virt_boot_secondary,
-};
diff --git a/arch/arm/mach-virt/virt.c b/arch/arm/mach-virt/virt.c
index 528c05e..c417752 100644
--- a/arch/arm/mach-virt/virt.c
+++ b/arch/arm/mach-virt/virt.c
@@ -44,12 +44,9 @@ static const char *virt_dt_match[] = {
 	NULL
 };
 
-extern struct smp_operations virt_smp_ops;
-
 DT_MACHINE_START(VIRT, "Dummy Virtual Machine")
 	.init_irq	= irqchip_init,
 	.init_time	= virt_timer_init,
 	.init_machine	= virt_init,
-	.smp		= smp_ops(virt_smp_ops),
 	.dt_compat	= virt_dt_match,
 MACHINE_END
-- 
1.7.2.5



From arnd at arndb.de  Tue Apr  2 12:24:03 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue,  2 Apr 2013 18:24:03 +0200
Subject: [PATCH V5 5/6] USB: EHCI: make ehci-msm a separate driver
In-Reply-To: <1364919844-1726-1-git-send-email-arnd@arndb.de>
References: <1364919844-1726-1-git-send-email-arnd@arndb.de>
Message-ID: <1364919844-1726-6-git-send-email-arnd@arndb.de>

From: Manjunath Goudar <manjunath.goudar at linaro.org>

Separate the  Qualcomm QSD/MSM on-chip host controller driver from
ehci-hcd host code so that it can be built as a separate driver module.
This work is part of enabling multi-platform kernels on ARM;
however, note that other changes are still needed before Qualcomm QSD/MSM
can be booted with a multi-platform kernel, which is not expected before
3.11.

With the infrastructure added by Alan Stern in patch 3e0232039
"USB: EHCI: prepare to make ehci-hcd a library module", we can
avoid this problem by turning a bus glue into a separate
module, as we do here for the msm bus glue.

In V5 (arnd):
 - add FIXME about missing usb_add_hcd() or usb_remove_hcd() calls

In V3:
 - Detailed commit message added here describing why this patch is required.
 - Arranged  #include's in alphabetical order.
 - driver.name initialized hcd_name[] = "ehci-msm" in platform_driver
   structure initialization instead of "msm-ehci", which was the reason
   why it broke in EHCI USB testing

In V2:
Tegra patch related changes removed from this patch.

Signed-off-by: Manjunath Goudar <manjunath.goudar at linaro.org>
Acked-by: Alan Stern <stern at rowland.harvard.edu>
Acked-by: David Brown <davidb at codeaurora.org>
Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 drivers/usb/host/Kconfig    |  2 +-
 drivers/usb/host/Makefile   |  1 +
 drivers/usb/host/ehci-hcd.c |  6 +--
 drivers/usb/host/ehci-msm.c | 89 +++++++++++++++++++++------------------------
 4 files changed, 44 insertions(+), 54 deletions(-)

diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index f6f7872..b9cdbbb 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -191,7 +191,7 @@ config USB_EHCI_HCD_AT91
           Atmel chips.
 
 config USB_EHCI_MSM
-	bool "Support for MSM on-chip EHCI USB controller"
+	tristate "Support for Qualcomm QSD/MSM on-chip EHCI USB controller"
 	depends on USB_EHCI_HCD && ARCH_MSM
 	select USB_EHCI_ROOT_HUB_TT
 	select USB_MSM_OTG
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 368d3eb..4fb73c1 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -32,6 +32,7 @@ obj-$(CONFIG_USB_EHCI_HCD_ORION)	+= ehci-orion.o
 obj-$(CONFIG_USB_EHCI_HCD_SPEAR)	+= ehci-spear.o
 obj-$(CONFIG_USB_EHCI_S5P)	+= ehci-s5p.o
 obj-$(CONFIG_USB_EHCI_HCD_AT91) += ehci-atmel.o
+obj-$(CONFIG_USB_EHCI_MSM)	+= ehci-msm.o
 
 obj-$(CONFIG_USB_OXU210HP_HCD)	+= oxu210hp-hcd.o
 obj-$(CONFIG_USB_ISP116X_HCD)	+= isp116x-hcd.o
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index ccc78ab..2e0c2bd 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -1259,11 +1259,6 @@ MODULE_LICENSE ("GPL");
 #define PLATFORM_DRIVER		ehci_octeon_driver
 #endif
 
-#ifdef CONFIG_USB_EHCI_MSM
-#include "ehci-msm.c"
-#define PLATFORM_DRIVER		ehci_msm_driver
-#endif
-
 #ifdef CONFIG_TILE_USB
 #include "ehci-tilegx.c"
 #define	PLATFORM_DRIVER		ehci_hcd_tilegx_driver
@@ -1303,6 +1298,7 @@ MODULE_LICENSE ("GPL");
 	!IS_ENABLED(CONFIG_USB_EHCI_HCD_SPEAR) && \
 	!IS_ENABLED(CONFIG_USB_EHCI_S5P) && \
 	!IS_ENABLED(CONFIG_USB_EHCI_HCD_AT91) && \
+	!IS_ENABLED(CONFIG_USB_EHCI_MSM) && \
 	!defined(PLATFORM_DRIVER) && \
 	!defined(PS3_SYSTEM_BUS_DRIVER) && \
 	!defined(OF_PLATFORM_DRIVER) && \
diff --git a/drivers/usb/host/ehci-msm.c b/drivers/usb/host/ehci-msm.c
index 88a49c8..93f062c 100644
--- a/drivers/usb/host/ehci-msm.c
+++ b/drivers/usb/host/ehci-msm.c
@@ -22,16 +22,26 @@
  * along with this program; if not, you can find it at http://www.fsf.org
  */
 
-#include <linux/platform_device.h>
 #include <linux/clk.h>
 #include <linux/err.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
 #include <linux/pm_runtime.h>
-
 #include <linux/usb/otg.h>
 #include <linux/usb/msm_hsusb_hw.h>
+#include <linux/usb.h>
+#include <linux/usb/hcd.h>
+
+#include "ehci.h"
 
 #define MSM_USB_BASE (hcd->regs)
 
+#define DRIVER_DESC "Qualcomm On-Chip EHCI Host Controller"
+
+static const char hcd_name[] = "ehci-msm";
+static struct hc_driver __read_mostly msm_hc_driver;
 static struct usb_phy *phy;
 
 static int ehci_msm_reset(struct usb_hcd *hcd)
@@ -56,52 +66,6 @@ static int ehci_msm_reset(struct usb_hcd *hcd)
 	return 0;
 }
 
-static struct hc_driver msm_hc_driver = {
-	.description		= hcd_name,
-	.product_desc		= "Qualcomm On-Chip EHCI Host Controller",
-	.hcd_priv_size		= sizeof(struct ehci_hcd),
-
-	/*
-	 * generic hardware linkage
-	 */
-	.irq			= ehci_irq,
-	.flags			= HCD_USB2 | HCD_MEMORY,
-
-	.reset			= ehci_msm_reset,
-	.start			= ehci_run,
-
-	.stop			= ehci_stop,
-	.shutdown		= ehci_shutdown,
-
-	/*
-	 * managing i/o requests and associated device resources
-	 */
-	.urb_enqueue		= ehci_urb_enqueue,
-	.urb_dequeue		= ehci_urb_dequeue,
-	.endpoint_disable	= ehci_endpoint_disable,
-	.endpoint_reset		= ehci_endpoint_reset,
-	.clear_tt_buffer_complete = ehci_clear_tt_buffer_complete,
-
-	/*
-	 * scheduling support
-	 */
-	.get_frame_number	= ehci_get_frame,
-
-	/*
-	 * root hub support
-	 */
-	.hub_status_data	= ehci_hub_status_data,
-	.hub_control		= ehci_hub_control,
-	.relinquish_port	= ehci_relinquish_port,
-	.port_handed_over	= ehci_port_handed_over,
-
-	/*
-	 * PM support
-	 */
-	.bus_suspend		= ehci_bus_suspend,
-	.bus_resume		= ehci_bus_resume,
-};
-
 static int ehci_msm_probe(struct platform_device *pdev)
 {
 	struct usb_hcd *hcd;
@@ -165,6 +129,8 @@ static int ehci_msm_probe(struct platform_device *pdev)
 	pm_runtime_no_callbacks(&pdev->dev);
 	pm_runtime_enable(&pdev->dev);
 
+	/* FIXME: need to call usb_add_hcd() here? */
+
 	return 0;
 
 put_hcd:
@@ -183,6 +149,8 @@ static int ehci_msm_remove(struct platform_device *pdev)
 
 	otg_set_host(phy->otg, NULL);
 
+	/* FIXME: need to call usb_remove_hcd() here? */
+
 	usb_put_hcd(hcd);
 
 	return 0;
@@ -226,3 +194,28 @@ static struct platform_driver ehci_msm_driver = {
 		   .pm = &ehci_msm_dev_pm_ops,
 	},
 };
+
+static const struct ehci_driver_overrides msm_overrides __initdata = {
+	.reset = ehci_msm_reset,
+};
+
+static int __init ehci_msm_init(void)
+{
+	if (usb_disabled())
+		return -ENODEV;
+
+	pr_info("%s: " DRIVER_DESC "\n", hcd_name);
+	ehci_init_driver(&msm_hc_driver, &msm_overrides);
+	return platform_driver_register(&ehci_msm_driver);
+}
+module_init(ehci_msm_init);
+
+static void __exit ehci_msm_cleanup(void)
+{
+	platform_driver_unregister(&ehci_msm_driver);
+}
+module_exit(ehci_msm_cleanup);
+
+MODULE_DESCRIPTION(DRIVER_DESC);
+MODULE_ALIAS("platform:msm-ehci");
+MODULE_LICENSE("GPL");
-- 
1.8.1.2



From arnd at arndb.de  Tue Apr  2 12:23:58 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue,  2 Apr 2013 18:23:58 +0200
Subject: [PATCH V5 0/6] USB: EHCI multiplatform for 3.10
Message-ID: <1364919844-1726-1-git-send-email-arnd@arndb.de>

Hi Greg,

Here are the EHCI patches that I think are good for inclusion in 3.10,
I hope you are willing to include them after the debacle over these
patches in 3.9.

The patches are all logically independent but sorted by priority,
so decide for yourself how many you want to take, starting at the
first one. The first six patches all have an Ack from Alan Stern
and from the respective ARM platform maintainers.

* The first patch (Orion) fixes a preexisting bug because the driver
  conflicts with the OMAP and vt8500 back-ends in 3.9. Both of those
  are fixed in usb-next now, but the same problem comes back with
  any other platform we enable for ARM multiplatform support.
* The second patch fixes a problem that will happen in 3.10 as we
  enable SPEAr multiplatform support.
* S5P/Exynos multiplatform support is not yet part of linux-next, but
  I still have hope for 3.10, so the third patch will be needed as well
  then.
* The ehci-atmel patch will not be needed in 3.10 but quite likely
  in 3.11.
* I have no time line for MSM multiplatform support, but we will
  get there eventually and the driver is broken already so there
  is no risk of regressions.
* The final patch is from me and still waiting for an Ack from Alan
  Stern, so please wait for his feedback before applying that one.

There is one more patch coming for ehci-tegra. I've forwarded
Manjunath's work on that driver to the Tegra developers, who
will test it and send it directly to you. The version I had was
incomplete.

	Arnd

Arnd Bergmann (1):
  USB: OHCI: avoid conflicting platform drivers

Manjunath Goudar (5):
  USB: EHCI: make ehci-orion a separate driver
  USB: EHCI: make ehci-spear a separate driver
  USB: EHCI: make ehci-s5p a separate driver
  USB: EHCI: make ehci-atmel a separate driver
  USB: EHCI: make ehci-msm a separate driver

 drivers/usb/host/Kconfig      |  40 +++++++++--
 drivers/usb/host/Makefile     |   5 ++
 drivers/usb/host/ehci-atmel.c |  88 +++++++++++------------
 drivers/usb/host/ehci-hcd.c   |  30 ++------
 drivers/usb/host/ehci-msm.c   |  89 +++++++++++------------
 drivers/usb/host/ehci-orion.c |  82 +++++++++------------
 drivers/usb/host/ehci-s5p.c   | 164 +++++++++++++++++++++---------------------
 drivers/usb/host/ehci-spear.c | 115 +++++++++++++----------------
 drivers/usb/host/ohci-hcd.c   | 136 ++++++++++++++++++++++++++++++-----
 9 files changed, 412 insertions(+), 337 deletions(-)

-- 
1.8.1.2



From arnd at arndb.de  Tue Apr  2 12:24:04 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue,  2 Apr 2013 18:24:04 +0200
Subject: [PATCH V5 6/6] USB: OHCI: avoid conflicting platform drivers
In-Reply-To: <1364919844-1726-1-git-send-email-arnd@arndb.de>
References: <1364919844-1726-1-git-send-email-arnd@arndb.de>
Message-ID: <1364919844-1726-7-git-send-email-arnd@arndb.de>

Like the EHCI driver, OHCI supports a large number of different platform
glue drivers by directly including them, which causes problems with
conflicting macro definitions in some cases. As more ARM architecture
specific back-ends are required to coexist in a single build, we should
split those out into separate drivers. Unfortunately, the infrastructure
for that is still under development, so to give us more time, this uses
a separate *_PLATFORM_DRIVER macro for each ARM specific OHCI backend,
just like we already do on PowerPC and some of the other ARM platforms.

In linux-3.10, only the SPEAr and CNS3xxx back-ends would actually conflict
without this patch, but over time we would get more of them, so this
is a way to avoid having to patch the driver every time it breaks. We
should still split out all back-ends into separate loadable modules,
but that work is only needed to improve code size and cleanliness after
this patch, not for correctness.

While we're here, this fixes the incorrectly sorted error path
for the OMAP1 and OMAP3 backends to ensure we always unregister
the exact set of drivers that were registered before erroring out.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 drivers/usb/host/ohci-hcd.c | 136 ++++++++++++++++++++++++++++++++++++++------
 1 file changed, 118 insertions(+), 18 deletions(-)

diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
index 180a2b0..9e6de95 100644
--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -1102,12 +1102,12 @@ MODULE_LICENSE ("GPL");
 
 #if defined(CONFIG_ARCH_S3C24XX) || defined(CONFIG_ARCH_S3C64XX)
 #include "ohci-s3c2410.c"
-#define PLATFORM_DRIVER		ohci_hcd_s3c2410_driver
+#define S3C2410_PLATFORM_DRIVER	ohci_hcd_s3c2410_driver
 #endif
 
 #ifdef CONFIG_USB_OHCI_EXYNOS
 #include "ohci-exynos.c"
-#define PLATFORM_DRIVER		exynos_ohci_driver
+#define EXYNOS_PLATFORM_DRIVER	exynos_ohci_driver
 #endif
 
 #ifdef CONFIG_USB_OHCI_HCD_OMAP1
@@ -1127,25 +1127,24 @@ MODULE_LICENSE ("GPL");
 
 #ifdef CONFIG_ARCH_EP93XX
 #include "ohci-ep93xx.c"
-#define PLATFORM_DRIVER		ohci_hcd_ep93xx_driver
+#define EP93XX_PLATFORM_DRIVER	ohci_hcd_ep93xx_driver
 #endif
 
 #ifdef CONFIG_ARCH_AT91
 #include "ohci-at91.c"
-#define PLATFORM_DRIVER		ohci_hcd_at91_driver
+#define AT91_PLATFORM_DRIVER	ohci_hcd_at91_driver
 #endif
 
 #ifdef CONFIG_ARCH_LPC32XX
 #include "ohci-nxp.c"
-#define PLATFORM_DRIVER		usb_hcd_nxp_driver
+#define NXP_PLATFORM_DRIVER	usb_hcd_nxp_driver
 #endif
 
 #ifdef CONFIG_ARCH_DAVINCI_DA8XX
 #include "ohci-da8xx.c"
-#define PLATFORM_DRIVER		ohci_hcd_da8xx_driver
+#define DAVINCI_PLATFORM_DRIVER	ohci_hcd_da8xx_driver
 #endif
 
-
 #ifdef CONFIG_USB_OHCI_HCD_PPC_OF
 #include "ohci-ppc-of.c"
 #define OF_PLATFORM_DRIVER	ohci_hcd_ppc_of_driver
@@ -1153,7 +1152,7 @@ MODULE_LICENSE ("GPL");
 
 #ifdef CONFIG_PLAT_SPEAR
 #include "ohci-spear.c"
-#define PLATFORM_DRIVER		spear_ohci_hcd_driver
+#define SPEAR_PLATFORM_DRIVER	spear_ohci_hcd_driver
 #endif
 
 #ifdef CONFIG_PPC_PS3
@@ -1199,7 +1198,14 @@ MODULE_LICENSE ("GPL");
 	!defined(SA1111_DRIVER) &&	\
 	!defined(PS3_SYSTEM_BUS_DRIVER) && \
 	!defined(SM501_OHCI_DRIVER) && \
-	!defined(TMIO_OHCI_DRIVER)
+	!defined(TMIO_OHCI_DRIVER) && \
+	!defined(S3C2410_PLATFORM_DRIVER) && \
+	!defined(EXYNOS_PLATFORM_DRIVER) && \
+	!defined(EP93XX_PLATFORM_DRIVER) && \
+	!defined(AT91_PLATFORM_DRIVER) && \
+	!defined(NXP_PLATFORM_DRIVER) && \
+	!defined(DAVINCI_PLATFORM_DRIVER) && \
+	!defined(SPEAR_PLATFORM_DRIVER)
 #error "missing bus glue for ohci-hcd"
 #endif
 
@@ -1277,9 +1283,79 @@ static int __init ohci_hcd_mod_init(void)
 		goto error_tmio;
 #endif
 
+#ifdef S3C2410_PLATFORM_DRIVER
+	retval = platform_driver_register(&S3C2410_PLATFORM_DRIVER);
+	if (retval < 0)
+		goto error_s3c2410;
+#endif
+
+#ifdef EXYNOS_PLATFORM_DRIVER
+	retval = platform_driver_register(&EXYNOS_PLATFORM_DRIVER);
+	if (retval < 0)
+		goto error_exynos;
+#endif
+
+#ifdef EP93XX_PLATFORM_DRIVER
+	retval = platform_driver_register(&EP93XX_PLATFORM_DRIVER);
+	if (retval < 0)
+		goto error_ep93xx;
+#endif
+
+#ifdef AT91_PLATFORM_DRIVER
+	retval = platform_driver_register(&AT91_PLATFORM_DRIVER);
+	if (retval < 0)
+		goto error_at91;
+#endif
+
+#ifdef NXP_PLATFORM_DRIVER
+	retval = platform_driver_register(&NXP_PLATFORM_DRIVER);
+	if (retval < 0)
+		goto error_nxp;
+#endif
+
+#ifdef DAVINCI_PLATFORM_DRIVER
+	retval = platform_driver_register(&DAVINCI_PLATFORM_DRIVER);
+	if (retval < 0)
+		goto error_davinci;
+#endif
+
+#ifdef SPEAR_PLATFORM_DRIVER
+	retval = platform_driver_register(&SPEAR_PLATFORM_DRIVER);
+	if (retval < 0)
+		goto error_spear;
+#endif
+
 	return retval;
 
 	/* Error path */
+#ifdef SPEAR_PLATFORM_DRIVER
+	platform_driver_unregister(&SPEAR_PLATFORM_DRIVER);
+ error_spear:
+#endif
+#ifdef DAVINCI_PLATFORM_DRIVER
+	platform_driver_unregister(&DAVINCI_PLATFORM_DRIVER);
+ error_davinci:
+#endif
+#ifdef NXP_PLATFORM_DRIVER
+	platform_driver_unregister(&NXP_PLATFORM_DRIVER);
+ error_nxp:
+#endif
+#ifdef AT91_PLATFORM_DRIVER
+	platform_driver_unregister(&AT91_PLATFORM_DRIVER);
+ error_at91:
+#endif
+#ifdef EP93XX_PLATFORM_DRIVER
+	platform_driver_unregister(&EP93XX_PLATFORM_DRIVER);
+ error_ep93xx:
+#endif
+#ifdef EXYNOS_PLATFORM_DRIVER
+	platform_driver_unregister(&EXYNOS_PLATFORM_DRIVER);
+ error_exynos:
+#endif
+#ifdef S3C2410_PLATFORM_DRIVER
+	platform_driver_unregister(&S3C2410_PLATFORM_DRIVER);
+ error_s3c2410:
+#endif
 #ifdef TMIO_OHCI_DRIVER
 	platform_driver_unregister(&TMIO_OHCI_DRIVER);
  error_tmio:
@@ -1300,17 +1376,17 @@ static int __init ohci_hcd_mod_init(void)
 	platform_driver_unregister(&OF_PLATFORM_DRIVER);
  error_of_platform:
 #endif
-#ifdef PLATFORM_DRIVER
-	platform_driver_unregister(&PLATFORM_DRIVER);
- error_platform:
+#ifdef OMAP3_PLATFORM_DRIVER
+	platform_driver_unregister(&OMAP3_PLATFORM_DRIVER);
+ error_omap3_platform:
 #endif
 #ifdef OMAP1_PLATFORM_DRIVER
 	platform_driver_unregister(&OMAP1_PLATFORM_DRIVER);
  error_omap1_platform:
 #endif
-#ifdef OMAP3_PLATFORM_DRIVER
-	platform_driver_unregister(&OMAP3_PLATFORM_DRIVER);
- error_omap3_platform:
+#ifdef PLATFORM_DRIVER
+	platform_driver_unregister(&PLATFORM_DRIVER);
+ error_platform:
 #endif
 #ifdef PS3_SYSTEM_BUS_DRIVER
 	ps3_ohci_driver_unregister(&PS3_SYSTEM_BUS_DRIVER);
@@ -1329,6 +1405,27 @@ module_init(ohci_hcd_mod_init);
 
 static void __exit ohci_hcd_mod_exit(void)
 {
+#ifdef SPEAR_PLATFORM_DRIVER
+	platform_driver_unregister(&SPEAR_PLATFORM_DRIVER);
+#endif
+#ifdef DAVINCI_PLATFORM_DRIVER
+	platform_driver_unregister(&DAVINCI_PLATFORM_DRIVER);
+#endif
+#ifdef NXP_PLATFORM_DRIVER
+	platform_driver_unregister(&NXP_PLATFORM_DRIVER);
+#endif
+#ifdef AT91_PLATFORM_DRIVER
+	platform_driver_unregister(&AT91_PLATFORM_DRIVER);
+#endif
+#ifdef EP93XX_PLATFORM_DRIVER
+	platform_driver_unregister(&EP93XX_PLATFORM_DRIVER);
+#endif
+#ifdef EXYNOS_PLATFORM_DRIVER
+	platform_driver_unregister(&EXYNOS_PLATFORM_DRIVER);
+#endif
+#ifdef S3C2410_PLATFORM_DRIVER
+	platform_driver_unregister(&S3C2410_PLATFORM_DRIVER);
+#endif
 #ifdef TMIO_OHCI_DRIVER
 	platform_driver_unregister(&TMIO_OHCI_DRIVER);
 #endif
@@ -1344,12 +1441,15 @@ static void __exit ohci_hcd_mod_exit(void)
 #ifdef OF_PLATFORM_DRIVER
 	platform_driver_unregister(&OF_PLATFORM_DRIVER);
 #endif
-#ifdef PLATFORM_DRIVER
-	platform_driver_unregister(&PLATFORM_DRIVER);
-#endif
 #ifdef OMAP3_PLATFORM_DRIVER
 	platform_driver_unregister(&OMAP3_PLATFORM_DRIVER);
 #endif
+#ifdef OMAP1_PLATFORM_DRIVER
+	platform_driver_unregister(&OMAP1_PLATFORM_DRIVER);
+#endif
+#ifdef PLATFORM_DRIVER
+	platform_driver_unregister(&PLATFORM_DRIVER);
+#endif
 #ifdef PS3_SYSTEM_BUS_DRIVER
 	ps3_ohci_driver_unregister(&PS3_SYSTEM_BUS_DRIVER);
 #endif
-- 
1.8.1.2



From arnd at arndb.de  Tue Apr  2 12:24:00 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue,  2 Apr 2013 18:24:00 +0200
Subject: [PATCH V5 2/6] USB: EHCI: make ehci-spear a separate driver
In-Reply-To: <1364919844-1726-1-git-send-email-arnd@arndb.de>
References: <1364919844-1726-1-git-send-email-arnd@arndb.de>
Message-ID: <1364919844-1726-3-git-send-email-arnd@arndb.de>

From: Manjunath Goudar <manjunath.goudar at linaro.org>

Separate the SPEAr host controller driver from ehci-hcd host code
so that it can be built as a separate driver module.
This work is part of enabling multi-platform kernels on ARM;
however, note that other changes are still needed before SPEAr can be
booted with a multi-platform kernel, but they are queued in the
arm-soc tree for 3.10.

With the infrastructure added by Alan Stern in patch 3e0232039
"USB: EHCI: prepare to make ehci-hcd a library module", we can
avoid this problem by turning a bus glue into a separate
module, as we do here for the SPEAr bus glue.

In V4 (arnd):
 - renamed all 'struct spear_ehci' pointers from 'ehci' to the
   less ambiguous 'sehci'.
 - folded trivial spear_start_ehci/spear_stop_ehci functions into
   callers.
 - brought back initialization of ehci->caps.

In V3:
 - Detailed commit message added here about why this patch is required.
 - Eliminated ehci_spear_setup routine because hcd registers can
   be directly set in the spear_ehci_hcd_drv_probe function.
 - spear_overrides struct initialized.
 - Converted to using .extra_priv_size for allocating spear_ehci,
   and updated all users of that structure.
 - to_spear_ehci() macro modified for spear_ehci.

In V2:
 - Replaced spear as SPEAr everywhere, leaving functions/variables/config options.

Signed-off-by: Deepak Saxena <dsaxena at linaro.org>
Signed-off-by: Manjunath Goudar <manjunath.goudar at linaro.org>
Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Acked-by: Viresh Kumar <viresh.linux at gmail.com>
Acked-by: Alan Stern <stern at rowland.harvard.edu>
Cc: Shiraz Hashim <shiraz.hashim at st.com>
Cc: spear-devel at list.st.com
---
 drivers/usb/host/Kconfig      |   8 +++
 drivers/usb/host/Makefile     |   1 +
 drivers/usb/host/ehci-hcd.c   |   6 +--
 drivers/usb/host/ehci-spear.c | 115 +++++++++++++++++++-----------------------
 4 files changed, 61 insertions(+), 69 deletions(-)

diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index e5649c1..4723f79 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -174,6 +174,14 @@ config USB_EHCI_HCD_ORION
 	  on Marvell's mobile PXA and MMP SoC, see "EHCI support for
 	  Marvell PXA/MMP USB controller" for those.
 
+config USB_EHCI_HCD_SPEAR
+        tristate "Support for ST SPEAr on-chip EHCI USB controller"
+        depends on USB_EHCI_HCD && PLAT_SPEAR
+        default y
+        ---help---
+          Enables support for the on-chip EHCI controller on
+          ST SPEAr chips.
+
 config USB_EHCI_MSM
 	bool "Support for MSM on-chip EHCI USB controller"
 	depends on USB_EHCI_HCD && ARCH_MSM
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 9492f50..3e02471 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -29,6 +29,7 @@ obj-$(CONFIG_USB_EHCI_HCD_PLATFORM)	+= ehci-platform.o
 obj-$(CONFIG_USB_EHCI_MXC)	+= ehci-mxc.o
 obj-$(CONFIG_USB_EHCI_HCD_OMAP)	+= ehci-omap.o
 obj-$(CONFIG_USB_EHCI_HCD_ORION)	+= ehci-orion.o
+obj-$(CONFIG_USB_EHCI_HCD_SPEAR)	+= ehci-spear.o
 
 obj-$(CONFIG_USB_OXU210HP_HCD)	+= oxu210hp-hcd.o
 obj-$(CONFIG_USB_ISP116X_HCD)	+= isp116x-hcd.o
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index 1f97268..c8c70a1 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -1264,11 +1264,6 @@ MODULE_LICENSE ("GPL");
 #define PLATFORM_DRIVER		ehci_octeon_driver
 #endif
 
-#ifdef CONFIG_PLAT_SPEAR
-#include "ehci-spear.c"
-#define PLATFORM_DRIVER		spear_ehci_hcd_driver
-#endif
-
 #ifdef CONFIG_USB_EHCI_MSM
 #include "ehci-msm.c"
 #define PLATFORM_DRIVER		ehci_msm_driver
@@ -1315,6 +1310,7 @@ MODULE_LICENSE ("GPL");
 	!IS_ENABLED(CONFIG_USB_EHCI_MXC) && \
 	!IS_ENABLED(CONFIG_USB_EHCI_HCD_OMAP) && \
 	!IS_ENABLED(CONFIG_USB_EHCI_HCD_ORION) && \
+	!IS_ENABLED(CONFIG_USB_EHCI_HCD_SPEAR) && \
 	!defined(PLATFORM_DRIVER) && \
 	!defined(PS3_SYSTEM_BUS_DRIVER) && \
 	!defined(OF_PLATFORM_DRIVER) && \
diff --git a/drivers/usb/host/ehci-spear.c b/drivers/usb/host/ehci-spear.c
index 210bb67..61ecfb3 100644
--- a/drivers/usb/host/ehci-spear.c
+++ b/drivers/usb/host/ehci-spear.c
@@ -1,5 +1,5 @@
 /*
-* Driver for EHCI HCD on SPEAR SOC
+* Driver for EHCI HCD on SPEAr SOC
 *
 * Copyright (C) 2010 ST Micro Electronics,
 * Deepak Sikri <deepak.sikri at st.com>
@@ -12,71 +12,30 @@
 */
 
 #include <linux/clk.h>
+#include <linux/dma-mapping.h>
+#include <linux/io.h>
 #include <linux/jiffies.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
 #include <linux/of.h>
 #include <linux/platform_device.h>
 #include <linux/pm.h>
+#include <linux/usb.h>
+#include <linux/usb/hcd.h>
 
-struct spear_ehci {
-	struct ehci_hcd ehci;
-	struct clk *clk;
-};
-
-#define to_spear_ehci(hcd)	(struct spear_ehci *)hcd_to_ehci(hcd)
+#include "ehci.h"
 
-static void spear_start_ehci(struct spear_ehci *ehci)
-{
-	clk_prepare_enable(ehci->clk);
-}
+#define DRIVER_DESC "EHCI SPEAr driver"
 
-static void spear_stop_ehci(struct spear_ehci *ehci)
-{
-	clk_disable_unprepare(ehci->clk);
-}
+static const char hcd_name[] = "SPEAr-ehci";
 
-static int ehci_spear_setup(struct usb_hcd *hcd)
-{
-	struct ehci_hcd *ehci = hcd_to_ehci(hcd);
-
-	/* registers start at offset 0x0 */
-	ehci->caps = hcd->regs;
+struct spear_ehci {
+	struct clk *clk;
+};
 
-	return ehci_setup(hcd);
-}
+#define to_spear_ehci(hcd)	(struct spear_ehci *)(hcd_to_ehci(hcd)->priv)
 
-static const struct hc_driver ehci_spear_hc_driver = {
-	.description			= hcd_name,
-	.product_desc			= "SPEAr EHCI",
-	.hcd_priv_size			= sizeof(struct spear_ehci),
-
-	/* generic hardware linkage */
-	.irq				= ehci_irq,
-	.flags				= HCD_MEMORY | HCD_USB2,
-
-	/* basic lifecycle operations */
-	.reset				= ehci_spear_setup,
-	.start				= ehci_run,
-	.stop				= ehci_stop,
-	.shutdown			= ehci_shutdown,
-
-	/* managing i/o requests and associated device resources */
-	.urb_enqueue			= ehci_urb_enqueue,
-	.urb_dequeue			= ehci_urb_dequeue,
-	.endpoint_disable		= ehci_endpoint_disable,
-	.endpoint_reset			= ehci_endpoint_reset,
-
-	/* scheduling support */
-	.get_frame_number		= ehci_get_frame,
-
-	/* root hub support */
-	.hub_status_data		= ehci_hub_status_data,
-	.hub_control			= ehci_hub_control,
-	.bus_suspend			= ehci_bus_suspend,
-	.bus_resume			= ehci_bus_resume,
-	.relinquish_port		= ehci_relinquish_port,
-	.port_handed_over		= ehci_port_handed_over,
-	.clear_tt_buffer_complete	= ehci_clear_tt_buffer_complete,
-};
+static struct hc_driver __read_mostly ehci_spear_hc_driver;
 
 #ifdef CONFIG_PM_SLEEP
 static int ehci_spear_drv_suspend(struct device *dev)
@@ -104,7 +63,7 @@ static u64 spear_ehci_dma_mask = DMA_BIT_MASK(32);
 static int spear_ehci_hcd_drv_probe(struct platform_device *pdev)
 {
 	struct usb_hcd *hcd ;
-	struct spear_ehci *ehci;
+	struct spear_ehci *sehci;
 	struct resource *res;
 	struct clk *usbh_clk;
 	const struct hc_driver *driver = &ehci_spear_hc_driver;
@@ -161,10 +120,13 @@ static int spear_ehci_hcd_drv_probe(struct platform_device *pdev)
 		goto err_put_hcd;
 	}
 
-	ehci = (struct spear_ehci *)hcd_to_ehci(hcd);
-	ehci->clk = usbh_clk;
+	sehci = to_spear_ehci(hcd);
+	sehci->clk = usbh_clk;
+
+	/* registers start at offset 0x0 */
+	hcd_to_ehci(hcd)->caps = hcd->regs;
 
-	spear_start_ehci(ehci);
+	clk_prepare_enable(sehci->clk);
 	retval = usb_add_hcd(hcd, irq, IRQF_SHARED);
 	if (retval)
 		goto err_stop_ehci;
@@ -172,7 +134,7 @@ static int spear_ehci_hcd_drv_probe(struct platform_device *pdev)
 	return retval;
 
 err_stop_ehci:
-	spear_stop_ehci(ehci);
+	clk_disable_unprepare(sehci->clk);
 err_put_hcd:
 	usb_put_hcd(hcd);
 fail:
@@ -184,7 +146,7 @@ fail:
 static int spear_ehci_hcd_drv_remove(struct platform_device *pdev)
 {
 	struct usb_hcd *hcd = platform_get_drvdata(pdev);
-	struct spear_ehci *ehci_p = to_spear_ehci(hcd);
+	struct spear_ehci *sehci = to_spear_ehci(hcd);
 
 	if (!hcd)
 		return 0;
@@ -192,8 +154,8 @@ static int spear_ehci_hcd_drv_remove(struct platform_device *pdev)
 		BUG();
 	usb_remove_hcd(hcd);
 
-	if (ehci_p->clk)
-		spear_stop_ehci(ehci_p);
+	if (sehci->clk)
+		clk_disable_unprepare(sehci->clk);
 	usb_put_hcd(hcd);
 
 	return 0;
@@ -216,4 +178,29 @@ static struct platform_driver spear_ehci_hcd_driver = {
 	}
 };
 
+static const struct ehci_driver_overrides spear_overrides __initdata = {
+	.extra_priv_size = sizeof(struct spear_ehci),
+};
+
+static int __init ehci_spear_init(void)
+{
+	if (usb_disabled())
+		return -ENODEV;
+
+	pr_info("%s: " DRIVER_DESC "\n", hcd_name);
+
+	ehci_init_driver(&ehci_spear_hc_driver, &spear_overrides);
+	return platform_driver_register(&spear_ehci_hcd_driver);
+}
+module_init(ehci_spear_init);
+
+static void __exit ehci_spear_cleanup(void)
+{
+	platform_driver_unregister(&spear_ehci_hcd_driver);
+}
+module_exit(ehci_spear_cleanup);
+
+MODULE_DESCRIPTION(DRIVER_DESC);
 MODULE_ALIAS("platform:spear-ehci");
+MODULE_AUTHOR("Deepak Sikri");
+MODULE_LICENSE("GPL");
-- 
1.8.1.2



From arnd at arndb.de  Tue Apr  2 12:23:59 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue,  2 Apr 2013 18:23:59 +0200
Subject: [PATCH V5 1/6] USB: EHCI: make ehci-orion a separate driver
In-Reply-To: <1364919844-1726-1-git-send-email-arnd@arndb.de>
References: <1364919844-1726-1-git-send-email-arnd@arndb.de>
Message-ID: <1364919844-1726-2-git-send-email-arnd@arndb.de>

From: Manjunath Goudar <manjunath.goudar at linaro.org>

Separate the Orion host controller driver from ehci-hcd host
code into its own driver module because of following reason.

With the multiplatform changes in arm-soc tree, it becomes
possible to enable the mvebu platform (which uses
ehci-orion) at the same time as other platforms that require
a conflicting EHCI bus glue. At the moment, this results
in a warning like

drivers/usb/host/ehci-hcd.c:1297:0: warning: "PLATFORM_DRIVER" redefined [enabled by default]
drivers/usb/host/ehci-hcd.c:1277:0: note: this is the location of the previous definition
drivers/usb/host/ehci-orion.c:334:31: warning: 'ehci_orion_driver' defined but not used [-Wunused-variable]

and an ehci driver that only works on one of them.

With the infrastructure added by Alan Stern in patch 3e0232039
"USB: EHCI: prepare to make ehci-hcd a library module", we can
avoid this problem by turning a bus glue into a separate
module, as we do here for the orion bus glue.

An earlier version of this patch was included in 3.9 but caused
a regression there, which has subsequently been fixed.

While we are here, use the opportunity to disabiguate the two
Marvell EHCI controller implementations in Kconfig.

In V4 (arnd):
- Improve Kconfig text

In V3:
- More detail provided in commit message regarding this patch.
- Replaced hcd_name string "ehci-orion" into "orion-ehci".
- MODULE_LICENSE is GPL v2.
- In ehci_init_driver calling second argument passed  as NULL instead of
  ehci_orion_overrides because ehci_orion_overrides is removed.

In V2:
- Tegra patch related changes removed from this patch.

Signed-off-by: Manjunath Goudar <manjunath.goudar at linaro.org>
Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Acked-by: Jason Cooper <jason at lakedaemon.net>
Tested-by: Andrew Lunn <andrew at lunn.ch>
Acked-by: Alan Stern <stern at rowland.harvard.edu>
---
 drivers/usb/host/Kconfig      | 17 ++++++++-
 drivers/usb/host/Makefile     |  1 +
 drivers/usb/host/ehci-hcd.c   |  6 +---
 drivers/usb/host/ehci-orion.c | 82 ++++++++++++++++++-------------------------
 4 files changed, 53 insertions(+), 53 deletions(-)

diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 2f68221..e5649c1 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -163,6 +163,17 @@ config USB_EHCI_HCD_OMAP
 	  Enables support for the on-chip EHCI controller on
 	  OMAP3 and later chips.
 
+config USB_EHCI_HCD_ORION
+	tristate  "Support for Marvell EBU on-chip EHCI USB controller"
+	depends on USB_EHCI_HCD && PLAT_ORION
+	default y
+	---help---
+	  Enables support for the on-chip EHCI controller on Marvell's
+	  embedded ARM SoCs, including Orion, Kirkwood, Dove, Armada XP,
+	  Armada 370.  This is different from the EHCI implementation
+	  on Marvell's mobile PXA and MMP SoC, see "EHCI support for
+	  Marvell PXA/MMP USB controller" for those.
+
 config USB_EHCI_MSM
 	bool "Support for MSM on-chip EHCI USB controller"
 	depends on USB_EHCI_HCD && ARCH_MSM
@@ -206,13 +217,17 @@ config USB_EHCI_S5P
 	 Enable support for the S5P SOC's on-chip EHCI controller.
 
 config USB_EHCI_MV
-	bool "EHCI support for Marvell on-chip controller"
+	bool "EHCI support for Marvell PXA/MMP USB controller"
 	depends on USB_EHCI_HCD && (ARCH_PXA || ARCH_MMP)
 	select USB_EHCI_ROOT_HUB_TT
 	---help---
 	  Enables support for Marvell (including PXA and MMP series) on-chip
 	  USB SPH and OTG controller. SPH is a single port host, and it can
 	  only be EHCI host. OTG is controller that can switch to host mode.
+	  Note that this driver will not work on Marvell's other EHCI
+	  controller used by the EBU-type SoCs including Orion, Kirkwood,
+	  Dova, Armada 370 and Armada XP. See "Support for Marvell EBU
+	  on-chip EHCI USB controller" for those.
 
 config USB_W90X900_EHCI
 	bool "W90X900(W90P910) EHCI support"
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 56de410..9492f50 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -28,6 +28,7 @@ obj-$(CONFIG_USB_EHCI_PCI)	+= ehci-pci.o
 obj-$(CONFIG_USB_EHCI_HCD_PLATFORM)	+= ehci-platform.o
 obj-$(CONFIG_USB_EHCI_MXC)	+= ehci-mxc.o
 obj-$(CONFIG_USB_EHCI_HCD_OMAP)	+= ehci-omap.o
+obj-$(CONFIG_USB_EHCI_HCD_ORION)	+= ehci-orion.o
 
 obj-$(CONFIG_USB_OXU210HP_HCD)	+= oxu210hp-hcd.o
 obj-$(CONFIG_USB_ISP116X_HCD)	+= isp116x-hcd.o
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index b12b97d..1f97268 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -1249,11 +1249,6 @@ MODULE_LICENSE ("GPL");
 #define XILINX_OF_PLATFORM_DRIVER	ehci_hcd_xilinx_of_driver
 #endif
 
-#ifdef CONFIG_PLAT_ORION
-#include "ehci-orion.c"
-#define	PLATFORM_DRIVER		ehci_orion_driver
-#endif
-
 #ifdef CONFIG_USB_W90X900_EHCI
 #include "ehci-w90x900.c"
 #define	PLATFORM_DRIVER		ehci_hcd_w90x900_driver
@@ -1319,6 +1314,7 @@ MODULE_LICENSE ("GPL");
 	!IS_ENABLED(CONFIG_USB_CHIPIDEA_HOST) && \
 	!IS_ENABLED(CONFIG_USB_EHCI_MXC) && \
 	!IS_ENABLED(CONFIG_USB_EHCI_HCD_OMAP) && \
+	!IS_ENABLED(CONFIG_USB_EHCI_HCD_ORION) && \
 	!defined(PLATFORM_DRIVER) && \
 	!defined(PS3_SYSTEM_BUS_DRIVER) && \
 	!defined(OF_PLATFORM_DRIVER) && \
diff --git a/drivers/usb/host/ehci-orion.c b/drivers/usb/host/ehci-orion.c
index 38c45fb..54c5794 100644
--- a/drivers/usb/host/ehci-orion.c
+++ b/drivers/usb/host/ehci-orion.c
@@ -17,6 +17,12 @@
 #include <linux/of.h>
 #include <linux/of_device.h>
 #include <linux/of_irq.h>
+#include <linux/usb.h>
+#include <linux/usb/hcd.h>
+#include <linux/io.h>
+#include <linux/dma-mapping.h>
+
+#include "ehci.h"
 
 #define rdl(off)	__raw_readl(hcd->regs + (off))
 #define wrl(off, val)	__raw_writel((val), hcd->regs + (off))
@@ -34,6 +40,12 @@
 #define USB_PHY_IVREF_CTRL	0x440
 #define USB_PHY_TST_GRP_CTRL	0x450
 
+#define DRIVER_DESC "EHCI orion driver"
+
+static const char hcd_name[] = "ehci-orion";
+
+static struct hc_driver __read_mostly ehci_orion_hc_driver;
+
 /*
  * Implement Orion USB controller specification guidelines
  */
@@ -104,51 +116,6 @@ static void orion_usb_phy_v1_setup(struct usb_hcd *hcd)
 	wrl(USB_MODE, 0x13);
 }
 
-static const struct hc_driver ehci_orion_hc_driver = {
-	.description = hcd_name,
-	.product_desc = "Marvell Orion EHCI",
-	.hcd_priv_size = sizeof(struct ehci_hcd),
-
-	/*
-	 * generic hardware linkage
-	 */
-	.irq = ehci_irq,
-	.flags = HCD_MEMORY | HCD_USB2,
-
-	/*
-	 * basic lifecycle operations
-	 */
-	.reset = ehci_setup,
-	.start = ehci_run,
-	.stop = ehci_stop,
-	.shutdown = ehci_shutdown,
-
-	/*
-	 * managing i/o requests and associated device resources
-	 */
-	.urb_enqueue = ehci_urb_enqueue,
-	.urb_dequeue = ehci_urb_dequeue,
-	.endpoint_disable = ehci_endpoint_disable,
-	.endpoint_reset = ehci_endpoint_reset,
-
-	/*
-	 * scheduling support
-	 */
-	.get_frame_number = ehci_get_frame,
-
-	/*
-	 * root hub support
-	 */
-	.hub_status_data = ehci_hub_status_data,
-	.hub_control = ehci_hub_control,
-	.bus_suspend = ehci_bus_suspend,
-	.bus_resume = ehci_bus_resume,
-	.relinquish_port = ehci_relinquish_port,
-	.port_handed_over = ehci_port_handed_over,
-
-	.clear_tt_buffer_complete = ehci_clear_tt_buffer_complete,
-};
-
 static void
 ehci_orion_conf_mbus_windows(struct usb_hcd *hcd,
 			     const struct mbus_dram_target_info *dram)
@@ -323,8 +290,6 @@ static int ehci_orion_drv_remove(struct platform_device *pdev)
 	return 0;
 }
 
-MODULE_ALIAS("platform:orion-ehci");
-
 static const struct of_device_id ehci_orion_dt_ids[] = {
 	{ .compatible = "marvell,orion-ehci", },
 	{},
@@ -341,3 +306,26 @@ static struct platform_driver ehci_orion_driver = {
 		.of_match_table = of_match_ptr(ehci_orion_dt_ids),
 	},
 };
+
+static int __init ehci_orion_init(void)
+{
+	if (usb_disabled())
+		return -ENODEV;
+
+	pr_info("%s: " DRIVER_DESC "\n", hcd_name);
+
+	ehci_init_driver(&ehci_orion_hc_driver, NULL);
+	return platform_driver_register(&ehci_orion_driver);
+}
+module_init(ehci_orion_init);
+
+static void __exit ehci_orion_cleanup(void)
+{
+	platform_driver_unregister(&ehci_orion_driver);
+}
+module_exit(ehci_orion_cleanup);
+
+MODULE_DESCRIPTION(DRIVER_DESC);
+MODULE_ALIAS("platform:orion-ehci");
+MODULE_AUTHOR("Tzachi Perelstein");
+MODULE_LICENSE("GPL v2");
-- 
1.8.1.2



From arnd at arndb.de  Tue Apr  2 12:24:01 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue,  2 Apr 2013 18:24:01 +0200
Subject: [PATCH V5 3/6] USB: EHCI: make ehci-s5p a separate driver
In-Reply-To: <1364919844-1726-1-git-send-email-arnd@arndb.de>
References: <1364919844-1726-1-git-send-email-arnd@arndb.de>
Message-ID: <1364919844-1726-4-git-send-email-arnd@arndb.de>

From: Manjunath Goudar <manjunath.goudar at linaro.org>

Separate the  Samsung S5P/EXYNOS host controller driver from ehci-hcd
host code so that it can be built as a separate driver module.
This work is part of enabling multi-platform kernels on ARM;
however, note that other changes are still needed before S5P/EXYNOS can
be booted with a multi-platform kernel. We currently expect those
to get merged for 3.10.

With the infrastructure added by Alan Stern in patch 3e0232039
"USB: EHCI: prepare to make ehci-hcd a library module", we can
avoid this problem by turning a bus glue into a separate
module, as we do here for the s5p bus glue.

In V4 (arnd)
 - revert some of the pointless changes.
 - fix allocation of s5p specific data structure.

In V3:
 - Detailed commit message added here, why this patch is required.
 - MODULE_LICENSE is GPL v2.
 - Added .extra_priv_size to eliminate the separate allocation of
   the s5p_ehci_hcd structure and removed .reset function pointer
   initialization.
 - Arranged  #include's in alphabetical order.
 - After using extra_priv_size initialization, struct usb_hcd *hcd
   is redundant and can be removed from the probe function.
 - Eliminated s5p_ehci_phy_enable,contents of statements moved
   into the s5p_ehci_probe
 - Eliminated s5p_ehci_phy_disable, contents of statements moved into
   the s5p_ehci_remove.

In V2:
 - Tegra patch related changes removed from this patch.

Signed-off-by: Manjunath Goudar <manjunath.goudar at linaro.org>
Acked-by: Jingoo Han <jg1.han at samsung.com>
Acked-by: Alan Stern <stern at rowland.harvard.edu>
Cc: Kukjin Kim <kgene.kim at samsung.com>
Cc: Kyungmin Park <kyungmin.park at samsung.com>
Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 drivers/usb/host/Kconfig    |   5 +-
 drivers/usb/host/Makefile   |   1 +
 drivers/usb/host/ehci-hcd.c |   6 +-
 drivers/usb/host/ehci-s5p.c | 164 +++++++++++++++++++++-----------------------
 4 files changed, 85 insertions(+), 91 deletions(-)

diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 4723f79..98abec0f 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -219,10 +219,11 @@ config USB_EHCI_SH
 	  If you use the PCI EHCI controller, this option is not necessary.
 
 config USB_EHCI_S5P
-       boolean "S5P EHCI support"
+       tristate "EHCI support for Samsung S5P/EXYNOS SoC Series"
        depends on USB_EHCI_HCD && PLAT_S5P
        help
-	 Enable support for the S5P SOC's on-chip EHCI controller.
+	Enable support for the Samsung S5Pxxxx and Exynos3/4/5 SOC's
+	on-chip EHCI controller.
 
 config USB_EHCI_MV
 	bool "EHCI support for Marvell PXA/MMP USB controller"
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 3e02471..3d895b5 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -30,6 +30,7 @@ obj-$(CONFIG_USB_EHCI_MXC)	+= ehci-mxc.o
 obj-$(CONFIG_USB_EHCI_HCD_OMAP)	+= ehci-omap.o
 obj-$(CONFIG_USB_EHCI_HCD_ORION)	+= ehci-orion.o
 obj-$(CONFIG_USB_EHCI_HCD_SPEAR)	+= ehci-spear.o
+obj-$(CONFIG_USB_EHCI_S5P)	+= ehci-s5p.o
 
 obj-$(CONFIG_USB_OXU210HP_HCD)	+= oxu210hp-hcd.o
 obj-$(CONFIG_USB_ISP116X_HCD)	+= isp116x-hcd.o
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index c8c70a1..8f1f4b4 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -1284,11 +1284,6 @@ MODULE_LICENSE ("GPL");
 #define PLATFORM_DRIVER		tegra_ehci_driver
 #endif
 
-#ifdef CONFIG_USB_EHCI_S5P
-#include "ehci-s5p.c"
-#define PLATFORM_DRIVER		s5p_ehci_driver
-#endif
-
 #ifdef CONFIG_SPARC_LEON
 #include "ehci-grlib.c"
 #define PLATFORM_DRIVER		ehci_grlib_driver
@@ -1311,6 +1306,7 @@ MODULE_LICENSE ("GPL");
 	!IS_ENABLED(CONFIG_USB_EHCI_HCD_OMAP) && \
 	!IS_ENABLED(CONFIG_USB_EHCI_HCD_ORION) && \
 	!IS_ENABLED(CONFIG_USB_EHCI_HCD_SPEAR) && \
+	!IS_ENABLED(CONFIG_USB_EHCI_S5P) && \
 	!defined(PLATFORM_DRIVER) && \
 	!defined(PS3_SYSTEM_BUS_DRIVER) && \
 	!defined(OF_PLATFORM_DRIVER) && \
diff --git a/drivers/usb/host/ehci-s5p.c b/drivers/usb/host/ehci-s5p.c
index 738490e..3147984 100644
--- a/drivers/usb/host/ehci-s5p.c
+++ b/drivers/usb/host/ehci-s5p.c
@@ -13,13 +13,24 @@
  */
 
 #include <linux/clk.h>
+#include <linux/dma-mapping.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
 #include <linux/of.h>
-#include <linux/platform_device.h>
 #include <linux/of_gpio.h>
+#include <linux/platform_device.h>
 #include <linux/platform_data/usb-ehci-s5p.h>
 #include <linux/usb/phy.h>
 #include <linux/usb/samsung_usb_phy.h>
 #include <plat/usb-phy.h>
+#include <linux/usb.h>
+#include <linux/usb/hcd.h>
+#include <linux/usb/otg.h>
+
+#include "ehci.h"
+
+#define DRIVER_DESC "EHCI s5p driver"
 
 #define EHCI_INSNREG00(base)			(base + 0x90)
 #define EHCI_INSNREG00_ENA_INCR16		(0x1 << 25)
@@ -30,65 +41,17 @@
 	(EHCI_INSNREG00_ENA_INCR16 | EHCI_INSNREG00_ENA_INCR8 |	\
 	 EHCI_INSNREG00_ENA_INCR4 | EHCI_INSNREG00_ENA_INCRX_ALIGN)
 
+static const char hcd_name[] = "ehci-s5p";
+static struct hc_driver __read_mostly s5p_ehci_hc_driver;
+
 struct s5p_ehci_hcd {
-	struct device *dev;
-	struct usb_hcd *hcd;
 	struct clk *clk;
 	struct usb_phy *phy;
 	struct usb_otg *otg;
 	struct s5p_ehci_platdata *pdata;
 };
 
-static const struct hc_driver s5p_ehci_hc_driver = {
-	.description		= hcd_name,
-	.product_desc		= "S5P EHCI Host Controller",
-	.hcd_priv_size		= sizeof(struct ehci_hcd),
-
-	.irq			= ehci_irq,
-	.flags			= HCD_MEMORY | HCD_USB2,
-
-	.reset			= ehci_setup,
-	.start			= ehci_run,
-	.stop			= ehci_stop,
-	.shutdown		= ehci_shutdown,
-
-	.get_frame_number	= ehci_get_frame,
-
-	.urb_enqueue		= ehci_urb_enqueue,
-	.urb_dequeue		= ehci_urb_dequeue,
-	.endpoint_disable	= ehci_endpoint_disable,
-	.endpoint_reset		= ehci_endpoint_reset,
-
-	.hub_status_data	= ehci_hub_status_data,
-	.hub_control		= ehci_hub_control,
-	.bus_suspend		= ehci_bus_suspend,
-	.bus_resume		= ehci_bus_resume,
-
-	.relinquish_port	= ehci_relinquish_port,
-	.port_handed_over	= ehci_port_handed_over,
-
-	.clear_tt_buffer_complete	= ehci_clear_tt_buffer_complete,
-};
-
-static void s5p_ehci_phy_enable(struct s5p_ehci_hcd *s5p_ehci)
-{
-	struct platform_device *pdev = to_platform_device(s5p_ehci->dev);
-
-	if (s5p_ehci->phy)
-		usb_phy_init(s5p_ehci->phy);
-	else if (s5p_ehci->pdata->phy_init)
-		s5p_ehci->pdata->phy_init(pdev, USB_PHY_TYPE_HOST);
-}
-
-static void s5p_ehci_phy_disable(struct s5p_ehci_hcd *s5p_ehci)
-{
-	struct platform_device *pdev = to_platform_device(s5p_ehci->dev);
-
-	if (s5p_ehci->phy)
-		usb_phy_shutdown(s5p_ehci->phy);
-	else if (s5p_ehci->pdata->phy_exit)
-		s5p_ehci->pdata->phy_exit(pdev, USB_PHY_TYPE_HOST);
-}
+#define to_s5p_ehci(hcd)      (struct s5p_ehci_hcd *)(hcd_to_ehci(hcd)->priv)
 
 static void s5p_setup_vbus_gpio(struct platform_device *pdev)
 {
@@ -134,11 +97,13 @@ static int s5p_ehci_probe(struct platform_device *pdev)
 
 	s5p_setup_vbus_gpio(pdev);
 
-	s5p_ehci = devm_kzalloc(&pdev->dev, sizeof(struct s5p_ehci_hcd),
-				GFP_KERNEL);
-	if (!s5p_ehci)
+	hcd = usb_create_hcd(&s5p_ehci_hc_driver,
+			     &pdev->dev, dev_name(&pdev->dev));
+	if (!hcd) {
+		dev_err(&pdev->dev, "Unable to create HCD\n");
 		return -ENOMEM;
-
+	}
+	s5p_ehci = to_s5p_ehci(hcd);
 	phy = devm_usb_get_phy(&pdev->dev, USB_PHY_TYPE_USB2);
 	if (IS_ERR_OR_NULL(phy)) {
 		/* Fallback to pdata */
@@ -153,16 +118,6 @@ static int s5p_ehci_probe(struct platform_device *pdev)
 		s5p_ehci->otg = phy->otg;
 	}
 
-	s5p_ehci->dev = &pdev->dev;
-
-	hcd = usb_create_hcd(&s5p_ehci_hc_driver, &pdev->dev,
-					dev_name(&pdev->dev));
-	if (!hcd) {
-		dev_err(&pdev->dev, "Unable to create HCD\n");
-		return -ENOMEM;
-	}
-
-	s5p_ehci->hcd = hcd;
 	s5p_ehci->clk = devm_clk_get(&pdev->dev, "usbhost");
 
 	if (IS_ERR(s5p_ehci->clk)) {
@@ -199,9 +154,12 @@ static int s5p_ehci_probe(struct platform_device *pdev)
 	}
 
 	if (s5p_ehci->otg)
-		s5p_ehci->otg->set_host(s5p_ehci->otg, &s5p_ehci->hcd->self);
+		s5p_ehci->otg->set_host(s5p_ehci->otg, &hcd->self);
 
-	s5p_ehci_phy_enable(s5p_ehci);
+	if (s5p_ehci->phy)
+		usb_phy_init(s5p_ehci->phy);
+	else if (s5p_ehci->pdata->phy_init)
+		s5p_ehci->pdata->phy_init(pdev, USB_PHY_TYPE_HOST);
 
 	ehci = hcd_to_ehci(hcd);
 	ehci->caps = hcd->regs;
@@ -220,7 +178,10 @@ static int s5p_ehci_probe(struct platform_device *pdev)
 	return 0;
 
 fail_add_hcd:
-	s5p_ehci_phy_disable(s5p_ehci);
+	if (s5p_ehci->phy)
+		usb_phy_shutdown(s5p_ehci->phy);
+	else if (s5p_ehci->pdata->phy_exit)
+		s5p_ehci->pdata->phy_exit(pdev, USB_PHY_TYPE_HOST);
 fail_io:
 	clk_disable_unprepare(s5p_ehci->clk);
 fail_clk:
@@ -230,15 +191,18 @@ fail_clk:
 
 static int s5p_ehci_remove(struct platform_device *pdev)
 {
-	struct s5p_ehci_hcd *s5p_ehci = platform_get_drvdata(pdev);
-	struct usb_hcd *hcd = s5p_ehci->hcd;
+	struct usb_hcd *hcd = platform_get_drvdata(pdev);
+	struct s5p_ehci_hcd *s5p_ehci = to_s5p_ehci(hcd);
 
 	usb_remove_hcd(hcd);
 
 	if (s5p_ehci->otg)
-		s5p_ehci->otg->set_host(s5p_ehci->otg, &s5p_ehci->hcd->self);
+		s5p_ehci->otg->set_host(s5p_ehci->otg, &hcd->self);
 
-	s5p_ehci_phy_disable(s5p_ehci);
+	if (s5p_ehci->phy)
+		usb_phy_shutdown(s5p_ehci->phy);
+	else if (s5p_ehci->pdata->phy_exit)
+		s5p_ehci->pdata->phy_exit(pdev, USB_PHY_TYPE_HOST);
 
 	clk_disable_unprepare(s5p_ehci->clk);
 
@@ -249,8 +213,7 @@ static int s5p_ehci_remove(struct platform_device *pdev)
 
 static void s5p_ehci_shutdown(struct platform_device *pdev)
 {
-	struct s5p_ehci_hcd *s5p_ehci = platform_get_drvdata(pdev);
-	struct usb_hcd *hcd = s5p_ehci->hcd;
+	struct usb_hcd *hcd = platform_get_drvdata(pdev);
 
 	if (hcd->driver->shutdown)
 		hcd->driver->shutdown(hcd);
@@ -259,17 +222,22 @@ static void s5p_ehci_shutdown(struct platform_device *pdev)
 #ifdef CONFIG_PM
 static int s5p_ehci_suspend(struct device *dev)
 {
-	struct s5p_ehci_hcd *s5p_ehci = dev_get_drvdata(dev);
-	struct usb_hcd *hcd = s5p_ehci->hcd;
+	struct usb_hcd *hcd = dev_get_drvdata(dev);
+	struct s5p_ehci_hcd *s5p_ehci = to_s5p_ehci(hcd);
+	struct platform_device *pdev = to_platform_device(dev);
+
 	bool do_wakeup = device_may_wakeup(dev);
 	int rc;
 
 	rc = ehci_suspend(hcd, do_wakeup);
 
 	if (s5p_ehci->otg)
-		s5p_ehci->otg->set_host(s5p_ehci->otg, &s5p_ehci->hcd->self);
+		s5p_ehci->otg->set_host(s5p_ehci->otg, &hcd->self);
 
-	s5p_ehci_phy_disable(s5p_ehci);
+	if (s5p_ehci->phy)
+		usb_phy_shutdown(s5p_ehci->phy);
+	else if (s5p_ehci->pdata->phy_exit)
+		s5p_ehci->pdata->phy_exit(pdev, USB_PHY_TYPE_HOST);
 
 	clk_disable_unprepare(s5p_ehci->clk);
 
@@ -278,15 +246,19 @@ static int s5p_ehci_suspend(struct device *dev)
 
 static int s5p_ehci_resume(struct device *dev)
 {
-	struct s5p_ehci_hcd *s5p_ehci = dev_get_drvdata(dev);
-	struct usb_hcd *hcd = s5p_ehci->hcd;
+	struct usb_hcd *hcd = dev_get_drvdata(dev);
+	struct  s5p_ehci_hcd *s5p_ehci = to_s5p_ehci(hcd);
+	struct platform_device *pdev = to_platform_device(dev);
 
 	clk_prepare_enable(s5p_ehci->clk);
 
 	if (s5p_ehci->otg)
-		s5p_ehci->otg->set_host(s5p_ehci->otg, &s5p_ehci->hcd->self);
+		s5p_ehci->otg->set_host(s5p_ehci->otg, &hcd->self);
 
-	s5p_ehci_phy_enable(s5p_ehci);
+	if (s5p_ehci->phy)
+		usb_phy_init(s5p_ehci->phy);
+	else if (s5p_ehci->pdata->phy_init)
+		s5p_ehci->pdata->phy_init(pdev, USB_PHY_TYPE_HOST);
 
 	/* DMA burst Enable */
 	writel(EHCI_INSNREG00_ENABLE_DMA_BURST, EHCI_INSNREG00(hcd->regs));
@@ -323,5 +295,29 @@ static struct platform_driver s5p_ehci_driver = {
 		.of_match_table = of_match_ptr(exynos_ehci_match),
 	}
 };
+static const struct ehci_driver_overrides s5p_overrides __initdata = {
+	.extra_priv_size = sizeof(struct s5p_ehci_hcd),
+};
+
+static int __init ehci_s5p_init(void)
+{
+	if (usb_disabled())
+		return -ENODEV;
+
+	pr_info("%s: " DRIVER_DESC "\n", hcd_name);
+	ehci_init_driver(&s5p_ehci_hc_driver, &s5p_overrides);
+	return platform_driver_register(&s5p_ehci_driver);
+}
+module_init(ehci_s5p_init);
+
+static void __exit ehci_s5p_cleanup(void)
+{
+	platform_driver_unregister(&s5p_ehci_driver);
+}
+module_exit(ehci_s5p_cleanup);
 
+MODULE_DESCRIPTION(DRIVER_DESC);
 MODULE_ALIAS("platform:s5p-ehci");
+MODULE_AUTHOR("Jingoo Han");
+MODULE_AUTHOR("Joonyoung Shim");
+MODULE_LICENSE("GPL v2");
-- 
1.8.1.2



From arnd at arndb.de  Tue Apr  2 12:24:02 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue,  2 Apr 2013 18:24:02 +0200
Subject: [PATCH V5 4/6] USB: EHCI: make ehci-atmel a separate driver
In-Reply-To: <1364919844-1726-1-git-send-email-arnd@arndb.de>
References: <1364919844-1726-1-git-send-email-arnd@arndb.de>
Message-ID: <1364919844-1726-5-git-send-email-arnd@arndb.de>

From: Manjunath Goudar <manjunath.goudar at linaro.org>

Separate the Atmel host controller driver from ehci-hcd host code
so that it can be built as a separate driver module.
This work is part of enabling multi-platform kernels on ARM;
however, note that other changes are still needed before Atmel can be
booted with a multi-platform kernel. This is currently planned for
Linux-3.11.

With the infrastructure added by Alan Stern in patch 3e0232039
"USB: EHCI: prepare to make ehci-hcd a library module", we can
avoid this problem by turning a bus glue into a separate
module, as we do here for the Atmel bus glue.

In V4 (arnd):
 - reordered #include statements.
 - removed call to ehci_shutdown and the corresponding export

In V3:
 - Detailed commit message added here about why this patch is required.
 - Replaced hcd_name string "ehci-atmel" to "atmel-ehci".
 - Inserted blank line in the Makefile to separate the EHCI drivers from
   the following non-EHCI drivers.
 - Exported ehci_shutdown symbol as it is needed by the Atmel driver.
 - Eliminated ehci_atmel_setup routine because hcd registers
   can be directly set in the ehci_atmel_drv_probe function.

In V2:
  Resolved below compiler error.
  drivers/usb/host/ehci-atmel.c: In function 'ehci_atmel_drv_remove':
  drivers/usb/host/ehci-atmel.c:167: error: implicit declaration of function 'ehci_shutdown'

Signed-off-by: Manjunath Goudar <manjunath.goudar at linaro.org>
Acked-by: Alan Stern <stern at rowland.harvard.edu>
Acked-by: Nicolas Ferre <nicolas.ferre at atmel.com>
Cc: Andrew Victor <linux at maxim.org.za>
Cc: Jean-Christophe Plagniol-Villard <plagnioj at jcrosoft.com>
Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 drivers/usb/host/Kconfig      |  8 ++++
 drivers/usb/host/Makefile     |  1 +
 drivers/usb/host/ehci-atmel.c | 88 ++++++++++++++++++++-----------------------
 drivers/usb/host/ehci-hcd.c   |  6 +--
 4 files changed, 51 insertions(+), 52 deletions(-)

diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 98abec0f..f6f7872 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -182,6 +182,14 @@ config USB_EHCI_HCD_SPEAR
           Enables support for the on-chip EHCI controller on
           ST SPEAr chips.
 
+config USB_EHCI_HCD_AT91
+        tristate  "Support for Atmel on-chip EHCI USB controller"
+        depends on USB_EHCI_HCD && ARCH_AT91
+        default y
+        ---help---
+          Enables support for the on-chip EHCI controller on
+          Atmel chips.
+
 config USB_EHCI_MSM
 	bool "Support for MSM on-chip EHCI USB controller"
 	depends on USB_EHCI_HCD && ARCH_MSM
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 3d895b5..368d3eb 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -31,6 +31,7 @@ obj-$(CONFIG_USB_EHCI_HCD_OMAP)	+= ehci-omap.o
 obj-$(CONFIG_USB_EHCI_HCD_ORION)	+= ehci-orion.o
 obj-$(CONFIG_USB_EHCI_HCD_SPEAR)	+= ehci-spear.o
 obj-$(CONFIG_USB_EHCI_S5P)	+= ehci-s5p.o
+obj-$(CONFIG_USB_EHCI_HCD_AT91) += ehci-atmel.o
 
 obj-$(CONFIG_USB_OXU210HP_HCD)	+= oxu210hp-hcd.o
 obj-$(CONFIG_USB_ISP116X_HCD)	+= isp116x-hcd.o
diff --git a/drivers/usb/host/ehci-atmel.c b/drivers/usb/host/ehci-atmel.c
index f3beac4..6642009 100644
--- a/drivers/usb/host/ehci-atmel.c
+++ b/drivers/usb/host/ehci-atmel.c
@@ -12,9 +12,22 @@
  */
 
 #include <linux/clk.h>
-#include <linux/platform_device.h>
+#include <linux/dma-mapping.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
 #include <linux/of.h>
 #include <linux/of_platform.h>
+#include <linux/platform_device.h>
+#include <linux/usb.h>
+#include <linux/usb/hcd.h>
+
+#include "ehci.h"
+
+#define DRIVER_DESC "EHCI Atmel driver"
+
+static const char hcd_name[] = "ehci-atmel";
+static struct hc_driver __read_mostly ehci_atmel_hc_driver;
 
 /* interface and function clocks */
 static struct clk *iclk, *fclk;
@@ -50,51 +63,6 @@ static void atmel_stop_ehci(struct platform_device *pdev)
 
 /*-------------------------------------------------------------------------*/
 
-static int ehci_atmel_setup(struct usb_hcd *hcd)
-{
-	struct ehci_hcd *ehci = hcd_to_ehci(hcd);
-
-	/* registers start at offset 0x0 */
-	ehci->caps = hcd->regs;
-
-	return ehci_setup(hcd);
-}
-
-static const struct hc_driver ehci_atmel_hc_driver = {
-	.description		= hcd_name,
-	.product_desc		= "Atmel EHCI UHP HS",
-	.hcd_priv_size		= sizeof(struct ehci_hcd),
-
-	/* generic hardware linkage */
-	.irq			= ehci_irq,
-	.flags			= HCD_MEMORY | HCD_USB2,
-
-	/* basic lifecycle operations */
-	.reset			= ehci_atmel_setup,
-	.start			= ehci_run,
-	.stop			= ehci_stop,
-	.shutdown		= ehci_shutdown,
-
-	/* managing i/o requests and associated device resources */
-	.urb_enqueue		= ehci_urb_enqueue,
-	.urb_dequeue		= ehci_urb_dequeue,
-	.endpoint_disable	= ehci_endpoint_disable,
-	.endpoint_reset		= ehci_endpoint_reset,
-
-	/* scheduling support */
-	.get_frame_number	= ehci_get_frame,
-
-	/* root hub support */
-	.hub_status_data	= ehci_hub_status_data,
-	.hub_control		= ehci_hub_control,
-	.bus_suspend		= ehci_bus_suspend,
-	.bus_resume		= ehci_bus_resume,
-	.relinquish_port	= ehci_relinquish_port,
-	.port_handed_over	= ehci_port_handed_over,
-
-	.clear_tt_buffer_complete	= ehci_clear_tt_buffer_complete,
-};
-
 static u64 at91_ehci_dma_mask = DMA_BIT_MASK(32);
 
 static int ehci_atmel_drv_probe(struct platform_device *pdev)
@@ -102,6 +70,7 @@ static int ehci_atmel_drv_probe(struct platform_device *pdev)
 	struct usb_hcd *hcd;
 	const struct hc_driver *driver = &ehci_atmel_hc_driver;
 	struct resource *res;
+	struct ehci_hcd *ehci;
 	int irq;
 	int retval;
 
@@ -162,6 +131,10 @@ static int ehci_atmel_drv_probe(struct platform_device *pdev)
 		goto fail_request_resource;
 	}
 
+	ehci = hcd_to_ehci(hcd);
+	/* registers start at offset 0x0 */
+	ehci->caps = hcd->regs;
+
 	atmel_start_ehci(pdev);
 
 	retval = usb_add_hcd(hcd, irq, IRQF_SHARED);
@@ -185,7 +158,6 @@ static int ehci_atmel_drv_remove(struct platform_device *pdev)
 {
 	struct usb_hcd *hcd = platform_get_drvdata(pdev);
 
-	ehci_shutdown(hcd);
 	usb_remove_hcd(hcd);
 	usb_put_hcd(hcd);
 
@@ -213,3 +185,25 @@ static struct platform_driver ehci_atmel_driver = {
 		.of_match_table	= of_match_ptr(atmel_ehci_dt_ids),
 	},
 };
+
+static int __init ehci_atmel_init(void)
+{
+	if (usb_disabled())
+		return -ENODEV;
+
+	pr_info("%s: " DRIVER_DESC "\n", hcd_name);
+	ehci_init_driver(&ehci_atmel_hc_driver, NULL);
+	return platform_driver_register(&ehci_atmel_driver);
+}
+module_init(ehci_atmel_init);
+
+static void __exit ehci_atmel_cleanup(void)
+{
+	platform_driver_unregister(&ehci_atmel_driver);
+}
+module_exit(ehci_atmel_cleanup);
+
+MODULE_DESCRIPTION(DRIVER_DESC);
+MODULE_ALIAS("platform:atmel-ehci");
+MODULE_AUTHOR("Nicolas Ferre");
+MODULE_LICENSE("GPL");
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index 8f1f4b4..ccc78ab 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -1254,11 +1254,6 @@ MODULE_LICENSE ("GPL");
 #define	PLATFORM_DRIVER		ehci_hcd_w90x900_driver
 #endif
 
-#ifdef CONFIG_ARCH_AT91
-#include "ehci-atmel.c"
-#define	PLATFORM_DRIVER		ehci_atmel_driver
-#endif
-
 #ifdef CONFIG_USB_OCTEON_EHCI
 #include "ehci-octeon.c"
 #define PLATFORM_DRIVER		ehci_octeon_driver
@@ -1307,6 +1302,7 @@ MODULE_LICENSE ("GPL");
 	!IS_ENABLED(CONFIG_USB_EHCI_HCD_ORION) && \
 	!IS_ENABLED(CONFIG_USB_EHCI_HCD_SPEAR) && \
 	!IS_ENABLED(CONFIG_USB_EHCI_S5P) && \
+	!IS_ENABLED(CONFIG_USB_EHCI_HCD_AT91) && \
 	!defined(PLATFORM_DRIVER) && \
 	!defined(PS3_SYSTEM_BUS_DRIVER) && \
 	!defined(OF_PLATFORM_DRIVER) && \
-- 
1.8.1.2



From nicolas.ferre at atmel.com  Tue Apr  2 12:28:08 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Tue, 2 Apr 2013 18:28:08 +0200
Subject: [RFC PATCH] rtc: rtc-at91rm9200: manage IMR depending on revision
In-Reply-To: <515AFA0B.7020509@interlog.com>
References: <1364573029-19346-5-git-send-email-jhovold@gmail.com>
 <1364908007-5150-1-git-send-email-nicolas.ferre@atmel.com>
 <515AFA0B.7020509@interlog.com>
Message-ID: <515B0718.3060305@atmel.com>

On 04/02/2013 05:32 PM, Douglas Gilbert :
> On 13-04-02 09:06 AM, Nicolas Ferre wrote:
>> Signed-off-by: Nicolas Ferre <nicolas.ferre at atmel.com>
>> ---
>> Hi all,
>>
>> The funny thing is that I was writing exactly the same code as Johan's
>> when he posted his series.
>>
>> So, here is my single patch, with the comment about the readback
>> stolen from
>> Johan's, but without the way to determine with IP is buggy and which
>> one is
>> not...
>> After having dug the possibility to read the IP revision, I discovered
>> that it
>> is not possible to use this information ("version" register offset
>> changing
>> according to... IP version number: well done!).
>> In conclusion, I guess that the only way to determine if we need the
>> workaround
>> is to use the DT.
>> One remark though: if we use the compatibility string for this
>> purpose, I fear
>> that we would twist the meaning of this information: SoC using an
>> "atmel,at91sam9x5-rtc" compatible RTC will not necessarily be touched
>> by the
>> "non responding IMR" bug: at91sam9n12 or upcoming sama5d3 are not
>> affected for
>> instance, and we need to cling to "atmel,at91rm9200-rtc" for them...
>> I think that we can use this method for the moment and move to another
>> compatibility string later if it is needed.
> 
> Rather than have so many people working on rtc-at91rm9200.c,
> how about someone bring its "RTT" sibling into the DT
> world. I'm talking about drivers/rtc/rtc-at91sam9.c ...

I am currently trying to fix the issue that I have created by pushing a
boggus fix to Andrew's patch series (and "stable" incidentally).
So I am trying to find the best way to address this and:
- a correct
- a smallest possible
path or patch series (I admit that I prefer a single patch).

So, I am still posting rtc-at91rm9200.c patches and hoping from a
feedback. Once we have a good solution I will try to include it in 3.9
and the stable trees affected.

Best regards,
-- 
Nicolas Ferre


From nicolas.ferre at atmel.com  Tue Apr  2 12:36:06 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Tue, 2 Apr 2013 18:36:06 +0200
Subject: [RFC PATCH v2] rtc: rtc-at91rm9200: manage IMR depending on revision
In-Reply-To: <1364908007-5150-1-git-send-email-nicolas.ferre@atmel.com>
References: <1364908007-5150-1-git-send-email-nicolas.ferre@atmel.com>
Message-ID: <1364920566-30040-1-git-send-email-nicolas.ferre@atmel.com>

Signed-off-by: Nicolas Ferre <nicolas.ferre at atmel.com>
---
Hi again,

Here is my latest revision of this fix. It depends on the patch that is already
in Andrew's patch stack: "drivers-rtc-rtc-at91rm9200c-add-dt-support.patch".

I now use a different compatibility string to figure out what is the IP
revision that has the "boggus IMR" error. I think this way to handle it
is much simpler than the "config" structure one from Johan. The small number of
line changed and the "single patch" nature of it make me think that it will be
easier to send upstream and in the "stable" trees...

Please give feedback, but moreover, I would like to know if you (Johan and Douglas)
agree to give your "Signed-off-by" line because this patch is certainly
inspired by your comments, code and reviews.

Thank you for your help. Best regards,

 .../bindings/rtc/atmel,at91rm9200-rtc.txt          |   3 +-
 drivers/rtc/rtc-at91rm9200.c                       | 126 ++++++++++++++++-----
 drivers/rtc/rtc-at91rm9200.h                       |   1 +
 3 files changed, 101 insertions(+), 29 deletions(-)

diff --git a/Documentation/devicetree/bindings/rtc/atmel,at91rm9200-rtc.txt b/Documentation/devicetree/bindings/rtc/atmel,at91rm9200-rtc.txt
index 2a3feab..9b87053 100644
--- a/Documentation/devicetree/bindings/rtc/atmel,at91rm9200-rtc.txt
+++ b/Documentation/devicetree/bindings/rtc/atmel,at91rm9200-rtc.txt
@@ -1,7 +1,8 @@
 Atmel AT91RM9200 Real Time Clock
 
 Required properties:
-- compatible: should be: "atmel,at91rm9200-rtc"
+- compatible: should be: "atmel,at91rm9200-rtc", "atmel,at91sam9x5-rtc" or
+                         "atmel,at91sam9n12-rtc".
 - reg: physical base address of the controller and length of memory mapped
   region.
 - interrupts: rtc alarm/event interrupt
diff --git a/drivers/rtc/rtc-at91rm9200.c b/drivers/rtc/rtc-at91rm9200.c
index 29b92e4..f6b2ee3 100644
--- a/drivers/rtc/rtc-at91rm9200.c
+++ b/drivers/rtc/rtc-at91rm9200.c
@@ -25,6 +25,7 @@
 #include <linux/rtc.h>
 #include <linux/bcd.h>
 #include <linux/interrupt.h>
+#include <linux/spinlock.h>
 #include <linux/ioctl.h>
 #include <linux/completion.h>
 #include <linux/io.h>
@@ -47,6 +48,69 @@ static unsigned int at91_alarm_year = AT91_RTC_EPOCH;
 static void __iomem *at91_rtc_regs;
 static int irq;
 static u32 at91_rtc_imr;
+static DEFINE_SPINLOCK(lock);
+static void (*at91_rtc_set_irq)(u32 irq_mask);
+static void (*at91_rtc_clear_irq)(u32 irq_mask);
+static u32 (*at91_rtc_read_imr)(void);
+
+static void at91_rtc_set_irq_simple(u32 irq_mask)
+{
+	at91_rtc_write(AT91_RTC_IER, irq_mask);
+}
+
+static void at91_rtc_clear_irq_simple(u32 irq_mask)
+{
+	at91_rtc_write(AT91_RTC_IDR, irq_mask);
+}
+
+static u32 at91_rtc_read_imr_simple(void)
+{
+	return at91_rtc_read(AT91_RTC_IMR);
+}
+
+static void at91_rtc_set_irq_brokenimr(u32 irq_mask)
+{
+	unsigned long flags;
+
+	spin_lock_irqsave(&lock, flags);
+	at91_rtc_imr |= irq_mask;
+	at91_rtc_write(AT91_RTC_IER, irq_mask);
+	spin_unlock_irqrestore(&lock, flags);
+}
+
+static void at91_rtc_clear_irq_brokenimr(u32 irq_mask)
+{
+	unsigned long flags;
+
+	spin_lock_irqsave(&lock, flags);
+	at91_rtc_write(AT91_RTC_IDR, irq_mask);
+	/*
+	 * Register read back (of any RTC-register) needed to make sure
+	 * IDR-register write has reached the peripheral before updating
+	 * shadow mask.
+	 *
+	 * Note that there is still a possibility that the mask is updated
+	 * before interrupts have actually been disabled in hardware. The only
+	 * way to be certain would be to poll the IMR-register, which is is
+	 * the very register we are trying to emulate. The register read back
+	 * is a reasonable heuristic.
+	 */
+	at91_rtc_read(AT91_RTC_SR);
+	at91_rtc_imr &= ~irq_mask;
+	spin_unlock_irqrestore(&lock, flags);
+}
+
+static u32 at91_rtc_read_imr_brokenimr(void)
+{
+	unsigned long flags;
+	u32 shadow_imr;
+
+	spin_lock_irqsave(&lock, flags);
+	shadow_imr = at91_rtc_imr;
+	spin_unlock_irqrestore(&lock, flags);
+
+	return shadow_imr;
+}
 
 /*
  * Decode time/date into rtc_time structure
@@ -111,11 +175,9 @@ static int at91_rtc_settime(struct device *dev, struct rtc_time *tm)
 	cr = at91_rtc_read(AT91_RTC_CR);
 	at91_rtc_write(AT91_RTC_CR, cr | AT91_RTC_UPDCAL | AT91_RTC_UPDTIM);
 
-	at91_rtc_imr |= AT91_RTC_ACKUPD;
-	at91_rtc_write(AT91_RTC_IER, AT91_RTC_ACKUPD);
+	at91_rtc_set_irq(AT91_RTC_ACKUPD);
 	wait_for_completion(&at91_rtc_updated);	/* wait for ACKUPD interrupt */
-	at91_rtc_write(AT91_RTC_IDR, AT91_RTC_ACKUPD);
-	at91_rtc_imr &= ~AT91_RTC_ACKUPD;
+	at91_rtc_clear_irq(AT91_RTC_ACKUPD);
 
 	at91_rtc_write(AT91_RTC_TIMR,
 			  bin2bcd(tm->tm_sec) << 0
@@ -147,7 +209,7 @@ static int at91_rtc_readalarm(struct device *dev, struct rtc_wkalrm *alrm)
 	tm->tm_yday = rtc_year_days(tm->tm_mday, tm->tm_mon, tm->tm_year);
 	tm->tm_year = at91_alarm_year - 1900;
 
-	alrm->enabled = (at91_rtc_imr & AT91_RTC_ALARM)
+	alrm->enabled = (at91_rtc_read_imr() & AT91_RTC_ALARM)
 			? 1 : 0;
 
 	dev_dbg(dev, "%s(): %4d-%02d-%02d %02d:%02d:%02d\n", __func__,
@@ -172,8 +234,7 @@ static int at91_rtc_setalarm(struct device *dev, struct rtc_wkalrm *alrm)
 	tm.tm_min = alrm->time.tm_min;
 	tm.tm_sec = alrm->time.tm_sec;
 
-	at91_rtc_write(AT91_RTC_IDR, AT91_RTC_ALARM);
-	at91_rtc_imr &= ~AT91_RTC_ALARM;
+	at91_rtc_clear_irq(AT91_RTC_ALARM);
 	at91_rtc_write(AT91_RTC_TIMALR,
 		  bin2bcd(tm.tm_sec) << 0
 		| bin2bcd(tm.tm_min) << 8
@@ -186,8 +247,7 @@ static int at91_rtc_setalarm(struct device *dev, struct rtc_wkalrm *alrm)
 
 	if (alrm->enabled) {
 		at91_rtc_write(AT91_RTC_SCCR, AT91_RTC_ALARM);
-		at91_rtc_imr |= AT91_RTC_ALARM;
-		at91_rtc_write(AT91_RTC_IER, AT91_RTC_ALARM);
+		at91_rtc_set_irq(AT91_RTC_ALARM);
 	}
 
 	dev_dbg(dev, "%s(): %4d-%02d-%02d %02d:%02d:%02d\n", __func__,
@@ -203,11 +263,9 @@ static int at91_rtc_alarm_irq_enable(struct device *dev, unsigned int enabled)
 
 	if (enabled) {
 		at91_rtc_write(AT91_RTC_SCCR, AT91_RTC_ALARM);
-		at91_rtc_imr |= AT91_RTC_ALARM;
-		at91_rtc_write(AT91_RTC_IER, AT91_RTC_ALARM);
+		at91_rtc_set_irq(AT91_RTC_ALARM);
 	} else {
-		at91_rtc_write(AT91_RTC_IDR, AT91_RTC_ALARM);
-		at91_rtc_imr &= ~AT91_RTC_ALARM;
+		at91_rtc_clear_irq(AT91_RTC_ALARM);
 	}
 
 	return 0;
@@ -217,10 +275,12 @@ static int at91_rtc_alarm_irq_enable(struct device *dev, unsigned int enabled)
  */
 static int at91_rtc_proc(struct device *dev, struct seq_file *seq)
 {
+	unsigned long imr = at91_rtc_read_imr();
+
 	seq_printf(seq, "update_IRQ\t: %s\n",
-			(at91_rtc_imr & AT91_RTC_ACKUPD) ? "yes" : "no");
+			(imr & AT91_RTC_ACKUPD) ? "yes" : "no");
 	seq_printf(seq, "periodic_IRQ\t: %s\n",
-			(at91_rtc_imr & AT91_RTC_SECEV) ? "yes" : "no");
+			(imr & AT91_RTC_SECEV) ? "yes" : "no");
 
 	return 0;
 }
@@ -235,7 +295,7 @@ static irqreturn_t at91_rtc_interrupt(int irq, void *dev_id)
 	unsigned int rtsr;
 	unsigned long events = 0;
 
-	rtsr = at91_rtc_read(AT91_RTC_SR) & at91_rtc_imr;
+	rtsr = at91_rtc_read(AT91_RTC_SR) & at91_rtc_read_imr();
 	if (rtsr) {		/* this interrupt is shared!  Is it ours? */
 		if (rtsr & AT91_RTC_ALARM)
 			events |= (RTC_AF | RTC_IRQF);
@@ -301,6 +361,18 @@ static int __init at91_rtc_probe(struct platform_device *pdev)
 					AT91_RTC_CALEV);
 	at91_rtc_imr = 0;
 
+	/* Choose IMR access functions */
+	at91_rtc_set_irq = at91_rtc_set_irq_simple;
+	at91_rtc_clear_irq = at91_rtc_clear_irq_simple;
+	at91_rtc_read_imr = at91_rtc_read_imr_simple;
+
+	if (pdev->dev.of_node
+	    && of_device_is_compatible(pdev->dev.of_node, "atmel,at91sam9x5-rtc")) {
+		at91_rtc_set_irq = at91_rtc_set_irq_brokenimr;
+		at91_rtc_clear_irq = at91_rtc_clear_irq_brokenimr;
+		at91_rtc_read_imr = at91_rtc_read_imr_brokenimr;
+	}
+
 	ret = request_irq(irq, at91_rtc_interrupt,
 				IRQF_SHARED,
 				"at91_rtc", pdev);
@@ -359,27 +431,23 @@ static int at91_rtc_suspend(struct device *dev)
 	/* this IRQ is shared with DBGU and other hardware which isn't
 	 * necessarily doing PM like we are...
 	 */
-	at91_rtc_bkpimr = at91_rtc_imr & (AT91_RTC_ALARM|AT91_RTC_SECEV);
+	at91_rtc_bkpimr = at91_rtc_read_imr() & (AT91_RTC_ALARM|AT91_RTC_SECEV);
 	if (at91_rtc_bkpimr) {
-		if (device_may_wakeup(dev)) {
+		if (device_may_wakeup(dev))
 			enable_irq_wake(irq);
-		} else {
-			at91_rtc_write(AT91_RTC_IDR, at91_rtc_bkpimr);
-			at91_rtc_imr &= ~at91_rtc_bkpimr;
-		}
-}
+		else
+			at91_rtc_clear_irq(at91_rtc_bkpimr);
+	}
 	return 0;
 }
 
 static int at91_rtc_resume(struct device *dev)
 {
 	if (at91_rtc_bkpimr) {
-		if (device_may_wakeup(dev)) {
+		if (device_may_wakeup(dev))
 			disable_irq_wake(irq);
-		} else {
-			at91_rtc_imr |= at91_rtc_bkpimr;
-			at91_rtc_write(AT91_RTC_IER, at91_rtc_bkpimr);
-		}
+		else
+			at91_rtc_set_irq(at91_rtc_bkpimr);
 	}
 	return 0;
 }
@@ -397,6 +465,8 @@ static const struct dev_pm_ops at91_rtc_pm = {
 
 static const struct of_device_id at91_rtc_dt_ids[] = {
 	{ .compatible = "atmel,at91rm9200-rtc" },
+	{ .compatible = "atmel,at91sam9x5-rtc" },
+	{ .compatible = "atmel,at91sam9n12-rtc" },
 	{ /* sentinel */ }
 };
 MODULE_DEVICE_TABLE(of, at91_rtc_dt_ids);
diff --git a/drivers/rtc/rtc-at91rm9200.h b/drivers/rtc/rtc-at91rm9200.h
index 5f940b6..da1945e 100644
--- a/drivers/rtc/rtc-at91rm9200.h
+++ b/drivers/rtc/rtc-at91rm9200.h
@@ -64,6 +64,7 @@
 #define	AT91_RTC_SCCR		0x1c			/* Status Clear Command Register */
 #define	AT91_RTC_IER		0x20			/* Interrupt Enable Register */
 #define	AT91_RTC_IDR		0x24			/* Interrupt Disable Register */
+#define	AT91_RTC_IMR		0x28			/* Interrupt Mask Register */
 
 #define	AT91_RTC_VER		0x2c			/* Valid Entry Register */
 #define		AT91_RTC_NVTIM		(1 <<  0)		/* Non valid Time */
-- 
1.8.0



From jon-hunter at ti.com  Tue Apr  2 12:38:28 2013
From: jon-hunter at ti.com (Jon Hunter)
Date: Tue, 2 Apr 2013 11:38:28 -0500
Subject: [RFC][BUG] arm/dts: OMAP3: set #interrupt-cells to two
In-Reply-To: <1364918124.5935.145.camel@mars>
References: <1364631689.3767.7.camel@mars>
 <CAAwP0s35J-edpvFv08xjjpwaezQBYNvMNhhXL-UacsuUtSt4ZA@mail.gmail.com>
 <1364834508.3939.74.camel@mars>
 <CAAwP0s1H9zaBZPMDz9=He-E68UK0Ay3jnxZ2frYH9r1xNeQhxQ@mail.gmail.com>
 <1364918124.5935.145.camel@mars>
Message-ID: <515B0984.7050803@ti.com>


On 04/02/2013 10:55 AM, Christoph Fritz wrote:
> On Mon, 2013-04-01 at 22:05 +0200, Javier Martinez Canillas wrote:
> 
>>> As a quick-fix (hack) I wrote directly to the registers in gpio_probe()
>>> to enable GPIO banks. I now geht this:
>>>
>>>>> [    0.214630] omap_gpio_probe, 1133, CM_CLKSEL_PER 0x48005040: 0x000000ff
>>>>> [    0.214660] omap_gpio_probe, 1136, CM_ICLKEN_PER 0x48005010: 0x0007ffff
>>>>> [    0.214660] omap_gpio_probe, 1139, CM_FCLKEN_PER 0x48005000: 0x0007ffff
> 
> to be more specific on this point, this is the patch to enable the
> gpio-clocks:
> 
> --
> Subject: [PATCH] HACK: enable gpio-clocks in gpio-omap probe()
> 
> Without this patch setting trigger value from #interrupt-cell two
> (smsc911x) fails.
> ---
>  drivers/gpio/gpio-omap.c |   12 ++++++++++++
>  1 file changed, 12 insertions(+)
> 
> diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
> index 159f5c5..720b2e6 100644
> --- a/drivers/gpio/gpio-omap.c
> +++ b/drivers/gpio/gpio-omap.c
> @@ -1098,6 +1098,7 @@ static int omap_gpio_probe(struct platform_device
> *pdev)
>  	struct resource *res;
>  	struct gpio_bank *bank;
>  	int ret = 0;
> +	void __iomem *tmp;
> 
>  	match = of_match_device(of_match_ptr(omap_gpio_match), dev);
> 
> @@ -1117,6 +1118,17 @@ static int omap_gpio_probe(struct platform_device
> *pdev)
>  		return -ENODEV;
>  	}
> 
> +	// TRM: Table 3-242. PER_CM Register Summary
> +	tmp = ioremap(0x48005040, 4); //CM_CLKSEL_PER, GPT2 = sys clk
> +	writel(0xFF, tmp);
> +	iounmap(tmp);
> +	tmp = ioremap(0x48005010, 4); //CM_ICLKEN_PER, ICKen GPT2
> +	writel(0x7FFFF, tmp);
> +	iounmap(tmp);
> +	tmp = ioremap(0x48005000, 4); //CM_FCLKEN_PER, GPIOX functional clock
> is enabled
> +	writel(0x7FFFF, tmp);
> +	iounmap(tmp);
> +
>  	bank->irq = res->start;
>  	bank->dev = dev;
>  	bank->dbck_flag = pdata->dbck_flag;
> 
> Is there a better way to do this?

A better way to hack this and leave the gpio bank on always would be ...

diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index f1fbedb2..0fc75a2 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -1181,8 +1181,6 @@ static int omap_gpio_probe(struct platform_device *pdev)
        if (bank->loses_context)
                bank->get_context_loss_count = pdata->get_context_loss_count;
 
-       pm_runtime_put(bank->dev);
-
        list_add_tail(&bank->node, &omap_gpio_list);
 
        return ret;

>>> And it works for me. _But_ when I do enable regulator twl4030
>>> (CONFIG_REGULATOR_TWL4030=y) in my config these registers get reset:
>>>
>>> [    2.935455] smsc911x_open, 1537, CM_CLKSEL_PER 0x48005040: 0x000000ff
>>> [    2.942291] smsc911x_open, 1540, CM_ICLKEN_PER 0x48005010: 0x00040fff
>>> [    2.949066] smsc911x_open, 1543, CM_FCLKEN_PER 0x48005000: 0x00000000
>>>
>>> And the IRQ source for the network chip (smsc911x) is disabled :-(
> 
> CONFIG_REGULATOR_TWL4030=y  disables the gpio-clocks. Why is that?

Well your hack is completely by-passing pm-runtime and so pm-runtime does not
know that someone has enabled the bank. Therefore, the next time pm_runtime_get()
is called followed by a pm_runtime_put() for the gpio bank it will disable the
bank. By removing the pm_runtime_put() at the end of probe should always keep the
bank enabled.

>>> Do you have any idea how to ("quick") fix this?
>>>
>>
>> A quick hack is to call gpio_request() explicitly before calling to
>> irq_set_type() is made.
>> I've this patch just to make it work until we find a clean solution:
>>
>> diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
>> index 90c15ee..d594e1d 100644
>> --- a/arch/arm/mach-omap2/gpmc.c
>> +++ b/arch/arm/mach-omap2/gpmc.c
>> @@ -14,6 +14,7 @@
>>   */
>>  #undef DEBUG
>>
>> +#include <linux/gpio.h>
>>  #include <linux/irq.h>
>>  #include <linux/kernel.h>
>>  #include <linux/init.h>
>> @@ -1528,6 +1529,11 @@ static int gpmc_probe_dt(struct platform_device *pdev)
>>                 return ret;
>>         }
>>
>> +       ret = gpio_request_one(176, GPIOF_IN, "smsc911x irq");
>> +       if (ret) {
>> +               pr_err("Failed to request IRQ GPIO%d\n", 176);
>> +               return ret;
>> +       }
>> +
>>         for_each_node_by_name(child, "nand") {
>>                 ret = gpmc_probe_nand_child(pdev, child);
>>                 if (ret < 0) {
>>
>> This solves the issue of the non-initialized GPIO bank before that
>> makes the kernel to hang.
> 
> Here it does not. A printk shows that I'm not using gpmc at all.
> So I added a gpmc node:
> 
> +       gpmc: gpmc at 0x6E000000 {
> +               compatible = "ti,omap3430-gpmc";
> +               ti,hwmods = "ti,gpmc";

This should just be ...

+               ti,hwmods = "gpmc";

> +               reg = <0x6E000000 0x2000>;
> +               gpmc,num-cs = <8>;
> +               gpmc,num-waitpins = <2>;
> +               #address-cells = <2>;
> +               #size-cells = <1>;
> +               ranges = <0 0 0x0 0x3FFFFFFF>;
> +
> +       };
> 
> But still, gpmc_probe_dt() isn't called. I maybe have to define some
> child nodes but currently I do configure the gpmc in u-boot and try to
> avoid kernel-gpmc-config.

Not sure what patches you have, but the plan for DT is that the kernel
configures the gpmc and is not dependent on the bootloader.

Cheers
Jon


From pawel.moll at arm.com  Tue Apr  2 12:40:09 2013
From: pawel.moll at arm.com (Pawel Moll)
Date: Tue, 02 Apr 2013 17:40:09 +0100
Subject: [PATCH 04/10] arm: zynq: Load scu baseaddress at run time
In-Reply-To: <CAHTX3d+1auKVLko+LKAA+a4rh4Rfw19ggzmS7DhvYuuCAWUwHA@mail.gmail.com>
References: <1364219596-4954-1-git-send-email-michal.simek@xilinx.com>
 <1364219596-4954-4-git-send-email-michal.simek@xilinx.com>
 <515059D4.5070903@gmail.com>
 <CAHTX3dJfvFNNuyJC54fS=NCpRxovVsxHTss8wJd_QOB2PaxL7g@mail.gmail.com>
 <51506F31.2080709@gmail.com>
 <CAHTX3d+1auKVLko+LKAA+a4rh4Rfw19ggzmS7DhvYuuCAWUwHA@mail.gmail.com>
Message-ID: <1364920809.3019.30.camel@hornet>

Greetings,

Apologies about "slightly" delayed response.

On Mon, 2013-03-25 at 16:07 +0000, Michal Simek wrote:
> Pawel: You are the author of this code in vexpress. Is there any
> particular reason
> to have there that ioremap?

At the time there was no standard DT->platsmp solution and the
traditional way was using the SCU to work out the CPUs.

If I was doing this today (and I'll re-do this code at some point) I'd
rely on the DT in the first place and maybe then have a SCU
"micro-driver" double-checking the DT data against the SCU information.
That way I could reduce the dependency on static mappings. And this is
what I want to get - if possible I don't want any static mapping at all.

Pawe?




From pawel.moll at arm.com  Tue Apr  2 12:41:10 2013
From: pawel.moll at arm.com (Pawel Moll)
Date: Tue, 02 Apr 2013 17:41:10 +0100
Subject: [PATCH v2 06/13] ARM: vexpress: remove sp804 OF init
In-Reply-To: <1364854883-5961-7-git-send-email-robherring2@gmail.com>
References: <1364854883-5961-1-git-send-email-robherring2@gmail.com>
 <1364854883-5961-7-git-send-email-robherring2@gmail.com>
Message-ID: <1364920870.3019.31.camel@hornet>

On Mon, 2013-04-01 at 23:21 +0100, Rob Herring wrote:
> From: Rob Herring <rob.herring at calxeda.com>
> 
> Remove the vexpress specific setup for the sp804 timer now that
> clocksource_of_init will do it.
> 
> Signed-off-by: Rob Herring <rob.herring at calxeda.com>
> ---
>  arch/arm/mach-vexpress/v2m.c |   11 -----------
>  1 file changed, 11 deletions(-)
> 
> diff --git a/arch/arm/mach-vexpress/v2m.c b/arch/arm/mach-vexpress/v2m.c
> index 6215717..cdc29d8 100644
> --- a/arch/arm/mach-vexpress/v2m.c
> +++ b/arch/arm/mach-vexpress/v2m.c
> @@ -431,20 +431,9 @@ void __init v2m_dt_init_early(void)
>  
>  static void __init v2m_dt_timer_init(void)
>  {
> -	struct device_node *node = NULL;
> -
>  	vexpress_clk_of_init();
>  
>  	clocksource_of_init();
> -	do {
> -		node = of_find_compatible_node(node, NULL, "arm,sp804");
> -	} while (node && vexpress_get_site_by_node(node) != VEXPRESS_SITE_MB);
> -	if (node) {
> -		pr_info("Using SP804 '%s' as a clock & events source\n",
> -				node->full_name);
> -		v2m_sp804_init(of_iomap(node, 0),
> -				irq_of_parse_and_map(node, 0));
> -	}
>  
>  	versatile_sched_clock_init(vexpress_get_24mhz_clock_base(),
>  				24000000);

Acked-by: Pawel Moll <pawel.moll at arm.com>

Thanks!

Pawel




From will.deacon at arm.com  Tue Apr  2 12:46:38 2013
From: will.deacon at arm.com (Will Deacon)
Date: Tue, 2 Apr 2013 17:46:38 +0100
Subject: [PATCH v5 1/3] arm: introduce psci_smp_ops
In-Reply-To: <1364919374-7836-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1304021700380.5078@kaball.uk.xensource.com>
 <1364919374-7836-1-git-send-email-stefano.stabellini@eu.citrix.com>
Message-ID: <20130402164638.GG6608@mudshark.cambridge.arm.com>

On Tue, Apr 02, 2013 at 05:16:12PM +0100, Stefano Stabellini wrote:
> Rename virt_smp_ops to psci_smp_ops and move them to arch/arm/kernel/psci_smp.c.
> Remove mach-virt/platsmp.c, now unused.
> Compile psci_smp if CONFIG_ARM_PSCI and CONFIG_SMP.
> 
> Add a cpu_die smp_op based on psci_ops.cpu_off.
> 
> Initialize PSCI before setting smp_ops in setup_arch.
> Use psci_smp_ops if the platform doesn't provide its own smp_ops.
> 
> 
> Changes in v5:
> - document psci_operations;
> - psci_init returns NULL.
> 
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
> Acked-by: Nicolas Pitre <nico at linaro.org>
> Acked-by: Rob Herring <rob.herring at calxeda.com>
> 
> CC: will.deacon at arm.com
> CC: arnd at arndb.de
> CC: marc.zyngier at arm.com
> CC: linux at arm.linux.org.uk
> CC: nico at linaro.org
> ---
>  arch/arm/include/asm/psci.h  |   29 ++++++++++++++++++
>  arch/arm/kernel/Makefile     |    5 ++-
>  arch/arm/kernel/psci.c       |    7 ++--
>  arch/arm/kernel/psci_smp.c   |   67 ++++++++++++++++++++++++++++++++++++++++++
>  arch/arm/kernel/setup.c      |    7 ++++-
>  arch/arm/mach-virt/Makefile  |    1 -
>  arch/arm/mach-virt/platsmp.c |   58 ------------------------------------
>  arch/arm/mach-virt/virt.c    |    3 --
>  8 files changed, 109 insertions(+), 68 deletions(-)
>  create mode 100644 arch/arm/kernel/psci_smp.c
>  delete mode 100644 arch/arm/mach-virt/platsmp.c

Reviewed-by: Will Deacon <will.deacon at arm.com>

Will


From pawel.moll at arm.com  Tue Apr  2 12:47:41 2013
From: pawel.moll at arm.com (Pawel Moll)
Date: Tue, 02 Apr 2013 17:47:41 +0100
Subject: [PATCH v2 07/13] ARM: dts: vexpress: disable CA9 core tile
 sp804 timer
In-Reply-To: <1364854883-5961-8-git-send-email-robherring2@gmail.com>
References: <1364854883-5961-1-git-send-email-robherring2@gmail.com>
 <1364854883-5961-8-git-send-email-robherring2@gmail.com>
Message-ID: <1364921261.3019.38.camel@hornet>

On Mon, 2013-04-01 at 23:21 +0100, Rob Herring wrote:
> From: Rob Herring <rob.herring at calxeda.com>
> 
> The motherboard sp804 timer is used, but core tile sp804 timer is not.
> According to Russell King, the clock configuration is undocumented and
> defaults to 32kHz which is not desireable. So mark core tile sp804 timer
> as disabled.
> 
> Signed-off-by: Rob Herring <rob.herring at calxeda.com>
> ---
>  arch/arm/boot/dts/vexpress-v2p-ca9.dts |    1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/boot/dts/vexpress-v2p-ca9.dts b/arch/arm/boot/dts/vexpress-v2p-ca9.dts
> index 1420bb1..62d9b22 100644
> --- a/arch/arm/boot/dts/vexpress-v2p-ca9.dts
> +++ b/arch/arm/boot/dts/vexpress-v2p-ca9.dts
> @@ -98,6 +98,7 @@
>  			     <0 49 4>;
>  		clocks = <&oscclk2>, <&oscclk2>;
>  		clock-names = "timclk", "apb_pclk";
> +		status = "disabled";
>  	};
>  
>  	watchdog at 100e5000 {

I'm not sure if this is necessary. The parent oscclk2 (frequency
33-100MHz) should provide enough information for SP804 to work. One
thing that worries me is that it may be not available (not registered
yet) at the time of SP804 initialisation, but then the driver would
simply give up (I hope) on this instance so we would be us back in the
situation where it's not used. I'll try to give this stuff a spin soon.

Pawe?




From linux-arm at overkiz.com  Tue Apr  2 12:46:51 2013
From: linux-arm at overkiz.com (Boris BREZILLON)
Date: Tue,  2 Apr 2013 18:46:51 +0200
Subject: [PATCH] ARM: at91/tc: fix clock source id for tc block > 1
Message-ID: <1364921211-15756-1-git-send-email-linux-arm@overkiz.com>

This patch fixes wrong clock request for TC block 2.
The second block was using t0_clk, t1_clk and t2_clk clks instead of
t3_clk, t4_clk and t5_clk clks.


Signed-off-by: Boris BREZILLON <linux-arm at overkiz.com>
---
 drivers/misc/atmel_tclib.c |   24 ++++++++++++++++--------
 1 file changed, 16 insertions(+), 8 deletions(-)

diff --git a/drivers/misc/atmel_tclib.c b/drivers/misc/atmel_tclib.c
index c8d8e38..768a988 100644
--- a/drivers/misc/atmel_tclib.c
+++ b/drivers/misc/atmel_tclib.c
@@ -142,6 +142,8 @@ static int __init tc_probe(struct platform_device *pdev)
 	struct atmel_tc *tc;
 	struct clk	*clk;
 	int		irq;
+	char		clk_id[7];
+	int		clk_offset;
 
 	if (!platform_get_resource(pdev, IORESOURCE_MEM, 0))
 		return -EINVAL;
@@ -156,25 +158,31 @@ static int __init tc_probe(struct platform_device *pdev)
 
 	tc->pdev = pdev;
 
-	clk = clk_get(&pdev->dev, "t0_clk");
-	if (IS_ERR(clk)) {
-		kfree(tc);
-		return -EINVAL;
-	}
-
 	/* Now take SoC information if available */
 	if (pdev->dev.of_node) {
 		const struct of_device_id *match;
 		match = of_match_node(atmel_tcb_dt_ids, pdev->dev.of_node);
 		if (match)
 			tc->tcb_config = match->data;
+		clk_offset = of_alias_get_id(tc->pdev->dev.of_node, "tcb");
+	} else
+		clk_offset = pdev->id;
+	clk_offset *= 3;
+
+	snprintf(clk_id, sizeof(clk_id), "t%d_clk", clk_offset++);
+	clk = clk_get(&pdev->dev, clk_id);
+	if (IS_ERR(clk)) {
+		kfree(tc);
+		return -EINVAL;
 	}
 
 	tc->clk[0] = clk;
-	tc->clk[1] = clk_get(&pdev->dev, "t1_clk");
+	snprintf(clk_id, sizeof(clk_id), "t%d_clk", clk_offset++);
+	tc->clk[1] = clk_get(&pdev->dev, clk_id);
 	if (IS_ERR(tc->clk[1]))
 		tc->clk[1] = clk;
-	tc->clk[2] = clk_get(&pdev->dev, "t2_clk");
+	snprintf(clk_id, sizeof(clk_id), "t%d_clk", clk_offset++);
+	tc->clk[2] = clk_get(&pdev->dev, clk_id);
 	if (IS_ERR(tc->clk[2]))
 		tc->clk[2] = clk;
 
-- 
1.7.9.5



From pawel.moll at arm.com  Tue Apr  2 12:48:20 2013
From: pawel.moll at arm.com (Pawel Moll)
Date: Tue, 02 Apr 2013 17:48:20 +0100
Subject: [PATCH v2 08/13] ARM: vexpress: remove extra timer-sp control
 register clearing
In-Reply-To: <1364854883-5961-9-git-send-email-robherring2@gmail.com>
References: <1364854883-5961-1-git-send-email-robherring2@gmail.com>
 <1364854883-5961-9-git-send-email-robherring2@gmail.com>
Message-ID: <1364921300.3019.39.camel@hornet>

On Mon, 2013-04-01 at 23:21 +0100, Rob Herring wrote:
> From: Rob Herring <rob.herring at calxeda.com>
> 
> The timer-sp initialization code clears the control register before
> initializing the timers, so every platform doing this is redundant.
> 
> Signed-off-by: Rob Herring <rob.herring at calxeda.com>
> ---
>  arch/arm/mach-vexpress/v2m.c |    3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/arch/arm/mach-vexpress/v2m.c b/arch/arm/mach-vexpress/v2m.c
> index cdc29d8..09e571d 100644
> --- a/arch/arm/mach-vexpress/v2m.c
> +++ b/arch/arm/mach-vexpress/v2m.c
> @@ -61,9 +61,6 @@ static void __init v2m_sp804_init(void __iomem *base, unsigned int irq)
>  	if (WARN_ON(!base || irq == NO_IRQ))
>  		return;
>  
> -	writel(0, base + TIMER_1_BASE + TIMER_CTRL);
> -	writel(0, base + TIMER_2_BASE + TIMER_CTRL);
> -
>  	sp804_clocksource_init(base + TIMER_2_BASE, "v2m-timer1");
>  	sp804_clockevents_init(base + TIMER_1_BASE, irq, "v2m-timer0");
>  }

Acked-by: Pawel Moll <pawel.moll at arm.com>

Thanks!

Pawel




From will.deacon at arm.com  Tue Apr  2 12:51:14 2013
From: will.deacon at arm.com (Will Deacon)
Date: Tue, 2 Apr 2013 17:51:14 +0100
Subject: [PATCH] ARM: Fix typo "CONFIG_LPAE" twice
In-Reply-To: <1364563104.1345.74.camel@x61.thuisdomein>
References: <1364563104.1345.74.camel@x61.thuisdomein>
Message-ID: <20130402165114.GI6608@mudshark.cambridge.arm.com>

Hi Paul,

On Fri, Mar 29, 2013 at 01:18:24PM +0000, Paul Bolle wrote:
> Signed-off-by: Paul Bolle <pebolle at tiscali.nl>
> ---
> 0) Untested.
> 
> 1) This typo was first introduced in v3.4: commit
> e5ab85800820edd907d3f43f285e1232f84d5a41 ("ARM: 7382/1: mm: truncate
> memory banks to fit in 4GB space for classic MMU"). The second instance
> was added in v3.9-rc2: commit d61947a164760ac520cb416768afdf38c33d60e7
> (" ARM: 7657/1: head: fix swapper and idmap population with LPAE and
> big-endian"). So testing is really needed here.
> 
> 2) If this passes (review and) testing, this probably needs to go to
> stable too.
> 
>  arch/arm/kernel/head.S  | 2 +-
>  arch/arm/kernel/setup.c | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
> index e0eb9a1..8bac553 100644
> --- a/arch/arm/kernel/head.S
> +++ b/arch/arm/kernel/head.S
> @@ -267,7 +267,7 @@ __create_page_tables:
>  	addne	r6, r6, #1 << SECTION_SHIFT
>  	strne	r6, [r3]
>  
> -#if defined(CONFIG_LPAE) && defined(CONFIG_CPU_ENDIAN_BE8)
> +#if defined(CONFIG_ARM_LPAE) && defined(CONFIG_CPU_ENDIAN_BE8)
>  	sub	r4, r4, #4			@ Fixup page table pointer
>  						@ for 64-bit descriptors
>  #endif

The problem with this code is that there are very few people with platforms
on which they can test it. You need an LPAE-capable CPU (Cortex-A7 or
Cortex-A15) sitting on a big-endian platform. The only platform that I have
for that is KVM, which doesn't have earlyprintk support.

Now, without the offending patch, such a configuration didn't even boot, but
I can't verify that the mapping actually works. Of course, what you have
written was the intended behaviour, so perhaps we should just go with that
for the time being.

Will


From jon-hunter at ti.com  Tue Apr  2 12:55:46 2013
From: jon-hunter at ti.com (Jon Hunter)
Date: Tue, 2 Apr 2013 11:55:46 -0500
Subject: [GIT PULL] ARM: OMAP2+: GPMC updates
Message-ID: <515B0D92.6070503@ti.com>

The following changes since commit dca3a783400a18e2bf4503b1d4a85c4d0ca1a7e4:

  Merge commit '31d9adca82ce65e5c99d045b5fd917c702b6fce3' into tmp (2013-04-01 14:33:50 -0500)

are available in the git repository at:


  git://github.com/jonhunter/linux.git omap-gpmc-for-v3.10

for you to fetch changes up to c67bd6e7cad2160c3bbfa2ac2bd954f918301c23:

  ARM: OMAP2+: Add GPMC DT support for Ethernet child nodes (2013-04-01 14:53:50 -0500)

----------------------------------------------------------------
Adds GPMC DT support for NOR flash and Ethernet and includes
various GPMC cleans-up and fixes.

This series is dependent on commit 7185684 (ARM: OMAP: use
consistent error checking) from RMK's clean-up branch and commit
31d9adc (ARM: OMAP2+: Fix broken gpmc support).
----------------------------------------------------------------
Ezequiel Garcia (8):
      ARM: omap2: gpmc: Mark local scoped functions static
      ARM: omap2: gpmc: Remove unused gpmc_round_ns_to_ticks() function
      ARM: omap2: gpmc: Fix gpmc_cs_reserved() return value
      ARM: omap2: gpmc-nand: Print something useful on CS request failure
      ARM: omap2: gpmc-onenand: Print something useful on CS request failure
      ARM: omap2: gpmc-onenand: Replace pr_err() with dev_err()
      ARM: omap2: gpmc-onenand: Replace printk KERN_ERR with dev_warn()
      ARM: omap2: gpmc: Remove redundant chip select out of range check

Javier Martinez Canillas (3):
      ARM: OMAP2+: return -ENODEV if GPMC child device creation fails
      ARM: OMAP2+: rename gpmc_probe_nor_child() to gpmc_probe_generic_child()
      ARM: OMAP2+: Add GPMC DT support for Ethernet child nodes

Jon Hunter (17):
      ARM: OMAP2+: Simplify code configuring ONENAND devices
      ARM: OMAP2+: Add variable to store number of GPMC waitpins
      ARM: OMAP2+: Add structure for storing GPMC settings
      ARM: OMAP2+: Add function for configuring GPMC settings
      ARM: OMAP2+: Convert ONENAND to use gpmc_cs_program_settings()
      ARM: OMAP2+: Convert NAND to use gpmc_cs_program_settings()
      ARM: OMAP2+: Convert SMC91x to use gpmc_cs_program_settings()
      ARM: OMAP2+: Convert TUSB to use gpmc_cs_program_settings()
      ARM: OMAP2+: Don't configure of chip-select options in gpmc_cs_configure()
      ARM: OMAP2+: Add function to read GPMC settings from device-tree
      ARM: OMAP2+: Add additional GPMC timing parameters
      ARM: OMAP2+: Add device-tree support for NOR flash
      ARM: OMAP2+: Convert NAND to retrieve GPMC settings from DT
      ARM: OMAP2+: Convert ONENAND to retrieve GPMC settings from DT
      ARM: OMAP2+: Detect incorrectly aligned GPMC base address
      ARM: OMAP2+: Remove unnecesssary GPMC definitions and variable
      ARM: OMAP2+: Allow GPMC probe to complete even if CS mapping fails

Mark Jackson (1):
      ARM: OMAP: Clear GPMC bits when applying new setting.

 Documentation/devicetree/bindings/bus/ti-gpmc.txt  |  103 +++-
 Documentation/devicetree/bindings/mtd/gpmc-nor.txt |   98 ++++
 .../devicetree/bindings/mtd/gpmc-onenand.txt       |    3 +
 Documentation/devicetree/bindings/net/gpmc-eth.txt |   97 ++++
 arch/arm/mach-omap2/gpmc-nand.c                    |   42 +-
 arch/arm/mach-omap2/gpmc-onenand.c                 |  118 ++---
 arch/arm/mach-omap2/gpmc-smc91x.c                  |   30 +-
 arch/arm/mach-omap2/gpmc.c                         |  544 ++++++++++++++------
 arch/arm/mach-omap2/gpmc.h                         |   43 +-
 arch/arm/mach-omap2/usb-tusb6010.c                 |   62 ++-
 10 files changed, 831 insertions(+), 309 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/mtd/gpmc-nor.txt
 create mode 100644 Documentation/devicetree/bindings/net/gpmc-eth.txt


From darrick.wong at oracle.com  Tue Apr  2 13:01:43 2013
From: darrick.wong at oracle.com (Darrick J. Wong)
Date: Tue, 2 Apr 2013 10:01:43 -0700
Subject: [PATCH v3] mm: Make snapshotting pages for stable writes a
 per-bio operation
In-Reply-To: <20130318230259.GP5313@blackbox.djwong.org>
References: <20130312153221.0d26fe5599d4885e51bb0c7c@linux-foundation.org>
 <20130313011020.GA5313@blackbox.djwong.org>
 <20130313085021.GA29730@quack.suse.cz>
 <20130313194429.GE5313@blackbox.djwong.org>
 <20130313210216.GA7754@quack.suse.cz>
 <20130314224243.GI5313@blackbox.djwong.org>
 <20130315100105.GA4889@quack.suse.cz>
 <20130315232816.GN5313@blackbox.djwong.org>
 <20130318174134.GB7852@quack.suse.cz>
 <20130318230259.GP5313@blackbox.djwong.org>
Message-ID: <20130402170143.GA8910@blackbox.djwong.org>

Hi,

A couple of weeks have gone by without further comments about this patch.

Are you interested in the minor cleanups and added comments, or is the v2 patch
in -next good enough?

Apparently Mel Gorman's interested in this patchset too.  Mel: Most of stable
pages part 2 are already in upstream for 3.9... except this piece.  Are you
interested in having this piece in 3.9 also?  Or is 3.10 good enough for
everyone?

--D

Mon, Mar 18, 2013 at 04:02:59PM -0700, Darrick J. Wong wrote:
> Walking a bio's page mappings has proved problematic, so create a new bio flag
> to indicate that a bio's data needs to be snapshotted in order to guarantee
> stable pages during writeback.  Next, for the one user (ext3/jbd) of
> snapshotting, hook all the places where writes can be initiated without
> PG_writeback set, and set BIO_SNAP_STABLE there.  We must also flag journal
> "metadata" bios for stable writeout, since file data can be written through the
> journal.  Finally, the MS_SNAP_STABLE mount flag (only used by ext3) is now
> superfluous, so get rid of it.
> 
> Signed-off-by: Darrick J. Wong <darrick.wong at oracle.com>
> 
> [darrick.wong at oracle.com: Fold in a couple of small cleanups from akpm]
> Signed-off-by: Andrew Morton <akpm at linux-foundation.org>
> ---
>  fs/buffer.c                 |    9 ++++++++-
>  fs/ext3/super.c             |    1 -
>  fs/jbd/commit.c             |   25 ++++++++++++++++++++++---
>  include/linux/blk_types.h   |    3 ++-
>  include/linux/buffer_head.h |    1 +
>  include/uapi/linux/fs.h     |    1 -
>  mm/bounce.c                 |   21 +--------------------
>  mm/page-writeback.c         |    4 ----
>  8 files changed, 34 insertions(+), 31 deletions(-)
> 
> diff --git a/fs/buffer.c b/fs/buffer.c
> index b4dcb34..71578d6 100644
> --- a/fs/buffer.c
> +++ b/fs/buffer.c
> @@ -2949,7 +2949,7 @@ static void guard_bh_eod(int rw, struct bio *bio, struct buffer_head *bh)
>  	}
>  }
>  
> -int submit_bh(int rw, struct buffer_head * bh)
> +int _submit_bh(int rw, struct buffer_head *bh, unsigned long bio_flags)
>  {
>  	struct bio *bio;
>  	int ret = 0;
> @@ -2984,6 +2984,7 @@ int submit_bh(int rw, struct buffer_head * bh)
>  
>  	bio->bi_end_io = end_bio_bh_io_sync;
>  	bio->bi_private = bh;
> +	bio->bi_flags |= bio_flags;
>  
>  	/* Take care of bh's that straddle the end of the device */
>  	guard_bh_eod(rw, bio, bh);
> @@ -2997,6 +2998,12 @@ int submit_bh(int rw, struct buffer_head * bh)
>  	bio_put(bio);
>  	return ret;
>  }
> +EXPORT_SYMBOL_GPL(_submit_bh);
> +
> +int submit_bh(int rw, struct buffer_head *bh)
> +{
> +	return _submit_bh(rw, bh, 0);
> +}
>  EXPORT_SYMBOL(submit_bh);
>  
>  /**
> diff --git a/fs/ext3/super.c b/fs/ext3/super.c
> index fb5120a..3dc48cc 100644
> --- a/fs/ext3/super.c
> +++ b/fs/ext3/super.c
> @@ -2067,7 +2067,6 @@ static int ext3_fill_super (struct super_block *sb, void *data, int silent)
>  		test_opt(sb,DATA_FLAGS) == EXT3_MOUNT_JOURNAL_DATA ? "journal":
>  		test_opt(sb,DATA_FLAGS) == EXT3_MOUNT_ORDERED_DATA ? "ordered":
>  		"writeback");
> -	sb->s_flags |= MS_SNAP_STABLE;
>  
>  	return 0;
>  
> diff --git a/fs/jbd/commit.c b/fs/jbd/commit.c
> index 86b39b1..11bb11f 100644
> --- a/fs/jbd/commit.c
> +++ b/fs/jbd/commit.c
> @@ -162,8 +162,17 @@ static void journal_do_submit_data(struct buffer_head **wbuf, int bufs,
>  
>  	for (i = 0; i < bufs; i++) {
>  		wbuf[i]->b_end_io = end_buffer_write_sync;
> -		/* We use-up our safety reference in submit_bh() */
> -		submit_bh(write_op, wbuf[i]);
> +		/*
> +		 * Here we write back pagecache data that may be mmaped. Since
> +		 * we cannot afford to clean the page and set PageWriteback
> +		 * here due to lock ordering (page lock ranks above transaction
> +		 * start), the data can change while IO is in flight. Tell the
> +		 * block layer it should bounce the bio pages if stable data
> +		 * during write is required.
> +		 *
> +		 * We use up our safety reference in submit_bh().
> +		 */
> +		_submit_bh(write_op, wbuf[i], 1 << BIO_SNAP_STABLE);
>  	}
>  }
>  
> @@ -667,7 +676,17 @@ start_journal_io:
>  				clear_buffer_dirty(bh);
>  				set_buffer_uptodate(bh);
>  				bh->b_end_io = journal_end_buffer_io_sync;
> -				submit_bh(write_op, bh);
> +				/*
> +				 * In data=journal mode, here we can end up
> +				 * writing pagecache data that might be
> +				 * mmapped. Since we can't afford to clean the
> +				 * page and set PageWriteback (see the comment
> +				 * near the other use of _submit_bh()), the
> +				 * data can change while the write is in
> +				 * flight.  Tell the block layer to bounce the
> +				 * bio pages if stable pages are required.
> +				 */
> +				_submit_bh(write_op, bh, 1 << BIO_SNAP_STABLE);
>  			}
>  			cond_resched();
>  
> diff --git a/include/linux/blk_types.h b/include/linux/blk_types.h
> index cdf1119..22990cf 100644
> --- a/include/linux/blk_types.h
> +++ b/include/linux/blk_types.h
> @@ -111,12 +111,13 @@ struct bio {
>  #define BIO_FS_INTEGRITY 9	/* fs owns integrity data, not block layer */
>  #define BIO_QUIET	10	/* Make BIO Quiet */
>  #define BIO_MAPPED_INTEGRITY 11/* integrity metadata has been remapped */
> +#define BIO_SNAP_STABLE	12	/* bio data must be snapshotted during write */
>  
>  /*
>   * Flags starting here get preserved by bio_reset() - this includes
>   * BIO_POOL_IDX()
>   */
> -#define BIO_RESET_BITS	12
> +#define BIO_RESET_BITS	13
>  
>  #define bio_flagged(bio, flag)	((bio)->bi_flags & (1 << (flag)))
>  
> diff --git a/include/linux/buffer_head.h b/include/linux/buffer_head.h
> index 5afc4f9..4c16c4a 100644
> --- a/include/linux/buffer_head.h
> +++ b/include/linux/buffer_head.h
> @@ -181,6 +181,7 @@ void ll_rw_block(int, int, struct buffer_head * bh[]);
>  int sync_dirty_buffer(struct buffer_head *bh);
>  int __sync_dirty_buffer(struct buffer_head *bh, int rw);
>  void write_dirty_buffer(struct buffer_head *bh, int rw);
> +int _submit_bh(int rw, struct buffer_head *bh, unsigned long bio_flags);
>  int submit_bh(int, struct buffer_head *);
>  void write_boundary_block(struct block_device *bdev,
>  			sector_t bblock, unsigned blocksize);
> diff --git a/include/uapi/linux/fs.h b/include/uapi/linux/fs.h
> index c7fc1e6..a4ed56c 100644
> --- a/include/uapi/linux/fs.h
> +++ b/include/uapi/linux/fs.h
> @@ -88,7 +88,6 @@ struct inodes_stat_t {
>  #define MS_STRICTATIME	(1<<24) /* Always perform atime updates */
>  
>  /* These sb flags are internal to the kernel */
> -#define MS_SNAP_STABLE	(1<<27) /* Snapshot pages during writeback, if needed */
>  #define MS_NOSEC	(1<<28)
>  #define MS_BORN		(1<<29)
>  #define MS_ACTIVE	(1<<30)
> diff --git a/mm/bounce.c b/mm/bounce.c
> index 5f89017..a5c2ec3 100644
> --- a/mm/bounce.c
> +++ b/mm/bounce.c
> @@ -181,32 +181,13 @@ static void bounce_end_io_read_isa(struct bio *bio, int err)
>  #ifdef CONFIG_NEED_BOUNCE_POOL
>  static int must_snapshot_stable_pages(struct request_queue *q, struct bio *bio)
>  {
> -	struct page *page;
> -	struct backing_dev_info *bdi;
> -	struct address_space *mapping;
> -	struct bio_vec *from;
> -	int i;
> -
>  	if (bio_data_dir(bio) != WRITE)
>  		return 0;
>  
>  	if (!bdi_cap_stable_pages_required(&q->backing_dev_info))
>  		return 0;
>  
> -	/*
> -	 * Based on the first page that has a valid mapping, decide whether or
> -	 * not we have to employ bounce buffering to guarantee stable pages.
> -	 */
> -	bio_for_each_segment(from, bio, i) {
> -		page = from->bv_page;
> -		mapping = page_mapping(page);
> -		if (!mapping)
> -			continue;
> -		bdi = mapping->backing_dev_info;
> -		return mapping->host->i_sb->s_flags & MS_SNAP_STABLE;
> -	}
> -
> -	return 0;
> +	return test_bit(BIO_SNAP_STABLE, &bio->bi_flags);
>  }
>  #else
>  static int must_snapshot_stable_pages(struct request_queue *q, struct bio *bio)
> diff --git a/mm/page-writeback.c b/mm/page-writeback.c
> index efe6814..4514ad7 100644
> --- a/mm/page-writeback.c
> +++ b/mm/page-writeback.c
> @@ -2311,10 +2311,6 @@ void wait_for_stable_page(struct page *page)
>  
>  	if (!bdi_cap_stable_pages_required(bdi))
>  		return;
> -#ifdef CONFIG_NEED_BOUNCE_POOL
> -	if (mapping->host->i_sb->s_flags & MS_SNAP_STABLE)
> -		return;
> -#endif /* CONFIG_NEED_BOUNCE_POOL */
>  
>  	wait_on_page_writeback(page);
>  }


From olof at lixom.net  Tue Apr  2 13:12:17 2013
From: olof at lixom.net (Olof Johansson)
Date: Tue, 2 Apr 2013 10:12:17 -0700
Subject: [PATCH] ARM: autcpu12: Fix config check in autcpu12_init_late()
In-Reply-To: <1364016140.352883792@f399.i.mail.ru>
References: <1363988123.3728.45.camel@deadeye.wl.decadent.org.uk>
 <1364016140.352883792@f399.i.mail.ru>
Message-ID: <20130402171217.GE25867@quad.lixom.net>

On Sat, Mar 23, 2013 at 09:22:20AM +0400, Alexander Shiyan wrote:
> > The 'CONFIG_' prefix is not implicit in IS_ENABLED().
> > 
> > Signed-off-by: Ben Hutchings <ben at decadent.org.uk>
> > Cc: Alexander Shiyan <shc_work at mail.ru>
> > Cc: Olof Johansson <olof at lixom.net>
> > Cc: Paul Bolle <pebolle at tiscali.nl>
> > Cc: <stable at vger.kernel.org> # 3.8+
> > ---
> > Found by inspection.  This is not even compile-tested.
> > 
> > Ben.
> > 
> >  arch/arm/mach-clps711x/board-autcpu12.c |    3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/arch/arm/mach-clps711x/board-autcpu12.c b/arch/arm/mach-clps711x/board-autcpu12.c
> > index f385847..8138523 100644
> > --- a/arch/arm/mach-clps711x/board-autcpu12.c
> > +++ b/arch/arm/mach-clps711x/board-autcpu12.c
> > @@ -158,7 +158,8 @@ static void __init autcpu12_init(void)
> >  
> >  static void __init autcpu12_init_late(void)
> >  {
> > -	if (IS_ENABLED(MTD_NAND_GPIO) && IS_ENABLED(GPIO_GENERIC_PLATFORM)) {
> > +	if (IS_ENABLED(CONFIG_MTD_NAND_GPIO) &&
> > +	    IS_ENABLED(CONFIG_GPIO_GENERIC_PLATFORM)) {
> >  		/* We are need both drivers to handle NAND */
> >  		platform_device_register(&autcpu12_nand_pdev);
> >  	}
> 
> Oops. Right.
> And I think checks can be removed completely.

Seems reasonable -- there's no reason to hold off registering the device just
because the driver isn't enabled.

Who'll repost a patch to just remove the tests? Ben? Alexander?


-Olof


From olof at lixom.net  Tue Apr  2 13:20:36 2013
From: olof at lixom.net (Olof Johansson)
Date: Tue, 2 Apr 2013 10:20:36 -0700
Subject: [PATCH] arm: vt8500: Add wm8850 config options to
 multi_v7_defconfig
In-Reply-To: <1364199100-12300-1-git-send-email-linux@prisktech.co.nz>
References: <1364199100-12300-1-git-send-email-linux@prisktech.co.nz>
Message-ID: <20130402172036.GG25867@quad.lixom.net>

On Mon, Mar 25, 2013 at 09:11:40PM +1300, Tony Prisk wrote:
> This patch finally adds the WM8850 SoC to the multi_v7_defconfig.
> We don't have a seperate defconfig for this SoC as it is only
> available as a multiplatform option.
> 
> Signed-off-by: Tony Prisk <linux at prisktech.co.nz>


Applied to next/multiplatform after fixing up some conflicts due to the SPEAR
additions.


-Olof


From tony at atomide.com  Tue Apr  2 13:21:30 2013
From: tony at atomide.com (Tony Lindgren)
Date: Tue, 2 Apr 2013 10:21:30 -0700
Subject: [PATCH v4 01/21] usb: phy: nop: Add some parameters to
 platform data
In-Reply-To: <20130320161947.GJ1567@arwen.pp.htv.fi>
References: <1363794300-31526-1-git-send-email-rogerq@ti.com>
 <1363794300-31526-2-git-send-email-rogerq@ti.com>
 <20130320155555.GG1567@arwen.pp.htv.fi>
 <20130320161324.GL16413@atomide.com>
 <20130320161947.GJ1567@arwen.pp.htv.fi>
Message-ID: <20130402172129.GT10155@atomide.com>

* Felipe Balbi <balbi at ti.com> [130320 09:24]:
> On Wed, Mar 20, 2013 at 09:13:24AM -0700, Tony Lindgren wrote:
> > * Felipe Balbi <balbi at ti.com> [130320 09:00]:
> > > On Wed, Mar 20, 2013 at 05:44:40PM +0200, Roger Quadros wrote:
> > > > Add clk_rate parameter to platform data. If supplied, the
> > > > NOP phy driver will program the clock to that rate during probe.
> > > > 
> > > > Also add 2 flags, needs_vcc and needs_reset.
> > > > If the flag is set and the regulator couldn't be found
> > > > then the driver will bail out with -EPROBE_DEFER.
> > > > 
> > > > Signed-off-by: Roger Quadros <rogerq at ti.com>
> > > > Acked-by: Felipe Balbi <balbi at ti.com>
> > > 
> > > Hi Tony,
> > > 
> > > maybe you might prefer to merge commit 1f0972f from my next branch which
> > > is exactly this patch. Basically, if you:
> > > 
> > > $ git fetch git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git next
> > > $ git merge 1f0972f
> > > 
> > > you get $SUBJECT and can apply the others without fear of conflicts
> > > later.
> > 
> > OK thanks will use commit 1f0972f, so let's consider that commit immutable.
> 
> yeah, once it hits my 'next' branch, I don't rebase anymore.

I've applied the board related patchs into omap-for-v3.10/usb that's based
on commit 1f0972f.

Regards,

Tony


From jason at lakedaemon.net  Tue Apr  2 13:24:54 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Tue, 2 Apr 2013 13:24:54 -0400
Subject: [PATCH] ARM: kirkwood: DT board setup for CloudBox
In-Reply-To: <20130402125408.GH16404@kw.sim.vm.gnt>
References: <1364555206-5870-1-git-send-email-simon.guinot@sequanux.org>
 <20130329153132.GJ13280@titan.lakedaemon.net>
 <20130329184109.GA16404@kw.sim.vm.gnt> <51568B89.1060009@free.fr>
 <20130401163316.GC16404@kw.sim.vm.gnt> <515A5BC6.5000007@free.fr>
 <20130402114535.GR13280@titan.lakedaemon.net>
 <20130402125408.GH16404@kw.sim.vm.gnt>
Message-ID: <20130402172454.GT13280@titan.lakedaemon.net>

On Tue, Apr 02, 2013 at 02:54:11PM +0200, Simon Guinot wrote:
> On Tue, Apr 02, 2013 at 07:45:35AM -0400, Jason Cooper wrote:
> > On Tue, Apr 02, 2013 at 06:17:10AM +0200, Chris Moore wrote:
> > > Le 01/04/2013 18:33, Simon Guinot a ?crit :
> > ...
> > > >The new CloudBox is a very different product which has been first named
> > > >FamilyBox and then released under the CloudBox name.
> > 
> > The question really comes down to, are there *any* differences on the
> > _board_?
> > 
> > If there are hardware differences, we need two dts files and two
> > compatibility strings.  Preferably appending the baseline model number
> > to each.  If they unwisely chose the same model number, we should append
> > '-db' or '-dev-board' to the compatibility string of the first board.
> > 
> > Although, in this case, there is a netspace_mini_v2 already in the
> > kernel (kirkwood-ns2mini.dts).  Is this the development version you were
> > speaking of?
> 
> I think that I am not clear in my explanations :)

Nope, I'm just a little dense this week. ;-)

> There is two different LaCie boards. There is no relations between this
> boards except their final product name (which is quite silly).
> 
> From a LaCie point, there is no board but only product naming. Here are
> the different names used by LaCie for this two boards/products:
> 
> 1: netspace_mini_v2 -> SafeBox -> CloudBox
> 2: FamilyBox -> CloudBox
> 
> "1" is the oldest board.

Got it.

> Under Linux, with my patch we are using the following names:
> 
> 1: netspace_mini_v2
> 2: cloudbox
> 
> The problem raised by Chris is that the cloudbox name could be
> confusing because one could try a "cloudbox" dtb on the board "1". For
> my part I don't think it is an issue because "1" is rather confidential
> (and it is an euphemism). 

Agreed.

> It would be more confusing for users if the kernel name for "2" is not
> cloudbox but cloudbox_{color,number,...} or even familybox. Moreover
> netspace_mini_v2 is a correct name for "1".
> 
> IMHO, we could let things as they are. Additionally, I could either
> extend the Kconfig description and add a some comments in the dts files,
> in order to to prevent any misunderstanding...
> 
> Let me know if you agree or not.

Yes, that makes more sense.  Thanks for clearing it up.  Please add the
clarifying remarks to the dts.

As for the model number for the public board (#2), why can't we append
"-90003xx"?  See [1], Specifications tab.

thx,

Jason.

[1] http://www.lacie.com/us/products/product.htm?id=10597


From tony at atomide.com  Tue Apr  2 13:29:10 2013
From: tony at atomide.com (Tony Lindgren)
Date: Tue, 2 Apr 2013 10:29:10 -0700
Subject: [GIT PULL 1/3] omap non critical fixes for v3.10 merge window
Message-ID: <pull-1364923751-842943>

The following changes since commit 07961ac7c0ee8b546658717034fe692fd12eefa9:

  Linux 3.9-rc5 (2013-03-31 15:12:43 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.10/fixes-non-critical-signed

for you to fetch changes up to 105612489bf59386b46b3f9f034e03f70e57aee6:

  Merge branch 'for_3.10/omap5_generic_updates' of git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux into omap-for-v3.10/fixes-non-critical (2013-04-01 09:30:47 -0700)

----------------------------------------------------------------

Non critical omap fixes for v3.10 merge window. A big chunk
of these fixes are needed to support omap5 es2 version that includes
PM features while the earlier version es1 did not.

----------------------------------------------------------------
Paul Bolle (3):
      ARM: OMAP: fix typo "CONFIG_SMC91x_MODULE"
      ARM: OMAP1: remove "config MACH_OMAP_HTCWIZARD"
      ARM: OMAP2+: fix typo "CONFIG_BRIDGE_DVFS"

Paul Walmsley (1):
      ARM: OMAP2+: powerdomain: avoid testing whether an unsigned char is less than 0

Rajendra Nayak (3):
      ARM: OMAP5: clock: No Freqsel on OMAP5 devices too
      ARM: OMAP2+: hwmod: Remove unused _HWMOD_WAKEUP_ENABLED flag
      ARM: OMAP: dpll: enable bypass clock only when attempting dpll bypass

Santosh Shilimkar (6):
      ARM: OMAP5: Update SOC id detection code for ES2
      ARM: OMAP5: timer: Update the clocksource name as per clock data
      ARM: OMAP5: prm: Allow prm init to succeed
      ARM: OMAP5: Update SAR RAM base address
      ARM: OMAP5: Update SAR memory layout for WakeupGen
      ARM: OMAP5: Make errata i688 workaround available

Tero Kristo (1):
      ARM: OMAP5: Reuse prm read_inst/write_inst

Tony Lindgren (2):
      Merge tag 'omap-devel-b-for-3.10' of git://git.kernel.org/.../pjw/omap-pending into omap-for-v3.10/fixes-non-critical
      Merge branch 'for_3.10/omap5_generic_updates' of git://git.kernel.org/.../ssantosh/linux into omap-for-v3.10/fixes-non-critical

Vaibhav Hiremath (2):
      ARM: OMAP2+: AM33xx: hwmod: Add missing sysc definition to wdt1 entry
      ARM: OMAP2+: am335x: Change the wdt1 func clk src to per_32k clk

 arch/arm/mach-omap1/Kconfig                |  6 ------
 arch/arm/mach-omap2/Kconfig                |  2 +-
 arch/arm/mach-omap2/board-2430sdp.c        |  2 +-
 arch/arm/mach-omap2/board-h4.c             |  2 +-
 arch/arm/mach-omap2/cclock33xx_data.c      |  8 ++++++++
 arch/arm/mach-omap2/dpll3xxx.c             | 30 ++++++++++++++----------------
 arch/arm/mach-omap2/dsp.c                  |  4 ++--
 arch/arm/mach-omap2/id.c                   | 12 +++++++++---
 arch/arm/mach-omap2/io.c                   |  9 +++++++++
 arch/arm/mach-omap2/omap4-common.c         | 10 ++++++++--
 arch/arm/mach-omap2/omap4-sar-layout.h     | 14 +++++++-------
 arch/arm/mach-omap2/omap54xx.h             |  1 +
 arch/arm/mach-omap2/omap_hwmod.c           |  4 ----
 arch/arm/mach-omap2/omap_hwmod.h           |  6 ++----
 arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 15 +++++++++++++++
 arch/arm/mach-omap2/powerdomain.c          | 18 ++++++++----------
 arch/arm/mach-omap2/prm44xx.c              |  6 +++---
 arch/arm/mach-omap2/soc.h                  |  2 ++
 arch/arm/mach-omap2/timer.c                |  5 +++--
 19 files changed, 94 insertions(+), 62 deletions(-)


From tony at atomide.com  Tue Apr  2 13:29:10 2013
From: tony at atomide.com (Tony Lindgren)
Date: Tue, 2 Apr 2013 10:29:10 -0700
Subject: [GIT PULL 2/3] omap cleanup for v3.10 merge window
In-Reply-To: <pull-1364923751-842943>
Message-ID: <mailman.4.1364923761.1198.linux-arm-kernel@lists.infradead.org>

The following changes since commit a937536b868b8369b98967929045f1df54234323:

  Linux 3.9-rc3 (2013-03-17 15:59:32 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.10/cleanup-v2-signed

for you to fetch changes up to c309f7f46167e85d1aae2fd31f23e7d2b5cdfbe0:

  Merge branch 'for_3.10/omap_generic_cleanup_v2' of git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux into omap-for-v3.10/cleanup-v2 (2013-03-28 14:45:31 -0700)

----------------------------------------------------------------

Clean up related changes for v3.10 merge window.
Mostly clock and PM related with removal of now unused
DMA channel definitions. The clock change to use SoC
specific lists will make it a little bit easier to
add support for new SoCs variants without having to patch
all over the place.

----------------------------------------------------------------
J Keerthy (1):
      ARM: OMAP2+: clock data: Remove CK_* flags

Jarkko Nikula (2):
      ARM: OMAP1: Remove unused DMA channel definitions
      ARM: OMAP2+: Remove unused DMA channel definitions

Santosh Shilimkar (8):
      ARM: OMAP2+: PM: Remove bogus fiq_[enable/disable] tuple
      ARM: OMAP4+: Remove the un-necessary cache flush from hotplug code
      ARM: OMAP4+: Remove un-necessary cacheflush in secondary CPU boot path
      ARM: OMAP4+: Remove out of placed smp_wmb() in secondary wakeup code
      ARM: OMAP4+: Move the CPU wakeup prepare code under smp_prepare_cpus()
      ARM: OMAP4: PM: Remove L4 wakeup depedency with MPU since errata fix exist now
      ARM: OMAP4: PM: Now remove L4 per clockdomain static depedency with MPU
      ARM: OMAP4: Fix the init code to have OMAP4460 errata available in DT build

Tero Kristo (1):
      ARM: OMAP4+: Use common scratchpad SAR RAM offsets for all architectures

Tony Lindgren (2):
      Merge tag 'omap-cleanup-a-for-3.10' of git://git.kernel.org/.../pjw/omap-pending into omap-for-v3.10/cleanup
      Merge branch 'for_3.10/omap_generic_cleanup_v2' of git://git.kernel.org/.../ssantosh/linux into omap-for-v3.10/cleanup-v2

 arch/arm/mach-omap1/dma.h              |  41 --
 arch/arm/mach-omap2/cclock2420_data.c  | 283 +++++++-------
 arch/arm/mach-omap2/cclock2430_data.c  | 311 ++++++++-------
 arch/arm/mach-omap2/cclock33xx_data.c  | 165 ++++----
 arch/arm/mach-omap2/cclock3xxx_data.c  | 685 ++++++++++++++++++---------------
 arch/arm/mach-omap2/cclock44xx_data.c  | 515 ++++++++++++-------------
 arch/arm/mach-omap2/clock.c            |  17 +-
 arch/arm/mach-omap2/clock.h            |  20 +-
 arch/arm/mach-omap2/cpuidle34xx.c      |   3 -
 arch/arm/mach-omap2/cpuidle44xx.c      |   7 -
 arch/arm/mach-omap2/dma.h              |  70 ----
 arch/arm/mach-omap2/omap-hotplug.c     |   6 -
 arch/arm/mach-omap2/omap-smp.c         |  57 +--
 arch/arm/mach-omap2/omap4-common.c     |  16 +
 arch/arm/mach-omap2/omap4-sar-layout.h |  14 +-
 arch/arm/mach-omap2/pm24xx.c           |  11 +-
 arch/arm/mach-omap2/pm34xx.c           |   9 +-
 arch/arm/mach-omap2/pm44xx.c           |  20 +-
 18 files changed, 1059 insertions(+), 1191 deletions(-)


From tony at atomide.com  Tue Apr  2 13:29:11 2013
From: tony at atomide.com (Tony Lindgren)
Date: Tue, 2 Apr 2013 10:29:11 -0700
Subject: [GIT PULL 3/3] omap hw crypto updates for v3.10 merge window
In-Reply-To: <pull-1364923751-842943>
Message-ID: <mailman.5.1364923763.1198.linux-arm-kernel@lists.infradead.org>

The following changes since commit 78e52e026d288aad88b46bff0d94b05e145c4583:

  ARM: OMAP2+: clock data: Remove CK_* flags (2013-03-18 09:57:39 -0600)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.10/crypto-signed

for you to fetch changes up to f13acab6594451da8b5bd39db0c0513aba592a8d:

  Merge tag 'omap-devel-a-for-3.10' of git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending into omap-for-v3.10/crypto (2013-04-01 10:07:28 -0700)

----------------------------------------------------------------

Omap crypto related bus level changes via Paul Walmsley <paul at pwsan.com>:

For OMAP2+ SoCs, convert the SHA/MD5 and AES accelerator integration
code and data to use hwmod and omap_device. This is a prerequisite for
moving the hwmod code out of arch/arm.

Basic test logs are available at:

http://www.pwsan.com/omap/testlogs/sham_aes_integration_devel_3.10/20130330155313/

----------------------------------------------------------------
Mark A. Greer (13):
      ARM: OMAP2xxx: hwmod: Convert SHAM crypto device data to hwmod
      ARM: OMAP2xxx: hwmod: Add DMA support for SHAM module
      ARM: OMAP3xxx: hwmod: Convert SHAM crypto device data to hwmod
      ARM: OMAP2+: Remove unnecessary message when no SHA IP is present
      ARM: OMAP2+: Only manually add hwmod data when DT not used.
      ARM: AM33XX: Add sha0 crypto clock data
      ARM: AM33XX: hwmod: Update and uncomment SHA0 module data
      ARM: OMAP2xxx: hwmod: Convert AES crypto devcie data to hwmod
      ARM: OMAP3xxx: hwmod: Convert AES crypto device data to hwmod
      ARM: OMAP2+: Remove unnecessary message when no AES IP is present
      ARM: OMAP2+: Only manually add hwmod data when DT not used.
      ARM: AM33XX: Add aes0 crypto clock data
      ARM: AM33XX: hwmod: Update and uncomment AES0 module data

Tony Lindgren (1):
      Merge tag 'omap-devel-a-for-3.10' of git://git.kernel.org/.../pjw/omap-pending into omap-for-v3.10/crypto

 arch/arm/mach-omap2/cclock2430_data.c              |   4 +-
 arch/arm/mach-omap2/cclock33xx_data.c              |  10 ++
 arch/arm/mach-omap2/cclock3xxx_data.c              |   2 +
 arch/arm/mach-omap2/devices.c                      | 149 +++---------------
 arch/arm/mach-omap2/omap_hwmod_2420_data.c         |   2 +
 arch/arm/mach-omap2/omap_hwmod_2430_data.c         |   2 +
 .../mach-omap2/omap_hwmod_2xxx_interconnect_data.c |  36 +++++
 arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c |  81 ++++++++++
 arch/arm/mach-omap2/omap_hwmod_33xx_data.c         |  92 +++++++++--
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c         | 172 +++++++++++++++++++--
 arch/arm/mach-omap2/omap_hwmod_common_data.h       |   4 +
 11 files changed, 401 insertions(+), 153 deletions(-)


From nicolas.pitre at linaro.org  Tue Apr  2 13:34:22 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Tue, 2 Apr 2013 13:34:22 -0400 (EDT)
Subject: [PATCH v5 3/3] xen/arm: introduce xen_early_init, use PSCI on xen
In-Reply-To: <1364919374-7836-3-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1304021700380.5078@kaball.uk.xensource.com>
 <1364919374-7836-3-git-send-email-stefano.stabellini@eu.citrix.com>
Message-ID: <alpine.LFD.2.03.1304021325230.1171@syhkavp.arg>

On Tue, 2 Apr 2013, Stefano Stabellini wrote:

> Split xen_guest_init in two functions, one of them (xen_early_init) is
> going to be called very early from setup_arch.
> 
> Change machine_desc->smp_init to xen_smp_init if Xen is present on the
> platform. xen_smp_init just sets smp_ops to psci_smp_ops.
> 
> Introduce a dependency for ARM_PSCI in XEN.

The Kconfig stuff should be more understandable to "normal" users 
configuring the kernel.  Hence it might make more sense for Xen to 
select PSCI rather than making it a prerequisite.

[...]
> @@ -176,27 +178,30 @@ static int __init xen_secondary_init(unsigned int cpu)
>  	return 0;
>  }
>  
> +static void __init xen_smp_init(void)
> +{
> +	if (psci_smp_available())
> +		smp_set_ops(&psci_smp_ops);
> +}
> +

I still don't understand why you need to do this.  Why can't you just 
rely on the next priority which is to set PSCI ops by default if 
available?  Using this hook for Xen doesn't look justified. As it is, 
you break MCPM.

As I explained to you, MCPM will end up using PSCI as well when 
available, which I think should be sufficient for your concern.


Nicolas


From stigge at antcom.de  Tue Apr  2 13:37:11 2013
From: stigge at antcom.de (Roland Stigge)
Date: Tue,  2 Apr 2013 19:37:11 +0200
Subject: [PATCH] MAINTAINERS: Add maintainer for LPC32xx
Message-ID: <1364924231-18591-1-git-send-email-stigge@antcom.de>

This patch adds Roland Stigge as maintainer for NXP LPC32xx.

Signed-off-by: Roland Stigge <stigge at antcom.de>

---
 MAINTAINERS |    6 ++++++
 1 file changed, 6 insertions(+)

--- linux-2.6.orig/MAINTAINERS
+++ linux-2.6/MAINTAINERS
@@ -4941,6 +4941,12 @@ W:	logfs.org
 S:	Maintained
 F:	fs/logfs/
 
+LPC32XX MACHINE SUPPORT
+M:	Roland Stigge <stigge at antcom.de>
+L:	linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
+S:	Maintained
+F:	arch/arm/mach-lpc32xx/
+
 LSILOGIC MPT FUSION DRIVERS (FC/SAS/SPI)
 M:	Nagalakshmi Nandigama <Nagalakshmi.Nandigama at lsi.com>
 M:	Sreekanth Reddy <Sreekanth.Reddy at lsi.com>


From nicolas.pitre at linaro.org  Tue Apr  2 13:41:17 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Tue, 2 Apr 2013 13:41:17 -0400 (EDT)
Subject: [PATCH v5 1/3] arm: introduce psci_smp_ops
In-Reply-To: <1364919374-7836-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1304021700380.5078@kaball.uk.xensource.com>
 <1364919374-7836-1-git-send-email-stefano.stabellini@eu.citrix.com>
Message-ID: <alpine.LFD.2.03.1304021336270.1171@syhkavp.arg>

On Tue, 2 Apr 2013, Stefano Stabellini wrote:

> Rename virt_smp_ops to psci_smp_ops and move them to arch/arm/kernel/psci_smp.c.
> Remove mach-virt/platsmp.c, now unused.
> Compile psci_smp if CONFIG_ARM_PSCI and CONFIG_SMP.
> 
> Add a cpu_die smp_op based on psci_ops.cpu_off.
> 
> Initialize PSCI before setting smp_ops in setup_arch.
> Use psci_smp_ops if the platform doesn't provide its own smp_ops.

[...]

> @@ -766,9 +767,13 @@ void __init setup_arch(char **cmdline_p)
>  	unflatten_device_tree();
>  
>  	arm_dt_init_cpu_maps();
> +	psci_init();
>  #ifdef CONFIG_SMP
>  	if (is_smp()) {
> -		smp_set_ops(mdesc->smp);
> +		if (mdesc->smp)
> +			smp_set_ops(mdesc->smp);
> +		else if (psci_smp_available())
> +			smp_set_ops(&psci_smp_ops);

Didn't we agree to do this the other way around, i.e. 

	if (psci_smp_available())
		smp_set_ops(&psci_smp_ops);
	else if (mdesc->smp)
		smp_set_ops(mdesc->smp);

?

This way you won't need the ->smp_init for Xen and that won't conflict 
with MCPM.


Nicolas


From stigge at antcom.de  Tue Apr  2 13:43:35 2013
From: stigge at antcom.de (Roland Stigge)
Date: Tue, 02 Apr 2013 19:43:35 +0200
Subject: [PATCH] ARM: LPC32xx: changed lpc23xx_restart to lpc32xx_restart
In-Reply-To: <20130402155817.GA25867@quad.lixom.net>
References: <1362601138-16550-1-git-send-email-martinknoll@me.com>
 <20130402155817.GA25867@quad.lixom.net>
Message-ID: <515B18C7.7010803@antcom.de>

On 02/04/13 17:58, Olof Johansson wrote:
> On Wed, Mar 06, 2013 at 09:18:58PM +0100, Martin Knoll wrote:
>> This function has an odd name. This is probably a typo.
> 
> You should cc the platform maintainer on these kind of patches (Roland Stigge).
> But it seems that he's not actually listed in MAINTAINERS.

I indeed missed the above patch - should be a simple syntactic fix in 3
places in arch/arm/. You can go ahead this time and directly take this
fix. Otherwise, please forward to me so I can add it to a lpc32xx tree
and do request pull.

> Roland, can you send a patch adding yourself as LPC32XX maintainer so these
> kind of patches don't get dropped? Thanks!

OK, just did.

Thanks for notifying!

Roland


From olof at lixom.net  Tue Apr  2 13:48:01 2013
From: olof at lixom.net (Olof Johansson)
Date: Tue, 2 Apr 2013 10:48:01 -0700
Subject: [GIT PULL v2] at91: soc for 3.10 #2
In-Reply-To: <1364467109-11173-1-git-send-email-nicolas.ferre@atmel.com>
References: <5152B357.3020500@atmel.com>
 <1364467109-11173-1-git-send-email-nicolas.ferre@atmel.com>
Message-ID: <20130402174801.GI25867@quad.lixom.net>

On Thu, Mar 28, 2013 at 11:38:29AM +0100, Nicolas Ferre wrote:
> Arnd, Olof,
> 
> A pull-request for 3.10 that is dedicated to the introduction of
> Atmel's new Cortex-A5 based product: SAMA5D3.
> This tag is built on top of the material already provided that resides on your
> side in at91/cleanup branch.
> The second revision of this pull-request includes a patch from Arnd to modify
> The AT91 Kconfig.
> 
> Thanks, best regards,
> 
> The following changes since commit 9317960fa38ff50ac287904e4c751a169635ecbf:
> 
>   ARM: at91: renamme rm9200 dt file (2013-03-13 17:28:14 +0100)
> 
> are available in the git repository at:
> 
>   git://github.com/at91linux/linux-at91.git tags/at91-soc
> 
> for you to fetch changes up to abac0fd0f6dad6fa01ac8fdfccc796233d0fea30:
> 
>   ARM: at91: make ATAGS support conditional on CONFIG_ATAGS (2013-03-28 09:51:39 +0100)
> 
> ----------------------------------------------------------------
> Introduction of new Atmel Cortex-A5: SAMA5D3 family.
> - Modify AT91 Kconfig to plit ARMv4/5 and ARMv7 arch
> - Modify PMC driver (clocks)
> - Core SAMA5 support
> - Board file, DT files and defconfig
> Add a condition on CONFIG_ATAGS for legacy boards

Pulled, thanks!


-Olof


From taras at ti.com  Tue Apr  2 13:49:25 2013
From: taras at ti.com (Taras Kondratiuk)
Date: Tue, 2 Apr 2013 20:49:25 +0300
Subject: [PATCH 2/5] clk: notifier handler for dynamic voltage scaling
In-Reply-To: <1362026969-11457-3-git-send-email-mturquette@linaro.org>
Message-ID: <515B1A25.3040800@ti.com>

Hi Mike

> +/*
> + * Copyright (C) 2011-2012 Linaro Ltd <mturquette at linaro.org>
> + *
> + * 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.
> + *
> + * Helper functions for dynamic voltage & frequency transitions using
> + * the OPP library.
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/regulator/consumer.h>
> +#include <linux/opp.h>
> +#include <linux/device.h>
> +#include <linux/slab.h>
> +#include <linux/module.h>
> +
> +/*
> + * XXX clk, regulator & tolerance should be stored in the OPP table?
> + */
> +struct dvfs_info {
> +    struct device *dev;
> +    struct clk *clk;
> +    struct regulator *reg;
> +    int tol;
> +    struct notifier_block nb;
> +};
> +
> +#define to_dvfs_info(_nb) container_of(_nb, struct dvfs_info, nb)
> +
> +static int dvfs_clk_notifier_handler(struct notifier_block *nb,
> +        unsigned long flags, void *data)
> +{
> +    struct clk_notifier_data *cnd = data;
> +    struct dvfs_info *di = to_dvfs_info(nb);
> +    int ret, volt_new, volt_old;
> +    struct opp *opp;
> +
> +    volt_old = regulator_get_voltage(di->reg);
> +    rcu_read_lock();
> +    opp = opp_find_freq_floor(di->dev, &cnd->new_rate);
I think here should be opp_find_freq_ceil().
Let's imagine we have a following OPP table for some device:
1 - <100MHz - 1.0V>
2 - <200MHz - 1.2V>
3 - <400MHz - 1.4V>

If device driver scales clock to 150MHz, then OPP #1 will be chosen.
This will lead to configuration <150MHz - 1.0V> that may be unstable.
It would be better to ceil and end-up with <150MHz - 1.2V>.

> +    volt_new = opp_get_voltage(opp);
> +    rcu_read_unlock();
> +
> +    /* scaling up?  scale voltage before frequency */
> +    if (flags & PRE_RATE_CHANGE && cnd->new_rate > cnd->old_rate) {
opp_find_freq_*() functions can update cnd->new_rate,
so you may compare not exactly what you are expecting.

> +        dev_dbg(di->dev, "%s: %d mV --> %d mV\n",
> +                __func__, volt_old, volt_new);
> +
> +        ret = regulator_set_voltage_tol(di->reg, volt_new, di->tol);
I may not have a deep understanding of regulator framework,
but looks like regulator_set_voltage_tol() is not the right API here.
As per my understanding regulator framework should aggregate
voltage request from different consumers of the particular regulator.

Let's say there are two consumers of VDD regulator.
First device set 1.0V. It will map to range 0.98-1.02V (2% tolerance).
If second device will try to set 1.3V it will fail because range 1.28-1.32V
does not overlap with the first request.

Maybe better to set upper limit to max OPP voltage or just use INT_MAX.

> +
> +        if (ret) {
> +            dev_warn(di->dev, "%s: unable to scale voltage up.\n",
> +                 __func__);
> +            return notifier_from_errno(ret);
> +        }
> +    }
> +
> +    /* scaling down?  scale voltage after frequency */
> +    if (flags & POST_RATE_CHANGE && cnd->new_rate < cnd->old_rate) {
> +        dev_dbg(di->dev, "%s: %d mV --> %d mV\n",
> +                __func__, volt_old, volt_new);
> +
> +        ret = regulator_set_voltage_tol(di->reg, volt_new, di->tol);
> +
> +        if (ret) {
> +            dev_warn(di->dev, "%s: unable to scale voltage down.\n",
> +                 __func__);
> +            return notifier_from_errno(ret);
> +        }
> +    }
> +
> +    return NOTIFY_OK;
> +}
> +
> +struct dvfs_info *dvfs_clk_notifier_register(struct dvfs_info_init *dii)
> +{
> +    struct dvfs_info *di;
> +    int ret = 0;
> +
> +    if (!dii)
> +        return ERR_PTR(-EINVAL);
> +
> +    di = kzalloc(sizeof(struct dvfs_info), GFP_KERNEL);
> +    if (!di)
> +        return ERR_PTR(-ENOMEM);
> +
> +    di->dev = dii->dev;
> +    di->clk = clk_get(di->dev, dii->con_id);
> +    if (IS_ERR(di->clk)) {
> +        ret = -ENOMEM;
> +        goto err;
> +    }
> +
> +    di->reg = regulator_get(di->dev, dii->reg_id);
> +    if (IS_ERR(di->reg)) {
> +        ret = -ENOMEM;
> +        goto err;
> +    }
> +
> +    di->tol = dii->tol;
> +    di->nb.notifier_call = dvfs_clk_notifier_handler;
> +
> +    ret = clk_notifier_register(di->clk, &di->nb);
> +
> +    if (ret)
> +        goto err;
> +
> +    return di;
> +
> +err:
> +    kfree(di);
> +    return ERR_PTR(ret);
> +}
> +EXPORT_SYMBOL_GPL(dvfs_clk_notifier_register);
> +
> +void dvfs_clk_notifier_unregister(struct dvfs_info *di)
> +{
> +    clk_notifier_unregister(di->clk, &di->nb);
> +    clk_put(di->clk);
> +    regulator_put(di->reg);
> +    kfree(di);
> +}
> +EXPORT_SYMBOL_GPL(dvfs_clk_notifier_unregister);
> diff --git a/include/linux/clk.h b/include/linux/clk.h
> index b3ac22d..28d952f 100644
> --- a/include/linux/clk.h
> +++ b/include/linux/clk.h
> @@ -78,9 +78,34 @@  struct clk_notifier_data {
>      unsigned long        new_rate;
>  };
>
> -int clk_notifier_register(struct clk *clk, struct notifier_block *nb);
> +/**
> + * struct dvfs_info_init - data needs to initialize struct dvfs_info
> + * @dev:    device related to this frequency-voltage pair
> + * @con_id:    string name of clock connection
> + * @reg_id:    string name of regulator
> + * @tol:    voltage tolerance for this device
> + *
> + * Provides the data needed to register a common dvfs sequence in a clk
> + * notifier handler.  The clk and regulator lookups are stored in a
> + * private struct and the notifier handler is registered with the clk
> + * framework with a call to dvfs_clk_notifier_register.
> + *
> + * FIXME stuffing @tol here is a hack.  It belongs in the opp table.
> + * Maybe clk & regulator will also live in the opp table some day.
> + */
> +struct dvfs_info_init {
> +    struct device *dev;
> +    const char *con_id;
> +    const char *reg_id;
> +    int tol;
> +};
> +
> +struct dvfs_info;
>
> +int clk_notifier_register(struct clk *clk, struct notifier_block *nb);
>  int clk_notifier_unregister(struct clk *clk, struct notifier_block *nb);
> +struct dvfs_info *dvfs_clk_notifier_register(struct dvfs_info_init *dii);
> +void dvfs_clk_notifier_unregister(struct dvfs_info *di);
>
>  #endif

-- 
BR
Taras Kondratiuk | GlobalLogic



From olof at lixom.net  Tue Apr  2 14:03:39 2013
From: olof at lixom.net (Olof Johansson)
Date: Tue, 2 Apr 2013 11:03:39 -0700
Subject: [GIT PULL] Preparatory GIC patches for arm64 support
In-Reply-To: <20130328140239.GF24039@arm.com>
References: <20130328140239.GF24039@arm.com>
Message-ID: <20130402180339.GJ25867@quad.lixom.net>

On Thu, Mar 28, 2013 at 02:02:39PM +0000, Catalin Marinas wrote:
> Hi,
> 
> As I'm about to go on holiday for two weeks and I haven't heard any
> preference for who should be merging these patches, I'm sending the pull
> request to arm-soc given that 90% of the changes target SoC code. Apart
> from the gic_secondary_init() patch, the rest is trivial header code
> moving around or removal.
> 
> Russell, if you have any objections, please let arm-soc guys and me know
> and feel free to pull these patches via your tree. I don't mind either
> way.
> 
> Thanks,
> 
> Catalin
> 
> 
> The following changes since commit a937536b868b8369b98967929045f1df54234323:
> 
>   Linux 3.9-rc3 (2013-03-17 15:59:32 -0700)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch64.git gic


Pulled as gic/cleanup into next/cleanup.

I got a handful of context conflicts due to additions near the old
secondary_init functions, and one add/add conflict on includes. All trivial to
resolve.


-Olof


From vinod.koul at intel.com  Tue Apr  2 13:42:16 2013
From: vinod.koul at intel.com (Vinod Koul)
Date: Tue, 2 Apr 2013 23:12:16 +0530
Subject: [PATCH V3] DMA: PL330: Add check if device tree compatible
In-Reply-To: <1364901405-16541-1-git-send-email-padma.v@samsung.com>
References: <1364901405-16541-1-git-send-email-padma.v@samsung.com>
Message-ID: <20130402174216.GM10326@intel.com>

On Tue, Apr 02, 2013 at 04:46:45PM +0530, Padmavathi Venna wrote:
> This patch register the dma controller with generic dma helpers only
> in DT case. This also adds some extra error handling in the driver.
> 
> Signed-off-by: Padmavathi Venna <padma.v at samsung.com>
> Reported-by: Sachin Kamat <sachin.kamat at linaro.org>
> ---
> 
> Based on Vinod Koul next branch.
> 
> Changes since V2:
> 	- Removed pl330_free_chan_resources for error handling in probe. 
> 
> Changes since V1:
> 	- return silently when of_dma_controller_register fails, as
> 	  suggested by Arnd.
> 
>  drivers/dma/pl330.c |   33 ++++++++++++++++++++++-----------
>  1 files changed, 22 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
> index 345e2a1..fa388c1c 100644
> --- a/drivers/dma/pl330.c
> +++ b/drivers/dma/pl330.c
> @@ -2882,7 +2882,7 @@ pl330_probe(struct amba_device *adev, const struct amba_id *id)
>  {
>  	struct dma_pl330_platdata *pdat;
>  	struct dma_pl330_dmac *pdmac;
> -	struct dma_pl330_chan *pch;
> +	struct dma_pl330_chan *pch, *_p;
>  	struct pl330_info *pi;
>  	struct dma_device *pd;
>  	struct resource *res;
> @@ -2984,7 +2984,17 @@ pl330_probe(struct amba_device *adev, const struct amba_id *id)
>  	ret = dma_async_device_register(pd);
>  	if (ret) {
>  		dev_err(&adev->dev, "unable to register DMAC\n");
> -		goto probe_err2;
> +		goto probe_err3;
> +	}
> +
> +	if (adev->dev.of_node) {
> +		ret = of_dma_controller_register(adev->dev.of_node,
> +					 of_dma_pl330_xlate, pdmac);
> +		if (ret) {
> +			dev_err(&adev->dev,
> +				"unable to register DMA to the generic"
> +				"DT DMA helpers\n");
This could have been in a single line

I have applied it to fixes.

--
~Vinod
> +		}
>  	}
>  
>  	dev_info(&adev->dev,
> @@ -2995,16 +3005,15 @@ pl330_probe(struct amba_device *adev, const struct amba_id *id)
>  		pi->pcfg.data_bus_width / 8, pi->pcfg.num_chan,
>  		pi->pcfg.num_peri, pi->pcfg.num_events);
>  
> -	ret = of_dma_controller_register(adev->dev.of_node,
> -					 of_dma_pl330_xlate, pdmac);
> -	if (ret) {
> -		dev_err(&adev->dev,
> -		"unable to register DMA to the generic DT DMA helpers\n");
> -		goto probe_err2;
> -	}
> -
>  	return 0;
> +probe_err3:
> +	amba_set_drvdata(adev, NULL);
>  
> +	/* Idle the DMAC */
> +	list_for_each_entry_safe(pch, _p, &pdmac->ddma.channels,
> +			chan.device_node)
> +		/* Remove the channel */
> +		list_del(&pch->chan.device_node);
>  probe_err2:
>  	pl330_del(pi);
>  probe_err1:
> @@ -3023,8 +3032,10 @@ static int pl330_remove(struct amba_device *adev)
>  	if (!pdmac)
>  		return 0;
>  
> -	of_dma_controller_free(adev->dev.of_node);
> +	if (adev->dev.of_node)
> +		of_dma_controller_free(adev->dev.of_node);
>  
> +	dma_async_device_unregister(&pdmac->ddma);
>  	amba_set_drvdata(adev, NULL);
>  
>  	/* Idle the DMAC */
> -- 
> 1.7.4.4
> 


From jic23 at kernel.org  Tue Apr  2 14:13:38 2013
From: jic23 at kernel.org (Jonathan Cameron)
Date: Tue, 02 Apr 2013 19:13:38 +0100
Subject: [PATCH] ARM: at91: dts: add adc resolution stuff
In-Reply-To: <5155A731.2060708@atmel.com>
References: <1364548399-15827-1-git-send-email-ludovic.desroches@atmel.com>
 <5155633A.3060701@kernel.org> <5155A731.2060708@atmel.com>
Message-ID: <515B1FD2.50401@kernel.org>

On 03/29/2013 02:37 PM, Nicolas Ferre wrote:
> On 03/29/2013 10:47 AM, Jonathan Cameron :
>> On 03/29/2013 09:13 AM, ludovic.desroches at atmel.com wrote:
>>> From: Ludovic Desroches <ludovic.desroches at atmel.com>
>>>
>>> Add the ADC low and high resolution configuration and which one to use.
>>>
>>> Signed-off-by: Ludovic Desroches <ludovic.desroches at atmel.com>
>>
>>> ---
>>>
>>> Hi,
>>>
>>> This patch is a split from this set of patches:
>>> http://thread.gmane.org/gmane.linux.ports.arm.kernel/206130/focus=6321
>>>
>>> Then device tree changes can go through ARM-SOC and driver changes through the
>>> iio subsystem.
>> I am guessing the IIO side is to follow.  Even when posting series where it different
>> bits are to go through different trees, it is useful to have them in one series so that
>> people can see the whole result.
> 
> Yes, a v2 series is coming. In fact, I asked Ludovic to post his .dtsi
> modifications separately because:
> - From the fist discussion, it seemed that we reached a consensus and
> that the current binding is okay

Consensus is probably putting it a bit strongly given Maxime's comments
but as there was no specific alternative suggested and they Maxime
was raising general issues rathe rthan specifics, I'll take the
iio side of these as is.

> - I have to reassemble a pull-request to arm-soc maintainers for 3.10
> and it seems that is is time to collect all material.
> 
> So, I plan to stack this update of AT91 device tree files real soon. If
> you want to give me your acknowledgement once you have read the whole
> series, let me know...
> 
> Best regards,
> 
> 
>>>  arch/arm/boot/dts/at91sam9260.dtsi | 3 +++
>>>  arch/arm/boot/dts/at91sam9g45.dtsi | 3 +++
>>>  arch/arm/boot/dts/at91sam9x5.dtsi  | 3 +++
>>>  3 files changed, 9 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/at91sam9260.dtsi b/arch/arm/boot/dts/at91sam9260.dtsi
>>> index cb7bcc5..367a604 100644
>>> --- a/arch/arm/boot/dts/at91sam9260.dtsi
>>> +++ b/arch/arm/boot/dts/at91sam9260.dtsi
>>> @@ -484,6 +484,9 @@
>>>  				atmel,adc-drdy-mask = <0x10000>;
>>>  				atmel,adc-status-register = <0x1c>;
>>>  				atmel,adc-trigger-register = <0x04>;
>>> +				atmel,adc-res = <8 10>;
>>> +				atmel,adc-res-names = "lowres", "highres";
>>> +				atmel,adc-use-res = "highres";
>>>  
>>>  				trigger at 0 {
>>>  					trigger-name = "timer-counter-0";
>>> diff --git a/arch/arm/boot/dts/at91sam9g45.dtsi b/arch/arm/boot/dts/at91sam9g45.dtsi
>>> index 6b1d4ca..0fa28af 100644
>>> --- a/arch/arm/boot/dts/at91sam9g45.dtsi
>>> +++ b/arch/arm/boot/dts/at91sam9g45.dtsi
>>> @@ -484,6 +484,9 @@
>>>  				atmel,adc-drdy-mask = <0x10000>;
>>>  				atmel,adc-status-register = <0x1c>;
>>>  				atmel,adc-trigger-register = <0x08>;
>>> +				atmel,adc-res = <8 10>;
>>> +				atmel,adc-res-names = "lowres", "highres";
>>> +				atmel,adc-use-res = "highres";
>>>  
>>>  				trigger at 0 {
>>>  					trigger-name = "external-rising";
>>> diff --git a/arch/arm/boot/dts/at91sam9x5.dtsi b/arch/arm/boot/dts/at91sam9x5.dtsi
>>> index a98c0d5..08bcdd7 100644
>>> --- a/arch/arm/boot/dts/at91sam9x5.dtsi
>>> +++ b/arch/arm/boot/dts/at91sam9x5.dtsi
>>> @@ -505,6 +505,9 @@
>>>  				atmel,adc-drdy-mask = <0x1000000>;
>>>  				atmel,adc-status-register = <0x30>;
>>>  				atmel,adc-trigger-register = <0xc0>;
>>> +				atmel,adc-res = <8 10>;
>>> +				atmel,adc-res-names = "lowres", "highres";
>>> +				atmel,adc-use-res = "highres";
>>>  
>>>  				trigger at 0 {
>>>  					trigger-name = "external-rising";
>>>
>>
>>
> 
> 


From moinejf at free.fr  Tue Apr  2 14:13:48 2013
From: moinejf at free.fr (Jean-Francois Moine)
Date: Tue, 2 Apr 2013 20:13:48 +0200
Subject: [PATCH v2] ARM: kirkwood: extend the kirkwood i2s driver for DT usage
Message-ID: <20130402201348.4ab406fb@armhf>

The kirkwood i2s driver is used without DT in the Kirkwood machine.
This patch adds a DT compatible definition for use in other Marvell
machines as the Armada 88AP510 (Dove).

Signed-off-by: Jean-Francois Moine <moinejf at free.fr>
---
v2
  - this patch replaces the previous
	[PATCH 2/2] ARM: kirkwood: extend the kirkwood i2s driver for DT usage
  - 2 possible clocks (Sebastian Hesselbarth)
  - shorter io mapping (Andrew Lunn)
  - less #ifdef's
---
 .../devicetree/bindings/sound/kirkwood-i2s.txt     |   26 +++++++++
 sound/soc/kirkwood/kirkwood-i2s.c                  |   58 +++++++++++++++-----
 2 files changed, 70 insertions(+), 14 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/sound/kirkwood-i2s.txt

diff --git a/Documentation/devicetree/bindings/sound/kirkwood-i2s.txt b/Documentation/devicetree/bindings/sound/kirkwood-i2s.txt
new file mode 100644
index 0000000..d1caa59
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/kirkwood-i2s.txt
@@ -0,0 +1,26 @@
+* Kirkwood I2S controller
+
+Required properties:
+
+- compatible: "marvell,kirkwood-i2s"
+- reg: physical base address of the controller and length of memory mapped
+  region.
+- interrupts: list of two irq numbers.
+  The first irq is used for data flow and the second one is used for errors.
+- clocks: one or two phandles.
+  The first one is mandatory and defines the internal clock.
+  The second one is optional and defines an external clock.
+
+Optional property:
+
+- marvell,burst-size: burst size which can be only 32 or 128.
+  Default value is 128.
+
+Example:
+
+i2s1: audio-controller at b4000 {
+	compatible = "marvell,kirkwood-i2s";
+	reg = <0xb4000 0x2210>;
+	interrupts = <21>, <22>;
+	clocks = <&gate_clk 13>;
+};
diff --git a/sound/soc/kirkwood/kirkwood-i2s.c b/sound/soc/kirkwood/kirkwood-i2s.c
index c74c890..37370b3 100644
--- a/sound/soc/kirkwood/kirkwood-i2s.c
+++ b/sound/soc/kirkwood/kirkwood-i2s.c
@@ -12,7 +12,6 @@
 
 #include <linux/init.h>
 #include <linux/module.h>
-#include <linux/platform_device.h>
 #include <linux/io.h>
 #include <linux/slab.h>
 #include <linux/mbus.h>
@@ -22,6 +21,8 @@
 #include <sound/pcm_params.h>
 #include <sound/soc.h>
 #include <linux/platform_data/asoc-kirkwood.h>
+#include <linux/of.h>
+
 #include "kirkwood.h"
 
 #define DRV_NAME	"kirkwood-i2s"
@@ -457,6 +458,7 @@ static int kirkwood_i2s_dev_probe(struct platform_device *pdev)
 	struct snd_soc_dai_driver *soc_dai = &kirkwood_i2s_dai;
 	struct kirkwood_dma_data *priv;
 	struct resource *mem;
+	struct device_node *np;
 	int err;
 
 	priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
@@ -482,24 +484,41 @@ static int kirkwood_i2s_dev_probe(struct platform_device *pdev)
 		return -ENXIO;
 	}
 
-	if (!data) {
-		dev_err(&pdev->dev, "no platform data ?!\n");
-		return -EINVAL;
-	}
+	/* get the DT or static parameters */
+	np = pdev->dev.of_node;
+	if (np) {
+		u32 val;
+
+		if (of_property_read_u32(np, "marvell,burst-size", &val)) {
+			val = 128;		/* default value */
+		} else if (val != 32 && val != 128) {
+			dev_err(&pdev->dev,
+				"'marvell,burst-size' can be only 32 or 128\n");
+			return -EINVAL;
+		}
+		priv->burst = val;
+		priv->clk = of_clk_get(np, 0);		/* internal clock */
+		priv->extclk = of_clk_get(np, 1); /* optional external clock */
+	} else {
+		if (!data) {
+			dev_err(&pdev->dev, "no platform data ?!\n");
+			return -EINVAL;
+		}
+		priv->burst = data->burst;
 
-	priv->burst = data->burst;
+		priv->clk = clk_get(&pdev->dev, NULL);
+		priv->extclk = clk_get(&pdev->dev, "extclk");
+	}
 
-	priv->clk = devm_clk_get(&pdev->dev, NULL);
 	if (IS_ERR(priv->clk)) {
 		dev_err(&pdev->dev, "no clock\n");
-		return PTR_ERR(priv->clk);
+		err = PTR_ERR(priv->clk);
+		goto error;
 	}
-
 	err = clk_prepare_enable(priv->clk);
 	if (err < 0)
-		return err;
+		goto error;
 
-	priv->extclk = clk_get(&pdev->dev, "extclk");
 	if (!IS_ERR(priv->extclk)) {
 		if (priv->extclk == priv->clk) {
 			clk_put(priv->extclk);
@@ -516,7 +535,7 @@ static int kirkwood_i2s_dev_probe(struct platform_device *pdev)
 	priv->ctl_rec = KIRKWOOD_RECCTL_SIZE_24;
 
 	/* Select the burst size */
-	if (data->burst == 32) {
+	if (priv->burst == 32) {
 		priv->ctl_play |= KIRKWOOD_PLAYCTL_BURST_32;
 		priv->ctl_rec |= KIRKWOOD_RECCTL_BURST_32;
 	} else {
@@ -528,12 +547,13 @@ static int kirkwood_i2s_dev_probe(struct platform_device *pdev)
 	if (!err)
 		return 0;
 	dev_err(&pdev->dev, "snd_soc_register_dai failed\n");
-
+error:
 	if (!IS_ERR(priv->extclk)) {
 		clk_disable_unprepare(priv->extclk);
 		clk_put(priv->extclk);
 	}
 	clk_disable_unprepare(priv->clk);
+	clk_put(priv->clk);
 
 	return err;
 }
@@ -549,16 +569,26 @@ static int kirkwood_i2s_dev_remove(struct platform_device *pdev)
 		clk_put(priv->extclk);
 	}
 	clk_disable_unprepare(priv->clk);
+	clk_put(priv->clk);
 
 	return 0;
 }
 
+#ifdef CONFIG_OF
+static struct of_device_id kirkwood_i2s_of_match[] = {
+	{ .compatible = "marvell,kirkwood-i2s" },
+	{ }
+};
+MODULE_DEVICE_TABLE(of, kirkwood_i2s_of_match);
+#endif
+
 static struct platform_driver kirkwood_i2s_driver = {
 	.probe  = kirkwood_i2s_dev_probe,
 	.remove = kirkwood_i2s_dev_remove,
 	.driver = {
 		.name = DRV_NAME,
 		.owner = THIS_MODULE,
+		.of_match_table = of_match_ptr(kirkwood_i2s_of_match),
 	},
 };
 
-- 
1.7.10.4



-- 
Ken ar c'henta?	|	      ** Breizh ha Linux atav! **
Jef		|		http://moinejf.free.fr/


From linux at prisktech.co.nz  Tue Apr  2 14:18:29 2013
From: linux at prisktech.co.nz (Tony Prisk)
Date: Wed, 03 Apr 2013 07:18:29 +1300
Subject: [PATCHv2 6/6] video: fb: vt8500: Convert framebuffer drivers
 to standardized binding
In-Reply-To: <20130402115014.GL20693@game.jcrosoft.org>
References: <1364878200-26343-1-git-send-email-linux@prisktech.co.nz>
 <1364878200-26343-7-git-send-email-linux@prisktech.co.nz>
 <515AB229.4050204@ti.com>
 <CABjd4Yx7zBAR+o-X7u9K9+iUeMq5qc=8n70qx1EoKPBT1JMR4A@mail.gmail.com>
 <20130402115014.GL20693@game.jcrosoft.org>
Message-ID: <515B20F5.4000708@prisktech.co.nz>

On 03/04/13 00:50, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 14:41 Tue 02 Apr     , Alexey Charkov wrote:
>> 2013/4/2 Tomi Valkeinen <tomi.valkeinen at ti.com>:
>>> On 2013-04-02 07:50, Tony Prisk wrote:
>>>> Now that a display timing binding is available, convert our almost identical
>>>> binding to use the standard binding.
>>>>
>>>> This patch converts the vt8500 and wm8505 framebuffer drivers and
>>>> associated dts/dtsi files to use the standard binding as defined in
>>>> bindings/video/display-timing.txt.
>>>>
>>>> There are two side-effects of making this conversion:
>>>>
>>>> 1) The fb node should now be in the board file, rather than the soc file as
>>>> the display-timing node is a child of the fb node.
>>>>
>>>> 2) We still require a bits per pixel property to initialize the framebuffer
>>>> for the different lcd panels. Rather than including this as part of the
>>>> display timing, it is moved into the framebuffer node.
>>> This means that the boards using the current DT bindings won't work with
>>> a kernel with these patches, right? Is that ok?
>> There are no known products shipping any DT-enabled firmware with
>> these chips in the wild. The only way to run modern kernels on
>> VIA/WonderMedia chips so far is by using the "appended DTB"
>> workaround, and the instructions that have been posted to Wiki's and
>> mailing list discussions imply that a fresh DTB is compiled from
>> current kernel sources to produce a bootable image.
>>
>> Thus, it seems that this change should not really break anything
>> major, as the user base is quite small and those who use new code are
>> most likely to use new DTB as well.
> I usually disagree but ok
>
> Best Regards,
> J.
The original binding was only ever meant to be a stop-gap as it was 
required for us to make the conversion to multiplatform/devicetree, and
was only agreed upon because without it all the other code was pointless 
and arch-vt8500 was suffering from bitrot at the time. It was always the 
intention to update to the standardized binding once it was mainlined.I 
haven't been able to find the original thread where it was discussed, 
but it was around Aug 2012.

Regards
Tony P


From vinod.koul at intel.com  Tue Apr  2 13:51:28 2013
From: vinod.koul at intel.com (Vinod Koul)
Date: Tue, 2 Apr 2013 23:21:28 +0530
Subject: [PATCH 1/2] dmaengine: add const for name parameter
In-Reply-To: <20130321145728.GD23109@S2101-09.ap.freescale.net>
References: <1363318601-31505-1-git-send-email-shawn.guo@linaro.org>
 <1363318601-31505-2-git-send-email-shawn.guo@linaro.org>
 <20130315085346.GA22650@pengutronix.de>
 <20130321094753.GN10326@intel.com>
 <20130321145728.GD23109@S2101-09.ap.freescale.net>
Message-ID: <20130402175128.GN10326@intel.com>

On Thu, Mar 21, 2013 at 10:57:30PM +0800, Shawn Guo wrote:
> Vinod,
> 
> On Thu, Mar 21, 2013 at 03:17:53PM +0530, Vinod Koul wrote:
> > On Fri, Mar 15, 2013 at 09:53:46AM +0100, Markus Pargmann wrote:
> > > Hi,
> > > 
> > > I already sent a nearly identical patch:
> > > https://patchwork.kernel.org/patch/2179321/
> > I applied that one a while ago so Markus can you check my tree and see if
> > anything is remaining, looks most of cases are covered
> > 
> Can you maintain that patch on a topic branch, so that we can ask Mark
> to pull it as dependency for the soc-dmaengine-pcm patch that support
> generic DMA binding users?
Looks like i never replied to this one, althoug I have pushed a branch

Mark,

You can pull commit a0c43a3 from topic/of or the entire branch into your tree

--
Thanks
~Vinod


From jic23 at kernel.org  Tue Apr  2 14:20:02 2013
From: jic23 at kernel.org (Jonathan Cameron)
Date: Tue, 02 Apr 2013 19:20:02 +0100
Subject: [PATCH 1/3] iio: at91_adc: add low and high res support
In-Reply-To: <1364568853-18561-2-git-send-email-ludovic.desroches@atmel.com>
References: <1364568853-18561-1-git-send-email-ludovic.desroches@atmel.com>
 <1364568853-18561-2-git-send-email-ludovic.desroches@atmel.com>
Message-ID: <515B2152.4030506@kernel.org>

On 03/29/2013 02:54 PM, ludovic.desroches at atmel.com wrote:
> From: Ludovic Desroches <ludovic.desroches at atmel.com>
> 
> at91 adc offers the choice between two resolutions: low and high.
> The low and high resolution values depends on adc IP version, as many IP
> properties have been exposed through device tree, these settings have also
> been added to the dt bindings.
> 
> Signed-off-by: Ludovic Desroches <ludovic.desroches at atmel.com>
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
Applied to the togreg branch of iio.git

> ---
>  .../devicetree/bindings/arm/atmel-adc.txt          | 11 ++++
>  drivers/iio/adc/at91_adc.c                         | 74 ++++++++++++++++++++--
>  2 files changed, 81 insertions(+), 4 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/arm/atmel-adc.txt b/Documentation/devicetree/bindings/arm/atmel-adc.txt
> index c63097d..fd2d69e 100644
> --- a/Documentation/devicetree/bindings/arm/atmel-adc.txt
> +++ b/Documentation/devicetree/bindings/arm/atmel-adc.txt
> @@ -14,9 +14,17 @@ Required properties:
>    - atmel,adc-status-register: Offset of the Interrupt Status Register
>    - atmel,adc-trigger-register: Offset of the Trigger Register
>    - atmel,adc-vref: Reference voltage in millivolts for the conversions
> +  - atmel,adc-res: List of resolution in bits supported by the ADC. List size
> +		   must be two at least.
> +  - atmel,adc-res-names: Contains one identifier string for each resolution
> +			 in atmel,adc-res property. "lowres" and "highres"
> +			 identifiers are required.
>  
>  Optional properties:
>    - atmel,adc-use-external: Boolean to enable of external triggers
> +  - atmel,adc-use-res: String corresponding to an identifier from
> +		       atmel,adc-res-names property. If not specified, the highest
> +		       resolution will be used.
>   
>  Optional trigger Nodes:
>    - Required properties:
> @@ -40,6 +48,9 @@ adc0: adc at fffb0000 {
>  	atmel,adc-trigger-register = <0x08>;
>  	atmel,adc-use-external;
>  	atmel,adc-vref = <3300>;
> +	atmel,adc-res = <8 10>;
> +	atmel,adc-res-names = "lowres", "highres";
> +	atmel,adc-use-res = "lowres";
>  
>  	trigger at 0 {
>  		trigger-name = "external-rising";
> diff --git a/drivers/iio/adc/at91_adc.c b/drivers/iio/adc/at91_adc.c
> index 83c836b..a7ad3e7 100644
> --- a/drivers/iio/adc/at91_adc.c
> +++ b/drivers/iio/adc/at91_adc.c
> @@ -57,6 +57,8 @@ struct at91_adc_state {
>  	u32			trigger_number;
>  	bool			use_external;
>  	u32			vref_mv;
> +	u32			res;		/* resolution used for convertions */
> +	bool			low_res;	/* the resolution corresponds to the lowest one */
>  	wait_queue_head_t	wq_data_avail;
>  };
>  
> @@ -138,7 +140,7 @@ static int at91_adc_channel_init(struct iio_dev *idev)
>  		chan->channel = bit;
>  		chan->scan_index = idx;
>  		chan->scan_type.sign = 'u';
> -		chan->scan_type.realbits = 10;
> +		chan->scan_type.realbits = st->res;
>  		chan->scan_type.storagebits = 16;
>  		chan->info_mask = IIO_CHAN_INFO_SCALE_SHARED_BIT |
>  			IIO_CHAN_INFO_RAW_SEPARATE_BIT;
> @@ -372,6 +374,59 @@ static int at91_adc_read_raw(struct iio_dev *idev,
>  	return -EINVAL;
>  }
>  
> +static int at91_adc_of_get_resolution(struct at91_adc_state *st,
> +				      struct platform_device *pdev)
> +{
> +	struct iio_dev *idev = iio_priv_to_dev(st);
> +	struct device_node *np = pdev->dev.of_node;
> +	int count, i, ret = 0;
> +	char *res_name, *s;
> +	u32 *resolutions;
> +
> +	count = of_property_count_strings(np, "atmel,adc-res-names");
> +	if (count < 2) {
> +		dev_err(&idev->dev, "You must specified at least two resolution names for "
> +				    "adc-res-names property in the DT\n");
> +		return count;
> +	}
> +
> +	resolutions = kmalloc(count * sizeof(*resolutions), GFP_KERNEL);
> +	if (!resolutions)
> +		return -ENOMEM;
> +
> +	if (of_property_read_u32_array(np, "atmel,adc-res", resolutions, count)) {
> +		dev_err(&idev->dev, "Missing adc-res property in the DT.\n");
> +		ret = -ENODEV;
> +		goto ret;
> +	}
> +
> +	if (of_property_read_string(np, "atmel,adc-use-res", (const char **)&res_name))
> +		res_name = "highres";
> +
> +	for (i = 0; i < count; i++) {
> +		if (of_property_read_string_index(np, "atmel,adc-res-names", i, (const char **)&s))
> +			continue;
> +
> +		if (strcmp(res_name, s))
> +			continue;
> +
> +		st->res = resolutions[i];
> +		if (!strcmp(res_name, "lowres"))
> +			st->low_res = true;
> +		else
> +			st->low_res = false;
> +
> +		dev_info(&idev->dev, "Resolution used: %u bits\n", st->res);
> +		goto ret;
> +	}
> +
> +	dev_err(&idev->dev, "There is no resolution for %s\n", res_name);
> +
> +ret:
> +	kfree(resolutions);
> +	return ret;
> +}
> +
>  static int at91_adc_probe_dt(struct at91_adc_state *st,
>  			     struct platform_device *pdev)
>  {
> @@ -415,6 +470,10 @@ static int at91_adc_probe_dt(struct at91_adc_state *st,
>  	}
>  	st->vref_mv = prop;
>  
> +	ret = at91_adc_of_get_resolution(st, pdev);
> +	if (ret)
> +		goto error_ret;
> +
>  	st->registers = devm_kzalloc(&idev->dev,
>  				     sizeof(struct at91_adc_reg_desc),
>  				     GFP_KERNEL);
> @@ -628,9 +687,16 @@ static int at91_adc_probe(struct platform_device *pdev)
>  	 */
>  	ticks = round_up((st->startup_time * adc_clk /
>  			  1000000) - 1, 8) / 8;
> -	at91_adc_writel(st, AT91_ADC_MR,
> -			(AT91_ADC_PRESCAL_(prsc) & AT91_ADC_PRESCAL) |
> -			(AT91_ADC_STARTUP_(ticks) & AT91_ADC_STARTUP));
> +
> +	if (st->low_res)
> +		at91_adc_writel(st, AT91_ADC_MR,
> +				AT91_ADC_LOWRES |
> +				(AT91_ADC_PRESCAL_(prsc) & AT91_ADC_PRESCAL) |
> +				(AT91_ADC_STARTUP_(ticks) & AT91_ADC_STARTUP));
> +	else
> +		at91_adc_writel(st, AT91_ADC_MR,
> +				(AT91_ADC_PRESCAL_(prsc) & AT91_ADC_PRESCAL) |
> +				(AT91_ADC_STARTUP_(ticks) & AT91_ADC_STARTUP));
>  
>  	/* Setup the ADC channels available on the board */
>  	ret = at91_adc_channel_init(idev);
> 


From linux at prisktech.co.nz  Tue Apr  2 14:20:35 2013
From: linux at prisktech.co.nz (Tony Prisk)
Date: Wed,  3 Apr 2013 07:20:35 +1300
Subject: [PATCHv3 3/6] video: vt8500: Correct descriptions in video/Kconfig
In-Reply-To: <1364926838-6721-1-git-send-email-linux@prisktech.co.nz>
References: <1364926838-6721-1-git-send-email-linux@prisktech.co.nz>
Message-ID: <1364926838-6721-4-git-send-email-linux@prisktech.co.nz>

This patch corrects the descriptions for the VIA VT8500 and
Wondermedia WM8xxx-series framebuffer drivers to correctly reflect
which hardware they support.

Signed-off-by: Tony Prisk <linux at prisktech.co.nz>
Reviewed-by: Jean-Christophe Plagniol-Villard <plagnioj at jcrosoft.com>
---
 drivers/video/Kconfig |   11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 661aa54..ad762ed 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -1789,7 +1789,7 @@ config FB_AU1200
 	  option au1200fb:panel=<name>.
 
 config FB_VT8500
-	bool "VT8500 LCD Driver"
+	bool "VIA VT8500 framebuffer support"
 	depends on (FB = y) && ARM && ARCH_VT8500
 	select FB_SYS_FILLRECT if (!FB_WMT_GE_ROPS)
 	select FB_SYS_COPYAREA if (!FB_WMT_GE_ROPS)
@@ -1799,17 +1799,18 @@ config FB_VT8500
 	  controller.
 
 config FB_WM8505
-	bool "WM8505 frame buffer support"
+	bool "Wondermedia WM8xxx-series frame buffer support"
 	depends on (FB = y) && ARM && ARCH_VT8500
 	select FB_SYS_FILLRECT if (!FB_WMT_GE_ROPS)
 	select FB_SYS_COPYAREA if (!FB_WMT_GE_ROPS)
 	select FB_SYS_IMAGEBLIT
 	help
-	  This is the framebuffer driver for WonderMedia WM8505/WM8650
-	  integrated LCD controller.
+	  This is the framebuffer driver for WonderMedia WM8xxx-series
+	  integrated LCD controller. This driver covers the WM8505, WM8650
+	  and WM8850 SoCs.
 
 config FB_WMT_GE_ROPS
-	bool "VT8500/WM85xx accelerated raster ops support"
+	bool "VT8500/WM8xxx accelerated raster ops support"
 	depends on (FB = y) && (FB_VT8500 || FB_WM8505)
 	default n
 	help
-- 
1.7.9.5



From linux at prisktech.co.nz  Tue Apr  2 14:20:34 2013
From: linux at prisktech.co.nz (Tony Prisk)
Date: Wed,  3 Apr 2013 07:20:34 +1300
Subject: [PATCHv3 2/6] video: vt8500: Remove unused
 platform_data/video-vt8500lcdfb.h
In-Reply-To: <1364926838-6721-1-git-send-email-linux@prisktech.co.nz>
References: <1364926838-6721-1-git-send-email-linux@prisktech.co.nz>
Message-ID: <1364926838-6721-3-git-send-email-linux@prisktech.co.nz>

With the conversion to devicetree only for arch-vt8500, this
header is no longer required. This patch removes the #include
from the two framebuffer drivers that used it, and the header file.

Signed-off-by: Tony Prisk <linux at prisktech.co.nz>
Reviewed-by: Jean-Christophe Plagniol-Villard <plagnioj at jcrosoft.com>
---
 drivers/video/vt8500lcdfb.c                     |    2 --
 drivers/video/wm8505fb.c                        |    2 --
 include/linux/platform_data/video-vt8500lcdfb.h |   31 -----------------------
 3 files changed, 35 deletions(-)
 delete mode 100644 include/linux/platform_data/video-vt8500lcdfb.h

diff --git a/drivers/video/vt8500lcdfb.c b/drivers/video/vt8500lcdfb.c
index aa2579c..2ff2312 100644
--- a/drivers/video/vt8500lcdfb.c
+++ b/drivers/video/vt8500lcdfb.c
@@ -30,8 +30,6 @@
 #include <linux/platform_device.h>
 #include <linux/wait.h>
 
-#include <linux/platform_data/video-vt8500lcdfb.h>
-
 #include "vt8500lcdfb.h"
 #include "wmt_ge_rops.h"
 
diff --git a/drivers/video/wm8505fb.c b/drivers/video/wm8505fb.c
index 4dd0580..fe9afd6 100644
--- a/drivers/video/wm8505fb.c
+++ b/drivers/video/wm8505fb.c
@@ -32,8 +32,6 @@
 #include <linux/of_fdt.h>
 #include <linux/memblock.h>
 
-#include <linux/platform_data/video-vt8500lcdfb.h>
-
 #include "wm8505fb_regs.h"
 #include "wmt_ge_rops.h"
 
diff --git a/include/linux/platform_data/video-vt8500lcdfb.h b/include/linux/platform_data/video-vt8500lcdfb.h
deleted file mode 100644
index 7f399c3..0000000
--- a/include/linux/platform_data/video-vt8500lcdfb.h
+++ /dev/null
@@ -1,31 +0,0 @@
-/*
- *  VT8500/WM8505 Frame Buffer platform data definitions
- *
- *  Copyright (C) 2010 Ed Spiridonov <edo.rus at gmail.com>
- *
- * This software is licensed under the terms of the GNU General Public
- * License version 2, as published by the Free Software Foundation, and
- * may be copied, distributed, and modified under those terms.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- */
-
-#ifndef _VT8500FB_H
-#define _VT8500FB_H
-
-#include <linux/fb.h>
-
-struct vt8500fb_platform_data {
-	struct fb_videomode	mode;
-	u32			xres_virtual;
-	u32			yres_virtual;
-	u32			bpp;
-	unsigned long		video_mem_phys;
-	void			*video_mem_virt;
-	unsigned long		video_mem_len;
-};
-
-#endif /* _VT8500FB_H */
-- 
1.7.9.5



From linux at prisktech.co.nz  Tue Apr  2 14:20:32 2013
From: linux at prisktech.co.nz (Tony Prisk)
Date: Wed,  3 Apr 2013 07:20:32 +1300
Subject: [PATCHv3 0/6] fb: vt8500: patches for 3.10
Message-ID: <1364926838-6721-1-git-send-email-linux@prisktech.co.nz>

V3 Changes:
Tidied up patch 1 as requested by Jean-Christophe - Makes the patch much
simpler.

V2 Changes:
Split the SoC and board portions of the binding into their respective files.
Removed the forced non-interlaced code from wm8505fb.c and vt8500lcdfb.c

Julia Lawall (1):
  drivers/video/wm8505fb.c: use devm_ functions

Tony Prisk (5):
  video: vt8500: Make wmt_ge_rops optional
  video: vt8500: Remove unused platform_data/video-vt8500lcdfb.h
  video: vt8500: Correct descriptions in video/Kconfig
  video: vt8500: Adjust contrast in wm8505 framebuffer driver.
  video: fb: vt8500: Convert framebuffer drivers to standardized
    binding

 .../devicetree/bindings/video/via,vt8500-fb.txt    |   48 ++-----
 .../devicetree/bindings/video/wm,wm8505-fb.txt     |   32 +++--
 arch/arm/boot/dts/vt8500-bv07.dts                  |   34 ++---
 arch/arm/boot/dts/vt8500.dtsi                      |    4 +-
 arch/arm/boot/dts/wm8505-ref.dts                   |   34 ++---
 arch/arm/boot/dts/wm8505.dtsi                      |    4 +-
 arch/arm/boot/dts/wm8650-mid.dts                   |   36 +++--
 arch/arm/boot/dts/wm8650.dtsi                      |    4 +-
 arch/arm/boot/dts/wm8850-w70v2.dts                 |   40 +++---
 arch/arm/boot/dts/wm8850.dtsi                      |    4 +-
 drivers/video/Kconfig                              |   37 +++--
 drivers/video/vt8500lcdfb.c                        |   55 +++-----
 drivers/video/wm8505fb.c                           |  144 ++++++--------------
 drivers/video/wmt_ge_rops.h                        |   23 ++++
 include/linux/platform_data/video-vt8500lcdfb.h    |   31 -----
 15 files changed, 211 insertions(+), 319 deletions(-)
 delete mode 100644 include/linux/platform_data/video-vt8500lcdfb.h

-- 
1.7.9.5



From linux at prisktech.co.nz  Tue Apr  2 14:20:33 2013
From: linux at prisktech.co.nz (Tony Prisk)
Date: Wed,  3 Apr 2013 07:20:33 +1300
Subject: [PATCHv3 1/6] video: vt8500: Make wmt_ge_rops optional
In-Reply-To: <1364926838-6721-1-git-send-email-linux@prisktech.co.nz>
References: <1364926838-6721-1-git-send-email-linux@prisktech.co.nz>
Message-ID: <1364926838-6721-2-git-send-email-linux@prisktech.co.nz>

wmt_ge_rops is a seperate driver to vt8500/wm8505 framebuffer
driver but is currently a required option. This patch makes
accelerated raster ops optional.

Signed-off-by: Tony Prisk <linux at prisktech.co.nz>
Reviewed-by: Jean-Christophe Plagniol-Villard <plagnioj at jcrosoft.com>
---
 drivers/video/Kconfig       |   22 ++++++++++++----------
 drivers/video/wmt_ge_rops.h |   23 +++++++++++++++++++++++
 2 files changed, 35 insertions(+), 10 deletions(-)

diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 4c1546f..661aa54 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -212,14 +212,6 @@ config FB_SYS_FOPS
        depends on FB
        default n
 
-config FB_WMT_GE_ROPS
-	tristate
-	depends on FB
-	default n
-	---help---
-	  Include functions for accelerated rectangle filling and area
-	  copying using WonderMedia Graphics Engine operations.
-
 config FB_DEFERRED_IO
 	bool
 	depends on FB
@@ -1799,7 +1791,8 @@ config FB_AU1200
 config FB_VT8500
 	bool "VT8500 LCD Driver"
 	depends on (FB = y) && ARM && ARCH_VT8500
-	select FB_WMT_GE_ROPS
+	select FB_SYS_FILLRECT if (!FB_WMT_GE_ROPS)
+	select FB_SYS_COPYAREA if (!FB_WMT_GE_ROPS)
 	select FB_SYS_IMAGEBLIT
 	help
 	  This is the framebuffer driver for VIA VT8500 integrated LCD
@@ -1808,12 +1801,21 @@ config FB_VT8500
 config FB_WM8505
 	bool "WM8505 frame buffer support"
 	depends on (FB = y) && ARM && ARCH_VT8500
-	select FB_WMT_GE_ROPS
+	select FB_SYS_FILLRECT if (!FB_WMT_GE_ROPS)
+	select FB_SYS_COPYAREA if (!FB_WMT_GE_ROPS)
 	select FB_SYS_IMAGEBLIT
 	help
 	  This is the framebuffer driver for WonderMedia WM8505/WM8650
 	  integrated LCD controller.
 
+config FB_WMT_GE_ROPS
+	bool "VT8500/WM85xx accelerated raster ops support"
+	depends on (FB = y) && (FB_VT8500 || FB_WM8505)
+	default n
+	help
+	  This adds support for accelerated raster operations on the
+	  VIA VT8500 and Wondermedia 85xx series SoCs.
+
 source "drivers/video/geode/Kconfig"
 
 config FB_HIT
diff --git a/drivers/video/wmt_ge_rops.h b/drivers/video/wmt_ge_rops.h
index 8738075..f73ec63 100644
--- a/drivers/video/wmt_ge_rops.h
+++ b/drivers/video/wmt_ge_rops.h
@@ -1,5 +1,28 @@
+#ifdef CONFIG_FB_WMT_GE_ROPS
+
 extern void wmt_ge_fillrect(struct fb_info *info,
 			    const struct fb_fillrect *rect);
 extern void wmt_ge_copyarea(struct fb_info *info,
 			    const struct fb_copyarea *area);
 extern int wmt_ge_sync(struct fb_info *info);
+
+#else
+
+static inline int wmt_ge_sync(struct fb_info *p)
+{
+	return 0;
+}
+
+static inline void wmt_ge_fillrect(struct fb_info *p,
+				    const struct fb_fillrect *rect)
+{
+	sys_fillrect(p, rect);
+}
+
+static inline void wmt_ge_copyarea(struct fb_info *p,
+				     const struct fb_copyarea *area)
+{
+	sys_copyarea(p, area);
+}
+
+#endif
-- 
1.7.9.5



From linux at prisktech.co.nz  Tue Apr  2 14:20:36 2013
From: linux at prisktech.co.nz (Tony Prisk)
Date: Wed,  3 Apr 2013 07:20:36 +1300
Subject: [PATCHv3 4/6] drivers/video/wm8505fb.c: use devm_ functions
In-Reply-To: <1364926838-6721-1-git-send-email-linux@prisktech.co.nz>
References: <1364926838-6721-1-git-send-email-linux@prisktech.co.nz>
Message-ID: <1364926838-6721-5-git-send-email-linux@prisktech.co.nz>

From: Julia Lawall <Julia.Lawall at lip6.fr>

The various devm_ functions allocate memory that is released when a driver
detaches.  This patch uses these functions for data that is allocated in
the probe function of a platform device and is only freed in the remove
function.

The patch makes some other cleanups.  First, the original code used
devm_kzalloc, but kfree.  This would lead to a double free.  The problem
was found using the following semantic match (http://coccinelle.lip6.fr/):

// <smpl>
@@
expression x,e;
@@
x = devm_kzalloc(...)
... when != x = e
?-kfree(x,...);
// </smpl>

The error-handing code of devm_request_and_ioremap does not print any
warning message, because devm_request_and_ioremap does this.

The call to dma_alloc_coherent is converted to its devm equivalent,
dmam_alloc_coherent.  This implicitly introduces a call to
dmam_free_coherent, which was completly missing in the original code.

A semicolon is removed at the end of the error-handling code for the call
to dma_alloc_coherent.

The block of code calling fb_alloc_cmap is moved below the block of code
calling wm8505fb_set_par, so that the error-handing code of the call to
wm8505fb_set_par can just return ret.  This way there is only one block of
error-handling code that needs to call fb_dealloc_cmap, and so this is
moved up to the place where it is needed, eliminating the need for all
gotos and labels in the function.  This was suggested by Tony Prisk.

The initializations of fbi and ret at the beginning of the function are not
necessary and are removed.  The call platform_set_drvdata(pdev, NULL); at
the end of the function is also removed.

Signed-off-by: Julia Lawall <Julia.Lawall at lip6.fr>
Signed-off-by: Tony Prisk <linux at prisktech.co.nz>
---
 drivers/video/wm8505fb.c |   79 +++++++++++-----------------------------------
 1 file changed, 19 insertions(+), 60 deletions(-)

diff --git a/drivers/video/wm8505fb.c b/drivers/video/wm8505fb.c
index fe9afd6..020df1d 100644
--- a/drivers/video/wm8505fb.c
+++ b/drivers/video/wm8505fb.c
@@ -272,15 +272,11 @@ static int wm8505fb_probe(struct platform_device *pdev)
 	unsigned long fb_mem_len;
 	void *fb_mem_virt;
 
-	ret = -ENOMEM;
-	fbi = NULL;
-
 	fbi = devm_kzalloc(&pdev->dev, sizeof(struct wm8505fb_info) +
 			sizeof(u32) * 16, GFP_KERNEL);
 	if (!fbi) {
 		dev_err(&pdev->dev, "Failed to initialize framebuffer device\n");
-		ret = -ENOMEM;
-		goto failed;
+		return -ENOMEM;
 	}
 
 	strcpy(fbi->fb.fix.id, DRIVER_NAME);
@@ -306,31 +302,14 @@ static int wm8505fb_probe(struct platform_device *pdev)
 	fbi->fb.pseudo_palette	= addr;
 
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-	if (res == NULL) {
-		dev_err(&pdev->dev, "no I/O memory resource defined\n");
-		ret = -ENODEV;
-		goto failed_fbi;
-	}
-
-	res = request_mem_region(res->start, resource_size(res), DRIVER_NAME);
-	if (res == NULL) {
-		dev_err(&pdev->dev, "failed to request I/O memory\n");
-		ret = -EBUSY;
-		goto failed_fbi;
-	}
-
-	fbi->regbase = ioremap(res->start, resource_size(res));
-	if (fbi->regbase == NULL) {
-		dev_err(&pdev->dev, "failed to map I/O memory\n");
-		ret = -EBUSY;
-		goto failed_free_res;
-	}
+	fbi->regbase = devm_request_and_ioremap(&pdev->dev, res);
+	if (fbi->regbase == NULL)
+		return -EBUSY;
 
 	np = of_parse_phandle(pdev->dev.of_node, "default-mode", 0);
 	if (!np) {
 		pr_err("%s: No display description in Device Tree\n", __func__);
-		ret = -EINVAL;
-		goto failed_free_res;
+		return -EINVAL;
 	}
 
 	/*
@@ -349,7 +328,7 @@ static int wm8505fb_probe(struct platform_device *pdev)
 	ret |= of_property_read_u32(np, "bpp", &bpp);
 	if (ret) {
 		pr_err("%s: Unable to read display properties\n", __func__);
-		goto failed_free_res;
+		return -EINVAL;
 	}
 
 	of_mode.vmode = FB_VMODE_NONINTERLACED;
@@ -363,12 +342,12 @@ static int wm8505fb_probe(struct platform_device *pdev)
 
 	/* try allocating the framebuffer */
 	fb_mem_len = of_mode.xres * of_mode.yres * 2 * (bpp / 8);
-	fb_mem_virt = dma_alloc_coherent(&pdev->dev, fb_mem_len, &fb_mem_phys,
+	fb_mem_virt = dmam_alloc_coherent(&pdev->dev, fb_mem_len, &fb_mem_phys,
 				GFP_KERNEL);
 	if (!fb_mem_virt) {
 		pr_err("%s: Failed to allocate framebuffer\n", __func__);
 		return -ENOMEM;
-	};
+	}
 
 	fbi->fb.var.xres_virtual	= of_mode.xres;
 	fbi->fb.var.yres_virtual	= of_mode.yres * 2;
@@ -379,28 +358,29 @@ static int wm8505fb_probe(struct platform_device *pdev)
 	fbi->fb.screen_base		= fb_mem_virt;
 	fbi->fb.screen_size		= fb_mem_len;
 
-	if (fb_alloc_cmap(&fbi->fb.cmap, 256, 0) < 0) {
-		dev_err(&pdev->dev, "Failed to allocate color map\n");
-		ret = -ENOMEM;
-		goto failed_free_io;
-	}
-
-	wm8505fb_init_hw(&fbi->fb);
-
 	fbi->contrast = 0x80;
 	ret = wm8505fb_set_par(&fbi->fb);
 	if (ret) {
 		dev_err(&pdev->dev, "Failed to set parameters\n");
-		goto failed_free_cmap;
+		return ret;
 	}
 
+	if (fb_alloc_cmap(&fbi->fb.cmap, 256, 0) < 0) {
+		dev_err(&pdev->dev, "Failed to allocate color map\n");
+		return -ENOMEM;
+	}
+
+	wm8505fb_init_hw(&fbi->fb);
+
 	platform_set_drvdata(pdev, fbi);
 
 	ret = register_framebuffer(&fbi->fb);
 	if (ret < 0) {
 		dev_err(&pdev->dev,
 			"Failed to register framebuffer device: %d\n", ret);
-		goto failed_free_cmap;
+		if (fbi->fb.cmap.len)
+			fb_dealloc_cmap(&fbi->fb.cmap);
+		return ret;
 	}
 
 	ret = device_create_file(&pdev->dev, &dev_attr_contrast);
@@ -414,25 +394,11 @@ static int wm8505fb_probe(struct platform_device *pdev)
 	       fbi->fb.fix.smem_start + fbi->fb.fix.smem_len - 1);
 
 	return 0;
-
-failed_free_cmap:
-	if (fbi->fb.cmap.len)
-		fb_dealloc_cmap(&fbi->fb.cmap);
-failed_free_io:
-	iounmap(fbi->regbase);
-failed_free_res:
-	release_mem_region(res->start, resource_size(res));
-failed_fbi:
-	platform_set_drvdata(pdev, NULL);
-	kfree(fbi);
-failed:
-	return ret;
 }
 
 static int wm8505fb_remove(struct platform_device *pdev)
 {
 	struct wm8505fb_info *fbi = platform_get_drvdata(pdev);
-	struct resource *res;
 
 	device_remove_file(&pdev->dev, &dev_attr_contrast);
 
@@ -443,13 +409,6 @@ static int wm8505fb_remove(struct platform_device *pdev)
 	if (fbi->fb.cmap.len)
 		fb_dealloc_cmap(&fbi->fb.cmap);
 
-	iounmap(fbi->regbase);
-
-	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-	release_mem_region(res->start, resource_size(res));
-
-	kfree(fbi);
-
 	return 0;
 }
 
-- 
1.7.9.5



From linux at prisktech.co.nz  Tue Apr  2 14:20:37 2013
From: linux at prisktech.co.nz (Tony Prisk)
Date: Wed,  3 Apr 2013 07:20:37 +1300
Subject: [PATCHv3 5/6] video: vt8500: Adjust contrast in wm8505 framebuffer
 driver.
In-Reply-To: <1364926838-6721-1-git-send-email-linux@prisktech.co.nz>
References: <1364926838-6721-1-git-send-email-linux@prisktech.co.nz>
Message-ID: <1364926838-6721-6-git-send-email-linux@prisktech.co.nz>

The contrast value was typo'd on the original commit (0x80 instead of
0x08). Following feedback from an enduser, a value of 0x10 seems more
suitable due to the default backlight being <100%.

Signed-off-by: Tony Prisk <linux at prisktech.co.nz>
Reviewed-by: Jean-Christophe Plagniol-Villard <plagnioj at jcrosoft.com>
---
 drivers/video/wm8505fb.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/wm8505fb.c b/drivers/video/wm8505fb.c
index 020df1d..e3be1e3 100644
--- a/drivers/video/wm8505fb.c
+++ b/drivers/video/wm8505fb.c
@@ -358,7 +358,7 @@ static int wm8505fb_probe(struct platform_device *pdev)
 	fbi->fb.screen_base		= fb_mem_virt;
 	fbi->fb.screen_size		= fb_mem_len;
 
-	fbi->contrast = 0x80;
+	fbi->contrast = 0x10;
 	ret = wm8505fb_set_par(&fbi->fb);
 	if (ret) {
 		dev_err(&pdev->dev, "Failed to set parameters\n");
-- 
1.7.9.5



From linux at prisktech.co.nz  Tue Apr  2 14:20:38 2013
From: linux at prisktech.co.nz (Tony Prisk)
Date: Wed,  3 Apr 2013 07:20:38 +1300
Subject: [PATCHv3 6/6] video: fb: vt8500: Convert framebuffer drivers to
 standardized binding
In-Reply-To: <1364926838-6721-1-git-send-email-linux@prisktech.co.nz>
References: <1364926838-6721-1-git-send-email-linux@prisktech.co.nz>
Message-ID: <1364926838-6721-7-git-send-email-linux@prisktech.co.nz>

Now that a display timing binding is available, convert our almost identical
binding to use the standard binding.

This patch converts the vt8500 and wm8505 framebuffer drivers and
associated dts/dtsi files to use the standard binding as defined in
bindings/video/display-timing.txt.

There are two side-effects of making this conversion:

1) The fb node should now be in the board file, rather than the soc file as
the display-timing node is a child of the fb node.

2) We still require a bits per pixel property to initialize the framebuffer
for the different lcd panels. Rather than including this as part of the
display timing, it is moved into the framebuffer node.

I have also taken the opportunity to alphabetise the includes of each
driver to avoid double-ups.

Signed-off-by: Tony Prisk <linux at prisktech.co.nz>
---
 .../devicetree/bindings/video/via,vt8500-fb.txt    |   48 ++++----------
 .../devicetree/bindings/video/wm,wm8505-fb.txt     |   32 ++++++----
 arch/arm/boot/dts/vt8500-bv07.dts                  |   34 +++++-----
 arch/arm/boot/dts/vt8500.dtsi                      |    4 +-
 arch/arm/boot/dts/wm8505-ref.dts                   |   34 +++++-----
 arch/arm/boot/dts/wm8505.dtsi                      |    4 +-
 arch/arm/boot/dts/wm8650-mid.dts                   |   36 +++++------
 arch/arm/boot/dts/wm8650.dtsi                      |    4 +-
 arch/arm/boot/dts/wm8850-w70v2.dts                 |   40 ++++++------
 arch/arm/boot/dts/wm8850.dtsi                      |    4 +-
 drivers/video/Kconfig                              |    6 ++
 drivers/video/vt8500lcdfb.c                        |   53 ++++++----------
 drivers/video/wm8505fb.c                           |   67 ++++++++------------
 13 files changed, 154 insertions(+), 212 deletions(-)

diff --git a/Documentation/devicetree/bindings/video/via,vt8500-fb.txt b/Documentation/devicetree/bindings/video/via,vt8500-fb.txt
index c870b64..2871e21 100644
--- a/Documentation/devicetree/bindings/video/via,vt8500-fb.txt
+++ b/Documentation/devicetree/bindings/video/via,vt8500-fb.txt
@@ -5,58 +5,32 @@ Required properties:
 - compatible : "via,vt8500-fb"
 - reg : Should contain 1 register ranges(address and length)
 - interrupts : framebuffer controller interrupt
-- display: a phandle pointing to the display node
+- bits-per-pixel : bit depth of framebuffer (16 or 32)
 
-Required nodes:
-- display: a display node is required to initialize the lcd panel
-	This should be in the board dts.
-- default-mode: a videomode within the display with timing parameters
-	as specified below.
+Required subnodes:
+- display-timings: see display-timing.txt for information
 
 Example:
 
-	fb at d800e400 {
+	fb at d8050800 {
 		compatible = "via,vt8500-fb";
 		reg = <0xd800e400 0x400>;
 		interrupts = <12>;
-		display = <&display>;
-		default-mode = <&mode0>;
-	};
-
-VIA VT8500 Display
------------------------------------------------------
-Required properties (as per of_videomode_helper):
-
- - hactive, vactive: Display resolution
- - hfront-porch, hback-porch, hsync-len: Horizontal Display timing parameters
-   in pixels
-   vfront-porch, vback-porch, vsync-len: Vertical display timing parameters in
-   lines
- - clock: displayclock in Hz
- - bpp: lcd panel bit-depth.
-	<16> for RGB565, <32> for RGB888
-
-Optional properties (as per of_videomode_helper):
- - width-mm, height-mm: Display dimensions in mm
- - hsync-active-high (bool): Hsync pulse is active high
- - vsync-active-high (bool): Vsync pulse is active high
- - interlaced (bool): This is an interlaced mode
- - doublescan (bool): This is a doublescan mode
+		bits-per-pixel = <16>;
 
-Example:
-	display: display at 0 {
-		modes {
-			mode0: mode at 0 {
+		display-timings {
+			native-mode = <&timing0>;
+			timing0: 800x480 {
+				clock-frequency = <0>; /* unused but required */
 				hactive = <800>;
 				vactive = <480>;
-				hback-porch = <88>;
 				hfront-porch = <40>;
+				hback-porch = <88>;
 				hsync-len = <0>;
 				vback-porch = <32>;
 				vfront-porch = <11>;
 				vsync-len = <1>;
-				clock = <0>;	/* unused but required */
-				bpp = <16>;	/* non-standard but required */
 			};
 		};
 	};
+
diff --git a/Documentation/devicetree/bindings/video/wm,wm8505-fb.txt b/Documentation/devicetree/bindings/video/wm,wm8505-fb.txt
index 3d325e1..0bcadb2 100644
--- a/Documentation/devicetree/bindings/video/wm,wm8505-fb.txt
+++ b/Documentation/devicetree/bindings/video/wm,wm8505-fb.txt
@@ -4,20 +4,30 @@ Wondermedia WM8505 Framebuffer
 Required properties:
 - compatible : "wm,wm8505-fb"
 - reg : Should contain 1 register ranges(address and length)
-- via,display: a phandle pointing to the display node
+- bits-per-pixel : bit depth of framebuffer (16 or 32)
 
-Required nodes:
-- display: a display node is required to initialize the lcd panel
-	This should be in the board dts. See definition in
-	Documentation/devicetree/bindings/video/via,vt8500-fb.txt
-- default-mode: a videomode node as specified in
-	Documentation/devicetree/bindings/video/via,vt8500-fb.txt
+Required subnodes:
+- display-timings: see display-timing.txt for information
 
 Example:
 
-	fb at d8050800 {
+	fb at d8051700 {
 		compatible = "wm,wm8505-fb";
-		reg = <0xd8050800 0x200>;
-		display = <&display>;
-		default-mode = <&mode0>;
+		reg = <0xd8051700 0x200>;
+		bits-per-pixel = <16>;
+
+		display-timings {
+			native-mode = <&timing0>;
+			timing0: 800x480 {
+				clock-frequency = <0>; /* unused but required */
+				hactive = <800>;
+				vactive = <480>;
+				hfront-porch = <40>;
+				hback-porch = <88>;
+				hsync-len = <0>;
+				vback-porch = <32>;
+				vfront-porch = <11>;
+				vsync-len = <1>;
+			};
+		};
 	};
diff --git a/arch/arm/boot/dts/vt8500-bv07.dts b/arch/arm/boot/dts/vt8500-bv07.dts
index 567cf4e..877b33a 100644
--- a/arch/arm/boot/dts/vt8500-bv07.dts
+++ b/arch/arm/boot/dts/vt8500-bv07.dts
@@ -11,26 +11,22 @@
 
 / {
 	model = "Benign BV07 Netbook";
+};
 
-	/*
-	 * Display node is based on Sascha Hauer's patch on dri-devel.
-	 * Added a bpp property to calculate the size of the framebuffer
-	 * until the binding is formalized.
-	 */
-	display: display at 0 {
-		modes {
-			mode0: mode at 0 {
-				hactive = <800>;
-				vactive = <480>;
-				hback-porch = <88>;
-				hfront-porch = <40>;
-				hsync-len = <0>;
-				vback-porch = <32>;
-				vfront-porch = <11>;
-				vsync-len = <1>;
-				clock = <0>;	/* unused but required */
-				bpp = <16>;	/* non-standard but required */
-			};
+&fb {
+	bits-per-pixel = <16>;
+	display-timings {
+		native-mode = <&timing0>;
+		timing0: 800x480 {
+			clock-frequency = <0>; /* unused but required */
+			hactive = <800>;
+			vactive = <480>;
+			hfront-porch = <40>;
+			hback-porch = <88>;
+			hsync-len = <0>;
+			vback-porch = <32>;
+			vfront-porch = <11>;
+			vsync-len = <1>;
 		};
 	};
 };
diff --git a/arch/arm/boot/dts/vt8500.dtsi b/arch/arm/boot/dts/vt8500.dtsi
index cf31ced..68c8dc6 100644
--- a/arch/arm/boot/dts/vt8500.dtsi
+++ b/arch/arm/boot/dts/vt8500.dtsi
@@ -98,12 +98,10 @@
 			interrupts = <43>;
 		};
 
-		fb at d800e400 {
+		fb: fb at d8050800 {
 			compatible = "via,vt8500-fb";
 			reg = <0xd800e400 0x400>;
 			interrupts = <12>;
-			display = <&display>;
-			default-mode = <&mode0>;
 		};
 
 		ge_rops at d8050400 {
diff --git a/arch/arm/boot/dts/wm8505-ref.dts b/arch/arm/boot/dts/wm8505-ref.dts
index fd4e248..edd2cec 100644
--- a/arch/arm/boot/dts/wm8505-ref.dts
+++ b/arch/arm/boot/dts/wm8505-ref.dts
@@ -11,26 +11,22 @@
 
 / {
 	model = "Wondermedia WM8505 Netbook";
+};
 
-	/*
-	 * Display node is based on Sascha Hauer's patch on dri-devel.
-	 * Added a bpp property to calculate the size of the framebuffer
-	 * until the binding is formalized.
-	 */
-	display: display at 0 {
-		modes {
-			mode0: mode at 0 {
-				hactive = <800>;
-				vactive = <480>;
-				hback-porch = <88>;
-				hfront-porch = <40>;
-				hsync-len = <0>;
-				vback-porch = <32>;
-				vfront-porch = <11>;
-				vsync-len = <1>;
-				clock = <0>;	/* unused but required */
-				bpp = <32>;	/* non-standard but required */
-			};
+&fb {
+	bits-per-pixel = <32>;
+	display-timings {
+		native-mode = <&timing0>;
+		timing0: 800x480 {
+			clock-frequency = <0>; /* unused but required */
+			hactive = <800>;
+			vactive = <480>;
+			hfront-porch = <40>;
+			hback-porch = <88>;
+			hsync-len = <0>;
+			vback-porch = <32>;
+			vfront-porch = <11>;
+			vsync-len = <1>;
 		};
 	};
 };
diff --git a/arch/arm/boot/dts/wm8505.dtsi b/arch/arm/boot/dts/wm8505.dtsi
index e74a1c0..bcf668d 100644
--- a/arch/arm/boot/dts/wm8505.dtsi
+++ b/arch/arm/boot/dts/wm8505.dtsi
@@ -128,11 +128,9 @@
 			interrupts = <0>;
 		};
 
-		fb at d8050800 {
+		fb: fb at d8050800 {
 			compatible = "wm,wm8505-fb";
 			reg = <0xd8050800 0x200>;
-			display = <&display>;
-			default-mode = <&mode0>;
 		};
 
 		ge_rops at d8050400 {
diff --git a/arch/arm/boot/dts/wm8650-mid.dts b/arch/arm/boot/dts/wm8650-mid.dts
index cefd938..61671a0 100644
--- a/arch/arm/boot/dts/wm8650-mid.dts
+++ b/arch/arm/boot/dts/wm8650-mid.dts
@@ -11,26 +11,24 @@
 
 / {
 	model = "Wondermedia WM8650-MID Tablet";
+};
+
+&fb {
+	bits-per-pixel = <16>;
 
-	/*
-	 * Display node is based on Sascha Hauer's patch on dri-devel.
-	 * Added a bpp property to calculate the size of the framebuffer
-	 * until the binding is formalized.
-	 */
-	display: display at 0 {
-		modes {
-			mode0: mode at 0 {
-				hactive = <800>;
-				vactive = <480>;
-				hback-porch = <88>;
-				hfront-porch = <40>;
-				hsync-len = <0>;
-				vback-porch = <32>;
-				vfront-porch = <11>;
-				vsync-len = <1>;
-				clock = <0>;	/* unused but required */
-				bpp = <16>;	/* non-standard but required */
-			};
+	display-timings {
+		native-mode = <&timing0>;
+		timing0: 800x480 {
+			clock-frequency = <0>; /* unused but required */
+			hactive = <800>;
+			vactive = <480>;
+			hfront-porch = <40>;
+			hback-porch = <88>;
+			hsync-len = <0>;
+			vback-porch = <32>;
+			vfront-porch = <11>;
+			vsync-len = <1>;
 		};
 	};
 };
+
diff --git a/arch/arm/boot/dts/wm8650.dtsi b/arch/arm/boot/dts/wm8650.dtsi
index db3c0a1..9313407 100644
--- a/arch/arm/boot/dts/wm8650.dtsi
+++ b/arch/arm/boot/dts/wm8650.dtsi
@@ -128,11 +128,9 @@
 			interrupts = <43>;
 		};
 
-		fb at d8050800 {
+		fb: fb at d8050800 {
 			compatible = "wm,wm8505-fb";
 			reg = <0xd8050800 0x200>;
-			display = <&display>;
-			default-mode = <&mode0>;
 		};
 
 		ge_rops at d8050400 {
diff --git a/arch/arm/boot/dts/wm8850-w70v2.dts b/arch/arm/boot/dts/wm8850-w70v2.dts
index fcc660c..32d2253 100644
--- a/arch/arm/boot/dts/wm8850-w70v2.dts
+++ b/arch/arm/boot/dts/wm8850-w70v2.dts
@@ -15,28 +15,6 @@
 / {
 	model = "Wondermedia WM8850-W70v2 Tablet";
 
-	/*
-	 * Display node is based on Sascha Hauer's patch on dri-devel.
-	 * Added a bpp property to calculate the size of the framebuffer
-	 * until the binding is formalized.
-	 */
-	display: display at 0 {
-		modes {
-			mode0: mode at 0 {
-				hactive = <800>;
-				vactive = <480>;
-				hback-porch = <88>;
-				hfront-porch = <40>;
-				hsync-len = <0>;
-				vback-porch = <32>;
-				vfront-porch = <11>;
-				vsync-len = <1>;
-				clock = <0>;	/* unused but required */
-				bpp = <16>;	/* non-standard but required */
-			};
-		};
-	};
-
 	backlight {
 		compatible = "pwm-backlight";
 		pwms = <&pwm 0 50000 1>;	/* duty inverted */
@@ -45,3 +23,21 @@
 		default-brightness-level = <5>;
 	};
 };
+
+&fb {
+	bits-per-pixel = <16>;
+	display-timings {
+		native-mode = <&timing0>;
+		timing0: 800x480 {
+			clock-frequency = <0>; /* unused but required */
+			hactive = <800>;
+			vactive = <480>;
+			hfront-porch = <40>;
+			hback-porch = <88>;
+			hsync-len = <0>;
+			vback-porch = <32>;
+			vfront-porch = <11>;
+			vsync-len = <1>;
+		};
+	};
+};
diff --git a/arch/arm/boot/dts/wm8850.dtsi b/arch/arm/boot/dts/wm8850.dtsi
index e8cbfdc..7149cd1 100644
--- a/arch/arm/boot/dts/wm8850.dtsi
+++ b/arch/arm/boot/dts/wm8850.dtsi
@@ -135,11 +135,9 @@
 			};
 		};
 
-		fb at d8051700 {
+		fb: fb at d8051700 {
 			compatible = "wm,wm8505-fb";
 			reg = <0xd8051700 0x200>;
-			display = <&display>;
-			default-mode = <&mode0>;
 		};
 
 		ge_rops at d8050400 {
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index ad762ed..d0c932a 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -1794,6 +1794,9 @@ config FB_VT8500
 	select FB_SYS_FILLRECT if (!FB_WMT_GE_ROPS)
 	select FB_SYS_COPYAREA if (!FB_WMT_GE_ROPS)
 	select FB_SYS_IMAGEBLIT
+	select FB_MODE_HELPERS
+	select OF_DISPLAY_TIMING
+	select OF_VIDEOMODE
 	help
 	  This is the framebuffer driver for VIA VT8500 integrated LCD
 	  controller.
@@ -1804,6 +1807,9 @@ config FB_WM8505
 	select FB_SYS_FILLRECT if (!FB_WMT_GE_ROPS)
 	select FB_SYS_COPYAREA if (!FB_WMT_GE_ROPS)
 	select FB_SYS_IMAGEBLIT
+	select FB_MODE_HELPERS
+	select OF_DISPLAY_TIMING
+	select OF_VIDEOMODE
 	help
 	  This is the framebuffer driver for WonderMedia WM8xxx-series
 	  integrated LCD controller. This driver covers the WM8505, WM8650
diff --git a/drivers/video/vt8500lcdfb.c b/drivers/video/vt8500lcdfb.c
index 2ff2312..9547e18 100644
--- a/drivers/video/vt8500lcdfb.c
+++ b/drivers/video/vt8500lcdfb.c
@@ -15,20 +15,21 @@
  * GNU General Public License for more details.
  */
 
-#include <linux/module.h>
-#include <linux/kernel.h>
-#include <linux/errno.h>
-#include <linux/string.h>
-#include <linux/mm.h>
-#include <linux/slab.h>
 #include <linux/delay.h>
+#include <linux/dma-mapping.h>
+#include <linux/errno.h>
 #include <linux/fb.h>
 #include <linux/init.h>
 #include <linux/interrupt.h>
 #include <linux/io.h>
-#include <linux/dma-mapping.h>
+#include <linux/kernel.h>
+#include <linux/mm.h>
+#include <linux/module.h>
 #include <linux/platform_device.h>
+#include <linux/slab.h>
+#include <linux/string.h>
 #include <linux/wait.h>
+#include <video/of_display_timing.h>
 
 #include "vt8500lcdfb.h"
 #include "wmt_ge_rops.h"
@@ -275,11 +276,11 @@ static int vt8500lcd_probe(struct platform_device *pdev)
 {
 	struct vt8500lcd_info *fbi;
 	struct resource *res;
+	struct display_timings *disp_timing;
 	void *addr;
 	int irq, ret;
 
 	struct fb_videomode	of_mode;
-	struct device_node	*np;
 	u32			bpp;
 	dma_addr_t fb_mem_phys;
 	unsigned long fb_mem_len;
@@ -344,32 +345,18 @@ static int vt8500lcd_probe(struct platform_device *pdev)
 		goto failed_free_res;
 	}
 
-	np = of_parse_phandle(pdev->dev.of_node, "default-mode", 0);
-	if (!np) {
-		pr_err("%s: No display description in Device Tree\n", __func__);
-		ret = -EINVAL;
-		goto failed_free_res;
-	}
+	disp_timing = of_get_display_timings(pdev->dev.of_node);
+	if (!disp_timing)
+		return -EINVAL;
 
-	/*
-	 * This code is copied from Sascha Hauer's of_videomode helper
-	 * and can be replaced with a call to the helper once mainlined
-	 */
-	ret = 0;
-	ret |= of_property_read_u32(np, "hactive", &of_mode.xres);
-	ret |= of_property_read_u32(np, "vactive", &of_mode.yres);
-	ret |= of_property_read_u32(np, "hback-porch", &of_mode.left_margin);
-	ret |= of_property_read_u32(np, "hfront-porch", &of_mode.right_margin);
-	ret |= of_property_read_u32(np, "hsync-len", &of_mode.hsync_len);
-	ret |= of_property_read_u32(np, "vback-porch", &of_mode.upper_margin);
-	ret |= of_property_read_u32(np, "vfront-porch", &of_mode.lower_margin);
-	ret |= of_property_read_u32(np, "vsync-len", &of_mode.vsync_len);
-	ret |= of_property_read_u32(np, "bpp", &bpp);
-	if (ret) {
-		pr_err("%s: Unable to read display properties\n", __func__);
-		goto failed_free_res;
-	}
-	of_mode.vmode = FB_VMODE_NONINTERLACED;
+	ret = of_get_fb_videomode(pdev->dev.of_node, &of_mode,
+							OF_USE_NATIVE_MODE);
+	if (ret)
+		return ret;
+
+	ret = of_property_read_u32(pdev->dev.of_node, "bits-per-pixel", &bpp);
+	if (ret)
+		return ret;
 
 	/* try allocating the framebuffer */
 	fb_mem_len = of_mode.xres * of_mode.yres * 2 * (bpp / 8);
diff --git a/drivers/video/wm8505fb.c b/drivers/video/wm8505fb.c
index e3be1e3..19e2e7f 100644
--- a/drivers/video/wm8505fb.c
+++ b/drivers/video/wm8505fb.c
@@ -14,23 +14,24 @@
  * GNU General Public License for more details.
  */
 
-#include <linux/module.h>
-#include <linux/kernel.h>
-#include <linux/errno.h>
-#include <linux/string.h>
-#include <linux/mm.h>
-#include <linux/slab.h>
 #include <linux/delay.h>
+#include <linux/dma-mapping.h>
 #include <linux/fb.h>
+#include <linux/errno.h>
 #include <linux/init.h>
 #include <linux/interrupt.h>
 #include <linux/io.h>
-#include <linux/dma-mapping.h>
-#include <linux/platform_device.h>
-#include <linux/wait.h>
+#include <linux/kernel.h>
+#include <linux/memblock.h>
+#include <linux/mm.h>
+#include <linux/module.h>
 #include <linux/of.h>
 #include <linux/of_fdt.h>
-#include <linux/memblock.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+#include <linux/string.h>
+#include <linux/wait.h>
+#include <video/of_display_timing.h>
 
 #include "wm8505fb_regs.h"
 #include "wmt_ge_rops.h"
@@ -261,12 +262,12 @@ static struct fb_ops wm8505fb_ops = {
 static int wm8505fb_probe(struct platform_device *pdev)
 {
 	struct wm8505fb_info	*fbi;
-	struct resource		*res;
+	struct resource	*res;
+	struct display_timings *disp_timing;
 	void			*addr;
 	int ret;
 
-	struct fb_videomode	of_mode;
-	struct device_node	*np;
+	struct fb_videomode	mode;
 	u32			bpp;
 	dma_addr_t fb_mem_phys;
 	unsigned long fb_mem_len;
@@ -306,33 +307,19 @@ static int wm8505fb_probe(struct platform_device *pdev)
 	if (fbi->regbase == NULL)
 		return -EBUSY;
 
-	np = of_parse_phandle(pdev->dev.of_node, "default-mode", 0);
-	if (!np) {
-		pr_err("%s: No display description in Device Tree\n", __func__);
+	disp_timing = of_get_display_timings(pdev->dev.of_node);
+	if (!disp_timing)
 		return -EINVAL;
-	}
 
-	/*
-	 * This code is copied from Sascha Hauer's of_videomode helper
-	 * and can be replaced with a call to the helper once mainlined
-	 */
-	ret = 0;
-	ret |= of_property_read_u32(np, "hactive", &of_mode.xres);
-	ret |= of_property_read_u32(np, "vactive", &of_mode.yres);
-	ret |= of_property_read_u32(np, "hback-porch", &of_mode.left_margin);
-	ret |= of_property_read_u32(np, "hfront-porch", &of_mode.right_margin);
-	ret |= of_property_read_u32(np, "hsync-len", &of_mode.hsync_len);
-	ret |= of_property_read_u32(np, "vback-porch", &of_mode.upper_margin);
-	ret |= of_property_read_u32(np, "vfront-porch", &of_mode.lower_margin);
-	ret |= of_property_read_u32(np, "vsync-len", &of_mode.vsync_len);
-	ret |= of_property_read_u32(np, "bpp", &bpp);
-	if (ret) {
-		pr_err("%s: Unable to read display properties\n", __func__);
-		return -EINVAL;
-	}
+	ret = of_get_fb_videomode(pdev->dev.of_node, &mode, OF_USE_NATIVE_MODE);
+	if (ret)
+		return ret;
+
+	ret = of_property_read_u32(pdev->dev.of_node, "bits-per-pixel", &bpp);
+	if (ret)
+		return ret;
 
-	of_mode.vmode = FB_VMODE_NONINTERLACED;
-	fb_videomode_to_var(&fbi->fb.var, &of_mode);
+	fb_videomode_to_var(&fbi->fb.var, &mode);
 
 	fbi->fb.var.nonstd		= 0;
 	fbi->fb.var.activate		= FB_ACTIVATE_NOW;
@@ -341,7 +328,7 @@ static int wm8505fb_probe(struct platform_device *pdev)
 	fbi->fb.var.width		= -1;
 
 	/* try allocating the framebuffer */
-	fb_mem_len = of_mode.xres * of_mode.yres * 2 * (bpp / 8);
+	fb_mem_len = mode.xres * mode.yres * 2 * (bpp / 8);
 	fb_mem_virt = dmam_alloc_coherent(&pdev->dev, fb_mem_len, &fb_mem_phys,
 				GFP_KERNEL);
 	if (!fb_mem_virt) {
@@ -349,8 +336,8 @@ static int wm8505fb_probe(struct platform_device *pdev)
 		return -ENOMEM;
 	}
 
-	fbi->fb.var.xres_virtual	= of_mode.xres;
-	fbi->fb.var.yres_virtual	= of_mode.yres * 2;
+	fbi->fb.var.xres_virtual	= mode.xres;
+	fbi->fb.var.yres_virtual	= mode.yres * 2;
 	fbi->fb.var.bits_per_pixel	= bpp;
 
 	fbi->fb.fix.smem_start		= fb_mem_phys;
-- 
1.7.9.5



From jic23 at kernel.org  Tue Apr  2 14:22:06 2013
From: jic23 at kernel.org (Jonathan Cameron)
Date: Tue, 02 Apr 2013 19:22:06 +0100
Subject: [PATCH 2/3] iio: at91_adc: add sleep mode support
In-Reply-To: <1364568853-18561-3-git-send-email-ludovic.desroches@atmel.com>
References: <1364568853-18561-1-git-send-email-ludovic.desroches@atmel.com>
 <1364568853-18561-3-git-send-email-ludovic.desroches@atmel.com>
Message-ID: <515B21CE.50501@kernel.org>

On 03/29/2013 02:54 PM, ludovic.desroches at atmel.com wrote:
> From: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
> 
> The sleep mode will allow to put the adc in sleep between conversion.
> 
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
I tied this next comment out.  Nice as is it is to make it clear
what contributions are, this looks pretty non standard in a block
that has a very specific purpose.

> [ludovic.desroches at atmel.com: correct typo]
> Signed-off-by: Ludovic Desroches <ludovic.desroches at atmel.com>
> Acked-by: Maxime Ripard <maxime.ripard at free-electrons.com>
Applied to togreg branch of iio.git
> ---
>  Documentation/devicetree/bindings/arm/atmel-adc.txt |  1 +
>  drivers/iio/adc/at91_adc.c                          | 19 ++++++++++---------
>  2 files changed, 11 insertions(+), 9 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/arm/atmel-adc.txt b/Documentation/devicetree/bindings/arm/atmel-adc.txt
> index fd2d69e..3a05492 100644
> --- a/Documentation/devicetree/bindings/arm/atmel-adc.txt
> +++ b/Documentation/devicetree/bindings/arm/atmel-adc.txt
> @@ -25,6 +25,7 @@ Optional properties:
>    - atmel,adc-use-res: String corresponding to an identifier from
>  		       atmel,adc-res-names property. If not specified, the highest
>  		       resolution will be used.
> +  - atmel,adc-sleep-mode: Boolean to enable sleep mode when no conversion
>   
>  Optional trigger Nodes:
>    - Required properties:
> diff --git a/drivers/iio/adc/at91_adc.c b/drivers/iio/adc/at91_adc.c
> index a7ad3e7..8e38f1c 100644
> --- a/drivers/iio/adc/at91_adc.c
> +++ b/drivers/iio/adc/at91_adc.c
> @@ -52,6 +52,7 @@ struct at91_adc_state {
>  	void __iomem		*reg_base;
>  	struct at91_adc_reg_desc *registers;
>  	u8			startup_time;
> +	bool			sleep_mode;
>  	struct iio_trigger	**trig;
>  	struct at91_adc_trigger	*trigger_list;
>  	u32			trigger_number;
> @@ -455,6 +456,8 @@ static int at91_adc_probe_dt(struct at91_adc_state *st,
>  	}
>  	st->num_channels = prop;
>  
> +	st->sleep_mode = of_property_read_bool(node, "atmel,adc-sleep-mode");
> +
>  	if (of_property_read_u32(node, "atmel,adc-startup-time", &prop)) {
>  		dev_err(&idev->dev, "Missing adc-startup-time property in the DT.\n");
>  		ret = -EINVAL;
> @@ -580,6 +583,7 @@ static int at91_adc_probe(struct platform_device *pdev)
>  	struct iio_dev *idev;
>  	struct at91_adc_state *st;
>  	struct resource *res;
> +	u32 reg;
>  
>  	idev = iio_device_alloc(sizeof(struct at91_adc_state));
>  	if (idev == NULL) {
> @@ -687,16 +691,13 @@ static int at91_adc_probe(struct platform_device *pdev)
>  	 */
>  	ticks = round_up((st->startup_time * adc_clk /
>  			  1000000) - 1, 8) / 8;
> -
> +	reg = AT91_ADC_PRESCAL_(prsc) & AT91_ADC_PRESCAL;
> +	reg |= AT91_ADC_STARTUP_(ticks) & AT91_ADC_STARTUP;
>  	if (st->low_res)
> -		at91_adc_writel(st, AT91_ADC_MR,
> -				AT91_ADC_LOWRES |
> -				(AT91_ADC_PRESCAL_(prsc) & AT91_ADC_PRESCAL) |
> -				(AT91_ADC_STARTUP_(ticks) & AT91_ADC_STARTUP));
> -	else
> -		at91_adc_writel(st, AT91_ADC_MR,
> -				(AT91_ADC_PRESCAL_(prsc) & AT91_ADC_PRESCAL) |
> -				(AT91_ADC_STARTUP_(ticks) & AT91_ADC_STARTUP));
> +		reg |= AT91_ADC_LOWRES;
> +	if (st->sleep_mode)
> +		reg |= AT91_ADC_SLEEP;
> +	at91_adc_writel(st, AT91_ADC_MR, reg);
>  
>  	/* Setup the ADC channels available on the board */
>  	ret = at91_adc_channel_init(idev);
> 


From olof at lixom.net  Tue Apr  2 14:23:44 2013
From: olof at lixom.net (Olof Johansson)
Date: Tue, 2 Apr 2013 11:23:44 -0700
Subject: [PATCH 1/2] ARM: irq: Call irqchit_init if no init_irq function
 is specified
In-Reply-To: <1364503606-10597-2-git-send-email-maxime.ripard@free-electrons.com>
References: <1364503606-10597-1-git-send-email-maxime.ripard@free-electrons.com>
 <1364503606-10597-2-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <20130402182344.GK25867@quad.lixom.net>

On Thu, Mar 28, 2013 at 09:46:44PM +0100, Maxime Ripard wrote:
> More and more sub-architectures are using only the irqchip_init
> function. Make the core code call this function if no init_irq field is
> provided in the machine description to remove some boilerplate code.
> 
> Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>

Applied to next/cleanup (fixed the typo in the subject though :).

I'm trying to figure out how to best apply 2/2 without causing a lot of
merge conflicts. It might make sense to either do it late in the merge
window or stage it at the base of 3.11 cleanup. I'll revisit after I've
dealt with the rest of the pull request queue.


-Olof


From paul at pwsan.com  Tue Apr  2 14:24:25 2013
From: paul at pwsan.com (Paul Walmsley)
Date: Tue, 2 Apr 2013 18:24:25 +0000 (UTC)
Subject: [PATCH] Revert "OMAP/serial: Fix incorrect Rx FIFO threshold
 setting, LSR validation on Tx, and Tx FIFO IRQ generation"
In-Reply-To: <CAOmKuSo4onVtk2Ke-i+0_1Ych33KuUYspRy+cySRHf4yWB5XDw@mail.gmail.com>
References: <alpine.DEB.2.00.1304010519260.28273@utopia.booyaka.com>
 <CAOmKuSpttQJmrL=Htiz-Zc4voAF7CnG_GQYAO2onKpauwYjtvw@mail.gmail.com>
 <alpine.DEB.2.00.1304010844100.28273@utopia.booyaka.com>
 <CAOmKuSrABrPcZ=Yg1+LAHWbh9CdTYR0eUmJ2dd3z91oz0uu21g@mail.gmail.com>
 <alpine.DEB.2.00.1304011008230.28273@utopia.booyaka.com>
 <CAOmKuSrbDc025Tj9xsqDebJ_KZdp_VnWAOs_OO5UAegV43JcDQ@mail.gmail.com>
 <CAOmKuSpbaKutLxbNihBRDz+B0Wt0XiPss-PcEHc-efCTvciNFg@mail.gmail.com>
 <alpine.DEB.2.00.1304011654520.9148@utopia.booyaka.com>
 <CAOmKuSo4onVtk2Ke-i+0_1Ych33KuUYspRy+cySRHf4yWB5XDw@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1304021821190.27146@utopia.booyaka.com>

On Mon, 1 Apr 2013, Alexey Pelykh wrote:

> Paul, can you please try to comment out change related to Rx line
> (granulation one). That's only Rx line related change in the patch.

Yes, looks like simply reverting the commit 1776fd059c40 ("OMAP/serial: 
Fix incorrect Rx FIFO threshold setting, LSR validation on Tx, and Tx FIFO 
IRQ generation") change to OMAP_UART_SCR_RX_TRIG_GRANU1_MASK fixes it.

Care to send a patch doing so ASAP for v3.9-rc fixes?  That would moot the 
revert of the entire commit 1776fd059c40.


- Paul


From jic23 at kernel.org  Tue Apr  2 14:24:32 2013
From: jic23 at kernel.org (Jonathan Cameron)
Date: Tue, 02 Apr 2013 19:24:32 +0100
Subject: [PATCH 3/3] iio: at91_adc: fix missing Sample and Hold time
In-Reply-To: <1364568853-18561-4-git-send-email-ludovic.desroches@atmel.com>
References: <1364568853-18561-1-git-send-email-ludovic.desroches@atmel.com>
 <1364568853-18561-4-git-send-email-ludovic.desroches@atmel.com>
Message-ID: <515B2260.1010900@kernel.org>

On 03/29/2013 02:54 PM, ludovic.desroches at atmel.com wrote:
> From: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
> 
> On the at91_adc a minimal Sample and Hold Time is necessary for the ADC to
> guarantee the best converted final value between two channels selection.
> This time has to be programmed through the bitfield SHTIM in the
> Mode Register ADC_MR.
> 
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
Again tidied this out of the patch description.  You handled it and
posted this revision so to my mind the sign off covers all we need
to know.

> [ludovic.desroches at atmel.com: add unit for sample and hold time]
> Signed-off-by: Ludovic Desroches <ludovic.desroches at atmel.com>
Applied to togreg branch of iio.git

> ---
>  Documentation/devicetree/bindings/arm/atmel-adc.txt |  1 +
>  drivers/iio/adc/at91_adc.c                          | 15 ++++++++++++++-
>  2 files changed, 15 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/arm/atmel-adc.txt b/Documentation/devicetree/bindings/arm/atmel-adc.txt
> index 3a05492..16769d9 100644
> --- a/Documentation/devicetree/bindings/arm/atmel-adc.txt
> +++ b/Documentation/devicetree/bindings/arm/atmel-adc.txt
> @@ -26,6 +26,7 @@ Optional properties:
>  		       atmel,adc-res-names property. If not specified, the highest
>  		       resolution will be used.
>    - atmel,adc-sleep-mode: Boolean to enable sleep mode when no conversion
> +  - atmel,adc-sample-hold-time: Sample and Hold Time in microseconds
>   
>  Optional trigger Nodes:
>    - Required properties:
> diff --git a/drivers/iio/adc/at91_adc.c b/drivers/iio/adc/at91_adc.c
> index 8e38f1c..69fe8d4 100644
> --- a/drivers/iio/adc/at91_adc.c
> +++ b/drivers/iio/adc/at91_adc.c
> @@ -52,6 +52,7 @@ struct at91_adc_state {
>  	void __iomem		*reg_base;
>  	struct at91_adc_reg_desc *registers;
>  	u8			startup_time;
> +	u8			sample_hold_time;
>  	bool			sleep_mode;
>  	struct iio_trigger	**trig;
>  	struct at91_adc_trigger	*trigger_list;
> @@ -465,6 +466,9 @@ static int at91_adc_probe_dt(struct at91_adc_state *st,
>  	}
>  	st->startup_time = prop;
>  
> +	prop = 0;
> +	of_property_read_u32(node, "atmel,adc-sample-hold-time", &prop);
> +	st->sample_hold_time = prop;
>  
>  	if (of_property_read_u32(node, "atmel,adc-vref", &prop)) {
>  		dev_err(&idev->dev, "Missing adc-vref property in the DT.\n");
> @@ -578,7 +582,7 @@ static const struct iio_info at91_adc_info = {
>  
>  static int at91_adc_probe(struct platform_device *pdev)
>  {
> -	unsigned int prsc, mstrclk, ticks, adc_clk;
> +	unsigned int prsc, mstrclk, ticks, adc_clk, shtim;
>  	int ret;
>  	struct iio_dev *idev;
>  	struct at91_adc_state *st;
> @@ -691,12 +695,21 @@ static int at91_adc_probe(struct platform_device *pdev)
>  	 */
>  	ticks = round_up((st->startup_time * adc_clk /
>  			  1000000) - 1, 8) / 8;
> +	/*
> +	 * a minimal Sample and Hold Time is necessary for the ADC to guarantee
> +	 * the best converted final value between two channels selection
> +	 * The formula thus is : Sample and Hold Time = (shtim + 1) / ADCClock
> +	 */
> +	shtim = round_up((st->sample_hold_time * adc_clk /
> +			  1000000) - 1, 1);
> +
>  	reg = AT91_ADC_PRESCAL_(prsc) & AT91_ADC_PRESCAL;
>  	reg |= AT91_ADC_STARTUP_(ticks) & AT91_ADC_STARTUP;
>  	if (st->low_res)
>  		reg |= AT91_ADC_LOWRES;
>  	if (st->sleep_mode)
>  		reg |= AT91_ADC_SLEEP;
> +	reg |= AT91_ADC_SHTIM_(shtim) & AT91_ADC_SHTIM;
>  	at91_adc_writel(st, AT91_ADC_MR, reg);
>  
>  	/* Setup the ADC channels available on the board */
> 


From mturquette at linaro.org  Tue Apr  2 14:25:13 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Tue, 02 Apr 2013 11:25:13 -0700
Subject: [PATCH] clk: add LP8788 clock driver
In-Reply-To: <A874F61F95741C4A9BA573A70FE3998F82E4A7F3@DQHE02.ent.ti.com>
References: <A874F61F95741C4A9BA573A70FE3998F82E48E3F@DQHE02.ent.ti.com>
 <20130402011236.8177.88731@quantum>
 <A874F61F95741C4A9BA573A70FE3998F82E4A7F3@DQHE02.ent.ti.com>
Message-ID: <20130402182513.8177.59192@quantum>

Quoting Kim, Milo (2013-04-01 19:18:32)
> > Just FYI most folks are simply using a macro to do the above.  E.g:
> > 
> > #define to_lp8788_clk(_hw) container_of(_hw, struct lp8788_clk, hw)
> 
> OK, thanks! Will be fixed in the 2nd patch.
> 
> > > +
> > > +static int lp8788_clk_is_enabled(struct clk_hw *hw)
> > > +{
> > > +       struct lp8788_clk *pclk = to_lp8788_clk(hw);
> > > +
> > > +       /*
> > > +        * Do not use the LP8788 register access here, unsafe locking
> > problem
> > > +        * may occur during loading the driver. So stored varible is
> > prefered.
> > > +        */
> > 
> > What unsafe locking problem?
> 
> If I try to get LP8788 clock status via the remap-i2c here, then locking problem
> occurs.
> The 'enable_lock' is already locked and the MUTEX of REGMAP is used on reading
> a register.
> 
> [    2.692443] -------------------------------------------------------
> [    2.699066] swapper/0/1 is trying to acquire lock:
> [    2.704132]  (&map->mutex){+.+...}, at: [<c0374ecc>] regmap_read+0x34/0x5c
> [    2.711486] 
> [    2.711486] but task is already holding lock:
> [    2.717681]  (enable_lock){......}, at: [<c047a6c8>] clk_disable_unused_subtr
> ee+0x3c/0xb4
> [    2.726379] 
> [    2.726379] which lock already depends on the new lock.
> 
> That's why lp8788_get_clk_status() is used on _probe().
> - Read a register and store the value into local status variable.
> Then local variable is used in .is_enabled().
> 

I think that the new clk reentrancy patch should fix this for you.  Can
you rebase your patch onto the latest clk-next and try using remap-i2c
again?  You can that branch here:
git://git.linaro.org/people/mturquette/linux.git clk-next

> > Also have you looked into using the new .is_prepare callback?  See:
> > https://git.linaro.org/gitweb?p=people/mturquette/linux.git;a=commitdif
> > f;h=3d6ee287a3e341c88eafd0b4620b12d640b3736b;hp=30ee400614385ac49f4c9b4
> > bc03d77ff8f07a61e
> 
> Not checked yet, but it looks no caller for this callback at this moment.
> Will this be added inside the clk_prepare()?
> 
> > > +
> > > +       return pclk->enabled;
> > 
> > Why provide a .is_enabled callback when there are no .enable
> > or .disable
> > callbacks?
> 
> LP8788 Clock is always enabled, so it needs to show the clock status.
> However, I think no effect on working the clock operation without is_enabled().
> Can I remove it?
> 

Yes you can remove it.  Since you do not provide a .disabled callback
then clk_disable_unused() will not try to disable your clock.  Do any
drivers call clk_prepare_enable on this clock?

It is also probably a good idea to set the CLK_IGNORE_UNUSED flag on
this clock (in addition to the CLK_IS_ROOT flag that you have already
set).  This way if your .unprepare callback ever does something some day
then you won't get a nasty surprise.

Regards,
Mike

> Thanks,
> Milo


From olof at lixom.net  Tue Apr  2 14:29:41 2013
From: olof at lixom.net (Olof Johansson)
Date: Tue, 2 Apr 2013 11:29:41 -0700
Subject: [GIT PULL] at91: tiny cleanup for 3.10 #2
In-Reply-To: <1364547250-19675-1-git-send-email-nicolas.ferre@atmel.com>
References: <1364547250-19675-1-git-send-email-nicolas.ferre@atmel.com>
Message-ID: <20130402182941.GL25867@quad.lixom.net>

On Fri, Mar 29, 2013 at 09:54:10AM +0100, Nicolas Ferre wrote:
> Arnd, Olof,
> 
> This is a one-line cleanup patch. I have made a pull-request anyway because
> I do not want to mix it with my upcoming DT pull-request. I guess that you can
> simply cherry-pick the patch if you want. It is based on material that you
> already have in arm-soc/at91/cleanup branch.
> 
> Thanks, best regards,
> 
> 
> The following changes since commit 9317960fa38ff50ac287904e4c751a169635ecbf:
> 
>   ARM: at91: renamme rm9200 dt file (2013-03-13 17:28:14 +0100)
> 
> are available in the git repository at:
> 
>   git://github.com/at91linux/linux-at91.git tags/at91-cleanup

Pulled, thanks.


-Olof


From olof at lixom.net  Tue Apr  2 14:31:00 2013
From: olof at lixom.net (Olof Johansson)
Date: Tue, 2 Apr 2013 11:31:00 -0700
Subject: [PATCHv2 00/10] ARM: sunxi: Architecture cleanups and rework
In-Reply-To: <51555CCF.2090005@free-electrons.com>
References: <1364289198-11589-1-git-send-email-maxime.ripard@free-electrons.com>
 <51555CCF.2090005@free-electrons.com>
Message-ID: <20130402183100.GM25867@quad.lixom.net>

On Fri, Mar 29, 2013 at 10:20:15AM +0100, Maxime Ripard wrote:
> Hi Mike,
> 
> Le 26/03/2013 10:13, Maxime Ripard a ?crit :
> > Hi,
> > 
> > This patchset is a serie of various cleanups and reworks in the sunxi
> > architecture to prepare a clean landing for the next Allwinner SoC, the
> > A31 (sun6i).
> > 
> > The A31 is significantly different from the previous Allwinner SoC we
> > supported, the A10 and A13, to no longer make the generic sunxi prefix
> > we used in most compatible string relevant, while it should really have
> > been sun4i in the first place.
> > 
> > This set is also the occasion to cleanup the timer and irq code by
> > switching to the recently introduced clocksource and irqchip
> > infrastructures.
> > 
> > This set depends on the UART patches I sent previously.
> 
> I was meaning to take this branch, but some of the drivers changes in it
> depends on the clock patches that Emilio sent and that are in clk-next.
> Is it ok to merge clk-next into my branch?

All of of a <subsystem>-next branch is usually asking for trouble, since it'll
cause all sorts of pain if the other maintianer is rebasing his for-next
branch.

Best is to get those patches on just a minimal topic branch (that is still
bisectable) that is shared between the trees.

Mike?


-Olof


From olof at lixom.net  Tue Apr  2 14:37:54 2013
From: olof at lixom.net (Olof Johansson)
Date: Tue, 2 Apr 2013 11:37:54 -0700
Subject: How to facilitate the cpuidle drivers to go to the same
 direction (Was: Re: [PATCH 4/9] ARM: OMAP4: cpuidle: fix wrong driver
 initialization)
In-Reply-To: <1364804988.32247.3.camel@pasglop>
References: <1364553095-25110-4-git-send-email-daniel.lezcano@linaro.org>
 <51556F1D.5030208@ti.com> <515570DF.5010608@linaro.org>
 <CAP245DX+mYQhhJ-fU6PQdV6V-1P7PGUaOoNo+QdhRFaQR=wiEQ@mail.gmail.com>
 <51558723.1050904@ti.com>
 <CAP245DWAAgQ4co34mdkFgepC5kP9v0n6B954ej2X_y20LE9kSQ@mail.gmail.com>
 <5155AEE7.106@ti.com> <5155B85F.6030808@linaro.org>
 <515923C7.8040408@linux.vnet.ibm.com>
 <1364804988.32247.3.camel@pasglop>
Message-ID: <20130402183754.GN25867@quad.lixom.net>

On Mon, Apr 01, 2013 at 10:29:48AM +0200, Benjamin Herrenschmidt wrote:
> On Mon, 2013-04-01 at 11:35 +0530, Deepthi Dharwar wrote:
> > But then, this means we get all the
> > arch specific code out under drivers/cpuidle
> > which can be very messy.
> 
> Not really no. We already have that here or there in other drivers,
> it's not necessarily messy and the stuff like that can generally be made
> reasonably self contained.
> 
> The main issue is that if I (powerpc) wants a fix in my
> some_ppc_box_idle.c driver, especially if it needs to sync with other
> arch changes, having to sync/ack with Rafael might complicate things a
> bit (though not necessarily a lot).
> 
> I would probably keep the liberty of sending to Linus directly urgent
> bug/regression fixes to individual cpuidle drivers relating to our archs
> without waiting every now and then if for example Rafael is on
> vacation :-)

Merging them all over sounds like a good idea to me as well.

This isn't too different from how we handle other subsystems; as
architecutre maintainer you just use your judgement on what needs an ack
vs cc. Some smaller details about how the backend of the driver works
on a platform is quite different from refactoring portions of the
framework.


-Olof


From olof at lixom.net  Tue Apr  2 14:48:36 2013
From: olof at lixom.net (Olof Johansson)
Date: Tue, 2 Apr 2013 11:48:36 -0700
Subject: [PATCH v2] ARM: at91: add Acme Systems Aria G25 board
In-Reply-To: <1364297952-32473-1-git-send-email-nicolas.ferre@atmel.com>
References: <1364201369-12047-1-git-send-email-nicolas.ferre@atmel.com>
 <1364297952-32473-1-git-send-email-nicolas.ferre@atmel.com>
Message-ID: <CAOesGMj+etPUMWffx2CiDtbWbB9A5_6QPbkTsmbEqCiBnkhm3A@mail.gmail.com>

Hi,

I just saw this since it came in through a pull request

On Tue, Mar 26, 2013 at 4:39 AM, Nicolas Ferre <nicolas.ferre at atmel.com> wrote:
> From: Douglas Gilbert <dgilbert at interlog.com>
>
> Signed-off-by: Douglas Gilbert <dgilbert at interlog.com>
> Signed-off-by: Nicolas Ferre <nicolas.ferre at atmel.com>
> ---
>  arch/arm/boot/dts/ariag25.dts | 175 ++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 175 insertions(+)
>  create mode 100644 arch/arm/boot/dts/ariag25.dts
>
> diff --git a/arch/arm/boot/dts/ariag25.dts b/arch/arm/boot/dts/ariag25.dts
> new file mode 100644
> index 0000000..b43266f
> --- /dev/null
> +++ b/arch/arm/boot/dts/ariag25.dts

Please prefix the boards with the platform. Most other SoCs already do
this, and I see now that some at91 boards haven't been prefixed in the
past, but it's a good idea to not add more of them.

So, at91-ariag25.dts is a good name in this case.


-Olof


From olof at lixom.net  Tue Apr  2 14:49:47 2013
From: olof at lixom.net (Olof Johansson)
Date: Tue, 2 Apr 2013 11:49:47 -0700
Subject: [GIT PULL] at91: DT changes for 3.10 #2
In-Reply-To: <1364569179-24773-1-git-send-email-nicolas.ferre@atmel.com>
References: <1364569179-24773-1-git-send-email-nicolas.ferre@atmel.com>
Message-ID: <20130402184947.GA8015@quad.lixom.net>

On Fri, Mar 29, 2013 at 03:59:39PM +0100, Nicolas Ferre wrote:
> Arnd, Olof,
> 
> Here is a pull-request for AT91 that is dedicated to Device Tree
> modifications. It is stacked on the material that you already have
> for 3.10 in your arm-soc/at91/dt branch.
> Following our discussion with Arnd, I added the non-urgent patches that I
> already proposed too late for 3.9. I also included the moving of macb node
> and kept the original patch.
> 
> Thanks, best regards,
> 
> The following changes since commit 6901d947be5ba1245a0f63271355b95f9056a362:
> 
>   ARM: at91/at91sam9x5cm: add 1-wire chip on CM board (2013-03-21 16:07:15 +0100)
> 
> are available in the git repository at:
> 
>   git://github.com/at91linux/linux-at91.git tags/at91-dt
> 
> for you to fetch changes up to cc2e191b0ccc5a987fdb29261ab9c264c608924d:
> 
>   ARM: at91/dt: fix macb node declaration (2013-03-29 10:02:04 +0100)
> 
> ----------------------------------------------------------------
> One macb DT node move for 9x5 family: 9g15 doesn't
> have an Ethernet interface.
> Little fixes mainly related to at91sam9x5 DT and the
> RTC addition.
> Addition of the Acme Systems Aria G25 board.
> 
> ----------------------------------------------------------------
> Douglas Gilbert (1):
>       ARM: at91: add Acme Systems Aria G25 board

Hi,

I just replied to the above patch -- please prefix the dts files with the
platform so it's easier to navigate the directory.

Otherwise the branch contents looks good, so send a fresh request when you've
respun.

Also, the new dts isn't added to the Makefile, please add it.


-Olof


From marex at denx.de  Tue Apr  2 15:11:05 2013
From: marex at denx.de (Marek Vasut)
Date: Tue, 2 Apr 2013 21:11:05 +0200
Subject: [PATCH] ARM: mxs: Slow down the I2C clock speed
In-Reply-To: <20130402112850.GD24039@S2101-09.ap.freescale.net>
References: <1364858969-17745-1-git-send-email-marex@denx.de>
 <20130402112850.GD24039@S2101-09.ap.freescale.net>
Message-ID: <201304022111.05858.marex@denx.de>

Dear Shawn Guo,

> Marek,
> 
> On Tue, Apr 02, 2013 at 01:29:29AM +0200, Marek Vasut wrote:
> > Slow down the I2C clock speed on M28 and SPS1 as it turns out the
> > I2C block in i.MX28 can not operate stable enough with the bus
> > running at 400kHz. Note that the driver used by Freescale runs
> > the bus at 250kHz when 400kHz speed is selected, but the mainline
> > Linux kernel runs the bus at actual 400kHz and that's where it is
> > occasionally unstable. Play safe and run the bus at 100kHz.
> > 
> > Signed-off-by: Marek Vasut <marex at denx.de>
> 
> You consider it a fix for 3.9 or just material for 3.10?

Fix for 3.9 please.

Best regards,
Marek Vasut


From swarren at wwwdotorg.org  Tue Apr  2 15:33:25 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Tue, 02 Apr 2013 13:33:25 -0600
Subject: [PATCH V3 1/3] ARM: tegra: get PMC clock source from DT
In-Reply-To: <1364901583-24867-2-git-send-email-josephl@nvidia.com>
References: <1364901583-24867-1-git-send-email-josephl@nvidia.com>
 <1364901583-24867-2-git-send-email-josephl@nvidia.com>
Message-ID: <515B3285.5080400@wwwdotorg.org>

On 04/02/2013 05:19 AM, Joseph Lo wrote:
> Adding the bindings of the clock source of PMC in DT. And getting
> the clock from DT.

>  .../bindings/arm/tegra/nvidia,tegra20-pmc.txt      | 23 ++++++++++++++++++++++
>  arch/arm/mach-tegra/common.c                       |  2 +-
>  arch/arm/mach-tegra/pmc.c                          |  4 ++++

I'd like to re-order and split up this series slightly differently.

Patch (1) should include the binding updates (nvidia,tegra20-pmc.txt)
from this patch 1/3 and the DT changes (*.dts) from patch 2/3.

Patch (2) should contain be the current patch 3/3 plus the *.c changes
from this patch 1/3.

That ensures that:

a) The DT binding changes happen before (or rather at the same time) as
the first other change that relies on them.

b) The DT changes happen before the code changes, which is required to
avoid the code-changes causing WARN_ON(IS_ERR(tegra_pclk)) from firing
before all the patches are applied.

c) The new code to retrieve tegra_pclk isn't added without anything that
uses the new variable; it's added only when something makes use of it.

> diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt

> +- clocks : the source clock of PMC
> +- clock-names : the name of source clock of PMC

"the" is wrong here, since there is more than one clock. Also, the
binding document needs to define the set of clocks that those properties
must provide. I suggest the following wording, which I cribbed from the
Tegra audio bindings:

- clocks : Must contain an entry for each entry in clock-names.
- clock-names : Must include the following entries:
  "pclk" (The Tegra clock of that name),
  "clk32k_in" (The 32KHz clock input to Tegra).

That text should also be added to the "Required properties" section, not
the "Optional proeprties" section.

> +/ SoC dts including file
>  pmc at 7000f400 {
>  	compatible = "nvidia,tegra20-pmc";
>  	reg = <0x7000e400 0x400>;
>  	nvidia,invert-interrupt;
> +	clocks = <&tegra_car 110>, <&clk32k_in>;
> +	clock-names = "pclk", "clk32k_in";

In this example, I'd prefer the clocks properties to be before the
custom nvidia,invert-interrupt property, so that all standard and
required properties are first, then custom properties. so, compatible,
reg, clock*, nvidia,invert-interrupt.

> diff --git a/arch/arm/mach-tegra/common.c b/arch/arm/mach-tegra/common.c

>  void __init tegra_dt_init_irq(void)
>  {
>  	tegra_clocks_init();
> +	tegra_pmc_init();
>  	tegra_init_irq();
>  	irqchip_init();
>  }

I'll let this slide for now. Please be aware that I'd prefer all
non-IRQ-related initialization to happen somewhere inside the machine's
.init_machine() callback, not its .init_irq() callback. However, we can
clean this up later; most likely a lot of the calls in
tegra_init_early() should move too.


From swarren at wwwdotorg.org  Tue Apr  2 15:36:21 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Tue, 02 Apr 2013 13:36:21 -0600
Subject: [PATCH V3 2/3] ARM: dts: tegra: add clock source for PMC
In-Reply-To: <1364901583-24867-3-git-send-email-josephl@nvidia.com>
References: <1364901583-24867-1-git-send-email-josephl@nvidia.com>
 <1364901583-24867-3-git-send-email-josephl@nvidia.com>
Message-ID: <515B3335.30405@wwwdotorg.org>

On 04/02/2013 05:19 AM, Joseph Lo wrote:
> Adding the clock sources of PMC into DTS for Tegra20 and Tegra30.

Why only Tegra20 and Tegra30; don't you need to make the exact same
changes to tegra114-dalmore.dts and tegra114-pluto.dts? (I think the
answer is yes, you do).

> diff --git a/arch/arm/boot/dts/tegra20-colibri-512.dtsi b/arch/arm/boot/dts/tegra20-colibri-512.dtsi
> index cb73e62..4c107e6 100644
> --- a/arch/arm/boot/dts/tegra20-colibri-512.dtsi
> +++ b/arch/arm/boot/dts/tegra20-colibri-512.dtsi
> @@ -8,6 +8,19 @@
>  		reg = <0x00000000 0x20000000>;
>  	};
>  
> +	clocks {
...
> +	};
> +
>  	host1x {

The node order is wrong here. The order should be:

1) Any nodes that existed in any included file, in the same order as
they existed in the included file.

2) Any new nodes that have a reg property, sorted by reg property.

3) Any new nodes without a reg property, sorted alpha-numerically by
node name.

So in this file for example, the new nod should exist between
sdhci at c8000600 and sound.

This same comment applies to every file in this patch.


From swarren at wwwdotorg.org  Tue Apr  2 15:37:58 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Tue, 02 Apr 2013 13:37:58 -0600
Subject: [PATCH V3 3/3] ARM: tegra: moving the CPU power timer function
 to PMC driver
In-Reply-To: <1364901583-24867-4-git-send-email-josephl@nvidia.com>
References: <1364901583-24867-1-git-send-email-josephl@nvidia.com>
 <1364901583-24867-4-git-send-email-josephl@nvidia.com>
Message-ID: <515B3396.4080206@wwwdotorg.org>

On 04/02/2013 05:19 AM, Joseph Lo wrote:
> The CPU power timer set up fucntion was related to PMC register. Now moving
> it to PMC driver. And it also help to clean up the PM related code later.

> diff --git a/arch/arm/mach-tegra/pmc.c b/arch/arm/mach-tegra/pmc.c

> +void set_power_timers(unsigned long us_on, unsigned long us_off)

> +	rate = clk_get_rate(tegra_pclk);
> +
> +	if (WARN_ON_ONCE(rate <= 0))

Nit: Since you need to repost the series anyway, I'd prefer to remove
that extra blank line between the assignment to rate, and the if statement.


From swarren at wwwdotorg.org  Tue Apr  2 15:39:31 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Tue, 02 Apr 2013 13:39:31 -0600
Subject: [PATCH V5 0/9] ARM: tegra: add platform suspend support
In-Reply-To: <1364901613-25080-1-git-send-email-josephl@nvidia.com>
References: <1364901613-25080-1-git-send-email-josephl@nvidia.com>
Message-ID: <515B33F3.1010007@wwwdotorg.org>

On 04/02/2013 05:20 AM, Joseph Lo wrote:
> This series introduces a basic functionality for Tegra to support the
> platform suspend and resume.
> 
> Note: This series only adds the support for Tegra20 and Tegra30. The
> Tegra114 will be supported later.
> 
> Verified on Seaboard and Cardhu.

I've also reproduced this on those two boards:-)

It's a pity that the only way to wake up Cardhu is using the RTC's
wakealarm though. Still, we can add extra keyboard/GPIO keys/... to the
various board DTs after this basic support series is checked in.


From swarren at wwwdotorg.org  Tue Apr  2 15:40:18 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Tue, 02 Apr 2013 13:40:18 -0600
Subject: [PATCH V3] ARM: tegra: cpuidle: remove redundant parameters for
 powered-down mode
In-Reply-To: <1364901650-25335-1-git-send-email-josephl@nvidia.com>
References: <1364901650-25335-1-git-send-email-josephl@nvidia.com>
Message-ID: <515B3422.9080607@wwwdotorg.org>

On 04/02/2013 05:20 AM, Joseph Lo wrote:
> After the patch series for system suspending support, tegra_idle_lp2_last()
> no longer uses its parameters cpu_on_time or cpu_off_time, so remove them.

This looks fine; I can apply it after I've applied the other two series
you posted.


From swarren at wwwdotorg.org  Tue Apr  2 15:42:57 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Tue, 02 Apr 2013 13:42:57 -0600
Subject: [PATCH V3 3/3] ARM: tegra: moving the CPU power timer function
 to PMC driver
In-Reply-To: <1364901583-24867-4-git-send-email-josephl@nvidia.com>
References: <1364901583-24867-1-git-send-email-josephl@nvidia.com>
 <1364901583-24867-4-git-send-email-josephl@nvidia.com>
Message-ID: <515B34C1.8080105@wwwdotorg.org>

On 04/02/2013 05:19 AM, Joseph Lo wrote:
> The CPU power timer set up fucntion was related to PMC register. Now moving

s/fucntion/function/.


From broonie at opensource.wolfsonmicro.com  Tue Apr  2 15:47:36 2013
From: broonie at opensource.wolfsonmicro.com (Mark Brown)
Date: Tue, 2 Apr 2013 20:47:36 +0100
Subject: [PATCH 1/2] dmaengine: add const for name parameter
In-Reply-To: <20130402175128.GN10326@intel.com>
References: <1363318601-31505-1-git-send-email-shawn.guo@linaro.org>
 <1363318601-31505-2-git-send-email-shawn.guo@linaro.org>
 <20130315085346.GA22650@pengutronix.de>
 <20130321094753.GN10326@intel.com>
 <20130321145728.GD23109@S2101-09.ap.freescale.net>
 <20130402175128.GN10326@intel.com>
Message-ID: <20130402194735.GL23065@opensource.wolfsonmicro.com>

On Tue, Apr 02, 2013 at 11:21:28PM +0530, Vinod Koul wrote:

> You can pull commit a0c43a3 from topic/of or the entire branch into your tree

It's just a warning fix so I'm not too concerned about it - so long as
everything is resolved by the time the merge window is over that ought
to be fine.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130402/dd0f7d35/attachment.sig>

From robherring2 at gmail.com  Tue Apr  2 15:49:11 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Tue, 02 Apr 2013 14:49:11 -0500
Subject: [PATCH v2 12/13] ARM: move sp804 and integrator timers to
 drivers/clocksource
In-Reply-To: <515A179A.8020800@linaro.org>
References: <1364854883-5961-1-git-send-email-robherring2@gmail.com>
 <1364854883-5961-13-git-send-email-robherring2@gmail.com>
 <515A179A.8020800@linaro.org>
Message-ID: <515B3637.8090603@gmail.com>

On 04/01/2013 06:26 PM, John Stultz wrote:
> On 04/01/2013 03:21 PM, Rob Herring wrote:
>> diff --git a/drivers/clocksource/integrator_ap_timer.c
>> b/drivers/clocksource/integrator_ap_timer.c
>> new file mode 100644
>> index 0000000..05e6204
>> --- /dev/null
>> +++ b/drivers/clocksource/integrator_ap_timer.c
> [snip]


>> +CLOCKSOURCE_OF_DECLARE(integrator_ap, "integrator-timer",
>> ap_of_timer_init);
> 
> So, most of the code here is really clockevent code and not clocksource
> code. I realize they were combined in the mach directory you're copying
> them from, but if we're going to move all this code out of the arch
> directory and into drivers/, I'd like to propose we not dump it all into
> drivers/clocksource.

Arguably, half the h/w is used for clocksource and half for clockevent
so it is equal. :) The sp804 and integrator are somewhat separated that
carving them up may be possible, but there are examples like i.MX timers
where the implementations are tied more closely together (the clockevent
compare value is the clocksource counter + delta).

Where do I put the init functions which need to know about both?

What about all the other timers that are already in drivers/clocksource?

> 
> For more context here see:
> http://www.spinics.net/lists/arm-kernel/msg234074.html

Seems like this is more a maintainer issue than necessarily what is the
right split of code (not that those are completely unrelated). Perhaps
splitting maintainership between core and drivers is needed. It
definitely seems Thomas cannot keep up with the plethora of ARM related
timers and irqchips getting moved into drivers/.

Rob

> So unless Thomas objects, would you be willing to break this change up
> adding the relevant irq related bits to a new drivers/clockevents
> directory? You can leave the sched_clock bits to clocksource for now,
> since I think that logic should eventually be integrated with the
> clocksource core.
> 
> When you resubmit, please also add Daniel Lezcano
> <daniel.lezcano at linaro.org> to the cc.
> 
> thanks
> -john



From swarren at wwwdotorg.org  Tue Apr  2 15:58:41 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Tue, 02 Apr 2013 13:58:41 -0600
Subject: [PATCH V5 7/9] ARM: dts: tegra: add non-removable and
 keep-power-in-suspend property for MMC
In-Reply-To: <1364901613-25080-8-git-send-email-josephl@nvidia.com>
References: <1364901613-25080-1-git-send-email-josephl@nvidia.com>
 <1364901613-25080-8-git-send-email-josephl@nvidia.com>
Message-ID: <515B3871.50801@wwwdotorg.org>

On 04/02/2013 05:20 AM, Joseph Lo wrote:
> This patch adds "non-removable" property of MMC host where the eMMC device
> is for Tegra platform.
> 
> And the "keep-power-in-suspend" property was used for the SDIO device that
> need this to go into suspend mode (e.g. BRCM43xx series).

>  arch/arm/boot/dts/tegra20-paz00.dts      | 1 +
>  arch/arm/boot/dts/tegra20-seaboard.dts   | 2 ++
>  arch/arm/boot/dts/tegra20-ventana.dts    | 2 ++
>  arch/arm/boot/dts/tegra20-whistler.dts   | 1 +
>  arch/arm/boot/dts/tegra30-beaver.dts     | 1 +
>  arch/arm/boot/dts/tegra30-cardhu-a02.dts | 1 +
>  arch/arm/boot/dts/tegra30-cardhu-a04.dts | 1 +
>  arch/arm/boot/dts/tegra30-cardhu.dtsi    | 1 +

I think there are a bunch of other boards that need a similar change,
right? There are certainly eMMC devices on other boards, and shouldn't
they be marked with non-removable? In particular, Beaver, Dalmore, and
Pluto, and likely some/all of the Colibri and Avionic Design boards. I
think it should be obvious which SDHCI devices need this, since there
won't be any cd-gpios property and the bus-width will likely be 8.


From olof at lixom.net  Tue Apr  2 15:59:31 2013
From: olof at lixom.net (Olof Johansson)
Date: Tue, 2 Apr 2013 12:59:31 -0700
Subject: [GIT PULL] Renesas ARM based SoC defconfig updates for v3.10 #2
In-Reply-To: <1364877094-1508-1-git-send-email-horms+renesas@verge.net.au>
References: <1364877094-1508-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <20130402195931.GB8015@quad.lixom.net>

On Tue, Apr 02, 2013 at 01:31:31PM +0900, Simon Horman wrote:
> Hi Arnd, Hi Olof,
> 
> The following changes since commit db30abdf3c07c564d4af0f991bb7f38b728f9035:
> 
>   ARM: mach-shmobile: marzen: add SATA support (2013-03-14 10:28:07 +0100)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-defconfig2-for-v3.10
> 
> for you to fetch changes up to 03d409a5c4f8b590caaebd8c99e8977227c3dee7:
> 
>   ARM: shmobile: ape6evm: add defconfig (2013-04-01 17:52:07 +0900)


Pulled, thanks.


-Olof


From swarren at wwwdotorg.org  Tue Apr  2 16:00:55 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Tue, 02 Apr 2013 14:00:55 -0600
Subject: [PATCH V5 9/9] ARM: dts: tegra: add the PM configurations of PMC
In-Reply-To: <1364901613-25080-10-git-send-email-josephl@nvidia.com>
References: <1364901613-25080-1-git-send-email-josephl@nvidia.com>
 <1364901613-25080-10-git-send-email-josephl@nvidia.com>
Message-ID: <515B38F7.5050606@wwwdotorg.org>

On 04/02/2013 05:20 AM, Joseph Lo wrote:
> Adding the PM configuration of PMC when the platform support suspend
> function.

For this patch, some more boards could be supported, but I think we'll
have to rely on other people (Lucas, Thierry) to send patches for them,
since they know the details of the board. It's fine to leave suspend
disabled on those boards until later.

Aside from the 1 other comment I made on this series, I think it's good
to go once your previous 3-long series is fixed and reposted per my
comments on it.


From olof at lixom.net  Tue Apr  2 16:25:03 2013
From: olof at lixom.net (Olof Johansson)
Date: Tue, 2 Apr 2013 13:25:03 -0700
Subject: [GIT PULL] Renesas ARM SoC updates for v3.10 #2
In-Reply-To: <1364879246-9470-1-git-send-email-horms+renesas@verge.net.au>
References: <1364879246-9470-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <20130402202503.GC8015@quad.lixom.net>

On Tue, Apr 02, 2013 at 02:06:56PM +0900, Simon Horman wrote:
> Hi Arnd, Hi Olof,
> 
> The following changes since commit 4c82e452732784419fd616cf1acf2bc9b004aae1:
> 
>   Merge tag 'renesas-intc-external-irq2-for-v3.10' into soc-base (2013-04-02 10:55:57 +0900)
> 
> are available in the git repository at:
> 
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-soc2-for-v3.10
> 
> for you to fetch changes up to 8585deb18580d04209a2986430aa0959ef38fce2:
> 
>   ARM: shmobile: r8a7790 SoC 64-bit DT support (2013-04-02 11:02:21 +0900)
> 
> ----------------------------------------------------------------
> Second round of Renesas ARM SoC updates for v3.10
> 
> Some Highlights:
> 
> * Add r8a7790 SoC
> * Add r8a73a4 SoC
> * Migrate r8a7740 SoC from INTC to GIC
> * Add thermal driver support to r8a73a4 SoC
> * Add irqpin DT nodes to sh73a0 SoC
> * Add SCIF support to r8a7778 SoC
> 
> This pull request is based on a merge of:
> git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas renesas-soc-for-v3.10
> git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas renesas-intc-external-irq2-for-v3.10

Ugh. So, the irq branch depends on the old soc branch, and now this depends on
the irq branch (and it is soc code). That's a circular dependency.

I'll add this as a next/soc2 branch in arm-soc, but please think about these
kind of circular dependencies in the future, and try to avoid them if you can
by splitting the branch contents in separate topics if possible.

Likewise, there's a bunch of patches in this branch such as the fixed divisor
clock patches that could be considered cleanup. Not a big deal to group them
with the soc code, but if you're already doing cleanup branches it'd be just as
well to put them in those.


-Olof


From paul at pwsan.com  Tue Apr  2 16:25:24 2013
From: paul at pwsan.com (Paul Walmsley)
Date: Tue, 2 Apr 2013 20:25:24 +0000 (UTC)
Subject: OMAP baseline test results for v3.9-rc3
In-Reply-To: <1364375463.3146.9.camel@sokoban>
References: <alpine.DEB.2.00.1303181536230.29332@utopia.booyaka.com>
 <51482707.6020501@ti.com> <1363684373.15426.137.camel@sokoban>
 <alpine.DEB.2.00.1303261829440.23957@utopia.booyaka.com>
 <1364375463.3146.9.camel@sokoban>
Message-ID: <alpine.DEB.2.00.1304022006360.31045@utopia.booyaka.com>

Hi

On Wed, 27 Mar 2013, Tero Kristo wrote:

> On Tue, 2013-03-26 at 18:43 +0000, Paul Walmsley wrote:
>
> > So what I'd like you to do is:
> > 
> > 1. Determine what devices are remaining to be reset and idled on OMAP4 
> >    with the bootloader that I use.  As far as I know, there are only four 
> >    that block full-chip idle: M3, DSP, SL2IF, FSUSB
> > 
> > 2. Determine what's needed to reset and idle them.  For the M3 and DSP, 
> >    I'd assume this involves pointing the reset vector for those 
> >    processors at a few lines of code that basically enter WFI or the C64x 
> >    equivalent.
> 
> This is the nasty part. We need firmware support for the blocks to do
> this, and this is imo a complete overkill for the task at hand, as it
> will duplicate the DSP + M3 firmware and drivers at least partially.

Why can't the DSP & M3 go straight from the reset vector to WFI (or the 
C64x equivalent?)  The M3s might need a couple of additional instructions 
to program DEEPSLEEP mode.  What other significant additional code is 
needed for those processors?

> If there was a simple way to do this, don't you think this would have
> been done already a year back when we started to discuss this first
> time? 

No, I don't think it has anything to do with the simplicity of the task.  
My sense is that no one at TI wants to work on it.  I can sympathize, but 
all of us who work on upstream Linux do things that we'd rather not do, 
for a more stable or more maintainable kernel.

So the first thing that should be done is to figure out whether the 
situation is really as bad as was suggested above.  Doesn't it seem 
unlikely that it would be necessary to "duplicate the firmware" -- which 
does much more than just idle the DSP & M3 -- just to put those subsystems 
into idle?

There's also the reset of the FSUSB IP block, which shouldn't need any 
firmware.  Who's going to work on that one?


- Paul


From sboyd at codeaurora.org  Tue Apr  2 16:31:12 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Tue,  2 Apr 2013 13:31:12 -0700
Subject: [PATCH] ARM: arch_timer: Silence debug preempt warnings
Message-ID: <1364934672-31554-1-git-send-email-sboyd@codeaurora.org>

Hot-plugging with CONFIG_DEBUG_PREEMPT=y on a device with arm
architected timers causes a slew of "using smp_processor_id() in
preemptible" warnings:

  BUG: using smp_processor_id() in preemptible [00000000] code: sh/111
  caller is arch_timer_cpu_notify+0x14/0xc8

This happens because sometimes the cpu notifier, arch_timer_cpu_notify(),
is called in preemptible context but we use this_cpu_ptr()
to retrieve the clockevent unconditionally. We're only going to
actually use the pointer in non-preemptible context though,
so use __this_cpu_ptr() instead to avoid the preemptible checks
and silence the warning.

Cc: Mark Rutland <mark.rutland at arm.com>
Cc: Marc Zyngier <Marc.Zyngier at arm.com>
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 drivers/clocksource/arm_arch_timer.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
index d7ad425..5928c29 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -248,7 +248,7 @@ static void __cpuinit arch_timer_stop(struct clock_event_device *clk)
 static int __cpuinit arch_timer_cpu_notify(struct notifier_block *self,
 					   unsigned long action, void *hcpu)
 {
-	struct clock_event_device *evt = this_cpu_ptr(arch_timer_evt);
+	struct clock_event_device *evt = __this_cpu_ptr(arch_timer_evt);
 
 	switch (action & ~CPU_TASKS_FROZEN) {
 	case CPU_STARTING:
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From olof at lixom.net  Tue Apr  2 16:33:05 2013
From: olof at lixom.net (Olof Johansson)
Date: Tue, 2 Apr 2013 13:33:05 -0700
Subject: [PATCH 06/28] gpio: Renesas R-Car GPIO driver V3
In-Reply-To: <1364879376-10020-7-git-send-email-horms+renesas@verge.net.au>
References: <1364879376-10020-1-git-send-email-horms+renesas@verge.net.au>
 <1364879376-10020-7-git-send-email-horms+renesas@verge.net.au>
Message-ID: <20130402203305.GD8015@quad.lixom.net>

On Tue, Apr 02, 2013 at 02:09:14PM +0900, Simon Horman wrote:
> From: Magnus Damm <damm at opensource.se>
> 
> This patch is V3 of a GPIO driver for the R-Car series of
> SoCs from Renesas. This driver is designed to be reusable
> between multiple SoCs that share the same basic building block,
> but so far it has only been used on R-Car H1 (r8a7779).
> 
> Each driver instance handles 32 GPIOs with individually
> maskable IRQs. The driver operates on a single I/O memory
> range and the 32 GPIOs are hooked up a single interrupt.
> 
> In the case of R-Car H1 either external IRQ pins or GPIOs
> with interrupts can be used for on-board interupts. For
> external IRQs 4 pins are supported, and in the case of GPIO
> there are 202 GPIOS as 202 interrupts hooked up via 6 driver
> instances and to the GIC and the Cortex-A9 Quad.
> 
> At this point this driver is interfacing as a regular
> platform device driver. In the future DT support will be
> submitted as an incremental feature patch.
> 
> Signed-off-by: Magnus Damm <damm at opensource.se>
> Signed-off-by: Simon Horman <horms+renesas at verge.net.au>

Hmm, you seem to not be collecting tags on patches or at least missed
one here. This patch, when posted, got a Reviewed-by from LinusW. I
caught it mostly since it had no ack (or reviewed) from the subsystem
maintainer in this case.

Please rebuild and resend with reviewed/acked tags as you've received
them, please.


Thanks!

-Olof


From heiko at sntech.de  Tue Apr  2 16:36:32 2013
From: heiko at sntech.de (Heiko =?utf-8?q?St=C3=BCbner?=)
Date: Tue, 2 Apr 2013 22:36:32 +0200
Subject: [PATCH 07/23] i2c: s3c2410: make header file local
In-Reply-To: <1362505353-8873-8-git-send-email-arnd@arndb.de>
References: <1362505353-8873-1-git-send-email-arnd@arndb.de>
 <1362505353-8873-8-git-send-email-arnd@arndb.de>
Message-ID: <201304022236.32629.heiko@sntech.de>

Am Dienstag, 5. M?rz 2013, 18:42:17 schrieb Arnd Bergmann:
> No other file in the kernel besides i2c-s3c2410.c uses
> the current plat/regs-iic.h, so we can simply move the
> header file to live in the same directory as the driver,
> as a preparation to multiplatform builds.

A patch doing the same is already sitting in the i2c for-next branch [0].


Heiko



[0] https://git.kernel.org/cgit/linux/kernel/git/wsa/linux.git/commit/?h=i2c/for-next&id=e636602ac2613da8c1777cb42443223994be4107


From olof at lixom.net  Tue Apr  2 16:41:45 2013
From: olof at lixom.net (Olof Johansson)
Date: Tue, 2 Apr 2013 13:41:45 -0700
Subject: [PATCH V7 2/2] ARM: bcm281xx: Add timer driver (DT portion)
In-Reply-To: <1363210048-3334-2-git-send-email-csd@broadcom.com>
References: <1363210048-3334-1-git-send-email-csd@broadcom.com>
 <1363210048-3334-2-git-send-email-csd@broadcom.com>
Message-ID: <20130402204145.GE8015@quad.lixom.net>

On Wed, Mar 13, 2013 at 02:27:28PM -0700, Christian Daudt wrote:
> This adds support for the Broadcom timer, used in the following SoCs:
> BCM11130, BCM11140, BCM11351, BCM28145, BCM28155
> 
> Updates from V6:
> - Split DT portion into a separate patch
> 
> Updates from V5:
> - Rebase to latest arm-soc/for-next
> 
> Updates from V4:
> - Switch code to use CLOCKSOURCE_OF_DECLARE
> 
> Updates from V3:
> - Migrate to 3.9 timer framework updates
> 
> Updates from V2:
> - prepend static fns + fields with kona_
> 
> Updates from V1:
> - Rename bcm_timer.c to bcm_kona_timer.c
> - Pull .h into bcm_kona_timer.c
> - Make timers static
> - Clean up comment block
> - Switched to using clockevents_config_and_register
> - Added an error to the get_timer loop if it repeats too much
> - Added to Documentation/devicetree/bindings/arm/bcm/bcm,kona-timer.txt
> - Added missing readl to timer_disable_and_clear
> 
> Note: bcm,kona-timer was kept as the 'compatible' field to make it
> specific enough for when there are multiple bcm timers (bcm,timer is
> too generic).
> 
> Signed-off-by: Christian Daudt <csd at broadcom.com>
> Acked-by: Arnd Bergmann <arnd at arndb.de>
> Acked-by: John Stultz <john.stultz at linaro.org>
> Reviewed-by: Stephen Warren <swarren at nvidia.com>

Thanks, applied to next/soc.


-Olof


From olof at lixom.net  Tue Apr  2 16:43:01 2013
From: olof at lixom.net (Olof Johansson)
Date: Tue, 2 Apr 2013 13:43:01 -0700
Subject: [PATCH V7 2/2] ARM: bcm281xx: Add timer driver (DT portion)
In-Reply-To: <CAGFynZ_YEHbUQxGFgp_SA__4xRge64oQ-y5ypXhV5mhtM2k4+w@mail.gmail.com>
References: <1363210048-3334-1-git-send-email-csd@broadcom.com>
 <1363210048-3334-2-git-send-email-csd@broadcom.com>
 <CAGFynZ_YEHbUQxGFgp_SA__4xRge64oQ-y5ypXhV5mhtM2k4+w@mail.gmail.com>
Message-ID: <20130402204301.GF8015@quad.lixom.net>

On Thu, Mar 28, 2013 at 09:07:41AM -0700, Christian Daudt wrote:
> Hi Grant,
>  In discussion with Olof @ Connect, he suggested that it would be best
> to send dt changes as a standalone patch to devicetree-discuss list to
> get it applied on its own. Can you pls apply this patch ?

Actually, I wanted them split but since these change the SoC dtsi it should
probably still go through arm-soc. I've applied it to our next/soc branch now.


Based on the thread, it looks like the main driver is picked up by John and
will go in that through his tree.

Thanks for your patience on dealing with this!



-Olof


From olof at lixom.net  Tue Apr  2 16:46:35 2013
From: olof at lixom.net (Olof Johansson)
Date: Tue, 2 Apr 2013 13:46:35 -0700
Subject: [PATCH] MAINTAINERS: Add maintainer for LPC32xx
In-Reply-To: <1364924231-18591-1-git-send-email-stigge@antcom.de>
References: <1364924231-18591-1-git-send-email-stigge@antcom.de>
Message-ID: <20130402204635.GG8015@quad.lixom.net>

On Tue, Apr 02, 2013 at 07:37:11PM +0200, Roland Stigge wrote:
> This patch adds Roland Stigge as maintainer for NXP LPC32xx.
> 
> Signed-off-by: Roland Stigge <stigge at antcom.de>

Thanks, applied.


-Olof


From festevam at gmail.com  Tue Apr  2 16:52:52 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Tue, 2 Apr 2013 17:52:52 -0300
Subject: [PATCH 0/6] Add initial imx6dl support
In-Reply-To: <1364913079-26039-1-git-send-email-shawn.guo@linaro.org>
References: <1364913079-26039-1-git-send-email-shawn.guo@linaro.org>
Message-ID: <CAOMZO5D5gD5KQvh885isVV8vKf3p_-rbYb1mYq_N5pp1q24Eag@mail.gmail.com>

On Tue, Apr 2, 2013 at 11:31 AM, Shawn Guo <shawn.guo at linaro.org> wrote:
> The i.MX6 DualLite/Solo (imx6dl) is a derivative of i.MX6 Quad/Dual
> (imx6q).  These two chips are highly compatible.  The series adds the
> initial imx6dl support based on imx6q base.
>
> Linus,
>
> The first two patches has dependency on patch "pinctrl: imx: move
> hard-coding data into device tree", which is sitting on IMX tree.  So
> can you please give your ACK for me to take them through the same tree?
>
> Thanks,
> Shawn
>
> Shawn Guo (6):
>   pinctrl: add pinctrl driver for imx6dl

I am not able to locate patch 1/6. Do you have a git tree with this
series applied?


From tim.bird at am.sony.com  Tue Apr  2 17:08:46 2013
From: tim.bird at am.sony.com (Tim Bird)
Date: Tue, 2 Apr 2013 14:08:46 -0700
Subject: RFC: right way to conditional-ize some macros for LTO
In-Reply-To: <1364907037.3650.54.camel@linaro1.home>
References: <5155E28A.30509@am.sony.com>
 <1364907037.3650.54.camel@linaro1.home>
Message-ID: <515B48DE.4000808@am.sony.com>

On 04/02/2013 05:50 AM, Jon Medhurst (Tixy) wrote:
> On Fri, 2013-03-29 at 11:50 -0700, Tim Bird wrote:
>> The macros themselves seem empty.  Can someone tell me what they do?
>> What is the status of these macros?  Are they even needed?
> 
> The names of the macros are for Thumb2 instructions which are redundant
> when building for the ARM instruction set. Newer toolchains which
> support the unified assembler syntax will effectively ignore them and I
> guess these empty macros are there so people can write assembler which
> will compile with older toolchains.
> 
>> Could they be
>> made conditional on something like NEED_IT_MACROS, and then have that set only
>> in the arch/arm/kernel/kprobes-test-thumb.c, before the unified.h is included?
> 
> That file needs the real Thumb2 instructions, not empty macros, and
> indeed it doesn't use them, because it is only compiled when
> CONFIG_THUMB2_KERNEL=y and that selects CONFIG_ARM_ASM_UNIFIED and those
> 'it' macro's are guarded by #ifndef CONFIG_ARM_ASM_UNIFIED.
> 
> Note, there are other files which use the 'it' instructions, e.g.
> arch/arm/include/asm/futex.h.
> 
>> I would like get this minor issue resolved in mainline, to make it easier for Andi
>> to get his LTO work upstream and have it work with ARM.
>>
>> Any suggestions are welcome.
> 
> If your toolchain supports the unified assembler syntax, you could try
> enabling CONFIG_ARM_ASM_UNIFIED in ARM builds.

Thanks very much!  It may well be that any toolchain capable of supporting
LTO will support the unified assembler syntax, in which case it would make
sense for LTO to enable this, on ARM.  I'll check it out.
 -- Tim

=============================
Tim Bird
Architecture Group Chair, CE Workgroup of the Linux Foundation
Senior Staff Engineer, Sony Network Entertainment
=============================



From ulf.hansson at stericsson.com  Tue Apr  2 17:09:36 2013
From: ulf.hansson at stericsson.com (Ulf Hansson)
Date: Tue, 2 Apr 2013 23:09:36 +0200
Subject: [PATCH V4 0/3] clk: Fixup issues for clk_set_parent
Message-ID: <1364936979-20805-1-git-send-email-ulf.hansson@stericsson.com>

From: Ulf Hansson <ulf.hansson at linaro.org>

These issues exist in the clk_set_parent API:

* Race issue for spinlocks when updating the clock tree toplogy.
* The feature of reparent to the orphan list is broken.

This patchset fixes both problems. Patch 1 prepares for patch 2 and
patch 3, which are where the real issues are resolved.

Changes in v4:
	- Rebased on top Mike's clk reentrancy patches.

Changes in v3:
	- Fix review comments from Mike.
	- Include fixup for allow reparent to the orphan list.

Changes in v2:
	- Do not remove the existing __clk_reparent API.
	- Rebase patches.

Ulf Hansson (3):
  clk: Restructure code for __clk_reparent
  clk: Fixup errorhandling for clk_set_parent
  clk: Fixup locking issues for clk_set_parent

 drivers/clk/clk.c |  193 ++++++++++++++++++++++++++++++++++++-----------------
 1 file changed, 130 insertions(+), 63 deletions(-)

-- 
1.7.10



From ulf.hansson at stericsson.com  Tue Apr  2 17:09:37 2013
From: ulf.hansson at stericsson.com (Ulf Hansson)
Date: Tue, 2 Apr 2013 23:09:37 +0200
Subject: [PATCH V4 1/3] clk: Restructure code for __clk_reparent
In-Reply-To: <1364936979-20805-1-git-send-email-ulf.hansson@stericsson.com>
References: <1364936979-20805-1-git-send-email-ulf.hansson@stericsson.com>
Message-ID: <1364936979-20805-2-git-send-email-ulf.hansson@stericsson.com>

From: Ulf Hansson <ulf.hansson at linaro.org>

Split __clk_reparent into three pieces, one for doing the actual
reparent for updating the clock tree topology, one for the
COMMON_CLK_DEBUG code and one for doing the rate recalculation.

This patch also makes it possible to hold the spinlock over the
update of the clock tree topology, which could not be done before
when both debugfs updates and clock rate updates was done within
the same function.

Signed-off-by: Ulf Hansson <ulf.hansson at linaro.org>
Cc: Rajagopal Venkat <rajagopal.venkat at linaro.org>
---
 drivers/clk/clk.c |   70 ++++++++++++++++++++++++++++++++---------------------
 1 file changed, 42 insertions(+), 28 deletions(-)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 0230c9d..013a3c7 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -343,6 +343,39 @@ out:
 }
 
 /**
+ * clk_debug_reparent - reparent clk node in the debugfs clk tree
+ * @clk: the clk being reparented
+ * @new_parent: the new clk parent, may be NULL
+ *
+ * Rename clk entry in the debugfs clk tree if debugfs has been
+ * initialized.  Otherwise it bails out early since the debugfs clk tree
+ * will be created lazily by clk_debug_init as part of a late_initcall.
+ *
+ * Caller must hold prepare_lock.
+ */
+static void clk_debug_reparent(struct clk *clk, struct clk *new_parent)
+{
+	struct dentry *d;
+	struct dentry *new_parent_d;
+
+	if (!inited)
+		return;
+
+	if (new_parent)
+		new_parent_d = new_parent->dentry;
+	else
+		new_parent_d = orphandir;
+
+	d = debugfs_rename(clk->dentry->d_parent, clk->dentry,
+			new_parent_d, clk->name);
+	if (d)
+		clk->dentry = d;
+	else
+		pr_debug("%s: failed to rename debugfs entry for %s\n",
+				__func__, clk->name);
+}
+
+/**
  * clk_debug_init - lazily create the debugfs clk tree visualization
  *
  * clks are often initialized very early during boot before memory can
@@ -396,6 +429,9 @@ static int __init clk_debug_init(void)
 late_initcall(clk_debug_init);
 #else
 static inline int clk_debug_register(struct clk *clk) { return 0; }
+static inline void clk_debug_reparent(struct clk *clk, struct clk *new_parent)
+{
+}
 #endif
 
 /* caller must hold prepare_lock */
@@ -1277,16 +1313,8 @@ out:
 	return ret;
 }
 
-void __clk_reparent(struct clk *clk, struct clk *new_parent)
+static void clk_reparent(struct clk *clk, struct clk *new_parent)
 {
-#ifdef CONFIG_COMMON_CLK_DEBUG
-	struct dentry *d;
-	struct dentry *new_parent_d;
-#endif
-
-	if (!clk || !new_parent)
-		return;
-
 	hlist_del(&clk->child_node);
 
 	if (new_parent)
@@ -1294,27 +1322,13 @@ void __clk_reparent(struct clk *clk, struct clk *new_parent)
 	else
 		hlist_add_head(&clk->child_node, &clk_orphan_list);
 
-#ifdef CONFIG_COMMON_CLK_DEBUG
-	if (!inited)
-		goto out;
-
-	if (new_parent)
-		new_parent_d = new_parent->dentry;
-	else
-		new_parent_d = orphandir;
-
-	d = debugfs_rename(clk->dentry->d_parent, clk->dentry,
-			new_parent_d, clk->name);
-	if (d)
-		clk->dentry = d;
-	else
-		pr_debug("%s: failed to rename debugfs entry for %s\n",
-				__func__, clk->name);
-out:
-#endif
-
 	clk->parent = new_parent;
+}
 
+void __clk_reparent(struct clk *clk, struct clk *new_parent)
+{
+	clk_reparent(clk, new_parent);
+	clk_debug_reparent(clk, new_parent);
 	__clk_recalc_rates(clk, POST_RATE_CHANGE);
 }
 
-- 
1.7.10



From ulf.hansson at stericsson.com  Tue Apr  2 17:09:38 2013
From: ulf.hansson at stericsson.com (Ulf Hansson)
Date: Tue, 2 Apr 2013 23:09:38 +0200
Subject: [PATCH V4 2/3] clk: Fixup errorhandling for clk_set_parent
In-Reply-To: <1364936979-20805-1-git-send-email-ulf.hansson@stericsson.com>
References: <1364936979-20805-1-git-send-email-ulf.hansson@stericsson.com>
Message-ID: <1364936979-20805-3-git-send-email-ulf.hansson@stericsson.com>

From: Ulf Hansson <ulf.hansson at linaro.org>

Fixup the broken feature of allowing reparent of a clk to the
orhpan list and vice verse. When operating on a single-parent
clk, the .set_parent callback for the clk hw is optional to
implement, but for a multi-parent clk it is mandatory.

Moreover improve the errorhandling by verifying the prerequisites
before triggering clk notifiers. This will prevent unnecessary
rollback with ABORT_RATE_CHANGE.

Signed-off-by: Ulf Hansson <ulf.hansson at linaro.org>
Cc: Rajagopal Venkat <rajagopal.venkat at linaro.org>
---
 drivers/clk/clk.c |   56 ++++++++++++++++++++++++++++++++++-------------------
 1 file changed, 36 insertions(+), 20 deletions(-)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 013a3c7..c83e8e5 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -1332,15 +1332,10 @@ void __clk_reparent(struct clk *clk, struct clk *new_parent)
 	__clk_recalc_rates(clk, POST_RATE_CHANGE);
 }
 
-static int __clk_set_parent(struct clk *clk, struct clk *parent)
+static u8 clk_fetch_parent_index(struct clk *clk, struct clk *parent)
 {
-	struct clk *old_parent;
-	unsigned long flags;
-	int ret = -EINVAL;
 	u8 i;
 
-	old_parent = clk->parent;
-
 	if (!clk->parents)
 		clk->parents = kzalloc((sizeof(struct clk*) * clk->num_parents),
 								GFP_KERNEL);
@@ -1360,11 +1355,14 @@ static int __clk_set_parent(struct clk *clk, struct clk *parent)
 		}
 	}
 
-	if (i == clk->num_parents) {
-		pr_debug("%s: clock %s is not a possible parent of clock %s\n",
-				__func__, parent->name, clk->name);
-		goto out;
-	}
+	return i;
+}
+
+static int __clk_set_parent(struct clk *clk, struct clk *parent, u8 p_index)
+{
+	unsigned long flags;
+	int ret = 0;
+	struct clk *old_parent = clk->parent;
 
 	/* migrate prepare and enable */
 	if (clk->prepare_count)
@@ -1377,7 +1375,8 @@ static int __clk_set_parent(struct clk *clk, struct clk *parent)
 	clk_enable_unlock(flags);
 
 	/* change clock input source */
-	ret = clk->ops->set_parent(clk->hw, i);
+	if (parent && clk->ops->set_parent)
+		ret = clk->ops->set_parent(clk->hw, p_index);
 
 	/* clean up old prepare and enable */
 	flags = clk_enable_lock();
@@ -1388,7 +1387,6 @@ static int __clk_set_parent(struct clk *clk, struct clk *parent)
 	if (clk->prepare_count)
 		__clk_unprepare(old_parent);
 
-out:
 	return ret;
 }
 
@@ -1407,11 +1405,14 @@ out:
 int clk_set_parent(struct clk *clk, struct clk *parent)
 {
 	int ret = 0;
+	u8 p_index = 0;
+	unsigned long p_rate = 0;
 
 	if (!clk || !clk->ops)
 		return -EINVAL;
 
-	if (!clk->ops->set_parent)
+	/* verify ops for for multi-parent clks */
+	if ((clk->num_parents > 1) && (!clk->ops->set_parent))
 		return -ENOSYS;
 
 	/* prevent racing with updates to the clock topology */
@@ -1420,19 +1421,34 @@ int clk_set_parent(struct clk *clk, struct clk *parent)
 	if (clk->parent == parent)
 		goto out;
 
+	/* check that we are allowed to re-parent if the clock is in use */
+	if ((clk->flags & CLK_SET_PARENT_GATE) && clk->prepare_count) {
+		ret = -EBUSY;
+		goto out;
+	}
+
+	/* try finding the new parent index */
+	if (parent) {
+		p_index = clk_fetch_parent_index(clk, parent);
+		p_rate = parent->rate;
+		if (p_index == clk->num_parents) {
+			pr_debug("%s: clk %s can not be parent of clk %s\n",
+					__func__, parent->name, clk->name);
+			ret = -EINVAL;
+			goto out;
+		}
+	}
+
 	/* propagate PRE_RATE_CHANGE notifications */
 	if (clk->notifier_count)
-		ret = __clk_speculate_rates(clk, parent->rate);
+		ret = __clk_speculate_rates(clk, p_rate);
 
 	/* abort if a driver objects */
 	if (ret == NOTIFY_STOP)
 		goto out;
 
-	/* only re-parent if the clock is not in use */
-	if ((clk->flags & CLK_SET_PARENT_GATE) && clk->prepare_count)
-		ret = -EBUSY;
-	else
-		ret = __clk_set_parent(clk, parent);
+	/* do the re-parent */
+	ret = __clk_set_parent(clk, parent, p_index);
 
 	/* propagate ABORT_RATE_CHANGE if .set_parent failed */
 	if (ret) {
-- 
1.7.10



From ulf.hansson at stericsson.com  Tue Apr  2 17:09:39 2013
From: ulf.hansson at stericsson.com (Ulf Hansson)
Date: Tue, 2 Apr 2013 23:09:39 +0200
Subject: [PATCH V4 3/3] clk: Fixup locking issues for clk_set_parent
In-Reply-To: <1364936979-20805-1-git-send-email-ulf.hansson@stericsson.com>
References: <1364936979-20805-1-git-send-email-ulf.hansson@stericsson.com>
Message-ID: <1364936979-20805-4-git-send-email-ulf.hansson@stericsson.com>

From: Ulf Hansson <ulf.hansson at linaro.org>

Updating the clock tree topology must be protected with the spinlock
when doing clk_set_parent, otherwise we can not handle the migration
of the enable_count in a safe manner.

While issuing the .set_parent callback to make the clk-hw perform the
switch to the new parent, we can not hold the spinlock since it is must
be allowed to be slow path. This complicates error handling, but is still
possible to achieve.

Signed-off-by: Ulf Hansson <ulf.hansson at linaro.org>
Cc: Rajagopal Venkat <rajagopal.venkat at linaro.org>
---
 drivers/clk/clk.c |   67 +++++++++++++++++++++++++++++++++++++++++------------
 1 file changed, 52 insertions(+), 15 deletions(-)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index c83e8e5..de6b459 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -1363,31 +1363,71 @@ static int __clk_set_parent(struct clk *clk, struct clk *parent, u8 p_index)
 	unsigned long flags;
 	int ret = 0;
 	struct clk *old_parent = clk->parent;
+	bool migrated_enable = false;
 
-	/* migrate prepare and enable */
+	/* migrate prepare */
 	if (clk->prepare_count)
 		__clk_prepare(parent);
 
-	/* FIXME replace with clk_is_enabled(clk) someday */
 	flags = clk_enable_lock();
-	if (clk->enable_count)
+
+	/* migrate enable */
+	if (clk->enable_count) {
 		__clk_enable(parent);
+		migrated_enable = true;
+	}
+
+	/* update the clk tree topology */
+	clk_reparent(clk, parent);
+
 	clk_enable_unlock(flags);
 
 	/* change clock input source */
 	if (parent && clk->ops->set_parent)
 		ret = clk->ops->set_parent(clk->hw, p_index);
 
-	/* clean up old prepare and enable */
-	flags = clk_enable_lock();
-	if (clk->enable_count)
+	if (ret) {
+		/*
+		 * The error handling is tricky due to that we need to release
+		 * the spinlock while issuing the .set_parent callback. This
+		 * means the new parent might have been enabled/disabled in
+		 * between, which must be considered when doing rollback.
+		 */
+		flags = clk_enable_lock();
+
+		clk_reparent(clk, old_parent);
+
+		if (migrated_enable && clk->enable_count) {
+			__clk_disable(parent);
+		} else if (migrated_enable && (clk->enable_count == 0)) {
+			__clk_disable(old_parent);
+		} else if (!migrated_enable && clk->enable_count) {
+			__clk_disable(parent);
+			__clk_enable(old_parent);
+		}
+
+		clk_enable_unlock(flags);
+
+		if (clk->prepare_count)
+			__clk_unprepare(parent);
+
+		return ret;
+	}
+
+	/* clean up enable for old parent if migration was done */
+	if (migrated_enable) {
+		flags = clk_enable_lock();
 		__clk_disable(old_parent);
-	clk_enable_unlock(flags);
+		clk_enable_unlock(flags);
+	}
 
+	/* clean up prepare for old parent if migration was done */
 	if (clk->prepare_count)
 		__clk_unprepare(old_parent);
 
-	return ret;
+	/* update debugfs with new clk tree topology */
+	clk_debug_reparent(clk, parent);
+	return 0;
 }
 
 /**
@@ -1450,14 +1490,11 @@ int clk_set_parent(struct clk *clk, struct clk *parent)
 	/* do the re-parent */
 	ret = __clk_set_parent(clk, parent, p_index);
 
-	/* propagate ABORT_RATE_CHANGE if .set_parent failed */
-	if (ret) {
+	/* propagate rate recalculation accordingly */
+	if (ret)
 		__clk_recalc_rates(clk, ABORT_RATE_CHANGE);
-		goto out;
-	}
-
-	/* propagate rate recalculation downstream */
-	__clk_reparent(clk, parent);
+	else
+		__clk_recalc_rates(clk, POST_RATE_CHANGE);
 
 out:
 	clk_prepare_unlock();
-- 
1.7.10



From alexey.pelykh at gmail.com  Tue Apr  2 17:19:45 2013
From: alexey.pelykh at gmail.com (Alexey Pelykh)
Date: Wed, 3 Apr 2013 00:19:45 +0300
Subject: [PATCH] Revert "OMAP/serial: Fix incorrect Rx FIFO threshold
 setting, LSR validation on Tx, and Tx FIFO IRQ generation"
In-Reply-To: <alpine.DEB.2.00.1304021821190.27146@utopia.booyaka.com>
References: <alpine.DEB.2.00.1304010519260.28273@utopia.booyaka.com>
 <CAOmKuSpttQJmrL=Htiz-Zc4voAF7CnG_GQYAO2onKpauwYjtvw@mail.gmail.com>
 <alpine.DEB.2.00.1304010844100.28273@utopia.booyaka.com>
 <CAOmKuSrABrPcZ=Yg1+LAHWbh9CdTYR0eUmJ2dd3z91oz0uu21g@mail.gmail.com>
 <alpine.DEB.2.00.1304011008230.28273@utopia.booyaka.com>
 <CAOmKuSrbDc025Tj9xsqDebJ_KZdp_VnWAOs_OO5UAegV43JcDQ@mail.gmail.com>
 <CAOmKuSpbaKutLxbNihBRDz+B0Wt0XiPss-PcEHc-efCTvciNFg@mail.gmail.com>
 <alpine.DEB.2.00.1304011654520.9148@utopia.booyaka.com>
 <CAOmKuSo4onVtk2Ke-i+0_1Ych33KuUYspRy+cySRHf4yWB5XDw@mail.gmail.com>
 <alpine.DEB.2.00.1304021821190.27146@utopia.booyaka.com>
Message-ID: <CAOmKuSqd=gNYFutpgDref58pbAbDwDin4mvL_OEooD1XuwKtgQ@mail.gmail.com>

Hi Paul,

No problem, I'll prepare patch in next 24 hours and will send in ASAP.

But, since we've found the issue, I suggest that we should look at it
closer, especially since at this moment only you can reproduce it. As
far as I understand, but I may be wrong,
this comment is wrong, since if to specify
OMAP_UART_SCR_RX_TRIG_GRANU1_MASK, it effectively sets Rx threshold to
1 character, instead of 16.
/* Set receive FIFO threshold to 16 characters and
 * transmit FIFO threshold to 16 spaces
 */

On Tue, Apr 2, 2013 at 9:24 PM, Paul Walmsley <paul at pwsan.com> wrote:
> On Mon, 1 Apr 2013, Alexey Pelykh wrote:
>
>> Paul, can you please try to comment out change related to Rx line
>> (granulation one). That's only Rx line related change in the patch.
>
> Yes, looks like simply reverting the commit 1776fd059c40 ("OMAP/serial:
> Fix incorrect Rx FIFO threshold setting, LSR validation on Tx, and Tx FIFO
> IRQ generation") change to OMAP_UART_SCR_RX_TRIG_GRANU1_MASK fixes it.
>
> Care to send a patch doing so ASAP for v3.9-rc fixes?  That would moot the
> revert of the entire commit 1776fd059c40.
>
>
> - Paul


From sebastian.hesselbarth at gmail.com  Tue Apr  2 17:47:08 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Tue, 02 Apr 2013 23:47:08 +0200
Subject: [PATCH v2] ARM: kirkwood: extend the kirkwood i2s driver for
 DT usage
In-Reply-To: <20130402201348.4ab406fb@armhf>
References: <20130402201348.4ab406fb@armhf>
Message-ID: <515B51DC.7020002@gmail.com>

On 04/02/2013 08:13 PM, Jean-Francois Moine wrote:
> The kirkwood i2s driver is used without DT in the Kirkwood machine.
> This patch adds a DT compatible definition for use in other Marvell
> machines as the Armada 88AP510 (Dove).
>
> Signed-off-by: Jean-Francois Moine<moinejf at free.fr>
> ---
[...]
> +Optional property:
> +
> +- marvell,burst-size: burst size which can be only 32 or 128.
> +  Default value is 128.

Jean-Francois,

I still think we don't need to expose burst-size at all. Is there
any SoC using a different burst-size of 128?

> +
> +Example:
> +
> +i2s1: audio-controller at b4000 {
> +	compatible = "marvell,kirkwood-i2s";
> +	reg =<0xb4000 0x2210>;
> +	interrupts =<21>,<22>;
> +	clocks =<&gate_clk 13>;
> +};
> diff --git a/sound/soc/kirkwood/kirkwood-i2s.c b/sound/soc/kirkwood/kirkwood-i2s.c
> index c74c890..37370b3 100644
> --- a/sound/soc/kirkwood/kirkwood-i2s.c
> +++ b/sound/soc/kirkwood/kirkwood-i2s.c
> @@ -12,7 +12,6 @@
>
>   #include<linux/init.h>
>   #include<linux/module.h>
> -#include<linux/platform_device.h>
>   #include<linux/io.h>
>   #include<linux/slab.h>
>   #include<linux/mbus.h>
> @@ -22,6 +21,8 @@
>   #include<sound/pcm_params.h>
>   #include<sound/soc.h>
>   #include<linux/platform_data/asoc-kirkwood.h>
> +#include<linux/of.h>
> +
>   #include "kirkwood.h"
>
>   #define DRV_NAME	"kirkwood-i2s"
> @@ -457,6 +458,7 @@ static int kirkwood_i2s_dev_probe(struct platform_device *pdev)
>   	struct snd_soc_dai_driver *soc_dai =&kirkwood_i2s_dai;
>   	struct kirkwood_dma_data *priv;
>   	struct resource *mem;
> +	struct device_node *np;

struct device_node *np = pdev->dev.of_node;

and remove the assignment below.

>   	int err;
>
>   	priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
> @@ -482,24 +484,41 @@ static int kirkwood_i2s_dev_probe(struct platform_device *pdev)
>   		return -ENXIO;
>   	}
>
> -	if (!data) {
> -		dev_err(&pdev->dev, "no platform data ?!\n");
> -		return -EINVAL;
> -	}
> +	/* get the DT or static parameters */
> +	np = pdev->dev.of_node;
> +	if (np) {
> +		u32 val;
> +
> +		if (of_property_read_u32(np, "marvell,burst-size",&val)) {
> +			val = 128;		/* default value */
> +		} else if (val != 32&&  val != 128) {
> +			dev_err(&pdev->dev,
> +				"'marvell,burst-size' can be only 32 or 128\n");
> +			return -EINVAL;
> +		}
> +		priv->burst = val;
> +		priv->clk = of_clk_get(np, 0);		/* internal clock */
> +		priv->extclk = of_clk_get(np, 1); /* optional external clock */
> +	} else {
> +		if (!data) {
> +			dev_err(&pdev->dev, "no platform data ?!\n");
> +			return -EINVAL;
> +		}
> +		priv->burst = data->burst;
>
> -	priv->burst = data->burst;
> +		priv->clk = clk_get(&pdev->dev, NULL);
> +		priv->extclk = clk_get(&pdev->dev, "extclk");
> +	}
>
> -	priv->clk = devm_clk_get(&pdev->dev, NULL);
>   	if (IS_ERR(priv->clk)) {
>   		dev_err(&pdev->dev, "no clock\n");
> -		return PTR_ERR(priv->clk);
> +		err = PTR_ERR(priv->clk);
> +		goto error;
>   	}
> -
>   	err = clk_prepare_enable(priv->clk);
>   	if (err<  0)
> -		return err;
> +		goto error;
>
> -	priv->extclk = clk_get(&pdev->dev, "extclk");
>   	if (!IS_ERR(priv->extclk)) {
>   		if (priv->extclk == priv->clk) {
>   			clk_put(priv->extclk);
> @@ -516,7 +535,7 @@ static int kirkwood_i2s_dev_probe(struct platform_device *pdev)
>   	priv->ctl_rec = KIRKWOOD_RECCTL_SIZE_24;
>
>   	/* Select the burst size */
> -	if (data->burst == 32) {
> +	if (priv->burst == 32) {
>   		priv->ctl_play |= KIRKWOOD_PLAYCTL_BURST_32;
>   		priv->ctl_rec |= KIRKWOOD_RECCTL_BURST_32;
>   	} else {
> @@ -528,12 +547,13 @@ static int kirkwood_i2s_dev_probe(struct platform_device *pdev)
>   	if (!err)
>   		return 0;
>   	dev_err(&pdev->dev, "snd_soc_register_dai failed\n");
> -
> +error:
>   	if (!IS_ERR(priv->extclk)) {
>   		clk_disable_unprepare(priv->extclk);
>   		clk_put(priv->extclk);
>   	}
>   	clk_disable_unprepare(priv->clk);
> +	clk_put(priv->clk);
>
>   	return err;
>   }
> @@ -549,16 +569,26 @@ static int kirkwood_i2s_dev_remove(struct platform_device *pdev)
>   		clk_put(priv->extclk);
>   	}
>   	clk_disable_unprepare(priv->clk);
> +	clk_put(priv->clk);
>
>   	return 0;
>   }
>
> +#ifdef CONFIG_OF
> +static struct of_device_id kirkwood_i2s_of_match[] = {
> +	{ .compatible = "marvell,kirkwood-i2s" },
> +	{ }
> +};
> +MODULE_DEVICE_TABLE(of, kirkwood_i2s_of_match);
> +#endif
> +

What about kirkwood-dma? We don't want to have that as another DT node.
IMHO both kirkwood-dma and kirkwood-i2s should be merged into one file,
then dma can be initialized by a common probe function.

Sebastian

>   static struct platform_driver kirkwood_i2s_driver = {
>   	.probe  = kirkwood_i2s_dev_probe,
>   	.remove = kirkwood_i2s_dev_remove,
>   	.driver = {
>   		.name = DRV_NAME,
>   		.owner = THIS_MODULE,
> +		.of_match_table = of_match_ptr(kirkwood_i2s_of_match),
>   	},
>   };
>



From sylvester.nawrocki at gmail.com  Tue Apr  2 17:51:17 2013
From: sylvester.nawrocki at gmail.com (Sylwester Nawrocki)
Date: Tue, 02 Apr 2013 23:51:17 +0200
Subject: [PATCH v4 1/6] drivers: phy: add generic PHY framework
In-Reply-To: <515A0C70.90201@wwwdotorg.org>
References: <1364449408-9510-1-git-send-email-kishon@ti.com>
 <1364449408-9510-2-git-send-email-kishon@ti.com> <515A09D8.7040703@gmail.com>
 <515A0C70.90201@wwwdotorg.org>
Message-ID: <515B52D5.5090709@gmail.com>

On 04/02/2013 12:38 AM, Stephen Warren wrote:
> On 04/01/2013 04:27 PM, Sylwester Nawrocki wrote:
>> On 03/28/2013 06:43 AM, Kishon Vijay Abraham I wrote:
>>> diff --git a/Documentation/devicetree/bindings/phy/phy-bindings.txt
>
>>> +example2:
>>> +phys: phy {
>>> +    compatible = "xxx";
>>> +    reg =<...>;
>>> +    .
>>> +    .
>>> +    phys =<&phys 1>;
>>> +    .
>>> +    .
>>> +};
>>> +
>>> +This node represents a controller that uses one of the PHYs which is defined
>>> +previously. Note that the phy handle has an additional specifier "1" to
>>> +differentiate between the three PHYs. For this case, the controller driver
>>> +should use of_phy_get_with_args/devm_of_phy_get_with_args.
>>
>> This means a PHY user needs to know indexes at the PHY driver ?
>
> The client node's DT has to specify which of the provider's PHYs it
> references, yes. Presumably the device driver for the client node knows
> absolutely nothing about this.

Ah, right. The device driver for the client node not necessarily need to be
aware about this. I think I got misled by the 'index' argument of
of_phy_get_with_args() which the PHY consumer need to supply. However it is
only an index pointing to a PHY specifier in its 'phys' property, hence it
would be normally 0 if the client needs only one PHY. Hopefully I got it
right this time.

>> I have been thinking of using this for an IP which has 4 video PHYs: 2 MIPI
>> CSI-2 and 2 MIPI DSI. The IP has just 2 registers, each of which is shared
>> between one MIPI CSI-2 DPHY and one MIPI DSI DPHY. So I thought about creating
>> a single device node for this IP and using 4 indexes for the PHYs, e.g. 0...3.
>
> That sounds right.
>
>> Then users of each PHY type would use only indexes 0..1 (to select their
>> corresponding port).
>
> I don't follow that. If the provider exports PHYs 0..3, then the client
> nodes would refer to PHYS 0..3 not 0..1.

Indeed, it seems I just wanted to preserve the CSI/DSI "channel" information
(0, 1), but that is not really needed anywhere.

>> However I fail to see how this could now be represented in the bindings.
>
> Exactly like the example you gave below, I would expect.
>
>> I assume struct phy::type could be used to differentiate between CSI-2 and DSI.
>> And struct phy::port could be used to select specific CSI-2 or DSI channel
>> (0, 1). Ideally the phy users should not care about index of a PHY at the PHY
>> device tree node. E.g. there are 2 MIPI CSI-2 receivers and each has only
>> one PHY assigned to it. I'm just wondering how the binding should look like,
>> so a PHY could be associated with a receiver automatically by the phy-core,
>> e.g.
>
> Details such as phy::type and phy::port sounds like internal driver
> implementation details which would have no effect on the bindings.

Yes, I seem to have mixed the phy-core implementation and the bindings a 
bit.
My intention was to have the PHYs registered with phy::port that would 
reflect
data channel id, as specified in the SoC's datasheet. However I can't 
think of
any use of it at the moment, except for debugging purpose.

>> /* DPHY IP node */
>> video-phy {
>>        reg =<0x10000000 8>;
>> };
>>
>> /* MIPI DSI nodes */
>> dsi_0 {
>>       phys =<&video-phy 0>;
>> };
>>
>> dsi_1 {
>>       phys =<&video-phy 1>;
>> };
>>
>> /* MIPI CSI-2 nodes */
>> csi_0 {
>>       phys =<&video-phy 2>;
>> };
>>
>> csi_1 {
>>       phys =<&video-phy 3>;
>> };
>
> That looks correct to me.
>
>> I'm not sure if it is not an overkill to use this the PHY framework with
>> a device which has only 2 registers. Perhaps something less heavy could
>> be designed for it. However, if the PHY framework is commonly used there
>> should be no issue wrt enabling the whole big infrastructure for a simple
>> device like this.
>
> I don't think the number of registers should really makes any
> difference; the whole point of the PHY framework is to decouple to
> providers and consumers, so doing anything custom for special cases
> would completely destroy the ability of the PHY framework to do that.

Ok, that's a very good argument. Something I have not been focused on
that much, given the architecture of hardware I used to work with.

I'll git it a try and I'll see if any any further questions jump out.


From olof at lixom.net  Tue Apr  2 18:11:43 2013
From: olof at lixom.net (Olof Johansson)
Date: Tue, 2 Apr 2013 15:11:43 -0700
Subject: [GIT PULL] Preparatory GIC patches for arm64 support
In-Reply-To: <20130402180339.GJ25867@quad.lixom.net>
References: <20130328140239.GF24039@arm.com>
 <20130402180339.GJ25867@quad.lixom.net>
Message-ID: <CAOesGMhoaXqCOYLu0mYbcRtcwch0Lr4FKi+14vudWw0BU+Gciw@mail.gmail.com>

On Tue, Apr 2, 2013 at 11:03 AM, Olof Johansson <olof at lixom.net> wrote:
> On Thu, Mar 28, 2013 at 02:02:39PM +0000, Catalin Marinas wrote:
>> Hi,
>>
>> As I'm about to go on holiday for two weeks and I haven't heard any
>> preference for who should be merging these patches, I'm sending the pull
>> request to arm-soc given that 90% of the changes target SoC code. Apart
>> from the gic_secondary_init() patch, the rest is trivial header code
>> moving around or removal.
>>
>> Russell, if you have any objections, please let arm-soc guys and me know
>> and feel free to pull these patches via your tree. I don't mind either
>> way.
>>
>> Thanks,
>>
>> Catalin
>>
>>
>> The following changes since commit a937536b868b8369b98967929045f1df54234323:
>>
>>   Linux 3.9-rc3 (2013-03-17 15:59:32 -0700)
>>
>> are available in the git repository at:
>>
>>   git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch64.git gic
>
>
> Pulled as gic/cleanup into next/cleanup.
>
> I got a handful of context conflicts due to additions near the old
> secondary_init functions, and one add/add conflict on includes. All trivial to
> resolve.

Tsk. When you removed <asm/mach/irq.h> from irq-vic.c, the implicit
include of linux/irq.h fell out. Clearly you didn't build test this
across arm defconfigs. :P

I've added the following fix on top of the branch you staged:

---


irqchip: vic: add include of linux/irq.h

With the include of <asm/mach/irq.h> removed, the implicit include of
linux/irq.h also disappeared. Add it back.

Signed-off-by: Olof Johansson <olof at lixom.net>

diff --git a/drivers/irqchip/irq-vic.c b/drivers/irqchip/irq-vic.c
index e38cb00..884d11c 100644
--- a/drivers/irqchip/irq-vic.c
+++ b/drivers/irqchip/irq-vic.c
@@ -23,6 +23,7 @@
 #include <linux/init.h>
 #include <linux/list.h>
 #include <linux/io.h>
+#include <linux/irq.h>
 #include <linux/irqdomain.h>
 #include <linux/of.h>
 #include <linux/of_address.h>



-Olof


From soren.brinkmann at xilinx.com  Tue Apr  2 18:36:56 2013
From: soren.brinkmann at xilinx.com (Soren Brinkmann)
Date: Tue, 2 Apr 2013 15:36:56 -0700
Subject: [PATCH] clk: divider: Introduce CLK_DIVIDER_ALLOW_ZERO flag
Message-ID: <397e02df-e5d1-4211-8a44-2ee15cf4188f@DB3EHSMHS005.ehs.local>

Dividers which have CLK_DIVIDER_ONE_BASED set have a redundant state,
being a divider value of zero. Some hardware implementations allow a
zero divider which simply doesn't alter the frequency. I.e. it acts like
a divide by one or bypassing the divider.
This flag is used to handle such HW in the clk-divider model.

Signed-off-by: Soren Brinkmann <soren.brinkmann at xilinx.com>
---
 drivers/clk/clk-divider.c    | 5 +++--
 include/linux/clk-provider.h | 8 +++++++-
 2 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
index 68b4021..6d96741 100644
--- a/drivers/clk/clk-divider.c
+++ b/drivers/clk/clk-divider.c
@@ -109,8 +109,9 @@ static unsigned long clk_divider_recalc_rate(struct clk_hw *hw,
 
 	div = _get_div(divider, val);
 	if (!div) {
-		WARN(1, "%s: Invalid divisor for clock %s\n", __func__,
-						__clk_get_name(hw->clk));
+		WARN(!(divider->flags & CLK_DIVIDER_ALLOW_ZERO),
+			"%s: Zero divisor and CLK_DIVIDER_ALLOW_ZERO not set\n",
+			__clk_get_name(hw->clk));
 		return parent_rate;
 	}
 
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 7f197d7..811426d 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -239,9 +239,14 @@ struct clk_div_table {
  * CLK_DIVIDER_ONE_BASED - by default the divisor is the value read from the
  * 	register plus one.  If CLK_DIVIDER_ONE_BASED is set then the divider is
  * 	the raw value read from the register, with the value of zero considered
- * 	invalid
+ *	invalid, unless CLK_DIVIDER_ALLOW_ZERO is set.
  * CLK_DIVIDER_POWER_OF_TWO - clock divisor is 2 raised to the value read from
  * 	the hardware register
+ * CLK_DIVIDER_ALLOW_ZERO - Allow zero divisors.  For dividers which have
+ *	CLK_DIVIDER_ONE_BASED set, it is possible to end up with a zero divisor.
+ *	Some hardware implementations gracefully handle this case and allow a
+ *	zero divisor by not modifying their input clock
+ *	(divide by one / bypass).
  */
 struct clk_divider {
 	struct clk_hw	hw;
@@ -255,6 +260,7 @@ struct clk_divider {
 
 #define CLK_DIVIDER_ONE_BASED		BIT(0)
 #define CLK_DIVIDER_POWER_OF_TWO	BIT(1)
+#define CLK_DIVIDER_ALLOW_ZERO		BIT(2)
 
 extern const struct clk_ops clk_divider_ops;
 struct clk *clk_register_divider(struct device *dev, const char *name,
-- 
1.8.2




From ulf.hansson at stericsson.com  Tue Apr  2 19:06:24 2013
From: ulf.hansson at stericsson.com (Ulf Hansson)
Date: Wed, 3 Apr 2013 01:06:24 +0200
Subject: [PATCH 0/3] clk: ux500: Add support for ab850x clocks
Message-ID: <1364943987-1338-1-git-send-email-ulf.hansson@stericsson.com>

From: Ulf Hansson <ulf.hansson at linaro.org>

This patchset implements a new clock hw type called sysctrl used for abx500
clocks. It will then setup the first version of clock tree specfic for ab850x.

The new sysctrl clk hw type depends on the ab8500-sysctrl API. The last patch
is a mfd patch which alignes the probe order between the abx500-clk driver and
the ab8500-sysctrl driver.

The intent is to merge the patchset together, preferably through Mike's
clk tree. I would thus try to fetch an ack from Samuel regarding the mfd
patch.

Ulf Hansson (3):
  clk: ux500: Add support for sysctrl clocks
  clk: ux500: abx500: Define clock tree for ab850x
  mfd: ab8500: sysctrl: Initialize driver at arch_initcall

 drivers/clk/ux500/Makefile      |    1 +
 drivers/clk/ux500/abx500-clk.c  |   71 ++++++++++++-
 drivers/clk/ux500/clk-sysctrl.c |  224 +++++++++++++++++++++++++++++++++++++++
 drivers/clk/ux500/clk.h         |   29 +++++
 drivers/mfd/ab8500-sysctrl.c    |    2 +-
 5 files changed, 323 insertions(+), 4 deletions(-)
 create mode 100644 drivers/clk/ux500/clk-sysctrl.c

-- 
1.7.10



From ulf.hansson at stericsson.com  Tue Apr  2 19:06:25 2013
From: ulf.hansson at stericsson.com (Ulf Hansson)
Date: Wed, 3 Apr 2013 01:06:25 +0200
Subject: [PATCH 1/3] clk: ux500: Add support for sysctrl clocks
In-Reply-To: <1364943987-1338-1-git-send-email-ulf.hansson@stericsson.com>
References: <1364943987-1338-1-git-send-email-ulf.hansson@stericsson.com>
Message-ID: <1364943987-1338-2-git-send-email-ulf.hansson@stericsson.com>

From: Ulf Hansson <ulf.hansson at linaro.org>

The abx500 sysctrl clocks are using the ab8500 sysctrl driver to
modify the clock hardware. Sysctrl clocks are represented by a
ab8500 sysctrl register and with a corresponding bitmask.

The sysctrl clocks are slow path clocks, which means clk_prepare
and clk_unprepare will be used to gate|ungate these clocks.

Signed-off-by: Ulf Hansson <ulf.hansson at linaro.org>
---
 drivers/clk/ux500/Makefile      |    1 +
 drivers/clk/ux500/clk-sysctrl.c |  224 +++++++++++++++++++++++++++++++++++++++
 drivers/clk/ux500/clk.h         |   29 +++++
 3 files changed, 254 insertions(+)
 create mode 100644 drivers/clk/ux500/clk-sysctrl.c

diff --git a/drivers/clk/ux500/Makefile b/drivers/clk/ux500/Makefile
index bcc0c11..c6a806e 100644
--- a/drivers/clk/ux500/Makefile
+++ b/drivers/clk/ux500/Makefile
@@ -5,6 +5,7 @@
 # Clock types
 obj-y += clk-prcc.o
 obj-y += clk-prcmu.o
+obj-y += clk-sysctrl.o
 
 # Clock definitions
 obj-y += u8500_clk.o
diff --git a/drivers/clk/ux500/clk-sysctrl.c b/drivers/clk/ux500/clk-sysctrl.c
new file mode 100644
index 0000000..72c826d
--- /dev/null
+++ b/drivers/clk/ux500/clk-sysctrl.c
@@ -0,0 +1,224 @@
+/*
+ * Sysctrl clock implementation for ux500 platform.
+ *
+ * Copyright (C) 2013 ST-Ericsson SA
+ * Author: Ulf Hansson <ulf.hansson at linaro.org>
+ *
+ * License terms: GNU General Public License (GPL) version 2
+ */
+
+#include <linux/clk-provider.h>
+#include <linux/clk-private.h>
+#include <linux/mfd/abx500/ab8500-sysctrl.h>
+#include <linux/device.h>
+#include <linux/slab.h>
+#include <linux/delay.h>
+#include <linux/io.h>
+#include <linux/err.h>
+#include "clk.h"
+
+#define SYSCTRL_MAX_NUM_PARENTS 4
+
+#define to_clk_sysctrl(_hw) container_of(_hw, struct clk_sysctrl, hw)
+
+struct clk_sysctrl {
+	struct clk_hw hw;
+	struct device *dev;
+	u8 parent_index;
+	u16 reg_sel[SYSCTRL_MAX_NUM_PARENTS];
+	u8 reg_mask[SYSCTRL_MAX_NUM_PARENTS];
+	u8 reg_bits[SYSCTRL_MAX_NUM_PARENTS];
+	unsigned long rate;
+	unsigned long enable_delay_us;
+};
+
+/* Sysctrl clock operations. */
+
+static int clk_sysctrl_prepare(struct clk_hw *hw)
+{
+	int ret;
+	struct clk_sysctrl *clk = to_clk_sysctrl(hw);
+
+	ret = ab8500_sysctrl_write(clk->reg_sel[0], clk->reg_mask[0],
+				clk->reg_bits[0]);
+
+	if (!ret && clk->enable_delay_us)
+		usleep_range(clk->enable_delay_us, clk->enable_delay_us);
+
+	return ret;
+}
+
+static void clk_sysctrl_unprepare(struct clk_hw *hw)
+{
+	struct clk_sysctrl *clk = to_clk_sysctrl(hw);
+	if (ab8500_sysctrl_clear(clk->reg_sel[0], clk->reg_mask[0]))
+		dev_err(clk->dev, "clk_sysctrl: %s fail to clear %s.\n",
+			__func__, __clk_get_name(hw->clk));
+}
+
+static unsigned long clk_sysctrl_recalc_rate(struct clk_hw *hw,
+					unsigned long parent_rate)
+{
+	struct clk_sysctrl *clk = to_clk_sysctrl(hw);
+	return clk->rate;
+}
+
+static int clk_sysctrl_set_parent(struct clk_hw *hw, u8 index)
+{
+	struct clk_sysctrl *clk = to_clk_sysctrl(hw);
+	u8 old_index = clk->parent_index;
+	int ret = 0;
+
+	if (clk->reg_sel[old_index]) {
+		ret = ab8500_sysctrl_clear(clk->reg_sel[old_index],
+					clk->reg_mask[old_index]);
+		if (ret)
+			return ret;
+	}
+
+	if (clk->reg_sel[index]) {
+		ret = ab8500_sysctrl_write(clk->reg_sel[index],
+					clk->reg_mask[index],
+					clk->reg_bits[index]);
+		if (ret) {
+			if (clk->reg_sel[old_index])
+				ab8500_sysctrl_write(clk->reg_sel[old_index],
+						clk->reg_mask[old_index],
+						clk->reg_bits[old_index]);
+			return ret;
+		}
+	}
+	clk->parent_index = index;
+
+	return ret;
+}
+
+static u8 clk_sysctrl_get_parent(struct clk_hw *hw)
+{
+	struct clk_sysctrl *clk = to_clk_sysctrl(hw);
+	return clk->parent_index;
+}
+
+static struct clk_ops clk_sysctrl_gate_ops = {
+	.prepare = clk_sysctrl_prepare,
+	.unprepare = clk_sysctrl_unprepare,
+};
+
+static struct clk_ops clk_sysctrl_gate_fixed_rate_ops = {
+	.prepare = clk_sysctrl_prepare,
+	.unprepare = clk_sysctrl_unprepare,
+	.recalc_rate = clk_sysctrl_recalc_rate,
+};
+
+static struct clk_ops clk_sysctrl_set_parent_ops = {
+	.set_parent = clk_sysctrl_set_parent,
+	.get_parent = clk_sysctrl_get_parent,
+};
+
+static struct clk *clk_reg_sysctrl(struct device *dev,
+				const char *name,
+				const char **parent_names,
+				u8 num_parents,
+				u16 *reg_sel,
+				u8 *reg_mask,
+				u8 *reg_bits,
+				unsigned long rate,
+				unsigned long enable_delay_us,
+				unsigned long flags,
+				struct clk_ops *clk_sysctrl_ops)
+{
+	struct clk_sysctrl *clk;
+	struct clk_init_data clk_sysctrl_init;
+	struct clk *clk_reg;
+	int i;
+
+	if (!dev)
+		return ERR_PTR(-EINVAL);
+
+	if (!name || (num_parents > SYSCTRL_MAX_NUM_PARENTS)) {
+		dev_err(dev, "clk_sysctrl: invalid arguments passed\n");
+		return ERR_PTR(-EINVAL);
+	}
+
+	clk = devm_kzalloc(dev, sizeof(struct clk_sysctrl), GFP_KERNEL);
+	if (!clk) {
+		dev_err(dev, "clk_sysctrl: could not allocate clk\n");
+		return ERR_PTR(-ENOMEM);
+	}
+
+	for (i = 0; i < num_parents; i++) {
+		clk->reg_sel[i] = reg_sel[i];
+		clk->reg_bits[i] = reg_bits[i];
+		clk->reg_mask[i] = reg_mask[i];
+	}
+
+	clk->parent_index = 0;
+	clk->rate = rate;
+	clk->enable_delay_us = enable_delay_us;
+	clk->dev = dev;
+
+	clk_sysctrl_init.name = name;
+	clk_sysctrl_init.ops = clk_sysctrl_ops;
+	clk_sysctrl_init.flags = flags;
+	clk_sysctrl_init.parent_names = parent_names;
+	clk_sysctrl_init.num_parents = num_parents;
+	clk->hw.init = &clk_sysctrl_init;
+
+	clk_reg = devm_clk_register(clk->dev, &clk->hw);
+	if (IS_ERR_OR_NULL(clk_reg)) {
+		dev_err(dev, "clk_sysctrl: clk_register failed\n");
+		return ERR_PTR(-ENOMEM);
+	}
+
+	return clk_reg;
+}
+
+struct clk *clk_reg_sysctrl_gate(struct device *dev,
+				const char *name,
+				const char *parent_name,
+				u16 reg_sel,
+				u8 reg_mask,
+				u8 reg_bits,
+				unsigned long enable_delay_us,
+				unsigned long flags)
+{
+	const char **parent_names = (parent_name ? &parent_name : NULL);
+	u8 num_parents = (parent_name ? 1 : 0);
+
+	return clk_reg_sysctrl(dev, name, parent_names, num_parents,
+			&reg_sel, &reg_mask, &reg_bits, 0, enable_delay_us,
+			flags, &clk_sysctrl_gate_ops);
+}
+
+struct clk *clk_reg_sysctrl_gate_fixed_rate(struct device *dev,
+					const char *name,
+					const char *parent_name,
+					u16 reg_sel,
+					u8 reg_mask,
+					u8 reg_bits,
+					unsigned long rate,
+					unsigned long enable_delay_us,
+					unsigned long flags)
+{
+	const char **parent_names = (parent_name ? &parent_name : NULL);
+	u8 num_parents = (parent_name ? 1 : 0);
+
+	return clk_reg_sysctrl(dev, name, parent_names, num_parents,
+			&reg_sel, &reg_mask, &reg_bits,
+			rate, enable_delay_us, flags,
+			&clk_sysctrl_gate_fixed_rate_ops);
+}
+
+struct clk *clk_reg_sysctrl_set_parent(struct device *dev,
+				const char *name,
+				const char **parent_names,
+				u8 num_parents,
+				u16 *reg_sel,
+				u8 *reg_mask,
+				u8 *reg_bits,
+				unsigned long flags)
+{
+	return clk_reg_sysctrl(dev, name, parent_names, num_parents,
+			reg_sel, reg_mask, reg_bits, 0, 0, flags,
+			&clk_sysctrl_set_parent_ops);
+}
diff --git a/drivers/clk/ux500/clk.h b/drivers/clk/ux500/clk.h
index c3e4491..3d2dfdc 100644
--- a/drivers/clk/ux500/clk.h
+++ b/drivers/clk/ux500/clk.h
@@ -11,6 +11,7 @@
 #define __UX500_CLK_H
 
 #include <linux/clk.h>
+#include <linux/device.h>
 
 struct clk *clk_reg_prcc_pclk(const char *name,
 			      const char *parent_name,
@@ -57,4 +58,32 @@ struct clk *clk_reg_prcmu_opp_volt_scalable(const char *name,
 					    unsigned long rate,
 					    unsigned long flags);
 
+struct clk *clk_reg_sysctrl_gate(struct device *dev,
+				 const char *name,
+				 const char *parent_name,
+				 u16 reg_sel,
+				 u8 reg_mask,
+				 u8 reg_bits,
+				 unsigned long enable_delay_us,
+				 unsigned long flags);
+
+struct clk *clk_reg_sysctrl_gate_fixed_rate(struct device *dev,
+					    const char *name,
+					    const char *parent_name,
+					    u16 reg_sel,
+					    u8 reg_mask,
+					    u8 reg_bits,
+					    unsigned long rate,
+					    unsigned long enable_delay_us,
+					    unsigned long flags);
+
+struct clk *clk_reg_sysctrl_set_parent(struct device *dev,
+				       const char *name,
+				       const char **parent_names,
+				       u8 num_parents,
+				       u16 *reg_sel,
+				       u8 *reg_mask,
+				       u8 *reg_bits,
+				       unsigned long flags);
+
 #endif /* __UX500_CLK_H */
-- 
1.7.10



From ulf.hansson at stericsson.com  Tue Apr  2 19:06:26 2013
From: ulf.hansson at stericsson.com (Ulf Hansson)
Date: Wed, 3 Apr 2013 01:06:26 +0200
Subject: [PATCH 2/3] clk: ux500: abx500: Define clock tree for ab850x
In-Reply-To: <1364943987-1338-1-git-send-email-ulf.hansson@stericsson.com>
References: <1364943987-1338-1-git-send-email-ulf.hansson@stericsson.com>
Message-ID: <1364943987-1338-3-git-send-email-ulf.hansson@stericsson.com>

From: Ulf Hansson <ulf.hansson at linaro.org>

The patch setups the first version of the clock tree for ab850x, which
is used by u8500 platforms. Mainly sysctrl clocks are used.

Signed-off-by: Ulf Hansson <ulf.hansson at linaro.org>
---
 drivers/clk/ux500/abx500-clk.c |   71 ++++++++++++++++++++++++++++++++++++++--
 1 file changed, 68 insertions(+), 3 deletions(-)

diff --git a/drivers/clk/ux500/abx500-clk.c b/drivers/clk/ux500/abx500-clk.c
index 9f7400d..a0fca00 100644
--- a/drivers/clk/ux500/abx500-clk.c
+++ b/drivers/clk/ux500/abx500-clk.c
@@ -12,13 +12,78 @@
 #include <linux/device.h>
 #include <linux/platform_device.h>
 #include <linux/mfd/abx500/ab8500.h>
-
-/* TODO: Add clock implementations here */
-
+#include <linux/mfd/abx500/ab8500-sysctrl.h>
+#include <linux/clk.h>
+#include <linux/clkdev.h>
+#include <linux/clk-provider.h>
+#include <linux/mfd/dbx500-prcmu.h>
+#include "clk.h"
 
 /* Clock definitions for ab8500 */
 static int ab8500_reg_clks(struct device *dev)
 {
+	int ret;
+	struct clk *clk;
+
+	const char *intclk_parents[] = {"ab8500_sysclk", "ulpclk"};
+	u16 intclk_reg_sel[] = {0 , AB8500_SYSULPCLKCTRL1};
+	u8 intclk_reg_mask[] = {0 , AB8500_SYSULPCLKCTRL1_SYSULPCLKINTSEL_MASK};
+	u8 intclk_reg_bits[] = {
+		0 ,
+		(1 << AB8500_SYSULPCLKCTRL1_SYSULPCLKINTSEL_SHIFT)
+	};
+
+	dev_info(dev, "register clocks for ab850x\n");
+
+	/* Enable SWAT */
+	ret = ab8500_sysctrl_set(AB8500_SWATCTRL, AB8500_SWATCTRL_SWATENABLE);
+	if (ret)
+		return ret;
+
+	/* ab8500_sysclk */
+	clk = clk_reg_prcmu_gate("ab8500_sysclk", NULL, PRCMU_SYSCLK,
+				CLK_IS_ROOT);
+	clk_register_clkdev(clk, "sysclk", "ab8500-usb.0");
+	clk_register_clkdev(clk, "sysclk", "ab-iddet.0");
+	clk_register_clkdev(clk, "sysclk", "ab85xx-codec.0");
+	clk_register_clkdev(clk, "sysclk", "shrm_bus");
+
+	/* ab8500_sysclk2 */
+	clk = clk_reg_sysctrl_gate(dev , "ab8500_sysclk2", "ab8500_sysclk",
+		AB8500_SYSULPCLKCTRL1, AB8500_SYSULPCLKCTRL1_SYSCLKBUF2REQ,
+		AB8500_SYSULPCLKCTRL1_SYSCLKBUF2REQ, 0, 0);
+	clk_register_clkdev(clk, "sysclk", "0-0070");
+
+	/* ab8500_sysclk3 */
+	clk = clk_reg_sysctrl_gate(dev , "ab8500_sysclk3", "ab8500_sysclk",
+		AB8500_SYSULPCLKCTRL1, AB8500_SYSULPCLKCTRL1_SYSCLKBUF3REQ,
+		AB8500_SYSULPCLKCTRL1_SYSCLKBUF3REQ, 0, 0);
+	clk_register_clkdev(clk, "sysclk", "cg1960_core.0");
+
+	/* ab8500_sysclk4 */
+	clk = clk_reg_sysctrl_gate(dev , "ab8500_sysclk4", "ab8500_sysclk",
+		AB8500_SYSULPCLKCTRL1, AB8500_SYSULPCLKCTRL1_SYSCLKBUF4REQ,
+		AB8500_SYSULPCLKCTRL1_SYSCLKBUF4REQ, 0, 0);
+
+	/* ab_ulpclk */
+	clk = clk_reg_sysctrl_gate_fixed_rate(dev, "ulpclk", NULL,
+		AB8500_SYSULPCLKCTRL1, AB8500_SYSULPCLKCTRL1_ULPCLKREQ,
+		AB8500_SYSULPCLKCTRL1_ULPCLKREQ,
+		38400000, 9000, CLK_IS_ROOT);
+	clk_register_clkdev(clk, "ulpclk", "ab85xx-codec.0");
+
+	/* ab8500_intclk */
+	clk = clk_reg_sysctrl_set_parent(dev , "intclk", intclk_parents, 2,
+		intclk_reg_sel, intclk_reg_mask, intclk_reg_bits, 0);
+	clk_register_clkdev(clk, "intclk", "ab85xx-codec.0");
+	clk_register_clkdev(clk, NULL, "ab8500-pwm.1");
+
+	/* ab8500_audioclk */
+	clk = clk_reg_sysctrl_gate(dev , "audioclk", "intclk",
+		AB8500_SYSULPCLKCTRL1, AB8500_SYSULPCLKCTRL1_AUDIOCLKENA,
+		AB8500_SYSULPCLKCTRL1_AUDIOCLKENA, 0, 0);
+	clk_register_clkdev(clk, "audioclk", "ab85xx-codec.0");
+
 	return 0;
 }
 
-- 
1.7.10



From ulf.hansson at stericsson.com  Tue Apr  2 19:06:27 2013
From: ulf.hansson at stericsson.com (Ulf Hansson)
Date: Wed, 3 Apr 2013 01:06:27 +0200
Subject: [PATCH 3/3] mfd: ab8500: sysctrl: Initialize driver at arch_initcall
In-Reply-To: <1364943987-1338-1-git-send-email-ulf.hansson@stericsson.com>
References: <1364943987-1338-1-git-send-email-ulf.hansson@stericsson.com>
Message-ID: <1364943987-1338-4-git-send-email-ulf.hansson@stericsson.com>

From: Ulf Hansson <ulf.hansson at linaro.org>

The abx500-clk driver is initiated at arch_initcall level. Moreover it
is relying on the ab8500-sysctrl API to be available. Therefore move
ab8500-sysctrl to arch_initcall level as well. The device is already
added before the abx500 clk device, thus it will be probed before as
well, which is exactly what we want.

Signed-off-by: Ulf Hansson <ulf.hansson at linaro.org>
Cc: Samuel Ortiz <sameo at linux.intel.com>
---
 drivers/mfd/ab8500-sysctrl.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mfd/ab8500-sysctrl.c b/drivers/mfd/ab8500-sysctrl.c
index 108fd86..3b65053 100644
--- a/drivers/mfd/ab8500-sysctrl.c
+++ b/drivers/mfd/ab8500-sysctrl.c
@@ -166,7 +166,7 @@ static int __init ab8500_sysctrl_init(void)
 {
 	return platform_driver_register(&ab8500_sysctrl_driver);
 }
-subsys_initcall(ab8500_sysctrl_init);
+arch_initcall(ab8500_sysctrl_init);
 
 MODULE_AUTHOR("Mattias Nilsson <mattias.i.nilsson at stericsson.com");
 MODULE_DESCRIPTION("AB8500 system control driver");
-- 
1.7.10



From swarren at wwwdotorg.org  Tue Apr  2 19:17:43 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Tue, 02 Apr 2013 17:17:43 -0600
Subject: [PATCHv4 RESEND 0/6] arm: vt8500: Add support for pinctrl/gpio
 module
In-Reply-To: <1364877661-26086-1-git-send-email-linux@prisktech.co.nz>
References: <1364877661-26086-1-git-send-email-linux@prisktech.co.nz>
Message-ID: <515B6717.1060602@wwwdotorg.org>

On 04/01/2013 10:40 PM, Tony Prisk wrote:
> Sorry - got Linus W's email address wrong in first send.
> 
> v4 changes:
> Changed as requested by Stephen Warren:
> Corrected the range checking in of_property_read_u32_index().
> Fix configs[0] assignment in wmt_pctl_dt_node_to_map_pull().
> Move the platform memory mapping from per-soc to common init.
> Drop the custom .of_xlate function and use the default of_gpio_simple_xlate.

Those changes all look fine.

> Remove the kfree(maps) call, and use devm_kzalloc to simplify the fail path.

I'm not sure that's a good idea.

The issue is that dt_node_to_maps() is called every time a pinctrl
consumer is probed, whereas the devm_kzalloc() call in dt_node_to_maps()
uses the pinctrl device itself, not the pinctrl consumer device.. Each
client's probe() could be deferred a few times. Hence, you may end up
accumulating all those map entries from the deferred probes, until the
pinctrl driver itself is remove()d. Similarly, if you unload/load a
(pinctrl client) driver module over and over, the same thing will happen.

Oh, and you left the following in there too:

> +static void wmt_pctl_dt_free_map(struct pinctrl_dev *pctldev,

> +	kfree(maps);



From marex at denx.de  Tue Apr  2 19:18:42 2013
From: marex at denx.de (Marek Vasut)
Date: Wed, 3 Apr 2013 01:18:42 +0200
Subject: [PATCH V2 01/12] spi/mxs: Always set LOCK_CS
In-Reply-To: <1364905195-24286-1-git-send-email-tpiepho@gmail.com>
References: <1364905195-24286-1-git-send-email-tpiepho@gmail.com>
Message-ID: <201304030118.42976.marex@denx.de>

Dear Trent Piepho,

> There are two bits which control the CS line in the CTRL0 register:
> LOCK_CS and IGNORE_CRC.  The latter would be better named DEASSERT_CS
> in SPI mode.
> 
> LOCK_CS keeps CS asserted though the entire transfer.  This should
> always be set.  The DMA code will always set it, explicitly on the
> first segment of the first transfer, and then implicitly on all the
> rest by never clearing the bit from the value read from the ctrl0
> register.
> 
> The only reason to not set LOCK_CS would be to attempt an altered
> protocol where CS pulses between each word.  Though don't get your
> hopes up if you want to do this, as the hardware doesn't appear to do
> this in any sane manner.

Can you please elaborate on this part above? The description is very vague.

Fabio, can you review this too please?

> The code can be simplified by just setting LOCK_CS once and then not
> needing to deal with it in the PIO and DMA transfer functions.
> 
> Signed-off-by: Trent Piepho <tpiepho at gmail.com>
> Cc: Marek Vasut <marex at denx.de>
> Cc: Fabio Estevam <fabio.estevam at freescale.com>
> Cc: Shawn Guo <shawn.guo at linaro.org>
> ---
>  drivers/spi/spi-mxs.c |    8 ++------
>  1 file changed, 2 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/spi/spi-mxs.c b/drivers/spi/spi-mxs.c
> index 22a0af0..9334167 100644
> --- a/drivers/spi/spi-mxs.c
> +++ b/drivers/spi/spi-mxs.c
> @@ -91,6 +91,8 @@ static int mxs_spi_setup_transfer(struct spi_device *dev,
> 
>  	mxs_ssp_set_clk_rate(ssp, hz);
> 
> +	writel(BM_SSP_CTRL0_LOCK_CS,
> +		ssp->base + HW_SSP_CTRL0 + STMP_OFFSET_REG_SET);
>  	writel(BF_SSP_CTRL1_SSP_MODE(BV_SSP_CTRL1_SSP_MODE__SPI) |
>  		     BF_SSP_CTRL1_WORD_LENGTH
>  		     (BV_SSP_CTRL1_WORD_LENGTH__EIGHT_BITS) |
> @@ -159,8 +161,6 @@ static inline void mxs_spi_enable(struct mxs_spi *spi)
>  {
>  	struct mxs_ssp *ssp = &spi->ssp;
> 
> -	writel(BM_SSP_CTRL0_LOCK_CS,
> -		ssp->base + HW_SSP_CTRL0 + STMP_OFFSET_REG_SET);
>  	writel(BM_SSP_CTRL0_IGNORE_CRC,
>  		ssp->base + HW_SSP_CTRL0 + STMP_OFFSET_REG_CLR);
>  }
> @@ -169,8 +169,6 @@ static inline void mxs_spi_disable(struct mxs_spi *spi)
>  {
>  	struct mxs_ssp *ssp = &spi->ssp;
> 
> -	writel(BM_SSP_CTRL0_LOCK_CS,
> -		ssp->base + HW_SSP_CTRL0 + STMP_OFFSET_REG_CLR);
>  	writel(BM_SSP_CTRL0_IGNORE_CRC,
>  		ssp->base + HW_SSP_CTRL0 + STMP_OFFSET_REG_SET);
>  }
> @@ -244,8 +242,6 @@ static int mxs_spi_txrx_dma(struct mxs_spi *spi, int
> cs, ctrl0 &= ~BM_SSP_CTRL0_XFER_COUNT;
>  	ctrl0 |= BM_SSP_CTRL0_DATA_XFER | mxs_spi_cs_to_reg(cs);
> 
> -	if (*first)
> -		ctrl0 |= BM_SSP_CTRL0_LOCK_CS;
>  	if (!write)
>  		ctrl0 |= BM_SSP_CTRL0_READ;

Best regards,
Marek Vasut


From marex at denx.de  Tue Apr  2 19:24:30 2013
From: marex at denx.de (Marek Vasut)
Date: Wed, 3 Apr 2013 01:24:30 +0200
Subject: [PATCH V2 03/12] spi/mxs: Change flag arguments in txrx functions
 to bit flags
In-Reply-To: <1364905195-24286-3-git-send-email-tpiepho@gmail.com>
References: <1364905195-24286-1-git-send-email-tpiepho@gmail.com>
 <1364905195-24286-3-git-send-email-tpiepho@gmail.com>
Message-ID: <201304030124.30625.marex@denx.de>

Dear Trent Piepho,

> There are three flag arguments to the PIO and DMA txrx functions.  Two
> are passed as pointers to integers, even though they are input only
> and not modified, which makes no sense to do.  The third is passed as
> an integer.
> 
> The compiler must use an argument register or stack variable for each
> flag this way.  By using bitflags in a single flag argument more
> efficient and smaller code is produced since all the flags can fit in
> a single register.  And all the flag arguments get cumbersome,
> especially when more are added for things like GPIO chipselects.
> 
> The "first" flag is never used, so can just be deleted.
> 
> The "last" flag is renamed to DEASSERT_CS, since that's really what it
> does.  The spi_transfer cs_change flag means that CS might be
> de-asserted on a transfer which is not last and not de-assert on the
> last transfer, so it is not which transfer is the last we need to know
> but rather the transfers which after which CS should be de-asserted.
> 
> This also extends the driver to not ignore cs_change when setting the
> DEASSERT_CS nee "last" flag.
> 
> Signed-off-by: Trent Piepho <tpiepho at gmail.com>
> Cc: Marek Vasut <marex at denx.de>
> Cc: Fabio Estevam <fabio.estevam at freescale.com>
> Cc: Shawn Guo <shawn.guo at linaro.org>
> ---
>  drivers/spi/spi-mxs.c |   55
> ++++++++++++++++++++++++++++--------------------- 1 file changed, 31
> insertions(+), 24 deletions(-)
> 
> diff --git a/drivers/spi/spi-mxs.c b/drivers/spi/spi-mxs.c
> index 7eb4bc9..3064304 100644
> --- a/drivers/spi/spi-mxs.c
> +++ b/drivers/spi/spi-mxs.c
> @@ -58,6 +58,13 @@
> 
>  #define SG_MAXLEN		0xff00
> 
> +/*
> + * Flags for txrx functions.  More efficient that using an argument
> register for + * each one.
> + */
> +#define TXRX_WRITE		1	/* This is a write */
> +#define TXRX_DEASSERT_CS	2	/* De-assert CS at end of txrx */
> +

Use (1 << n) here as these are bitfield flags.

[...]

> @@ -409,10 +418,9 @@ static int mxs_spi_transfer_one(struct spi_master
> *master, if (status)
>  			break;
> 
> -		if (&t->transfer_list == m->transfers.next)
> -			first = 1;
> -		if (&t->transfer_list == m->transfers.prev)
> -			last = 1;
> +		/* De-assert on last transfer, inverted by cs_change flag */
> +		flag = (&t->transfer_list == m->transfers.prev) ^ t->cs_change ?
> +		       TXRX_DEASSERT_CS : 0;

Make this into an if-else block, this really is hard to parse at first glance.

>  		if ((t->rx_buf && t->tx_buf) || (t->rx_dma && t->tx_dma)) {
>  			dev_err(ssp->dev,
>  				"Cannot send and receive simultaneously\n");
[...]


From mturquette at linaro.org  Tue Apr  2 19:26:36 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Tue, 02 Apr 2013 16:26:36 -0700
Subject: [PATCH 1/3] clk: ux500: Add support for sysctrl clocks
In-Reply-To: <1364943987-1338-2-git-send-email-ulf.hansson@stericsson.com>
References: <1364943987-1338-1-git-send-email-ulf.hansson@stericsson.com>
 <1364943987-1338-2-git-send-email-ulf.hansson@stericsson.com>
Message-ID: <20130402232636.8177.41113@quantum>

Quoting Ulf Hansson (2013-04-02 16:06:25)
> From: Ulf Hansson <ulf.hansson at linaro.org>
> 
> The abx500 sysctrl clocks are using the ab8500 sysctrl driver to
> modify the clock hardware. Sysctrl clocks are represented by a
> ab8500 sysctrl register and with a corresponding bitmask.
> 
> The sysctrl clocks are slow path clocks, which means clk_prepare
> and clk_unprepare will be used to gate|ungate these clocks.
> 
> Signed-off-by: Ulf Hansson <ulf.hansson at linaro.org>
> ---
>  drivers/clk/ux500/Makefile      |    1 +
>  drivers/clk/ux500/clk-sysctrl.c |  224 +++++++++++++++++++++++++++++++++++++++
>  drivers/clk/ux500/clk.h         |   29 +++++
>  3 files changed, 254 insertions(+)
>  create mode 100644 drivers/clk/ux500/clk-sysctrl.c
> 
> diff --git a/drivers/clk/ux500/Makefile b/drivers/clk/ux500/Makefile
> index bcc0c11..c6a806e 100644
> --- a/drivers/clk/ux500/Makefile
> +++ b/drivers/clk/ux500/Makefile
> @@ -5,6 +5,7 @@
>  # Clock types
>  obj-y += clk-prcc.o
>  obj-y += clk-prcmu.o
> +obj-y += clk-sysctrl.o
>  
>  # Clock definitions
>  obj-y += u8500_clk.o
> diff --git a/drivers/clk/ux500/clk-sysctrl.c b/drivers/clk/ux500/clk-sysctrl.c
> new file mode 100644
> index 0000000..72c826d
> --- /dev/null
> +++ b/drivers/clk/ux500/clk-sysctrl.c
> @@ -0,0 +1,224 @@
> +/*
> + * Sysctrl clock implementation for ux500 platform.
> + *
> + * Copyright (C) 2013 ST-Ericsson SA
> + * Author: Ulf Hansson <ulf.hansson at linaro.org>
> + *
> + * License terms: GNU General Public License (GPL) version 2
> + */
> +
> +#include <linux/clk-provider.h>
> +#include <linux/clk-private.h>

I think the above header accidentally slipped in.

Regards,
Mike


From ezequiel.garcia at free-electrons.com  Tue Apr  2 19:23:23 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Tue, 2 Apr 2013 20:23:23 -0300
Subject: [PATCH v2 1/4] thermal: Add driver for Armada 370/XP SoC thermal
 management
In-Reply-To: <1364907910.2190.37.camel@rzhang1-mobl4>
References: <1364292988-8358-1-git-send-email-ezequiel.garcia@free-electrons.com>
 <1364292988-8358-2-git-send-email-ezequiel.garcia@free-electrons.com>
 <1364435017.2275.20.camel@rzhang1-mobl4>
 <20130402013740.GA28373@localhost>
 <1364907910.2190.37.camel@rzhang1-mobl4>
Message-ID: <20130402232322.GB2222@localhost>

On Tue, Apr 02, 2013 at 09:05:10PM +0800, Zhang Rui wrote:
> On Mon, 2013-04-01 at 22:37 -0300, Ezequiel Garcia wrote:
> > Hi Zhang,
> > 
> > On Thu, Mar 28, 2013 at 09:43:37AM +0800, Zhang Rui wrote:
> > > On Tue, 2013-03-26 at 07:16 -0300, Ezequiel Garcia wrote:
> > > > This driver supports both Armada 370 and Armada XP SoC
> > > > thermal management controllers.
> > > > 
> > > > Armada 370 has a register to check a valid temperature, whereas
> > > > Armada XP does not. Each has a different initialization (i.e. calibration)
> > > > function. The temperature conversion formula is the same for both.
> > > > 
> > > > The controller present in each SoC have a very similar feature set,
> > > > so it corresponds to have one driver to support both of them.
> > > > 
> > > > Although this driver may present similarities to Dove and Kirkwood
> > > > thermal driver, the exact differences and coincidences are not fully
> > > > known. For this reason, support is given through a separate driver.
> > > > 
> > > > Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
> 
> patch applied.
> 

Great, thank you! Which branch have you applied this?

-- 
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com


From marex at denx.de  Tue Apr  2 19:29:41 2013
From: marex at denx.de (Marek Vasut)
Date: Wed, 3 Apr 2013 01:29:41 +0200
Subject: [PATCH V2 05/12] spi/mxs: Fix chip select control bits in DMA mode
In-Reply-To: <1364905195-24286-5-git-send-email-tpiepho@gmail.com>
References: <1364905195-24286-1-git-send-email-tpiepho@gmail.com>
 <1364905195-24286-5-git-send-email-tpiepho@gmail.com>
Message-ID: <201304030129.41380.marex@denx.de>

Dear Trent Piepho,

> In DMA mode the chip select control bits would be ORed into the CTRL0
> register without first clearing the bits.  This means that after
> addressing slave 1 the bit would be still be set when addressing slave
> 0, resulting in slave 1 continuing to be addressed.
> 
> The message handing function would pass the cs value to the txrx
> function, which would re-program the bits on each transfer in the
> message.  The selected cs does not change during a message so this is
> inefficient.  It also means there are two different sets of code for
> selecting the CS, one for PIO that worked and one for DMA that didn't.
> 
> Change the code to set the CS bits in the message transfer function
> once.  Now the DMA and PIO txrx functions don't need to care about CS
> at all.
> 
> Signed-off-by: Trent Piepho <tpiepho at gmail.com>
> Cc: Marek Vasut <marex at denx.de>
> Cc: Fabio Estevam <fabio.estevam at freescale.com>
> Cc: Shawn Guo <shawn.guo at linaro.org>

[...]

> @@ -409,9 +396,12 @@ static int mxs_spi_transfer_one(struct spi_master
> *master, struct spi_transfer *t, *tmp_t;
>  	unsigned int flag;
>  	int status = 0;
> -	int cs;
> 
> -	cs = m->spi->chip_select;
> +	/* Program CS register bits here, it will be used for all transfers. */
> +	writel(BM_SSP_CTRL0_WAIT_FOR_CMD | BM_SSP_CTRL0_WAIT_FOR_IRQ,
> +	       ssp->base + HW_SSP_CTRL0 + STMP_OFFSET_REG_CLR);
> +	writel(mxs_spi_cs_to_reg(m->spi->chip_select),
> +	       ssp->base + HW_SSP_CTRL0 + STMP_OFFSET_REG_SET);

I have no problem with this patch in general, but put this stuff back into a 
function with proper description stating that these bits are not what their name 
means. Having this stuff in the code just like that looks like hell and is 
absolutely not clear about what it really does. Besides, having such things well 
encapsulated makes further hacking on/maintainance of the driver much easier.

>  	list_for_each_entry_safe(t, tmp_t, &m->transfers, transfer_list) {
> 

[...]
Best regards,
Marek Vasut


From marex at denx.de  Tue Apr  2 19:31:37 2013
From: marex at denx.de (Marek Vasut)
Date: Wed, 3 Apr 2013 01:31:37 +0200
Subject: [PATCH V2 08/12] spi/mxs: Fix race in setup method
In-Reply-To: <1364905195-24286-8-git-send-email-tpiepho@gmail.com>
References: <1364905195-24286-1-git-send-email-tpiepho@gmail.com>
 <1364905195-24286-8-git-send-email-tpiepho@gmail.com>
Message-ID: <201304030131.37782.marex@denx.de>

Dear Trent Piepho,

> Despite many warnings in the SPI documentation and code, the spi-mxs
> driver sets shared chip registers in the ->setup method.  This method can
> be called when transfers are in progress on other slaves controlled by the
> master.  Setting registers or any other shared state will corrupt those
> transfers.
> 
> So fix mxs_spi_setup() to not call mxs_spi_setup_transfer().
> 
> Signed-off-by: Trent Piepho <tpiepho at gmail.com>
> Cc: Marek Vasut <marex at denx.de>
> Cc: Fabio Estevam <fabio.estevam at freescale.com>
> Cc: Shawn Guo <shawn.guo at linaro.org>
> ---
>  drivers/spi/spi-mxs.c |   11 +++--------
>  1 file changed, 3 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/spi/spi-mxs.c b/drivers/spi/spi-mxs.c
> index 103c478..2a2147a 100644
> --- a/drivers/spi/spi-mxs.c
> +++ b/drivers/spi/spi-mxs.c
> @@ -115,21 +115,16 @@ static int mxs_spi_setup_transfer(struct spi_device
> *dev,
> 
>  static int mxs_spi_setup(struct spi_device *dev)
>  {
> -	int err = 0;
> -
>  	if (!dev->bits_per_word)
>  		dev->bits_per_word = 8;
> 
>  	if (dev->mode & ~(SPI_CPOL | SPI_CPHA))
>  		return -EINVAL;
> 
> -	err = mxs_spi_setup_transfer(dev, NULL);
> -	if (err) {
> -		dev_err(&dev->dev,
> -			"Failed to setup transfer, error = %d\n", err);
> -	}
> +	if (dev->bits_per_word != 8)
> +		return -EINVAL;

What's this new addition doing here?

btw. I was under the impression the MXS SSP block can handle other word-widths 
than 8 bit, no ?

Best regards,
Marek Vasut


From marex at denx.de  Tue Apr  2 19:35:08 2013
From: marex at denx.de (Marek Vasut)
Date: Wed, 3 Apr 2013 01:35:08 +0200
Subject: [PATCH V2 10/12] spi/mxs: Clean up setup_transfer function
In-Reply-To: <1364905195-24286-10-git-send-email-tpiepho@gmail.com>
References: <1364905195-24286-1-git-send-email-tpiepho@gmail.com>
 <1364905195-24286-10-git-send-email-tpiepho@gmail.com>
Message-ID: <201304030135.09072.marex@denx.de>

Dear Trent Piepho,

> It can't be called with a NULL transfer anymore so it can be
> simplified to not check for that.
> 
> Change printouts to more closely match what the spi core would print.
> I.e., don't print function names.  Try to make them clearer.
> 
> Fix indention of line-wrapped code to Linux standard.
> 
> The transfer pointer can be const.
> 
> It's not necessary to check if the spi_transfer's bit per word is
> zero.  The spi core automatically inserts the spi_device's bits per
> word in that case.
> 
> It's not necessary to check if the spi_transfer's speed_hz is zero, as
> the spi core also fills it in from the spi_device.  However, the spi
> core does not check if spi_device's speed is zero so we have to do
> that still.
> 
> Signed-off-by: Trent Piepho <tpiepho at gmail.com>
> Cc: Marek Vasut <marex at denx.de>
> Cc: Fabio Estevam <fabio.estevam at freescale.com>
> Cc: Shawn Guo <shawn.guo at linaro.org>

Ok, this is again combining cleanup and fixup/feature changes. You know what to 
do by now.

btw it might be nice to reorder the series so that cleanups go in first as 
they're easy and fixes afterwards.

Best regards,
Marek Vasut


From marex at denx.de  Tue Apr  2 19:38:38 2013
From: marex at denx.de (Marek Vasut)
Date: Wed, 3 Apr 2013 01:38:38 +0200
Subject: [PATCH V2 11/12] spi/mxs: Don't set clock for each xfer
In-Reply-To: <1364905195-24286-11-git-send-email-tpiepho@gmail.com>
References: <1364905195-24286-1-git-send-email-tpiepho@gmail.com>
 <1364905195-24286-11-git-send-email-tpiepho@gmail.com>
Message-ID: <201304030138.38609.marex@denx.de>

Dear Trent Piepho,

> mxs_spi_setup_transfer() would set the SSP SCK rate every time it was
> called, which is before each transfer.  It is uncommon for the SCK rate to
> change between transfers and this causes unnecessary reprogramming of the
> clock registers.  Changed to only set the rate when it has changed.
> 
> This significantly speeds up short SPI messages, especially messages made
> up of many transfers.  On an iMX287, using spidev with messages that
> consist of 511 transfers of 4 bytes each at an SCK of 48 MHz, the
> effective transfer rate more than doubles from about 290 KB/sec to 600
> KB/sec.
> 
> Signed-off-by: Trent Piepho <tpiepho at gmail.com>
> Cc: Marek Vasut <marex at denx.de>
> Cc: Fabio Estevam <fabio.estevam at freescale.com>
> Cc: Shawn Guo <shawn.guo at linaro.org>
> ---
>  drivers/spi/spi-mxs.c |   15 ++++++++++++++-
>  1 file changed, 14 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/spi/spi-mxs.c b/drivers/spi/spi-mxs.c
> index a7d5f85..12794ea 100644
> --- a/drivers/spi/spi-mxs.c
> +++ b/drivers/spi/spi-mxs.c
> @@ -68,6 +68,7 @@
>  struct mxs_spi {
>  	struct mxs_ssp		ssp;
>  	struct completion	c;

Stick the comment here.

> +	unsigned int		sck;	/* Rate requested (vs actual) */
>  };
> 
>  static int mxs_spi_setup_transfer(struct spi_device *dev,
> @@ -88,7 +89,19 @@ static int mxs_spi_setup_transfer(struct spi_device
> *dev, return -EINVAL;
>  	}
> 
> -	mxs_ssp_set_clk_rate(ssp, hz);
> +	if (hz != spi->sck) {
> +		mxs_ssp_set_clk_rate(ssp, hz);
> +		/*
> +		 * Save requested value, not actual value from ssp->clk_rate.
> +		 * Otherwise we would set the rate again each trasfer when
> +		 * actual is not quite the same as requested.
> +		 */
> +		spi->sck = hz;
> +		/*
> +		 * Perhaps we should return an error if the actual clock is
> +		 * nowhere close to what was requested?
> +		 */

Maybe you want to check the ssp->ssp_clk vs. hz indeed.

> +	}
> 
>  	writel(BM_SSP_CTRL0_LOCK_CS,
>  		ssp->base + HW_SSP_CTRL0 + STMP_OFFSET_REG_SET);

Best regards,
Marek Vasut


From marex at denx.de  Tue Apr  2 19:39:32 2013
From: marex at denx.de (Marek Vasut)
Date: Wed, 3 Apr 2013 01:39:32 +0200
Subject: [PATCH 1/5] spi/mxs: Fix extra CS pulses and read mode in
 multi-transfer messages
In-Reply-To: <CA+7tXii8xhZQeKU2dTN26LxySNXhJT9NgRXcJ21cOX64qYj1NA@mail.gmail.com>
References: <1364570381-17605-1-git-send-email-tpiepho@gmail.com>
 <201304021232.12736.marex@denx.de>
 <CA+7tXii8xhZQeKU2dTN26LxySNXhJT9NgRXcJ21cOX64qYj1NA@mail.gmail.com>
Message-ID: <201304030139.33190.marex@denx.de>

Dear Trent Piepho,

> On Tue, Apr 2, 2013 at 3:32 AM, Marek Vasut <marex at denx.de> wrote:
> >> Don't see anything in CodingStyle that one should be preferred over
> >> the other.
> > 
> > There ain't any I'm aware of, but to paraphrase you, let's keep the
> > format that's already used in the driver ;-) :
> > 
> > 114         if (dev->mode & ~(SPI_CPOL | SPI_CPHA))
> 
> Thanks for pointing that out, as that code can be deleted.  Which
> means I don't need to be consistent with it anymore and can create a
> new standard, to be followed henceforth, now and forever.
> 
> But it looks like the or method is more common in the kernel code.  So
> I'll change it in V2.
> 
> >> > btw. are you using MX23 or MX28 to test this?
> >> 
> >> IMX28.
> > 
> > Is that any mainline board?
> 
> Nope, custom hardware.
> 
> >> >> Existing code that uses the first/last flags is wrong and needs to be
> >> >> changed.  Therefor code using 'first' and 'last' will be changed.
> >> >> 
> >> >> Passing the flags as pointers is bad practice and makes no sense to
> >> >> do.  Does it make any sense to re-write code fix the way it uses
> >> >> first and last, then re-write those same lines a second time to not
> >> >> use pointers?
> >> > 
> >> > You can always flip it the other way -- first rework the use of flags,
> >> > then apply the fix. It'd make the patch much easier to understand,
> >> > don't you think?
> >> 
> >> So I should change 'first' to not be a pointer to an integer in one
> >> patch, then delete the flag entirely in another patch?
> > 
> > I'd say make a patch (0001) that implements the transition to using your
> > newly defined flags and then make a patch (0002) that "Fix extra CS
> > pulses and read mode in multi-transfer messages". One patch shall do one
> > thing, that's the usual rule of the thumb. Obviously keep them in a
> > series if these patches shall go in together. And why doesn't squashing
> > them all together work you might ask -- because reviewing the result is
> > hard.
> 
> 5 patches have now been split into 12.

Much better, yes.

Best regards,
Marek Vasut


From robherring2 at gmail.com  Tue Apr  2 19:42:05 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Tue, 02 Apr 2013 18:42:05 -0500
Subject: [PATCHv4 1/6] of: Add support for reading a u32 from a multi-value
 property.
In-Reply-To: <1364877661-26086-2-git-send-email-linux@prisktech.co.nz>
References: <1364877661-26086-1-git-send-email-linux@prisktech.co.nz>
 <1364877661-26086-2-git-send-email-linux@prisktech.co.nz>
Message-ID: <515B6CCD.9060703@gmail.com>

On 04/01/2013 11:40 PM, Tony Prisk wrote:
> This patch adds an of_property_read_u32_index() function to allow
> reading a single indexed u32 value from a property containing multiple
> u32 values.
> 
> Signed-off-by: Tony Prisk <linux at prisktech.co.nz>
> Reviewed-by: Stephen Warren <swarren at nvidia.com>
> ---
>  drivers/of/base.c  |   33 +++++++++++++++++++++++++++++++++
>  include/linux/of.h |    9 +++++++++
>  2 files changed, 42 insertions(+)
> 
> diff --git a/drivers/of/base.c b/drivers/of/base.c
> index 321d3ef..f6c89ed 100644
> --- a/drivers/of/base.c
> +++ b/drivers/of/base.c
> @@ -746,6 +746,39 @@ struct device_node *of_find_node_by_phandle(phandle handle)
>  EXPORT_SYMBOL(of_find_node_by_phandle);
>  
>  /**
> + * of_property_read_u32_index - Find and read a u32 from a multi-value property.
> + *
> + * @np:		device node from which the property value is to be read.
> + * @propname:	name of the property to be searched.
> + * @index:	index of the u32 in the list of values
> + * @out_value:	pointer to return value, modified only if no error.
> + *
> + * Search for a property in a device node and read nth 32-bit value from
> + * it. Returns 0 on success, -EINVAL if the property does not exist,
> + * -ENODATA if property does not have a value, and -EOVERFLOW if the
> + * property data isn't large enough.
> + *
> + * The out_value is modified only if a valid u32 value can be decoded.
> + */
> +int of_property_read_u32_index(const struct device_node *np,
> +				       const char *propname,
> +				       u32 index, u32 *out_value)
> +{
> +	struct property *prop = of_find_property(np, propname, NULL);
> +
> +	if (!prop)
> +		return -EINVAL;
> +	if (!prop->value)
> +		return -ENODATA;
> +	if (((index + 1) * sizeof(*out_value)) > prop->length)
> +		return -EOVERFLOW;

Yet another copy of almost the same code...

Can you re-factor things to do something like this:

diff --git a/drivers/of/base.c b/drivers/of/base.c
index 321d3ef..482d29c 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -745,6 +745,21 @@ struct device_node *of_find_node_by_phandle(phandle handle)
 }
 EXPORT_SYMBOL(of_find_node_by_phandle);
 
+static void *of_find_property_value_of_size(const struct device_node *np,
+			const char *propname, u32 len)
+{
+	struct property *prop = of_find_property(np, propname, NULL);
+
+	if (!prop)
+		return -EINVAL;
+	if (!prop->value)
+		return -ENODATA;
+	if (len > prop->length)
+		return -EOVERFLOW;
+
+	return prop->value;
+}
+
 /**
  * of_property_read_u8_array - Find and read an array of u8 from a property.
  *
@@ -766,17 +781,11 @@ EXPORT_SYMBOL(of_find_node_by_phandle);
 int of_property_read_u8_array(const struct device_node *np,
 			const char *propname, u8 *out_values, size_t sz)
 {
-	struct property *prop = of_find_property(np, propname, NULL);
-	const u8 *val;
+	const u8 *val = of_find_property_value_of_size(np, propname, sz * sizeof(*out_values));
 
-	if (!prop)
-		return -EINVAL;
-	if (!prop->value)
-		return -ENODATA;
-	if ((sz * sizeof(*out_values)) > prop->length)
-		return -EOVERFLOW;
+	if (IS_ERR(val))
+		return PTR_ERR(val);
 
-	val = prop->value;
 	while (sz--)
 		*out_values++ = *val++;
 	return 0;


> +	*out_value = be32_to_cpup(((__be32 *)prop->value) + index);
> +	return 0;
> +}
> +EXPORT_SYMBOL_GPL(of_property_read_u32_index);
> +
> +/**
>   * of_property_read_u8_array - Find and read an array of u8 from a property.
>   *
>   * @np:		device node from which the property value is to be read.
> diff --git a/include/linux/of.h b/include/linux/of.h
> index a0f1292..c0747a4 100644
> --- a/include/linux/of.h
> +++ b/include/linux/of.h
> @@ -235,6 +235,9 @@ extern struct device_node *of_find_node_with_property(
>  extern struct property *of_find_property(const struct device_node *np,
>  					 const char *name,
>  					 int *lenp);
> +extern int of_property_read_u32_index(const struct device_node *np,
> +				       const char *propname,
> +				       u32 index, u32 *out_value);
>  extern int of_property_read_u8_array(const struct device_node *np,
>  			const char *propname, u8 *out_values, size_t sz);
>  extern int of_property_read_u16_array(const struct device_node *np,
> @@ -394,6 +397,12 @@ static inline struct device_node *of_find_compatible_node(
>  	return NULL;
>  }
>  
> +static inline int of_property_read_u32_index(const struct device_node *np,
> +			const char *propname, u32 index, u32 *out_value)
> +{
> +	return -ENOSYS;
> +}
> +
>  static inline int of_property_read_u8_array(const struct device_node *np,
>  			const char *propname, u8 *out_values, size_t sz)
>  {
> 



From mturquette at linaro.org  Tue Apr  2 19:46:48 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Tue, 02 Apr 2013 16:46:48 -0700
Subject: [PATCH v4] clk: add si5351 i2c common clock driver
In-Reply-To: <1364050010-23919-1-git-send-email-sebastian.hesselbarth@gmail.com>
References: <1363603397-2762-1-git-send-email-sebastian.hesselbarth@gmail.com>
 <1364050010-23919-1-git-send-email-sebastian.hesselbarth@gmail.com>
Message-ID: <20130402234648.8177.86213@quantum>

Quoting Sebastian Hesselbarth (2013-03-23 07:46:50)
> diff --git a/drivers/clk/clk-si5351.c b/drivers/clk/clk-si5351.c
> new file mode 100644
> index 0000000..9d0c210
> --- /dev/null
> +++ b/drivers/clk/clk-si5351.c
> @@ -0,0 +1,1411 @@
> +/*
> + * clk-si5351.c: Silicon Laboratories Si5351A/B/C I2C Clock Generator
> + *
> + * Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
> + * Rabeeh Khoury <rabeeh at solid-run.com>
> + *
> + * References:
> + * [1] "Si5351A/B/C Data Sheet"
> + *     http://www.silabs.com/Support%20Documents/TechnicalDocs/Si5351.pdf
> + * [2] "Manually Generating an Si5351 Register Map"
> + *     http://www.silabs.com/Support%20Documents/TechnicalDocs/AN619.pdf
> + *
> + * 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.
> + */
> +
> +#include <linux/module.h>
> +#include <linux/kernel.h>
> +#include <linux/clk-private.h>

I hope that this is supposed to be clk-provider.h.  I don't plan on
taking in any more clock drivers that depend on clk-private.h.  I didn't
see any reason for this patch to not use clk-provider.h.

Regards,
Mike


From mturquette at linaro.org  Tue Apr  2 19:51:18 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Tue, 02 Apr 2013 16:51:18 -0700
Subject: [PATCH 1/1] clk: fix clk_mux::flags kerneldoc
In-Reply-To: <1364222107-1079-1-git-send-email-james.hogan@imgtec.com>
References: <1364222107-1079-1-git-send-email-james.hogan@imgtec.com>
Message-ID: <20130402235118.8177.72734@quantum>

Quoting James Hogan (2013-03-25 07:35:07)
> The kerneldoc comment for struct clk_mux documented the non-existent
> num_clks instead of flags. Correct this.
> 
> Signed-off-by: James Hogan <james.hogan at imgtec.com>

Thanks for the fix.  Taken into clk-next.

Regards,
Mike

> ---
>  include/linux/clk-provider.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
> index cdad3ce..e7504d5 100644
> --- a/include/linux/clk-provider.h
> +++ b/include/linux/clk-provider.h
> @@ -276,7 +276,7 @@ struct clk *clk_register_divider_table(struct device *dev, const char *name,
>   * @reg:       register controlling multiplexer
>   * @shift:     shift to multiplexer bit field
>   * @width:     width of mutliplexer bit field
> - * @num_clks:  number of parent clocks
> + * @flags:     hardware-specific flags
>   * @lock:      register lock
>   *
>   * Clock with multiple selectable parents.  Implements .get_parent, .set_parent
> -- 
> 1.8.1.2


From kuninori.morimoto.gx at renesas.com  Tue Apr  2 20:08:55 2013
From: kuninori.morimoto.gx at renesas.com (Kuninori Morimoto)
Date: Tue, 02 Apr 2013 17:08:55 -0700 (PDT)
Subject: [PATCH 1/2] ARM: shmobile: R8A7779: add Ether support
In-Reply-To: <515AC546.90905@cogentembedded.com>
References: <201304020204.54546.sergei.shtylyov@cogentembedded.com>
 <87wqsl6ale.wl%kuninori.morimoto.gx@renesas.com>
 <515AC546.90905@cogentembedded.com>
Message-ID: <87txnocw6n.wl%kuninori.morimoto.gx@renesas.com>


Hi Sergei

> > Then, this (void *pdata) should be
> > (struct sh_eth_plat_data *pdata) IMO
> 
>     ether_device.dev.platform_data is 'void *'. I didn't want to bring in 
> extra header for the little use.

Not enough reason for me.

"void *" means there is no pointer check,
and extra header is just 1 line. No ?

If you want to use this style,
then, additional extra header is fate, IMO

Best regards
---
Kuninori Morimoto


From marex at denx.de  Tue Apr  2 20:20:25 2013
From: marex at denx.de (Marek Vasut)
Date: Wed,  3 Apr 2013 02:20:25 +0200
Subject: [PATCH] pinctrl: imx5: fix SD2_DATA1 pad AUDMUX_AUD4 configuration
Message-ID: <1364948425-15372-1-git-send-email-marex@denx.de>

The IOMUXC_AUDMUX_P4_INPUT_TXCLK_AMX_SELECT_INPUT must be configured as 1
instead of 0 to have AUD4 muxed on SD2 pins working.

Signed-off-by: Marek Vasut <marex at denx.de>
Cc: Fabio Estevam <fabio.estevam at freescale.com>
Cc: Linus Walleij <linus.walleij at linaro.org>
Cc: Philipp Zabel <p.zabel at pengutronix.de>
Cc: Shawn Guo <shawn.guo at linaro.org>
---
 arch/arm/boot/dts/imx53-pinfunc.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/imx53-pinfunc.h b/arch/arm/boot/dts/imx53-pinfunc.h
index 1362060..aec406b 100644
--- a/arch/arm/boot/dts/imx53-pinfunc.h
+++ b/arch/arm/boot/dts/imx53-pinfunc.h
@@ -1073,7 +1073,7 @@
 #define MX53_PAD_SD2_DATA1__ESDHC2_DAT1				0x30c 0x698 0x000 0x0 0x0
 #define MX53_PAD_SD2_DATA1__GPIO1_14				0x30c 0x698 0x000 0x1 0x0
 #define MX53_PAD_SD2_DATA1__KPP_COL_7				0x30c 0x698 0x848 0x2 0x1
-#define MX53_PAD_SD2_DATA1__AUDMUX_AUD4_TXFS			0x30c 0x698 0x744 0x3 0x0
+#define MX53_PAD_SD2_DATA1__AUDMUX_AUD4_TXFS			0x30c 0x698 0x744 0x3 0x1
 #define MX53_PAD_SD2_DATA1__CSPI_SS0				0x30c 0x698 0x78c 0x5 0x4
 #define MX53_PAD_SD2_DATA1__RTIC_SEC_VIO			0x30c 0x698 0x000 0x7 0x0
 #define MX53_PAD_SD2_DATA0__ESDHC2_DAT0				0x310 0x69c 0x000 0x0 0x0
-- 
1.7.10.4



From marex at denx.de  Tue Apr  2 20:21:18 2013
From: marex at denx.de (Marek Vasut)
Date: Wed, 3 Apr 2013 02:21:18 +0200
Subject: [PATCH] pinctrl: imx5: fix SD2_DATA1 pad AUDMUX_AUD4 configuration
In-Reply-To: <20130402114323.GE24039@S2101-09.ap.freescale.net>
References: <1364882642-25574-1-git-send-email-marex@denx.de>
 <20130402114323.GE24039@S2101-09.ap.freescale.net>
Message-ID: <201304030221.18506.marex@denx.de>

Dear Shawn Guo,

> Marek,
> 
> On Tue, Apr 02, 2013 at 08:04:02AM +0200, Marek Vasut wrote:
> > The IOMUXC_AUDMUX_P4_INPUT_TXCLK_AMX_SELECT_INPUT must be configured as 1
> > instead of 0 to have AUD4 muxed on SD2 pins working.
> > 
> > Signed-off-by: Marek Vasut <marex at denx.de>
> > Cc: Fabio Estevam <fabio.estevam at freescale.com>
> > Cc: Linus Walleij <linus.walleij at linaro.org>
> > Cc: Philipp Zabel <p.zabel at pengutronix.de>
> > Cc: Shawn Guo <shawn.guo at linaro.org>
> > ---
> > 
> >  drivers/pinctrl/pinctrl-imx53.c |    2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > NOTE: Shawn, we might want this in -stable too ?
> 
> I have queued patch b466af3 (pinctrl: imx: move hard-coding data into
> device tree) on my imx/dt branch to remove these tables from pinctrl
> drivers.
> 
> Since there is no in-tree users for MX53_PAD_SD2_DATA1__AUDMUX_AUD4_TXFS,
> and we're moving away from it, can we just patch
> arch/arm/boot/dts/imx53-pinfunc.h instead?
> 
> Shawn

One serving of such patch, coming right up ;-)

btw. do you want to apply this one for -stable or do we just leave it as is ?

Best regards,
Marek Vasut


From kuninori.morimoto.gx at renesas.com  Tue Apr  2 20:25:04 2013
From: kuninori.morimoto.gx at renesas.com (Kuninori Morimoto)
Date: Tue, 02 Apr 2013 17:25:04 -0700 (PDT)
Subject: [PATCH 1/2] ARM: shmobile: R8A7779: add Ether support
In-Reply-To: <515AC4C8.1080803@cogentembedded.com>
References: <201304020204.54546.sergei.shtylyov@cogentembedded.com>
 <87y5d16b1d.wl%kuninori.morimoto.gx@renesas.com>
 <515AC4C8.1080803@cogentembedded.com>
Message-ID: <87sj38cvfn.wl%kuninori.morimoto.gx@renesas.com>


Hi Sergei

> > Current ARM SoC is trying to not use platform_device_register()
> > Please use platform_device_register_xxx()
> > Same comment for [2/2]
> 
>     Is there some rationale to it? I don't find platform_device_register_xxx()
> especially handy to use.

http://www.spinics.net/lists/linux-sh/msg16871.html

Best regards
---
Kuninori Morimoto


From olof at lixom.net  Tue Apr  2 20:26:30 2013
From: olof at lixom.net (Olof Johansson)
Date: Tue, 2 Apr 2013 17:26:30 -0700
Subject: [GIT PULL] at91: soc for 3.10 #2
In-Reply-To: <201303271902.00068.arnd@arndb.de>
References: <5152B357.3020500@atmel.com>
	<201303271902.00068.arnd@arndb.de>
Message-ID: <CAOesGMiy7q-xbc0SN78d7cvZmLgywy1PH7_Srw_=pzErSkrt-g@mail.gmail.com>

On Wed, Mar 27, 2013 at 12:01 PM, Arnd Bergmann <arnd at arndb.de> wrote:
> On Wednesday 27 March 2013, Nicolas Ferre wrote:
>
>> ----------------------------------------------------------------
>> Introduction of new Atmel Cortex-A5: SAMA5D3 family.
>> - Modify AT91 Kconfig to plit ARMv4/5 and ARMv7 arch
>> - Modify PMC driver (clocks)
>> - Core SAMA5 support
>> - Board file, DT files and defconfig
>
> Looks really good. Olof said he'd take over merging tomorrow,
> so I'll leave it for him.
>
>> ----------------------------------------------------------------
>> Ludovic Desroches (6):
>>       ARM: at91: change name template in AT91_SOC_START macro
>>       ARM: at91: add AT91_SAM9_TIME entry to select at91sam926x_time.c compilation
>>       ARM: at91: introduce the core type choice to split ARMv4/5 and ARMv7 arch
>>       ARM: at91: introduce SAMA5 support
>>       ARM: at91: dt: add device tree files for SAMA5D3 family
>>       ARM: at91: add defconfig for SAMA5
>
> There is one obvious change that would be nice to include here,
> can you add this on top (either Nicolas or Olof)?
>
> 8<---------
> Subject: ARM: at91: make ATAGS support conditional on CONFIG_ATAGS
>
> We have the global CONFIG_ATAGS symbol that is used to determine
> whether ATAGS based boot is possible or not. Since we are
> splitting out the legacy boards from the main Kconfig on at91,
> we can use that symbol to easily hide the old options.
>
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
>
> diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig
> index 0280238..119a0a4 100644
> --- a/arch/arm/mach-at91/Kconfig
> +++ b/arch/arm/mach-at91/Kconfig
> @@ -137,8 +137,9 @@ config SOC_AT91SAM9N12
>           Select this if you are using Atmel's AT91SAM9N12 SoC.
>
>  # ----------------------------------------------------------
> -
> +if ATAGS
>  source arch/arm/mach-at91/Kconfig.non_dt
> +endif
>  endif # SOC_SAM_V4_V5
>
>  comment "Generic Board Type"

Actually, it's not that simple. With this patch, I get:

arch/arm/Kconfig:1841:error: recursive dependency detected!
arch/arm/Kconfig:1841:  symbol USE_OF is selected by MACH_AT91RM9200_DT
arch/arm/mach-at91/Kconfig:147: symbol MACH_AT91RM9200_DT depends on
SOC_AT91RM9200
arch/arm/mach-at91/Kconfig:74:  symbol SOC_AT91RM9200 is selected by
ARCH_AT91RM9200
arch/arm/mach-at91/Kconfig.non_dt:12:   symbol ARCH_AT91RM9200 is part
of choice <choice>
arch/arm/mach-at91/Kconfig.non_dt:6:    choice <choice> contains symbol <choice>
arch/arm/mach-at91/Kconfig.non_dt:6:    choice <choice> contains symbol ATAGS
arch/arm/Kconfig:1850:  symbol ATAGS depends on USE_OF

Also, USE_OF isn't set at that point (it's controlled by the next
section), so it can't be used as a replacement.

Also, isn't it a bit backwards in the first place to first set ATAGS
vs no-ATAGS, and then get to choose what hardware you want to build
for?

I'll take off the last patch from the branch and re-merge it (since I
hadn't pushed it out yet), the above can be sorted out separately.


-Olof


From mturquette at linaro.org  Tue Apr  2 20:34:50 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Tue, 02 Apr 2013 17:34:50 -0700
Subject: RFC v2: Zynq Clock Controller
In-Reply-To: <9b6821a5-8275-427e-a5aa-1bfd8e800d1b@TX2EHSMHS027.ehs.local>
References: <27dae808-1d3a-4001-8eb2-b0a6e2a34b8f@AM1EHSMHS013.ehs.local>
 <515093B4.2090701@wwwdotorg.org>
 <8fd7278d-37c5-48ff-8d06-edc64d532a96@VA3EHSMHS037.ehs.local>
 <5150DEB6.7070208@wwwdotorg.org>
 <b810d127-dad8-447c-bf88-8ac715debbff@CO9EHSMHS026.ehs.local>
 <20130327021844.4014.43809@quantum>
 <9b6821a5-8275-427e-a5aa-1bfd8e800d1b@TX2EHSMHS027.ehs.local>
Message-ID: <20130403003450.8177.2879@quantum>

Quoting S?ren Brinkmann (2013-03-29 15:36:18)
> On Tue, Mar 26, 2013 at 07:18:44PM -0700, Mike Turquette wrote:
> > As long as a key exists to link two clocks together then registration
> > order shouldn't matter.  Originally this key was an immutable clk name
> > string.
> > 
> > If clock parents are specified in DT then that should also suffice, in
> > place of doing string comparisons.
> > 
> > If no key to pair up clocks exists then yes we will have to rely purely
> > on the struct clk *opaque_cookie and register clocks in order.
> Okay, so I guess, the fundamental mechanisms should be in place. What is
> needed, is changing the key from being the clk name to something else.
> And preferably this something else is made up of something available
> through DT, so a child can reference its parent w/o the parent to be
> probed first. E.g. the provider's node name + the index of the clock
> output?

Right, order shouldn't matter in the sense that registering a child
before a parent should not constitute an absolute failure from the clock
framework point of view.

Folks using DT today still rely on the parent string name to link things
up.  Grep around for usage of of_clk_get_parent_name to see how several
platforms use that during registration.

> You mentioned, something like this was supposed to happen anyway, right?
> Do you already have something specific in mind/are working on a
> solution?
> 

I'm not looking at it currently.  If no one else gets around to it then
eventually I will.  It would be nice to not have to use
of_clk_get_parent_name and instead have a better way to establish
parent-child relationships at clock registration-time for DT clocks.

Regards,
Mike

>         S?ren


From mturquette at linaro.org  Tue Apr  2 20:38:30 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Tue, 02 Apr 2013 17:38:30 -0700
Subject: [PATCH] clk: divider: Use DIV_ROUND_CLOSEST
In-Reply-To: <4b6b9df8-e221-4e52-82d3-efdcd5de9bd1@AM1EHSMHS021.ehs.local>
References: <20130320001609.8663.21043@quantum>
 <f3ff0545-52cd-4b7b-967e-f81324ba0152@CH1EHSMHS040.ehs.local>
 <20130320185051.GA28349@pengutronix.de>
 <20130321091531.GN20530@pengutronix.de>
 <cffdea50-cadf-4662-a4fb-c61ab853fc4c@VA3EHSMHS014.ehs.local>
 <20130327013703.4014.45615@quantum>
 <4b6b9df8-e221-4e52-82d3-efdcd5de9bd1@AM1EHSMHS021.ehs.local>
Message-ID: <20130403003830.8177.40547@quantum>

Quoting S?ren Brinkmann (2013-04-01 16:24:12)
> On Tue, Mar 26, 2013 at 06:37:03PM -0700, Mike Turquette wrote:
> > Quoting S?ren Brinkmann (2013-03-26 15:45:22)
> > > On Thu, Mar 21, 2013 at 10:15:31AM +0100, Uwe Kleine-K?nig wrote:
> > > > Hello,
> > > > 
> > > > On Wed, Mar 20, 2013 at 07:50:51PM +0100, Sascha Hauer wrote:
> > > > > On Wed, Mar 20, 2013 at 09:32:51AM -0700, S?ren Brinkmann wrote:
> > > > > > If the caller
> > > > > > doesn't like the returned frequency he can request a different one.
> > > > > > And he's eventually happy with the return value he calls
> > > > > > clk_set_rate() requesting the frequency clk_round_rate() returned.
> > > > > > Always rounding down seems a bit odd to me.
> > > > > > 
> > > > > > Another issue with the current implmentation:
> > > > > > clk_divider_round_rate() calls clk_divider_bestdiv(), which uses the ROUND_UP macro, returning a rather low frequency.
> > > > > 
> > > > > And that is correct. clk_divider_bestdiv is used to calculate the
> > > > > maximum parent frequency for which a given divider value does not
> > > > > exceed the desired rate.
> > > > The reason for that is that the (more?) usual constraint is like: This
> > > > mmc card can handle up to 100 MHz. Or this i2c device can handle up to
> > > > this and that frequency. Of course there are different constraints, e.g.
> > > > for a UART if the target baud speed is 38400 you better run at 38402
> > > > than at 19201.
> > > > 
> > > > I wonder if it depends on the clock if you want "best approximation <=
> > > > requested value" or "best approximation" or on the caller. In the former
> > > > case a flag for the clock would be the right thing (as suggested in this
> > > > thread). If however it's the caller of round_rate who knows better which
> > > > rounding is preferred than better extend the clk API.
> > > > 
> > > > Extending the API could just be a convenience function that doesn't
> > > > affect the implementations of the clk API. E.g.:
> > > > 
> > > >       long clk_round_rate_nearest(struct clk *clk, unsigned long rate)
> > > >       {
> > > >               long lower_limit = clk_round_rate(clk, rate);
> > > >               long upper_limit = clk_round_rate(clk, rate + (rate - lower_limit));
> > > > 
> > > >               if (rate - lower_limit < upper_limit - rate)
> > > >                       return lower_limit;
> > > >               else
> > > >                       return upper_limit;
> > > >       }
> > > > 
> > > I guess both approaches may work. Anybody has a preference?
> > > 
> > 
> > A dedicated function like the one Uwe defined is better than adding
> > subtlety to the existing clk_round_rate via a flag in a clock driver.
> I looked at my problem again.
> 
> A new API function is probably fine for UART, ethernet drivers and
> similar. Although, compared to a flag it would add some redundant
> rounding, since clk_set_rate() implicitly also rounds the rate.
>         clk_set_rate()
>                 clk_calc_new_rates()
>                         clk_round_rate()
> But that is true for every driver which doesn't blindly call
> clk_set_rate() and checks upfront through clk_round_rate() what
> the actual frequency would look like.
> 
> So, do we agree to add this additional clk_round_rate_nearest()
> function?

Cc'ing Russell if he has any comments on adding clk_round_rate_nearest,
since he is author of the original clk api.

Regards,
Mike

> And if, should I just make Uwe's proposal another patch, additionally to
> the other clk-divider change I'm working on?
> Or Uwe, do you prefer to submit it yourself?
> 
> 
> For my original problem, though, this is only part of a solution. It
> appeared to be a rounding issue, but the actual root cause is the loss
> of resolution when OPPs are converted to a frequency table for cpufreq.
> I'm not sure how this can be resolved, yet.
> 
> 
>         S?ren


From john.stultz at linaro.org  Tue Apr  2 20:41:37 2013
From: john.stultz at linaro.org (John Stultz)
Date: Tue, 02 Apr 2013 17:41:37 -0700
Subject: [PATCH v2 12/13] ARM: move sp804 and integrator timers to
 drivers/clocksource
In-Reply-To: <515B3637.8090603@gmail.com>
References: <1364854883-5961-1-git-send-email-robherring2@gmail.com>
 <1364854883-5961-13-git-send-email-robherring2@gmail.com>
 <515A179A.8020800@linaro.org> <515B3637.8090603@gmail.com>
Message-ID: <515B7AC1.9090403@linaro.org>

On 04/02/2013 12:49 PM, Rob Herring wrote:
> On 04/01/2013 06:26 PM, John Stultz wrote:
>> On 04/01/2013 03:21 PM, Rob Herring wrote:
>>> diff --git a/drivers/clocksource/integrator_ap_timer.c
>>> b/drivers/clocksource/integrator_ap_timer.c
>>> new file mode 100644
>>> index 0000000..05e6204
>>> --- /dev/null
>>> +++ b/drivers/clocksource/integrator_ap_timer.c
>> [snip]
>
>>> +CLOCKSOURCE_OF_DECLARE(integrator_ap, "integrator-timer",
>>> ap_of_timer_init);
>> So, most of the code here is really clockevent code and not clocksource
>> code. I realize they were combined in the mach directory you're copying
>> them from, but if we're going to move all this code out of the arch
>> directory and into drivers/, I'd like to propose we not dump it all into
>> drivers/clocksource.
> Arguably, half the h/w is used for clocksource and half for clockevent
> so it is equal. :) The sp804 and integrator are somewhat separated that
> carving them up may be possible, but there are examples like i.MX timers
> where the implementations are tied more closely together (the clockevent
> compare value is the clocksource counter + delta).
>
> Where do I put the init functions which need to know about both?

Either have them init themselves via *_initcall, or call out from one to 
the other?

> What about all the other timers that are already in drivers/clocksource?

I'm hoping to start moving those out soon.


>> For more context here see:
>> http://www.spinics.net/lists/arm-kernel/msg234074.html
> Seems like this is more a maintainer issue than necessarily what is the
> right split of code (not that those are completely unrelated). Perhaps
> splitting maintainership between core and drivers is needed. It
> definitely seems Thomas cannot keep up with the plethora of ARM related
> timers and irqchips getting moved into drivers/.

Well, I'm hoping Daniel can help offload Thomas, but I've still not 
heard back if Thomas is ok with this whole proposal or not.

thanks
-john


From mturquette at linaro.org  Tue Apr  2 20:43:32 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Tue, 02 Apr 2013 17:43:32 -0700
Subject: [PATCH] ARM: mvebu: Use common of_clk_init() function
In-Reply-To: <20130402130236.683fa734@armhf>
References: <20130402130236.683fa734@armhf>
Message-ID: <20130403004332.8177.71536@quantum>

Quoting Jean-Francois Moine (2013-04-02 04:02:36)
> The use common of_clk_init() function simplifies the clock initialization
> and adds handling of the DT "fixed-clock".
> 
> Signed-off-by: Jean-Francois Moine <moinejf at free.fr>

This is a nice change.  Taken into clk-next.

Regards,
Mike

> ---
>  drivers/clk/mvebu/clk-cpu.c |   17 ++---------------
>  drivers/clk/mvebu/clk-cpu.h |   22 ----------------------
>  drivers/clk/mvebu/clk.c     |    6 +-----
>  3 files changed, 3 insertions(+), 42 deletions(-)
>  delete mode 100644 drivers/clk/mvebu/clk-cpu.h
> 
> diff --git a/drivers/clk/mvebu/clk-cpu.c b/drivers/clk/mvebu/clk-cpu.c
> index 9dd2551..b0fbc07 100644
> --- a/drivers/clk/mvebu/clk-cpu.c
> +++ b/drivers/clk/mvebu/clk-cpu.c
> @@ -16,7 +16,6 @@
>  #include <linux/io.h>
>  #include <linux/of.h>
>  #include <linux/delay.h>
> -#include "clk-cpu.h"
>  
>  #define SYS_CTRL_CLK_DIVIDER_CTRL_OFFSET    0x0
>  #define SYS_CTRL_CLK_DIVIDER_VALUE_OFFSET   0xC
> @@ -173,17 +172,5 @@ clks_out:
>         kfree(cpuclk);
>  }
>  
> -static const __initconst struct of_device_id clk_cpu_match[] = {
> -       {
> -               .compatible = "marvell,armada-xp-cpu-clock",
> -               .data = of_cpu_clk_setup,
> -       },
> -       {
> -               /* sentinel */
> -       },
> -};
> -
> -void __init mvebu_cpu_clk_init(void)
> -{
> -       of_clk_init(clk_cpu_match);
> -}
> +CLK_OF_DECLARE(armada_xp_cpu_clock, "marvell,armada-xp-cpu-clock",
> +                                        of_cpu_clk_setup);
> diff --git a/drivers/clk/mvebu/clk-cpu.h b/drivers/clk/mvebu/clk-cpu.h
> deleted file mode 100644
> index 08e2aff..0000000
> --- a/drivers/clk/mvebu/clk-cpu.h
> +++ /dev/null
> @@ -1,22 +0,0 @@
> -/*
> - * Marvell MVEBU CPU clock handling.
> - *
> - * Copyright (C) 2012 Marvell
> - *
> - * Gregory CLEMENT <gregory.clement at free-electrons.com>
> - *
> - * 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.
> - */
> -
> -#ifndef __MVEBU_CLK_CPU_H
> -#define __MVEBU_CLK_CPU_H
> -
> -#ifdef CONFIG_MVEBU_CLK_CPU
> -void __init mvebu_cpu_clk_init(void);
> -#else
> -static inline void mvebu_cpu_clk_init(void) {}
> -#endif
> -
> -#endif
> diff --git a/drivers/clk/mvebu/clk.c b/drivers/clk/mvebu/clk.c
> index 855681b..29f10fb 100644
> --- a/drivers/clk/mvebu/clk.c
> +++ b/drivers/clk/mvebu/clk.c
> @@ -10,18 +10,14 @@
>   * warranty of any kind, whether express or implied.
>   */
>  #include <linux/kernel.h>
> -#include <linux/clk.h>
>  #include <linux/clk-provider.h>
> -#include <linux/of_address.h>
> -#include <linux/clk/mvebu.h>
>  #include <linux/of.h>
>  #include "clk-core.h"
> -#include "clk-cpu.h"
>  #include "clk-gating-ctrl.h"
>  
>  void __init mvebu_clocks_init(void)
>  {
>         mvebu_core_clk_init();
>         mvebu_gating_clk_init();
> -       mvebu_cpu_clk_init();
> +       of_clk_init(NULL);
>  }
> -- 
> 1.7.10.4
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From horms at verge.net.au  Tue Apr  2 20:57:09 2013
From: horms at verge.net.au (Simon Horman)
Date: Wed, 3 Apr 2013 09:57:09 +0900
Subject: [GIT PULL] Renesas ARM SoC updates for v3.10 #2
In-Reply-To: <20130402202503.GC8015@quad.lixom.net>
References: <1364879246-9470-1-git-send-email-horms+renesas@verge.net.au>
 <20130402202503.GC8015@quad.lixom.net>
Message-ID: <20130403005707.GA30263@verge.net.au>

On Tue, Apr 02, 2013 at 01:25:03PM -0700, Olof Johansson wrote:
> On Tue, Apr 02, 2013 at 02:06:56PM +0900, Simon Horman wrote:
> > Hi Arnd, Hi Olof,
> > 
> > The following changes since commit 4c82e452732784419fd616cf1acf2bc9b004aae1:
> > 
> >   Merge tag 'renesas-intc-external-irq2-for-v3.10' into soc-base (2013-04-02 10:55:57 +0900)
> > 
> > are available in the git repository at:
> > 
> > 
> >   git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-soc2-for-v3.10
> > 
> > for you to fetch changes up to 8585deb18580d04209a2986430aa0959ef38fce2:
> > 
> >   ARM: shmobile: r8a7790 SoC 64-bit DT support (2013-04-02 11:02:21 +0900)
> > 
> > ----------------------------------------------------------------
> > Second round of Renesas ARM SoC updates for v3.10
> > 
> > Some Highlights:
> > 
> > * Add r8a7790 SoC
> > * Add r8a73a4 SoC
> > * Migrate r8a7740 SoC from INTC to GIC
> > * Add thermal driver support to r8a73a4 SoC
> > * Add irqpin DT nodes to sh73a0 SoC
> > * Add SCIF support to r8a7778 SoC
> > 
> > This pull request is based on a merge of:
> > git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas renesas-soc-for-v3.10
> > git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas renesas-intc-external-irq2-for-v3.10
> 
> Ugh. So, the irq branch depends on the old soc branch, and now this depends on
> the irq branch (and it is soc code). That's a circular dependency.
>
> I'll add this as a next/soc2 branch in arm-soc, but please think about these
> kind of circular dependencies in the future, and try to avoid them if you can
> by splitting the branch contents in separate topics if possible.

Sorry about that. I have been having a bit of trouble managing the
dependencies and some assumptions I made with earlier branches
turned out to be invalid as new patches came in. I'll try to be
more careful in future.

> Likewise, there's a bunch of patches in this branch such as the fixed
> divisor clock patches that could be considered cleanup. Not a big deal to
> group them with the soc code, but if you're already doing cleanup
> branches it'd be just as well to put them in those.

I'm not carrying any cleanup branches at this time.
I will keep in in mind for future patches of this nature.


From horms at verge.net.au  Tue Apr  2 21:34:02 2013
From: horms at verge.net.au (Simon Horman)
Date: Wed, 3 Apr 2013 10:34:02 +0900
Subject: [PATCH 06/28] gpio: Renesas R-Car GPIO driver V3
In-Reply-To: <20130402203305.GD8015@quad.lixom.net>
References: <1364879376-10020-1-git-send-email-horms+renesas@verge.net.au>
 <1364879376-10020-7-git-send-email-horms+renesas@verge.net.au>
 <20130402203305.GD8015@quad.lixom.net>
Message-ID: <20130403013402.GG30263@verge.net.au>

On Tue, Apr 02, 2013 at 01:33:05PM -0700, Olof Johansson wrote:
> On Tue, Apr 02, 2013 at 02:09:14PM +0900, Simon Horman wrote:
> > From: Magnus Damm <damm at opensource.se>
> > 
> > This patch is V3 of a GPIO driver for the R-Car series of
> > SoCs from Renesas. This driver is designed to be reusable
> > between multiple SoCs that share the same basic building block,
> > but so far it has only been used on R-Car H1 (r8a7779).
> > 
> > Each driver instance handles 32 GPIOs with individually
> > maskable IRQs. The driver operates on a single I/O memory
> > range and the 32 GPIOs are hooked up a single interrupt.
> > 
> > In the case of R-Car H1 either external IRQ pins or GPIOs
> > with interrupts can be used for on-board interupts. For
> > external IRQs 4 pins are supported, and in the case of GPIO
> > there are 202 GPIOS as 202 interrupts hooked up via 6 driver
> > instances and to the GIC and the Cortex-A9 Quad.
> > 
> > At this point this driver is interfacing as a regular
> > platform device driver. In the future DT support will be
> > submitted as an incremental feature patch.
> > 
> > Signed-off-by: Magnus Damm <damm at opensource.se>
> > Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
> 
> Hmm, you seem to not be collecting tags on patches or at least missed
> one here. This patch, when posted, got a Reviewed-by from LinusW. I
> caught it mostly since it had no ack (or reviewed) from the subsystem
> maintainer in this case.
> 
> Please rebuild and resend with reviewed/acked tags as you've received
> them, please.

Sorry, I do try to accumulate them but sometimes I miss some.

I will add Linus's Reviewed-by.
I will also check through all the patches in this pull-request
(renesas-pinmux2-for-v3.10).
for missing acks. And I will repost this pull-request.

I will also repost the renesas-boards3-for-v3.10 pull-request after
checking it for missing acks and rebasing it on the new
renesas-pinmux2-for-v3.10.


From olof at lixom.net  Tue Apr  2 21:34:37 2013
From: olof at lixom.net (Olof Johansson)
Date: Tue, 2 Apr 2013 18:34:37 -0700
Subject: [PATCH 06/28] gpio: Renesas R-Car GPIO driver V3
In-Reply-To: <20130403013402.GG30263@verge.net.au>
References: <1364879376-10020-1-git-send-email-horms+renesas@verge.net.au>
 <1364879376-10020-7-git-send-email-horms+renesas@verge.net.au>
 <20130402203305.GD8015@quad.lixom.net>
 <20130403013402.GG30263@verge.net.au>
Message-ID: <CAOesGMjhybNxwBTpm9WCeSGegRL3fNMYqZBHzP7EGeZQ2C--Kw@mail.gmail.com>

On Tue, Apr 2, 2013 at 6:34 PM, Simon Horman <horms at verge.net.au> wrote:
> On Tue, Apr 02, 2013 at 01:33:05PM -0700, Olof Johansson wrote:
>> On Tue, Apr 02, 2013 at 02:09:14PM +0900, Simon Horman wrote:
>> > From: Magnus Damm <damm at opensource.se>
>> >
>> > This patch is V3 of a GPIO driver for the R-Car series of
>> > SoCs from Renesas. This driver is designed to be reusable
>> > between multiple SoCs that share the same basic building block,
>> > but so far it has only been used on R-Car H1 (r8a7779).
>> >
>> > Each driver instance handles 32 GPIOs with individually
>> > maskable IRQs. The driver operates on a single I/O memory
>> > range and the 32 GPIOs are hooked up a single interrupt.
>> >
>> > In the case of R-Car H1 either external IRQ pins or GPIOs
>> > with interrupts can be used for on-board interupts. For
>> > external IRQs 4 pins are supported, and in the case of GPIO
>> > there are 202 GPIOS as 202 interrupts hooked up via 6 driver
>> > instances and to the GIC and the Cortex-A9 Quad.
>> >
>> > At this point this driver is interfacing as a regular
>> > platform device driver. In the future DT support will be
>> > submitted as an incremental feature patch.
>> >
>> > Signed-off-by: Magnus Damm <damm at opensource.se>
>> > Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
>>
>> Hmm, you seem to not be collecting tags on patches or at least missed
>> one here. This patch, when posted, got a Reviewed-by from LinusW. I
>> caught it mostly since it had no ack (or reviewed) from the subsystem
>> maintainer in this case.
>>
>> Please rebuild and resend with reviewed/acked tags as you've received
>> them, please.
>
> Sorry, I do try to accumulate them but sometimes I miss some.
>
> I will add Linus's Reviewed-by.
> I will also check through all the patches in this pull-request
> (renesas-pinmux2-for-v3.10).
> for missing acks. And I will repost this pull-request.
>
> I will also repost the renesas-boards3-for-v3.10 pull-request after
> checking it for missing acks and rebasing it on the new
> renesas-pinmux2-for-v3.10.

Ok, thanks!


-Olof


From horms at verge.net.au  Tue Apr  2 21:36:04 2013
From: horms at verge.net.au (Simon Horman)
Date: Wed, 3 Apr 2013 10:36:04 +0900
Subject: Renesas ARM SoC board updates for v3.10 #3
In-Reply-To: <1364879483-11144-1-git-send-email-horms+renesas@verge.net.au>
References: <1364879483-11144-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <20130403013604.GA7202@verge.net.au>

Hi,

Olof pointed out that there are some attribution problems in
renesas-pinmux2-for-v3.10. I will resolve them, rebase and re-send
this pull request (renesas-boards3-for-v3.10).

On Tue, Apr 02, 2013 at 02:11:12PM +0900, Simon Horman wrote:
> Hi Arnd, Hi Olof,
> 
> The following changes since commit df16da03fc60fcfbc7f4b0cb849f9c1fc956a991:
> 
>   Merge branch 'pinmux' into boards-base (2013-04-02 13:21:54 +0900)
> 
> are available in the git repository at:
> 
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-boards3-for-v3.10
> 
> for you to fetch changes up to b9a2f94954622b8fab222b1029fbfcdbed558b44:
> 
>   ARM: shmobile: mackerel: clean up MMCIF vs. SDHI1 selection (2013-04-02 13:22:54 +0900)
> 
> ----------------------------------------------------------------
> Third round of  Renesas ARM SoC board updates for v3.10
> 
> Highlights:
> 
> * Add Lager board support
> * Add ape6evm board support
> * Add Bock-W board support
> * Mackerel MMCIF/SDHI clean ups
> * Add ethernet support to kzm9g-reference
> 
> This pull request is based on a merge of:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas renesas-pinmux2-for-v3.10
> git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas renesas-boards2-for-v3.10
> 
> ----------------------------------------------------------------
> Guennadi Liakhovetski (6):
>       ARM: shmobile: kzm9g-reference: add ethernet support
>       ARM: shmobile: mackerel: SDHI resources do not have to be numbered
>       ARM: shmobile: mackerel: remove OCR masks, where regulators are used
>       ARM: shmobile: mackerel: switch SDHI and MMCIF interfaces to slot-gpio
>       ARM: shmobile: mackerel: add interrupt names for SDHI0
>       ARM: shmobile: mackerel: clean up MMCIF vs. SDHI1 selection
> 
> Kuninori Morimoto (1):
>       ARM: shmobile: add R-Car M1A Bock-W platform support
> 
> Magnus Damm (4):
>       ARM: shmobile: APE6EVM base support
>       ARM: shmobile: APE6EVM PFC support
>       ARM: shmobile: APE6EVM LAN9220 support
>       ARM: shmobile: Initial r8a7790 Lager board support
> 
>  arch/arm/boot/dts/Makefile                   |    3 +
>  arch/arm/boot/dts/r8a73a4-ape6evm.dts        |   52 ++++++++++++
>  arch/arm/boot/dts/r8a7778-bockw.dts          |   32 ++++++++
>  arch/arm/boot/dts/r8a7790-lager.dts          |   31 +++++++
>  arch/arm/boot/dts/sh73a0-kzm9g-reference.dts |   13 +++
>  arch/arm/configs/bockw_defconfig             |   66 +++++++++++++++
>  arch/arm/mach-shmobile/Kconfig               |   21 ++++-
>  arch/arm/mach-shmobile/Makefile              |    3 +
>  arch/arm/mach-shmobile/board-ape6evm.c       |   94 ++++++++++++++++++++++
>  arch/arm/mach-shmobile/board-bockw.c         |   43 ++++++++++
>  arch/arm/mach-shmobile/board-lager.c         |   46 +++++++++++
>  arch/arm/mach-shmobile/board-mackerel.c      |  111 ++++++++++----------------
>  12 files changed, 443 insertions(+), 72 deletions(-)
>  create mode 100644 arch/arm/boot/dts/r8a73a4-ape6evm.dts
>  create mode 100644 arch/arm/boot/dts/r8a7778-bockw.dts
>  create mode 100644 arch/arm/boot/dts/r8a7790-lager.dts
>  create mode 100644 arch/arm/configs/bockw_defconfig
>  create mode 100644 arch/arm/mach-shmobile/board-ape6evm.c
>  create mode 100644 arch/arm/mach-shmobile/board-bockw.c
>  create mode 100644 arch/arm/mach-shmobile/board-lager.c
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


From olof at lixom.net  Tue Apr  2 21:36:13 2013
From: olof at lixom.net (Olof Johansson)
Date: Tue, 2 Apr 2013 18:36:13 -0700
Subject: [GIT PULL] ARM: LPC32xx: defconfig update
In-Reply-To: <5152B96D.8020103@antcom.de>
References: <5152B96D.8020103@antcom.de>
Message-ID: <20130403013613.GA27874@quad.lixom.net>

On Wed, Mar 27, 2013 at 10:18:37AM +0100, Roland Stigge wrote:
> Hi Arnd and Olof,
> 
> this is the defconfig update for 3.10.
> 
> The signed tag is lpc32xx-defconfig-for-3.10
> 
> The following changes since commit 8bb9660418e05bb1845ac1a2428444d78e322cc7:
> 
>   Linux 3.9-rc4 (2013-03-23 16:52:44 -0700)
> 
> are available in the git repository at:
> 
>   git://git.antcom.de/linux-2.6.git lpc32xx/defconfig

Pulled into next/soc, thanks!


-Olof


From shawn.guo at linaro.org  Tue Apr  2 21:41:39 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Wed, 3 Apr 2013 09:41:39 +0800
Subject: [PATCH V2 01/12] spi/mxs: Always set LOCK_CS
In-Reply-To: <1364905195-24286-1-git-send-email-tpiepho@gmail.com>
References: <1364905195-24286-1-git-send-email-tpiepho@gmail.com>
Message-ID: <20130403014137.GI24039@S2101-09.ap.freescale.net>

On Tue, Apr 02, 2013 at 05:19:44AM -0700, Trent Piepho wrote:
> There are two bits which control the CS line in the CTRL0 register:
> LOCK_CS and IGNORE_CRC.  The latter would be better named DEASSERT_CS
> in SPI mode.
> 
> LOCK_CS keeps CS asserted though the entire transfer.  This should
> always be set.  The DMA code will always set it, explicitly on the
> first segment of the first transfer, and then implicitly on all the
> rest by never clearing the bit from the value read from the ctrl0
> register.
> 
> The only reason to not set LOCK_CS would be to attempt an altered
> protocol where CS pulses between each word.  Though don't get your
> hopes up if you want to do this, as the hardware doesn't appear to do
> this in any sane manner.
> 
> The code can be simplified by just setting LOCK_CS once and then not
> needing to deal with it in the PIO and DMA transfer functions.
> 
> Signed-off-by: Trent Piepho <tpiepho at gmail.com>

Trent,

Just FYI, Mark Brown is taking care of SPI subsystem patches recently.
Please remember copy him on the series when you repost, if you want to
see the series get applied eventually :)

Shawn



From kgene.kim at samsung.com  Tue Apr  2 21:46:08 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Wed, 03 Apr 2013 10:46:08 +0900
Subject: [PATCH] ARM: dts: add usb 2.0 clock references to exynos5250
 device tree
In-Reply-To: <CAFp+6iFXd-4uFfc4v_kWf_FTBmeHkNwsEV0QoyHCzza8evgd9A@mail.gmail.com>
References: <1363195099-15919-1-git-send-email-dianders@chromium.org>
 <006301ce211d$a6caa670$f45ff350$%han@samsung.com>
 <CAFp+6iFXd-4uFfc4v_kWf_FTBmeHkNwsEV0QoyHCzza8evgd9A@mail.gmail.com>
Message-ID: <24ae01ce300d$037af160$0a70d420$%kim@samsung.com>

Vivek Gautam wrote:
> 
> Hi,
> 
> 
> On Fri, Mar 15, 2013 at 7:07 AM, Jingoo Han <jg1.han at samsung.com> wrote:
> >
> > On Thursday, March 14, 2013 2:18 AM, Doug Anderson wrote:
> >>
> >> This is a fixup to two device tree nodes that have already landed but
> >> without clock nodes since the transition to common clock happened at
> >> the same time.
> >>
> >> Signed-off-by: Doug Anderson <dianders at chromium.org>
> >
> > The clock number and name are right.
> >
> > Reviewed-by: Jingoo Han <jg1.han at samsung.com>
> >
> >
> > Best regards,
> > Jingoo Han
> >
> >> ---
> >>  arch/arm/boot/dts/exynos5250.dtsi | 6 ++++++
> >>  1 file changed, 6 insertions(+)
> >>
> >> diff --git a/arch/arm/boot/dts/exynos5250.dtsi
> b/arch/arm/boot/dts/exynos5250.dtsi
> >> index 24c52e6..59be603 100644
> >> --- a/arch/arm/boot/dts/exynos5250.dtsi
> >> +++ b/arch/arm/boot/dts/exynos5250.dtsi
> >> @@ -402,12 +402,18 @@
> >>               compatible = "samsung,exynos4210-ehci";
> >>               reg = <0x12110000 0x100>;
> >>               interrupts = <0 71 0>;
> >> +
> >> +             clocks = <&clock 285>;
> >> +             clock-names = "usbhost";
> >>       };
> >>
> >>       usb at 12120000 {
> >>               compatible = "samsung,exynos4210-ohci";
> >>               reg = <0x12120000 0x100>;
> >>               interrupts = <0 71 0>;
> >> +
> >> +             clocks = <&clock 285>;
> >> +             clock-names = "usbhost";
> 
> tested this patch with smdk5250 h/w.
> 
> Tested-by: Vivek Gautam <gautam.vivek at samsung.com>
> 
Vivek and Jingoo,

Thanks for your review and test.

Looks good to me and I applied in my local.
Just note that this should be seen in my public tree tomorrow night(KST).

- Kukjin



From shawn.guo at linaro.org  Tue Apr  2 21:48:35 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Wed, 3 Apr 2013 09:48:35 +0800
Subject: [PATCH 0/6] Add initial imx6dl support
In-Reply-To: <CAOMZO5D5gD5KQvh885isVV8vKf3p_-rbYb1mYq_N5pp1q24Eag@mail.gmail.com>
References: <1364913079-26039-1-git-send-email-shawn.guo@linaro.org>
 <CAOMZO5D5gD5KQvh885isVV8vKf3p_-rbYb1mYq_N5pp1q24Eag@mail.gmail.com>
Message-ID: <20130403014833.GJ24039@S2101-09.ap.freescale.net>

On Tue, Apr 02, 2013 at 05:52:52PM -0300, Fabio Estevam wrote:
> > Shawn Guo (6):
> >   pinctrl: add pinctrl driver for imx6dl
> 
> I am not able to locate patch 1/6. Do you have a git tree with this
> series applied?

Ah, yes.  The patch exceeds the 100 KB limit and is waiting for
moderator approval.

I just push the series on branch devel/imx6dl.

Shawn



From kpark3469 at gmail.com  Tue Apr  2 22:00:03 2013
From: kpark3469 at gmail.com (Keun-O Park)
Date: Wed, 3 Apr 2013 11:00:03 +0900
Subject: [PATCH] ARM: kprobes: fix test coverage missing failures
In-Reply-To: <1364912353.3650.91.camel@linaro1.home>
References: <1364871884-28252-1-git-send-email-kpark3469@gmail.com>
 <1364912353.3650.91.camel@linaro1.home>
Message-ID: <CA+KhAHaguOmS+iq3URLg2WAROD37cGqni1NC8xbsucKYRf6Mrg@mail.gmail.com>

On Tue, Apr 2, 2013 at 11:19 PM, Jon Medhurst (Tixy) <tixy at linaro.org> wrote:
> On Tue, 2013-04-02 at 12:04 +0900, kpark3469 at gmail.com wrote:
>> From: Sahara <keun-o.park at windriver.com>
>>
>> If kprobe tests run on ARMv6k or ARMv6, there're a number of test
>> coverage missing failures like:
>
> The tests only fail (return an error code) for the coverage tests when
> compiled for ARMv7 because, obviously, that's the only architecture that
> can cover all the combinations of instructions. Perhaps we should just
> disabled the coverage tests pre-ARMv7 kernels to avoid the noisy output
> you see.
>
> I think the best way to look at it is that the coverage tests are test
> code for the test code, and should only be of concern to people updating
> the test code.
>
> If we go down the route that this patch follows of conditional
> compilation then we are making the main kernel code more messy in order
> to support test code and I'm not sure that is a good idea. It will be
> much worse should someone want to do the same for ARMv5.
>
> There is also the problem that once you #ifdef things for ARMv6 then you
> need an ARMv6 system to test that combination of data structures,
> whereas at the moment an ARMv7 board will cover everything.
>
> --
> Tixy

Hi Jon,
I see. You're worried about the main kernel code being tainted by adding more
test code for test. To keep the clean decode table without #ifdef,
most modified codes in
arch/arm/kernel/kprobes-arm.c may be removed.
But, in order to keep consistency supporting 'nop', I think at least we still
need to add patches for 'nop' in arch/arm/kernel/kprobes-test.c and
kprobes-test.h.
It doesn't look good 'nop' is used by default like TEST_INSTRUCTION()
while TEST('nop') is
excluded in kprobe_arm_test_cases.

-- Kpark

>
>> FAIL: Register test coverage missing for 0ff000f0 00600090 (04404)
>> FAIL: Test coverage entry missing for 0ff000f0 00600090
>> FAIL: Test coverage entry missing for 0f200090 00200090
>> FAIL: Register test coverage missing for 0fb00000 03000000 (05000)
>> FAIL: Test coverage entry missing for 0fb00000 03000000
>> FAIL: Test coverage entry missing for 0fff00ff 03200001
>> FAIL: Test coverage entry missing for 0fff00ff 03200004
>> FAIL: Test coverage entry missing for 0fff00fc 03200000
>> FAIL: Test coverage entry missing for 0fb00010 06000010
>> FAIL: Test coverage entry missing for 0f8000f0 060000b0
>> FAIL: Test coverage entry missing for 0f8000f0 060000d0
>> FAIL: Register test coverage missing for 0f800010 06000010 (55005)
>> FAIL: Test coverage entry missing for 0f800010 06000010
>> FAIL: Test coverage entry missing for 0ff000f0 07f000f0
>> FAIL: Register test coverage missing for 0fa00070 07a00050 (05005)
>> FAIL: Test coverage entry missing for 0fa00070 07a00050
>> FAIL: Register test coverage missing for 0fe0007f 07c0001f (05000)
>> FAIL: Test coverage entry missing for 0fe0007f 07c0001f
>> FAIL: Register test coverage missing for 0fe00070 07c00010 (05001)
>> FAIL: Test coverage entry missing for 0fe00070 07c00010
>>
>> Some instructions (like yield, sev, nop, and so on) are available in
>> ARMv6k or ARMv7, which we can test by checking the __LINUX_ARM_ARCH__
>> or checking the CONFIG_CPU_32v6K.
>> While MLS is excluded on ARMv6, more TEST_UNSUPPORTED coverages for
>> MLA is needed.
>> NOP instruction is used in several predefined macros, and these will
>> lead us to get a lot of INSN_REJECTED errors since the nop instruction
>> is not included in kprobe_decode_arm_table on ARMv6. By checking the
>> __LINUX_ARM_ARCH__ or the CONFIG_CPU_32v6K, 'nop' or 'mov r0,r0' will
>> be selected.
>>
>> Signed-off-by: Sahara <keun-o.park at windriver.com>
>> ---
>>  arch/arm/kernel/kprobes-arm.c      |   20 ++++++++++++++++++--
>>  arch/arm/kernel/kprobes-test-arm.c |    3 +++
>>  arch/arm/kernel/kprobes-test.c     |    2 +-
>>  arch/arm/kernel/kprobes-test.h     |   18 ++++++++++++------
>>  4 files changed, 34 insertions(+), 9 deletions(-)
>>
>> diff --git a/arch/arm/kernel/kprobes-arm.c b/arch/arm/kernel/kprobes-arm.c
>> index 8a30c89..324fd22 100644
>> --- a/arch/arm/kernel/kprobes-arm.c
>> +++ b/arch/arm/kernel/kprobes-arm.c
>> @@ -495,10 +495,13 @@ static const union decode_item arm_cccc_0000_____1001_table[] = {
>>
>>       /* MLA                  cccc 0000 0010 xxxx xxxx xxxx 1001 xxxx */
>>       /* MLAS                 cccc 0000 0011 xxxx xxxx xxxx 1001 xxxx */
>> -     DECODE_OR       (0x0fe000f0, 0x00200090),
>> +     DECODE_EMULATEX (0x0fe000f0, 0x00200090, emulate_rd16rn12rm0rs8_rwflags_nopc,
>> +                                              REGS(NOPC, NOPC, NOPC, 0, NOPC)),
>> +#if __LINUX_ARM_ARCH__ >= 7
>>       /* MLS                  cccc 0000 0110 xxxx xxxx xxxx 1001 xxxx */
>>       DECODE_EMULATEX (0x0ff000f0, 0x00600090, emulate_rd16rn12rm0rs8_rwflags_nopc,
>>                                                REGS(NOPC, NOPC, NOPC, 0, NOPC)),
>> +#endif
>>
>>       /* UMAAL                cccc 0000 0100 xxxx xxxx xxxx 1001 xxxx */
>>       DECODE_OR       (0x0ff000f0, 0x00400090),
>> @@ -533,12 +536,14 @@ static const union decode_item arm_cccc_0001_____1001_table[] = {
>>  static const union decode_item arm_cccc_000x_____1xx1_table[] = {
>>       /* Extra load/store instructions                                */
>>
>> +#if __LINUX_ARM_ARCH__ >= 7
>>       /* STRHT                cccc 0000 xx10 xxxx xxxx xxxx 1011 xxxx */
>>       /* ???                  cccc 0000 xx10 xxxx xxxx xxxx 11x1 xxxx */
>>       /* LDRHT                cccc 0000 xx11 xxxx xxxx xxxx 1011 xxxx */
>>       /* LDRSBT               cccc 0000 xx11 xxxx xxxx xxxx 1101 xxxx */
>>       /* LDRSHT               cccc 0000 xx11 xxxx xxxx xxxx 1111 xxxx */
>>       DECODE_REJECT   (0x0f200090, 0x00200090),
>> +#endif
>>
>>       /* LDRD/STRD lr,pc,{... cccc 000x x0x0 xxxx 111x xxxx 1101 xxxx */
>>       DECODE_REJECT   (0x0e10e0d0, 0x0000e0d0),
>> @@ -641,11 +646,14 @@ static const union decode_item arm_cccc_000x_table[] = {
>>  static const union decode_item arm_cccc_001x_table[] = {
>>       /* Data-processing (immediate)                                  */
>>
>> +#if __LINUX_ARM_ARCH__ >= 7
>>       /* MOVW                 cccc 0011 0000 xxxx xxxx xxxx xxxx xxxx */
>>       /* MOVT                 cccc 0011 0100 xxxx xxxx xxxx xxxx xxxx */
>>       DECODE_EMULATEX (0x0fb00000, 0x03000000, emulate_rd12rm0_noflags_nopc,
>>                                                REGS(0, NOPC, 0, 0, 0)),
>> +#endif
>>
>> +#if (__LINUX_ARM_ARCH__ >= 7) || defined(CONFIG_CPU_32v6K)
>>       /* YIELD                cccc 0011 0010 0000 xxxx xxxx 0000 0001 */
>>       DECODE_OR       (0x0fff00ff, 0x03200001),
>>       /* SEV                  cccc 0011 0010 0000 xxxx xxxx 0000 0100 */
>> @@ -654,7 +662,9 @@ static const union decode_item arm_cccc_001x_table[] = {
>>       /* WFE                  cccc 0011 0010 0000 xxxx xxxx 0000 0010 */
>>       /* WFI                  cccc 0011 0010 0000 xxxx xxxx 0000 0011 */
>>       DECODE_SIMULATE (0x0fff00fc, 0x03200000, kprobe_simulate_nop),
>> -     /* DBG                  cccc 0011 0010 0000 xxxx xxxx ffff xxxx */
>> +     /* DBG                  cccc 0011 0010 0000 xxxx xxxx 1111 xxxx */
>> +     DECODE_REJECT   (0x0fb000f0, 0x032000f0),
>> +#endif
>>       /* unallocated hints    cccc 0011 0010 0000 xxxx xxxx xxxx xxxx */
>>       /* MSR (immediate)      cccc 0011 0x10 xxxx xxxx xxxx xxxx xxxx */
>>       DECODE_REJECT   (0x0fb00000, 0x03200000),
>> @@ -712,6 +722,7 @@ static const union decode_item arm_cccc_0110_____xxx1_table[] = {
>>       DECODE_EMULATEX (0x0fb00070, 0x06b00030, emulate_rd12rm0_noflags_nopc,
>>                                                REGS(0, NOPC, 0, 0, NOPC)),
>>
>> +#if __LINUX_ARM_ARCH__ >= 7
>>       /* ???                  cccc 0110 0x00 xxxx xxxx xxxx xxx1 xxxx */
>>       DECODE_REJECT   (0x0fb00010, 0x06000010),
>>       /* ???                  cccc 0110 0xxx xxxx xxxx xxxx 1011 xxxx */
>> @@ -756,6 +767,7 @@ static const union decode_item arm_cccc_0110_____xxx1_table[] = {
>>       /* UHSUB8               cccc 0110 0111 xxxx xxxx xxxx 1111 xxxx */
>>       DECODE_EMULATEX (0x0f800010, 0x06000010, emulate_rd12rn16rm0_rwflags_nopc,
>>                                                REGS(NOPC, NOPC, 0, 0, NOPC)),
>> +#endif
>>
>>       /* PKHBT                cccc 0110 1000 xxxx xxxx xxxx x001 xxxx */
>>       /* PKHTB                cccc 0110 1000 xxxx xxxx xxxx x101 xxxx */
>> @@ -790,8 +802,10 @@ static const union decode_item arm_cccc_0110_____xxx1_table[] = {
>>  static const union decode_item arm_cccc_0111_____xxx1_table[] = {
>>       /* Media instructions                                           */
>>
>> +#if __LINUX_ARM_ARCH__ >= 7
>>       /* UNDEFINED            cccc 0111 1111 xxxx xxxx xxxx 1111 xxxx */
>>       DECODE_REJECT   (0x0ff000f0, 0x07f000f0),
>> +#endif
>>
>>       /* SMLALD               cccc 0111 0100 xxxx xxxx xxxx 00x1 xxxx */
>>       /* SMLSLD               cccc 0111 0100 xxxx xxxx xxxx 01x1 xxxx */
>> @@ -820,6 +834,7 @@ static const union decode_item arm_cccc_0111_____xxx1_table[] = {
>>       DECODE_EMULATEX (0x0ff000d0, 0x075000d0, emulate_rd16rn12rm0rs8_rwflags_nopc,
>>                                                REGS(NOPC, NOPC, NOPC, 0, NOPC)),
>>
>> +#if __LINUX_ARM_ARCH__ >= 7
>>       /* SBFX                 cccc 0111 101x xxxx xxxx xxxx x101 xxxx */
>>       /* UBFX                 cccc 0111 111x xxxx xxxx xxxx x101 xxxx */
>>       DECODE_EMULATEX (0x0fa00070, 0x07a00050, emulate_rd12rm0_noflags_nopc,
>> @@ -832,6 +847,7 @@ static const union decode_item arm_cccc_0111_____xxx1_table[] = {
>>       /* BFI                  cccc 0111 110x xxxx xxxx xxxx x001 xxxx */
>>       DECODE_EMULATEX (0x0fe00070, 0x07c00010, emulate_rd12rm0_noflags_nopc,
>>                                                REGS(0, NOPC, 0, 0, NOPCX)),
>> +#endif
>>
>>       DECODE_END
>>  };
>> diff --git a/arch/arm/kernel/kprobes-test-arm.c b/arch/arm/kernel/kprobes-test-arm.c
>> index 8393129..850b7b9 100644
>> --- a/arch/arm/kernel/kprobes-test-arm.c
>> +++ b/arch/arm/kernel/kprobes-test-arm.c
>> @@ -353,6 +353,9 @@ void kprobe_arm_test_cases(void)
>>       TEST_RRR(    "mlahi     r7, r",8, VAL3,", r",9, VAL1,", r",10, VAL2,"")
>>       TEST_RR(     "mla       lr, r",1, VAL2,", r",2, VAL3,", r13")
>>       TEST_UNSUPPORTED(".word 0xe02f3291 @ mla pc, r1, r2, r3")
>> +     TEST_UNSUPPORTED(".word 0xe020329f @ mla r0, pc, r2, r3")
>> +     TEST_UNSUPPORTED(".word 0xe0203f91 @ mla r0, r1, pc, r3")
>> +     TEST_UNSUPPORTED(".word 0xe020f291 @ mla r0, r1, r2, pc")
>>       TEST_RRR(    "mlas      r0, r",1, VAL1,", r",2, VAL2,", r",3,  VAL3,"")
>>       TEST_RRR(    "mlahis    r7, r",8, VAL3,", r",9, VAL1,", r",10, VAL2,"")
>>       TEST_RR(     "mlas      lr, r",1, VAL2,", r",2, VAL3,", r13")
>> diff --git a/arch/arm/kernel/kprobes-test.c b/arch/arm/kernel/kprobes-test.c
>> index 0cd63d0..0651fd6 100644
>> --- a/arch/arm/kernel/kprobes-test.c
>> +++ b/arch/arm/kernel/kprobes-test.c
>> @@ -478,7 +478,7 @@ static int run_api_tests(long (*func)(long, long))
>>  static void __naked benchmark_nop(void)
>>  {
>>       __asm__ __volatile__ (
>> -             "nop            \n\t"
>> +             NOP"            \n\t"
>>               "bx     lr"
>>       );
>>  }
>> diff --git a/arch/arm/kernel/kprobes-test.h b/arch/arm/kernel/kprobes-test.h
>> index e28a869..24822f0 100644
>> --- a/arch/arm/kernel/kprobes-test.h
>> +++ b/arch/arm/kernel/kprobes-test.h
>> @@ -144,20 +144,26 @@ struct test_arg_end {
>>       ".code "TEST_ISA"                               \n\t"   \
>>       "0:                                             \n\t"
>>
>> +#if (__LINUX_ARM_ARCH__ >= 7) || defined(CONFIG_CPU_32v6K)
>> +#define NOP "nop"
>> +#else
>> +#define NOP "mov     r0, r0"
>> +#endif
>> +
>>  #define TEST_INSTRUCTION(instruction)                                \
>> -     "50:    nop                                     \n\t"   \
>> +     "50:    "NOP"                                   \n\t"   \
>>       "1:     "instruction"                           \n\t"   \
>> -     "       nop                                     \n\t"
>> +     "       "NOP"                                   \n\t"
>>
>>  #define TEST_BRANCH_F(instruction)                           \
>>       TEST_INSTRUCTION(instruction)                           \
>>       "       b       99f                             \n\t"   \
>> -     "2:     nop                                     \n\t"
>> +     "2:     "NOP"                                   \n\t"
>>
>>  #define TEST_BRANCH_B(instruction)                           \
>>       "       b       50f                             \n\t"   \
>>       "       b       99f                             \n\t"   \
>> -     "2:     nop                                     \n\t"   \
>> +     "2:     "NOP"                                   \n\t"   \
>>       "       b       99f                             \n\t"   \
>>       TEST_INSTRUCTION(instruction)
>>
>> @@ -166,12 +172,12 @@ struct test_arg_end {
>>       "       b       99f                             \n\t"   \
>>       codex"                                          \n\t"   \
>>       "       b       99f                             \n\t"   \
>> -     "2:     nop                                     \n\t"
>> +     "2:     "NOP"                                   \n\t"
>>
>>  #define TEST_BRANCH_BX(instruction, codex)                   \
>>       "       b       50f                             \n\t"   \
>>       "       b       99f                             \n\t"   \
>> -     "2:     nop                                     \n\t"   \
>> +     "2:     "NOP"                                   \n\t"   \
>>       "       b       99f                             \n\t"   \
>>       codex"                                          \n\t"   \
>>       TEST_INSTRUCTION(instruction)
>
>


From kgene.kim at samsung.com  Tue Apr  2 22:02:53 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Wed, 03 Apr 2013 11:02:53 +0900
Subject: [PATCH 0/2] These two patches to s3c_pm_arch_prepare_irqs() were
 part of the work
In-Reply-To: <1363711900-25560-1-git-send-email-dianders@chromium.org>
References: <1363711900-25560-1-git-send-email-dianders@chromium.org>
Message-ID: <24b401ce300f$5a767b40$0f6371c0$%kim@samsung.com>

Doug Anderson wrote:
> 
> to make suspend/resume reliable on the ARM Chromebook
> (exynos5250-snow).
> 
> A few more details:
> - The first patch is not strictly needed but was a nice cleanup.  Our
>   understanding was that EINT0 was originally turned on for exynos
>   evt0 silicon and not needed for evt1.

Looks good to me, applied, thanks.

> - The second patch is more important and (also) more obvious.  The
>   function was modifying the S5P_WAKEUP_MASK register and then
>   clobbering its own modifications.
> 
Applied with 1st one, BTW, do you want to send this for stable tree?

- Kukjin

> For some history, see:
> - https://gerrit.chromium.org/gerrit/31337
> - https://gerrit.chromium.org/gerrit/31341
> 
> 
> Jonathan Kliegman (2):
>   arm: exynos: Remove hardcode wakeup unmask for EINT_0
>   arm: exynos: Clear ENABLE_WAKEUP_SW bit when entering suspend
> 
>  arch/arm/mach-exynos/include/mach/pm-core.h | 9 ++-------
>  1 file changed, 2 insertions(+), 7 deletions(-)
> 
> --
> 1.8.1.3



From horms+renesas at verge.net.au  Tue Apr  2 22:04:40 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed,  3 Apr 2013 11:04:40 +0900
Subject: [PATCH 02/28] sh: sh7269: Fix compilation by adding missing includes
In-Reply-To: <1364954706-14727-1-git-send-email-horms+renesas@verge.net.au>
References: <1364954706-14727-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364954706-14727-3-git-send-email-horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

struct resource is defined in linux/ioport.h. Include it.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/sh/kernel/cpu/sh2a/pinmux-sh7269.c |    2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/sh/kernel/cpu/sh2a/pinmux-sh7269.c b/arch/sh/kernel/cpu/sh2a/pinmux-sh7269.c
index 1825b0b..4c17fb6 100644
--- a/arch/sh/kernel/cpu/sh2a/pinmux-sh7269.c
+++ b/arch/sh/kernel/cpu/sh2a/pinmux-sh7269.c
@@ -9,7 +9,9 @@
  * for more details.
  */
 
+#include <linux/bug.h>
 #include <linux/init.h>
+#include <linux/ioport.h>
 #include <linux/kernel.h>
 #include <cpu/pfc.h>
 
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 22:04:39 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed,  3 Apr 2013 11:04:39 +0900
Subject: [PATCH 01/28] sh-pfc: Fix compiler warning when BUG()
In-Reply-To: <1364954706-14727-1-git-send-email-horms+renesas@verge.net.au>
References: <1364954706-14727-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364954706-14727-2-git-send-email-horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

The sh_pfc_phys_to_virt() function ends with a BUG() statement without a
return. When CONFIG_BUG isn't set the function will thus have no return
value. Fix it.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 drivers/pinctrl/sh-pfc/core.c |    1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/pinctrl/sh-pfc/core.c b/drivers/pinctrl/sh-pfc/core.c
index feef897..97e6ea3 100644
--- a/drivers/pinctrl/sh-pfc/core.c
+++ b/drivers/pinctrl/sh-pfc/core.c
@@ -72,6 +72,7 @@ static void __iomem *sh_pfc_phys_to_virt(struct sh_pfc *pfc,
 	}
 
 	BUG();
+	return NULL;
 }
 
 int sh_pfc_get_pin_index(struct sh_pfc *pfc, unsigned int pin)
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 22:04:38 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed,  3 Apr 2013 11:04:38 +0900
Subject: [GIT PULL v2] Renesas ARM and SH based SoC pinmux updates for v3.10
Message-ID: <1364954706-14727-1-git-send-email-horms+renesas@verge.net.au>

Hi Olof, Hi Arnd,

The following changes since commit 809609a5d8427b0025304dbb69a84a692d11c4f9:

  Merge branch 'soc' into pinmux-base (2013-04-02 11:08:34 +0900)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-pinmux2-for-v3.10

for you to fetch changes up to 202ac6a21a79500ef5aab4cd8665be2597e9345c:

  sh-pfc: r8a73a4: Remove unused GPIO bias data (2013-04-03 10:30:43 +0900)

----------------------------------------------------------------
Second round of Renesas ARM and SH based SoC pinmux updates for v3.10

Highlights:

* Compilation fixes for sh7269 and for when CONFIG_BUG is not set
* sh-pfc Support for r8a73a4 SoC
* Move GPIOs handling from the PFC device to separate GPIO devices on the r8a7779 SoC

This pull request is based on a merge of:
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas renesas-pinmux-for-v3.10
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas renesas-soc2-for-v3.10

----------------------------------------------------------------
Laurent Pinchart (14):
      sh-pfc: Fix compiler warning when BUG()
      sh: sh7269: Fix compilation by adding missing includes
      sh-pfc: r8a7779: Remove function GPIOs
      sh-pfc: r8a7779: Don't use GPIO enum entries
      ARM: shmobile: r8a7779: Remove all GPIOs
      gpio-rcar: Add pinctrl support
      ARM: shmobile: marzen: Add GPIO LEDs
      sh-pfc: Make function GPIOs support optional
      sh-pfc: Make GPIO support optional
      sh-pfc: Skip gpiochip registration when no GPIO resource is found
      sh-pfc: Configure pins as GPIOs at request time when handled externally
      ARM: shmobile: r8a7779: Register GPIO devices
      sh-pfc: r8a7779: Remove GPIO data
      sh-pfc: r8a7779: Split DU input and output pixel clocks

Magnus Damm (14):
      gpio: Renesas R-Car GPIO driver V3
      sh-pfc: Add r8a73a4 pinmux support
      sh-pfc: r8a73a4: Support sparse GPIO numbers
      sh-pfc: r8a73a4: GPIO IRQ support
      sh-pfc: r8a73a4: Add bias (pull-up/down) pinconf support
      sh-pfc: r8a73a4: Add SCIF pin groups and functions
      sh-pfc: r8a73a4: Add IRQC pin groups and functions
      sh-pfc: r8a73a4: Remove SCIF function GPIOS
      sh-pfc: r8a73a4: Remove IRQC function GPIOS
      ARM: shmobile: r8a73a4: Remove SCIF function GPIOs
      ARM: shmobile: r8a73a4: Remove IRQC function GPIOs
      sh-pfc: r8a73a4: Remove function GPIOs
      ARM: shmobile: r8a73a4: Remove all GPIO enums
      sh-pfc: r8a73a4: Remove unused GPIO bias data

 arch/arm/mach-shmobile/board-marzen.c         |   32 +
 arch/arm/mach-shmobile/include/mach/r8a7779.h |  317 ---
 arch/arm/mach-shmobile/setup-r8a7779.c        |   58 +-
 arch/sh/kernel/cpu/sh2a/pinmux-sh7269.c       |    2 +
 drivers/gpio/Kconfig                          |    6 +
 drivers/gpio/Makefile                         |    1 +
 drivers/gpio/gpio-rcar.c                      |  396 ++++
 drivers/pinctrl/sh-pfc/Kconfig                |    5 +
 drivers/pinctrl/sh-pfc/Makefile               |    1 +
 drivers/pinctrl/sh-pfc/core.c                 |   41 +-
 drivers/pinctrl/sh-pfc/core.h                 |    1 +
 drivers/pinctrl/sh-pfc/gpio.c                 |   45 +-
 drivers/pinctrl/sh-pfc/pfc-r8a73a4.c          | 2587 +++++++++++++++++++++++++
 drivers/pinctrl/sh-pfc/pfc-r8a7779.c          |  479 +----
 drivers/pinctrl/sh-pfc/pinctrl.c              |   11 +
 include/linux/platform_data/gpio-rcar.h       |   26 +
 16 files changed, 3274 insertions(+), 734 deletions(-)
 create mode 100644 drivers/gpio/gpio-rcar.c
 create mode 100644 drivers/pinctrl/sh-pfc/pfc-r8a73a4.c
 create mode 100644 include/linux/platform_data/gpio-rcar.h


From horms+renesas at verge.net.au  Tue Apr  2 22:04:47 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed,  3 Apr 2013 11:04:47 +0900
Subject: [PATCH 09/28] sh-pfc: Make function GPIOs support optional
In-Reply-To: <1364954706-14727-1-git-send-email-horms+renesas@verge.net.au>
References: <1364954706-14727-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364954706-14727-10-git-send-email-horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

The target is to get rid of function GPIOs completely. To reach this,
make function GPIOs support optional by skipping the function GPIO chip
registration if no function GPIOS are defined in SoC data.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Acked-by: Linus Walleij <linus.walleij at linaro.org>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 drivers/pinctrl/sh-pfc/gpio.c |    3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/pinctrl/sh-pfc/gpio.c b/drivers/pinctrl/sh-pfc/gpio.c
index d7acb06..7a54ec7 100644
--- a/drivers/pinctrl/sh-pfc/gpio.c
+++ b/drivers/pinctrl/sh-pfc/gpio.c
@@ -384,6 +384,9 @@ int sh_pfc_register_gpiochip(struct sh_pfc *pfc)
 	}
 
 	/* Register the function GPIOs chip. */
+	if (pfc->info->nr_func_gpios == 0)
+		return 0;
+
 	chip = sh_pfc_add_gpiochip(pfc, gpio_function_setup);
 	if (IS_ERR(chip))
 		return PTR_ERR(chip);
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 22:04:42 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed,  3 Apr 2013 11:04:42 +0900
Subject: [PATCH 04/28] sh-pfc: r8a7779: Don't use GPIO enum entries
In-Reply-To: <1364954706-14727-1-git-send-email-horms+renesas@verge.net.au>
References: <1364954706-14727-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364954706-14727-5-git-send-email-horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

Refactor the GPIO macro magic to use GPIO numbers directly instead of
the GPIO_GP_x_y enum entries. This will allow removing the GPIO enum
entries from the mach/r8a7779.h header.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Acked-by: Linus Walleij <linus.walleij at linaro.org>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 drivers/pinctrl/sh-pfc/pfc-r8a7779.c |  104 ++++++++++++++++++++++++----------
 1 file changed, 74 insertions(+), 30 deletions(-)

diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a7779.c b/drivers/pinctrl/sh-pfc/pfc-r8a7779.c
index 4db9944..41d8bda 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a7779.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a7779.c
@@ -19,39 +19,83 @@
  */
 
 #include <linux/kernel.h>
-#include <mach/r8a7779.h>
 
 #include "sh_pfc.h"
 
-#define CPU_32_PORT6(fn, pfx, sfx)				\
-	PORT_1(fn, pfx##0, sfx), PORT_1(fn, pfx##1, sfx),	\
-	PORT_1(fn, pfx##2, sfx), PORT_1(fn, pfx##3, sfx),	\
-	PORT_1(fn, pfx##4, sfx), PORT_1(fn, pfx##5, sfx),	\
-	PORT_1(fn, pfx##6, sfx), PORT_1(fn, pfx##7, sfx),	\
-	PORT_1(fn, pfx##8, sfx)
-
-#define CPU_ALL_PORT(fn, pfx, sfx)				\
-	PORT_32(fn, pfx##_0_, sfx),				\
-	PORT_32(fn, pfx##_1_, sfx),				\
-	PORT_32(fn, pfx##_2_, sfx),				\
-	PORT_32(fn, pfx##_3_, sfx),				\
-	PORT_32(fn, pfx##_4_, sfx),				\
-	PORT_32(fn, pfx##_5_, sfx),				\
-	CPU_32_PORT6(fn, pfx##_6_, sfx)
-
-#define _GP_GPIO(pfx, sfx) PINMUX_GPIO(GPIO_GP##pfx, GP##pfx##_DATA)
-#define _GP_DATA(pfx, sfx) PINMUX_DATA(GP##pfx##_DATA, GP##pfx##_FN,	\
-				       GP##pfx##_IN, GP##pfx##_OUT)
-
-#define _GP_INOUTSEL(pfx, sfx) GP##pfx##_IN, GP##pfx##_OUT
-#define _GP_INDT(pfx, sfx) GP##pfx##_DATA
-
-#define GP_ALL(str)	CPU_ALL_PORT(_PORT_ALL, GP, str)
-#define PINMUX_GPIO_GP_ALL()	CPU_ALL_PORT(_GP_GPIO, , unused)
-#define PINMUX_DATA_GP_ALL()	CPU_ALL_PORT(_GP_DATA, , unused)
-
-#define GP_INOUTSEL(bank) PORT_32_REV(_GP_INOUTSEL, _##bank##_, unused)
-#define GP_INDT(bank) PORT_32_REV(_GP_INDT, _##bank##_, unused)
+#define PORT_GP_1(bank, pin, fn, sfx) fn(bank, pin, GP_##bank##_##pin, sfx)
+
+#define PORT_GP_32(bank, fn, sfx)					\
+	PORT_GP_1(bank, 0,  fn, sfx), PORT_GP_1(bank, 1,  fn, sfx),	\
+	PORT_GP_1(bank, 2,  fn, sfx), PORT_GP_1(bank, 3,  fn, sfx),	\
+	PORT_GP_1(bank, 4,  fn, sfx), PORT_GP_1(bank, 5,  fn, sfx),	\
+	PORT_GP_1(bank, 6,  fn, sfx), PORT_GP_1(bank, 7,  fn, sfx),	\
+	PORT_GP_1(bank, 8,  fn, sfx), PORT_GP_1(bank, 9,  fn, sfx),	\
+	PORT_GP_1(bank, 10, fn, sfx), PORT_GP_1(bank, 11, fn, sfx),	\
+	PORT_GP_1(bank, 12, fn, sfx), PORT_GP_1(bank, 13, fn, sfx),	\
+	PORT_GP_1(bank, 14, fn, sfx), PORT_GP_1(bank, 15, fn, sfx),	\
+	PORT_GP_1(bank, 16, fn, sfx), PORT_GP_1(bank, 17, fn, sfx),	\
+	PORT_GP_1(bank, 18, fn, sfx), PORT_GP_1(bank, 19, fn, sfx),	\
+	PORT_GP_1(bank, 20, fn, sfx), PORT_GP_1(bank, 21, fn, sfx),	\
+	PORT_GP_1(bank, 22, fn, sfx), PORT_GP_1(bank, 23, fn, sfx),	\
+	PORT_GP_1(bank, 24, fn, sfx), PORT_GP_1(bank, 25, fn, sfx),	\
+	PORT_GP_1(bank, 26, fn, sfx), PORT_GP_1(bank, 27, fn, sfx),	\
+	PORT_GP_1(bank, 28, fn, sfx), PORT_GP_1(bank, 29, fn, sfx),	\
+	PORT_GP_1(bank, 30, fn, sfx), PORT_GP_1(bank, 31, fn, sfx)
+
+#define PORT_GP_32_9(bank, fn, sfx)					\
+	PORT_GP_1(bank, 0, fn, sfx), PORT_GP_1(bank, 1, fn, sfx),	\
+	PORT_GP_1(bank, 2, fn, sfx), PORT_GP_1(bank, 3, fn, sfx),	\
+	PORT_GP_1(bank, 4, fn, sfx), PORT_GP_1(bank, 5, fn, sfx),	\
+	PORT_GP_1(bank, 6, fn, sfx), PORT_GP_1(bank, 7, fn, sfx),	\
+	PORT_GP_1(bank, 8, fn, sfx)
+
+#define PORT_GP_32_REV(bank, fn, sfx)					\
+	PORT_GP_1(bank, 31, fn, sfx), PORT_GP_1(bank, 30, fn, sfx),	\
+	PORT_GP_1(bank, 29, fn, sfx), PORT_GP_1(bank, 28, fn, sfx),	\
+	PORT_GP_1(bank, 27, fn, sfx), PORT_GP_1(bank, 26, fn, sfx),	\
+	PORT_GP_1(bank, 25, fn, sfx), PORT_GP_1(bank, 24, fn, sfx),	\
+	PORT_GP_1(bank, 23, fn, sfx), PORT_GP_1(bank, 22, fn, sfx),	\
+	PORT_GP_1(bank, 21, fn, sfx), PORT_GP_1(bank, 20, fn, sfx),	\
+	PORT_GP_1(bank, 19, fn, sfx), PORT_GP_1(bank, 18, fn, sfx),	\
+	PORT_GP_1(bank, 17, fn, sfx), PORT_GP_1(bank, 16, fn, sfx),	\
+	PORT_GP_1(bank, 15, fn, sfx), PORT_GP_1(bank, 14, fn, sfx),	\
+	PORT_GP_1(bank, 13, fn, sfx), PORT_GP_1(bank, 12, fn, sfx),	\
+	PORT_GP_1(bank, 11, fn, sfx), PORT_GP_1(bank, 10, fn, sfx),	\
+	PORT_GP_1(bank, 9,  fn, sfx), PORT_GP_1(bank, 8,  fn, sfx),	\
+	PORT_GP_1(bank, 7,  fn, sfx), PORT_GP_1(bank, 6,  fn, sfx),	\
+	PORT_GP_1(bank, 5,  fn, sfx), PORT_GP_1(bank, 4,  fn, sfx),	\
+	PORT_GP_1(bank, 3,  fn, sfx), PORT_GP_1(bank, 2,  fn, sfx),	\
+	PORT_GP_1(bank, 1,  fn, sfx), PORT_GP_1(bank, 0,  fn, sfx)
+
+#define CPU_ALL_PORT(fn, sfx)						\
+	PORT_GP_32(0, fn, sfx),						\
+	PORT_GP_32(1, fn, sfx),						\
+	PORT_GP_32(2, fn, sfx),						\
+	PORT_GP_32(3, fn, sfx),						\
+	PORT_GP_32(4, fn, sfx),						\
+	PORT_GP_32(5, fn, sfx),						\
+	PORT_GP_32_9(6, fn, sfx)
+
+#define _GP_PORT_ALL(bank, pin, name, sfx)	name##_##sfx
+
+#define _GP_GPIO(bank, pin, _name, sfx)					\
+	[(bank * 32) + pin] = {						\
+		.name = __stringify(_name),				\
+		.enum_id = _name##_DATA,				\
+	}
+
+#define _GP_DATA(bank, pin, name, sfx)					\
+	PINMUX_DATA(name##_DATA, name##_FN, name##_IN, name##_OUT)
+
+#define _GP_INOUTSEL(bank, pin, name, sfx)	name##_IN, name##_OUT
+#define _GP_INDT(bank, pin, name, sfx)		name##_DATA
+
+#define GP_ALL(str)		CPU_ALL_PORT(_GP_PORT_ALL, str)
+#define PINMUX_GPIO_GP_ALL()	CPU_ALL_PORT(_GP_GPIO, unused)
+#define PINMUX_DATA_GP_ALL()	CPU_ALL_PORT(_GP_DATA, unused)
+
+#define GP_INOUTSEL(bank) PORT_GP_32_REV(bank, _GP_INOUTSEL, unused)
+#define GP_INDT(bank) PORT_GP_32_REV(bank, _GP_INDT, unused)
 
 #define PINMUX_IPSR_DATA(ipsr, fn) PINMUX_DATA(fn##_MARK, FN_##ipsr, FN_##fn)
 #define PINMUX_IPSR_MODSEL_DATA(ipsr, fn, ms) PINMUX_DATA(fn##_MARK, FN_##ms, \
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 22:04:45 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed,  3 Apr 2013 11:04:45 +0900
Subject: [PATCH 07/28] gpio-rcar: Add pinctrl support
In-Reply-To: <1364954706-14727-1-git-send-email-horms+renesas@verge.net.au>
References: <1364954706-14727-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364954706-14727-8-git-send-email-horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

Register the GPIO pin range, and request and free GPIO pins using the
pinctrl API.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Acked-by: Linus Walleij <linus.walleij at linaro.org>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 drivers/gpio/gpio-rcar.c                |   23 +++++++++++++++++++++++
 include/linux/platform_data/gpio-rcar.h |    1 +
 2 files changed, 24 insertions(+)

diff --git a/drivers/gpio/gpio-rcar.c b/drivers/gpio/gpio-rcar.c
index 581ba56..b4ca450 100644
--- a/drivers/gpio/gpio-rcar.c
+++ b/drivers/gpio/gpio-rcar.c
@@ -22,6 +22,7 @@
 #include <linux/irq.h>
 #include <linux/irqdomain.h>
 #include <linux/module.h>
+#include <linux/pinctrl/consumer.h>
 #include <linux/platform_data/gpio-rcar.h>
 #include <linux/platform_device.h>
 #include <linux/spinlock.h>
@@ -190,6 +191,21 @@ static void gpio_rcar_config_general_input_output_mode(struct gpio_chip *chip,
 	spin_unlock_irqrestore(&p->lock, flags);
 }
 
+static int gpio_rcar_request(struct gpio_chip *chip, unsigned offset)
+{
+	return pinctrl_request_gpio(chip->base + offset);
+}
+
+static void gpio_rcar_free(struct gpio_chip *chip, unsigned offset)
+{
+	pinctrl_free_gpio(chip->base + offset);
+
+	/* Set the GPIO as an input to ensure that the next GPIO request won't
+	 * drive the GPIO pin as an output.
+	 */
+	gpio_rcar_config_general_input_output_mode(chip, offset, false);
+}
+
 static int gpio_rcar_direction_input(struct gpio_chip *chip, unsigned offset)
 {
 	gpio_rcar_config_general_input_output_mode(chip, offset, false);
@@ -285,6 +301,8 @@ static int gpio_rcar_probe(struct platform_device *pdev)
 	}
 
 	gpio_chip = &p->gpio_chip;
+	gpio_chip->request = gpio_rcar_request;
+	gpio_chip->free = gpio_rcar_free;
 	gpio_chip->direction_input = gpio_rcar_direction_input;
 	gpio_chip->get = gpio_rcar_get;
 	gpio_chip->direction_output = gpio_rcar_direction_output;
@@ -337,6 +355,11 @@ static int gpio_rcar_probe(struct platform_device *pdev)
 				 p->config.irq_base, ret);
 	}
 
+	ret = gpiochip_add_pin_range(gpio_chip, p->config.pctl_name, 0,
+				     gpio_chip->base, gpio_chip->ngpio);
+	if (ret < 0)
+		dev_warn(&pdev->dev, "failed to add pin range\n");
+
 	return 0;
 
 err1:
diff --git a/include/linux/platform_data/gpio-rcar.h b/include/linux/platform_data/gpio-rcar.h
index bebfcd8..b253f77 100644
--- a/include/linux/platform_data/gpio-rcar.h
+++ b/include/linux/platform_data/gpio-rcar.h
@@ -20,6 +20,7 @@ struct gpio_rcar_config {
 	unsigned int gpio_base;
 	unsigned int irq_base;
 	unsigned int number_of_pins;
+	const char *pctl_name;
 };
 
 #endif /* __GPIO_RCAR_H__ */
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 22:04:46 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed,  3 Apr 2013 11:04:46 +0900
Subject: [PATCH 08/28] ARM: shmobile: marzen: Add GPIO LEDs
In-Reply-To: <1364954706-14727-1-git-send-email-horms+renesas@verge.net.au>
References: <1364954706-14727-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364954706-14727-9-git-send-email-horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

The board has 3 LEDs connected to GPIOs. Add a led-gpio device to
support them.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/board-marzen.c |   32 ++++++++++++++++++++++++++++++++
 1 file changed, 32 insertions(+)

diff --git a/arch/arm/mach-shmobile/board-marzen.c b/arch/arm/mach-shmobile/board-marzen.c
index 5852331..a88f7f3 100644
--- a/arch/arm/mach-shmobile/board-marzen.c
+++ b/arch/arm/mach-shmobile/board-marzen.c
@@ -25,6 +25,7 @@
 #include <linux/platform_device.h>
 #include <linux/delay.h>
 #include <linux/io.h>
+#include <linux/leds.h>
 #include <linux/dma-mapping.h>
 #include <linux/pinctrl/machine.h>
 #include <linux/regulator/fixed.h>
@@ -168,12 +169,43 @@ static struct platform_device usb_phy_device = {
 	.num_resources	= ARRAY_SIZE(usb_phy_resources),
 };
 
+/* LEDS */
+static struct gpio_led marzen_leds[] = {
+	{
+		.name		= "led2",
+		.gpio		= 157,
+		.default_state	= LEDS_GPIO_DEFSTATE_ON,
+	}, {
+		.name		= "led3",
+		.gpio		= 158,
+		.default_state	= LEDS_GPIO_DEFSTATE_ON,
+	}, {
+		.name		= "led4",
+		.gpio		= 159,
+		.default_state	= LEDS_GPIO_DEFSTATE_ON,
+	},
+};
+
+static struct gpio_led_platform_data marzen_leds_pdata = {
+	.leds		= marzen_leds,
+	.num_leds	= ARRAY_SIZE(marzen_leds),
+};
+
+static struct platform_device leds_device = {
+	.name	= "leds-gpio",
+	.id	= 0,
+	.dev	= {
+		.platform_data  = &marzen_leds_pdata,
+	},
+};
+
 static struct platform_device *marzen_devices[] __initdata = {
 	&eth_device,
 	&sdhi0_device,
 	&thermal_device,
 	&hspi_device,
 	&usb_phy_device,
+	&leds_device,
 };
 
 /* USB */
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 22:04:49 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed,  3 Apr 2013 11:04:49 +0900
Subject: [PATCH 11/28] sh-pfc: Skip gpiochip registration when no GPIO
 resource is found
In-Reply-To: <1364954706-14727-1-git-send-email-horms+renesas@verge.net.au>
References: <1364954706-14727-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364954706-14727-12-git-send-email-horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

Boards/platforms that register dedicated GPIO devices will not supply a
memory resource for GPIOs. Try to locate the GPIO memory resource at
initialization time, and skip registration of the gpiochip if the
resource can't be found.

This is a temporary modification to ease the transition to separate GPIO
drivers. It should be reverted when all boards and platforms will have
been moved.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Acked-by: Linus Walleij <linus.walleij at linaro.org>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 drivers/pinctrl/sh-pfc/gpio.c |   39 +++++++++++++++++++++------------------
 1 file changed, 21 insertions(+), 18 deletions(-)

diff --git a/drivers/pinctrl/sh-pfc/gpio.c b/drivers/pinctrl/sh-pfc/gpio.c
index 317cebb..d37efa7 100644
--- a/drivers/pinctrl/sh-pfc/gpio.c
+++ b/drivers/pinctrl/sh-pfc/gpio.c
@@ -101,24 +101,9 @@ static void gpio_setup_data_reg(struct sh_pfc_chip *chip, unsigned gpio)
 static int gpio_setup_data_regs(struct sh_pfc_chip *chip)
 {
 	struct sh_pfc *pfc = chip->pfc;
-	unsigned long addr = pfc->info->data_regs[0].reg;
 	const struct pinmux_data_reg *dreg;
 	unsigned int i;
 
-	/* Find the window that contain the GPIO registers. */
-	for (i = 0; i < pfc->num_windows; ++i) {
-		struct sh_pfc_window *window = &pfc->window[i];
-
-		if (addr >= window->phys && addr < window->phys + window->size)
-			break;
-	}
-
-	if (i == pfc->num_windows)
-		return -EINVAL;
-
-	/* GPIO data registers must be in the first memory resource. */
-	chip->mem = &pfc->window[i];
-
 	/* Count the number of data registers, allocate memory and initialize
 	 * them.
 	 */
@@ -319,7 +304,8 @@ static int gpio_function_setup(struct sh_pfc_chip *chip)
  */
 
 static struct sh_pfc_chip *
-sh_pfc_add_gpiochip(struct sh_pfc *pfc, int(*setup)(struct sh_pfc_chip *))
+sh_pfc_add_gpiochip(struct sh_pfc *pfc, int(*setup)(struct sh_pfc_chip *),
+		    struct sh_pfc_window *mem)
 {
 	struct sh_pfc_chip *chip;
 	int ret;
@@ -328,6 +314,7 @@ sh_pfc_add_gpiochip(struct sh_pfc *pfc, int(*setup)(struct sh_pfc_chip *))
 	if (unlikely(!chip))
 		return ERR_PTR(-ENOMEM);
 
+	chip->mem = mem;
 	chip->pfc = pfc;
 
 	ret = setup(chip);
@@ -357,8 +344,24 @@ int sh_pfc_register_gpiochip(struct sh_pfc *pfc)
 	if (pfc->info->data_regs == NULL)
 		return 0;
 
+	/* Find the memory window that contain the GPIO registers. Boards that
+	 * register a separate GPIO device will not supply a memory resource
+	 * that covers the data registers. In that case don't try to handle
+	 * GPIOs.
+	 */
+	for (i = 0; i < pfc->num_windows; ++i) {
+		struct sh_pfc_window *window = &pfc->window[i];
+
+		if (pfc->info->data_regs[0].reg >= window->phys &&
+		    pfc->info->data_regs[0].reg < window->phys + window->size)
+			break;
+	}
+
+	if (i == pfc->num_windows)
+		return 0;
+
 	/* Register the real GPIOs chip. */
-	chip = sh_pfc_add_gpiochip(pfc, gpio_pin_setup);
+	chip = sh_pfc_add_gpiochip(pfc, gpio_pin_setup, &pfc->window[i]);
 	if (IS_ERR(chip))
 		return PTR_ERR(chip);
 
@@ -390,7 +393,7 @@ int sh_pfc_register_gpiochip(struct sh_pfc *pfc)
 	if (pfc->info->nr_func_gpios == 0)
 		return 0;
 
-	chip = sh_pfc_add_gpiochip(pfc, gpio_function_setup);
+	chip = sh_pfc_add_gpiochip(pfc, gpio_function_setup, NULL);
 	if (IS_ERR(chip))
 		return PTR_ERR(chip);
 
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 22:04:41 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed,  3 Apr 2013 11:04:41 +0900
Subject: [PATCH 03/28] sh-pfc: r8a7779: Remove function GPIOs
In-Reply-To: <1364954706-14727-1-git-send-email-horms+renesas@verge.net.au>
References: <1364954706-14727-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364954706-14727-4-git-send-email-horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

All r8a7779 platforms use the pinctrl API to control functions. Function
GPIOs are unused and unneeded, remove them.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Acked-by: Linus Walleij <linus.walleij at linaro.org>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 drivers/pinctrl/sh-pfc/pfc-r8a7779.c |  271 ----------------------------------
 1 file changed, 271 deletions(-)

diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a7779.c b/drivers/pinctrl/sh-pfc/pfc-r8a7779.c
index 1d7b0df..4db9944 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a7779.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a7779.c
@@ -2670,274 +2670,6 @@ static const struct sh_pfc_function pinmux_functions[] = {
 	SH_PFC_FUNCTION(usb2),
 };
 
-#define PINMUX_FN_BASE	ARRAY_SIZE(pinmux_pins)
-
-static const struct pinmux_func pinmux_func_gpios[] = {
-	GPIO_FN(AVS1), GPIO_FN(AVS2), GPIO_FN(A17), GPIO_FN(A18),
-	GPIO_FN(A19),
-
-	/* IPSR0 */
-	GPIO_FN(PWM1), GPIO_FN(PWMFSW0),
-	GPIO_FN(SCIF_CLK), GPIO_FN(TCLK0_C), GPIO_FN(BS),
-	GPIO_FN(FD2), GPIO_FN(ATADIR0), GPIO_FN(SDSELF),
-	GPIO_FN(HCTS1), GPIO_FN(A0),
-	GPIO_FN(FD3), GPIO_FN(A20),
-	GPIO_FN(A21),
-	GPIO_FN(A22),
-	GPIO_FN(VI1_R0), GPIO_FN(A23), GPIO_FN(FCLE),
-	GPIO_FN(VI1_R1), GPIO_FN(A24),
-	GPIO_FN(FD4),	GPIO_FN(VI1_R2),
-	GPIO_FN(SSI_WS78_B), GPIO_FN(A25),
-	GPIO_FN(FD5), GPIO_FN(VI1_R3),
-	GPIO_FN(SSI_SDATA7_B), GPIO_FN(CLKOUT),
-	GPIO_FN(PWM0_B),
-	GPIO_FN(SDSELF_B), GPIO_FN(RD_WR), GPIO_FN(FWE), GPIO_FN(ATAG0),
-	GPIO_FN(VI1_R7), GPIO_FN(HRTS1),
-
-	/* IPSR1 */
-	GPIO_FN(FD6), GPIO_FN(FD7),
-	GPIO_FN(FALE),
-	GPIO_FN(ATACS00),
-	GPIO_FN(FRE), GPIO_FN(ATACS10), GPIO_FN(VI1_R4),
-	GPIO_FN(HSCK1), GPIO_FN(SSI_SDATA8_B),
-	GPIO_FN(SSI_SDATA9),
-	GPIO_FN(FD0), GPIO_FN(ATARD0), GPIO_FN(VI1_R5),
-	GPIO_FN(HTX1),
-	GPIO_FN(SSI_SCK9),
-	GPIO_FN(FD1),	GPIO_FN(ATAWR0), GPIO_FN(VI1_R6),
-	GPIO_FN(HRX1), GPIO_FN(SSI_WS9),
-	GPIO_FN(MLB_CLK), GPIO_FN(PWM2), GPIO_FN(MLB_SIG),
-	GPIO_FN(PWM3), GPIO_FN(MLB_DAT), GPIO_FN(PWM4),
-	GPIO_FN(HTX0), GPIO_FN(SDATA),
-	GPIO_FN(SUB_TCK), GPIO_FN(CC5_STATE2),
-	GPIO_FN(CC5_STATE10), GPIO_FN(CC5_STATE18), GPIO_FN(CC5_STATE26),
-	GPIO_FN(CC5_STATE34),
-
-	/* IPSR2 */
-	GPIO_FN(HRX0), GPIO_FN(SCKZ),
-	GPIO_FN(SUB_TDI), GPIO_FN(CC5_STATE3), GPIO_FN(CC5_STATE11),
-	GPIO_FN(CC5_STATE19), GPIO_FN(CC5_STATE27), GPIO_FN(CC5_STATE35),
-	GPIO_FN(HSCK0), GPIO_FN(MTS), GPIO_FN(PWM5),
-	GPIO_FN(SSI_SDATA9_B), GPIO_FN(SUB_TDO),
-	GPIO_FN(CC5_STATE0), GPIO_FN(CC5_STATE8), GPIO_FN(CC5_STATE16),
-	GPIO_FN(CC5_STATE24), GPIO_FN(CC5_STATE32), GPIO_FN(HCTS0),
-	GPIO_FN(STM), GPIO_FN(PWM0_D),
-	GPIO_FN(SCIF_CLK_C), GPIO_FN(SUB_TRST), GPIO_FN(TCLK1_B),
-	GPIO_FN(CC5_OSCOUT), GPIO_FN(HRTS0),
-	GPIO_FN(MDATA), GPIO_FN(SUB_TMS), GPIO_FN(CC5_STATE1),
-	GPIO_FN(CC5_STATE9), GPIO_FN(CC5_STATE17), GPIO_FN(CC5_STATE25),
-	GPIO_FN(CC5_STATE33), GPIO_FN(LCDOUT0),
-	GPIO_FN(DREQ0), GPIO_FN(GPS_CLK_B), GPIO_FN(AUDATA0),
-	GPIO_FN(LCDOUT1), GPIO_FN(DACK0),
-	GPIO_FN(DRACK0), GPIO_FN(GPS_SIGN_B), GPIO_FN(AUDATA1),
-	GPIO_FN(LCDOUT2), GPIO_FN(LCDOUT3),
-	GPIO_FN(LCDOUT4), GPIO_FN(LCDOUT5),
-	GPIO_FN(LCDOUT6), GPIO_FN(LCDOUT7),
-	GPIO_FN(LCDOUT8), GPIO_FN(DREQ1), GPIO_FN(SCL2),
-	GPIO_FN(AUDATA2),
-
-	/* IPSR3 */
-	GPIO_FN(LCDOUT9), GPIO_FN(DACK1), GPIO_FN(SDA2),
-	GPIO_FN(AUDATA3), GPIO_FN(LCDOUT10),
-	GPIO_FN(LCDOUT11),
-	GPIO_FN(LCDOUT12), GPIO_FN(LCDOUT13),
-	GPIO_FN(LCDOUT14),
-	GPIO_FN(LCDOUT15), GPIO_FN(LCDOUT16),
-	GPIO_FN(EX_WAIT1), GPIO_FN(SCL1), GPIO_FN(TCLK1), GPIO_FN(AUDATA4),
-	GPIO_FN(LCDOUT17), GPIO_FN(EX_WAIT2), GPIO_FN(SDA1),
-	GPIO_FN(GPS_MAG_B), GPIO_FN(AUDATA5),
-	GPIO_FN(LCDOUT18),
-	GPIO_FN(LCDOUT19), GPIO_FN(LCDOUT20),
-	GPIO_FN(LCDOUT21),
-	GPIO_FN(LCDOUT22), GPIO_FN(LCDOUT23),
-	GPIO_FN(QSTVA_QVS),
-	GPIO_FN(SCL3_B), GPIO_FN(QCLK),
-	GPIO_FN(QSTVB_QVE),
-	GPIO_FN(SDA3_B), GPIO_FN(SDA2_C), GPIO_FN(DACK0_B), GPIO_FN(DRACK0_B),
-	GPIO_FN(QSTH_QHS),
-	GPIO_FN(QSTB_QHE),
-	GPIO_FN(QCPV_QDE),
-	GPIO_FN(CAN1_TX), GPIO_FN(SCL2_C), GPIO_FN(REMOCON),
-
-	/* IPSR4 */
-	GPIO_FN(QPOLA), GPIO_FN(CAN_CLK_C),
-	GPIO_FN(QPOLB), GPIO_FN(CAN1_RX),
-	GPIO_FN(DREQ0_B), GPIO_FN(SSI_SCK78_B),
-	GPIO_FN(VI2_DATA0_VI2_B0), GPIO_FN(PWM6),
-	GPIO_FN(AUDCK),
-	GPIO_FN(PWMFSW0_B), GPIO_FN(VI2_DATA1_VI2_B1),
-	GPIO_FN(PWM0),
-	GPIO_FN(AUDSYNC), GPIO_FN(VI2_G0),
-	GPIO_FN(VI2_G1), GPIO_FN(VI2_G2),
-	GPIO_FN(VI2_G3), GPIO_FN(VI2_G4),
-	GPIO_FN(VI2_G5),
-	GPIO_FN(VI2_DATA2_VI2_B2), GPIO_FN(SCL1_B),
-	GPIO_FN(AUDATA6),
-	GPIO_FN(VI2_DATA3_VI2_B3), GPIO_FN(SDA1_B),
-	GPIO_FN(AUDATA7),
-	GPIO_FN(VI2_G6), GPIO_FN(VI2_G7),
-	GPIO_FN(VI2_R0), GPIO_FN(VI2_R1),
-	GPIO_FN(VI2_R2), GPIO_FN(VI2_R3),
-	GPIO_FN(VI2_DATA4_VI2_B4), GPIO_FN(SCL2_B),
-
-	/* IPSR5 */
-	GPIO_FN(VI2_DATA5_VI2_B5), GPIO_FN(SDA2_B),
-	GPIO_FN(VI2_R4), GPIO_FN(VI2_R5),
-	GPIO_FN(VI2_R6), GPIO_FN(VI2_R7),
-	GPIO_FN(SCL2_D), GPIO_FN(SDA2_D),
-	GPIO_FN(VI2_CLKENB),
-	GPIO_FN(SCL1_D), GPIO_FN(VI2_FIELD),
-	GPIO_FN(SDA1_D), GPIO_FN(VI2_HSYNC),
-	GPIO_FN(VI3_HSYNC), GPIO_FN(VI2_VSYNC),
-	GPIO_FN(VI3_VSYNC),
-	GPIO_FN(VI2_CLK),
-	GPIO_FN(VI1_CLKENB), GPIO_FN(VI3_CLKENB),
-	GPIO_FN(AUDIO_CLKC), GPIO_FN(SPEEDIN),
-	GPIO_FN(GPS_SIGN_D), GPIO_FN(VI2_DATA6_VI2_B6),
-	GPIO_FN(TCLK0), GPIO_FN(QSTVA_B_QVS_B),
-	GPIO_FN(AUDIO_CLKOUT_B), GPIO_FN(GPS_MAG_D),
-	GPIO_FN(VI2_DATA7_VI2_B7),
-	GPIO_FN(VI1_FIELD),
-	GPIO_FN(VI3_FIELD), GPIO_FN(AUDIO_CLKOUT),
-	GPIO_FN(GPS_CLK_C), GPIO_FN(GPS_CLK_D), GPIO_FN(AUDIO_CLKA),
-	GPIO_FN(CAN_TXCLK), GPIO_FN(AUDIO_CLKB),
-	GPIO_FN(CAN_DEBUGOUT0), GPIO_FN(MOUT0),
-
-	/* IPSR6 */
-	GPIO_FN(SSI_SCK0129), GPIO_FN(CAN_DEBUGOUT1), GPIO_FN(MOUT1),
-	GPIO_FN(SSI_WS0129), GPIO_FN(CAN_DEBUGOUT2), GPIO_FN(MOUT2),
-	GPIO_FN(SSI_SDATA0), GPIO_FN(CAN_DEBUGOUT3), GPIO_FN(MOUT5),
-	GPIO_FN(SSI_SDATA1), GPIO_FN(CAN_DEBUGOUT4), GPIO_FN(MOUT6),
-	GPIO_FN(SSI_SDATA2), GPIO_FN(CAN_DEBUGOUT5), GPIO_FN(SSI_SCK34),
-	GPIO_FN(CAN_DEBUGOUT6), GPIO_FN(CAN0_TX_B), GPIO_FN(IERX),
-	GPIO_FN(SSI_SCK9_C), GPIO_FN(SSI_WS34), GPIO_FN(CAN_DEBUGOUT7),
-	GPIO_FN(CAN0_RX_B), GPIO_FN(IETX), GPIO_FN(SSI_WS9_C),
-	GPIO_FN(SSI_SDATA3), GPIO_FN(PWM0_C), GPIO_FN(CAN_DEBUGOUT8),
-	GPIO_FN(CAN_CLK_B), GPIO_FN(IECLK), GPIO_FN(SCIF_CLK_B),
-	GPIO_FN(TCLK0_B), GPIO_FN(SSI_SDATA4), GPIO_FN(CAN_DEBUGOUT9),
-	GPIO_FN(SSI_SDATA9_C), GPIO_FN(SSI_SCK5), GPIO_FN(ADICLK),
-	GPIO_FN(CAN_DEBUGOUT10), GPIO_FN(TCLK0_D),
-	GPIO_FN(SSI_WS5), GPIO_FN(ADICS_SAMP), GPIO_FN(CAN_DEBUGOUT11),
-	GPIO_FN(SSI_SDATA5), GPIO_FN(ADIDATA),
-	GPIO_FN(CAN_DEBUGOUT12), GPIO_FN(SSI_SCK6),
-	GPIO_FN(ADICHS0), GPIO_FN(CAN0_TX), GPIO_FN(IERX_B),
-
-	/* IPSR7 */
-	GPIO_FN(SSI_WS6), GPIO_FN(ADICHS1), GPIO_FN(CAN0_RX), GPIO_FN(IETX_B),
-	GPIO_FN(SSI_SDATA6), GPIO_FN(ADICHS2), GPIO_FN(CAN_CLK),
-	GPIO_FN(IECLK_B), GPIO_FN(SSI_SCK78), GPIO_FN(CAN_DEBUGOUT13),
-	GPIO_FN(SSI_SCK9_B),
-	GPIO_FN(SSI_WS78), GPIO_FN(CAN_DEBUGOUT14),
-	GPIO_FN(SSI_WS9_B), GPIO_FN(SSI_SDATA7),
-	GPIO_FN(CAN_DEBUGOUT15), GPIO_FN(TCLK1_C),
-	GPIO_FN(SSI_SDATA8), GPIO_FN(VSP),
-	GPIO_FN(ATACS01), GPIO_FN(ATACS11),
-	GPIO_FN(CC5_TDO), GPIO_FN(ATADIR1),
-	GPIO_FN(CC5_TRST), GPIO_FN(ATAG1),
-	GPIO_FN(CC5_TMS), GPIO_FN(ATARD1),
-	GPIO_FN(CC5_TCK), GPIO_FN(ATAWR1),
-	GPIO_FN(CC5_TDI), GPIO_FN(DREQ2),
-	GPIO_FN(DACK2),
-
-	/* IPSR8 */
-	GPIO_FN(AD_CLK),
-	GPIO_FN(CC5_STATE4), GPIO_FN(CC5_STATE12), GPIO_FN(CC5_STATE20),
-	GPIO_FN(CC5_STATE28), GPIO_FN(CC5_STATE36),
-	GPIO_FN(AD_DI),
-	GPIO_FN(CC5_STATE5), GPIO_FN(CC5_STATE13), GPIO_FN(CC5_STATE21),
-	GPIO_FN(CC5_STATE29), GPIO_FN(CC5_STATE37),
-	GPIO_FN(CAN_DEBUG_HW_TRIGGER), GPIO_FN(AD_DO),
-	GPIO_FN(CC5_STATE6), GPIO_FN(CC5_STATE14), GPIO_FN(CC5_STATE22),
-	GPIO_FN(CC5_STATE30), GPIO_FN(CC5_STATE38),
-	GPIO_FN(CAN_STEP0), GPIO_FN(AD_NCS), GPIO_FN(CC5_STATE7),
-	GPIO_FN(CC5_STATE15), GPIO_FN(CC5_STATE23), GPIO_FN(CC5_STATE31),
-	GPIO_FN(CC5_STATE39), GPIO_FN(FMCLK), GPIO_FN(RDS_CLK), GPIO_FN(PCMOE),
-	GPIO_FN(BPFCLK), GPIO_FN(PCMWE), GPIO_FN(FMIN), GPIO_FN(RDS_DATA),
-	GPIO_FN(VI0_CLK), GPIO_FN(VI0_CLKENB),
-	GPIO_FN(HTX1_B), GPIO_FN(MT1_SYNC),
-	GPIO_FN(VI0_FIELD), GPIO_FN(HRX1_B),
-	GPIO_FN(VI0_HSYNC), GPIO_FN(VI0_DATA0_B_VI0_B0_B),
-	GPIO_FN(HSCK1_B),
-	GPIO_FN(VI0_VSYNC), GPIO_FN(VI0_DATA1_B_VI0_B1_B),
-	GPIO_FN(PWMFSW0_C),
-
-	/* IPSR9 */
-	GPIO_FN(VI0_DATA0_VI0_B0), GPIO_FN(HRTS1_B), GPIO_FN(MT1_VCXO),
-	GPIO_FN(VI0_DATA1_VI0_B1), GPIO_FN(HCTS1_B), GPIO_FN(MT1_PWM),
-	GPIO_FN(VI0_DATA2_VI0_B2), GPIO_FN(VI0_DATA3_VI0_B3),
-	GPIO_FN(VI0_DATA4_VI0_B4),
-	GPIO_FN(VI0_DATA5_VI0_B5), GPIO_FN(VI0_DATA6_VI0_B6),
-	GPIO_FN(ARM_TRACEDATA_0), GPIO_FN(VI0_DATA7_VI0_B7),
-	GPIO_FN(ARM_TRACEDATA_1), GPIO_FN(VI0_G0),
-	GPIO_FN(SSI_SCK78_C), GPIO_FN(ARM_TRACEDATA_2),
-	GPIO_FN(VI0_G1), GPIO_FN(SSI_WS78_C),
-	GPIO_FN(ARM_TRACEDATA_3), GPIO_FN(VI0_G2), GPIO_FN(ETH_TXD1),
-	GPIO_FN(ARM_TRACEDATA_4), GPIO_FN(TS_SPSYNC0),
-	GPIO_FN(VI0_G3), GPIO_FN(ETH_CRS_DV),
-	GPIO_FN(ARM_TRACEDATA_5), GPIO_FN(TS_SDAT0), GPIO_FN(VI0_G4),
-	GPIO_FN(ETH_TX_EN), GPIO_FN(ARM_TRACEDATA_6),
-	GPIO_FN(VI0_G5), GPIO_FN(ETH_RX_ER),
-	GPIO_FN(ARM_TRACEDATA_7), GPIO_FN(VI0_G6), GPIO_FN(ETH_RXD0),
-	GPIO_FN(ARM_TRACEDATA_8), GPIO_FN(VI0_G7),
-	GPIO_FN(ETH_RXD1), GPIO_FN(ARM_TRACEDATA_9),
-
-	/* IPSR10 */
-	GPIO_FN(VI0_R0), GPIO_FN(SSI_SDATA7_C),
-	GPIO_FN(DREQ1_B), GPIO_FN(ARM_TRACEDATA_10), GPIO_FN(DREQ0_C),
-	GPIO_FN(VI0_R1), GPIO_FN(SSI_SDATA8_C), GPIO_FN(DACK1_B),
-	GPIO_FN(ARM_TRACEDATA_11), GPIO_FN(DACK0_C), GPIO_FN(DRACK0_C),
-	GPIO_FN(VI0_R2), GPIO_FN(ETH_LINK),
-	GPIO_FN(ARM_TRACEDATA_12), GPIO_FN(VI0_R3), GPIO_FN(ETH_MAGIC),
-	GPIO_FN(ARM_TRACEDATA_13),
-	GPIO_FN(VI0_R4), GPIO_FN(ETH_REFCLK),
-	GPIO_FN(ARM_TRACEDATA_14), GPIO_FN(MT1_CLK),
-	GPIO_FN(TS_SCK0), GPIO_FN(VI0_R5), GPIO_FN(ETH_TXD0),
-	GPIO_FN(ARM_TRACEDATA_15),
-	GPIO_FN(MT1_D), GPIO_FN(TS_SDEN0), GPIO_FN(VI0_R6), GPIO_FN(ETH_MDC),
-	GPIO_FN(DREQ2_C), GPIO_FN(TRACECLK),
-	GPIO_FN(MT1_BEN), GPIO_FN(PWMFSW0_D), GPIO_FN(VI0_R7),
-	GPIO_FN(ETH_MDIO), GPIO_FN(DACK2_C),
-	GPIO_FN(SCIF_CLK_D), GPIO_FN(TRACECTL), GPIO_FN(MT1_PEN),
-	GPIO_FN(VI1_CLK), GPIO_FN(SIM_D), GPIO_FN(SDA3), GPIO_FN(VI1_HSYNC),
-	GPIO_FN(VI3_CLK), GPIO_FN(SSI_SCK4), GPIO_FN(GPS_SIGN_C),
-	GPIO_FN(PWMFSW0_E), GPIO_FN(VI1_VSYNC), GPIO_FN(AUDIO_CLKOUT_C),
-	GPIO_FN(SSI_WS4), GPIO_FN(SIM_CLK), GPIO_FN(GPS_MAG_C),
-	GPIO_FN(SPV_TRST), GPIO_FN(SCL3),
-
-	/* IPSR11 */
-	GPIO_FN(VI1_DATA0_VI1_B0), GPIO_FN(SIM_RST),
-	GPIO_FN(SPV_TCK), GPIO_FN(ADICLK_B), GPIO_FN(VI1_DATA1_VI1_B1),
-	GPIO_FN(MT0_CLK), GPIO_FN(SPV_TMS),
-	GPIO_FN(ADICS_B_SAMP_B), GPIO_FN(VI1_DATA2_VI1_B2),
-	GPIO_FN(MT0_D), GPIO_FN(SPVTDI), GPIO_FN(ADIDATA_B),
-	GPIO_FN(VI1_DATA3_VI1_B3), GPIO_FN(MT0_BEN),
-	GPIO_FN(SPV_TDO), GPIO_FN(ADICHS0_B), GPIO_FN(VI1_DATA4_VI1_B4),
-	GPIO_FN(MT0_PEN), GPIO_FN(SPA_TRST),
-	GPIO_FN(ADICHS1_B), GPIO_FN(VI1_DATA5_VI1_B5),
-	GPIO_FN(MT0_SYNC), GPIO_FN(SPA_TCK),
-	GPIO_FN(ADICHS2_B), GPIO_FN(VI1_DATA6_VI1_B6),
-	GPIO_FN(MT0_VCXO), GPIO_FN(SPA_TMS),
-	GPIO_FN(VI1_DATA7_VI1_B7),
-	GPIO_FN(MT0_PWM), GPIO_FN(SPA_TDI),
-	GPIO_FN(VI1_G0), GPIO_FN(VI3_DATA0),
-	GPIO_FN(TS_SCK1), GPIO_FN(DREQ2_B), GPIO_FN(SPA_TDO),
-	GPIO_FN(HCTS0_B), GPIO_FN(VI1_G1), GPIO_FN(VI3_DATA1),
-	GPIO_FN(SSI_SCK1), GPIO_FN(TS_SDEN1), GPIO_FN(DACK2_B),
-	GPIO_FN(HRTS0_B),
-
-	/* IPSR12 */
-	GPIO_FN(VI1_G2), GPIO_FN(VI3_DATA2), GPIO_FN(SSI_WS1),
-	GPIO_FN(TS_SPSYNC1), GPIO_FN(HSCK0_B), GPIO_FN(VI1_G3),
-	GPIO_FN(VI3_DATA3), GPIO_FN(SSI_SCK2), GPIO_FN(TS_SDAT1),
-	GPIO_FN(SCL1_C), GPIO_FN(HTX0_B), GPIO_FN(VI1_G4), GPIO_FN(VI3_DATA4),
-	GPIO_FN(SSI_WS2), GPIO_FN(SDA1_C), GPIO_FN(SIM_RST_B),
-	GPIO_FN(HRX0_B), GPIO_FN(VI1_G5), GPIO_FN(VI3_DATA5),
-	GPIO_FN(GPS_CLK), GPIO_FN(FSE), GPIO_FN(SIM_D_B),
-	GPIO_FN(VI1_G6), GPIO_FN(VI3_DATA6), GPIO_FN(GPS_SIGN), GPIO_FN(FRB),
-	GPIO_FN(SIM_CLK_B), GPIO_FN(VI1_G7),
-	GPIO_FN(VI3_DATA7), GPIO_FN(GPS_MAG), GPIO_FN(FCE),
-};
-
 static const struct pinmux_cfg_reg pinmux_config_regs[] = {
 	{ PINMUX_CFG_REG("GPSR0", 0xfffc0004, 32, 1) {
 		GP_0_31_FN, FN_IP3_31_29,
@@ -3831,9 +3563,6 @@ const struct sh_pfc_soc_info r8a7779_pinmux_info = {
 	.functions = pinmux_functions,
 	.nr_functions = ARRAY_SIZE(pinmux_functions),
 
-	.func_gpios = pinmux_func_gpios,
-	.nr_func_gpios = ARRAY_SIZE(pinmux_func_gpios),
-
 	.cfg_regs = pinmux_config_regs,
 	.data_regs = pinmux_data_regs,
 
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 22:04:48 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed,  3 Apr 2013 11:04:48 +0900
Subject: [PATCH 10/28] sh-pfc: Make GPIO support optional
In-Reply-To: <1364954706-14727-1-git-send-email-horms+renesas@verge.net.au>
References: <1364954706-14727-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364954706-14727-11-git-send-email-horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

When implemented as a separate IP block, GPIOs should be handled by a
separate driver. To make this possible GPIO support needs to be optional
in the sh-pfc driver.

If no GPIO data registers are supplied in the SoC information structure
skip registration of the gpiochip.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Acked-by: Linus Walleij <linus.walleij at linaro.org>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 drivers/pinctrl/sh-pfc/gpio.c |    3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/pinctrl/sh-pfc/gpio.c b/drivers/pinctrl/sh-pfc/gpio.c
index 7a54ec7..317cebb 100644
--- a/drivers/pinctrl/sh-pfc/gpio.c
+++ b/drivers/pinctrl/sh-pfc/gpio.c
@@ -354,6 +354,9 @@ int sh_pfc_register_gpiochip(struct sh_pfc *pfc)
 	unsigned int i;
 	int ret;
 
+	if (pfc->info->data_regs == NULL)
+		return 0;
+
 	/* Register the real GPIOs chip. */
 	chip = sh_pfc_add_gpiochip(pfc, gpio_pin_setup);
 	if (IS_ERR(chip))
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 22:04:51 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed,  3 Apr 2013 11:04:51 +0900
Subject: [PATCH 13/28] ARM: shmobile: r8a7779: Register GPIO devices
In-Reply-To: <1364954706-14727-1-git-send-email-horms+renesas@verge.net.au>
References: <1364954706-14727-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364954706-14727-14-git-send-email-horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

Move GPIOs handling from the PFC device to separate GPIO devices.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/setup-r8a7779.c |   58 ++++++++++++++++++++++++++++----
 1 file changed, 52 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-shmobile/setup-r8a7779.c b/arch/arm/mach-shmobile/setup-r8a7779.c
index 042df35..a460ba3 100644
--- a/arch/arm/mach-shmobile/setup-r8a7779.c
+++ b/arch/arm/mach-shmobile/setup-r8a7779.c
@@ -22,6 +22,7 @@
 #include <linux/interrupt.h>
 #include <linux/irq.h>
 #include <linux/of_platform.h>
+#include <linux/platform_data/gpio-rcar.h>
 #include <linux/platform_device.h>
 #include <linux/delay.h>
 #include <linux/input.h>
@@ -68,11 +69,6 @@ static struct resource r8a7779_pfc_resources[] = {
 		.end	= 0xfffc023b,
 		.flags	= IORESOURCE_MEM,
 	},
-	[1] = {
-		.start	= 0xffc40000,
-		.end	= 0xffc46fff,
-		.flags	= IORESOURCE_MEM,
-	}
 };
 
 static struct platform_device r8a7779_pfc_device = {
@@ -82,9 +78,59 @@ static struct platform_device r8a7779_pfc_device = {
 	.num_resources	= ARRAY_SIZE(r8a7779_pfc_resources),
 };
 
+#define R8A7779_GPIO(idx, npins) \
+static struct resource r8a7779_gpio##idx##_resources[] = {		\
+	[0] = {								\
+		.start	= 0xffc40000 + 0x1000 * (idx),			\
+		.end	= 0xffc4002b + 0x1000 * (idx),			\
+		.flags	= IORESOURCE_MEM,				\
+	},								\
+	[1] = {								\
+		.start	= gic_iid(0xad + (idx)),			\
+		.flags	= IORESOURCE_IRQ,				\
+	}								\
+};									\
+									\
+static struct gpio_rcar_config r8a7779_gpio##idx##_platform_data = {	\
+	.gpio_base	= 32 * (idx),					\
+	.irq_base	= 0,						\
+	.number_of_pins	= npins,					\
+	.pctl_name	= "pfc-r8a7779",				\
+};									\
+									\
+static struct platform_device r8a7779_gpio##idx##_device = {		\
+	.name		= "gpio_rcar",					\
+	.id		= idx,						\
+	.resource	= r8a7779_gpio##idx##_resources,		\
+	.num_resources	= ARRAY_SIZE(r8a7779_gpio##idx##_resources),	\
+	.dev		= {						\
+		.platform_data	= &r8a7779_gpio##idx##_platform_data,	\
+	},								\
+}
+
+R8A7779_GPIO(0, 32);
+R8A7779_GPIO(1, 32);
+R8A7779_GPIO(2, 32);
+R8A7779_GPIO(3, 32);
+R8A7779_GPIO(4, 32);
+R8A7779_GPIO(5, 32);
+R8A7779_GPIO(6, 9);
+
+static struct platform_device *r8a7779_pinctrl_devices[] __initdata = {
+	&r8a7779_pfc_device,
+	&r8a7779_gpio0_device,
+	&r8a7779_gpio1_device,
+	&r8a7779_gpio2_device,
+	&r8a7779_gpio3_device,
+	&r8a7779_gpio4_device,
+	&r8a7779_gpio5_device,
+	&r8a7779_gpio6_device,
+};
+
 void __init r8a7779_pinmux_init(void)
 {
-	platform_device_register(&r8a7779_pfc_device);
+	platform_add_devices(r8a7779_pinctrl_devices,
+			    ARRAY_SIZE(r8a7779_pinctrl_devices));
 }
 
 static struct plat_sci_port scif0_platform_data = {
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 22:04:50 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed,  3 Apr 2013 11:04:50 +0900
Subject: [PATCH 12/28] sh-pfc: Configure pins as GPIOs at request time when
 handled externally
In-Reply-To: <1364954706-14727-1-git-send-email-horms+renesas@verge.net.au>
References: <1364954706-14727-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364954706-14727-13-git-send-email-horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

When a GPIO is handled by a separate driver the pinmux
gpio_set_direction() handler won't be called. The pin mux type then need
to be configured to GPIO at request time.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 drivers/pinctrl/sh-pfc/core.c    |   37 ++++++++++++++++---------------------
 drivers/pinctrl/sh-pfc/pinctrl.c |   11 +++++++++++
 2 files changed, 27 insertions(+), 21 deletions(-)

diff --git a/drivers/pinctrl/sh-pfc/core.c b/drivers/pinctrl/sh-pfc/core.c
index 97e6ea3..ced9a95 100644
--- a/drivers/pinctrl/sh-pfc/core.c
+++ b/drivers/pinctrl/sh-pfc/core.c
@@ -268,7 +268,7 @@ int sh_pfc_config_mux(struct sh_pfc *pfc, unsigned mark, int pinmux_type)
 	int ret;
 
 	switch (pinmux_type) {
-
+	case PINMUX_TYPE_GPIO:
 	case PINMUX_TYPE_FUNCTION:
 		range = NULL;
 		break;
@@ -297,6 +297,8 @@ int sh_pfc_config_mux(struct sh_pfc *pfc, unsigned mark, int pinmux_type)
 	enum_id = 0;
 	field = 0;
 	value = 0;
+
+	/* Iterate over all the configuration fields we need to update. */
 	while (1) {
 		pos = sh_pfc_mark_to_enum(pfc, mark, pos, &enum_id);
 		if (pos < 0)
@@ -305,18 +307,20 @@ int sh_pfc_config_mux(struct sh_pfc *pfc, unsigned mark, int pinmux_type)
 		if (!enum_id)
 			break;
 
-		/* first check if this is a function enum */
+		/* Check if the configuration field selects a function. If it
+		 * doesn't, skip the field if it's not applicable to the
+		 * requested pinmux type.
+		 */
 		in_range = sh_pfc_enum_in_range(enum_id, &pfc->info->function);
 		if (!in_range) {
-			/* not a function enum */
-			if (range) {
-				/*
-				 * other range exists, so this pin is
-				 * a regular GPIO pin that now is being
-				 * bound to a specific direction.
-				 *
-				 * for this case we only allow function enums
-				 * and the enums that match the other range.
+			if (pinmux_type == PINMUX_TYPE_FUNCTION) {
+				/* Functions are allowed to modify all
+				 * fields.
+				 */
+				in_range = 1;
+			} else if (pinmux_type != PINMUX_TYPE_GPIO) {
+				/* Input/output types can only modify fields
+				 * that correspond to their respective ranges.
 				 */
 				in_range = sh_pfc_enum_in_range(enum_id, range);
 
@@ -327,17 +331,8 @@ int sh_pfc_config_mux(struct sh_pfc *pfc, unsigned mark, int pinmux_type)
 				 */
 				if (in_range && enum_id == range->force)
 					continue;
-			} else {
-				/*
-				 * no other range exists, so this pin
-				 * must then be of the function type.
-				 *
-				 * allow function type pins to select
-				 * any combination of function/in/out
-				 * in their MARK lists.
-				 */
-				in_range = 1;
 			}
+			/* GPIOs are only allowed to modify function fields. */
 		}
 
 		if (!in_range)
diff --git a/drivers/pinctrl/sh-pfc/pinctrl.c b/drivers/pinctrl/sh-pfc/pinctrl.c
index aef268b..3492ec9 100644
--- a/drivers/pinctrl/sh-pfc/pinctrl.c
+++ b/drivers/pinctrl/sh-pfc/pinctrl.c
@@ -182,6 +182,17 @@ static int sh_pfc_gpio_request_enable(struct pinctrl_dev *pctldev,
 		goto done;
 	}
 
+	if (!pfc->gpio) {
+		/* If GPIOs are handled externally the pin mux type need to be
+		 * set to GPIO here.
+		 */
+		const struct sh_pfc_pin *pin = &pfc->info->pins[idx];
+
+		ret = sh_pfc_config_mux(pfc, pin->enum_id, PINMUX_TYPE_GPIO);
+		if (ret < 0)
+			goto done;
+	}
+
 	cfg->type = PINMUX_TYPE_GPIO;
 
 	ret = 0;
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 22:04:43 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed,  3 Apr 2013 11:04:43 +0900
Subject: [PATCH 05/28] ARM: shmobile: r8a7779: Remove all GPIOs
In-Reply-To: <1364954706-14727-1-git-send-email-horms+renesas@verge.net.au>
References: <1364954706-14727-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364954706-14727-6-git-send-email-horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

Function GPIOs are not used anymore, and all code use the GPIO numbers
directly. Remove the GPIOs enumeration.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Acked-by: Linus Walleij <linus.walleij at linaro.org>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/include/mach/r8a7779.h |  317 -------------------------
 1 file changed, 317 deletions(-)

diff --git a/arch/arm/mach-shmobile/include/mach/r8a7779.h b/arch/arm/mach-shmobile/include/mach/r8a7779.h
index 68c3b2d..945299e 100644
--- a/arch/arm/mach-shmobile/include/mach/r8a7779.h
+++ b/arch/arm/mach-shmobile/include/mach/r8a7779.h
@@ -4,323 +4,6 @@
 #include <linux/sh_clk.h>
 #include <linux/pm_domain.h>
 
-/* Pin Function Controller:
- * GPIO_FN_xx - GPIO used to select pin function
- * GPIO_GP_x_x - GPIO mapped to real I/O pin on CPU
- */
-enum {
-	GPIO_GP_0_0, GPIO_GP_0_1, GPIO_GP_0_2, GPIO_GP_0_3,
-	GPIO_GP_0_4, GPIO_GP_0_5, GPIO_GP_0_6, GPIO_GP_0_7,
-	GPIO_GP_0_8, GPIO_GP_0_9, GPIO_GP_0_10, GPIO_GP_0_11,
-	GPIO_GP_0_12, GPIO_GP_0_13, GPIO_GP_0_14, GPIO_GP_0_15,
-	GPIO_GP_0_16, GPIO_GP_0_17, GPIO_GP_0_18, GPIO_GP_0_19,
-	GPIO_GP_0_20, GPIO_GP_0_21, GPIO_GP_0_22, GPIO_GP_0_23,
-	GPIO_GP_0_24, GPIO_GP_0_25, GPIO_GP_0_26, GPIO_GP_0_27,
-	GPIO_GP_0_28, GPIO_GP_0_29, GPIO_GP_0_30, GPIO_GP_0_31,
-
-	GPIO_GP_1_0, GPIO_GP_1_1, GPIO_GP_1_2, GPIO_GP_1_3,
-	GPIO_GP_1_4, GPIO_GP_1_5, GPIO_GP_1_6, GPIO_GP_1_7,
-	GPIO_GP_1_8, GPIO_GP_1_9, GPIO_GP_1_10, GPIO_GP_1_11,
-	GPIO_GP_1_12, GPIO_GP_1_13, GPIO_GP_1_14, GPIO_GP_1_15,
-	GPIO_GP_1_16, GPIO_GP_1_17, GPIO_GP_1_18, GPIO_GP_1_19,
-	GPIO_GP_1_20, GPIO_GP_1_21, GPIO_GP_1_22, GPIO_GP_1_23,
-	GPIO_GP_1_24, GPIO_GP_1_25, GPIO_GP_1_26, GPIO_GP_1_27,
-	GPIO_GP_1_28, GPIO_GP_1_29, GPIO_GP_1_30, GPIO_GP_1_31,
-
-	GPIO_GP_2_0, GPIO_GP_2_1, GPIO_GP_2_2, GPIO_GP_2_3,
-	GPIO_GP_2_4, GPIO_GP_2_5, GPIO_GP_2_6, GPIO_GP_2_7,
-	GPIO_GP_2_8, GPIO_GP_2_9, GPIO_GP_2_10, GPIO_GP_2_11,
-	GPIO_GP_2_12, GPIO_GP_2_13, GPIO_GP_2_14, GPIO_GP_2_15,
-	GPIO_GP_2_16, GPIO_GP_2_17, GPIO_GP_2_18, GPIO_GP_2_19,
-	GPIO_GP_2_20, GPIO_GP_2_21, GPIO_GP_2_22, GPIO_GP_2_23,
-	GPIO_GP_2_24, GPIO_GP_2_25, GPIO_GP_2_26, GPIO_GP_2_27,
-	GPIO_GP_2_28, GPIO_GP_2_29, GPIO_GP_2_30, GPIO_GP_2_31,
-
-	GPIO_GP_3_0, GPIO_GP_3_1, GPIO_GP_3_2, GPIO_GP_3_3,
-	GPIO_GP_3_4, GPIO_GP_3_5, GPIO_GP_3_6, GPIO_GP_3_7,
-	GPIO_GP_3_8, GPIO_GP_3_9, GPIO_GP_3_10, GPIO_GP_3_11,
-	GPIO_GP_3_12, GPIO_GP_3_13, GPIO_GP_3_14, GPIO_GP_3_15,
-	GPIO_GP_3_16, GPIO_GP_3_17, GPIO_GP_3_18, GPIO_GP_3_19,
-	GPIO_GP_3_20, GPIO_GP_3_21, GPIO_GP_3_22, GPIO_GP_3_23,
-	GPIO_GP_3_24, GPIO_GP_3_25, GPIO_GP_3_26, GPIO_GP_3_27,
-	GPIO_GP_3_28, GPIO_GP_3_29, GPIO_GP_3_30, GPIO_GP_3_31,
-
-	GPIO_GP_4_0, GPIO_GP_4_1, GPIO_GP_4_2, GPIO_GP_4_3,
-	GPIO_GP_4_4, GPIO_GP_4_5, GPIO_GP_4_6, GPIO_GP_4_7,
-	GPIO_GP_4_8, GPIO_GP_4_9, GPIO_GP_4_10, GPIO_GP_4_11,
-	GPIO_GP_4_12, GPIO_GP_4_13, GPIO_GP_4_14, GPIO_GP_4_15,
-	GPIO_GP_4_16, GPIO_GP_4_17, GPIO_GP_4_18, GPIO_GP_4_19,
-	GPIO_GP_4_20, GPIO_GP_4_21, GPIO_GP_4_22, GPIO_GP_4_23,
-	GPIO_GP_4_24, GPIO_GP_4_25, GPIO_GP_4_26, GPIO_GP_4_27,
-	GPIO_GP_4_28, GPIO_GP_4_29, GPIO_GP_4_30, GPIO_GP_4_31,
-
-	GPIO_GP_5_0, GPIO_GP_5_1, GPIO_GP_5_2, GPIO_GP_5_3,
-	GPIO_GP_5_4, GPIO_GP_5_5, GPIO_GP_5_6, GPIO_GP_5_7,
-	GPIO_GP_5_8, GPIO_GP_5_9, GPIO_GP_5_10, GPIO_GP_5_11,
-	GPIO_GP_5_12, GPIO_GP_5_13, GPIO_GP_5_14, GPIO_GP_5_15,
-	GPIO_GP_5_16, GPIO_GP_5_17, GPIO_GP_5_18, GPIO_GP_5_19,
-	GPIO_GP_5_20, GPIO_GP_5_21, GPIO_GP_5_22, GPIO_GP_5_23,
-	GPIO_GP_5_24, GPIO_GP_5_25, GPIO_GP_5_26, GPIO_GP_5_27,
-	GPIO_GP_5_28, GPIO_GP_5_29, GPIO_GP_5_30, GPIO_GP_5_31,
-
-	GPIO_GP_6_0, GPIO_GP_6_1, GPIO_GP_6_2, GPIO_GP_6_3,
-	GPIO_GP_6_4, GPIO_GP_6_5, GPIO_GP_6_6, GPIO_GP_6_7,
-	GPIO_GP_6_8,
-
-	GPIO_FN_AVS1, GPIO_FN_AVS2, GPIO_FN_A17, GPIO_FN_A18,
-	GPIO_FN_A19,
-
-	/* IPSR0 */
-	GPIO_FN_PWM1, GPIO_FN_PWMFSW0,
-	GPIO_FN_SCIF_CLK, GPIO_FN_TCLK0_C, GPIO_FN_BS,
-	GPIO_FN_FD2, GPIO_FN_ATADIR0, GPIO_FN_SDSELF,
-	GPIO_FN_HCTS1, GPIO_FN_A0,
-	GPIO_FN_FD3, GPIO_FN_A20,
-	GPIO_FN_A21,
-	GPIO_FN_A22, GPIO_FN_VI1_R0,
-	GPIO_FN_A23, GPIO_FN_FCLE, GPIO_FN_VI1_R1,
-	GPIO_FN_A24, GPIO_FN_FD4,
-	GPIO_FN_VI1_R2, GPIO_FN_SSI_WS78_B, GPIO_FN_A25,
-	GPIO_FN_FD5,
-	GPIO_FN_VI1_R3, GPIO_FN_SSI_SDATA7_B,
-	GPIO_FN_CLKOUT, GPIO_FN_PWM0_B,
-	GPIO_FN_SDSELF_B, GPIO_FN_RD_WR, GPIO_FN_FWE, GPIO_FN_ATAG0,
-	GPIO_FN_VI1_R7, GPIO_FN_HRTS1,
-
-	/* IPSR1 */
-	GPIO_FN_FD6, GPIO_FN_FD7,
-	GPIO_FN_FALE,
-	GPIO_FN_ATACS00,
-	GPIO_FN_FRE, GPIO_FN_ATACS10, GPIO_FN_VI1_R4,
-	GPIO_FN_HSCK1, GPIO_FN_SSI_SDATA8_B,
-	GPIO_FN_SSI_SDATA9,
-	GPIO_FN_FD0, GPIO_FN_ATARD0, GPIO_FN_VI1_R5,
-	GPIO_FN_HTX1, GPIO_FN_SSI_SCK9,
-	GPIO_FN_FD1,
-	GPIO_FN_ATAWR0, GPIO_FN_VI1_R6, GPIO_FN_HRX1,
-	GPIO_FN_SSI_WS9, GPIO_FN_MLB_CLK, GPIO_FN_PWM2,
-	GPIO_FN_MLB_SIG, GPIO_FN_PWM3,
-	GPIO_FN_MLB_DAT, GPIO_FN_PWM4, GPIO_FN_HTX0,
-	GPIO_FN_SDATA, GPIO_FN_SUB_TCK,
-	GPIO_FN_CC5_STATE2, GPIO_FN_CC5_STATE10, GPIO_FN_CC5_STATE18,
-	GPIO_FN_CC5_STATE26, GPIO_FN_CC5_STATE34,
-
-	/* IPSR2 */
-	GPIO_FN_HRX0, GPIO_FN_SCKZ,
-	GPIO_FN_SUB_TDI, GPIO_FN_CC5_STATE3, GPIO_FN_CC5_STATE11,
-	GPIO_FN_CC5_STATE19, GPIO_FN_CC5_STATE27, GPIO_FN_CC5_STATE35,
-	GPIO_FN_HSCK0, GPIO_FN_MTS, GPIO_FN_PWM5,
-	GPIO_FN_SSI_SDATA9_B, GPIO_FN_SUB_TDO,
-	GPIO_FN_CC5_STATE0, GPIO_FN_CC5_STATE8, GPIO_FN_CC5_STATE16,
-	GPIO_FN_CC5_STATE24, GPIO_FN_CC5_STATE32, GPIO_FN_HCTS0,
-	GPIO_FN_STM, GPIO_FN_PWM0_D, GPIO_FN_SCIF_CLK_C,
-	GPIO_FN_SUB_TRST, GPIO_FN_TCLK1_B, GPIO_FN_CC5_OSCOUT, GPIO_FN_HRTS0,
-	GPIO_FN_MDATA, GPIO_FN_SUB_TMS,
-	GPIO_FN_CC5_STATE1, GPIO_FN_CC5_STATE9, GPIO_FN_CC5_STATE17,
-	GPIO_FN_CC5_STATE25, GPIO_FN_CC5_STATE33,
-	GPIO_FN_LCDOUT0, GPIO_FN_DREQ0, GPIO_FN_GPS_CLK_B, GPIO_FN_AUDATA0,
-	GPIO_FN_LCDOUT1, GPIO_FN_DACK0,
-	GPIO_FN_DRACK0, GPIO_FN_GPS_SIGN_B, GPIO_FN_AUDATA1,
-	GPIO_FN_LCDOUT2, GPIO_FN_LCDOUT3,
-	GPIO_FN_LCDOUT4, GPIO_FN_LCDOUT5,
-	GPIO_FN_LCDOUT6, GPIO_FN_LCDOUT7,
-	GPIO_FN_LCDOUT8, GPIO_FN_DREQ1, GPIO_FN_SCL2,
-	GPIO_FN_AUDATA2,
-
-	/* IPSR3 */
-	GPIO_FN_LCDOUT9, GPIO_FN_DACK1, GPIO_FN_SDA2,
-	GPIO_FN_AUDATA3, GPIO_FN_LCDOUT10,
-	GPIO_FN_LCDOUT11, GPIO_FN_LCDOUT12,
-	GPIO_FN_LCDOUT13, GPIO_FN_LCDOUT14,
-	GPIO_FN_LCDOUT15, GPIO_FN_LCDOUT16, GPIO_FN_EX_WAIT1,
-	GPIO_FN_SCL1, GPIO_FN_TCLK1, GPIO_FN_AUDATA4,
-	GPIO_FN_LCDOUT17, GPIO_FN_EX_WAIT2, GPIO_FN_SDA1, GPIO_FN_GPS_MAG_B,
-	GPIO_FN_AUDATA5, GPIO_FN_LCDOUT18,
-	GPIO_FN_LCDOUT19, GPIO_FN_LCDOUT20,
-	GPIO_FN_LCDOUT21, GPIO_FN_LCDOUT22,
-	GPIO_FN_LCDOUT23,
-	GPIO_FN_QSTVA_QVS, GPIO_FN_SCL3_B,
-	GPIO_FN_QCLK,
-	GPIO_FN_QSTVB_QVE, GPIO_FN_SDA3_B,
-	GPIO_FN_SDA2_C, GPIO_FN_DACK0_B, GPIO_FN_DRACK0_B,
-	GPIO_FN_QSTH_QHS,
-	GPIO_FN_QSTB_QHE,
-	GPIO_FN_QCPV_QDE,
-	GPIO_FN_CAN1_TX, GPIO_FN_SCL2_C, GPIO_FN_REMOCON,
-
-	/* IPSR4 */
-	GPIO_FN_QPOLA, GPIO_FN_CAN_CLK_C,
-	GPIO_FN_QPOLB, GPIO_FN_CAN1_RX,
-	GPIO_FN_DREQ0_B, GPIO_FN_SSI_SCK78_B,
-	GPIO_FN_VI2_DATA0_VI2_B0, GPIO_FN_PWM6,
-	GPIO_FN_AUDCK, GPIO_FN_PWMFSW0_B,
-	GPIO_FN_VI2_DATA1_VI2_B1, GPIO_FN_PWM0,
-	GPIO_FN_AUDSYNC,
-	GPIO_FN_VI2_G0,
-	GPIO_FN_VI2_G1, GPIO_FN_VI2_G2,
-	GPIO_FN_VI2_G3, GPIO_FN_VI2_G4,
-	GPIO_FN_VI2_G5, GPIO_FN_VI2_DATA2_VI2_B2,
-	GPIO_FN_SCL1_B, GPIO_FN_AUDATA6,
-	GPIO_FN_VI2_DATA3_VI2_B3,
-	GPIO_FN_SDA1_B, GPIO_FN_AUDATA7,
-	GPIO_FN_VI2_G6,
-	GPIO_FN_VI2_G7, GPIO_FN_VI2_R0,
-	GPIO_FN_VI2_R1, GPIO_FN_VI2_R2,
-	GPIO_FN_VI2_R3, GPIO_FN_VI2_DATA4_VI2_B4,
-	GPIO_FN_SCL2_B,
-
-	/* IPSR5 */
-	GPIO_FN_VI2_DATA5_VI2_B5, GPIO_FN_SDA2_B,
-	GPIO_FN_VI2_R4, GPIO_FN_VI2_R5,
-	GPIO_FN_VI2_R6, GPIO_FN_VI2_R7,
-	GPIO_FN_SCL2_D, GPIO_FN_SDA2_D,
-	GPIO_FN_VI2_CLKENB,
-	GPIO_FN_SCL1_D, GPIO_FN_VI2_FIELD,
-	GPIO_FN_SDA1_D, GPIO_FN_VI2_HSYNC,
-	GPIO_FN_VI3_HSYNC, GPIO_FN_VI2_VSYNC,
-	GPIO_FN_VI3_VSYNC,
-	GPIO_FN_VI2_CLK,
-	GPIO_FN_VI1_CLKENB, GPIO_FN_VI3_CLKENB,
-	GPIO_FN_AUDIO_CLKC, GPIO_FN_SPEEDIN,
-	GPIO_FN_GPS_SIGN_D, GPIO_FN_VI2_DATA6_VI2_B6,
-	GPIO_FN_TCLK0, GPIO_FN_QSTVA_B_QVS_B,
-	GPIO_FN_AUDIO_CLKOUT_B, GPIO_FN_GPS_MAG_D,
-	GPIO_FN_VI2_DATA7_VI2_B7,
-	GPIO_FN_VI1_FIELD, GPIO_FN_VI3_FIELD,
-	GPIO_FN_AUDIO_CLKOUT, GPIO_FN_GPS_CLK_C,
-	GPIO_FN_GPS_CLK_D, GPIO_FN_AUDIO_CLKA, GPIO_FN_CAN_TXCLK,
-	GPIO_FN_AUDIO_CLKB, GPIO_FN_CAN_DEBUGOUT0,
-	GPIO_FN_MOUT0,
-
-	/* IPSR6 */
-	GPIO_FN_SSI_SCK0129, GPIO_FN_CAN_DEBUGOUT1, GPIO_FN_MOUT1,
-	GPIO_FN_SSI_WS0129, GPIO_FN_CAN_DEBUGOUT2, GPIO_FN_MOUT2,
-	GPIO_FN_SSI_SDATA0, GPIO_FN_CAN_DEBUGOUT3, GPIO_FN_MOUT5,
-	GPIO_FN_SSI_SDATA1, GPIO_FN_CAN_DEBUGOUT4, GPIO_FN_MOUT6,
-	GPIO_FN_SSI_SDATA2, GPIO_FN_CAN_DEBUGOUT5, GPIO_FN_SSI_SCK34,
-	GPIO_FN_CAN_DEBUGOUT6, GPIO_FN_CAN0_TX_B, GPIO_FN_IERX,
-	GPIO_FN_SSI_SCK9_C, GPIO_FN_SSI_WS34, GPIO_FN_CAN_DEBUGOUT7,
-	GPIO_FN_CAN0_RX_B, GPIO_FN_IETX, GPIO_FN_SSI_WS9_C,
-	GPIO_FN_SSI_SDATA3, GPIO_FN_PWM0_C, GPIO_FN_CAN_DEBUGOUT8,
-	GPIO_FN_CAN_CLK_B, GPIO_FN_IECLK, GPIO_FN_SCIF_CLK_B, GPIO_FN_TCLK0_B,
-	GPIO_FN_SSI_SDATA4, GPIO_FN_CAN_DEBUGOUT9, GPIO_FN_SSI_SDATA9_C,
-	GPIO_FN_SSI_SCK5, GPIO_FN_ADICLK, GPIO_FN_CAN_DEBUGOUT10,
-	GPIO_FN_TCLK0_D, GPIO_FN_SSI_WS5, GPIO_FN_ADICS_SAMP,
-	GPIO_FN_CAN_DEBUGOUT11, GPIO_FN_SSI_SDATA5,
-	GPIO_FN_ADIDATA, GPIO_FN_CAN_DEBUGOUT12,
-	GPIO_FN_SSI_SCK6, GPIO_FN_ADICHS0, GPIO_FN_CAN0_TX, GPIO_FN_IERX_B,
-
-	/* IPSR7 */
-	GPIO_FN_SSI_WS6, GPIO_FN_ADICHS1, GPIO_FN_CAN0_RX, GPIO_FN_IETX_B,
-	GPIO_FN_SSI_SDATA6, GPIO_FN_ADICHS2, GPIO_FN_CAN_CLK, GPIO_FN_IECLK_B,
-	GPIO_FN_SSI_SCK78, GPIO_FN_CAN_DEBUGOUT13,
-	GPIO_FN_SSI_SCK9_B, GPIO_FN_SSI_WS78,
-	GPIO_FN_CAN_DEBUGOUT14, GPIO_FN_SSI_WS9_B,
-	GPIO_FN_SSI_SDATA7, GPIO_FN_CAN_DEBUGOUT15,
-	GPIO_FN_TCLK1_C,
-	GPIO_FN_SSI_SDATA8, GPIO_FN_VSP,
-	GPIO_FN_ATACS01,
-	GPIO_FN_ATACS11, GPIO_FN_CC5_TDO,
-	GPIO_FN_ATADIR1, GPIO_FN_CC5_TRST,
-	GPIO_FN_ATAG1, GPIO_FN_CC5_TMS,
-	GPIO_FN_ATARD1,	GPIO_FN_CC5_TCK,
-	GPIO_FN_ATAWR1,	GPIO_FN_CC5_TDI,
-	GPIO_FN_DREQ2,	GPIO_FN_DACK2,
-
-	/* IPSR8 */
-	GPIO_FN_AD_CLK,
-	GPIO_FN_CC5_STATE4, GPIO_FN_CC5_STATE12, GPIO_FN_CC5_STATE20,
-	GPIO_FN_CC5_STATE28, GPIO_FN_CC5_STATE36,
-	GPIO_FN_AD_DI,
-	GPIO_FN_CC5_STATE5, GPIO_FN_CC5_STATE13, GPIO_FN_CC5_STATE21,
-	GPIO_FN_CC5_STATE29, GPIO_FN_CC5_STATE37,
-	GPIO_FN_CAN_DEBUG_HW_TRIGGER, GPIO_FN_AD_DO,
-	GPIO_FN_CC5_STATE6, GPIO_FN_CC5_STATE14, GPIO_FN_CC5_STATE22,
-	GPIO_FN_CC5_STATE30, GPIO_FN_CC5_STATE38,
-	GPIO_FN_CAN_STEP0, GPIO_FN_AD_NCS, GPIO_FN_CC5_STATE7,
-	GPIO_FN_CC5_STATE15, GPIO_FN_CC5_STATE23, GPIO_FN_CC5_STATE31,
-	GPIO_FN_CC5_STATE39, GPIO_FN_FMCLK, GPIO_FN_RDS_CLK, GPIO_FN_PCMOE,
-	GPIO_FN_BPFCLK, GPIO_FN_PCMWE, GPIO_FN_FMIN, GPIO_FN_RDS_DATA,
-	GPIO_FN_VI0_CLK, GPIO_FN_VI0_CLKENB,
-	GPIO_FN_HTX1_B, GPIO_FN_MT1_SYNC, GPIO_FN_VI0_FIELD,
-	GPIO_FN_HRX1_B, GPIO_FN_VI0_HSYNC, GPIO_FN_VI0_DATA0_B_VI0_B0_B,
-	GPIO_FN_HSCK1_B,
-	GPIO_FN_VI0_VSYNC, GPIO_FN_VI0_DATA1_B_VI0_B1_B,
-	GPIO_FN_PWMFSW0_C,
-
-	/* IPSR9 */
-	GPIO_FN_VI0_DATA0_VI0_B0, GPIO_FN_HRTS1_B, GPIO_FN_MT1_VCXO,
-	GPIO_FN_VI0_DATA1_VI0_B1, GPIO_FN_HCTS1_B, GPIO_FN_MT1_PWM,
-	GPIO_FN_VI0_DATA2_VI0_B2, GPIO_FN_VI0_DATA3_VI0_B3,
-	GPIO_FN_VI0_DATA4_VI0_B4,
-	GPIO_FN_VI0_DATA5_VI0_B5, GPIO_FN_VI0_DATA6_VI0_B6,
-	GPIO_FN_ARM_TRACEDATA_0, GPIO_FN_VI0_DATA7_VI0_B7,
-	GPIO_FN_ARM_TRACEDATA_1, GPIO_FN_VI0_G0,
-	GPIO_FN_SSI_SCK78_C, GPIO_FN_ARM_TRACEDATA_2,
-	GPIO_FN_VI0_G1, GPIO_FN_SSI_WS78_C,
-	GPIO_FN_ARM_TRACEDATA_3, GPIO_FN_VI0_G2, GPIO_FN_ETH_TXD1,
-	GPIO_FN_ARM_TRACEDATA_4, GPIO_FN_TS_SPSYNC0,
-	GPIO_FN_VI0_G3, GPIO_FN_ETH_CRS_DV,
-	GPIO_FN_ARM_TRACEDATA_5, GPIO_FN_TS_SDAT0, GPIO_FN_VI0_G4,
-	GPIO_FN_ETH_TX_EN, GPIO_FN_ARM_TRACEDATA_6,
-	GPIO_FN_VI0_G5,	GPIO_FN_ETH_RX_ER,
-	GPIO_FN_ARM_TRACEDATA_7, GPIO_FN_VI0_G6, GPIO_FN_ETH_RXD0,
-	GPIO_FN_ARM_TRACEDATA_8, GPIO_FN_VI0_G7,
-	GPIO_FN_ETH_RXD1, GPIO_FN_ARM_TRACEDATA_9,
-
-	/* IPSR10 */
-	GPIO_FN_VI0_R0, GPIO_FN_SSI_SDATA7_C, GPIO_FN_DREQ1_B,
-	GPIO_FN_ARM_TRACEDATA_10, GPIO_FN_DREQ0_C, GPIO_FN_VI0_R1,
-	GPIO_FN_SSI_SDATA8_C, GPIO_FN_DACK1_B, GPIO_FN_ARM_TRACEDATA_11,
-	GPIO_FN_DACK0_C, GPIO_FN_DRACK0_C, GPIO_FN_VI0_R2, GPIO_FN_ETH_LINK,
-	GPIO_FN_ARM_TRACEDATA_12,
-	GPIO_FN_VI0_R3, GPIO_FN_ETH_MAGIC,
-	GPIO_FN_ARM_TRACEDATA_13, GPIO_FN_VI0_R4, GPIO_FN_ETH_REFCLK,
-	GPIO_FN_ARM_TRACEDATA_14,
-	GPIO_FN_MT1_CLK, GPIO_FN_TS_SCK0, GPIO_FN_VI0_R5, GPIO_FN_ETH_TXD0,
-	GPIO_FN_ARM_TRACEDATA_15,
-	GPIO_FN_MT1_D, GPIO_FN_TS_SDEN0, GPIO_FN_VI0_R6, GPIO_FN_ETH_MDC,
-	GPIO_FN_DREQ2_C, GPIO_FN_TRACECLK,
-	GPIO_FN_MT1_BEN, GPIO_FN_PWMFSW0_D, GPIO_FN_VI0_R7, GPIO_FN_ETH_MDIO,
-	GPIO_FN_DACK2_C, GPIO_FN_SCIF_CLK_D,
-	GPIO_FN_TRACECTL, GPIO_FN_MT1_PEN, GPIO_FN_VI1_CLK, GPIO_FN_SIM_D,
-	GPIO_FN_SDA3, GPIO_FN_VI1_HSYNC, GPIO_FN_VI3_CLK, GPIO_FN_SSI_SCK4,
-	GPIO_FN_GPS_SIGN_C, GPIO_FN_PWMFSW0_E, GPIO_FN_VI1_VSYNC,
-	GPIO_FN_AUDIO_CLKOUT_C, GPIO_FN_SSI_WS4, GPIO_FN_SIM_CLK,
-	GPIO_FN_GPS_MAG_C, GPIO_FN_SPV_TRST, GPIO_FN_SCL3,
-
-	/* IPSR11 */
-	GPIO_FN_VI1_DATA0_VI1_B0, GPIO_FN_SIM_RST,
-	GPIO_FN_SPV_TCK, GPIO_FN_ADICLK_B, GPIO_FN_VI1_DATA1_VI1_B1,
-	GPIO_FN_MT0_CLK, GPIO_FN_SPV_TMS,
-	GPIO_FN_ADICS_B_SAMP_B, GPIO_FN_VI1_DATA2_VI1_B2,
-	GPIO_FN_MT0_D, GPIO_FN_SPVTDI, GPIO_FN_ADIDATA_B,
-	GPIO_FN_VI1_DATA3_VI1_B3, GPIO_FN_MT0_BEN,
-	GPIO_FN_SPV_TDO, GPIO_FN_ADICHS0_B, GPIO_FN_VI1_DATA4_VI1_B4,
-	GPIO_FN_MT0_PEN, GPIO_FN_SPA_TRST,
-	GPIO_FN_ADICHS1_B, GPIO_FN_VI1_DATA5_VI1_B5,
-	GPIO_FN_MT0_SYNC, GPIO_FN_SPA_TCK,
-	GPIO_FN_ADICHS2_B, GPIO_FN_VI1_DATA6_VI1_B6,
-	GPIO_FN_MT0_VCXO, GPIO_FN_SPA_TMS,
-	GPIO_FN_VI1_DATA7_VI1_B7, GPIO_FN_MT0_PWM,
-	GPIO_FN_SPA_TDI, GPIO_FN_VI1_G0, GPIO_FN_VI3_DATA0,
-	GPIO_FN_TS_SCK1, GPIO_FN_DREQ2_B,
-	GPIO_FN_SPA_TDO, GPIO_FN_HCTS0_B, GPIO_FN_VI1_G1, GPIO_FN_VI3_DATA1,
-	GPIO_FN_SSI_SCK1, GPIO_FN_TS_SDEN1, GPIO_FN_DACK2_B,
-	GPIO_FN_HRTS0_B,
-
-	/* IPSR12 */
-	GPIO_FN_VI1_G2, GPIO_FN_VI3_DATA2, GPIO_FN_SSI_WS1, GPIO_FN_TS_SPSYNC1,
-	GPIO_FN_HSCK0_B, GPIO_FN_VI1_G3, GPIO_FN_VI3_DATA3,
-	GPIO_FN_SSI_SCK2, GPIO_FN_TS_SDAT1, GPIO_FN_SCL1_C, GPIO_FN_HTX0_B,
-	GPIO_FN_VI1_G4, GPIO_FN_VI3_DATA4, GPIO_FN_SSI_WS2, GPIO_FN_SDA1_C,
-	GPIO_FN_SIM_RST_B, GPIO_FN_HRX0_B, GPIO_FN_VI1_G5, GPIO_FN_VI3_DATA5,
-	GPIO_FN_GPS_CLK, GPIO_FN_FSE, GPIO_FN_SIM_D_B,
-	GPIO_FN_VI1_G6, GPIO_FN_VI3_DATA6, GPIO_FN_GPS_SIGN, GPIO_FN_FRB,
-	GPIO_FN_SIM_CLK_B, GPIO_FN_VI1_G7, GPIO_FN_VI3_DATA7,
-	GPIO_FN_GPS_MAG, GPIO_FN_FCE,
-};
-
 struct platform_device;
 
 struct r8a7779_pm_ch {
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 22:04:52 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed,  3 Apr 2013 11:04:52 +0900
Subject: [PATCH 14/28] sh-pfc: r8a7779: Remove GPIO data
In-Reply-To: <1364954706-14727-1-git-send-email-horms+renesas@verge.net.au>
References: <1364954706-14727-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364954706-14727-15-git-send-email-horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

GPIOs are now handled by a separate driver, remove GPIO data from the
SoC information structure.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Acked-by: Linus Walleij <linus.walleij at linaro.org>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 drivers/pinctrl/sh-pfc/pfc-r8a7779.c |   58 +---------------------------------
 1 file changed, 1 insertion(+), 57 deletions(-)

diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a7779.c b/drivers/pinctrl/sh-pfc/pfc-r8a7779.c
index 41d8bda..e448ff1 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a7779.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a7779.c
@@ -85,18 +85,12 @@
 	}
 
 #define _GP_DATA(bank, pin, name, sfx)					\
-	PINMUX_DATA(name##_DATA, name##_FN, name##_IN, name##_OUT)
-
-#define _GP_INOUTSEL(bank, pin, name, sfx)	name##_IN, name##_OUT
-#define _GP_INDT(bank, pin, name, sfx)		name##_DATA
+	PINMUX_DATA(name##_DATA, name##_FN)
 
 #define GP_ALL(str)		CPU_ALL_PORT(_GP_PORT_ALL, str)
 #define PINMUX_GPIO_GP_ALL()	CPU_ALL_PORT(_GP_GPIO, unused)
 #define PINMUX_DATA_GP_ALL()	CPU_ALL_PORT(_GP_DATA, unused)
 
-#define GP_INOUTSEL(bank) PORT_GP_32_REV(bank, _GP_INOUTSEL, unused)
-#define GP_INDT(bank) PORT_GP_32_REV(bank, _GP_INDT, unused)
-
 #define PINMUX_IPSR_DATA(ipsr, fn) PINMUX_DATA(fn##_MARK, FN_##ipsr, FN_##fn)
 #define PINMUX_IPSR_MODSEL_DATA(ipsr, fn, ms) PINMUX_DATA(fn##_MARK, FN_##ms, \
 							  FN_##ipsr, FN_##fn)
@@ -108,14 +102,6 @@ enum {
 	GP_ALL(DATA), /* GP_0_0_DATA -> GP_6_8_DATA */
 	PINMUX_DATA_END,
 
-	PINMUX_INPUT_BEGIN,
-	GP_ALL(IN), /* GP_0_0_IN -> GP_6_8_IN */
-	PINMUX_INPUT_END,
-
-	PINMUX_OUTPUT_BEGIN,
-	GP_ALL(OUT), /* GP_0_0_OUT -> GP_6_8_OUT */
-	PINMUX_OUTPUT_END,
-
 	PINMUX_FUNCTION_BEGIN,
 	GP_ALL(FN), /* GP_0_0_FN -> GP_6_8_FN */
 
@@ -3549,45 +3535,6 @@ static const struct pinmux_cfg_reg pinmux_config_regs[] = {
 	    /* SEL_I2C1 [2] */
 	    FN_SEL_I2C1_0, FN_SEL_I2C1_1, FN_SEL_I2C1_2, FN_SEL_I2C1_3 }
 	},
-	{ PINMUX_CFG_REG("INOUTSEL0", 0xffc40004, 32, 1) { GP_INOUTSEL(0) } },
-	{ PINMUX_CFG_REG("INOUTSEL1", 0xffc41004, 32, 1) { GP_INOUTSEL(1) } },
-	{ PINMUX_CFG_REG("INOUTSEL2", 0xffc42004, 32, 1) { GP_INOUTSEL(2) } },
-	{ PINMUX_CFG_REG("INOUTSEL3", 0xffc43004, 32, 1) { GP_INOUTSEL(3) } },
-	{ PINMUX_CFG_REG("INOUTSEL4", 0xffc44004, 32, 1) { GP_INOUTSEL(4) } },
-	{ PINMUX_CFG_REG("INOUTSEL5", 0xffc45004, 32, 1) { GP_INOUTSEL(5) } },
-	{ PINMUX_CFG_REG("INOUTSEL6", 0xffc46004, 32, 1) {
-		0, 0, 0, 0, 0, 0, 0, 0,	0, 0, 0, 0, 0, 0, 0, 0,
-		0, 0, 0, 0, 0, 0, 0, 0,	0, 0, 0, 0, 0, 0, 0, 0,
-		0, 0, 0, 0, 0, 0, 0, 0,
-		0, 0,
-		0, 0,
-		0, 0,
-		GP_6_8_IN, GP_6_8_OUT,
-		GP_6_7_IN, GP_6_7_OUT,
-		GP_6_6_IN, GP_6_6_OUT,
-		GP_6_5_IN, GP_6_5_OUT,
-		GP_6_4_IN, GP_6_4_OUT,
-		GP_6_3_IN, GP_6_3_OUT,
-		GP_6_2_IN, GP_6_2_OUT,
-		GP_6_1_IN, GP_6_1_OUT,
-		GP_6_0_IN, GP_6_0_OUT, }
-	},
-	{ },
-};
-
-static const struct pinmux_data_reg pinmux_data_regs[] = {
-	{ PINMUX_DATA_REG("INDT0", 0xffc40008, 32) { GP_INDT(0) } },
-	{ PINMUX_DATA_REG("INDT1", 0xffc41008, 32) { GP_INDT(1) } },
-	{ PINMUX_DATA_REG("INDT2", 0xffc42008, 32) { GP_INDT(2) } },
-	{ PINMUX_DATA_REG("INDT3", 0xffc43008, 32) { GP_INDT(3) } },
-	{ PINMUX_DATA_REG("INDT4", 0xffc44008, 32) { GP_INDT(4) } },
-	{ PINMUX_DATA_REG("INDT5", 0xffc45008, 32) { GP_INDT(5) } },
-	{ PINMUX_DATA_REG("INDT6", 0xffc46008, 32) {
-		0, 0, 0, 0, 0, 0, 0, 0,	0, 0, 0, 0, 0, 0, 0, 0,
-		0, 0, 0, 0, 0, 0, 0, GP_6_8_DATA,
-		GP_6_7_DATA, GP_6_6_DATA, GP_6_5_DATA, GP_6_4_DATA,
-		GP_6_3_DATA, GP_6_2_DATA, GP_6_1_DATA, GP_6_0_DATA }
-	},
 	{ },
 };
 
@@ -3596,8 +3543,6 @@ const struct sh_pfc_soc_info r8a7779_pinmux_info = {
 
 	.unlock_reg = 0xfffc0000, /* PMMR */
 
-	.input = { PINMUX_INPUT_BEGIN, PINMUX_INPUT_END },
-	.output = { PINMUX_OUTPUT_BEGIN, PINMUX_OUTPUT_END },
 	.function = { PINMUX_FUNCTION_BEGIN, PINMUX_FUNCTION_END },
 
 	.pins = pinmux_pins,
@@ -3608,7 +3553,6 @@ const struct sh_pfc_soc_info r8a7779_pinmux_info = {
 	.nr_functions = ARRAY_SIZE(pinmux_functions),
 
 	.cfg_regs = pinmux_config_regs,
-	.data_regs = pinmux_data_regs,
 
 	.gpio_data = pinmux_data,
 	.gpio_data_size = ARRAY_SIZE(pinmux_data),
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 22:04:55 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed,  3 Apr 2013 11:04:55 +0900
Subject: [PATCH 17/28] sh-pfc: r8a73a4: Support sparse GPIO numbers
In-Reply-To: <1364954706-14727-1-git-send-email-horms+renesas@verge.net.au>
References: <1364954706-14727-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364954706-14727-18-git-send-email-horms+renesas@verge.net.au>

From: Magnus Damm <damm at opensource.se>

The r8a73a4 SoC has sparse GPIO numbers. Declare ranges for pin numbers
in the PFC SoC data. Pin numbers shall be used with the GPIO API from
this point on.

Signed-off-by: Magnus Damm <damm at opensource.se>
Acked-by: Linus Walleij <linus.walleij at linaro.org>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/include/mach/r8a73a4.h |    2 +-
 drivers/pinctrl/sh-pfc/pfc-r8a73a4.c          |   16 ++++++++++++++++
 2 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-shmobile/include/mach/r8a73a4.h b/arch/arm/mach-shmobile/include/mach/r8a73a4.h
index f0b1b4a..2d4af4a 100644
--- a/arch/arm/mach-shmobile/include/mach/r8a73a4.h
+++ b/arch/arm/mach-shmobile/include/mach/r8a73a4.h
@@ -86,7 +86,7 @@ enum {
 	GPIO_PORT325, GPIO_PORT326, GPIO_PORT327, GPIO_PORT328, GPIO_PORT329,
 
 	/* Port0 */
-	GPIO_FN_LCDD0,
+	GPIO_FN_LCDD0 = 330,
 	GPIO_FN_PDM2_CLK_0,
 	GPIO_FN_DU0_DR0,
 	GPIO_FN_IRQ0,
diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a73a4.c b/drivers/pinctrl/sh-pfc/pfc-r8a73a4.c
index 47d75d5..5dd68fb9 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a73a4.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a73a4.c
@@ -1424,6 +1424,20 @@ static struct sh_pfc_pin pinmux_pins[] = {
 	GPIO_PORT_ALL(),
 };
 
+static const struct pinmux_range pinmux_ranges[] = {
+	{.begin = 0, .end = 30,},
+	{.begin = 32, .end = 40,},
+	{.begin = 64, .end = 85,},
+	{.begin = 96, .end = 126,},
+	{.begin = 128, .end = 134,},
+	{.begin = 160, .end = 178,},
+	{.begin = 192, .end = 222,},
+	{.begin = 224, .end = 250,},
+	{.begin = 256, .end = 283,},
+	{.begin = 288, .end = 308,},
+	{.begin = 320, .end = 329,},
+};
+
 #define PINMUX_FN_BASE	ARRAY_SIZE(pinmux_pins)
 
 static const struct pinmux_func pinmux_func_gpios[] = {
@@ -2815,6 +2829,8 @@ const struct sh_pfc_soc_info r8a73a4_pinmux_info = {
 
 	.pins = pinmux_pins,
 	.nr_pins = ARRAY_SIZE(pinmux_pins),
+	.ranges = pinmux_ranges,
+	.nr_ranges = ARRAY_SIZE(pinmux_ranges),
 	.func_gpios = pinmux_func_gpios,
 	.nr_func_gpios = ARRAY_SIZE(pinmux_func_gpios),
 
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 22:04:44 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed,  3 Apr 2013 11:04:44 +0900
Subject: [PATCH 06/28] gpio: Renesas R-Car GPIO driver V3
In-Reply-To: <1364954706-14727-1-git-send-email-horms+renesas@verge.net.au>
References: <1364954706-14727-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364954706-14727-7-git-send-email-horms+renesas@verge.net.au>

From: Magnus Damm <damm at opensource.se>

This patch is V3 of a GPIO driver for the R-Car series of
SoCs from Renesas. This driver is designed to be reusable
between multiple SoCs that share the same basic building block,
but so far it has only been used on R-Car H1 (r8a7779).

Each driver instance handles 32 GPIOs with individually
maskable IRQs. The driver operates on a single I/O memory
range and the 32 GPIOs are hooked up a single interrupt.

In the case of R-Car H1 either external IRQ pins or GPIOs
with interrupts can be used for on-board interupts. For
external IRQs 4 pins are supported, and in the case of GPIO
there are 202 GPIOS as 202 interrupts hooked up via 6 driver
instances and to the GIC and the Cortex-A9 Quad.

At this point this driver is interfacing as a regular
platform device driver. In the future DT support will be
submitted as an incremental feature patch.

Signed-off-by: Magnus Damm <damm at opensource.se>
Reviewed-by: Linus Walleij <linus.walleij at linaro.org>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 drivers/gpio/Kconfig                    |    6 +
 drivers/gpio/Makefile                   |    1 +
 drivers/gpio/gpio-rcar.c                |  373 +++++++++++++++++++++++++++++++
 include/linux/platform_data/gpio-rcar.h |   25 +++
 4 files changed, 405 insertions(+)
 create mode 100644 drivers/gpio/gpio-rcar.c
 create mode 100644 include/linux/platform_data/gpio-rcar.h

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 93aaadf..d766e3c 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -204,6 +204,12 @@ config GPIO_PXA
 	help
 	  Say yes here to support the PXA GPIO device
 
+config GPIO_RCAR
+	tristate "Renesas R-Car GPIO"
+	depends on ARM
+	help
+	  Say yes here to support GPIO on Renesas R-Car SoCs.
+
 config GPIO_SPEAR_SPICS
 	bool "ST SPEAr13xx SPI Chip Select as GPIO support"
 	depends on PLAT_SPEAR
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 22e07bc..b41c74d 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -57,6 +57,7 @@ obj-$(CONFIG_GPIO_PL061)	+= gpio-pl061.o
 obj-$(CONFIG_GPIO_PXA)		+= gpio-pxa.o
 obj-$(CONFIG_GPIO_RC5T583)	+= gpio-rc5t583.o
 obj-$(CONFIG_GPIO_RDC321X)	+= gpio-rdc321x.o
+obj-$(CONFIG_GPIO_RCAR)		+= gpio-rcar.o
 obj-$(CONFIG_PLAT_SAMSUNG)	+= gpio-samsung.o
 obj-$(CONFIG_ARCH_SA1100)	+= gpio-sa1100.o
 obj-$(CONFIG_GPIO_SCH)		+= gpio-sch.o
diff --git a/drivers/gpio/gpio-rcar.c b/drivers/gpio/gpio-rcar.c
new file mode 100644
index 0000000..581ba56
--- /dev/null
+++ b/drivers/gpio/gpio-rcar.c
@@ -0,0 +1,373 @@
+/*
+ * Renesas R-Car GPIO Support
+ *
+ *  Copyright (C) 2013 Magnus Damm
+ *
+ * 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
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/err.h>
+#include <linux/gpio.h>
+#include <linux/init.h>
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/ioport.h>
+#include <linux/irq.h>
+#include <linux/irqdomain.h>
+#include <linux/module.h>
+#include <linux/platform_data/gpio-rcar.h>
+#include <linux/platform_device.h>
+#include <linux/spinlock.h>
+#include <linux/slab.h>
+
+struct gpio_rcar_priv {
+	void __iomem *base;
+	spinlock_t lock;
+	struct gpio_rcar_config config;
+	struct platform_device *pdev;
+	struct gpio_chip gpio_chip;
+	struct irq_chip irq_chip;
+	struct irq_domain *irq_domain;
+};
+
+#define IOINTSEL 0x00
+#define INOUTSEL 0x04
+#define OUTDT 0x08
+#define INDT 0x0c
+#define INTDT 0x10
+#define INTCLR 0x14
+#define INTMSK 0x18
+#define MSKCLR 0x1c
+#define POSNEG 0x20
+#define EDGLEVEL 0x24
+#define FILONOFF 0x28
+
+static inline u32 gpio_rcar_read(struct gpio_rcar_priv *p, int offs)
+{
+	return ioread32(p->base + offs);
+}
+
+static inline void gpio_rcar_write(struct gpio_rcar_priv *p, int offs,
+				   u32 value)
+{
+	iowrite32(value, p->base + offs);
+}
+
+static void gpio_rcar_modify_bit(struct gpio_rcar_priv *p, int offs,
+				 int bit, bool value)
+{
+	u32 tmp = gpio_rcar_read(p, offs);
+
+	if (value)
+		tmp |= BIT(bit);
+	else
+		tmp &= ~BIT(bit);
+
+	gpio_rcar_write(p, offs, tmp);
+}
+
+static void gpio_rcar_irq_disable(struct irq_data *d)
+{
+	struct gpio_rcar_priv *p = irq_data_get_irq_chip_data(d);
+
+	gpio_rcar_write(p, INTMSK, ~BIT(irqd_to_hwirq(d)));
+}
+
+static void gpio_rcar_irq_enable(struct irq_data *d)
+{
+	struct gpio_rcar_priv *p = irq_data_get_irq_chip_data(d);
+
+	gpio_rcar_write(p, MSKCLR, BIT(irqd_to_hwirq(d)));
+}
+
+static void gpio_rcar_config_interrupt_input_mode(struct gpio_rcar_priv *p,
+						  unsigned int hwirq,
+						  bool active_high_rising_edge,
+						  bool level_trigger)
+{
+	unsigned long flags;
+
+	/* follow steps in the GPIO documentation for
+	 * "Setting Edge-Sensitive Interrupt Input Mode" and
+	 * "Setting Level-Sensitive Interrupt Input Mode"
+	 */
+
+	spin_lock_irqsave(&p->lock, flags);
+
+	/* Configure postive or negative logic in POSNEG */
+	gpio_rcar_modify_bit(p, POSNEG, hwirq, !active_high_rising_edge);
+
+	/* Configure edge or level trigger in EDGLEVEL */
+	gpio_rcar_modify_bit(p, EDGLEVEL, hwirq, !level_trigger);
+
+	/* Select "Interrupt Input Mode" in IOINTSEL */
+	gpio_rcar_modify_bit(p, IOINTSEL, hwirq, true);
+
+	/* Write INTCLR in case of edge trigger */
+	if (!level_trigger)
+		gpio_rcar_write(p, INTCLR, BIT(hwirq));
+
+	spin_unlock_irqrestore(&p->lock, flags);
+}
+
+static int gpio_rcar_irq_set_type(struct irq_data *d, unsigned int type)
+{
+	struct gpio_rcar_priv *p = irq_data_get_irq_chip_data(d);
+	unsigned int hwirq = irqd_to_hwirq(d);
+
+	dev_dbg(&p->pdev->dev, "sense irq = %d, type = %d\n", hwirq, type);
+
+	switch (type & IRQ_TYPE_SENSE_MASK) {
+	case IRQ_TYPE_LEVEL_HIGH:
+		gpio_rcar_config_interrupt_input_mode(p, hwirq, true, true);
+		break;
+	case IRQ_TYPE_LEVEL_LOW:
+		gpio_rcar_config_interrupt_input_mode(p, hwirq, false, true);
+		break;
+	case IRQ_TYPE_EDGE_RISING:
+		gpio_rcar_config_interrupt_input_mode(p, hwirq, true, false);
+		break;
+	case IRQ_TYPE_EDGE_FALLING:
+		gpio_rcar_config_interrupt_input_mode(p, hwirq, false, false);
+		break;
+	default:
+		return -EINVAL;
+	}
+	return 0;
+}
+
+static irqreturn_t gpio_rcar_irq_handler(int irq, void *dev_id)
+{
+	struct gpio_rcar_priv *p = dev_id;
+	u32 pending;
+	unsigned int offset, irqs_handled = 0;
+
+	while ((pending = gpio_rcar_read(p, INTDT))) {
+		offset = __ffs(pending);
+		gpio_rcar_write(p, INTCLR, BIT(offset));
+		generic_handle_irq(irq_find_mapping(p->irq_domain, offset));
+		irqs_handled++;
+	}
+
+	return irqs_handled ? IRQ_HANDLED : IRQ_NONE;
+}
+
+static inline struct gpio_rcar_priv *gpio_to_priv(struct gpio_chip *chip)
+{
+	return container_of(chip, struct gpio_rcar_priv, gpio_chip);
+}
+
+static void gpio_rcar_config_general_input_output_mode(struct gpio_chip *chip,
+						       unsigned int gpio,
+						       bool output)
+{
+	struct gpio_rcar_priv *p = gpio_to_priv(chip);
+	unsigned long flags;
+
+	/* follow steps in the GPIO documentation for
+	 * "Setting General Output Mode" and
+	 * "Setting General Input Mode"
+	 */
+
+	spin_lock_irqsave(&p->lock, flags);
+
+	/* Configure postive logic in POSNEG */
+	gpio_rcar_modify_bit(p, POSNEG, gpio, false);
+
+	/* Select "General Input/Output Mode" in IOINTSEL */
+	gpio_rcar_modify_bit(p, IOINTSEL, gpio, false);
+
+	/* Select Input Mode or Output Mode in INOUTSEL */
+	gpio_rcar_modify_bit(p, INOUTSEL, gpio, output);
+
+	spin_unlock_irqrestore(&p->lock, flags);
+}
+
+static int gpio_rcar_direction_input(struct gpio_chip *chip, unsigned offset)
+{
+	gpio_rcar_config_general_input_output_mode(chip, offset, false);
+	return 0;
+}
+
+static int gpio_rcar_get(struct gpio_chip *chip, unsigned offset)
+{
+	return (int)(gpio_rcar_read(gpio_to_priv(chip), INDT) & BIT(offset));
+}
+
+static void gpio_rcar_set(struct gpio_chip *chip, unsigned offset, int value)
+{
+	struct gpio_rcar_priv *p = gpio_to_priv(chip);
+	unsigned long flags;
+
+	spin_lock_irqsave(&p->lock, flags);
+	gpio_rcar_modify_bit(p, OUTDT, offset, value);
+	spin_unlock_irqrestore(&p->lock, flags);
+}
+
+static int gpio_rcar_direction_output(struct gpio_chip *chip, unsigned offset,
+				      int value)
+{
+	/* write GPIO value to output before selecting output mode of pin */
+	gpio_rcar_set(chip, offset, value);
+	gpio_rcar_config_general_input_output_mode(chip, offset, true);
+	return 0;
+}
+
+static int gpio_rcar_to_irq(struct gpio_chip *chip, unsigned offset)
+{
+	return irq_create_mapping(gpio_to_priv(chip)->irq_domain, offset);
+}
+
+static int gpio_rcar_irq_domain_map(struct irq_domain *h, unsigned int virq,
+				 irq_hw_number_t hw)
+{
+	struct gpio_rcar_priv *p = h->host_data;
+
+	dev_dbg(&p->pdev->dev, "map hw irq = %d, virq = %d\n", (int)hw, virq);
+
+	irq_set_chip_data(virq, h->host_data);
+	irq_set_chip_and_handler(virq, &p->irq_chip, handle_level_irq);
+	set_irq_flags(virq, IRQF_VALID); /* kill me now */
+	return 0;
+}
+
+static struct irq_domain_ops gpio_rcar_irq_domain_ops = {
+	.map	= gpio_rcar_irq_domain_map,
+};
+
+static int gpio_rcar_probe(struct platform_device *pdev)
+{
+	struct gpio_rcar_config *pdata = pdev->dev.platform_data;
+	struct gpio_rcar_priv *p;
+	struct resource *io, *irq;
+	struct gpio_chip *gpio_chip;
+	struct irq_chip *irq_chip;
+	const char *name = dev_name(&pdev->dev);
+	int ret;
+
+	p = devm_kzalloc(&pdev->dev, sizeof(*p), GFP_KERNEL);
+	if (!p) {
+		dev_err(&pdev->dev, "failed to allocate driver data\n");
+		ret = -ENOMEM;
+		goto err0;
+	}
+
+	/* deal with driver instance configuration */
+	if (pdata)
+		p->config = *pdata;
+
+	p->pdev = pdev;
+	platform_set_drvdata(pdev, p);
+	spin_lock_init(&p->lock);
+
+	io = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
+
+	if (!io || !irq) {
+		dev_err(&pdev->dev, "missing IRQ or IOMEM\n");
+		ret = -EINVAL;
+		goto err0;
+	}
+
+	p->base = devm_ioremap_nocache(&pdev->dev, io->start,
+				       resource_size(io));
+	if (!p->base) {
+		dev_err(&pdev->dev, "failed to remap I/O memory\n");
+		ret = -ENXIO;
+		goto err0;
+	}
+
+	gpio_chip = &p->gpio_chip;
+	gpio_chip->direction_input = gpio_rcar_direction_input;
+	gpio_chip->get = gpio_rcar_get;
+	gpio_chip->direction_output = gpio_rcar_direction_output;
+	gpio_chip->set = gpio_rcar_set;
+	gpio_chip->to_irq = gpio_rcar_to_irq;
+	gpio_chip->label = name;
+	gpio_chip->owner = THIS_MODULE;
+	gpio_chip->base = p->config.gpio_base;
+	gpio_chip->ngpio = p->config.number_of_pins;
+
+	irq_chip = &p->irq_chip;
+	irq_chip->name = name;
+	irq_chip->irq_mask = gpio_rcar_irq_disable;
+	irq_chip->irq_unmask = gpio_rcar_irq_enable;
+	irq_chip->irq_enable = gpio_rcar_irq_enable;
+	irq_chip->irq_disable = gpio_rcar_irq_disable;
+	irq_chip->irq_set_type = gpio_rcar_irq_set_type;
+	irq_chip->flags	= IRQCHIP_SKIP_SET_WAKE | IRQCHIP_SET_TYPE_MASKED;
+
+	p->irq_domain = irq_domain_add_simple(pdev->dev.of_node,
+					      p->config.number_of_pins,
+					      p->config.irq_base,
+					      &gpio_rcar_irq_domain_ops, p);
+	if (!p->irq_domain) {
+		ret = -ENXIO;
+		dev_err(&pdev->dev, "cannot initialize irq domain\n");
+		goto err1;
+	}
+
+	if (devm_request_irq(&pdev->dev, irq->start,
+			     gpio_rcar_irq_handler, 0, name, p)) {
+		dev_err(&pdev->dev, "failed to request IRQ\n");
+		ret = -ENOENT;
+		goto err1;
+	}
+
+	ret = gpiochip_add(gpio_chip);
+	if (ret) {
+		dev_err(&pdev->dev, "failed to add GPIO controller\n");
+		goto err1;
+	}
+
+	dev_info(&pdev->dev, "driving %d GPIOs\n", p->config.number_of_pins);
+
+	/* warn in case of mismatch if irq base is specified */
+	if (p->config.irq_base) {
+		ret = irq_find_mapping(p->irq_domain, 0);
+		if (p->config.irq_base != ret)
+			dev_warn(&pdev->dev, "irq base mismatch (%u/%u)\n",
+				 p->config.irq_base, ret);
+	}
+
+	return 0;
+
+err1:
+	irq_domain_remove(p->irq_domain);
+err0:
+	return ret;
+}
+
+static int gpio_rcar_remove(struct platform_device *pdev)
+{
+	struct gpio_rcar_priv *p = platform_get_drvdata(pdev);
+	int ret;
+
+	ret = gpiochip_remove(&p->gpio_chip);
+	if (ret)
+		return ret;
+
+	irq_domain_remove(p->irq_domain);
+	return 0;
+}
+
+static struct platform_driver gpio_rcar_device_driver = {
+	.probe		= gpio_rcar_probe,
+	.remove		= gpio_rcar_remove,
+	.driver		= {
+		.name	= "gpio_rcar",
+	}
+};
+
+module_platform_driver(gpio_rcar_device_driver);
+
+MODULE_AUTHOR("Magnus Damm");
+MODULE_DESCRIPTION("Renesas R-Car GPIO Driver");
+MODULE_LICENSE("GPL v2");
diff --git a/include/linux/platform_data/gpio-rcar.h b/include/linux/platform_data/gpio-rcar.h
new file mode 100644
index 0000000..bebfcd8
--- /dev/null
+++ b/include/linux/platform_data/gpio-rcar.h
@@ -0,0 +1,25 @@
+/*
+ * Renesas R-Car GPIO Support
+ *
+ *  Copyright (C) 2013 Magnus Damm
+ *
+ * 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
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef __GPIO_RCAR_H__
+#define __GPIO_RCAR_H__
+
+struct gpio_rcar_config {
+	unsigned int gpio_base;
+	unsigned int irq_base;
+	unsigned int number_of_pins;
+};
+
+#endif /* __GPIO_RCAR_H__ */
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 22:04:56 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed,  3 Apr 2013 11:04:56 +0900
Subject: [PATCH 18/28] sh-pfc: r8a73a4: GPIO IRQ support
In-Reply-To: <1364954706-14727-1-git-send-email-horms+renesas@verge.net.au>
References: <1364954706-14727-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364954706-14727-19-git-send-email-horms+renesas@verge.net.au>

From: Magnus Damm <damm at opensource.se>

V2 of code to add GPIO -> IRQ mappings to the
PFC table for the r8a73a4 SoC. Requires the IRQs
to be mapped at a fixed location in Linux IRQ
space. The actual IRQs are not handled by the
PFC, instead IRQC is used on r8a73a4.

Signed-off-by: Magnus Damm <damm at opensource.se>
Acked-by: Linus Walleij <linus.walleij at linaro.org>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 drivers/pinctrl/sh-pfc/pfc-r8a73a4.c |   63 ++++++++++++++++++++++++++++++++++
 1 file changed, 63 insertions(+)

diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a73a4.c b/drivers/pinctrl/sh-pfc/pfc-r8a73a4.c
index 5dd68fb9..0177329 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a73a4.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a73a4.c
@@ -2818,6 +2818,66 @@ static const struct pinmux_data_reg pinmux_data_regs[] = {
 	{ },
 };
 
+static const struct pinmux_irq pinmux_irqs[] = {
+	PINMUX_IRQ(irq_pin(0), 0),
+	PINMUX_IRQ(irq_pin(1), 1),
+	PINMUX_IRQ(irq_pin(2), 2),
+	PINMUX_IRQ(irq_pin(3), 3),
+	PINMUX_IRQ(irq_pin(4), 4),
+	PINMUX_IRQ(irq_pin(5), 5),
+	PINMUX_IRQ(irq_pin(6), 6),
+	PINMUX_IRQ(irq_pin(7), 7),
+	PINMUX_IRQ(irq_pin(8), 8),
+	PINMUX_IRQ(irq_pin(9), 9),
+	PINMUX_IRQ(irq_pin(10), 10),
+	PINMUX_IRQ(irq_pin(11), 11),
+	PINMUX_IRQ(irq_pin(12), 12),
+	PINMUX_IRQ(irq_pin(13), 13),
+	PINMUX_IRQ(irq_pin(14), 14),
+	PINMUX_IRQ(irq_pin(15), 15),
+	PINMUX_IRQ(irq_pin(16), 320),
+	PINMUX_IRQ(irq_pin(17), 321),
+	PINMUX_IRQ(irq_pin(18), 85),
+	PINMUX_IRQ(irq_pin(19), 84),
+	PINMUX_IRQ(irq_pin(20), 160),
+	PINMUX_IRQ(irq_pin(21), 161),
+	PINMUX_IRQ(irq_pin(22), 162),
+	PINMUX_IRQ(irq_pin(23), 163),
+	PINMUX_IRQ(irq_pin(24), 175),
+	PINMUX_IRQ(irq_pin(25), 176),
+	PINMUX_IRQ(irq_pin(26), 177),
+	PINMUX_IRQ(irq_pin(27), 178),
+	PINMUX_IRQ(irq_pin(28), 322),
+	PINMUX_IRQ(irq_pin(29), 323),
+	PINMUX_IRQ(irq_pin(30), 324),
+	PINMUX_IRQ(irq_pin(31), 192),
+	PINMUX_IRQ(irq_pin(32), 193),
+	PINMUX_IRQ(irq_pin(33), 194),
+	PINMUX_IRQ(irq_pin(34), 195),
+	PINMUX_IRQ(irq_pin(35), 196),
+	PINMUX_IRQ(irq_pin(36), 197),
+	PINMUX_IRQ(irq_pin(37), 198),
+	PINMUX_IRQ(irq_pin(38), 199),
+	PINMUX_IRQ(irq_pin(39), 200),
+	PINMUX_IRQ(irq_pin(40), 66),
+	PINMUX_IRQ(irq_pin(41), 102),
+	PINMUX_IRQ(irq_pin(42), 103),
+	PINMUX_IRQ(irq_pin(43), 109),
+	PINMUX_IRQ(irq_pin(44), 110),
+	PINMUX_IRQ(irq_pin(45), 111),
+	PINMUX_IRQ(irq_pin(46), 112),
+	PINMUX_IRQ(irq_pin(47), 113),
+	PINMUX_IRQ(irq_pin(48), 114),
+	PINMUX_IRQ(irq_pin(49), 115),
+	PINMUX_IRQ(irq_pin(50), 301),
+	PINMUX_IRQ(irq_pin(51), 290),
+	PINMUX_IRQ(irq_pin(52), 296),
+	PINMUX_IRQ(irq_pin(53), 325),
+	PINMUX_IRQ(irq_pin(54), 326),
+	PINMUX_IRQ(irq_pin(55), 327),
+	PINMUX_IRQ(irq_pin(56), 328),
+	PINMUX_IRQ(irq_pin(57), 329),
+};
 const struct sh_pfc_soc_info r8a73a4_pinmux_info = {
 	.name		= "r8a73a4_pfc",
 
@@ -2839,4 +2899,7 @@ const struct sh_pfc_soc_info r8a73a4_pinmux_info = {
 
 	.gpio_data	= pinmux_data,
 	.gpio_data_size	= ARRAY_SIZE(pinmux_data),
+
+	.gpio_irq = pinmux_irqs,
+	.gpio_irq_size = ARRAY_SIZE(pinmux_irqs),
 };
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 22:04:53 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed,  3 Apr 2013 11:04:53 +0900
Subject: [PATCH 15/28] sh-pfc: r8a7779: Split DU input and output pixel clocks
In-Reply-To: <1364954706-14727-1-git-send-email-horms+renesas@verge.net.au>
References: <1364954706-14727-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364954706-14727-16-git-send-email-horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

The output pixel clocks can be used without the input pixel clocks.
Split them in different groups.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 drivers/pinctrl/sh-pfc/pfc-r8a7779.c |   60 ++++++++++++++++++++++------------
 1 file changed, 39 insertions(+), 21 deletions(-)

diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a7779.c b/drivers/pinctrl/sh-pfc/pfc-r8a7779.c
index e448ff1..62dcdcd 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a7779.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a7779.c
@@ -1498,19 +1498,26 @@ static const unsigned int du0_rgb888_mux[] = {
 	DU0_DB7_MARK, DU0_DB6_MARK, DU0_DB5_MARK, DU0_DB4_MARK,
 	DU0_DB3_MARK, DU0_DB2_MARK, DU0_DB1_MARK, DU0_DB0_MARK,
 };
-static const unsigned int du0_clk_0_pins[] = {
-	/* CLKIN, CLKOUT */
-	29, 180,
+static const unsigned int du0_clk_in_pins[] = {
+	/* CLKIN */
+	29,
 };
-static const unsigned int du0_clk_0_mux[] = {
-	DU0_DOTCLKIN_MARK, DU0_DOTCLKOUT0_MARK,
+static const unsigned int du0_clk_in_mux[] = {
+	DU0_DOTCLKIN_MARK,
 };
-static const unsigned int du0_clk_1_pins[] = {
-	/* CLKIN, CLKOUT */
-	29, 30,
+static const unsigned int du0_clk_out_0_pins[] = {
+	/* CLKOUT */
+	180,
 };
-static const unsigned int du0_clk_1_mux[] = {
-	DU0_DOTCLKIN_MARK, DU0_DOTCLKOUT1_MARK,
+static const unsigned int du0_clk_out_0_mux[] = {
+	DU0_DOTCLKOUT0_MARK,
+};
+static const unsigned int du0_clk_out_1_pins[] = {
+	/* CLKOUT */
+	30,
+};
+static const unsigned int du0_clk_out_1_mux[] = {
+	DU0_DOTCLKOUT1_MARK,
 };
 static const unsigned int du0_sync_0_pins[] = {
 	/* VSYNC, HSYNC, DISP */
@@ -1571,12 +1578,19 @@ static const unsigned int du1_rgb888_mux[] = {
 	DU1_DB7_MARK, DU1_DB6_MARK, DU1_DB5_MARK, DU1_DB4_MARK,
 	DU1_DB3_MARK, DU1_DB2_MARK, DU1_DB1_MARK, DU1_DB0_MARK,
 };
-static const unsigned int du1_clk_pins[] = {
-	/* CLKIN, CLKOUT */
-	58, 59,
+static const unsigned int du1_clk_in_pins[] = {
+	/* CLKIN */
+	58,
+};
+static const unsigned int du1_clk_in_mux[] = {
+	DU1_DOTCLKIN_MARK,
+};
+static const unsigned int du1_clk_out_pins[] = {
+	/* CLKOUT */
+	59,
 };
-static const unsigned int du1_clk_mux[] = {
-	DU1_DOTCLKIN_MARK, DU1_DOTCLKOUT_MARK,
+static const unsigned int du1_clk_out_mux[] = {
+	DU1_DOTCLKOUT_MARK,
 };
 static const unsigned int du1_sync_0_pins[] = {
 	/* VSYNC, HSYNC, DISP */
@@ -2369,15 +2383,17 @@ static const unsigned int usb2_mux[] = {
 static const struct sh_pfc_pin_group pinmux_groups[] = {
 	SH_PFC_PIN_GROUP(du0_rgb666),
 	SH_PFC_PIN_GROUP(du0_rgb888),
-	SH_PFC_PIN_GROUP(du0_clk_0),
-	SH_PFC_PIN_GROUP(du0_clk_1),
+	SH_PFC_PIN_GROUP(du0_clk_in),
+	SH_PFC_PIN_GROUP(du0_clk_out_0),
+	SH_PFC_PIN_GROUP(du0_clk_out_1),
 	SH_PFC_PIN_GROUP(du0_sync_0),
 	SH_PFC_PIN_GROUP(du0_sync_1),
 	SH_PFC_PIN_GROUP(du0_oddf),
 	SH_PFC_PIN_GROUP(du0_cde),
 	SH_PFC_PIN_GROUP(du1_rgb666),
 	SH_PFC_PIN_GROUP(du1_rgb888),
-	SH_PFC_PIN_GROUP(du1_clk),
+	SH_PFC_PIN_GROUP(du1_clk_in),
+	SH_PFC_PIN_GROUP(du1_clk_out),
 	SH_PFC_PIN_GROUP(du1_sync_0),
 	SH_PFC_PIN_GROUP(du1_sync_1),
 	SH_PFC_PIN_GROUP(du1_oddf),
@@ -2492,8 +2508,9 @@ static const struct sh_pfc_pin_group pinmux_groups[] = {
 static const char * const du0_groups[] = {
 	"du0_rgb666",
 	"du0_rgb888",
-	"du0_clk_0",
-	"du0_clk_1",
+	"du0_clk_in",
+	"du0_clk_out_0",
+	"du0_clk_out_1",
 	"du0_sync_0",
 	"du0_sync_1",
 	"du0_oddf",
@@ -2503,7 +2520,8 @@ static const char * const du0_groups[] = {
 static const char * const du1_groups[] = {
 	"du1_rgb666",
 	"du1_rgb888",
-	"du1_clk",
+	"du1_clk_in",
+	"du1_clk_out",
 	"du1_sync_0",
 	"du1_sync_1",
 	"du1_oddf",
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 22:04:58 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed,  3 Apr 2013 11:04:58 +0900
Subject: [PATCH 20/28] sh-pfc: r8a73a4: Add SCIF pin groups and functions
In-Reply-To: <1364954706-14727-1-git-send-email-horms+renesas@verge.net.au>
References: <1364954706-14727-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364954706-14727-21-git-send-email-horms+renesas@verge.net.au>

From: Magnus Damm <damm at opensource.se>

Add PINCTRL support for r8a73a4 SCIF ports SCIFA0->SCIFA1 and
SCIFB0->SCIFB3.

Signed-off-by: Magnus Damm <damm at opensource.se>
Acked-by: Linus Walleij <linus.walleij at linaro.org>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 drivers/pinctrl/sh-pfc/pfc-r8a73a4.c |  287 ++++++++++++++++++++++++++++++++++
 1 file changed, 287 insertions(+)

diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a73a4.c b/drivers/pinctrl/sh-pfc/pfc-r8a73a4.c
index 86a5fd3..cd5c5fd 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a73a4.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a73a4.c
@@ -1576,6 +1576,286 @@ static const struct pinmux_range pinmux_ranges[] = {
 	{.begin = 320, .end = 329,},
 };
 
+/* - SCIFA0 ----------------------------------------------------------------- */
+static const unsigned int scifa0_data_pins[] = {
+	/* SCIFA0_RXD, SCIFA0_TXD */
+	117, 116,
+};
+static const unsigned int scifa0_data_mux[] = {
+	SCIFA0_RXD_MARK, SCIFA0_TXD_MARK,
+};
+static const unsigned int scifa0_clk_pins[] = {
+	/* SCIFA0_SCK */
+	34,
+};
+static const unsigned int scifa0_clk_mux[] = {
+	SCIFA0_SCK_MARK,
+};
+static const unsigned int scifa0_ctrl_pins[] = {
+	/* SCIFA0_RTS, SCIFA0_CTS */
+	32, 33,
+};
+static const unsigned int scifa0_ctrl_mux[] = {
+	SCIFA0_RTS_MARK, SCIFA0_CTS_MARK,
+};
+/* - SCIFA1 ----------------------------------------------------------------- */
+static const unsigned int scifa1_data_pins[] = {
+	/* SCIFA1_RXD, SCIFA1_TXD */
+	119, 118,
+};
+static const unsigned int scifa1_data_mux[] = {
+	SCIFA1_RXD_MARK, SCIFA1_TXD_MARK,
+};
+static const unsigned int scifa1_clk_pins[] = {
+	/* SCIFA1_SCK */
+	37,
+};
+static const unsigned int scifa1_clk_mux[] = {
+	SCIFA1_SCK_MARK,
+};
+static const unsigned int scifa1_ctrl_pins[] = {
+	/* SCIFA1_RTS, SCIFA1_CTS */
+	35, 36,
+};
+static const unsigned int scifa1_ctrl_mux[] = {
+	SCIFA1_RTS_MARK, SCIFA1_CTS_MARK,
+};
+/* - SCIFB0 ----------------------------------------------------------------- */
+static const unsigned int scifb0_data_pins[] = {
+	/* SCIFB0_RXD, SCIFB0_TXD */
+	123, 122,
+};
+static const unsigned int scifb0_data_mux[] = {
+	SCIFB0_RXD_MARK, SCIFB0_TXD_MARK,
+};
+static const unsigned int scifb0_clk_pins[] = {
+	/* SCIFB0_SCK */
+	40,
+};
+static const unsigned int scifb0_clk_mux[] = {
+	SCIFB0_SCK_MARK,
+};
+static const unsigned int scifb0_ctrl_pins[] = {
+	/* SCIFB0_RTS, SCIFB0_CTS */
+	38, 39,
+};
+static const unsigned int scifb0_ctrl_mux[] = {
+	SCIFB0_RTS_MARK, SCIFB0_CTS_MARK,
+};
+/* - SCIFB1 ----------------------------------------------------------------- */
+static const unsigned int scifb1_data_pins[] = {
+	/* SCIFB1_RXD, SCIFB1_TXD */
+	27, 26,
+};
+static const unsigned int scifb1_data_mux[] = {
+	SCIFB1_RXD_27_MARK, SCIFB1_TXD_26_MARK,
+};
+static const unsigned int scifb1_clk_pins[] = {
+	/* SCIFB1_SCK */
+	28,
+};
+static const unsigned int scifb1_clk_mux[] = {
+	SCIFB1_SCK_28_MARK,
+};
+static const unsigned int scifb1_ctrl_pins[] = {
+	/* SCIFB1_RTS, SCIFB1_CTS */
+	24, 25,
+};
+static const unsigned int scifb1_ctrl_mux[] = {
+	SCIFB1_RTS_24_MARK, SCIFB1_CTS_25_MARK,
+};
+static const unsigned int scifb1_data_b_pins[] = {
+	/* SCIFB1_RXD, SCIFB1_TXD */
+	72, 67,
+};
+static const unsigned int scifb1_data_b_mux[] = {
+	SCIFB1_RXD_72_MARK, SCIFB1_TXD_67_MARK,
+};
+static const unsigned int scifb1_clk_b_pins[] = {
+	/* SCIFB1_SCK */
+	261,
+};
+static const unsigned int scifb1_clk_b_mux[] = {
+	SCIFB1_SCK_261_MARK,
+};
+static const unsigned int scifb1_ctrl_b_pins[] = {
+	/* SCIFB1_RTS, SCIFB1_CTS */
+	70, 71,
+};
+static const unsigned int scifb1_ctrl_b_mux[] = {
+	SCIFB1_RTS_70_MARK, SCIFB1_CTS_71_MARK,
+};
+/* - SCIFB2 ----------------------------------------------------------------- */
+static const unsigned int scifb2_data_pins[] = {
+	/* SCIFB2_RXD, SCIFB2_TXD */
+	69, 68,
+};
+static const unsigned int scifb2_data_mux[] = {
+	SCIFB2_RXD_69_MARK, SCIFB2_TXD_68_MARK,
+};
+static const unsigned int scifb2_clk_pins[] = {
+	/* SCIFB2_SCK */
+	262,
+};
+static const unsigned int scifb2_clk_mux[] = {
+	SCIFB2_SCK_262_MARK,
+};
+static const unsigned int scifb2_ctrl_pins[] = {
+	/* SCIFB2_RTS, SCIFB2_CTS */
+	73, 66,
+};
+static const unsigned int scifb2_ctrl_mux[] = {
+	SCIFB2_RTS_73_MARK, SCIFB2_CTS_66_MARK,
+};
+static const unsigned int scifb2_data_b_pins[] = {
+	/* SCIFB2_RXD, SCIFB2_TXD */
+	297, 295,
+};
+static const unsigned int scifb2_data_b_mux[] = {
+	SCIFB2_RXD_297_MARK, SCIFB2_TXD_295_MARK,
+};
+static const unsigned int scifb2_clk_b_pins[] = {
+	/* SCIFB2_SCK */
+	299,
+};
+static const unsigned int scifb2_clk_b_mux[] = {
+	SCIFB2_SCK_299_MARK,
+};
+static const unsigned int scifb2_ctrl_b_pins[] = {
+	/* SCIFB2_RTS, SCIFB2_CTS */
+	300, 298,
+};
+static const unsigned int scifb2_ctrl_b_mux[] = {
+	SCIFB2_RTS_300_MARK, SCIFB2_CTS_298_MARK,
+};
+/* - SCIFB3 ----------------------------------------------------------------- */
+static const unsigned int scifb3_data_pins[] = {
+	/* SCIFB3_RXD, SCIFB3_TXD */
+	22, 21,
+};
+static const unsigned int scifb3_data_mux[] = {
+	SCIFB3_RXD_22_MARK, SCIFB3_TXD_21_MARK,
+};
+static const unsigned int scifb3_clk_pins[] = {
+	/* SCIFB3_SCK */
+	23,
+};
+static const unsigned int scifb3_clk_mux[] = {
+	SCIFB3_SCK_23_MARK,
+};
+static const unsigned int scifb3_ctrl_pins[] = {
+	/* SCIFB3_RTS, SCIFB3_CTS */
+	19, 20,
+};
+static const unsigned int scifb3_ctrl_mux[] = {
+	SCIFB3_RTS_19_MARK, SCIFB3_CTS_20_MARK,
+};
+static const unsigned int scifb3_data_b_pins[] = {
+	/* SCIFB3_RXD, SCIFB3_TXD */
+	120, 121,
+};
+static const unsigned int scifb3_data_b_mux[] = {
+	SCIFB3_RXD_120_MARK, SCIFB3_TXD_121_MARK,
+};
+static const unsigned int scifb3_clk_b_pins[] = {
+	/* SCIFB3_SCK */
+	40,
+};
+static const unsigned int scifb3_clk_b_mux[] = {
+	SCIFB3_SCK_40_MARK,
+};
+static const unsigned int scifb3_ctrl_b_pins[] = {
+	/* SCIFB3_RTS, SCIFB3_CTS */
+	38, 39,
+};
+static const unsigned int scifb3_ctrl_b_mux[] = {
+	SCIFB3_RTS_38_MARK, SCIFB3_CTS_39_MARK,
+};
+
+static const struct sh_pfc_pin_group pinmux_groups[] = {
+	SH_PFC_PIN_GROUP(scifa0_data),
+	SH_PFC_PIN_GROUP(scifa0_clk),
+	SH_PFC_PIN_GROUP(scifa0_ctrl),
+	SH_PFC_PIN_GROUP(scifa1_data),
+	SH_PFC_PIN_GROUP(scifa1_clk),
+	SH_PFC_PIN_GROUP(scifa1_ctrl),
+	SH_PFC_PIN_GROUP(scifb0_data),
+	SH_PFC_PIN_GROUP(scifb0_clk),
+	SH_PFC_PIN_GROUP(scifb0_ctrl),
+	SH_PFC_PIN_GROUP(scifb1_data),
+	SH_PFC_PIN_GROUP(scifb1_clk),
+	SH_PFC_PIN_GROUP(scifb1_ctrl),
+	SH_PFC_PIN_GROUP(scifb1_data_b),
+	SH_PFC_PIN_GROUP(scifb1_clk_b),
+	SH_PFC_PIN_GROUP(scifb1_ctrl_b),
+	SH_PFC_PIN_GROUP(scifb2_data),
+	SH_PFC_PIN_GROUP(scifb2_clk),
+	SH_PFC_PIN_GROUP(scifb2_ctrl),
+	SH_PFC_PIN_GROUP(scifb2_data_b),
+	SH_PFC_PIN_GROUP(scifb2_clk_b),
+	SH_PFC_PIN_GROUP(scifb2_ctrl_b),
+	SH_PFC_PIN_GROUP(scifb3_data),
+	SH_PFC_PIN_GROUP(scifb3_clk),
+	SH_PFC_PIN_GROUP(scifb3_ctrl),
+	SH_PFC_PIN_GROUP(scifb3_data_b),
+	SH_PFC_PIN_GROUP(scifb3_clk_b),
+	SH_PFC_PIN_GROUP(scifb3_ctrl_b),
+};
+
+static const char * const scifa0_groups[] = {
+	"scifa0_data",
+	"scifa0_clk",
+	"scifa0_ctrl",
+};
+
+static const char * const scifa1_groups[] = {
+	"scifa1_data",
+	"scifa1_clk",
+	"scifa1_ctrl",
+};
+
+static const char * const scifb0_groups[] = {
+	"scifb0_data",
+	"scifb0_clk",
+	"scifb0_ctrl",
+};
+
+static const char * const scifb1_groups[] = {
+	"scifb1_data",
+	"scifb1_clk",
+	"scifb1_ctrl",
+	"scifb1_data_b",
+	"scifb1_clk_b",
+	"scifb1_ctrl_b",
+};
+
+static const char * const scifb2_groups[] = {
+	"scifb2_data",
+	"scifb2_clk",
+	"scifb2_ctrl",
+	"scifb2_data_b",
+	"scifb2_clk_b",
+	"scifb2_ctrl_b",
+};
+
+static const char * const scifb3_groups[] = {
+	"scifb3_data",
+	"scifb3_clk",
+	"scifb3_ctrl",
+	"scifb3_data_b",
+	"scifb3_clk_b",
+	"scifb3_ctrl_b",
+};
+
+static const struct sh_pfc_function pinmux_functions[] = {
+	SH_PFC_FUNCTION(scifa0),
+	SH_PFC_FUNCTION(scifa1),
+	SH_PFC_FUNCTION(scifb0),
+	SH_PFC_FUNCTION(scifb1),
+	SH_PFC_FUNCTION(scifb2),
+	SH_PFC_FUNCTION(scifb3),
+};
+
 #define PINMUX_FN_BASE	ARRAY_SIZE(pinmux_pins)
 
 static const struct pinmux_func pinmux_func_gpios[] = {
@@ -3084,8 +3364,15 @@ const struct sh_pfc_soc_info r8a73a4_pinmux_info = {
 
 	.pins = pinmux_pins,
 	.nr_pins = ARRAY_SIZE(pinmux_pins),
+
 	.ranges = pinmux_ranges,
 	.nr_ranges = ARRAY_SIZE(pinmux_ranges),
+
+	.groups = pinmux_groups,
+	.nr_groups = ARRAY_SIZE(pinmux_groups),
+	.functions = pinmux_functions,
+	.nr_functions = ARRAY_SIZE(pinmux_functions),
+
 	.func_gpios = pinmux_func_gpios,
 	.nr_func_gpios = ARRAY_SIZE(pinmux_func_gpios),
 
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 22:05:02 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed,  3 Apr 2013 11:05:02 +0900
Subject: [PATCH 24/28] ARM: shmobile: r8a73a4: Remove SCIF function GPIOs
In-Reply-To: <1364954706-14727-1-git-send-email-horms+renesas@verge.net.au>
References: <1364954706-14727-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364954706-14727-25-git-send-email-horms+renesas@verge.net.au>

From: Magnus Damm <damm at opensource.se>

Remove SCIF function GPIOs that have been deprecated by the pinctrl API.

Signed-off-by: Magnus Damm <damm at opensource.se>
Acked-by: Linus Walleij <linus.walleij at linaro.org>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/include/mach/r8a73a4.h |   45 -------------------------
 1 file changed, 45 deletions(-)

diff --git a/arch/arm/mach-shmobile/include/mach/r8a73a4.h b/arch/arm/mach-shmobile/include/mach/r8a73a4.h
index 2d4af4a..703387a 100644
--- a/arch/arm/mach-shmobile/include/mach/r8a73a4.h
+++ b/arch/arm/mach-shmobile/include/mach/r8a73a4.h
@@ -200,55 +200,45 @@ enum {
 
 	/* Port19 */
 	GPIO_FN_LCDD19,
-	GPIO_FN_SCIFB3_RTS_19,
 	GPIO_FN_DU0_DB3,
 
 	/* Port20 */
 	GPIO_FN_LCDD20,
-	GPIO_FN_SCIFB3_CTS_20,
 	GPIO_FN_DU0_DB4,
 
 	/* Port21 */
 	GPIO_FN_LCDD21,
-	GPIO_FN_SCIFB3_TXD_21,
 	GPIO_FN_DU0_DB5,
 
 	/* Port22 */
 	GPIO_FN_LCDD22,
-	GPIO_FN_SCIFB3_RXD_22,
 	GPIO_FN_DU0_DB6,
 
 	/* Port23 */
 	GPIO_FN_LCDD23,
-	GPIO_FN_SCIFB3_SCK_23,
 	GPIO_FN_DU0_DB7,
 
 	/* Port24 */
 	GPIO_FN_LCDHSYN,
 	GPIO_FN_LCDCS,
-	GPIO_FN_SCIFB1_RTS_24,
 	GPIO_FN_DU0_EXHSYNC_N_CSYNC_N_HSYNC_N,
 
 	/* Port25 */
 	GPIO_FN_LCDVSYN,
-	GPIO_FN_SCIFB1_CTS_25,
 	GPIO_FN_DU0_EXVSYNC_N_VSYNC_N_CSYNC_N,
 
 	/* Port26 */
 	GPIO_FN_LCDDCK,
 	GPIO_FN_LCDWR,
-	GPIO_FN_SCIFB1_TXD_26,
 	GPIO_FN_DU0_DOTCLKIN,
 
 	/* Port27 */
 	GPIO_FN_LCDDISP,
 	GPIO_FN_LCDRS,
-	GPIO_FN_SCIFB1_RXD_27,
 	GPIO_FN_DU0_DOTCLKOUT,
 
 	/* Port28 */
 	GPIO_FN_LCDRD_N,
-	GPIO_FN_SCIFB1_SCK_28,
 	GPIO_FN_DU0_DOTCLKOUTB,
 
 	/* Port29 */
@@ -262,48 +252,36 @@ enum {
 	GPIO_FN_DU0_ODDF_N_CLAMP,
 
 	/* Port32 */
-	GPIO_FN_SCIFA0_RTS,
 	GPIO_FN_SIM0_DET,
 	GPIO_FN_CSCIF0_RTS,
 
 	/* Port33 */
-	GPIO_FN_SCIFA0_CTS,
 	GPIO_FN_SIM1_DET,
 	GPIO_FN_CSCIF0_CTS,
 
 	/* Port34 */
-	GPIO_FN_SCIFA0_SCK,
 	GPIO_FN_SIM0_PWRON,
 	GPIO_FN_CSCIF0_SCK,
 
 	/* Port35 */
-	GPIO_FN_SCIFA1_RTS,
 	GPIO_FN_CSCIF1_RTS,
 
 	/* Port36 */
-	GPIO_FN_SCIFA1_CTS,
 	GPIO_FN_CSCIF1_CTS,
 
 	/* Port37 */
-	GPIO_FN_SCIFA1_SCK,
 	GPIO_FN_CSCIF1_SCK,
 
 	/* Port38 */
-	GPIO_FN_SCIFB0_RTS,
 	GPIO_FN_TPU0TO1,
-	GPIO_FN_SCIFB3_RTS_38,
 	GPIO_FN_CHSCIF0_HRTS,
 
 	/* Port39 */
-	GPIO_FN_SCIFB0_CTS,
 	GPIO_FN_TPU0TO2,
-	GPIO_FN_SCIFB3_CTS_39,
 	GPIO_FN_CHSCIF0_HCTS,
 
 	/* Port40 */
-	GPIO_FN_SCIFB0_SCK,
 	GPIO_FN_TPU0TO3,
-	GPIO_FN_SCIFB3_SCK_40,
 	GPIO_FN_CHSCIF0_HSCK,
 
 	/* Port64 */
@@ -314,52 +292,44 @@ enum {
 
 	/* Port66 */
 	GPIO_FN_HSI_RX_WAKE,
-	GPIO_FN_SCIFB2_CTS_66,
 	GPIO_FN_MSIOF3_SYNC,
 	GPIO_FN_GenIO4,
 	GPIO_FN_IRQ40,
 
 	/* Port67 */
 	GPIO_FN_HSI_RX_READY,
-	GPIO_FN_SCIFB1_TXD_67,
 	GPIO_FN_GIO_OUT3_67,
 	GPIO_FN_CHSCIF1_HTX,
 
 	/* Port68 */
 	GPIO_FN_HSI_RX_FLAG,
-	GPIO_FN_SCIFB2_TXD_68,
 	GPIO_FN_MSIOF3_TXD,
 	GPIO_FN_GIO_OUT4_68,
 
 	/* Port69 */
 	GPIO_FN_HSI_RX_DATA,
-	GPIO_FN_SCIFB2_RXD_69,
 	GPIO_FN_MSIOF3_RXD,
 	GPIO_FN_GIO_OUT5_69,
 
 	/* Port70 */
 	GPIO_FN_HSI_TX_FLAG,
-	GPIO_FN_SCIFB1_RTS_70,
 	GPIO_FN_GIO_OUT1_70,
 	GPIO_FN_HSIC_TSTCLK0,
 	GPIO_FN_CHSCIF1_HRTS,
 
 	/* Port71 */
 	GPIO_FN_HSI_TX_DATA,
-	GPIO_FN_SCIFB1_CTS_71,
 	GPIO_FN_GIO_OUT2_71,
 	GPIO_FN_HSIC_TSTCLK1,
 	GPIO_FN_CHSCIF1_HCTS,
 
 	/* Port72 */
 	GPIO_FN_HSI_TX_WAKE,
-	GPIO_FN_SCIFB1_RXD_72,
 	GPIO_FN_GenIO8,
 	GPIO_FN_CHSCIF1_HRX,
 
 	/* Port73 */
 	GPIO_FN_HSI_TX_READY,
-	GPIO_FN_SCIFB2_RTS_73,
 	GPIO_FN_MSIOF3_SCK,
 	GPIO_FN_GIO_OUT0_73,
 
@@ -438,36 +408,28 @@ enum {
 	GPIO_FN_IRQ49,
 
 	/* Port116 */
-	GPIO_FN_SCIFA0_TXD,
 	GPIO_FN_CSCIF0_TX,
 
 	/* Port117 */
-	GPIO_FN_SCIFA0_RXD,
 	GPIO_FN_CSCIF0_RX,
 
 	/* Port118 */
-	GPIO_FN_SCIFA1_TXD,
 	GPIO_FN_CSCIF1_TX,
 
 	/* Port119 */
-	GPIO_FN_SCIFA1_RXD,
 	GPIO_FN_CSCIF1_RX,
 
 	/* Port120 */
 	GPIO_FN_SF_PORT_1_120,
-	GPIO_FN_SCIFB3_RXD_120,
 	GPIO_FN_DU0_CDE,
 
 	/* Port121 */
 	GPIO_FN_SF_PORT_0_121,
-	GPIO_FN_SCIFB3_TXD_121,
 
 	/* Port122 */
-	GPIO_FN_SCIFB0_TXD,
 	GPIO_FN_CHSCIF0_HTX,
 
 	/* Port123 */
-	GPIO_FN_SCIFB0_RXD,
 	GPIO_FN_CHSCIF0_HRX,
 
 	/* Port124 */
@@ -761,11 +723,9 @@ enum {
 	GPIO_FN_MSIOF0_TXD,
 
 	/* Port261 */
-	GPIO_FN_SCIFB1_SCK_261,
 	GPIO_FN_CHSCIF1_HSCK,
 
 	/* Port262 */
-	GPIO_FN_SCIFB2_SCK_262,
 
 	/* Port263 - Port266 FN1 */
 	GPIO_FN_MSIOF1_SS2,
@@ -849,7 +809,6 @@ enum {
 	/* Port295 */
 	GPIO_FN_SDHID2_0,
 	GPIO_FN_MSIOF4_TXD,
-	GPIO_FN_SCIFB2_TXD_295,
 	GPIO_FN_MSIOF6_TXD,
 
 	/* Port296 */
@@ -870,10 +829,6 @@ enum {
 	GPIO_FN_MSIOF4_SS1,
 
 	/* Port297 - Port300 FN3 */
-	GPIO_FN_SCIFB2_RXD_297,
-	GPIO_FN_SCIFB2_CTS_298,
-	GPIO_FN_SCIFB2_SCK_299,
-	GPIO_FN_SCIFB2_RTS_300,
 
 	/* Port297 - Port300 FN4 */
 	GPIO_FN_MSIOF6_RXD,
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 22:04:59 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed,  3 Apr 2013 11:04:59 +0900
Subject: [PATCH 21/28] sh-pfc: r8a73a4: Add IRQC pin groups and functions
In-Reply-To: <1364954706-14727-1-git-send-email-horms+renesas@verge.net.au>
References: <1364954706-14727-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364954706-14727-22-git-send-email-horms+renesas@verge.net.au>

From: Magnus Damm <damm at opensource.se>

V2 of PINCTRL support for r8a73a4 IRQC hardware
and in particular the external pins IRQ0 -> IRQ57.

Signed-off-by: Magnus Damm <damm at opensource.se>
Acked-by: Linus Walleij <linus.walleij at linaro.org>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 drivers/pinctrl/sh-pfc/pfc-r8a73a4.c |  186 ++++++++++++++++++++++++++++++++++
 1 file changed, 186 insertions(+)

diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a73a4.c b/drivers/pinctrl/sh-pfc/pfc-r8a73a4.c
index cd5c5fd..8a5288c 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a73a4.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a73a4.c
@@ -1576,6 +1576,72 @@ static const struct pinmux_range pinmux_ranges[] = {
 	{.begin = 320, .end = 329,},
 };
 
+/* - IRQC ------------------------------------------------------------------- */
+#define IRQC_PINS_MUX(pin, irq_mark)				\
+static const unsigned int irqc_irq##irq_mark##_pins[] = {	\
+	pin,							\
+};								\
+static const unsigned int irqc_irq##irq_mark##_mux[] = {	\
+	IRQ##irq_mark##_MARK,					\
+}
+IRQC_PINS_MUX(0, 0);
+IRQC_PINS_MUX(1, 1);
+IRQC_PINS_MUX(2, 2);
+IRQC_PINS_MUX(3, 3);
+IRQC_PINS_MUX(4, 4);
+IRQC_PINS_MUX(5, 5);
+IRQC_PINS_MUX(6, 6);
+IRQC_PINS_MUX(7, 7);
+IRQC_PINS_MUX(8, 8);
+IRQC_PINS_MUX(9, 9);
+IRQC_PINS_MUX(10, 10);
+IRQC_PINS_MUX(11, 11);
+IRQC_PINS_MUX(12, 12);
+IRQC_PINS_MUX(13, 13);
+IRQC_PINS_MUX(14, 14);
+IRQC_PINS_MUX(15, 15);
+IRQC_PINS_MUX(66, 40);
+IRQC_PINS_MUX(84, 19);
+IRQC_PINS_MUX(85, 18);
+IRQC_PINS_MUX(102, 41);
+IRQC_PINS_MUX(103, 42);
+IRQC_PINS_MUX(109, 43);
+IRQC_PINS_MUX(110, 44);
+IRQC_PINS_MUX(111, 45);
+IRQC_PINS_MUX(112, 46);
+IRQC_PINS_MUX(113, 47);
+IRQC_PINS_MUX(114, 48);
+IRQC_PINS_MUX(115, 49);
+IRQC_PINS_MUX(160, 20);
+IRQC_PINS_MUX(161, 21);
+IRQC_PINS_MUX(162, 22);
+IRQC_PINS_MUX(163, 23);
+IRQC_PINS_MUX(175, 24);
+IRQC_PINS_MUX(176, 25);
+IRQC_PINS_MUX(177, 26);
+IRQC_PINS_MUX(178, 27);
+IRQC_PINS_MUX(192, 31);
+IRQC_PINS_MUX(193, 32);
+IRQC_PINS_MUX(194, 33);
+IRQC_PINS_MUX(195, 34);
+IRQC_PINS_MUX(196, 35);
+IRQC_PINS_MUX(197, 36);
+IRQC_PINS_MUX(198, 37);
+IRQC_PINS_MUX(199, 38);
+IRQC_PINS_MUX(200, 39);
+IRQC_PINS_MUX(290, 51);
+IRQC_PINS_MUX(296, 52);
+IRQC_PINS_MUX(301, 50);
+IRQC_PINS_MUX(320, 16);
+IRQC_PINS_MUX(321, 17);
+IRQC_PINS_MUX(322, 28);
+IRQC_PINS_MUX(323, 29);
+IRQC_PINS_MUX(324, 30);
+IRQC_PINS_MUX(325, 53);
+IRQC_PINS_MUX(326, 54);
+IRQC_PINS_MUX(327, 55);
+IRQC_PINS_MUX(328, 56);
+IRQC_PINS_MUX(329, 57);
 /* - SCIFA0 ----------------------------------------------------------------- */
 static const unsigned int scifa0_data_pins[] = {
 	/* SCIFA0_RXD, SCIFA0_TXD */
@@ -1773,6 +1839,64 @@ static const unsigned int scifb3_ctrl_b_mux[] = {
 };
 
 static const struct sh_pfc_pin_group pinmux_groups[] = {
+	SH_PFC_PIN_GROUP(irqc_irq0),
+	SH_PFC_PIN_GROUP(irqc_irq1),
+	SH_PFC_PIN_GROUP(irqc_irq2),
+	SH_PFC_PIN_GROUP(irqc_irq3),
+	SH_PFC_PIN_GROUP(irqc_irq4),
+	SH_PFC_PIN_GROUP(irqc_irq5),
+	SH_PFC_PIN_GROUP(irqc_irq6),
+	SH_PFC_PIN_GROUP(irqc_irq7),
+	SH_PFC_PIN_GROUP(irqc_irq8),
+	SH_PFC_PIN_GROUP(irqc_irq9),
+	SH_PFC_PIN_GROUP(irqc_irq10),
+	SH_PFC_PIN_GROUP(irqc_irq11),
+	SH_PFC_PIN_GROUP(irqc_irq12),
+	SH_PFC_PIN_GROUP(irqc_irq13),
+	SH_PFC_PIN_GROUP(irqc_irq14),
+	SH_PFC_PIN_GROUP(irqc_irq15),
+	SH_PFC_PIN_GROUP(irqc_irq16),
+	SH_PFC_PIN_GROUP(irqc_irq17),
+	SH_PFC_PIN_GROUP(irqc_irq18),
+	SH_PFC_PIN_GROUP(irqc_irq19),
+	SH_PFC_PIN_GROUP(irqc_irq20),
+	SH_PFC_PIN_GROUP(irqc_irq21),
+	SH_PFC_PIN_GROUP(irqc_irq22),
+	SH_PFC_PIN_GROUP(irqc_irq23),
+	SH_PFC_PIN_GROUP(irqc_irq24),
+	SH_PFC_PIN_GROUP(irqc_irq25),
+	SH_PFC_PIN_GROUP(irqc_irq26),
+	SH_PFC_PIN_GROUP(irqc_irq27),
+	SH_PFC_PIN_GROUP(irqc_irq28),
+	SH_PFC_PIN_GROUP(irqc_irq29),
+	SH_PFC_PIN_GROUP(irqc_irq30),
+	SH_PFC_PIN_GROUP(irqc_irq31),
+	SH_PFC_PIN_GROUP(irqc_irq32),
+	SH_PFC_PIN_GROUP(irqc_irq33),
+	SH_PFC_PIN_GROUP(irqc_irq34),
+	SH_PFC_PIN_GROUP(irqc_irq35),
+	SH_PFC_PIN_GROUP(irqc_irq36),
+	SH_PFC_PIN_GROUP(irqc_irq37),
+	SH_PFC_PIN_GROUP(irqc_irq38),
+	SH_PFC_PIN_GROUP(irqc_irq39),
+	SH_PFC_PIN_GROUP(irqc_irq40),
+	SH_PFC_PIN_GROUP(irqc_irq41),
+	SH_PFC_PIN_GROUP(irqc_irq42),
+	SH_PFC_PIN_GROUP(irqc_irq43),
+	SH_PFC_PIN_GROUP(irqc_irq44),
+	SH_PFC_PIN_GROUP(irqc_irq45),
+	SH_PFC_PIN_GROUP(irqc_irq46),
+	SH_PFC_PIN_GROUP(irqc_irq47),
+	SH_PFC_PIN_GROUP(irqc_irq48),
+	SH_PFC_PIN_GROUP(irqc_irq49),
+	SH_PFC_PIN_GROUP(irqc_irq50),
+	SH_PFC_PIN_GROUP(irqc_irq51),
+	SH_PFC_PIN_GROUP(irqc_irq52),
+	SH_PFC_PIN_GROUP(irqc_irq53),
+	SH_PFC_PIN_GROUP(irqc_irq54),
+	SH_PFC_PIN_GROUP(irqc_irq55),
+	SH_PFC_PIN_GROUP(irqc_irq56),
+	SH_PFC_PIN_GROUP(irqc_irq57),
 	SH_PFC_PIN_GROUP(scifa0_data),
 	SH_PFC_PIN_GROUP(scifa0_clk),
 	SH_PFC_PIN_GROUP(scifa0_ctrl),
@@ -1802,6 +1926,67 @@ static const struct sh_pfc_pin_group pinmux_groups[] = {
 	SH_PFC_PIN_GROUP(scifb3_ctrl_b),
 };
 
+static const char * const irqc_groups[] = {
+	"irqc_irq0",
+	"irqc_irq1",
+	"irqc_irq2",
+	"irqc_irq3",
+	"irqc_irq4",
+	"irqc_irq5",
+	"irqc_irq6",
+	"irqc_irq7",
+	"irqc_irq8",
+	"irqc_irq9",
+	"irqc_irq10",
+	"irqc_irq11",
+	"irqc_irq12",
+	"irqc_irq13",
+	"irqc_irq14",
+	"irqc_irq15",
+	"irqc_irq16",
+	"irqc_irq17",
+	"irqc_irq18",
+	"irqc_irq19",
+	"irqc_irq20",
+	"irqc_irq21",
+	"irqc_irq22",
+	"irqc_irq23",
+	"irqc_irq24",
+	"irqc_irq25",
+	"irqc_irq26",
+	"irqc_irq27",
+	"irqc_irq28",
+	"irqc_irq29",
+	"irqc_irq30",
+	"irqc_irq31",
+	"irqc_irq32",
+	"irqc_irq33",
+	"irqc_irq34",
+	"irqc_irq35",
+	"irqc_irq36",
+	"irqc_irq37",
+	"irqc_irq38",
+	"irqc_irq39",
+	"irqc_irq40",
+	"irqc_irq41",
+	"irqc_irq42",
+	"irqc_irq43",
+	"irqc_irq44",
+	"irqc_irq45",
+	"irqc_irq46",
+	"irqc_irq47",
+	"irqc_irq48",
+	"irqc_irq49",
+	"irqc_irq50",
+	"irqc_irq51",
+	"irqc_irq52",
+	"irqc_irq53",
+	"irqc_irq54",
+	"irqc_irq55",
+	"irqc_irq56",
+	"irqc_irq57",
+};
+
 static const char * const scifa0_groups[] = {
 	"scifa0_data",
 	"scifa0_clk",
@@ -1848,6 +2033,7 @@ static const char * const scifb3_groups[] = {
 };
 
 static const struct sh_pfc_function pinmux_functions[] = {
+	SH_PFC_FUNCTION(irqc),
 	SH_PFC_FUNCTION(scifa0),
 	SH_PFC_FUNCTION(scifa1),
 	SH_PFC_FUNCTION(scifb0),
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 22:04:57 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed,  3 Apr 2013 11:04:57 +0900
Subject: [PATCH 19/28] sh-pfc: r8a73a4: Add bias (pull-up/down) pinconf support
In-Reply-To: <1364954706-14727-1-git-send-email-horms+renesas@verge.net.au>
References: <1364954706-14727-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364954706-14727-20-git-send-email-horms+renesas@verge.net.au>

From: Magnus Damm <damm at opensource.se>

Implement pull-up/down support for r8a73a4 similar to the implementation
for sh73a0.

Signed-off-by: Magnus Damm <damm at opensource.se>
Acked-by: Linus Walleij <linus.walleij at linaro.org>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 drivers/pinctrl/sh-pfc/pfc-r8a73a4.c |  197 +++++++++++++++++++++++++++++++++-
 1 file changed, 196 insertions(+), 1 deletion(-)

diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a73a4.c b/drivers/pinctrl/sh-pfc/pfc-r8a73a4.c
index 0177329..86a5fd3 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a73a4.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a73a4.c
@@ -17,10 +17,13 @@
  * along with this program; if not, write to the Free Software
  * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
  */
+#include <linux/io.h>
 #include <linux/kernel.h>
+#include <linux/pinctrl/pinconf-generic.h>
 #include <mach/irqs.h>
 #include <mach/r8a73a4.h>
 
+#include "core.h"
 #include "sh_pfc.h"
 
 #define CPU_ALL_PORT(fn, pfx, sfx)					\
@@ -1420,8 +1423,143 @@ static const pinmux_enum_t pinmux_data[] = {
 	PINMUX_DATA(IRQ57_MARK,			PORT329_FN0),
 };
 
+#define R8A73A4_PIN(pin, cfgs)			\
+	{					\
+		.name = __stringify(PORT##pin),	\
+		.enum_id = PORT##pin##_DATA,	\
+		.configs = cfgs,		\
+	}
+
+#define __O	(SH_PFC_PIN_CFG_OUTPUT)
+#define __IO	(SH_PFC_PIN_CFG_INPUT | SH_PFC_PIN_CFG_OUTPUT)
+#define __PUD	(SH_PFC_PIN_CFG_PULL_DOWN | SH_PFC_PIN_CFG_PULL_UP)
+
+#define R8A73A4_PIN_IO_PU_PD(pin)       R8A73A4_PIN(pin, __IO | __PUD)
+#define R8A73A4_PIN_O(pin)              R8A73A4_PIN(pin, __O)
+
 static struct sh_pfc_pin pinmux_pins[] = {
-	GPIO_PORT_ALL(),
+	R8A73A4_PIN_IO_PU_PD(0), R8A73A4_PIN_IO_PU_PD(1),
+	R8A73A4_PIN_IO_PU_PD(2), R8A73A4_PIN_IO_PU_PD(3),
+	R8A73A4_PIN_IO_PU_PD(4), R8A73A4_PIN_IO_PU_PD(5),
+	R8A73A4_PIN_IO_PU_PD(6), R8A73A4_PIN_IO_PU_PD(7),
+	R8A73A4_PIN_IO_PU_PD(8), R8A73A4_PIN_IO_PU_PD(9),
+	R8A73A4_PIN_IO_PU_PD(10), R8A73A4_PIN_IO_PU_PD(11),
+	R8A73A4_PIN_IO_PU_PD(12), R8A73A4_PIN_IO_PU_PD(13),
+	R8A73A4_PIN_IO_PU_PD(14), R8A73A4_PIN_IO_PU_PD(15),
+	R8A73A4_PIN_IO_PU_PD(16), R8A73A4_PIN_IO_PU_PD(17),
+	R8A73A4_PIN_IO_PU_PD(18), R8A73A4_PIN_IO_PU_PD(19),
+	R8A73A4_PIN_IO_PU_PD(20), R8A73A4_PIN_IO_PU_PD(21),
+	R8A73A4_PIN_IO_PU_PD(22), R8A73A4_PIN_IO_PU_PD(23),
+	R8A73A4_PIN_IO_PU_PD(24), R8A73A4_PIN_IO_PU_PD(25),
+	R8A73A4_PIN_IO_PU_PD(26), R8A73A4_PIN_IO_PU_PD(27),
+	R8A73A4_PIN_IO_PU_PD(28), R8A73A4_PIN_IO_PU_PD(29),
+	R8A73A4_PIN_IO_PU_PD(30),
+	R8A73A4_PIN_IO_PU_PD(32), R8A73A4_PIN_IO_PU_PD(33),
+	R8A73A4_PIN_IO_PU_PD(34), R8A73A4_PIN_IO_PU_PD(35),
+	R8A73A4_PIN_IO_PU_PD(36), R8A73A4_PIN_IO_PU_PD(37),
+	R8A73A4_PIN_IO_PU_PD(38), R8A73A4_PIN_IO_PU_PD(39),
+	R8A73A4_PIN_IO_PU_PD(40),
+	R8A73A4_PIN_IO_PU_PD(64), R8A73A4_PIN_IO_PU_PD(65),
+	R8A73A4_PIN_IO_PU_PD(66), R8A73A4_PIN_IO_PU_PD(67),
+	R8A73A4_PIN_IO_PU_PD(68), R8A73A4_PIN_IO_PU_PD(69),
+	R8A73A4_PIN_IO_PU_PD(70), R8A73A4_PIN_IO_PU_PD(71),
+	R8A73A4_PIN_IO_PU_PD(72), R8A73A4_PIN_IO_PU_PD(73),
+	R8A73A4_PIN_O(74), R8A73A4_PIN_IO_PU_PD(75),
+	R8A73A4_PIN_IO_PU_PD(76), R8A73A4_PIN_IO_PU_PD(77),
+	R8A73A4_PIN_IO_PU_PD(78), R8A73A4_PIN_IO_PU_PD(79),
+	R8A73A4_PIN_IO_PU_PD(80), R8A73A4_PIN_IO_PU_PD(81),
+	R8A73A4_PIN_IO_PU_PD(82), R8A73A4_PIN_IO_PU_PD(83),
+	R8A73A4_PIN_IO_PU_PD(84), R8A73A4_PIN_IO_PU_PD(85),
+	R8A73A4_PIN_IO_PU_PD(96), R8A73A4_PIN_IO_PU_PD(97),
+	R8A73A4_PIN_IO_PU_PD(98), R8A73A4_PIN_IO_PU_PD(99),
+	R8A73A4_PIN_IO_PU_PD(100), R8A73A4_PIN_IO_PU_PD(101),
+	R8A73A4_PIN_IO_PU_PD(102), R8A73A4_PIN_IO_PU_PD(103),
+	R8A73A4_PIN_IO_PU_PD(104), R8A73A4_PIN_IO_PU_PD(105),
+	R8A73A4_PIN_IO_PU_PD(106), R8A73A4_PIN_IO_PU_PD(107),
+	R8A73A4_PIN_IO_PU_PD(108), R8A73A4_PIN_IO_PU_PD(109),
+	R8A73A4_PIN_IO_PU_PD(110), R8A73A4_PIN_IO_PU_PD(111),
+	R8A73A4_PIN_IO_PU_PD(112), R8A73A4_PIN_IO_PU_PD(113),
+	R8A73A4_PIN_IO_PU_PD(114), R8A73A4_PIN_IO_PU_PD(115),
+	R8A73A4_PIN_IO_PU_PD(116), R8A73A4_PIN_IO_PU_PD(117),
+	R8A73A4_PIN_IO_PU_PD(118), R8A73A4_PIN_IO_PU_PD(119),
+	R8A73A4_PIN_IO_PU_PD(120), R8A73A4_PIN_IO_PU_PD(121),
+	R8A73A4_PIN_IO_PU_PD(122), R8A73A4_PIN_IO_PU_PD(123),
+	R8A73A4_PIN_IO_PU_PD(124), R8A73A4_PIN_IO_PU_PD(125),
+	R8A73A4_PIN_IO_PU_PD(126),
+	R8A73A4_PIN_IO_PU_PD(128), R8A73A4_PIN_IO_PU_PD(129),
+	R8A73A4_PIN_IO_PU_PD(130), R8A73A4_PIN_IO_PU_PD(131),
+	R8A73A4_PIN_IO_PU_PD(132), R8A73A4_PIN_IO_PU_PD(133),
+	R8A73A4_PIN_IO_PU_PD(134),
+	R8A73A4_PIN_IO_PU_PD(160), R8A73A4_PIN_IO_PU_PD(161),
+	R8A73A4_PIN_IO_PU_PD(162), R8A73A4_PIN_IO_PU_PD(163),
+	R8A73A4_PIN_IO_PU_PD(164), R8A73A4_PIN_IO_PU_PD(165),
+	R8A73A4_PIN_IO_PU_PD(166), R8A73A4_PIN_IO_PU_PD(167),
+	R8A73A4_PIN_IO_PU_PD(168), R8A73A4_PIN_IO_PU_PD(169),
+	R8A73A4_PIN_IO_PU_PD(170), R8A73A4_PIN_IO_PU_PD(171),
+	R8A73A4_PIN_IO_PU_PD(172), R8A73A4_PIN_IO_PU_PD(173),
+	R8A73A4_PIN_IO_PU_PD(174), R8A73A4_PIN_IO_PU_PD(175),
+	R8A73A4_PIN_IO_PU_PD(176), R8A73A4_PIN_IO_PU_PD(177),
+	R8A73A4_PIN_IO_PU_PD(178),
+	R8A73A4_PIN_IO_PU_PD(192), R8A73A4_PIN_IO_PU_PD(193),
+	R8A73A4_PIN_IO_PU_PD(194), R8A73A4_PIN_IO_PU_PD(195),
+	R8A73A4_PIN_IO_PU_PD(196), R8A73A4_PIN_IO_PU_PD(197),
+	R8A73A4_PIN_IO_PU_PD(198), R8A73A4_PIN_IO_PU_PD(199),
+	R8A73A4_PIN_IO_PU_PD(200), R8A73A4_PIN_IO_PU_PD(201),
+	R8A73A4_PIN_IO_PU_PD(202), R8A73A4_PIN_IO_PU_PD(203),
+	R8A73A4_PIN_IO_PU_PD(204), R8A73A4_PIN_IO_PU_PD(205),
+	R8A73A4_PIN_IO_PU_PD(206), R8A73A4_PIN_IO_PU_PD(207),
+	R8A73A4_PIN_IO_PU_PD(208), R8A73A4_PIN_IO_PU_PD(209),
+	R8A73A4_PIN_IO_PU_PD(210), R8A73A4_PIN_IO_PU_PD(211),
+	R8A73A4_PIN_IO_PU_PD(212), R8A73A4_PIN_IO_PU_PD(213),
+	R8A73A4_PIN_IO_PU_PD(214), R8A73A4_PIN_IO_PU_PD(215),
+	R8A73A4_PIN_IO_PU_PD(216), R8A73A4_PIN_IO_PU_PD(217),
+	R8A73A4_PIN_IO_PU_PD(218), R8A73A4_PIN_IO_PU_PD(219),
+	R8A73A4_PIN_IO_PU_PD(220), R8A73A4_PIN_IO_PU_PD(221),
+	R8A73A4_PIN_IO_PU_PD(222),
+	R8A73A4_PIN_IO_PU_PD(224), R8A73A4_PIN_IO_PU_PD(225),
+	R8A73A4_PIN_IO_PU_PD(226), R8A73A4_PIN_IO_PU_PD(227),
+	R8A73A4_PIN_IO_PU_PD(228), R8A73A4_PIN_IO_PU_PD(229),
+	R8A73A4_PIN_IO_PU_PD(230), R8A73A4_PIN_IO_PU_PD(231),
+	R8A73A4_PIN_IO_PU_PD(232), R8A73A4_PIN_IO_PU_PD(233),
+	R8A73A4_PIN_IO_PU_PD(234), R8A73A4_PIN_IO_PU_PD(235),
+	R8A73A4_PIN_IO_PU_PD(236), R8A73A4_PIN_IO_PU_PD(237),
+	R8A73A4_PIN_IO_PU_PD(238), R8A73A4_PIN_IO_PU_PD(239),
+	R8A73A4_PIN_IO_PU_PD(240), R8A73A4_PIN_IO_PU_PD(241),
+	R8A73A4_PIN_IO_PU_PD(242), R8A73A4_PIN_IO_PU_PD(243),
+	R8A73A4_PIN_IO_PU_PD(244), R8A73A4_PIN_IO_PU_PD(245),
+	R8A73A4_PIN_IO_PU_PD(246), R8A73A4_PIN_IO_PU_PD(247),
+	R8A73A4_PIN_IO_PU_PD(248), R8A73A4_PIN_IO_PU_PD(249),
+	R8A73A4_PIN_IO_PU_PD(250),
+	R8A73A4_PIN_IO_PU_PD(256), R8A73A4_PIN_IO_PU_PD(257),
+	R8A73A4_PIN_IO_PU_PD(258), R8A73A4_PIN_IO_PU_PD(259),
+	R8A73A4_PIN_IO_PU_PD(260), R8A73A4_PIN_IO_PU_PD(261),
+	R8A73A4_PIN_IO_PU_PD(262), R8A73A4_PIN_IO_PU_PD(263),
+	R8A73A4_PIN_IO_PU_PD(264), R8A73A4_PIN_IO_PU_PD(265),
+	R8A73A4_PIN_IO_PU_PD(266), R8A73A4_PIN_IO_PU_PD(267),
+	R8A73A4_PIN_IO_PU_PD(268), R8A73A4_PIN_IO_PU_PD(269),
+	R8A73A4_PIN_IO_PU_PD(270), R8A73A4_PIN_IO_PU_PD(271),
+	R8A73A4_PIN_IO_PU_PD(272), R8A73A4_PIN_IO_PU_PD(273),
+	R8A73A4_PIN_IO_PU_PD(274), R8A73A4_PIN_IO_PU_PD(275),
+	R8A73A4_PIN_IO_PU_PD(276), R8A73A4_PIN_IO_PU_PD(277),
+	R8A73A4_PIN_IO_PU_PD(278), R8A73A4_PIN_IO_PU_PD(279),
+	R8A73A4_PIN_IO_PU_PD(280), R8A73A4_PIN_IO_PU_PD(281),
+	R8A73A4_PIN_IO_PU_PD(282), R8A73A4_PIN_IO_PU_PD(283),
+	R8A73A4_PIN_O(288), R8A73A4_PIN_IO_PU_PD(289),
+	R8A73A4_PIN_IO_PU_PD(290), R8A73A4_PIN_IO_PU_PD(291),
+	R8A73A4_PIN_IO_PU_PD(292), R8A73A4_PIN_IO_PU_PD(293),
+	R8A73A4_PIN_IO_PU_PD(294), R8A73A4_PIN_IO_PU_PD(295),
+	R8A73A4_PIN_IO_PU_PD(296), R8A73A4_PIN_IO_PU_PD(297),
+	R8A73A4_PIN_IO_PU_PD(298), R8A73A4_PIN_IO_PU_PD(299),
+	R8A73A4_PIN_IO_PU_PD(300), R8A73A4_PIN_IO_PU_PD(301),
+	R8A73A4_PIN_IO_PU_PD(302), R8A73A4_PIN_IO_PU_PD(303),
+	R8A73A4_PIN_IO_PU_PD(304), R8A73A4_PIN_IO_PU_PD(305),
+	R8A73A4_PIN_IO_PU_PD(306), R8A73A4_PIN_IO_PU_PD(307),
+	R8A73A4_PIN_IO_PU_PD(308),
+	R8A73A4_PIN_IO_PU_PD(320), R8A73A4_PIN_IO_PU_PD(321),
+	R8A73A4_PIN_IO_PU_PD(322), R8A73A4_PIN_IO_PU_PD(323),
+	R8A73A4_PIN_IO_PU_PD(324), R8A73A4_PIN_IO_PU_PD(325),
+	R8A73A4_PIN_IO_PU_PD(326), R8A73A4_PIN_IO_PU_PD(327),
+	R8A73A4_PIN_IO_PU_PD(328), R8A73A4_PIN_IO_PU_PD(329),
 };
 
 static const struct pinmux_range pinmux_ranges[] = {
@@ -2878,8 +3016,65 @@ static const struct pinmux_irq pinmux_irqs[] = {
 	PINMUX_IRQ(irq_pin(56), 328),
 	PINMUX_IRQ(irq_pin(57), 329),
 };
+
+#define PORTCR_PULMD_OFF (0 << 6)
+#define PORTCR_PULMD_DOWN (2 << 6)
+#define PORTCR_PULMD_UP (3 << 6)
+#define PORTCR_PULMD_MASK (3 << 6)
+
+static const unsigned int r8a73a4_portcr_offsets[] = {
+	0x00000000, 0x00001000, 0x00000000, 0x00001000,
+	0x00001000, 0x00002000, 0x00002000, 0x00002000,
+	0x00002000, 0x00003000, 0x00003000,
+};
+
+static unsigned int r8a73a4_pinmux_get_bias(struct sh_pfc *pfc,
+					    unsigned int pin)
+{
+	void __iomem *addr;
+
+	addr = pfc->window->virt + r8a73a4_portcr_offsets[pin >> 5] + pin;
+
+	switch (ioread8(addr) & PORTCR_PULMD_MASK) {
+	case PORTCR_PULMD_UP:
+		return PIN_CONFIG_BIAS_PULL_UP;
+	case PORTCR_PULMD_DOWN:
+		return PIN_CONFIG_BIAS_PULL_DOWN;
+	case PORTCR_PULMD_OFF:
+	default:
+		return PIN_CONFIG_BIAS_DISABLE;
+	}
+}
+
+static void r8a73a4_pinmux_set_bias(struct sh_pfc *pfc, unsigned int pin,
+				   unsigned int bias)
+{
+	void __iomem *addr;
+	u32 value;
+
+	addr = pfc->window->virt + r8a73a4_portcr_offsets[pin >> 5] + pin;
+	value = ioread8(addr) & ~PORTCR_PULMD_MASK;
+
+	switch (bias) {
+	case PIN_CONFIG_BIAS_PULL_UP:
+		value |= PORTCR_PULMD_UP;
+		break;
+	case PIN_CONFIG_BIAS_PULL_DOWN:
+		value |= PORTCR_PULMD_DOWN;
+		break;
+	}
+
+	iowrite8(value, addr);
+}
+
+static const struct sh_pfc_soc_operations r8a73a4_pinmux_ops = {
+	.get_bias = r8a73a4_pinmux_get_bias,
+	.set_bias = r8a73a4_pinmux_set_bias,
+};
+
 const struct sh_pfc_soc_info r8a73a4_pinmux_info = {
 	.name		= "r8a73a4_pfc",
+	.ops		= &r8a73a4_pinmux_ops,
 
 	.input = { PINMUX_INPUT_BEGIN, PINMUX_INPUT_END },
 	.input_pu = { PINMUX_INPUT_PULLUP_BEGIN, PINMUX_INPUT_PULLUP_END },
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 22:05:00 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed,  3 Apr 2013 11:05:00 +0900
Subject: [PATCH 22/28] sh-pfc: r8a73a4: Remove SCIF function GPIOS
In-Reply-To: <1364954706-14727-1-git-send-email-horms+renesas@verge.net.au>
References: <1364954706-14727-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364954706-14727-23-git-send-email-horms+renesas@verge.net.au>

From: Magnus Damm <damm at opensource.se>

The r8a73a4 board support will use the pinctrl API to control the SCIF
pins, remove the corresponding unused function GPIOS.

Signed-off-by: Magnus Damm <damm at opensource.se>
Acked-by: Linus Walleij <linus.walleij at linaro.org>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 drivers/pinctrl/sh-pfc/pfc-r8a73a4.c |   45 ----------------------------------
 1 file changed, 45 deletions(-)

diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a73a4.c b/drivers/pinctrl/sh-pfc/pfc-r8a73a4.c
index 8a5288c..470b18f 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a73a4.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a73a4.c
@@ -2160,55 +2160,45 @@ static const struct pinmux_func pinmux_func_gpios[] = {
 
 	/* Port19 */
 	GPIO_FN(LCDD19),
-	GPIO_FN(SCIFB3_RTS_19),
 	GPIO_FN(DU0_DB3),
 
 	/* Port20 */
 	GPIO_FN(LCDD20),
-	GPIO_FN(SCIFB3_CTS_20),
 	GPIO_FN(DU0_DB4),
 
 	/* Port21 */
 	GPIO_FN(LCDD21),
-	GPIO_FN(SCIFB3_TXD_21),
 	GPIO_FN(DU0_DB5),
 
 	/* Port22 */
 	GPIO_FN(LCDD22),
-	GPIO_FN(SCIFB3_RXD_22),
 	GPIO_FN(DU0_DB6),
 
 	/* Port23 */
 	GPIO_FN(LCDD23),
-	GPIO_FN(SCIFB3_SCK_23),
 	GPIO_FN(DU0_DB7),
 
 	/* Port24 */
 	GPIO_FN(LCDHSYN),
 	GPIO_FN(LCDCS),
-	GPIO_FN(SCIFB1_RTS_24),
 	GPIO_FN(DU0_EXHSYNC_N_CSYNC_N_HSYNC_N),
 
 	/* Port25 */
 	GPIO_FN(LCDVSYN),
-	GPIO_FN(SCIFB1_CTS_25),
 	GPIO_FN(DU0_EXVSYNC_N_VSYNC_N_CSYNC_N),
 
 	/* Port26 */
 	GPIO_FN(LCDDCK),
 	GPIO_FN(LCDWR),
-	GPIO_FN(SCIFB1_TXD_26),
 	GPIO_FN(DU0_DOTCLKIN),
 
 	/* Port27 */
 	GPIO_FN(LCDDISP),
 	GPIO_FN(LCDRS),
-	GPIO_FN(SCIFB1_RXD_27),
 	GPIO_FN(DU0_DOTCLKOUT),
 
 	/* Port28 */
 	GPIO_FN(LCDRD_N),
-	GPIO_FN(SCIFB1_SCK_28),
 	GPIO_FN(DU0_DOTCLKOUTB),
 
 	/* Port29 */
@@ -2222,48 +2212,36 @@ static const struct pinmux_func pinmux_func_gpios[] = {
 	GPIO_FN(DU0_ODDF_N_CLAMP),
 
 	/* Port32 */
-	GPIO_FN(SCIFA0_RTS),
 	GPIO_FN(SIM0_DET),
 	GPIO_FN(CSCIF0_RTS),
 
 	/* Port33 */
-	GPIO_FN(SCIFA0_CTS),
 	GPIO_FN(SIM1_DET),
 	GPIO_FN(CSCIF0_CTS),
 
 	/* Port34 */
-	GPIO_FN(SCIFA0_SCK),
 	GPIO_FN(SIM0_PWRON),
 	GPIO_FN(CSCIF0_SCK),
 
 	/* Port35 */
-	GPIO_FN(SCIFA1_RTS),
 	GPIO_FN(CSCIF1_RTS),
 
 	/* Port36 */
-	GPIO_FN(SCIFA1_CTS),
 	GPIO_FN(CSCIF1_CTS),
 
 	/* Port37 */
-	GPIO_FN(SCIFA1_SCK),
 	GPIO_FN(CSCIF1_SCK),
 
 	/* Port38 */
-	GPIO_FN(SCIFB0_RTS),
 	GPIO_FN(TPU0TO1),
-	GPIO_FN(SCIFB3_RTS_38),
 	GPIO_FN(CHSCIF0_HRTS),
 
 	/* Port39 */
-	GPIO_FN(SCIFB0_CTS),
 	GPIO_FN(TPU0TO2),
-	GPIO_FN(SCIFB3_CTS_39),
 	GPIO_FN(CHSCIF0_HCTS),
 
 	/* Port40 */
-	GPIO_FN(SCIFB0_SCK),
 	GPIO_FN(TPU0TO3),
-	GPIO_FN(SCIFB3_SCK_40),
 	GPIO_FN(CHSCIF0_HSCK),
 
 	/* Port64 */
@@ -2274,52 +2252,44 @@ static const struct pinmux_func pinmux_func_gpios[] = {
 
 	/* Port66 */
 	GPIO_FN(HSI_RX_WAKE),
-	GPIO_FN(SCIFB2_CTS_66),
 	GPIO_FN(MSIOF3_SYNC),
 	GPIO_FN(GenIO4),
 	GPIO_FN(IRQ40),
 
 	/* Port67 */
 	GPIO_FN(HSI_RX_READY),
-	GPIO_FN(SCIFB1_TXD_67),
 	GPIO_FN(GIO_OUT3_67),
 	GPIO_FN(CHSCIF1_HTX),
 
 	/* Port68 */
 	GPIO_FN(HSI_RX_FLAG),
-	GPIO_FN(SCIFB2_TXD_68),
 	GPIO_FN(MSIOF3_TXD),
 	GPIO_FN(GIO_OUT4_68),
 
 	/* Port69 */
 	GPIO_FN(HSI_RX_DATA),
-	GPIO_FN(SCIFB2_RXD_69),
 	GPIO_FN(MSIOF3_RXD),
 	GPIO_FN(GIO_OUT5_69),
 
 	/* Port70 */
 	GPIO_FN(HSI_TX_FLAG),
-	GPIO_FN(SCIFB1_RTS_70),
 	GPIO_FN(GIO_OUT1_70),
 	GPIO_FN(HSIC_TSTCLK0),
 	GPIO_FN(CHSCIF1_HRTS),
 
 	/* Port71 */
 	GPIO_FN(HSI_TX_DATA),
-	GPIO_FN(SCIFB1_CTS_71),
 	GPIO_FN(GIO_OUT2_71),
 	GPIO_FN(HSIC_TSTCLK1),
 	GPIO_FN(CHSCIF1_HCTS),
 
 	/* Port72 */
 	GPIO_FN(HSI_TX_WAKE),
-	GPIO_FN(SCIFB1_RXD_72),
 	GPIO_FN(GenIO8),
 	GPIO_FN(CHSCIF1_HRX),
 
 	/* Port73 */
 	GPIO_FN(HSI_TX_READY),
-	GPIO_FN(SCIFB2_RTS_73),
 	GPIO_FN(MSIOF3_SCK),
 	GPIO_FN(GIO_OUT0_73),
 
@@ -2398,36 +2368,28 @@ static const struct pinmux_func pinmux_func_gpios[] = {
 	GPIO_FN(IRQ49),
 
 	/* Port116 */
-	GPIO_FN(SCIFA0_TXD),
 	GPIO_FN(CSCIF0_TX),
 
 	/* Port117 */
-	GPIO_FN(SCIFA0_RXD),
 	GPIO_FN(CSCIF0_RX),
 
 	/* Port118 */
-	GPIO_FN(SCIFA1_TXD),
 	GPIO_FN(CSCIF1_TX),
 
 	/* Port119 */
-	GPIO_FN(SCIFA1_RXD),
 	GPIO_FN(CSCIF1_RX),
 
 	/* Port120 */
 	GPIO_FN(SF_PORT_1_120),
-	GPIO_FN(SCIFB3_RXD_120),
 	GPIO_FN(DU0_CDE),
 
 	/* Port121 */
 	GPIO_FN(SF_PORT_0_121),
-	GPIO_FN(SCIFB3_TXD_121),
 
 	/* Port122 */
-	GPIO_FN(SCIFB0_TXD),
 	GPIO_FN(CHSCIF0_HTX),
 
 	/* Port123 */
-	GPIO_FN(SCIFB0_RXD),
 	GPIO_FN(CHSCIF0_HRX),
 
 	/* Port124 */
@@ -2721,11 +2683,9 @@ static const struct pinmux_func pinmux_func_gpios[] = {
 	GPIO_FN(MSIOF0_TXD),
 
 	/* Port261 */
-	GPIO_FN(SCIFB1_SCK_261),
 	GPIO_FN(CHSCIF1_HSCK),
 
 	/* Port262 */
-	GPIO_FN(SCIFB2_SCK_262),
 
 	/* Port263 - Port266 FN1 */
 	GPIO_FN(MSIOF1_SS2),
@@ -2809,7 +2769,6 @@ static const struct pinmux_func pinmux_func_gpios[] = {
 	/* Port295 */
 	GPIO_FN(SDHID2_0),
 	GPIO_FN(MSIOF4_TXD),
-	GPIO_FN(SCIFB2_TXD_295),
 	GPIO_FN(MSIOF6_TXD),
 
 	/* Port296 */
@@ -2830,10 +2789,6 @@ static const struct pinmux_func pinmux_func_gpios[] = {
 	GPIO_FN(MSIOF4_SS1),
 
 	/* Port297 - Port300 FN3 */
-	GPIO_FN(SCIFB2_RXD_297),
-	GPIO_FN(SCIFB2_CTS_298),
-	GPIO_FN(SCIFB2_SCK_299),
-	GPIO_FN(SCIFB2_RTS_300),
 
 	/* Port297 - Port300 FN4 */
 	GPIO_FN(MSIOF6_RXD),
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 22:05:04 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed,  3 Apr 2013 11:05:04 +0900
Subject: [PATCH 26/28] sh-pfc: r8a73a4: Remove function GPIOs
In-Reply-To: <1364954706-14727-1-git-send-email-horms+renesas@verge.net.au>
References: <1364954706-14727-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364954706-14727-27-git-send-email-horms+renesas@verge.net.au>

From: Magnus Damm <damm at opensource.se>

All r8a73a4 platforms use the pinctrl API to control pin functions.
Function GPIOs are no longer needed.

Signed-off-by: Magnus Damm <damm at opensource.se>
Acked-by: Linus Walleij <linus.walleij at linaro.org>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 drivers/pinctrl/sh-pfc/pfc-r8a73a4.c |  737 ----------------------------------
 1 file changed, 737 deletions(-)

diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a73a4.c b/drivers/pinctrl/sh-pfc/pfc-r8a73a4.c
index 66fc747..464c5f9 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a73a4.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a73a4.c
@@ -2042,740 +2042,6 @@ static const struct sh_pfc_function pinmux_functions[] = {
 	SH_PFC_FUNCTION(scifb3),
 };
 
-#define PINMUX_FN_BASE	ARRAY_SIZE(pinmux_pins)
-
-static const struct pinmux_func pinmux_func_gpios[] = {
-	/* Port0 */
-	GPIO_FN(LCDD0),
-	GPIO_FN(PDM2_CLK_0),
-	GPIO_FN(DU0_DR0),
-
-	/* Port1 */
-	GPIO_FN(LCDD1),
-	GPIO_FN(PDM2_DATA_1),
-	GPIO_FN(DU0_DR19),
-
-	/* Port2 */
-	GPIO_FN(LCDD2),
-	GPIO_FN(PDM3_CLK_2),
-	GPIO_FN(DU0_DR2),
-
-	/* Port3 */
-	GPIO_FN(LCDD3),
-	GPIO_FN(PDM3_DATA_3),
-	GPIO_FN(DU0_DR3),
-
-	/* Port4 */
-	GPIO_FN(LCDD4),
-	GPIO_FN(PDM4_CLK_4),
-	GPIO_FN(DU0_DR4),
-
-	/* Port5 */
-	GPIO_FN(LCDD5),
-	GPIO_FN(PDM4_DATA_5),
-	GPIO_FN(DU0_DR5),
-
-	/* Port6 */
-	GPIO_FN(LCDD6),
-	GPIO_FN(PDM0_OUTCLK_6),
-	GPIO_FN(DU0_DR6),
-
-	/* Port7 */
-	GPIO_FN(LCDD7),
-	GPIO_FN(PDM0_OUTDATA_7),
-	GPIO_FN(DU0_DR7),
-
-	/* Port8 */
-	GPIO_FN(LCDD8),
-	GPIO_FN(PDM1_OUTCLK_8),
-	GPIO_FN(DU0_DG0),
-
-	/* Port9 */
-	GPIO_FN(LCDD9),
-	GPIO_FN(PDM1_OUTDATA_9),
-	GPIO_FN(DU0_DG1),
-
-	/* Port10 */
-	GPIO_FN(LCDD10),
-	GPIO_FN(FSICCK),
-	GPIO_FN(DU0_DG2),
-
-	/* Port11 */
-	GPIO_FN(LCDD11),
-	GPIO_FN(FSICISLD),
-	GPIO_FN(DU0_DG3),
-
-	/* Port12 */
-	GPIO_FN(LCDD12),
-	GPIO_FN(FSICOMC),
-	GPIO_FN(DU0_DG4),
-
-	/* Port13 */
-	GPIO_FN(LCDD13),
-	GPIO_FN(FSICOLR),
-	GPIO_FN(FSICILR),
-	GPIO_FN(DU0_DG5),
-
-	/* Port14 */
-	GPIO_FN(LCDD14),
-	GPIO_FN(FSICOBT),
-	GPIO_FN(FSICIBT),
-	GPIO_FN(DU0_DG6),
-
-	/* Port15 */
-	GPIO_FN(LCDD15),
-	GPIO_FN(FSICOSLD),
-	GPIO_FN(DU0_DG7),
-
-	/* Port16 */
-	GPIO_FN(LCDD16),
-	GPIO_FN(TPU1TO1),
-	GPIO_FN(DU0_DB0),
-
-	/* Port17 */
-	GPIO_FN(LCDD17),
-	GPIO_FN(SF_IRQ_00),
-	GPIO_FN(DU0_DB1),
-
-	/* Port18 */
-	GPIO_FN(LCDD18),
-	GPIO_FN(SF_IRQ_01),
-	GPIO_FN(DU0_DB2),
-
-	/* Port19 */
-	GPIO_FN(LCDD19),
-	GPIO_FN(DU0_DB3),
-
-	/* Port20 */
-	GPIO_FN(LCDD20),
-	GPIO_FN(DU0_DB4),
-
-	/* Port21 */
-	GPIO_FN(LCDD21),
-	GPIO_FN(DU0_DB5),
-
-	/* Port22 */
-	GPIO_FN(LCDD22),
-	GPIO_FN(DU0_DB6),
-
-	/* Port23 */
-	GPIO_FN(LCDD23),
-	GPIO_FN(DU0_DB7),
-
-	/* Port24 */
-	GPIO_FN(LCDHSYN),
-	GPIO_FN(LCDCS),
-	GPIO_FN(DU0_EXHSYNC_N_CSYNC_N_HSYNC_N),
-
-	/* Port25 */
-	GPIO_FN(LCDVSYN),
-	GPIO_FN(DU0_EXVSYNC_N_VSYNC_N_CSYNC_N),
-
-	/* Port26 */
-	GPIO_FN(LCDDCK),
-	GPIO_FN(LCDWR),
-	GPIO_FN(DU0_DOTCLKIN),
-
-	/* Port27 */
-	GPIO_FN(LCDDISP),
-	GPIO_FN(LCDRS),
-	GPIO_FN(DU0_DOTCLKOUT),
-
-	/* Port28 */
-	GPIO_FN(LCDRD_N),
-	GPIO_FN(DU0_DOTCLKOUTB),
-
-	/* Port29 */
-	GPIO_FN(LCDLCLK),
-	GPIO_FN(SF_IRQ_02),
-	GPIO_FN(DU0_DISP_CSYNC_N_DE),
-
-	/* Port30 */
-	GPIO_FN(LCDDON),
-	GPIO_FN(SF_IRQ_03),
-	GPIO_FN(DU0_ODDF_N_CLAMP),
-
-	/* Port32 */
-	GPIO_FN(SIM0_DET),
-	GPIO_FN(CSCIF0_RTS),
-
-	/* Port33 */
-	GPIO_FN(SIM1_DET),
-	GPIO_FN(CSCIF0_CTS),
-
-	/* Port34 */
-	GPIO_FN(SIM0_PWRON),
-	GPIO_FN(CSCIF0_SCK),
-
-	/* Port35 */
-	GPIO_FN(CSCIF1_RTS),
-
-	/* Port36 */
-	GPIO_FN(CSCIF1_CTS),
-
-	/* Port37 */
-	GPIO_FN(CSCIF1_SCK),
-
-	/* Port38 */
-	GPIO_FN(TPU0TO1),
-	GPIO_FN(CHSCIF0_HRTS),
-
-	/* Port39 */
-	GPIO_FN(TPU0TO2),
-	GPIO_FN(CHSCIF0_HCTS),
-
-	/* Port40 */
-	GPIO_FN(TPU0TO3),
-	GPIO_FN(CHSCIF0_HSCK),
-
-	/* Port64 */
-	GPIO_FN(PDM0_DATA),
-
-	/* Port65 */
-	GPIO_FN(PDM1_DATA),
-
-	/* Port66 */
-	GPIO_FN(HSI_RX_WAKE),
-	GPIO_FN(MSIOF3_SYNC),
-	GPIO_FN(GenIO4),
-
-	/* Port67 */
-	GPIO_FN(HSI_RX_READY),
-	GPIO_FN(GIO_OUT3_67),
-	GPIO_FN(CHSCIF1_HTX),
-
-	/* Port68 */
-	GPIO_FN(HSI_RX_FLAG),
-	GPIO_FN(MSIOF3_TXD),
-	GPIO_FN(GIO_OUT4_68),
-
-	/* Port69 */
-	GPIO_FN(HSI_RX_DATA),
-	GPIO_FN(MSIOF3_RXD),
-	GPIO_FN(GIO_OUT5_69),
-
-	/* Port70 */
-	GPIO_FN(HSI_TX_FLAG),
-	GPIO_FN(GIO_OUT1_70),
-	GPIO_FN(HSIC_TSTCLK0),
-	GPIO_FN(CHSCIF1_HRTS),
-
-	/* Port71 */
-	GPIO_FN(HSI_TX_DATA),
-	GPIO_FN(GIO_OUT2_71),
-	GPIO_FN(HSIC_TSTCLK1),
-	GPIO_FN(CHSCIF1_HCTS),
-
-	/* Port72 */
-	GPIO_FN(HSI_TX_WAKE),
-	GPIO_FN(GenIO8),
-	GPIO_FN(CHSCIF1_HRX),
-
-	/* Port73 */
-	GPIO_FN(HSI_TX_READY),
-	GPIO_FN(MSIOF3_SCK),
-	GPIO_FN(GIO_OUT0_73),
-
-	/* Port74 - Port85 */
-	GPIO_FN(IRDA_OUT),
-	GPIO_FN(IRDA_IN),
-	GPIO_FN(IRDA_FIRSEL),
-	GPIO_FN(TPU0TO0),
-	GPIO_FN(DIGRFEN),
-	GPIO_FN(GPS_TIMESTAMP),
-	GPIO_FN(TXP),
-	GPIO_FN(TXP2),
-	GPIO_FN(COEX_0),
-	GPIO_FN(COEX_1),
-
-	/* Port96 - Port101 */
-	GPIO_FN(KEYIN0),
-	GPIO_FN(KEYIN1),
-	GPIO_FN(KEYIN2),
-	GPIO_FN(KEYIN3),
-	GPIO_FN(KEYIN4),
-	GPIO_FN(KEYIN5),
-
-	/* Port102 */
-	GPIO_FN(KEYIN6),
-
-	/* Port103 */
-	GPIO_FN(KEYIN7),
-
-	/* Port104 - Port108 */
-	GPIO_FN(KEYOUT0),
-	GPIO_FN(KEYOUT1),
-	GPIO_FN(KEYOUT2),
-	GPIO_FN(KEYOUT3),
-	GPIO_FN(KEYOUT4),
-
-	/* Port109 */
-	GPIO_FN(KEYOUT5),
-
-	/* Port110 */
-	GPIO_FN(KEYOUT6),
-
-	/* Port111 */
-	GPIO_FN(KEYOUT7),
-	GPIO_FN(RFANAEN),
-
-	/* Port112 */
-	GPIO_FN(KEYIN8),
-	GPIO_FN(KEYOUT8),
-	GPIO_FN(SF_IRQ_04),
-
-	/* Port113 */
-	GPIO_FN(KEYIN9),
-	GPIO_FN(KEYOUT9),
-	GPIO_FN(SF_IRQ_05),
-
-	/* Port114 */
-	GPIO_FN(KEYIN10),
-	GPIO_FN(KEYOUT10),
-	GPIO_FN(SF_IRQ_06),
-
-	/* Port115 */
-	GPIO_FN(KEYIN11),
-	GPIO_FN(KEYOUT11),
-	GPIO_FN(SF_IRQ_07),
-
-	/* Port116 */
-	GPIO_FN(CSCIF0_TX),
-
-	/* Port117 */
-	GPIO_FN(CSCIF0_RX),
-
-	/* Port118 */
-	GPIO_FN(CSCIF1_TX),
-
-	/* Port119 */
-	GPIO_FN(CSCIF1_RX),
-
-	/* Port120 */
-	GPIO_FN(SF_PORT_1_120),
-	GPIO_FN(DU0_CDE),
-
-	/* Port121 */
-	GPIO_FN(SF_PORT_0_121),
-
-	/* Port122 */
-	GPIO_FN(CHSCIF0_HTX),
-
-	/* Port123 */
-	GPIO_FN(CHSCIF0_HRX),
-
-	/* Port124 */
-	GPIO_FN(ISP_STROBE_124),
-
-	/* Port125 */
-	GPIO_FN(STP_ISD_0),
-	GPIO_FN(PDM4_CLK_125),
-	GPIO_FN(MSIOF2_TXD),
-	GPIO_FN(SIM0_VOLTSEL0),
-
-	/* Port126 */
-	GPIO_FN(TS_SDEN),
-	GPIO_FN(MSIOF7_SYNC),
-	GPIO_FN(STP_ISEN_1),
-
-	/* Port128 */
-	GPIO_FN(STP_ISEN_0),
-	GPIO_FN(PDM1_OUTDATA_128),
-	GPIO_FN(MSIOF2_SYNC),
-	GPIO_FN(SIM1_VOLTSEL1),
-
-	/* Port129 */
-	GPIO_FN(TS_SPSYNC),
-	GPIO_FN(MSIOF7_RXD),
-	GPIO_FN(STP_ISSYNC_1),
-
-	/* Port130 */
-	GPIO_FN(STP_ISSYNC_0),
-	GPIO_FN(PDM4_DATA_130),
-	GPIO_FN(MSIOF2_RXD),
-	GPIO_FN(SIM0_VOLTSEL1),
-
-	/* Port131 */
-	GPIO_FN(STP_OPWM_0),
-	GPIO_FN(SIM1_PWRON),
-
-	/* Port132 */
-	GPIO_FN(TS_SCK),
-	GPIO_FN(MSIOF7_SCK),
-	GPIO_FN(STP_ISCLK_1),
-
-	/* Port133 */
-	GPIO_FN(STP_ISCLK_0),
-	GPIO_FN(PDM1_OUTCLK_133),
-	GPIO_FN(MSIOF2_SCK),
-	GPIO_FN(SIM1_VOLTSEL0),
-
-	/* Port134 */
-	GPIO_FN(TS_SDAT),
-	GPIO_FN(MSIOF7_TXD),
-	GPIO_FN(STP_ISD_1),
-
-	/* Port160 - Port178 */
-	GPIO_FN(MMCD0_0),
-	GPIO_FN(MMCD0_1),
-	GPIO_FN(MMCD0_2),
-	GPIO_FN(MMCD0_3),
-	GPIO_FN(MMCD0_4),
-	GPIO_FN(MMCD0_5),
-	GPIO_FN(MMCD0_6),
-	GPIO_FN(MMCD0_7),
-	GPIO_FN(MMCCMD0),
-	GPIO_FN(MMCCLK0),
-	GPIO_FN(MMCRST),
-
-	/* Port192 - Port200 FN1 */
-	GPIO_FN(A10),
-	GPIO_FN(A9),
-	GPIO_FN(A8),
-	GPIO_FN(A7),
-	GPIO_FN(A6),
-	GPIO_FN(A5),
-	GPIO_FN(A4),
-	GPIO_FN(A3),
-	GPIO_FN(A2),
-
-	/* Port192 - Port200 FN2 */
-	GPIO_FN(MMCD1_7),
-	GPIO_FN(MMCD1_6),
-	GPIO_FN(MMCD1_5),
-	GPIO_FN(MMCD1_4),
-	GPIO_FN(MMCD1_3),
-	GPIO_FN(MMCD1_2),
-	GPIO_FN(MMCD1_1),
-	GPIO_FN(MMCD1_0),
-	GPIO_FN(MMCCMD1),
-
-	/* Port192 - Port200 IRQ */
-
-	/* Port201 */
-	GPIO_FN(A1),
-
-	/* Port202 */
-	GPIO_FN(A0),
-	GPIO_FN(BS),
-
-	/* Port203 */
-	GPIO_FN(CKO),
-	GPIO_FN(MMCCLK1),
-
-	/* Port204 */
-	GPIO_FN(CS0_N),
-	GPIO_FN(SIM0_GPO1),
-
-	/* Port205 */
-	GPIO_FN(CS2_N),
-	GPIO_FN(SIM0_GPO2),
-
-	/* Port206 */
-	GPIO_FN(CS4_N),
-	GPIO_FN(VIO_VD),
-	GPIO_FN(SIM1_GPO0),
-
-	/* Port207 - Port212 FN1 */
-	GPIO_FN(D15),
-	GPIO_FN(D14),
-	GPIO_FN(D13),
-	GPIO_FN(D12),
-	GPIO_FN(D11),
-	GPIO_FN(D10),
-
-	/* Port207 - Port212 FN5 */
-	GPIO_FN(GIO_OUT15),
-	GPIO_FN(GIO_OUT14),
-	GPIO_FN(GIO_OUT13),
-	GPIO_FN(GIO_OUT12),
-	GPIO_FN(WGM_TXP2),
-	GPIO_FN(WGM_GPS_TIMEM_ASK_RFCLK),
-
-	/* Port213 - Port222 FN1 */
-	GPIO_FN(D9),
-	GPIO_FN(D8),
-	GPIO_FN(D7),
-	GPIO_FN(D6),
-	GPIO_FN(D5),
-	GPIO_FN(D4),
-	GPIO_FN(D3),
-	GPIO_FN(D2),
-	GPIO_FN(D1),
-	GPIO_FN(D0),
-
-	/* Port213 - Port222 FN2 */
-	GPIO_FN(VIO_D9),
-	GPIO_FN(VIO_D8),
-	GPIO_FN(VIO_D7),
-	GPIO_FN(VIO_D6),
-	GPIO_FN(VIO_D5),
-	GPIO_FN(VIO_D4),
-	GPIO_FN(VIO_D3),
-	GPIO_FN(VIO_D2),
-	GPIO_FN(VIO_D1),
-	GPIO_FN(VIO_D0),
-
-	/* Port213 - Port222 FN5 */
-	GPIO_FN(GIO_OUT9),
-	GPIO_FN(GIO_OUT8),
-	GPIO_FN(GIO_OUT7),
-	GPIO_FN(GIO_OUT6),
-	GPIO_FN(GIO_OUT5_217),
-	GPIO_FN(GIO_OUT4_218),
-	GPIO_FN(GIO_OUT3_219),
-	GPIO_FN(GIO_OUT2_220),
-	GPIO_FN(GIO_OUT1_221),
-	GPIO_FN(GIO_OUT0_222),
-
-	/* Port224 */
-	GPIO_FN(RDWR_224),
-	GPIO_FN(VIO_HD),
-	GPIO_FN(SIM1_GPO2),
-
-	/* Port225 */
-	GPIO_FN(RD_N),
-
-	/* Port226 */
-	GPIO_FN(WAIT_N),
-	GPIO_FN(VIO_CLK),
-	GPIO_FN(SIM1_GPO1),
-
-	/* Port227 */
-	GPIO_FN(WE0_N),
-	GPIO_FN(RDWR_227),
-
-	/* Port228 */
-	GPIO_FN(WE1_N),
-	GPIO_FN(SIM0_GPO0),
-
-	/* Port229 */
-	GPIO_FN(PWMO),
-	GPIO_FN(VIO_CKO1_229),
-
-	/* Port230 */
-	GPIO_FN(SLIM_CLK),
-	GPIO_FN(VIO_CKO4_230),
-
-	/* Port231 */
-	GPIO_FN(SLIM_DATA),
-	GPIO_FN(VIO_CKO5_231),
-
-	/* Port232 */
-	GPIO_FN(VIO_CKO2_232),
-	GPIO_FN(SF_PORT_0_232),
-
-	/* Port233 */
-	GPIO_FN(VIO_CKO3_233),
-	GPIO_FN(SF_PORT_1_233),
-
-	/* Port234 */
-	GPIO_FN(FSIACK),
-	GPIO_FN(PDM3_CLK_234),
-	GPIO_FN(ISP_IRIS1_234),
-
-	/* Port235 */
-	GPIO_FN(FSIAISLD),
-	GPIO_FN(PDM3_DATA_235),
-
-	/* Port236 */
-	GPIO_FN(FSIAOMC),
-	GPIO_FN(PDM0_OUTCLK_236),
-	GPIO_FN(ISP_IRIS0_236),
-
-	/* Port237 */
-	GPIO_FN(FSIAOLR),
-	GPIO_FN(FSIAILR),
-
-	/* Port238 */
-	GPIO_FN(FSIAOBT),
-	GPIO_FN(FSIAIBT),
-
-	/* Port239 */
-	GPIO_FN(FSIAOSLD),
-	GPIO_FN(PDM0_OUTDATA_239),
-
-	/* Port240 */
-	GPIO_FN(FSIBISLD),
-
-	/* Port241 */
-	GPIO_FN(FSIBOLR),
-	GPIO_FN(FSIBILR),
-
-	/* Port242 */
-	GPIO_FN(FSIBOMC),
-	GPIO_FN(ISP_SHUTTER1_242),
-
-	/* Port243 */
-	GPIO_FN(FSIBOBT),
-	GPIO_FN(FSIBIBT),
-
-	/* Port244 */
-	GPIO_FN(FSIBOSLD),
-	GPIO_FN(FSIASPDIF),
-
-	/* Port245 */
-	GPIO_FN(FSIBCK),
-	GPIO_FN(ISP_SHUTTER0_245),
-
-	/* Port246 - Port250 FN1 */
-	GPIO_FN(ISP_IRIS1_246),
-	GPIO_FN(ISP_IRIS0_247),
-	GPIO_FN(ISP_SHUTTER1_248),
-	GPIO_FN(ISP_SHUTTER0_249),
-	GPIO_FN(ISP_STROBE_250),
-
-	/* Port256 - Port258 */
-	GPIO_FN(MSIOF0_SYNC),
-	GPIO_FN(MSIOF0_RXD),
-	GPIO_FN(MSIOF0_SCK),
-
-	/* Port259 */
-	GPIO_FN(MSIOF0_SS2),
-	GPIO_FN(VIO_CKO3_259),
-
-	/* Port260 */
-	GPIO_FN(MSIOF0_TXD),
-
-	/* Port261 */
-	GPIO_FN(CHSCIF1_HSCK),
-
-	/* Port262 */
-
-	/* Port263 - Port266 FN1 */
-	GPIO_FN(MSIOF1_SS2),
-	GPIO_FN(MSIOF1_TXD),
-	GPIO_FN(MSIOF1_RXD),
-	GPIO_FN(MSIOF1_SS1),
-
-	/* Port263 - Port266 FN4 */
-	GPIO_FN(MSIOF5_SS2),
-	GPIO_FN(MSIOF5_TXD),
-	GPIO_FN(MSIOF5_RXD),
-	GPIO_FN(MSIOF5_SS1),
-
-	/* Port267 */
-	GPIO_FN(MSIOF0_SS1),
-
-	/* Port268 */
-	GPIO_FN(MSIOF1_SCK),
-	GPIO_FN(MSIOF5_SCK),
-
-	/* Port269 */
-	GPIO_FN(MSIOF1_SYNC),
-	GPIO_FN(MSIOF5_SYNC),
-
-	/* Port270 - Port273 FN1 */
-	GPIO_FN(MSIOF2_SS1),
-	GPIO_FN(MSIOF2_SS2),
-	GPIO_FN(MSIOF3_SS2),
-	GPIO_FN(MSIOF3_SS1),
-
-	/* Port270 - Port273 FN3 */
-	GPIO_FN(VIO_CKO5_270),
-	GPIO_FN(VIO_CKO2_271),
-	GPIO_FN(VIO_CKO1_272),
-	GPIO_FN(VIO_CKO4_273),
-
-	/* Port274 */
-	GPIO_FN(MSIOF4_SS2),
-	GPIO_FN(TPU1TO0),
-
-	/* Port275 - Port280 */
-	GPIO_FN(IC_DP),
-	GPIO_FN(SIM0_RST),
-	GPIO_FN(IC_DM),
-	GPIO_FN(SIM0_BSICOMP),
-	GPIO_FN(SIM0_CLK),
-	GPIO_FN(SIM0_IO),
-
-	/* Port281 */
-	GPIO_FN(SIM1_IO),
-	GPIO_FN(PDM2_DATA_281),
-
-	/* Port282 */
-	GPIO_FN(SIM1_CLK),
-	GPIO_FN(PDM2_CLK_282),
-
-	/* Port283 */
-	GPIO_FN(SIM1_RST),
-
-	/* Port289 */
-	GPIO_FN(SDHID1_0),
-	GPIO_FN(STMDATA0_2),
-
-	/* Port290 */
-	GPIO_FN(SDHID1_1),
-	GPIO_FN(STMDATA1_2),
-
-	/* Port291 - Port294 FN1 */
-	GPIO_FN(SDHID1_2),
-	GPIO_FN(SDHID1_3),
-	GPIO_FN(SDHICLK1),
-	GPIO_FN(SDHICMD1),
-
-	/* Port291 - Port294 FN3 */
-	GPIO_FN(STMDATA2_2),
-	GPIO_FN(STMDATA3_2),
-	GPIO_FN(STMCLK_2),
-	GPIO_FN(STMSIDI_2),
-
-	/* Port295 */
-	GPIO_FN(SDHID2_0),
-	GPIO_FN(MSIOF4_TXD),
-	GPIO_FN(MSIOF6_TXD),
-
-	/* Port296 */
-	GPIO_FN(SDHID2_1),
-	GPIO_FN(MSIOF6_SS2),
-
-	/* Port297 - Port300 FN1 */
-	GPIO_FN(SDHID2_2),
-	GPIO_FN(SDHID2_3),
-	GPIO_FN(SDHICLK2),
-	GPIO_FN(SDHICMD2),
-
-	/* Port297 - Port300 FN2 */
-	GPIO_FN(MSIOF4_RXD),
-	GPIO_FN(MSIOF4_SYNC),
-	GPIO_FN(MSIOF4_SCK),
-	GPIO_FN(MSIOF4_SS1),
-
-	/* Port297 - Port300 FN3 */
-
-	/* Port297 - Port300 FN4 */
-	GPIO_FN(MSIOF6_RXD),
-	GPIO_FN(MSIOF6_SYNC),
-	GPIO_FN(MSIOF6_SCK),
-	GPIO_FN(MSIOF6_SS1),
-
-	/* Port301 */
-	GPIO_FN(SDHICD0),
-
-	/* Port302 - Port306 FN1 */
-	GPIO_FN(SDHID0_0),
-	GPIO_FN(SDHID0_1),
-	GPIO_FN(SDHID0_2),
-	GPIO_FN(SDHID0_3),
-	GPIO_FN(SDHICMD0),
-
-	/* Port302 - Port306 FN3 */
-	GPIO_FN(STMDATA0_1),
-	GPIO_FN(STMDATA1_1),
-	GPIO_FN(STMDATA2_1),
-	GPIO_FN(STMDATA3_1),
-	GPIO_FN(STMSIDI_1),
-
-	/* Port307 */
-	GPIO_FN(SDHIWP0),
-
-	/* Port308 */
-	GPIO_FN(SDHICLK0),
-	GPIO_FN(STMCLK_1),
-
-	/* Port320 - Port329 */
-};
-
 static const struct pinmux_cfg_reg pinmux_config_regs[] = {
 
 	PORTCR(0, 0xe6050000),
@@ -3456,9 +2722,6 @@ const struct sh_pfc_soc_info r8a73a4_pinmux_info = {
 	.functions = pinmux_functions,
 	.nr_functions = ARRAY_SIZE(pinmux_functions),
 
-	.func_gpios = pinmux_func_gpios,
-	.nr_func_gpios = ARRAY_SIZE(pinmux_func_gpios),
-
 	.cfg_regs	= pinmux_config_regs,
 	.data_regs	= pinmux_data_regs,
 
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 22:05:01 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed,  3 Apr 2013 11:05:01 +0900
Subject: [PATCH 23/28] sh-pfc: r8a73a4: Remove IRQC function GPIOS
In-Reply-To: <1364954706-14727-1-git-send-email-horms+renesas@verge.net.au>
References: <1364954706-14727-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364954706-14727-24-git-send-email-horms+renesas@verge.net.au>

From: Magnus Damm <damm at opensource.se>

The r8a73a4 board support will use the pinctrl API to control the
external IRQ pins so remove the unused function GPIOS.

Signed-off-by: Magnus Damm <damm at opensource.se>
Acked-by: Linus Walleij <linus.walleij at linaro.org>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 drivers/pinctrl/sh-pfc/pfc-r8a73a4.c |   58 ----------------------------------
 1 file changed, 58 deletions(-)

diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a73a4.c b/drivers/pinctrl/sh-pfc/pfc-r8a73a4.c
index 470b18f..66fc747 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a73a4.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a73a4.c
@@ -2049,99 +2049,83 @@ static const struct pinmux_func pinmux_func_gpios[] = {
 	GPIO_FN(LCDD0),
 	GPIO_FN(PDM2_CLK_0),
 	GPIO_FN(DU0_DR0),
-	GPIO_FN(IRQ0),
 
 	/* Port1 */
 	GPIO_FN(LCDD1),
 	GPIO_FN(PDM2_DATA_1),
 	GPIO_FN(DU0_DR19),
-	GPIO_FN(IRQ1),
 
 	/* Port2 */
 	GPIO_FN(LCDD2),
 	GPIO_FN(PDM3_CLK_2),
 	GPIO_FN(DU0_DR2),
-	GPIO_FN(IRQ2),
 
 	/* Port3 */
 	GPIO_FN(LCDD3),
 	GPIO_FN(PDM3_DATA_3),
 	GPIO_FN(DU0_DR3),
-	GPIO_FN(IRQ3),
 
 	/* Port4 */
 	GPIO_FN(LCDD4),
 	GPIO_FN(PDM4_CLK_4),
 	GPIO_FN(DU0_DR4),
-	GPIO_FN(IRQ4),
 
 	/* Port5 */
 	GPIO_FN(LCDD5),
 	GPIO_FN(PDM4_DATA_5),
 	GPIO_FN(DU0_DR5),
-	GPIO_FN(IRQ5),
 
 	/* Port6 */
 	GPIO_FN(LCDD6),
 	GPIO_FN(PDM0_OUTCLK_6),
 	GPIO_FN(DU0_DR6),
-	GPIO_FN(IRQ6),
 
 	/* Port7 */
 	GPIO_FN(LCDD7),
 	GPIO_FN(PDM0_OUTDATA_7),
 	GPIO_FN(DU0_DR7),
-	GPIO_FN(IRQ7),
 
 	/* Port8 */
 	GPIO_FN(LCDD8),
 	GPIO_FN(PDM1_OUTCLK_8),
 	GPIO_FN(DU0_DG0),
-	GPIO_FN(IRQ8),
 
 	/* Port9 */
 	GPIO_FN(LCDD9),
 	GPIO_FN(PDM1_OUTDATA_9),
 	GPIO_FN(DU0_DG1),
-	GPIO_FN(IRQ9),
 
 	/* Port10 */
 	GPIO_FN(LCDD10),
 	GPIO_FN(FSICCK),
 	GPIO_FN(DU0_DG2),
-	GPIO_FN(IRQ10),
 
 	/* Port11 */
 	GPIO_FN(LCDD11),
 	GPIO_FN(FSICISLD),
 	GPIO_FN(DU0_DG3),
-	GPIO_FN(IRQ11),
 
 	/* Port12 */
 	GPIO_FN(LCDD12),
 	GPIO_FN(FSICOMC),
 	GPIO_FN(DU0_DG4),
-	GPIO_FN(IRQ12),
 
 	/* Port13 */
 	GPIO_FN(LCDD13),
 	GPIO_FN(FSICOLR),
 	GPIO_FN(FSICILR),
 	GPIO_FN(DU0_DG5),
-	GPIO_FN(IRQ13),
 
 	/* Port14 */
 	GPIO_FN(LCDD14),
 	GPIO_FN(FSICOBT),
 	GPIO_FN(FSICIBT),
 	GPIO_FN(DU0_DG6),
-	GPIO_FN(IRQ14),
 
 	/* Port15 */
 	GPIO_FN(LCDD15),
 	GPIO_FN(FSICOSLD),
 	GPIO_FN(DU0_DG7),
-	GPIO_FN(IRQ15),
 
 	/* Port16 */
 	GPIO_FN(LCDD16),
@@ -2254,7 +2238,6 @@ static const struct pinmux_func pinmux_func_gpios[] = {
 	GPIO_FN(HSI_RX_WAKE),
 	GPIO_FN(MSIOF3_SYNC),
 	GPIO_FN(GenIO4),
-	GPIO_FN(IRQ40),
 
 	/* Port67 */
 	GPIO_FN(HSI_RX_READY),
@@ -2304,8 +2287,6 @@ static const struct pinmux_func pinmux_func_gpios[] = {
 	GPIO_FN(TXP2),
 	GPIO_FN(COEX_0),
 	GPIO_FN(COEX_1),
-	GPIO_FN(IRQ19),
-	GPIO_FN(IRQ18),
 
 	/* Port96 - Port101 */
 	GPIO_FN(KEYIN0),
@@ -2317,11 +2298,9 @@ static const struct pinmux_func pinmux_func_gpios[] = {
 
 	/* Port102 */
 	GPIO_FN(KEYIN6),
-	GPIO_FN(IRQ41),
 
 	/* Port103 */
 	GPIO_FN(KEYIN7),
-	GPIO_FN(IRQ42),
 
 	/* Port104 - Port108 */
 	GPIO_FN(KEYOUT0),
@@ -2332,40 +2311,33 @@ static const struct pinmux_func pinmux_func_gpios[] = {
 
 	/* Port109 */
 	GPIO_FN(KEYOUT5),
-	GPIO_FN(IRQ43),
 
 	/* Port110 */
 	GPIO_FN(KEYOUT6),
-	GPIO_FN(IRQ44),
 
 	/* Port111 */
 	GPIO_FN(KEYOUT7),
 	GPIO_FN(RFANAEN),
-	GPIO_FN(IRQ45),
 
 	/* Port112 */
 	GPIO_FN(KEYIN8),
 	GPIO_FN(KEYOUT8),
 	GPIO_FN(SF_IRQ_04),
-	GPIO_FN(IRQ46),
 
 	/* Port113 */
 	GPIO_FN(KEYIN9),
 	GPIO_FN(KEYOUT9),
 	GPIO_FN(SF_IRQ_05),
-	GPIO_FN(IRQ47),
 
 	/* Port114 */
 	GPIO_FN(KEYIN10),
 	GPIO_FN(KEYOUT10),
 	GPIO_FN(SF_IRQ_06),
-	GPIO_FN(IRQ48),
 
 	/* Port115 */
 	GPIO_FN(KEYIN11),
 	GPIO_FN(KEYOUT11),
 	GPIO_FN(SF_IRQ_07),
-	GPIO_FN(IRQ49),
 
 	/* Port116 */
 	GPIO_FN(CSCIF0_TX),
@@ -2444,10 +2416,6 @@ static const struct pinmux_func pinmux_func_gpios[] = {
 	GPIO_FN(STP_ISD_1),
 
 	/* Port160 - Port178 */
-	GPIO_FN(IRQ20),
-	GPIO_FN(IRQ21),
-	GPIO_FN(IRQ22),
-	GPIO_FN(IRQ23),
 	GPIO_FN(MMCD0_0),
 	GPIO_FN(MMCD0_1),
 	GPIO_FN(MMCD0_2),
@@ -2459,10 +2427,6 @@ static const struct pinmux_func pinmux_func_gpios[] = {
 	GPIO_FN(MMCCMD0),
 	GPIO_FN(MMCCLK0),
 	GPIO_FN(MMCRST),
-	GPIO_FN(IRQ24),
-	GPIO_FN(IRQ25),
-	GPIO_FN(IRQ26),
-	GPIO_FN(IRQ27),
 
 	/* Port192 - Port200 FN1 */
 	GPIO_FN(A10),
@@ -2487,15 +2451,6 @@ static const struct pinmux_func pinmux_func_gpios[] = {
 	GPIO_FN(MMCCMD1),
 
 	/* Port192 - Port200 IRQ */
-	GPIO_FN(IRQ31),
-	GPIO_FN(IRQ32),
-	GPIO_FN(IRQ33),
-	GPIO_FN(IRQ34),
-	GPIO_FN(IRQ35),
-	GPIO_FN(IRQ36),
-	GPIO_FN(IRQ37),
-	GPIO_FN(IRQ38),
-	GPIO_FN(IRQ39),
 
 	/* Port201 */
 	GPIO_FN(A1),
@@ -2752,7 +2707,6 @@ static const struct pinmux_func pinmux_func_gpios[] = {
 	/* Port290 */
 	GPIO_FN(SDHID1_1),
 	GPIO_FN(STMDATA1_2),
-	GPIO_FN(IRQ51),
 
 	/* Port291 - Port294 FN1 */
 	GPIO_FN(SDHID1_2),
@@ -2774,7 +2728,6 @@ static const struct pinmux_func pinmux_func_gpios[] = {
 	/* Port296 */
 	GPIO_FN(SDHID2_1),
 	GPIO_FN(MSIOF6_SS2),
-	GPIO_FN(IRQ52),
 
 	/* Port297 - Port300 FN1 */
 	GPIO_FN(SDHID2_2),
@@ -2798,7 +2751,6 @@ static const struct pinmux_func pinmux_func_gpios[] = {
 
 	/* Port301 */
 	GPIO_FN(SDHICD0),
-	GPIO_FN(IRQ50),
 
 	/* Port302 - Port306 FN1 */
 	GPIO_FN(SDHID0_0),
@@ -2822,16 +2774,6 @@ static const struct pinmux_func pinmux_func_gpios[] = {
 	GPIO_FN(STMCLK_1),
 
 	/* Port320 - Port329 */
-	GPIO_FN(IRQ16),
-	GPIO_FN(IRQ17),
-	GPIO_FN(IRQ28),
-	GPIO_FN(IRQ29),
-	GPIO_FN(IRQ30),
-	GPIO_FN(IRQ53),
-	GPIO_FN(IRQ54),
-	GPIO_FN(IRQ55),
-	GPIO_FN(IRQ56),
-	GPIO_FN(IRQ57),
 };
 
 static const struct pinmux_cfg_reg pinmux_config_regs[] = {
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 22:05:03 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed,  3 Apr 2013 11:05:03 +0900
Subject: [PATCH 25/28] ARM: shmobile: r8a73a4: Remove IRQC function GPIOs
In-Reply-To: <1364954706-14727-1-git-send-email-horms+renesas@verge.net.au>
References: <1364954706-14727-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364954706-14727-26-git-send-email-horms+renesas@verge.net.au>

From: Magnus Damm <damm at opensource.se>

Remove IRQ pin function GPIOs that have been deprecated by the pinctrl
API.

Signed-off-by: Magnus Damm <damm at opensource.se>
Acked-by: Linus Walleij <linus.walleij at linaro.org>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/include/mach/r8a73a4.h |   58 -------------------------
 1 file changed, 58 deletions(-)

diff --git a/arch/arm/mach-shmobile/include/mach/r8a73a4.h b/arch/arm/mach-shmobile/include/mach/r8a73a4.h
index 703387a..9162e86 100644
--- a/arch/arm/mach-shmobile/include/mach/r8a73a4.h
+++ b/arch/arm/mach-shmobile/include/mach/r8a73a4.h
@@ -89,99 +89,83 @@ enum {
 	GPIO_FN_LCDD0 = 330,
 	GPIO_FN_PDM2_CLK_0,
 	GPIO_FN_DU0_DR0,
-	GPIO_FN_IRQ0,
 
 	/* Port1 */
 	GPIO_FN_LCDD1,
 	GPIO_FN_PDM2_DATA_1,
 	GPIO_FN_DU0_DR19,
-	GPIO_FN_IRQ1,
 
 	/* Port2 */
 	GPIO_FN_LCDD2,
 	GPIO_FN_PDM3_CLK_2,
 	GPIO_FN_DU0_DR2,
-	GPIO_FN_IRQ2,
 
 	/* Port3 */
 	GPIO_FN_LCDD3,
 	GPIO_FN_PDM3_DATA_3,
 	GPIO_FN_DU0_DR3,
-	GPIO_FN_IRQ3,
 
 	/* Port4 */
 	GPIO_FN_LCDD4,
 	GPIO_FN_PDM4_CLK_4,
 	GPIO_FN_DU0_DR4,
-	GPIO_FN_IRQ4,
 
 	/* Port5 */
 	GPIO_FN_LCDD5,
 	GPIO_FN_PDM4_DATA_5,
 	GPIO_FN_DU0_DR5,
-	GPIO_FN_IRQ5,
 
 	/* Port6 */
 	GPIO_FN_LCDD6,
 	GPIO_FN_PDM0_OUTCLK_6,
 	GPIO_FN_DU0_DR6,
-	GPIO_FN_IRQ6,
 
 	/* Port7 */
 	GPIO_FN_LCDD7,
 	GPIO_FN_PDM0_OUTDATA_7,
 	GPIO_FN_DU0_DR7,
-	GPIO_FN_IRQ7,
 
 	/* Port8 */
 	GPIO_FN_LCDD8,
 	GPIO_FN_PDM1_OUTCLK_8,
 	GPIO_FN_DU0_DG0,
-	GPIO_FN_IRQ8,
 
 	/* Port9 */
 	GPIO_FN_LCDD9,
 	GPIO_FN_PDM1_OUTDATA_9,
 	GPIO_FN_DU0_DG1,
-	GPIO_FN_IRQ9,
 
 	/* Port10 */
 	GPIO_FN_LCDD10,
 	GPIO_FN_FSICCK,
 	GPIO_FN_DU0_DG2,
-	GPIO_FN_IRQ10,
 
 	/* Port11 */
 	GPIO_FN_LCDD11,
 	GPIO_FN_FSICISLD,
 	GPIO_FN_DU0_DG3,
-	GPIO_FN_IRQ11,
 
 	/* Port12 */
 	GPIO_FN_LCDD12,
 	GPIO_FN_FSICOMC,
 	GPIO_FN_DU0_DG4,
-	GPIO_FN_IRQ12,
 
 	/* Port13 */
 	GPIO_FN_LCDD13,
 	GPIO_FN_FSICOLR,
 	GPIO_FN_FSICILR,
 	GPIO_FN_DU0_DG5,
-	GPIO_FN_IRQ13,
 
 	/* Port14 */
 	GPIO_FN_LCDD14,
 	GPIO_FN_FSICOBT,
 	GPIO_FN_FSICIBT,
 	GPIO_FN_DU0_DG6,
-	GPIO_FN_IRQ14,
 
 	/* Port15 */
 	GPIO_FN_LCDD15,
 	GPIO_FN_FSICOSLD,
 	GPIO_FN_DU0_DG7,
-	GPIO_FN_IRQ15,
 
 	/* Port16 */
 	GPIO_FN_LCDD16,
@@ -294,7 +278,6 @@ enum {
 	GPIO_FN_HSI_RX_WAKE,
 	GPIO_FN_MSIOF3_SYNC,
 	GPIO_FN_GenIO4,
-	GPIO_FN_IRQ40,
 
 	/* Port67 */
 	GPIO_FN_HSI_RX_READY,
@@ -344,8 +327,6 @@ enum {
 	GPIO_FN_TXP2,
 	GPIO_FN_COEX_0,
 	GPIO_FN_COEX_1,
-	GPIO_FN_IRQ19,
-	GPIO_FN_IRQ18,
 
 	/* Port96 - Port101 */
 	GPIO_FN_KEYIN0,
@@ -357,11 +338,9 @@ enum {
 
 	/* Port102 */
 	GPIO_FN_KEYIN6,
-	GPIO_FN_IRQ41,
 
 	/* Port103 */
 	GPIO_FN_KEYIN7,
-	GPIO_FN_IRQ42,
 
 	/* Port104 - Port108 */
 	GPIO_FN_KEYOUT0,
@@ -372,40 +351,33 @@ enum {
 
 	/* Port109 */
 	GPIO_FN_KEYOUT5,
-	GPIO_FN_IRQ43,
 
 	/* Port110 */
 	GPIO_FN_KEYOUT6,
-	GPIO_FN_IRQ44,
 
 	/* Port111 */
 	GPIO_FN_KEYOUT7,
 	GPIO_FN_RFANAEN,
-	GPIO_FN_IRQ45,
 
 	/* Port112 */
 	GPIO_FN_KEYIN8,
 	GPIO_FN_KEYOUT8,
 	GPIO_FN_SF_IRQ_04,
-	GPIO_FN_IRQ46,
 
 	/* Port113 */
 	GPIO_FN_KEYIN9,
 	GPIO_FN_KEYOUT9,
 	GPIO_FN_SF_IRQ_05,
-	GPIO_FN_IRQ47,
 
 	/* Port114 */
 	GPIO_FN_KEYIN10,
 	GPIO_FN_KEYOUT10,
 	GPIO_FN_SF_IRQ_06,
-	GPIO_FN_IRQ48,
 
 	/* Port115 */
 	GPIO_FN_KEYIN11,
 	GPIO_FN_KEYOUT11,
 	GPIO_FN_SF_IRQ_07,
-	GPIO_FN_IRQ49,
 
 	/* Port116 */
 	GPIO_FN_CSCIF0_TX,
@@ -484,10 +456,6 @@ enum {
 	GPIO_FN_STP_ISD_1,
 
 	/* Port160 - Port178 */
-	GPIO_FN_IRQ20,
-	GPIO_FN_IRQ21,
-	GPIO_FN_IRQ22,
-	GPIO_FN_IRQ23,
 	GPIO_FN_MMCD0_0,
 	GPIO_FN_MMCD0_1,
 	GPIO_FN_MMCD0_2,
@@ -499,10 +467,6 @@ enum {
 	GPIO_FN_MMCCMD0,
 	GPIO_FN_MMCCLK0,
 	GPIO_FN_MMCRST,
-	GPIO_FN_IRQ24,
-	GPIO_FN_IRQ25,
-	GPIO_FN_IRQ26,
-	GPIO_FN_IRQ27,
 
 	/* Port192 - Port200 FN1 */
 	GPIO_FN_A10,
@@ -527,15 +491,6 @@ enum {
 	GPIO_FN_MMCCMD1,
 
 	/* Port192 - Port200 IRQ */
-	GPIO_FN_IRQ31,
-	GPIO_FN_IRQ32,
-	GPIO_FN_IRQ33,
-	GPIO_FN_IRQ34,
-	GPIO_FN_IRQ35,
-	GPIO_FN_IRQ36,
-	GPIO_FN_IRQ37,
-	GPIO_FN_IRQ38,
-	GPIO_FN_IRQ39,
 
 	/* Port201 */
 	GPIO_FN_A1,
@@ -792,7 +747,6 @@ enum {
 	/* Port290 */
 	GPIO_FN_SDHID1_1,
 	GPIO_FN_STMDATA1_2,
-	GPIO_FN_IRQ51,
 
 	/* Port291 - Port294 FN1 */
 	GPIO_FN_SDHID1_2,
@@ -814,7 +768,6 @@ enum {
 	/* Port296 */
 	GPIO_FN_SDHID2_1,
 	GPIO_FN_MSIOF6_SS2,
-	GPIO_FN_IRQ52,
 
 	/* Port297 - Port300 FN1 */
 	GPIO_FN_SDHID2_2,
@@ -838,7 +791,6 @@ enum {
 
 	/* Port301 */
 	GPIO_FN_SDHICD0,
-	GPIO_FN_IRQ50,
 
 	/* Port302 - Port306 FN1 */
 	GPIO_FN_SDHID0_0,
@@ -862,16 +814,6 @@ enum {
 	GPIO_FN_STMCLK_1,
 
 	/* Port320 - Port329 */
-	GPIO_FN_IRQ16,
-	GPIO_FN_IRQ17,
-	GPIO_FN_IRQ28,
-	GPIO_FN_IRQ29,
-	GPIO_FN_IRQ30,
-	GPIO_FN_IRQ53,
-	GPIO_FN_IRQ54,
-	GPIO_FN_IRQ55,
-	GPIO_FN_IRQ56,
-	GPIO_FN_IRQ57,
 };
 
 void r8a73a4_add_standard_devices(void);
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 22:05:06 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed,  3 Apr 2013 11:05:06 +0900
Subject: [PATCH 28/28] sh-pfc: r8a73a4: Remove unused GPIO bias data
In-Reply-To: <1364954706-14727-1-git-send-email-horms+renesas@verge.net.au>
References: <1364954706-14727-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364954706-14727-29-git-send-email-horms+renesas@verge.net.au>

From: Magnus Damm <damm at opensource.se>

Remove unused pull-up/down data from the r8a73a4 PFC code.

Signed-off-by: Magnus Damm <damm at opensource.se>
Acked-by: Linus Walleij <linus.walleij at linaro.org>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 drivers/pinctrl/sh-pfc/pfc-r8a73a4.c |  176 +++-------------------------------
 1 file changed, 15 insertions(+), 161 deletions(-)

diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a73a4.c b/drivers/pinctrl/sh-pfc/pfc-r8a73a4.c
index 464c5f9..bbff559 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a73a4.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a73a4.c
@@ -115,16 +115,6 @@ enum {
 	PORT_ALL(IN),
 	PINMUX_INPUT_END,
 
-	/* PORT0_IN_PU -> PORT329_IN_PU */
-	PINMUX_INPUT_PULLUP_BEGIN,
-	PORT_ALL(IN_PU),
-	PINMUX_INPUT_PULLUP_END,
-
-	/* PORT0_IN_PD -> PORT329_IN_PD */
-	PINMUX_INPUT_PULLDOWN_BEGIN,
-	PORT_ALL(IN_PD),
-	PINMUX_INPUT_PULLDOWN_END,
-
 	/* PORT0_OUT -> PORT329_OUT */
 	PINMUX_OUTPUT_BEGIN,
 	PORT_ALL(OUT),
@@ -438,156 +428,12 @@ enum {
 	PINMUX_MARK_END,
 };
 
+#define _PORT_DATA(pfx, sfx)	PORT_DATA_IO(pfx)
+#define PINMUX_DATA_ALL()    CPU_ALL_PORT(_PORT_DATA, , unused)
+
 static const pinmux_enum_t pinmux_data[] = {
 	/* specify valid pin states for each pin in GPIO mode */
-
-	PORT_DATA_IO_PU_PD(0), PORT_DATA_IO_PU_PD(1),
-	PORT_DATA_IO_PU_PD(2), PORT_DATA_IO_PU_PD(3),
-	PORT_DATA_IO_PU_PD(4), PORT_DATA_IO_PU_PD(5),
-	PORT_DATA_IO_PU_PD(6), PORT_DATA_IO_PU_PD(7),
-	PORT_DATA_IO_PU_PD(8), PORT_DATA_IO_PU_PD(9),
-
-	PORT_DATA_IO_PU_PD(10), PORT_DATA_IO_PU_PD(11),
-	PORT_DATA_IO_PU_PD(12), PORT_DATA_IO_PU_PD(13),
-	PORT_DATA_IO_PU_PD(14),	PORT_DATA_IO_PU_PD(15),
-	PORT_DATA_IO_PU_PD(16), PORT_DATA_IO_PU_PD(17),
-	PORT_DATA_IO_PU_PD(18), PORT_DATA_IO_PU_PD(19),
-
-	PORT_DATA_IO_PU_PD(20), PORT_DATA_IO_PU_PD(21),
-	PORT_DATA_IO_PU_PD(22), PORT_DATA_IO_PU_PD(23),
-	PORT_DATA_IO_PU_PD(24),	PORT_DATA_IO_PU_PD(25),
-	PORT_DATA_IO_PU_PD(26), PORT_DATA_IO_PU_PD(27),
-	PORT_DATA_IO_PU_PD(28), PORT_DATA_IO_PU_PD(29),
-
-	PORT_DATA_IO_PU_PD(30), PORT_DATA_IO_PU_PD(32),
-	PORT_DATA_IO_PU_PD(33), PORT_DATA_IO_PU_PD(34),
-	PORT_DATA_IO_PU_PD(35), PORT_DATA_IO_PU_PD(36),
-	PORT_DATA_IO_PU_PD(37), PORT_DATA_IO_PU_PD(38),
-	PORT_DATA_IO_PU_PD(39), PORT_DATA_IO_PU_PD(40),
-
-	PORT_DATA_IO_PU_PD(64),	PORT_DATA_IO_PU_PD(65),
-	PORT_DATA_IO_PU_PD(66), PORT_DATA_IO_PU_PD(67),
-	PORT_DATA_IO_PU_PD(68), PORT_DATA_IO_PU_PD(69),
-
-	PORT_DATA_IO_PU_PD(70), PORT_DATA_IO_PU_PD(71),
-	PORT_DATA_IO_PU_PD(72), PORT_DATA_IO_PU_PD(73),
-	PORT_DATA_O(74), PORT_DATA_IO_PU_PD(75),
-	PORT_DATA_IO_PU_PD(76), PORT_DATA_IO_PU_PD(77),
-	PORT_DATA_IO_PU_PD(78), PORT_DATA_IO_PU_PD(79),
-
-	PORT_DATA_IO_PU_PD(80), PORT_DATA_IO_PU_PD(81),
-	PORT_DATA_IO_PU_PD(82), PORT_DATA_IO_PU_PD(83),
-	PORT_DATA_IO_PU_PD(84), PORT_DATA_IO_PU_PD(85),
-
-	PORT_DATA_IO_PU_PD(96), PORT_DATA_IO_PU_PD(97),
-	PORT_DATA_IO_PU_PD(98), PORT_DATA_IO_PU_PD(99),
-
-	PORT_DATA_IO_PU_PD(100), PORT_DATA_IO_PU_PD(101),
-	PORT_DATA_IO_PU_PD(102), PORT_DATA_IO_PU_PD(103),
-	PORT_DATA_IO_PU_PD(104), PORT_DATA_IO_PU_PD(105),
-	PORT_DATA_IO_PU_PD(106), PORT_DATA_IO_PU_PD(107),
-	PORT_DATA_IO_PU_PD(108), PORT_DATA_IO_PU_PD(109),
-
-	PORT_DATA_IO_PU_PD(110), PORT_DATA_IO_PU_PD(111),
-	PORT_DATA_IO_PU_PD(112), PORT_DATA_IO_PU_PD(113),
-	PORT_DATA_IO_PU_PD(114), PORT_DATA_IO_PU_PD(115),
-	PORT_DATA_IO_PU_PD(116), PORT_DATA_IO_PU_PD(117),
-	PORT_DATA_IO_PU_PD(118), PORT_DATA_IO_PU_PD(119),
-
-	PORT_DATA_IO_PU_PD(120), PORT_DATA_IO_PU_PD(121),
-	PORT_DATA_IO_PU_PD(122), PORT_DATA_IO_PU_PD(123),
-	PORT_DATA_IO_PU_PD(124), PORT_DATA_IO_PU_PD(125),
-	PORT_DATA_IO_PU_PD(126),
-	PORT_DATA_IO_PU_PD(128), PORT_DATA_IO_PU_PD(129),
-
-	PORT_DATA_IO_PU_PD(130), PORT_DATA_IO_PU_PD(131),
-	PORT_DATA_IO_PU_PD(132), PORT_DATA_IO_PU_PD(133),
-	PORT_DATA_IO_PU_PD(134),
-
-	PORT_DATA_IO_PU_PD(160), PORT_DATA_IO_PU_PD(161),
-	PORT_DATA_IO_PU_PD(162), PORT_DATA_IO_PU_PD(163),
-	PORT_DATA_IO_PU_PD(164), PORT_DATA_IO_PU_PD(165),
-	PORT_DATA_IO_PU_PD(166), PORT_DATA_IO_PU_PD(167),
-	PORT_DATA_IO_PU_PD(168), PORT_DATA_IO_PU_PD(169),
-
-	PORT_DATA_IO_PU_PD(170), PORT_DATA_IO_PU_PD(171),
-	PORT_DATA_IO_PU_PD(172), PORT_DATA_IO_PU_PD(173),
-	PORT_DATA_IO_PU_PD(174), PORT_DATA_IO_PU_PD(175),
-	PORT_DATA_IO_PU_PD(176), PORT_DATA_IO_PU_PD(177),
-	PORT_DATA_IO_PU_PD(178),
-
-	PORT_DATA_IO_PU_PD(192), PORT_DATA_IO_PU_PD(193),
-	PORT_DATA_IO_PU_PD(194), PORT_DATA_IO_PU_PD(195),
-	PORT_DATA_IO_PU_PD(196), PORT_DATA_IO_PU_PD(197),
-	PORT_DATA_IO_PU_PD(198), PORT_DATA_IO_PU_PD(199),
-
-	PORT_DATA_IO_PU_PD(200), PORT_DATA_IO_PU_PD(201),
-	PORT_DATA_IO_PU_PD(202), PORT_DATA_IO_PU_PD(203),
-	PORT_DATA_IO_PU_PD(204), PORT_DATA_IO_PU_PD(205),
-	PORT_DATA_IO_PU_PD(206), PORT_DATA_IO_PU_PD(207),
-	PORT_DATA_IO_PU_PD(208), PORT_DATA_IO_PU_PD(209),
-
-	PORT_DATA_IO_PU_PD(210), PORT_DATA_IO_PU_PD(211),
-	PORT_DATA_IO_PU_PD(212), PORT_DATA_IO_PU_PD(213),
-	PORT_DATA_IO_PU_PD(214), PORT_DATA_IO_PU_PD(215),
-	PORT_DATA_IO_PU_PD(216), PORT_DATA_IO_PU_PD(217),
-	PORT_DATA_IO_PU_PD(218), PORT_DATA_IO_PU_PD(219),
-
-	PORT_DATA_IO_PU_PD(220), PORT_DATA_IO_PU_PD(221),
-	PORT_DATA_IO_PU_PD(222), PORT_DATA_IO_PU_PD(224),
-	PORT_DATA_IO_PU_PD(225), PORT_DATA_IO_PU_PD(226),
-	PORT_DATA_IO_PU_PD(227), PORT_DATA_IO_PU_PD(228),
-	PORT_DATA_IO_PU_PD(229),
-
-	PORT_DATA_IO_PU_PD(230), PORT_DATA_IO_PU_PD(231),
-	PORT_DATA_IO_PU_PD(232), PORT_DATA_IO_PU_PD(233),
-	PORT_DATA_IO_PU_PD(234), PORT_DATA_IO_PU_PD(235),
-	PORT_DATA_IO_PU_PD(236), PORT_DATA_IO_PU_PD(237),
-	PORT_DATA_IO_PU_PD(238), PORT_DATA_IO_PU_PD(239),
-
-	PORT_DATA_IO_PU_PD(240), PORT_DATA_IO_PU_PD(241),
-	PORT_DATA_IO_PU_PD(242), PORT_DATA_IO_PU_PD(243),
-	PORT_DATA_IO_PU_PD(244), PORT_DATA_IO_PU_PD(245),
-	PORT_DATA_IO_PU_PD(246), PORT_DATA_IO_PU_PD(247),
-	PORT_DATA_IO_PU_PD(248), PORT_DATA_IO_PU_PD(249),
-
-	PORT_DATA_IO_PU_PD(250),
-	PORT_DATA_IO_PU_PD(256), PORT_DATA_IO_PU_PD(257),
-	PORT_DATA_IO_PU_PD(258), PORT_DATA_IO_PU_PD(259),
-
-	PORT_DATA_IO_PU_PD(260), PORT_DATA_IO_PU_PD(261),
-	PORT_DATA_IO_PU_PD(262), PORT_DATA_IO_PU_PD(263),
-	PORT_DATA_IO_PU_PD(264), PORT_DATA_IO_PU_PD(265),
-	PORT_DATA_IO_PU_PD(266), PORT_DATA_IO_PU_PD(267),
-	PORT_DATA_IO_PU_PD(268), PORT_DATA_IO_PU_PD(269),
-
-	PORT_DATA_IO_PU_PD(270), PORT_DATA_IO_PU_PD(271),
-	PORT_DATA_IO_PU_PD(272), PORT_DATA_IO_PU_PD(273),
-	PORT_DATA_IO_PU_PD(274), PORT_DATA_IO_PU_PD(275),
-	PORT_DATA_IO_PU_PD(276), PORT_DATA_IO_PU_PD(277),
-	PORT_DATA_IO_PU_PD(278), PORT_DATA_IO_PU_PD(279),
-
-	PORT_DATA_IO_PU_PD(280), PORT_DATA_IO_PU_PD(281),
-	PORT_DATA_IO_PU_PD(282), PORT_DATA_IO_PU_PD(283),
-	PORT_DATA_O(288), PORT_DATA_IO_PU_PD(289),
-
-	PORT_DATA_IO_PU_PD(290), PORT_DATA_IO_PU_PD(291),
-	PORT_DATA_IO_PU_PD(292), PORT_DATA_IO_PU_PD(293),
-	PORT_DATA_IO_PU_PD(294), PORT_DATA_IO_PU_PD(295),
-	PORT_DATA_IO_PU_PD(296), PORT_DATA_IO_PU_PD(297),
-	PORT_DATA_IO_PU_PD(298), PORT_DATA_IO_PU_PD(299),
-
-	PORT_DATA_IO_PU_PD(300), PORT_DATA_IO_PU_PD(301),
-	PORT_DATA_IO_PU_PD(302), PORT_DATA_IO_PU_PD(303),
-	PORT_DATA_IO_PU_PD(304), PORT_DATA_IO_PU_PD(305),
-	PORT_DATA_IO_PU_PD(306), PORT_DATA_IO_PU_PD(307),
-	PORT_DATA_IO_PU_PD(308),
-
-	PORT_DATA_IO_PU_PD(320), PORT_DATA_IO_PU_PD(321),
-	PORT_DATA_IO_PU_PD(322), PORT_DATA_IO_PU_PD(323),
-	PORT_DATA_IO_PU_PD(324), PORT_DATA_IO_PU_PD(325),
-	PORT_DATA_IO_PU_PD(326), PORT_DATA_IO_PU_PD(327),
-	PORT_DATA_IO_PU_PD(328), PORT_DATA_IO_PU_PD(329),
+	PINMUX_DATA_ALL(),
 
 	/* Port0 */
 	PINMUX_DATA(LCDD0_MARK,		PORT0_FN1),
@@ -2042,8 +1888,18 @@ static const struct sh_pfc_function pinmux_functions[] = {
 	SH_PFC_FUNCTION(scifb3),
 };
 
-static const struct pinmux_cfg_reg pinmux_config_regs[] = {
+#undef PORTCR
+#define PORTCR(nr, reg)							\
+	{								\
+		PINMUX_CFG_REG("PORT" nr "CR", reg, 8, 4) {		\
+			_PCRH(PORT##nr##_IN, 0, 0, PORT##nr##_OUT),	\
+				PORT##nr##_FN0, PORT##nr##_FN1,		\
+				PORT##nr##_FN2, PORT##nr##_FN3,		\
+				PORT##nr##_FN4, PORT##nr##_FN5,		\
+				PORT##nr##_FN6, PORT##nr##_FN7 }	\
+	}
 
+static const struct pinmux_cfg_reg pinmux_config_regs[] = {
 	PORTCR(0, 0xe6050000),
 	PORTCR(1, 0xe6050001),
 	PORTCR(2, 0xe6050002),
@@ -2706,8 +2562,6 @@ const struct sh_pfc_soc_info r8a73a4_pinmux_info = {
 	.ops		= &r8a73a4_pinmux_ops,
 
 	.input = { PINMUX_INPUT_BEGIN, PINMUX_INPUT_END },
-	.input_pu = { PINMUX_INPUT_PULLUP_BEGIN, PINMUX_INPUT_PULLUP_END },
-	.input_pd = { PINMUX_INPUT_PULLDOWN_BEGIN, PINMUX_INPUT_PULLDOWN_END },
 	.output = { PINMUX_OUTPUT_BEGIN, PINMUX_OUTPUT_END },
 	.function = { PINMUX_FUNCTION_BEGIN, PINMUX_FUNCTION_END },
 
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 22:05:05 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed,  3 Apr 2013 11:05:05 +0900
Subject: [PATCH 27/28] ARM: shmobile: r8a73a4: Remove all GPIO enums
In-Reply-To: <1364954706-14727-1-git-send-email-horms+renesas@verge.net.au>
References: <1364954706-14727-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364954706-14727-28-git-send-email-horms+renesas@verge.net.au>

From: Magnus Damm <damm at opensource.se>

Function GPIOs are not used anymore, and all code use the GPIO numbers
directly. Remove the GPIOs enumeration.

Signed-off-by: Magnus Damm <damm at opensource.se>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/include/mach/r8a73a4.h |  815 -------------------------
 1 file changed, 815 deletions(-)

diff --git a/arch/arm/mach-shmobile/include/mach/r8a73a4.h b/arch/arm/mach-shmobile/include/mach/r8a73a4.h
index 9162e86..f043103 100644
--- a/arch/arm/mach-shmobile/include/mach/r8a73a4.h
+++ b/arch/arm/mach-shmobile/include/mach/r8a73a4.h
@@ -1,821 +1,6 @@
 #ifndef __ASM_R8A73A4_H__
 #define __ASM_R8A73A4_H__
 
-/*
- * Pin Function Controller:
- *	GPIO_FN_xx - GPIO used to select pin function
- *	GPIO_PORTxx - GPIO mapped to real I/O pin on CPU
- */
-enum {
-
-	/* PORT */
-	GPIO_PORT0, GPIO_PORT1, GPIO_PORT2, GPIO_PORT3, GPIO_PORT4,
-	GPIO_PORT5, GPIO_PORT6, GPIO_PORT7, GPIO_PORT8, GPIO_PORT9,
-
-	GPIO_PORT10, GPIO_PORT11, GPIO_PORT12, GPIO_PORT13, GPIO_PORT14,
-	GPIO_PORT15, GPIO_PORT16, GPIO_PORT17, GPIO_PORT18, GPIO_PORT19,
-
-	GPIO_PORT20, GPIO_PORT21, GPIO_PORT22, GPIO_PORT23, GPIO_PORT24,
-	GPIO_PORT25, GPIO_PORT26, GPIO_PORT27, GPIO_PORT28, GPIO_PORT29,
-
-	GPIO_PORT30, GPIO_PORT32, GPIO_PORT33, GPIO_PORT34,
-	GPIO_PORT35, GPIO_PORT36, GPIO_PORT37, GPIO_PORT38, GPIO_PORT39,
-
-	GPIO_PORT40, GPIO_PORT64,
-	GPIO_PORT65, GPIO_PORT66, GPIO_PORT67, GPIO_PORT68, GPIO_PORT69,
-
-	GPIO_PORT70, GPIO_PORT71, GPIO_PORT72, GPIO_PORT73, GPIO_PORT74,
-	GPIO_PORT75, GPIO_PORT76, GPIO_PORT77, GPIO_PORT78, GPIO_PORT79,
-
-	GPIO_PORT80, GPIO_PORT81, GPIO_PORT82, GPIO_PORT83, GPIO_PORT84,
-	GPIO_PORT85, GPIO_PORT96, GPIO_PORT97, GPIO_PORT98, GPIO_PORT99,
-
-	GPIO_PORT100, GPIO_PORT101, GPIO_PORT102, GPIO_PORT103, GPIO_PORT104,
-	GPIO_PORT105, GPIO_PORT106, GPIO_PORT107, GPIO_PORT108, GPIO_PORT109,
-
-	GPIO_PORT110, GPIO_PORT111, GPIO_PORT112, GPIO_PORT113, GPIO_PORT114,
-	GPIO_PORT115, GPIO_PORT116, GPIO_PORT117, GPIO_PORT118, GPIO_PORT119,
-
-	GPIO_PORT120, GPIO_PORT121, GPIO_PORT122, GPIO_PORT123, GPIO_PORT124,
-	GPIO_PORT125, GPIO_PORT126, GPIO_PORT128, GPIO_PORT129,
-
-	GPIO_PORT130, GPIO_PORT131, GPIO_PORT132, GPIO_PORT133, GPIO_PORT134,
-
-	GPIO_PORT160, GPIO_PORT161, GPIO_PORT162, GPIO_PORT163, GPIO_PORT164,
-	GPIO_PORT165, GPIO_PORT166, GPIO_PORT167, GPIO_PORT168, GPIO_PORT169,
-
-	GPIO_PORT170, GPIO_PORT171, GPIO_PORT172, GPIO_PORT173, GPIO_PORT174,
-	GPIO_PORT175, GPIO_PORT176, GPIO_PORT177, GPIO_PORT178,
-
-	GPIO_PORT192, GPIO_PORT193, GPIO_PORT194,
-	GPIO_PORT195, GPIO_PORT196, GPIO_PORT197, GPIO_PORT198, GPIO_PORT199,
-
-	GPIO_PORT200, GPIO_PORT201, GPIO_PORT202, GPIO_PORT203, GPIO_PORT204,
-	GPIO_PORT205, GPIO_PORT206, GPIO_PORT207, GPIO_PORT208, GPIO_PORT209,
-
-	GPIO_PORT210, GPIO_PORT211, GPIO_PORT212, GPIO_PORT213, GPIO_PORT214,
-	GPIO_PORT215, GPIO_PORT216, GPIO_PORT217, GPIO_PORT218, GPIO_PORT219,
-
-	GPIO_PORT220, GPIO_PORT221, GPIO_PORT222, GPIO_PORT224,
-	GPIO_PORT225, GPIO_PORT226, GPIO_PORT227, GPIO_PORT228, GPIO_PORT229,
-
-	GPIO_PORT230, GPIO_PORT231, GPIO_PORT232, GPIO_PORT233, GPIO_PORT234,
-	GPIO_PORT235, GPIO_PORT236, GPIO_PORT237, GPIO_PORT238, GPIO_PORT239,
-
-	GPIO_PORT240, GPIO_PORT241, GPIO_PORT242, GPIO_PORT243, GPIO_PORT244,
-	GPIO_PORT245, GPIO_PORT246, GPIO_PORT247, GPIO_PORT248, GPIO_PORT249,
-
-	GPIO_PORT250, GPIO_PORT256, GPIO_PORT257, GPIO_PORT258, GPIO_PORT259,
-
-	GPIO_PORT260, GPIO_PORT261, GPIO_PORT262, GPIO_PORT263, GPIO_PORT264,
-	GPIO_PORT265, GPIO_PORT266, GPIO_PORT267, GPIO_PORT268, GPIO_PORT269,
-
-	GPIO_PORT270, GPIO_PORT271, GPIO_PORT272, GPIO_PORT273, GPIO_PORT274,
-	GPIO_PORT275, GPIO_PORT276, GPIO_PORT277, GPIO_PORT278, GPIO_PORT279,
-
-	GPIO_PORT280, GPIO_PORT281, GPIO_PORT282, GPIO_PORT283,
-	GPIO_PORT288, GPIO_PORT289,
-
-	GPIO_PORT290, GPIO_PORT291, GPIO_PORT292, GPIO_PORT293, GPIO_PORT294,
-	GPIO_PORT295, GPIO_PORT296, GPIO_PORT297, GPIO_PORT298, GPIO_PORT299,
-
-	GPIO_PORT300, GPIO_PORT301, GPIO_PORT302, GPIO_PORT303, GPIO_PORT304,
-	GPIO_PORT305, GPIO_PORT306, GPIO_PORT307, GPIO_PORT308,
-
-	GPIO_PORT320, GPIO_PORT321, GPIO_PORT322, GPIO_PORT323, GPIO_PORT324,
-	GPIO_PORT325, GPIO_PORT326, GPIO_PORT327, GPIO_PORT328, GPIO_PORT329,
-
-	/* Port0 */
-	GPIO_FN_LCDD0 = 330,
-	GPIO_FN_PDM2_CLK_0,
-	GPIO_FN_DU0_DR0,
-
-	/* Port1 */
-	GPIO_FN_LCDD1,
-	GPIO_FN_PDM2_DATA_1,
-	GPIO_FN_DU0_DR19,
-
-	/* Port2 */
-	GPIO_FN_LCDD2,
-	GPIO_FN_PDM3_CLK_2,
-	GPIO_FN_DU0_DR2,
-
-	/* Port3 */
-	GPIO_FN_LCDD3,
-	GPIO_FN_PDM3_DATA_3,
-	GPIO_FN_DU0_DR3,
-
-	/* Port4 */
-	GPIO_FN_LCDD4,
-	GPIO_FN_PDM4_CLK_4,
-	GPIO_FN_DU0_DR4,
-
-	/* Port5 */
-	GPIO_FN_LCDD5,
-	GPIO_FN_PDM4_DATA_5,
-	GPIO_FN_DU0_DR5,
-
-	/* Port6 */
-	GPIO_FN_LCDD6,
-	GPIO_FN_PDM0_OUTCLK_6,
-	GPIO_FN_DU0_DR6,
-
-	/* Port7 */
-	GPIO_FN_LCDD7,
-	GPIO_FN_PDM0_OUTDATA_7,
-	GPIO_FN_DU0_DR7,
-
-	/* Port8 */
-	GPIO_FN_LCDD8,
-	GPIO_FN_PDM1_OUTCLK_8,
-	GPIO_FN_DU0_DG0,
-
-	/* Port9 */
-	GPIO_FN_LCDD9,
-	GPIO_FN_PDM1_OUTDATA_9,
-	GPIO_FN_DU0_DG1,
-
-	/* Port10 */
-	GPIO_FN_LCDD10,
-	GPIO_FN_FSICCK,
-	GPIO_FN_DU0_DG2,
-
-	/* Port11 */
-	GPIO_FN_LCDD11,
-	GPIO_FN_FSICISLD,
-	GPIO_FN_DU0_DG3,
-
-	/* Port12 */
-	GPIO_FN_LCDD12,
-	GPIO_FN_FSICOMC,
-	GPIO_FN_DU0_DG4,
-
-	/* Port13 */
-	GPIO_FN_LCDD13,
-	GPIO_FN_FSICOLR,
-	GPIO_FN_FSICILR,
-	GPIO_FN_DU0_DG5,
-
-	/* Port14 */
-	GPIO_FN_LCDD14,
-	GPIO_FN_FSICOBT,
-	GPIO_FN_FSICIBT,
-	GPIO_FN_DU0_DG6,
-
-	/* Port15 */
-	GPIO_FN_LCDD15,
-	GPIO_FN_FSICOSLD,
-	GPIO_FN_DU0_DG7,
-
-	/* Port16 */
-	GPIO_FN_LCDD16,
-	GPIO_FN_TPU1TO1,
-	GPIO_FN_DU0_DB0,
-
-	/* Port17 */
-	GPIO_FN_LCDD17,
-	GPIO_FN_SF_IRQ_00,
-	GPIO_FN_DU0_DB1,
-
-	/* Port18 */
-	GPIO_FN_LCDD18,
-	GPIO_FN_SF_IRQ_01,
-	GPIO_FN_DU0_DB2,
-
-	/* Port19 */
-	GPIO_FN_LCDD19,
-	GPIO_FN_DU0_DB3,
-
-	/* Port20 */
-	GPIO_FN_LCDD20,
-	GPIO_FN_DU0_DB4,
-
-	/* Port21 */
-	GPIO_FN_LCDD21,
-	GPIO_FN_DU0_DB5,
-
-	/* Port22 */
-	GPIO_FN_LCDD22,
-	GPIO_FN_DU0_DB6,
-
-	/* Port23 */
-	GPIO_FN_LCDD23,
-	GPIO_FN_DU0_DB7,
-
-	/* Port24 */
-	GPIO_FN_LCDHSYN,
-	GPIO_FN_LCDCS,
-	GPIO_FN_DU0_EXHSYNC_N_CSYNC_N_HSYNC_N,
-
-	/* Port25 */
-	GPIO_FN_LCDVSYN,
-	GPIO_FN_DU0_EXVSYNC_N_VSYNC_N_CSYNC_N,
-
-	/* Port26 */
-	GPIO_FN_LCDDCK,
-	GPIO_FN_LCDWR,
-	GPIO_FN_DU0_DOTCLKIN,
-
-	/* Port27 */
-	GPIO_FN_LCDDISP,
-	GPIO_FN_LCDRS,
-	GPIO_FN_DU0_DOTCLKOUT,
-
-	/* Port28 */
-	GPIO_FN_LCDRD_N,
-	GPIO_FN_DU0_DOTCLKOUTB,
-
-	/* Port29 */
-	GPIO_FN_LCDLCLK,
-	GPIO_FN_SF_IRQ_02,
-	GPIO_FN_DU0_DISP_CSYNC_N_DE,
-
-	/* Port30 */
-	GPIO_FN_LCDDON,
-	GPIO_FN_SF_IRQ_03,
-	GPIO_FN_DU0_ODDF_N_CLAMP,
-
-	/* Port32 */
-	GPIO_FN_SIM0_DET,
-	GPIO_FN_CSCIF0_RTS,
-
-	/* Port33 */
-	GPIO_FN_SIM1_DET,
-	GPIO_FN_CSCIF0_CTS,
-
-	/* Port34 */
-	GPIO_FN_SIM0_PWRON,
-	GPIO_FN_CSCIF0_SCK,
-
-	/* Port35 */
-	GPIO_FN_CSCIF1_RTS,
-
-	/* Port36 */
-	GPIO_FN_CSCIF1_CTS,
-
-	/* Port37 */
-	GPIO_FN_CSCIF1_SCK,
-
-	/* Port38 */
-	GPIO_FN_TPU0TO1,
-	GPIO_FN_CHSCIF0_HRTS,
-
-	/* Port39 */
-	GPIO_FN_TPU0TO2,
-	GPIO_FN_CHSCIF0_HCTS,
-
-	/* Port40 */
-	GPIO_FN_TPU0TO3,
-	GPIO_FN_CHSCIF0_HSCK,
-
-	/* Port64 */
-	GPIO_FN_PDM0_DATA,
-
-	/* Port65 */
-	GPIO_FN_PDM1_DATA,
-
-	/* Port66 */
-	GPIO_FN_HSI_RX_WAKE,
-	GPIO_FN_MSIOF3_SYNC,
-	GPIO_FN_GenIO4,
-
-	/* Port67 */
-	GPIO_FN_HSI_RX_READY,
-	GPIO_FN_GIO_OUT3_67,
-	GPIO_FN_CHSCIF1_HTX,
-
-	/* Port68 */
-	GPIO_FN_HSI_RX_FLAG,
-	GPIO_FN_MSIOF3_TXD,
-	GPIO_FN_GIO_OUT4_68,
-
-	/* Port69 */
-	GPIO_FN_HSI_RX_DATA,
-	GPIO_FN_MSIOF3_RXD,
-	GPIO_FN_GIO_OUT5_69,
-
-	/* Port70 */
-	GPIO_FN_HSI_TX_FLAG,
-	GPIO_FN_GIO_OUT1_70,
-	GPIO_FN_HSIC_TSTCLK0,
-	GPIO_FN_CHSCIF1_HRTS,
-
-	/* Port71 */
-	GPIO_FN_HSI_TX_DATA,
-	GPIO_FN_GIO_OUT2_71,
-	GPIO_FN_HSIC_TSTCLK1,
-	GPIO_FN_CHSCIF1_HCTS,
-
-	/* Port72 */
-	GPIO_FN_HSI_TX_WAKE,
-	GPIO_FN_GenIO8,
-	GPIO_FN_CHSCIF1_HRX,
-
-	/* Port73 */
-	GPIO_FN_HSI_TX_READY,
-	GPIO_FN_MSIOF3_SCK,
-	GPIO_FN_GIO_OUT0_73,
-
-	/* Port74 - Port85 */
-	GPIO_FN_IRDA_OUT,
-	GPIO_FN_IRDA_IN,
-	GPIO_FN_IRDA_FIRSEL,
-	GPIO_FN_TPU0TO0,
-	GPIO_FN_DIGRFEN,
-	GPIO_FN_GPS_TIMESTAMP,
-	GPIO_FN_TXP,
-	GPIO_FN_TXP2,
-	GPIO_FN_COEX_0,
-	GPIO_FN_COEX_1,
-
-	/* Port96 - Port101 */
-	GPIO_FN_KEYIN0,
-	GPIO_FN_KEYIN1,
-	GPIO_FN_KEYIN2,
-	GPIO_FN_KEYIN3,
-	GPIO_FN_KEYIN4,
-	GPIO_FN_KEYIN5,
-
-	/* Port102 */
-	GPIO_FN_KEYIN6,
-
-	/* Port103 */
-	GPIO_FN_KEYIN7,
-
-	/* Port104 - Port108 */
-	GPIO_FN_KEYOUT0,
-	GPIO_FN_KEYOUT1,
-	GPIO_FN_KEYOUT2,
-	GPIO_FN_KEYOUT3,
-	GPIO_FN_KEYOUT4,
-
-	/* Port109 */
-	GPIO_FN_KEYOUT5,
-
-	/* Port110 */
-	GPIO_FN_KEYOUT6,
-
-	/* Port111 */
-	GPIO_FN_KEYOUT7,
-	GPIO_FN_RFANAEN,
-
-	/* Port112 */
-	GPIO_FN_KEYIN8,
-	GPIO_FN_KEYOUT8,
-	GPIO_FN_SF_IRQ_04,
-
-	/* Port113 */
-	GPIO_FN_KEYIN9,
-	GPIO_FN_KEYOUT9,
-	GPIO_FN_SF_IRQ_05,
-
-	/* Port114 */
-	GPIO_FN_KEYIN10,
-	GPIO_FN_KEYOUT10,
-	GPIO_FN_SF_IRQ_06,
-
-	/* Port115 */
-	GPIO_FN_KEYIN11,
-	GPIO_FN_KEYOUT11,
-	GPIO_FN_SF_IRQ_07,
-
-	/* Port116 */
-	GPIO_FN_CSCIF0_TX,
-
-	/* Port117 */
-	GPIO_FN_CSCIF0_RX,
-
-	/* Port118 */
-	GPIO_FN_CSCIF1_TX,
-
-	/* Port119 */
-	GPIO_FN_CSCIF1_RX,
-
-	/* Port120 */
-	GPIO_FN_SF_PORT_1_120,
-	GPIO_FN_DU0_CDE,
-
-	/* Port121 */
-	GPIO_FN_SF_PORT_0_121,
-
-	/* Port122 */
-	GPIO_FN_CHSCIF0_HTX,
-
-	/* Port123 */
-	GPIO_FN_CHSCIF0_HRX,
-
-	/* Port124 */
-	GPIO_FN_ISP_STROBE_124,
-
-	/* Port125 */
-	GPIO_FN_STP_ISD_0,
-	GPIO_FN_PDM4_CLK_125,
-	GPIO_FN_MSIOF2_TXD,
-	GPIO_FN_SIM0_VOLTSEL0,
-
-	/* Port126 */
-	GPIO_FN_TS_SDEN,
-	GPIO_FN_MSIOF7_SYNC,
-	GPIO_FN_STP_ISEN_1,
-
-	/* Port128 */
-	GPIO_FN_STP_ISEN_0,
-	GPIO_FN_PDM1_OUTDATA_128,
-	GPIO_FN_MSIOF2_SYNC,
-	GPIO_FN_SIM1_VOLTSEL1,
-
-	/* Port129 */
-	GPIO_FN_TS_SPSYNC,
-	GPIO_FN_MSIOF7_RXD,
-	GPIO_FN_STP_ISSYNC_1,
-
-	/* Port130 */
-	GPIO_FN_STP_ISSYNC_0,
-	GPIO_FN_PDM4_DATA_130,
-	GPIO_FN_MSIOF2_RXD,
-	GPIO_FN_SIM0_VOLTSEL1,
-
-	/* Port131 */
-	GPIO_FN_STP_OPWM_0,
-	GPIO_FN_SIM1_PWRON,
-
-	/* Port132 */
-	GPIO_FN_TS_SCK,
-	GPIO_FN_MSIOF7_SCK,
-	GPIO_FN_STP_ISCLK_1,
-
-	/* Port133 */
-	GPIO_FN_STP_ISCLK_0,
-	GPIO_FN_PDM1_OUTCLK_133,
-	GPIO_FN_MSIOF2_SCK,
-	GPIO_FN_SIM1_VOLTSEL0,
-
-	/* Port134 */
-	GPIO_FN_TS_SDAT,
-	GPIO_FN_MSIOF7_TXD,
-	GPIO_FN_STP_ISD_1,
-
-	/* Port160 - Port178 */
-	GPIO_FN_MMCD0_0,
-	GPIO_FN_MMCD0_1,
-	GPIO_FN_MMCD0_2,
-	GPIO_FN_MMCD0_3,
-	GPIO_FN_MMCD0_4,
-	GPIO_FN_MMCD0_5,
-	GPIO_FN_MMCD0_6,
-	GPIO_FN_MMCD0_7,
-	GPIO_FN_MMCCMD0,
-	GPIO_FN_MMCCLK0,
-	GPIO_FN_MMCRST,
-
-	/* Port192 - Port200 FN1 */
-	GPIO_FN_A10,
-	GPIO_FN_A9,
-	GPIO_FN_A8,
-	GPIO_FN_A7,
-	GPIO_FN_A6,
-	GPIO_FN_A5,
-	GPIO_FN_A4,
-	GPIO_FN_A3,
-	GPIO_FN_A2,
-
-	/* Port192 - Port200 FN2 */
-	GPIO_FN_MMCD1_7,
-	GPIO_FN_MMCD1_6,
-	GPIO_FN_MMCD1_5,
-	GPIO_FN_MMCD1_4,
-	GPIO_FN_MMCD1_3,
-	GPIO_FN_MMCD1_2,
-	GPIO_FN_MMCD1_1,
-	GPIO_FN_MMCD1_0,
-	GPIO_FN_MMCCMD1,
-
-	/* Port192 - Port200 IRQ */
-
-	/* Port201 */
-	GPIO_FN_A1,
-
-	/* Port202 */
-	GPIO_FN_A0,
-	GPIO_FN_BS,
-
-	/* Port203 */
-	GPIO_FN_CKO,
-	GPIO_FN_MMCCLK1,
-
-	/* Port204 */
-	GPIO_FN_CS0_N,
-	GPIO_FN_SIM0_GPO1,
-
-	/* Port205 */
-	GPIO_FN_CS2_N,
-	GPIO_FN_SIM0_GPO2,
-
-	/* Port206 */
-	GPIO_FN_CS4_N,
-	GPIO_FN_VIO_VD,
-	GPIO_FN_SIM1_GPO0,
-
-	/* Port207 - Port212 FN1 */
-	GPIO_FN_D15,
-	GPIO_FN_D14,
-	GPIO_FN_D13,
-	GPIO_FN_D12,
-	GPIO_FN_D11,
-	GPIO_FN_D10,
-
-	/* Port207 - Port212 FN5 */
-	GPIO_FN_GIO_OUT15,
-	GPIO_FN_GIO_OUT14,
-	GPIO_FN_GIO_OUT13,
-	GPIO_FN_GIO_OUT12,
-	GPIO_FN_WGM_TXP2,
-	GPIO_FN_WGM_GPS_TIMEM_ASK_RFCLK,
-
-	/* Port213 - Port222 FN1 */
-	GPIO_FN_D9,
-	GPIO_FN_D8,
-	GPIO_FN_D7,
-	GPIO_FN_D6,
-	GPIO_FN_D5,
-	GPIO_FN_D4,
-	GPIO_FN_D3,
-	GPIO_FN_D2,
-	GPIO_FN_D1,
-	GPIO_FN_D0,
-
-	/* Port213 - Port222 FN2 */
-	GPIO_FN_VIO_D9,
-	GPIO_FN_VIO_D8,
-	GPIO_FN_VIO_D7,
-	GPIO_FN_VIO_D6,
-	GPIO_FN_VIO_D5,
-	GPIO_FN_VIO_D4,
-	GPIO_FN_VIO_D3,
-	GPIO_FN_VIO_D2,
-	GPIO_FN_VIO_D1,
-	GPIO_FN_VIO_D0,
-
-	/* Port213 - Port222 FN5 */
-	GPIO_FN_GIO_OUT9,
-	GPIO_FN_GIO_OUT8,
-	GPIO_FN_GIO_OUT7,
-	GPIO_FN_GIO_OUT6,
-	GPIO_FN_GIO_OUT5_217,
-	GPIO_FN_GIO_OUT4_218,
-	GPIO_FN_GIO_OUT3_219,
-	GPIO_FN_GIO_OUT2_220,
-	GPIO_FN_GIO_OUT1_221,
-	GPIO_FN_GIO_OUT0_222,
-
-	/* Port224 */
-	GPIO_FN_RDWR_224,
-	GPIO_FN_VIO_HD,
-	GPIO_FN_SIM1_GPO2,
-
-	/* Port225 */
-	GPIO_FN_RD_N,
-
-	/* Port226 */
-	GPIO_FN_WAIT_N,
-	GPIO_FN_VIO_CLK,
-	GPIO_FN_SIM1_GPO1,
-
-	/* Port227 */
-	GPIO_FN_WE0_N,
-	GPIO_FN_RDWR_227,
-
-	/* Port228 */
-	GPIO_FN_WE1_N,
-	GPIO_FN_SIM0_GPO0,
-
-	/* Port229 */
-	GPIO_FN_PWMO,
-	GPIO_FN_VIO_CKO1_229,
-
-	/* Port230 */
-	GPIO_FN_SLIM_CLK,
-	GPIO_FN_VIO_CKO4_230,
-
-	/* Port231 */
-	GPIO_FN_SLIM_DATA,
-	GPIO_FN_VIO_CKO5_231,
-
-	/* Port232 */
-	GPIO_FN_VIO_CKO2_232,
-	GPIO_FN_SF_PORT_0_232,
-
-	/* Port233 */
-	GPIO_FN_VIO_CKO3_233,
-	GPIO_FN_SF_PORT_1_233,
-
-	/* Port234 */
-	GPIO_FN_FSIACK,
-	GPIO_FN_PDM3_CLK_234,
-	GPIO_FN_ISP_IRIS1_234,
-
-	/* Port235 */
-	GPIO_FN_FSIAISLD,
-	GPIO_FN_PDM3_DATA_235,
-
-	/* Port236 */
-	GPIO_FN_FSIAOMC,
-	GPIO_FN_PDM0_OUTCLK_236,
-	GPIO_FN_ISP_IRIS0_236,
-
-	/* Port237 */
-	GPIO_FN_FSIAOLR,
-	GPIO_FN_FSIAILR,
-
-	/* Port238 */
-	GPIO_FN_FSIAOBT,
-	GPIO_FN_FSIAIBT,
-
-	/* Port239 */
-	GPIO_FN_FSIAOSLD,
-	GPIO_FN_PDM0_OUTDATA_239,
-
-	/* Port240 */
-	GPIO_FN_FSIBISLD,
-
-	/* Port241 */
-	GPIO_FN_FSIBOLR,
-	GPIO_FN_FSIBILR,
-
-	/* Port242 */
-	GPIO_FN_FSIBOMC,
-	GPIO_FN_ISP_SHUTTER1_242,
-
-	/* Port243 */
-	GPIO_FN_FSIBOBT,
-	GPIO_FN_FSIBIBT,
-
-	/* Port244 */
-	GPIO_FN_FSIBOSLD,
-	GPIO_FN_FSIASPDIF,
-
-	/* Port245 */
-	GPIO_FN_FSIBCK,
-	GPIO_FN_ISP_SHUTTER0_245,
-
-	/* Port246 - Port250 FN1 */
-	GPIO_FN_ISP_IRIS1_246,
-	GPIO_FN_ISP_IRIS0_247,
-	GPIO_FN_ISP_SHUTTER1_248,
-	GPIO_FN_ISP_SHUTTER0_249,
-	GPIO_FN_ISP_STROBE_250,
-
-	/* Port256 - Port258 */
-	GPIO_FN_MSIOF0_SYNC,
-	GPIO_FN_MSIOF0_RXD,
-	GPIO_FN_MSIOF0_SCK,
-
-	/* Port259 */
-	GPIO_FN_MSIOF0_SS2,
-	GPIO_FN_VIO_CKO3_259,
-
-	/* Port260 */
-	GPIO_FN_MSIOF0_TXD,
-
-	/* Port261 */
-	GPIO_FN_CHSCIF1_HSCK,
-
-	/* Port262 */
-
-	/* Port263 - Port266 FN1 */
-	GPIO_FN_MSIOF1_SS2,
-	GPIO_FN_MSIOF1_TXD,
-	GPIO_FN_MSIOF1_RXD,
-	GPIO_FN_MSIOF1_SS1,
-
-	/* Port263 - Port266 FN4 */
-	GPIO_FN_MSIOF5_SS2,
-	GPIO_FN_MSIOF5_TXD,
-	GPIO_FN_MSIOF5_RXD,
-	GPIO_FN_MSIOF5_SS1,
-
-	/* Port267 */
-	GPIO_FN_MSIOF0_SS1,
-
-	/* Port268 */
-	GPIO_FN_MSIOF1_SCK,
-	GPIO_FN_MSIOF5_SCK,
-
-	/* Port269 */
-	GPIO_FN_MSIOF1_SYNC,
-	GPIO_FN_MSIOF5_SYNC,
-
-	/* Port270 - Port273 FN1 */
-	GPIO_FN_MSIOF2_SS1,
-	GPIO_FN_MSIOF2_SS2,
-	GPIO_FN_MSIOF3_SS2,
-	GPIO_FN_MSIOF3_SS1,
-
-	/* Port270 - Port273 FN3 */
-	GPIO_FN_VIO_CKO5_270,
-	GPIO_FN_VIO_CKO2_271,
-	GPIO_FN_VIO_CKO1_272,
-	GPIO_FN_VIO_CKO4_273,
-
-	/* Port274 */
-	GPIO_FN_MSIOF4_SS2,
-	GPIO_FN_TPU1TO0,
-
-	/* Port275 - Port280 */
-	GPIO_FN_IC_DP,
-	GPIO_FN_SIM0_RST,
-	GPIO_FN_IC_DM,
-	GPIO_FN_SIM0_BSICOMP,
-	GPIO_FN_SIM0_CLK,
-	GPIO_FN_SIM0_IO,
-
-	/* Port281 */
-	GPIO_FN_SIM1_IO,
-	GPIO_FN_PDM2_DATA_281,
-
-	/* Port282 */
-	GPIO_FN_SIM1_CLK,
-	GPIO_FN_PDM2_CLK_282,
-
-	/* Port283 */
-	GPIO_FN_SIM1_RST,
-
-	/* Port289 */
-	GPIO_FN_SDHID1_0,
-	GPIO_FN_STMDATA0_2,
-
-	/* Port290 */
-	GPIO_FN_SDHID1_1,
-	GPIO_FN_STMDATA1_2,
-
-	/* Port291 - Port294 FN1 */
-	GPIO_FN_SDHID1_2,
-	GPIO_FN_SDHID1_3,
-	GPIO_FN_SDHICLK1,
-	GPIO_FN_SDHICMD1,
-
-	/* Port291 - Port294 FN3 */
-	GPIO_FN_STMDATA2_2,
-	GPIO_FN_STMDATA3_2,
-	GPIO_FN_STMCLK_2,
-	GPIO_FN_STMSIDI_2,
-
-	/* Port295 */
-	GPIO_FN_SDHID2_0,
-	GPIO_FN_MSIOF4_TXD,
-	GPIO_FN_MSIOF6_TXD,
-
-	/* Port296 */
-	GPIO_FN_SDHID2_1,
-	GPIO_FN_MSIOF6_SS2,
-
-	/* Port297 - Port300 FN1 */
-	GPIO_FN_SDHID2_2,
-	GPIO_FN_SDHID2_3,
-	GPIO_FN_SDHICLK2,
-	GPIO_FN_SDHICMD2,
-
-	/* Port297 - Port300 FN2 */
-	GPIO_FN_MSIOF4_RXD,
-	GPIO_FN_MSIOF4_SYNC,
-	GPIO_FN_MSIOF4_SCK,
-	GPIO_FN_MSIOF4_SS1,
-
-	/* Port297 - Port300 FN3 */
-
-	/* Port297 - Port300 FN4 */
-	GPIO_FN_MSIOF6_RXD,
-	GPIO_FN_MSIOF6_SYNC,
-	GPIO_FN_MSIOF6_SCK,
-	GPIO_FN_MSIOF6_SS1,
-
-	/* Port301 */
-	GPIO_FN_SDHICD0,
-
-	/* Port302 - Port306 FN1 */
-	GPIO_FN_SDHID0_0,
-	GPIO_FN_SDHID0_1,
-	GPIO_FN_SDHID0_2,
-	GPIO_FN_SDHID0_3,
-	GPIO_FN_SDHICMD0,
-
-	/* Port302 - Port306 FN3 */
-	GPIO_FN_STMDATA0_1,
-	GPIO_FN_STMDATA1_1,
-	GPIO_FN_STMDATA2_1,
-	GPIO_FN_STMDATA3_1,
-	GPIO_FN_STMSIDI_1,
-
-	/* Port307 */
-	GPIO_FN_SDHIWP0,
-
-	/* Port308 */
-	GPIO_FN_SDHICLK0,
-	GPIO_FN_STMCLK_1,
-
-	/* Port320 - Port329 */
-};
-
 void r8a73a4_add_standard_devices(void);
 void r8a73a4_clock_init(void);
 void r8a73a4_pinmux_init(void);
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 22:04:54 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed,  3 Apr 2013 11:04:54 +0900
Subject: [PATCH 16/28] sh-pfc: Add r8a73a4 pinmux support
In-Reply-To: <1364954706-14727-1-git-send-email-horms+renesas@verge.net.au>
References: <1364954706-14727-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364954706-14727-17-git-send-email-horms+renesas@verge.net.au>

From: Magnus Damm <damm at opensource.se>

Add initial PFC support for the r8a73a4 SoC.

At this point only GPIO interface is supported, move to newer interfaces
planned as incremental changes.

Original authors are Morimoto-san with help from Yoshii-san, thanks to
them for the heavy lifting. Adjusted by Magnus to work together with
updated code in drivers/pinctrl.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Signed-off-by: Takashi Yoshii <takashi.yoshii.zj at renesas.com>
Signed-off-by: Magnus Damm <damm at opensource.se>
Acked-by: Linus Walleij <linus.walleij at linaro.org>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/include/mach/r8a73a4.h |  918 ++++++++
 drivers/pinctrl/sh-pfc/Kconfig                |    5 +
 drivers/pinctrl/sh-pfc/Makefile               |    1 +
 drivers/pinctrl/sh-pfc/core.c                 |    3 +
 drivers/pinctrl/sh-pfc/core.h                 |    1 +
 drivers/pinctrl/sh-pfc/pfc-r8a73a4.c          | 2826 +++++++++++++++++++++++++
 6 files changed, 3754 insertions(+)
 create mode 100644 drivers/pinctrl/sh-pfc/pfc-r8a73a4.c

diff --git a/arch/arm/mach-shmobile/include/mach/r8a73a4.h b/arch/arm/mach-shmobile/include/mach/r8a73a4.h
index f043103..f0b1b4a 100644
--- a/arch/arm/mach-shmobile/include/mach/r8a73a4.h
+++ b/arch/arm/mach-shmobile/include/mach/r8a73a4.h
@@ -1,6 +1,924 @@
 #ifndef __ASM_R8A73A4_H__
 #define __ASM_R8A73A4_H__
 
+/*
+ * Pin Function Controller:
+ *	GPIO_FN_xx - GPIO used to select pin function
+ *	GPIO_PORTxx - GPIO mapped to real I/O pin on CPU
+ */
+enum {
+
+	/* PORT */
+	GPIO_PORT0, GPIO_PORT1, GPIO_PORT2, GPIO_PORT3, GPIO_PORT4,
+	GPIO_PORT5, GPIO_PORT6, GPIO_PORT7, GPIO_PORT8, GPIO_PORT9,
+
+	GPIO_PORT10, GPIO_PORT11, GPIO_PORT12, GPIO_PORT13, GPIO_PORT14,
+	GPIO_PORT15, GPIO_PORT16, GPIO_PORT17, GPIO_PORT18, GPIO_PORT19,
+
+	GPIO_PORT20, GPIO_PORT21, GPIO_PORT22, GPIO_PORT23, GPIO_PORT24,
+	GPIO_PORT25, GPIO_PORT26, GPIO_PORT27, GPIO_PORT28, GPIO_PORT29,
+
+	GPIO_PORT30, GPIO_PORT32, GPIO_PORT33, GPIO_PORT34,
+	GPIO_PORT35, GPIO_PORT36, GPIO_PORT37, GPIO_PORT38, GPIO_PORT39,
+
+	GPIO_PORT40, GPIO_PORT64,
+	GPIO_PORT65, GPIO_PORT66, GPIO_PORT67, GPIO_PORT68, GPIO_PORT69,
+
+	GPIO_PORT70, GPIO_PORT71, GPIO_PORT72, GPIO_PORT73, GPIO_PORT74,
+	GPIO_PORT75, GPIO_PORT76, GPIO_PORT77, GPIO_PORT78, GPIO_PORT79,
+
+	GPIO_PORT80, GPIO_PORT81, GPIO_PORT82, GPIO_PORT83, GPIO_PORT84,
+	GPIO_PORT85, GPIO_PORT96, GPIO_PORT97, GPIO_PORT98, GPIO_PORT99,
+
+	GPIO_PORT100, GPIO_PORT101, GPIO_PORT102, GPIO_PORT103, GPIO_PORT104,
+	GPIO_PORT105, GPIO_PORT106, GPIO_PORT107, GPIO_PORT108, GPIO_PORT109,
+
+	GPIO_PORT110, GPIO_PORT111, GPIO_PORT112, GPIO_PORT113, GPIO_PORT114,
+	GPIO_PORT115, GPIO_PORT116, GPIO_PORT117, GPIO_PORT118, GPIO_PORT119,
+
+	GPIO_PORT120, GPIO_PORT121, GPIO_PORT122, GPIO_PORT123, GPIO_PORT124,
+	GPIO_PORT125, GPIO_PORT126, GPIO_PORT128, GPIO_PORT129,
+
+	GPIO_PORT130, GPIO_PORT131, GPIO_PORT132, GPIO_PORT133, GPIO_PORT134,
+
+	GPIO_PORT160, GPIO_PORT161, GPIO_PORT162, GPIO_PORT163, GPIO_PORT164,
+	GPIO_PORT165, GPIO_PORT166, GPIO_PORT167, GPIO_PORT168, GPIO_PORT169,
+
+	GPIO_PORT170, GPIO_PORT171, GPIO_PORT172, GPIO_PORT173, GPIO_PORT174,
+	GPIO_PORT175, GPIO_PORT176, GPIO_PORT177, GPIO_PORT178,
+
+	GPIO_PORT192, GPIO_PORT193, GPIO_PORT194,
+	GPIO_PORT195, GPIO_PORT196, GPIO_PORT197, GPIO_PORT198, GPIO_PORT199,
+
+	GPIO_PORT200, GPIO_PORT201, GPIO_PORT202, GPIO_PORT203, GPIO_PORT204,
+	GPIO_PORT205, GPIO_PORT206, GPIO_PORT207, GPIO_PORT208, GPIO_PORT209,
+
+	GPIO_PORT210, GPIO_PORT211, GPIO_PORT212, GPIO_PORT213, GPIO_PORT214,
+	GPIO_PORT215, GPIO_PORT216, GPIO_PORT217, GPIO_PORT218, GPIO_PORT219,
+
+	GPIO_PORT220, GPIO_PORT221, GPIO_PORT222, GPIO_PORT224,
+	GPIO_PORT225, GPIO_PORT226, GPIO_PORT227, GPIO_PORT228, GPIO_PORT229,
+
+	GPIO_PORT230, GPIO_PORT231, GPIO_PORT232, GPIO_PORT233, GPIO_PORT234,
+	GPIO_PORT235, GPIO_PORT236, GPIO_PORT237, GPIO_PORT238, GPIO_PORT239,
+
+	GPIO_PORT240, GPIO_PORT241, GPIO_PORT242, GPIO_PORT243, GPIO_PORT244,
+	GPIO_PORT245, GPIO_PORT246, GPIO_PORT247, GPIO_PORT248, GPIO_PORT249,
+
+	GPIO_PORT250, GPIO_PORT256, GPIO_PORT257, GPIO_PORT258, GPIO_PORT259,
+
+	GPIO_PORT260, GPIO_PORT261, GPIO_PORT262, GPIO_PORT263, GPIO_PORT264,
+	GPIO_PORT265, GPIO_PORT266, GPIO_PORT267, GPIO_PORT268, GPIO_PORT269,
+
+	GPIO_PORT270, GPIO_PORT271, GPIO_PORT272, GPIO_PORT273, GPIO_PORT274,
+	GPIO_PORT275, GPIO_PORT276, GPIO_PORT277, GPIO_PORT278, GPIO_PORT279,
+
+	GPIO_PORT280, GPIO_PORT281, GPIO_PORT282, GPIO_PORT283,
+	GPIO_PORT288, GPIO_PORT289,
+
+	GPIO_PORT290, GPIO_PORT291, GPIO_PORT292, GPIO_PORT293, GPIO_PORT294,
+	GPIO_PORT295, GPIO_PORT296, GPIO_PORT297, GPIO_PORT298, GPIO_PORT299,
+
+	GPIO_PORT300, GPIO_PORT301, GPIO_PORT302, GPIO_PORT303, GPIO_PORT304,
+	GPIO_PORT305, GPIO_PORT306, GPIO_PORT307, GPIO_PORT308,
+
+	GPIO_PORT320, GPIO_PORT321, GPIO_PORT322, GPIO_PORT323, GPIO_PORT324,
+	GPIO_PORT325, GPIO_PORT326, GPIO_PORT327, GPIO_PORT328, GPIO_PORT329,
+
+	/* Port0 */
+	GPIO_FN_LCDD0,
+	GPIO_FN_PDM2_CLK_0,
+	GPIO_FN_DU0_DR0,
+	GPIO_FN_IRQ0,
+
+	/* Port1 */
+	GPIO_FN_LCDD1,
+	GPIO_FN_PDM2_DATA_1,
+	GPIO_FN_DU0_DR19,
+	GPIO_FN_IRQ1,
+
+	/* Port2 */
+	GPIO_FN_LCDD2,
+	GPIO_FN_PDM3_CLK_2,
+	GPIO_FN_DU0_DR2,
+	GPIO_FN_IRQ2,
+
+	/* Port3 */
+	GPIO_FN_LCDD3,
+	GPIO_FN_PDM3_DATA_3,
+	GPIO_FN_DU0_DR3,
+	GPIO_FN_IRQ3,
+
+	/* Port4 */
+	GPIO_FN_LCDD4,
+	GPIO_FN_PDM4_CLK_4,
+	GPIO_FN_DU0_DR4,
+	GPIO_FN_IRQ4,
+
+	/* Port5 */
+	GPIO_FN_LCDD5,
+	GPIO_FN_PDM4_DATA_5,
+	GPIO_FN_DU0_DR5,
+	GPIO_FN_IRQ5,
+
+	/* Port6 */
+	GPIO_FN_LCDD6,
+	GPIO_FN_PDM0_OUTCLK_6,
+	GPIO_FN_DU0_DR6,
+	GPIO_FN_IRQ6,
+
+	/* Port7 */
+	GPIO_FN_LCDD7,
+	GPIO_FN_PDM0_OUTDATA_7,
+	GPIO_FN_DU0_DR7,
+	GPIO_FN_IRQ7,
+
+	/* Port8 */
+	GPIO_FN_LCDD8,
+	GPIO_FN_PDM1_OUTCLK_8,
+	GPIO_FN_DU0_DG0,
+	GPIO_FN_IRQ8,
+
+	/* Port9 */
+	GPIO_FN_LCDD9,
+	GPIO_FN_PDM1_OUTDATA_9,
+	GPIO_FN_DU0_DG1,
+	GPIO_FN_IRQ9,
+
+	/* Port10 */
+	GPIO_FN_LCDD10,
+	GPIO_FN_FSICCK,
+	GPIO_FN_DU0_DG2,
+	GPIO_FN_IRQ10,
+
+	/* Port11 */
+	GPIO_FN_LCDD11,
+	GPIO_FN_FSICISLD,
+	GPIO_FN_DU0_DG3,
+	GPIO_FN_IRQ11,
+
+	/* Port12 */
+	GPIO_FN_LCDD12,
+	GPIO_FN_FSICOMC,
+	GPIO_FN_DU0_DG4,
+	GPIO_FN_IRQ12,
+
+	/* Port13 */
+	GPIO_FN_LCDD13,
+	GPIO_FN_FSICOLR,
+	GPIO_FN_FSICILR,
+	GPIO_FN_DU0_DG5,
+	GPIO_FN_IRQ13,
+
+	/* Port14 */
+	GPIO_FN_LCDD14,
+	GPIO_FN_FSICOBT,
+	GPIO_FN_FSICIBT,
+	GPIO_FN_DU0_DG6,
+	GPIO_FN_IRQ14,
+
+	/* Port15 */
+	GPIO_FN_LCDD15,
+	GPIO_FN_FSICOSLD,
+	GPIO_FN_DU0_DG7,
+	GPIO_FN_IRQ15,
+
+	/* Port16 */
+	GPIO_FN_LCDD16,
+	GPIO_FN_TPU1TO1,
+	GPIO_FN_DU0_DB0,
+
+	/* Port17 */
+	GPIO_FN_LCDD17,
+	GPIO_FN_SF_IRQ_00,
+	GPIO_FN_DU0_DB1,
+
+	/* Port18 */
+	GPIO_FN_LCDD18,
+	GPIO_FN_SF_IRQ_01,
+	GPIO_FN_DU0_DB2,
+
+	/* Port19 */
+	GPIO_FN_LCDD19,
+	GPIO_FN_SCIFB3_RTS_19,
+	GPIO_FN_DU0_DB3,
+
+	/* Port20 */
+	GPIO_FN_LCDD20,
+	GPIO_FN_SCIFB3_CTS_20,
+	GPIO_FN_DU0_DB4,
+
+	/* Port21 */
+	GPIO_FN_LCDD21,
+	GPIO_FN_SCIFB3_TXD_21,
+	GPIO_FN_DU0_DB5,
+
+	/* Port22 */
+	GPIO_FN_LCDD22,
+	GPIO_FN_SCIFB3_RXD_22,
+	GPIO_FN_DU0_DB6,
+
+	/* Port23 */
+	GPIO_FN_LCDD23,
+	GPIO_FN_SCIFB3_SCK_23,
+	GPIO_FN_DU0_DB7,
+
+	/* Port24 */
+	GPIO_FN_LCDHSYN,
+	GPIO_FN_LCDCS,
+	GPIO_FN_SCIFB1_RTS_24,
+	GPIO_FN_DU0_EXHSYNC_N_CSYNC_N_HSYNC_N,
+
+	/* Port25 */
+	GPIO_FN_LCDVSYN,
+	GPIO_FN_SCIFB1_CTS_25,
+	GPIO_FN_DU0_EXVSYNC_N_VSYNC_N_CSYNC_N,
+
+	/* Port26 */
+	GPIO_FN_LCDDCK,
+	GPIO_FN_LCDWR,
+	GPIO_FN_SCIFB1_TXD_26,
+	GPIO_FN_DU0_DOTCLKIN,
+
+	/* Port27 */
+	GPIO_FN_LCDDISP,
+	GPIO_FN_LCDRS,
+	GPIO_FN_SCIFB1_RXD_27,
+	GPIO_FN_DU0_DOTCLKOUT,
+
+	/* Port28 */
+	GPIO_FN_LCDRD_N,
+	GPIO_FN_SCIFB1_SCK_28,
+	GPIO_FN_DU0_DOTCLKOUTB,
+
+	/* Port29 */
+	GPIO_FN_LCDLCLK,
+	GPIO_FN_SF_IRQ_02,
+	GPIO_FN_DU0_DISP_CSYNC_N_DE,
+
+	/* Port30 */
+	GPIO_FN_LCDDON,
+	GPIO_FN_SF_IRQ_03,
+	GPIO_FN_DU0_ODDF_N_CLAMP,
+
+	/* Port32 */
+	GPIO_FN_SCIFA0_RTS,
+	GPIO_FN_SIM0_DET,
+	GPIO_FN_CSCIF0_RTS,
+
+	/* Port33 */
+	GPIO_FN_SCIFA0_CTS,
+	GPIO_FN_SIM1_DET,
+	GPIO_FN_CSCIF0_CTS,
+
+	/* Port34 */
+	GPIO_FN_SCIFA0_SCK,
+	GPIO_FN_SIM0_PWRON,
+	GPIO_FN_CSCIF0_SCK,
+
+	/* Port35 */
+	GPIO_FN_SCIFA1_RTS,
+	GPIO_FN_CSCIF1_RTS,
+
+	/* Port36 */
+	GPIO_FN_SCIFA1_CTS,
+	GPIO_FN_CSCIF1_CTS,
+
+	/* Port37 */
+	GPIO_FN_SCIFA1_SCK,
+	GPIO_FN_CSCIF1_SCK,
+
+	/* Port38 */
+	GPIO_FN_SCIFB0_RTS,
+	GPIO_FN_TPU0TO1,
+	GPIO_FN_SCIFB3_RTS_38,
+	GPIO_FN_CHSCIF0_HRTS,
+
+	/* Port39 */
+	GPIO_FN_SCIFB0_CTS,
+	GPIO_FN_TPU0TO2,
+	GPIO_FN_SCIFB3_CTS_39,
+	GPIO_FN_CHSCIF0_HCTS,
+
+	/* Port40 */
+	GPIO_FN_SCIFB0_SCK,
+	GPIO_FN_TPU0TO3,
+	GPIO_FN_SCIFB3_SCK_40,
+	GPIO_FN_CHSCIF0_HSCK,
+
+	/* Port64 */
+	GPIO_FN_PDM0_DATA,
+
+	/* Port65 */
+	GPIO_FN_PDM1_DATA,
+
+	/* Port66 */
+	GPIO_FN_HSI_RX_WAKE,
+	GPIO_FN_SCIFB2_CTS_66,
+	GPIO_FN_MSIOF3_SYNC,
+	GPIO_FN_GenIO4,
+	GPIO_FN_IRQ40,
+
+	/* Port67 */
+	GPIO_FN_HSI_RX_READY,
+	GPIO_FN_SCIFB1_TXD_67,
+	GPIO_FN_GIO_OUT3_67,
+	GPIO_FN_CHSCIF1_HTX,
+
+	/* Port68 */
+	GPIO_FN_HSI_RX_FLAG,
+	GPIO_FN_SCIFB2_TXD_68,
+	GPIO_FN_MSIOF3_TXD,
+	GPIO_FN_GIO_OUT4_68,
+
+	/* Port69 */
+	GPIO_FN_HSI_RX_DATA,
+	GPIO_FN_SCIFB2_RXD_69,
+	GPIO_FN_MSIOF3_RXD,
+	GPIO_FN_GIO_OUT5_69,
+
+	/* Port70 */
+	GPIO_FN_HSI_TX_FLAG,
+	GPIO_FN_SCIFB1_RTS_70,
+	GPIO_FN_GIO_OUT1_70,
+	GPIO_FN_HSIC_TSTCLK0,
+	GPIO_FN_CHSCIF1_HRTS,
+
+	/* Port71 */
+	GPIO_FN_HSI_TX_DATA,
+	GPIO_FN_SCIFB1_CTS_71,
+	GPIO_FN_GIO_OUT2_71,
+	GPIO_FN_HSIC_TSTCLK1,
+	GPIO_FN_CHSCIF1_HCTS,
+
+	/* Port72 */
+	GPIO_FN_HSI_TX_WAKE,
+	GPIO_FN_SCIFB1_RXD_72,
+	GPIO_FN_GenIO8,
+	GPIO_FN_CHSCIF1_HRX,
+
+	/* Port73 */
+	GPIO_FN_HSI_TX_READY,
+	GPIO_FN_SCIFB2_RTS_73,
+	GPIO_FN_MSIOF3_SCK,
+	GPIO_FN_GIO_OUT0_73,
+
+	/* Port74 - Port85 */
+	GPIO_FN_IRDA_OUT,
+	GPIO_FN_IRDA_IN,
+	GPIO_FN_IRDA_FIRSEL,
+	GPIO_FN_TPU0TO0,
+	GPIO_FN_DIGRFEN,
+	GPIO_FN_GPS_TIMESTAMP,
+	GPIO_FN_TXP,
+	GPIO_FN_TXP2,
+	GPIO_FN_COEX_0,
+	GPIO_FN_COEX_1,
+	GPIO_FN_IRQ19,
+	GPIO_FN_IRQ18,
+
+	/* Port96 - Port101 */
+	GPIO_FN_KEYIN0,
+	GPIO_FN_KEYIN1,
+	GPIO_FN_KEYIN2,
+	GPIO_FN_KEYIN3,
+	GPIO_FN_KEYIN4,
+	GPIO_FN_KEYIN5,
+
+	/* Port102 */
+	GPIO_FN_KEYIN6,
+	GPIO_FN_IRQ41,
+
+	/* Port103 */
+	GPIO_FN_KEYIN7,
+	GPIO_FN_IRQ42,
+
+	/* Port104 - Port108 */
+	GPIO_FN_KEYOUT0,
+	GPIO_FN_KEYOUT1,
+	GPIO_FN_KEYOUT2,
+	GPIO_FN_KEYOUT3,
+	GPIO_FN_KEYOUT4,
+
+	/* Port109 */
+	GPIO_FN_KEYOUT5,
+	GPIO_FN_IRQ43,
+
+	/* Port110 */
+	GPIO_FN_KEYOUT6,
+	GPIO_FN_IRQ44,
+
+	/* Port111 */
+	GPIO_FN_KEYOUT7,
+	GPIO_FN_RFANAEN,
+	GPIO_FN_IRQ45,
+
+	/* Port112 */
+	GPIO_FN_KEYIN8,
+	GPIO_FN_KEYOUT8,
+	GPIO_FN_SF_IRQ_04,
+	GPIO_FN_IRQ46,
+
+	/* Port113 */
+	GPIO_FN_KEYIN9,
+	GPIO_FN_KEYOUT9,
+	GPIO_FN_SF_IRQ_05,
+	GPIO_FN_IRQ47,
+
+	/* Port114 */
+	GPIO_FN_KEYIN10,
+	GPIO_FN_KEYOUT10,
+	GPIO_FN_SF_IRQ_06,
+	GPIO_FN_IRQ48,
+
+	/* Port115 */
+	GPIO_FN_KEYIN11,
+	GPIO_FN_KEYOUT11,
+	GPIO_FN_SF_IRQ_07,
+	GPIO_FN_IRQ49,
+
+	/* Port116 */
+	GPIO_FN_SCIFA0_TXD,
+	GPIO_FN_CSCIF0_TX,
+
+	/* Port117 */
+	GPIO_FN_SCIFA0_RXD,
+	GPIO_FN_CSCIF0_RX,
+
+	/* Port118 */
+	GPIO_FN_SCIFA1_TXD,
+	GPIO_FN_CSCIF1_TX,
+
+	/* Port119 */
+	GPIO_FN_SCIFA1_RXD,
+	GPIO_FN_CSCIF1_RX,
+
+	/* Port120 */
+	GPIO_FN_SF_PORT_1_120,
+	GPIO_FN_SCIFB3_RXD_120,
+	GPIO_FN_DU0_CDE,
+
+	/* Port121 */
+	GPIO_FN_SF_PORT_0_121,
+	GPIO_FN_SCIFB3_TXD_121,
+
+	/* Port122 */
+	GPIO_FN_SCIFB0_TXD,
+	GPIO_FN_CHSCIF0_HTX,
+
+	/* Port123 */
+	GPIO_FN_SCIFB0_RXD,
+	GPIO_FN_CHSCIF0_HRX,
+
+	/* Port124 */
+	GPIO_FN_ISP_STROBE_124,
+
+	/* Port125 */
+	GPIO_FN_STP_ISD_0,
+	GPIO_FN_PDM4_CLK_125,
+	GPIO_FN_MSIOF2_TXD,
+	GPIO_FN_SIM0_VOLTSEL0,
+
+	/* Port126 */
+	GPIO_FN_TS_SDEN,
+	GPIO_FN_MSIOF7_SYNC,
+	GPIO_FN_STP_ISEN_1,
+
+	/* Port128 */
+	GPIO_FN_STP_ISEN_0,
+	GPIO_FN_PDM1_OUTDATA_128,
+	GPIO_FN_MSIOF2_SYNC,
+	GPIO_FN_SIM1_VOLTSEL1,
+
+	/* Port129 */
+	GPIO_FN_TS_SPSYNC,
+	GPIO_FN_MSIOF7_RXD,
+	GPIO_FN_STP_ISSYNC_1,
+
+	/* Port130 */
+	GPIO_FN_STP_ISSYNC_0,
+	GPIO_FN_PDM4_DATA_130,
+	GPIO_FN_MSIOF2_RXD,
+	GPIO_FN_SIM0_VOLTSEL1,
+
+	/* Port131 */
+	GPIO_FN_STP_OPWM_0,
+	GPIO_FN_SIM1_PWRON,
+
+	/* Port132 */
+	GPIO_FN_TS_SCK,
+	GPIO_FN_MSIOF7_SCK,
+	GPIO_FN_STP_ISCLK_1,
+
+	/* Port133 */
+	GPIO_FN_STP_ISCLK_0,
+	GPIO_FN_PDM1_OUTCLK_133,
+	GPIO_FN_MSIOF2_SCK,
+	GPIO_FN_SIM1_VOLTSEL0,
+
+	/* Port134 */
+	GPIO_FN_TS_SDAT,
+	GPIO_FN_MSIOF7_TXD,
+	GPIO_FN_STP_ISD_1,
+
+	/* Port160 - Port178 */
+	GPIO_FN_IRQ20,
+	GPIO_FN_IRQ21,
+	GPIO_FN_IRQ22,
+	GPIO_FN_IRQ23,
+	GPIO_FN_MMCD0_0,
+	GPIO_FN_MMCD0_1,
+	GPIO_FN_MMCD0_2,
+	GPIO_FN_MMCD0_3,
+	GPIO_FN_MMCD0_4,
+	GPIO_FN_MMCD0_5,
+	GPIO_FN_MMCD0_6,
+	GPIO_FN_MMCD0_7,
+	GPIO_FN_MMCCMD0,
+	GPIO_FN_MMCCLK0,
+	GPIO_FN_MMCRST,
+	GPIO_FN_IRQ24,
+	GPIO_FN_IRQ25,
+	GPIO_FN_IRQ26,
+	GPIO_FN_IRQ27,
+
+	/* Port192 - Port200 FN1 */
+	GPIO_FN_A10,
+	GPIO_FN_A9,
+	GPIO_FN_A8,
+	GPIO_FN_A7,
+	GPIO_FN_A6,
+	GPIO_FN_A5,
+	GPIO_FN_A4,
+	GPIO_FN_A3,
+	GPIO_FN_A2,
+
+	/* Port192 - Port200 FN2 */
+	GPIO_FN_MMCD1_7,
+	GPIO_FN_MMCD1_6,
+	GPIO_FN_MMCD1_5,
+	GPIO_FN_MMCD1_4,
+	GPIO_FN_MMCD1_3,
+	GPIO_FN_MMCD1_2,
+	GPIO_FN_MMCD1_1,
+	GPIO_FN_MMCD1_0,
+	GPIO_FN_MMCCMD1,
+
+	/* Port192 - Port200 IRQ */
+	GPIO_FN_IRQ31,
+	GPIO_FN_IRQ32,
+	GPIO_FN_IRQ33,
+	GPIO_FN_IRQ34,
+	GPIO_FN_IRQ35,
+	GPIO_FN_IRQ36,
+	GPIO_FN_IRQ37,
+	GPIO_FN_IRQ38,
+	GPIO_FN_IRQ39,
+
+	/* Port201 */
+	GPIO_FN_A1,
+
+	/* Port202 */
+	GPIO_FN_A0,
+	GPIO_FN_BS,
+
+	/* Port203 */
+	GPIO_FN_CKO,
+	GPIO_FN_MMCCLK1,
+
+	/* Port204 */
+	GPIO_FN_CS0_N,
+	GPIO_FN_SIM0_GPO1,
+
+	/* Port205 */
+	GPIO_FN_CS2_N,
+	GPIO_FN_SIM0_GPO2,
+
+	/* Port206 */
+	GPIO_FN_CS4_N,
+	GPIO_FN_VIO_VD,
+	GPIO_FN_SIM1_GPO0,
+
+	/* Port207 - Port212 FN1 */
+	GPIO_FN_D15,
+	GPIO_FN_D14,
+	GPIO_FN_D13,
+	GPIO_FN_D12,
+	GPIO_FN_D11,
+	GPIO_FN_D10,
+
+	/* Port207 - Port212 FN5 */
+	GPIO_FN_GIO_OUT15,
+	GPIO_FN_GIO_OUT14,
+	GPIO_FN_GIO_OUT13,
+	GPIO_FN_GIO_OUT12,
+	GPIO_FN_WGM_TXP2,
+	GPIO_FN_WGM_GPS_TIMEM_ASK_RFCLK,
+
+	/* Port213 - Port222 FN1 */
+	GPIO_FN_D9,
+	GPIO_FN_D8,
+	GPIO_FN_D7,
+	GPIO_FN_D6,
+	GPIO_FN_D5,
+	GPIO_FN_D4,
+	GPIO_FN_D3,
+	GPIO_FN_D2,
+	GPIO_FN_D1,
+	GPIO_FN_D0,
+
+	/* Port213 - Port222 FN2 */
+	GPIO_FN_VIO_D9,
+	GPIO_FN_VIO_D8,
+	GPIO_FN_VIO_D7,
+	GPIO_FN_VIO_D6,
+	GPIO_FN_VIO_D5,
+	GPIO_FN_VIO_D4,
+	GPIO_FN_VIO_D3,
+	GPIO_FN_VIO_D2,
+	GPIO_FN_VIO_D1,
+	GPIO_FN_VIO_D0,
+
+	/* Port213 - Port222 FN5 */
+	GPIO_FN_GIO_OUT9,
+	GPIO_FN_GIO_OUT8,
+	GPIO_FN_GIO_OUT7,
+	GPIO_FN_GIO_OUT6,
+	GPIO_FN_GIO_OUT5_217,
+	GPIO_FN_GIO_OUT4_218,
+	GPIO_FN_GIO_OUT3_219,
+	GPIO_FN_GIO_OUT2_220,
+	GPIO_FN_GIO_OUT1_221,
+	GPIO_FN_GIO_OUT0_222,
+
+	/* Port224 */
+	GPIO_FN_RDWR_224,
+	GPIO_FN_VIO_HD,
+	GPIO_FN_SIM1_GPO2,
+
+	/* Port225 */
+	GPIO_FN_RD_N,
+
+	/* Port226 */
+	GPIO_FN_WAIT_N,
+	GPIO_FN_VIO_CLK,
+	GPIO_FN_SIM1_GPO1,
+
+	/* Port227 */
+	GPIO_FN_WE0_N,
+	GPIO_FN_RDWR_227,
+
+	/* Port228 */
+	GPIO_FN_WE1_N,
+	GPIO_FN_SIM0_GPO0,
+
+	/* Port229 */
+	GPIO_FN_PWMO,
+	GPIO_FN_VIO_CKO1_229,
+
+	/* Port230 */
+	GPIO_FN_SLIM_CLK,
+	GPIO_FN_VIO_CKO4_230,
+
+	/* Port231 */
+	GPIO_FN_SLIM_DATA,
+	GPIO_FN_VIO_CKO5_231,
+
+	/* Port232 */
+	GPIO_FN_VIO_CKO2_232,
+	GPIO_FN_SF_PORT_0_232,
+
+	/* Port233 */
+	GPIO_FN_VIO_CKO3_233,
+	GPIO_FN_SF_PORT_1_233,
+
+	/* Port234 */
+	GPIO_FN_FSIACK,
+	GPIO_FN_PDM3_CLK_234,
+	GPIO_FN_ISP_IRIS1_234,
+
+	/* Port235 */
+	GPIO_FN_FSIAISLD,
+	GPIO_FN_PDM3_DATA_235,
+
+	/* Port236 */
+	GPIO_FN_FSIAOMC,
+	GPIO_FN_PDM0_OUTCLK_236,
+	GPIO_FN_ISP_IRIS0_236,
+
+	/* Port237 */
+	GPIO_FN_FSIAOLR,
+	GPIO_FN_FSIAILR,
+
+	/* Port238 */
+	GPIO_FN_FSIAOBT,
+	GPIO_FN_FSIAIBT,
+
+	/* Port239 */
+	GPIO_FN_FSIAOSLD,
+	GPIO_FN_PDM0_OUTDATA_239,
+
+	/* Port240 */
+	GPIO_FN_FSIBISLD,
+
+	/* Port241 */
+	GPIO_FN_FSIBOLR,
+	GPIO_FN_FSIBILR,
+
+	/* Port242 */
+	GPIO_FN_FSIBOMC,
+	GPIO_FN_ISP_SHUTTER1_242,
+
+	/* Port243 */
+	GPIO_FN_FSIBOBT,
+	GPIO_FN_FSIBIBT,
+
+	/* Port244 */
+	GPIO_FN_FSIBOSLD,
+	GPIO_FN_FSIASPDIF,
+
+	/* Port245 */
+	GPIO_FN_FSIBCK,
+	GPIO_FN_ISP_SHUTTER0_245,
+
+	/* Port246 - Port250 FN1 */
+	GPIO_FN_ISP_IRIS1_246,
+	GPIO_FN_ISP_IRIS0_247,
+	GPIO_FN_ISP_SHUTTER1_248,
+	GPIO_FN_ISP_SHUTTER0_249,
+	GPIO_FN_ISP_STROBE_250,
+
+	/* Port256 - Port258 */
+	GPIO_FN_MSIOF0_SYNC,
+	GPIO_FN_MSIOF0_RXD,
+	GPIO_FN_MSIOF0_SCK,
+
+	/* Port259 */
+	GPIO_FN_MSIOF0_SS2,
+	GPIO_FN_VIO_CKO3_259,
+
+	/* Port260 */
+	GPIO_FN_MSIOF0_TXD,
+
+	/* Port261 */
+	GPIO_FN_SCIFB1_SCK_261,
+	GPIO_FN_CHSCIF1_HSCK,
+
+	/* Port262 */
+	GPIO_FN_SCIFB2_SCK_262,
+
+	/* Port263 - Port266 FN1 */
+	GPIO_FN_MSIOF1_SS2,
+	GPIO_FN_MSIOF1_TXD,
+	GPIO_FN_MSIOF1_RXD,
+	GPIO_FN_MSIOF1_SS1,
+
+	/* Port263 - Port266 FN4 */
+	GPIO_FN_MSIOF5_SS2,
+	GPIO_FN_MSIOF5_TXD,
+	GPIO_FN_MSIOF5_RXD,
+	GPIO_FN_MSIOF5_SS1,
+
+	/* Port267 */
+	GPIO_FN_MSIOF0_SS1,
+
+	/* Port268 */
+	GPIO_FN_MSIOF1_SCK,
+	GPIO_FN_MSIOF5_SCK,
+
+	/* Port269 */
+	GPIO_FN_MSIOF1_SYNC,
+	GPIO_FN_MSIOF5_SYNC,
+
+	/* Port270 - Port273 FN1 */
+	GPIO_FN_MSIOF2_SS1,
+	GPIO_FN_MSIOF2_SS2,
+	GPIO_FN_MSIOF3_SS2,
+	GPIO_FN_MSIOF3_SS1,
+
+	/* Port270 - Port273 FN3 */
+	GPIO_FN_VIO_CKO5_270,
+	GPIO_FN_VIO_CKO2_271,
+	GPIO_FN_VIO_CKO1_272,
+	GPIO_FN_VIO_CKO4_273,
+
+	/* Port274 */
+	GPIO_FN_MSIOF4_SS2,
+	GPIO_FN_TPU1TO0,
+
+	/* Port275 - Port280 */
+	GPIO_FN_IC_DP,
+	GPIO_FN_SIM0_RST,
+	GPIO_FN_IC_DM,
+	GPIO_FN_SIM0_BSICOMP,
+	GPIO_FN_SIM0_CLK,
+	GPIO_FN_SIM0_IO,
+
+	/* Port281 */
+	GPIO_FN_SIM1_IO,
+	GPIO_FN_PDM2_DATA_281,
+
+	/* Port282 */
+	GPIO_FN_SIM1_CLK,
+	GPIO_FN_PDM2_CLK_282,
+
+	/* Port283 */
+	GPIO_FN_SIM1_RST,
+
+	/* Port289 */
+	GPIO_FN_SDHID1_0,
+	GPIO_FN_STMDATA0_2,
+
+	/* Port290 */
+	GPIO_FN_SDHID1_1,
+	GPIO_FN_STMDATA1_2,
+	GPIO_FN_IRQ51,
+
+	/* Port291 - Port294 FN1 */
+	GPIO_FN_SDHID1_2,
+	GPIO_FN_SDHID1_3,
+	GPIO_FN_SDHICLK1,
+	GPIO_FN_SDHICMD1,
+
+	/* Port291 - Port294 FN3 */
+	GPIO_FN_STMDATA2_2,
+	GPIO_FN_STMDATA3_2,
+	GPIO_FN_STMCLK_2,
+	GPIO_FN_STMSIDI_2,
+
+	/* Port295 */
+	GPIO_FN_SDHID2_0,
+	GPIO_FN_MSIOF4_TXD,
+	GPIO_FN_SCIFB2_TXD_295,
+	GPIO_FN_MSIOF6_TXD,
+
+	/* Port296 */
+	GPIO_FN_SDHID2_1,
+	GPIO_FN_MSIOF6_SS2,
+	GPIO_FN_IRQ52,
+
+	/* Port297 - Port300 FN1 */
+	GPIO_FN_SDHID2_2,
+	GPIO_FN_SDHID2_3,
+	GPIO_FN_SDHICLK2,
+	GPIO_FN_SDHICMD2,
+
+	/* Port297 - Port300 FN2 */
+	GPIO_FN_MSIOF4_RXD,
+	GPIO_FN_MSIOF4_SYNC,
+	GPIO_FN_MSIOF4_SCK,
+	GPIO_FN_MSIOF4_SS1,
+
+	/* Port297 - Port300 FN3 */
+	GPIO_FN_SCIFB2_RXD_297,
+	GPIO_FN_SCIFB2_CTS_298,
+	GPIO_FN_SCIFB2_SCK_299,
+	GPIO_FN_SCIFB2_RTS_300,
+
+	/* Port297 - Port300 FN4 */
+	GPIO_FN_MSIOF6_RXD,
+	GPIO_FN_MSIOF6_SYNC,
+	GPIO_FN_MSIOF6_SCK,
+	GPIO_FN_MSIOF6_SS1,
+
+	/* Port301 */
+	GPIO_FN_SDHICD0,
+	GPIO_FN_IRQ50,
+
+	/* Port302 - Port306 FN1 */
+	GPIO_FN_SDHID0_0,
+	GPIO_FN_SDHID0_1,
+	GPIO_FN_SDHID0_2,
+	GPIO_FN_SDHID0_3,
+	GPIO_FN_SDHICMD0,
+
+	/* Port302 - Port306 FN3 */
+	GPIO_FN_STMDATA0_1,
+	GPIO_FN_STMDATA1_1,
+	GPIO_FN_STMDATA2_1,
+	GPIO_FN_STMDATA3_1,
+	GPIO_FN_STMSIDI_1,
+
+	/* Port307 */
+	GPIO_FN_SDHIWP0,
+
+	/* Port308 */
+	GPIO_FN_SDHICLK0,
+	GPIO_FN_STMCLK_1,
+
+	/* Port320 - Port329 */
+	GPIO_FN_IRQ16,
+	GPIO_FN_IRQ17,
+	GPIO_FN_IRQ28,
+	GPIO_FN_IRQ29,
+	GPIO_FN_IRQ30,
+	GPIO_FN_IRQ53,
+	GPIO_FN_IRQ54,
+	GPIO_FN_IRQ55,
+	GPIO_FN_IRQ56,
+	GPIO_FN_IRQ57,
+};
+
 void r8a73a4_add_standard_devices(void);
 void r8a73a4_clock_init(void);
 void r8a73a4_pinmux_init(void);
diff --git a/drivers/pinctrl/sh-pfc/Kconfig b/drivers/pinctrl/sh-pfc/Kconfig
index af16f8f..0e1f99c 100644
--- a/drivers/pinctrl/sh-pfc/Kconfig
+++ b/drivers/pinctrl/sh-pfc/Kconfig
@@ -22,6 +22,11 @@ config GPIO_SH_PFC
 	  This enables support for GPIOs within the SoC's pin function
 	  controller.
 
+config PINCTRL_PFC_R8A73A4
+	def_bool y
+	depends on ARCH_R8A73A4
+	select PINCTRL_SH_PFC
+
 config PINCTRL_PFC_R8A7740
 	def_bool y
 	depends on ARCH_R8A7740
diff --git a/drivers/pinctrl/sh-pfc/Makefile b/drivers/pinctrl/sh-pfc/Makefile
index e8b9562..211cd8e 100644
--- a/drivers/pinctrl/sh-pfc/Makefile
+++ b/drivers/pinctrl/sh-pfc/Makefile
@@ -3,6 +3,7 @@ ifeq ($(CONFIG_GPIO_SH_PFC),y)
 sh-pfc-objs			+= gpio.o
 endif
 obj-$(CONFIG_PINCTRL_SH_PFC)	+= sh-pfc.o
+obj-$(CONFIG_PINCTRL_PFC_R8A73A4)	+= pfc-r8a73a4.o
 obj-$(CONFIG_PINCTRL_PFC_R8A7740)	+= pfc-r8a7740.o
 obj-$(CONFIG_PINCTRL_PFC_R8A7779)	+= pfc-r8a7779.o
 obj-$(CONFIG_PINCTRL_PFC_SH7203)	+= pfc-sh7203.o
diff --git a/drivers/pinctrl/sh-pfc/core.c b/drivers/pinctrl/sh-pfc/core.c
index ced9a95..b551336 100644
--- a/drivers/pinctrl/sh-pfc/core.c
+++ b/drivers/pinctrl/sh-pfc/core.c
@@ -418,6 +418,9 @@ static int sh_pfc_remove(struct platform_device *pdev)
 }
 
 static const struct platform_device_id sh_pfc_id_table[] = {
+#ifdef CONFIG_PINCTRL_PFC_R8A73A4
+	{ "pfc-r8a73a4", (kernel_ulong_t)&r8a73a4_pinmux_info },
+#endif
 #ifdef CONFIG_PINCTRL_PFC_R8A7740
 	{ "pfc-r8a7740", (kernel_ulong_t)&r8a7740_pinmux_info },
 #endif
diff --git a/drivers/pinctrl/sh-pfc/core.h b/drivers/pinctrl/sh-pfc/core.h
index 763d717..89cb428 100644
--- a/drivers/pinctrl/sh-pfc/core.h
+++ b/drivers/pinctrl/sh-pfc/core.h
@@ -54,6 +54,7 @@ void sh_pfc_write_raw_reg(void __iomem *mapped_reg, unsigned long reg_width,
 int sh_pfc_get_pin_index(struct sh_pfc *pfc, unsigned int pin);
 int sh_pfc_config_mux(struct sh_pfc *pfc, unsigned mark, int pinmux_type);
 
+extern const struct sh_pfc_soc_info r8a73a4_pinmux_info;
 extern const struct sh_pfc_soc_info r8a7740_pinmux_info;
 extern const struct sh_pfc_soc_info r8a7779_pinmux_info;
 extern const struct sh_pfc_soc_info sh7203_pinmux_info;
diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a73a4.c b/drivers/pinctrl/sh-pfc/pfc-r8a73a4.c
new file mode 100644
index 0000000..47d75d5
--- /dev/null
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a73a4.c
@@ -0,0 +1,2826 @@
+/*
+ * Copyright (C) 2012-2013  Renesas Solutions Corp.
+ * Copyright (C) 2013  Magnus Damm
+ * Copyright (C) 2012  Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
+ *
+ * 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; version 2 of the
+ * License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
+ */
+#include <linux/kernel.h>
+#include <mach/irqs.h>
+#include <mach/r8a73a4.h>
+
+#include "sh_pfc.h"
+
+#define CPU_ALL_PORT(fn, pfx, sfx)					\
+	/*  Port0 - Port30 */						\
+	PORT_10(fn, pfx, sfx),						\
+	PORT_10(fn, pfx##1, sfx),					\
+	PORT_10(fn, pfx##2, sfx),					\
+	PORT_1(fn,  pfx##30, sfx),					\
+	/* Port32 - Port40 */						\
+	PORT_1(fn,  pfx##32, sfx),	PORT_1(fn,  pfx##33, sfx),	\
+	PORT_1(fn,  pfx##34, sfx),	PORT_1(fn,  pfx##35, sfx),	\
+	PORT_1(fn,  pfx##36, sfx),	PORT_1(fn,  pfx##37, sfx),	\
+	PORT_1(fn,  pfx##38, sfx),	PORT_1(fn,  pfx##39, sfx),	\
+	PORT_1(fn,  pfx##40, sfx),					\
+	/* Port64  - Port85 */						\
+	PORT_1(fn, pfx##64, sfx),	PORT_1(fn, pfx##65, sfx),	\
+	PORT_1(fn, pfx##66, sfx),	PORT_1(fn, pfx##67, sfx),	\
+	PORT_1(fn, pfx##68, sfx),	PORT_1(fn, pfx##69, sfx),	\
+	PORT_10(fn, pfx##7, sfx),					\
+	PORT_1(fn, pfx##80, sfx),	PORT_1(fn, pfx##81, sfx),	\
+	PORT_1(fn, pfx##82, sfx),	PORT_1(fn, pfx##83, sfx),	\
+	PORT_1(fn, pfx##84, sfx),	PORT_1(fn, pfx##85, sfx),	\
+	/* Port96  - Port126 */						\
+	PORT_1(fn, pfx##96, sfx),	PORT_1(fn, pfx##97, sfx),	\
+	PORT_1(fn, pfx##98, sfx),	PORT_1(fn, pfx##99, sfx),	\
+	PORT_10(fn, pfx##10, sfx),					\
+	PORT_10(fn, pfx##11, sfx),					\
+	PORT_1(fn, pfx##120, sfx),	PORT_1(fn, pfx##121, sfx),	\
+	PORT_1(fn, pfx##122, sfx),	PORT_1(fn, pfx##123, sfx),	\
+	PORT_1(fn, pfx##124, sfx),	PORT_1(fn, pfx##125, sfx),	\
+	PORT_1(fn, pfx##126, sfx),					\
+	/* Port128 - Port134 */						\
+	PORT_1(fn, pfx##128, sfx),	PORT_1(fn, pfx##129, sfx),	\
+	PORT_1(fn, pfx##130, sfx),	PORT_1(fn, pfx##131, sfx),	\
+	PORT_1(fn, pfx##132, sfx),	PORT_1(fn, pfx##133, sfx),	\
+	PORT_1(fn, pfx##134, sfx),					\
+	/* Port160 - Port178 */						\
+	PORT_10(fn, pfx##16, sfx),					\
+	PORT_1(fn, pfx##170, sfx),	PORT_1(fn, pfx##171, sfx),	\
+	PORT_1(fn, pfx##172, sfx),	PORT_1(fn, pfx##173, sfx),	\
+	PORT_1(fn, pfx##174, sfx),	PORT_1(fn, pfx##175, sfx),	\
+	PORT_1(fn, pfx##176, sfx),	PORT_1(fn, pfx##177, sfx),	\
+	PORT_1(fn, pfx##178, sfx),					\
+	/* Port192 - Port222 */						\
+	PORT_1(fn, pfx##192, sfx),	PORT_1(fn, pfx##193, sfx),	\
+	PORT_1(fn, pfx##194, sfx),	PORT_1(fn, pfx##195, sfx),	\
+	PORT_1(fn, pfx##196, sfx),	PORT_1(fn, pfx##197, sfx),	\
+	PORT_1(fn, pfx##198, sfx),	PORT_1(fn, pfx##199, sfx),	\
+	PORT_10(fn, pfx##20, sfx),					\
+	PORT_10(fn, pfx##21, sfx),					\
+	PORT_1(fn, pfx##220, sfx),	PORT_1(fn, pfx##221, sfx),	\
+	PORT_1(fn, pfx##222, sfx),					\
+	/* Port224 - Port250 */						\
+	PORT_1(fn, pfx##224, sfx),	PORT_1(fn, pfx##225, sfx),	\
+	PORT_1(fn, pfx##226, sfx),	PORT_1(fn, pfx##227, sfx),	\
+	PORT_1(fn, pfx##228, sfx),	PORT_1(fn, pfx##229, sfx),	\
+	PORT_10(fn, pfx##23, sfx),					\
+	PORT_10(fn, pfx##24, sfx),					\
+	PORT_1(fn, pfx##250, sfx),					\
+	/* Port256 - Port283 */						\
+	PORT_1(fn, pfx##256, sfx),	PORT_1(fn, pfx##257, sfx),	\
+	PORT_1(fn, pfx##258, sfx),	PORT_1(fn, pfx##259, sfx),	\
+	PORT_10(fn, pfx##26, sfx),					\
+	PORT_10(fn, pfx##27, sfx),					\
+	PORT_1(fn, pfx##280, sfx),	PORT_1(fn, pfx##281, sfx),	\
+	PORT_1(fn, pfx##282, sfx),	PORT_1(fn, pfx##283, sfx),	\
+	/* Port288 - Port308 */						\
+	PORT_1(fn, pfx##288, sfx),	PORT_1(fn, pfx##289, sfx),	\
+	PORT_10(fn, pfx##29, sfx),					\
+	PORT_1(fn, pfx##300, sfx),	PORT_1(fn, pfx##301, sfx),	\
+	PORT_1(fn, pfx##302, sfx),	PORT_1(fn, pfx##303, sfx),	\
+	PORT_1(fn, pfx##304, sfx),	PORT_1(fn, pfx##305, sfx),	\
+	PORT_1(fn, pfx##306, sfx),	PORT_1(fn, pfx##307, sfx),	\
+	PORT_1(fn, pfx##308, sfx),					\
+	/* Port320 - Port329 */						\
+	PORT_10(fn, pfx##32, sfx)
+
+
+enum {
+	PINMUX_RESERVED = 0,
+
+	/* PORT0_DATA -> PORT329_DATA */
+	PINMUX_DATA_BEGIN,
+	PORT_ALL(DATA),
+	PINMUX_DATA_END,
+
+	/* PORT0_IN -> PORT329_IN */
+	PINMUX_INPUT_BEGIN,
+	PORT_ALL(IN),
+	PINMUX_INPUT_END,
+
+	/* PORT0_IN_PU -> PORT329_IN_PU */
+	PINMUX_INPUT_PULLUP_BEGIN,
+	PORT_ALL(IN_PU),
+	PINMUX_INPUT_PULLUP_END,
+
+	/* PORT0_IN_PD -> PORT329_IN_PD */
+	PINMUX_INPUT_PULLDOWN_BEGIN,
+	PORT_ALL(IN_PD),
+	PINMUX_INPUT_PULLDOWN_END,
+
+	/* PORT0_OUT -> PORT329_OUT */
+	PINMUX_OUTPUT_BEGIN,
+	PORT_ALL(OUT),
+	PINMUX_OUTPUT_END,
+
+	PINMUX_FUNCTION_BEGIN,
+	PORT_ALL(FN_IN), /* PORT0_FN_IN -> PORT329_FN_IN */
+	PORT_ALL(FN_OUT), /* PORT0_FN_OUT -> PORT329_FN_OUT */
+	PORT_ALL(FN0), /* PORT0_FN0 -> PORT329_FN0 */
+	PORT_ALL(FN1), /* PORT0_FN1 -> PORT329_FN1 */
+	PORT_ALL(FN2), /* PORT0_FN2 -> PORT329_FN2 */
+	PORT_ALL(FN3), /* PORT0_FN3 -> PORT329_FN3 */
+	PORT_ALL(FN4), /* PORT0_FN4 -> PORT329_FN4 */
+	PORT_ALL(FN5), /* PORT0_FN5 -> PORT329_FN5 */
+	PORT_ALL(FN6), /* PORT0_FN6 -> PORT329_FN6 */
+	PORT_ALL(FN7), /* PORT0_FN7 -> PORT329_FN7 */
+
+	MSEL1CR_31_0, MSEL1CR_31_1,
+	MSEL1CR_27_0, MSEL1CR_27_1,
+	MSEL1CR_25_0, MSEL1CR_25_1,
+	MSEL1CR_24_0, MSEL1CR_24_1,
+	MSEL1CR_22_0, MSEL1CR_22_1,
+	MSEL1CR_21_0, MSEL1CR_21_1,
+	MSEL1CR_20_0, MSEL1CR_20_1,
+	MSEL1CR_19_0, MSEL1CR_19_1,
+	MSEL1CR_18_0, MSEL1CR_18_1,
+	MSEL1CR_17_0, MSEL1CR_17_1,
+	MSEL1CR_16_0, MSEL1CR_16_1,
+	MSEL1CR_15_0, MSEL1CR_15_1,
+	MSEL1CR_14_0, MSEL1CR_14_1,
+	MSEL1CR_13_0, MSEL1CR_13_1,
+	MSEL1CR_12_0, MSEL1CR_12_1,
+	MSEL1CR_11_0, MSEL1CR_11_1,
+	MSEL1CR_10_0, MSEL1CR_10_1,
+	MSEL1CR_09_0, MSEL1CR_09_1,
+	MSEL1CR_08_0, MSEL1CR_08_1,
+	MSEL1CR_07_0, MSEL1CR_07_1,
+	MSEL1CR_06_0, MSEL1CR_06_1,
+	MSEL1CR_05_0, MSEL1CR_05_1,
+	MSEL1CR_04_0, MSEL1CR_04_1,
+	MSEL1CR_03_0, MSEL1CR_03_1,
+	MSEL1CR_02_0, MSEL1CR_02_1,
+	MSEL1CR_01_0, MSEL1CR_01_1,
+	MSEL1CR_00_0, MSEL1CR_00_1,
+
+	MSEL3CR_31_0, MSEL3CR_31_1,
+	MSEL3CR_28_0, MSEL3CR_28_1,
+	MSEL3CR_27_0, MSEL3CR_27_1,
+	MSEL3CR_26_0, MSEL3CR_26_1,
+	MSEL3CR_23_0, MSEL3CR_23_1,
+	MSEL3CR_22_0, MSEL3CR_22_1,
+	MSEL3CR_21_0, MSEL3CR_21_1,
+	MSEL3CR_20_0, MSEL3CR_20_1,
+	MSEL3CR_19_0, MSEL3CR_19_1,
+	MSEL3CR_18_0, MSEL3CR_18_1,
+	MSEL3CR_17_0, MSEL3CR_17_1,
+	MSEL3CR_16_0, MSEL3CR_16_1,
+	MSEL3CR_15_0, MSEL3CR_15_1,
+	MSEL3CR_12_0, MSEL3CR_12_1,
+	MSEL3CR_11_0, MSEL3CR_11_1,
+	MSEL3CR_10_0, MSEL3CR_10_1,
+	MSEL3CR_09_0, MSEL3CR_09_1,
+	MSEL3CR_06_0, MSEL3CR_06_1,
+	MSEL3CR_03_0, MSEL3CR_03_1,
+	MSEL3CR_01_0, MSEL3CR_01_1,
+	MSEL3CR_00_0, MSEL3CR_00_1,
+
+	MSEL4CR_30_0, MSEL4CR_30_1,
+	MSEL4CR_29_0, MSEL4CR_29_1,
+	MSEL4CR_28_0, MSEL4CR_28_1,
+	MSEL4CR_27_0, MSEL4CR_27_1,
+	MSEL4CR_26_0, MSEL4CR_26_1,
+	MSEL4CR_25_0, MSEL4CR_25_1,
+	MSEL4CR_24_0, MSEL4CR_24_1,
+	MSEL4CR_23_0, MSEL4CR_23_1,
+	MSEL4CR_22_0, MSEL4CR_22_1,
+	MSEL4CR_21_0, MSEL4CR_21_1,
+	MSEL4CR_20_0, MSEL4CR_20_1,
+	MSEL4CR_19_0, MSEL4CR_19_1,
+	MSEL4CR_18_0, MSEL4CR_18_1,
+	MSEL4CR_17_0, MSEL4CR_17_1,
+	MSEL4CR_16_0, MSEL4CR_16_1,
+	MSEL4CR_15_0, MSEL4CR_15_1,
+	MSEL4CR_14_0, MSEL4CR_14_1,
+	MSEL4CR_13_0, MSEL4CR_13_1,
+	MSEL4CR_12_0, MSEL4CR_12_1,
+	MSEL4CR_11_0, MSEL4CR_11_1,
+	MSEL4CR_10_0, MSEL4CR_10_1,
+	MSEL4CR_09_0, MSEL4CR_09_1,
+	MSEL4CR_07_0, MSEL4CR_07_1,
+	MSEL4CR_04_0, MSEL4CR_04_1,
+	MSEL4CR_01_0, MSEL4CR_01_1,
+
+	MSEL5CR_31_0, MSEL5CR_31_1,
+	MSEL5CR_30_0, MSEL5CR_30_1,
+	MSEL5CR_29_0, MSEL5CR_29_1,
+	MSEL5CR_28_0, MSEL5CR_28_1,
+	MSEL5CR_27_0, MSEL5CR_27_1,
+	MSEL5CR_26_0, MSEL5CR_26_1,
+	MSEL5CR_25_0, MSEL5CR_25_1,
+	MSEL5CR_24_0, MSEL5CR_24_1,
+	MSEL5CR_23_0, MSEL5CR_23_1,
+	MSEL5CR_22_0, MSEL5CR_22_1,
+	MSEL5CR_21_0, MSEL5CR_21_1,
+	MSEL5CR_20_0, MSEL5CR_20_1,
+	MSEL5CR_19_0, MSEL5CR_19_1,
+	MSEL5CR_18_0, MSEL5CR_18_1,
+	MSEL5CR_17_0, MSEL5CR_17_1,
+	MSEL5CR_16_0, MSEL5CR_16_1,
+	MSEL5CR_15_0, MSEL5CR_15_1,
+	MSEL5CR_14_0, MSEL5CR_14_1,
+	MSEL5CR_13_0, MSEL5CR_13_1,
+	MSEL5CR_12_0, MSEL5CR_12_1,
+	MSEL5CR_11_0, MSEL5CR_11_1,
+	MSEL5CR_10_0, MSEL5CR_10_1,
+	MSEL5CR_09_0, MSEL5CR_09_1,
+	MSEL5CR_08_0, MSEL5CR_08_1,
+	MSEL5CR_07_0, MSEL5CR_07_1,
+	MSEL5CR_06_0, MSEL5CR_06_1,
+
+	MSEL8CR_16_0, MSEL8CR_16_1,
+	MSEL8CR_01_0, MSEL8CR_01_1,
+	MSEL8CR_00_0, MSEL8CR_00_1,
+
+	PINMUX_FUNCTION_END,
+
+	PINMUX_MARK_BEGIN,
+
+
+#define F1(a)	a##_MARK
+#define F2(a)	a##_MARK
+#define F3(a)	a##_MARK
+#define F4(a)	a##_MARK
+#define F5(a)	a##_MARK
+#define F6(a)	a##_MARK
+#define F7(a)	a##_MARK
+#define IRQ(a)	IRQ##a##_MARK
+
+	F1(LCDD0), F3(PDM2_CLK_0), F7(DU0_DR0), IRQ(0), /* Port0 */
+	F1(LCDD1), F3(PDM2_DATA_1), F7(DU0_DR19), IRQ(1),
+	F1(LCDD2), F3(PDM3_CLK_2), F7(DU0_DR2), IRQ(2),
+	F1(LCDD3), F3(PDM3_DATA_3), F7(DU0_DR3), IRQ(3),
+	F1(LCDD4), F3(PDM4_CLK_4), F7(DU0_DR4), IRQ(4),
+	F1(LCDD5), F3(PDM4_DATA_5), F7(DU0_DR5), IRQ(5),
+	F1(LCDD6), F3(PDM0_OUTCLK_6), F7(DU0_DR6), IRQ(6),
+	F1(LCDD7), F3(PDM0_OUTDATA_7), F7(DU0_DR7), IRQ(7),
+	F1(LCDD8), F3(PDM1_OUTCLK_8), F7(DU0_DG0), IRQ(8),
+	F1(LCDD9), F3(PDM1_OUTDATA_9), F7(DU0_DG1), IRQ(9),
+	F1(LCDD10), F3(FSICCK), F7(DU0_DG2), IRQ(10), /* Port10 */
+	F1(LCDD11), F3(FSICISLD), F7(DU0_DG3), IRQ(11),
+	F1(LCDD12), F3(FSICOMC), F7(DU0_DG4), IRQ(12),
+	F1(LCDD13), F3(FSICOLR), F4(FSICILR), F7(DU0_DG5), IRQ(13),
+	F1(LCDD14), F3(FSICOBT), F4(FSICIBT), F7(DU0_DG6), IRQ(14),
+	F1(LCDD15), F3(FSICOSLD), F7(DU0_DG7), IRQ(15),
+	F1(LCDD16), F4(TPU1TO1), F7(DU0_DB0),
+	F1(LCDD17), F4(SF_IRQ_00), F7(DU0_DB1),
+	F1(LCDD18), F4(SF_IRQ_01), F7(DU0_DB2),
+	F1(LCDD19), F3(SCIFB3_RTS_19), F7(DU0_DB3),
+	F1(LCDD20), F3(SCIFB3_CTS_20), F7(DU0_DB4), /* Port20 */
+	F1(LCDD21), F3(SCIFB3_TXD_21), F7(DU0_DB5),
+	F1(LCDD22), F3(SCIFB3_RXD_22), F7(DU0_DB6),
+	F1(LCDD23), F3(SCIFB3_SCK_23), F7(DU0_DB7),
+	F1(LCDHSYN), F2(LCDCS), F3(SCIFB1_RTS_24),
+	F7(DU0_EXHSYNC_N_CSYNC_N_HSYNC_N),
+	F1(LCDVSYN), F3(SCIFB1_CTS_25), F7(DU0_EXVSYNC_N_VSYNC_N_CSYNC_N),
+	F1(LCDDCK), F2(LCDWR), F3(SCIFB1_TXD_26), F7(DU0_DOTCLKIN),
+	F1(LCDDISP), F2(LCDRS), F3(SCIFB1_RXD_27), F7(DU0_DOTCLKOUT),
+	F1(LCDRD_N), F3(SCIFB1_SCK_28), F7(DU0_DOTCLKOUTB),
+	F1(LCDLCLK), F4(SF_IRQ_02), F7(DU0_DISP_CSYNC_N_DE),
+	F1(LCDDON), F4(SF_IRQ_03), F7(DU0_ODDF_N_CLAMP), /* Port30 */
+
+	F1(SCIFA0_RTS), F5(SIM0_DET), F7(CSCIF0_RTS), /* Port32 */
+	F1(SCIFA0_CTS), F5(SIM1_DET), F7(CSCIF0_CTS),
+	F1(SCIFA0_SCK), F5(SIM0_PWRON), F7(CSCIF0_SCK),
+	F1(SCIFA1_RTS), F7(CSCIF1_RTS),
+	F1(SCIFA1_CTS), F7(CSCIF1_CTS),
+	F1(SCIFA1_SCK), F7(CSCIF1_SCK),
+	F1(SCIFB0_RTS), F3(TPU0TO1), F4(SCIFB3_RTS_38), F7(CHSCIF0_HRTS),
+	F1(SCIFB0_CTS), F3(TPU0TO2), F4(SCIFB3_CTS_39), F7(CHSCIF0_HCTS),
+	F1(SCIFB0_SCK), F3(TPU0TO3), F4(SCIFB3_SCK_40),
+	F7(CHSCIF0_HSCK), /* Port40 */
+
+	F1(PDM0_DATA), /* Port64 */
+	F1(PDM1_DATA),
+	F1(HSI_RX_WAKE), F2(SCIFB2_CTS_66), F3(MSIOF3_SYNC), F5(GenIO4),
+	IRQ(40),
+	F1(HSI_RX_READY), F2(SCIFB1_TXD_67), F5(GIO_OUT3_67), F7(CHSCIF1_HTX),
+	F1(HSI_RX_FLAG), F2(SCIFB2_TXD_68), F3(MSIOF3_TXD), F5(GIO_OUT4_68),
+	F1(HSI_RX_DATA), F2(SCIFB2_RXD_69), F3(MSIOF3_RXD), F5(GIO_OUT5_69),
+	F1(HSI_TX_FLAG), F2(SCIFB1_RTS_70), F5(GIO_OUT1_70), F6(HSIC_TSTCLK0),
+	F7(CHSCIF1_HRTS), /* Port70 */
+	F1(HSI_TX_DATA), F2(SCIFB1_CTS_71), F5(GIO_OUT2_71), F6(HSIC_TSTCLK1),
+	F7(CHSCIF1_HCTS),
+	F1(HSI_TX_WAKE), F2(SCIFB1_RXD_72), F5(GenIO8), F7(CHSCIF1_HRX),
+	F1(HSI_TX_READY), F2(SCIFB2_RTS_73), F3(MSIOF3_SCK), F5(GIO_OUT0_73),
+	F1(IRDA_OUT), F1(IRDA_IN), F1(IRDA_FIRSEL), F1(TPU0TO0),
+	F1(DIGRFEN), F1(GPS_TIMESTAMP), F1(TXP), /* Port80 */
+	F1(TXP2), F1(COEX_0), F1(COEX_1), IRQ(19), IRQ(18), /* Port85 */
+
+	F1(KEYIN0), /* Port96 */
+	F1(KEYIN1), F1(KEYIN2), F1(KEYIN3), F1(KEYIN4), /* Port100 */
+	F1(KEYIN5), F1(KEYIN6), IRQ(41), F1(KEYIN7), IRQ(42),
+	F2(KEYOUT0), F2(KEYOUT1), F2(KEYOUT2), F2(KEYOUT3),
+	F2(KEYOUT4), F2(KEYOUT5), IRQ(43), F2(KEYOUT6), IRQ(44), /* Port110 */
+	F2(KEYOUT7), F5(RFANAEN), IRQ(45),
+	F1(KEYIN8), F2(KEYOUT8), F4(SF_IRQ_04), IRQ(46),
+	F1(KEYIN9), F2(KEYOUT9), F4(SF_IRQ_05), IRQ(47),
+	F1(KEYIN10), F2(KEYOUT10), F4(SF_IRQ_06), IRQ(48),
+	F1(KEYIN11), F2(KEYOUT11), F4(SF_IRQ_07), IRQ(49),
+	F1(SCIFA0_TXD), F7(CSCIF0_TX), F1(SCIFA0_RXD), F7(CSCIF0_RX),
+	F1(SCIFA1_TXD), F7(CSCIF1_TX), F1(SCIFA1_RXD), F7(CSCIF1_RX),
+	F3(SF_PORT_1_120), F4(SCIFB3_RXD_120), F7(DU0_CDE), /* Port120 */
+	F3(SF_PORT_0_121), F4(SCIFB3_TXD_121),
+	F1(SCIFB0_TXD), F7(CHSCIF0_HTX),
+	F1(SCIFB0_RXD), F7(CHSCIF0_HRX), F3(ISP_STROBE_124),
+	F1(STP_ISD_0), F2(PDM4_CLK_125), F3(MSIOF2_TXD), F5(SIM0_VOLTSEL0),
+	F1(TS_SDEN), F2(MSIOF7_SYNC), F3(STP_ISEN_1),
+	F1(STP_ISEN_0), F2(PDM1_OUTDATA_128), F3(MSIOF2_SYNC),
+	F5(SIM1_VOLTSEL1), F1(TS_SPSYNC), F2(MSIOF7_RXD), F3(STP_ISSYNC_1),
+	F1(STP_ISSYNC_0), F2(PDM4_DATA_130), F3(MSIOF2_RXD),
+	F5(SIM0_VOLTSEL1), /* Port130 */
+	F1(STP_OPWM_0), F5(SIM1_PWRON), F1(TS_SCK), F2(MSIOF7_SCK),
+	F3(STP_ISCLK_1), F1(STP_ISCLK_0), F2(PDM1_OUTCLK_133), F3(MSIOF2_SCK),
+	F5(SIM1_VOLTSEL0), F1(TS_SDAT), F2(MSIOF7_TXD), F3(STP_ISD_1),
+	IRQ(20), /* Port160 */
+	IRQ(21), IRQ(22), IRQ(23),
+	F1(MMCD0_0), F1(MMCD0_1), F1(MMCD0_2), F1(MMCD0_3),
+	F1(MMCD0_4), F1(MMCD0_5), F1(MMCD0_6), /* Port170 */
+	F1(MMCD0_7), F1(MMCCMD0), F1(MMCCLK0), F1(MMCRST),
+	IRQ(24), IRQ(25), IRQ(26), IRQ(27),
+	F1(A10), F2(MMCD1_7), IRQ(31), /* Port192 */
+	F1(A9), F2(MMCD1_6), IRQ(32),
+	F1(A8), F2(MMCD1_5), IRQ(33),
+	F1(A7), F2(MMCD1_4), IRQ(34),
+	F1(A6), F2(MMCD1_3), IRQ(35),
+	F1(A5), F2(MMCD1_2), IRQ(36),
+	F1(A4), F2(MMCD1_1), IRQ(37),
+	F1(A3), F2(MMCD1_0), IRQ(38),
+	F1(A2), F2(MMCCMD1), IRQ(39), /* Port200 */
+	F1(A1),
+	F1(A0), F2(BS),
+	F1(CKO), F2(MMCCLK1),
+	F1(CS0_N), F5(SIM0_GPO1),
+	F1(CS2_N), F5(SIM0_GPO2),
+	F1(CS4_N), F2(VIO_VD), F5(SIM1_GPO0),
+	F1(D15), F5(GIO_OUT15),
+	F1(D14), F5(GIO_OUT14),
+	F1(D13), F5(GIO_OUT13),
+	F1(D12), F5(GIO_OUT12), /* Port210 */
+	F1(D11), F5(WGM_TXP2),
+	F1(D10), F5(WGM_GPS_TIMEM_ASK_RFCLK),
+	F1(D9), F2(VIO_D9), F5(GIO_OUT9),
+	F1(D8), F2(VIO_D8), F5(GIO_OUT8),
+	F1(D7), F2(VIO_D7), F5(GIO_OUT7),
+	F1(D6), F2(VIO_D6), F5(GIO_OUT6),
+	F1(D5), F2(VIO_D5), F5(GIO_OUT5_217),
+	F1(D4), F2(VIO_D4), F5(GIO_OUT4_218),
+	F1(D3), F2(VIO_D3), F5(GIO_OUT3_219),
+	F1(D2), F2(VIO_D2), F5(GIO_OUT2_220), /* Port220 */
+	F1(D1), F2(VIO_D1), F5(GIO_OUT1_221),
+	F1(D0), F2(VIO_D0), F5(GIO_OUT0_222),
+	F1(RDWR_224), F2(VIO_HD), F5(SIM1_GPO2),
+	F1(RD_N), F1(WAIT_N), F2(VIO_CLK), F5(SIM1_GPO1),
+	F1(WE0_N), F2(RDWR_227),
+	F1(WE1_N), F5(SIM0_GPO0),
+	F1(PWMO), F2(VIO_CKO1_229),
+	F1(SLIM_CLK), F2(VIO_CKO4_230), /* Port230 */
+	F1(SLIM_DATA), F2(VIO_CKO5_231), F2(VIO_CKO2_232), F4(SF_PORT_0_232),
+	F2(VIO_CKO3_233), F4(SF_PORT_1_233),
+	F1(FSIACK), F2(PDM3_CLK_234), F3(ISP_IRIS1_234),
+	F1(FSIAISLD), F2(PDM3_DATA_235),
+	F1(FSIAOMC), F2(PDM0_OUTCLK_236), F3(ISP_IRIS0_236),
+	F1(FSIAOLR), F2(FSIAILR), F1(FSIAOBT), F2(FSIAIBT),
+	F1(FSIAOSLD), F2(PDM0_OUTDATA_239),
+	F1(FSIBISLD), /* Port240 */
+	F1(FSIBOLR), F2(FSIBILR), F1(FSIBOMC), F3(ISP_SHUTTER1_242),
+	F1(FSIBOBT), F2(FSIBIBT), F1(FSIBOSLD), F2(FSIASPDIF),
+	F1(FSIBCK), F3(ISP_SHUTTER0_245),
+	F1(ISP_IRIS1_246), F1(ISP_IRIS0_247), F1(ISP_SHUTTER1_248),
+	F1(ISP_SHUTTER0_249), F1(ISP_STROBE_250), /* Port250 */
+	F1(MSIOF0_SYNC), F1(MSIOF0_RXD), F1(MSIOF0_SCK), F1(MSIOF0_SS2),
+	F3(VIO_CKO3_259), F1(MSIOF0_TXD), /* Port260 */
+	F2(SCIFB1_SCK_261), F7(CHSCIF1_HSCK), F2(SCIFB2_SCK_262),
+	F1(MSIOF1_SS2), F4(MSIOF5_SS2), F1(MSIOF1_TXD), F4(MSIOF5_TXD),
+	F1(MSIOF1_RXD), F4(MSIOF5_RXD), F1(MSIOF1_SS1), F4(MSIOF5_SS1),
+	F1(MSIOF0_SS1), F1(MSIOF1_SCK), F4(MSIOF5_SCK),
+	F1(MSIOF1_SYNC), F4(MSIOF5_SYNC),
+	F1(MSIOF2_SS1), F3(VIO_CKO5_270), /* Port270 */
+	F1(MSIOF2_SS2), F3(VIO_CKO2_271), F1(MSIOF3_SS2), F3(VIO_CKO1_272),
+	F1(MSIOF3_SS1), F3(VIO_CKO4_273), F1(MSIOF4_SS2), F4(TPU1TO0),
+	F1(IC_DP), F1(SIM0_RST), F1(IC_DM), F1(SIM0_BSICOMP),
+	F1(SIM0_CLK), F1(SIM0_IO), /* Port280 */
+	F1(SIM1_IO), F2(PDM2_DATA_281), F1(SIM1_CLK), F2(PDM2_CLK_282),
+	F1(SIM1_RST), F1(SDHID1_0), F3(STMDATA0_2),
+	F1(SDHID1_1), F3(STMDATA1_2), IRQ(51), /* Port290 */
+	F1(SDHID1_2), F3(STMDATA2_2), F1(SDHID1_3), F3(STMDATA3_2),
+	F1(SDHICLK1), F3(STMCLK_2), F1(SDHICMD1), F3(STMSIDI_2),
+	F1(SDHID2_0), F2(MSIOF4_TXD), F3(SCIFB2_TXD_295), F4(MSIOF6_TXD),
+	F1(SDHID2_1), F4(MSIOF6_SS2), IRQ(52),
+	F1(SDHID2_2), F2(MSIOF4_RXD), F3(SCIFB2_RXD_297), F4(MSIOF6_RXD),
+	F1(SDHID2_3), F2(MSIOF4_SYNC), F3(SCIFB2_CTS_298), F4(MSIOF6_SYNC),
+	F1(SDHICLK2), F2(MSIOF4_SCK), F3(SCIFB2_SCK_299), F4(MSIOF6_SCK),
+	F1(SDHICMD2), F2(MSIOF4_SS1), F3(SCIFB2_RTS_300),
+	F4(MSIOF6_SS1), /* Port300 */
+	F1(SDHICD0), IRQ(50), F1(SDHID0_0), F3(STMDATA0_1),
+	F1(SDHID0_1), F3(STMDATA1_1), F1(SDHID0_2), F3(STMDATA2_1),
+	F1(SDHID0_3), F3(STMDATA3_1), F1(SDHICMD0), F3(STMSIDI_1),
+	F1(SDHIWP0), F1(SDHICLK0), F3(STMCLK_1), IRQ(16), /* Port320 */
+	IRQ(17), IRQ(28), IRQ(29), IRQ(30), IRQ(53), IRQ(54),
+	IRQ(55), IRQ(56), IRQ(57),
+	PINMUX_MARK_END,
+};
+
+static const pinmux_enum_t pinmux_data[] = {
+	/* specify valid pin states for each pin in GPIO mode */
+
+	PORT_DATA_IO_PU_PD(0), PORT_DATA_IO_PU_PD(1),
+	PORT_DATA_IO_PU_PD(2), PORT_DATA_IO_PU_PD(3),
+	PORT_DATA_IO_PU_PD(4), PORT_DATA_IO_PU_PD(5),
+	PORT_DATA_IO_PU_PD(6), PORT_DATA_IO_PU_PD(7),
+	PORT_DATA_IO_PU_PD(8), PORT_DATA_IO_PU_PD(9),
+
+	PORT_DATA_IO_PU_PD(10), PORT_DATA_IO_PU_PD(11),
+	PORT_DATA_IO_PU_PD(12), PORT_DATA_IO_PU_PD(13),
+	PORT_DATA_IO_PU_PD(14),	PORT_DATA_IO_PU_PD(15),
+	PORT_DATA_IO_PU_PD(16), PORT_DATA_IO_PU_PD(17),
+	PORT_DATA_IO_PU_PD(18), PORT_DATA_IO_PU_PD(19),
+
+	PORT_DATA_IO_PU_PD(20), PORT_DATA_IO_PU_PD(21),
+	PORT_DATA_IO_PU_PD(22), PORT_DATA_IO_PU_PD(23),
+	PORT_DATA_IO_PU_PD(24),	PORT_DATA_IO_PU_PD(25),
+	PORT_DATA_IO_PU_PD(26), PORT_DATA_IO_PU_PD(27),
+	PORT_DATA_IO_PU_PD(28), PORT_DATA_IO_PU_PD(29),
+
+	PORT_DATA_IO_PU_PD(30), PORT_DATA_IO_PU_PD(32),
+	PORT_DATA_IO_PU_PD(33), PORT_DATA_IO_PU_PD(34),
+	PORT_DATA_IO_PU_PD(35), PORT_DATA_IO_PU_PD(36),
+	PORT_DATA_IO_PU_PD(37), PORT_DATA_IO_PU_PD(38),
+	PORT_DATA_IO_PU_PD(39), PORT_DATA_IO_PU_PD(40),
+
+	PORT_DATA_IO_PU_PD(64),	PORT_DATA_IO_PU_PD(65),
+	PORT_DATA_IO_PU_PD(66), PORT_DATA_IO_PU_PD(67),
+	PORT_DATA_IO_PU_PD(68), PORT_DATA_IO_PU_PD(69),
+
+	PORT_DATA_IO_PU_PD(70), PORT_DATA_IO_PU_PD(71),
+	PORT_DATA_IO_PU_PD(72), PORT_DATA_IO_PU_PD(73),
+	PORT_DATA_O(74), PORT_DATA_IO_PU_PD(75),
+	PORT_DATA_IO_PU_PD(76), PORT_DATA_IO_PU_PD(77),
+	PORT_DATA_IO_PU_PD(78), PORT_DATA_IO_PU_PD(79),
+
+	PORT_DATA_IO_PU_PD(80), PORT_DATA_IO_PU_PD(81),
+	PORT_DATA_IO_PU_PD(82), PORT_DATA_IO_PU_PD(83),
+	PORT_DATA_IO_PU_PD(84), PORT_DATA_IO_PU_PD(85),
+
+	PORT_DATA_IO_PU_PD(96), PORT_DATA_IO_PU_PD(97),
+	PORT_DATA_IO_PU_PD(98), PORT_DATA_IO_PU_PD(99),
+
+	PORT_DATA_IO_PU_PD(100), PORT_DATA_IO_PU_PD(101),
+	PORT_DATA_IO_PU_PD(102), PORT_DATA_IO_PU_PD(103),
+	PORT_DATA_IO_PU_PD(104), PORT_DATA_IO_PU_PD(105),
+	PORT_DATA_IO_PU_PD(106), PORT_DATA_IO_PU_PD(107),
+	PORT_DATA_IO_PU_PD(108), PORT_DATA_IO_PU_PD(109),
+
+	PORT_DATA_IO_PU_PD(110), PORT_DATA_IO_PU_PD(111),
+	PORT_DATA_IO_PU_PD(112), PORT_DATA_IO_PU_PD(113),
+	PORT_DATA_IO_PU_PD(114), PORT_DATA_IO_PU_PD(115),
+	PORT_DATA_IO_PU_PD(116), PORT_DATA_IO_PU_PD(117),
+	PORT_DATA_IO_PU_PD(118), PORT_DATA_IO_PU_PD(119),
+
+	PORT_DATA_IO_PU_PD(120), PORT_DATA_IO_PU_PD(121),
+	PORT_DATA_IO_PU_PD(122), PORT_DATA_IO_PU_PD(123),
+	PORT_DATA_IO_PU_PD(124), PORT_DATA_IO_PU_PD(125),
+	PORT_DATA_IO_PU_PD(126),
+	PORT_DATA_IO_PU_PD(128), PORT_DATA_IO_PU_PD(129),
+
+	PORT_DATA_IO_PU_PD(130), PORT_DATA_IO_PU_PD(131),
+	PORT_DATA_IO_PU_PD(132), PORT_DATA_IO_PU_PD(133),
+	PORT_DATA_IO_PU_PD(134),
+
+	PORT_DATA_IO_PU_PD(160), PORT_DATA_IO_PU_PD(161),
+	PORT_DATA_IO_PU_PD(162), PORT_DATA_IO_PU_PD(163),
+	PORT_DATA_IO_PU_PD(164), PORT_DATA_IO_PU_PD(165),
+	PORT_DATA_IO_PU_PD(166), PORT_DATA_IO_PU_PD(167),
+	PORT_DATA_IO_PU_PD(168), PORT_DATA_IO_PU_PD(169),
+
+	PORT_DATA_IO_PU_PD(170), PORT_DATA_IO_PU_PD(171),
+	PORT_DATA_IO_PU_PD(172), PORT_DATA_IO_PU_PD(173),
+	PORT_DATA_IO_PU_PD(174), PORT_DATA_IO_PU_PD(175),
+	PORT_DATA_IO_PU_PD(176), PORT_DATA_IO_PU_PD(177),
+	PORT_DATA_IO_PU_PD(178),
+
+	PORT_DATA_IO_PU_PD(192), PORT_DATA_IO_PU_PD(193),
+	PORT_DATA_IO_PU_PD(194), PORT_DATA_IO_PU_PD(195),
+	PORT_DATA_IO_PU_PD(196), PORT_DATA_IO_PU_PD(197),
+	PORT_DATA_IO_PU_PD(198), PORT_DATA_IO_PU_PD(199),
+
+	PORT_DATA_IO_PU_PD(200), PORT_DATA_IO_PU_PD(201),
+	PORT_DATA_IO_PU_PD(202), PORT_DATA_IO_PU_PD(203),
+	PORT_DATA_IO_PU_PD(204), PORT_DATA_IO_PU_PD(205),
+	PORT_DATA_IO_PU_PD(206), PORT_DATA_IO_PU_PD(207),
+	PORT_DATA_IO_PU_PD(208), PORT_DATA_IO_PU_PD(209),
+
+	PORT_DATA_IO_PU_PD(210), PORT_DATA_IO_PU_PD(211),
+	PORT_DATA_IO_PU_PD(212), PORT_DATA_IO_PU_PD(213),
+	PORT_DATA_IO_PU_PD(214), PORT_DATA_IO_PU_PD(215),
+	PORT_DATA_IO_PU_PD(216), PORT_DATA_IO_PU_PD(217),
+	PORT_DATA_IO_PU_PD(218), PORT_DATA_IO_PU_PD(219),
+
+	PORT_DATA_IO_PU_PD(220), PORT_DATA_IO_PU_PD(221),
+	PORT_DATA_IO_PU_PD(222), PORT_DATA_IO_PU_PD(224),
+	PORT_DATA_IO_PU_PD(225), PORT_DATA_IO_PU_PD(226),
+	PORT_DATA_IO_PU_PD(227), PORT_DATA_IO_PU_PD(228),
+	PORT_DATA_IO_PU_PD(229),
+
+	PORT_DATA_IO_PU_PD(230), PORT_DATA_IO_PU_PD(231),
+	PORT_DATA_IO_PU_PD(232), PORT_DATA_IO_PU_PD(233),
+	PORT_DATA_IO_PU_PD(234), PORT_DATA_IO_PU_PD(235),
+	PORT_DATA_IO_PU_PD(236), PORT_DATA_IO_PU_PD(237),
+	PORT_DATA_IO_PU_PD(238), PORT_DATA_IO_PU_PD(239),
+
+	PORT_DATA_IO_PU_PD(240), PORT_DATA_IO_PU_PD(241),
+	PORT_DATA_IO_PU_PD(242), PORT_DATA_IO_PU_PD(243),
+	PORT_DATA_IO_PU_PD(244), PORT_DATA_IO_PU_PD(245),
+	PORT_DATA_IO_PU_PD(246), PORT_DATA_IO_PU_PD(247),
+	PORT_DATA_IO_PU_PD(248), PORT_DATA_IO_PU_PD(249),
+
+	PORT_DATA_IO_PU_PD(250),
+	PORT_DATA_IO_PU_PD(256), PORT_DATA_IO_PU_PD(257),
+	PORT_DATA_IO_PU_PD(258), PORT_DATA_IO_PU_PD(259),
+
+	PORT_DATA_IO_PU_PD(260), PORT_DATA_IO_PU_PD(261),
+	PORT_DATA_IO_PU_PD(262), PORT_DATA_IO_PU_PD(263),
+	PORT_DATA_IO_PU_PD(264), PORT_DATA_IO_PU_PD(265),
+	PORT_DATA_IO_PU_PD(266), PORT_DATA_IO_PU_PD(267),
+	PORT_DATA_IO_PU_PD(268), PORT_DATA_IO_PU_PD(269),
+
+	PORT_DATA_IO_PU_PD(270), PORT_DATA_IO_PU_PD(271),
+	PORT_DATA_IO_PU_PD(272), PORT_DATA_IO_PU_PD(273),
+	PORT_DATA_IO_PU_PD(274), PORT_DATA_IO_PU_PD(275),
+	PORT_DATA_IO_PU_PD(276), PORT_DATA_IO_PU_PD(277),
+	PORT_DATA_IO_PU_PD(278), PORT_DATA_IO_PU_PD(279),
+
+	PORT_DATA_IO_PU_PD(280), PORT_DATA_IO_PU_PD(281),
+	PORT_DATA_IO_PU_PD(282), PORT_DATA_IO_PU_PD(283),
+	PORT_DATA_O(288), PORT_DATA_IO_PU_PD(289),
+
+	PORT_DATA_IO_PU_PD(290), PORT_DATA_IO_PU_PD(291),
+	PORT_DATA_IO_PU_PD(292), PORT_DATA_IO_PU_PD(293),
+	PORT_DATA_IO_PU_PD(294), PORT_DATA_IO_PU_PD(295),
+	PORT_DATA_IO_PU_PD(296), PORT_DATA_IO_PU_PD(297),
+	PORT_DATA_IO_PU_PD(298), PORT_DATA_IO_PU_PD(299),
+
+	PORT_DATA_IO_PU_PD(300), PORT_DATA_IO_PU_PD(301),
+	PORT_DATA_IO_PU_PD(302), PORT_DATA_IO_PU_PD(303),
+	PORT_DATA_IO_PU_PD(304), PORT_DATA_IO_PU_PD(305),
+	PORT_DATA_IO_PU_PD(306), PORT_DATA_IO_PU_PD(307),
+	PORT_DATA_IO_PU_PD(308),
+
+	PORT_DATA_IO_PU_PD(320), PORT_DATA_IO_PU_PD(321),
+	PORT_DATA_IO_PU_PD(322), PORT_DATA_IO_PU_PD(323),
+	PORT_DATA_IO_PU_PD(324), PORT_DATA_IO_PU_PD(325),
+	PORT_DATA_IO_PU_PD(326), PORT_DATA_IO_PU_PD(327),
+	PORT_DATA_IO_PU_PD(328), PORT_DATA_IO_PU_PD(329),
+
+	/* Port0 */
+	PINMUX_DATA(LCDD0_MARK,		PORT0_FN1),
+	PINMUX_DATA(PDM2_CLK_0_MARK,	PORT0_FN3),
+	PINMUX_DATA(DU0_DR0_MARK,	PORT0_FN7),
+	PINMUX_DATA(IRQ0_MARK,		PORT0_FN0),
+
+	/* Port1 */
+	PINMUX_DATA(LCDD1_MARK,		PORT1_FN1),
+	PINMUX_DATA(PDM2_DATA_1_MARK,	PORT1_FN3,	MSEL3CR_12_0),
+	PINMUX_DATA(DU0_DR19_MARK,	PORT1_FN7),
+	PINMUX_DATA(IRQ1_MARK,		PORT1_FN0),
+
+	/* Port2 */
+	PINMUX_DATA(LCDD2_MARK,		PORT2_FN1),
+	PINMUX_DATA(PDM3_CLK_2_MARK,	PORT2_FN3),
+	PINMUX_DATA(DU0_DR2_MARK,	PORT2_FN7),
+	PINMUX_DATA(IRQ2_MARK,		PORT2_FN0),
+
+	/* Port3 */
+	PINMUX_DATA(LCDD3_MARK,		PORT3_FN1),
+	PINMUX_DATA(PDM3_DATA_3_MARK,	PORT3_FN3,	MSEL3CR_12_0),
+	PINMUX_DATA(DU0_DR3_MARK,	PORT3_FN7),
+	PINMUX_DATA(IRQ3_MARK,		PORT3_FN0),
+
+	/* Port4 */
+	PINMUX_DATA(LCDD4_MARK,		PORT4_FN1),
+	PINMUX_DATA(PDM4_CLK_4_MARK,	PORT4_FN3),
+	PINMUX_DATA(DU0_DR4_MARK,	PORT4_FN7),
+	PINMUX_DATA(IRQ4_MARK,		PORT4_FN0),
+
+	/* Port5 */
+	PINMUX_DATA(LCDD5_MARK,		PORT5_FN1),
+	PINMUX_DATA(PDM4_DATA_5_MARK,	PORT5_FN3,	MSEL3CR_12_0),
+	PINMUX_DATA(DU0_DR5_MARK,	PORT5_FN7),
+	PINMUX_DATA(IRQ5_MARK,		PORT5_FN0),
+
+	/* Port6 */
+	PINMUX_DATA(LCDD6_MARK,		PORT6_FN1),
+	PINMUX_DATA(PDM0_OUTCLK_6_MARK,	PORT6_FN3),
+	PINMUX_DATA(DU0_DR6_MARK,	PORT6_FN7),
+	PINMUX_DATA(IRQ6_MARK,		PORT6_FN0),
+
+	/* Port7 */
+	PINMUX_DATA(LCDD7_MARK,			PORT7_FN1),
+	PINMUX_DATA(PDM0_OUTDATA_7_MARK,	PORT7_FN3),
+	PINMUX_DATA(DU0_DR7_MARK,		PORT7_FN7),
+	PINMUX_DATA(IRQ7_MARK,			PORT7_FN0),
+
+	/* Port8 */
+	PINMUX_DATA(LCDD8_MARK,		PORT8_FN1),
+	PINMUX_DATA(PDM1_OUTCLK_8_MARK,	PORT8_FN3),
+	PINMUX_DATA(DU0_DG0_MARK,	PORT8_FN7),
+	PINMUX_DATA(IRQ8_MARK,		PORT8_FN0),
+
+	/* Port9 */
+	PINMUX_DATA(LCDD9_MARK,		PORT9_FN1),
+	PINMUX_DATA(PDM1_OUTDATA_9_MARK, PORT9_FN3),
+	PINMUX_DATA(DU0_DG1_MARK,	PORT9_FN7),
+	PINMUX_DATA(IRQ9_MARK,		PORT9_FN0),
+
+	/* Port10 */
+	PINMUX_DATA(LCDD10_MARK,		PORT10_FN1),
+	PINMUX_DATA(FSICCK_MARK,		PORT10_FN3),
+	PINMUX_DATA(DU0_DG2_MARK,		PORT10_FN7),
+	PINMUX_DATA(IRQ10_MARK,			PORT10_FN0),
+
+	/* Port11 */
+	PINMUX_DATA(LCDD11_MARK,		PORT11_FN1),
+	PINMUX_DATA(FSICISLD_MARK,		PORT11_FN3),
+	PINMUX_DATA(DU0_DG3_MARK,		PORT11_FN7),
+	PINMUX_DATA(IRQ11_MARK,			PORT11_FN0),
+
+	/* Port12 */
+	PINMUX_DATA(LCDD12_MARK,		PORT12_FN1),
+	PINMUX_DATA(FSICOMC_MARK,		PORT12_FN3),
+	PINMUX_DATA(DU0_DG4_MARK,		PORT12_FN7),
+	PINMUX_DATA(IRQ12_MARK,			PORT12_FN0),
+
+	/* Port13 */
+	PINMUX_DATA(LCDD13_MARK,		PORT13_FN1),
+	PINMUX_DATA(FSICOLR_MARK,		PORT13_FN3),
+	PINMUX_DATA(FSICILR_MARK,		PORT13_FN4),
+	PINMUX_DATA(DU0_DG5_MARK,		PORT13_FN7),
+	PINMUX_DATA(IRQ13_MARK,			PORT13_FN0),
+
+	/* Port14 */
+	PINMUX_DATA(LCDD14_MARK,		PORT14_FN1),
+	PINMUX_DATA(FSICOBT_MARK,		PORT14_FN3),
+	PINMUX_DATA(FSICIBT_MARK,		PORT14_FN4),
+	PINMUX_DATA(DU0_DG6_MARK,		PORT14_FN7),
+	PINMUX_DATA(IRQ14_MARK,			PORT14_FN0),
+
+	/* Port15 */
+	PINMUX_DATA(LCDD15_MARK,		PORT15_FN1),
+	PINMUX_DATA(FSICOSLD_MARK,		PORT15_FN3),
+	PINMUX_DATA(DU0_DG7_MARK,		PORT15_FN7),
+	PINMUX_DATA(IRQ15_MARK,			PORT15_FN0),
+
+	/* Port16 */
+	PINMUX_DATA(LCDD16_MARK,		PORT16_FN1),
+	PINMUX_DATA(TPU1TO1_MARK,		PORT16_FN4),
+	PINMUX_DATA(DU0_DB0_MARK,		PORT16_FN7),
+
+	/* Port17 */
+	PINMUX_DATA(LCDD17_MARK,		PORT17_FN1),
+	PINMUX_DATA(SF_IRQ_00_MARK,		PORT17_FN4),
+	PINMUX_DATA(DU0_DB1_MARK,		PORT17_FN7),
+
+	/* Port18 */
+	PINMUX_DATA(LCDD18_MARK,		PORT18_FN1),
+	PINMUX_DATA(SF_IRQ_01_MARK,		PORT18_FN4),
+	PINMUX_DATA(DU0_DB2_MARK,		PORT18_FN7),
+
+	/* Port19 */
+	PINMUX_DATA(LCDD19_MARK,		PORT19_FN1),
+	PINMUX_DATA(SCIFB3_RTS_19_MARK,		PORT19_FN3),
+	PINMUX_DATA(DU0_DB3_MARK,		PORT19_FN7),
+
+	/* Port20 */
+	PINMUX_DATA(LCDD20_MARK,		PORT20_FN1),
+	PINMUX_DATA(SCIFB3_CTS_20_MARK,		PORT20_FN3,	MSEL3CR_09_0),
+	PINMUX_DATA(DU0_DB4_MARK,		PORT20_FN7),
+
+	/* Port21 */
+	PINMUX_DATA(LCDD21_MARK,		PORT21_FN1),
+	PINMUX_DATA(SCIFB3_TXD_21_MARK,		PORT21_FN3,	MSEL3CR_09_0),
+	PINMUX_DATA(DU0_DB5_MARK,		PORT21_FN7),
+
+	/* Port22 */
+	PINMUX_DATA(LCDD22_MARK,		PORT22_FN1),
+	PINMUX_DATA(SCIFB3_RXD_22_MARK,		PORT22_FN3,	MSEL3CR_09_0),
+	PINMUX_DATA(DU0_DB6_MARK,		PORT22_FN7),
+
+	/* Port23 */
+	PINMUX_DATA(LCDD23_MARK,		PORT23_FN1),
+	PINMUX_DATA(SCIFB3_SCK_23_MARK,		PORT23_FN3),
+	PINMUX_DATA(DU0_DB7_MARK,		PORT23_FN7),
+
+	/* Port24 */
+	PINMUX_DATA(LCDHSYN_MARK,			PORT24_FN1),
+	PINMUX_DATA(LCDCS_MARK,				PORT24_FN2),
+	PINMUX_DATA(SCIFB1_RTS_24_MARK,			PORT24_FN3),
+	PINMUX_DATA(DU0_EXHSYNC_N_CSYNC_N_HSYNC_N_MARK,	PORT24_FN7),
+
+	/* Port25 */
+	PINMUX_DATA(LCDVSYN_MARK,			PORT25_FN1),
+	PINMUX_DATA(SCIFB1_CTS_25_MARK, PORT25_FN3, MSEL3CR_11_0),
+	PINMUX_DATA(DU0_EXVSYNC_N_VSYNC_N_CSYNC_N_MARK,	PORT25_FN7),
+
+	/* Port26 */
+	PINMUX_DATA(LCDDCK_MARK,		PORT26_FN1),
+	PINMUX_DATA(LCDWR_MARK,			PORT26_FN2),
+	PINMUX_DATA(SCIFB1_TXD_26_MARK,		PORT26_FN3,	MSEL3CR_11_0),
+	PINMUX_DATA(DU0_DOTCLKIN_MARK,		PORT26_FN7),
+
+	/* Port27 */
+	PINMUX_DATA(LCDDISP_MARK,		PORT27_FN1),
+	PINMUX_DATA(LCDRS_MARK,			PORT27_FN2),
+	PINMUX_DATA(SCIFB1_RXD_27_MARK,		PORT27_FN3,	MSEL3CR_11_0),
+	PINMUX_DATA(DU0_DOTCLKOUT_MARK,		PORT27_FN7),
+
+	/* Port28 */
+	PINMUX_DATA(LCDRD_N_MARK,		PORT28_FN1),
+	PINMUX_DATA(SCIFB1_SCK_28_MARK,		PORT28_FN3),
+	PINMUX_DATA(DU0_DOTCLKOUTB_MARK,	PORT28_FN7),
+
+	/* Port29 */
+	PINMUX_DATA(LCDLCLK_MARK,		PORT29_FN1),
+	PINMUX_DATA(SF_IRQ_02_MARK,		PORT29_FN4),
+	PINMUX_DATA(DU0_DISP_CSYNC_N_DE_MARK,	PORT29_FN7),
+
+	/* Port30 */
+	PINMUX_DATA(LCDDON_MARK,		PORT30_FN1),
+	PINMUX_DATA(SF_IRQ_03_MARK,		PORT30_FN4),
+	PINMUX_DATA(DU0_ODDF_N_CLAMP_MARK,	PORT30_FN7),
+
+	/* Port32 */
+	PINMUX_DATA(SCIFA0_RTS_MARK,		PORT32_FN1),
+	PINMUX_DATA(SIM0_DET_MARK,		PORT32_FN5),
+	PINMUX_DATA(CSCIF0_RTS_MARK,		PORT32_FN7),
+
+	/* Port33 */
+	PINMUX_DATA(SCIFA0_CTS_MARK,		PORT33_FN1),
+	PINMUX_DATA(SIM1_DET_MARK,		PORT33_FN5),
+	PINMUX_DATA(CSCIF0_CTS_MARK,		PORT33_FN7),
+
+	/* Port34 */
+	PINMUX_DATA(SCIFA0_SCK_MARK,		PORT34_FN1),
+	PINMUX_DATA(SIM0_PWRON_MARK,		PORT34_FN5),
+	PINMUX_DATA(CSCIF0_SCK_MARK,		PORT34_FN7),
+
+	/* Port35 */
+	PINMUX_DATA(SCIFA1_RTS_MARK,		PORT35_FN1),
+	PINMUX_DATA(CSCIF1_RTS_MARK,		PORT35_FN7),
+
+	/* Port36 */
+	PINMUX_DATA(SCIFA1_CTS_MARK,		PORT36_FN1),
+	PINMUX_DATA(CSCIF1_CTS_MARK,		PORT36_FN7),
+
+	/* Port37 */
+	PINMUX_DATA(SCIFA1_SCK_MARK,		PORT37_FN1),
+	PINMUX_DATA(CSCIF1_SCK_MARK,		PORT37_FN7),
+
+	/* Port38 */
+	PINMUX_DATA(SCIFB0_RTS_MARK,		PORT38_FN1),
+	PINMUX_DATA(TPU0TO1_MARK,		PORT38_FN3),
+	PINMUX_DATA(SCIFB3_RTS_38_MARK,		PORT38_FN4),
+	PINMUX_DATA(CHSCIF0_HRTS_MARK,		PORT38_FN7),
+
+	/* Port39 */
+	PINMUX_DATA(SCIFB0_CTS_MARK,		PORT39_FN1),
+	PINMUX_DATA(TPU0TO2_MARK,		PORT39_FN3),
+	PINMUX_DATA(SCIFB3_CTS_39_MARK,		PORT39_FN4,	MSEL3CR_09_1),
+	PINMUX_DATA(CHSCIF0_HCTS_MARK,		PORT39_FN7),
+
+	/* Port40 */
+	PINMUX_DATA(SCIFB0_SCK_MARK,		PORT40_FN1),
+	PINMUX_DATA(TPU0TO3_MARK,		PORT40_FN3),
+	PINMUX_DATA(SCIFB3_SCK_40_MARK,		PORT40_FN4),
+	PINMUX_DATA(CHSCIF0_HSCK_MARK,		PORT40_FN7),
+
+	/* Port64 */
+	PINMUX_DATA(PDM0_DATA_MARK,		PORT64_FN1),
+
+	/* Port65 */
+	PINMUX_DATA(PDM1_DATA_MARK,		PORT65_FN1),
+
+	/* Port66 */
+	PINMUX_DATA(HSI_RX_WAKE_MARK,		PORT66_FN1),
+	PINMUX_DATA(SCIFB2_CTS_66_MARK,		PORT66_FN2,	MSEL3CR_10_0),
+	PINMUX_DATA(MSIOF3_SYNC_MARK,		PORT66_FN3),
+	PINMUX_DATA(GenIO4_MARK,		PORT66_FN5),
+	PINMUX_DATA(IRQ40_MARK,			PORT66_FN0),
+
+	/* Port67 */
+	PINMUX_DATA(HSI_RX_READY_MARK,		PORT67_FN1),
+	PINMUX_DATA(SCIFB1_TXD_67_MARK,		PORT67_FN2,	MSEL3CR_11_1),
+	PINMUX_DATA(GIO_OUT3_67_MARK,		PORT67_FN5),
+	PINMUX_DATA(CHSCIF1_HTX_MARK,		PORT67_FN7),
+
+	/* Port68 */
+	PINMUX_DATA(HSI_RX_FLAG_MARK,		PORT68_FN1),
+	PINMUX_DATA(SCIFB2_TXD_68_MARK,		PORT68_FN2,	MSEL3CR_10_0),
+	PINMUX_DATA(MSIOF3_TXD_MARK,		PORT68_FN3),
+	PINMUX_DATA(GIO_OUT4_68_MARK,		PORT68_FN5),
+
+	/* Port69 */
+	PINMUX_DATA(HSI_RX_DATA_MARK,		PORT69_FN1),
+	PINMUX_DATA(SCIFB2_RXD_69_MARK,		PORT69_FN2,	MSEL3CR_10_0),
+	PINMUX_DATA(MSIOF3_RXD_MARK,		PORT69_FN3),
+	PINMUX_DATA(GIO_OUT5_69_MARK,		PORT69_FN5),
+
+	/* Port70 */
+	PINMUX_DATA(HSI_TX_FLAG_MARK,		PORT70_FN1),
+	PINMUX_DATA(SCIFB1_RTS_70_MARK,		PORT70_FN2),
+	PINMUX_DATA(GIO_OUT1_70_MARK,		PORT70_FN5),
+	PINMUX_DATA(HSIC_TSTCLK0_MARK,		PORT70_FN6),
+	PINMUX_DATA(CHSCIF1_HRTS_MARK,		PORT70_FN7),
+
+	/* Port71 */
+	PINMUX_DATA(HSI_TX_DATA_MARK,		PORT71_FN1),
+	PINMUX_DATA(SCIFB1_CTS_71_MARK,		PORT71_FN2,	MSEL3CR_11_1),
+	PINMUX_DATA(GIO_OUT2_71_MARK,		PORT71_FN5),
+	PINMUX_DATA(HSIC_TSTCLK1_MARK,		PORT71_FN6),
+	PINMUX_DATA(CHSCIF1_HCTS_MARK,		PORT71_FN7),
+
+	/* Port72 */
+	PINMUX_DATA(HSI_TX_WAKE_MARK,		PORT72_FN1),
+	PINMUX_DATA(SCIFB1_RXD_72_MARK,		PORT72_FN2,	MSEL3CR_11_1),
+	PINMUX_DATA(GenIO8_MARK,		PORT72_FN5),
+	PINMUX_DATA(CHSCIF1_HRX_MARK,		PORT72_FN7),
+
+	/* Port73 */
+	PINMUX_DATA(HSI_TX_READY_MARK,		PORT73_FN1),
+	PINMUX_DATA(SCIFB2_RTS_73_MARK,		PORT73_FN2),
+	PINMUX_DATA(MSIOF3_SCK_MARK,		PORT73_FN3),
+	PINMUX_DATA(GIO_OUT0_73_MARK,		PORT73_FN5),
+
+	/* Port74 - Port85 */
+	PINMUX_DATA(IRDA_OUT_MARK,		PORT74_FN1),
+	PINMUX_DATA(IRDA_IN_MARK,		PORT75_FN1),
+	PINMUX_DATA(IRDA_FIRSEL_MARK,		PORT76_FN1),
+	PINMUX_DATA(TPU0TO0_MARK,		PORT77_FN1),
+	PINMUX_DATA(DIGRFEN_MARK,		PORT78_FN1),
+	PINMUX_DATA(GPS_TIMESTAMP_MARK,		PORT79_FN1),
+	PINMUX_DATA(TXP_MARK,			PORT80_FN1),
+	PINMUX_DATA(TXP2_MARK,			PORT81_FN1),
+	PINMUX_DATA(COEX_0_MARK,		PORT82_FN1),
+	PINMUX_DATA(COEX_1_MARK,		PORT83_FN1),
+	PINMUX_DATA(IRQ19_MARK,			PORT84_FN0),
+	PINMUX_DATA(IRQ18_MARK,			PORT85_FN0),
+
+	/* Port96 - Port101 */
+	PINMUX_DATA(KEYIN0_MARK,		PORT96_FN1),
+	PINMUX_DATA(KEYIN1_MARK,		PORT97_FN1),
+	PINMUX_DATA(KEYIN2_MARK,		PORT98_FN1),
+	PINMUX_DATA(KEYIN3_MARK,		PORT99_FN1),
+	PINMUX_DATA(KEYIN4_MARK,		PORT100_FN1),
+	PINMUX_DATA(KEYIN5_MARK,		PORT101_FN1),
+
+	/* Port102 */
+	PINMUX_DATA(KEYIN6_MARK,		PORT102_FN1),
+	PINMUX_DATA(IRQ41_MARK,			PORT102_FN0),
+
+	/* Port103 */
+	PINMUX_DATA(KEYIN7_MARK,		PORT103_FN1),
+	PINMUX_DATA(IRQ42_MARK,			PORT103_FN0),
+
+	/* Port104 - Port108 */
+	PINMUX_DATA(KEYOUT0_MARK,		PORT104_FN2),
+	PINMUX_DATA(KEYOUT1_MARK,		PORT105_FN2),
+	PINMUX_DATA(KEYOUT2_MARK,		PORT106_FN2),
+	PINMUX_DATA(KEYOUT3_MARK,		PORT107_FN2),
+	PINMUX_DATA(KEYOUT4_MARK,		PORT108_FN2),
+
+	/* Port109 */
+	PINMUX_DATA(KEYOUT5_MARK,		PORT109_FN2),
+	PINMUX_DATA(IRQ43_MARK,			PORT109_FN0),
+
+	/* Port110 */
+	PINMUX_DATA(KEYOUT6_MARK,		PORT110_FN2),
+	PINMUX_DATA(IRQ44_MARK,			PORT110_FN0),
+
+	/* Port111 */
+	PINMUX_DATA(KEYOUT7_MARK,		PORT111_FN2),
+	PINMUX_DATA(RFANAEN_MARK,		PORT111_FN5),
+	PINMUX_DATA(IRQ45_MARK,			PORT111_FN0),
+
+	/* Port112 */
+	PINMUX_DATA(KEYIN8_MARK,		PORT112_FN1),
+	PINMUX_DATA(KEYOUT8_MARK,		PORT112_FN2),
+	PINMUX_DATA(SF_IRQ_04_MARK,		PORT112_FN4),
+	PINMUX_DATA(IRQ46_MARK,			PORT112_FN0),
+
+	/* Port113 */
+	PINMUX_DATA(KEYIN9_MARK,		PORT113_FN1),
+	PINMUX_DATA(KEYOUT9_MARK,		PORT113_FN2),
+	PINMUX_DATA(SF_IRQ_05_MARK,		PORT113_FN4),
+	PINMUX_DATA(IRQ47_MARK,			PORT113_FN0),
+
+	/* Port114 */
+	PINMUX_DATA(KEYIN10_MARK,		PORT114_FN1),
+	PINMUX_DATA(KEYOUT10_MARK,		PORT114_FN2),
+	PINMUX_DATA(SF_IRQ_06_MARK,		PORT114_FN4),
+	PINMUX_DATA(IRQ48_MARK,			PORT114_FN0),
+
+	/* Port115 */
+	PINMUX_DATA(KEYIN11_MARK,		PORT115_FN1),
+	PINMUX_DATA(KEYOUT11_MARK,		PORT115_FN2),
+	PINMUX_DATA(SF_IRQ_07_MARK,		PORT115_FN4),
+	PINMUX_DATA(IRQ49_MARK,			PORT115_FN0),
+
+	/* Port116 */
+	PINMUX_DATA(SCIFA0_TXD_MARK,		PORT116_FN1),
+	PINMUX_DATA(CSCIF0_TX_MARK,		PORT116_FN7),
+
+	/* Port117 */
+	PINMUX_DATA(SCIFA0_RXD_MARK,		PORT117_FN1),
+	PINMUX_DATA(CSCIF0_RX_MARK,		PORT117_FN7),
+
+	/* Port118 */
+	PINMUX_DATA(SCIFA1_TXD_MARK,		PORT118_FN1),
+	PINMUX_DATA(CSCIF1_TX_MARK,		PORT118_FN7),
+
+	/* Port119 */
+	PINMUX_DATA(SCIFA1_RXD_MARK,		PORT119_FN1),
+	PINMUX_DATA(CSCIF1_RX_MARK,		PORT119_FN7),
+
+	/* Port120 */
+	PINMUX_DATA(SF_PORT_1_120_MARK,		PORT120_FN3),
+	PINMUX_DATA(SCIFB3_RXD_120_MARK,	PORT120_FN4,	MSEL3CR_09_1),
+	PINMUX_DATA(DU0_CDE_MARK,		PORT120_FN7),
+
+	/* Port121 */
+	PINMUX_DATA(SF_PORT_0_121_MARK,		PORT121_FN3),
+	PINMUX_DATA(SCIFB3_TXD_121_MARK,	PORT121_FN4,	MSEL3CR_09_1),
+
+	/* Port122 */
+	PINMUX_DATA(SCIFB0_TXD_MARK,		PORT122_FN1),
+	PINMUX_DATA(CHSCIF0_HTX_MARK,		PORT122_FN7),
+
+	/* Port123 */
+	PINMUX_DATA(SCIFB0_RXD_MARK,		PORT123_FN1),
+	PINMUX_DATA(CHSCIF0_HRX_MARK,		PORT123_FN7),
+
+	/* Port124 */
+	PINMUX_DATA(ISP_STROBE_124_MARK,	PORT124_FN3),
+
+	/* Port125 */
+	PINMUX_DATA(STP_ISD_0_MARK,		PORT125_FN1),
+	PINMUX_DATA(PDM4_CLK_125_MARK,		PORT125_FN2),
+	PINMUX_DATA(MSIOF2_TXD_MARK,		PORT125_FN3),
+	PINMUX_DATA(SIM0_VOLTSEL0_MARK,		PORT125_FN5),
+
+	/* Port126 */
+	PINMUX_DATA(TS_SDEN_MARK,		PORT126_FN1),
+	PINMUX_DATA(MSIOF7_SYNC_MARK,		PORT126_FN2),
+	PINMUX_DATA(STP_ISEN_1_MARK,		PORT126_FN3),
+
+	/* Port128 */
+	PINMUX_DATA(STP_ISEN_0_MARK,		PORT128_FN1),
+	PINMUX_DATA(PDM1_OUTDATA_128_MARK,	PORT128_FN2),
+	PINMUX_DATA(MSIOF2_SYNC_MARK,		PORT128_FN3),
+	PINMUX_DATA(SIM1_VOLTSEL1_MARK,		PORT128_FN5),
+
+	/* Port129 */
+	PINMUX_DATA(TS_SPSYNC_MARK,		PORT129_FN1),
+	PINMUX_DATA(MSIOF7_RXD_MARK,		PORT129_FN2),
+	PINMUX_DATA(STP_ISSYNC_1_MARK,		PORT129_FN3),
+
+	/* Port130 */
+	PINMUX_DATA(STP_ISSYNC_0_MARK,		PORT130_FN1),
+	PINMUX_DATA(PDM4_DATA_130_MARK,		PORT130_FN2,	MSEL3CR_12_1),
+	PINMUX_DATA(MSIOF2_RXD_MARK,		PORT130_FN3),
+	PINMUX_DATA(SIM0_VOLTSEL1_MARK,		PORT130_FN5),
+
+	/* Port131 */
+	PINMUX_DATA(STP_OPWM_0_MARK,		PORT131_FN1),
+	PINMUX_DATA(SIM1_PWRON_MARK,		PORT131_FN5),
+
+	/* Port132 */
+	PINMUX_DATA(TS_SCK_MARK,		PORT132_FN1),
+	PINMUX_DATA(MSIOF7_SCK_MARK,		PORT132_FN2),
+	PINMUX_DATA(STP_ISCLK_1_MARK,		PORT132_FN3),
+
+	/* Port133 */
+	PINMUX_DATA(STP_ISCLK_0_MARK,		PORT133_FN1),
+	PINMUX_DATA(PDM1_OUTCLK_133_MARK,	PORT133_FN2),
+	PINMUX_DATA(MSIOF2_SCK_MARK,		PORT133_FN3),
+	PINMUX_DATA(SIM1_VOLTSEL0_MARK,		PORT133_FN5),
+
+	/* Port134 */
+	PINMUX_DATA(TS_SDAT_MARK,		PORT134_FN1),
+	PINMUX_DATA(MSIOF7_TXD_MARK,		PORT134_FN2),
+	PINMUX_DATA(STP_ISD_1_MARK,		PORT134_FN3),
+
+	/* Port160 - Port178 */
+	PINMUX_DATA(IRQ20_MARK,			PORT160_FN0),
+	PINMUX_DATA(IRQ21_MARK,			PORT161_FN0),
+	PINMUX_DATA(IRQ22_MARK,			PORT162_FN0),
+	PINMUX_DATA(IRQ23_MARK,			PORT163_FN0),
+	PINMUX_DATA(MMCD0_0_MARK,		PORT164_FN1),
+	PINMUX_DATA(MMCD0_1_MARK,		PORT165_FN1),
+	PINMUX_DATA(MMCD0_2_MARK,		PORT166_FN1),
+	PINMUX_DATA(MMCD0_3_MARK,		PORT167_FN1),
+	PINMUX_DATA(MMCD0_4_MARK,		PORT168_FN1),
+	PINMUX_DATA(MMCD0_5_MARK,		PORT169_FN1),
+	PINMUX_DATA(MMCD0_6_MARK,		PORT170_FN1),
+	PINMUX_DATA(MMCD0_7_MARK,		PORT171_FN1),
+	PINMUX_DATA(MMCCMD0_MARK,		PORT172_FN1),
+	PINMUX_DATA(MMCCLK0_MARK,		PORT173_FN1),
+	PINMUX_DATA(MMCRST_MARK,		PORT174_FN1),
+	PINMUX_DATA(IRQ24_MARK,			PORT175_FN0),
+	PINMUX_DATA(IRQ25_MARK,			PORT176_FN0),
+	PINMUX_DATA(IRQ26_MARK,			PORT177_FN0),
+	PINMUX_DATA(IRQ27_MARK,			PORT178_FN0),
+
+	/* Port192 - Port200 FN1 */
+	PINMUX_DATA(A10_MARK,		PORT192_FN1),
+	PINMUX_DATA(A9_MARK,		PORT193_FN1),
+	PINMUX_DATA(A8_MARK,		PORT194_FN1),
+	PINMUX_DATA(A7_MARK,		PORT195_FN1),
+	PINMUX_DATA(A6_MARK,		PORT196_FN1),
+	PINMUX_DATA(A5_MARK,		PORT197_FN1),
+	PINMUX_DATA(A4_MARK,		PORT198_FN1),
+	PINMUX_DATA(A3_MARK,		PORT199_FN1),
+	PINMUX_DATA(A2_MARK,		PORT200_FN1),
+
+	/* Port192 - Port200 FN2 */
+	PINMUX_DATA(MMCD1_7_MARK,		PORT192_FN2),
+	PINMUX_DATA(MMCD1_6_MARK,		PORT193_FN2),
+	PINMUX_DATA(MMCD1_5_MARK,		PORT194_FN2),
+	PINMUX_DATA(MMCD1_4_MARK,		PORT195_FN2),
+	PINMUX_DATA(MMCD1_3_MARK,		PORT196_FN2),
+	PINMUX_DATA(MMCD1_2_MARK,		PORT197_FN2),
+	PINMUX_DATA(MMCD1_1_MARK,		PORT198_FN2),
+	PINMUX_DATA(MMCD1_0_MARK,		PORT199_FN2),
+	PINMUX_DATA(MMCCMD1_MARK,		PORT200_FN2),
+
+	/* Port192 - Port200 IRQ */
+	PINMUX_DATA(IRQ31_MARK,			PORT192_FN0),
+	PINMUX_DATA(IRQ32_MARK,			PORT193_FN0),
+	PINMUX_DATA(IRQ33_MARK,			PORT194_FN0),
+	PINMUX_DATA(IRQ34_MARK,			PORT195_FN0),
+	PINMUX_DATA(IRQ35_MARK,			PORT196_FN0),
+	PINMUX_DATA(IRQ36_MARK,			PORT197_FN0),
+	PINMUX_DATA(IRQ37_MARK,			PORT198_FN0),
+	PINMUX_DATA(IRQ38_MARK,			PORT199_FN0),
+	PINMUX_DATA(IRQ39_MARK,			PORT200_FN0),
+
+	/* Port201 */
+	PINMUX_DATA(A1_MARK,		PORT201_FN1),
+
+	/* Port202 */
+	PINMUX_DATA(A0_MARK,		PORT202_FN1),
+	PINMUX_DATA(BS_MARK,		PORT202_FN2),
+
+	/* Port203 */
+	PINMUX_DATA(CKO_MARK,		PORT203_FN1),
+	PINMUX_DATA(MMCCLK1_MARK,	PORT203_FN2),
+
+	/* Port204 */
+	PINMUX_DATA(CS0_N_MARK,		PORT204_FN1),
+	PINMUX_DATA(SIM0_GPO1_MARK,	PORT204_FN5),
+
+	/* Port205 */
+	PINMUX_DATA(CS2_N_MARK,		PORT205_FN1),
+	PINMUX_DATA(SIM0_GPO2_MARK,	PORT205_FN5),
+
+	/* Port206 */
+	PINMUX_DATA(CS4_N_MARK,		PORT206_FN1),
+	PINMUX_DATA(VIO_VD_MARK,	PORT206_FN2),
+	PINMUX_DATA(SIM1_GPO0_MARK,	PORT206_FN5),
+
+	/* Port207 - Port212 FN1 */
+	PINMUX_DATA(D15_MARK,		PORT207_FN1),
+	PINMUX_DATA(D14_MARK,		PORT208_FN1),
+	PINMUX_DATA(D13_MARK,		PORT209_FN1),
+	PINMUX_DATA(D12_MARK,		PORT210_FN1),
+	PINMUX_DATA(D11_MARK,		PORT211_FN1),
+	PINMUX_DATA(D10_MARK,		PORT212_FN1),
+
+	/* Port207 - Port212 FN5 */
+	PINMUX_DATA(GIO_OUT15_MARK,			PORT207_FN5),
+	PINMUX_DATA(GIO_OUT14_MARK,			PORT208_FN5),
+	PINMUX_DATA(GIO_OUT13_MARK,			PORT209_FN5),
+	PINMUX_DATA(GIO_OUT12_MARK,			PORT210_FN5),
+	PINMUX_DATA(WGM_TXP2_MARK,			PORT211_FN5),
+	PINMUX_DATA(WGM_GPS_TIMEM_ASK_RFCLK_MARK,	PORT212_FN5),
+
+	/* Port213 - Port222 FN1 */
+	PINMUX_DATA(D9_MARK,		PORT213_FN1),
+	PINMUX_DATA(D8_MARK,		PORT214_FN1),
+	PINMUX_DATA(D7_MARK,		PORT215_FN1),
+	PINMUX_DATA(D6_MARK,		PORT216_FN1),
+	PINMUX_DATA(D5_MARK,		PORT217_FN1),
+	PINMUX_DATA(D4_MARK,		PORT218_FN1),
+	PINMUX_DATA(D3_MARK,		PORT219_FN1),
+	PINMUX_DATA(D2_MARK,		PORT220_FN1),
+	PINMUX_DATA(D1_MARK,		PORT221_FN1),
+	PINMUX_DATA(D0_MARK,		PORT222_FN1),
+
+	/* Port213 - Port222 FN2 */
+	PINMUX_DATA(VIO_D9_MARK,	PORT213_FN2),
+	PINMUX_DATA(VIO_D8_MARK,	PORT214_FN2),
+	PINMUX_DATA(VIO_D7_MARK,	PORT215_FN2),
+	PINMUX_DATA(VIO_D6_MARK,	PORT216_FN2),
+	PINMUX_DATA(VIO_D5_MARK,	PORT217_FN2),
+	PINMUX_DATA(VIO_D4_MARK,	PORT218_FN2),
+	PINMUX_DATA(VIO_D3_MARK,	PORT219_FN2),
+	PINMUX_DATA(VIO_D2_MARK,	PORT220_FN2),
+	PINMUX_DATA(VIO_D1_MARK,	PORT221_FN2),
+	PINMUX_DATA(VIO_D0_MARK,	PORT222_FN2),
+
+	/* Port213 - Port222 FN5 */
+	PINMUX_DATA(GIO_OUT9_MARK,	PORT213_FN5),
+	PINMUX_DATA(GIO_OUT8_MARK,	PORT214_FN5),
+	PINMUX_DATA(GIO_OUT7_MARK,	PORT215_FN5),
+	PINMUX_DATA(GIO_OUT6_MARK,	PORT216_FN5),
+	PINMUX_DATA(GIO_OUT5_217_MARK,	PORT217_FN5),
+	PINMUX_DATA(GIO_OUT4_218_MARK,	PORT218_FN5),
+	PINMUX_DATA(GIO_OUT3_219_MARK,	PORT219_FN5),
+	PINMUX_DATA(GIO_OUT2_220_MARK,	PORT220_FN5),
+	PINMUX_DATA(GIO_OUT1_221_MARK,	PORT221_FN5),
+	PINMUX_DATA(GIO_OUT0_222_MARK,	PORT222_FN5),
+
+	/* Port224 */
+	PINMUX_DATA(RDWR_224_MARK,	PORT224_FN1),
+	PINMUX_DATA(VIO_HD_MARK,	PORT224_FN2),
+	PINMUX_DATA(SIM1_GPO2_MARK,	PORT224_FN5),
+
+	/* Port225 */
+	PINMUX_DATA(RD_N_MARK,		PORT225_FN1),
+
+	/* Port226 */
+	PINMUX_DATA(WAIT_N_MARK,	PORT226_FN1),
+	PINMUX_DATA(VIO_CLK_MARK,	PORT226_FN2),
+	PINMUX_DATA(SIM1_GPO1_MARK,	PORT226_FN5),
+
+	/* Port227 */
+	PINMUX_DATA(WE0_N_MARK,		PORT227_FN1),
+	PINMUX_DATA(RDWR_227_MARK,	PORT227_FN2),
+
+	/* Port228 */
+	PINMUX_DATA(WE1_N_MARK,		PORT228_FN1),
+	PINMUX_DATA(SIM0_GPO0_MARK,	PORT228_FN5),
+
+	/* Port229 */
+	PINMUX_DATA(PWMO_MARK,		PORT229_FN1),
+	PINMUX_DATA(VIO_CKO1_229_MARK,	PORT229_FN2),
+
+	/* Port230 */
+	PINMUX_DATA(SLIM_CLK_MARK,	PORT230_FN1),
+	PINMUX_DATA(VIO_CKO4_230_MARK,	PORT230_FN2),
+
+	/* Port231 */
+	PINMUX_DATA(SLIM_DATA_MARK,	PORT231_FN1),
+	PINMUX_DATA(VIO_CKO5_231_MARK,	PORT231_FN2),
+
+	/* Port232 */
+	PINMUX_DATA(VIO_CKO2_232_MARK,	PORT232_FN2),
+	PINMUX_DATA(SF_PORT_0_232_MARK,	PORT232_FN4),
+
+	/* Port233 */
+	PINMUX_DATA(VIO_CKO3_233_MARK,	PORT233_FN2),
+	PINMUX_DATA(SF_PORT_1_233_MARK,	PORT233_FN4),
+
+	/* Port234 */
+	PINMUX_DATA(FSIACK_MARK,	PORT234_FN1),
+	PINMUX_DATA(PDM3_CLK_234_MARK,	PORT234_FN2),
+	PINMUX_DATA(ISP_IRIS1_234_MARK,	PORT234_FN3),
+
+	/* Port235 */
+	PINMUX_DATA(FSIAISLD_MARK,	PORT235_FN1),
+	PINMUX_DATA(PDM3_DATA_235_MARK,	PORT235_FN2,	MSEL3CR_12_1),
+
+	/* Port236 */
+	PINMUX_DATA(FSIAOMC_MARK,		PORT236_FN1),
+	PINMUX_DATA(PDM0_OUTCLK_236_MARK,	PORT236_FN2),
+	PINMUX_DATA(ISP_IRIS0_236_MARK,		PORT236_FN3),
+
+	/* Port237 */
+	PINMUX_DATA(FSIAOLR_MARK,	PORT237_FN1),
+	PINMUX_DATA(FSIAILR_MARK,	PORT237_FN2),
+
+	/* Port238 */
+	PINMUX_DATA(FSIAOBT_MARK,	PORT238_FN1),
+	PINMUX_DATA(FSIAIBT_MARK,	PORT238_FN2),
+
+	/* Port239 */
+	PINMUX_DATA(FSIAOSLD_MARK,		PORT239_FN1),
+	PINMUX_DATA(PDM0_OUTDATA_239_MARK,	PORT239_FN2),
+
+	/* Port240 */
+	PINMUX_DATA(FSIBISLD_MARK,	PORT240_FN1),
+
+	/* Port241 */
+	PINMUX_DATA(FSIBOLR_MARK,	PORT241_FN1),
+	PINMUX_DATA(FSIBILR_MARK,	PORT241_FN2),
+
+	/* Port242 */
+	PINMUX_DATA(FSIBOMC_MARK,		PORT242_FN1),
+	PINMUX_DATA(ISP_SHUTTER1_242_MARK,	PORT242_FN3),
+
+	/* Port243 */
+	PINMUX_DATA(FSIBOBT_MARK,	PORT243_FN1),
+	PINMUX_DATA(FSIBIBT_MARK,	PORT243_FN2),
+
+	/* Port244 */
+	PINMUX_DATA(FSIBOSLD_MARK,	PORT244_FN1),
+	PINMUX_DATA(FSIASPDIF_MARK,	PORT244_FN2),
+
+	/* Port245 */
+	PINMUX_DATA(FSIBCK_MARK,		PORT245_FN1),
+	PINMUX_DATA(ISP_SHUTTER0_245_MARK,	PORT245_FN3),
+
+	/* Port246 - Port250 FN1 */
+	PINMUX_DATA(ISP_IRIS1_246_MARK,		PORT246_FN1),
+	PINMUX_DATA(ISP_IRIS0_247_MARK,		PORT247_FN1),
+	PINMUX_DATA(ISP_SHUTTER1_248_MARK,	PORT248_FN1),
+	PINMUX_DATA(ISP_SHUTTER0_249_MARK,	PORT249_FN1),
+	PINMUX_DATA(ISP_STROBE_250_MARK,	PORT250_FN1),
+
+	/* Port256 - Port258 */
+	PINMUX_DATA(MSIOF0_SYNC_MARK,		PORT256_FN1),
+	PINMUX_DATA(MSIOF0_RXD_MARK,		PORT257_FN1),
+	PINMUX_DATA(MSIOF0_SCK_MARK,		PORT258_FN1),
+
+	/* Port259 */
+	PINMUX_DATA(MSIOF0_SS2_MARK,		PORT259_FN1),
+	PINMUX_DATA(VIO_CKO3_259_MARK,		PORT259_FN3),
+
+	/* Port260 */
+	PINMUX_DATA(MSIOF0_TXD_MARK,		PORT260_FN1),
+
+	/* Port261 */
+	PINMUX_DATA(SCIFB1_SCK_261_MARK,	PORT261_FN2),
+	PINMUX_DATA(CHSCIF1_HSCK_MARK,		PORT261_FN7),
+
+	/* Port262 */
+	PINMUX_DATA(SCIFB2_SCK_262_MARK,	PORT262_FN2),
+
+	/* Port263 - Port266 FN1 */
+	PINMUX_DATA(MSIOF1_SS2_MARK,		PORT263_FN1),
+	PINMUX_DATA(MSIOF1_TXD_MARK,		PORT264_FN1),
+	PINMUX_DATA(MSIOF1_RXD_MARK,		PORT265_FN1),
+	PINMUX_DATA(MSIOF1_SS1_MARK,		PORT266_FN1),
+
+	/* Port263 - Port266 FN4 */
+	PINMUX_DATA(MSIOF5_SS2_MARK,		PORT263_FN4),
+	PINMUX_DATA(MSIOF5_TXD_MARK,		PORT264_FN4),
+	PINMUX_DATA(MSIOF5_RXD_MARK,		PORT265_FN4),
+	PINMUX_DATA(MSIOF5_SS1_MARK,		PORT266_FN4),
+
+	/* Port267 */
+	PINMUX_DATA(MSIOF0_SS1_MARK,		PORT267_FN1),
+
+	/* Port268 */
+	PINMUX_DATA(MSIOF1_SCK_MARK,		PORT268_FN1),
+	PINMUX_DATA(MSIOF5_SCK_MARK,		PORT268_FN4),
+
+	/* Port269 */
+	PINMUX_DATA(MSIOF1_SYNC_MARK,		PORT269_FN1),
+	PINMUX_DATA(MSIOF5_SYNC_MARK,		PORT269_FN4),
+
+	/* Port270 - Port273 FN1 */
+	PINMUX_DATA(MSIOF2_SS1_MARK,		PORT270_FN1),
+	PINMUX_DATA(MSIOF2_SS2_MARK,		PORT271_FN1),
+	PINMUX_DATA(MSIOF3_SS2_MARK,		PORT272_FN1),
+	PINMUX_DATA(MSIOF3_SS1_MARK,		PORT273_FN1),
+
+	/* Port270 - Port273 FN3 */
+	PINMUX_DATA(VIO_CKO5_270_MARK,		PORT270_FN3),
+	PINMUX_DATA(VIO_CKO2_271_MARK,		PORT271_FN3),
+	PINMUX_DATA(VIO_CKO1_272_MARK,		PORT272_FN3),
+	PINMUX_DATA(VIO_CKO4_273_MARK,		PORT273_FN3),
+
+	/* Port274 */
+	PINMUX_DATA(MSIOF4_SS2_MARK,		PORT274_FN1),
+	PINMUX_DATA(TPU1TO0_MARK,		PORT274_FN4),
+
+	/* Port275 - Port280 */
+	PINMUX_DATA(IC_DP_MARK,			PORT275_FN1),
+	PINMUX_DATA(SIM0_RST_MARK,		PORT276_FN1),
+	PINMUX_DATA(IC_DM_MARK,			PORT277_FN1),
+	PINMUX_DATA(SIM0_BSICOMP_MARK,		PORT278_FN1),
+	PINMUX_DATA(SIM0_CLK_MARK,		PORT279_FN1),
+	PINMUX_DATA(SIM0_IO_MARK,		PORT280_FN1),
+
+	/* Port281 */
+	PINMUX_DATA(SIM1_IO_MARK,		PORT281_FN1),
+	PINMUX_DATA(PDM2_DATA_281_MARK,		PORT281_FN2,	MSEL3CR_12_1),
+
+	/* Port282 */
+	PINMUX_DATA(SIM1_CLK_MARK,		PORT282_FN1),
+	PINMUX_DATA(PDM2_CLK_282_MARK,		PORT282_FN2),
+
+	/* Port283 */
+	PINMUX_DATA(SIM1_RST_MARK,		PORT283_FN1),
+
+	/* Port289 */
+	PINMUX_DATA(SDHID1_0_MARK,		PORT289_FN1),
+	PINMUX_DATA(STMDATA0_2_MARK,		PORT289_FN3),
+
+	/* Port290 */
+	PINMUX_DATA(SDHID1_1_MARK,		PORT290_FN1),
+	PINMUX_DATA(STMDATA1_2_MARK,		PORT290_FN3),
+	PINMUX_DATA(IRQ51_MARK,			PORT290_FN0),
+
+	/* Port291 - Port294 FN1 */
+	PINMUX_DATA(SDHID1_2_MARK,		PORT291_FN1),
+	PINMUX_DATA(SDHID1_3_MARK,		PORT292_FN1),
+	PINMUX_DATA(SDHICLK1_MARK,		PORT293_FN1),
+	PINMUX_DATA(SDHICMD1_MARK,		PORT294_FN1),
+
+	/* Port291 - Port294 FN3 */
+	PINMUX_DATA(STMDATA2_2_MARK,		PORT291_FN3),
+	PINMUX_DATA(STMDATA3_2_MARK,		PORT292_FN3),
+	PINMUX_DATA(STMCLK_2_MARK,		PORT293_FN3),
+	PINMUX_DATA(STMSIDI_2_MARK,		PORT294_FN3),
+
+	/* Port295 */
+	PINMUX_DATA(SDHID2_0_MARK,		PORT295_FN1),
+	PINMUX_DATA(MSIOF4_TXD_MARK,		PORT295_FN2),
+	PINMUX_DATA(SCIFB2_TXD_295_MARK,	PORT295_FN3,	MSEL3CR_10_1),
+	PINMUX_DATA(MSIOF6_TXD_MARK,		PORT295_FN4),
+
+	/* Port296 */
+	PINMUX_DATA(SDHID2_1_MARK,		PORT296_FN1),
+	PINMUX_DATA(MSIOF6_SS2_MARK,		PORT296_FN4),
+	PINMUX_DATA(IRQ52_MARK,			PORT296_FN0),
+
+	/* Port297 - Port300 FN1 */
+	PINMUX_DATA(SDHID2_2_MARK,		PORT297_FN1),
+	PINMUX_DATA(SDHID2_3_MARK,		PORT298_FN1),
+	PINMUX_DATA(SDHICLK2_MARK,		PORT299_FN1),
+	PINMUX_DATA(SDHICMD2_MARK,		PORT300_FN1),
+
+	/* Port297 - Port300 FN2 */
+	PINMUX_DATA(MSIOF4_RXD_MARK,		PORT297_FN2),
+	PINMUX_DATA(MSIOF4_SYNC_MARK,		PORT298_FN2),
+	PINMUX_DATA(MSIOF4_SCK_MARK,		PORT299_FN2),
+	PINMUX_DATA(MSIOF4_SS1_MARK,		PORT300_FN2),
+
+	/* Port297 - Port300 FN3 */
+	PINMUX_DATA(SCIFB2_RXD_297_MARK,	PORT297_FN3,	MSEL3CR_10_1),
+	PINMUX_DATA(SCIFB2_CTS_298_MARK,	PORT298_FN3,	MSEL3CR_10_1),
+	PINMUX_DATA(SCIFB2_SCK_299_MARK,	PORT299_FN3),
+	PINMUX_DATA(SCIFB2_RTS_300_MARK,	PORT300_FN3),
+
+	/* Port297 - Port300 FN4 */
+	PINMUX_DATA(MSIOF6_RXD_MARK,		PORT297_FN4),
+	PINMUX_DATA(MSIOF6_SYNC_MARK,		PORT298_FN4),
+	PINMUX_DATA(MSIOF6_SCK_MARK,		PORT299_FN4),
+	PINMUX_DATA(MSIOF6_SS1_MARK,		PORT300_FN4),
+
+	/* Port301 */
+	PINMUX_DATA(SDHICD0_MARK,		PORT301_FN1),
+	PINMUX_DATA(IRQ50_MARK,			PORT301_FN0),
+
+	/* Port302 - Port306 FN1 */
+	PINMUX_DATA(SDHID0_0_MARK,		PORT302_FN1),
+	PINMUX_DATA(SDHID0_1_MARK,		PORT303_FN1),
+	PINMUX_DATA(SDHID0_2_MARK,		PORT304_FN1),
+	PINMUX_DATA(SDHID0_3_MARK,		PORT305_FN1),
+	PINMUX_DATA(SDHICMD0_MARK,		PORT306_FN1),
+
+	/* Port302 - Port306 FN3 */
+	PINMUX_DATA(STMDATA0_1_MARK,		PORT302_FN3),
+	PINMUX_DATA(STMDATA1_1_MARK,		PORT303_FN3),
+	PINMUX_DATA(STMDATA2_1_MARK,		PORT304_FN3),
+	PINMUX_DATA(STMDATA3_1_MARK,		PORT305_FN3),
+	PINMUX_DATA(STMSIDI_1_MARK,		PORT306_FN3),
+
+	/* Port307 */
+	PINMUX_DATA(SDHIWP0_MARK,		PORT307_FN1),
+
+	/* Port308 */
+	PINMUX_DATA(SDHICLK0_MARK,		PORT308_FN1),
+	PINMUX_DATA(STMCLK_1_MARK,		PORT308_FN3),
+
+	/* Port320 - Port329 */
+	PINMUX_DATA(IRQ16_MARK,			PORT320_FN0),
+	PINMUX_DATA(IRQ17_MARK,			PORT321_FN0),
+	PINMUX_DATA(IRQ28_MARK,			PORT322_FN0),
+	PINMUX_DATA(IRQ29_MARK,			PORT323_FN0),
+	PINMUX_DATA(IRQ30_MARK,			PORT324_FN0),
+	PINMUX_DATA(IRQ53_MARK,			PORT325_FN0),
+	PINMUX_DATA(IRQ54_MARK,			PORT326_FN0),
+	PINMUX_DATA(IRQ55_MARK,			PORT327_FN0),
+	PINMUX_DATA(IRQ56_MARK,			PORT328_FN0),
+	PINMUX_DATA(IRQ57_MARK,			PORT329_FN0),
+};
+
+static struct sh_pfc_pin pinmux_pins[] = {
+	GPIO_PORT_ALL(),
+};
+
+#define PINMUX_FN_BASE	ARRAY_SIZE(pinmux_pins)
+
+static const struct pinmux_func pinmux_func_gpios[] = {
+	/* Port0 */
+	GPIO_FN(LCDD0),
+	GPIO_FN(PDM2_CLK_0),
+	GPIO_FN(DU0_DR0),
+	GPIO_FN(IRQ0),
+
+	/* Port1 */
+	GPIO_FN(LCDD1),
+	GPIO_FN(PDM2_DATA_1),
+	GPIO_FN(DU0_DR19),
+	GPIO_FN(IRQ1),
+
+	/* Port2 */
+	GPIO_FN(LCDD2),
+	GPIO_FN(PDM3_CLK_2),
+	GPIO_FN(DU0_DR2),
+	GPIO_FN(IRQ2),
+
+	/* Port3 */
+	GPIO_FN(LCDD3),
+	GPIO_FN(PDM3_DATA_3),
+	GPIO_FN(DU0_DR3),
+	GPIO_FN(IRQ3),
+
+	/* Port4 */
+	GPIO_FN(LCDD4),
+	GPIO_FN(PDM4_CLK_4),
+	GPIO_FN(DU0_DR4),
+	GPIO_FN(IRQ4),
+
+	/* Port5 */
+	GPIO_FN(LCDD5),
+	GPIO_FN(PDM4_DATA_5),
+	GPIO_FN(DU0_DR5),
+	GPIO_FN(IRQ5),
+
+	/* Port6 */
+	GPIO_FN(LCDD6),
+	GPIO_FN(PDM0_OUTCLK_6),
+	GPIO_FN(DU0_DR6),
+	GPIO_FN(IRQ6),
+
+	/* Port7 */
+	GPIO_FN(LCDD7),
+	GPIO_FN(PDM0_OUTDATA_7),
+	GPIO_FN(DU0_DR7),
+	GPIO_FN(IRQ7),
+
+	/* Port8 */
+	GPIO_FN(LCDD8),
+	GPIO_FN(PDM1_OUTCLK_8),
+	GPIO_FN(DU0_DG0),
+	GPIO_FN(IRQ8),
+
+	/* Port9 */
+	GPIO_FN(LCDD9),
+	GPIO_FN(PDM1_OUTDATA_9),
+	GPIO_FN(DU0_DG1),
+	GPIO_FN(IRQ9),
+
+	/* Port10 */
+	GPIO_FN(LCDD10),
+	GPIO_FN(FSICCK),
+	GPIO_FN(DU0_DG2),
+	GPIO_FN(IRQ10),
+
+	/* Port11 */
+	GPIO_FN(LCDD11),
+	GPIO_FN(FSICISLD),
+	GPIO_FN(DU0_DG3),
+	GPIO_FN(IRQ11),
+
+	/* Port12 */
+	GPIO_FN(LCDD12),
+	GPIO_FN(FSICOMC),
+	GPIO_FN(DU0_DG4),
+	GPIO_FN(IRQ12),
+
+	/* Port13 */
+	GPIO_FN(LCDD13),
+	GPIO_FN(FSICOLR),
+	GPIO_FN(FSICILR),
+	GPIO_FN(DU0_DG5),
+	GPIO_FN(IRQ13),
+
+	/* Port14 */
+	GPIO_FN(LCDD14),
+	GPIO_FN(FSICOBT),
+	GPIO_FN(FSICIBT),
+	GPIO_FN(DU0_DG6),
+	GPIO_FN(IRQ14),
+
+	/* Port15 */
+	GPIO_FN(LCDD15),
+	GPIO_FN(FSICOSLD),
+	GPIO_FN(DU0_DG7),
+	GPIO_FN(IRQ15),
+
+	/* Port16 */
+	GPIO_FN(LCDD16),
+	GPIO_FN(TPU1TO1),
+	GPIO_FN(DU0_DB0),
+
+	/* Port17 */
+	GPIO_FN(LCDD17),
+	GPIO_FN(SF_IRQ_00),
+	GPIO_FN(DU0_DB1),
+
+	/* Port18 */
+	GPIO_FN(LCDD18),
+	GPIO_FN(SF_IRQ_01),
+	GPIO_FN(DU0_DB2),
+
+	/* Port19 */
+	GPIO_FN(LCDD19),
+	GPIO_FN(SCIFB3_RTS_19),
+	GPIO_FN(DU0_DB3),
+
+	/* Port20 */
+	GPIO_FN(LCDD20),
+	GPIO_FN(SCIFB3_CTS_20),
+	GPIO_FN(DU0_DB4),
+
+	/* Port21 */
+	GPIO_FN(LCDD21),
+	GPIO_FN(SCIFB3_TXD_21),
+	GPIO_FN(DU0_DB5),
+
+	/* Port22 */
+	GPIO_FN(LCDD22),
+	GPIO_FN(SCIFB3_RXD_22),
+	GPIO_FN(DU0_DB6),
+
+	/* Port23 */
+	GPIO_FN(LCDD23),
+	GPIO_FN(SCIFB3_SCK_23),
+	GPIO_FN(DU0_DB7),
+
+	/* Port24 */
+	GPIO_FN(LCDHSYN),
+	GPIO_FN(LCDCS),
+	GPIO_FN(SCIFB1_RTS_24),
+	GPIO_FN(DU0_EXHSYNC_N_CSYNC_N_HSYNC_N),
+
+	/* Port25 */
+	GPIO_FN(LCDVSYN),
+	GPIO_FN(SCIFB1_CTS_25),
+	GPIO_FN(DU0_EXVSYNC_N_VSYNC_N_CSYNC_N),
+
+	/* Port26 */
+	GPIO_FN(LCDDCK),
+	GPIO_FN(LCDWR),
+	GPIO_FN(SCIFB1_TXD_26),
+	GPIO_FN(DU0_DOTCLKIN),
+
+	/* Port27 */
+	GPIO_FN(LCDDISP),
+	GPIO_FN(LCDRS),
+	GPIO_FN(SCIFB1_RXD_27),
+	GPIO_FN(DU0_DOTCLKOUT),
+
+	/* Port28 */
+	GPIO_FN(LCDRD_N),
+	GPIO_FN(SCIFB1_SCK_28),
+	GPIO_FN(DU0_DOTCLKOUTB),
+
+	/* Port29 */
+	GPIO_FN(LCDLCLK),
+	GPIO_FN(SF_IRQ_02),
+	GPIO_FN(DU0_DISP_CSYNC_N_DE),
+
+	/* Port30 */
+	GPIO_FN(LCDDON),
+	GPIO_FN(SF_IRQ_03),
+	GPIO_FN(DU0_ODDF_N_CLAMP),
+
+	/* Port32 */
+	GPIO_FN(SCIFA0_RTS),
+	GPIO_FN(SIM0_DET),
+	GPIO_FN(CSCIF0_RTS),
+
+	/* Port33 */
+	GPIO_FN(SCIFA0_CTS),
+	GPIO_FN(SIM1_DET),
+	GPIO_FN(CSCIF0_CTS),
+
+	/* Port34 */
+	GPIO_FN(SCIFA0_SCK),
+	GPIO_FN(SIM0_PWRON),
+	GPIO_FN(CSCIF0_SCK),
+
+	/* Port35 */
+	GPIO_FN(SCIFA1_RTS),
+	GPIO_FN(CSCIF1_RTS),
+
+	/* Port36 */
+	GPIO_FN(SCIFA1_CTS),
+	GPIO_FN(CSCIF1_CTS),
+
+	/* Port37 */
+	GPIO_FN(SCIFA1_SCK),
+	GPIO_FN(CSCIF1_SCK),
+
+	/* Port38 */
+	GPIO_FN(SCIFB0_RTS),
+	GPIO_FN(TPU0TO1),
+	GPIO_FN(SCIFB3_RTS_38),
+	GPIO_FN(CHSCIF0_HRTS),
+
+	/* Port39 */
+	GPIO_FN(SCIFB0_CTS),
+	GPIO_FN(TPU0TO2),
+	GPIO_FN(SCIFB3_CTS_39),
+	GPIO_FN(CHSCIF0_HCTS),
+
+	/* Port40 */
+	GPIO_FN(SCIFB0_SCK),
+	GPIO_FN(TPU0TO3),
+	GPIO_FN(SCIFB3_SCK_40),
+	GPIO_FN(CHSCIF0_HSCK),
+
+	/* Port64 */
+	GPIO_FN(PDM0_DATA),
+
+	/* Port65 */
+	GPIO_FN(PDM1_DATA),
+
+	/* Port66 */
+	GPIO_FN(HSI_RX_WAKE),
+	GPIO_FN(SCIFB2_CTS_66),
+	GPIO_FN(MSIOF3_SYNC),
+	GPIO_FN(GenIO4),
+	GPIO_FN(IRQ40),
+
+	/* Port67 */
+	GPIO_FN(HSI_RX_READY),
+	GPIO_FN(SCIFB1_TXD_67),
+	GPIO_FN(GIO_OUT3_67),
+	GPIO_FN(CHSCIF1_HTX),
+
+	/* Port68 */
+	GPIO_FN(HSI_RX_FLAG),
+	GPIO_FN(SCIFB2_TXD_68),
+	GPIO_FN(MSIOF3_TXD),
+	GPIO_FN(GIO_OUT4_68),
+
+	/* Port69 */
+	GPIO_FN(HSI_RX_DATA),
+	GPIO_FN(SCIFB2_RXD_69),
+	GPIO_FN(MSIOF3_RXD),
+	GPIO_FN(GIO_OUT5_69),
+
+	/* Port70 */
+	GPIO_FN(HSI_TX_FLAG),
+	GPIO_FN(SCIFB1_RTS_70),
+	GPIO_FN(GIO_OUT1_70),
+	GPIO_FN(HSIC_TSTCLK0),
+	GPIO_FN(CHSCIF1_HRTS),
+
+	/* Port71 */
+	GPIO_FN(HSI_TX_DATA),
+	GPIO_FN(SCIFB1_CTS_71),
+	GPIO_FN(GIO_OUT2_71),
+	GPIO_FN(HSIC_TSTCLK1),
+	GPIO_FN(CHSCIF1_HCTS),
+
+	/* Port72 */
+	GPIO_FN(HSI_TX_WAKE),
+	GPIO_FN(SCIFB1_RXD_72),
+	GPIO_FN(GenIO8),
+	GPIO_FN(CHSCIF1_HRX),
+
+	/* Port73 */
+	GPIO_FN(HSI_TX_READY),
+	GPIO_FN(SCIFB2_RTS_73),
+	GPIO_FN(MSIOF3_SCK),
+	GPIO_FN(GIO_OUT0_73),
+
+	/* Port74 - Port85 */
+	GPIO_FN(IRDA_OUT),
+	GPIO_FN(IRDA_IN),
+	GPIO_FN(IRDA_FIRSEL),
+	GPIO_FN(TPU0TO0),
+	GPIO_FN(DIGRFEN),
+	GPIO_FN(GPS_TIMESTAMP),
+	GPIO_FN(TXP),
+	GPIO_FN(TXP2),
+	GPIO_FN(COEX_0),
+	GPIO_FN(COEX_1),
+	GPIO_FN(IRQ19),
+	GPIO_FN(IRQ18),
+
+	/* Port96 - Port101 */
+	GPIO_FN(KEYIN0),
+	GPIO_FN(KEYIN1),
+	GPIO_FN(KEYIN2),
+	GPIO_FN(KEYIN3),
+	GPIO_FN(KEYIN4),
+	GPIO_FN(KEYIN5),
+
+	/* Port102 */
+	GPIO_FN(KEYIN6),
+	GPIO_FN(IRQ41),
+
+	/* Port103 */
+	GPIO_FN(KEYIN7),
+	GPIO_FN(IRQ42),
+
+	/* Port104 - Port108 */
+	GPIO_FN(KEYOUT0),
+	GPIO_FN(KEYOUT1),
+	GPIO_FN(KEYOUT2),
+	GPIO_FN(KEYOUT3),
+	GPIO_FN(KEYOUT4),
+
+	/* Port109 */
+	GPIO_FN(KEYOUT5),
+	GPIO_FN(IRQ43),
+
+	/* Port110 */
+	GPIO_FN(KEYOUT6),
+	GPIO_FN(IRQ44),
+
+	/* Port111 */
+	GPIO_FN(KEYOUT7),
+	GPIO_FN(RFANAEN),
+	GPIO_FN(IRQ45),
+
+	/* Port112 */
+	GPIO_FN(KEYIN8),
+	GPIO_FN(KEYOUT8),
+	GPIO_FN(SF_IRQ_04),
+	GPIO_FN(IRQ46),
+
+	/* Port113 */
+	GPIO_FN(KEYIN9),
+	GPIO_FN(KEYOUT9),
+	GPIO_FN(SF_IRQ_05),
+	GPIO_FN(IRQ47),
+
+	/* Port114 */
+	GPIO_FN(KEYIN10),
+	GPIO_FN(KEYOUT10),
+	GPIO_FN(SF_IRQ_06),
+	GPIO_FN(IRQ48),
+
+	/* Port115 */
+	GPIO_FN(KEYIN11),
+	GPIO_FN(KEYOUT11),
+	GPIO_FN(SF_IRQ_07),
+	GPIO_FN(IRQ49),
+
+	/* Port116 */
+	GPIO_FN(SCIFA0_TXD),
+	GPIO_FN(CSCIF0_TX),
+
+	/* Port117 */
+	GPIO_FN(SCIFA0_RXD),
+	GPIO_FN(CSCIF0_RX),
+
+	/* Port118 */
+	GPIO_FN(SCIFA1_TXD),
+	GPIO_FN(CSCIF1_TX),
+
+	/* Port119 */
+	GPIO_FN(SCIFA1_RXD),
+	GPIO_FN(CSCIF1_RX),
+
+	/* Port120 */
+	GPIO_FN(SF_PORT_1_120),
+	GPIO_FN(SCIFB3_RXD_120),
+	GPIO_FN(DU0_CDE),
+
+	/* Port121 */
+	GPIO_FN(SF_PORT_0_121),
+	GPIO_FN(SCIFB3_TXD_121),
+
+	/* Port122 */
+	GPIO_FN(SCIFB0_TXD),
+	GPIO_FN(CHSCIF0_HTX),
+
+	/* Port123 */
+	GPIO_FN(SCIFB0_RXD),
+	GPIO_FN(CHSCIF0_HRX),
+
+	/* Port124 */
+	GPIO_FN(ISP_STROBE_124),
+
+	/* Port125 */
+	GPIO_FN(STP_ISD_0),
+	GPIO_FN(PDM4_CLK_125),
+	GPIO_FN(MSIOF2_TXD),
+	GPIO_FN(SIM0_VOLTSEL0),
+
+	/* Port126 */
+	GPIO_FN(TS_SDEN),
+	GPIO_FN(MSIOF7_SYNC),
+	GPIO_FN(STP_ISEN_1),
+
+	/* Port128 */
+	GPIO_FN(STP_ISEN_0),
+	GPIO_FN(PDM1_OUTDATA_128),
+	GPIO_FN(MSIOF2_SYNC),
+	GPIO_FN(SIM1_VOLTSEL1),
+
+	/* Port129 */
+	GPIO_FN(TS_SPSYNC),
+	GPIO_FN(MSIOF7_RXD),
+	GPIO_FN(STP_ISSYNC_1),
+
+	/* Port130 */
+	GPIO_FN(STP_ISSYNC_0),
+	GPIO_FN(PDM4_DATA_130),
+	GPIO_FN(MSIOF2_RXD),
+	GPIO_FN(SIM0_VOLTSEL1),
+
+	/* Port131 */
+	GPIO_FN(STP_OPWM_0),
+	GPIO_FN(SIM1_PWRON),
+
+	/* Port132 */
+	GPIO_FN(TS_SCK),
+	GPIO_FN(MSIOF7_SCK),
+	GPIO_FN(STP_ISCLK_1),
+
+	/* Port133 */
+	GPIO_FN(STP_ISCLK_0),
+	GPIO_FN(PDM1_OUTCLK_133),
+	GPIO_FN(MSIOF2_SCK),
+	GPIO_FN(SIM1_VOLTSEL0),
+
+	/* Port134 */
+	GPIO_FN(TS_SDAT),
+	GPIO_FN(MSIOF7_TXD),
+	GPIO_FN(STP_ISD_1),
+
+	/* Port160 - Port178 */
+	GPIO_FN(IRQ20),
+	GPIO_FN(IRQ21),
+	GPIO_FN(IRQ22),
+	GPIO_FN(IRQ23),
+	GPIO_FN(MMCD0_0),
+	GPIO_FN(MMCD0_1),
+	GPIO_FN(MMCD0_2),
+	GPIO_FN(MMCD0_3),
+	GPIO_FN(MMCD0_4),
+	GPIO_FN(MMCD0_5),
+	GPIO_FN(MMCD0_6),
+	GPIO_FN(MMCD0_7),
+	GPIO_FN(MMCCMD0),
+	GPIO_FN(MMCCLK0),
+	GPIO_FN(MMCRST),
+	GPIO_FN(IRQ24),
+	GPIO_FN(IRQ25),
+	GPIO_FN(IRQ26),
+	GPIO_FN(IRQ27),
+
+	/* Port192 - Port200 FN1 */
+	GPIO_FN(A10),
+	GPIO_FN(A9),
+	GPIO_FN(A8),
+	GPIO_FN(A7),
+	GPIO_FN(A6),
+	GPIO_FN(A5),
+	GPIO_FN(A4),
+	GPIO_FN(A3),
+	GPIO_FN(A2),
+
+	/* Port192 - Port200 FN2 */
+	GPIO_FN(MMCD1_7),
+	GPIO_FN(MMCD1_6),
+	GPIO_FN(MMCD1_5),
+	GPIO_FN(MMCD1_4),
+	GPIO_FN(MMCD1_3),
+	GPIO_FN(MMCD1_2),
+	GPIO_FN(MMCD1_1),
+	GPIO_FN(MMCD1_0),
+	GPIO_FN(MMCCMD1),
+
+	/* Port192 - Port200 IRQ */
+	GPIO_FN(IRQ31),
+	GPIO_FN(IRQ32),
+	GPIO_FN(IRQ33),
+	GPIO_FN(IRQ34),
+	GPIO_FN(IRQ35),
+	GPIO_FN(IRQ36),
+	GPIO_FN(IRQ37),
+	GPIO_FN(IRQ38),
+	GPIO_FN(IRQ39),
+
+	/* Port201 */
+	GPIO_FN(A1),
+
+	/* Port202 */
+	GPIO_FN(A0),
+	GPIO_FN(BS),
+
+	/* Port203 */
+	GPIO_FN(CKO),
+	GPIO_FN(MMCCLK1),
+
+	/* Port204 */
+	GPIO_FN(CS0_N),
+	GPIO_FN(SIM0_GPO1),
+
+	/* Port205 */
+	GPIO_FN(CS2_N),
+	GPIO_FN(SIM0_GPO2),
+
+	/* Port206 */
+	GPIO_FN(CS4_N),
+	GPIO_FN(VIO_VD),
+	GPIO_FN(SIM1_GPO0),
+
+	/* Port207 - Port212 FN1 */
+	GPIO_FN(D15),
+	GPIO_FN(D14),
+	GPIO_FN(D13),
+	GPIO_FN(D12),
+	GPIO_FN(D11),
+	GPIO_FN(D10),
+
+	/* Port207 - Port212 FN5 */
+	GPIO_FN(GIO_OUT15),
+	GPIO_FN(GIO_OUT14),
+	GPIO_FN(GIO_OUT13),
+	GPIO_FN(GIO_OUT12),
+	GPIO_FN(WGM_TXP2),
+	GPIO_FN(WGM_GPS_TIMEM_ASK_RFCLK),
+
+	/* Port213 - Port222 FN1 */
+	GPIO_FN(D9),
+	GPIO_FN(D8),
+	GPIO_FN(D7),
+	GPIO_FN(D6),
+	GPIO_FN(D5),
+	GPIO_FN(D4),
+	GPIO_FN(D3),
+	GPIO_FN(D2),
+	GPIO_FN(D1),
+	GPIO_FN(D0),
+
+	/* Port213 - Port222 FN2 */
+	GPIO_FN(VIO_D9),
+	GPIO_FN(VIO_D8),
+	GPIO_FN(VIO_D7),
+	GPIO_FN(VIO_D6),
+	GPIO_FN(VIO_D5),
+	GPIO_FN(VIO_D4),
+	GPIO_FN(VIO_D3),
+	GPIO_FN(VIO_D2),
+	GPIO_FN(VIO_D1),
+	GPIO_FN(VIO_D0),
+
+	/* Port213 - Port222 FN5 */
+	GPIO_FN(GIO_OUT9),
+	GPIO_FN(GIO_OUT8),
+	GPIO_FN(GIO_OUT7),
+	GPIO_FN(GIO_OUT6),
+	GPIO_FN(GIO_OUT5_217),
+	GPIO_FN(GIO_OUT4_218),
+	GPIO_FN(GIO_OUT3_219),
+	GPIO_FN(GIO_OUT2_220),
+	GPIO_FN(GIO_OUT1_221),
+	GPIO_FN(GIO_OUT0_222),
+
+	/* Port224 */
+	GPIO_FN(RDWR_224),
+	GPIO_FN(VIO_HD),
+	GPIO_FN(SIM1_GPO2),
+
+	/* Port225 */
+	GPIO_FN(RD_N),
+
+	/* Port226 */
+	GPIO_FN(WAIT_N),
+	GPIO_FN(VIO_CLK),
+	GPIO_FN(SIM1_GPO1),
+
+	/* Port227 */
+	GPIO_FN(WE0_N),
+	GPIO_FN(RDWR_227),
+
+	/* Port228 */
+	GPIO_FN(WE1_N),
+	GPIO_FN(SIM0_GPO0),
+
+	/* Port229 */
+	GPIO_FN(PWMO),
+	GPIO_FN(VIO_CKO1_229),
+
+	/* Port230 */
+	GPIO_FN(SLIM_CLK),
+	GPIO_FN(VIO_CKO4_230),
+
+	/* Port231 */
+	GPIO_FN(SLIM_DATA),
+	GPIO_FN(VIO_CKO5_231),
+
+	/* Port232 */
+	GPIO_FN(VIO_CKO2_232),
+	GPIO_FN(SF_PORT_0_232),
+
+	/* Port233 */
+	GPIO_FN(VIO_CKO3_233),
+	GPIO_FN(SF_PORT_1_233),
+
+	/* Port234 */
+	GPIO_FN(FSIACK),
+	GPIO_FN(PDM3_CLK_234),
+	GPIO_FN(ISP_IRIS1_234),
+
+	/* Port235 */
+	GPIO_FN(FSIAISLD),
+	GPIO_FN(PDM3_DATA_235),
+
+	/* Port236 */
+	GPIO_FN(FSIAOMC),
+	GPIO_FN(PDM0_OUTCLK_236),
+	GPIO_FN(ISP_IRIS0_236),
+
+	/* Port237 */
+	GPIO_FN(FSIAOLR),
+	GPIO_FN(FSIAILR),
+
+	/* Port238 */
+	GPIO_FN(FSIAOBT),
+	GPIO_FN(FSIAIBT),
+
+	/* Port239 */
+	GPIO_FN(FSIAOSLD),
+	GPIO_FN(PDM0_OUTDATA_239),
+
+	/* Port240 */
+	GPIO_FN(FSIBISLD),
+
+	/* Port241 */
+	GPIO_FN(FSIBOLR),
+	GPIO_FN(FSIBILR),
+
+	/* Port242 */
+	GPIO_FN(FSIBOMC),
+	GPIO_FN(ISP_SHUTTER1_242),
+
+	/* Port243 */
+	GPIO_FN(FSIBOBT),
+	GPIO_FN(FSIBIBT),
+
+	/* Port244 */
+	GPIO_FN(FSIBOSLD),
+	GPIO_FN(FSIASPDIF),
+
+	/* Port245 */
+	GPIO_FN(FSIBCK),
+	GPIO_FN(ISP_SHUTTER0_245),
+
+	/* Port246 - Port250 FN1 */
+	GPIO_FN(ISP_IRIS1_246),
+	GPIO_FN(ISP_IRIS0_247),
+	GPIO_FN(ISP_SHUTTER1_248),
+	GPIO_FN(ISP_SHUTTER0_249),
+	GPIO_FN(ISP_STROBE_250),
+
+	/* Port256 - Port258 */
+	GPIO_FN(MSIOF0_SYNC),
+	GPIO_FN(MSIOF0_RXD),
+	GPIO_FN(MSIOF0_SCK),
+
+	/* Port259 */
+	GPIO_FN(MSIOF0_SS2),
+	GPIO_FN(VIO_CKO3_259),
+
+	/* Port260 */
+	GPIO_FN(MSIOF0_TXD),
+
+	/* Port261 */
+	GPIO_FN(SCIFB1_SCK_261),
+	GPIO_FN(CHSCIF1_HSCK),
+
+	/* Port262 */
+	GPIO_FN(SCIFB2_SCK_262),
+
+	/* Port263 - Port266 FN1 */
+	GPIO_FN(MSIOF1_SS2),
+	GPIO_FN(MSIOF1_TXD),
+	GPIO_FN(MSIOF1_RXD),
+	GPIO_FN(MSIOF1_SS1),
+
+	/* Port263 - Port266 FN4 */
+	GPIO_FN(MSIOF5_SS2),
+	GPIO_FN(MSIOF5_TXD),
+	GPIO_FN(MSIOF5_RXD),
+	GPIO_FN(MSIOF5_SS1),
+
+	/* Port267 */
+	GPIO_FN(MSIOF0_SS1),
+
+	/* Port268 */
+	GPIO_FN(MSIOF1_SCK),
+	GPIO_FN(MSIOF5_SCK),
+
+	/* Port269 */
+	GPIO_FN(MSIOF1_SYNC),
+	GPIO_FN(MSIOF5_SYNC),
+
+	/* Port270 - Port273 FN1 */
+	GPIO_FN(MSIOF2_SS1),
+	GPIO_FN(MSIOF2_SS2),
+	GPIO_FN(MSIOF3_SS2),
+	GPIO_FN(MSIOF3_SS1),
+
+	/* Port270 - Port273 FN3 */
+	GPIO_FN(VIO_CKO5_270),
+	GPIO_FN(VIO_CKO2_271),
+	GPIO_FN(VIO_CKO1_272),
+	GPIO_FN(VIO_CKO4_273),
+
+	/* Port274 */
+	GPIO_FN(MSIOF4_SS2),
+	GPIO_FN(TPU1TO0),
+
+	/* Port275 - Port280 */
+	GPIO_FN(IC_DP),
+	GPIO_FN(SIM0_RST),
+	GPIO_FN(IC_DM),
+	GPIO_FN(SIM0_BSICOMP),
+	GPIO_FN(SIM0_CLK),
+	GPIO_FN(SIM0_IO),
+
+	/* Port281 */
+	GPIO_FN(SIM1_IO),
+	GPIO_FN(PDM2_DATA_281),
+
+	/* Port282 */
+	GPIO_FN(SIM1_CLK),
+	GPIO_FN(PDM2_CLK_282),
+
+	/* Port283 */
+	GPIO_FN(SIM1_RST),
+
+	/* Port289 */
+	GPIO_FN(SDHID1_0),
+	GPIO_FN(STMDATA0_2),
+
+	/* Port290 */
+	GPIO_FN(SDHID1_1),
+	GPIO_FN(STMDATA1_2),
+	GPIO_FN(IRQ51),
+
+	/* Port291 - Port294 FN1 */
+	GPIO_FN(SDHID1_2),
+	GPIO_FN(SDHID1_3),
+	GPIO_FN(SDHICLK1),
+	GPIO_FN(SDHICMD1),
+
+	/* Port291 - Port294 FN3 */
+	GPIO_FN(STMDATA2_2),
+	GPIO_FN(STMDATA3_2),
+	GPIO_FN(STMCLK_2),
+	GPIO_FN(STMSIDI_2),
+
+	/* Port295 */
+	GPIO_FN(SDHID2_0),
+	GPIO_FN(MSIOF4_TXD),
+	GPIO_FN(SCIFB2_TXD_295),
+	GPIO_FN(MSIOF6_TXD),
+
+	/* Port296 */
+	GPIO_FN(SDHID2_1),
+	GPIO_FN(MSIOF6_SS2),
+	GPIO_FN(IRQ52),
+
+	/* Port297 - Port300 FN1 */
+	GPIO_FN(SDHID2_2),
+	GPIO_FN(SDHID2_3),
+	GPIO_FN(SDHICLK2),
+	GPIO_FN(SDHICMD2),
+
+	/* Port297 - Port300 FN2 */
+	GPIO_FN(MSIOF4_RXD),
+	GPIO_FN(MSIOF4_SYNC),
+	GPIO_FN(MSIOF4_SCK),
+	GPIO_FN(MSIOF4_SS1),
+
+	/* Port297 - Port300 FN3 */
+	GPIO_FN(SCIFB2_RXD_297),
+	GPIO_FN(SCIFB2_CTS_298),
+	GPIO_FN(SCIFB2_SCK_299),
+	GPIO_FN(SCIFB2_RTS_300),
+
+	/* Port297 - Port300 FN4 */
+	GPIO_FN(MSIOF6_RXD),
+	GPIO_FN(MSIOF6_SYNC),
+	GPIO_FN(MSIOF6_SCK),
+	GPIO_FN(MSIOF6_SS1),
+
+	/* Port301 */
+	GPIO_FN(SDHICD0),
+	GPIO_FN(IRQ50),
+
+	/* Port302 - Port306 FN1 */
+	GPIO_FN(SDHID0_0),
+	GPIO_FN(SDHID0_1),
+	GPIO_FN(SDHID0_2),
+	GPIO_FN(SDHID0_3),
+	GPIO_FN(SDHICMD0),
+
+	/* Port302 - Port306 FN3 */
+	GPIO_FN(STMDATA0_1),
+	GPIO_FN(STMDATA1_1),
+	GPIO_FN(STMDATA2_1),
+	GPIO_FN(STMDATA3_1),
+	GPIO_FN(STMSIDI_1),
+
+	/* Port307 */
+	GPIO_FN(SDHIWP0),
+
+	/* Port308 */
+	GPIO_FN(SDHICLK0),
+	GPIO_FN(STMCLK_1),
+
+	/* Port320 - Port329 */
+	GPIO_FN(IRQ16),
+	GPIO_FN(IRQ17),
+	GPIO_FN(IRQ28),
+	GPIO_FN(IRQ29),
+	GPIO_FN(IRQ30),
+	GPIO_FN(IRQ53),
+	GPIO_FN(IRQ54),
+	GPIO_FN(IRQ55),
+	GPIO_FN(IRQ56),
+	GPIO_FN(IRQ57),
+};
+
+static const struct pinmux_cfg_reg pinmux_config_regs[] = {
+
+	PORTCR(0, 0xe6050000),
+	PORTCR(1, 0xe6050001),
+	PORTCR(2, 0xe6050002),
+	PORTCR(3, 0xe6050003),
+	PORTCR(4, 0xe6050004),
+	PORTCR(5, 0xe6050005),
+	PORTCR(6, 0xe6050006),
+	PORTCR(7, 0xe6050007),
+	PORTCR(8, 0xe6050008),
+	PORTCR(9, 0xe6050009),
+	PORTCR(10, 0xe605000A),
+	PORTCR(11, 0xe605000B),
+	PORTCR(12, 0xe605000C),
+	PORTCR(13, 0xe605000D),
+	PORTCR(14, 0xe605000E),
+	PORTCR(15, 0xe605000F),
+	PORTCR(16, 0xe6050010),
+	PORTCR(17, 0xe6050011),
+	PORTCR(18, 0xe6050012),
+	PORTCR(19, 0xe6050013),
+	PORTCR(20, 0xe6050014),
+	PORTCR(21, 0xe6050015),
+	PORTCR(22, 0xe6050016),
+	PORTCR(23, 0xe6050017),
+	PORTCR(24, 0xe6050018),
+	PORTCR(25, 0xe6050019),
+	PORTCR(26, 0xe605001A),
+	PORTCR(27, 0xe605001B),
+	PORTCR(28, 0xe605001C),
+	PORTCR(29, 0xe605001D),
+	PORTCR(30, 0xe605001E),
+	PORTCR(32, 0xe6051020),
+	PORTCR(33, 0xe6051021),
+	PORTCR(34, 0xe6051022),
+	PORTCR(35, 0xe6051023),
+	PORTCR(36, 0xe6051024),
+	PORTCR(37, 0xe6051025),
+	PORTCR(38, 0xe6051026),
+	PORTCR(39, 0xe6051027),
+	PORTCR(40, 0xe6051028),
+	PORTCR(64, 0xe6050040),
+	PORTCR(65, 0xe6050041),
+	PORTCR(66, 0xe6050042),
+	PORTCR(67, 0xe6050043),
+	PORTCR(68, 0xe6050044),
+	PORTCR(69, 0xe6050045),
+	PORTCR(70, 0xe6050046),
+	PORTCR(71, 0xe6050047),
+	PORTCR(72, 0xe6050048),
+	PORTCR(73, 0xe6050049),
+	PORTCR(74, 0xe605004A),
+	PORTCR(75, 0xe605004B),
+	PORTCR(76, 0xe605004C),
+	PORTCR(77, 0xe605004D),
+	PORTCR(78, 0xe605004E),
+	PORTCR(79, 0xe605004F),
+	PORTCR(80, 0xe6050050),
+	PORTCR(81, 0xe6050051),
+	PORTCR(82, 0xe6050052),
+	PORTCR(83, 0xe6050053),
+	PORTCR(84, 0xe6050054),
+	PORTCR(85, 0xe6050055),
+	PORTCR(96, 0xe6051060),
+	PORTCR(97, 0xe6051061),
+	PORTCR(98, 0xe6051062),
+	PORTCR(99, 0xe6051063),
+	PORTCR(100, 0xe6051064),
+	PORTCR(101, 0xe6051065),
+	PORTCR(102, 0xe6051066),
+	PORTCR(103, 0xe6051067),
+	PORTCR(104, 0xe6051068),
+	PORTCR(105, 0xe6051069),
+	PORTCR(106, 0xe605106A),
+	PORTCR(107, 0xe605106B),
+	PORTCR(108, 0xe605106C),
+	PORTCR(109, 0xe605106D),
+	PORTCR(110, 0xe605106E),
+	PORTCR(111, 0xe605106F),
+	PORTCR(112, 0xe6051070),
+	PORTCR(113, 0xe6051071),
+	PORTCR(114, 0xe6051072),
+	PORTCR(115, 0xe6051073),
+	PORTCR(116, 0xe6051074),
+	PORTCR(117, 0xe6051075),
+	PORTCR(118, 0xe6051076),
+	PORTCR(119, 0xe6051077),
+	PORTCR(120, 0xe6051078),
+	PORTCR(121, 0xe6051079),
+	PORTCR(122, 0xe605107A),
+	PORTCR(123, 0xe605107B),
+	PORTCR(124, 0xe605107C),
+	PORTCR(125, 0xe605107D),
+	PORTCR(126, 0xe605107E),
+	PORTCR(128, 0xe6051080),
+	PORTCR(129, 0xe6051081),
+	PORTCR(130, 0xe6051082),
+	PORTCR(131, 0xe6051083),
+	PORTCR(132, 0xe6051084),
+	PORTCR(133, 0xe6051085),
+	PORTCR(134, 0xe6051086),
+	PORTCR(160, 0xe60520A0),
+	PORTCR(161, 0xe60520A1),
+	PORTCR(162, 0xe60520A2),
+	PORTCR(163, 0xe60520A3),
+	PORTCR(164, 0xe60520A4),
+	PORTCR(165, 0xe60520A5),
+	PORTCR(166, 0xe60520A6),
+	PORTCR(167, 0xe60520A7),
+	PORTCR(168, 0xe60520A8),
+	PORTCR(169, 0xe60520A9),
+	PORTCR(170, 0xe60520AA),
+	PORTCR(171, 0xe60520AB),
+	PORTCR(172, 0xe60520AC),
+	PORTCR(173, 0xe60520AD),
+	PORTCR(174, 0xe60520AE),
+	PORTCR(175, 0xe60520AF),
+	PORTCR(176, 0xe60520B0),
+	PORTCR(177, 0xe60520B1),
+	PORTCR(178, 0xe60520B2),
+	PORTCR(192, 0xe60520C0),
+	PORTCR(193, 0xe60520C1),
+	PORTCR(194, 0xe60520C2),
+	PORTCR(195, 0xe60520C3),
+	PORTCR(196, 0xe60520C4),
+	PORTCR(197, 0xe60520C5),
+	PORTCR(198, 0xe60520C6),
+	PORTCR(199, 0xe60520C7),
+	PORTCR(200, 0xe60520C8),
+	PORTCR(201, 0xe60520C9),
+	PORTCR(202, 0xe60520CA),
+	PORTCR(203, 0xe60520CB),
+	PORTCR(204, 0xe60520CC),
+	PORTCR(205, 0xe60520CD),
+	PORTCR(206, 0xe60520CE),
+	PORTCR(207, 0xe60520CF),
+	PORTCR(208, 0xe60520D0),
+	PORTCR(209, 0xe60520D1),
+	PORTCR(210, 0xe60520D2),
+	PORTCR(211, 0xe60520D3),
+	PORTCR(212, 0xe60520D4),
+	PORTCR(213, 0xe60520D5),
+	PORTCR(214, 0xe60520D6),
+	PORTCR(215, 0xe60520D7),
+	PORTCR(216, 0xe60520D8),
+	PORTCR(217, 0xe60520D9),
+	PORTCR(218, 0xe60520DA),
+	PORTCR(219, 0xe60520DB),
+	PORTCR(220, 0xe60520DC),
+	PORTCR(221, 0xe60520DD),
+	PORTCR(222, 0xe60520DE),
+	PORTCR(224, 0xe60520E0),
+	PORTCR(225, 0xe60520E1),
+	PORTCR(226, 0xe60520E2),
+	PORTCR(227, 0xe60520E3),
+	PORTCR(228, 0xe60520E4),
+	PORTCR(229, 0xe60520E5),
+	PORTCR(230, 0xe60520e6),
+	PORTCR(231, 0xe60520E7),
+	PORTCR(232, 0xe60520E8),
+	PORTCR(233, 0xe60520E9),
+	PORTCR(234, 0xe60520EA),
+	PORTCR(235, 0xe60520EB),
+	PORTCR(236, 0xe60520EC),
+	PORTCR(237, 0xe60520ED),
+	PORTCR(238, 0xe60520EE),
+	PORTCR(239, 0xe60520EF),
+	PORTCR(240, 0xe60520F0),
+	PORTCR(241, 0xe60520F1),
+	PORTCR(242, 0xe60520F2),
+	PORTCR(243, 0xe60520F3),
+	PORTCR(244, 0xe60520F4),
+	PORTCR(245, 0xe60520F5),
+	PORTCR(246, 0xe60520F6),
+	PORTCR(247, 0xe60520F7),
+	PORTCR(248, 0xe60520F8),
+	PORTCR(249, 0xe60520F9),
+	PORTCR(250, 0xe60520FA),
+	PORTCR(256, 0xe6052100),
+	PORTCR(257, 0xe6052101),
+	PORTCR(258, 0xe6052102),
+	PORTCR(259, 0xe6052103),
+	PORTCR(260, 0xe6052104),
+	PORTCR(261, 0xe6052105),
+	PORTCR(262, 0xe6052106),
+	PORTCR(263, 0xe6052107),
+	PORTCR(264, 0xe6052108),
+	PORTCR(265, 0xe6052109),
+	PORTCR(266, 0xe605210A),
+	PORTCR(267, 0xe605210B),
+	PORTCR(268, 0xe605210C),
+	PORTCR(269, 0xe605210D),
+	PORTCR(270, 0xe605210E),
+	PORTCR(271, 0xe605210F),
+	PORTCR(272, 0xe6052110),
+	PORTCR(273, 0xe6052111),
+	PORTCR(274, 0xe6052112),
+	PORTCR(275, 0xe6052113),
+	PORTCR(276, 0xe6052114),
+	PORTCR(277, 0xe6052115),
+	PORTCR(278, 0xe6052116),
+	PORTCR(279, 0xe6052117),
+	PORTCR(280, 0xe6052118),
+	PORTCR(281, 0xe6052119),
+	PORTCR(282, 0xe605211A),
+	PORTCR(283, 0xe605211B),
+	PORTCR(288, 0xe6053120),
+	PORTCR(289, 0xe6053121),
+	PORTCR(290, 0xe6053122),
+	PORTCR(291, 0xe6053123),
+	PORTCR(292, 0xe6053124),
+	PORTCR(293, 0xe6053125),
+	PORTCR(294, 0xe6053126),
+	PORTCR(295, 0xe6053127),
+	PORTCR(296, 0xe6053128),
+	PORTCR(297, 0xe6053129),
+	PORTCR(298, 0xe605312A),
+	PORTCR(299, 0xe605312B),
+	PORTCR(300, 0xe605312C),
+	PORTCR(301, 0xe605312D),
+	PORTCR(302, 0xe605312E),
+	PORTCR(303, 0xe605312F),
+	PORTCR(304, 0xe6053130),
+	PORTCR(305, 0xe6053131),
+	PORTCR(306, 0xe6053132),
+	PORTCR(307, 0xe6053133),
+	PORTCR(308, 0xe6053134),
+	PORTCR(320, 0xe6053140),
+	PORTCR(321, 0xe6053141),
+	PORTCR(322, 0xe6053142),
+	PORTCR(323, 0xe6053143),
+	PORTCR(324, 0xe6053144),
+	PORTCR(325, 0xe6053145),
+	PORTCR(326, 0xe6053146),
+	PORTCR(327, 0xe6053147),
+	PORTCR(328, 0xe6053148),
+	PORTCR(329, 0xe6053149),
+
+	{ PINMUX_CFG_REG("MSEL1CR", 0xe605800c, 32, 1) {
+			MSEL1CR_31_0, MSEL1CR_31_1,
+			0, 0,
+			0, 0,
+			0, 0,
+			MSEL1CR_27_0, MSEL1CR_27_1,
+			0, 0,
+			MSEL1CR_25_0, MSEL1CR_25_1,
+			MSEL1CR_24_0, MSEL1CR_24_1,
+			0, 0,
+			MSEL1CR_22_0, MSEL1CR_22_1,
+			MSEL1CR_21_0, MSEL1CR_21_1,
+			MSEL1CR_20_0, MSEL1CR_20_1,
+			MSEL1CR_19_0, MSEL1CR_19_1,
+			MSEL1CR_18_0, MSEL1CR_18_1,
+			MSEL1CR_17_0, MSEL1CR_17_1,
+			MSEL1CR_16_0, MSEL1CR_16_1,
+			MSEL1CR_15_0, MSEL1CR_15_1,
+			MSEL1CR_14_0, MSEL1CR_14_1,
+			MSEL1CR_13_0, MSEL1CR_13_1,
+			MSEL1CR_12_0, MSEL1CR_12_1,
+			MSEL1CR_11_0, MSEL1CR_11_1,
+			MSEL1CR_10_0, MSEL1CR_10_1,
+			MSEL1CR_09_0, MSEL1CR_09_1,
+			MSEL1CR_08_0, MSEL1CR_08_1,
+			MSEL1CR_07_0, MSEL1CR_07_1,
+			MSEL1CR_06_0, MSEL1CR_06_1,
+			MSEL1CR_05_0, MSEL1CR_05_1,
+			MSEL1CR_04_0, MSEL1CR_04_1,
+			MSEL1CR_03_0, MSEL1CR_03_1,
+			MSEL1CR_02_0, MSEL1CR_02_1,
+			MSEL1CR_01_0, MSEL1CR_01_1,
+			MSEL1CR_00_0, MSEL1CR_00_1,
+		}
+	},
+	{ PINMUX_CFG_REG("MSEL3CR", 0xe6058020, 32, 1) {
+			MSEL3CR_31_0, MSEL3CR_31_1,
+			0, 0,
+			0, 0,
+			MSEL3CR_28_0, MSEL3CR_28_1,
+			MSEL3CR_27_0, MSEL3CR_27_1,
+			MSEL3CR_26_0, MSEL3CR_26_1,
+			0, 0,
+			0, 0,
+			MSEL3CR_23_0, MSEL3CR_23_1,
+			MSEL3CR_22_0, MSEL3CR_22_1,
+			MSEL3CR_21_0, MSEL3CR_21_1,
+			MSEL3CR_20_0, MSEL3CR_20_1,
+			MSEL3CR_19_0, MSEL3CR_19_1,
+			MSEL3CR_18_0, MSEL3CR_18_1,
+			MSEL3CR_17_0, MSEL3CR_17_1,
+			MSEL3CR_16_0, MSEL3CR_16_1,
+			MSEL3CR_15_0, MSEL3CR_15_1,
+			0, 0,
+			0, 0,
+			MSEL3CR_12_0, MSEL3CR_12_1,
+			MSEL3CR_11_0, MSEL3CR_11_1,
+			MSEL3CR_10_0, MSEL3CR_10_1,
+			MSEL3CR_09_0, MSEL3CR_09_1,
+			0, 0,
+			0, 0,
+			MSEL3CR_06_0, MSEL3CR_06_1,
+			0, 0,
+			0, 0,
+			MSEL3CR_03_0, MSEL3CR_03_1,
+			0, 0,
+			MSEL3CR_01_0, MSEL3CR_01_1,
+			MSEL3CR_00_0, MSEL3CR_00_1,
+			}
+	},
+	{ PINMUX_CFG_REG("MSEL4CR", 0xe6058024, 32, 1) {
+			0, 0,
+			MSEL4CR_30_0, MSEL4CR_30_1,
+			MSEL4CR_29_0, MSEL4CR_29_1,
+			MSEL4CR_28_0, MSEL4CR_28_1,
+			MSEL4CR_27_0, MSEL4CR_27_1,
+			MSEL4CR_26_0, MSEL4CR_26_1,
+			MSEL4CR_25_0, MSEL4CR_25_1,
+			MSEL4CR_24_0, MSEL4CR_24_1,
+			MSEL4CR_23_0, MSEL4CR_23_1,
+			MSEL4CR_22_0, MSEL4CR_22_1,
+			MSEL4CR_21_0, MSEL4CR_21_1,
+			MSEL4CR_20_0, MSEL4CR_20_1,
+			MSEL4CR_19_0, MSEL4CR_19_1,
+			MSEL4CR_18_0, MSEL4CR_18_1,
+			MSEL4CR_17_0, MSEL4CR_17_1,
+			MSEL4CR_16_0, MSEL4CR_16_1,
+			MSEL4CR_15_0, MSEL4CR_15_1,
+			MSEL4CR_14_0, MSEL4CR_14_1,
+			MSEL4CR_13_0, MSEL4CR_13_1,
+			MSEL4CR_12_0, MSEL4CR_12_1,
+			MSEL4CR_11_0, MSEL4CR_11_1,
+			MSEL4CR_10_0, MSEL4CR_10_1,
+			MSEL4CR_09_0, MSEL4CR_09_1,
+			0, 0,
+			MSEL4CR_07_0, MSEL4CR_07_1,
+			0, 0,
+			0, 0,
+			MSEL4CR_04_0, MSEL4CR_04_1,
+			0, 0,
+			0, 0,
+			MSEL4CR_01_0, MSEL4CR_01_1,
+			0, 0,
+		}
+	},
+	{ PINMUX_CFG_REG("MSEL5CR", 0xe6058028, 32, 1) {
+			MSEL5CR_31_0, MSEL5CR_31_1,
+			MSEL5CR_30_0, MSEL5CR_30_1,
+			MSEL5CR_29_0, MSEL5CR_29_1,
+			MSEL5CR_28_0, MSEL5CR_28_1,
+			MSEL5CR_27_0, MSEL5CR_27_1,
+			MSEL5CR_26_0, MSEL5CR_26_1,
+			MSEL5CR_25_0, MSEL5CR_25_1,
+			MSEL5CR_24_0, MSEL5CR_24_1,
+			MSEL5CR_23_0, MSEL5CR_23_1,
+			MSEL5CR_22_0, MSEL5CR_22_1,
+			MSEL5CR_21_0, MSEL5CR_21_1,
+			MSEL5CR_20_0, MSEL5CR_20_1,
+			MSEL5CR_19_0, MSEL5CR_19_1,
+			MSEL5CR_18_0, MSEL5CR_18_1,
+			MSEL5CR_17_0, MSEL5CR_17_1,
+			MSEL5CR_16_0, MSEL5CR_16_1,
+			MSEL5CR_15_0, MSEL5CR_15_1,
+			MSEL5CR_14_0, MSEL5CR_14_1,
+			MSEL5CR_13_0, MSEL5CR_13_1,
+			MSEL5CR_12_0, MSEL5CR_12_1,
+			MSEL5CR_11_0, MSEL5CR_11_1,
+			MSEL5CR_10_0, MSEL5CR_10_1,
+			MSEL5CR_09_0, MSEL5CR_09_1,
+			MSEL5CR_08_0, MSEL5CR_08_1,
+			MSEL5CR_07_0, MSEL5CR_07_1,
+			MSEL5CR_06_0, MSEL5CR_06_1,
+			0, 0,
+			0, 0,
+			0, 0,
+			0, 0,
+			0, 0,
+			0, 0,
+		}
+	},
+	{ PINMUX_CFG_REG("MSEL8CR", 0xe6058034, 32, 1) {
+			0, 0,
+			0, 0,
+			0, 0,
+			0, 0,
+			0, 0,
+			0, 0,
+			0, 0,
+			0, 0,
+			0, 0,
+			0, 0,
+			0, 0,
+			0, 0,
+			0, 0,
+			0, 0,
+			0, 0,
+			MSEL8CR_16_0, MSEL8CR_16_1,
+			0, 0,
+			0, 0,
+			0, 0,
+			0, 0,
+			0, 0,
+			0, 0,
+			0, 0,
+			0, 0,
+			0, 0,
+			0, 0,
+			0, 0,
+			0, 0,
+			0, 0,
+			0, 0,
+			MSEL8CR_01_0, MSEL8CR_01_1,
+			MSEL8CR_00_0, MSEL8CR_00_1,
+		}
+	},
+	{ },
+};
+
+static const struct pinmux_data_reg pinmux_data_regs[] = {
+
+	{ PINMUX_DATA_REG("PORTL031_000DR", 0xe6054000, 32) {
+			0, PORT30_DATA, PORT29_DATA, PORT28_DATA,
+			PORT27_DATA, PORT26_DATA, PORT25_DATA, PORT24_DATA,
+			PORT23_DATA, PORT22_DATA, PORT21_DATA, PORT20_DATA,
+			PORT19_DATA, PORT18_DATA, PORT17_DATA, PORT16_DATA,
+			PORT15_DATA, PORT14_DATA, PORT13_DATA, PORT12_DATA,
+			PORT11_DATA, PORT10_DATA, PORT9_DATA, PORT8_DATA,
+			PORT7_DATA, PORT6_DATA, PORT5_DATA, PORT4_DATA,
+			PORT3_DATA, PORT2_DATA, PORT1_DATA, PORT0_DATA,
+		}
+	},
+	{ PINMUX_DATA_REG("PORTD063_032DR", 0xe6055000, 32) {
+			0, 0, 0, 0,
+			0, 0, 0, 0,
+			0, 0, 0, 0,
+			0, 0, 0, 0,
+			0, 0, 0, 0,
+			0, 0, 0, PORT40_DATA,
+			PORT39_DATA, PORT38_DATA, PORT37_DATA, PORT36_DATA,
+			PORT35_DATA, PORT34_DATA, PORT33_DATA, PORT32_DATA,
+		}
+	},
+	{ PINMUX_DATA_REG("PORTL095_064DR", 0xe6054004, 32) {
+			0, 0, 0, 0,
+			0, 0, 0, 0,
+			0, 0, PORT85_DATA, PORT84_DATA,
+			PORT83_DATA, PORT82_DATA, PORT81_DATA, PORT80_DATA,
+			PORT79_DATA, PORT78_DATA, PORT77_DATA, PORT76_DATA,
+			PORT75_DATA, PORT74_DATA, PORT73_DATA, PORT72_DATA,
+			PORT71_DATA, PORT70_DATA, PORT69_DATA, PORT68_DATA,
+			PORT67_DATA, PORT66_DATA, PORT65_DATA, PORT64_DATA,
+		}
+	},
+	{ PINMUX_DATA_REG("PORTD127_096DR", 0xe6055004, 32) {
+			0, PORT126_DATA, PORT125_DATA, PORT124_DATA,
+			PORT123_DATA, PORT122_DATA, PORT121_DATA, PORT120_DATA,
+			PORT119_DATA, PORT118_DATA, PORT117_DATA, PORT116_DATA,
+			PORT115_DATA, PORT114_DATA, PORT113_DATA, PORT112_DATA,
+			PORT111_DATA, PORT110_DATA, PORT109_DATA, PORT108_DATA,
+			PORT107_DATA, PORT106_DATA, PORT105_DATA, PORT104_DATA,
+			PORT103_DATA, PORT102_DATA, PORT101_DATA, PORT100_DATA,
+			PORT99_DATA, PORT98_DATA, PORT97_DATA, PORT96_DATA,
+		}
+	},
+	{ PINMUX_DATA_REG("PORTD159_128DR", 0xe6055008, 32) {
+			0, 0, 0, 0,
+			0, 0, 0, 0,
+			0, 0, 0, 0,
+			0, 0, 0, 0,
+			0, 0, 0, 0,
+			0, 0, 0, 0,
+			0, PORT134_DATA, PORT133_DATA, PORT132_DATA,
+			PORT131_DATA, PORT130_DATA, PORT129_DATA, PORT128_DATA,
+		}
+	},
+	{ PINMUX_DATA_REG("PORTR191_160DR", 0xe6056000, 32) {
+			0, 0, 0, 0,
+			0, 0, 0, 0,
+			0, 0, 0, 0,
+			0, PORT178_DATA, PORT177_DATA, PORT176_DATA,
+			PORT175_DATA, PORT174_DATA, PORT173_DATA, PORT172_DATA,
+			PORT171_DATA, PORT170_DATA, PORT169_DATA, PORT168_DATA,
+			PORT167_DATA, PORT166_DATA, PORT165_DATA, PORT164_DATA,
+			PORT163_DATA, PORT162_DATA, PORT161_DATA, PORT160_DATA,
+		}
+	},
+	{ PINMUX_DATA_REG("PORTR223_192DR", 0xe6056004, 32) {
+			0, PORT222_DATA, PORT221_DATA, PORT220_DATA,
+			PORT219_DATA, PORT218_DATA, PORT217_DATA, PORT216_DATA,
+			PORT215_DATA, PORT214_DATA, PORT213_DATA, PORT212_DATA,
+			PORT211_DATA, PORT210_DATA, PORT209_DATA, PORT208_DATA,
+			PORT207_DATA, PORT206_DATA, PORT205_DATA, PORT204_DATA,
+			PORT203_DATA, PORT202_DATA, PORT201_DATA, PORT200_DATA,
+			PORT199_DATA, PORT198_DATA, PORT197_DATA, PORT196_DATA,
+			PORT195_DATA, PORT194_DATA, PORT193_DATA, PORT192_DATA,
+		}
+	},
+	{ PINMUX_DATA_REG("PORTR255_224DR", 0xe6056008, 32) {
+			0, 0, 0, 0,
+			0, PORT250_DATA, PORT249_DATA, PORT248_DATA,
+			PORT247_DATA, PORT246_DATA, PORT245_DATA, PORT244_DATA,
+			PORT243_DATA, PORT242_DATA, PORT241_DATA, PORT240_DATA,
+			PORT239_DATA, PORT238_DATA, PORT237_DATA, PORT236_DATA,
+			PORT235_DATA, PORT234_DATA, PORT233_DATA, PORT232_DATA,
+			PORT231_DATA, PORT230_DATA, PORT229_DATA, PORT228_DATA,
+			PORT227_DATA, PORT226_DATA, PORT225_DATA, PORT224_DATA,
+		}
+	},
+	{ PINMUX_DATA_REG("PORTR287_256DR", 0xe605600C, 32) {
+			0, 0, 0, 0,
+			PORT283_DATA, PORT282_DATA, PORT281_DATA, PORT280_DATA,
+			PORT279_DATA, PORT278_DATA, PORT277_DATA, PORT276_DATA,
+			PORT275_DATA, PORT274_DATA, PORT273_DATA, PORT272_DATA,
+			PORT271_DATA, PORT270_DATA, PORT269_DATA, PORT268_DATA,
+			PORT267_DATA, PORT266_DATA, PORT265_DATA, PORT264_DATA,
+			PORT263_DATA, PORT262_DATA, PORT261_DATA, PORT260_DATA,
+			PORT259_DATA, PORT258_DATA, PORT257_DATA, PORT256_DATA,
+		}
+	},
+	{ PINMUX_DATA_REG("PORTU319_288DR", 0xe6057000, 32) {
+			0, 0, 0, 0,
+			0, 0, 0, 0,
+			0, 0, 0, PORT308_DATA,
+			PORT307_DATA, PORT306_DATA, PORT305_DATA, PORT304_DATA,
+			PORT303_DATA, PORT302_DATA, PORT301_DATA, PORT300_DATA,
+			PORT299_DATA, PORT298_DATA, PORT297_DATA, PORT296_DATA,
+			PORT295_DATA, PORT294_DATA, PORT293_DATA, PORT292_DATA,
+			PORT291_DATA, PORT290_DATA, PORT289_DATA, PORT288_DATA,
+		}
+	},
+	{ PINMUX_DATA_REG("PORTU351_320DR", 0xe6057004, 32) {
+			0, 0, 0, 0,
+			0, 0, 0, 0,
+			0, 0, 0, 0,
+			0, 0, 0, 0,
+			0, 0, 0, 0,
+			0, 0, PORT329_DATA, PORT328_DATA,
+			PORT327_DATA, PORT326_DATA, PORT325_DATA, PORT324_DATA,
+			PORT323_DATA, PORT322_DATA, PORT321_DATA, PORT320_DATA,
+		}
+	},
+	{ },
+};
+
+const struct sh_pfc_soc_info r8a73a4_pinmux_info = {
+	.name		= "r8a73a4_pfc",
+
+	.input = { PINMUX_INPUT_BEGIN, PINMUX_INPUT_END },
+	.input_pu = { PINMUX_INPUT_PULLUP_BEGIN, PINMUX_INPUT_PULLUP_END },
+	.input_pd = { PINMUX_INPUT_PULLDOWN_BEGIN, PINMUX_INPUT_PULLDOWN_END },
+	.output = { PINMUX_OUTPUT_BEGIN, PINMUX_OUTPUT_END },
+	.function = { PINMUX_FUNCTION_BEGIN, PINMUX_FUNCTION_END },
+
+	.pins = pinmux_pins,
+	.nr_pins = ARRAY_SIZE(pinmux_pins),
+	.func_gpios = pinmux_func_gpios,
+	.nr_func_gpios = ARRAY_SIZE(pinmux_func_gpios),
+
+	.cfg_regs	= pinmux_config_regs,
+	.data_regs	= pinmux_data_regs,
+
+	.gpio_data	= pinmux_data,
+	.gpio_data_size	= ARRAY_SIZE(pinmux_data),
+};
-- 
1.7.10.4



From sboyd at codeaurora.org  Tue Apr  2 22:06:37 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Tue, 02 Apr 2013 19:06:37 -0700
Subject: [RFC PATCH v1 0/3] clk: implement remuxing during set_rate
In-Reply-To: <1363967031-22781-1-git-send-email-james.hogan@imgtec.com>
References: <1363967031-22781-1-git-send-email-james.hogan@imgtec.com>
Message-ID: <515B8EAD.8020109@codeaurora.org>

On 03/22/13 08:43, James Hogan wrote:
> This patchset adds support for automatic selection of the best parent
> for a clock mux, i.e. the one which can provide the closest clock rate
> to that requested. It can be controlled by a new CLK_SET_RATE_REMUX flag
> so that it doesn't happen unless explicitly allowed.
>
> This works by way of adding a parameter to the round_rate clock op which
> allows the clock driver to optionally select a different parent index.
> This is used in clk_calc_new_rates to decide whether to initiate a
> set_parent operation. This would obviously require the argument to be
> added to all users of round_rate, something this patchset doesn't do as
> I'm not sure if it's really the preferred method (hence the RFC).
>
> An alternative would be to add a new callback, but that would complicate
> the code in clk.c somewhat. I suppose it would also be possible for the
> round_rate callback to call a function to set a struct clk member to
> mark that the parent should change (it's all within mutex protected
> code after all). Comments anyone?

It seems like you want to be able to call clk_set_rate() on a mux?
Usually when this comes up people say you should use clk_set_parent()
but I have a real use case (see below) and maybe you do too.

This patch set caught my eye because we need to be able to switch
parents during clk_set_rate() on MSM. We usually have two or three PLLs
feed into a mux that might feed into a divider that feeds into one or
two gates. I want clk_set_rate() on these gates to propagate up through
the divider to the mux and then have the mux switch depending on the rate.

I would like to get away without writing any new code beyond the ops
that are already there though. Well, I may have to write one new op
because I have hardware that can change the mux and divider at the same
time.

Can we push the code into the core? Perhaps by doing what you do in
clk-mux.c directly in clk_calc_new_rates()? We could store a new_parent
pointer in struct clk along with the new_rate when we find the best rate
and then when we propagate rates we can propagate the parent switch.
This part would be a little tricky if a clock has both a set_parent and
a set_rate op; what do you call first? The set_rate op? The set_parent
op? It matters for my hardware. We probably need to introduce a new
set_rate_and_parent op in case both parts of the equation change so that
the driver can do it atomically if desired (for my hardware) or in the
correct order (this part could be two generic functions like
generic_clk_rate_parent() and generic_clk_parent_rate() for the two
different orders, or two flags and the logic in the core, whatever).

I like keeping it in the core because we wouldn't need to change the
round_rate() function signature, it would be called in a loop with
different parent rates, and we wouldn't have to touch the clk-mux code
at all because it would all be done generically. Plus I get almost
everything for free for my hardware, I just need to write a new op that
does that atomic mux and rate switch. What do you think?

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation



From horms+renesas at verge.net.au  Tue Apr  2 22:08:17 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed,  3 Apr 2013 11:08:17 +0900
Subject: [PATCH 02/11] ARM: shmobile: kzm9g-reference: add ethernet support
In-Reply-To: <1364954906-16014-1-git-send-email-horms+renesas@verge.net.au>
References: <1364954906-16014-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364954906-16014-3-git-send-email-horms+renesas@verge.net.au>

From: Guennadi Liakhovetski <g.liakhovetski at gmx.de>

Add a DT node for the SMSC 9221 ethernet chip, found on kzm9g, to its
reference implementation.

Signed-off-by: Guennadi Liakhovetski <g.liakhovetski at gmx.de>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/sh73a0-kzm9g-reference.dts |   13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/arch/arm/boot/dts/sh73a0-kzm9g-reference.dts b/arch/arm/boot/dts/sh73a0-kzm9g-reference.dts
index f33b5cc..5972abb 100644
--- a/arch/arm/boot/dts/sh73a0-kzm9g-reference.dts
+++ b/arch/arm/boot/dts/sh73a0-kzm9g-reference.dts
@@ -44,6 +44,19 @@
 		regulator-always-on;
 		regulator-boot-on;
 	};
+
+	lan9220 at 10000000 {
+		compatible = "smsc,lan9220", "smsc,lan9115";
+		reg = <0x10000000 0x100>;
+		phy-mode = "mii";
+		interrupt-parent = <&irqpin0>;
+		interrupts = <3 0>;	/* active low */
+		reg-io-width = <4>;
+		smsc,irq-push-pull;
+		smsc,save-mac-address;
+		vddvario-supply = <&reg_1p8v>;
+		vdd33a-supply = <&reg_3p3v>;
+	};
 };
 
 &mmcif {
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 22:08:19 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed,  3 Apr 2013 11:08:19 +0900
Subject: [PATCH 04/11] ARM: shmobile: APE6EVM PFC support
In-Reply-To: <1364954906-16014-1-git-send-email-horms+renesas@verge.net.au>
References: <1364954906-16014-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364954906-16014-5-git-send-email-horms+renesas@verge.net.au>

From: Magnus Damm <damm at opensource.se>

Start using the r8a73a4 PFC on the APE6EVM board
and configure the SCIFA0 console signals in the
PFC via PINCTRL.

Signed-off-by: Magnus Damm <damm at opensource.se>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/board-ape6evm.c |   10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/mach-shmobile/board-ape6evm.c b/arch/arm/mach-shmobile/board-ape6evm.c
index 9234d4f..33a8a62 100644
--- a/arch/arm/mach-shmobile/board-ape6evm.c
+++ b/arch/arm/mach-shmobile/board-ape6evm.c
@@ -21,15 +21,25 @@
 #include <linux/interrupt.h>
 #include <linux/irqchip.h>
 #include <linux/kernel.h>
+#include <linux/pinctrl/machine.h>
 #include <linux/platform_device.h>
 #include <mach/common.h>
 #include <mach/r8a73a4.h>
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
 
+static const struct pinctrl_map ape6evm_pinctrl_map[] = {
+	/* SCIFA0 console */
+	PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.0", "pfc-r8a73a4",
+				  "scifa0_data", "scifa0"),
+};
+
 static void __init ape6evm_add_standard_devices(void)
 {
 	r8a73a4_clock_init();
+	pinctrl_register_mappings(ape6evm_pinctrl_map,
+				  ARRAY_SIZE(ape6evm_pinctrl_map));
+	r8a73a4_pinmux_init();
 	r8a73a4_add_standard_devices();
 }
 
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 22:08:15 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed,  3 Apr 2013 11:08:15 +0900
Subject: [GIT PULL v2] Renesas ARM SoC board updates for v3.10 #3
Message-ID: <1364954906-16014-1-git-send-email-horms+renesas@verge.net.au>

Hi Olof, Hi Arnd,

The following changes since commit eb0ae7280939fda741ad6ae9b108725517652f56:

  Merge tag 'renesas-pinmux2-for-v3.10' into boards-base (2013-04-03 10:49:18 +0900)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-boards3-for-v3.10

for you to fetch changes up to 00ae962f8051bb143fa1c43c6a9c8274c3a9c593:

  ARM: shmobile: mackerel: clean up MMCIF vs. SDHI1 selection (2013-04-03 10:50:44 +0900)

----------------------------------------------------------------
Third round of  Renesas ARM SoC board updates for v3.10

Highlights:

* Add Lager board support
* Add ape6evm board support
* Add Bock-W board support
* Mackerel MMCIF/SDHI clean ups
* Add ethernet support to kzm9g-reference

This pull request is based on a merge of:

git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas renesas-pinmux2-for-v3.10
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas renesas-boards2-for-v3.10

The merge with renesas-pinmux2-for-v3.10 was made to provide
run-time dependencies for the following changes:

ARM: shmobile: APE6EVM LAN9220 support
ARM: shmobile: APE6EVM PFC support

----------------------------------------------------------------
Guennadi Liakhovetski (6):
      ARM: shmobile: kzm9g-reference: add ethernet support
      ARM: shmobile: mackerel: SDHI resources do not have to be numbered
      ARM: shmobile: mackerel: remove OCR masks, where regulators are used
      ARM: shmobile: mackerel: switch SDHI and MMCIF interfaces to slot-gpio
      ARM: shmobile: mackerel: add interrupt names for SDHI0
      ARM: shmobile: mackerel: clean up MMCIF vs. SDHI1 selection

Kuninori Morimoto (1):
      ARM: shmobile: add R-Car M1A Bock-W platform support

Magnus Damm (4):
      ARM: shmobile: APE6EVM base support
      ARM: shmobile: APE6EVM PFC support
      ARM: shmobile: APE6EVM LAN9220 support
      ARM: shmobile: Initial r8a7790 Lager board support

 arch/arm/boot/dts/Makefile                   |    3 +
 arch/arm/boot/dts/r8a73a4-ape6evm.dts        |   52 ++++++++++++
 arch/arm/boot/dts/r8a7778-bockw.dts          |   32 ++++++++
 arch/arm/boot/dts/r8a7790-lager.dts          |   31 +++++++
 arch/arm/boot/dts/sh73a0-kzm9g-reference.dts |   13 +++
 arch/arm/configs/bockw_defconfig             |   66 +++++++++++++++
 arch/arm/mach-shmobile/Kconfig               |   21 ++++-
 arch/arm/mach-shmobile/Makefile              |    3 +
 arch/arm/mach-shmobile/board-ape6evm.c       |   94 ++++++++++++++++++++++
 arch/arm/mach-shmobile/board-bockw.c         |   43 ++++++++++
 arch/arm/mach-shmobile/board-lager.c         |   46 +++++++++++
 arch/arm/mach-shmobile/board-mackerel.c      |  111 ++++++++++----------------
 12 files changed, 443 insertions(+), 72 deletions(-)
 create mode 100644 arch/arm/boot/dts/r8a73a4-ape6evm.dts
 create mode 100644 arch/arm/boot/dts/r8a7778-bockw.dts
 create mode 100644 arch/arm/boot/dts/r8a7790-lager.dts
 create mode 100644 arch/arm/configs/bockw_defconfig
 create mode 100644 arch/arm/mach-shmobile/board-ape6evm.c
 create mode 100644 arch/arm/mach-shmobile/board-bockw.c
 create mode 100644 arch/arm/mach-shmobile/board-lager.c


From horms+renesas at verge.net.au  Tue Apr  2 22:08:18 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed,  3 Apr 2013 11:08:18 +0900
Subject: [PATCH 03/11] ARM: shmobile: APE6EVM base support
In-Reply-To: <1364954906-16014-1-git-send-email-horms+renesas@verge.net.au>
References: <1364954906-16014-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364954906-16014-4-git-send-email-horms+renesas@verge.net.au>

From: Magnus Damm <damm at opensource.se>

V3 of APE6EVM base board support making use of
1 GiB of memory, the SCIFA0 serial port and
ARM architected timer.

Signed-off-by: Magnus Damm <damm at opensource.se>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/Makefile             |    1 +
 arch/arm/boot/dts/r8a73a4-ape6evm.dts  |   31 +++++++++++++++++++++
 arch/arm/mach-shmobile/Kconfig         |    8 +++++-
 arch/arm/mach-shmobile/Makefile        |    1 +
 arch/arm/mach-shmobile/board-ape6evm.c |   46 ++++++++++++++++++++++++++++++++
 5 files changed, 86 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/r8a73a4-ape6evm.dts
 create mode 100644 arch/arm/mach-shmobile/board-ape6evm.c

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 363fa507..a99b0f7 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -140,6 +140,7 @@ dtb-$(CONFIG_ARCH_SHMOBILE) += emev2-kzm9d.dtb \
 	r8a7779-marzen-reference.dtb \
 	sh73a0-kzm9g.dtb \
 	sh73a0-kzm9g-reference.dtb \
+	r8a73a4-ape6evm.dtb \
 	sh7372-mackerel.dtb
 dtb-$(CONFIG_ARCH_SOCFPGA) += socfpga_cyclone5.dtb \
 	socfpga_vt.dtb
diff --git a/arch/arm/boot/dts/r8a73a4-ape6evm.dts b/arch/arm/boot/dts/r8a73a4-ape6evm.dts
new file mode 100644
index 0000000..833f703
--- /dev/null
+++ b/arch/arm/boot/dts/r8a73a4-ape6evm.dts
@@ -0,0 +1,31 @@
+/*
+ * Device Tree Source for the APE6EVM board
+ *
+ * Copyright (C) 2013 Renesas Solutions Corp.
+ *
+ * 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.
+ */
+
+/dts-v1/;
+/include/ "r8a73a4.dtsi"
+
+/ {
+	model = "APE6EVM";
+	compatible = "renesas,ape6evm", "renesas,r8a73a4";
+
+	chosen {
+		bootargs = "console=ttySC0,115200 ignore_loglevel";
+	};
+
+	memory at 40000000 {
+		device_type = "memory";
+		reg = <0 0x40000000 0 0x40000000>;
+	};
+
+	lbsc {
+		#address-cells = <1>;
+		#size-cells = <1>;
+	};
+};
diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index 18712ad..c0da6af 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -96,6 +96,11 @@ config MACH_AG5EVM
 	select REGULATOR_FIXED_VOLTAGE if REGULATOR
 	select SH_LCD_MIPI_DSI
 
+config MACH_APE6EVM
+	bool "APE6EVM board"
+	depends on ARCH_R8A73A4
+	select USE_OF
+
 config MACH_MACKEREL
 	bool "mackerel board"
 	depends on ARCH_SH7372
@@ -189,7 +194,7 @@ config MEMORY_START
 	hex "Physical memory start address"
 	default "0x40000000" if MACH_AP4EVB || MACH_AG5EVM || \
 				MACH_MACKEREL || MACH_BONITO || \
-				MACH_ARMADILLO800EVA
+				MACH_ARMADILLO800EVA || MACH_APE6EVM
 	default "0x41000000" if MACH_KOTA2
 	default "0x00000000"
 	---help---
@@ -199,6 +204,7 @@ config MEMORY_START
 
 config MEMORY_SIZE
 	hex "Physical memory size"
+	default "0x40000000" if MACH_APE6EVM
 	default "0x20000000" if MACH_AG5EVM || MACH_BONITO || \
 				MACH_ARMADILLO800EVA
 	default "0x1e000000" if MACH_KOTA2
diff --git a/arch/arm/mach-shmobile/Makefile b/arch/arm/mach-shmobile/Makefile
index 5eada96..ec2524e 100644
--- a/arch/arm/mach-shmobile/Makefile
+++ b/arch/arm/mach-shmobile/Makefile
@@ -37,6 +37,7 @@ obj-$(CONFIG_ARCH_SH73A0)	+= pm-sh73a0.o
 # Board objects
 obj-$(CONFIG_MACH_AP4EVB)	+= board-ap4evb.o
 obj-$(CONFIG_MACH_AG5EVM)	+= board-ag5evm.o
+obj-$(CONFIG_MACH_APE6EVM)	+= board-ape6evm.o
 obj-$(CONFIG_MACH_MACKEREL)	+= board-mackerel.o
 obj-$(CONFIG_MACH_KOTA2)	+= board-kota2.o
 obj-$(CONFIG_MACH_BONITO)	+= board-bonito.o
diff --git a/arch/arm/mach-shmobile/board-ape6evm.c b/arch/arm/mach-shmobile/board-ape6evm.c
new file mode 100644
index 0000000..9234d4f
--- /dev/null
+++ b/arch/arm/mach-shmobile/board-ape6evm.c
@@ -0,0 +1,46 @@
+/*
+ * APE6EVM board support
+ *
+ * Copyright (C) 2013  Renesas Solutions Corp.
+ * Copyright (C) 2013  Magnus Damm
+ *
+ * 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; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
+ */
+
+#include <linux/interrupt.h>
+#include <linux/irqchip.h>
+#include <linux/kernel.h>
+#include <linux/platform_device.h>
+#include <mach/common.h>
+#include <mach/r8a73a4.h>
+#include <asm/mach-types.h>
+#include <asm/mach/arch.h>
+
+static void __init ape6evm_add_standard_devices(void)
+{
+	r8a73a4_clock_init();
+	r8a73a4_add_standard_devices();
+}
+
+static const char *ape6evm_boards_compat_dt[] __initdata = {
+	"renesas,ape6evm",
+	NULL,
+};
+
+DT_MACHINE_START(APE6EVM_DT, "ape6evm")
+	.init_irq	= irqchip_init,
+	.init_time	= shmobile_timer_init,
+	.init_machine	= ape6evm_add_standard_devices,
+	.dt_compat	= ape6evm_boards_compat_dt,
+MACHINE_END
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 22:08:22 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed,  3 Apr 2013 11:08:22 +0900
Subject: [PATCH 07/11] ARM: shmobile: mackerel: SDHI resources do not have to
 be numbered
In-Reply-To: <1364954906-16014-1-git-send-email-horms+renesas@verge.net.au>
References: <1364954906-16014-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364954906-16014-8-git-send-email-horms+renesas@verge.net.au>

From: Guennadi Liakhovetski <g.liakhovetski at gmx.de>

The SDHI driver doesn't care about platform resource order, explicit
resource numbering is redundant.

Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas at gmail.com>
Acked-by: Magnus Damm <damm at opensource.se>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/board-mackerel.c |   33 +++++++++++--------------------
 1 file changed, 12 insertions(+), 21 deletions(-)

diff --git a/arch/arm/mach-shmobile/board-mackerel.c b/arch/arm/mach-shmobile/board-mackerel.c
index 1a9c753..c4f80d4 100644
--- a/arch/arm/mach-shmobile/board-mackerel.c
+++ b/arch/arm/mach-shmobile/board-mackerel.c
@@ -982,21 +982,18 @@ static struct sh_mobile_sdhi_info sdhi0_info = {
 };
 
 static struct resource sdhi0_resources[] = {
-	[0] = {
+	{
 		.name	= "SDHI0",
 		.start	= 0xe6850000,
 		.end	= 0xe68500ff,
 		.flags	= IORESOURCE_MEM,
-	},
-	[1] = {
+	}, {
 		.start	= evt2irq(0x0e00) /* SDHI0_SDHI0I0 */,
 		.flags	= IORESOURCE_IRQ,
-	},
-	[2] = {
+	}, {
 		.start	= evt2irq(0x0e20) /* SDHI0_SDHI0I1 */,
 		.flags	= IORESOURCE_IRQ,
-	},
-	[3] = {
+	}, {
 		.start	= evt2irq(0x0e40) /* SDHI0_SDHI0I2 */,
 		.flags	= IORESOURCE_IRQ,
 	},
@@ -1025,23 +1022,20 @@ static struct sh_mobile_sdhi_info sdhi1_info = {
 };
 
 static struct resource sdhi1_resources[] = {
-	[0] = {
+	{
 		.name	= "SDHI1",
 		.start	= 0xe6860000,
 		.end	= 0xe68600ff,
 		.flags	= IORESOURCE_MEM,
-	},
-	[1] = {
+	}, {
 		.name	= SH_MOBILE_SDHI_IRQ_CARD_DETECT,
 		.start	= evt2irq(0x0e80), /* SDHI1_SDHI1I0 */
 		.flags	= IORESOURCE_IRQ,
-	},
-	[2] = {
+	}, {
 		.name	= SH_MOBILE_SDHI_IRQ_SDCARD,
 		.start	= evt2irq(0x0ea0), /* SDHI1_SDHI1I1 */
 		.flags	= IORESOURCE_IRQ,
-	},
-	[3] = {
+	}, {
 		.name	= SH_MOBILE_SDHI_IRQ_SDIO,
 		.start	= evt2irq(0x0ec0), /* SDHI1_SDHI1I2 */
 		.flags	= IORESOURCE_IRQ,
@@ -1079,23 +1073,20 @@ static struct sh_mobile_sdhi_info sdhi2_info = {
 };
 
 static struct resource sdhi2_resources[] = {
-	[0] = {
+	{
 		.name	= "SDHI2",
 		.start	= 0xe6870000,
 		.end	= 0xe68700ff,
 		.flags	= IORESOURCE_MEM,
-	},
-	[1] = {
+	}, {
 		.name	= SH_MOBILE_SDHI_IRQ_CARD_DETECT,
 		.start	= evt2irq(0x1200), /* SDHI2_SDHI2I0 */
 		.flags	= IORESOURCE_IRQ,
-	},
-	[2] = {
+	}, {
 		.name	= SH_MOBILE_SDHI_IRQ_SDCARD,
 		.start	= evt2irq(0x1220), /* SDHI2_SDHI2I1 */
 		.flags	= IORESOURCE_IRQ,
-	},
-	[3] = {
+	}, {
 		.name	= SH_MOBILE_SDHI_IRQ_SDIO,
 		.start	= evt2irq(0x1240), /* SDHI2_SDHI2I2 */
 		.flags	= IORESOURCE_IRQ,
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 22:08:16 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed,  3 Apr 2013 11:08:16 +0900
Subject: [PATCH 01/11] ARM: shmobile: add R-Car M1A Bock-W platform support
In-Reply-To: <1364954906-16014-1-git-send-email-horms+renesas@verge.net.au>
References: <1364954906-16014-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364954906-16014-2-git-send-email-horms+renesas@verge.net.au>

From: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>

Add basic Bock-W board support

More devices will be added on top of this patch after
PICNTRL and clock framework are in better shape.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Acked-by: Magnus Damm <damm at opensource.se>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/Makefile           |    1 +
 arch/arm/boot/dts/r8a7778-bockw.dts  |   32 +++++++++++++++++
 arch/arm/configs/bockw_defconfig     |   66 ++++++++++++++++++++++++++++++++++
 arch/arm/mach-shmobile/Kconfig       |    6 ++++
 arch/arm/mach-shmobile/Makefile      |    1 +
 arch/arm/mach-shmobile/board-bockw.c |   43 ++++++++++++++++++++++
 6 files changed, 149 insertions(+)
 create mode 100644 arch/arm/boot/dts/r8a7778-bockw.dts
 create mode 100644 arch/arm/configs/bockw_defconfig
 create mode 100644 arch/arm/mach-shmobile/board-bockw.c

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index ee9fbe4..363fa507 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -136,6 +136,7 @@ dtb-$(CONFIG_ARCH_U8500) += snowball.dtb \
 	ccu9540.dtb
 dtb-$(CONFIG_ARCH_SHMOBILE) += emev2-kzm9d.dtb \
 	r8a7740-armadillo800eva.dtb \
+	r8a7778-bockw.dtb \
 	r8a7779-marzen-reference.dtb \
 	sh73a0-kzm9g.dtb \
 	sh73a0-kzm9g-reference.dtb \
diff --git a/arch/arm/boot/dts/r8a7778-bockw.dts b/arch/arm/boot/dts/r8a7778-bockw.dts
new file mode 100644
index 0000000..735c964
--- /dev/null
+++ b/arch/arm/boot/dts/r8a7778-bockw.dts
@@ -0,0 +1,32 @@
+/*
+ * Reference Device Tree Source for the Bock-W board
+ *
+ * Copyright (C) 2013  Renesas Solutions Corp.
+ * Copyright (C) 2013  Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
+ *
+ * based on r8a7779
+ *
+ * Copyright (C) 2013 Renesas Solutions Corp.
+ * Copyright (C) 2013 Simon Horman
+ *
+ * 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.
+ */
+
+/dts-v1/;
+/include/ "r8a7778.dtsi"
+
+/ {
+	model = "bockw";
+	compatible = "renesas,bockw", "renesas,r8a7778";
+
+	chosen {
+		bootargs = "console=ttySC0,115200 ignore_loglevel";
+	};
+
+	memory {
+		device_type = "memory";
+		reg = <0x60000000 0x10000000>;
+	};
+};
diff --git a/arch/arm/configs/bockw_defconfig b/arch/arm/configs/bockw_defconfig
new file mode 100644
index 0000000..6037705
--- /dev/null
+++ b/arch/arm/configs/bockw_defconfig
@@ -0,0 +1,66 @@
+# CONFIG_ARM_PATCH_PHYS_VIRT is not set
+CONFIG_KERNEL_LZMA=y
+CONFIG_NO_HZ=y
+CONFIG_IKCONFIG=y
+CONFIG_IKCONFIG_PROC=y
+CONFIG_LOG_BUF_SHIFT=16
+CONFIG_SYSCTL_SYSCALL=y
+CONFIG_EMBEDDED=y
+CONFIG_SLAB=y
+# CONFIG_IOSCHED_CFQ is not set
+CONFIG_ARCH_SHMOBILE=y
+CONFIG_ARCH_R8A7778=y
+CONFIG_MACH_BOCKW=y
+CONFIG_MEMORY_START=0x60000000
+CONFIG_MEMORY_SIZE=0x10000000
+CONFIG_SHMOBILE_TIMER_HZ=1024
+# CONFIG_SH_TIMER_CMT is not set
+# CONFIG_EM_TIMER_STI is not set
+CONFIG_ARM_ERRATA_430973=y
+CONFIG_ARM_ERRATA_458693=y
+CONFIG_ARM_ERRATA_460075=y
+CONFIG_ARM_ERRATA_743622=y
+CONFIG_ARM_ERRATA_754322=y
+CONFIG_AEABI=y
+# CONFIG_OABI_COMPAT is not set
+CONFIG_HIGHMEM=y
+CONFIG_ZBOOT_ROM_TEXT=0x0
+CONFIG_ZBOOT_ROM_BSS=0x0
+CONFIG_ARM_APPENDED_DTB=y
+CONFIG_CMDLINE="console=ttySC0,115200 ignore_loglevel"
+CONFIG_CMDLINE_FORCE=y
+# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
+# CONFIG_SUSPEND is not set
+CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
+CONFIG_DEVTMPFS=y
+CONFIG_DEVTMPFS_MOUNT=y
+# CONFIG_STANDALONE is not set
+# CONFIG_PREVENT_FIRMWARE_BUILD is not set
+# CONFIG_FW_LOADER is not set
+# CONFIG_INPUT is not set
+# CONFIG_SERIO is not set
+# CONFIG_VT is not set
+# CONFIG_LEGACY_PTYS is not set
+# CONFIG_DEVKMEM is not set
+CONFIG_SERIAL_SH_SCI=y
+CONFIG_SERIAL_SH_SCI_NR_UARTS=6
+CONFIG_SERIAL_SH_SCI_CONSOLE=y
+# CONFIG_HW_RANDOM is not set
+# CONFIG_HWMON is not set
+# CONFIG_USB_SUPPORT is not set
+CONFIG_UIO=y
+CONFIG_UIO_PDRV_GENIRQ=y
+# CONFIG_IOMMU_SUPPORT is not set
+# CONFIG_DNOTIFY is not set
+# CONFIG_INOTIFY_USER is not set
+CONFIG_TMPFS=y
+# CONFIG_MISC_FILESYSTEMS is not set
+# CONFIG_ENABLE_WARN_DEPRECATED is not set
+# CONFIG_ENABLE_MUST_CHECK is not set
+# CONFIG_SCHED_DEBUG is not set
+# CONFIG_DEBUG_BUGVERBOSE is not set
+# CONFIG_FTRACE is not set
+# CONFIG_ARM_UNWIND is not set
+CONFIG_KEYS=y
+CONFIG_CRYPTO=y
+CONFIG_AVERAGE=y
diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index 3933a31..18712ad 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -124,6 +124,12 @@ config MACH_ARMADILLO800EVA
 	select SND_SOC_WM8978 if SND_SIMPLE_CARD
 	select USE_OF
 
+config MACH_BOCKW
+	bool "BOCK-W platform"
+	depends on ARCH_R8A7778
+	select ARCH_REQUIRE_GPIOLIB
+	select USE_OF
+
 config MACH_MARZEN
 	bool "MARZEN board"
 	depends on ARCH_R8A7779
diff --git a/arch/arm/mach-shmobile/Makefile b/arch/arm/mach-shmobile/Makefile
index 0c9a290..5eada96 100644
--- a/arch/arm/mach-shmobile/Makefile
+++ b/arch/arm/mach-shmobile/Makefile
@@ -40,6 +40,7 @@ obj-$(CONFIG_MACH_AG5EVM)	+= board-ag5evm.o
 obj-$(CONFIG_MACH_MACKEREL)	+= board-mackerel.o
 obj-$(CONFIG_MACH_KOTA2)	+= board-kota2.o
 obj-$(CONFIG_MACH_BONITO)	+= board-bonito.o
+obj-$(CONFIG_MACH_BOCKW)	+= board-bockw.o
 obj-$(CONFIG_MACH_MARZEN)	+= board-marzen.o
 obj-$(CONFIG_MACH_MARZEN_REFERENCE)	+= board-marzen-reference.o
 obj-$(CONFIG_MACH_ARMADILLO800EVA)	+= board-armadillo800eva.o
diff --git a/arch/arm/mach-shmobile/board-bockw.c b/arch/arm/mach-shmobile/board-bockw.c
new file mode 100644
index 0000000..56ab56e
--- /dev/null
+++ b/arch/arm/mach-shmobile/board-bockw.c
@@ -0,0 +1,43 @@
+/*
+ * Bock-W board support
+ *
+ * Copyright (C) 2013  Renesas Solutions Corp.
+ * Copyright (C) 2013  Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
+ *
+ * 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; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
+ */
+
+#include <linux/platform_device.h>
+#include <mach/common.h>
+#include <mach/r8a7778.h>
+#include <asm/mach/arch.h>
+
+static void __init bockw_init(void)
+{
+	r8a7778_clock_init();
+	r8a7778_add_standard_devices();
+}
+
+static const char *bockw_boards_compat_dt[] __initdata = {
+	"renesas,bockw",
+	NULL,
+};
+
+DT_MACHINE_START(BOCKW_DT, "bockw")
+	.init_early	= r8a7778_init_delay,
+	.init_irq	= r8a7778_init_irq_dt,
+	.init_machine	= bockw_init,
+	.init_time	= shmobile_timer_init,
+	.dt_compat	= bockw_boards_compat_dt,
+MACHINE_END
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 22:08:20 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed,  3 Apr 2013 11:08:20 +0900
Subject: [PATCH 05/11] ARM: shmobile: APE6EVM LAN9220 support
In-Reply-To: <1364954906-16014-1-git-send-email-horms+renesas@verge.net.au>
References: <1364954906-16014-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364954906-16014-6-git-send-email-horms+renesas@verge.net.au>

From: Magnus Damm <damm at opensource.se>

Add LAN9220 support to the APE6EVM board using C and DT.
At this point the PFC driver lacks DT bindings so to
configure the PFC we use PINCTRL in C board code.

Signed-off-by: Magnus Damm <damm at opensource.se>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a73a4-ape6evm.dts  |   23 ++++++++++++++++++-
 arch/arm/mach-shmobile/board-ape6evm.c |   38 ++++++++++++++++++++++++++++++++
 2 files changed, 60 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/r8a73a4-ape6evm.dts b/arch/arm/boot/dts/r8a73a4-ape6evm.dts
index 833f703..f603c69 100644
--- a/arch/arm/boot/dts/r8a73a4-ape6evm.dts
+++ b/arch/arm/boot/dts/r8a73a4-ape6evm.dts
@@ -16,7 +16,7 @@
 	compatible = "renesas,ape6evm", "renesas,r8a73a4";
 
 	chosen {
-		bootargs = "console=ttySC0,115200 ignore_loglevel";
+		bootargs = "console=ttySC0,115200 ignore_loglevel root=/dev/nfs ip=dhcp";
 	};
 
 	memory at 40000000 {
@@ -24,8 +24,29 @@
 		reg = <0 0x40000000 0 0x40000000>;
 	};
 
+	ape6evm_fixed_3v3: fixedregulator at 0 {
+		compatible = "regulator-fixed";
+		regulator-name = "3V3";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		regulator-always-on;
+	};
+
 	lbsc {
 		#address-cells = <1>;
 		#size-cells = <1>;
+
+		ethernet at 8000000 {
+			compatible = "smsc,lan9118", "smsc,lan9115";
+			reg = <0x08000000 0x1000>;
+			interrupt-parent = <&irqc1>;
+			interrupts = <8 0x4>;
+			phy-mode = "mii";
+			reg-io-width = <4>;
+			smsc,irq-active-high;
+			smsc,irq-push-pull;
+			vdd33a-supply = <&ape6evm_fixed_3v3>;
+			vddvario-supply = <&ape6evm_fixed_3v3>;
+		};
 	};
 };
diff --git a/arch/arm/mach-shmobile/board-ape6evm.c b/arch/arm/mach-shmobile/board-ape6evm.c
index 33a8a62..55b8c9f 100644
--- a/arch/arm/mach-shmobile/board-ape6evm.c
+++ b/arch/arm/mach-shmobile/board-ape6evm.c
@@ -18,20 +18,49 @@
  * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
  */
 
+#include <linux/gpio.h>
 #include <linux/interrupt.h>
 #include <linux/irqchip.h>
 #include <linux/kernel.h>
 #include <linux/pinctrl/machine.h>
 #include <linux/platform_device.h>
+#include <linux/regulator/fixed.h>
+#include <linux/regulator/machine.h>
+#include <linux/smsc911x.h>
 #include <mach/common.h>
+#include <mach/irqs.h>
 #include <mach/r8a73a4.h>
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
 
+/* Dummy supplies, where voltage doesn't matter */
+static struct regulator_consumer_supply dummy_supplies[] = {
+	REGULATOR_SUPPLY("vddvario", "smsc911x"),
+	REGULATOR_SUPPLY("vdd33a", "smsc911x"),
+};
+
+/* SMSC LAN9220 */
+static const struct resource lan9220_res[] = {
+	DEFINE_RES_MEM(0x08000000, 0x1000),
+	{
+		.start	= irq_pin(40), /* IRQ40 */
+		.flags	= IORESOURCE_IRQ | IRQF_TRIGGER_HIGH,
+	},
+};
+
+static const struct smsc911x_platform_config lan9220_data = {
+	.flags		= SMSC911X_USE_32BIT,
+	.irq_type	= SMSC911X_IRQ_TYPE_PUSH_PULL,
+	.irq_polarity	= SMSC911X_IRQ_POLARITY_ACTIVE_HIGH,
+};
+
 static const struct pinctrl_map ape6evm_pinctrl_map[] = {
 	/* SCIFA0 console */
 	PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.0", "pfc-r8a73a4",
 				  "scifa0_data", "scifa0"),
+	/* SMSC */
+	PIN_MAP_MUX_GROUP_DEFAULT("smsc911x", "pfc-r8a73a4",
+				  "irqc_irq40", "irqc"),
 };
 
 static void __init ape6evm_add_standard_devices(void)
@@ -41,6 +70,15 @@ static void __init ape6evm_add_standard_devices(void)
 				  ARRAY_SIZE(ape6evm_pinctrl_map));
 	r8a73a4_pinmux_init();
 	r8a73a4_add_standard_devices();
+
+	/* LAN9220 ethernet */
+	gpio_request_one(270, GPIOF_OUT_INIT_HIGH, NULL); /* smsc9220 RESET */
+
+	regulator_register_fixed(0, dummy_supplies, ARRAY_SIZE(dummy_supplies));
+
+	platform_device_register_resndata(&platform_bus, "smsc911x", -1,
+					  lan9220_res, ARRAY_SIZE(lan9220_res),
+					  &lan9220_data, sizeof(lan9220_data));
 }
 
 static const char *ape6evm_boards_compat_dt[] __initdata = {
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 22:08:23 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed,  3 Apr 2013 11:08:23 +0900
Subject: [PATCH 08/11] ARM: shmobile: mackerel: remove OCR masks,
 where regulators are used
In-Reply-To: <1364954906-16014-1-git-send-email-horms+renesas@verge.net.au>
References: <1364954906-16014-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364954906-16014-9-git-send-email-horms+renesas@verge.net.au>

From: Guennadi Liakhovetski <g.liakhovetski at gmx.de>

Both SDHI and MMCIF drivers ignore their OCR platform values, when
available voltages can be retrieved from regulators.

Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas at gmail.com>
Acked-by: Magnus Damm <damm at opensource.se>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/board-mackerel.c |    2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/arm/mach-shmobile/board-mackerel.c b/arch/arm/mach-shmobile/board-mackerel.c
index c4f80d4..734565d 100644
--- a/arch/arm/mach-shmobile/board-mackerel.c
+++ b/arch/arm/mach-shmobile/board-mackerel.c
@@ -1014,7 +1014,6 @@ static struct platform_device sdhi0_device = {
 static struct sh_mobile_sdhi_info sdhi1_info = {
 	.dma_slave_tx	= SHDMA_SLAVE_SDHI1_TX,
 	.dma_slave_rx	= SHDMA_SLAVE_SDHI1_RX,
-	.tmio_ocr_mask	= MMC_VDD_165_195,
 	.tmio_flags	= TMIO_MMC_WRPROTECT_DISABLE,
 	.tmio_caps	= MMC_CAP_SD_HIGHSPEED | MMC_CAP_SDIO_IRQ |
 			  MMC_CAP_NEEDS_POLL,
@@ -1125,7 +1124,6 @@ static struct resource sh_mmcif_resources[] = {
 
 static struct sh_mmcif_plat_data sh_mmcif_plat = {
 	.sup_pclk	= 0,
-	.ocr		= MMC_VDD_165_195 | MMC_VDD_32_33 | MMC_VDD_33_34,
 	.caps		= MMC_CAP_4_BIT_DATA |
 			  MMC_CAP_8_BIT_DATA |
 			  MMC_CAP_NEEDS_POLL,
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 22:08:25 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed,  3 Apr 2013 11:08:25 +0900
Subject: [PATCH 10/11] ARM: shmobile: mackerel: add interrupt names for SDHI0
In-Reply-To: <1364954906-16014-1-git-send-email-horms+renesas@verge.net.au>
References: <1364954906-16014-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364954906-16014-11-git-send-email-horms+renesas@verge.net.au>

From: Guennadi Liakhovetski <g.liakhovetski at gmx.de>

To unify with SDHI1 also use named IRQs for SDHI0. This also clarifies
which specific IRQs are used.

Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas at gmail.com>
Acked-by: Magnus Damm <damm at opensource.se>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/board-mackerel.c |    9 ++-------
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/arch/arm/mach-shmobile/board-mackerel.c b/arch/arm/mach-shmobile/board-mackerel.c
index a47a1116..b976ad6 100644
--- a/arch/arm/mach-shmobile/board-mackerel.c
+++ b/arch/arm/mach-shmobile/board-mackerel.c
@@ -979,12 +979,11 @@ static struct resource sdhi0_resources[] = {
 		.end	= 0xe68500ff,
 		.flags	= IORESOURCE_MEM,
 	}, {
-		.start	= evt2irq(0x0e00) /* SDHI0_SDHI0I0 */,
-		.flags	= IORESOURCE_IRQ,
-	}, {
+		.name	= SH_MOBILE_SDHI_IRQ_SDCARD,
 		.start	= evt2irq(0x0e20) /* SDHI0_SDHI0I1 */,
 		.flags	= IORESOURCE_IRQ,
 	}, {
+		.name	= SH_MOBILE_SDHI_IRQ_SDIO,
 		.start	= evt2irq(0x0e40) /* SDHI0_SDHI0I2 */,
 		.flags	= IORESOURCE_IRQ,
 	},
@@ -1020,10 +1019,6 @@ static struct resource sdhi1_resources[] = {
 		.end	= 0xe68600ff,
 		.flags	= IORESOURCE_MEM,
 	}, {
-		.name	= SH_MOBILE_SDHI_IRQ_CARD_DETECT,
-		.start	= evt2irq(0x0e80), /* SDHI1_SDHI1I0 */
-		.flags	= IORESOURCE_IRQ,
-	}, {
 		.name	= SH_MOBILE_SDHI_IRQ_SDCARD,
 		.start	= evt2irq(0x0ea0), /* SDHI1_SDHI1I1 */
 		.flags	= IORESOURCE_IRQ,
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 22:08:21 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed,  3 Apr 2013 11:08:21 +0900
Subject: [PATCH 06/11] ARM: shmobile: Initial r8a7790 Lager board support
In-Reply-To: <1364954906-16014-1-git-send-email-horms+renesas@verge.net.au>
References: <1364954906-16014-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364954906-16014-7-git-send-email-horms+renesas@verge.net.au>

From: Magnus Damm <damm at opensource.se>

Lager base board support making use of 2 GiB of memory,
the r8a7790 SoC with the SCIF0 serial port and CA15 with
ARM architected timer.

Signed-off-by: Magnus Damm <damm at opensource.se>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/Makefile           |    1 +
 arch/arm/boot/dts/r8a7790-lager.dts  |   31 +++++++++++++++++++++++
 arch/arm/mach-shmobile/Kconfig       |    9 ++++++-
 arch/arm/mach-shmobile/Makefile      |    1 +
 arch/arm/mach-shmobile/board-lager.c |   46 ++++++++++++++++++++++++++++++++++
 5 files changed, 87 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/r8a7790-lager.dts
 create mode 100644 arch/arm/mach-shmobile/board-lager.c

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index a99b0f7..47b6be7 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -138,6 +138,7 @@ dtb-$(CONFIG_ARCH_SHMOBILE) += emev2-kzm9d.dtb \
 	r8a7740-armadillo800eva.dtb \
 	r8a7778-bockw.dtb \
 	r8a7779-marzen-reference.dtb \
+	r8a7790-lager.dtb \
 	sh73a0-kzm9g.dtb \
 	sh73a0-kzm9g-reference.dtb \
 	r8a73a4-ape6evm.dtb \
diff --git a/arch/arm/boot/dts/r8a7790-lager.dts b/arch/arm/boot/dts/r8a7790-lager.dts
new file mode 100644
index 0000000..09a84fc
--- /dev/null
+++ b/arch/arm/boot/dts/r8a7790-lager.dts
@@ -0,0 +1,31 @@
+/*
+ * Device Tree Source for the Lager board
+ *
+ * Copyright (C) 2013 Renesas Solutions Corp.
+ *
+ * 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.
+ */
+
+/dts-v1/;
+/include/ "r8a7790.dtsi"
+
+/ {
+	model = "Lager";
+	compatible = "renesas,lager", "renesas,r8a7790";
+
+	chosen {
+		bootargs = "console=ttySC6,115200 ignore_loglevel";
+	};
+
+	memory at 40000000 {
+		device_type = "memory";
+		reg = <0 0x40000000 0 0x80000000>;
+	};
+
+	lbsc {
+		#address-cells = <1>;
+		#size-cells = <1>;
+	};
+};
diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index c0da6af..549e059 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -154,6 +154,11 @@ config MACH_MARZEN_REFERENCE
 
 	   This is intended to aid developers
 
+config MACH_LAGER
+	bool "Lager board"
+	depends on ARCH_R8A7790
+	select USE_OF
+
 config MACH_KZM9D
 	bool "KZM9D board"
 	depends on ARCH_EMEV2
@@ -194,7 +199,8 @@ config MEMORY_START
 	hex "Physical memory start address"
 	default "0x40000000" if MACH_AP4EVB || MACH_AG5EVM || \
 				MACH_MACKEREL || MACH_BONITO || \
-				MACH_ARMADILLO800EVA || MACH_APE6EVM
+				MACH_ARMADILLO800EVA || MACH_APE6EVM || \
+				MACH_LAGER
 	default "0x41000000" if MACH_KOTA2
 	default "0x00000000"
 	---help---
@@ -204,6 +210,7 @@ config MEMORY_START
 
 config MEMORY_SIZE
 	hex "Physical memory size"
+	default "0x80000000" if MACH_LAGER
 	default "0x40000000" if MACH_APE6EVM
 	default "0x20000000" if MACH_AG5EVM || MACH_BONITO || \
 				MACH_ARMADILLO800EVA
diff --git a/arch/arm/mach-shmobile/Makefile b/arch/arm/mach-shmobile/Makefile
index ec2524e..068f1da 100644
--- a/arch/arm/mach-shmobile/Makefile
+++ b/arch/arm/mach-shmobile/Makefile
@@ -44,6 +44,7 @@ obj-$(CONFIG_MACH_BONITO)	+= board-bonito.o
 obj-$(CONFIG_MACH_BOCKW)	+= board-bockw.o
 obj-$(CONFIG_MACH_MARZEN)	+= board-marzen.o
 obj-$(CONFIG_MACH_MARZEN_REFERENCE)	+= board-marzen-reference.o
+obj-$(CONFIG_MACH_LAGER)	+= board-lager.o
 obj-$(CONFIG_MACH_ARMADILLO800EVA)	+= board-armadillo800eva.o
 obj-$(CONFIG_MACH_KZM9D)	+= board-kzm9d.o
 obj-$(CONFIG_MACH_KZM9G)	+= board-kzm9g.o
diff --git a/arch/arm/mach-shmobile/board-lager.c b/arch/arm/mach-shmobile/board-lager.c
new file mode 100644
index 0000000..ea6f9e5
--- /dev/null
+++ b/arch/arm/mach-shmobile/board-lager.c
@@ -0,0 +1,46 @@
+/*
+ * Lager board support
+ *
+ * Copyright (C) 2013  Renesas Solutions Corp.
+ * Copyright (C) 2013  Magnus Damm
+ *
+ * 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; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
+ */
+
+#include <linux/interrupt.h>
+#include <linux/irqchip.h>
+#include <linux/kernel.h>
+#include <linux/platform_device.h>
+#include <mach/common.h>
+#include <mach/r8a7790.h>
+#include <asm/mach-types.h>
+#include <asm/mach/arch.h>
+
+static void __init lager_add_standard_devices(void)
+{
+	r8a7790_clock_init();
+	r8a7790_add_standard_devices();
+}
+
+static const char *lager_boards_compat_dt[] __initdata = {
+	"renesas,lager",
+	NULL,
+};
+
+DT_MACHINE_START(LAGER_DT, "lager")
+	.init_irq	= irqchip_init,
+	.init_time	= shmobile_timer_init,
+	.init_machine	= lager_add_standard_devices,
+	.dt_compat	= lager_boards_compat_dt,
+MACHINE_END
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 22:08:26 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed,  3 Apr 2013 11:08:26 +0900
Subject: [PATCH 11/11] ARM: shmobile: mackerel: clean up MMCIF vs. SDHI1
 selection
In-Reply-To: <1364954906-16014-1-git-send-email-horms+renesas@verge.net.au>
References: <1364954906-16014-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364954906-16014-12-git-send-email-horms+renesas@verge.net.au>

From: Guennadi Liakhovetski <g.liakhovetski at gmx.de>

MMCIF and SDHI1 share the same slot on mackerel. One of them is selected
by a jumper, which cannot be queried from software. Currently in software
one of the two interfaces is selected, depending whether or not the MMCIF
driver is enabled. This is not optimal, since the kernel has to be rebuilt
to switch from one interface to another. Still, so far there isn't a
better option. At least make this selection consistent.

Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas at gmail.com>
Acked-by: Magnus Damm <damm at opensource.se>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/board-mackerel.c |   34 +++++++++++++++----------------
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/arch/arm/mach-shmobile/board-mackerel.c b/arch/arm/mach-shmobile/board-mackerel.c
index b976ad6..5b452e1 100644
--- a/arch/arm/mach-shmobile/board-mackerel.c
+++ b/arch/arm/mach-shmobile/board-mackerel.c
@@ -999,7 +999,7 @@ static struct platform_device sdhi0_device = {
 	},
 };
 
-#if !defined(CONFIG_MMC_SH_MMCIF) && !defined(CONFIG_MMC_SH_MMCIF_MODULE)
+#if !IS_ENABLED(CONFIG_MMC_SH_MMCIF)
 /* SDHI1 */
 
 /* GPIO 41 can trigger IRQ8, but it is used by USBHS1, we have to poll */
@@ -1062,10 +1062,6 @@ static struct resource sdhi2_resources[] = {
 		.end	= 0xe68700ff,
 		.flags	= IORESOURCE_MEM,
 	}, {
-		.name	= SH_MOBILE_SDHI_IRQ_CARD_DETECT,
-		.start	= evt2irq(0x1200), /* SDHI2_SDHI2I0 */
-		.flags	= IORESOURCE_IRQ,
-	}, {
 		.name	= SH_MOBILE_SDHI_IRQ_SDCARD,
 		.start	= evt2irq(0x1220), /* SDHI2_SDHI2I1 */
 		.flags	= IORESOURCE_IRQ,
@@ -1087,6 +1083,7 @@ static struct platform_device sdhi2_device = {
 };
 
 /* SH_MMCIF */
+#if IS_ENABLED(CONFIG_MMC_SH_MMCIF)
 static struct resource sh_mmcif_resources[] = {
 	[0] = {
 		.name	= "MMCIF",
@@ -1118,7 +1115,7 @@ static struct sh_mmcif_plat_data sh_mmcif_plat = {
 	.slave_id_rx	= SHDMA_SLAVE_MMCIF_RX,
 };
 
-static struct platform_device sh_mmcif_device __maybe_unused = {
+static struct platform_device sh_mmcif_device = {
 	.name		= "sh_mmcif",
 	.id		= 0,
 	.dev		= {
@@ -1129,7 +1126,7 @@ static struct platform_device sh_mmcif_device __maybe_unused = {
 	.num_resources	= ARRAY_SIZE(sh_mmcif_resources),
 	.resource	= sh_mmcif_resources,
 };
-
+#endif
 
 static int mackerel_camera_add(struct soc_camera_device *icd);
 static void mackerel_camera_del(struct soc_camera_device *icd);
@@ -1236,11 +1233,12 @@ static struct platform_device *mackerel_devices[] __initdata = {
 	&fsi_hdmi_device,
 	&nand_flash_device,
 	&sdhi0_device,
-#if !defined(CONFIG_MMC_SH_MMCIF) && !defined(CONFIG_MMC_SH_MMCIF_MODULE)
+#if !IS_ENABLED(CONFIG_MMC_SH_MMCIF)
 	&sdhi1_device,
+#else
+	&sh_mmcif_device,
 #endif
 	&sdhi2_device,
-	&sh_mmcif_device,
 	&ceu_device,
 	&mackerel_camera,
 	&hdmi_device,
@@ -1305,11 +1303,6 @@ static struct i2c_board_info i2c1_devices[] = {
 };
 
 static const struct pinctrl_map mackerel_pinctrl_map[] = {
-	/* MMCIF */
-	PIN_MAP_MUX_GROUP_DEFAULT("sh_mmcif.0", "pfc-sh7372",
-				  "mmc0_data8_0", "mmc0"),
-	PIN_MAP_MUX_GROUP_DEFAULT("sh_mmcif.0", "pfc-sh7372",
-				  "mmc0_ctrl_0", "mmc0"),
 	/* SDHI0 */
 	PIN_MAP_MUX_GROUP_DEFAULT("sh_mobile_sdhi.0", "pfc-sh7372",
 				  "sdhi0_data4", "sdhi0"),
@@ -1318,11 +1311,17 @@ static const struct pinctrl_map mackerel_pinctrl_map[] = {
 	PIN_MAP_MUX_GROUP_DEFAULT("sh_mobile_sdhi.0", "pfc-sh7372",
 				  "sdhi0_wp", "sdhi0"),
 	/* SDHI1 */
-#if !defined(CONFIG_MMC_SH_MMCIF) && !defined(CONFIG_MMC_SH_MMCIF_MODULE)
+#if !IS_ENABLED(CONFIG_MMC_SH_MMCIF)
 	PIN_MAP_MUX_GROUP_DEFAULT("sh_mobile_sdhi.1", "pfc-sh7372",
 				  "sdhi1_data4", "sdhi1"),
 	PIN_MAP_MUX_GROUP_DEFAULT("sh_mobile_sdhi.1", "pfc-sh7372",
 				  "sdhi1_ctrl", "sdhi1"),
+#else
+	/* MMCIF */
+	PIN_MAP_MUX_GROUP_DEFAULT("sh_mmcif.0", "pfc-sh7372",
+				  "mmc0_data8_0", "mmc0"),
+	PIN_MAP_MUX_GROUP_DEFAULT("sh_mmcif.0", "pfc-sh7372",
+				  "mmc0_ctrl_0", "mmc0"),
 #endif
 	/* SDHI2 */
 	PIN_MAP_MUX_GROUP_DEFAULT("sh_mobile_sdhi.2", "pfc-sh7372",
@@ -1347,10 +1346,11 @@ static void __init mackerel_init(void)
 		{ "A3SP", &usbhs0_device, },
 		{ "A3SP", &usbhs1_device, },
 		{ "A3SP", &nand_flash_device, },
-		{ "A3SP", &sh_mmcif_device, },
 		{ "A3SP", &sdhi0_device, },
-#if !defined(CONFIG_MMC_SH_MMCIF) && !defined(CONFIG_MMC_SH_MMCIF_MODULE)
+#if !IS_ENABLED(CONFIG_MMC_SH_MMCIF)
 		{ "A3SP", &sdhi1_device, },
+#else
+		{ "A3SP", &sh_mmcif_device, },
 #endif
 		{ "A3SP", &sdhi2_device, },
 		{ "A4R", &ceu_device, },
-- 
1.7.10.4



From horms+renesas at verge.net.au  Tue Apr  2 22:08:24 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed,  3 Apr 2013 11:08:24 +0900
Subject: [PATCH 09/11] ARM: shmobile: mackerel: switch SDHI and MMCIF
 interfaces to slot-gpio
In-Reply-To: <1364954906-16014-1-git-send-email-horms+renesas@verge.net.au>
References: <1364954906-16014-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1364954906-16014-10-git-send-email-horms+renesas@verge.net.au>

From: Guennadi Liakhovetski <g.liakhovetski at gmx.de>

Both SDHI and MMCIF drivers can use the standard slot-gpio card-detection
functions. Switch mackerel to using them instead of platform callbacks.

Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas at gmail.com>
Acked-by: Magnus Damm <damm at opensource.se>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/board-mackerel.c |   39 ++++++++++---------------------
 1 file changed, 12 insertions(+), 27 deletions(-)

diff --git a/arch/arm/mach-shmobile/board-mackerel.c b/arch/arm/mach-shmobile/board-mackerel.c
index 734565d..a47a1116 100644
--- a/arch/arm/mach-shmobile/board-mackerel.c
+++ b/arch/arm/mach-shmobile/board-mackerel.c
@@ -963,15 +963,6 @@ static struct platform_device nand_flash_device = {
 	},
 };
 
-/*
- * The card detect pin of the top SD/MMC slot (CN7) is active low and is
- * connected to GPIO A22 of SH7372 (GPIO 41).
- */
-static int slot_cn7_get_cd(struct platform_device *pdev)
-{
-	return !gpio_get_value(41);
-}
-
 /* SDHI0 */
 static struct sh_mobile_sdhi_info sdhi0_info = {
 	.dma_slave_tx	= SHDMA_SLAVE_SDHI0_TX,
@@ -1011,13 +1002,15 @@ static struct platform_device sdhi0_device = {
 
 #if !defined(CONFIG_MMC_SH_MMCIF) && !defined(CONFIG_MMC_SH_MMCIF_MODULE)
 /* SDHI1 */
+
+/* GPIO 41 can trigger IRQ8, but it is used by USBHS1, we have to poll */
 static struct sh_mobile_sdhi_info sdhi1_info = {
 	.dma_slave_tx	= SHDMA_SLAVE_SDHI1_TX,
 	.dma_slave_rx	= SHDMA_SLAVE_SDHI1_RX,
-	.tmio_flags	= TMIO_MMC_WRPROTECT_DISABLE,
+	.tmio_flags	= TMIO_MMC_WRPROTECT_DISABLE | TMIO_MMC_USE_GPIO_CD,
 	.tmio_caps	= MMC_CAP_SD_HIGHSPEED | MMC_CAP_SDIO_IRQ |
 			  MMC_CAP_NEEDS_POLL,
-	.get_cd		= slot_cn7_get_cd,
+	.cd_gpio	= 41,
 };
 
 static struct resource sdhi1_resources[] = {
@@ -1052,23 +1045,19 @@ static struct platform_device sdhi1_device = {
 };
 #endif
 
+/* SDHI2 */
+
 /*
  * The card detect pin of the top SD/MMC slot (CN23) is active low and is
- * connected to GPIO SCIFB_SCK of SH7372 (162).
+ * connected to GPIO SCIFB_SCK of SH7372 (GPIO 162).
  */
-static int slot_cn23_get_cd(struct platform_device *pdev)
-{
-	return !gpio_get_value(162);
-}
-
-/* SDHI2 */
 static struct sh_mobile_sdhi_info sdhi2_info = {
 	.dma_slave_tx	= SHDMA_SLAVE_SDHI2_TX,
 	.dma_slave_rx	= SHDMA_SLAVE_SDHI2_RX,
-	.tmio_flags	= TMIO_MMC_WRPROTECT_DISABLE,
+	.tmio_flags	= TMIO_MMC_WRPROTECT_DISABLE | TMIO_MMC_USE_GPIO_CD,
 	.tmio_caps	= MMC_CAP_SD_HIGHSPEED | MMC_CAP_SDIO_IRQ |
 			  MMC_CAP_NEEDS_POLL,
-	.get_cd		= slot_cn23_get_cd,
+	.cd_gpio	= 162,
 };
 
 static struct resource sdhi2_resources[] = {
@@ -1127,7 +1116,9 @@ static struct sh_mmcif_plat_data sh_mmcif_plat = {
 	.caps		= MMC_CAP_4_BIT_DATA |
 			  MMC_CAP_8_BIT_DATA |
 			  MMC_CAP_NEEDS_POLL,
-	.get_cd		= slot_cn7_get_cd,
+	.use_cd_gpio	= true,
+	/* card detect pin for SD/MMC slot (CN7) */
+	.cd_gpio	= 41,
 	.slave_id_tx	= SHDMA_SLAVE_MMCIF_TX,
 	.slave_id_rx	= SHDMA_SLAVE_MMCIF_RX,
 };
@@ -1475,12 +1466,6 @@ static void __init mackerel_init(void)
 	/* SDHI0 PORT172 card-detect IRQ26 */
 	gpio_request(GPIO_FN_IRQ26_172, NULL);
 
-	/* card detect pin for MMC slot (CN7) */
-	gpio_request_one(41, GPIOF_IN, NULL);
-
-	/* card detect pin for microSD slot (CN23) */
-	gpio_request_one(162, GPIOF_IN, NULL);
-
 	/* FLCTL */
 	gpio_request(GPIO_FN_D0_NAF0, NULL);
 	gpio_request(GPIO_FN_D1_NAF1, NULL);
-- 
1.7.10.4



From tpiepho at gmail.com  Tue Apr  2 22:12:58 2013
From: tpiepho at gmail.com (Trent Piepho)
Date: Tue, 2 Apr 2013 19:12:58 -0700
Subject: [PATCH V2 08/12] spi/mxs: Fix race in setup method
In-Reply-To: <201304030131.37782.marex@denx.de>
References: <1364905195-24286-1-git-send-email-tpiepho@gmail.com>
 <1364905195-24286-8-git-send-email-tpiepho@gmail.com>
 <201304030131.37782.marex@denx.de>
Message-ID: <CA+7tXigasUbSRD6hQH66m6XsDkzS9ubLSB24f4akB3pv9xrT=A@mail.gmail.com>

On Tue, Apr 2, 2013 at 4:31 PM, Marek Vasut <marex at denx.de> wrote:
>>  static int mxs_spi_setup(struct spi_device *dev)
>>  {
>> -     int err = 0;
>> -
>>       if (!dev->bits_per_word)
>>               dev->bits_per_word = 8;
>>
>>       if (dev->mode & ~(SPI_CPOL | SPI_CPHA))
>>               return -EINVAL;
>>
>> -     err = mxs_spi_setup_transfer(dev, NULL);
>> -     if (err) {
>> -             dev_err(&dev->dev,
>> -                     "Failed to setup transfer, error = %d\n", err);
>> -     }
>> +     if (dev->bits_per_word != 8)
>> +             return -EINVAL;
>
> What's this new addition doing here?

It's not new.  The only useful thing mxs_spi_setup_transfer() (which
is no longer called) did in this instance was make that check.

> btw. I was under the impression the MXS SSP block can handle other word-widths
> than 8 bit, no ?

In theory it can, however the driver only supports 8-bits and will
reject anything else.


From shawn.guo at linaro.org  Tue Apr  2 22:13:51 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Wed, 3 Apr 2013 10:13:51 +0800
Subject: [PATCH] ARM: imx: do not bring up unavailable cores
In-Reply-To: <20130402151715.GB6608@mudshark.cambridge.arm.com>
References: <1364913146-26084-1-git-send-email-shawn.guo@linaro.org>
 <20130402151715.GB6608@mudshark.cambridge.arm.com>
Message-ID: <20130403021348.GK24039@S2101-09.ap.freescale.net>

On Tue, Apr 02, 2013 at 04:17:15PM +0100, Will Deacon wrote:
> On Tue, Apr 02, 2013 at 03:32:26PM +0100, Shawn Guo wrote:
> > The i.MX6 Quad can be fused as i.MX6 Dual chip, and similarly i.MX6
> > DualLite can be fused as i.MX6 Solo.  The actual number of available
> > cores can be found out from SCU.
> > 
> > Since we do not reflect the fusing thing in device tree, the function
> > arm_dt_init_cpu_maps() will always call set_cpu_possible(true) for 4
> > cores on i.MX6 Quad/Dual and 2 cores for i.MX6 DualLite/Solo.  This
> > causes failures when kernel tries to bring those unavailable cores
> > online.  For example, the following failure message will be seen when
> > booting an i.MX6 Solo chip.
> > 
> >   CPU1: failed to come online
> > 
> > Though kernel will still boot fine, the message is somehow annoying.
> > Let's get rid of it by calling set_cpu_possible(false) on those
> > unavailable cores.
> > 
> > While at it, the set_cpu_possible(true) for available cores is removed,
> > since it's already been done in arm_dt_init_cpu_maps().
> > 
> > Signed-off-by: Shawn Guo <shawn.guo at linaro.org>
> > ---
> >  arch/arm/mach-imx/platsmp.c |    4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/arch/arm/mach-imx/platsmp.c b/arch/arm/mach-imx/platsmp.c
> > index 7c0b03f..7061bde 100644
> > --- a/arch/arm/mach-imx/platsmp.c
> > +++ b/arch/arm/mach-imx/platsmp.c
> > @@ -79,8 +79,8 @@ static void __init imx_smp_init_cpus(void)
> >  
> >  	ncores = scu_get_core_count(scu_base);
> >  
> > -	for (i = 0; i < ncores; i++)
> > -		set_cpu_possible(i, true);
> > +	for (i = ncores; i < NR_CPUS; i++)
> > +		set_cpu_possible(i, false);
> >  }
> 
> So you're passing the wrong DT to the kernel and then getting annoyed about
> some warnings in the dmesg?

I wouldn't way I'm passing the wrong DT to the kernel.  Here is the
thing, for i.MX6 DualLite example.

The i.MX6 DualLite is a dual core CA9 SoC.  The SoC is designed with a
One Time Programming (OTP) fuse bit.  When this fuse bit gets
programmed, one of the core will become unavailable and SCU
register will report core number as 1.

We write up DT for dual core case as default and let kernel to find out
if the i.MX6 DualLite it runs on actually has only one core available.

> Assuming the bootloader knows how many CPUs
> there are, shouldn't that be sorting out the CPU nodes before passing the
> dtb to the kernel?

The bootloader doesn't know the core numbers, unless we have code in
bootloader to find it out by reading fuse bit or SCU register that the
i.MX6 DualLite has one or two cores available.

Shawn



From kgene.kim at samsung.com  Tue Apr  2 22:16:37 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Wed, 03 Apr 2013 11:16:37 +0900
Subject: [PATCH 0/2] These two patches to s3c_pm_arch_prepare_irqs() were
 part of the work
In-Reply-To: <24b401ce300f$5a767b40$0f6371c0$%kim@samsung.com>
References: <1363711900-25560-1-git-send-email-dianders@chromium.org>
 <24b401ce300f$5a767b40$0f6371c0$%kim@samsung.com>
Message-ID: <24b501ce3011$454d3c70$cfe7b550$%kim@samsung.com>

Kukjin Kim wrote:
> 
> Doug Anderson wrote:
> >
> > to make suspend/resume reliable on the ARM Chromebook
> > (exynos5250-snow).
> >
> > A few more details:
> > - The first patch is not strictly needed but was a nice cleanup.  Our
> >   understanding was that EINT0 was originally turned on for exynos
> >   evt0 silicon and not needed for evt1.
> 
> Looks good to me, applied, thanks.
> 
> > - The second patch is more important and (also) more obvious.  The
> >   function was modifying the S5P_WAKEUP_MASK register and then
> >   clobbering its own modifications.
> >
> Applied with 1st one, BTW, do you want to send this for stable tree?
> 
One more note, just now I discussed Jaecheol Lee about the bit,
ENABLE_WAKEUP_SW, as the patch fixed, it should be cleared but used to be
set s3c_irqwake_intmask. Let me check again, then if any updates I'll let
you know.

Thanks.

- Kukjin



From marex at denx.de  Tue Apr  2 22:27:41 2013
From: marex at denx.de (Marek Vasut)
Date: Wed, 3 Apr 2013 04:27:41 +0200
Subject: [PATCH V2 08/12] spi/mxs: Fix race in setup method
In-Reply-To: <CA+7tXigasUbSRD6hQH66m6XsDkzS9ubLSB24f4akB3pv9xrT=A@mail.gmail.com>
References: <1364905195-24286-1-git-send-email-tpiepho@gmail.com>
 <201304030131.37782.marex@denx.de>
 <CA+7tXigasUbSRD6hQH66m6XsDkzS9ubLSB24f4akB3pv9xrT=A@mail.gmail.com>
Message-ID: <201304030427.41297.marex@denx.de>

Dear Trent Piepho,

> On Tue, Apr 2, 2013 at 4:31 PM, Marek Vasut <marex at denx.de> wrote:
> >>  static int mxs_spi_setup(struct spi_device *dev)
> >>  {
> >> 
> >> -     int err = 0;
> >> -
> >> 
> >>       if (!dev->bits_per_word)
> >>       
> >>               dev->bits_per_word = 8;
> >>       
> >>       if (dev->mode & ~(SPI_CPOL | SPI_CPHA))
> >>       
> >>               return -EINVAL;
> >> 
> >> -     err = mxs_spi_setup_transfer(dev, NULL);
> >> -     if (err) {
> >> -             dev_err(&dev->dev,
> >> -                     "Failed to setup transfer, error = %d\n", err);
> >> -     }
> >> +     if (dev->bits_per_word != 8)
> >> +             return -EINVAL;
> > 
> > What's this new addition doing here?
> 
> It's not new.

It is new in the context of this patch and it's not described in the commit 
message.

> The only useful thing mxs_spi_setup_transfer() (which
> is no longer called) did in this instance was make that check.
> 
> > btw. I was under the impression the MXS SSP block can handle other
> > word-widths than 8 bit, no ?
> 
> In theory it can,

In practice too ;-)

> however the driver only supports 8-bits and will
> reject anything else.

Then please at least add a comment about this.

Best regards,
Marek Vasut


From robherring2 at gmail.com  Tue Apr  2 22:31:48 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Tue, 02 Apr 2013 21:31:48 -0500
Subject: [PATCH v2 12/13] ARM: move sp804 and integrator timers to
 drivers/clocksource
In-Reply-To: <515B7AC1.9090403@linaro.org>
References: <1364854883-5961-1-git-send-email-robherring2@gmail.com>
 <1364854883-5961-13-git-send-email-robherring2@gmail.com>
 <515A179A.8020800@linaro.org> <515B3637.8090603@gmail.com>
 <515B7AC1.9090403@linaro.org>
Message-ID: <515B9494.3060807@gmail.com>

On 04/02/2013 07:41 PM, John Stultz wrote:
> On 04/02/2013 12:49 PM, Rob Herring wrote:
>> On 04/01/2013 06:26 PM, John Stultz wrote:
>>> On 04/01/2013 03:21 PM, Rob Herring wrote:
>>>> diff --git a/drivers/clocksource/integrator_ap_timer.c
>>>> b/drivers/clocksource/integrator_ap_timer.c
>>>> new file mode 100644
>>>> index 0000000..05e6204
>>>> --- /dev/null
>>>> +++ b/drivers/clocksource/integrator_ap_timer.c
>>> [snip]
>>
>>>> +CLOCKSOURCE_OF_DECLARE(integrator_ap, "integrator-timer",
>>>> ap_of_timer_init);
>>> So, most of the code here is really clockevent code and not clocksource
>>> code. I realize they were combined in the mach directory you're copying
>>> them from, but if we're going to move all this code out of the arch
>>> directory and into drivers/, I'd like to propose we not dump it all into
>>> drivers/clocksource.
>> Arguably, half the h/w is used for clocksource and half for clockevent
>> so it is equal. :) The sp804 and integrator are somewhat separated that
>> carving them up may be possible, but there are examples like i.MX timers
>> where the implementations are tied more closely together (the clockevent
>> compare value is the clocksource counter + delta).
>>
>> Where do I put the init functions which need to know about both?
> 
> Either have them init themselves via *_initcall, or call out from one to
> the other?

initcalls are too late on ARM. This is why CLOCKSOURCE_OF_DECLARE was
created, but it is tied to 1 init callback per matched DT node. The nice
thing about it is we avoid any headers with arbitrary timer init
functions and data and calls from the platform code in the DT case.

We could also create a CLOCKEVENT_OF_DECLARE and match twice, but then
that is 2 searches thru the DT.

I don't think an undefined interface of shared data that's different for
every timer is a good idea. This is typically the mapped address(es),
clocks, spinlocks, register access functions, misc flags, etc.

>> What about all the other timers that are already in drivers/clocksource?
> 
> I'm hoping to start moving those out soon.

I count 3 clkevt only, 4 clocksource only and 13 drivers with both. How
intertwined the 13 are, I don't know. I think we should get things moved
to a common spot first and look at all the various h/w first before
deciding how to best split things up.

Rob

>>> For more context here see:
>>> http://www.spinics.net/lists/arm-kernel/msg234074.html
>> Seems like this is more a maintainer issue than necessarily what is the
>> right split of code (not that those are completely unrelated). Perhaps
>> splitting maintainership between core and drivers is needed. It
>> definitely seems Thomas cannot keep up with the plethora of ARM related
>> timers and irqchips getting moved into drivers/.
> 
> Well, I'm hoping Daniel can help offload Thomas, but I've still not
> heard back if Thomas is ok with this whole proposal or not.
> 
> thanks
> -john



From festevam at gmail.com  Tue Apr  2 22:38:26 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Tue, 2 Apr 2013 23:38:26 -0300
Subject: [PATCH] ARM: imx: do not bring up unavailable cores
In-Reply-To: <20130403021348.GK24039@S2101-09.ap.freescale.net>
References: <1364913146-26084-1-git-send-email-shawn.guo@linaro.org>
 <20130402151715.GB6608@mudshark.cambridge.arm.com>
 <20130403021348.GK24039@S2101-09.ap.freescale.net>
Message-ID: <CAOMZO5AJjz4Z68GxkeCM3rH9p9-z6jaOM35MBSjN-UE_Dk4=eg@mail.gmail.com>

On Tue, Apr 2, 2013 at 11:13 PM, Shawn Guo <shawn.guo at linaro.org> wrote:

> The bootloader doesn't know the core numbers, unless we have code in
> bootloader to find it out by reading fuse bit or SCU register that the
> i.MX6 DualLite has one or two cores available.

U-boot does read SCU register and can identify Quad/Dual-Lite/Solo/Solo-lite.


From shawn.guo at linaro.org  Tue Apr  2 22:47:21 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Wed, 3 Apr 2013 10:47:21 +0800
Subject: [PATCH] ARM: imx: do not bring up unavailable cores
In-Reply-To: <CAOMZO5AJjz4Z68GxkeCM3rH9p9-z6jaOM35MBSjN-UE_Dk4=eg@mail.gmail.com>
References: <1364913146-26084-1-git-send-email-shawn.guo@linaro.org>
 <20130402151715.GB6608@mudshark.cambridge.arm.com>
 <20130403021348.GK24039@S2101-09.ap.freescale.net>
 <CAOMZO5AJjz4Z68GxkeCM3rH9p9-z6jaOM35MBSjN-UE_Dk4=eg@mail.gmail.com>
Message-ID: <20130403024719.GF27148@S2101-09.ap.freescale.net>

On Tue, Apr 02, 2013 at 11:38:26PM -0300, Fabio Estevam wrote:
> On Tue, Apr 2, 2013 at 11:13 PM, Shawn Guo <shawn.guo at linaro.org> wrote:
> 
> > The bootloader doesn't know the core numbers, unless we have code in
> > bootloader to find it out by reading fuse bit or SCU register that the
> > i.MX6 DualLite has one or two cores available.
> 
> U-boot does read SCU register and can identify Quad/Dual-Lite/Solo/Solo-lite.

Ah, great.  I haven't checked the U-Boot code for some time.  But does
U-Boot remove cpu nodes of those unavailable cores from device tree
before passing it to kernel?

Shawn



From ben at decadent.org.uk  Tue Apr  2 22:53:00 2013
From: ben at decadent.org.uk (Ben Hutchings)
Date: Wed, 03 Apr 2013 03:53:00 +0100
Subject: [PATCH] ARM: autcpu12: Fix config check in autcpu12_init_late()
In-Reply-To: <20130402171217.GE25867@quad.lixom.net>
References: <1363988123.3728.45.camel@deadeye.wl.decadent.org.uk>
 <1364016140.352883792@f399.i.mail.ru>
 <20130402171217.GE25867@quad.lixom.net>
Message-ID: <1364957580.2840.2.camel@deadeye.wl.decadent.org.uk>

On Tue, 2013-04-02 at 10:12 -0700, Olof Johansson wrote:
> On Sat, Mar 23, 2013 at 09:22:20AM +0400, Alexander Shiyan wrote:
> > > The 'CONFIG_' prefix is not implicit in IS_ENABLED().
> > > 
> > > Signed-off-by: Ben Hutchings <ben at decadent.org.uk>
> > > Cc: Alexander Shiyan <shc_work at mail.ru>
> > > Cc: Olof Johansson <olof at lixom.net>
> > > Cc: Paul Bolle <pebolle at tiscali.nl>
> > > Cc: <stable at vger.kernel.org> # 3.8+
> > > ---
> > > Found by inspection.  This is not even compile-tested.
> > > 
> > > Ben.
> > > 
> > >  arch/arm/mach-clps711x/board-autcpu12.c |    3 ++-
> > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/arch/arm/mach-clps711x/board-autcpu12.c b/arch/arm/mach-clps711x/board-autcpu12.c
> > > index f385847..8138523 100644
> > > --- a/arch/arm/mach-clps711x/board-autcpu12.c
> > > +++ b/arch/arm/mach-clps711x/board-autcpu12.c
> > > @@ -158,7 +158,8 @@ static void __init autcpu12_init(void)
> > >  
> > >  static void __init autcpu12_init_late(void)
> > >  {
> > > -	if (IS_ENABLED(MTD_NAND_GPIO) && IS_ENABLED(GPIO_GENERIC_PLATFORM)) {
> > > +	if (IS_ENABLED(CONFIG_MTD_NAND_GPIO) &&
> > > +	    IS_ENABLED(CONFIG_GPIO_GENERIC_PLATFORM)) {
> > >  		/* We are need both drivers to handle NAND */
> > >  		platform_device_register(&autcpu12_nand_pdev);
> > >  	}
> > 
> > Oops. Right.
> > And I think checks can be removed completely.
> 
> Seems reasonable -- there's no reason to hold off registering the device just
> because the driver isn't enabled.
> 
> Who'll repost a patch to just remove the tests? Ben? Alexander?

I won't - I don't know anything about this code other than it's spelt
wrong.

Ben.

-- 
Ben Hutchings
Power corrupts.  Absolute power is kind of neat.
                           - John Lehman, Secretary of the US Navy 1981-1987
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130403/4f0c7b9c/attachment.sig>

From nicolas.pitre at linaro.org  Tue Apr  2 23:00:20 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Tue, 2 Apr 2013 23:00:20 -0400 (EDT)
Subject: [GIT PULL] Multi Cluster Power Management infrastructure
In-Reply-To: <20130328134808.GD16765@e102568-lin.cambridge.arm.com>
References: <alpine.LFD.2.03.1303251219530.1372@syhkavp.arg>
 <20130328134808.GD16765@e102568-lin.cambridge.arm.com>
Message-ID: <alpine.LFD.2.03.1304022258430.1171@syhkavp.arg>


Ping.


On Thu, 28 Mar 2013, Lorenzo Pieralisi wrote:

> Hi Russell,
> 
> On Mon, Mar 25, 2013 at 04:41:52PM +0000, Nicolas Pitre wrote:
> > 
> > Russell, would you please pull the following:
> > 
> > 	git://git.linaro.org/people/nico/linux mcpm
> > 
> > This contains the basic infrastructure needed to support CPU hotplug, 
> > deep CPU idle and secondary CPU bringup in a cluster based system such 
> > as, but not limited to, those based on the big.LITTLE architecture.
> 
> Can I ask you please what's your plan for merging this series ?
> We have lots of code in our trees that depends on this set (which has been
> extensively tested), hence I am really looking forward to having a stable
> branch to rebase on top.
> 
> Thank you very much,
> Lorenzo
> 
> > 
> > This is the same set of patches from the previous pull request that 
> > missed thelast merge window, except for minor changes needed for this 
> > code to work with v3.9-rc3 (i.e. removal of the __cpuinit tags and 
> > removal of set_smp_cross_call() from the smp_init_cpus method).
> > 
> > The diffstat follows:
> > 
> >  Documentation/arm/cluster-pm-race-avoidance.txt | 498 ++++++++++++++++++
> >  Documentation/arm/vlocks.txt                    | 211 ++++++++
> >  arch/arm/Kconfig                                |   8 +
> >  arch/arm/common/Makefile                        |   1 +
> >  arch/arm/common/mcpm_entry.c                    | 314 +++++++++++
> >  arch/arm/common/mcpm_head.S                     | 219 ++++++++
> >  arch/arm/common/mcpm_platsmp.c                  |  87 +++
> >  arch/arm/common/vlock.S                         | 108 ++++
> >  arch/arm/common/vlock.h                         |  29 +
> >  arch/arm/include/asm/mcpm_entry.h               | 190 +++++++
> >  10 files changed, 1665 insertions(+)
> > 
> > 
> > Nicolas
> > 
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> > 
> 


From huyuhua2111 at sina.com  Tue Apr  2 23:01:54 2013
From: huyuhua2111 at sina.com (Archer)
Date: Wed, 3 Apr 2013 11:01:54 +0800
Subject: Manufacturer of PCB Solid Carbide Drills and Routers
Message-ID: <201304031101541888899@sina.com>

Dear General Manager:

Trading here, exporting standard solid PCB drills (dia 3.20mm-6.50mm) and special PCB drills with chip-removal groove and reground chisel edge (dia 1.5mm-6.5mm) with good quality and reasonable price.  

Looking forward to hearing from you soon
 
--------------------------
Archer Hu
Archer at wilsonprecisiontool.com
Shanghai Well-Sun Precision Tool Co., Ltd
Add: No. 3 Building, No. 868 Zhenchen Rd, Baoshan District, Shanghai
Tel:021-36162006
Tex:021-36162016
Website: www.well-sun.net

From olof at lixom.net  Tue Apr  2 23:15:11 2013
From: olof at lixom.net (Olof Johansson)
Date: Tue, 2 Apr 2013 20:15:11 -0700
Subject: [GIT PULL] imx fixes for 3.9, take 5
In-Reply-To: <20130402134627.GF24039@S2101-09.ap.freescale.net>
References: <20130402134627.GF24039@S2101-09.ap.freescale.net>
Message-ID: <20130403031511.GB27874@quad.lixom.net>

On Tue, Apr 02, 2013 at 09:46:29PM +0800, Shawn Guo wrote:
> The following changes since commit 07961ac7c0ee8b546658717034fe692fd12eefa9:
> 
>   Linux 3.9-rc5 (2013-03-31 15:12:43 -0700)
> 
> are available in the git repository at:
> 
>   git://git.linaro.org/people/shawnguo/linux-2.6.git tags/imx-fixes-3.9-5
> 
> for you to fetch changes up to 710b213d3f1cdb0451fa2d5a71faa2b1f510e3ad:
> 
>   ARM: imx35 Bugfix admux clock (2013-04-02 21:05:40 +0800)
> 
> ----------------------------------------------------------------
> The imx fixes for 3.9, take 5:
>  - One fix for the typo in use of Kconfig symbol
>    MACH_EUKREA_CPUIMX27_USEUART4.  It's been there for a long time
>    and got caught by code inspection recently.  It hasn't been noticed
>    earlier probably because it does not cause any problem in real.

2.6.35 to be exact.

It's more a sign that the board can be removed than that it should be fixed
immediately for 3.9, wouldn't you say? Clearly no one seems to care about
mainline functionality on that platform -- especially since it was now found
through inspection and not usage.

>  - A couple of fixes on imx35 clock driver to have audmux functional
>    and iomux pad configurable after a reboot.

These look like valid fixes but I can't from the commit messages tell
when the problem was introduced, and what the actual breakage that the
user sees it. It almost looks like it's adding a few clocks that were
never used before, not a regression? I'm happy to be proven wrong though.

So, please resend with just the two clock fixes, as long as they are indeed
regressions for something that used to work. Or I can just cherry-pick them
over if you prefer.


-Olof


From festevam at gmail.com  Tue Apr  2 23:18:53 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Wed, 3 Apr 2013 00:18:53 -0300
Subject: [PATCH] ARM: imx: do not bring up unavailable cores
In-Reply-To: <20130403024719.GF27148@S2101-09.ap.freescale.net>
References: <1364913146-26084-1-git-send-email-shawn.guo@linaro.org>
 <20130402151715.GB6608@mudshark.cambridge.arm.com>
 <20130403021348.GK24039@S2101-09.ap.freescale.net>
 <CAOMZO5AJjz4Z68GxkeCM3rH9p9-z6jaOM35MBSjN-UE_Dk4=eg@mail.gmail.com>
 <20130403024719.GF27148@S2101-09.ap.freescale.net>
Message-ID: <CAOMZO5C5uVDWi1vXTeyQF5P8N=ARHvW-qMknVeyG4zY85KcEkw@mail.gmail.com>

On Tue, Apr 2, 2013 at 11:47 PM, Shawn Guo <shawn.guo at linaro.org> wrote:

> Ah, great.  I haven't checked the U-Boot code for some time.  But does
> U-Boot remove cpu nodes of those unavailable cores from device tree
> before passing it to kernel?

No, it just uses the information from the SCU to print the name of the
mx6 variant on boot.


From shawn.guo at linaro.org  Tue Apr  2 23:40:26 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Wed, 3 Apr 2013 11:40:26 +0800
Subject: [GIT PULL] imx fixes for 3.9, take 5
In-Reply-To: <20130403031511.GB27874@quad.lixom.net>
References: <20130402134627.GF24039@S2101-09.ap.freescale.net>
 <20130403031511.GB27874@quad.lixom.net>
Message-ID: <20130403034023.GN24039@S2101-09.ap.freescale.net>

On Tue, Apr 02, 2013 at 08:15:11PM -0700, Olof Johansson wrote:
> >  - One fix for the typo in use of Kconfig symbol
> >    MACH_EUKREA_CPUIMX27_USEUART4.  It's been there for a long time
> >    and got caught by code inspection recently.  It hasn't been noticed
> >    earlier probably because it does not cause any problem in real.
> 
> 2.6.35 to be exact.
> 
> It's more a sign that the board can be removed than that it should be fixed
> immediately for 3.9, wouldn't you say? Clearly no one seems to care about
> mainline functionality on that platform -- especially since it was now found
> through inspection and not usage.
> 
UART4 on the board is not cared or used by people does not necessarily
means that the board is not cared or used by people.  But I agree that
it's not an urgent fix for 3.9, and I will queue it for 3.10 as a
non-critical fix.

> >  - A couple of fixes on imx35 clock driver to have audmux functional
> >    and iomux pad configurable after a reboot.
> 
> These look like valid fixes but I can't from the commit messages tell
> when the problem was introduced, and what the actual breakage that the
> user sees it. It almost looks like it's adding a few clocks that were
> never used before, not a regression? I'm happy to be proven wrong though.
> 
I think these are regression caused by imx35 common clock migration.

> So, please resend with just the two clock fixes, as long as they are indeed
> regressions for something that used to work. Or I can just cherry-pick them
> over if you prefer.

Please just cherry-pick them, thanks.

Shawn



From santosh.shilimkar at ti.com  Tue Apr  2 23:52:13 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Wed, 3 Apr 2013 09:22:13 +0530
Subject: [GIT PULL] ARM: OMAP5: hwmod, prm/cm data files and updates for
 3.10
In-Reply-To: <20130401170539.GK10155@atomide.com>
References: <1363768852-18125-1-git-send-email-santosh.shilimkar@ti.com>
 <20130401170539.GK10155@atomide.com>
Message-ID: <515BA76D.3000302@ti.com>

Paul,

On Monday 01 April 2013 10:35 PM, Tony Lindgren wrote:
> * Santosh Shilimkar <santosh.shilimkar at ti.com> [130320 01:43]:
>> Tony,
>>
>> Here is the pull request for OMAP5 data file patches which are on list from
>> last merge window. As aligned on list, I have dropped clock data from the
>> series. That means for the boot, one clock data patch needs to be applied.
>> It is available on my git tree in 'out_of_tree/omap5_clk_data' branch.
>>
>> As discussed already on list, you will notice hwmod data loc has come down
>> from ~6000 lines to ~2000 lines becasue of removal of iospace, irq, dma data
>> as well as unused hwmods. Few hwmods for which dt conversion is pending are
>> not added as well but those would add max ~400 loc in future.
>>
>> The following changes since commit a937536b868b8369b98967929045f1df54234323:
>>
>>   Linux 3.9-rc3 (2013-03-17 15:59:32 -0700)
>>
>> are available in the git repository at:
>>
>>   git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux.git for_3.10/omap5_data_files
>>
>> for you to fetch changes up to 8a6a32e589a1a2a5a3fb8ebe8fc7426997bc6d89:
>>
>>   ARM: OMAP5: Enable build and frameowrk initialisations (2013-03-19 14:09:11 +0530)
> 
> Paul, do you have any comments on these?
> 
Ping.

> This branch should be queued separately because of the amount of
> LOC it adds. But as you may have other PRCM related patches then it's
> probably best that you queue it.
> 
Just to be clear, these are all data files patches which are auto-generated.

Thes patchset has already missed last couple of merge windows and its the
biggest bottleneck in getting OMAP5 booting from mainline. So I request
you to please have a look it quickly so that Tony can line that up for
3.10.

Thanks for help in advance !!

Regards,
Santosh


From jason at lakedaemon.net  Tue Apr  2 22:49:19 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Tue, 2 Apr 2013 22:49:19 -0400
Subject: [PATCH v3] ARM: dove: add more hardware description in the DT
In-Reply-To: <20130330221212.GC13280@titan.lakedaemon.net>
References: <20130326080719.2d4d6450@armhf>
 <20130330221212.GC13280@titan.lakedaemon.net>
Message-ID: <20130403024919.GU13280@titan.lakedaemon.net>

On Sat, Mar 30, 2013 at 06:12:12PM -0400, Jason Cooper wrote:
> On Tue, Mar 26, 2013 at 08:07:19AM +0100, Jean-Francois Moine wrote:
> > The 88AP510 chip (Marvell Dove) contains a LCD controller, a display
> > controller and two audio controllers.
> > 
> > Signed-off-by: Jean-Francois Moine <moinejf at free.fr>
> > ---
> > v3 from Sebastian Hesselbarth remarks
> >    - dcon register block ends at 0xc4
> > v2 from Sebastian Hesselbarth remarks
> >    - better names for the devices
> >    - fix bad i2s interrupt controller
> >    - 2 irq's by audio controller
> >    - display controller added
> > ---
> >  arch/arm/boot/dts/dove.dtsi |   38 +++++++++++++++++++++++++++++++
> >  1 file changed, 38 insertions(+)
> 
> Applied to mvebu/dt

I've dropped this version from mvebu/dt until you and Sebastian work it
out.

thx,

Jason.


From avinashphilip at ti.com  Tue Apr  2 23:58:43 2013
From: avinashphilip at ti.com (Philip, Avinash)
Date: Wed, 3 Apr 2013 03:58:43 +0000
Subject: [PATCH v3 1/3] ARM: davinci: clk framework support for
 enable/disable functionality
In-Reply-To: <51597108.4050706@ti.com>
References: <1364197789-16783-1-git-send-email-avinashphilip@ti.com>
 <1364204268-15010-1-git-send-email-avinashphilip@ti.com>
 <51597108.4050706@ti.com>
Message-ID: <518397C60809E147AF5323E0420B992E3EAA74AB@DBDE01.ent.ti.com>

On Mon, Apr 01, 2013 at 17:05:36, Nori, Sekhar wrote:
> On 3/25/2013 3:07 PM, Philip Avinash wrote:
> > Davinci clock framework currently not supporting clock enable/disable
> 
> This is incorrect. We do support enable disable of PSCs in davinci clock
> implementation.
> 
> > functionality on clock nodes. In Davinci platform, EHRPWM module requires
> 
> s/In Davinci platform/On DA850 SoC/
> 
> > support for clock enable/disable for TBCLK support. Hence this patch
> > adds support for enabling/disabling clocks depends on the availability
> > of the functionality.
> 
> I reworded the path description as below. Taking care of above and
> making some other minor changes:
> 
>     DaVinci clock implementation does not support clock enable/disable
>     functionality on non-PSC clock nodes.
> 
>     On DA850 SoC, EHRPWM module requires support for enable/disable
>     of TBCLK controlled using a system module register.
> 
>     This patch adds a method for enabling/disabling non-PSC clocks
>     into DaVinci clock implementation.
> 
> > 
> > Signed-off-by: Philip Avinash <avinashphilip at ti.com>
> > ---
> > Changes since v2:
> > 	- start using "usecount" field in clk structure to
> > 	  enable/disable clocks.
> > 
> > Changes since v1:
> > 	- Add support for clock enable/disable functionality.
> > 
> >  arch/arm/mach-davinci/clock.c |   21 ++++++++++++++-------
> >  arch/arm/mach-davinci/clock.h |    2 ++
> >  2 files changed, 16 insertions(+), 7 deletions(-)
> > 
> > diff --git a/arch/arm/mach-davinci/clock.c b/arch/arm/mach-davinci/clock.c
> > index d458558..960c7a5 100644
> > --- a/arch/arm/mach-davinci/clock.c
> > +++ b/arch/arm/mach-davinci/clock.c
> > @@ -35,19 +35,26 @@ static void __clk_enable(struct clk *clk)
> >  {
> >  	if (clk->parent)
> >  		__clk_enable(clk->parent);
> > -	if (clk->usecount++ == 0 && (clk->flags & CLK_PSC))
> > -		davinci_psc_config(clk->domain, clk->gpsc, clk->lpsc,
> > -				true, clk->flags);
> > +	if (clk->usecount++ == 0) {
> > +		if (clk->flags & CLK_PSC)
> > +			davinci_psc_config(clk->domain, clk->gpsc, clk->lpsc,
> > +					true, clk->flags);
> 
> This line break can be aligned to open parenthesis. This is reported by
> checkpatch --strict. I fixed this locally.
> 
> With these changed, I am queuing this patch for v3.10


Thanks for correction and queuing. checkpatch --strict is new to me.

Avinash

> 
> Thanks,
> Sekhar
> 


From nsekhar at ti.com  Wed Apr  3 00:17:10 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Wed, 3 Apr 2013 09:47:10 +0530
Subject: [PATCH v7 0/5] Add DT support for davinci_mmc driver
In-Reply-To: <87wqskx6pd.fsf@octavius.laptop.org>
References: <1364476211-14322-1-git-send-email-prakash.pm@ti.com>
 <515AAB88.3030406@ti.com> <87wqskx6pd.fsf@octavius.laptop.org>
Message-ID: <515BAD46.8060904@ti.com>

On 4/2/2013 9:31 PM, Chris Ball wrote:
> Hi,
> 
> On Tue, Apr 02 2013, Sekhar Nori wrote:
>> I would like to take this series through DaVinci tree to manage the
>> dependencies with mach-davinci. I need your ack on the driver part and
>> the DT binding. Can you please provide your ack?
> 
> Acked-by: Chris Ball <cjb at laptop.org>

Thanks Chris. I added your Ack to 2/5 and 3/5 which had driver changes.

Regards,
Sekhar


From plagnioj at jcrosoft.com  Wed Apr  3 00:33:30 2013
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Wed, 3 Apr 2013 06:33:30 +0200
Subject: [PATCHv3 0/6] fb: vt8500: patches for 3.10
In-Reply-To: <1364926838-6721-1-git-send-email-linux@prisktech.co.nz>
References: <1364926838-6721-1-git-send-email-linux@prisktech.co.nz>
Message-ID: <20130403043330.GM20693@game.jcrosoft.org>

On 07:20 Wed 03 Apr     , Tony Prisk wrote:
Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
on the whole serie

Best Regards,
J.
> V3 Changes:
> Tidied up patch 1 as requested by Jean-Christophe - Makes the patch much
> simpler.
> 
> V2 Changes:
> Split the SoC and board portions of the binding into their respective files.
> Removed the forced non-interlaced code from wm8505fb.c and vt8500lcdfb.c
> 
> Julia Lawall (1):
>   drivers/video/wm8505fb.c: use devm_ functions
> 
> Tony Prisk (5):
>   video: vt8500: Make wmt_ge_rops optional
>   video: vt8500: Remove unused platform_data/video-vt8500lcdfb.h
>   video: vt8500: Correct descriptions in video/Kconfig
>   video: vt8500: Adjust contrast in wm8505 framebuffer driver.
>   video: fb: vt8500: Convert framebuffer drivers to standardized
>     binding
> 
>  .../devicetree/bindings/video/via,vt8500-fb.txt    |   48 ++-----
>  .../devicetree/bindings/video/wm,wm8505-fb.txt     |   32 +++--
>  arch/arm/boot/dts/vt8500-bv07.dts                  |   34 ++---
>  arch/arm/boot/dts/vt8500.dtsi                      |    4 +-
>  arch/arm/boot/dts/wm8505-ref.dts                   |   34 ++---
>  arch/arm/boot/dts/wm8505.dtsi                      |    4 +-
>  arch/arm/boot/dts/wm8650-mid.dts                   |   36 +++--
>  arch/arm/boot/dts/wm8650.dtsi                      |    4 +-
>  arch/arm/boot/dts/wm8850-w70v2.dts                 |   40 +++---
>  arch/arm/boot/dts/wm8850.dtsi                      |    4 +-
>  drivers/video/Kconfig                              |   37 +++--
>  drivers/video/vt8500lcdfb.c                        |   55 +++-----
>  drivers/video/wm8505fb.c                           |  144 ++++++--------------
>  drivers/video/wmt_ge_rops.h                        |   23 ++++
>  include/linux/platform_data/video-vt8500lcdfb.h    |   31 -----
>  15 files changed, 211 insertions(+), 319 deletions(-)
>  delete mode 100644 include/linux/platform_data/video-vt8500lcdfb.h
> 
> -- 
> 1.7.9.5
> 


From festevam at gmail.com  Wed Apr  3 00:47:42 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Wed,  3 Apr 2013 01:47:42 -0300
Subject: [PATCH] ARM: dts: Add initial support for Wandboard Dual-Lite
Message-ID: <1364964462-19143-1-git-send-email-festevam@gmail.com>

From: Fabio Estevam <fabio.estevam at freescale.com>

Wandboard is a development board that has two variants: one version based
on mx6 dual lite and another one based on mx6 solo.

For more details about Wandboard, please refer to: http://www.wandboard.org/

Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
---
 arch/arm/boot/dts/Makefile              |    1 +
 arch/arm/boot/dts/imx6dl-wandboard.dtsp |   40 +++++++++++++++++++++++++++++++
 arch/arm/boot/dts/imx6dl.dtsip          |   11 +++++++++
 3 files changed, 52 insertions(+)
 create mode 100644 arch/arm/boot/dts/imx6dl-wandboard.dtsp

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 5345ac1..a566619 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -100,6 +100,7 @@ dtb-$(CONFIG_ARCH_MXC) += \
 	imx53-smd.dtb \
 	imx6dl-sabreauto.dtb \
 	imx6dl-sabresd.dtb \
+	imx6dl-wandboard.dtb \
 	imx6q-arm2.dtb \
 	imx6q-sabreauto.dtb \
 	imx6q-sabrelite.dtb \
diff --git a/arch/arm/boot/dts/imx6dl-wandboard.dtsp b/arch/arm/boot/dts/imx6dl-wandboard.dtsp
new file mode 100644
index 0000000..e95d2b0
--- /dev/null
+++ b/arch/arm/boot/dts/imx6dl-wandboard.dtsp
@@ -0,0 +1,40 @@
+/*
+ * Copyright 2013 Freescale Semiconductor, Inc.
+ *
+ * Author: Fabio Estevam <fabio.estevam at freescale.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.
+ *
+ */
+/dts-v1/;
+#include "imx6dl.dtsip"
+
+/ {
+	model = "Wandboard i.MX6 Dual Lite Board";
+	compatible = "wand,imx6dl-wandboard", "fsl,imx6q";
+
+	memory {
+		reg = <0x10000000 0x40000000>;
+	};
+};
+
+&fec {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_enet_1>;
+	phy-mode = "rgmii";
+	status = "okay";
+};
+
+&uart1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_uart1_1>;
+	status = "okay";
+};
+
+&usdhc3 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_usdhc3_4pin>;
+	status = "okay";
+};
diff --git a/arch/arm/boot/dts/imx6dl.dtsip b/arch/arm/boot/dts/imx6dl.dtsip
index 951ba53..2e6cff0 100644
--- a/arch/arm/boot/dts/imx6dl.dtsip
+++ b/arch/arm/boot/dts/imx6dl.dtsip
@@ -136,6 +136,17 @@
 							MX6DL_PAD_SD3_DAT7__SD3_DATA7 0x17059
 						>;
 					};
+
+					pinctrl_usdhc3_4pin: usdhc3grp-4pin {
+						fsl,pins = <
+							MX6DL_PAD_SD3_CMD__SD3_CMD    0x17059
+							MX6DL_PAD_SD3_CLK__SD3_CLK    0x10059
+							MX6DL_PAD_SD3_DAT0__SD3_DATA0 0x17059
+							MX6DL_PAD_SD3_DAT1__SD3_DATA1 0x17059
+							MX6DL_PAD_SD3_DAT2__SD3_DATA2 0x17059
+							MX6DL_PAD_SD3_DAT3__SD3_DATA3 0x17059
+						>;
+					};
 				};
 
 
-- 
1.7.9.5



From plagnioj at jcrosoft.com  Wed Apr  3 00:45:55 2013
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Wed, 3 Apr 2013 06:45:55 +0200
Subject: [PATCH] ARM: at91/tc: fix clock source id for tc block > 1
In-Reply-To: <1364921211-15756-1-git-send-email-linux-arm@overkiz.com>
References: <1364921211-15756-1-git-send-email-linux-arm@overkiz.com>
Message-ID: <20130403044555.GN20693@game.jcrosoft.org>

On 18:46 Tue 02 Apr     , Boris BREZILLON wrote:
> This patch fixes wrong clock request for TC block 2.
> The second block was using t0_clk, t1_clk and t2_clk clks instead of
> t3_clk, t4_clk and t5_clk clks.
> 
this is intended as we have 3 clock per device

Best Regards,
J.
> 
> Signed-off-by: Boris BREZILLON <linux-arm at overkiz.com>
> ---
>  drivers/misc/atmel_tclib.c |   24 ++++++++++++++++--------
>  1 file changed, 16 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/misc/atmel_tclib.c b/drivers/misc/atmel_tclib.c
> index c8d8e38..768a988 100644
> --- a/drivers/misc/atmel_tclib.c
> +++ b/drivers/misc/atmel_tclib.c
> @@ -142,6 +142,8 @@ static int __init tc_probe(struct platform_device *pdev)
>  	struct atmel_tc *tc;
>  	struct clk	*clk;
>  	int		irq;
> +	char		clk_id[7];
> +	int		clk_offset;
>  
>  	if (!platform_get_resource(pdev, IORESOURCE_MEM, 0))
>  		return -EINVAL;
> @@ -156,25 +158,31 @@ static int __init tc_probe(struct platform_device *pdev)
>  
>  	tc->pdev = pdev;
>  
> -	clk = clk_get(&pdev->dev, "t0_clk");
> -	if (IS_ERR(clk)) {
> -		kfree(tc);
> -		return -EINVAL;
> -	}
> -
>  	/* Now take SoC information if available */
>  	if (pdev->dev.of_node) {
>  		const struct of_device_id *match;
>  		match = of_match_node(atmel_tcb_dt_ids, pdev->dev.of_node);
>  		if (match)
>  			tc->tcb_config = match->data;
> +		clk_offset = of_alias_get_id(tc->pdev->dev.of_node, "tcb");
> +	} else
> +		clk_offset = pdev->id;
> +	clk_offset *= 3;
> +
> +	snprintf(clk_id, sizeof(clk_id), "t%d_clk", clk_offset++);
> +	clk = clk_get(&pdev->dev, clk_id);
> +	if (IS_ERR(clk)) {
> +		kfree(tc);
> +		return -EINVAL;
>  	}
>  
>  	tc->clk[0] = clk;
> -	tc->clk[1] = clk_get(&pdev->dev, "t1_clk");
> +	snprintf(clk_id, sizeof(clk_id), "t%d_clk", clk_offset++);
> +	tc->clk[1] = clk_get(&pdev->dev, clk_id);
>  	if (IS_ERR(tc->clk[1]))
>  		tc->clk[1] = clk;
> -	tc->clk[2] = clk_get(&pdev->dev, "t2_clk");
> +	snprintf(clk_id, sizeof(clk_id), "t%d_clk", clk_offset++);
> +	tc->clk[2] = clk_get(&pdev->dev, clk_id);
>  	if (IS_ERR(tc->clk[2]))
>  		tc->clk[2] = clk;
>  
> -- 
> 1.7.9.5
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From kgene.kim at samsung.com  Wed Apr  3 00:56:07 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Wed, 03 Apr 2013 13:56:07 +0900
Subject: [PATCH 3/3] ARM: EXYNOS5250: Register architected timers
In-Reply-To: <515AC4E3.2070508@suse.de>
References: <1363222742-15220-1-git-send-email-agraf@suse.de>
 <1363222742-15220-4-git-send-email-agraf@suse.de>
 <239701ce2f8f$093a2f40$1bae8dc0$%kim@samsung.com> <515AC4E3.2070508@suse.de>
Message-ID: <24db01ce3027$8d457400$a7d05c00$%kim@samsung.com>

Alexander Graf wrote:
> 
> On 04/02/2013 12:44 PM, Kukjin Kim wrote:
> > Alexander Graf wrote:
> >> When running on an exynos 5250 SoC, we don't initialize the architected
> >> timers. The chip however supports architected timers.
> >>
> > Yes, exynos5250 can support, mct(multi core timer) is used though.
> >
> >> When we don't initialize them, KVM will try to access them and run into
> >> NULL pointer dereferences attempting to do so.
> >>
> > Yes, right.
> >
> >> This patch is really more of a hack than a real fix, but does get me
> >> working with KVM on Arndale.
> >>
> > Hmm, if you think, this is _really_ a hack, you need to add some
> comments
> > about that for clearance, and since the mct.c file has been moved into
> > drivers/clocksource/, this should be re-worked.
> >
> > BTW, I discussed about this with Thomas and Giridhar just now, we
> reached
> > this 3rd patch could be dropped because the correct way is to add a dts
> > node for arch timer which patch 2nd is already doing after 3.9-rc1
> because
> > of CLOCKSOURCE_OF_DECLARE macro.
> >
> > So if you' OK above, let me know so that I can take only 1st and 2nd
> > patches to support KVM on exynos5250.
> 
> I'd say go ahead and take them and I'll verify whether things work on
> your tree :).
> 
OK, I will.

> What's the git repo of your branch?
> 
You can test with my for-next branch but this series can be seen tomorrow
night(KST) in my public tree.

Any problems, please let me know.

Thanks.

- Kukjin



From Wenyou.Yang at atmel.com  Wed Apr  3 01:09:53 2013
From: Wenyou.Yang at atmel.com (Yang, Wenyou)
Date: Wed, 3 Apr 2013 05:09:53 +0000
Subject: [PATCH v7 06/14] spi/spi-atmel: add flag to controller data for
 lock operations
In-Reply-To: <20130401134613.GY18636@opensource.wolfsonmicro.com>
References: <1363678866-3567-1-git-send-email-wenyou.yang@atmel.com>
 <1363679163-3897-1-git-send-email-wenyou.yang@atmel.com>
 <20130401134613.GY18636@opensource.wolfsonmicro.com>
Message-ID: <B256D81BAE5131468A838E5D7A24364150E8CC7B@penmbx01>

Hi, Mark,

> -----Original Message-----
> From: Mark Brown [mailto:broonie at opensource.wolfsonmicro.com]
> Sent: 2013?4?1? 21:46
> To: Yang, Wenyou
> Cc: linux-arm-kernel at lists.infradead.org; grant.likely at secretlab.ca;
> richard.genoud at gmail.com; plagnioj at jcrosoft.com; Ferre, Nicolas; Lin, JM;
> spi-devel-general at lists.sourceforge.net; linux-kernel at vger.kernel.org
> Subject: Re: [PATCH v7 06/14] spi/spi-atmel: add flag to controller data for lock
> operations
> 
> On Tue, Mar 19, 2013 at 03:46:03PM +0800, Wenyou Yang wrote:
> 
> > +static void atmel_spi_lock(struct atmel_spi *as) {
> > +		spin_lock_irqsave(&as->lock, as->flags); }
> 
> Coding style.
I will change it in next version.

> 
> > -	spin_unlock(&as->lock);
> > +	atmel_spi_unlock(as);
> >  	msg->complete(msg->context);
> > -	spin_lock(&as->lock);
> > +	atmel_spi_lock(as);
> 
> This replaces non-irqsave versions with irqsave versions of the lock.
> Is this safe/correct?  If it is I'd have expected some sort of mention of it in the
> commit log.
I will add some commit log.

Best Regards,
Wenyou Yang

From shawn.guo at linaro.org  Wed Apr  3 01:24:25 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Wed, 3 Apr 2013 13:24:25 +0800
Subject: [PATCH] pinctrl: imx5: fix SD2_DATA1 pad AUDMUX_AUD4 configuration
In-Reply-To: <201304030221.18506.marex@denx.de>
References: <1364882642-25574-1-git-send-email-marex@denx.de>
 <20130402114323.GE24039@S2101-09.ap.freescale.net>
 <201304030221.18506.marex@denx.de>
Message-ID: <20130403052423.GO24039@S2101-09.ap.freescale.net>

On Wed, Apr 03, 2013 at 02:21:18AM +0200, Marek Vasut wrote:
> One serving of such patch, coming right up ;-)
> 
> btw. do you want to apply this one for -stable or do we just leave it as is ?
> 
If you do not insist, I would say let's leave it as it is, as we
encourage people to upgrade device tree to adopt the new pinctrl
binding.

Shawn



From shawn.guo at linaro.org  Wed Apr  3 01:27:34 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Wed, 3 Apr 2013 13:27:34 +0800
Subject: [PATCH] pinctrl: imx5: fix SD2_DATA1 pad AUDMUX_AUD4 configuration
In-Reply-To: <1364948425-15372-1-git-send-email-marex@denx.de>
References: <1364948425-15372-1-git-send-email-marex@denx.de>
Message-ID: <20130403052732.GP24039@S2101-09.ap.freescale.net>

On Wed, Apr 03, 2013 at 02:20:25AM +0200, Marek Vasut wrote:
> The IOMUXC_AUDMUX_P4_INPUT_TXCLK_AMX_SELECT_INPUT must be configured as 1
> instead of 0 to have AUD4 muxed on SD2 pins working.
> 
> Signed-off-by: Marek Vasut <marex at denx.de>

Changed the prefix to "ARM: dts: imx53: " and applied the patch.

Shawn



From kishon at ti.com  Wed Apr  3 01:32:39 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Wed, 3 Apr 2013 11:02:39 +0530
Subject: [PATCH v4 1/6] drivers: phy: add generic PHY framework
In-Reply-To: <515AFC06.8000502@wwwdotorg.org>
References: <1364449408-9510-1-git-send-email-kishon@ti.com>
 <1364449408-9510-2-git-send-email-kishon@ti.com>
 <5154658A.3080209@wwwdotorg.org> <515A98B3.7090405@ti.com>
 <515AFC06.8000502@wwwdotorg.org>
Message-ID: <515BBEF7.2030404@ti.com>

On Tuesday 02 April 2013 09:10 PM, Stephen Warren wrote:
> On 04/02/2013 02:37 AM, Kishon Vijay Abraham I wrote:
>> Hi,
>>
>> On Thursday 28 March 2013 09:15 PM, Stephen Warren wrote:
>>> On 03/27/2013 11:43 PM, Kishon Vijay Abraham I wrote:
>>>> The PHY framework provides a set of APIs for the PHY drivers to
>>>> create/destroy a PHY and APIs for the PHY users to obtain a reference
>>>> to the
>>>
>>>> diff --git a/Documentation/devicetree/bindings/phy/phy-bindings.txt
>
>>>> +PHY subsystem refer Documentation/phy.txt
>>>> +
>>>> +PHY device node
>>>> +===============
>>>> +
>>>> +Optional Properties:
>>>> +#phy-cells:    Number of cells in a PHY specifier;  The meaning of all those
>>>> +        cells is defined by the binding for the phy node. However
>>>> +        in-order to return the correct PHY, the PHY susbsystem
>>>> +        requires the first cell always refers to the port.
>>>
>>> Why impose that restriction? Other DT bindings do not.
>>>
>>> This is typically implemented by having each provider driver implement a
>>> .of_xlate() operation, which parses all of the specifier cells, and
>>> returns the ID of the object it represents. This allows bindings to use
>>> whatever arbitrary representation they want.
>>
>> Do you mean something like this
>>
>> struct phy *of_phy_get(struct device *dev, int index)
>> {
>>      struct phy *phy = NULL;
>>      struct phy_bind *phy_map = NULL;
>>      struct of_phandle_args args;
>>      struct device_node *node;
>>
>>      if (!dev->of_node) {
>>          dev_dbg(dev, "device does not have a device node entry\n");
>>          return ERR_PTR(-EINVAL);
>>      }
>>
>>      ret = of_parse_phandle_with_args(dev->of_node, "phys", "#phy-cells",
>>          index, &args);
>>      if (ret) {
>>          dev_dbg(dev, "failed to get phy in %s node\n",
>>              dev->of_node->full_name);
>>          return ERR_PTR(-ENODEV);
>>      }
>
> Looks good.
>
>> //Here we have to get a reference to the phy in order to call of_xlate
>> which seems a little hacky to me. I'm not sure how else can we call the
>> provider driver :-(
>>      phy = of_phy_lookup(dev, node);
>>      if (IS_ERR(phy) || !try_module_get(phy->ops->owner)) {
>>          phy = ERR_PTR(-EPROBE_DEFER);
>>          goto err0;
>>      }
>
> I think the concept of a "PHY provider" and a "PHY instance" are different.
>
> of_xlate should be called on a "PHY provider", and return a "PHY
> instance". Hence, above you want to only look up a "PHY provider", so
> there's no hackiness involved.

Cool. That makes it a lot clearer.

Thanks
Kishon


From thierry.reding at avionic-design.de  Wed Apr  3 01:45:49 2013
From: thierry.reding at avionic-design.de (Thierry Reding)
Date: Wed, 3 Apr 2013 07:45:49 +0200
Subject: [PATCH V5 7/9] ARM: dts: tegra: add non-removable and
 keep-power-in-suspend property for MMC
In-Reply-To: <515B3871.50801@wwwdotorg.org>
References: <1364901613-25080-1-git-send-email-josephl@nvidia.com>
 <1364901613-25080-8-git-send-email-josephl@nvidia.com>
 <515B3871.50801@wwwdotorg.org>
Message-ID: <20130403054549.GA6764@avionic-0098.mockup.avionic-design.de>

On Tue, Apr 02, 2013 at 01:58:41PM -0600, Stephen Warren wrote:
> On 04/02/2013 05:20 AM, Joseph Lo wrote:
> > This patch adds "non-removable" property of MMC host where the eMMC device
> > is for Tegra platform.
> > 
> > And the "keep-power-in-suspend" property was used for the SDIO device that
> > need this to go into suspend mode (e.g. BRCM43xx series).
> 
> >  arch/arm/boot/dts/tegra20-paz00.dts      | 1 +
> >  arch/arm/boot/dts/tegra20-seaboard.dts   | 2 ++
> >  arch/arm/boot/dts/tegra20-ventana.dts    | 2 ++
> >  arch/arm/boot/dts/tegra20-whistler.dts   | 1 +
> >  arch/arm/boot/dts/tegra30-beaver.dts     | 1 +
> >  arch/arm/boot/dts/tegra30-cardhu-a02.dts | 1 +
> >  arch/arm/boot/dts/tegra30-cardhu-a04.dts | 1 +
> >  arch/arm/boot/dts/tegra30-cardhu.dtsi    | 1 +
> 
> I think there are a bunch of other boards that need a similar change,
> right? There are certainly eMMC devices on other boards, and shouldn't
> they be marked with non-removable? In particular, Beaver, Dalmore, and
> Pluto, and likely some/all of the Colibri and Avionic Design boards. I
> think it should be obvious which SDHCI devices need this, since there
> won't be any cd-gpios property and the bus-width will likely be 8.

For Tegra20 Tamonten we don't use eMMC. Ideally we'd be using NAND to
boot from but that doesn't have mainline support. I have a semi-working
patch and will probably spend some more time getting it ready. The MMC
cards are all removable, though I guess since they are the boot device
they still should remain powered in suspend?

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130403/9e82f9be/attachment.sig>

From wenyou.yang at atmel.com  Wed Apr  3 01:56:21 2013
From: wenyou.yang at atmel.com (Wenyou Yang)
Date: Wed, 3 Apr 2013 13:56:21 +0800
Subject: [PATCH v8 0/8] spi/spi-atmel: add dmaengine support for atmel spi
 controller and to test the device tree support
Message-ID: <1364968581-23700-1-git-send-email-wenyou.yang@atmel.com>

Hi Mark, 

The work is based on Nicolas and Richard's work.

It is based on v3.9-rc5 
	+ Joachim Eastwood's spi/atmel: fix speed_hz check in atmel_spi_transfer()
	+ the following four patches of the version 7 series, which you've applied.
		- detect the capabilities of SPI core by reading the VERSION register
		- add support transfer on CS1,2,3, not only on CS0
		- call unmapping on transfers buffers
		- status information passed through controller data

As per your suggestion, do some change for the patches.

Thanks a lot for your work.

Best Regards
Wenyou Yang


Changelog:
v8:
     1 ./ squash the following two patches into dmaengine patch.
     	   - fix spi-atmel driver to adapt to slave_config changes
	   - correct 16 bits transfers with DMA.
     2./ Add some commit log for patches.

v7:
     1./ remove patch: fix probing failure after xfer->speed_hz set.
     2./ remove patch: add pinctrl support for atmel spi.

v6:
     1./ remove: fix master->num_chipselect wrongly set patch which isn't a issue in v3.9-rc1.
     2./ fix probing failure after xfer->speed_hz set.

v5:
     1./ add pinctrl patches.
     2./ detect capabilities by reading spi version register to replace multiple compatiles.
     3./ change the "cs-gpios" property of spi node.
     4./ rebase on v3.8.

v4:
     1./ Take Joe Perches's adivce, rewrite atmel_spi_is_v2(struct atmel_spi *as) 
         and atmel_spi_use_dma(struct atmel_spi *as),
	 and remove atmel_spi_use_pdc(struct atmel_spi *as).
     2./ Rebase on v3.8-rc3.

V3:
     1./ Rebase on v3.8-rc2.
     2./ Remove some Jean-Christophe's patches which has been applied on v3.8-rc2.
     3./ Remove spi property "cs-gpios" from the SoC dtsi files to the board dts files
         to avoid some useless pin conflicts.

v2: 
     1./ Remove the patch :PATCH]mtd: m25p80: change the m25p80_read to reading page to page
	 which purpose to fix the BUG: when run "flashcp /bin/busybox /dev/mtdX" in the at91sam9g25ek
	 with DMA mode, it arises a OOPS. Now fix it in this patch:
	    [PATHC] spi/atmel_spi: add dmaengine support changing to fix the [BUG].
     2./ Remove two patches:
   	    which purpose to read dts property to select SPI IP version and DMA mode
	    Now they will be gat from device tree different compatile.
     3./ Fix DMA: when enable both spi0 AND spi1, the spi0 doesn't work BUG.
     4./ Rebase v3.7-rc8.


Nicolas Ferre (3):
  spi/spi-atmel: add physical base address
  spi/spi-atmel: add flag to controller data for lock operations
  spi/spi-atmel: add dmaengine support

Richard Genoud (4):
  spi/spi-atmel: BUG: fix doesn' support 16 bits transfers using PIO
  ARM: at91: add clocks for spi dt entries
  ARM: dts: add spi nodes for atmel SoC
  ARM: dts: add spi nodes for the atmel boards

Wenyou Yang (1):
  ARM: dts: add pinctrl property for spi node for atmel SoC

 arch/arm/boot/dts/at91sam9260.dtsi          |   40 ++
 arch/arm/boot/dts/at91sam9263.dtsi          |   40 ++
 arch/arm/boot/dts/at91sam9263ek.dts         |   10 +
 arch/arm/boot/dts/at91sam9g20ek_common.dtsi |   10 +
 arch/arm/boot/dts/at91sam9g45.dtsi          |   40 ++
 arch/arm/boot/dts/at91sam9m10g45ek.dts      |   10 +
 arch/arm/boot/dts/at91sam9n12.dtsi          |   40 ++
 arch/arm/boot/dts/at91sam9n12ek.dts         |   10 +
 arch/arm/boot/dts/at91sam9x5.dtsi           |   40 ++
 arch/arm/boot/dts/at91sam9x5ek.dtsi         |   10 +
 arch/arm/mach-at91/at91sam9260.c            |    2 +
 arch/arm/mach-at91/at91sam9g45.c            |    2 +
 arch/arm/mach-at91/at91sam9n12.c            |    2 +
 arch/arm/mach-at91/at91sam9x5.c             |    2 +
 drivers/spi/spi-atmel.c                     |  653 +++++++++++++++++++++++++--
 15 files changed, 876 insertions(+), 35 deletions(-)

-- 
1.7.9.5



From wenyou.yang at atmel.com  Wed Apr  3 01:57:42 2013
From: wenyou.yang at atmel.com (Wenyou Yang)
Date: Wed, 3 Apr 2013 13:57:42 +0800
Subject: [PATCH v8 1/8] spi/spi-atmel: add physical base address
In-Reply-To: <1364968581-23700-1-git-send-email-wenyou.yang@atmel.com>
References: <1364968581-23700-1-git-send-email-wenyou.yang@atmel.com>
Message-ID: <1364968662-23763-1-git-send-email-wenyou.yang@atmel.com>

From: Nicolas Ferre <nicolas.ferre at atmel.com>

Needed for future use with dmaengine enabled driver.

Signed-off-by: Nicolas Ferre <nicolas.ferre at atmel.com>
Cc: spi-devel-general at lists.sourceforge.net
Cc: linux-kernel at vger.kernel.org
[wenyou.yang at atmel.com: submit the patch]
Signed-off-by: Wenyou Yang <wenyou.yang at atmel.com>
---
 drivers/spi/spi-atmel.c |    2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
index 15e8459..38f8c0d 100644
--- a/drivers/spi/spi-atmel.c
+++ b/drivers/spi/spi-atmel.c
@@ -196,6 +196,7 @@ struct atmel_spi_caps {
 struct atmel_spi {
 	spinlock_t		lock;
 
+	phys_addr_t		phybase;
 	void __iomem		*regs;
 	int			irq;
 	struct clk		*clk;
@@ -996,6 +997,7 @@ static int atmel_spi_probe(struct platform_device *pdev)
 	as->regs = ioremap(regs->start, resource_size(regs));
 	if (!as->regs)
 		goto out_free_buffer;
+	as->phybase = regs->start;
 	as->irq = irq;
 	as->clk = clk;
 
-- 
1.7.9.5



From thierry.reding at avionic-design.de  Wed Apr  3 01:59:35 2013
From: thierry.reding at avionic-design.de (Thierry Reding)
Date: Wed, 3 Apr 2013 07:59:35 +0200
Subject: [PATCH V5 9/9] ARM: dts: tegra: add the PM configurations of PMC
In-Reply-To: <515B38F7.5050606@wwwdotorg.org>
References: <1364901613-25080-1-git-send-email-josephl@nvidia.com>
 <1364901613-25080-10-git-send-email-josephl@nvidia.com>
 <515B38F7.5050606@wwwdotorg.org>
Message-ID: <20130403055935.GB6764@avionic-0098.mockup.avionic-design.de>

On Tue, Apr 02, 2013 at 02:00:55PM -0600, Stephen Warren wrote:
> On 04/02/2013 05:20 AM, Joseph Lo wrote:
> > Adding the PM configuration of PMC when the platform support suspend
> > function.
> 
> For this patch, some more boards could be supported, but I think we'll
> have to rely on other people (Lucas, Thierry) to send patches for them,
> since they know the details of the board. It's fine to leave suspend
> disabled on those boards until later.

I'm not sure what would be the best way to get the Tamonten devices out
of suspend again. For Plutux and TEC we have a power button that could
possibly be reused. There's a WAKEUP pin on the Tamonten connector which
goes to GPIO PV2, but the mechanism to trigger it is carrier-board
dependent.

For the Medcom-Wide we don't have a power button, but it could possibly
use the WAKEUP pin if that's connected. It seems like in all designs it
goes to the CPLD, but I need to check with engineering if there's a way
to manipulate it.

So yes, I think for now we can leave suspend disabled on Tamonten and I
can send patches to enable it once I've clarified with engineering.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130403/573faedf/attachment.sig>

From wenyou.yang at atmel.com  Wed Apr  3 01:58:36 2013
From: wenyou.yang at atmel.com (Wenyou Yang)
Date: Wed, 3 Apr 2013 13:58:36 +0800
Subject: [PATCH v8 2/8] spi/spi-atmel: add flag to controller data for lock
 operations
In-Reply-To: <1364968581-23700-1-git-send-email-wenyou.yang@atmel.com>
References: <1364968581-23700-1-git-send-email-wenyou.yang@atmel.com>
Message-ID: <1364968716-23848-1-git-send-email-wenyou.yang@atmel.com>

From: Nicolas Ferre <nicolas.ferre at atmel.com>

Will allow to drop the lock during DMA operations.

Replacing non-irqsave versions with irqsave versions of the lock
to make it correct in both pdc and dmaengine transfer mode

Signed-off-by: Nicolas Ferre <nicolas.ferre at atmel.com>
Cc: spi-devel-general at lists.sourceforge.net
Cc: linux-kernel at vger.kernel.org
[wenyou.yang at atmel.com: submit the patch]
Signed-off-by: Wenyou Yang <wenyou.yang at atmel.com>
---
 drivers/spi/spi-atmel.c |   35 +++++++++++++++++++++--------------
 1 file changed, 21 insertions(+), 14 deletions(-)

diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
index 38f8c0d..2df562f 100644
--- a/drivers/spi/spi-atmel.c
+++ b/drivers/spi/spi-atmel.c
@@ -195,6 +195,7 @@ struct atmel_spi_caps {
  */
 struct atmel_spi {
 	spinlock_t		lock;
+	unsigned long		flags;
 
 	phys_addr_t		phybase;
 	void __iomem		*regs;
@@ -333,6 +334,16 @@ static void cs_deactivate(struct atmel_spi *as, struct spi_device *spi)
 		gpio_set_value(asd->npcs_pin, !active);
 }
 
+static void atmel_spi_lock(struct atmel_spi *as)
+{
+	spin_lock_irqsave(&as->lock, as->flags);
+}
+
+static void atmel_spi_unlock(struct atmel_spi *as)
+{
+	spin_unlock_irqrestore(&as->lock, as->flags);
+}
+
 static inline int atmel_spi_xfer_is_last(struct spi_message *msg,
 					struct spi_transfer *xfer)
 {
@@ -569,9 +580,9 @@ atmel_spi_msg_done(struct spi_master *master, struct atmel_spi *as,
 		"xfer complete: %u bytes transferred\n",
 		msg->actual_length);
 
-	spin_unlock(&as->lock);
+	atmel_spi_unlock(as);
 	msg->complete(msg->context);
-	spin_lock(&as->lock);
+	atmel_spi_lock(as);
 
 	as->current_transfer = NULL;
 	as->next_transfer = NULL;
@@ -594,7 +605,7 @@ atmel_spi_interrupt(int irq, void *dev_id)
 	u32			status, pending, imr;
 	int			ret = IRQ_NONE;
 
-	spin_lock(&as->lock);
+	atmel_spi_lock(as);
 
 	xfer = as->current_transfer;
 	msg = list_entry(as->queue.next, struct spi_message, queue);
@@ -697,7 +708,7 @@ atmel_spi_interrupt(int irq, void *dev_id)
 		}
 	}
 
-	spin_unlock(&as->lock);
+	atmel_spi_unlock(as);
 
 	return ret;
 }
@@ -802,13 +813,11 @@ static int atmel_spi_setup(struct spi_device *spi)
 		spi->controller_state = asd;
 		gpio_direction_output(npcs_pin, !(spi->mode & SPI_CS_HIGH));
 	} else {
-		unsigned long		flags;
-
-		spin_lock_irqsave(&as->lock, flags);
+		atmel_spi_lock(as);
 		if (as->stay == spi)
 			as->stay = NULL;
 		cs_deactivate(as, spi);
-		spin_unlock_irqrestore(&as->lock, flags);
+		atmel_spi_unlock(as);
 	}
 
 	asd->csr = csr;
@@ -827,7 +836,6 @@ static int atmel_spi_transfer(struct spi_device *spi, struct spi_message *msg)
 {
 	struct atmel_spi	*as;
 	struct spi_transfer	*xfer;
-	unsigned long		flags;
 	struct device		*controller = spi->master->dev.parent;
 	u8			bits;
 	struct atmel_spi_device	*asd;
@@ -892,11 +900,11 @@ static int atmel_spi_transfer(struct spi_device *spi, struct spi_message *msg)
 	msg->status = -EINPROGRESS;
 	msg->actual_length = 0;
 
-	spin_lock_irqsave(&as->lock, flags);
+	atmel_spi_lock(as);
 	list_add_tail(&msg->queue, &as->queue);
 	if (!as->current_transfer)
 		atmel_spi_next_message(spi->master);
-	spin_unlock_irqrestore(&as->lock, flags);
+	atmel_spi_unlock(as);
 
 	return 0;
 }
@@ -906,17 +914,16 @@ static void atmel_spi_cleanup(struct spi_device *spi)
 	struct atmel_spi	*as = spi_master_get_devdata(spi->master);
 	struct atmel_spi_device	*asd = spi->controller_state;
 	unsigned		gpio = (unsigned) spi->controller_data;
-	unsigned long		flags;
 
 	if (!asd)
 		return;
 
-	spin_lock_irqsave(&as->lock, flags);
+	atmel_spi_lock(as);
 	if (as->stay == spi) {
 		as->stay = NULL;
 		cs_deactivate(as, spi);
 	}
-	spin_unlock_irqrestore(&as->lock, flags);
+	atmel_spi_unlock(as);
 
 	spi->controller_state = NULL;
 	gpio_free(gpio);
-- 
1.7.9.5



From kishon at ti.com  Wed Apr  3 01:59:53 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Wed, 3 Apr 2013 11:29:53 +0530
Subject: [PATCH v4 0/6] Generic PHY Framework
In-Reply-To: <20130328.143142.2080627792603647441.davem@davemloft.net>
References: <1364449408-9510-1-git-send-email-kishon@ti.com>
 <20130328.143142.2080627792603647441.davem@davemloft.net>
Message-ID: <515BC559.1070602@ti.com>

Hi,

On Friday 29 March 2013 12:01 AM, David Miller wrote:
>
> You really need to CC: netdev at vger.kernel.org rather than me explicitly
> on this patch set.

I was CC'ing whatever get_maintainer shows. I'll make sure to CC 
netdev at vger.kernel.org though there's nothing related to network in this 
patch series (Maybe sometime in the future it'll be used).

Thanks
Kishon


From wenyou.yang at atmel.com  Wed Apr  3 01:59:19 2013
From: wenyou.yang at atmel.com (Wenyou Yang)
Date: Wed, 3 Apr 2013 13:59:19 +0800
Subject: [PATCH v8 3/8] spi/spi-atmel: add dmaengine support
In-Reply-To: <1364968581-23700-1-git-send-email-wenyou.yang@atmel.com>
References: <1364968581-23700-1-git-send-email-wenyou.yang@atmel.com>
Message-ID: <1364968759-24036-1-git-send-email-wenyou.yang@atmel.com>

From: Nicolas Ferre <nicolas.ferre at atmel.com>

Add dmaengine support.

Using "has_dma_support" member of struct is used to select
the transfer mode: dmaengine or pdc.

For the dmaengine transfer mode, it supports both 8 bits and 16 bits transfer.

For the dmaengine transfer mode, if it fails to config dmaengine,
or if the message length is less than 16 bytes, it will use the PIO transfer mode.

Signed-off-by: Nicolas Ferre <nicolas.ferre at atmel.com>
[wenyou.yang at atmel.com: using "has_dma_support" to select dmaengine as the spi xfer mode]
[wenyou.yang at atmel.com: fix DMA: OOPS if buffer > 4096 bytes]
[wenyou.yang at atmel.com: submit the patch]
Signed-off-by: Wenyou Yang <wenyou.yang at atmel.com>
Cc: richard.genoud at gmail.com
Cc: spi-devel-general at lists.sourceforge.ne
Cc: linux-kernel at vger.kernel.org
[richard.genoud at gmail.com: update with dmaengine interface]
[richard.genoud at gmail.com: fix __init/__devinit sections mismatch]
[richard.genoud at gmail.com: adapt to slave_config changes]
[richard.genoud at gmail.com: add support t0 16 bits transfer]
---
This patch is based on the original patch from Nicolas
	- add dmaengine support
and squash the below patches from Richard Genoud <richard.genoud at gmail.com>
	- update with dmaengine interface
	- fix __init/__devinit sections mismatch
	- fix spi-atmel driver to adapt to slave_config changes
	- correct 16 bits transfers with DMA

Hi, Richard,

Could you sign your signature in this patch?

Best Regards,
Wenyou Yang

 drivers/spi/spi-atmel.c |  587 +++++++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 566 insertions(+), 21 deletions(-)

diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
index 2df562f..759d83a 100644
--- a/drivers/spi/spi-atmel.c
+++ b/drivers/spi/spi-atmel.c
@@ -15,11 +15,13 @@
 #include <linux/platform_device.h>
 #include <linux/delay.h>
 #include <linux/dma-mapping.h>
+#include <linux/dmaengine.h>
 #include <linux/err.h>
 #include <linux/interrupt.h>
 #include <linux/spi/spi.h>
 #include <linux/slab.h>
 #include <linux/platform_data/atmel.h>
+#include <linux/platform_data/dma-atmel.h>
 #include <linux/of.h>
 
 #include <linux/io.h>
@@ -182,6 +184,22 @@
 #define spi_writel(port,reg,value) \
 	__raw_writel((value), (port)->regs + SPI_##reg)
 
+/* use PIO for small transfers, avoiding DMA setup/teardown overhead and
+ * cache operations; better heuristics consider wordsize and bitrate.
+ */
+#define DMA_MIN_BYTES	16
+
+struct atmel_spi_dma {
+	struct dma_chan			*chan_rx;
+	struct dma_chan			*chan_tx;
+	struct scatterlist		sgrx;
+	struct scatterlist		sgtx;
+	struct dma_async_tx_descriptor	*data_desc_rx;
+	struct dma_async_tx_descriptor	*data_desc_tx;
+
+	struct at_dma_slave	dma_slave;
+};
+
 struct atmel_spi_caps {
 	bool	is_spi2;
 	bool	has_wdrbt;
@@ -206,16 +224,23 @@ struct atmel_spi {
 
 	u8			stopping;
 	struct list_head	queue;
+	struct tasklet_struct	tasklet;
 	struct spi_transfer	*current_transfer;
 	unsigned long		current_remaining_bytes;
 	struct spi_transfer	*next_transfer;
 	unsigned long		next_remaining_bytes;
 	int			done_status;
 
+	/* scratch buffer */
 	void			*buffer;
 	dma_addr_t		buffer_dma;
 
 	struct atmel_spi_caps	caps;
+
+	bool			use_dma;
+	bool			use_pdc;
+	/* dmaengine data */
+	struct atmel_spi_dma	dma;
 };
 
 /* Controller-specific per-slave state */
@@ -284,6 +309,7 @@ static void cs_activate(struct atmel_spi *as, struct spi_device *spi)
 					| SPI_BIT(MODFDIS)
 					| SPI_BIT(MSTR));
 		}
+
 		mr = spi_readl(as, MR);
 		gpio_set_value(asd->npcs_pin, active);
 	} else {
@@ -344,6 +370,12 @@ static void atmel_spi_unlock(struct atmel_spi *as)
 	spin_unlock_irqrestore(&as->lock, as->flags);
 }
 
+static inline bool atmel_spi_use_dma(struct atmel_spi *as,
+				struct spi_transfer *xfer)
+{
+	return as->use_dma && xfer->len >= DMA_MIN_BYTES;
+}
+
 static inline int atmel_spi_xfer_is_last(struct spi_message *msg,
 					struct spi_transfer *xfer)
 {
@@ -355,6 +387,265 @@ static inline int atmel_spi_xfer_can_be_chained(struct spi_transfer *xfer)
 	return xfer->delay_usecs == 0 && !xfer->cs_change;
 }
 
+static int atmel_spi_dma_slave_config(struct atmel_spi *as,
+				struct dma_slave_config *slave_config,
+				u8 bits_per_word)
+{
+	int err = 0;
+
+	if (bits_per_word > 8) {
+		slave_config->dst_addr_width = DMA_SLAVE_BUSWIDTH_2_BYTES;
+		slave_config->src_addr_width = DMA_SLAVE_BUSWIDTH_2_BYTES;
+	} else {
+		slave_config->dst_addr_width = DMA_SLAVE_BUSWIDTH_1_BYTE;
+		slave_config->src_addr_width = DMA_SLAVE_BUSWIDTH_1_BYTE;
+	}
+
+	slave_config->dst_addr = (dma_addr_t)as->phybase + SPI_TDR;
+	slave_config->src_addr = (dma_addr_t)as->phybase + SPI_RDR;
+	slave_config->src_maxburst = 1;
+	slave_config->dst_maxburst = 1;
+	slave_config->device_fc = false;
+
+	slave_config->direction = DMA_MEM_TO_DEV;
+	if (dmaengine_slave_config(as->dma.chan_tx, slave_config)) {
+		dev_err(&as->pdev->dev,
+			"failed to configure tx dma channel\n");
+		err = -EINVAL;
+	}
+
+	slave_config->direction = DMA_DEV_TO_MEM;
+	if (dmaengine_slave_config(as->dma.chan_rx, slave_config)) {
+		dev_err(&as->pdev->dev,
+			"failed to configure rx dma channel\n");
+		err = -EINVAL;
+	}
+
+	return err;
+}
+
+static bool filter(struct dma_chan *chan, void *slave)
+{
+	struct	at_dma_slave *sl = slave;
+
+	if (sl->dma_dev == chan->device->dev) {
+		chan->private = sl;
+		return true;
+	} else {
+		return false;
+	}
+}
+
+static int atmel_spi_configure_dma(struct atmel_spi *as)
+{
+	struct at_dma_slave *sdata = &as->dma.dma_slave;
+	struct dma_slave_config	slave_config;
+	int err;
+
+	if (sdata && sdata->dma_dev) {
+		dma_cap_mask_t mask;
+
+		/* Try to grab two DMA channels */
+		dma_cap_zero(mask);
+		dma_cap_set(DMA_SLAVE, mask);
+		as->dma.chan_tx = dma_request_channel(mask, filter, sdata);
+		if (as->dma.chan_tx)
+			as->dma.chan_rx =
+				dma_request_channel(mask, filter, sdata);
+	}
+	if (!as->dma.chan_rx || !as->dma.chan_tx) {
+		dev_err(&as->pdev->dev,
+			"DMA channel not available, SPI unable to use DMA\n");
+		err = -EBUSY;
+		goto error;
+	}
+
+	err = atmel_spi_dma_slave_config(as, &slave_config, 8);
+	if (err)
+		goto error;
+
+	dev_info(&as->pdev->dev,
+			"Using %s (tx) and %s (rx) for DMA transfers\n",
+			dma_chan_name(as->dma.chan_tx),
+			dma_chan_name(as->dma.chan_rx));
+	return 0;
+error:
+	if (as->dma.chan_rx)
+		dma_release_channel(as->dma.chan_rx);
+	if (as->dma.chan_tx)
+		dma_release_channel(as->dma.chan_tx);
+	return err;
+}
+
+static void atmel_spi_stop_dma(struct atmel_spi *as)
+{
+	if (as->dma.chan_rx)
+		as->dma.chan_rx->device->device_control(as->dma.chan_rx,
+							DMA_TERMINATE_ALL, 0);
+	if (as->dma.chan_tx)
+		as->dma.chan_tx->device->device_control(as->dma.chan_tx,
+							DMA_TERMINATE_ALL, 0);
+}
+
+static void atmel_spi_release_dma(struct atmel_spi *as)
+{
+	if (as->dma.chan_rx)
+		dma_release_channel(as->dma.chan_rx);
+	if (as->dma.chan_tx)
+		dma_release_channel(as->dma.chan_tx);
+}
+
+/* This function is called by the DMA driver from tasklet context */
+static void dma_callback(void *data)
+{
+	struct spi_master	*master = data;
+	struct atmel_spi	*as = spi_master_get_devdata(master);
+
+	/* trigger SPI tasklet */
+	tasklet_schedule(&as->tasklet);
+}
+
+/*
+ * Next transfer using PIO.
+ * lock is held, spi tasklet is blocked
+ */
+static void atmel_spi_next_xfer_pio(struct spi_master *master,
+				struct spi_transfer *xfer)
+{
+	struct atmel_spi	*as = spi_master_get_devdata(master);
+
+	dev_vdbg(master->dev.parent, "atmel_spi_next_xfer_pio\n");
+
+	as->current_remaining_bytes = xfer->len;
+
+	/* Make sure data is not remaining in RDR */
+	spi_readl(as, RDR);
+	while (spi_readl(as, SR) & SPI_BIT(RDRF)) {
+		spi_readl(as, RDR);
+		cpu_relax();
+	}
+
+	if (xfer->tx_buf)
+		spi_writel(as, TDR, *(u8 *)(xfer->tx_buf));
+	else
+		spi_writel(as, TDR, 0);
+
+	dev_dbg(master->dev.parent,
+		"  start pio xfer %p: len %u tx %p rx %p\n",
+		xfer, xfer->len, xfer->tx_buf, xfer->rx_buf);
+
+	/* Enable relevant interrupts */
+	spi_writel(as, IER, SPI_BIT(RDRF) | SPI_BIT(OVRES));
+}
+
+/*
+ * Submit next transfer for DMA.
+ * lock is held, spi tasklet is blocked
+ */
+static int atmel_spi_next_xfer_dma_submit(struct spi_master *master,
+				struct spi_transfer *xfer,
+				u32 *plen)
+{
+	struct atmel_spi	*as = spi_master_get_devdata(master);
+	struct dma_chan		*rxchan = as->dma.chan_rx;
+	struct dma_chan		*txchan = as->dma.chan_tx;
+	struct dma_async_tx_descriptor *rxdesc;
+	struct dma_async_tx_descriptor *txdesc;
+	struct dma_slave_config	slave_config;
+	dma_cookie_t		cookie;
+	u32	len = *plen;
+
+	dev_vdbg(master->dev.parent, "atmel_spi_next_xfer_dma_submit\n");
+
+	/* Check that the channels are available */
+	if (!rxchan || !txchan)
+		return -ENODEV;
+
+	/* release lock for DMA operations */
+	atmel_spi_unlock(as);
+
+	/* prepare the RX dma transfer */
+	sg_init_table(&as->dma.sgrx, 1);
+	if (xfer->rx_buf) {
+		as->dma.sgrx.dma_address = xfer->rx_dma + xfer->len - *plen;
+	} else {
+		as->dma.sgrx.dma_address = as->buffer_dma;
+		if (len > BUFFER_SIZE)
+			len = BUFFER_SIZE;
+	}
+
+	/* prepare the TX dma transfer */
+	sg_init_table(&as->dma.sgtx, 1);
+	if (xfer->tx_buf) {
+		as->dma.sgtx.dma_address = xfer->tx_dma + xfer->len - *plen;
+	} else {
+		as->dma.sgtx.dma_address = as->buffer_dma;
+		if (len > BUFFER_SIZE)
+			len = BUFFER_SIZE;
+		memset(as->buffer, 0, len);
+	}
+
+	sg_dma_len(&as->dma.sgtx) = len;
+	sg_dma_len(&as->dma.sgrx) = len;
+
+	*plen = len;
+
+	if (atmel_spi_dma_slave_config(as, &slave_config, 8))
+		goto err_exit;
+
+	/* Send both scatterlists */
+	rxdesc = rxchan->device->device_prep_slave_sg(rxchan,
+					&as->dma.sgrx,
+					1,
+					DMA_FROM_DEVICE,
+					DMA_PREP_INTERRUPT | DMA_CTRL_ACK,
+					NULL);
+	if (!rxdesc)
+		goto err_dma;
+
+	txdesc = txchan->device->device_prep_slave_sg(txchan,
+					&as->dma.sgtx,
+					1,
+					DMA_TO_DEVICE,
+					DMA_PREP_INTERRUPT | DMA_CTRL_ACK,
+					NULL);
+	if (!txdesc)
+		goto err_dma;
+
+	dev_dbg(master->dev.parent,
+		"  start dma xfer %p: len %u tx %p/%08x rx %p/%08x\n",
+		xfer, xfer->len, xfer->tx_buf, xfer->tx_dma,
+		xfer->rx_buf, xfer->rx_dma);
+
+	/* Enable relevant interrupts */
+	spi_writel(as, IER, SPI_BIT(OVRES));
+
+	/* Put the callback on the RX transfer only, that should finish last */
+	rxdesc->callback = dma_callback;
+	rxdesc->callback_param = master;
+
+	/* Submit and fire RX and TX with TX last so we're ready to read! */
+	cookie = rxdesc->tx_submit(rxdesc);
+	if (dma_submit_error(cookie))
+		goto err_dma;
+	cookie = txdesc->tx_submit(txdesc);
+	if (dma_submit_error(cookie))
+		goto err_dma;
+	rxchan->device->device_issue_pending(rxchan);
+	txchan->device->device_issue_pending(txchan);
+
+	/* take back lock */
+	atmel_spi_lock(as);
+	return 0;
+
+err_dma:
+	spi_writel(as, IDR, SPI_BIT(OVRES));
+	atmel_spi_stop_dma(as);
+err_exit:
+	atmel_spi_lock(as);
+	return -ENOMEM;
+}
+
 static void atmel_spi_next_xfer_data(struct spi_master *master,
 				struct spi_transfer *xfer,
 				dma_addr_t *tx_dma,
@@ -372,6 +663,7 @@ static void atmel_spi_next_xfer_data(struct spi_master *master,
 		if (len > BUFFER_SIZE)
 			len = BUFFER_SIZE;
 	}
+
 	if (xfer->tx_buf)
 		*tx_dma = xfer->tx_dma + xfer->len - *plen;
 	else {
@@ -387,10 +679,10 @@ static void atmel_spi_next_xfer_data(struct spi_master *master,
 }
 
 /*
- * Submit next transfer for DMA.
+ * Submit next transfer for PDC.
  * lock is held, spi irq is blocked
  */
-static void atmel_spi_next_xfer(struct spi_master *master,
+static void atmel_spi_pdc_next_xfer(struct spi_master *master,
 				struct spi_message *msg)
 {
 	struct atmel_spi	*as = spi_master_get_devdata(master);
@@ -487,6 +779,48 @@ static void atmel_spi_next_xfer(struct spi_master *master,
 	spi_writel(as, PTCR, SPI_BIT(TXTEN) | SPI_BIT(RXTEN));
 }
 
+/*
+ * Choose way to submit next transfer and start it.
+ * lock is held, spi tasklet is blocked
+ */
+static void atmel_spi_dma_next_xfer(struct spi_master *master,
+				struct spi_message *msg)
+{
+	struct atmel_spi	*as = spi_master_get_devdata(master);
+	struct spi_transfer	*xfer;
+	u32	remaining, len;
+
+	remaining = as->current_remaining_bytes;
+	if (remaining) {
+		xfer = as->current_transfer;
+		len = remaining;
+	} else {
+		if (!as->current_transfer)
+			xfer = list_entry(msg->transfers.next,
+				struct spi_transfer, transfer_list);
+		else
+			xfer = list_entry(
+				as->current_transfer->transfer_list.next,
+					struct spi_transfer, transfer_list);
+
+		as->current_transfer = xfer;
+		len = xfer->len;
+	}
+
+	if (atmel_spi_use_dma(as, xfer)) {
+		u32 total = len;
+		if (!atmel_spi_next_xfer_dma_submit(master, xfer, &len)) {
+			as->current_remaining_bytes = total - len;
+			return;
+		} else {
+			dev_err(&msg->spi->dev, "unable to use DMA, fallback to PIO\n");
+		}
+	}
+
+	/* use PIO if error appened using DMA */
+	atmel_spi_next_xfer_pio(master, xfer);
+}
+
 static void atmel_spi_next_message(struct spi_master *master)
 {
 	struct atmel_spi	*as = spi_master_get_devdata(master);
@@ -511,7 +845,10 @@ static void atmel_spi_next_message(struct spi_master *master)
 	} else
 		cs_activate(as, spi);
 
-	atmel_spi_next_xfer(master, msg);
+	if (as->use_pdc)
+		atmel_spi_pdc_next_xfer(master, msg);
+	else
+		atmel_spi_dma_next_xfer(master, msg);
 }
 
 /*
@@ -564,6 +901,11 @@ static void atmel_spi_dma_unmap_xfer(struct spi_master *master,
 				 xfer->len, DMA_FROM_DEVICE);
 }
 
+static void atmel_spi_disable_pdc_transfer(struct atmel_spi *as)
+{
+	spi_writel(as, PTCR, SPI_BIT(RXTDIS) | SPI_BIT(TXTDIS));
+}
+
 static void
 atmel_spi_msg_done(struct spi_master *master, struct atmel_spi *as,
 		struct spi_message *msg, int stay)
@@ -589,14 +931,183 @@ atmel_spi_msg_done(struct spi_master *master, struct atmel_spi *as,
 	as->done_status = 0;
 
 	/* continue if needed */
-	if (list_empty(&as->queue) || as->stopping)
-		spi_writel(as, PTCR, SPI_BIT(RXTDIS) | SPI_BIT(TXTDIS));
-	else
+	if (list_empty(&as->queue) || as->stopping) {
+		if (as->use_pdc)
+			atmel_spi_disable_pdc_transfer(as);
+	} else {
 		atmel_spi_next_message(master);
+	}
+}
+
+/* Called from IRQ
+ * lock is held
+ *
+ * Must update "current_remaining_bytes" to keep track of data
+ * to transfer.
+ */
+static void
+atmel_spi_pump_pio_data(struct atmel_spi *as, struct spi_transfer *xfer)
+{
+	u8		*txp;
+	u8		*rxp;
+	unsigned long	xfer_pos = xfer->len - as->current_remaining_bytes;
+
+	if (xfer->rx_buf) {
+		rxp = ((u8 *)xfer->rx_buf) + xfer_pos;
+		*rxp = spi_readl(as, RDR);
+	} else {
+		spi_readl(as, RDR);
+	}
+
+	as->current_remaining_bytes--;
+
+	if (as->current_remaining_bytes) {
+		if (xfer->tx_buf) {
+			txp = ((u8 *)xfer->tx_buf) + xfer_pos + 1;
+			spi_writel(as, TDR, *txp);
+		} else {
+			spi_writel(as, TDR, 0);
+		}
+	}
+}
+
+/* Tasklet
+ * Called from DMA callback + pio transfer and overrun IRQ.
+ */
+static void atmel_spi_tasklet_func(unsigned long data)
+{
+	struct spi_master	*master = (struct spi_master *)data;
+	struct atmel_spi	*as = spi_master_get_devdata(master);
+	struct spi_message	*msg;
+	struct spi_transfer	*xfer;
+
+	dev_vdbg(master->dev.parent, "atmel_spi_tasklet_func\n");
+
+	atmel_spi_lock(as);
+
+	xfer = as->current_transfer;
+
+	if (xfer == NULL)
+		/* already been there */
+		goto tasklet_out;
+
+	msg = list_entry(as->queue.next, struct spi_message, queue);
+
+	if (as->current_remaining_bytes == 0) {
+		if (as->done_status < 0) {
+			/* error happened (overrun) */
+			if (atmel_spi_use_dma(as, xfer))
+				atmel_spi_stop_dma(as);
+		} else {
+			/* only update length if no error */
+			msg->actual_length += xfer->len;
+		}
+
+		if (atmel_spi_use_dma(as, xfer))
+			if (!msg->is_dma_mapped)
+				atmel_spi_dma_unmap_xfer(master, xfer);
+
+		if (xfer->delay_usecs)
+			udelay(xfer->delay_usecs);
+
+		if (atmel_spi_xfer_is_last(msg, xfer) || as->done_status < 0) {
+			/* report completed (or erroneous) message */
+			atmel_spi_msg_done(master, as, msg, xfer->cs_change);
+		} else {
+			if (xfer->cs_change) {
+				cs_deactivate(as, msg->spi);
+				udelay(1);
+				cs_activate(as, msg->spi);
+			}
+
+			/*
+			 * Not done yet. Submit the next transfer.
+			 *
+			 * FIXME handle protocol options for xfer
+			 */
+			atmel_spi_dma_next_xfer(master, msg);
+		}
+	} else {
+		/*
+		 * Keep going, we still have data to send in
+		 * the current transfer.
+		 */
+		atmel_spi_dma_next_xfer(master, msg);
+	}
+
+tasklet_out:
+	atmel_spi_unlock(as);
+}
+
+/* Interrupt
+ *
+ * No need for locking in this Interrupt handler: done_status is the
+ * only information modified. What we need is the update of this field
+ * before tasklet runs. This is ensured by using barrier.
+ */
+static irqreturn_t
+atmel_spi_pio_interrupt(int irq, void *dev_id)
+{
+	struct spi_master	*master = dev_id;
+	struct atmel_spi	*as = spi_master_get_devdata(master);
+	u32			status, pending, imr;
+	struct spi_transfer	*xfer;
+	int			ret = IRQ_NONE;
+
+	imr = spi_readl(as, IMR);
+	status = spi_readl(as, SR);
+	pending = status & imr;
+
+	if (pending & SPI_BIT(OVRES)) {
+		ret = IRQ_HANDLED;
+		spi_writel(as, IDR, SPI_BIT(OVRES));
+		dev_warn(master->dev.parent, "overrun\n");
+
+		/*
+		 * When we get an overrun, we disregard the current
+		 * transfer. Data will not be copied back from any
+		 * bounce buffer and msg->actual_len will not be
+		 * updated with the last xfer.
+		 *
+		 * We will also not process any remaning transfers in
+		 * the message.
+		 *
+		 * All actions are done in tasklet with done_status indication
+		 */
+		as->done_status = -EIO;
+		smp_wmb();
+
+		/* Clear any overrun happening while cleaning up */
+		spi_readl(as, SR);
+
+		tasklet_schedule(&as->tasklet);
+
+	} else if (pending & SPI_BIT(RDRF)) {
+		atmel_spi_lock(as);
+
+		if (as->current_remaining_bytes) {
+			ret = IRQ_HANDLED;
+			xfer = as->current_transfer;
+			atmel_spi_pump_pio_data(as, xfer);
+			if (!as->current_remaining_bytes) {
+				/* no more data to xfer, kick tasklet */
+				spi_writel(as, IDR, pending);
+				tasklet_schedule(&as->tasklet);
+			}
+		}
+
+		atmel_spi_unlock(as);
+	} else {
+		WARN_ONCE(pending, "IRQ not handled, pending = %x\n", pending);
+		ret = IRQ_HANDLED;
+		spi_writel(as, IDR, pending);
+	}
+
+	return ret;
 }
 
 static irqreturn_t
-atmel_spi_interrupt(int irq, void *dev_id)
+atmel_spi_pdc_interrupt(int irq, void *dev_id)
 {
 	struct spi_master	*master = dev_id;
 	struct atmel_spi	*as = spi_master_get_devdata(master);
@@ -697,14 +1208,14 @@ atmel_spi_interrupt(int irq, void *dev_id)
 				 *
 				 * FIXME handle protocol options for xfer
 				 */
-				atmel_spi_next_xfer(master, msg);
+				atmel_spi_pdc_next_xfer(master, msg);
 			}
 		} else {
 			/*
 			 * Keep going, we still have data to send in
 			 * the current transfer.
 			 */
-			atmel_spi_next_xfer(master, msg);
+			atmel_spi_pdc_next_xfer(master, msg);
 		}
 	}
 
@@ -875,13 +1386,10 @@ static int atmel_spi_transfer(struct spi_device *spi, struct spi_message *msg)
 
 		/*
 		 * DMA map early, for performance (empties dcache ASAP) and
-		 * better fault reporting.  This is a DMA-only driver.
-		 *
-		 * NOTE that if dma_unmap_single() ever starts to do work on
-		 * platforms supported by this driver, we would need to clean
-		 * up mappings for previously-mapped transfers.
+		 * better fault reporting.
 		 */
-		if (!msg->is_dma_mapped) {
+		if ((!msg->is_dma_mapped) && (atmel_spi_use_dma(as, xfer)
+			|| as->use_pdc)) {
 			if (atmel_spi_dma_map_xfer(as, xfer) < 0)
 				return -ENOMEM;
 		}
@@ -1000,6 +1508,7 @@ static int atmel_spi_probe(struct platform_device *pdev)
 
 	spin_lock_init(&as->lock);
 	INIT_LIST_HEAD(&as->queue);
+
 	as->pdev = pdev;
 	as->regs = ioremap(regs->start, resource_size(regs));
 	if (!as->regs)
@@ -1010,8 +1519,28 @@ static int atmel_spi_probe(struct platform_device *pdev)
 
 	atmel_get_caps(as);
 
-	ret = request_irq(irq, atmel_spi_interrupt, 0,
-			dev_name(&pdev->dev), master);
+	as->use_dma = false;
+	as->use_pdc = false;
+	if (as->caps.has_dma_support) {
+		if (atmel_spi_configure_dma(as) == 0)
+			as->use_dma = true;
+	} else {
+		as->use_pdc = true;
+	}
+
+	if (as->caps.has_dma_support && !as->use_dma)
+		dev_info(&pdev->dev, "Atmel SPI Controller using PIO only\n");
+
+	if (as->use_pdc) {
+		ret = request_irq(irq, atmel_spi_pdc_interrupt, 0,
+					dev_name(&pdev->dev), master);
+	} else {
+		tasklet_init(&as->tasklet, atmel_spi_tasklet_func,
+					(unsigned long)master);
+
+		ret = request_irq(irq, atmel_spi_pio_interrupt, 0,
+					dev_name(&pdev->dev), master);
+	}
 	if (ret)
 		goto out_unmap_regs;
 
@@ -1025,7 +1554,9 @@ static int atmel_spi_probe(struct platform_device *pdev)
 	} else {
 		spi_writel(as, MR, SPI_BIT(MSTR) | SPI_BIT(MODFDIS));
 	}
-	spi_writel(as, PTCR, SPI_BIT(RXTDIS) | SPI_BIT(TXTDIS));
+
+	if (as->use_pdc)
+		spi_writel(as, PTCR, SPI_BIT(RXTDIS) | SPI_BIT(TXTDIS));
 	spi_writel(as, CR, SPI_BIT(SPIEN));
 
 	/* go! */
@@ -1034,11 +1565,14 @@ static int atmel_spi_probe(struct platform_device *pdev)
 
 	ret = spi_register_master(master);
 	if (ret)
-		goto out_reset_hw;
+		goto out_free_dma;
 
 	return 0;
 
-out_reset_hw:
+out_free_dma:
+	if (as->use_dma)
+		atmel_spi_release_dma(as);
+
 	spi_writel(as, CR, SPI_BIT(SWRST));
 	spi_writel(as, CR, SPI_BIT(SWRST)); /* AT91SAM9263 Rev B workaround */
 	clk_disable(clk);
@@ -1046,6 +1580,8 @@ out_reset_hw:
 out_unmap_regs:
 	iounmap(as->regs);
 out_free_buffer:
+	if (!as->use_pdc)
+		tasklet_kill(&as->tasklet);
 	dma_free_coherent(&pdev->dev, BUFFER_SIZE, as->buffer,
 			as->buffer_dma);
 out_free:
@@ -1064,6 +1600,11 @@ static int atmel_spi_remove(struct platform_device *pdev)
 	/* reset the hardware and block queue progress */
 	spin_lock_irq(&as->lock);
 	as->stopping = 1;
+	if (as->use_dma) {
+		atmel_spi_stop_dma(as);
+		atmel_spi_release_dma(as);
+	}
+
 	spi_writel(as, CR, SPI_BIT(SWRST));
 	spi_writel(as, CR, SPI_BIT(SWRST)); /* AT91SAM9263 Rev B workaround */
 	spi_readl(as, SR);
@@ -1072,13 +1613,17 @@ static int atmel_spi_remove(struct platform_device *pdev)
 	/* Terminate remaining queued transfers */
 	list_for_each_entry(msg, &as->queue, queue) {
 		list_for_each_entry(xfer, &msg->transfers, transfer_list) {
-			if (!msg->is_dma_mapped)
+			if (!msg->is_dma_mapped
+				&& (atmel_spi_use_dma(as, xfer)
+					|| as->use_pdc))
 				atmel_spi_dma_unmap_xfer(master, xfer);
 		}
 		msg->status = -ESHUTDOWN;
 		msg->complete(msg->context);
 	}
 
+	if (!as->use_pdc)
+		tasklet_kill(&as->tasklet);
 	dma_free_coherent(&pdev->dev, BUFFER_SIZE, as->buffer,
 			as->buffer_dma);
 
-- 
1.7.9.5



From wenyou.yang at atmel.com  Wed Apr  3 02:00:05 2013
From: wenyou.yang at atmel.com (Wenyou Yang)
Date: Wed, 3 Apr 2013 14:00:05 +0800
Subject: [PATCH v8 4/8] spi/spi-atmel: BUG: fix doesn' support 16 bits
 transfers using PIO
In-Reply-To: <1364968581-23700-1-git-send-email-wenyou.yang@atmel.com>
References: <1364968581-23700-1-git-send-email-wenyou.yang@atmel.com>
Message-ID: <1364968805-24090-1-git-send-email-wenyou.yang@atmel.com>

From: Richard Genoud <richard.genoud at gmail.com>

Fix using PIO transfer mode only support 8 bits transfer, doesn't support 16 bits.

Signed-off-by: Richard Genoud <richard.genoud at gmail.com>
Cc: spi-devel-general at lists.sourceforge.net
Cc: linux-kernel at vger.kernel.org
[wenyou.yang at atmel.com: submit the patch]
Signed-off-by: Wenyou Yang <wenyou.yang at atmel.com>
---
 drivers/spi/spi-atmel.c |   47 ++++++++++++++++++++++++++++++++++++++---------
 1 file changed, 38 insertions(+), 9 deletions(-)

diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
index 759d83a..a619779 100644
--- a/drivers/spi/spi-atmel.c
+++ b/drivers/spi/spi-atmel.c
@@ -526,13 +526,17 @@ static void atmel_spi_next_xfer_pio(struct spi_master *master,
 	}
 
 	if (xfer->tx_buf)
-		spi_writel(as, TDR, *(u8 *)(xfer->tx_buf));
+		if (xfer->bits_per_word > 8)
+			spi_writel(as, TDR, *(u16 *)(xfer->tx_buf));
+		else
+			spi_writel(as, TDR, *(u8 *)(xfer->tx_buf));
 	else
 		spi_writel(as, TDR, 0);
 
 	dev_dbg(master->dev.parent,
-		"  start pio xfer %p: len %u tx %p rx %p\n",
-		xfer, xfer->len, xfer->tx_buf, xfer->rx_buf);
+		"  start pio xfer %p: len %u tx %p rx %p bitpw %d\n",
+		xfer, xfer->len, xfer->tx_buf, xfer->rx_buf,
+		xfer->bits_per_word);
 
 	/* Enable relevant interrupts */
 	spi_writel(as, IER, SPI_BIT(RDRF) | SPI_BIT(OVRES));
@@ -950,21 +954,39 @@ atmel_spi_pump_pio_data(struct atmel_spi *as, struct spi_transfer *xfer)
 {
 	u8		*txp;
 	u8		*rxp;
+	u16		*txp16;
+	u16		*rxp16;
 	unsigned long	xfer_pos = xfer->len - as->current_remaining_bytes;
 
 	if (xfer->rx_buf) {
-		rxp = ((u8 *)xfer->rx_buf) + xfer_pos;
-		*rxp = spi_readl(as, RDR);
+		if (xfer->bits_per_word > 8) {
+			rxp16 = (u16 *)(((u8 *)xfer->rx_buf) + xfer_pos);
+			*rxp16 = spi_readl(as, RDR);
+		} else {
+			rxp = ((u8 *)xfer->rx_buf) + xfer_pos;
+			*rxp = spi_readl(as, RDR);
+		}
 	} else {
 		spi_readl(as, RDR);
 	}
-
-	as->current_remaining_bytes--;
+	if (xfer->bits_per_word > 8) {
+		as->current_remaining_bytes -= 2;
+		if (as->current_remaining_bytes < 0)
+			as->current_remaining_bytes = 0;
+	} else {
+		as->current_remaining_bytes--;
+	}
 
 	if (as->current_remaining_bytes) {
 		if (xfer->tx_buf) {
-			txp = ((u8 *)xfer->tx_buf) + xfer_pos + 1;
-			spi_writel(as, TDR, *txp);
+			if (xfer->bits_per_word > 8) {
+				txp16 = (u16 *)(((u8 *)xfer->tx_buf)
+							+ xfer_pos + 2);
+				spi_writel(as, TDR, *txp16);
+			} else {
+				txp = ((u8 *)xfer->tx_buf) + xfer_pos + 1;
+				spi_writel(as, TDR, *txp);
+			}
 		} else {
 			spi_writel(as, TDR, 0);
 		}
@@ -1378,6 +1400,13 @@ static int atmel_spi_transfer(struct spi_device *spi, struct spi_message *msg)
 			}
 		}
 
+		if (xfer->bits_per_word > 8) {
+			if (xfer->len % 2) {
+				dev_dbg(&spi->dev, "buffer len should be 16 bits aligned\n");
+				return -EINVAL;
+			}
+		}
+
 		/* FIXME implement these protocol options!! */
 		if (xfer->speed_hz < spi->max_speed_hz) {
 			dev_dbg(&spi->dev, "can't change speed in transfer\n");
-- 
1.7.9.5



From wenyou.yang at atmel.com  Wed Apr  3 02:01:22 2013
From: wenyou.yang at atmel.com (Wenyou Yang)
Date: Wed, 3 Apr 2013 14:01:22 +0800
Subject: [PATCH v8 5/8] ARM: at91: add clocks for spi dt entries
In-Reply-To: <1364968581-23700-1-git-send-email-wenyou.yang@atmel.com>
References: <1364968581-23700-1-git-send-email-wenyou.yang@atmel.com>
Message-ID: <1364968882-24132-1-git-send-email-wenyou.yang@atmel.com>

From: Richard Genoud <richard.genoud at gmail.com>

Signed-off-by: Richard Genoud <richard.genoud at gmail.com>
[<wenyou.yang at atmel.com: declare the spi clocks for sam9260, at91sam9g45, and at91sam9n12]
[wenyou.yang at atmel.com: submit the patch]
Signed-off-by: Wenyou Yang <wenyou.yang at atmel.com>
Cc: linux at arm.linux.org.uk
Cc: linux at maxim.org.za
Cc: linux-kernel at vger.kernel.org
---
 arch/arm/mach-at91/at91sam9260.c |    2 ++
 arch/arm/mach-at91/at91sam9g45.c |    2 ++
 arch/arm/mach-at91/at91sam9n12.c |    2 ++
 arch/arm/mach-at91/at91sam9x5.c  |    2 ++
 4 files changed, 8 insertions(+)

diff --git a/arch/arm/mach-at91/at91sam9260.c b/arch/arm/mach-at91/at91sam9260.c
index b67cd53..44199bc 100644
--- a/arch/arm/mach-at91/at91sam9260.c
+++ b/arch/arm/mach-at91/at91sam9260.c
@@ -232,6 +232,8 @@ static struct clk_lookup periph_clocks_lookups[] = {
 	CLKDEV_CON_DEV_ID("t2_clk", "fffdc000.timer", &tc5_clk),
 	CLKDEV_CON_DEV_ID("hclk", "500000.ohci", &ohci_clk),
 	CLKDEV_CON_DEV_ID("mci_clk", "fffa8000.mmc", &mmc_clk),
+	CLKDEV_CON_DEV_ID("spi_clk", "fffc8000.spi", &spi0_clk),
+	CLKDEV_CON_DEV_ID("spi_clk", "fffcc000.spi", &spi1_clk),
 	/* fake hclk clock */
 	CLKDEV_CON_DEV_ID("hclk", "at91_ohci", &ohci_clk),
 	CLKDEV_CON_ID("pioA", &pioA_clk),
diff --git a/arch/arm/mach-at91/at91sam9g45.c b/arch/arm/mach-at91/at91sam9g45.c
index d3addee..2ec5efe 100644
--- a/arch/arm/mach-at91/at91sam9g45.c
+++ b/arch/arm/mach-at91/at91sam9g45.c
@@ -262,6 +262,8 @@ static struct clk_lookup periph_clocks_lookups[] = {
 	CLKDEV_CON_DEV_ID("mci_clk", "fffd0000.mmc", &mmc1_clk),
 	CLKDEV_CON_DEV_ID(NULL, "fff84000.i2c", &twi0_clk),
 	CLKDEV_CON_DEV_ID(NULL, "fff88000.i2c", &twi1_clk),
+	CLKDEV_CON_DEV_ID("spi_clk", "fffa4000.spi", &spi0_clk),
+	CLKDEV_CON_DEV_ID("spi_clk", "fffa8000.spi", &spi1_clk),
 	/* fake hclk clock */
 	CLKDEV_CON_DEV_ID("hclk", "at91_ohci", &uhphs_clk),
 	CLKDEV_CON_DEV_ID(NULL, "fffff200.gpio", &pioA_clk),
diff --git a/arch/arm/mach-at91/at91sam9n12.c b/arch/arm/mach-at91/at91sam9n12.c
index 5dfc8fd..ccd0783 100644
--- a/arch/arm/mach-at91/at91sam9n12.c
+++ b/arch/arm/mach-at91/at91sam9n12.c
@@ -172,6 +172,8 @@ static struct clk_lookup periph_clocks_lookups[] = {
 	CLKDEV_CON_DEV_ID("dma_clk", "ffffec00.dma-controller", &dma_clk),
 	CLKDEV_CON_DEV_ID(NULL, "f8010000.i2c", &twi0_clk),
 	CLKDEV_CON_DEV_ID(NULL, "f8014000.i2c", &twi1_clk),
+	CLKDEV_CON_DEV_ID("spi_clk", "f0000000.spi", &spi0_clk),
+	CLKDEV_CON_DEV_ID("spi_clk", "f0004000.spi", &spi1_clk),
 	CLKDEV_CON_DEV_ID(NULL, "fffff400.gpio", &pioAB_clk),
 	CLKDEV_CON_DEV_ID(NULL, "fffff600.gpio", &pioAB_clk),
 	CLKDEV_CON_DEV_ID(NULL, "fffff800.gpio", &pioCD_clk),
diff --git a/arch/arm/mach-at91/at91sam9x5.c b/arch/arm/mach-at91/at91sam9x5.c
index 44a9a62..a200d8a 100644
--- a/arch/arm/mach-at91/at91sam9x5.c
+++ b/arch/arm/mach-at91/at91sam9x5.c
@@ -237,6 +237,8 @@ static struct clk_lookup periph_clocks_lookups[] = {
 	CLKDEV_CON_DEV_ID(NULL, "f8010000.i2c", &twi0_clk),
 	CLKDEV_CON_DEV_ID(NULL, "f8014000.i2c", &twi1_clk),
 	CLKDEV_CON_DEV_ID(NULL, "f8018000.i2c", &twi2_clk),
+	CLKDEV_CON_DEV_ID("spi_clk", "f0000000.spi", &spi0_clk),
+	CLKDEV_CON_DEV_ID("spi_clk", "f0004000.spi", &spi1_clk),
 	CLKDEV_CON_DEV_ID(NULL, "fffff400.gpio", &pioAB_clk),
 	CLKDEV_CON_DEV_ID(NULL, "fffff600.gpio", &pioAB_clk),
 	CLKDEV_CON_DEV_ID(NULL, "fffff800.gpio", &pioCD_clk),
-- 
1.7.9.5



From wenyou.yang at atmel.com  Wed Apr  3 02:02:18 2013
From: wenyou.yang at atmel.com (Wenyou Yang)
Date: Wed, 3 Apr 2013 14:02:18 +0800
Subject: [PATCH v8 6/8] ARM: dts: add spi nodes for atmel SoC
In-Reply-To: <1364968581-23700-1-git-send-email-wenyou.yang@atmel.com>
References: <1364968581-23700-1-git-send-email-wenyou.yang@atmel.com>
Message-ID: <1364968938-24198-1-git-send-email-wenyou.yang@atmel.com>

From: Richard Genoud <richard.genoud at gmail.com>

Signed-off-by: Richard Genoud <richard.genoud at gmail.com>
[wenyou.yang at atmel.com: add spi nodes for sam9260, sam9263, sam9g45 and sam9n12]
[wenyou.yang at atmel.com: remove spi property "cs-gpios" to the board dts files]
[wenyou.yang at atmel.com: submit the patch]
Signed-off-by: Wenyou Yang <wenyou.yang at atmel.com>
Cc: linux at arm.linux.org.uk
Cc: linux-kernel at vger.kernel.org
---
 arch/arm/boot/dts/at91sam9260.dtsi |   18 ++++++++++++++++++
 arch/arm/boot/dts/at91sam9263.dtsi |   18 ++++++++++++++++++
 arch/arm/boot/dts/at91sam9g45.dtsi |   18 ++++++++++++++++++
 arch/arm/boot/dts/at91sam9n12.dtsi |   18 ++++++++++++++++++
 arch/arm/boot/dts/at91sam9x5.dtsi  |   18 ++++++++++++++++++
 5 files changed, 90 insertions(+)

diff --git a/arch/arm/boot/dts/at91sam9260.dtsi b/arch/arm/boot/dts/at91sam9260.dtsi
index cb7bcc5..6e31dc8 100644
--- a/arch/arm/boot/dts/at91sam9260.dtsi
+++ b/arch/arm/boot/dts/at91sam9260.dtsi
@@ -471,6 +471,24 @@
 				status = "disabled";
 			};
 
+			spi0: spi at fffc8000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "atmel,at91rm9200-spi";
+				reg = <0xfffc8000 0x200>;
+				interrupts = <12 4 3>;
+				status = "disabled";
+			};
+
+			spi1: spi at fffcc000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "atmel,at91rm9200-spi";
+				reg = <0xfffcc000 0x200>;
+				interrupts = <13 4 3>;
+				status = "disabled";
+			};
+
 			adc0: adc at fffe0000 {
 				compatible = "atmel,at91sam9260-adc";
 				reg = <0xfffe0000 0x100>;
diff --git a/arch/arm/boot/dts/at91sam9263.dtsi b/arch/arm/boot/dts/at91sam9263.dtsi
index 271d4de..6c6d9ae 100644
--- a/arch/arm/boot/dts/at91sam9263.dtsi
+++ b/arch/arm/boot/dts/at91sam9263.dtsi
@@ -462,6 +462,24 @@
 				reg = <0xfffffd40 0x10>;
 				status = "disabled";
 			};
+
+			spi0: spi at fffa4000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "atmel,at91rm9200-spi";
+				reg = <0xfffa4000 0x200>;
+				interrupts = <14 4 3>;
+				status = "disabled";
+			};
+
+			spi1: spi at fffa8000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "atmel,at91rm9200-spi";
+				reg = <0xfffa8000 0x200>;
+				interrupts = <15 4 3>;
+				status = "disabled";
+			};
 		};
 
 		nand0: nand at 40000000 {
diff --git a/arch/arm/boot/dts/at91sam9g45.dtsi b/arch/arm/boot/dts/at91sam9g45.dtsi
index 6b1d4ca..e085b8a 100644
--- a/arch/arm/boot/dts/at91sam9g45.dtsi
+++ b/arch/arm/boot/dts/at91sam9g45.dtsi
@@ -531,6 +531,24 @@
 				reg = <0xfffffd40 0x10>;
 				status = "disabled";
 			};
+
+			spi0: spi at fffa4000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "atmel,at91rm9200-spi";
+				reg = <0xfffa4000 0x200>;
+				interrupts = <14 4 3>;
+				status = "disabled";
+			};
+
+			spi1: spi at fffa8000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "atmel,at91rm9200-spi";
+				reg = <0xfffa8000 0x200>;
+				interrupts = <15 4 3>;
+				status = "disabled";
+			};
 		};
 
 		nand0: nand at 40000000 {
diff --git a/arch/arm/boot/dts/at91sam9n12.dtsi b/arch/arm/boot/dts/at91sam9n12.dtsi
index 7750f98..f3f87ef3 100644
--- a/arch/arm/boot/dts/at91sam9n12.dtsi
+++ b/arch/arm/boot/dts/at91sam9n12.dtsi
@@ -373,6 +373,24 @@
 				#size-cells = <0>;
 				status = "disabled";
 			};
+
+			spi0: spi at f0000000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "atmel,at91rm9200-spi";
+				reg = <0xf0000000 0x100>;
+				interrupts = <13 4 3>;
+				status = "disabled";
+			};
+
+			spi1: spi at f0004000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "atmel,at91rm9200-spi";
+				reg = <0xf0004000 0x100>;
+				interrupts = <14 4 3>;
+				status = "disabled";
+			};
 		};
 
 		nand0: nand at 40000000 {
diff --git a/arch/arm/boot/dts/at91sam9x5.dtsi b/arch/arm/boot/dts/at91sam9x5.dtsi
index a98c0d5..77ce2e1 100644
--- a/arch/arm/boot/dts/at91sam9x5.dtsi
+++ b/arch/arm/boot/dts/at91sam9x5.dtsi
@@ -529,6 +529,24 @@
 					trigger-value = <0x6>;
 				};
 			};
+
+			spi0: spi at f0000000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "atmel,at91rm9200-spi";
+				reg = <0xf0000000 0x100>;
+				interrupts = <13 4 3>;
+				status = "disabled";
+			};
+
+			spi1: spi at f0004000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "atmel,at91rm9200-spi";
+				reg = <0xf0004000 0x100>;
+				interrupts = <14 4 3>;
+				status = "disabled";
+			};
 		};
 
 		nand0: nand at 40000000 {
-- 
1.7.9.5



From wenyou.yang at atmel.com  Wed Apr  3 02:03:05 2013
From: wenyou.yang at atmel.com (Wenyou Yang)
Date: Wed, 3 Apr 2013 14:03:05 +0800
Subject: [PATCH v8 7/8] ARM: dts: add spi nodes for the atmel boards
In-Reply-To: <1364968581-23700-1-git-send-email-wenyou.yang@atmel.com>
References: <1364968581-23700-1-git-send-email-wenyou.yang@atmel.com>
Message-ID: <1364968986-24236-1-git-send-email-wenyou.yang@atmel.com>

From: Richard Genoud <richard.genoud at gmail.com>

Signed-off-by: Richard Genoud <richard.genoud at gmail.com>
[wenyou.yang at atmel.com: added spi nodes for the sam9263ek, sam9g20ek, sam9m10g45ek and sam9n12ek boards]
[wenyou.yang at atmel.com: submit the patch]
Signed-off-by: Wenyou Yang <wenyou.yang at atmel.com>
Cc: linux at arm.linux.org.uk
Cc: linux-kernel at vger.kernel.org
---
 arch/arm/boot/dts/at91sam9263ek.dts         |   10 ++++++++++
 arch/arm/boot/dts/at91sam9g20ek_common.dtsi |   10 ++++++++++
 arch/arm/boot/dts/at91sam9m10g45ek.dts      |   10 ++++++++++
 arch/arm/boot/dts/at91sam9n12ek.dts         |   10 ++++++++++
 arch/arm/boot/dts/at91sam9x5ek.dtsi         |   10 ++++++++++
 5 files changed, 50 insertions(+)

diff --git a/arch/arm/boot/dts/at91sam9263ek.dts b/arch/arm/boot/dts/at91sam9263ek.dts
index 1eb0872..a14e424 100644
--- a/arch/arm/boot/dts/at91sam9263ek.dts
+++ b/arch/arm/boot/dts/at91sam9263ek.dts
@@ -79,6 +79,16 @@
 					};
 				};
 			};
+
+			spi0: spi at fffa4000 {
+				status = "okay";
+				cs-gpios = <&pioA 5 0>, <0>, <0>, <0>;
+				mtd_dataflash at 0 {
+					compatible = "atmel,at45", "atmel,dataflash";
+					spi-max-frequency = <50000000>;
+					reg = <0>;
+				};
+			};
 		};
 
 		nand0: nand at 40000000 {
diff --git a/arch/arm/boot/dts/at91sam9g20ek_common.dtsi b/arch/arm/boot/dts/at91sam9g20ek_common.dtsi
index da15e83..23d1f46 100644
--- a/arch/arm/boot/dts/at91sam9g20ek_common.dtsi
+++ b/arch/arm/boot/dts/at91sam9g20ek_common.dtsi
@@ -96,6 +96,16 @@
 				status = "okay";
 				pinctrl-0 = <&pinctrl_ssc0_tx>;
 			};
+
+			spi0: spi at fffc8000 {
+				status = "okay";
+				cs-gpios = <0>, <&pioC 11 0>, <0>, <0>;
+				mtd_dataflash at 0 {
+					compatible = "atmel,at45", "atmel,dataflash";
+					spi-max-frequency = <50000000>;
+					reg = <1>;
+				};
+			};
 		};
 
 		nand0: nand at 40000000 {
diff --git a/arch/arm/boot/dts/at91sam9m10g45ek.dts b/arch/arm/boot/dts/at91sam9m10g45ek.dts
index 20c3191..92c52a7 100644
--- a/arch/arm/boot/dts/at91sam9m10g45ek.dts
+++ b/arch/arm/boot/dts/at91sam9m10g45ek.dts
@@ -102,6 +102,16 @@
 					};
 				};
 			};
+
+			spi0: spi at fffa4000{
+				status = "okay";
+				cs-gpios = <&pioB 3 0>, <0>, <0>, <0>;
+				mtd_dataflash at 0 {
+					compatible = "atmel,at45", "atmel,dataflash";
+					spi-max-frequency = <13000000>;
+					reg = <0>;
+				};
+			};
 		};
 
 		nand0: nand at 40000000 {
diff --git a/arch/arm/boot/dts/at91sam9n12ek.dts b/arch/arm/boot/dts/at91sam9n12ek.dts
index d400f8d..34c842b 100644
--- a/arch/arm/boot/dts/at91sam9n12ek.dts
+++ b/arch/arm/boot/dts/at91sam9n12ek.dts
@@ -67,6 +67,16 @@
 					};
 				};
 			};
+
+			spi0: spi at f0000000 {
+				status = "okay";
+				cs-gpios = <&pioA 14 0>, <0>, <0>, <0>;
+				m25p80 at 0 {
+					compatible = "atmel,at25df321a";
+					spi-max-frequency = <50000000>;
+					reg = <0>;
+				};
+			};
 		};
 
 		nand0: nand at 40000000 {
diff --git a/arch/arm/boot/dts/at91sam9x5ek.dtsi b/arch/arm/boot/dts/at91sam9x5ek.dtsi
index 8a7cf1d..09f5e66 100644
--- a/arch/arm/boot/dts/at91sam9x5ek.dtsi
+++ b/arch/arm/boot/dts/at91sam9x5ek.dtsi
@@ -84,6 +84,16 @@
 					};
 				};
 			};
+
+			spi0: spi at f0000000 {
+				status = "okay";
+				cs-gpios = <&pioA 14 0>, <0>, <0>, <0>;
+				m25p80 at 0 {
+					compatible = "atmel,at25df321a";
+					spi-max-frequency = <50000000>;
+					reg = <0>;
+				};
+			};
 		};
 
 		usb0: ohci at 00600000 {
-- 
1.7.9.5



From wenyou.yang at atmel.com  Wed Apr  3 02:03:52 2013
From: wenyou.yang at atmel.com (Wenyou Yang)
Date: Wed, 3 Apr 2013 14:03:52 +0800
Subject: [PATCH v8 8/8] ARM: dts: add pinctrl property for spi node for atmel
 SoC
In-Reply-To: <1364968581-23700-1-git-send-email-wenyou.yang@atmel.com>
References: <1364968581-23700-1-git-send-email-wenyou.yang@atmel.com>
Message-ID: <1364969032-24281-1-git-send-email-wenyou.yang@atmel.com>

Signed-off-by: Wenyou Yang <wenyou.yang at atmel.com>
Cc: linux at arm.linux.org.uk
Cc: linux-kernel at vger.kernel.org
---
 arch/arm/boot/dts/at91sam9260.dtsi |   22 ++++++++++++++++++++++
 arch/arm/boot/dts/at91sam9263.dtsi |   22 ++++++++++++++++++++++
 arch/arm/boot/dts/at91sam9g45.dtsi |   22 ++++++++++++++++++++++
 arch/arm/boot/dts/at91sam9n12.dtsi |   22 ++++++++++++++++++++++
 arch/arm/boot/dts/at91sam9x5.dtsi  |   22 ++++++++++++++++++++++
 5 files changed, 110 insertions(+)

diff --git a/arch/arm/boot/dts/at91sam9260.dtsi b/arch/arm/boot/dts/at91sam9260.dtsi
index 6e31dc8..39253b9 100644
--- a/arch/arm/boot/dts/at91sam9260.dtsi
+++ b/arch/arm/boot/dts/at91sam9260.dtsi
@@ -322,6 +322,24 @@
 					};
 				};
 
+				spi0 {
+					pinctrl_spi0: spi0-0 {
+						atmel,pins =
+							<0 0 0x1 0x0	/* PA0 periph A SPI0_MISO pin */
+							 0 1 0x1 0x0	/* PA1 periph A SPI0_MOSI pin */
+							 0 2 0x1 0x0>;	/* PA2 periph A SPI0_SPCK pin */
+					};
+				};
+
+				spi1 {
+					pinctrl_spi1: spi1-0 {
+						atmel,pins =
+							<1 0 0x1 0x0	/* PB0 periph A SPI1_MISO pin */
+							 1 1 0x1 0x0	/* PB1 periph A SPI1_MOSI pin */
+							 1 2 0x1 0x0>;	/* PB2 periph A SPI1_SPCK pin */
+					};
+				};
+
 				pioA: gpio at fffff400 {
 					compatible = "atmel,at91rm9200-gpio";
 					reg = <0xfffff400 0x200>;
@@ -477,6 +495,8 @@
 				compatible = "atmel,at91rm9200-spi";
 				reg = <0xfffc8000 0x200>;
 				interrupts = <12 4 3>;
+				pinctrl-names = "default";
+				pinctrl-0 = <&pinctrl_spi0>;
 				status = "disabled";
 			};
 
@@ -486,6 +506,8 @@
 				compatible = "atmel,at91rm9200-spi";
 				reg = <0xfffcc000 0x200>;
 				interrupts = <13 4 3>;
+				pinctrl-names = "default";
+				pinctrl-0 = <&pinctrl_spi1>;
 				status = "disabled";
 			};
 
diff --git a/arch/arm/boot/dts/at91sam9263.dtsi b/arch/arm/boot/dts/at91sam9263.dtsi
index 6c6d9ae..94b58ab 100644
--- a/arch/arm/boot/dts/at91sam9263.dtsi
+++ b/arch/arm/boot/dts/at91sam9263.dtsi
@@ -303,6 +303,24 @@
 					};
 				};
 
+				spi0 {
+					pinctrl_spi0: spi0-0 {
+						atmel,pins =
+							<0 0 0x2 0x0	/* PA0 periph B SPI0_MISO pin */
+							 0 1 0x2 0x0	/* PA1 periph B SPI0_MOSI pin */
+							 0 2 0x2 0x0>;	/* PA2 periph B SPI0_SPCK pin */
+					};
+				};
+
+				spi1 {
+					pinctrl_spi1: spi1-0 {
+						atmel,pins =
+							<1 12 0x1 0x0	/* PB12 periph A SPI1_MISO pin */
+							 1 13 0x1 0x0	/* PB13 periph A SPI1_MOSI pin */
+							 1 14 0x1 0x0>;	/* PB14 periph A SPI1_SPCK pin */
+					};
+				};
+
 				pioA: gpio at fffff200 {
 					compatible = "atmel,at91rm9200-gpio";
 					reg = <0xfffff200 0x200>;
@@ -469,6 +487,8 @@
 				compatible = "atmel,at91rm9200-spi";
 				reg = <0xfffa4000 0x200>;
 				interrupts = <14 4 3>;
+				pinctrl-names = "default";
+				pinctrl-0 = <&pinctrl_spi0>;
 				status = "disabled";
 			};
 
@@ -478,6 +498,8 @@
 				compatible = "atmel,at91rm9200-spi";
 				reg = <0xfffa8000 0x200>;
 				interrupts = <15 4 3>;
+				pinctrl-names = "default";
+				pinctrl-0 = <&pinctrl_spi1>;
 				status = "disabled";
 			};
 		};
diff --git a/arch/arm/boot/dts/at91sam9g45.dtsi b/arch/arm/boot/dts/at91sam9g45.dtsi
index e085b8a..cfdf429 100644
--- a/arch/arm/boot/dts/at91sam9g45.dtsi
+++ b/arch/arm/boot/dts/at91sam9g45.dtsi
@@ -322,6 +322,24 @@
 					};
 				};
 
+				spi0 {
+					pinctrl_spi0: spi0-0 {
+						atmel,pins =
+							<1 0 0x1 0x0	/* PB0 periph A SPI0_MISO pin */
+							 1 1 0x1 0x0	/* PB1 periph A SPI0_MOSI pin */
+							 1 2 0x1 0x0>;	/* PB2 periph A SPI0_SPCK pin */
+					};
+				};
+
+				spi1 {
+					pinctrl_spi1: spi1-0 {
+						atmel,pins =
+							<1 14 0x1 0x0	/* PB14 periph A SPI1_MISO pin */
+							 1 15 0x1 0x0	/* PB15 periph A SPI1_MOSI pin */
+							 1 16 0x1 0x0>;	/* PB16 periph A SPI1_SPCK pin */
+					};
+				};
+
 				pioA: gpio at fffff200 {
 					compatible = "atmel,at91rm9200-gpio";
 					reg = <0xfffff200 0x200>;
@@ -538,6 +556,8 @@
 				compatible = "atmel,at91rm9200-spi";
 				reg = <0xfffa4000 0x200>;
 				interrupts = <14 4 3>;
+				pinctrl-names = "default";
+				pinctrl-0 = <&pinctrl_spi0>;
 				status = "disabled";
 			};
 
@@ -547,6 +567,8 @@
 				compatible = "atmel,at91rm9200-spi";
 				reg = <0xfffa8000 0x200>;
 				interrupts = <15 4 3>;
+				pinctrl-names = "default";
+				pinctrl-0 = <&pinctrl_spi1>;
 				status = "disabled";
 			};
 		};
diff --git a/arch/arm/boot/dts/at91sam9n12.dtsi b/arch/arm/boot/dts/at91sam9n12.dtsi
index f3f87ef3..b2961f1 100644
--- a/arch/arm/boot/dts/at91sam9n12.dtsi
+++ b/arch/arm/boot/dts/at91sam9n12.dtsi
@@ -261,6 +261,24 @@
 					};
 				};
 
+				spi0 {
+					pinctrl_spi0: spi0-0 {
+						atmel,pins =
+							<0 11 0x1 0x0	/* PA11 periph A SPI0_MISO pin */
+							 0 12 0x1 0x0	/* PA12 periph A SPI0_MOSI pin */
+							 0 13 0x1 0x0>;	/* PA13 periph A SPI0_SPCK pin */
+					};
+				};
+
+				spi1 {
+					pinctrl_spi1: spi1-0 {
+						atmel,pins =
+							<0 21 0x2 0x0	/* PA21 periph B SPI1_MISO pin */
+							 0 22 0x2 0x0	/* PA22 periph B SPI1_MOSI pin */
+							 0 23 0x2 0x0>;	/* PA23 periph B SPI1_SPCK pin */
+					};
+				};
+
 				pioA: gpio at fffff400 {
 					compatible = "atmel,at91sam9x5-gpio", "atmel,at91rm9200-gpio";
 					reg = <0xfffff400 0x200>;
@@ -380,6 +398,8 @@
 				compatible = "atmel,at91rm9200-spi";
 				reg = <0xf0000000 0x100>;
 				interrupts = <13 4 3>;
+				pinctrl-names = "default";
+				pinctrl-0 = <&pinctrl_spi0>;
 				status = "disabled";
 			};
 
@@ -389,6 +409,8 @@
 				compatible = "atmel,at91rm9200-spi";
 				reg = <0xf0004000 0x100>;
 				interrupts = <14 4 3>;
+				pinctrl-names = "default";
+				pinctrl-0 = <&pinctrl_spi1>;
 				status = "disabled";
 			};
 		};
diff --git a/arch/arm/boot/dts/at91sam9x5.dtsi b/arch/arm/boot/dts/at91sam9x5.dtsi
index 77ce2e1..347b438 100644
--- a/arch/arm/boot/dts/at91sam9x5.dtsi
+++ b/arch/arm/boot/dts/at91sam9x5.dtsi
@@ -343,6 +343,24 @@
 					};
 				};
 
+				spi0 {
+					pinctrl_spi0: spi0-0 {
+						atmel,pins =
+							<0 11 0x1 0x0	/* PA11 periph A SPI0_MISO pin */
+							 0 12 0x1 0x0	/* PA12 periph A SPI0_MOSI pin */
+							 0 13 0x1 0x0>;	/* PA13 periph A SPI0_SPCK pin */
+					};
+				};
+
+				spi1 {
+					pinctrl_spi1: spi1-0 {
+						atmel,pins =
+							<0 21 0x2 0x0	/* PA21 periph B SPI1_MISO pin */
+							 0 22 0x2 0x0	/* PA22 periph B SPI1_MOSI pin */
+							 0 23 0x2 0x0>;	/* PA23 periph B SPI1_SPCK pin */
+					};
+				};
+
 				pioA: gpio at fffff400 {
 					compatible = "atmel,at91sam9x5-gpio", "atmel,at91rm9200-gpio";
 					reg = <0xfffff400 0x200>;
@@ -536,6 +554,8 @@
 				compatible = "atmel,at91rm9200-spi";
 				reg = <0xf0000000 0x100>;
 				interrupts = <13 4 3>;
+				pinctrl-names = "default";
+				pinctrl-0 = <&pinctrl_spi0>;
 				status = "disabled";
 			};
 
@@ -545,6 +565,8 @@
 				compatible = "atmel,at91rm9200-spi";
 				reg = <0xf0004000 0x100>;
 				interrupts = <14 4 3>;
+				pinctrl-names = "default";
+				pinctrl-0 = <&pinctrl_spi1>;
 				status = "disabled";
 			};
 		};
-- 
1.7.9.5



From tpiepho at gmail.com  Wed Apr  3 02:08:40 2013
From: tpiepho at gmail.com (Trent Piepho)
Date: Tue, 2 Apr 2013 23:08:40 -0700
Subject: [PATCH V2 08/12] spi/mxs: Fix race in setup method
In-Reply-To: <201304030427.41297.marex@denx.de>
References: <1364905195-24286-1-git-send-email-tpiepho@gmail.com>
 <201304030131.37782.marex@denx.de>
 <CA+7tXigasUbSRD6hQH66m6XsDkzS9ubLSB24f4akB3pv9xrT=A@mail.gmail.com>
 <201304030427.41297.marex@denx.de>
Message-ID: <CA+7tXih2r6YFE80y7z7Nj7c0Ytvh+v56-SrbS+VQ7kCW3KBRXA@mail.gmail.com>

On Apr 2, 2013 7:27 PM, "Marek Vasut" <marex at denx.de> wrote:
>
> > The only useful thing mxs_spi_setup_transfer() (which
> > is no longer called) did in this instance was make that check.
> >
> > > btw. I was under the impression the MXS SSP block can handle other
> > > word-widths than 8 bit, no ?
> >
> > In theory it can,
>
> In practice too ;-)
>
> > however the driver only supports 8-bits and will
> > reject anything else.
>
> Then please at least add a comment about this.

What does that have to do with this patch?  There was no comment about
it before.  You're insisting that changes be broken up to the extent
that changing one line of code takes multiple patches!  Now you want a
comment about existing driver behavior added to patch that doesn't
change that behavior?

Documenting the driver behavior would seem to be a job for the driver
maintainer.  If doing this is something I need to do, then maybe I
should maintain it?


From swarren at wwwdotorg.org  Wed Apr  3 02:17:10 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Wed,  3 Apr 2013 00:17:10 -0600
Subject: [PATCH] video: implement a dumb framebuffer driver
Message-ID: <1364969830-6481-1-git-send-email-swarren@wwwdotorg.org>

A dumb frame-buffer describes a raw memory region that may be rendered
to, with the assumption that the display hardware has already been set
up to scan out from that buffer.

This is useful in cases where a bootloader exists and has set up the
display hardware, but a Linux driver doesn't yet exist for the display
hardware.

Signed-off-by: Stephen Warren <swarren at wwwdotorg.org>
---
Should this be merged through akpm's tree (I think many fb drivers are
these days), or if not, I could take it through the bcm2835 tree.

I ended up going with a separate FB driver:
* DRM/KMS look much more complex, and don't provide any benefit that I can
  tell for this simple driver.
* Creating a separate driver rather than adjusting offb.c to work allows a
  new clean binding to be defined, and doesn't require removing or ifdefing
  PPC-isms in offb.c.

 .../devicetree/bindings/video/dumb-framebuffer.txt |   25 +++
 drivers/video/Kconfig                              |   17 ++
 drivers/video/Makefile                             |    1 +
 drivers/video/dumbfb.c                             |  234 ++++++++++++++++++++
 4 files changed, 277 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/video/dumb-framebuffer.txt
 create mode 100644 drivers/video/dumbfb.c

diff --git a/Documentation/devicetree/bindings/video/dumb-framebuffer.txt b/Documentation/devicetree/bindings/video/dumb-framebuffer.txt
new file mode 100644
index 0000000..ba6676b
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/dumb-framebuffer.txt
@@ -0,0 +1,25 @@
+Dumb Framebuffer
+
+A dumb frame-buffer describes a raw memory region that may be rendered to,
+with the assumption that the display hardware has already been set up to scan
+out from that buffer.
+
+Required properties:
+- compatible: "dumb-framebuffer"
+- reg: Should contain the location and size of the framebuffer memory.
+- width: The width of the framebuffer in pixels.
+- height: The height of the framebuffer in pixels.
+- stride: The number of bytes in each line of the framebuffer.
+- format: The format of the framebuffer surface. Valid values are:
+  r5g6b5: A 16bpp format.
+
+Example:
+
+	framebuffer {
+		compatible = "dumb-framebuffer";
+		reg = <0x1d385000 (1600 * 1200 * 2)>;
+		width = <1600>;
+		height = <1200>;
+		stride = <(1600 * 2)>;
+		format = "r5g6b5";
+	};
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 4c1546f..0ebc143 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -2451,6 +2451,23 @@ config FB_PUV3_UNIGFX
 	  Choose this option if you want to use the Unigfx device as a
 	  framebuffer device. Without the support of PCI & AGP.
 
+config FB_DUMB
+	bool "Dumb framebuffer support"
+	depends on (FB = y) && OF
+	select FB_CFB_FILLRECT
+	select FB_CFB_COPYAREA
+	select FB_CFB_IMAGEBLIT
+	help
+	  Say Y if you want support for a dumb frame-buffer.
+
+	  This driver assumes that the display hardware has been initialized
+	  before the kernel boots, and the kernel will simply render to the
+	  pre-allocated frame buffer surface.
+
+	  Configuration re: surface address, size, and format must be provided
+	  through device tree, or potentially plain old platform data in the
+	  future.
+
 source "drivers/video/omap/Kconfig"
 source "drivers/video/omap2/Kconfig"
 source "drivers/video/exynos/Kconfig"
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 9df3873..c8facd4 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -165,6 +165,7 @@ obj-$(CONFIG_FB_MX3)		  += mx3fb.o
 obj-$(CONFIG_FB_DA8XX)		  += da8xx-fb.o
 obj-$(CONFIG_FB_MXS)		  += mxsfb.o
 obj-$(CONFIG_FB_SSD1307)	  += ssd1307fb.o
+obj-$(CONFIG_FB_DUMB)             += dumbfb.o
 
 # the test framebuffer is last
 obj-$(CONFIG_FB_VIRTUAL)          += vfb.o
diff --git a/drivers/video/dumbfb.c b/drivers/video/dumbfb.c
new file mode 100644
index 0000000..96afffb
--- /dev/null
+++ b/drivers/video/dumbfb.c
@@ -0,0 +1,234 @@
+/*
+ * Simplest possible dumb frame-buffer driver, as a platform device
+ *
+ * Copyright (c) 2013, Stephen Warren
+ *
+ * Based on q40fb.c, which was:
+ * Copyright (C) 2001 Richard Zidlicky <rz at linux-m68k.org>
+ *
+ * Also based on offb.c, which was:
+ * Copyright (C) 1997 Geert Uytterhoeven
+ * Copyright (C) 1996 Paul Mackerras
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ */
+
+#include <linux/errno.h>
+#include <linux/fb.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+
+static struct fb_fix_screeninfo dumbfb_fix = {
+	.id		= "dumb",
+	.type		= FB_TYPE_PACKED_PIXELS,
+	.visual		= FB_VISUAL_TRUECOLOR,
+	.accel		= FB_ACCEL_NONE,
+};
+
+static struct fb_var_screeninfo dumbfb_var = {
+	.height		= -1,
+	.width		= -1,
+	.activate	= FB_ACTIVATE_NOW,
+	.vmode		= FB_VMODE_NONINTERLACED,
+};
+
+static int dumbfb_setcolreg(u_int regno, u_int red, u_int green, u_int blue,
+			    u_int transp, struct fb_info *info)
+{
+	u32 *pal = info->pseudo_palette;
+	u32 cr = red >> (16 - info->var.red.length);
+	u32 cg = green >> (16 - info->var.green.length);
+	u32 cb = blue >> (16 - info->var.blue.length);
+	u32 value;
+
+	if (regno >= 16)
+		return -EINVAL;
+
+	value = (cr << info->var.red.offset) |
+		(cg << info->var.green.offset) |
+		(cb << info->var.blue.offset);
+	if (info->var.transp.length > 0) {
+		u32 mask = (1 << info->var.transp.length) - 1;
+		mask <<= info->var.transp.offset;
+		value |= mask;
+	}
+	pal[regno] = value;
+
+	return 0;
+}
+
+static struct fb_ops dumbfb_ops = {
+	.owner		= THIS_MODULE,
+	.fb_setcolreg	= dumbfb_setcolreg,
+	.fb_fillrect	= cfb_fillrect,
+	.fb_copyarea	= cfb_copyarea,
+	.fb_imageblit	= cfb_imageblit,
+};
+
+struct dumbfb_format {
+	const char *name;
+	u32 bits_per_pixel;
+	struct fb_bitfield red;
+	struct fb_bitfield green;
+	struct fb_bitfield blue;
+	struct fb_bitfield transp;
+};
+
+struct dumbfb_format dumbfb_formats[] = {
+	{ "r5g6b5", 16, {11, 5}, {5, 6}, {0, 5}, {0, 0} },
+};
+
+struct dumbfb_params {
+	u32 width;
+	u32 height;
+	u32 stride;
+	struct dumbfb_format *format;
+};
+
+static int dumbfb_parse_dt(struct platform_device *pdev,
+			   struct dumbfb_params *params)
+{
+	struct device_node *np = pdev->dev.of_node;
+	int ret;
+	const char *format;
+	int i;
+
+	ret = of_property_read_u32(np, "width", &params->width);
+	if (ret) {
+		dev_err(&pdev->dev, "Can't parse width property\n");
+		return ret;
+	}
+
+	ret = of_property_read_u32(np, "height", &params->height);
+	if (ret) {
+		dev_err(&pdev->dev, "Can't parse height property\n");
+		return ret;
+	}
+
+	ret = of_property_read_u32(np, "stride", &params->stride);
+	if (ret) {
+		dev_err(&pdev->dev, "Can't parse stride property\n");
+		return ret;
+	}
+
+	ret = of_property_read_string(np, "format", &format);
+	if (ret) {
+		dev_err(&pdev->dev, "Can't parse format property\n");
+		return ret;
+	}
+	params->format = NULL;
+	for (i = 0; i < ARRAY_SIZE(dumbfb_formats); i++) {
+		if (strcmp(format, dumbfb_formats[i].name))
+			continue;
+		params->format = &dumbfb_formats[i];
+		break;
+	}
+	if (!params->format) {
+		dev_err(&pdev->dev, "Invalid format value\n");
+		return -EINVAL;
+	}
+
+	return 0;
+}
+
+static int dumbfb_probe(struct platform_device *pdev)
+{
+	int ret;
+	struct dumbfb_params params;
+	struct fb_info *info;
+	struct resource *mem;
+
+	if (fb_get_options("dumbfb", NULL))
+		return -ENODEV;
+
+	ret = dumbfb_parse_dt(pdev, &params);
+	if (ret)
+		return ret;
+
+	mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	if (!mem) {
+		dev_err(&pdev->dev, "No memory resource\n");
+		return -EINVAL;
+	}
+
+	info = framebuffer_alloc(sizeof(u32) * 16, &pdev->dev);
+	if (!info)
+		return -ENOMEM;
+	platform_set_drvdata(pdev, info);
+
+	info->fix = dumbfb_fix;
+	info->fix.smem_start = mem->start;
+	info->fix.smem_len = resource_size(mem);
+	info->fix.line_length = params.stride;
+
+	info->var = dumbfb_var;
+	info->var.xres = params.width;
+	info->var.yres = params.height;
+	info->var.xres_virtual = params.width;
+	info->var.yres_virtual = params.height;
+	info->var.bits_per_pixel = params.format->bits_per_pixel;
+	info->var.red = params.format->red;
+	info->var.green = params.format->green;
+	info->var.blue = params.format->blue;
+	info->var.transp = params.format->transp;
+
+	info->fbops = &dumbfb_ops;
+	info->flags = FBINFO_DEFAULT;
+	info->screen_base = devm_ioremap(&pdev->dev, info->fix.smem_start,
+					 info->fix.smem_len);
+	if (!info->screen_base) {
+		framebuffer_release(info);
+		return -ENODEV;
+	}
+	info->pseudo_palette = (void *)(info + 1);
+
+	ret = register_framebuffer(info);
+	if (ret < 0) {
+		dev_err(&pdev->dev, "Unable to register dumbfb: %d\n", ret);
+		framebuffer_release(info);
+		return ret;
+	}
+
+	dev_info(&pdev->dev, "fb%d: dumbfb registered!\n", info->node);
+
+	return 0;
+}
+
+static int dumbfb_remove(struct platform_device *pdev)
+{
+	struct fb_info *info = platform_get_drvdata(pdev);
+
+	unregister_framebuffer(info);
+	framebuffer_release(info);
+
+	return 0;
+}
+
+static const struct of_device_id dumbfb_of_match[] = {
+	{ .compatible = "dumb-framebuffer", },
+	{ },
+};
+MODULE_DEVICE_TABLE(of, dumbfb_of_match);
+
+static struct platform_driver dumbfb_driver = {
+	.driver = {
+		.name = "dumb-framebuffer",
+		.owner = THIS_MODULE,
+		.of_match_table = dumbfb_of_match,
+	},
+	.probe = dumbfb_probe,
+	.remove = dumbfb_remove,
+};
+module_platform_driver(dumbfb_driver);
+
+MODULE_AUTHOR("Stephen Warren <swarren at wwwdotorg.org>");
+MODULE_DESCRIPTION("Dumb framebuffer driver");
+MODULE_LICENSE("GPL v2");
-- 
1.7.10.4



From swarren at wwwdotorg.org  Wed Apr  3 02:18:50 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Wed,  3 Apr 2013 00:18:50 -0600
Subject: [PATCH 1/2] ARM: bcm2835: add dumb framebuffer to device tree
Message-ID: <1364969931-6574-1-git-send-email-swarren@wwwdotorg.org>

Place a template dumb-framebuffer device into the RPi device tree. The
bootloader is expected to fill in all the parameters at boot time.
Hence, disable the device by default, so if the bootloader doesn't do
this, the device isn't activated with invalid parameters.

Signed-off-by: Stephen Warren <swarren at wwwdotorg.org>
---
 arch/arm/boot/dts/bcm2835-rpi-b.dts |   11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/boot/dts/bcm2835-rpi-b.dts b/arch/arm/boot/dts/bcm2835-rpi-b.dts
index 71ea7f9..26106aa 100644
--- a/arch/arm/boot/dts/bcm2835-rpi-b.dts
+++ b/arch/arm/boot/dts/bcm2835-rpi-b.dts
@@ -8,6 +8,17 @@
 	memory {
 		reg = <0 0x10000000>;
 	};
+
+	framebuffer {
+		compatible = "dumb-framebuffer";
+		status = "disabled";
+		/* The bootloader is expected to fill these in */
+		reg = <0 0>;
+		width = <0>;
+		height = <0>;
+		stride = <0>;
+		format = "";
+	};
 };
 
 &gpio {
-- 
1.7.10.4



From swarren at wwwdotorg.org  Wed Apr  3 02:18:51 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Wed,  3 Apr 2013 00:18:51 -0600
Subject: [PATCH 2/2] ARM: bcm235: defconfig updates for dumb framebuffer
In-Reply-To: <1364969931-6574-1-git-send-email-swarren@wwwdotorg.org>
References: <1364969931-6574-1-git-send-email-swarren@wwwdotorg.org>
Message-ID: <1364969931-6574-2-git-send-email-swarren@wwwdotorg.org>

Enable the dumb framebuffer driver, fbconsole, and VT support.

Signed-off-by: Stephen Warren <swarren at wwwdotorg.org>
---
 arch/arm/configs/bcm2835_defconfig |    6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/arm/configs/bcm2835_defconfig b/arch/arm/configs/bcm2835_defconfig
index 1fa601e..0b2b1ac 100644
--- a/arch/arm/configs/bcm2835_defconfig
+++ b/arch/arm/configs/bcm2835_defconfig
@@ -57,7 +57,6 @@ CONFIG_ENC28J60_WRITEVERIFY=y
 # CONFIG_INPUT_KEYBOARD is not set
 # CONFIG_INPUT_MOUSE is not set
 # CONFIG_SERIO is not set
-# CONFIG_VT is not set
 # CONFIG_LEGACY_PTYS is not set
 # CONFIG_DEVKMEM is not set
 CONFIG_SERIAL_AMBA_PL011=y
@@ -72,6 +71,11 @@ CONFIG_SPI_DEBUG=y
 CONFIG_SPI_BCM2835=y
 CONFIG_GPIO_SYSFS=y
 # CONFIG_HWMON is not set
+CONFIG_FB=y
+CONFIG_FB_DUMB=y
+CONFIG_FRAMEBUFFER_CONSOLE=y
+CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y
+CONFIG_LOGO=y
 CONFIG_USB=y
 CONFIG_USB_DEBUG=y
 CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
-- 
1.7.10.4



From linux at prisktech.co.nz  Wed Apr  3 02:24:47 2013
From: linux at prisktech.co.nz (Tony Prisk)
Date: Wed,  3 Apr 2013 19:24:47 +1300
Subject: [PATCHv5 3/7] arm: vt8500: Increase available GPIOs on arch-vt8500
In-Reply-To: <1364970291-17721-1-git-send-email-linux@prisktech.co.nz>
References: <1364970291-17721-1-git-send-email-linux@prisktech.co.nz>
Message-ID: <1364970291-17721-4-git-send-email-linux@prisktech.co.nz>

With the inclusion of the pin control driver, more GPIO pins have been
identified on the arch-vt8500 SoCs requiring an increase in the available
GPIOs.

Signed-off-by: Tony Prisk <linux at prisktech.co.nz>
---
 arch/arm/Kconfig |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 13b7394..244c618 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1661,7 +1661,8 @@ config ARCH_NR_GPIO
 	default 1024 if ARCH_SHMOBILE || ARCH_TEGRA
 	default 512 if SOC_OMAP5
 	default 355 if ARCH_U8500
-	default 288 if ARCH_VT8500 || ARCH_SUNXI
+	default 352 if ARCH_VT8500
+	default 288 if ARCH_SUNXI
 	default 264 if MACH_H4700
 	default 0
 	help
-- 
1.7.9.5



From linux at prisktech.co.nz  Wed Apr  3 02:24:45 2013
From: linux at prisktech.co.nz (Tony Prisk)
Date: Wed,  3 Apr 2013 19:24:45 +1300
Subject: [PATCHv5 1/7] of: Add support for reading a u32 from a multi-value
 property.
In-Reply-To: <1364970291-17721-1-git-send-email-linux@prisktech.co.nz>
References: <1364970291-17721-1-git-send-email-linux@prisktech.co.nz>
Message-ID: <1364970291-17721-2-git-send-email-linux@prisktech.co.nz>

This patch adds an of_property_read_u32_index() function to allow
reading a single indexed u32 value from a property containing multiple
u32 values.

Signed-off-by: Tony Prisk <linux at prisktech.co.nz>
Reviewed-by: Stephen Warren <swarren at nvidia.com>
---
 drivers/of/base.c  |   33 +++++++++++++++++++++++++++++++++
 include/linux/of.h |    9 +++++++++
 2 files changed, 42 insertions(+)

diff --git a/drivers/of/base.c b/drivers/of/base.c
index 321d3ef..f6c89ed 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -746,6 +746,39 @@ struct device_node *of_find_node_by_phandle(phandle handle)
 EXPORT_SYMBOL(of_find_node_by_phandle);
 
 /**
+ * of_property_read_u32_index - Find and read a u32 from a multi-value property.
+ *
+ * @np:		device node from which the property value is to be read.
+ * @propname:	name of the property to be searched.
+ * @index:	index of the u32 in the list of values
+ * @out_value:	pointer to return value, modified only if no error.
+ *
+ * Search for a property in a device node and read nth 32-bit value from
+ * it. Returns 0 on success, -EINVAL if the property does not exist,
+ * -ENODATA if property does not have a value, and -EOVERFLOW if the
+ * property data isn't large enough.
+ *
+ * The out_value is modified only if a valid u32 value can be decoded.
+ */
+int of_property_read_u32_index(const struct device_node *np,
+				       const char *propname,
+				       u32 index, u32 *out_value)
+{
+	struct property *prop = of_find_property(np, propname, NULL);
+
+	if (!prop)
+		return -EINVAL;
+	if (!prop->value)
+		return -ENODATA;
+	if (((index + 1) * sizeof(*out_value)) > prop->length)
+		return -EOVERFLOW;
+
+	*out_value = be32_to_cpup(((__be32 *)prop->value) + index);
+	return 0;
+}
+EXPORT_SYMBOL_GPL(of_property_read_u32_index);
+
+/**
  * of_property_read_u8_array - Find and read an array of u8 from a property.
  *
  * @np:		device node from which the property value is to be read.
diff --git a/include/linux/of.h b/include/linux/of.h
index a0f1292..c0747a4 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -235,6 +235,9 @@ extern struct device_node *of_find_node_with_property(
 extern struct property *of_find_property(const struct device_node *np,
 					 const char *name,
 					 int *lenp);
+extern int of_property_read_u32_index(const struct device_node *np,
+				       const char *propname,
+				       u32 index, u32 *out_value);
 extern int of_property_read_u8_array(const struct device_node *np,
 			const char *propname, u8 *out_values, size_t sz);
 extern int of_property_read_u16_array(const struct device_node *np,
@@ -394,6 +397,12 @@ static inline struct device_node *of_find_compatible_node(
 	return NULL;
 }
 
+static inline int of_property_read_u32_index(const struct device_node *np,
+			const char *propname, u32 index, u32 *out_value)
+{
+	return -ENOSYS;
+}
+
 static inline int of_property_read_u8_array(const struct device_node *np,
 			const char *propname, u8 *out_values, size_t sz)
 {
-- 
1.7.9.5



From linux at prisktech.co.nz  Wed Apr  3 02:24:44 2013
From: linux at prisktech.co.nz (Tony Prisk)
Date: Wed,  3 Apr 2013 19:24:44 +1300
Subject: [PATCHv5 0/7] arm: vt8500: Add support for pinctrl/gpio module
Message-ID: <1364970291-17721-1-git-send-email-linux@prisktech.co.nz>

v5 changes:
Changed as requested by Rob Herring:
Added of_find_property_value_of_size() to drivers/of/base.c to remove some
code that was being duplicated.

Changed as requested by Stephen Warren:
Redid the kfree(maps) code as devm_kzalloc would cause issues. We now kzalloc
maps all at once, and configs as required. A call to wmt_pctl_dt_free_map() is
used to kfree the allocated blocks if we fail early.

v4 changes:
Changed as requested by Stephen Warren:
Corrected the range checking in of_property_read_u32_index().
Fix configs[0] assignment in wmt_pctl_dt_node_to_map_pull().
Remove the kfree(maps) call, and use devm_kzalloc to simplify the fail path.
Drop the custom .of_xlate function and use the default of_gpio_simple_xlate.
Move the platform memory mapping from per-soc to common init.

v3 changes:
Rebased onto v3.9-rc4
Added the missing interrupt-controller info to the relevant dtsi files.
Removed the gpio-vt8500.txt binding along with the gpio driver.

Changes made as requested by Linux Walleij:
Removed the wm,pinmux property which has caused too much confusion, and left the
	open-coded version in arm/arch-vt8500/vt8500.c until a proper solution
	is sorted out.

Changes made as requested by Stephen Warren:
Defined an active-low flag for gpio since its useful and we will have a use-case
	for it with our LCD power-on/off.

v2 changes:
Rebased onto v3.9-rc2

Changes made as requested by Linus Walleij:
Moved the files into drivers/pinctrl/vt8500/ to keep them tidy.
Changed readl/writel to *_relaxed variants.
Comment indentation corrected and remove additional whitespace.
Changed wmt_pctl_find_group_by_pin() error code from -1 to -EINVAL.
Removed OF read indexed-u32 function to OF subsystem.
General code tidy up as requested.

Changes made as requested by Stephen Warren:
Add binding information for interrupt generation.
Move optional properties to correct location in document.


This patch series removes the existing GPIO driver and replaces it with
a combined pinctrl+gpio driver.

Patch 1 - Add an OF function to read the nth u32 value from a property
  listing multiple values.

Patch 2 - Increase the available GPIO space for the newly added gpios.
  Because there is no hardware documentation from Wondermedia we don't know
  how many GPIO's there actually are. New gpio pins have been located since
  the original GPIO driver was written, hence the increase.

Patch 3 - The main pinctrl/gpio driver and the data for the 5 supported SoCs.
  Each SoC is different, and therefore has its own data. This design was
  borrowed from the Tegra pinctrl driver. The pin numbering is based on a
  bank+pin encoding so that when other pin functions are found later on we can
  add them without having to renumber existing pins.

Patch 4 - Update the SoC dts(i) files to support the new pinctrl driver.

Patch 5 - Remove the existing GPIO driver nodes from the dtsi's.

Patch 6 - Remove the existing GPIO driver.

I suspect this series may need to be broken up since there are two arm-soc
patches, and 4 pinctrl/gpio patches.

Patch 1 is required for the new driver to function properly.
Patch 2 is independant, but required for the driver to function properly.
Patches 3-4 are pinctrl/gpio patches.
Patch 5-6 remove the old gpio code which is no longer required.


Patch 2 could go via arm-soc if necessary.

Regards
Tony Prisk

Tony Prisk (7):
  of: Add support for reading a u32 from a multi-value property.
  of: Remove duplicated code for validating property and value
  arm: vt8500: Increase available GPIOs on arch-vt8500
  pinctrl: gpio: vt8500: Add pincontrol driver for arch-vt8500
  arm: dts: vt8500: Update Wondermedia SoC dtsi files for pinctrl
    driver
  arm: vt8500: Remove gpio devicetree nodes
  gpio: vt8500: Remove arch-vt8500 gpio driver

 .../devicetree/bindings/gpio/gpio-vt8500.txt       |   24 -
 .../devicetree/bindings/pinctrl/pinctrl-vt8500.txt |   57 ++
 arch/arm/Kconfig                                   |    3 +-
 arch/arm/boot/dts/vt8500.dtsi                      |   10 +-
 arch/arm/boot/dts/wm8505.dtsi                      |   10 +-
 arch/arm/boot/dts/wm8650.dtsi                      |   10 +-
 arch/arm/boot/dts/wm8850.dtsi                      |   10 +-
 arch/arm/mach-vt8500/Kconfig                       |    1 +
 drivers/gpio/Kconfig                               |    6 -
 drivers/gpio/Makefile                              |    1 -
 drivers/gpio/gpio-vt8500.c                         |  355 -----------
 drivers/of/base.c                                  |  111 ++--
 drivers/pinctrl/Kconfig                            |    1 +
 drivers/pinctrl/Makefile                           |    1 +
 drivers/pinctrl/vt8500/Kconfig                     |   52 ++
 drivers/pinctrl/vt8500/Makefile                    |    8 +
 drivers/pinctrl/vt8500/pinctrl-vt8500.c            |  501 ++++++++++++++++
 drivers/pinctrl/vt8500/pinctrl-wm8505.c            |  532 ++++++++++++++++
 drivers/pinctrl/vt8500/pinctrl-wm8650.c            |  370 ++++++++++++
 drivers/pinctrl/vt8500/pinctrl-wm8750.c            |  409 +++++++++++++
 drivers/pinctrl/vt8500/pinctrl-wm8850.c            |  388 ++++++++++++
 drivers/pinctrl/vt8500/pinctrl-wmt.c               |  632 ++++++++++++++++++++
 drivers/pinctrl/vt8500/pinctrl-wmt.h               |   79 +++
 include/linux/of.h                                 |    9 +
 24 files changed, 3142 insertions(+), 438 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/gpio/gpio-vt8500.txt
 create mode 100644 Documentation/devicetree/bindings/pinctrl/pinctrl-vt8500.txt
 delete mode 100644 drivers/gpio/gpio-vt8500.c
 create mode 100644 drivers/pinctrl/vt8500/Kconfig
 create mode 100644 drivers/pinctrl/vt8500/Makefile
 create mode 100644 drivers/pinctrl/vt8500/pinctrl-vt8500.c
 create mode 100644 drivers/pinctrl/vt8500/pinctrl-wm8505.c
 create mode 100644 drivers/pinctrl/vt8500/pinctrl-wm8650.c
 create mode 100644 drivers/pinctrl/vt8500/pinctrl-wm8750.c
 create mode 100644 drivers/pinctrl/vt8500/pinctrl-wm8850.c
 create mode 100644 drivers/pinctrl/vt8500/pinctrl-wmt.c
 create mode 100644 drivers/pinctrl/vt8500/pinctrl-wmt.h

-- 
1.7.9.5



From linux at prisktech.co.nz  Wed Apr  3 02:24:46 2013
From: linux at prisktech.co.nz (Tony Prisk)
Date: Wed,  3 Apr 2013 19:24:46 +1300
Subject: [PATCHv5 2/7] of: Remove duplicated code for validating property and
 value
In-Reply-To: <1364970291-17721-1-git-send-email-linux@prisktech.co.nz>
References: <1364970291-17721-1-git-send-email-linux@prisktech.co.nz>
Message-ID: <1364970291-17721-3-git-send-email-linux@prisktech.co.nz>

Several functions in of/base.c have the same code duplicated for
finding and validating a property and value.

struct property *prop = of_find_property(np, propname, NULL);
if (!prop)
	return -EINVAL;
if (!prop->value)
	return -ENODATA;
if (<some length> > prop->length)
	return -EOVERFLOW;

This patch adds of_find_property_value_of_size() which performs the
equivalent of the above code and removes the instances where it was
duplicated in several functions.

Reported-by: Rob Herring <robherring2 at gmail.com>
Signed-off-by: Tony Prisk <linux at prisktech.co.nz>
---
 drivers/of/base.c |   94 +++++++++++++++++++++++++++++------------------------
 1 file changed, 51 insertions(+), 43 deletions(-)

diff --git a/drivers/of/base.c b/drivers/of/base.c
index f6c89ed..c6443de 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -746,6 +746,34 @@ struct device_node *of_find_node_by_phandle(phandle handle)
 EXPORT_SYMBOL(of_find_node_by_phandle);
 
 /**
+ * of_find_property_value_of_size
+ *
+ * @np:		device node from which the property value is to be read.
+ * @propname:	name of the property to be searched.
+ * @len:	requested length of property value
+ *
+ * Search for a property in a device node and valid the requested size.
+ * Returns the property value on success, -EINVAL if the property does not
+ *  exist, -ENODATA if property does not have a value, and -EOVERFLOW if the
+ * property data isn't large enough.
+ *
+ */
+static void *of_find_property_value_of_size(const struct device_node *np,
+			const char *propname, u32 len)
+{
+	struct property *prop = of_find_property(np, propname, NULL);
+
+	if (!prop)
+		return ERR_PTR(-EINVAL);
+	if (!prop->value)
+		return ERR_PTR(-ENODATA);
+	if (len > prop->length)
+		return ERR_PTR(-EOVERFLOW);
+
+	return prop->value;
+}
+
+/**
  * of_property_read_u32_index - Find and read a u32 from a multi-value property.
  *
  * @np:		device node from which the property value is to be read.
@@ -764,16 +792,13 @@ int of_property_read_u32_index(const struct device_node *np,
 				       const char *propname,
 				       u32 index, u32 *out_value)
 {
-	struct property *prop = of_find_property(np, propname, NULL);
+	const u32 *val = of_find_property_value_of_size(np, propname,
+					((index + 1) * sizeof(*out_value)));
 
-	if (!prop)
-		return -EINVAL;
-	if (!prop->value)
-		return -ENODATA;
-	if (((index + 1) * sizeof(*out_value)) > prop->length)
-		return -EOVERFLOW;
+	if (IS_ERR(val))
+		return PTR_ERR(val);
 
-	*out_value = be32_to_cpup(((__be32 *)prop->value) + index);
+	*out_value = be32_to_cpup(((__be32 *)val) + index);
 	return 0;
 }
 EXPORT_SYMBOL_GPL(of_property_read_u32_index);
@@ -799,17 +824,12 @@ EXPORT_SYMBOL_GPL(of_property_read_u32_index);
 int of_property_read_u8_array(const struct device_node *np,
 			const char *propname, u8 *out_values, size_t sz)
 {
-	struct property *prop = of_find_property(np, propname, NULL);
-	const u8 *val;
+	const u8 *val = of_find_property_value_of_size(np, propname,
+						(sz * sizeof(*out_values)));
 
-	if (!prop)
-		return -EINVAL;
-	if (!prop->value)
-		return -ENODATA;
-	if ((sz * sizeof(*out_values)) > prop->length)
-		return -EOVERFLOW;
+	if (IS_ERR(val))
+		return PTR_ERR(val);
 
-	val = prop->value;
 	while (sz--)
 		*out_values++ = *val++;
 	return 0;
@@ -837,17 +857,12 @@ EXPORT_SYMBOL_GPL(of_property_read_u8_array);
 int of_property_read_u16_array(const struct device_node *np,
 			const char *propname, u16 *out_values, size_t sz)
 {
-	struct property *prop = of_find_property(np, propname, NULL);
-	const __be16 *val;
+	const __be16 *val = of_find_property_value_of_size(np, propname,
+						(sz * sizeof(*out_values)));
 
-	if (!prop)
-		return -EINVAL;
-	if (!prop->value)
-		return -ENODATA;
-	if ((sz * sizeof(*out_values)) > prop->length)
-		return -EOVERFLOW;
+	if (IS_ERR(val))
+		return PTR_ERR(val);
 
-	val = prop->value;
 	while (sz--)
 		*out_values++ = be16_to_cpup(val++);
 	return 0;
@@ -874,17 +889,12 @@ int of_property_read_u32_array(const struct device_node *np,
 			       const char *propname, u32 *out_values,
 			       size_t sz)
 {
-	struct property *prop = of_find_property(np, propname, NULL);
-	const __be32 *val;
+	const __be32 *val = of_find_property_value_of_size(np, propname,
+						(sz * sizeof(*out_values)));
 
-	if (!prop)
-		return -EINVAL;
-	if (!prop->value)
-		return -ENODATA;
-	if ((sz * sizeof(*out_values)) > prop->length)
-		return -EOVERFLOW;
+	if (IS_ERR(val))
+		return PTR_ERR(val);
 
-	val = prop->value;
 	while (sz--)
 		*out_values++ = be32_to_cpup(val++);
 	return 0;
@@ -907,15 +917,13 @@ EXPORT_SYMBOL_GPL(of_property_read_u32_array);
 int of_property_read_u64(const struct device_node *np, const char *propname,
 			 u64 *out_value)
 {
-	struct property *prop = of_find_property(np, propname, NULL);
+	const __be32 *val = of_find_property_value_of_size(np, propname,
+						sizeof(*out_value));
 
-	if (!prop)
-		return -EINVAL;
-	if (!prop->value)
-		return -ENODATA;
-	if (sizeof(*out_value) > prop->length)
-		return -EOVERFLOW;
-	*out_value = of_read_number(prop->value, 2);
+	if (IS_ERR(val))
+		return PTR_ERR(val);
+
+	*out_value = of_read_number(val, 2);
 	return 0;
 }
 EXPORT_SYMBOL_GPL(of_property_read_u64);
-- 
1.7.9.5



From linux at prisktech.co.nz  Wed Apr  3 02:24:50 2013
From: linux at prisktech.co.nz (Tony Prisk)
Date: Wed,  3 Apr 2013 19:24:50 +1300
Subject: [PATCHv5 6/7] arm: vt8500: Remove gpio devicetree nodes
In-Reply-To: <1364970291-17721-1-git-send-email-linux@prisktech.co.nz>
References: <1364970291-17721-1-git-send-email-linux@prisktech.co.nz>
Message-ID: <1364970291-17721-7-git-send-email-linux@prisktech.co.nz>

Remove the gpio related devicetree nodes as these are no longer required
with the move to a combined pinctrl/gpio driver.

Signed-off-by: Tony Prisk <linux at prisktech.co.nz>
---
 arch/arm/boot/dts/vt8500.dtsi |    7 -------
 arch/arm/boot/dts/wm8505.dtsi |    7 -------
 arch/arm/boot/dts/wm8650.dtsi |    7 -------
 arch/arm/boot/dts/wm8850.dtsi |    7 -------
 4 files changed, 28 deletions(-)

diff --git a/arch/arm/boot/dts/vt8500.dtsi b/arch/arm/boot/dts/vt8500.dtsi
index 8e87aa9..e1c3926 100644
--- a/arch/arm/boot/dts/vt8500.dtsi
+++ b/arch/arm/boot/dts/vt8500.dtsi
@@ -25,13 +25,6 @@
 			#interrupt-cells = <1>;
 		};
 
-		gpio: gpio-controller at d8110000 {
-			compatible = "via,vt8500-gpio";
-			gpio-controller;
-			reg = <0xd8110000 0x10000>;
-			#gpio-cells = <3>;
-		};
-
 		pinctrl: pinctrl at d8110000 {
 			compatible = "via,vt8500-pinctrl";
 			reg = <0xd8110000 0x10000>;
diff --git a/arch/arm/boot/dts/wm8505.dtsi b/arch/arm/boot/dts/wm8505.dtsi
index e4f768a..bb92ef8 100644
--- a/arch/arm/boot/dts/wm8505.dtsi
+++ b/arch/arm/boot/dts/wm8505.dtsi
@@ -40,13 +40,6 @@
 			interrupts = <56 57 58 59 60 61 62 63>;
 		};
 
-		gpio: gpio-controller at d8110000 {
-			compatible = "wm,wm8505-gpio";
-			gpio-controller;
-			reg = <0xd8110000 0x10000>;
-			#gpio-cells = <3>;
-		};
-
 		pinctrl: pinctrl at d8110000 {
 			compatible = "wm,wm8505-pinctrl";
 			reg = <0xd8110000 0x10000>;
diff --git a/arch/arm/boot/dts/wm8650.dtsi b/arch/arm/boot/dts/wm8650.dtsi
index 01b6a8d..bb4af58 100644
--- a/arch/arm/boot/dts/wm8650.dtsi
+++ b/arch/arm/boot/dts/wm8650.dtsi
@@ -34,13 +34,6 @@
 			interrupts = <56 57 58 59 60 61 62 63>;
 		};
 
-		gpio: gpio-controller at d8110000 {
-			compatible = "wm,wm8650-gpio";
-			gpio-controller;
-			reg = <0xd8110000 0x10000>;
-			#gpio-cells = <3>;
-		};
-
 		pinctrl: pinctrl at d8110000 {
 			compatible = "wm,wm8650-pinctrl";
 			reg = <0xd8110000 0x10000>;
diff --git a/arch/arm/boot/dts/wm8850.dtsi b/arch/arm/boot/dts/wm8850.dtsi
index 297aa05..11cd180 100644
--- a/arch/arm/boot/dts/wm8850.dtsi
+++ b/arch/arm/boot/dts/wm8850.dtsi
@@ -41,13 +41,6 @@
 			interrupts = <56 57 58 59 60 61 62 63>;
 		};
 
-		gpio: gpio-controller at d8110000 {
-			compatible = "wm,wm8650-gpio";
-			gpio-controller;
-			reg = <0xd8110000 0x10000>;
-			#gpio-cells = <3>;
-		};
-
 		pinctrl: pinctrl at d8110000 {
 			compatible = "wm,wm8850-pinctrl";
 			reg = <0xd8110000 0x10000>;
-- 
1.7.9.5



From linux at prisktech.co.nz  Wed Apr  3 02:24:51 2013
From: linux at prisktech.co.nz (Tony Prisk)
Date: Wed,  3 Apr 2013 19:24:51 +1300
Subject: [PATCHv5 7/7] gpio: vt8500: Remove arch-vt8500 gpio driver
In-Reply-To: <1364970291-17721-1-git-send-email-linux@prisktech.co.nz>
References: <1364970291-17721-1-git-send-email-linux@prisktech.co.nz>
Message-ID: <1364970291-17721-8-git-send-email-linux@prisktech.co.nz>

With the move to a combined pinctrl/gpio driver, the arch-vt8500
gpio driver is no longer required.

Signed-off-by: Tony Prisk <linux at prisktech.co.nz>
---
 .../devicetree/bindings/gpio/gpio-vt8500.txt       |   24 --
 drivers/gpio/Kconfig                               |    6 -
 drivers/gpio/Makefile                              |    1 -
 drivers/gpio/gpio-vt8500.c                         |  355 --------------------
 4 files changed, 386 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/gpio/gpio-vt8500.txt
 delete mode 100644 drivers/gpio/gpio-vt8500.c

diff --git a/Documentation/devicetree/bindings/gpio/gpio-vt8500.txt b/Documentation/devicetree/bindings/gpio/gpio-vt8500.txt
deleted file mode 100644
index f4dc523..0000000
--- a/Documentation/devicetree/bindings/gpio/gpio-vt8500.txt
+++ /dev/null
@@ -1,24 +0,0 @@
-VIA/Wondermedia VT8500 GPIO Controller
------------------------------------------------------
-
-Required properties:
-- compatible : "via,vt8500-gpio", "wm,wm8505-gpio"
-	or "wm,wm8650-gpio" depending on your SoC
-- reg : Should contain 1 register range (address and length)
-- #gpio-cells : should be <3>.
-	1) bank
-	2) pin number
-	3) flags - should be 0
-
-Example:
-
-	gpio: gpio-controller at d8110000 {
-		compatible = "via,vt8500-gpio";
-		gpio-controller;
-		reg = <0xd8110000 0x10000>;
-		#gpio-cells = <3>;
-	};
-
-	vibrate {
-		gpios = <&gpio 0 1 0>; /* Bank 0, Pin 1, No flags */
-	};
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 93aaadf..b166e30 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -227,12 +227,6 @@ config GPIO_TS5500
 	  blocks of the TS-5500: DIO1, DIO2 and the LCD port, and the TS-5600
 	  LCD port.
 
-config GPIO_VT8500
-	bool "VIA/Wondermedia SoC GPIO Support"
-	depends on ARCH_VT8500
-	help
-	  Say yes here to support the VT8500/WM8505/WM8650 GPIO controller.
-
 config GPIO_XILINX
 	bool "Xilinx GPIO support"
 	depends on PPC_OF || MICROBLAZE
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 22e07bc..a274d7d 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -80,7 +80,6 @@ obj-$(CONFIG_GPIO_TWL6040)	+= gpio-twl6040.o
 obj-$(CONFIG_GPIO_UCB1400)	+= gpio-ucb1400.o
 obj-$(CONFIG_GPIO_VIPERBOARD)	+= gpio-viperboard.o
 obj-$(CONFIG_GPIO_VR41XX)	+= gpio-vr41xx.o
-obj-$(CONFIG_GPIO_VT8500)	+= gpio-vt8500.o
 obj-$(CONFIG_GPIO_VX855)	+= gpio-vx855.o
 obj-$(CONFIG_GPIO_WM831X)	+= gpio-wm831x.o
 obj-$(CONFIG_GPIO_WM8350)	+= gpio-wm8350.o
diff --git a/drivers/gpio/gpio-vt8500.c b/drivers/gpio/gpio-vt8500.c
deleted file mode 100644
index 81683ca..0000000
--- a/drivers/gpio/gpio-vt8500.c
+++ /dev/null
@@ -1,355 +0,0 @@
-/* drivers/gpio/gpio-vt8500.c
- *
- * Copyright (C) 2012 Tony Prisk <linux at prisktech.co.nz>
- * Based on arch/arm/mach-vt8500/gpio.c:
- * - Copyright (C) 2010 Alexey Charkov <alchark at gmail.com>
- *
- * This software is licensed under the terms of the GNU General Public
- * License version 2, as published by the Free Software Foundation, and
- * may be copied, distributed, and modified under those terms.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- */
-
-#include <linux/module.h>
-#include <linux/err.h>
-#include <linux/io.h>
-#include <linux/gpio.h>
-#include <linux/platform_device.h>
-#include <linux/bitops.h>
-#include <linux/of.h>
-#include <linux/of_address.h>
-#include <linux/of_irq.h>
-#include <linux/of_device.h>
-
-/*
-	We handle GPIOs by bank, each bank containing up to 32 GPIOs covered
-	by one set of registers (although not all may be valid).
-
-	Because different SoC's have different register offsets, we pass the
-	register offsets as data in vt8500_gpio_dt_ids[].
-
-	A value of NO_REG is used to indicate that this register is not
-	supported. Only used for ->en at the moment.
-*/
-
-#define NO_REG	0xFFFF
-
-/*
- * struct vt8500_gpio_bank_regoffsets
- * @en: offset to enable register of the bank
- * @dir: offset to direction register of the bank
- * @data_out: offset to the data out register of the bank
- * @data_in: offset to the data in register of the bank
- * @ngpio: highest valid pin in this bank
- */
-
-struct vt8500_gpio_bank_regoffsets {
-	unsigned int	en;
-	unsigned int	dir;
-	unsigned int	data_out;
-	unsigned int	data_in;
-	unsigned char	ngpio;
-};
-
-struct vt8500_gpio_data {
-	unsigned int				num_banks;
-	struct vt8500_gpio_bank_regoffsets	banks[];
-};
-
-#define VT8500_BANK(__en, __dir, __out, __in, __ngpio)		\
-{								\
-	.en = __en,						\
-	.dir = __dir,						\
-	.data_out = __out,					\
-	.data_in = __in,					\
-	.ngpio = __ngpio,					\
-}
-
-static struct vt8500_gpio_data vt8500_data = {
-	.num_banks	= 7,
-	.banks	= {
-		VT8500_BANK(NO_REG, 0x3C, 0x5C, 0x7C, 9),
-		VT8500_BANK(0x00, 0x20, 0x40, 0x60, 26),
-		VT8500_BANK(0x04, 0x24, 0x44, 0x64, 28),
-		VT8500_BANK(0x08, 0x28, 0x48, 0x68, 31),
-		VT8500_BANK(0x0C, 0x2C, 0x4C, 0x6C, 19),
-		VT8500_BANK(0x10, 0x30, 0x50, 0x70, 19),
-		VT8500_BANK(0x14, 0x34, 0x54, 0x74, 23),
-	},
-};
-
-static struct vt8500_gpio_data wm8505_data = {
-	.num_banks	= 10,
-	.banks	= {
-		VT8500_BANK(0x64, 0x8C, 0xB4, 0xDC, 22),
-		VT8500_BANK(0x40, 0x68, 0x90, 0xB8, 8),
-		VT8500_BANK(0x44, 0x6C, 0x94, 0xBC, 32),
-		VT8500_BANK(0x48, 0x70, 0x98, 0xC0, 6),
-		VT8500_BANK(0x4C, 0x74, 0x9C, 0xC4, 16),
-		VT8500_BANK(0x50, 0x78, 0xA0, 0xC8, 25),
-		VT8500_BANK(0x54, 0x7C, 0xA4, 0xCC, 5),
-		VT8500_BANK(0x58, 0x80, 0xA8, 0xD0, 5),
-		VT8500_BANK(0x5C, 0x84, 0xAC, 0xD4, 12),
-		VT8500_BANK(0x60, 0x88, 0xB0, 0xD8, 16),
-		VT8500_BANK(0x500, 0x504, 0x508, 0x50C, 6),
-	},
-};
-
-/*
- * No information about which bits are valid so we just make
- * them all available until its figured out.
- */
-static struct vt8500_gpio_data wm8650_data = {
-	.num_banks	= 9,
-	.banks	= {
-		VT8500_BANK(0x40, 0x80, 0xC0, 0x00, 32),
-		VT8500_BANK(0x44, 0x84, 0xC4, 0x04, 32),
-		VT8500_BANK(0x48, 0x88, 0xC8, 0x08, 32),
-		VT8500_BANK(0x4C, 0x8C, 0xCC, 0x0C, 32),
-		VT8500_BANK(0x50, 0x90, 0xD0, 0x10, 32),
-		VT8500_BANK(0x54, 0x94, 0xD4, 0x14, 32),
-		VT8500_BANK(0x58, 0x98, 0xD8, 0x18, 32),
-		VT8500_BANK(0x5C, 0x9C, 0xDC, 0x1C, 32),
-		VT8500_BANK(0x7C, 0xBC, 0xFC, 0x3C, 32),
-		VT8500_BANK(0x500, 0x504, 0x508, 0x50C, 6),
-	},
-};
-
-struct vt8500_gpio_chip {
-	struct gpio_chip		chip;
-
-	const struct vt8500_gpio_bank_regoffsets *regs;
-	void __iomem	*base;
-};
-
-struct vt8500_data {
-	struct vt8500_gpio_chip *chip;
-	void __iomem *iobase;
-	int num_banks;
-};
-
-
-#define to_vt8500(__chip) container_of(__chip, struct vt8500_gpio_chip, chip)
-
-static int vt8500_gpio_request(struct gpio_chip *chip, unsigned offset)
-{
-	u32 val;
-	struct vt8500_gpio_chip *vt8500_chip = to_vt8500(chip);
-
-	if (vt8500_chip->regs->en == NO_REG)
-		return 0;
-
-	val = readl_relaxed(vt8500_chip->base + vt8500_chip->regs->en);
-	val |= BIT(offset);
-	writel_relaxed(val, vt8500_chip->base + vt8500_chip->regs->en);
-
-	return 0;
-}
-
-static void vt8500_gpio_free(struct gpio_chip *chip, unsigned offset)
-{
-	struct vt8500_gpio_chip *vt8500_chip = to_vt8500(chip);
-	u32 val;
-
-	if (vt8500_chip->regs->en == NO_REG)
-		return;
-
-	val = readl_relaxed(vt8500_chip->base + vt8500_chip->regs->en);
-	val &= ~BIT(offset);
-	writel_relaxed(val, vt8500_chip->base + vt8500_chip->regs->en);
-}
-
-static int vt8500_gpio_direction_input(struct gpio_chip *chip, unsigned offset)
-{
-	struct vt8500_gpio_chip *vt8500_chip = to_vt8500(chip);
-
-	u32 val = readl_relaxed(vt8500_chip->base + vt8500_chip->regs->dir);
-	val &= ~BIT(offset);
-	writel_relaxed(val, vt8500_chip->base + vt8500_chip->regs->dir);
-
-	return 0;
-}
-
-static int vt8500_gpio_direction_output(struct gpio_chip *chip, unsigned offset,
-								int value)
-{
-	struct vt8500_gpio_chip *vt8500_chip = to_vt8500(chip);
-
-	u32 val = readl_relaxed(vt8500_chip->base + vt8500_chip->regs->dir);
-	val |= BIT(offset);
-	writel_relaxed(val, vt8500_chip->base + vt8500_chip->regs->dir);
-
-	if (value) {
-		val = readl_relaxed(vt8500_chip->base +
-						vt8500_chip->regs->data_out);
-		val |= BIT(offset);
-		writel_relaxed(val, vt8500_chip->base +
-						vt8500_chip->regs->data_out);
-	}
-	return 0;
-}
-
-static int vt8500_gpio_get_value(struct gpio_chip *chip, unsigned offset)
-{
-	struct vt8500_gpio_chip *vt8500_chip = to_vt8500(chip);
-
-	return (readl_relaxed(vt8500_chip->base + vt8500_chip->regs->data_in) >>
-								offset) & 1;
-}
-
-static void vt8500_gpio_set_value(struct gpio_chip *chip, unsigned offset,
-								int value)
-{
-	struct vt8500_gpio_chip *vt8500_chip = to_vt8500(chip);
-
-	u32 val = readl_relaxed(vt8500_chip->base +
-						vt8500_chip->regs->data_out);
-	if (value)
-		val |= BIT(offset);
-	else
-		val &= ~BIT(offset);
-
-	writel_relaxed(val, vt8500_chip->base + vt8500_chip->regs->data_out);
-}
-
-static int vt8500_of_xlate(struct gpio_chip *gc,
-			    const struct of_phandle_args *gpiospec, u32 *flags)
-{
-	/* bank if specificed in gpiospec->args[0] */
-	if (flags)
-		*flags = gpiospec->args[2];
-
-	return gpiospec->args[1];
-}
-
-static int vt8500_add_chips(struct platform_device *pdev, void __iomem *base,
-				const struct vt8500_gpio_data *data)
-{
-	struct vt8500_data *priv;
-	struct vt8500_gpio_chip *vtchip;
-	struct gpio_chip *chip;
-	int i;
-	int pin_cnt = 0;
-
-	priv = devm_kzalloc(&pdev->dev, sizeof(struct vt8500_data), GFP_KERNEL);
-	if (!priv) {
-		dev_err(&pdev->dev, "failed to allocate memory\n");
-		return -ENOMEM;
-	}
-
-	priv->chip = devm_kzalloc(&pdev->dev,
-			sizeof(struct vt8500_gpio_chip) * data->num_banks,
-			GFP_KERNEL);
-	if (!priv->chip) {
-		dev_err(&pdev->dev, "failed to allocate chip memory\n");
-		return -ENOMEM;
-	}
-
-	priv->iobase = base;
-	priv->num_banks = data->num_banks;
-	platform_set_drvdata(pdev, priv);
-
-	vtchip = priv->chip;
-
-	for (i = 0; i < data->num_banks; i++) {
-		vtchip[i].base = base;
-		vtchip[i].regs = &data->banks[i];
-
-		chip = &vtchip[i].chip;
-
-		chip->of_xlate = vt8500_of_xlate;
-		chip->of_gpio_n_cells = 3;
-		chip->of_node = pdev->dev.of_node;
-
-		chip->request = vt8500_gpio_request;
-		chip->free = vt8500_gpio_free;
-		chip->direction_input = vt8500_gpio_direction_input;
-		chip->direction_output = vt8500_gpio_direction_output;
-		chip->get = vt8500_gpio_get_value;
-		chip->set = vt8500_gpio_set_value;
-		chip->can_sleep = 0;
-		chip->base = pin_cnt;
-		chip->ngpio = data->banks[i].ngpio;
-
-		pin_cnt += data->banks[i].ngpio;
-
-		gpiochip_add(chip);
-	}
-	return 0;
-}
-
-static struct of_device_id vt8500_gpio_dt_ids[] = {
-	{ .compatible = "via,vt8500-gpio", .data = &vt8500_data, },
-	{ .compatible = "wm,wm8505-gpio", .data = &wm8505_data, },
-	{ .compatible = "wm,wm8650-gpio", .data = &wm8650_data, },
-	{ /* Sentinel */ },
-};
-
-static int vt8500_gpio_probe(struct platform_device *pdev)
-{
-	int ret;
-	void __iomem *gpio_base;
-	struct resource *res;
-	const struct of_device_id *of_id =
-				of_match_device(vt8500_gpio_dt_ids, &pdev->dev);
-
-	if (!of_id) {
-		dev_err(&pdev->dev, "No matching driver data\n");
-		return -ENODEV;
-	}
-
-	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-	if (!res) {
-		dev_err(&pdev->dev, "Unable to get IO resource\n");
-		return -ENODEV;
-	}
-
-	gpio_base = devm_request_and_ioremap(&pdev->dev, res);
-	if (!gpio_base) {
-		dev_err(&pdev->dev, "Unable to map GPIO registers\n");
-		return -ENOMEM;
-	}
-
-	ret = vt8500_add_chips(pdev, gpio_base, of_id->data);
-
-	return ret;
-}
-
-static int vt8500_gpio_remove(struct platform_device *pdev)
-{
-	int i;
-	int ret;
-	struct vt8500_data *priv = platform_get_drvdata(pdev);
-	struct vt8500_gpio_chip *vtchip = priv->chip;
-
-	for (i = 0; i < priv->num_banks; i++) {
-		ret = gpiochip_remove(&vtchip[i].chip);
-		if (ret)
-			dev_warn(&pdev->dev, "gpiochip_remove returned %d\n",
-				 ret);
-	}
-
-	return 0;
-}
-
-static struct platform_driver vt8500_gpio_driver = {
-	.probe		= vt8500_gpio_probe,
-	.remove		= vt8500_gpio_remove,
-	.driver		= {
-		.name	= "vt8500-gpio",
-		.owner	= THIS_MODULE,
-		.of_match_table = vt8500_gpio_dt_ids,
-	},
-};
-
-module_platform_driver(vt8500_gpio_driver);
-
-MODULE_DESCRIPTION("VT8500 GPIO Driver");
-MODULE_AUTHOR("Tony Prisk <linux at prisktech.co.nz>");
-MODULE_LICENSE("GPL v2");
-MODULE_DEVICE_TABLE(of, vt8500_gpio_dt_ids);
-- 
1.7.9.5



From linux at prisktech.co.nz  Wed Apr  3 02:24:49 2013
From: linux at prisktech.co.nz (Tony Prisk)
Date: Wed,  3 Apr 2013 19:24:49 +1300
Subject: [PATCHv5 5/7] arm: dts: vt8500: Update Wondermedia SoC dtsi files for
 pinctrl driver
In-Reply-To: <1364970291-17721-1-git-send-email-linux@prisktech.co.nz>
References: <1364970291-17721-1-git-send-email-linux@prisktech.co.nz>
Message-ID: <1364970291-17721-6-git-send-email-linux@prisktech.co.nz>

This patch adds pinctrl nodes to the VIA VT8500 and Wondermedia SoC dtsi
files to support the pinctrl driver.

Signed-off-by: Tony Prisk <linux at prisktech.co.nz>
---
 arch/arm/boot/dts/vt8500.dtsi |    9 +++++++++
 arch/arm/boot/dts/wm8505.dtsi |    9 +++++++++
 arch/arm/boot/dts/wm8650.dtsi |    9 +++++++++
 arch/arm/boot/dts/wm8850.dtsi |    9 +++++++++
 4 files changed, 36 insertions(+)

diff --git a/arch/arm/boot/dts/vt8500.dtsi b/arch/arm/boot/dts/vt8500.dtsi
index cf31ced..8e87aa9 100644
--- a/arch/arm/boot/dts/vt8500.dtsi
+++ b/arch/arm/boot/dts/vt8500.dtsi
@@ -32,6 +32,15 @@
 			#gpio-cells = <3>;
 		};
 
+		pinctrl: pinctrl at d8110000 {
+			compatible = "via,vt8500-pinctrl";
+			reg = <0xd8110000 0x10000>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			gpio-controller;
+			#gpio-cells = <2>;
+		};
+
 		pmc at d8130000 {
 			compatible = "via,vt8500-pmc";
 			reg = <0xd8130000 0x1000>;
diff --git a/arch/arm/boot/dts/wm8505.dtsi b/arch/arm/boot/dts/wm8505.dtsi
index e74a1c0..e4f768a 100644
--- a/arch/arm/boot/dts/wm8505.dtsi
+++ b/arch/arm/boot/dts/wm8505.dtsi
@@ -47,6 +47,15 @@
 			#gpio-cells = <3>;
 		};
 
+		pinctrl: pinctrl at d8110000 {
+			compatible = "wm,wm8505-pinctrl";
+			reg = <0xd8110000 0x10000>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			gpio-controller;
+			#gpio-cells = <2>;
+		};
+
 		pmc at d8130000 {
 			compatible = "via,vt8500-pmc";
 			reg = <0xd8130000 0x1000>;
diff --git a/arch/arm/boot/dts/wm8650.dtsi b/arch/arm/boot/dts/wm8650.dtsi
index db3c0a1..01b6a8d 100644
--- a/arch/arm/boot/dts/wm8650.dtsi
+++ b/arch/arm/boot/dts/wm8650.dtsi
@@ -41,6 +41,15 @@
 			#gpio-cells = <3>;
 		};
 
+		pinctrl: pinctrl at d8110000 {
+			compatible = "wm,wm8650-pinctrl";
+			reg = <0xd8110000 0x10000>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			gpio-controller;
+			#gpio-cells = <2>;
+		};
+
 		pmc at d8130000 {
 			compatible = "via,vt8500-pmc";
 			reg = <0xd8130000 0x1000>;
diff --git a/arch/arm/boot/dts/wm8850.dtsi b/arch/arm/boot/dts/wm8850.dtsi
index e8cbfdc..297aa05 100644
--- a/arch/arm/boot/dts/wm8850.dtsi
+++ b/arch/arm/boot/dts/wm8850.dtsi
@@ -48,6 +48,15 @@
 			#gpio-cells = <3>;
 		};
 
+		pinctrl: pinctrl at d8110000 {
+			compatible = "wm,wm8850-pinctrl";
+			reg = <0xd8110000 0x10000>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			gpio-controller;
+			#gpio-cells = <2>;
+		};
+
 		pmc at d8130000 {
 			compatible = "via,vt8500-pmc";
 			reg = <0xd8130000 0x1000>;
-- 
1.7.9.5



From olof at lixom.net  Wed Apr  3 02:25:12 2013
From: olof at lixom.net (Olof Johansson)
Date: Tue, 2 Apr 2013 23:25:12 -0700
Subject: [GIT PULL v2] Renesas ARM and SH based SoC pinmux updates for
 v3.10
In-Reply-To: <1364954706-14727-1-git-send-email-horms+renesas@verge.net.au>
References: <1364954706-14727-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <20130403062512.GA29601@quad.lixom.net>

On Wed, Apr 03, 2013 at 11:04:38AM +0900, Simon Horman wrote:
> Hi Olof, Hi Arnd,
> 
> The following changes since commit 809609a5d8427b0025304dbb69a84a692d11c4f9:
> 
>   Merge branch 'soc' into pinmux-base (2013-04-02 11:08:34 +0900)
> 
> are available in the git repository at:
> 
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-pinmux2-for-v3.10
> 
> for you to fetch changes up to 202ac6a21a79500ef5aab4cd8665be2597e9345c:
> 
>   sh-pfc: r8a73a4: Remove unused GPIO bias data (2013-04-03 10:30:43 +0900)


Pulled into next/soc2.


-Olof


From linux at prisktech.co.nz  Wed Apr  3 02:24:48 2013
From: linux at prisktech.co.nz (Tony Prisk)
Date: Wed,  3 Apr 2013 19:24:48 +1300
Subject: [PATCHv5 4/7] pinctrl: gpio: vt8500: Add pincontrol driver for
 arch-vt8500
In-Reply-To: <1364970291-17721-1-git-send-email-linux@prisktech.co.nz>
References: <1364970291-17721-1-git-send-email-linux@prisktech.co.nz>
Message-ID: <1364970291-17721-5-git-send-email-linux@prisktech.co.nz>

This patch adds support for the GPIO/pinmux controller found on the VIA
VT8500 and Wondermedia WM8xxx-series SoCs.

Each pin within the controller is capable of operating as a GPIO or as
an alternate function. The pins are numbered according to their control
bank/bit so that if new pins are added, the existing numbering is maintained.

All currently supported SoCs are included: VT8500, WM8505, WM8650, WM8750 and
WM8850.

Signed-off-by: Tony Prisk <linux at prisktech.co.nz>
Reviewed-by: Stephen Warren <swarren at nvidia.com>
---
 .../devicetree/bindings/pinctrl/pinctrl-vt8500.txt |   57 ++
 arch/arm/mach-vt8500/Kconfig                       |    1 +
 drivers/pinctrl/Kconfig                            |    1 +
 drivers/pinctrl/Makefile                           |    1 +
 drivers/pinctrl/vt8500/Kconfig                     |   52 ++
 drivers/pinctrl/vt8500/Makefile                    |    8 +
 drivers/pinctrl/vt8500/pinctrl-vt8500.c            |  501 ++++++++++++++++
 drivers/pinctrl/vt8500/pinctrl-wm8505.c            |  532 ++++++++++++++++
 drivers/pinctrl/vt8500/pinctrl-wm8650.c            |  370 ++++++++++++
 drivers/pinctrl/vt8500/pinctrl-wm8750.c            |  409 +++++++++++++
 drivers/pinctrl/vt8500/pinctrl-wm8850.c            |  388 ++++++++++++
 drivers/pinctrl/vt8500/pinctrl-wmt.c               |  632 ++++++++++++++++++++
 drivers/pinctrl/vt8500/pinctrl-wmt.h               |   79 +++
 13 files changed, 3031 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pinctrl/pinctrl-vt8500.txt
 create mode 100644 drivers/pinctrl/vt8500/Kconfig
 create mode 100644 drivers/pinctrl/vt8500/Makefile
 create mode 100644 drivers/pinctrl/vt8500/pinctrl-vt8500.c
 create mode 100644 drivers/pinctrl/vt8500/pinctrl-wm8505.c
 create mode 100644 drivers/pinctrl/vt8500/pinctrl-wm8650.c
 create mode 100644 drivers/pinctrl/vt8500/pinctrl-wm8750.c
 create mode 100644 drivers/pinctrl/vt8500/pinctrl-wm8850.c
 create mode 100644 drivers/pinctrl/vt8500/pinctrl-wmt.c
 create mode 100644 drivers/pinctrl/vt8500/pinctrl-wmt.h

diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-vt8500.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-vt8500.txt
new file mode 100644
index 0000000..b3aa90f
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-vt8500.txt
@@ -0,0 +1,57 @@
+VIA VT8500 and Wondermedia WM8xxx-series pinmux/gpio controller
+
+These SoCs contain a combined Pinmux/GPIO module. Each pin may operate as
+either a GPIO in, GPIO out or as an alternate function (I2C, SPI etc).
+
+Required properties:
+- compatible: "via,vt8500-pinctrl", "wm,wm8505-pinctrl", "wm,wm8650-pinctrl",
+	"wm8750-pinctrl" or "wm,wm8850-pinctrl"
+- reg: Should contain the physical address of the module's registers.
+- interrupt-controller: Marks the device node as an interrupt controller.
+- #interrupt-cells: Should be two.
+- gpio-controller: Marks the device node as a GPIO controller.
+- #gpio-cells : Should be two. The first cell is the pin number and the
+  second cell is used to specify optional parameters.
+	bit 0 - active low
+
+Please refer to ../gpio/gpio.txt for a general description of GPIO bindings.
+
+Please refer to pinctrl-bindings.txt in this directory for details of the
+common pinctrl bindings used by client devices, including the meaning of the
+phrase "pin configuration node".
+
+Each pin configuration node lists the pin(s) to which it applies, and one or
+more of the mux functions to select on those pin(s), and pull-up/down
+configuration. Each subnode only affects those parameters that are explicitly
+listed. In other words, a subnode that lists only a mux function implies no
+information about any pull configuration. Similarly, a subnode that lists only
+a pull parameter implies no information about the mux function.
+
+Required subnode-properties:
+- wm,pins: An array of cells. Each cell contains the ID of a pin.
+
+Optional subnode-properties:
+- wm,function: Integer, containing the function to mux to the pin(s):
+  0: GPIO in
+  1: GPIO out
+  2: alternate
+
+- wm,pull: Integer, representing the pull-down/up to apply to the pin(s):
+  0: none
+  1: down
+  2: up
+
+Each of wm,function and wm,pull may contain either a single value which
+will be applied to all pins in wm,pins, or one value for each entry in
+wm,pins.
+
+Example:
+
+	pinctrl: pinctrl {
+		compatible = "wm,wm8505-pinctrl";
+		reg = <0xD8110000 0x10000>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
diff --git a/arch/arm/mach-vt8500/Kconfig b/arch/arm/mach-vt8500/Kconfig
index e3e94b2..9b25293 100644
--- a/arch/arm/mach-vt8500/Kconfig
+++ b/arch/arm/mach-vt8500/Kconfig
@@ -7,6 +7,7 @@ config ARCH_VT8500
 	select GENERIC_CLOCKEVENTS
 	select HAVE_CLK
 	select VT8500_TIMER
+	select PINCTRL
 	help
 	  Support for VIA/WonderMedia VT8500/WM85xx System-on-Chip.
 
diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index 34f51d2..35e9400 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -229,6 +229,7 @@ config PINCTRL_EXYNOS5440
 source "drivers/pinctrl/mvebu/Kconfig"
 source "drivers/pinctrl/sh-pfc/Kconfig"
 source "drivers/pinctrl/spear/Kconfig"
+source "drivers/pinctrl/vt8500/Kconfig"
 
 config PINCTRL_XWAY
 	bool
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index f82cc5b..a5a52c8 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -52,3 +52,4 @@ obj-$(CONFIG_PLAT_ORION)        += mvebu/
 obj-$(CONFIG_ARCH_SHMOBILE)	+= sh-pfc/
 obj-$(CONFIG_SUPERH)		+= sh-pfc/
 obj-$(CONFIG_PLAT_SPEAR)	+= spear/
+obj-$(CONFIG_ARCH_VT8500)	+= vt8500/
diff --git a/drivers/pinctrl/vt8500/Kconfig b/drivers/pinctrl/vt8500/Kconfig
new file mode 100644
index 0000000..55724a7
--- /dev/null
+++ b/drivers/pinctrl/vt8500/Kconfig
@@ -0,0 +1,52 @@
+#
+# VIA/Wondermedia PINCTRL drivers
+#
+
+if ARCH_VT8500
+
+config PINCTRL_WMT
+	bool
+	select PINMUX
+	select GENERIC_PINCONF
+
+config PINCTRL_VT8500
+	bool "VIA VT8500 pin controller driver"
+	depends on ARCH_WM8505
+	select PINCTRL_WMT
+	help
+	  Say yes here to support the gpio/pin control module on
+	  VIA VT8500 SoCs.
+
+config PINCTRL_WM8505
+	bool "Wondermedia WM8505 pin controller driver"
+	depends on ARCH_WM8505
+	select PINCTRL_WMT
+	help
+	  Say yes here to support the gpio/pin control module on
+	  Wondermedia WM8505 SoCs.
+
+config PINCTRL_WM8650
+	bool "Wondermedia WM8650 pin controller driver"
+	depends on ARCH_WM8505
+	select PINCTRL_WMT
+	help
+	  Say yes here to support the gpio/pin control module on
+	  Wondermedia WM8650 SoCs.
+
+config PINCTRL_WM8750
+	bool "Wondermedia WM8750 pin controller driver"
+	depends on ARCH_WM8750
+	select PINCTRL_WMT
+	help
+	  Say yes here to support the gpio/pin control module on
+	  Wondermedia WM8750 SoCs.
+
+config PINCTRL_WM8850
+	bool "Wondermedia WM8850 pin controller driver"
+	depends on ARCH_WM8850
+	select PINCTRL_WMT
+	help
+	  Say yes here to support the gpio/pin control module on
+	  Wondermedia WM8850 SoCs.
+
+endif
diff --git a/drivers/pinctrl/vt8500/Makefile b/drivers/pinctrl/vt8500/Makefile
new file mode 100644
index 0000000..24ec45d
--- /dev/null
+++ b/drivers/pinctrl/vt8500/Makefile
@@ -0,0 +1,8 @@
+# VIA/Wondermedia pinctrl support
+
+obj-$(CONFIG_PINCTRL_WMT)	+= pinctrl-wmt.o
+obj-$(CONFIG_PINCTRL_VT8500)	+= pinctrl-vt8500.o
+obj-$(CONFIG_PINCTRL_WM8505)	+= pinctrl-wm8505.o
+obj-$(CONFIG_PINCTRL_WM8650)	+= pinctrl-wm8650.o
+obj-$(CONFIG_PINCTRL_WM8750)	+= pinctrl-wm8750.o
+obj-$(CONFIG_PINCTRL_WM8850)	+= pinctrl-wm8850.o
diff --git a/drivers/pinctrl/vt8500/pinctrl-vt8500.c b/drivers/pinctrl/vt8500/pinctrl-vt8500.c
new file mode 100644
index 0000000..f2fe9f8
--- /dev/null
+++ b/drivers/pinctrl/vt8500/pinctrl-vt8500.c
@@ -0,0 +1,501 @@
+/*
+ * Pinctrl data for VIA VT8500 SoC
+ *
+ * Copyright (c) 2013 Tony Prisk <linux at prisktech.co.nz>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ */
+
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/pinctrl/pinctrl.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+
+#include "pinctrl-wmt.h"
+
+/*
+ * Describe the register offsets within the GPIO memory space
+ * The dedicated external GPIO's should always be listed in bank 0
+ * so they are exported in the 0..31 range which is what users
+ * expect.
+ *
+ * Do not reorder these banks as it will change the pin numbering
+ */
+static const struct wmt_pinctrl_bank_registers vt8500_banks[] = {
+	WMT_PINCTRL_BANK(NO_REG, 0x3C, 0x5C, 0x7C, NO_REG, NO_REG),	/* 0 */
+	WMT_PINCTRL_BANK(0x00, 0x20, 0x40, 0x60, NO_REG, NO_REG),	/* 1 */
+	WMT_PINCTRL_BANK(0x04, 0x24, 0x44, 0x64, NO_REG, NO_REG),	/* 2 */
+	WMT_PINCTRL_BANK(0x08, 0x28, 0x48, 0x68, NO_REG, NO_REG),	/* 3 */
+	WMT_PINCTRL_BANK(0x0C, 0x2C, 0x4C, 0x6C, NO_REG, NO_REG),	/* 4 */
+	WMT_PINCTRL_BANK(0x10, 0x30, 0x50, 0x70, NO_REG, NO_REG),	/* 5 */
+	WMT_PINCTRL_BANK(0x14, 0x34, 0x54, 0x74, NO_REG, NO_REG),	/* 6 */
+};
+
+/* Please keep sorted by bank/bit */
+#define WMT_PIN_EXTGPIO0	WMT_PIN(0, 0)
+#define WMT_PIN_EXTGPIO1	WMT_PIN(0, 1)
+#define WMT_PIN_EXTGPIO2	WMT_PIN(0, 2)
+#define WMT_PIN_EXTGPIO3	WMT_PIN(0, 3)
+#define WMT_PIN_EXTGPIO4	WMT_PIN(0, 4)
+#define WMT_PIN_EXTGPIO5	WMT_PIN(0, 5)
+#define WMT_PIN_EXTGPIO6	WMT_PIN(0, 6)
+#define WMT_PIN_EXTGPIO7	WMT_PIN(0, 7)
+#define WMT_PIN_EXTGPIO8	WMT_PIN(0, 8)
+#define WMT_PIN_UART0RTS	WMT_PIN(1, 0)
+#define WMT_PIN_UART0TXD	WMT_PIN(1, 1)
+#define WMT_PIN_UART0CTS	WMT_PIN(1, 2)
+#define WMT_PIN_UART0RXD	WMT_PIN(1, 3)
+#define WMT_PIN_UART1RTS	WMT_PIN(1, 4)
+#define WMT_PIN_UART1TXD	WMT_PIN(1, 5)
+#define WMT_PIN_UART1CTS	WMT_PIN(1, 6)
+#define WMT_PIN_UART1RXD	WMT_PIN(1, 7)
+#define WMT_PIN_SPI0CLK		WMT_PIN(1, 8)
+#define WMT_PIN_SPI0SS		WMT_PIN(1, 9)
+#define WMT_PIN_SPI0MISO	WMT_PIN(1, 10)
+#define WMT_PIN_SPI0MOSI	WMT_PIN(1, 11)
+#define WMT_PIN_SPI1CLK		WMT_PIN(1, 12)
+#define WMT_PIN_SPI1SS		WMT_PIN(1, 13)
+#define WMT_PIN_SPI1MISO	WMT_PIN(1, 14)
+#define WMT_PIN_SPI1MOSI	WMT_PIN(1, 15)
+#define WMT_PIN_SPI2CLK		WMT_PIN(1, 16)
+#define WMT_PIN_SPI2SS		WMT_PIN(1, 17)
+#define WMT_PIN_SPI2MISO	WMT_PIN(1, 18)
+#define WMT_PIN_SPI2MOSI	WMT_PIN(1, 19)
+#define WMT_PIN_SDDATA0		WMT_PIN(2, 0)
+#define WMT_PIN_SDDATA1		WMT_PIN(2, 1)
+#define WMT_PIN_SDDATA2		WMT_PIN(2, 2)
+#define WMT_PIN_SDDATA3		WMT_PIN(2, 3)
+#define WMT_PIN_MMCDATA0	WMT_PIN(2, 4)
+#define WMT_PIN_MMCDATA1	WMT_PIN(2, 5)
+#define WMT_PIN_MMCDATA2	WMT_PIN(2, 6)
+#define WMT_PIN_MMCDATA3	WMT_PIN(2, 7)
+#define WMT_PIN_SDCLK		WMT_PIN(2, 8)
+#define WMT_PIN_SDWP		WMT_PIN(2, 9)
+#define WMT_PIN_SDCMD		WMT_PIN(2, 10)
+#define WMT_PIN_MSDATA0		WMT_PIN(2, 16)
+#define WMT_PIN_MSDATA1		WMT_PIN(2, 17)
+#define WMT_PIN_MSDATA2		WMT_PIN(2, 18)
+#define WMT_PIN_MSDATA3		WMT_PIN(2, 19)
+#define WMT_PIN_MSCLK		WMT_PIN(2, 20)
+#define WMT_PIN_MSBS		WMT_PIN(2, 21)
+#define WMT_PIN_MSINS		WMT_PIN(2, 22)
+#define WMT_PIN_I2C0SCL		WMT_PIN(2, 24)
+#define WMT_PIN_I2C0SDA		WMT_PIN(2, 25)
+#define WMT_PIN_I2C1SCL		WMT_PIN(2, 26)
+#define WMT_PIN_I2C1SDA		WMT_PIN(2, 27)
+#define WMT_PIN_MII0RXD0	WMT_PIN(3, 0)
+#define WMT_PIN_MII0RXD1	WMT_PIN(3, 1)
+#define WMT_PIN_MII0RXD2	WMT_PIN(3, 2)
+#define WMT_PIN_MII0RXD3	WMT_PIN(3, 3)
+#define WMT_PIN_MII0RXCLK	WMT_PIN(3, 4)
+#define WMT_PIN_MII0RXDV	WMT_PIN(3, 5)
+#define WMT_PIN_MII0RXERR	WMT_PIN(3, 6)
+#define WMT_PIN_MII0PHYRST	WMT_PIN(3, 7)
+#define WMT_PIN_MII0TXD0	WMT_PIN(3, 8)
+#define WMT_PIN_MII0TXD1	WMT_PIN(3, 9)
+#define WMT_PIN_MII0TXD2	WMT_PIN(3, 10)
+#define WMT_PIN_MII0TXD3	WMT_PIN(3, 11)
+#define WMT_PIN_MII0TXCLK	WMT_PIN(3, 12)
+#define WMT_PIN_MII0TXEN	WMT_PIN(3, 13)
+#define WMT_PIN_MII0TXERR	WMT_PIN(3, 14)
+#define WMT_PIN_MII0PHYPD	WMT_PIN(3, 15)
+#define WMT_PIN_MII0COL		WMT_PIN(3, 16)
+#define WMT_PIN_MII0CRS		WMT_PIN(3, 17)
+#define WMT_PIN_MII0MDIO	WMT_PIN(3, 18)
+#define WMT_PIN_MII0MDC		WMT_PIN(3, 19)
+#define WMT_PIN_SEECS		WMT_PIN(3, 20)
+#define WMT_PIN_SEECK		WMT_PIN(3, 21)
+#define WMT_PIN_SEEDI		WMT_PIN(3, 22)
+#define WMT_PIN_SEEDO		WMT_PIN(3, 23)
+#define WMT_PIN_IDEDREQ0	WMT_PIN(3, 24)
+#define WMT_PIN_IDEDREQ1	WMT_PIN(3, 25)
+#define WMT_PIN_IDEIOW		WMT_PIN(3, 26)
+#define WMT_PIN_IDEIOR		WMT_PIN(3, 27)
+#define WMT_PIN_IDEDACK		WMT_PIN(3, 28)
+#define WMT_PIN_IDEIORDY	WMT_PIN(3, 29)
+#define WMT_PIN_IDEINTRQ	WMT_PIN(3, 30)
+#define WMT_PIN_VDIN0		WMT_PIN(4, 0)
+#define WMT_PIN_VDIN1		WMT_PIN(4, 1)
+#define WMT_PIN_VDIN2		WMT_PIN(4, 2)
+#define WMT_PIN_VDIN3		WMT_PIN(4, 3)
+#define WMT_PIN_VDIN4		WMT_PIN(4, 4)
+#define WMT_PIN_VDIN5		WMT_PIN(4, 5)
+#define WMT_PIN_VDIN6		WMT_PIN(4, 6)
+#define WMT_PIN_VDIN7		WMT_PIN(4, 7)
+#define WMT_PIN_VDOUT0		WMT_PIN(4, 8)
+#define WMT_PIN_VDOUT1		WMT_PIN(4, 9)
+#define WMT_PIN_VDOUT2		WMT_PIN(4, 10)
+#define WMT_PIN_VDOUT3		WMT_PIN(4, 11)
+#define WMT_PIN_VDOUT4		WMT_PIN(4, 12)
+#define WMT_PIN_VDOUT5		WMT_PIN(4, 13)
+#define WMT_PIN_NANDCLE0	WMT_PIN(4, 14)
+#define WMT_PIN_NANDCLE1	WMT_PIN(4, 15)
+#define WMT_PIN_VDOUT6_7	WMT_PIN(4, 16)
+#define WMT_PIN_VHSYNC		WMT_PIN(4, 17)
+#define WMT_PIN_VVSYNC		WMT_PIN(4, 18)
+#define WMT_PIN_TSDIN0		WMT_PIN(5, 8)
+#define WMT_PIN_TSDIN1		WMT_PIN(5, 9)
+#define WMT_PIN_TSDIN2		WMT_PIN(5, 10)
+#define WMT_PIN_TSDIN3		WMT_PIN(5, 11)
+#define WMT_PIN_TSDIN4		WMT_PIN(5, 12)
+#define WMT_PIN_TSDIN5		WMT_PIN(5, 13)
+#define WMT_PIN_TSDIN6		WMT_PIN(5, 14)
+#define WMT_PIN_TSDIN7		WMT_PIN(5, 15)
+#define WMT_PIN_TSSYNC		WMT_PIN(5, 16)
+#define WMT_PIN_TSVALID		WMT_PIN(5, 17)
+#define WMT_PIN_TSCLK		WMT_PIN(5, 18)
+#define WMT_PIN_LCDD0		WMT_PIN(6, 0)
+#define WMT_PIN_LCDD1		WMT_PIN(6, 1)
+#define WMT_PIN_LCDD2		WMT_PIN(6, 2)
+#define WMT_PIN_LCDD3		WMT_PIN(6, 3)
+#define WMT_PIN_LCDD4		WMT_PIN(6, 4)
+#define WMT_PIN_LCDD5		WMT_PIN(6, 5)
+#define WMT_PIN_LCDD6		WMT_PIN(6, 6)
+#define WMT_PIN_LCDD7		WMT_PIN(6, 7)
+#define WMT_PIN_LCDD8		WMT_PIN(6, 8)
+#define WMT_PIN_LCDD9		WMT_PIN(6, 9)
+#define WMT_PIN_LCDD10		WMT_PIN(6, 10)
+#define WMT_PIN_LCDD11		WMT_PIN(6, 11)
+#define WMT_PIN_LCDD12		WMT_PIN(6, 12)
+#define WMT_PIN_LCDD13		WMT_PIN(6, 13)
+#define WMT_PIN_LCDD14		WMT_PIN(6, 14)
+#define WMT_PIN_LCDD15		WMT_PIN(6, 15)
+#define WMT_PIN_LCDD16		WMT_PIN(6, 16)
+#define WMT_PIN_LCDD17		WMT_PIN(6, 17)
+#define WMT_PIN_LCDCLK		WMT_PIN(6, 18)
+#define WMT_PIN_LCDDEN		WMT_PIN(6, 19)
+#define WMT_PIN_LCDLINE		WMT_PIN(6, 20)
+#define WMT_PIN_LCDFRM		WMT_PIN(6, 21)
+#define WMT_PIN_LCDBIAS		WMT_PIN(6, 22)
+
+static const struct pinctrl_pin_desc vt8500_pins[] = {
+	PINCTRL_PIN(WMT_PIN_EXTGPIO0, "extgpio0"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO1, "extgpio1"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO2, "extgpio2"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO3, "extgpio3"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO4, "extgpio4"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO5, "extgpio5"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO6, "extgpio6"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO7, "extgpio7"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO8, "extgpio8"),
+	PINCTRL_PIN(WMT_PIN_UART0RTS, "uart0_rts"),
+	PINCTRL_PIN(WMT_PIN_UART0TXD, "uart0_txd"),
+	PINCTRL_PIN(WMT_PIN_UART0CTS, "uart0_cts"),
+	PINCTRL_PIN(WMT_PIN_UART0RXD, "uart0_rxd"),
+	PINCTRL_PIN(WMT_PIN_UART1RTS, "uart1_rts"),
+	PINCTRL_PIN(WMT_PIN_UART1TXD, "uart1_txd"),
+	PINCTRL_PIN(WMT_PIN_UART1CTS, "uart1_cts"),
+	PINCTRL_PIN(WMT_PIN_UART1RXD, "uart1_rxd"),
+	PINCTRL_PIN(WMT_PIN_SPI0CLK, "spi0_clk"),
+	PINCTRL_PIN(WMT_PIN_SPI0SS, "spi0_ss"),
+	PINCTRL_PIN(WMT_PIN_SPI0MISO, "spi0_miso"),
+	PINCTRL_PIN(WMT_PIN_SPI0MOSI, "spi0_mosi"),
+	PINCTRL_PIN(WMT_PIN_SPI1CLK, "spi1_clk"),
+	PINCTRL_PIN(WMT_PIN_SPI1SS, "spi1_ss"),
+	PINCTRL_PIN(WMT_PIN_SPI1MISO, "spi1_miso"),
+	PINCTRL_PIN(WMT_PIN_SPI1MOSI, "spi1_mosi"),
+	PINCTRL_PIN(WMT_PIN_SPI2CLK, "spi2_clk"),
+	PINCTRL_PIN(WMT_PIN_SPI2SS, "spi2_ss"),
+	PINCTRL_PIN(WMT_PIN_SPI2MISO, "spi2_miso"),
+	PINCTRL_PIN(WMT_PIN_SPI2MOSI, "spi2_mosi"),
+	PINCTRL_PIN(WMT_PIN_SDDATA0, "sd_data0"),
+	PINCTRL_PIN(WMT_PIN_SDDATA1, "sd_data1"),
+	PINCTRL_PIN(WMT_PIN_SDDATA2, "sd_data2"),
+	PINCTRL_PIN(WMT_PIN_SDDATA3, "sd_data3"),
+	PINCTRL_PIN(WMT_PIN_MMCDATA0, "mmc_data0"),
+	PINCTRL_PIN(WMT_PIN_MMCDATA1, "mmc_data1"),
+	PINCTRL_PIN(WMT_PIN_MMCDATA2, "mmc_data2"),
+	PINCTRL_PIN(WMT_PIN_MMCDATA3, "mmc_data3"),
+	PINCTRL_PIN(WMT_PIN_SDCLK, "sd_clk"),
+	PINCTRL_PIN(WMT_PIN_SDWP, "sd_wp"),
+	PINCTRL_PIN(WMT_PIN_SDCMD, "sd_cmd"),
+	PINCTRL_PIN(WMT_PIN_MSDATA0, "ms_data0"),
+	PINCTRL_PIN(WMT_PIN_MSDATA1, "ms_data1"),
+	PINCTRL_PIN(WMT_PIN_MSDATA2, "ms_data2"),
+	PINCTRL_PIN(WMT_PIN_MSDATA3, "ms_data3"),
+	PINCTRL_PIN(WMT_PIN_MSCLK, "ms_clk"),
+	PINCTRL_PIN(WMT_PIN_MSBS, "ms_bs"),
+	PINCTRL_PIN(WMT_PIN_MSINS, "ms_ins"),
+	PINCTRL_PIN(WMT_PIN_I2C0SCL, "i2c0_scl"),
+	PINCTRL_PIN(WMT_PIN_I2C0SDA, "i2c0_sda"),
+	PINCTRL_PIN(WMT_PIN_I2C1SCL, "i2c1_scl"),
+	PINCTRL_PIN(WMT_PIN_I2C1SDA, "i2c1_sda"),
+	PINCTRL_PIN(WMT_PIN_MII0RXD0, "mii0_rxd0"),
+	PINCTRL_PIN(WMT_PIN_MII0RXD1, "mii0_rxd1"),
+	PINCTRL_PIN(WMT_PIN_MII0RXD2, "mii0_rxd2"),
+	PINCTRL_PIN(WMT_PIN_MII0RXD3, "mii0_rxd3"),
+	PINCTRL_PIN(WMT_PIN_MII0RXCLK, "mii0_rxclk"),
+	PINCTRL_PIN(WMT_PIN_MII0RXDV, "mii0_rxdv"),
+	PINCTRL_PIN(WMT_PIN_MII0RXERR, "mii0_rxerr"),
+	PINCTRL_PIN(WMT_PIN_MII0PHYRST, "mii0_phyrst"),
+	PINCTRL_PIN(WMT_PIN_MII0TXD0, "mii0_txd0"),
+	PINCTRL_PIN(WMT_PIN_MII0TXD1, "mii0_txd1"),
+	PINCTRL_PIN(WMT_PIN_MII0TXD2, "mii0_txd2"),
+	PINCTRL_PIN(WMT_PIN_MII0TXD3, "mii0_txd3"),
+	PINCTRL_PIN(WMT_PIN_MII0TXCLK, "mii0_txclk"),
+	PINCTRL_PIN(WMT_PIN_MII0TXEN, "mii0_txen"),
+	PINCTRL_PIN(WMT_PIN_MII0TXERR, "mii0_txerr"),
+	PINCTRL_PIN(WMT_PIN_MII0PHYPD, "mii0_phypd"),
+	PINCTRL_PIN(WMT_PIN_MII0COL, "mii0_col"),
+	PINCTRL_PIN(WMT_PIN_MII0CRS, "mii0_crs"),
+	PINCTRL_PIN(WMT_PIN_MII0MDIO, "mii0_mdio"),
+	PINCTRL_PIN(WMT_PIN_MII0MDC, "mii0_mdc"),
+	PINCTRL_PIN(WMT_PIN_SEECS, "see_cs"),
+	PINCTRL_PIN(WMT_PIN_SEECK, "see_ck"),
+	PINCTRL_PIN(WMT_PIN_SEEDI, "see_di"),
+	PINCTRL_PIN(WMT_PIN_SEEDO, "see_do"),
+	PINCTRL_PIN(WMT_PIN_IDEDREQ0, "ide_dreq0"),
+	PINCTRL_PIN(WMT_PIN_IDEDREQ1, "ide_dreq1"),
+	PINCTRL_PIN(WMT_PIN_IDEIOW, "ide_iow"),
+	PINCTRL_PIN(WMT_PIN_IDEIOR, "ide_ior"),
+	PINCTRL_PIN(WMT_PIN_IDEDACK, "ide_dack"),
+	PINCTRL_PIN(WMT_PIN_IDEIORDY, "ide_iordy"),
+	PINCTRL_PIN(WMT_PIN_IDEINTRQ, "ide_intrq"),
+	PINCTRL_PIN(WMT_PIN_VDIN0, "vdin0"),
+	PINCTRL_PIN(WMT_PIN_VDIN1, "vdin1"),
+	PINCTRL_PIN(WMT_PIN_VDIN2, "vdin2"),
+	PINCTRL_PIN(WMT_PIN_VDIN3, "vdin3"),
+	PINCTRL_PIN(WMT_PIN_VDIN4, "vdin4"),
+	PINCTRL_PIN(WMT_PIN_VDIN5, "vdin5"),
+	PINCTRL_PIN(WMT_PIN_VDIN6, "vdin6"),
+	PINCTRL_PIN(WMT_PIN_VDIN7, "vdin7"),
+	PINCTRL_PIN(WMT_PIN_VDOUT0, "vdout0"),
+	PINCTRL_PIN(WMT_PIN_VDOUT1, "vdout1"),
+	PINCTRL_PIN(WMT_PIN_VDOUT2, "vdout2"),
+	PINCTRL_PIN(WMT_PIN_VDOUT3, "vdout3"),
+	PINCTRL_PIN(WMT_PIN_VDOUT4, "vdout4"),
+	PINCTRL_PIN(WMT_PIN_VDOUT5, "vdout5"),
+	PINCTRL_PIN(WMT_PIN_NANDCLE0, "nand_cle0"),
+	PINCTRL_PIN(WMT_PIN_NANDCLE1, "nand_cle1"),
+	PINCTRL_PIN(WMT_PIN_VDOUT6_7, "vdout6_7"),
+	PINCTRL_PIN(WMT_PIN_VHSYNC, "vhsync"),
+	PINCTRL_PIN(WMT_PIN_VVSYNC, "vvsync"),
+	PINCTRL_PIN(WMT_PIN_TSDIN0, "tsdin0"),
+	PINCTRL_PIN(WMT_PIN_TSDIN1, "tsdin1"),
+	PINCTRL_PIN(WMT_PIN_TSDIN2, "tsdin2"),
+	PINCTRL_PIN(WMT_PIN_TSDIN3, "tsdin3"),
+	PINCTRL_PIN(WMT_PIN_TSDIN4, "tsdin4"),
+	PINCTRL_PIN(WMT_PIN_TSDIN5, "tsdin5"),
+	PINCTRL_PIN(WMT_PIN_TSDIN6, "tsdin6"),
+	PINCTRL_PIN(WMT_PIN_TSDIN7, "tsdin7"),
+	PINCTRL_PIN(WMT_PIN_TSSYNC, "tssync"),
+	PINCTRL_PIN(WMT_PIN_TSVALID, "tsvalid"),
+	PINCTRL_PIN(WMT_PIN_TSCLK, "tsclk"),
+	PINCTRL_PIN(WMT_PIN_LCDD0, "lcd_d0"),
+	PINCTRL_PIN(WMT_PIN_LCDD1, "lcd_d1"),
+	PINCTRL_PIN(WMT_PIN_LCDD2, "lcd_d2"),
+	PINCTRL_PIN(WMT_PIN_LCDD3, "lcd_d3"),
+	PINCTRL_PIN(WMT_PIN_LCDD4, "lcd_d4"),
+	PINCTRL_PIN(WMT_PIN_LCDD5, "lcd_d5"),
+	PINCTRL_PIN(WMT_PIN_LCDD6, "lcd_d6"),
+	PINCTRL_PIN(WMT_PIN_LCDD7, "lcd_d7"),
+	PINCTRL_PIN(WMT_PIN_LCDD8, "lcd_d8"),
+	PINCTRL_PIN(WMT_PIN_LCDD9, "lcd_d9"),
+	PINCTRL_PIN(WMT_PIN_LCDD10, "lcd_d10"),
+	PINCTRL_PIN(WMT_PIN_LCDD11, "lcd_d11"),
+	PINCTRL_PIN(WMT_PIN_LCDD12, "lcd_d12"),
+	PINCTRL_PIN(WMT_PIN_LCDD13, "lcd_d13"),
+	PINCTRL_PIN(WMT_PIN_LCDD14, "lcd_d14"),
+	PINCTRL_PIN(WMT_PIN_LCDD15, "lcd_d15"),
+	PINCTRL_PIN(WMT_PIN_LCDD16, "lcd_d16"),
+	PINCTRL_PIN(WMT_PIN_LCDD17, "lcd_d17"),
+	PINCTRL_PIN(WMT_PIN_LCDCLK, "lcd_clk"),
+	PINCTRL_PIN(WMT_PIN_LCDDEN, "lcd_den"),
+	PINCTRL_PIN(WMT_PIN_LCDLINE, "lcd_line"),
+	PINCTRL_PIN(WMT_PIN_LCDFRM, "lcd_frm"),
+	PINCTRL_PIN(WMT_PIN_LCDBIAS, "lcd_bias"),
+};
+
+/* Order of these names must match the above list */
+static const char * const vt8500_groups[] = {
+	"extgpio0",
+	"extgpio1",
+	"extgpio2",
+	"extgpio3",
+	"extgpio4",
+	"extgpio5",
+	"extgpio6",
+	"extgpio7",
+	"extgpio8",
+	"uart0_rts",
+	"uart0_txd",
+	"uart0_cts",
+	"uart0_rxd",
+	"uart1_rts",
+	"uart1_txd",
+	"uart1_cts",
+	"uart1_rxd",
+	"spi0_clk",
+	"spi0_ss",
+	"spi0_miso",
+	"spi0_mosi",
+	"spi1_clk",
+	"spi1_ss",
+	"spi1_miso",
+	"spi1_mosi",
+	"spi2_clk",
+	"spi2_ss",
+	"spi2_miso",
+	"spi2_mosi",
+	"sd_data0",
+	"sd_data1",
+	"sd_data2",
+	"sd_data3",
+	"mmc_data0",
+	"mmc_data1",
+	"mmc_data2",
+	"mmc_data3",
+	"sd_clk",
+	"sd_wp",
+	"sd_cmd",
+	"ms_data0",
+	"ms_data1",
+	"ms_data2",
+	"ms_data3",
+	"ms_clk",
+	"ms_bs",
+	"ms_ins",
+	"i2c0_scl",
+	"i2c0_sda",
+	"i2c1_scl",
+	"i2c1_sda",
+	"mii0_rxd0",
+	"mii0_rxd1",
+	"mii0_rxd2",
+	"mii0_rxd3",
+	"mii0_rxclk",
+	"mii0_rxdv",
+	"mii0_rxerr",
+	"mii0_phyrst",
+	"mii0_txd0",
+	"mii0_txd1",
+	"mii0_txd2",
+	"mii0_txd3",
+	"mii0_txclk",
+	"mii0_txen",
+	"mii0_txerr",
+	"mii0_phypd",
+	"mii0_col",
+	"mii0_crs",
+	"mii0_mdio",
+	"mii0_mdc",
+	"see_cs",
+	"see_ck",
+	"see_di",
+	"see_do",
+	"ide_dreq0",
+	"ide_dreq1",
+	"ide_iow",
+	"ide_ior",
+	"ide_dack",
+	"ide_iordy",
+	"ide_intrq",
+	"vdin0",
+	"vdin1",
+	"vdin2",
+	"vdin3",
+	"vdin4",
+	"vdin5",
+	"vdin6",
+	"vdin7",
+	"vdout0",
+	"vdout1",
+	"vdout2",
+	"vdout3",
+	"vdout4",
+	"vdout5",
+	"nand_cle0",
+	"nand_cle1",
+	"vdout6_7",
+	"vhsync",
+	"vvsync",
+	"tsdin0",
+	"tsdin1",
+	"tsdin2",
+	"tsdin3",
+	"tsdin4",
+	"tsdin5",
+	"tsdin6",
+	"tsdin7",
+	"tssync",
+	"tsvalid",
+	"tsclk",
+	"lcd_d0",
+	"lcd_d1",
+	"lcd_d2",
+	"lcd_d3",
+	"lcd_d4",
+	"lcd_d5",
+	"lcd_d6",
+	"lcd_d7",
+	"lcd_d8",
+	"lcd_d9",
+	"lcd_d10",
+	"lcd_d11",
+	"lcd_d12",
+	"lcd_d13",
+	"lcd_d14",
+	"lcd_d15",
+	"lcd_d16",
+	"lcd_d17",
+	"lcd_clk",
+	"lcd_den",
+	"lcd_line",
+	"lcd_frm",
+	"lcd_bias",
+};
+
+static int vt8500_pinctrl_probe(struct platform_device *pdev)
+{
+	struct wmt_pinctrl_data *data;
+
+	data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
+	if (!data) {
+		dev_err(&pdev->dev, "failed to allocate data\n");
+		return -ENOMEM;
+	}
+
+	data->banks = vt8500_banks;
+	data->nbanks = ARRAY_SIZE(vt8500_banks);
+	data->pins = vt8500_pins;
+	data->npins = ARRAY_SIZE(vt8500_pins);
+	data->groups = vt8500_groups;
+	data->ngroups = ARRAY_SIZE(vt8500_groups);
+
+	return wmt_pinctrl_probe(pdev, data);
+}
+
+static int vt8500_pinctrl_remove(struct platform_device *pdev)
+{
+	return wmt_pinctrl_remove(pdev);
+}
+
+static struct of_device_id wmt_pinctrl_of_match[] = {
+	{ .compatible = "via,vt8500-pinctrl" },
+	{ /* sentinel */ },
+};
+
+static struct platform_driver wmt_pinctrl_driver = {
+	.probe	= vt8500_pinctrl_probe,
+	.remove	= vt8500_pinctrl_remove,
+	.driver = {
+		.name	= "pinctrl-vt8500",
+		.owner	= THIS_MODULE,
+		.of_match_table	= wmt_pinctrl_of_match,
+	},
+};
+
+module_platform_driver(wmt_pinctrl_driver);
+
+MODULE_AUTHOR("Tony Prisk <linux at prisktech.co.nz>");
+MODULE_DESCRIPTION("VIA VT8500 Pincontrol driver");
+MODULE_LICENSE("GPL v2");
+MODULE_DEVICE_TABLE(of, wmt_pinctrl_of_match);
diff --git a/drivers/pinctrl/vt8500/pinctrl-wm8505.c b/drivers/pinctrl/vt8500/pinctrl-wm8505.c
new file mode 100644
index 0000000..483ba73
--- /dev/null
+++ b/drivers/pinctrl/vt8500/pinctrl-wm8505.c
@@ -0,0 +1,532 @@
+/*
+ * Pinctrl data for Wondermedia WM8505 SoC
+ *
+ * Copyright (c) 2013 Tony Prisk <linux at prisktech.co.nz>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ */
+
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/pinctrl/pinctrl.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+
+#include "pinctrl-wmt.h"
+
+/*
+ * Describe the register offsets within the GPIO memory space
+ * The dedicated external GPIO's should always be listed in bank 0
+ * so they are exported in the 0..31 range which is what users
+ * expect.
+ *
+ * Do not reorder these banks as it will change the pin numbering
+ */
+static const struct wmt_pinctrl_bank_registers wm8505_banks[] = {
+	WMT_PINCTRL_BANK(0x64, 0x8C, 0xB4, 0xDC, NO_REG, NO_REG),	/* 0 */
+	WMT_PINCTRL_BANK(0x40, 0x68, 0x90, 0xB8, NO_REG, NO_REG),	/* 1 */
+	WMT_PINCTRL_BANK(0x44, 0x6C, 0x94, 0xBC, NO_REG, NO_REG),	/* 2 */
+	WMT_PINCTRL_BANK(0x48, 0x70, 0x98, 0xC0, NO_REG, NO_REG),	/* 3 */
+	WMT_PINCTRL_BANK(0x4C, 0x74, 0x9C, 0xC4, NO_REG, NO_REG),	/* 4 */
+	WMT_PINCTRL_BANK(0x50, 0x78, 0xA0, 0xC8, NO_REG, NO_REG),	/* 5 */
+	WMT_PINCTRL_BANK(0x54, 0x7C, 0xA4, 0xD0, NO_REG, NO_REG),	/* 6 */
+	WMT_PINCTRL_BANK(0x58, 0x80, 0xA8, 0xD4, NO_REG, NO_REG),	/* 7 */
+	WMT_PINCTRL_BANK(0x5C, 0x84, 0xAC, 0xD8, NO_REG, NO_REG),	/* 8 */
+	WMT_PINCTRL_BANK(0x60, 0x88, 0xB0, 0xDC, NO_REG, NO_REG),	/* 9 */
+	WMT_PINCTRL_BANK(0x500, 0x504, 0x508, 0x50C, NO_REG, NO_REG),	/* 10 */
+};
+
+/* Please keep sorted by bank/bit */
+#define WMT_PIN_EXTGPIO0	WMT_PIN(0, 0)
+#define WMT_PIN_EXTGPIO1	WMT_PIN(0, 1)
+#define WMT_PIN_EXTGPIO2	WMT_PIN(0, 2)
+#define WMT_PIN_EXTGPIO3	WMT_PIN(0, 3)
+#define WMT_PIN_EXTGPIO4	WMT_PIN(0, 4)
+#define WMT_PIN_EXTGPIO5	WMT_PIN(0, 5)
+#define WMT_PIN_EXTGPIO6	WMT_PIN(0, 6)
+#define WMT_PIN_EXTGPIO7	WMT_PIN(0, 7)
+#define WMT_PIN_WAKEUP0		WMT_PIN(0, 16)
+#define WMT_PIN_WAKEUP1		WMT_PIN(0, 17)
+#define WMT_PIN_WAKEUP2		WMT_PIN(0, 18)
+#define WMT_PIN_WAKEUP3		WMT_PIN(0, 19)
+#define WMT_PIN_SUSGPIO0	WMT_PIN(0, 21)
+#define WMT_PIN_SDDATA0		WMT_PIN(1, 0)
+#define WMT_PIN_SDDATA1		WMT_PIN(1, 1)
+#define WMT_PIN_SDDATA2		WMT_PIN(1, 2)
+#define WMT_PIN_SDDATA3		WMT_PIN(1, 3)
+#define WMT_PIN_MMCDATA0	WMT_PIN(1, 4)
+#define WMT_PIN_MMCDATA1	WMT_PIN(1, 5)
+#define WMT_PIN_MMCDATA2	WMT_PIN(1, 6)
+#define WMT_PIN_MMCDATA3	WMT_PIN(1, 7)
+#define WMT_PIN_VDIN0		WMT_PIN(2, 0)
+#define WMT_PIN_VDIN1		WMT_PIN(2, 1)
+#define WMT_PIN_VDIN2		WMT_PIN(2, 2)
+#define WMT_PIN_VDIN3		WMT_PIN(2, 3)
+#define WMT_PIN_VDIN4		WMT_PIN(2, 4)
+#define WMT_PIN_VDIN5		WMT_PIN(2, 5)
+#define WMT_PIN_VDIN6		WMT_PIN(2, 6)
+#define WMT_PIN_VDIN7		WMT_PIN(2, 7)
+#define WMT_PIN_VDOUT0		WMT_PIN(2, 8)
+#define WMT_PIN_VDOUT1		WMT_PIN(2, 9)
+#define WMT_PIN_VDOUT2		WMT_PIN(2, 10)
+#define WMT_PIN_VDOUT3		WMT_PIN(2, 11)
+#define WMT_PIN_VDOUT4		WMT_PIN(2, 12)
+#define WMT_PIN_VDOUT5		WMT_PIN(2, 13)
+#define WMT_PIN_VDOUT6		WMT_PIN(2, 14)
+#define WMT_PIN_VDOUT7		WMT_PIN(2, 15)
+#define WMT_PIN_VDOUT8		WMT_PIN(2, 16)
+#define WMT_PIN_VDOUT9		WMT_PIN(2, 17)
+#define WMT_PIN_VDOUT10		WMT_PIN(2, 18)
+#define WMT_PIN_VDOUT11		WMT_PIN(2, 19)
+#define WMT_PIN_VDOUT12		WMT_PIN(2, 20)
+#define WMT_PIN_VDOUT13		WMT_PIN(2, 21)
+#define WMT_PIN_VDOUT14		WMT_PIN(2, 22)
+#define WMT_PIN_VDOUT15		WMT_PIN(2, 23)
+#define WMT_PIN_VDOUT16		WMT_PIN(2, 24)
+#define WMT_PIN_VDOUT17		WMT_PIN(2, 25)
+#define WMT_PIN_VDOUT18		WMT_PIN(2, 26)
+#define WMT_PIN_VDOUT19		WMT_PIN(2, 27)
+#define WMT_PIN_VDOUT20		WMT_PIN(2, 28)
+#define WMT_PIN_VDOUT21		WMT_PIN(2, 29)
+#define WMT_PIN_VDOUT22		WMT_PIN(2, 30)
+#define WMT_PIN_VDOUT23		WMT_PIN(2, 31)
+#define WMT_PIN_VHSYNC		WMT_PIN(3, 0)
+#define WMT_PIN_VVSYNC		WMT_PIN(3, 1)
+#define WMT_PIN_VGAHSYNC	WMT_PIN(3, 2)
+#define WMT_PIN_VGAVSYNC	WMT_PIN(3, 3)
+#define WMT_PIN_VDHSYNC		WMT_PIN(3, 4)
+#define WMT_PIN_VDVSYNC		WMT_PIN(3, 5)
+#define WMT_PIN_NORD0		WMT_PIN(4, 0)
+#define WMT_PIN_NORD1		WMT_PIN(4, 1)
+#define WMT_PIN_NORD2		WMT_PIN(4, 2)
+#define WMT_PIN_NORD3		WMT_PIN(4, 3)
+#define WMT_PIN_NORD4		WMT_PIN(4, 4)
+#define WMT_PIN_NORD5		WMT_PIN(4, 5)
+#define WMT_PIN_NORD6		WMT_PIN(4, 6)
+#define WMT_PIN_NORD7		WMT_PIN(4, 7)
+#define WMT_PIN_NORD8		WMT_PIN(4, 8)
+#define WMT_PIN_NORD9		WMT_PIN(4, 9)
+#define WMT_PIN_NORD10		WMT_PIN(4, 10)
+#define WMT_PIN_NORD11		WMT_PIN(4, 11)
+#define WMT_PIN_NORD12		WMT_PIN(4, 12)
+#define WMT_PIN_NORD13		WMT_PIN(4, 13)
+#define WMT_PIN_NORD14		WMT_PIN(4, 14)
+#define WMT_PIN_NORD15		WMT_PIN(4, 15)
+#define WMT_PIN_NORA0		WMT_PIN(5, 0)
+#define WMT_PIN_NORA1		WMT_PIN(5, 1)
+#define WMT_PIN_NORA2		WMT_PIN(5, 2)
+#define WMT_PIN_NORA3		WMT_PIN(5, 3)
+#define WMT_PIN_NORA4		WMT_PIN(5, 4)
+#define WMT_PIN_NORA5		WMT_PIN(5, 5)
+#define WMT_PIN_NORA6		WMT_PIN(5, 6)
+#define WMT_PIN_NORA7		WMT_PIN(5, 7)
+#define WMT_PIN_NORA8		WMT_PIN(5, 8)
+#define WMT_PIN_NORA9		WMT_PIN(5, 9)
+#define WMT_PIN_NORA10		WMT_PIN(5, 10)
+#define WMT_PIN_NORA11		WMT_PIN(5, 11)
+#define WMT_PIN_NORA12		WMT_PIN(5, 12)
+#define WMT_PIN_NORA13		WMT_PIN(5, 13)
+#define WMT_PIN_NORA14		WMT_PIN(5, 14)
+#define WMT_PIN_NORA15		WMT_PIN(5, 15)
+#define WMT_PIN_NORA16		WMT_PIN(5, 16)
+#define WMT_PIN_NORA17		WMT_PIN(5, 17)
+#define WMT_PIN_NORA18		WMT_PIN(5, 18)
+#define WMT_PIN_NORA19		WMT_PIN(5, 19)
+#define WMT_PIN_NORA20		WMT_PIN(5, 20)
+#define WMT_PIN_NORA21		WMT_PIN(5, 21)
+#define WMT_PIN_NORA22		WMT_PIN(5, 22)
+#define WMT_PIN_NORA23		WMT_PIN(5, 23)
+#define WMT_PIN_NORA24		WMT_PIN(5, 24)
+#define WMT_PIN_AC97SDI		WMT_PIN(6, 0)
+#define WMT_PIN_AC97SYNC	WMT_PIN(6, 1)
+#define WMT_PIN_AC97SDO		WMT_PIN(6, 2)
+#define WMT_PIN_AC97BCLK	WMT_PIN(6, 3)
+#define WMT_PIN_AC97RST		WMT_PIN(6, 4)
+#define WMT_PIN_SFDO		WMT_PIN(7, 0)
+#define WMT_PIN_SFCS0		WMT_PIN(7, 1)
+#define WMT_PIN_SFCS1		WMT_PIN(7, 2)
+#define WMT_PIN_SFCLK		WMT_PIN(7, 3)
+#define WMT_PIN_SFDI		WMT_PIN(7, 4)
+#define WMT_PIN_SPI0CLK		WMT_PIN(8, 0)
+#define WMT_PIN_SPI0MISO	WMT_PIN(8, 1)
+#define WMT_PIN_SPI0MOSI	WMT_PIN(8, 2)
+#define WMT_PIN_SPI0SS		WMT_PIN(8, 3)
+#define WMT_PIN_SPI1CLK		WMT_PIN(8, 4)
+#define WMT_PIN_SPI1MISO	WMT_PIN(8, 5)
+#define WMT_PIN_SPI1MOSI	WMT_PIN(8, 6)
+#define WMT_PIN_SPI1SS		WMT_PIN(8, 7)
+#define WMT_PIN_SPI2CLK		WMT_PIN(8, 8)
+#define WMT_PIN_SPI2MISO	WMT_PIN(8, 9)
+#define WMT_PIN_SPI2MOSI	WMT_PIN(8, 10)
+#define WMT_PIN_SPI2SS		WMT_PIN(8, 11)
+#define WMT_PIN_UART0_RTS	WMT_PIN(9, 0)
+#define WMT_PIN_UART0_TXD	WMT_PIN(9, 1)
+#define WMT_PIN_UART0_CTS	WMT_PIN(9, 2)
+#define WMT_PIN_UART0_RXD	WMT_PIN(9, 3)
+#define WMT_PIN_UART1_RTS	WMT_PIN(9, 4)
+#define WMT_PIN_UART1_TXD	WMT_PIN(9, 5)
+#define WMT_PIN_UART1_CTS	WMT_PIN(9, 6)
+#define WMT_PIN_UART1_RXD	WMT_PIN(9, 7)
+#define WMT_PIN_UART2_RTS	WMT_PIN(9, 8)
+#define WMT_PIN_UART2_TXD	WMT_PIN(9, 9)
+#define WMT_PIN_UART2_CTS	WMT_PIN(9, 10)
+#define WMT_PIN_UART2_RXD	WMT_PIN(9, 11)
+#define WMT_PIN_UART3_RTS	WMT_PIN(9, 12)
+#define WMT_PIN_UART3_TXD	WMT_PIN(9, 13)
+#define WMT_PIN_UART3_CTS	WMT_PIN(9, 14)
+#define WMT_PIN_UART3_RXD	WMT_PIN(9, 15)
+#define WMT_PIN_I2C0SCL		WMT_PIN(10, 0)
+#define WMT_PIN_I2C0SDA		WMT_PIN(10, 1)
+#define WMT_PIN_I2C1SCL		WMT_PIN(10, 2)
+#define WMT_PIN_I2C1SDA		WMT_PIN(10, 3)
+#define WMT_PIN_I2C2SCL		WMT_PIN(10, 4)
+#define WMT_PIN_I2C2SDA		WMT_PIN(10, 5)
+
+static const struct pinctrl_pin_desc wm8505_pins[] = {
+	PINCTRL_PIN(WMT_PIN_EXTGPIO0, "extgpio0"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO1, "extgpio1"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO2, "extgpio2"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO3, "extgpio3"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO4, "extgpio4"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO5, "extgpio5"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO6, "extgpio6"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO7, "extgpio7"),
+	PINCTRL_PIN(WMT_PIN_WAKEUP0, "wakeup0"),
+	PINCTRL_PIN(WMT_PIN_WAKEUP1, "wakeup1"),
+	PINCTRL_PIN(WMT_PIN_WAKEUP2, "wakeup2"),
+	PINCTRL_PIN(WMT_PIN_WAKEUP3, "wakeup3"),
+	PINCTRL_PIN(WMT_PIN_SUSGPIO0, "susgpio0"),
+	PINCTRL_PIN(WMT_PIN_SDDATA0, "sd_data0"),
+	PINCTRL_PIN(WMT_PIN_SDDATA1, "sd_data1"),
+	PINCTRL_PIN(WMT_PIN_SDDATA2, "sd_data2"),
+	PINCTRL_PIN(WMT_PIN_SDDATA3, "sd_data3"),
+	PINCTRL_PIN(WMT_PIN_MMCDATA0, "mmc_data0"),
+	PINCTRL_PIN(WMT_PIN_MMCDATA1, "mmc_data1"),
+	PINCTRL_PIN(WMT_PIN_MMCDATA2, "mmc_data2"),
+	PINCTRL_PIN(WMT_PIN_MMCDATA3, "mmc_data3"),
+	PINCTRL_PIN(WMT_PIN_VDIN0, "vdin0"),
+	PINCTRL_PIN(WMT_PIN_VDIN1, "vdin1"),
+	PINCTRL_PIN(WMT_PIN_VDIN2, "vdin2"),
+	PINCTRL_PIN(WMT_PIN_VDIN3, "vdin3"),
+	PINCTRL_PIN(WMT_PIN_VDIN4, "vdin4"),
+	PINCTRL_PIN(WMT_PIN_VDIN5, "vdin5"),
+	PINCTRL_PIN(WMT_PIN_VDIN6, "vdin6"),
+	PINCTRL_PIN(WMT_PIN_VDIN7, "vdin7"),
+	PINCTRL_PIN(WMT_PIN_VDOUT0, "vdout0"),
+	PINCTRL_PIN(WMT_PIN_VDOUT1, "vdout1"),
+	PINCTRL_PIN(WMT_PIN_VDOUT2, "vdout2"),
+	PINCTRL_PIN(WMT_PIN_VDOUT3, "vdout3"),
+	PINCTRL_PIN(WMT_PIN_VDOUT4, "vdout4"),
+	PINCTRL_PIN(WMT_PIN_VDOUT5, "vdout5"),
+	PINCTRL_PIN(WMT_PIN_VDOUT6, "vdout6"),
+	PINCTRL_PIN(WMT_PIN_VDOUT7, "vdout7"),
+	PINCTRL_PIN(WMT_PIN_VDOUT8, "vdout8"),
+	PINCTRL_PIN(WMT_PIN_VDOUT9, "vdout9"),
+	PINCTRL_PIN(WMT_PIN_VDOUT10, "vdout10"),
+	PINCTRL_PIN(WMT_PIN_VDOUT11, "vdout11"),
+	PINCTRL_PIN(WMT_PIN_VDOUT12, "vdout12"),
+	PINCTRL_PIN(WMT_PIN_VDOUT13, "vdout13"),
+	PINCTRL_PIN(WMT_PIN_VDOUT14, "vdout14"),
+	PINCTRL_PIN(WMT_PIN_VDOUT15, "vdout15"),
+	PINCTRL_PIN(WMT_PIN_VDOUT16, "vdout16"),
+	PINCTRL_PIN(WMT_PIN_VDOUT17, "vdout17"),
+	PINCTRL_PIN(WMT_PIN_VDOUT18, "vdout18"),
+	PINCTRL_PIN(WMT_PIN_VDOUT19, "vdout19"),
+	PINCTRL_PIN(WMT_PIN_VDOUT20, "vdout20"),
+	PINCTRL_PIN(WMT_PIN_VDOUT21, "vdout21"),
+	PINCTRL_PIN(WMT_PIN_VDOUT22, "vdout22"),
+	PINCTRL_PIN(WMT_PIN_VDOUT23, "vdout23"),
+	PINCTRL_PIN(WMT_PIN_VHSYNC, "v_hsync"),
+	PINCTRL_PIN(WMT_PIN_VVSYNC, "v_vsync"),
+	PINCTRL_PIN(WMT_PIN_VGAHSYNC, "vga_hsync"),
+	PINCTRL_PIN(WMT_PIN_VGAVSYNC, "vga_vsync"),
+	PINCTRL_PIN(WMT_PIN_VDHSYNC, "vd_hsync"),
+	PINCTRL_PIN(WMT_PIN_VDVSYNC, "vd_vsync"),
+	PINCTRL_PIN(WMT_PIN_NORD0, "nor_d0"),
+	PINCTRL_PIN(WMT_PIN_NORD1, "nor_d1"),
+	PINCTRL_PIN(WMT_PIN_NORD2, "nor_d2"),
+	PINCTRL_PIN(WMT_PIN_NORD3, "nor_d3"),
+	PINCTRL_PIN(WMT_PIN_NORD4, "nor_d4"),
+	PINCTRL_PIN(WMT_PIN_NORD5, "nor_d5"),
+	PINCTRL_PIN(WMT_PIN_NORD6, "nor_d6"),
+	PINCTRL_PIN(WMT_PIN_NORD7, "nor_d7"),
+	PINCTRL_PIN(WMT_PIN_NORD8, "nor_d8"),
+	PINCTRL_PIN(WMT_PIN_NORD9, "nor_d9"),
+	PINCTRL_PIN(WMT_PIN_NORD10, "nor_d10"),
+	PINCTRL_PIN(WMT_PIN_NORD11, "nor_d11"),
+	PINCTRL_PIN(WMT_PIN_NORD12, "nor_d12"),
+	PINCTRL_PIN(WMT_PIN_NORD13, "nor_d13"),
+	PINCTRL_PIN(WMT_PIN_NORD14, "nor_d14"),
+	PINCTRL_PIN(WMT_PIN_NORD15, "nor_d15"),
+	PINCTRL_PIN(WMT_PIN_NORA0, "nor_a0"),
+	PINCTRL_PIN(WMT_PIN_NORA1, "nor_a1"),
+	PINCTRL_PIN(WMT_PIN_NORA2, "nor_a2"),
+	PINCTRL_PIN(WMT_PIN_NORA3, "nor_a3"),
+	PINCTRL_PIN(WMT_PIN_NORA4, "nor_a4"),
+	PINCTRL_PIN(WMT_PIN_NORA5, "nor_a5"),
+	PINCTRL_PIN(WMT_PIN_NORA6, "nor_a6"),
+	PINCTRL_PIN(WMT_PIN_NORA7, "nor_a7"),
+	PINCTRL_PIN(WMT_PIN_NORA8, "nor_a8"),
+	PINCTRL_PIN(WMT_PIN_NORA9, "nor_a9"),
+	PINCTRL_PIN(WMT_PIN_NORA10, "nor_a10"),
+	PINCTRL_PIN(WMT_PIN_NORA11, "nor_a11"),
+	PINCTRL_PIN(WMT_PIN_NORA12, "nor_a12"),
+	PINCTRL_PIN(WMT_PIN_NORA13, "nor_a13"),
+	PINCTRL_PIN(WMT_PIN_NORA14, "nor_a14"),
+	PINCTRL_PIN(WMT_PIN_NORA15, "nor_a15"),
+	PINCTRL_PIN(WMT_PIN_NORA16, "nor_a16"),
+	PINCTRL_PIN(WMT_PIN_NORA17, "nor_a17"),
+	PINCTRL_PIN(WMT_PIN_NORA18, "nor_a18"),
+	PINCTRL_PIN(WMT_PIN_NORA19, "nor_a19"),
+	PINCTRL_PIN(WMT_PIN_NORA20, "nor_a20"),
+	PINCTRL_PIN(WMT_PIN_NORA21, "nor_a21"),
+	PINCTRL_PIN(WMT_PIN_NORA22, "nor_a22"),
+	PINCTRL_PIN(WMT_PIN_NORA23, "nor_a23"),
+	PINCTRL_PIN(WMT_PIN_NORA24, "nor_a24"),
+	PINCTRL_PIN(WMT_PIN_AC97SDI, "ac97_sdi"),
+	PINCTRL_PIN(WMT_PIN_AC97SYNC, "ac97_sync"),
+	PINCTRL_PIN(WMT_PIN_AC97SDO, "ac97_sdo"),
+	PINCTRL_PIN(WMT_PIN_AC97BCLK, "ac97_bclk"),
+	PINCTRL_PIN(WMT_PIN_AC97RST, "ac97_rst"),
+	PINCTRL_PIN(WMT_PIN_SFDO, "sf_do"),
+	PINCTRL_PIN(WMT_PIN_SFCS0, "sf_cs0"),
+	PINCTRL_PIN(WMT_PIN_SFCS1, "sf_cs1"),
+	PINCTRL_PIN(WMT_PIN_SFCLK, "sf_clk"),
+	PINCTRL_PIN(WMT_PIN_SFDI, "sf_di"),
+	PINCTRL_PIN(WMT_PIN_SPI0CLK, "spi0_clk"),
+	PINCTRL_PIN(WMT_PIN_SPI0MISO, "spi0_miso"),
+	PINCTRL_PIN(WMT_PIN_SPI0MOSI, "spi0_mosi"),
+	PINCTRL_PIN(WMT_PIN_SPI0SS, "spi0_ss"),
+	PINCTRL_PIN(WMT_PIN_SPI1CLK, "spi1_clk"),
+	PINCTRL_PIN(WMT_PIN_SPI1MISO, "spi1_miso"),
+	PINCTRL_PIN(WMT_PIN_SPI1MOSI, "spi1_mosi"),
+	PINCTRL_PIN(WMT_PIN_SPI1SS, "spi1_ss"),
+	PINCTRL_PIN(WMT_PIN_SPI2CLK, "spi2_clk"),
+	PINCTRL_PIN(WMT_PIN_SPI2MISO, "spi2_miso"),
+	PINCTRL_PIN(WMT_PIN_SPI2MOSI, "spi2_mosi"),
+	PINCTRL_PIN(WMT_PIN_SPI2SS, "spi2_ss"),
+	PINCTRL_PIN(WMT_PIN_UART0_RTS, "uart0_rts"),
+	PINCTRL_PIN(WMT_PIN_UART0_TXD, "uart0_txd"),
+	PINCTRL_PIN(WMT_PIN_UART0_CTS, "uart0_cts"),
+	PINCTRL_PIN(WMT_PIN_UART0_RXD, "uart0_rxd"),
+	PINCTRL_PIN(WMT_PIN_UART1_RTS, "uart1_rts"),
+	PINCTRL_PIN(WMT_PIN_UART1_TXD, "uart1_txd"),
+	PINCTRL_PIN(WMT_PIN_UART1_CTS, "uart1_cts"),
+	PINCTRL_PIN(WMT_PIN_UART1_RXD, "uart1_rxd"),
+	PINCTRL_PIN(WMT_PIN_UART2_RTS, "uart2_rts"),
+	PINCTRL_PIN(WMT_PIN_UART2_TXD, "uart2_txd"),
+	PINCTRL_PIN(WMT_PIN_UART2_CTS, "uart2_cts"),
+	PINCTRL_PIN(WMT_PIN_UART2_RXD, "uart2_rxd"),
+	PINCTRL_PIN(WMT_PIN_UART3_RTS, "uart3_rts"),
+	PINCTRL_PIN(WMT_PIN_UART3_TXD, "uart3_txd"),
+	PINCTRL_PIN(WMT_PIN_UART3_CTS, "uart3_cts"),
+	PINCTRL_PIN(WMT_PIN_UART3_RXD, "uart3_rxd"),
+	PINCTRL_PIN(WMT_PIN_I2C0SCL, "i2c0_scl"),
+	PINCTRL_PIN(WMT_PIN_I2C0SDA, "i2c0_sda"),
+	PINCTRL_PIN(WMT_PIN_I2C1SCL, "i2c1_scl"),
+	PINCTRL_PIN(WMT_PIN_I2C1SDA, "i2c1_sda"),
+	PINCTRL_PIN(WMT_PIN_I2C2SCL, "i2c2_scl"),
+	PINCTRL_PIN(WMT_PIN_I2C2SDA, "i2c2_sda"),
+};
+
+/* Order of these names must match the above list */
+static const char * const wm8505_groups[] = {
+	"extgpio0",
+	"extgpio1",
+	"extgpio2",
+	"extgpio3",
+	"extgpio4",
+	"extgpio5",
+	"extgpio6",
+	"extgpio7",
+	"wakeup0",
+	"wakeup1",
+	"wakeup2",
+	"wakeup3",
+	"susgpio0",
+	"sd_data0",
+	"sd_data1",
+	"sd_data2",
+	"sd_data3",
+	"mmc_data0",
+	"mmc_data1",
+	"mmc_data2",
+	"mmc_data3",
+	"vdin0",
+	"vdin1",
+	"vdin2",
+	"vdin3",
+	"vdin4",
+	"vdin5",
+	"vdin6",
+	"vdin7",
+	"vdout0",
+	"vdout1",
+	"vdout2",
+	"vdout3",
+	"vdout4",
+	"vdout5",
+	"vdout6",
+	"vdout7",
+	"vdout8",
+	"vdout9",
+	"vdout10",
+	"vdout11",
+	"vdout12",
+	"vdout13",
+	"vdout14",
+	"vdout15",
+	"vdout16",
+	"vdout17",
+	"vdout18",
+	"vdout19",
+	"vdout20",
+	"vdout21",
+	"vdout22",
+	"vdout23",
+	"v_hsync",
+	"v_vsync",
+	"vga_hsync",
+	"vga_vsync",
+	"vd_hsync",
+	"vd_vsync",
+	"nor_d0",
+	"nor_d1",
+	"nor_d2",
+	"nor_d3",
+	"nor_d4",
+	"nor_d5",
+	"nor_d6",
+	"nor_d7",
+	"nor_d8",
+	"nor_d9",
+	"nor_d10",
+	"nor_d11",
+	"nor_d12",
+	"nor_d13",
+	"nor_d14",
+	"nor_d15",
+	"nor_a0",
+	"nor_a1",
+	"nor_a2",
+	"nor_a3",
+	"nor_a4",
+	"nor_a5",
+	"nor_a6",
+	"nor_a7",
+	"nor_a8",
+	"nor_a9",
+	"nor_a10",
+	"nor_a11",
+	"nor_a12",
+	"nor_a13",
+	"nor_a14",
+	"nor_a15",
+	"nor_a16",
+	"nor_a17",
+	"nor_a18",
+	"nor_a19",
+	"nor_a20",
+	"nor_a21",
+	"nor_a22",
+	"nor_a23",
+	"nor_a24",
+	"ac97_sdi",
+	"ac97_sync",
+	"ac97_sdo",
+	"ac97_bclk",
+	"ac97_rst",
+	"sf_do",
+	"sf_cs0",
+	"sf_cs1",
+	"sf_clk",
+	"sf_di",
+	"spi0_clk",
+	"spi0_miso",
+	"spi0_mosi",
+	"spi0_ss",
+	"spi1_clk",
+	"spi1_miso",
+	"spi1_mosi",
+	"spi1_ss",
+	"spi2_clk",
+	"spi2_miso",
+	"spi2_mosi",
+	"spi2_ss",
+	"uart0_rts",
+	"uart0_txd",
+	"uart0_cts",
+	"uart0_rxd",
+	"uart1_rts",
+	"uart1_txd",
+	"uart1_cts",
+	"uart1_rxd",
+	"uart2_rts",
+	"uart2_txd",
+	"uart2_cts",
+	"uart2_rxd",
+	"uart3_rts",
+	"uart3_txd",
+	"uart3_cts",
+	"uart3_rxd",
+	"i2c0_scl",
+	"i2c0_sda",
+	"i2c1_scl",
+	"i2c1_sda",
+	"i2c2_scl",
+	"i2c2_sda",
+};
+
+static int wm8505_pinctrl_probe(struct platform_device *pdev)
+{
+	struct wmt_pinctrl_data *data;
+
+	data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
+	if (!data) {
+		dev_err(&pdev->dev, "failed to allocate data\n");
+		return -ENOMEM;
+	}
+
+	data->banks = wm8505_banks;
+	data->nbanks = ARRAY_SIZE(wm8505_banks);
+	data->pins = wm8505_pins;
+	data->npins = ARRAY_SIZE(wm8505_pins);
+	data->groups = wm8505_groups;
+	data->ngroups = ARRAY_SIZE(wm8505_groups);
+
+	return wmt_pinctrl_probe(pdev, data);
+}
+
+static int wm8505_pinctrl_remove(struct platform_device *pdev)
+{
+	return wmt_pinctrl_remove(pdev);
+}
+
+static struct of_device_id wmt_pinctrl_of_match[] = {
+	{ .compatible = "wm,wm8505-pinctrl" },
+	{ /* sentinel */ },
+};
+
+static struct platform_driver wmt_pinctrl_driver = {
+	.probe	= wm8505_pinctrl_probe,
+	.remove	= wm8505_pinctrl_remove,
+	.driver = {
+		.name	= "pinctrl-wm8505",
+		.owner	= THIS_MODULE,
+		.of_match_table	= wmt_pinctrl_of_match,
+	},
+};
+
+module_platform_driver(wmt_pinctrl_driver);
+
+MODULE_AUTHOR("Tony Prisk <linux at prisktech.co.nz>");
+MODULE_DESCRIPTION("Wondermedia WM8505 Pincontrol driver");
+MODULE_LICENSE("GPL v2");
+MODULE_DEVICE_TABLE(of, wmt_pinctrl_of_match);
diff --git a/drivers/pinctrl/vt8500/pinctrl-wm8650.c b/drivers/pinctrl/vt8500/pinctrl-wm8650.c
new file mode 100644
index 0000000..7de57f0
--- /dev/null
+++ b/drivers/pinctrl/vt8500/pinctrl-wm8650.c
@@ -0,0 +1,370 @@
+/*
+ * Pinctrl data for Wondermedia WM8650 SoC
+ *
+ * Copyright (c) 2013 Tony Prisk <linux at prisktech.co.nz>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ */
+
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/pinctrl/pinctrl.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+
+#include "pinctrl-wmt.h"
+
+/*
+ * Describe the register offsets within the GPIO memory space
+ * The dedicated external GPIO's should always be listed in bank 0
+ * so they are exported in the 0..31 range which is what users
+ * expect.
+ *
+ * Do not reorder these banks as it will change the pin numbering
+ */
+static const struct wmt_pinctrl_bank_registers wm8650_banks[] = {
+	WMT_PINCTRL_BANK(0x40, 0x80, 0xC0, 0x00, 0x480, 0x4C0),		/* 0 */
+	WMT_PINCTRL_BANK(0x44, 0x84, 0xC4, 0x04, 0x484, 0x4C4),		/* 1 */
+	WMT_PINCTRL_BANK(0x48, 0x88, 0xC8, 0x08, 0x488, 0x4C8),		/* 2 */
+	WMT_PINCTRL_BANK(0x4C, 0x8C, 0xCC, 0x0C, 0x48C, 0x4CC),		/* 3 */
+	WMT_PINCTRL_BANK(0x50, 0x90, 0xD0, 0x10, 0x490, 0x4D0),		/* 4 */
+	WMT_PINCTRL_BANK(0x54, 0x94, 0xD4, 0x14, 0x494, 0x4D4),		/* 5 */
+	WMT_PINCTRL_BANK(0x58, 0x98, 0xD8, 0x18, 0x498, 0x4D8),		/* 6 */
+	WMT_PINCTRL_BANK(0x5C, 0x9C, 0xDC, 0x1C, 0x49C, 0x4DC),		/* 7 */
+};
+
+/* Please keep sorted by bank/bit */
+#define WMT_PIN_EXTGPIO0	WMT_PIN(0, 0)
+#define WMT_PIN_EXTGPIO1	WMT_PIN(0, 1)
+#define WMT_PIN_EXTGPIO2	WMT_PIN(0, 2)
+#define WMT_PIN_EXTGPIO3	WMT_PIN(0, 3)
+#define WMT_PIN_EXTGPIO4	WMT_PIN(0, 4)
+#define WMT_PIN_EXTGPIO5	WMT_PIN(0, 5)
+#define WMT_PIN_EXTGPIO6	WMT_PIN(0, 6)
+#define WMT_PIN_EXTGPIO7	WMT_PIN(0, 7)
+#define WMT_PIN_WAKEUP0		WMT_PIN(0, 16)
+#define WMT_PIN_WAKEUP1		WMT_PIN(0, 17)
+#define WMT_PIN_SUSGPIO0	WMT_PIN(0, 21)
+#define WMT_PIN_SD0CD		WMT_PIN(0, 28)
+#define WMT_PIN_SD1CD		WMT_PIN(0, 29)
+#define WMT_PIN_VDOUT0		WMT_PIN(1, 0)
+#define WMT_PIN_VDOUT1		WMT_PIN(1, 1)
+#define WMT_PIN_VDOUT2		WMT_PIN(1, 2)
+#define WMT_PIN_VDOUT3		WMT_PIN(1, 3)
+#define WMT_PIN_VDOUT4		WMT_PIN(1, 4)
+#define WMT_PIN_VDOUT5		WMT_PIN(1, 5)
+#define WMT_PIN_VDOUT6		WMT_PIN(1, 6)
+#define WMT_PIN_VDOUT7		WMT_PIN(1, 7)
+#define WMT_PIN_VDOUT8		WMT_PIN(1, 8)
+#define WMT_PIN_VDOUT9		WMT_PIN(1, 9)
+#define WMT_PIN_VDOUT10		WMT_PIN(1, 10)
+#define WMT_PIN_VDOUT11		WMT_PIN(1, 11)
+#define WMT_PIN_VDOUT12		WMT_PIN(1, 12)
+#define WMT_PIN_VDOUT13		WMT_PIN(1, 13)
+#define WMT_PIN_VDOUT14		WMT_PIN(1, 14)
+#define WMT_PIN_VDOUT15		WMT_PIN(1, 15)
+#define WMT_PIN_VDOUT16		WMT_PIN(1, 16)
+#define WMT_PIN_VDOUT17		WMT_PIN(1, 17)
+#define WMT_PIN_VDOUT18		WMT_PIN(1, 18)
+#define WMT_PIN_VDOUT19		WMT_PIN(1, 19)
+#define WMT_PIN_VDOUT20		WMT_PIN(1, 20)
+#define WMT_PIN_VDOUT21		WMT_PIN(1, 21)
+#define WMT_PIN_VDOUT22		WMT_PIN(1, 22)
+#define WMT_PIN_VDOUT23		WMT_PIN(1, 23)
+#define WMT_PIN_VDIN0		WMT_PIN(2, 0)
+#define WMT_PIN_VDIN1		WMT_PIN(2, 1)
+#define WMT_PIN_VDIN2		WMT_PIN(2, 2)
+#define WMT_PIN_VDIN3		WMT_PIN(2, 3)
+#define WMT_PIN_VDIN4		WMT_PIN(2, 4)
+#define WMT_PIN_VDIN5		WMT_PIN(2, 5)
+#define WMT_PIN_VDIN6		WMT_PIN(2, 6)
+#define WMT_PIN_VDIN7		WMT_PIN(2, 7)
+#define WMT_PIN_I2C1SCL		WMT_PIN(2, 12)
+#define WMT_PIN_I2C1SDA		WMT_PIN(2, 13)
+#define WMT_PIN_SPI0MOSI	WMT_PIN(2, 24)
+#define WMT_PIN_SPI0MISO	WMT_PIN(2, 25)
+#define WMT_PIN_SPI0SS0		WMT_PIN(2, 26)
+#define WMT_PIN_SPI0CLK		WMT_PIN(2, 27)
+#define WMT_PIN_SD0DATA0	WMT_PIN(3, 8)
+#define WMT_PIN_SD0DATA1	WMT_PIN(3, 9)
+#define WMT_PIN_SD0DATA2	WMT_PIN(3, 10)
+#define WMT_PIN_SD0DATA3	WMT_PIN(3, 11)
+#define WMT_PIN_SD0CLK		WMT_PIN(3, 12)
+#define WMT_PIN_SD0WP		WMT_PIN(3, 13)
+#define WMT_PIN_SD0CMD		WMT_PIN(3, 14)
+#define WMT_PIN_SD1DATA0	WMT_PIN(3, 24)
+#define WMT_PIN_SD1DATA1	WMT_PIN(3, 25)
+#define WMT_PIN_SD1DATA2	WMT_PIN(3, 26)
+#define WMT_PIN_SD1DATA3	WMT_PIN(3, 27)
+#define WMT_PIN_SD1DATA4	WMT_PIN(3, 28)
+#define WMT_PIN_SD1DATA5	WMT_PIN(3, 29)
+#define WMT_PIN_SD1DATA6	WMT_PIN(3, 30)
+#define WMT_PIN_SD1DATA7	WMT_PIN(3, 31)
+#define WMT_PIN_I2C0SCL		WMT_PIN(5, 8)
+#define WMT_PIN_I2C0SDA		WMT_PIN(5, 9)
+#define WMT_PIN_UART0RTS	WMT_PIN(5, 16)
+#define WMT_PIN_UART0TXD	WMT_PIN(5, 17)
+#define WMT_PIN_UART0CTS	WMT_PIN(5, 18)
+#define WMT_PIN_UART0RXD	WMT_PIN(5, 19)
+#define WMT_PIN_UART1RTS	WMT_PIN(5, 20)
+#define WMT_PIN_UART1TXD	WMT_PIN(5, 21)
+#define WMT_PIN_UART1CTS	WMT_PIN(5, 22)
+#define WMT_PIN_UART1RXD	WMT_PIN(5, 23)
+#define WMT_PIN_UART2RTS	WMT_PIN(5, 24)
+#define WMT_PIN_UART2TXD	WMT_PIN(5, 25)
+#define WMT_PIN_UART2CTS	WMT_PIN(5, 26)
+#define WMT_PIN_UART2RXD	WMT_PIN(5, 27)
+#define WMT_PIN_UART3RTS	WMT_PIN(5, 28)
+#define WMT_PIN_UART3TXD	WMT_PIN(5, 29)
+#define WMT_PIN_UART3CTS	WMT_PIN(5, 30)
+#define WMT_PIN_UART3RXD	WMT_PIN(5, 31)
+#define WMT_PIN_KPADROW0	WMT_PIN(6, 16)
+#define WMT_PIN_KPADROW1	WMT_PIN(6, 17)
+#define WMT_PIN_KPADCOL0	WMT_PIN(6, 18)
+#define WMT_PIN_KPADCOL1	WMT_PIN(6, 19)
+#define WMT_PIN_SD1CLK		WMT_PIN(7, 0)
+#define WMT_PIN_SD1CMD		WMT_PIN(7, 1)
+#define WMT_PIN_SD1WP		WMT_PIN(7, 13)
+
+static const struct pinctrl_pin_desc wm8650_pins[] = {
+	PINCTRL_PIN(WMT_PIN_EXTGPIO0, "extgpio0"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO1, "extgpio1"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO2, "extgpio2"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO3, "extgpio3"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO4, "extgpio4"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO5, "extgpio5"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO6, "extgpio6"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO7, "extgpio7"),
+	PINCTRL_PIN(WMT_PIN_WAKEUP0, "wakeup0"),
+	PINCTRL_PIN(WMT_PIN_WAKEUP1, "wakeup1"),
+	PINCTRL_PIN(WMT_PIN_SUSGPIO0, "susgpio0"),
+	PINCTRL_PIN(WMT_PIN_SD0CD, "sd0_cd"),
+	PINCTRL_PIN(WMT_PIN_SD1CD, "sd1_cd"),
+	PINCTRL_PIN(WMT_PIN_VDOUT0, "vdout0"),
+	PINCTRL_PIN(WMT_PIN_VDOUT1, "vdout1"),
+	PINCTRL_PIN(WMT_PIN_VDOUT2, "vdout2"),
+	PINCTRL_PIN(WMT_PIN_VDOUT3, "vdout3"),
+	PINCTRL_PIN(WMT_PIN_VDOUT4, "vdout4"),
+	PINCTRL_PIN(WMT_PIN_VDOUT5, "vdout5"),
+	PINCTRL_PIN(WMT_PIN_VDOUT6, "vdout6"),
+	PINCTRL_PIN(WMT_PIN_VDOUT7, "vdout7"),
+	PINCTRL_PIN(WMT_PIN_VDOUT8, "vdout8"),
+	PINCTRL_PIN(WMT_PIN_VDOUT9, "vdout9"),
+	PINCTRL_PIN(WMT_PIN_VDOUT10, "vdout10"),
+	PINCTRL_PIN(WMT_PIN_VDOUT11, "vdout11"),
+	PINCTRL_PIN(WMT_PIN_VDOUT12, "vdout12"),
+	PINCTRL_PIN(WMT_PIN_VDOUT13, "vdout13"),
+	PINCTRL_PIN(WMT_PIN_VDOUT14, "vdout14"),
+	PINCTRL_PIN(WMT_PIN_VDOUT15, "vdout15"),
+	PINCTRL_PIN(WMT_PIN_VDOUT16, "vdout16"),
+	PINCTRL_PIN(WMT_PIN_VDOUT17, "vdout17"),
+	PINCTRL_PIN(WMT_PIN_VDOUT18, "vdout18"),
+	PINCTRL_PIN(WMT_PIN_VDOUT19, "vdout19"),
+	PINCTRL_PIN(WMT_PIN_VDOUT20, "vdout20"),
+	PINCTRL_PIN(WMT_PIN_VDOUT21, "vdout21"),
+	PINCTRL_PIN(WMT_PIN_VDOUT22, "vdout22"),
+	PINCTRL_PIN(WMT_PIN_VDOUT23, "vdout23"),
+	PINCTRL_PIN(WMT_PIN_VDIN0, "vdin0"),
+	PINCTRL_PIN(WMT_PIN_VDIN1, "vdin1"),
+	PINCTRL_PIN(WMT_PIN_VDIN2, "vdin2"),
+	PINCTRL_PIN(WMT_PIN_VDIN3, "vdin3"),
+	PINCTRL_PIN(WMT_PIN_VDIN4, "vdin4"),
+	PINCTRL_PIN(WMT_PIN_VDIN5, "vdin5"),
+	PINCTRL_PIN(WMT_PIN_VDIN6, "vdin6"),
+	PINCTRL_PIN(WMT_PIN_VDIN7, "vdin7"),
+	PINCTRL_PIN(WMT_PIN_I2C1SCL, "i2c1_scl"),
+	PINCTRL_PIN(WMT_PIN_I2C1SDA, "i2c1_sda"),
+	PINCTRL_PIN(WMT_PIN_SPI0MOSI, "spi0_mosi"),
+	PINCTRL_PIN(WMT_PIN_SPI0MISO, "spi0_miso"),
+	PINCTRL_PIN(WMT_PIN_SPI0SS0, "spi0_ss0"),
+	PINCTRL_PIN(WMT_PIN_SPI0CLK, "spi0_clk"),
+	PINCTRL_PIN(WMT_PIN_SD0DATA0, "sd0_data0"),
+	PINCTRL_PIN(WMT_PIN_SD0DATA1, "sd0_data1"),
+	PINCTRL_PIN(WMT_PIN_SD0DATA2, "sd0_data2"),
+	PINCTRL_PIN(WMT_PIN_SD0DATA3, "sd0_data3"),
+	PINCTRL_PIN(WMT_PIN_SD0CLK, "sd0_clk"),
+	PINCTRL_PIN(WMT_PIN_SD0WP, "sd0_wp"),
+	PINCTRL_PIN(WMT_PIN_SD0CMD, "sd0_cmd"),
+	PINCTRL_PIN(WMT_PIN_SD1DATA0, "sd1_data0"),
+	PINCTRL_PIN(WMT_PIN_SD1DATA1, "sd1_data1"),
+	PINCTRL_PIN(WMT_PIN_SD1DATA2, "sd1_data2"),
+	PINCTRL_PIN(WMT_PIN_SD1DATA3, "sd1_data3"),
+	PINCTRL_PIN(WMT_PIN_SD1DATA4, "sd1_data4"),
+	PINCTRL_PIN(WMT_PIN_SD1DATA5, "sd1_data5"),
+	PINCTRL_PIN(WMT_PIN_SD1DATA6, "sd1_data6"),
+	PINCTRL_PIN(WMT_PIN_SD1DATA7, "sd1_data7"),
+	PINCTRL_PIN(WMT_PIN_I2C0SCL, "i2c0_scl"),
+	PINCTRL_PIN(WMT_PIN_I2C0SDA, "i2c0_sda"),
+	PINCTRL_PIN(WMT_PIN_UART0RTS, "uart0_rts"),
+	PINCTRL_PIN(WMT_PIN_UART0TXD, "uart0_txd"),
+	PINCTRL_PIN(WMT_PIN_UART0CTS, "uart0_cts"),
+	PINCTRL_PIN(WMT_PIN_UART0RXD, "uart0_rxd"),
+	PINCTRL_PIN(WMT_PIN_UART1RTS, "uart1_rts"),
+	PINCTRL_PIN(WMT_PIN_UART1TXD, "uart1_txd"),
+	PINCTRL_PIN(WMT_PIN_UART1CTS, "uart1_cts"),
+	PINCTRL_PIN(WMT_PIN_UART1RXD, "uart1_rxd"),
+	PINCTRL_PIN(WMT_PIN_UART2RTS, "uart2_rts"),
+	PINCTRL_PIN(WMT_PIN_UART2TXD, "uart2_txd"),
+	PINCTRL_PIN(WMT_PIN_UART2CTS, "uart2_cts"),
+	PINCTRL_PIN(WMT_PIN_UART2RXD, "uart2_rxd"),
+	PINCTRL_PIN(WMT_PIN_UART3RTS, "uart3_rts"),
+	PINCTRL_PIN(WMT_PIN_UART3TXD, "uart3_txd"),
+	PINCTRL_PIN(WMT_PIN_UART3CTS, "uart3_cts"),
+	PINCTRL_PIN(WMT_PIN_UART3RXD, "uart3_rxd"),
+	PINCTRL_PIN(WMT_PIN_KPADROW0, "kpadrow0"),
+	PINCTRL_PIN(WMT_PIN_KPADROW1, "kpadrow1"),
+	PINCTRL_PIN(WMT_PIN_KPADCOL0, "kpadcol0"),
+	PINCTRL_PIN(WMT_PIN_KPADCOL1, "kpadcol1"),
+	PINCTRL_PIN(WMT_PIN_SD1CLK, "sd1_clk"),
+	PINCTRL_PIN(WMT_PIN_SD1CMD, "sd1_cmd"),
+	PINCTRL_PIN(WMT_PIN_SD1WP, "sd1_wp"),
+};
+
+/* Order of these names must match the above list */
+static const char * const wm8650_groups[] = {
+	"extgpio0",
+	"extgpio1",
+	"extgpio2",
+	"extgpio3",
+	"extgpio4",
+	"extgpio5",
+	"extgpio6",
+	"extgpio7",
+	"wakeup0",
+	"wakeup1",
+	"susgpio0",
+	"sd0_cd",
+	"sd1_cd",
+	"vdout0",
+	"vdout1",
+	"vdout2",
+	"vdout3",
+	"vdout4",
+	"vdout5",
+	"vdout6",
+	"vdout7",
+	"vdout8",
+	"vdout9",
+	"vdout10",
+	"vdout11",
+	"vdout12",
+	"vdout13",
+	"vdout14",
+	"vdout15",
+	"vdout16",
+	"vdout17",
+	"vdout18",
+	"vdout19",
+	"vdout20",
+	"vdout21",
+	"vdout22",
+	"vdout23",
+	"vdin0",
+	"vdin1",
+	"vdin2",
+	"vdin3",
+	"vdin4",
+	"vdin5",
+	"vdin6",
+	"vdin7",
+	"i2c1_scl",
+	"i2c1_sda",
+	"spi0_mosi",
+	"spi0_miso",
+	"spi0_ss0",
+	"spi0_clk",
+	"sd0_data0",
+	"sd0_data1",
+	"sd0_data2",
+	"sd0_data3",
+	"sd0_clk",
+	"sd0_wp",
+	"sd0_cmd",
+	"sd1_data0",
+	"sd1_data1",
+	"sd1_data2",
+	"sd1_data3",
+	"sd1_data4",
+	"sd1_data5",
+	"sd1_data6",
+	"sd1_data7",
+	"i2c0_scl",
+	"i2c0_sda",
+	"uart0_rts",
+	"uart0_txd",
+	"uart0_cts",
+	"uart0_rxd",
+	"uart1_rts",
+	"uart1_txd",
+	"uart1_cts",
+	"uart1_rxd",
+	"uart2_rts",
+	"uart2_txd",
+	"uart2_cts",
+	"uart2_rxd",
+	"uart3_rts",
+	"uart3_txd",
+	"uart3_cts",
+	"uart3_rxd",
+	"kpadrow0",
+	"kpadrow1",
+	"kpadcol0",
+	"kpadcol1",
+	"sd1_clk",
+	"sd1_cmd",
+	"sd1_wp",
+};
+
+static int wm8650_pinctrl_probe(struct platform_device *pdev)
+{
+	struct wmt_pinctrl_data *data;
+
+	data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
+	if (!data) {
+		dev_err(&pdev->dev, "failed to allocate data\n");
+		return -ENOMEM;
+	}
+
+	data->banks = wm8650_banks;
+	data->nbanks = ARRAY_SIZE(wm8650_banks);
+	data->pins = wm8650_pins;
+	data->npins = ARRAY_SIZE(wm8650_pins);
+	data->groups = wm8650_groups;
+	data->ngroups = ARRAY_SIZE(wm8650_groups);
+
+	return wmt_pinctrl_probe(pdev, data);
+}
+
+static int wm8650_pinctrl_remove(struct platform_device *pdev)
+{
+	return wmt_pinctrl_remove(pdev);
+}
+
+static struct of_device_id wmt_pinctrl_of_match[] = {
+	{ .compatible = "wm,wm8650-pinctrl" },
+	{ /* sentinel */ },
+};
+
+static struct platform_driver wmt_pinctrl_driver = {
+	.probe	= wm8650_pinctrl_probe,
+	.remove	= wm8650_pinctrl_remove,
+	.driver = {
+		.name	= "pinctrl-wm8650",
+		.owner	= THIS_MODULE,
+		.of_match_table	= wmt_pinctrl_of_match,
+	},
+};
+
+module_platform_driver(wmt_pinctrl_driver);
+
+MODULE_AUTHOR("Tony Prisk <linux at prisktech.co.nz>");
+MODULE_DESCRIPTION("Wondermedia WM8650 Pincontrol driver");
+MODULE_LICENSE("GPL v2");
+MODULE_DEVICE_TABLE(of, wmt_pinctrl_of_match);
diff --git a/drivers/pinctrl/vt8500/pinctrl-wm8750.c b/drivers/pinctrl/vt8500/pinctrl-wm8750.c
new file mode 100644
index 0000000..b964cc5
--- /dev/null
+++ b/drivers/pinctrl/vt8500/pinctrl-wm8750.c
@@ -0,0 +1,409 @@
+/*
+ * Pinctrl data for Wondermedia WM8750 SoC
+ *
+ * Copyright (c) 2013 Tony Prisk <linux at prisktech.co.nz>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ */
+
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/pinctrl/pinctrl.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+
+#include "pinctrl-wmt.h"
+
+/*
+ * Describe the register offsets within the GPIO memory space
+ * The dedicated external GPIO's should always be listed in bank 0
+ * so they are exported in the 0..31 range which is what users
+ * expect.
+ *
+ * Do not reorder these banks as it will change the pin numbering
+ */
+static const struct wmt_pinctrl_bank_registers wm8750_banks[] = {
+	WMT_PINCTRL_BANK(0x40, 0x80, 0xC0, 0x00, 0x480, 0x4C0),	/* 0 */
+	WMT_PINCTRL_BANK(0x44, 0x84, 0xC4, 0x04, 0x484, 0x4C4),	/* 1 */
+	WMT_PINCTRL_BANK(0x48, 0x88, 0xC8, 0x08, 0x488, 0x4C8),	/* 2 */
+	WMT_PINCTRL_BANK(0x4C, 0x8C, 0xCC, 0x0C, 0x48C, 0x4CC),	/* 3 */
+	WMT_PINCTRL_BANK(0x50, 0x90, 0xD0, 0x10, 0x490, 0x4D0),	/* 4 */
+	WMT_PINCTRL_BANK(0x54, 0x94, 0xD4, 0x14, 0x494, 0x4D4),	/* 5 */
+	WMT_PINCTRL_BANK(0x58, 0x98, 0xD8, 0x18, 0x498, 0x4D8),	/* 6 */
+	WMT_PINCTRL_BANK(0x5C, 0x9C, 0xDC, 0x1C, 0x49C, 0x4DC),	/* 7 */
+	WMT_PINCTRL_BANK(0x60, 0xA0, 0xE0, 0x20, 0x4A0, 0x4E0),	/* 8 */
+	WMT_PINCTRL_BANK(0x70, 0xB0, 0xF0, 0x30, 0x4B0, 0x4F0),	/* 9 */
+	WMT_PINCTRL_BANK(0x7C, 0xBC, 0xDC, 0x3C, 0x4BC, 0x4FC),	/* 10 */
+};
+
+/* Please keep sorted by bank/bit */
+#define WMT_PIN_EXTGPIO0	WMT_PIN(0, 0)
+#define WMT_PIN_EXTGPIO1	WMT_PIN(0, 1)
+#define WMT_PIN_EXTGPIO2	WMT_PIN(0, 2)
+#define WMT_PIN_EXTGPIO3	WMT_PIN(0, 3)
+#define WMT_PIN_EXTGPIO4	WMT_PIN(0, 4)
+#define WMT_PIN_EXTGPIO5	WMT_PIN(0, 5)
+#define WMT_PIN_EXTGPIO6	WMT_PIN(0, 6)
+#define WMT_PIN_EXTGPIO7	WMT_PIN(0, 7)
+#define WMT_PIN_WAKEUP0		WMT_PIN(0, 16)
+#define WMT_PIN_WAKEUP1		WMT_PIN(0, 16)
+#define WMT_PIN_SD0CD		WMT_PIN(0, 28)
+#define WMT_PIN_VDOUT0		WMT_PIN(1, 0)
+#define WMT_PIN_VDOUT1		WMT_PIN(1, 1)
+#define WMT_PIN_VDOUT2		WMT_PIN(1, 2)
+#define WMT_PIN_VDOUT3		WMT_PIN(1, 3)
+#define WMT_PIN_VDOUT4		WMT_PIN(1, 4)
+#define WMT_PIN_VDOUT5		WMT_PIN(1, 5)
+#define WMT_PIN_VDOUT6		WMT_PIN(1, 6)
+#define WMT_PIN_VDOUT7		WMT_PIN(1, 7)
+#define WMT_PIN_VDOUT8		WMT_PIN(1, 8)
+#define WMT_PIN_VDOUT9		WMT_PIN(1, 9)
+#define WMT_PIN_VDOUT10		WMT_PIN(1, 10)
+#define WMT_PIN_VDOUT11		WMT_PIN(1, 11)
+#define WMT_PIN_VDOUT12		WMT_PIN(1, 12)
+#define WMT_PIN_VDOUT13		WMT_PIN(1, 13)
+#define WMT_PIN_VDOUT14		WMT_PIN(1, 14)
+#define WMT_PIN_VDOUT15		WMT_PIN(1, 15)
+#define WMT_PIN_VDOUT16		WMT_PIN(1, 16)
+#define WMT_PIN_VDOUT17		WMT_PIN(1, 17)
+#define WMT_PIN_VDOUT18		WMT_PIN(1, 18)
+#define WMT_PIN_VDOUT19		WMT_PIN(1, 19)
+#define WMT_PIN_VDOUT20		WMT_PIN(1, 20)
+#define WMT_PIN_VDOUT21		WMT_PIN(1, 21)
+#define WMT_PIN_VDOUT22		WMT_PIN(1, 22)
+#define WMT_PIN_VDOUT23		WMT_PIN(1, 23)
+#define WMT_PIN_VDIN0		WMT_PIN(2, 0)
+#define WMT_PIN_VDIN1		WMT_PIN(2, 1)
+#define WMT_PIN_VDIN2		WMT_PIN(2, 2)
+#define WMT_PIN_VDIN3		WMT_PIN(2, 3)
+#define WMT_PIN_VDIN4		WMT_PIN(2, 4)
+#define WMT_PIN_VDIN5		WMT_PIN(2, 5)
+#define WMT_PIN_VDIN6		WMT_PIN(2, 6)
+#define WMT_PIN_VDIN7		WMT_PIN(2, 7)
+#define WMT_PIN_SPI0_MOSI	WMT_PIN(2, 24)
+#define WMT_PIN_SPI0_MISO	WMT_PIN(2, 25)
+#define WMT_PIN_SPI0_SS		WMT_PIN(2, 26)
+#define WMT_PIN_SPI0_CLK	WMT_PIN(2, 27)
+#define WMT_PIN_SPI0_SSB	WMT_PIN(2, 28)
+#define WMT_PIN_SD0CLK		WMT_PIN(3, 17)
+#define WMT_PIN_SD0CMD		WMT_PIN(3, 18)
+#define WMT_PIN_SD0WP		WMT_PIN(3, 19)
+#define WMT_PIN_SD0DATA0	WMT_PIN(3, 20)
+#define WMT_PIN_SD0DATA1	WMT_PIN(3, 21)
+#define WMT_PIN_SD0DATA2	WMT_PIN(3, 22)
+#define WMT_PIN_SD0DATA3	WMT_PIN(3, 23)
+#define WMT_PIN_SD1DATA0	WMT_PIN(3, 24)
+#define WMT_PIN_SD1DATA1	WMT_PIN(3, 25)
+#define WMT_PIN_SD1DATA2	WMT_PIN(3, 26)
+#define WMT_PIN_SD1DATA3	WMT_PIN(3, 27)
+#define WMT_PIN_SD1DATA4	WMT_PIN(3, 28)
+#define WMT_PIN_SD1DATA5	WMT_PIN(3, 29)
+#define WMT_PIN_SD1DATA6	WMT_PIN(3, 30)
+#define WMT_PIN_SD1DATA7	WMT_PIN(3, 31)
+#define WMT_PIN_I2C0_SCL	WMT_PIN(5, 8)
+#define WMT_PIN_I2C0_SDA	WMT_PIN(5, 9)
+#define WMT_PIN_I2C1_SCL	WMT_PIN(5, 10)
+#define WMT_PIN_I2C1_SDA	WMT_PIN(5, 11)
+#define WMT_PIN_I2C2_SCL	WMT_PIN(5, 12)
+#define WMT_PIN_I2C2_SDA	WMT_PIN(5, 13)
+#define WMT_PIN_UART0_RTS	WMT_PIN(5, 16)
+#define WMT_PIN_UART0_TXD	WMT_PIN(5, 17)
+#define WMT_PIN_UART0_CTS	WMT_PIN(5, 18)
+#define WMT_PIN_UART0_RXD	WMT_PIN(5, 19)
+#define WMT_PIN_UART1_RTS	WMT_PIN(5, 20)
+#define WMT_PIN_UART1_TXD	WMT_PIN(5, 21)
+#define WMT_PIN_UART1_CTS	WMT_PIN(5, 22)
+#define WMT_PIN_UART1_RXD	WMT_PIN(5, 23)
+#define WMT_PIN_UART2_RTS	WMT_PIN(5, 24)
+#define WMT_PIN_UART2_TXD	WMT_PIN(5, 25)
+#define WMT_PIN_UART2_CTS	WMT_PIN(5, 26)
+#define WMT_PIN_UART2_RXD	WMT_PIN(5, 27)
+#define WMT_PIN_UART3_RTS	WMT_PIN(5, 28)
+#define WMT_PIN_UART3_TXD	WMT_PIN(5, 29)
+#define WMT_PIN_UART3_CTS	WMT_PIN(5, 30)
+#define WMT_PIN_UART3_RXD	WMT_PIN(5, 31)
+#define WMT_PIN_SD2CD		WMT_PIN(6, 0)
+#define WMT_PIN_SD2DATA3	WMT_PIN(6, 1)
+#define WMT_PIN_SD2DATA0	WMT_PIN(6, 2)
+#define WMT_PIN_SD2WP		WMT_PIN(6, 3)
+#define WMT_PIN_SD2DATA1	WMT_PIN(6, 4)
+#define WMT_PIN_SD2DATA2	WMT_PIN(6, 5)
+#define WMT_PIN_SD2CMD		WMT_PIN(6, 6)
+#define WMT_PIN_SD2CLK		WMT_PIN(6, 7)
+#define WMT_PIN_SD2PWR		WMT_PIN(6, 9)
+#define WMT_PIN_SD1CLK		WMT_PIN(7, 0)
+#define WMT_PIN_SD1CMD		WMT_PIN(7, 1)
+#define WMT_PIN_SD1PWR		WMT_PIN(7, 10)
+#define WMT_PIN_SD1WP		WMT_PIN(7, 11)
+#define WMT_PIN_SD1CD		WMT_PIN(7, 12)
+#define WMT_PIN_SPI0SS3		WMT_PIN(7, 24)
+#define WMT_PIN_SPI0SS2		WMT_PIN(7, 25)
+#define WMT_PIN_PWMOUT1		WMT_PIN(7, 26)
+#define WMT_PIN_PWMOUT0		WMT_PIN(7, 27)
+
+static const struct pinctrl_pin_desc wm8750_pins[] = {
+	PINCTRL_PIN(WMT_PIN_EXTGPIO0, "extgpio0"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO1, "extgpio1"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO2, "extgpio2"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO3, "extgpio3"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO4, "extgpio4"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO5, "extgpio5"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO6, "extgpio6"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO7, "extgpio7"),
+	PINCTRL_PIN(WMT_PIN_WAKEUP0, "wakeup0"),
+	PINCTRL_PIN(WMT_PIN_WAKEUP1, "wakeup1"),
+	PINCTRL_PIN(WMT_PIN_SD0CD, "sd0_cd"),
+	PINCTRL_PIN(WMT_PIN_VDOUT0, "vdout0"),
+	PINCTRL_PIN(WMT_PIN_VDOUT1, "vdout1"),
+	PINCTRL_PIN(WMT_PIN_VDOUT2, "vdout2"),
+	PINCTRL_PIN(WMT_PIN_VDOUT3, "vdout3"),
+	PINCTRL_PIN(WMT_PIN_VDOUT4, "vdout4"),
+	PINCTRL_PIN(WMT_PIN_VDOUT5, "vdout5"),
+	PINCTRL_PIN(WMT_PIN_VDOUT6, "vdout6"),
+	PINCTRL_PIN(WMT_PIN_VDOUT7, "vdout7"),
+	PINCTRL_PIN(WMT_PIN_VDOUT8, "vdout8"),
+	PINCTRL_PIN(WMT_PIN_VDOUT9, "vdout9"),
+	PINCTRL_PIN(WMT_PIN_VDOUT10, "vdout10"),
+	PINCTRL_PIN(WMT_PIN_VDOUT11, "vdout11"),
+	PINCTRL_PIN(WMT_PIN_VDOUT12, "vdout12"),
+	PINCTRL_PIN(WMT_PIN_VDOUT13, "vdout13"),
+	PINCTRL_PIN(WMT_PIN_VDOUT14, "vdout14"),
+	PINCTRL_PIN(WMT_PIN_VDOUT15, "vdout15"),
+	PINCTRL_PIN(WMT_PIN_VDOUT16, "vdout16"),
+	PINCTRL_PIN(WMT_PIN_VDOUT17, "vdout17"),
+	PINCTRL_PIN(WMT_PIN_VDOUT18, "vdout18"),
+	PINCTRL_PIN(WMT_PIN_VDOUT19, "vdout19"),
+	PINCTRL_PIN(WMT_PIN_VDOUT20, "vdout20"),
+	PINCTRL_PIN(WMT_PIN_VDOUT21, "vdout21"),
+	PINCTRL_PIN(WMT_PIN_VDOUT22, "vdout22"),
+	PINCTRL_PIN(WMT_PIN_VDOUT23, "vdout23"),
+	PINCTRL_PIN(WMT_PIN_VDIN0, "vdin0"),
+	PINCTRL_PIN(WMT_PIN_VDIN1, "vdin1"),
+	PINCTRL_PIN(WMT_PIN_VDIN2, "vdin2"),
+	PINCTRL_PIN(WMT_PIN_VDIN3, "vdin3"),
+	PINCTRL_PIN(WMT_PIN_VDIN4, "vdin4"),
+	PINCTRL_PIN(WMT_PIN_VDIN5, "vdin5"),
+	PINCTRL_PIN(WMT_PIN_VDIN6, "vdin6"),
+	PINCTRL_PIN(WMT_PIN_VDIN7, "vdin7"),
+	PINCTRL_PIN(WMT_PIN_SPI0_MOSI, "spi0_mosi"),
+	PINCTRL_PIN(WMT_PIN_SPI0_MISO, "spi0_miso"),
+	PINCTRL_PIN(WMT_PIN_SPI0_SS, "spi0_ss"),
+	PINCTRL_PIN(WMT_PIN_SPI0_CLK, "spi0_clk"),
+	PINCTRL_PIN(WMT_PIN_SPI0_SSB, "spi0_ssb"),
+	PINCTRL_PIN(WMT_PIN_SD0CLK, "sd0_clk"),
+	PINCTRL_PIN(WMT_PIN_SD0CMD, "sd0_cmd"),
+	PINCTRL_PIN(WMT_PIN_SD0WP, "sd0_wp"),
+	PINCTRL_PIN(WMT_PIN_SD0DATA0, "sd0_data0"),
+	PINCTRL_PIN(WMT_PIN_SD0DATA1, "sd0_data1"),
+	PINCTRL_PIN(WMT_PIN_SD0DATA2, "sd0_data2"),
+	PINCTRL_PIN(WMT_PIN_SD0DATA3, "sd0_data3"),
+	PINCTRL_PIN(WMT_PIN_SD1DATA0, "sd1_data0"),
+	PINCTRL_PIN(WMT_PIN_SD1DATA1, "sd1_data1"),
+	PINCTRL_PIN(WMT_PIN_SD1DATA2, "sd1_data2"),
+	PINCTRL_PIN(WMT_PIN_SD1DATA3, "sd1_data3"),
+	PINCTRL_PIN(WMT_PIN_SD1DATA4, "sd1_data4"),
+	PINCTRL_PIN(WMT_PIN_SD1DATA5, "sd1_data5"),
+	PINCTRL_PIN(WMT_PIN_SD1DATA6, "sd1_data6"),
+	PINCTRL_PIN(WMT_PIN_SD1DATA7, "sd1_data7"),
+	PINCTRL_PIN(WMT_PIN_I2C0_SCL, "i2c0_scl"),
+	PINCTRL_PIN(WMT_PIN_I2C0_SDA, "i2c0_sda"),
+	PINCTRL_PIN(WMT_PIN_I2C1_SCL, "i2c1_scl"),
+	PINCTRL_PIN(WMT_PIN_I2C1_SDA, "i2c1_sda"),
+	PINCTRL_PIN(WMT_PIN_I2C2_SCL, "i2c2_scl"),
+	PINCTRL_PIN(WMT_PIN_I2C2_SDA, "i2c2_sda"),
+	PINCTRL_PIN(WMT_PIN_UART0_RTS, "uart0_rts"),
+	PINCTRL_PIN(WMT_PIN_UART0_TXD, "uart0_txd"),
+	PINCTRL_PIN(WMT_PIN_UART0_CTS, "uart0_cts"),
+	PINCTRL_PIN(WMT_PIN_UART0_RXD, "uart0_rxd"),
+	PINCTRL_PIN(WMT_PIN_UART1_RTS, "uart1_rts"),
+	PINCTRL_PIN(WMT_PIN_UART1_TXD, "uart1_txd"),
+	PINCTRL_PIN(WMT_PIN_UART1_CTS, "uart1_cts"),
+	PINCTRL_PIN(WMT_PIN_UART1_RXD, "uart1_rxd"),
+	PINCTRL_PIN(WMT_PIN_UART2_RTS, "uart2_rts"),
+	PINCTRL_PIN(WMT_PIN_UART2_TXD, "uart2_txd"),
+	PINCTRL_PIN(WMT_PIN_UART2_CTS, "uart2_cts"),
+	PINCTRL_PIN(WMT_PIN_UART2_RXD, "uart2_rxd"),
+	PINCTRL_PIN(WMT_PIN_UART3_RTS, "uart3_rts"),
+	PINCTRL_PIN(WMT_PIN_UART3_TXD, "uart3_txd"),
+	PINCTRL_PIN(WMT_PIN_UART3_CTS, "uart3_cts"),
+	PINCTRL_PIN(WMT_PIN_UART3_RXD, "uart3_rxd"),
+	PINCTRL_PIN(WMT_PIN_SD2CD, "sd2_cd"),
+	PINCTRL_PIN(WMT_PIN_SD2DATA3, "sd2_data3"),
+	PINCTRL_PIN(WMT_PIN_SD2DATA0, "sd2_data0"),
+	PINCTRL_PIN(WMT_PIN_SD2WP, "sd2_wp"),
+	PINCTRL_PIN(WMT_PIN_SD2DATA1, "sd2_data1"),
+	PINCTRL_PIN(WMT_PIN_SD2DATA2, "sd2_data2"),
+	PINCTRL_PIN(WMT_PIN_SD2CMD, "sd2_cmd"),
+	PINCTRL_PIN(WMT_PIN_SD2CLK, "sd2_clk"),
+	PINCTRL_PIN(WMT_PIN_SD2PWR, "sd2_pwr"),
+	PINCTRL_PIN(WMT_PIN_SD1CLK, "sd1_clk"),
+	PINCTRL_PIN(WMT_PIN_SD1CMD, "sd1_cmd"),
+	PINCTRL_PIN(WMT_PIN_SD1PWR, "sd1_pwr"),
+	PINCTRL_PIN(WMT_PIN_SD1WP, "sd1_wp"),
+	PINCTRL_PIN(WMT_PIN_SD1CD, "sd1_cd"),
+	PINCTRL_PIN(WMT_PIN_SPI0SS3, "spi0_ss3"),
+	PINCTRL_PIN(WMT_PIN_SPI0SS2, "spi0_ss2"),
+	PINCTRL_PIN(WMT_PIN_PWMOUT1, "pwmout1"),
+	PINCTRL_PIN(WMT_PIN_PWMOUT0, "pwmout0"),
+};
+
+/* Order of these names must match the above list */
+static const char * const wm8750_groups[] = {
+	"extgpio0",
+	"extgpio1",
+	"extgpio2",
+	"extgpio3",
+	"extgpio4",
+	"extgpio5",
+	"extgpio6",
+	"extgpio7",
+	"wakeup0",
+	"wakeup1",
+	"sd0_cd",
+	"vdout0",
+	"vdout1",
+	"vdout2",
+	"vdout3",
+	"vdout4",
+	"vdout5",
+	"vdout6",
+	"vdout7",
+	"vdout8",
+	"vdout9",
+	"vdout10",
+	"vdout11",
+	"vdout12",
+	"vdout13",
+	"vdout14",
+	"vdout15",
+	"vdout16",
+	"vdout17",
+	"vdout18",
+	"vdout19",
+	"vdout20",
+	"vdout21",
+	"vdout22",
+	"vdout23",
+	"vdin0",
+	"vdin1",
+	"vdin2",
+	"vdin3",
+	"vdin4",
+	"vdin5",
+	"vdin6",
+	"vdin7",
+	"spi0_mosi",
+	"spi0_miso",
+	"spi0_ss",
+	"spi0_clk",
+	"spi0_ssb",
+	"sd0_clk",
+	"sd0_cmd",
+	"sd0_wp",
+	"sd0_data0",
+	"sd0_data1",
+	"sd0_data2",
+	"sd0_data3",
+	"sd1_data0",
+	"sd1_data1",
+	"sd1_data2",
+	"sd1_data3",
+	"sd1_data4",
+	"sd1_data5",
+	"sd1_data6",
+	"sd1_data7",
+	"i2c0_scl",
+	"i2c0_sda",
+	"i2c1_scl",
+	"i2c1_sda",
+	"i2c2_scl",
+	"i2c2_sda",
+	"uart0_rts",
+	"uart0_txd",
+	"uart0_cts",
+	"uart0_rxd",
+	"uart1_rts",
+	"uart1_txd",
+	"uart1_cts",
+	"uart1_rxd",
+	"uart2_rts",
+	"uart2_txd",
+	"uart2_cts",
+	"uart2_rxd",
+	"uart3_rts",
+	"uart3_txd",
+	"uart3_cts",
+	"uart3_rxd",
+	"sd2_cd",
+	"sd2_data3",
+	"sd2_data0",
+	"sd2_wp",
+	"sd2_data1",
+	"sd2_data2",
+	"sd2_cmd",
+	"sd2_clk",
+	"sd2_pwr",
+	"sd1_clk",
+	"sd1_cmd",
+	"sd1_pwr",
+	"sd1_wp",
+	"sd1_cd",
+	"spi0_ss3",
+	"spi0_ss2",
+	"pwmout1",
+	"pwmout0",
+};
+
+static int wm8750_pinctrl_probe(struct platform_device *pdev)
+{
+	struct wmt_pinctrl_data *data;
+
+	data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
+	if (!data) {
+		dev_err(&pdev->dev, "failed to allocate data\n");
+		return -ENOMEM;
+	}
+
+	data->banks = wm8750_banks;
+	data->nbanks = ARRAY_SIZE(wm8750_banks);
+	data->pins = wm8750_pins;
+	data->npins = ARRAY_SIZE(wm8750_pins);
+	data->groups = wm8750_groups;
+	data->ngroups = ARRAY_SIZE(wm8750_groups);
+
+	return wmt_pinctrl_probe(pdev, data);
+}
+
+static int wm8750_pinctrl_remove(struct platform_device *pdev)
+{
+	return wmt_pinctrl_remove(pdev);
+}
+
+static struct of_device_id wmt_pinctrl_of_match[] = {
+	{ .compatible = "wm,wm8750-pinctrl" },
+	{ /* sentinel */ },
+};
+
+static struct platform_driver wmt_pinctrl_driver = {
+	.probe	= wm8750_pinctrl_probe,
+	.remove	= wm8750_pinctrl_remove,
+	.driver = {
+		.name	= "pinctrl-wm8750",
+		.owner	= THIS_MODULE,
+		.of_match_table	= wmt_pinctrl_of_match,
+	},
+};
+
+module_platform_driver(wmt_pinctrl_driver);
+
+MODULE_AUTHOR("Tony Prisk <linux at prisktech.co.nz>");
+MODULE_DESCRIPTION("Wondermedia WM8750 Pincontrol driver");
+MODULE_LICENSE("GPL v2");
+MODULE_DEVICE_TABLE(of, wmt_pinctrl_of_match);
diff --git a/drivers/pinctrl/vt8500/pinctrl-wm8850.c b/drivers/pinctrl/vt8500/pinctrl-wm8850.c
new file mode 100644
index 0000000..ecadce9c
--- /dev/null
+++ b/drivers/pinctrl/vt8500/pinctrl-wm8850.c
@@ -0,0 +1,388 @@
+/*
+ * Pinctrl data for Wondermedia WM8850 SoC
+ *
+ * Copyright (c) 2013 Tony Prisk <linux at prisktech.co.nz>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ */
+
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/pinctrl/pinctrl.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+
+#include "pinctrl-wmt.h"
+
+/*
+ * Describe the register offsets within the GPIO memory space
+ * The dedicated external GPIO's should always be listed in bank 0
+ * so they are exported in the 0..31 range which is what users
+ * expect.
+ *
+ * Do not reorder these banks as it will change the pin numbering
+ */
+static const struct wmt_pinctrl_bank_registers wm8850_banks[] = {
+	WMT_PINCTRL_BANK(0x40, 0x80, 0xC0, 0x00, 0x480, 0x4C0),		/* 0 */
+	WMT_PINCTRL_BANK(0x44, 0x84, 0xC4, 0x04, 0x484, 0x4C4),		/* 1 */
+	WMT_PINCTRL_BANK(0x48, 0x88, 0xC8, 0x08, 0x488, 0x4C8),		/* 2 */
+	WMT_PINCTRL_BANK(0x4C, 0x8C, 0xCC, 0x0C, 0x48C, 0x4CC),		/* 3 */
+	WMT_PINCTRL_BANK(0x50, 0x90, 0xD0, 0x10, 0x490, 0x4D0),		/* 4 */
+	WMT_PINCTRL_BANK(0x54, 0x94, 0xD4, 0x14, 0x494, 0x4D4),		/* 5 */
+	WMT_PINCTRL_BANK(0x58, 0x98, 0xD8, 0x18, 0x498, 0x4D8),		/* 6 */
+	WMT_PINCTRL_BANK(0x5C, 0x9C, 0xDC, 0x1C, 0x49C, 0x4DC),		/* 7 */
+	WMT_PINCTRL_BANK(0x60, 0xA0, 0xE0, 0x20, 0x4A0, 0x4E0),		/* 8 */
+	WMT_PINCTRL_BANK(0x70, 0xB0, 0xF0, 0x30, 0x4B0, 0x4F0),		/* 9 */
+	WMT_PINCTRL_BANK(0x7C, 0xBC, 0xDC, 0x3C, 0x4BC, 0x4FC),		/* 10 */
+};
+
+/* Please keep sorted by bank/bit */
+#define WMT_PIN_EXTGPIO0	WMT_PIN(0, 0)
+#define WMT_PIN_EXTGPIO1	WMT_PIN(0, 1)
+#define WMT_PIN_EXTGPIO2	WMT_PIN(0, 2)
+#define WMT_PIN_EXTGPIO3	WMT_PIN(0, 3)
+#define WMT_PIN_EXTGPIO4	WMT_PIN(0, 4)
+#define WMT_PIN_EXTGPIO5	WMT_PIN(0, 5)
+#define WMT_PIN_EXTGPIO6	WMT_PIN(0, 6)
+#define WMT_PIN_EXTGPIO7	WMT_PIN(0, 7)
+#define WMT_PIN_WAKEUP0		WMT_PIN(0, 16)
+#define WMT_PIN_WAKEUP1		WMT_PIN(0, 17)
+#define WMT_PIN_WAKEUP2		WMT_PIN(0, 18)
+#define WMT_PIN_WAKEUP3		WMT_PIN(0, 19)
+#define WMT_PIN_SUSGPIO0	WMT_PIN(0, 21)
+#define WMT_PIN_SUSGPIO1	WMT_PIN(0, 22)
+#define WMT_PIN_SD0CD		WMT_PIN(0, 28)
+#define WMT_PIN_VDOUT0		WMT_PIN(1, 0)
+#define WMT_PIN_VDOUT1		WMT_PIN(1, 1)
+#define WMT_PIN_VDOUT2		WMT_PIN(1, 2)
+#define WMT_PIN_VDOUT3		WMT_PIN(1, 3)
+#define WMT_PIN_VDOUT4		WMT_PIN(1, 4)
+#define WMT_PIN_VDOUT5		WMT_PIN(1, 5)
+#define WMT_PIN_VDOUT6		WMT_PIN(1, 6)
+#define WMT_PIN_VDOUT7		WMT_PIN(1, 7)
+#define WMT_PIN_VDOUT8		WMT_PIN(1, 8)
+#define WMT_PIN_VDOUT9		WMT_PIN(1, 9)
+#define WMT_PIN_VDOUT10		WMT_PIN(1, 10)
+#define WMT_PIN_VDOUT11		WMT_PIN(1, 11)
+#define WMT_PIN_VDOUT12		WMT_PIN(1, 12)
+#define WMT_PIN_VDOUT13		WMT_PIN(1, 13)
+#define WMT_PIN_VDOUT14		WMT_PIN(1, 14)
+#define WMT_PIN_VDOUT15		WMT_PIN(1, 15)
+#define WMT_PIN_VDOUT16		WMT_PIN(1, 16)
+#define WMT_PIN_VDOUT17		WMT_PIN(1, 17)
+#define WMT_PIN_VDOUT18		WMT_PIN(1, 18)
+#define WMT_PIN_VDOUT19		WMT_PIN(1, 19)
+#define WMT_PIN_VDOUT20		WMT_PIN(1, 20)
+#define WMT_PIN_VDOUT21		WMT_PIN(1, 21)
+#define WMT_PIN_VDOUT22		WMT_PIN(1, 22)
+#define WMT_PIN_VDOUT23		WMT_PIN(1, 23)
+#define WMT_PIN_VDIN0		WMT_PIN(2, 0)
+#define WMT_PIN_VDIN1		WMT_PIN(2, 1)
+#define WMT_PIN_VDIN2		WMT_PIN(2, 2)
+#define WMT_PIN_VDIN3		WMT_PIN(2, 3)
+#define WMT_PIN_VDIN4		WMT_PIN(2, 4)
+#define WMT_PIN_VDIN5		WMT_PIN(2, 5)
+#define WMT_PIN_VDIN6		WMT_PIN(2, 6)
+#define WMT_PIN_VDIN7		WMT_PIN(2, 7)
+#define WMT_PIN_SPI0_MOSI	WMT_PIN(2, 24)
+#define WMT_PIN_SPI0_MISO	WMT_PIN(2, 25)
+#define WMT_PIN_SPI0_SS		WMT_PIN(2, 26)
+#define WMT_PIN_SPI0_CLK	WMT_PIN(2, 27)
+#define WMT_PIN_SPI0_SSB	WMT_PIN(2, 28)
+#define WMT_PIN_SD0CLK		WMT_PIN(3, 17)
+#define WMT_PIN_SD0CMD		WMT_PIN(3, 18)
+#define WMT_PIN_SD0WP		WMT_PIN(3, 19)
+#define WMT_PIN_SD0DATA0	WMT_PIN(3, 20)
+#define WMT_PIN_SD0DATA1	WMT_PIN(3, 21)
+#define WMT_PIN_SD0DATA2	WMT_PIN(3, 22)
+#define WMT_PIN_SD0DATA3	WMT_PIN(3, 23)
+#define WMT_PIN_SD1DATA0	WMT_PIN(3, 24)
+#define WMT_PIN_SD1DATA1	WMT_PIN(3, 25)
+#define WMT_PIN_SD1DATA2	WMT_PIN(3, 26)
+#define WMT_PIN_SD1DATA3	WMT_PIN(3, 27)
+#define WMT_PIN_SD1DATA4	WMT_PIN(3, 28)
+#define WMT_PIN_SD1DATA5	WMT_PIN(3, 29)
+#define WMT_PIN_SD1DATA6	WMT_PIN(3, 30)
+#define WMT_PIN_SD1DATA7	WMT_PIN(3, 31)
+#define WMT_PIN_I2C0_SCL	WMT_PIN(5, 8)
+#define WMT_PIN_I2C0_SDA	WMT_PIN(5, 9)
+#define WMT_PIN_I2C1_SCL	WMT_PIN(5, 10)
+#define WMT_PIN_I2C1_SDA	WMT_PIN(5, 11)
+#define WMT_PIN_I2C2_SCL	WMT_PIN(5, 12)
+#define WMT_PIN_I2C2_SDA	WMT_PIN(5, 13)
+#define WMT_PIN_UART0_RTS	WMT_PIN(5, 16)
+#define WMT_PIN_UART0_TXD	WMT_PIN(5, 17)
+#define WMT_PIN_UART0_CTS	WMT_PIN(5, 18)
+#define WMT_PIN_UART0_RXD	WMT_PIN(5, 19)
+#define WMT_PIN_UART1_RTS	WMT_PIN(5, 20)
+#define WMT_PIN_UART1_TXD	WMT_PIN(5, 21)
+#define WMT_PIN_UART1_CTS	WMT_PIN(5, 22)
+#define WMT_PIN_UART1_RXD	WMT_PIN(5, 23)
+#define WMT_PIN_UART2_RTS	WMT_PIN(5, 24)
+#define WMT_PIN_UART2_TXD	WMT_PIN(5, 25)
+#define WMT_PIN_UART2_CTS	WMT_PIN(5, 26)
+#define WMT_PIN_UART2_RXD	WMT_PIN(5, 27)
+#define WMT_PIN_SD2WP		WMT_PIN(6, 3)
+#define WMT_PIN_SD2CMD		WMT_PIN(6, 6)
+#define WMT_PIN_SD2CLK		WMT_PIN(6, 7)
+#define WMT_PIN_SD2PWR		WMT_PIN(6, 9)
+#define WMT_PIN_SD1CLK		WMT_PIN(7, 0)
+#define WMT_PIN_SD1CMD		WMT_PIN(7, 1)
+#define WMT_PIN_SD1PWR		WMT_PIN(7, 10)
+#define WMT_PIN_SD1WP		WMT_PIN(7, 11)
+#define WMT_PIN_SD1CD		WMT_PIN(7, 12)
+#define WMT_PIN_PWMOUT1		WMT_PIN(7, 26)
+#define WMT_PIN_PWMOUT0		WMT_PIN(7, 27)
+
+static const struct pinctrl_pin_desc wm8850_pins[] = {
+	PINCTRL_PIN(WMT_PIN_EXTGPIO0, "extgpio0"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO1, "extgpio1"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO2, "extgpio2"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO3, "extgpio3"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO4, "extgpio4"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO5, "extgpio5"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO6, "extgpio6"),
+	PINCTRL_PIN(WMT_PIN_EXTGPIO7, "extgpio7"),
+	PINCTRL_PIN(WMT_PIN_WAKEUP0, "wakeup0"),
+	PINCTRL_PIN(WMT_PIN_WAKEUP1, "wakeup1"),
+	PINCTRL_PIN(WMT_PIN_WAKEUP2, "wakeup2"),
+	PINCTRL_PIN(WMT_PIN_WAKEUP3, "wakeup3"),
+	PINCTRL_PIN(WMT_PIN_SUSGPIO0, "susgpio0"),
+	PINCTRL_PIN(WMT_PIN_SUSGPIO1, "susgpio1"),
+	PINCTRL_PIN(WMT_PIN_SD0CD, "sd0_cd"),
+	PINCTRL_PIN(WMT_PIN_VDOUT0, "vdout0"),
+	PINCTRL_PIN(WMT_PIN_VDOUT1, "vdout1"),
+	PINCTRL_PIN(WMT_PIN_VDOUT2, "vdout2"),
+	PINCTRL_PIN(WMT_PIN_VDOUT3, "vdout3"),
+	PINCTRL_PIN(WMT_PIN_VDOUT4, "vdout4"),
+	PINCTRL_PIN(WMT_PIN_VDOUT5, "vdout5"),
+	PINCTRL_PIN(WMT_PIN_VDOUT6, "vdout6"),
+	PINCTRL_PIN(WMT_PIN_VDOUT7, "vdout7"),
+	PINCTRL_PIN(WMT_PIN_VDOUT8, "vdout8"),
+	PINCTRL_PIN(WMT_PIN_VDOUT9, "vdout9"),
+	PINCTRL_PIN(WMT_PIN_VDOUT10, "vdout10"),
+	PINCTRL_PIN(WMT_PIN_VDOUT11, "vdout11"),
+	PINCTRL_PIN(WMT_PIN_VDOUT12, "vdout12"),
+	PINCTRL_PIN(WMT_PIN_VDOUT13, "vdout13"),
+	PINCTRL_PIN(WMT_PIN_VDOUT14, "vdout14"),
+	PINCTRL_PIN(WMT_PIN_VDOUT15, "vdout15"),
+	PINCTRL_PIN(WMT_PIN_VDOUT16, "vdout16"),
+	PINCTRL_PIN(WMT_PIN_VDOUT17, "vdout17"),
+	PINCTRL_PIN(WMT_PIN_VDOUT18, "vdout18"),
+	PINCTRL_PIN(WMT_PIN_VDOUT19, "vdout19"),
+	PINCTRL_PIN(WMT_PIN_VDOUT20, "vdout20"),
+	PINCTRL_PIN(WMT_PIN_VDOUT21, "vdout21"),
+	PINCTRL_PIN(WMT_PIN_VDOUT22, "vdout22"),
+	PINCTRL_PIN(WMT_PIN_VDOUT23, "vdout23"),
+	PINCTRL_PIN(WMT_PIN_VDIN0, "vdin0"),
+	PINCTRL_PIN(WMT_PIN_VDIN1, "vdin1"),
+	PINCTRL_PIN(WMT_PIN_VDIN2, "vdin2"),
+	PINCTRL_PIN(WMT_PIN_VDIN3, "vdin3"),
+	PINCTRL_PIN(WMT_PIN_VDIN4, "vdin4"),
+	PINCTRL_PIN(WMT_PIN_VDIN5, "vdin5"),
+	PINCTRL_PIN(WMT_PIN_VDIN6, "vdin6"),
+	PINCTRL_PIN(WMT_PIN_VDIN7, "vdin7"),
+	PINCTRL_PIN(WMT_PIN_SPI0_MOSI, "spi0_mosi"),
+	PINCTRL_PIN(WMT_PIN_SPI0_MISO, "spi0_miso"),
+	PINCTRL_PIN(WMT_PIN_SPI0_SS, "spi0_ss"),
+	PINCTRL_PIN(WMT_PIN_SPI0_CLK, "spi0_clk"),
+	PINCTRL_PIN(WMT_PIN_SPI0_SSB, "spi0_ssb"),
+	PINCTRL_PIN(WMT_PIN_SD0CLK, "sd0_clk"),
+	PINCTRL_PIN(WMT_PIN_SD0CMD, "sd0_cmd"),
+	PINCTRL_PIN(WMT_PIN_SD0WP, "sd0_wp"),
+	PINCTRL_PIN(WMT_PIN_SD0DATA0, "sd0_data0"),
+	PINCTRL_PIN(WMT_PIN_SD0DATA1, "sd0_data1"),
+	PINCTRL_PIN(WMT_PIN_SD0DATA2, "sd0_data2"),
+	PINCTRL_PIN(WMT_PIN_SD0DATA3, "sd0_data3"),
+	PINCTRL_PIN(WMT_PIN_SD1DATA0, "sd1_data0"),
+	PINCTRL_PIN(WMT_PIN_SD1DATA1, "sd1_data1"),
+	PINCTRL_PIN(WMT_PIN_SD1DATA2, "sd1_data2"),
+	PINCTRL_PIN(WMT_PIN_SD1DATA3, "sd1_data3"),
+	PINCTRL_PIN(WMT_PIN_SD1DATA4, "sd1_data4"),
+	PINCTRL_PIN(WMT_PIN_SD1DATA5, "sd1_data5"),
+	PINCTRL_PIN(WMT_PIN_SD1DATA6, "sd1_data6"),
+	PINCTRL_PIN(WMT_PIN_SD1DATA7, "sd1_data7"),
+	PINCTRL_PIN(WMT_PIN_I2C0_SCL, "i2c0_scl"),
+	PINCTRL_PIN(WMT_PIN_I2C0_SDA, "i2c0_sda"),
+	PINCTRL_PIN(WMT_PIN_I2C1_SCL, "i2c1_scl"),
+	PINCTRL_PIN(WMT_PIN_I2C1_SDA, "i2c1_sda"),
+	PINCTRL_PIN(WMT_PIN_I2C2_SCL, "i2c2_scl"),
+	PINCTRL_PIN(WMT_PIN_I2C2_SDA, "i2c2_sda"),
+	PINCTRL_PIN(WMT_PIN_UART0_RTS, "uart0_rts"),
+	PINCTRL_PIN(WMT_PIN_UART0_TXD, "uart0_txd"),
+	PINCTRL_PIN(WMT_PIN_UART0_CTS, "uart0_cts"),
+	PINCTRL_PIN(WMT_PIN_UART0_RXD, "uart0_rxd"),
+	PINCTRL_PIN(WMT_PIN_UART1_RTS, "uart1_rts"),
+	PINCTRL_PIN(WMT_PIN_UART1_TXD, "uart1_txd"),
+	PINCTRL_PIN(WMT_PIN_UART1_CTS, "uart1_cts"),
+	PINCTRL_PIN(WMT_PIN_UART1_RXD, "uart1_rxd"),
+	PINCTRL_PIN(WMT_PIN_UART2_RTS, "uart2_rts"),
+	PINCTRL_PIN(WMT_PIN_UART2_TXD, "uart2_txd"),
+	PINCTRL_PIN(WMT_PIN_UART2_CTS, "uart2_cts"),
+	PINCTRL_PIN(WMT_PIN_UART2_RXD, "uart2_rxd"),
+	PINCTRL_PIN(WMT_PIN_SD2WP, "sd2_wp"),
+	PINCTRL_PIN(WMT_PIN_SD2CMD, "sd2_cmd"),
+	PINCTRL_PIN(WMT_PIN_SD2CLK, "sd2_clk"),
+	PINCTRL_PIN(WMT_PIN_SD2PWR, "sd2_pwr"),
+	PINCTRL_PIN(WMT_PIN_SD1CLK, "sd1_clk"),
+	PINCTRL_PIN(WMT_PIN_SD1CMD, "sd1_cmd"),
+	PINCTRL_PIN(WMT_PIN_SD1PWR, "sd1_pwr"),
+	PINCTRL_PIN(WMT_PIN_SD1WP, "sd1_wp"),
+	PINCTRL_PIN(WMT_PIN_SD1CD, "sd1_cd"),
+	PINCTRL_PIN(WMT_PIN_PWMOUT1, "pwmout1"),
+	PINCTRL_PIN(WMT_PIN_PWMOUT0, "pwmout0"),
+};
+
+/* Order of these names must match the above list */
+static const char * const wm8850_groups[] = {
+	"extgpio0",
+	"extgpio1",
+	"extgpio2",
+	"extgpio3",
+	"extgpio4",
+	"extgpio5",
+	"extgpio6",
+	"extgpio7",
+	"wakeup0",
+	"wakeup1",
+	"wakeup2",
+	"wakeup3",
+	"susgpio0",
+	"susgpio1",
+	"sd0_cd",
+	"vdout0",
+	"vdout1",
+	"vdout2",
+	"vdout3",
+	"vdout4",
+	"vdout5",
+	"vdout6",
+	"vdout7",
+	"vdout8",
+	"vdout9",
+	"vdout10",
+	"vdout11",
+	"vdout12",
+	"vdout13",
+	"vdout14",
+	"vdout15",
+	"vdout16",
+	"vdout17",
+	"vdout18",
+	"vdout19",
+	"vdout20",
+	"vdout21",
+	"vdout22",
+	"vdout23",
+	"vdin0",
+	"vdin1",
+	"vdin2",
+	"vdin3",
+	"vdin4",
+	"vdin5",
+	"vdin6",
+	"vdin7",
+	"spi0_mosi",
+	"spi0_miso",
+	"spi0_ss",
+	"spi0_clk",
+	"spi0_ssb",
+	"sd0_clk",
+	"sd0_cmd",
+	"sd0_wp",
+	"sd0_data0",
+	"sd0_data1",
+	"sd0_data2",
+	"sd0_data3",
+	"sd1_data0",
+	"sd1_data1",
+	"sd1_data2",
+	"sd1_data3",
+	"sd1_data4",
+	"sd1_data5",
+	"sd1_data6",
+	"sd1_data7",
+	"i2c0_scl",
+	"i2c0_sda",
+	"i2c1_scl",
+	"i2c1_sda",
+	"i2c2_scl",
+	"i2c2_sda",
+	"uart0_rts",
+	"uart0_txd",
+	"uart0_cts",
+	"uart0_rxd",
+	"uart1_rts",
+	"uart1_txd",
+	"uart1_cts",
+	"uart1_rxd",
+	"uart2_rts",
+	"uart2_txd",
+	"uart2_cts",
+	"uart2_rxd",
+	"sd2_wp",
+	"sd2_cmd",
+	"sd2_clk",
+	"sd2_pwr",
+	"sd1_clk",
+	"sd1_cmd",
+	"sd1_pwr",
+	"sd1_wp",
+	"sd1_cd",
+	"pwmout1",
+	"pwmout0",
+};
+
+static int wm8850_pinctrl_probe(struct platform_device *pdev)
+{
+	struct wmt_pinctrl_data *data;
+
+	data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
+	if (!data) {
+		dev_err(&pdev->dev, "failed to allocate data\n");
+		return -ENOMEM;
+	}
+
+	data->banks = wm8850_banks;
+	data->nbanks = ARRAY_SIZE(wm8850_banks);
+	data->pins = wm8850_pins;
+	data->npins = ARRAY_SIZE(wm8850_pins);
+	data->groups = wm8850_groups;
+	data->ngroups = ARRAY_SIZE(wm8850_groups);
+
+	return wmt_pinctrl_probe(pdev, data);
+}
+
+static int wm8850_pinctrl_remove(struct platform_device *pdev)
+{
+	return wmt_pinctrl_remove(pdev);
+}
+
+static struct of_device_id wmt_pinctrl_of_match[] = {
+	{ .compatible = "wm,wm8850-pinctrl" },
+	{ /* sentinel */ },
+};
+
+static struct platform_driver wmt_pinctrl_driver = {
+	.probe	= wm8850_pinctrl_probe,
+	.remove	= wm8850_pinctrl_remove,
+	.driver = {
+		.name	= "pinctrl-wm8850",
+		.owner	= THIS_MODULE,
+		.of_match_table	= wmt_pinctrl_of_match,
+	},
+};
+
+module_platform_driver(wmt_pinctrl_driver);
+
+MODULE_AUTHOR("Tony Prisk <linux at prisktech.co.nz>");
+MODULE_DESCRIPTION("Wondermedia WM8850 Pincontrol driver");
+MODULE_LICENSE("GPL v2");
+MODULE_DEVICE_TABLE(of, wmt_pinctrl_of_match);
diff --git a/drivers/pinctrl/vt8500/pinctrl-wmt.c b/drivers/pinctrl/vt8500/pinctrl-wmt.c
new file mode 100644
index 0000000..14400a7
--- /dev/null
+++ b/drivers/pinctrl/vt8500/pinctrl-wmt.c
@@ -0,0 +1,632 @@
+/*
+ * Pinctrl driver for the Wondermedia SoC's
+ *
+ * Copyright (c) 2013 Tony Prisk <linux at prisktech.co.nz>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ */
+
+#include <linux/err.h>
+#include <linux/gpio.h>
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/irq.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_irq.h>
+#include <linux/pinctrl/consumer.h>
+#include <linux/pinctrl/machine.h>
+#include <linux/pinctrl/pinconf.h>
+#include <linux/pinctrl/pinconf-generic.h>
+#include <linux/pinctrl/pinctrl.h>
+#include <linux/pinctrl/pinmux.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+
+#include "pinctrl-wmt.h"
+
+static inline void wmt_setbits(struct wmt_pinctrl_data *data, u32 reg,
+				 u32 mask)
+{
+	u32 val;
+
+	val = readl_relaxed(data->base + reg);
+	val |= mask;
+	writel_relaxed(val, data->base + reg);
+}
+
+static inline void wmt_clearbits(struct wmt_pinctrl_data *data, u32 reg,
+				   u32 mask)
+{
+	u32 val;
+
+	val = readl_relaxed(data->base + reg);
+	val &= ~mask;
+	writel_relaxed(val, data->base + reg);
+}
+
+enum wmt_func_sel {
+	WMT_FSEL_GPIO_IN = 0,
+	WMT_FSEL_GPIO_OUT = 1,
+	WMT_FSEL_ALT = 2,
+	WMT_FSEL_COUNT = 3,
+};
+
+static const char * const wmt_functions[WMT_FSEL_COUNT] = {
+	[WMT_FSEL_GPIO_IN] = "gpio_in",
+	[WMT_FSEL_GPIO_OUT] = "gpio_out",
+	[WMT_FSEL_ALT] = "alt",
+};
+
+static int wmt_pmx_get_functions_count(struct pinctrl_dev *pctldev)
+{
+	return WMT_FSEL_COUNT;
+}
+
+static const char *wmt_pmx_get_function_name(struct pinctrl_dev *pctldev,
+					     unsigned selector)
+{
+	return wmt_functions[selector];
+}
+
+static int wmt_pmx_get_function_groups(struct pinctrl_dev *pctldev,
+				       unsigned selector,
+				       const char * const **groups,
+				       unsigned * const num_groups)
+{
+	struct wmt_pinctrl_data *data = pinctrl_dev_get_drvdata(pctldev);
+
+	/* every pin does every function */
+	*groups = data->groups;
+	*num_groups = data->ngroups;
+
+	return 0;
+}
+
+static int wmt_set_pinmux(struct wmt_pinctrl_data *data, unsigned func,
+			  unsigned pin)
+{
+	u32 bank = WMT_BANK_FROM_PIN(pin);
+	u32 bit = WMT_BIT_FROM_PIN(pin);
+	u32 reg_en = data->banks[bank].reg_en;
+	u32 reg_dir = data->banks[bank].reg_dir;
+
+	if (reg_dir == NO_REG) {
+		dev_err(data->dev, "pin:%d no direction register defined\n",
+			pin);
+		return -EINVAL;
+	}
+
+	/*
+	 * If reg_en == NO_REG, we assume it is a dedicated GPIO and cannot be
+	 * disabled (as on VT8500) and that no alternate function is available.
+	 */
+	switch (func) {
+	case WMT_FSEL_GPIO_IN:
+		if (reg_en != NO_REG)
+			wmt_setbits(data, reg_en, BIT(bit));
+		wmt_clearbits(data, reg_dir, BIT(bit));
+		break;
+	case WMT_FSEL_GPIO_OUT:
+		if (reg_en != NO_REG)
+			wmt_setbits(data, reg_en, BIT(bit));
+		wmt_setbits(data, reg_dir, BIT(bit));
+		break;
+	case WMT_FSEL_ALT:
+		if (reg_en == NO_REG) {
+			dev_err(data->dev, "pin:%d no alt function available\n",
+				pin);
+			return -EINVAL;
+		}
+		wmt_clearbits(data, reg_en, BIT(bit));
+	}
+
+	return 0;
+}
+
+static int wmt_pmx_enable(struct pinctrl_dev *pctldev,
+			  unsigned func_selector,
+			  unsigned group_selector)
+{
+	struct wmt_pinctrl_data *data = pinctrl_dev_get_drvdata(pctldev);
+	u32 pinnum = data->pins[group_selector].number;
+
+	return wmt_set_pinmux(data, func_selector, pinnum);
+}
+
+static void wmt_pmx_disable(struct pinctrl_dev *pctldev,
+			    unsigned func_selector,
+			    unsigned group_selector)
+{
+	struct wmt_pinctrl_data *data = pinctrl_dev_get_drvdata(pctldev);
+	u32 pinnum = data->pins[group_selector].number;
+
+	/* disable by setting GPIO_IN */
+	wmt_set_pinmux(data, WMT_FSEL_GPIO_IN, pinnum);
+}
+
+static void wmt_pmx_gpio_disable_free(struct pinctrl_dev *pctldev,
+				      struct pinctrl_gpio_range *range,
+				      unsigned offset)
+{
+	struct wmt_pinctrl_data *data = pinctrl_dev_get_drvdata(pctldev);
+
+	/* disable by setting GPIO_IN */
+	wmt_set_pinmux(data, WMT_FSEL_GPIO_IN, offset);
+}
+
+static int wmt_pmx_gpio_set_direction(struct pinctrl_dev *pctldev,
+				      struct pinctrl_gpio_range *range,
+				      unsigned offset,
+				      bool input)
+{
+	struct wmt_pinctrl_data *data = pinctrl_dev_get_drvdata(pctldev);
+
+	wmt_set_pinmux(data, (input ? WMT_FSEL_GPIO_IN : WMT_FSEL_GPIO_OUT),
+		       offset);
+
+	return 0;
+}
+
+static struct pinmux_ops wmt_pinmux_ops = {
+	.get_functions_count = wmt_pmx_get_functions_count,
+	.get_function_name = wmt_pmx_get_function_name,
+	.get_function_groups = wmt_pmx_get_function_groups,
+	.enable = wmt_pmx_enable,
+	.disable = wmt_pmx_disable,
+	.gpio_disable_free = wmt_pmx_gpio_disable_free,
+	.gpio_set_direction = wmt_pmx_gpio_set_direction,
+};
+
+static int wmt_get_groups_count(struct pinctrl_dev *pctldev)
+{
+	struct wmt_pinctrl_data *data = pinctrl_dev_get_drvdata(pctldev);
+
+	return data->ngroups;
+}
+
+static const char *wmt_get_group_name(struct pinctrl_dev *pctldev,
+				      unsigned selector)
+{
+	struct wmt_pinctrl_data *data = pinctrl_dev_get_drvdata(pctldev);
+
+	return data->groups[selector];
+}
+
+static int wmt_get_group_pins(struct pinctrl_dev *pctldev,
+			      unsigned selector,
+			      const unsigned **pins,
+			      unsigned *num_pins)
+{
+	struct wmt_pinctrl_data *data = pinctrl_dev_get_drvdata(pctldev);
+
+	*pins = &data->pins[selector].number;
+	*num_pins = 1;
+
+	return 0;
+}
+
+static int wmt_pctl_find_group_by_pin(struct wmt_pinctrl_data *data, u32 pin)
+{
+	int i;
+
+	for (i = 0; i < data->npins; i++) {
+		if (data->pins[i].number == pin)
+			return i;
+	}
+
+	return -EINVAL;
+}
+
+static int wmt_pctl_dt_node_to_map_func(struct wmt_pinctrl_data *data,
+					struct device_node *np,
+					u32 pin, u32 fnum,
+					struct pinctrl_map **maps)
+{
+	int group;
+	struct pinctrl_map *map = *maps;
+
+	if (fnum >= ARRAY_SIZE(wmt_functions)) {
+		dev_err(data->dev, "invalid wm,function %d\n", fnum);
+		return -EINVAL;
+	}
+
+	group = wmt_pctl_find_group_by_pin(data, pin);
+	if (group < 0) {
+		dev_err(data->dev, "unable to match pin %d to group\n", pin);
+		return group;
+	}
+
+	map->type = PIN_MAP_TYPE_MUX_GROUP;
+	map->data.mux.group = data->groups[group];
+	map->data.mux.function = wmt_functions[fnum];
+	(*maps)++;
+
+	return 0;
+}
+
+static int wmt_pctl_dt_node_to_map_pull(struct wmt_pinctrl_data *data,
+					struct device_node *np,
+					u32 pin, u32 pull,
+					struct pinctrl_map **maps)
+{
+	int group;
+	unsigned long *configs;
+	struct pinctrl_map *map = *maps;
+
+	if (pull > 2) {
+		dev_err(data->dev, "invalid wm,pull %d\n", pull);
+		return -EINVAL;
+	}
+
+	group = wmt_pctl_find_group_by_pin(data, pin);
+	if (group < 0) {
+		dev_err(data->dev, "unable to match pin %d to group\n", pin);
+		return group;
+	}
+
+	configs = kzalloc(sizeof(*configs), GFP_KERNEL);
+	if (!configs)
+		return -ENOMEM;
+
+	configs[0] = pull;
+
+	map->type = PIN_MAP_TYPE_CONFIGS_PIN;
+	map->data.configs.group_or_pin = data->groups[group];
+	map->data.configs.configs = configs;
+	map->data.configs.num_configs = 1;
+	(*maps)++;
+
+	return 0;
+}
+
+static void wmt_pctl_dt_free_map(struct pinctrl_dev *pctldev,
+				 struct pinctrl_map *maps,
+				 unsigned num_maps)
+{
+	int i;
+
+	for (i = 0; i < num_maps; i++)
+		if (maps[i].type == PIN_MAP_TYPE_CONFIGS_PIN)
+			kfree(maps[i].data.configs.configs);
+
+	kfree(maps);
+}
+
+static int wmt_pctl_dt_node_to_map(struct pinctrl_dev *pctldev,
+				   struct device_node *np,
+				   struct pinctrl_map **map,
+				   unsigned *num_maps)
+{
+	struct pinctrl_map *maps, *cur_map;
+	struct property *pins, *funcs, *pulls;
+	u32 pin, func, pull;
+	int num_pins, num_funcs, num_pulls, maps_per_pin;
+	int i, err;
+	struct wmt_pinctrl_data *data = pinctrl_dev_get_drvdata(pctldev);
+
+	pins = of_find_property(np, "wm,pins", NULL);
+	if (!pins) {
+		dev_err(data->dev, "missing wmt,pins property\n");
+		return -EINVAL;
+	}
+
+	funcs = of_find_property(np, "wm,function", NULL);
+	pulls = of_find_property(np, "wm,pull", NULL);
+
+	if (!funcs && !pulls) {
+		dev_err(data->dev, "neither wm,function nor wm,pull specified\n");
+		return -EINVAL;
+	}
+
+	/*
+	 * The following lines calculate how many values are defined for each
+	 * of the properties.
+	 */
+	num_pins = pins->length / sizeof(u32);
+	num_funcs = funcs ? (funcs->length / sizeof(u32)) : 0;
+	num_pulls = pulls ? (pulls->length / sizeof(u32)) : 0;
+
+	if (num_funcs > 1 && num_funcs != num_pins) {
+		dev_err(data->dev, "wm,function must have 1 or %d entries\n",
+			num_pins);
+		return -EINVAL;
+	}
+
+	if (num_pulls > 1 && num_pulls != num_pins) {
+		dev_err(data->dev, "wm,pull must have 1 or %d entries\n",
+			num_pins);
+		return -EINVAL;
+	}
+
+	maps_per_pin = 0;
+	if (num_funcs)
+		maps_per_pin++;
+	if (num_pulls)
+		maps_per_pin++;
+
+	cur_map = maps = kzalloc(num_pins * maps_per_pin * sizeof(*maps),
+				 GFP_KERNEL);
+	if (!maps)
+		return -ENOMEM;
+
+	for (i = 0; i < num_pins; i++) {
+		err = of_property_read_u32_index(np, "wm,pins", i, &pin);
+		if (err)
+			goto fail;
+
+		if (pin >= (data->nbanks * 32)) {
+			dev_err(data->dev, "invalid wm,pins value\n");
+			err = -EINVAL;
+			goto fail;
+		}
+
+		if (num_funcs) {
+			err = of_property_read_u32_index(np, "wm,function",
+						(num_funcs > 1 ? i : 0), &func);
+			if (err)
+				goto fail;
+
+			err = wmt_pctl_dt_node_to_map_func(data, np, pin, func,
+							   &cur_map);
+			if (err)
+				goto fail;
+		}
+
+		if (num_pulls) {
+			err = of_property_read_u32_index(np, "wm,pull",
+						(num_pulls > 1 ? i : 0), &pull);
+			if (err)
+				goto fail;
+
+			err = wmt_pctl_dt_node_to_map_pull(data, np, pin, pull,
+							   &cur_map);
+			if (err)
+				goto fail;
+		}
+	}
+	*map = maps;
+	*num_maps = num_pins * maps_per_pin;
+	return 0;
+
+/*
+ * The fail path removes any maps that have been allocated. The fail path is
+ * only called from code after maps has been kzalloc'd. It is also safe to
+ * pass 'num_pins * maps_per_pin' as the map count even though we probably
+ * failed before all the mappings were read as all maps are allocated at once,
+ * and configs are only allocated for .type = PIN_MAP_TYPE_CONFIGS_PIN - there
+ * is no failpath where a config can be allocated without .type being set.
+ */
+fail:
+	wmt_pctl_dt_free_map(pctldev, maps, num_pins * maps_per_pin);
+	return err;
+}
+
+static struct pinctrl_ops wmt_pctl_ops = {
+	.get_groups_count = wmt_get_groups_count,
+	.get_group_name	= wmt_get_group_name,
+	.get_group_pins	= wmt_get_group_pins,
+	.dt_node_to_map = wmt_pctl_dt_node_to_map,
+	.dt_free_map = wmt_pctl_dt_free_map,
+};
+
+static int wmt_pinconf_get(struct pinctrl_dev *pctldev, unsigned pin,
+			   unsigned long *config)
+{
+	return -ENOTSUPP;
+}
+
+static int wmt_pinconf_set(struct pinctrl_dev *pctldev, unsigned pin,
+			   unsigned long config)
+{
+	struct wmt_pinctrl_data *data = pinctrl_dev_get_drvdata(pctldev);
+	enum pin_config_param param = pinconf_to_config_param(config);
+	u16 arg = pinconf_to_config_argument(config);
+	u32 bank = WMT_BANK_FROM_PIN(pin);
+	u32 bit = WMT_BIT_FROM_PIN(pin);
+	u32 reg_pull_en = data->banks[bank].reg_pull_en;
+	u32 reg_pull_cfg = data->banks[bank].reg_pull_cfg;
+
+	if ((reg_pull_en == NO_REG) || (reg_pull_cfg == NO_REG)) {
+		dev_err(data->dev, "bias functions not supported on pin %d\n",
+			pin);
+		return -EINVAL;
+	}
+
+	if ((param == PIN_CONFIG_BIAS_PULL_DOWN) ||
+	    (param == PIN_CONFIG_BIAS_PULL_UP)) {
+		if (arg == 0)
+			param = PIN_CONFIG_BIAS_DISABLE;
+	}
+
+	switch (param) {
+	case PIN_CONFIG_BIAS_DISABLE:
+		wmt_clearbits(data, reg_pull_en, BIT(bit));
+		break;
+	case PIN_CONFIG_BIAS_PULL_DOWN:
+		wmt_clearbits(data, reg_pull_cfg, BIT(bit));
+		wmt_setbits(data, reg_pull_en, BIT(bit));
+		break;
+	case PIN_CONFIG_BIAS_PULL_UP:
+		wmt_setbits(data, reg_pull_cfg, BIT(bit));
+		wmt_setbits(data, reg_pull_en, BIT(bit));
+		break;
+	default:
+		dev_err(data->dev, "unknown pinconf param\n");
+		return -EINVAL;
+	}
+
+	return 0;
+}
+
+static struct pinconf_ops wmt_pinconf_ops = {
+	.pin_config_get = wmt_pinconf_get,
+	.pin_config_set = wmt_pinconf_set,
+};
+
+static struct pinctrl_desc wmt_desc = {
+	.owner = THIS_MODULE,
+	.name = "pinctrl-wmt",
+	.pctlops = &wmt_pctl_ops,
+	.pmxops = &wmt_pinmux_ops,
+	.confops = &wmt_pinconf_ops,
+};
+
+static int wmt_gpio_request(struct gpio_chip *chip, unsigned offset)
+{
+	return pinctrl_request_gpio(chip->base + offset);
+}
+
+static void wmt_gpio_free(struct gpio_chip *chip, unsigned offset)
+{
+	pinctrl_free_gpio(chip->base + offset);
+}
+
+static int wmt_gpio_get_direction(struct gpio_chip *chip, unsigned offset)
+{
+	struct wmt_pinctrl_data *data = dev_get_drvdata(chip->dev);
+	u32 bank = WMT_BANK_FROM_PIN(offset);
+	u32 bit = WMT_BIT_FROM_PIN(offset);
+	u32 reg_dir = data->banks[bank].reg_dir;
+	u32 val;
+
+	val = readl_relaxed(data->base + reg_dir);
+	if (val & BIT(bit))
+		return GPIOF_DIR_OUT;
+	else
+		return GPIOF_DIR_IN;
+}
+
+static int wmt_gpio_direction_input(struct gpio_chip *chip, unsigned offset)
+{
+	return pinctrl_gpio_direction_input(chip->base + offset);
+}
+
+static int wmt_gpio_direction_output(struct gpio_chip *chip, unsigned offset,
+				     int value)
+{
+	return pinctrl_gpio_direction_output(chip->base + offset);
+}
+
+static int wmt_gpio_get_value(struct gpio_chip *chip, unsigned offset)
+{
+	struct wmt_pinctrl_data *data = dev_get_drvdata(chip->dev);
+	u32 bank = WMT_BANK_FROM_PIN(offset);
+	u32 bit = WMT_BIT_FROM_PIN(offset);
+	u32 reg_data_in = data->banks[bank].reg_data_in;
+
+	if (reg_data_in == NO_REG) {
+		dev_err(data->dev, "no data in register defined\n");
+		return -EINVAL;
+	}
+
+	return !!(readl_relaxed(data->base + reg_data_in) & BIT(bit));
+}
+
+static void wmt_gpio_set_value(struct gpio_chip *chip, unsigned offset,
+			       int val)
+{
+	struct wmt_pinctrl_data *data = dev_get_drvdata(chip->dev);
+	u32 bank = WMT_BANK_FROM_PIN(offset);
+	u32 bit = WMT_BIT_FROM_PIN(offset);
+	u32 reg_data_out = data->banks[bank].reg_data_out;
+
+	if (reg_data_out == NO_REG) {
+		dev_err(data->dev, "no data out register defined\n");
+		return;
+	}
+
+	if (val)
+		wmt_setbits(data, reg_data_out, BIT(bit));
+	else
+		wmt_clearbits(data, reg_data_out, BIT(bit));
+}
+
+static struct gpio_chip wmt_gpio_chip = {
+	.label = "gpio-wmt",
+	.owner = THIS_MODULE,
+	.request = wmt_gpio_request,
+	.free = wmt_gpio_free,
+	.get_direction = wmt_gpio_get_direction,
+	.direction_input = wmt_gpio_direction_input,
+	.direction_output = wmt_gpio_direction_output,
+	.get = wmt_gpio_get_value,
+	.set = wmt_gpio_set_value,
+	.can_sleep = 0,
+};
+
+int wmt_pinctrl_probe(struct platform_device *pdev,
+		      struct wmt_pinctrl_data *data)
+{
+	int err;
+	struct resource *res;
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	data->base = devm_request_and_ioremap(&pdev->dev, res);
+	if (!data->base) {
+		dev_err(&pdev->dev, "failed to map memory resource\n");
+		return -EBUSY;
+	}
+
+	wmt_desc.pins = data->pins;
+	wmt_desc.npins = data->npins;
+
+	data->gpio_chip = wmt_gpio_chip;
+	data->gpio_chip.dev = &pdev->dev;
+	data->gpio_chip.of_node = pdev->dev.of_node;
+	data->gpio_chip.ngpio = data->nbanks * 32;
+
+	platform_set_drvdata(pdev, data);
+
+	data->dev = &pdev->dev;
+
+	data->pctl_dev = pinctrl_register(&wmt_desc, &pdev->dev, data);
+	if (IS_ERR(data->pctl_dev)) {
+		dev_err(&pdev->dev, "Failed to register pinctrl\n");
+		return -EINVAL;
+	}
+
+	err = gpiochip_add(&data->gpio_chip);
+	if (err) {
+		dev_err(&pdev->dev, "could not add GPIO chip\n");
+		goto fail_gpio;
+	}
+
+	err = gpiochip_add_pin_range(&data->gpio_chip, dev_name(data->dev),
+				     0, 0, data->nbanks * 32);
+	if (err)
+		goto fail_range;
+
+	dev_info(&pdev->dev, "Pin controller initialized\n");
+
+	return 0;
+
+fail_range:
+	err = gpiochip_remove(&data->gpio_chip);
+	if (err)
+		dev_err(&pdev->dev, "failed to remove gpio chip\n");
+fail_gpio:
+	pinctrl_unregister(data->pctl_dev);
+	return err;
+}
+
+int wmt_pinctrl_remove(struct platform_device *pdev)
+{
+	struct wmt_pinctrl_data *data = platform_get_drvdata(pdev);
+	int err;
+
+	err = gpiochip_remove(&data->gpio_chip);
+	if (err)
+		dev_err(&pdev->dev, "failed to remove gpio chip\n");
+
+	pinctrl_unregister(data->pctl_dev);
+
+	return 0;
+}
diff --git a/drivers/pinctrl/vt8500/pinctrl-wmt.h b/drivers/pinctrl/vt8500/pinctrl-wmt.h
new file mode 100644
index 0000000..41f5f2d
--- /dev/null
+++ b/drivers/pinctrl/vt8500/pinctrl-wmt.h
@@ -0,0 +1,79 @@
+/*
+ * Pinctrl driver for the Wondermedia SoC's
+ *
+ * Copyright (c) 2013 Tony Prisk <linux at prisktech.co.nz>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ */
+
+#include <linux/gpio.h>
+
+/* VT8500 has no enable register in the extgpio bank. */
+#define NO_REG	0xFFFF
+
+#define WMT_PINCTRL_BANK(__en, __dir, __dout, __din, __pen, __pcfg)	\
+{									\
+	.reg_en		= __en,						\
+	.reg_dir	= __dir,					\
+	.reg_data_out	= __dout,					\
+	.reg_data_in	= __din,					\
+	.reg_pull_en	= __pen,					\
+	.reg_pull_cfg	= __pcfg,					\
+}
+
+/* Encode/decode the bank/bit pairs into a pin value */
+#define WMT_PIN(__bank, __offset)	((__bank << 5) | __offset)
+#define WMT_BANK_FROM_PIN(__pin)	(__pin >> 5)
+#define WMT_BIT_FROM_PIN(__pin)		(__pin & 0x1f)
+
+#define WMT_GROUP(__name, __data)		\
+{						\
+	.name = __name,				\
+	.pins = __data,				\
+	.npins = ARRAY_SIZE(__data),		\
+}
+
+struct wmt_pinctrl_bank_registers {
+	u32	reg_en;
+	u32	reg_dir;
+	u32	reg_data_out;
+	u32	reg_data_in;
+
+	u32	reg_pull_en;
+	u32	reg_pull_cfg;
+};
+
+struct wmt_pinctrl_group {
+	const char *name;
+	const unsigned int *pins;
+	const unsigned npins;
+};
+
+struct wmt_pinctrl_data {
+	struct device *dev;
+	struct pinctrl_dev *pctl_dev;
+
+	/* must be initialized before calling wmt_pinctrl_probe */
+	void __iomem *base;
+	const struct wmt_pinctrl_bank_registers *banks;
+	const struct pinctrl_pin_desc *pins;
+	const char * const *groups;
+
+	u32 nbanks;
+	u32 npins;
+	u32 ngroups;
+
+	struct gpio_chip gpio_chip;
+	struct pinctrl_gpio_range gpio_range;
+};
+
+int wmt_pinctrl_probe(struct platform_device *pdev,
+		      struct wmt_pinctrl_data *data);
+int wmt_pinctrl_remove(struct platform_device *pdev);
-- 
1.7.9.5



From magnus.damm at gmail.com  Wed Apr  3 02:32:46 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Wed, 03 Apr 2013 15:32:46 +0900
Subject: [PATCH 00/04] ARM: shmobile: pinmux platform device cleanups
Message-ID: <20130403063246.2500.65318.sendpatchset@w520>

ARM: shmobile: pinmux platform device cleanups

[PATCH 01/04] ARM: shmobile: r8a7740 pinmux platform device cleanup
[PATCH 02/04] ARM: shmobile: r8a7779 pinmux platform device cleanup
[PATCH 03/04] ARM: shmobile: sh7372 pinmux platform device cleanup
[PATCH 04/04] ARM: shmobile: sh73a0 pinmux platform device cleanup

This series simply cleans up the pinmux platform device handling
to save a couple of lines. Compile time tested on each SoC.

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 Written against renesas-next-20130403 in renesas.git
 
 arch/arm/mach-shmobile/setup-r8a7740.c |   24 +++++-------------------
 arch/arm/mach-shmobile/setup-r8a7779.c |   19 ++++---------------
 arch/arm/mach-shmobile/setup-sh7372.c  |   24 +++++-------------------
 arch/arm/mach-shmobile/setup-sh73a0.c  |   25 ++++++-------------------
 4 files changed, 20 insertions(+), 72 deletions(-)


From magnus.damm at gmail.com  Wed Apr  3 02:32:58 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Wed, 03 Apr 2013 15:32:58 +0900
Subject: [PATCH 01/04] ARM: shmobile: r8a7740 pinmux platform device cleanup
In-Reply-To: <20130403063246.2500.65318.sendpatchset@w520>
References: <20130403063246.2500.65318.sendpatchset@w520>
Message-ID: <20130403063258.2500.17414.sendpatchset@w520>

From: Magnus Damm <damm at opensource.se>

Use DEFINE_RES_MEM() and platform_device_register_simple()
to save a couple of lines of code.

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 arch/arm/mach-shmobile/setup-r8a7740.c |   24 +++++-------------------
 1 file changed, 5 insertions(+), 19 deletions(-)

--- 0001/arch/arm/mach-shmobile/setup-r8a7740.c
+++ work/arch/arm/mach-shmobile/setup-r8a7740.c	2013-04-03 15:01:50.000000000 +0900
@@ -70,29 +70,15 @@ void __init r8a7740_map_io(void)
 }
 
 /* PFC */
-static struct resource r8a7740_pfc_resources[] = {
-	[0] = {
-		.start	= 0xe6050000,
-		.end	= 0xe6057fff,
-		.flags	= IORESOURCE_MEM,
-	},
-	[1] = {
-		.start	= 0xe605800c,
-		.end	= 0xe605802b,
-		.flags	= IORESOURCE_MEM,
-	}
-};
-
-static struct platform_device r8a7740_pfc_device = {
-	.name		= "pfc-r8a7740",
-	.id		= -1,
-	.resource	= r8a7740_pfc_resources,
-	.num_resources	= ARRAY_SIZE(r8a7740_pfc_resources),
+static const struct resource pfc_resources[] = {
+	DEFINE_RES_MEM(0xe6050000, 0x8000),
+	DEFINE_RES_MEM(0xe605800c, 0x0020),
 };
 
 void __init r8a7740_pinmux_init(void)
 {
-	platform_device_register(&r8a7740_pfc_device);
+	platform_device_register_simple("pfc-r8a7740", -1, pfc_resources,
+					ARRAY_SIZE(pfc_resources));
 }
 
 static struct renesas_intc_irqpin_config irqpin0_platform_data = {


From magnus.damm at gmail.com  Wed Apr  3 02:33:08 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Wed, 03 Apr 2013 15:33:08 +0900
Subject: [PATCH 02/04] ARM: shmobile: r8a7779 pinmux platform device cleanup
In-Reply-To: <20130403063246.2500.65318.sendpatchset@w520>
References: <20130403063246.2500.65318.sendpatchset@w520>
Message-ID: <20130403063308.2500.76867.sendpatchset@w520>

From: Magnus Damm <damm at opensource.se>

Use DEFINE_RES_MEM() to save a couple of lines of code.

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 arch/arm/mach-shmobile/setup-r8a7779.c |   19 ++++---------------
 1 file changed, 4 insertions(+), 15 deletions(-)

--- 0001/arch/arm/mach-shmobile/setup-r8a7779.c
+++ work/arch/arm/mach-shmobile/setup-r8a7779.c	2013-04-03 15:30:16.000000000 +0900
@@ -63,12 +63,8 @@ void __init r8a7779_map_io(void)
 	iotable_init(r8a7779_io_desc, ARRAY_SIZE(r8a7779_io_desc));
 }
 
-static struct resource r8a7779_pfc_resources[] = {
-	[0] = {
-		.start	= 0xfffc0000,
-		.end	= 0xfffc023b,
-		.flags	= IORESOURCE_MEM,
-	},
+static const struct resource r8a7779_pfc_resources[] = {
+	DEFINE_RES_MEM(0xfffc0000, 0x023c),
 };
 
 static struct platform_device r8a7779_pfc_device = {
@@ -80,15 +76,8 @@ static struct platform_device r8a7779_pf
 
 #define R8A7779_GPIO(idx, npins) \
 static struct resource r8a7779_gpio##idx##_resources[] = {		\
-	[0] = {								\
-		.start	= 0xffc40000 + 0x1000 * (idx),			\
-		.end	= 0xffc4002b + 0x1000 * (idx),			\
-		.flags	= IORESOURCE_MEM,				\
-	},								\
-	[1] = {								\
-		.start	= gic_iid(0xad + (idx)),			\
-		.flags	= IORESOURCE_IRQ,				\
-	}								\
+	DEFINE_RES_MEM(0xffc40000 + (0x1000 * (idx)), 0x002c),		\
+	DEFINE_RES_IRQ(gic_iid(0xad + (idx))),				\
 };									\
 									\
 static struct gpio_rcar_config r8a7779_gpio##idx##_platform_data = {	\


From magnus.damm at gmail.com  Wed Apr  3 02:33:18 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Wed, 03 Apr 2013 15:33:18 +0900
Subject: [PATCH 03/04] ARM: shmobile: sh7372 pinmux platform device cleanup
In-Reply-To: <20130403063246.2500.65318.sendpatchset@w520>
References: <20130403063246.2500.65318.sendpatchset@w520>
Message-ID: <20130403063318.2500.49100.sendpatchset@w520>

From: Magnus Damm <damm at opensource.se>

Use DEFINE_RES_MEM() and platform_device_register_simple()
to save a couple of lines of code.

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 arch/arm/mach-shmobile/setup-sh7372.c |   24 +++++-------------------
 1 file changed, 5 insertions(+), 19 deletions(-)

--- 0001/arch/arm/mach-shmobile/setup-sh7372.c
+++ work/arch/arm/mach-shmobile/setup-sh7372.c	2013-04-03 15:17:30.000000000 +0900
@@ -62,29 +62,15 @@ void __init sh7372_map_io(void)
 }
 
 /* PFC */
-static struct resource sh7372_pfc_resources[] = {
-	[0] = {
-		.start	= 0xe6050000,
-		.end	= 0xe6057fff,
-		.flags	= IORESOURCE_MEM,
-	},
-	[1] = {
-		.start	= 0xe605800c,
-		.end	= 0xe6058027,
-		.flags	= IORESOURCE_MEM,
-	}
-};
-
-static struct platform_device sh7372_pfc_device = {
-	.name		= "pfc-sh7372",
-	.id		= -1,
-	.resource	= sh7372_pfc_resources,
-	.num_resources	= ARRAY_SIZE(sh7372_pfc_resources),
+static const struct resource pfc_resources[] = {
+	DEFINE_RES_MEM(0xe6050000, 0x8000),
+	DEFINE_RES_MEM(0xe605800c, 0x001c),
 };
 
 void __init sh7372_pinmux_init(void)
 {
-	platform_device_register(&sh7372_pfc_device);
+	platform_device_register_simple("pfc-sh7372", -1, pfc_resources,
+					ARRAY_SIZE(pfc_resources));
 }
 
 /* SCIFA0 */


From magnus.damm at gmail.com  Wed Apr  3 02:33:28 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Wed, 03 Apr 2013 15:33:28 +0900
Subject: [PATCH 04/04] ARM: shmobile: sh73a0 pinmux platform device cleanup
In-Reply-To: <20130403063246.2500.65318.sendpatchset@w520>
References: <20130403063246.2500.65318.sendpatchset@w520>
Message-ID: <20130403063328.2500.86264.sendpatchset@w520>

From: Magnus Damm <damm at opensource.se>

Use DEFINE_RES_MEM() and platform_device_register_simple()
to save a couple of lines of code.

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 arch/arm/mach-shmobile/setup-sh73a0.c |   25 ++++++-------------------
 1 file changed, 6 insertions(+), 19 deletions(-)

--- 0001/arch/arm/mach-shmobile/setup-sh73a0.c
+++ work/arch/arm/mach-shmobile/setup-sh73a0.c	2013-04-03 15:19:37.000000000 +0900
@@ -61,29 +61,16 @@ void __init sh73a0_map_io(void)
 	iotable_init(sh73a0_io_desc, ARRAY_SIZE(sh73a0_io_desc));
 }
 
-static struct resource sh73a0_pfc_resources[] = {
-	[0] = {
-		.start	= 0xe6050000,
-		.end	= 0xe6057fff,
-		.flags	= IORESOURCE_MEM,
-	},
-	[1] = {
-		.start	= 0xe605801c,
-		.end	= 0xe6058027,
-		.flags	= IORESOURCE_MEM,
-	}
-};
-
-static struct platform_device sh73a0_pfc_device = {
-	.name		= "pfc-sh73a0",
-	.id		= -1,
-	.resource	= sh73a0_pfc_resources,
-	.num_resources	= ARRAY_SIZE(sh73a0_pfc_resources),
+/* PFC */
+static const struct resource pfc_resources[] = {
+	DEFINE_RES_MEM(0xe6050000, 0x8000),
+	DEFINE_RES_MEM(0xe605801c, 0x000c),
 };
 
 void __init sh73a0_pinmux_init(void)
 {
-	platform_device_register(&sh73a0_pfc_device);
+	platform_device_register_simple("pfc-sh73a0", -1, pfc_resources,
+					ARRAY_SIZE(pfc_resources));
 }
 
 static struct plat_sci_port scif0_platform_data = {


From swarren at wwwdotorg.org  Wed Apr  3 02:28:26 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Wed, 03 Apr 2013 00:28:26 -0600
Subject: [PATCH] bcm2835: Add Broadcom BCM2835 RNG to the device tree
In-Reply-To: <1364451124-5039-1-git-send-email-lkundrak@v3.sk>
References: <1364135511-26970-1-git-send-email-lkundrak@v3.sk>
 <1364451124-5039-1-git-send-email-lkundrak@v3.sk>
Message-ID: <515BCC0A.4020608@wwwdotorg.org>

On 03/28/2013 12:12 AM, Lubomir Rintel wrote:
> This adds a device tree binding for random number generator present on Broadcom
> BCM2835 SoC, used in Raspberry Pi and Roku 2 devices.

Applied to bcm2835's for-3.10/dt tree, with some slight fixups to the
patch subject and description word-wrapping.


From josephl at nvidia.com  Wed Apr  3 02:28:32 2013
From: josephl at nvidia.com (Joseph Lo)
Date: Wed, 3 Apr 2013 14:28:32 +0800
Subject: [PATCH V5 7/9] ARM: dts: tegra: add non-removable and
 keep-power-in-suspend property for MMC
In-Reply-To: <20130403054549.GA6764@avionic-0098.mockup.avionic-design.de>
References: <1364901613-25080-1-git-send-email-josephl@nvidia.com>
 <1364901613-25080-8-git-send-email-josephl@nvidia.com>
 <515B3871.50801@wwwdotorg.org>
 <20130403054549.GA6764@avionic-0098.mockup.avionic-design.de>
Message-ID: <1364970512.16957.15.camel@jlo-ubuntu-64.nvidia.com>

On Wed, 2013-04-03 at 13:45 +0800, Thierry Reding wrote:
> * PGP Signed by an unknown key
> 
> On Tue, Apr 02, 2013 at 01:58:41PM -0600, Stephen Warren wrote:
> > On 04/02/2013 05:20 AM, Joseph Lo wrote:
> > > This patch adds "non-removable" property of MMC host where the eMMC device
> > > is for Tegra platform.
> > > 
> > > And the "keep-power-in-suspend" property was used for the SDIO device that
> > > need this to go into suspend mode (e.g. BRCM43xx series).
> > 
> > >  arch/arm/boot/dts/tegra20-paz00.dts      | 1 +
> > >  arch/arm/boot/dts/tegra20-seaboard.dts   | 2 ++
> > >  arch/arm/boot/dts/tegra20-ventana.dts    | 2 ++
> > >  arch/arm/boot/dts/tegra20-whistler.dts   | 1 +
> > >  arch/arm/boot/dts/tegra30-beaver.dts     | 1 +
> > >  arch/arm/boot/dts/tegra30-cardhu-a02.dts | 1 +
> > >  arch/arm/boot/dts/tegra30-cardhu-a04.dts | 1 +
> > >  arch/arm/boot/dts/tegra30-cardhu.dtsi    | 1 +
> > 
> > I think there are a bunch of other boards that need a similar change,
> > right? There are certainly eMMC devices on other boards, and shouldn't
> > they be marked with non-removable? In particular, Beaver, Dalmore, and
> > Pluto, and likely some/all of the Colibri and Avionic Design boards. I
> > think it should be obvious which SDHCI devices need this, since there
> > won't be any cd-gpios property and the bus-width will likely be 8.
> 
> For Tegra20 Tamonten we don't use eMMC. Ideally we'd be using NAND to
> boot from but that doesn't have mainline support. I have a semi-working
> patch and will probably spend some more time getting it ready. The MMC
> cards are all removable, though I guess since they are the boot device
> they still should remain powered in suspend?
> 
The "non-removable" property is a specific property to avoid the risk of
writing back data to a different card after resume. If you just want to
test the suspend function, you can add "mmc_core.removable=0" in your
boot arg.

The "keep-power-in-suspend" is used for the BRCM43xx series SDIO device.
Without this, it can't go into suspend mode.




From olof at lixom.net  Wed Apr  3 02:30:59 2013
From: olof at lixom.net (Olof Johansson)
Date: Tue, 2 Apr 2013 23:30:59 -0700
Subject: [GIT PULL v2] Renesas ARM SoC board updates for v3.10 #3
In-Reply-To: <1364954906-16014-1-git-send-email-horms+renesas@verge.net.au>
References: <1364954906-16014-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <20130403063059.GB29601@quad.lixom.net>

Hi,

On Wed, Apr 03, 2013 at 11:08:15AM +0900, Simon Horman wrote:
> Hi Olof, Hi Arnd,
> 
> The following changes since commit eb0ae7280939fda741ad6ae9b108725517652f56:
> 
>   Merge tag 'renesas-pinmux2-for-v3.10' into boards-base (2013-04-03 10:49:18 +0900)
> 
> are available in the git repository at:
> 
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-boards3-for-v3.10

Pulled in in a next/boards2 since it depends on next/soc2.

>  arch/arm/configs/bockw_defconfig             |   66 +++++++++++++++

shmobile is now up to 11 defconfigs in arch/arm/configs. It'd be nice if
you could move towards what OMAP and many other platforms have started
doing for a while now, with one superset defconfig for the platform
(well, one for v4/v5 harware and one for v6+).


-Olof


From davem at davemloft.net  Wed Apr  3 02:31:57 2013
From: davem at davemloft.net (David Miller)
Date: Wed, 03 Apr 2013 02:31:57 -0400 (EDT)
Subject: [PATCH v4 0/6] Generic PHY Framework
In-Reply-To: <515BC559.1070602@ti.com>
References: <1364449408-9510-1-git-send-email-kishon@ti.com>
 <20130328.143142.2080627792603647441.davem@davemloft.net>
 <515BC559.1070602@ti.com>
Message-ID: <20130403.023157.1254170239558661397.davem@davemloft.net>

From: Kishon Vijay Abraham I <kishon at ti.com>
Date: Wed, 3 Apr 2013 11:29:53 +0530

> Hi,
> 
> On Friday 29 March 2013 12:01 AM, David Miller wrote:
>>
>> You really need to CC: netdev at vger.kernel.org rather than me
>> explicitly
>> on this patch set.
> 
> I was CC'ing whatever get_maintainer shows. I'll make sure to CC
> netdev at vger.kernel.org though there's nothing related to network in
> this patch series (Maybe sometime in the future it'll be used).

What about drivers/net/phy isn't networking?


From marex at denx.de  Wed Apr  3 02:34:09 2013
From: marex at denx.de (Marek Vasut)
Date: Wed, 3 Apr 2013 08:34:09 +0200
Subject: [PATCH] pinctrl: imx5: fix SD2_DATA1 pad AUDMUX_AUD4 configuration
In-Reply-To: <20130403052732.GP24039@S2101-09.ap.freescale.net>
References: <1364948425-15372-1-git-send-email-marex@denx.de>
 <20130403052732.GP24039@S2101-09.ap.freescale.net>
Message-ID: <201304030834.09344.marex@denx.de>

Dear Shawn Guo,

> On Wed, Apr 03, 2013 at 02:20:25AM +0200, Marek Vasut wrote:
> > The IOMUXC_AUDMUX_P4_INPUT_TXCLK_AMX_SELECT_INPUT must be configured as 1
> > instead of 0 to have AUD4 muxed on SD2 pins working.
> > 
> > Signed-off-by: Marek Vasut <marex at denx.de>
> 
> Changed the prefix to "ARM: dts: imx53: " and applied the patch.

I followed the pattern this time ... oh well, this again. Sorry.

Best regards,
Marek Vasut


From josephl at nvidia.com  Wed Apr  3 02:34:25 2013
From: josephl at nvidia.com (Joseph Lo)
Date: Wed, 3 Apr 2013 14:34:25 +0800
Subject: [PATCH V5 9/9] ARM: dts: tegra: add the PM configurations of PMC
In-Reply-To: <20130403055935.GB6764@avionic-0098.mockup.avionic-design.de>
References: <1364901613-25080-1-git-send-email-josephl@nvidia.com>
 <1364901613-25080-10-git-send-email-josephl@nvidia.com>
 <515B38F7.5050606@wwwdotorg.org>
 <20130403055935.GB6764@avionic-0098.mockup.avionic-design.de>
Message-ID: <1364970865.16957.21.camel@jlo-ubuntu-64.nvidia.com>

On Wed, 2013-04-03 at 13:59 +0800, Thierry Reding wrote:
> * PGP Signed by an unknown key
> 
> On Tue, Apr 02, 2013 at 02:00:55PM -0600, Stephen Warren wrote:
> > On 04/02/2013 05:20 AM, Joseph Lo wrote:
> > > Adding the PM configuration of PMC when the platform support suspend
> > > function.
> > 
> > For this patch, some more boards could be supported, but I think we'll
> > have to rely on other people (Lucas, Thierry) to send patches for them,
> > since they know the details of the board. It's fine to leave suspend
> > disabled on those boards until later.
> 
> I'm not sure what would be the best way to get the Tamonten devices out
> of suspend again. For Plutux and TEC we have a power button that could
> possibly be reused. There's a WAKEUP pin on the Tamonten connector which
> goes to GPIO PV2, but the mechanism to trigger it is carrier-board
> dependent.
> 
> For the Medcom-Wide we don't have a power button, but it could possibly
> use the WAKEUP pin if that's connected. It seems like in all designs it
> goes to the CPLD, but I need to check with engineering if there's a way
> to manipulate it.
> 
> So yes, I think for now we can leave suspend disabled on Tamonten and I
> can send patches to enable it once I've clarified with engineering.
> 
Hi Thierry,

I just recall I still need at least "nvidia,cpu-pwr-good-time" and
"nvidia,cpu-pwr-off-time" two properties to make CPU idle power-down
mode (same with LP2) work normally after this series.

So can you provide me that or point me out where is your downstream
kernel source? There data would be come from DT after this series.

Thanks,
Joseph




From s.hauer at pengutronix.de  Wed Apr  3 02:35:37 2013
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Wed, 3 Apr 2013 08:35:37 +0200
Subject: [GIT PULL] imx fixes for 3.9, take 5
In-Reply-To: <20130403031511.GB27874@quad.lixom.net>
References: <20130402134627.GF24039@S2101-09.ap.freescale.net>
 <20130403031511.GB27874@quad.lixom.net>
Message-ID: <20130403063537.GP1906@pengutronix.de>

On Tue, Apr 02, 2013 at 08:15:11PM -0700, Olof Johansson wrote:
> On Tue, Apr 02, 2013 at 09:46:29PM +0800, Shawn Guo wrote:
> > The following changes since commit 07961ac7c0ee8b546658717034fe692fd12eefa9:
> > 
> >   Linux 3.9-rc5 (2013-03-31 15:12:43 -0700)
> > 
> > are available in the git repository at:
> > 
> >   git://git.linaro.org/people/shawnguo/linux-2.6.git tags/imx-fixes-3.9-5
> > 
> > for you to fetch changes up to 710b213d3f1cdb0451fa2d5a71faa2b1f510e3ad:
> > 
> >   ARM: imx35 Bugfix admux clock (2013-04-02 21:05:40 +0800)
> > 
> > ----------------------------------------------------------------
> > The imx fixes for 3.9, take 5:
> >  - One fix for the typo in use of Kconfig symbol
> >    MACH_EUKREA_CPUIMX27_USEUART4.  It's been there for a long time
> >    and got caught by code inspection recently.  It hasn't been noticed
> >    earlier probably because it does not cause any problem in real.
> 
> 2.6.35 to be exact.
> 
> It's more a sign that the board can be removed than that it should be fixed
> immediately for 3.9, wouldn't you say? Clearly no one seems to care about
> mainline functionality on that platform -- especially since it was now found
> through inspection and not usage.
> 
> >  - A couple of fixes on imx35 clock driver to have audmux functional
> >    and iomux pad configurable after a reboot.
> 
> These look like valid fixes but I can't from the commit messages tell
> when the problem was introduced, and what the actual breakage that the
> user sees it. It almost looks like it's adding a few clocks that were
> never used before, not a regression? I'm happy to be proven wrong though.

Maybe the commit log could be better, but they are real bug fixes.

ARM: imx35 Bugfix admux clock

This patch registers a new lookup so that the audmux driver finds the
clock and enables it (the clock is optional in the driver). Otherwise
the clock framework will find the clock unused and disables it during
late init time.

ARM: clk-imx35: Bugfix iomux clock

This patch enables a clock needed for the iomuxer, otherwise it gets
disabled during late init time and the iomux stops working. This usually
is not noticed because normally the iomux is configured before that
point.
The really correct solution is to add clock support to the iomux driver
instead of enabling it in the SoC clock driver. This requires changes for
all SoCs using this driver though which still should be done later.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From kishon at ti.com  Wed Apr  3 02:35:30 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Wed, 3 Apr 2013 12:05:30 +0530
Subject: [PATCH v4 0/6] Generic PHY Framework
In-Reply-To: <20130403.023157.1254170239558661397.davem@davemloft.net>
References: <1364449408-9510-1-git-send-email-kishon@ti.com>
 <20130328.143142.2080627792603647441.davem@davemloft.net>
 <515BC559.1070602@ti.com>
 <20130403.023157.1254170239558661397.davem@davemloft.net>
Message-ID: <515BCDB2.2040506@ti.com>

Hi,

On Wednesday 03 April 2013 12:01 PM, David Miller wrote:
> From: Kishon Vijay Abraham I <kishon at ti.com>
> Date: Wed, 3 Apr 2013 11:29:53 +0530
>
>> Hi,
>>
>> On Friday 29 March 2013 12:01 AM, David Miller wrote:
>>>
>>> You really need to CC: netdev at vger.kernel.org rather than me
>>> explicitly
>>> on this patch set.
>>
>> I was CC'ing whatever get_maintainer shows. I'll make sure to CC
>> netdev at vger.kernel.org though there's nothing related to network in
>> this patch series (Maybe sometime in the future it'll be used).
>
> What about drivers/net/phy isn't networking?

This patch series is about drivers/phy which will be used for now by 
usb, sata and maybe some video PHY's. Network itself has a comprehensive 
PHY in drivers/net/phy which we'd like to merge it with drivers/phy so 
that we have all the phy stuff in drivers/phy but we are not planning 
too far ahead here.

Thanks
Kishon


From monstr at monstr.eu  Wed Apr  3 02:44:34 2013
From: monstr at monstr.eu (Michal Simek)
Date: Wed, 3 Apr 2013 08:44:34 +0200
Subject: [PATCH 08/10] arm: zynq: Add smp support
In-Reply-To: <515A0CE0.7050401@gmail.com>
References: <1364219596-4954-1-git-send-email-michal.simek@xilinx.com>
 <1364219596-4954-8-git-send-email-michal.simek@xilinx.com>
 <51505C39.4060507@gmail.com> <51507BCC.2050707@monstr.eu>
 <5150CB64.5030502@gmail.com>
 <CAHTX3dLD6gPG-1nzbk9gcsiO=SAq7UKDa7vvOOYHvTHt8zJhUg@mail.gmail.com>
 <515A0CE0.7050401@gmail.com>
Message-ID: <CAHTX3d+dMjATSkkMUf-QdmQ0i+HYKgegeA0gbB9dYxK0Q0_HAg@mail.gmail.com>

2013/4/2 Rob Herring <robherring2 at gmail.com>:
> On 03/26/2013 02:42 AM, Michal Simek wrote:
>> 2013/3/25 Rob Herring <robherring2 at gmail.com>:
>>> On 03/25/2013 11:31 AM, Michal Simek wrote:
>>>> On 03/25/2013 03:16 PM, Rob Herring wrote:
>>>>> On 03/25/2013 08:53 AM, Michal Simek wrote:
>>>>>> Zynq is dual core Cortex A9 which starts always
>>>>>> at zero. Using simple trampoline ensure long jump
>>>>>> to secondary_startup code.
>
> [...]
>
>>>>>> +        slcr_cpu_stop(cpu);
>>>>>
>>>>> Isn't a secondary cpu already stopped?
>>>>
>>>> On the normal boot this is really necessary because first stage bootloader
>>>> doesn't stop cpu just keep it in loop and without stopping cpu
>>>> and starting it again it doesn't work.
>>>
>>> And there is no way to exit the loop other than a reset?
>>
>> You can exit the loop by writing jump address to one location where bootloader
>> expect it. Then it jumps to proper function and it was done like that before.
>> But this is not suitable for cpu hotplug because that loop is placed
>> in OCM (on chip memory)
>> and it can be used for different purpose.
>> Also there is no way how to return cpu to this mode.
>
> I was asking about the cold boot case, not hotplug. If you are spinning
> in the bootloader waiting for a jump address, then why do you need the
> slcr_cpu_stop for cold boot? In the hotplug case, you have already
> called slcr_cpu_stop in the unplug path, so this shouldn't be needed
> there either.

For cold boot case there is an option to write jump addr
to specific address which fsbl (xilinx proprietary bootloader) expects
or just do cpu reset.
Waiting loop is placed in OCM. Then u-boot runs and user can change OCM mapping
for whatever reason.

My point is that reset is cleaner way because I am exactly sure
that cpu will be in the correct state and previous bootloader/code just
hasn't done any weird setting/changes.
It means that my requirement is that any bootloader will just ensure
that cpu1 is
in any waiting loop/sleep/whatever and I will do proper reset when I
need to start it.

I understand your concern about moving slcr_cpu_stop to different location
or even just stop cpu in bootloader but that's even more problematic.

>>>>>> +            __raw_writel(address, phys_to_virt(0x8));
>>>
>>> This should be a per core address including core 0 if you ever want to
>>> do something like cpuidle powergating on one core and hotplug on another.
>>
>> That's interesting idea.
>> Please correct me if I am wrong, I didn't play with cpuidle.
>>
>> Zynq is dual core and hotplug can be done only on cpu1. (not sure if
>> in general cpu0
>> can be unplugged too. If yes, are you doing that?).
>
> You cannot do hotplug on cpu 0, but that is a current Linux limitation.
> I believe support to hotplug cpu 0 was recently added for x86. So this
> may change at some point.
>
> What the h/w can support is another issue. Some chips have independent
> power domains per core and some have combined domains. I can and do
> powergate individual cores including core 0 in cpuidle for highbank. The
> main difference to hotplug is whether I set the wake-up address when I
> go down (cpuidle) or when I wake the core (hotplug). For hotplug, you
> don't want the core to come back before the kernel is ready for it.

ok

>> I didn't play with cpuidle code but I am not quite sure if you can use hotplug
>> if cpu0 is in idle because this code is for >cpu0.
>>
>> I can imagine to be more flexible on quad core where your comment make
>> definitely sense.
>
> The next part could be quad core...

I will look at changing this boot up code for future.

Thanks,
Michal



-- 
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform


From olof at lixom.net  Wed Apr  3 02:46:53 2013
From: olof at lixom.net (Olof Johansson)
Date: Tue, 2 Apr 2013 23:46:53 -0700
Subject: [PATCH] video: implement a dumb framebuffer driver
In-Reply-To: <1364969830-6481-1-git-send-email-swarren@wwwdotorg.org>
References: <1364969830-6481-1-git-send-email-swarren@wwwdotorg.org>
Message-ID: <20130403064653.GA6263@quad.lixom.net>

On Wed, Apr 03, 2013 at 12:17:10AM -0600, Stephen Warren wrote:
> A dumb frame-buffer describes a raw memory region that may be rendered
> to, with the assumption that the display hardware has already been set
> up to scan out from that buffer.
> 
> This is useful in cases where a bootloader exists and has set up the
> display hardware, but a Linux driver doesn't yet exist for the display
> hardware.
> 
> Signed-off-by: Stephen Warren <swarren at wwwdotorg.org>
> ---
> Should this be merged through akpm's tree (I think many fb drivers are
> these days), or if not, I could take it through the bcm2835 tree.

Yes, through akpm is the way to go (with ack from Rob/Grant for bindings).

> I ended up going with a separate FB driver:
> * DRM/KMS look much more complex, and don't provide any benefit that I can
>   tell for this simple driver.
> * Creating a separate driver rather than adjusting offb.c to work allows a
>   new clean binding to be defined, and doesn't require removing or ifdefing
>   PPC-isms in offb.c.

Sounds reasonable.

I've got some opinions on the color of this shed below. I don't have strong
opinions on the matter though.

> 
>  .../devicetree/bindings/video/dumb-framebuffer.txt |   25 +++
>  drivers/video/Kconfig                              |   17 ++
>  drivers/video/Makefile                             |    1 +
>  drivers/video/dumbfb.c                             |  234 ++++++++++++++++++++
>  4 files changed, 277 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/video/dumb-framebuffer.txt
>  create mode 100644 drivers/video/dumbfb.c
> 
> diff --git a/Documentation/devicetree/bindings/video/dumb-framebuffer.txt b/Documentation/devicetree/bindings/video/dumb-framebuffer.txt
> new file mode 100644
> index 0000000..ba6676b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/dumb-framebuffer.txt
> @@ -0,0 +1,25 @@
> +Dumb Framebuffer
> +
> +A dumb frame-buffer describes a raw memory region that may be rendered to,
> +with the assumption that the display hardware has already been set up to scan
> +out from that buffer.

I think we have preferred "simple" over "dumb" in the past in other context.

> +
> +Required properties:
> +- compatible: "dumb-framebuffer"
> +- reg: Should contain the location and size of the framebuffer memory.
> +- width: The width of the framebuffer in pixels.
> +- height: The height of the framebuffer in pixels.
> +- stride: The number of bytes in each line of the framebuffer.
> +- format: The format of the framebuffer surface. Valid values are:
> +  r5g6b5: A 16bpp format.

Hm, I'm used to this being written as "rgb565", which is also the format
string that the fsl-imx-drm binding seems to use.

I guess actual depth can easily be derived from format.

> +Example:
> +
> +	framebuffer {
> +		compatible = "dumb-framebuffer";
> +		reg = <0x1d385000 (1600 * 1200 * 2)>;
> +		width = <1600>;
> +		height = <1200>;
> +		stride = <(1600 * 2)>;
> +		format = "r5g6b5";
> +	};


-Olof


From marex at denx.de  Wed Apr  3 02:50:31 2013
From: marex at denx.de (Marek Vasut)
Date: Wed, 3 Apr 2013 08:50:31 +0200
Subject: [PATCH V2 08/12] spi/mxs: Fix race in setup method
In-Reply-To: <CA+7tXih2r6YFE80y7z7Nj7c0Ytvh+v56-SrbS+VQ7kCW3KBRXA@mail.gmail.com>
References: <1364905195-24286-1-git-send-email-tpiepho@gmail.com>
 <201304030427.41297.marex@denx.de>
 <CA+7tXih2r6YFE80y7z7Nj7c0Ytvh+v56-SrbS+VQ7kCW3KBRXA@mail.gmail.com>
Message-ID: <201304030850.31752.marex@denx.de>

Dear Trent Piepho,

> On Apr 2, 2013 7:27 PM, "Marek Vasut" <marex at denx.de> wrote:
> > > The only useful thing mxs_spi_setup_transfer() (which
> > > is no longer called) did in this instance was make that check.
> > > 
> > > > btw. I was under the impression the MXS SSP block can handle other
> > > > word-widths than 8 bit, no ?
> > > 
> > > In theory it can,
> > 
> > In practice too ;-)
> > 
> > > however the driver only supports 8-bits and will
> > > reject anything else.
> > 
> > Then please at least add a comment about this.
> 
> What does that have to do with this patch?

You're adding a piece of code. This change is
a) not documented in the commit message
b) unrelated to this fix, seems to be more fitting in 10/12 or something -- 
maybe even shuffling the patches a bit might help

So add a comment to make this clearer for people who hack on this after you.

> There was no comment about
> it before.  You're insisting that changes be broken up to the extent
> that changing one line of code takes multiple patches!  Now you want a
> comment about existing driver behavior added to patch that doesn't
> change that behavior?
> 
> Documenting the driver behavior would seem to be a job for the driver
> maintainer.  If doing this is something I need to do, then maybe I
> should maintain it?

You ain't rubbing people the right way at all, I tell you. This pushy/offensive 
behavior helps noone, calm down please. It is usually a good idea to sleep on 
your reply or take your time.

Ad maintainership -- there's no maintainer of the driver, there's only Fabio, 
Shawn, me and the SPI subsystem guys. And it works well. It's everybodys' code 
and everyone's welcome to contribute. What's the problem? 

Best regards,
Marek Vasut


From marex at denx.de  Wed Apr  3 02:52:51 2013
From: marex at denx.de (Marek Vasut)
Date: Wed, 3 Apr 2013 08:52:51 +0200
Subject: [PATCH] pinctrl: imx5: fix SD2_DATA1 pad AUDMUX_AUD4 configuration
In-Reply-To: <20130403052423.GO24039@S2101-09.ap.freescale.net>
References: <1364882642-25574-1-git-send-email-marex@denx.de>
 <201304030221.18506.marex@denx.de>
 <20130403052423.GO24039@S2101-09.ap.freescale.net>
Message-ID: <201304030852.52125.marex@denx.de>

Dear Shawn Guo,

> On Wed, Apr 03, 2013 at 02:21:18AM +0200, Marek Vasut wrote:
> > One serving of such patch, coming right up ;-)
> > 
> > btw. do you want to apply this one for -stable or do we just leave it as
> > is ?
> 
> If you do not insist, I would say let's leave it as it is, as we
> encourage people to upgrade device tree to adopt the new pinctrl
> binding.

Actually, I have a bad feeling about having an open bug in stable tree. Someone 
might use that tree and might try to use AUDMUX4 on his (out-of-tree) device and 
might run into the same problem. Three times 'might' in one sentence doesn't 
make it sound too likely, but if you have not much trouble with getting it in -
stable, please try to.

Best regards,
Marek Vasut


From shc_work at mail.ru  Wed Apr  3 02:57:42 2013
From: shc_work at mail.ru (=?UTF-8?B?QWxleGFuZGVyIFNoaXlhbg==?=)
Date: Wed, 03 Apr 2013 10:57:42 +0400
Subject: =?UTF-8?B?UmU6IFtQQVRDSF0gQVJNOiBhdXRjcHUxMjogRml4IGNvbmZpZyBjaGVjayBp?=
 =?UTF-8?B?biBhdXRjcHUxMl9pbml0X2xhdGUoKQ==?=
In-Reply-To: <20130402171217.GE25867@quad.lixom.net>
References: <1363988123.3728.45.camel@deadeye.wl.decadent.org.uk>
 <1364016140.352883792@f399.i.mail.ru>
 <20130402171217.GE25867@quad.lixom.net>
Message-ID: <1364972262.31344533@f56.mail.ru>

Hello.

> On Sat, Mar 23, 2013 at 09:22:20AM +0400, Alexander Shiyan wrote:
> > > The 'CONFIG_' prefix is not implicit in IS_ENABLED().
> > > 
> > > Signed-off-by: Ben Hutchings <ben at decadent.org.uk>
> > > Cc: Alexander Shiyan <shc_work at mail.ru>
> > > Cc: Olof Johansson <olof at lixom.net>
> > > Cc: Paul Bolle <pebolle at tiscali.nl>
> > > Cc: <stable at vger.kernel.org> # 3.8+
> > > ---
> > > Found by inspection.  This is not even compile-tested.
> > > 
> > > Ben.
> > > 
> > >  arch/arm/mach-clps711x/board-autcpu12.c |    3 ++-
> > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/arch/arm/mach-clps711x/board-autcpu12.c b/arch/arm/mach-clps711x/board-autcpu12.c
> > > index f385847..8138523 100644
> > > --- a/arch/arm/mach-clps711x/board-autcpu12.c
> > > +++ b/arch/arm/mach-clps711x/board-autcpu12.c
> > > @@ -158,7 +158,8 @@ static void __init autcpu12_init(void)
> > >  
> > >  static void __init autcpu12_init_late(void)
> > >  {
> > > -	if (IS_ENABLED(MTD_NAND_GPIO) && IS_ENABLED(GPIO_GENERIC_PLATFORM)) {
> > > +	if (IS_ENABLED(CONFIG_MTD_NAND_GPIO) &&
> > > +	    IS_ENABLED(CONFIG_GPIO_GENERIC_PLATFORM)) {
> > >  		/* We are need both drivers to handle NAND */
> > >  		platform_device_register(&autcpu12_nand_pdev);
> > >  	}
> > 
> > Oops. Right.
> > And I think checks can be removed completely.
> 
> Seems reasonable -- there's no reason to hold off registering the device just
> because the driver isn't enabled.
> 
> Who'll repost a patch to just remove the tests? Ben? Alexander?

Please apply the patch just yet. I will keep in mind this change.
Thanks.

---

From josephl at nvidia.com  Wed Apr  3 02:59:04 2013
From: josephl at nvidia.com (Joseph Lo)
Date: Wed, 3 Apr 2013 14:59:04 +0800
Subject: [PATCH V5 7/9] ARM: dts: tegra: add non-removable and
 keep-power-in-suspend property for MMC
In-Reply-To: <515B3871.50801@wwwdotorg.org>
References: <1364901613-25080-1-git-send-email-josephl@nvidia.com>
 <1364901613-25080-8-git-send-email-josephl@nvidia.com>
 <515B3871.50801@wwwdotorg.org>
Message-ID: <1364972344.16957.26.camel@jlo-ubuntu-64.nvidia.com>

On Wed, 2013-04-03 at 03:58 +0800, Stephen Warren wrote:
> On 04/02/2013 05:20 AM, Joseph Lo wrote:
> > This patch adds "non-removable" property of MMC host where the eMMC device
> > is for Tegra platform.
> > 
> > And the "keep-power-in-suspend" property was used for the SDIO device that
> > need this to go into suspend mode (e.g. BRCM43xx series).
> 
> >  arch/arm/boot/dts/tegra20-paz00.dts      | 1 +
> >  arch/arm/boot/dts/tegra20-seaboard.dts   | 2 ++
> >  arch/arm/boot/dts/tegra20-ventana.dts    | 2 ++
> >  arch/arm/boot/dts/tegra20-whistler.dts   | 1 +
> >  arch/arm/boot/dts/tegra30-beaver.dts     | 1 +
> >  arch/arm/boot/dts/tegra30-cardhu-a02.dts | 1 +
> >  arch/arm/boot/dts/tegra30-cardhu-a04.dts | 1 +
> >  arch/arm/boot/dts/tegra30-cardhu.dtsi    | 1 +
> 
> I think there are a bunch of other boards that need a similar change,
> right? There are certainly eMMC devices on other boards, and shouldn't
> they be marked with non-removable? In particular, Beaver, Dalmore, and
> Pluto, and likely some/all of the Colibri and Avionic Design boards. I
> think it should be obvious which SDHCI devices need this, since there
> won't be any cd-gpios property and the bus-width will likely be 8.

OK, I already added the property for Beaver. I will add one more support
for Dalmore in this patch. For Pluto, it didn't add any SDCHI node in DT
yet. We need another patch to enable SDHCI on Pluto first and add the
properties there.

Thanks,
Joseph



From thierry.reding at avionic-design.de  Wed Apr  3 03:04:23 2013
From: thierry.reding at avionic-design.de (Thierry Reding)
Date: Wed, 3 Apr 2013 09:04:23 +0200
Subject: [PATCH V5 9/9] ARM: dts: tegra: add the PM configurations of PMC
In-Reply-To: <1364970865.16957.21.camel@jlo-ubuntu-64.nvidia.com>
References: <1364901613-25080-1-git-send-email-josephl@nvidia.com>
 <1364901613-25080-10-git-send-email-josephl@nvidia.com>
 <515B38F7.5050606@wwwdotorg.org>
 <20130403055935.GB6764@avionic-0098.mockup.avionic-design.de>
 <1364970865.16957.21.camel@jlo-ubuntu-64.nvidia.com>
Message-ID: <20130403070423.GB22867@avionic-0098.mockup.avionic-design.de>

On Wed, Apr 03, 2013 at 02:34:25PM +0800, Joseph Lo wrote:
> On Wed, 2013-04-03 at 13:59 +0800, Thierry Reding wrote:
> > * PGP Signed by an unknown key
> > 
> > On Tue, Apr 02, 2013 at 02:00:55PM -0600, Stephen Warren wrote:
> > > On 04/02/2013 05:20 AM, Joseph Lo wrote:
> > > > Adding the PM configuration of PMC when the platform support suspend
> > > > function.
> > > 
> > > For this patch, some more boards could be supported, but I think we'll
> > > have to rely on other people (Lucas, Thierry) to send patches for them,
> > > since they know the details of the board. It's fine to leave suspend
> > > disabled on those boards until later.
> > 
> > I'm not sure what would be the best way to get the Tamonten devices out
> > of suspend again. For Plutux and TEC we have a power button that could
> > possibly be reused. There's a WAKEUP pin on the Tamonten connector which
> > goes to GPIO PV2, but the mechanism to trigger it is carrier-board
> > dependent.
> > 
> > For the Medcom-Wide we don't have a power button, but it could possibly
> > use the WAKEUP pin if that's connected. It seems like in all designs it
> > goes to the CPLD, but I need to check with engineering if there's a way
> > to manipulate it.
> > 
> > So yes, I think for now we can leave suspend disabled on Tamonten and I
> > can send patches to enable it once I've clarified with engineering.
> > 
> Hi Thierry,
> 
> I just recall I still need at least "nvidia,cpu-pwr-good-time" and
> "nvidia,cpu-pwr-off-time" two properties to make CPU idle power-down
> mode (same with LP2) work normally after this series.
> 
> So can you provide me that or point me out where is your downstream
> kernel source? There data would be come from DT after this series.

We don't have suspend support in downstream kernels either. However
since the Tamonten was derived from the Harmony reference design I
suppose the same values can be reused.

That said, the binding document says that those values are only required
if nvidia,suspend-mode is set. So if we don't add it for the Tamonten
boards why would you need the cpu-pwr-good-time and cpu-pwr-off-time
values. Or maybe the binding document is wrong?

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130403/bc859369/attachment-0001.sig>

From josephl at nvidia.com  Wed Apr  3 03:11:17 2013
From: josephl at nvidia.com (Joseph Lo)
Date: Wed, 3 Apr 2013 15:11:17 +0800
Subject: [PATCH V5 9/9] ARM: dts: tegra: add the PM configurations of PMC
In-Reply-To: <20130403070423.GB22867@avionic-0098.mockup.avionic-design.de>
References: <1364901613-25080-1-git-send-email-josephl@nvidia.com>
 <1364901613-25080-10-git-send-email-josephl@nvidia.com>
 <515B38F7.5050606@wwwdotorg.org>
 <20130403055935.GB6764@avionic-0098.mockup.avionic-design.de>
 <1364970865.16957.21.camel@jlo-ubuntu-64.nvidia.com>
 <20130403070423.GB22867@avionic-0098.mockup.avionic-design.de>
Message-ID: <1364973077.16957.32.camel@jlo-ubuntu-64.nvidia.com>

On Wed, 2013-04-03 at 15:04 +0800, Thierry Reding wrote:
> * PGP Signed by an unknown key
> 
> On Wed, Apr 03, 2013 at 02:34:25PM +0800, Joseph Lo wrote:
> > On Wed, 2013-04-03 at 13:59 +0800, Thierry Reding wrote:
> > > > Old Signed by an unknown key
> > > 
> > > On Tue, Apr 02, 2013 at 02:00:55PM -0600, Stephen Warren wrote:
> > > > On 04/02/2013 05:20 AM, Joseph Lo wrote:
> > > > > Adding the PM configuration of PMC when the platform support suspend
> > > > > function.
> > > > 
> > > > For this patch, some more boards could be supported, but I think we'll
> > > > have to rely on other people (Lucas, Thierry) to send patches for them,
> > > > since they know the details of the board. It's fine to leave suspend
> > > > disabled on those boards until later.
> > > 
> > > I'm not sure what would be the best way to get the Tamonten devices out
> > > of suspend again. For Plutux and TEC we have a power button that could
> > > possibly be reused. There's a WAKEUP pin on the Tamonten connector which
> > > goes to GPIO PV2, but the mechanism to trigger it is carrier-board
> > > dependent.
> > > 
> > > For the Medcom-Wide we don't have a power button, but it could possibly
> > > use the WAKEUP pin if that's connected. It seems like in all designs it
> > > goes to the CPLD, but I need to check with engineering if there's a way
> > > to manipulate it.
> > > 
> > > So yes, I think for now we can leave suspend disabled on Tamonten and I
> > > can send patches to enable it once I've clarified with engineering.
> > > 
> > Hi Thierry,
> > 
> > I just recall I still need at least "nvidia,cpu-pwr-good-time" and
> > "nvidia,cpu-pwr-off-time" two properties to make CPU idle power-down
> > mode (same with LP2) work normally after this series.
> > 
> > So can you provide me that or point me out where is your downstream
> > kernel source? There data would be come from DT after this series.
> 
> We don't have suspend support in downstream kernels either. However
> since the Tamonten was derived from the Harmony reference design I
> suppose the same values can be reused.
> 
OK. That's enough.

> That said, the binding document says that those values are only required
> if nvidia,suspend-mode is set. So if we don't add it for the Tamonten
> boards why would you need the cpu-pwr-good-time and cpu-pwr-off-time
> values. Or maybe the binding document is wrong?

Actually, when you support CPU idle power-down mode (LP2), you already
support suspend function (at least LP2 mode). Just no wake up source
define in DT for your boards.

May I add these properties to your boards (same as Harmony)? Then you
can figure out your wake up source later, at least the RTC can wake up
your device I believe.

Thanks,
Joseph




From thierry.reding at avionic-design.de  Wed Apr  3 03:19:32 2013
From: thierry.reding at avionic-design.de (Thierry Reding)
Date: Wed, 3 Apr 2013 09:19:32 +0200
Subject: [PATCH V5 9/9] ARM: dts: tegra: add the PM configurations of PMC
In-Reply-To: <1364973077.16957.32.camel@jlo-ubuntu-64.nvidia.com>
References: <1364901613-25080-1-git-send-email-josephl@nvidia.com>
 <1364901613-25080-10-git-send-email-josephl@nvidia.com>
 <515B38F7.5050606@wwwdotorg.org>
 <20130403055935.GB6764@avionic-0098.mockup.avionic-design.de>
 <1364970865.16957.21.camel@jlo-ubuntu-64.nvidia.com>
 <20130403070423.GB22867@avionic-0098.mockup.avionic-design.de>
 <1364973077.16957.32.camel@jlo-ubuntu-64.nvidia.com>
Message-ID: <20130403071932.GA23157@avionic-0098.mockup.avionic-design.de>

On Wed, Apr 03, 2013 at 03:11:17PM +0800, Joseph Lo wrote:
> On Wed, 2013-04-03 at 15:04 +0800, Thierry Reding wrote:
> > * PGP Signed by an unknown key
> > 
> > On Wed, Apr 03, 2013 at 02:34:25PM +0800, Joseph Lo wrote:
> > > On Wed, 2013-04-03 at 13:59 +0800, Thierry Reding wrote:
> > > > > Old Signed by an unknown key
> > > > 
> > > > On Tue, Apr 02, 2013 at 02:00:55PM -0600, Stephen Warren wrote:
> > > > > On 04/02/2013 05:20 AM, Joseph Lo wrote:
> > > > > > Adding the PM configuration of PMC when the platform support suspend
> > > > > > function.
> > > > > 
> > > > > For this patch, some more boards could be supported, but I think we'll
> > > > > have to rely on other people (Lucas, Thierry) to send patches for them,
> > > > > since they know the details of the board. It's fine to leave suspend
> > > > > disabled on those boards until later.
> > > > 
> > > > I'm not sure what would be the best way to get the Tamonten devices out
> > > > of suspend again. For Plutux and TEC we have a power button that could
> > > > possibly be reused. There's a WAKEUP pin on the Tamonten connector which
> > > > goes to GPIO PV2, but the mechanism to trigger it is carrier-board
> > > > dependent.
> > > > 
> > > > For the Medcom-Wide we don't have a power button, but it could possibly
> > > > use the WAKEUP pin if that's connected. It seems like in all designs it
> > > > goes to the CPLD, but I need to check with engineering if there's a way
> > > > to manipulate it.
> > > > 
> > > > So yes, I think for now we can leave suspend disabled on Tamonten and I
> > > > can send patches to enable it once I've clarified with engineering.
> > > > 
> > > Hi Thierry,
> > > 
> > > I just recall I still need at least "nvidia,cpu-pwr-good-time" and
> > > "nvidia,cpu-pwr-off-time" two properties to make CPU idle power-down
> > > mode (same with LP2) work normally after this series.
> > > 
> > > So can you provide me that or point me out where is your downstream
> > > kernel source? There data would be come from DT after this series.
> > 
> > We don't have suspend support in downstream kernels either. However
> > since the Tamonten was derived from the Harmony reference design I
> > suppose the same values can be reused.
> > 
> OK. That's enough.
> 
> > That said, the binding document says that those values are only required
> > if nvidia,suspend-mode is set. So if we don't add it for the Tamonten
> > boards why would you need the cpu-pwr-good-time and cpu-pwr-off-time
> > values. Or maybe the binding document is wrong?
> 
> Actually, when you support CPU idle power-down mode (LP2), you already
> support suspend function (at least LP2 mode). Just no wake up source
> define in DT for your boards.

Okay, but for CPU idle LP2 we don't need a wakeup source, right? I only
need the wakeup source if I explicitly suspend the device.

> May I add these properties to your boards (same as Harmony)? Then you
> can figure out your wake up source later, at least the RTC can wake up
> your device I believe.

From what I understand there should be no changes in behaviour after
this patch, so it should be fine.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130403/e1baa29f/attachment.sig>

From nicolas.ferre at atmel.com  Wed Apr  3 03:22:48 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Wed, 3 Apr 2013 09:22:48 +0200
Subject: [GIT PULL] at91: soc for 3.10 #2
In-Reply-To: <CAOesGMiy7q-xbc0SN78d7cvZmLgywy1PH7_Srw_=pzErSkrt-g@mail.gmail.com>
References: <5152B357.3020500@atmel.com> <201303271902.00068.arnd@arndb.de>
 <CAOesGMiy7q-xbc0SN78d7cvZmLgywy1PH7_Srw_=pzErSkrt-g@mail.gmail.com>
Message-ID: <515BD8C8.5060701@atmel.com>

On 04/03/2013 02:26 AM, Olof Johansson :
> On Wed, Mar 27, 2013 at 12:01 PM, Arnd Bergmann <arnd at arndb.de> wrote:
>> On Wednesday 27 March 2013, Nicolas Ferre wrote:
>>
>>> ----------------------------------------------------------------
>>> Introduction of new Atmel Cortex-A5: SAMA5D3 family.
>>> - Modify AT91 Kconfig to plit ARMv4/5 and ARMv7 arch
>>> - Modify PMC driver (clocks)
>>> - Core SAMA5 support
>>> - Board file, DT files and defconfig
>>
>> Looks really good. Olof said he'd take over merging tomorrow,
>> so I'll leave it for him.
>>
>>> ----------------------------------------------------------------
>>> Ludovic Desroches (6):
>>>       ARM: at91: change name template in AT91_SOC_START macro
>>>       ARM: at91: add AT91_SAM9_TIME entry to select at91sam926x_time.c compilation
>>>       ARM: at91: introduce the core type choice to split ARMv4/5 and ARMv7 arch
>>>       ARM: at91: introduce SAMA5 support
>>>       ARM: at91: dt: add device tree files for SAMA5D3 family
>>>       ARM: at91: add defconfig for SAMA5
>>
>> There is one obvious change that would be nice to include here,
>> can you add this on top (either Nicolas or Olof)?
>>
>> 8<---------
>> Subject: ARM: at91: make ATAGS support conditional on CONFIG_ATAGS
>>
>> We have the global CONFIG_ATAGS symbol that is used to determine
>> whether ATAGS based boot is possible or not. Since we are
>> splitting out the legacy boards from the main Kconfig on at91,
>> we can use that symbol to easily hide the old options.
>>
>> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
>>
>> diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig
>> index 0280238..119a0a4 100644
>> --- a/arch/arm/mach-at91/Kconfig
>> +++ b/arch/arm/mach-at91/Kconfig
>> @@ -137,8 +137,9 @@ config SOC_AT91SAM9N12
>>           Select this if you are using Atmel's AT91SAM9N12 SoC.
>>
>>  # ----------------------------------------------------------
>> -
>> +if ATAGS
>>  source arch/arm/mach-at91/Kconfig.non_dt
>> +endif
>>  endif # SOC_SAM_V4_V5
>>
>>  comment "Generic Board Type"
> 
> Actually, it's not that simple. With this patch, I get:
> 
> arch/arm/Kconfig:1841:error: recursive dependency detected!
> arch/arm/Kconfig:1841:  symbol USE_OF is selected by MACH_AT91RM9200_DT
> arch/arm/mach-at91/Kconfig:147: symbol MACH_AT91RM9200_DT depends on
> SOC_AT91RM9200
> arch/arm/mach-at91/Kconfig:74:  symbol SOC_AT91RM9200 is selected by
> ARCH_AT91RM9200
> arch/arm/mach-at91/Kconfig.non_dt:12:   symbol ARCH_AT91RM9200 is part
> of choice <choice>
> arch/arm/mach-at91/Kconfig.non_dt:6:    choice <choice> contains symbol <choice>
> arch/arm/mach-at91/Kconfig.non_dt:6:    choice <choice> contains symbol ATAGS
> arch/arm/Kconfig:1850:  symbol ATAGS depends on USE_OF
> 
> Also, USE_OF isn't set at that point (it's controlled by the next
> section), so it can't be used as a replacement.
> 
> Also, isn't it a bit backwards in the first place to first set ATAGS
> vs no-ATAGS, and then get to choose what hardware you want to build
> for?

True, I was thinking it was a common pattern.

> I'll take off the last patch from the branch and re-merge it (since I
> hadn't pushed it out yet), the above can be sorted out separately.

Thanks Olof for taking care about this! We will come back on this later
or simply decide that it is not worth it / not logical...

Best regards,
-- 
Nicolas Ferre


From s.trumtrar at pengutronix.de  Wed Apr  3 03:25:24 2013
From: s.trumtrar at pengutronix.de (Steffen Trumtrar)
Date: Wed, 3 Apr 2013 09:25:24 +0200
Subject: [PATCH 04/10] arm: zynq: Load scu baseaddress at run time
In-Reply-To: <CAHTX3dKD4G0E8qoxTR2HnJVdagoeOerM+TiZzkJUPjcGwYdX_Q@mail.gmail.com>
References: <1364219596-4954-1-git-send-email-michal.simek@xilinx.com>
 <1364219596-4954-4-git-send-email-michal.simek@xilinx.com>
 <515059D4.5070903@gmail.com>
 <CAHTX3dJfvFNNuyJC54fS=NCpRxovVsxHTss8wJd_QOB2PaxL7g@mail.gmail.com>
 <51506F31.2080709@gmail.com>
 <CAHTX3d+1auKVLko+LKAA+a4rh4Rfw19ggzmS7DhvYuuCAWUwHA@mail.gmail.com>
 <1364920809.3019.30.camel@hornet>
 <CAHTX3dKD4G0E8qoxTR2HnJVdagoeOerM+TiZzkJUPjcGwYdX_Q@mail.gmail.com>
Message-ID: <20130403072524.GC32161@pengutronix.de>

On Wed, Apr 03, 2013 at 08:33:19AM +0200, Michal Simek wrote:
> Hi
> 
> 2013/4/2 Pawel Moll <pawel.moll at arm.com>
> 
> > Greetings,
> >
> > Apologies about "slightly" delayed response.
> >
> > On Mon, 2013-03-25 at 16:07 +0000, Michal Simek wrote:
> > > Pawel: You are the author of this code in vexpress. Is there any
> > > particular reason
> > > to have there that ioremap?
> >
> > At the time there was no standard DT->platsmp solution and the
> > traditional way was using the SCU to work out the CPUs.
> >
> > If I was doing this today (and I'll re-do this code at some point) I'd
> > rely on the DT in the first place and maybe then have a SCU
> > "micro-driver" double-checking the DT data against the SCU information.
> > That way I could reduce the dependency on static mappings. And this is
> > what I want to get - if possible I don't want any static mapping at all.
> >
> 
> Sure. Currently I want to use that static mapping because I know that user
> DTSes are just wrong and relating on HW is better for me right now.
> 

Wouldn't we risk getting more faulty DTSes instead of stopping them?
If you stop the support starting with kernel 3.xx everyone has to fix
their *.dts and be done with it.

Regards,
Steffen

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From nicolas.ferre at atmel.com  Wed Apr  3 03:26:10 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Wed, 3 Apr 2013 09:26:10 +0200
Subject: [PATCH] ARM: at91/tc: fix clock source id for tc block > 1
In-Reply-To: <20130403044555.GN20693@game.jcrosoft.org>
References: <1364921211-15756-1-git-send-email-linux-arm@overkiz.com>
 <20130403044555.GN20693@game.jcrosoft.org>
Message-ID: <515BD992.50009@atmel.com>

On 04/03/2013 06:45 AM, Jean-Christophe PLAGNIOL-VILLARD :
> On 18:46 Tue 02 Apr     , Boris BREZILLON wrote:
>> This patch fixes wrong clock request for TC block 2.
>> The second block was using t0_clk, t1_clk and t2_clk clks instead of
>> t3_clk, t4_clk and t5_clk clks.
>>
> this is intended as we have 3 clock per device

True.
Boris, did you hit an issue with former code that your patch is solving?
What is the reason for this patch?

Thanks, best regards,


>> Signed-off-by: Boris BREZILLON <linux-arm at overkiz.com>
>> ---
>>  drivers/misc/atmel_tclib.c |   24 ++++++++++++++++--------
>>  1 file changed, 16 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/misc/atmel_tclib.c b/drivers/misc/atmel_tclib.c
>> index c8d8e38..768a988 100644
>> --- a/drivers/misc/atmel_tclib.c
>> +++ b/drivers/misc/atmel_tclib.c
>> @@ -142,6 +142,8 @@ static int __init tc_probe(struct platform_device *pdev)
>>  	struct atmel_tc *tc;
>>  	struct clk	*clk;
>>  	int		irq;
>> +	char		clk_id[7];
>> +	int		clk_offset;
>>  
>>  	if (!platform_get_resource(pdev, IORESOURCE_MEM, 0))
>>  		return -EINVAL;
>> @@ -156,25 +158,31 @@ static int __init tc_probe(struct platform_device *pdev)
>>  
>>  	tc->pdev = pdev;
>>  
>> -	clk = clk_get(&pdev->dev, "t0_clk");
>> -	if (IS_ERR(clk)) {
>> -		kfree(tc);
>> -		return -EINVAL;
>> -	}
>> -
>>  	/* Now take SoC information if available */
>>  	if (pdev->dev.of_node) {
>>  		const struct of_device_id *match;
>>  		match = of_match_node(atmel_tcb_dt_ids, pdev->dev.of_node);
>>  		if (match)
>>  			tc->tcb_config = match->data;
>> +		clk_offset = of_alias_get_id(tc->pdev->dev.of_node, "tcb");
>> +	} else
>> +		clk_offset = pdev->id;
>> +	clk_offset *= 3;
>> +
>> +	snprintf(clk_id, sizeof(clk_id), "t%d_clk", clk_offset++);
>> +	clk = clk_get(&pdev->dev, clk_id);
>> +	if (IS_ERR(clk)) {
>> +		kfree(tc);
>> +		return -EINVAL;
>>  	}
>>  
>>  	tc->clk[0] = clk;
>> -	tc->clk[1] = clk_get(&pdev->dev, "t1_clk");
>> +	snprintf(clk_id, sizeof(clk_id), "t%d_clk", clk_offset++);
>> +	tc->clk[1] = clk_get(&pdev->dev, clk_id);
>>  	if (IS_ERR(tc->clk[1]))
>>  		tc->clk[1] = clk;
>> -	tc->clk[2] = clk_get(&pdev->dev, "t2_clk");
>> +	snprintf(clk_id, sizeof(clk_id), "t%d_clk", clk_offset++);
>> +	tc->clk[2] = clk_get(&pdev->dev, clk_id);
>>  	if (IS_ERR(tc->clk[2]))
>>  		tc->clk[2] = clk;
>>  
>> -- 
>> 1.7.9.5
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 


-- 
Nicolas Ferre


From josephl at nvidia.com  Wed Apr  3 03:33:51 2013
From: josephl at nvidia.com (Joseph Lo)
Date: Wed, 3 Apr 2013 15:33:51 +0800
Subject: [PATCH V5 9/9] ARM: dts: tegra: add the PM configurations of PMC
In-Reply-To: <20130403071932.GA23157@avionic-0098.mockup.avionic-design.de>
References: <1364901613-25080-1-git-send-email-josephl@nvidia.com>
 <1364901613-25080-10-git-send-email-josephl@nvidia.com>
 <515B38F7.5050606@wwwdotorg.org>
 <20130403055935.GB6764@avionic-0098.mockup.avionic-design.de>
 <1364970865.16957.21.camel@jlo-ubuntu-64.nvidia.com>
 <20130403070423.GB22867@avionic-0098.mockup.avionic-design.de>
 <1364973077.16957.32.camel@jlo-ubuntu-64.nvidia.com>
 <20130403071932.GA23157@avionic-0098.mockup.avionic-design.de>
Message-ID: <1364974431.16957.41.camel@jlo-ubuntu-64.nvidia.com>

On Wed, 2013-04-03 at 15:19 +0800, Thierry Reding wrote:
> * PGP Signed by an unknown key
> 
> On Wed, Apr 03, 2013 at 03:11:17PM +0800, Joseph Lo wrote:
> > On Wed, 2013-04-03 at 15:04 +0800, Thierry Reding wrote:
> > > > Old Signed by an unknown key
> > > 
> > > On Wed, Apr 03, 2013 at 02:34:25PM +0800, Joseph Lo wrote:
> > > > On Wed, 2013-04-03 at 13:59 +0800, Thierry Reding wrote:
> > > > > > Old Signed by an unknown key
> > > > > 
> > > > > On Tue, Apr 02, 2013 at 02:00:55PM -0600, Stephen Warren wrote:
> > > > > > On 04/02/2013 05:20 AM, Joseph Lo wrote:
> > > > > > > Adding the PM configuration of PMC when the platform support suspend
> > > > > > > function.
> > > > > > 
> > > > > > For this patch, some more boards could be supported, but I think we'll
> > > > > > have to rely on other people (Lucas, Thierry) to send patches for them,
> > > > > > since they know the details of the board. It's fine to leave suspend
> > > > > > disabled on those boards until later.
> > > > > 
> > > > > I'm not sure what would be the best way to get the Tamonten devices out
> > > > > of suspend again. For Plutux and TEC we have a power button that could
> > > > > possibly be reused. There's a WAKEUP pin on the Tamonten connector which
> > > > > goes to GPIO PV2, but the mechanism to trigger it is carrier-board
> > > > > dependent.
> > > > > 
> > > > > For the Medcom-Wide we don't have a power button, but it could possibly
> > > > > use the WAKEUP pin if that's connected. It seems like in all designs it
> > > > > goes to the CPLD, but I need to check with engineering if there's a way
> > > > > to manipulate it.
> > > > > 
> > > > > So yes, I think for now we can leave suspend disabled on Tamonten and I
> > > > > can send patches to enable it once I've clarified with engineering.
> > > > > 
> > > > Hi Thierry,
> > > > 
> > > > I just recall I still need at least "nvidia,cpu-pwr-good-time" and
> > > > "nvidia,cpu-pwr-off-time" two properties to make CPU idle power-down
> > > > mode (same with LP2) work normally after this series.
> > > > 
> > > > So can you provide me that or point me out where is your downstream
> > > > kernel source? There data would be come from DT after this series.
> > > 
> > > We don't have suspend support in downstream kernels either. However
> > > since the Tamonten was derived from the Harmony reference design I
> > > suppose the same values can be reused.
> > > 
> > OK. That's enough.
> > 
> > > That said, the binding document says that those values are only required
> > > if nvidia,suspend-mode is set. So if we don't add it for the Tamonten
> > > boards why would you need the cpu-pwr-good-time and cpu-pwr-off-time
> > > values. Or maybe the binding document is wrong?
> > 
> > Actually, when you support CPU idle power-down mode (LP2), you already
> > support suspend function (at least LP2 mode). Just no wake up source
> > define in DT for your boards.
> 
> Okay, but for CPU idle LP2 we don't need a wakeup source, right? I only
> need the wakeup source if I explicitly suspend the device.
> 
Yes. The difference between CPU idle and suspend LP2 is wake up from any
interrupt or specific interrupt source (wake up source for suspend).

My approach is adding CPU idle LP2 support first and make it support
suspend later. Then reorganize them into PM related code and get the
configurations from DT.

> > May I add these properties to your boards (same as Harmony)? Then you
> > can figure out your wake up source later, at least the RTC can wake up
> > your device I believe.
> 
> From what I understand there should be no changes in behaviour after
> this patch, so it should be fine.
> 
OK, thanks.




From nicolas.ferre at atmel.com  Wed Apr  3 03:45:48 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Wed, 3 Apr 2013 09:45:48 +0200
Subject: [GIT PULL] at91: DT changes for 3.10 #2
In-Reply-To: <20130402184947.GA8015@quad.lixom.net>
References: <1364569179-24773-1-git-send-email-nicolas.ferre@atmel.com>
 <20130402184947.GA8015@quad.lixom.net>
Message-ID: <515BDE2C.9030904@atmel.com>

On 04/02/2013 08:49 PM, Olof Johansson :
> On Fri, Mar 29, 2013 at 03:59:39PM +0100, Nicolas Ferre wrote:
>> Arnd, Olof,
>>
>> Here is a pull-request for AT91 that is dedicated to Device Tree
>> modifications. It is stacked on the material that you already have
>> for 3.10 in your arm-soc/at91/dt branch.
>> Following our discussion with Arnd, I added the non-urgent patches that I
>> already proposed too late for 3.9. I also included the moving of macb node
>> and kept the original patch.
>>
>> Thanks, best regards,
>>
>> The following changes since commit 6901d947be5ba1245a0f63271355b95f9056a362:
>>
>>   ARM: at91/at91sam9x5cm: add 1-wire chip on CM board (2013-03-21 16:07:15 +0100)
>>
>> are available in the git repository at:
>>
>>   git://github.com/at91linux/linux-at91.git tags/at91-dt
>>
>> for you to fetch changes up to cc2e191b0ccc5a987fdb29261ab9c264c608924d:
>>
>>   ARM: at91/dt: fix macb node declaration (2013-03-29 10:02:04 +0100)
>>
>> ----------------------------------------------------------------
>> One macb DT node move for 9x5 family: 9g15 doesn't
>> have an Ethernet interface.
>> Little fixes mainly related to at91sam9x5 DT and the
>> RTC addition.
>> Addition of the Acme Systems Aria G25 board.
>>
>> ----------------------------------------------------------------
>> Douglas Gilbert (1):
>>       ARM: at91: add Acme Systems Aria G25 board
> 
> Hi,
> 
> I just replied to the above patch -- please prefix the dts files with the
> platform so it's easier to navigate the directory.

Yes, I have to make sure that everybody agree on our side...

> Otherwise the branch contents looks good, so send a fresh request when you've
> respun.
> 
> Also, the new dts isn't added to the Makefile, please add it.

Ok, I will do. Maybe I can also stack a DT related patch about ADC
support that I was planning to add in another pull-request covering the
same topic.

Thanks, best regards,
-- 
Nicolas Ferre


From horms at verge.net.au  Wed Apr  3 03:46:05 2013
From: horms at verge.net.au (Simon Horman)
Date: Wed, 3 Apr 2013 16:46:05 +0900
Subject: [PATCH v3 1/2] irqchip: intc-irqpin: Add support for shared
 interrupt lines
In-Reply-To: <CABYn4sx_pRxgdM3kD3okmt8xbCFas+T0cczQO=RF75Q8Bt2e_Q@mail.gmail.com>
References: <1364296699-20919-1-git-send-email-hechtb+renesas@gmail.com>
 <20130327045942.GH25431@verge.net.au>
 <CABYn4sx_pRxgdM3kD3okmt8xbCFas+T0cczQO=RF75Q8Bt2e_Q@mail.gmail.com>
Message-ID: <20130403074604.GC30989@verge.net.au>

On Wed, Mar 27, 2013 at 02:50:05PM +0100, Bastian Hecht wrote:
> Hi Simon,
> 
> 2013/3/27 Simon Horman <horms at verge.net.au>:
> > On Tue, Mar 26, 2013 at 12:18:18PM +0100, Bastian Hecht wrote:
> >> On some hardware we don't have a 1-1 mapping from the external
> >> interrupts coming from INTC to the GIC SPI pins. We can however
> >> share lines to demux incoming IRQs on these SoCs.
> >>
> >> This patch enables the intc_irqpin driver to detect requests for shared
> >> interrupt lines and demuxes them properly by querying the INTC INTREQx0A
> >> registers.
> >>
> >> If you need multiple shared intc_irqpin device instances, be sure to mask
> >> out all interrupts on the INTC that share the one line before you start
> >> to register them. Else you run into IRQ floods that would be caused by
> >> interrupts for which no handler has been set up yet when the first
> >> intc_irqpin device is registered.
> >>
> >> Signed-off-by: Bastian Hecht <hechtb+renesas at gmail.com>
> >> Acked-by: Magnus Damm <damm at opensource.se>
> >
> > Thanks, I will see about queuing up these changes for v3.10.
> >
> >
> > I believe that with these changes it should be possible to rebase/rework
> > armadillo800eva-reference so that it no longer uses the unmerged INTC
> > DT bindings. Would it be possible for you to see about making a fresh
> > version of armadillo800eva-reference that is based on the next branch
> > in the Renesas tree plus this series of two patches?
> 
> yes ok, I'll prepare a new armadillo reference version. The patches
> were based on all+next, but I'll post a v4 rebased on next.
> I'll post a separate patch series for the reference code if you don't
> mind, as this might take a few days to be done.

Hi Bastian,

gentle nudge with regards to a fresh armadillo-reference.


From mkl at pengutronix.de  Wed Apr  3 03:56:41 2013
From: mkl at pengutronix.de (Marc Kleine-Budde)
Date: Wed, 03 Apr 2013 09:56:41 +0200
Subject: [PATCH 0/2] mmc: mxs-mmc: add cd-inverted and non-removeable
In-Reply-To: <1364223751-28253-1-git-send-email-mkl@pengutronix.de>
References: <1364223751-28253-1-git-send-email-mkl@pengutronix.de>
Message-ID: <515BE0B9.4010209@pengutronix.de>

On 03/25/2013 04:02 PM, Marc Kleine-Budde wrote:
> Hello,
> 
> this patch add support for the cd-inverted and non-removeable property (as
> defined in devicetree/bindings/mmc/mmc.txt) to the mxs-mmc driver. Tested on a
> custom imx28 board.
> 
> This series applies to Chris Ball's cjb/mmc-next branch.

ping

-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130403/5c9ccc69/attachment.sig>

From linux-arm at overkiz.com  Wed Apr  3 03:59:56 2013
From: linux-arm at overkiz.com (Boris BREZILLON)
Date: Wed, 03 Apr 2013 09:59:56 +0200
Subject: [PATCH] ARM: at91/tc: fix clock source id for tc block > 1
In-Reply-To: <515BD992.50009@atmel.com>
References: <1364921211-15756-1-git-send-email-linux-arm@overkiz.com>
 <20130403044555.GN20693@game.jcrosoft.org> <515BD992.50009@atmel.com>
Message-ID: <515BE17C.8050903@overkiz.com>

On 03/04/2013 09:26, Nicolas Ferre wrote:
> On 04/03/2013 06:45 AM, Jean-Christophe PLAGNIOL-VILLARD :
>> On 18:46 Tue 02 Apr     , Boris BREZILLON wrote:
>>> This patch fixes wrong clock request for TC block 2.
>>> The second block was using t0_clk, t1_clk and t2_clk clks instead of
>>> t3_clk, t4_clk and t5_clk clks.
>>>
>> this is intended as we have 3 clock per device
You're right.
>
> True.
> Boris, did you hit an issue with former code that your patch is solving?
> What is the reason for this patch?
I should have taken a closer look at the code before sending this patch.
I mistook clk name for conid devid association.

As I am enabling the tc block 1 clocks in the bootstrap code, I thought 
this was the reason for these clocks to be enabled after the kernel boot.

But I tried to disable these clocks in the bootstrap and this works fine.

Sorry if I bothered you.

Best Regards,

Boris
>
> Thanks, best regards,
>
>
>>> Signed-off-by: Boris BREZILLON <linux-arm at overkiz.com>
>>> ---
>>>   drivers/misc/atmel_tclib.c |   24 ++++++++++++++++--------
>>>   1 file changed, 16 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/drivers/misc/atmel_tclib.c b/drivers/misc/atmel_tclib.c
>>> index c8d8e38..768a988 100644
>>> --- a/drivers/misc/atmel_tclib.c
>>> +++ b/drivers/misc/atmel_tclib.c
>>> @@ -142,6 +142,8 @@ static int __init tc_probe(struct platform_device *pdev)
>>>   	struct atmel_tc *tc;
>>>   	struct clk	*clk;
>>>   	int		irq;
>>> +	char		clk_id[7];
>>> +	int		clk_offset;
>>>
>>>   	if (!platform_get_resource(pdev, IORESOURCE_MEM, 0))
>>>   		return -EINVAL;
>>> @@ -156,25 +158,31 @@ static int __init tc_probe(struct platform_device *pdev)
>>>
>>>   	tc->pdev = pdev;
>>>
>>> -	clk = clk_get(&pdev->dev, "t0_clk");
>>> -	if (IS_ERR(clk)) {
>>> -		kfree(tc);
>>> -		return -EINVAL;
>>> -	}
>>> -
>>>   	/* Now take SoC information if available */
>>>   	if (pdev->dev.of_node) {
>>>   		const struct of_device_id *match;
>>>   		match = of_match_node(atmel_tcb_dt_ids, pdev->dev.of_node);
>>>   		if (match)
>>>   			tc->tcb_config = match->data;
>>> +		clk_offset = of_alias_get_id(tc->pdev->dev.of_node, "tcb");
>>> +	} else
>>> +		clk_offset = pdev->id;
>>> +	clk_offset *= 3;
>>> +
>>> +	snprintf(clk_id, sizeof(clk_id), "t%d_clk", clk_offset++);
>>> +	clk = clk_get(&pdev->dev, clk_id);
>>> +	if (IS_ERR(clk)) {
>>> +		kfree(tc);
>>> +		return -EINVAL;
>>>   	}
>>>
>>>   	tc->clk[0] = clk;
>>> -	tc->clk[1] = clk_get(&pdev->dev, "t1_clk");
>>> +	snprintf(clk_id, sizeof(clk_id), "t%d_clk", clk_offset++);
>>> +	tc->clk[1] = clk_get(&pdev->dev, clk_id);
>>>   	if (IS_ERR(tc->clk[1]))
>>>   		tc->clk[1] = clk;
>>> -	tc->clk[2] = clk_get(&pdev->dev, "t2_clk");
>>> +	snprintf(clk_id, sizeof(clk_id), "t%d_clk", clk_offset++);
>>> +	tc->clk[2] = clk_get(&pdev->dev, clk_id);
>>>   	if (IS_ERR(tc->clk[2]))
>>>   		tc->clk[2] = clk;
>>>
>>> --
>>> 1.7.9.5
>>>
>>>
>>> _______________________________________________
>>> linux-arm-kernel mailing list
>>> linux-arm-kernel at lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>
>
>



From gang.chen at asianux.com  Wed Apr  3 04:13:16 2013
From: gang.chen at asianux.com (Chen Gang)
Date: Wed, 03 Apr 2013 16:13:16 +0800
Subject: [Suggestion] ARM64:kernel: compiling issue for early_console.
In-Reply-To: <5152DFF1.2090000@asianux.com>
References: <5152DB83.8080703@asianux.com>
 <20130327115509.GA1603@MacBook-Pro.local> <5152DFF1.2090000@asianux.com>
Message-ID: <515BE49C.8040601@asianux.com>

Hello Maintainers:

  it seems, this issue still exists in next-20130402.

  have you already fixed it in another tree ?

  if really no one fix it within this week, I should try (since I find it).

  thanks.

gchen.


On 2013?03?27? 20:02, Chen Gang wrote:
> On 2013?03?27? 19:55, Catalin Marinas wrote:
>> On Wed, Mar 27, 2013 at 11:44:03AM +0000, Chen Gang wrote:
>>>>   the error message:
>>>>     arch/arm64/kernel/early_printk.c: At top level:
>>>>     arch/arm64/kernel/early_printk.c:98:23: error: conflicting types for ?early_console?
>>>>     In file included from arch/arm64/kernel/early_printk.c:20:0:
>>>>     include/linux/console.h:145:24: note: previous declaration of ?early_console? was here
>>>>     make[1]: *** [arch/arm64/kernel/early_printk.o] Error 1
>>>>     make: *** [arch/arm64/kernel] Error 2
>> Is this in linux-next? Mainline seems fine.
> 
>   yes, it is in next-20130326 at least :-)
> 
>>
>> I saw some patches from tglx on unifying the various early printk
>> implementations, though not sure whether it's those patches causing it
>> (in which case arm64 needs to be updated as well).
> 
>   maybe, but we need check the details to prove it :-)
> 
> 
>   thanks.
> 


-- 
Chen Gang

Asianux Corporation


From magnus.damm at gmail.com  Wed Apr  3 04:19:10 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Wed, 3 Apr 2013 17:19:10 +0900
Subject: [PATCH 0/5 v3] ARM: shmobile: Add SMSC support on Bock-W
In-Reply-To: <87sj395zvv.wl%kuninori.morimoto.gx@renesas.com>
References: <87zjxvewko.wl%kuninori.morimoto.gx@renesas.com>
 <87fvzb56n3.wl%kuninori.morimoto.gx@renesas.com>
 <87sj395zvv.wl%kuninori.morimoto.gx@renesas.com>
Message-ID: <CANqRtoSEf7TuBN6DZ7Qn9S8h8ts_pxahpELEK2b4KgAVpN7svw@mail.gmail.com>

Hi Morimoto-san, Simon,

On Tue, Apr 2, 2013 at 1:18 PM, Kuninori Morimoto
<kuninori.morimoto.gx at renesas.com> wrote:
>
> Hi Simon
>
> These patches are v3 of extpin support on r8a7778,
> and enable SMSC ether support on Bock-W board
>
> This patch set is based latest simon/next
>
> Kuninori Morimoto (5):
>       ARM: shmobile: r8a7778: remove pointless PLATFORM_INFO()
>       ARM: shmobile: r8a7778: add r8a7778_init_irq_extpin()
>       ARM: shmobile: bockw: add SMSC ethernet support
>       ARM: shmobile: bockw: enable network settings on bootargs
>       ARM: shmobile: bockw: enable SMSC ethernet on defconfig

Thanks, these are all fine with me.

Acked-by: Magnus Damm <damm at opensource.se>


From nicolas.ferre at atmel.com  Wed Apr  3 04:32:21 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Wed, 3 Apr 2013 10:32:21 +0200
Subject: [PATCH] ARM: at91/tc: fix clock source id for tc block > 1
In-Reply-To: <515BE17C.8050903@overkiz.com>
References: <1364921211-15756-1-git-send-email-linux-arm@overkiz.com>
 <20130403044555.GN20693@game.jcrosoft.org> <515BD992.50009@atmel.com>
 <515BE17C.8050903@overkiz.com>
Message-ID: <515BE915.4010706@atmel.com>

On 04/03/2013 09:59 AM, Boris BREZILLON :
> On 03/04/2013 09:26, Nicolas Ferre wrote:
>> On 04/03/2013 06:45 AM, Jean-Christophe PLAGNIOL-VILLARD :
>>> On 18:46 Tue 02 Apr     , Boris BREZILLON wrote:
>>>> This patch fixes wrong clock request for TC block 2.
>>>> The second block was using t0_clk, t1_clk and t2_clk clks instead of
>>>> t3_clk, t4_clk and t5_clk clks.
>>>>
>>> this is intended as we have 3 clock per device
> You're right.
>>
>> True.
>> Boris, did you hit an issue with former code that your patch is solving?
>> What is the reason for this patch?
> I should have taken a closer look at the code before sending this patch.
> I mistook clk name for conid devid association.
> 
> As I am enabling the tc block 1 clocks in the bootstrap code, I thought
> this was the reason for these clocks to be enabled after the kernel boot.
> 
> But I tried to disable these clocks in the bootstrap and this works fine.
> 
> Sorry if I bothered you.

Not bothered at all Boris! This is exactly how I like to see the
community working together.

Please feel free to send more and more patches about AT91: this is
always valuable for us.

Best regards,

>>>> Signed-off-by: Boris BREZILLON <linux-arm at overkiz.com>
>>>> ---
>>>>   drivers/misc/atmel_tclib.c |   24 ++++++++++++++++--------
>>>>   1 file changed, 16 insertions(+), 8 deletions(-)
>>>>
>>>> diff --git a/drivers/misc/atmel_tclib.c b/drivers/misc/atmel_tclib.c
>>>> index c8d8e38..768a988 100644
>>>> --- a/drivers/misc/atmel_tclib.c
>>>> +++ b/drivers/misc/atmel_tclib.c
>>>> @@ -142,6 +142,8 @@ static int __init tc_probe(struct
>>>> platform_device *pdev)
>>>>       struct atmel_tc *tc;
>>>>       struct clk    *clk;
>>>>       int        irq;
>>>> +    char        clk_id[7];
>>>> +    int        clk_offset;
>>>>
>>>>       if (!platform_get_resource(pdev, IORESOURCE_MEM, 0))
>>>>           return -EINVAL;
>>>> @@ -156,25 +158,31 @@ static int __init tc_probe(struct
>>>> platform_device *pdev)
>>>>
>>>>       tc->pdev = pdev;
>>>>
>>>> -    clk = clk_get(&pdev->dev, "t0_clk");
>>>> -    if (IS_ERR(clk)) {
>>>> -        kfree(tc);
>>>> -        return -EINVAL;
>>>> -    }
>>>> -
>>>>       /* Now take SoC information if available */
>>>>       if (pdev->dev.of_node) {
>>>>           const struct of_device_id *match;
>>>>           match = of_match_node(atmel_tcb_dt_ids, pdev->dev.of_node);
>>>>           if (match)
>>>>               tc->tcb_config = match->data;
>>>> +        clk_offset = of_alias_get_id(tc->pdev->dev.of_node, "tcb");
>>>> +    } else
>>>> +        clk_offset = pdev->id;
>>>> +    clk_offset *= 3;
>>>> +
>>>> +    snprintf(clk_id, sizeof(clk_id), "t%d_clk", clk_offset++);
>>>> +    clk = clk_get(&pdev->dev, clk_id);
>>>> +    if (IS_ERR(clk)) {
>>>> +        kfree(tc);
>>>> +        return -EINVAL;
>>>>       }
>>>>
>>>>       tc->clk[0] = clk;
>>>> -    tc->clk[1] = clk_get(&pdev->dev, "t1_clk");
>>>> +    snprintf(clk_id, sizeof(clk_id), "t%d_clk", clk_offset++);
>>>> +    tc->clk[1] = clk_get(&pdev->dev, clk_id);
>>>>       if (IS_ERR(tc->clk[1]))
>>>>           tc->clk[1] = clk;
>>>> -    tc->clk[2] = clk_get(&pdev->dev, "t2_clk");
>>>> +    snprintf(clk_id, sizeof(clk_id), "t%d_clk", clk_offset++);
>>>> +    tc->clk[2] = clk_get(&pdev->dev, clk_id);
>>>>       if (IS_ERR(tc->clk[2]))
>>>>           tc->clk[2] = clk;
>>>>
>>>> -- 
>>>> 1.7.9.5
>>>>
>>>>
>>>> _______________________________________________
>>>> linux-arm-kernel mailing list
>>>> linux-arm-kernel at lists.infradead.org
>>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>>
>>
>>
> 
> 
> 


-- 
Nicolas Ferre


From shawn.guo at linaro.org  Wed Apr  3 04:38:48 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Wed, 3 Apr 2013 16:38:48 +0800
Subject: [PATCH] pinctrl: imx5: fix SD2_DATA1 pad AUDMUX_AUD4 configuration
In-Reply-To: <201304030852.52125.marex@denx.de>
References: <1364882642-25574-1-git-send-email-marex@denx.de>
 <201304030221.18506.marex@denx.de>
 <20130403052423.GO24039@S2101-09.ap.freescale.net>
 <201304030852.52125.marex@denx.de>
Message-ID: <20130403083846.GQ24039@S2101-09.ap.freescale.net>

On Wed, Apr 03, 2013 at 08:52:51AM +0200, Marek Vasut wrote:
> Dear Shawn Guo,
> 
> > On Wed, Apr 03, 2013 at 02:21:18AM +0200, Marek Vasut wrote:
> > > One serving of such patch, coming right up ;-)
> > > 
> > > btw. do you want to apply this one for -stable or do we just leave it as
> > > is ?
> > 
> > If you do not insist, I would say let's leave it as it is, as we
> > encourage people to upgrade device tree to adopt the new pinctrl
> > binding.
> 
> Actually, I have a bad feeling about having an open bug in stable tree. Someone 
> might use that tree and might try to use AUDMUX4 on his (out-of-tree) device and 
> might run into the same problem. Three times 'might' in one sentence doesn't 
> make it sound too likely, but if you have not much trouble with getting it in -
> stable, please try to.

Ok, it's Linus' call then, since it's a fix that should go via pinctrl
tree.  Since I will not be able to rebase my 3.10 stuff on -rc7, if the
patch does not catch up with -rc6, we run into a annoying merge
conflict during the merge window.

Shawn



From shawn.guo at linaro.org  Wed Apr  3 04:50:26 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Wed, 3 Apr 2013 16:50:26 +0800
Subject: [PATCH] ARM: dts: Add initial support for Wandboard Dual-Lite
In-Reply-To: <1364964462-19143-1-git-send-email-festevam@gmail.com>
References: <1364964462-19143-1-git-send-email-festevam@gmail.com>
Message-ID: <20130403085025.GR24039@S2101-09.ap.freescale.net>

On Wed, Apr 03, 2013 at 01:47:42AM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam at freescale.com>
> 
> Wandboard is a development board that has two variants: one version based
> on mx6 dual lite and another one based on mx6 solo.
> 
> For more details about Wandboard, please refer to: http://www.wandboard.org/
> 
> Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
> ---
>  arch/arm/boot/dts/Makefile              |    1 +
>  arch/arm/boot/dts/imx6dl-wandboard.dtsp |   40 +++++++++++++++++++++++++++++++
>  arch/arm/boot/dts/imx6dl.dtsip          |   11 +++++++++
>  3 files changed, 52 insertions(+)
>  create mode 100644 arch/arm/boot/dts/imx6dl-wandboard.dtsp
> 
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 5345ac1..a566619 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -100,6 +100,7 @@ dtb-$(CONFIG_ARCH_MXC) += \
>  	imx53-smd.dtb \
>  	imx6dl-sabreauto.dtb \
>  	imx6dl-sabresd.dtb \
> +	imx6dl-wandboard.dtb \
>  	imx6q-arm2.dtb \
>  	imx6q-sabreauto.dtb \
>  	imx6q-sabrelite.dtb \
> diff --git a/arch/arm/boot/dts/imx6dl-wandboard.dtsp b/arch/arm/boot/dts/imx6dl-wandboard.dtsp
> new file mode 100644
> index 0000000..e95d2b0
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx6dl-wandboard.dtsp
> @@ -0,0 +1,40 @@
> +/*
> + * Copyright 2013 Freescale Semiconductor, Inc.
> + *
> + * Author: Fabio Estevam <fabio.estevam at freescale.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.
> + *
> + */
> +/dts-v1/;
> +#include "imx6dl.dtsip"
> +
> +/ {
> +	model = "Wandboard i.MX6 Dual Lite Board";
> +	compatible = "wand,imx6dl-wandboard", "fsl,imx6q";

"fsl,imx6dl" please.

> +
> +	memory {
> +		reg = <0x10000000 0x40000000>;
> +	};
> +};
> +
> +&fec {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_enet_1>;
> +	phy-mode = "rgmii";
> +	status = "okay";
> +};
> +
> +&uart1 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_uart1_1>;
> +	status = "okay";
> +};
> +
> +&usdhc3 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_usdhc3_4pin>;

Unlike mxs that pin groups are defined per function, imx simply defines
pin groups per controller.  So please just follow the pattern to use
something like pinctrl_usdhc3_2.

Shawn

> +	status = "okay";
> +};
> diff --git a/arch/arm/boot/dts/imx6dl.dtsip b/arch/arm/boot/dts/imx6dl.dtsip
> index 951ba53..2e6cff0 100644
> --- a/arch/arm/boot/dts/imx6dl.dtsip
> +++ b/arch/arm/boot/dts/imx6dl.dtsip
> @@ -136,6 +136,17 @@
>  							MX6DL_PAD_SD3_DAT7__SD3_DATA7 0x17059
>  						>;
>  					};
> +
> +					pinctrl_usdhc3_4pin: usdhc3grp-4pin {
> +						fsl,pins = <
> +							MX6DL_PAD_SD3_CMD__SD3_CMD    0x17059
> +							MX6DL_PAD_SD3_CLK__SD3_CLK    0x10059
> +							MX6DL_PAD_SD3_DAT0__SD3_DATA0 0x17059
> +							MX6DL_PAD_SD3_DAT1__SD3_DATA1 0x17059
> +							MX6DL_PAD_SD3_DAT2__SD3_DATA2 0x17059
> +							MX6DL_PAD_SD3_DAT3__SD3_DATA3 0x17059
> +						>;
> +					};
>  				};
>  
>  
> -- 
> 1.7.9.5
> 



From tixy at linaro.org  Wed Apr  3 05:11:52 2013
From: tixy at linaro.org (Jon Medhurst (Tixy))
Date: Wed, 03 Apr 2013 10:11:52 +0100
Subject: [PATCH] ARM: kprobes: fix test coverage missing failures
In-Reply-To: <CA+KhAHaguOmS+iq3URLg2WAROD37cGqni1NC8xbsucKYRf6Mrg@mail.gmail.com>
References: <1364871884-28252-1-git-send-email-kpark3469@gmail.com>
 <1364912353.3650.91.camel@linaro1.home>
 <CA+KhAHaguOmS+iq3URLg2WAROD37cGqni1NC8xbsucKYRf6Mrg@mail.gmail.com>
Message-ID: <1364980312.3561.7.camel@linaro1.home>

On Wed, 2013-04-03 at 11:00 +0900, Keun-O Park wrote:
> On Tue, Apr 2, 2013 at 11:19 PM, Jon Medhurst (Tixy) <tixy at linaro.org> wrote:
> > On Tue, 2013-04-02 at 12:04 +0900, kpark3469 at gmail.com wrote:
> >> From: Sahara <keun-o.park at windriver.com>
> >>
> >> If kprobe tests run on ARMv6k or ARMv6, there're a number of test
> >> coverage missing failures like:
> >
> > The tests only fail (return an error code) for the coverage tests when
> > compiled for ARMv7 because, obviously, that's the only architecture that
> > can cover all the combinations of instructions. Perhaps we should just
> > disabled the coverage tests pre-ARMv7 kernels to avoid the noisy output
> > you see.
> >
> > I think the best way to look at it is that the coverage tests are test
> > code for the test code, and should only be of concern to people updating
> > the test code.
> >
> > If we go down the route that this patch follows of conditional
> > compilation then we are making the main kernel code more messy in order
> > to support test code and I'm not sure that is a good idea. It will be
> > much worse should someone want to do the same for ARMv5.
> >
> > There is also the problem that once you #ifdef things for ARMv6 then you
> > need an ARMv6 system to test that combination of data structures,
> > whereas at the moment an ARMv7 board will cover everything.
> >
> > --
> > Tixy
> 
> Hi Jon,
> I see. You're worried about the main kernel code being tainted by adding more
> test code for test. To keep the clean decode table without #ifdef,
> most modified codes in
> arch/arm/kernel/kprobes-arm.c may be removed. architectures without
> But, in order to keep consistency supporting 'nop', I think at least we still
> need to add patches for 'nop' in arch/arm/kernel/kprobes-test.c and
> kprobes-test.h.
> It doesn't look good 'nop' is used by default like TEST_INSTRUCTION()
> while TEST('nop') is
> excluded in kprobe_arm_test_cases.

I hate to sound overly awkward, but I'm not sure I agree with this
either :-) When building for architectures without a proper NOP
instructions the assembler will treat it as a pseudo-instruction
equivalent to MOV R0,R0 in ARM code and MOV R8,R8 in Thumb code. So it
doesn't seem worth adding an explicit macro to do this if the assembler
already does it anyway.

-- 
Tixy





From prabhakar.csengg at gmail.com  Wed Apr  3 05:16:02 2013
From: prabhakar.csengg at gmail.com (Prabhakar Lad)
Date: Wed, 3 Apr 2013 14:46:02 +0530
Subject: Query on pinctrl usage for DT nodes
Message-ID: <CA+V-a8uiPwsAD--OHFAE=i2ed+-wbXm4p2deZXr92+Zv6GDS1w@mail.gmail.com>

Hi Linus/Stephen,

I am working adding  DT nodes for DA850.

Following is the pin control snippet of da850.dtsi:-

		pmx_core: pinmux at 1c14120 {
			compatible = "pinctrl-single";
			reg = <0x14120 0x50>;
			#address-cells = <1>;
			#size-cells = <0>;
			pinctrl-single,bit-per-mux;
			pinctrl-single,register-width = <32>;
			pinctrl-single,function-mask = <0xffffffff>;
			status = "disabled"

                        i2c0_pins: pinmux_i2c0_pins {
                                pinctrl-single,bits = <
                                        /* I2C0_SDA,I2C0_SCL */
                                        0x10 0x00002200 0x0000ff00
                                >;
                        };
                        mdio_pins: pinmux_mdio_pins {
                                pinctrl-single,bits = <
                                        /* MDIO_CLK, MDIO_D */
                                        0x10 0x00000088 0x000000ff
                                >;
                        };
                }

And following is the code snippet for dts:-

		i2c0: i2c at 1c22000 {
			status = "okay";
			clock-frequency = <100000>;
			pinctrl-names = "default";
			pinctrl-0 = <&i2c0_pins>;
		};
		mdio: mdio at 1e24000 {
			status = "okay";
			bus_freq = <2200000>;
			pinctrl-names = "default";
              };
		
But while booting I see the following boot log:-
...
cpuidle: using governor menu
TCP: cubic registered
NET: Registered protocol family 17
pinctrl-single 1c14120.pinmux: pin 1c14130 already requested by
davinci_mdio.0; cannot claim for i2c_davinci.1
pinctrl-single 1c14120.pinmux: pin-4 (i2c_davinci.1) status -22
pinctrl-single 1c14120.pinmux: could not request pin 4 on device pinctrl-single
console [netcon0] enabled
....

This is because the mdio and i2c are using same pin 0x10, Is there any
alternative way to handle if the two node's are using same pins any
pointers could be very much helpful ?

Regards,
--Prabhakar


From 17 at wholesaler2.tk  Wed Apr  3 05:17:26 2013
From: 17 at wholesaler2.tk (Video card photo Supply)
Date: Wed, 03 Apr 2013 09:17:26 +0000
Subject: =?GB2312?B?VmlkZW8gY2FyZCBwaG90byBTdXBwbHnT68T6ubLP7cHLz+Cy4aGj?=
Message-ID: <047d7b6d96268db4dd04d97152f5@google.com>

Dear Sir or Madam,
Electronics Co.,Ltd here.
We specialize in electronic devices field with full experience and we have  
100 % confidence in our technology and quality.
Now our hot seller is video card ?

Video card is a digital product just like a Mp4 with a printing paper to  
cover it . You can design the artwork of the paper , and put the video you  
prefer into it . Usually we used the video card for business promotion or  
as the gift to your customers or friends .

If any interest, feel free to contact me.
Best regards,

Cherry
Sales Specialist

ELECTRONIC LIMITED

https://picasaweb.google.com/lh/sredir?uname=111891504856419410645&target=ALBUM&id=5852624663795756561&authkey=Gv1sRgCODrltKymKjWZA&invite=CNjkuvcK&feat=email
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130403/0623f0e2/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: picasaweblogo-zh_CN.gif
Type: image/gif
Size: 1646 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130403/0623f0e2/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: email.jpg
Type: image/jpeg
Size: 5118 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130403/0623f0e2/attachment.jpg>

From g.liakhovetski at gmx.de  Wed Apr  3 05:19:03 2013
From: g.liakhovetski at gmx.de (Guennadi Liakhovetski)
Date: Wed, 3 Apr 2013 11:19:03 +0200 (CEST)
Subject: [PATCH/RFC 1/2] irqchip: renesas-intc-irqpin: DT binding for sense
 bitfield width
In-Reply-To: <Pine.LNX.4.64.1304031103590.10531@axis700.grange>
References: <Pine.LNX.4.64.1304031103590.10531@axis700.grange>
Message-ID: <Pine.LNX.4.64.1304031112170.10531@axis700.grange>

Most Renesas irqpin controllers have 4-bit sense fields, however, some
have different widths. This patch adds a DT binding to optionally
specify such non-standard values.

Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas at gmail.com>
---
 .../interrupt-controller/renesas,intc-irqpin.txt   |    2 ++
 drivers/irqchip/irq-renesas-intc-irqpin.c          |    5 ++++-
 2 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.txt b/Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.txt
index e55d183..6b48742 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.txt
+++ b/Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.txt
@@ -11,3 +11,5 @@ Optional properties:
   resource allocation properties
 - control-parent: disable and enable interrupts on the parent interrupt
   controller, needed for some broken implementations
+- sense-bitfield-width: width of a single sense bitfield in the SENSE register,
+  if different from the default 4 bits
diff --git a/drivers/irqchip/irq-renesas-intc-irqpin.c b/drivers/irqchip/irq-renesas-intc-irqpin.c
index 82bbe8f..6aadfe6 100644
--- a/drivers/irqchip/irq-renesas-intc-irqpin.c
+++ b/drivers/irqchip/irq-renesas-intc-irqpin.c
@@ -381,9 +381,12 @@ static int intc_irqpin_probe(struct platform_device *pdev)
 	for (k = 0; k < p->number_of_irqs; k++)
 		intc_irqpin_mask_unmask_prio(p, k, 1);
 
-	if (!pdata)
+	if (!pdata) {
 		p->config.control_parent = of_property_read_bool(pdev->dev.of_node,
 								 "control-parent");
+		of_property_read_u32(pdev->dev.of_node, "sense-bitfield-width",
+				     &p->config.sense_bitfield_width);
+	}
 
 	/* use more severe masking method if requested */
 	if (p->config.control_parent) {
-- 
1.7.2.5



From g.liakhovetski at gmx.de  Wed Apr  3 05:18:57 2013
From: g.liakhovetski at gmx.de (Guennadi Liakhovetski)
Date: Wed, 3 Apr 2013 11:18:57 +0200 (CEST)
Subject: [PATCH/RFC 0/2] ARM: shmobile: DT irqpin for r8a7779 and
 marzen-reference
Message-ID: <Pine.LNX.4.64.1304031103590.10531@axis700.grange>

Hi

This 2 patches add DT irqpin support on marzen-reference. Only 
compile-tested due to the lack of hardware. The patches can go 
independently via their respective trees. irqpin on marzen will not work 
if patch 2 is applied before patch 1, but as long as there are no devices, 
using irqpin interrupts, no breakage will be caused.

Guennadi Liakhovetski (2):
      irqchip: renesas-intc-irqpin: DT binding for sense bitfield width
      ARM: shmobile: marzen-reference: add irqpin support in DT

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/


From g.liakhovetski at gmx.de  Wed Apr  3 05:19:07 2013
From: g.liakhovetski at gmx.de (Guennadi Liakhovetski)
Date: Wed, 3 Apr 2013 11:19:07 +0200 (CEST)
Subject: [PATCH/RFC 2/2] ARM: shmobile: marzen-reference: add irqpin support
 in DT
In-Reply-To: <Pine.LNX.4.64.1304031103590.10531@axis700.grange>
References: <Pine.LNX.4.64.1304031103590.10531@axis700.grange>
Message-ID: <Pine.LNX.4.64.1304031115250.10531@axis700.grange>

Add an irqpin interrupt controller DT node on marzen-reference.

Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas at gmail.com>
---
 arch/arm/boot/dts/r8a7779.dtsi |   17 +++++++++++++++++
 1 files changed, 17 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7779.dtsi b/arch/arm/boot/dts/r8a7779.dtsi
index fe5c6f2..7f146c6 100644
--- a/arch/arm/boot/dts/r8a7779.dtsi
+++ b/arch/arm/boot/dts/r8a7779.dtsi
@@ -48,6 +48,23 @@
                       <0xf0000100 0x100>;
         };
 
+	irqpin0: irqpin at fe780010 {
+		compatible = "renesas,intc-irqpin";
+		#interrupt-cells = <2>;
+		interrupt-controller;
+		reg = <0xfe78001c 4>,
+			<0xfe780010 4>,
+			<0xfe780024 4>,
+			<0xfe780044 4>,
+			<0xfe780064 4>;
+		interrupt-parent = <&gic>;
+		interrupts = <0 27 0x4
+				0 28 0x4
+				0 29 0x4
+				0 30 0x4>;
+		sense-bitfield-width = <2>;
+	};
+
 	i2c0: i2c at 0xffc70000 {
 		#address-cells = <1>;
 		#size-cells = <0>;
-- 
1.7.2.5



From linus.walleij at stericsson.com  Wed Apr  3 05:23:34 2013
From: linus.walleij at stericsson.com (Linus Walleij)
Date: Wed, 3 Apr 2013 11:23:34 +0200
Subject: [PATCH] pinctrl/abx500: fix ab8505 alternate function
Message-ID: <1364981014-423-1-git-send-email-linus.walleij@stericsson.com>

From: Patrice Chotard <patrice.chotard at st.com>

This fix allows to correctly select default and
alternate pin mode.

By default for all ABx500 family chip, pin default
mode is selected by clearing corresponding bit in
GPIOSELx register except for pins which support
alternate function, in this case, corresponding bit
must be set.

But, due to an unlogical hardware implementation,
for one particular pin (GPIO11) reverse setting
must be done. For that, update the alternate function
array by declaring that this pin supports alternate
function.

Reported-by: Ramesh Chandrasekaran <ramesh.chandrasekaran at stericsson.com>
Signed-off-by: Patrice Chotard <patrice.chotard at st.com>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 drivers/pinctrl/pinctrl-ab8505.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pinctrl/pinctrl-ab8505.c b/drivers/pinctrl/pinctrl-ab8505.c
index 3a4238e..8ae076a 100644
--- a/drivers/pinctrl/pinctrl-ab8505.c
+++ b/drivers/pinctrl/pinctrl-ab8505.c
@@ -284,7 +284,7 @@ struct alternate_functions ab8505_alternate_functions[AB8505_GPIO_MAX_NUMBER + 1
 
 	ALTERNATE_FUNCTIONS(9, UNUSED, UNUSED, UNUSED, 0, 0, 0), /* no GPIO9, bit 0 reserved */
 	ALTERNATE_FUNCTIONS(10,      1,      0, UNUSED, 1, 0, 0), /* GPIO10, altA and altB controlled by bit 0 */
-	ALTERNATE_FUNCTIONS(11,      2, UNUSED, UNUSED, 0, 0, 0), /* GPIO11, altA controlled by bit 2 */
+	ALTERNATE_FUNCTIONS(11,      2,      1, UNUSED, 0, 0, 0), /* GPIO11, altA controlled by bit 2 */
 	ALTERNATE_FUNCTIONS(12, UNUSED, UNUSED, UNUSED, 0, 0, 0), /* no GPIO12, bit3 reseved */
 	ALTERNATE_FUNCTIONS(13,      4,      3,      4, 1, 0, 2), /* GPIO13, altA altB and altC controlled by bit 3 and 4 */
 	ALTERNATE_FUNCTIONS(14,      5, UNUSED, UNUSED, 0, 0, 0), /* GPIO14, altA controlled by bit 5 */
-- 
1.7.11.3



From nicolas.ferre at atmel.com  Wed Apr  3 05:25:03 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Wed, 3 Apr 2013 11:25:03 +0200
Subject: [PATCH] ARM: at91: remove unused dbgu_readl() macro
Message-ID: <1364981103-22980-1-git-send-email-nicolas.ferre@atmel.com>

Signed-off-by: Nicolas Ferre <nicolas.ferre at atmel.com>
---
 arch/arm/mach-at91/include/mach/at91_dbgu.h | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/arch/arm/mach-at91/include/mach/at91_dbgu.h b/arch/arm/mach-at91/include/mach/at91_dbgu.h
index 2aa0c5e..3b59485 100644
--- a/arch/arm/mach-at91/include/mach/at91_dbgu.h
+++ b/arch/arm/mach-at91/include/mach/at91_dbgu.h
@@ -16,9 +16,6 @@
 #ifndef AT91_DBGU_H
 #define AT91_DBGU_H
 
-#define dbgu_readl(dbgu, field) \
-	__raw_readl(AT91_VA_BASE_SYS + dbgu + AT91_DBGU_ ## field)
-
 #if !defined(CONFIG_ARCH_AT91X40)
 #define AT91_DBGU_CR		(0x00)	/* Control Register */
 #define AT91_DBGU_MR		(0x04)	/* Mode Register */
-- 
1.8.0



From florian at openwrt.org  Wed Apr  3 05:27:02 2013
From: florian at openwrt.org (Florian Fainelli)
Date: Wed, 03 Apr 2013 11:27:02 +0200
Subject: [PATCH 2/4] ARM: kirkwood: add device node entries for the gigabit
 interfaces
In-Reply-To: <1364580879-4297-3-git-send-email-florian@openwrt.org>
References: <1364580879-4297-1-git-send-email-florian@openwrt.org>
 <1364580879-4297-3-git-send-email-florian@openwrt.org>
Message-ID: <515BF5E6.5040703@openwrt.org>

Le 03/29/13 19:14, Florian Fainelli a ?crit :
> This patch modifies kirkwood.dtsi to specify the various gigabit
> interfaces nodes available on kirkwood devices. They are disabled by
> default and should be enabled on a per-board basis. egiga0 and egiga1
> aliases are defined for convenience. The mdio node is also present and
> should be enabled on a per-board basis as well.
>
> Signed-off-by: Florian Fainelli <florian at openwrt.org>
> ---

[snip]

> +
> +		ethernet-group at 70000 {

This one is off-by 0x2000 and should have been 72000

> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +			compatible = "marvell,mv643xx-eth-block";
> +			reg = <0x70000 0x4000>;

Same here

> +			tx-csum-limit = <1600>;
> +			status = "disabled";
> +
> +			egiga0: egiga0 at 0 {
> +				device_type = "network";
> +				compatible = "marvell,mv643xx-eth";
> +				reg = <0>;
> +				interrupts = <11>;
> +				clocks = <&gate_clk 0>;
> +				clock-names = "0";
> +			};
> +		};
> +
> +		ethernet-group at 74000 {

And here, it should be 76000

> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +			compatible = "marvell,mv643xx-eth-block";
> +			reg = <0x74000 0x4000>;

And here too.
--
Florian


From tpiepho at gmail.com  Wed Apr  3 05:32:01 2013
From: tpiepho at gmail.com (Trent Piepho)
Date: Wed, 3 Apr 2013 02:32:01 -0700
Subject: [PATCH V2 08/12] spi/mxs: Fix race in setup method
In-Reply-To: <201304030850.31752.marex@denx.de>
References: <1364905195-24286-1-git-send-email-tpiepho@gmail.com>
 <201304030427.41297.marex@denx.de>
 <CA+7tXih2r6YFE80y7z7Nj7c0Ytvh+v56-SrbS+VQ7kCW3KBRXA@mail.gmail.com>
 <201304030850.31752.marex@denx.de>
Message-ID: <CA+7tXih95vdd1dDjxx9aMwhody7J5LrfTpERz-412BaVW9TzSw@mail.gmail.com>

On Tue, Apr 2, 2013 at 11:50 PM, Marek Vasut <marex at denx.de> wrote:
> Dear Trent Piepho,
>
>> On Apr 2, 2013 7:27 PM, "Marek Vasut" <marex at denx.de> wrote:
>> > > The only useful thing mxs_spi_setup_transfer() (which
>> > > is no longer called) did in this instance was make that check.
>> > >
>> > > > btw. I was under the impression the MXS SSP block can handle other
>> > > > word-widths than 8 bit, no ?
>> > >
>> > > In theory it can,
>> >
>> > In practice too ;-)
>> >
>> > > however the driver only supports 8-bits and will
>> > > reject anything else.
>> >
>> > Then please at least add a comment about this.
>>
>> What does that have to do with this patch?
>
> You're adding a piece of code. This change is
> a) not documented in the commit message
> b) unrelated to this fix, seems to be more fitting in 10/12 or something --
> maybe even shuffling the patches a bit might help

It's not changing the behavior and it's not new code.  It's existing
code that was in a different function, but that function does other
things which can't be done at this point.  That's in the patch
description.  It is obviously part of the this patch since not calling
mxs_spi_setup_transfer() would include continuing to have the same
behavior w.r.t. checking the spi device settings that was already in
existence.

> So add a comment to make this clearer for people who hack on this after you.
>
>> There was no comment about
>> it before.  You're insisting that changes be broken up to the extent
>> that changing one line of code takes multiple patches!  Now you want a
>> comment about existing driver behavior added to patch that doesn't
>> change that behavior?
>>
>> Documenting the driver behavior would seem to be a job for the driver
>> maintainer.  If doing this is something I need to do, then maybe I
>> should maintain it?
>
> You ain't rubbing people the right way at all, I tell you. This pushy/offensive
> behavior helps noone, calm down please. It is usually a good idea to sleep on
> your reply or take your time.

Well neither are you!  I put up with your nitpicking far more than I
should have.  Move a comment from one line to another?  Really?  You
want me to waste the time to make a new patch series just because you
think a four word comment would look nicer one line up?  That's
ridiculous!  I think you've gone beyond the point of finding flaws or
mistakes (have you found any actual bugs in any of my code?) and are
just being obstructionist.

> Ad maintainership -- there's no maintainer of the driver, there's only Fabio,
> Shawn, me and the SPI subsystem guys. And it works well. It's everybodys' code
> and everyone's welcome to contribute. What's the problem?

I've spent far more time dealing with demands to split tiny patches
into even tinier patches and tweak the exact character placement to
your personal desires than I did to find and fix the bugs in the first
place!  I think you should accept that if you didn't fix the driver
before now, then someone else is going to fix it or replace it.  So
you had your opportunity to get every last character exactly the way
you wanted it and that passed.  I fixed it.  So I get to use my
judgement and write what I think is best.  If you can find any actual
bugs, or even CodingStyle errors, or merely that a majority of
existing kernel code is stylistically different, or different way of
doing something that has an object improvement, then I'm all ears.
But there is no need for you to complain about completely irrelevant
details.  I've had people submit patches to my code that didn't do
things the way I would have done it.  But you know what, if I wanted
it done my way I should have done it myself when I had the chance.

Since I seem to know how this driver works better than anyone else who
has come forward, maybe I should maintain it?  That way I can spend my
time fixing it instead or dealing making silly changes to patches.


From richard.genoud at gmail.com  Wed Apr  3 05:42:50 2013
From: richard.genoud at gmail.com (Richard GENOUD)
Date: Wed, 3 Apr 2013 11:42:50 +0200
Subject: [PATCH v8 1/8] spi/spi-atmel: add physical base address
In-Reply-To: <1364968662-23763-1-git-send-email-wenyou.yang@atmel.com>
References: <1364968581-23700-1-git-send-email-wenyou.yang@atmel.com>
 <1364968662-23763-1-git-send-email-wenyou.yang@atmel.com>
Message-ID: <20130403094247.GA26067@lnx-rg>

On [mer., 03.04.2013 13:57:42], Wenyou Yang wrote:
> From: Nicolas Ferre <nicolas.ferre at atmel.com>
> 
> Needed for future use with dmaengine enabled driver.
> 
> Signed-off-by: Nicolas Ferre <nicolas.ferre at atmel.com>
> Cc: spi-devel-general at lists.sourceforge.net
> Cc: linux-kernel at vger.kernel.org
> [wenyou.yang at atmel.com: submit the patch]
> Signed-off-by: Wenyou Yang <wenyou.yang at atmel.com>
> ---
>  drivers/spi/spi-atmel.c |    2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
> index 15e8459..38f8c0d 100644
> --- a/drivers/spi/spi-atmel.c
> +++ b/drivers/spi/spi-atmel.c
> @@ -196,6 +196,7 @@ struct atmel_spi_caps {
>  struct atmel_spi {
>  	spinlock_t		lock;
>  
> +	phys_addr_t		phybase;
>  	void __iomem		*regs;
>  	int			irq;
>  	struct clk		*clk;
> @@ -996,6 +997,7 @@ static int atmel_spi_probe(struct platform_device *pdev)
>  	as->regs = ioremap(regs->start, resource_size(regs));
>  	if (!as->regs)
>  		goto out_free_buffer;
> +	as->phybase = regs->start;
>  	as->irq = irq;
>  	as->clk = clk;
>  
> -- 
> 1.7.9.5
> 
Tested-by: Richard Genoud <richard.genoud at gmail.com>


From marc.zyngier at arm.com  Wed Apr  3 05:43:13 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed,  3 Apr 2013 10:43:13 +0100
Subject: [PATCH] ARM: KVM: fix KVM_CAP_ARM_SET_DEVICE_ADDR reporting
Message-ID: <1364982193-21867-1-git-send-email-marc.zyngier@arm.com>

Commit 3401d54696f9 (KVM: ARM: Introduce KVM_ARM_SET_DEVICE_ADDR
ioctl) added support for the KVM_CAP_ARM_SET_DEVICE_ADDR capability,
but failed to add a break in the relevant case statement, returning
the number of CPUs instead.

Luckilly enough, the CONFIG_NR_CPUS=0 patch hasn't been merged yet
(https://lkml.org/lkml/diff/2012/3/31/131/1), so the bug wasn't
noticed.

Just give it a break!

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm/kvm/arm.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index 6cc076e..d568e83 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -198,6 +198,7 @@ int kvm_dev_ioctl_check_extension(long ext)
 		break;
 	case KVM_CAP_ARM_SET_DEVICE_ADDR:
 		r = 1;
+		break;
 	case KVM_CAP_NR_VCPUS:
 		r = num_online_cpus();
 		break;
-- 
1.8.1.4




From will.deacon at arm.com  Wed Apr  3 05:43:34 2013
From: will.deacon at arm.com (Will Deacon)
Date: Wed, 3 Apr 2013 10:43:34 +0100
Subject: [PATCH 3/7] ARM: KVM: move to a KVM provided HYP idmap
In-Reply-To: <1364909115-3810-4-git-send-email-marc.zyngier@arm.com>
References: <1364909115-3810-1-git-send-email-marc.zyngier@arm.com>
 <1364909115-3810-4-git-send-email-marc.zyngier@arm.com>
Message-ID: <20130403094334.GB11040@mudshark.cambridge.arm.com>

On Tue, Apr 02, 2013 at 02:25:11PM +0100, Marc Zyngier wrote:
> After the HYP page table rework, it is pretty easy to let the KVM
> code provide its own idmap, rather than expecting the kernel to
> provide it. It takes actually less code to do so.
> 
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> ---
>  arch/arm/include/asm/idmap.h   |  1 -
>  arch/arm/include/asm/kvm_mmu.h |  1 -
>  arch/arm/kvm/mmu.c             | 24 +++++++++++++++++++++++-
>  arch/arm/mm/idmap.c            | 31 +------------------------------
>  4 files changed, 24 insertions(+), 33 deletions(-)

[...]

> diff --git a/arch/arm/mm/idmap.c b/arch/arm/mm/idmap.c
> index 5ee505c..9c467d0 100644
> --- a/arch/arm/mm/idmap.c
> +++ b/arch/arm/mm/idmap.c
> @@ -83,37 +83,10 @@ static void identity_mapping_add(pgd_t *pgd, const char *text_start,
>  	} while (pgd++, addr = next, addr != end);
>  }
>  
> -#if defined(CONFIG_ARM_VIRT_EXT) && defined(CONFIG_ARM_LPAE)
> -pgd_t *hyp_pgd;
> -
> -extern char  __hyp_idmap_text_start[], __hyp_idmap_text_end[];
> -
> -static int __init init_static_idmap_hyp(void)
> -{
> -	hyp_pgd = kzalloc(PTRS_PER_PGD * sizeof(pgd_t), GFP_KERNEL);
> -	if (!hyp_pgd)
> -		return -ENOMEM;
> -
> -	pr_info("Setting up static HYP identity map for 0x%p - 0x%p\n",
> -		__hyp_idmap_text_start, __hyp_idmap_text_end);
> -	identity_mapping_add(hyp_pgd, __hyp_idmap_text_start,
> -			     __hyp_idmap_text_end, PMD_SECT_AP1);
> -
> -	return 0;
> -}
> -#else
> -static int __init init_static_idmap_hyp(void)
> -{
> -	return 0;
> -}
> -#endif
> -
>  extern char  __idmap_text_start[], __idmap_text_end[];
>  
>  static int __init init_static_idmap(void)
>  {
> -	int ret;
> -
>  	idmap_pgd = pgd_alloc(&init_mm);
>  	if (!idmap_pgd)
>  		return -ENOMEM;
> @@ -123,12 +96,10 @@ static int __init init_static_idmap(void)
>  	identity_mapping_add(idmap_pgd, __idmap_text_start,
>  			     __idmap_text_end, 0);
>  
> -	ret = init_static_idmap_hyp();
> -
>  	/* Flush L1 for the hardware to see this page table content */
>  	flush_cache_louis();
>  
> -	return ret;
> +	return 0;
>  }
>  early_initcall(init_static_idmap);

You can probably kill off the #include <asm/virt.h> from this file too,
although I can't immediately see why it's needed anyway.

If that works out,

  Acked-by: Will Deacon <will.deacon at arm.com>

Will


From marc.zyngier at arm.com  Wed Apr  3 05:46:27 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 03 Apr 2013 10:46:27 +0100
Subject: [PATCH 3/7] ARM: KVM: move to a KVM provided HYP idmap
In-Reply-To: <20130403094334.GB11040@mudshark.cambridge.arm.com>
References: <1364909115-3810-1-git-send-email-marc.zyngier@arm.com>
 <1364909115-3810-4-git-send-email-marc.zyngier@arm.com>
 <20130403094334.GB11040@mudshark.cambridge.arm.com>
Message-ID: <515BFA73.6070804@arm.com>

On 03/04/13 10:43, Will Deacon wrote:
> On Tue, Apr 02, 2013 at 02:25:11PM +0100, Marc Zyngier wrote:
>> After the HYP page table rework, it is pretty easy to let the KVM
>> code provide its own idmap, rather than expecting the kernel to
>> provide it. It takes actually less code to do so.
>>
>> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
>> ---
>>  arch/arm/include/asm/idmap.h   |  1 -
>>  arch/arm/include/asm/kvm_mmu.h |  1 -
>>  arch/arm/kvm/mmu.c             | 24 +++++++++++++++++++++++-
>>  arch/arm/mm/idmap.c            | 31 +------------------------------
>>  4 files changed, 24 insertions(+), 33 deletions(-)
> 
> [...]
> 
>> diff --git a/arch/arm/mm/idmap.c b/arch/arm/mm/idmap.c
>> index 5ee505c..9c467d0 100644
>> --- a/arch/arm/mm/idmap.c
>> +++ b/arch/arm/mm/idmap.c
>> @@ -83,37 +83,10 @@ static void identity_mapping_add(pgd_t *pgd, const char *text_start,
>>  	} while (pgd++, addr = next, addr != end);
>>  }
>>  
>> -#if defined(CONFIG_ARM_VIRT_EXT) && defined(CONFIG_ARM_LPAE)
>> -pgd_t *hyp_pgd;
>> -
>> -extern char  __hyp_idmap_text_start[], __hyp_idmap_text_end[];
>> -
>> -static int __init init_static_idmap_hyp(void)
>> -{
>> -	hyp_pgd = kzalloc(PTRS_PER_PGD * sizeof(pgd_t), GFP_KERNEL);
>> -	if (!hyp_pgd)
>> -		return -ENOMEM;
>> -
>> -	pr_info("Setting up static HYP identity map for 0x%p - 0x%p\n",
>> -		__hyp_idmap_text_start, __hyp_idmap_text_end);
>> -	identity_mapping_add(hyp_pgd, __hyp_idmap_text_start,
>> -			     __hyp_idmap_text_end, PMD_SECT_AP1);
>> -
>> -	return 0;
>> -}
>> -#else
>> -static int __init init_static_idmap_hyp(void)
>> -{
>> -	return 0;
>> -}
>> -#endif
>> -
>>  extern char  __idmap_text_start[], __idmap_text_end[];
>>  
>>  static int __init init_static_idmap(void)
>>  {
>> -	int ret;
>> -
>>  	idmap_pgd = pgd_alloc(&init_mm);
>>  	if (!idmap_pgd)
>>  		return -ENOMEM;
>> @@ -123,12 +96,10 @@ static int __init init_static_idmap(void)
>>  	identity_mapping_add(idmap_pgd, __idmap_text_start,
>>  			     __idmap_text_end, 0);
>>  
>> -	ret = init_static_idmap_hyp();
>> -
>>  	/* Flush L1 for the hardware to see this page table content */
>>  	flush_cache_louis();
>>  
>> -	return ret;
>> +	return 0;
>>  }
>>  early_initcall(init_static_idmap);
> 
> You can probably kill off the #include <asm/virt.h> from this file too,
> although I can't immediately see why it's needed anyway.

It should never have been there the first place! I'll get rid of it in v2.

> If that works out,
> 
>   Acked-by: Will Deacon <will.deacon at arm.com>

Thanks!

	M.
-- 
Jazz is not dead. It just smells funny...



From gang.chen at asianux.com  Wed Apr  3 05:46:53 2013
From: gang.chen at asianux.com (Chen Gang)
Date: Wed, 03 Apr 2013 17:46:53 +0800
Subject: [Suggestion] ARM:S5pv210: compiling issue for s5pv210 by using
 randconfig
In-Reply-To: <514FB202.3040807@asianux.com>
References: <514FB202.3040807@asianux.com>
Message-ID: <515BFA8D.2000204@asianux.com>

Hello Maintainers:

  when you have time, could you help to check this suggestion ?

  if we really need treat it as an issue, and also no one have time to
fix it, I should try.


  thanks.

gchen.

On 2013?03?25? 10:10, Chen Gang wrote:
> Hello Maintainers:
> 
>   is it an issue that need solving ?
> 
>   :-)
> 
> 
> details:
> 
>   make:
>     make V=1 EXTRA_CFLAGS=-W ARCH=arm randconfig
>     make V=1 EXTRA_CFLAGS=-W ARCH=arm menuconfig
>       set arm-linux-gnu-  for "Cross-compiler tool prefix"
>       set "Samsung S5PV210/S5PC210" for "ARM system type"
>     make V=1 EXTRA_CFLAGS=-W ARCH=arm
> 
> 
>   err:
>     arch/arm/kernel/entry-armv.S: Assembler messages:
>     arch/arm/kernel/entry-armv.S:207: Error: selected processor does not support ARM mode `clrex'
>     arch/arm/kernel/entry-armv.S:231: Error: selected processor does not support ARM mode `clrex'
>     arch/arm/kernel/entry-armv.S:314: Error: selected processor does not support ARM mode `clrex'
>     arch/arm/kernel/entry-armv.S:335: Error: selected processor does not support ARM mode `clrex'
>     arch/arm/kernel/entry-armv.S:813: Error: selected processor does not support ARM mode `ldrd r4,r5,[r0]'
>     arch/arm/kernel/entry-armv.S:814: Error: selected processor does not support ARM mode `ldrd r6,r7,[r1]'
>     arch/arm/kernel/entry-armv.S:816: Error: selected processor does not support ARM mode `ldrexd r0,r1,[r2]'
>     arch/arm/kernel/entry-armv.S:819: Error: selected processor does not support ARM mode `strexdeq r3,r6,r7,[r2]'
>     make[1]: *** [arch/arm/kernel/entry-armv.o] Error 1
>     make: *** [arch/arm/kernel] Error 2
> 
>   related gcc command:
> arm-linux-gnu-gcc -Wp,-MD,arch/arm/kernel/.entry-armv.o.d  -nostdinc -isystem /usr/lib/gcc/arm-linux-gnueabi/4.7.1/include -I/android/public-kernel/linux-next/arch/arm/include -Iarch/arm/include/generated  -Iinclude -I/android/public-kernel/linux-next/arch/arm/include/uapi -Iarch/arm/include/generated/uapi -I/android/public-kernel/linux-next/include/uapi -Iinclude/generated/uapi -include /android/public-kernel/linux-next/include/linux/kconfig.h -D__KERNEL__ -mlittle-endian -Iarch/arm/mach-s5pv210/include -Iarch/arm/plat-samsung/include  -D__ASSEMBLY__ -mabi=apcs-gnu -mno-thumb-interwork -marm -D__LINUX_ARM_ARCH__=4 -march=armv4t -mtune=arm9tdmi -include asm/unified.h -msoft-float          -c -o arch/arm/kernel/entry-armv.o arch/arm/kernel/entry-armv.S
> 
> 
> 
>   thanks.
> 


-- 
Chen Gang

Asianux Corporation


From ulf.hansson at stericsson.com  Wed Apr  3 05:46:52 2013
From: ulf.hansson at stericsson.com (Ulf Hansson)
Date: Wed, 3 Apr 2013 11:46:52 +0200
Subject: [PATCH V2 1/3] clk: ux500: Add support for sysctrl clocks
Message-ID: <1364982412-9853-1-git-send-email-ulf.hansson@stericsson.com>

From: Ulf Hansson <ulf.hansson at linaro.org>

The abx500 sysctrl clocks are using the ab8500 sysctrl driver to
modify the clock hardware. Sysctrl clocks are represented by a
ab8500 sysctrl register and with a corresponding bitmask.

The sysctrl clocks are slow path clocks, which means clk_prepare
and clk_unprepare will be used to gate|ungate these clocks.

Signed-off-by: Ulf Hansson <ulf.hansson at linaro.org>
---

Changes in v2:
	- Removed wrong header file.

---
 drivers/clk/ux500/Makefile      |    1 +
 drivers/clk/ux500/clk-sysctrl.c |  223 +++++++++++++++++++++++++++++++++++++++
 drivers/clk/ux500/clk.h         |   29 +++++
 3 files changed, 253 insertions(+)
 create mode 100644 drivers/clk/ux500/clk-sysctrl.c

diff --git a/drivers/clk/ux500/Makefile b/drivers/clk/ux500/Makefile
index bcc0c11..c6a806e 100644
--- a/drivers/clk/ux500/Makefile
+++ b/drivers/clk/ux500/Makefile
@@ -5,6 +5,7 @@
 # Clock types
 obj-y += clk-prcc.o
 obj-y += clk-prcmu.o
+obj-y += clk-sysctrl.o
 
 # Clock definitions
 obj-y += u8500_clk.o
diff --git a/drivers/clk/ux500/clk-sysctrl.c b/drivers/clk/ux500/clk-sysctrl.c
new file mode 100644
index 0000000..162a02b
--- /dev/null
+++ b/drivers/clk/ux500/clk-sysctrl.c
@@ -0,0 +1,223 @@
+/*
+ * Sysctrl clock implementation for ux500 platform.
+ *
+ * Copyright (C) 2013 ST-Ericsson SA
+ * Author: Ulf Hansson <ulf.hansson at linaro.org>
+ *
+ * License terms: GNU General Public License (GPL) version 2
+ */
+
+#include <linux/clk-provider.h>
+#include <linux/mfd/abx500/ab8500-sysctrl.h>
+#include <linux/device.h>
+#include <linux/slab.h>
+#include <linux/delay.h>
+#include <linux/io.h>
+#include <linux/err.h>
+#include "clk.h"
+
+#define SYSCTRL_MAX_NUM_PARENTS 4
+
+#define to_clk_sysctrl(_hw) container_of(_hw, struct clk_sysctrl, hw)
+
+struct clk_sysctrl {
+	struct clk_hw hw;
+	struct device *dev;
+	u8 parent_index;
+	u16 reg_sel[SYSCTRL_MAX_NUM_PARENTS];
+	u8 reg_mask[SYSCTRL_MAX_NUM_PARENTS];
+	u8 reg_bits[SYSCTRL_MAX_NUM_PARENTS];
+	unsigned long rate;
+	unsigned long enable_delay_us;
+};
+
+/* Sysctrl clock operations. */
+
+static int clk_sysctrl_prepare(struct clk_hw *hw)
+{
+	int ret;
+	struct clk_sysctrl *clk = to_clk_sysctrl(hw);
+
+	ret = ab8500_sysctrl_write(clk->reg_sel[0], clk->reg_mask[0],
+				clk->reg_bits[0]);
+
+	if (!ret && clk->enable_delay_us)
+		usleep_range(clk->enable_delay_us, clk->enable_delay_us);
+
+	return ret;
+}
+
+static void clk_sysctrl_unprepare(struct clk_hw *hw)
+{
+	struct clk_sysctrl *clk = to_clk_sysctrl(hw);
+	if (ab8500_sysctrl_clear(clk->reg_sel[0], clk->reg_mask[0]))
+		dev_err(clk->dev, "clk_sysctrl: %s fail to clear %s.\n",
+			__func__, __clk_get_name(hw->clk));
+}
+
+static unsigned long clk_sysctrl_recalc_rate(struct clk_hw *hw,
+					unsigned long parent_rate)
+{
+	struct clk_sysctrl *clk = to_clk_sysctrl(hw);
+	return clk->rate;
+}
+
+static int clk_sysctrl_set_parent(struct clk_hw *hw, u8 index)
+{
+	struct clk_sysctrl *clk = to_clk_sysctrl(hw);
+	u8 old_index = clk->parent_index;
+	int ret = 0;
+
+	if (clk->reg_sel[old_index]) {
+		ret = ab8500_sysctrl_clear(clk->reg_sel[old_index],
+					clk->reg_mask[old_index]);
+		if (ret)
+			return ret;
+	}
+
+	if (clk->reg_sel[index]) {
+		ret = ab8500_sysctrl_write(clk->reg_sel[index],
+					clk->reg_mask[index],
+					clk->reg_bits[index]);
+		if (ret) {
+			if (clk->reg_sel[old_index])
+				ab8500_sysctrl_write(clk->reg_sel[old_index],
+						clk->reg_mask[old_index],
+						clk->reg_bits[old_index]);
+			return ret;
+		}
+	}
+	clk->parent_index = index;
+
+	return ret;
+}
+
+static u8 clk_sysctrl_get_parent(struct clk_hw *hw)
+{
+	struct clk_sysctrl *clk = to_clk_sysctrl(hw);
+	return clk->parent_index;
+}
+
+static struct clk_ops clk_sysctrl_gate_ops = {
+	.prepare = clk_sysctrl_prepare,
+	.unprepare = clk_sysctrl_unprepare,
+};
+
+static struct clk_ops clk_sysctrl_gate_fixed_rate_ops = {
+	.prepare = clk_sysctrl_prepare,
+	.unprepare = clk_sysctrl_unprepare,
+	.recalc_rate = clk_sysctrl_recalc_rate,
+};
+
+static struct clk_ops clk_sysctrl_set_parent_ops = {
+	.set_parent = clk_sysctrl_set_parent,
+	.get_parent = clk_sysctrl_get_parent,
+};
+
+static struct clk *clk_reg_sysctrl(struct device *dev,
+				const char *name,
+				const char **parent_names,
+				u8 num_parents,
+				u16 *reg_sel,
+				u8 *reg_mask,
+				u8 *reg_bits,
+				unsigned long rate,
+				unsigned long enable_delay_us,
+				unsigned long flags,
+				struct clk_ops *clk_sysctrl_ops)
+{
+	struct clk_sysctrl *clk;
+	struct clk_init_data clk_sysctrl_init;
+	struct clk *clk_reg;
+	int i;
+
+	if (!dev)
+		return ERR_PTR(-EINVAL);
+
+	if (!name || (num_parents > SYSCTRL_MAX_NUM_PARENTS)) {
+		dev_err(dev, "clk_sysctrl: invalid arguments passed\n");
+		return ERR_PTR(-EINVAL);
+	}
+
+	clk = devm_kzalloc(dev, sizeof(struct clk_sysctrl), GFP_KERNEL);
+	if (!clk) {
+		dev_err(dev, "clk_sysctrl: could not allocate clk\n");
+		return ERR_PTR(-ENOMEM);
+	}
+
+	for (i = 0; i < num_parents; i++) {
+		clk->reg_sel[i] = reg_sel[i];
+		clk->reg_bits[i] = reg_bits[i];
+		clk->reg_mask[i] = reg_mask[i];
+	}
+
+	clk->parent_index = 0;
+	clk->rate = rate;
+	clk->enable_delay_us = enable_delay_us;
+	clk->dev = dev;
+
+	clk_sysctrl_init.name = name;
+	clk_sysctrl_init.ops = clk_sysctrl_ops;
+	clk_sysctrl_init.flags = flags;
+	clk_sysctrl_init.parent_names = parent_names;
+	clk_sysctrl_init.num_parents = num_parents;
+	clk->hw.init = &clk_sysctrl_init;
+
+	clk_reg = devm_clk_register(clk->dev, &clk->hw);
+	if (IS_ERR_OR_NULL(clk_reg)) {
+		dev_err(dev, "clk_sysctrl: clk_register failed\n");
+		return ERR_PTR(-ENOMEM);
+	}
+
+	return clk_reg;
+}
+
+struct clk *clk_reg_sysctrl_gate(struct device *dev,
+				const char *name,
+				const char *parent_name,
+				u16 reg_sel,
+				u8 reg_mask,
+				u8 reg_bits,
+				unsigned long enable_delay_us,
+				unsigned long flags)
+{
+	const char **parent_names = (parent_name ? &parent_name : NULL);
+	u8 num_parents = (parent_name ? 1 : 0);
+
+	return clk_reg_sysctrl(dev, name, parent_names, num_parents,
+			&reg_sel, &reg_mask, &reg_bits, 0, enable_delay_us,
+			flags, &clk_sysctrl_gate_ops);
+}
+
+struct clk *clk_reg_sysctrl_gate_fixed_rate(struct device *dev,
+					const char *name,
+					const char *parent_name,
+					u16 reg_sel,
+					u8 reg_mask,
+					u8 reg_bits,
+					unsigned long rate,
+					unsigned long enable_delay_us,
+					unsigned long flags)
+{
+	const char **parent_names = (parent_name ? &parent_name : NULL);
+	u8 num_parents = (parent_name ? 1 : 0);
+
+	return clk_reg_sysctrl(dev, name, parent_names, num_parents,
+			&reg_sel, &reg_mask, &reg_bits,
+			rate, enable_delay_us, flags,
+			&clk_sysctrl_gate_fixed_rate_ops);
+}
+
+struct clk *clk_reg_sysctrl_set_parent(struct device *dev,
+				const char *name,
+				const char **parent_names,
+				u8 num_parents,
+				u16 *reg_sel,
+				u8 *reg_mask,
+				u8 *reg_bits,
+				unsigned long flags)
+{
+	return clk_reg_sysctrl(dev, name, parent_names, num_parents,
+			reg_sel, reg_mask, reg_bits, 0, 0, flags,
+			&clk_sysctrl_set_parent_ops);
+}
diff --git a/drivers/clk/ux500/clk.h b/drivers/clk/ux500/clk.h
index c3e4491..3d2dfdc 100644
--- a/drivers/clk/ux500/clk.h
+++ b/drivers/clk/ux500/clk.h
@@ -11,6 +11,7 @@
 #define __UX500_CLK_H
 
 #include <linux/clk.h>
+#include <linux/device.h>
 
 struct clk *clk_reg_prcc_pclk(const char *name,
 			      const char *parent_name,
@@ -57,4 +58,32 @@ struct clk *clk_reg_prcmu_opp_volt_scalable(const char *name,
 					    unsigned long rate,
 					    unsigned long flags);
 
+struct clk *clk_reg_sysctrl_gate(struct device *dev,
+				 const char *name,
+				 const char *parent_name,
+				 u16 reg_sel,
+				 u8 reg_mask,
+				 u8 reg_bits,
+				 unsigned long enable_delay_us,
+				 unsigned long flags);
+
+struct clk *clk_reg_sysctrl_gate_fixed_rate(struct device *dev,
+					    const char *name,
+					    const char *parent_name,
+					    u16 reg_sel,
+					    u8 reg_mask,
+					    u8 reg_bits,
+					    unsigned long rate,
+					    unsigned long enable_delay_us,
+					    unsigned long flags);
+
+struct clk *clk_reg_sysctrl_set_parent(struct device *dev,
+				       const char *name,
+				       const char **parent_names,
+				       u8 num_parents,
+				       u16 *reg_sel,
+				       u8 *reg_mask,
+				       u8 *reg_bits,
+				       unsigned long flags);
+
 #endif /* __UX500_CLK_H */
-- 
1.7.10



From will.deacon at arm.com  Wed Apr  3 05:50:24 2013
From: will.deacon at arm.com (Will Deacon)
Date: Wed, 3 Apr 2013 10:50:24 +0100
Subject: [PATCH 4/7] ARM: KVM: enforce page alignment for identity mapped
 code
In-Reply-To: <1364909115-3810-5-git-send-email-marc.zyngier@arm.com>
References: <1364909115-3810-1-git-send-email-marc.zyngier@arm.com>
 <1364909115-3810-5-git-send-email-marc.zyngier@arm.com>
Message-ID: <20130403095024.GC11040@mudshark.cambridge.arm.com>

On Tue, Apr 02, 2013 at 02:25:12PM +0100, Marc Zyngier wrote:
> We're about to move to a init procedure where we rely on the
> fact that the init code fits in a single page. Make sure we
> align the idmap text on a page boundary, and that the code is
> not bigger than a single page.
> 
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> ---
>  arch/arm/kernel/vmlinux.lds.S | 2 +-
>  arch/arm/kvm/init.S           | 7 +++++++
>  2 files changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
> index b571484..d9dd265 100644
> --- a/arch/arm/kernel/vmlinux.lds.S
> +++ b/arch/arm/kernel/vmlinux.lds.S
> @@ -20,7 +20,7 @@
>  	VMLINUX_SYMBOL(__idmap_text_start) = .;				\
>  	*(.idmap.text)							\
>  	VMLINUX_SYMBOL(__idmap_text_end) = .;				\
> -	ALIGN_FUNCTION();						\
> +	. = ALIGN(PAGE_SIZE);						\
>  	VMLINUX_SYMBOL(__hyp_idmap_text_start) = .;			\
>  	*(.hyp.idmap.text)						\
>  	VMLINUX_SYMBOL(__hyp_idmap_text_end) = .;
> diff --git a/arch/arm/kvm/init.S b/arch/arm/kvm/init.S
> index 9f37a79..35a463f 100644
> --- a/arch/arm/kvm/init.S
> +++ b/arch/arm/kvm/init.S
> @@ -111,4 +111,11 @@ __do_hyp_init:
>  	.globl __kvm_hyp_init_end
>  __kvm_hyp_init_end:
>  
> +	/*
> +	 * The above code *must* fit in a single page for the trampoline
> +	 * madness to work. Whoever decides to change it must make sure
> +	 * we map the right amount of memory for the trampoline to work.
> +	 * The line below ensures any breakage will get noticed.
> +	 */
> +	.org	__kvm_hyp_init + PAGE_SIZE
>  	.popsection

What effect does this have on the size of the kernel image? I'd expect the
idmap code to be pretty small, so aligning to a page might be overkill a lot
of the time.

Will


From richard.genoud at gmail.com  Wed Apr  3 05:44:44 2013
From: richard.genoud at gmail.com (Richard GENOUD)
Date: Wed, 3 Apr 2013 11:44:44 +0200
Subject: [PATCH v8 2/8] spi/spi-atmel: add flag to controller data for
 lock operations
In-Reply-To: <1364968716-23848-1-git-send-email-wenyou.yang@atmel.com>
References: <1364968581-23700-1-git-send-email-wenyou.yang@atmel.com>
 <1364968716-23848-1-git-send-email-wenyou.yang@atmel.com>
Message-ID: <20130403094442.GB26067@lnx-rg>

On [mer., 03.04.2013 13:58:36], Wenyou Yang wrote:
> From: Nicolas Ferre <nicolas.ferre at atmel.com>
> 
> Will allow to drop the lock during DMA operations.
> 
> Replacing non-irqsave versions with irqsave versions of the lock
> to make it correct in both pdc and dmaengine transfer mode
> 
> Signed-off-by: Nicolas Ferre <nicolas.ferre at atmel.com>
> Cc: spi-devel-general at lists.sourceforge.net
> Cc: linux-kernel at vger.kernel.org
> [wenyou.yang at atmel.com: submit the patch]
> Signed-off-by: Wenyou Yang <wenyou.yang at atmel.com>
> ---
>  drivers/spi/spi-atmel.c |   35 +++++++++++++++++++++--------------
>  1 file changed, 21 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
> index 38f8c0d..2df562f 100644
> --- a/drivers/spi/spi-atmel.c
> +++ b/drivers/spi/spi-atmel.c
> @@ -195,6 +195,7 @@ struct atmel_spi_caps {
>   */
>  struct atmel_spi {
>  	spinlock_t		lock;
> +	unsigned long		flags;
>  
>  	phys_addr_t		phybase;
>  	void __iomem		*regs;
> @@ -333,6 +334,16 @@ static void cs_deactivate(struct atmel_spi *as, struct spi_device *spi)
>  		gpio_set_value(asd->npcs_pin, !active);
>  }
>  
> +static void atmel_spi_lock(struct atmel_spi *as)
> +{
> +	spin_lock_irqsave(&as->lock, as->flags);
> +}
> +
> +static void atmel_spi_unlock(struct atmel_spi *as)
> +{
> +	spin_unlock_irqrestore(&as->lock, as->flags);
> +}
> +
>  static inline int atmel_spi_xfer_is_last(struct spi_message *msg,
>  					struct spi_transfer *xfer)
>  {
> @@ -569,9 +580,9 @@ atmel_spi_msg_done(struct spi_master *master, struct atmel_spi *as,
>  		"xfer complete: %u bytes transferred\n",
>  		msg->actual_length);
>  
> -	spin_unlock(&as->lock);
> +	atmel_spi_unlock(as);
>  	msg->complete(msg->context);
> -	spin_lock(&as->lock);
> +	atmel_spi_lock(as);
>  
>  	as->current_transfer = NULL;
>  	as->next_transfer = NULL;
> @@ -594,7 +605,7 @@ atmel_spi_interrupt(int irq, void *dev_id)
>  	u32			status, pending, imr;
>  	int			ret = IRQ_NONE;
>  
> -	spin_lock(&as->lock);
> +	atmel_spi_lock(as);
>  
>  	xfer = as->current_transfer;
>  	msg = list_entry(as->queue.next, struct spi_message, queue);
> @@ -697,7 +708,7 @@ atmel_spi_interrupt(int irq, void *dev_id)
>  		}
>  	}
>  
> -	spin_unlock(&as->lock);
> +	atmel_spi_unlock(as);
>  
>  	return ret;
>  }
> @@ -802,13 +813,11 @@ static int atmel_spi_setup(struct spi_device *spi)
>  		spi->controller_state = asd;
>  		gpio_direction_output(npcs_pin, !(spi->mode & SPI_CS_HIGH));
>  	} else {
> -		unsigned long		flags;
> -
> -		spin_lock_irqsave(&as->lock, flags);
> +		atmel_spi_lock(as);
>  		if (as->stay == spi)
>  			as->stay = NULL;
>  		cs_deactivate(as, spi);
> -		spin_unlock_irqrestore(&as->lock, flags);
> +		atmel_spi_unlock(as);
>  	}
>  
>  	asd->csr = csr;
> @@ -827,7 +836,6 @@ static int atmel_spi_transfer(struct spi_device *spi, struct spi_message *msg)
>  {
>  	struct atmel_spi	*as;
>  	struct spi_transfer	*xfer;
> -	unsigned long		flags;
>  	struct device		*controller = spi->master->dev.parent;
>  	u8			bits;
>  	struct atmel_spi_device	*asd;
> @@ -892,11 +900,11 @@ static int atmel_spi_transfer(struct spi_device *spi, struct spi_message *msg)
>  	msg->status = -EINPROGRESS;
>  	msg->actual_length = 0;
>  
> -	spin_lock_irqsave(&as->lock, flags);
> +	atmel_spi_lock(as);
>  	list_add_tail(&msg->queue, &as->queue);
>  	if (!as->current_transfer)
>  		atmel_spi_next_message(spi->master);
> -	spin_unlock_irqrestore(&as->lock, flags);
> +	atmel_spi_unlock(as);
>  
>  	return 0;
>  }
> @@ -906,17 +914,16 @@ static void atmel_spi_cleanup(struct spi_device *spi)
>  	struct atmel_spi	*as = spi_master_get_devdata(spi->master);
>  	struct atmel_spi_device	*asd = spi->controller_state;
>  	unsigned		gpio = (unsigned) spi->controller_data;
> -	unsigned long		flags;
>  
>  	if (!asd)
>  		return;
>  
> -	spin_lock_irqsave(&as->lock, flags);
> +	atmel_spi_lock(as);
>  	if (as->stay == spi) {
>  		as->stay = NULL;
>  		cs_deactivate(as, spi);
>  	}
> -	spin_unlock_irqrestore(&as->lock, flags);
> +	atmel_spi_unlock(as);
>  
>  	spi->controller_state = NULL;
>  	gpio_free(gpio);
> -- 
> 1.7.9.5
>
On sam9g35 with DMA and PIO (3.9-rc5 + device tree patches)
Tested-by: Richard Genoud <richard.genoud at gmail.com>


From jhovold at gmail.com  Wed Apr  3 05:51:50 2013
From: jhovold at gmail.com (Johan Hovold)
Date: Wed, 3 Apr 2013 11:51:50 +0200
Subject: [RFC PATCH v2] rtc: rtc-at91rm9200: manage IMR depending on
 revision
In-Reply-To: <1364920566-30040-1-git-send-email-nicolas.ferre@atmel.com>
References: <1364908007-5150-1-git-send-email-nicolas.ferre@atmel.com>
 <1364920566-30040-1-git-send-email-nicolas.ferre@atmel.com>
Message-ID: <20130403095150.GC27600@localhost>

On Tue, Apr 02, 2013 at 06:36:06PM +0200, Nicolas Ferre wrote:
> Signed-off-by: Nicolas Ferre <nicolas.ferre at atmel.com>
> ---
> Hi again,
> 
> Here is my latest revision of this fix. It depends on the patch that is already
> in Andrew's patch stack: "drivers-rtc-rtc-at91rm9200c-add-dt-support.patch".

That is a problem, as the patch in Andrew's stack is not (and should
not) be marked for stable. Hence this patch cannot be applied to the
stable trees and it won't even apply to 3.9-rc.

But there's more: The offending patch introduced the races we have been
discussion while attempting to add support for the sam9x5 with the
broken hardware register. But that family cannot be used without
DT-support, which the driver currently does not support. Hence, we added
a workaround (and introduced a regression by mistake), while adding
support for a SoC which still could not use the driver. [ For example,
the sam9x5 RTC-base register address can only be supplied from DT. ]

I think the only reasonable thing to do is to revert the patch and add
whatever version of the work-around on top of the device-tree support
when that is added to the driver (hence, earliest v3.10).

> I now use a different compatibility string to figure out what is the IP
> revision that has the "boggus IMR" error. I think this way to handle it
> is much simpler than the "config" structure one from Johan.

I wouldn't say it's much simpler. My solution is only more generic, but
could of course also be reduced to "set a flag if compatible matches
sam9x5".

> The small number of line changed and the "single patch" nature of it
> make me think that it will be easier to send upstream and in the
> "stable" trees...

Unfortunately, the 130-line diff isn't very small. In fact, it violates
the stable-kernel guide line of <100 lines. And as noted above, it
depends on another patch which adds DT-support (which is a new feature
and not a fix).

But the fundamental problem remains: it does not fix anything which was
working before the first work-around patch introduced the regression. I
think this is a clear case where we need to revert.

> Please give feedback, but moreover, I would like to know if you (Johan and Douglas)
> agree to give your "Signed-off-by" line because this patch is certainly
> inspired by your comments, code and reviews.
> 
> Thank you for your help. Best regards,
> 
>  .../bindings/rtc/atmel,at91rm9200-rtc.txt          |   3 +-
>  drivers/rtc/rtc-at91rm9200.c                       | 126 ++++++++++++++++-----
>  drivers/rtc/rtc-at91rm9200.h                       |   1 +
>  3 files changed, 101 insertions(+), 29 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/rtc/atmel,at91rm9200-rtc.txt b/Documentation/devicetree/bindings/rtc/atmel,at91rm9200-rtc.txt
> index 2a3feab..9b87053 100644
> --- a/Documentation/devicetree/bindings/rtc/atmel,at91rm9200-rtc.txt
> +++ b/Documentation/devicetree/bindings/rtc/atmel,at91rm9200-rtc.txt
> @@ -1,7 +1,8 @@
>  Atmel AT91RM9200 Real Time Clock
>  
>  Required properties:
> -- compatible: should be: "atmel,at91rm9200-rtc"
> +- compatible: should be: "atmel,at91rm9200-rtc", "atmel,at91sam9x5-rtc" or
> +                         "atmel,at91sam9n12-rtc".

Also at91sam9g45 and at91sam9rl use this driver. As seems to be the case
for other peripherals, I suggest we use "atmel,at91sam9x5-rtc" for
sam9x5 and "atmel,at91rm9200-rtc" for the other SoCs, that is, the least
(and first) common denominator.

Either way, there's not need to add at91sam9n12-rtc in this patch.

>  - reg: physical base address of the controller and length of memory mapped
>    region.
>  - interrupts: rtc alarm/event interrupt

I'll respond to this mail with a revert-patch, and an updated RFC-series
based on top of the DT-patch in Andrew's queue.

Thanks,
Johan


From jhovold at gmail.com  Wed Apr  3 05:54:22 2013
From: jhovold at gmail.com (Johan Hovold)
Date: Wed,  3 Apr 2013 11:54:22 +0200
Subject: [PATCH] Revert "drivers/rtc/rtc-at91rm9200.c: use a variable for
 storing IMR"
In-Reply-To: <20130403095150.GC27600@localhost>
References: <20130403095150.GC27600@localhost>
Message-ID: <1364982862-19759-1-git-send-email-jhovold@gmail.com>

This reverts commit 0ef1594c017521ea89278e80fe3f80dafb17abde.

This patch introduced a few races which cannot be easily fixed with a
small follow-up patch. Furthermore, the SoC with the broken hardware
register, which this patch intended to add support for, can only be used
with device trees, which this driver currently does not support.

Cc: stable <stable at vger.kernel.org>
Signed-off-by: Johan Hovold <jhovold at gmail.com>
---
 drivers/rtc/rtc-at91rm9200.c | 50 +++++++++++++++++---------------------------
 drivers/rtc/rtc-at91rm9200.h |  1 +
 2 files changed, 20 insertions(+), 31 deletions(-)

diff --git a/drivers/rtc/rtc-at91rm9200.c b/drivers/rtc/rtc-at91rm9200.c
index 0a9f27e..434ebc3 100644
--- a/drivers/rtc/rtc-at91rm9200.c
+++ b/drivers/rtc/rtc-at91rm9200.c
@@ -44,7 +44,6 @@ static DECLARE_COMPLETION(at91_rtc_updated);
 static unsigned int at91_alarm_year = AT91_RTC_EPOCH;
 static void __iomem *at91_rtc_regs;
 static int irq;
-static u32 at91_rtc_imr;
 
 /*
  * Decode time/date into rtc_time structure
@@ -109,11 +108,9 @@ static int at91_rtc_settime(struct device *dev, struct rtc_time *tm)
 	cr = at91_rtc_read(AT91_RTC_CR);
 	at91_rtc_write(AT91_RTC_CR, cr | AT91_RTC_UPDCAL | AT91_RTC_UPDTIM);
 
-	at91_rtc_imr |= AT91_RTC_ACKUPD;
 	at91_rtc_write(AT91_RTC_IER, AT91_RTC_ACKUPD);
 	wait_for_completion(&at91_rtc_updated);	/* wait for ACKUPD interrupt */
 	at91_rtc_write(AT91_RTC_IDR, AT91_RTC_ACKUPD);
-	at91_rtc_imr &= ~AT91_RTC_ACKUPD;
 
 	at91_rtc_write(AT91_RTC_TIMR,
 			  bin2bcd(tm->tm_sec) << 0
@@ -145,7 +142,7 @@ static int at91_rtc_readalarm(struct device *dev, struct rtc_wkalrm *alrm)
 	tm->tm_yday = rtc_year_days(tm->tm_mday, tm->tm_mon, tm->tm_year);
 	tm->tm_year = at91_alarm_year - 1900;
 
-	alrm->enabled = (at91_rtc_imr & AT91_RTC_ALARM)
+	alrm->enabled = (at91_rtc_read(AT91_RTC_IMR) & AT91_RTC_ALARM)
 			? 1 : 0;
 
 	dev_dbg(dev, "%s(): %4d-%02d-%02d %02d:%02d:%02d\n", __func__,
@@ -171,7 +168,6 @@ static int at91_rtc_setalarm(struct device *dev, struct rtc_wkalrm *alrm)
 	tm.tm_sec = alrm->time.tm_sec;
 
 	at91_rtc_write(AT91_RTC_IDR, AT91_RTC_ALARM);
-	at91_rtc_imr &= ~AT91_RTC_ALARM;
 	at91_rtc_write(AT91_RTC_TIMALR,
 		  bin2bcd(tm.tm_sec) << 0
 		| bin2bcd(tm.tm_min) << 8
@@ -184,7 +180,6 @@ static int at91_rtc_setalarm(struct device *dev, struct rtc_wkalrm *alrm)
 
 	if (alrm->enabled) {
 		at91_rtc_write(AT91_RTC_SCCR, AT91_RTC_ALARM);
-		at91_rtc_imr |= AT91_RTC_ALARM;
 		at91_rtc_write(AT91_RTC_IER, AT91_RTC_ALARM);
 	}
 
@@ -201,12 +196,9 @@ static int at91_rtc_alarm_irq_enable(struct device *dev, unsigned int enabled)
 
 	if (enabled) {
 		at91_rtc_write(AT91_RTC_SCCR, AT91_RTC_ALARM);
-		at91_rtc_imr |= AT91_RTC_ALARM;
 		at91_rtc_write(AT91_RTC_IER, AT91_RTC_ALARM);
-	} else {
+	} else
 		at91_rtc_write(AT91_RTC_IDR, AT91_RTC_ALARM);
-		at91_rtc_imr &= ~AT91_RTC_ALARM;
-	}
 
 	return 0;
 }
@@ -215,10 +207,12 @@ static int at91_rtc_alarm_irq_enable(struct device *dev, unsigned int enabled)
  */
 static int at91_rtc_proc(struct device *dev, struct seq_file *seq)
 {
+	unsigned long imr = at91_rtc_read(AT91_RTC_IMR);
+
 	seq_printf(seq, "update_IRQ\t: %s\n",
-			(at91_rtc_imr & AT91_RTC_ACKUPD) ? "yes" : "no");
+			(imr & AT91_RTC_ACKUPD) ? "yes" : "no");
 	seq_printf(seq, "periodic_IRQ\t: %s\n",
-			(at91_rtc_imr & AT91_RTC_SECEV) ? "yes" : "no");
+			(imr & AT91_RTC_SECEV) ? "yes" : "no");
 
 	return 0;
 }
@@ -233,7 +227,7 @@ static irqreturn_t at91_rtc_interrupt(int irq, void *dev_id)
 	unsigned int rtsr;
 	unsigned long events = 0;
 
-	rtsr = at91_rtc_read(AT91_RTC_SR) & at91_rtc_imr;
+	rtsr = at91_rtc_read(AT91_RTC_SR) & at91_rtc_read(AT91_RTC_IMR);
 	if (rtsr) {		/* this interrupt is shared!  Is it ours? */
 		if (rtsr & AT91_RTC_ALARM)
 			events |= (RTC_AF | RTC_IRQF);
@@ -297,7 +291,6 @@ static int __init at91_rtc_probe(struct platform_device *pdev)
 	at91_rtc_write(AT91_RTC_IDR, AT91_RTC_ACKUPD | AT91_RTC_ALARM |
 					AT91_RTC_SECEV | AT91_RTC_TIMEV |
 					AT91_RTC_CALEV);
-	at91_rtc_imr = 0;
 
 	ret = request_irq(irq, at91_rtc_interrupt,
 				IRQF_SHARED,
@@ -336,7 +329,6 @@ static int __exit at91_rtc_remove(struct platform_device *pdev)
 	at91_rtc_write(AT91_RTC_IDR, AT91_RTC_ACKUPD | AT91_RTC_ALARM |
 					AT91_RTC_SECEV | AT91_RTC_TIMEV |
 					AT91_RTC_CALEV);
-	at91_rtc_imr = 0;
 	free_irq(irq, pdev);
 
 	rtc_device_unregister(rtc);
@@ -349,35 +341,31 @@ static int __exit at91_rtc_remove(struct platform_device *pdev)
 
 /* AT91RM9200 RTC Power management control */
 
-static u32 at91_rtc_bkpimr;
-
+static u32 at91_rtc_imr;
 
 static int at91_rtc_suspend(struct device *dev)
 {
 	/* this IRQ is shared with DBGU and other hardware which isn't
 	 * necessarily doing PM like we are...
 	 */
-	at91_rtc_bkpimr = at91_rtc_imr & (AT91_RTC_ALARM|AT91_RTC_SECEV);
-	if (at91_rtc_bkpimr) {
-		if (device_may_wakeup(dev)) {
+	at91_rtc_imr = at91_rtc_read(AT91_RTC_IMR)
+			& (AT91_RTC_ALARM|AT91_RTC_SECEV);
+	if (at91_rtc_imr) {
+		if (device_may_wakeup(dev))
 			enable_irq_wake(irq);
-		} else {
-			at91_rtc_write(AT91_RTC_IDR, at91_rtc_bkpimr);
-			at91_rtc_imr &= ~at91_rtc_bkpimr;
-		}
-}
+		else
+			at91_rtc_write(AT91_RTC_IDR, at91_rtc_imr);
+	}
 	return 0;
 }
 
 static int at91_rtc_resume(struct device *dev)
 {
-	if (at91_rtc_bkpimr) {
-		if (device_may_wakeup(dev)) {
+	if (at91_rtc_imr) {
+		if (device_may_wakeup(dev))
 			disable_irq_wake(irq);
-		} else {
-			at91_rtc_imr |= at91_rtc_bkpimr;
-			at91_rtc_write(AT91_RTC_IER, at91_rtc_bkpimr);
-		}
+		else
+			at91_rtc_write(AT91_RTC_IER, at91_rtc_imr);
 	}
 	return 0;
 }
diff --git a/drivers/rtc/rtc-at91rm9200.h b/drivers/rtc/rtc-at91rm9200.h
index 5f940b6..da1945e 100644
--- a/drivers/rtc/rtc-at91rm9200.h
+++ b/drivers/rtc/rtc-at91rm9200.h
@@ -64,6 +64,7 @@
 #define	AT91_RTC_SCCR		0x1c			/* Status Clear Command Register */
 #define	AT91_RTC_IER		0x20			/* Interrupt Enable Register */
 #define	AT91_RTC_IDR		0x24			/* Interrupt Disable Register */
+#define	AT91_RTC_IMR		0x28			/* Interrupt Mask Register */
 
 #define	AT91_RTC_VER		0x2c			/* Valid Entry Register */
 #define		AT91_RTC_NVTIM		(1 <<  0)		/* Non valid Time */
-- 
1.8.1.5



From kpark3469 at gmail.com  Wed Apr  3 05:56:06 2013
From: kpark3469 at gmail.com (Keun-O Park)
Date: Wed, 3 Apr 2013 18:56:06 +0900
Subject: [PATCH] ARM: kprobes: fix test coverage missing failures
In-Reply-To: <1364980312.3561.7.camel@linaro1.home>
References: <1364871884-28252-1-git-send-email-kpark3469@gmail.com>
 <1364912353.3650.91.camel@linaro1.home>
 <CA+KhAHaguOmS+iq3URLg2WAROD37cGqni1NC8xbsucKYRf6Mrg@mail.gmail.com>
 <1364980312.3561.7.camel@linaro1.home>
Message-ID: <CA+KhAHYNw7bywrZUXvFsXG-4-xT7RfER4He-=+wNSyq3K4CQiQ@mail.gmail.com>

On Wed, Apr 3, 2013 at 6:11 PM, Jon Medhurst (Tixy) <tixy at linaro.org> wrote:
> On Wed, 2013-04-03 at 11:00 +0900, Keun-O Park wrote:
>> On Tue, Apr 2, 2013 at 11:19 PM, Jon Medhurst (Tixy) <tixy at linaro.org> wrote:
>> > On Tue, 2013-04-02 at 12:04 +0900, kpark3469 at gmail.com wrote:
>> >> From: Sahara <keun-o.park at windriver.com>
>> >>
>> >> If kprobe tests run on ARMv6k or ARMv6, there're a number of test
>> >> coverage missing failures like:
>> >
>> > The tests only fail (return an error code) for the coverage tests when
>> > compiled for ARMv7 because, obviously, that's the only architecture that
>> > can cover all the combinations of instructions. Perhaps we should just
>> > disabled the coverage tests pre-ARMv7 kernels to avoid the noisy output
>> > you see.
>> >
>> > I think the best way to look at it is that the coverage tests are test
>> > code for the test code, and should only be of concern to people updating
>> > the test code.
>> >
>> > If we go down the route that this patch follows of conditional
>> > compilation then we are making the main kernel code more messy in order
>> > to support test code and I'm not sure that is a good idea. It will be
>> > much worse should someone want to do the same for ARMv5.
>> >
>> > There is also the problem that once you #ifdef things for ARMv6 then you
>> > need an ARMv6 system to test that combination of data structures,
>> > whereas at the moment an ARMv7 board will cover everything.
>> >
>> > --
>> > Tixy
>>
>> Hi Jon,
>> I see. You're worried about the main kernel code being tainted by adding more
>> test code for test. To keep the clean decode table without #ifdef,
>> most modified codes in
>> arch/arm/kernel/kprobes-arm.c may be removed. architectures without
>> But, in order to keep consistency supporting 'nop', I think at least we still
>> need to add patches for 'nop' in arch/arm/kernel/kprobes-test.c and
>> kprobes-test.h.
>> It doesn't look good 'nop' is used by default like TEST_INSTRUCTION()
>> while TEST('nop') is
>> excluded in kprobe_arm_test_cases.
>
> I hate to sound overly awkward, but I'm not sure I agree with this
> either :-) When building for architectures without a proper NOP
> instructions the assembler will treat it as a pseudo-instruction
> equivalent to MOV R0,R0 in ARM code and MOV R8,R8 in Thumb code. So it
> doesn't seem worth adding an explicit macro to do this if the assembler
> already does it anyway.
>
> --
> Tixy
>

Ah.. I see. What I missed was whether the assembler treat nop as a
pseudo-instruction or not.
If so, it's ok with that. I agree with you.
Thanks.

-- Kpark


>
>


From marc.zyngier at arm.com  Wed Apr  3 06:00:39 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 03 Apr 2013 11:00:39 +0100
Subject: [PATCH 4/7] ARM: KVM: enforce page alignment for identity mapped
 code
In-Reply-To: <20130403095024.GC11040@mudshark.cambridge.arm.com>
References: <1364909115-3810-1-git-send-email-marc.zyngier@arm.com>
 <1364909115-3810-5-git-send-email-marc.zyngier@arm.com>
 <20130403095024.GC11040@mudshark.cambridge.arm.com>
Message-ID: <515BFDC7.9020401@arm.com>

On 03/04/13 10:50, Will Deacon wrote:
> On Tue, Apr 02, 2013 at 02:25:12PM +0100, Marc Zyngier wrote:
>> We're about to move to a init procedure where we rely on the
>> fact that the init code fits in a single page. Make sure we
>> align the idmap text on a page boundary, and that the code is
>> not bigger than a single page.
>>
>> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
>> ---
>>  arch/arm/kernel/vmlinux.lds.S | 2 +-
>>  arch/arm/kvm/init.S           | 7 +++++++
>>  2 files changed, 8 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
>> index b571484..d9dd265 100644
>> --- a/arch/arm/kernel/vmlinux.lds.S
>> +++ b/arch/arm/kernel/vmlinux.lds.S
>> @@ -20,7 +20,7 @@
>>  	VMLINUX_SYMBOL(__idmap_text_start) = .;				\
>>  	*(.idmap.text)							\
>>  	VMLINUX_SYMBOL(__idmap_text_end) = .;				\
>> -	ALIGN_FUNCTION();						\
>> +	. = ALIGN(PAGE_SIZE);						\
>>  	VMLINUX_SYMBOL(__hyp_idmap_text_start) = .;			\
>>  	*(.hyp.idmap.text)						\
>>  	VMLINUX_SYMBOL(__hyp_idmap_text_end) = .;
>> diff --git a/arch/arm/kvm/init.S b/arch/arm/kvm/init.S
>> index 9f37a79..35a463f 100644
>> --- a/arch/arm/kvm/init.S
>> +++ b/arch/arm/kvm/init.S
>> @@ -111,4 +111,11 @@ __do_hyp_init:
>>  	.globl __kvm_hyp_init_end
>>  __kvm_hyp_init_end:
>>  
>> +	/*
>> +	 * The above code *must* fit in a single page for the trampoline
>> +	 * madness to work. Whoever decides to change it must make sure
>> +	 * we map the right amount of memory for the trampoline to work.
>> +	 * The line below ensures any breakage will get noticed.
>> +	 */
>> +	.org	__kvm_hyp_init + PAGE_SIZE
>>  	.popsection
> 
> What effect does this have on the size of the kernel image? I'd expect the
> idmap code to be pretty small, so aligning to a page might be overkill a lot
> of the time.

So we're indeed wasting memory between the kernel and the HYP idmaps.
The reason for this is to ensure that the init code is not spread across
two pages, which would make the trampoline harder to allocate.

If there's a way to ensure that the init.S code will fit a single page,
then we can remove this ALIGN(PAGE_SIZE).

	M.
-- 
Jazz is not dead. It just smells funny...



From arnd at arndb.de  Wed Apr  3 06:02:41 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed, 3 Apr 2013 10:02:41 +0000
Subject: [GIT PULL] at91: soc for 3.10 #2
In-Reply-To: <515BD8C8.5060701@atmel.com>
References: <5152B357.3020500@atmel.com>
 <CAOesGMiy7q-xbc0SN78d7cvZmLgywy1PH7_Srw_=pzErSkrt-g@mail.gmail.com>
 <515BD8C8.5060701@atmel.com>
Message-ID: <201304031002.41770.arnd@arndb.de>

On Wednesday 03 April 2013, Nicolas Ferre wrote:
> > Also, USE_OF isn't set at that point (it's controlled by the next
> > section), so it can't be used as a replacement.
> > 
> > Also, isn't it a bit backwards in the first place to first set ATAGS
> > vs no-ATAGS, and then get to choose what hardware you want to build
> > for?
> 
> True, I was thinking it was a common pattern.

It's not common yet, but I want to get to the point where we can
globally disable ATAGS support for multiplatform kernels and get
only DT-enabled ones. There is no easy rule for when to select
or depend on a global feature, but there are a number of cases where
I think 'depends on' makes more sense in the long run.

Another example is CPU architecture level. Traditionally every
board selects CPU_v6 or CPU_v7, but in ARCH_MULTIPLATFORM, I created
a filter that lets you enable only one of them, and then pick all
the platforms that have the respective CPU, which is much easier
than having to know which platforms might be ARMv6 if you want to
build e.g. a kernel with THUMB2 support but as many boards enabled
as possible.

	Arnd


From will.deacon at arm.com  Wed Apr  3 06:07:51 2013
From: will.deacon at arm.com (Will Deacon)
Date: Wed, 3 Apr 2013 11:07:51 +0100
Subject: [PATCH 6/7] ARM: KVM: switch to a dual-step HYP init code
In-Reply-To: <1364909115-3810-7-git-send-email-marc.zyngier@arm.com>
References: <1364909115-3810-1-git-send-email-marc.zyngier@arm.com>
 <1364909115-3810-7-git-send-email-marc.zyngier@arm.com>
Message-ID: <20130403100751.GD11040@mudshark.cambridge.arm.com>

On Tue, Apr 02, 2013 at 02:25:14PM +0100, Marc Zyngier wrote:
> Our HYP init code suffers from two major design issues:
> - it cannot support CPU hotplug, as we tear down the idmap very early
> - it cannot perform a TLB invalidation when switching from init to
>   runtime mappings, as pages are manipulated from PL1 exclusively

[...]

> diff --git a/arch/arm/kvm/init.S b/arch/arm/kvm/init.S
> index 35a463f..b2c6967 100644
> --- a/arch/arm/kvm/init.S
> +++ b/arch/arm/kvm/init.S
> @@ -21,6 +21,7 @@
>  #include <asm/asm-offsets.h>
>  #include <asm/kvm_asm.h>
>  #include <asm/kvm_arm.h>
> +#include <asm/kvm_mmu.h>
>  
>  /********************************************************************
>   * Hypervisor initialization
> @@ -47,6 +48,9 @@ __kvm_hyp_init:
>  	W(b)	.
>  
>  __do_hyp_init:
> +	cmp	r2, #0			@ We have a SP?
> +	bne	phase2			@ Yes, second stage init
> +
>  	@ Set the HTTBR to point to the hypervisor PGD pointer passed
>  	mcrr	p15, 4, r0, r1, c2
>  
> @@ -96,14 +100,35 @@ __do_hyp_init:
>  	orr	r0, r0, r1
>  	isb
>  	mcr	p15, 4, r0, c1, c0, 0	@ HSCR
> -	isb
>  
> -	@ Set stack pointer and return to the kernel
> +	eret
> +
> +phase2:
> +	@ Set stack pointer
>  	mov	sp, r2
>  
>  	@ Set HVBAR to point to the HYP vectors
>  	mcr	p15, 4, r3, c12, c0, 0	@ HVBAR
>  
> +	@ Jump to the trampoline page
> +	ldr	r2, =#PAGE_MASK

Shifting right by PAGE_SHIFT can avoid the load.

> +	adr	r3, target
> +	bic	r3, r3, r2
> +	ldr	r2, =#TRAMPOLINE_VA
> +	add	r3, r3, r2
> +	mov	pc, r3
> +
> +	nop

<insert dead chicken and voodoo chant here>

> +
> +target:	@ We're now in the trampoline code, switch page tables
> +	mcrr	p15, 4, r0, r1, c2
> +	isb
> +
> +	@ Invalidate the old TLBs
> +	mcr	p15, 4, r0, c8, c7, 0	@ TLBIALLH
> +	dsb
> +	isb

You don't actually need this isb (there's an eret next!).

>  	eret
>  
>  	.ltorg

Will


From linux at arm.linux.org.uk  Wed Apr  3 06:06:38 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Wed, 3 Apr 2013 11:06:38 +0100
Subject: [PATCH V2 1/3] clk: ux500: Add support for sysctrl clocks
In-Reply-To: <1364982412-9853-1-git-send-email-ulf.hansson@stericsson.com>
References: <1364982412-9853-1-git-send-email-ulf.hansson@stericsson.com>
Message-ID: <20130403100638.GD17995@n2100.arm.linux.org.uk>

On Wed, Apr 03, 2013 at 11:46:52AM +0200, Ulf Hansson wrote:
> +	clk_reg = devm_clk_register(clk->dev, &clk->hw);
> +	if (IS_ERR_OR_NULL(clk_reg)) {

Please go and read the devm_clk_register() code and work out whether
your check above is appropriate.  Thanks.


From will.deacon at arm.com  Wed Apr  3 06:10:18 2013
From: will.deacon at arm.com (Will Deacon)
Date: Wed, 3 Apr 2013 11:10:18 +0100
Subject: [Suggestion] ARM:S5pv210: compiling issue for s5pv210 by using
 randconfig
In-Reply-To: <515BFA8D.2000204@asianux.com>
References: <514FB202.3040807@asianux.com>
 <515BFA8D.2000204@asianux.com>
Message-ID: <20130403101018.GE11040@mudshark.cambridge.arm.com>

On Wed, Apr 03, 2013 at 10:46:53AM +0100, Chen Gang wrote:
> Hello Maintainers:
> 
>   when you have time, could you help to check this suggestion ?

[...]

> > 
> >   make:
> >     make V=1 EXTRA_CFLAGS=-W ARCH=arm randconfig
> >     make V=1 EXTRA_CFLAGS=-W ARCH=arm menuconfig
> >       set arm-linux-gnu-  for "Cross-compiler tool prefix"
> >       set "Samsung S5PV210/S5PC210" for "ARM system type"
> >     make V=1 EXTRA_CFLAGS=-W ARCH=arm

I think the main problem is that you've reported an issue created from a
randconfig, but you haven't made the config in question available.

Will


From nicolas.ferre at atmel.com  Wed Apr  3 06:18:48 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Wed, 3 Apr 2013 12:18:48 +0200
Subject: [PATCH] Revert "drivers/rtc/rtc-at91rm9200.c: use a variable
 for storing IMR"
In-Reply-To: <1364982862-19759-1-git-send-email-jhovold@gmail.com>
References: <20130403095150.GC27600@localhost>
 <1364982862-19759-1-git-send-email-jhovold@gmail.com>
Message-ID: <515C0208.2000605@atmel.com>

On 04/03/2013 11:54 AM, Johan Hovold :
> This reverts commit 0ef1594c017521ea89278e80fe3f80dafb17abde.
> 
> This patch introduced a few races which cannot be easily fixed with a
> small follow-up patch. Furthermore, the SoC with the broken hardware
> register, which this patch intended to add support for, can only be used
> with device trees, which this driver currently does not support.
> 
> Cc: stable <stable at vger.kernel.org>
> Signed-off-by: Johan Hovold <jhovold at gmail.com>

Fair enough, after fighting to find a solution that can makes us move
forward... your strong arguments convinced me.

So, Andrew, please can you take this "revert" patch for 3.9-rc ?
And sorry for the noise.

Acked-by: Nicolas Ferre <nicolas.ferre at atmel.com>

(Andrew, I figured out that you are not in copy of the original email:
do I need to send it back to you or can you pick it up in patchwork?
https://patchwork.kernel.org/patch/2385921/
)

> ---
>  drivers/rtc/rtc-at91rm9200.c | 50 +++++++++++++++++---------------------------
>  drivers/rtc/rtc-at91rm9200.h |  1 +
>  2 files changed, 20 insertions(+), 31 deletions(-)
> 
> diff --git a/drivers/rtc/rtc-at91rm9200.c b/drivers/rtc/rtc-at91rm9200.c
> index 0a9f27e..434ebc3 100644
> --- a/drivers/rtc/rtc-at91rm9200.c
> +++ b/drivers/rtc/rtc-at91rm9200.c
> @@ -44,7 +44,6 @@ static DECLARE_COMPLETION(at91_rtc_updated);
>  static unsigned int at91_alarm_year = AT91_RTC_EPOCH;
>  static void __iomem *at91_rtc_regs;
>  static int irq;
> -static u32 at91_rtc_imr;
>  
>  /*
>   * Decode time/date into rtc_time structure
> @@ -109,11 +108,9 @@ static int at91_rtc_settime(struct device *dev, struct rtc_time *tm)
>  	cr = at91_rtc_read(AT91_RTC_CR);
>  	at91_rtc_write(AT91_RTC_CR, cr | AT91_RTC_UPDCAL | AT91_RTC_UPDTIM);
>  
> -	at91_rtc_imr |= AT91_RTC_ACKUPD;
>  	at91_rtc_write(AT91_RTC_IER, AT91_RTC_ACKUPD);
>  	wait_for_completion(&at91_rtc_updated);	/* wait for ACKUPD interrupt */
>  	at91_rtc_write(AT91_RTC_IDR, AT91_RTC_ACKUPD);
> -	at91_rtc_imr &= ~AT91_RTC_ACKUPD;
>  
>  	at91_rtc_write(AT91_RTC_TIMR,
>  			  bin2bcd(tm->tm_sec) << 0
> @@ -145,7 +142,7 @@ static int at91_rtc_readalarm(struct device *dev, struct rtc_wkalrm *alrm)
>  	tm->tm_yday = rtc_year_days(tm->tm_mday, tm->tm_mon, tm->tm_year);
>  	tm->tm_year = at91_alarm_year - 1900;
>  
> -	alrm->enabled = (at91_rtc_imr & AT91_RTC_ALARM)
> +	alrm->enabled = (at91_rtc_read(AT91_RTC_IMR) & AT91_RTC_ALARM)
>  			? 1 : 0;
>  
>  	dev_dbg(dev, "%s(): %4d-%02d-%02d %02d:%02d:%02d\n", __func__,
> @@ -171,7 +168,6 @@ static int at91_rtc_setalarm(struct device *dev, struct rtc_wkalrm *alrm)
>  	tm.tm_sec = alrm->time.tm_sec;
>  
>  	at91_rtc_write(AT91_RTC_IDR, AT91_RTC_ALARM);
> -	at91_rtc_imr &= ~AT91_RTC_ALARM;
>  	at91_rtc_write(AT91_RTC_TIMALR,
>  		  bin2bcd(tm.tm_sec) << 0
>  		| bin2bcd(tm.tm_min) << 8
> @@ -184,7 +180,6 @@ static int at91_rtc_setalarm(struct device *dev, struct rtc_wkalrm *alrm)
>  
>  	if (alrm->enabled) {
>  		at91_rtc_write(AT91_RTC_SCCR, AT91_RTC_ALARM);
> -		at91_rtc_imr |= AT91_RTC_ALARM;
>  		at91_rtc_write(AT91_RTC_IER, AT91_RTC_ALARM);
>  	}
>  
> @@ -201,12 +196,9 @@ static int at91_rtc_alarm_irq_enable(struct device *dev, unsigned int enabled)
>  
>  	if (enabled) {
>  		at91_rtc_write(AT91_RTC_SCCR, AT91_RTC_ALARM);
> -		at91_rtc_imr |= AT91_RTC_ALARM;
>  		at91_rtc_write(AT91_RTC_IER, AT91_RTC_ALARM);
> -	} else {
> +	} else
>  		at91_rtc_write(AT91_RTC_IDR, AT91_RTC_ALARM);
> -		at91_rtc_imr &= ~AT91_RTC_ALARM;
> -	}
>  
>  	return 0;
>  }
> @@ -215,10 +207,12 @@ static int at91_rtc_alarm_irq_enable(struct device *dev, unsigned int enabled)
>   */
>  static int at91_rtc_proc(struct device *dev, struct seq_file *seq)
>  {
> +	unsigned long imr = at91_rtc_read(AT91_RTC_IMR);
> +
>  	seq_printf(seq, "update_IRQ\t: %s\n",
> -			(at91_rtc_imr & AT91_RTC_ACKUPD) ? "yes" : "no");
> +			(imr & AT91_RTC_ACKUPD) ? "yes" : "no");
>  	seq_printf(seq, "periodic_IRQ\t: %s\n",
> -			(at91_rtc_imr & AT91_RTC_SECEV) ? "yes" : "no");
> +			(imr & AT91_RTC_SECEV) ? "yes" : "no");
>  
>  	return 0;
>  }
> @@ -233,7 +227,7 @@ static irqreturn_t at91_rtc_interrupt(int irq, void *dev_id)
>  	unsigned int rtsr;
>  	unsigned long events = 0;
>  
> -	rtsr = at91_rtc_read(AT91_RTC_SR) & at91_rtc_imr;
> +	rtsr = at91_rtc_read(AT91_RTC_SR) & at91_rtc_read(AT91_RTC_IMR);
>  	if (rtsr) {		/* this interrupt is shared!  Is it ours? */
>  		if (rtsr & AT91_RTC_ALARM)
>  			events |= (RTC_AF | RTC_IRQF);
> @@ -297,7 +291,6 @@ static int __init at91_rtc_probe(struct platform_device *pdev)
>  	at91_rtc_write(AT91_RTC_IDR, AT91_RTC_ACKUPD | AT91_RTC_ALARM |
>  					AT91_RTC_SECEV | AT91_RTC_TIMEV |
>  					AT91_RTC_CALEV);
> -	at91_rtc_imr = 0;
>  
>  	ret = request_irq(irq, at91_rtc_interrupt,
>  				IRQF_SHARED,
> @@ -336,7 +329,6 @@ static int __exit at91_rtc_remove(struct platform_device *pdev)
>  	at91_rtc_write(AT91_RTC_IDR, AT91_RTC_ACKUPD | AT91_RTC_ALARM |
>  					AT91_RTC_SECEV | AT91_RTC_TIMEV |
>  					AT91_RTC_CALEV);
> -	at91_rtc_imr = 0;
>  	free_irq(irq, pdev);
>  
>  	rtc_device_unregister(rtc);
> @@ -349,35 +341,31 @@ static int __exit at91_rtc_remove(struct platform_device *pdev)
>  
>  /* AT91RM9200 RTC Power management control */
>  
> -static u32 at91_rtc_bkpimr;
> -
> +static u32 at91_rtc_imr;
>  
>  static int at91_rtc_suspend(struct device *dev)
>  {
>  	/* this IRQ is shared with DBGU and other hardware which isn't
>  	 * necessarily doing PM like we are...
>  	 */
> -	at91_rtc_bkpimr = at91_rtc_imr & (AT91_RTC_ALARM|AT91_RTC_SECEV);
> -	if (at91_rtc_bkpimr) {
> -		if (device_may_wakeup(dev)) {
> +	at91_rtc_imr = at91_rtc_read(AT91_RTC_IMR)
> +			& (AT91_RTC_ALARM|AT91_RTC_SECEV);
> +	if (at91_rtc_imr) {
> +		if (device_may_wakeup(dev))
>  			enable_irq_wake(irq);
> -		} else {
> -			at91_rtc_write(AT91_RTC_IDR, at91_rtc_bkpimr);
> -			at91_rtc_imr &= ~at91_rtc_bkpimr;
> -		}
> -}
> +		else
> +			at91_rtc_write(AT91_RTC_IDR, at91_rtc_imr);
> +	}
>  	return 0;
>  }
>  
>  static int at91_rtc_resume(struct device *dev)
>  {
> -	if (at91_rtc_bkpimr) {
> -		if (device_may_wakeup(dev)) {
> +	if (at91_rtc_imr) {
> +		if (device_may_wakeup(dev))
>  			disable_irq_wake(irq);
> -		} else {
> -			at91_rtc_imr |= at91_rtc_bkpimr;
> -			at91_rtc_write(AT91_RTC_IER, at91_rtc_bkpimr);
> -		}
> +		else
> +			at91_rtc_write(AT91_RTC_IER, at91_rtc_imr);
>  	}
>  	return 0;
>  }
> diff --git a/drivers/rtc/rtc-at91rm9200.h b/drivers/rtc/rtc-at91rm9200.h
> index 5f940b6..da1945e 100644
> --- a/drivers/rtc/rtc-at91rm9200.h
> +++ b/drivers/rtc/rtc-at91rm9200.h
> @@ -64,6 +64,7 @@
>  #define	AT91_RTC_SCCR		0x1c			/* Status Clear Command Register */
>  #define	AT91_RTC_IER		0x20			/* Interrupt Enable Register */
>  #define	AT91_RTC_IDR		0x24			/* Interrupt Disable Register */
> +#define	AT91_RTC_IMR		0x28			/* Interrupt Mask Register */
>  
>  #define	AT91_RTC_VER		0x2c			/* Valid Entry Register */
>  #define		AT91_RTC_NVTIM		(1 <<  0)		/* Non valid Time */
> 


-- 
Nicolas Ferre


From richard.genoud at gmail.com  Wed Apr  3 06:23:35 2013
From: richard.genoud at gmail.com (Richard GENOUD)
Date: Wed, 3 Apr 2013 12:23:35 +0200
Subject: [PATCH v8 3/8] spi/spi-atmel: add dmaengine support
In-Reply-To: <1364968759-24036-1-git-send-email-wenyou.yang@atmel.com>
References: <1364968581-23700-1-git-send-email-wenyou.yang@atmel.com>
 <1364968759-24036-1-git-send-email-wenyou.yang@atmel.com>
Message-ID: <20130403102332.GA4633@lnx-rg>

On [mer., 03.04.2013 13:59:19], Wenyou Yang wrote:
> From: Nicolas Ferre <nicolas.ferre at atmel.com>
> 
> Add dmaengine support.
> 
> Using "has_dma_support" member of struct is used to select
> the transfer mode: dmaengine or pdc.
> 
> For the dmaengine transfer mode, it supports both 8 bits and 16 bits transfer.
> 
> For the dmaengine transfer mode, if it fails to config dmaengine,
> or if the message length is less than 16 bytes, it will use the PIO transfer mode.
> 
> Signed-off-by: Nicolas Ferre <nicolas.ferre at atmel.com>
> [wenyou.yang at atmel.com: using "has_dma_support" to select dmaengine as the spi xfer mode]
> [wenyou.yang at atmel.com: fix DMA: OOPS if buffer > 4096 bytes]
> [wenyou.yang at atmel.com: submit the patch]
> Signed-off-by: Wenyou Yang <wenyou.yang at atmel.com>
> Cc: richard.genoud at gmail.com
> Cc: spi-devel-general at lists.sourceforge.ne
> Cc: linux-kernel at vger.kernel.org
> [richard.genoud at gmail.com: update with dmaengine interface]
> [richard.genoud at gmail.com: fix __init/__devinit sections mismatch]
> [richard.genoud at gmail.com: adapt to slave_config changes]
> [richard.genoud at gmail.com: add support t0 16 bits transfer]
> ---
> This patch is based on the original patch from Nicolas
> 	- add dmaengine support
> and squash the below patches from Richard Genoud <richard.genoud at gmail.com>
> 	- update with dmaengine interface
> 	- fix __init/__devinit sections mismatch
> 	- fix spi-atmel driver to adapt to slave_config changes
> 	- correct 16 bits transfers with DMA
> 
> Hi, Richard,
> 
> Could you sign your signature in this patch?
> 
> Best Regards,
> Wenyou Yang
> 
>  drivers/spi/spi-atmel.c |  587 +++++++++++++++++++++++++++++++++++++++++++++--
>  1 file changed, 566 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
> index 2df562f..759d83a 100644
> --- a/drivers/spi/spi-atmel.c
> +++ b/drivers/spi/spi-atmel.c
> @@ -15,11 +15,13 @@
>  #include <linux/platform_device.h>
>  #include <linux/delay.h>
>  #include <linux/dma-mapping.h>
> +#include <linux/dmaengine.h>
>  #include <linux/err.h>
>  #include <linux/interrupt.h>
>  #include <linux/spi/spi.h>
>  #include <linux/slab.h>
>  #include <linux/platform_data/atmel.h>
> +#include <linux/platform_data/dma-atmel.h>
>  #include <linux/of.h>
>  
>  #include <linux/io.h>
> @@ -182,6 +184,22 @@
>  #define spi_writel(port,reg,value) \
>  	__raw_writel((value), (port)->regs + SPI_##reg)
>  
> +/* use PIO for small transfers, avoiding DMA setup/teardown overhead and
> + * cache operations; better heuristics consider wordsize and bitrate.
> + */
> +#define DMA_MIN_BYTES	16
> +
> +struct atmel_spi_dma {
> +	struct dma_chan			*chan_rx;
> +	struct dma_chan			*chan_tx;
> +	struct scatterlist		sgrx;
> +	struct scatterlist		sgtx;
> +	struct dma_async_tx_descriptor	*data_desc_rx;
> +	struct dma_async_tx_descriptor	*data_desc_tx;
> +
> +	struct at_dma_slave	dma_slave;
> +};
> +
>  struct atmel_spi_caps {
>  	bool	is_spi2;
>  	bool	has_wdrbt;
> @@ -206,16 +224,23 @@ struct atmel_spi {
>  
>  	u8			stopping;
>  	struct list_head	queue;
> +	struct tasklet_struct	tasklet;
>  	struct spi_transfer	*current_transfer;
>  	unsigned long		current_remaining_bytes;
>  	struct spi_transfer	*next_transfer;
>  	unsigned long		next_remaining_bytes;
>  	int			done_status;
>  
> +	/* scratch buffer */
>  	void			*buffer;
>  	dma_addr_t		buffer_dma;
>  
>  	struct atmel_spi_caps	caps;
> +
> +	bool			use_dma;
> +	bool			use_pdc;
> +	/* dmaengine data */
> +	struct atmel_spi_dma	dma;
>  };
>  
>  /* Controller-specific per-slave state */
> @@ -284,6 +309,7 @@ static void cs_activate(struct atmel_spi *as, struct spi_device *spi)
>  					| SPI_BIT(MODFDIS)
>  					| SPI_BIT(MSTR));
>  		}
> +
>  		mr = spi_readl(as, MR);
>  		gpio_set_value(asd->npcs_pin, active);
>  	} else {
> @@ -344,6 +370,12 @@ static void atmel_spi_unlock(struct atmel_spi *as)
>  	spin_unlock_irqrestore(&as->lock, as->flags);
>  }
>  
> +static inline bool atmel_spi_use_dma(struct atmel_spi *as,
> +				struct spi_transfer *xfer)
> +{
> +	return as->use_dma && xfer->len >= DMA_MIN_BYTES;
> +}
> +
>  static inline int atmel_spi_xfer_is_last(struct spi_message *msg,
>  					struct spi_transfer *xfer)
>  {
> @@ -355,6 +387,265 @@ static inline int atmel_spi_xfer_can_be_chained(struct spi_transfer *xfer)
>  	return xfer->delay_usecs == 0 && !xfer->cs_change;
>  }
>  
> +static int atmel_spi_dma_slave_config(struct atmel_spi *as,
> +				struct dma_slave_config *slave_config,
> +				u8 bits_per_word)
> +{
> +	int err = 0;
> +
> +	if (bits_per_word > 8) {
> +		slave_config->dst_addr_width = DMA_SLAVE_BUSWIDTH_2_BYTES;
> +		slave_config->src_addr_width = DMA_SLAVE_BUSWIDTH_2_BYTES;
> +	} else {
> +		slave_config->dst_addr_width = DMA_SLAVE_BUSWIDTH_1_BYTE;
> +		slave_config->src_addr_width = DMA_SLAVE_BUSWIDTH_1_BYTE;
> +	}
> +
> +	slave_config->dst_addr = (dma_addr_t)as->phybase + SPI_TDR;
> +	slave_config->src_addr = (dma_addr_t)as->phybase + SPI_RDR;
> +	slave_config->src_maxburst = 1;
> +	slave_config->dst_maxburst = 1;
> +	slave_config->device_fc = false;
> +
> +	slave_config->direction = DMA_MEM_TO_DEV;
> +	if (dmaengine_slave_config(as->dma.chan_tx, slave_config)) {
> +		dev_err(&as->pdev->dev,
> +			"failed to configure tx dma channel\n");
> +		err = -EINVAL;
> +	}
> +
> +	slave_config->direction = DMA_DEV_TO_MEM;
> +	if (dmaengine_slave_config(as->dma.chan_rx, slave_config)) {
> +		dev_err(&as->pdev->dev,
> +			"failed to configure rx dma channel\n");
> +		err = -EINVAL;
> +	}
> +
> +	return err;
> +}
> +
> +static bool filter(struct dma_chan *chan, void *slave)
> +{
> +	struct	at_dma_slave *sl = slave;
> +
> +	if (sl->dma_dev == chan->device->dev) {
> +		chan->private = sl;
> +		return true;
> +	} else {
> +		return false;
> +	}
> +}
> +
> +static int atmel_spi_configure_dma(struct atmel_spi *as)
> +{
> +	struct at_dma_slave *sdata = &as->dma.dma_slave;
> +	struct dma_slave_config	slave_config;
> +	int err;
> +
> +	if (sdata && sdata->dma_dev) {
> +		dma_cap_mask_t mask;
> +
> +		/* Try to grab two DMA channels */
> +		dma_cap_zero(mask);
> +		dma_cap_set(DMA_SLAVE, mask);
> +		as->dma.chan_tx = dma_request_channel(mask, filter, sdata);
> +		if (as->dma.chan_tx)
> +			as->dma.chan_rx =
> +				dma_request_channel(mask, filter, sdata);
> +	}
> +	if (!as->dma.chan_rx || !as->dma.chan_tx) {
> +		dev_err(&as->pdev->dev,
> +			"DMA channel not available, SPI unable to use DMA\n");
> +		err = -EBUSY;
> +		goto error;
> +	}
> +
> +	err = atmel_spi_dma_slave_config(as, &slave_config, 8);
> +	if (err)
> +		goto error;
> +
> +	dev_info(&as->pdev->dev,
> +			"Using %s (tx) and %s (rx) for DMA transfers\n",
> +			dma_chan_name(as->dma.chan_tx),
> +			dma_chan_name(as->dma.chan_rx));
> +	return 0;
> +error:
> +	if (as->dma.chan_rx)
> +		dma_release_channel(as->dma.chan_rx);
> +	if (as->dma.chan_tx)
> +		dma_release_channel(as->dma.chan_tx);
> +	return err;
> +}
> +
> +static void atmel_spi_stop_dma(struct atmel_spi *as)
> +{
> +	if (as->dma.chan_rx)
> +		as->dma.chan_rx->device->device_control(as->dma.chan_rx,
> +							DMA_TERMINATE_ALL, 0);
> +	if (as->dma.chan_tx)
> +		as->dma.chan_tx->device->device_control(as->dma.chan_tx,
> +							DMA_TERMINATE_ALL, 0);
> +}
> +
> +static void atmel_spi_release_dma(struct atmel_spi *as)
> +{
> +	if (as->dma.chan_rx)
> +		dma_release_channel(as->dma.chan_rx);
> +	if (as->dma.chan_tx)
> +		dma_release_channel(as->dma.chan_tx);
> +}
> +
> +/* This function is called by the DMA driver from tasklet context */
> +static void dma_callback(void *data)
> +{
> +	struct spi_master	*master = data;
> +	struct atmel_spi	*as = spi_master_get_devdata(master);
> +
> +	/* trigger SPI tasklet */
> +	tasklet_schedule(&as->tasklet);
> +}
> +
> +/*
> + * Next transfer using PIO.
> + * lock is held, spi tasklet is blocked
> + */
> +static void atmel_spi_next_xfer_pio(struct spi_master *master,
> +				struct spi_transfer *xfer)
> +{
> +	struct atmel_spi	*as = spi_master_get_devdata(master);
> +
> +	dev_vdbg(master->dev.parent, "atmel_spi_next_xfer_pio\n");
> +
> +	as->current_remaining_bytes = xfer->len;
> +
> +	/* Make sure data is not remaining in RDR */
> +	spi_readl(as, RDR);
> +	while (spi_readl(as, SR) & SPI_BIT(RDRF)) {
> +		spi_readl(as, RDR);
> +		cpu_relax();
> +	}
> +
> +	if (xfer->tx_buf)
> +		spi_writel(as, TDR, *(u8 *)(xfer->tx_buf));
> +	else
> +		spi_writel(as, TDR, 0);
> +
> +	dev_dbg(master->dev.parent,
> +		"  start pio xfer %p: len %u tx %p rx %p\n",
> +		xfer, xfer->len, xfer->tx_buf, xfer->rx_buf);
> +
> +	/* Enable relevant interrupts */
> +	spi_writel(as, IER, SPI_BIT(RDRF) | SPI_BIT(OVRES));
> +}
> +
> +/*
> + * Submit next transfer for DMA.
> + * lock is held, spi tasklet is blocked
> + */
> +static int atmel_spi_next_xfer_dma_submit(struct spi_master *master,
> +				struct spi_transfer *xfer,
> +				u32 *plen)
> +{
> +	struct atmel_spi	*as = spi_master_get_devdata(master);
> +	struct dma_chan		*rxchan = as->dma.chan_rx;
> +	struct dma_chan		*txchan = as->dma.chan_tx;
> +	struct dma_async_tx_descriptor *rxdesc;
> +	struct dma_async_tx_descriptor *txdesc;
> +	struct dma_slave_config	slave_config;
> +	dma_cookie_t		cookie;
> +	u32	len = *plen;
> +
> +	dev_vdbg(master->dev.parent, "atmel_spi_next_xfer_dma_submit\n");
> +
> +	/* Check that the channels are available */
> +	if (!rxchan || !txchan)
> +		return -ENODEV;
> +
> +	/* release lock for DMA operations */
> +	atmel_spi_unlock(as);
> +
> +	/* prepare the RX dma transfer */
> +	sg_init_table(&as->dma.sgrx, 1);
> +	if (xfer->rx_buf) {
> +		as->dma.sgrx.dma_address = xfer->rx_dma + xfer->len - *plen;
> +	} else {
> +		as->dma.sgrx.dma_address = as->buffer_dma;
> +		if (len > BUFFER_SIZE)
> +			len = BUFFER_SIZE;
> +	}
> +
> +	/* prepare the TX dma transfer */
> +	sg_init_table(&as->dma.sgtx, 1);
> +	if (xfer->tx_buf) {
> +		as->dma.sgtx.dma_address = xfer->tx_dma + xfer->len - *plen;
> +	} else {
> +		as->dma.sgtx.dma_address = as->buffer_dma;
> +		if (len > BUFFER_SIZE)
> +			len = BUFFER_SIZE;
> +		memset(as->buffer, 0, len);
> +	}
> +
> +	sg_dma_len(&as->dma.sgtx) = len;
> +	sg_dma_len(&as->dma.sgrx) = len;
> +
> +	*plen = len;
> +
> +	if (atmel_spi_dma_slave_config(as, &slave_config, 8))
> +		goto err_exit;
> +
> +	/* Send both scatterlists */
> +	rxdesc = rxchan->device->device_prep_slave_sg(rxchan,
> +					&as->dma.sgrx,
> +					1,
> +					DMA_FROM_DEVICE,
> +					DMA_PREP_INTERRUPT | DMA_CTRL_ACK,
> +					NULL);
> +	if (!rxdesc)
> +		goto err_dma;
> +
> +	txdesc = txchan->device->device_prep_slave_sg(txchan,
> +					&as->dma.sgtx,
> +					1,
> +					DMA_TO_DEVICE,
> +					DMA_PREP_INTERRUPT | DMA_CTRL_ACK,
> +					NULL);
> +	if (!txdesc)
> +		goto err_dma;
> +
> +	dev_dbg(master->dev.parent,
> +		"  start dma xfer %p: len %u tx %p/%08x rx %p/%08x\n",
> +		xfer, xfer->len, xfer->tx_buf, xfer->tx_dma,
> +		xfer->rx_buf, xfer->rx_dma);
> +
> +	/* Enable relevant interrupts */
> +	spi_writel(as, IER, SPI_BIT(OVRES));
> +
> +	/* Put the callback on the RX transfer only, that should finish last */
> +	rxdesc->callback = dma_callback;
> +	rxdesc->callback_param = master;
> +
> +	/* Submit and fire RX and TX with TX last so we're ready to read! */
> +	cookie = rxdesc->tx_submit(rxdesc);
> +	if (dma_submit_error(cookie))
> +		goto err_dma;
> +	cookie = txdesc->tx_submit(txdesc);
> +	if (dma_submit_error(cookie))
> +		goto err_dma;
> +	rxchan->device->device_issue_pending(rxchan);
> +	txchan->device->device_issue_pending(txchan);
> +
> +	/* take back lock */
> +	atmel_spi_lock(as);
> +	return 0;
> +
> +err_dma:
> +	spi_writel(as, IDR, SPI_BIT(OVRES));
> +	atmel_spi_stop_dma(as);
> +err_exit:
> +	atmel_spi_lock(as);
> +	return -ENOMEM;
> +}
> +
>  static void atmel_spi_next_xfer_data(struct spi_master *master,
>  				struct spi_transfer *xfer,
>  				dma_addr_t *tx_dma,
> @@ -372,6 +663,7 @@ static void atmel_spi_next_xfer_data(struct spi_master *master,
>  		if (len > BUFFER_SIZE)
>  			len = BUFFER_SIZE;
>  	}
> +
>  	if (xfer->tx_buf)
>  		*tx_dma = xfer->tx_dma + xfer->len - *plen;
>  	else {
> @@ -387,10 +679,10 @@ static void atmel_spi_next_xfer_data(struct spi_master *master,
>  }
>  
>  /*
> - * Submit next transfer for DMA.
> + * Submit next transfer for PDC.
>   * lock is held, spi irq is blocked
>   */
> -static void atmel_spi_next_xfer(struct spi_master *master,
> +static void atmel_spi_pdc_next_xfer(struct spi_master *master,
>  				struct spi_message *msg)
>  {
>  	struct atmel_spi	*as = spi_master_get_devdata(master);
> @@ -487,6 +779,48 @@ static void atmel_spi_next_xfer(struct spi_master *master,
>  	spi_writel(as, PTCR, SPI_BIT(TXTEN) | SPI_BIT(RXTEN));
>  }
>  
> +/*
> + * Choose way to submit next transfer and start it.
> + * lock is held, spi tasklet is blocked
> + */
> +static void atmel_spi_dma_next_xfer(struct spi_master *master,
> +				struct spi_message *msg)
> +{
> +	struct atmel_spi	*as = spi_master_get_devdata(master);
> +	struct spi_transfer	*xfer;
> +	u32	remaining, len;
> +
> +	remaining = as->current_remaining_bytes;
> +	if (remaining) {
> +		xfer = as->current_transfer;
> +		len = remaining;
> +	} else {
> +		if (!as->current_transfer)
> +			xfer = list_entry(msg->transfers.next,
> +				struct spi_transfer, transfer_list);
> +		else
> +			xfer = list_entry(
> +				as->current_transfer->transfer_list.next,
> +					struct spi_transfer, transfer_list);
> +
> +		as->current_transfer = xfer;
> +		len = xfer->len;
> +	}
> +
> +	if (atmel_spi_use_dma(as, xfer)) {
> +		u32 total = len;
> +		if (!atmel_spi_next_xfer_dma_submit(master, xfer, &len)) {
> +			as->current_remaining_bytes = total - len;
> +			return;
> +		} else {
> +			dev_err(&msg->spi->dev, "unable to use DMA, fallback to PIO\n");
> +		}
> +	}
> +
> +	/* use PIO if error appened using DMA */
> +	atmel_spi_next_xfer_pio(master, xfer);
> +}
> +
>  static void atmel_spi_next_message(struct spi_master *master)
>  {
>  	struct atmel_spi	*as = spi_master_get_devdata(master);
> @@ -511,7 +845,10 @@ static void atmel_spi_next_message(struct spi_master *master)
>  	} else
>  		cs_activate(as, spi);
>  
> -	atmel_spi_next_xfer(master, msg);
> +	if (as->use_pdc)
> +		atmel_spi_pdc_next_xfer(master, msg);
> +	else
> +		atmel_spi_dma_next_xfer(master, msg);
>  }
>  
>  /*
> @@ -564,6 +901,11 @@ static void atmel_spi_dma_unmap_xfer(struct spi_master *master,
>  				 xfer->len, DMA_FROM_DEVICE);
>  }
>  
> +static void atmel_spi_disable_pdc_transfer(struct atmel_spi *as)
> +{
> +	spi_writel(as, PTCR, SPI_BIT(RXTDIS) | SPI_BIT(TXTDIS));
> +}
> +
>  static void
>  atmel_spi_msg_done(struct spi_master *master, struct atmel_spi *as,
>  		struct spi_message *msg, int stay)
> @@ -589,14 +931,183 @@ atmel_spi_msg_done(struct spi_master *master, struct atmel_spi *as,
>  	as->done_status = 0;
>  
>  	/* continue if needed */
> -	if (list_empty(&as->queue) || as->stopping)
> -		spi_writel(as, PTCR, SPI_BIT(RXTDIS) | SPI_BIT(TXTDIS));
> -	else
> +	if (list_empty(&as->queue) || as->stopping) {
> +		if (as->use_pdc)
> +			atmel_spi_disable_pdc_transfer(as);
> +	} else {
>  		atmel_spi_next_message(master);
> +	}
> +}
> +
> +/* Called from IRQ
> + * lock is held
> + *
> + * Must update "current_remaining_bytes" to keep track of data
> + * to transfer.
> + */
> +static void
> +atmel_spi_pump_pio_data(struct atmel_spi *as, struct spi_transfer *xfer)
> +{
> +	u8		*txp;
> +	u8		*rxp;
> +	unsigned long	xfer_pos = xfer->len - as->current_remaining_bytes;
> +
> +	if (xfer->rx_buf) {
> +		rxp = ((u8 *)xfer->rx_buf) + xfer_pos;
> +		*rxp = spi_readl(as, RDR);
> +	} else {
> +		spi_readl(as, RDR);
> +	}
> +
> +	as->current_remaining_bytes--;
> +
> +	if (as->current_remaining_bytes) {
> +		if (xfer->tx_buf) {
> +			txp = ((u8 *)xfer->tx_buf) + xfer_pos + 1;
> +			spi_writel(as, TDR, *txp);
> +		} else {
> +			spi_writel(as, TDR, 0);
> +		}
> +	}
> +}
> +
> +/* Tasklet
> + * Called from DMA callback + pio transfer and overrun IRQ.
> + */
> +static void atmel_spi_tasklet_func(unsigned long data)
> +{
> +	struct spi_master	*master = (struct spi_master *)data;
> +	struct atmel_spi	*as = spi_master_get_devdata(master);
> +	struct spi_message	*msg;
> +	struct spi_transfer	*xfer;
> +
> +	dev_vdbg(master->dev.parent, "atmel_spi_tasklet_func\n");
> +
> +	atmel_spi_lock(as);
> +
> +	xfer = as->current_transfer;
> +
> +	if (xfer == NULL)
> +		/* already been there */
> +		goto tasklet_out;
> +
> +	msg = list_entry(as->queue.next, struct spi_message, queue);
> +
> +	if (as->current_remaining_bytes == 0) {
> +		if (as->done_status < 0) {
> +			/* error happened (overrun) */
> +			if (atmel_spi_use_dma(as, xfer))
> +				atmel_spi_stop_dma(as);
> +		} else {
> +			/* only update length if no error */
> +			msg->actual_length += xfer->len;
> +		}
> +
> +		if (atmel_spi_use_dma(as, xfer))
> +			if (!msg->is_dma_mapped)
> +				atmel_spi_dma_unmap_xfer(master, xfer);
> +
> +		if (xfer->delay_usecs)
> +			udelay(xfer->delay_usecs);
> +
> +		if (atmel_spi_xfer_is_last(msg, xfer) || as->done_status < 0) {
> +			/* report completed (or erroneous) message */
> +			atmel_spi_msg_done(master, as, msg, xfer->cs_change);
> +		} else {
> +			if (xfer->cs_change) {
> +				cs_deactivate(as, msg->spi);
> +				udelay(1);
> +				cs_activate(as, msg->spi);
> +			}
> +
> +			/*
> +			 * Not done yet. Submit the next transfer.
> +			 *
> +			 * FIXME handle protocol options for xfer
> +			 */
> +			atmel_spi_dma_next_xfer(master, msg);
> +		}
> +	} else {
> +		/*
> +		 * Keep going, we still have data to send in
> +		 * the current transfer.
> +		 */
> +		atmel_spi_dma_next_xfer(master, msg);
> +	}
> +
> +tasklet_out:
> +	atmel_spi_unlock(as);
> +}
> +
> +/* Interrupt
> + *
> + * No need for locking in this Interrupt handler: done_status is the
> + * only information modified. What we need is the update of this field
> + * before tasklet runs. This is ensured by using barrier.
> + */
> +static irqreturn_t
> +atmel_spi_pio_interrupt(int irq, void *dev_id)
> +{
> +	struct spi_master	*master = dev_id;
> +	struct atmel_spi	*as = spi_master_get_devdata(master);
> +	u32			status, pending, imr;
> +	struct spi_transfer	*xfer;
> +	int			ret = IRQ_NONE;
> +
> +	imr = spi_readl(as, IMR);
> +	status = spi_readl(as, SR);
> +	pending = status & imr;
> +
> +	if (pending & SPI_BIT(OVRES)) {
> +		ret = IRQ_HANDLED;
> +		spi_writel(as, IDR, SPI_BIT(OVRES));
> +		dev_warn(master->dev.parent, "overrun\n");
> +
> +		/*
> +		 * When we get an overrun, we disregard the current
> +		 * transfer. Data will not be copied back from any
> +		 * bounce buffer and msg->actual_len will not be
> +		 * updated with the last xfer.
> +		 *
> +		 * We will also not process any remaning transfers in
> +		 * the message.
> +		 *
> +		 * All actions are done in tasklet with done_status indication
> +		 */
> +		as->done_status = -EIO;
> +		smp_wmb();
> +
> +		/* Clear any overrun happening while cleaning up */
> +		spi_readl(as, SR);
> +
> +		tasklet_schedule(&as->tasklet);
> +
> +	} else if (pending & SPI_BIT(RDRF)) {
> +		atmel_spi_lock(as);
> +
> +		if (as->current_remaining_bytes) {
> +			ret = IRQ_HANDLED;
> +			xfer = as->current_transfer;
> +			atmel_spi_pump_pio_data(as, xfer);
> +			if (!as->current_remaining_bytes) {
> +				/* no more data to xfer, kick tasklet */
> +				spi_writel(as, IDR, pending);
> +				tasklet_schedule(&as->tasklet);
> +			}
> +		}
> +
> +		atmel_spi_unlock(as);
> +	} else {
> +		WARN_ONCE(pending, "IRQ not handled, pending = %x\n", pending);
> +		ret = IRQ_HANDLED;
> +		spi_writel(as, IDR, pending);
> +	}
> +
> +	return ret;
>  }
>  
>  static irqreturn_t
> -atmel_spi_interrupt(int irq, void *dev_id)
> +atmel_spi_pdc_interrupt(int irq, void *dev_id)
>  {
>  	struct spi_master	*master = dev_id;
>  	struct atmel_spi	*as = spi_master_get_devdata(master);
> @@ -697,14 +1208,14 @@ atmel_spi_interrupt(int irq, void *dev_id)
>  				 *
>  				 * FIXME handle protocol options for xfer
>  				 */
> -				atmel_spi_next_xfer(master, msg);
> +				atmel_spi_pdc_next_xfer(master, msg);
>  			}
>  		} else {
>  			/*
>  			 * Keep going, we still have data to send in
>  			 * the current transfer.
>  			 */
> -			atmel_spi_next_xfer(master, msg);
> +			atmel_spi_pdc_next_xfer(master, msg);
>  		}
>  	}
>  
> @@ -875,13 +1386,10 @@ static int atmel_spi_transfer(struct spi_device *spi, struct spi_message *msg)
>  
>  		/*
>  		 * DMA map early, for performance (empties dcache ASAP) and
> -		 * better fault reporting.  This is a DMA-only driver.
> -		 *
> -		 * NOTE that if dma_unmap_single() ever starts to do work on
> -		 * platforms supported by this driver, we would need to clean
> -		 * up mappings for previously-mapped transfers.
> +		 * better fault reporting.
>  		 */
> -		if (!msg->is_dma_mapped) {
> +		if ((!msg->is_dma_mapped) && (atmel_spi_use_dma(as, xfer)
> +			|| as->use_pdc)) {
>  			if (atmel_spi_dma_map_xfer(as, xfer) < 0)
>  				return -ENOMEM;
>  		}
> @@ -1000,6 +1508,7 @@ static int atmel_spi_probe(struct platform_device *pdev)
>  
>  	spin_lock_init(&as->lock);
>  	INIT_LIST_HEAD(&as->queue);
> +
>  	as->pdev = pdev;
>  	as->regs = ioremap(regs->start, resource_size(regs));
>  	if (!as->regs)
> @@ -1010,8 +1519,28 @@ static int atmel_spi_probe(struct platform_device *pdev)
>  
>  	atmel_get_caps(as);
>  
> -	ret = request_irq(irq, atmel_spi_interrupt, 0,
> -			dev_name(&pdev->dev), master);
> +	as->use_dma = false;
> +	as->use_pdc = false;
> +	if (as->caps.has_dma_support) {
> +		if (atmel_spi_configure_dma(as) == 0)
> +			as->use_dma = true;
> +	} else {
> +		as->use_pdc = true;
> +	}
> +
> +	if (as->caps.has_dma_support && !as->use_dma)
> +		dev_info(&pdev->dev, "Atmel SPI Controller using PIO only\n");
> +
> +	if (as->use_pdc) {
> +		ret = request_irq(irq, atmel_spi_pdc_interrupt, 0,
> +					dev_name(&pdev->dev), master);
> +	} else {
> +		tasklet_init(&as->tasklet, atmel_spi_tasklet_func,
> +					(unsigned long)master);
> +
> +		ret = request_irq(irq, atmel_spi_pio_interrupt, 0,
> +					dev_name(&pdev->dev), master);
> +	}
>  	if (ret)
>  		goto out_unmap_regs;
>  
> @@ -1025,7 +1554,9 @@ static int atmel_spi_probe(struct platform_device *pdev)
>  	} else {
>  		spi_writel(as, MR, SPI_BIT(MSTR) | SPI_BIT(MODFDIS));
>  	}
> -	spi_writel(as, PTCR, SPI_BIT(RXTDIS) | SPI_BIT(TXTDIS));
> +
> +	if (as->use_pdc)
> +		spi_writel(as, PTCR, SPI_BIT(RXTDIS) | SPI_BIT(TXTDIS));
>  	spi_writel(as, CR, SPI_BIT(SPIEN));
>  
>  	/* go! */
> @@ -1034,11 +1565,14 @@ static int atmel_spi_probe(struct platform_device *pdev)
>  
>  	ret = spi_register_master(master);
>  	if (ret)
> -		goto out_reset_hw;
> +		goto out_free_dma;
>  
>  	return 0;
>  
> -out_reset_hw:
> +out_free_dma:
> +	if (as->use_dma)
> +		atmel_spi_release_dma(as);
> +
>  	spi_writel(as, CR, SPI_BIT(SWRST));
>  	spi_writel(as, CR, SPI_BIT(SWRST)); /* AT91SAM9263 Rev B workaround */
>  	clk_disable(clk);
> @@ -1046,6 +1580,8 @@ out_reset_hw:
>  out_unmap_regs:
>  	iounmap(as->regs);
>  out_free_buffer:
> +	if (!as->use_pdc)
> +		tasklet_kill(&as->tasklet);
>  	dma_free_coherent(&pdev->dev, BUFFER_SIZE, as->buffer,
>  			as->buffer_dma);
>  out_free:
> @@ -1064,6 +1600,11 @@ static int atmel_spi_remove(struct platform_device *pdev)
>  	/* reset the hardware and block queue progress */
>  	spin_lock_irq(&as->lock);
>  	as->stopping = 1;
> +	if (as->use_dma) {
> +		atmel_spi_stop_dma(as);
> +		atmel_spi_release_dma(as);
> +	}
> +
>  	spi_writel(as, CR, SPI_BIT(SWRST));
>  	spi_writel(as, CR, SPI_BIT(SWRST)); /* AT91SAM9263 Rev B workaround */
>  	spi_readl(as, SR);
> @@ -1072,13 +1613,17 @@ static int atmel_spi_remove(struct platform_device *pdev)
>  	/* Terminate remaining queued transfers */
>  	list_for_each_entry(msg, &as->queue, queue) {
>  		list_for_each_entry(xfer, &msg->transfers, transfer_list) {
> -			if (!msg->is_dma_mapped)
> +			if (!msg->is_dma_mapped
> +				&& (atmel_spi_use_dma(as, xfer)
> +					|| as->use_pdc))
>  				atmel_spi_dma_unmap_xfer(master, xfer);
>  		}
>  		msg->status = -ESHUTDOWN;
>  		msg->complete(msg->context);
>  	}
>  
> +	if (!as->use_pdc)
> +		tasklet_kill(&as->tasklet);
>  	dma_free_coherent(&pdev->dev, BUFFER_SIZE, as->buffer,
>  			as->buffer_dma);
>  
> -- 
> 1.7.9.5
> 
As I did some work on that one:
Signed-off-by: Richard Genoud <richard.genoud at gmail.com>

BUT, there's one thing not working (at least for me !):
With DMA enabled, using spidev.
if we use the ioctl SPI_IOC_MESSAGE(x) (tested with x=3):

#define SMALL 2
#define BIG 120
#define NB 3
struct spi_ioc_transfer	xfer[NB];
char buffer[BIG];
char rx_header[SMALL];
char rx_footer[SMALL];
char tx_header[SMALL];
char tx_footer[SMALL];

xfer[0].tx_buf = (unsigned long)&tx_header;
xfer[0].rx_buf = (unsigned long)&rx_header;
xfer[0].len = SMALL;
xfer[1].tx_buf = (unsigned long)buffer;
xfer[1].rx_buf = (unsigned long)buffer;
xfer[1].len = BIG;
xfer[2].tx_buf = (unsigned long)&tx_footer;
xfer[2].rx_buf = (unsigned long)&rx_footer;
xfer[2].len = SMALL
ioctl(fd, SPI_IOC_MESSAGE(NB), xfer);

In this use case, the buffer received contains weird stuff *sometimes*
(header corrupted for example).
BUT if I set 
+#define DMA_MIN_BYTES	1
instead of:
+#define DMA_MIN_BYTES	16
Everything works fine.
So I suggest for now:
+/*
+ * FIXME: alternating DMA and PIO transfert (with SPI_IOC_MESSAGE() for
+ * instance), seems to corrupt data.
+ */
+#define DMA_MIN_BYTES	1

With that change:
On sam9g35 with DMA and PIO (3.9-rc5 + device tree patches)
Tested-by: Richard Genoud <richard.genoud at gmail.com>




From gang.chen at asianux.com  Wed Apr  3 06:29:14 2013
From: gang.chen at asianux.com (Chen Gang)
Date: Wed, 03 Apr 2013 18:29:14 +0800
Subject: [Suggestion] ARM:S5pv210: compiling issue for s5pv210 by using
 randconfig
In-Reply-To: <20130403101018.GE11040@mudshark.cambridge.arm.com>
References: <514FB202.3040807@asianux.com> <515BFA8D.2000204@asianux.com>
 <20130403101018.GE11040@mudshark.cambridge.arm.com>
Message-ID: <515C047A.9010906@asianux.com>

On 2013?04?03? 18:10, Will Deacon wrote:
> I think the main problem is that you've reported an issue created from a
> randconfig, but you haven't made the config in question available.

  excuse me, my English is not quite well.

  I guess your meaning is :
    I need also provide the related .config file in this mail.
    so we can be more easier to find the root cause.

  is it correct ?


  BTW:
    unlucky, the original .config has been deleted.
    I can try to reproduce it, so let us to fix it with more efficiency.

  thanks.

-- 
Chen Gang

Asianux Corporation


From richard.genoud at gmail.com  Wed Apr  3 06:35:14 2013
From: richard.genoud at gmail.com (Richard GENOUD)
Date: Wed, 3 Apr 2013 12:35:14 +0200
Subject: [PATCH v8 8/8] ARM: dts: add pinctrl property for spi node for
 atmel SoC
In-Reply-To: <1364969032-24281-1-git-send-email-wenyou.yang@atmel.com>
References: <1364968581-23700-1-git-send-email-wenyou.yang@atmel.com>
 <1364969032-24281-1-git-send-email-wenyou.yang@atmel.com>
Message-ID: <20130403103512.GB4633@lnx-rg>

On [mer., 03.04.2013 14:03:52], Wenyou Yang wrote:
> Signed-off-by: Wenyou Yang <wenyou.yang at atmel.com>
> Cc: linux at arm.linux.org.uk
> Cc: linux-kernel at vger.kernel.org
> ---
>  arch/arm/boot/dts/at91sam9260.dtsi |   22 ++++++++++++++++++++++
>  arch/arm/boot/dts/at91sam9263.dtsi |   22 ++++++++++++++++++++++
>  arch/arm/boot/dts/at91sam9g45.dtsi |   22 ++++++++++++++++++++++
>  arch/arm/boot/dts/at91sam9n12.dtsi |   22 ++++++++++++++++++++++
>  arch/arm/boot/dts/at91sam9x5.dtsi  |   22 ++++++++++++++++++++++
>  5 files changed, 110 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/at91sam9260.dtsi b/arch/arm/boot/dts/at91sam9260.dtsi
> index 6e31dc8..39253b9 100644
> --- a/arch/arm/boot/dts/at91sam9260.dtsi
> +++ b/arch/arm/boot/dts/at91sam9260.dtsi
> @@ -322,6 +322,24 @@
>  					};
>  				};
>  
> +				spi0 {
> +					pinctrl_spi0: spi0-0 {
> +						atmel,pins =
> +							<0 0 0x1 0x0	/* PA0 periph A SPI0_MISO pin */
> +							 0 1 0x1 0x0	/* PA1 periph A SPI0_MOSI pin */
> +							 0 2 0x1 0x0>;	/* PA2 periph A SPI0_SPCK pin */
> +					};
> +				};
> +
> +				spi1 {
> +					pinctrl_spi1: spi1-0 {
> +						atmel,pins =
> +							<1 0 0x1 0x0	/* PB0 periph A SPI1_MISO pin */
> +							 1 1 0x1 0x0	/* PB1 periph A SPI1_MOSI pin */
> +							 1 2 0x1 0x0>;	/* PB2 periph A SPI1_SPCK pin */
> +					};
> +				};
> +
>  				pioA: gpio at fffff400 {
>  					compatible = "atmel,at91rm9200-gpio";
>  					reg = <0xfffff400 0x200>;
> @@ -477,6 +495,8 @@
>  				compatible = "atmel,at91rm9200-spi";
>  				reg = <0xfffc8000 0x200>;
>  				interrupts = <12 4 3>;
> +				pinctrl-names = "default";
> +				pinctrl-0 = <&pinctrl_spi0>;
>  				status = "disabled";
>  			};
>  
> @@ -486,6 +506,8 @@
>  				compatible = "atmel,at91rm9200-spi";
>  				reg = <0xfffcc000 0x200>;
>  				interrupts = <13 4 3>;
> +				pinctrl-names = "default";
> +				pinctrl-0 = <&pinctrl_spi1>;
>  				status = "disabled";
>  			};
>  
> diff --git a/arch/arm/boot/dts/at91sam9263.dtsi b/arch/arm/boot/dts/at91sam9263.dtsi
> index 6c6d9ae..94b58ab 100644
> --- a/arch/arm/boot/dts/at91sam9263.dtsi
> +++ b/arch/arm/boot/dts/at91sam9263.dtsi
> @@ -303,6 +303,24 @@
>  					};
>  				};
>  
> +				spi0 {
> +					pinctrl_spi0: spi0-0 {
> +						atmel,pins =
> +							<0 0 0x2 0x0	/* PA0 periph B SPI0_MISO pin */
> +							 0 1 0x2 0x0	/* PA1 periph B SPI0_MOSI pin */
> +							 0 2 0x2 0x0>;	/* PA2 periph B SPI0_SPCK pin */
> +					};
> +				};
> +
> +				spi1 {
> +					pinctrl_spi1: spi1-0 {
> +						atmel,pins =
> +							<1 12 0x1 0x0	/* PB12 periph A SPI1_MISO pin */
> +							 1 13 0x1 0x0	/* PB13 periph A SPI1_MOSI pin */
> +							 1 14 0x1 0x0>;	/* PB14 periph A SPI1_SPCK pin */
> +					};
> +				};
> +
>  				pioA: gpio at fffff200 {
>  					compatible = "atmel,at91rm9200-gpio";
>  					reg = <0xfffff200 0x200>;
> @@ -469,6 +487,8 @@
>  				compatible = "atmel,at91rm9200-spi";
>  				reg = <0xfffa4000 0x200>;
>  				interrupts = <14 4 3>;
> +				pinctrl-names = "default";
> +				pinctrl-0 = <&pinctrl_spi0>;
>  				status = "disabled";
>  			};
>  
> @@ -478,6 +498,8 @@
>  				compatible = "atmel,at91rm9200-spi";
>  				reg = <0xfffa8000 0x200>;
>  				interrupts = <15 4 3>;
> +				pinctrl-names = "default";
> +				pinctrl-0 = <&pinctrl_spi1>;
>  				status = "disabled";
>  			};
>  		};
> diff --git a/arch/arm/boot/dts/at91sam9g45.dtsi b/arch/arm/boot/dts/at91sam9g45.dtsi
> index e085b8a..cfdf429 100644
> --- a/arch/arm/boot/dts/at91sam9g45.dtsi
> +++ b/arch/arm/boot/dts/at91sam9g45.dtsi
> @@ -322,6 +322,24 @@
>  					};
>  				};
>  
> +				spi0 {
> +					pinctrl_spi0: spi0-0 {
> +						atmel,pins =
> +							<1 0 0x1 0x0	/* PB0 periph A SPI0_MISO pin */
> +							 1 1 0x1 0x0	/* PB1 periph A SPI0_MOSI pin */
> +							 1 2 0x1 0x0>;	/* PB2 periph A SPI0_SPCK pin */
> +					};
> +				};
> +
> +				spi1 {
> +					pinctrl_spi1: spi1-0 {
> +						atmel,pins =
> +							<1 14 0x1 0x0	/* PB14 periph A SPI1_MISO pin */
> +							 1 15 0x1 0x0	/* PB15 periph A SPI1_MOSI pin */
> +							 1 16 0x1 0x0>;	/* PB16 periph A SPI1_SPCK pin */
> +					};
> +				};
> +
>  				pioA: gpio at fffff200 {
>  					compatible = "atmel,at91rm9200-gpio";
>  					reg = <0xfffff200 0x200>;
> @@ -538,6 +556,8 @@
>  				compatible = "atmel,at91rm9200-spi";
>  				reg = <0xfffa4000 0x200>;
>  				interrupts = <14 4 3>;
> +				pinctrl-names = "default";
> +				pinctrl-0 = <&pinctrl_spi0>;
>  				status = "disabled";
>  			};
>  
> @@ -547,6 +567,8 @@
>  				compatible = "atmel,at91rm9200-spi";
>  				reg = <0xfffa8000 0x200>;
>  				interrupts = <15 4 3>;
> +				pinctrl-names = "default";
> +				pinctrl-0 = <&pinctrl_spi1>;
>  				status = "disabled";
>  			};
>  		};
> diff --git a/arch/arm/boot/dts/at91sam9n12.dtsi b/arch/arm/boot/dts/at91sam9n12.dtsi
> index f3f87ef3..b2961f1 100644
> --- a/arch/arm/boot/dts/at91sam9n12.dtsi
> +++ b/arch/arm/boot/dts/at91sam9n12.dtsi
> @@ -261,6 +261,24 @@
>  					};
>  				};
>  
> +				spi0 {
> +					pinctrl_spi0: spi0-0 {
> +						atmel,pins =
> +							<0 11 0x1 0x0	/* PA11 periph A SPI0_MISO pin */
> +							 0 12 0x1 0x0	/* PA12 periph A SPI0_MOSI pin */
> +							 0 13 0x1 0x0>;	/* PA13 periph A SPI0_SPCK pin */
> +					};
> +				};
> +
> +				spi1 {
> +					pinctrl_spi1: spi1-0 {
> +						atmel,pins =
> +							<0 21 0x2 0x0	/* PA21 periph B SPI1_MISO pin */
> +							 0 22 0x2 0x0	/* PA22 periph B SPI1_MOSI pin */
> +							 0 23 0x2 0x0>;	/* PA23 periph B SPI1_SPCK pin */
> +					};
> +				};
> +
>  				pioA: gpio at fffff400 {
>  					compatible = "atmel,at91sam9x5-gpio", "atmel,at91rm9200-gpio";
>  					reg = <0xfffff400 0x200>;
> @@ -380,6 +398,8 @@
>  				compatible = "atmel,at91rm9200-spi";
>  				reg = <0xf0000000 0x100>;
>  				interrupts = <13 4 3>;
> +				pinctrl-names = "default";
> +				pinctrl-0 = <&pinctrl_spi0>;
>  				status = "disabled";
>  			};
>  
> @@ -389,6 +409,8 @@
>  				compatible = "atmel,at91rm9200-spi";
>  				reg = <0xf0004000 0x100>;
>  				interrupts = <14 4 3>;
> +				pinctrl-names = "default";
> +				pinctrl-0 = <&pinctrl_spi1>;
>  				status = "disabled";
>  			};
>  		};
> diff --git a/arch/arm/boot/dts/at91sam9x5.dtsi b/arch/arm/boot/dts/at91sam9x5.dtsi
> index 77ce2e1..347b438 100644
> --- a/arch/arm/boot/dts/at91sam9x5.dtsi
> +++ b/arch/arm/boot/dts/at91sam9x5.dtsi
> @@ -343,6 +343,24 @@
>  					};
>  				};
>  
> +				spi0 {
> +					pinctrl_spi0: spi0-0 {
> +						atmel,pins =
> +							<0 11 0x1 0x0	/* PA11 periph A SPI0_MISO pin */
> +							 0 12 0x1 0x0	/* PA12 periph A SPI0_MOSI pin */
> +							 0 13 0x1 0x0>;	/* PA13 periph A SPI0_SPCK pin */
> +					};
> +				};
> +
> +				spi1 {
> +					pinctrl_spi1: spi1-0 {
> +						atmel,pins =
> +							<0 21 0x2 0x0	/* PA21 periph B SPI1_MISO pin */
> +							 0 22 0x2 0x0	/* PA22 periph B SPI1_MOSI pin */
> +							 0 23 0x2 0x0>;	/* PA23 periph B SPI1_SPCK pin */
> +					};
> +				};
> +
>  				pioA: gpio at fffff400 {
>  					compatible = "atmel,at91sam9x5-gpio", "atmel,at91rm9200-gpio";
>  					reg = <0xfffff400 0x200>;
> @@ -536,6 +554,8 @@
>  				compatible = "atmel,at91rm9200-spi";
>  				reg = <0xf0000000 0x100>;
>  				interrupts = <13 4 3>;
> +				pinctrl-names = "default";
> +				pinctrl-0 = <&pinctrl_spi0>;
>  				status = "disabled";
>  			};
>  
> @@ -545,6 +565,8 @@
>  				compatible = "atmel,at91rm9200-spi";
>  				reg = <0xf0004000 0x100>;
>  				interrupts = <14 4 3>;
> +				pinctrl-names = "default";
> +				pinctrl-0 = <&pinctrl_spi1>;
>  				status = "disabled";
>  			};
>  		};
> -- 
> 1.7.9.5
> 
On sam9g35 with DMA and PIO (3.9-rc5 + device tree patches)
Tested-by: Richard Genoud <richard.genoud at gmail.com>


From nicolas.ferre at atmel.com  Wed Apr  3 06:37:47 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Wed, 3 Apr 2013 12:37:47 +0200
Subject: [RFC PATCH v2] rtc: rtc-at91rm9200: manage IMR depending on
 revision
In-Reply-To: <20130403095150.GC27600@localhost>
References: <1364908007-5150-1-git-send-email-nicolas.ferre@atmel.com>
 <1364920566-30040-1-git-send-email-nicolas.ferre@atmel.com>
 <20130403095150.GC27600@localhost>
Message-ID: <515C067B.6070503@atmel.com>

On 04/03/2013 11:51 AM, Johan Hovold :
> On Tue, Apr 02, 2013 at 06:36:06PM +0200, Nicolas Ferre wrote:
>> Signed-off-by: Nicolas Ferre <nicolas.ferre at atmel.com>
>> ---
>> Hi again,
>>
>> Here is my latest revision of this fix. It depends on the patch that is already
>> in Andrew's patch stack: "drivers-rtc-rtc-at91rm9200c-add-dt-support.patch".
> 
> That is a problem, as the patch in Andrew's stack is not (and should
> not) be marked for stable. Hence this patch cannot be applied to the
> stable trees and it won't even apply to 3.9-rc.

My intentions were to tag both patches for "stable". You highlight that
it is not a good practice: I admit that you are right.


> But there's more: The offending patch introduced the races we have been
> discussion while attempting to add support for the sam9x5 with the
> broken hardware register. But that family cannot be used without
> DT-support, which the driver currently does not support. Hence, we added
> a workaround (and introduced a regression by mistake), while adding
> support for a SoC which still could not use the driver. [ For example,
> the sam9x5 RTC-base register address can only be supplied from DT. ]
> 
> I think the only reasonable thing to do is to revert the patch and add
> whatever version of the work-around on top of the device-tree support
> when that is added to the driver (hence, earliest v3.10).

Yes. Let's do this.


>> I now use a different compatibility string to figure out what is the IP
>> revision that has the "boggus IMR" error. I think this way to handle it
>> is much simpler than the "config" structure one from Johan.
> 
> I wouldn't say it's much simpler. My solution is only more generic, but
> could of course also be reduced to "set a flag if compatible matches
> sam9x5".

The advantage is precisely to avoid the need for a "flag". Only function
pointers that are changed in case of the compatible string matching.


>> The small number of line changed and the "single patch" nature of it
>> make me think that it will be easier to send upstream and in the
>> "stable" trees...
> 
> Unfortunately, the 130-line diff isn't very small. In fact, it violates
> the stable-kernel guide line of <100 lines. And as noted above, it
> depends on another patch which adds DT-support (which is a new feature
> and not a fix).
> 
> But the fundamental problem remains: it does not fix anything which was
> working before the first work-around patch introduced the regression. I
> think this is a clear case where we need to revert.

Okay.

>> Please give feedback, but moreover, I would like to know if you (Johan and Douglas)
>> agree to give your "Signed-off-by" line because this patch is certainly
>> inspired by your comments, code and reviews.
>>
>> Thank you for your help. Best regards,
>>
>>  .../bindings/rtc/atmel,at91rm9200-rtc.txt          |   3 +-
>>  drivers/rtc/rtc-at91rm9200.c                       | 126 ++++++++++++++++-----
>>  drivers/rtc/rtc-at91rm9200.h                       |   1 +
>>  3 files changed, 101 insertions(+), 29 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/rtc/atmel,at91rm9200-rtc.txt b/Documentation/devicetree/bindings/rtc/atmel,at91rm9200-rtc.txt
>> index 2a3feab..9b87053 100644
>> --- a/Documentation/devicetree/bindings/rtc/atmel,at91rm9200-rtc.txt
>> +++ b/Documentation/devicetree/bindings/rtc/atmel,at91rm9200-rtc.txt
>> @@ -1,7 +1,8 @@
>>  Atmel AT91RM9200 Real Time Clock
>>  
>>  Required properties:
>> -- compatible: should be: "atmel,at91rm9200-rtc"
>> +- compatible: should be: "atmel,at91rm9200-rtc", "atmel,at91sam9x5-rtc" or
>> +                         "atmel,at91sam9n12-rtc".
> 
> Also at91sam9g45 and at91sam9rl use this driver.

Yes, sure, I did not want to add every single user of the RTC...

> As seems to be the case
> for other peripherals, I suggest we use "atmel,at91sam9x5-rtc" for
> sam9x5 and "atmel,at91rm9200-rtc" for the other SoCs, that is, the least
> (and first) common denominator.

... I was just following the habit of naming the changes in peripheral
revision by it first use in a SoC:
at91rm9200-rtc: from rm9200 up to 9g45
at91sam9x5-rtc: sam9x5 only (with IMR issue)
at91sam9n12-rtc: fist SoC that corrects the IMR issue with a new IP
revision, until now and sama5d3 SoC



> Either way, there's not need to add at91sam9n12-rtc in this patch.
> 
>>  - reg: physical base address of the controller and length of memory mapped
>>    region.
>>  - interrupts: rtc alarm/event interrupt
> 
> I'll respond to this mail with a revert-patch, and an updated RFC-series
> based on top of the DT-patch in Andrew's queue.

Best regards,
-- 
Nicolas Ferre


From marc.zyngier at arm.com  Wed Apr  3 06:38:30 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 03 Apr 2013 11:38:30 +0100
Subject: [PATCH 6/7] ARM: KVM: switch to a dual-step HYP init code
In-Reply-To: <20130403100751.GD11040@mudshark.cambridge.arm.com>
References: <1364909115-3810-1-git-send-email-marc.zyngier@arm.com>
 <1364909115-3810-7-git-send-email-marc.zyngier@arm.com>
 <20130403100751.GD11040@mudshark.cambridge.arm.com>
Message-ID: <515C06A6.5030807@arm.com>

On 03/04/13 11:07, Will Deacon wrote:
> On Tue, Apr 02, 2013 at 02:25:14PM +0100, Marc Zyngier wrote:
>> Our HYP init code suffers from two major design issues:
>> - it cannot support CPU hotplug, as we tear down the idmap very early
>> - it cannot perform a TLB invalidation when switching from init to
>>   runtime mappings, as pages are manipulated from PL1 exclusively
> 
> [...]
> 
>> diff --git a/arch/arm/kvm/init.S b/arch/arm/kvm/init.S
>> index 35a463f..b2c6967 100644
>> --- a/arch/arm/kvm/init.S
>> +++ b/arch/arm/kvm/init.S
>> @@ -21,6 +21,7 @@
>>  #include <asm/asm-offsets.h>
>>  #include <asm/kvm_asm.h>
>>  #include <asm/kvm_arm.h>
>> +#include <asm/kvm_mmu.h>
>>  
>>  /********************************************************************
>>   * Hypervisor initialization
>> @@ -47,6 +48,9 @@ __kvm_hyp_init:
>>  	W(b)	.
>>  
>>  __do_hyp_init:
>> +	cmp	r2, #0			@ We have a SP?
>> +	bne	phase2			@ Yes, second stage init
>> +
>>  	@ Set the HTTBR to point to the hypervisor PGD pointer passed
>>  	mcrr	p15, 4, r0, r1, c2
>>  
>> @@ -96,14 +100,35 @@ __do_hyp_init:
>>  	orr	r0, r0, r1
>>  	isb
>>  	mcr	p15, 4, r0, c1, c0, 0	@ HSCR
>> -	isb
>>  
>> -	@ Set stack pointer and return to the kernel
>> +	eret
>> +
>> +phase2:
>> +	@ Set stack pointer
>>  	mov	sp, r2
>>  
>>  	@ Set HVBAR to point to the HYP vectors
>>  	mcr	p15, 4, r3, c12, c0, 0	@ HVBAR
>>  
>> +	@ Jump to the trampoline page
>> +	ldr	r2, =#PAGE_MASK
> 
> Shifting right by PAGE_SHIFT can avoid the load.

Not really. We're masking out the top bits of "target" and adding them
to the trampoline base address, so shifting doesn't help.

But, as you suggested offline, BFI can come to the rescue and make that
code totally fun and unreadable. How about (untested):

	ldr	r2, =#TRAMPOLINE_VA
	adr	r3, target
	bfi	r2, r3, #0, #PAGE_SHIFT
	mov	pc, r2

I really like it! :)

> 
>> +	adr	r3, target
>> +	bic	r3, r3, r2
>> +	ldr	r2, =#TRAMPOLINE_VA
>> +	add	r3, r3, r2
>> +	mov	pc, r3
>> +
>> +	nop
> 
> <insert dead chicken and voodoo chant here>

... "You know I'll never sleep no more" ...

>> +
>> +target:	@ We're now in the trampoline code, switch page tables
>> +	mcrr	p15, 4, r0, r1, c2
>> +	isb
>> +
>> +	@ Invalidate the old TLBs
>> +	mcr	p15, 4, r0, c8, c7, 0	@ TLBIALLH
>> +	dsb
>> +	isb
> 
> You don't actually need this isb (there's an eret next!).

Good point. I'll remove it in V2.

Thanks for reviewing,

	M.
-- 
Jazz is not dead. It just smells funny...



From thomas.petazzoni at free-electrons.com  Wed Apr  3 06:46:08 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Wed, 3 Apr 2013 12:46:08 +0200
Subject: [PATCH] arm: mvebu: Fix the memory size on the Mirabox
In-Reply-To: <20130329193716.GA7127@localhost>
References: <1364579477-19018-1-git-send-email-ryan@presslab.us>
 <20130329180447.GK13280@titan.lakedaemon.net>
 <CABx3TkVK86b8Ku4EvUVe8OBtprwKW6YtJ7OU6YVHa3Bd5s7DsQ@mail.gmail.com>
 <20130329193716.GA7127@localhost>
Message-ID: <20130403124608.5de971f1@skate>

Dear Ezequiel Garcia,

On Fri, 29 Mar 2013 16:37:17 -0300, Ezequiel Garcia wrote:

> As far as I can remember, Gregory has a Mirabox with only 512 MiB,
> which means some boards were shipped with 512 MiB and some with 1 GiB.
> Moreover, apparently nothing can distinguish one from the other.

I do confirm that some Mirabox only have 512 MB of RAM, at least
according to U-Boot:

U-Boot 2009.08 (May 23 2012 - 16:35:03)Marvell version: 1.1.0 NQ
U-Boot Addressing:
       Code:		00600000:006AFFF0
       BSS:		006F8E40
       Stack:		0x5fff70
       PageTable:	0x8e0000
       Heap address:	0x900000:0xe00000
Board: DB-88F6710-BP
SoC:   MV6710 Z1
CPU:   Marvell PJ4B v7 UP (Rev 1) LE
       DDR @ 600Mhz, TClock @ 200Mhz
       DDR 16Bit Width, FastPath Memory Access
PEX 0: Root Complex Interface, Detected Link X1
PEX 1: Root Complex Interface, Detected Link X1
DRAM:  512 MB
       CS 0: base 0x00000000 size 512 MB
       Addresses 14M - 0M are saved for the U-Boot usage.

The mvebu_defconfig contains CONFIG_ARM_ATAG_DTB_COMPAT=y, so it should
automatically pick up the amount of memory defined by U-Boot in the
ATAGS.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From thomas.petazzoni at free-electrons.com  Wed Apr  3 06:52:47 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Wed, 3 Apr 2013 12:52:47 +0200
Subject: [RFC PATCHv1 2/5] bus: mvebu: fix mistake in PCIe window target
 attribute for Kirkwood
In-Reply-To: <1364407504-13524-3-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1364407504-13524-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1364407504-13524-3-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <20130403125247.5914a862@skate>

Jason (Cooper),

Do you mind taking this patch in your mvebu/drivers branch, next to the
patch adding the mvebu-mbus driver? Or do you want a new mvebu-mbus
driver patch that contains this fix and would replace the one you have
already merged in mvebu/drivers?

Thanks!

Thomas

On Wed, 27 Mar 2013 19:05:01 +0100, Thomas Petazzoni wrote:
> The target and attributes for the PCIe address decoding windows were
> not correct on Kirkwood for the second PCIe interface.
> 
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> ---
> Note: this patch should be merged with the existing mvebu-mbus driver.
> ---
>  drivers/bus/mvebu-mbus.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
> index 586d03e..4de2c6b 100644
> --- a/drivers/bus/mvebu-mbus.c
> +++ b/drivers/bus/mvebu-mbus.c
> @@ -626,7 +626,7 @@ static const struct mvebu_mbus_soc_data armada_xp_mbus_data = {
>  
>  static const struct mvebu_mbus_mapping kirkwood_map[] = {
>  	MAPDEF("pcie0.0", 4, 0xe0, MAPDEF_PCIMASK),
> -	MAPDEF("pcie1.0", 8, 0xe0, MAPDEF_PCIMASK),
> +	MAPDEF("pcie1.0", 4, 0xd0, MAPDEF_PCIMASK),
>  	MAPDEF("sram",    3, 0x01, MAPDEF_NOMASK),
>  	MAPDEF("nand",    1, 0x2f, MAPDEF_NOMASK),
>  	{},



-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From daniel.lezcano at linaro.org  Wed Apr  3 06:56:59 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Wed, 03 Apr 2013 12:56:59 +0200
Subject: [PATCH 1/9] ARM: cpuidle: remove useless declaration
Message-ID: <515C0AFB.80203@linaro.org>


Hi Rafael,

I noticed this patchset went to the linux-arm-project in patchwork but
it was addressed to you / linux-pm. AFAIU, you rely on patchwork to
manage the patches, I was wondering if you could have missed them ?

Thanks
  -- Daniel




From jason at lakedaemon.net  Wed Apr  3 06:57:57 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Wed, 3 Apr 2013 06:57:57 -0400
Subject: [RFC PATCHv1 2/5] bus: mvebu: fix mistake in PCIe window
 target attribute for Kirkwood
In-Reply-To: <20130403125247.5914a862@skate>
References: <1364407504-13524-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1364407504-13524-3-git-send-email-thomas.petazzoni@free-electrons.com>
 <20130403125247.5914a862@skate>
Message-ID: <20130403105757.GV13280@titan.lakedaemon.net>

Thomas,

On Wed, Apr 03, 2013 at 12:52:47PM +0200, Thomas Petazzoni wrote:
> Jason (Cooper),
> 
> Do you mind taking this patch in your mvebu/drivers branch, next to the
> patch adding the mvebu-mbus driver? Or do you want a new mvebu-mbus
> driver patch that contains this fix and would replace the one you have
> already merged in mvebu/drivers?

Thanks for pointing this out.  I'll put it in mvebu/drivers as you
suggested.  I'll need to rebase mvebu/soc on it.  But I haven't done the
PR yet, so not a big deal.

thx,

Jason.


> On Wed, 27 Mar 2013 19:05:01 +0100, Thomas Petazzoni wrote:
> > The target and attributes for the PCIe address decoding windows were
> > not correct on Kirkwood for the second PCIe interface.
> > 
> > Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> > ---
> > Note: this patch should be merged with the existing mvebu-mbus driver.
> > ---
> >  drivers/bus/mvebu-mbus.c |    2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
> > index 586d03e..4de2c6b 100644
> > --- a/drivers/bus/mvebu-mbus.c
> > +++ b/drivers/bus/mvebu-mbus.c
> > @@ -626,7 +626,7 @@ static const struct mvebu_mbus_soc_data armada_xp_mbus_data = {
> >  
> >  static const struct mvebu_mbus_mapping kirkwood_map[] = {
> >  	MAPDEF("pcie0.0", 4, 0xe0, MAPDEF_PCIMASK),
> > -	MAPDEF("pcie1.0", 8, 0xe0, MAPDEF_PCIMASK),
> > +	MAPDEF("pcie1.0", 4, 0xd0, MAPDEF_PCIMASK),
> >  	MAPDEF("sram",    3, 0x01, MAPDEF_NOMASK),
> >  	MAPDEF("nand",    1, 0x2f, MAPDEF_NOMASK),
> >  	{},


From rjw at sisk.pl  Wed Apr  3 07:07:45 2013
From: rjw at sisk.pl (Rafael J. Wysocki)
Date: Wed, 03 Apr 2013 13:07:45 +0200
Subject: [PATCH 1/9] ARM: cpuidle: remove useless declaration
In-Reply-To: <515C0AFB.80203@linaro.org>
References: <515C0AFB.80203@linaro.org>
Message-ID: <16852141.k3F9XMielB@vostro.rjw.lan>

On Wednesday, April 03, 2013 12:56:59 PM Daniel Lezcano wrote:
> 
> Hi Rafael,
> 
> I noticed this patchset went to the linux-arm-project in patchwork but
> it was addressed to you / linux-pm. AFAIU, you rely on patchwork to
> manage the patches, I was wondering if you could have missed them ?

I didn't miss it, but I thought that the ARM people would take the patches.

If I'm supposed to take those patches, I need ACKs from every maintainer in
question.  If the patches have been ACKed already, please resend them with the
ACKs.

Thanks,
Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.


From daniel.lezcano at linaro.org  Wed Apr  3 07:04:17 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Wed, 03 Apr 2013 13:04:17 +0200
Subject: [PATCH 1/9] ARM: cpuidle: remove useless declaration
In-Reply-To: <16852141.k3F9XMielB@vostro.rjw.lan>
References: <515C0AFB.80203@linaro.org> <16852141.k3F9XMielB@vostro.rjw.lan>
Message-ID: <515C0CB1.4010802@linaro.org>

On 04/03/2013 01:07 PM, Rafael J. Wysocki wrote:
> On Wednesday, April 03, 2013 12:56:59 PM Daniel Lezcano wrote:
>>
>> Hi Rafael,
>>
>> I noticed this patchset went to the linux-arm-project in patchwork but
>> it was addressed to you / linux-pm. AFAIU, you rely on patchwork to
>> manage the patches, I was wondering if you could have missed them ?
> 
> I didn't miss it, but I thought that the ARM people would take the patches.
> 
> If I'm supposed to take those patches, I need ACKs from every maintainer in
> question.  If the patches have been ACKed already, please resend them with the
> ACKs.

Ok.

-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From thomas.petazzoni at free-electrons.com  Wed Apr  3 07:05:52 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Wed, 3 Apr 2013 13:05:52 +0200
Subject: [RFC PATCHv1 2/5] bus: mvebu: fix mistake in PCIe window target
 attribute for Kirkwood
In-Reply-To: <20130403105757.GV13280@titan.lakedaemon.net>
References: <1364407504-13524-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1364407504-13524-3-git-send-email-thomas.petazzoni@free-electrons.com>
 <20130403125247.5914a862@skate>
 <20130403105757.GV13280@titan.lakedaemon.net>
Message-ID: <20130403130552.0c28ea34@skate>

Dear Jason Cooper,

On Wed, 3 Apr 2013 06:57:57 -0400, Jason Cooper wrote:

> Thanks for pointing this out.  I'll put it in mvebu/drivers as you
> suggested.  I'll need to rebase mvebu/soc on it.  But I haven't done the
> PR yet, so not a big deal.

Ok, thanks. I'll finalize the cleanup of the kirkwood PCIe branch in
order to be able to submit a version that hopefully should be
acceptable.

Thanks,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From sebastian.hesselbarth at gmail.com  Wed Apr  3 07:10:52 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Wed, 3 Apr 2013 13:10:52 +0200
Subject: [PATCH v4] clk: add si5351 i2c common clock driver
In-Reply-To: <20130402234648.8177.86213@quantum>
References: <1363603397-2762-1-git-send-email-sebastian.hesselbarth@gmail.com>
 <1364050010-23919-1-git-send-email-sebastian.hesselbarth@gmail.com>
 <20130402234648.8177.86213@quantum>
Message-ID: <CABJ1b_RtBtLP6jQ1wt8xuLKhvRG2jPr0zcgGWYeWQUUxTd3h7w@mail.gmail.com>

On Wed, Apr 3, 2013 at 1:46 AM, Mike Turquette <mturquette at linaro.org> wrote:
> Quoting Sebastian Hesselbarth (2013-03-23 07:46:50)
>> diff --git a/drivers/clk/clk-si5351.c b/drivers/clk/clk-si5351.c
>> new file mode 100644
>> index 0000000..9d0c210
>> --- /dev/null
>> +++ b/drivers/clk/clk-si5351.c
>> @@ -0,0 +1,1411 @@
>> +/*
>> + * clk-si5351.c: Silicon Laboratories Si5351A/B/C I2C Clock Generator
>> + *
>> + * Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
>> + * Rabeeh Khoury <rabeeh at solid-run.com>
>> + *
>> + * References:
>> + * [1] "Si5351A/B/C Data Sheet"
>> + *     http://www.silabs.com/Support%20Documents/TechnicalDocs/Si5351.pdf
>> + * [2] "Manually Generating an Si5351 Register Map"
>> + *     http://www.silabs.com/Support%20Documents/TechnicalDocs/AN619.pdf
>> + *
>> + * 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.
>> + */
>> +
>> +#include <linux/module.h>
>> +#include <linux/kernel.h>
>> +#include <linux/clk-private.h>
>
> I hope that this is supposed to be clk-provider.h.  I don't plan on
> taking in any more clock drivers that depend on clk-private.h.  I didn't
> see any reason for this patch to not use clk-provider.h.

True except for two things:
- The driver sets clk flags for the hierarchy after parsing the DT and
there is no helper __clk_set_flags()
- For single parent clks (pxtal, pclkin) I reuse &clk->name for .parent_names

For the latter I would have to add two static char *[1] somewhere, not
a big deal. But the for the flags,
I guess there will be no __clk_set_flags helper? Then I'd have to
parse the DT in advance to have the
correct flags ready at clk registration.

Sebastian


From peter.ujfalusi at ti.com  Wed Apr  3 07:17:42 2013
From: peter.ujfalusi at ti.com (Peter Ujfalusi)
Date: Wed, 3 Apr 2013 13:17:42 +0200
Subject: [RFC v2] dmaengine: omap-dma: Start DMA without delay for cyclic
 channels
Message-ID: <1364987862-14597-1-git-send-email-peter.ujfalusi@ti.com>

cyclic DMA is only used by audio which needs DMA to be started without a
delay.
If the DMA for audio is started using the tasklet we experience random
channel switch (to be more precise: channel shift).

Reported-by: Peter Meerwald <pmeerw at pmeerw.net>
Signed-off-by: Peter Ujfalusi <peter.ujfalusi at ti.com>
---
Hi Russell,

Instead of removing the tasklet we can identify the DMA channel used by audio
based on the cyclic flag of the channel.
I think this can be used as a short term solution to fix the audio channel shift
issue and later when we have the dynamic DMA channel allocation we can adjust
the code.

Regards,
Peter

 drivers/dma/omap-dma.c | 20 ++++++++++++++------
 1 file changed, 14 insertions(+), 6 deletions(-)

diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
index 2ea3d7e..ec3fc4f 100644
--- a/drivers/dma/omap-dma.c
+++ b/drivers/dma/omap-dma.c
@@ -282,12 +282,20 @@ static void omap_dma_issue_pending(struct dma_chan *chan)
 
 	spin_lock_irqsave(&c->vc.lock, flags);
 	if (vchan_issue_pending(&c->vc) && !c->desc) {
-		struct omap_dmadev *d = to_omap_dma_dev(chan->device);
-		spin_lock(&d->lock);
-		if (list_empty(&c->node))
-			list_add_tail(&c->node, &d->pending);
-		spin_unlock(&d->lock);
-		tasklet_schedule(&d->task);
+		/*
+		 * c->cyclic is used only by audio and in this case the DMA need
+		 * to be started without delay.
+		 */
+		if (!c->cyclic) {
+			struct omap_dmadev *d = to_omap_dma_dev(chan->device);
+			spin_lock(&d->lock);
+			if (list_empty(&c->node))
+				list_add_tail(&c->node, &d->pending);
+			spin_unlock(&d->lock);
+			tasklet_schedule(&d->task);
+		} else {
+			omap_dma_start_desc(c);
+		}
 	}
 	spin_unlock_irqrestore(&c->vc.lock, flags);
 }
-- 
1.8.1.5



From daniel.lezcano at linaro.org  Wed Apr  3 07:18:55 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Wed, 03 Apr 2013 13:18:55 +0200
Subject: [PATCH 5/9] ARM: tegra2: cpuidle: change driver initialization
In-Reply-To: <5155BB27.4000405@wwwdotorg.org>
References: <1364553095-25110-1-git-send-email-daniel.lezcano@linaro.org>
 <1364553095-25110-5-git-send-email-daniel.lezcano@linaro.org>
 <5155BB27.4000405@wwwdotorg.org>
Message-ID: <515C101F.1020801@linaro.org>

On 03/29/2013 05:02 PM, Stephen Warren wrote:
> On 03/29/2013 04:31 AM, Daniel Lezcano wrote:
>> Initialize the idle states directly in the driver structure.
>>
>> That prevents extra structure declaration and memcpy at init time.
> 
> Joseph, can you please review/ack patch 5/9 and patch 6/9. Thanks.

Thanks Joseph to review the patches.

Rafael is expecting an Acked-by.

If you are ok, with these patches, is it possible to ack them please ?

Thanks
  -- Daniel


-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From santosh.shilimkar at ti.com  Wed Apr  3 07:24:42 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Wed, 3 Apr 2013 16:54:42 +0530
Subject: [RFC v2] dmaengine: omap-dma: Start DMA without delay for cyclic
 channels
In-Reply-To: <1364987862-14597-1-git-send-email-peter.ujfalusi@ti.com>
References: <1364987862-14597-1-git-send-email-peter.ujfalusi@ti.com>
Message-ID: <515C117A.6060700@ti.com>

On Wednesday 03 April 2013 04:47 PM, Peter Ujfalusi wrote:
> cyclic DMA is only used by audio which needs DMA to be started without a
> delay.
> If the DMA for audio is started using the tasklet we experience random
> channel switch (to be more precise: channel shift).
> 
> Reported-by: Peter Meerwald <pmeerw at pmeerw.net>
> Signed-off-by: Peter Ujfalusi <peter.ujfalusi at ti.com>
> ---
> Hi Russell,
> 
> Instead of removing the tasklet we can identify the DMA channel used by audio
> based on the cyclic flag of the channel.
> I think this can be used as a short term solution to fix the audio channel shift
> issue and later when we have the dynamic DMA channel allocation we can adjust
> the code.
> 
> Regards,
> Peter
> 
>  drivers/dma/omap-dma.c | 20 ++++++++++++++------
>  1 file changed, 14 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
> index 2ea3d7e..ec3fc4f 100644
> --- a/drivers/dma/omap-dma.c
> +++ b/drivers/dma/omap-dma.c
> @@ -282,12 +282,20 @@ static void omap_dma_issue_pending(struct dma_chan *chan)
>  
>  	spin_lock_irqsave(&c->vc.lock, flags);
>  	if (vchan_issue_pending(&c->vc) && !c->desc) {
If you add "!c->cyclic" in above if then you can avoid
indentation change and just have else for cyclic case.

> -		struct omap_dmadev *d = to_omap_dma_dev(chan->device);
> -		spin_lock(&d->lock);
> -		if (list_empty(&c->node))
> -			list_add_tail(&c->node, &d->pending);
> -		spin_unlock(&d->lock);
> -		tasklet_schedule(&d->task);
> +		/*
> +		 * c->cyclic is used only by audio and in this case the DMA need
> +		 * to be started without delay.
> +		 */
> +		if (!c->cyclic) {
> +			struct omap_dmadev *d = to_omap_dma_dev(chan->device);
> +			spin_lock(&d->lock);
> +			if (list_empty(&c->node))
> +				list_add_tail(&c->node, &d->pending);
> +			spin_unlock(&d->lock);
> +			tasklet_schedule(&d->task);
> +		} else {
> +			omap_dma_start_desc(c);
> +		}
>  	}
>  	spin_unlock_irqrestore(&c->vc.lock, flags);
>  }
> 



From josephl at nvidia.com  Wed Apr  3 07:23:59 2013
From: josephl at nvidia.com (Joseph Lo)
Date: Wed, 3 Apr 2013 19:23:59 +0800
Subject: [PATCH 5/9] ARM: tegra2: cpuidle: change driver initialization
In-Reply-To: <515C101F.1020801@linaro.org>
References: <1364553095-25110-1-git-send-email-daniel.lezcano@linaro.org>
 <1364553095-25110-5-git-send-email-daniel.lezcano@linaro.org>
 <5155BB27.4000405@wwwdotorg.org>  <515C101F.1020801@linaro.org>
Message-ID: <1364988239.16957.78.camel@jlo-ubuntu-64.nvidia.com>

On Wed, 2013-04-03 at 19:18 +0800, Daniel Lezcano wrote:
> On 03/29/2013 05:02 PM, Stephen Warren wrote:
> > On 03/29/2013 04:31 AM, Daniel Lezcano wrote:
> >> Initialize the idle states directly in the driver structure.
> >>
> >> That prevents extra structure declaration and memcpy at init time.
> > 
> > Joseph, can you please review/ack patch 5/9 and patch 6/9. Thanks.
> 
> Thanks Joseph to review the patches.
> 
> Rafael is expecting an Acked-by.
> 
> If you are ok, with these patches, is it possible to ack them please ?
> 
OK.

The 5/9 and 6/9 of this series.
Acked-by: Joseph Lo <josephl at nvidia.com>

Thanks,
Joseph
> 
> 




From stefano.stabellini at eu.citrix.com  Wed Apr  3 07:28:31 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Wed, 3 Apr 2013 12:28:31 +0100
Subject: [PATCH v5 3/3] xen/arm: introduce xen_early_init, use PSCI on xen
In-Reply-To: <alpine.LFD.2.03.1304021325230.1171@syhkavp.arg>
References: <alpine.DEB.2.02.1304021700380.5078@kaball.uk.xensource.com>
 <1364919374-7836-3-git-send-email-stefano.stabellini@eu.citrix.com>
 <alpine.LFD.2.03.1304021325230.1171@syhkavp.arg>
Message-ID: <alpine.DEB.2.02.1304031217310.5078@kaball.uk.xensource.com>

On Tue, 2 Apr 2013, Nicolas Pitre wrote:
> On Tue, 2 Apr 2013, Stefano Stabellini wrote:
> 
> > Split xen_guest_init in two functions, one of them (xen_early_init) is
> > going to be called very early from setup_arch.
> > 
> > Change machine_desc->smp_init to xen_smp_init if Xen is present on the
> > platform. xen_smp_init just sets smp_ops to psci_smp_ops.
> > 
> > Introduce a dependency for ARM_PSCI in XEN.
> 
> The Kconfig stuff should be more understandable to "normal" users 
> configuring the kernel.  Hence it might make more sense for Xen to 
> select PSCI rather than making it a prerequisite.

You are right, I'll do that.


> [...]
> > @@ -176,27 +178,30 @@ static int __init xen_secondary_init(unsigned int cpu)
> >  	return 0;
> >  }
> >  
> > +static void __init xen_smp_init(void)
> > +{
> > +	if (psci_smp_available())
> > +		smp_set_ops(&psci_smp_ops);
> > +}
> > +
> 
> I still don't understand why you need to do this.  Why can't you just 
> rely on the next priority which is to set PSCI ops by default if 
> available?  Using this hook for Xen doesn't look justified. As it is, 
> you break MCPM.
> 
> As I explained to you, MCPM will end up using PSCI as well when 
> available, which I think should be sufficient for your concern.

The smp_init hook is not limited to MCPM or the versatile express
platform. It's a generic hook that can be used by any platform and can
override the platform smp_ops or the psci_smp_ops depending on platform
specific configurations.

Configurations that I am pretty sure won't be available on Xen anyway,
while I am certain that using psci_smp_ops would work.

It seems to me that relying on the fact that only versatile express and
only MCPM use smp_init, even though it might work today, it's very
fragile and could break tomorrow without any of us noticing.


From stefano.stabellini at eu.citrix.com  Wed Apr  3 07:29:31 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Wed, 3 Apr 2013 12:29:31 +0100
Subject: [PATCH v5 1/3] arm: introduce psci_smp_ops
In-Reply-To: <alpine.LFD.2.03.1304021336270.1171@syhkavp.arg>
References: <alpine.DEB.2.02.1304021700380.5078@kaball.uk.xensource.com>
 <1364919374-7836-1-git-send-email-stefano.stabellini@eu.citrix.com>
 <alpine.LFD.2.03.1304021336270.1171@syhkavp.arg>
Message-ID: <alpine.DEB.2.02.1304031218520.5078@kaball.uk.xensource.com>

On Tue, 2 Apr 2013, Nicolas Pitre wrote:
> On Tue, 2 Apr 2013, Stefano Stabellini wrote:
> 
> > Rename virt_smp_ops to psci_smp_ops and move them to arch/arm/kernel/psci_smp.c.
> > Remove mach-virt/platsmp.c, now unused.
> > Compile psci_smp if CONFIG_ARM_PSCI and CONFIG_SMP.
> > 
> > Add a cpu_die smp_op based on psci_ops.cpu_off.
> > 
> > Initialize PSCI before setting smp_ops in setup_arch.
> > Use psci_smp_ops if the platform doesn't provide its own smp_ops.
> 
> [...]
> 
> > @@ -766,9 +767,13 @@ void __init setup_arch(char **cmdline_p)
> >  	unflatten_device_tree();
> >  
> >  	arm_dt_init_cpu_maps();
> > +	psci_init();
> >  #ifdef CONFIG_SMP
> >  	if (is_smp()) {
> > -		smp_set_ops(mdesc->smp);
> > +		if (mdesc->smp)
> > +			smp_set_ops(mdesc->smp);
> > +		else if (psci_smp_available())
> > +			smp_set_ops(&psci_smp_ops);
> 
> Didn't we agree to do this the other way around, i.e. 
> 
> 	if (psci_smp_available())
> 		smp_set_ops(&psci_smp_ops);
> 	else if (mdesc->smp)
> 		smp_set_ops(mdesc->smp);
> 
> ?

Yes, we agreed about it.
However that change was in a separate patch that I have dropped from
this version of the series, that is why it is missing.

I'll add back the change but I'll keep it in a separate patch to leave
the original one, now acked twice and reviewed once, untouched.


> This way you won't need the ->smp_init for Xen and that won't conflict 
> with MCPM.

See my other reply on the subject.


From girishks2000 at gmail.com  Wed Apr  3 07:30:04 2013
From: girishks2000 at gmail.com (Girish KS)
Date: Wed, 3 Apr 2013 17:00:04 +0530
Subject: [PATCH V3 2/5] spi: s3c64xx: added support for polling mode
In-Reply-To: <20130401131207.GI18636@opensource.wolfsonmicro.com>
References: <1363157014-9615-1-git-send-email-ks.giri@samsung.com>
 <1363157014-9615-3-git-send-email-ks.giri@samsung.com>
 <20130401131207.GI18636@opensource.wolfsonmicro.com>
Message-ID: <CAKrE-KdWe6aCg0p99BFEeQP-P2nwvdhs2itH3XnHsJMCUjWPAA@mail.gmail.com>

On Mon, Apr 1, 2013 at 6:42 PM, Mark Brown
<broonie at opensource.wolfsonmicro.com> wrote:
> On Wed, Mar 13, 2013 at 12:13:31PM +0530, Girish K S wrote:
>
>> Some SoC's that adopt this controller might not have have dma
>> interface. This patch adds support for complete polling mode
>> and gives flexibity for the user to select poll/dma mode.
>
> Ouch, that sounds like a regression.
>
>> @@ -419,6 +422,27 @@ static inline void enable_cs(struct s3c64xx_spi_driver_data *sdd,
>>
>>       cs = spi->controller_data;
>>       gpio_set_value(cs->line, spi->mode & SPI_CS_HIGH ? 1 : 0);
>> +
>> +     /* Start the signals */
>> +     writel(0, sdd->regs + S3C64XX_SPI_SLAVE_SEL);
>> +}
>> +
>
> This looks odd and not obviously related to the rest of the change -
> does it belong as part of some of your other commits adding support for
> using the controller /CS functionality?  In general it feels like this
> ought to be broken down a bit - there's some refactoring as well as the
> new functionality.

it is part of this patch. It is just the movement of slave active bit from
s3c64xx_spi_config to enable_cs and disable_cs function respectively.
It is not part of chip select gpio patch.

>
>> +static u32 wait_for_timeout(struct s3c64xx_spi_driver_data *sdd,
>> +                                     int timeout_ms)
>> +{
>> +     void __iomem *regs = sdd->regs;
>> +     unsigned long val;
>> +     u32 status;
>> +     /* max fifo depth available */
>> +     u32 max_fifo = (FIFO_LVL_MASK(sdd) >> 1) + 1;
>> +
>> +     val = msecs_to_loops(timeout_ms);
>> +     do {
>> +             status = readl(regs + S3C64XX_SPI_STATUS);
>> +     } while (RX_FIFO_LVL(status, sdd) < max_fifo && --val);
>> +
>> +     /* return the actual received data length */
>> +     return RX_FIFO_LVL(status, sdd);
>
> This is really wait_for_fifo_empty_with_timeout() isn't it?  It feels
> like there ought to be at least a cpu_relax() in the busy wait too.

This code existed in the older version, I just made it as a separate function.
Will check it and make necessary change.

>
>> +             /*
>> +              * If the receive length is bigger than the controller fifo
>> +              * size, calculate the loops and read the fifo as many times.
>> +              * loops = length / max fifo size (calculated by using the
>> +              * fifo mask).
>> +              * For any size less than the fifo size the below code is
>> +              * executed atleast once.
>> +              */
>> +             loops = xfer->len / ((FIFO_LVL_MASK(sdd) >> 1) + 1);
>> +             buf = xfer->rx_buf;
>> +             do{
>
> Coding style.

Will change it

>
>> -     if (!sdd->pdev->dev.of_node) {
>> +     if (!sdd->pdev->dev.of_node && !is_polling(sdd)) {
>>               res = platform_get_resource(pdev, IORESOURCE_DMA,  0);
>>               if (!res) {
>>                       dev_err(&pdev->dev, "Unable to get SPI tx dma "
>
> It seems like it'd be sensible to also handle failure to get the DMA
> resource by going into polling mode.

There are 2 cases currently i have identified and handled,
1. The SoC's dont have DMA support for spi controller. For such SoC's we
 would not add the dma resource in the spi dts node. In this case the probe
 would return error if failure for DMA resuorce is handled.

2. The SoC has a DMA support for SPI controller, but due to some x
reason(H/W bug),
 the driver would force polling mode by enabling
S3C64XX_SPI_QUIRK_POLL in driver
 data. For such SoC's there would be a dma entry in the spi controller
dts node, and
 probe can handle failure for DMA resource successfully.

To handle above both situations successfully if
(!sdd->pdev->dev.of_node && !is_polling(sdd)) is used.


From josephl at nvidia.com  Wed Apr  3 07:31:26 2013
From: josephl at nvidia.com (Joseph Lo)
Date: Wed, 3 Apr 2013 19:31:26 +0800
Subject: [PATCH V4 0/2] ARM: tegra: add clock source of PMC
Message-ID: <1364988688-24613-1-git-send-email-josephl@nvidia.com>

This series add DT bindings for the source clocks of PMC. Then
getting the clok from DT and moving related code to PMC driver.

V4:
* re-organize the patch
* add the DT properties for Tegra114
V3:
* add the DT bindings for the clock source of PMC
* getting the clock from DT

Joseph Lo (2):
  ARM: dt: tegra: add clock source of PMC
  ARM: tegra: moving the CPU power timer function to PMC driver

 .../bindings/arm/tegra/nvidia,tegra20-pmc.txt      | 29 ++++++++++++++++-
 arch/arm/boot/dts/tegra114-dalmore.dts             | 13 ++++++++
 arch/arm/boot/dts/tegra114-pluto.dts               | 13 ++++++++
 arch/arm/boot/dts/tegra114.dtsi                    |  2 ++
 arch/arm/boot/dts/tegra20-colibri-512.dtsi         | 13 ++++++++
 arch/arm/boot/dts/tegra20-harmony.dts              | 13 ++++++++
 arch/arm/boot/dts/tegra20-paz00.dts                | 13 ++++++++
 arch/arm/boot/dts/tegra20-seaboard.dts             | 13 ++++++++
 arch/arm/boot/dts/tegra20-tamonten.dtsi            | 13 ++++++++
 arch/arm/boot/dts/tegra20-trimslice.dts            | 13 ++++++++
 arch/arm/boot/dts/tegra20-ventana.dts              | 13 ++++++++
 arch/arm/boot/dts/tegra20-whistler.dts             | 13 ++++++++
 arch/arm/boot/dts/tegra20.dtsi                     |  2 ++
 arch/arm/boot/dts/tegra30-beaver.dts               | 13 ++++++++
 arch/arm/boot/dts/tegra30-cardhu.dtsi              | 13 ++++++++
 arch/arm/boot/dts/tegra30.dtsi                     |  2 ++
 arch/arm/mach-tegra/common.c                       |  2 +-
 arch/arm/mach-tegra/pm.c                           | 37 +---------------------
 arch/arm/mach-tegra/pmc.c                          | 35 ++++++++++++++++++++
 arch/arm/mach-tegra/pmc.h                          |  4 +++
 20 files changed, 231 insertions(+), 38 deletions(-)

-- 
1.8.2



From josephl at nvidia.com  Wed Apr  3 07:31:27 2013
From: josephl at nvidia.com (Joseph Lo)
Date: Wed, 3 Apr 2013 19:31:27 +0800
Subject: [PATCH V4 1/2] ARM: dt: tegra: add clock source of PMC
In-Reply-To: <1364988688-24613-1-git-send-email-josephl@nvidia.com>
References: <1364988688-24613-1-git-send-email-josephl@nvidia.com>
Message-ID: <1364988688-24613-2-git-send-email-josephl@nvidia.com>

Adding the bindings of the clock source of PMC in DT.

Signed-off-by: Joseph Lo <josephl at nvidia.com>
---
V4:
* move the c code to the patch 2/2 of this series
* the clock related define should be required properties
* fix the oreder of clocks node in DTS file
* add Tegra114 support
V3:
* add clk32k_in as one of the PMC clock source.
* add a fixed clock of clk32k_in for Tegra20 & Tegra30
* add binding document for the clock source of PMC
* get the clock from DT by of_get_clk_by_name()
* fix WARN_ON_ONCE to WARN_ON when there is no clock define in DT
V2:
* new in this series
---
 .../bindings/arm/tegra/nvidia,tegra20-pmc.txt      | 29 +++++++++++++++++++++-
 arch/arm/boot/dts/tegra114-dalmore.dts             | 13 ++++++++++
 arch/arm/boot/dts/tegra114-pluto.dts               | 13 ++++++++++
 arch/arm/boot/dts/tegra114.dtsi                    |  2 ++
 arch/arm/boot/dts/tegra20-colibri-512.dtsi         | 13 ++++++++++
 arch/arm/boot/dts/tegra20-harmony.dts              | 13 ++++++++++
 arch/arm/boot/dts/tegra20-paz00.dts                | 13 ++++++++++
 arch/arm/boot/dts/tegra20-seaboard.dts             | 13 ++++++++++
 arch/arm/boot/dts/tegra20-tamonten.dtsi            | 13 ++++++++++
 arch/arm/boot/dts/tegra20-trimslice.dts            | 13 ++++++++++
 arch/arm/boot/dts/tegra20-ventana.dts              | 13 ++++++++++
 arch/arm/boot/dts/tegra20-whistler.dts             | 13 ++++++++++
 arch/arm/boot/dts/tegra20.dtsi                     |  2 ++
 arch/arm/boot/dts/tegra30-beaver.dts               | 13 ++++++++++
 arch/arm/boot/dts/tegra30-cardhu.dtsi              | 13 ++++++++++
 arch/arm/boot/dts/tegra30.dtsi                     |  2 ++
 16 files changed, 190 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt
index b5846e2..ee529b1 100644
--- a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt
+++ b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt
@@ -1,9 +1,15 @@
 NVIDIA Tegra Power Management Controller (PMC)
 
-Properties:
+Required properties:
 - name : Should be pmc
 - compatible : Should contain "nvidia,tegra<chip>-pmc".
 - reg : Offset and length of the register set for the device
+- clocks : Must contain an entry for each entry in clock-names.
+- clock-names : Must include the following entries:
+  "pclk" (The Tegra clock of that name),
+  "clk32k_in" (The 32KHz clock input to Tegra).
+
+Optional properties:
 - nvidia,invert-interrupt : If present, inverts the PMU interrupt signal.
   The PMU is an external Power Management Unit, whose interrupt output
   signal is fed into the PMC. This signal is optionally inverted, and then
@@ -12,8 +18,29 @@ Properties:
 
 Example:
 
+/ SoC dts including file
 pmc at 7000f400 {
 	compatible = "nvidia,tegra20-pmc";
 	reg = <0x7000e400 0x400>;
+	clocks = <&tegra_car 110>, <&clk32k_in>;
+	clock-names = "pclk", "clk32k_in";
 	nvidia,invert-interrupt;
 };
+
+/ Tegra board dts file
+{
+	...
+	clocks {
+		compatible = "simple-bus";
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		clk32k_in: clock {
+			compatible = "fixed-clock";
+			reg=<0>;
+			#clock-cells = <0>;
+			clock-frequency = <32768>;
+		};
+	};
+	...
+};
diff --git a/arch/arm/boot/dts/tegra114-dalmore.dts b/arch/arm/boot/dts/tegra114-dalmore.dts
index ad27ea7..4aa2897 100644
--- a/arch/arm/boot/dts/tegra114-dalmore.dts
+++ b/arch/arm/boot/dts/tegra114-dalmore.dts
@@ -839,6 +839,19 @@
 		status = "okay";
 	};
 
+	clocks {
+		compatible = "simple-bus";
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		clk32k_in: clock {
+			compatible = "fixed-clock";
+			reg=<0>;
+			#clock-cells = <0>;
+			clock-frequency = <32768>;
+		};
+	};
+
 	regulators {
 		compatible = "simple-bus";
 		#address-cells = <1>;
diff --git a/arch/arm/boot/dts/tegra114-pluto.dts b/arch/arm/boot/dts/tegra114-pluto.dts
index 9bea8f5..5deb869 100644
--- a/arch/arm/boot/dts/tegra114-pluto.dts
+++ b/arch/arm/boot/dts/tegra114-pluto.dts
@@ -18,4 +18,17 @@
 	pmc {
 		nvidia,invert-interrupt;
 	};
+
+	clocks {
+		compatible = "simple-bus";
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		clk32k_in: clock {
+			compatible = "fixed-clock";
+			reg=<0>;
+			#clock-cells = <0>;
+			clock-frequency = <32768>;
+		};
+	};
 };
diff --git a/arch/arm/boot/dts/tegra114.dtsi b/arch/arm/boot/dts/tegra114.dtsi
index 5302044..4eb87b8 100644
--- a/arch/arm/boot/dts/tegra114.dtsi
+++ b/arch/arm/boot/dts/tegra114.dtsi
@@ -301,6 +301,8 @@
 	pmc {
 		compatible = "nvidia,tegra114-pmc";
 		reg = <0x7000e400 0x400>;
+		clocks = <&tegra_car 261>, <&clk32k_in>;
+		clock-names = "pclk", "clk32k_in";
 	};
 
 	iommu {
diff --git a/arch/arm/boot/dts/tegra20-colibri-512.dtsi b/arch/arm/boot/dts/tegra20-colibri-512.dtsi
index 79af149..d953ccc 100644
--- a/arch/arm/boot/dts/tegra20-colibri-512.dtsi
+++ b/arch/arm/boot/dts/tegra20-colibri-512.dtsi
@@ -447,6 +447,19 @@
 		cd-gpios = <&gpio 23 1>; /* gpio PC7 */
 	};
 
+	clocks {
+		compatible = "simple-bus";
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		clk32k_in: clock {
+			compatible = "fixed-clock";
+			reg=<0>;
+			#clock-cells = <0>;
+			clock-frequency = <32768>;
+		};
+	};
+
 	sound {
 		compatible = "nvidia,tegra-audio-wm9712-colibri_t20",
 			         "nvidia,tegra-audio-wm9712";
diff --git a/arch/arm/boot/dts/tegra20-harmony.dts b/arch/arm/boot/dts/tegra20-harmony.dts
index 5fb0888..2c4da87 100644
--- a/arch/arm/boot/dts/tegra20-harmony.dts
+++ b/arch/arm/boot/dts/tegra20-harmony.dts
@@ -451,6 +451,19 @@
 		bus-width = <8>;
 	};
 
+	clocks {
+		compatible = "simple-bus";
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		clk32k_in: clock {
+			compatible = "fixed-clock";
+			reg=<0>;
+			#clock-cells = <0>;
+			clock-frequency = <32768>;
+		};
+	};
+
 	kbc {
 		status = "okay";
 		nvidia,debounce-delay-ms = <2>;
diff --git a/arch/arm/boot/dts/tegra20-paz00.dts b/arch/arm/boot/dts/tegra20-paz00.dts
index 43fd28b..c421db4 100644
--- a/arch/arm/boot/dts/tegra20-paz00.dts
+++ b/arch/arm/boot/dts/tegra20-paz00.dts
@@ -447,6 +447,19 @@
 		bus-width = <8>;
 	};
 
+	clocks {
+		compatible = "simple-bus";
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		clk32k_in: clock {
+			compatible = "fixed-clock";
+			reg=<0>;
+			#clock-cells = <0>;
+			clock-frequency = <32768>;
+		};
+	};
+
 	gpio-keys {
 		compatible = "gpio-keys";
 
diff --git a/arch/arm/boot/dts/tegra20-seaboard.dts b/arch/arm/boot/dts/tegra20-seaboard.dts
index 4f810a5..b8f0400 100644
--- a/arch/arm/boot/dts/tegra20-seaboard.dts
+++ b/arch/arm/boot/dts/tegra20-seaboard.dts
@@ -595,6 +595,19 @@
 		bus-width = <8>;
 	};
 
+	clocks {
+		compatible = "simple-bus";
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		clk32k_in: clock {
+			compatible = "fixed-clock";
+			reg=<0>;
+			#clock-cells = <0>;
+			clock-frequency = <32768>;
+		};
+	};
+
 	gpio-keys {
 		compatible = "gpio-keys";
 
diff --git a/arch/arm/boot/dts/tegra20-tamonten.dtsi b/arch/arm/boot/dts/tegra20-tamonten.dtsi
index 6e9d91f..c190257 100644
--- a/arch/arm/boot/dts/tegra20-tamonten.dtsi
+++ b/arch/arm/boot/dts/tegra20-tamonten.dtsi
@@ -471,6 +471,19 @@
 		status = "okay";
 	};
 
+	clocks {
+		compatible = "simple-bus";
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		clk32k_in: clock {
+			compatible = "fixed-clock";
+			reg=<0>;
+			#clock-cells = <0>;
+			clock-frequency = <32768>;
+		};
+	};
+
 	regulators {
 		compatible = "simple-bus";
 
diff --git a/arch/arm/boot/dts/tegra20-trimslice.dts b/arch/arm/boot/dts/tegra20-trimslice.dts
index 955bf49..51b3a44 100644
--- a/arch/arm/boot/dts/tegra20-trimslice.dts
+++ b/arch/arm/boot/dts/tegra20-trimslice.dts
@@ -330,6 +330,19 @@
 		bus-width = <4>;
 	};
 
+	clocks {
+		compatible = "simple-bus";
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		clk32k_in: clock {
+			compatible = "fixed-clock";
+			reg=<0>;
+			#clock-cells = <0>;
+			clock-frequency = <32768>;
+		};
+	};
+
 	poweroff {
 		compatible = "gpio-poweroff";
 		gpios = <&gpio 191 1>; /* gpio PX7, active low */
diff --git a/arch/arm/boot/dts/tegra20-ventana.dts b/arch/arm/boot/dts/tegra20-ventana.dts
index 3f8ae10..7095e96 100644
--- a/arch/arm/boot/dts/tegra20-ventana.dts
+++ b/arch/arm/boot/dts/tegra20-ventana.dts
@@ -531,6 +531,19 @@
 		bus-width = <8>;
 	};
 
+	clocks {
+		compatible = "simple-bus";
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		clk32k_in: clock {
+			compatible = "fixed-clock";
+			reg=<0>;
+			#clock-cells = <0>;
+			clock-frequency = <32768>;
+		};
+	};
+
 	regulators {
 		compatible = "simple-bus";
 		#address-cells = <1>;
diff --git a/arch/arm/boot/dts/tegra20-whistler.dts b/arch/arm/boot/dts/tegra20-whistler.dts
index 87e2d85..99746c6 100644
--- a/arch/arm/boot/dts/tegra20-whistler.dts
+++ b/arch/arm/boot/dts/tegra20-whistler.dts
@@ -520,6 +520,19 @@
 		bus-width = <8>;
 	};
 
+	clocks {
+		compatible = "simple-bus";
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		clk32k_in: clock {
+			compatible = "fixed-clock";
+			reg=<0>;
+			#clock-cells = <0>;
+			clock-frequency = <32768>;
+		};
+	};
+
 	kbc {
 		status = "okay";
 		nvidia,debounce-delay-ms = <20>;
diff --git a/arch/arm/boot/dts/tegra20.dtsi b/arch/arm/boot/dts/tegra20.dtsi
index 26c1134..5fc661d 100644
--- a/arch/arm/boot/dts/tegra20.dtsi
+++ b/arch/arm/boot/dts/tegra20.dtsi
@@ -419,6 +419,8 @@
 	pmc {
 		compatible = "nvidia,tegra20-pmc";
 		reg = <0x7000e400 0x400>;
+		clocks = <&tegra_car 110>, <&clk32k_in>;
+		clock-names = "pclk", "clk32k_in";
 	};
 
 	memory-controller at 7000f000 {
diff --git a/arch/arm/boot/dts/tegra30-beaver.dts b/arch/arm/boot/dts/tegra30-beaver.dts
index 0a2cd24..6248b24 100644
--- a/arch/arm/boot/dts/tegra30-beaver.dts
+++ b/arch/arm/boot/dts/tegra30-beaver.dts
@@ -268,6 +268,19 @@
 		bus-width = <8>;
 	};
 
+	clocks {
+		compatible = "simple-bus";
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		clk32k_in: clock {
+			compatible = "fixed-clock";
+			reg=<0>;
+			#clock-cells = <0>;
+			clock-frequency = <32768>;
+		};
+	};
+
 	regulators {
 		compatible = "simple-bus";
 		#address-cells = <1>;
diff --git a/arch/arm/boot/dts/tegra30-cardhu.dtsi b/arch/arm/boot/dts/tegra30-cardhu.dtsi
index 11204e1..7edd51e 100644
--- a/arch/arm/boot/dts/tegra30-cardhu.dtsi
+++ b/arch/arm/boot/dts/tegra30-cardhu.dtsi
@@ -322,6 +322,19 @@
 		bus-width = <8>;
 	};
 
+	clocks {
+		compatible = "simple-bus";
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		clk32k_in: clock {
+			compatible = "fixed-clock";
+			reg=<0>;
+			#clock-cells = <0>;
+			clock-frequency = <32768>;
+		};
+	};
+
 	regulators {
 		compatible = "simple-bus";
 		#address-cells = <1>;
diff --git a/arch/arm/boot/dts/tegra30.dtsi b/arch/arm/boot/dts/tegra30.dtsi
index 6042cc1..15ded60 100644
--- a/arch/arm/boot/dts/tegra30.dtsi
+++ b/arch/arm/boot/dts/tegra30.dtsi
@@ -428,6 +428,8 @@
 	pmc {
 		compatible = "nvidia,tegra30-pmc";
 		reg = <0x7000e400 0x400>;
+		clocks = <&tegra_car 218>, <&clk32k_in>;
+		clock-names = "pclk", "clk32k_in";
 	};
 
 	memory-controller {
-- 
1.8.2



From josephl at nvidia.com  Wed Apr  3 07:31:28 2013
From: josephl at nvidia.com (Joseph Lo)
Date: Wed, 3 Apr 2013 19:31:28 +0800
Subject: [PATCH V4 2/2] ARM: tegra: moving the CPU power timer function to PMC
 driver
In-Reply-To: <1364988688-24613-1-git-send-email-josephl@nvidia.com>
References: <1364988688-24613-1-git-send-email-josephl@nvidia.com>
Message-ID: <1364988688-24613-3-git-send-email-josephl@nvidia.com>

The CPU power timer set up function was related to PMC register. Now moving
it to PMC driver. And it also help to clean up the PM related code later.

The timer was calculated based on the input clock of PMC. In this patch, we
also get the clock from DT.

Signed-off-by: Joseph Lo <josephl at nvidia.com>
---
V4:
* move the c code from previous patch to here
V3:
* no change
V2:
* the PCLK is from DT not hard code
---
 arch/arm/mach-tegra/common.c |  2 +-
 arch/arm/mach-tegra/pm.c     | 37 +------------------------------------
 arch/arm/mach-tegra/pmc.c    | 35 +++++++++++++++++++++++++++++++++++
 arch/arm/mach-tegra/pmc.h    |  4 ++++
 4 files changed, 41 insertions(+), 37 deletions(-)

diff --git a/arch/arm/mach-tegra/common.c b/arch/arm/mach-tegra/common.c
index f0315c9..b02ebe7 100644
--- a/arch/arm/mach-tegra/common.c
+++ b/arch/arm/mach-tegra/common.c
@@ -61,6 +61,7 @@ u32 tegra_uart_config[4] = {
 void __init tegra_dt_init_irq(void)
 {
 	tegra_clocks_init();
+	tegra_pmc_init();
 	tegra_init_irq();
 	irqchip_init();
 }
@@ -100,7 +101,6 @@ void __init tegra_init_early(void)
 	tegra_apb_io_init();
 	tegra_init_fuse();
 	tegra_init_cache();
-	tegra_pmc_init();
 	tegra_powergate_init();
 	tegra_hotplug_init();
 }
diff --git a/arch/arm/mach-tegra/pm.c b/arch/arm/mach-tegra/pm.c
index acacbe8..ef12c0d 100644
--- a/arch/arm/mach-tegra/pm.c
+++ b/arch/arm/mach-tegra/pm.c
@@ -22,7 +22,6 @@
 #include <linux/cpumask.h>
 #include <linux/delay.h>
 #include <linux/cpu_pm.h>
-#include <linux/clk.h>
 #include <linux/err.h>
 #include <linux/clk/tegra.h>
 
@@ -37,52 +36,18 @@
 #include "reset.h"
 #include "flowctrl.h"
 #include "fuse.h"
+#include "pmc.h"
 #include "sleep.h"
 
 #define TEGRA_POWER_CPU_PWRREQ_OE	(1 << 16)  /* CPU pwr req enable */
 
 #define PMC_CTRL		0x0
-#define PMC_CPUPWRGOOD_TIMER	0xc8
-#define PMC_CPUPWROFF_TIMER	0xcc
 
 #ifdef CONFIG_PM_SLEEP
 static DEFINE_SPINLOCK(tegra_lp2_lock);
 static void __iomem *pmc = IO_ADDRESS(TEGRA_PMC_BASE);
-static struct clk *tegra_pclk;
 void (*tegra_tear_down_cpu)(void);
 
-static void set_power_timers(unsigned long us_on, unsigned long us_off)
-{
-	unsigned long long ticks;
-	unsigned long long pclk;
-	unsigned long rate;
-	static unsigned long tegra_last_pclk;
-
-	if (tegra_pclk == NULL) {
-		tegra_pclk = clk_get_sys(NULL, "pclk");
-		WARN_ON(IS_ERR(tegra_pclk));
-	}
-
-	rate = clk_get_rate(tegra_pclk);
-
-	if (WARN_ON_ONCE(rate <= 0))
-		pclk = 100000000;
-	else
-		pclk = rate;
-
-	if ((rate != tegra_last_pclk)) {
-		ticks = (us_on * pclk) + 999999ull;
-		do_div(ticks, 1000000);
-		writel((unsigned long)ticks, pmc + PMC_CPUPWRGOOD_TIMER);
-
-		ticks = (us_off * pclk) + 999999ull;
-		do_div(ticks, 1000000);
-		writel((unsigned long)ticks, pmc + PMC_CPUPWROFF_TIMER);
-		wmb();
-	}
-	tegra_last_pclk = pclk;
-}
-
 /*
  * restore_cpu_complex
  *
diff --git a/arch/arm/mach-tegra/pmc.c b/arch/arm/mach-tegra/pmc.c
index b30e921..faa33e8 100644
--- a/arch/arm/mach-tegra/pmc.c
+++ b/arch/arm/mach-tegra/pmc.c
@@ -16,6 +16,7 @@
  */
 
 #include <linux/kernel.h>
+#include <linux/clk.h>
 #include <linux/io.h>
 #include <linux/of.h>
 #include <linux/of_address.h>
@@ -27,6 +28,9 @@
 #define PMC_REMOVE_CLAMPING		0x34
 #define PMC_PWRGATE_STATUS		0x38
 
+#define PMC_CPUPWRGOOD_TIMER	0xc8
+#define PMC_CPUPWROFF_TIMER	0xcc
+
 #define TEGRA_POWERGATE_PCIE	3
 #define TEGRA_POWERGATE_VDEC	4
 #define TEGRA_POWERGATE_CPU1	9
@@ -43,6 +47,7 @@ static DEFINE_SPINLOCK(tegra_powergate_lock);
 
 static void __iomem *tegra_pmc_base;
 static bool tegra_pmc_invert_interrupt;
+static struct clk *tegra_pclk;
 
 static inline u32 tegra_pmc_readl(u32 reg)
 {
@@ -133,6 +138,34 @@ int tegra_pmc_cpu_remove_clamping(int cpuid)
 	return tegra_pmc_powergate_remove_clamping(id);
 }
 
+#ifdef CONFIG_PM_SLEEP
+void set_power_timers(unsigned long us_on, unsigned long us_off)
+{
+	unsigned long long ticks;
+	unsigned long long pclk;
+	unsigned long rate;
+	static unsigned long tegra_last_pclk;
+
+	rate = clk_get_rate(tegra_pclk);
+	if (WARN_ON_ONCE(rate <= 0))
+		pclk = 100000000;
+	else
+		pclk = rate;
+
+	if ((rate != tegra_last_pclk)) {
+		ticks = (us_on * pclk) + 999999ull;
+		do_div(ticks, 1000000);
+		tegra_pmc_writel((unsigned long)ticks, PMC_CPUPWRGOOD_TIMER);
+
+		ticks = (us_off * pclk) + 999999ull;
+		do_div(ticks, 1000000);
+		tegra_pmc_writel((unsigned long)ticks, PMC_CPUPWROFF_TIMER);
+		wmb();
+	}
+	tegra_last_pclk = pclk;
+}
+#endif
+
 static const struct of_device_id matches[] __initconst = {
 	{ .compatible = "nvidia,tegra114-pmc" },
 	{ .compatible = "nvidia,tegra30-pmc" },
@@ -151,6 +184,8 @@ static void tegra_pmc_parse_dt(void)
 
 	tegra_pmc_invert_interrupt = of_property_read_bool(np,
 				     "nvidia,invert-interrupt");
+	tegra_pclk = of_clk_get_by_name(np, "pclk");
+	WARN_ON(IS_ERR(tegra_pclk));
 }
 
 void __init tegra_pmc_init(void)
diff --git a/arch/arm/mach-tegra/pmc.h b/arch/arm/mach-tegra/pmc.h
index 7d44710..22f16c9 100644
--- a/arch/arm/mach-tegra/pmc.h
+++ b/arch/arm/mach-tegra/pmc.h
@@ -18,6 +18,10 @@
 #ifndef __MACH_TEGRA_PMC_H
 #define __MACH_TEGRA_PMC_H
 
+#ifdef CONFIG_PM_SLEEP
+void set_power_timers(unsigned long us_on, unsigned long us_off);
+#endif
+
 bool tegra_pmc_cpu_is_powered(int cpuid);
 int tegra_pmc_cpu_power_on(int cpuid);
 int tegra_pmc_cpu_remove_clamping(int cpuid);
-- 
1.8.2



From josephl at nvidia.com  Wed Apr  3 07:31:43 2013
From: josephl at nvidia.com (Joseph Lo)
Date: Wed, 3 Apr 2013 19:31:43 +0800
Subject: [PATCH V6 0/9] ARM: tegra: add platform suspend support
Message-ID: <1364988712-24797-1-git-send-email-josephl@nvidia.com>

This series introduces a basic functionality for Tegra to support the
platform suspend and resume.

Note: This series only adds the support for Tegra20 and Tegra30. The
Tegra114 will be supported later.

Verified on Seaboard and Cardhu.

V6:
* add more boards support by dts file

V5:
* some fixes from V4's review comments

V4:
* add tegra_pm_validate_suspend_mode() to validate the suspend mode config
  from DT
* squash the patch below into [4/9] to avoid churn after this series
  [2/3] ARM: tegra: refactor the pmc_pm_set function

V3:
* fix the PMC DT configurations for paz00 board
* add a protection for only support LP2 suspend mode

V2:
* re-order the patch sequence to make sure the suspend function can be
  enabled well after the last patch be merged
* squash the patches that defined the PM bindings for PMC and the
  implementation

Joseph Lo (9):
  gpio: tegra: add gpio wakeup source handling
  ARM: tegra: irq: add wake up handling
  ARM: dt: tegra: add bindings of power management configurations for
    PMC
  ARM: tegra: pm: add platform suspend support
  ARM: dts: tegra: add power gpio keys to DT
  ARM: dts: tegra: whistler: add wakeup source for KBC
  ARM: dts: tegra: add non-removable and keep-power-in-suspend property
    for MMC
  ARM: tegra: config: defconfig update
  ARM: dts: tegra: add the PM configurations of PMC

 .../bindings/arm/tegra/nvidia,tegra20-pmc.txt      |  38 ++++++
 arch/arm/boot/dts/tegra114-dalmore.dts             |   1 +
 arch/arm/boot/dts/tegra20-colibri-512.dtsi         |   9 ++
 arch/arm/boot/dts/tegra20-harmony.dts              |  17 +++
 arch/arm/boot/dts/tegra20-paz00.dts                |   7 ++
 arch/arm/boot/dts/tegra20-seaboard.dts             |   8 ++
 arch/arm/boot/dts/tegra20-tamonten.dtsi            |   6 +
 arch/arm/boot/dts/tegra20-trimslice.dts            |  20 ++++
 arch/arm/boot/dts/tegra20-ventana.dts              |  19 +++
 arch/arm/boot/dts/tegra20-whistler.dts             |  10 ++
 arch/arm/boot/dts/tegra30-beaver.dts               |   8 ++
 arch/arm/boot/dts/tegra30-cardhu-a02.dts           |   1 +
 arch/arm/boot/dts/tegra30-cardhu-a04.dts           |   1 +
 arch/arm/boot/dts/tegra30-cardhu.dtsi              |   8 ++
 arch/arm/configs/tegra_defconfig                   |   1 +
 arch/arm/mach-tegra/common.c                       |   3 +
 arch/arm/mach-tegra/irq.c                          |  96 ++++++++++++++-
 arch/arm/mach-tegra/irq.h                          |   6 +
 arch/arm/mach-tegra/pm.c                           |  93 ++++++++++++--
 arch/arm/mach-tegra/pm.h                           |  15 +++
 arch/arm/mach-tegra/pmc.c                          | 133 ++++++++++++++++++++-
 arch/arm/mach-tegra/pmc.h                          |  12 +-
 drivers/gpio/gpio-tegra.c                          |  21 +++-
 23 files changed, 513 insertions(+), 20 deletions(-)

-- 
1.8.2



From josephl at nvidia.com  Wed Apr  3 07:31:44 2013
From: josephl at nvidia.com (Joseph Lo)
Date: Wed, 3 Apr 2013 19:31:44 +0800
Subject: [PATCH V6 1/9] gpio: tegra: add gpio wakeup source handling
In-Reply-To: <1364988712-24797-1-git-send-email-josephl@nvidia.com>
References: <1364988712-24797-1-git-send-email-josephl@nvidia.com>
Message-ID: <1364988712-24797-2-git-send-email-josephl@nvidia.com>

This patch add the gpio wakeup source handling for the Tegra platform. It
was be done by enabling the irq for the gpio in the gpio controller and
enabling the bank irq of the gpio in the Tegra legacy irq controller when
the system going to suspend.

Based on the work by:
Varun Wadekar <vwadekar at nvidia.com>

Cc: Grant Likely <grant.likely at secretlab.ca>
Cc: Linus Walleij <linus.walleij at linaro.org>
Signed-off-by: Joseph Lo <josephl at nvidia.com>
Acked-by: Linus Walleij <linus.walleij at linaro.org>
---
V6:
* no change
V5:
* no change
V4:
* no change
V3:
* no change
V2:
* no change
---
 drivers/gpio/gpio-tegra.c | 21 +++++++++++++++++++--
 1 file changed, 19 insertions(+), 2 deletions(-)

diff --git a/drivers/gpio/gpio-tegra.c b/drivers/gpio/gpio-tegra.c
index a78a81f..2f1b265 100644
--- a/drivers/gpio/gpio-tegra.c
+++ b/drivers/gpio/gpio-tegra.c
@@ -72,6 +72,7 @@ struct tegra_gpio_bank {
 	u32 oe[4];
 	u32 int_enb[4];
 	u32 int_lvl[4];
+	u32 wake_enb[4];
 #endif
 };
 
@@ -333,15 +334,31 @@ static int tegra_gpio_suspend(struct device *dev)
 			bank->oe[p] = tegra_gpio_readl(GPIO_OE(gpio));
 			bank->int_enb[p] = tegra_gpio_readl(GPIO_INT_ENB(gpio));
 			bank->int_lvl[p] = tegra_gpio_readl(GPIO_INT_LVL(gpio));
+
+			/* Enable gpio irq for wake up source */
+			tegra_gpio_writel(bank->wake_enb[p],
+					  GPIO_INT_ENB(gpio));
 		}
 	}
 	local_irq_restore(flags);
 	return 0;
 }
 
-static int tegra_gpio_wake_enable(struct irq_data *d, unsigned int enable)
+static int tegra_gpio_irq_set_wake(struct irq_data *d, unsigned int enable)
 {
 	struct tegra_gpio_bank *bank = irq_data_get_irq_chip_data(d);
+	int gpio = d->hwirq;
+	u32 port, bit, mask;
+
+	port = GPIO_PORT(gpio);
+	bit = GPIO_BIT(gpio);
+	mask = BIT(bit);
+
+	if (enable)
+		bank->wake_enb[port] |= mask;
+	else
+		bank->wake_enb[port] &= ~mask;
+
 	return irq_set_irq_wake(bank->irq, enable);
 }
 #endif
@@ -353,7 +370,7 @@ static struct irq_chip tegra_gpio_irq_chip = {
 	.irq_unmask	= tegra_gpio_irq_unmask,
 	.irq_set_type	= tegra_gpio_irq_set_type,
 #ifdef CONFIG_PM_SLEEP
-	.irq_set_wake	= tegra_gpio_wake_enable,
+	.irq_set_wake	= tegra_gpio_irq_set_wake,
 #endif
 };
 
-- 
1.8.2



From josephl at nvidia.com  Wed Apr  3 07:31:45 2013
From: josephl at nvidia.com (Joseph Lo)
Date: Wed, 3 Apr 2013 19:31:45 +0800
Subject: [PATCH V6 2/9] ARM: tegra: irq: add wake up handling
In-Reply-To: <1364988712-24797-1-git-send-email-josephl@nvidia.com>
References: <1364988712-24797-1-git-send-email-josephl@nvidia.com>
Message-ID: <1364988712-24797-3-git-send-email-josephl@nvidia.com>

Add the wake up handling for legacy irq controller, and using
IRQCHIP_MASK_ON_SUSPEND for wake irq handling.

Based on the work by:
Varun Wadekar <vwadekar at nvidia.com>

Signed-off-by: Joseph Lo <josephl at nvidia.com>
---
V6:
* no change
V5:
* don't use BUG_ON when irq_nr is not correct in set_wake function
V4:
* no change
V3:
* no change
V2:
* no change
---
 arch/arm/mach-tegra/common.c |  2 +
 arch/arm/mach-tegra/irq.c    | 96 +++++++++++++++++++++++++++++++++++++++++++-
 arch/arm/mach-tegra/irq.h    |  6 +++
 3 files changed, 103 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-tegra/common.c b/arch/arm/mach-tegra/common.c
index b02ebe7..c84505c 100644
--- a/arch/arm/mach-tegra/common.c
+++ b/arch/arm/mach-tegra/common.c
@@ -33,6 +33,7 @@
 #include "common.h"
 #include "fuse.h"
 #include "iomap.h"
+#include "irq.h"
 #include "pmc.h"
 #include "apbio.h"
 #include "sleep.h"
@@ -64,6 +65,7 @@ void __init tegra_dt_init_irq(void)
 	tegra_pmc_init();
 	tegra_init_irq();
 	irqchip_init();
+	tegra_legacy_irq_syscore_init();
 }
 #endif
 
diff --git a/arch/arm/mach-tegra/irq.c b/arch/arm/mach-tegra/irq.c
index 1952e82..0de4eed 100644
--- a/arch/arm/mach-tegra/irq.c
+++ b/arch/arm/mach-tegra/irq.c
@@ -4,7 +4,7 @@
  * Author:
  *	Colin Cross <ccross at android.com>
  *
- * Copyright (C) 2010, NVIDIA Corporation
+ * Copyright (C) 2010,2013, NVIDIA Corporation
  *
  * This software is licensed under the terms of the GNU General Public
  * License version 2, as published by the Free Software Foundation, and
@@ -23,6 +23,7 @@
 #include <linux/io.h>
 #include <linux/of.h>
 #include <linux/irqchip/arm-gic.h>
+#include <linux/syscore_ops.h>
 
 #include "board.h"
 #include "iomap.h"
@@ -43,6 +44,7 @@
 #define ICTLR_COP_IEP_CLASS	0x3c
 
 #define FIRST_LEGACY_IRQ 32
+#define TEGRA_MAX_NUM_ICTLRS	5
 
 #define SGI_MASK 0xFFFF
 
@@ -56,6 +58,15 @@ static void __iomem *ictlr_reg_base[] = {
 	IO_ADDRESS(TEGRA_QUINARY_ICTLR_BASE),
 };
 
+#ifdef CONFIG_PM_SLEEP
+static u32 cop_ier[TEGRA_MAX_NUM_ICTLRS];
+static u32 cop_iep[TEGRA_MAX_NUM_ICTLRS];
+static u32 cpu_ier[TEGRA_MAX_NUM_ICTLRS];
+static u32 cpu_iep[TEGRA_MAX_NUM_ICTLRS];
+
+static u32 ictlr_wake_mask[TEGRA_MAX_NUM_ICTLRS];
+#endif
+
 bool tegra_pending_sgi(void)
 {
 	u32 pending_set;
@@ -125,6 +136,87 @@ static int tegra_retrigger(struct irq_data *d)
 	return 1;
 }
 
+#ifdef CONFIG_PM_SLEEP
+static int tegra_set_wake(struct irq_data *d, unsigned int enable)
+{
+	u32 irq = d->irq;
+	u32 index, mask;
+
+	if (irq < FIRST_LEGACY_IRQ ||
+		irq >= FIRST_LEGACY_IRQ + num_ictlrs * 32)
+		return -EINVAL;
+
+	index = ((irq - FIRST_LEGACY_IRQ) / 32);
+	mask = BIT((irq - FIRST_LEGACY_IRQ) % 32);
+	if (enable)
+		ictlr_wake_mask[index] |= mask;
+	else
+		ictlr_wake_mask[index] &= ~mask;
+
+	return 0;
+}
+
+static int tegra_legacy_irq_suspend(void)
+{
+	unsigned long flags;
+	int i;
+
+	local_irq_save(flags);
+	for (i = 0; i < num_ictlrs; i++) {
+		void __iomem *ictlr = ictlr_reg_base[i];
+		/* Save interrupt state */
+		cpu_ier[i] = readl_relaxed(ictlr + ICTLR_CPU_IER);
+		cpu_iep[i] = readl_relaxed(ictlr + ICTLR_CPU_IEP_CLASS);
+		cop_ier[i] = readl_relaxed(ictlr + ICTLR_COP_IER);
+		cop_iep[i] = readl_relaxed(ictlr + ICTLR_COP_IEP_CLASS);
+
+		/* Disable COP interrupts */
+		writel_relaxed(~0ul, ictlr + ICTLR_COP_IER_CLR);
+
+		/* Disable CPU interrupts */
+		writel_relaxed(~0ul, ictlr + ICTLR_CPU_IER_CLR);
+
+		/* Enable the wakeup sources of ictlr */
+		writel_relaxed(ictlr_wake_mask[i], ictlr + ICTLR_CPU_IER_SET);
+	}
+	local_irq_restore(flags);
+
+	return 0;
+}
+
+static void tegra_legacy_irq_resume(void)
+{
+	unsigned long flags;
+	int i;
+
+	local_irq_save(flags);
+	for (i = 0; i < num_ictlrs; i++) {
+		void __iomem *ictlr = ictlr_reg_base[i];
+		writel_relaxed(cpu_iep[i], ictlr + ICTLR_CPU_IEP_CLASS);
+		writel_relaxed(~0ul, ictlr + ICTLR_CPU_IER_CLR);
+		writel_relaxed(cpu_ier[i], ictlr + ICTLR_CPU_IER_SET);
+		writel_relaxed(cop_iep[i], ictlr + ICTLR_COP_IEP_CLASS);
+		writel_relaxed(~0ul, ictlr + ICTLR_COP_IER_CLR);
+		writel_relaxed(cop_ier[i], ictlr + ICTLR_COP_IER_SET);
+	}
+	local_irq_restore(flags);
+}
+
+static struct syscore_ops tegra_legacy_irq_syscore_ops = {
+	.suspend = tegra_legacy_irq_suspend,
+	.resume = tegra_legacy_irq_resume,
+};
+
+int tegra_legacy_irq_syscore_init(void)
+{
+	register_syscore_ops(&tegra_legacy_irq_syscore_ops);
+
+	return 0;
+}
+#else
+#define tegra_set_wake NULL
+#endif
+
 void __init tegra_init_irq(void)
 {
 	int i;
@@ -150,6 +242,8 @@ void __init tegra_init_irq(void)
 	gic_arch_extn.irq_mask = tegra_mask;
 	gic_arch_extn.irq_unmask = tegra_unmask;
 	gic_arch_extn.irq_retrigger = tegra_retrigger;
+	gic_arch_extn.irq_set_wake = tegra_set_wake;
+	gic_arch_extn.flags = IRQCHIP_MASK_ON_SUSPEND;
 
 	/*
 	 * Check if there is a devicetree present, since the GIC will be
diff --git a/arch/arm/mach-tegra/irq.h b/arch/arm/mach-tegra/irq.h
index 5142649..bc05ce5 100644
--- a/arch/arm/mach-tegra/irq.h
+++ b/arch/arm/mach-tegra/irq.h
@@ -19,4 +19,10 @@
 
 bool tegra_pending_sgi(void);
 
+#ifdef CONFIG_PM_SLEEP
+int tegra_legacy_irq_syscore_init(void);
+#else
+static inline int tegra_legacy_irq_syscore_init(void) { return 0; }
+#endif
+
 #endif
-- 
1.8.2



From josephl at nvidia.com  Wed Apr  3 07:31:46 2013
From: josephl at nvidia.com (Joseph Lo)
Date: Wed, 3 Apr 2013 19:31:46 +0800
Subject: [PATCH V6 3/9] ARM: dt: tegra: add bindings of power management
 configurations for PMC
In-Reply-To: <1364988712-24797-1-git-send-email-josephl@nvidia.com>
References: <1364988712-24797-1-git-send-email-josephl@nvidia.com>
Message-ID: <1364988712-24797-4-git-send-email-josephl@nvidia.com>

The PMC mostly controls the entry and exit of the system from different
sleep modes. Different platform or system may have different configurations.
The power management configurations of PMC is represented as some properties.
The system needs to define the properties when the system supports deep sleep
mode (i.e. suspend).

Cc: Grant Likely <grant.likely at secretlab.ca>
Cc: Rob Herring <rob.herring at calxeda.com>
Cc: devicetree-discuss at lists.ozlabs.org
Signed-off-by: Joseph Lo <josephl at nvidia.com>
---
V6:
* no change
V5:
* fix typos
V4:
* no change
V3:
* fix typos
V2:
* squash the patches that defined the PM bindings for PMC and the
  implementation
* replace the "unsigned long" with "u32" for the variables that are parsed
  from DT
---
 .../bindings/arm/tegra/nvidia,tegra20-pmc.txt      | 38 ++++++++++
 arch/arm/mach-tegra/pmc.c                          | 83 ++++++++++++++++++++++
 arch/arm/mach-tegra/pmc.h                          |  8 +++
 3 files changed, 129 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt
index ee529b1..1608a54 100644
--- a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt
+++ b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt
@@ -1,5 +1,9 @@
 NVIDIA Tegra Power Management Controller (PMC)
 
+The PMC block interacts with an external Power Management Unit. The PMC
+mostly controls the entry and exit of the system from different sleep
+modes. It provides power-gating controllers for SoC and CPU power-islands.
+
 Required properties:
 - name : Should be pmc
 - compatible : Should contain "nvidia,tegra<chip>-pmc".
@@ -15,6 +19,32 @@ Optional properties:
   signal is fed into the PMC. This signal is optionally inverted, and then
   fed into the ARM GIC. The PMC is not involved in the detection or
   handling of this interrupt signal, merely its inversion.
+- nvidia,suspend-mode : The suspend mode that the platform should use.
+  Valid values are 0, 1 and 2:
+  0 (LP0): CPU + Core voltage off and DRAM in self-refresh
+  1 (LP1): CPU voltage off and DRAM in self-refresh
+  2 (LP2): CPU voltage off
+- nvidia,core-power-req-active-high : Boolean, core power request active-high
+- nvidia,sys-clock-req-active-high : Boolean, system clock request active-high
+- nvidia,combined-power-req : Boolean, combined power request for CPU & Core
+- nvidia,cpu-pwr-good-en : Boolean, CPU power good signal (from PMIC to PMC)
+			   is enabled.
+
+Required properties when nvidia,suspend-mode is specified:
+- nvidia,cpu-pwr-good-time : CPU power good time in uS.
+- nvidia,cpu-pwr-off-time : CPU power off time in uS.
+- nvidia,core-pwr-good-time : <Oscillator-stable-time Power-stable-time>
+			      Core power good time in uS.
+- nvidia,core-pwr-off-time : Core power off time in uS.
+
+Required properties when nvidia,suspend-mode=<0>:
+- nvidia,lp0-vec : <start length> Starting address and length of LP0 vector
+  The LP0 vector contains the warm boot code that is executed by AVP when
+  resuming from the LP0 state. The AVP (Audio-Video Processor) is an ARM7
+  processor and always being the first boot processor when chip is power on
+  or resume from deep sleep mode. When the system is resumed from the deep
+  sleep mode, the warm boot code will restore some PLLs, clocks and then
+  bring up CPU0 for resuming the system.
 
 Example:
 
@@ -25,6 +55,14 @@ pmc at 7000f400 {
 	clocks = <&tegra_car 110>, <&clk32k_in>;
 	clock-names = "pclk", "clk32k_in";
 	nvidia,invert-interrupt;
+	nvidia,suspend-mode = <1>;
+	nvidia,cpu-pwr-good-time = <2000>;
+	nvidia,cpu-pwr-off-time = <100>;
+	nvidia,core-pwr-good-time = <3845 3845>;
+	nvidia,core-pwr-off-time = <458>;
+	nvidia,core-power-req-active-high;
+	nvidia,sys-clock-req-active-high;
+	nvidia,lp0-vec = <0xbdffd000 0x2000>;
 };
 
 / Tegra board dts file
diff --git a/arch/arm/mach-tegra/pmc.c b/arch/arm/mach-tegra/pmc.c
index faa33e8..e896826 100644
--- a/arch/arm/mach-tegra/pmc.c
+++ b/arch/arm/mach-tegra/pmc.c
@@ -21,6 +21,8 @@
 #include <linux/of.h>
 #include <linux/of_address.h>
 
+#include "pmc.h"
+
 #define PMC_CTRL			0x0
 #define PMC_CTRL_INTR_LOW		(1 << 17)
 #define PMC_PWRGATE_TOGGLE		0x30
@@ -49,6 +51,22 @@ static void __iomem *tegra_pmc_base;
 static bool tegra_pmc_invert_interrupt;
 static struct clk *tegra_pclk;
 
+struct pmc_pm_data {
+	u32 cpu_good_time;	/* CPU power good time in uS */
+	u32 cpu_off_time;	/* CPU power off time in uS */
+	u32 core_osc_time;	/* Core power good osc time in uS */
+	u32 core_pmu_time;	/* Core power good pmu time in uS */
+	u32 core_off_time;	/* Core power off time in uS */
+	bool corereq_high;	/* Core power request active-high */
+	bool sysclkreq_high;	/* System clock request active-high */
+	bool combined_req;	/* Combined pwr req for CPU & Core */
+	bool cpu_pwr_good_en;	/* CPU power good signal is enabled */
+	u32 lp0_vec_phy_addr;	/* The phy addr of LP0 warm boot code */
+	u32 lp0_vec_size;	/* The size of LP0 warm boot code */
+	enum tegra_suspend_mode suspend_mode;
+};
+static struct pmc_pm_data pmc_pm_data;
+
 static inline u32 tegra_pmc_readl(u32 reg)
 {
 	return readl(tegra_pmc_base + reg);
@@ -176,6 +194,10 @@ static const struct of_device_id matches[] __initconst = {
 static void tegra_pmc_parse_dt(void)
 {
 	struct device_node *np;
+	u32 prop;
+	enum tegra_suspend_mode suspend_mode;
+	u32 core_good_time[2] = {0, 0};
+	u32 lp0_vec[2] = {0, 0};
 
 	np = of_find_matching_node(NULL, matches);
 	BUG_ON(!np);
@@ -186,6 +208,67 @@ static void tegra_pmc_parse_dt(void)
 				     "nvidia,invert-interrupt");
 	tegra_pclk = of_clk_get_by_name(np, "pclk");
 	WARN_ON(IS_ERR(tegra_pclk));
+
+	/* Grabbing the power management configurations */
+	if (of_property_read_u32(np, "nvidia,suspend-mode", &prop)) {
+		suspend_mode = TEGRA_SUSPEND_NONE;
+	} else {
+		switch (prop) {
+		case 0:
+			suspend_mode = TEGRA_SUSPEND_LP0;
+			break;
+		case 1:
+			suspend_mode = TEGRA_SUSPEND_LP1;
+			break;
+		case 2:
+			suspend_mode = TEGRA_SUSPEND_LP2;
+			break;
+		default:
+			suspend_mode = TEGRA_SUSPEND_NONE;
+			break;
+		}
+	}
+
+	if (of_property_read_u32(np, "nvidia,cpu-pwr-good-time", &prop))
+		suspend_mode = TEGRA_SUSPEND_NONE;
+	pmc_pm_data.cpu_good_time = prop;
+
+	if (of_property_read_u32(np, "nvidia,cpu-pwr-off-time", &prop))
+		suspend_mode = TEGRA_SUSPEND_NONE;
+	pmc_pm_data.cpu_off_time = prop;
+
+	if (of_property_read_u32_array(np, "nvidia,core-pwr-good-time",
+			core_good_time, ARRAY_SIZE(core_good_time)))
+		suspend_mode = TEGRA_SUSPEND_NONE;
+	pmc_pm_data.core_osc_time = core_good_time[0];
+	pmc_pm_data.core_pmu_time = core_good_time[1];
+
+	if (of_property_read_u32(np, "nvidia,core-pwr-off-time",
+				 &prop))
+		suspend_mode = TEGRA_SUSPEND_NONE;
+	pmc_pm_data.core_off_time = prop;
+
+	pmc_pm_data.corereq_high = of_property_read_bool(np,
+				"nvidia,core-power-req-active-high");
+
+	pmc_pm_data.sysclkreq_high = of_property_read_bool(np,
+				"nvidia,sys-clock-req-active-high");
+
+	pmc_pm_data.combined_req = of_property_read_bool(np,
+				"nvidia,combined-power-req");
+
+	pmc_pm_data.cpu_pwr_good_en = of_property_read_bool(np,
+				"nvidia,cpu-pwr-good-en");
+
+	if (of_property_read_u32_array(np, "nvidia,lp0-vec", lp0_vec,
+				       ARRAY_SIZE(lp0_vec)))
+		if (suspend_mode == TEGRA_SUSPEND_LP0)
+			suspend_mode = TEGRA_SUSPEND_LP1;
+
+	pmc_pm_data.lp0_vec_phy_addr = lp0_vec[0];
+	pmc_pm_data.lp0_vec_size = lp0_vec[1];
+
+	pmc_pm_data.suspend_mode = suspend_mode;
 }
 
 void __init tegra_pmc_init(void)
diff --git a/arch/arm/mach-tegra/pmc.h b/arch/arm/mach-tegra/pmc.h
index 22f16c9..6bc0fc09 100644
--- a/arch/arm/mach-tegra/pmc.h
+++ b/arch/arm/mach-tegra/pmc.h
@@ -18,6 +18,14 @@
 #ifndef __MACH_TEGRA_PMC_H
 #define __MACH_TEGRA_PMC_H
 
+enum tegra_suspend_mode {
+	TEGRA_SUSPEND_NONE = 0,
+	TEGRA_SUSPEND_LP2,	/* CPU voltage off */
+	TEGRA_SUSPEND_LP1,	/* CPU voltage off, DRAM self-refresh */
+	TEGRA_SUSPEND_LP0,      /* CPU + core voltage off, DRAM self-refresh */
+	TEGRA_MAX_SUSPEND_MODE,
+};
+
 #ifdef CONFIG_PM_SLEEP
 void set_power_timers(unsigned long us_on, unsigned long us_off);
 #endif
-- 
1.8.2



From josephl at nvidia.com  Wed Apr  3 07:31:47 2013
From: josephl at nvidia.com (Joseph Lo)
Date: Wed, 3 Apr 2013 19:31:47 +0800
Subject: [PATCH V6 4/9] ARM: tegra: pm: add platform suspend support
In-Reply-To: <1364988712-24797-1-git-send-email-josephl@nvidia.com>
References: <1364988712-24797-1-git-send-email-josephl@nvidia.com>
Message-ID: <1364988712-24797-5-git-send-email-josephl@nvidia.com>

Adding suspend to RAM support for Tegra platform. There are three suspend
mode for Tegra. The difference were below.

* LP2: CPU voltage off
* LP1: CPU voltage off, DRAM in self-refresh
* LP0: CPU + Core voltage off, DRAM in self-refresh

After this patch, the LP2 suspend mode will be supported.

Signed-off-by: Joseph Lo <josephl at nvidia.com>
---
V6:
* no change
V5:
* move tegra_init_suspend() to tegra_init_late()
* remove useless BUG_ON for the polarity of CPU power request
V4:
* add tegra_pm_validate_suspend_mode() to validate the suspend mode config
  from DT
* squash the patch below that origianl being introduced after this series
  to clean up some PM related code
  [2/3] ARM: tegra: refactor the pmc_pm_set function
V3:
* add a protection for only support LP2 suspend mode
V2:
* add the PM_SLEEP protection for "tegra_init_suspend"
* remove "tegra_suspend_{enter/exit}_lp2"
* refactor the "tegra_pmc_pm_set" for non-used parameter
* replace "unsigned long" with "u32" for tegra_pmc_get_cpu_time
---
 arch/arm/mach-tegra/common.c |  1 +
 arch/arm/mach-tegra/pm.c     | 93 +++++++++++++++++++++++++++++++++++++-------
 arch/arm/mach-tegra/pm.h     | 15 +++++++
 arch/arm/mach-tegra/pmc.c    | 50 ++++++++++++++++++++++--
 arch/arm/mach-tegra/pmc.h    |  4 +-
 5 files changed, 146 insertions(+), 17 deletions(-)

diff --git a/arch/arm/mach-tegra/common.c b/arch/arm/mach-tegra/common.c
index c84505c..eb1f3c8 100644
--- a/arch/arm/mach-tegra/common.c
+++ b/arch/arm/mach-tegra/common.c
@@ -109,5 +109,6 @@ void __init tegra_init_early(void)
 
 void __init tegra_init_late(void)
 {
+	tegra_init_suspend();
 	tegra_powergate_debugfs_init();
 }
diff --git a/arch/arm/mach-tegra/pm.c b/arch/arm/mach-tegra/pm.c
index ef12c0d..14957ff 100644
--- a/arch/arm/mach-tegra/pm.c
+++ b/arch/arm/mach-tegra/pm.c
@@ -22,6 +22,7 @@
 #include <linux/cpumask.h>
 #include <linux/delay.h>
 #include <linux/cpu_pm.h>
+#include <linux/suspend.h>
 #include <linux/err.h>
 #include <linux/clk/tegra.h>
 
@@ -38,14 +39,10 @@
 #include "fuse.h"
 #include "pmc.h"
 #include "sleep.h"
-
-#define TEGRA_POWER_CPU_PWRREQ_OE	(1 << 16)  /* CPU pwr req enable */
-
-#define PMC_CTRL		0x0
+#include "pmc.h"
 
 #ifdef CONFIG_PM_SLEEP
 static DEFINE_SPINLOCK(tegra_lp2_lock);
-static void __iomem *pmc = IO_ADDRESS(TEGRA_PMC_BASE);
 void (*tegra_tear_down_cpu)(void);
 
 /*
@@ -140,14 +137,7 @@ static int tegra_sleep_cpu(unsigned long v2p)
 
 void tegra_idle_lp2_last(u32 cpu_on_time, u32 cpu_off_time)
 {
-	u32 mode;
-
-	/* Only the last cpu down does the final suspend steps */
-	mode = readl(pmc + PMC_CTRL);
-	mode |= TEGRA_POWER_CPU_PWRREQ_OE;
-	writel(mode, pmc + PMC_CTRL);
-
-	set_power_timers(cpu_on_time, cpu_off_time);
+	tegra_pmc_pm_set(TEGRA_SUSPEND_LP2);
 
 	cpu_cluster_pm_enter();
 	suspend_cpu_complex();
@@ -157,4 +147,81 @@ void tegra_idle_lp2_last(u32 cpu_on_time, u32 cpu_off_time)
 	restore_cpu_complex();
 	cpu_cluster_pm_exit();
 }
+
+enum tegra_suspend_mode tegra_pm_validate_suspend_mode(
+				enum tegra_suspend_mode mode)
+{
+	/* Tegra114 didn't support any suspending mode yet. */
+	if (tegra_chip_id == TEGRA114)
+		return TEGRA_SUSPEND_NONE;
+
+	/*
+	 * The Tegra devices only support suspending to LP2 currently.
+	 */
+	if (mode > TEGRA_SUSPEND_LP2)
+		return TEGRA_SUSPEND_LP2;
+
+	return mode;
+}
+
+static const char *lp_state[TEGRA_MAX_SUSPEND_MODE] = {
+	[TEGRA_SUSPEND_NONE] = "none",
+	[TEGRA_SUSPEND_LP2] = "LP2",
+	[TEGRA_SUSPEND_LP1] = "LP1",
+	[TEGRA_SUSPEND_LP0] = "LP0",
+};
+
+static int __cpuinit tegra_suspend_enter(suspend_state_t state)
+{
+	enum tegra_suspend_mode mode = tegra_pmc_get_suspend_mode();
+
+	if (WARN_ON(mode < TEGRA_SUSPEND_NONE ||
+		    mode >= TEGRA_MAX_SUSPEND_MODE))
+		return -EINVAL;
+
+	pr_info("Entering suspend state %s\n", lp_state[mode]);
+
+	tegra_pmc_pm_set(mode);
+
+	local_fiq_disable();
+
+	suspend_cpu_complex();
+	switch (mode) {
+	case TEGRA_SUSPEND_LP2:
+		tegra_set_cpu_in_lp2(0);
+		break;
+	default:
+		break;
+	}
+
+	cpu_suspend(PHYS_OFFSET - PAGE_OFFSET, &tegra_sleep_cpu);
+
+	switch (mode) {
+	case TEGRA_SUSPEND_LP2:
+		tegra_clear_cpu_in_lp2(0);
+		break;
+	default:
+		break;
+	}
+	restore_cpu_complex();
+
+	local_fiq_enable();
+
+	return 0;
+}
+
+static const struct platform_suspend_ops tegra_suspend_ops = {
+	.valid		= suspend_valid_only_mem,
+	.enter		= tegra_suspend_enter,
+};
+
+void __init tegra_init_suspend(void)
+{
+	if (tegra_pmc_get_suspend_mode() == TEGRA_SUSPEND_NONE)
+		return;
+
+	tegra_pmc_suspend_init();
+
+	suspend_set_ops(&tegra_suspend_ops);
+}
 #endif
diff --git a/arch/arm/mach-tegra/pm.h b/arch/arm/mach-tegra/pm.h
index 787335c..73a45f1 100644
--- a/arch/arm/mach-tegra/pm.h
+++ b/arch/arm/mach-tegra/pm.h
@@ -21,6 +21,8 @@
 #ifndef _MACH_TEGRA_PM_H_
 #define _MACH_TEGRA_PM_H_
 
+#include "pmc.h"
+
 extern unsigned long l2x0_saved_regs_addr;
 
 void save_cpu_arch_register(void);
@@ -32,4 +34,17 @@ bool tegra_set_cpu_in_lp2(int phy_cpu_id);
 void tegra_idle_lp2_last(u32 cpu_on_time, u32 cpu_off_time);
 extern void (*tegra_tear_down_cpu)(void);
 
+#ifdef CONFIG_PM_SLEEP
+enum tegra_suspend_mode tegra_pm_validate_suspend_mode(
+				enum tegra_suspend_mode mode);
+void tegra_init_suspend(void);
+#else
+enum tegra_suspend_mode tegra_pm_validate_suspend_mode(
+				enum tegra_suspend_mode mode)
+{
+	return TEGRA_SUSPEND_NONE;
+}
+static inline void tegra_init_suspend(void) {}
+#endif
+
 #endif /* _MACH_TEGRA_PM_H_ */
diff --git a/arch/arm/mach-tegra/pmc.c b/arch/arm/mach-tegra/pmc.c
index e896826..32360e5 100644
--- a/arch/arm/mach-tegra/pmc.c
+++ b/arch/arm/mach-tegra/pmc.c
@@ -21,7 +21,14 @@
 #include <linux/of.h>
 #include <linux/of_address.h>
 
+#include "fuse.h"
+#include "pm.h"
 #include "pmc.h"
+#include "sleep.h"
+
+#define TEGRA_POWER_EFFECT_LP0		(1 << 14)  /* LP0 when CPU pwr gated */
+#define TEGRA_POWER_CPU_PWRREQ_POLARITY	(1 << 15)  /* CPU pwr req polarity */
+#define TEGRA_POWER_CPU_PWRREQ_OE	(1 << 16)  /* CPU pwr req enable */
 
 #define PMC_CTRL			0x0
 #define PMC_CTRL_INTR_LOW		(1 << 17)
@@ -157,14 +164,12 @@ int tegra_pmc_cpu_remove_clamping(int cpuid)
 }
 
 #ifdef CONFIG_PM_SLEEP
-void set_power_timers(unsigned long us_on, unsigned long us_off)
+static void set_power_timers(u32 us_on, u32 us_off, unsigned long rate)
 {
 	unsigned long long ticks;
 	unsigned long long pclk;
-	unsigned long rate;
 	static unsigned long tegra_last_pclk;
 
-	rate = clk_get_rate(tegra_pclk);
 	if (WARN_ON_ONCE(rate <= 0))
 		pclk = 100000000;
 	else
@@ -182,6 +187,44 @@ void set_power_timers(unsigned long us_on, unsigned long us_off)
 	}
 	tegra_last_pclk = pclk;
 }
+
+enum tegra_suspend_mode tegra_pmc_get_suspend_mode(void)
+{
+	return pmc_pm_data.suspend_mode;
+}
+
+void tegra_pmc_pm_set(enum tegra_suspend_mode mode)
+{
+	u32 reg;
+	unsigned long rate = 0;
+
+	reg = tegra_pmc_readl(PMC_CTRL);
+	reg |= TEGRA_POWER_CPU_PWRREQ_OE;
+	reg &= ~TEGRA_POWER_EFFECT_LP0;
+
+	switch (mode) {
+	case TEGRA_SUSPEND_LP2:
+		rate = clk_get_rate(tegra_pclk);
+		break;
+	default:
+		break;
+	}
+
+	set_power_timers(pmc_pm_data.cpu_good_time, pmc_pm_data.cpu_off_time,
+			 rate);
+
+	tegra_pmc_writel(reg, PMC_CTRL);
+}
+
+void tegra_pmc_suspend_init(void)
+{
+	u32 reg;
+
+	/* Always enable CPU power request */
+	reg = tegra_pmc_readl(PMC_CTRL);
+	reg |= TEGRA_POWER_CPU_PWRREQ_OE;
+	tegra_pmc_writel(reg, PMC_CTRL);
+}
 #endif
 
 static const struct of_device_id matches[] __initconst = {
@@ -228,6 +271,7 @@ static void tegra_pmc_parse_dt(void)
 			break;
 		}
 	}
+	suspend_mode = tegra_pm_validate_suspend_mode(suspend_mode);
 
 	if (of_property_read_u32(np, "nvidia,cpu-pwr-good-time", &prop))
 		suspend_mode = TEGRA_SUSPEND_NONE;
diff --git a/arch/arm/mach-tegra/pmc.h b/arch/arm/mach-tegra/pmc.h
index 6bc0fc09..e1c2df2 100644
--- a/arch/arm/mach-tegra/pmc.h
+++ b/arch/arm/mach-tegra/pmc.h
@@ -27,7 +27,9 @@ enum tegra_suspend_mode {
 };
 
 #ifdef CONFIG_PM_SLEEP
-void set_power_timers(unsigned long us_on, unsigned long us_off);
+enum tegra_suspend_mode tegra_pmc_get_suspend_mode(void);
+void tegra_pmc_pm_set(enum tegra_suspend_mode mode);
+void tegra_pmc_suspend_init(void);
 #endif
 
 bool tegra_pmc_cpu_is_powered(int cpuid);
-- 
1.8.2



From josephl at nvidia.com  Wed Apr  3 07:31:48 2013
From: josephl at nvidia.com (Joseph Lo)
Date: Wed, 3 Apr 2013 19:31:48 +0800
Subject: [PATCH V6 5/9] ARM: dts: tegra: add power gpio keys to DT
In-Reply-To: <1364988712-24797-1-git-send-email-josephl@nvidia.com>
References: <1364988712-24797-1-git-send-email-josephl@nvidia.com>
Message-ID: <1364988712-24797-6-git-send-email-josephl@nvidia.com>

This adds the power gpio key to DT and enable the wakeup of the gpio key
for the device. The Seaboard and paz00 already had the power gpio key
binding and the power key of Whistler was on KBC. So these boards' device
tree didn't include in this patch.

Signed-off-by: Joseph Lo <josephl at nvidia.com>
---
V6:
* no change
V5:
* no change
V4:
* no change
V3:
* no change
V2:
* no change
---
 arch/arm/boot/dts/tegra20-harmony.dts   | 11 +++++++++++
 arch/arm/boot/dts/tegra20-trimslice.dts | 11 +++++++++++
 arch/arm/boot/dts/tegra20-ventana.dts   | 11 +++++++++++
 3 files changed, 33 insertions(+)

diff --git a/arch/arm/boot/dts/tegra20-harmony.dts b/arch/arm/boot/dts/tegra20-harmony.dts
index 2c4da87..d86dd85 100644
--- a/arch/arm/boot/dts/tegra20-harmony.dts
+++ b/arch/arm/boot/dts/tegra20-harmony.dts
@@ -464,6 +464,17 @@
 		};
 	};
 
+	gpio-keys {
+		compatible = "gpio-keys";
+
+		power {
+			label = "Power";
+			gpios = <&gpio 170 1>; /* gpio PV2, active low */
+			linux,code = <116>; /* KEY_POWER */
+			gpio-key,wakeup;
+		};
+	};
+
 	kbc {
 		status = "okay";
 		nvidia,debounce-delay-ms = <2>;
diff --git a/arch/arm/boot/dts/tegra20-trimslice.dts b/arch/arm/boot/dts/tegra20-trimslice.dts
index 51b3a44..f96870c 100644
--- a/arch/arm/boot/dts/tegra20-trimslice.dts
+++ b/arch/arm/boot/dts/tegra20-trimslice.dts
@@ -343,6 +343,17 @@
 		};
 	};
 
+	gpio-keys {
+		compatible = "gpio-keys";
+
+		power {
+			label = "Power";
+			gpios = <&gpio 190 1>; /* gpio PX6, active low */
+			linux,code = <116>; /* KEY_POWER */
+			gpio-key,wakeup;
+		};
+	};
+
 	poweroff {
 		compatible = "gpio-poweroff";
 		gpios = <&gpio 191 1>; /* gpio PX7, active low */
diff --git a/arch/arm/boot/dts/tegra20-ventana.dts b/arch/arm/boot/dts/tegra20-ventana.dts
index 7095e96..5688d9f 100644
--- a/arch/arm/boot/dts/tegra20-ventana.dts
+++ b/arch/arm/boot/dts/tegra20-ventana.dts
@@ -544,6 +544,17 @@
 		};
 	};
 
+	gpio-keys {
+		compatible = "gpio-keys";
+
+		power {
+			label = "Power";
+			gpios = <&gpio 170 1>; /* gpio PV2, active low */
+			linux,code = <116>; /* KEY_POWER */
+			gpio-key,wakeup;
+		};
+	};
+
 	regulators {
 		compatible = "simple-bus";
 		#address-cells = <1>;
-- 
1.8.2



From josephl at nvidia.com  Wed Apr  3 07:31:49 2013
From: josephl at nvidia.com (Joseph Lo)
Date: Wed, 3 Apr 2013 19:31:49 +0800
Subject: [PATCH V6 6/9] ARM: dts: tegra: whistler: add wakeup source for KBC
In-Reply-To: <1364988712-24797-1-git-send-email-josephl@nvidia.com>
References: <1364988712-24797-1-git-send-email-josephl@nvidia.com>
Message-ID: <1364988712-24797-7-git-send-email-josephl@nvidia.com>

Adding KBC as a wakeup source for Whistler board.

Signed-off-by: Joseph Lo <josephl at nvidia.com>
---
V6:
* no change
V5:
* no change
V4:
* no change
V3:
* no change
V2:
* no change
---
 arch/arm/boot/dts/tegra20-whistler.dts | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/tegra20-whistler.dts b/arch/arm/boot/dts/tegra20-whistler.dts
index 99746c6..47c7a82 100644
--- a/arch/arm/boot/dts/tegra20-whistler.dts
+++ b/arch/arm/boot/dts/tegra20-whistler.dts
@@ -539,6 +539,7 @@
 		nvidia,repeat-delay-ms = <160>;
 		nvidia,kbc-row-pins = <0 1 2>;
 		nvidia,kbc-col-pins = <16 17>;
+		nvidia,wakeup-source;
 		linux,keymap = <0x00000074	/* KEY_POWER */
 				0x01000066	/* KEY_HOME */
 				0x0101009E	/* KEY_BACK */
-- 
1.8.2



From josephl at nvidia.com  Wed Apr  3 07:31:50 2013
From: josephl at nvidia.com (Joseph Lo)
Date: Wed, 3 Apr 2013 19:31:50 +0800
Subject: [PATCH V6 7/9] ARM: dts: tegra: add non-removable and
 keep-power-in-suspend property for MMC
In-Reply-To: <1364988712-24797-1-git-send-email-josephl@nvidia.com>
References: <1364988712-24797-1-git-send-email-josephl@nvidia.com>
Message-ID: <1364988712-24797-8-git-send-email-josephl@nvidia.com>

This patch adds "non-removable" property of MMC host where the eMMC device
is for Tegra platform.

And the "keep-power-in-suspend" property was used for the SDIO device that
need this to go into suspend mode (e.g. BRCM43xx series).

Signed-off-by: Joseph Lo <josephl at nvidia.com>
---
V6:
* add "non-removable" property for Dalmore
V5:
* no change
V4:
* no change
V3:
* no change
V2:
* no change
---
 arch/arm/boot/dts/tegra114-dalmore.dts   | 1 +
 arch/arm/boot/dts/tegra20-paz00.dts      | 1 +
 arch/arm/boot/dts/tegra20-seaboard.dts   | 2 ++
 arch/arm/boot/dts/tegra20-ventana.dts    | 2 ++
 arch/arm/boot/dts/tegra20-whistler.dts   | 1 +
 arch/arm/boot/dts/tegra30-beaver.dts     | 1 +
 arch/arm/boot/dts/tegra30-cardhu-a02.dts | 1 +
 arch/arm/boot/dts/tegra30-cardhu-a04.dts | 1 +
 arch/arm/boot/dts/tegra30-cardhu.dtsi    | 1 +
 9 files changed, 11 insertions(+)

diff --git a/arch/arm/boot/dts/tegra114-dalmore.dts b/arch/arm/boot/dts/tegra114-dalmore.dts
index 4aa2897..6b7f0ab 100644
--- a/arch/arm/boot/dts/tegra114-dalmore.dts
+++ b/arch/arm/boot/dts/tegra114-dalmore.dts
@@ -837,6 +837,7 @@
 	sdhci at 78000600 {
 		bus-width = <8>;
 		status = "okay";
+		non-removable;
 	};
 
 	clocks {
diff --git a/arch/arm/boot/dts/tegra20-paz00.dts b/arch/arm/boot/dts/tegra20-paz00.dts
index c421db4..3bd8448 100644
--- a/arch/arm/boot/dts/tegra20-paz00.dts
+++ b/arch/arm/boot/dts/tegra20-paz00.dts
@@ -445,6 +445,7 @@
 	sdhci at c8000600 {
 		status = "okay";
 		bus-width = <8>;
+		non-removable;
 	};
 
 	clocks {
diff --git a/arch/arm/boot/dts/tegra20-seaboard.dts b/arch/arm/boot/dts/tegra20-seaboard.dts
index b8f0400..6bf4ee7 100644
--- a/arch/arm/boot/dts/tegra20-seaboard.dts
+++ b/arch/arm/boot/dts/tegra20-seaboard.dts
@@ -580,6 +580,7 @@
 		status = "okay";
 		power-gpios = <&gpio 86 0>; /* gpio PK6 */
 		bus-width = <4>;
+		keep-power-in-suspend;
 	};
 
 	sdhci at c8000400 {
@@ -593,6 +594,7 @@
 	sdhci at c8000600 {
 		status = "okay";
 		bus-width = <8>;
+		non-removable;
 	};
 
 	clocks {
diff --git a/arch/arm/boot/dts/tegra20-ventana.dts b/arch/arm/boot/dts/tegra20-ventana.dts
index 5688d9f..bdc07b5 100644
--- a/arch/arm/boot/dts/tegra20-ventana.dts
+++ b/arch/arm/boot/dts/tegra20-ventana.dts
@@ -516,6 +516,7 @@
 		status = "okay";
 		power-gpios = <&gpio 86 0>; /* gpio PK6 */
 		bus-width = <4>;
+		keep-power-in-suspend;
 	};
 
 	sdhci at c8000400 {
@@ -529,6 +530,7 @@
 	sdhci at c8000600 {
 		status = "okay";
 		bus-width = <8>;
+		non-removable;
 	};
 
 	clocks {
diff --git a/arch/arm/boot/dts/tegra20-whistler.dts b/arch/arm/boot/dts/tegra20-whistler.dts
index 47c7a82..b3fc473 100644
--- a/arch/arm/boot/dts/tegra20-whistler.dts
+++ b/arch/arm/boot/dts/tegra20-whistler.dts
@@ -518,6 +518,7 @@
 	sdhci at c8000600 {
 		status = "okay";
 		bus-width = <8>;
+		non-removable;
 	};
 
 	clocks {
diff --git a/arch/arm/boot/dts/tegra30-beaver.dts b/arch/arm/boot/dts/tegra30-beaver.dts
index 6248b24..a930d19 100644
--- a/arch/arm/boot/dts/tegra30-beaver.dts
+++ b/arch/arm/boot/dts/tegra30-beaver.dts
@@ -266,6 +266,7 @@
 	sdhci at 78000600 {
 		status = "okay";
 		bus-width = <8>;
+		non-removable;
 	};
 
 	clocks {
diff --git a/arch/arm/boot/dts/tegra30-cardhu-a02.dts b/arch/arm/boot/dts/tegra30-cardhu-a02.dts
index adc88aa..e392bd2 100644
--- a/arch/arm/boot/dts/tegra30-cardhu-a02.dts
+++ b/arch/arm/boot/dts/tegra30-cardhu-a02.dts
@@ -88,6 +88,7 @@
 		status = "okay";
 		power-gpios = <&gpio 28 0>; /* gpio PD4 */
 		bus-width = <4>;
+		keep-power-in-suspend;
 	};
 };
 
diff --git a/arch/arm/boot/dts/tegra30-cardhu-a04.dts b/arch/arm/boot/dts/tegra30-cardhu-a04.dts
index 08163e1..d0db6c7 100644
--- a/arch/arm/boot/dts/tegra30-cardhu-a04.dts
+++ b/arch/arm/boot/dts/tegra30-cardhu-a04.dts
@@ -100,5 +100,6 @@
 		status = "okay";
 		power-gpios = <&gpio 27 0>; /* gpio PD3 */
 		bus-width = <4>;
+		keep-power-in-suspend;
 	};
 };
diff --git a/arch/arm/boot/dts/tegra30-cardhu.dtsi b/arch/arm/boot/dts/tegra30-cardhu.dtsi
index 7edd51e..0e97c74 100644
--- a/arch/arm/boot/dts/tegra30-cardhu.dtsi
+++ b/arch/arm/boot/dts/tegra30-cardhu.dtsi
@@ -320,6 +320,7 @@
 	sdhci at 78000600 {
 		status = "okay";
 		bus-width = <8>;
+		non-removable;
 	};
 
 	clocks {
-- 
1.8.2



From josephl at nvidia.com  Wed Apr  3 07:31:51 2013
From: josephl at nvidia.com (Joseph Lo)
Date: Wed, 3 Apr 2013 19:31:51 +0800
Subject: [PATCH V6 8/9] ARM: tegra: config: defconfig update
In-Reply-To: <1364988712-24797-1-git-send-email-josephl@nvidia.com>
References: <1364988712-24797-1-git-send-email-josephl@nvidia.com>
Message-ID: <1364988712-24797-9-git-send-email-josephl@nvidia.com>

KEYBOARD_GPIO:
* Enable gpio-key driver

Signed-off-by: Joseph Lo <josephl at nvidia.com>
---
V6:
* no change
V5:
* no change
V4:
* no change
V3:
* no change
V2:
* no change
---
 arch/arm/configs/tegra_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/tegra_defconfig b/arch/arm/configs/tegra_defconfig
index 2b42a2c..a5f0485 100644
--- a/arch/arm/configs/tegra_defconfig
+++ b/arch/arm/configs/tegra_defconfig
@@ -106,6 +106,7 @@ CONFIG_RT2X00=y
 CONFIG_RT2800USB=m
 CONFIG_INPUT_EVDEV=y
 CONFIG_KEYBOARD_TEGRA=y
+CONFIG_KEYBOARD_GPIO=y
 CONFIG_INPUT_MISC=y
 CONFIG_INPUT_MPU3050=y
 # CONFIG_LEGACY_PTYS is not set
-- 
1.8.2



From josephl at nvidia.com  Wed Apr  3 07:31:52 2013
From: josephl at nvidia.com (Joseph Lo)
Date: Wed, 3 Apr 2013 19:31:52 +0800
Subject: [PATCH V6 9/9] ARM: dts: tegra: add the PM configurations of PMC
In-Reply-To: <1364988712-24797-1-git-send-email-josephl@nvidia.com>
References: <1364988712-24797-1-git-send-email-josephl@nvidia.com>
Message-ID: <1364988712-24797-10-git-send-email-josephl@nvidia.com>

Adding the PM configuration of PMC when the platform support suspend
function.

Signed-off-by: Joseph Lo <josephl at nvidia.com>
---
V6:
* add support for colibri and tamonten based board
V5:
* no change
V4:
* no change
V3:
* fix the configuration for paz00 board
V2:
* no change
---
 arch/arm/boot/dts/tegra20-colibri-512.dtsi | 9 +++++++++
 arch/arm/boot/dts/tegra20-harmony.dts      | 6 ++++++
 arch/arm/boot/dts/tegra20-paz00.dts        | 6 ++++++
 arch/arm/boot/dts/tegra20-seaboard.dts     | 6 ++++++
 arch/arm/boot/dts/tegra20-tamonten.dtsi    | 6 ++++++
 arch/arm/boot/dts/tegra20-trimslice.dts    | 9 +++++++++
 arch/arm/boot/dts/tegra20-ventana.dts      | 6 ++++++
 arch/arm/boot/dts/tegra20-whistler.dts     | 8 ++++++++
 arch/arm/boot/dts/tegra30-beaver.dts       | 7 +++++++
 arch/arm/boot/dts/tegra30-cardhu.dtsi      | 7 +++++++
 10 files changed, 70 insertions(+)

diff --git a/arch/arm/boot/dts/tegra20-colibri-512.dtsi b/arch/arm/boot/dts/tegra20-colibri-512.dtsi
index d953ccc..a094787 100644
--- a/arch/arm/boot/dts/tegra20-colibri-512.dtsi
+++ b/arch/arm/boot/dts/tegra20-colibri-512.dtsi
@@ -361,6 +361,15 @@
 		};
 	};
 
+	pmc {
+		nvidia,suspend-mode = <2>;
+		nvidia,cpu-pwr-good-time = <5000>;
+		nvidia,cpu-pwr-off-time = <5000>;
+		nvidia,core-pwr-good-time = <3845 3845>;
+		nvidia,core-pwr-off-time = <3875>;
+		nvidia,sys-clock-req-active-high;
+	};
+
 	memory-controller at 7000f400 {
 		emc-table at 83250 {
 			reg = <83250>;
diff --git a/arch/arm/boot/dts/tegra20-harmony.dts b/arch/arm/boot/dts/tegra20-harmony.dts
index d86dd85..a44b54e 100644
--- a/arch/arm/boot/dts/tegra20-harmony.dts
+++ b/arch/arm/boot/dts/tegra20-harmony.dts
@@ -416,6 +416,12 @@
 
 	pmc {
 		nvidia,invert-interrupt;
+		nvidia,suspend-mode = <2>;
+		nvidia,cpu-pwr-good-time = <5000>;
+		nvidia,cpu-pwr-off-time = <5000>;
+		nvidia,core-pwr-good-time = <3845 3845>;
+		nvidia,core-pwr-off-time = <3875>;
+		nvidia,sys-clock-req-active-high;
 	};
 
 	usb at c5000000 {
diff --git a/arch/arm/boot/dts/tegra20-paz00.dts b/arch/arm/boot/dts/tegra20-paz00.dts
index 3bd8448..8c0e9a2 100644
--- a/arch/arm/boot/dts/tegra20-paz00.dts
+++ b/arch/arm/boot/dts/tegra20-paz00.dts
@@ -415,6 +415,12 @@
 
 	pmc {
 		nvidia,invert-interrupt;
+		nvidia,suspend-mode = <2>;
+		nvidia,cpu-pwr-good-time = <2000>;
+		nvidia,cpu-pwr-off-time = <0>;
+		nvidia,core-pwr-good-time = <3845 3845>;
+		nvidia,core-pwr-off-time = <0>;
+		nvidia,sys-clock-req-active-high;
 	};
 
 	usb at c5000000 {
diff --git a/arch/arm/boot/dts/tegra20-seaboard.dts b/arch/arm/boot/dts/tegra20-seaboard.dts
index 6bf4ee7..c45b698 100644
--- a/arch/arm/boot/dts/tegra20-seaboard.dts
+++ b/arch/arm/boot/dts/tegra20-seaboard.dts
@@ -517,6 +517,12 @@
 
 	pmc {
 		nvidia,invert-interrupt;
+		nvidia,suspend-mode = <2>;
+		nvidia,cpu-pwr-good-time = <5000>;
+		nvidia,cpu-pwr-off-time = <5000>;
+		nvidia,core-pwr-good-time = <3845 3845>;
+		nvidia,core-pwr-off-time = <3875>;
+		nvidia,sys-clock-req-active-high;
 	};
 
 	memory-controller at 7000f400 {
diff --git a/arch/arm/boot/dts/tegra20-tamonten.dtsi b/arch/arm/boot/dts/tegra20-tamonten.dtsi
index c190257..50b3ec1 100644
--- a/arch/arm/boot/dts/tegra20-tamonten.dtsi
+++ b/arch/arm/boot/dts/tegra20-tamonten.dtsi
@@ -458,6 +458,12 @@
 
 	pmc {
 		nvidia,invert-interrupt;
+		nvidia,suspend-mode = <2>;
+		nvidia,cpu-pwr-good-time = <5000>;
+		nvidia,cpu-pwr-off-time = <5000>;
+		nvidia,core-pwr-good-time = <3845 3845>;
+		nvidia,core-pwr-off-time = <3875>;
+		nvidia,sys-clock-req-active-high;
 	};
 
 	usb at c5008000 {
diff --git a/arch/arm/boot/dts/tegra20-trimslice.dts b/arch/arm/boot/dts/tegra20-trimslice.dts
index f96870c..f2fbc38 100644
--- a/arch/arm/boot/dts/tegra20-trimslice.dts
+++ b/arch/arm/boot/dts/tegra20-trimslice.dts
@@ -300,6 +300,15 @@
 		};
 	};
 
+	pmc {
+		nvidia,suspend-mode = <2>;
+		nvidia,cpu-pwr-good-time = <5000>;
+		nvidia,cpu-pwr-off-time = <5000>;
+		nvidia,core-pwr-good-time = <3845 3845>;
+		nvidia,core-pwr-off-time = <3875>;
+		nvidia,sys-clock-req-active-high;
+	};
+
 	usb at c5000000 {
 		status = "okay";
 		nvidia,vbus-gpio = <&gpio 170 0>; /* gpio PV2 */
diff --git a/arch/arm/boot/dts/tegra20-ventana.dts b/arch/arm/boot/dts/tegra20-ventana.dts
index bdc07b5..395df48 100644
--- a/arch/arm/boot/dts/tegra20-ventana.dts
+++ b/arch/arm/boot/dts/tegra20-ventana.dts
@@ -493,6 +493,12 @@
 
 	pmc {
 		nvidia,invert-interrupt;
+		nvidia,suspend-mode = <2>;
+		nvidia,cpu-pwr-good-time = <2000>;
+		nvidia,cpu-pwr-off-time = <100>;
+		nvidia,core-pwr-good-time = <3845 3845>;
+		nvidia,core-pwr-off-time = <458>;
+		nvidia,sys-clock-req-active-high;
 	};
 
 	usb at c5000000 {
diff --git a/arch/arm/boot/dts/tegra20-whistler.dts b/arch/arm/boot/dts/tegra20-whistler.dts
index b3fc473..2ed6bb8 100644
--- a/arch/arm/boot/dts/tegra20-whistler.dts
+++ b/arch/arm/boot/dts/tegra20-whistler.dts
@@ -496,6 +496,14 @@
 
 	pmc {
 		nvidia,invert-interrupt;
+		nvidia,suspend-mode = <2>;
+		nvidia,cpu-pwr-good-time = <2000>;
+		nvidia,cpu-pwr-off-time = <1000>;
+		nvidia,core-pwr-good-time = <0 3845>;
+		nvidia,core-pwr-off-time = <93727>;
+		nvidia,core-power-req-active-high;
+		nvidia,sys-clock-req-active-high;
+		nvidia,combined-power-req;
 	};
 
 	usb at c5000000 {
diff --git a/arch/arm/boot/dts/tegra30-beaver.dts b/arch/arm/boot/dts/tegra30-beaver.dts
index a930d19..b732f7c 100644
--- a/arch/arm/boot/dts/tegra30-beaver.dts
+++ b/arch/arm/boot/dts/tegra30-beaver.dts
@@ -253,6 +253,13 @@
 	pmc {
 		status = "okay";
 		nvidia,invert-interrupt;
+		nvidia,suspend-mode = <2>;
+		nvidia,cpu-pwr-good-time = <2000>;
+		nvidia,cpu-pwr-off-time = <200>;
+		nvidia,core-pwr-good-time = <3845 3845>;
+		nvidia,core-pwr-off-time = <0>;
+		nvidia,core-power-req-active-high;
+		nvidia,sys-clock-req-active-high;
 	};
 
 	sdhci at 78000000 {
diff --git a/arch/arm/boot/dts/tegra30-cardhu.dtsi b/arch/arm/boot/dts/tegra30-cardhu.dtsi
index 0e97c74..01b4c26 100644
--- a/arch/arm/boot/dts/tegra30-cardhu.dtsi
+++ b/arch/arm/boot/dts/tegra30-cardhu.dtsi
@@ -307,6 +307,13 @@
 	pmc {
 		status = "okay";
 		nvidia,invert-interrupt;
+		nvidia,suspend-mode = <2>;
+		nvidia,cpu-pwr-good-time = <2000>;
+		nvidia,cpu-pwr-off-time = <200>;
+		nvidia,core-pwr-good-time = <3845 3845>;
+		nvidia,core-pwr-off-time = <0>;
+		nvidia,core-power-req-active-high;
+		nvidia,sys-clock-req-active-high;
 	};
 
 	sdhci at 78000000 {
-- 
1.8.2



From josephl at nvidia.com  Wed Apr  3 07:32:30 2013
From: josephl at nvidia.com (Joseph Lo)
Date: Wed, 3 Apr 2013 19:32:30 +0800
Subject: [PATCH] clocksource: tegra: enable arch_timer
Message-ID: <1364988750-25058-1-git-send-email-josephl@nvidia.com>

Architected timer is the local timer for Cortex-A15. Adding the support
for Tegra.

Cc: John Stultz <john.stultz at linaro.org>
Cc: Thomas Gleixner <tglx at linutronix.de>
Signed-off-by: Joseph Lo <josephl at nvidia.com>
---
 drivers/clocksource/tegra20_timer.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/clocksource/tegra20_timer.c b/drivers/clocksource/tegra20_timer.c
index ae877b0..e443f44 100644
--- a/drivers/clocksource/tegra20_timer.c
+++ b/drivers/clocksource/tegra20_timer.c
@@ -30,6 +30,7 @@
 #include <asm/mach/time.h>
 #include <asm/smp_twd.h>
 #include <asm/sched_clock.h>
+#include <asm/arch_timer.h>
 
 #define RTC_SECONDS            0x08
 #define RTC_SHADOW_SECONDS     0x0c
@@ -200,8 +201,6 @@ static void __init tegra20_init_timer(struct device_node *np)
 		WARN(1, "Unknown clock rate");
 	}
 
-	setup_sched_clock(tegra_read_sched_clock, 32, 1000000);
-
 	if (clocksource_mmio_init(timer_reg_base + TIMERUS_CNTR_1US,
 		"timer_us", 1000000, 300, 32, clocksource_mmio_readl_up)) {
 		pr_err("Failed to register clocksource\n");
@@ -218,6 +217,10 @@ static void __init tegra20_init_timer(struct device_node *np)
 	tegra_clockevent.irq = tegra_timer_irq.irq;
 	clockevents_config_and_register(&tegra_clockevent, 1000000,
 					0x1, 0x1fffffff);
+	if (arch_timer_of_register())
+		setup_sched_clock(tegra_read_sched_clock, 32, 1000000);
+	else
+		arch_timer_sched_clock_init();
 }
 CLOCKSOURCE_OF_DECLARE(tegra20_timer, "nvidia,tegra20-timer", tegra20_init_timer);
 
-- 
1.8.2



From cov at codeaurora.org  Wed Apr  3 07:39:41 2013
From: cov at codeaurora.org (Christopher Covington)
Date: Wed, 03 Apr 2013 07:39:41 -0400
Subject: [Suggestion] ARM64:kernel: compiling issue for early_console.
In-Reply-To: <515BE49C.8040601@asianux.com>
References: <5152DB83.8080703@asianux.com>
 <20130327115509.GA1603@MacBook-Pro.local> <5152DFF1.2090000@asianux.com>
 <515BE49C.8040601@asianux.com>
Message-ID: <515C14FD.4040703@codeaurora.org>

Hi Chen,

On 04/03/2013 04:13 AM, Chen Gang wrote:
> Hello Maintainers:
> 
>   it seems, this issue still exists in next-20130402.
> 
>   have you already fixed it in another tree ?

Maybe somebody else does have a fix, but Catalin mentioned he was going on
vacation for two weeks on March 28th in "[GIT PULL] Preparatory GIC patches
for arm64 support".

>   if really no one fix it within this week, I should try (since I find it).

I'm sure a fix would be appreciated.

> On 2013?03?27? 20:02, Chen Gang wrote:
>> On 2013?03?27? 19:55, Catalin Marinas wrote:
>>> On Wed, Mar 27, 2013 at 11:44:03AM +0000, Chen Gang wrote:
>>>>>   the error message:
>>>>>     arch/arm64/kernel/early_printk.c: At top level:
>>>>>     arch/arm64/kernel/early_printk.c:98:23: error: conflicting types for ?early_console?
>>>>>     In file included from arch/arm64/kernel/early_printk.c:20:0:
>>>>>     include/linux/console.h:145:24: note: previous declaration of ?early_console? was here
>>>>>     make[1]: *** [arch/arm64/kernel/early_printk.o] Error 1
>>>>>     make: *** [arch/arm64/kernel] Error 2
>>> Is this in linux-next? Mainline seems fine.
>>
>>   yes, it is in next-20130326 at least :-)
>>
>>>
>>> I saw some patches from tglx on unifying the various early printk
>>> implementations, though not sure whether it's those patches causing it
>>> (in which case arm64 needs to be updated as well).

I looked briefly and wasn't able to find this patchset.

Regards,
Christopher

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by the Linux Foundation.


From nsekhar at ti.com  Wed Apr  3 07:45:54 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Wed, 3 Apr 2013 17:15:54 +0530
Subject: [PATCH v9 0/9] DMA Engine support for AM33XX
In-Reply-To: <1362586540-10393-1-git-send-email-mporter@ti.com>
References: <1362586540-10393-1-git-send-email-mporter@ti.com>
Message-ID: <515C1672.4060000@ti.com>

Hi Matt,

On 3/6/2013 9:45 PM, Matt Porter wrote:

> This series adds DMA Engine support for AM33xx, which uses
> an EDMA DMAC. The EDMA DMAC has been previously supported by only
> a private API implementation (much like the situation with OMAP
> DMA) found on the DaVinci family of SoCs.

> Matt Porter (9):
>   ARM: davinci: move private EDMA API to arm/common
>   ARM: edma: remove unused transfer controller handlers

If you are going to be late in re-spinning the entire series in time for
v3.10, then I suggest I queue the first two patches through davinci tree
for v3.10 and then you can work on rest of patches for next (v3.11)
merge window.

Let me know what you think.

>   ARM: edma: add AM33XX support to the private EDMA API
>   dmaengine: edma: enable build for AM33XX
>   dmaengine: edma: Add TI EDMA device tree binding
>   ARM: dts: add AM33XX EDMA support
>   spi: omap2-mcspi: convert to dma_request_slave_channel_compat()
>   spi: omap2-mcspi: add generic DMA request support to the DT binding
>   ARM: dts: add AM33XX SPI DMA support

Thanks,
Sekhar


From broonie at opensource.wolfsonmicro.com  Wed Apr  3 07:49:37 2013
From: broonie at opensource.wolfsonmicro.com (Mark Brown)
Date: Wed, 3 Apr 2013 12:49:37 +0100
Subject: [PATCH V3 2/5] spi: s3c64xx: added support for polling mode
In-Reply-To: <CAKrE-KdWe6aCg0p99BFEeQP-P2nwvdhs2itH3XnHsJMCUjWPAA@mail.gmail.com>
References: <1363157014-9615-1-git-send-email-ks.giri@samsung.com>
 <1363157014-9615-3-git-send-email-ks.giri@samsung.com>
 <20130401131207.GI18636@opensource.wolfsonmicro.com>
 <CAKrE-KdWe6aCg0p99BFEeQP-P2nwvdhs2itH3XnHsJMCUjWPAA@mail.gmail.com>
Message-ID: <20130403114935.GA11305@opensource.wolfsonmicro.com>

On Wed, Apr 03, 2013 at 05:00:04PM +0530, Girish KS wrote:
> On Mon, Apr 1, 2013 at 6:42 PM, Mark Brown

> >> -     if (!sdd->pdev->dev.of_node) {
> >> +     if (!sdd->pdev->dev.of_node && !is_polling(sdd)) {
> >>               res = platform_get_resource(pdev, IORESOURCE_DMA,  0);
> >>               if (!res) {
> >>                       dev_err(&pdev->dev, "Unable to get SPI tx dma "

> > It seems like it'd be sensible to also handle failure to get the DMA
> > resource by going into polling mode.

> There are 2 cases currently i have identified and handled,
> 1. The SoC's dont have DMA support for spi controller. For such SoC's we
>  would not add the dma resource in the spi dts node. In this case the probe
>  would return error if failure for DMA resuorce is handled.

That's not what the code currently does...

> 2. The SoC has a DMA support for SPI controller, but due to some x
> reason(H/W bug),
>  the driver would force polling mode by enabling
> S3C64XX_SPI_QUIRK_POLL in driver
>  data. For such SoC's there would be a dma entry in the spi controller
> dts node, and
>  probe can handle failure for DMA resource successfully.

> To handle above both situations successfully if
> (!sdd->pdev->dev.of_node && !is_polling(sdd)) is used.

Right, that's what the code currently does but what I'm suggesting is
that this isn't the most helpful thing to do and that printing a big
warning then soldiering on in polling mode might be more useful.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130403/2f42c448/attachment.sig>

From peter.ujfalusi at ti.com  Wed Apr  3 07:52:25 2013
From: peter.ujfalusi at ti.com (Peter Ujfalusi)
Date: Wed, 3 Apr 2013 13:52:25 +0200
Subject: [RFC v2] dmaengine: omap-dma: Start DMA without delay for cyclic
 channels
In-Reply-To: <515C117A.6060700@ti.com>
References: <1364987862-14597-1-git-send-email-peter.ujfalusi@ti.com>
 <515C117A.6060700@ti.com>
Message-ID: <515C17F9.4040300@ti.com>

On 04/03/2013 01:24 PM, Santosh Shilimkar wrote:
> On Wednesday 03 April 2013 04:47 PM, Peter Ujfalusi wrote:
>> cyclic DMA is only used by audio which needs DMA to be started without a
>> delay.
>> If the DMA for audio is started using the tasklet we experience random
>> channel switch (to be more precise: channel shift).
>>
>> Reported-by: Peter Meerwald <pmeerw at pmeerw.net>
>> Signed-off-by: Peter Ujfalusi <peter.ujfalusi at ti.com>
>> ---
>> Hi Russell,
>>
>> Instead of removing the tasklet we can identify the DMA channel used by audio
>> based on the cyclic flag of the channel.
>> I think this can be used as a short term solution to fix the audio channel shift
>> issue and later when we have the dynamic DMA channel allocation we can adjust
>> the code.
>>
>> Regards,
>> Peter
>>
>>  drivers/dma/omap-dma.c | 20 ++++++++++++++------
>>  1 file changed, 14 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
>> index 2ea3d7e..ec3fc4f 100644
>> --- a/drivers/dma/omap-dma.c
>> +++ b/drivers/dma/omap-dma.c
>> @@ -282,12 +282,20 @@ static void omap_dma_issue_pending(struct dma_chan *chan)
>>  
>>  	spin_lock_irqsave(&c->vc.lock, flags);
>>  	if (vchan_issue_pending(&c->vc) && !c->desc) {
> If you add "!c->cyclic" in above if then you can avoid
> indentation change and just have else for cyclic case.

It can not be embedded there because of the existing tests. How would we
handle the case when c->desc is _not_ NULL and c->cyclic is false? We would
need to test again in else, but we can not do this for the
vchan_issue_pending(&c->vc).

> 
>> -		struct omap_dmadev *d = to_omap_dma_dev(chan->device);
>> -		spin_lock(&d->lock);
>> -		if (list_empty(&c->node))
>> -			list_add_tail(&c->node, &d->pending);
>> -		spin_unlock(&d->lock);
>> -		tasklet_schedule(&d->task);
>> +		/*
>> +		 * c->cyclic is used only by audio and in this case the DMA need
>> +		 * to be started without delay.
>> +		 */
>> +		if (!c->cyclic) {
>> +			struct omap_dmadev *d = to_omap_dma_dev(chan->device);
>> +			spin_lock(&d->lock);
>> +			if (list_empty(&c->node))
>> +				list_add_tail(&c->node, &d->pending);
>> +			spin_unlock(&d->lock);
>> +			tasklet_schedule(&d->task);
>> +		} else {
>> +			omap_dma_start_desc(c);
>> +		}
>>  	}
>>  	spin_unlock_irqrestore(&c->vc.lock, flags);
>>  }
>>
> 


-- 
P?ter


From zonque at gmail.com  Wed Apr  3 07:52:41 2013
From: zonque at gmail.com (Daniel Mack)
Date: Wed, 3 Apr 2013 13:52:41 +0200
Subject: [RFC v2 16/18] ARM: OMAP2+: AM33XX: Basic suspend resume support
In-Reply-To: <1356959231-17335-17-git-send-email-vaibhav.bedia@ti.com>
References: <1356959231-17335-1-git-send-email-vaibhav.bedia@ti.com>
 <1356959231-17335-17-git-send-email-vaibhav.bedia@ti.com>
Message-ID: <CACTFLAM=69kZOGoJU8_tBfrJKmDTivpF8ZC8R95anHHA37f7_A@mail.gmail.com>

Hi Vaibhav,

On Mon, Dec 31, 2012 at 2:07 PM, Vaibhav Bedia <vaibhav.bedia at ti.com> wrote:
> AM335x supports various low power modes as documented
> in section 8.1.4.3 of the AM335x TRM which is available
> @ http://www.ti.com/litv/pdf/spruh73f

May I ask about the plans for this series? Will you be re-spinning
them for a current
tree, and what's the planned merge window for it?


Many thanks,
Daniel




>
> DeepSleep0 mode offers the lowest power mode with limited
> wakeup sources without a system reboot and is mapped as
> the suspend state in the kernel. In this state, MPU and
> PER domains are turned off with the internal RAM held in
> retention to facilitate resume process. As part of the boot
> process, the assembly code is copied over to OCMCRAM using
> the OMAP SRAM code.
>
> AM335x has a Cortex-M3 (WKUP_M3) which assists the MPU
> in DeepSleep0 entry and exit. WKUP_M3 takes care of the
> clockdomain and powerdomain transitions based on the
> intended low power state. MPU needs to load the appropriate
> WKUP_M3 binary onto the WKUP_M3 memory space before it can
> leverage any of the PM features like DeepSleep.
>
> The IPC mechanism between MPU and WKUP_M3 uses a mailbox
> sub-module and 8 IPC registers in the Control module. MPU
> uses the assigned Mailbox for issuing an interrupt to
> WKUP_M3 which then goes and checks the IPC registers for
> the payload. WKUP_M3 has the ability to trigger on interrupt
> to MPU by executing the "sev" instruction.
>
> In the current implementation when the suspend process
> is initiated MPU interrupts the WKUP_M3 to let it know about
> the intent of entering DeepSleep0 and waits for an ACK. When
> the ACK is received MPU continues with its suspend process
> to suspend all the drivers and then jumps to assembly in
> OCMC RAM. The assembly code puts the PLLs in bypass, puts the
> external RAM in self-refresh mode and then finally execute the
> WFI instruction. Execution of the WFI instruction triggers another
> interrupt to the WKUP_M3 which then continues wiht the power down
> sequence wherein the clockdomain and powerdomain transition takes
> place. As part of the sleep sequence, WKUP_M3 unmasks the interrupt
> lines for the wakeup sources. WFI execution on WKUP_M3 causes the
> hardware to disable the main oscillator of the SoC.
>
> When a wakeup event occurs, WKUP_M3 starts the power-up
> sequence by switching on the power domains and finally
> enabling the clock to MPU. Since the MPU gets powered down
> as part of the sleep sequence in the resume path ROM code
> starts executing. The ROM code detects a wakeup from sleep
> and then jumps to the resume location in OCMC which was
> populated in one of the IPC registers as part of the suspend
> sequence.
>
> The low level code in OCMC relocks the PLLs, enables access
> to external RAM and then jumps to the cpu_resume code of
> the kernel to finish the resume process.
>
> Signed-off-by: Vaibhav Bedia <vaibhav.bedia at ti.com>
> Cc: Tony Lingren <tony at atomide.com>
> Cc: Santosh Shilimkar <santosh.shilimkar at ti.com>
> Cc: Benoit Cousson <b-cousson at ti.com>
> Cc: Paul Walmsley <paul at pwsan.com>
> Cc: Kevin Hilman <khilman at deeprootsystems.com>
> ---
> v1->v2:
>         Move assembly code addition, control module access
>         and hookup in OMAP PM framework in separate patches.
>         Address other comments from Kevin Hilman and Santosh
>         Shilimkar on v1. The discussion on v1 is present @
>         http://lists.infradead.org/pipermail/linux-arm-kernel/2012-November/129979.html
>         Note: The mailbox change will need slight rework once
>         the driver is finalized.
>
>  arch/arm/mach-omap2/pm33xx.c |  469 ++++++++++++++++++++++++++++++++++++++++++
>  arch/arm/mach-omap2/pm33xx.h |   56 +++++
>  2 files changed, 525 insertions(+), 0 deletions(-)
>  create mode 100644 arch/arm/mach-omap2/pm33xx.c
>  create mode 100644 arch/arm/mach-omap2/pm33xx.h
>
> diff --git a/arch/arm/mach-omap2/pm33xx.c b/arch/arm/mach-omap2/pm33xx.c
> new file mode 100644
> index 0000000..aaa4daa
> --- /dev/null
> +++ b/arch/arm/mach-omap2/pm33xx.c
> @@ -0,0 +1,469 @@
> +/*
> + * AM33XX Power Management Routines
> + *
> + * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
> + * Vaibhav Bedia <vaibhav.bedia at ti.com>
> + *
> + * 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 version 2.
> + *
> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
> + * kind, whether express or implied; without even the implied warranty
> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/init.h>
> +#include <linux/err.h>
> +#include <linux/firmware.h>
> +#include <linux/io.h>
> +#include <linux/platform_device.h>
> +#include <linux/sched.h>
> +#include <linux/suspend.h>
> +#include <linux/completion.h>
> +#include <linux/module.h>
> +#include <linux/mailbox.h>
> +#include <linux/interrupt.h>
> +
> +#include <asm/suspend.h>
> +#include <asm/proc-fns.h>
> +#include <asm/sizes.h>
> +#include <asm/fncpy.h>
> +#include <asm/system_misc.h>
> +
> +#include "pm.h"
> +#include "cm33xx.h"
> +#include "pm33xx.h"
> +#include "control.h"
> +#include "clockdomain.h"
> +#include "powerdomain.h"
> +#include "omap_hwmod.h"
> +#include "omap_device.h"
> +#include "soc.h"
> +#include "sram.h"
> +
> +void (*am33xx_do_wfi_sram)(void);
> +
> +static void __iomem *am33xx_emif_base;
> +static struct powerdomain *cefuse_pwrdm, *gfx_pwrdm, *per_pwrdm;
> +static struct clockdomain *gfx_l4ls_clkdm;
> +static struct omap_hwmod *usb_oh, *cpsw_oh, *tptc0_oh, *tptc1_oh, *tptc2_oh;
> +static struct wkup_m3_context *wkup_m3;
> +
> +static DECLARE_COMPLETION(wkup_m3_sync);
> +
> +#ifdef CONFIG_SUSPEND
> +static int am33xx_do_sram_idle(long unsigned int unused)
> +{
> +       am33xx_do_wfi_sram();
> +       return 0;
> +}
> +
> +static int am33xx_pm_suspend(void)
> +{
> +       int status, ret = 0;
> +
> +       /*
> +        * By default the following IPs do not have MSTANDBY asserted
> +        * which is necessary for PER domain transition. If the drivers
> +        * are not compiled into the kernel HWMOD code will not change the
> +        * state of the IPs if the IP was not never enabled. To ensure
> +        * that there no issues with or without the drivers being compiled
> +        * in the kernel, we forcefully put these IPs to idle.
> +        */
> +       omap_hwmod_enable(usb_oh);
> +       omap_hwmod_enable(tptc0_oh);
> +       omap_hwmod_enable(tptc1_oh);
> +       omap_hwmod_enable(tptc2_oh);
> +       omap_hwmod_enable(cpsw_oh);
> +
> +       omap_hwmod_idle(usb_oh);
> +       omap_hwmod_idle(tptc0_oh);
> +       omap_hwmod_idle(tptc1_oh);
> +       omap_hwmod_idle(tptc2_oh);
> +       omap_hwmod_idle(cpsw_oh);
> +
> +       /* Try to put GFX to sleep */
> +       pwrdm_set_next_fpwrst(gfx_pwrdm, PWRDM_FUNC_PWRST_OFF);
> +
> +       ret = cpu_suspend(0, am33xx_do_sram_idle);
> +
> +       status = pwrdm_read_fpwrst(gfx_pwrdm);
> +       if (status != PWRDM_FUNC_PWRST_OFF)
> +               pr_err("GFX domain did not transition\n");
> +       else
> +               pr_info("GFX domain entered low power state\n");
> +
> +       /*
> +        * GFX_L4LS clock domain needs to be woken up to
> +        * ensure thet L4LS clock domain does not get stuck in transition
> +        * If that happens L3 module does not get disabled, thereby leading
> +        * to PER power domain transition failing
> +        *
> +        * The clock framework should take care of ensuring
> +        * that the clock domain is in the right state when
> +        * GFX driver is active.
> +        */
> +       clkdm_wakeup(gfx_l4ls_clkdm);
> +       clkdm_sleep(gfx_l4ls_clkdm);
> +
> +       if (ret) {
> +               pr_err("Kernel suspend failure\n");
> +       } else {
> +               status = omap_ctrl_readl(AM33XX_CONTROL_IPC_MSG_REG1);
> +               status &= IPC_RESP_MASK;
> +               status >>= __ffs(IPC_RESP_MASK);
> +
> +               switch (status) {
> +               case 0:
> +                       pr_info("Successfully put all powerdomains to target state\n");
> +                       /*
> +                        * XXX: Leads to loss of logic state in PER power domain
> +                        * Use SOC specific ops for this?
> +                        */
> +                       break;
> +               case 1:
> +                       pr_err("Could not transition all powerdomains to target state\n");
> +                       ret = -1;
> +                       break;
> +               default:
> +                       pr_err("Something went wrong :(\nStatus = %d\n",
> +                               status);
> +                       ret = -1;
> +               }
> +       }
> +
> +       return ret;
> +}
> +
> +static int am33xx_pm_enter(suspend_state_t suspend_state)
> +{
> +       int ret = 0;
> +
> +       switch (suspend_state) {
> +       case PM_SUSPEND_STANDBY:
> +       case PM_SUSPEND_MEM:
> +               ret = am33xx_pm_suspend();
> +               break;
> +       default:
> +               ret = -EINVAL;
> +       }
> +
> +       return ret;
> +}
> +
> +static int am33xx_pm_begin(suspend_state_t state)
> +{
> +       int ret = 0;
> +       struct mailbox_msg dummy_msg;
> +
> +       disable_hlt();
> +
> +       MAILBOX_FILL_HEADER_MSG(dummy_msg, 0xABCDABCD);
> +
> +       wkup_m3->ipc_data.sleep_mode = IPC_CMD_DS0;
> +       wkup_m3->ipc_data.param1  = DS_IPC_DEFAULT;
> +       wkup_m3->ipc_data.param2  = DS_IPC_DEFAULT;
> +
> +       am33xx_wkup_m3_ipc_cmd(&wkup_m3->ipc_data);
> +
> +       wkup_m3->state = M3_STATE_MSG_FOR_LP;
> +
> +       mailbox_enable_irq(wkup_m3->mbox, IRQ_RX);
> +
> +       ret = mailbox_msg_send(wkup_m3->mbox, &dummy_msg);
> +       if (ret) {
> +               pr_err("A8<->CM3 MSG for LP failed\n");
> +               am33xx_m3_state_machine_reset();
> +               ret = -1;
> +       }
> +
> +       /* Give some time to M3 to respond. 500msec is a random value here */
> +       if (!wait_for_completion_timeout(&wkup_m3_sync,
> +                                       msecs_to_jiffies(500))) {
> +               pr_err("A8<->CM3 sync failure\n");
> +               am33xx_m3_state_machine_reset();
> +               ret = -1;
> +       } else {
> +               pr_debug("Message sent for entering DeepSleep mode\n");
> +               mailbox_disable_irq(wkup_m3->mbox, IRQ_RX);
> +       }
> +
> +       return ret;
> +}
> +
> +static void am33xx_pm_end(void)
> +{
> +       mailbox_enable_irq(wkup_m3->mbox, IRQ_RX);
> +
> +       am33xx_m3_state_machine_reset();
> +
> +       enable_hlt();
> +
> +       return;
> +}
> +
> +static const struct platform_suspend_ops am33xx_pm_ops = {
> +       .begin          = am33xx_pm_begin,
> +       .end            = am33xx_pm_end,
> +       .enter          = am33xx_pm_enter,
> +       .valid          = suspend_valid_only_mem,
> +};
> +
> +static void am33xx_m3_state_machine_reset(void)
> +{
> +       int ret = 0;
> +       struct mailbox_msg dummy_msg;
> +
> +       MAILBOX_FILL_HEADER_MSG(dummy_msg, 0xABCDABCD);
> +
> +       wkup_m3->ipc_data.sleep_mode    = IPC_CMD_RESET;
> +       wkup_m3->ipc_data.param1        = DS_IPC_DEFAULT;
> +       wkup_m3->ipc_data.param2        = DS_IPC_DEFAULT;
> +
> +       am33xx_wkup_m3_ipc_cmd(&wkup_m3->ipc_data);
> +
> +       wkup_m3->state = M3_STATE_MSG_FOR_RESET;
> +
> +       ret = mailbox_msg_send(wkup_m3->mbox, &dummy_msg);
> +       if (!ret) {
> +               pr_debug("Message sent for resetting M3 state machine\n");
> +               /* Give some to M3 to respond. 500msec is a random value here */
> +               if (!wait_for_completion_timeout(&wkup_m3_sync,
> +                                               msecs_to_jiffies(500)))
> +                       pr_err("A8<->CM3 sync failure\n");
> +       } else {
> +               pr_err("Could not reset M3 state machine!!!\n");
> +               wkup_m3->state = M3_STATE_UNKNOWN;
> +       }
> +}
> +#endif /* CONFIG_SUSPEND */
> +
> +/*
> + * Dummy notifier for the mailbox
> + * XXX: Get rid of this requirement once the MBX driver has been finalized
> + */
> +static int wkup_mbox_msg(struct notifier_block *self, unsigned long len,
> +               void *msg)
> +{
> +       return 0;
> +}
> +
> +static struct notifier_block wkup_mbox_notifier = {
> +       .notifier_call = wkup_mbox_msg,
> +};
> +
> +static irqreturn_t wkup_m3_txev_handler(int irq, void *unused)
> +{
> +       am33xx_txev_eoi();
> +
> +       switch (wkup_m3->state) {
> +       case M3_STATE_RESET:
> +               wkup_m3->state = M3_STATE_INITED;
> +               break;
> +       case M3_STATE_MSG_FOR_RESET:
> +               wkup_m3->state = M3_STATE_INITED;
> +               mailbox_rx_flush(wkup_m3->mbox);
> +               complete(&wkup_m3_sync);
> +               break;
> +       case M3_STATE_MSG_FOR_LP:
> +               mailbox_rx_flush(wkup_m3->mbox);
> +               complete(&wkup_m3_sync);
> +               break;
> +       case M3_STATE_UNKNOWN:
> +               pr_err("IRQ %d with WKUP_M3 in unknown state\n", irq);
> +               mailbox_rx_flush(wkup_m3->mbox);
> +               return IRQ_NONE;
> +       }
> +
> +       am33xx_txev_enable();
> +       return IRQ_HANDLED;
> +}
> +
> +static void am33xx_pm_firmware_cb(const struct firmware *fw, void *context)
> +{
> +       struct wkup_m3_context *wkup_m3_context = context;
> +       struct platform_device *pdev = to_platform_device(wkup_m3_context->dev);
> +       int ret = 0;
> +
> +       /* no firmware found */
> +       if (!fw) {
> +               dev_err(wkup_m3_context->dev, "request_firmware failed\n");
> +               goto err;
> +       }
> +
> +       memcpy((void *)wkup_m3_context->code, fw->data, fw->size);
> +       pr_info("Copied the M3 firmware to UMEM\n");
> +
> +       wkup_m3->state = M3_STATE_RESET;
> +
> +       ret = omap_device_deassert_hardreset(pdev, "wkup_m3");
> +       if (ret) {
> +               pr_err("Could not deassert the reset for WKUP_M3\n");
> +               goto err;
> +       } else {
> +#ifdef CONFIG_SUSPEND
> +               suspend_set_ops(&am33xx_pm_ops);
> +               /*
> +                * Physical resume address to be used by ROM code
> +                */
> +               wkup_m3->ipc_data.resume_addr = (AM33XX_OCMC_END -
> +                               am33xx_do_wfi_sz + am33xx_resume_offset + 0x4);
> +#endif
> +               return;
> +       }
> +
> +err:
> +       mailbox_put(wkup_m3_context->mbox, &wkup_mbox_notifier);
> +}
> +
> +static int wkup_m3_init(void)
> +{
> +       int irq, ret = 0;
> +       struct resource *mem;
> +       struct platform_device *pdev = to_platform_device(wkup_m3->dev);
> +
> +       omap_device_enable_hwmods(to_omap_device(pdev));
> +
> +       /* Reserve the MBOX for sending messages to M3 */
> +       wkup_m3->mbox = mailbox_get("wkup_m3", &wkup_mbox_notifier);
> +       if (IS_ERR(wkup_m3->mbox)) {
> +               pr_err("Could not reserve mailbox for A8->M3 IPC\n");
> +               ret = -ENODEV;
> +               goto exit;
> +       }
> +
> +       irq = platform_get_irq(pdev, 0);
> +       if (!irq) {
> +               dev_err(wkup_m3->dev, "no irq resource\n");
> +               ret = -ENXIO;
> +               goto err;
> +       }
> +
> +       mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +       if (!mem) {
> +               dev_err(wkup_m3->dev, "no memory resource\n");
> +               ret = -ENXIO;
> +               goto err;
> +       }
> +
> +       wkup_m3->code = devm_request_and_ioremap(wkup_m3->dev, mem);
> +       if (!wkup_m3->code) {
> +               dev_err(wkup_m3->dev, "could not ioremap\n");
> +               ret = -EADDRNOTAVAIL;
> +               goto err;
> +       }
> +
> +       ret = devm_request_irq(wkup_m3->dev, irq, wkup_m3_txev_handler,
> +                 IRQF_DISABLED, "wkup_m3_txev", NULL);
> +       if (ret) {
> +               dev_err(wkup_m3->dev, "request_irq failed\n");
> +               goto err;
> +       } else {
> +               am33xx_txev_enable();
> +       }
> +
> +       pr_info("Trying to load am335x-pm-firmware.bin");
> +
> +       /* We don't want to delay boot */
> +       request_firmware_nowait(THIS_MODULE, 0, "am335x-pm-firmware.bin",
> +                               wkup_m3->dev, GFP_KERNEL, wkup_m3,
> +                               am33xx_pm_firmware_cb);
> +       return 0;
> +
> +err:
> +       mailbox_put(wkup_m3->mbox, &wkup_mbox_notifier);
> +exit:
> +       return ret;
> +}
> +
> +/*
> + * Push the minimal suspend-resume code to SRAM
> + */
> +void am33xx_push_sram_idle(void)
> +{
> +       am33xx_do_wfi_sram = (void *)omap_sram_push
> +                                       (am33xx_do_wfi, am33xx_do_wfi_sz);
> +}
> +
> +static int __init am33xx_map_emif(void)
> +{
> +       am33xx_emif_base = ioremap(AM33XX_EMIF_BASE, SZ_32K);
> +
> +       if (!am33xx_emif_base)
> +               return -ENOMEM;
> +
> +       return 0;
> +}
> +
> +void __iomem *am33xx_get_emif_base(void)
> +{
> +       return am33xx_emif_base;
> +}
> +
> +int __init am33xx_pm_init(void)
> +{
> +       int ret;
> +
> +       if (!soc_is_am33xx())
> +               return -ENODEV;
> +
> +       pr_info("Power Management for AM33XX family\n");
> +
> +       /*
> +        * By default the following IPs do not have MSTANDBY asserted
> +        * which is necessary for PER domain transition. If the drivers
> +        * are not compiled into the kernel HWMOD code will not change the
> +        * state of the IPs if the IP was not never enabled
> +        */
> +       usb_oh          = omap_hwmod_lookup("usb_otg_hs");
> +       tptc0_oh        = omap_hwmod_lookup("tptc0");
> +       tptc1_oh        = omap_hwmod_lookup("tptc1");
> +       tptc2_oh        = omap_hwmod_lookup("tptc2");
> +       cpsw_oh         = omap_hwmod_lookup("cpgmac0");
> +
> +       gfx_pwrdm = pwrdm_lookup("gfx_pwrdm");
> +       per_pwrdm = pwrdm_lookup("per_pwrdm");
> +
> +       gfx_l4ls_clkdm = clkdm_lookup("gfx_l4ls_gfx_clkdm");
> +
> +       if ((!usb_oh) || (!tptc0_oh) || (!tptc1_oh) || (!tptc2_oh) ||
> +               (!cpsw_oh) || (!gfx_pwrdm) || (!per_pwrdm) ||
> +               (!gfx_l4ls_clkdm)) {
> +               ret = -ENODEV;
> +               goto err;
> +       }
> +
> +       wkup_m3 = kzalloc(sizeof(struct wkup_m3_context), GFP_KERNEL);
> +       if (!wkup_m3) {
> +               pr_err("Memory allocation failed\n");
> +               ret = -ENOMEM;
> +               goto err;
> +       }
> +
> +       ret = am33xx_map_emif();
> +       if (ret) {
> +               pr_err("Could not ioremap EMIF\n");
> +               goto err;
> +       }
> +
> +       (void) clkdm_for_each(omap_pm_clkdms_setup, NULL);
> +
> +       /* CEFUSE domain can be turned off post bootup */
> +       cefuse_pwrdm = pwrdm_lookup("cefuse_pwrdm");
> +       if (cefuse_pwrdm)
> +               pwrdm_set_next_fpwrst(cefuse_pwrdm, PWRDM_FUNC_PWRST_OFF);
> +       else
> +               pr_err("Failed to get cefuse_pwrdm\n");
> +
> +       wkup_m3->dev = omap_device_get_by_hwmod_name("wkup_m3");
> +
> +       ret = wkup_m3_init();
> +       if (ret)
> +               pr_err("Could not initialise firmware loading\n");
> +
> +err:
> +       return ret;
> +}
> diff --git a/arch/arm/mach-omap2/pm33xx.h b/arch/arm/mach-omap2/pm33xx.h
> new file mode 100644
> index 0000000..13a2c85
> --- /dev/null
> +++ b/arch/arm/mach-omap2/pm33xx.h
> @@ -0,0 +1,56 @@
> +/*
> + * AM33XX Power Management Routines
> + *
> + * Copyright (C) 2012 Texas Instruments Inc.
> + * Vaibhav Bedia <vaibhav.bedia at ti.com>
> + *
> + * 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 version 2.
> + *
> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
> + * kind, whether express or implied; without even the implied warranty
> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +#ifndef __ARCH_ARM_MACH_OMAP2_PM33XX_H
> +#define __ARCH_ARM_MACH_OMAP2_PM33XX_H
> +
> +#include "control.h"
> +
> +#ifndef __ASSEMBLER__
> +struct wkup_m3_context {
> +       struct am33xx_ipc_data  ipc_data;
> +       struct device           *dev;
> +       struct firmware         *firmware;
> +       struct mailbox          *mbox;
> +       void __iomem            *code;
> +       u8                      state;
> +};
> +
> +#ifdef CONFIG_SUSPEND
> +static void am33xx_m3_state_machine_reset(void);
> +#else
> +static inline void am33xx_m3_state_machine_reset(void) {}
> +#endif /* CONFIG_SUSPEND */
> +
> +extern void __iomem *am33xx_get_emif_base(void);
> +#endif
> +
> +#define        IPC_CMD_DS0                     0x3
> +#define IPC_CMD_RESET                   0xe
> +#define DS_IPC_DEFAULT                 0xffffffff
> +
> +#define IPC_RESP_SHIFT                 16
> +#define IPC_RESP_MASK                  (0xffff << 16)
> +
> +#define M3_STATE_UNKNOWN               0
> +#define M3_STATE_RESET                 1
> +#define M3_STATE_INITED                        2
> +#define M3_STATE_MSG_FOR_LP            3
> +#define M3_STATE_MSG_FOR_RESET         4
> +
> +#define AM33XX_OCMC_END                        0x40310000
> +#define AM33XX_EMIF_BASE               0x4C000000
> +
> +#endif
> --
> 1.7.0.4
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From santosh.shilimkar at ti.com  Wed Apr  3 08:00:13 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Wed, 3 Apr 2013 17:30:13 +0530
Subject: [RFC v2] dmaengine: omap-dma: Start DMA without delay for cyclic
 channels
In-Reply-To: <515C17F9.4040300@ti.com>
References: <1364987862-14597-1-git-send-email-peter.ujfalusi@ti.com>
 <515C117A.6060700@ti.com> <515C17F9.4040300@ti.com>
Message-ID: <515C19CD.306@ti.com>

On Wednesday 03 April 2013 05:22 PM, Peter Ujfalusi wrote:
> On 04/03/2013 01:24 PM, Santosh Shilimkar wrote:
>> On Wednesday 03 April 2013 04:47 PM, Peter Ujfalusi wrote:
>>> cyclic DMA is only used by audio which needs DMA to be started without a
>>> delay.
>>> If the DMA for audio is started using the tasklet we experience random
>>> channel switch (to be more precise: channel shift).
>>>
>>> Reported-by: Peter Meerwald <pmeerw at pmeerw.net>
>>> Signed-off-by: Peter Ujfalusi <peter.ujfalusi at ti.com>
>>> ---
>>> Hi Russell,
>>>
>>> Instead of removing the tasklet we can identify the DMA channel used by audio
>>> based on the cyclic flag of the channel.
>>> I think this can be used as a short term solution to fix the audio channel shift
>>> issue and later when we have the dynamic DMA channel allocation we can adjust
>>> the code.
>>>
>>> Regards,
>>> Peter
>>>
>>>  drivers/dma/omap-dma.c | 20 ++++++++++++++------
>>>  1 file changed, 14 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
>>> index 2ea3d7e..ec3fc4f 100644
>>> --- a/drivers/dma/omap-dma.c
>>> +++ b/drivers/dma/omap-dma.c
>>> @@ -282,12 +282,20 @@ static void omap_dma_issue_pending(struct dma_chan *chan)
>>>  
>>>  	spin_lock_irqsave(&c->vc.lock, flags);
>>>  	if (vchan_issue_pending(&c->vc) && !c->desc) {
>> If you add "!c->cyclic" in above if then you can avoid
>> indentation change and just have else for cyclic case.
> 
> It can not be embedded there because of the existing tests. How would we
> handle the case when c->desc is _not_ NULL and c->cyclic is false? We would
> need to test again in else, but we can not do this for the
> vchan_issue_pending(&c->vc).
> 
right. Thanks for clarifying it.

Regards,
Santosh



From peter.ujfalusi at ti.com  Wed Apr  3 07:59:11 2013
From: peter.ujfalusi at ti.com (Peter Ujfalusi)
Date: Wed, 3 Apr 2013 13:59:11 +0200
Subject: [PATCH v3] ARM: omap2: twl-common: Add default power configuration
Message-ID: <1364990351-6778-1-git-send-email-peter.ujfalusi@ti.com>

From: Matthias Brugger <matthias.bgg at gmail.com>

This patch adds a generic power script configuration.
When rebooting an OMAP3530 at 125 MHz, the reboot hangs.
With the generic power script, TWL4030 will be reset
when a warm reset occures. This way the OMAP3530 does not
hang on reboot.

Signed-off-by: Matthias Brugger <matthias.bgg at gmail.com>
Signed-off-by: Peter Ujfalusi <peter.ujfalusi at ti.com>
---
Tony, Matthias,

Changes since v2:
- remove the __initdata from all the structures introduced by this patch

Regards,
Peter

 arch/arm/mach-omap2/twl-common.c | 38 ++++++++++++++++++++++++++++++++++++++
 arch/arm/mach-omap2/twl-common.h |  1 +
 2 files changed, 39 insertions(+)

diff --git a/arch/arm/mach-omap2/twl-common.c b/arch/arm/mach-omap2/twl-common.c
index 51e138c..7551bbc 100644
--- a/arch/arm/mach-omap2/twl-common.c
+++ b/arch/arm/mach-omap2/twl-common.c
@@ -121,6 +121,41 @@ static struct twl4030_audio_data omap3_audio_pdata = {
 	.codec = &omap3_codec,
 };
 
+static struct twl4030_ins wrst_seq[] __initdata = {
+	{MSG_SINGULAR(DEV_GRP_NULL, 0x1b, RES_STATE_OFF), 2},
+	{MSG_SINGULAR(DEV_GRP_P1, 0xf, RES_STATE_WRST), 15},
+	{MSG_SINGULAR(DEV_GRP_P1, 0x10, RES_STATE_WRST), 15},
+	{MSG_SINGULAR(DEV_GRP_P1, 0x7, RES_STATE_WRST), 0x60},
+	{MSG_SINGULAR(DEV_GRP_P1, 0x19, RES_STATE_ACTIVE), 2},
+	{MSG_SINGULAR(DEV_GRP_NULL, 0x1b, RES_STATE_ACTIVE), 2},
+};
+
+static struct twl4030_script wrst_script __initdata = {
+	.script = wrst_seq,
+	.size	= ARRAY_SIZE(wrst_seq),
+	.flags	= TWL4030_WRST_SCRIPT,
+};
+
+static struct twl4030_script *omap3_power_scripts[] __initdata = {
+	&wrst_script,
+};
+
+static struct twl4030_resconfig omap3_rconfig[] __initdata = {
+	{ .resource = RES_HFCLKOUT, .devgroup = DEV_GRP_P3, .type = -1,
+		.type2 = -1 },
+	{ .resource = RES_VDD1, .devgroup = DEV_GRP_P1, .type = -1,
+		.type2 = -1 },
+	{ .resource = RES_VDD2, .devgroup = DEV_GRP_P1, .type = -1,
+		.type2 = -1 },
+	{ 0, 0},
+};
+
+static struct twl4030_power_data omap3_power_pdata __initdata = {
+	.scripts	= omap3_power_scripts,
+	.num		= ARRAY_SIZE(omap3_power_scripts),
+	.resource_config = omap3_rconfig,
+};
+
 static struct regulator_consumer_supply omap3_vdda_dac_supplies[] = {
 	REGULATOR_SUPPLY("vdda_dac", "omapdss_venc"),
 };
@@ -225,6 +260,9 @@ void __init omap3_pmic_get_config(struct twl4030_platform_data *pmic_data,
 	if (pdata_flags & TWL_COMMON_PDATA_AUDIO && !pmic_data->audio)
 		pmic_data->audio = &omap3_audio_pdata;
 
+	if (pdata_flags & TWL_COMMON_PDATA_POWER && !pmic_data->power)
+		pmic_data->power = &omap3_power_pdata;
+
 	/* Common regulator configurations */
 	if (regulators_flags & TWL_COMMON_REGULATOR_VDAC && !pmic_data->vdac)
 		pmic_data->vdac = &omap3_vdac_idata;
diff --git a/arch/arm/mach-omap2/twl-common.h b/arch/arm/mach-omap2/twl-common.h
index 24b65d0..b64590b8 100644
--- a/arch/arm/mach-omap2/twl-common.h
+++ b/arch/arm/mach-omap2/twl-common.h
@@ -7,6 +7,7 @@
 #define TWL_COMMON_PDATA_BCI		(1 << 1)
 #define TWL_COMMON_PDATA_MADC		(1 << 2)
 #define TWL_COMMON_PDATA_AUDIO		(1 << 3)
+#define TWL_COMMON_PDATA_POWER		(1 << 4)
 
 /* Common LDO regulators for TWL4030/TWL6030 */
 #define TWL_COMMON_REGULATOR_VDAC	(1 << 0)
-- 
1.8.1.5



From linus.walleij at linaro.org  Wed Apr  3 07:59:54 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Wed, 3 Apr 2013 13:59:54 +0200
Subject: [PATCH 4/6] pinctrl: sunxi: add clock support
In-Reply-To: <51535077.1050203@free-electrons.com>
References: <1363962042-29536-1-git-send-email-emilio@elopez.com.ar>
 <1363962042-29536-5-git-send-email-emilio@elopez.com.ar>
 <CACRpkdbn9c_bAWUN8hTLkeidCnyZ=0nRQRBV39DMkK_0jBfoUQ@mail.gmail.com>
 <51535077.1050203@free-electrons.com>
Message-ID: <CACRpkda80EKT2LbsBCOng=gkdtdd+vbYwkMPiFZUBx7z_aqY+A@mail.gmail.com>

On Wed, Mar 27, 2013 at 9:03 PM, Maxime Ripard
<maxime.ripard at free-electrons.com> wrote:

> Hi Linus,
> Le 27/03/2013 14:14, Linus Walleij a ?crit :
>> On Fri, Mar 22, 2013 at 3:20 PM, Emilio L?pez <emilio at elopez.com.ar> wrote:
>>
>>> For the port controller to work, we need to enable the apb0_pio gate.
>>> This commit adds the ability to enable one clock specified on the device
>>> tree to the pinctrl driver.
>>>
>>> Signed-off-by: Emilio L?pez <emilio at elopez.com.ar>
>>
>> Acked-by: Linus Walleij <linus.walleij at linaro.org>
>>
>> I guess you'll want to merge these as one series to some platform-specific
>> tree, tell me if you want it merged in the pinctrl tree.
>
> The easiest would probably be to merge this patch through your patch,
> with Mike taking the clock driver patches and me taking the dt ones,
> once we agree on the other patches.

OK then, patch applied to the pinctrl tree, thanks!

Yours,
Linus Walleij


From daniel.lezcano at linaro.org  Wed Apr  3 08:09:55 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Wed, 03 Apr 2013 14:09:55 +0200
Subject: [PATCH 5/9] ARM: tegra2: cpuidle: change driver initialization
In-Reply-To: <1364988239.16957.78.camel@jlo-ubuntu-64.nvidia.com>
References: <1364553095-25110-1-git-send-email-daniel.lezcano@linaro.org>
 <1364553095-25110-5-git-send-email-daniel.lezcano@linaro.org>
 <5155BB27.4000405@wwwdotorg.org> <515C101F.1020801@linaro.org>
 <1364988239.16957.78.camel@jlo-ubuntu-64.nvidia.com>
Message-ID: <515C1C13.801@linaro.org>

On 04/03/2013 01:23 PM, Joseph Lo wrote:
> On Wed, 2013-04-03 at 19:18 +0800, Daniel Lezcano wrote:
>> On 03/29/2013 05:02 PM, Stephen Warren wrote:
>>> On 03/29/2013 04:31 AM, Daniel Lezcano wrote:
>>>> Initialize the idle states directly in the driver structure.
>>>>
>>>> That prevents extra structure declaration and memcpy at init time.
>>>
>>> Joseph, can you please review/ack patch 5/9 and patch 6/9. Thanks.
>>
>> Thanks Joseph to review the patches.
>>
>> Rafael is expecting an Acked-by.
>>
>> If you are ok, with these patches, is it possible to ack them please ?
>>
> OK.
> 
> The 5/9 and 6/9 of this series.
> Acked-by: Joseph Lo <josephl at nvidia.com>

Thanks Joseph.




-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From prakash.pm at ti.com  Wed Apr  3 08:13:02 2013
From: prakash.pm at ti.com (Manjunathappa, Prakash)
Date: Wed, 3 Apr 2013 12:13:02 +0000
Subject: [PATCH v4 3/5] ARM: davinci: da850: add SPI1 DT node
In-Reply-To: <1363776419-10563-4-git-send-email-prakash.pm@ti.com>
References: <1363776419-10563-1-git-send-email-prakash.pm@ti.com>
 <1363776419-10563-4-git-send-email-prakash.pm@ti.com>
Message-ID: <A73F36158E33644199EB82C5EC81C7BC3EA4C066@DBDE01.ent.ti.com>

Hi,

On Wed, Mar 20, 2013 at 16:16:57, Manjunathappa, Prakash wrote:
> Patch adds SPI1 DT node along with pinmux data.
> 
> Signed-off-by: Manjunathappa, Prakash <prakash.pm at ti.com>
> ---
>  arch/arm/boot/dts/da850.dtsi |   18 ++++++++++++++++++
>  1 files changed, 18 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
> index 3ec1bda..327fb06 100644
> --- a/arch/arm/boot/dts/da850.dtsi
> +++ b/arch/arm/boot/dts/da850.dtsi
> @@ -62,6 +62,14 @@
>  					0x10 0x00002200 0x0000ff00
>  				>;
>  			};
> +			spi1_pins: pinmux_spi_pins {
> +				pinctrl-single,bits = <
> +					/* SIMO, SOMI, ENA,
> +					 * CLK, CS[0], CS[1]
> +					 */
> +					0x14 0x00111111 0x00ffffff

Since chip select is specific to a board, let me separate it out so as to
allow boards choose accordingly.

Thanks,
Prakash


From daniel.lezcano at linaro.org  Wed Apr  3 08:15:14 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Wed,  3 Apr 2013 14:15:14 +0200
Subject: [PATCH 1/9] ARM: cpuidle: remove useless declaration
Message-ID: <1364991322-20585-1-git-send-email-daniel.lezcano@linaro.org>

The noop functions code is not necessary because the header file is
included in files which are compiled when CONFIG_CPU_IDLE is on.

Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
---
 arch/arm/include/asm/cpuidle.h |    7 +------
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/arch/arm/include/asm/cpuidle.h b/arch/arm/include/asm/cpuidle.h
index 2fca60a..7367787 100644
--- a/arch/arm/include/asm/cpuidle.h
+++ b/arch/arm/include/asm/cpuidle.h
@@ -1,13 +1,8 @@
 #ifndef __ASM_ARM_CPUIDLE_H
 #define __ASM_ARM_CPUIDLE_H
 
-#ifdef CONFIG_CPU_IDLE
 extern int arm_cpuidle_simple_enter(struct cpuidle_device *dev,
-		struct cpuidle_driver *drv, int index);
-#else
-static inline int arm_cpuidle_simple_enter(struct cpuidle_device *dev,
-		struct cpuidle_driver *drv, int index) { return -ENODEV; }
-#endif
+				    struct cpuidle_driver *drv, int index);
 
 /* Common ARM WFI state */
 #define ARM_CPUIDLE_WFI_STATE_PWR(p) {\
-- 
1.7.9.5



From daniel.lezcano at linaro.org  Wed Apr  3 08:15:15 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Wed,  3 Apr 2013 14:15:15 +0200
Subject: [PATCH 2/9] ARM: shmobile: pm: fix init sections
In-Reply-To: <1364991322-20585-1-git-send-email-daniel.lezcano@linaro.org>
References: <1364991322-20585-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1364991322-20585-2-git-send-email-daniel.lezcano@linaro.org>

Add the __init section for the functions which are called
at init time.

Signed-off-by: Daniel Lezcano <daniel.linaro.org>
Acked-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/cpuidle.c   |    4 ++--
 arch/arm/mach-shmobile/pm-sh7372.c |    4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-shmobile/cpuidle.c b/arch/arm/mach-shmobile/cpuidle.c
index 9e05026..068f9ca 100644
--- a/arch/arm/mach-shmobile/cpuidle.c
+++ b/arch/arm/mach-shmobile/cpuidle.c
@@ -36,12 +36,12 @@ static struct cpuidle_driver shmobile_cpuidle_default_driver = {
 
 static struct cpuidle_driver *cpuidle_drv = &shmobile_cpuidle_default_driver;
 
-void shmobile_cpuidle_set_driver(struct cpuidle_driver *drv)
+void __init shmobile_cpuidle_set_driver(struct cpuidle_driver *drv)
 {
 	cpuidle_drv = drv;
 }
 
-int shmobile_cpuidle_init(void)
+int __init shmobile_cpuidle_init(void)
 {
 	struct cpuidle_device *dev = &shmobile_cpuidle_dev;
 
diff --git a/arch/arm/mach-shmobile/pm-sh7372.c b/arch/arm/mach-shmobile/pm-sh7372.c
index a0826a4..f6b14ca 100644
--- a/arch/arm/mach-shmobile/pm-sh7372.c
+++ b/arch/arm/mach-shmobile/pm-sh7372.c
@@ -450,12 +450,12 @@ static struct cpuidle_driver sh7372_cpuidle_driver = {
 	},
 };
 
-static void sh7372_cpuidle_init(void)
+static void __init sh7372_cpuidle_init(void)
 {
 	shmobile_cpuidle_set_driver(&sh7372_cpuidle_driver);
 }
 #else
-static void sh7372_cpuidle_init(void) {}
+static void __init sh7372_cpuidle_init(void) {}
 #endif
 
 #ifdef CONFIG_SUSPEND
-- 
1.7.9.5



From daniel.lezcano at linaro.org  Wed Apr  3 08:15:16 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Wed,  3 Apr 2013 14:15:16 +0200
Subject: [PATCH 3/9] ARM: shmobile: cpuidle: remove useless WFI function
In-Reply-To: <1364991322-20585-1-git-send-email-daniel.lezcano@linaro.org>
References: <1364991322-20585-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1364991322-20585-3-git-send-email-daniel.lezcano@linaro.org>

Remove the shmobile_enter_wfi function which is the same as the
common WFI enter function from the arm cpuidle driver defined
with the ARM_CPUIDLE_WFI_STATE macro.

Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
Acked-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/cpuidle.c |    8 --------
 1 file changed, 8 deletions(-)

diff --git a/arch/arm/mach-shmobile/cpuidle.c b/arch/arm/mach-shmobile/cpuidle.c
index 068f9ca..c872ae8 100644
--- a/arch/arm/mach-shmobile/cpuidle.c
+++ b/arch/arm/mach-shmobile/cpuidle.c
@@ -16,20 +16,12 @@
 #include <asm/cpuidle.h>
 #include <asm/io.h>
 
-int shmobile_enter_wfi(struct cpuidle_device *dev, struct cpuidle_driver *drv,
-		       int index)
-{
-	cpu_do_idle();
-	return 0;
-}
-
 static struct cpuidle_device shmobile_cpuidle_dev;
 static struct cpuidle_driver shmobile_cpuidle_default_driver = {
 	.name			= "shmobile_cpuidle",
 	.owner			= THIS_MODULE,
 	.en_core_tk_irqen	= 1,
 	.states[0]		= ARM_CPUIDLE_WFI_STATE,
-	.states[0].enter	= shmobile_enter_wfi,
 	.safe_state_index	= 0, /* C1 */
 	.state_count		= 1,
 };
-- 
1.7.9.5



From daniel.lezcano at linaro.org  Wed Apr  3 08:15:17 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Wed,  3 Apr 2013 14:15:17 +0200
Subject: [PATCH 4/9] ARM: tegra2: cpuidle: change driver initialization
In-Reply-To: <1364991322-20585-1-git-send-email-daniel.lezcano@linaro.org>
References: <1364991322-20585-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1364991322-20585-4-git-send-email-daniel.lezcano@linaro.org>

Initialize the idle states directly in the driver structure.

That prevents extra structure declaration and memcpy at init time.

Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
Reviewed-by: Joseph Lo <josephl at nvidia.com>
Acked-by: Joseph Lo <josephl at nvidia.com>
---
 arch/arm/mach-tegra/cpuidle-tegra20.c |   40 ++++++++++++++++-----------------
 1 file changed, 20 insertions(+), 20 deletions(-)

diff --git a/arch/arm/mach-tegra/cpuidle-tegra20.c b/arch/arm/mach-tegra/cpuidle-tegra20.c
index 825ced4..1ad1a67 100644
--- a/arch/arm/mach-tegra/cpuidle-tegra20.c
+++ b/arch/arm/mach-tegra/cpuidle-tegra20.c
@@ -43,28 +43,32 @@ static atomic_t abort_barrier;
 static int tegra20_idle_lp2_coupled(struct cpuidle_device *dev,
 				    struct cpuidle_driver *drv,
 				    int index);
+#define TEGRA20_MAX_STATES 2
+#else
+#define TEGRA20_MAX_STATES 1
 #endif
 
-static struct cpuidle_state tegra_idle_states[] = {
-	[0] = ARM_CPUIDLE_WFI_STATE_PWR(600),
-#ifdef CONFIG_PM_SLEEP
-	[1] = {
-		.enter			= tegra20_idle_lp2_coupled,
-		.exit_latency		= 5000,
-		.target_residency	= 10000,
-		.power_usage		= 0,
-		.flags			= CPUIDLE_FLAG_TIME_VALID |
-					  CPUIDLE_FLAG_COUPLED,
-		.name			= "powered-down",
-		.desc			= "CPU power gated",
-	},
-#endif
-};
-
 static struct cpuidle_driver tegra_idle_driver = {
 	.name = "tegra_idle",
 	.owner = THIS_MODULE,
 	.en_core_tk_irqen = 1,
+	.states = {
+		ARM_CPUIDLE_WFI_STATE_PWR(600),
+#ifdef CONFIG_PM_SLEEP
+		{
+			.enter            = tegra20_idle_lp2_coupled,
+			.exit_latency     = 5000,
+			.target_residency = 10000,
+			.power_usage      = 0,
+			.flags            = CPUIDLE_FLAG_TIME_VALID |
+			CPUIDLE_FLAG_COUPLED,
+			.name             = "powered-down",
+			.desc             = "CPU power gated",
+		},
+#endif
+	},
+	.state_count = TEGRA20_MAX_STATES,
+	.safe_state_index = 0,
 };
 
 static DEFINE_PER_CPU(struct cpuidle_device, tegra_idle_device);
@@ -226,10 +230,6 @@ int __init tegra20_cpuidle_init(void)
 	tegra_tear_down_cpu = tegra20_tear_down_cpu;
 #endif
 
-	drv->state_count = ARRAY_SIZE(tegra_idle_states);
-	memcpy(drv->states, tegra_idle_states,
-			drv->state_count * sizeof(drv->states[0]));
-
 	ret = cpuidle_register_driver(&tegra_idle_driver);
 	if (ret) {
 		pr_err("CPUidle driver registration failed\n");
-- 
1.7.9.5



From daniel.lezcano at linaro.org  Wed Apr  3 08:15:18 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Wed,  3 Apr 2013 14:15:18 +0200
Subject: [PATCH 5/9] ARM: tegra: cpuidle: remove useless initialization
In-Reply-To: <1364991322-20585-1-git-send-email-daniel.lezcano@linaro.org>
References: <1364991322-20585-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1364991322-20585-5-git-send-email-daniel.lezcano@linaro.org>

dev->state_count is initialized automatically by cpuidle_register_device.

When drv->state_count is equal to dev->state_count, no need to init this
field, so removing it.

Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
Reviewed-by: Joseph Lo <josephl at nvidia.com>
Acked-by: Joseph Lo <josephl at nvidia.com>
---
 arch/arm/mach-tegra/cpuidle-tegra114.c |    1 -
 arch/arm/mach-tegra/cpuidle-tegra20.c  |    1 -
 arch/arm/mach-tegra/cpuidle-tegra30.c  |    1 -
 3 files changed, 3 deletions(-)

diff --git a/arch/arm/mach-tegra/cpuidle-tegra114.c b/arch/arm/mach-tegra/cpuidle-tegra114.c
index 0f4e8c4..c527cff 100644
--- a/arch/arm/mach-tegra/cpuidle-tegra114.c
+++ b/arch/arm/mach-tegra/cpuidle-tegra114.c
@@ -49,7 +49,6 @@ int __init tegra114_cpuidle_init(void)
 		dev = &per_cpu(tegra_idle_device, cpu);
 		dev->cpu = cpu;
 
-		dev->state_count = drv->state_count;
 		ret = cpuidle_register_device(dev);
 		if (ret) {
 			pr_err("CPU%u: CPUidle device registration failed\n",
diff --git a/arch/arm/mach-tegra/cpuidle-tegra20.c b/arch/arm/mach-tegra/cpuidle-tegra20.c
index 1ad1a67..b94d76a 100644
--- a/arch/arm/mach-tegra/cpuidle-tegra20.c
+++ b/arch/arm/mach-tegra/cpuidle-tegra20.c
@@ -243,7 +243,6 @@ int __init tegra20_cpuidle_init(void)
 		dev->coupled_cpus = *cpu_possible_mask;
 #endif
 
-		dev->state_count = drv->state_count;
 		ret = cpuidle_register_device(dev);
 		if (ret) {
 			pr_err("CPU%u: CPUidle device registration failed\n",
diff --git a/arch/arm/mach-tegra/cpuidle-tegra30.c b/arch/arm/mach-tegra/cpuidle-tegra30.c
index 8b50cf4..c4e01fe 100644
--- a/arch/arm/mach-tegra/cpuidle-tegra30.c
+++ b/arch/arm/mach-tegra/cpuidle-tegra30.c
@@ -176,7 +176,6 @@ int __init tegra30_cpuidle_init(void)
 		dev = &per_cpu(tegra_idle_device, cpu);
 		dev->cpu = cpu;
 
-		dev->state_count = drv->state_count;
 		ret = cpuidle_register_device(dev);
 		if (ret) {
 			pr_err("CPU%u: CPUidle device registration failed\n",
-- 
1.7.9.5



From daniel.lezcano at linaro.org  Wed Apr  3 08:15:19 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Wed,  3 Apr 2013 14:15:19 +0200
Subject: [PATCH 6/9] ARM: davinci: cpuidle: fix wrong enter function
In-Reply-To: <1364991322-20585-1-git-send-email-daniel.lezcano@linaro.org>
References: <1364991322-20585-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1364991322-20585-6-git-send-email-daniel.lezcano@linaro.org>

The davinci_enter_idle is called from the cpuidle with the
cpuidle_wrap_enter function. This one does the time compution
for entering and exiting the idle function and then we call
again cpuidle_wrap_enter for cpu_do_idle. This is wrong, we
are calling recursively cpuidle_wrap_enter for nothing and
furthermore reenabling the local irq.

Remove this and replace it by the cpu_do_idle function.

Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
Acked-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
---
 arch/arm/mach-davinci/cpuidle.c |    8 ++------
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-davinci/cpuidle.c b/arch/arm/mach-davinci/cpuidle.c
index 5ac9e93..22d6d4a 100644
--- a/arch/arm/mach-davinci/cpuidle.c
+++ b/arch/arm/mach-davinci/cpuidle.c
@@ -50,14 +50,10 @@ static void davinci_save_ddr_power(int enter, bool pdown)
 
 /* Actual code that puts the SoC in different idle states */
 static int davinci_enter_idle(struct cpuidle_device *dev,
-				struct cpuidle_driver *drv,
-						int index)
+			      struct cpuidle_driver *drv, int index)
 {
 	davinci_save_ddr_power(1, ddr2_pdown);
-
-	index = cpuidle_wrap_enter(dev,	drv, index,
-				arm_cpuidle_simple_enter);
-
+	cpu_do_idle();
 	davinci_save_ddr_power(0, ddr2_pdown);
 
 	return index;
-- 
1.7.9.5



From daniel.lezcano at linaro.org  Wed Apr  3 08:15:20 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Wed,  3 Apr 2013 14:15:20 +0200
Subject: [PATCH 7/9] intel: cpuidle: remove stop/start critical timings
In-Reply-To: <1364991322-20585-1-git-send-email-daniel.lezcano@linaro.org>
References: <1364991322-20585-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1364991322-20585-7-git-send-email-daniel.lezcano@linaro.org>

The start/stop_critical_timings are called from arch/x86/kernel/process.c
in the cpu_idle loop function.

Remove the ones in the cpuidle driver.

Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
---
 drivers/idle/intel_idle.c |    3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/idle/intel_idle.c b/drivers/idle/intel_idle.c
index 5d66750..c99c31e 100644
--- a/drivers/idle/intel_idle.c
+++ b/drivers/idle/intel_idle.c
@@ -339,7 +339,6 @@ static int intel_idle(struct cpuidle_device *dev,
 	if (!(lapic_timer_reliable_states & (1 << (cstate))))
 		clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &cpu);
 
-	stop_critical_timings();
 	if (!need_resched()) {
 
 		__monitor((void *)&current_thread_info()->flags, 0, 0);
@@ -348,8 +347,6 @@ static int intel_idle(struct cpuidle_device *dev,
 			__mwait(eax, ecx);
 	}
 
-	start_critical_timings();
-
 	if (!(lapic_timer_reliable_states & (1 << (cstate))))
 		clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &cpu);
 
-- 
1.7.9.5



From daniel.lezcano at linaro.org  Wed Apr  3 08:15:21 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Wed,  3 Apr 2013 14:15:21 +0200
Subject: [PATCH 8/9] ARM: omap3: cpuidle: enable time keeping
In-Reply-To: <1364991322-20585-1-git-send-email-daniel.lezcano@linaro.org>
References: <1364991322-20585-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1364991322-20585-8-git-send-email-daniel.lezcano@linaro.org>

The TIME_VALID flag is specified for the different states but
the time residency computation is not done, no tk flag, no time
computation in the idle function.

Set the en_core_tk_irqen flag to activate it.

Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
Acked-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
---
 arch/arm/mach-omap2/cpuidle34xx.c |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/cpuidle34xx.c b/arch/arm/mach-omap2/cpuidle34xx.c
index 80392fc..4f67a5b 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -274,8 +274,9 @@ static int omap3_enter_idle_bm(struct cpuidle_device *dev,
 static DEFINE_PER_CPU(struct cpuidle_device, omap3_idle_dev);
 
 static struct cpuidle_driver omap3_idle_driver = {
-	.name =		"omap3_idle",
-	.owner =	THIS_MODULE,
+	.name             = "omap3_idle",
+	.owner            = THIS_MODULE,
+	.en_core_tk_irqen = 1,
 	.states = {
 		{
 			.enter		  = omap3_enter_idle_bm,
-- 
1.7.9.5



From daniel.lezcano at linaro.org  Wed Apr  3 08:15:22 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Wed,  3 Apr 2013 14:15:22 +0200
Subject: [PATCH 9/9] POWERPC: pseries: cpuidle: use time keeping flag
In-Reply-To: <1364991322-20585-1-git-send-email-daniel.lezcano@linaro.org>
References: <1364991322-20585-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1364991322-20585-9-git-send-email-daniel.lezcano@linaro.org>

The current code computes the idle time but that can be handled
by the cpuidle framework if we enable the .en_core_tk_irqen flag.

Set the flag and remove the code related to the time computation.

Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
Signed-off-by: Deepthi Dharwar <deepthi at linux.vnet.ibm.com>
---
 arch/powerpc/platforms/pseries/processor_idle.c |   35 ++++++++++-------------
 1 file changed, 15 insertions(+), 20 deletions(-)

diff --git a/arch/powerpc/platforms/pseries/processor_idle.c b/arch/powerpc/platforms/pseries/processor_idle.c
index 4d806b4..a197120 100644
--- a/arch/powerpc/platforms/pseries/processor_idle.c
+++ b/arch/powerpc/platforms/pseries/processor_idle.c
@@ -23,8 +23,9 @@
 #include "pseries.h"
 
 struct cpuidle_driver pseries_idle_driver = {
-	.name =		"pseries_idle",
-	.owner =	THIS_MODULE,
+	.name             = "pseries_idle",
+	.owner            = THIS_MODULE,
+	.en_core_tk_irqen = 1,
 };
 
 #define MAX_IDLE_STATE_COUNT	2
@@ -33,10 +34,8 @@ static int max_idle_state = MAX_IDLE_STATE_COUNT - 1;
 static struct cpuidle_device __percpu *pseries_cpuidle_devices;
 static struct cpuidle_state *cpuidle_state_table;
 
-static inline void idle_loop_prolog(unsigned long *in_purr, ktime_t *kt_before)
+static inline void idle_loop_prolog(unsigned long *in_purr)
 {
-
-	*kt_before = ktime_get();
 	*in_purr = mfspr(SPRN_PURR);
 	/*
 	 * Indicate to the HV that we are idle. Now would be
@@ -45,12 +44,10 @@ static inline void idle_loop_prolog(unsigned long *in_purr, ktime_t *kt_before)
 	get_lppaca()->idle = 1;
 }
 
-static inline  s64 idle_loop_epilog(unsigned long in_purr, ktime_t kt_before)
+static inline void idle_loop_epilog(unsigned long in_purr)
 {
 	get_lppaca()->wait_state_cycles += mfspr(SPRN_PURR) - in_purr;
 	get_lppaca()->idle = 0;
-
-	return ktime_to_us(ktime_sub(ktime_get(), kt_before));
 }
 
 static int snooze_loop(struct cpuidle_device *dev,
@@ -58,10 +55,9 @@ static int snooze_loop(struct cpuidle_device *dev,
 			int index)
 {
 	unsigned long in_purr;
-	ktime_t kt_before;
 	int cpu = dev->cpu;
 
-	idle_loop_prolog(&in_purr, &kt_before);
+	idle_loop_prolog(&in_purr);
 	local_irq_enable();
 	set_thread_flag(TIF_POLLING_NRFLAG);
 
@@ -75,8 +71,8 @@ static int snooze_loop(struct cpuidle_device *dev,
 	clear_thread_flag(TIF_POLLING_NRFLAG);
 	smp_mb();
 
-	dev->last_residency =
-		(int)idle_loop_epilog(in_purr, kt_before);
+	idle_loop_epilog(in_purr);
+
 	return index;
 }
 
@@ -102,9 +98,8 @@ static int dedicated_cede_loop(struct cpuidle_device *dev,
 				int index)
 {
 	unsigned long in_purr;
-	ktime_t kt_before;
 
-	idle_loop_prolog(&in_purr, &kt_before);
+	idle_loop_prolog(&in_purr);
 	get_lppaca()->donate_dedicated_cpu = 1;
 
 	ppc64_runlatch_off();
@@ -112,8 +107,9 @@ static int dedicated_cede_loop(struct cpuidle_device *dev,
 	check_and_cede_processor();
 
 	get_lppaca()->donate_dedicated_cpu = 0;
-	dev->last_residency =
-		(int)idle_loop_epilog(in_purr, kt_before);
+
+	idle_loop_epilog(in_purr);
+
 	return index;
 }
 
@@ -122,9 +118,8 @@ static int shared_cede_loop(struct cpuidle_device *dev,
 			int index)
 {
 	unsigned long in_purr;
-	ktime_t kt_before;
 
-	idle_loop_prolog(&in_purr, &kt_before);
+	idle_loop_prolog(&in_purr);
 
 	/*
 	 * Yield the processor to the hypervisor.  We return if
@@ -135,8 +130,8 @@ static int shared_cede_loop(struct cpuidle_device *dev,
 	 */
 	check_and_cede_processor();
 
-	dev->last_residency =
-		(int)idle_loop_epilog(in_purr, kt_before);
+	idle_loop_epilog(in_purr);
+
 	return index;
 }
 
-- 
1.7.9.5



From linus.walleij at linaro.org  Wed Apr  3 08:18:14 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Wed, 3 Apr 2013 14:18:14 +0200
Subject: [PATCH] pinctrl:sirf:re-arch and add support for new SiRFatlas6
 SoC
In-Reply-To: <CAGsJ_4wmn-LxxX-JeSJzdkVFSUeJ=vQrKHJr9yUtsoxG2BFHtw@mail.gmail.com>
References: <1363597988-7409-1-git-send-email-Barry.Song@csr.com>
 <CACRpkdYUTQ_7V1CbKbx05zgBONj6iUi=ekzSwmZz8dqeRx7ZJw@mail.gmail.com>
 <CAGsJ_4wmn-LxxX-JeSJzdkVFSUeJ=vQrKHJr9yUtsoxG2BFHtw@mail.gmail.com>
Message-ID: <CACRpkdaMYTXpnfg8MhRP5Fs_Qn2gwv=Xuk3YSYejxt+vK9D6+w@mail.gmail.com>

On Thu, Mar 28, 2013 at 7:27 AM, Barry Song <21cnbao at gmail.com> wrote:
> 2013/3/28, Linus Walleij <linus.walleij at linaro.org>:

>>> Signed-off-by: Barry Song <Baohua.Song at csr.com>
>>
>> This is OK but can you please:
>
> ok. one issue is recently Arnd has given another changes in
> pinctrl-sirf in arm-soc multiple platform branch:
> https://git.kernel.org/cgit/linux/kernel/git/arm/arm-soc.git/commit/?h=prima2/multiplatform&id=67d71344fd09223820eb9de39b597ec29f035e89
>
> it makes us easily to get merging conflict. what is your suggestion
> about taking all these changes in 3.10?

Please send this to where the rest of the patches are with my ACK
(I guess the ARM SoC tree?)

Acked-by: Linus Walleij <linus.walleij at linaro.org>

Yours,
Linus Walleij


From daniel.lezcano at linaro.org  Wed Apr  3 08:23:23 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Wed, 03 Apr 2013 14:23:23 +0200
Subject: [PATCH 1/9] ARM: cpuidle: remove useless declaration
In-Reply-To: <1364991322-20585-1-git-send-email-daniel.lezcano@linaro.org>
References: <1364991322-20585-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <515C1F3B.5040008@linaro.org>

On 04/03/2013 02:15 PM, Daniel Lezcano wrote:
> The noop functions code is not necessary because the header file is
> included in files which are compiled when CONFIG_CPU_IDLE is on.
>
> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>

I have been involved in the development of this file. I know Rob is no
longer working on this neither monitoring the code.

Russell are you ok with this patch ? Rafael needs your ack to take this
patch into its tree.

Thanks

-- Daniel

> ---
>  arch/arm/include/asm/cpuidle.h |    7 +------
>  1 file changed, 1 insertion(+), 6 deletions(-)
>
> diff --git a/arch/arm/include/asm/cpuidle.h b/arch/arm/include/asm/cpuidle.h
> index 2fca60a..7367787 100644
> --- a/arch/arm/include/asm/cpuidle.h
> +++ b/arch/arm/include/asm/cpuidle.h
> @@ -1,13 +1,8 @@
>  #ifndef __ASM_ARM_CPUIDLE_H
>  #define __ASM_ARM_CPUIDLE_H
>  
> -#ifdef CONFIG_CPU_IDLE
>  extern int arm_cpuidle_simple_enter(struct cpuidle_device *dev,
> -		struct cpuidle_driver *drv, int index);
> -#else
> -static inline int arm_cpuidle_simple_enter(struct cpuidle_device *dev,
> -		struct cpuidle_driver *drv, int index) { return -ENODEV; }
> -#endif
> +				    struct cpuidle_driver *drv, int index);
>  
>  /* Common ARM WFI state */
>  #define ARM_CPUIDLE_WFI_STATE_PWR(p) {\


-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From ulf.hansson at stericsson.com  Wed Apr  3 08:26:57 2013
From: ulf.hansson at stericsson.com (Ulf Hansson)
Date: Wed, 3 Apr 2013 14:26:57 +0200
Subject: [PATCH V3 1/3] clk: ux500: Add support for sysctrl clocks
Message-ID: <1364992017-12683-1-git-send-email-ulf.hansson@stericsson.com>

From: Ulf Hansson <ulf.hansson at linaro.org>

The abx500 sysctrl clocks are using the ab8500 sysctrl driver to
modify the clock hardware. Sysctrl clocks are represented by a
ab8500 sysctrl register and with a corresponding bitmask.

The sysctrl clocks are slow path clocks, which means clk_prepare
and clk_unprepare will be used to gate|ungate these clocks.

Signed-off-by: Ulf Hansson <ulf.hansson at linaro.org>
---

Changes in v3:
	- Fixed error check at clk registration.
Changes in v2:
	- Removed wrong header file.
---
 drivers/clk/ux500/Makefile      |    1 +
 drivers/clk/ux500/clk-sysctrl.c |  221 +++++++++++++++++++++++++++++++++++++++
 drivers/clk/ux500/clk.h         |   29 +++++
 3 files changed, 251 insertions(+)
 create mode 100644 drivers/clk/ux500/clk-sysctrl.c

diff --git a/drivers/clk/ux500/Makefile b/drivers/clk/ux500/Makefile
index bcc0c11..c6a806e 100644
--- a/drivers/clk/ux500/Makefile
+++ b/drivers/clk/ux500/Makefile
@@ -5,6 +5,7 @@
 # Clock types
 obj-y += clk-prcc.o
 obj-y += clk-prcmu.o
+obj-y += clk-sysctrl.o
 
 # Clock definitions
 obj-y += u8500_clk.o
diff --git a/drivers/clk/ux500/clk-sysctrl.c b/drivers/clk/ux500/clk-sysctrl.c
new file mode 100644
index 0000000..bc7e9bd
--- /dev/null
+++ b/drivers/clk/ux500/clk-sysctrl.c
@@ -0,0 +1,221 @@
+/*
+ * Sysctrl clock implementation for ux500 platform.
+ *
+ * Copyright (C) 2013 ST-Ericsson SA
+ * Author: Ulf Hansson <ulf.hansson at linaro.org>
+ *
+ * License terms: GNU General Public License (GPL) version 2
+ */
+
+#include <linux/clk-provider.h>
+#include <linux/mfd/abx500/ab8500-sysctrl.h>
+#include <linux/device.h>
+#include <linux/slab.h>
+#include <linux/delay.h>
+#include <linux/io.h>
+#include <linux/err.h>
+#include "clk.h"
+
+#define SYSCTRL_MAX_NUM_PARENTS 4
+
+#define to_clk_sysctrl(_hw) container_of(_hw, struct clk_sysctrl, hw)
+
+struct clk_sysctrl {
+	struct clk_hw hw;
+	struct device *dev;
+	u8 parent_index;
+	u16 reg_sel[SYSCTRL_MAX_NUM_PARENTS];
+	u8 reg_mask[SYSCTRL_MAX_NUM_PARENTS];
+	u8 reg_bits[SYSCTRL_MAX_NUM_PARENTS];
+	unsigned long rate;
+	unsigned long enable_delay_us;
+};
+
+/* Sysctrl clock operations. */
+
+static int clk_sysctrl_prepare(struct clk_hw *hw)
+{
+	int ret;
+	struct clk_sysctrl *clk = to_clk_sysctrl(hw);
+
+	ret = ab8500_sysctrl_write(clk->reg_sel[0], clk->reg_mask[0],
+				clk->reg_bits[0]);
+
+	if (!ret && clk->enable_delay_us)
+		usleep_range(clk->enable_delay_us, clk->enable_delay_us);
+
+	return ret;
+}
+
+static void clk_sysctrl_unprepare(struct clk_hw *hw)
+{
+	struct clk_sysctrl *clk = to_clk_sysctrl(hw);
+	if (ab8500_sysctrl_clear(clk->reg_sel[0], clk->reg_mask[0]))
+		dev_err(clk->dev, "clk_sysctrl: %s fail to clear %s.\n",
+			__func__, __clk_get_name(hw->clk));
+}
+
+static unsigned long clk_sysctrl_recalc_rate(struct clk_hw *hw,
+					unsigned long parent_rate)
+{
+	struct clk_sysctrl *clk = to_clk_sysctrl(hw);
+	return clk->rate;
+}
+
+static int clk_sysctrl_set_parent(struct clk_hw *hw, u8 index)
+{
+	struct clk_sysctrl *clk = to_clk_sysctrl(hw);
+	u8 old_index = clk->parent_index;
+	int ret = 0;
+
+	if (clk->reg_sel[old_index]) {
+		ret = ab8500_sysctrl_clear(clk->reg_sel[old_index],
+					clk->reg_mask[old_index]);
+		if (ret)
+			return ret;
+	}
+
+	if (clk->reg_sel[index]) {
+		ret = ab8500_sysctrl_write(clk->reg_sel[index],
+					clk->reg_mask[index],
+					clk->reg_bits[index]);
+		if (ret) {
+			if (clk->reg_sel[old_index])
+				ab8500_sysctrl_write(clk->reg_sel[old_index],
+						clk->reg_mask[old_index],
+						clk->reg_bits[old_index]);
+			return ret;
+		}
+	}
+	clk->parent_index = index;
+
+	return ret;
+}
+
+static u8 clk_sysctrl_get_parent(struct clk_hw *hw)
+{
+	struct clk_sysctrl *clk = to_clk_sysctrl(hw);
+	return clk->parent_index;
+}
+
+static struct clk_ops clk_sysctrl_gate_ops = {
+	.prepare = clk_sysctrl_prepare,
+	.unprepare = clk_sysctrl_unprepare,
+};
+
+static struct clk_ops clk_sysctrl_gate_fixed_rate_ops = {
+	.prepare = clk_sysctrl_prepare,
+	.unprepare = clk_sysctrl_unprepare,
+	.recalc_rate = clk_sysctrl_recalc_rate,
+};
+
+static struct clk_ops clk_sysctrl_set_parent_ops = {
+	.set_parent = clk_sysctrl_set_parent,
+	.get_parent = clk_sysctrl_get_parent,
+};
+
+static struct clk *clk_reg_sysctrl(struct device *dev,
+				const char *name,
+				const char **parent_names,
+				u8 num_parents,
+				u16 *reg_sel,
+				u8 *reg_mask,
+				u8 *reg_bits,
+				unsigned long rate,
+				unsigned long enable_delay_us,
+				unsigned long flags,
+				struct clk_ops *clk_sysctrl_ops)
+{
+	struct clk_sysctrl *clk;
+	struct clk_init_data clk_sysctrl_init;
+	struct clk *clk_reg;
+	int i;
+
+	if (!dev)
+		return ERR_PTR(-EINVAL);
+
+	if (!name || (num_parents > SYSCTRL_MAX_NUM_PARENTS)) {
+		dev_err(dev, "clk_sysctrl: invalid arguments passed\n");
+		return ERR_PTR(-EINVAL);
+	}
+
+	clk = devm_kzalloc(dev, sizeof(struct clk_sysctrl), GFP_KERNEL);
+	if (!clk) {
+		dev_err(dev, "clk_sysctrl: could not allocate clk\n");
+		return ERR_PTR(-ENOMEM);
+	}
+
+	for (i = 0; i < num_parents; i++) {
+		clk->reg_sel[i] = reg_sel[i];
+		clk->reg_bits[i] = reg_bits[i];
+		clk->reg_mask[i] = reg_mask[i];
+	}
+
+	clk->parent_index = 0;
+	clk->rate = rate;
+	clk->enable_delay_us = enable_delay_us;
+	clk->dev = dev;
+
+	clk_sysctrl_init.name = name;
+	clk_sysctrl_init.ops = clk_sysctrl_ops;
+	clk_sysctrl_init.flags = flags;
+	clk_sysctrl_init.parent_names = parent_names;
+	clk_sysctrl_init.num_parents = num_parents;
+	clk->hw.init = &clk_sysctrl_init;
+
+	clk_reg = devm_clk_register(clk->dev, &clk->hw);
+	if (IS_ERR(clk_reg))
+		dev_err(dev, "clk_sysctrl: clk_register failed\n");
+
+	return clk_reg;
+}
+
+struct clk *clk_reg_sysctrl_gate(struct device *dev,
+				const char *name,
+				const char *parent_name,
+				u16 reg_sel,
+				u8 reg_mask,
+				u8 reg_bits,
+				unsigned long enable_delay_us,
+				unsigned long flags)
+{
+	const char **parent_names = (parent_name ? &parent_name : NULL);
+	u8 num_parents = (parent_name ? 1 : 0);
+
+	return clk_reg_sysctrl(dev, name, parent_names, num_parents,
+			&reg_sel, &reg_mask, &reg_bits, 0, enable_delay_us,
+			flags, &clk_sysctrl_gate_ops);
+}
+
+struct clk *clk_reg_sysctrl_gate_fixed_rate(struct device *dev,
+					const char *name,
+					const char *parent_name,
+					u16 reg_sel,
+					u8 reg_mask,
+					u8 reg_bits,
+					unsigned long rate,
+					unsigned long enable_delay_us,
+					unsigned long flags)
+{
+	const char **parent_names = (parent_name ? &parent_name : NULL);
+	u8 num_parents = (parent_name ? 1 : 0);
+
+	return clk_reg_sysctrl(dev, name, parent_names, num_parents,
+			&reg_sel, &reg_mask, &reg_bits,
+			rate, enable_delay_us, flags,
+			&clk_sysctrl_gate_fixed_rate_ops);
+}
+
+struct clk *clk_reg_sysctrl_set_parent(struct device *dev,
+				const char *name,
+				const char **parent_names,
+				u8 num_parents,
+				u16 *reg_sel,
+				u8 *reg_mask,
+				u8 *reg_bits,
+				unsigned long flags)
+{
+	return clk_reg_sysctrl(dev, name, parent_names, num_parents,
+			reg_sel, reg_mask, reg_bits, 0, 0, flags,
+			&clk_sysctrl_set_parent_ops);
+}
diff --git a/drivers/clk/ux500/clk.h b/drivers/clk/ux500/clk.h
index c3e4491..3d2dfdc 100644
--- a/drivers/clk/ux500/clk.h
+++ b/drivers/clk/ux500/clk.h
@@ -11,6 +11,7 @@
 #define __UX500_CLK_H
 
 #include <linux/clk.h>
+#include <linux/device.h>
 
 struct clk *clk_reg_prcc_pclk(const char *name,
 			      const char *parent_name,
@@ -57,4 +58,32 @@ struct clk *clk_reg_prcmu_opp_volt_scalable(const char *name,
 					    unsigned long rate,
 					    unsigned long flags);
 
+struct clk *clk_reg_sysctrl_gate(struct device *dev,
+				 const char *name,
+				 const char *parent_name,
+				 u16 reg_sel,
+				 u8 reg_mask,
+				 u8 reg_bits,
+				 unsigned long enable_delay_us,
+				 unsigned long flags);
+
+struct clk *clk_reg_sysctrl_gate_fixed_rate(struct device *dev,
+					    const char *name,
+					    const char *parent_name,
+					    u16 reg_sel,
+					    u8 reg_mask,
+					    u8 reg_bits,
+					    unsigned long rate,
+					    unsigned long enable_delay_us,
+					    unsigned long flags);
+
+struct clk *clk_reg_sysctrl_set_parent(struct device *dev,
+				       const char *name,
+				       const char **parent_names,
+				       u8 num_parents,
+				       u16 *reg_sel,
+				       u8 *reg_mask,
+				       u8 *reg_bits,
+				       unsigned long flags);
+
 #endif /* __UX500_CLK_H */
-- 
1.7.10



From thomas.petazzoni at free-electrons.com  Wed Apr  3 08:27:12 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Wed, 3 Apr 2013 14:27:12 +0200
Subject: [PATCHv7 00/17] PCIe support for the Armada 370 and Armada XP SoCs
In-Reply-To: <1364395234-11195-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1364395234-11195-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <20130403142712.160be55e@skate>

Bjorn, Rob, Grant, Russell,

Through this e-mail, I'd like to send you a kind reminder about this
patch series. The latest version has been sent a week ago, and there
has been only minor changes requested since v4 sent early March, i.e a
month ago. Therefore, I would hope for this series to enter 3.10.

But this patch set is touching areas you are the maintainer for, so I
would appreciate if you could do a formal review and give your comments
or your Ack. I would especially appreciate if you do so in the very
near future, so that if there are comments, I'll have the time to fix
them and resubmit and updated version in time.

Here are the patches, classified by maintainer area:

 * For Grant Likely and Rob Herring, the drivers/of patches:

   [PATCHv7 01/17] of/pci: Provide support for parsing PCI DT ranges property
   http://lists.infradead.org/pipermail/linux-arm-kernel/2013-March/158556.html

     this patch has been around since 3 months now, and has seen a
     number of iterations, first from Thierry Reding, and then by
     Andrew Murray. It is also used by Thierry Reding's PCIe driver,
     and possibly by the upcoming Exynos PCIe driver as well.

   [PATCHv7 02/17] of/pci: Add of_pci_get_devfn() function
   http://lists.infradead.org/pipermail/linux-arm-kernel/2013-March/158550.html

     this patch has been around since 3 months, with no major change
     since then.

   [PATCHv7 03/17] of/pci: Add of_pci_parse_bus_range() function
   http://lists.infradead.org/pipermail/linux-arm-kernel/2013-March/158551.html

     same thing.

 * For Bjorn Helgaas, the drivers/pci/ patches:

   [PATCHv7 04/17] pci: infrastructure to add drivers in drivers/pci/host
   http://lists.infradead.org/pipermail/linux-arm-kernel/2013-March/158552.html

   [PATCHv7 08/17] pci: PCIe driver for Marvell Armada 370/XP systems
   http://lists.infradead.org/pipermail/linux-arm-kernel/2013-March/158566.html

 * For Russell King, the arch/arm/kernel/ patch:

   [PATCHv7 05/17] arm: pci: add a align_resource hook
   http://lists.infradead.org/pipermail/linux-arm-kernel/2013-March/158553.html

     this patch has been around for more than two months now, and has
     been submitted last week to the patch tracking system, at
     http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=7683/1.

For more details, see the cover letter below, or of course, do not
hesitate to request for additional ones as needed.

Thanks a lot for your support,

Thomas


On Wed, 27 Mar 2013 15:40:17 +0100, Thomas Petazzoni wrote:
> Hello,
> 
> This series of patches introduces PCIe support for the Marvell Armada
> 370 and Armada XP. In the future, we plan to extend the driver to
> cover Kirkwood platforms, and possibly other Marvell EBU platforms as
> well.
> 
> As we are approaching 3.10, I would now like to get formal Acked-by,
> or disagreements from the following maintainers/developers :
> 
>  * Grant Likely, as the OF maintainer, for patches 1, 2 and 3
> 
>    [PATCH v5 01/17] of/pci: Provide support for parsing PCI DT ranges
>    [PATCH v5 02/17] of/pci: Add of_pci_get_devfn() function
>    [PATCH v5 03/17] of/pci: Add of_pci_parse_bus_range() function
> 
>  * Bjorn Helgaas, as the PCI maintainer, for patches 4 and 8
> 
>    [PATCH v5 04/17] pci: infrastructure to add drivers in drivers/pci/host
>    [PATCH v5 08/17] pci: PCIe driver for Marvell Armada 370/XP systems
> 
>  * Russell King, as the ARM maintainer, for patch 5
> 
>    [PATCH v5 05/17] arm: pci: add a align_resource hook
> 
>  * Arnd Bergmann, Mitch Bradley and Jason Gunthorpe, for patch 8 (the
>    PCIe driver itself), and specifically the Device Tree binding.
> 
>    [PATCH v5 08/17] pci: PCIe driver for Marvell Armada 370/XP systems
> 
> This patch set depends on:
> 
>  * The arm-soc/mvebu/cleanup branch in Arnd and Olof arm-soc tree
> 
>  * [PATCH v3 for 3.10] Introduce a Marvell EBU MBus driver
>    http://lists.infradead.org/pipermail/linux-arm-kernel/2013-March/156883.html
> 
> For easier testing, the code has been pushed to:
> 
>   git://github.com/MISL-EBU-System-SW/mainline-public.git marvell-pcie-v7
> 
> This PATCHv7 follows:
>  * PATCHv6, sent on March, 26st 2013
>  * PATCHv5, sent on March, 21st 2013
>  * PATCHv4, sent on March, 8th 2013
>  * PATCHv3, sent on February, 12th 2013
>  * PATCHv2, sent on January, 28th 2013
>  * RFCv1, sent on December, 7th 2012
> 
> Changes between v6 and v7:
> 
>  * Use assigned-addresses in the DT subnodes for the MMIO PCIe
>    registers, in order to align with what Thierry is doing on the
>    Tegra PCIe driver.
> 
>  * Added empty 'ranges;' properties in the subnodes, as requested by
>    Arnd. Note that due to this, it is not possible to remove the
>    #address-cells and #size-cells properties from the subnodes, as
>    Jason Gunthorpe requested, otherwise the DT compiler complains with:
> 
>      Warning (ranges_format): /soc/pcie-controller/pcie at 1,0 has empty
>      "ranges" property but its #address-cells (2) differs from
>      /soc/pcie-controller (3)
> 
>      Warning (ranges_format): /soc/pcie-controller/pcie at 1,0 has empty
>      "ranges" property but its #size-cells (1) differs from
>      /soc/pcie-controller (2)
> 
>  * Use the new RFCv3 patch from Andrew Murray for 'of/pci: Provide
>    support for parsing PCI DT ranges property'.
> 
>  * Updated the DT binding documentation accordingly.
> 
> Changes between v5 and v6:
> 
>  * Use pci_create_root_bus() + pci_scan_child_bus() instead of
>    pci_scan_root_bus(). This is needed to be able to add MSI support
>    later on. Moreover Thierry Reding suggested that
>    pci_scan_root_bus() "does a pci_bus_add_devices(), which is called
>    again in pci_common_init() in the ARM code". Thanks Thierry for
>    pointing out this issue.
> 
> Changes between v4 and v5:
> 
>  * Rebased on top of 3.9-rc2 + the new mvebu-mbus driver (v3).
> 
>  * Changed the names of the PCI DT sub-nodes to match the OF
>    specifications: they should be named pcie at DD,FF where DD is the
>    device number and FF the function number. Requested by Mitch
>    Bradley.
> 
>  * Add the device_type = "pci" property at the pcie-controller
>    level. Requested by Mitch Bradley.
> 
>  * Drop patch 'of/pci: Add of_pci_get_bus() function' because it
>    wasn't actually used in the rest of the patch series.
> 
>  * Updated the patch 'of/pci: Provide support for parsing PCI DT
>    ranges property' to use the latest version proposed by Andrew
>    Murray on the devicetree-discuss@ mailing list.
> 
> Changes between v3 and v4:
> 
>  * Rebased on top of 3.9-rc1.
> 
>  * Drop patch "ARM: pci: Allow passing per-controller private data"
>    because it was merged in 3.9.
> 
>  * Drop patch "lib: devres: don't enclose pcim_*() functions in
>    CONFIG_HAS_IOPORT", because it was merged in 3.9.
> 
>  * Added CONFIG_PCI_MVEBU=y in mvebu_defconfig, so that the right PCI
>    host controller driver is automatically enabled.
> 
>  * Instead of using the DT 'ranges' property to encode the PCIe
>    register ranges, use a 'reg' property on the main PCIe controller
>    DT node together with a 'reg-names' property. Suggested by Jason
>    Gunthorpe.
> 
>  * Don't select PCI_SW_HOST_BRIDGE and PCI_SW_PCI_PCI_BRIDGE, they
>    don't exist anymore. Reported by Bjorn Helgaas.
> 
>  * Added support for the Armada XP GP board.
> 
>  * Fix the 'ranges' property so that the memory range is an identity
>    map between CPU addresses and bus addresses. Suggested by Arnd
>    Bergmann.
> 
>  * Changed the 'ranges' property to have the I/O region after the
>    memory region.
> 
>  * Use the new mvebu-mbus driver API to create/remove address decoding
>    windows when needed. This remove the need to include
>    <mach/addr-map.h>. Requested by Arnd Bergmann.
> 
>  * Include directly into the driver the few common PCIe functions we
>    were using from arch/arm/plat-orion/pcie.c. This allows to remove
>    the inclusion of <plat/pcie.h>. Requested by Arnd Bergmann.
> 
>  * Directly set up the address decoding windows when the memory
>    base/limit and I/O base/limit are configured in the PCI-to-PCI
>    bridge instead of relying on the memory and I/O accesses being
>    enabled in the PCI_COMMAND register. Suggested by Bjorn Helgaas.
> 
>  * Added some comments on top of the calculations of the I/O
>    base/limit and memory base/limit. Suggested by Arnd Bergmann.
> 
>  * Changed a bit the way the "realio" resource is created, from
>    suggestions given by Arnd Bergmann.
> 
>  * Updated the Device Tree binding documentation. Reported by Jason
>    Gunthorpe.
> 
>  * Instead of using "marvell,armada-370-xp-pcie" as the DT compatible
>    string, use two separate compatible strings:
>    "marvell,armada-370-pcie" and "marvell,armada-xp-pcie". For now,
>    the driver does the same thing for both.
> 
> Changes between v2 and v3:
> 
>  * Use of_irq_map_pci() instead of of_irq_map_raw(), as suggested by
>    Andrew Murray. In order to do this, we moved the interrupt-map and
>    interrupt-map-mask DT properties from the main PCIe controller node
>    to the DT subnodes representing each PCIe interface.
> 
>  * Remove the usage of the emulated host bridge.
> 
>  * Move the emulated PCI-to-PCI bridge code into the Marvell PCI
>    driver itself, in order to allow a tighter integration. Suggested
>    by Bjorn Helgaas and Jason Gunthorpe.
> 
>  * Make the allocation of address decoding windows dynamic: it's when
>    memory accesses or I/O accesses are enabled at the PCI-to-PCI
>    bridge level that we allocate and setup the corresponding address
>    decoding window. Requested by Bjorn Helgaas.
> 
>  * Fixed the implementation of I/O accesses to use I/O addresses that
>    fall within the normal IO_SPACE_LIMIT. This required using the
>    "remap" functionality of address decoding windows, and therefore
>    some changes in the address decoding window allocator. Follows a
>    long discussion about I/O accesses.
> 
>  * Set up a correct bus number in the configuration of the PCIe
>    interfaces so that we don't have to fake bus numbers
>    anymore. Requested by Jason Gunthorpe.
> 
>  * Fix the of_pci_get_devfn() implementation according to Stephen
>    Warren's comment.
> 
>  * Use CFLAGS_ instead of ccflags to add the mach-mvebu and plat-orion
>    include paths when building the pci-mvebu driver. This ensures that
>    the include paths are only added when building this specific
>    driver. Requested by Stephen Warren.
> 
>  * Fix the ->resource_align() to only apply on bus 0 (the one on which
>    the emulated PCI-to-PCI bridges sit), and to request an alignment
>    on the size of the window (and not only 64 KB for I/O windows and 1
>    MB for memory windows).
> 
>  * Clarified the commit log of "clk: mvebu: create parent-child
>    relation for PCIe clocks on Armada 370"
> 
> Thanks,
> 
> Thomas
> 
> Andrew Murray (1):
>   of/pci: Provide support for parsing PCI DT ranges property
> 
> Thierry Reding (2):
>   of/pci: Add of_pci_get_devfn() function
>   of/pci: Add of_pci_parse_bus_range() function
> 
> Thomas Petazzoni (14):
>   pci: infrastructure to add drivers in drivers/pci/host
>   arm: pci: add a align_resource hook
>   clk: mvebu: create parent-child relation for PCIe clocks on Armada
>     370
>   clk: mvebu: add more PCIe clocks for Armada XP
>   pci: PCIe driver for Marvell Armada 370/XP systems
>   arm: mvebu: PCIe support is now available on mvebu
>   arm: mvebu: add PCIe Device Tree informations for Armada 370
>   arm: mvebu: add PCIe Device Tree informations for Armada XP
>   arm: mvebu: PCIe Device Tree informations for OpenBlocks AX3-4
>   arm: mvebu: PCIe Device Tree informations for Armada XP DB
>   arm: mvebu: PCIe Device Tree informations for Armada 370 Mirabox
>   arm: mvebu: PCIe Device Tree informations for Armada 370 DB
>   arm: mvebu: PCIe Device Tree informations for Armada XP GP
>   arm: mvebu: update defconfig with PCI and USB support
> 
>  .../devicetree/bindings/pci/mvebu-pci.txt          |  220 +++++
>  arch/arm/boot/dts/armada-370-db.dts                |   17 +
>  arch/arm/boot/dts/armada-370-mirabox.dts           |   16 +
>  arch/arm/boot/dts/armada-370.dtsi                  |   51 ++
>  arch/arm/boot/dts/armada-xp-db.dts                 |   33 +
>  arch/arm/boot/dts/armada-xp-gp.dts                 |   21 +
>  arch/arm/boot/dts/armada-xp-mv78230.dtsi           |  104 +++
>  arch/arm/boot/dts/armada-xp-mv78260.dtsi           |  122 +++
>  arch/arm/boot/dts/armada-xp-mv78460.dtsi           |  188 ++++
>  arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts   |    9 +
>  arch/arm/configs/mvebu_defconfig                   |    3 +
>  arch/arm/include/asm/mach/pci.h                    |   11 +
>  arch/arm/kernel/bios32.c                           |    6 +
>  arch/arm/mach-mvebu/Kconfig                        |    2 +
>  arch/microblaze/pci/pci-common.c                   |  110 +--
>  arch/mips/pci/pci.c                                |   50 +-
>  arch/powerpc/kernel/pci-common.c                   |   99 +--
>  drivers/clk/mvebu/clk-gating-ctrl.c                |   18 +-
>  drivers/of/address.c                               |   63 ++
>  drivers/of/of_pci.c                                |   59 +-
>  drivers/pci/Kconfig                                |    2 +
>  drivers/pci/Makefile                               |    3 +
>  drivers/pci/host/Kconfig                           |    8 +
>  drivers/pci/host/Makefile                          |    4 +
>  drivers/pci/host/pci-mvebu.c                       |  927 ++++++++++++++++++++
>  include/linux/of_address.h                         |   42 +
>  include/linux/of_pci.h                             |    2 +
>  27 files changed, 2009 insertions(+), 181 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/pci/mvebu-pci.txt
>  create mode 100644 drivers/pci/host/Kconfig
>  create mode 100644 drivers/pci/host/Makefile
>  create mode 100644 drivers/pci/host/pci-mvebu.c
> 



-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From peter.ujfalusi at ti.com  Wed Apr  3 08:27:28 2013
From: peter.ujfalusi at ti.com (Peter Ujfalusi)
Date: Wed, 3 Apr 2013 14:27:28 +0200
Subject: [PATCH v3] ARM: omap2: twl-common: Add default power configuration
In-Reply-To: <1364990351-6778-1-git-send-email-peter.ujfalusi@ti.com>
References: <1364990351-6778-1-git-send-email-peter.ujfalusi@ti.com>
Message-ID: <515C2030.7090809@ti.com>

Whata...

On 04/03/2013 01:59 PM, Peter Ujfalusi wrote:
> From: Matthias Brugger <matthias.bgg at gmail.com>
> 
> This patch adds a generic power script configuration.
> When rebooting an OMAP3530 at 125 MHz, the reboot hangs.
> With the generic power script, TWL4030 will be reset
> when a warm reset occures. This way the OMAP3530 does not
> hang on reboot.
> 
> Signed-off-by: Matthias Brugger <matthias.bgg at gmail.com>
> Signed-off-by: Peter Ujfalusi <peter.ujfalusi at ti.com>
> ---
> Tony, Matthias,
> 
> Changes since v2:
> - remove the __initdata from all the structures introduced by this patch
> 
> Regards,
> Peter
> 
>  arch/arm/mach-omap2/twl-common.c | 38 ++++++++++++++++++++++++++++++++++++++
>  arch/arm/mach-omap2/twl-common.h |  1 +
>  2 files changed, 39 insertions(+)
> 
> diff --git a/arch/arm/mach-omap2/twl-common.c b/arch/arm/mach-omap2/twl-common.c
> index 51e138c..7551bbc 100644
> --- a/arch/arm/mach-omap2/twl-common.c
> +++ b/arch/arm/mach-omap2/twl-common.c
> @@ -121,6 +121,41 @@ static struct twl4030_audio_data omap3_audio_pdata = {
>  	.codec = &omap3_codec,
>  };
>  
> +static struct twl4030_ins wrst_seq[] __initdata = {

The __initdata remained :o

Will resend it.

> +	{MSG_SINGULAR(DEV_GRP_NULL, 0x1b, RES_STATE_OFF), 2},
> +	{MSG_SINGULAR(DEV_GRP_P1, 0xf, RES_STATE_WRST), 15},
> +	{MSG_SINGULAR(DEV_GRP_P1, 0x10, RES_STATE_WRST), 15},
> +	{MSG_SINGULAR(DEV_GRP_P1, 0x7, RES_STATE_WRST), 0x60},
> +	{MSG_SINGULAR(DEV_GRP_P1, 0x19, RES_STATE_ACTIVE), 2},
> +	{MSG_SINGULAR(DEV_GRP_NULL, 0x1b, RES_STATE_ACTIVE), 2},
> +};
> +
> +static struct twl4030_script wrst_script __initdata = {
> +	.script = wrst_seq,
> +	.size	= ARRAY_SIZE(wrst_seq),
> +	.flags	= TWL4030_WRST_SCRIPT,
> +};
> +
> +static struct twl4030_script *omap3_power_scripts[] __initdata = {
> +	&wrst_script,
> +};
> +
> +static struct twl4030_resconfig omap3_rconfig[] __initdata = {
> +	{ .resource = RES_HFCLKOUT, .devgroup = DEV_GRP_P3, .type = -1,
> +		.type2 = -1 },
> +	{ .resource = RES_VDD1, .devgroup = DEV_GRP_P1, .type = -1,
> +		.type2 = -1 },
> +	{ .resource = RES_VDD2, .devgroup = DEV_GRP_P1, .type = -1,
> +		.type2 = -1 },
> +	{ 0, 0},
> +};
> +
> +static struct twl4030_power_data omap3_power_pdata __initdata = {
> +	.scripts	= omap3_power_scripts,
> +	.num		= ARRAY_SIZE(omap3_power_scripts),
> +	.resource_config = omap3_rconfig,
> +};
> +
>  static struct regulator_consumer_supply omap3_vdda_dac_supplies[] = {
>  	REGULATOR_SUPPLY("vdda_dac", "omapdss_venc"),
>  };
> @@ -225,6 +260,9 @@ void __init omap3_pmic_get_config(struct twl4030_platform_data *pmic_data,
>  	if (pdata_flags & TWL_COMMON_PDATA_AUDIO && !pmic_data->audio)
>  		pmic_data->audio = &omap3_audio_pdata;
>  
> +	if (pdata_flags & TWL_COMMON_PDATA_POWER && !pmic_data->power)
> +		pmic_data->power = &omap3_power_pdata;
> +
>  	/* Common regulator configurations */
>  	if (regulators_flags & TWL_COMMON_REGULATOR_VDAC && !pmic_data->vdac)
>  		pmic_data->vdac = &omap3_vdac_idata;
> diff --git a/arch/arm/mach-omap2/twl-common.h b/arch/arm/mach-omap2/twl-common.h
> index 24b65d0..b64590b8 100644
> --- a/arch/arm/mach-omap2/twl-common.h
> +++ b/arch/arm/mach-omap2/twl-common.h
> @@ -7,6 +7,7 @@
>  #define TWL_COMMON_PDATA_BCI		(1 << 1)
>  #define TWL_COMMON_PDATA_MADC		(1 << 2)
>  #define TWL_COMMON_PDATA_AUDIO		(1 << 3)
> +#define TWL_COMMON_PDATA_POWER		(1 << 4)
>  
>  /* Common LDO regulators for TWL4030/TWL6030 */
>  #define TWL_COMMON_REGULATOR_VDAC	(1 << 0)
> 


-- 
P?ter


From pawel.moll at arm.com  Wed Apr  3 08:26:27 2013
From: pawel.moll at arm.com (Pawel Moll)
Date: Wed,  3 Apr 2013 13:26:27 +0100
Subject: [PATCH] mfd: vexpress: Give the "leds-gpio" device a real parent
Message-ID: <1364991987-6598-1-git-send-email-pawel.moll@arm.com>

The registration of the "leds-gpio" device was using
"vexpress_sysreg_dev" as a parent before it was actually
set to something different than NULL.

Trivial fix by reordering the code.

Reported-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
Signed-off-by: Pawel Moll <pawel.moll at arm.com>
---
 drivers/mfd/vexpress-sysreg.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/mfd/vexpress-sysreg.c b/drivers/mfd/vexpress-sysreg.c
index bf75e96..96a020b 100644
--- a/drivers/mfd/vexpress-sysreg.c
+++ b/drivers/mfd/vexpress-sysreg.c
@@ -490,12 +490,12 @@ static int vexpress_sysreg_probe(struct platform_device *pdev)
 		return err;
 	}
 
+	vexpress_sysreg_dev = &pdev->dev;
+
 	platform_device_register_data(vexpress_sysreg_dev, "leds-gpio",
 			PLATFORM_DEVID_AUTO, &vexpress_sysreg_leds_pdata,
 			sizeof(vexpress_sysreg_leds_pdata));
 
-	vexpress_sysreg_dev = &pdev->dev;
-
 	device_create_file(vexpress_sysreg_dev, &dev_attr_sys_id);
 
 	return 0;
-- 
1.7.10.4




From fabio.estevam at freescale.com  Wed Apr  3 08:29:16 2013
From: fabio.estevam at freescale.com (Fabio Estevam)
Date: Wed, 3 Apr 2013 09:29:16 -0300
Subject: [PATCH v2] ARM: dts: Add initial support for Wandboard Dual-Lite
Message-ID: <1364992156-22852-1-git-send-email-fabio.estevam@freescale.com>

Wandboard is a development board that has two variants: one version based
on mx6 dual lite and another one based on mx6 solo.

For more details about Wandboard, please refer to: http://www.wandboard.org/

Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
---
Changes since v1:
- Use im6xdl instead of imx6q
- Use pinctrl_usdhc3_2 for label

 arch/arm/boot/dts/Makefile              |    1 +
 arch/arm/boot/dts/imx6dl-wandboard.dtsp |   40 +++++++++++++++++++++++++++++++
 arch/arm/boot/dts/imx6dl.dtsip          |   11 +++++++++
 3 files changed, 52 insertions(+)
 create mode 100644 arch/arm/boot/dts/imx6dl-wandboard.dtsp

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 5345ac1..a566619 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -100,6 +100,7 @@ dtb-$(CONFIG_ARCH_MXC) += \
 	imx53-smd.dtb \
 	imx6dl-sabreauto.dtb \
 	imx6dl-sabresd.dtb \
+	imx6dl-wandboard.dtb \
 	imx6q-arm2.dtb \
 	imx6q-sabreauto.dtb \
 	imx6q-sabrelite.dtb \
diff --git a/arch/arm/boot/dts/imx6dl-wandboard.dtsp b/arch/arm/boot/dts/imx6dl-wandboard.dtsp
new file mode 100644
index 0000000..e95d2b0
--- /dev/null
+++ b/arch/arm/boot/dts/imx6dl-wandboard.dtsp
@@ -0,0 +1,40 @@
+/*
+ * Copyright 2013 Freescale Semiconductor, Inc.
+ *
+ * Author: Fabio Estevam <fabio.estevam at freescale.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.
+ *
+ */
+/dts-v1/;
+#include "imx6dl.dtsip"
+
+/ {
+	model = "Wandboard i.MX6 Dual Lite Board";
+	compatible = "wand,imx6dl-wandboard", "fsl,imx6dl";
+
+	memory {
+		reg = <0x10000000 0x40000000>;
+	};
+};
+
+&fec {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_enet_1>;
+	phy-mode = "rgmii";
+	status = "okay";
+};
+
+&uart1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_uart1_1>;
+	status = "okay";
+};
+
+&usdhc3 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_usdhc3_2>;
+	status = "okay";
+};
diff --git a/arch/arm/boot/dts/imx6dl.dtsip b/arch/arm/boot/dts/imx6dl.dtsip
index 951ba53..2e6cff0 100644
--- a/arch/arm/boot/dts/imx6dl.dtsip
+++ b/arch/arm/boot/dts/imx6dl.dtsip
@@ -136,6 +136,17 @@
 							MX6DL_PAD_SD3_DAT7__SD3_DATA7 0x17059
 						>;
 					};
+
+					pinctrl_usdhc3_2: usdhc3grp_2 {
+						fsl,pins = <
+							MX6DL_PAD_SD3_CMD__SD3_CMD    0x17059
+							MX6DL_PAD_SD3_CLK__SD3_CLK    0x10059
+							MX6DL_PAD_SD3_DAT0__SD3_DATA0 0x17059
+							MX6DL_PAD_SD3_DAT1__SD3_DATA1 0x17059
+							MX6DL_PAD_SD3_DAT2__SD3_DATA2 0x17059
+							MX6DL_PAD_SD3_DAT3__SD3_DATA3 0x17059
+						>;
+					};
 				};
 
 
-- 
1.7.9.5




From peter.ujfalusi at ti.com  Wed Apr  3 08:31:27 2013
From: peter.ujfalusi at ti.com (Peter Ujfalusi)
Date: Wed, 3 Apr 2013 14:31:27 +0200
Subject: [PATCH v4] ARM: omap2: twl-common: Add default power configuration
Message-ID: <1364992287-6992-1-git-send-email-peter.ujfalusi@ti.com>

From: Matthias Brugger <matthias.bgg at gmail.com>

This patch adds a generic power script configuration.
When rebooting an OMAP3530 at 125 MHz, the reboot hangs.
With the generic power script, TWL4030 will be reset
when a warm reset occures. This way the OMAP3530 does not
hang on reboot.

Signed-off-by: Matthias Brugger <matthias.bgg at gmail.com>
Signed-off-by: Peter Ujfalusi <peter.ujfalusi at ti.com>
---
Tony, Matthias,

Changes since v3:
- remove the __initdata from all the structures introduced by this patch

If it is OK, I'll send a pull with this patch.

Regards,
Peter

 arch/arm/mach-omap2/twl-common.c | 38 ++++++++++++++++++++++++++++++++++++++
 arch/arm/mach-omap2/twl-common.h |  1 +
 2 files changed, 39 insertions(+)

diff --git a/arch/arm/mach-omap2/twl-common.c b/arch/arm/mach-omap2/twl-common.c
index 51e138c..a85531e 100644
--- a/arch/arm/mach-omap2/twl-common.c
+++ b/arch/arm/mach-omap2/twl-common.c
@@ -121,6 +121,41 @@ static struct twl4030_audio_data omap3_audio_pdata = {
 	.codec = &omap3_codec,
 };
 
+static struct twl4030_ins wrst_seq[] = {
+	{MSG_SINGULAR(DEV_GRP_NULL, 0x1b, RES_STATE_OFF), 2},
+	{MSG_SINGULAR(DEV_GRP_P1, 0xf, RES_STATE_WRST), 15},
+	{MSG_SINGULAR(DEV_GRP_P1, 0x10, RES_STATE_WRST), 15},
+	{MSG_SINGULAR(DEV_GRP_P1, 0x7, RES_STATE_WRST), 0x60},
+	{MSG_SINGULAR(DEV_GRP_P1, 0x19, RES_STATE_ACTIVE), 2},
+	{MSG_SINGULAR(DEV_GRP_NULL, 0x1b, RES_STATE_ACTIVE), 2},
+};
+
+static struct twl4030_script wrst_script = {
+	.script = wrst_seq,
+	.size	= ARRAY_SIZE(wrst_seq),
+	.flags	= TWL4030_WRST_SCRIPT,
+};
+
+static struct twl4030_script *omap3_power_scripts[] = {
+	&wrst_script,
+};
+
+static struct twl4030_resconfig omap3_rconfig[] = {
+	{ .resource = RES_HFCLKOUT, .devgroup = DEV_GRP_P3, .type = -1,
+		.type2 = -1 },
+	{ .resource = RES_VDD1, .devgroup = DEV_GRP_P1, .type = -1,
+		.type2 = -1 },
+	{ .resource = RES_VDD2, .devgroup = DEV_GRP_P1, .type = -1,
+		.type2 = -1 },
+	{ 0, 0},
+};
+
+static struct twl4030_power_data omap3_power_pdata = {
+	.scripts	= omap3_power_scripts,
+	.num		= ARRAY_SIZE(omap3_power_scripts),
+	.resource_config = omap3_rconfig,
+};
+
 static struct regulator_consumer_supply omap3_vdda_dac_supplies[] = {
 	REGULATOR_SUPPLY("vdda_dac", "omapdss_venc"),
 };
@@ -225,6 +260,9 @@ void __init omap3_pmic_get_config(struct twl4030_platform_data *pmic_data,
 	if (pdata_flags & TWL_COMMON_PDATA_AUDIO && !pmic_data->audio)
 		pmic_data->audio = &omap3_audio_pdata;
 
+	if (pdata_flags & TWL_COMMON_PDATA_POWER && !pmic_data->power)
+		pmic_data->power = &omap3_power_pdata;
+
 	/* Common regulator configurations */
 	if (regulators_flags & TWL_COMMON_REGULATOR_VDAC && !pmic_data->vdac)
 		pmic_data->vdac = &omap3_vdac_idata;
diff --git a/arch/arm/mach-omap2/twl-common.h b/arch/arm/mach-omap2/twl-common.h
index 24b65d0..b64590b8 100644
--- a/arch/arm/mach-omap2/twl-common.h
+++ b/arch/arm/mach-omap2/twl-common.h
@@ -7,6 +7,7 @@
 #define TWL_COMMON_PDATA_BCI		(1 << 1)
 #define TWL_COMMON_PDATA_MADC		(1 << 2)
 #define TWL_COMMON_PDATA_AUDIO		(1 << 3)
+#define TWL_COMMON_PDATA_POWER		(1 << 4)
 
 /* Common LDO regulators for TWL4030/TWL6030 */
 #define TWL_COMMON_REGULATOR_VDAC	(1 << 0)
-- 
1.8.1.5



From linus.walleij at linaro.org  Wed Apr  3 08:35:27 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Wed, 3 Apr 2013 14:35:27 +0200
Subject: [PATCH 2/2] ARM: remove mach .init_irq for irqchip_init users
In-Reply-To: <1364503606-10597-3-git-send-email-maxime.ripard@free-electrons.com>
References: <1364503606-10597-1-git-send-email-maxime.ripard@free-electrons.com>
 <1364503606-10597-3-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <CACRpkdapQB7=fem1x8v5nAzitAVMZAe=P4Eroz-wmmK1CQSMgg@mail.gmail.com>

On Thu, Mar 28, 2013 at 9:46 PM, Maxime Ripard
<maxime.ripard at free-electrons.com> wrote:

> Now that the arm core code calls irqchip_init, we can remove it from all
> the machines that were using it.
>
> Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
> Acked-by: Simon Horman <horms+renesas at verge.net.au>

Acked-by: Linus Walleij <linus.walleij at linaro.org>

For Nomadik.

Yours,
Linus Walleij


From kishon at ti.com  Wed Apr  3 08:53:50 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Wed, 3 Apr 2013 18:23:50 +0530
Subject: [PATCH v5 2/6] usb: phy: omap-usb2: use the new generic PHY framework
In-Reply-To: <1364993634-6378-1-git-send-email-kishon@ti.com>
References: <1364993634-6378-1-git-send-email-kishon@ti.com>
Message-ID: <1364993634-6378-3-git-send-email-kishon@ti.com>

Used the generic PHY framework API to create the PHY. omap_usb2_suspend
is split into omap_usb_suspend and omap_usb_resume in order to align
with the new framework.

However using the old USB PHY library cannot be completely removed
because OTG is intertwined with PHY and moving to the new framework
will break OTG. Once we have a separate OTG state machine, we
can get rid of the USB PHY library.

Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
---
 drivers/usb/phy/omap-usb2.c |   48 +++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 48 insertions(+)

diff --git a/drivers/usb/phy/omap-usb2.c b/drivers/usb/phy/omap-usb2.c
index 844ab68..4e48db4 100644
--- a/drivers/usb/phy/omap-usb2.c
+++ b/drivers/usb/phy/omap-usb2.c
@@ -28,6 +28,7 @@
 #include <linux/pm_runtime.h>
 #include <linux/delay.h>
 #include <linux/usb/omap_control_usb.h>
+#include <linux/phy/phy.h>
 
 /**
  * omap_usb2_set_comparator - links the comparator present in the sytem with
@@ -119,9 +120,49 @@ static int omap_usb2_suspend(struct usb_phy *x, int suspend)
 	return 0;
 }
 
+static int omap_usb_suspend(struct phy *x)
+{
+	struct omap_usb *phy = dev_get_drvdata(&x->dev);
+
+	if (!phy->is_suspended) {
+		omap_control_usb_phy_power(phy->control_dev, 0);
+		pm_runtime_put_sync(phy->dev);
+		phy->is_suspended = 1;
+	}
+
+	return 0;
+}
+
+static int omap_usb_resume(struct phy *x)
+{
+	u32 ret;
+	struct omap_usb *phy = dev_get_drvdata(&x->dev);
+
+	if (phy->is_suspended) {
+		ret = pm_runtime_get_sync(phy->dev);
+		if (ret < 0) {
+			dev_err(phy->dev, "get_sync failed with err %d\n",
+									ret);
+			return ret;
+		}
+		omap_control_usb_phy_power(phy->control_dev, 1);
+		phy->is_suspended = 0;
+	}
+
+	return 0;
+}
+
+static struct phy_ops ops = {
+	.suspend	= omap_usb_suspend,
+	.resume		= omap_usb_resume,
+	.of_xlate	= of_phy_xlate,
+	.owner		= THIS_MODULE,
+};
+
 static int omap_usb2_probe(struct platform_device *pdev)
 {
 	struct omap_usb			*phy;
+	struct phy			*generic_phy;
 	struct usb_otg			*otg;
 
 	phy = devm_kzalloc(&pdev->dev, sizeof(*phy), GFP_KERNEL);
@@ -144,6 +185,13 @@ static int omap_usb2_probe(struct platform_device *pdev)
 	phy->phy.otg		= otg;
 	phy->phy.type		= USB_PHY_TYPE_USB2;
 
+	generic_phy = devm_phy_create(phy->dev, "omap-usb2", pdev->dev.of_node,
+		USB_PHY_TYPE_USB2, &ops, phy);
+	if (IS_ERR(generic_phy)) {
+		dev_dbg(&pdev->dev, "Failed to create PHY\n");
+		return PTR_ERR(generic_phy);
+	}
+
 	phy->control_dev = omap_get_control_dev();
 	if (IS_ERR(phy->control_dev)) {
 		dev_dbg(&pdev->dev, "Failed to get control device\n");
-- 
1.7.10.4



From kishon at ti.com  Wed Apr  3 08:53:53 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Wed, 3 Apr 2013 18:23:53 +0530
Subject: [PATCH v5 5/6] ARM: dts: omap: update usb_otg_hs data
In-Reply-To: <1364993634-6378-1-git-send-email-kishon@ti.com>
References: <1364993634-6378-1-git-send-email-kishon@ti.com>
Message-ID: <1364993634-6378-6-git-send-email-kishon@ti.com>

Updated the usb_otg_hs dt data to include the *phy* and *phy-names*
binding in order for the driver to use the new generic PHY framework.
Also updated the Documentation to include the binding information.
The PHY binding information can be found at
Documentation/devicetree/bindings/phy/phy-bindings.txt

Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
---
 Documentation/devicetree/bindings/usb/omap-usb.txt |    5 +++++
 Documentation/devicetree/bindings/usb/usb-phy.txt  |    6 ++++++
 arch/arm/boot/dts/omap3.dtsi                       |    2 ++
 arch/arm/boot/dts/omap4.dtsi                       |    3 +++
 arch/arm/boot/dts/twl4030.dtsi                     |    1 +
 5 files changed, 17 insertions(+)

diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt b/Documentation/devicetree/bindings/usb/omap-usb.txt
index abce256..9324e79 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -19,6 +19,9 @@ OMAP MUSB GLUE
  - power : Should be "50". This signifies the controller can supply upto
    100mA when operating in host mode.
  - usb-phy : the phandle for the PHY device
+ - phys : the phandle for the PHY device (used by generic PHY framework)
+ - phy-names : the names of the PHY corresponding to the PHYs present in the
+   *phy* phandle.
 
 Optional properties:
  - ctrl-module : phandle of the control module this glue uses to write to
@@ -33,6 +36,8 @@ usb_otg_hs: usb_otg_hs at 4a0ab000 {
 	num_eps = <16>;
 	ram_bits = <12>;
 	ctrl-module = <&omap_control_usb>;
+	phys = <&usb2_phy>;
+	phy-names = "usb2-phy";
 };
 
 Board specific device node entry
diff --git a/Documentation/devicetree/bindings/usb/usb-phy.txt b/Documentation/devicetree/bindings/usb/usb-phy.txt
index 61496f5..c0245c8 100644
--- a/Documentation/devicetree/bindings/usb/usb-phy.txt
+++ b/Documentation/devicetree/bindings/usb/usb-phy.txt
@@ -5,6 +5,8 @@ OMAP USB2 PHY
 Required properties:
  - compatible: Should be "ti,omap-usb2"
  - reg : Address and length of the register set for the device.
+ - #phy-cells: determine the number of cells that should be given in the
+   phandle while referencing this phy.
 
 Optional properties:
  - ctrl-module : phandle of the control module used by PHY driver to power on
@@ -16,6 +18,7 @@ usb2phy at 4a0ad080 {
 	compatible = "ti,omap-usb2";
 	reg = <0x4a0ad080 0x58>;
 	ctrl-module = <&omap_control_usb>;
+	#phy-cells = <0>;
 };
 
 OMAP USB3 PHY
@@ -25,6 +28,8 @@ Required properties:
  - reg : Address and length of the register set for the device.
  - reg-names: The names of the register addresses corresponding to the registers
    filled in "reg".
+ - #phy-cells: determine the number of cells that should be given in the
+   phandle while referencing this phy.
 
 Optional properties:
  - ctrl-module : phandle of the control module used by PHY driver to power on
@@ -39,4 +44,5 @@ usb3phy at 4a084400 {
 	      <0x4a084c00 0x40>;
 	reg-names = "phy_rx", "phy_tx", "pll_ctrl";
 	ctrl-module = <&omap_control_usb>;
+	#phy-cells = <0>;
 };
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 1e21565..dd7d2ff 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -405,6 +405,8 @@
 			interrupt-names = "mc", "dma";
 			ti,hwmods = "usb_otg_hs";
 			usb-phy = <&usb2_phy>;
+			phys = <&usb2_phy>;
+			phy-names = "usb2-phy";
 			multipoint = <1>;
 			num-eps = <16>;
 			ram-bits = <12>;
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 06d044e..64cd000 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -442,6 +442,7 @@
 				compatible = "ti,omap-usb2";
 				reg = <0x4a0ad080 0x58>;
 				ctrl-module = <&omap_control_usb>;
+				#phy-cells = <0>;
 			};
 		};
 
@@ -550,6 +551,8 @@
 			interrupt-names = "mc", "dma";
 			ti,hwmods = "usb_otg_hs";
 			usb-phy = <&usb2_phy>;
+			phys = <&usb2_phy>;
+			phy-names = "usb2-phy";
 			multipoint = <1>;
 			num-eps = <16>;
 			ram-bits = <12>;
diff --git a/arch/arm/boot/dts/twl4030.dtsi b/arch/arm/boot/dts/twl4030.dtsi
index 398d2c3..6f71de7 100644
--- a/arch/arm/boot/dts/twl4030.dtsi
+++ b/arch/arm/boot/dts/twl4030.dtsi
@@ -74,5 +74,6 @@
 		usb1v8-supply = <&vusb1v8>;
 		usb3v1-supply = <&vusb3v1>;
 		usb_mode = <1>;
+		#phy-cells = <0>;
 	};
 };
-- 
1.7.10.4



From kishon at ti.com  Wed Apr  3 08:53:49 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Wed, 3 Apr 2013 18:23:49 +0530
Subject: [PATCH v5 1/6] drivers: phy: add generic PHY framework
In-Reply-To: <1364993634-6378-1-git-send-email-kishon@ti.com>
References: <1364993634-6378-1-git-send-email-kishon@ti.com>
Message-ID: <1364993634-6378-2-git-send-email-kishon@ti.com>

The PHY framework provides a set of APIs for the PHY drivers to
create/destroy a PHY and APIs for the PHY users to obtain a reference to the
PHY with or without using phandle. To obtain a reference to the PHY without
using phandle, the platform specfic intialization code (say from board file)
should have already called phy_bind with the binding information. The binding
information consists of phy's device name, phy user device name and an index.
The index is used when the same phy user binds to mulitple phys.

PHY drivers should create the PHY by passing phy_descriptor that has
describes the PHY (label, type etc..) and ops like init, exit, suspend, resume,
power_on, power_off.

The documentation for the generic PHY framework is added in
Documentation/phy.txt and the documentation for the sysfs entry is added
in Documentation/ABI/testing/sysfs-class-phy and the documentation for
dt binding is can be found at
Documentation/devicetree/bindings/phy/phy-bindings.txt

Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
---
 Documentation/ABI/testing/sysfs-class-phy          |   15 +
 .../devicetree/bindings/phy/phy-bindings.txt       |   67 +++
 Documentation/phy.txt                              |  113 ++++
 MAINTAINERS                                        |    7 +
 drivers/Kconfig                                    |    2 +
 drivers/Makefile                                   |    2 +
 drivers/phy/Kconfig                                |   13 +
 drivers/phy/Makefile                               |    5 +
 drivers/phy/phy-core.c                             |  616 ++++++++++++++++++++
 include/linux/phy/phy.h                            |  228 ++++++++
 10 files changed, 1068 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-class-phy
 create mode 100644 Documentation/devicetree/bindings/phy/phy-bindings.txt
 create mode 100644 Documentation/phy.txt
 create mode 100644 drivers/phy/Kconfig
 create mode 100644 drivers/phy/Makefile
 create mode 100644 drivers/phy/phy-core.c
 create mode 100644 include/linux/phy/phy.h

diff --git a/Documentation/ABI/testing/sysfs-class-phy b/Documentation/ABI/testing/sysfs-class-phy
new file mode 100644
index 0000000..b735467
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-phy
@@ -0,0 +1,15 @@
+What:		/sys/class/phy/<phy>/label
+Date:		Apr 2013
+KernelVersion:	3.10
+Contact:	Kishon Vijay Abraham I <kishon at ti.com>
+Description:
+		This is a read-only file for getting the label of the phy.
+
+What:		/sys/class/phy/<phy>/phy_bind
+Date:		Apr 2013
+KernelVersion:	3.10
+Contact:	Kishon Vijay Abraham I <kishon at ti.com>
+Description:
+		This is a read-only file for reading the phy binding
+		information. It contains the device name of the controller,
+		the index and the device name of the PHY in that order.
diff --git a/Documentation/devicetree/bindings/phy/phy-bindings.txt b/Documentation/devicetree/bindings/phy/phy-bindings.txt
new file mode 100644
index 0000000..e7b246a
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-bindings.txt
@@ -0,0 +1,67 @@
+This document explains only the dt data binding. For general information about
+PHY subsystem refer Documentation/phy.txt
+
+PHY device node
+===============
+
+Required Properties:
+#phy-cells:	Number of cells in a PHY specifier;  The meaning of all those
+		cells is defined by the binding for the phy node. The PHY
+		provider can use the values in cells to find the appropriate
+		PHY.
+
+For example:
+
+phys: phy {
+    compatible = "xxx";
+    reg = <...>;
+    .
+    .
+    #phy-cells = <1>;
+    .
+    .
+};
+
+That node describes an IP block that implements 2 different PHYs. In order to
+differentiate between these 2 PHYs, an additonal specifier should be given
+while trying to get a reference to it.
+
+PHY user node
+=============
+
+Required Properties:
+phys : the phandle for the PHY device (used by the PHY subsystem)
+
+Optional properties:
+phy-names : the names of the PHY corresponding to the PHYs present in the
+	    *phys* phandle
+
+Example 1:
+usb1: usb_otg_ss at xxx {
+    compatible = "xxx";
+    reg = <xxx>;
+    .
+    .
+    phys = <&usb2_phy>, <&usb3_phy>;
+    phy-names = "usb2phy", "usb3phy";
+    .
+    .
+};
+
+This node represents a controller that uses two PHYs one for usb2 and one for
+usb3.
+
+Example 2:
+usb2: usb_otg_ss at xxx {
+    compatible = "xxx";
+    reg = <xxx>;
+    .
+    .
+    phys = <&phys 1>;
+    .
+    .
+};
+
+This node represents a controller that uses one of the PHYs which is defined
+previously. Note that the phy handle has an additional specifier "1" to
+differentiate between the two PHYs.
diff --git a/Documentation/phy.txt b/Documentation/phy.txt
new file mode 100644
index 0000000..7785ec0
--- /dev/null
+++ b/Documentation/phy.txt
@@ -0,0 +1,113 @@
+			    PHY SUBSYSTEM
+		  Kishon Vijay Abraham I <kishon at ti.com>
+
+This document explains the Generic PHY Framework along with the APIs provided,
+and how-to-use.
+
+1. Introduction
+
+*PHY* is the abbreviation for physical layer. It is used to connect a device
+to the physical medium e.g., the USB controller has a PHY to provide functions
+such as serialization, de-serialization, encoding, decoding and is responsible
+for obtaining the required data transmission rate. Note that some USB
+controller has PHY functionality embedded into it and others use an external
+PHY. Other peripherals that uses a PHY include Wireless LAN, Ethernet,
+SATA etc.
+
+The intention of creating this framework is to bring the phy drivers spread
+all over the Linux kernel to drivers/phy to increase code re-use and to
+increase code maintainability.
+
+This framework will be of use only to devices that uses external PHY (PHY
+functionality is not embedded within the controller).
+
+2. Creating the PHY
+
+The PHY driver should create the PHY in order for other peripheral controllers
+to make use of it. The PHY framework provides 2 APIs to create the PHY.
+
+struct phy *phy_create(struct device *dev, const char *label,
+	struct device_node *of_node, int type, struct phy_ops *ops,
+	void *priv);
+struct phy *devm_phy_create(struct device *dev, const char *label,
+	struct device_node *of_node, int type, struct phy_ops *ops,
+	void *priv);
+
+The PHY drivers can use one of the above 2 APIs to create the PHY by passing
+the device pointer, label, device node, type, phy ops and a driver data.
+phy_ops is a set of function pointers for performing PHY operations such as
+init, exit, suspend, resume, power_on and power_off.
+
+3. Binding the PHY to the controller
+
+The framework provides an API for binding the controller to the PHY in the
+case of non dt boot.
+
+struct phy_bind *phy_bind(const char *dev_name, int index,
+				const char *phy_dev_name);
+
+The API fills the phy_bind structure with the dev_name (device name of the
+controller), index and phy_dev_name (device name of the PHY). This will
+be used when the controller requests this phy. This API should be used by
+platform specific initialization code (board file).
+
+In the case of dt boot, the binding information should be added in the dt
+data of the controller.
+
+4. Getting a reference to the PHY
+
+Before the controller can make use of the PHY, it has to get a reference to
+it. This framework provides 6 APIs to get a reference to the PHY.
+
+struct phy *phy_get(struct device *dev, int index);
+struct phy *devm_phy_get(struct device *dev, int index);
+struct phy *of_phy_get(struct device *dev, const char *phandle, int index);
+struct phy *devm_of_phy_get(struct device *dev, const char *phandle, int index);
+struct phy *of_phy_get_byname(struct device *dev, const char *string);
+struct phy *devm_of_phy_get_byname(struct device *dev, const char *string);
+
+phy_get and devm_phy_get can be used to get the PHY in non-dt boot. This API
+uses the binding information added using the phy_bind API to find and return
+the appropriate PHY. The only difference between the two APIs is that
+devm_phy_get associates the device with the PHY using devres on successful PHY
+get. On driver detach, release function is invoked on the the devres data and
+devres data is freed.
+
+of_phy_get and devm_of_phy_get can be used to get the PHY in dt boot. These
+APIs take the phandle and index to get a reference to the PHY. The only
+difference between the two APIs is that devm_of_phy_get associates the device
+with the PHY using devres on successful phy get. On driver detach, release
+function is invoked on the devres data and it is freed.
+
+of_phy_get_byname and devm_of_phy_get_byname can also be used to get the PHY
+in dt boot. It is same as the above API except that the user has to pass the
+phy name as filled in "phy-names" phandle in dt data and the framework will
+find the index and get the PHY.
+
+5. Releasing a reference to the PHY
+
+When the controller no longer needs the PHY, it has to release the reference
+to the PHY it has obtained using the APIs mentioned in the above section. The
+PHY framework provides 2 APIS to release a reference to the PHY.
+
+void phy_put(struct phy *phy);
+void devm_phy_put(struct device *dev, struct phy *phy);
+
+Both these APIs are used to release a reference to the PHY and devm_phy_put
+destroys the devres associated with this PHY.
+
+6. Destroying the PHY
+
+When the driver that created the PHY is unloaded, it should destroy the PHY it
+created using one of the following 2 APIs.
+
+void phy_destroy(struct phy *phy);
+void devm_phy_destroy(struct device *dev, struct phy *phy);
+
+Both these APIs destroys the PHY and devm_phy_destroy destroys the devres
+associated with this PHY.
+
+7. DeviceTree Binding
+
+The documentation for PHY dt binding can be found @
+Documentation/devicetree/bindings/phy/phy-bindings.txt
diff --git a/MAINTAINERS b/MAINTAINERS
index 72b0843..f2674e7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3474,6 +3474,13 @@ S:	Maintained
 F:	include/asm-generic
 F:	include/uapi/asm-generic
 
+GENERIC PHY FRAMEWORK
+M:	Kishon Vijay Abraham I <kishon at ti.com>
+L:	linux-kernel at vger.kernel.org
+S:	Supported
+F:	drivers/phy/
+F:	include/linux/phy/
+
 GENERIC UIO DRIVER FOR PCI DEVICES
 M:	"Michael S. Tsirkin" <mst at redhat.com>
 L:	kvm at vger.kernel.org
diff --git a/drivers/Kconfig b/drivers/Kconfig
index 202fa6d..ad2c374a 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -162,4 +162,6 @@ source "drivers/irqchip/Kconfig"
 
 source "drivers/ipack/Kconfig"
 
+source "drivers/phy/Kconfig"
+
 endmenu
diff --git a/drivers/Makefile b/drivers/Makefile
index dce39a9..9da8321 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -45,6 +45,8 @@ obj-y				+= char/
 # gpu/ comes after char for AGP vs DRM startup
 obj-y				+= gpu/
 
+obj-y				+= phy/
+
 obj-$(CONFIG_CONNECTOR)		+= connector/
 
 # i810fb and intelfb depend on char/agp/
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
new file mode 100644
index 0000000..5f85909
--- /dev/null
+++ b/drivers/phy/Kconfig
@@ -0,0 +1,13 @@
+#
+# PHY
+#
+
+menuconfig GENERIC_PHY
+	tristate "PHY Subsystem"
+	help
+	  Generic PHY support.
+
+	  This framework is designed to provide a generic interface for PHY
+	  devices present in the kernel. This layer will have the generic
+	  API by which phy drivers can create PHY using the phy framework and
+	  phy users can obtain reference to the PHY.
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
new file mode 100644
index 0000000..9e9560f
--- /dev/null
+++ b/drivers/phy/Makefile
@@ -0,0 +1,5 @@
+#
+# Makefile for the phy drivers.
+#
+
+obj-$(CONFIG_GENERIC_PHY)	+= phy-core.o
diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
new file mode 100644
index 0000000..1d753f2
--- /dev/null
+++ b/drivers/phy/phy-core.c
@@ -0,0 +1,616 @@
+/*
+ * phy-core.c  --  Generic Phy framework.
+ *
+ * Copyright (C) 2013 Texas Instruments
+ *
+ * Author: Kishon Vijay Abraham I <kishon at ti.com>
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <linux/kernel.h>
+#include <linux/export.h>
+#include <linux/module.h>
+#include <linux/err.h>
+#include <linux/device.h>
+#include <linux/slab.h>
+#include <linux/of.h>
+#include <linux/phy/phy.h>
+
+static struct class *phy_class;
+static DEFINE_MUTEX(phy_bind_mutex);
+static LIST_HEAD(phy_bind_list);
+static int phy_core_init(void);
+
+static void devm_phy_release(struct device *dev, void *res)
+{
+	struct phy *phy = *(struct phy **)res;
+
+	phy_put(phy);
+}
+
+static void devm_phy_consume(struct device *dev, void *res)
+{
+	struct phy *phy = *(struct phy **)res;
+
+	phy_destroy(phy);
+}
+
+static int devm_phy_match(struct device *dev, void *res, void *match_data)
+{
+	return res == match_data;
+}
+
+static struct phy *phy_lookup(struct device *dev, int index)
+{
+	struct phy_bind *phy_bind = NULL;
+
+	list_for_each_entry(phy_bind, &phy_bind_list, list) {
+		if (!(strcmp(phy_bind->dev_name, dev_name(dev)) &&
+				phy_bind->index == index)) {
+			if (phy_bind->phy)
+				return phy_bind->phy;
+			else
+				return ERR_PTR(-EPROBE_DEFER);
+		}
+	}
+
+	return ERR_PTR(-ENODEV);
+}
+
+static struct phy *of_phy_lookup(struct device_node *node)
+{
+	struct phy *phy;
+	struct device *dev;
+	struct class_dev_iter iter;
+
+	class_dev_iter_init(&iter, phy_class, NULL, NULL);
+	while ((dev = class_dev_iter_next(&iter))) {
+		phy = container_of(dev, struct phy, dev);
+		if (node != phy->of_node)
+			continue;
+
+		class_dev_iter_exit(&iter);
+		return phy;
+	}
+
+	class_dev_iter_exit(&iter);
+	return ERR_PTR(-EPROBE_DEFER);
+}
+
+/**
+ * phy_put() - release the PHY
+ * @phy: the phy returned by phy_get()
+ *
+ * Releases a refcount the caller received from phy_get().
+ */
+void phy_put(struct phy *phy)
+{
+	if (!IS_ERR(phy)) {
+		module_put(phy->ops->owner);
+		put_device(&phy->dev);
+	}
+}
+EXPORT_SYMBOL_GPL(phy_put);
+
+/**
+ * devm_phy_put() - release the PHY
+ * @dev: device that wants to release this phy
+ * @phy: the phy returned by devm_phy_get()
+ *
+ * destroys the devres associated with this phy and invokes phy_put
+ * to release the phy.
+ */
+void devm_phy_put(struct device *dev, struct phy *phy)
+{
+	int r;
+
+	r = devres_destroy(dev, devm_phy_release, devm_phy_match, phy);
+	dev_WARN_ONCE(dev, r, "couldn't find PHY resource\n");
+}
+EXPORT_SYMBOL_GPL(devm_phy_put);
+
+/**
+ * of_phy_xlate() - returns the phy instance from phy provider
+ * @phy: the phy returned by of_phy_lookup()
+ * @args: of_phandle_args (not used here)
+ *
+ * Intended to be used by phy provider for the common case where #phy-cells is
+ * 0. For other cases where #phy-cells is greater than '0', the phy provider
+ * should provide a custom of_xlate function that reads the *args* and returns
+ * the appropriate phy.
+ */
+struct phy *of_phy_xlate(struct phy *phy, struct of_phandle_args *args)
+{
+	return phy;
+}
+EXPORT_SYMBOL_GPL(of_phy_xlate);
+
+/**
+ * of_phy_get() - lookup and obtain a reference to a phy by phandle
+ * @dev: device that requests this phy
+ * @index: the index of the phy
+ *
+ * Returns the phy associated with the given phandle value,
+ * after getting a refcount to it or -ENODEV if there is no such phy or
+ * -EPROBE_DEFER if there is a phandle to the phy, but the device is
+ * not yet loaded.
+ */
+struct phy *of_phy_get(struct device *dev, int index)
+{
+	int ret;
+	struct phy *phy = NULL;
+	struct phy_bind *phy_map = NULL;
+	struct of_phandle_args args;
+	struct device_node *node;
+
+	if (!dev->of_node) {
+		dev_dbg(dev, "device does not have a device node entry\n");
+		return ERR_PTR(-EINVAL);
+	}
+
+	ret = of_parse_phandle_with_args(dev->of_node, "phys", "#phy-cells",
+		index, &args);
+	if (ret) {
+		dev_dbg(dev, "failed to get phy in %s node\n",
+			dev->of_node->full_name);
+		return ERR_PTR(-ENODEV);
+	}
+
+	phy = of_phy_lookup(args.np);
+	if (IS_ERR(phy) || !try_module_get(phy->ops->owner)) {
+		phy = ERR_PTR(-EPROBE_DEFER);
+		goto err0;
+	}
+
+	phy = phy->ops->of_xlate(phy, &args);
+	if (IS_ERR(phy))
+		goto err1;
+
+	phy_map = phy_bind(dev_name(dev), index, dev_name(&phy->dev));
+	if (!IS_ERR(phy_map)) {
+		phy_map->phy = phy;
+		phy_map->auto_bind = true;
+	}
+
+	get_device(&phy->dev);
+
+err1:
+	module_put(phy->ops->owner);
+
+err0:
+	of_node_put(node);
+
+	return phy;
+}
+EXPORT_SYMBOL_GPL(of_phy_get);
+
+/**
+ * devm_of_phy_get() - lookup and obtain a reference to a phy by phandle
+ * @dev: device that requests this phy
+ * @index: the index of the phy
+ *
+ * Calls of_phy_get to get a reference to the PHY and passes on the return
+ * value of of_phy_get. While at that, it also associates the device with the
+ * phy using devres on successful phy get. On driver detach, release function
+ * is invoked on the the devres data and devres data is freed.
+ */
+struct phy *devm_of_phy_get(struct device *dev, int index)
+{
+	struct phy *phy = NULL, **ptr;
+
+	ptr = devres_alloc(devm_phy_release, sizeof(*ptr), GFP_KERNEL);
+	if (!ptr)
+		return ERR_PTR(-ENOMEM);
+
+	phy = of_phy_get(dev, index);
+	if (!IS_ERR(phy)) {
+		*ptr = phy;
+		devres_add(dev, ptr);
+	} else {
+		devres_free(ptr);
+	}
+
+	return phy;
+}
+EXPORT_SYMBOL_GPL(devm_of_phy_get);
+
+/**
+ * of_phy_get_byname() - lookup and obtain a reference to a phy by name
+ * @dev: device that requests this phy
+ * @string - the phy name as given in the dt data
+ *
+ * Calls of_phy_get to get a reference to the PHY and passes on the return
+ * value of of_phy_get.
+ */
+struct phy *of_phy_get_byname(struct device *dev, const char *string)
+{
+	int index;
+
+	if (!dev->of_node) {
+		dev_dbg(dev, "device does not have a device node entry\n");
+		return ERR_PTR(-EINVAL);
+	}
+
+	index = of_property_match_string(dev->of_node, "phy-names", string);
+
+	return of_phy_get(dev, index);
+}
+EXPORT_SYMBOL_GPL(of_phy_get_byname);
+
+/**
+ * devm_of_phy_get_byname() - lookup and obtain a reference to a phy by name
+ * @dev: device that requests this phy
+ * @string: the phy name as given in the dt data
+ *
+ * Calls devm_of_phy_get (which associates the device with the phy using devres
+ * on successful phy get) and passes on the return value of devm_of_phy_get.
+ */
+struct phy *devm_of_phy_get_byname(struct device *dev, const char *string)
+{
+	int index;
+
+	if (!dev->of_node) {
+		dev_dbg(dev, "device does not have a device node entry\n");
+		return ERR_PTR(-EINVAL);
+	}
+
+	index = of_property_match_string(dev->of_node, "phy-names", string);
+
+	return devm_of_phy_get(dev, index);
+}
+EXPORT_SYMBOL_GPL(devm_of_phy_get_byname);
+
+/**
+ * phy_get() - lookup and obtain a reference to a phy.
+ * @dev: device that requests this phy
+ * @index: the index of the phy
+ *
+ * Returns the phy driver, after getting a refcount to it; or
+ * -ENODEV if there is no such phy.  The caller is responsible for
+ * calling phy_put() to release that count.
+ */
+struct phy *phy_get(struct device *dev, int index)
+{
+	struct phy *phy = NULL;
+
+	phy = phy_lookup(dev, index);
+	if (IS_ERR(phy)) {
+		dev_err(dev, "unable to find phy\n");
+		return phy;
+	}
+
+	if (!try_module_get(phy->ops->owner))
+		return ERR_PTR(-EPROBE_DEFER);
+
+	get_device(&phy->dev);
+
+	return phy;
+}
+EXPORT_SYMBOL_GPL(phy_get);
+
+/**
+ * devm_phy_get() - lookup and obtain a reference to a phy.
+ * @dev: device that requests this phy
+ * @index: the index of the phy
+ *
+ * Gets the phy using phy_get(), and associates a device with it using
+ * devres. On driver detach, release function is invoked on the devres data,
+ * then, devres data is freed.
+ */
+struct phy *devm_phy_get(struct device *dev, int index)
+{
+	struct phy **ptr, *phy;
+
+	ptr = devres_alloc(devm_phy_release, sizeof(*ptr), GFP_KERNEL);
+	if (!ptr)
+		return ERR_PTR(-ENOMEM);
+
+	phy = phy_get(dev, index);
+	if (!IS_ERR(phy)) {
+		*ptr = phy;
+		devres_add(dev, ptr);
+	} else {
+		devres_free(ptr);
+	}
+
+	return phy;
+}
+EXPORT_SYMBOL_GPL(devm_phy_get);
+
+/**
+ * phy_create() - create a new phy
+ * @dev: device that is creating the new phy
+ * @label: label given to phy
+ * @of_node: device node of the phy
+ * @type: specifies the phy type
+ * @ops: function pointers for performing phy operations
+ * @priv: private data from phy driver
+ *
+ * Called to create a phy using phy framework.
+ */
+struct phy *phy_create(struct device *dev, const char *label,
+	struct device_node *of_node, int type, struct phy_ops *ops,
+	void *priv)
+{
+	int ret;
+	struct phy *phy;
+	struct phy_bind *phy_bind;
+	const char *devname = NULL;
+
+	if (!dev) {
+		dev_err(dev, "no device provided for PHY\n");
+		ret = -EINVAL;
+		goto err0;
+	}
+
+	if (!ops || !ops->of_xlate || !priv) {
+		dev_err(dev, "no PHY ops/PHY data provided\n");
+		ret = -EINVAL;
+		goto err0;
+	}
+
+	if (!phy_class)
+		phy_core_init();
+
+	phy = kzalloc(sizeof(*phy), GFP_KERNEL);
+	if (!phy) {
+		ret = -ENOMEM;
+		goto err0;
+	}
+
+	devname = dev_name(dev);
+	device_initialize(&phy->dev);
+
+	phy->dev.class = phy_class;
+	phy->dev.parent = dev;
+	phy->label = label;
+	phy->of_node = of_node;
+	phy->type = type;
+	phy->ops = ops;
+
+	dev_set_drvdata(&phy->dev, priv);
+
+	ret = dev_set_name(&phy->dev, "%s", devname);
+	if (ret)
+		goto err1;
+
+	mutex_lock(&phy_bind_mutex);
+	list_for_each_entry(phy_bind, &phy_bind_list, list)
+		if (!(strcmp(phy_bind->phy_dev_name, devname)))
+			phy_bind->phy = phy;
+	mutex_unlock(&phy_bind_mutex);
+
+	ret = device_add(&phy->dev);
+	if (ret)
+		goto err2;
+
+	return phy;
+
+err2:
+	phy_bind->phy = NULL;
+
+err1:
+	put_device(&phy->dev);
+	kfree(phy);
+
+err0:
+	return ERR_PTR(ret);
+}
+EXPORT_SYMBOL_GPL(phy_create);
+
+/**
+ * devm_phy_create() - create a new phy
+ * @dev: device that is creating the new phy
+ * @dev: device that is creating the new phy
+ * @label: label given to phy
+ * @of_node: device node of the phy
+ * @type: specifies the phy type
+ * @ops: function pointers for performing phy operations
+ * @priv: private data from phy driver
+ *
+ * Creates a new PHY device adding it to the PHY class.
+ * While at that, it also associates the device with the phy using devres.
+ * On driver detach, release function is invoked on the devres data,
+ * then, devres data is freed.
+ */
+struct phy *devm_phy_create(struct device *dev, const char *label,
+	struct device_node *of_node, int type, struct phy_ops *ops,
+	void *priv)
+{
+	struct phy **ptr, *phy;
+
+	ptr = devres_alloc(devm_phy_consume, sizeof(*ptr), GFP_KERNEL);
+	if (!ptr)
+		return ERR_PTR(-ENOMEM);
+
+	phy = phy_create(dev, label, of_node, type, ops, priv);
+	if (!IS_ERR(phy)) {
+		*ptr = phy;
+		devres_add(dev, ptr);
+	} else {
+		devres_free(ptr);
+	}
+
+	return phy;
+}
+EXPORT_SYMBOL_GPL(devm_phy_create);
+
+/**
+ * phy_destroy() - destroy the phy
+ * @phy: the phy to be destroyed
+ *
+ * Called to destroy the phy.
+ */
+void phy_destroy(struct phy *phy)
+{
+	struct phy_bind *phy_bind;
+
+	mutex_lock(&phy_bind_mutex);
+	list_for_each_entry(phy_bind, &phy_bind_list, list) {
+		if (phy_bind->phy == phy)
+			phy_bind->phy = NULL;
+
+		if (phy_bind->auto_bind) {
+			list_del(&phy_bind->list);
+			kfree(phy_bind);
+		}
+	}
+	mutex_unlock(&phy_bind_mutex);
+
+	device_unregister(&phy->dev);
+}
+EXPORT_SYMBOL_GPL(phy_destroy);
+
+/**
+ * devm_phy_destroy() - destroy the PHY
+ * @dev: device that wants to release this phy
+ * @phy: the phy returned by devm_phy_get()
+ *
+ * destroys the devres associated with this phy and invokes phy_destroy
+ * to destroy the phy.
+ */
+void devm_phy_destroy(struct device *dev, struct phy *phy)
+{
+	int r;
+
+	r = devres_destroy(dev, devm_phy_consume, devm_phy_match, phy);
+	dev_WARN_ONCE(dev, r, "couldn't find PHY resource\n");
+}
+EXPORT_SYMBOL_GPL(devm_phy_destroy);
+
+/**
+ * phy_bind() - bind the phy and the controller that uses the phy
+ * @dev_name: the device name of the device that will bind to the phy
+ * @index: index to specify the port number
+ * @phy_dev_name: the device name of the phy
+ *
+ * Fills the phy_bind structure with the dev_name and phy_dev_name. This will
+ * be used when the phy driver registers the phy and when the controller
+ * requests this phy.
+ *
+ * To be used by platform specific initialization code.
+ */
+struct phy_bind *phy_bind(const char *dev_name, int index,
+				const char *phy_dev_name)
+{
+	struct phy_bind *phy_bind;
+
+	mutex_lock(&phy_bind_mutex);
+	list_for_each_entry(phy_bind, &phy_bind_list, list) {
+		if (!strcmp(phy_bind->dev_name, dev_name) && phy_bind->index ==
+			index) {
+			phy_bind->phy_dev_name = phy_dev_name;
+			goto ret0;
+		}
+	}
+
+	phy_bind = kzalloc(sizeof(*phy_bind), GFP_KERNEL);
+	if (!phy_bind) {
+		phy_bind = ERR_PTR(-ENOMEM);
+		goto ret0;
+	}
+
+	phy_bind->dev_name = dev_name;
+	phy_bind->phy_dev_name = phy_dev_name;
+	phy_bind->index = index;
+	phy_bind->auto_bind = false;
+
+	list_add_tail(&phy_bind->list, &phy_bind_list);
+
+ret0:
+	mutex_unlock(&phy_bind_mutex);
+	return phy_bind;
+}
+EXPORT_SYMBOL_GPL(phy_bind);
+
+static ssize_t phy_name_show(struct device *dev,
+			     struct device_attribute *attr, char *buf)
+{
+	struct phy *phy;
+
+	phy = container_of(dev, struct phy, dev);
+
+	return sprintf(buf, "%s\n", phy->label);
+}
+
+static ssize_t phy_bind_show(struct device *dev,
+			     struct device_attribute *attr, char *buf)
+{
+	struct phy_bind *phy_bind;
+	struct phy *phy;
+	char *p = buf;
+	int len;
+
+	phy = container_of(dev, struct phy, dev);
+
+	list_for_each_entry(phy_bind, &phy_bind_list, list)
+		if (phy_bind->phy == phy)
+			p += sprintf(p, "%s %d %s\n", phy_bind->dev_name,
+				phy_bind->index, phy_bind->phy_dev_name);
+	len = (p - buf);
+
+	return len;
+}
+
+static struct device_attribute phy_dev_attrs[] = {
+	__ATTR(label, 0444, phy_name_show, NULL),
+	__ATTR(phy_bind, 0444, phy_bind_show, NULL),
+	__ATTR_NULL,
+};
+
+/**
+ * phy_release() - release the phy
+ * @dev: the dev member within phy
+ *
+ * when the last reference to the device is removed; it is called
+ * from the embedded kobject as release method.
+ */
+static void phy_release(struct device *dev)
+{
+	struct phy *phy;
+
+	phy = container_of(dev, struct phy, dev);
+	dev_dbg(dev, "releasing '%s'\n", dev_name(dev));
+	kfree(phy);
+}
+
+static int phy_core_init(void)
+{
+	if (phy_class)
+		return 0;
+
+	phy_class = class_create(THIS_MODULE, "phy");
+	if (IS_ERR(phy_class)) {
+		pr_err("failed to create phy class --> %ld\n",
+			PTR_ERR(phy_class));
+		return PTR_ERR(phy_class);
+	}
+
+	phy_class->dev_release = phy_release;
+	phy_class->dev_attrs = phy_dev_attrs;
+
+	return 0;
+}
+module_init(phy_core_init);
+
+static void __exit phy_core_exit(void)
+{
+	class_destroy(phy_class);
+}
+module_exit(phy_core_exit);
+
+MODULE_DESCRIPTION("Generic PHY Framework");
+MODULE_AUTHOR("Kishon Vijay Abraham I <kishon at ti.com>");
+MODULE_LICENSE("GPL v2");
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
new file mode 100644
index 0000000..97a48bd
--- /dev/null
+++ b/include/linux/phy/phy.h
@@ -0,0 +1,228 @@
+/*
+ * phy.h -- generic phy header file
+ *
+ * Copyright (C) 2013 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 as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * Author: Kishon Vijay Abraham I <kishon at ti.com>
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#ifndef __DRIVERS_PHY_H
+#define __DRIVERS_PHY_H
+
+#include <linux/err.h>
+#include <linux/of.h>
+#include <linux/device.h>
+
+struct phy;
+
+/**
+ * struct phy_ops - set of function pointers for performing phy operations
+ * @init: operation to be performed for initializing phy
+ * @exit: operation to be performed while exiting
+ * @suspend: suspending the phy
+ * @resume: resuming the phy
+ * @power_on: powering on the phy
+ * @power_off: powering off the phy
+ * @of_xlate: function pointer to obtain phy instance from phy pointer
+ * @owner: the module owner containing the ops
+ */
+struct phy_ops {
+	int	(*init)(struct phy *phy);
+	int	(*exit)(struct phy *phy);
+	int	(*suspend)(struct phy *phy);
+	int	(*resume)(struct phy *phy);
+	int	(*power_on)(struct phy *phy);
+	int	(*power_off)(struct phy *phy);
+	struct phy * (*of_xlate)(struct phy *phy, struct of_phandle_args *args);
+	struct module *owner;
+};
+
+/**
+ * struct phy - represent the phy device
+ * @dev: phy device
+ * @label: label given to phy
+ * @type: specifies the phy type
+ * @of_node: device node of the phy
+ * @ops: function pointers for performing phy operations
+ */
+struct phy {
+	struct device		dev;
+	const char		*label;
+	int			type;
+	struct device_node	*of_node;
+	struct phy_ops		*ops;
+};
+
+/**
+ * struct phy_bind - represent the binding for the phy
+ * @dev_name: the device name of the device that will bind to the phy
+ * @phy_dev_name: the device name of the phy
+ * @index: used if a single controller uses multiple phys
+ * @auto_bind: tells if the binding is done explicitly from board file or not
+ * @phy: reference to the phy
+ * @list: to maintain a linked list of the binding information
+ */
+struct phy_bind {
+	const char	*dev_name;
+	const char	*phy_dev_name;
+	int		index;
+	int		auto_bind:1;
+	struct phy	*phy;
+	struct list_head list;
+};
+
+#if IS_ENABLED(CONFIG_GENERIC_PHY)
+extern struct phy *phy_get(struct device *dev, int index);
+extern struct phy *devm_phy_get(struct device *dev, int index);
+extern struct phy *of_phy_get(struct device *dev, int index);
+extern struct phy *devm_of_phy_get(struct device *dev, int index);
+extern struct phy *of_phy_get_byname(struct device *dev, const char *string);
+extern struct phy *devm_of_phy_get_byname(struct device *dev,
+	const char *string);
+extern void phy_put(struct phy *phy);
+extern void devm_phy_put(struct device *dev, struct phy *phy);
+extern struct phy *of_phy_xlate(struct phy *phy, struct of_phandle_args *args);
+extern struct phy *phy_create(struct device *dev, const char *label,
+	struct device_node *of_node, int type, struct phy_ops *ops,
+	void *priv);
+extern struct phy *devm_phy_create(struct device *dev, const char *label,
+	struct device_node *of_node, int type, struct phy_ops *ops,
+	void *priv);
+extern void phy_destroy(struct phy *phy);
+extern void devm_phy_destroy(struct device *dev, struct phy *phy);
+extern struct phy_bind *phy_bind(const char *dev_name, int index,
+				const char *phy_dev_name);
+#else
+static inline struct phy *phy_get(struct device *dev, int index)
+{
+	return ERR_PTR(-ENOSYS);
+}
+
+static inline struct phy *devm_phy_get(struct device *dev, int index)
+{
+	return ERR_PTR(-ENOSYS);
+}
+
+static inline struct phy *of_phy_get(struct device *dev, int index)
+{
+	return ERR_PTR(-ENOSYS);
+}
+
+static inline struct phy *devm_of_phy_get(struct device *dev, int index)
+{
+	return ERR_PTR(-ENOSYS);
+}
+
+static inline struct phy *of_phy_get_byname(struct device *dev,
+	const char *string)
+{
+	return ERR_PTR(-ENOSYS);
+}
+
+static inline struct phy *devm_of_phy_get_byname(struct device *dev,
+	const char *string)
+{
+	return ERR_PTR(-ENOSYS);
+}
+
+static inline void phy_put(struct phy *phy)
+{
+}
+
+static inline void devm_phy_put(struct device *dev, struct phy *phy)
+{
+}
+
+static inline struct phy *of_phy_xlate(struct phy *phy,
+	struct of_phandle_args *args)
+{
+	return ERR_PTR(-ENOSYS);
+}
+
+static inline struct phy *phy_create(struct device *dev, const char *label,
+	struct device_node *of_node, int type, struct phy_ops *ops,
+	void *priv)
+{
+	return ERR_PTR(-ENOSYS);
+}
+
+static inline struct phy *devm_phy_create(struct device *dev, const char *label,
+	struct device_node *of_node, int type, struct phy_ops *ops,
+	void *priv)
+{
+	return ERR_PTR(-ENOSYS);
+}
+
+static inline void phy_destroy(struct phy *phy)
+{
+}
+
+static inline void devm_phy_destroy(struct device *dev, struct phy *phy)
+{
+}
+
+static inline struct phy_bind *phy_bind(const char *dev_name, int index,
+				const char *phy_dev_name)
+{
+	return ERR_PTR(-ENOSYS);
+}
+#endif
+
+static inline int phy_init(struct phy *phy)
+{
+	if (phy->ops->init)
+		return phy->ops->init(phy);
+
+	return -EINVAL;
+}
+
+static inline int phy_exit(struct phy *phy)
+{
+	if (phy->ops->exit)
+		return phy->ops->exit(phy);
+
+	return -EINVAL;
+}
+
+static inline int phy_suspend(struct phy *phy)
+{
+	if (phy->ops->suspend)
+		return phy->ops->suspend(phy);
+
+	return -EINVAL;
+}
+
+static inline int phy_resume(struct phy *phy)
+{
+	if (phy->ops->resume)
+		return phy->ops->resume(phy);
+
+	return -EINVAL;
+}
+
+static inline int phy_poweron(struct phy *phy)
+{
+	if (phy->ops->power_on)
+		return phy->ops->power_on(phy);
+
+	return -EINVAL;
+}
+
+static inline int phy_poweroff(struct phy *phy)
+{
+	if (phy->ops->power_off)
+		return phy->ops->power_off(phy);
+
+	return -EINVAL;
+}
+#endif /* __DRIVERS_PHY_H */
-- 
1.7.10.4



From kishon at ti.com  Wed Apr  3 08:53:48 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Wed, 3 Apr 2013 18:23:48 +0530
Subject: [PATCH v5 0/6] Generic PHY Framework
Message-ID: <1364993634-6378-1-git-send-email-kishon@ti.com>

Added a generic PHY framework that provides a set of APIs for the PHY drivers
to create/destroy a PHY and APIs for the PHY users to obtain a reference to
the PHY with or without using phandle. To obtain a reference to the PHY
without using phandle, the platform specfic intialization code (say from board
file) should have already called phy_bind with the binding information. The
binding information consists of phy's device name, phy user device name and an
index. The index is used when the same phy user binds to mulitple phys.

This framework will be of use only to devices that uses external PHY (PHY
functionality is not embedded within the controller).

The intention of creating this framework is to bring the phy drivers spread
all over the Linux kernel to drivers/phy to increase code re-use and to
increase code maintainability.

Comments to make PHY as bus wasn't done because PHY devices can be part of
other bus and making a same device attached to multiple bus leads to bad
design.

Making omap-usb2 and twl4030 to use this framework is provided as a sample.

This patch series is developed on linus tree HEAD. Once the patch series gets
finalised I'll resend omap-usb2 and twl4030 part based on Felipe's tree.

Changes from v4:
* removed of_phy_get_with_args/devm_of_phy_get_with_args. Now the *phy providers*
  should use their custom implementation of of_xlate or use of_phy_xlate to get
  *phy instance* from *phy providers*.
* Added of_phy_xlate to be used by *phy providers* if it provides only one PHY.
* changed phy_core from having subsys_initcall to module_init.
* other minor fixes.

Changes from v3:
* Changed the return value of PHY APIs to ENOSYS
* Added APIs of_phy_get_with_args/devm_of_phy_get_with_args to support getting
  PHYs if the same IP implements multiple PHYs.
* modified phy_bind API so that the binding information can now be _updated_.
  In effect of this removed the binding information added in board files and
  added only in usb-musb.c. If a particular board uses a different phy binding,
  it can update it in board file after usb_musb_init().
* Added Documentation/devicetree/bindings/phy/phy-bindings.txt for dt binding
  information.

Changes from v2:
* removed phy_descriptor structure completely so changed the APIs which were
  taking phy_descriptor as parameters
* Added 2 more APIs *of_phy_get_byname* and *devm_of_phy_get_byname* to be used
  by PHY user drivers which has *phy* and *phy-names* binding in the dt data
* Fixed a few typos
* Removed phy_list and we now use class_dev_iter_init, class_dev_iter_next and
  class_dev_iter_exit for traversing through the phy list. (Note we still need
  phy_bind list and phy_bind_mutex).
* Changed the sysfs entry name from *bind* to *phy_bind*.

Changes from v1:
* Added Documentation for the PHY framework
* Added few more APIs mostly w.r.t devres
* Modified omap-usb2 and twl4030 to make use of the new framework

Did USB enumeration testing in panda and beagle.

Kishon Vijay Abraham I (6):
  drivers: phy: add generic PHY framework
  usb: phy: omap-usb2: use the new generic PHY framework
  usb: otg: twl4030: use the new generic PHY framework
  ARM: OMAP: USB: Add phy binding information
  ARM: dts: omap: update usb_otg_hs data
  usb: musb: omap2430: use the new generic PHY framework

 Documentation/ABI/testing/sysfs-class-phy          |   15 +
 .../devicetree/bindings/phy/phy-bindings.txt       |   67 +++
 Documentation/devicetree/bindings/usb/omap-usb.txt |    5 +
 Documentation/devicetree/bindings/usb/usb-phy.txt  |    6 +
 Documentation/phy.txt                              |  113 ++++
 MAINTAINERS                                        |    7 +
 arch/arm/boot/dts/omap3.dtsi                       |    2 +
 arch/arm/boot/dts/omap4.dtsi                       |    3 +
 arch/arm/boot/dts/twl4030.dtsi                     |    1 +
 arch/arm/mach-omap2/usb-musb.c                     |    7 +-
 drivers/Kconfig                                    |    2 +
 drivers/Makefile                                   |    2 +
 drivers/phy/Kconfig                                |   13 +
 drivers/phy/Makefile                               |    5 +
 drivers/phy/phy-core.c                             |  616 ++++++++++++++++++++
 drivers/usb/musb/musb_core.h                       |    2 +
 drivers/usb/musb/omap2430.c                        |   22 +-
 drivers/usb/otg/twl4030-usb.c                      |   37 ++
 drivers/usb/phy/omap-usb2.c                        |   48 ++
 include/linux/phy/phy.h                            |  228 ++++++++
 20 files changed, 1194 insertions(+), 7 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-class-phy
 create mode 100644 Documentation/devicetree/bindings/phy/phy-bindings.txt
 create mode 100644 Documentation/phy.txt
 create mode 100644 drivers/phy/Kconfig
 create mode 100644 drivers/phy/Makefile
 create mode 100644 drivers/phy/phy-core.c
 create mode 100644 include/linux/phy/phy.h

-- 
1.7.10.4



From kishon at ti.com  Wed Apr  3 08:53:54 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Wed, 3 Apr 2013 18:23:54 +0530
Subject: [PATCH v5 6/6] usb: musb: omap2430: use the new generic PHY framework
In-Reply-To: <1364993634-6378-1-git-send-email-kishon@ti.com>
References: <1364993634-6378-1-git-send-email-kishon@ti.com>
Message-ID: <1364993634-6378-7-git-send-email-kishon@ti.com>

Use the generic PHY framework API to get the PHY. The usb_phy_set_suspend
and usb_phy_set_resume is replaced with phy_suspend and phy_resume to
align with the new PHY framework.

musb->xceiv can't be removed as of now because musb core uses xceiv.state and
xceiv.otg. Once there is a separate state machine to handle otg, these can be
moved out of xceiv and then we can start using the generic PHY framework.

Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
---
 drivers/usb/musb/musb_core.h |    2 ++
 drivers/usb/musb/omap2430.c  |   22 ++++++++++++++++------
 2 files changed, 18 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 7fb4819..78251fd 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -46,6 +46,7 @@
 #include <linux/usb.h>
 #include <linux/usb/otg.h>
 #include <linux/usb/musb.h>
+#include <linux/phy/phy.h>
 
 struct musb;
 struct musb_hw_ep;
@@ -357,6 +358,7 @@ struct musb {
 	u16			int_tx;
 
 	struct usb_phy		*xceiv;
+	struct phy		*phy;
 
 	int nIrq;
 	unsigned		irq_wake:1;
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 1a42a45..55f071d 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -349,14 +349,24 @@ static int omap2430_musb_init(struct musb *musb)
 	 * up through ULPI.  TWL4030-family PMICs include one,
 	 * which needs a driver, drivers aren't always needed.
 	 */
-	if (dev->parent->of_node)
+	if (dev->parent->of_node) {
+		musb->phy = devm_of_phy_get_byname(dev->parent, "usb2-phy");
+
+		/* We can't totally remove musb->xceiv as of now because
+		 * musb core uses xceiv.state and xceiv.otg. Once we have
+		 * a separate state machine to handle otg, these can be moved
+		 * out of xceiv and then we can start using the generic PHY
+		 * framework
+		 */
 		musb->xceiv = devm_usb_get_phy_by_phandle(dev->parent,
 		    "usb-phy", 0);
-	else
+	} else {
 		musb->xceiv = devm_usb_get_phy_dev(dev, 0);
+		musb->phy = devm_phy_get(dev, 0);
+	}
 
-	if (IS_ERR_OR_NULL(musb->xceiv)) {
-		pr_err("HS USB OTG: no transceiver configured\n");
+	if (IS_ERR_OR_NULL(musb->xceiv) || IS_ERR(musb->phy)) {
+		dev_err(dev, "no transceiver configured\n");
 		return -EPROBE_DEFER;
 	}
 
@@ -612,7 +622,7 @@ static int omap2430_runtime_suspend(struct device *dev)
 				OTG_INTERFSEL);
 
 		omap2430_low_level_exit(musb);
-		usb_phy_set_suspend(musb->xceiv, 1);
+		phy_suspend(musb->phy);
 	}
 
 	return 0;
@@ -628,7 +638,7 @@ static int omap2430_runtime_resume(struct device *dev)
 		musb_writel(musb->mregs, OTG_INTERFSEL,
 				musb->context.otg_interfsel);
 
-		usb_phy_set_suspend(musb->xceiv, 0);
+		phy_resume(musb->phy);
 	}
 
 	return 0;
-- 
1.7.10.4



From kishon at ti.com  Wed Apr  3 08:53:51 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Wed, 3 Apr 2013 18:23:51 +0530
Subject: [PATCH v5 3/6] usb: otg: twl4030: use the new generic PHY framework
In-Reply-To: <1364993634-6378-1-git-send-email-kishon@ti.com>
References: <1364993634-6378-1-git-send-email-kishon@ti.com>
Message-ID: <1364993634-6378-4-git-send-email-kishon@ti.com>

Used the generic PHY framework API to create the PHY. twl4030_usb_suspend
and twl4030_usb_resume is added to phy_ops in order to align
with the new framework.

However using the old USB PHY library cannot be completely removed
because OTG is intertwined with PHY and moving to the new
framework completely will break OTG. Once we have a separate OTG state machine,
we can get rid of the USB PHY library.

Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
---
 drivers/usb/otg/twl4030-usb.c |   37 +++++++++++++++++++++++++++++++++++++
 1 file changed, 37 insertions(+)

diff --git a/drivers/usb/otg/twl4030-usb.c b/drivers/usb/otg/twl4030-usb.c
index a994715..6dab049 100644
--- a/drivers/usb/otg/twl4030-usb.c
+++ b/drivers/usb/otg/twl4030-usb.c
@@ -33,6 +33,7 @@
 #include <linux/io.h>
 #include <linux/delay.h>
 #include <linux/usb/otg.h>
+#include <linux/phy/phy.h>
 #include <linux/usb/musb-omap.h>
 #include <linux/usb/ulpi.h>
 #include <linux/i2c/twl.h>
@@ -575,10 +576,39 @@ static int twl4030_set_host(struct usb_otg *otg, struct usb_bus *host)
 	return 0;
 }
 
+static int twl4030_usb_suspend(struct phy *phy)
+{
+	struct twl4030_usb *twl = dev_get_drvdata(&phy->dev);
+
+	twl4030_phy_suspend(twl, 1);
+
+	return 0;
+}
+
+static int twl4030_usb_resume(struct phy *phy)
+{
+	struct twl4030_usb *twl = dev_get_drvdata(&phy->dev);
+
+	if (!twl->asleep)
+		return -EBUSY;
+	__twl4030_phy_resume(twl);
+	twl->asleep = 0;
+
+	return 0;
+}
+
+static struct phy_ops ops = {
+	.suspend	= twl4030_usb_suspend,
+	.resume		= twl4030_usb_resume,
+	.of_xlate	= of_phy_xlate,
+	.owner		= THIS_MODULE,
+};
+
 static int twl4030_usb_probe(struct platform_device *pdev)
 {
 	struct twl4030_usb_data *pdata = pdev->dev.platform_data;
 	struct twl4030_usb	*twl;
+	struct phy		*phy;
 	int			status, err;
 	struct usb_otg		*otg;
 	struct device_node	*np = pdev->dev.of_node;
@@ -617,6 +647,13 @@ static int twl4030_usb_probe(struct platform_device *pdev)
 	otg->set_host		= twl4030_set_host;
 	otg->set_peripheral	= twl4030_set_peripheral;
 
+	phy = devm_phy_create(twl->dev, "twl4030", pdev->dev.of_node,
+		USB_PHY_TYPE_USB2, &ops, twl);
+	if (IS_ERR(phy)) {
+		dev_dbg(&pdev->dev, "Failed to create PHY\n");
+		return PTR_ERR(phy);
+	}
+
 	/* init spinlock for workqueue */
 	spin_lock_init(&twl->lock);
 
-- 
1.7.10.4



From kishon at ti.com  Wed Apr  3 08:53:52 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Wed, 3 Apr 2013 18:23:52 +0530
Subject: [PATCH v5 4/6] ARM: OMAP: USB: Add phy binding information
In-Reply-To: <1364993634-6378-1-git-send-email-kishon@ti.com>
References: <1364993634-6378-1-git-send-email-kishon@ti.com>
Message-ID: <1364993634-6378-5-git-send-email-kishon@ti.com>

In order for controllers to get PHY in case of non dt boot, the phy
binding information should be added in the platform specific
initialization code using phy_bind.

Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
---
 arch/arm/mach-omap2/usb-musb.c |    7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
index 3242a55..f01bc42 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -24,6 +24,7 @@
 #include <linux/dma-mapping.h>
 #include <linux/io.h>
 #include <linux/usb/musb.h>
+#include <linux/phy/phy.h>
 
 #include "omap_device.h"
 #include "soc.h"
@@ -85,8 +86,12 @@ void __init usb_musb_init(struct omap_musb_board_data *musb_board_data)
 	musb_plat.mode = board_data->mode;
 	musb_plat.extvbus = board_data->extvbus;
 
-	if (cpu_is_omap44xx())
+	if (cpu_is_omap44xx()) {
 		musb_plat.has_mailbox = true;
+		phy_bind("musb-hdrc.0.auto", 0, "omap-usb2.1.auto");
+	} else if (cpu_is_omap34xx()) {
+		phy_bind("musb-hdrc.0.auto", 0, "twl4030_usb");
+	}
 
 	if (soc_is_am35xx()) {
 		oh_name = "am35x_otg_hs";
-- 
1.7.10.4



From shawn.guo at linaro.org  Wed Apr  3 08:56:22 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Wed, 3 Apr 2013 20:56:22 +0800
Subject: [GIT PULL] mxs fixes for 3.9, take 4
Message-ID: <20130403125620.GA21790@S2101-09.ap.freescale.net>

The following changes since commit 07961ac7c0ee8b546658717034fe692fd12eefa9:

  Linux 3.9-rc5 (2013-03-31 15:12:43 -0700)

are available in the git repository at:

  git://git.linaro.org/people/shawnguo/linux-2.6.git tags/mxs-fixes-3.9-4

for you to fetch changes up to 55985e15b80beb339d3e332f00a26003deff14e6:

  ARM: mxs: Slow down the I2C clock speed (2013-04-03 09:34:01 +0800)

----------------------------------------------------------------
The mxs fixes for 3.9, take 4:
 - A couple mxs boards that run I2C at 400 kHz experience some unstable
   issue occasionally.  Slow down the clock speed to have I2C work
   reliably.

----------------------------------------------------------------
Marek Vasut (1):
      ARM: mxs: Slow down the I2C clock speed

 arch/arm/boot/dts/imx28-m28evk.dts |    1 -
 arch/arm/boot/dts/imx28-sps1.dts   |    1 -
 2 files changed, 2 deletions(-)



From robherring2 at gmail.com  Wed Apr  3 09:01:02 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Wed, 03 Apr 2013 08:01:02 -0500
Subject: [PATCH] ARM: imx: do not bring up unavailable cores
In-Reply-To: <CAOMZO5C5uVDWi1vXTeyQF5P8N=ARHvW-qMknVeyG4zY85KcEkw@mail.gmail.com>
References: <1364913146-26084-1-git-send-email-shawn.guo@linaro.org>
 <20130402151715.GB6608@mudshark.cambridge.arm.com>
 <20130403021348.GK24039@S2101-09.ap.freescale.net>
 <CAOMZO5AJjz4Z68GxkeCM3rH9p9-z6jaOM35MBSjN-UE_Dk4=eg@mail.gmail.com>
 <20130403024719.GF27148@S2101-09.ap.freescale.net>
 <CAOMZO5C5uVDWi1vXTeyQF5P8N=ARHvW-qMknVeyG4zY85KcEkw@mail.gmail.com>
Message-ID: <515C280E.7000500@gmail.com>

On 04/02/2013 10:18 PM, Fabio Estevam wrote:
> On Tue, Apr 2, 2013 at 11:47 PM, Shawn Guo <shawn.guo at linaro.org> wrote:
> 
>> Ah, great.  I haven't checked the U-Boot code for some time.  But does
>> U-Boot remove cpu nodes of those unavailable cores from device tree
>> before passing it to kernel?
> 
> No, it just uses the information from the SCU to print the name of the
> mx6 variant on boot.

It is quite common and the correct place IMHO to do this dtb fixup in
u-boot. You can just add 'status = "disabled";' properties. I'm not sure
that the kernel is checking the status though.

Reading the core count from the SCU is the only reason the SCU needs to
be statically mapped, so if you remove that you can remove the static
mapping.

Rob


From gang.chen at asianux.com  Wed Apr  3 09:00:56 2013
From: gang.chen at asianux.com (Chen Gang)
Date: Wed, 03 Apr 2013 21:00:56 +0800
Subject: [Suggestion] ARM64:kernel: compiling issue for early_console.
In-Reply-To: <515C14FD.4040703@codeaurora.org>
References: <5152DB83.8080703@asianux.com>
 <20130327115509.GA1603@MacBook-Pro.local> <5152DFF1.2090000@asianux.com>
 <515BE49C.8040601@asianux.com> <515C14FD.4040703@codeaurora.org>
Message-ID: <515C2808.70406@asianux.com>

On 2013?04?03? 19:39, Christopher Covington wrote:
> Maybe somebody else does have a fix, but Catalin mentioned he was going on
> vacation for two weeks on March 28th in "[GIT PULL] Preparatory GIC patches
> for arm64 support".
> 
  ok, I can wait.

>> >   if really no one fix it within this week, I should try (since I find it).
> I'm sure a fix would be appreciated.
> 

  ok, thanks. I prefer to wait (at least for the end of Catalin's vacation).


>> > On 2013?03?27? 20:02, Chen Gang wrote:
>>> >> On 2013?03?27? 19:55, Catalin Marinas wrote:
>>>> >>>
>>>> >>> I saw some patches from tglx on unifying the various early printk
>>>> >>> implementations, though not sure whether it's those patches causing it
>>>> >>> (in which case arm64 needs to be updated as well).
> I looked briefly and wasn't able to find this patchset.

  ok, thank for your results.


-- 
Chen Gang

Asianux Corporation


From jamie at jamieiles.com  Wed Apr  3 09:20:35 2013
From: jamie at jamieiles.com (Jamie Iles)
Date: Wed, 3 Apr 2013 14:20:35 +0100
Subject: [PATCH 2/2] ARM: remove mach .init_irq for irqchip_init users
In-Reply-To: <1364503606-10597-3-git-send-email-maxime.ripard@free-electrons.com>
References: <1364503606-10597-1-git-send-email-maxime.ripard@free-electrons.com>
 <1364503606-10597-3-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <20130403132035.GA2413@page>

On Thu, Mar 28, 2013 at 09:46:45PM +0100, Maxime Ripard wrote:
> Now that the arm core code calls irqchip_init, we can remove it from all
> the machines that were using it.
> 
> Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
> Acked-by: Simon Horman <horms+renesas at verge.net.au>

Acked-by: Jamie Iles <jamie at jamieiles.com>

Thanks Maxime!


From sergei.shtylyov at cogentembedded.com  Wed Apr  3 09:22:22 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Wed, 03 Apr 2013 17:22:22 +0400
Subject: [PATCH 1/2] ARM: shmobile: R8A7779: add Ether support
In-Reply-To: <87txnocw6n.wl%kuninori.morimoto.gx@renesas.com>
References: <201304020204.54546.sergei.shtylyov@cogentembedded.com>
 <87wqsl6ale.wl%kuninori.morimoto.gx@renesas.com>
 <515AC546.90905@cogentembedded.com>
 <87txnocw6n.wl%kuninori.morimoto.gx@renesas.com>
Message-ID: <515C2D0E.8010607@cogentembedded.com>

Hello.

On 03-04-2013 4:08, Kuninori Morimoto wrote:

>>> Then, this (void *pdata) should be
>>> (struct sh_eth_plat_data *pdata) IMO

>>      ether_device.dev.platform_data is 'void *'. I didn't want to bring in
>> extra header for the little use.

> Not enough reason for me.

> "void *" means there is no pointer check,
> and extra header is just 1 line. No ?

    There's no pointer check either if we just initialize the 'platform_data'
member as part of the platfrom device initializer, so we can actually stuff 
pointer to any nonsense there. Why make this case different?

> If you want to use this style,
> then, additional extra header is fate, IMO

    We can agree to disagree here. :-)

WBR, Sergei



From arnd at arndb.de  Wed Apr  3 09:25:49 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed, 3 Apr 2013 13:25:49 +0000
Subject: [RFC PATCH] at_hdmac: move to generic DMA binding
In-Reply-To: <1364994863-7347-1-git-send-email-=ludovic.desroches@atmel.com>
References: <1364994863-7347-1-git-send-email-=ludovic.desroches@atmel.com>
Message-ID: <201304031325.49813.arnd@arndb.de>

On Wednesday 03 April 2013, =ludovic.desroches at atmel.com wrote:
> +
> +DMA clients connected to the Atmel DMA controller must use the format
> +described in the dma.txt file, using a four-cell specifier for each channel.
> +The four cells in order are:
> +
> +1. A phandle pointing to the DMA controller
> +2. The memory interface (16 most significant bits), the peripheral interface
> +(16 less significant bits)
> 
> Most of our products have only one memory interface which is the interface 0
> from the dma controller point of view. The SAMA5D3 family is the only one to
> have two memory interfaces (0 and 1) so the peripheral interface is interface 2
> instead of interface 1.
> Since it will concern only one device family, I think it is better to put both
> interfaces in the same cell.

Seems reasonable.

> +3. The peripheral identifier (can be different for tx and rx)
> +4. The chunk transfer size, must be 1, 4, 8 or 16

I wonder if the chunk transfer size should instead be set using
dmaengine_slave_config(). Is this something that you need to have
configured at the platform level, or can it be hardcoded into the
slave driver independent of where that slave is being used?

	Arnd


From sergei.shtylyov at cogentembedded.com  Wed Apr  3 09:27:00 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Wed, 03 Apr 2013 17:27:00 +0400
Subject: [PATCH 1/2] ARM: shmobile: R8A7779: add Ether support
In-Reply-To: <87sj38cvfn.wl%kuninori.morimoto.gx@renesas.com>
References: <201304020204.54546.sergei.shtylyov@cogentembedded.com>
 <87y5d16b1d.wl%kuninori.morimoto.gx@renesas.com>
 <515AC4C8.1080803@cogentembedded.com>
 <87sj38cvfn.wl%kuninori.morimoto.gx@renesas.com>
Message-ID: <515C2E24.1080108@cogentembedded.com>

Hello.

On 03-04-2013 4:25, Kuninori Morimoto wrote:

>>> Current ARM SoC is trying to not use platform_device_register()
>>> Please use platform_device_register_xxx()
>>> Same comment for [2/2]

>>      Is there some rationale to it? I don't find platform_device_register_xxx()
>> especially handy to use.

> http://www.spinics.net/lists/linux-sh/msg16871.html

    I don't see there actual Greg KH's rationale for not using 
platform_register_device().

WBR, Sergei



From linus.walleij at linaro.org  Wed Apr  3 09:28:03 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Wed, 3 Apr 2013 15:28:03 +0200
Subject: [PATCH 0/3] gpio: remove GENERIC_GPIO completely
In-Reply-To: <1364562678-8945-1-git-send-email-acourbot@nvidia.com>
References: <1364562678-8945-1-git-send-email-acourbot@nvidia.com>
Message-ID: <CACRpkdak79-KuSXdRb7B83Xe+6-f-gNK12Q+EVbXNPSwJLqgrw@mail.gmail.com>

On Fri, Mar 29, 2013 at 2:11 PM, Alexandre Courbot <gnurou at gmail.com> wrote:

> Since I have received no death threat from architecture maintainers I'd like to
> proceed with the remainder of this work so that it doesn't go half-baked into
> 3.10. These three patches finish the removal of the GENERIC_GPIO config option
> which has been made equivalent to GPIOLIB in the previous series. It does so by
> first changing all references to GENERIC_GPIO into GPIOLIB in driver code and
> configuration files, and then removing the unused option from the Kconfig files
> where it is declared.
>
> The last patch in the series confirms gpiolib in its new role as GPIO framework
> by renaming CONFIG_GPIOLIB into CONFIG_GPIO, following the model used by other
> frameworks. This name changing might rise concern but it seems more logical to
> me and the historical gpiolib name is still mentioned in the documentation to
> relieve the confusion.
>
> If I can get a few acks on these (or at least the first two ones) I'd like to
> include them into my next branch as soon as possible so points of breakage can
> be fixed. There are indeed a few new users of GENERIC_GPIO (CC Romain, I sent a
> warning but saw no action so far) in the next tree and compilation will break
> for them.
>
> Another issue, I could not update the Chinese documentation in a satisfying
> manner due to my absence of Chinese skills. Hope that will be forgiven.
>
> Alexandre Courbot (3):
>   Convert selectors of GENERIC_GPIO to GPIOLIB
>   Remove GENERIC_GPIO config option
>   Rename CONFIG_GPIOLIB to CONFIG_GPIO

The series:
Acked-by: Linus Walleij <linus.walleij at linaro.org>

Yours,
Linus Walleij


From robherring2 at gmail.com  Wed Apr  3 09:28:47 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Wed, 03 Apr 2013 08:28:47 -0500
Subject: [PATCH] clocksource: tegra: enable arch_timer
In-Reply-To: <1364988750-25058-1-git-send-email-josephl@nvidia.com>
References: <1364988750-25058-1-git-send-email-josephl@nvidia.com>
Message-ID: <515C2E8F.1030802@gmail.com>

On 04/03/2013 06:32 AM, Joseph Lo wrote:
> Architected timer is the local timer for Cortex-A15. Adding the support
> for Tegra.
> 
> Cc: John Stultz <john.stultz at linaro.org>
> Cc: Thomas Gleixner <tglx at linutronix.de>
> Signed-off-by: Joseph Lo <josephl at nvidia.com>

My patch series to add CLOCKSOURCE_OF_DECLARE support to arch timer and
sched_clock enhancements will make this unnecessary:

http://www.spinics.net/lists/arm-kernel/msg234597.html

Testing would be appreciated.

Rob

> ---
>  drivers/clocksource/tegra20_timer.c | 7 +++++--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/clocksource/tegra20_timer.c b/drivers/clocksource/tegra20_timer.c
> index ae877b0..e443f44 100644
> --- a/drivers/clocksource/tegra20_timer.c
> +++ b/drivers/clocksource/tegra20_timer.c
> @@ -30,6 +30,7 @@
>  #include <asm/mach/time.h>
>  #include <asm/smp_twd.h>
>  #include <asm/sched_clock.h>
> +#include <asm/arch_timer.h>
>  
>  #define RTC_SECONDS            0x08
>  #define RTC_SHADOW_SECONDS     0x0c
> @@ -200,8 +201,6 @@ static void __init tegra20_init_timer(struct device_node *np)
>  		WARN(1, "Unknown clock rate");
>  	}
>  
> -	setup_sched_clock(tegra_read_sched_clock, 32, 1000000);
> -
>  	if (clocksource_mmio_init(timer_reg_base + TIMERUS_CNTR_1US,
>  		"timer_us", 1000000, 300, 32, clocksource_mmio_readl_up)) {
>  		pr_err("Failed to register clocksource\n");
> @@ -218,6 +217,10 @@ static void __init tegra20_init_timer(struct device_node *np)
>  	tegra_clockevent.irq = tegra_timer_irq.irq;
>  	clockevents_config_and_register(&tegra_clockevent, 1000000,
>  					0x1, 0x1fffffff);
> +	if (arch_timer_of_register())
> +		setup_sched_clock(tegra_read_sched_clock, 32, 1000000);
> +	else
> +		arch_timer_sched_clock_init();
>  }
>  CLOCKSOURCE_OF_DECLARE(tegra20_timer, "nvidia,tegra20-timer", tegra20_init_timer);
>  
> 



From linus.walleij at linaro.org  Wed Apr  3 09:40:05 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Wed, 3 Apr 2013 15:40:05 +0200
Subject: [PATCHv5 0/7] arm: vt8500: Add support for pinctrl/gpio module
In-Reply-To: <1364970291-17721-1-git-send-email-linux@prisktech.co.nz>
References: <1364970291-17721-1-git-send-email-linux@prisktech.co.nz>
Message-ID: <CACRpkdZAtgpfA5rZ_C=eKDDOE9aDm=3k1QDava=EGL2BaoV+0g@mail.gmail.com>

On Wed, Apr 3, 2013 at 8:24 AM, Tony Prisk <linux at prisktech.co.nz> wrote:

> v5 changes:
> Changed as requested by Rob Herring:
> Added of_find_property_value_of_size() to drivers/of/base.c to remove some
> code that was being duplicated.
>
> Changed as requested by Stephen Warren:
> Redid the kfree(maps) code as devm_kzalloc would cause issues. We now kzalloc
> maps all at once, and configs as required. A call to wmt_pctl_dt_free_map() is
> used to kfree the allocated blocks if we fail early.

This v5 series:
Acked-by: Linus Walleij <linus.walleij at linaro.org>

I guess it will go in through the VT8500 tree eventually?

Maybe you could put Stephen's BCMring patch on top when sending
it in (also Acked-by) so we can avoid having that dangling.

Yours,
Linus Walleij


From balbi at ti.com  Wed Apr  3 09:42:18 2013
From: balbi at ti.com (Felipe Balbi)
Date: Wed, 3 Apr 2013 16:42:18 +0300
Subject: [PATCH v5 1/6] drivers: phy: add generic PHY framework
In-Reply-To: <1364993634-6378-2-git-send-email-kishon@ti.com>
References: <1364993634-6378-1-git-send-email-kishon@ti.com>
 <1364993634-6378-2-git-send-email-kishon@ti.com>
Message-ID: <20130403134102.GC14680@arwen.pp.htv.fi>

On Wed, Apr 03, 2013 at 06:23:49PM +0530, Kishon Vijay Abraham I wrote:
> The PHY framework provides a set of APIs for the PHY drivers to
> create/destroy a PHY and APIs for the PHY users to obtain a reference to the
> PHY with or without using phandle. To obtain a reference to the PHY without
> using phandle, the platform specfic intialization code (say from board file)
> should have already called phy_bind with the binding information. The binding
> information consists of phy's device name, phy user device name and an index.
> The index is used when the same phy user binds to mulitple phys.
> 
> PHY drivers should create the PHY by passing phy_descriptor that has
> describes the PHY (label, type etc..) and ops like init, exit, suspend, resume,
> power_on, power_off.
> 
> The documentation for the generic PHY framework is added in
> Documentation/phy.txt and the documentation for the sysfs entry is added
> in Documentation/ABI/testing/sysfs-class-phy and the documentation for
> dt binding is can be found at
> Documentation/devicetree/bindings/phy/phy-bindings.txt
> 
> Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
> ---
>  Documentation/ABI/testing/sysfs-class-phy          |   15 +
>  .../devicetree/bindings/phy/phy-bindings.txt       |   67 +++
>  Documentation/phy.txt                              |  113 ++++
>  MAINTAINERS                                        |    7 +
>  drivers/Kconfig                                    |    2 +
>  drivers/Makefile                                   |    2 +
>  drivers/phy/Kconfig                                |   13 +
>  drivers/phy/Makefile                               |    5 +
>  drivers/phy/phy-core.c                             |  616 ++++++++++++++++++++
>  include/linux/phy/phy.h                            |  228 ++++++++
>  10 files changed, 1068 insertions(+)
>  create mode 100644 Documentation/ABI/testing/sysfs-class-phy
>  create mode 100644 Documentation/devicetree/bindings/phy/phy-bindings.txt
>  create mode 100644 Documentation/phy.txt
>  create mode 100644 drivers/phy/Kconfig
>  create mode 100644 drivers/phy/Makefile
>  create mode 100644 drivers/phy/phy-core.c
>  create mode 100644 include/linux/phy/phy.h
> 
> diff --git a/Documentation/ABI/testing/sysfs-class-phy b/Documentation/ABI/testing/sysfs-class-phy
> new file mode 100644
> index 0000000..b735467
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-class-phy
> @@ -0,0 +1,15 @@
> +What:		/sys/class/phy/<phy>/label
> +Date:		Apr 2013
> +KernelVersion:	3.10
> +Contact:	Kishon Vijay Abraham I <kishon at ti.com>
> +Description:
> +		This is a read-only file for getting the label of the phy.
> +
> +What:		/sys/class/phy/<phy>/phy_bind
> +Date:		Apr 2013
> +KernelVersion:	3.10
> +Contact:	Kishon Vijay Abraham I <kishon at ti.com>
> +Description:
> +		This is a read-only file for reading the phy binding
> +		information. It contains the device name of the controller,
> +		the index and the device name of the PHY in that order.
> diff --git a/Documentation/devicetree/bindings/phy/phy-bindings.txt b/Documentation/devicetree/bindings/phy/phy-bindings.txt
> new file mode 100644
> index 0000000..e7b246a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/phy-bindings.txt
> @@ -0,0 +1,67 @@
> +This document explains only the dt data binding. For general information about
> +PHY subsystem refer Documentation/phy.txt
> +
> +PHY device node
> +===============
> +
> +Required Properties:
> +#phy-cells:	Number of cells in a PHY specifier;  The meaning of all those
> +		cells is defined by the binding for the phy node. The PHY
> +		provider can use the values in cells to find the appropriate
> +		PHY.
> +
> +For example:
> +
> +phys: phy {
> +    compatible = "xxx";
> +    reg = <...>;
> +    .
> +    .
> +    #phy-cells = <1>;
> +    .
> +    .
> +};
> +
> +That node describes an IP block that implements 2 different PHYs. In order to
> +differentiate between these 2 PHYs, an additonal specifier should be given
> +while trying to get a reference to it.
> +
> +PHY user node
> +=============
> +
> +Required Properties:
> +phys : the phandle for the PHY device (used by the PHY subsystem)
> +
> +Optional properties:
> +phy-names : the names of the PHY corresponding to the PHYs present in the
> +	    *phys* phandle
> +
> +Example 1:
> +usb1: usb_otg_ss at xxx {
> +    compatible = "xxx";
> +    reg = <xxx>;
> +    .
> +    .
> +    phys = <&usb2_phy>, <&usb3_phy>;
> +    phy-names = "usb2phy", "usb3phy";
> +    .
> +    .
> +};
> +
> +This node represents a controller that uses two PHYs one for usb2 and one for
> +usb3.
> +
> +Example 2:
> +usb2: usb_otg_ss at xxx {
> +    compatible = "xxx";
> +    reg = <xxx>;
> +    .
> +    .
> +    phys = <&phys 1>;
> +    .
> +    .
> +};
> +
> +This node represents a controller that uses one of the PHYs which is defined
> +previously. Note that the phy handle has an additional specifier "1" to
> +differentiate between the two PHYs.
> diff --git a/Documentation/phy.txt b/Documentation/phy.txt
> new file mode 100644
> index 0000000..7785ec0
> --- /dev/null
> +++ b/Documentation/phy.txt
> @@ -0,0 +1,113 @@
> +			    PHY SUBSYSTEM
> +		  Kishon Vijay Abraham I <kishon at ti.com>
> +
> +This document explains the Generic PHY Framework along with the APIs provided,
> +and how-to-use.
> +
> +1. Introduction
> +
> +*PHY* is the abbreviation for physical layer. It is used to connect a device
> +to the physical medium e.g., the USB controller has a PHY to provide functions
> +such as serialization, de-serialization, encoding, decoding and is responsible
> +for obtaining the required data transmission rate. Note that some USB
> +controller has PHY functionality embedded into it and others use an external
> +PHY. Other peripherals that uses a PHY include Wireless LAN, Ethernet,
> +SATA etc.
> +
> +The intention of creating this framework is to bring the phy drivers spread
> +all over the Linux kernel to drivers/phy to increase code re-use and to
> +increase code maintainability.
> +
> +This framework will be of use only to devices that uses external PHY (PHY
> +functionality is not embedded within the controller).
> +
> +2. Creating the PHY
> +
> +The PHY driver should create the PHY in order for other peripheral controllers
> +to make use of it. The PHY framework provides 2 APIs to create the PHY.
> +
> +struct phy *phy_create(struct device *dev, const char *label,
> +	struct device_node *of_node, int type, struct phy_ops *ops,
> +	void *priv);
> +struct phy *devm_phy_create(struct device *dev, const char *label,
> +	struct device_node *of_node, int type, struct phy_ops *ops,
> +	void *priv);
> +
> +The PHY drivers can use one of the above 2 APIs to create the PHY by passing
> +the device pointer, label, device node, type, phy ops and a driver data.
> +phy_ops is a set of function pointers for performing PHY operations such as
> +init, exit, suspend, resume, power_on and power_off.
> +
> +3. Binding the PHY to the controller
> +
> +The framework provides an API for binding the controller to the PHY in the
> +case of non dt boot.
> +
> +struct phy_bind *phy_bind(const char *dev_name, int index,
> +				const char *phy_dev_name);
> +
> +The API fills the phy_bind structure with the dev_name (device name of the
> +controller), index and phy_dev_name (device name of the PHY). This will
> +be used when the controller requests this phy. This API should be used by
> +platform specific initialization code (board file).
> +
> +In the case of dt boot, the binding information should be added in the dt
> +data of the controller.
> +
> +4. Getting a reference to the PHY
> +
> +Before the controller can make use of the PHY, it has to get a reference to
> +it. This framework provides 6 APIs to get a reference to the PHY.
> +
> +struct phy *phy_get(struct device *dev, int index);
> +struct phy *devm_phy_get(struct device *dev, int index);
> +struct phy *of_phy_get(struct device *dev, const char *phandle, int index);
> +struct phy *devm_of_phy_get(struct device *dev, const char *phandle, int index);
> +struct phy *of_phy_get_byname(struct device *dev, const char *string);
> +struct phy *devm_of_phy_get_byname(struct device *dev, const char *string);
> +
> +phy_get and devm_phy_get can be used to get the PHY in non-dt boot. This API
> +uses the binding information added using the phy_bind API to find and return
> +the appropriate PHY. The only difference between the two APIs is that
> +devm_phy_get associates the device with the PHY using devres on successful PHY
> +get. On driver detach, release function is invoked on the the devres data and
> +devres data is freed.
> +
> +of_phy_get and devm_of_phy_get can be used to get the PHY in dt boot. These
> +APIs take the phandle and index to get a reference to the PHY. The only
> +difference between the two APIs is that devm_of_phy_get associates the device
> +with the PHY using devres on successful phy get. On driver detach, release
> +function is invoked on the devres data and it is freed.
> +
> +of_phy_get_byname and devm_of_phy_get_byname can also be used to get the PHY
> +in dt boot. It is same as the above API except that the user has to pass the
> +phy name as filled in "phy-names" phandle in dt data and the framework will
> +find the index and get the PHY.
> +
> +5. Releasing a reference to the PHY
> +
> +When the controller no longer needs the PHY, it has to release the reference
> +to the PHY it has obtained using the APIs mentioned in the above section. The
> +PHY framework provides 2 APIS to release a reference to the PHY.
> +
> +void phy_put(struct phy *phy);
> +void devm_phy_put(struct device *dev, struct phy *phy);
> +
> +Both these APIs are used to release a reference to the PHY and devm_phy_put
> +destroys the devres associated with this PHY.
> +
> +6. Destroying the PHY
> +
> +When the driver that created the PHY is unloaded, it should destroy the PHY it
> +created using one of the following 2 APIs.
> +
> +void phy_destroy(struct phy *phy);
> +void devm_phy_destroy(struct device *dev, struct phy *phy);
> +
> +Both these APIs destroys the PHY and devm_phy_destroy destroys the devres
> +associated with this PHY.
> +
> +7. DeviceTree Binding
> +
> +The documentation for PHY dt binding can be found @
> +Documentation/devicetree/bindings/phy/phy-bindings.txt
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 72b0843..f2674e7 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -3474,6 +3474,13 @@ S:	Maintained
>  F:	include/asm-generic
>  F:	include/uapi/asm-generic
>  
> +GENERIC PHY FRAMEWORK
> +M:	Kishon Vijay Abraham I <kishon at ti.com>
> +L:	linux-kernel at vger.kernel.org
> +S:	Supported
> +F:	drivers/phy/
> +F:	include/linux/phy/
> +
>  GENERIC UIO DRIVER FOR PCI DEVICES
>  M:	"Michael S. Tsirkin" <mst at redhat.com>
>  L:	kvm at vger.kernel.org
> diff --git a/drivers/Kconfig b/drivers/Kconfig
> index 202fa6d..ad2c374a 100644
> --- a/drivers/Kconfig
> +++ b/drivers/Kconfig
> @@ -162,4 +162,6 @@ source "drivers/irqchip/Kconfig"
>  
>  source "drivers/ipack/Kconfig"
>  
> +source "drivers/phy/Kconfig"
> +
>  endmenu
> diff --git a/drivers/Makefile b/drivers/Makefile
> index dce39a9..9da8321 100644
> --- a/drivers/Makefile
> +++ b/drivers/Makefile
> @@ -45,6 +45,8 @@ obj-y				+= char/
>  # gpu/ comes after char for AGP vs DRM startup
>  obj-y				+= gpu/
>  
> +obj-y				+= phy/
> +
>  obj-$(CONFIG_CONNECTOR)		+= connector/
>  
>  # i810fb and intelfb depend on char/agp/
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> new file mode 100644
> index 0000000..5f85909
> --- /dev/null
> +++ b/drivers/phy/Kconfig
> @@ -0,0 +1,13 @@
> +#
> +# PHY
> +#
> +
> +menuconfig GENERIC_PHY
> +	tristate "PHY Subsystem"
> +	help
> +	  Generic PHY support.
> +
> +	  This framework is designed to provide a generic interface for PHY
> +	  devices present in the kernel. This layer will have the generic
> +	  API by which phy drivers can create PHY using the phy framework and
> +	  phy users can obtain reference to the PHY.
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> new file mode 100644
> index 0000000..9e9560f
> --- /dev/null
> +++ b/drivers/phy/Makefile
> @@ -0,0 +1,5 @@
> +#
> +# Makefile for the phy drivers.
> +#
> +
> +obj-$(CONFIG_GENERIC_PHY)	+= phy-core.o
> diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
> new file mode 100644
> index 0000000..1d753f2
> --- /dev/null
> +++ b/drivers/phy/phy-core.c
> @@ -0,0 +1,616 @@
> +/*
> + * phy-core.c  --  Generic Phy framework.
> + *
> + * Copyright (C) 2013 Texas Instruments
> + *
> + * Author: Kishon Vijay Abraham I <kishon at ti.com>
> + *
> + * This program is free software; you can redistribute  it and/or modify it
> + * under  the terms of  the GNU General  Public License as published by the
> + * Free Software Foundation;  either version 2 of the  License, or (at your
> + * option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/export.h>
> +#include <linux/module.h>
> +#include <linux/err.h>
> +#include <linux/device.h>
> +#include <linux/slab.h>
> +#include <linux/of.h>
> +#include <linux/phy/phy.h>
> +
> +static struct class *phy_class;
> +static DEFINE_MUTEX(phy_bind_mutex);
> +static LIST_HEAD(phy_bind_list);
> +static int phy_core_init(void);
> +
> +static void devm_phy_release(struct device *dev, void *res)
> +{
> +	struct phy *phy = *(struct phy **)res;
> +
> +	phy_put(phy);
> +}
> +
> +static void devm_phy_consume(struct device *dev, void *res)
> +{
> +	struct phy *phy = *(struct phy **)res;
> +
> +	phy_destroy(phy);
> +}
> +
> +static int devm_phy_match(struct device *dev, void *res, void *match_data)
> +{
> +	return res == match_data;
> +}
> +
> +static struct phy *phy_lookup(struct device *dev, int index)
> +{
> +	struct phy_bind *phy_bind = NULL;
> +
> +	list_for_each_entry(phy_bind, &phy_bind_list, list) {
> +		if (!(strcmp(phy_bind->dev_name, dev_name(dev)) &&
> +				phy_bind->index == index)) {
> +			if (phy_bind->phy)
> +				return phy_bind->phy;
> +			else
> +				return ERR_PTR(-EPROBE_DEFER);
> +		}
> +	}
> +
> +	return ERR_PTR(-ENODEV);
> +}
> +
> +static struct phy *of_phy_lookup(struct device_node *node)
> +{
> +	struct phy *phy;
> +	struct device *dev;
> +	struct class_dev_iter iter;
> +
> +	class_dev_iter_init(&iter, phy_class, NULL, NULL);
> +	while ((dev = class_dev_iter_next(&iter))) {
> +		phy = container_of(dev, struct phy, dev);

it would look a bit better if you provided a to_phy() macro. Specially
since this container_of() repeats multiple times in this file.

> +/**
> + * phy_put() - release the PHY
> + * @phy: the phy returned by phy_get()
> + *
> + * Releases a refcount the caller received from phy_get().
> + */
> +void phy_put(struct phy *phy)
> +{

I would rather:

if (WARN(IS_ERR(phy), "invalid parameter\n"))
	return;

module_put(phy->ops->owner);
put_device(&phy->dev);

that way we can catch users passing bogus pointers here. When PHY layer
is disabled, you want to make this is no-op with a static inline in a
header anyway.

> +struct phy *of_phy_xlate(struct phy *phy, struct of_phandle_args *args)
> +{
> +	return phy;
> +}
> +EXPORT_SYMBOL_GPL(of_phy_xlate);

so you get a PHY and just return it ? What gives ?? (maybe I skipped
some of the discussion...)

> +struct phy *of_phy_get(struct device *dev, int index)
> +{
> +	int ret;
> +	struct phy *phy = NULL;
> +	struct phy_bind *phy_map = NULL;
> +	struct of_phandle_args args;
> +	struct device_node *node;
> +
> +	if (!dev->of_node) {
> +		dev_dbg(dev, "device does not have a device node entry\n");
> +		return ERR_PTR(-EINVAL);
> +	}
> +
> +	ret = of_parse_phandle_with_args(dev->of_node, "phys", "#phy-cells",
> +		index, &args);
> +	if (ret) {
> +		dev_dbg(dev, "failed to get phy in %s node\n",
> +			dev->of_node->full_name);
> +		return ERR_PTR(-ENODEV);
> +	}
> +
> +	phy = of_phy_lookup(args.np);
> +	if (IS_ERR(phy) || !try_module_get(phy->ops->owner)) {
> +		phy = ERR_PTR(-EPROBE_DEFER);
> +		goto err0;
> +	}
> +
> +	phy = phy->ops->of_xlate(phy, &args);

alright, so of_xlate() is optional, am I right ? How about not
implementing the above and have a check for of_xlate() being a valid
pointer here ?

> +struct phy *phy_create(struct device *dev, const char *label,
> +	struct device_node *of_node, int type, struct phy_ops *ops,
> +	void *priv)
> +{
> +	int ret;
> +	struct phy *phy;
> +	struct phy_bind *phy_bind;
> +	const char *devname = NULL;
> +
> +	if (!dev) {
> +		dev_err(dev, "no device provided for PHY\n");

I'd call this a WARN() or am I too pedantic? :-p

> +	if (!ops || !ops->of_xlate || !priv) {
> +		dev_err(dev, "no PHY ops/PHY data provided\n");

likewise here.

> +		ret = -EINVAL;
> +		goto err0;
> +	}
> +
> +	if (!phy_class)
> +		phy_core_init();

why don't you setup the class on module_init ? Then this would be a
terrible error condition here :-)

> +static struct device_attribute phy_dev_attrs[] = {
> +	__ATTR(label, 0444, phy_name_show, NULL),
> +	__ATTR(phy_bind, 0444, phy_bind_show, NULL),

you could expose a human-readable 'type' string. BTW, how are you using
type ? USB2/USB3/etc ? Have you considered our OMAP5 SerDes pair which
are currently for USB3 and SATA (and could just as easily be used for
PCIe)

> +static void phy_release(struct device *dev)
> +{
> +	struct phy *phy;
> +
> +	phy = container_of(dev, struct phy, dev);
> +	dev_dbg(dev, "releasing '%s'\n", dev_name(dev));

how about dev_vdbg() ? I doubt anyone will be waiting for this
message... Just a thought

> +static int phy_core_init(void)
> +{
> +	if (phy_class)
> +		return 0;

Weird.. if you initialize the class here, why do you need to initialize
it during phy_create() ?

What's going on ? Also, module_init() will only be called once, why this
if (phy_class) check ?

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130403/f22c3489/attachment.sig>

From jhovold at gmail.com  Wed Apr  3 09:46:43 2013
From: jhovold at gmail.com (Johan Hovold)
Date: Wed, 3 Apr 2013 15:46:43 +0200
Subject: [RFC PATCH v2] rtc: rtc-at91rm9200: manage IMR depending on
 revision
In-Reply-To: <515C067B.6070503@atmel.com>
References: <1364908007-5150-1-git-send-email-nicolas.ferre@atmel.com>
 <1364920566-30040-1-git-send-email-nicolas.ferre@atmel.com>
 <20130403095150.GC27600@localhost> <515C067B.6070503@atmel.com>
Message-ID: <20130403134643.GD27600@localhost>

On Wed, Apr 03, 2013 at 12:37:47PM +0200, Nicolas Ferre wrote:
> On 04/03/2013 11:51 AM, Johan Hovold :
> > On Tue, Apr 02, 2013 at 06:36:06PM +0200, Nicolas Ferre wrote:

[...]

> >> I now use a different compatibility string to figure out what is the IP
> >> revision that has the "boggus IMR" error. I think this way to handle it
> >> is much simpler than the "config" structure one from Johan.
> > 
> > I wouldn't say it's much simpler. My solution is only more generic, but
> > could of course also be reduced to "set a flag if compatible matches
> > sam9x5".
> 
> The advantage is precisely to avoid the need for a "flag". Only function
> pointers that are changed in case of the compatible string matching.

Yeah, you could do it that way. The overhead is negligible in either
solution; mask updates are infrequent and the only difference when
retrieving the mask would be to first check the flag.

An advantage of using the config-struct would perhaps be that it is same
mechanism used in i2c-at91 and atmel_lcdfb (in the arm-soc tree) to deal
with SoC-quirks and is easily extended should need arise.

The diffs of both solutions are also of roughly the same size.

But I don't have any strong preference. You decide.

[...]

> >> diff --git a/Documentation/devicetree/bindings/rtc/atmel,at91rm9200-rtc.txt b/Documentation/devicetree/bindings/rtc/atmel,at91rm9200-rtc.txt
> >> index 2a3feab..9b87053 100644
> >> --- a/Documentation/devicetree/bindings/rtc/atmel,at91rm9200-rtc.txt
> >> +++ b/Documentation/devicetree/bindings/rtc/atmel,at91rm9200-rtc.txt
> >> @@ -1,7 +1,8 @@
> >>  Atmel AT91RM9200 Real Time Clock
> >>  
> >>  Required properties:
> >> -- compatible: should be: "atmel,at91rm9200-rtc"
> >> +- compatible: should be: "atmel,at91rm9200-rtc", "atmel,at91sam9x5-rtc" or
> >> +                         "atmel,at91sam9n12-rtc".
> > 
> > Also at91sam9g45 and at91sam9rl use this driver.
> 
> Yes, sure, I did not want to add every single user of the RTC...
> 
> > As seems to be the case
> > for other peripherals, I suggest we use "atmel,at91sam9x5-rtc" for
> > sam9x5 and "atmel,at91rm9200-rtc" for the other SoCs, that is, the least
> > (and first) common denominator.
> 
> ... I was just following the habit of naming the changes in peripheral
> revision by it first use in a SoC:
> at91rm9200-rtc: from rm9200 up to 9g45
> at91sam9x5-rtc: sam9x5 only (with IMR issue)
> at91sam9n12-rtc: fist SoC that corrects the IMR issue with a new IP
> revision, until now and sama5d3 SoC

Ah, ok.
 
> > Either way, there's not need to add at91sam9n12-rtc in this patch.
> > 
> >>  - reg: physical base address of the controller and length of memory mapped
> >>    region.
> >>  - interrupts: rtc alarm/event interrupt
> > 
> > I'll respond to this mail with a revert-patch, and an updated RFC-series
> > based on top of the DT-patch in Andrew's queue.

Thanks,
Johan


From balbi at ti.com  Wed Apr  3 09:48:27 2013
From: balbi at ti.com (Felipe Balbi)
Date: Wed, 3 Apr 2013 16:48:27 +0300
Subject: [PATCH v5 2/6] usb: phy: omap-usb2: use the new generic PHY
 framework
In-Reply-To: <1364993634-6378-3-git-send-email-kishon@ti.com>
References: <1364993634-6378-1-git-send-email-kishon@ti.com>
 <1364993634-6378-3-git-send-email-kishon@ti.com>
Message-ID: <20130403134827.GF14680@arwen.pp.htv.fi>

On Wed, Apr 03, 2013 at 06:23:50PM +0530, Kishon Vijay Abraham I wrote:
> Used the generic PHY framework API to create the PHY. omap_usb2_suspend
> is split into omap_usb_suspend and omap_usb_resume in order to align
> with the new framework.
> 
> However using the old USB PHY library cannot be completely removed
> because OTG is intertwined with PHY and moving to the new framework
> will break OTG. Once we have a separate OTG state machine, we
> can get rid of the USB PHY library.
> 
> Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
> ---
>  drivers/usb/phy/omap-usb2.c |   48 +++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 48 insertions(+)
> 
> diff --git a/drivers/usb/phy/omap-usb2.c b/drivers/usb/phy/omap-usb2.c
> index 844ab68..4e48db4 100644
> --- a/drivers/usb/phy/omap-usb2.c
> +++ b/drivers/usb/phy/omap-usb2.c
> @@ -28,6 +28,7 @@
>  #include <linux/pm_runtime.h>
>  #include <linux/delay.h>
>  #include <linux/usb/omap_control_usb.h>
> +#include <linux/phy/phy.h>
>  
>  /**
>   * omap_usb2_set_comparator - links the comparator present in the sytem with
> @@ -119,9 +120,49 @@ static int omap_usb2_suspend(struct usb_phy *x, int suspend)
>  	return 0;
>  }
>  
> +static int omap_usb_suspend(struct phy *x)
> +{
> +	struct omap_usb *phy = dev_get_drvdata(&x->dev);
> +
> +	if (!phy->is_suspended) {
> +		omap_control_usb_phy_power(phy->control_dev, 0);
> +		pm_runtime_put_sync(phy->dev);
> +		phy->is_suspended = 1;
> +	}
> +
> +	return 0;
> +}
> +
> +static int omap_usb_resume(struct phy *x)
> +{
> +	u32 ret;
> +	struct omap_usb *phy = dev_get_drvdata(&x->dev);
> +
> +	if (phy->is_suspended) {
> +		ret = pm_runtime_get_sync(phy->dev);
> +		if (ret < 0) {
> +			dev_err(phy->dev, "get_sync failed with err %d\n",
> +									ret);
> +			return ret;
> +		}
> +		omap_control_usb_phy_power(phy->control_dev, 1);
> +		phy->is_suspended = 0;
> +	}
> +
> +	return 0;
> +}
> +
> +static struct phy_ops ops = {

const ? Maybe provide a:

#define DEFINE_PHY_OPS(name)	\
const struct phy_ops #name_phy_ops = {

macro ? This will force people to add the const keyword :-)

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130403/c783de21/attachment.sig>

From nicolas.pitre at linaro.org  Wed Apr  3 10:00:02 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Wed, 3 Apr 2013 10:00:02 -0400 (EDT)
Subject: [PATCH v5 3/3] xen/arm: introduce xen_early_init, use PSCI on xen
In-Reply-To: <alpine.DEB.2.02.1304031217310.5078@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1304021700380.5078@kaball.uk.xensource.com>
 <1364919374-7836-3-git-send-email-stefano.stabellini@eu.citrix.com>
 <alpine.LFD.2.03.1304021325230.1171@syhkavp.arg>
 <alpine.DEB.2.02.1304031217310.5078@kaball.uk.xensource.com>
Message-ID: <alpine.LFD.2.03.1304030955180.1171@syhkavp.arg>

On Wed, 3 Apr 2013, Stefano Stabellini wrote:

> On Tue, 2 Apr 2013, Nicolas Pitre wrote:
> > On Tue, 2 Apr 2013, Stefano Stabellini wrote:
> > 
> > > @@ -176,27 +178,30 @@ static int __init xen_secondary_init(unsigned int cpu)
> > >  	return 0;
> > >  }
> > >  
> > > +static void __init xen_smp_init(void)
> > > +{
> > > +	if (psci_smp_available())
> > > +		smp_set_ops(&psci_smp_ops);
> > > +}
> > > +
> > 
> > I still don't understand why you need to do this.  Why can't you just 
> > rely on the next priority which is to set PSCI ops by default if 
> > available?  Using this hook for Xen doesn't look justified. As it is, 
> > you break MCPM.
> > 
> > As I explained to you, MCPM will end up using PSCI as well when 
> > available, which I think should be sufficient for your concern.
> 
> The smp_init hook is not limited to MCPM or the versatile express
> platform. It's a generic hook that can be used by any platform and can
> override the platform smp_ops or the psci_smp_ops depending on platform
> specific configurations.
> 
> Configurations that I am pretty sure won't be available on Xen anyway,
> while I am certain that using psci_smp_ops would work.
> 
> It seems to me that relying on the fact that only versatile express and
> only MCPM use smp_init, even though it might work today, it's very
> fragile and could break tomorrow without any of us noticing.

I claim: this breaks MCPM today.

You claim: the alternative _could_ break with Xen tomorrow.

Could we please wait until there is an actual problem with Xen before 
being overly defensive in the code?


Nicolas


From prakash.pm at ti.com  Wed Apr  3 10:09:05 2013
From: prakash.pm at ti.com (Manjunathappa, Prakash)
Date: Wed, 3 Apr 2013 19:39:05 +0530
Subject: [PATCH v5 0/5] Patch enables support for m25p64 SPI flash support on
 da850-EVM.
Message-ID: <1364998150-5980-1-git-send-email-prakash.pm@ti.com>

Testing information:
da850-evm comes with partitions specified in DT blob.
Able to mount/umount and create/delete files on filesystem partition.

Applies on top of linux_davinci/master tree:
git://gitorious.org/linux-davinci/linux-davinci.git

Since v4:
Separate out chip_select pinmuxing so as to allow boards choose
accordingly.

Since v3:
Minor nit, fix tabs and commit message of 2/5.

Since v2:
Fix compatible property DT naming convention.

Since v1:
Look for m25p64 instead of m25p80 flash chip and correct partition information.
Dropped below accepted patch:
"spi/davinci: fix module build error"
Considered below missed out patch:
spi/davinci: add DT binding documentation

Manjunathappa, Prakash (4):
  spi/davinci: no wildcards in DT compatible property
  ARM: davinci: da850: add SPI1 DT node
  ARM: davinci: da850: override SPI DT node device name
  ARM: davinci: da850-evm: add SPI flash support

Murali Karicheri (1):
  spi/davinci: add DT binding documentation

 .../devicetree/bindings/spi/spi-davinci.txt        |   51 ++++++++++++++++++++
 arch/arm/boot/dts/da850-evm.dts                    |   40 +++++++++++++++
 arch/arm/boot/dts/da850.dtsi                       |   22 ++++++++
 arch/arm/mach-davinci/da8xx-dt.c                   |    1 +
 drivers/spi/spi-davinci.c                          |    4 +-
 5 files changed, 116 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/spi/spi-davinci.txt

-- 
1.7.4.1



From prakash.pm at ti.com  Wed Apr  3 10:09:06 2013
From: prakash.pm at ti.com (Manjunathappa, Prakash)
Date: Wed, 3 Apr 2013 19:39:06 +0530
Subject: [PATCH v5 1/5] spi/davinci: no wildcards in DT compatible property
In-Reply-To: <1364998150-5980-1-git-send-email-prakash.pm@ti.com>
References: <1364998150-5980-1-git-send-email-prakash.pm@ti.com>
Message-ID: <1364998150-5980-2-git-send-email-prakash.pm@ti.com>

Follow DT naming convention for compatible property of the blob.
Use first chip name that introduced the specific version of the
device.

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

diff --git a/drivers/spi/spi-davinci.c b/drivers/spi/spi-davinci.c
index 8234d22..2e8f24a 100644
--- a/drivers/spi/spi-davinci.c
+++ b/drivers/spi/spi-davinci.c
@@ -776,10 +776,10 @@ rx_dma_failed:
 #if defined(CONFIG_OF)
 static const struct of_device_id davinci_spi_of_match[] = {
 	{
-		.compatible = "ti,dm644x-spi",
+		.compatible = "ti,dm6441-spi",
 	},
 	{
-		.compatible = "ti,da8xx-spi",
+		.compatible = "ti,da830-spi",
 		.data = (void *)SPI_VERSION_2,
 	},
 	{ },
-- 
1.7.4.1



From prakash.pm at ti.com  Wed Apr  3 10:09:07 2013
From: prakash.pm at ti.com (Manjunathappa, Prakash)
Date: Wed, 3 Apr 2013 19:39:07 +0530
Subject: [PATCH v5 2/5] spi/davinci: add DT binding documentation
In-Reply-To: <1364998150-5980-1-git-send-email-prakash.pm@ti.com>
References: <1364998150-5980-1-git-send-email-prakash.pm@ti.com>
Message-ID: <1364998150-5980-3-git-send-email-prakash.pm@ti.com>

From: Murali Karicheri <m-karicheri2 at ti.com>

Add binding documentation for spi-davinci module.

[prakash.pm at ti.com: Follow DT naming convention for compatible property]
Signed-off-by: Murali Karicheri <m-karicheri2 at ti.com>
Reviewed-by: Grant Likely <grant.likely at secretlab.ca>
Reviewed-by: Sekhar Nori <nsekhar at ti.com>
Signed-off-by: Manjunathappa, Prakash <prakash.pm at ti.com>
---
Since v3:
Changed the commit message and fixed alignment issues.

 .../devicetree/bindings/spi/spi-davinci.txt        |   51 ++++++++++++++++++++
 1 files changed, 51 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/spi/spi-davinci.txt

diff --git a/Documentation/devicetree/bindings/spi/spi-davinci.txt b/Documentation/devicetree/bindings/spi/spi-davinci.txt
new file mode 100644
index 0000000..6d0ac8d
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/spi-davinci.txt
@@ -0,0 +1,51 @@
+Davinci SPI controller device bindings
+
+Required properties:
+- #address-cells: number of cells required to define a chip select
+	address on the SPI bus. Should be set to 1.
+- #size-cells: should be zero.
+- compatible:
+	- "ti,dm6441-spi" for SPI used similar to that on DM644x SoC family
+	- "ti,da830-spi" for SPI used similar to that on DA8xx SoC family
+- reg: Offset and length of SPI controller register space
+- num-cs: Number of chip selects
+- ti,davinci-spi-intr-line: interrupt line used to connect the SPI
+	IP to the interrupt controller within the SoC. Possible values
+	are 0 and 1. Manual says one of the two possible interrupt
+	lines can be tied to the interrupt controller. Set this
+	based on a specifc SoC configuration.
+- interrupts: interrupt number mapped to CPU.
+- clocks: spi clk phandle
+
+Example of a NOR flash slave device (n25q032) connected to DaVinci
+SPI controller device over the SPI bus.
+
+spi0:spi at 20BF0000 {
+	#address-cells			= <1>;
+	#size-cells			= <0>;
+	compatible			= "ti,dm6446-spi";
+	reg				= <0x20BF0000 0x1000>;
+	num-cs				= <4>;
+	ti,davinci-spi-intr-line	= <0>;
+	interrupts			= <338>;
+	clocks				= <&clkspi>;
+
+	flash: n25q032 at 0 {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		compatible = "st,m25p32";
+		spi-max-frequency = <25000000>;
+		reg = <0>;
+
+		partition at 0 {
+			label = "u-boot-spl";
+			reg = <0x0 0x80000>;
+			read-only;
+		};
+
+		partition at 1 {
+			label = "test";
+			reg = <0x80000 0x380000>;
+		};
+	};
+};
-- 
1.7.4.1



From prakash.pm at ti.com  Wed Apr  3 10:09:08 2013
From: prakash.pm at ti.com (Manjunathappa, Prakash)
Date: Wed, 3 Apr 2013 19:39:08 +0530
Subject: [PATCH v5 3/5] ARM: davinci: da850: add SPI1 DT node
In-Reply-To: <1364998150-5980-1-git-send-email-prakash.pm@ti.com>
References: <1364998150-5980-1-git-send-email-prakash.pm@ti.com>
Message-ID: <1364998150-5980-4-git-send-email-prakash.pm@ti.com>

Patch adds SPI1 DT node along with pinmux data.

Signed-off-by: Manjunathappa, Prakash <prakash.pm at ti.com>
---
Since v4:
Separate out chip_select pinmuxing so as to allow boards choose
what to configure. Dropped unused CS1 and ENA pinmuxing.

 arch/arm/boot/dts/da850.dtsi |   22 ++++++++++++++++++++++
 1 files changed, 22 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 3ec1bda..1d445cd 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -62,6 +62,18 @@
 					0x10 0x00002200 0x0000ff00
 				>;
 			};
+			spi1_pins: pinmux_spi_pins {
+				pinctrl-single,bits = <
+					/* SIMO, SOMI, CLK */
+					0x14 0x00110100 0x00ff0f00
+				>;
+			};
+			spi1_cs0_pin: pinmux_spi1_cs0 {
+				pinctrl-single,bits = <
+					/* CS0 */
+					0x14 0x00000010 0x000000f0
+				>;
+			};
 		};
 		serial0: serial at 1c42000 {
 			compatible = "ns16550a";
@@ -107,6 +119,16 @@
 			reg = <0x21000 0x1000>;
 			status = "disabled";
 		};
+		spi1: spi at 1f0e000 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			compatible = "ti,da830-spi";
+			reg = <0x30e000 0x1000>;
+			num-cs = <4>;
+			ti,davinci-spi-intr-line = <1>;
+			interrupts = <56>;
+			status = "disabled";
+		};
 	};
 	nand_cs3 at 62000000 {
 		compatible = "ti,davinci-nand";
-- 
1.7.4.1



From prakash.pm at ti.com  Wed Apr  3 10:09:09 2013
From: prakash.pm at ti.com (Manjunathappa, Prakash)
Date: Wed, 3 Apr 2013 19:39:09 +0530
Subject: [PATCH v5 4/5] ARM: davinci: da850: override SPI DT node device name
In-Reply-To: <1364998150-5980-1-git-send-email-prakash.pm@ti.com>
References: <1364998150-5980-1-git-send-email-prakash.pm@ti.com>
Message-ID: <1364998150-5980-5-git-send-email-prakash.pm@ti.com>

Populate OF_DEV_AUXDATA with desired device name expected by spi-davinci
driver. Without this clk_get of spi-davinci DT driver fails.

Signed-off-by: Manjunathappa, Prakash <prakash.pm at ti.com>
---
 arch/arm/mach-davinci/da8xx-dt.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-davinci/da8xx-dt.c b/arch/arm/mach-davinci/da8xx-dt.c
index 6b7a0a2..24146de 100644
--- a/arch/arm/mach-davinci/da8xx-dt.c
+++ b/arch/arm/mach-davinci/da8xx-dt.c
@@ -40,6 +40,7 @@ static void __init da8xx_init_irq(void)
 struct of_dev_auxdata da850_auxdata_lookup[] __initdata = {
 	OF_DEV_AUXDATA("ti,davinci-i2c", 0x01c22000, "i2c_davinci.1", NULL),
 	OF_DEV_AUXDATA("ti,davinci-wdt", 0x01c21000, "watchdog", NULL),
+	OF_DEV_AUXDATA("ti,da830-spi", 0x01f0e000, "spi_davinci.1", NULL),
 	{}
 };
 
-- 
1.7.4.1



From prakash.pm at ti.com  Wed Apr  3 10:09:10 2013
From: prakash.pm at ti.com (Manjunathappa, Prakash)
Date: Wed, 3 Apr 2013 19:39:10 +0530
Subject: [PATCH v5 5/5] ARM: davinci: da850-evm: add SPI flash support
In-Reply-To: <1364998150-5980-1-git-send-email-prakash.pm@ti.com>
References: <1364998150-5980-1-git-send-email-prakash.pm@ti.com>
Message-ID: <1364998150-5980-6-git-send-email-prakash.pm@ti.com>

Enable m25p64 SPI flash support on da850-EVM. Also
add partition information of SPI flash.

Signed-off-by: Manjunathappa, Prakash <prakash.pm at ti.com>
---
Since v2:
Fixed partition sizes.

Since v1:
Look for m25p64 instead of m25p80.
Corrected the filesystem partition information.

 arch/arm/boot/dts/da850-evm.dts |   40 +++++++++++++++++++++++++++++++++++++++
 1 files changed, 40 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
index c359872..8fbde9a 100644
--- a/arch/arm/boot/dts/da850-evm.dts
+++ b/arch/arm/boot/dts/da850-evm.dts
@@ -41,6 +41,46 @@
 		wdt: wdt at 1c21000 {
 			status = "okay";
 		};
+		spi1: spi at 1f0e000 {
+			status = "okay";
+			pinctrl-names = "default";
+			pinctrl-0 = <&spi1_pins &spi1_cs0_pin>;
+			flash: m25p80 at 0 {
+				#address-cells = <1>;
+				#size-cells = <1>;
+				compatible = "m25p64";
+				spi-max-frequency = <30000000>;
+				reg = <0>;
+				partition at 0 {
+					label = "U-Boot-SPL";
+					reg = <0x00000000 0x00010000>;
+					read-only;
+				};
+				partition at 1 {
+					label = "U-Boot";
+					reg = <0x00010000 0x00080000>;
+					read-only;
+				};
+				partition at 2 {
+					label = "U-Boot-Env";
+					reg = <0x00090000 0x00010000>;
+					read-only;
+				};
+				partition at 3 {
+					label = "Kernel";
+					reg = <0x000a0000 0x00280000>;
+				};
+				partition at 4 {
+					label = "Filesystem";
+					reg = <0x00320000 0x00400000>;
+				};
+				partition at 5 {
+					label = "MAC-Address";
+					reg = <0x007f0000 0x00010000>;
+					read-only;
+				};
+			};
+		};
 	};
 	nand_cs3 at 62000000 {
 		status = "okay";
-- 
1.7.4.1



From kishon at ti.com  Wed Apr  3 10:18:42 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Wed, 3 Apr 2013 19:48:42 +0530
Subject: [PATCH v5 1/6] drivers: phy: add generic PHY framework
In-Reply-To: <20130403134102.GC14680@arwen.pp.htv.fi>
References: <1364993634-6378-1-git-send-email-kishon@ti.com>
 <1364993634-6378-2-git-send-email-kishon@ti.com>
 <20130403134102.GC14680@arwen.pp.htv.fi>
Message-ID: <515C3A42.4020404@ti.com>

Hi,

On Wednesday 03 April 2013 07:12 PM, Felipe Balbi wrote:
> On Wed, Apr 03, 2013 at 06:23:49PM +0530, Kishon Vijay Abraham I wrote:
>> The PHY framework provides a set of APIs for the PHY drivers to
>> create/destroy a PHY and APIs for the PHY users to obtain a reference to the
>> PHY with or without using phandle. To obtain a reference to the PHY without
>> using phandle, the platform specfic intialization code (say from board file)
>> should have already called phy_bind with the binding information. The binding
>> information consists of phy's device name, phy user device name and an index.
>> The index is used when the same phy user binds to mulitple phys.
>>
>> PHY drivers should create the PHY by passing phy_descriptor that has
>> describes the PHY (label, type etc..) and ops like init, exit, suspend, resume,
>> power_on, power_off.
>>
>> The documentation for the generic PHY framework is added in
>> Documentation/phy.txt and the documentation for the sysfs entry is added
>> in Documentation/ABI/testing/sysfs-class-phy and the documentation for
>> dt binding is can be found at
>> Documentation/devicetree/bindings/phy/phy-bindings.txt
>>
>> Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
>> ---
>>   Documentation/ABI/testing/sysfs-class-phy          |   15 +
>>   .../devicetree/bindings/phy/phy-bindings.txt       |   67 +++
>>   Documentation/phy.txt                              |  113 ++++
>>   MAINTAINERS                                        |    7 +
>>   drivers/Kconfig                                    |    2 +
>>   drivers/Makefile                                   |    2 +
>>   drivers/phy/Kconfig                                |   13 +
>>   drivers/phy/Makefile                               |    5 +
>>   drivers/phy/phy-core.c                             |  616 ++++++++++++++++++++
>>   include/linux/phy/phy.h                            |  228 ++++++++
>>   10 files changed, 1068 insertions(+)
>>   create mode 100644 Documentation/ABI/testing/sysfs-class-phy
>>   create mode 100644 Documentation/devicetree/bindings/phy/phy-bindings.txt
>>   create mode 100644 Documentation/phy.txt
>>   create mode 100644 drivers/phy/Kconfig
>>   create mode 100644 drivers/phy/Makefile
>>   create mode 100644 drivers/phy/phy-core.c
>>   create mode 100644 include/linux/phy/phy.h
>>
>> diff --git a/Documentation/ABI/testing/sysfs-class-phy b/Documentation/ABI/testing/sysfs-class-phy
>> new file mode 100644
>> index 0000000..b735467
>> --- /dev/null
>> +++ b/Documentation/ABI/testing/sysfs-class-phy
>> @@ -0,0 +1,15 @@
>> +What:		/sys/class/phy/<phy>/label
>> +Date:		Apr 2013
>> +KernelVersion:	3.10
>> +Contact:	Kishon Vijay Abraham I <kishon at ti.com>
>> +Description:
>> +		This is a read-only file for getting the label of the phy.
>> +
>> +What:		/sys/class/phy/<phy>/phy_bind
>> +Date:		Apr 2013
>> +KernelVersion:	3.10
>> +Contact:	Kishon Vijay Abraham I <kishon at ti.com>
>> +Description:
>> +		This is a read-only file for reading the phy binding
>> +		information. It contains the device name of the controller,
>> +		the index and the device name of the PHY in that order.
>> diff --git a/Documentation/devicetree/bindings/phy/phy-bindings.txt b/Documentation/devicetree/bindings/phy/phy-bindings.txt
>> new file mode 100644
>> index 0000000..e7b246a
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/phy/phy-bindings.txt
>> @@ -0,0 +1,67 @@
>> +This document explains only the dt data binding. For general information about
>> +PHY subsystem refer Documentation/phy.txt
>> +
>> +PHY device node
>> +===============
>> +
>> +Required Properties:
>> +#phy-cells:	Number of cells in a PHY specifier;  The meaning of all those
>> +		cells is defined by the binding for the phy node. The PHY
>> +		provider can use the values in cells to find the appropriate
>> +		PHY.
>> +
>> +For example:
>> +
>> +phys: phy {
>> +    compatible = "xxx";
>> +    reg = <...>;
>> +    .
>> +    .
>> +    #phy-cells = <1>;
>> +    .
>> +    .
>> +};
>> +
>> +That node describes an IP block that implements 2 different PHYs. In order to
>> +differentiate between these 2 PHYs, an additonal specifier should be given
>> +while trying to get a reference to it.
>> +
>> +PHY user node
>> +=============
>> +
>> +Required Properties:
>> +phys : the phandle for the PHY device (used by the PHY subsystem)
>> +
>> +Optional properties:
>> +phy-names : the names of the PHY corresponding to the PHYs present in the
>> +	    *phys* phandle
>> +
>> +Example 1:
>> +usb1: usb_otg_ss at xxx {
>> +    compatible = "xxx";
>> +    reg = <xxx>;
>> +    .
>> +    .
>> +    phys = <&usb2_phy>, <&usb3_phy>;
>> +    phy-names = "usb2phy", "usb3phy";
>> +    .
>> +    .
>> +};
>> +
>> +This node represents a controller that uses two PHYs one for usb2 and one for
>> +usb3.
>> +
>> +Example 2:
>> +usb2: usb_otg_ss at xxx {
>> +    compatible = "xxx";
>> +    reg = <xxx>;
>> +    .
>> +    .
>> +    phys = <&phys 1>;
>> +    .
>> +    .
>> +};
>> +
>> +This node represents a controller that uses one of the PHYs which is defined
>> +previously. Note that the phy handle has an additional specifier "1" to
>> +differentiate between the two PHYs.
>> diff --git a/Documentation/phy.txt b/Documentation/phy.txt
>> new file mode 100644
>> index 0000000..7785ec0
>> --- /dev/null
>> +++ b/Documentation/phy.txt
>> @@ -0,0 +1,113 @@
>> +			    PHY SUBSYSTEM
>> +		  Kishon Vijay Abraham I <kishon at ti.com>
>> +
>> +This document explains the Generic PHY Framework along with the APIs provided,
>> +and how-to-use.
>> +
>> +1. Introduction
>> +
>> +*PHY* is the abbreviation for physical layer. It is used to connect a device
>> +to the physical medium e.g., the USB controller has a PHY to provide functions
>> +such as serialization, de-serialization, encoding, decoding and is responsible
>> +for obtaining the required data transmission rate. Note that some USB
>> +controller has PHY functionality embedded into it and others use an external
>> +PHY. Other peripherals that uses a PHY include Wireless LAN, Ethernet,
>> +SATA etc.
>> +
>> +The intention of creating this framework is to bring the phy drivers spread
>> +all over the Linux kernel to drivers/phy to increase code re-use and to
>> +increase code maintainability.
>> +
>> +This framework will be of use only to devices that uses external PHY (PHY
>> +functionality is not embedded within the controller).
>> +
>> +2. Creating the PHY
>> +
>> +The PHY driver should create the PHY in order for other peripheral controllers
>> +to make use of it. The PHY framework provides 2 APIs to create the PHY.
>> +
>> +struct phy *phy_create(struct device *dev, const char *label,
>> +	struct device_node *of_node, int type, struct phy_ops *ops,
>> +	void *priv);
>> +struct phy *devm_phy_create(struct device *dev, const char *label,
>> +	struct device_node *of_node, int type, struct phy_ops *ops,
>> +	void *priv);
>> +
>> +The PHY drivers can use one of the above 2 APIs to create the PHY by passing
>> +the device pointer, label, device node, type, phy ops and a driver data.
>> +phy_ops is a set of function pointers for performing PHY operations such as
>> +init, exit, suspend, resume, power_on and power_off.
>> +
>> +3. Binding the PHY to the controller
>> +
>> +The framework provides an API for binding the controller to the PHY in the
>> +case of non dt boot.
>> +
>> +struct phy_bind *phy_bind(const char *dev_name, int index,
>> +				const char *phy_dev_name);
>> +
>> +The API fills the phy_bind structure with the dev_name (device name of the
>> +controller), index and phy_dev_name (device name of the PHY). This will
>> +be used when the controller requests this phy. This API should be used by
>> +platform specific initialization code (board file).
>> +
>> +In the case of dt boot, the binding information should be added in the dt
>> +data of the controller.
>> +
>> +4. Getting a reference to the PHY
>> +
>> +Before the controller can make use of the PHY, it has to get a reference to
>> +it. This framework provides 6 APIs to get a reference to the PHY.
>> +
>> +struct phy *phy_get(struct device *dev, int index);
>> +struct phy *devm_phy_get(struct device *dev, int index);
>> +struct phy *of_phy_get(struct device *dev, const char *phandle, int index);
>> +struct phy *devm_of_phy_get(struct device *dev, const char *phandle, int index);
>> +struct phy *of_phy_get_byname(struct device *dev, const char *string);
>> +struct phy *devm_of_phy_get_byname(struct device *dev, const char *string);
>> +
>> +phy_get and devm_phy_get can be used to get the PHY in non-dt boot. This API
>> +uses the binding information added using the phy_bind API to find and return
>> +the appropriate PHY. The only difference between the two APIs is that
>> +devm_phy_get associates the device with the PHY using devres on successful PHY
>> +get. On driver detach, release function is invoked on the the devres data and
>> +devres data is freed.
>> +
>> +of_phy_get and devm_of_phy_get can be used to get the PHY in dt boot. These
>> +APIs take the phandle and index to get a reference to the PHY. The only
>> +difference between the two APIs is that devm_of_phy_get associates the device
>> +with the PHY using devres on successful phy get. On driver detach, release
>> +function is invoked on the devres data and it is freed.
>> +
>> +of_phy_get_byname and devm_of_phy_get_byname can also be used to get the PHY
>> +in dt boot. It is same as the above API except that the user has to pass the
>> +phy name as filled in "phy-names" phandle in dt data and the framework will
>> +find the index and get the PHY.
>> +
>> +5. Releasing a reference to the PHY
>> +
>> +When the controller no longer needs the PHY, it has to release the reference
>> +to the PHY it has obtained using the APIs mentioned in the above section. The
>> +PHY framework provides 2 APIS to release a reference to the PHY.
>> +
>> +void phy_put(struct phy *phy);
>> +void devm_phy_put(struct device *dev, struct phy *phy);
>> +
>> +Both these APIs are used to release a reference to the PHY and devm_phy_put
>> +destroys the devres associated with this PHY.
>> +
>> +6. Destroying the PHY
>> +
>> +When the driver that created the PHY is unloaded, it should destroy the PHY it
>> +created using one of the following 2 APIs.
>> +
>> +void phy_destroy(struct phy *phy);
>> +void devm_phy_destroy(struct device *dev, struct phy *phy);
>> +
>> +Both these APIs destroys the PHY and devm_phy_destroy destroys the devres
>> +associated with this PHY.
>> +
>> +7. DeviceTree Binding
>> +
>> +The documentation for PHY dt binding can be found @
>> +Documentation/devicetree/bindings/phy/phy-bindings.txt
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 72b0843..f2674e7 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -3474,6 +3474,13 @@ S:	Maintained
>>   F:	include/asm-generic
>>   F:	include/uapi/asm-generic
>>
>> +GENERIC PHY FRAMEWORK
>> +M:	Kishon Vijay Abraham I <kishon at ti.com>
>> +L:	linux-kernel at vger.kernel.org
>> +S:	Supported
>> +F:	drivers/phy/
>> +F:	include/linux/phy/
>> +
>>   GENERIC UIO DRIVER FOR PCI DEVICES
>>   M:	"Michael S. Tsirkin" <mst at redhat.com>
>>   L:	kvm at vger.kernel.org
>> diff --git a/drivers/Kconfig b/drivers/Kconfig
>> index 202fa6d..ad2c374a 100644
>> --- a/drivers/Kconfig
>> +++ b/drivers/Kconfig
>> @@ -162,4 +162,6 @@ source "drivers/irqchip/Kconfig"
>>
>>   source "drivers/ipack/Kconfig"
>>
>> +source "drivers/phy/Kconfig"
>> +
>>   endmenu
>> diff --git a/drivers/Makefile b/drivers/Makefile
>> index dce39a9..9da8321 100644
>> --- a/drivers/Makefile
>> +++ b/drivers/Makefile
>> @@ -45,6 +45,8 @@ obj-y				+= char/
>>   # gpu/ comes after char for AGP vs DRM startup
>>   obj-y				+= gpu/
>>
>> +obj-y				+= phy/
>> +
>>   obj-$(CONFIG_CONNECTOR)		+= connector/
>>
>>   # i810fb and intelfb depend on char/agp/
>> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
>> new file mode 100644
>> index 0000000..5f85909
>> --- /dev/null
>> +++ b/drivers/phy/Kconfig
>> @@ -0,0 +1,13 @@
>> +#
>> +# PHY
>> +#
>> +
>> +menuconfig GENERIC_PHY
>> +	tristate "PHY Subsystem"
>> +	help
>> +	  Generic PHY support.
>> +
>> +	  This framework is designed to provide a generic interface for PHY
>> +	  devices present in the kernel. This layer will have the generic
>> +	  API by which phy drivers can create PHY using the phy framework and
>> +	  phy users can obtain reference to the PHY.
>> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
>> new file mode 100644
>> index 0000000..9e9560f
>> --- /dev/null
>> +++ b/drivers/phy/Makefile
>> @@ -0,0 +1,5 @@
>> +#
>> +# Makefile for the phy drivers.
>> +#
>> +
>> +obj-$(CONFIG_GENERIC_PHY)	+= phy-core.o
>> diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
>> new file mode 100644
>> index 0000000..1d753f2
>> --- /dev/null
>> +++ b/drivers/phy/phy-core.c
>> @@ -0,0 +1,616 @@
>> +/*
>> + * phy-core.c  --  Generic Phy framework.
>> + *
>> + * Copyright (C) 2013 Texas Instruments
>> + *
>> + * Author: Kishon Vijay Abraham I <kishon at ti.com>
>> + *
>> + * This program is free software; you can redistribute  it and/or modify it
>> + * under  the terms of  the GNU General  Public License as published by the
>> + * Free Software Foundation;  either version 2 of the  License, or (at your
>> + * option) any later version.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
>> + */
>> +
>> +#include <linux/kernel.h>
>> +#include <linux/export.h>
>> +#include <linux/module.h>
>> +#include <linux/err.h>
>> +#include <linux/device.h>
>> +#include <linux/slab.h>
>> +#include <linux/of.h>
>> +#include <linux/phy/phy.h>
>> +
>> +static struct class *phy_class;
>> +static DEFINE_MUTEX(phy_bind_mutex);
>> +static LIST_HEAD(phy_bind_list);
>> +static int phy_core_init(void);
>> +
>> +static void devm_phy_release(struct device *dev, void *res)
>> +{
>> +	struct phy *phy = *(struct phy **)res;
>> +
>> +	phy_put(phy);
>> +}
>> +
>> +static void devm_phy_consume(struct device *dev, void *res)
>> +{
>> +	struct phy *phy = *(struct phy **)res;
>> +
>> +	phy_destroy(phy);
>> +}
>> +
>> +static int devm_phy_match(struct device *dev, void *res, void *match_data)
>> +{
>> +	return res == match_data;
>> +}
>> +
>> +static struct phy *phy_lookup(struct device *dev, int index)
>> +{
>> +	struct phy_bind *phy_bind = NULL;
>> +
>> +	list_for_each_entry(phy_bind, &phy_bind_list, list) {
>> +		if (!(strcmp(phy_bind->dev_name, dev_name(dev)) &&
>> +				phy_bind->index == index)) {
>> +			if (phy_bind->phy)
>> +				return phy_bind->phy;
>> +			else
>> +				return ERR_PTR(-EPROBE_DEFER);
>> +		}
>> +	}
>> +
>> +	return ERR_PTR(-ENODEV);
>> +}
>> +
>> +static struct phy *of_phy_lookup(struct device_node *node)
>> +{
>> +	struct phy *phy;
>> +	struct device *dev;
>> +	struct class_dev_iter iter;
>> +
>> +	class_dev_iter_init(&iter, phy_class, NULL, NULL);
>> +	while ((dev = class_dev_iter_next(&iter))) {
>> +		phy = container_of(dev, struct phy, dev);
>
> it would look a bit better if you provided a to_phy() macro. Specially
> since this container_of() repeats multiple times in this file.

hmm.. ok.
>
>> +/**
>> + * phy_put() - release the PHY
>> + * @phy: the phy returned by phy_get()
>> + *
>> + * Releases a refcount the caller received from phy_get().
>> + */
>> +void phy_put(struct phy *phy)
>> +{
>
> I would rather:
>
> if (WARN(IS_ERR(phy), "invalid parameter\n"))
> 	return;
>
> module_put(phy->ops->owner);
> put_device(&phy->dev);
>
> that way we can catch users passing bogus pointers here. When PHY layer
> is disabled, you want to make this is no-op with a static inline in a
> header anyway.

yeah. Have that no-op in header file.
>
>> +struct phy *of_phy_xlate(struct phy *phy, struct of_phandle_args *args)
>> +{
>> +	return phy;
>> +}
>> +EXPORT_SYMBOL_GPL(of_phy_xlate);
>
> so you get a PHY and just return it ? What gives ?? (maybe I skipped
> some of the discussion...)

hmm.. this is for the common case where the PHY provider implements only 
one PHY. And both phy provider and phy_instance is represented by struct 
phy *.

For the case where PHY provider implements multiple PHYs (here it will 
have a single dt node), the PHY provider will implement it's own version 
of of_xlate that takes *of_phandle_args* as argument and finds the 
appropriate PHY.
>
>> +struct phy *of_phy_get(struct device *dev, int index)
>> +{
>> +	int ret;
>> +	struct phy *phy = NULL;
>> +	struct phy_bind *phy_map = NULL;
>> +	struct of_phandle_args args;
>> +	struct device_node *node;
>> +
>> +	if (!dev->of_node) {
>> +		dev_dbg(dev, "device does not have a device node entry\n");
>> +		return ERR_PTR(-EINVAL);
>> +	}
>> +
>> +	ret = of_parse_phandle_with_args(dev->of_node, "phys", "#phy-cells",
>> +		index, &args);
>> +	if (ret) {
>> +		dev_dbg(dev, "failed to get phy in %s node\n",
>> +			dev->of_node->full_name);
>> +		return ERR_PTR(-ENODEV);
>> +	}
>> +
>> +	phy = of_phy_lookup(args.np);
>> +	if (IS_ERR(phy) || !try_module_get(phy->ops->owner)) {
>> +		phy = ERR_PTR(-EPROBE_DEFER);
>> +		goto err0;
>> +	}
>> +
>> +	phy = phy->ops->of_xlate(phy, &args);
>
> alright, so of_xlate() is optional, am I right ? How about not

Not really. of_xlate is mandatory (it's even checked in phy_create). 
Either the PHY provider can implement it's own version or use the 
implementation above (by filling the function pointer).

> implementing the above and have a check for of_xlate() being a valid
> pointer here ?

Having the way it is actually mandates the PHY providers to always 
provide of_xlate which IMO is better since some PHY providers wont 
accidentally be using the default implementation.
>
>> +struct phy *phy_create(struct device *dev, const char *label,
>> +	struct device_node *of_node, int type, struct phy_ops *ops,
>> +	void *priv)
>> +{
>> +	int ret;
>> +	struct phy *phy;
>> +	struct phy_bind *phy_bind;
>> +	const char *devname = NULL;
>> +
>> +	if (!dev) {
>> +		dev_err(dev, "no device provided for PHY\n");
>
> I'd call this a WARN() or am I too pedantic? :-p
>
>> +	if (!ops || !ops->of_xlate || !priv) {
>> +		dev_err(dev, "no PHY ops/PHY data provided\n");
>
> likewise here.

hmm.. ok.
>
>> +		ret = -EINVAL;
>> +		goto err0;
>> +	}
>> +
>> +	if (!phy_class)
>> +		phy_core_init();
>
> why don't you setup the class on module_init ? Then this would be a
> terrible error condition here :-)

This is for the case where the PHY driver gets loaded before the PHY 
framework. I could have returned EPROBE_DEFER here instead I thought 
will have it this way.
>
>> +static struct device_attribute phy_dev_attrs[] = {
>> +	__ATTR(label, 0444, phy_name_show, NULL),
>> +	__ATTR(phy_bind, 0444, phy_bind_show, NULL),
>
> you could expose a human-readable 'type' string. BTW, how are you using
> type ? USB2/USB3/etc ? Have you considered our OMAP5 SerDes pair which

Actually not using *type* anywhere. Just used as an additional info 
about the PHY. It's actually not even enum. Maybe I can remove it 
completely.
> are currently for USB3 and SATA (and could just as easily be used for
> PCIe)

Yeah. Me and Balaji were planning to work on it for having a single 
driver to be used for all the above.
>
>> +static void phy_release(struct device *dev)
>> +{
>> +	struct phy *phy;
>> +
>> +	phy = container_of(dev, struct phy, dev);
>> +	dev_dbg(dev, "releasing '%s'\n", dev_name(dev));
>
> how about dev_vdbg() ? I doubt anyone will be waiting for this
> message... Just a thought
>
>> +static int phy_core_init(void)
>> +{
>> +	if (phy_class)
>> +		return 0;
>
> Weird.. if you initialize the class here, why do you need to initialize
> it during phy_create() ?
>
> What's going on ? Also, module_init() will only be called once, why this
> if (phy_class) check ?

er.. for the case where phy driver is loaded before this PHY framework, 
phy_create would have already called phy_core_init to create the 
phy_class. So module_init() is not needed at all since we have already 
created the phy_class. I think this looks a bit hacky.
Either we can have EPROBE_DEFER in phy_create or have this module as 
subsys_initcall() like I had it before. I would actually prefer it to be 
subsys_initcall().

Thanks
Kishon


From pdeschrijver at nvidia.com  Wed Apr  3 10:19:16 2013
From: pdeschrijver at nvidia.com (Peter De Schrijver)
Date: Wed, 3 Apr 2013 17:19:16 +0300
Subject: [PATCH v8 10/14] ARM: tegra: Define Tegra114 CAR binding
In-Reply-To: <515031E3.40007@nvidia.com>
References: <1363956029-31873-1-git-send-email-pdeschrijver@nvidia.com>
 <1363956029-31873-11-git-send-email-pdeschrijver@nvidia.com>
 <515031E3.40007@nvidia.com>
Message-ID: <20130403141916.GS18519@tbergstrom-lnx.Nvidia.com>

On Mon, Mar 25, 2013 at 12:15:47PM +0100, Prashant Gaikwad wrote:
> On Friday 22 March 2013 06:09 PM, Peter De Schrijver wrote:
> > The device tree binding models Tegra114 CAR (Clock And Reset) as a single
> > monolithic clock provider.
> >
> > Signed-off-by: Peter De Schrijver <pdeschrijver at nvidia.com>
> > ---
> 
> <snip>
> 
> > +  263	cclk_lp
> > +  264	dfll_ref
> > +  265	dfll_soc
> > +
> 
> Peter,
> 
> Please remove following clock IDs from binding.
> 
> > +Mux clocks
> > +

...
> > +  306	clk_out_1_mux

Is at least used by the init list. So we can't remove that?

Cheers,

Peter.


From mgorman at suse.de  Wed Apr  3 10:20:19 2013
From: mgorman at suse.de (Mel Gorman)
Date: Wed, 3 Apr 2013 15:20:19 +0100
Subject: [PATCH v3] mm: Make snapshotting pages for stable writes a
 per-bio operation
In-Reply-To: <20130402170143.GA8910@blackbox.djwong.org>
References: <20130313011020.GA5313@blackbox.djwong.org>
 <20130313085021.GA29730@quack.suse.cz>
 <20130313194429.GE5313@blackbox.djwong.org>
 <20130313210216.GA7754@quack.suse.cz>
 <20130314224243.GI5313@blackbox.djwong.org>
 <20130315100105.GA4889@quack.suse.cz>
 <20130315232816.GN5313@blackbox.djwong.org>
 <20130318174134.GB7852@quack.suse.cz>
 <20130318230259.GP5313@blackbox.djwong.org>
 <20130402170143.GA8910@blackbox.djwong.org>
Message-ID: <20130403142019.GC5811@suse.de>

On Tue, Apr 02, 2013 at 10:01:43AM -0700, Darrick J. Wong wrote:
> Hi,
> 
> A couple of weeks have gone by without further comments about this patch.
> 
> Are you interested in the minor cleanups and added comments, or is the v2 patch
> in -next good enough?
> 
> Apparently Mel Gorman's interested in this patchset too.  Mel: Most of stable
> pages part 2 are already in upstream for 3.9... except this piece.  Are you
> interested in having this piece in 3.9 also?  Or is 3.10 good enough for
> everyone?
> 

My understanding is that it only affects ARM and DEBUG_VM so there is a
relatively small chance of this generating spurious bug reports.  However,
3.9 is still far enough away that I see no good reason to delay this patch
until 3.10 either.

-- 
Mel Gorman
SUSE Labs


From daniel.lezcano at linaro.org  Wed Apr  3 10:25:54 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Wed, 03 Apr 2013 16:25:54 +0200
Subject: [PATCH 9/9] POWERPC: pseries: cpuidle: use time keeping flag
In-Reply-To: <1364991322-20585-9-git-send-email-daniel.lezcano@linaro.org>
References: <1364991322-20585-1-git-send-email-daniel.lezcano@linaro.org>
 <1364991322-20585-9-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <515C3BF2.7040609@linaro.org>

On 04/03/2013 02:15 PM, Daniel Lezcano wrote:
> The current code computes the idle time but that can be handled
> by the cpuidle framework if we enable the .en_core_tk_irqen flag.
>
> Set the flag and remove the code related to the time computation.
>
> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
> Signed-off-by: Deepthi Dharwar <deepthi at linux.vnet.ibm.com>
> ---

Rafael,

Deepthi took the patch, did a fix and tested it, this is why there is
its signed-off.

Deepthi, could you ack the patch for Rafael also ?

Thanks
-- Daniel

>  arch/powerpc/platforms/pseries/processor_idle.c |   35 ++++++++++-------------
>  1 file changed, 15 insertions(+), 20 deletions(-)
>
> diff --git a/arch/powerpc/platforms/pseries/processor_idle.c b/arch/powerpc/platforms/pseries/processor_idle.c
> index 4d806b4..a197120 100644
> --- a/arch/powerpc/platforms/pseries/processor_idle.c
> +++ b/arch/powerpc/platforms/pseries/processor_idle.c
> @@ -23,8 +23,9 @@
>  #include "pseries.h"
>  
>  struct cpuidle_driver pseries_idle_driver = {
> -	.name =		"pseries_idle",
> -	.owner =	THIS_MODULE,
> +	.name             = "pseries_idle",
> +	.owner            = THIS_MODULE,
> +	.en_core_tk_irqen = 1,
>  };
>  
>  #define MAX_IDLE_STATE_COUNT	2
> @@ -33,10 +34,8 @@ static int max_idle_state = MAX_IDLE_STATE_COUNT - 1;
>  static struct cpuidle_device __percpu *pseries_cpuidle_devices;
>  static struct cpuidle_state *cpuidle_state_table;
>  
> -static inline void idle_loop_prolog(unsigned long *in_purr, ktime_t *kt_before)
> +static inline void idle_loop_prolog(unsigned long *in_purr)
>  {
> -
> -	*kt_before = ktime_get();
>  	*in_purr = mfspr(SPRN_PURR);
>  	/*
>  	 * Indicate to the HV that we are idle. Now would be
> @@ -45,12 +44,10 @@ static inline void idle_loop_prolog(unsigned long *in_purr, ktime_t *kt_before)
>  	get_lppaca()->idle = 1;
>  }
>  
> -static inline  s64 idle_loop_epilog(unsigned long in_purr, ktime_t kt_before)
> +static inline void idle_loop_epilog(unsigned long in_purr)
>  {
>  	get_lppaca()->wait_state_cycles += mfspr(SPRN_PURR) - in_purr;
>  	get_lppaca()->idle = 0;
> -
> -	return ktime_to_us(ktime_sub(ktime_get(), kt_before));
>  }
>  
>  static int snooze_loop(struct cpuidle_device *dev,
> @@ -58,10 +55,9 @@ static int snooze_loop(struct cpuidle_device *dev,
>  			int index)
>  {
>  	unsigned long in_purr;
> -	ktime_t kt_before;
>  	int cpu = dev->cpu;
>  
> -	idle_loop_prolog(&in_purr, &kt_before);
> +	idle_loop_prolog(&in_purr);
>  	local_irq_enable();
>  	set_thread_flag(TIF_POLLING_NRFLAG);
>  
> @@ -75,8 +71,8 @@ static int snooze_loop(struct cpuidle_device *dev,
>  	clear_thread_flag(TIF_POLLING_NRFLAG);
>  	smp_mb();
>  
> -	dev->last_residency =
> -		(int)idle_loop_epilog(in_purr, kt_before);
> +	idle_loop_epilog(in_purr);
> +
>  	return index;
>  }
>  
> @@ -102,9 +98,8 @@ static int dedicated_cede_loop(struct cpuidle_device *dev,
>  				int index)
>  {
>  	unsigned long in_purr;
> -	ktime_t kt_before;
>  
> -	idle_loop_prolog(&in_purr, &kt_before);
> +	idle_loop_prolog(&in_purr);
>  	get_lppaca()->donate_dedicated_cpu = 1;
>  
>  	ppc64_runlatch_off();
> @@ -112,8 +107,9 @@ static int dedicated_cede_loop(struct cpuidle_device *dev,
>  	check_and_cede_processor();
>  
>  	get_lppaca()->donate_dedicated_cpu = 0;
> -	dev->last_residency =
> -		(int)idle_loop_epilog(in_purr, kt_before);
> +
> +	idle_loop_epilog(in_purr);
> +
>  	return index;
>  }
>  
> @@ -122,9 +118,8 @@ static int shared_cede_loop(struct cpuidle_device *dev,
>  			int index)
>  {
>  	unsigned long in_purr;
> -	ktime_t kt_before;
>  
> -	idle_loop_prolog(&in_purr, &kt_before);
> +	idle_loop_prolog(&in_purr);
>  
>  	/*
>  	 * Yield the processor to the hypervisor.  We return if
> @@ -135,8 +130,8 @@ static int shared_cede_loop(struct cpuidle_device *dev,
>  	 */
>  	check_and_cede_processor();
>  
> -	dev->last_residency =
> -		(int)idle_loop_epilog(in_purr, kt_before);
> +	idle_loop_epilog(in_purr);
> +
>  	return index;
>  }
>  


-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From balbi at ti.com  Wed Apr  3 10:27:47 2013
From: balbi at ti.com (Felipe Balbi)
Date: Wed, 3 Apr 2013 17:27:47 +0300
Subject: [PATCH v5 1/6] drivers: phy: add generic PHY framework
In-Reply-To: <515C3A42.4020404@ti.com>
References: <1364993634-6378-1-git-send-email-kishon@ti.com>
 <1364993634-6378-2-git-send-email-kishon@ti.com>
 <20130403134102.GC14680@arwen.pp.htv.fi> <515C3A42.4020404@ti.com>
Message-ID: <20130403142747.GK14680@arwen.pp.htv.fi>

hi,

On Wed, Apr 03, 2013 at 07:48:42PM +0530, Kishon Vijay Abraham I wrote:
> >>+struct phy *of_phy_xlate(struct phy *phy, struct of_phandle_args *args)
> >>+{
> >>+	return phy;
> >>+}
> >>+EXPORT_SYMBOL_GPL(of_phy_xlate);
> >
> >so you get a PHY and just return it ? What gives ?? (maybe I skipped
> >some of the discussion...)
> 
> hmm.. this is for the common case where the PHY provider implements
> only one PHY. And both phy provider and phy_instance is represented
> by struct phy *.
> 
> For the case where PHY provider implements multiple PHYs (here it
> will have a single dt node), the PHY provider will implement it's own
> version of of_xlate that takes *of_phandle_args* as argument and
> finds the appropriate PHY.

got it.

> >>+struct phy *of_phy_get(struct device *dev, int index)
> >>+{
> >>+	int ret;
> >>+	struct phy *phy = NULL;
> >>+	struct phy_bind *phy_map = NULL;
> >>+	struct of_phandle_args args;
> >>+	struct device_node *node;
> >>+
> >>+	if (!dev->of_node) {
> >>+		dev_dbg(dev, "device does not have a device node entry\n");
> >>+		return ERR_PTR(-EINVAL);
> >>+	}
> >>+
> >>+	ret = of_parse_phandle_with_args(dev->of_node, "phys", "#phy-cells",
> >>+		index, &args);
> >>+	if (ret) {
> >>+		dev_dbg(dev, "failed to get phy in %s node\n",
> >>+			dev->of_node->full_name);
> >>+		return ERR_PTR(-ENODEV);
> >>+	}
> >>+
> >>+	phy = of_phy_lookup(args.np);
> >>+	if (IS_ERR(phy) || !try_module_get(phy->ops->owner)) {
> >>+		phy = ERR_PTR(-EPROBE_DEFER);
> >>+		goto err0;
> >>+	}
> >>+
> >>+	phy = phy->ops->of_xlate(phy, &args);
> >
> >alright, so of_xlate() is optional, am I right ? How about not
> 
> Not really. of_xlate is mandatory (it's even checked in phy_create).
> Either the PHY provider can implement it's own version or use the
> implementation above (by filling the function pointer).

alright.

> >implementing the above and have a check for of_xlate() being a valid
> >pointer here ?
> 
> Having the way it is actually mandates the PHY providers to always
> provide of_xlate which IMO is better since some PHY providers wont
> accidentally be using the default implementation.

ok cool, thanks for clarifying.

> >>+		ret = -EINVAL;
> >>+		goto err0;
> >>+	}
> >>+
> >>+	if (!phy_class)
> >>+		phy_core_init();
> >
> >why don't you setup the class on module_init ? Then this would be a
> >terrible error condition here :-)
> 
> This is for the case where the PHY driver gets loaded before the PHY
> framework. I could have returned EPROBE_DEFER here instead I thought
> will have it this way.

looks a bit weird IMO. Is it really possible for PHY to load before ?
Since PHY driver uses symbols from phy-core, modprobe will make sure to
load drivers based on symbol dependency, right ?

> >>+static struct device_attribute phy_dev_attrs[] = {
> >>+	__ATTR(label, 0444, phy_name_show, NULL),
> >>+	__ATTR(phy_bind, 0444, phy_bind_show, NULL),
> >
> >you could expose a human-readable 'type' string. BTW, how are you using
> >type ? USB2/USB3/etc ? Have you considered our OMAP5 SerDes pair which
> 
> Actually not using *type* anywhere. Just used as an additional info
> about the PHY. It's actually not even enum. Maybe I can remove it
> completely.

makes sense.

> >are currently for USB3 and SATA (and could just as easily be used for
> >PCIe)
> 
> Yeah. Me and Balaji were planning to work on it for having a single
> driver to be used for all the above.

cool :-)

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130403/57dd0ca2/attachment.sig>

From kishon at ti.com  Wed Apr  3 10:32:52 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Wed, 3 Apr 2013 20:02:52 +0530
Subject: [PATCH v5 1/6] drivers: phy: add generic PHY framework
In-Reply-To: <20130403142747.GK14680@arwen.pp.htv.fi>
References: <1364993634-6378-1-git-send-email-kishon@ti.com>
 <1364993634-6378-2-git-send-email-kishon@ti.com>
 <20130403134102.GC14680@arwen.pp.htv.fi> <515C3A42.4020404@ti.com>
 <20130403142747.GK14680@arwen.pp.htv.fi>
Message-ID: <515C3D94.1060000@ti.com>

Hi,

On Wednesday 03 April 2013 07:57 PM, Felipe Balbi wrote:
> hi,
>
> On Wed, Apr 03, 2013 at 07:48:42PM +0530, Kishon Vijay Abraham I wrote:
>>>> +struct phy *of_phy_xlate(struct phy *phy, struct of_phandle_args *args)
>>>> +{
>>>> +	return phy;
>>>> +}
>>>> +EXPORT_SYMBOL_GPL(of_phy_xlate);
>>>
>>> so you get a PHY and just return it ? What gives ?? (maybe I skipped
>>> some of the discussion...)
>>
>> hmm.. this is for the common case where the PHY provider implements
>> only one PHY. And both phy provider and phy_instance is represented
>> by struct phy *.
>>
>> For the case where PHY provider implements multiple PHYs (here it
>> will have a single dt node), the PHY provider will implement it's own
>> version of of_xlate that takes *of_phandle_args* as argument and
>> finds the appropriate PHY.
>
> got it.
>
>>>> +struct phy *of_phy_get(struct device *dev, int index)
>>>> +{
>>>> +	int ret;
>>>> +	struct phy *phy = NULL;
>>>> +	struct phy_bind *phy_map = NULL;
>>>> +	struct of_phandle_args args;
>>>> +	struct device_node *node;
>>>> +
>>>> +	if (!dev->of_node) {
>>>> +		dev_dbg(dev, "device does not have a device node entry\n");
>>>> +		return ERR_PTR(-EINVAL);
>>>> +	}
>>>> +
>>>> +	ret = of_parse_phandle_with_args(dev->of_node, "phys", "#phy-cells",
>>>> +		index, &args);
>>>> +	if (ret) {
>>>> +		dev_dbg(dev, "failed to get phy in %s node\n",
>>>> +			dev->of_node->full_name);
>>>> +		return ERR_PTR(-ENODEV);
>>>> +	}
>>>> +
>>>> +	phy = of_phy_lookup(args.np);
>>>> +	if (IS_ERR(phy) || !try_module_get(phy->ops->owner)) {
>>>> +		phy = ERR_PTR(-EPROBE_DEFER);
>>>> +		goto err0;
>>>> +	}
>>>> +
>>>> +	phy = phy->ops->of_xlate(phy, &args);
>>>
>>> alright, so of_xlate() is optional, am I right ? How about not
>>
>> Not really. of_xlate is mandatory (it's even checked in phy_create).
>> Either the PHY provider can implement it's own version or use the
>> implementation above (by filling the function pointer).
>
> alright.
>
>>> implementing the above and have a check for of_xlate() being a valid
>>> pointer here ?
>>
>> Having the way it is actually mandates the PHY providers to always
>> provide of_xlate which IMO is better since some PHY providers wont
>> accidentally be using the default implementation.
>
> ok cool, thanks for clarifying.
>
>>>> +		ret = -EINVAL;
>>>> +		goto err0;
>>>> +	}
>>>> +
>>>> +	if (!phy_class)
>>>> +		phy_core_init();
>>>
>>> why don't you setup the class on module_init ? Then this would be a
>>> terrible error condition here :-)
>>
>> This is for the case where the PHY driver gets loaded before the PHY
>> framework. I could have returned EPROBE_DEFER here instead I thought
>> will have it this way.
>
> looks a bit weird IMO. Is it really possible for PHY to load before ?

yeah. it actually happened when I tried with beagle and had all the 
modules as built-in. Because twl4030 has subsys_initcall(), it loads 
before PHY framework.

Thanks
Kishon


From pdeschrijver at nvidia.com  Wed Apr  3 10:40:34 2013
From: pdeschrijver at nvidia.com (Peter De Schrijver)
Date: Wed, 3 Apr 2013 17:40:34 +0300
Subject: [PATCH v9 00/14] Tegra114 clockframework
Message-ID: <1365000110-8916-1-git-send-email-pdeschrijver@nvidia.com>

This is the nineth version of the Tegra114 clockframework. It is based on the
next-20130320-fixed branch of
git://nv-tegra.nvidia.com/user/swarren/linux-2.6.git,
http://patchwork.ozlabs.org/patch/229972/ and
http://patchwork.ozlabs.org/patch/229978/ and
http://patchwork.ozlabs.org/patch/233415/

It has been boottested on Dalmore.

Changes from v8:

* Added pdiv table for PLLU
* Fixed clock initialization for audio

Changes from v7:

* Fixed dummy operations
* Removed some duplicates from the binding document
* Fixed tegra114_clk enum to be in line with the binding document
* Removed __initdata from tegra_periph_clk_list and
  tegra_periph_nodiv_clk_list
* Mark csite clock as CLK_IGNORE_UNUSED
* Fixed mux mask for disp1 and disp2
* Fixed initializations for PLLX, PLLC, PLLC2 and PLCC3
* Converted clk_pll_wait_for_lock() to use a mask instead of a single bit
* added TEGRA_PLL_HAS_LOCK_ENABLE flag

Changes from v6:

* Remove clock-frequency from DT serial nodes
* Remove useless 'cpu' clock from binding documentation
* Use HW gate control for PLLU divided outputs
* Fix clock ID for 'd_audio' clock
* Add dummy cpu car ops to ease making a bisectable series

Changes from v5:

* Add initialization code for PLLC
* Remove some unnecessary clocks
* Fix bug in PLL locking refactoring
* Add super clocks
* Remove most calls to clk_register_clkdev() for the peripheral clocks

Changes from v4:

* Split the new PLL types patch into smaller patches
* Fix some bugs in the PLL patches

Changes from v3:

* Merge with for-next branch
* Provide empty tegra_cpu_car_ops to make SMP boot not crash

Changes from v2:

* Added missing PLLs
* Added bindings to tegra114.dtsi
* Moved the table patch for clk-mux.c to 'clk: add table lookup to mux'
* Bugfixes

Changes from v1:

* Remove SATA and PCIe clocks. They don't appear in the internal TRM, so I
  assume they don't exist.
* Rebase on top of Hiroshi's latest Tegra114 patches
* More generic mux code. This is necessary for the AHUB and DAM clocks.


Peter De Schrijver (14):
  clk: tegra: provide dummy cpu car ops
  clk: tegra: Refactor PLL programming code
  clk: tegra: Add TEGRA_PLL_BYPASS flag
  clk: tegra: introduce TEGRA_PLL_HAS_LOCK_ENABLE
  clk: tegra: Add PLL post divider table
  clk: tegra: move from a lock bit idx to a lock mask
  clk: tegra: Add new fields and PLL types for Tegra114
  clk: tegra: Add flags to tegra_clk_periph()
  clk: tegra: Workaround for Tegra114 MSENC problem
  ARM: tegra: Define Tegra114 CAR binding
  clk: tegra: Implement clocks for Tegra114
  clk: tegra: devicetree match for nvidia,tegra114-car
  ARM: dt: Add references to tegra_car clocks
  clk: tegra: Remove forced clk_enable of uartd

 .../bindings/clock/nvidia,tegra114-car.txt         |  317 +++
 arch/arm/boot/dts/tegra114-dalmore.dts             |    1 -
 arch/arm/boot/dts/tegra114-pluto.dts               |    1 -
 arch/arm/boot/dts/tegra114.dtsi                    |    8 +-
 drivers/clk/tegra/Makefile                         |    1 +
 drivers/clk/tegra/clk-periph-gate.c                |    9 +
 drivers/clk/tegra/clk-periph.c                     |   11 +-
 drivers/clk/tegra/clk-pll.c                        | 1194 ++++++++++--
 drivers/clk/tegra/clk-tegra114.c                   | 2085 ++++++++++++++++++++
 drivers/clk/tegra/clk-tegra20.c                    |  173 +-
 drivers/clk/tegra/clk-tegra30.c                    |  265 ++--
 drivers/clk/tegra/clk.c                            |    4 +-
 drivers/clk/tegra/clk.h                            |   95 +-
 13 files changed, 3805 insertions(+), 359 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/clock/nvidia,tegra114-car.txt
 create mode 100644 drivers/clk/tegra/clk-tegra114.c

-- 
1.7.7.rc0.72.g4b5ea.dirty



From jack at suse.cz  Wed Apr  3 10:42:44 2013
From: jack at suse.cz (Jan Kara)
Date: Wed, 3 Apr 2013 16:42:44 +0200
Subject: [PATCH v3] mm: Make snapshotting pages for stable writes a
 per-bio operation
In-Reply-To: <20130403142019.GC5811@suse.de>
References: <20130313085021.GA29730@quack.suse.cz>
 <20130313194429.GE5313@blackbox.djwong.org>
 <20130313210216.GA7754@quack.suse.cz>
 <20130314224243.GI5313@blackbox.djwong.org>
 <20130315100105.GA4889@quack.suse.cz>
 <20130315232816.GN5313@blackbox.djwong.org>
 <20130318174134.GB7852@quack.suse.cz>
 <20130318230259.GP5313@blackbox.djwong.org>
 <20130402170143.GA8910@blackbox.djwong.org>
 <20130403142019.GC5811@suse.de>
Message-ID: <20130403144244.GC14667@quack.suse.cz>

On Wed 03-04-13 15:20:19, Mel Gorman wrote:
> On Tue, Apr 02, 2013 at 10:01:43AM -0700, Darrick J. Wong wrote:
> > Hi,
> > 
> > A couple of weeks have gone by without further comments about this patch.
> > 
> > Are you interested in the minor cleanups and added comments, or is the v2 patch
> > in -next good enough?
> > 
> > Apparently Mel Gorman's interested in this patchset too.  Mel: Most of stable
> > pages part 2 are already in upstream for 3.9... except this piece.  Are you
> > interested in having this piece in 3.9 also?  Or is 3.10 good enough for
> > everyone?
> > 
> 
> My understanding is that it only affects ARM and DEBUG_VM so there is a
> relatively small chance of this generating spurious bug reports.  However,
> 3.9 is still far enough away that I see no good reason to delay this patch
> until 3.10 either.
  No, actually with direct IO, anything that needs stable pages is going to
blow up quickly because pages attached to bio needn't be from page cache. So
I think it should better make it into 3.9.

									Honza
-- 
Jan Kara <jack at suse.cz>
SUSE Labs, CR


From pdeschrijver at nvidia.com  Wed Apr  3 10:40:35 2013
From: pdeschrijver at nvidia.com (Peter De Schrijver)
Date: Wed, 3 Apr 2013 17:40:35 +0300
Subject: [PATCH v9 01/14] clk: tegra: provide dummy cpu car ops
In-Reply-To: <1365000110-8916-1-git-send-email-pdeschrijver@nvidia.com>
References: <1365000110-8916-1-git-send-email-pdeschrijver@nvidia.com>
Message-ID: <1365000110-8916-2-git-send-email-pdeschrijver@nvidia.com>

tegra_boot_secondary() relies on some of the car ops. This means having an
uninitialized tegra_cpu_car_ops will lead to an early boot panic.
Providing a dummy struct avoids this and makes adding Tegra114 clock support
in a bisectable way a lot easier.

Signed-off-by: Peter De Schrijver <pdeschrijver at nvidia.com>
---
 drivers/clk/tegra/clk.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/clk/tegra/clk.c b/drivers/clk/tegra/clk.c
index 4a61d15..70b7a47 100644
--- a/drivers/clk/tegra/clk.c
+++ b/drivers/clk/tegra/clk.c
@@ -22,7 +22,8 @@
 #include "clk.h"
 
 /* Global data of Tegra CPU CAR ops */
-struct tegra_cpu_car_ops *tegra_cpu_car_ops;
+static struct tegra_cpu_car_ops dummy_car_ops;
+struct tegra_cpu_car_ops *tegra_cpu_car_ops = &dummy_car_ops;
 
 void __init tegra_init_dup_clks(struct tegra_clk_duplicate *dup_list,
 				struct clk *clks[], int clk_max)
-- 
1.7.7.rc0.72.g4b5ea.dirty



From pdeschrijver at nvidia.com  Wed Apr  3 10:40:36 2013
From: pdeschrijver at nvidia.com (Peter De Schrijver)
Date: Wed, 3 Apr 2013 17:40:36 +0300
Subject: [PATCH v9 02/14] clk: tegra: Refactor PLL programming code
In-Reply-To: <1365000110-8916-1-git-send-email-pdeschrijver@nvidia.com>
References: <1365000110-8916-1-git-send-email-pdeschrijver@nvidia.com>
Message-ID: <1365000110-8916-3-git-send-email-pdeschrijver@nvidia.com>

Refactor the PLL programming code to make it useable by the new PLL types
introduced by Tegra114.

The following changes were done:

* Split programming the PLL into updating m,n,p and updating cpcon
* Move locking from _update_pll_cpcon() to clk_pll_set_rate()
* Introduce _get_pll_mnp() helper
* Move check for identical m,n,p values to clk_pll_set_rate()
* struct tegra_clk_pll_freq_table will always contain the values as defined
  by the hardware.
* Simplify the arguments to clk_pll_wait_for_lock()
* Split _tegra_clk_register_pll()

Signed-off-by: Peter De Schrijver <pdeschrijver at nvidia.com>
---
 drivers/clk/tegra/clk-pll.c     |  262 ++++++++++++++++++++++++---------------
 drivers/clk/tegra/clk-tegra20.c |  144 +++++++++++-----------
 drivers/clk/tegra/clk-tegra30.c |  234 +++++++++++++++++-----------------
 drivers/clk/tegra/clk.h         |    9 +-
 4 files changed, 356 insertions(+), 293 deletions(-)

diff --git a/drivers/clk/tegra/clk-pll.c b/drivers/clk/tegra/clk-pll.c
index 165f247..3feefb1 100644
--- a/drivers/clk/tegra/clk-pll.c
+++ b/drivers/clk/tegra/clk-pll.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2012, NVIDIA CORPORATION.  All rights reserved.
+ * Copyright (c) 2012, 2013, NVIDIA CORPORATION.  All rights reserved.
  *
  * This program is free software; you can redistribute it and/or modify it
  * under the terms and conditions of the GNU General Public License,
@@ -113,20 +113,28 @@ static void clk_pll_enable_lock(struct tegra_clk_pll *pll)
 	pll_writel_misc(val, pll);
 }
 
-static int clk_pll_wait_for_lock(struct tegra_clk_pll *pll,
-				 void __iomem *lock_addr, u32 lock_bit_idx)
+static int clk_pll_wait_for_lock(struct tegra_clk_pll *pll)
 {
 	int i;
-	u32 val;
+	u32 val, lock_bit;
+	void __iomem *lock_addr;
 
 	if (!(pll->flags & TEGRA_PLL_USE_LOCK)) {
 		udelay(pll->params->lock_delay);
 		return 0;
 	}
 
+	lock_addr = pll->clk_base;
+	if (pll->flags & TEGRA_PLL_LOCK_MISC)
+		lock_addr += pll->params->misc_reg;
+	else
+		lock_addr += pll->params->base_reg;
+
+	lock_bit = BIT(pll->params->lock_bit_idx);
+
 	for (i = 0; i < pll->params->lock_delay; i++) {
 		val = readl_relaxed(lock_addr);
-		if (val & BIT(lock_bit_idx)) {
+		if (val & lock_bit) {
 			udelay(PLL_POST_LOCK_DELAY);
 			return 0;
 		}
@@ -155,7 +163,7 @@ static int clk_pll_is_enabled(struct clk_hw *hw)
 	return val & PLL_BASE_ENABLE ? 1 : 0;
 }
 
-static int _clk_pll_enable(struct clk_hw *hw)
+static void _clk_pll_enable(struct clk_hw *hw)
 {
 	struct tegra_clk_pll *pll = to_clk_pll(hw);
 	u32 val;
@@ -172,11 +180,6 @@ static int _clk_pll_enable(struct clk_hw *hw)
 		val |= PMC_PLLP_WB0_OVERRIDE_PLLM_ENABLE;
 		writel_relaxed(val, pll->pmc + PMC_PLLP_WB0_OVERRIDE);
 	}
-
-	clk_pll_wait_for_lock(pll, pll->clk_base + pll->params->base_reg,
-			      pll->params->lock_bit_idx);
-
-	return 0;
 }
 
 static void _clk_pll_disable(struct clk_hw *hw)
@@ -204,7 +207,9 @@ static int clk_pll_enable(struct clk_hw *hw)
 	if (pll->lock)
 		spin_lock_irqsave(pll->lock, flags);
 
-	ret = _clk_pll_enable(hw);
+	_clk_pll_enable(hw);
+
+	ret = clk_pll_wait_for_lock(pll);
 
 	if (pll->lock)
 		spin_unlock_irqrestore(pll->lock, flags);
@@ -241,8 +246,6 @@ static int _get_table_rate(struct clk_hw *hw,
 	if (sel->input_rate == 0)
 		return -EINVAL;
 
-	BUG_ON(sel->p < 1);
-
 	cfg->input_rate = sel->input_rate;
 	cfg->output_rate = sel->output_rate;
 	cfg->m = sel->m;
@@ -290,88 +293,109 @@ static int _calc_rate(struct clk_hw *hw, struct tegra_clk_pll_freq_table *cfg,
 	     cfg->output_rate <<= 1)
 		p_div++;
 
-	cfg->p = 1 << p_div;
+	cfg->p = p_div;
 	cfg->m = parent_rate / cfreq;
 	cfg->n = cfg->output_rate / cfreq;
 	cfg->cpcon = OUT_OF_TABLE_CPCON;
 
 	if (cfg->m > divm_max(pll) || cfg->n > divn_max(pll) ||
-	    cfg->p > divp_max(pll) || cfg->output_rate > pll->params->vco_max) {
+	    (1 << p_div) > divp_max(pll)
+	    || cfg->output_rate > pll->params->vco_max) {
 		pr_err("%s: Failed to set %s rate %lu\n",
 		       __func__, __clk_get_name(hw->clk), rate);
 		return -EINVAL;
 	}
 
+	if (pll->flags & TEGRA_PLLU)
+		cfg->p ^= 1;
+
 	return 0;
 }
 
-static int _program_pll(struct clk_hw *hw, struct tegra_clk_pll_freq_table *cfg,
-			unsigned long rate)
+static void _update_pll_mnp(struct tegra_clk_pll *pll,
+			    struct tegra_clk_pll_freq_table *cfg)
 {
-	struct tegra_clk_pll *pll = to_clk_pll(hw);
-	unsigned long flags = 0;
-	u32 divp, val, old_base;
-	int state;
-
-	divp = __ffs(cfg->p);
-
-	if (pll->flags & TEGRA_PLLU)
-		divp ^= 1;
+	u32 val;
 
-	if (pll->lock)
-		spin_lock_irqsave(pll->lock, flags);
+	val = pll_readl_base(pll);
 
-	old_base = val = pll_readl_base(pll);
 	val &= ~((divm_mask(pll) << pll->divm_shift) |
 		 (divn_mask(pll) << pll->divn_shift) |
 		 (divp_mask(pll) << pll->divp_shift));
 	val |= ((cfg->m << pll->divm_shift) |
 		(cfg->n << pll->divn_shift) |
-		(divp << pll->divp_shift));
-	if (val == old_base) {
-		if (pll->lock)
-			spin_unlock_irqrestore(pll->lock, flags);
-		return 0;
+		(cfg->p << pll->divp_shift));
+
+	pll_writel_base(val, pll);
+}
+
+static void _get_pll_mnp(struct tegra_clk_pll *pll,
+			 struct tegra_clk_pll_freq_table *cfg)
+{
+	u32 val;
+
+	val = pll_readl_base(pll);
+
+	cfg->m = (val >> pll->divm_shift) & (divm_mask(pll));
+	cfg->n = (val >> pll->divn_shift) & (divn_mask(pll));
+	cfg->p = (val >> pll->divp_shift) & (divp_mask(pll));
+}
+
+static void _update_pll_cpcon(struct tegra_clk_pll *pll,
+			      struct tegra_clk_pll_freq_table *cfg,
+			      unsigned long rate)
+{
+	u32 val;
+
+	val = pll_readl_misc(pll);
+
+	val &= ~(PLL_MISC_CPCON_MASK << PLL_MISC_CPCON_SHIFT);
+	val |= cfg->cpcon << PLL_MISC_CPCON_SHIFT;
+
+	if (pll->flags & TEGRA_PLL_SET_LFCON) {
+		val &= ~(PLL_MISC_LFCON_MASK << PLL_MISC_LFCON_SHIFT);
+		if (cfg->n >= PLLDU_LFCON_SET_DIVN)
+			val |= 1 << PLL_MISC_LFCON_SHIFT;
+	} else if (pll->flags & TEGRA_PLL_SET_DCCON) {
+		val &= ~(1 << PLL_MISC_DCCON_SHIFT);
+		if (rate >= (pll->params->vco_max >> 1))
+			val |= 1 << PLL_MISC_DCCON_SHIFT;
 	}
 
+	pll_writel_misc(val, pll);
+}
+
+static int _program_pll(struct clk_hw *hw, struct tegra_clk_pll_freq_table *cfg,
+			unsigned long rate)
+{
+	struct tegra_clk_pll *pll = to_clk_pll(hw);
+	int state, ret = 0;
+
 	state = clk_pll_is_enabled(hw);
 
-	if (state) {
+	if (state)
 		_clk_pll_disable(hw);
-		val &= ~(PLL_BASE_BYPASS | PLL_BASE_ENABLE);
-	}
-	pll_writel_base(val, pll);
 
-	if (pll->flags & TEGRA_PLL_HAS_CPCON) {
-		val = pll_readl_misc(pll);
-		val &= ~(PLL_MISC_CPCON_MASK << PLL_MISC_CPCON_SHIFT);
-		val |= cfg->cpcon << PLL_MISC_CPCON_SHIFT;
-		if (pll->flags & TEGRA_PLL_SET_LFCON) {
-			val &= ~(PLL_MISC_LFCON_MASK << PLL_MISC_LFCON_SHIFT);
-			if (cfg->n >= PLLDU_LFCON_SET_DIVN)
-				val |= 0x1 << PLL_MISC_LFCON_SHIFT;
-		} else if (pll->flags & TEGRA_PLL_SET_DCCON) {
-			val &= ~(0x1 << PLL_MISC_DCCON_SHIFT);
-			if (rate >= (pll->params->vco_max >> 1))
-				val |= 0x1 << PLL_MISC_DCCON_SHIFT;
-		}
-		pll_writel_misc(val, pll);
-	}
+	_update_pll_mnp(pll, cfg);
 
-	if (pll->lock)
-		spin_unlock_irqrestore(pll->lock, flags);
+	if (pll->flags & TEGRA_PLL_HAS_CPCON)
+		_update_pll_cpcon(pll, cfg, rate);
 
-	if (state)
-		clk_pll_enable(hw);
+	if (state) {
+		_clk_pll_enable(hw);
+		ret = clk_pll_wait_for_lock(pll);
+	}
 
-	return 0;
+	return ret;
 }
 
 static int clk_pll_set_rate(struct clk_hw *hw, unsigned long rate,
 			unsigned long parent_rate)
 {
 	struct tegra_clk_pll *pll = to_clk_pll(hw);
-	struct tegra_clk_pll_freq_table cfg;
+	struct tegra_clk_pll_freq_table cfg, old_cfg;
+	unsigned long flags = 0;
+	int ret = 0;
 
 	if (pll->flags & TEGRA_PLL_FIXED) {
 		if (rate != pll->fixed_rate) {
@@ -387,7 +411,18 @@ static int clk_pll_set_rate(struct clk_hw *hw, unsigned long rate,
 	    _calc_rate(hw, &cfg, rate, parent_rate))
 		return -EINVAL;
 
-	return _program_pll(hw, &cfg, rate);
+	if (pll->lock)
+		spin_lock_irqsave(pll->lock, flags);
+
+	_get_pll_mnp(pll, &old_cfg);
+
+	if (old_cfg.m != cfg.m || old_cfg.n != cfg.n || old_cfg.p != cfg.p)
+		ret = _program_pll(hw, &cfg, rate);
+
+	if (pll->lock)
+		spin_unlock_irqrestore(pll->lock, flags);
+
+	return ret;
 }
 
 static long clk_pll_round_rate(struct clk_hw *hw, unsigned long rate,
@@ -409,7 +444,7 @@ static long clk_pll_round_rate(struct clk_hw *hw, unsigned long rate,
 		return -EINVAL;
 
 	output_rate *= cfg.n;
-	do_div(output_rate, cfg.m * cfg.p);
+	do_div(output_rate, cfg.m * (1 << cfg.p));
 
 	return output_rate;
 }
@@ -418,10 +453,12 @@ static unsigned long clk_pll_recalc_rate(struct clk_hw *hw,
 					 unsigned long parent_rate)
 {
 	struct tegra_clk_pll *pll = to_clk_pll(hw);
-	u32 val = pll_readl_base(pll);
-	u32 divn = 0, divm = 0, divp = 0;
+	struct tegra_clk_pll_freq_table cfg;
+	u32 val;
 	u64 rate = parent_rate;
 
+	val = pll_readl_base(pll);
+
 	if (val & PLL_BASE_BYPASS)
 		return parent_rate;
 
@@ -435,16 +472,16 @@ static unsigned long clk_pll_recalc_rate(struct clk_hw *hw,
 		return pll->fixed_rate;
 	}
 
-	divp = (val >> pll->divp_shift) & (divp_mask(pll));
+	_get_pll_mnp(pll, &cfg);
+
 	if (pll->flags & TEGRA_PLLU)
-		divp ^= 1;
+		cfg.p ^= 1;
 
-	divn = (val >> pll->divn_shift) & (divn_mask(pll));
-	divm = (val >> pll->divm_shift) & (divm_mask(pll));
-	divm *= (1 << divp);
+	cfg.m *= 1 << cfg.p;
+
+	rate *= cfg.n;
+	do_div(rate, cfg.m);
 
-	rate *= divn;
-	do_div(rate, divm);
 	return rate;
 }
 
@@ -538,8 +575,8 @@ static int clk_plle_enable(struct clk_hw *hw)
 	val |= (PLL_BASE_BYPASS | PLL_BASE_ENABLE);
 	pll_writel_base(val, pll);
 
-	clk_pll_wait_for_lock(pll, pll->clk_base + pll->params->misc_reg,
-			      pll->params->lock_bit_idx);
+	clk_pll_wait_for_lock(pll);
+
 	return 0;
 }
 
@@ -577,28 +614,17 @@ const struct clk_ops tegra_clk_plle_ops = {
 	.enable = clk_plle_enable,
 };
 
-static struct clk *_tegra_clk_register_pll(const char *name,
-		const char *parent_name, void __iomem *clk_base,
-		void __iomem *pmc, unsigned long flags,
-		unsigned long fixed_rate,
-		struct tegra_clk_pll_params *pll_params, u8 pll_flags,
-		struct tegra_clk_pll_freq_table *freq_table, spinlock_t *lock,
-		const struct clk_ops *ops)
+static struct tegra_clk_pll *_tegra_init_pll(void __iomem *clk_base,
+		void __iomem *pmc, unsigned long fixed_rate,
+		struct tegra_clk_pll_params *pll_params, u32 pll_flags,
+		struct tegra_clk_pll_freq_table *freq_table, spinlock_t *lock)
 {
 	struct tegra_clk_pll *pll;
-	struct clk *clk;
-	struct clk_init_data init;
 
 	pll = kzalloc(sizeof(*pll), GFP_KERNEL);
 	if (!pll)
 		return ERR_PTR(-ENOMEM);
 
-	init.name = name;
-	init.ops = ops;
-	init.flags = flags;
-	init.parent_names = (parent_name ? &parent_name : NULL);
-	init.num_parents = (parent_name ? 1 : 0);
-
 	pll->clk_base = clk_base;
 	pll->pmc = pmc;
 
@@ -615,34 +641,68 @@ static struct clk *_tegra_clk_register_pll(const char *name,
 	pll->divm_shift = PLL_BASE_DIVM_SHIFT;
 	pll->divm_width = PLL_BASE_DIVM_WIDTH;
 
+	return pll;
+}
+
+static struct clk *_tegra_clk_register_pll(struct tegra_clk_pll *pll,
+		const char *name, const char *parent_name, unsigned long flags,
+		const struct clk_ops *ops)
+{
+	struct clk_init_data init;
+
+	init.name = name;
+	init.ops = ops;
+	init.flags = flags;
+	init.parent_names = (parent_name ? &parent_name : NULL);
+	init.num_parents = (parent_name ? 1 : 0);
+
 	/* Data in .init is copied by clk_register(), so stack variable OK */
 	pll->hw.init = &init;
 
-	clk = clk_register(NULL, &pll->hw);
-	if (IS_ERR(clk))
-		kfree(pll);
-
-	return clk;
+	return clk_register(NULL, &pll->hw);
 }
 
 struct clk *tegra_clk_register_pll(const char *name, const char *parent_name,
 		void __iomem *clk_base, void __iomem *pmc,
 		unsigned long flags, unsigned long fixed_rate,
-		struct tegra_clk_pll_params *pll_params, u8 pll_flags,
+		struct tegra_clk_pll_params *pll_params, u32 pll_flags,
 		struct tegra_clk_pll_freq_table *freq_table, spinlock_t *lock)
 {
-	return _tegra_clk_register_pll(name, parent_name, clk_base, pmc,
-			flags, fixed_rate, pll_params, pll_flags, freq_table,
-			lock, &tegra_clk_pll_ops);
+	struct tegra_clk_pll *pll;
+	struct clk *clk;
+
+	pll = _tegra_init_pll(clk_base, pmc, fixed_rate, pll_params, pll_flags,
+			      freq_table, lock);
+	if (IS_ERR(pll))
+		return ERR_CAST(pll);
+
+	clk = _tegra_clk_register_pll(pll, name, parent_name, flags,
+				      &tegra_clk_pll_ops);
+	if (IS_ERR(clk))
+		kfree(pll);
+
+	return clk;
 }
 
 struct clk *tegra_clk_register_plle(const char *name, const char *parent_name,
 		void __iomem *clk_base, void __iomem *pmc,
 		unsigned long flags, unsigned long fixed_rate,
-		struct tegra_clk_pll_params *pll_params, u8 pll_flags,
+		struct tegra_clk_pll_params *pll_params, u32 pll_flags,
 		struct tegra_clk_pll_freq_table *freq_table, spinlock_t *lock)
 {
-	return _tegra_clk_register_pll(name, parent_name, clk_base, pmc,
-			flags, fixed_rate, pll_params, pll_flags, freq_table,
-			lock, &tegra_clk_plle_ops);
+	struct tegra_clk_pll *pll;
+	struct clk *clk;
+	pll_flags |= TEGRA_PLL_LOCK_MISC;
+
+	pll = _tegra_init_pll(clk_base, pmc, fixed_rate, pll_params, pll_flags,
+			      freq_table, lock);
+	if (IS_ERR(pll))
+		return ERR_CAST(pll);
+
+	clk = _tegra_clk_register_pll(pll, name, parent_name, flags,
+				      &tegra_clk_plle_ops);
+	if (IS_ERR(clk))
+		kfree(pll);
+
+	return clk;
 }
diff --git a/drivers/clk/tegra/clk-tegra20.c b/drivers/clk/tegra/clk-tegra20.c
index 3738d33..13efdfb 100644
--- a/drivers/clk/tegra/clk-tegra20.c
+++ b/drivers/clk/tegra/clk-tegra20.c
@@ -248,125 +248,125 @@ static struct clk *clks[clk_max];
 static struct clk_onecell_data clk_data;
 
 static struct tegra_clk_pll_freq_table pll_c_freq_table[] = {
-	{ 12000000, 600000000, 600, 12, 1, 8 },
-	{ 13000000, 600000000, 600, 13, 1, 8 },
-	{ 19200000, 600000000, 500, 16, 1, 6 },
-	{ 26000000, 600000000, 600, 26, 1, 8 },
+	{ 12000000, 600000000, 600, 12, 0, 8 },
+	{ 13000000, 600000000, 600, 13, 0, 8 },
+	{ 19200000, 600000000, 500, 16, 0, 6 },
+	{ 26000000, 600000000, 600, 26, 0, 8 },
 	{ 0, 0, 0, 0, 0, 0 },
 };
 
 static struct tegra_clk_pll_freq_table pll_m_freq_table[] = {
-	{ 12000000, 666000000, 666, 12, 1, 8},
-	{ 13000000, 666000000, 666, 13, 1, 8},
-	{ 19200000, 666000000, 555, 16, 1, 8},
-	{ 26000000, 666000000, 666, 26, 1, 8},
-	{ 12000000, 600000000, 600, 12, 1, 8},
-	{ 13000000, 600000000, 600, 13, 1, 8},
-	{ 19200000, 600000000, 375, 12, 1, 6},
-	{ 26000000, 600000000, 600, 26, 1, 8},
+	{ 12000000, 666000000, 666, 12, 0, 8},
+	{ 13000000, 666000000, 666, 13, 0, 8},
+	{ 19200000, 666000000, 555, 16, 0, 8},
+	{ 26000000, 666000000, 666, 26, 0, 8},
+	{ 12000000, 600000000, 600, 12, 0, 8},
+	{ 13000000, 600000000, 600, 13, 0, 8},
+	{ 19200000, 600000000, 375, 12, 0, 6},
+	{ 26000000, 600000000, 600, 26, 0, 8},
 	{ 0, 0, 0, 0, 0, 0 },
 };
 
 static struct tegra_clk_pll_freq_table pll_p_freq_table[] = {
-	{ 12000000, 216000000, 432, 12, 2, 8},
-	{ 13000000, 216000000, 432, 13, 2, 8},
-	{ 19200000, 216000000, 90,   4, 2, 1},
-	{ 26000000, 216000000, 432, 26, 2, 8},
-	{ 12000000, 432000000, 432, 12, 1, 8},
-	{ 13000000, 432000000, 432, 13, 1, 8},
-	{ 19200000, 432000000, 90,   4, 1, 1},
-	{ 26000000, 432000000, 432, 26, 1, 8},
+	{ 12000000, 216000000, 432, 12, 1, 8},
+	{ 13000000, 216000000, 432, 13, 1, 8},
+	{ 19200000, 216000000, 90,   4, 1, 1},
+	{ 26000000, 216000000, 432, 26, 1, 8},
+	{ 12000000, 432000000, 432, 12, 0, 8},
+	{ 13000000, 432000000, 432, 13, 0, 8},
+	{ 19200000, 432000000, 90,   4, 0, 1},
+	{ 26000000, 432000000, 432, 26, 0, 8},
 	{ 0, 0, 0, 0, 0, 0 },
 };
 
 static struct tegra_clk_pll_freq_table pll_a_freq_table[] = {
-	{ 28800000, 56448000, 49, 25, 1, 1},
-	{ 28800000, 73728000, 64, 25, 1, 1},
-	{ 28800000, 24000000,  5,  6, 1, 1},
+	{ 28800000, 56448000, 49, 25, 0, 1},
+	{ 28800000, 73728000, 64, 25, 0, 1},
+	{ 28800000, 24000000,  5,  6, 0, 1},
 	{ 0, 0, 0, 0, 0, 0 },
 };
 
 static struct tegra_clk_pll_freq_table pll_d_freq_table[] = {
-	{ 12000000, 216000000, 216, 12, 1, 4},
-	{ 13000000, 216000000, 216, 13, 1, 4},
-	{ 19200000, 216000000, 135, 12, 1, 3},
-	{ 26000000, 216000000, 216, 26, 1, 4},
+	{ 12000000, 216000000, 216, 12, 0, 4},
+	{ 13000000, 216000000, 216, 13, 0, 4},
+	{ 19200000, 216000000, 135, 12, 0, 3},
+	{ 26000000, 216000000, 216, 26, 0, 4},
 
-	{ 12000000, 594000000, 594, 12, 1, 8},
-	{ 13000000, 594000000, 594, 13, 1, 8},
-	{ 19200000, 594000000, 495, 16, 1, 8},
-	{ 26000000, 594000000, 594, 26, 1, 8},
+	{ 12000000, 594000000, 594, 12, 0, 8},
+	{ 13000000, 594000000, 594, 13, 0, 8},
+	{ 19200000, 594000000, 495, 16, 0, 8},
+	{ 26000000, 594000000, 594, 26, 0, 8},
 
-	{ 12000000, 1000000000, 1000, 12, 1, 12},
-	{ 13000000, 1000000000, 1000, 13, 1, 12},
-	{ 19200000, 1000000000, 625,  12, 1, 8},
-	{ 26000000, 1000000000, 1000, 26, 1, 12},
+	{ 12000000, 1000000000, 1000, 12, 0, 12},
+	{ 13000000, 1000000000, 1000, 13, 0, 12},
+	{ 19200000, 1000000000, 625,  12, 0, 8},
+	{ 26000000, 1000000000, 1000, 26, 0, 12},
 
 	{ 0, 0, 0, 0, 0, 0 },
 };
 
 static struct tegra_clk_pll_freq_table pll_u_freq_table[] = {
-	{ 12000000, 480000000, 960, 12, 2, 0},
-	{ 13000000, 480000000, 960, 13, 2, 0},
-	{ 19200000, 480000000, 200, 4,  2, 0},
-	{ 26000000, 480000000, 960, 26, 2, 0},
+	{ 12000000, 480000000, 960, 12, 0, 0},
+	{ 13000000, 480000000, 960, 13, 0, 0},
+	{ 19200000, 480000000, 200, 4,  0, 0},
+	{ 26000000, 480000000, 960, 26, 0, 0},
 	{ 0, 0, 0, 0, 0, 0 },
 };
 
 static struct tegra_clk_pll_freq_table pll_x_freq_table[] = {
 	/* 1 GHz */
-	{ 12000000, 1000000000, 1000, 12, 1, 12},
-	{ 13000000, 1000000000, 1000, 13, 1, 12},
-	{ 19200000, 1000000000, 625,  12, 1, 8},
-	{ 26000000, 1000000000, 1000, 26, 1, 12},
+	{ 12000000, 1000000000, 1000, 12, 0, 12},
+	{ 13000000, 1000000000, 1000, 13, 0, 12},
+	{ 19200000, 1000000000, 625,  12, 0, 8},
+	{ 26000000, 1000000000, 1000, 26, 0, 12},
 
 	/* 912 MHz */
-	{ 12000000, 912000000,  912,  12, 1, 12},
-	{ 13000000, 912000000,  912,  13, 1, 12},
-	{ 19200000, 912000000,  760,  16, 1, 8},
-	{ 26000000, 912000000,  912,  26, 1, 12},
+	{ 12000000, 912000000,  912,  12, 0, 12},
+	{ 13000000, 912000000,  912,  13, 0, 12},
+	{ 19200000, 912000000,  760,  16, 0, 8},
+	{ 26000000, 912000000,  912,  26, 0, 12},
 
 	/* 816 MHz */
-	{ 12000000, 816000000,  816,  12, 1, 12},
-	{ 13000000, 816000000,  816,  13, 1, 12},
-	{ 19200000, 816000000,  680,  16, 1, 8},
-	{ 26000000, 816000000,  816,  26, 1, 12},
+	{ 12000000, 816000000,  816,  12, 0, 12},
+	{ 13000000, 816000000,  816,  13, 0, 12},
+	{ 19200000, 816000000,  680,  16, 0, 8},
+	{ 26000000, 816000000,  816,  26, 0, 12},
 
 	/* 760 MHz */
-	{ 12000000, 760000000,  760,  12, 1, 12},
-	{ 13000000, 760000000,  760,  13, 1, 12},
-	{ 19200000, 760000000,  950,  24, 1, 8},
-	{ 26000000, 760000000,  760,  26, 1, 12},
+	{ 12000000, 760000000,  760,  12, 0, 12},
+	{ 13000000, 760000000,  760,  13, 0, 12},
+	{ 19200000, 760000000,  950,  24, 0, 8},
+	{ 26000000, 760000000,  760,  26, 0, 12},
 
 	/* 750 MHz */
-	{ 12000000, 750000000,  750,  12, 1, 12},
-	{ 13000000, 750000000,  750,  13, 1, 12},
-	{ 19200000, 750000000,  625,  16, 1, 8},
-	{ 26000000, 750000000,  750,  26, 1, 12},
+	{ 12000000, 750000000,  750,  12, 0, 12},
+	{ 13000000, 750000000,  750,  13, 0, 12},
+	{ 19200000, 750000000,  625,  16, 0, 8},
+	{ 26000000, 750000000,  750,  26, 0, 12},
 
 	/* 608 MHz */
-	{ 12000000, 608000000,  608,  12, 1, 12},
-	{ 13000000, 608000000,  608,  13, 1, 12},
-	{ 19200000, 608000000,  380,  12, 1, 8},
-	{ 26000000, 608000000,  608,  26, 1, 12},
+	{ 12000000, 608000000,  608,  12, 0, 12},
+	{ 13000000, 608000000,  608,  13, 0, 12},
+	{ 19200000, 608000000,  380,  12, 0, 8},
+	{ 26000000, 608000000,  608,  26, 0, 12},
 
 	/* 456 MHz */
-	{ 12000000, 456000000,  456,  12, 1, 12},
-	{ 13000000, 456000000,  456,  13, 1, 12},
-	{ 19200000, 456000000,  380,  16, 1, 8},
-	{ 26000000, 456000000,  456,  26, 1, 12},
+	{ 12000000, 456000000,  456,  12, 0, 12},
+	{ 13000000, 456000000,  456,  13, 0, 12},
+	{ 19200000, 456000000,  380,  16, 0, 8},
+	{ 26000000, 456000000,  456,  26, 0, 12},
 
 	/* 312 MHz */
-	{ 12000000, 312000000,  312,  12, 1, 12},
-	{ 13000000, 312000000,  312,  13, 1, 12},
-	{ 19200000, 312000000,  260,  16, 1, 8},
-	{ 26000000, 312000000,  312,  26, 1, 12},
+	{ 12000000, 312000000,  312,  12, 0, 12},
+	{ 13000000, 312000000,  312,  13, 0, 12},
+	{ 19200000, 312000000,  260,  16, 0, 8},
+	{ 26000000, 312000000,  312,  26, 0, 12},
 
 	{ 0, 0, 0, 0, 0, 0 },
 };
 
 static struct tegra_clk_pll_freq_table pll_e_freq_table[] = {
-	{ 12000000, 100000000,  200,  24, 1, 0 },
+	{ 12000000, 100000000,  200,  24, 0, 0 },
 	{ 0, 0, 0, 0, 0, 0 },
 };
 
diff --git a/drivers/clk/tegra/clk-tegra30.c b/drivers/clk/tegra/clk-tegra30.c
index 2d2b972..a7b955c 100644
--- a/drivers/clk/tegra/clk-tegra30.c
+++ b/drivers/clk/tegra/clk-tegra30.c
@@ -374,164 +374,164 @@ static const struct utmi_clk_param utmi_parameters[] = {
 };
 
 static struct tegra_clk_pll_freq_table pll_c_freq_table[] = {
-	{ 12000000, 1040000000, 520,  6, 1, 8},
-	{ 13000000, 1040000000, 480,  6, 1, 8},
-	{ 16800000, 1040000000, 495,  8, 1, 8},	/* actual: 1039.5 MHz */
-	{ 19200000, 1040000000, 325,  6, 1, 6},
-	{ 26000000, 1040000000, 520, 13, 1, 8},
-
-	{ 12000000, 832000000, 416,  6, 1, 8},
-	{ 13000000, 832000000, 832, 13, 1, 8},
-	{ 16800000, 832000000, 396,  8, 1, 8},	/* actual: 831.6 MHz */
-	{ 19200000, 832000000, 260,  6, 1, 8},
-	{ 26000000, 832000000, 416, 13, 1, 8},
-
-	{ 12000000, 624000000, 624, 12, 1, 8},
-	{ 13000000, 624000000, 624, 13, 1, 8},
-	{ 16800000, 600000000, 520, 14, 1, 8},
-	{ 19200000, 624000000, 520, 16, 1, 8},
-	{ 26000000, 624000000, 624, 26, 1, 8},
-
-	{ 12000000, 600000000, 600, 12, 1, 8},
-	{ 13000000, 600000000, 600, 13, 1, 8},
-	{ 16800000, 600000000, 500, 14, 1, 8},
-	{ 19200000, 600000000, 375, 12, 1, 6},
-	{ 26000000, 600000000, 600, 26, 1, 8},
-
-	{ 12000000, 520000000, 520, 12, 1, 8},
-	{ 13000000, 520000000, 520, 13, 1, 8},
-	{ 16800000, 520000000, 495, 16, 1, 8},	/* actual: 519.75 MHz */
-	{ 19200000, 520000000, 325, 12, 1, 6},
-	{ 26000000, 520000000, 520, 26, 1, 8},
-
-	{ 12000000, 416000000, 416, 12, 1, 8},
-	{ 13000000, 416000000, 416, 13, 1, 8},
-	{ 16800000, 416000000, 396, 16, 1, 8},	/* actual: 415.8 MHz */
-	{ 19200000, 416000000, 260, 12, 1, 6},
-	{ 26000000, 416000000, 416, 26, 1, 8},
+	{ 12000000, 1040000000, 520,  6, 0, 8},
+	{ 13000000, 1040000000, 480,  6, 0, 8},
+	{ 16800000, 1040000000, 495,  8, 0, 8},	/* actual: 1039.5 MHz */
+	{ 19200000, 1040000000, 325,  6, 0, 6},
+	{ 26000000, 1040000000, 520, 13, 0, 8},
+
+	{ 12000000, 832000000, 416,  6, 0, 8},
+	{ 13000000, 832000000, 832, 13, 0, 8},
+	{ 16800000, 832000000, 396,  8, 0, 8},	/* actual: 831.6 MHz */
+	{ 19200000, 832000000, 260,  6, 0, 8},
+	{ 26000000, 832000000, 416, 13, 0, 8},
+
+	{ 12000000, 624000000, 624, 12, 0, 8},
+	{ 13000000, 624000000, 624, 13, 0, 8},
+	{ 16800000, 600000000, 520, 14, 0, 8},
+	{ 19200000, 624000000, 520, 16, 0, 8},
+	{ 26000000, 624000000, 624, 26, 0, 8},
+
+	{ 12000000, 600000000, 600, 12, 0, 8},
+	{ 13000000, 600000000, 600, 13, 0, 8},
+	{ 16800000, 600000000, 500, 14, 0, 8},
+	{ 19200000, 600000000, 375, 12, 0, 6},
+	{ 26000000, 600000000, 600, 26, 0, 8},
+
+	{ 12000000, 520000000, 520, 12, 0, 8},
+	{ 13000000, 520000000, 520, 13, 0, 8},
+	{ 16800000, 520000000, 495, 16, 0, 8},	/* actual: 519.75 MHz */
+	{ 19200000, 520000000, 325, 12, 0, 6},
+	{ 26000000, 520000000, 520, 26, 0, 8},
+
+	{ 12000000, 416000000, 416, 12, 0, 8},
+	{ 13000000, 416000000, 416, 13, 0, 8},
+	{ 16800000, 416000000, 396, 16, 0, 8},	/* actual: 415.8 MHz */
+	{ 19200000, 416000000, 260, 12, 0, 6},
+	{ 26000000, 416000000, 416, 26, 0, 8},
 	{ 0, 0, 0, 0, 0, 0 },
 };
 
 static struct tegra_clk_pll_freq_table pll_m_freq_table[] = {
-	{ 12000000, 666000000, 666, 12, 1, 8},
-	{ 13000000, 666000000, 666, 13, 1, 8},
-	{ 16800000, 666000000, 555, 14, 1, 8},
-	{ 19200000, 666000000, 555, 16, 1, 8},
-	{ 26000000, 666000000, 666, 26, 1, 8},
-	{ 12000000, 600000000, 600, 12, 1, 8},
-	{ 13000000, 600000000, 600, 13, 1, 8},
-	{ 16800000, 600000000, 500, 14, 1, 8},
-	{ 19200000, 600000000, 375, 12, 1, 6},
-	{ 26000000, 600000000, 600, 26, 1, 8},
+	{ 12000000, 666000000, 666, 12, 0, 8},
+	{ 13000000, 666000000, 666, 13, 0, 8},
+	{ 16800000, 666000000, 555, 14, 0, 8},
+	{ 19200000, 666000000, 555, 16, 0, 8},
+	{ 26000000, 666000000, 666, 26, 0, 8},
+	{ 12000000, 600000000, 600, 12, 0, 8},
+	{ 13000000, 600000000, 600, 13, 0, 8},
+	{ 16800000, 600000000, 500, 14, 0, 8},
+	{ 19200000, 600000000, 375, 12, 0, 6},
+	{ 26000000, 600000000, 600, 26, 0, 8},
 	{ 0, 0, 0, 0, 0, 0 },
 };
 
 static struct tegra_clk_pll_freq_table pll_p_freq_table[] = {
-	{ 12000000, 216000000, 432, 12, 2, 8},
-	{ 13000000, 216000000, 432, 13, 2, 8},
-	{ 16800000, 216000000, 360, 14, 2, 8},
-	{ 19200000, 216000000, 360, 16, 2, 8},
-	{ 26000000, 216000000, 432, 26, 2, 8},
+	{ 12000000, 216000000, 432, 12, 1, 8},
+	{ 13000000, 216000000, 432, 13, 1, 8},
+	{ 16800000, 216000000, 360, 14, 1, 8},
+	{ 19200000, 216000000, 360, 16, 1, 8},
+	{ 26000000, 216000000, 432, 26, 1, 8},
 	{ 0, 0, 0, 0, 0, 0 },
 };
 
 static struct tegra_clk_pll_freq_table pll_a_freq_table[] = {
-	{ 9600000, 564480000, 294, 5, 1, 4},
-	{ 9600000, 552960000, 288, 5, 1, 4},
-	{ 9600000, 24000000,  5,   2, 1, 1},
+	{ 9600000, 564480000, 294, 5, 0, 4},
+	{ 9600000, 552960000, 288, 5, 0, 4},
+	{ 9600000, 24000000,  5,   2, 0, 1},
 
-	{ 28800000, 56448000, 49, 25, 1, 1},
-	{ 28800000, 73728000, 64, 25, 1, 1},
-	{ 28800000, 24000000,  5,  6, 1, 1},
+	{ 28800000, 56448000, 49, 25, 0, 1},
+	{ 28800000, 73728000, 64, 25, 0, 1},
+	{ 28800000, 24000000,  5,  6, 0, 1},
 	{ 0, 0, 0, 0, 0, 0 },
 };
 
 static struct tegra_clk_pll_freq_table pll_d_freq_table[] = {
-	{ 12000000, 216000000, 216, 12, 1, 4},
-	{ 13000000, 216000000, 216, 13, 1, 4},
-	{ 16800000, 216000000, 180, 14, 1, 4},
-	{ 19200000, 216000000, 180, 16, 1, 4},
-	{ 26000000, 216000000, 216, 26, 1, 4},
-
-	{ 12000000, 594000000, 594, 12, 1, 8},
-	{ 13000000, 594000000, 594, 13, 1, 8},
-	{ 16800000, 594000000, 495, 14, 1, 8},
-	{ 19200000, 594000000, 495, 16, 1, 8},
-	{ 26000000, 594000000, 594, 26, 1, 8},
-
-	{ 12000000, 1000000000, 1000, 12, 1, 12},
-	{ 13000000, 1000000000, 1000, 13, 1, 12},
-	{ 19200000, 1000000000, 625,  12, 1, 8},
-	{ 26000000, 1000000000, 1000, 26, 1, 12},
+	{ 12000000, 216000000, 216, 12, 0, 4},
+	{ 13000000, 216000000, 216, 13, 0, 4},
+	{ 16800000, 216000000, 180, 14, 0, 4},
+	{ 19200000, 216000000, 180, 16, 0, 4},
+	{ 26000000, 216000000, 216, 26, 0, 4},
+
+	{ 12000000, 594000000, 594, 12, 0, 8},
+	{ 13000000, 594000000, 594, 13, 0, 8},
+	{ 16800000, 594000000, 495, 14, 0, 8},
+	{ 19200000, 594000000, 495, 16, 0, 8},
+	{ 26000000, 594000000, 594, 26, 0, 8},
+
+	{ 12000000, 1000000000, 1000, 12, 0, 12},
+	{ 13000000, 1000000000, 1000, 13, 0, 12},
+	{ 19200000, 1000000000, 625,  12, 0, 8},
+	{ 26000000, 1000000000, 1000, 26, 0, 12},
 
 	{ 0, 0, 0, 0, 0, 0 },
 };
 
 static struct tegra_clk_pll_freq_table pll_u_freq_table[] = {
-	{ 12000000, 480000000, 960, 12, 2, 12},
-	{ 13000000, 480000000, 960, 13, 2, 12},
-	{ 16800000, 480000000, 400, 7,  2, 5},
-	{ 19200000, 480000000, 200, 4,  2, 3},
-	{ 26000000, 480000000, 960, 26, 2, 12},
+	{ 12000000, 480000000, 960, 12, 0, 12},
+	{ 13000000, 480000000, 960, 13, 0, 12},
+	{ 16800000, 480000000, 400, 7,  0, 5},
+	{ 19200000, 480000000, 200, 4,  0, 3},
+	{ 26000000, 480000000, 960, 26, 0, 12},
 	{ 0, 0, 0, 0, 0, 0 },
 };
 
 static struct tegra_clk_pll_freq_table pll_x_freq_table[] = {
 	/* 1.7 GHz */
-	{ 12000000, 1700000000, 850,  6,  1, 8},
-	{ 13000000, 1700000000, 915,  7,  1, 8},	/* actual: 1699.2 MHz */
-	{ 16800000, 1700000000, 708,  7,  1, 8},	/* actual: 1699.2 MHz */
-	{ 19200000, 1700000000, 885,  10, 1, 8},	/* actual: 1699.2 MHz */
-	{ 26000000, 1700000000, 850,  13, 1, 8},
+	{ 12000000, 1700000000, 850,  6,  0, 8},
+	{ 13000000, 1700000000, 915,  7,  0, 8},	/* actual: 1699.2 MHz */
+	{ 16800000, 1700000000, 708,  7,  0, 8},	/* actual: 1699.2 MHz */
+	{ 19200000, 1700000000, 885,  10, 0, 8},	/* actual: 1699.2 MHz */
+	{ 26000000, 1700000000, 850,  13, 0, 8},
 
 	/* 1.6 GHz */
-	{ 12000000, 1600000000, 800,  6,  1, 8},
-	{ 13000000, 1600000000, 738,  6,  1, 8},	/* actual: 1599.0 MHz */
-	{ 16800000, 1600000000, 857,  9,  1, 8},	/* actual: 1599.7 MHz */
-	{ 19200000, 1600000000, 500,  6,  1, 8},
-	{ 26000000, 1600000000, 800,  13, 1, 8},
+	{ 12000000, 1600000000, 800,  6,  0, 8},
+	{ 13000000, 1600000000, 738,  6,  0, 8},	/* actual: 1599.0 MHz */
+	{ 16800000, 1600000000, 857,  9,  0, 8},	/* actual: 1599.7 MHz */
+	{ 19200000, 1600000000, 500,  6,  0, 8},
+	{ 26000000, 1600000000, 800,  13, 0, 8},
 
 	/* 1.5 GHz */
-	{ 12000000, 1500000000, 750,  6,  1, 8},
-	{ 13000000, 1500000000, 923,  8,  1, 8},	/* actual: 1499.8 MHz */
-	{ 16800000, 1500000000, 625,  7,  1, 8},
-	{ 19200000, 1500000000, 625,  8,  1, 8},
-	{ 26000000, 1500000000, 750,  13, 1, 8},
+	{ 12000000, 1500000000, 750,  6,  0, 8},
+	{ 13000000, 1500000000, 923,  8,  0, 8},	/* actual: 1499.8 MHz */
+	{ 16800000, 1500000000, 625,  7,  0, 8},
+	{ 19200000, 1500000000, 625,  8,  0, 8},
+	{ 26000000, 1500000000, 750,  13, 0, 8},
 
 	/* 1.4 GHz */
-	{ 12000000, 1400000000, 700,  6,  1, 8},
-	{ 13000000, 1400000000, 969,  9,  1, 8},	/* actual: 1399.7 MHz */
-	{ 16800000, 1400000000, 1000, 12, 1, 8},
-	{ 19200000, 1400000000, 875,  12, 1, 8},
-	{ 26000000, 1400000000, 700,  13, 1, 8},
+	{ 12000000, 1400000000, 700,  6,  0, 8},
+	{ 13000000, 1400000000, 969,  9,  0, 8},	/* actual: 1399.7 MHz */
+	{ 16800000, 1400000000, 1000, 12, 0, 8},
+	{ 19200000, 1400000000, 875,  12, 0, 8},
+	{ 26000000, 1400000000, 700,  13, 0, 8},
 
 	/* 1.3 GHz */
-	{ 12000000, 1300000000, 975,  9,  1, 8},
-	{ 13000000, 1300000000, 1000, 10, 1, 8},
-	{ 16800000, 1300000000, 928,  12, 1, 8},	/* actual: 1299.2 MHz */
-	{ 19200000, 1300000000, 812,  12, 1, 8},	/* actual: 1299.2 MHz */
-	{ 26000000, 1300000000, 650,  13, 1, 8},
+	{ 12000000, 1300000000, 975,  9,  0, 8},
+	{ 13000000, 1300000000, 1000, 10, 0, 8},
+	{ 16800000, 1300000000, 928,  12, 0, 8},	/* actual: 1299.2 MHz */
+	{ 19200000, 1300000000, 812,  12, 0, 8},	/* actual: 1299.2 MHz */
+	{ 26000000, 1300000000, 650,  13, 0, 8},
 
 	/* 1.2 GHz */
-	{ 12000000, 1200000000, 1000, 10, 1, 8},
-	{ 13000000, 1200000000, 923,  10, 1, 8},	/* actual: 1199.9 MHz */
-	{ 16800000, 1200000000, 1000, 14, 1, 8},
-	{ 19200000, 1200000000, 1000, 16, 1, 8},
-	{ 26000000, 1200000000, 600,  13, 1, 8},
+	{ 12000000, 1200000000, 1000, 10, 0, 8},
+	{ 13000000, 1200000000, 923,  10, 0, 8},	/* actual: 1199.9 MHz */
+	{ 16800000, 1200000000, 1000, 14, 0, 8},
+	{ 19200000, 1200000000, 1000, 16, 0, 8},
+	{ 26000000, 1200000000, 600,  13, 0, 8},
 
 	/* 1.1 GHz */
-	{ 12000000, 1100000000, 825,  9,  1, 8},
-	{ 13000000, 1100000000, 846,  10, 1, 8},	/* actual: 1099.8 MHz */
-	{ 16800000, 1100000000, 982,  15, 1, 8},	/* actual: 1099.8 MHz */
-	{ 19200000, 1100000000, 859,  15, 1, 8},	/* actual: 1099.5 MHz */
-	{ 26000000, 1100000000, 550,  13, 1, 8},
+	{ 12000000, 1100000000, 825,  9,  0, 8},
+	{ 13000000, 1100000000, 846,  10, 0, 8},	/* actual: 1099.8 MHz */
+	{ 16800000, 1100000000, 982,  15, 0, 8},	/* actual: 1099.8 MHz */
+	{ 19200000, 1100000000, 859,  15, 0, 8},	/* actual: 1099.5 MHz */
+	{ 26000000, 1100000000, 550,  13, 0, 8},
 
 	/* 1 GHz */
-	{ 12000000, 1000000000, 1000, 12, 1, 8},
-	{ 13000000, 1000000000, 1000, 13, 1, 8},
-	{ 16800000, 1000000000, 833,  14, 1, 8},	/* actual: 999.6 MHz */
-	{ 19200000, 1000000000, 625,  12, 1, 8},
-	{ 26000000, 1000000000, 1000, 26, 1, 8},
+	{ 12000000, 1000000000, 1000, 12, 0, 8},
+	{ 13000000, 1000000000, 1000, 13, 0, 8},
+	{ 16800000, 1000000000, 833,  14, 0, 8},	/* actual: 999.6 MHz */
+	{ 19200000, 1000000000, 625,  12, 0, 8},
+	{ 26000000, 1000000000, 1000, 26, 0, 8},
 
 	{ 0, 0, 0, 0, 0, 0 },
 };
diff --git a/drivers/clk/tegra/clk.h b/drivers/clk/tegra/clk.h
index 3c566e2..b9691dd 100644
--- a/drivers/clk/tegra/clk.h
+++ b/drivers/clk/tegra/clk.h
@@ -182,12 +182,14 @@ struct tegra_clk_pll_params {
  * TEGRA_PLL_FIXED - We are not supposed to change output frequency
  *     of some plls.
  * TEGRA_PLLE_CONFIGURE - Configure PLLE when enabling.
+ * TEGRA_PLL_LOCK_MISC - Lock bit is in the misc register instead of the
+ *     base register.
  */
 struct tegra_clk_pll {
 	struct clk_hw	hw;
 	void __iomem	*clk_base;
 	void __iomem	*pmc;
-	u8		flags;
+	u32		flags;
 	unsigned long	fixed_rate;
 	spinlock_t	*lock;
 	u8		divn_shift;
@@ -210,18 +212,19 @@ struct tegra_clk_pll {
 #define TEGRA_PLLM BIT(5)
 #define TEGRA_PLL_FIXED BIT(6)
 #define TEGRA_PLLE_CONFIGURE BIT(7)
+#define TEGRA_PLL_LOCK_MISC BIT(8)
 
 extern const struct clk_ops tegra_clk_pll_ops;
 extern const struct clk_ops tegra_clk_plle_ops;
 struct clk *tegra_clk_register_pll(const char *name, const char *parent_name,
 		void __iomem *clk_base, void __iomem *pmc,
 		unsigned long flags, unsigned long fixed_rate,
-		struct tegra_clk_pll_params *pll_params, u8 pll_flags,
+		struct tegra_clk_pll_params *pll_params, u32 pll_flags,
 		struct tegra_clk_pll_freq_table *freq_table, spinlock_t *lock);
 struct clk *tegra_clk_register_plle(const char *name, const char *parent_name,
 		void __iomem *clk_base, void __iomem *pmc,
 		unsigned long flags, unsigned long fixed_rate,
-		struct tegra_clk_pll_params *pll_params, u8 pll_flags,
+		struct tegra_clk_pll_params *pll_params, u32 pll_flags,
 		struct tegra_clk_pll_freq_table *freq_table, spinlock_t *lock);
 
 /**
-- 
1.7.7.rc0.72.g4b5ea.dirty



From thierry.reding at avionic-design.de  Wed Apr  3 10:45:07 2013
From: thierry.reding at avionic-design.de (Thierry Reding)
Date: Wed,  3 Apr 2013 16:45:07 +0200
Subject: [PATCH v3 01/12] of/pci: Provide support for parsing PCI DT ranges
 property
In-Reply-To: <1365000318-28256-1-git-send-email-thierry.reding@avionic-design.de>
References: <1365000318-28256-1-git-send-email-thierry.reding@avionic-design.de>
Message-ID: <1365000318-28256-2-git-send-email-thierry.reding@avionic-design.de>

From: Andrew Murray <Andrew.Murray at arm.com>

This patch factors out common implementation patterns to reduce overall kernel
code and provide a means for host bridge drivers to directly obtain struct
resources from the DT's ranges property without relying on architecture specific
DT handling. This will make it easier to write archiecture independent host bridge
drivers and mitigate against further duplication of DT parsing code.

This patch can be used in the following way:

	struct of_pci_range_parser parser;
	struct of_pci_range range;

	if (of_pci_range_parser(&parser, np))
		; //no ranges property

	for_each_of_pci_range(&parser, &range) {

		/*
			directly access properties of the address range, e.g.:
			range.pci_space, range.pci_addr, range.cpu_addr,
			range.size, range.flags

			alternatively obtain a struct resource, e.g.:
			struct resource res;
			of_pci_range_to_resource(&range, np, &res);
		*/
	}

Additionally the implementation takes care of adjacent ranges and merges them
into a single range (as was the case with powerpc and microblaze).

The modifications to microblaze, mips and powerpc have not been tested.

Signed-off-by: Andrew Murray <Andrew.Murray at arm.com>
Signed-off-by: Liviu Dudau <Liviu.Dudau at arm.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Signed-off-by: Thierry Reding <thierry.reding at avionic-design.de>
---
 arch/microblaze/pci/pci-common.c | 110 ++++++++++++++-------------------------
 arch/mips/pci/pci.c              |  50 ++++++------------
 arch/powerpc/kernel/pci-common.c |  99 ++++++++++++-----------------------
 drivers/of/address.c             |  63 ++++++++++++++++++++++
 include/linux/of_address.h       |  42 +++++++++++++++
 5 files changed, 194 insertions(+), 170 deletions(-)

diff --git a/arch/microblaze/pci/pci-common.c b/arch/microblaze/pci/pci-common.c
index bdb8ea1..11dd9ac 100644
--- a/arch/microblaze/pci/pci-common.c
+++ b/arch/microblaze/pci/pci-common.c
@@ -657,67 +657,43 @@ void pci_resource_to_user(const struct pci_dev *dev, int bar,
 void pci_process_bridge_OF_ranges(struct pci_controller *hose,
 				  struct device_node *dev, int primary)
 {
-	const u32 *ranges;
-	int rlen;
-	int pna = of_n_addr_cells(dev);
-	int np = pna + 5;
 	int memno = 0, isa_hole = -1;
-	u32 pci_space;
-	unsigned long long pci_addr, cpu_addr, pci_next, cpu_next, size;
 	unsigned long long isa_mb = 0;
 	struct resource *res;
+	struct of_pci_range range;
+	struct of_pci_range_parser parser;
+	u32 res_type;
 
 	pr_info("PCI host bridge %s %s ranges:\n",
 	       dev->full_name, primary ? "(primary)" : "");
 
-	/* Get ranges property */
-	ranges = of_get_property(dev, "ranges", &rlen);
-	if (ranges == NULL)
+	/* Check for ranges property */
+	if (of_pci_range_parser(&parser, dev))
 		return;
 
-	/* Parse it */
 	pr_debug("Parsing ranges property...\n");
-	while ((rlen -= np * 4) >= 0) {
+	for_each_of_pci_range(&parser, &range) {
 		/* Read next ranges element */
-		pci_space = ranges[0];
-		pci_addr = of_read_number(ranges + 1, 2);
-		cpu_addr = of_translate_address(dev, ranges + 3);
-		size = of_read_number(ranges + pna + 3, 2);
-
-		pr_debug("pci_space: 0x%08x pci_addr:0x%016llx ",
-				pci_space, pci_addr);
-		pr_debug("cpu_addr:0x%016llx size:0x%016llx\n",
-					cpu_addr, size);
-
-		ranges += np;
+		pr_debug("pci_space: 0x%08x pci_addr: 0x%016llx ",
+				range.pci_space, range.pci_addr);
+		pr_debug("cpu_addr: 0x%016llx size: 0x%016llx\n",
+				range.cpu_addr, range.size);
 
 		/* If we failed translation or got a zero-sized region
 		 * (some FW try to feed us with non sensical zero sized regions
 		 * such as power3 which look like some kind of attempt
 		 * at exposing the VGA memory hole)
 		 */
-		if (cpu_addr == OF_BAD_ADDR || size == 0)
+		if (range.cpu_addr == OF_BAD_ADDR || range.size == 0)
 			continue;
 
-		/* Now consume following elements while they are contiguous */
-		for (; rlen >= np * sizeof(u32);
-		     ranges += np, rlen -= np * 4) {
-			if (ranges[0] != pci_space)
-				break;
-			pci_next = of_read_number(ranges + 1, 2);
-			cpu_next = of_translate_address(dev, ranges + 3);
-			if (pci_next != pci_addr + size ||
-			    cpu_next != cpu_addr + size)
-				break;
-			size += of_read_number(ranges + pna + 3, 2);
-		}
-
 		/* Act based on address space type */
 		res = NULL;
-		switch ((pci_space >> 24) & 0x3) {
-		case 1:		/* PCI IO space */
+		res_type = range.flags & IORESOURCE_TYPE_BITS;
+		if (res_type == IORESOURCE_IO) {
 			pr_info("  IO 0x%016llx..0x%016llx -> 0x%016llx\n",
-			       cpu_addr, cpu_addr + size - 1, pci_addr);
+				range.cpu_addr, range.cpu_addr + range.size - 1,
+				range.pci_addr);
 
 			/* We support only one IO range */
 			if (hose->pci_io_size) {
@@ -725,11 +701,12 @@ void pci_process_bridge_OF_ranges(struct pci_controller *hose,
 				continue;
 			}
 			/* On 32 bits, limit I/O space to 16MB */
-			if (size > 0x01000000)
-				size = 0x01000000;
+			if (range.size > 0x01000000)
+				range.size = 0x01000000;
 
 			/* 32 bits needs to map IOs here */
-			hose->io_base_virt = ioremap(cpu_addr, size);
+			hose->io_base_virt = ioremap(range.cpu_addr,
+						range.size);
 
 			/* Expect trouble if pci_addr is not 0 */
 			if (primary)
@@ -738,19 +715,18 @@ void pci_process_bridge_OF_ranges(struct pci_controller *hose,
 			/* pci_io_size and io_base_phys always represent IO
 			 * space starting at 0 so we factor in pci_addr
 			 */
-			hose->pci_io_size = pci_addr + size;
-			hose->io_base_phys = cpu_addr - pci_addr;
+			hose->pci_io_size = range.pci_addr + range.size;
+			hose->io_base_phys = range.cpu_addr - range.pci_addr;
 
 			/* Build resource */
 			res = &hose->io_resource;
-			res->flags = IORESOURCE_IO;
-			res->start = pci_addr;
-			break;
-		case 2:		/* PCI Memory space */
-		case 3:		/* PCI 64 bits Memory space */
+			range.cpu_addr = range.pci_addr;
+		} else if (res_type == IORESOURCE_MEM) {
 			pr_info(" MEM 0x%016llx..0x%016llx -> 0x%016llx %s\n",
-			       cpu_addr, cpu_addr + size - 1, pci_addr,
-			       (pci_space & 0x40000000) ? "Prefetch" : "");
+				range.cpu_addr, range.cpu_addr + range.size - 1,
+				range.pci_addr,
+				(range.pci_space & 0x40000000) ?
+				"Prefetch" : "");
 
 			/* We support only 3 memory ranges */
 			if (memno >= 3) {
@@ -758,13 +734,13 @@ void pci_process_bridge_OF_ranges(struct pci_controller *hose,
 				continue;
 			}
 			/* Handles ISA memory hole space here */
-			if (pci_addr == 0) {
+			if (range.pci_addr == 0) {
 				isa_mb = cpu_addr;
 				isa_hole = memno;
 				if (primary || isa_mem_base == 0)
-					isa_mem_base = cpu_addr;
-				hose->isa_mem_phys = cpu_addr;
-				hose->isa_mem_size = size;
+					isa_mem_base = range.cpu_addr;
+				hose->isa_mem_phys = range.cpu_addr;
+				hose->isa_mem_size = range.size;
 			}
 
 			/* We get the PCI/Mem offset from the first range or
@@ -772,30 +748,22 @@ void pci_process_bridge_OF_ranges(struct pci_controller *hose,
 			 * hole. If they don't match, bugger.
 			 */
 			if (memno == 0 ||
-			    (isa_hole >= 0 && pci_addr != 0 &&
+			    (isa_hole >= 0 && range.pci_addr != 0 &&
 			     hose->pci_mem_offset == isa_mb))
-				hose->pci_mem_offset = cpu_addr - pci_addr;
-			else if (pci_addr != 0 &&
-				 hose->pci_mem_offset != cpu_addr - pci_addr) {
+				hose->pci_mem_offset = range.cpu_addr
+							- range.pci_addr;
+			else if (range.pci_addr != 0 &&
+				 hose->pci_mem_offset != range.cpu_addr
+							- range.pci_addr) {
 				pr_info(" \\--> Skipped (offset mismatch) !\n");
 				continue;
 			}
 
 			/* Build resource */
 			res = &hose->mem_resources[memno++];
-			res->flags = IORESOURCE_MEM;
-			if (pci_space & 0x40000000)
-				res->flags |= IORESOURCE_PREFETCH;
-			res->start = cpu_addr;
-			break;
-		}
-		if (res != NULL) {
-			res->name = dev->full_name;
-			res->end = res->start + size - 1;
-			res->parent = NULL;
-			res->sibling = NULL;
-			res->child = NULL;
 		}
+		if (res != NULL)
+			of_pci_range_to_resource(&range, dev, res);
 	}
 
 	/* If there's an ISA hole and the pci_mem_offset is -not- matching
diff --git a/arch/mips/pci/pci.c b/arch/mips/pci/pci.c
index 0872f12..bee49a4 100644
--- a/arch/mips/pci/pci.c
+++ b/arch/mips/pci/pci.c
@@ -122,51 +122,33 @@ static void pcibios_scanbus(struct pci_controller *hose)
 #ifdef CONFIG_OF
 void pci_load_of_ranges(struct pci_controller *hose, struct device_node *node)
 {
-	const __be32 *ranges;
-	int rlen;
-	int pna = of_n_addr_cells(node);
-	int np = pna + 5;
+	struct of_pci_range_range range;
+	struct of_pci_range_parser parser;
+	u32 res_type;
 
 	pr_info("PCI host bridge %s ranges:\n", node->full_name);
-	ranges = of_get_property(node, "ranges", &rlen);
-	if (ranges == NULL)
-		return;
 	hose->of_node = node;
 
-	while ((rlen -= np * 4) >= 0) {
-		u32 pci_space;
+	if (of_pci_range_parser(&parser, node))
+		return;
+
+	for_each_of_pci_range(&parser, &range) {
 		struct resource *res = NULL;
-		u64 addr, size;
-
-		pci_space = be32_to_cpup(&ranges[0]);
-		addr = of_translate_address(node, ranges + 3);
-		size = of_read_number(ranges + pna + 3, 2);
-		ranges += np;
-		switch ((pci_space >> 24) & 0x3) {
-		case 1:		/* PCI IO space */
+
+		res_type = range.flags & IORESOURCE_TYPE_BITS;
+		if (res_type == IORESOURCE_IO) {
 			pr_info("  IO 0x%016llx..0x%016llx\n",
-					addr, addr + size - 1);
+				range.addr, range.addr + range.size - 1);
 			hose->io_map_base =
-				(unsigned long)ioremap(addr, size);
+				(unsigned long)ioremap(range.addr, range.size);
 			res = hose->io_resource;
-			res->flags = IORESOURCE_IO;
-			break;
-		case 2:		/* PCI Memory space */
-		case 3:		/* PCI 64 bits Memory space */
+		} else if (res_type == IORESOURCE_MEM) {
 			pr_info(" MEM 0x%016llx..0x%016llx\n",
-					addr, addr + size - 1);
+				range.addr, range.addr + range.size - 1);
 			res = hose->mem_resource;
-			res->flags = IORESOURCE_MEM;
-			break;
-		}
-		if (res != NULL) {
-			res->start = addr;
-			res->name = node->full_name;
-			res->end = res->start + size - 1;
-			res->parent = NULL;
-			res->sibling = NULL;
-			res->child = NULL;
 		}
+		if (res != NULL)
+			of_pci_range_to_resource(&range, node, res);
 	}
 }
 #endif
diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index fa12ae4..878d530 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -676,61 +676,37 @@ void pci_resource_to_user(const struct pci_dev *dev, int bar,
 void pci_process_bridge_OF_ranges(struct pci_controller *hose,
 				  struct device_node *dev, int primary)
 {
-	const u32 *ranges;
-	int rlen;
-	int pna = of_n_addr_cells(dev);
-	int np = pna + 5;
 	int memno = 0, isa_hole = -1;
-	u32 pci_space;
-	unsigned long long pci_addr, cpu_addr, pci_next, cpu_next, size;
 	unsigned long long isa_mb = 0;
 	struct resource *res;
+	struct of_pci_range range;
+	struct of_pci_range_parser parser;
+	u32 res_type;
 
 	printk(KERN_INFO "PCI host bridge %s %s ranges:\n",
 	       dev->full_name, primary ? "(primary)" : "");
 
-	/* Get ranges property */
-	ranges = of_get_property(dev, "ranges", &rlen);
-	if (ranges == NULL)
+	/* Check for ranges property */
+	if (of_pci_range_parser(&parser, dev))
 		return;
 
-	/* Parse it */
-	while ((rlen -= np * 4) >= 0) {
-		/* Read next ranges element */
-		pci_space = ranges[0];
-		pci_addr = of_read_number(ranges + 1, 2);
-		cpu_addr = of_translate_address(dev, ranges + 3);
-		size = of_read_number(ranges + pna + 3, 2);
-		ranges += np;
-
+	for_each_of_pci_range(&parser, &range) {
 		/* If we failed translation or got a zero-sized region
 		 * (some FW try to feed us with non sensical zero sized regions
 		 * such as power3 which look like some kind of attempt at exposing
 		 * the VGA memory hole)
 		 */
-		if (cpu_addr == OF_BAD_ADDR || size == 0)
+		if (range.cpu_addr == OF_BAD_ADDR || range.size == 0)
 			continue;
 
-		/* Now consume following elements while they are contiguous */
-		for (; rlen >= np * sizeof(u32);
-		     ranges += np, rlen -= np * 4) {
-			if (ranges[0] != pci_space)
-				break;
-			pci_next = of_read_number(ranges + 1, 2);
-			cpu_next = of_translate_address(dev, ranges + 3);
-			if (pci_next != pci_addr + size ||
-			    cpu_next != cpu_addr + size)
-				break;
-			size += of_read_number(ranges + pna + 3, 2);
-		}
-
 		/* Act based on address space type */
 		res = NULL;
-		switch ((pci_space >> 24) & 0x3) {
-		case 1:		/* PCI IO space */
+		res_type = range.flags & IORESOURCE_TYPE_BITS;
+		if (res_type == IORESOURCE_IO) {
 			printk(KERN_INFO
 			       "  IO 0x%016llx..0x%016llx -> 0x%016llx\n",
-			       cpu_addr, cpu_addr + size - 1, pci_addr);
+				range.cpu_addr, range.cpu_addr + range.size - 1,
+				range.pci_addr);
 
 			/* We support only one IO range */
 			if (hose->pci_io_size) {
@@ -740,11 +716,12 @@ void pci_process_bridge_OF_ranges(struct pci_controller *hose,
 			}
 #ifdef CONFIG_PPC32
 			/* On 32 bits, limit I/O space to 16MB */
-			if (size > 0x01000000)
-				size = 0x01000000;
+			if (range.size > 0x01000000)
+				range.size = 0x01000000;
 
 			/* 32 bits needs to map IOs here */
-			hose->io_base_virt = ioremap(cpu_addr, size);
+			hose->io_base_virt = ioremap(range.cpu_addr,
+						range.size);
 
 			/* Expect trouble if pci_addr is not 0 */
 			if (primary)
@@ -754,20 +731,19 @@ void pci_process_bridge_OF_ranges(struct pci_controller *hose,
 			/* pci_io_size and io_base_phys always represent IO
 			 * space starting at 0 so we factor in pci_addr
 			 */
-			hose->pci_io_size = pci_addr + size;
-			hose->io_base_phys = cpu_addr - pci_addr;
+			hose->pci_io_size = range.pci_addr + range.size;
+			hose->io_base_phys = range.cpu_addr - range.pci_addr;
 
 			/* Build resource */
 			res = &hose->io_resource;
-			res->flags = IORESOURCE_IO;
-			res->start = pci_addr;
-			break;
-		case 2:		/* PCI Memory space */
-		case 3:		/* PCI 64 bits Memory space */
+			range.cpu_addr = range.pci_addr;
+		} else if (res_type == IORESOURCE_MEM) {
 			printk(KERN_INFO
 			       " MEM 0x%016llx..0x%016llx -> 0x%016llx %s\n",
-			       cpu_addr, cpu_addr + size - 1, pci_addr,
-			       (pci_space & 0x40000000) ? "Prefetch" : "");
+				range.cpu_addr, range.cpu_addr + range.size - 1,
+				range.pci_addr,
+				(range.pci_space & 0x40000000) ?
+				"Prefetch" : "");
 
 			/* We support only 3 memory ranges */
 			if (memno >= 3) {
@@ -776,13 +752,13 @@ void pci_process_bridge_OF_ranges(struct pci_controller *hose,
 				continue;
 			}
 			/* Handles ISA memory hole space here */
-			if (pci_addr == 0) {
+			if (range.pci_addr == 0) {
 				isa_mb = cpu_addr;
 				isa_hole = memno;
 				if (primary || isa_mem_base == 0)
-					isa_mem_base = cpu_addr;
-				hose->isa_mem_phys = cpu_addr;
-				hose->isa_mem_size = size;
+					isa_mem_base = range.cpu_addr;
+				hose->isa_mem_phys = range.cpu_addr;
+				hose->isa_mem_size = range.size;
 			}
 
 			/* We get the PCI/Mem offset from the first range or
@@ -790,11 +766,13 @@ void pci_process_bridge_OF_ranges(struct pci_controller *hose,
 			 * hole. If they don't match, bugger.
 			 */
 			if (memno == 0 ||
-			    (isa_hole >= 0 && pci_addr != 0 &&
+			(isa_hole >= 0 && range.pci_addr != 0 &&
 			     hose->pci_mem_offset == isa_mb))
-				hose->pci_mem_offset = cpu_addr - pci_addr;
+				hose->pci_mem_offset = range.cpu_addr -
+							range.pci_addr;
 			else if (pci_addr != 0 &&
-				 hose->pci_mem_offset != cpu_addr - pci_addr) {
+				hose->pci_mem_offset != range.cpu_addr -
+							range.pci_addr) {
 				printk(KERN_INFO
 				       " \\--> Skipped (offset mismatch) !\n");
 				continue;
@@ -802,19 +780,10 @@ void pci_process_bridge_OF_ranges(struct pci_controller *hose,
 
 			/* Build resource */
 			res = &hose->mem_resources[memno++];
-			res->flags = IORESOURCE_MEM;
-			if (pci_space & 0x40000000)
-				res->flags |= IORESOURCE_PREFETCH;
-			res->start = cpu_addr;
 			break;
 		}
-		if (res != NULL) {
-			res->name = dev->full_name;
-			res->end = res->start + size - 1;
-			res->parent = NULL;
-			res->sibling = NULL;
-			res->child = NULL;
-		}
+		if (res != NULL)
+			of_pci_range_to_resource(&range, dev, res);
 	}
 
 	/* If there's an ISA hole and the pci_mem_offset is -not- matching
diff --git a/drivers/of/address.c b/drivers/of/address.c
index 04da786..e87f45e 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -227,6 +227,69 @@ int of_pci_address_to_resource(struct device_node *dev, int bar,
 	return __of_address_to_resource(dev, addrp, size, flags, NULL, r);
 }
 EXPORT_SYMBOL_GPL(of_pci_address_to_resource);
+
+int of_pci_range_parser(struct of_pci_range_parser *parser,
+			struct device_node *node)
+{
+	const int na = 3, ns = 2;
+	int rlen;
+
+	parser->node = node;
+	parser->pna = of_n_addr_cells(node);
+	parser->np = parser->pna + na + ns;
+
+	parser->range = of_get_property(node, "ranges", &rlen);
+	if (parser->range == NULL)
+		return -ENOENT;
+
+	parser->end = parser->range + rlen / sizeof(__be32);
+
+	return 0;
+}
+
+struct of_pci_range *of_pci_process_ranges(struct of_pci_range_parser *parser,
+						struct of_pci_range *range)
+{
+	const int na = 3, ns = 2;
+
+	if (!parser->range || parser->range + parser->np > parser->end)
+		return NULL;
+
+	range->pci_space = be32_to_cpup(parser->range);
+	range->flags = of_bus_pci_get_flags(parser->range);
+	range->pci_addr = of_read_number(parser->range + 1, ns);
+	range->cpu_addr = of_translate_address(parser->node,
+				parser->range + na);
+	range->size = of_read_number(parser->range + parser->pna + na, ns);
+
+	parser->range += parser->np;
+
+	/* Now consume following elements while they are contiguous */
+	while (parser->range + parser->np <= parser->end) {
+		u32 flags, pci_space;
+		u64 pci_addr, cpu_addr, size;
+
+		pci_space = be32_to_cpup(parser->range);
+		flags = of_bus_pci_get_flags(parser->range);
+		pci_addr = of_read_number(parser->range + 1, ns);
+		cpu_addr = of_translate_address(parser->node,
+				parser->range + na);
+		size = of_read_number(parser->range + parser->pna + na, ns);
+
+		if (flags != range->flags)
+			break;
+		if (pci_addr != range->pci_addr + range->size ||
+		    cpu_addr != range->cpu_addr + range->size)
+			break;
+
+		range->size += size;
+		parser->range += parser->np;
+	}
+
+	return range;
+}
+EXPORT_SYMBOL_GPL(of_pci_process_ranges);
+
 #endif /* CONFIG_PCI */
 
 /*
diff --git a/include/linux/of_address.h b/include/linux/of_address.h
index 0506eb5..c7003a3 100644
--- a/include/linux/of_address.h
+++ b/include/linux/of_address.h
@@ -4,6 +4,32 @@
 #include <linux/errno.h>
 #include <linux/of.h>
 
+struct of_pci_range_parser {
+	struct device_node *node;
+	const __be32 *range, *end;
+	int np, pna;
+};
+
+struct of_pci_range {
+	u32 pci_space;
+	u64 pci_addr;
+	u64 cpu_addr;
+	u64 size;
+	u32 flags;
+};
+
+#define for_each_of_pci_range(parser, range) \
+	for (; of_pci_process_ranges(parser, range);)
+
+#define of_pci_range_to_resource(range, np, res) \
+	do { \
+		(res)->flags = (range)->flags; \
+		(res)->start = (range)->cpu_addr; \
+		(res)->end = (range)->cpu_addr + (range)->size - 1; \
+		(res)->parent = (res)->child = (res)->sibling = NULL; \
+		(res)->name = (np)->full_name; \
+	} while (0)
+
 #ifdef CONFIG_OF_ADDRESS
 extern u64 of_translate_address(struct device_node *np, const __be32 *addr);
 extern bool of_can_translate_address(struct device_node *dev);
@@ -27,6 +53,10 @@ static inline unsigned long pci_address_to_pio(phys_addr_t addr) { return -1; }
 #define pci_address_to_pio pci_address_to_pio
 #endif
 
+int of_pci_range_parser(struct of_pci_range_parser *parser,
+			struct device_node *node);
+struct of_pci_range *of_pci_process_ranges(struct of_pci_range_parser *parser,
+						struct of_pci_range *range);
 #else /* CONFIG_OF_ADDRESS */
 #ifndef of_address_to_resource
 static inline int of_address_to_resource(struct device_node *dev, int index,
@@ -53,6 +83,18 @@ static inline const __be32 *of_get_address(struct device_node *dev, int index,
 {
 	return NULL;
 }
+
+int of_pci_range_parser(struct of_pci_range_parser *parser,
+			struct device_noed *node)
+{
+	return -1;
+}
+
+struct of_pci_range *of_pci_process_ranges(struct of_pci_range_parser *parser,
+						struct of_pci_range *range)
+{
+	return NULL;
+}
 #endif /* CONFIG_OF_ADDRESS */
 
 
-- 
1.8.2



From thierry.reding at avionic-design.de  Wed Apr  3 10:45:15 2013
From: thierry.reding at avionic-design.de (Thierry Reding)
Date: Wed,  3 Apr 2013 16:45:15 +0200
Subject: [PATCH v3 09/12] ARM: tegra: tec: Add PCIe support
In-Reply-To: <1365000318-28256-1-git-send-email-thierry.reding@avionic-design.de>
References: <1365000318-28256-1-git-send-email-thierry.reding@avionic-design.de>
Message-ID: <1365000318-28256-10-git-send-email-thierry.reding@avionic-design.de>

Enable the first PCIe root port which is connected to an FPGA on the
Tamonten Evaluation Carrier and add device nodes for each of the PCI
endpoints available in the standard configuration.

Signed-off-by: Thierry Reding <thierry.reding at avionic-design.de>
---
Changes in v2:
- remove duplicate nodes and properties defined in tegra20-tamonten.dtsi

Changes in v3:
- remove PCIe endpoint device tree nodes, all devices can be discovered
  via standard PCI enumeration

 arch/arm/boot/dts/tegra20-tec.dts | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/tegra20-tec.dts b/arch/arm/boot/dts/tegra20-tec.dts
index 1ae37ba..e396cb2 100644
--- a/arch/arm/boot/dts/tegra20-tec.dts
+++ b/arch/arm/boot/dts/tegra20-tec.dts
@@ -64,6 +64,14 @@
 		};
 	};
 
+	pcie-controller {
+		status = "okay";
+
+		pci at 1,0 {
+			status = "okay";
+		};
+	};
+
 	sound {
 		compatible = "ad,tegra-audio-wm8903-tec",
 			     "nvidia,tegra-audio-wm8903";
-- 
1.8.2



From thierry.reding at avionic-design.de  Wed Apr  3 10:45:09 2013
From: thierry.reding at avionic-design.de (Thierry Reding)
Date: Wed,  3 Apr 2013 16:45:09 +0200
Subject: [PATCH v3 03/12] of/pci: Add of_pci_parse_bus_range() function
In-Reply-To: <1365000318-28256-1-git-send-email-thierry.reding@avionic-design.de>
References: <1365000318-28256-1-git-send-email-thierry.reding@avionic-design.de>
Message-ID: <1365000318-28256-4-git-send-email-thierry.reding@avionic-design.de>

This function can be used to parse a bus-range property as specified by
device nodes representing PCI bridges.

Signed-off-by: Thierry Reding <thierry.reding at avionic-design.de>
---
 drivers/of/of_pci.c    | 25 +++++++++++++++++++++++++
 include/linux/of_pci.h |  1 +
 2 files changed, 26 insertions(+)

diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
index 4dd7b9b..42c687a 100644
--- a/drivers/of/of_pci.c
+++ b/drivers/of/of_pci.c
@@ -64,3 +64,28 @@ int of_pci_get_devfn(struct device_node *np)
 	return (be32_to_cpup(reg) >> 8) & 0xff;
 }
 EXPORT_SYMBOL_GPL(of_pci_get_devfn);
+
+/**
+ * of_pci_parse_bus_range() - parse the bus-range property of a PCI device
+ * @node: device node
+ * @res: address to a struct resource to return the bus-range
+ *
+ * Returns 0 on success or a negative error-code on failure.
+ */
+int of_pci_parse_bus_range(struct device_node *node, struct resource *res)
+{
+	const __be32 *values;
+	int len;
+
+	values = of_get_property(node, "bus-range", &len);
+	if (!values || len < sizeof(*values) * 2)
+		return -EINVAL;
+
+	res->name = node->name;
+	res->start = be32_to_cpup(values++);
+	res->end = be32_to_cpup(values);
+	res->flags = IORESOURCE_BUS;
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(of_pci_parse_bus_range);
diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
index 91ec484..7a04826 100644
--- a/include/linux/of_pci.h
+++ b/include/linux/of_pci.h
@@ -11,5 +11,6 @@ struct device_node;
 struct device_node *of_pci_find_child_device(struct device_node *parent,
 					     unsigned int devfn);
 int of_pci_get_devfn(struct device_node *np);
+int of_pci_parse_bus_range(struct device_node *node, struct resource *res);
 
 #endif
-- 
1.8.2



From thierry.reding at avionic-design.de  Wed Apr  3 10:45:10 2013
From: thierry.reding at avionic-design.de (Thierry Reding)
Date: Wed,  3 Apr 2013 16:45:10 +0200
Subject: [PATCH v3 04/12] PCI: Introduce new MSI chip infrastructure
In-Reply-To: <1365000318-28256-1-git-send-email-thierry.reding@avionic-design.de>
References: <1365000318-28256-1-git-send-email-thierry.reding@avionic-design.de>
Message-ID: <1365000318-28256-5-git-send-email-thierry.reding@avionic-design.de>

The new struct msi_chip is used to associated an MSI controller with a
PCI bus. It is automatically handed down from the root to its children
during bus enumeration.

This patch provides default (weak) implementations for the architecture-
specific MSI functions (arch_setup_msi_irq(), arch_teardown_msi_irq()
and arch_msi_check_device()) which check if a PCI device's bus has an
attached MSI chip and forward the call appropriately.

Signed-off-by: Thierry Reding <thierry.reding at avionic-design.de>
---
 drivers/pci/msi.c   | 35 +++++++++++++++++++++++++++++++----
 drivers/pci/probe.c |  1 +
 include/linux/msi.h | 10 ++++++++++
 include/linux/pci.h |  1 +
 4 files changed, 43 insertions(+), 4 deletions(-)

diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index 00cc78c..fce3549 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -26,14 +26,41 @@
 
 static int pci_msi_enable = 1;
 
-/* Arch hooks */
+int __weak arch_setup_msi_irq(struct pci_dev *dev, struct msi_desc *desc)
+{
+	struct msi_chip *chip = dev->bus->msi;
+
+	if (chip && chip->setup_irq) {
+		int err;
+
+		err = chip->setup_irq(chip, dev, desc);
+		if (err < 0)
+			return err;
+
+		irq_set_chip_data(desc->irq, chip);
+		return err;
+	}
+
+	return -EINVAL;
+}
 
-#ifndef arch_msi_check_device
-int arch_msi_check_device(struct pci_dev *dev, int nvec, int type)
+void __weak arch_teardown_msi_irq(unsigned int irq)
 {
+	struct msi_chip *chip = irq_get_chip_data(irq);
+
+	if (chip && chip->teardown_irq)
+		chip->teardown_irq(chip, irq);
+}
+
+int __weak arch_msi_check_device(struct pci_dev *dev, int nvec, int type)
+{
+	struct msi_chip *chip = dev->bus->msi;
+
+	if (chip && chip->check_device)
+		return chip->check_device(chip, dev, nvec, type);
+
 	return 0;
 }
-#endif
 
 #ifndef arch_setup_msi_irqs
 # define arch_setup_msi_irqs default_setup_msi_irqs
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index b494066..9307550 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -634,6 +634,7 @@ static struct pci_bus *pci_alloc_child_bus(struct pci_bus *parent,
 
 	child->parent = parent;
 	child->ops = parent->ops;
+	child->msi = parent->msi;
 	child->sysdata = parent->sysdata;
 	child->bus_flags = parent->bus_flags;
 
diff --git a/include/linux/msi.h b/include/linux/msi.h
index ce93a34..ea4a5be 100644
--- a/include/linux/msi.h
+++ b/include/linux/msi.h
@@ -58,5 +58,15 @@ extern int arch_setup_msi_irqs(struct pci_dev *dev, int nvec, int type);
 extern void arch_teardown_msi_irqs(struct pci_dev *dev);
 extern int arch_msi_check_device(struct pci_dev* dev, int nvec, int type);
 
+struct msi_chip {
+	struct module *owner;
+	struct device *dev;
+
+	int (*setup_irq)(struct msi_chip *chip, struct pci_dev *dev,
+			 struct msi_desc *desc);
+	void (*teardown_irq)(struct msi_chip *chip, unsigned int irq);
+	int (*check_device)(struct msi_chip *chip, struct pci_dev *dev,
+			    int nvec, int type);
+};
 
 #endif /* LINUX_MSI_H */
diff --git a/include/linux/pci.h b/include/linux/pci.h
index f42cdc6..7e44085 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -431,6 +431,7 @@ struct pci_bus {
 	struct resource busn_res;	/* bus numbers routed to this bus */
 
 	struct pci_ops	*ops;		/* configuration access functions */
+	struct msi_chip	*msi;		/* MSI controller */
 	void		*sysdata;	/* hook for sys-specific extension */
 	struct proc_dir_entry *procdir;	/* directory entry in /proc/bus/pci */
 
-- 
1.8.2



From thierry.reding at avionic-design.de  Wed Apr  3 10:45:17 2013
From: thierry.reding at avionic-design.de (Thierry Reding)
Date: Wed,  3 Apr 2013 16:45:17 +0200
Subject: [PATCH v3 11/12] ARM: tegra: trimslice: Initialize PCIe from DT
In-Reply-To: <1365000318-28256-1-git-send-email-thierry.reding@avionic-design.de>
References: <1365000318-28256-1-git-send-email-thierry.reding@avionic-design.de>
Message-ID: <1365000318-28256-12-git-send-email-thierry.reding@avionic-design.de>

With the device tree support in place, probe the PCIe controller from
the device tree and remove the corresponding workaround in the board
file.

Signed-off-by: Thierry Reding <thierry.reding at avionic-design.de>
---
Changes in v2:
- add missing dummy regulator nodes by Stephen Warren
- rename port 0 DT node and disable unused port 1

 arch/arm/boot/dts/tegra20-trimslice.dts | 28 ++++++++++++++++++++++++++++
 1 file changed, 28 insertions(+)

diff --git a/arch/arm/boot/dts/tegra20-trimslice.dts b/arch/arm/boot/dts/tegra20-trimslice.dts
index 955bf49..dc081c3 100644
--- a/arch/arm/boot/dts/tegra20-trimslice.dts
+++ b/arch/arm/boot/dts/tegra20-trimslice.dts
@@ -300,6 +300,16 @@
 		};
 	};
 
+	pcie-controller {
+		status = "okay";
+		pex-clk-supply = <&pci_clk_reg>;
+		vdd-supply = <&pci_vdd_reg>;
+
+		pci at 1,0 {
+			status = "okay";
+		};
+	};
+
 	usb at c5000000 {
 		status = "okay";
 		nvidia,vbus-gpio = <&gpio 170 0>; /* gpio PV2 */
@@ -357,6 +367,24 @@
 			regulator-max-microvolt = <1800000>;
 			regulator-always-on;
 		};
+
+		pci_clk_reg: regulator at 2 {
+			compatible = "regulator-fixed";
+			reg = <2>;
+			regulator-name = "pci_clk";
+			regulator-min-microvolt = <3300000>;
+			regulator-max-microvolt = <3300000>;
+			regulator-always-on;
+		};
+
+		pci_vdd_reg: regulator at 3 {
+			compatible = "regulator-fixed";
+			reg = <3>;
+			regulator-name = "pci_vdd";
+			regulator-min-microvolt = <1050000>;
+			regulator-max-microvolt = <1050000>;
+			regulator-always-on;
+		};
 	};
 
 	sound {
-- 
1.8.2



From thierry.reding at avionic-design.de  Wed Apr  3 10:45:06 2013
From: thierry.reding at avionic-design.de (Thierry Reding)
Date: Wed,  3 Apr 2013 16:45:06 +0200
Subject: [PATCH v3 00/12] Rewrite Tegra PCIe driver
Message-ID: <1365000318-28256-1-git-send-email-thierry.reding@avionic-design.de>

This patch series contains an almost complete rewrite of the Tegra PCIe
driver. The code is moved to the drivers/pci/host directory and turned
into a proper platform driver, adding MSI and DT support while at it.
Other PCI host controller drivers can be added to that directory in an
attempt to make it easier to factor out common code.

Patches 1 to 3 add generic OF helpers to parse a PCI node's ranges
property as well as obtain the device and function numbers from a node's
reg property.

Patch 4 introduces a new MSI chip infrastructure which is required to
make multiple platform-specific implementations of the MSI support
functions coexist peacefully.

Patches 5 and 6 move some of the Tegra specific code around to allow it
to be used from outside the arch/arm/mach-tegra directory.

Patch 7 moves the Tegra PCIe controller driver to the drivers/pci/host
directory and turns it into a proper platform driver. It also adds MSI
(based on patches by NVIDIA) and DT support.

Patches 8 to 11 add device tree based probing for the TEC, Harmony and
TrimSlice boards. Finally the default configuration for Tegra is updated
in patch 12.

Thierry

Andrew Murray (1):
  of/pci: Provide support for parsing PCI DT ranges property

Thierry Reding (11):
  of/pci: Add of_pci_get_devfn() function
  of/pci: Add of_pci_parse_bus_range() function
  PCI: Introduce new MSI chip infrastructure
  ARM: tegra: Move tegra_pcie_xclk_clamp() to PMC
  ARM: tegra: Move pmc.h to include/linux/tegra-pmc.h
  PCI: tegra: Move PCIe driver to drivers/pci/host
  ARM: tegra: tamonten: Add PCIe support
  ARM: tegra: tec: Add PCIe support
  ARM: tegra: harmony: Initialize PCIe from DT
  ARM: tegra: trimslice: Initialize PCIe from DT
  ARM: tegra: Update default configuration (PCIe)

 .../bindings/pci/nvidia,tegra20-pcie.txt           |  123 ++
 arch/arm/boot/dts/tegra20-harmony.dts              |   20 +-
 arch/arm/boot/dts/tegra20-tamonten.dtsi            |   17 +-
 arch/arm/boot/dts/tegra20-tec.dts                  |    8 +
 arch/arm/boot/dts/tegra20-trimslice.dts            |   28 +
 arch/arm/boot/dts/tegra20.dtsi                     |   53 +
 arch/arm/configs/tegra_defconfig                   |    4 +-
 arch/arm/mach-tegra/Kconfig                        |    7 +-
 arch/arm/mach-tegra/Makefile                       |    3 -
 arch/arm/mach-tegra/board-harmony-pcie.c           |   89 --
 arch/arm/mach-tegra/board.h                        |    8 -
 arch/arm/mach-tegra/iomap.h                        |    3 -
 arch/arm/mach-tegra/pcie.c                         |  886 -----------
 arch/arm/mach-tegra/pmc.c                          |   16 +
 arch/arm/mach-tegra/tegra.c                        |   24 -
 arch/microblaze/pci/pci-common.c                   |  110 +-
 arch/mips/pci/pci.c                                |   50 +-
 arch/powerpc/kernel/pci-common.c                   |   99 +-
 drivers/of/address.c                               |   63 +
 drivers/of/of_pci.c                                |   59 +-
 drivers/pci/Kconfig                                |    2 +
 drivers/pci/Makefile                               |    3 +
 drivers/pci/host/Kconfig                           |    8 +
 drivers/pci/host/Makefile                          |    1 +
 drivers/pci/host/pci-tegra.c                       | 1560 ++++++++++++++++++++
 drivers/pci/msi.c                                  |   35 +-
 drivers/pci/probe.c                                |    1 +
 include/linux/msi.h                                |   10 +
 include/linux/of_address.h                         |   42 +
 include/linux/of_pci.h                             |    2 +
 include/linux/pci.h                                |    1 +
 include/linux/tegra-pmc.h                          |   23 +
 32 files changed, 2155 insertions(+), 1203 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt
 delete mode 100644 arch/arm/mach-tegra/board-harmony-pcie.c
 delete mode 100644 arch/arm/mach-tegra/pcie.c
 create mode 100644 drivers/pci/host/Kconfig
 create mode 100644 drivers/pci/host/Makefile
 create mode 100644 drivers/pci/host/pci-tegra.c
 create mode 100644 include/linux/tegra-pmc.h

-- 
1.8.2



From thierry.reding at avionic-design.de  Wed Apr  3 10:45:16 2013
From: thierry.reding at avionic-design.de (Thierry Reding)
Date: Wed,  3 Apr 2013 16:45:16 +0200
Subject: [PATCH v3 10/12] ARM: tegra: harmony: Initialize PCIe from DT
In-Reply-To: <1365000318-28256-1-git-send-email-thierry.reding@avionic-design.de>
References: <1365000318-28256-1-git-send-email-thierry.reding@avionic-design.de>
Message-ID: <1365000318-28256-11-git-send-email-thierry.reding@avionic-design.de>

With the device tree support in place, probe the PCIe controller from
the device tree and remove the corresponding workaround in the board
file.

Signed-off-by: Thierry Reding <thierry.reding at avionic-design.de>
---
 arch/arm/boot/dts/tegra20-harmony.dts | 20 ++++++++++++++++----
 1 file changed, 16 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/tegra20-harmony.dts b/arch/arm/boot/dts/tegra20-harmony.dts
index 5fb0888..8799d7a 100644
--- a/arch/arm/boot/dts/tegra20-harmony.dts
+++ b/arch/arm/boot/dts/tegra20-harmony.dts
@@ -334,7 +334,7 @@
 					regulator-always-on;
 				};
 
-				ldo0 {
+				pci_clk_reg: ldo0 {
 					regulator-name = "vdd_ldo0,vddio_pex_clk";
 					regulator-min-microvolt = <3300000>;
 					regulator-max-microvolt = <3300000>;
@@ -418,6 +418,20 @@
 		nvidia,invert-interrupt;
 	};
 
+	pcie-controller {
+		pex-clk-supply = <&pci_clk_reg>;
+		vdd-supply = <&pci_vdd_reg>;
+		status = "okay";
+
+		pci at 1,0 {
+			status = "okay";
+		};
+
+		pci at 2,0 {
+			status = "okay";
+		};
+	};
+
 	usb at c5000000 {
 		status = "okay";
 	};
@@ -601,7 +615,7 @@
 			enable-active-high;
 		};
 
-		regulator at 3 {
+		pci_vdd_reg: regulator at 3 {
 			compatible = "regulator-fixed";
 			reg = <3>;
 			regulator-name = "vdd_1v05";
@@ -609,8 +623,6 @@
 			regulator-max-microvolt = <1050000>;
 			gpio = <&pmic 2 0>;
 			enable-active-high;
-			/* Hack until board-harmony-pcie.c is removed */
-			status = "disabled";
 		};
 
 		regulator at 4 {
-- 
1.8.2



From thierry.reding at avionic-design.de  Wed Apr  3 10:45:18 2013
From: thierry.reding at avionic-design.de (Thierry Reding)
Date: Wed,  3 Apr 2013 16:45:18 +0200
Subject: [PATCH v3 12/12] ARM: tegra: Update default configuration (PCIe)
In-Reply-To: <1365000318-28256-1-git-send-email-thierry.reding@avionic-design.de>
References: <1365000318-28256-1-git-send-email-thierry.reding@avionic-design.de>
Message-ID: <1365000318-28256-13-git-send-email-thierry.reding@avionic-design.de>

Enable PCI and MSI support as well as the new Tegra PCIe controller
driver.

Signed-off-by: Thierry Reding <thierry.reding at avionic-design.de>
---
 arch/arm/configs/tegra_defconfig | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm/configs/tegra_defconfig b/arch/arm/configs/tegra_defconfig
index 2b42a2c..6cedaa1 100644
--- a/arch/arm/configs/tegra_defconfig
+++ b/arch/arm/configs/tegra_defconfig
@@ -26,8 +26,10 @@ CONFIG_GPIO_PCA953X=y
 CONFIG_ARCH_TEGRA_2x_SOC=y
 CONFIG_ARCH_TEGRA_3x_SOC=y
 CONFIG_ARCH_TEGRA_114_SOC=y
-CONFIG_TEGRA_PCI=y
 CONFIG_TEGRA_EMC_SCALING_ENABLE=y
+CONFIG_PCI=y
+CONFIG_PCI_MSI=y
+CONFIG_PCI_TEGRA=y
 CONFIG_SMP=y
 CONFIG_PREEMPT=y
 CONFIG_AEABI=y
-- 
1.8.2



From thierry.reding at avionic-design.de  Wed Apr  3 10:45:12 2013
From: thierry.reding at avionic-design.de (Thierry Reding)
Date: Wed,  3 Apr 2013 16:45:12 +0200
Subject: [PATCH v3 06/12] ARM: tegra: Move pmc.h to include/linux/tegra-pmc.h
In-Reply-To: <1365000318-28256-1-git-send-email-thierry.reding@avionic-design.de>
References: <1365000318-28256-1-git-send-email-thierry.reding@avionic-design.de>
Message-ID: <1365000318-28256-7-git-send-email-thierry.reding@avionic-design.de>

In preparation for moving the PCIe driver into the drivers/pci/host
directory, this header, which contains prototypes that are required by
the PCIe driver, needs to be moved to a globally visible location.

Signed-off-by: Thierry Reding <thierry.reding at avionic-design.de>
---
Changes in v2:
- keep tegra_pmc_init() prototype in arch/arm/mach-tegra/pmc.h
- move pmc.h to includex/linux/tegra-pmc.h

Changes in v3:
- update subject to match new location

 arch/arm/mach-tegra/pmc.h |  1 -
 include/linux/tegra-pmc.h | 23 +++++++++++++++++++++++
 2 files changed, 23 insertions(+), 1 deletion(-)
 create mode 100644 include/linux/tegra-pmc.h

diff --git a/arch/arm/mach-tegra/pmc.h b/arch/arm/mach-tegra/pmc.h
index c778451..7d44710 100644
--- a/arch/arm/mach-tegra/pmc.h
+++ b/arch/arm/mach-tegra/pmc.h
@@ -23,6 +23,5 @@ int tegra_pmc_cpu_power_on(int cpuid);
 int tegra_pmc_cpu_remove_clamping(int cpuid);
 
 void tegra_pmc_init(void);
-void tegra_pmc_pcie_xclk_clamp(bool clamp);
 
 #endif
diff --git a/include/linux/tegra-pmc.h b/include/linux/tegra-pmc.h
new file mode 100644
index 0000000..b6296bf
--- /dev/null
+++ b/include/linux/tegra-pmc.h
@@ -0,0 +1,23 @@
+/*
+ * Copyright (C) 2012 NVIDIA CORPORATION. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
+ *
+ */
+
+#ifndef __LINUX_TEGRA_PMC_H
+#define __LINUX_TEGRA_PMC_H
+
+void tegra_pmc_pcie_xclk_clamp(bool clamp);
+
+#endif
-- 
1.8.2



From thierry.reding at avionic-design.de  Wed Apr  3 10:45:08 2013
From: thierry.reding at avionic-design.de (Thierry Reding)
Date: Wed,  3 Apr 2013 16:45:08 +0200
Subject: [PATCH v3 02/12] of/pci: Add of_pci_get_devfn() function
In-Reply-To: <1365000318-28256-1-git-send-email-thierry.reding@avionic-design.de>
References: <1365000318-28256-1-git-send-email-thierry.reding@avionic-design.de>
Message-ID: <1365000318-28256-3-git-send-email-thierry.reding@avionic-design.de>

This function can be used to parse the device and function number from a
standard 5-cell PCI resource. PCI_SLOT() and PCI_FUNC() can be used on
the returned value obtain the device and function numbers respectively.

Signed-off-by: Thierry Reding <thierry.reding at avionic-design.de>
---
Changes in v2:
- rename devfn and err variables for clarity

 drivers/of/of_pci.c    | 34 +++++++++++++++++++++++++++++-----
 include/linux/of_pci.h |  1 +
 2 files changed, 30 insertions(+), 5 deletions(-)

diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
index 13e37e2..4dd7b9b 100644
--- a/drivers/of/of_pci.c
+++ b/drivers/of/of_pci.c
@@ -5,14 +5,15 @@
 #include <asm/prom.h>
 
 static inline int __of_pci_pci_compare(struct device_node *node,
-				       unsigned int devfn)
+				       unsigned int data)
 {
-	unsigned int size;
-	const __be32 *reg = of_get_property(node, "reg", &size);
+	int devfn;
 
-	if (!reg || size < 5 * sizeof(__be32))
+	devfn = of_pci_get_devfn(node);
+	if (devfn < 0)
 		return 0;
-	return ((be32_to_cpup(&reg[0]) >> 8) & 0xff) == devfn;
+
+	return devfn == data;
 }
 
 struct device_node *of_pci_find_child_device(struct device_node *parent,
@@ -40,3 +41,26 @@ struct device_node *of_pci_find_child_device(struct device_node *parent,
 	return NULL;
 }
 EXPORT_SYMBOL_GPL(of_pci_find_child_device);
+
+/**
+ * of_pci_get_devfn() - Get device and function numbers for a device node
+ * @np: device node
+ *
+ * Parses a standard 5-cell PCI resource and returns an 8-bit value that can
+ * be passed to the PCI_SLOT() and PCI_FUNC() macros to extract the device
+ * and function numbers respectively. On error a negative error code is
+ * returned.
+ */
+int of_pci_get_devfn(struct device_node *np)
+{
+	unsigned int size;
+	const __be32 *reg;
+
+	reg = of_get_property(np, "reg", &size);
+
+	if (!reg || size < 5 * sizeof(__be32))
+		return -EINVAL;
+
+	return (be32_to_cpup(reg) >> 8) & 0xff;
+}
+EXPORT_SYMBOL_GPL(of_pci_get_devfn);
diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
index bb115de..91ec484 100644
--- a/include/linux/of_pci.h
+++ b/include/linux/of_pci.h
@@ -10,5 +10,6 @@ int of_irq_map_pci(const struct pci_dev *pdev, struct of_irq *out_irq);
 struct device_node;
 struct device_node *of_pci_find_child_device(struct device_node *parent,
 					     unsigned int devfn);
+int of_pci_get_devfn(struct device_node *np);
 
 #endif
-- 
1.8.2



From thierry.reding at avionic-design.de  Wed Apr  3 10:45:11 2013
From: thierry.reding at avionic-design.de (Thierry Reding)
Date: Wed,  3 Apr 2013 16:45:11 +0200
Subject: [PATCH v3 05/12] ARM: tegra: Move tegra_pcie_xclk_clamp() to PMC
In-Reply-To: <1365000318-28256-1-git-send-email-thierry.reding@avionic-design.de>
References: <1365000318-28256-1-git-send-email-thierry.reding@avionic-design.de>
Message-ID: <1365000318-28256-6-git-send-email-thierry.reding@avionic-design.de>

The PMC code already accesses to PMC registers so it makes sense to
move this function there as well. While at it, rename the function to
tegra_pmc_pcie_xclk_clamp() for consistency.

Signed-off-by: Thierry Reding <thierry.reding at avionic-design.de>
Acked-by: Stephen Warren <swarren at wwwdotorg.org>
---
 arch/arm/mach-tegra/pcie.c | 30 ++++--------------------------
 arch/arm/mach-tegra/pmc.c  | 16 ++++++++++++++++
 arch/arm/mach-tegra/pmc.h  |  1 +
 3 files changed, 21 insertions(+), 26 deletions(-)

diff --git a/arch/arm/mach-tegra/pcie.c b/arch/arm/mach-tegra/pcie.c
index 46144a1..6c1989b 100644
--- a/arch/arm/mach-tegra/pcie.c
+++ b/arch/arm/mach-tegra/pcie.c
@@ -41,6 +41,7 @@
 
 #include "board.h"
 #include "iomap.h"
+#include "pmc.h"
 
 /* Hack - need to parse this from DT */
 #define INT_PCIE_INTR 130
@@ -147,17 +148,6 @@
 #define  PADS_PLL_CTL_TXCLKREF_DIV10		(0 << 20)
 #define  PADS_PLL_CTL_TXCLKREF_DIV5		(1 << 20)
 
-/* PMC access is required for PCIE xclk (un)clamping */
-#define PMC_SCRATCH42		0x144
-#define PMC_SCRATCH42_PCX_CLAMP	(1 << 0)
-
-static void __iomem *reg_pmc_base = IO_ADDRESS(TEGRA_PMC_BASE);
-
-#define pmc_writel(value, reg) \
-	__raw_writel(value, reg_pmc_base + (reg))
-#define pmc_readl(reg) \
-	__raw_readl(reg_pmc_base + (reg))
-
 /*
  * Tegra2 defines 1GB in the AXI address map for PCIe.
  *
@@ -639,18 +629,6 @@ static int tegra_pcie_enable_controller(void)
 	return 0;
 }
 
-static void tegra_pcie_xclk_clamp(bool clamp)
-{
-	u32 reg;
-
-	reg = pmc_readl(PMC_SCRATCH42) & ~PMC_SCRATCH42_PCX_CLAMP;
-
-	if (clamp)
-		reg |= PMC_SCRATCH42_PCX_CLAMP;
-
-	pmc_writel(reg, PMC_SCRATCH42);
-}
-
 static void tegra_pcie_power_off(void)
 {
 	tegra_periph_reset_assert(tegra_pcie.pcie_xclk);
@@ -658,7 +636,7 @@ static void tegra_pcie_power_off(void)
 	tegra_periph_reset_assert(tegra_pcie.pex_clk);
 
 	tegra_powergate_power_off(TEGRA_POWERGATE_PCIE);
-	tegra_pcie_xclk_clamp(true);
+	tegra_pmc_pcie_xclk_clamp(true);
 }
 
 static int tegra_pcie_power_regate(void)
@@ -667,7 +645,7 @@ static int tegra_pcie_power_regate(void)
 
 	tegra_pcie_power_off();
 
-	tegra_pcie_xclk_clamp(true);
+	tegra_pmc_pcie_xclk_clamp(true);
 
 	tegra_periph_reset_assert(tegra_pcie.pcie_xclk);
 	tegra_periph_reset_assert(tegra_pcie.afi_clk);
@@ -681,7 +659,7 @@ static int tegra_pcie_power_regate(void)
 
 	tegra_periph_reset_deassert(tegra_pcie.afi_clk);
 
-	tegra_pcie_xclk_clamp(false);
+	tegra_pmc_pcie_xclk_clamp(false);
 
 	clk_prepare_enable(tegra_pcie.afi_clk);
 	clk_prepare_enable(tegra_pcie.pex_clk);
diff --git a/arch/arm/mach-tegra/pmc.c b/arch/arm/mach-tegra/pmc.c
index b30e921..f82284c 100644
--- a/arch/arm/mach-tegra/pmc.c
+++ b/arch/arm/mach-tegra/pmc.c
@@ -44,6 +44,10 @@ static DEFINE_SPINLOCK(tegra_powergate_lock);
 static void __iomem *tegra_pmc_base;
 static bool tegra_pmc_invert_interrupt;
 
+/* PMC access is required for PCIE xclk (un)clamping */
+#define PMC_SCRATCH42		0x144
+#define PMC_SCRATCH42_PCX_CLAMP	(1 << 0)
+
 static inline u32 tegra_pmc_readl(u32 reg)
 {
 	return readl(tegra_pmc_base + reg);
@@ -166,3 +170,15 @@ void __init tegra_pmc_init(void)
 		val &= ~PMC_CTRL_INTR_LOW;
 	tegra_pmc_writel(val, PMC_CTRL);
 }
+
+void tegra_pmc_pcie_xclk_clamp(bool clamp)
+{
+	u32 reg;
+
+	reg = tegra_pmc_readl(PMC_SCRATCH42) & ~PMC_SCRATCH42_PCX_CLAMP;
+
+	if (clamp)
+		reg |= PMC_SCRATCH42_PCX_CLAMP;
+
+	tegra_pmc_writel(reg, PMC_SCRATCH42);
+}
diff --git a/arch/arm/mach-tegra/pmc.h b/arch/arm/mach-tegra/pmc.h
index 7d44710..c778451 100644
--- a/arch/arm/mach-tegra/pmc.h
+++ b/arch/arm/mach-tegra/pmc.h
@@ -23,5 +23,6 @@ int tegra_pmc_cpu_power_on(int cpuid);
 int tegra_pmc_cpu_remove_clamping(int cpuid);
 
 void tegra_pmc_init(void);
+void tegra_pmc_pcie_xclk_clamp(bool clamp);
 
 #endif
-- 
1.8.2



From thierry.reding at avionic-design.de  Wed Apr  3 10:45:14 2013
From: thierry.reding at avionic-design.de (Thierry Reding)
Date: Wed,  3 Apr 2013 16:45:14 +0200
Subject: [PATCH v3 08/12] ARM: tegra: tamonten: Add PCIe support
In-Reply-To: <1365000318-28256-1-git-send-email-thierry.reding@avionic-design.de>
References: <1365000318-28256-1-git-send-email-thierry.reding@avionic-design.de>
Message-ID: <1365000318-28256-9-git-send-email-thierry.reding@avionic-design.de>

Add properties common to all Tamonten-derived boards to the Tamonten
DTSI and add the fixed 1.05 V regulator.

Signed-off-by: Thierry Reding <thierry.reding at avionic-design.de>
---
Changes in v2:
- add properties common to all Tamonten boards
- add fixed 1.05 V regulator

 arch/arm/boot/dts/tegra20-tamonten.dtsi | 17 ++++++++++++++++-
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/tegra20-tamonten.dtsi b/arch/arm/boot/dts/tegra20-tamonten.dtsi
index 08cc557..020f7bc 100644
--- a/arch/arm/boot/dts/tegra20-tamonten.dtsi
+++ b/arch/arm/boot/dts/tegra20-tamonten.dtsi
@@ -438,7 +438,7 @@
 					regulator-always-on;
 				};
 
-				ldo0 {
+				pci_clk_reg: ldo0 {
 					regulator-name = "vdd_ldo0,vddio_pex_clk";
 					regulator-min-microvolt = <3300000>;
 					regulator-max-microvolt = <3300000>;
@@ -533,6 +533,11 @@
 		nvidia,invert-interrupt;
 	};
 
+	pcie-controller {
+		pex-clk-supply = <&pci_clk_reg>;
+		vdd-supply = <&pci_vdd_reg>;
+	};
+
 	usb at c5008000 {
 		status = "okay";
 	};
@@ -558,5 +563,15 @@
 			regulator-max-microvolt = <5000000>;
 			regulator-always-on;
 		};
+
+		pci_vdd_reg: regulator at 1 {
+			compatible = "regulator-fixed";
+			reg = <1>;
+			regulator-name = "vdd_1v05";
+			regulator-min-microvolt = <1050000>;
+			regulator-max-microvolt = <1050000>;
+			gpio = <&pmic 2 0>;
+			enable-active-high;
+		};
 	};
 };
-- 
1.8.2



From pdeschrijver at nvidia.com  Wed Apr  3 10:40:37 2013
From: pdeschrijver at nvidia.com (Peter De Schrijver)
Date: Wed, 3 Apr 2013 17:40:37 +0300
Subject: [PATCH v9 03/14] clk: tegra: Add TEGRA_PLL_BYPASS flag
In-Reply-To: <1365000110-8916-1-git-send-email-pdeschrijver@nvidia.com>
References: <1365000110-8916-1-git-send-email-pdeschrijver@nvidia.com>
Message-ID: <1365000110-8916-4-git-send-email-pdeschrijver@nvidia.com>

Not all PLLs in Tegra114 have a bypass bit. Adapt the common code to only use
this bit when available.

Signed-off-by: Peter De Schrijver <pdeschrijver at nvidia.com>
---
 drivers/clk/tegra/clk-pll.c |   12 ++++++++----
 drivers/clk/tegra/clk.h     |    2 ++
 2 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/clk/tegra/clk-pll.c b/drivers/clk/tegra/clk-pll.c
index 3feefb1..4ee6d03 100644
--- a/drivers/clk/tegra/clk-pll.c
+++ b/drivers/clk/tegra/clk-pll.c
@@ -171,7 +171,8 @@ static void _clk_pll_enable(struct clk_hw *hw)
 	clk_pll_enable_lock(pll);
 
 	val = pll_readl_base(pll);
-	val &= ~PLL_BASE_BYPASS;
+	if (pll->flags & TEGRA_PLL_BYPASS)
+		val &= ~PLL_BASE_BYPASS;
 	val |= PLL_BASE_ENABLE;
 	pll_writel_base(val, pll);
 
@@ -188,7 +189,9 @@ static void _clk_pll_disable(struct clk_hw *hw)
 	u32 val;
 
 	val = pll_readl_base(pll);
-	val &= ~(PLL_BASE_BYPASS | PLL_BASE_ENABLE);
+	if (pll->flags & TEGRA_PLL_BYPASS)
+		val &= ~PLL_BASE_BYPASS;
+	val &= ~PLL_BASE_ENABLE;
 	pll_writel_base(val, pll);
 
 	if (pll->flags & TEGRA_PLLM) {
@@ -459,7 +462,7 @@ static unsigned long clk_pll_recalc_rate(struct clk_hw *hw,
 
 	val = pll_readl_base(pll);
 
-	if (val & PLL_BASE_BYPASS)
+	if ((pll->flags & TEGRA_PLL_BYPASS) && (val & PLL_BASE_BYPASS))
 		return parent_rate;
 
 	if ((pll->flags & TEGRA_PLL_FIXED) && !(val & PLL_BASE_OVERRIDE)) {
@@ -671,6 +674,7 @@ struct clk *tegra_clk_register_pll(const char *name, const char *parent_name,
 	struct tegra_clk_pll *pll;
 	struct clk *clk;
 
+	pll_flags |= TEGRA_PLL_BYPASS;
 	pll = _tegra_init_pll(clk_base, pmc, fixed_rate, pll_params, pll_flags,
 			      freq_table, lock);
 	if (IS_ERR(pll))
@@ -692,8 +696,8 @@ struct clk *tegra_clk_register_plle(const char *name, const char *parent_name,
 {
 	struct tegra_clk_pll *pll;
 	struct clk *clk;
-	pll_flags |= TEGRA_PLL_LOCK_MISC;
 
+	pll_flags |= TEGRA_PLL_LOCK_MISC | TEGRA_PLL_BYPASS;
 	pll = _tegra_init_pll(clk_base, pmc, fixed_rate, pll_params, pll_flags,
 			      freq_table, lock);
 	if (IS_ERR(pll))
diff --git a/drivers/clk/tegra/clk.h b/drivers/clk/tegra/clk.h
index b9691dd..fff520a 100644
--- a/drivers/clk/tegra/clk.h
+++ b/drivers/clk/tegra/clk.h
@@ -184,6 +184,7 @@ struct tegra_clk_pll_params {
  * TEGRA_PLLE_CONFIGURE - Configure PLLE when enabling.
  * TEGRA_PLL_LOCK_MISC - Lock bit is in the misc register instead of the
  *     base register.
+ * TEGRA_PLL_BYPASS - PLL has bypass bit
  */
 struct tegra_clk_pll {
 	struct clk_hw	hw;
@@ -213,6 +214,7 @@ struct tegra_clk_pll {
 #define TEGRA_PLL_FIXED BIT(6)
 #define TEGRA_PLLE_CONFIGURE BIT(7)
 #define TEGRA_PLL_LOCK_MISC BIT(8)
+#define TEGRA_PLL_BYPASS BIT(9)
 
 extern const struct clk_ops tegra_clk_pll_ops;
 extern const struct clk_ops tegra_clk_plle_ops;
-- 
1.7.7.rc0.72.g4b5ea.dirty



From thierry.reding at avionic-design.de  Wed Apr  3 10:45:13 2013
From: thierry.reding at avionic-design.de (Thierry Reding)
Date: Wed,  3 Apr 2013 16:45:13 +0200
Subject: [PATCH v3 07/12] PCI: tegra: Move PCIe driver to drivers/pci/host
In-Reply-To: <1365000318-28256-1-git-send-email-thierry.reding@avionic-design.de>
References: <1365000318-28256-1-git-send-email-thierry.reding@avionic-design.de>
Message-ID: <1365000318-28256-8-git-send-email-thierry.reding@avionic-design.de>

Move the PCIe driver from arch/arm/mach-tegra into the drivers/pci/host
directory. The motivation is to collect various host controller drivers
in the same location in order to facilitate refactoring.

The Tegra PCIe driver has been largely rewritten, both in order to turn
it into a proper platform driver and to add MSI (based on code by
Krishna Kishore <kthota at nvidia.com>) as well as device tree support.

Signed-off-by: Thierry Reding <thierry.reding at avionic-design.de>
---
Changes in v2:
- remove Harmony and TrimSlice leftovers
- use symbolic names for interrupt codes
- fix root port reset sequence
- depend on ARCH_TEGRA
- only enable configured root ports
- make regulators mandatory
- fix build with !PCI_MSI
- derive XBAR configuration from nvidia,num-lanes property
- remap configuration space on a per-bus basis

Changes in v3:
- move Tegra30 specific bits into a follow-up patch
- update DT binding to be more spec-conformant
- update for recent OF ranges parser changes
- use new MSI chip infrastructure

 .../bindings/pci/nvidia,tegra20-pcie.txt           |  123 ++
 arch/arm/boot/dts/tegra20.dtsi                     |   53 +
 arch/arm/mach-tegra/Kconfig                        |    7 +-
 arch/arm/mach-tegra/Makefile                       |    3 -
 arch/arm/mach-tegra/board-harmony-pcie.c           |   89 --
 arch/arm/mach-tegra/board.h                        |    8 -
 arch/arm/mach-tegra/iomap.h                        |    3 -
 arch/arm/mach-tegra/pcie.c                         |  864 -----------
 arch/arm/mach-tegra/tegra.c                        |   24 -
 drivers/pci/Kconfig                                |    2 +
 drivers/pci/Makefile                               |    3 +
 drivers/pci/host/Kconfig                           |    8 +
 drivers/pci/host/Makefile                          |    1 +
 drivers/pci/host/pci-tegra.c                       | 1560 ++++++++++++++++++++
 14 files changed, 1752 insertions(+), 996 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt
 delete mode 100644 arch/arm/mach-tegra/board-harmony-pcie.c
 delete mode 100644 arch/arm/mach-tegra/pcie.c
 create mode 100644 drivers/pci/host/Kconfig
 create mode 100644 drivers/pci/host/Makefile
 create mode 100644 drivers/pci/host/pci-tegra.c

diff --git a/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt b/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt
new file mode 100644
index 0000000..55f6248
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt
@@ -0,0 +1,123 @@
+NVIDIA Tegra PCIe controller
+
+Required properties:
+- compatible: "nvidia,tegra20-pcie"
+- device_type: must be "pci"
+- reg: physical base address and length of the controller's registers
+- reg-names: list of names to identify entries in the reg property
+- interrupts: the interrupt outputs of the controller
+- interrupt-names: list of names to identify interrupts
+- pex-clk-supply: supply voltage for internal reference clock
+- vdd-supply: power supply for controller (1.05V)
+- bus-range: range of bus numbers associated with this controller
+- #address-cells: address representation for root ports (must be 3)
+  - cell 0 specifies the bus and device numbers of the root port:
+    [23:16]: bus number
+    [15:11]: device number
+  - cell 1 denotes the upper 32 address bits and should be 0
+  - cell 2 contains the lower 32 address bits and is used to translate to the
+    CPU address space
+- #size-cells: size representation for root ports (must be 2)
+- ranges: describes the translation of addresses for root ports
+- clocks: the clock inputs of the controller
+- clock-names: list of names to identify clocks
+
+Root ports are defined as subnodes of the PCIe controller node.
+
+Required properties:
+- device_type: must be "pci"
+- assigned-addresses: address and size of the port configuration registers
+- reg: PCI bus address of the root port
+- #address-cells: must be 3
+- #size-cells: must be 2
+- ranges: sub-ranges distributed from the PCIe controller node
+- nvidia,num-lanes: number of lanes to use for this port
+
+Example:
+
+SoC DTSI:
+
+	pcie-controller {
+		compatible = "nvidia,tegra20-pcie";
+		device_type = "pci";
+		reg = <0x80003000 0x00000800   /* PADS registers */
+		       0x80003800 0x00000200   /* AFI registers */
+		       0x90000000 0x10000000>; /* configuration space */
+		reg-names = "pads", "afi", "cs";
+		interrupts = <0 98 0x04   /* controller interrupt */
+		              0 99 0x04>; /* MSI interrupt */
+		interrupt-names = "intr", "msi";
+
+		bus-range = <0x00 0xff>;
+		#address-cells = <3>;
+		#size-cells = <2>;
+
+		ranges = <0x82000000 0 0x80000000 0x80000000 0 0x00001000   /* port 0 registers */
+			  0x82000000 0 0x80001000 0x80001000 0 0x00001000   /* port 1 registers */
+			  0x81000000 0 0          0x82000000 0 0x00010000   /* downstream I/O */
+			  0x82000000 0 0xa0000000 0xa0000000 0 0x10000000   /* non-prefetchable memory */
+			  0xc2000000 0 0xb0000000 0xb0000000 0 0x10000000>; /* prefetchable memory */
+
+		clocks = <&tegra_car 70>, <&tegra_car 72>, <&tegra_car 74>,
+			 <&tegra_car 118>;
+		clock-names = "pex", "afi", "pcie_xclk", "pll_e";
+		status = "disabled";
+
+		pci at 1,0 {
+			device_type = "pci";
+			assigned-addresses = <0x82000800 0 0x80000000 0 0x1000>;
+			reg = <0x000800 0 0 0 0>;
+			status = "disabled";
+
+			#address-cells = <3>;
+			#size-cells = <2>;
+
+			ranges;
+
+			nvidia,num-lanes = <2>;
+		};
+
+		pci at 2,0 {
+			device_type = "pci";
+			assigned-addresses = <0x82001000 0 0x80001000 0 0x1000>;
+			reg = <0x001000 0 0 0 0>;
+			status = "disabled";
+
+			#address-cells = <3>;
+			#size-cells = <2>;
+
+			ranges;
+
+			nvidia,num-lanes = <2>;
+		};
+	};
+
+
+Board DTS:
+
+	pcie-controller {
+		status = "okay";
+
+		vdd-supply = <&pci_vdd_reg>;
+		pex-clk-supply = <&pci_clk_reg>;
+
+		/* root port 00:01.0 */
+		pci at 1,0 {
+			status = "okay";
+
+			/* bridge 01:00.0 */
+			pci at 0,0 {
+				reg = <0x010000 0 0 0 0>;
+
+				#address-cells = <3>;
+				#size-cells = <2>;
+
+				device_type = "pci";
+
+				/* endpoint 02:00.0 */
+				pci at 0,0 {
+					reg = <0x020000 0 0 0 0>;
+				};
+			};
+		};
+	};
diff --git a/arch/arm/boot/dts/tegra20.dtsi b/arch/arm/boot/dts/tegra20.dtsi
index 431a5e0..ec111b7 100644
--- a/arch/arm/boot/dts/tegra20.dtsi
+++ b/arch/arm/boot/dts/tegra20.dtsi
@@ -451,6 +451,59 @@
 		#size-cells = <0>;
 	};
 
+	pcie-controller {
+		compatible = "nvidia,tegra20-pcie";
+		device_type = "pci";
+		reg = <0x80003000 0x00000800   /* PADS registers */
+		       0x80003800 0x00000200   /* AFI registers */
+		       0x90000000 0x10000000>; /* configuration space */
+		reg-names = "pads", "afi", "cs";
+		interrupts = <0 98 0x04   /* controller interrupt */
+		              0 99 0x04>; /* MSI interrupt */
+		interrupt-names = "intr", "msi";
+
+		bus-range = <0x00 0xff>;
+		#address-cells = <3>;
+		#size-cells = <2>;
+
+		ranges = <0x82000000 0 0x80000000 0x80000000 0 0x00001000   /* port 0 registers */
+			  0x82000000 0 0x80001000 0x80001000 0 0x00001000   /* port 1 registers */
+			  0x81000000 0 0          0x82000000 0 0x00010000   /* downstream I/O */
+			  0x82000000 0 0xa0000000 0xa0000000 0 0x10000000   /* non-prefetchable memory */
+			  0xc2000000 0 0xb0000000 0xb0000000 0 0x10000000>; /* prefetchable memory */
+
+		clocks = <&tegra_car 70>, <&tegra_car 72>, <&tegra_car 74>,
+			 <&tegra_car 118>;
+		clock-names = "pex", "afi", "pcie_xclk", "pll_e";
+		status = "disabled";
+
+		pci at 1,0 {
+			device_type = "pci";
+			assigned-addresses = <0x82000800 0 0x80000000 0 0x1000>;
+			reg = <0x000800 0 0 0 0>;
+			status = "disabled";
+
+			#address-cells = <3>;
+			#size-cells = <2>;
+			ranges;
+
+			nvidia,num-lanes = <2>;
+		};
+
+		pci at 2,0 {
+			device_type = "pci";
+			assigned-addresses = <0x82001000 0 0x80001000 0 0x1000>;
+			reg = <0x001000 0 0 0 0>;
+			status = "disabled";
+
+			#address-cells = <3>;
+			#size-cells = <2>;
+			ranges;
+
+			nvidia,num-lanes = <2>;
+		};
+	};
+
 	usb at c5000000 {
 		compatible = "nvidia,tegra20-ehci", "usb-ehci";
 		reg = <0xc5000000 0x4000>;
diff --git a/arch/arm/mach-tegra/Kconfig b/arch/arm/mach-tegra/Kconfig
index 661ba32..8c9b6d2 100644
--- a/arch/arm/mach-tegra/Kconfig
+++ b/arch/arm/mach-tegra/Kconfig
@@ -13,6 +13,8 @@ config ARCH_TEGRA
 	select SOC_BUS
 	select SPARSE_IRQ
 	select USE_OF
+	select MIGHT_HAVE_PCI
+	select ARCH_SUPPORTS_MSI
 	help
 	  This enables support for NVIDIA Tegra based systems.
 
@@ -68,11 +70,6 @@ config ARCH_TEGRA_114_SOC
 	  Support for NVIDIA Tegra T114 processor family, based on the
 	  ARM CortexA15MP CPU
 
-config TEGRA_PCI
-	bool "PCI Express support"
-	depends on ARCH_TEGRA_2x_SOC
-	select PCI
-
 config TEGRA_AHB
 	bool "Enable AHB driver for NVIDIA Tegra SoCs"
 	default y
diff --git a/arch/arm/mach-tegra/Makefile b/arch/arm/mach-tegra/Makefile
index e40326d..ba89d7c 100644
--- a/arch/arm/mach-tegra/Makefile
+++ b/arch/arm/mach-tegra/Makefile
@@ -26,13 +26,10 @@ endif
 obj-$(CONFIG_SMP)			+= platsmp.o headsmp.o
 obj-$(CONFIG_HOTPLUG_CPU)               += hotplug.o
 obj-$(CONFIG_CPU_FREQ)                  += cpu-tegra.o
-obj-$(CONFIG_TEGRA_PCI)			+= pcie.o
 
 obj-$(CONFIG_ARCH_TEGRA_114_SOC)	+= tegra114_speedo.o
 ifeq ($(CONFIG_CPU_IDLE),y)
 obj-$(CONFIG_ARCH_TEGRA_114_SOC)	+= cpuidle-tegra114.o
 endif
 
-obj-$(CONFIG_ARCH_TEGRA_2x_SOC)		+= board-harmony-pcie.o
-
 obj-$(CONFIG_ARCH_TEGRA_2x_SOC)		+= board-paz00.o
diff --git a/arch/arm/mach-tegra/board-harmony-pcie.c b/arch/arm/mach-tegra/board-harmony-pcie.c
deleted file mode 100644
index 035b240..0000000
--- a/arch/arm/mach-tegra/board-harmony-pcie.c
+++ /dev/null
@@ -1,89 +0,0 @@
-/*
- * arch/arm/mach-tegra/board-harmony-pcie.c
- *
- * Copyright (C) 2010 CompuLab, Ltd.
- * Mike Rapoport <mike at compulab.co.il>
- *
- * This software is licensed under the terms of the GNU General Public
- * License version 2, as published by the Free Software Foundation, and
- * may be copied, distributed, and modified under those terms.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- */
-
-#include <linux/kernel.h>
-#include <linux/gpio.h>
-#include <linux/err.h>
-#include <linux/of_gpio.h>
-#include <linux/regulator/consumer.h>
-
-#include <asm/mach-types.h>
-
-#include "board.h"
-
-#ifdef CONFIG_TEGRA_PCI
-
-int __init harmony_pcie_init(void)
-{
-	struct device_node *np;
-	int en_vdd_1v05;
-	struct regulator *regulator = NULL;
-	int err;
-
-	np = of_find_node_by_path("/regulators/regulator at 3");
-	if (!np) {
-		pr_err("%s: of_find_node_by_path failed\n", __func__);
-		return -ENODEV;
-	}
-
-	en_vdd_1v05 = of_get_named_gpio(np, "gpio", 0);
-	if (en_vdd_1v05 < 0) {
-		pr_err("%s: of_get_named_gpio failed: %d\n", __func__,
-		       en_vdd_1v05);
-		return en_vdd_1v05;
-	}
-
-	err = gpio_request(en_vdd_1v05, "EN_VDD_1V05");
-	if (err) {
-		pr_err("%s: gpio_request failed: %d\n", __func__, err);
-		return err;
-	}
-
-	gpio_direction_output(en_vdd_1v05, 1);
-
-	regulator = regulator_get(NULL, "vdd_ldo0,vddio_pex_clk");
-	if (IS_ERR(regulator)) {
-		err = PTR_ERR(regulator);
-		pr_err("%s: regulator_get failed: %d\n", __func__, err);
-		goto err_reg;
-	}
-
-	err = regulator_enable(regulator);
-	if (err) {
-		pr_err("%s: regulator_enable failed: %d\n", __func__, err);
-		goto err_en;
-	}
-
-	err = tegra_pcie_init(true, true);
-	if (err) {
-		pr_err("%s: tegra_pcie_init failed: %d\n", __func__, err);
-		goto err_pcie;
-	}
-
-	return 0;
-
-err_pcie:
-	regulator_disable(regulator);
-err_en:
-	regulator_put(regulator);
-err_reg:
-	gpio_free(en_vdd_1v05);
-
-	return err;
-}
-
-#endif
diff --git a/arch/arm/mach-tegra/board.h b/arch/arm/mach-tegra/board.h
index 1787327..ea9e773 100644
--- a/arch/arm/mach-tegra/board.h
+++ b/arch/arm/mach-tegra/board.h
@@ -30,7 +30,6 @@ void __init tegra_init_early(void);
 void __init tegra_map_common_io(void);
 void __init tegra_init_irq(void);
 void __init tegra_dt_init_irq(void);
-int __init tegra_pcie_init(bool init_port0, bool init_port1);
 
 void tegra_init_late(void);
 
@@ -47,13 +46,6 @@ int __init tegra_powergate_debugfs_init(void);
 static inline int tegra_powergate_debugfs_init(void) { return 0; }
 #endif
 
-int __init harmony_regulator_init(void);
-#ifdef CONFIG_TEGRA_PCI
-int __init harmony_pcie_init(void);
-#else
-static inline int harmony_pcie_init(void) { return 0; }
-#endif
-
 void __init tegra_paz00_wifikill_init(void);
 
 #endif
diff --git a/arch/arm/mach-tegra/iomap.h b/arch/arm/mach-tegra/iomap.h
index 399fbca..d228421 100644
--- a/arch/arm/mach-tegra/iomap.h
+++ b/arch/arm/mach-tegra/iomap.h
@@ -278,9 +278,6 @@
 #define IO_APB_VIRT	IOMEM(0xFE300000)
 #define IO_APB_SIZE	SZ_1M
 
-#define TEGRA_PCIE_BASE		0x80000000
-#define TEGRA_PCIE_IO_BASE	(TEGRA_PCIE_BASE + SZ_4M)
-
 #define IO_TO_VIRT_BETWEEN(p, st, sz)	((p) >= (st) && (p) < ((st) + (sz)))
 #define IO_TO_VIRT_XLATE(p, pst, vst)	(((p) - (pst) + (vst)))
 
diff --git a/arch/arm/mach-tegra/pcie.c b/arch/arm/mach-tegra/pcie.c
deleted file mode 100644
index 6c1989b..0000000
--- a/arch/arm/mach-tegra/pcie.c
+++ /dev/null
@@ -1,864 +0,0 @@
-/*
- * arch/arm/mach-tegra/pci.c
- *
- * PCIe host controller driver for TEGRA(2) SOCs
- *
- * Copyright (c) 2010, CompuLab, Ltd.
- * Author: Mike Rapoport <mike at compulab.co.il>
- *
- * Based on NVIDIA PCIe driver
- * Copyright (c) 2008-2009, NVIDIA Corporation.
- *
- * Bits taken from arch/arm/mach-dove/pcie.c
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful, but WITHOUT
- * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
- * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
- * more details.
- *
- * You should have received a copy of the GNU General Public License along
- * with this program; if not, write to the Free Software Foundation, Inc.,
- * 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.
- */
-
-#include <linux/kernel.h>
-#include <linux/pci.h>
-#include <linux/interrupt.h>
-#include <linux/irq.h>
-#include <linux/clk.h>
-#include <linux/delay.h>
-#include <linux/export.h>
-#include <linux/clk/tegra.h>
-#include <linux/tegra-powergate.h>
-
-#include <asm/sizes.h>
-#include <asm/mach/pci.h>
-
-#include "board.h"
-#include "iomap.h"
-#include "pmc.h"
-
-/* Hack - need to parse this from DT */
-#define INT_PCIE_INTR 130
-
-/* register definitions */
-#define AFI_OFFSET	0x3800
-#define PADS_OFFSET	0x3000
-#define RP0_OFFSET	0x0000
-#define RP1_OFFSET	0x1000
-
-#define AFI_AXI_BAR0_SZ	0x00
-#define AFI_AXI_BAR1_SZ	0x04
-#define AFI_AXI_BAR2_SZ	0x08
-#define AFI_AXI_BAR3_SZ	0x0c
-#define AFI_AXI_BAR4_SZ	0x10
-#define AFI_AXI_BAR5_SZ	0x14
-
-#define AFI_AXI_BAR0_START	0x18
-#define AFI_AXI_BAR1_START	0x1c
-#define AFI_AXI_BAR2_START	0x20
-#define AFI_AXI_BAR3_START	0x24
-#define AFI_AXI_BAR4_START	0x28
-#define AFI_AXI_BAR5_START	0x2c
-
-#define AFI_FPCI_BAR0	0x30
-#define AFI_FPCI_BAR1	0x34
-#define AFI_FPCI_BAR2	0x38
-#define AFI_FPCI_BAR3	0x3c
-#define AFI_FPCI_BAR4	0x40
-#define AFI_FPCI_BAR5	0x44
-
-#define AFI_CACHE_BAR0_SZ	0x48
-#define AFI_CACHE_BAR0_ST	0x4c
-#define AFI_CACHE_BAR1_SZ	0x50
-#define AFI_CACHE_BAR1_ST	0x54
-
-#define AFI_MSI_BAR_SZ		0x60
-#define AFI_MSI_FPCI_BAR_ST	0x64
-#define AFI_MSI_AXI_BAR_ST	0x68
-
-#define AFI_CONFIGURATION		0xac
-#define  AFI_CONFIGURATION_EN_FPCI	(1 << 0)
-
-#define AFI_FPCI_ERROR_MASKS	0xb0
-
-#define AFI_INTR_MASK		0xb4
-#define  AFI_INTR_MASK_INT_MASK	(1 << 0)
-#define  AFI_INTR_MASK_MSI_MASK	(1 << 8)
-
-#define AFI_INTR_CODE		0xb8
-#define  AFI_INTR_CODE_MASK	0xf
-#define  AFI_INTR_MASTER_ABORT	4
-#define  AFI_INTR_LEGACY	6
-
-#define AFI_INTR_SIGNATURE	0xbc
-#define AFI_SM_INTR_ENABLE	0xc4
-
-#define AFI_AFI_INTR_ENABLE		0xc8
-#define  AFI_INTR_EN_INI_SLVERR		(1 << 0)
-#define  AFI_INTR_EN_INI_DECERR		(1 << 1)
-#define  AFI_INTR_EN_TGT_SLVERR		(1 << 2)
-#define  AFI_INTR_EN_TGT_DECERR		(1 << 3)
-#define  AFI_INTR_EN_TGT_WRERR		(1 << 4)
-#define  AFI_INTR_EN_DFPCI_DECERR	(1 << 5)
-#define  AFI_INTR_EN_AXI_DECERR		(1 << 6)
-#define  AFI_INTR_EN_FPCI_TIMEOUT	(1 << 7)
-
-#define AFI_PCIE_CONFIG					0x0f8
-#define  AFI_PCIE_CONFIG_PCIEC0_DISABLE_DEVICE		(1 << 1)
-#define  AFI_PCIE_CONFIG_PCIEC1_DISABLE_DEVICE		(1 << 2)
-#define  AFI_PCIE_CONFIG_SM2TMS0_XBAR_CONFIG_MASK	(0xf << 20)
-#define  AFI_PCIE_CONFIG_SM2TMS0_XBAR_CONFIG_SINGLE	(0x0 << 20)
-#define  AFI_PCIE_CONFIG_SM2TMS0_XBAR_CONFIG_DUAL	(0x1 << 20)
-
-#define AFI_FUSE			0x104
-#define  AFI_FUSE_PCIE_T0_GEN2_DIS	(1 << 2)
-
-#define AFI_PEX0_CTRL			0x110
-#define AFI_PEX1_CTRL			0x118
-#define  AFI_PEX_CTRL_RST		(1 << 0)
-#define  AFI_PEX_CTRL_REFCLK_EN		(1 << 3)
-
-#define RP_VEND_XP	0x00000F00
-#define  RP_VEND_XP_DL_UP	(1 << 30)
-
-#define RP_LINK_CONTROL_STATUS			0x00000090
-#define  RP_LINK_CONTROL_STATUS_LINKSTAT_MASK	0x3fff0000
-
-#define PADS_CTL_SEL		0x0000009C
-
-#define PADS_CTL		0x000000A0
-#define  PADS_CTL_IDDQ_1L	(1 << 0)
-#define  PADS_CTL_TX_DATA_EN_1L	(1 << 6)
-#define  PADS_CTL_RX_DATA_EN_1L	(1 << 10)
-
-#define PADS_PLL_CTL				0x000000B8
-#define  PADS_PLL_CTL_RST_B4SM			(1 << 1)
-#define  PADS_PLL_CTL_LOCKDET			(1 << 8)
-#define  PADS_PLL_CTL_REFCLK_MASK		(0x3 << 16)
-#define  PADS_PLL_CTL_REFCLK_INTERNAL_CML	(0 << 16)
-#define  PADS_PLL_CTL_REFCLK_INTERNAL_CMOS	(1 << 16)
-#define  PADS_PLL_CTL_REFCLK_EXTERNAL		(2 << 16)
-#define  PADS_PLL_CTL_TXCLKREF_MASK		(0x1 << 20)
-#define  PADS_PLL_CTL_TXCLKREF_DIV10		(0 << 20)
-#define  PADS_PLL_CTL_TXCLKREF_DIV5		(1 << 20)
-
-/*
- * Tegra2 defines 1GB in the AXI address map for PCIe.
- *
- * That address space is split into different regions, with sizes and
- * offsets as follows:
- *
- * 0x80000000 - 0x80003fff - PCI controller registers
- * 0x80004000 - 0x80103fff - PCI configuration space
- * 0x80104000 - 0x80203fff - PCI extended configuration space
- * 0x80203fff - 0x803fffff - unused
- * 0x80400000 - 0x8040ffff - downstream IO
- * 0x80410000 - 0x8fffffff - unused
- * 0x90000000 - 0x9fffffff - non-prefetchable memory
- * 0xa0000000 - 0xbfffffff - prefetchable memory
- */
-#define PCIE_REGS_SZ		SZ_16K
-#define PCIE_CFG_OFF		PCIE_REGS_SZ
-#define PCIE_CFG_SZ		SZ_1M
-#define PCIE_EXT_CFG_OFF	(PCIE_CFG_SZ + PCIE_CFG_OFF)
-#define PCIE_EXT_CFG_SZ		SZ_1M
-#define PCIE_IOMAP_SZ		(PCIE_REGS_SZ + PCIE_CFG_SZ + PCIE_EXT_CFG_SZ)
-
-#define MEM_BASE_0		(TEGRA_PCIE_BASE + SZ_256M)
-#define MEM_SIZE_0		SZ_128M
-#define MEM_BASE_1		(MEM_BASE_0 + MEM_SIZE_0)
-#define MEM_SIZE_1		SZ_128M
-#define PREFETCH_MEM_BASE_0	(MEM_BASE_1 + MEM_SIZE_1)
-#define PREFETCH_MEM_SIZE_0	SZ_128M
-#define PREFETCH_MEM_BASE_1	(PREFETCH_MEM_BASE_0 + PREFETCH_MEM_SIZE_0)
-#define PREFETCH_MEM_SIZE_1	SZ_128M
-
-#define  PCIE_CONF_BUS(b)	((b) << 16)
-#define  PCIE_CONF_DEV(d)	((d) << 11)
-#define  PCIE_CONF_FUNC(f)	((f) << 8)
-#define  PCIE_CONF_REG(r)	\
-	(((r) & ~0x3) | (((r) < 256) ? PCIE_CFG_OFF : PCIE_EXT_CFG_OFF))
-
-struct tegra_pcie_port {
-	int			index;
-	u8			root_bus_nr;
-	void __iomem		*base;
-
-	bool			link_up;
-
-	char			mem_space_name[16];
-	char			prefetch_space_name[20];
-	struct resource		res[2];
-};
-
-struct tegra_pcie_info {
-	struct tegra_pcie_port	port[2];
-	int			num_ports;
-
-	void __iomem		*regs;
-	struct resource		res_mmio;
-
-	struct clk		*pex_clk;
-	struct clk		*afi_clk;
-	struct clk		*pcie_xclk;
-	struct clk		*pll_e;
-};
-
-static struct tegra_pcie_info tegra_pcie;
-
-static inline void afi_writel(u32 value, unsigned long offset)
-{
-	writel(value, offset + AFI_OFFSET + tegra_pcie.regs);
-}
-
-static inline u32 afi_readl(unsigned long offset)
-{
-	return readl(offset + AFI_OFFSET + tegra_pcie.regs);
-}
-
-static inline void pads_writel(u32 value, unsigned long offset)
-{
-	writel(value, offset + PADS_OFFSET + tegra_pcie.regs);
-}
-
-static inline u32 pads_readl(unsigned long offset)
-{
-	return readl(offset + PADS_OFFSET + tegra_pcie.regs);
-}
-
-static struct tegra_pcie_port *bus_to_port(int bus)
-{
-	int i;
-
-	for (i = tegra_pcie.num_ports - 1; i >= 0; i--) {
-		int rbus = tegra_pcie.port[i].root_bus_nr;
-		if (rbus != -1 && rbus == bus)
-			break;
-	}
-
-	return i >= 0 ? tegra_pcie.port + i : NULL;
-}
-
-static int tegra_pcie_read_conf(struct pci_bus *bus, unsigned int devfn,
-				int where, int size, u32 *val)
-{
-	struct tegra_pcie_port *pp = bus_to_port(bus->number);
-	void __iomem *addr;
-
-	if (pp) {
-		if (devfn != 0) {
-			*val = 0xffffffff;
-			return PCIBIOS_DEVICE_NOT_FOUND;
-		}
-
-		addr = pp->base + (where & ~0x3);
-	} else {
-		addr = tegra_pcie.regs + (PCIE_CONF_BUS(bus->number) +
-					  PCIE_CONF_DEV(PCI_SLOT(devfn)) +
-					  PCIE_CONF_FUNC(PCI_FUNC(devfn)) +
-					  PCIE_CONF_REG(where));
-	}
-
-	*val = readl(addr);
-
-	if (size == 1)
-		*val = (*val >> (8 * (where & 3))) & 0xff;
-	else if (size == 2)
-		*val = (*val >> (8 * (where & 3))) & 0xffff;
-
-	return PCIBIOS_SUCCESSFUL;
-}
-
-static int tegra_pcie_write_conf(struct pci_bus *bus, unsigned int devfn,
-				 int where, int size, u32 val)
-{
-	struct tegra_pcie_port *pp = bus_to_port(bus->number);
-	void __iomem *addr;
-
-	u32 mask;
-	u32 tmp;
-
-	if (pp) {
-		if (devfn != 0)
-			return PCIBIOS_DEVICE_NOT_FOUND;
-
-		addr = pp->base + (where & ~0x3);
-	} else {
-		addr = tegra_pcie.regs + (PCIE_CONF_BUS(bus->number) +
-					  PCIE_CONF_DEV(PCI_SLOT(devfn)) +
-					  PCIE_CONF_FUNC(PCI_FUNC(devfn)) +
-					  PCIE_CONF_REG(where));
-	}
-
-	if (size == 4) {
-		writel(val, addr);
-		return PCIBIOS_SUCCESSFUL;
-	}
-
-	if (size == 2)
-		mask = ~(0xffff << ((where & 0x3) * 8));
-	else if (size == 1)
-		mask = ~(0xff << ((where & 0x3) * 8));
-	else
-		return PCIBIOS_BAD_REGISTER_NUMBER;
-
-	tmp = readl(addr) & mask;
-	tmp |= val << ((where & 0x3) * 8);
-	writel(tmp, addr);
-
-	return PCIBIOS_SUCCESSFUL;
-}
-
-static struct pci_ops tegra_pcie_ops = {
-	.read	= tegra_pcie_read_conf,
-	.write	= tegra_pcie_write_conf,
-};
-
-static void tegra_pcie_fixup_bridge(struct pci_dev *dev)
-{
-	u16 reg;
-
-	if ((dev->class >> 16) == PCI_BASE_CLASS_BRIDGE) {
-		pci_read_config_word(dev, PCI_COMMAND, &reg);
-		reg |= (PCI_COMMAND_IO | PCI_COMMAND_MEMORY |
-			PCI_COMMAND_MASTER | PCI_COMMAND_SERR);
-		pci_write_config_word(dev, PCI_COMMAND, reg);
-	}
-}
-DECLARE_PCI_FIXUP_FINAL(PCI_ANY_ID, PCI_ANY_ID, tegra_pcie_fixup_bridge);
-
-/* Tegra PCIE root complex wrongly reports device class */
-static void tegra_pcie_fixup_class(struct pci_dev *dev)
-{
-	dev->class = PCI_CLASS_BRIDGE_PCI << 8;
-}
-DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_NVIDIA, 0x0bf0, tegra_pcie_fixup_class);
-DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_NVIDIA, 0x0bf1, tegra_pcie_fixup_class);
-
-/* Tegra PCIE requires relaxed ordering */
-static void tegra_pcie_relax_enable(struct pci_dev *dev)
-{
-	pcie_capability_set_word(dev, PCI_EXP_DEVCTL, PCI_EXP_DEVCTL_RELAX_EN);
-}
-DECLARE_PCI_FIXUP_FINAL(PCI_ANY_ID, PCI_ANY_ID, tegra_pcie_relax_enable);
-
-static int tegra_pcie_setup(int nr, struct pci_sys_data *sys)
-{
-	struct tegra_pcie_port *pp;
-
-	if (nr >= tegra_pcie.num_ports)
-		return 0;
-
-	pp = tegra_pcie.port + nr;
-	pp->root_bus_nr = sys->busnr;
-
-	pci_ioremap_io(nr * SZ_64K, TEGRA_PCIE_IO_BASE);
-
-	/*
-	 * IORESOURCE_MEM
-	 */
-	snprintf(pp->mem_space_name, sizeof(pp->mem_space_name),
-		 "PCIe %d MEM", pp->index);
-	pp->mem_space_name[sizeof(pp->mem_space_name) - 1] = 0;
-	pp->res[0].name = pp->mem_space_name;
-	if (pp->index == 0) {
-		pp->res[0].start = MEM_BASE_0;
-		pp->res[0].end = pp->res[0].start + MEM_SIZE_0 - 1;
-	} else {
-		pp->res[0].start = MEM_BASE_1;
-		pp->res[0].end = pp->res[0].start + MEM_SIZE_1 - 1;
-	}
-	pp->res[0].flags = IORESOURCE_MEM;
-	if (request_resource(&iomem_resource, &pp->res[0]))
-		panic("Request PCIe Memory resource failed\n");
-	pci_add_resource_offset(&sys->resources, &pp->res[0], sys->mem_offset);
-
-	/*
-	 * IORESOURCE_MEM | IORESOURCE_PREFETCH
-	 */
-	snprintf(pp->prefetch_space_name, sizeof(pp->prefetch_space_name),
-		 "PCIe %d PREFETCH MEM", pp->index);
-	pp->prefetch_space_name[sizeof(pp->prefetch_space_name) - 1] = 0;
-	pp->res[1].name = pp->prefetch_space_name;
-	if (pp->index == 0) {
-		pp->res[1].start = PREFETCH_MEM_BASE_0;
-		pp->res[1].end = pp->res[1].start + PREFETCH_MEM_SIZE_0 - 1;
-	} else {
-		pp->res[1].start = PREFETCH_MEM_BASE_1;
-		pp->res[1].end = pp->res[1].start + PREFETCH_MEM_SIZE_1 - 1;
-	}
-	pp->res[1].flags = IORESOURCE_MEM | IORESOURCE_PREFETCH;
-	if (request_resource(&iomem_resource, &pp->res[1]))
-		panic("Request PCIe Prefetch Memory resource failed\n");
-	pci_add_resource_offset(&sys->resources, &pp->res[1], sys->mem_offset);
-
-	return 1;
-}
-
-static int tegra_pcie_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
-{
-	return INT_PCIE_INTR;
-}
-
-static struct pci_bus __init *tegra_pcie_scan_bus(int nr,
-						  struct pci_sys_data *sys)
-{
-	struct tegra_pcie_port *pp;
-
-	if (nr >= tegra_pcie.num_ports)
-		return NULL;
-
-	pp = tegra_pcie.port + nr;
-	pp->root_bus_nr = sys->busnr;
-
-	return pci_scan_root_bus(NULL, sys->busnr, &tegra_pcie_ops, sys,
-				 &sys->resources);
-}
-
-static struct hw_pci tegra_pcie_hw __initdata = {
-	.nr_controllers	= 2,
-	.setup		= tegra_pcie_setup,
-	.scan		= tegra_pcie_scan_bus,
-	.map_irq	= tegra_pcie_map_irq,
-};
-
-
-static irqreturn_t tegra_pcie_isr(int irq, void *arg)
-{
-	const char *err_msg[] = {
-		"Unknown",
-		"AXI slave error",
-		"AXI decode error",
-		"Target abort",
-		"Master abort",
-		"Invalid write",
-		"Response decoding error",
-		"AXI response decoding error",
-		"Transcation timeout",
-	};
-
-	u32 code, signature;
-
-	code = afi_readl(AFI_INTR_CODE) & AFI_INTR_CODE_MASK;
-	signature = afi_readl(AFI_INTR_SIGNATURE);
-	afi_writel(0, AFI_INTR_CODE);
-
-	if (code == AFI_INTR_LEGACY)
-		return IRQ_NONE;
-
-	if (code >= ARRAY_SIZE(err_msg))
-		code = 0;
-
-	/*
-	 * do not pollute kernel log with master abort reports since they
-	 * happen a lot during enumeration
-	 */
-	if (code == AFI_INTR_MASTER_ABORT)
-		pr_debug("PCIE: %s, signature: %08x\n", err_msg[code], signature);
-	else
-		pr_err("PCIE: %s, signature: %08x\n", err_msg[code], signature);
-
-	return IRQ_HANDLED;
-}
-
-static void tegra_pcie_setup_translations(void)
-{
-	u32 fpci_bar;
-	u32 size;
-	u32 axi_address;
-
-	/* Bar 0: config Bar */
-	fpci_bar = ((u32)0xfdff << 16);
-	size = PCIE_CFG_SZ;
-	axi_address = TEGRA_PCIE_BASE + PCIE_CFG_OFF;
-	afi_writel(axi_address, AFI_AXI_BAR0_START);
-	afi_writel(size >> 12, AFI_AXI_BAR0_SZ);
-	afi_writel(fpci_bar, AFI_FPCI_BAR0);
-
-	/* Bar 1: extended config Bar */
-	fpci_bar = ((u32)0xfe1 << 20);
-	size = PCIE_EXT_CFG_SZ;
-	axi_address = TEGRA_PCIE_BASE + PCIE_EXT_CFG_OFF;
-	afi_writel(axi_address, AFI_AXI_BAR1_START);
-	afi_writel(size >> 12, AFI_AXI_BAR1_SZ);
-	afi_writel(fpci_bar, AFI_FPCI_BAR1);
-
-	/* Bar 2: downstream IO bar */
-	fpci_bar = ((__u32)0xfdfc << 16);
-	size = SZ_128K;
-	axi_address = TEGRA_PCIE_IO_BASE;
-	afi_writel(axi_address, AFI_AXI_BAR2_START);
-	afi_writel(size >> 12, AFI_AXI_BAR2_SZ);
-	afi_writel(fpci_bar, AFI_FPCI_BAR2);
-
-	/* Bar 3: prefetchable memory BAR */
-	fpci_bar = (((PREFETCH_MEM_BASE_0 >> 12) & 0x0fffffff) << 4) | 0x1;
-	size =  PREFETCH_MEM_SIZE_0 +  PREFETCH_MEM_SIZE_1;
-	axi_address = PREFETCH_MEM_BASE_0;
-	afi_writel(axi_address, AFI_AXI_BAR3_START);
-	afi_writel(size >> 12, AFI_AXI_BAR3_SZ);
-	afi_writel(fpci_bar, AFI_FPCI_BAR3);
-
-	/* Bar 4: non prefetchable memory BAR */
-	fpci_bar = (((MEM_BASE_0 >> 12)	& 0x0FFFFFFF) << 4) | 0x1;
-	size = MEM_SIZE_0 + MEM_SIZE_1;
-	axi_address = MEM_BASE_0;
-	afi_writel(axi_address, AFI_AXI_BAR4_START);
-	afi_writel(size >> 12, AFI_AXI_BAR4_SZ);
-	afi_writel(fpci_bar, AFI_FPCI_BAR4);
-
-	/* Bar 5: NULL out the remaining BAR as it is not used */
-	fpci_bar = 0;
-	size = 0;
-	axi_address = 0;
-	afi_writel(axi_address, AFI_AXI_BAR5_START);
-	afi_writel(size >> 12, AFI_AXI_BAR5_SZ);
-	afi_writel(fpci_bar, AFI_FPCI_BAR5);
-
-	/* map all upstream transactions as uncached */
-	afi_writel(PHYS_OFFSET, AFI_CACHE_BAR0_ST);
-	afi_writel(0, AFI_CACHE_BAR0_SZ);
-	afi_writel(0, AFI_CACHE_BAR1_ST);
-	afi_writel(0, AFI_CACHE_BAR1_SZ);
-
-	/* No MSI */
-	afi_writel(0, AFI_MSI_FPCI_BAR_ST);
-	afi_writel(0, AFI_MSI_BAR_SZ);
-	afi_writel(0, AFI_MSI_AXI_BAR_ST);
-	afi_writel(0, AFI_MSI_BAR_SZ);
-}
-
-static int tegra_pcie_enable_controller(void)
-{
-	u32 val, reg;
-	int i, timeout;
-
-	/* Enable slot clock and pulse the reset signals */
-	for (i = 0, reg = AFI_PEX0_CTRL; i < 2; i++, reg += 0x8) {
-		val = afi_readl(reg) |  AFI_PEX_CTRL_REFCLK_EN;
-		afi_writel(val, reg);
-		val &= ~AFI_PEX_CTRL_RST;
-		afi_writel(val, reg);
-
-		val = afi_readl(reg) | AFI_PEX_CTRL_RST;
-		afi_writel(val, reg);
-	}
-
-	/* Enable dual controller and both ports */
-	val = afi_readl(AFI_PCIE_CONFIG);
-	val &= ~(AFI_PCIE_CONFIG_PCIEC0_DISABLE_DEVICE |
-		 AFI_PCIE_CONFIG_PCIEC1_DISABLE_DEVICE |
-		 AFI_PCIE_CONFIG_SM2TMS0_XBAR_CONFIG_MASK);
-	val |= AFI_PCIE_CONFIG_SM2TMS0_XBAR_CONFIG_DUAL;
-	afi_writel(val, AFI_PCIE_CONFIG);
-
-	val = afi_readl(AFI_FUSE) & ~AFI_FUSE_PCIE_T0_GEN2_DIS;
-	afi_writel(val, AFI_FUSE);
-
-	/* Initialze internal PHY, enable up to 16 PCIE lanes */
-	pads_writel(0x0, PADS_CTL_SEL);
-
-	/* override IDDQ to 1 on all 4 lanes */
-	val = pads_readl(PADS_CTL) | PADS_CTL_IDDQ_1L;
-	pads_writel(val, PADS_CTL);
-
-	/*
-	 * set up PHY PLL inputs select PLLE output as refclock,
-	 * set TX ref sel to div10 (not div5)
-	 */
-	val = pads_readl(PADS_PLL_CTL);
-	val &= ~(PADS_PLL_CTL_REFCLK_MASK | PADS_PLL_CTL_TXCLKREF_MASK);
-	val |= (PADS_PLL_CTL_REFCLK_INTERNAL_CML | PADS_PLL_CTL_TXCLKREF_DIV10);
-	pads_writel(val, PADS_PLL_CTL);
-
-	/* take PLL out of reset  */
-	val = pads_readl(PADS_PLL_CTL) | PADS_PLL_CTL_RST_B4SM;
-	pads_writel(val, PADS_PLL_CTL);
-
-	/*
-	 * Hack, set the clock voltage to the DEFAULT provided by hw folks.
-	 * This doesn't exist in the documentation
-	 */
-	pads_writel(0xfa5cfa5c, 0xc8);
-
-	/* Wait for the PLL to lock */
-	timeout = 300;
-	do {
-		val = pads_readl(PADS_PLL_CTL);
-		usleep_range(1000, 1000);
-		if (--timeout == 0) {
-			pr_err("Tegra PCIe error: timeout waiting for PLL\n");
-			return -EBUSY;
-		}
-	} while (!(val & PADS_PLL_CTL_LOCKDET));
-
-	/* turn off IDDQ override */
-	val = pads_readl(PADS_CTL) & ~PADS_CTL_IDDQ_1L;
-	pads_writel(val, PADS_CTL);
-
-	/* enable TX/RX data */
-	val = pads_readl(PADS_CTL);
-	val |= (PADS_CTL_TX_DATA_EN_1L | PADS_CTL_RX_DATA_EN_1L);
-	pads_writel(val, PADS_CTL);
-
-	/* Take the PCIe interface module out of reset */
-	tegra_periph_reset_deassert(tegra_pcie.pcie_xclk);
-
-	/* Finally enable PCIe */
-	val = afi_readl(AFI_CONFIGURATION) | AFI_CONFIGURATION_EN_FPCI;
-	afi_writel(val, AFI_CONFIGURATION);
-
-	val = (AFI_INTR_EN_INI_SLVERR | AFI_INTR_EN_INI_DECERR |
-	       AFI_INTR_EN_TGT_SLVERR | AFI_INTR_EN_TGT_DECERR |
-	       AFI_INTR_EN_TGT_WRERR | AFI_INTR_EN_DFPCI_DECERR);
-	afi_writel(val, AFI_AFI_INTR_ENABLE);
-	afi_writel(0xffffffff, AFI_SM_INTR_ENABLE);
-
-	/* FIXME: No MSI for now, only INT */
-	afi_writel(AFI_INTR_MASK_INT_MASK, AFI_INTR_MASK);
-
-	/* Disable all execptions */
-	afi_writel(0, AFI_FPCI_ERROR_MASKS);
-
-	return 0;
-}
-
-static void tegra_pcie_power_off(void)
-{
-	tegra_periph_reset_assert(tegra_pcie.pcie_xclk);
-	tegra_periph_reset_assert(tegra_pcie.afi_clk);
-	tegra_periph_reset_assert(tegra_pcie.pex_clk);
-
-	tegra_powergate_power_off(TEGRA_POWERGATE_PCIE);
-	tegra_pmc_pcie_xclk_clamp(true);
-}
-
-static int tegra_pcie_power_regate(void)
-{
-	int err;
-
-	tegra_pcie_power_off();
-
-	tegra_pmc_pcie_xclk_clamp(true);
-
-	tegra_periph_reset_assert(tegra_pcie.pcie_xclk);
-	tegra_periph_reset_assert(tegra_pcie.afi_clk);
-
-	err = tegra_powergate_sequence_power_up(TEGRA_POWERGATE_PCIE,
-						tegra_pcie.pex_clk);
-	if (err) {
-		pr_err("PCIE: powerup sequence failed: %d\n", err);
-		return err;
-	}
-
-	tegra_periph_reset_deassert(tegra_pcie.afi_clk);
-
-	tegra_pmc_pcie_xclk_clamp(false);
-
-	clk_prepare_enable(tegra_pcie.afi_clk);
-	clk_prepare_enable(tegra_pcie.pex_clk);
-	return clk_prepare_enable(tegra_pcie.pll_e);
-}
-
-static int tegra_pcie_clocks_get(void)
-{
-	int err;
-
-	tegra_pcie.pex_clk = clk_get(NULL, "pex");
-	if (IS_ERR(tegra_pcie.pex_clk))
-		return PTR_ERR(tegra_pcie.pex_clk);
-
-	tegra_pcie.afi_clk = clk_get(NULL, "afi");
-	if (IS_ERR(tegra_pcie.afi_clk)) {
-		err = PTR_ERR(tegra_pcie.afi_clk);
-		goto err_afi_clk;
-	}
-
-	tegra_pcie.pcie_xclk = clk_get(NULL, "pcie_xclk");
-	if (IS_ERR(tegra_pcie.pcie_xclk)) {
-		err =  PTR_ERR(tegra_pcie.pcie_xclk);
-		goto err_pcie_xclk;
-	}
-
-	tegra_pcie.pll_e = clk_get_sys(NULL, "pll_e");
-	if (IS_ERR(tegra_pcie.pll_e)) {
-		err = PTR_ERR(tegra_pcie.pll_e);
-		goto err_pll_e;
-	}
-
-	return 0;
-
-err_pll_e:
-	clk_put(tegra_pcie.pcie_xclk);
-err_pcie_xclk:
-	clk_put(tegra_pcie.afi_clk);
-err_afi_clk:
-	clk_put(tegra_pcie.pex_clk);
-
-	return err;
-}
-
-static void tegra_pcie_clocks_put(void)
-{
-	clk_put(tegra_pcie.pll_e);
-	clk_put(tegra_pcie.pcie_xclk);
-	clk_put(tegra_pcie.afi_clk);
-	clk_put(tegra_pcie.pex_clk);
-}
-
-static int __init tegra_pcie_get_resources(void)
-{
-	int err;
-
-	err = tegra_pcie_clocks_get();
-	if (err) {
-		pr_err("PCIE: failed to get clocks: %d\n", err);
-		return err;
-	}
-
-	err = tegra_pcie_power_regate();
-	if (err) {
-		pr_err("PCIE: failed to power up: %d\n", err);
-		goto err_pwr_on;
-	}
-
-	tegra_pcie.regs = ioremap_nocache(TEGRA_PCIE_BASE, PCIE_IOMAP_SZ);
-	if (tegra_pcie.regs == NULL) {
-		pr_err("PCIE: Failed to map PCI/AFI registers\n");
-		err = -ENOMEM;
-		goto err_map_reg;
-	}
-
-	err = request_irq(INT_PCIE_INTR, tegra_pcie_isr,
-			  IRQF_SHARED, "PCIE", &tegra_pcie);
-	if (err) {
-		pr_err("PCIE: Failed to register IRQ: %d\n", err);
-		goto err_req_io;
-	}
-	set_irq_flags(INT_PCIE_INTR, IRQF_VALID);
-
-	return 0;
-
-err_req_io:
-	iounmap(tegra_pcie.regs);
-err_map_reg:
-	tegra_pcie_power_off();
-err_pwr_on:
-	tegra_pcie_clocks_put();
-
-	return err;
-}
-
-/*
- * FIXME: If there are no PCIe cards attached, then calling this function
- * can result in the increase of the bootup time as there are big timeout
- * loops.
- */
-#define TEGRA_PCIE_LINKUP_TIMEOUT	200	/* up to 1.2 seconds */
-static bool tegra_pcie_check_link(struct tegra_pcie_port *pp, int idx,
-				  u32 reset_reg)
-{
-	u32 reg;
-	int retries = 3;
-	int timeout;
-
-	do {
-		timeout = TEGRA_PCIE_LINKUP_TIMEOUT;
-		while (timeout) {
-			reg = readl(pp->base + RP_VEND_XP);
-
-			if (reg & RP_VEND_XP_DL_UP)
-				break;
-
-			mdelay(1);
-			timeout--;
-		}
-
-		if (!timeout)  {
-			pr_err("PCIE: port %d: link down, retrying\n", idx);
-			goto retry;
-		}
-
-		timeout = TEGRA_PCIE_LINKUP_TIMEOUT;
-		while (timeout) {
-			reg = readl(pp->base + RP_LINK_CONTROL_STATUS);
-
-			if (reg & 0x20000000)
-				return true;
-
-			mdelay(1);
-			timeout--;
-		}
-
-retry:
-		/* Pulse the PEX reset */
-		reg = afi_readl(reset_reg) | AFI_PEX_CTRL_RST;
-		afi_writel(reg, reset_reg);
-		mdelay(1);
-		reg = afi_readl(reset_reg) & ~AFI_PEX_CTRL_RST;
-		afi_writel(reg, reset_reg);
-
-		retries--;
-	} while (retries);
-
-	return false;
-}
-
-static void __init tegra_pcie_add_port(int index, u32 offset, u32 reset_reg)
-{
-	struct tegra_pcie_port *pp;
-
-	pp = tegra_pcie.port + tegra_pcie.num_ports;
-
-	pp->index = -1;
-	pp->base = tegra_pcie.regs + offset;
-	pp->link_up = tegra_pcie_check_link(pp, index, reset_reg);
-
-	if (!pp->link_up) {
-		pp->base = NULL;
-		printk(KERN_INFO "PCIE: port %d: link down, ignoring\n", index);
-		return;
-	}
-
-	tegra_pcie.num_ports++;
-	pp->index = index;
-	pp->root_bus_nr = -1;
-	memset(pp->res, 0, sizeof(pp->res));
-}
-
-int __init tegra_pcie_init(bool init_port0, bool init_port1)
-{
-	int err;
-
-	if (!(init_port0 || init_port1))
-		return -ENODEV;
-
-	pcibios_min_mem = 0;
-
-	err = tegra_pcie_get_resources();
-	if (err)
-		return err;
-
-	err = tegra_pcie_enable_controller();
-	if (err)
-		return err;
-
-	/* setup the AFI address translations */
-	tegra_pcie_setup_translations();
-
-	if (init_port0)
-		tegra_pcie_add_port(0, RP0_OFFSET, AFI_PEX0_CTRL);
-
-	if (init_port1)
-		tegra_pcie_add_port(1, RP1_OFFSET, AFI_PEX1_CTRL);
-
-	pci_common_init(&tegra_pcie_hw);
-
-	return 0;
-}
diff --git a/arch/arm/mach-tegra/tegra.c b/arch/arm/mach-tegra/tegra.c
index 9cf1ab1..b339c08 100644
--- a/arch/arm/mach-tegra/tegra.c
+++ b/arch/arm/mach-tegra/tegra.c
@@ -113,28 +113,6 @@ out:
 				tegra20_auxdata_lookup, parent);
 }
 
-static void __init trimslice_init(void)
-{
-#ifdef CONFIG_TEGRA_PCI
-	int ret;
-
-	ret = tegra_pcie_init(true, true);
-	if (ret)
-		pr_err("tegra_pci_init() failed: %d\n", ret);
-#endif
-}
-
-static void __init harmony_init(void)
-{
-#ifdef CONFIG_TEGRA_PCI
-	int ret;
-
-	ret = harmony_pcie_init();
-	if (ret)
-		pr_err("harmony_pcie_init() failed: %d\n", ret);
-#endif
-}
-
 static void __init paz00_init(void)
 {
 	if (IS_ENABLED(CONFIG_ARCH_TEGRA_2x_SOC))
@@ -145,8 +123,6 @@ static struct {
 	char *machine;
 	void (*init)(void);
 } board_init_funcs[] = {
-	{ "compulab,trimslice", trimslice_init },
-	{ "nvidia,harmony", harmony_init },
 	{ "compal,paz00", paz00_init },
 };
 
diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
index 6d51aa6..ac45398 100644
--- a/drivers/pci/Kconfig
+++ b/drivers/pci/Kconfig
@@ -119,3 +119,5 @@ config PCI_IOAPIC
 config PCI_LABEL
 	def_bool y if (DMI || ACPI)
 	select NLS
+
+source "drivers/pci/host/Kconfig"
diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile
index 0c3efcf..6ebf5bf 100644
--- a/drivers/pci/Makefile
+++ b/drivers/pci/Makefile
@@ -67,3 +67,6 @@ obj-$(CONFIG_XEN_PCIDEV_FRONTEND) += xen-pcifront.o
 obj-$(CONFIG_OF) += of.o
 
 ccflags-$(CONFIG_PCI_DEBUG) := -DDEBUG
+
+# PCI host controller drivers
+obj-y += host/
diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
new file mode 100644
index 0000000..b818b24
--- /dev/null
+++ b/drivers/pci/host/Kconfig
@@ -0,0 +1,8 @@
+menu "PCI host controller drivers"
+	depends on PCI
+
+config PCI_TEGRA
+	bool "NVIDIA Tegra PCIe controller"
+	depends on ARCH_TEGRA
+
+endmenu
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
new file mode 100644
index 0000000..bf3adff
--- /dev/null
+++ b/drivers/pci/host/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_PCI_TEGRA) += pci-tegra.o
diff --git a/drivers/pci/host/pci-tegra.c b/drivers/pci/host/pci-tegra.c
new file mode 100644
index 0000000..6e17fc2
--- /dev/null
+++ b/drivers/pci/host/pci-tegra.c
@@ -0,0 +1,1560 @@
+/*
+ * PCIe host controller driver for TEGRA(2) SOCs
+ *
+ * Copyright (c) 2010, CompuLab, Ltd.
+ * Author: Mike Rapoport <mike at compulab.co.il>
+ *
+ * Based on NVIDIA PCIe driver
+ * Copyright (c) 2008-2009, NVIDIA Corporation.
+ *
+ * Bits taken from arch/arm/mach-dove/pcie.c
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.
+ */
+
+#include <linux/kernel.h>
+#include <linux/slab.h>
+#include <linux/pci.h>
+#include <linux/platform_device.h>
+#include <linux/interrupt.h>
+#include <linux/irq.h>
+#include <linux/irqdomain.h>
+#include <linux/clk.h>
+#include <linux/clk/tegra.h>
+#include <linux/delay.h>
+#include <linux/export.h>
+#include <linux/msi.h>
+#include <linux/of_address.h>
+#include <linux/of_pci.h>
+#include <linux/of_platform.h>
+#include <linux/tegra-pmc.h>
+#include <linux/tegra-powergate.h>
+#include <linux/vmalloc.h>
+#include <linux/regulator/consumer.h>
+
+#include <asm/sizes.h>
+#include <asm/mach/irq.h>
+#include <asm/mach/map.h>
+#include <asm/mach/pci.h>
+
+#define INT_PCI_MSI_NR (8 * 32)
+#define TEGRA_MAX_PORTS 2
+
+/* register definitions */
+
+#define AFI_AXI_BAR0_SZ	0x00
+#define AFI_AXI_BAR1_SZ	0x04
+#define AFI_AXI_BAR2_SZ	0x08
+#define AFI_AXI_BAR3_SZ	0x0c
+#define AFI_AXI_BAR4_SZ	0x10
+#define AFI_AXI_BAR5_SZ	0x14
+
+#define AFI_AXI_BAR0_START	0x18
+#define AFI_AXI_BAR1_START	0x1c
+#define AFI_AXI_BAR2_START	0x20
+#define AFI_AXI_BAR3_START	0x24
+#define AFI_AXI_BAR4_START	0x28
+#define AFI_AXI_BAR5_START	0x2c
+
+#define AFI_FPCI_BAR0	0x30
+#define AFI_FPCI_BAR1	0x34
+#define AFI_FPCI_BAR2	0x38
+#define AFI_FPCI_BAR3	0x3c
+#define AFI_FPCI_BAR4	0x40
+#define AFI_FPCI_BAR5	0x44
+
+#define AFI_CACHE_BAR0_SZ	0x48
+#define AFI_CACHE_BAR0_ST	0x4c
+#define AFI_CACHE_BAR1_SZ	0x50
+#define AFI_CACHE_BAR1_ST	0x54
+
+#define AFI_MSI_BAR_SZ		0x60
+#define AFI_MSI_FPCI_BAR_ST	0x64
+#define AFI_MSI_AXI_BAR_ST	0x68
+
+#define AFI_MSI_VEC0		0x6c
+#define AFI_MSI_VEC1		0x70
+#define AFI_MSI_VEC2		0x74
+#define AFI_MSI_VEC3		0x78
+#define AFI_MSI_VEC4		0x7c
+#define AFI_MSI_VEC5		0x80
+#define AFI_MSI_VEC6		0x84
+#define AFI_MSI_VEC7		0x88
+
+#define AFI_MSI_EN_VEC0		0x8c
+#define AFI_MSI_EN_VEC1		0x90
+#define AFI_MSI_EN_VEC2		0x94
+#define AFI_MSI_EN_VEC3		0x98
+#define AFI_MSI_EN_VEC4		0x9c
+#define AFI_MSI_EN_VEC5		0xa0
+#define AFI_MSI_EN_VEC6		0xa4
+#define AFI_MSI_EN_VEC7		0xa8
+
+#define AFI_CONFIGURATION		0xac
+#define  AFI_CONFIGURATION_EN_FPCI	(1 << 0)
+
+#define AFI_FPCI_ERROR_MASKS	0xb0
+
+#define AFI_INTR_MASK		0xb4
+#define  AFI_INTR_MASK_INT_MASK	(1 << 0)
+#define  AFI_INTR_MASK_MSI_MASK	(1 << 8)
+
+#define AFI_INTR_CODE			0xb8
+#define  AFI_INTR_CODE_MASK		0xf
+#define  AFI_INTR_AXI_SLAVE_ERROR	1
+#define  AFI_INTR_AXI_DECODE_ERROR	2
+#define  AFI_INTR_TARGET_ABORT		3
+#define  AFI_INTR_MASTER_ABORT		4
+#define  AFI_INTR_INVALID_WRITE		5
+#define  AFI_INTR_LEGACY		6
+#define  AFI_INTR_FPCI_DECODE_ERROR	7
+
+#define AFI_INTR_SIGNATURE	0xbc
+#define AFI_UPPER_FPCI_ADDRESS	0xc0
+#define AFI_SM_INTR_ENABLE	0xc4
+#define  AFI_SM_INTR_INTA_ASSERT	(1 << 0)
+#define  AFI_SM_INTR_INTB_ASSERT	(1 << 1)
+#define  AFI_SM_INTR_INTC_ASSERT	(1 << 2)
+#define  AFI_SM_INTR_INTD_ASSERT	(1 << 3)
+#define  AFI_SM_INTR_INTA_DEASSERT	(1 << 4)
+#define  AFI_SM_INTR_INTB_DEASSERT	(1 << 5)
+#define  AFI_SM_INTR_INTC_DEASSERT	(1 << 6)
+#define  AFI_SM_INTR_INTD_DEASSERT	(1 << 7)
+
+#define AFI_AFI_INTR_ENABLE		0xc8
+#define  AFI_INTR_EN_INI_SLVERR		(1 << 0)
+#define  AFI_INTR_EN_INI_DECERR		(1 << 1)
+#define  AFI_INTR_EN_TGT_SLVERR		(1 << 2)
+#define  AFI_INTR_EN_TGT_DECERR		(1 << 3)
+#define  AFI_INTR_EN_TGT_WRERR		(1 << 4)
+#define  AFI_INTR_EN_DFPCI_DECERR	(1 << 5)
+#define  AFI_INTR_EN_AXI_DECERR		(1 << 6)
+#define  AFI_INTR_EN_FPCI_TIMEOUT	(1 << 7)
+
+#define AFI_PCIE_CONFIG					0x0f8
+#define  AFI_PCIE_CONFIG_PCIE_DISABLE(x)		(1 << ((x) + 1))
+#define  AFI_PCIE_CONFIG_PCIE_DISABLE_ALL		0xe
+#define  AFI_PCIE_CONFIG_SM2TMS0_XBAR_CONFIG_MASK	(0xf << 20)
+#define  AFI_PCIE_CONFIG_SM2TMS0_XBAR_CONFIG_SINGLE	(0x0 << 20)
+#define  AFI_PCIE_CONFIG_SM2TMS0_XBAR_CONFIG_DUAL	(0x1 << 20)
+
+#define AFI_FUSE			0x104
+#define  AFI_FUSE_PCIE_T0_GEN2_DIS	(1 << 2)
+
+#define AFI_PEX0_CTRL			0x110
+#define AFI_PEX1_CTRL			0x118
+#define  AFI_PEX_CTRL_RST		(1 << 0)
+#define  AFI_PEX_CTRL_REFCLK_EN		(1 << 3)
+
+#define RP_VEND_XP	0x00000F00
+#define  RP_VEND_XP_DL_UP	(1 << 30)
+
+#define RP_LINK_CONTROL_STATUS			0x00000090
+#define  RP_LINK_CONTROL_STATUS_LINKSTAT_MASK	0x3fff0000
+
+#define PADS_CTL_SEL		0x0000009C
+
+#define PADS_CTL		0x000000A0
+#define  PADS_CTL_IDDQ_1L	(1 << 0)
+#define  PADS_CTL_TX_DATA_EN_1L	(1 << 6)
+#define  PADS_CTL_RX_DATA_EN_1L	(1 << 10)
+
+#define PADS_PLL_CTL				0x000000B8
+#define  PADS_PLL_CTL_RST_B4SM			(1 << 1)
+#define  PADS_PLL_CTL_LOCKDET			(1 << 8)
+#define  PADS_PLL_CTL_REFCLK_MASK		(0x3 << 16)
+#define  PADS_PLL_CTL_REFCLK_INTERNAL_CML	(0 << 16)
+#define  PADS_PLL_CTL_REFCLK_INTERNAL_CMOS	(1 << 16)
+#define  PADS_PLL_CTL_REFCLK_EXTERNAL		(2 << 16)
+#define  PADS_PLL_CTL_TXCLKREF_MASK		(0x1 << 20)
+#define  PADS_PLL_CTL_TXCLKREF_DIV10		(0 << 20)
+#define  PADS_PLL_CTL_TXCLKREF_DIV5		(1 << 20)
+
+struct tegra_msi {
+	DECLARE_BITMAP(used, INT_PCI_MSI_NR);
+	struct irq_domain *domain;
+	struct msi_chip chip;
+	unsigned long pages;
+	struct mutex lock;
+	int irq;
+};
+
+static inline struct tegra_msi *to_tegra_msi(struct msi_chip *chip)
+{
+	return container_of(chip, struct tegra_msi, chip);
+}
+
+struct tegra_pcie {
+	struct device *dev;
+
+	void __iomem *pads;
+	void __iomem *afi;
+	int irq;
+
+	struct list_head busses;
+	struct resource *cs;
+
+	struct resource io;
+	struct resource mem;
+	struct resource prefetch;
+	struct resource busn;
+
+	struct clk *pex_clk;
+	struct clk *afi_clk;
+	struct clk *pcie_xclk;
+	struct clk *pll_e;
+
+	struct tegra_msi msi;
+
+	struct list_head ports;
+	unsigned int num_ports;
+	u32 xbar_config;
+
+	struct regulator *pex_clk_supply;
+	struct regulator *vdd_supply;
+};
+
+struct tegra_pcie_port {
+	struct tegra_pcie *pcie;
+	struct list_head list;
+	struct resource regs;
+	void __iomem *base;
+	unsigned int index;
+	unsigned int lanes;
+};
+
+struct tegra_pcie_bus {
+	struct vm_struct *area;
+	struct list_head list;
+	unsigned int nr;
+};
+
+static inline struct tegra_pcie *sys_to_pcie(struct pci_sys_data *sys)
+{
+	return sys->private_data;
+}
+
+static inline void afi_writel(struct tegra_pcie *pcie, u32 value,
+			      unsigned long offset)
+{
+	writel(value, pcie->afi + offset);
+}
+
+static inline u32 afi_readl(struct tegra_pcie *pcie, unsigned long offset)
+{
+	return readl(pcie->afi + offset);
+}
+
+static inline void pads_writel(struct tegra_pcie *pcie, u32 value,
+			       unsigned long offset)
+{
+	writel(value, pcie->pads + offset);
+}
+
+static inline u32 pads_readl(struct tegra_pcie *pcie, unsigned long offset)
+{
+	return readl(pcie->pads + offset);
+}
+
+/*
+ * The configuration space mapping on Tegra is somewhat similar to the ECAM
+ * defined by PCIe. However it deviates a bit in how the 4 bits for extended
+ * register accesses are mapped:
+ *
+ *    [27:24] extended register number
+ *    [23:16] bus number
+ *    [15:11] device number
+ *    [10: 8] function number
+ *    [ 7: 0] register number
+ *
+ * Mapping the whole extended configuration space would required 256 MiB of
+ * virtual address space, only a small part of which will actually be used.
+ * To work around this, a 1 MiB of virtual addresses are allocated per bus
+ * when the bus is first accessed. When the physical range is mapped, the
+ * the bus number bits are hidden so that the extended register number bits
+ * appear as bits [19:16]. Therefore the virtual mapping looks like this:
+ *
+ *    [19:16] extended register number
+ *    [15:11] device number
+ *    [10: 8] function number
+ *    [ 7: 0] register number
+ *
+ * This is achieved by stitching together 16 chunks of 64 KiB of physical
+ * address space via the MMU.
+ */
+static unsigned long tegra_pcie_conf_offset(unsigned int devfn, int where)
+{
+	return ((where & 0xf00) << 8) | (PCI_SLOT(devfn) << 11) |
+	       (PCI_FUNC(devfn) << 8) | (where & 0xfc);
+}
+
+static struct tegra_pcie_bus *tegra_pcie_bus_alloc(struct tegra_pcie *pcie,
+						   unsigned int busnr)
+{
+	pgprot_t prot = L_PTE_PRESENT | L_PTE_YOUNG | L_PTE_DIRTY | L_PTE_XN |
+			L_PTE_MT_DEV_SHARED | L_PTE_SHARED;
+	phys_addr_t cs = pcie->cs->start;
+	struct tegra_pcie_bus *bus;
+	unsigned int i;
+	int err;
+
+	bus = kzalloc(sizeof(*bus), GFP_KERNEL);
+	if (!bus)
+		return ERR_PTR(-ENOMEM);
+
+	INIT_LIST_HEAD(&bus->list);
+	bus->nr = busnr;
+
+	/* allocate 1 MiB of virtual addresses */
+	bus->area = get_vm_area(SZ_1M, VM_IOREMAP);
+	if (!bus->area) {
+		err = -ENOMEM;
+		goto free;
+	}
+
+	/* map each of the 16 chunks of 64 KiB each */
+	for (i = 0; i < 16; i++) {
+		unsigned long virt = (unsigned long)bus->area->addr +
+				     i * SZ_64K;
+		phys_addr_t phys = cs + i * SZ_1M + busnr * SZ_64K;
+
+		err = ioremap_page_range(virt, virt + SZ_64K, phys, prot);
+		if (err < 0) {
+			dev_err(pcie->dev, "ioremap_page_range() failed: %d\n",
+				err);
+			goto unmap;
+		}
+	}
+
+	return bus;
+
+unmap:
+	vunmap(bus->area->addr);
+free:
+	kfree(bus);
+	return ERR_PTR(err);
+}
+
+/*
+ * Look up a virtual address mapping for the specified bus number. If no such
+ * mapping existis, try to create one.
+ */
+static void __iomem *tegra_pcie_bus_map(struct tegra_pcie *pcie,
+					unsigned int busnr)
+{
+	struct tegra_pcie_bus *bus;
+
+	list_for_each_entry(bus, &pcie->busses, list)
+		if (bus->nr == busnr)
+			return bus->area->addr;
+
+	bus = tegra_pcie_bus_alloc(pcie, busnr);
+	if (IS_ERR(bus))
+		return NULL;
+
+	list_add_tail(&bus->list, &pcie->busses);
+
+	return bus->area->addr;
+}
+
+static int tegra_pcie_read_conf(struct pci_bus *bus, unsigned int devfn,
+				int where, int size, u32 *value)
+{
+	struct tegra_pcie *pcie = sys_to_pcie(bus->sysdata);
+	void __iomem *addr = NULL;
+
+	if (bus->number == 0) {
+		unsigned int slot = PCI_SLOT(devfn);
+		struct tegra_pcie_port *port;
+
+		list_for_each_entry(port, &pcie->ports, list) {
+			if (port->index + 1 == slot) {
+				addr = port->base + (where & ~3);
+				break;
+			}
+		}
+	} else {
+		addr = tegra_pcie_bus_map(pcie, bus->number);
+		if (!addr) {
+			dev_err(pcie->dev,
+				"failed to map cfg. space for bus %u\n",
+				bus->number);
+			*value = 0xffffffff;
+			return PCIBIOS_DEVICE_NOT_FOUND;
+		}
+
+		addr += tegra_pcie_conf_offset(devfn, where);
+	}
+
+	if (!addr) {
+		*value = 0xffffffff;
+		return PCIBIOS_DEVICE_NOT_FOUND;
+	}
+
+	*value = readl(addr);
+
+	if (size == 1)
+		*value = (*value >> (8 * (where & 3))) & 0xff;
+	else if (size == 2)
+		*value = (*value >> (8 * (where & 3))) & 0xffff;
+
+	return PCIBIOS_SUCCESSFUL;
+}
+
+static int tegra_pcie_write_conf(struct pci_bus *bus, unsigned int devfn,
+				 int where, int size, u32 value)
+{
+	struct tegra_pcie *pcie = sys_to_pcie(bus->sysdata);
+	void __iomem *addr = NULL;
+	u32 mask, tmp;
+
+	if (bus->number == 0) {
+		unsigned int slot = PCI_SLOT(devfn);
+		struct tegra_pcie_port *port;
+
+		list_for_each_entry(port, &pcie->ports, list) {
+			if (port->index + 1 == slot) {
+				addr = port->base + (where & ~3);
+				break;
+			}
+		}
+	} else {
+		addr = tegra_pcie_bus_map(pcie, bus->number);
+		if (!addr) {
+			dev_err(pcie->dev,
+				"failed to map cfg. space for bus %u\n",
+				bus->number);
+			return PCIBIOS_DEVICE_NOT_FOUND;
+		}
+
+		addr += tegra_pcie_conf_offset(devfn, where);
+	}
+
+	if (size == 4) {
+		writel(value, addr);
+		return PCIBIOS_SUCCESSFUL;
+	}
+
+	if (size == 2)
+		mask = ~(0xffff << ((where & 0x3) * 8));
+	else if (size == 1)
+		mask = ~(0xff << ((where & 0x3) * 8));
+	else
+		return PCIBIOS_BAD_REGISTER_NUMBER;
+
+	tmp = readl(addr) & mask;
+	tmp |= value << ((where & 0x3) * 8);
+	writel(tmp, addr);
+
+	return PCIBIOS_SUCCESSFUL;
+}
+
+static struct pci_ops tegra_pcie_ops = {
+	.read = tegra_pcie_read_conf,
+	.write = tegra_pcie_write_conf,
+};
+
+static unsigned long tegra_pcie_port_get_pex_ctrl(struct tegra_pcie_port *port)
+{
+	unsigned long ret = 0;
+
+	switch (port->index) {
+	case 0:
+		ret = AFI_PEX0_CTRL;
+		break;
+
+	case 1:
+		ret = AFI_PEX1_CTRL;
+		break;
+	}
+
+	return ret;
+}
+
+static void tegra_pcie_port_reset(struct tegra_pcie_port *port)
+{
+	unsigned long ctrl = tegra_pcie_port_get_pex_ctrl(port);
+	unsigned long value;
+
+	/* pulse reset signal */
+	value = afi_readl(port->pcie, ctrl);
+	value &= ~AFI_PEX_CTRL_RST;
+	afi_writel(port->pcie, value, ctrl);
+
+	usleep_range(1000, 1000);
+
+	value = afi_readl(port->pcie, ctrl);
+	value |= AFI_PEX_CTRL_RST;
+	afi_writel(port->pcie, value, ctrl);
+}
+
+static void tegra_pcie_port_enable(struct tegra_pcie_port *port)
+{
+	unsigned long ctrl = tegra_pcie_port_get_pex_ctrl(port);
+	unsigned long value;
+
+	/* enable reference clock */
+	value = afi_readl(port->pcie, ctrl);
+	value |= AFI_PEX_CTRL_REFCLK_EN;
+	afi_writel(port->pcie, value, ctrl);
+
+	tegra_pcie_port_reset(port);
+}
+
+static void tegra_pcie_port_disable(struct tegra_pcie_port *port)
+{
+	unsigned long ctrl = tegra_pcie_port_get_pex_ctrl(port);
+	unsigned long value;
+
+	/* assert port reset */
+	value = afi_readl(port->pcie, ctrl);
+	value &= ~AFI_PEX_CTRL_RST;
+	afi_writel(port->pcie, value, ctrl);
+
+	/* disable reference clock */
+	value = afi_readl(port->pcie, ctrl);
+	value &= ~AFI_PEX_CTRL_REFCLK_EN;
+	afi_writel(port->pcie, value, ctrl);
+}
+
+static void tegra_pcie_port_free(struct tegra_pcie_port *port)
+{
+	struct tegra_pcie *pcie = port->pcie;
+
+	devm_iounmap(pcie->dev, port->base);
+	devm_release_mem_region(pcie->dev, port->regs.start,
+				resource_size(&port->regs));
+	list_del(&port->list);
+	devm_kfree(pcie->dev, port);
+}
+
+static void tegra_pcie_fixup_bridge(struct pci_dev *dev)
+{
+	u16 reg;
+
+	if ((dev->class >> 16) == PCI_BASE_CLASS_BRIDGE) {
+		pci_read_config_word(dev, PCI_COMMAND, &reg);
+		reg |= (PCI_COMMAND_IO | PCI_COMMAND_MEMORY |
+			PCI_COMMAND_MASTER | PCI_COMMAND_SERR);
+		pci_write_config_word(dev, PCI_COMMAND, reg);
+	}
+}
+DECLARE_PCI_FIXUP_FINAL(PCI_ANY_ID, PCI_ANY_ID, tegra_pcie_fixup_bridge);
+
+/* Tegra PCIE root complex wrongly reports device class */
+static void tegra_pcie_fixup_class(struct pci_dev *dev)
+{
+	dev->class = PCI_CLASS_BRIDGE_PCI << 8;
+}
+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_NVIDIA, 0x0bf0, tegra_pcie_fixup_class);
+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_NVIDIA, 0x0bf1, tegra_pcie_fixup_class);
+
+/* Tegra PCIE requires relaxed ordering */
+static void tegra_pcie_relax_enable(struct pci_dev *dev)
+{
+	pcie_capability_set_word(dev, PCI_EXP_DEVCTL, PCI_EXP_DEVCTL_RELAX_EN);
+}
+DECLARE_PCI_FIXUP_FINAL(PCI_ANY_ID, PCI_ANY_ID, tegra_pcie_relax_enable);
+
+static int tegra_pcie_setup(int nr, struct pci_sys_data *sys)
+{
+	struct tegra_pcie *pcie = sys_to_pcie(sys);
+
+	pci_add_resource_offset(&sys->resources, &pcie->mem, sys->mem_offset);
+	pci_add_resource_offset(&sys->resources, &pcie->prefetch, sys->mem_offset);
+	pci_add_resource(&sys->resources, &pcie->busn);
+
+	pci_ioremap_io(nr * SZ_64K, pcie->io.start);
+
+	return 1;
+}
+
+static int tegra_pcie_map_irq(const struct pci_dev *pdev, u8 slot, u8 pin)
+{
+	struct tegra_pcie *pcie = sys_to_pcie(pdev->bus->sysdata);
+
+	return pcie->irq;
+}
+
+static struct pci_bus *tegra_pcie_scan_bus(int nr, struct pci_sys_data *sys)
+{
+	struct tegra_pcie *pcie = sys_to_pcie(sys);
+	struct pci_host_bridge_window *window;
+	struct pci_bus *bus;
+	bool found = false;
+
+	list_for_each_entry(window, &sys->resources, list) {
+		if (window->res->flags & IORESOURCE_BUS) {
+			found = true;
+			break;
+		}
+	}
+
+	if (!found)
+		dev_err(pcie->dev, "no bus resource found!\n");
+
+	bus = pci_create_root_bus(pcie->dev, sys->busnr, &tegra_pcie_ops,
+				  sys, &sys->resources);
+	if (!bus)
+		return NULL;
+
+	if (IS_ENABLED(CONFIG_PCI_MSI))
+		bus->msi = &pcie->msi.chip;
+
+	pci_scan_child_bus(bus);
+
+	return bus;
+}
+
+static irqreturn_t tegra_pcie_isr(int irq, void *arg)
+{
+	const char *err_msg[] = {
+		"Unknown",
+		"AXI slave error",
+		"AXI decode error",
+		"Target abort",
+		"Master abort",
+		"Invalid write",
+		"Response decoding error",
+		"AXI response decoding error",
+		"Transaction timeout",
+	};
+	struct tegra_pcie *pcie = arg;
+	u32 code, signature;
+
+	code = afi_readl(pcie, AFI_INTR_CODE) & AFI_INTR_CODE_MASK;
+	signature = afi_readl(pcie, AFI_INTR_SIGNATURE);
+	afi_writel(pcie, 0, AFI_INTR_CODE);
+
+	if (code == AFI_INTR_LEGACY)
+		return IRQ_NONE;
+
+	if (code >= ARRAY_SIZE(err_msg))
+		code = 0;
+
+	/*
+	 * do not pollute kernel log with master abort reports since they
+	 * happen a lot during enumeration
+	 */
+	if (code == AFI_INTR_MASTER_ABORT)
+		dev_dbg(pcie->dev, "%s, signature: %08x\n", err_msg[code],
+			signature);
+	else
+		dev_err(pcie->dev, "%s, signature: %08x\n", err_msg[code],
+			signature);
+
+	if (code == AFI_INTR_TARGET_ABORT || code == AFI_INTR_MASTER_ABORT ||
+	    code == AFI_INTR_FPCI_DECODE_ERROR) {
+		u32 fpci = afi_readl(pcie, AFI_UPPER_FPCI_ADDRESS) & 0xff;
+		u64 address = (u64)fpci << 32 | (signature & 0xfffffffc);
+
+		if (code == AFI_INTR_MASTER_ABORT)
+			dev_dbg(pcie->dev, "  FPCI address: %10llx\n", address);
+		else
+			dev_err(pcie->dev, "  FPCI address: %10llx\n", address);
+	}
+
+	return IRQ_HANDLED;
+}
+
+/*
+ * FPCI map is as follows:
+ * - 0xfdfc000000: I/O space
+ * - 0xfdfe000000: type 0 configuration space
+ * - 0xfdff000000: type 1 configuration space
+ * - 0xfe00000000: type 0 extended configuration space
+ * - 0xfe10000000: type 1 extended configuration space
+ */
+static void tegra_pcie_setup_translations(struct tegra_pcie *pcie)
+{
+	u32 fpci_bar, size, axi_address;
+
+	/* Bar 0: type 1 extended configuration space */
+	fpci_bar = 0xfe100000;
+	size = resource_size(pcie->cs);
+	axi_address = pcie->cs->start;
+	afi_writel(pcie, axi_address, AFI_AXI_BAR0_START);
+	afi_writel(pcie, size >> 12, AFI_AXI_BAR0_SZ);
+	afi_writel(pcie, fpci_bar, AFI_FPCI_BAR0);
+
+	/* Bar 1: downstream IO bar */
+	fpci_bar = 0xfdfc0000;
+	size = resource_size(&pcie->io);
+	axi_address = pcie->io.start;
+	afi_writel(pcie, axi_address, AFI_AXI_BAR1_START);
+	afi_writel(pcie, size >> 12, AFI_AXI_BAR1_SZ);
+	afi_writel(pcie, fpci_bar, AFI_FPCI_BAR1);
+
+	/* Bar 2: prefetchable memory BAR */
+	fpci_bar = (((pcie->prefetch.start >> 12) & 0x0fffffff) << 4) | 0x1;
+	size = resource_size(&pcie->prefetch);
+	axi_address = pcie->prefetch.start;
+	afi_writel(pcie, axi_address, AFI_AXI_BAR2_START);
+	afi_writel(pcie, size >> 12, AFI_AXI_BAR2_SZ);
+	afi_writel(pcie, fpci_bar, AFI_FPCI_BAR2);
+
+	/* Bar 3: non prefetchable memory BAR */
+	fpci_bar = (((pcie->mem.start >> 12) & 0x0fffffff) << 4) | 0x1;
+	size = resource_size(&pcie->mem);
+	axi_address = pcie->mem.start;
+	afi_writel(pcie, axi_address, AFI_AXI_BAR3_START);
+	afi_writel(pcie, size >> 12, AFI_AXI_BAR3_SZ);
+	afi_writel(pcie, fpci_bar, AFI_FPCI_BAR3);
+
+	/* NULL out the remaining BARs as they are not used */
+	afi_writel(pcie, 0, AFI_AXI_BAR4_START);
+	afi_writel(pcie, 0, AFI_AXI_BAR4_SZ);
+	afi_writel(pcie, 0, AFI_FPCI_BAR4);
+
+	afi_writel(pcie, 0, AFI_AXI_BAR5_START);
+	afi_writel(pcie, 0, AFI_AXI_BAR5_SZ);
+	afi_writel(pcie, 0, AFI_FPCI_BAR5);
+
+	/* map all upstream transactions as uncached */
+	afi_writel(pcie, PHYS_OFFSET, AFI_CACHE_BAR0_ST);
+	afi_writel(pcie, 0, AFI_CACHE_BAR0_SZ);
+	afi_writel(pcie, 0, AFI_CACHE_BAR1_ST);
+	afi_writel(pcie, 0, AFI_CACHE_BAR1_SZ);
+
+	/* MSI translations are setup only when needed */
+	afi_writel(pcie, 0, AFI_MSI_FPCI_BAR_ST);
+	afi_writel(pcie, 0, AFI_MSI_BAR_SZ);
+	afi_writel(pcie, 0, AFI_MSI_AXI_BAR_ST);
+	afi_writel(pcie, 0, AFI_MSI_BAR_SZ);
+}
+
+static int tegra_pcie_enable_controller(struct tegra_pcie *pcie)
+{
+	struct tegra_pcie_port *port;
+	unsigned int timeout;
+	unsigned long value;
+
+	/* configure mode and disable all ports */
+	value = afi_readl(pcie, AFI_PCIE_CONFIG);
+	value &= ~AFI_PCIE_CONFIG_SM2TMS0_XBAR_CONFIG_MASK;
+	value |= AFI_PCIE_CONFIG_PCIE_DISABLE_ALL | pcie->xbar_config;
+
+	list_for_each_entry(port, &pcie->ports, list)
+		value &= ~AFI_PCIE_CONFIG_PCIE_DISABLE(port->index);
+
+	afi_writel(pcie, value, AFI_PCIE_CONFIG);
+
+	value = afi_readl(pcie, AFI_FUSE);
+	value &= ~AFI_FUSE_PCIE_T0_GEN2_DIS;
+	afi_writel(pcie, value, AFI_FUSE);
+
+	/* initialze internal PHY, enable up to 16 PCIE lanes */
+	pads_writel(pcie, 0x0, PADS_CTL_SEL);
+
+	/* override IDDQ to 1 on all 4 lanes */
+	value = pads_readl(pcie, PADS_CTL);
+	value |= PADS_CTL_IDDQ_1L;
+	pads_writel(pcie, value, PADS_CTL);
+
+	/*
+	 * Set up PHY PLL inputs select PLLE output as refclock,
+	 * set TX ref sel to div10 (not div5).
+	 */
+	value = pads_readl(pcie, PADS_PLL_CTL);
+	value &= ~(PADS_PLL_CTL_REFCLK_MASK | PADS_PLL_CTL_TXCLKREF_MASK);
+	value |= (PADS_PLL_CTL_REFCLK_INTERNAL_CML | PADS_PLL_CTL_TXCLKREF_DIV10);
+	pads_writel(pcie, value, PADS_PLL_CTL);
+
+	/* take PLL out of reset  */
+	value = pads_readl(pcie, PADS_PLL_CTL);
+	value |= PADS_PLL_CTL_RST_B4SM;
+	pads_writel(pcie, value, PADS_PLL_CTL);
+
+	/*
+	 * Hack, set the clock voltage to the DEFAULT provided by hw folks.
+	 * This doesn't exist in the documentation.
+	 */
+	pads_writel(pcie, 0xfa5cfa5c, 0xc8);
+
+	/* wait for the PLL to lock */
+	timeout = 300;
+	do {
+		value = pads_readl(pcie, PADS_PLL_CTL);
+		usleep_range(1000, 1000);
+		if (--timeout == 0) {
+			pr_err("Tegra PCIe error: timeout waiting for PLL\n");
+			return -EBUSY;
+		}
+	} while (!(value & PADS_PLL_CTL_LOCKDET));
+
+	/* turn off IDDQ override */
+	value = pads_readl(pcie, PADS_CTL);
+	value &= ~PADS_CTL_IDDQ_1L;
+	pads_writel(pcie, value, PADS_CTL);
+
+	/* enable TX/RX data */
+	value = pads_readl(pcie, PADS_CTL);
+	value |= PADS_CTL_TX_DATA_EN_1L | PADS_CTL_RX_DATA_EN_1L;
+	pads_writel(pcie, value, PADS_CTL);
+
+	/* take the PCIe interface module out of reset */
+	tegra_periph_reset_deassert(pcie->pcie_xclk);
+
+	/* finally enable PCIe */
+	value = afi_readl(pcie, AFI_CONFIGURATION);
+	value |= AFI_CONFIGURATION_EN_FPCI;
+	afi_writel(pcie, value, AFI_CONFIGURATION);
+
+	value = AFI_INTR_EN_INI_SLVERR | AFI_INTR_EN_INI_DECERR |
+		AFI_INTR_EN_TGT_SLVERR | AFI_INTR_EN_TGT_DECERR |
+		AFI_INTR_EN_TGT_WRERR | AFI_INTR_EN_DFPCI_DECERR;
+	afi_writel(pcie, value, AFI_AFI_INTR_ENABLE);
+	afi_writel(pcie, 0xffffffff, AFI_SM_INTR_ENABLE);
+
+	/* don't enable MSI for now, only when needed */
+	afi_writel(pcie, AFI_INTR_MASK_INT_MASK, AFI_INTR_MASK);
+
+	/* disable all exceptions */
+	afi_writel(pcie, 0, AFI_FPCI_ERROR_MASKS);
+
+	return 0;
+}
+
+static void tegra_pcie_power_off(struct tegra_pcie *pcie)
+{
+	int err;
+
+	/* TODO: disable and unprepare clocks? */
+
+	tegra_periph_reset_assert(pcie->pcie_xclk);
+	tegra_periph_reset_assert(pcie->afi_clk);
+	tegra_periph_reset_assert(pcie->pex_clk);
+
+	tegra_powergate_power_off(TEGRA_POWERGATE_PCIE);
+	tegra_pmc_pcie_xclk_clamp(true);
+
+	err = regulator_disable(pcie->pex_clk_supply);
+	if (err < 0)
+		dev_err(pcie->dev, "failed to disable pex-clk regulator: %d\n",
+			err);
+
+	err = regulator_disable(pcie->vdd_supply);
+	if (err < 0)
+		dev_err(pcie->dev, "failed to disable VDD regulator: %d\n",
+			err);
+}
+
+static int tegra_pcie_power_on(struct tegra_pcie *pcie)
+{
+	int err;
+
+	tegra_periph_reset_assert(pcie->pcie_xclk);
+	tegra_periph_reset_assert(pcie->afi_clk);
+	tegra_periph_reset_assert(pcie->pex_clk);
+
+	tegra_powergate_power_off(TEGRA_POWERGATE_PCIE);
+	tegra_pmc_pcie_xclk_clamp(true);
+
+	/* enable regulators */
+	err = regulator_enable(pcie->vdd_supply);
+	if (err < 0) {
+		dev_err(pcie->dev, "failed to enable VDD regulator: %d\n", err);
+		return err;
+	}
+
+	err = regulator_enable(pcie->pex_clk_supply);
+	if (err < 0) {
+		dev_err(pcie->dev, "failed to enable pex-clk regulator: %d\n",
+			err);
+		return err;
+	}
+
+	err = tegra_powergate_sequence_power_up(TEGRA_POWERGATE_PCIE,
+						pcie->pex_clk);
+	if (err) {
+		dev_err(pcie->dev, "powerup sequence failed: %d\n", err);
+		return err;
+	}
+
+	tegra_periph_reset_deassert(pcie->afi_clk);
+
+	tegra_pmc_pcie_xclk_clamp(false);
+
+	err = clk_prepare_enable(pcie->afi_clk);
+	if (err < 0) {
+		dev_err(pcie->dev, "failed to enable AFI clock: %d\n", err);
+		return err;
+	}
+
+	err = clk_prepare_enable(pcie->pll_e);
+	if (err < 0) {
+		dev_err(pcie->dev, "failed to enable PLLE clock: %d\n", err);
+		return err;
+	}
+
+	return 0;
+}
+
+static int tegra_pcie_clocks_get(struct tegra_pcie *pcie)
+{
+	pcie->pex_clk = devm_clk_get(pcie->dev, "pex");
+	if (IS_ERR(pcie->pex_clk))
+		return PTR_ERR(pcie->pex_clk);
+
+	pcie->afi_clk = devm_clk_get(pcie->dev, "afi");
+	if (IS_ERR(pcie->afi_clk))
+		return PTR_ERR(pcie->afi_clk);
+
+	pcie->pcie_xclk = devm_clk_get(pcie->dev, "pcie_xclk");
+	if (IS_ERR(pcie->pcie_xclk))
+		return PTR_ERR(pcie->pcie_xclk);
+
+	pcie->pll_e = devm_clk_get(pcie->dev, "pll_e");
+	if (IS_ERR(pcie->pll_e))
+		return PTR_ERR(pcie->pll_e);
+
+	return 0;
+}
+
+static int tegra_pcie_get_resources(struct tegra_pcie *pcie)
+{
+	struct platform_device *pdev = to_platform_device(pcie->dev);
+	struct resource *pads, *afi, *res;
+	int err;
+
+	err = tegra_pcie_clocks_get(pcie);
+	if (err) {
+		dev_err(&pdev->dev, "failed to get clocks: %d\n", err);
+		return err;
+	}
+
+	err = tegra_pcie_power_on(pcie);
+	if (err) {
+		dev_err(&pdev->dev, "failed to power up: %d\n", err);
+		return err;
+	}
+
+	/* request and remap controller registers */
+	pads = platform_get_resource_byname(pdev, IORESOURCE_MEM, "pads");
+	if (!pads) {
+		err = -EADDRNOTAVAIL;
+		goto poweroff;
+	}
+
+	afi = platform_get_resource_byname(pdev, IORESOURCE_MEM, "afi");
+	if (!afi) {
+		err = -EADDRNOTAVAIL;
+		goto poweroff;
+	}
+
+	pcie->pads = devm_request_and_ioremap(&pdev->dev, pads);
+	if (!pcie->pads) {
+		err = -EADDRNOTAVAIL;
+		goto poweroff;
+	}
+
+	pcie->afi = devm_request_and_ioremap(&pdev->dev, afi);
+	if (!pcie->afi) {
+		err = -EADDRNOTAVAIL;
+		goto poweroff;
+	}
+
+	/* request and remap configuration space */
+	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "cs");
+	if (!res) {
+		err = -EADDRNOTAVAIL;
+		goto poweroff;
+	}
+
+	pcie->cs = devm_request_mem_region(pcie->dev, res->start,
+					   resource_size(res), res->name);
+	if (!pcie->cs) {
+		err = -EADDRNOTAVAIL;
+		goto poweroff;
+	}
+
+	/* request interrupt */
+	err = platform_get_irq_byname(pdev, "intr");
+	if (err < 0) {
+		dev_err(&pdev->dev, "failed to get IRQ: %d\n", err);
+		goto poweroff;
+	}
+
+	pcie->irq = err;
+
+	err = devm_request_irq(&pdev->dev, pcie->irq, tegra_pcie_isr,
+			       IRQF_SHARED, "PCIE", pcie);
+	if (err) {
+		dev_err(&pdev->dev, "failed to register IRQ: %d\n", err);
+		goto poweroff;
+	}
+
+	return 0;
+
+poweroff:
+	tegra_pcie_power_off(pcie);
+	return err;
+}
+
+static int tegra_pcie_put_resources(struct tegra_pcie *pcie)
+{
+	tegra_pcie_power_off(pcie);
+	return 0;
+}
+
+static int tegra_msi_alloc(struct tegra_msi *chip)
+{
+	int msi;
+
+	mutex_lock(&chip->lock);
+
+	msi = find_first_zero_bit(chip->used, INT_PCI_MSI_NR);
+	if (msi < INT_PCI_MSI_NR)
+		set_bit(msi, chip->used);
+	else
+		msi = -ENOSPC;
+
+	mutex_unlock(&chip->lock);
+
+	return msi;
+}
+
+static void tegra_msi_free(struct tegra_msi *chip, unsigned long irq)
+{
+	struct device *dev = chip->chip.dev;
+
+	mutex_lock(&chip->lock);
+
+	if (!test_bit(irq, chip->used))
+		dev_err(dev, "trying to free unused MSI#%lu\n", irq);
+	else
+		clear_bit(irq, chip->used);
+
+	mutex_unlock(&chip->lock);
+}
+
+static irqreturn_t tegra_pcie_msi_irq(int irq, void *data)
+{
+	struct tegra_pcie *pcie = data;
+	struct tegra_msi *msi = &pcie->msi;
+	unsigned int i;
+
+	for (i = 0; i < 8; i++) {
+		unsigned long reg = afi_readl(pcie, AFI_MSI_VEC0 + i * 4);
+
+		while (reg) {
+			unsigned int offset = find_first_bit(&reg, 32);
+			unsigned int index = i * 32 + offset;
+			unsigned int irq;
+
+			/* clear the interrupt */
+			afi_writel(pcie, 1 << offset, AFI_MSI_VEC0 + i * 4);
+
+			irq = irq_find_mapping(msi->domain, index);
+			if (irq) {
+				if (test_bit(index, msi->used))
+					generic_handle_irq(irq);
+				else
+					dev_info(pcie->dev, "unhandled MSI\n");
+			} else {
+				/*
+				 * that's weird who triggered this?
+				 * just clear it
+				 */
+				dev_info(pcie->dev, "unexpected MSI\n");
+			}
+
+			/* see if there's any more pending in this vector */
+			reg = afi_readl(pcie, AFI_MSI_VEC0 + i * 4);
+		}
+	}
+
+	return IRQ_HANDLED;
+}
+
+static int tegra_msi_setup_irq(struct msi_chip *chip, struct pci_dev *pdev,
+			       struct msi_desc *desc)
+{
+	struct tegra_msi *msi = to_tegra_msi(chip);
+	struct tegra_pcie *pcie = container_of(chip, struct tegra_pcie, msi.chip);
+	struct msi_msg msg;
+	unsigned int irq;
+	int hwirq;
+
+	hwirq = tegra_msi_alloc(msi);
+	if (hwirq < 0)
+		return hwirq;
+
+	irq = irq_create_mapping(msi->domain, hwirq);
+	if (!irq)
+		return -EINVAL;
+
+	irq_set_msi_desc(irq, desc);
+
+	msg.address_lo = afi_readl(pcie, AFI_MSI_AXI_BAR_ST);
+	/* 32 bit address only */
+	msg.address_hi = 0;
+	msg.data = hwirq;
+
+	write_msi_msg(irq, &msg);
+
+	return 0;
+}
+
+static void tegra_msi_teardown_irq(struct msi_chip *chip, unsigned int irq)
+{
+	struct tegra_msi *msi = to_tegra_msi(chip);
+	struct irq_data *d = irq_get_irq_data(irq);
+
+	tegra_msi_free(msi, d->hwirq);
+}
+
+static struct irq_chip tegra_msi_irq_chip = {
+	.name = "Tegra PCIe MSI",
+	.irq_enable = unmask_msi_irq,
+	.irq_disable = mask_msi_irq,
+	.irq_mask = mask_msi_irq,
+	.irq_unmask = unmask_msi_irq,
+};
+
+static int tegra_msi_map(struct irq_domain *domain, unsigned int irq,
+			 irq_hw_number_t hwirq)
+{
+	irq_set_chip_and_handler(irq, &tegra_msi_irq_chip, handle_simple_irq);
+	irq_set_chip_data(irq, domain->host_data);
+	set_irq_flags(irq, IRQF_VALID);
+
+	return 0;
+}
+
+static const struct irq_domain_ops msi_domain_ops = {
+	.map = tegra_msi_map,
+};
+
+static int tegra_pcie_enable_msi(struct tegra_pcie *pcie)
+{
+	struct platform_device *pdev = to_platform_device(pcie->dev);
+	struct tegra_msi *msi = &pcie->msi;
+	unsigned long base;
+	int err;
+	u32 reg;
+
+	mutex_init(&msi->lock);
+
+	msi->chip.dev = pcie->dev;
+	msi->chip.setup_irq = tegra_msi_setup_irq;
+	msi->chip.teardown_irq = tegra_msi_teardown_irq;
+
+	msi->domain = irq_domain_add_linear(pcie->dev->of_node, INT_PCI_MSI_NR,
+					    &msi_domain_ops, &msi->chip);
+	if (!msi->domain) {
+		dev_err(&pdev->dev, "failed to create IRQ domain\n");
+		return -ENOMEM;
+	}
+
+	err = platform_get_irq_byname(pdev, "msi");
+	if (err < 0) {
+		dev_err(&pdev->dev, "failed to get IRQ: %d\n", err);
+		goto err;
+	}
+
+	msi->irq = err;
+
+	err = devm_request_irq(&pdev->dev, msi->irq, tegra_pcie_msi_irq,
+			       0, tegra_msi_irq_chip.name, pcie);
+	if (err < 0) {
+		dev_err(&pdev->dev, "failed to request IRQ: %d\n", err);
+		goto err;
+	}
+
+	/* setup AFI/FPCI range */
+	msi->pages = __get_free_pages(GFP_KERNEL, 3);
+	base = virt_to_phys((void *)msi->pages);
+
+	afi_writel(pcie, base, AFI_MSI_FPCI_BAR_ST);
+	afi_writel(pcie, base, AFI_MSI_AXI_BAR_ST);
+	/* this register is in 4K increments */
+	afi_writel(pcie, 1, AFI_MSI_BAR_SZ);
+
+	/* enable all MSI vectors */
+	afi_writel(pcie, 0xffffffff, AFI_MSI_EN_VEC0);
+	afi_writel(pcie, 0xffffffff, AFI_MSI_EN_VEC1);
+	afi_writel(pcie, 0xffffffff, AFI_MSI_EN_VEC2);
+	afi_writel(pcie, 0xffffffff, AFI_MSI_EN_VEC3);
+	afi_writel(pcie, 0xffffffff, AFI_MSI_EN_VEC4);
+	afi_writel(pcie, 0xffffffff, AFI_MSI_EN_VEC5);
+	afi_writel(pcie, 0xffffffff, AFI_MSI_EN_VEC6);
+	afi_writel(pcie, 0xffffffff, AFI_MSI_EN_VEC7);
+
+	/* and unmask the MSI interrupt */
+	reg = afi_readl(pcie, AFI_INTR_MASK);
+	reg |= AFI_INTR_MASK_MSI_MASK;
+	afi_writel(pcie, reg, AFI_INTR_MASK);
+
+	return 0;
+
+err:
+	irq_domain_remove(msi->domain);
+	return err;
+}
+
+static int tegra_pcie_disable_msi(struct tegra_pcie *pcie)
+{
+	struct tegra_msi *msi = &pcie->msi;
+	unsigned int i, irq;
+	u32 value;
+
+	/* mask the MSI interrupt */
+	value = afi_readl(pcie, AFI_INTR_MASK);
+	value &= ~AFI_INTR_MASK_MSI_MASK;
+	afi_writel(pcie, value, AFI_INTR_MASK);
+
+	/* disable all MSI vectors */
+	afi_writel(pcie, 0, AFI_MSI_EN_VEC0);
+	afi_writel(pcie, 0, AFI_MSI_EN_VEC1);
+	afi_writel(pcie, 0, AFI_MSI_EN_VEC2);
+	afi_writel(pcie, 0, AFI_MSI_EN_VEC3);
+	afi_writel(pcie, 0, AFI_MSI_EN_VEC4);
+	afi_writel(pcie, 0, AFI_MSI_EN_VEC5);
+	afi_writel(pcie, 0, AFI_MSI_EN_VEC6);
+	afi_writel(pcie, 0, AFI_MSI_EN_VEC7);
+
+	free_pages(msi->pages, 3);
+
+	for (i = 0; i < INT_PCI_MSI_NR; i++) {
+		irq = irq_find_mapping(msi->domain, i);
+		if (irq > 0)
+			irq_dispose_mapping(irq);
+	}
+
+	irq_domain_remove(msi->domain);
+
+	return 0;
+}
+
+static u32 tegra_pcie_get_xbar_config(struct tegra_pcie *pcie, u32 lanes)
+{
+	struct device_node *np = pcie->dev->of_node;
+
+	switch (lanes) {
+	case 0x00000004:
+		dev_info(pcie->dev, "single-mode configuration\n");
+		return AFI_PCIE_CONFIG_SM2TMS0_XBAR_CONFIG_SINGLE;
+
+	case 0x00000202:
+		dev_info(pcie->dev, "dual-mode configuration\n");
+		return AFI_PCIE_CONFIG_SM2TMS0_XBAR_CONFIG_DUAL;
+	}
+
+	return 0;
+}
+
+static int tegra_pcie_parse_dt(struct tegra_pcie *pcie)
+{
+	struct device_node *np = pcie->dev->of_node, *port;
+	struct of_pci_range_parser parser;
+	struct of_pci_range range;
+	struct resource res;
+	u32 lanes = 0;
+	int err;
+
+	if (of_pci_range_parser(&parser, np)) {
+		dev_err(pcie->dev, "missing \"ranges\" property\n");
+		return -EINVAL;
+	}
+
+	pcie->vdd_supply = devm_regulator_get(pcie->dev, "vdd");
+	if (IS_ERR(pcie->vdd_supply))
+		return PTR_ERR(pcie->vdd_supply);
+
+	pcie->pex_clk_supply = devm_regulator_get(pcie->dev, "pex-clk");
+	if (IS_ERR(pcie->pex_clk_supply))
+		return PTR_ERR(pcie->pex_clk_supply);
+
+	for_each_of_pci_range(&parser, &range) {
+		of_pci_range_to_resource(&range, np, &res);
+
+		switch (res.flags & IORESOURCE_TYPE_BITS) {
+		case IORESOURCE_IO:
+			memcpy(&pcie->io, &res, sizeof(res));
+			pcie->io.name = "I/O";
+			break;
+
+		case IORESOURCE_MEM:
+			if (res.flags & IORESOURCE_PREFETCH) {
+				memcpy(&pcie->prefetch, &res, sizeof(res));
+				pcie->prefetch.name = "PREFETCH";
+			} else {
+				memcpy(&pcie->mem, &res, sizeof(res));
+				pcie->mem.name = "MEM";
+			}
+			break;
+		}
+	}
+
+	err = of_pci_parse_bus_range(np, &pcie->busn);
+	if (err < 0) {
+		dev_err(pcie->dev, "failed to parse ranges property: %d\n",
+			err);
+		pcie->busn.name = np->name;
+		pcie->busn.start = 0;
+		pcie->busn.end = 0xff;
+		pcie->busn.flags = IORESOURCE_BUS;
+	}
+
+	/* parse root ports */
+	for_each_child_of_node(np, port) {
+		struct tegra_pcie_port *rp;
+		unsigned int index;
+		u32 value;
+
+		err = of_pci_get_devfn(port);
+		if (err < 0) {
+			dev_err(pcie->dev, "failed to parse address: %d\n",
+				err);
+			return err;
+		}
+
+		index = PCI_SLOT(err);
+
+		if (index < 1 || index > TEGRA_MAX_PORTS) {
+			dev_err(pcie->dev, "invalid port number: %d\n", index);
+			return -EINVAL;
+		}
+
+		index--;
+
+		err = of_property_read_u32(port, "nvidia,num-lanes", &value);
+		if (err < 0) {
+			dev_err(pcie->dev, "failed to parse # of lanes: %d\n",
+				err);
+			return err;
+		}
+
+		if (value > 16) {
+			dev_err(pcie->dev, "invalid # of lanes: %u\n", value);
+			return -EINVAL;
+		}
+
+		lanes |= value << (index << 3);
+
+		if (!of_device_is_available(port))
+			continue;
+
+		rp = devm_kzalloc(pcie->dev, sizeof(*rp), GFP_KERNEL);
+		if (!rp)
+			return -ENOMEM;
+
+		err = of_address_to_resource(port, 0, &rp->regs);
+		if (err < 0) {
+			dev_err(pcie->dev, "failed to parse address: %d\n",
+				err);
+			return err;
+		}
+
+		INIT_LIST_HEAD(&rp->list);
+		rp->index = index;
+		rp->lanes = value;
+		rp->pcie = pcie;
+
+		rp->base = devm_request_and_ioremap(pcie->dev, &rp->regs);
+		if (!rp->base)
+			return -EADDRNOTAVAIL;
+
+		list_add_tail(&rp->list, &pcie->ports);
+	}
+
+	pcie->xbar_config = tegra_pcie_get_xbar_config(pcie, lanes);
+	if (!pcie->xbar_config) {
+		dev_err(pcie->dev, "invalid lane configuration\n");
+		return -EINVAL;
+	}
+
+	return 0;
+}
+
+/*
+ * FIXME: If there are no PCIe cards attached, then calling this function
+ * can result in the increase of the bootup time as there are big timeout
+ * loops.
+ */
+#define TEGRA_PCIE_LINKUP_TIMEOUT	200	/* up to 1.2 seconds */
+static bool tegra_pcie_port_check_link(struct tegra_pcie_port *port)
+{
+	unsigned int retries = 3;
+	unsigned long value;
+
+	do {
+		unsigned int timeout = TEGRA_PCIE_LINKUP_TIMEOUT;
+
+		do {
+			value = readl(port->base + RP_VEND_XP);
+
+			if (value & RP_VEND_XP_DL_UP)
+				break;
+
+			usleep_range(1000, 1000);
+		} while (--timeout);
+
+		if (!timeout) {
+			dev_err(port->pcie->dev, "link %u down, retrying\n",
+				port->index);
+			goto retry;
+		}
+
+		timeout = TEGRA_PCIE_LINKUP_TIMEOUT;
+
+		do {
+			value = readl(port->base + RP_LINK_CONTROL_STATUS);
+
+			if (value & 0x20000000)
+				return true;
+
+			usleep_range(1000, 1000);
+		} while (--timeout);
+
+retry:
+		tegra_pcie_port_reset(port);
+	} while (--retries);
+
+	return false;
+}
+
+static int tegra_pcie_enable(struct tegra_pcie *pcie)
+{
+	struct tegra_pcie_port *port, *tmp;
+	struct hw_pci hw;
+
+	list_for_each_entry_safe(port, tmp, &pcie->ports, list) {
+		dev_info(pcie->dev, "probing port %u, using %u lanes\n",
+			 port->index, port->lanes);
+
+		tegra_pcie_port_enable(port);
+
+		if (tegra_pcie_port_check_link(port))
+			continue;
+
+		dev_info(pcie->dev, "link %u down, ignoring\n", port->index);
+
+		tegra_pcie_port_disable(port);
+		tegra_pcie_port_free(port);
+	}
+
+	memset(&hw, 0, sizeof(hw));
+
+	hw.nr_controllers = 1;
+	hw.private_data = (void **)&pcie;
+	hw.setup = tegra_pcie_setup;
+	hw.scan = tegra_pcie_scan_bus;
+	hw.map_irq = tegra_pcie_map_irq;
+
+	pci_common_init(&hw);
+
+	return 0;
+}
+
+static int tegra_pcie_probe(struct platform_device *pdev)
+{
+	struct tegra_pcie *pcie;
+	int err;
+
+	pcie = devm_kzalloc(&pdev->dev, sizeof(*pcie), GFP_KERNEL);
+	if (!pcie)
+		return -ENOMEM;
+
+	INIT_LIST_HEAD(&pcie->busses);
+	INIT_LIST_HEAD(&pcie->ports);
+	pcie->dev = &pdev->dev;
+
+	err = tegra_pcie_parse_dt(pcie);
+	if (err < 0)
+		return err;
+
+	pcibios_min_mem = 0;
+
+	err = tegra_pcie_get_resources(pcie);
+	if (err < 0) {
+		dev_err(&pdev->dev, "failed to request resources: %d\n", err);
+		return err;
+	}
+
+	err = tegra_pcie_enable_controller(pcie);
+	if (err)
+		goto put_resources;
+
+	/* setup the AFI address translations */
+	tegra_pcie_setup_translations(pcie);
+
+	if (IS_ENABLED(CONFIG_PCI_MSI)) {
+		err = tegra_pcie_enable_msi(pcie);
+		if (err < 0) {
+			dev_err(&pdev->dev,
+				"failed to enable MSI support: %d\n",
+				err);
+			goto put_resources;
+		}
+	}
+
+	err = tegra_pcie_enable(pcie);
+	if (err < 0) {
+		dev_err(&pdev->dev, "failed to enable PCIe ports: %d\n", err);
+		goto disable_msi;
+	}
+
+	platform_set_drvdata(pdev, pcie);
+	return 0;
+
+disable_msi:
+	if (IS_ENABLED(CONFIG_PCI_MSI))
+		tegra_pcie_disable_msi(pcie);
+put_resources:
+	tegra_pcie_put_resources(pcie);
+	return err;
+}
+
+static int tegra_pcie_remove(struct platform_device *pdev)
+{
+	struct tegra_pcie *pcie = platform_get_drvdata(pdev);
+	struct tegra_pcie_bus *bus;
+	int err;
+
+	list_for_each_entry(bus, &pcie->busses, list) {
+		vunmap(bus->area->addr);
+		kfree(bus);
+	}
+
+	if (IS_ENABLED(CONFIG_PCI_MSI)) {
+		err = tegra_pcie_disable_msi(pcie);
+		if (err < 0)
+			return err;
+	}
+
+	err = tegra_pcie_put_resources(pcie);
+	if (err < 0)
+		return err;
+
+	return 0;
+}
+
+static const struct of_device_id tegra_pcie_of_match[] = {
+	{ .compatible = "nvidia,tegra20-pcie", },
+	{ },
+};
+
+static struct platform_driver tegra_pcie_driver = {
+	.driver = {
+		.name = "tegra-pcie",
+		.owner = THIS_MODULE,
+		.of_match_table = tegra_pcie_of_match,
+	},
+	.probe = tegra_pcie_probe,
+	.remove = tegra_pcie_remove,
+};
+module_platform_driver(tegra_pcie_driver);
-- 
1.8.2



From pdeschrijver at nvidia.com  Wed Apr  3 10:40:38 2013
From: pdeschrijver at nvidia.com (Peter De Schrijver)
Date: Wed, 3 Apr 2013 17:40:38 +0300
Subject: [PATCH v9 04/14] clk: tegra: introduce TEGRA_PLL_HAS_LOCK_ENABLE
In-Reply-To: <1365000110-8916-1-git-send-email-pdeschrijver@nvidia.com>
References: <1365000110-8916-1-git-send-email-pdeschrijver@nvidia.com>
Message-ID: <1365000110-8916-5-git-send-email-pdeschrijver@nvidia.com>

Tegra114 PLLC2 and PLLC3 don't have a lock enable bit. The lock bits are
always functional.

Signed-off-by: Peter De Schrijver <pdeschrijver at nvidia.com>
---
 drivers/clk/tegra/clk-pll.c |    5 +++++
 drivers/clk/tegra/clk.h     |    2 ++
 2 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/drivers/clk/tegra/clk-pll.c b/drivers/clk/tegra/clk-pll.c
index 4ee6d03..eaab060 100644
--- a/drivers/clk/tegra/clk-pll.c
+++ b/drivers/clk/tegra/clk-pll.c
@@ -108,6 +108,9 @@ static void clk_pll_enable_lock(struct tegra_clk_pll *pll)
 	if (!(pll->flags & TEGRA_PLL_USE_LOCK))
 		return;
 
+	if (!(pll->flags & TEGRA_PLL_HAS_LOCK_ENABLE))
+		return;
+
 	val = pll_readl_misc(pll);
 	val |= BIT(pll->params->lock_enable_bit_idx);
 	pll_writel_misc(val, pll);
@@ -675,6 +678,7 @@ struct clk *tegra_clk_register_pll(const char *name, const char *parent_name,
 	struct clk *clk;
 
 	pll_flags |= TEGRA_PLL_BYPASS;
+	pll_flags |= TEGRA_PLL_HAS_LOCK_ENABLE;
 	pll = _tegra_init_pll(clk_base, pmc, fixed_rate, pll_params, pll_flags,
 			      freq_table, lock);
 	if (IS_ERR(pll))
@@ -698,6 +702,7 @@ struct clk *tegra_clk_register_plle(const char *name, const char *parent_name,
 	struct clk *clk;
 
 	pll_flags |= TEGRA_PLL_LOCK_MISC | TEGRA_PLL_BYPASS;
+	pll_flags |= TEGRA_PLL_HAS_LOCK_ENABLE;
 	pll = _tegra_init_pll(clk_base, pmc, fixed_rate, pll_params, pll_flags,
 			      freq_table, lock);
 	if (IS_ERR(pll))
diff --git a/drivers/clk/tegra/clk.h b/drivers/clk/tegra/clk.h
index fff520a..17ddb22 100644
--- a/drivers/clk/tegra/clk.h
+++ b/drivers/clk/tegra/clk.h
@@ -185,6 +185,7 @@ struct tegra_clk_pll_params {
  * TEGRA_PLL_LOCK_MISC - Lock bit is in the misc register instead of the
  *     base register.
  * TEGRA_PLL_BYPASS - PLL has bypass bit
+ * TEGRA_PLL_HAS_LOCK_ENABLE - PLL has bit to enable lock monitoring
  */
 struct tegra_clk_pll {
 	struct clk_hw	hw;
@@ -215,6 +216,7 @@ struct tegra_clk_pll {
 #define TEGRA_PLLE_CONFIGURE BIT(7)
 #define TEGRA_PLL_LOCK_MISC BIT(8)
 #define TEGRA_PLL_BYPASS BIT(9)
+#define TEGRA_PLL_HAS_LOCK_ENABLE BIT(10)
 
 extern const struct clk_ops tegra_clk_pll_ops;
 extern const struct clk_ops tegra_clk_plle_ops;
-- 
1.7.7.rc0.72.g4b5ea.dirty



From stefano.stabellini at eu.citrix.com  Wed Apr  3 10:47:08 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Wed, 3 Apr 2013 15:47:08 +0100
Subject: [PATCH v5 3/3] xen/arm: introduce xen_early_init, use PSCI on xen
In-Reply-To: <alpine.LFD.2.03.1304030955180.1171@syhkavp.arg>
References: <alpine.DEB.2.02.1304021700380.5078@kaball.uk.xensource.com>
 <1364919374-7836-3-git-send-email-stefano.stabellini@eu.citrix.com>
 <alpine.LFD.2.03.1304021325230.1171@syhkavp.arg>
 <alpine.DEB.2.02.1304031217310.5078@kaball.uk.xensource.com>
 <alpine.LFD.2.03.1304030955180.1171@syhkavp.arg>
Message-ID: <alpine.DEB.2.02.1304031525550.5078@kaball.uk.xensource.com>

On Wed, 3 Apr 2013, Nicolas Pitre wrote:
> On Wed, 3 Apr 2013, Stefano Stabellini wrote:
> 
> > On Tue, 2 Apr 2013, Nicolas Pitre wrote:
> > > On Tue, 2 Apr 2013, Stefano Stabellini wrote:
> > > 
> > > > @@ -176,27 +178,30 @@ static int __init xen_secondary_init(unsigned int cpu)
> > > >  	return 0;
> > > >  }
> > > >  
> > > > +static void __init xen_smp_init(void)
> > > > +{
> > > > +	if (psci_smp_available())
> > > > +		smp_set_ops(&psci_smp_ops);
> > > > +}
> > > > +
> > > 
> > > I still don't understand why you need to do this.  Why can't you just 
> > > rely on the next priority which is to set PSCI ops by default if 
> > > available?  Using this hook for Xen doesn't look justified. As it is, 
> > > you break MCPM.
> > > 
> > > As I explained to you, MCPM will end up using PSCI as well when 
> > > available, which I think should be sufficient for your concern.
> > 
> > The smp_init hook is not limited to MCPM or the versatile express
> > platform. It's a generic hook that can be used by any platform and can
> > override the platform smp_ops or the psci_smp_ops depending on platform
> > specific configurations.
> > 
> > Configurations that I am pretty sure won't be available on Xen anyway,
> > while I am certain that using psci_smp_ops would work.
> > 
> > It seems to me that relying on the fact that only versatile express and
> > only MCPM use smp_init, even though it might work today, it's very
> > fragile and could break tomorrow without any of us noticing.
> 
> I claim: this breaks MCPM today.
>
> You claim: the alternative _could_ break with Xen tomorrow.
> 
> Could we please wait until there is an actual problem with Xen before 
> being overly defensive in the code?

Sorry, I realized that I should have explained myself better.

The smp_init patch together with the MCPM patch series
(http://marc.info/?l=linux-arm-kernel&m=136004188122492) breaks Xen Dom0
SMP support on versatile express *today* (ifndef CONFIG_CLUSTER_PM):
smp_init is not NULL on versatile express anymore therefore smp_init is
going to be called, causing vexpress_smp_ops to be selected even if psci
is on device tree.

On the other hand if this patch was applied, xen_smp_init would override
smp_init making sure that psci_smp_ops is used on Xen and everything
would work as expected.


So as it stands today, we need this patch for regular Xen Dom0 SMP
support.


BTW I have actually tried it on my versatile express machine to make
sure that it is correct :)


From pdeschrijver at nvidia.com  Wed Apr  3 10:40:39 2013
From: pdeschrijver at nvidia.com (Peter De Schrijver)
Date: Wed, 3 Apr 2013 17:40:39 +0300
Subject: [PATCH v9 05/14] clk: tegra: Add PLL post divider table
In-Reply-To: <1365000110-8916-1-git-send-email-pdeschrijver@nvidia.com>
References: <1365000110-8916-1-git-send-email-pdeschrijver@nvidia.com>
Message-ID: <1365000110-8916-6-git-send-email-pdeschrijver@nvidia.com>

Some PLLs in Tegra114 don't use a power of 2 mapping for the post divider.
Introduce a table based approach and switch PLLU to it.

Signed-off-by: Peter De Schrijver <pdeschrijver at nvidia.com>
---
 drivers/clk/tegra/clk-pll.c     |   38 ++++++++++++++++++++++++++++++++------
 drivers/clk/tegra/clk-tegra20.c |    7 +++++++
 drivers/clk/tegra/clk-tegra30.c |    7 +++++++
 drivers/clk/tegra/clk.h         |   13 +++++++++++++
 4 files changed, 59 insertions(+), 6 deletions(-)

diff --git a/drivers/clk/tegra/clk-pll.c b/drivers/clk/tegra/clk-pll.c
index eaab060..ccb367e 100644
--- a/drivers/clk/tegra/clk-pll.c
+++ b/drivers/clk/tegra/clk-pll.c
@@ -266,6 +266,7 @@ static int _calc_rate(struct clk_hw *hw, struct tegra_clk_pll_freq_table *cfg,
 		      unsigned long rate, unsigned long parent_rate)
 {
 	struct tegra_clk_pll *pll = to_clk_pll(hw);
+	struct pdiv_map *p_tohw = pll->params->pdiv_tohw;
 	unsigned long cfreq;
 	u32 p_div = 0;
 
@@ -299,7 +300,6 @@ static int _calc_rate(struct clk_hw *hw, struct tegra_clk_pll_freq_table *cfg,
 	     cfg->output_rate <<= 1)
 		p_div++;
 
-	cfg->p = p_div;
 	cfg->m = parent_rate / cfreq;
 	cfg->n = cfg->output_rate / cfreq;
 	cfg->cpcon = OUT_OF_TABLE_CPCON;
@@ -312,8 +312,19 @@ static int _calc_rate(struct clk_hw *hw, struct tegra_clk_pll_freq_table *cfg,
 		return -EINVAL;
 	}
 
-	if (pll->flags & TEGRA_PLLU)
-		cfg->p ^= 1;
+	if (p_tohw) {
+		p_div = 1 << p_div;
+		while (p_tohw->pdiv) {
+			if (p_div <= p_tohw->pdiv) {
+				cfg->p = p_tohw->hw_val;
+				break;
+			}
+			p_tohw++;
+		}
+		if (!p_tohw->pdiv)
+			return -EINVAL;
+	} else
+		cfg->p = p_div;
 
 	return 0;
 }
@@ -460,8 +471,10 @@ static unsigned long clk_pll_recalc_rate(struct clk_hw *hw,
 {
 	struct tegra_clk_pll *pll = to_clk_pll(hw);
 	struct tegra_clk_pll_freq_table cfg;
+	struct pdiv_map *p_tohw = pll->params->pdiv_tohw;
 	u32 val;
 	u64 rate = parent_rate;
+	int pdiv;
 
 	val = pll_readl_base(pll);
 
@@ -480,10 +493,23 @@ static unsigned long clk_pll_recalc_rate(struct clk_hw *hw,
 
 	_get_pll_mnp(pll, &cfg);
 
-	if (pll->flags & TEGRA_PLLU)
-		cfg.p ^= 1;
+	if (p_tohw) {
+		while (p_tohw->pdiv) {
+			if (cfg.p == p_tohw->hw_val) {
+				pdiv = p_tohw->pdiv;
+				break;
+			}
+			p_tohw++;
+		}
+
+		if (!p_tohw->pdiv) {
+			WARN_ON(1);
+			pdiv = 1;
+		}
+	} else
+		pdiv = 1 << cfg.p;
 
-	cfg.m *= 1 << cfg.p;
+	cfg.m *= pdiv;
 
 	rate *= cfg.n;
 	do_div(rate, cfg.m);
diff --git a/drivers/clk/tegra/clk-tegra20.c b/drivers/clk/tegra/clk-tegra20.c
index 13efdfb..b1a49cb 100644
--- a/drivers/clk/tegra/clk-tegra20.c
+++ b/drivers/clk/tegra/clk-tegra20.c
@@ -441,6 +441,12 @@ static struct tegra_clk_pll_params pll_d_params = {
 	.lock_delay = 1000,
 };
 
+static struct pdiv_map pllu_p[] = {
+	{ .pdiv = 1, .hw_val = 1 },
+	{ .pdiv = 2, .hw_val = 0 },
+	{ .pdiv = 0, .hw_val = 0 },
+};
+
 static struct tegra_clk_pll_params pll_u_params = {
 	.input_min = 2000000,
 	.input_max = 40000000,
@@ -453,6 +459,7 @@ static struct tegra_clk_pll_params pll_u_params = {
 	.lock_bit_idx = PLL_BASE_LOCK,
 	.lock_enable_bit_idx = PLLDU_MISC_LOCK_ENABLE,
 	.lock_delay = 1000,
+	.pdiv_tohw = pllu_p,
 };
 
 static struct tegra_clk_pll_params pll_x_params = {
diff --git a/drivers/clk/tegra/clk-tegra30.c b/drivers/clk/tegra/clk-tegra30.c
index a7b955c..102bcbb 100644
--- a/drivers/clk/tegra/clk-tegra30.c
+++ b/drivers/clk/tegra/clk-tegra30.c
@@ -467,6 +467,12 @@ static struct tegra_clk_pll_freq_table pll_d_freq_table[] = {
 	{ 0, 0, 0, 0, 0, 0 },
 };
 
+static struct pdiv_map pllu_p[] = {
+	{ .pdiv = 1, .hw_val = 1 },
+	{ .pdiv = 2, .hw_val = 0 },
+	{ .pdiv = 0, .hw_val = 0 },
+};
+
 static struct tegra_clk_pll_freq_table pll_u_freq_table[] = {
 	{ 12000000, 480000000, 960, 12, 0, 12},
 	{ 13000000, 480000000, 960, 13, 0, 12},
@@ -640,6 +646,7 @@ static struct tegra_clk_pll_params pll_u_params = {
 	.lock_bit_idx = PLL_BASE_LOCK,
 	.lock_enable_bit_idx = PLLDU_MISC_LOCK_ENABLE,
 	.lock_delay = 1000,
+	.pdiv_tohw = pllu_p,
 };
 
 static struct tegra_clk_pll_params pll_x_params = {
diff --git a/drivers/clk/tegra/clk.h b/drivers/clk/tegra/clk.h
index 17ddb22..925da45 100644
--- a/drivers/clk/tegra/clk.h
+++ b/drivers/clk/tegra/clk.h
@@ -117,6 +117,17 @@ struct tegra_clk_pll_freq_table {
 };
 
 /**
+ * struct pdiv_map - map post divider to hw value
+ *
+ * @pdiv:		post divider
+ * @hw_val:		value to be written to the PLL hw
+ */
+struct pdiv_map {
+	u8 pdiv;
+	u8 hw_val;
+};
+
+/**
  * struct clk_pll_params - PLL parameters
  *
  * @input_min:			Minimum input frequency
@@ -146,6 +157,8 @@ struct tegra_clk_pll_params {
 	u32		lock_bit_idx;
 	u32		lock_enable_bit_idx;
 	int		lock_delay;
+	int		max_p;
+	struct pdiv_map *pdiv_tohw;
 };
 
 /**
-- 
1.7.7.rc0.72.g4b5ea.dirty



From pdeschrijver at nvidia.com  Wed Apr  3 10:40:40 2013
From: pdeschrijver at nvidia.com (Peter De Schrijver)
Date: Wed, 3 Apr 2013 17:40:40 +0300
Subject: [PATCH v9 06/14] clk: tegra: move from a lock bit idx to a lock mask
In-Reply-To: <1365000110-8916-1-git-send-email-pdeschrijver@nvidia.com>
References: <1365000110-8916-1-git-send-email-pdeschrijver@nvidia.com>
Message-ID: <1365000110-8916-7-git-send-email-pdeschrijver@nvidia.com>

PLLC2 and PLLC3 on Tegra114 have separate phaselock and frequencylock bits.
So switch to a lock mask to be able to test both at the same time.

Signed-off-by: Peter De Schrijver <pdeschrijver at nvidia.com>
---
 drivers/clk/tegra/clk-pll.c     |    6 +++---
 drivers/clk/tegra/clk-tegra20.c |   20 ++++++++++----------
 drivers/clk/tegra/clk-tegra30.c |   22 +++++++++++-----------
 drivers/clk/tegra/clk.h         |    2 +-
 4 files changed, 25 insertions(+), 25 deletions(-)

diff --git a/drivers/clk/tegra/clk-pll.c b/drivers/clk/tegra/clk-pll.c
index ccb367e..0b96352 100644
--- a/drivers/clk/tegra/clk-pll.c
+++ b/drivers/clk/tegra/clk-pll.c
@@ -119,7 +119,7 @@ static void clk_pll_enable_lock(struct tegra_clk_pll *pll)
 static int clk_pll_wait_for_lock(struct tegra_clk_pll *pll)
 {
 	int i;
-	u32 val, lock_bit;
+	u32 val, lock_mask;
 	void __iomem *lock_addr;
 
 	if (!(pll->flags & TEGRA_PLL_USE_LOCK)) {
@@ -133,11 +133,11 @@ static int clk_pll_wait_for_lock(struct tegra_clk_pll *pll)
 	else
 		lock_addr += pll->params->base_reg;
 
-	lock_bit = BIT(pll->params->lock_bit_idx);
+	lock_mask = pll->params->lock_mask;
 
 	for (i = 0; i < pll->params->lock_delay; i++) {
 		val = readl_relaxed(lock_addr);
-		if (val & lock_bit) {
+		if ((val & lock_mask) == lock_mask) {
 			udelay(PLL_POST_LOCK_DELAY);
 			return 0;
 		}
diff --git a/drivers/clk/tegra/clk-tegra20.c b/drivers/clk/tegra/clk-tegra20.c
index b1a49cb..b6a747f 100644
--- a/drivers/clk/tegra/clk-tegra20.c
+++ b/drivers/clk/tegra/clk-tegra20.c
@@ -86,8 +86,8 @@
 #define PLLE_BASE 0xe8
 #define PLLE_MISC 0xec
 
-#define PLL_BASE_LOCK 27
-#define PLLE_MISC_LOCK 11
+#define PLL_BASE_LOCK BIT(27)
+#define PLLE_MISC_LOCK BIT(11)
 
 #define PLL_MISC_LOCK_ENABLE 18
 #define PLLDU_MISC_LOCK_ENABLE 22
@@ -380,7 +380,7 @@ static struct tegra_clk_pll_params pll_c_params = {
 	.vco_max = 1400000000,
 	.base_reg = PLLC_BASE,
 	.misc_reg = PLLC_MISC,
-	.lock_bit_idx = PLL_BASE_LOCK,
+	.lock_mask = PLL_BASE_LOCK,
 	.lock_enable_bit_idx = PLL_MISC_LOCK_ENABLE,
 	.lock_delay = 300,
 };
@@ -394,7 +394,7 @@ static struct tegra_clk_pll_params pll_m_params = {
 	.vco_max = 1200000000,
 	.base_reg = PLLM_BASE,
 	.misc_reg = PLLM_MISC,
-	.lock_bit_idx = PLL_BASE_LOCK,
+	.lock_mask = PLL_BASE_LOCK,
 	.lock_enable_bit_idx = PLL_MISC_LOCK_ENABLE,
 	.lock_delay = 300,
 };
@@ -408,7 +408,7 @@ static struct tegra_clk_pll_params pll_p_params = {
 	.vco_max = 1400000000,
 	.base_reg = PLLP_BASE,
 	.misc_reg = PLLP_MISC,
-	.lock_bit_idx = PLL_BASE_LOCK,
+	.lock_mask = PLL_BASE_LOCK,
 	.lock_enable_bit_idx = PLL_MISC_LOCK_ENABLE,
 	.lock_delay = 300,
 };
@@ -422,7 +422,7 @@ static struct tegra_clk_pll_params pll_a_params = {
 	.vco_max = 1400000000,
 	.base_reg = PLLA_BASE,
 	.misc_reg = PLLA_MISC,
-	.lock_bit_idx = PLL_BASE_LOCK,
+	.lock_mask = PLL_BASE_LOCK,
 	.lock_enable_bit_idx = PLL_MISC_LOCK_ENABLE,
 	.lock_delay = 300,
 };
@@ -436,7 +436,7 @@ static struct tegra_clk_pll_params pll_d_params = {
 	.vco_max = 1000000000,
 	.base_reg = PLLD_BASE,
 	.misc_reg = PLLD_MISC,
-	.lock_bit_idx = PLL_BASE_LOCK,
+	.lock_mask = PLL_BASE_LOCK,
 	.lock_enable_bit_idx = PLLDU_MISC_LOCK_ENABLE,
 	.lock_delay = 1000,
 };
@@ -456,7 +456,7 @@ static struct tegra_clk_pll_params pll_u_params = {
 	.vco_max = 960000000,
 	.base_reg = PLLU_BASE,
 	.misc_reg = PLLU_MISC,
-	.lock_bit_idx = PLL_BASE_LOCK,
+	.lock_mask = PLL_BASE_LOCK,
 	.lock_enable_bit_idx = PLLDU_MISC_LOCK_ENABLE,
 	.lock_delay = 1000,
 	.pdiv_tohw = pllu_p,
@@ -471,7 +471,7 @@ static struct tegra_clk_pll_params pll_x_params = {
 	.vco_max = 1200000000,
 	.base_reg = PLLX_BASE,
 	.misc_reg = PLLX_MISC,
-	.lock_bit_idx = PLL_BASE_LOCK,
+	.lock_mask = PLL_BASE_LOCK,
 	.lock_enable_bit_idx = PLL_MISC_LOCK_ENABLE,
 	.lock_delay = 300,
 };
@@ -485,7 +485,7 @@ static struct tegra_clk_pll_params pll_e_params = {
 	.vco_max = 0,
 	.base_reg = PLLE_BASE,
 	.misc_reg = PLLE_MISC,
-	.lock_bit_idx = PLLE_MISC_LOCK,
+	.lock_mask = PLLE_MISC_LOCK,
 	.lock_enable_bit_idx = PLLE_MISC_LOCK_ENABLE,
 	.lock_delay = 0,
 };
diff --git a/drivers/clk/tegra/clk-tegra30.c b/drivers/clk/tegra/clk-tegra30.c
index 102bcbb..9c43bb4 100644
--- a/drivers/clk/tegra/clk-tegra30.c
+++ b/drivers/clk/tegra/clk-tegra30.c
@@ -116,8 +116,8 @@
 #define PLLDU_MISC_LOCK_ENABLE 22
 #define PLLE_MISC_LOCK_ENABLE 9
 
-#define PLL_BASE_LOCK 27
-#define PLLE_MISC_LOCK 11
+#define PLL_BASE_LOCK BIT(27)
+#define PLLE_MISC_LOCK BIT(11)
 
 #define PLLE_AUX 0x48c
 #define PLLC_OUT 0x84
@@ -559,7 +559,7 @@ static struct tegra_clk_pll_params pll_c_params = {
 	.vco_max = 1400000000,
 	.base_reg = PLLC_BASE,
 	.misc_reg = PLLC_MISC,
-	.lock_bit_idx = PLL_BASE_LOCK,
+	.lock_mask = PLL_BASE_LOCK,
 	.lock_enable_bit_idx = PLL_MISC_LOCK_ENABLE,
 	.lock_delay = 300,
 };
@@ -573,7 +573,7 @@ static struct tegra_clk_pll_params pll_m_params = {
 	.vco_max = 1200000000,
 	.base_reg = PLLM_BASE,
 	.misc_reg = PLLM_MISC,
-	.lock_bit_idx = PLL_BASE_LOCK,
+	.lock_mask = PLL_BASE_LOCK,
 	.lock_enable_bit_idx = PLL_MISC_LOCK_ENABLE,
 	.lock_delay = 300,
 };
@@ -587,7 +587,7 @@ static struct tegra_clk_pll_params pll_p_params = {
 	.vco_max = 1400000000,
 	.base_reg = PLLP_BASE,
 	.misc_reg = PLLP_MISC,
-	.lock_bit_idx = PLL_BASE_LOCK,
+	.lock_mask = PLL_BASE_LOCK,
 	.lock_enable_bit_idx = PLL_MISC_LOCK_ENABLE,
 	.lock_delay = 300,
 };
@@ -601,7 +601,7 @@ static struct tegra_clk_pll_params pll_a_params = {
 	.vco_max = 1400000000,
 	.base_reg = PLLA_BASE,
 	.misc_reg = PLLA_MISC,
-	.lock_bit_idx = PLL_BASE_LOCK,
+	.lock_mask = PLL_BASE_LOCK,
 	.lock_enable_bit_idx = PLL_MISC_LOCK_ENABLE,
 	.lock_delay = 300,
 };
@@ -615,7 +615,7 @@ static struct tegra_clk_pll_params pll_d_params = {
 	.vco_max = 1000000000,
 	.base_reg = PLLD_BASE,
 	.misc_reg = PLLD_MISC,
-	.lock_bit_idx = PLL_BASE_LOCK,
+	.lock_mask = PLL_BASE_LOCK,
 	.lock_enable_bit_idx = PLLDU_MISC_LOCK_ENABLE,
 	.lock_delay = 1000,
 };
@@ -629,7 +629,7 @@ static struct tegra_clk_pll_params pll_d2_params = {
 	.vco_max = 1000000000,
 	.base_reg = PLLD2_BASE,
 	.misc_reg = PLLD2_MISC,
-	.lock_bit_idx = PLL_BASE_LOCK,
+	.lock_mask = PLL_BASE_LOCK,
 	.lock_enable_bit_idx = PLLDU_MISC_LOCK_ENABLE,
 	.lock_delay = 1000,
 };
@@ -643,7 +643,7 @@ static struct tegra_clk_pll_params pll_u_params = {
 	.vco_max = 960000000,
 	.base_reg = PLLU_BASE,
 	.misc_reg = PLLU_MISC,
-	.lock_bit_idx = PLL_BASE_LOCK,
+	.lock_mask = PLL_BASE_LOCK,
 	.lock_enable_bit_idx = PLLDU_MISC_LOCK_ENABLE,
 	.lock_delay = 1000,
 	.pdiv_tohw = pllu_p,
@@ -658,7 +658,7 @@ static struct tegra_clk_pll_params pll_x_params = {
 	.vco_max = 1700000000,
 	.base_reg = PLLX_BASE,
 	.misc_reg = PLLX_MISC,
-	.lock_bit_idx = PLL_BASE_LOCK,
+	.lock_mask = PLL_BASE_LOCK,
 	.lock_enable_bit_idx = PLL_MISC_LOCK_ENABLE,
 	.lock_delay = 300,
 };
@@ -672,7 +672,7 @@ static struct tegra_clk_pll_params pll_e_params = {
 	.vco_max = 2400000000U,
 	.base_reg = PLLE_BASE,
 	.misc_reg = PLLE_MISC,
-	.lock_bit_idx = PLLE_MISC_LOCK,
+	.lock_mask = PLLE_MISC_LOCK,
 	.lock_enable_bit_idx = PLLE_MISC_LOCK_ENABLE,
 	.lock_delay = 300,
 };
diff --git a/drivers/clk/tegra/clk.h b/drivers/clk/tegra/clk.h
index 925da45..3b498e0 100644
--- a/drivers/clk/tegra/clk.h
+++ b/drivers/clk/tegra/clk.h
@@ -154,7 +154,7 @@ struct tegra_clk_pll_params {
 	u32		base_reg;
 	u32		misc_reg;
 	u32		lock_reg;
-	u32		lock_bit_idx;
+	u32		lock_mask;
 	u32		lock_enable_bit_idx;
 	int		lock_delay;
 	int		max_p;
-- 
1.7.7.rc0.72.g4b5ea.dirty



From pdeschrijver at nvidia.com  Wed Apr  3 10:40:41 2013
From: pdeschrijver at nvidia.com (Peter De Schrijver)
Date: Wed, 3 Apr 2013 17:40:41 +0300
Subject: [PATCH v9 07/14] clk: tegra: Add new fields and PLL types for Tegra114
In-Reply-To: <1365000110-8916-1-git-send-email-pdeschrijver@nvidia.com>
References: <1365000110-8916-1-git-send-email-pdeschrijver@nvidia.com>
Message-ID: <1365000110-8916-8-git-send-email-pdeschrijver@nvidia.com>

Tegra114 introduces new PLL types. This requires new clocktypes as well
as some new fields in the pll structure.

Signed-off-by: Peter De Schrijver <pdeschrijver at nvidia.com>
---
 drivers/clk/tegra/clk-pll.c |  839 +++++++++++++++++++++++++++++++++++++++++++
 drivers/clk/tegra/clk.h     |   50 +++-
 2 files changed, 888 insertions(+), 1 deletions(-)

diff --git a/drivers/clk/tegra/clk-pll.c b/drivers/clk/tegra/clk-pll.c
index 0b96352..17c2cc0 100644
--- a/drivers/clk/tegra/clk-pll.c
+++ b/drivers/clk/tegra/clk-pll.c
@@ -79,6 +79,48 @@
 #define PLLE_SS_CTRL 0x68
 #define PLLE_SS_DISABLE (7 << 10)
 
+#define PLLE_AUX_PLLP_SEL	BIT(2)
+#define PLLE_AUX_ENABLE_SWCTL	BIT(4)
+#define PLLE_AUX_SEQ_ENABLE	BIT(24)
+#define PLLE_AUX_PLLRE_SEL	BIT(28)
+
+#define PLLE_MISC_PLLE_PTS	BIT(8)
+#define PLLE_MISC_IDDQ_SW_VALUE	BIT(13)
+#define PLLE_MISC_IDDQ_SW_CTRL	BIT(14)
+#define PLLE_MISC_VREG_BG_CTRL_SHIFT	4
+#define PLLE_MISC_VREG_BG_CTRL_MASK	(3 << PLLE_MISC_VREG_BG_CTRL_SHIFT)
+#define PLLE_MISC_VREG_CTRL_SHIFT	2
+#define PLLE_MISC_VREG_CTRL_MASK	(2 << PLLE_MISC_VREG_CTRL_SHIFT)
+
+#define PLLCX_MISC_STROBE	BIT(31)
+#define PLLCX_MISC_RESET	BIT(30)
+#define PLLCX_MISC_SDM_DIV_SHIFT 28
+#define PLLCX_MISC_SDM_DIV_MASK (0x3 << PLLCX_MISC_SDM_DIV_SHIFT)
+#define PLLCX_MISC_FILT_DIV_SHIFT 26
+#define PLLCX_MISC_FILT_DIV_MASK (0x3 << PLLCX_MISC_FILT_DIV_SHIFT)
+#define PLLCX_MISC_ALPHA_SHIFT 18
+#define PLLCX_MISC_DIV_LOW_RANGE \
+		((0x1 << PLLCX_MISC_SDM_DIV_SHIFT) | \
+		(0x1 << PLLCX_MISC_FILT_DIV_SHIFT))
+#define PLLCX_MISC_DIV_HIGH_RANGE \
+		((0x2 << PLLCX_MISC_SDM_DIV_SHIFT) | \
+		(0x2 << PLLCX_MISC_FILT_DIV_SHIFT))
+#define PLLCX_MISC_COEF_LOW_RANGE \
+		((0x14 << PLLCX_MISC_KA_SHIFT) | (0x38 << PLLCX_MISC_KB_SHIFT))
+#define PLLCX_MISC_KA_SHIFT 2
+#define PLLCX_MISC_KB_SHIFT 9
+#define PLLCX_MISC_DEFAULT (PLLCX_MISC_COEF_LOW_RANGE | \
+			    (0x19 << PLLCX_MISC_ALPHA_SHIFT) | \
+			    PLLCX_MISC_DIV_LOW_RANGE | \
+			    PLLCX_MISC_RESET)
+#define PLLCX_MISC1_DEFAULT 0x000d2308
+#define PLLCX_MISC2_DEFAULT 0x30211200
+#define PLLCX_MISC3_DEFAULT 0x200
+
+#define PMC_PLLM_WB0_OVERRIDE	0x1dc
+#define PMC_PLLM_WB0_OVERRIDE_2	0x2b0
+#define PMC_PLLM_WB0_OVERRIDE_2_DIVP_MASK BIT(27)
+
 #define PMC_SATA_PWRGT 0x1ac
 #define PMC_SATA_PWRGT_PLLE_IDDQ_VALUE BIT(5)
 #define PMC_SATA_PWRGT_PLLE_IDDQ_SWCTL BIT(4)
@@ -101,6 +143,24 @@
 #define divn_max(p) (divn_mask(p))
 #define divp_max(p) (1 << (divp_mask(p)))
 
+
+#ifdef CONFIG_ARCH_TEGRA_114_SOC
+/* PLLXC has 4-bit PDIV, but entry 15 is not allowed in h/w */
+#define PLLXC_PDIV_MAX			14
+
+/* non-monotonic mapping below is not a typo */
+static u8 pllxc_p[PLLXC_PDIV_MAX + 1] = {
+	/* PDIV: 0, 1, 2, 3, 4, 5, 6,  7,  8,  9, 10, 11, 12, 13, 14 */
+	/* p: */ 1, 2, 3, 4, 5, 6, 8, 10, 12, 16, 12, 16, 20, 24, 32
+};
+
+#define PLLCX_PDIV_MAX 7
+static u8 pllcx_p[PLLCX_PDIV_MAX + 1] = {
+	/* PDIV: 0, 1, 2, 3, 4, 5,  6,  7 */
+	/* p: */ 1, 2, 3, 4, 6, 8, 12, 16
+};
+#endif
+
 static void clk_pll_enable_lock(struct tegra_clk_pll *pll)
 {
 	u32 val;
@@ -646,6 +706,520 @@ const struct clk_ops tegra_clk_plle_ops = {
 	.enable = clk_plle_enable,
 };
 
+#ifdef CONFIG_ARCH_TEGRA_114_SOC
+
+static int _pll_fixed_mdiv(struct tegra_clk_pll_params *pll_params,
+			   unsigned long parent_rate)
+{
+	if (parent_rate > pll_params->cf_max)
+		return 2;
+	else
+		return 1;
+}
+
+static int clk_pll_iddq_enable(struct clk_hw *hw)
+{
+	struct tegra_clk_pll *pll = to_clk_pll(hw);
+	unsigned long flags = 0;
+
+	u32 val;
+	int ret;
+
+	if (pll->lock)
+		spin_lock_irqsave(pll->lock, flags);
+
+	val = pll_readl(pll->params->iddq_reg, pll);
+	val &= ~BIT(pll->params->iddq_bit_idx);
+	pll_writel(val, pll->params->iddq_reg, pll);
+	udelay(2);
+
+	_clk_pll_enable(hw);
+
+	ret = clk_pll_wait_for_lock(pll);
+
+	if (pll->lock)
+		spin_unlock_irqrestore(pll->lock, flags);
+
+	return 0;
+}
+
+static void clk_pll_iddq_disable(struct clk_hw *hw)
+{
+	struct tegra_clk_pll *pll = to_clk_pll(hw);
+	unsigned long flags = 0;
+	u32 val;
+
+	if (pll->lock)
+		spin_lock_irqsave(pll->lock, flags);
+
+	_clk_pll_disable(hw);
+
+	val = pll_readl(pll->params->iddq_reg, pll);
+	val |= BIT(pll->params->iddq_bit_idx);
+	pll_writel(val, pll->params->iddq_reg, pll);
+	udelay(2);
+
+	if (pll->lock)
+		spin_unlock_irqrestore(pll->lock, flags);
+}
+
+static int _calc_dynamic_ramp_rate(struct clk_hw *hw,
+				struct tegra_clk_pll_freq_table *cfg,
+				unsigned long rate, unsigned long parent_rate)
+{
+	struct tegra_clk_pll *pll = to_clk_pll(hw);
+	unsigned int p;
+
+	if (!rate)
+		return -EINVAL;
+
+	p = DIV_ROUND_UP(pll->params->vco_min, rate);
+	cfg->m = _pll_fixed_mdiv(pll->params, parent_rate);
+	cfg->p = p;
+	cfg->output_rate = rate * cfg->p;
+	cfg->n = cfg->output_rate * cfg->m / parent_rate;
+
+	if (cfg->n > divn_max(pll) || cfg->output_rate > pll->params->vco_max)
+		return -EINVAL;
+
+	return 0;
+}
+
+static int _pll_ramp_calc_pll(struct clk_hw *hw,
+			      struct tegra_clk_pll_freq_table *cfg,
+			      unsigned long rate, unsigned long parent_rate)
+{
+	struct tegra_clk_pll *pll = to_clk_pll(hw);
+	int err = 0;
+
+	err = _get_table_rate(hw, cfg, rate, parent_rate);
+	if (err < 0)
+		err = _calc_dynamic_ramp_rate(hw, cfg, rate, parent_rate);
+	else if (cfg->m != _pll_fixed_mdiv(pll->params, parent_rate)) {
+			WARN_ON(1);
+			err = -EINVAL;
+			goto out;
+	}
+
+	if (!cfg->p || (cfg->p >  pll->params->max_p))
+		err = -EINVAL;
+
+out:
+	return err;
+}
+
+static int clk_pllxc_set_rate(struct clk_hw *hw, unsigned long rate,
+				unsigned long parent_rate)
+{
+	struct tegra_clk_pll *pll = to_clk_pll(hw);
+	struct tegra_clk_pll_freq_table cfg, old_cfg;
+	unsigned long flags = 0;
+	int ret = 0;
+	u8 old_p;
+
+	ret = _pll_ramp_calc_pll(hw, &cfg, rate, parent_rate);
+	if (ret < 0)
+		return ret;
+
+	if (pll->lock)
+		spin_lock_irqsave(pll->lock, flags);
+
+	_get_pll_mnp(pll, &old_cfg);
+
+	old_p = pllxc_p[old_cfg.p];
+	if (old_cfg.m != cfg.m || old_cfg.n != cfg.n || old_p != cfg.p) {
+		cfg.p -= 1;
+		ret = _program_pll(hw, &cfg, rate);
+	}
+
+	if (pll->lock)
+		spin_unlock_irqrestore(pll->lock, flags);
+
+	return ret;
+}
+
+static long clk_pll_ramp_round_rate(struct clk_hw *hw, unsigned long rate,
+				unsigned long *prate)
+{
+	struct tegra_clk_pll_freq_table cfg;
+	int ret = 0;
+	u64 output_rate = *prate;
+
+	ret = _pll_ramp_calc_pll(hw, &cfg, rate, *prate);
+	if (ret < 0)
+		return ret;
+
+	output_rate *= cfg.n;
+	do_div(output_rate, cfg.m * cfg.p);
+
+	return output_rate;
+}
+
+static int clk_pllm_set_rate(struct clk_hw *hw, unsigned long rate,
+				unsigned long parent_rate)
+{
+	struct tegra_clk_pll_freq_table cfg;
+	struct tegra_clk_pll *pll = to_clk_pll(hw);
+	unsigned long flags = 0;
+	int state, ret = 0;
+	u32 val;
+
+	if (pll->lock)
+		spin_lock_irqsave(pll->lock, flags);
+
+	state = clk_pll_is_enabled(hw);
+	if (state) {
+		if (rate != clk_get_rate(hw->clk)) {
+			pr_err("%s: Cannot change active PLLM\n", __func__);
+			ret = -EINVAL;
+			goto out;
+		}
+		goto out;
+	}
+
+	ret = _pll_ramp_calc_pll(hw, &cfg, rate, parent_rate);
+	if (ret < 0)
+		goto out;
+
+	cfg.p -= 1;
+
+	val = readl_relaxed(pll->pmc + PMC_PLLM_WB0_OVERRIDE);
+	if (val & PMC_PLLP_WB0_OVERRIDE_PLLM_OVERRIDE) {
+		val = readl_relaxed(pll->pmc + PMC_PLLM_WB0_OVERRIDE_2);
+		val = cfg.p ? (val | PMC_PLLM_WB0_OVERRIDE_2_DIVP_MASK) :
+			(val & ~PMC_PLLM_WB0_OVERRIDE_2_DIVP_MASK);
+		writel_relaxed(val, pll->pmc + PMC_PLLM_WB0_OVERRIDE_2);
+
+		val = readl_relaxed(pll->pmc + PMC_PLLM_WB0_OVERRIDE);
+		val &= ~(divn_mask(pll) | divm_mask(pll));
+		val |= (cfg.m << pll->divm_shift) | (cfg.n << pll->divn_shift);
+		writel_relaxed(val, pll->pmc + PMC_PLLM_WB0_OVERRIDE);
+	} else
+		_update_pll_mnp(pll, &cfg);
+
+
+out:
+	if (pll->lock)
+		spin_unlock_irqrestore(pll->lock, flags);
+
+	return ret;
+}
+
+static void _pllcx_strobe(struct tegra_clk_pll *pll)
+{
+	u32 val;
+
+	val = pll_readl_misc(pll);
+	val |= PLLCX_MISC_STROBE;
+	pll_writel_misc(val, pll);
+	udelay(2);
+
+	val &= ~PLLCX_MISC_STROBE;
+	pll_writel_misc(val, pll);
+}
+
+static int clk_pllc_enable(struct clk_hw *hw)
+{
+	struct tegra_clk_pll *pll = to_clk_pll(hw);
+	u32 val;
+	int ret = 0;
+	unsigned long flags = 0;
+
+	if (pll->lock)
+		spin_lock_irqsave(pll->lock, flags);
+
+	_clk_pll_enable(hw);
+	udelay(2);
+
+	val = pll_readl_misc(pll);
+	val &= ~PLLCX_MISC_RESET;
+	pll_writel_misc(val, pll);
+	udelay(2);
+
+	_pllcx_strobe(pll);
+
+	ret = clk_pll_wait_for_lock(pll);
+
+	if (pll->lock)
+		spin_unlock_irqrestore(pll->lock, flags);
+
+	return ret;
+}
+
+static void _clk_pllc_disable(struct clk_hw *hw)
+{
+	struct tegra_clk_pll *pll = to_clk_pll(hw);
+	u32 val;
+
+	_clk_pll_disable(hw);
+
+	val = pll_readl_misc(pll);
+	val |= PLLCX_MISC_RESET;
+	pll_writel_misc(val, pll);
+	udelay(2);
+}
+
+static void clk_pllc_disable(struct clk_hw *hw)
+{
+	struct tegra_clk_pll *pll = to_clk_pll(hw);
+	unsigned long flags = 0;
+
+	if (pll->lock)
+		spin_lock_irqsave(pll->lock, flags);
+
+	_clk_pllc_disable(hw);
+
+	if (pll->lock)
+		spin_unlock_irqrestore(pll->lock, flags);
+}
+
+static int _pllcx_update_dynamic_coef(struct tegra_clk_pll *pll,
+					unsigned long input_rate, u32 n)
+{
+	u32 val, n_threshold;
+
+	switch (input_rate) {
+	case 12000000:
+		n_threshold = 70;
+		break;
+	case 13000000:
+	case 26000000:
+		n_threshold = 71;
+		break;
+	case 16800000:
+		n_threshold = 55;
+		break;
+	case 19200000:
+		n_threshold = 48;
+		break;
+	default:
+		pr_err("%s: Unexpected reference rate %lu\n",
+			__func__, input_rate);
+		return -EINVAL;
+	}
+
+	val = pll_readl_misc(pll);
+	val &= ~(PLLCX_MISC_SDM_DIV_MASK | PLLCX_MISC_FILT_DIV_MASK);
+	val |= n <= n_threshold ?
+		PLLCX_MISC_DIV_LOW_RANGE : PLLCX_MISC_DIV_HIGH_RANGE;
+	pll_writel_misc(val, pll);
+
+	return 0;
+}
+
+static int clk_pllc_set_rate(struct clk_hw *hw, unsigned long rate,
+				unsigned long parent_rate)
+{
+	struct tegra_clk_pll_freq_table cfg;
+	struct tegra_clk_pll *pll = to_clk_pll(hw);
+	unsigned long flags = 0;
+	int state, ret = 0;
+	u32 val;
+	u16 old_m, old_n;
+	u8 old_p;
+
+	if (pll->lock)
+		spin_lock_irqsave(pll->lock, flags);
+
+	ret = _pll_ramp_calc_pll(hw, &cfg, rate, parent_rate);
+	if (ret < 0)
+		goto out;
+
+	val = pll_readl_base(pll);
+	old_m = (val >> pll->divm_shift) & (divm_mask(pll));
+	old_n = (val >> pll->divn_shift) & (divn_mask(pll));
+	old_p = pllcx_p[(val >> pll->divp_shift) & (divp_mask(pll))];
+
+	if (cfg.m != old_m) {
+		WARN_ON(1);
+		goto out;
+	}
+
+	if (old_n == cfg.n && old_p == cfg.p)
+		goto out;
+
+	cfg.p -= 1;
+
+	state = clk_pll_is_enabled(hw);
+	if (state)
+		_clk_pllc_disable(hw);
+
+	ret = _pllcx_update_dynamic_coef(pll, parent_rate, cfg.n);
+	if (ret < 0)
+		goto out;
+
+	_update_pll_mnp(pll, &cfg);
+
+	if (state)
+		ret = clk_pllc_enable(hw);
+
+out:
+	if (pll->lock)
+		spin_unlock_irqrestore(pll->lock, flags);
+
+	return ret;
+}
+
+static long _pllre_calc_rate(struct tegra_clk_pll *pll,
+			     struct tegra_clk_pll_freq_table *cfg,
+			     unsigned long rate, unsigned long parent_rate)
+{
+	u16 m, n;
+	u64 output_rate = parent_rate;
+
+	m = _pll_fixed_mdiv(pll->params, parent_rate);
+	n = rate * m / parent_rate;
+
+	output_rate *= n;
+	do_div(output_rate, m);
+
+	if (cfg) {
+		cfg->m = m;
+		cfg->n = n;
+	}
+
+	return output_rate;
+}
+static int clk_pllre_set_rate(struct clk_hw *hw, unsigned long rate,
+				unsigned long parent_rate)
+{
+	struct tegra_clk_pll_freq_table cfg, old_cfg;
+	struct tegra_clk_pll *pll = to_clk_pll(hw);
+	unsigned long flags = 0;
+	int state, ret = 0;
+
+	if (pll->lock)
+		spin_lock_irqsave(pll->lock, flags);
+
+	_pllre_calc_rate(pll, &cfg, rate, parent_rate);
+	_get_pll_mnp(pll, &old_cfg);
+	cfg.p = old_cfg.p;
+
+	if (cfg.m != old_cfg.m || cfg.n != old_cfg.n) {
+		state = clk_pll_is_enabled(hw);
+		if (state)
+			_clk_pll_disable(hw);
+
+		_update_pll_mnp(pll, &cfg);
+
+		if (state) {
+			_clk_pll_enable(hw);
+			ret = clk_pll_wait_for_lock(pll);
+		}
+	}
+
+	if (pll->lock)
+		spin_unlock_irqrestore(pll->lock, flags);
+
+	return ret;
+}
+
+static unsigned long clk_pllre_recalc_rate(struct clk_hw *hw,
+					 unsigned long parent_rate)
+{
+	struct tegra_clk_pll_freq_table cfg;
+	struct tegra_clk_pll *pll = to_clk_pll(hw);
+	u64 rate = parent_rate;
+
+	_get_pll_mnp(pll, &cfg);
+
+	rate *= cfg.n;
+	do_div(rate, cfg.m);
+
+	return rate;
+}
+
+static long clk_pllre_round_rate(struct clk_hw *hw, unsigned long rate,
+				 unsigned long *prate)
+{
+	struct tegra_clk_pll *pll = to_clk_pll(hw);
+
+	return _pllre_calc_rate(pll, NULL, rate, *prate);
+}
+
+static int clk_plle_tegra114_enable(struct clk_hw *hw)
+{
+	struct tegra_clk_pll *pll = to_clk_pll(hw);
+	struct tegra_clk_pll_freq_table sel;
+	u32 val;
+	int ret;
+	unsigned long flags = 0;
+	unsigned long input_rate = clk_get_rate(clk_get_parent(hw->clk));
+
+	if (_get_table_rate(hw, &sel, pll->fixed_rate, input_rate))
+		return -EINVAL;
+
+	if (pll->lock)
+		spin_lock_irqsave(pll->lock, flags);
+
+	val = pll_readl_base(pll);
+	val &= ~BIT(29); /* Disable lock override */
+	pll_writel_base(val, pll);
+
+	val = pll_readl(pll->params->aux_reg, pll);
+	val |= PLLE_AUX_ENABLE_SWCTL;
+	val &= ~PLLE_AUX_SEQ_ENABLE;
+	pll_writel(val, pll->params->aux_reg, pll);
+	udelay(1);
+
+	val = pll_readl_misc(pll);
+	val |= PLLE_MISC_LOCK_ENABLE;
+	val |= PLLE_MISC_IDDQ_SW_CTRL;
+	val &= ~PLLE_MISC_IDDQ_SW_VALUE;
+	val |= PLLE_MISC_PLLE_PTS;
+	val |= PLLE_MISC_VREG_BG_CTRL_MASK | PLLE_MISC_VREG_CTRL_MASK;
+	pll_writel_misc(val, pll);
+	udelay(5);
+
+	val = pll_readl(PLLE_SS_CTRL, pll);
+	val |= PLLE_SS_DISABLE;
+	pll_writel(val, PLLE_SS_CTRL, pll);
+
+	val = pll_readl_base(pll);
+	val &= ~(divm_mask(pll) | divn_mask(pll) | divp_mask(pll));
+	val &= ~(PLLE_BASE_DIVCML_WIDTH << PLLE_BASE_DIVCML_SHIFT);
+	val |= sel.m << pll->divm_shift;
+	val |= sel.n << pll->divn_shift;
+	val |= sel.cpcon << PLLE_BASE_DIVCML_SHIFT;
+	pll_writel_base(val, pll);
+	udelay(1);
+
+	_clk_pll_enable(hw);
+	ret = clk_pll_wait_for_lock(pll);
+
+	if (ret < 0)
+		goto out;
+
+	/* TODO: enable hw control of xusb brick pll */
+
+out:
+	if (pll->lock)
+		spin_unlock_irqrestore(pll->lock, flags);
+
+	return ret;
+}
+
+static void clk_plle_tegra114_disable(struct clk_hw *hw)
+{
+	struct tegra_clk_pll *pll = to_clk_pll(hw);
+	unsigned long flags = 0;
+	u32 val;
+
+	if (pll->lock)
+		spin_lock_irqsave(pll->lock, flags);
+
+	_clk_pll_disable(hw);
+
+	val = pll_readl_misc(pll);
+	val |= PLLE_MISC_IDDQ_SW_CTRL | PLLE_MISC_IDDQ_SW_VALUE;
+	pll_writel_misc(val, pll);
+	udelay(1);
+
+	if (pll->lock)
+		spin_unlock_irqrestore(pll->lock, flags);
+}
+#endif
+
 static struct tegra_clk_pll *_tegra_init_pll(void __iomem *clk_base,
 		void __iomem *pmc, unsigned long fixed_rate,
 		struct tegra_clk_pll_params *pll_params, u32 pll_flags,
@@ -741,3 +1315,268 @@ struct clk *tegra_clk_register_plle(const char *name, const char *parent_name,
 
 	return clk;
 }
+
+#ifdef CONFIG_ARCH_TEGRA_114_SOC
+const struct clk_ops tegra_clk_pllxc_ops = {
+	.is_enabled = clk_pll_is_enabled,
+	.enable = clk_pll_iddq_enable,
+	.disable = clk_pll_iddq_disable,
+	.recalc_rate = clk_pll_recalc_rate,
+	.round_rate = clk_pll_ramp_round_rate,
+	.set_rate = clk_pllxc_set_rate,
+};
+
+const struct clk_ops tegra_clk_pllm_ops = {
+	.is_enabled = clk_pll_is_enabled,
+	.enable = clk_pll_iddq_enable,
+	.disable = clk_pll_iddq_disable,
+	.recalc_rate = clk_pll_recalc_rate,
+	.round_rate = clk_pll_ramp_round_rate,
+	.set_rate = clk_pllm_set_rate,
+};
+
+const struct clk_ops tegra_clk_pllc_ops = {
+	.is_enabled = clk_pll_is_enabled,
+	.enable = clk_pllc_enable,
+	.disable = clk_pllc_disable,
+	.recalc_rate = clk_pll_recalc_rate,
+	.round_rate = clk_pll_ramp_round_rate,
+	.set_rate = clk_pllc_set_rate,
+};
+
+const struct clk_ops tegra_clk_pllre_ops = {
+	.is_enabled = clk_pll_is_enabled,
+	.enable = clk_pll_iddq_enable,
+	.disable = clk_pll_iddq_disable,
+	.recalc_rate = clk_pllre_recalc_rate,
+	.round_rate = clk_pllre_round_rate,
+	.set_rate = clk_pllre_set_rate,
+};
+
+const struct clk_ops tegra_clk_plle_tegra114_ops = {
+	.is_enabled =  clk_pll_is_enabled,
+	.enable = clk_plle_tegra114_enable,
+	.disable = clk_plle_tegra114_disable,
+	.recalc_rate = clk_pll_recalc_rate,
+};
+
+
+struct clk *tegra_clk_register_pllxc(const char *name, const char *parent_name,
+			  void __iomem *clk_base, void __iomem *pmc,
+			  unsigned long flags, unsigned long fixed_rate,
+			  struct tegra_clk_pll_params *pll_params,
+			  u32 pll_flags,
+			  struct tegra_clk_pll_freq_table *freq_table,
+			  spinlock_t *lock)
+{
+	struct tegra_clk_pll *pll;
+	struct clk *clk;
+
+	if (!pll_params->pdiv_tohw)
+		return ERR_PTR(-EINVAL);
+
+	pll_flags |= TEGRA_PLL_HAS_LOCK_ENABLE;
+	pll = _tegra_init_pll(clk_base, pmc, fixed_rate, pll_params, pll_flags,
+			      freq_table, lock);
+	if (IS_ERR(pll))
+		return ERR_CAST(pll);
+
+	clk = _tegra_clk_register_pll(pll, name, parent_name, flags,
+				      &tegra_clk_pllxc_ops);
+	if (IS_ERR(clk))
+		kfree(pll);
+
+	return clk;
+}
+
+struct clk *tegra_clk_register_pllre(const char *name, const char *parent_name,
+			  void __iomem *clk_base, void __iomem *pmc,
+			  unsigned long flags, unsigned long fixed_rate,
+			  struct tegra_clk_pll_params *pll_params,
+			  u32 pll_flags,
+			  struct tegra_clk_pll_freq_table *freq_table,
+			  spinlock_t *lock, unsigned long parent_rate)
+{
+	u32 val;
+	struct tegra_clk_pll *pll;
+	struct clk *clk;
+
+	pll_flags |= TEGRA_PLL_HAS_LOCK_ENABLE;
+	pll = _tegra_init_pll(clk_base, pmc, fixed_rate, pll_params, pll_flags,
+			      freq_table, lock);
+	if (IS_ERR(pll))
+		return ERR_CAST(pll);
+
+	/* program minimum rate by default */
+
+	val = pll_readl_base(pll);
+	if (val & PLL_BASE_ENABLE)
+		WARN_ON(val & pll_params->iddq_bit_idx);
+	else {
+		int m;
+
+		m = _pll_fixed_mdiv(pll_params, parent_rate);
+		val = m << PLL_BASE_DIVM_SHIFT;
+		val |= (pll_params->vco_min / parent_rate)
+				<< PLL_BASE_DIVN_SHIFT;
+		pll_writel_base(val, pll);
+	}
+
+	/* disable lock override */
+
+	val = pll_readl_misc(pll);
+	val &= ~BIT(29);
+	pll_writel_misc(val, pll);
+
+	pll_flags |= TEGRA_PLL_LOCK_MISC;
+	clk = _tegra_clk_register_pll(pll, name, parent_name, flags,
+				      &tegra_clk_pllre_ops);
+	if (IS_ERR(clk))
+		kfree(pll);
+
+	return clk;
+}
+
+struct clk *tegra_clk_register_pllm(const char *name, const char *parent_name,
+			  void __iomem *clk_base, void __iomem *pmc,
+			  unsigned long flags, unsigned long fixed_rate,
+			  struct tegra_clk_pll_params *pll_params,
+			  u32 pll_flags,
+			  struct tegra_clk_pll_freq_table *freq_table,
+			  spinlock_t *lock)
+{
+	struct tegra_clk_pll *pll;
+	struct clk *clk;
+
+	if (!pll_params->pdiv_tohw)
+		return ERR_PTR(-EINVAL);
+
+	pll_flags |= TEGRA_PLL_BYPASS;
+	pll_flags |= TEGRA_PLL_HAS_LOCK_ENABLE;
+	pll = _tegra_init_pll(clk_base, pmc, fixed_rate, pll_params, pll_flags,
+			      freq_table, lock);
+	if (IS_ERR(pll))
+		return ERR_CAST(pll);
+
+	clk = _tegra_clk_register_pll(pll, name, parent_name, flags,
+				      &tegra_clk_pllm_ops);
+	if (IS_ERR(clk))
+		kfree(pll);
+
+	return clk;
+}
+
+struct clk *tegra_clk_register_pllc(const char *name, const char *parent_name,
+			  void __iomem *clk_base, void __iomem *pmc,
+			  unsigned long flags, unsigned long fixed_rate,
+			  struct tegra_clk_pll_params *pll_params,
+			  u32 pll_flags,
+			  struct tegra_clk_pll_freq_table *freq_table,
+			  spinlock_t *lock)
+{
+	struct clk *parent, *clk;
+	struct pdiv_map *p_tohw = pll_params->pdiv_tohw;
+	struct tegra_clk_pll *pll;
+	struct tegra_clk_pll_freq_table cfg;
+	unsigned long parent_rate;
+
+	if (!p_tohw)
+		return ERR_PTR(-EINVAL);
+
+	parent = __clk_lookup(parent_name);
+	if (IS_ERR(parent)) {
+		WARN(1, "parent clk %s of %s must be registered first\n",
+			name, parent_name);
+		return ERR_PTR(-EINVAL);
+	}
+
+	pll_flags |= TEGRA_PLL_BYPASS;
+	pll = _tegra_init_pll(clk_base, pmc, fixed_rate, pll_params, pll_flags,
+			      freq_table, lock);
+	if (IS_ERR(pll))
+		return ERR_CAST(pll);
+
+	parent_rate = __clk_get_rate(parent);
+
+	/*
+	 * Most of PLLC register fields are shadowed, and can not be read
+	 * directly from PLL h/w. Hence, actual PLLC boot state is unknown.
+	 * Initialize PLL to default state: disabled, reset; shadow registers
+	 * loaded with default parameters; dividers are preset for half of
+	 * minimum VCO rate (the latter assured that shadowed divider settings
+	 * are within supported range).
+	 */
+
+	cfg.m = _pll_fixed_mdiv(pll_params, parent_rate);
+	cfg.n = cfg.m * pll_params->vco_min / parent_rate;
+
+	while (p_tohw->pdiv) {
+		if (p_tohw->pdiv == 2) {
+			cfg.p = p_tohw->hw_val;
+			break;
+		}
+		p_tohw++;
+	}
+
+	if (!p_tohw->pdiv) {
+		WARN_ON(1);
+		return ERR_PTR(-EINVAL);
+	}
+
+	pll_writel_base(0, pll);
+	_update_pll_mnp(pll, &cfg);
+
+	pll_writel_misc(PLLCX_MISC_DEFAULT, pll);
+	pll_writel(PLLCX_MISC1_DEFAULT, pll_params->ext_misc_reg[0], pll);
+	pll_writel(PLLCX_MISC2_DEFAULT, pll_params->ext_misc_reg[1], pll);
+	pll_writel(PLLCX_MISC3_DEFAULT, pll_params->ext_misc_reg[2], pll);
+
+	_pllcx_update_dynamic_coef(pll, parent_rate, cfg.n);
+
+	clk = _tegra_clk_register_pll(pll, name, parent_name, flags,
+				      &tegra_clk_pllc_ops);
+	if (IS_ERR(clk))
+		kfree(pll);
+
+	return clk;
+}
+
+struct clk *tegra_clk_register_plle_tegra114(const char *name,
+				const char *parent_name,
+				void __iomem *clk_base, unsigned long flags,
+				unsigned long fixed_rate,
+				struct tegra_clk_pll_params *pll_params,
+				struct tegra_clk_pll_freq_table *freq_table,
+				spinlock_t *lock)
+{
+	struct tegra_clk_pll *pll;
+	struct clk *clk;
+	u32 val, val_aux;
+
+	pll = _tegra_init_pll(clk_base, NULL, fixed_rate, pll_params,
+			      TEGRA_PLL_HAS_LOCK_ENABLE, freq_table, lock);
+	if (IS_ERR(pll))
+		return ERR_CAST(pll);
+
+	/* ensure parent is set to pll_re_vco */
+
+	val = pll_readl_base(pll);
+	val_aux = pll_readl(pll_params->aux_reg, pll);
+
+	if (val & PLL_BASE_ENABLE) {
+		if (!(val_aux & PLLE_AUX_PLLRE_SEL))
+			WARN(1, "pll_e enabled with unsupported parent %s\n",
+			  (val & PLLE_AUX_PLLP_SEL) ? "pllp_out0" : "pll_ref");
+	} else {
+		val_aux |= PLLE_AUX_PLLRE_SEL;
+		pll_writel(val, pll_params->aux_reg, pll);
+	}
+
+	clk = _tegra_clk_register_pll(pll, name, parent_name, flags,
+				      &tegra_clk_plle_tegra114_ops);
+	if (IS_ERR(clk))
+		kfree(pll);
+
+	return clk;
+}
+#endif
diff --git a/drivers/clk/tegra/clk.h b/drivers/clk/tegra/clk.h
index 3b498e0..8cedb09 100644
--- a/drivers/clk/tegra/clk.h
+++ b/drivers/clk/tegra/clk.h
@@ -1,4 +1,4 @@
-/*
+	/*
  * Copyright (c) 2012, NVIDIA CORPORATION.  All rights reserved.
  *
  * This program is free software; you can redistribute it and/or modify it
@@ -156,6 +156,13 @@ struct tegra_clk_pll_params {
 	u32		lock_reg;
 	u32		lock_mask;
 	u32		lock_enable_bit_idx;
+	u32		iddq_reg;
+	u32		iddq_bit_idx;
+	u32		aux_reg;
+	u32		dyn_ramp_reg;
+	u32		ext_misc_reg[3];
+	int		stepa_shift;
+	int		stepb_shift;
 	int		lock_delay;
 	int		max_p;
 	struct pdiv_map *pdiv_tohw;
@@ -238,12 +245,53 @@ struct clk *tegra_clk_register_pll(const char *name, const char *parent_name,
 		unsigned long flags, unsigned long fixed_rate,
 		struct tegra_clk_pll_params *pll_params, u32 pll_flags,
 		struct tegra_clk_pll_freq_table *freq_table, spinlock_t *lock);
+
 struct clk *tegra_clk_register_plle(const char *name, const char *parent_name,
 		void __iomem *clk_base, void __iomem *pmc,
 		unsigned long flags, unsigned long fixed_rate,
 		struct tegra_clk_pll_params *pll_params, u32 pll_flags,
 		struct tegra_clk_pll_freq_table *freq_table, spinlock_t *lock);
 
+struct clk *tegra_clk_register_pllxc(const char *name, const char *parent_name,
+			    void __iomem *clk_base, void __iomem *pmc,
+			    unsigned long flags, unsigned long fixed_rate,
+			    struct tegra_clk_pll_params *pll_params,
+			    u32 pll_flags,
+			    struct tegra_clk_pll_freq_table *freq_table,
+			    spinlock_t *lock);
+
+struct clk *tegra_clk_register_pllm(const char *name, const char *parent_name,
+			   void __iomem *clk_base, void __iomem *pmc,
+			   unsigned long flags, unsigned long fixed_rate,
+			   struct tegra_clk_pll_params *pll_params,
+			   u32 pll_flags,
+			   struct tegra_clk_pll_freq_table *freq_table,
+			   spinlock_t *lock);
+
+struct clk *tegra_clk_register_pllc(const char *name, const char *parent_name,
+			   void __iomem *clk_base, void __iomem *pmc,
+			   unsigned long flags, unsigned long fixed_rate,
+			   struct tegra_clk_pll_params *pll_params,
+			   u32 pll_flags,
+			   struct tegra_clk_pll_freq_table *freq_table,
+			   spinlock_t *lock);
+
+struct clk *tegra_clk_register_pllre(const char *name, const char *parent_name,
+			   void __iomem *clk_base, void __iomem *pmc,
+			   unsigned long flags, unsigned long fixed_rate,
+			   struct tegra_clk_pll_params *pll_params,
+			   u32 pll_flags,
+			   struct tegra_clk_pll_freq_table *freq_table,
+			   spinlock_t *lock, unsigned long parent_rate);
+
+struct clk *tegra_clk_register_plle_tegra114(const char *name,
+				const char *parent_name,
+				void __iomem *clk_base, unsigned long flags,
+				unsigned long fixed_rate,
+				struct tegra_clk_pll_params *pll_params,
+				struct tegra_clk_pll_freq_table *freq_table,
+				spinlock_t *lock);
+
 /**
  * struct tegra_clk_pll_out - PLL divider down clock
  *
-- 
1.7.7.rc0.72.g4b5ea.dirty



From pdeschrijver at nvidia.com  Wed Apr  3 10:40:42 2013
From: pdeschrijver at nvidia.com (Peter De Schrijver)
Date: Wed, 3 Apr 2013 17:40:42 +0300
Subject: [PATCH v9 08/14] clk: tegra: Add flags to tegra_clk_periph()
In-Reply-To: <1365000110-8916-1-git-send-email-pdeschrijver@nvidia.com>
References: <1365000110-8916-1-git-send-email-pdeschrijver@nvidia.com>
Message-ID: <1365000110-8916-9-git-send-email-pdeschrijver@nvidia.com>

We will need some tegra peripheral clocks with the CLK_IGNORE_UNUSED flag,
most notably mselect, which is a bridge between AXI and most peripherals.

Signed-off-by: Peter De Schrijver <pdeschrijver at nvidia.com>
---
 drivers/clk/tegra/clk-periph.c  |   11 ++++++-----
 drivers/clk/tegra/clk-tegra20.c |    2 +-
 drivers/clk/tegra/clk-tegra30.c |    2 +-
 drivers/clk/tegra/clk.h         |    9 ++++++---
 4 files changed, 14 insertions(+), 10 deletions(-)

diff --git a/drivers/clk/tegra/clk-periph.c b/drivers/clk/tegra/clk-periph.c
index 788486e..067abb3 100644
--- a/drivers/clk/tegra/clk-periph.c
+++ b/drivers/clk/tegra/clk-periph.c
@@ -170,14 +170,15 @@ const struct clk_ops tegra_clk_periph_nodiv_ops = {
 static struct clk *_tegra_clk_register_periph(const char *name,
 			const char **parent_names, int num_parents,
 			struct tegra_clk_periph *periph,
-			void __iomem *clk_base, u32 offset, bool div)
+			void __iomem *clk_base, u32 offset, bool div,
+			unsigned long flags)
 {
 	struct clk *clk;
 	struct clk_init_data init;
 
 	init.name = name;
 	init.ops = div ? &tegra_clk_periph_ops : &tegra_clk_periph_nodiv_ops;
-	init.flags = div ? 0 : CLK_SET_RATE_PARENT;
+	init.flags = flags;
 	init.parent_names = parent_names;
 	init.num_parents = num_parents;
 
@@ -202,10 +203,10 @@ static struct clk *_tegra_clk_register_periph(const char *name,
 struct clk *tegra_clk_register_periph(const char *name,
 		const char **parent_names, int num_parents,
 		struct tegra_clk_periph *periph, void __iomem *clk_base,
-		u32 offset)
+		u32 offset, unsigned long flags)
 {
 	return _tegra_clk_register_periph(name, parent_names, num_parents,
-			periph, clk_base, offset, true);
+			periph, clk_base, offset, true, flags);
 }
 
 struct clk *tegra_clk_register_periph_nodiv(const char *name,
@@ -214,5 +215,5 @@ struct clk *tegra_clk_register_periph_nodiv(const char *name,
 		u32 offset)
 {
 	return _tegra_clk_register_periph(name, parent_names, num_parents,
-			periph, clk_base, offset, false);
+			periph, clk_base, offset, false, CLK_SET_RATE_PARENT);
 }
diff --git a/drivers/clk/tegra/clk-tegra20.c b/drivers/clk/tegra/clk-tegra20.c
index b6a747f..05c4995 100644
--- a/drivers/clk/tegra/clk-tegra20.c
+++ b/drivers/clk/tegra/clk-tegra20.c
@@ -1019,7 +1019,7 @@ static void __init tegra20_periph_clk_init(void)
 		data = &tegra_periph_clk_list[i];
 		clk = tegra_clk_register_periph(data->name, data->parent_names,
 				data->num_parents, &data->periph,
-				clk_base, data->offset);
+				clk_base, data->offset, data->flags);
 		clk_register_clkdev(clk, data->con_id, data->dev_id);
 		clks[data->clk_id] = clk;
 	}
diff --git a/drivers/clk/tegra/clk-tegra30.c b/drivers/clk/tegra/clk-tegra30.c
index 9c43bb4..7e749b0 100644
--- a/drivers/clk/tegra/clk-tegra30.c
+++ b/drivers/clk/tegra/clk-tegra30.c
@@ -1668,7 +1668,7 @@ static void __init tegra30_periph_clk_init(void)
 		data = &tegra_periph_clk_list[i];
 		clk = tegra_clk_register_periph(data->name, data->parent_names,
 				data->num_parents, &data->periph,
-				clk_base, data->offset);
+				clk_base, data->offset, data->flags);
 		clk_register_clkdev(clk, data->con_id, data->dev_id);
 		clks[data->clk_id] = clk;
 	}
diff --git a/drivers/clk/tegra/clk.h b/drivers/clk/tegra/clk.h
index 8cedb09..fd12b77 100644
--- a/drivers/clk/tegra/clk.h
+++ b/drivers/clk/tegra/clk.h
@@ -417,7 +417,7 @@ extern const struct clk_ops tegra_clk_periph_ops;
 struct clk *tegra_clk_register_periph(const char *name,
 		const char **parent_names, int num_parents,
 		struct tegra_clk_periph *periph, void __iomem *clk_base,
-		u32 offset);
+		u32 offset, unsigned long flags);
 struct clk *tegra_clk_register_periph_nodiv(const char *name,
 		const char **parent_names, int num_parents,
 		struct tegra_clk_periph *periph, void __iomem *clk_base,
@@ -460,12 +460,14 @@ struct tegra_periph_init_data {
 	u32 offset;
 	const char *con_id;
 	const char *dev_id;
+	unsigned long flags;
 };
 
 #define TEGRA_INIT_DATA_TABLE(_name, _con_id, _dev_id, _parent_names, _offset,\
 			_mux_shift, _mux_mask, _mux_flags, _div_shift,	\
 			_div_width, _div_frac_width, _div_flags, _regs,	\
-			_clk_num, _enb_refcnt, _gate_flags, _clk_id, _table) \
+			_clk_num, _enb_refcnt, _gate_flags, _clk_id, _table,\
+			_flags) \
 	{								\
 		.name = _name,						\
 		.clk_id = _clk_id,					\
@@ -480,6 +482,7 @@ struct tegra_periph_init_data {
 		.offset = _offset,					\
 		.con_id = _con_id,					\
 		.dev_id = _dev_id,					\
+		.flags = _flags						\
 	}
 
 #define TEGRA_INIT_DATA(_name, _con_id, _dev_id, _parent_names, _offset,\
@@ -490,7 +493,7 @@ struct tegra_periph_init_data {
 			_mux_shift, BIT(_mux_width) - 1, _mux_flags,	\
 			_div_shift, _div_width, _div_frac_width, _div_flags, \
 			_regs, _clk_num, _enb_refcnt, _gate_flags, _clk_id,\
-			NULL)
+			NULL, 0)
 
 /**
  * struct clk_super_mux - super clock
-- 
1.7.7.rc0.72.g4b5ea.dirty



From pdeschrijver at nvidia.com  Wed Apr  3 10:40:43 2013
From: pdeschrijver at nvidia.com (Peter De Schrijver)
Date: Wed, 3 Apr 2013 17:40:43 +0300
Subject: [PATCH v9 10/14] ARM: tegra: Define Tegra114 CAR binding
In-Reply-To: <1365000110-8916-1-git-send-email-pdeschrijver@nvidia.com>
References: <1365000110-8916-1-git-send-email-pdeschrijver@nvidia.com>
Message-ID: <1365000110-8916-10-git-send-email-pdeschrijver@nvidia.com>

The device tree binding models Tegra114 CAR (Clock And Reset) as a single
monolithic clock provider.

Signed-off-by: Peter De Schrijver <pdeschrijver at nvidia.com>
---
 .../bindings/clock/nvidia,tegra114-car.txt         |  317 ++++++++++++++++++++
 1 files changed, 317 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/clock/nvidia,tegra114-car.txt

diff --git a/Documentation/devicetree/bindings/clock/nvidia,tegra114-car.txt b/Documentation/devicetree/bindings/clock/nvidia,tegra114-car.txt
new file mode 100644
index 0000000..33574a2
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/nvidia,tegra114-car.txt
@@ -0,0 +1,317 @@
+NVIDIA Tegra114 Clock And Reset Controller
+
+This binding uses the common clock binding:
+Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+The CAR (Clock And Reset) Controller on Tegra is the HW module responsible
+for muxing and gating Tegra's clocks, and setting their rates.
+
+Required properties :
+- compatible : Should be "nvidia,tegra114-car"
+- reg : Should contain CAR registers location and length
+- clocks : Should contain phandle and clock specifiers for two clocks:
+  the 32 KHz "32k_in", and the board-specific oscillator "osc".
+- #clock-cells : Should be 1.
+  In clock consumers, this cell represents the clock ID exposed by the CAR.
+
+  The first 160 clocks are numbered to match the bits in the CAR's CLK_OUT_ENB
+  registers. These IDs often match those in the CAR's RST_DEVICES registers,
+  but not in all cases. Some bits in CLK_OUT_ENB affect multiple clocks. In
+  this case, those clocks are assigned IDs above 160 in order to highlight
+  this issue. Implementations that interpret these clock IDs as bit values
+  within the CLK_OUT_ENB or RST_DEVICES registers should be careful to
+  explicitly handle these special cases.
+
+  The balance of the clocks controlled by the CAR are assigned IDs of 160 and
+  above.
+
+  0	unassigned
+  1	unassigned
+  2	unassigned
+  3	unassigned
+  4	rtc
+  5	timer
+  6	uarta
+  7	unassigned	(register bit affects uartb and vfir)
+  8	unassigned
+  9	sdmmc2
+  10	unassigned	(register bit affects spdif_in and spdif_out)
+  11	i2s1
+  12	i2c1
+  13	ndflash
+  14	sdmmc1
+  15	sdmmc4
+  16	unassigned
+  17	pwm
+  18	i2s2
+  19	epp
+  20	unassigned	(register bit affects vi and vi_sensor)
+  21	2d
+  22	usbd
+  23	isp
+  24	3d
+  25	unassigned
+  26	disp2
+  27	disp1
+  28	host1x
+  29	vcp
+  30	i2s0
+  31	unassigned
+
+  32	unassigned
+  33	unassigned
+  34	apbdma
+  35	unassigned
+  36	kbc
+  37	unassigned
+  38	unassigned
+  39	unassigned	(register bit affects fuse and fuse_burn)
+  40	kfuse
+  41	sbc1
+  42	nor
+  43	unassigned
+  44	sbc2
+  45	unassigned
+  46	sbc3
+  47	i2c5
+  48	dsia
+  49	unassigned
+  50	mipi
+  51	hdmi
+  52	csi
+  53	unassigned
+  54	i2c2
+  55	uartc
+  56	mipi-cal
+  57	emc
+  58	usb2
+  59	usb3
+  60	msenc
+  61	vde
+  62	bsea
+  63	bsev
+
+  64	unassigned
+  65	uartd
+  66	unassigned
+  67	i2c3
+  68	sbc4
+  69	sdmmc3
+  70	unassigned
+  71	owr
+  72	afi
+  73	csite
+  74	unassigned
+  75	unassigned
+  76	la
+  77	trace
+  78	soc_therm
+  79	dtv
+  80	ndspeed
+  81	i2cslow
+  82	dsib
+  83	tsec
+  84	unassigned
+  85	unassigned
+  86	unassigned
+  87	unassigned
+  88	unassigned
+  89	xusb_host
+  90	unassigned
+  91	msenc
+  92	csus
+  93	unassigned
+  94	unassigned
+  95	unassigned	(bit affects xusb_dev and xusb_dev_src)
+
+  96	unassigned
+  97	unassigned
+  98	unassigned
+  99	mselect
+  100	tsensor
+  101	i2s3
+  102	i2s4
+  103	i2c4
+  104	sbc5
+  105	sbc6
+  106	d_audio
+  107	apbif
+  108	dam0
+  109	dam1
+  110	dam2
+  111	hda2codec_2x
+  112	unassigned
+  113	audio0_2x
+  114	audio1_2x
+  115	audio2_2x
+  116	audio3_2x
+  117	audio4_2x
+  118	spdif_2x
+  119	actmon
+  120	extern1
+  121	extern2
+  122	extern3
+  123	unassigned
+  124	unassigned
+  125	hda
+  126	unassigned
+  127	se
+
+  128	hda2hdmi
+  129	unassigned
+  130	unassigned
+  131	unassigned
+  132	unassigned
+  133	unassigned
+  134	unassigned
+  135	unassigned
+  136	unassigned
+  137	unassigned
+  138	unassigned
+  139	unassigned
+  140	unassigned
+  141	unassigned
+  142	unassigned
+  143	unassigned	(bit affects xusb_falcon_src, xusb_fs_src,
+			 xusb_host_src and xusb_ss_src)
+  144	cilab
+  145	cilcd
+  146	cile
+  147	dsialp
+  148	dsiblp
+  149	unassigned
+  150	dds
+  151	unassigned
+  152	dp2
+  153	amx
+  154	adx
+  155	unassigned	(bit affects dfll_ref and dfll_soc)
+  156	xusb_ss
+
+  192	uartb
+  193	vfir
+  194	spdif_in
+  195	spdif_out
+  196	vi
+  197	vi_sensor
+  198	fuse
+  199	fuse_burn
+  200	clk_32k
+  201	clk_m
+  202	clk_m_div2
+  203	clk_m_div4
+  204	pll_ref
+  205	pll_c
+  206	pll_c_out1
+  207	pll_c2
+  208	pll_c3
+  209	pll_m
+  210	pll_m_out1
+  211	pll_p
+  212	pll_p_out1
+  213	pll_p_out2
+  214	pll_p_out3
+  215	pll_p_out4
+  216	pll_a
+  217	pll_a_out0
+  218	pll_d
+  219	pll_d_out0
+  220	pll_d2
+  221	pll_d2_out0
+  222	pll_u
+  223	pll_u_480M
+  224	pll_u_60M
+  225	pll_u_48M
+  226	pll_u_12M
+  227	pll_x
+  228	pll_x_out0
+  229	pll_re_vco
+  230	pll_re_out
+  231	pll_e_out0
+  232	spdif_in_sync
+  233	i2s0_sync
+  234	i2s1_sync
+  235	i2s2_sync
+  236	i2s3_sync
+  237	i2s4_sync
+  238	vimclk_sync
+  239	audio0
+  240	audio1
+  241	audio2
+  242	audio3
+  243	audio4
+  244	spdif
+  245	clk_out_1
+  246	clk_out_2
+  247	clk_out_3
+  248	blink
+  252	xusb_host_src
+  253	xusb_falcon_src
+  254	xusb_fs_src
+  255	xusb_ss_src
+  256	xusb_dev_src
+  257	xusb_dev
+  258	xusb_hs_src
+  259	sclk
+  260	hclk
+  261	pclk
+  262	cclk_g
+  263	cclk_lp
+  264	dfll_ref
+  265	dfll_soc
+
+Mux clocks
+
+  300	audio0_mux
+  301	audio1_mux
+  302	audio2_mux
+  303	audio3_mux
+  304	audio4_mux
+  305	spdif_mux
+  306	clk_out_1_mux
+  307	clk_out_2_mux
+  308	clk_out_3_mux
+  309	dsia_mux
+  310	dsib_mux
+
+Example SoC include file:
+
+/ {
+	tegra_car: clock {
+		compatible = "nvidia,tegra114-car";
+		reg = <0x60006000 0x1000>;
+		#clock-cells = <1>;
+	};
+
+	usb at c5004000 {
+		clocks = <&tegra_car 58>; /* usb2 */
+	};
+};
+
+Example board file:
+
+/ {
+	clocks {
+		compatible = "simple-bus";
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		osc: clock at 0 {
+			compatible = "fixed-clock";
+			reg = <0>;
+			#clock-cells = <0>;
+			clock-frequency = <12000000>;
+		};
+
+		clk_32k: clock at 1 {
+			compatible = "fixed-clock";
+			reg = <1>;
+			#clock-cells = <0>;
+			clock-frequency = <32768>;
+		};
+	};
+
+	&tegra_car {
+		clocks = <&clk_32k> <&osc>;
+	};
+};
-- 
1.7.7.rc0.72.g4b5ea.dirty



From pdeschrijver at nvidia.com  Wed Apr  3 10:40:44 2013
From: pdeschrijver at nvidia.com (Peter De Schrijver)
Date: Wed, 3 Apr 2013 17:40:44 +0300
Subject: [PATCH v9 09/14] clk: tegra: Workaround for Tegra114 MSENC problem
In-Reply-To: <1365000110-8916-1-git-send-email-pdeschrijver@nvidia.com>
References: <1365000110-8916-1-git-send-email-pdeschrijver@nvidia.com>
Message-ID: <1365000110-8916-11-git-send-email-pdeschrijver@nvidia.com>

Workaround a hardware bug in MSENC during clock enable.

Signed-off-by: Peter De Schrijver <pdeschrijver at nvidia.com>
---
 drivers/clk/tegra/clk-periph-gate.c |    9 +++++++++
 drivers/clk/tegra/clk.h             |    2 ++
 2 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/drivers/clk/tegra/clk-periph-gate.c b/drivers/clk/tegra/clk-periph-gate.c
index 6dd5332..c9083fb 100644
--- a/drivers/clk/tegra/clk-periph-gate.c
+++ b/drivers/clk/tegra/clk-periph-gate.c
@@ -43,6 +43,8 @@ static DEFINE_SPINLOCK(periph_ref_lock);
 
 #define periph_clk_to_bit(periph) (1 << (gate->clk_num % 32))
 
+#define LVL2_CLK_GATE_OVRE 0x554
+
 /* Peripheral gate clock ops */
 static int clk_periph_is_enabled(struct clk_hw *hw)
 {
@@ -83,6 +85,13 @@ static int clk_periph_enable(struct clk_hw *hw)
 		}
 	}
 
+	if (gate->flags & TEGRA_PERIPH_WAR_1005168) {
+		writel_relaxed(0, gate->clk_base + LVL2_CLK_GATE_OVRE);
+		writel_relaxed(BIT(22), gate->clk_base + LVL2_CLK_GATE_OVRE);
+		udelay(1);
+		writel_relaxed(0, gate->clk_base + LVL2_CLK_GATE_OVRE);
+	}
+
 	spin_unlock_irqrestore(&periph_ref_lock, flags);
 
 	return 0;
diff --git a/drivers/clk/tegra/clk.h b/drivers/clk/tegra/clk.h
index fd12b77..fb48f04 100644
--- a/drivers/clk/tegra/clk.h
+++ b/drivers/clk/tegra/clk.h
@@ -358,6 +358,7 @@ struct tegra_clk_periph_regs {
  * TEGRA_PERIPH_ON_APB - If peripheral is in the APB bus then read the
  *     bus to flush the write operation in apb bus. This flag indicates
  *     that this peripheral is in apb bus.
+ * TEGRA_PERIPH_WAR_1005168 - Apply workaround for Tegra114 MSENC bug
  */
 struct tegra_clk_periph_gate {
 	u32			magic;
@@ -377,6 +378,7 @@ struct tegra_clk_periph_gate {
 #define TEGRA_PERIPH_NO_RESET BIT(0)
 #define TEGRA_PERIPH_MANUAL_RESET BIT(1)
 #define TEGRA_PERIPH_ON_APB BIT(2)
+#define TEGRA_PERIPH_WAR_1005168 BIT(3)
 
 void tegra_periph_reset(struct tegra_clk_periph_gate *gate, bool assert);
 extern const struct clk_ops tegra_clk_periph_gate_ops;
-- 
1.7.7.rc0.72.g4b5ea.dirty



From rogerq at ti.com  Wed Apr  3 10:53:50 2013
From: rogerq at ti.com (Roger Quadros)
Date: Wed, 3 Apr 2013 17:53:50 +0300
Subject: [PATCH v4 01/21] usb: phy: nop: Add some parameters to platform
 data
In-Reply-To: <20130402172129.GT10155@atomide.com>
References: <1363794300-31526-1-git-send-email-rogerq@ti.com>
 <1363794300-31526-2-git-send-email-rogerq@ti.com>
 <20130320155555.GG1567@arwen.pp.htv.fi> <20130320161324.GL16413@atomide.com>
 <20130320161947.GJ1567@arwen.pp.htv.fi> <20130402172129.GT10155@atomide.com>
Message-ID: <515C427E.4020101@ti.com>

On 04/02/2013 08:21 PM, Tony Lindgren wrote:
> * Felipe Balbi <balbi at ti.com> [130320 09:24]:
>> On Wed, Mar 20, 2013 at 09:13:24AM -0700, Tony Lindgren wrote:
>>> * Felipe Balbi <balbi at ti.com> [130320 09:00]:
>>>> On Wed, Mar 20, 2013 at 05:44:40PM +0200, Roger Quadros wrote:
>>>>> Add clk_rate parameter to platform data. If supplied, the
>>>>> NOP phy driver will program the clock to that rate during probe.
>>>>>
>>>>> Also add 2 flags, needs_vcc and needs_reset.
>>>>> If the flag is set and the regulator couldn't be found
>>>>> then the driver will bail out with -EPROBE_DEFER.
>>>>>
>>>>> Signed-off-by: Roger Quadros <rogerq at ti.com>
>>>>> Acked-by: Felipe Balbi <balbi at ti.com>
>>>>
>>>> Hi Tony,
>>>>
>>>> maybe you might prefer to merge commit 1f0972f from my next branch which
>>>> is exactly this patch. Basically, if you:
>>>>
>>>> $ git fetch git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git next
>>>> $ git merge 1f0972f
>>>>
>>>> you get $SUBJECT and can apply the others without fear of conflicts
>>>> later.
>>>
>>> OK thanks will use commit 1f0972f, so let's consider that commit immutable.
>>
>> yeah, once it hits my 'next' branch, I don't rebase anymore.
> 
> I've applied the board related patchs into omap-for-v3.10/usb that's based
> on commit 1f0972f.

Thanks Tony.

cheers,
-roger


From pdeschrijver at nvidia.com  Wed Apr  3 10:40:45 2013
From: pdeschrijver at nvidia.com (Peter De Schrijver)
Date: Wed, 3 Apr 2013 17:40:45 +0300
Subject: [PATCH v9 11/14] clk: tegra: Implement clocks for Tegra114
In-Reply-To: <1365000110-8916-1-git-send-email-pdeschrijver@nvidia.com>
References: <1365000110-8916-1-git-send-email-pdeschrijver@nvidia.com>
Message-ID: <1365000110-8916-12-git-send-email-pdeschrijver@nvidia.com>

Implement clocks for Tegra114.

Signed-off-by: Peter De Schrijver <pdeschrijver at nvidia.com>
---
 drivers/clk/tegra/Makefile       |    1 +
 drivers/clk/tegra/clk-tegra114.c | 2085 ++++++++++++++++++++++++++++++++++++++
 2 files changed, 2086 insertions(+), 0 deletions(-)
 create mode 100644 drivers/clk/tegra/clk-tegra114.c

diff --git a/drivers/clk/tegra/Makefile b/drivers/clk/tegra/Makefile
index 2b41b0f..f49fac2 100644
--- a/drivers/clk/tegra/Makefile
+++ b/drivers/clk/tegra/Makefile
@@ -9,3 +9,4 @@ obj-y					+= clk-super.o
 
 obj-$(CONFIG_ARCH_TEGRA_2x_SOC)         += clk-tegra20.o
 obj-$(CONFIG_ARCH_TEGRA_3x_SOC)         += clk-tegra30.o
+obj-$(CONFIG_ARCH_TEGRA_114_SOC)	+= clk-tegra114.o
diff --git a/drivers/clk/tegra/clk-tegra114.c b/drivers/clk/tegra/clk-tegra114.c
new file mode 100644
index 0000000..e2a7fa1
--- /dev/null
+++ b/drivers/clk/tegra/clk-tegra114.c
@@ -0,0 +1,2085 @@
+/*
+ * Copyright (c) 2012, 2013, NVIDIA CORPORATION.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <linux/io.h>
+#include <linux/clk.h>
+#include <linux/clk-provider.h>
+#include <linux/clkdev.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/delay.h>
+#include <linux/clk/tegra.h>
+
+#include "clk.h"
+
+#define RST_DEVICES_L			0x004
+#define RST_DEVICES_H			0x008
+#define RST_DEVICES_U			0x00C
+#define RST_DEVICES_V			0x358
+#define RST_DEVICES_W			0x35C
+#define RST_DEVICES_X			0x28C
+#define RST_DEVICES_SET_L		0x300
+#define RST_DEVICES_CLR_L		0x304
+#define RST_DEVICES_SET_H		0x308
+#define RST_DEVICES_CLR_H		0x30c
+#define RST_DEVICES_SET_U		0x310
+#define RST_DEVICES_CLR_U		0x314
+#define RST_DEVICES_SET_V		0x430
+#define RST_DEVICES_CLR_V		0x434
+#define RST_DEVICES_SET_W		0x438
+#define RST_DEVICES_CLR_W		0x43c
+#define RST_DEVICES_NUM			5
+
+#define CLK_OUT_ENB_L			0x010
+#define CLK_OUT_ENB_H			0x014
+#define CLK_OUT_ENB_U			0x018
+#define CLK_OUT_ENB_V			0x360
+#define CLK_OUT_ENB_W			0x364
+#define CLK_OUT_ENB_X			0x280
+#define CLK_OUT_ENB_SET_L		0x320
+#define CLK_OUT_ENB_CLR_L		0x324
+#define CLK_OUT_ENB_SET_H		0x328
+#define CLK_OUT_ENB_CLR_H		0x32c
+#define CLK_OUT_ENB_SET_U		0x330
+#define CLK_OUT_ENB_CLR_U		0x334
+#define CLK_OUT_ENB_SET_V		0x440
+#define CLK_OUT_ENB_CLR_V		0x444
+#define CLK_OUT_ENB_SET_W		0x448
+#define CLK_OUT_ENB_CLR_W		0x44c
+#define CLK_OUT_ENB_SET_X		0x284
+#define CLK_OUT_ENB_CLR_X		0x288
+#define CLK_OUT_ENB_NUM			6
+
+#define PLLC_BASE 0x80
+#define PLLC_MISC2 0x88
+#define PLLC_MISC 0x8c
+#define PLLC2_BASE 0x4e8
+#define PLLC2_MISC 0x4ec
+#define PLLC3_BASE 0x4fc
+#define PLLC3_MISC 0x500
+#define PLLM_BASE 0x90
+#define PLLM_MISC 0x9c
+#define PLLP_BASE 0xa0
+#define PLLP_MISC 0xac
+#define PLLX_BASE 0xe0
+#define PLLX_MISC 0xe4
+#define PLLX_MISC2 0x514
+#define PLLX_MISC3 0x518
+#define PLLD_BASE 0xd0
+#define PLLD_MISC 0xdc
+#define PLLD2_BASE 0x4b8
+#define PLLD2_MISC 0x4bc
+#define PLLE_BASE 0xe8
+#define PLLE_MISC 0xec
+#define PLLA_BASE 0xb0
+#define PLLA_MISC 0xbc
+#define PLLU_BASE 0xc0
+#define PLLU_MISC 0xcc
+#define PLLRE_BASE 0x4c4
+#define PLLRE_MISC 0x4c8
+
+#define PLL_MISC_LOCK_ENABLE 18
+#define PLLC_MISC_LOCK_ENABLE 24
+#define PLLDU_MISC_LOCK_ENABLE 22
+#define PLLE_MISC_LOCK_ENABLE 9
+#define PLLRE_MISC_LOCK_ENABLE 30
+
+#define PLLC_IDDQ_BIT 26
+#define PLLX_IDDQ_BIT 3
+#define PLLRE_IDDQ_BIT 16
+
+#define PLL_BASE_LOCK BIT(27)
+#define PLLE_MISC_LOCK BIT(11)
+#define PLLRE_MISC_LOCK BIT(24)
+#define PLLCX_BASE_LOCK (BIT(26)|BIT(27))
+
+#define PLLE_AUX 0x48c
+#define PLLC_OUT 0x84
+#define PLLM_OUT 0x94
+#define PLLP_OUTA 0xa4
+#define PLLP_OUTB 0xa8
+#define PLLA_OUT 0xb4
+
+#define AUDIO_SYNC_CLK_I2S0 0x4a0
+#define AUDIO_SYNC_CLK_I2S1 0x4a4
+#define AUDIO_SYNC_CLK_I2S2 0x4a8
+#define AUDIO_SYNC_CLK_I2S3 0x4ac
+#define AUDIO_SYNC_CLK_I2S4 0x4b0
+#define AUDIO_SYNC_CLK_SPDIF 0x4b4
+
+#define AUDIO_SYNC_DOUBLER 0x49c
+
+#define PMC_CLK_OUT_CNTRL 0x1a8
+#define PMC_DPD_PADS_ORIDE 0x1c
+#define PMC_DPD_PADS_ORIDE_BLINK_ENB 20
+#define PMC_CTRL 0
+#define PMC_CTRL_BLINK_ENB 7
+
+#define OSC_CTRL			0x50
+#define OSC_CTRL_OSC_FREQ_SHIFT		28
+#define OSC_CTRL_PLL_REF_DIV_SHIFT	26
+
+#define PLLXC_SW_MAX_P			6
+
+#define CCLKG_BURST_POLICY 0x368
+#define CCLKLP_BURST_POLICY 0x370
+#define SCLK_BURST_POLICY 0x028
+#define SYSTEM_CLK_RATE 0x030
+
+#define UTMIP_PLL_CFG2 0x488
+#define UTMIP_PLL_CFG2_STABLE_COUNT(x) (((x) & 0xffff) << 6)
+#define UTMIP_PLL_CFG2_ACTIVE_DLY_COUNT(x) (((x) & 0x3f) << 18)
+#define UTMIP_PLL_CFG2_FORCE_PD_SAMP_A_POWERDOWN BIT(0)
+#define UTMIP_PLL_CFG2_FORCE_PD_SAMP_B_POWERDOWN BIT(2)
+#define UTMIP_PLL_CFG2_FORCE_PD_SAMP_C_POWERDOWN BIT(4)
+
+#define UTMIP_PLL_CFG1 0x484
+#define UTMIP_PLL_CFG1_ENABLE_DLY_COUNT(x) (((x) & 0x1f) << 6)
+#define UTMIP_PLL_CFG1_XTAL_FREQ_COUNT(x) (((x) & 0xfff) << 0)
+#define UTMIP_PLL_CFG1_FORCE_PLLU_POWERUP BIT(17)
+#define UTMIP_PLL_CFG1_FORCE_PLLU_POWERDOWN BIT(16)
+#define UTMIP_PLL_CFG1_FORCE_PLL_ENABLE_POWERUP BIT(15)
+#define UTMIP_PLL_CFG1_FORCE_PLL_ENABLE_POWERDOWN BIT(14)
+#define UTMIP_PLL_CFG1_FORCE_PLL_ACTIVE_POWERDOWN BIT(12)
+
+#define UTMIPLL_HW_PWRDN_CFG0			0x52c
+#define UTMIPLL_HW_PWRDN_CFG0_SEQ_START_STATE	BIT(25)
+#define UTMIPLL_HW_PWRDN_CFG0_SEQ_ENABLE	BIT(24)
+#define UTMIPLL_HW_PWRDN_CFG0_USE_LOCKDET	BIT(6)
+#define UTMIPLL_HW_PWRDN_CFG0_SEQ_RESET_INPUT_VALUE	BIT(5)
+#define UTMIPLL_HW_PWRDN_CFG0_SEQ_IN_SWCTL	BIT(4)
+#define UTMIPLL_HW_PWRDN_CFG0_CLK_ENABLE_SWCTL	BIT(2)
+#define UTMIPLL_HW_PWRDN_CFG0_IDDQ_OVERRIDE	BIT(1)
+#define UTMIPLL_HW_PWRDN_CFG0_IDDQ_SWCTL	BIT(0)
+
+#define CLK_SOURCE_I2S0 0x1d8
+#define CLK_SOURCE_I2S1 0x100
+#define CLK_SOURCE_I2S2 0x104
+#define CLK_SOURCE_NDFLASH 0x160
+#define CLK_SOURCE_I2S3 0x3bc
+#define CLK_SOURCE_I2S4 0x3c0
+#define CLK_SOURCE_SPDIF_OUT 0x108
+#define CLK_SOURCE_SPDIF_IN 0x10c
+#define CLK_SOURCE_PWM 0x110
+#define CLK_SOURCE_ADX 0x638
+#define CLK_SOURCE_AMX 0x63c
+#define CLK_SOURCE_HDA 0x428
+#define CLK_SOURCE_HDA2CODEC_2X 0x3e4
+#define CLK_SOURCE_SBC1 0x134
+#define CLK_SOURCE_SBC2 0x118
+#define CLK_SOURCE_SBC3 0x11c
+#define CLK_SOURCE_SBC4 0x1b4
+#define CLK_SOURCE_SBC5 0x3c8
+#define CLK_SOURCE_SBC6 0x3cc
+#define CLK_SOURCE_SATA_OOB 0x420
+#define CLK_SOURCE_SATA 0x424
+#define CLK_SOURCE_NDSPEED 0x3f8
+#define CLK_SOURCE_VFIR 0x168
+#define CLK_SOURCE_SDMMC1 0x150
+#define CLK_SOURCE_SDMMC2 0x154
+#define CLK_SOURCE_SDMMC3 0x1bc
+#define CLK_SOURCE_SDMMC4 0x164
+#define CLK_SOURCE_VDE 0x1c8
+#define CLK_SOURCE_CSITE 0x1d4
+#define CLK_SOURCE_LA 0x1f8
+#define CLK_SOURCE_TRACE 0x634
+#define CLK_SOURCE_OWR 0x1cc
+#define CLK_SOURCE_NOR 0x1d0
+#define CLK_SOURCE_MIPI 0x174
+#define CLK_SOURCE_I2C1 0x124
+#define CLK_SOURCE_I2C2 0x198
+#define CLK_SOURCE_I2C3 0x1b8
+#define CLK_SOURCE_I2C4 0x3c4
+#define CLK_SOURCE_I2C5 0x128
+#define CLK_SOURCE_UARTA 0x178
+#define CLK_SOURCE_UARTB 0x17c
+#define CLK_SOURCE_UARTC 0x1a0
+#define CLK_SOURCE_UARTD 0x1c0
+#define CLK_SOURCE_UARTE 0x1c4
+#define CLK_SOURCE_UARTA_DBG 0x178
+#define CLK_SOURCE_UARTB_DBG 0x17c
+#define CLK_SOURCE_UARTC_DBG 0x1a0
+#define CLK_SOURCE_UARTD_DBG 0x1c0
+#define CLK_SOURCE_UARTE_DBG 0x1c4
+#define CLK_SOURCE_3D 0x158
+#define CLK_SOURCE_2D 0x15c
+#define CLK_SOURCE_VI_SENSOR 0x1a8
+#define CLK_SOURCE_VI 0x148
+#define CLK_SOURCE_EPP 0x16c
+#define CLK_SOURCE_MSENC 0x1f0
+#define CLK_SOURCE_TSEC 0x1f4
+#define CLK_SOURCE_HOST1X 0x180
+#define CLK_SOURCE_HDMI 0x18c
+#define CLK_SOURCE_DISP1 0x138
+#define CLK_SOURCE_DISP2 0x13c
+#define CLK_SOURCE_CILAB 0x614
+#define CLK_SOURCE_CILCD 0x618
+#define CLK_SOURCE_CILE 0x61c
+#define CLK_SOURCE_DSIALP 0x620
+#define CLK_SOURCE_DSIBLP 0x624
+#define CLK_SOURCE_TSENSOR 0x3b8
+#define CLK_SOURCE_D_AUDIO 0x3d0
+#define CLK_SOURCE_DAM0 0x3d8
+#define CLK_SOURCE_DAM1 0x3dc
+#define CLK_SOURCE_DAM2 0x3e0
+#define CLK_SOURCE_ACTMON 0x3e8
+#define CLK_SOURCE_EXTERN1 0x3ec
+#define CLK_SOURCE_EXTERN2 0x3f0
+#define CLK_SOURCE_EXTERN3 0x3f4
+#define CLK_SOURCE_I2CSLOW 0x3fc
+#define CLK_SOURCE_SE 0x42c
+#define CLK_SOURCE_MSELECT 0x3b4
+#define CLK_SOURCE_SOC_THERM 0x644
+#define CLK_SOURCE_XUSB_HOST_SRC 0x600
+#define CLK_SOURCE_XUSB_FALCON_SRC 0x604
+#define CLK_SOURCE_XUSB_FS_SRC 0x608
+#define CLK_SOURCE_XUSB_SS_SRC 0x610
+#define CLK_SOURCE_XUSB_DEV_SRC 0x60c
+#define CLK_SOURCE_EMC 0x19c
+
+static int periph_clk_enb_refcnt[CLK_OUT_ENB_NUM * 32];
+
+static void __iomem *clk_base;
+static void __iomem *pmc_base;
+
+static DEFINE_SPINLOCK(pll_d_lock);
+static DEFINE_SPINLOCK(pll_d2_lock);
+static DEFINE_SPINLOCK(pll_u_lock);
+static DEFINE_SPINLOCK(pll_div_lock);
+static DEFINE_SPINLOCK(pll_re_lock);
+static DEFINE_SPINLOCK(clk_doubler_lock);
+static DEFINE_SPINLOCK(clk_out_lock);
+static DEFINE_SPINLOCK(sysrate_lock);
+
+static struct pdiv_map pllxc_p[] = {
+	{ .pdiv = 1, .hw_val = 0 },
+	{ .pdiv = 2, .hw_val = 1 },
+	{ .pdiv = 3, .hw_val = 2 },
+	{ .pdiv = 4, .hw_val = 3 },
+	{ .pdiv = 5, .hw_val = 4 },
+	{ .pdiv = 6, .hw_val = 5 },
+	{ .pdiv = 8, .hw_val = 6 },
+	{ .pdiv = 10, .hw_val = 7 },
+	{ .pdiv = 12, .hw_val = 8 },
+	{ .pdiv = 16, .hw_val = 9 },
+	{ .pdiv = 12, .hw_val = 10 },
+	{ .pdiv = 16, .hw_val = 11 },
+	{ .pdiv = 20, .hw_val = 12 },
+	{ .pdiv = 24, .hw_val = 13 },
+	{ .pdiv = 32, .hw_val = 14 },
+	{ .pdiv = 0, .hw_val = 0 },
+};
+
+static struct tegra_clk_pll_freq_table pll_c_freq_table[] = {
+	{ 12000000, 624000000, 104, 0, 2},
+	{ 12000000, 600000000, 100, 0, 2},
+	{ 13000000, 600000000,  92, 0, 2},	/* actual: 598.0 MHz */
+	{ 16800000, 600000000,  71, 0, 2},	/* actual: 596.4 MHz */
+	{ 19200000, 600000000,  62, 0, 2},	/* actual: 595.2 MHz */
+	{ 26000000, 600000000,  92, 1, 2},	/* actual: 598.0 MHz */
+	{ 0, 0, 0, 0, 0, 0 },
+};
+
+static struct tegra_clk_pll_params pll_c_params = {
+	.input_min = 12000000,
+	.input_max = 800000000,
+	.cf_min = 12000000,
+	.cf_max = 19200000,	/* s/w policy, h/w capability 50 MHz */
+	.vco_min = 600000000,
+	.vco_max = 1400000000,
+	.base_reg = PLLC_BASE,
+	.misc_reg = PLLC_MISC,
+	.lock_mask = PLL_BASE_LOCK,
+	.lock_enable_bit_idx = PLLC_MISC_LOCK_ENABLE,
+	.lock_delay = 300,
+	.iddq_reg = PLLC_MISC,
+	.iddq_bit_idx = PLLC_IDDQ_BIT,
+	.max_p = PLLXC_SW_MAX_P,
+	.dyn_ramp_reg = PLLC_MISC2,
+	.stepa_shift = 17,
+	.stepb_shift = 9,
+	.pdiv_tohw = pllxc_p,
+};
+
+static struct pdiv_map pllc_p[] = {
+	{ .pdiv = 1, .hw_val = 0 },
+	{ .pdiv = 2, .hw_val = 1 },
+	{ .pdiv = 4, .hw_val = 3 },
+	{ .pdiv = 8, .hw_val = 5 },
+	{ .pdiv = 16, .hw_val = 7 },
+	{ .pdiv = 0, .hw_val = 0 },
+};
+
+static struct tegra_clk_pll_freq_table pll_cx_freq_table[] = {
+	{12000000, 600000000, 100, 0, 2},
+	{13000000, 600000000, 92, 0, 2},	/* actual: 598.0 MHz */
+	{16800000, 600000000, 71, 0, 2},	/* actual: 596.4 MHz */
+	{19200000, 600000000, 62, 0, 2},	/* actual: 595.2 MHz */
+	{26000000, 600000000, 92, 1, 2},	/* actual: 598.0 MHz */
+	{0, 0, 0, 0, 0, 0},
+};
+
+static struct tegra_clk_pll_params pll_c2_params = {
+	.input_min = 12000000,
+	.input_max = 48000000,
+	.cf_min = 12000000,
+	.cf_max = 19200000,
+	.vco_min = 600000000,
+	.vco_max = 1200000000,
+	.base_reg = PLLC2_BASE,
+	.misc_reg = PLLC2_MISC,
+	.lock_mask = PLL_BASE_LOCK,
+	.lock_enable_bit_idx = PLL_MISC_LOCK_ENABLE,
+	.lock_delay = 300,
+	.pdiv_tohw = pllc_p,
+	.ext_misc_reg[0] = 0x4f0,
+	.ext_misc_reg[1] = 0x4f4,
+	.ext_misc_reg[2] = 0x4f8,
+};
+
+static struct tegra_clk_pll_params pll_c3_params = {
+	.input_min = 12000000,
+	.input_max = 48000000,
+	.cf_min = 12000000,
+	.cf_max = 19200000,
+	.vco_min = 600000000,
+	.vco_max = 1200000000,
+	.base_reg = PLLC3_BASE,
+	.misc_reg = PLLC3_MISC,
+	.lock_mask = PLL_BASE_LOCK,
+	.lock_enable_bit_idx = PLL_MISC_LOCK_ENABLE,
+	.lock_delay = 300,
+	.pdiv_tohw = pllc_p,
+	.ext_misc_reg[0] = 0x504,
+	.ext_misc_reg[1] = 0x508,
+	.ext_misc_reg[2] = 0x50c,
+};
+
+static struct pdiv_map pllm_p[] = {
+	{ .pdiv = 1, .hw_val = 0 },
+	{ .pdiv = 2, .hw_val = 1 },
+	{ .pdiv = 0, .hw_val = 0 },
+};
+
+static struct tegra_clk_pll_freq_table pll_m_freq_table[] = {
+	{12000000, 800000000, 66, 0, 1},	/* actual: 792.0 MHz */
+	{13000000, 800000000, 61, 0, 1},	/* actual: 793.0 MHz */
+	{16800000, 800000000, 47, 0, 1},	/* actual: 789.6 MHz */
+	{19200000, 800000000, 41, 0, 1},	/* actual: 787.2 MHz */
+	{26000000, 800000000, 61, 1, 1},	/* actual: 793.0 MHz */
+	{0, 0, 0, 0, 0, 0},
+};
+
+static struct tegra_clk_pll_params pll_m_params = {
+	.input_min = 12000000,
+	.input_max = 500000000,
+	.cf_min = 12000000,
+	.cf_max = 19200000,	/* s/w policy, h/w capability 50 MHz */
+	.vco_min = 400000000,
+	.vco_max = 1066000000,
+	.base_reg = PLLM_BASE,
+	.misc_reg = PLLM_MISC,
+	.lock_mask = PLL_BASE_LOCK,
+	.lock_enable_bit_idx = PLL_MISC_LOCK_ENABLE,
+	.lock_delay = 300,
+	.max_p = 2,
+	.pdiv_tohw = pllm_p,
+};
+
+static struct tegra_clk_pll_freq_table pll_p_freq_table[] = {
+	{12000000, 216000000, 432, 12, 1, 8},
+	{13000000, 216000000, 432, 13, 1, 8},
+	{16800000, 216000000, 360, 14, 1, 8},
+	{19200000, 216000000, 360, 16, 1, 8},
+	{26000000, 216000000, 432, 26, 1, 8},
+	{0, 0, 0, 0, 0, 0},
+};
+
+static struct tegra_clk_pll_params pll_p_params = {
+	.input_min = 2000000,
+	.input_max = 31000000,
+	.cf_min = 1000000,
+	.cf_max = 6000000,
+	.vco_min = 200000000,
+	.vco_max = 700000000,
+	.base_reg = PLLP_BASE,
+	.misc_reg = PLLP_MISC,
+	.lock_mask = PLL_BASE_LOCK,
+	.lock_enable_bit_idx = PLL_MISC_LOCK_ENABLE,
+	.lock_delay = 300,
+};
+
+static struct tegra_clk_pll_freq_table pll_a_freq_table[] = {
+	{9600000, 282240000, 147, 5, 0, 4},
+	{9600000, 368640000, 192, 5, 0, 4},
+	{9600000, 240000000, 200, 8, 0, 8},
+
+	{28800000, 282240000, 245, 25, 0, 8},
+	{28800000, 368640000, 320, 25, 0, 8},
+	{28800000, 240000000, 200, 24, 0, 8},
+	{0, 0, 0, 0, 0, 0},
+};
+
+
+static struct tegra_clk_pll_params pll_a_params = {
+	.input_min = 2000000,
+	.input_max = 31000000,
+	.cf_min = 1000000,
+	.cf_max = 6000000,
+	.vco_min = 200000000,
+	.vco_max = 700000000,
+	.base_reg = PLLA_BASE,
+	.misc_reg = PLLA_MISC,
+	.lock_mask = PLL_BASE_LOCK,
+	.lock_enable_bit_idx = PLL_MISC_LOCK_ENABLE,
+	.lock_delay = 300,
+};
+
+static struct tegra_clk_pll_freq_table pll_d_freq_table[] = {
+	{12000000, 216000000, 864, 12, 2, 12},
+	{13000000, 216000000, 864, 13, 2, 12},
+	{16800000, 216000000, 720, 14, 2, 12},
+	{19200000, 216000000, 720, 16, 2, 12},
+	{26000000, 216000000, 864, 26, 2, 12},
+
+	{12000000, 594000000, 594, 12, 0, 12},
+	{13000000, 594000000, 594, 13, 0, 12},
+	{16800000, 594000000, 495, 14, 0, 12},
+	{19200000, 594000000, 495, 16, 0, 12},
+	{26000000, 594000000, 594, 26, 0, 12},
+
+	{12000000, 1000000000, 1000, 12, 0, 12},
+	{13000000, 1000000000, 1000, 13, 0, 12},
+	{19200000, 1000000000, 625, 12, 0, 12},
+	{26000000, 1000000000, 1000, 26, 0, 12},
+
+	{0, 0, 0, 0, 0, 0},
+};
+
+static struct tegra_clk_pll_params pll_d_params = {
+	.input_min = 2000000,
+	.input_max = 40000000,
+	.cf_min = 1000000,
+	.cf_max = 6000000,
+	.vco_min = 500000000,
+	.vco_max = 1000000000,
+	.base_reg = PLLD_BASE,
+	.misc_reg = PLLD_MISC,
+	.lock_mask = PLL_BASE_LOCK,
+	.lock_enable_bit_idx = PLLDU_MISC_LOCK_ENABLE,
+	.lock_delay = 1000,
+};
+
+static struct tegra_clk_pll_params pll_d2_params = {
+	.input_min = 2000000,
+	.input_max = 40000000,
+	.cf_min = 1000000,
+	.cf_max = 6000000,
+	.vco_min = 500000000,
+	.vco_max = 1000000000,
+	.base_reg = PLLD2_BASE,
+	.misc_reg = PLLD2_MISC,
+	.lock_mask = PLL_BASE_LOCK,
+	.lock_enable_bit_idx = PLLDU_MISC_LOCK_ENABLE,
+	.lock_delay = 1000,
+};
+
+static struct pdiv_map pllu_p[] = {
+	{ .pdiv = 1, .hw_val = 1 },
+	{ .pdiv = 2, .hw_val = 0 },
+	{ .pdiv = 0, .hw_val = 0 },
+};
+
+static struct tegra_clk_pll_freq_table pll_u_freq_table[] = {
+	{12000000, 480000000, 960, 12, 0, 12},
+	{13000000, 480000000, 960, 13, 0, 12},
+	{16800000, 480000000, 400, 7, 0, 5},
+	{19200000, 480000000, 200, 4, 0, 3},
+	{26000000, 480000000, 960, 26, 0, 12},
+	{0, 0, 0, 0, 0, 0},
+};
+
+static struct tegra_clk_pll_params pll_u_params = {
+	.input_min = 2000000,
+	.input_max = 40000000,
+	.cf_min = 1000000,
+	.cf_max = 6000000,
+	.vco_min = 480000000,
+	.vco_max = 960000000,
+	.base_reg = PLLU_BASE,
+	.misc_reg = PLLU_MISC,
+	.lock_mask = PLL_BASE_LOCK,
+	.lock_enable_bit_idx = PLLDU_MISC_LOCK_ENABLE,
+	.lock_delay = 1000,
+	.pdiv_tohw = pllu_p,
+};
+
+static struct tegra_clk_pll_freq_table pll_x_freq_table[] = {
+	/* 1 GHz */
+	{12000000, 1000000000, 83, 0, 1},	/* actual: 996.0 MHz */
+	{13000000, 1000000000, 76, 0, 1},	/* actual: 988.0 MHz */
+	{16800000, 1000000000, 59, 0, 1},	/* actual: 991.2 MHz */
+	{19200000, 1000000000, 52, 0, 1},	/* actual: 998.4 MHz */
+	{26000000, 1000000000, 76, 1, 1},	/* actual: 988.0 MHz */
+
+	{0, 0, 0, 0, 0, 0},
+};
+
+static struct tegra_clk_pll_params pll_x_params = {
+	.input_min = 12000000,
+	.input_max = 800000000,
+	.cf_min = 12000000,
+	.cf_max = 19200000,	/* s/w policy, h/w capability 50 MHz */
+	.vco_min = 700000000,
+	.vco_max = 2400000000U,
+	.base_reg = PLLX_BASE,
+	.misc_reg = PLLX_MISC,
+	.lock_mask = PLL_BASE_LOCK,
+	.lock_enable_bit_idx = PLL_MISC_LOCK_ENABLE,
+	.lock_delay = 300,
+	.iddq_reg = PLLX_MISC3,
+	.iddq_bit_idx = PLLX_IDDQ_BIT,
+	.max_p = PLLXC_SW_MAX_P,
+	.dyn_ramp_reg = PLLX_MISC2,
+	.stepa_shift = 16,
+	.stepb_shift = 24,
+	.pdiv_tohw = pllxc_p,
+};
+
+static struct tegra_clk_pll_freq_table pll_e_freq_table[] = {
+	/* PLLE special case: use cpcon field to store cml divider value */
+	{336000000, 100000000, 100, 21, 16, 11},
+	{312000000, 100000000, 200, 26, 24, 13},
+	{0, 0, 0, 0, 0, 0},
+};
+
+static struct tegra_clk_pll_params pll_e_params = {
+	.input_min = 12000000,
+	.input_max = 1000000000,
+	.cf_min = 12000000,
+	.cf_max = 75000000,
+	.vco_min = 1600000000,
+	.vco_max = 2400000000U,
+	.base_reg = PLLE_BASE,
+	.misc_reg = PLLE_MISC,
+	.aux_reg = PLLE_AUX,
+	.lock_mask = PLLE_MISC_LOCK,
+	.lock_enable_bit_idx = PLLE_MISC_LOCK_ENABLE,
+	.lock_delay = 300,
+};
+
+static struct tegra_clk_pll_params pll_re_vco_params = {
+	.input_min = 12000000,
+	.input_max = 1000000000,
+	.cf_min = 12000000,
+	.cf_max = 19200000, /* s/w policy, h/w capability 38 MHz */
+	.vco_min = 300000000,
+	.vco_max = 600000000,
+	.base_reg = PLLRE_BASE,
+	.misc_reg = PLLRE_MISC,
+	.lock_mask = PLLRE_MISC_LOCK,
+	.lock_enable_bit_idx = PLLRE_MISC_LOCK_ENABLE,
+	.lock_delay = 300,
+	.iddq_reg = PLLRE_MISC,
+	.iddq_bit_idx = PLLRE_IDDQ_BIT,
+};
+
+/* Peripheral clock registers */
+
+static struct tegra_clk_periph_regs periph_l_regs = {
+	.enb_reg = CLK_OUT_ENB_L,
+	.enb_set_reg = CLK_OUT_ENB_SET_L,
+	.enb_clr_reg = CLK_OUT_ENB_CLR_L,
+	.rst_reg = RST_DEVICES_L,
+	.rst_set_reg = RST_DEVICES_SET_L,
+	.rst_clr_reg = RST_DEVICES_CLR_L,
+};
+
+static struct tegra_clk_periph_regs periph_h_regs = {
+	.enb_reg = CLK_OUT_ENB_H,
+	.enb_set_reg = CLK_OUT_ENB_SET_H,
+	.enb_clr_reg = CLK_OUT_ENB_CLR_H,
+	.rst_reg = RST_DEVICES_H,
+	.rst_set_reg = RST_DEVICES_SET_H,
+	.rst_clr_reg = RST_DEVICES_CLR_H,
+};
+
+static struct tegra_clk_periph_regs periph_u_regs = {
+	.enb_reg = CLK_OUT_ENB_U,
+	.enb_set_reg = CLK_OUT_ENB_SET_U,
+	.enb_clr_reg = CLK_OUT_ENB_CLR_U,
+	.rst_reg = RST_DEVICES_U,
+	.rst_set_reg = RST_DEVICES_SET_U,
+	.rst_clr_reg = RST_DEVICES_CLR_U,
+};
+
+static struct tegra_clk_periph_regs periph_v_regs = {
+	.enb_reg = CLK_OUT_ENB_V,
+	.enb_set_reg = CLK_OUT_ENB_SET_V,
+	.enb_clr_reg = CLK_OUT_ENB_CLR_V,
+	.rst_reg = RST_DEVICES_V,
+	.rst_set_reg = RST_DEVICES_SET_V,
+	.rst_clr_reg = RST_DEVICES_CLR_V,
+};
+
+static struct tegra_clk_periph_regs periph_w_regs = {
+	.enb_reg = CLK_OUT_ENB_W,
+	.enb_set_reg = CLK_OUT_ENB_SET_W,
+	.enb_clr_reg = CLK_OUT_ENB_CLR_W,
+	.rst_reg = RST_DEVICES_W,
+	.rst_set_reg = RST_DEVICES_SET_W,
+	.rst_clr_reg = RST_DEVICES_CLR_W,
+};
+
+/* possible OSC frequencies in Hz */
+static unsigned long tegra114_input_freq[] = {
+	[0] = 13000000,
+	[1] = 16800000,
+	[4] = 19200000,
+	[5] = 38400000,
+	[8] = 12000000,
+	[9] = 48000000,
+	[12] = 260000000,
+};
+
+#define MASK(x) (BIT(x) - 1)
+
+#define TEGRA_INIT_DATA_MUX(_name, _con_id, _dev_id, _parents, _offset,	\
+			    _clk_num, _regs, _gate_flags, _clk_id)	\
+	TEGRA_INIT_DATA_TABLE(_name, _con_id, _dev_id, _parents, _offset,\
+			30, MASK(2), 0, 0, 8, 1, 0, _regs, _clk_num,	\
+			periph_clk_enb_refcnt, _gate_flags, _clk_id,	\
+			_parents##_idx, 0)
+
+#define TEGRA_INIT_DATA_MUX_FLAGS(_name, _con_id, _dev_id, _parents, _offset,\
+			    _clk_num, _regs, _gate_flags, _clk_id, flags)\
+	TEGRA_INIT_DATA_TABLE(_name, _con_id, _dev_id, _parents, _offset,\
+			30, MASK(2), 0, 0, 8, 1, 0, _regs, _clk_num,	\
+			periph_clk_enb_refcnt, _gate_flags, _clk_id,	\
+			_parents##_idx, flags)
+
+#define TEGRA_INIT_DATA_MUX8(_name, _con_id, _dev_id, _parents, _offset, \
+			     _clk_num, _regs, _gate_flags, _clk_id)	\
+	TEGRA_INIT_DATA_TABLE(_name, _con_id, _dev_id, _parents, _offset,\
+			29, MASK(3), 0, 0, 8, 1, 0, _regs, _clk_num,	\
+			periph_clk_enb_refcnt, _gate_flags, _clk_id,	\
+			_parents##_idx, 0)
+
+#define TEGRA_INIT_DATA_INT(_name, _con_id, _dev_id, _parents, _offset,	\
+			    _clk_num, _regs, _gate_flags, _clk_id)	\
+	TEGRA_INIT_DATA_TABLE(_name, _con_id, _dev_id, _parents, _offset,\
+			30, MASK(2), 0, 0, 8, 1, TEGRA_DIVIDER_INT, _regs,\
+			_clk_num, periph_clk_enb_refcnt, _gate_flags,	\
+			_clk_id, _parents##_idx, 0)
+
+#define TEGRA_INIT_DATA_INT_FLAGS(_name, _con_id, _dev_id, _parents, _offset,\
+			    _clk_num, _regs, _gate_flags, _clk_id, flags)\
+	TEGRA_INIT_DATA_TABLE(_name, _con_id, _dev_id, _parents, _offset,\
+			30, MASK(2), 0, 0, 8, 1, TEGRA_DIVIDER_INT, _regs,\
+			_clk_num, periph_clk_enb_refcnt, _gate_flags,	\
+			_clk_id, _parents##_idx, flags)
+
+#define TEGRA_INIT_DATA_INT8(_name, _con_id, _dev_id, _parents, _offset,\
+			    _clk_num, _regs, _gate_flags, _clk_id)	\
+	TEGRA_INIT_DATA_TABLE(_name, _con_id, _dev_id, _parents, _offset,\
+			29, MASK(3), 0, 0, 8, 1, TEGRA_DIVIDER_INT, _regs,\
+			_clk_num, periph_clk_enb_refcnt, _gate_flags,	\
+			_clk_id, _parents##_idx, 0)
+
+#define TEGRA_INIT_DATA_UART(_name, _con_id, _dev_id, _parents, _offset,\
+			     _clk_num, _regs, _clk_id)			\
+	TEGRA_INIT_DATA_TABLE(_name, _con_id, _dev_id, _parents, _offset,\
+			30, MASK(2), 0, 0, 16, 1, TEGRA_DIVIDER_UART, _regs,\
+			_clk_num, periph_clk_enb_refcnt, 0, _clk_id,	\
+			_parents##_idx, 0)
+
+#define TEGRA_INIT_DATA_I2C(_name, _con_id, _dev_id, _parents, _offset,\
+			     _clk_num, _regs, _clk_id)			\
+	TEGRA_INIT_DATA_TABLE(_name, _con_id, _dev_id, _parents, _offset,\
+			30, MASK(2), 0, 0, 16, 0, 0, _regs, _clk_num,	\
+			periph_clk_enb_refcnt, 0, _clk_id, _parents##_idx, 0)
+
+#define TEGRA_INIT_DATA_NODIV(_name, _con_id, _dev_id, _parents, _offset, \
+			      _mux_shift, _mux_mask, _clk_num, _regs,	\
+			      _gate_flags, _clk_id)			\
+	TEGRA_INIT_DATA_TABLE(_name, _con_id, _dev_id, _parents, _offset,\
+			_mux_shift, _mux_mask, 0, 0, 0, 0, 0, _regs,	\
+			_clk_num, periph_clk_enb_refcnt, _gate_flags,	\
+			_clk_id, _parents##_idx, 0)
+
+#define TEGRA_INIT_DATA_XUSB(_name, _con_id, _dev_id, _parents, _offset, \
+			     _clk_num, _regs, _gate_flags, _clk_id)	 \
+	TEGRA_INIT_DATA_TABLE(_name, _con_id, _dev_id, _parents, _offset, \
+			29, MASK(3), 0, 0, 8, 1, TEGRA_DIVIDER_INT, _regs, \
+			_clk_num, periph_clk_enb_refcnt, _gate_flags,	 \
+			_clk_id, _parents##_idx, 0)
+
+#define TEGRA_INIT_DATA_AUDIO(_name, _con_id, _dev_id, _offset,  _clk_num,\
+				 _regs, _gate_flags, _clk_id)		\
+	TEGRA_INIT_DATA_TABLE(_name, _con_id, _dev_id, mux_d_audio_clk,	\
+			_offset, 16, 0xE01F, 0, 0, 8, 1, 0, _regs, _clk_num, \
+			periph_clk_enb_refcnt, _gate_flags , _clk_id,	\
+			mux_d_audio_clk_idx, 0)
+
+enum tegra114_clk {
+	rtc = 4, timer = 5, uarta = 6, sdmmc2 = 9, i2s1 = 11, i2c1 = 12,
+	ndflash = 13, sdmmc1 = 14, sdmmc4 = 15, pwm = 17, i2s2 = 18, epp = 19,
+	gr_2d = 21, usbd = 22, isp = 23, gr_3d = 24, disp2 = 26, disp1 = 27,
+	host1x = 28, vcp = 29, i2s0 = 30, apbdma = 34, kbc = 36, kfuse = 40,
+	sbc1 = 41, nor = 42, sbc2 = 44, sbc3 = 46, i2c5 = 47, dsia = 48,
+	mipi = 50, hdmi = 51, csi = 52, i2c2 = 54, uartc = 55, mipi_cal = 56,
+	emc, usb2, usb3, vde = 61, bsea = 62, bsev = 63, uartd = 65,
+	i2c3 = 67, sbc4 = 68, sdmmc3 = 69, owr = 71, csite = 73,
+	la = 76, trace = 77, soc_therm = 78, dtv = 79, ndspeed = 80,
+	i2cslow = 81, dsib = 82, tsec = 83, xusb_host = 89, msenc = 91,
+	csus = 92, mselect = 99, tsensor = 100, i2s3 = 101, i2s4 = 102,
+	i2c4 = 103, sbc5 = 104, sbc6 = 105, d_audio, apbif = 107, dam0, dam1,
+	dam2, hda2codec_2x = 111, audio0_2x = 113, audio1_2x, audio2_2x,
+	audio3_2x, audio4_2x, spdif_2x, actmon = 119, extern1 = 120,
+	extern2 = 121, extern3 = 122, hda = 125, se = 127, hda2hdmi = 128,
+	cilab = 144, cilcd = 145, cile = 146, dsialp = 147, dsiblp = 148,
+	dds = 150, dp2 = 152, amx = 153, adx = 154, xusb_ss = 156, uartb = 192,
+	vfir, spdif_in, spdif_out, vi, vi_sensor, fuse, fuse_burn, clk_32k,
+	clk_m, clk_m_div2, clk_m_div4, pll_ref, pll_c, pll_c_out1, pll_c2,
+	pll_c3, pll_m, pll_m_out1, pll_p, pll_p_out1, pll_p_out2, pll_p_out3,
+	pll_p_out4, pll_a, pll_a_out0, pll_d, pll_d_out0, pll_d2, pll_d2_out0,
+	pll_u, pll_u_480M, pll_u_60M, pll_u_48M, pll_u_12M, pll_x, pll_x_out0,
+	pll_re_vco, pll_re_out, pll_e_out0, spdif_in_sync, i2s0_sync,
+	i2s1_sync, i2s2_sync, i2s3_sync, i2s4_sync, vimclk_sync, audio0,
+	audio1, audio2, audio3, audio4, spdif, clk_out_1, clk_out_2, clk_out_3,
+	blink, xusb_host_src, xusb_falcon_src, xusb_fs_src, xusb_ss_src,
+	xusb_dev_src, xusb_dev, xusb_hs_src, sclk, hclk, pclk, cclk_g, cclk_lp,
+
+	/* Mux clocks */
+
+	audio0_mux = 300, audio1_mux, audio2_mux, audio3_mux, audio4_mux,
+	spdif_mux, clk_out_1_mux, clk_out_2_mux, clk_out_3_mux, dsia_mux,
+	dsib_mux, clk_max,
+};
+
+struct utmi_clk_param {
+	/* Oscillator Frequency in KHz */
+	u32 osc_frequency;
+	/* UTMIP PLL Enable Delay Count  */
+	u8 enable_delay_count;
+	/* UTMIP PLL Stable count */
+	u8 stable_count;
+	/*  UTMIP PLL Active delay count */
+	u8 active_delay_count;
+	/* UTMIP PLL Xtal frequency count */
+	u8 xtal_freq_count;
+};
+
+static const struct utmi_clk_param utmi_parameters[] = {
+	{.osc_frequency = 13000000, .enable_delay_count = 0x02,
+	 .stable_count = 0x33, .active_delay_count = 0x05,
+	 .xtal_freq_count = 0x7F},
+	{.osc_frequency = 19200000, .enable_delay_count = 0x03,
+	 .stable_count = 0x4B, .active_delay_count = 0x06,
+	 .xtal_freq_count = 0xBB},
+	{.osc_frequency = 12000000, .enable_delay_count = 0x02,
+	 .stable_count = 0x2F, .active_delay_count = 0x04,
+	 .xtal_freq_count = 0x76},
+	{.osc_frequency = 26000000, .enable_delay_count = 0x04,
+	 .stable_count = 0x66, .active_delay_count = 0x09,
+	 .xtal_freq_count = 0xFE},
+	{.osc_frequency = 16800000, .enable_delay_count = 0x03,
+	 .stable_count = 0x41, .active_delay_count = 0x0A,
+	 .xtal_freq_count = 0xA4},
+};
+
+/* peripheral mux definitions */
+
+#define MUX_I2S_SPDIF(_id)						\
+static const char *mux_pllaout0_##_id##_2x_pllp_clkm[] = { "pll_a_out0", \
+							   #_id, "pll_p",\
+							   "clk_m"};
+MUX_I2S_SPDIF(audio0)
+MUX_I2S_SPDIF(audio1)
+MUX_I2S_SPDIF(audio2)
+MUX_I2S_SPDIF(audio3)
+MUX_I2S_SPDIF(audio4)
+MUX_I2S_SPDIF(audio)
+
+#define mux_pllaout0_audio0_2x_pllp_clkm_idx NULL
+#define mux_pllaout0_audio1_2x_pllp_clkm_idx NULL
+#define mux_pllaout0_audio2_2x_pllp_clkm_idx NULL
+#define mux_pllaout0_audio3_2x_pllp_clkm_idx NULL
+#define mux_pllaout0_audio4_2x_pllp_clkm_idx NULL
+#define mux_pllaout0_audio_2x_pllp_clkm_idx NULL
+
+static const char *mux_pllp_pllc_pllm_clkm[] = {
+	"pll_p", "pll_c", "pll_m", "clk_m"
+};
+#define mux_pllp_pllc_pllm_clkm_idx NULL
+
+static const char *mux_pllp_pllc_pllm[] = { "pll_p", "pll_c", "pll_m" };
+#define mux_pllp_pllc_pllm_idx NULL
+
+static const char *mux_pllp_pllc_clk32_clkm[] = {
+	"pll_p", "pll_c", "clk_32k", "clk_m"
+};
+#define mux_pllp_pllc_clk32_clkm_idx NULL
+
+static const char *mux_plla_pllc_pllp_clkm[] = {
+	"pll_a_out0", "pll_c", "pll_p", "clk_m"
+};
+#define mux_plla_pllc_pllp_clkm_idx mux_pllp_pllc_pllm_clkm_idx
+
+static const char *mux_pllp_pllc2_c_c3_pllm_clkm[] = {
+	"pll_p", "pll_c2", "pll_c", "pll_c3", "pll_m", "clk_m"
+};
+static u32 mux_pllp_pllc2_c_c3_pllm_clkm_idx[] = {
+	[0] = 0, [1] = 1, [2] = 2, [3] = 3, [4] = 4, [5] = 6,
+};
+
+static const char *mux_pllp_clkm[] = {
+	"pll_p", "clk_m"
+};
+static u32 mux_pllp_clkm_idx[] = {
+	[0] = 0, [1] = 3,
+};
+
+static const char *mux_pllm_pllc2_c_c3_pllp_plla[] = {
+	"pll_m", "pll_c2", "pll_c", "pll_c3", "pll_p", "pll_a_out0"
+};
+#define mux_pllm_pllc2_c_c3_pllp_plla_idx mux_pllp_pllc2_c_c3_pllm_clkm_idx
+
+static const char *mux_pllp_pllm_plld_plla_pllc_plld2_clkm[] = {
+	"pll_p", "pll_m", "pll_d_out0", "pll_a_out0", "pll_c",
+	"pll_d2_out0", "clk_m"
+};
+#define mux_pllp_pllm_plld_plla_pllc_plld2_clkm_idx NULL
+
+static const char *mux_pllm_pllc_pllp_plla[] = {
+	"pll_m", "pll_c", "pll_p", "pll_a_out0"
+};
+#define mux_pllm_pllc_pllp_plla_idx mux_pllp_pllc_pllm_clkm_idx
+
+static const char *mux_pllp_pllc_clkm[] = {
+	"pll_p", "pll_c", "pll_m"
+};
+static u32 mux_pllp_pllc_clkm_idx[] = {
+	[0] = 0, [1] = 1, [2] = 3,
+};
+
+static const char *mux_pllp_pllc_clkm_clk32[] = {
+	"pll_p", "pll_c", "clk_m", "clk_32k"
+};
+#define mux_pllp_pllc_clkm_clk32_idx NULL
+
+static const char *mux_plla_clk32_pllp_clkm_plle[] = {
+	"pll_a_out0", "clk_32k", "pll_p", "clk_m", "pll_e_out0"
+};
+#define mux_plla_clk32_pllp_clkm_plle_idx NULL
+
+static const char *mux_clkm_pllp_pllc_pllre[] = {
+	"clk_m", "pll_p", "pll_c", "pll_re_out"
+};
+static u32 mux_clkm_pllp_pllc_pllre_idx[] = {
+	[0] = 0, [1] = 1, [2] = 3, [3] = 5,
+};
+
+static const char *mux_clkm_48M_pllp_480M[] = {
+	"clk_m", "pll_u_48M", "pll_p", "pll_u_480M"
+};
+#define mux_clkm_48M_pllp_480M_idx NULL
+
+static const char *mux_clkm_pllre_clk32_480M_pllc_ref[] = {
+	"clk_m", "pll_re_out", "clk_32k", "pll_u_480M", "pll_c", "pll_ref"
+};
+static u32 mux_clkm_pllre_clk32_480M_pllc_ref_idx[] = {
+	[0] = 0, [1] = 1, [2] = 3, [3] = 3, [4] = 4, [5] = 7,
+};
+
+static const char *mux_plld_out0_plld2_out0[] = {
+	"pll_d_out0", "pll_d2_out0",
+};
+#define mux_plld_out0_plld2_out0_idx NULL
+
+static const char *mux_d_audio_clk[] = {
+	"pll_a_out0", "pll_p", "clk_m", "spdif_in_sync", "i2s0_sync",
+	"i2s1_sync", "i2s2_sync", "i2s3_sync", "i2s4_sync", "vimclk_sync",
+};
+static u32 mux_d_audio_clk_idx[] = {
+	[0] = 0, [1] = 0x8000, [2] = 0xc000, [3] = 0xE000, [4] = 0xE001,
+	[5] = 0xE002, [6] = 0xE003, [7] = 0xE004, [8] = 0xE005, [9] = 0xE007,
+};
+
+static const char *mux_pllmcp_clkm[] = {
+	"pll_m_out0", "pll_c_out0", "pll_p_out0", "clk_m", "pll_m_ud",
+};
+
+static const struct clk_div_table pll_re_div_table[] = {
+	{ .val = 0, .div = 1 },
+	{ .val = 1, .div = 2 },
+	{ .val = 2, .div = 3 },
+	{ .val = 3, .div = 4 },
+	{ .val = 4, .div = 5 },
+	{ .val = 5, .div = 6 },
+	{ .val = 0, .div = 0 },
+};
+
+static struct clk *clks[clk_max];
+static struct clk_onecell_data clk_data;
+
+static unsigned long osc_freq;
+static unsigned long pll_ref_freq;
+
+static int __init tegra114_osc_clk_init(void __iomem *clk_base)
+{
+	struct clk *clk;
+	u32 val, pll_ref_div;
+
+	val = readl_relaxed(clk_base + OSC_CTRL);
+
+	osc_freq = tegra114_input_freq[val >> OSC_CTRL_OSC_FREQ_SHIFT];
+	if (!osc_freq) {
+		WARN_ON(1);
+		return -EINVAL;
+	}
+
+	/* clk_m */
+	clk = clk_register_fixed_rate(NULL, "clk_m", NULL, CLK_IS_ROOT,
+				      osc_freq);
+	clk_register_clkdev(clk, "clk_m", NULL);
+	clks[clk_m] = clk;
+
+	/* pll_ref */
+	val = (val >> OSC_CTRL_PLL_REF_DIV_SHIFT) & 3;
+	pll_ref_div = 1 << val;
+	clk = clk_register_fixed_factor(NULL, "pll_ref", "clk_m",
+					CLK_SET_RATE_PARENT, 1, pll_ref_div);
+	clk_register_clkdev(clk, "pll_ref", NULL);
+	clks[pll_ref] = clk;
+
+	pll_ref_freq = osc_freq / pll_ref_div;
+
+	return 0;
+}
+
+static void __init tegra114_fixed_clk_init(void __iomem *clk_base)
+{
+	struct clk *clk;
+
+	/* clk_32k */
+	clk = clk_register_fixed_rate(NULL, "clk_32k", NULL, CLK_IS_ROOT,
+				      32768);
+	clk_register_clkdev(clk, "clk_32k", NULL);
+	clks[clk_32k] = clk;
+
+	/* clk_m_div2 */
+	clk = clk_register_fixed_factor(NULL, "clk_m_div2", "clk_m",
+					CLK_SET_RATE_PARENT, 1, 2);
+	clk_register_clkdev(clk, "clk_m_div2", NULL);
+	clks[clk_m_div2] = clk;
+
+	/* clk_m_div4 */
+	clk = clk_register_fixed_factor(NULL, "clk_m_div4", "clk_m",
+					CLK_SET_RATE_PARENT, 1, 4);
+	clk_register_clkdev(clk, "clk_m_div4", NULL);
+	clks[clk_m_div4] = clk;
+
+}
+
+static __init void tegra114_utmi_param_configure(void __iomem *clk_base)
+{
+	u32 reg;
+	int i;
+
+	for (i = 0; i < ARRAY_SIZE(utmi_parameters); i++) {
+		if (osc_freq == utmi_parameters[i].osc_frequency)
+			break;
+	}
+
+	if (i >= ARRAY_SIZE(utmi_parameters)) {
+		pr_err("%s: Unexpected oscillator freq %lu\n", __func__,
+		       osc_freq);
+		return;
+	}
+
+	reg = readl_relaxed(clk_base + UTMIP_PLL_CFG2);
+
+	/* Program UTMIP PLL stable and active counts */
+	/* [FIXME] arclk_rst.h says WRONG! This should be 1ms -> 0x50 Check! */
+	reg &= ~UTMIP_PLL_CFG2_STABLE_COUNT(~0);
+	reg |= UTMIP_PLL_CFG2_STABLE_COUNT(utmi_parameters[i].stable_count);
+
+	reg &= ~UTMIP_PLL_CFG2_ACTIVE_DLY_COUNT(~0);
+
+	reg |= UTMIP_PLL_CFG2_ACTIVE_DLY_COUNT(utmi_parameters[i].
+					    active_delay_count);
+
+	/* Remove power downs from UTMIP PLL control bits */
+	reg &= ~UTMIP_PLL_CFG2_FORCE_PD_SAMP_A_POWERDOWN;
+	reg &= ~UTMIP_PLL_CFG2_FORCE_PD_SAMP_B_POWERDOWN;
+	reg &= ~UTMIP_PLL_CFG2_FORCE_PD_SAMP_C_POWERDOWN;
+
+	writel_relaxed(reg, clk_base + UTMIP_PLL_CFG2);
+
+	/* Program UTMIP PLL delay and oscillator frequency counts */
+	reg = readl_relaxed(clk_base + UTMIP_PLL_CFG1);
+	reg &= ~UTMIP_PLL_CFG1_ENABLE_DLY_COUNT(~0);
+
+	reg |= UTMIP_PLL_CFG1_ENABLE_DLY_COUNT(utmi_parameters[i].
+					    enable_delay_count);
+
+	reg &= ~UTMIP_PLL_CFG1_XTAL_FREQ_COUNT(~0);
+	reg |= UTMIP_PLL_CFG1_XTAL_FREQ_COUNT(utmi_parameters[i].
+					   xtal_freq_count);
+
+	/* Remove power downs from UTMIP PLL control bits */
+	reg &= ~UTMIP_PLL_CFG1_FORCE_PLL_ENABLE_POWERDOWN;
+	reg &= ~UTMIP_PLL_CFG1_FORCE_PLL_ACTIVE_POWERDOWN;
+	reg &= ~UTMIP_PLL_CFG1_FORCE_PLLU_POWERUP;
+	reg &= ~UTMIP_PLL_CFG1_FORCE_PLLU_POWERDOWN;
+	writel_relaxed(reg, clk_base + UTMIP_PLL_CFG1);
+
+	/* Setup HW control of UTMIPLL */
+	reg = readl_relaxed(clk_base + UTMIPLL_HW_PWRDN_CFG0);
+	reg |= UTMIPLL_HW_PWRDN_CFG0_USE_LOCKDET;
+	reg &= ~UTMIPLL_HW_PWRDN_CFG0_CLK_ENABLE_SWCTL;
+	reg |= UTMIPLL_HW_PWRDN_CFG0_SEQ_START_STATE;
+	writel_relaxed(reg, clk_base + UTMIPLL_HW_PWRDN_CFG0);
+
+	reg = readl_relaxed(clk_base + UTMIP_PLL_CFG1);
+	reg &= ~UTMIP_PLL_CFG1_FORCE_PLL_ENABLE_POWERUP;
+	reg &= ~UTMIP_PLL_CFG1_FORCE_PLL_ENABLE_POWERDOWN;
+	writel_relaxed(reg, clk_base + UTMIP_PLL_CFG1);
+
+	udelay(1);
+
+	/* Setup SW override of UTMIPLL assuming USB2.0
+	   ports are assigned to USB2 */
+	reg = readl_relaxed(clk_base + UTMIPLL_HW_PWRDN_CFG0);
+	reg |= UTMIPLL_HW_PWRDN_CFG0_IDDQ_SWCTL;
+	reg &= ~UTMIPLL_HW_PWRDN_CFG0_IDDQ_OVERRIDE;
+	writel_relaxed(reg, clk_base + UTMIPLL_HW_PWRDN_CFG0);
+
+	udelay(1);
+
+	/* Enable HW control UTMIPLL */
+	reg = readl_relaxed(clk_base + UTMIPLL_HW_PWRDN_CFG0);
+	reg |= UTMIPLL_HW_PWRDN_CFG0_SEQ_ENABLE;
+	writel_relaxed(reg, clk_base + UTMIPLL_HW_PWRDN_CFG0);
+}
+
+static void __init _clip_vco_min(struct tegra_clk_pll_params *pll_params)
+{
+	pll_params->vco_min =
+		DIV_ROUND_UP(pll_params->vco_min, pll_ref_freq) * pll_ref_freq;
+}
+
+static int __init _setup_dynamic_ramp(struct tegra_clk_pll_params *pll_params,
+				      void __iomem *clk_base)
+{
+	u32 val;
+	u32 step_a, step_b;
+
+	switch (pll_ref_freq) {
+	case 12000000:
+	case 13000000:
+	case 26000000:
+		step_a = 0x2B;
+		step_b = 0x0B;
+		break;
+	case 16800000:
+		step_a = 0x1A;
+		step_b = 0x09;
+		break;
+	case 19200000:
+		step_a = 0x12;
+		step_b = 0x08;
+		break;
+	default:
+		pr_err("%s: Unexpected reference rate %lu\n",
+			__func__, pll_ref_freq);
+		WARN_ON(1);
+		return -EINVAL;
+	}
+
+	val = step_a << pll_params->stepa_shift;
+	val |= step_b << pll_params->stepb_shift;
+	writel_relaxed(val, clk_base + pll_params->dyn_ramp_reg);
+
+	return 0;
+}
+
+static void __init _init_iddq(struct tegra_clk_pll_params *pll_params,
+			      void __iomem *clk_base)
+{
+	u32 val, val_iddq;
+
+	val = readl_relaxed(clk_base + pll_params->base_reg);
+	val_iddq = readl_relaxed(clk_base + pll_params->iddq_reg);
+
+	if (val & BIT(30))
+		WARN_ON(val_iddq & BIT(pll_params->iddq_bit_idx));
+	else {
+		val_iddq |= BIT(pll_params->iddq_bit_idx);
+		writel_relaxed(val_iddq, clk_base + pll_params->iddq_reg);
+	}
+}
+
+static void __init tegra114_pll_init(void __iomem *clk_base,
+				     void __iomem *pmc)
+{
+	u32 val;
+	struct clk *clk;
+
+	/* PLLC */
+	_clip_vco_min(&pll_c_params);
+	if (_setup_dynamic_ramp(&pll_c_params, clk_base) >= 0) {
+		_init_iddq(&pll_c_params, clk_base);
+		clk = tegra_clk_register_pllxc("pll_c", "pll_ref", clk_base,
+				pmc, 0, 0, &pll_c_params, TEGRA_PLL_USE_LOCK,
+				pll_c_freq_table, NULL);
+		clk_register_clkdev(clk, "pll_c", NULL);
+		clks[pll_c] = clk;
+
+		/* PLLC_OUT1 */
+		clk = tegra_clk_register_divider("pll_c_out1_div", "pll_c",
+				clk_base + PLLC_OUT, 0, TEGRA_DIVIDER_ROUND_UP,
+				8, 8, 1, NULL);
+		clk = tegra_clk_register_pll_out("pll_c_out1", "pll_c_out1_div",
+					clk_base + PLLC_OUT, 1, 0,
+					CLK_SET_RATE_PARENT, 0, NULL);
+		clk_register_clkdev(clk, "pll_c_out1", NULL);
+		clks[pll_c_out1] = clk;
+	}
+
+	/* PLLC2 */
+	_clip_vco_min(&pll_c2_params);
+	clk = tegra_clk_register_pllc("pll_c2", "pll_ref", clk_base, pmc, 0, 0,
+			     &pll_c2_params, TEGRA_PLL_USE_LOCK,
+			     pll_cx_freq_table, NULL);
+	clk_register_clkdev(clk, "pll_c2", NULL);
+	clks[pll_c2] = clk;
+
+	/* PLLC3 */
+	_clip_vco_min(&pll_c3_params);
+	clk = tegra_clk_register_pllc("pll_c3", "pll_ref", clk_base, pmc, 0, 0,
+			     &pll_c3_params, TEGRA_PLL_USE_LOCK,
+			     pll_cx_freq_table, NULL);
+	clk_register_clkdev(clk, "pll_c3", NULL);
+	clks[pll_c3] = clk;
+
+	/* PLLP */
+	clk = tegra_clk_register_pll("pll_p", "pll_ref", clk_base, pmc, 0,
+			    408000000, &pll_p_params,
+			    TEGRA_PLL_FIXED | TEGRA_PLL_USE_LOCK,
+			    pll_p_freq_table, NULL);
+	clk_register_clkdev(clk, "pll_p", NULL);
+	clks[pll_p] = clk;
+
+	/* PLLP_OUT1 */
+	clk = tegra_clk_register_divider("pll_p_out1_div", "pll_p",
+				clk_base + PLLP_OUTA, 0, TEGRA_DIVIDER_FIXED |
+				TEGRA_DIVIDER_ROUND_UP, 8, 8, 1, &pll_div_lock);
+	clk = tegra_clk_register_pll_out("pll_p_out1", "pll_p_out1_div",
+				clk_base + PLLP_OUTA, 1, 0,
+				CLK_IGNORE_UNUSED | CLK_SET_RATE_PARENT, 0,
+				&pll_div_lock);
+	clk_register_clkdev(clk, "pll_p_out1", NULL);
+	clks[pll_p_out1] = clk;
+
+	/* PLLP_OUT2 */
+	clk = tegra_clk_register_divider("pll_p_out2_div", "pll_p",
+				clk_base + PLLP_OUTA, 0, TEGRA_DIVIDER_FIXED |
+				TEGRA_DIVIDER_ROUND_UP, 24, 8, 1,
+				&pll_div_lock);
+	clk = tegra_clk_register_pll_out("pll_p_out2", "pll_p_out2_div",
+				clk_base + PLLP_OUTA, 17, 16,
+				CLK_IGNORE_UNUSED | CLK_SET_RATE_PARENT, 0,
+				&pll_div_lock);
+	clk_register_clkdev(clk, "pll_p_out2", NULL);
+	clks[pll_p_out2] = clk;
+
+	/* PLLP_OUT3 */
+	clk = tegra_clk_register_divider("pll_p_out3_div", "pll_p",
+				clk_base + PLLP_OUTB, 0, TEGRA_DIVIDER_FIXED |
+				TEGRA_DIVIDER_ROUND_UP, 8, 8, 1, &pll_div_lock);
+	clk = tegra_clk_register_pll_out("pll_p_out3", "pll_p_out3_div",
+				clk_base + PLLP_OUTB, 1, 0,
+				CLK_IGNORE_UNUSED | CLK_SET_RATE_PARENT, 0,
+				&pll_div_lock);
+	clk_register_clkdev(clk, "pll_p_out3", NULL);
+	clks[pll_p_out3] = clk;
+
+	/* PLLP_OUT4 */
+	clk = tegra_clk_register_divider("pll_p_out4_div", "pll_p",
+				clk_base + PLLP_OUTB, 0, TEGRA_DIVIDER_FIXED |
+				TEGRA_DIVIDER_ROUND_UP, 24, 8, 1,
+				&pll_div_lock);
+	clk = tegra_clk_register_pll_out("pll_p_out4", "pll_p_out4_div",
+				clk_base + PLLP_OUTB, 17, 16,
+				CLK_IGNORE_UNUSED | CLK_SET_RATE_PARENT, 0,
+				&pll_div_lock);
+	clk_register_clkdev(clk, "pll_p_out4", NULL);
+	clks[pll_p_out4] = clk;
+
+	/* PLLM */
+	_clip_vco_min(&pll_m_params);
+	clk = tegra_clk_register_pllm("pll_m", "pll_ref", clk_base, pmc,
+			     CLK_IGNORE_UNUSED | CLK_SET_RATE_GATE, 0,
+			     &pll_m_params, TEGRA_PLL_USE_LOCK,
+			     pll_m_freq_table, NULL);
+	clk_register_clkdev(clk, "pll_m", NULL);
+	clks[pll_m] = clk;
+
+	/* PLLM_OUT1 */
+	clk = tegra_clk_register_divider("pll_m_out1_div", "pll_m",
+				clk_base + PLLM_OUT, 0, TEGRA_DIVIDER_ROUND_UP,
+				8, 8, 1, NULL);
+	clk = tegra_clk_register_pll_out("pll_m_out1", "pll_m_out1_div",
+				clk_base + PLLM_OUT, 1, 0, CLK_IGNORE_UNUSED |
+				CLK_SET_RATE_PARENT, 0, NULL);
+	clk_register_clkdev(clk, "pll_m_out1", NULL);
+	clks[pll_m_out1] = clk;
+
+	/* PLLM_UD */
+	clk = clk_register_fixed_factor(NULL, "pll_m_ud", "pll_m",
+					CLK_SET_RATE_PARENT, 1, 1);
+
+	/* PLLX */
+	_clip_vco_min(&pll_x_params);
+	if (_setup_dynamic_ramp(&pll_x_params, clk_base) >= 0) {
+		_init_iddq(&pll_x_params, clk_base);
+		clk = tegra_clk_register_pllxc("pll_x", "pll_ref", clk_base,
+				pmc, CLK_IGNORE_UNUSED, 0, &pll_x_params,
+				TEGRA_PLL_USE_LOCK, pll_x_freq_table, NULL);
+		clk_register_clkdev(clk, "pll_x", NULL);
+		clks[pll_x] = clk;
+	}
+
+	/* PLLX_OUT0 */
+	clk = clk_register_fixed_factor(NULL, "pll_x_out0", "pll_x",
+					CLK_SET_RATE_PARENT, 1, 2);
+	clk_register_clkdev(clk, "pll_x_out0", NULL);
+	clks[pll_x_out0] = clk;
+
+	/* PLLU */
+	val = readl(clk_base + pll_u_params.base_reg);
+	val &= ~BIT(24); /* disable PLLU_OVERRIDE */
+	writel(val, clk_base + pll_u_params.base_reg);
+
+	clk = tegra_clk_register_pll("pll_u", "pll_ref", clk_base, pmc, 0,
+			    0, &pll_u_params, TEGRA_PLLU |
+			    TEGRA_PLL_HAS_CPCON | TEGRA_PLL_SET_LFCON |
+			    TEGRA_PLL_USE_LOCK, pll_u_freq_table, &pll_u_lock);
+	clk_register_clkdev(clk, "pll_u", NULL);
+	clks[pll_u] = clk;
+
+	tegra114_utmi_param_configure(clk_base);
+
+	/* PLLU_480M */
+	clk = clk_register_gate(NULL, "pll_u_480M", "pll_u",
+				CLK_SET_RATE_PARENT, clk_base + PLLU_BASE,
+				22, 0, &pll_u_lock);
+	clk_register_clkdev(clk, "pll_u_480M", NULL);
+	clks[pll_u_480M] = clk;
+
+	/* PLLU_60M */
+	clk = clk_register_fixed_factor(NULL, "pll_u_60M", "pll_u",
+					CLK_SET_RATE_PARENT, 1, 8);
+	clk_register_clkdev(clk, "pll_u_60M", NULL);
+	clks[pll_u_60M] = clk;
+
+	/* PLLU_48M */
+	clk = clk_register_fixed_factor(NULL, "pll_u_48M", "pll_u",
+					CLK_SET_RATE_PARENT, 1, 10);
+	clk_register_clkdev(clk, "pll_u_48M", NULL);
+	clks[pll_u_48M] = clk;
+
+	/* PLLU_12M */
+	clk = clk_register_fixed_factor(NULL, "pll_u_12M", "pll_u",
+					CLK_SET_RATE_PARENT, 1, 40);
+	clk_register_clkdev(clk, "pll_u_12M", NULL);
+	clks[pll_u_12M] = clk;
+
+	/* PLLD */
+	clk = tegra_clk_register_pll("pll_d", "pll_ref", clk_base, pmc, 0,
+			    0, &pll_d_params,
+			    TEGRA_PLL_HAS_CPCON | TEGRA_PLL_SET_LFCON |
+			    TEGRA_PLL_USE_LOCK, pll_d_freq_table, &pll_d_lock);
+	clk_register_clkdev(clk, "pll_d", NULL);
+	clks[pll_d] = clk;
+
+	/* PLLD_OUT0 */
+	clk = clk_register_fixed_factor(NULL, "pll_d_out0", "pll_d",
+					CLK_SET_RATE_PARENT, 1, 2);
+	clk_register_clkdev(clk, "pll_d_out0", NULL);
+	clks[pll_d_out0] = clk;
+
+	/* PLLD2 */
+	clk = tegra_clk_register_pll("pll_d2", "pll_ref", clk_base, pmc, 0,
+			    0, &pll_d2_params,
+			    TEGRA_PLL_HAS_CPCON | TEGRA_PLL_SET_LFCON |
+			    TEGRA_PLL_USE_LOCK, pll_d_freq_table, &pll_d2_lock);
+	clk_register_clkdev(clk, "pll_d2", NULL);
+	clks[pll_d2] = clk;
+
+	/* PLLD2_OUT0 */
+	clk = clk_register_fixed_factor(NULL, "pll_d2_out0", "pll_d2",
+					CLK_SET_RATE_PARENT, 1, 2);
+	clk_register_clkdev(clk, "pll_d2_out0", NULL);
+	clks[pll_d2_out0] = clk;
+
+	/* PLLA */
+	clk = tegra_clk_register_pll("pll_a", "pll_p_out1", clk_base, pmc, 0,
+			    0, &pll_a_params, TEGRA_PLL_HAS_CPCON |
+			    TEGRA_PLL_USE_LOCK, pll_a_freq_table, NULL);
+	clk_register_clkdev(clk, "pll_a", NULL);
+	clks[pll_a] = clk;
+
+	/* PLLA_OUT0 */
+	clk = tegra_clk_register_divider("pll_a_out0_div", "pll_a",
+				clk_base + PLLA_OUT, 0, TEGRA_DIVIDER_ROUND_UP,
+				8, 8, 1, NULL);
+	clk = tegra_clk_register_pll_out("pll_a_out0", "pll_a_out0_div",
+				clk_base + PLLA_OUT, 1, 0, CLK_IGNORE_UNUSED |
+				CLK_SET_RATE_PARENT, 0, NULL);
+	clk_register_clkdev(clk, "pll_a_out0", NULL);
+	clks[pll_a_out0] = clk;
+
+	/* PLLRE */
+	_clip_vco_min(&pll_re_vco_params);
+	clk = tegra_clk_register_pllre("pll_re_vco", "pll_ref", clk_base, pmc,
+			     0, 0, &pll_re_vco_params, TEGRA_PLL_USE_LOCK,
+			     NULL, &pll_re_lock, pll_ref_freq);
+	clk_register_clkdev(clk, "pll_re_vco", NULL);
+	clks[pll_re_vco] = clk;
+
+	clk = clk_register_divider_table(NULL, "pll_re_out", "pll_re_vco", 0,
+					 clk_base + PLLRE_BASE, 16, 4, 0,
+					 pll_re_div_table, &pll_re_lock);
+	clk_register_clkdev(clk, "pll_re_out", NULL);
+	clks[pll_re_out] = clk;
+
+	/* PLLE */
+	clk = tegra_clk_register_plle_tegra114("pll_e_out0", "pll_re_vco",
+				      clk_base, 0, 100000000, &pll_e_params,
+				      pll_e_freq_table, NULL);
+	clk_register_clkdev(clk, "pll_e_out0", NULL);
+	clks[pll_e_out0] = clk;
+}
+
+static const char *mux_audio_sync_clk[] = { "spdif_in_sync", "i2s0_sync",
+	"i2s1_sync", "i2s2_sync", "i2s3_sync", "i2s4_sync", "vimclk_sync",
+};
+
+static const char *clk_out1_parents[] = { "clk_m", "clk_m_div2",
+	"clk_m_div4", "extern1",
+};
+
+static const char *clk_out2_parents[] = { "clk_m", "clk_m_div2",
+	"clk_m_div4", "extern2",
+};
+
+static const char *clk_out3_parents[] = { "clk_m", "clk_m_div2",
+	"clk_m_div4", "extern3",
+};
+
+static void __init tegra114_audio_clk_init(void __iomem *clk_base)
+{
+	struct clk *clk;
+
+	/* spdif_in_sync */
+	clk = tegra_clk_register_sync_source("spdif_in_sync", 24000000,
+					     24000000);
+	clk_register_clkdev(clk, "spdif_in_sync", NULL);
+	clks[spdif_in_sync] = clk;
+
+	/* i2s0_sync */
+	clk = tegra_clk_register_sync_source("i2s0_sync", 24000000, 24000000);
+	clk_register_clkdev(clk, "i2s0_sync", NULL);
+	clks[i2s0_sync] = clk;
+
+	/* i2s1_sync */
+	clk = tegra_clk_register_sync_source("i2s1_sync", 24000000, 24000000);
+	clk_register_clkdev(clk, "i2s1_sync", NULL);
+	clks[i2s1_sync] = clk;
+
+	/* i2s2_sync */
+	clk = tegra_clk_register_sync_source("i2s2_sync", 24000000, 24000000);
+	clk_register_clkdev(clk, "i2s2_sync", NULL);
+	clks[i2s2_sync] = clk;
+
+	/* i2s3_sync */
+	clk = tegra_clk_register_sync_source("i2s3_sync", 24000000, 24000000);
+	clk_register_clkdev(clk, "i2s3_sync", NULL);
+	clks[i2s3_sync] = clk;
+
+	/* i2s4_sync */
+	clk = tegra_clk_register_sync_source("i2s4_sync", 24000000, 24000000);
+	clk_register_clkdev(clk, "i2s4_sync", NULL);
+	clks[i2s4_sync] = clk;
+
+	/* vimclk_sync */
+	clk = tegra_clk_register_sync_source("vimclk_sync", 24000000, 24000000);
+	clk_register_clkdev(clk, "vimclk_sync", NULL);
+	clks[vimclk_sync] = clk;
+
+	/* audio0 */
+	clk = clk_register_mux(NULL, "audio0_mux", mux_audio_sync_clk,
+			       ARRAY_SIZE(mux_audio_sync_clk), 0,
+			       clk_base + AUDIO_SYNC_CLK_I2S0, 0, 3, 0,
+			       NULL);
+	clks[audio0_mux] = clk;
+	clk = clk_register_gate(NULL, "audio0", "audio0_mux", 0,
+				clk_base + AUDIO_SYNC_CLK_I2S0, 4,
+				CLK_GATE_SET_TO_DISABLE, NULL);
+	clk_register_clkdev(clk, "audio0", NULL);
+	clks[audio0] = clk;
+
+	/* audio1 */
+	clk = clk_register_mux(NULL, "audio1_mux", mux_audio_sync_clk,
+			       ARRAY_SIZE(mux_audio_sync_clk), 0,
+			       clk_base + AUDIO_SYNC_CLK_I2S1, 0, 3, 0,
+			       NULL);
+	clks[audio1_mux] = clk;
+	clk = clk_register_gate(NULL, "audio1", "audio1_mux", 0,
+				clk_base + AUDIO_SYNC_CLK_I2S1, 4,
+				CLK_GATE_SET_TO_DISABLE, NULL);
+	clk_register_clkdev(clk, "audio1", NULL);
+	clks[audio1] = clk;
+
+	/* audio2 */
+	clk = clk_register_mux(NULL, "audio2_mux", mux_audio_sync_clk,
+			       ARRAY_SIZE(mux_audio_sync_clk), 0,
+			       clk_base + AUDIO_SYNC_CLK_I2S2, 0, 3, 0,
+			       NULL);
+	clks[audio2_mux] = clk;
+	clk = clk_register_gate(NULL, "audio2", "audio2_mux", 0,
+				clk_base + AUDIO_SYNC_CLK_I2S2, 4,
+				CLK_GATE_SET_TO_DISABLE, NULL);
+	clk_register_clkdev(clk, "audio2", NULL);
+	clks[audio2] = clk;
+
+	/* audio3 */
+	clk = clk_register_mux(NULL, "audio3_mux", mux_audio_sync_clk,
+			       ARRAY_SIZE(mux_audio_sync_clk), 0,
+			       clk_base + AUDIO_SYNC_CLK_I2S3, 0, 3, 0,
+			       NULL);
+	clks[audio3_mux] = clk;
+	clk = clk_register_gate(NULL, "audio3", "audio3_mux", 0,
+				clk_base + AUDIO_SYNC_CLK_I2S3, 4,
+				CLK_GATE_SET_TO_DISABLE, NULL);
+	clk_register_clkdev(clk, "audio3", NULL);
+	clks[audio3] = clk;
+
+	/* audio4 */
+	clk = clk_register_mux(NULL, "audio4_mux", mux_audio_sync_clk,
+			       ARRAY_SIZE(mux_audio_sync_clk), 0,
+			       clk_base + AUDIO_SYNC_CLK_I2S4, 0, 3, 0,
+			       NULL);
+	clks[audio4_mux] = clk;
+	clk = clk_register_gate(NULL, "audio4", "audio4_mux", 0,
+				clk_base + AUDIO_SYNC_CLK_I2S4, 4,
+				CLK_GATE_SET_TO_DISABLE, NULL);
+	clk_register_clkdev(clk, "audio4", NULL);
+	clks[audio4] = clk;
+
+	/* spdif */
+	clk = clk_register_mux(NULL, "spdif_mux", mux_audio_sync_clk,
+			       ARRAY_SIZE(mux_audio_sync_clk), 0,
+			       clk_base + AUDIO_SYNC_CLK_SPDIF, 0, 3, 0,
+			       NULL);
+	clks[spdif_mux] = clk;
+	clk = clk_register_gate(NULL, "spdif", "spdif_mux", 0,
+				clk_base + AUDIO_SYNC_CLK_SPDIF, 4,
+				CLK_GATE_SET_TO_DISABLE, NULL);
+	clk_register_clkdev(clk, "spdif", NULL);
+	clks[spdif] = clk;
+
+	/* audio0_2x */
+	clk = clk_register_fixed_factor(NULL, "audio0_doubler", "audio0",
+					CLK_SET_RATE_PARENT, 2, 1);
+	clk = tegra_clk_register_divider("audio0_div", "audio0_doubler",
+				clk_base + AUDIO_SYNC_DOUBLER, 0, 0, 24, 1,
+				0, &clk_doubler_lock);
+	clk = tegra_clk_register_periph_gate("audio0_2x", "audio0_div",
+				  TEGRA_PERIPH_NO_RESET, clk_base,
+				  CLK_SET_RATE_PARENT, 113, &periph_v_regs,
+				  periph_clk_enb_refcnt);
+	clk_register_clkdev(clk, "audio0_2x", NULL);
+	clks[audio0_2x] = clk;
+
+	/* audio1_2x */
+	clk = clk_register_fixed_factor(NULL, "audio1_doubler", "audio1",
+					CLK_SET_RATE_PARENT, 2, 1);
+	clk = tegra_clk_register_divider("audio1_div", "audio1_doubler",
+				clk_base + AUDIO_SYNC_DOUBLER, 0, 0, 25, 1,
+				0, &clk_doubler_lock);
+	clk = tegra_clk_register_periph_gate("audio1_2x", "audio1_div",
+				  TEGRA_PERIPH_NO_RESET, clk_base,
+				  CLK_SET_RATE_PARENT, 114, &periph_v_regs,
+				  periph_clk_enb_refcnt);
+	clk_register_clkdev(clk, "audio1_2x", NULL);
+	clks[audio1_2x] = clk;
+
+	/* audio2_2x */
+	clk = clk_register_fixed_factor(NULL, "audio2_doubler", "audio2",
+					CLK_SET_RATE_PARENT, 2, 1);
+	clk = tegra_clk_register_divider("audio2_div", "audio2_doubler",
+				clk_base + AUDIO_SYNC_DOUBLER, 0, 0, 26, 1,
+				0, &clk_doubler_lock);
+	clk = tegra_clk_register_periph_gate("audio2_2x", "audio2_div",
+				  TEGRA_PERIPH_NO_RESET, clk_base,
+				  CLK_SET_RATE_PARENT, 115, &periph_v_regs,
+				  periph_clk_enb_refcnt);
+	clk_register_clkdev(clk, "audio2_2x", NULL);
+	clks[audio2_2x] = clk;
+
+	/* audio3_2x */
+	clk = clk_register_fixed_factor(NULL, "audio3_doubler", "audio3",
+					CLK_SET_RATE_PARENT, 2, 1);
+	clk = tegra_clk_register_divider("audio3_div", "audio3_doubler",
+				clk_base + AUDIO_SYNC_DOUBLER, 0, 0, 27, 1,
+				0, &clk_doubler_lock);
+	clk = tegra_clk_register_periph_gate("audio3_2x", "audio3_div",
+				  TEGRA_PERIPH_NO_RESET, clk_base,
+				  CLK_SET_RATE_PARENT, 116, &periph_v_regs,
+				  periph_clk_enb_refcnt);
+	clk_register_clkdev(clk, "audio3_2x", NULL);
+	clks[audio3_2x] = clk;
+
+	/* audio4_2x */
+	clk = clk_register_fixed_factor(NULL, "audio4_doubler", "audio4",
+					CLK_SET_RATE_PARENT, 2, 1);
+	clk = tegra_clk_register_divider("audio4_div", "audio4_doubler",
+				clk_base + AUDIO_SYNC_DOUBLER, 0, 0, 28, 1,
+				0, &clk_doubler_lock);
+	clk = tegra_clk_register_periph_gate("audio4_2x", "audio4_div",
+				  TEGRA_PERIPH_NO_RESET, clk_base,
+				  CLK_SET_RATE_PARENT, 117, &periph_v_regs,
+				  periph_clk_enb_refcnt);
+	clk_register_clkdev(clk, "audio4_2x", NULL);
+	clks[audio4_2x] = clk;
+
+	/* spdif_2x */
+	clk = clk_register_fixed_factor(NULL, "spdif_doubler", "spdif",
+					CLK_SET_RATE_PARENT, 2, 1);
+	clk = tegra_clk_register_divider("spdif_div", "spdif_doubler",
+				clk_base + AUDIO_SYNC_DOUBLER, 0, 0, 29, 1,
+				0, &clk_doubler_lock);
+	clk = tegra_clk_register_periph_gate("spdif_2x", "spdif_div",
+				  TEGRA_PERIPH_NO_RESET, clk_base,
+				  CLK_SET_RATE_PARENT, 118,
+				  &periph_v_regs, periph_clk_enb_refcnt);
+	clk_register_clkdev(clk, "spdif_2x", NULL);
+	clks[spdif_2x] = clk;
+}
+
+static void __init tegra114_pmc_clk_init(void __iomem *pmc_base)
+{
+	struct clk *clk;
+
+	/* clk_out_1 */
+	clk = clk_register_mux(NULL, "clk_out_1_mux", clk_out1_parents,
+			       ARRAY_SIZE(clk_out1_parents), 0,
+			       pmc_base + PMC_CLK_OUT_CNTRL, 6, 3, 0,
+			       &clk_out_lock);
+	clks[clk_out_1_mux] = clk;
+	clk = clk_register_gate(NULL, "clk_out_1", "clk_out_1_mux", 0,
+				pmc_base + PMC_CLK_OUT_CNTRL, 2, 0,
+				&clk_out_lock);
+	clk_register_clkdev(clk, "extern1", "clk_out_1");
+	clks[clk_out_1] = clk;
+
+	/* clk_out_2 */
+	clk = clk_register_mux(NULL, "clk_out_2_mux", clk_out2_parents,
+			       ARRAY_SIZE(clk_out1_parents), 0,
+			       pmc_base + PMC_CLK_OUT_CNTRL, 14, 3, 0,
+			       &clk_out_lock);
+	clks[clk_out_2_mux] = clk;
+	clk = clk_register_gate(NULL, "clk_out_2", "clk_out_2_mux", 0,
+				pmc_base + PMC_CLK_OUT_CNTRL, 10, 0,
+				&clk_out_lock);
+	clk_register_clkdev(clk, "extern2", "clk_out_2");
+	clks[clk_out_2] = clk;
+
+	/* clk_out_3 */
+	clk = clk_register_mux(NULL, "clk_out_3_mux", clk_out3_parents,
+			       ARRAY_SIZE(clk_out1_parents), 0,
+			       pmc_base + PMC_CLK_OUT_CNTRL, 22, 3, 0,
+			       &clk_out_lock);
+	clks[clk_out_3_mux] = clk;
+	clk = clk_register_gate(NULL, "clk_out_3", "clk_out_3_mux", 0,
+				pmc_base + PMC_CLK_OUT_CNTRL, 18, 0,
+				&clk_out_lock);
+	clk_register_clkdev(clk, "extern3", "clk_out_3");
+	clks[clk_out_3] = clk;
+
+	/* blink */
+	clk = clk_register_gate(NULL, "blink_override", "clk_32k", 0,
+				pmc_base + PMC_DPD_PADS_ORIDE,
+				PMC_DPD_PADS_ORIDE_BLINK_ENB, 0, NULL);
+	clk = clk_register_gate(NULL, "blink", "blink_override", 0,
+				pmc_base + PMC_CTRL,
+				PMC_CTRL_BLINK_ENB, 0, NULL);
+	clk_register_clkdev(clk, "blink", NULL);
+	clks[blink] = clk;
+
+}
+
+static const char *sclk_parents[] = { "clk_m", "pll_c_out1", "pll_p_out4",
+			       "pll_p_out3", "pll_p_out2", "unused",
+			       "clk_32k", "pll_m_out1" };
+
+static const char *cclk_g_parents[] = { "clk_m", "pll_c", "clk_32k", "pll_m",
+					"pll_p", "pll_p_out4", "unused",
+					"unused", "pll_x" };
+
+static const char *cclk_lp_parents[] = { "clk_m", "pll_c", "clk_32k", "pll_m",
+					 "pll_p", "pll_p_out4", "unused",
+					 "unused", "pll_x", "pll_x_out0" };
+
+static void __init tegra114_super_clk_init(void __iomem *clk_base)
+{
+	struct clk *clk;
+
+	/* CCLKG */
+	clk = tegra_clk_register_super_mux("cclk_g", cclk_g_parents,
+					ARRAY_SIZE(cclk_g_parents),
+					CLK_SET_RATE_PARENT,
+					clk_base + CCLKG_BURST_POLICY,
+					0, 4, 0, 0, NULL);
+	clk_register_clkdev(clk, "cclk_g", NULL);
+	clks[cclk_g] = clk;
+
+	/* CCLKLP */
+	clk = tegra_clk_register_super_mux("cclk_lp", cclk_lp_parents,
+					ARRAY_SIZE(cclk_lp_parents),
+					CLK_SET_RATE_PARENT,
+					clk_base + CCLKLP_BURST_POLICY,
+					0, 4, 8, 9, NULL);
+	clk_register_clkdev(clk, "cclk_lp", NULL);
+	clks[cclk_lp] = clk;
+
+	/* SCLK */
+	clk = tegra_clk_register_super_mux("sclk", sclk_parents,
+					ARRAY_SIZE(sclk_parents),
+					CLK_SET_RATE_PARENT,
+					clk_base + SCLK_BURST_POLICY,
+					0, 4, 0, 0, NULL);
+	clk_register_clkdev(clk, "sclk", NULL);
+	clks[sclk] = clk;
+
+	/* HCLK */
+	clk = clk_register_divider(NULL, "hclk_div", "sclk", 0,
+				   clk_base + SYSTEM_CLK_RATE, 4, 2, 0,
+				   &sysrate_lock);
+	clk = clk_register_gate(NULL, "hclk", "hclk_div", CLK_SET_RATE_PARENT |
+				CLK_IGNORE_UNUSED, clk_base + SYSTEM_CLK_RATE,
+				7, CLK_GATE_SET_TO_DISABLE, &sysrate_lock);
+	clk_register_clkdev(clk, "hclk", NULL);
+	clks[hclk] = clk;
+
+	/* PCLK */
+	clk = clk_register_divider(NULL, "pclk_div", "hclk", 0,
+				   clk_base + SYSTEM_CLK_RATE, 0, 2, 0,
+				   &sysrate_lock);
+	clk = clk_register_gate(NULL, "pclk", "pclk_div", CLK_SET_RATE_PARENT |
+				CLK_IGNORE_UNUSED, clk_base + SYSTEM_CLK_RATE,
+				3, CLK_GATE_SET_TO_DISABLE, &sysrate_lock);
+	clk_register_clkdev(clk, "pclk", NULL);
+	clks[pclk] = clk;
+}
+
+static struct tegra_periph_init_data tegra_periph_clk_list[] = {
+	TEGRA_INIT_DATA_MUX("i2s0", NULL, "tegra30-i2s.0", mux_pllaout0_audio0_2x_pllp_clkm, CLK_SOURCE_I2S0, 30, &periph_l_regs, TEGRA_PERIPH_ON_APB, i2s0),
+	TEGRA_INIT_DATA_MUX("i2s1", NULL, "tegra30-i2s.1", mux_pllaout0_audio1_2x_pllp_clkm, CLK_SOURCE_I2S1, 11, &periph_l_regs, TEGRA_PERIPH_ON_APB, i2s1),
+	TEGRA_INIT_DATA_MUX("i2s2", NULL, "tegra30-i2s.2", mux_pllaout0_audio2_2x_pllp_clkm, CLK_SOURCE_I2S2, 18, &periph_l_regs, TEGRA_PERIPH_ON_APB, i2s2),
+	TEGRA_INIT_DATA_MUX("i2s3", NULL, "tegra30-i2s.3", mux_pllaout0_audio3_2x_pllp_clkm, CLK_SOURCE_I2S3, 101, &periph_v_regs, TEGRA_PERIPH_ON_APB, i2s3),
+	TEGRA_INIT_DATA_MUX("i2s4", NULL, "tegra30-i2s.4", mux_pllaout0_audio4_2x_pllp_clkm, CLK_SOURCE_I2S4, 102, &periph_v_regs, TEGRA_PERIPH_ON_APB, i2s4),
+	TEGRA_INIT_DATA_MUX("spdif_out", "spdif_out", "tegra30-spdif", mux_pllaout0_audio_2x_pllp_clkm, CLK_SOURCE_SPDIF_OUT, 10, &periph_l_regs, TEGRA_PERIPH_ON_APB, spdif_out),
+	TEGRA_INIT_DATA_MUX("spdif_in", "spdif_in", "tegra30-spdif", mux_pllp_pllc_pllm, CLK_SOURCE_SPDIF_IN, 10, &periph_l_regs, TEGRA_PERIPH_ON_APB, spdif_in),
+	TEGRA_INIT_DATA_MUX("pwm", NULL, "pwm", mux_pllp_pllc_clk32_clkm, CLK_SOURCE_PWM, 17, &periph_l_regs, TEGRA_PERIPH_ON_APB, pwm),
+	TEGRA_INIT_DATA_MUX("adx", NULL, "adx", mux_plla_pllc_pllp_clkm, CLK_SOURCE_ADX, 154, &periph_w_regs, TEGRA_PERIPH_ON_APB, adx),
+	TEGRA_INIT_DATA_MUX("amx", NULL, "amx", mux_plla_pllc_pllp_clkm, CLK_SOURCE_AMX, 153, &periph_w_regs, TEGRA_PERIPH_ON_APB, amx),
+	TEGRA_INIT_DATA_MUX("hda", "hda", "tegra30-hda", mux_pllp_pllc_pllm_clkm, CLK_SOURCE_HDA, 125, &periph_v_regs, TEGRA_PERIPH_ON_APB, hda),
+	TEGRA_INIT_DATA_MUX("hda2codec_2x", "hda2codec", "tegra30-hda", mux_pllp_pllc_pllm_clkm, CLK_SOURCE_HDA2CODEC_2X, 111, &periph_v_regs, TEGRA_PERIPH_ON_APB, hda2codec_2x),
+	TEGRA_INIT_DATA_MUX("sbc1", NULL, "tegra11-spi.0", mux_pllp_pllc_pllm_clkm, CLK_SOURCE_SBC1, 41, &periph_h_regs, TEGRA_PERIPH_ON_APB, sbc1),
+	TEGRA_INIT_DATA_MUX("sbc2", NULL, "tegra11-spi.1", mux_pllp_pllc_pllm_clkm, CLK_SOURCE_SBC2, 44, &periph_h_regs, TEGRA_PERIPH_ON_APB, sbc2),
+	TEGRA_INIT_DATA_MUX("sbc3", NULL, "tegra11-spi.2", mux_pllp_pllc_pllm_clkm, CLK_SOURCE_SBC3, 46, &periph_h_regs, TEGRA_PERIPH_ON_APB, sbc3),
+	TEGRA_INIT_DATA_MUX("sbc4", NULL, "tegra11-spi.3", mux_pllp_pllc_pllm_clkm, CLK_SOURCE_SBC4, 68, &periph_u_regs, TEGRA_PERIPH_ON_APB, sbc4),
+	TEGRA_INIT_DATA_MUX("sbc5", NULL, "tegra11-spi.4", mux_pllp_pllc_pllm_clkm, CLK_SOURCE_SBC5, 104, &periph_v_regs, TEGRA_PERIPH_ON_APB, sbc5),
+	TEGRA_INIT_DATA_MUX("sbc6", NULL, "tegra11-spi.5", mux_pllp_pllc_pllm_clkm, CLK_SOURCE_SBC6, 105, &periph_v_regs, TEGRA_PERIPH_ON_APB, sbc6),
+	TEGRA_INIT_DATA_MUX8("ndflash", NULL, "tegra_nand", mux_pllp_pllc2_c_c3_pllm_clkm, CLK_SOURCE_NDFLASH, 13, &periph_u_regs, TEGRA_PERIPH_ON_APB, ndspeed),
+	TEGRA_INIT_DATA_MUX8("ndspeed", NULL, "tegra_nand_speed", mux_pllp_pllc2_c_c3_pllm_clkm, CLK_SOURCE_NDSPEED, 80, &periph_u_regs, TEGRA_PERIPH_ON_APB, ndspeed),
+	TEGRA_INIT_DATA_MUX("vfir", NULL, "vfir", mux_pllp_pllc_pllm_clkm, CLK_SOURCE_VFIR, 7, &periph_l_regs, TEGRA_PERIPH_ON_APB, vfir),
+	TEGRA_INIT_DATA_MUX("sdmmc1", NULL, "sdhci-tegra.0", mux_pllp_pllc_pllm_clkm, CLK_SOURCE_SDMMC1, 14, &periph_l_regs, 0, sdmmc1),
+	TEGRA_INIT_DATA_MUX("sdmmc2", NULL, "sdhci-tegra.1", mux_pllp_pllc_pllm_clkm, CLK_SOURCE_SDMMC2, 9, &periph_l_regs, 0, sdmmc2),
+	TEGRA_INIT_DATA_MUX("sdmmc3", NULL, "sdhci-tegra.2", mux_pllp_pllc_pllm_clkm, CLK_SOURCE_SDMMC3, 69, &periph_u_regs, 0, sdmmc3),
+	TEGRA_INIT_DATA_MUX("sdmmc4", NULL, "sdhci-tegra.3", mux_pllp_pllc_pllm_clkm, CLK_SOURCE_SDMMC4, 15, &periph_l_regs, 0, sdmmc4),
+	TEGRA_INIT_DATA_INT("vde", NULL, "vde", mux_pllp_pllc2_c_c3_pllm_clkm, CLK_SOURCE_VDE, 61, &periph_h_regs, 0, vde),
+	TEGRA_INIT_DATA_MUX_FLAGS("csite", NULL, "csite", mux_pllp_pllc_pllm_clkm, CLK_SOURCE_CSITE, 73, &periph_u_regs, TEGRA_PERIPH_ON_APB, csite, CLK_IGNORE_UNUSED),
+	TEGRA_INIT_DATA_MUX("la", NULL, "la", mux_pllp_pllc_pllm_clkm, CLK_SOURCE_LA, 76, &periph_u_regs, TEGRA_PERIPH_ON_APB, la),
+	TEGRA_INIT_DATA_MUX("trace", NULL, "trace", mux_pllp_pllc_pllm_clkm, CLK_SOURCE_TRACE, 77, &periph_u_regs, TEGRA_PERIPH_ON_APB, trace),
+	TEGRA_INIT_DATA_MUX("owr", NULL, "tegra_w1", mux_pllp_pllc_pllm_clkm, CLK_SOURCE_OWR, 71, &periph_u_regs, TEGRA_PERIPH_ON_APB, owr),
+	TEGRA_INIT_DATA_MUX("nor", NULL, "tegra-nor", mux_pllp_pllc_pllm_clkm, CLK_SOURCE_NOR, 42, &periph_h_regs, 0, nor),
+	TEGRA_INIT_DATA_MUX("mipi", NULL, "mipi", mux_pllp_pllc_pllm_clkm, CLK_SOURCE_MIPI, 50, &periph_h_regs, TEGRA_PERIPH_ON_APB, mipi),
+	TEGRA_INIT_DATA_I2C("i2c1", "div-clk", "tegra11-i2c.0", mux_pllp_clkm, CLK_SOURCE_I2C1, 12, &periph_l_regs, i2c1),
+	TEGRA_INIT_DATA_I2C("i2c2", "div-clk", "tegra11-i2c.1", mux_pllp_clkm, CLK_SOURCE_I2C2, 54, &periph_h_regs, i2c2),
+	TEGRA_INIT_DATA_I2C("i2c3", "div-clk", "tegra11-i2c.2", mux_pllp_clkm, CLK_SOURCE_I2C3, 67, &periph_u_regs, i2c3),
+	TEGRA_INIT_DATA_I2C("i2c4", "div-clk", "tegra11-i2c.3", mux_pllp_clkm, CLK_SOURCE_I2C4, 103, &periph_v_regs, i2c4),
+	TEGRA_INIT_DATA_I2C("i2c5", "div-clk", "tegra11-i2c.4", mux_pllp_clkm, CLK_SOURCE_I2C5, 47, &periph_h_regs, i2c5),
+	TEGRA_INIT_DATA_UART("uarta", NULL, "tegra_uart.0", mux_pllp_pllc_pllm_clkm, CLK_SOURCE_UARTA, 6, &periph_l_regs, uarta),
+	TEGRA_INIT_DATA_UART("uartb", NULL, "tegra_uart.1", mux_pllp_pllc_pllm_clkm, CLK_SOURCE_UARTB, 7, &periph_l_regs, uartb),
+	TEGRA_INIT_DATA_UART("uartc", NULL, "tegra_uart.2", mux_pllp_pllc_pllm_clkm, CLK_SOURCE_UARTC, 55, &periph_h_regs, uartc),
+	TEGRA_INIT_DATA_UART("uartd", NULL, "tegra_uart.3", mux_pllp_pllc_pllm_clkm, CLK_SOURCE_UARTD, 65, &periph_u_regs, uartd),
+	TEGRA_INIT_DATA_INT("3d", NULL, "3d", mux_pllm_pllc2_c_c3_pllp_plla, CLK_SOURCE_3D, 24, &periph_l_regs, 0, gr_3d),
+	TEGRA_INIT_DATA_INT("2d", NULL, "2d", mux_pllm_pllc2_c_c3_pllp_plla, CLK_SOURCE_2D, 21, &periph_l_regs, 0, gr_2d),
+	TEGRA_INIT_DATA_MUX("vi_sensor", "vi_sensor", "tegra_camera", mux_pllm_pllc2_c_c3_pllp_plla, CLK_SOURCE_VI_SENSOR, 20, &periph_l_regs, TEGRA_PERIPH_NO_RESET, vi_sensor),
+	TEGRA_INIT_DATA_INT8("vi", "vi", "tegra_camera", mux_pllm_pllc2_c_c3_pllp_plla, CLK_SOURCE_VI, 20, &periph_l_regs, 0, vi),
+	TEGRA_INIT_DATA_INT8("epp", NULL, "epp", mux_pllm_pllc2_c_c3_pllp_plla, CLK_SOURCE_EPP, 19, &periph_l_regs, 0, epp),
+	TEGRA_INIT_DATA_INT8("msenc", NULL, "msenc", mux_pllm_pllc2_c_c3_pllp_plla, CLK_SOURCE_MSENC, 91, &periph_h_regs, TEGRA_PERIPH_WAR_1005168, msenc),
+	TEGRA_INIT_DATA_INT8("tsec", NULL, "tsec", mux_pllp_pllc2_c_c3_pllm_clkm, CLK_SOURCE_TSEC, 83, &periph_u_regs, 0, tsec),
+	TEGRA_INIT_DATA_INT8("host1x", NULL, "host1x", mux_pllm_pllc2_c_c3_pllp_plla, CLK_SOURCE_HOST1X, 28, &periph_l_regs, 0, host1x),
+	TEGRA_INIT_DATA_MUX8("hdmi", NULL, "hdmi", mux_pllp_pllm_plld_plla_pllc_plld2_clkm, CLK_SOURCE_HDMI, 51, &periph_h_regs, 0, hdmi),
+	TEGRA_INIT_DATA_MUX("cilab", "cilab", "tegra_camera", mux_pllp_pllc_clkm, CLK_SOURCE_CILAB, 144, &periph_w_regs, 0, cilab),
+	TEGRA_INIT_DATA_MUX("cilcd", "cilcd", "tegra_camera", mux_pllp_pllc_clkm, CLK_SOURCE_CILCD, 145, &periph_w_regs, 0, cilcd),
+	TEGRA_INIT_DATA_MUX("cile", "cile", "tegra_camera", mux_pllp_pllc_clkm, CLK_SOURCE_CILE, 146, &periph_w_regs, 0, cile),
+	TEGRA_INIT_DATA_MUX("dsialp", "dsialp", "tegradc.0", mux_pllp_pllc_clkm, CLK_SOURCE_DSIALP, 147, &periph_w_regs, 0, dsialp),
+	TEGRA_INIT_DATA_MUX("dsiblp", "dsiblp", "tegradc.1", mux_pllp_pllc_clkm, CLK_SOURCE_DSIBLP, 148, &periph_w_regs, 0, dsiblp),
+	TEGRA_INIT_DATA_MUX("tsensor", NULL, "tegra-tsensor", mux_pllp_pllc_clkm_clk32, CLK_SOURCE_TSENSOR, 100, &periph_v_regs, TEGRA_PERIPH_ON_APB, tsensor),
+	TEGRA_INIT_DATA_MUX("actmon", NULL, "actmon", mux_pllp_pllc_clk32_clkm, CLK_SOURCE_ACTMON, 119, &periph_v_regs, 0, actmon),
+	TEGRA_INIT_DATA_MUX8("extern1", NULL, "extern1", mux_plla_clk32_pllp_clkm_plle, CLK_SOURCE_EXTERN1, 120, &periph_v_regs, 0, extern1),
+	TEGRA_INIT_DATA_MUX8("extern2", NULL, "extern2", mux_plla_clk32_pllp_clkm_plle, CLK_SOURCE_EXTERN2, 121, &periph_v_regs, 0, extern2),
+	TEGRA_INIT_DATA_MUX8("extern3", NULL, "extern3", mux_plla_clk32_pllp_clkm_plle, CLK_SOURCE_EXTERN3, 122, &periph_v_regs, 0, extern3),
+	TEGRA_INIT_DATA_MUX("i2cslow", NULL, "i2cslow", mux_pllp_pllc_clk32_clkm, CLK_SOURCE_I2CSLOW, 81, &periph_u_regs, TEGRA_PERIPH_ON_APB, i2cslow),
+	TEGRA_INIT_DATA_INT8("se", NULL, "se", mux_pllp_pllc2_c_c3_pllm_clkm, CLK_SOURCE_SE, 127, &periph_v_regs, TEGRA_PERIPH_ON_APB, se),
+	TEGRA_INIT_DATA_INT_FLAGS("mselect", NULL, "mselect", mux_pllp_clkm, CLK_SOURCE_MSELECT, 99, &periph_v_regs, 0, mselect, CLK_IGNORE_UNUSED),
+	TEGRA_INIT_DATA_MUX8("soc_therm", NULL, "soc_therm", mux_pllm_pllc_pllp_plla, CLK_SOURCE_SOC_THERM, 78, &periph_u_regs, TEGRA_PERIPH_ON_APB, soc_therm),
+	TEGRA_INIT_DATA_XUSB("xusb_host_src", "host_src", "tegra_xhci", mux_clkm_pllp_pllc_pllre, CLK_SOURCE_XUSB_HOST_SRC, 143, &periph_w_regs, TEGRA_PERIPH_ON_APB | TEGRA_PERIPH_NO_RESET, xusb_host_src),
+	TEGRA_INIT_DATA_XUSB("xusb_falcon_src", "falcon_src", "tegra_xhci", mux_clkm_pllp_pllc_pllre, CLK_SOURCE_XUSB_FALCON_SRC, 143, &periph_w_regs, TEGRA_PERIPH_NO_RESET, xusb_falcon_src),
+	TEGRA_INIT_DATA_XUSB("xusb_fs_src", "fs_src", "tegra_xhci", mux_clkm_48M_pllp_480M, CLK_SOURCE_XUSB_FS_SRC, 143, &periph_w_regs, TEGRA_PERIPH_NO_RESET, xusb_fs_src),
+	TEGRA_INIT_DATA_XUSB("xusb_ss_src", "ss_src", "tegra_xhci", mux_clkm_pllre_clk32_480M_pllc_ref, CLK_SOURCE_XUSB_SS_SRC, 143, &periph_w_regs, TEGRA_PERIPH_NO_RESET, xusb_ss_src),
+	TEGRA_INIT_DATA_XUSB("xusb_dev_src", "dev_src", "tegra_xhci", mux_clkm_pllp_pllc_pllre, CLK_SOURCE_XUSB_DEV_SRC, 95, &periph_u_regs, TEGRA_PERIPH_ON_APB | TEGRA_PERIPH_NO_RESET, xusb_dev_src),
+	TEGRA_INIT_DATA_AUDIO("d_audio", "d_audio", "tegra30-ahub", CLK_SOURCE_D_AUDIO, 106, &periph_v_regs, TEGRA_PERIPH_ON_APB, d_audio),
+	TEGRA_INIT_DATA_AUDIO("dam0", NULL, "tegra30-dam.0", CLK_SOURCE_DAM0, 108, &periph_v_regs, TEGRA_PERIPH_ON_APB, dam0),
+	TEGRA_INIT_DATA_AUDIO("dam1", NULL, "tegra30-dam.1", CLK_SOURCE_DAM1, 109, &periph_v_regs, TEGRA_PERIPH_ON_APB, dam1),
+	TEGRA_INIT_DATA_AUDIO("dam2", NULL, "tegra30-dam.2", CLK_SOURCE_DAM2, 110, &periph_v_regs, TEGRA_PERIPH_ON_APB, dam2),
+};
+
+static struct tegra_periph_init_data tegra_periph_nodiv_clk_list[] = {
+	TEGRA_INIT_DATA_NODIV("disp1", NULL, "tegradc.0", mux_pllp_pllm_plld_plla_pllc_plld2_clkm, CLK_SOURCE_DISP1, 29, 7, 27, &periph_l_regs, 0, disp1),
+	TEGRA_INIT_DATA_NODIV("disp2", NULL, "tegradc.1", mux_pllp_pllm_plld_plla_pllc_plld2_clkm, CLK_SOURCE_DISP2, 29, 7, 26, &periph_l_regs, 0, disp2),
+};
+
+static __init void tegra114_periph_clk_init(void __iomem *clk_base)
+{
+	struct tegra_periph_init_data *data;
+	struct clk *clk;
+	int i;
+	u32 val;
+
+	/* apbdma */
+	clk = tegra_clk_register_periph_gate("apbdma", "clk_m", 0, clk_base,
+				  0, 34, &periph_h_regs,
+				  periph_clk_enb_refcnt);
+	clks[apbdma] = clk;
+
+	/* rtc */
+	clk = tegra_clk_register_periph_gate("rtc", "clk_32k",
+				    TEGRA_PERIPH_ON_APB |
+				    TEGRA_PERIPH_NO_RESET, clk_base,
+				    0, 4, &periph_l_regs,
+				    periph_clk_enb_refcnt);
+	clk_register_clkdev(clk, NULL, "rtc-tegra");
+	clks[rtc] = clk;
+
+	/* kbc */
+	clk = tegra_clk_register_periph_gate("kbc", "clk_32k",
+				    TEGRA_PERIPH_ON_APB |
+				    TEGRA_PERIPH_NO_RESET, clk_base,
+				    0, 36, &periph_h_regs,
+				    periph_clk_enb_refcnt);
+	clks[kbc] = clk;
+
+	/* timer */
+	clk = tegra_clk_register_periph_gate("timer", "clk_m", 0, clk_base,
+				  0, 5, &periph_l_regs,
+				  periph_clk_enb_refcnt);
+	clk_register_clkdev(clk, NULL, "timer");
+	clks[timer] = clk;
+
+	/* kfuse */
+	clk = tegra_clk_register_periph_gate("kfuse", "clk_m",
+				  TEGRA_PERIPH_ON_APB, clk_base,  0, 40,
+				  &periph_h_regs, periph_clk_enb_refcnt);
+	clks[kfuse] = clk;
+
+	/* fuse */
+	clk = tegra_clk_register_periph_gate("fuse", "clk_m",
+				  TEGRA_PERIPH_ON_APB, clk_base,  0, 39,
+				  &periph_h_regs, periph_clk_enb_refcnt);
+	clks[fuse] = clk;
+
+	/* fuse_burn */
+	clk = tegra_clk_register_periph_gate("fuse_burn", "clk_m",
+				  TEGRA_PERIPH_ON_APB, clk_base,  0, 39,
+				  &periph_h_regs, periph_clk_enb_refcnt);
+	clks[fuse_burn] = clk;
+
+	/* apbif */
+	clk = tegra_clk_register_periph_gate("apbif", "clk_m",
+				  TEGRA_PERIPH_ON_APB, clk_base,  0, 107,
+				  &periph_v_regs, periph_clk_enb_refcnt);
+	clks[apbif] = clk;
+
+	/* hda2hdmi */
+	clk = tegra_clk_register_periph_gate("hda2hdmi", "clk_m",
+				    TEGRA_PERIPH_ON_APB, clk_base,  0, 128,
+				    &periph_w_regs, periph_clk_enb_refcnt);
+	clks[hda2hdmi] = clk;
+
+	/* vcp */
+	clk = tegra_clk_register_periph_gate("vcp", "clk_m", 0, clk_base,  0,
+				  29, &periph_l_regs,
+				  periph_clk_enb_refcnt);
+	clks[vcp] = clk;
+
+	/* bsea */
+	clk = tegra_clk_register_periph_gate("bsea", "clk_m", 0, clk_base,
+				  0, 62, &periph_h_regs,
+				  periph_clk_enb_refcnt);
+	clks[bsea] = clk;
+
+	/* bsev */
+	clk = tegra_clk_register_periph_gate("bsev", "clk_m", 0, clk_base,
+				  0, 63, &periph_h_regs,
+				  periph_clk_enb_refcnt);
+	clks[bsev] = clk;
+
+	/* mipi-cal */
+	clk = tegra_clk_register_periph_gate("mipi-cal", "clk_m", 0, clk_base,
+				   0, 56, &periph_h_regs,
+				  periph_clk_enb_refcnt);
+	clks[mipi_cal] = clk;
+
+	/* usbd */
+	clk = tegra_clk_register_periph_gate("usbd", "clk_m", 0, clk_base,
+				  0, 22, &periph_l_regs,
+				  periph_clk_enb_refcnt);
+	clks[usbd] = clk;
+
+	/* usb2 */
+	clk = tegra_clk_register_periph_gate("usb2", "clk_m", 0, clk_base,
+				  0, 58, &periph_h_regs,
+				  periph_clk_enb_refcnt);
+	clks[usb2] = clk;
+
+	/* usb3 */
+	clk = tegra_clk_register_periph_gate("usb3", "clk_m", 0, clk_base,
+				  0, 59, &periph_h_regs,
+				  periph_clk_enb_refcnt);
+	clks[usb3] = clk;
+
+	/* csi */
+	clk = tegra_clk_register_periph_gate("csi", "pll_p_out3", 0, clk_base,
+				   0, 52, &periph_h_regs,
+				  periph_clk_enb_refcnt);
+	clks[csi] = clk;
+
+	/* isp */
+	clk = tegra_clk_register_periph_gate("isp", "clk_m", 0, clk_base, 0,
+				  23, &periph_l_regs,
+				  periph_clk_enb_refcnt);
+	clks[isp] = clk;
+
+	/* csus */
+	clk = tegra_clk_register_periph_gate("csus", "clk_m",
+				  TEGRA_PERIPH_NO_RESET, clk_base, 0, 92,
+				  &periph_u_regs, periph_clk_enb_refcnt);
+	clks[csus] = clk;
+
+	/* dds */
+	clk = tegra_clk_register_periph_gate("dds", "clk_m",
+				  TEGRA_PERIPH_ON_APB, clk_base, 0, 150,
+				  &periph_w_regs, periph_clk_enb_refcnt);
+	clks[dds] = clk;
+
+	/* dp2 */
+	clk = tegra_clk_register_periph_gate("dp2", "clk_m",
+				  TEGRA_PERIPH_ON_APB, clk_base, 0, 152,
+				  &periph_w_regs, periph_clk_enb_refcnt);
+	clks[dp2] = clk;
+
+	/* dtv */
+	clk = tegra_clk_register_periph_gate("dtv", "clk_m",
+				    TEGRA_PERIPH_ON_APB, clk_base, 0, 79,
+				    &periph_u_regs, periph_clk_enb_refcnt);
+	clks[dtv] = clk;
+
+	/* dsia */
+	clk = clk_register_mux(NULL, "dsia_mux", mux_plld_out0_plld2_out0,
+			       ARRAY_SIZE(mux_plld_out0_plld2_out0), 0,
+			       clk_base + PLLD_BASE, 25, 1, 0, &pll_d_lock);
+	clks[dsia_mux] = clk;
+	clk = tegra_clk_register_periph_gate("dsia", "dsia_mux", 0, clk_base,
+				    0, 48, &periph_h_regs,
+				    periph_clk_enb_refcnt);
+	clks[dsia] = clk;
+
+	/* dsib */
+	clk = clk_register_mux(NULL, "dsib_mux", mux_plld_out0_plld2_out0,
+			       ARRAY_SIZE(mux_plld_out0_plld2_out0), 0,
+			       clk_base + PLLD2_BASE, 25, 1, 0, &pll_d2_lock);
+	clks[dsib_mux] = clk;
+	clk = tegra_clk_register_periph_gate("dsib", "dsib_mux", 0, clk_base,
+				    0, 82, &periph_u_regs,
+				    periph_clk_enb_refcnt);
+	clks[dsib] = clk;
+
+	/* xusb_hs_src */
+	val = readl(clk_base + CLK_SOURCE_XUSB_SS_SRC);
+	val |= BIT(25); /* always select PLLU_60M */
+	writel(val, clk_base + CLK_SOURCE_XUSB_SS_SRC);
+
+	clk = clk_register_fixed_factor(NULL, "xusb_hs_src", "pll_u_60M", 0,
+					1, 1);
+	clks[xusb_hs_src] = clk;
+
+	/* xusb_host */
+	clk = tegra_clk_register_periph_gate("xusb_host", "xusb_host_src", 0,
+				    clk_base, 0, 89, &periph_u_regs,
+				    periph_clk_enb_refcnt);
+	clks[xusb_host] = clk;
+
+	/* xusb_ss */
+	clk = tegra_clk_register_periph_gate("xusb_ss", "xusb_ss_src", 0,
+				    clk_base, 0, 156, &periph_w_regs,
+				    periph_clk_enb_refcnt);
+	clks[xusb_host] = clk;
+
+	/* xusb_dev */
+	clk = tegra_clk_register_periph_gate("xusb_dev", "xusb_dev_src", 0,
+				    clk_base, 0, 95, &periph_u_regs,
+				    periph_clk_enb_refcnt);
+	clks[xusb_dev] = clk;
+
+	/* emc */
+	clk = clk_register_mux(NULL, "emc_mux", mux_pllmcp_clkm,
+			       ARRAY_SIZE(mux_pllmcp_clkm), 0,
+			       clk_base + CLK_SOURCE_EMC,
+			       29, 3, 0, NULL);
+	clk = tegra_clk_register_periph_gate("emc", "emc_mux", 0, clk_base,
+				CLK_IGNORE_UNUSED, 57, &periph_h_regs,
+				periph_clk_enb_refcnt);
+	clks[emc] = clk;
+
+	for (i = 0; i < ARRAY_SIZE(tegra_periph_clk_list); i++) {
+		data = &tegra_periph_clk_list[i];
+		clk = tegra_clk_register_periph(data->name, data->parent_names,
+				data->num_parents, &data->periph,
+				clk_base, data->offset, data->flags);
+		clks[data->clk_id] = clk;
+	}
+
+	for (i = 0; i < ARRAY_SIZE(tegra_periph_nodiv_clk_list); i++) {
+		data = &tegra_periph_nodiv_clk_list[i];
+		clk = tegra_clk_register_periph_nodiv(data->name,
+				data->parent_names, data->num_parents,
+				&data->periph, clk_base, data->offset);
+		clks[data->clk_id] = clk;
+	}
+}
+
+static struct tegra_cpu_car_ops tegra114_cpu_car_ops;
+
+static const struct of_device_id pmc_match[] __initconst = {
+	{ .compatible = "nvidia,tegra114-pmc" },
+	{},
+};
+
+static __initdata struct tegra_clk_init_table init_table[] = {
+	{uarta, pll_p, 408000000, 0},
+	{uartb, pll_p, 408000000, 0},
+	{uartc, pll_p, 408000000, 0},
+	{uartd, pll_p, 408000000, 1},
+	{pll_a, clk_max, 564480000, 1},
+	{pll_a_out0, clk_max, 11289600, 1},
+	{extern1, pll_a_out0, 0, 1},
+	{clk_out_1_mux, extern1, 0, 1},
+	{clk_out_1, clk_max, 0, 1},
+	{i2s0, pll_a_out0, 11289600, 0},
+	{i2s1, pll_a_out0, 11289600, 0},
+	{i2s2, pll_a_out0, 11289600, 0},
+	{i2s3, pll_a_out0, 11289600, 0},
+	{i2s4, pll_a_out0, 11289600, 0},
+	{clk_max, clk_max, 0, 0}, /* This MUST be the last entry. */
+};
+
+static void __init tegra114_clock_apply_init_table(void)
+{
+	tegra_init_from_table(init_table, clks, clk_max);
+}
+
+void __init tegra114_clock_init(struct device_node *np)
+{
+	struct device_node *node;
+	int i;
+
+	clk_base = of_iomap(np, 0);
+	if (!clk_base) {
+		pr_err("ioremap tegra114 CAR failed\n");
+		return;
+	}
+
+	node = of_find_matching_node(NULL, pmc_match);
+	if (!node) {
+		pr_err("Failed to find pmc node\n");
+		WARN_ON(1);
+		return;
+	}
+
+	pmc_base = of_iomap(node, 0);
+	if (!pmc_base) {
+		pr_err("Can't map pmc registers\n");
+		WARN_ON(1);
+		return;
+	}
+
+	if (tegra114_osc_clk_init(clk_base) < 0)
+		return;
+
+	tegra114_fixed_clk_init(clk_base);
+	tegra114_pll_init(clk_base, pmc_base);
+	tegra114_periph_clk_init(clk_base);
+	tegra114_audio_clk_init(clk_base);
+	tegra114_pmc_clk_init(pmc_base);
+	tegra114_super_clk_init(clk_base);
+
+	for (i = 0; i < ARRAY_SIZE(clks); i++) {
+		if (IS_ERR(clks[i])) {
+			pr_err
+			    ("Tegra114 clk %d: register failed with %ld\n",
+			     i, PTR_ERR(clks[i]));
+		}
+		if (!clks[i])
+			clks[i] = ERR_PTR(-EINVAL);
+	}
+
+	clk_data.clks = clks;
+	clk_data.clk_num = ARRAY_SIZE(clks);
+	of_clk_add_provider(np, of_clk_src_onecell_get, &clk_data);
+
+	tegra_clk_apply_init_table = tegra114_clock_apply_init_table;
+
+	tegra_cpu_car_ops = &tegra114_cpu_car_ops;
+}
-- 
1.7.7.rc0.72.g4b5ea.dirty



From pdeschrijver at nvidia.com  Wed Apr  3 10:40:46 2013
From: pdeschrijver at nvidia.com (Peter De Schrijver)
Date: Wed, 3 Apr 2013 17:40:46 +0300
Subject: [PATCH v9 12/14] clk: tegra: devicetree match for nvidia, tegra114-car
In-Reply-To: <1365000110-8916-1-git-send-email-pdeschrijver@nvidia.com>
References: <1365000110-8916-1-git-send-email-pdeschrijver@nvidia.com>
Message-ID: <1365000110-8916-13-git-send-email-pdeschrijver@nvidia.com>

Signed-off-by: Peter De Schrijver <pdeschrijver at nvidia.com>
---
 drivers/clk/tegra/clk.c |    1 +
 drivers/clk/tegra/clk.h |    6 ++++++
 2 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/drivers/clk/tegra/clk.c b/drivers/clk/tegra/clk.c
index 70b7a47..923ca7e 100644
--- a/drivers/clk/tegra/clk.c
+++ b/drivers/clk/tegra/clk.c
@@ -77,6 +77,7 @@ void __init tegra_init_from_table(struct tegra_clk_init_table *tbl,
 static const struct of_device_id tegra_dt_clk_match[] = {
 	{ .compatible = "nvidia,tegra20-car", .data = tegra20_clock_init },
 	{ .compatible = "nvidia,tegra30-car", .data = tegra30_clock_init },
+	{ .compatible = "nvidia,tegra114-car", .data = tegra114_clock_init },
 	{ }
 };
 
diff --git a/drivers/clk/tegra/clk.h b/drivers/clk/tegra/clk.h
index fb48f04..e056562 100644
--- a/drivers/clk/tegra/clk.h
+++ b/drivers/clk/tegra/clk.h
@@ -583,6 +583,12 @@ void tegra30_clock_init(struct device_node *np);
 static inline void tegra30_clock_init(struct device_node *np) {}
 #endif /* CONFIG_ARCH_TEGRA_3x_SOC */
 
+#ifdef CONFIG_ARCH_TEGRA_114_SOC
+void tegra114_clock_init(struct device_node *np);
+#else
+static inline void tegra114_clock_init(struct device_node *np) {}
+#endif /* CONFIG_ARCH_TEGRA114_SOC */
+
 typedef void (*tegra_clk_apply_init_table_func)(void);
 extern tegra_clk_apply_init_table_func tegra_clk_apply_init_table;
 
-- 
1.7.7.rc0.72.g4b5ea.dirty



From arnd at arndb.de  Wed Apr  3 10:55:47 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed, 3 Apr 2013 14:55:47 +0000
Subject: [PATCH v5 2/6] usb: phy: omap-usb2: use the new generic PHY
 framework
In-Reply-To: <20130403134827.GF14680@arwen.pp.htv.fi>
References: <1364993634-6378-1-git-send-email-kishon@ti.com>
 <1364993634-6378-3-git-send-email-kishon@ti.com>
 <20130403134827.GF14680@arwen.pp.htv.fi>
Message-ID: <201304031455.47864.arnd@arndb.de>

On Wednesday 03 April 2013, Felipe Balbi wrote:
> const ? Maybe provide a:
> 
> #define DEFINE_PHY_OPS(name)    \
> const struct phy_ops #name_phy_ops = {
> 
> macro ? This will force people to add the const keyword :-)

Forcing people to use const structures is good, but I think it would be
better without the macro, just by marking the argument in 
devm_phy_create() as const.

	Arnd


From pdeschrijver at nvidia.com  Wed Apr  3 10:40:47 2013
From: pdeschrijver at nvidia.com (Peter De Schrijver)
Date: Wed, 3 Apr 2013 17:40:47 +0300
Subject: [PATCH v9 13/14] ARM: dt: Add references to tegra_car clocks
In-Reply-To: <1365000110-8916-1-git-send-email-pdeschrijver@nvidia.com>
References: <1365000110-8916-1-git-send-email-pdeschrijver@nvidia.com>
Message-ID: <1365000110-8916-14-git-send-email-pdeschrijver@nvidia.com>

Add references to tegra_car clocks for the basic device nodes. Also remove
the clock-frequency property of the serial node as the UART driver can now
use the clock framework to obtain the frequency.

Signed-off-by: Peter De Schrijver <pdeschrijver at nvidia.com>
---
 arch/arm/boot/dts/tegra114-dalmore.dts |    1 -
 arch/arm/boot/dts/tegra114-pluto.dts   |    1 -
 arch/arm/boot/dts/tegra114.dtsi        |    8 +++++++-
 3 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/tegra114-dalmore.dts b/arch/arm/boot/dts/tegra114-dalmore.dts
index a61974e..52f1b45 100644
--- a/arch/arm/boot/dts/tegra114-dalmore.dts
+++ b/arch/arm/boot/dts/tegra114-dalmore.dts
@@ -715,7 +715,6 @@
 
 	serial at 70006300 {
 		status = "okay";
-		clock-frequency = <408000000>;
 	};
 
 	pmc {
diff --git a/arch/arm/boot/dts/tegra114-pluto.dts b/arch/arm/boot/dts/tegra114-pluto.dts
index 9bea8f5..31955d7 100644
--- a/arch/arm/boot/dts/tegra114-pluto.dts
+++ b/arch/arm/boot/dts/tegra114-pluto.dts
@@ -12,7 +12,6 @@
 
 	serial at 70006300 {
 		status = "okay";
-		clock-frequency = <408000000>;
 	};
 
 	pmc {
diff --git a/arch/arm/boot/dts/tegra114.dtsi b/arch/arm/boot/dts/tegra114.dtsi
index 5302044..33831a0 100644
--- a/arch/arm/boot/dts/tegra114.dtsi
+++ b/arch/arm/boot/dts/tegra114.dtsi
@@ -31,10 +31,11 @@
 			      0 42 0x04
 			      0 121 0x04
 			      0 122 0x04>;
+		clocks = <&tegra_car 5>;
 	};
 
 	tegra_car: clock {
-		compatible = "nvidia,tegra114-car, nvidia,tegra30-car";
+		compatible = "nvidia,tegra114-car";
 		reg = <0x60006000 0x1000>;
 		#clock-cells = <1>;
 	};
@@ -120,6 +121,7 @@
 		interrupts = <0 36 0x04>;
 		nvidia,dma-request-selector = <&apbdma 8>;
 		status = "disabled";
+		clocks = <&tegra_car 6>;
 	};
 
 	uartb: serial at 70006040 {
@@ -129,6 +131,7 @@
 		interrupts = <0 37 0x04>;
 		nvidia,dma-request-selector = <&apbdma 9>;
 		status = "disabled";
+		clocks = <&tegra_car 192>;
 	};
 
 	uartc: serial at 70006200 {
@@ -138,6 +141,7 @@
 		interrupts = <0 46 0x04>;
 		nvidia,dma-request-selector = <&apbdma 10>;
 		status = "disabled";
+		clocks = <&tegra_car 55>;
 	};
 
 	uartd: serial at 70006300 {
@@ -147,6 +151,7 @@
 		interrupts = <0 90 0x04>;
 		nvidia,dma-request-selector = <&apbdma 19>;
 		status = "disabled";
+		clocks = <&tegra_car 65>;
 	};
 
 	pwm: pwm {
@@ -288,6 +293,7 @@
 		compatible = "nvidia,tegra114-rtc", "nvidia,tegra20-rtc";
 		reg = <0x7000e000 0x100>;
 		interrupts = <0 2 0x04>;
+		clocks = <&tegra_car 4>;
 	};
 
 	kbc {
-- 
1.7.7.rc0.72.g4b5ea.dirty



From pdeschrijver at nvidia.com  Wed Apr  3 10:40:48 2013
From: pdeschrijver at nvidia.com (Peter De Schrijver)
Date: Wed, 3 Apr 2013 17:40:48 +0300
Subject: [PATCH v9 13/14] ARM: dt: Add references to tegra_car clocks
In-Reply-To: <1365000110-8916-1-git-send-email-pdeschrijver@nvidia.com>
References: <1365000110-8916-1-git-send-email-pdeschrijver@nvidia.com>
Message-ID: <1365000110-8916-15-git-send-email-pdeschrijver@nvidia.com>

Add references to tegra_car clocks for the basic device nodes. Also remove
the clock-frequency property of the serial node as the UART driver can now
use the clock framework to obtain the frequency.

Signed-off-by: Peter De Schrijver <pdeschrijver at nvidia.com>
---
 arch/arm/boot/dts/tegra114-dalmore.dts |    1 -
 arch/arm/boot/dts/tegra114-pluto.dts   |    1 -
 arch/arm/boot/dts/tegra114.dtsi        |    8 +++++++-
 3 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/tegra114-dalmore.dts b/arch/arm/boot/dts/tegra114-dalmore.dts
index a61974e..52f1b45 100644
--- a/arch/arm/boot/dts/tegra114-dalmore.dts
+++ b/arch/arm/boot/dts/tegra114-dalmore.dts
@@ -715,7 +715,6 @@
 
 	serial at 70006300 {
 		status = "okay";
-		clock-frequency = <408000000>;
 	};
 
 	pmc {
diff --git a/arch/arm/boot/dts/tegra114-pluto.dts b/arch/arm/boot/dts/tegra114-pluto.dts
index 9bea8f5..31955d7 100644
--- a/arch/arm/boot/dts/tegra114-pluto.dts
+++ b/arch/arm/boot/dts/tegra114-pluto.dts
@@ -12,7 +12,6 @@
 
 	serial at 70006300 {
 		status = "okay";
-		clock-frequency = <408000000>;
 	};
 
 	pmc {
diff --git a/arch/arm/boot/dts/tegra114.dtsi b/arch/arm/boot/dts/tegra114.dtsi
index 5302044..33831a0 100644
--- a/arch/arm/boot/dts/tegra114.dtsi
+++ b/arch/arm/boot/dts/tegra114.dtsi
@@ -31,10 +31,11 @@
 			      0 42 0x04
 			      0 121 0x04
 			      0 122 0x04>;
+		clocks = <&tegra_car 5>;
 	};
 
 	tegra_car: clock {
-		compatible = "nvidia,tegra114-car, nvidia,tegra30-car";
+		compatible = "nvidia,tegra114-car";
 		reg = <0x60006000 0x1000>;
 		#clock-cells = <1>;
 	};
@@ -120,6 +121,7 @@
 		interrupts = <0 36 0x04>;
 		nvidia,dma-request-selector = <&apbdma 8>;
 		status = "disabled";
+		clocks = <&tegra_car 6>;
 	};
 
 	uartb: serial at 70006040 {
@@ -129,6 +131,7 @@
 		interrupts = <0 37 0x04>;
 		nvidia,dma-request-selector = <&apbdma 9>;
 		status = "disabled";
+		clocks = <&tegra_car 192>;
 	};
 
 	uartc: serial at 70006200 {
@@ -138,6 +141,7 @@
 		interrupts = <0 46 0x04>;
 		nvidia,dma-request-selector = <&apbdma 10>;
 		status = "disabled";
+		clocks = <&tegra_car 55>;
 	};
 
 	uartd: serial at 70006300 {
@@ -147,6 +151,7 @@
 		interrupts = <0 90 0x04>;
 		nvidia,dma-request-selector = <&apbdma 19>;
 		status = "disabled";
+		clocks = <&tegra_car 65>;
 	};
 
 	pwm: pwm {
@@ -288,6 +293,7 @@
 		compatible = "nvidia,tegra114-rtc", "nvidia,tegra20-rtc";
 		reg = <0x7000e000 0x100>;
 		interrupts = <0 2 0x04>;
+		clocks = <&tegra_car 4>;
 	};
 
 	kbc {
-- 
1.7.7.rc0.72.g4b5ea.dirty



From pdeschrijver at nvidia.com  Wed Apr  3 10:40:49 2013
From: pdeschrijver at nvidia.com (Peter De Schrijver)
Date: Wed, 3 Apr 2013 17:40:49 +0300
Subject: [PATCH v9 14/14] clk: tegra: Remove forced clk_enable of uartd
In-Reply-To: <1365000110-8916-1-git-send-email-pdeschrijver@nvidia.com>
References: <1365000110-8916-1-git-send-email-pdeschrijver@nvidia.com>
Message-ID: <1365000110-8916-16-git-send-email-pdeschrijver@nvidia.com>

The UART driver enables the console uart clock, so we don't need to do that
anymore in this file.

Signed-off-by: Peter De Schrijver <pdeschrijver at nvidia.com>
---
 drivers/clk/tegra/clk-tegra114.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/clk/tegra/clk-tegra114.c b/drivers/clk/tegra/clk-tegra114.c
index e2a7fa1..0db81dd 100644
--- a/drivers/clk/tegra/clk-tegra114.c
+++ b/drivers/clk/tegra/clk-tegra114.c
@@ -2011,7 +2011,7 @@ static __initdata struct tegra_clk_init_table init_table[] = {
 	{uarta, pll_p, 408000000, 0},
 	{uartb, pll_p, 408000000, 0},
 	{uartc, pll_p, 408000000, 0},
-	{uartd, pll_p, 408000000, 1},
+	{uartd, pll_p, 408000000, 0},
 	{pll_a, clk_max, 564480000, 1},
 	{pll_a_out0, clk_max, 11289600, 1},
 	{extern1, pll_a_out0, 0, 1},
-- 
1.7.7.rc0.72.g4b5ea.dirty



From mturquette at linaro.org  Wed Apr  3 11:40:27 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Wed, 03 Apr 2013 08:40:27 -0700
Subject: [PATCH] clk: divider: Introduce CLK_DIVIDER_ALLOW_ZERO flag
In-Reply-To: <397e02df-e5d1-4211-8a44-2ee15cf4188f@DB3EHSMHS005.ehs.local>
References: <397e02df-e5d1-4211-8a44-2ee15cf4188f@DB3EHSMHS005.ehs.local>
Message-ID: <20130403154027.8177.58419@quantum>

Quoting Soren Brinkmann (2013-04-02 15:36:56)
> Dividers which have CLK_DIVIDER_ONE_BASED set have a redundant state,
> being a divider value of zero. Some hardware implementations allow a
> zero divider which simply doesn't alter the frequency. I.e. it acts like
> a divide by one or bypassing the divider.
> This flag is used to handle such HW in the clk-divider model.
> 
> Signed-off-by: Soren Brinkmann <soren.brinkmann at xilinx.com>

This version looks good.  Taken into clk-next.

Thanks,
Mike

> ---
>  drivers/clk/clk-divider.c    | 5 +++--
>  include/linux/clk-provider.h | 8 +++++++-
>  2 files changed, 10 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
> index 68b4021..6d96741 100644
> --- a/drivers/clk/clk-divider.c
> +++ b/drivers/clk/clk-divider.c
> @@ -109,8 +109,9 @@ static unsigned long clk_divider_recalc_rate(struct clk_hw *hw,
>  
>         div = _get_div(divider, val);
>         if (!div) {
> -               WARN(1, "%s: Invalid divisor for clock %s\n", __func__,
> -                                               __clk_get_name(hw->clk));
> +               WARN(!(divider->flags & CLK_DIVIDER_ALLOW_ZERO),
> +                       "%s: Zero divisor and CLK_DIVIDER_ALLOW_ZERO not set\n",
> +                       __clk_get_name(hw->clk));
>                 return parent_rate;
>         }
>  
> diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
> index 7f197d7..811426d 100644
> --- a/include/linux/clk-provider.h
> +++ b/include/linux/clk-provider.h
> @@ -239,9 +239,14 @@ struct clk_div_table {
>   * CLK_DIVIDER_ONE_BASED - by default the divisor is the value read from the
>   *     register plus one.  If CLK_DIVIDER_ONE_BASED is set then the divider is
>   *     the raw value read from the register, with the value of zero considered
> - *     invalid
> + *     invalid, unless CLK_DIVIDER_ALLOW_ZERO is set.
>   * CLK_DIVIDER_POWER_OF_TWO - clock divisor is 2 raised to the value read from
>   *     the hardware register
> + * CLK_DIVIDER_ALLOW_ZERO - Allow zero divisors.  For dividers which have
> + *     CLK_DIVIDER_ONE_BASED set, it is possible to end up with a zero divisor.
> + *     Some hardware implementations gracefully handle this case and allow a
> + *     zero divisor by not modifying their input clock
> + *     (divide by one / bypass).
>   */
>  struct clk_divider {
>         struct clk_hw   hw;
> @@ -255,6 +260,7 @@ struct clk_divider {
>  
>  #define CLK_DIVIDER_ONE_BASED          BIT(0)
>  #define CLK_DIVIDER_POWER_OF_TWO       BIT(1)
> +#define CLK_DIVIDER_ALLOW_ZERO         BIT(2)
>  
>  extern const struct clk_ops clk_divider_ops;
>  struct clk *clk_register_divider(struct device *dev, const char *name,
> -- 
> 1.8.2


From rogerio.pimentel at freescale.com  Wed Apr  3 11:36:28 2013
From: rogerio.pimentel at freescale.com (Rogerio Pimentel)
Date: Wed, 3 Apr 2013 12:36:28 -0300
Subject: [PATCH 1/3] video: Make IPU KMS parse display-timings
Message-ID: <1365003390-26964-1-git-send-email-rogerio.pimentel@freescale.com>

From: Marek Vasut <marex at denx.de>

This patch adds support for parsing of the DT display-timings prop
to IPU KMS driver.

Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
Signed-off-by: Marek Vasut <marex at denx.de>
---
 drivers/staging/imx-drm/parallel-display.c |   10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/staging/imx-drm/parallel-display.c b/drivers/staging/imx-drm/parallel-display.c
index a8064fc..2a25202 100644
--- a/drivers/staging/imx-drm/parallel-display.c
+++ b/drivers/staging/imx-drm/parallel-display.c
@@ -57,6 +57,7 @@ static void imx_pd_connector_destroy(struct drm_connector *connector)
 static int imx_pd_connector_get_modes(struct drm_connector *connector)
 {
 	struct imx_parallel_display *imxpd = con_to_imxpd(connector);
+	struct device_node *np = imxpd->dev->of_node;
 	int num_modes = 0;
 
 	if (imxpd->edid) {
@@ -72,6 +73,15 @@ static int imx_pd_connector_get_modes(struct drm_connector *connector)
 		num_modes++;
 	}
 
+	if (np) {
+		struct drm_display_mode *mode = drm_mode_create(connector->dev);
+		of_get_drm_display_mode(np, &imxpd->mode, 0);
+		drm_mode_copy(mode, &imxpd->mode);
+		mode->type |= DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED,
+		drm_mode_probed_add(connector, mode);
+		num_modes++;
+	}
+
 	return num_modes;
 }
 
-- 
1.7.10.4




From rogerio.pimentel at freescale.com  Wed Apr  3 11:36:29 2013
From: rogerio.pimentel at freescale.com (Rogerio Pimentel)
Date: Wed, 3 Apr 2013 12:36:29 -0300
Subject: [PATCH 2/3] ARM: dts: mx53qsb: Add support for parallel display
In-Reply-To: <1365003390-26964-1-git-send-email-rogerio.pimentel@freescale.com>
References: <1365003390-26964-1-git-send-email-rogerio.pimentel@freescale.com>
Message-ID: <1365003390-26964-2-git-send-email-rogerio.pimentel@freescale.com>

Add support for CLAA WVGA display for i.MX53 QSB.

Signed-off-by: Rogerio Pimentel <rogerio.pimentel at freescale.com>
---
 arch/arm/boot/dts/imx53-qsb.dtsp |   26 ++++++++++++++++++++++++++
 arch/arm/boot/dts/imx53.dtsip    |   35 +++++++++++++++++++++++++++++++++++
 2 files changed, 61 insertions(+)

diff --git a/arch/arm/boot/dts/imx53-qsb.dtsp b/arch/arm/boot/dts/imx53-qsb.dtsp
index dae8d9f..f9449b0 100644
--- a/arch/arm/boot/dts/imx53-qsb.dtsp
+++ b/arch/arm/boot/dts/imx53-qsb.dtsp
@@ -21,6 +21,32 @@
 		reg = <0x70000000 0x40000000>;
 	};
 
+	display at di0 {
+		compatible = "fsl,imx-parallel-display";
+		crtcs = <&ipu 0>;
+		interface-pix-fmt = "rgb565";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_ipu_disp1_1>;
+		display-timings {
+			claawvga {
+				native-mode;
+				clock-frequency = <27000000>;
+				hactive = <800>;
+				vactive = <480>;
+				hback-porch = <40>;
+				hfront-porch = <60>;
+				vback-porch = <10>;
+				vfront-porch = <10>;
+				hsync-len = <20>;
+				vsync-len = <10>;
+				hsync-active = <0>;
+				vsync-active = <0>;
+				de-active = <1>;
+				pixelclk-active = <0>;
+			};
+		};
+	};
+
 	gpio-keys {
 		compatible = "gpio-keys";
 
diff --git a/arch/arm/boot/dts/imx53.dtsip b/arch/arm/boot/dts/imx53.dtsip
index 6c73bee..d2cd67e 100644
--- a/arch/arm/boot/dts/imx53.dtsip
+++ b/arch/arm/boot/dts/imx53.dtsip
@@ -441,6 +441,41 @@
 					};
 				};
 
+				ipu_disp1 {
+					pinctrl_ipu_disp1_1: ipudisp1grp-1 {
+						fsl,pins = <
+						MX53_PAD_DI0_DISP_CLK__IPU_DI0_DISP_CLK 0x5
+						MX53_PAD_DI0_PIN15__IPU_DI0_PIN15 0x5
+						MX53_PAD_DI0_PIN2__IPU_DI0_PIN2 0x5
+						MX53_PAD_DI0_PIN3__IPU_DI0_PIN3  0x5
+						MX53_PAD_DISP0_DAT0__IPU_DISP0_DAT_0 0x5
+						MX53_PAD_DISP0_DAT1__IPU_DISP0_DAT_1 0x5
+						MX53_PAD_DISP0_DAT2__IPU_DISP0_DAT_2 0x5
+						MX53_PAD_DISP0_DAT3__IPU_DISP0_DAT_3 0x5
+						MX53_PAD_DISP0_DAT4__IPU_DISP0_DAT_4 0x5
+						MX53_PAD_DISP0_DAT5__IPU_DISP0_DAT_5 0x5
+						MX53_PAD_DISP0_DAT6__IPU_DISP0_DAT_6 0x5
+						MX53_PAD_DISP0_DAT7__IPU_DISP0_DAT_7 0x5
+						MX53_PAD_DISP0_DAT8__IPU_DISP0_DAT_8 0x5
+						MX53_PAD_DISP0_DAT9__IPU_DISP0_DAT_9 0x5
+						MX53_PAD_DISP0_DAT10__IPU_DISP0_DAT_10 0x5
+						MX53_PAD_DISP0_DAT11__IPU_DISP0_DAT_11 0x5
+						MX53_PAD_DISP0_DAT12__IPU_DISP0_DAT_12 0x5
+						MX53_PAD_DISP0_DAT13__IPU_DISP0_DAT_13 0x5
+						MX53_PAD_DISP0_DAT14__IPU_DISP0_DAT_14 0x5
+						MX53_PAD_DISP0_DAT15__IPU_DISP0_DAT_15 0x5
+						MX53_PAD_DISP0_DAT16__IPU_DISP0_DAT_16 0x5
+						MX53_PAD_DISP0_DAT17__IPU_DISP0_DAT_17 0x5
+						MX53_PAD_DISP0_DAT18__IPU_DISP0_DAT_18 0x5
+						MX53_PAD_DISP0_DAT19__IPU_DISP0_DAT_19 0x5
+						MX53_PAD_DISP0_DAT20__IPU_DISP0_DAT_20 0x5
+						MX53_PAD_DISP0_DAT21__IPU_DISP0_DAT_21 0x5
+						MX53_PAD_DISP0_DAT22__IPU_DISP0_DAT_22 0x5
+						MX53_PAD_DISP0_DAT23__IPU_DISP0_DAT_23 0x5
+						>;
+					};
+				};
+
 				owire {
 					pinctrl_owire_1: owiregrp-1 {
 						fsl,pins = <
-- 
1.7.10.4




From rogerio.pimentel at freescale.com  Wed Apr  3 11:36:30 2013
From: rogerio.pimentel at freescale.com (Rogerio Pimentel)
Date: Wed, 3 Apr 2013 12:36:30 -0300
Subject: [PATCH 3/3] ARM: imx_v6_v7_defconfig: enable parallel display
In-Reply-To: <1365003390-26964-1-git-send-email-rogerio.pimentel@freescale.com>
References: <1365003390-26964-1-git-send-email-rogerio.pimentel@freescale.com>
Message-ID: <1365003390-26964-3-git-send-email-rogerio.pimentel@freescale.com>

Allow parallel display to work by default

Signed-off-by: Rogerio Pimentel <rogerio.pimentel at freescale.com>
---
 arch/arm/configs/imx_v6_v7_defconfig |    3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/configs/imx_v6_v7_defconfig b/arch/arm/configs/imx_v6_v7_defconfig
index e36b010..4942479 100644
--- a/arch/arm/configs/imx_v6_v7_defconfig
+++ b/arch/arm/configs/imx_v6_v7_defconfig
@@ -162,6 +162,7 @@ CONFIG_MEDIA_CAMERA_SUPPORT=y
 CONFIG_SOC_CAMERA=y
 CONFIG_SOC_CAMERA_OV2640=y
 CONFIG_DRM=y
+CONFIG_OF_VIDEOMODE=y
 CONFIG_VIDEO_MX3=y
 CONFIG_FB=y
 CONFIG_LCD_PLATFORM=y
@@ -206,6 +207,8 @@ CONFIG_IMX_SDMA=y
 CONFIG_MXS_DMA=y
 CONFIG_STAGING=y
 CONFIG_DRM_IMX=y
+CONFIG_DRM_IMX_FB_HELPER=y
+CONFIG_DRM_IMX_PARALLEL_DISPLAY=y
 CONFIG_DRM_IMX_IPUV3_CORE=y
 CONFIG_DRM_IMX_IPUV3=y
 CONFIG_COMMON_CLK_DEBUG=y
-- 
1.7.10.4




From tony at atomide.com  Wed Apr  3 11:43:35 2013
From: tony at atomide.com (Tony Lindgren)
Date: Wed, 3 Apr 2013 08:43:35 -0700
Subject: [PATCH v4] ARM: omap2: twl-common: Add default power configuration
In-Reply-To: <1364992287-6992-1-git-send-email-peter.ujfalusi@ti.com>
References: <1364992287-6992-1-git-send-email-peter.ujfalusi@ti.com>
Message-ID: <20130403154335.GU10155@atomide.com>

* Peter Ujfalusi <peter.ujfalusi at ti.com> [130403 05:36]:
> From: Matthias Brugger <matthias.bgg at gmail.com>
> 
> This patch adds a generic power script configuration.
> When rebooting an OMAP3530 at 125 MHz, the reboot hangs.
> With the generic power script, TWL4030 will be reset
> when a warm reset occures. This way the OMAP3530 does not
> hang on reboot.
> 
> Signed-off-by: Matthias Brugger <matthias.bgg at gmail.com>
> Signed-off-by: Peter Ujfalusi <peter.ujfalusi at ti.com>
> ---
> Tony, Matthias,
> 
> Changes since v3:
> - remove the __initdata from all the structures introduced by this patch
> 
> If it is OK, I'll send a pull with this patch.

Well I was wondering if you have checked what happens if you re-init
the driver via /sys? Is this safe to do?

Regards,

Tony
 
>  arch/arm/mach-omap2/twl-common.c | 38 ++++++++++++++++++++++++++++++++++++++
>  arch/arm/mach-omap2/twl-common.h |  1 +
>  2 files changed, 39 insertions(+)
> 
> diff --git a/arch/arm/mach-omap2/twl-common.c b/arch/arm/mach-omap2/twl-common.c
> index 51e138c..a85531e 100644
> --- a/arch/arm/mach-omap2/twl-common.c
> +++ b/arch/arm/mach-omap2/twl-common.c
> @@ -121,6 +121,41 @@ static struct twl4030_audio_data omap3_audio_pdata = {
>  	.codec = &omap3_codec,
>  };
>  
> +static struct twl4030_ins wrst_seq[] = {
> +	{MSG_SINGULAR(DEV_GRP_NULL, 0x1b, RES_STATE_OFF), 2},
> +	{MSG_SINGULAR(DEV_GRP_P1, 0xf, RES_STATE_WRST), 15},
> +	{MSG_SINGULAR(DEV_GRP_P1, 0x10, RES_STATE_WRST), 15},
> +	{MSG_SINGULAR(DEV_GRP_P1, 0x7, RES_STATE_WRST), 0x60},
> +	{MSG_SINGULAR(DEV_GRP_P1, 0x19, RES_STATE_ACTIVE), 2},
> +	{MSG_SINGULAR(DEV_GRP_NULL, 0x1b, RES_STATE_ACTIVE), 2},
> +};
> +
> +static struct twl4030_script wrst_script = {
> +	.script = wrst_seq,
> +	.size	= ARRAY_SIZE(wrst_seq),
> +	.flags	= TWL4030_WRST_SCRIPT,
> +};
> +
> +static struct twl4030_script *omap3_power_scripts[] = {
> +	&wrst_script,
> +};
> +
> +static struct twl4030_resconfig omap3_rconfig[] = {
> +	{ .resource = RES_HFCLKOUT, .devgroup = DEV_GRP_P3, .type = -1,
> +		.type2 = -1 },
> +	{ .resource = RES_VDD1, .devgroup = DEV_GRP_P1, .type = -1,
> +		.type2 = -1 },
> +	{ .resource = RES_VDD2, .devgroup = DEV_GRP_P1, .type = -1,
> +		.type2 = -1 },
> +	{ 0, 0},
> +};
> +
> +static struct twl4030_power_data omap3_power_pdata = {
> +	.scripts	= omap3_power_scripts,
> +	.num		= ARRAY_SIZE(omap3_power_scripts),
> +	.resource_config = omap3_rconfig,
> +};
> +
>  static struct regulator_consumer_supply omap3_vdda_dac_supplies[] = {
>  	REGULATOR_SUPPLY("vdda_dac", "omapdss_venc"),
>  };
> @@ -225,6 +260,9 @@ void __init omap3_pmic_get_config(struct twl4030_platform_data *pmic_data,
>  	if (pdata_flags & TWL_COMMON_PDATA_AUDIO && !pmic_data->audio)
>  		pmic_data->audio = &omap3_audio_pdata;
>  
> +	if (pdata_flags & TWL_COMMON_PDATA_POWER && !pmic_data->power)
> +		pmic_data->power = &omap3_power_pdata;
> +
>  	/* Common regulator configurations */
>  	if (regulators_flags & TWL_COMMON_REGULATOR_VDAC && !pmic_data->vdac)
>  		pmic_data->vdac = &omap3_vdac_idata;
> diff --git a/arch/arm/mach-omap2/twl-common.h b/arch/arm/mach-omap2/twl-common.h
> index 24b65d0..b64590b8 100644
> --- a/arch/arm/mach-omap2/twl-common.h
> +++ b/arch/arm/mach-omap2/twl-common.h
> @@ -7,6 +7,7 @@
>  #define TWL_COMMON_PDATA_BCI		(1 << 1)
>  #define TWL_COMMON_PDATA_MADC		(1 << 2)
>  #define TWL_COMMON_PDATA_AUDIO		(1 << 3)
> +#define TWL_COMMON_PDATA_POWER		(1 << 4)
>  
>  /* Common LDO regulators for TWL4030/TWL6030 */
>  #define TWL_COMMON_REGULATOR_VDAC	(1 << 0)
> -- 
> 1.8.1.5
> 


From balbi at ti.com  Wed Apr  3 11:47:04 2013
From: balbi at ti.com (Felipe Balbi)
Date: Wed, 3 Apr 2013 18:47:04 +0300
Subject: [PATCH v5 1/6] drivers: phy: add generic PHY framework
In-Reply-To: <515C3D94.1060000@ti.com>
References: <1364993634-6378-1-git-send-email-kishon@ti.com>
 <1364993634-6378-2-git-send-email-kishon@ti.com>
 <20130403134102.GC14680@arwen.pp.htv.fi> <515C3A42.4020404@ti.com>
 <20130403142747.GK14680@arwen.pp.htv.fi> <515C3D94.1060000@ti.com>
Message-ID: <20130403154704.GD19093@arwen.pp.htv.fi>

Hi,

On Wed, Apr 03, 2013 at 08:02:52PM +0530, Kishon Vijay Abraham I wrote:
> >>>>+		ret = -EINVAL;
> >>>>+		goto err0;
> >>>>+	}
> >>>>+
> >>>>+	if (!phy_class)
> >>>>+		phy_core_init();
> >>>
> >>>why don't you setup the class on module_init ? Then this would be a
> >>>terrible error condition here :-)
> >>
> >>This is for the case where the PHY driver gets loaded before the PHY
> >>framework. I could have returned EPROBE_DEFER here instead I thought
> >>will have it this way.
> >
> >looks a bit weird IMO. Is it really possible for PHY to load before ?
> 
> yeah. it actually happened when I tried with beagle and had all the
> modules as built-in. Because twl4030 has subsys_initcall(), it loads
> before PHY framework.

that's a bug in twl4030.

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130403/494c6f11/attachment.sig>

From balbi at ti.com  Wed Apr  3 11:48:07 2013
From: balbi at ti.com (Felipe Balbi)
Date: Wed, 3 Apr 2013 18:48:07 +0300
Subject: [PATCH v5 2/6] usb: phy: omap-usb2: use the new generic PHY
 framework
In-Reply-To: <201304031455.47864.arnd@arndb.de>
References: <1364993634-6378-1-git-send-email-kishon@ti.com>
 <1364993634-6378-3-git-send-email-kishon@ti.com>
 <20130403134827.GF14680@arwen.pp.htv.fi>
 <201304031455.47864.arnd@arndb.de>
Message-ID: <20130403154807.GE19093@arwen.pp.htv.fi>

Hi,

On Wed, Apr 03, 2013 at 02:55:47PM +0000, Arnd Bergmann wrote:
> On Wednesday 03 April 2013, Felipe Balbi wrote:
> > const ? Maybe provide a:
> > 
> > #define DEFINE_PHY_OPS(name)    \
> > const struct phy_ops #name_phy_ops = {
> > 
> > macro ? This will force people to add the const keyword :-)
> 
> Forcing people to use const structures is good, but I think it would be
> better without the macro, just by marking the argument in 
> devm_phy_create() as const.

that won't force the definition of the struct to be const, however. But
I get your point.

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130403/661c611c/attachment-0001.sig>

From alexey.pelykh at gmail.com  Wed Apr  3 11:55:12 2013
From: alexey.pelykh at gmail.com (Alexey Pelykh)
Date: Wed, 3 Apr 2013 18:55:12 +0300
Subject: [PATCH] Revert "OMAP/serial: Fix incorrect Rx FIFO threshold
 setting, LSR validation on Tx, and Tx FIFO IRQ generation"
In-Reply-To: <CAOmKuSqd=gNYFutpgDref58pbAbDwDin4mvL_OEooD1XuwKtgQ@mail.gmail.com>
References: <alpine.DEB.2.00.1304010519260.28273@utopia.booyaka.com>
 <CAOmKuSpttQJmrL=Htiz-Zc4voAF7CnG_GQYAO2onKpauwYjtvw@mail.gmail.com>
 <alpine.DEB.2.00.1304010844100.28273@utopia.booyaka.com>
 <CAOmKuSrABrPcZ=Yg1+LAHWbh9CdTYR0eUmJ2dd3z91oz0uu21g@mail.gmail.com>
 <alpine.DEB.2.00.1304011008230.28273@utopia.booyaka.com>
 <CAOmKuSrbDc025Tj9xsqDebJ_KZdp_VnWAOs_OO5UAegV43JcDQ@mail.gmail.com>
 <CAOmKuSpbaKutLxbNihBRDz+B0Wt0XiPss-PcEHc-efCTvciNFg@mail.gmail.com>
 <alpine.DEB.2.00.1304011654520.9148@utopia.booyaka.com>
 <CAOmKuSo4onVtk2Ke-i+0_1Ych33KuUYspRy+cySRHf4yWB5XDw@mail.gmail.com>
 <alpine.DEB.2.00.1304021821190.27146@utopia.booyaka.com>
 <CAOmKuSqd=gNYFutpgDref58pbAbDwDin4mvL_OEooD1XuwKtgQ@mail.gmail.com>
Message-ID: <CAOmKuSp8nPJw7+LKK3ny7ZjEEV-CeDjGg0GD2fDjZiP6HBKGGw@mail.gmail.com>

Paul,

Should I start a new email chain with that patch or add it here?

On Wed, Apr 3, 2013 at 12:19 AM, Alexey Pelykh <alexey.pelykh at gmail.com> wrote:
> Hi Paul,
>
> No problem, I'll prepare patch in next 24 hours and will send in ASAP.
>
> But, since we've found the issue, I suggest that we should look at it
> closer, especially since at this moment only you can reproduce it. As
> far as I understand, but I may be wrong,
> this comment is wrong, since if to specify
> OMAP_UART_SCR_RX_TRIG_GRANU1_MASK, it effectively sets Rx threshold to
> 1 character, instead of 16.
> /* Set receive FIFO threshold to 16 characters and
>  * transmit FIFO threshold to 16 spaces
>  */
>
> On Tue, Apr 2, 2013 at 9:24 PM, Paul Walmsley <paul at pwsan.com> wrote:
>> On Mon, 1 Apr 2013, Alexey Pelykh wrote:
>>
>>> Paul, can you please try to comment out change related to Rx line
>>> (granulation one). That's only Rx line related change in the patch.
>>
>> Yes, looks like simply reverting the commit 1776fd059c40 ("OMAP/serial:
>> Fix incorrect Rx FIFO threshold setting, LSR validation on Tx, and Tx FIFO
>> IRQ generation") change to OMAP_UART_SCR_RX_TRIG_GRANU1_MASK fixes it.
>>
>> Care to send a patch doing so ASAP for v3.9-rc fixes?  That would moot the
>> revert of the entire commit 1776fd059c40.
>>
>>
>> - Paul


From ludovic.desroches at atmel.com  Wed Apr  3 11:05:36 2013
From: ludovic.desroches at atmel.com (Ludovic Desroches)
Date: Wed, 3 Apr 2013 17:05:36 +0200
Subject: [RFC PATCH] at_hdmac: move to generic DMA binding
In-Reply-To: <201304031325.49813.arnd@arndb.de>
References: <1364994863-7347-1-git-send-email-=ludovic.desroches@atmel.com>
 <201304031325.49813.arnd@arndb.de>
Message-ID: <20130403150536.GC9234@ludovic.desroches@atmel.com>

On Wed, Apr 03, 2013 at 01:25:49PM +0000, Arnd Bergmann wrote:
> On Wednesday 03 April 2013, =ludovic.desroches at atmel.com wrote:
> > +
> > +DMA clients connected to the Atmel DMA controller must use the format
> > +described in the dma.txt file, using a four-cell specifier for each channel.
> > +The four cells in order are:
> > +
> > +1. A phandle pointing to the DMA controller
> > +2. The memory interface (16 most significant bits), the peripheral interface
> > +(16 less significant bits)
> > 
> > Most of our products have only one memory interface which is the interface 0
> > from the dma controller point of view. The SAMA5D3 family is the only one to
> > have two memory interfaces (0 and 1) so the peripheral interface is interface 2
> > instead of interface 1.
> > Since it will concern only one device family, I think it is better to put both
> > interfaces in the same cell.
> 
> Seems reasonable.
> 
> > +3. The peripheral identifier (can be different for tx and rx)
> > +4. The chunk transfer size, must be 1, 4, 8 or 16
> 
> I wonder if the chunk transfer size should instead be set using
> dmaengine_slave_config(). Is this something that you need to have
> configured at the platform level, or can it be hardcoded into the
> slave driver independent of where that slave is being used?

You are right about the use of dmaengine_slave_config.

I was thinking about mci case where we set the chunk transfer size to one
because of issues when using SDIO. So it could be interesting to have this
value in the device tree in order to let the user choose the chunk transfer
size according to its use case. Maybe it is not the right place.


Ludovic


From pawel.moll at arm.com  Wed Apr  3 12:06:17 2013
From: pawel.moll at arm.com (Pawel Moll)
Date: Wed, 03 Apr 2013 17:06:17 +0100
Subject: [PATCH 04/10] arm: zynq: Load scu baseaddress at run time
In-Reply-To: <CAHTX3dKD4G0E8qoxTR2HnJVdagoeOerM+TiZzkJUPjcGwYdX_Q@mail.gmail.com>
References: <1364219596-4954-1-git-send-email-michal.simek@xilinx.com>
 <1364219596-4954-4-git-send-email-michal.simek@xilinx.com>
 <515059D4.5070903@gmail.com>
 <CAHTX3dJfvFNNuyJC54fS=NCpRxovVsxHTss8wJd_QOB2PaxL7g@mail.gmail.com>
 <51506F31.2080709@gmail.com>
 <CAHTX3d+1auKVLko+LKAA+a4rh4Rfw19ggzmS7DhvYuuCAWUwHA@mail.gmail.com>
 <1364920809.3019.30.camel@hornet>
 <CAHTX3dKD4G0E8qoxTR2HnJVdagoeOerM+TiZzkJUPjcGwYdX_Q@mail.gmail.com>
Message-ID: <1365005177.26858.11.camel@hornet>

On Wed, 2013-04-03 at 07:33 +0100, Michal Simek wrote:
> The point is different. Was there any reason why you used this static
> mapping
> and then dynamic?
> This code:
>         iotable_init(&vexpress_dt_cortex_a9_scu_map, 1);
>         vexpress_dt_cortex_a9_scu_base = ioremap(phys_addr, SZ_256);

The SCU code is being used very early - too early for "normal" ioremap()
(one problem I'm aware of is lack of kmalloc, but there may be more). So
the static mapping is required. Now, traditionally there was some (more
or less cryptic) pointer arithmetic was used (eg. "base = map_virt_addr
+ 0x100"). I'm sure some would argue it's fine, but I personally dislike
it. Then Nico Pitre's patches made the ioremap() aware of the static
mappings so it will reuse them when possible. Of course it would be
better to be able to do normal ioremap() without any tricks, but it's
another story and I don't feel like discussing it.

So, to summarize, the static mapping is there to make the ioremap()
possible in the first place. If your ioremap() works without it (which
means that you're doing it late enough) you can ignore the
iotable_init() completely.

Does this answer the question?

Pawe?





From g.liakhovetski at gmx.de  Wed Apr  3 12:13:55 2013
From: g.liakhovetski at gmx.de (Guennadi Liakhovetski)
Date: Wed,  3 Apr 2013 18:13:55 +0200
Subject: [PATCH/RFC 2/3] ARM: shmobile: initialise clock early on
 kzm9g-reference
In-Reply-To: <1365005636-17526-1-git-send-email-g.liakhovetski@gmx.de>
References: <1365005636-17526-1-git-send-email-g.liakhovetski@gmx.de>
Message-ID: <1365005636-17526-3-git-send-email-g.liakhovetski@gmx.de>

To prepare to enable TWD on kzm9g-reference, clock initialisation has to be
done early. Move it from .init_machine to .init_time stage.

Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas at gmail.com>
---
 arch/arm/mach-shmobile/board-kzm9g-reference.c |    8 +++++++-
 arch/arm/mach-shmobile/setup-sh73a0.c          |   13 +++++++++----
 2 files changed, 16 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-shmobile/board-kzm9g-reference.c b/arch/arm/mach-shmobile/board-kzm9g-reference.c
index aefa50d..0f9b276 100644
--- a/arch/arm/mach-shmobile/board-kzm9g-reference.c
+++ b/arch/arm/mach-shmobile/board-kzm9g-reference.c
@@ -90,6 +90,12 @@ static void __init kzm_init(void)
 #endif
 }
 
+static void __init timer_init(void)
+{
+	sh73a0_clock_init();
+	shmobile_timer_init();
+}
+
 static const char *kzm9g_boards_compat_dt[] __initdata = {
 	"renesas,kzm9g-reference",
 	NULL,
@@ -102,6 +108,6 @@ DT_MACHINE_START(KZM9G_DT, "kzm9g-reference")
 	.nr_irqs	= NR_IRQS_LEGACY,
 	.init_irq	= irqchip_init,
 	.init_machine	= kzm_init,
-	.init_time	= shmobile_timer_init,
+	.init_time	= timer_init,
 	.dt_compat	= kzm9g_boards_compat_dt,
 MACHINE_END
diff --git a/arch/arm/mach-shmobile/setup-sh73a0.c b/arch/arm/mach-shmobile/setup-sh73a0.c
index 0469e84..8a1bc1c 100644
--- a/arch/arm/mach-shmobile/setup-sh73a0.c
+++ b/arch/arm/mach-shmobile/setup-sh73a0.c
@@ -1018,9 +1018,6 @@ void __init sh73a0_add_standard_devices_dt(void)
 {
 	struct platform_device_info devinfo = { .name = "cpufreq-cpu0", .id = -1, };
 
-	/* clocks are setup late during boot in the case of DT */
-	sh73a0_clock_init();
-
 	platform_add_devices(sh73a0_devices_dt,
 			     ARRAY_SIZE(sh73a0_devices_dt));
 	of_platform_populate(NULL, of_default_bus_match_table,
@@ -1030,6 +1027,14 @@ void __init sh73a0_add_standard_devices_dt(void)
 	platform_device_register_full(&devinfo);
 }
 
+static void __init add_standard_devices(void)
+{
+	/* clocks are setup late during boot in the case of DT */
+	sh73a0_clock_init();
+
+	sh73a0_add_standard_devices_dt();
+}
+
 static const char *sh73a0_boards_compat_dt[] __initdata = {
 	"renesas,sh73a0",
 	NULL,
@@ -1041,7 +1046,7 @@ DT_MACHINE_START(SH73A0_DT, "Generic SH73A0 (Flattened Device Tree)")
 	.init_early	= sh73a0_init_delay,
 	.nr_irqs	= NR_IRQS_LEGACY,
 	.init_irq	= irqchip_init,
-	.init_machine	= sh73a0_add_standard_devices_dt,
+	.init_machine	= add_standard_devices,
 	.init_time	= shmobile_timer_init,
 	.dt_compat	= sh73a0_boards_compat_dt,
 MACHINE_END
-- 
1.7.2.5



From g.liakhovetski at gmx.de  Wed Apr  3 12:13:54 2013
From: g.liakhovetski at gmx.de (Guennadi Liakhovetski)
Date: Wed,  3 Apr 2013 18:13:54 +0200
Subject: [PATCH 1/3] ARM: also support TWD clock,
 instantiated from platform data
In-Reply-To: <1365005636-17526-1-git-send-email-g.liakhovetski@gmx.de>
References: <1365005636-17526-1-git-send-email-g.liakhovetski@gmx.de>
Message-ID: <1365005636-17526-2-git-send-email-g.liakhovetski@gmx.de>

While gradually switching clock initialisation to DT some architectures
can have TWD device in DT, but supplying clock initialised from platform
data. This patch adds support for such configurations to ARM.

Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas at gmail.com>
Cc: Russell King <linux at arm.linux.org.uk>
---
 arch/arm/kernel/smp_twd.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/kernel/smp_twd.c b/arch/arm/kernel/smp_twd.c
index 3f25650..8f12aa3 100644
--- a/arch/arm/kernel/smp_twd.c
+++ b/arch/arm/kernel/smp_twd.c
@@ -244,7 +244,7 @@ static void twd_get_clock(struct device_node *np)
 
 	if (np)
 		twd_clk = of_clk_get(np, 0);
-	else
+	if (IS_ERR(twd_clk))
 		twd_clk = clk_get_sys("smp_twd", NULL);
 
 	if (IS_ERR(twd_clk)) {
-- 
1.7.2.5



From g.liakhovetski at gmx.de  Wed Apr  3 12:13:53 2013
From: g.liakhovetski at gmx.de (Guennadi Liakhovetski)
Date: Wed,  3 Apr 2013 18:13:53 +0200
Subject: [PATCH/RFC 0/3] ARM: shmobile: kzm9g-reference: enable TWD
Message-ID: <1365005636-17526-1-git-send-email-g.liakhovetski@gmx.de>

The first patch in this series is required for the result to work, but is 
modifying a generic driver, so, it should be considered separately, and if 
accepted, it can be applied separately too. Patches 2 and 3 are RFC, 
because I'm not sure, whether this is indeed the right way to enable TWD 
on kzm9g-reference.

Cc: Guennadi Liakhovetski <g.liakhovetski+renesas at gmail.com>

Guennadi Liakhovetski (3):
  ARM: also support TWD clock, instantiated from platform data
  ARM: shmobile: initialise clock early on kzm9g-reference
  ARM: shmobile: kzm9g-reference: add a TWD DT node

 arch/arm/boot/dts/sh73a0-kzm9g-reference.dts   |    7 +++++++
 arch/arm/kernel/smp_twd.c                      |    2 +-
 arch/arm/mach-shmobile/board-kzm9g-reference.c |    8 +++++++-
 arch/arm/mach-shmobile/setup-sh73a0.c          |   13 +++++++++----
 4 files changed, 24 insertions(+), 6 deletions(-)

-- 
1.7.2.5

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/


From g.liakhovetski at gmx.de  Wed Apr  3 12:13:56 2013
From: g.liakhovetski at gmx.de (Guennadi Liakhovetski)
Date: Wed,  3 Apr 2013 18:13:56 +0200
Subject: [PATCH/RFC 3/3] ARM: shmobile: kzm9g-reference: add a TWD DT node
In-Reply-To: <1365005636-17526-1-git-send-email-g.liakhovetski@gmx.de>
References: <1365005636-17526-1-git-send-email-g.liakhovetski@gmx.de>
Message-ID: <1365005636-17526-4-git-send-email-g.liakhovetski@gmx.de>

This patch enables the use of TWD on kzm9g-reference.

Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas at gmail.com>
---
 arch/arm/boot/dts/sh73a0-kzm9g-reference.dts |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/sh73a0-kzm9g-reference.dts b/arch/arm/boot/dts/sh73a0-kzm9g-reference.dts
index b6f759e..ed9dd45 100644
--- a/arch/arm/boot/dts/sh73a0-kzm9g-reference.dts
+++ b/arch/arm/boot/dts/sh73a0-kzm9g-reference.dts
@@ -40,6 +40,13 @@
 		reg = <0x41000000 0x1e800000>;
 	};
 
+	timer at f0000600 {
+		compatible = "arm,cortex-a9-twd-timer";
+		reg = <0xf0000600 0x20>;
+		interrupt-parent = <&gic>;
+		interrupts = <1 13 0x4>;
+	};
+
 	reg_1p8v: regulator at 0 {
 		compatible = "regulator-fixed";
 		regulator-name = "fixed-1.8V";
-- 
1.7.2.5



From shawn.guo at linaro.org  Wed Apr  3 12:02:43 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Thu, 4 Apr 2013 00:02:43 +0800
Subject: [PATCH] ARM: imx: provide twd clock lookup from device tree
Message-ID: <1365004963-27957-1-git-send-email-shawn.guo@linaro.org>

While booting from device tree, imx6q used to provide twd clock lookup
by calling clk_register_clkdev() in clock driver.  However, the commit
bd60345 (ARM: use device tree to get smp_twd clock) forces DT boot to
look up the clock from device tree.  It causes the failure below when
twd driver tries to get the clock, and hence kernel has to calibrate the
local timer frequency.

 smp_twd: clock not found -2
 ...
 Calibrating local timer... 396.13MHz.

Fix the regression by providing twd clock lookup from device tree, and
remove the unused twd clk_register_clkdev() call from clock driver.

Signed-off-by: Shawn Guo <shawn.guo at linaro.org>
---
Arnd, Olof,

This is a fix for 3.9.

Shawn

 arch/arm/boot/dts/imx6qdl.dtsi |    1 +
 arch/arm/mach-imx/clk-imx6q.c  |    1 -
 2 files changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 06ec460..281a223 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -91,6 +91,7 @@
 			compatible = "arm,cortex-a9-twd-timer";
 			reg = <0x00a00600 0x20>;
 			interrupts = <1 13 0xf01>;
+			clocks = <&clks 15>;
 		};
 
 		L2: l2-cache at 00a02000 {
diff --git a/arch/arm/mach-imx/clk-imx6q.c b/arch/arm/mach-imx/clk-imx6q.c
index 2f9ff93..22a3021 100644
--- a/arch/arm/mach-imx/clk-imx6q.c
+++ b/arch/arm/mach-imx/clk-imx6q.c
@@ -443,7 +443,6 @@ int __init mx6q_clocks_init(void)
 
 	clk_register_clkdev(clk[gpt_ipg], "ipg", "imx-gpt.0");
 	clk_register_clkdev(clk[gpt_ipg_per], "per", "imx-gpt.0");
-	clk_register_clkdev(clk[twd], NULL, "smp_twd");
 	clk_register_clkdev(clk[cko1_sel], "cko1_sel", NULL);
 	clk_register_clkdev(clk[ahb], "ahb", NULL);
 	clk_register_clkdev(clk[cko1], "cko1", NULL);
-- 
1.7.9.5




From linux at arm.linux.org.uk  Wed Apr  3 12:19:55 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Wed, 3 Apr 2013 17:19:55 +0100
Subject: [PATCH v1] ARM: keep __my_cpu_offset consistent with generic one
In-Reply-To: <20130312105638.GQ4977@n2100.arm.linux.org.uk>
References: <1362663356-21151-1-git-send-email-tom.leiming@gmail.com>
 <CACVXFVOhr222CVrzkVP_oLgVkdReD9BXXSBg7fmp6Wvx9_peCw@mail.gmail.com>
 <20130312105638.GQ4977@n2100.arm.linux.org.uk>
Message-ID: <20130403161955.GE17995@n2100.arm.linux.org.uk>

On Tue, Mar 12, 2013 at 10:56:38AM +0000, Russell King - ARM Linux wrote:
> On Tue, Mar 12, 2013 at 10:32:21AM +0800, Ming Lei wrote:
> > On Thu, Mar 7, 2013 at 9:35 PM, Ming Lei <tom.leiming at gmail.com> wrote:
> > > Commit 14318efb(ARM: 7587/1: implement optimized percpu variable access)
> > > introduces arm's __my_cpu_offset to optimize percpu vaiable access,
> > > which really works well on hackbench, but will cause __my_cpu_offset
> > > to return garbage value before it is initialized in cpu_init() called
> > > by setup_arch, so accessing percpu variable before setup_arch may cause
> > > kernel hang. But generic __my_cpu_offset always returns zero before
> > > percpu area is brought up, and won't hang kernel.
> > >
> > > So the patch tries to clear __my_cpu_offset on boot CPU early
> > > to avoid boot hang.
> > >
> > > At least now percpu variable is accessed by lockdep before
> > > setup_arch(), and enabling CONFIG_LOCK_STAT or CONFIG_DEBUG_LOCKDEP
> > > can trigger kernel hang.
> > >
> > > Cc: Peter Zijlstra <peterz at infradead.org>
> > > Cc: Ingo Molnar <mingo at redhat.com>
> > > Cc: Rob Herring <rob.herring at calxeda.com>
> > > Cc: Will Deacon <will.deacon at arm.com>
> > > Cc: Nicolas Pitre <nico at linaro.org>
> > > Cc: Russell King <rmk+kernel at arm.linux.org.uk>
> > > Signed-off-by: Ming Lei <tom.leiming at gmail.com>
> > > ---
> > > V1:
> > >         - documents lockdep uses percpu variable early
> > 
> > Looks no one objects the patch, so I has submitted it into Russell's
> > patch system, and hope it can be pushed to linus tree soon and
> > make LOCK_STAT/DEBUG_LOCKDEP usable on ARMv7.
> 
> I'm not convinced it is correct.  Is the percpu data as stored in the
> kernel image (in other words, at offset zero) supposed to be read only?
> If so, the above means that we'll be accessing that rather than the
> copy of the percpu data we should be accessing.
> 
> The percpu data areas are allocated by setup_per_cpu_areas() - that's
> where we should be initializing this, just like it's done on PowerPC.

Still not convinced this is a proper fix.  Look, the problem is this:

- Initially, set the CPU percpu offset to zero.  This means the boot
  CPU reads and writes to the percpu data section in the kernel image.

- The percpu areas are initialized, and the percpu data copied to each
  percpu data - this will have any writes from the boot CPU included as
  changes to the percpu data.

- The boot CPU continues to read/write to the percpu data section.

- If the boot CPU suspends/resumes, cpu_init() gets called, which will
  call set_my_cpu_offset(per_cpu_offset(cpu)); for the boot CPU.

- The boot CPU now uses the allocated percpu data section and any
  updates it did in the percpu data section in the kernel image are
  lost to it.

Your patch may be right on its own to solve the initial problem, but
it leaves a _big_ hole.

Now, the big question here: is it right that the boot CPU should ever
write to the static percpu data section in the kernel image?  What if
there's a pointer in there, initially NULL, which then gets checked
by each CPU and initialized if NULL - we'll end up sharing the same
allocation amongst all CPUs, which probably isn't what was intended.
If there's a list_head which gets added to, that too will be very bad.

Although you have uncovered a problem, I still think by setting the
offset to zero initially, you're just papering over a much bigger
can of worms.

So, should percpu data be used this early in boot before the percpu
stuff is properly initialized?  That feels _extremely_ unsafe.

This, I think, needs to be addressed properly.  And part of that is
knowing where things went wrong.  Will Deacon asked you for a backtrace
showing where this problem occured.  Your response seems to be to
resend the patch with a "v1" tag a no new information.

Sorry, not applying this until the above issue has been discussed
and the location of these percpu accesses has been properly analysed.


From linus.walleij at linaro.org  Wed Apr  3 12:29:03 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Wed, 3 Apr 2013 18:29:03 +0200
Subject: [PATCH V5 1/9] gpio: tegra: add gpio wakeup source handling
In-Reply-To: <1364901613-25080-2-git-send-email-josephl@nvidia.com>
References: <1364901613-25080-1-git-send-email-josephl@nvidia.com>
 <1364901613-25080-2-git-send-email-josephl@nvidia.com>
Message-ID: <CACRpkdYOLuUyBu7ER7hqLGZnAoYS0Z7XJ6LC2=ec3vxKzF1rqA@mail.gmail.com>

On Tue, Apr 2, 2013 at 1:20 PM, Joseph Lo <josephl at nvidia.com> wrote:
> This patch ad
d the gpio wakeup source handling for the Tegra platform. It
> was be done by enabling the irq for the gpio in the gpio controller and
> enabling the bank irq of the gpio in the Tegra legacy irq controller when
> the system going to suspend.
>
> Based on the work by:
> Varun Wadekar <vwadekar at nvidia.com>
>
> Cc: Grant Likely <grant.likely at secretlab.ca>
> Cc: Linus Walleij <linus.walleij at linaro.org>
> Signed-off-by: Joseph Lo <josephl at nvidia.com>
> Acked-by: Linus Walleij <linus.walleij at linaro.org>
> ---
> V5:
> * no change
> V4:
> * no change
> V3:
> * no change
> V2:
> * no change

Shall I just apply this to the GPIO tree to stop these repetitive mails
from coming?

Yours,
Linus Walleij


From soren.brinkmann at xilinx.com  Wed Apr  3 12:31:14 2013
From: soren.brinkmann at xilinx.com (=?utf-8?B?U8O2cmVu?= Brinkmann)
Date: Wed, 3 Apr 2013 09:31:14 -0700
Subject: [PATCH] clk: divider: Introduce CLK_DIVIDER_ALLOW_ZERO flag
In-Reply-To: <20130403154027.8177.58419@quantum>
References: <1364942216-4575-1-git-send-email-soren.brinkmann@xilinx.com>
 <20130403154027.8177.58419@quantum>
Message-ID: <8fd6da66-dd3b-4e02-b958-095dee577330@VA3EHSMHS017.ehs.local>

On Wed, Apr 03, 2013 at 08:40:27AM -0700, Mike Turquette wrote:
> Quoting Soren Brinkmann (2013-04-02 15:36:56)
> > Dividers which have CLK_DIVIDER_ONE_BASED set have a redundant state,
> > being a divider value of zero. Some hardware implementations allow a
> > zero divider which simply doesn't alter the frequency. I.e. it acts like
> > a divide by one or bypassing the divider.
> > This flag is used to handle such HW in the clk-divider model.
> > 
> > Signed-off-by: Soren Brinkmann <soren.brinkmann at xilinx.com>
> 
> This version looks good.  Taken into clk-next.
Thanks.

	S?ren




From linus.walleij at linaro.org  Wed Apr  3 12:31:58 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Wed, 3 Apr 2013 18:31:58 +0200
Subject: [PATCHv7 00/17] PCIe support for the Armada 370 and Armada XP SoCs
In-Reply-To: <20130403142712.160be55e@skate>
References: <1364395234-11195-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <20130403142712.160be55e@skate>
Message-ID: <CACRpkdYbxXqP_KdcfUFCU4ZyNLn3SmLYcio5QgPqE=zLP7FV2w@mail.gmail.com>

On Wed, Apr 3, 2013 at 2:27 PM, Thomas Petazzoni
<thomas.petazzoni at free-electrons.com> wrote:

> Bjorn, Rob, Grant, Russell,
>
> Through this e-mail, I'd like to send you a kind reminder about this
> patch series. The latest version has been sent a week ago, and there
> has been only minor changes requested since v4 sent early March, i.e a
> month ago. Therefore, I would hope for this series to enter 3.10.
>
> But this patch set is touching areas you are the maintainer for, so I
> would appreciate if you could do a formal review and give your comments
> or your Ack. I would especially appreciate if you do so in the very
> near future, so that if there are comments, I'll have the time to fix
> them and resubmit and updated version in time.
>
> Here are the patches, classified by maintainer area:

FYI I have applied patches 1 thru 3 and converted my PCI DT series
for the Integrator to use the new infrastructure, so you can add
Tested-by: Linus Walleij <linus.walleij at linaro.org>
on these if you wish. (Working fine.)

The Integrator PCI DT work is dependent on these patches so I
also have a strong interest to have them merged somewhere so I
can submit my series against them...

Yours,
Linus Walleij


From davem at davemloft.net  Wed Apr  3 12:33:03 2013
From: davem at davemloft.net (David Miller)
Date: Wed, 03 Apr 2013 12:33:03 -0400 (EDT)
Subject: [PATCH v4 0/6] Generic PHY Framework
In-Reply-To: <515BCDB2.2040506@ti.com>
References: <515BC559.1070602@ti.com>
 <20130403.023157.1254170239558661397.davem@davemloft.net>
 <515BCDB2.2040506@ti.com>
Message-ID: <20130403.123303.544482473271388131.davem@davemloft.net>

From: Kishon Vijay Abraham I <kishon at ti.com>
Date: Wed, 3 Apr 2013 12:05:30 +0530

> This patch series is about drivers/phy which will be used for now by
> usb, sata and maybe some video PHY's. Network itself has a
> comprehensive PHY in drivers/net/phy which we'd like to merge it with
> drivers/phy so that we have all the phy stuff in drivers/phy but we
> are not planning too far ahead here.

Ok, that makes sense, thanks.


From linux at arm.linux.org.uk  Wed Apr  3 12:37:12 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Wed, 3 Apr 2013 17:37:12 +0100
Subject: [PATCH] ARM: Only initialize max_mapnr when using flatmem
In-Reply-To: <20130108164640.GA30493@n2100.arm.linux.org.uk>
References: <1350935514-27422-1-git-send-email-spang@chromium.org>
 <20130108164640.GA30493@n2100.arm.linux.org.uk>
Message-ID: <20130403163712.GF17995@n2100.arm.linux.org.uk>

On Tue, Jan 08, 2013 at 04:46:40PM +0000, Russell King - ARM Linux wrote:
> On Mon, Oct 22, 2012 at 03:51:54PM -0400, Michael Spang wrote:
> > The expression used to initialize max_mapnr is not appropriate for
> > sparsemem, since mem_map is NULL and pfn_to_page() only works on valid
> > pages. This patch leaves max_mapnr uninitialized for sparsemem.
> > 
> > For flatmem, the expression simplifies to copying max_pfn.
> > 
> > Signed-off-by: Michael Spang <spang at chromium.org>
> > ---
> >  arch/arm/mm/init.c |    4 +++-
> >  1 files changed, 3 insertions(+), 1 deletions(-)
> > 
> > I'm not sure we need this variable it all - it looks like there are no
> > users.
> 
> Indeed, I've just confirmed that. I suggest we just get rid of it instead,
> like this:
> 
>  arch/arm/mm/init.c |    6 +++++-
>  1 files changed, 5 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
> index ad722f1..bd93bdc 100644
> --- a/arch/arm/mm/init.c
> +++ b/arch/arm/mm/init.c
> @@ -600,7 +600,11 @@ void __init mem_init(void)
>  	extern u32 itcm_end;
>  #endif
>  
> -	max_mapnr   = pfn_to_page(max_pfn + PHYS_PFN_OFFSET) - mem_map;
> +	/*
> +	 * We used to initialize max_mapnr here to be the same as max_pfn,
> +	 * but as nothing uses it (we don't use the generic pfn_valid())
> +	 * this has become unnecessary.
> +	 */
>  
>  	/* this will put all unused low memory onto the freelists */
>  	free_unused_memmap(&meminfo);
> 

I notice there wasn't a response to this, and the patch is in the patch
system.  I'm going to discard that patch now, and assume that this issue
is dead.  Thanks.


From linus.walleij at linaro.org  Wed Apr  3 12:39:34 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Wed, 3 Apr 2013 18:39:34 +0200
Subject: [PATCH 1/6] pinctrl: add pinctrl driver for imx6dl
In-Reply-To: <1364913079-26039-2-git-send-email-shawn.guo@linaro.org>
References: <1364913079-26039-1-git-send-email-shawn.guo@linaro.org>
 <1364913079-26039-2-git-send-email-shawn.guo@linaro.org>
Message-ID: <CACRpkdaoVSHQg11E6W-hVyU6ud51yoQQ8-SrgnrmiO47JqJdrg@mail.gmail.com>

On Tue, Apr 2, 2013 at 4:31 PM, Shawn Guo <shawn.guo at linaro.org> wrote:

> The imx6dl is a derivative of imx6q with very limited difference.  These
> two SoCs are so compatible that they can be handled as one platform in
> software.  That said, we will not have target SOC_IMX6DL but just
> reusing SOC_IMX6Q.   That's why the pinctrl-imx6dl driver is added here
> with symbol PINCTRL_IMX6Q controlling the build of it.
>
> Signed-off-by: Shawn Guo <shawn.guo at linaro.org>

OK Acked-by: Linus Walleij <linus.walleij at linaro.org>

Also for patch 2.

Will you take this through the Freescale tree?

Yours,
Linus Walleij


From linus.walleij at linaro.org  Wed Apr  3 12:42:58 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Wed, 3 Apr 2013 18:42:58 +0200
Subject: [PATCH 0/6] Add initial imx6dl support
In-Reply-To: <1364913079-26039-1-git-send-email-shawn.guo@linaro.org>
References: <1364913079-26039-1-git-send-email-shawn.guo@linaro.org>
Message-ID: <CACRpkdYdturHtm5sdaE4WEX8ZR-6uHcCJ+_X+xdMSCb1DEDv6A@mail.gmail.com>

On Tue, Apr 2, 2013 at 4:31 PM, Shawn Guo <shawn.guo at linaro.org> wrote:

> The i.MX6 DualLite/Solo (imx6dl) is a derivative of i.MX6 Quad/Dual
> (imx6q).  These two chips are highly compatible.  The series adds the
> initial imx6dl support based on imx6q base.
>
> Linus,
>
> The first two patches has dependency on patch "pinctrl: imx: move
> hard-coding data into device tree", which is sitting on IMX tree.  So
> can you please give your ACK for me to take them through the same tree?

Just did, sorry for delays. Thanks!

Yours,
Linus Walleij


From swarren at wwwdotorg.org  Wed Apr  3 12:44:38 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Wed, 03 Apr 2013 10:44:38 -0600
Subject: Query on pinctrl usage for DT nodes
In-Reply-To: <CA+V-a8uiPwsAD--OHFAE=i2ed+-wbXm4p2deZXr92+Zv6GDS1w@mail.gmail.com>
References: <CA+V-a8uiPwsAD--OHFAE=i2ed+-wbXm4p2deZXr92+Zv6GDS1w@mail.gmail.com>
Message-ID: <515C5C76.3080009@wwwdotorg.org>

On 04/03/2013 03:16 AM, Prabhakar Lad wrote:
> Hi Linus/Stephen,
> 
> I am working adding  DT nodes for DA850.
> 
> Following is the pin control snippet of da850.dtsi:-
> 
> 		pmx_core: pinmux at 1c14120 {
...
>                         i2c0_pins: pinmux_i2c0_pins {
>                                 pinctrl-single,bits = <
>                                         /* I2C0_SDA,I2C0_SCL */
>                                         0x10 0x00002200 0x0000ff00
>                                 >;
>                         };
>                         mdio_pins: pinmux_mdio_pins {
>                                 pinctrl-single,bits = <
>                                         /* MDIO_CLK, MDIO_D */
>                                         0x10 0x00000088 0x000000ff
>                                 >;
>                         };
>                 }
> 
> And following is the code snippet for dts:-
> 
> 		i2c0: i2c at 1c22000 {
> 			status = "okay";
> 			clock-frequency = <100000>;
> 			pinctrl-names = "default";
> 			pinctrl-0 = <&i2c0_pins>;
> 		};
> 		mdio: mdio at 1e24000 {
> 			status = "okay";
> 			bus_freq = <2200000>;
> 			pinctrl-names = "default";

I assume there's also the following there:

			pinctrl-0 = <&mdio_pins>;

>               };
> 		
> But while booting I see the following boot log:-
> ...
> cpuidle: using governor menu
> TCP: cubic registered
> NET: Registered protocol family 17
> pinctrl-single 1c14120.pinmux: pin 1c14130 already requested by
> davinci_mdio.0; cannot claim for i2c_davinci.1
> pinctrl-single 1c14120.pinmux: pin-4 (i2c_davinci.1) status -22
> pinctrl-single 1c14120.pinmux: could not request pin 4 on device pinctrl-single
> console [netcon0] enabled
> ....
> 
> This is because the mdio and i2c are using same pin 0x10,

How can two devices use the same pin? I mean physically, in hardware?

Is this because pinctrl-single uses the register address as the pin
number, whereas you have registers which configure multiple pins at
once? If so, your hardware isn't something that can be represented by
pinctrl-single.

> Is there any
> alternative way to handle if the two node's are using same pins any
> pointers could be very much helpful ?



From swarren at wwwdotorg.org  Wed Apr  3 12:51:32 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Wed, 03 Apr 2013 10:51:32 -0600
Subject: [PATCH 5/9] ARM: tegra2: cpuidle: change driver initialization
In-Reply-To: <1364610152.2622.3.camel@jlo-ubuntu-64.nvidia.com>
References: <1364553095-25110-1-git-send-email-daniel.lezcano@linaro.org>
 <1364553095-25110-5-git-send-email-daniel.lezcano@linaro.org>
 <1364610152.2622.3.camel@jlo-ubuntu-64.nvidia.com>
Message-ID: <515C5E14.3070202@wwwdotorg.org>

On 03/29/2013 08:22 PM, Joseph Lo wrote:
> On Fri, 2013-03-29 at 18:31 +0800, Daniel Lezcano wrote:
>> Initialize the idle states directly in the driver structure.
>>
>> That prevents extra structure declaration and memcpy at init time.
>>
>> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
> 
> Hi Daniel,
> 
> Thank you.
> 
> Both the 5th and 6th patch,
> 
> Reviewed-by: Joseph Lo <josephl at nvidia.com>

Thanks. Those same two patches therefore,

Acked-by: Stephen Warren <swarren at nvidia.com>



From swarren at wwwdotorg.org  Wed Apr  3 12:52:19 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Wed, 03 Apr 2013 10:52:19 -0600
Subject: [PATCH V5 1/9] gpio: tegra: add gpio wakeup source handling
In-Reply-To: <CACRpkdYOLuUyBu7ER7hqLGZnAoYS0Z7XJ6LC2=ec3vxKzF1rqA@mail.gmail.com>
References: <1364901613-25080-1-git-send-email-josephl@nvidia.com>
 <1364901613-25080-2-git-send-email-josephl@nvidia.com>
 <CACRpkdYOLuUyBu7ER7hqLGZnAoYS0Z7XJ6LC2=ec3vxKzF1rqA@mail.gmail.com>
Message-ID: <515C5E43.1080904@wwwdotorg.org>

On 04/03/2013 10:29 AM, Linus Walleij wrote:
> On Tue, Apr 2, 2013 at 1:20 PM, Joseph Lo <josephl at nvidia.com> wrote:
>> This patch ad
> d the gpio wakeup source handling for the Tegra platform. It
>> was be done by enabling the irq for the gpio in the gpio controller and
>> enabling the bank irq of the gpio in the Tegra legacy irq controller when
>> the system going to suspend.
>>
>> Based on the work by:
>> Varun Wadekar <vwadekar at nvidia.com>
>>
>> Cc: Grant Likely <grant.likely at secretlab.ca>
>> Cc: Linus Walleij <linus.walleij at linaro.org>
>> Signed-off-by: Joseph Lo <josephl at nvidia.com>
>> Acked-by: Linus Walleij <linus.walleij at linaro.org>
>> ---
>> V5:
>> * no change
>> V4:
>> * no change
>> V3:
>> * no change
>> V2:
>> * no change
> 
> Shall I just apply this to the GPIO tree to stop these repetitive mails
> from coming?

It's part of a series where other patches are being rev'd. I'll apply it
to the Tegra tree with the series once it's final.



From linus.walleij at linaro.org  Wed Apr  3 12:52:51 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Wed, 3 Apr 2013 18:52:51 +0200
Subject: [PATCH v2 12/13] ARM: move sp804 and integrator timers to
 drivers/clocksource
In-Reply-To: <515B3637.8090603@gmail.com>
References: <1364854883-5961-1-git-send-email-robherring2@gmail.com>
 <1364854883-5961-13-git-send-email-robherring2@gmail.com>
 <515A179A.8020800@linaro.org> <515B3637.8090603@gmail.com>
Message-ID: <CACRpkdb0B1iZrTYuD=3d86_ipSfa23msm-sjanDWQarotHEqZA@mail.gmail.com>

On Tue, Apr 2, 2013 at 9:49 PM, Rob Herring <robherring2 at gmail.com> wrote:
> On 04/01/2013 06:26 PM, John Stultz wrote:

>> So, most of the code here is really clockevent code and not clocksource
>> code. I realize they were combined in the mach directory you're copying
>> them from, but if we're going to move all this code out of the arch
>> directory and into drivers/, I'd like to propose we not dump it all into
>> drivers/clocksource.
>
> Arguably, half the h/w is used for clocksource and half for clockevent
> so it is equal. :) The sp804 and integrator are somewhat separated that
> carving them up may be possible, but there are examples like i.MX timers
> where the implementations are tied more closely together (the clockevent
> compare value is the clocksource counter + delta).
>
> Where do I put the init functions which need to know about both?
>
> What about all the other timers that are already in drivers/clocksource?

The other day I thought about this because I remembered discussing
it with John, and thinking about how some drivers (like ours) combine
clock source, clock event, sched_clock() hook and delay timers. The
same hardware is incidentally used for all four.

Driver writers really like to think about a driver pertaining to a certain
memory segment in the hardware, and that's causing some strain
here and there in the kernel.

Anyway, I was thinking that the four classes of drivers were somehow
related but not the same thing.

So what about renaming
drivers/clocksource -> drivers/timer

Then create a subdirectory drivers/timer/clocksource
for the pure clocksource code and any drivers falling into that
category.

Thus drivers/timer/clockevent, drivers/timer/schedclock
and drivers/timer/delay can be created to handle specialized
hardware blocks.

But the best thing with that scheme would be that combined
drivers doing several things at once could live directly in
drivers/timer/* and not pollute drivers/clocksource.

Yes/No/Insane?

Yours,
Linus Walleij


From linux at arm.linux.org.uk  Wed Apr  3 12:53:53 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Wed, 3 Apr 2013 17:53:53 +0100
Subject: OK to use commit 71856843 as base for further omap clean up?
In-Reply-To: <20130326232200.GQ30923@n2100.arm.linux.org.uk>
References: <20130319175921.GA22104@atomide.com> <5150A60E.2090108@ti.com>
 <20130326232200.GQ30923@n2100.arm.linux.org.uk>
Message-ID: <20130403165353.GW30923@n2100.arm.linux.org.uk>

On Tue, Mar 26, 2013 at 11:22:00PM +0000, Russell King - ARM Linux wrote:
> On Mon, Mar 25, 2013 at 02:31:26PM -0500, Jon Hunter wrote:
> > Hi Russell,
> > 
> > On 03/19/2013 12:59 PM, Tony Lindgren wrote:
> > > Hi Russell,
> > > 
> > > Can we use your commit 71856843 (ARM: OMAP: use consistent error checking)
> > > as an immutable base for further omap dmtimer and gpmc work?
> > 
> > I saw that you updated your clean-up branch. Ok to use the below commit
> > [1] as a base for some v3.10 updates?
> 
> It's still the same commit.  I'm not intending to remove this commit
> from it, so yes, fine, go ahead.

*sigh*.  Actually, 4d485661d799e81f98097057d445f4803cef2af0 is buggered
which is the commit below it.  I said yes too quickly.  Oh well, it'll
just have to be broken for when it hits mainline now.


From broonie at opensource.wolfsonmicro.com  Wed Apr  3 12:57:02 2013
From: broonie at opensource.wolfsonmicro.com (Mark Brown)
Date: Wed, 3 Apr 2013 17:57:02 +0100
Subject: [PATCH 1/2] ASoC: Samsung: return error if drvdata is not set
In-Reply-To: <1364901782-16619-1-git-send-email-padma.v@samsung.com>
References: <1364901782-16619-1-git-send-email-padma.v@samsung.com>
Message-ID: <20130403165702.GB11305@opensource.wolfsonmicro.com>

On Tue, Apr 02, 2013 at 04:53:01PM +0530, Padmavathi Venna wrote:
> From: Prathyush K <prathyush.k at samsung.com>
> 
> This patch fixes a possible crash in case drvdata for the secondary
> device is not set.

Applied both, thanks.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130403/78b589c9/attachment-0001.sig>

From linus.walleij at linaro.org  Wed Apr  3 12:58:36 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Wed, 3 Apr 2013 18:58:36 +0200
Subject: [PATCH] pinctrl: imx5: fix SD2_DATA1 pad AUDMUX_AUD4 configuration
In-Reply-To: <20130403083846.GQ24039@S2101-09.ap.freescale.net>
References: <1364882642-25574-1-git-send-email-marex@denx.de>
 <201304030221.18506.marex@denx.de>
 <20130403052423.GO24039@S2101-09.ap.freescale.net>
 <201304030852.52125.marex@denx.de>
 <20130403083846.GQ24039@S2101-09.ap.freescale.net>
Message-ID: <CACRpkdZpM6z5CDRNXOape_kJShBxSKNvUV0L6cosER16Sn6NbQ@mail.gmail.com>

On Wed, Apr 3, 2013 at 10:38 AM, Shawn Guo <shawn.guo at linaro.org> wrote:
> On Wed, Apr 03, 2013 at 08:52:51AM +0200, Marek Vasut wrote:
>> Dear Shawn Guo,
>>
>> > On Wed, Apr 03, 2013 at 02:21:18AM +0200, Marek Vasut wrote:
>> > > One serving of such patch, coming right up ;-)
>> > >
>> > > btw. do you want to apply this one for -stable or do we just leave it as
>> > > is ?
>> >
>> > If you do not insist, I would say let's leave it as it is, as we
>> > encourage people to upgrade device tree to adopt the new pinctrl
>> > binding.
>>
>> Actually, I have a bad feeling about having an open bug in stable tree. Someone
>> might use that tree and might try to use AUDMUX4 on his (out-of-tree) device and
>> might run into the same problem. Three times 'might' in one sentence doesn't
>> make it sound too likely, but if you have not much trouble with getting it in -
>> stable, please try to.
>
> Ok, it's Linus' call then, since it's a fix that should go via pinctrl
> tree.  Since I will not be able to rebase my 3.10 stuff on -rc7, if the
> patch does not catch up with -rc6, we run into a annoying merge
> conflict during the merge window.

Basically I'm not keen on sending any DT patches as fixes, DT
is at one time supposed to be moved out of the kernel even. I don't
think it qualifies for fixes this late in the merge window.

Besides it's not in a part of the file hierarchy I maintain so I
strongly prefer pure DT patches to go in from the platform trees.
(Subject should be ARM: imx ...)

Please carry this patch in the Freescale tree.

Yours,
Linus Walleij


From pawel.moll at arm.com  Wed Apr  3 13:11:57 2013
From: pawel.moll at arm.com (Pawel Moll)
Date: Wed, 03 Apr 2013 18:11:57 +0100
Subject: [PATCH 04/10] arm: zynq: Load scu baseaddress at run time
In-Reply-To: <CAHTX3dJMpp+E2u-cAeYbqtxC1WAYWpCeRx6W7G=dWDcgzUz5DA@mail.gmail.com>
References: <1364219596-4954-1-git-send-email-michal.simek@xilinx.com>
 <1364219596-4954-4-git-send-email-michal.simek@xilinx.com>
 <515059D4.5070903@gmail.com>
 <CAHTX3dJfvFNNuyJC54fS=NCpRxovVsxHTss8wJd_QOB2PaxL7g@mail.gmail.com>
 <51506F31.2080709@gmail.com>
 <CAHTX3d+1auKVLko+LKAA+a4rh4Rfw19ggzmS7DhvYuuCAWUwHA@mail.gmail.com>
 <1364920809.3019.30.camel@hornet>
 <CAHTX3dKD4G0E8qoxTR2HnJVdagoeOerM+TiZzkJUPjcGwYdX_Q@mail.gmail.com>
 <1365005177.26858.11.camel@hornet>
 <CAHTX3dJMpp+E2u-cAeYbqtxC1WAYWpCeRx6W7G=dWDcgzUz5DA@mail.gmail.com>
Message-ID: <1365009117.26858.14.camel@hornet>

On Wed, 2013-04-03 at 18:04 +0100, Michal Simek wrote:
> Then my question is if you can just remove that ioremap, as I have
> done for zynq,
> without any related problem.

Well, the vexpress platsmp functions are going away soon, replaced by
the generic DT code. When this happen I won't even try to access the
SCU, so both its static mapping and the ioremap will go as well :-)

Pawe?




From dianders at chromium.org  Wed Apr  3 13:20:56 2013
From: dianders at chromium.org (Doug Anderson)
Date: Wed, 3 Apr 2013 10:20:56 -0700
Subject: [PATCH 0/2] These two patches to s3c_pm_arch_prepare_irqs() were
 part of the work
In-Reply-To: <24b501ce3011$454d3c70$cfe7b550$%kim@samsung.com>
References: <1363711900-25560-1-git-send-email-dianders@chromium.org>
 <24b401ce300f$5a767b40$0f6371c0$%kim@samsung.com>
 <24b501ce3011$454d3c70$cfe7b550$%kim@samsung.com>
Message-ID: <CAD=FV=XTMbs9q5FvsFUTmCDrFu7q-ngnS3F94cHNnCRmN3UNLg@mail.gmail.com>

Kukjin,

On Tue, Apr 2, 2013 at 7:16 PM, Kukjin Kim <kgene.kim at samsung.com> wrote:
>> Applied with 1st one, BTW, do you want to send this for stable tree?

I don't have any need for it to be in stable tree.  The ARM Chromebook
hasn't reached critical functionality on any released/upstram Linux
versions so it doesn't make much sense to backport fixes.  If someone
else wants it in stable (and can confirm that it helps them) then I
certainly wouldn't object!


> One more note, just now I discussed Jaecheol Lee about the bit,
> ENABLE_WAKEUP_SW, as the patch fixed, it should be cleared but used to be
> set s3c_irqwake_intmask. Let me check again, then if any updates I'll let
> you know.

OK, thanks.  If there is a reason that ENABLE_WAKEUP_SW needs to be
set then it would be good to understand that case.  :)

-Doug


From linus.walleij at stericsson.com  Wed Apr  3 13:21:23 2013
From: linus.walleij at stericsson.com (Linus Walleij)
Date: Wed, 3 Apr 2013 19:21:23 +0200
Subject: [PATCH] pinctrl/nomadik: add device tree bindings for db8540
Message-ID: <1365009683-3757-1-git-send-email-linus.walleij@stericsson.com>

From: Gabriel Fernandez <gabriel.fernandez at stericsson.com>

This adds a simple device tree binding for db8540 boards.

Signed-off-by: Gabriel Fernandez <gabriel.fernandez at stericsson.com>
Reviewed-by: Philippe Langlais <philippe.langlais at stericsson.com>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 drivers/pinctrl/pinctrl-nomadik.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/pinctrl/pinctrl-nomadik.c b/drivers/pinctrl/pinctrl-nomadik.c
index 267d81c..435bf30 100644
--- a/drivers/pinctrl/pinctrl-nomadik.c
+++ b/drivers/pinctrl/pinctrl-nomadik.c
@@ -2111,6 +2111,10 @@ static const struct of_device_id nmk_pinctrl_match[] = {
 		.compatible = "stericsson,nmk-pinctrl",
 		.data = (void *)PINCTRL_NMK_DB8500,
 	},
+	{
+		.compatible = "stericsson,nmk-pinctrl-db8540",
+		.data = (void *)PINCTRL_NMK_DB8540,
+	},
 	{},
 };
 
-- 
1.7.11.3



From khilman at linaro.org  Wed Apr  3 13:47:23 2013
From: khilman at linaro.org (Kevin Hilman)
Date: Wed, 03 Apr 2013 10:47:23 -0700
Subject: [PATCH 8/9] ARM: omap3: cpuidle: enable time keeping
In-Reply-To: <1364991322-20585-8-git-send-email-daniel.lezcano@linaro.org>
 (Daniel Lezcano's message of "Wed, 3 Apr 2013 14:15:21 +0200")
References: <1364991322-20585-1-git-send-email-daniel.lezcano@linaro.org>
 <1364991322-20585-8-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <87zjxfzetw.fsf@linaro.org>

Daniel Lezcano <daniel.lezcano at linaro.org> writes:

> The TIME_VALID flag is specified for the different states but
> the time residency computation is not done, no tk flag, no time
> computation in the idle function.
>
> Set the en_core_tk_irqen flag to activate it.
>
> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
> Acked-by: Santosh Shilimkar <santosh.shilimkar at ti.com>

Acked-by: Kevin Hilman <khilman at linaro.org>

Also, is this a regression fix that also needs to hit v3.9?

Kevin

> ---
>  arch/arm/mach-omap2/cpuidle34xx.c |    5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/cpuidle34xx.c b/arch/arm/mach-omap2/cpuidle34xx.c
> index 80392fc..4f67a5b 100644
> --- a/arch/arm/mach-omap2/cpuidle34xx.c
> +++ b/arch/arm/mach-omap2/cpuidle34xx.c
> @@ -274,8 +274,9 @@ static int omap3_enter_idle_bm(struct cpuidle_device *dev,
>  static DEFINE_PER_CPU(struct cpuidle_device, omap3_idle_dev);
>  
>  static struct cpuidle_driver omap3_idle_driver = {
> -	.name =		"omap3_idle",
> -	.owner =	THIS_MODULE,
> +	.name             = "omap3_idle",
> +	.owner            = THIS_MODULE,
> +	.en_core_tk_irqen = 1,
>  	.states = {
>  		{
>  			.enter		  = omap3_enter_idle_bm,


From swarren at wwwdotorg.org  Wed Apr  3 13:55:40 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Wed, 03 Apr 2013 11:55:40 -0600
Subject: [PATCH v9 10/14] ARM: tegra: Define Tegra114 CAR binding
In-Reply-To: <1365000110-8916-10-git-send-email-pdeschrijver@nvidia.com>
References: <1365000110-8916-1-git-send-email-pdeschrijver@nvidia.com>
 <1365000110-8916-10-git-send-email-pdeschrijver@nvidia.com>
Message-ID: <515C6D1C.60503@wwwdotorg.org>

On 04/03/2013 08:40 AM, Peter De Schrijver wrote:
> The device tree binding models Tegra114 CAR (Clock And Reset) as a single
> monolithic clock provider.

> diff --git a/Documentation/devicetree/bindings/clock/nvidia,tegra114-car.txt b/Documentation/devicetree/bindings/clock/nvidia,tegra114-car.txt

> +Mux clocks
> +
> +  300	audio0_mux
> +  301	audio1_mux
> +  302	audio2_mux
> +  303	audio3_mux
> +  304	audio4_mux
> +  305	spdif_mux
> +  306	clk_out_1_mux
> +  307	clk_out_2_mux
> +  308	clk_out_3_mux
> +  309	dsia_mux
> +  310	dsib_mux

I think Prashant was expecting those to be removed, and for this series
to rely on "clk: Add composite clock type" instead?


From swarren at wwwdotorg.org  Wed Apr  3 13:52:46 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Wed, 03 Apr 2013 11:52:46 -0600
Subject: [PATCH v9 00/14] Tegra114 clockframework
In-Reply-To: <1365000110-8916-1-git-send-email-pdeschrijver@nvidia.com>
References: <1365000110-8916-1-git-send-email-pdeschrijver@nvidia.com>
Message-ID: <515C6C6E.6060302@wwwdotorg.org>

On 04/03/2013 08:40 AM, Peter De Schrijver wrote:
> This is the nineth version of the Tegra114 clockframework. It is based on the
> next-20130320-fixed branch of
> git://nv-tegra.nvidia.com/user/swarren/linux-2.6.git,

That's not a particularly useful base; these patches won't be applied to
linux-next, but rather to Tegra's for-3.10/clk branch, with the clock
for-next tree merged in to pick up "clk: add table lookup to mux".

> http://patchwork.ozlabs.org/patch/229972/ and

That is "clk: tegra: Don't enable PLLs during early boot". That was
rejected. I assume this isn't really needed given your changelog entry
"Fixed clock initialization for audio", but rather my "clk: tegra: defer
application of init table" should be applied instead?

> http://patchwork.ozlabs.org/patch/229978/ and

For reference, that is "clk: add table lookup to mux", which is in the
clock for-next tree.

> http://patchwork.ozlabs.org/patch/233415/

That is Joseph's "clocksource: tegra: enable arch_timer". Is this
actually a dependency, or an optimization, or ...?

Rob Herring objected to that patch since it isn't necessary if his
series "ARM arch, sp804 and integrator timer CLKSRC_OF support" is applied.

If I apply just your (Peter's) CCF series without Joseph's or Rob's
patches, will everything still work, or is this a hard dependency to
create a working system?


From cov at codeaurora.org  Wed Apr  3 14:01:01 2013
From: cov at codeaurora.org (Christopher Covington)
Date: Wed,  3 Apr 2013 14:01:01 -0400
Subject: [PATCH] arm64: Fix task tracing
Message-ID: <1365012061-31660-1-git-send-email-cov@codeaurora.org>

For accurate accounting call contextidr_thread_switch before a
task is scheduled, rather than after.

Signed-off-by: Christopher Covington <cov at codeaurora.org>
---
 arch/arm64/kernel/process.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
index 0337cdb..c2cc249 100644
--- a/arch/arm64/kernel/process.c
+++ b/arch/arm64/kernel/process.c
@@ -311,11 +311,11 @@ struct task_struct *__switch_to(struct task_struct *prev,
 	fpsimd_thread_switch(next);
 	tls_thread_switch(next);
 	hw_breakpoint_thread_switch(next);
+	contextidr_thread_switch(next);
 
 	/* the actual thread switch */
 	last = cpu_switch_to(prev, next);
 
-	contextidr_thread_switch(next);
 	return last;
 }
 
-- 
Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by the Linux Foundation.



From tony at atomide.com  Wed Apr  3 14:04:47 2013
From: tony at atomide.com (Tony Lindgren)
Date: Wed, 3 Apr 2013 11:04:47 -0700
Subject: [GIT PULL] ARM: OMAP2+: System timer updates
In-Reply-To: <515A3E01.1060308@ti.com>
References: <515A3E01.1060308@ti.com>
Message-ID: <20130403180447.GX10155@atomide.com>

* Jon Hunter <jon-hunter at ti.com> [130401 19:14]:
> The following changes since commit 2d61aecee8f32259920cdf90a452fa26ffc64e9f:
> 
>   Merge commit '6bb27d7349db51b50c40534710fe164ca0d58902' into omap-timer-for-v3.10 (2013-04-01 13:47:29 -0500)
> 
> are available in the git repository at:
> 
> 
>   git://github.com/jonhunter/linux.git omap-timer-for-v3.10
> 
> for you to fetch changes up to 4615943cf3a531bc76f589c22bd366da092b7c0f:
> 
>   ARM: OMAP4+: Fix sparse warning in system timers (2013-04-01 13:49:46 -0500)
> 
> ----------------------------------------------------------------
> This series consists mainly of clean-ups for clockevents and
> clocksource timers on OMAP2+ devices. The most significant change
> in functionality comes from the 5th patch which is changing the
> selection of the clocksource timer for OMAP3 and AM335x devices
> when gptimers are used for clocksource.
> 
> This series is dependent on commit 7185684 (ARM: OMAP: use
> consistent error checking) from RMK's clean-up branch and commit
> 6bb27d7 (ARM: delete struct sys_timer)

Thanks pulling into omap-for-v3.10/timer. I ended up merging this
with omap-for-v3.10/fixes-non-critical because of the omap5 merge
conflict.

Regards,

Tony

> ----------------------------------------------------------------
> 
> Jon Hunter (7):
>       ARM: OMAP2+: Display correct system timer name
>       ARM: OMAP2+: Remove hard-coded test on timer ID
>       ARM: OMAP2+: Simplify system timer clock definitions
>       ARM: OMAP2+: Simplify system timers definitions
>       ARM: OMAP3: Update clocksource timer selection
>       ARM: OMAP2+: Store ID of system timers in timer structure
>       ARM: OMAP4+: Fix sparse warning in system timers
> 
>  arch/arm/mach-omap2/board-cm-t3517.c |    2 +-
>  arch/arm/mach-omap2/board-generic.c  |    2 +-
>  arch/arm/mach-omap2/common.h         |    3 +-
>  arch/arm/mach-omap2/timer.c          |  121 +++++++++++++++++-----------------
>  4 files changed, 65 insertions(+), 63 deletions(-)


From will.deacon at arm.com  Wed Apr  3 14:04:43 2013
From: will.deacon at arm.com (Will Deacon)
Date: Wed, 3 Apr 2013 19:04:43 +0100
Subject: [PATCH] arm64: Fix task tracing
In-Reply-To: <1365012061-31660-1-git-send-email-cov@codeaurora.org>
References: <1365012061-31660-1-git-send-email-cov@codeaurora.org>
Message-ID: <20130403180443.GB21167@mudshark.cambridge.arm.com>

Hi Christopher,

On Wed, Apr 03, 2013 at 07:01:01PM +0100, Christopher Covington wrote:
> For accurate accounting call contextidr_thread_switch before a
> task is scheduled, rather than after.
> 
> Signed-off-by: Christopher Covington <cov at codeaurora.org>
> ---
>  arch/arm64/kernel/process.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
> index 0337cdb..c2cc249 100644
> --- a/arch/arm64/kernel/process.c
> +++ b/arch/arm64/kernel/process.c
> @@ -311,11 +311,11 @@ struct task_struct *__switch_to(struct task_struct *prev,
>  	fpsimd_thread_switch(next);
>  	tls_thread_switch(next);
>  	hw_breakpoint_thread_switch(next);
> +	contextidr_thread_switch(next);
>  
>  	/* the actual thread switch */
>  	last = cpu_switch_to(prev, next);
>  
> -	contextidr_thread_switch(next);
>  	return last;
>  }

Catalin and I wondered about this and decided to go with the current
approach in case a debugger, in response to the contextidr write, decided to
go off and mine information about the *new* task using the sp.

If we update the register before we've switched the registers, there's a
sizeable window where the debugger will get confused.

Do you have a real use-case that has triggered this patch?

Cheers,

Will


From linux at prisktech.co.nz  Wed Apr  3 14:08:30 2013
From: linux at prisktech.co.nz (Tony Prisk)
Date: Thu, 04 Apr 2013 07:08:30 +1300
Subject: [PATCHv5 0/7] arm: vt8500: Add support for pinctrl/gpio module
In-Reply-To: <CACRpkdZAtgpfA5rZ_C=eKDDOE9aDm=3k1QDava=EGL2BaoV+0g@mail.gmail.com>
References: <1364970291-17721-1-git-send-email-linux@prisktech.co.nz>
 <CACRpkdZAtgpfA5rZ_C=eKDDOE9aDm=3k1QDava=EGL2BaoV+0g@mail.gmail.com>
Message-ID: <515C701E.1000402@prisktech.co.nz>

On 04/04/13 02:40, Linus Walleij wrote:
> On Wed, Apr 3, 2013 at 8:24 AM, Tony Prisk <linux at prisktech.co.nz> wrote:
>
>> v5 changes:
>> Changed as requested by Rob Herring:
>> Added of_find_property_value_of_size() to drivers/of/base.c to remove some
>> code that was being duplicated.
>>
>> Changed as requested by Stephen Warren:
>> Redid the kfree(maps) code as devm_kzalloc would cause issues. We now kzalloc
>> maps all at once, and configs as required. A call to wmt_pctl_dt_free_map() is
>> used to kfree the allocated blocks if we fail early.
> This v5 series:
> Acked-by: Linus Walleij <linus.walleij at linaro.org>
>
> I guess it will go in through the VT8500 tree eventually?
>
> Maybe you could put Stephen's BCMring patch on top when sending
> it in (also Acked-by) so we can avoid having that dangling.
>
> Yours,
> Linus Walleij
We don't have a VT8500 tree. Originally I planned for it to go through 
you, but it could go through arm-soc if they want to take it.

Regards
Tony P


From swarren at wwwdotorg.org  Wed Apr  3 14:10:11 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Wed, 03 Apr 2013 12:10:11 -0600
Subject: [PATCH v9 12/14] clk: tegra: devicetree match for nvidia,
 tegra114-car
In-Reply-To: <1365000110-8916-13-git-send-email-pdeschrijver@nvidia.com>
References: <1365000110-8916-1-git-send-email-pdeschrijver@nvidia.com>
 <1365000110-8916-13-git-send-email-pdeschrijver@nvidia.com>
Message-ID: <515C7083.9070702@wwwdotorg.org>

On 04/03/2013 08:40 AM, Peter De Schrijver wrote:
> Signed-off-by: Peter De Schrijver <pdeschrijver at nvidia.com>

I see this patch does depend on my "clk: tegra: defer application of
init table", although my patch was based on top of this series so needs
to be adjusted to remove the Tegra114 portions so it can be applied first.


From swarren at wwwdotorg.org  Wed Apr  3 14:22:27 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Wed, 03 Apr 2013 12:22:27 -0600
Subject: [PATCH] clocksource: tegra: enable arch_timer
In-Reply-To: <515C2E8F.1030802@gmail.com>
References: <1364988750-25058-1-git-send-email-josephl@nvidia.com>
 <515C2E8F.1030802@gmail.com>
Message-ID: <515C7363.4040404@wwwdotorg.org>

On 04/03/2013 07:28 AM, Rob Herring wrote:
> On 04/03/2013 06:32 AM, Joseph Lo wrote:
>> Architected timer is the local timer for Cortex-A15. Adding the support
>> for Tegra.
>>
>> Cc: John Stultz <john.stultz at linaro.org>
>> Cc: Thomas Gleixner <tglx at linutronix.de>
>> Signed-off-by: Joseph Lo <josephl at nvidia.com>
> 
> My patch series to add CLOCKSOURCE_OF_DECLARE support to arch timer and
> sched_clock enhancements will make this unnecessary:
> 
> http://www.spinics.net/lists/arm-kernel/msg234597.html
> 
> Testing would be appreciated.

Joseph (or Rob), what's the benefit of this change; what works with it
and/or what breaks without it?

Rob, if I did apply this change, and you also apply that series of
yours, what is the result: compile-time breakage, run-time breakage,
just some redundant code that needs to be removed again?

Thanks.


From swarren at wwwdotorg.org  Wed Apr  3 14:27:33 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Wed, 03 Apr 2013 12:27:33 -0600
Subject: [PATCH v9 00/14] Tegra114 clockframework
In-Reply-To: <515C6C6E.6060302@wwwdotorg.org>
References: <1365000110-8916-1-git-send-email-pdeschrijver@nvidia.com>
 <515C6C6E.6060302@wwwdotorg.org>
Message-ID: <515C7495.8060106@wwwdotorg.org>

On 04/03/2013 11:52 AM, Stephen Warren wrote:
> On 04/03/2013 08:40 AM, Peter De Schrijver wrote:
>> This is the nineth version of the Tegra114 clockframework. It is based on the
>> next-20130320-fixed branch of
>> git://nv-tegra.nvidia.com/user/swarren/linux-2.6.git,
... [it depends on]
>> http://patchwork.ozlabs.org/patch/233415/
> 
> That is Joseph's "clocksource: tegra: enable arch_timer". Is this
> actually a dependency, or an optimization, or ...?
> 
> Rob Herring objected to that patch since it isn't necessary if his
> series "ARM arch, sp804 and integrator timer CLKSRC_OF support" is applied.
> 
> If I apply just your (Peter's) CCF series without Joseph's or Rob's
> patches, will everything still work, or is this a hard dependency to
> create a working system?

I manage to get this series applied on top of my local dev branch, based
on next-20130328 (it was painful). Testing indicates that there is no
dependency on Joseph's patch mentioned above; I could boot, log in, and
play audio (with local patches) with /or/ without Joseph's patch applied.

However, I still find that I need to revert f7db706 ARM: "7674/1: smp:
Avoid dummy clockevent being preferred over real hardware clock-event",
or I get a hard system hang right after the root fs is mounted. As such,
I not sure if it's worthwhile applying this series since it's unlikely
to actually work once merged into Torvalds' tree.

Do you have any idea what the problem is here?

I'll try rebasing my local test branch on top of the latest linux-next
just in case some other fix solved this already, but I'm not going to
hold my breath.


From alexey.pelykh at gmail.com  Wed Apr  3 14:31:46 2013
From: alexey.pelykh at gmail.com (Alexey Pelykh)
Date: Wed, 3 Apr 2013 14:31:46 -0400
Subject: [PATCH] OMAP/serial: Revert bad fix of Rx FIFO threshold granularity
Message-ID: <20130403183146.GA4072@inertiallabs-linux64>

From: Alexey Pelykh <alexey.pelykh at gmail.com>

Partially reverts 1776fd059c40907297d6c26c51876575d63fd9e2
that introduced regression reported by Paul Walmsley.

This commit restores setting granularity in SCR register
and adds note about comments below being inconsistent with
actual code.

Signed-off-by: Alexey Pelykh <alexey.pelykh at gmail.com>
Cc: Paul Walmsley <paul at pwsan.com>
Cc: Kevin Hilman <khilman at linaro.org>
Cc: Felipe Balbi <balbi at ti.com>
Cc: linux-serial at vger.kernel.org 
Cc: linux-arm-kernel at lists.infradead.org 
Cc: linux-omap at vger.kernel.org 

---

Paul, please confirm that this patch solves the regression.

diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 4dc4140..30d4f7a 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -886,6 +886,17 @@ serial_omap_set_termios(struct uart_port *port, struct ktermios *termios,
 	serial_out(up, UART_MCR, up->mcr | UART_MCR_TCRTLR);
 	/* FIFO ENABLE, DMA MODE */
 
+	up->scr |= OMAP_UART_SCR_RX_TRIG_GRANU1_MASK;
+	/*
+	 * NOTE: Setting OMAP_UART_SCR_RX_TRIG_GRANU1_MASK
+	 * sets Enables the granularity of 1 for TRIGGER RX
+	 * level. Along with setting RX FIFO trigger level
+	 * to 1 (as noted below, 16 characters) and TLR[3:0]
+	 * to zero this will result RX FIFO threshold level
+	 * to 1 character, instead of 16 as noted in comment
+	 * below.
+	 */
+
 	/* Set receive FIFO threshold to 16 characters and
 	 * transmit FIFO threshold to 16 spaces
 	 */


From tony at atomide.com  Wed Apr  3 14:38:03 2013
From: tony at atomide.com (Tony Lindgren)
Date: Wed, 3 Apr 2013 11:38:03 -0700
Subject: Query on pinctrl usage for DT nodes
In-Reply-To: <515C5C76.3080009@wwwdotorg.org>
References: <CA+V-a8uiPwsAD--OHFAE=i2ed+-wbXm4p2deZXr92+Zv6GDS1w@mail.gmail.com>
 <515C5C76.3080009@wwwdotorg.org>
Message-ID: <20130403183803.GA10155@atomide.com>

* Stephen Warren <swarren at wwwdotorg.org> [130403 09:49]:
> On 04/03/2013 03:16 AM, Prabhakar Lad wrote:
> > Hi Linus/Stephen,
> > 
> > I am working adding  DT nodes for DA850.
> > 
> > Following is the pin control snippet of da850.dtsi:-
> > 
> > 		pmx_core: pinmux at 1c14120 {
> ...
> >                         i2c0_pins: pinmux_i2c0_pins {
> >                                 pinctrl-single,bits = <
> >                                         /* I2C0_SDA,I2C0_SCL */
> >                                         0x10 0x00002200 0x0000ff00
> >                                 >;
> >                         };
> >                         mdio_pins: pinmux_mdio_pins {
> >                                 pinctrl-single,bits = <
> >                                         /* MDIO_CLK, MDIO_D */
> >                                         0x10 0x00000088 0x000000ff
> >                                 >;
> >                         };
> >                 }
> > 
> > And following is the code snippet for dts:-
> > 
> > 		i2c0: i2c at 1c22000 {
> > 			status = "okay";
> > 			clock-frequency = <100000>;
> > 			pinctrl-names = "default";
> > 			pinctrl-0 = <&i2c0_pins>;
> > 		};
> > 		mdio: mdio at 1e24000 {
> > 			status = "okay";
> > 			bus_freq = <2200000>;
> > 			pinctrl-names = "default";
> 
> I assume there's also the following there:
> 
> 			pinctrl-0 = <&mdio_pins>;
> 
> >               };
> > 		
> > But while booting I see the following boot log:-
> > ...
> > cpuidle: using governor menu
> > TCP: cubic registered
> > NET: Registered protocol family 17
> > pinctrl-single 1c14120.pinmux: pin 1c14130 already requested by
> > davinci_mdio.0; cannot claim for i2c_davinci.1
> > pinctrl-single 1c14120.pinmux: pin-4 (i2c_davinci.1) status -22
> > pinctrl-single 1c14120.pinmux: could not request pin 4 on device pinctrl-single
> > console [netcon0] enabled
> > ....
> > 
> > This is because the mdio and i2c are using same pin 0x10,
> 
> How can two devices use the same pin? I mean physically, in hardware?
> 
> Is this because pinctrl-single uses the register address as the pin
> number, whereas you have registers which configure multiple pins at
> once? If so, your hardware isn't something that can be represented by
> pinctrl-single.
> 
> > Is there any
> > alternative way to handle if the two node's are using same pins any
> > pointers could be very much helpful ?

It could also that the mux register(s) follow the one-mux-per-bit
mapping.

In that case pinctrl-single,bits option as documented in the
Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt.

Regards,

Tony




From tony at atomide.com  Wed Apr  3 14:42:03 2013
From: tony at atomide.com (Tony Lindgren)
Date: Wed, 3 Apr 2013 11:42:03 -0700
Subject: Query on pinctrl usage for DT nodes
In-Reply-To: <20130403183803.GA10155@atomide.com>
References: <CA+V-a8uiPwsAD--OHFAE=i2ed+-wbXm4p2deZXr92+Zv6GDS1w@mail.gmail.com>
 <515C5C76.3080009@wwwdotorg.org>
 <20130403183803.GA10155@atomide.com>
Message-ID: <20130403184202.GB10155@atomide.com>

* Tony Lindgren <tony at atomide.com> [130403 11:42]:
> * Stephen Warren <swarren at wwwdotorg.org> [130403 09:49]:
> > On 04/03/2013 03:16 AM, Prabhakar Lad wrote:
> > > Hi Linus/Stephen,
> > > 
> > > I am working adding  DT nodes for DA850.
> > > 
> > > Following is the pin control snippet of da850.dtsi:-
> > > 
> > > 		pmx_core: pinmux at 1c14120 {
> > ...
> > >                         i2c0_pins: pinmux_i2c0_pins {
> > >                                 pinctrl-single,bits = <
> > >                                         /* I2C0_SDA,I2C0_SCL */
> > >                                         0x10 0x00002200 0x0000ff00
> > >                                 >;
> > >                         };
> > >                         mdio_pins: pinmux_mdio_pins {
> > >                                 pinctrl-single,bits = <
> > >                                         /* MDIO_CLK, MDIO_D */
> > >                                         0x10 0x00000088 0x000000ff
> > >                                 >;
> > >                         };
> > >                 }
> > > 
> > > And following is the code snippet for dts:-
> > > 
> > > 		i2c0: i2c at 1c22000 {
> > > 			status = "okay";
> > > 			clock-frequency = <100000>;
> > > 			pinctrl-names = "default";
> > > 			pinctrl-0 = <&i2c0_pins>;
> > > 		};
> > > 		mdio: mdio at 1e24000 {
> > > 			status = "okay";
> > > 			bus_freq = <2200000>;
> > > 			pinctrl-names = "default";
> > 
> > I assume there's also the following there:
> > 
> > 			pinctrl-0 = <&mdio_pins>;
> > 
> > >               };
> > > 		
> > > But while booting I see the following boot log:-
> > > ...
> > > cpuidle: using governor menu
> > > TCP: cubic registered
> > > NET: Registered protocol family 17
> > > pinctrl-single 1c14120.pinmux: pin 1c14130 already requested by
> > > davinci_mdio.0; cannot claim for i2c_davinci.1
> > > pinctrl-single 1c14120.pinmux: pin-4 (i2c_davinci.1) status -22
> > > pinctrl-single 1c14120.pinmux: could not request pin 4 on device pinctrl-single
> > > console [netcon0] enabled
> > > ....
> > > 
> > > This is because the mdio and i2c are using same pin 0x10,
> > 
> > How can two devices use the same pin? I mean physically, in hardware?
> > 
> > Is this because pinctrl-single uses the register address as the pin
> > number, whereas you have registers which configure multiple pins at
> > once? If so, your hardware isn't something that can be represented by
> > pinctrl-single.
> > 
> > > Is there any
> > > alternative way to handle if the two node's are using same pins any
> > > pointers could be very much helpful ?
> 
> It could also that the mux register(s) follow the one-mux-per-bit
> mapping.
> 
> In that case pinctrl-single,bits option as documented in the
> Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt.

Oh it's already using pinctrl-single,bits option. Maybe there's a
bug, adding Peter to cc.

Regards,

Tony


From olof at lixom.net  Wed Apr  3 14:52:32 2013
From: olof at lixom.net (Olof Johansson)
Date: Wed, 3 Apr 2013 11:52:32 -0700
Subject: [PATCHv2 1/2] ARM: socfpga: Enable soft reset
In-Reply-To: <20130320152915.GA32083@amd.pavel.ucw.cz>
References: <1363707936-17769-1-git-send-email-dinguyen@altera.com>
 <20130320152915.GA32083@amd.pavel.ucw.cz>
Message-ID: <20130403185232.GA11360@quad.lixom.net>

On Wed, Mar 20, 2013 at 04:29:15PM +0100, Pavel Machek wrote:
> Hi!
> 
> > From: Dinh Nguyen <dinguyen at altera.com>
> > 
> > Enable a cold or warm reset to the HW from userspace.
> > 
> > Also fix a few sparse errors:
> > 
> > warning: symbol 'sys_manager_base_addr' was not declared. Should it be static?
> > warning: symbol 'rst_manager_base_addr' was not declared. Should it be static?
> > 
> > Signed-off-by: Dinh Nguyen <dinguyen at altera.com>
> 
> Tested-by: Pavel Machek <pavel at denx.de>
> 
> Would it make sense to apply something like this? Struct looks cleaner
> than offset defines... 
> 
> Thanks,
> 									Pavel
> 
>     Switch reset manager to using struct (not defines), cleanups.
>     
>     Convert SMP code to use the struct instead of open-coded numbers.
> 
>     Also none of the code is time-critical, so it
>     does not make sense to use __raw_writel variants.
>     
>     Signed-off-by: Pavel Machek <pavel at denx.de>
> 
> diff --git a/arch/arm/mach-socfpga/core.h b/arch/arm/mach-socfpga/core.h
> index d2a251f..f4b6048 100644
> --- a/arch/arm/mach-socfpga/core.h
> +++ b/arch/arm/mach-socfpga/core.h
> @@ -20,19 +20,21 @@
>  #ifndef __MACH_CORE_H
>  #define __MACH_CORE_H
>  
> -#define SOCFPGA_RSTMGR_CTRL	0x04
> -#define SOCFPGA_RSTMGR_MODPERRST	0x14
> -#define SOCFPGA_RSTMGR_BRGMODRST	0x1c
> -
> -/* System Manager bits */
> -#define RSTMGR_CTRL_SWCOLDRSTREQ	0x1	/* Cold Reset */
> -#define RSTMGR_CTRL_SWWARMRSTREQ	0x2	/* Warm Reset */
> -/*MPU Module Reset Register */
> -#define RSTMGR_MPUMODRST_CPU0	0x1	/*CPU0 Reset*/
> -#define RSTMGR_MPUMODRST_CPU1	0x2	/*CPU1 Reset*/
> -#define RSTMGR_MPUMODRST_WDS		0x4	/*Watchdog Reset*/
> -#define RSTMGR_MPUMODRST_SCUPER	0x8	/*SCU and periphs reset*/
> -#define RSTMGR_MPUMODRST_L2		0x10	/*L2 Cache reset*/
> +struct socfpga_rstmgr_hw {
> +	u32 unk;
> +	u32 ctrl;		/* 0x04 */
> +	u32 unk2, unk3;
> +/* MPU Module Reset Register */
> +#define RSTMGR_MPUMODRST_CPU0	0x1	/* CPU0 Reset */
> +#define RSTMGR_MPUMODRST_CPU1	0x2	/* CPU1 Reset */
> +#define RSTMGR_MPUMODRST_WDS	0x4	/* Watchdog Reset */
> +#define RSTMGR_MPUMODRST_SCUPER	0x8	/* SCU and periphs reset */
> +#define RSTMGR_MPUMODRST_L2	0x10	/* L2 Cache reset */
> +	u32 mpumodrst; 		/* 0x10 */
> +	u32 modperrst;		/* 0x14 */
> +	u32 unk5;
> +	u32 bgrmodrst;		/* 0x1c */
> +};

As Russell already replied, struct used to represent register layout is
normally frowned upon in drivers.

If you want to tighten up the code in this case, make a local helper
function that just takes the register offset instead, i.e.:

> -	temp = __raw_readl(rst_manager_base_addr + SOCFPGA_RSTMGR_CTRL);
> +	temp = readl(&rst_manager_base_addr->ctrl);

	temp = rst_readl(SOCFPGA_RSTMGR_CTRL);

(and then have rst_readl/rst_writel do the math based on base address).



-Olof


From robherring2 at gmail.com  Wed Apr  3 14:52:48 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Wed, 03 Apr 2013 13:52:48 -0500
Subject: [PATCHv5 2/7] of: Remove duplicated code for validating property
 and value
In-Reply-To: <1364970291-17721-3-git-send-email-linux@prisktech.co.nz>
References: <1364970291-17721-1-git-send-email-linux@prisktech.co.nz>
 <1364970291-17721-3-git-send-email-linux@prisktech.co.nz>
Message-ID: <515C7A80.1040301@gmail.com>

On 04/03/2013 01:24 AM, Tony Prisk wrote:
> Several functions in of/base.c have the same code duplicated for
> finding and validating a property and value.
> 
> struct property *prop = of_find_property(np, propname, NULL);
> if (!prop)
> 	return -EINVAL;
> if (!prop->value)
> 	return -ENODATA;
> if (<some length> > prop->length)
> 	return -EOVERFLOW;
> 
> This patch adds of_find_property_value_of_size() which performs the
> equivalent of the above code and removes the instances where it was
> duplicated in several functions.
> 
> Reported-by: Rob Herring <robherring2 at gmail.com>
> Signed-off-by: Tony Prisk <linux at prisktech.co.nz>
> ---

I'd prefer the first 2 patches in reverse order, but its not a big deal.
So for both:

Acked-by: Rob Herring <rob.herring at calxeda.com>

>  drivers/of/base.c |   94 +++++++++++++++++++++++++++++------------------------
>  1 file changed, 51 insertions(+), 43 deletions(-)
> 
> diff --git a/drivers/of/base.c b/drivers/of/base.c
> index f6c89ed..c6443de 100644
> --- a/drivers/of/base.c
> +++ b/drivers/of/base.c
> @@ -746,6 +746,34 @@ struct device_node *of_find_node_by_phandle(phandle handle)
>  EXPORT_SYMBOL(of_find_node_by_phandle);
>  
>  /**
> + * of_find_property_value_of_size
> + *
> + * @np:		device node from which the property value is to be read.
> + * @propname:	name of the property to be searched.
> + * @len:	requested length of property value
> + *
> + * Search for a property in a device node and valid the requested size.
> + * Returns the property value on success, -EINVAL if the property does not
> + *  exist, -ENODATA if property does not have a value, and -EOVERFLOW if the
> + * property data isn't large enough.
> + *
> + */
> +static void *of_find_property_value_of_size(const struct device_node *np,
> +			const char *propname, u32 len)
> +{
> +	struct property *prop = of_find_property(np, propname, NULL);
> +
> +	if (!prop)
> +		return ERR_PTR(-EINVAL);
> +	if (!prop->value)
> +		return ERR_PTR(-ENODATA);
> +	if (len > prop->length)
> +		return ERR_PTR(-EOVERFLOW);
> +
> +	return prop->value;
> +}
> +
> +/**
>   * of_property_read_u32_index - Find and read a u32 from a multi-value property.
>   *
>   * @np:		device node from which the property value is to be read.
> @@ -764,16 +792,13 @@ int of_property_read_u32_index(const struct device_node *np,
>  				       const char *propname,
>  				       u32 index, u32 *out_value)
>  {
> -	struct property *prop = of_find_property(np, propname, NULL);
> +	const u32 *val = of_find_property_value_of_size(np, propname,
> +					((index + 1) * sizeof(*out_value)));
>  
> -	if (!prop)
> -		return -EINVAL;
> -	if (!prop->value)
> -		return -ENODATA;
> -	if (((index + 1) * sizeof(*out_value)) > prop->length)
> -		return -EOVERFLOW;
> +	if (IS_ERR(val))
> +		return PTR_ERR(val);
>  
> -	*out_value = be32_to_cpup(((__be32 *)prop->value) + index);
> +	*out_value = be32_to_cpup(((__be32 *)val) + index);
>  	return 0;
>  }
>  EXPORT_SYMBOL_GPL(of_property_read_u32_index);
> @@ -799,17 +824,12 @@ EXPORT_SYMBOL_GPL(of_property_read_u32_index);
>  int of_property_read_u8_array(const struct device_node *np,
>  			const char *propname, u8 *out_values, size_t sz)
>  {
> -	struct property *prop = of_find_property(np, propname, NULL);
> -	const u8 *val;
> +	const u8 *val = of_find_property_value_of_size(np, propname,
> +						(sz * sizeof(*out_values)));
>  
> -	if (!prop)
> -		return -EINVAL;
> -	if (!prop->value)
> -		return -ENODATA;
> -	if ((sz * sizeof(*out_values)) > prop->length)
> -		return -EOVERFLOW;
> +	if (IS_ERR(val))
> +		return PTR_ERR(val);
>  
> -	val = prop->value;
>  	while (sz--)
>  		*out_values++ = *val++;
>  	return 0;
> @@ -837,17 +857,12 @@ EXPORT_SYMBOL_GPL(of_property_read_u8_array);
>  int of_property_read_u16_array(const struct device_node *np,
>  			const char *propname, u16 *out_values, size_t sz)
>  {
> -	struct property *prop = of_find_property(np, propname, NULL);
> -	const __be16 *val;
> +	const __be16 *val = of_find_property_value_of_size(np, propname,
> +						(sz * sizeof(*out_values)));
>  
> -	if (!prop)
> -		return -EINVAL;
> -	if (!prop->value)
> -		return -ENODATA;
> -	if ((sz * sizeof(*out_values)) > prop->length)
> -		return -EOVERFLOW;
> +	if (IS_ERR(val))
> +		return PTR_ERR(val);
>  
> -	val = prop->value;
>  	while (sz--)
>  		*out_values++ = be16_to_cpup(val++);
>  	return 0;
> @@ -874,17 +889,12 @@ int of_property_read_u32_array(const struct device_node *np,
>  			       const char *propname, u32 *out_values,
>  			       size_t sz)
>  {
> -	struct property *prop = of_find_property(np, propname, NULL);
> -	const __be32 *val;
> +	const __be32 *val = of_find_property_value_of_size(np, propname,
> +						(sz * sizeof(*out_values)));
>  
> -	if (!prop)
> -		return -EINVAL;
> -	if (!prop->value)
> -		return -ENODATA;
> -	if ((sz * sizeof(*out_values)) > prop->length)
> -		return -EOVERFLOW;
> +	if (IS_ERR(val))
> +		return PTR_ERR(val);
>  
> -	val = prop->value;
>  	while (sz--)
>  		*out_values++ = be32_to_cpup(val++);
>  	return 0;
> @@ -907,15 +917,13 @@ EXPORT_SYMBOL_GPL(of_property_read_u32_array);
>  int of_property_read_u64(const struct device_node *np, const char *propname,
>  			 u64 *out_value)
>  {
> -	struct property *prop = of_find_property(np, propname, NULL);
> +	const __be32 *val = of_find_property_value_of_size(np, propname,
> +						sizeof(*out_value));
>  
> -	if (!prop)
> -		return -EINVAL;
> -	if (!prop->value)
> -		return -ENODATA;
> -	if (sizeof(*out_value) > prop->length)
> -		return -EOVERFLOW;
> -	*out_value = of_read_number(prop->value, 2);
> +	if (IS_ERR(val))
> +		return PTR_ERR(val);
> +
> +	*out_value = of_read_number(val, 2);
>  	return 0;
>  }
>  EXPORT_SYMBOL_GPL(of_property_read_u64);
> 



From linus.walleij at stericsson.com  Wed Apr  3 15:02:09 2013
From: linus.walleij at stericsson.com (Linus Walleij)
Date: Wed, 3 Apr 2013 21:02:09 +0200
Subject: [PATCH] pinctrl/pinconf: partial revert of pin config debugfs
Message-ID: <1365015729-9192-1-git-send-email-linus.walleij@stericsson.com>

From: Linus Walleij <linus.walleij at linaro.org>

I accidentally left this patch:

commit 6f9e41f4e673bf9ae6a5c0831b1524a91ea1c440
"pinctrl/pinconfig: add debug interface"

in the tree though the patch was not yet finished.
Revert it partially (we need the infrastructural changes).

Cc: Laurent Meunier <laurent.meunier at st.com>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 drivers/pinctrl/pinconf.c | 207 ----------------------------------------------
 1 file changed, 207 deletions(-)

diff --git a/drivers/pinctrl/pinconf.c b/drivers/pinctrl/pinconf.c
index 8aefd28..baee2cc 100644
--- a/drivers/pinctrl/pinconf.c
+++ b/drivers/pinctrl/pinconf.c
@@ -574,207 +574,6 @@ static const struct file_operations pinconf_groups_ops = {
 	.release	= single_release,
 };
 
-/* 32bit read/write ressources */
-#define MAX_NAME_LEN 16
-char dbg_pinname[MAX_NAME_LEN]; /* shared: name of the state of the pin*/
-char dbg_state_name[MAX_NAME_LEN]; /* shared: state of the pin*/
-static u32 dbg_config; /* shared: config to be read/set for the pin & state*/
-
-static int pinconf_dbg_pinname_print(struct seq_file *s, void *d)
-{
-	if (strlen(dbg_pinname))
-		seq_printf(s, "%s\n", dbg_pinname);
-	else
-		seq_printf(s, "No pin name set\n");
-	return 0;
-}
-
-static int pinconf_dbg_pinname_open(struct inode *inode, struct file *file)
-{
-	return single_open(file, pinconf_dbg_pinname_print, inode->i_private);
-}
-
-static int pinconf_dbg_pinname_write(struct file *file,
-	const char __user *user_buf, size_t count, loff_t *ppos)
-{
-	int err;
-
-	if (count > MAX_NAME_LEN)
-		return -EINVAL;
-
-	err = sscanf(user_buf, "%15s", dbg_pinname);
-
-	if (err != 1)
-		return -EINVAL;
-
-	return count;
-}
-
-static const struct file_operations pinconf_dbg_pinname_fops = {
-	.open = pinconf_dbg_pinname_open,
-	.write = pinconf_dbg_pinname_write,
-	.read = seq_read,
-	.llseek = seq_lseek,
-	.release = single_release,
-	.owner = THIS_MODULE,
-};
-
-static int pinconf_dbg_state_print(struct seq_file *s, void *d)
-{
-	if (strlen(dbg_state_name))
-		seq_printf(s, "%s\n", dbg_pinname);
-	else
-		seq_printf(s, "No pin state set\n");
-	return 0;
-}
-
-static int pinconf_dbg_state_open(struct inode *inode, struct file *file)
-{
-	return single_open(file, pinconf_dbg_state_print, inode->i_private);
-}
-
-static int pinconf_dbg_state_write(struct file *file,
-	const char __user *user_buf, size_t count, loff_t *ppos)
-{
-	int err;
-
-	if (count > MAX_NAME_LEN)
-		return -EINVAL;
-
-	err = sscanf(user_buf, "%15s", dbg_state_name);
-
-	if (err != 1)
-		return -EINVAL;
-
-	return count;
-}
-
-static const struct file_operations pinconf_dbg_pinstate_fops = {
-	.open = pinconf_dbg_state_open,
-	.write = pinconf_dbg_state_write,
-	.read = seq_read,
-	.llseek = seq_lseek,
-	.release = single_release,
-	.owner = THIS_MODULE,
-};
-
-/**
- * pinconf_dbg_config_print() - display the pinctrl config from the pinctrl
- * map, of a pin/state pair based on pinname and state that have been
- * selected with the debugfs entries pinconf-name and pinconf-state
- * @s: contains the 32bits config to be written
- * @d: not used
- */
-static int pinconf_dbg_config_print(struct seq_file *s, void *d)
-{
-	struct pinctrl_maps *maps_node;
-	struct pinctrl_map const *map;
-	struct pinctrl_dev *pctldev = NULL;
-	const struct pinconf_ops *confops = NULL;
-	int i, j;
-	bool found = false;
-
-	mutex_lock(&pinctrl_mutex);
-
-	/* Parse the pinctrl map and look for the elected pin/state */
-	for_each_maps(maps_node, i, map) {
-		if (map->type != PIN_MAP_TYPE_CONFIGS_PIN)
-			continue;
-
-		if (strncmp(map->name, dbg_state_name, MAX_NAME_LEN) > 0)
-			continue;
-
-		for (j = 0; j < map->data.configs.num_configs; j++) {
-			if (0 == strncmp(map->data.configs.group_or_pin,
-						dbg_pinname, MAX_NAME_LEN)) {
-				/* We found the right pin / state, read the
-				 * config and store the pctldev */
-				dbg_config = map->data.configs.configs[j];
-				pctldev = get_pinctrl_dev_from_devname
-					(map->ctrl_dev_name);
-				found = true;
-				break;
-			}
-		}
-	}
-
-	mutex_unlock(&pinctrl_mutex);
-
-	if (found) {
-		seq_printf(s, "Config of %s in state %s: 0x%08X\n", dbg_pinname,
-				 dbg_state_name, dbg_config);
-
-		if (pctldev)
-			confops = pctldev->desc->confops;
-
-		if (confops && confops->pin_config_config_dbg_show)
-			confops->pin_config_config_dbg_show(pctldev,
-					s, dbg_config);
-	} else {
-		seq_printf(s, "No pin found for defined name/state\n");
-	}
-
-	return 0;
-}
-
-static int pinconf_dbg_config_open(struct inode *inode, struct file *file)
-{
-	return single_open(file, pinconf_dbg_config_print, inode->i_private);
-}
-
-/**
- * pinconf_dbg_config_write() - overwrite the pinctrl config in thepinctrl
- * map, of a pin/state pair based on pinname and state that have been
- * selected with the debugfs entries pinconf-name and pinconf-state
- */
-static int pinconf_dbg_config_write(struct file *file,
-	const char __user *user_buf, size_t count, loff_t *ppos)
-{
-	int err;
-	unsigned long config;
-	struct pinctrl_maps *maps_node;
-	struct pinctrl_map const *map;
-	int i, j;
-
-	err = kstrtoul_from_user(user_buf, count, 0, &config);
-
-	if (err)
-		return err;
-
-	dbg_config = config;
-
-	mutex_lock(&pinctrl_mutex);
-
-	/* Parse the pinctrl map and look for the selected pin/state */
-	for_each_maps(maps_node, i, map) {
-		if (map->type != PIN_MAP_TYPE_CONFIGS_PIN)
-			continue;
-
-		if (strncmp(map->name, dbg_state_name, MAX_NAME_LEN) > 0)
-			continue;
-
-		/*  we found the right pin / state, so overwrite config */
-		for (j = 0; j < map->data.configs.num_configs; j++) {
-			if (strncmp(map->data.configs.group_or_pin, dbg_pinname,
-						MAX_NAME_LEN) == 0)
-				map->data.configs.configs[j] = dbg_config;
-		}
-	}
-
-	mutex_unlock(&pinctrl_mutex);
-
-	return count;
-}
-
-static const struct file_operations pinconf_dbg_pinconfig_fops = {
-	.open = pinconf_dbg_config_open,
-	.write = pinconf_dbg_config_write,
-	.read = seq_read,
-	.llseek = seq_lseek,
-	.release = single_release,
-	.owner = THIS_MODULE,
-};
-
 void pinconf_init_device_debugfs(struct dentry *devroot,
 			 struct pinctrl_dev *pctldev)
 {
@@ -782,12 +581,6 @@ void pinconf_init_device_debugfs(struct dentry *devroot,
 			    devroot, pctldev, &pinconf_pins_ops);
 	debugfs_create_file("pinconf-groups", S_IFREG | S_IRUGO,
 			    devroot, pctldev, &pinconf_groups_ops);
-	debugfs_create_file("pinconf-name", (S_IRUGO | S_IWUSR | S_IWGRP),
-			    devroot, pctldev, &pinconf_dbg_pinname_fops);
-	debugfs_create_file("pinconf-state",  (S_IRUGO | S_IWUSR | S_IWGRP),
-			    devroot, pctldev, &pinconf_dbg_pinstate_fops);
-	debugfs_create_file("pinconf-config",  (S_IRUGO | S_IWUSR | S_IWGRP),
-			    devroot, pctldev, &pinconf_dbg_pinconfig_fops);
 }
 
 #endif
-- 
1.7.11.3



From alexey.pelykh at gmail.com  Wed Apr  3 15:04:05 2013
From: alexey.pelykh at gmail.com (Alexey Pelykh)
Date: Wed, 3 Apr 2013 22:04:05 +0300
Subject: [PATCH] Revert "OMAP/serial: Fix incorrect Rx FIFO threshold
 setting, LSR validation on Tx, and Tx FIFO IRQ generation"
In-Reply-To: <CAOmKuSp8nPJw7+LKK3ny7ZjEEV-CeDjGg0GD2fDjZiP6HBKGGw@mail.gmail.com>
References: <alpine.DEB.2.00.1304010519260.28273@utopia.booyaka.com>
 <CAOmKuSpttQJmrL=Htiz-Zc4voAF7CnG_GQYAO2onKpauwYjtvw@mail.gmail.com>
 <alpine.DEB.2.00.1304010844100.28273@utopia.booyaka.com>
 <CAOmKuSrABrPcZ=Yg1+LAHWbh9CdTYR0eUmJ2dd3z91oz0uu21g@mail.gmail.com>
 <alpine.DEB.2.00.1304011008230.28273@utopia.booyaka.com>
 <CAOmKuSrbDc025Tj9xsqDebJ_KZdp_VnWAOs_OO5UAegV43JcDQ@mail.gmail.com>
 <CAOmKuSpbaKutLxbNihBRDz+B0Wt0XiPss-PcEHc-efCTvciNFg@mail.gmail.com>
 <alpine.DEB.2.00.1304011654520.9148@utopia.booyaka.com>
 <CAOmKuSo4onVtk2Ke-i+0_1Ych33KuUYspRy+cySRHf4yWB5XDw@mail.gmail.com>
 <alpine.DEB.2.00.1304021821190.27146@utopia.booyaka.com>
 <CAOmKuSqd=gNYFutpgDref58pbAbDwDin4mvL_OEooD1XuwKtgQ@mail.gmail.com>
 <CAOmKuSp8nPJw7+LKK3ny7ZjEEV-CeDjGg0GD2fDjZiP6HBKGGw@mail.gmail.com>
Message-ID: <CAOmKuSoJ38YKyzuyESfx=jgi3y=EunAUt7RPp2=7pRQosytQYg@mail.gmail.com>

I've submitted patch that should remove this regression

On Wed, Apr 3, 2013 at 6:55 PM, Alexey Pelykh <alexey.pelykh at gmail.com> wrote:
> Paul,
>
> Should I start a new email chain with that patch or add it here?
>
> On Wed, Apr 3, 2013 at 12:19 AM, Alexey Pelykh <alexey.pelykh at gmail.com> wrote:
>> Hi Paul,
>>
>> No problem, I'll prepare patch in next 24 hours and will send in ASAP.
>>
>> But, since we've found the issue, I suggest that we should look at it
>> closer, especially since at this moment only you can reproduce it. As
>> far as I understand, but I may be wrong,
>> this comment is wrong, since if to specify
>> OMAP_UART_SCR_RX_TRIG_GRANU1_MASK, it effectively sets Rx threshold to
>> 1 character, instead of 16.
>> /* Set receive FIFO threshold to 16 characters and
>>  * transmit FIFO threshold to 16 spaces
>>  */
>>
>> On Tue, Apr 2, 2013 at 9:24 PM, Paul Walmsley <paul at pwsan.com> wrote:
>>> On Mon, 1 Apr 2013, Alexey Pelykh wrote:
>>>
>>>> Paul, can you please try to comment out change related to Rx line
>>>> (granulation one). That's only Rx line related change in the patch.
>>>
>>> Yes, looks like simply reverting the commit 1776fd059c40 ("OMAP/serial:
>>> Fix incorrect Rx FIFO threshold setting, LSR validation on Tx, and Tx FIFO
>>> IRQ generation") change to OMAP_UART_SCR_RX_TRIG_GRANU1_MASK fixes it.
>>>
>>> Care to send a patch doing so ASAP for v3.9-rc fixes?  That would moot the
>>> revert of the entire commit 1776fd059c40.
>>>
>>>
>>> - Paul


From dgilbert at interlog.com  Wed Apr  3 15:10:12 2013
From: dgilbert at interlog.com (Douglas Gilbert)
Date: Wed, 03 Apr 2013 15:10:12 -0400
Subject: [PATCH v2] ARM: at91: add Acme Systems Aria G25 board
In-Reply-To: <CAOesGMj+etPUMWffx2CiDtbWbB9A5_6QPbkTsmbEqCiBnkhm3A@mail.gmail.com>
References: <1364201369-12047-1-git-send-email-nicolas.ferre@atmel.com>
 <1364297952-32473-1-git-send-email-nicolas.ferre@atmel.com>
 <CAOesGMj+etPUMWffx2CiDtbWbB9A5_6QPbkTsmbEqCiBnkhm3A@mail.gmail.com>
Message-ID: <515C7E94.6030702@interlog.com>

On 13-04-02 02:48 PM, Olof Johansson wrote:
> Hi,
>
> I just saw this since it came in through a pull request
>
> On Tue, Mar 26, 2013 at 4:39 AM, Nicolas Ferre <nicolas.ferre at atmel.com> wrote:
>> From: Douglas Gilbert <dgilbert at interlog.com>
>>
>> Signed-off-by: Douglas Gilbert <dgilbert at interlog.com>
>> Signed-off-by: Nicolas Ferre <nicolas.ferre at atmel.com>
>> ---
>>   arch/arm/boot/dts/ariag25.dts | 175 ++++++++++++++++++++++++++++++++++++++++++
>>   1 file changed, 175 insertions(+)
>>   create mode 100644 arch/arm/boot/dts/ariag25.dts
>>
>> diff --git a/arch/arm/boot/dts/ariag25.dts b/arch/arm/boot/dts/ariag25.dts
>> new file mode 100644
>> index 0000000..b43266f
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/ariag25.dts
>
> Please prefix the boards with the platform. Most other SoCs already do
> this, and I see now that some at91 boards haven't been prefixed in the
> past, but it's a good idea to not add more of them.
>
> So, at91-ariag25.dts is a good name in this case.

That is fine with me. I have changed my working DT
config file to at91-ariag25.dts and will push that
out to Robert Nelson soon.

Also I'm working on a DT version of an existing Acme
product called the FoxG20 which is based on the
AT91SAM9G20 SoC. It already has non-DT support inside
the mainline kernel. I am using at91-foxg20.dts for
its DT config file.

Doug Gilbert




From soren.brinkmann at xilinx.com  Wed Apr  3 15:17:12 2013
From: soren.brinkmann at xilinx.com (Soren Brinkmann)
Date: Wed, 3 Apr 2013 12:17:12 -0700
Subject: [PATCH] clk: Properly handle notifier return values
Message-ID: <a2f153b2-9266-4ddc-94a9-3efbcbe9768c@CH1EHSMHS018.ehs.local>

Notifiers may return NOTIFY_(OK|DONE|STOP|BAD). The CCF uses an
inconsistent mix of checking against NOTIFY_STOP or NOTIFY_BAD.
This inconsistency leaves errors undetected in some cases:
clk_set_parent() calls __clk_speculate_rates(), which stops when it
hits a NOTIFIER_BAD (STOP is ignored), and passes this value back to the
caller.
clk_set_parent() compares this return value against NOTIFY_STOP only,
ignoring NOTIFY_BAD returns.

Use NOTIFY_STOP_MASK to detect a negative notifier return value and
document all four return value options.

Signed-off-by: Soren Brinkmann <soren.brinkmann at xilinx.com>
---
 drivers/clk/clk.c   | 10 +++++-----
 include/linux/clk.h |  8 ++++----
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index ed87b24..68bd38c 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -876,16 +876,16 @@ static int __clk_speculate_rates(struct clk *clk, unsigned long parent_rate)
 	else
 		new_rate = parent_rate;
 
-	/* abort the rate change if a driver returns NOTIFY_BAD */
+	/* abort rate change if a driver returns NOTIFY_BAD or NOTIFY_STOP */
 	if (clk->notifier_count)
 		ret = __clk_notify(clk, PRE_RATE_CHANGE, clk->rate, new_rate);
 
-	if (ret == NOTIFY_BAD)
+	if (ret & NOTIFY_STOP_MASK)
 		goto out;
 
 	hlist_for_each_entry(child, &clk->children, child_node) {
 		ret = __clk_speculate_rates(child, new_rate);
-		if (ret == NOTIFY_BAD)
+		if (ret & NOTIFY_STOP_MASK)
 			break;
 	}
 
@@ -978,7 +978,7 @@ static struct clk *clk_propagate_rate_change(struct clk *clk, unsigned long even
 
 	if (clk->notifier_count) {
 		ret = __clk_notify(clk, event, clk->rate, clk->new_rate);
-		if (ret == NOTIFY_BAD)
+		if (ret & NOTIFY_STOP_MASK)
 			fail_clk = clk;
 	}
 
@@ -1296,7 +1296,7 @@ int clk_set_parent(struct clk *clk, struct clk *parent)
 		ret = __clk_speculate_rates(clk, parent->rate);
 
 	/* abort if a driver objects */
-	if (ret == NOTIFY_STOP)
+	if (ret & NOTIFY_STOP_MASK)
 		goto out;
 
 	/* only re-parent if the clock is not in use */
diff --git a/include/linux/clk.h b/include/linux/clk.h
index b3ac22d..9a6d045 100644
--- a/include/linux/clk.h
+++ b/include/linux/clk.h
@@ -28,16 +28,16 @@ struct clk;
  * PRE_RATE_CHANGE - called immediately before the clk rate is changed,
  *     to indicate that the rate change will proceed.  Drivers must
  *     immediately terminate any operations that will be affected by the
- *     rate change.  Callbacks may either return NOTIFY_DONE or
- *     NOTIFY_STOP.
+ *     rate change.  Callbacks may either return NOTIFY_DONE, NOTIFY_OK,
+ *     NOTIFY_STOP or NOTIFY_BAD.
  *
  * ABORT_RATE_CHANGE: called if the rate change failed for some reason
  *     after PRE_RATE_CHANGE.  In this case, all registered notifiers on
  *     the clk will be called with ABORT_RATE_CHANGE. Callbacks must
- *     always return NOTIFY_DONE.
+ *     always return NOTIFY_DONE or NOTIFY_OK.
  *
  * POST_RATE_CHANGE - called after the clk rate change has successfully
- *     completed.  Callbacks must always return NOTIFY_DONE.
+ *     completed.  Callbacks must always return NOTIFY_DONE or NOTIFY_OK.
  *
  */
 #define PRE_RATE_CHANGE			BIT(0)
-- 
1.8.2




From linus.walleij at stericsson.com  Wed Apr  3 15:31:07 2013
From: linus.walleij at stericsson.com (Linus Walleij)
Date: Wed, 3 Apr 2013 21:31:07 +0200
Subject: [PATCH] pinctrl/pinconfig: add debug interface
Message-ID: <1365017467-23554-1-git-send-email-linus.walleij@stericsson.com>

From: Laurent Meunier <laurent.meunier at st.com>

This update adds a debugfs interface to modify a pin configuration
for a given state in the pinctrl map. This allows to modify the
configuration for a non-active state, typically sleep state.
This configuration is not applied right away, but only when the state
will be entered.

This solution is mandated for us by HW validation: in order
to test and verify several pin configurations during sleep without
recompiling the software.

Signed-off-by: Laurent Meunier <laurent.meunier at st.com>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 drivers/pinctrl/pinconf.c       | 231 ++++++++++++++++++++++++++++++++++++++++
 include/linux/pinctrl/pinconf.h |   4 +
 2 files changed, 235 insertions(+)

diff --git a/drivers/pinctrl/pinconf.c b/drivers/pinctrl/pinconf.c
index baee2cc..a95ac8d 100644
--- a/drivers/pinctrl/pinconf.c
+++ b/drivers/pinctrl/pinconf.c
@@ -17,6 +17,7 @@
 #include <linux/slab.h>
 #include <linux/debugfs.h>
 #include <linux/seq_file.h>
+#include <linux/uaccess.h>
 #include <linux/pinctrl/machine.h>
 #include <linux/pinctrl/pinctrl.h>
 #include <linux/pinctrl/pinconf.h>
@@ -574,6 +575,234 @@ static const struct file_operations pinconf_groups_ops = {
 	.release	= single_release,
 };
 
+/* 32bit read/write resources */
+#define MAX_NAME_LEN 15
+
+enum pinconf_dbg_request_type {
+	PINCONF_DBG_REQ_TYPE_INVALID,
+	PINCONF_DBG_REQ_TYPE_MODIFY,
+};
+
+struct dbg_cfg {
+	enum pinconf_dbg_request_type req_type;
+	enum pinctrl_map_type map_type;
+	char dev_name[MAX_NAME_LEN+1];
+	char state_name[MAX_NAME_LEN+1];
+	char pin_name[MAX_NAME_LEN+1];
+	char config[MAX_NAME_LEN+1];
+};
+
+static struct dbg_cfg pinconf_dbg_conf;
+
+/**
+ * pinconf_dbg_config_print() - display the pinctrl config from the pinctrl
+ * map, of a pin/state pair based on pinname and state that have been
+ * selected with the debugfs entries pinconf-name and pinconf-state
+ * @s: contains the 32bits config to be written
+ * @d: not used
+ */
+static int pinconf_dbg_config_print(struct seq_file *s, void *d)
+{
+	struct pinctrl_maps *maps_node;
+	struct pinctrl_map const *map;
+	struct pinctrl_dev *pctldev = NULL;
+	struct pinconf_ops const *confops = NULL;
+	int i, j;
+	bool found = false;
+	struct dbg_cfg *dbg = &pinconf_dbg_conf;
+	unsigned long config = 0;
+
+	mutex_lock(&pinctrl_mutex);
+
+	/* Parse the pinctrl map and look for the elected pin/state */
+	for_each_maps(maps_node, i, map) {
+		if (map->type != dbg->map_type)
+			continue;
+		if (strncmp(map->dev_name, dbg->dev_name, MAX_NAME_LEN) != 0)
+			continue;
+		if (strncmp(map->name, dbg->state_name, MAX_NAME_LEN) != 0)
+			continue;
+
+		for (j = 0; j < map->data.configs.num_configs; j++) {
+			if (0 == strncmp(map->data.configs.group_or_pin,
+						dbg->pin_name, MAX_NAME_LEN)) {
+				/*
+				 * We found the right pin / state, read the
+				 * config and store the pctldev
+				 */
+				config = map->data.configs.configs[j];
+				pctldev = get_pinctrl_dev_from_devname
+					(map->ctrl_dev_name);
+				found = true;
+				break;
+			}
+		}
+	}
+
+	mutex_unlock(&pinctrl_mutex);
+
+	if (!found) {
+		seq_printf(s, "No config found for dev/state/pin, expected:\n");
+		seq_printf(s, "modify config_pins devname " \
+			   "state pinname value\n");
+	}
+
+	seq_printf(s, "Dev %s has config of %s in state %s: 0x%08lX\n",
+		   dbg->dev_name, dbg->pin_name,
+		   dbg->state_name, config);
+
+	if (pctldev)
+		confops = pctldev->desc->confops;
+
+	if (confops && confops->pin_config_config_dbg_show)
+		confops->pin_config_config_dbg_show(pctldev,
+						    s, config);
+	return 0;
+}
+
+/**
+ * pinconf_dbg_config_write() - overwrite the pinctrl config in the pinctrl
+ * map, of a pin/state pair based on pinname and state that have been
+ * selected with the debugfs entries pinconf-name and pinconf-state
+ * @user_buf: contains 'modify configs_pin devicename state pinname newvalue'
+ */
+static int pinconf_dbg_config_write(struct file *file,
+	const char __user *user_buf, size_t count, loff_t *ppos)
+{
+	struct pinctrl_maps *maps_node;
+	struct pinctrl_map const *map;
+	struct pinctrl_dev *pctldev = NULL;
+	struct pinconf_ops const *confops = NULL;
+	struct dbg_cfg *dbg = &pinconf_dbg_conf;
+	bool found = false;
+	char buf[128];
+	char *b = &buf[0];
+	int buf_size;
+	char *token;
+	struct pinctrl_map_configs const *configs;
+	int i;
+
+	/* Get userspace string and assure termination */
+	buf_size = min(count, (sizeof(buf)-1));
+	if (copy_from_user(buf, user_buf, buf_size))
+		return -EFAULT;
+
+	buf[buf_size] = 0;
+
+	/*
+	 * need to parse entry and extract parameters:
+	 * modify configs_pin devicename state pinname newvalue
+	 */
+
+	/* Get arg: 'modify' */
+	if (!strncmp(b, "modify ", strlen("modify "))) {
+		dbg->req_type = PINCONF_DBG_REQ_TYPE_MODIFY;
+		b += strlen("modify ");
+	} else {
+		return -EINVAL;
+	}
+
+	/* Get arg type: "config_pin" type supported so far */
+	if (!strncmp(b, "config_pins ", strlen("config_pins "))) {
+		dbg->map_type = PIN_MAP_TYPE_CONFIGS_PIN;
+		b += strlen("config_pins ");
+	} else {
+		return -EINVAL;
+	}
+
+	/* get arg 'device_name' */
+	token = strsep(&b, " ");
+	if (token == NULL)
+		return -EINVAL;
+	if (strlen(token) < MAX_NAME_LEN)
+		sscanf(token, "%s", dbg->dev_name);
+	else
+		return -EINVAL;
+
+	/* get arg 'state_name' */
+	token = strsep(&b, " ");
+	if (token == NULL)
+		return -EINVAL;
+	if (strlen(token) < MAX_NAME_LEN)
+		sscanf(token, "%s", dbg->state_name);
+	else
+		return -EINVAL;
+
+	/* get arg 'pin_name' */
+	token = strsep(&b, " ");
+	if (token == NULL)
+		return -EINVAL;
+	if (strlen(token) < MAX_NAME_LEN)
+		sscanf(token, "%s", dbg->pin_name);
+	else
+		return -EINVAL;
+
+	/* get new_value of config' */
+	token = strsep(&b, " ");
+	if (token == NULL)
+		return -EINVAL;
+
+	if (strlen(token) < MAX_NAME_LEN)
+		sscanf(token, "%s", dbg->config);
+	else
+		return -EINVAL;
+
+	mutex_lock(&pinctrl_mutex);
+
+	/* Parse the pinctrl map and look for the selected dev/state/pin */
+	for_each_maps(maps_node, i, map) {
+		if (strncmp(map->dev_name, dbg->dev_name, MAX_NAME_LEN) != 0)
+			continue;
+		if (map->type != dbg->map_type)
+			continue;
+		if (strncmp(map->name, dbg->state_name, MAX_NAME_LEN) != 0)
+			continue;
+
+		/*  we found the right pin / state, so overwrite config */
+		if (strncmp(map->data.configs.group_or_pin,
+			dbg->pin_name, MAX_NAME_LEN) == 0) {
+
+			found = true;
+			pctldev = get_pinctrl_dev_from_devname(
+					map->ctrl_dev_name);
+			configs = &map->data.configs;
+			break;
+		}
+	}
+
+	mutex_unlock(&pinctrl_mutex);
+
+	if (!found)
+		return -EINVAL;
+
+	if (pctldev)
+		confops = pctldev->desc->confops;
+
+	if (confops && confops->pin_config_dbg_set) {
+		for (i = 0; i < configs->num_configs; i++) {
+			confops->pin_config_dbg_set(pctldev,
+						    dbg->config,
+						    configs->configs[i]);
+		}
+	}
+
+	return count;
+}
+
+static int pinconf_dbg_config_open(struct inode *inode, struct file *file)
+{
+	return single_open(file, pinconf_dbg_config_print, inode->i_private);
+}
+
+static const struct file_operations pinconf_dbg_pinconfig_fops = {
+	.open = pinconf_dbg_config_open,
+	.write = pinconf_dbg_config_write,
+	.read = seq_read,
+	.llseek = seq_lseek,
+	.release = single_release,
+	.owner = THIS_MODULE,
+};
+
 void pinconf_init_device_debugfs(struct dentry *devroot,
 			 struct pinctrl_dev *pctldev)
 {
@@ -581,6 +810,8 @@ void pinconf_init_device_debugfs(struct dentry *devroot,
 			    devroot, pctldev, &pinconf_pins_ops);
 	debugfs_create_file("pinconf-groups", S_IFREG | S_IRUGO,
 			    devroot, pctldev, &pinconf_groups_ops);
+	debugfs_create_file("pinconf-config",  (S_IRUGO | S_IWUSR | S_IWGRP),
+			    devroot, pctldev, &pinconf_dbg_pinconfig_fops);
 }
 
 #endif
diff --git a/include/linux/pinctrl/pinconf.h b/include/linux/pinctrl/pinconf.h
index e7a7201..2cc8d2c 100644
--- a/include/linux/pinctrl/pinconf.h
+++ b/include/linux/pinctrl/pinconf.h
@@ -28,6 +28,7 @@ struct seq_file;
  * @pin_config_set: configure an individual pin
  * @pin_config_group_get: get configurations for an entire pin group
  * @pin_config_group_set: configure all pins in a group
+ * @pin_config_group_dbg_set: optional debugfs to modify a pin configuration
  * @pin_config_dbg_show: optional debugfs display hook that will provide
  *	per-device info for a certain pin in debugfs
  * @pin_config_group_dbg_show: optional debugfs display hook that will provide
@@ -51,6 +52,9 @@ struct pinconf_ops {
 	int (*pin_config_group_set) (struct pinctrl_dev *pctldev,
 				     unsigned selector,
 				     unsigned long config);
+	int (*pin_config_dbg_set) (struct pinctrl_dev *pctldev,
+				   const char *arg,
+				   unsigned long config);
 	void (*pin_config_dbg_show) (struct pinctrl_dev *pctldev,
 				     struct seq_file *s,
 				     unsigned offset);
-- 
1.7.11.3



From paul at pwsan.com  Wed Apr  3 15:42:22 2013
From: paul at pwsan.com (Paul Walmsley)
Date: Wed, 3 Apr 2013 19:42:22 +0000 (UTC)
Subject: [GIT PULL] ARM: OMAP5: hwmod, prm/cm data files and updates for
 3.10
In-Reply-To: <515BA76D.3000302@ti.com>
References: <1363768852-18125-1-git-send-email-santosh.shilimkar@ti.com>
 <20130401170539.GK10155@atomide.com> <515BA76D.3000302@ti.com>
Message-ID: <alpine.DEB.2.00.1304031146230.2616@utopia.booyaka.com>

Hi Santosh

On Wed, 3 Apr 2013, Santosh Shilimkar wrote:

> Thes patchset has already missed last couple of merge windows and its the
> biggest bottleneck in getting OMAP5 booting from mainline. So I request
> you to please have a look it quickly so that Tony can line that up for
> 3.10.

Looks like there are a few minor issues with the patches based on a quick 
look.  I'll post those to the list shortly; they should be easy to fix.  
But those issues aren't my real concern with this series.

What's harder to fix are the underlying process issues.  My main concern 
is that these patches add almost 9,000 lines of code and data.  We've 
received clear guidance from the upstream ARM SoC maintainers that any 
significant new additions need to be balanced with moving a similar number 
of lines of code and data out of arch/arm/{plat-,mach-}* into drivers/.  
(Or the new patches should be accompanied with patches that show obvious 
progress towards the goal of moving code and data out of 
arch/arm/{plat-,mach-}*.)  We need to see more help from TI on the 
prerequisites for this cleanup process.

For example, as discussed last year with the TI upstream PM team, an 
important first step in this process in my view is to get rid of the 
direct PRM/CM register accesses in the OMAP PM code.  See commit 
c4ceedcb18cf7a06059482a3a1828b9aad9f78cf ("ARM: OMAP2+: CM/clock: convert 
_omap2_module_wait_ready() to use SoC-independent CM functions") as an 
example of this process.  This should make it easier to get the PRM/CM 
functionality into drivers/.  That in turn make it possible to move the 
clockdomain, clock, powerdomain, and hwmod code to drivers/.ARM: OMAP2+: 
CM/clock: convert _omap2_module_wait_ready() to use SoC-independent CM 
functions.  So far as I can tell, there hasn't been any forward progress 
on this.

It's also necessary to see more TI contributions in finding and fixing 
regressions.  Detecting and fixing regressions from the previous kernel 
release should be done first, before working on cleanup series or new 
feature/SoC additions.  Looking at the list of v3.9-rc regressions that 
I've found, we've gotten very little organized help from TI on dealing 
with them.  

This in turn robs the maintainers of time that could be spent doing patch 
review or further cleanup work, which benefits no one in the end.  
Ideally each regression would be assigned to a member of the TI upstream 
team, and the whole process could be completed within one or two weeks.

...

So from my point of view, I'd like to see the following changes before we 
accept any new patchsets that add a significant number of lines:

1. Organized help from TI in finding and fixing regressions in the -rc 
cycle, with the regressions dealt with before any new feature 
pull-requests are sent

2. Help from TI on some of the cleanup work that we've mentioned in the 
past, starting with the PRM/CM register access cleanup inside mach-omap2/

3. Pairing any large feature or SoC additions with at least an equal 
removal of lines of code


regards,

- Paul


From khilman at linaro.org  Wed Apr  3 15:44:47 2013
From: khilman at linaro.org (Kevin Hilman)
Date: Wed, 03 Apr 2013 12:44:47 -0700
Subject: [PATCH v2 01/18] ARM: OMAP4+: PM: Consolidate MPU subsystem PM
 code for re-use
In-Reply-To: <1364205910-32392-2-git-send-email-santosh.shilimkar@ti.com>
 (Santosh Shilimkar's message of "Mon, 25 Mar 2013 15:34:53 +0530")
References: <1364205910-32392-1-git-send-email-santosh.shilimkar@ti.com>
 <1364205910-32392-2-git-send-email-santosh.shilimkar@ti.com>
Message-ID: <87a9pfxuts.fsf@linaro.org>

Hi Santosh,

Santosh Shilimkar <santosh.shilimkar at ti.com> writes:

> OMAP5 and future OMAP based SOCs has backward compatible MPUSS
> IP block with OMAP4. It's programming model is mostly similar.
> Hence consolidate the OMAP MPUSS code so that it can be re-used
> on OMAP5 and future SOCs.
>
> No functional change.
>
> Acked-by: Nishanth Menon <nm at ti.com>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
> ---
>  arch/arm/mach-omap2/omap-mpuss-lowpower.c |   65 ++++++++++++++++++++++++-----
>  1 file changed, 54 insertions(+), 11 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
> index d650f91..d9e4843 100644
> --- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
> +++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
> @@ -71,10 +71,46 @@ struct omap4_cpu_pm_info {
>  	void (*secondary_startup)(void);
>  };
>  
> +/**
> + * struct cpu_pm_ops - CPU pm operations
> + * @finish_suspend:	CPU suspend finisher function pointer
> + * @resume:		CPU resume function pointer
> + * @scu_prepare:	CPU Snoop Control program function pointer
> + *
> + * Structure holds functions pointer for CPU low power operations like
> + * suspend, resume and scu programming.
> + */
> +struct cpu_pm_ops {
> +	int (*finish_suspend)(unsigned long cpu_state);
> +	void (*resume)(void);
> +	void (*scu_prepare)(unsigned int cpu_id, unsigned int cpu_state);
> +};
> +
> +extern int omap4_finish_suspend(unsigned long cpu_state);
> +extern void omap4_cpu_resume(void);

checkpatch should've yelled at you for adding externs to .c files.

Also, aren't these already defined in common.h anyways?

Otherwise, patch looks fine.

Kevin

>  static DEFINE_PER_CPU(struct omap4_cpu_pm_info, omap4_pm_info);
>  static struct powerdomain *mpuss_pd;
>  static void __iomem *sar_base;
>  
> +static int default_finish_suspend(unsigned long cpu_state)
> +{
> +	omap_do_wfi();
> +	return 0;
> +}
> +
> +static void dummy_cpu_resume(void)
> +{}
> +
> +static void dummy_scu_prepare(unsigned int cpu_id, unsigned int cpu_state)
> +{}
> +
> +struct cpu_pm_ops omap_pm_ops = {
> +	.finish_suspend		= default_finish_suspend,
> +	.resume			= dummy_cpu_resume,
> +	.scu_prepare		= dummy_scu_prepare,
> +};
> +
>  /*
>   * Program the wakeup routine address for the CPU0 and CPU1
>   * used for OFF or DORMANT wakeup.
> @@ -172,11 +208,12 @@ static void save_l2x0_context(void)
>  {
>  	u32 val;
>  	void __iomem *l2x0_base = omap4_get_l2cache_base();
> -
> -	val = __raw_readl(l2x0_base + L2X0_AUX_CTRL);
> -	__raw_writel(val, sar_base + L2X0_AUXCTRL_OFFSET);
> -	val = __raw_readl(l2x0_base + L2X0_PREFETCH_CTRL);
> -	__raw_writel(val, sar_base + L2X0_PREFETCH_CTRL_OFFSET);
> +	if (l2x0_base) {
> +		val = __raw_readl(l2x0_base + L2X0_AUX_CTRL);
> +		__raw_writel(val, sar_base + L2X0_AUXCTRL_OFFSET);
> +		val = __raw_readl(l2x0_base + L2X0_PREFETCH_CTRL);
> +		__raw_writel(val, sar_base + L2X0_PREFETCH_CTRL_OFFSET);
> +	}
>  }
>  #else
>  static void save_l2x0_context(void)
> @@ -239,17 +276,17 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int power_state)
>  
>  	cpu_clear_prev_logic_pwrst(cpu);
>  	pwrdm_set_next_pwrst(pm_info->pwrdm, power_state);
> -	set_cpu_wakeup_addr(cpu, virt_to_phys(omap4_cpu_resume));
> -	scu_pwrst_prepare(cpu, power_state);
> +	set_cpu_wakeup_addr(cpu, virt_to_phys(omap_pm_ops.resume));
> +	omap_pm_ops.scu_prepare(cpu, power_state);
>  	l2x0_pwrst_prepare(cpu, save_state);
>  
>  	/*
>  	 * Call low level function  with targeted low power state.
>  	 */
>  	if (save_state)
> -		cpu_suspend(save_state, omap4_finish_suspend);
> +		cpu_suspend(save_state, omap_pm_ops.finish_suspend);
>  	else
> -		omap4_finish_suspend(save_state);
> +		omap_pm_ops.finish_suspend(save_state);
>  
>  	/*
>  	 * Restore the CPUx power state to ON otherwise CPUx
> @@ -285,14 +322,14 @@ int __cpuinit omap4_hotplug_cpu(unsigned int cpu, unsigned int power_state)
>  	pwrdm_clear_all_prev_pwrst(pm_info->pwrdm);
>  	pwrdm_set_next_pwrst(pm_info->pwrdm, power_state);
>  	set_cpu_wakeup_addr(cpu, virt_to_phys(pm_info->secondary_startup));
> -	scu_pwrst_prepare(cpu, power_state);
> +	omap_pm_ops.scu_prepare(cpu, power_state);
>  
>  	/*
>  	 * CPU never retuns back if targeted power state is OFF mode.
>  	 * CPU ONLINE follows normal CPU ONLINE ptah via
>  	 * omap_secondary_startup().
>  	 */
> -	omap4_finish_suspend(cpu_state);
> +	omap_pm_ops.finish_suspend(cpu_state);
>  
>  	pwrdm_set_next_pwrst(pm_info->pwrdm, PWRDM_POWER_ON);
>  	return 0;
> @@ -369,6 +406,12 @@ int __init omap4_mpuss_init(void)
>  
>  	save_l2x0_context();
>  
> +	if (cpu_is_omap44xx()) {
> +		omap_pm_ops.finish_suspend = omap4_finish_suspend;
> +		omap_pm_ops.resume = omap4_cpu_resume;
> +		omap_pm_ops.scu_prepare = scu_pwrst_prepare;
> +	}
> +
>  	return 0;
>  }


From linus.walleij at stericsson.com  Wed Apr  3 15:47:27 2013
From: linus.walleij at stericsson.com (Linus Walleij)
Date: Wed, 3 Apr 2013 21:47:27 +0200
Subject: [PATCH v2] pinctrl/pinconfig: add debug interface
Message-ID: <1365018447-28062-1-git-send-email-linus.walleij@stericsson.com>

From: Laurent Meunier <laurent.meunier at st.com>

This update adds a debugfs interface to modify a pin configuration
for a given state in the pinctrl map. This allows to modify the
configuration for a non-active state, typically sleep state.
This configuration is not applied right away, but only when the state
will be entered.

This solution is mandated for us by HW validation: in order
to test and verify several pin configurations during sleep without
recompiling the software.

Signed-off-by: Laurent Meunier <laurent.meunier at st.com>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
ChangeLog v1->v2:
- Change name of the debugfs string processing function in the
  driver API to pin_config_dbg_parse() because that is what it
  shall do, then have that be passed a pointer to fill in the
  parsed result.
---
 drivers/pinctrl/pinconf.c       | 231 ++++++++++++++++++++++++++++++++++++++++
 include/linux/pinctrl/pinconf.h |   4 +
 2 files changed, 235 insertions(+)

diff --git a/drivers/pinctrl/pinconf.c b/drivers/pinctrl/pinconf.c
index baee2cc..faabc25 100644
--- a/drivers/pinctrl/pinconf.c
+++ b/drivers/pinctrl/pinconf.c
@@ -17,6 +17,7 @@
 #include <linux/slab.h>
 #include <linux/debugfs.h>
 #include <linux/seq_file.h>
+#include <linux/uaccess.h>
 #include <linux/pinctrl/machine.h>
 #include <linux/pinctrl/pinctrl.h>
 #include <linux/pinctrl/pinconf.h>
@@ -574,6 +575,234 @@ static const struct file_operations pinconf_groups_ops = {
 	.release	= single_release,
 };
 
+/* 32bit read/write resources */
+#define MAX_NAME_LEN 15
+
+enum pinconf_dbg_request_type {
+	PINCONF_DBG_REQ_TYPE_INVALID,
+	PINCONF_DBG_REQ_TYPE_MODIFY,
+};
+
+struct dbg_cfg {
+	enum pinconf_dbg_request_type req_type;
+	enum pinctrl_map_type map_type;
+	char dev_name[MAX_NAME_LEN+1];
+	char state_name[MAX_NAME_LEN+1];
+	char pin_name[MAX_NAME_LEN+1];
+	char config[MAX_NAME_LEN+1];
+};
+
+static struct dbg_cfg pinconf_dbg_conf;
+
+/**
+ * pinconf_dbg_config_print() - display the pinctrl config from the pinctrl
+ * map, of a pin/state pair based on pinname and state that have been
+ * selected with the debugfs entries pinconf-name and pinconf-state
+ * @s: contains the 32bits config to be written
+ * @d: not used
+ */
+static int pinconf_dbg_config_print(struct seq_file *s, void *d)
+{
+	struct pinctrl_maps *maps_node;
+	struct pinctrl_map const *map;
+	struct pinctrl_dev *pctldev = NULL;
+	struct pinconf_ops const *confops = NULL;
+	int i, j;
+	bool found = false;
+	struct dbg_cfg *dbg = &pinconf_dbg_conf;
+	unsigned long config = 0;
+
+	mutex_lock(&pinctrl_mutex);
+
+	/* Parse the pinctrl map and look for the elected pin/state */
+	for_each_maps(maps_node, i, map) {
+		if (map->type != dbg->map_type)
+			continue;
+		if (strncmp(map->dev_name, dbg->dev_name, MAX_NAME_LEN) != 0)
+			continue;
+		if (strncmp(map->name, dbg->state_name, MAX_NAME_LEN) != 0)
+			continue;
+
+		for (j = 0; j < map->data.configs.num_configs; j++) {
+			if (0 == strncmp(map->data.configs.group_or_pin,
+						dbg->pin_name, MAX_NAME_LEN)) {
+				/*
+				 * We found the right pin / state, read the
+				 * config and store the pctldev
+				 */
+				config = map->data.configs.configs[j];
+				pctldev = get_pinctrl_dev_from_devname
+					(map->ctrl_dev_name);
+				found = true;
+				break;
+			}
+		}
+	}
+
+	mutex_unlock(&pinctrl_mutex);
+
+	if (!found) {
+		seq_printf(s, "No config found for dev/state/pin, expected:\n");
+		seq_printf(s, "modify config_pins devname " \
+			   "state pinname value\n");
+	}
+
+	seq_printf(s, "Dev %s has config of %s in state %s: 0x%08lX\n",
+		   dbg->dev_name, dbg->pin_name,
+		   dbg->state_name, config);
+
+	if (pctldev)
+		confops = pctldev->desc->confops;
+
+	if (confops && confops->pin_config_config_dbg_show)
+		confops->pin_config_config_dbg_show(pctldev,
+						    s, config);
+	return 0;
+}
+
+/**
+ * pinconf_dbg_config_write() - overwrite the pinctrl config in the pinctrl
+ * map, of a pin/state pair based on pinname and state that have been
+ * selected with the debugfs entries pinconf-name and pinconf-state
+ * @user_buf: contains 'modify configs_pin devicename state pinname newvalue'
+ */
+static int pinconf_dbg_config_write(struct file *file,
+	const char __user *user_buf, size_t count, loff_t *ppos)
+{
+	struct pinctrl_maps *maps_node;
+	struct pinctrl_map const *map;
+	struct pinctrl_dev *pctldev = NULL;
+	struct pinconf_ops const *confops = NULL;
+	struct dbg_cfg *dbg = &pinconf_dbg_conf;
+	bool found = false;
+	char buf[128];
+	char *b = &buf[0];
+	int buf_size;
+	char *token;
+	struct pinctrl_map_configs const *configs;
+	int i;
+
+	/* Get userspace string and assure termination */
+	buf_size = min(count, (sizeof(buf)-1));
+	if (copy_from_user(buf, user_buf, buf_size))
+		return -EFAULT;
+
+	buf[buf_size] = 0;
+
+	/*
+	 * need to parse entry and extract parameters:
+	 * modify configs_pin devicename state pinname newvalue
+	 */
+
+	/* Get arg: 'modify' */
+	if (!strncmp(b, "modify ", strlen("modify "))) {
+		dbg->req_type = PINCONF_DBG_REQ_TYPE_MODIFY;
+		b += strlen("modify ");
+	} else {
+		return -EINVAL;
+	}
+
+	/* Get arg type: "config_pin" type supported so far */
+	if (!strncmp(b, "config_pins ", strlen("config_pins "))) {
+		dbg->map_type = PIN_MAP_TYPE_CONFIGS_PIN;
+		b += strlen("config_pins ");
+	} else {
+		return -EINVAL;
+	}
+
+	/* get arg 'device_name' */
+	token = strsep(&b, " ");
+	if (token == NULL)
+		return -EINVAL;
+	if (strlen(token) < MAX_NAME_LEN)
+		sscanf(token, "%s", dbg->dev_name);
+	else
+		return -EINVAL;
+
+	/* get arg 'state_name' */
+	token = strsep(&b, " ");
+	if (token == NULL)
+		return -EINVAL;
+	if (strlen(token) < MAX_NAME_LEN)
+		sscanf(token, "%s", dbg->state_name);
+	else
+		return -EINVAL;
+
+	/* get arg 'pin_name' */
+	token = strsep(&b, " ");
+	if (token == NULL)
+		return -EINVAL;
+	if (strlen(token) < MAX_NAME_LEN)
+		sscanf(token, "%s", dbg->pin_name);
+	else
+		return -EINVAL;
+
+	/* get new_value of config' */
+	token = strsep(&b, " ");
+	if (token == NULL)
+		return -EINVAL;
+
+	if (strlen(token) < MAX_NAME_LEN)
+		sscanf(token, "%s", dbg->config);
+	else
+		return -EINVAL;
+
+	mutex_lock(&pinctrl_mutex);
+
+	/* Parse the pinctrl map and look for the selected dev/state/pin */
+	for_each_maps(maps_node, i, map) {
+		if (strncmp(map->dev_name, dbg->dev_name, MAX_NAME_LEN) != 0)
+			continue;
+		if (map->type != dbg->map_type)
+			continue;
+		if (strncmp(map->name, dbg->state_name, MAX_NAME_LEN) != 0)
+			continue;
+
+		/*  we found the right pin / state, so overwrite config */
+		if (strncmp(map->data.configs.group_or_pin,
+			dbg->pin_name, MAX_NAME_LEN) == 0) {
+
+			found = true;
+			pctldev = get_pinctrl_dev_from_devname(
+					map->ctrl_dev_name);
+			configs = &map->data.configs;
+			break;
+		}
+	}
+
+	mutex_unlock(&pinctrl_mutex);
+
+	if (!found)
+		return -EINVAL;
+
+	if (pctldev)
+		confops = pctldev->desc->confops;
+
+	if (confops && confops->pin_config_dbg_parse) {
+		for (i = 0; i < configs->num_configs; i++) {
+			confops->pin_config_dbg_parse(pctldev,
+						    dbg->config,
+						    &configs->configs[i]);
+		}
+	}
+
+	return count;
+}
+
+static int pinconf_dbg_config_open(struct inode *inode, struct file *file)
+{
+	return single_open(file, pinconf_dbg_config_print, inode->i_private);
+}
+
+static const struct file_operations pinconf_dbg_pinconfig_fops = {
+	.open = pinconf_dbg_config_open,
+	.write = pinconf_dbg_config_write,
+	.read = seq_read,
+	.llseek = seq_lseek,
+	.release = single_release,
+	.owner = THIS_MODULE,
+};
+
 void pinconf_init_device_debugfs(struct dentry *devroot,
 			 struct pinctrl_dev *pctldev)
 {
@@ -581,6 +810,8 @@ void pinconf_init_device_debugfs(struct dentry *devroot,
 			    devroot, pctldev, &pinconf_pins_ops);
 	debugfs_create_file("pinconf-groups", S_IFREG | S_IRUGO,
 			    devroot, pctldev, &pinconf_groups_ops);
+	debugfs_create_file("pinconf-config",  (S_IRUGO | S_IWUSR | S_IWGRP),
+			    devroot, pctldev, &pinconf_dbg_pinconfig_fops);
 }
 
 #endif
diff --git a/include/linux/pinctrl/pinconf.h b/include/linux/pinctrl/pinconf.h
index e7a7201..fbe02de 100644
--- a/include/linux/pinctrl/pinconf.h
+++ b/include/linux/pinctrl/pinconf.h
@@ -28,6 +28,7 @@ struct seq_file;
  * @pin_config_set: configure an individual pin
  * @pin_config_group_get: get configurations for an entire pin group
  * @pin_config_group_set: configure all pins in a group
+ * @pin_config_dbg_parse: optional debugfs to parse a string pin configuration
  * @pin_config_dbg_show: optional debugfs display hook that will provide
  *	per-device info for a certain pin in debugfs
  * @pin_config_group_dbg_show: optional debugfs display hook that will provide
@@ -51,6 +52,9 @@ struct pinconf_ops {
 	int (*pin_config_group_set) (struct pinctrl_dev *pctldev,
 				     unsigned selector,
 				     unsigned long config);
+	int (*pin_config_dbg_parse) (struct pinctrl_dev *pctldev,
+				   const char *arg,
+				   unsigned long *config);
 	void (*pin_config_dbg_show) (struct pinctrl_dev *pctldev,
 				     struct seq_file *s,
 				     unsigned offset);
-- 
1.7.11.3



From mturquette at linaro.org  Wed Apr  3 15:59:13 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Wed, 03 Apr 2013 12:59:13 -0700
Subject: [PATCH] ARM: mvebu: Use common of_clk_init() function
In-Reply-To: <20130403004332.8177.71536@quantum>
References: <20130402130236.683fa734@armhf> <20130403004332.8177.71536@quantum>
Message-ID: <20130403195913.3383.82857@quantum>

Quoting Mike Turquette (2013-04-02 17:43:32)
> Quoting Jean-Francois Moine (2013-04-02 04:02:36)
> > The use common of_clk_init() function simplifies the clock initialization
> > and adds handling of the DT "fixed-clock".
> > 
> > Signed-off-by: Jean-Francois Moine <moinejf at free.fr>
> 
> This is a nice change.  Taken into clk-next.
> 

When I applied this patch I modified the $SUBJECT line as:

clk: mvebu: Use common of_clk_init() function

Regards,
Mike

> Regards,
> Mike
> 
> > ---
> >  drivers/clk/mvebu/clk-cpu.c |   17 ++---------------
> >  drivers/clk/mvebu/clk-cpu.h |   22 ----------------------
> >  drivers/clk/mvebu/clk.c     |    6 +-----
> >  3 files changed, 3 insertions(+), 42 deletions(-)
> >  delete mode 100644 drivers/clk/mvebu/clk-cpu.h
> > 
> > diff --git a/drivers/clk/mvebu/clk-cpu.c b/drivers/clk/mvebu/clk-cpu.c
> > index 9dd2551..b0fbc07 100644
> > --- a/drivers/clk/mvebu/clk-cpu.c
> > +++ b/drivers/clk/mvebu/clk-cpu.c
> > @@ -16,7 +16,6 @@
> >  #include <linux/io.h>
> >  #include <linux/of.h>
> >  #include <linux/delay.h>
> > -#include "clk-cpu.h"
> >  
> >  #define SYS_CTRL_CLK_DIVIDER_CTRL_OFFSET    0x0
> >  #define SYS_CTRL_CLK_DIVIDER_VALUE_OFFSET   0xC
> > @@ -173,17 +172,5 @@ clks_out:
> >         kfree(cpuclk);
> >  }
> >  
> > -static const __initconst struct of_device_id clk_cpu_match[] = {
> > -       {
> > -               .compatible = "marvell,armada-xp-cpu-clock",
> > -               .data = of_cpu_clk_setup,
> > -       },
> > -       {
> > -               /* sentinel */
> > -       },
> > -};
> > -
> > -void __init mvebu_cpu_clk_init(void)
> > -{
> > -       of_clk_init(clk_cpu_match);
> > -}
> > +CLK_OF_DECLARE(armada_xp_cpu_clock, "marvell,armada-xp-cpu-clock",
> > +                                        of_cpu_clk_setup);
> > diff --git a/drivers/clk/mvebu/clk-cpu.h b/drivers/clk/mvebu/clk-cpu.h
> > deleted file mode 100644
> > index 08e2aff..0000000
> > --- a/drivers/clk/mvebu/clk-cpu.h
> > +++ /dev/null
> > @@ -1,22 +0,0 @@
> > -/*
> > - * Marvell MVEBU CPU clock handling.
> > - *
> > - * Copyright (C) 2012 Marvell
> > - *
> > - * Gregory CLEMENT <gregory.clement at free-electrons.com>
> > - *
> > - * 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.
> > - */
> > -
> > -#ifndef __MVEBU_CLK_CPU_H
> > -#define __MVEBU_CLK_CPU_H
> > -
> > -#ifdef CONFIG_MVEBU_CLK_CPU
> > -void __init mvebu_cpu_clk_init(void);
> > -#else
> > -static inline void mvebu_cpu_clk_init(void) {}
> > -#endif
> > -
> > -#endif
> > diff --git a/drivers/clk/mvebu/clk.c b/drivers/clk/mvebu/clk.c
> > index 855681b..29f10fb 100644
> > --- a/drivers/clk/mvebu/clk.c
> > +++ b/drivers/clk/mvebu/clk.c
> > @@ -10,18 +10,14 @@
> >   * warranty of any kind, whether express or implied.
> >   */
> >  #include <linux/kernel.h>
> > -#include <linux/clk.h>
> >  #include <linux/clk-provider.h>
> > -#include <linux/of_address.h>
> > -#include <linux/clk/mvebu.h>
> >  #include <linux/of.h>
> >  #include "clk-core.h"
> > -#include "clk-cpu.h"
> >  #include "clk-gating-ctrl.h"
> >  
> >  void __init mvebu_clocks_init(void)
> >  {
> >         mvebu_core_clk_init();
> >         mvebu_gating_clk_init();
> > -       mvebu_cpu_clk_init();
> > +       of_clk_init(NULL);
> >  }
> > -- 
> > 1.7.10.4
> > 
> > 
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From paul at pwsan.com  Wed Apr  3 16:09:31 2013
From: paul at pwsan.com (Paul Walmsley)
Date: Wed, 3 Apr 2013 20:09:31 +0000 (UTC)
Subject: [GIT PULL] ARM: OMAP5: hwmod, prm/cm data files and updates for
 3.10
In-Reply-To: <1363768852-18125-1-git-send-email-santosh.shilimkar@ti.com>
References: <1363768852-18125-1-git-send-email-santosh.shilimkar@ti.com>
Message-ID: <alpine.DEB.2.00.1304031953010.16711@utopia.booyaka.com>

cc Kevin

Hi

On Wed, 20 Mar 2013, Santosh Shilimkar wrote:

> Benoit Cousson (7):
>       ARM: OMAP5: PRM: Add OMAP54XX register and bitfield files

So it looks like this patch never made it to the mailing list.  Was it too 
big?  If so, please try splitting it into two or more pieces.  Looking at 
the git branch that you posted for pulling, the patch adds two files, so 
maybe you can just create one patch for each file?

Also, looking at the bottom of the arch/arm/mach-omap2/prm54xx.h from this 
commit 600e78bb51c0ee081f0da14f879c3e4a1dee9896, there are a bunch of 
function prototypes that reference OMAP44xx.  Shouldn't these reference 
OMAP54xx, or be removed from this file?  If you're reusing the OMAP4 PRM 
functions for OMAP5, then shouldn't they be moved out from the OMAP4 
header files into a separate header file?

>       ARM: OMAP5: CM: Add OMAP54XX register and bitfield files

There are similar problems with this patch.  It doesn't look like it ever 
made it to the linux-omap list, in my inbox, anyway.  And again the 
function prototypes make several references to OMAP4, when they should 
refer to OMAP5 or be removed from this file.

>       ARM: OMAP5: PRCM: Add OMAP54XX local MPU PRCM registers

More duplicated OMAP4 function prototypes here.

>       ARM: OMAP5: SCRM: Add OMAP54XX header file.

Looks fine to me.

>       ARM: OMAP2+: clockdomain data: Add OMAP54XX data and update the header
>       ARM: OMAP5: powerdomain data: Add OMAP54XX data and update the header

These two look okay to me based on a superficial inspection.  Is there a 
public TRM posted for OMAP5?  It's not in the obvious place, so there's no 
way to review these against the TRM:

http://www.ti.com/lsds/ti/omap-applications-processors/technical-documents.page?familyId=601&docCategoryId=6

>       ARM: OMAP5: hwmod data: Create initial OMAP5 SOC hwmod data

Looks like this one hasn't been reposted after the changes that were made 
to it after Tony's comments?  If I've just missed the list post, please 
send a link.  Otherwise, the updated patch should be reposted.

> Santosh Shilimkar (4):
>       ARM: OMAP5: hwmod_data: Fix UART sysc settings
>       ARM: OMAP5: hwmod-data: Add timer clock activity flags

These two should be rolled into the "ARM: OMAP5: hwmod data: Create 
initial OMAP5 SOC hwmod data" patch.

>       ARM: OMAP5: voltagedomain data: Add OMAP5 voltage domain data

This one needs to be acked by Kevin.

>       ARM: OMAP5: Enable build and frameowrk initialisations

Looks fine to me.


- Paul


From paul at pwsan.com  Wed Apr  3 16:13:36 2013
From: paul at pwsan.com (Paul Walmsley)
Date: Wed, 3 Apr 2013 20:13:36 +0000 (UTC)
Subject: [PATCH 00/10] ARM: OMAP5: hwmod, clock and prm data files
In-Reply-To: <1358522856-12180-1-git-send-email-santosh.shilimkar@ti.com>
References: <1358522856-12180-1-git-send-email-santosh.shilimkar@ti.com>
Message-ID: <alpine.DEB.2.00.1304032012260.16711@utopia.booyaka.com>

Hi,

On Fri, 18 Jan 2013, Santosh Shilimkar wrote:

> Series contains the hwmod, clock and prm data files for OMAP54xx SOCs.
> This data was kept out of tree to be validated on es2.0 silicon version
> and also to avoid the es1.0/es2.0 differences which are many.
> 
> Benoit Cousson, Rajendra Nayak, Paul Walmesly and Mike have all contributed
> to get the autogen scripts in shape for OMAP5.
> 
> >From various discussion on the list, the clock data files are suppose
> to be moved to drivers/clk/. Once the direction is clear, patch 8
> can be updated accordingly.
> 
> Patches are tested on OMAP5 sEVM and uEVM. For testing few additional patches
> are needed. Same tree can be fetched from here [1]
> 
> The following changes since commit 7d1f9aeff1ee4a20b1aeb377dd0f579fe9647619:
> 
>   Linux 3.8-rc4 (2013-01-17 19:25:45 -0800)
> 
> are available in the git repository at:
> 
>   git://github.com/SantoshShilimkar/linux.git for_3.9/omap5_data_files
> 
> for you to fetch changes up to 7f534e1ebeb2bc64250b56fe00eb7d4dfa585e8e:
> 
>   ARM: OMAP5: Enable build and frameowrk initialisations (2013-01-18 19:45:48 +0530)

I've posted several comments on the patch contents themselves, all of 
which are relatively minor, and should be easy to fix:

http://marc.info/?l=linux-omap&m=136501977311223&w=2


- Paul


From linus.walleij at stericsson.com  Wed Apr  3 16:15:44 2013
From: linus.walleij at stericsson.com (Linus Walleij)
Date: Wed, 3 Apr 2013 22:15:44 +0200
Subject: [PATCH] pinctrl/abx500: fix ab9540 alternate function
Message-ID: <1365020144-28781-1-git-send-email-linus.walleij@stericsson.com>

From: Patrice Chotard <patrice.chotard at st.com>

This fix allows to correctly select default and
alternate pin mode.

By default for all ABx500 family chip, pin default
mode is selected by clearing corresponding bit in
GPIOSELx register except for pins which support
alternate function, in this case, corresponding bit
must be set.

But, due to an unlogical hardware implementation,
for one particular pin (GPIO11) reverse setting
must be done. For that, update the alternate function
array by declaring that this pin supports alternate
function.
Same issue has been fixed in pinctrl-ab8505.c

Signed-off-by: Patrice Chotard <patrice.chotard at st.com>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 drivers/pinctrl/pinctrl-ab9540.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pinctrl/pinctrl-ab9540.c b/drivers/pinctrl/pinctrl-ab9540.c
index 7610bd0..80f3173 100644
--- a/drivers/pinctrl/pinctrl-ab9540.c
+++ b/drivers/pinctrl/pinctrl-ab9540.c
@@ -393,7 +393,7 @@ struct alternate_functions ab9540alternate_functions[AB9540_GPIO_MAX_NUMBER + 1]
 	/* GPIOSEL2 - bits 0 and 3 are reserved */
 	ALTERNATE_FUNCTIONS(9, UNUSED, UNUSED, UNUSED, 0, 0, 0), /* no GPIO9 */
 	ALTERNATE_FUNCTIONS(10,      1,      0, UNUSED, 1, 0, 0), /* GPIO10, altA and altB controlled by bit 0 */
-	ALTERNATE_FUNCTIONS(11,      2, UNUSED, UNUSED, 0, 0, 0), /* GPIO11, altA controlled by bit 1 */
+	ALTERNATE_FUNCTIONS(11,      2,	     1, UNUSED, 0, 0, 0), /* GPIO11, altA controlled by bit 1 */
 	ALTERNATE_FUNCTIONS(12, UNUSED, UNUSED, UNUSED, 0, 0, 0), /* no GPIO12 */
 	ALTERNATE_FUNCTIONS(13,      4,      3,      4, 1, 0, 2), /* GPIO13, altA altB and altC controlled by bit 3 and 4 */
 	ALTERNATE_FUNCTIONS(14,      5, UNUSED, UNUSED, 0, 0, 0), /* GPIO14, altA controlled by bit 5 */
-- 
1.7.11.3



From paul at pwsan.com  Wed Apr  3 16:16:18 2013
From: paul at pwsan.com (Paul Walmsley)
Date: Wed, 3 Apr 2013 20:16:18 +0000 (UTC)
Subject: [PATCH] OMAP/serial: Revert bad fix of Rx FIFO threshold
 granularity
In-Reply-To: <20130403183146.GA4072@inertiallabs-linux64>
References: <20130403183146.GA4072@inertiallabs-linux64>
Message-ID: <alpine.DEB.2.00.1304032015050.16711@utopia.booyaka.com>

Hi Greg, Alexey,

On Wed, 3 Apr 2013, Alexey Pelykh wrote:

> From: Alexey Pelykh <alexey.pelykh at gmail.com>
> 
> Partially reverts 1776fd059c40907297d6c26c51876575d63fd9e2
> that introduced regression reported by Paul Walmsley.
> 
> This commit restores setting granularity in SCR register
> and adds note about comments below being inconsistent with
> actual code.
> 
> Signed-off-by: Alexey Pelykh <alexey.pelykh at gmail.com>
> Cc: Paul Walmsley <paul at pwsan.com>
> Cc: Kevin Hilman <khilman at linaro.org>
> Cc: Felipe Balbi <balbi at ti.com>
> Cc: linux-serial at vger.kernel.org 
> Cc: linux-arm-kernel at lists.infradead.org 
> Cc: linux-omap at vger.kernel.org 

Tested-by: Paul Walmsley <paul at pwsan.com>

Thanks for the fast response and fix, Alexey.

Greg, is it possible for you to take this for v3.9-rc fixes?


- Paul


From paul at pwsan.com  Wed Apr  3 16:17:40 2013
From: paul at pwsan.com (Paul Walmsley)
Date: Wed, 3 Apr 2013 20:17:40 +0000 (UTC)
Subject: [PATCH] Revert "OMAP/serial: Fix incorrect Rx FIFO threshold
 setting, LSR validation on Tx, and Tx FIFO IRQ generation"
In-Reply-To: <CAOmKuSoJ38YKyzuyESfx=jgi3y=EunAUt7RPp2=7pRQosytQYg@mail.gmail.com>
References: <alpine.DEB.2.00.1304010519260.28273@utopia.booyaka.com>
 <CAOmKuSpttQJmrL=Htiz-Zc4voAF7CnG_GQYAO2onKpauwYjtvw@mail.gmail.com>
 <alpine.DEB.2.00.1304010844100.28273@utopia.booyaka.com>
 <CAOmKuSrABrPcZ=Yg1+LAHWbh9CdTYR0eUmJ2dd3z91oz0uu21g@mail.gmail.com>
 <alpine.DEB.2.00.1304011008230.28273@utopia.booyaka.com>
 <CAOmKuSrbDc025Tj9xsqDebJ_KZdp_VnWAOs_OO5UAegV43JcDQ@mail.gmail.com>
 <CAOmKuSpbaKutLxbNihBRDz+B0Wt0XiPss-PcEHc-efCTvciNFg@mail.gmail.com>
 <alpine.DEB.2.00.1304011654520.9148@utopia.booyaka.com>
 <CAOmKuSo4onVtk2Ke-i+0_1Ych33KuUYspRy+cySRHf4yWB5XDw@mail.gmail.com>
 <alpine.DEB.2.00.1304021821190.27146@utopia.booyaka.com>
 <CAOmKuSqd=gNYFutpgDref58pbAbDwDin4mvL_OEooD1XuwKtgQ@mail.gmail.com>
 <CAOmKuSp8nPJw7+LKK3ny7ZjEEV-CeDjGg0GD2fDjZiP6HBKGGw@mail.gmail.com>
 <CAOmKuSoJ38YKyzuyESfx=jgi3y=EunAUt7RPp2=7pRQosytQYg@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1304032016370.16711@utopia.booyaka.com>

On Wed, 3 Apr 2013, Alexey Pelykh wrote:

> I've submitted patch that should remove this regression

Thanks, indeed it does.  So the revert patch that I sent at the beginning 
of this thread is now mooted.

- Paul


From khilman at linaro.org  Wed Apr  3 16:20:55 2013
From: khilman at linaro.org (Kevin Hilman)
Date: Wed, 03 Apr 2013 13:20:55 -0700
Subject: [PATCH v2 03/18] ARM: OMAP4+: PM: Consolidate and use OMAP4 PM
 code for OMAP5
In-Reply-To: <1364205910-32392-4-git-send-email-santosh.shilimkar@ti.com>
 (Santosh Shilimkar's message of "Mon, 25 Mar 2013 15:34:55 +0530")
References: <1364205910-32392-1-git-send-email-santosh.shilimkar@ti.com>
 <1364205910-32392-4-git-send-email-santosh.shilimkar@ti.com>
Message-ID: <87li8zwel4.fsf@linaro.org>

Santosh Shilimkar <santosh.shilimkar at ti.com> writes:

> OMAP5 has backward compatible PRCM block and it's programming
> model is mostly similar to OMAP4. Same is going to be maintained
> for future OMAP4 based SOCs. Hence consolidate the OMAP4 power
> management code so that it can be re-used on OMAP5 and later devices.
>
> With consolidated code, let basic power management code build
> for OMAP5 devices. While at it, update the kernel-doc for omap4_pm_init().
>
> Acked-by: Nishanth Menon <nm at ti.com>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
> ---
>  arch/arm/mach-omap2/Makefile                       |    9 ++--
>  arch/arm/mach-omap2/{pm44xx.c => pm_omap4plus.c}   |   54 ++++++++++++++++----
>  .../mach-omap2/{sleep44xx.S => sleep_omap4plus.S}  |    0
>  3 files changed, 49 insertions(+), 14 deletions(-)
>  rename arch/arm/mach-omap2/{pm44xx.c => pm_omap4plus.c} (86%)
>  rename arch/arm/mach-omap2/{sleep44xx.S => sleep_omap4plus.S} (100%)
>
> diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
> index 5d5ff91..d91ae0f 100644
> --- a/arch/arm/mach-omap2/Makefile
> +++ b/arch/arm/mach-omap2/Makefile
> @@ -35,14 +35,14 @@ obj-$(CONFIG_SOC_HAS_OMAP2_SDRC)	+= sdrc.o
>  obj-$(CONFIG_SMP)			+= omap-smp.o omap-headsmp.o
>  obj-$(CONFIG_HOTPLUG_CPU)		+= omap-hotplug.o
>  omap-4-5-common				=  omap4-common.o omap-wakeupgen.o \
> -					   sleep44xx.o
> +					   sleep_omap4plus.o
>  obj-$(CONFIG_ARCH_OMAP4)		+= $(omap-4-5-common)
>  obj-$(CONFIG_SOC_OMAP5)			+= $(omap-4-5-common)
>  
>  plus_sec := $(call as-instr,.arch_extension sec,+sec)
>  AFLAGS_omap-headsmp.o			:=-Wa,-march=armv7-a$(plus_sec)
>  AFLAGS_omap-smc.o			:=-Wa,-march=armv7-a$(plus_sec)
> -AFLAGS_sleep44xx.o			:=-Wa,-march=armv7-a$(plus_sec)
> +AFLAGS_sleep_omap4plus.o		:=-Wa,-march=armv7-a$(plus_sec)
>  
>  # Functions loaded to SRAM
>  obj-$(CONFIG_SOC_OMAP2420)		+= sram242x.o
> @@ -80,11 +80,12 @@ endif
>  obj-$(CONFIG_OMAP_PM_NOOP)		+= omap-pm-noop.o
>  
>  ifeq ($(CONFIG_PM),y)
> +omap4plus-common-pm			=  omap-mpuss-lowpower.o pm_omap4plus.o
>  obj-$(CONFIG_ARCH_OMAP2)		+= pm24xx.o
>  obj-$(CONFIG_ARCH_OMAP2)		+= sleep24xx.o
>  obj-$(CONFIG_ARCH_OMAP3)		+= pm34xx.o sleep34xx.o
> -obj-$(CONFIG_ARCH_OMAP4)		+= pm44xx.o omap-mpuss-lowpower.o
> -obj-$(CONFIG_SOC_OMAP5)			+= omap-mpuss-lowpower.o
> +obj-$(CONFIG_ARCH_OMAP4)		+= $(omap4plus-common-pm)
> +obj-$(CONFIG_SOC_OMAP5)			+= $(omap4plus-common-pm)
>  obj-$(CONFIG_PM_DEBUG)			+= pm-debug.o
>  
>  obj-$(CONFIG_POWER_AVS_OMAP)		+= sr_device.o
> diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm_omap4plus.c
> similarity index 86%
> rename from arch/arm/mach-omap2/pm44xx.c
> rename to arch/arm/mach-omap2/pm_omap4plus.c
> index 5ba6d88..e920c34 100644
> --- a/arch/arm/mach-omap2/pm44xx.c
> +++ b/arch/arm/mach-omap2/pm_omap4plus.c
> @@ -1,7 +1,7 @@
>  /*
> - * OMAP4 Power Management Routines
> + * OMAP4PLUS Power Management Routines

nit: OMAP4+  (you only need to spell out "plus" in the filename.

>   *
> - * Copyright (C) 2010-2011 Texas Instruments, Inc.
> + * Copyright (C) 2010-2013 Texas Instruments, Inc.
>   * Rajendra Nayak <rnayak at ti.com>
>   * Santosh Shilimkar <santosh.shilimkar at ti.com>
>   *
> @@ -135,16 +135,16 @@ static void omap_default_idle(void)
>  }
>  
>  /**
> - * omap4_pm_init - Init routine for OMAP4 PM
> + * omap4_init_static_deps - Add OMAP4 static dependencies
>   *
> - * Initializes all powerdomain and clockdomain target states
> - * and all PRCM settings.
> + * Add needed static clockdomain dependencies on OMAP4 devices.
> + * Return: 0 on success or 'err' on failures
>   */
> -int __init omap4_pm_init(void)
> +static inline int omap4_init_static_deps(void)

You dropped the __init here, but it's still only called from another
__init function, so I suspect it should stay.

>  {
> -	int ret;
>  	struct clockdomain *emif_clkdm, *mpuss_clkdm, *l3_1_clkdm;
>  	struct clockdomain *ducati_clkdm, *l3_2_clkdm;
> +	int ret = 0;
>  
>  	if (omap_rev() == OMAP4430_REV_ES1_0) {
>  		WARN(1, "Power Management not supported on OMAP4430 ES1.0\n");
> @@ -163,7 +163,7 @@ int __init omap4_pm_init(void)
>  	ret = pwrdm_for_each(pwrdms_setup, NULL);
>  	if (ret) {
>  		pr_err("Failed to setup powerdomains\n");
> -		goto err2;
> +		return ret;
>  	}
>  
>  	/*
> @@ -179,7 +179,7 @@ int __init omap4_pm_init(void)
>  	ducati_clkdm = clkdm_lookup("ducati_clkdm");
>  	if ((!mpuss_clkdm) || (!emif_clkdm) || (!l3_1_clkdm) ||
>  		(!l3_2_clkdm) || (!ducati_clkdm))
> -		goto err2;
> +		return -EINVAL;
>  	ret = clkdm_add_wkdep(mpuss_clkdm, emif_clkdm);
>  	ret |= clkdm_add_wkdep(mpuss_clkdm, l3_1_clkdm);
> @@ -188,9 +188,42 @@ int __init omap4_pm_init(void)
>  	ret |= clkdm_add_wkdep(ducati_clkdm, l3_2_clkdm);
>  	if (ret) {
>  		pr_err("Failed to add MPUSS -> L3/EMIF/L4PER, DUCATI -> L3 wakeup dependency\n");
> +		return -EINVAL;
> +	}
> +
> +	return ret;
> +}
> +
> +/**
> + * omap4_pm_init - Init routine for OMAP4+ devices
> + *
> + * Initializes all powerdomain and clockdomain target states
> + * and all PRCM settings.
> + * Return: Returns the error code returned by called functions.
> + */
> +int __init omap4_pm_init(void)
> +{
> +	int ret = 0;
> +
> +	if (omap_rev() == OMAP4430_REV_ES1_0) {
> +		WARN(1, "Power Management not supported on OMAP4430 ES1.0\n");
> +		return -ENODEV;
> +	}
> +
> +	pr_info("Power Management for TI OMAP4PLUS devices.\n");

s/PLUS/+/

Kevin

> +
> +	ret = pwrdm_for_each(pwrdms_setup, NULL);
> +	if (ret) {
> +		pr_err("Failed to setup powerdomains.\n");
>  		goto err2;
>  	}
>  
> +	if (cpu_is_omap44xx()) {
> +		ret = omap4_init_static_deps();
> +		if (ret)
> +			goto err2;
> +	}
> +
>  	ret = omap4_mpuss_init();
>  	if (ret) {
>  		pr_err("Failed to initialise OMAP4 MPUSS\n");
> @@ -206,7 +239,8 @@ int __init omap4_pm_init(void)
>  	/* Overwrite the default cpu_do_idle() */
>  	arm_pm_idle = omap_default_idle;
>  
> -	omap4_idle_init();
> +	if (cpu_is_omap44xx())
> +		omap4_idle_init();
>  
>  err2:
>  	return ret;
> diff --git a/arch/arm/mach-omap2/sleep44xx.S b/arch/arm/mach-omap2/sleep_omap4plus.S
> similarity index 100%
> rename from arch/arm/mach-omap2/sleep44xx.S
> rename to arch/arm/mach-omap2/sleep_omap4plus.S


From paul at pwsan.com  Wed Apr  3 16:21:07 2013
From: paul at pwsan.com (Paul Walmsley)
Date: Wed, 3 Apr 2013 20:21:07 +0000 (UTC)
Subject: [PATCH] Revert "OMAP/serial: Fix incorrect Rx FIFO threshold
 setting, LSR validation on Tx, and Tx FIFO IRQ generation"
In-Reply-To: <CAOmKuSqd=gNYFutpgDref58pbAbDwDin4mvL_OEooD1XuwKtgQ@mail.gmail.com>
References: <alpine.DEB.2.00.1304010519260.28273@utopia.booyaka.com>
 <CAOmKuSpttQJmrL=Htiz-Zc4voAF7CnG_GQYAO2onKpauwYjtvw@mail.gmail.com>
 <alpine.DEB.2.00.1304010844100.28273@utopia.booyaka.com>
 <CAOmKuSrABrPcZ=Yg1+LAHWbh9CdTYR0eUmJ2dd3z91oz0uu21g@mail.gmail.com>
 <alpine.DEB.2.00.1304011008230.28273@utopia.booyaka.com>
 <CAOmKuSrbDc025Tj9xsqDebJ_KZdp_VnWAOs_OO5UAegV43JcDQ@mail.gmail.com>
 <CAOmKuSpbaKutLxbNihBRDz+B0Wt0XiPss-PcEHc-efCTvciNFg@mail.gmail.com>
 <alpine.DEB.2.00.1304011654520.9148@utopia.booyaka.com>
 <CAOmKuSo4onVtk2Ke-i+0_1Ych33KuUYspRy+cySRHf4yWB5XDw@mail.gmail.com>
 <alpine.DEB.2.00.1304021821190.27146@utopia.booyaka.com>
 <CAOmKuSqd=gNYFutpgDref58pbAbDwDin4mvL_OEooD1XuwKtgQ@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1304032018330.16711@utopia.booyaka.com>

Hi,

On Wed, 3 Apr 2013, Alexey Pelykh wrote:

> But, since we've found the issue, I suggest that we should look at it
> closer, especially since at this moment only you can reproduce it. As
> far as I understand, but I may be wrong,
> this comment is wrong, since if to specify
> OMAP_UART_SCR_RX_TRIG_GRANU1_MASK, it effectively sets Rx threshold to
> 1 character, instead of 16.
> /* Set receive FIFO threshold to 16 characters and
>  * transmit FIFO threshold to 16 spaces
>  */

If you want to continue to experiment with it, I'd be willing to do an 
occasional test boot on 37xx EVM.  It's nice to see community patches...


- Paul


From linus.walleij at linaro.org  Wed Apr  3 16:23:46 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Wed, 3 Apr 2013 22:23:46 +0200
Subject: [PATCHv5 0/7] arm: vt8500: Add support for pinctrl/gpio module
In-Reply-To: <515C701E.1000402@prisktech.co.nz>
References: <1364970291-17721-1-git-send-email-linux@prisktech.co.nz>
 <CACRpkdZAtgpfA5rZ_C=eKDDOE9aDm=3k1QDava=EGL2BaoV+0g@mail.gmail.com>
 <515C701E.1000402@prisktech.co.nz>
Message-ID: <CACRpkdapvxK6ad4PGasb0XKjPYJabpvwZhx+o72iwbCZFkkZFg@mail.gmail.com>

On Wed, Apr 3, 2013 at 8:08 PM, Tony Prisk <linux at prisktech.co.nz> wrote:
> On 04/04/13 02:40, Linus Walleij wrote:

>> This v5 series:
>> Acked-by: Linus Walleij <linus.walleij at linaro.org>
>>
>> I guess it will go in through the VT8500 tree eventually?
>>
>> Maybe you could put Stephen's BCMring patch on top when sending
>> it in (also Acked-by) so we can avoid having that dangling.
>>
>> Yours,
>> Linus Walleij
>
> We don't have a VT8500 tree. Originally I planned for it to go through you,
> but it could go through arm-soc if they want to take it.

You should definately be sending VT8500 series like this through
ARM SoC. Prepare a pull request or patch series and
send to arm at kernel.org.

Thanks,
Linus Walleij


From gregkh at linuxfoundation.org  Wed Apr  3 16:24:57 2013
From: gregkh at linuxfoundation.org (Greg KH)
Date: Wed, 3 Apr 2013 13:24:57 -0700
Subject: [PATCH] OMAP/serial: Revert bad fix of Rx FIFO threshold
 granularity
In-Reply-To: <alpine.DEB.2.00.1304032015050.16711@utopia.booyaka.com>
References: <20130403183146.GA4072@inertiallabs-linux64>
 <alpine.DEB.2.00.1304032015050.16711@utopia.booyaka.com>
Message-ID: <20130403202457.GA19668@kroah.com>

On Wed, Apr 03, 2013 at 08:16:18PM +0000, Paul Walmsley wrote:
> Hi Greg, Alexey,
> 
> On Wed, 3 Apr 2013, Alexey Pelykh wrote:
> 
> > From: Alexey Pelykh <alexey.pelykh at gmail.com>
> > 
> > Partially reverts 1776fd059c40907297d6c26c51876575d63fd9e2
> > that introduced regression reported by Paul Walmsley.
> > 
> > This commit restores setting granularity in SCR register
> > and adds note about comments below being inconsistent with
> > actual code.
> > 
> > Signed-off-by: Alexey Pelykh <alexey.pelykh at gmail.com>
> > Cc: Paul Walmsley <paul at pwsan.com>
> > Cc: Kevin Hilman <khilman at linaro.org>
> > Cc: Felipe Balbi <balbi at ti.com>
> > Cc: linux-serial at vger.kernel.org 
> > Cc: linux-arm-kernel at lists.infradead.org 
> > Cc: linux-omap at vger.kernel.org 
> 
> Tested-by: Paul Walmsley <paul at pwsan.com>
> 
> Thanks for the fast response and fix, Alexey.
> 
> Greg, is it possible for you to take this for v3.9-rc fixes?

Will do, thanks.

greg k-h


From khilman at linaro.org  Wed Apr  3 16:25:22 2013
From: khilman at linaro.org (Kevin Hilman)
Date: Wed, 03 Apr 2013 13:25:22 -0700
Subject: [PATCH v2 05/18] ARM: OMAP5: PM: Enables ES2 PM mode by default
In-Reply-To: <1364205910-32392-6-git-send-email-santosh.shilimkar@ti.com>
 (Santosh Shilimkar's message of "Mon, 25 Mar 2013 15:34:57 +0530")
References: <1364205910-32392-1-git-send-email-santosh.shilimkar@ti.com>
 <1364205910-32392-6-git-send-email-santosh.shilimkar@ti.com>
Message-ID: <876203wedp.fsf@linaro.org>

Santosh Shilimkar <santosh.shilimkar at ti.com> writes:

> Enables MPUSS ES2 power management mode using ES2_PM_MODE in
> AMBA_IF_MODE register.
>
> 0x0: ES1 behavior, CPU cores would enter and exit OFF mode together. Broken

What is broken?

> 0x1: ES2 behavior, CPU cores are allowed to enter/exit OFF mode independently.
>
> The AMBA_IF_MODE register value is stored on SAR RAM and restored by
> ROM code.
>
> Acked-by: Nishanth Menon <nm at ti.com>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
> ---
>  arch/arm/mach-omap2/omap-secure.h    |    2 ++
>  arch/arm/mach-omap2/omap-wakeupgen.c |   19 +++++++++++++++++++
>  arch/arm/mach-omap2/omap-wakeupgen.h |    1 +
>  3 files changed, 22 insertions(+)
>
> diff --git a/arch/arm/mach-omap2/omap-secure.h b/arch/arm/mach-omap2/omap-secure.h
> index 0e72917..82b3c4c 100644
> --- a/arch/arm/mach-omap2/omap-secure.h
> +++ b/arch/arm/mach-omap2/omap-secure.h
> @@ -42,6 +42,8 @@
>  #define OMAP4_MON_L2X0_AUXCTRL_INDEX	0x109
>  #define OMAP4_MON_L2X0_PREFETCH_INDEX	0x113
>  
> +#define OMAP5_MON_AMBA_IF_INDEX		0x108
> +
>  /* Secure PPA(Primary Protected Application) APIs */
>  #define OMAP4_PPA_L2_POR_INDEX		0x23
>  #define OMAP4_PPA_CPU_ACTRL_SMP_INDEX	0x25
> diff --git a/arch/arm/mach-omap2/omap-wakeupgen.c b/arch/arm/mach-omap2/omap-wakeupgen.c
> index f8bb3b9..8bcaa8c 100644
> --- a/arch/arm/mach-omap2/omap-wakeupgen.c
> +++ b/arch/arm/mach-omap2/omap-wakeupgen.c
> @@ -42,6 +42,7 @@
>  #define CPU1_ID			0x1
>  #define OMAP4_NR_BANKS		4
>  #define OMAP4_NR_IRQS		128
> +#define OMAP5_AMBA_IF_PM_MODE	(1 << 5)

nit: use BIT()

Kevin


From khilman at linaro.org  Wed Apr  3 16:31:37 2013
From: khilman at linaro.org (Kevin Hilman)
Date: Wed, 03 Apr 2013 13:31:37 -0700
Subject: [PATCH v2 06/18] ARM: OMAP5: PM: Enable Mercury retention mode on
 CPUx powerdomains
In-Reply-To: <1364205910-32392-7-git-send-email-santosh.shilimkar@ti.com>
 (Santosh Shilimkar's message of "Mon, 25 Mar 2013 15:34:58 +0530")
References: <1364205910-32392-1-git-send-email-santosh.shilimkar@ti.com>
 <1364205910-32392-7-git-send-email-santosh.shilimkar@ti.com>
Message-ID: <87k3ojuziu.fsf@linaro.org>

Santosh Shilimkar <santosh.shilimkar at ti.com> writes:

> In addition to the standard power-management technique, the OMAP5
> MPU subsystem also employs an SR3-APG (mercury) power management
> technology to reduce leakage.
>
> It allows for full logic and memories retention on MPU_C0 and MPU_C1 and
> is controlled by the PRCM_MPU.
>
> Acked-by: Nishanth Menon <nm at ti.com>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
> ---
>  arch/arm/mach-omap2/omap-mpuss-lowpower.c |   27 +++++++++++++++++++++++++++
>  1 file changed, 27 insertions(+)
>
> diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
> index b1441b1..d390d18 100644
> --- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
> +++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
> @@ -62,6 +62,10 @@
>  #include "prm44xx.h"
>  #include "prm-regbits-44xx.h"
>  
> +/* Add defines needed for mercury mode. Refer MPU's PRM_PSCON_COUNT */
> +#define PRM_PSCON_HG_EN		(1 << 24)
> +#define PRM_PSCON_HG_RAMPUP	(1 << 25)

nit: use BIT()

>  #ifdef CONFIG_SMP
>  
>  struct omap4_cpu_pm_info {
> @@ -337,6 +341,28 @@ int __cpuinit omap4_hotplug_cpu(unsigned int cpu, unsigned int power_state)
>  	return 0;
>  }
>  
> +/**
> + * enable_mercury_retention_mode: Enable OMAP5 mercury retention feature
> + *
> + * OMAP5 devices supports  SR3-APG (mercury) power management technology to
> + * reduce leakage. It allows for full logic and memories retention on
> + * MPU_C0 and MPU_C1 and is controlled by the PRCM_MPU. The function enable
> + * the mercury retention feature.
> + */
> +static void enable_mercury_retention_mode(void)

__init ?

This is very OMAP5 specific (unless you generalize the offsets used) so
should this have omap5_ prefix?

Kevin

> +{
> +	u32 reg;
> +
> +	/*
> +	 * To enable mercury mode, both HG_EN and HG_RAMPUP needs to be
> +	 * enabled from PRM_PSCON_COUNT register.
> +	 */
> +	reg = omap4_prcm_mpu_read_inst_reg(OMAP54XX_PRCM_MPU_DEVICE_INST,
> +			OMAP54XX_PRCM_MPU_PRM_PSCON_COUNT_OFFSET);
> +	reg |= PRM_PSCON_HG_EN | PRM_PSCON_HG_RAMPUP;
> +	omap4_prcm_mpu_write_inst_reg(reg, OMAP54XX_PRCM_MPU_DEVICE_INST,
> +			OMAP54XX_PRCM_MPU_PRM_PSCON_COUNT_OFFSET);

nit: when I see 'reg', I expect it to be a register/offset.  But this is
a register value.  Maybe use 'val' instead as you've done elsewhere in
this series.

Kevin

> +}
>  
>  /*
>   * Initialise OMAP4 MPUSS
> @@ -415,6 +441,7 @@ int __init omap4_mpuss_init(void)
>  		cpu_context_offset = OMAP4_RM_CPU0_CPU0_CONTEXT_OFFSET;
>  	} else if (soc_is_omap54xx()) {
>  		cpu_context_offset = OMAP54XX_RM_CPU0_CPU0_CONTEXT_OFFSET;
> +		enable_mercury_retention_mode();
>  	}
>  
>  	return 0;


From linus.walleij at linaro.org  Wed Apr  3 16:32:27 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Wed, 3 Apr 2013 22:32:27 +0200
Subject: [PATCH 1/9] ARM: ux500: Increase the size of the PRCMU's TCPM size
In-Reply-To: <1364908916-29803-1-git-send-email-lee.jones@linaro.org>
References: <1364908916-29803-1-git-send-email-lee.jones@linaro.org>
Message-ID: <CACRpkdbgFjvZkOAJd5g335DnHWdAQJgOg3EVUL88+bkS41eq9g@mail.gmail.com>

On Tue, Apr 2, 2013 at 3:21 PM, Lee Jones <lee.jones at linaro.org> wrote:

> The Tightly Coupled Program Memory location is actually 32kB in
> size, rather than the originally depicted 4kB.
>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>

Patch applied.

Yours,
Linus Walleij


From pavel at denx.de  Wed Apr  3 16:32:35 2013
From: pavel at denx.de (Pavel Machek)
Date: Wed, 3 Apr 2013 22:32:35 +0200
Subject: [PATCHv2 1/2] ARM: socfpga: Enable soft reset
In-Reply-To: <20130403185232.GA11360@quad.lixom.net>
References: <1363707936-17769-1-git-send-email-dinguyen@altera.com>
 <20130320152915.GA32083@amd.pavel.ucw.cz>
 <20130403185232.GA11360@quad.lixom.net>
Message-ID: <20130403203234.GA7643@amd.pavel.ucw.cz>

Hi!

> > +struct socfpga_rstmgr_hw {
> > +	u32 unk;
> > +	u32 ctrl;		/* 0x04 */
> > +	u32 unk2, unk3;
> > +/* MPU Module Reset Register */
> > +#define RSTMGR_MPUMODRST_CPU0	0x1	/* CPU0 Reset */
> > +#define RSTMGR_MPUMODRST_CPU1	0x2	/* CPU1 Reset */
> > +#define RSTMGR_MPUMODRST_WDS	0x4	/* Watchdog Reset */
> > +#define RSTMGR_MPUMODRST_SCUPER	0x8	/* SCU and periphs reset */
> > +#define RSTMGR_MPUMODRST_L2	0x10	/* L2 Cache reset */
> > +	u32 mpumodrst; 		/* 0x10 */
> > +	u32 modperrst;		/* 0x14 */
> > +	u32 unk5;
> > +	u32 bgrmodrst;		/* 0x1c */
> > +};
> 
> As Russell already replied, struct used to represent register layout is
> normally frowned upon in drivers.

Well... as Russell also said, this is arch-specific code, so it is
actually ok.

> If you want to tighten up the code in this case, make a local helper
> function that just takes the register offset instead, i.e.:
> 
> > -	temp = __raw_readl(rst_manager_base_addr + SOCFPGA_RSTMGR_CTRL);
> > +	temp = readl(&rst_manager_base_addr->ctrl);
> 
> 	temp = rst_readl(SOCFPGA_RSTMGR_CTRL);
> 
> (and then have rst_readl/rst_writel do the math based on base
> address).

That does not prevent mistake such as
rst_readl(SOCFPGA_SYSMGR_CTRL)... and with number of different
subsystems on socfpga (each with separate base address), I fear that
might be an issue.

Unfortunately, C does not check type of enums, so they can't be used
to solve that.

Any other ideas?
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


From khilman at linaro.org  Wed Apr  3 16:33:22 2013
From: khilman at linaro.org (Kevin Hilman)
Date: Wed, 03 Apr 2013 13:33:22 -0700
Subject: [PATCH v2 07/18] ARM: OMAP5: Add init_late() hook to enable pm
 initialization
In-Reply-To: <1364205910-32392-8-git-send-email-santosh.shilimkar@ti.com>
 (Santosh Shilimkar's message of "Mon, 25 Mar 2013 15:34:59 +0530")
References: <1364205910-32392-1-git-send-email-santosh.shilimkar@ti.com>
 <1364205910-32392-8-git-send-email-santosh.shilimkar@ti.com>
Message-ID: <87eheruzfx.fsf@linaro.org>

Santosh Shilimkar <santosh.shilimkar at ti.com> writes:

> With consolidated code, now we can add the .init_late hook for
> OMAP5 to enable power management and mux initialization.
>
> Acked-by: Nishanth Menon <nm at ti.com>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
> ---
>  arch/arm/mach-omap2/board-generic.c |    1 +
>  arch/arm/mach-omap2/common.h        |    3 ++-
>  arch/arm/mach-omap2/io.c            |    8 ++++++++
>  3 files changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.c
> index e54a480..8e261a6 100644
> --- a/arch/arm/mach-omap2/board-generic.c
> +++ b/arch/arm/mach-omap2/board-generic.c
> @@ -180,6 +180,7 @@ DT_MACHINE_START(OMAP5_DT, "Generic OMAP5 (Flattened Device Tree)")
>  	.init_irq	= omap_gic_of_init,
>  	.init_machine	= omap_generic_init,
>  	.init_time	= omap5_realtime_timer_init,
> +	.init_late	= omap5_init_late,
>  	.dt_compat	= omap5_boards_compat,
>  	.restart	= omap44xx_restart,
>  MACHINE_END
> diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
> index 40f4a03..f75d972 100644
> --- a/arch/arm/mach-omap2/common.h
> +++ b/arch/arm/mach-omap2/common.h
> @@ -59,7 +59,7 @@ static inline int omap3_pm_init(void)
>  }
>  #endif
>  
> -#if defined(CONFIG_PM) && defined(CONFIG_ARCH_OMAP4)
> +#if defined(CONFIG_PM) && (defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5))
>  int omap4_pm_init(void);
>  #else
>  static inline int omap4_pm_init(void)
> @@ -108,6 +108,7 @@ void omap35xx_init_late(void);
>  void omap3630_init_late(void);
>  void am35xx_init_late(void);
>  void ti81xx_init_late(void);
> +void omap5_init_late(void);
>  int omap2_common_pm_late_init(void);
>  
>  #if defined(CONFIG_SOC_OMAP2420) || defined(CONFIG_SOC_OMAP2430)
> diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
> index e948a39..cdd1264 100644
> --- a/arch/arm/mach-omap2/io.c
> +++ b/arch/arm/mach-omap2/io.c
> @@ -636,6 +636,14 @@ void __init omap5_init_early(void)
>  	omap_hwmod_init_postsetup();
>  
>  }
> +
> +void __init omap5_init_late(void)
> +{
> +	omap_mux_late_init();
> +	omap2_common_pm_late_init();
> +	omap4_pm_init();
> +	omap2_clk_enable_autoidle_all();
> +}

Since you're consolidating, why not rename omap4430_init_late to
omap4plus_init_late and use it for both OMAP4 and OMAP5?

Kevin

>  #endif
>  
>  void __init omap_sdrc_init(struct omap_sdrc_params *sdrc_cs0,


From linus.walleij at linaro.org  Wed Apr  3 16:33:36 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Wed, 3 Apr 2013 22:33:36 +0200
Subject: [PATCH 2/9] ARM: ux500: Remove incorrect DB9540 PRCMU TCDM base
 location
In-Reply-To: <1364908916-29803-2-git-send-email-lee.jones@linaro.org>
References: <1364908916-29803-1-git-send-email-lee.jones@linaro.org>
 <1364908916-29803-2-git-send-email-lee.jones@linaro.org>
Message-ID: <CACRpkdapOBRLAtYOh=CvfqDbxxovn+qO0QiOhGCrYtv2qSt-Ng@mail.gmail.com>

On Tue, Apr 2, 2013 at 3:21 PM, Lee Jones <lee.jones at linaro.org> wrote:

> The Tightly Coupled Data Memory for the DB9540 is actually in the
> same place as the DB8500's. This definition is just plain wrong.
>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>

Patch applied.

Yours,
Linus Walleij


From linus.walleij at linaro.org  Wed Apr  3 16:34:24 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Wed, 3 Apr 2013 22:34:24 +0200
Subject: [PATCH 3/9] ARM: ux500: Supply a DTS file for the u8540 platform
In-Reply-To: <1364908916-29803-3-git-send-email-lee.jones@linaro.org>
References: <1364908916-29803-1-git-send-email-lee.jones@linaro.org>
 <1364908916-29803-3-git-send-email-lee.jones@linaro.org>
Message-ID: <CACRpkdafSvT5Xb=7sqnkRHcc4UKkVzr8jzThMgWn6459RDmKGw@mail.gmail.com>

On Tue, Apr 2, 2013 at 3:21 PM, Lee Jones <lee.jones at linaro.org> wrote:

> This is a skeleton DTS file which only enables serial. Just using
> this simple file yields a terminal when booting u8540.
>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>
> ---
>  arch/arm/boot/dts/u8540.dts |   36 ++++++++++++++++++++++++++++++++++++

Please rename this DTS file ccu8540.dts.

Yours,
Linus Walleij


From linus.walleij at linaro.org  Wed Apr  3 16:38:41 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Wed, 3 Apr 2013 22:38:41 +0200
Subject: [PATCH 4/9] ARM: ux500: Move Snowball's thermal DT node into
 existing PRCMU one
In-Reply-To: <1364908916-29803-4-git-send-email-lee.jones@linaro.org>
References: <1364908916-29803-1-git-send-email-lee.jones@linaro.org>
 <1364908916-29803-4-git-send-email-lee.jones@linaro.org>
Message-ID: <CACRpkdar=xD34yaMP2gOfUPkpxOhDymS6zTedKOEW7j2DNHusA@mail.gmail.com>

On Tue, Apr 2, 2013 at 3:21 PM, Lee Jones <lee.jones at linaro.org> wrote:

> When the thermal DT node was inserted a new PRCMU node was created;
> however, one already exists in the Snowball DTS file. Here we
> amalgamate the two into a single consolidated node.
>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>

Patch applied.

Thanks,
Linus Walleij


From linus.walleij at linaro.org  Wed Apr  3 16:39:50 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Wed, 3 Apr 2013 22:39:50 +0200
Subject: [PATCH 5/9] ARM: ux500: Over-ride TCDM size when booting the
 DB8540 platform
In-Reply-To: <1364908916-29803-5-git-send-email-lee.jones@linaro.org>
References: <1364908916-29803-1-git-send-email-lee.jones@linaro.org>
 <1364908916-29803-5-git-send-email-lee.jones@linaro.org>
Message-ID: <CACRpkdbh-DJti2ny=uBe-b_vGkQBNL=emMuZ6+_cE5jvRsA4sA@mail.gmail.com>

On Tue, Apr 2, 2013 at 3:21 PM, Lee Jones <lee.jones at linaro.org> wrote:

> The PRCMU's Tightly Coupled Data Memory on the DB8540 platform is
> 8kB larger than it's predecessor's. We need to reflect that in its
> Device Tree. By re-specifying the address and size of the device
> we effectively over-ride the previous values with more accurate
> ones.
>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>

Need to change the name of the file it hits to ccu8540 before
it applies...

Yours,
Linus Walleij


From linus.walleij at linaro.org  Wed Apr  3 16:42:41 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Wed, 3 Apr 2013 22:42:41 +0200
Subject: [PATCH 6/9] ARM: ux500: Create a new of_dev_auxdata structure for
 u8540 enablement
In-Reply-To: <1364908916-29803-6-git-send-email-lee.jones@linaro.org>
References: <1364908916-29803-1-git-send-email-lee.jones@linaro.org>
 <1364908916-29803-6-git-send-email-lee.jones@linaro.org>
Message-ID: <CACRpkda8Zfc_AvHkqACA7UjdSSAphbu5rUBBktN_awwiSTQAaw@mail.gmail.com>

On Tue, Apr 2, 2013 at 3:21 PM, Lee Jones <lee.jones at linaro.org> wrote:

> If we attempt to use the existing u8500 of_dev_auxdata struct to boot
> the u8540, we fail to obtain a console, due to a lack of DMA support
> on the platform.
>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>

Patch applied.

Thanks,
Linus Walleij


From linus.walleij at linaro.org  Wed Apr  3 16:44:14 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Wed, 3 Apr 2013 22:44:14 +0200
Subject: [PATCH 7/9] ARM: ux500: Add a VQMMC (level-shifting) regulator DT
 node for Snowball
In-Reply-To: <1364908916-29803-7-git-send-email-lee.jones@linaro.org>
References: <1364908916-29803-1-git-send-email-lee.jones@linaro.org>
 <1364908916-29803-7-git-send-email-lee.jones@linaro.org>
Message-ID: <CACRpkdaVWUq5dQ7ktGAhSmKkWs7DvKrHtQng106ccD27hp_HuQ@mail.gmail.com>

On Tue, Apr 2, 2013 at 3:21 PM, Lee Jones <lee.jones at linaro.org> wrote:

> Until recently platform code took care of all MMCI level-shifting by
> way of an ios_handler() call-back. Now it is the driver's responsibility
> to handle. In order to so that we need to provide the VQMMC regulator
> reference in Device Tree. This patch takes care of that.
>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>

Patch applied, thanks!

Yours,
Linus Walleij


From tony at atomide.com  Wed Apr  3 14:03:58 2013
From: tony at atomide.com (Tony Lindgren)
Date: Wed, 3 Apr 2013 11:03:58 -0700
Subject: OK to use commit 71856843 as base for further omap clean up?
In-Reply-To: <20130403165353.GW30923@n2100.arm.linux.org.uk>
References: <20130319175921.GA22104@atomide.com> <5150A60E.2090108@ti.com>
 <20130326232200.GQ30923@n2100.arm.linux.org.uk>
 <20130403165353.GW30923@n2100.arm.linux.org.uk>
Message-ID: <20130403180358.GW10155@atomide.com>

* Russell King - ARM Linux <linux at arm.linux.org.uk> [130403 09:58]:
> On Tue, Mar 26, 2013 at 11:22:00PM +0000, Russell King - ARM Linux wrote:
> > On Mon, Mar 25, 2013 at 02:31:26PM -0500, Jon Hunter wrote:
> > > Hi Russell,
> > > 
> > > On 03/19/2013 12:59 PM, Tony Lindgren wrote:
> > > > Hi Russell,
> > > > 
> > > > Can we use your commit 71856843 (ARM: OMAP: use consistent error checking)
> > > > as an immutable base for further omap dmtimer and gpmc work?
> > > 
> > > I saw that you updated your clean-up branch. Ok to use the below commit
> > > [1] as a base for some v3.10 updates?
> > 
> > It's still the same commit.  I'm not intending to remove this commit
> > from it, so yes, fine, go ahead.
> 
> *sigh*.  Actually, 4d485661d799e81f98097057d445f4803cef2af0 is buggered
> which is the commit below it.  I said yes too quickly.  Oh well, it'll
> just have to be broken for when it hits mainline now.

Yes we have few branches based on that. Note that the issue reported by
Lothar I just resolved in the omap-for-v3.10/timer branch along with
other conflicts when pulling in Jon's patches, so that might do the trick
assuming there are no other issues.

Regards,

Tony


From linus.walleij at linaro.org  Wed Apr  3 16:46:17 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Wed, 3 Apr 2013 22:46:17 +0200
Subject: [PATCH 8/9] mfd: db8500-prcmu: Return early if the TCPM cannot be
 located
In-Reply-To: <1364908916-29803-8-git-send-email-lee.jones@linaro.org>
References: <1364908916-29803-1-git-send-email-lee.jones@linaro.org>
 <1364908916-29803-8-git-send-email-lee.jones@linaro.org>
Message-ID: <CACRpkdbQ0Zfd6vWisH-q1XcmPFqzQGtL8GzZpFyxbtGAoYT88A@mail.gmail.com>

On Tue, Apr 2, 2013 at 3:21 PM, Lee Jones <lee.jones at linaro.org> wrote:

> Currently we check to see if we obtained the Tightly Coupled Program
> Memory (TCPM) base and only execute the code within the check if we
> have it. It's more traditional to return early if we don't have it.
> This way we can flatten most of the function's code down to a single
> tab spacing.
>
> Cc: Samuel Ortiz <sameo at linux.intel.com>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>

Acked-by: Linus Walleij <linus.walleij at linaro.org>

This should go in through the MFD tree.

Yours,
Linus Walleij


From alexey.pelykh at gmail.com  Wed Apr  3 16:46:49 2013
From: alexey.pelykh at gmail.com (Alexey Pelykh)
Date: Wed, 3 Apr 2013 23:46:49 +0300
Subject: [PATCH] Revert "OMAP/serial: Fix incorrect Rx FIFO threshold
 setting, LSR validation on Tx, and Tx FIFO IRQ generation"
In-Reply-To: <alpine.DEB.2.00.1304032018330.16711@utopia.booyaka.com>
References: <alpine.DEB.2.00.1304010519260.28273@utopia.booyaka.com>
 <CAOmKuSpttQJmrL=Htiz-Zc4voAF7CnG_GQYAO2onKpauwYjtvw@mail.gmail.com>
 <alpine.DEB.2.00.1304010844100.28273@utopia.booyaka.com>
 <CAOmKuSrABrPcZ=Yg1+LAHWbh9CdTYR0eUmJ2dd3z91oz0uu21g@mail.gmail.com>
 <alpine.DEB.2.00.1304011008230.28273@utopia.booyaka.com>
 <CAOmKuSrbDc025Tj9xsqDebJ_KZdp_VnWAOs_OO5UAegV43JcDQ@mail.gmail.com>
 <CAOmKuSpbaKutLxbNihBRDz+B0Wt0XiPss-PcEHc-efCTvciNFg@mail.gmail.com>
 <alpine.DEB.2.00.1304011654520.9148@utopia.booyaka.com>
 <CAOmKuSo4onVtk2Ke-i+0_1Ych33KuUYspRy+cySRHf4yWB5XDw@mail.gmail.com>
 <alpine.DEB.2.00.1304021821190.27146@utopia.booyaka.com>
 <CAOmKuSqd=gNYFutpgDref58pbAbDwDin4mvL_OEooD1XuwKtgQ@mail.gmail.com>
 <alpine.DEB.2.00.1304032018330.16711@utopia.booyaka.com>
Message-ID: <CAOmKuSqVs4i_CMC4Pf=rLrkzh93YietU5p7XwgSC9DvvEyVL1g@mail.gmail.com>

Hi

On Wed, Apr 3, 2013 at 11:21 PM, Paul Walmsley <paul at pwsan.com> wrote:
> Hi,
>
> On Wed, 3 Apr 2013, Alexey Pelykh wrote:
>
>> But, since we've found the issue, I suggest that we should look at it
>> closer, especially since at this moment only you can reproduce it. As
>> far as I understand, but I may be wrong,
>> this comment is wrong, since if to specify
>> OMAP_UART_SCR_RX_TRIG_GRANU1_MASK, it effectively sets Rx threshold to
>> 1 character, instead of 16.
>> /* Set receive FIFO threshold to 16 characters and
>>  * transmit FIFO threshold to 16 spaces
>>  */
>
> If you want to continue to experiment with it, I'd be willing to do an
> occasional test boot on 37xx EVM.  It's nice to see community patches...
>

I'm pretty sure that current configuration of UART indeed sets Rx FIFO
threshold to
1 character, as opposite to 16 characters mentioned in comments. Kernel 3.3
is the origin of Rx 1-char-granularity bit setting, but states clearly
that Rx FIFO
is being set to 1 character in non-DMA mode. The comment appears between
3.6 and 3.7 in commit 6721ab7f77f2614ab43e3de2f908b1d7436331df by Felipe Balbi.
3.0-3.2 kernels don't have 1-char-granularity enabled, and Rx FIFO
threshold level
was effectively set to 16 characters, what should be the same as my
patch that turned off
1-char-granularity

Paul, can you confirm (if possible, surely) if 3.0-3.2 kernels had same issue?

Felipe, it would be great to get your comments on this?

>
> - Paul


From linus.walleij at linaro.org  Wed Apr  3 16:47:36 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Wed, 3 Apr 2013 22:47:36 +0200
Subject: [PATCH 9/9] mfd: db8500-prcmu: Support platform dependant device
 selection
In-Reply-To: <1364908916-29803-9-git-send-email-lee.jones@linaro.org>
References: <1364908916-29803-1-git-send-email-lee.jones@linaro.org>
 <1364908916-29803-9-git-send-email-lee.jones@linaro.org>
Message-ID: <CACRpkdaRfBFMO+XnJVq9ccxsqw3+RS+OCPuF8ivrrRu=OxuJEQ@mail.gmail.com>

On Tue, Apr 2, 2013 at 3:21 PM, Lee Jones <lee.jones at linaro.org> wrote:

> The main aim for this cycle is to have the u8540 booting to a
> console. However, the u8540 doesn't support all of the u8500
> platform devices yet. After this stage is complete we can then
> fill in the inadequacies, such as specific clock support at a
> later date. To achieve this we're placing devices supported by
> all platforms into a common device structure and the remaining
> ones into a platform specific one.
>
> Cc: Samuel Ortiz <sameo at linux.intel.com>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>

Acked-by: Linus Walleij <linus.walleij at linaro.org>

This should also go through the MFD tree.

Yours,
Linus Walleij


From notasas at gmail.com  Wed Apr  3 16:48:10 2013
From: notasas at gmail.com (Grazvydas Ignotas)
Date: Wed, 3 Apr 2013 23:48:10 +0300
Subject: [PATCH] Revert "OMAP/serial: Fix incorrect Rx FIFO threshold
 setting, LSR validation on Tx, and Tx FIFO IRQ generation"
In-Reply-To: <CAOmKuSqd=gNYFutpgDref58pbAbDwDin4mvL_OEooD1XuwKtgQ@mail.gmail.com>
References: <alpine.DEB.2.00.1304010519260.28273@utopia.booyaka.com>
 <CAOmKuSpttQJmrL=Htiz-Zc4voAF7CnG_GQYAO2onKpauwYjtvw@mail.gmail.com>
 <alpine.DEB.2.00.1304010844100.28273@utopia.booyaka.com>
 <CAOmKuSrABrPcZ=Yg1+LAHWbh9CdTYR0eUmJ2dd3z91oz0uu21g@mail.gmail.com>
 <alpine.DEB.2.00.1304011008230.28273@utopia.booyaka.com>
 <CAOmKuSrbDc025Tj9xsqDebJ_KZdp_VnWAOs_OO5UAegV43JcDQ@mail.gmail.com>
 <CAOmKuSpbaKutLxbNihBRDz+B0Wt0XiPss-PcEHc-efCTvciNFg@mail.gmail.com>
 <alpine.DEB.2.00.1304011654520.9148@utopia.booyaka.com>
 <CAOmKuSo4onVtk2Ke-i+0_1Ych33KuUYspRy+cySRHf4yWB5XDw@mail.gmail.com>
 <alpine.DEB.2.00.1304021821190.27146@utopia.booyaka.com>
 <CAOmKuSqd=gNYFutpgDref58pbAbDwDin4mvL_OEooD1XuwKtgQ@mail.gmail.com>
Message-ID: <CANOLnOPc-=RP8K8A8sda6riBNTHG0vBAeGtryXALgewm53_B3A@mail.gmail.com>

Hi,

On Wed, Apr 3, 2013 at 12:19 AM, Alexey Pelykh <alexey.pelykh at gmail.com> wrote:
>
> But, since we've found the issue, I suggest that we should look at it
> closer, especially since at this moment only you can reproduce it. As

FWIW I was also affected by it, maybe because my console is on UART3
and that is on different power (or was is clock?) domain than UART1.


--
Gra?vydas


From daniel.lezcano at linaro.org  Wed Apr  3 16:49:03 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Wed, 03 Apr 2013 22:49:03 +0200
Subject: [PATCH 8/9] ARM: omap3: cpuidle: enable time keeping
In-Reply-To: <87zjxfzetw.fsf@linaro.org>
References: <1364991322-20585-1-git-send-email-daniel.lezcano@linaro.org>
 <1364991322-20585-8-git-send-email-daniel.lezcano@linaro.org>
 <87zjxfzetw.fsf@linaro.org>
Message-ID: <515C95BF.6030103@linaro.org>

On 04/03/2013 07:47 PM, Kevin Hilman wrote:
> Daniel Lezcano <daniel.lezcano at linaro.org> writes:
> 
>> The TIME_VALID flag is specified for the different states but
>> the time residency computation is not done, no tk flag, no time
>> computation in the idle function.
>>
>> Set the en_core_tk_irqen flag to activate it.
>>
>> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
>> Acked-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
> 
> Acked-by: Kevin Hilman <khilman at linaro.org>
> 
> Also, is this a regression fix that also needs to hit v3.9?

Yes, I think so.


>> ---
>>  arch/arm/mach-omap2/cpuidle34xx.c |    5 +++--
>>  1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/cpuidle34xx.c b/arch/arm/mach-omap2/cpuidle34xx.c
>> index 80392fc..4f67a5b 100644
>> --- a/arch/arm/mach-omap2/cpuidle34xx.c
>> +++ b/arch/arm/mach-omap2/cpuidle34xx.c
>> @@ -274,8 +274,9 @@ static int omap3_enter_idle_bm(struct cpuidle_device *dev,
>>  static DEFINE_PER_CPU(struct cpuidle_device, omap3_idle_dev);
>>  
>>  static struct cpuidle_driver omap3_idle_driver = {
>> -	.name =		"omap3_idle",
>> -	.owner =	THIS_MODULE,
>> +	.name             = "omap3_idle",
>> +	.owner            = THIS_MODULE,
>> +	.en_core_tk_irqen = 1,
>>  	.states = {
>>  		{
>>  			.enter		  = omap3_enter_idle_bm,


-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From khilman at linaro.org  Wed Apr  3 16:49:18 2013
From: khilman at linaro.org (Kevin Hilman)
Date: Wed, 03 Apr 2013 13:49:18 -0700
Subject: [PATCH v2 08/18] ARM: OMAP5: PM: Add CPU power off in hotplug path
In-Reply-To: <1364205910-32392-9-git-send-email-santosh.shilimkar@ti.com>
 (Santosh Shilimkar's message of "Mon, 25 Mar 2013 15:35:00 +0530")
References: <1364205910-32392-1-git-send-email-santosh.shilimkar@ti.com>
 <1364205910-32392-9-git-send-email-santosh.shilimkar@ti.com>
Message-ID: <876203uypd.fsf@linaro.org>

Santosh Shilimkar <santosh.shilimkar at ti.com> writes:

> Add power management code to handle the CPU off mode to enable CPUP hotplug
> mode for OMAP5 devices. Separate suspend finisher is used for OMAP5(Cortex-A15)
> because it doesn't use SCU power status register and external PL310 L2 cache
> which makes code flow bit different.
>
> Acked-by: Nishanth Menon <nm at ti.com>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>

[...]

> @@ -436,14 +445,21 @@ int __init omap4_mpuss_init(void)
>  
>  	if (cpu_is_omap44xx()) {
>  		omap_pm_ops.finish_suspend = omap4_finish_suspend;
> +		omap_pm_ops.hotplug_restart = omap_secondary_startup;
>  		omap_pm_ops.resume = omap4_cpu_resume;
>  		omap_pm_ops.scu_prepare = scu_pwrst_prepare;
>  		cpu_context_offset = OMAP4_RM_CPU0_CPU0_CONTEXT_OFFSET;
>  	} else if (soc_is_omap54xx()) {
> +		omap_pm_ops.finish_suspend = omap5_finish_suspend;
> +		omap_pm_ops.hotplug_restart = omap5_secondary_startup;
>  		cpu_context_offset = OMAP54XX_RM_CPU0_CPU0_CONTEXT_OFFSET;
>  		enable_mercury_retention_mode();
>  	}
>  
> +	/* Over-write the OMAP4 hook to take care of ROM BUG */
> +	if (cpu_is_omap446x())
> +		omap_pm_ops.hotplug_restart = omap_secondary_startup_4460;

A couple nits...

I think this would go better at the end of the 'if omap44xx' block
above.

Also, while you're hear, maybe it's time to rename the current secondary 
startup functions to match the new one.  IOW omap4_..., omap4460_... and omap5_...

Kevin


From linus.walleij at linaro.org  Wed Apr  3 16:49:48 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Wed, 3 Apr 2013 22:49:48 +0200
Subject: [PATCH 1/2] ARM: ux500: remove redundant DB8500_PIN_SLEEP
 definition
In-Reply-To: <1364487669-24368-2-git-send-email-fabio.baltieri@linaro.org>
References: <1364487669-24368-1-git-send-email-fabio.baltieri@linaro.org>
 <1364487669-24368-2-git-send-email-fabio.baltieri@linaro.org>
Message-ID: <CACRpkdbWho1x7DUmQuWXbiz1Gcx6gmR2U8Sh62hBQKF=8RpHVA@mail.gmail.com>

On Thu, Mar 28, 2013 at 5:21 PM, Fabio Baltieri
<fabio.baltieri at linaro.org> wrote:

> DB8500_PIN_SLEEP was defined twice, drop one of the two.
>
> Signed-off-by: Fabio Baltieri <fabio.baltieri at linaro.org>

Patch applied.

Yours,
Linus Walleij


From linus.walleij at linaro.org  Wed Apr  3 16:52:30 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Wed, 3 Apr 2013 22:52:30 +0200
Subject: [PATCH v2 2/2] ARM: ux500: 8500: add ab8500-musb pinctrl support
In-Reply-To: <1364560187-20495-1-git-send-email-fabio.baltieri@linaro.org>
References: <1364487669-24368-3-git-send-email-fabio.baltieri@linaro.org>
 <1364560187-20495-1-git-send-email-fabio.baltieri@linaro.org>
Message-ID: <CACRpkdZY211JisP=GNp9CLY11X9UxZcTBNu7PZNZxZyM0sn5Vg@mail.gmail.com>

On Fri, Mar 29, 2013 at 1:29 PM, Fabio Baltieri
<fabio.baltieri at linaro.org> wrote:

> From: Patrice Chotard <patrice.chotard at stericsson.com>
>
> Add necessary definitions to support ab8500-musb pinctrl default and
> sleep states.
>
> Signed-off-by: Patrice Chotard <patrice.chotard at stericsson.com>
> Signed-off-by: Fabio Baltieri <fabio.baltieri at linaro.org>
> ---
>
> Hi Linus,
>
> I'm sending a v2 on this one as I mis-replaced a device id (manually
> applied patch, sorry about that).
>
> Changes from v1:
> - fix typo in GPIO257_AE29 device name

Thanks, patch applied!

Yours,
Linus Walleij


From khilman at linaro.org  Wed Apr  3 16:54:41 2013
From: khilman at linaro.org (Kevin Hilman)
Date: Wed, 03 Apr 2013 13:54:41 -0700
Subject: [PATCH v2 09/18] ARM: OMAP4+: PM: Restore CPU power state to ON
 with clockdomain force wakeup method
In-Reply-To: <1364205910-32392-10-git-send-email-santosh.shilimkar@ti.com>
 (Santosh Shilimkar's message of "Mon, 25 Mar 2013 15:35:01 +0530")
References: <1364205910-32392-1-git-send-email-santosh.shilimkar@ti.com>
 <1364205910-32392-10-git-send-email-santosh.shilimkar@ti.com>
Message-ID: <87mwtftjvy.fsf@linaro.org>

Santosh Shilimkar <santosh.shilimkar at ti.com> writes:

> While waking up CPU from off state using clock domain force wakeup, restore
> the CPU power state to ON state before putting CPU clock domain under
> hardware control. Otherwise CPU wakeup might fail. The change is recommended
> for all OMAP4+ devices though the PRCM weakness was observed on OMAP5
> devices first.

Sounds reasonable, but can you describe the "weakness" a little more?

IOW, what exactly happens if this is not done?  It sounds like the CPU
might immediately go back to retention, but how does that happen unless
it does a WFI?

Also, this sounds like a fix to me, and should probably be broken out
accordingly.

Kevin



From paul at pwsan.com  Wed Apr  3 16:57:28 2013
From: paul at pwsan.com (Paul Walmsley)
Date: Wed, 3 Apr 2013 20:57:28 +0000 (UTC)
Subject: [PATCH] Revert "OMAP/serial: Fix incorrect Rx FIFO threshold
 setting, LSR validation on Tx, and Tx FIFO IRQ generation"
In-Reply-To: <CAOmKuSqd=gNYFutpgDref58pbAbDwDin4mvL_OEooD1XuwKtgQ@mail.gmail.com>
References: <alpine.DEB.2.00.1304010519260.28273@utopia.booyaka.com>
 <CAOmKuSpttQJmrL=Htiz-Zc4voAF7CnG_GQYAO2onKpauwYjtvw@mail.gmail.com>
 <alpine.DEB.2.00.1304010844100.28273@utopia.booyaka.com>
 <CAOmKuSrABrPcZ=Yg1+LAHWbh9CdTYR0eUmJ2dd3z91oz0uu21g@mail.gmail.com>
 <alpine.DEB.2.00.1304011008230.28273@utopia.booyaka.com>
 <CAOmKuSrbDc025Tj9xsqDebJ_KZdp_VnWAOs_OO5UAegV43JcDQ@mail.gmail.com>
 <CAOmKuSpbaKutLxbNihBRDz+B0Wt0XiPss-PcEHc-efCTvciNFg@mail.gmail.com>
 <alpine.DEB.2.00.1304011654520.9148@utopia.booyaka.com>
 <CAOmKuSo4onVtk2Ke-i+0_1Ych33KuUYspRy+cySRHf4yWB5XDw@mail.gmail.com>
 <alpine.DEB.2.00.1304021821190.27146@utopia.booyaka.com>
 <CAOmKuSqd=gNYFutpgDref58pbAbDwDin4mvL_OEooD1XuwKtgQ@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1304030933510.12727@utopia.booyaka.com>

Hi Alexey,

On Wed, 3 Apr 2013, Alexey Pelykh wrote:

> But, since we've found the issue, I suggest that we should look at it
> closer, especially since at this moment only you can reproduce it.

Well probably no one else is testing it :-)

> As far as I understand, but I may be wrong, this comment is wrong, since 
> if to specify OMAP_UART_SCR_RX_TRIG_GRANU1_MASK, it effectively sets Rx 
> threshold to 1 character, instead of 16. /* Set receive FIFO threshold 
> to 16 characters and
>  * transmit FIFO threshold to 16 spaces
>  */

Again it certainly would not surprise me... that UART IP block seems to be 
poorly understood :-(  Bizarre, I know.

- Paul


From khilman at linaro.org  Wed Apr  3 16:58:36 2013
From: khilman at linaro.org (Kevin Hilman)
Date: Wed, 03 Apr 2013 13:58:36 -0700
Subject: [PATCH v2 11/18] ARM: OMAP5: PM: Add L2 memory power down support
In-Reply-To: <1364205910-32392-12-git-send-email-santosh.shilimkar@ti.com>
 (Santosh Shilimkar's message of "Mon, 25 Mar 2013 15:35:03 +0530")
References: <1364205910-32392-1-git-send-email-santosh.shilimkar@ti.com>
 <1364205910-32392-12-git-send-email-santosh.shilimkar@ti.com>
Message-ID: <87ehertjpf.fsf@linaro.org>

Santosh Shilimkar <santosh.shilimkar at ti.com> writes:

> When the entire MPUSS cluster is powered down in device off state, L2 cache
> memory looses it's content and hence while targetting such a state,
> l2 cache needs to be flushed to main memory.
>
> Add the necessary low power code support for the same.
>
> Acked-by: Nishanth Menon <nm at ti.com>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
> ---
>  arch/arm/mach-omap2/omap-secure.h     |    1 +
>  arch/arm/mach-omap2/sleep_omap4plus.S |   21 +++++++++++++++++++++
>  2 files changed, 22 insertions(+)
>
> diff --git a/arch/arm/mach-omap2/omap-secure.h b/arch/arm/mach-omap2/omap-secure.h
> index 1739468..a171a5a 100644
> --- a/arch/arm/mach-omap2/omap-secure.h
> +++ b/arch/arm/mach-omap2/omap-secure.h
> @@ -47,6 +47,7 @@
>  #define OMAP4_MON_L2X0_PREFETCH_INDEX	0x113
>  #define OMAP5_MON_CACHES_CLEAN_INDEX	0x103
>  #define OMAP5_MON_AUX_CTRL_INDEX	0x107
> +#define OMAP5_MON_L2AUX_CTRL_INDEX	0x104

this #define is not used in this patch.

Kevin

>  #define OMAP5_MON_AMBA_IF_INDEX		0x108
>  
> diff --git a/arch/arm/mach-omap2/sleep_omap4plus.S b/arch/arm/mach-omap2/sleep_omap4plus.S
> index 4a5e2e4..288f62f 100644
> --- a/arch/arm/mach-omap2/sleep_omap4plus.S
> +++ b/arch/arm/mach-omap2/sleep_omap4plus.S
> @@ -337,6 +337,7 @@ ENDPROC(omap4_cpu_resume)
>   *	0 - Nothing lost and no need to save: MPUSS INA/CSWR
>   *	1 - CPUx L1 and logic lost: CPU OFF, MPUSS INA/CSWR
>   *	2 - CPUx L1 and logic lost + GIC lost: MPUSS OSWR
> + *	3 - CPUx L1 and logic lost + GIC,L2 lost: MPU OSWR & L2 lost(debug only)
>   */
>  ENTRY(omap5_finish_suspend)
>  	stmfd	sp!, {r4-r12, lr}
> @@ -391,6 +392,26 @@ skip_secure_l1_clean_op:
>  	isb
>  	dsb
>  
> +	bl	omap4_get_sar_ram_base
> +	mov	r8, r0
> +	mrc	p15, 0, r5, c0, c0, 5		@ Read MPIDR
> +	ands	r5, r5, #0x0f
> +	ldreq	r0, [r8, #L2X0_SAVE_OFFSET0]	@ Retrieve L2 state
> +	ldrne	r0, [r8, #L2X0_SAVE_OFFSET1]
> +	cmp	r0, #3
> +	bne	do_wfi
> +	bl	omap4_get_sar_ram_base
> +	ldr	r9, [r0, #OMAP_TYPE_OFFSET]
> +	cmp	r9, #0x1			@ Check for HS device
> +	bne	skip_secure_l2_clean_op
> +	mov	r0, #1				@ Clean secure L2
> +	stmfd   r13!, {r4-r12, r14}
> +	ldr	r12, =OMAP5_MON_CACHES_CLEAN_INDEX
> +	DO_SMC
> +	ldmfd   r13!, {r4-r12, r14}
> +skip_secure_l2_clean_op:
> +	bl	v7_flush_dcache_all
> +
>  do_wfi:
>  	bl	omap_do_wfi


From khilman at linaro.org  Wed Apr  3 17:03:10 2013
From: khilman at linaro.org (Kevin Hilman)
Date: Wed, 03 Apr 2013 14:03:10 -0700
Subject: [PATCH v2 12/18] ARM: OMAP4: CPUidle: Avoid double idle driver
 registration
In-Reply-To: <1364205910-32392-13-git-send-email-santosh.shilimkar@ti.com>
 (Santosh Shilimkar's message of "Mon, 25 Mar 2013 15:35:04 +0530")
References: <1364205910-32392-1-git-send-email-santosh.shilimkar@ti.com>
 <1364205910-32392-13-git-send-email-santosh.shilimkar@ti.com>
Message-ID: <877gkjtjht.fsf@linaro.org>

Santosh Shilimkar <santosh.shilimkar at ti.com> writes:

> OMAP4 CPUidle driver registration call is under a loop which leads
> to calling cpuidle_register_driver twice which is not intended.
>
> Fix it by moving the driver registration outside the loop.
>
> Reported-by: Nishanth Menon <nm at ti.com>
> Acked-by: Nishanth Menon <nm at ti.com>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>

Looks good.

I've already got a for_3.10/fixes/cpuidle branch going, so I'll apply
this one there.

Kevin


From khilman at linaro.org  Wed Apr  3 17:03:59 2013
From: khilman at linaro.org (Kevin Hilman)
Date: Wed, 03 Apr 2013 14:03:59 -0700
Subject: [PATCH v2 13/18] ARM: OMAP: CPUidle: Unregister drivere on device
 registration failure
In-Reply-To: <1364205910-32392-14-git-send-email-santosh.shilimkar@ti.com>
 (Santosh Shilimkar's message of "Mon, 25 Mar 2013 15:35:05 +0530")
References: <1364205910-32392-1-git-send-email-santosh.shilimkar@ti.com>
 <1364205910-32392-14-git-send-email-santosh.shilimkar@ti.com>
Message-ID: <871uartjgg.fsf@linaro.org>

Santosh Shilimkar <santosh.shilimkar at ti.com> writes:

> If the CPUidle device registration fails for some reason, we should
> unregister the driver on error path.
>
> Fix the code accordingly. Also when at it, check of the driver registration
> failure too.
>
> Acked-by: Nishanth Menon <nm at ti.com>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>

Adding to my for_3.10/fixes/cpuidle branch.

Kevin


From linus.walleij at linaro.org  Wed Apr  3 17:05:11 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Wed, 3 Apr 2013 23:05:11 +0200
Subject: [PATCH 3/6] pinctrl: samsung: Split pin bank description into two
 structures
In-Reply-To: <1363642315-10331-4-git-send-email-tomasz.figa@gmail.com>
References: <1363642315-10331-1-git-send-email-tomasz.figa@gmail.com>
 <1363642315-10331-4-git-send-email-tomasz.figa@gmail.com>
Message-ID: <CACRpkdYh27R1qZWGQpenCpUHNpbtAHOh-Cc1iRZnbCT8zPW9aw@mail.gmail.com>

On Mon, Mar 18, 2013 at 10:31 PM, Tomasz Figa <tomasz.figa at gmail.com> wrote:

> This patch splits pin bank description into two structures, one
> describing bank type (currently only bitfield widths), which can be
> shared across multiple banks and second containing bank-specific
> parameters including a pointer to a bank type struct.
>
> It is a prerequisite for further patch removing the statically hardcoded
> register offsets, making it impossible to support SoCs with different
> set and order of pin control registers.
>
> Signed-off-by: Tomasz Figa <tomasz.figa at gmail.com>

I'd like an ACK from Thomas Abraham on this patch.

Thanks,
Linus Walleij


From khilman at linaro.org  Wed Apr  3 17:05:52 2013
From: khilman at linaro.org (Kevin Hilman)
Date: Wed, 03 Apr 2013 14:05:52 -0700
Subject: [PATCH v2 14/18] ARM: OMAP4: CPUidle: Make C-state description
 field more precise
In-Reply-To: <1364205910-32392-15-git-send-email-santosh.shilimkar@ti.com>
 (Santosh Shilimkar's message of "Mon, 25 Mar 2013 15:35:06 +0530")
References: <1364205910-32392-1-git-send-email-santosh.shilimkar@ti.com>
 <1364205910-32392-15-git-send-email-santosh.shilimkar@ti.com>
Message-ID: <87vc83s4sv.fsf@linaro.org>

Santosh Shilimkar <santosh.shilimkar at ti.com> writes:

> It is useful to know the CPU power state along with MPUSS power state
> in a supported C-state. Since the data is available via sysfs, one can
> avoid scrolling the source code for precise construction of C-state.
>
> Reported-by: Nishanth Menon <nm at ti.com>
> Acked-by: Nishanth Menon <nm at ti.com>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>

Nice.

Adding to for_3.10/fixes/cpuidle branch.

Kevin


From alexey.pelykh at gmail.com  Wed Apr  3 17:06:39 2013
From: alexey.pelykh at gmail.com (Alexey Pelykh)
Date: Thu, 4 Apr 2013 00:06:39 +0300
Subject: [PATCH] Revert "OMAP/serial: Fix incorrect Rx FIFO threshold
 setting, LSR validation on Tx, and Tx FIFO IRQ generation"
In-Reply-To: <alpine.DEB.2.00.1304030933510.12727@utopia.booyaka.com>
References: <alpine.DEB.2.00.1304010519260.28273@utopia.booyaka.com>
 <CAOmKuSpttQJmrL=Htiz-Zc4voAF7CnG_GQYAO2onKpauwYjtvw@mail.gmail.com>
 <alpine.DEB.2.00.1304010844100.28273@utopia.booyaka.com>
 <CAOmKuSrABrPcZ=Yg1+LAHWbh9CdTYR0eUmJ2dd3z91oz0uu21g@mail.gmail.com>
 <alpine.DEB.2.00.1304011008230.28273@utopia.booyaka.com>
 <CAOmKuSrbDc025Tj9xsqDebJ_KZdp_VnWAOs_OO5UAegV43JcDQ@mail.gmail.com>
 <CAOmKuSpbaKutLxbNihBRDz+B0Wt0XiPss-PcEHc-efCTvciNFg@mail.gmail.com>
 <alpine.DEB.2.00.1304011654520.9148@utopia.booyaka.com>
 <CAOmKuSo4onVtk2Ke-i+0_1Ych33KuUYspRy+cySRHf4yWB5XDw@mail.gmail.com>
 <alpine.DEB.2.00.1304021821190.27146@utopia.booyaka.com>
 <CAOmKuSqd=gNYFutpgDref58pbAbDwDin4mvL_OEooD1XuwKtgQ@mail.gmail.com>
 <alpine.DEB.2.00.1304030933510.12727@utopia.booyaka.com>
Message-ID: <CAOmKuSr1NohJBZ_sU43b=6oNtk+P1mL=AOA6ZW6c1dLQBkw6Ng@mail.gmail.com>

Hi Paul,

Is it possible to check behavior on 3.0-3.2 kernels?

On Wed, Apr 3, 2013 at 11:57 PM, Paul Walmsley <paul at pwsan.com> wrote:
> Hi Alexey,
>
> On Wed, 3 Apr 2013, Alexey Pelykh wrote:
>
>> But, since we've found the issue, I suggest that we should look at it
>> closer, especially since at this moment only you can reproduce it.
>
> Well probably no one else is testing it :-)
>
>> As far as I understand, but I may be wrong, this comment is wrong, since
>> if to specify OMAP_UART_SCR_RX_TRIG_GRANU1_MASK, it effectively sets Rx
>> threshold to 1 character, instead of 16. /* Set receive FIFO threshold
>> to 16 characters and
>>  * transmit FIFO threshold to 16 spaces
>>  */
>
> Again it certainly would not surprise me... that UART IP block seems to be
> poorly understood :-(  Bizarre, I know.
>
> - Paul


From james.hogan at imgtec.com  Wed Apr  3 17:08:17 2013
From: james.hogan at imgtec.com (James Hogan)
Date: Wed, 3 Apr 2013 22:08:17 +0100
Subject: [RFC PATCH v1 0/3] clk: implement remuxing during set_rate
In-Reply-To: <515B8EAD.8020109@codeaurora.org>
References: <1363967031-22781-1-git-send-email-james.hogan@imgtec.com>
 <515B8EAD.8020109@codeaurora.org>
Message-ID: <CAAG0J99i-AwbGoerTzQvJ+JC9yj-3Owm3e5+6xTijo4Gihcx-Q@mail.gmail.com>

On 3 April 2013 03:06, Stephen Boyd <sboyd at codeaurora.org> wrote:
>
> On 03/22/13 08:43, James Hogan wrote:
> > This patchset adds support for automatic selection of the best parent
> > for a clock mux, i.e. the one which can provide the closest clock rate
> > to that requested. It can be controlled by a new CLK_SET_RATE_REMUX flag
> > so that it doesn't happen unless explicitly allowed.
> >
> > This works by way of adding a parameter to the round_rate clock op which
> > allows the clock driver to optionally select a different parent index.
> > This is used in clk_calc_new_rates to decide whether to initiate a
> > set_parent operation. This would obviously require the argument to be
> > added to all users of round_rate, something this patchset doesn't do as
> > I'm not sure if it's really the preferred method (hence the RFC).
> >
> > An alternative would be to add a new callback, but that would complicate
> > the code in clk.c somewhat. I suppose it would also be possible for the
> > round_rate callback to call a function to set a struct clk member to
> > mark that the parent should change (it's all within mutex protected
> > code after all). Comments anyone?
>
> It seems like you want to be able to call clk_set_rate() on a mux?

Yes, that's right.

> Usually when this comes up people say you should use clk_set_parent()
> but I have a real use case (see below) and maybe you do too.

Agreed, it shouldn't be up to generic drivers to know what clocks to
reparent to in order to get a given frequency.

>
> This patch set caught my eye because we need to be able to switch
> parents during clk_set_rate() on MSM. We usually have two or three PLLs
> feed into a mux that might feed into a divider that feeds into one or
> two gates. I want clk_set_rate() on these gates to propagate up through
> the divider to the mux and then have the mux switch depending on the rate.

We have a similar sort of thing here too. With the hardware I'm
working on, various clocks can be sourced from external oscillators,
the system clock (usually derived form a PLL), or in some cases from
other more complex clocks and PLLs, and are often fed into dividers
and gates which are the clocks that drivers are provided with.

>
> I would like to get away without writing any new code beyond the ops
> that are already there though. Well, I may have to write one new op
> because I have hardware that can change the mux and divider at the same
> time.
>
> Can we push the code into the core? Perhaps by doing what you do in
> clk-mux.c directly in clk_calc_new_rates()? We could store a new_parent
> pointer in struct clk along with the new_rate when we find the best rate
> and then when we propagate rates we can propagate the parent switch.
> This part would be a little tricky if a clock has both a set_parent and
> a set_rate op; what do you call first? The set_rate op? The set_parent
> op? It matters for my hardware. We probably need to introduce a new
> set_rate_and_parent op in case both parts of the equation change so that
> the driver can do it atomically if desired (for my hardware) or in the
> correct order (this part could be two generic functions like
> generic_clk_rate_parent() and generic_clk_parent_rate() for the two
> different orders, or two flags and the logic in the core, whatever).
>
> I like keeping it in the core because we wouldn't need to change the
> round_rate() function signature, it would be called in a loop with
> different parent rates, and we wouldn't have to touch the clk-mux code
> at all because it would all be done generically. Plus I get almost
> everything for free for my hardware, I just need to write a new op that
> does that atomic mux and rate switch. What do you think?

I like this idea a lot. It feels cleaner, and as far as I can tell at
a glance it should be possible. Thanks for the feedback, and comments
about atomic changes, I'll certainly bear those issues in mind so I
don't make it difficult to add that callback. I think it's probably
best in the non-atomic case to default to the existing behaviour (set
parent rate before child rate, which translates to setting parent
before setting rate), and if somebody comes along with a different use
case they can add the necessary flag or whatever to alter the
behaviour.

I won't get any time to try this out for a couple of weeks as I'm on
paternity leave at the moment.

Cheers
James


From swarren at wwwdotorg.org  Wed Apr  3 17:09:37 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Wed, 03 Apr 2013 15:09:37 -0600
Subject: [PATCH V4 1/2] ARM: dt: tegra: add clock source of PMC
In-Reply-To: <1364988688-24613-2-git-send-email-josephl@nvidia.com>
References: <1364988688-24613-1-git-send-email-josephl@nvidia.com>
 <1364988688-24613-2-git-send-email-josephl@nvidia.com>
Message-ID: <515C9A91.3040602@wwwdotorg.org>

On 04/03/2013 05:31 AM, Joseph Lo wrote:
> Adding the bindings of the clock source of PMC in DT.

The series, applied to Tegra's for-3.10/soc branch.

I'd usually apply DT changes to for-3.10/dt, but since the later code
changes depend on this DT change, I included it in the same branch.


From khilman at linaro.org  Wed Apr  3 17:10:27 2013
From: khilman at linaro.org (Kevin Hilman)
Date: Wed, 03 Apr 2013 14:10:27 -0700
Subject: [PATCH v2 15/18] ARM: OMAP4+: CPUidle: Consolidate idle driver
 for OMAP5 support
In-Reply-To: <1364205910-32392-16-git-send-email-santosh.shilimkar@ti.com>
 (Santosh Shilimkar's message of "Mon, 25 Mar 2013 15:35:07 +0530")
References: <1364205910-32392-1-git-send-email-santosh.shilimkar@ti.com>
 <1364205910-32392-16-git-send-email-santosh.shilimkar@ti.com>
Message-ID: <87ip43s4l8.fsf@linaro.org>

Santosh Shilimkar <santosh.shilimkar at ti.com> writes:

> The OMAP5 idle driver can re-use most of OMAP4 CPUidle driver
> implementation. Also the next derivative SOCs are going to re-use
> the MPUSS so, same driver with minor updates can be re-used.
>
> Prepare the code so that its easier to add CPUidle support for
> OMAP5 devices.
>
> Acked-by: Nishanth Menon <nm at ti.com>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
> ---
>  arch/arm/mach-omap2/cpuidle44xx.c |   31 ++++++++++++++++---------------
>  1 file changed, 16 insertions(+), 15 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/cpuidle44xx.c b/arch/arm/mach-omap2/cpuidle44xx.c
> index b8a22f0..ac6d526 100644
> --- a/arch/arm/mach-omap2/cpuidle44xx.c
> +++ b/arch/arm/mach-omap2/cpuidle44xx.c
> @@ -1,7 +1,7 @@
>  /*
> - * OMAP4 CPU idle Routines
> + * OMAP4PLUS CPU idle Routines

nit: s/PLUS/+/ 

in a few other places in this patch also.


>   *
> - * Copyright (C) 2011 Texas Instruments, Inc.
> + * Copyright (C) 2011-2013 Texas Instruments, Inc.
>   * Santosh Shilimkar <santosh.shilimkar at ti.com>
>   * Rajendra Nayak <rnayak at ti.com>
>   *
> @@ -24,13 +24,13 @@
>  #include "clockdomain.h"
>  
>  /* Machine specific information */
> -struct omap4_idle_statedata {
> +struct idle_statedata {
>  	u32 cpu_state;
>  	u32 mpu_logic_state;
>  	u32 mpu_state;
>  };
>  
> -static struct omap4_idle_statedata omap4_idle_data[] = {
> +static struct idle_statedata omap4_idle_data[] = {
>  	{
>  		.cpu_state = PWRDM_POWER_ON,
>  		.mpu_state = PWRDM_POWER_ON,
> @@ -53,11 +53,12 @@ static struct clockdomain *cpu_clkdm[NR_CPUS];
>  
>  static atomic_t abort_barrier;
>  static bool cpu_done[NR_CPUS];
> +static struct idle_statedata *state_ptr = &omap4_idle_data[0];

The assignment at init time (from the next patch) should be done here
for 44xx, and the next patch can just add OMAP5 support.

Kevin


From swarren at wwwdotorg.org  Wed Apr  3 17:10:37 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Wed, 03 Apr 2013 15:10:37 -0600
Subject: [PATCH V6 0/9] ARM: tegra: add platform suspend support
In-Reply-To: <1364988712-24797-1-git-send-email-josephl@nvidia.com>
References: <1364988712-24797-1-git-send-email-josephl@nvidia.com>
Message-ID: <515C9ACD.3030002@wwwdotorg.org>

On 04/03/2013 05:31 AM, Joseph Lo wrote:
> This series introduces a basic functionality for Tegra to support the
> platform suspend and resume.
> 
> Note: This series only adds the support for Tegra20 and Tegra30. The
> Tegra114 will be supported later.

The series is applied.

Patches 1-4 to Tegra's for-3.10/soc branch.
Patches 5-7, 9 to Tegra's for-3.10/dt branch.
Patch 8 squashed into Tegra's for-3.10/defconfig branch.


From swarren at wwwdotorg.org  Wed Apr  3 17:11:21 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Wed, 03 Apr 2013 15:11:21 -0600
Subject: [PATCH V3] ARM: tegra: cpuidle: remove redundant parameters for
 powered-down mode
In-Reply-To: <1364901650-25335-1-git-send-email-josephl@nvidia.com>
References: <1364901650-25335-1-git-send-email-josephl@nvidia.com>
Message-ID: <515C9AF9.9060007@wwwdotorg.org>

On 04/02/2013 05:20 AM, Joseph Lo wrote:
> After the patch series for system suspending support, tegra_idle_lp2_last()
> no longer uses its parameters cpu_on_time or cpu_off_time, so remove them.

Applied to Tegra's for-3.10/soc branch.


From olof at lixom.net  Wed Apr  3 17:12:14 2013
From: olof at lixom.net (Olof Johansson)
Date: Wed, 3 Apr 2013 14:12:14 -0700
Subject: [PATCHv2 1/2] ARM: socfpga: Enable soft reset
In-Reply-To: <20130403203234.GA7643@amd.pavel.ucw.cz>
References: <1363707936-17769-1-git-send-email-dinguyen@altera.com>
 <20130320152915.GA32083@amd.pavel.ucw.cz>
 <20130403185232.GA11360@quad.lixom.net>
 <20130403203234.GA7643@amd.pavel.ucw.cz>
Message-ID: <CAOesGMitpM=6w_81YYO9eYbCCS0oyfihT-6ZYcaeD9TQywChvw@mail.gmail.com>

On Wed, Apr 3, 2013 at 1:32 PM, Pavel Machek <pavel at denx.de> wrote:
> Hi!
>
>> > +struct socfpga_rstmgr_hw {
>> > +   u32 unk;
>> > +   u32 ctrl;               /* 0x04 */
>> > +   u32 unk2, unk3;
>> > +/* MPU Module Reset Register */
>> > +#define RSTMGR_MPUMODRST_CPU0      0x1     /* CPU0 Reset */
>> > +#define RSTMGR_MPUMODRST_CPU1      0x2     /* CPU1 Reset */
>> > +#define RSTMGR_MPUMODRST_WDS       0x4     /* Watchdog Reset */
>> > +#define RSTMGR_MPUMODRST_SCUPER    0x8     /* SCU and periphs reset */
>> > +#define RSTMGR_MPUMODRST_L2        0x10    /* L2 Cache reset */
>> > +   u32 mpumodrst;          /* 0x10 */
>> > +   u32 modperrst;          /* 0x14 */
>> > +   u32 unk5;
>> > +   u32 bgrmodrst;          /* 0x1c */
>> > +};
>>
>> As Russell already replied, struct used to represent register layout is
>> normally frowned upon in drivers.
>
> Well... as Russell also said, this is arch-specific code, so it is
> actually ok.

Which is why I said "normally frowned upon" instead of "always frowned upon".

>> If you want to tighten up the code in this case, make a local helper
>> function that just takes the register offset instead, i.e.:
>>
>> > -   temp = __raw_readl(rst_manager_base_addr + SOCFPGA_RSTMGR_CTRL);
>> > +   temp = readl(&rst_manager_base_addr->ctrl);
>>
>>       temp = rst_readl(SOCFPGA_RSTMGR_CTRL);
>>
>> (and then have rst_readl/rst_writel do the math based on base
>> address).
>
> That does not prevent mistake such as
> rst_readl(SOCFPGA_SYSMGR_CTRL)... and with number of different
> subsystems on socfpga (each with separate base address), I fear that
> might be an issue.
>
> Unfortunately, C does not check type of enums, so they can't be used
> to solve that.

That's no different from accidentally doing
readl(&sys_manager_base_addr->ctrl) instead of
rst_manager_base_addr->ctrl.


-Olof


From csd_b at daudt.org  Wed Apr  3 17:16:15 2013
From: csd_b at daudt.org (Christian Daudt)
Date: Wed, 3 Apr 2013 14:16:15 -0700
Subject: [PATCH V2 1/2] ARM: bcm281xx: Add L2 cache enable code
In-Reply-To: <1363299268-10506-1-git-send-email-csd@broadcom.com>
References: <1363299268-10506-1-git-send-email-csd@broadcom.com>
Message-ID: <CAGFynZ9pE_B8KQNQvWsyn4Yz7tdd5VQwm=c76S-SPsGKNgu9ug@mail.gmail.com>

On Thu, Mar 14, 2013 at 3:14 PM, Christian Daudt <csd at broadcom.com> wrote:
> - Adds a module to provide calls into secure monitor mode
> - Uses this module to make secure monitor calls to enable L2 cache.
>
> Updates from V1:
> - Split DT portion into separate patch
> - replace #ifdef-ed L2 code with "if".
> - move init call to board init
>
> Signed-off-by: Christian Daudt <csd at broadcom.com>
>
> diff --git a/arch/arm/mach-bcm/Makefile b/arch/arm/mach-bcm/Makefile
> index bbf4122..6adb6aec 100644
> --- a/arch/arm/mach-bcm/Makefile
> +++ b/arch/arm/mach-bcm/Makefile
> @@ -10,4 +10,6 @@
>  # of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>  # GNU General Public License for more details.
>
> -obj-$(CONFIG_ARCH_BCM) := board_bcm.o
> +obj-$(CONFIG_ARCH_BCM)         := board_bcm.o bcm_kona_smc.o bcm_kona_smc_asm.o
> +plus_sec := $(call as-instr,.arch_extension sec,+sec)
> +AFLAGS_bcm_kona_smc_asm.o      :=-Wa,-march=armv7-a$(plus_sec)
> diff --git a/arch/arm/mach-bcm/bcm_kona_smc.c b/arch/arm/mach-bcm/bcm_kona_smc.c
> new file mode 100644
> index 0000000..5f1d131
> --- /dev/null
> +++ b/arch/arm/mach-bcm/bcm_kona_smc.c
> @@ -0,0 +1,118 @@
> +/*
> + * Copyright (C) 2013 Broadcom Corporation
> + *
> + * 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 version 2.
> + *
> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
> + * kind, whether express or implied; without even the implied warranty
> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include <stdarg.h>
> +#include <linux/smp.h>
> +#include <linux/io.h>
> +#include <linux/ioport.h>
> +
> +#include <asm/cacheflush.h>
> +#include <linux/of_address.h>
> +
> +#include "bcm_kona_smc.h"
> +
> +struct secure_bridge_data {
> +       void __iomem *bounce;           /* virtual address */
> +       u32 __iomem buffer_addr;        /* physical address */
> +       int initialized;
> +} bridge_data;
> +
> +struct bcm_kona_smc_data {
> +       unsigned service_id;
> +       unsigned arg0;
> +       unsigned arg1;
> +       unsigned arg2;
> +       unsigned arg3;
> +};
> +
> +static const struct of_device_id bcm_kona_smc_ids[] __initconst = {
> +       {.compatible = "bcm,kona-smc"},
> +       {},
> +};
> +
> +/* Map in the bounce area */
> +void bcm_kona_smc_init(void)
> +{
> +       struct device_node *node;
> +
> +       /* Read buffer addr and size from the device tree node */
> +       node = of_find_matching_node(NULL, bcm_kona_smc_ids);
> +       BUG_ON(!node);
> +
> +       /* Don't care about size or flags of the DT node */
> +       bridge_data.buffer_addr =
> +               be32_to_cpu(*of_get_address(node, 0, NULL, NULL));
> +       BUG_ON(!bridge_data.buffer_addr);
> +
> +       bridge_data.bounce = of_iomap(node, 0);
> +       BUG_ON(!bridge_data.bounce);
> +
> +       bridge_data.initialized = 1;
> +
> +       pr_info("Secure API initialized!\n");
> +}
> +
> +/* __bcm_kona_smc() should only run on CPU 0, with pre-emption disabled */
> +static void __bcm_kona_smc(void *info)
> +{
> +       struct bcm_kona_smc_data *data = info;
> +       u32 *args = bridge_data.bounce;
> +       int rc = 0;
> +
> +       /* Must run on CPU 0 */
> +       BUG_ON(smp_processor_id() != 0);
> +
> +       /* Check map in the bounce area */
> +       BUG_ON(!bridge_data.initialized);
> +
> +       /* Copy one 32 bit word into the bounce area */
> +       args[0] = data->arg0;
> +       args[1] = data->arg1;
> +       args[2] = data->arg2;
> +       args[3] = data->arg3;
> +
> +       /* Flush caches for input data passed to Secure Monitor */
> +       if (data->service_id != SSAPI_BRCM_START_VC_CORE)
> +               flush_cache_all();
> +
> +       /* Trap into Secure Monitor */
> +       rc = bcm_kona_smc_asm(data->service_id, bridge_data.buffer_addr);
> +
> +       if (rc != SEC_ROM_RET_OK)
> +               pr_err("Secure Monitor call failed (0x%x)!\n", rc);
> +}
> +
> +unsigned bcm_kona_smc(unsigned service_id, unsigned arg0, unsigned arg1,
> +                 unsigned arg2, unsigned arg3)
> +{
> +       struct bcm_kona_smc_data data;
> +
> +       data.service_id = service_id;
> +       data.arg0 = arg0;
> +       data.arg1 = arg1;
> +       data.arg2 = arg2;
> +       data.arg3 = arg3;
> +
> +       /*
> +        * Due to a limitation of the secure monitor, we must use the SMP
> +        * infrastructure to forward all secure monitor calls to Core 0.
> +        */
> +       if (get_cpu() != 0)
> +               smp_call_function_single(0, __bcm_kona_smc, (void *)&data, 1);
> +       else
> +               __bcm_kona_smc(&data);
> +
> +       put_cpu();
> +
> +       return 0;
> +}
> diff --git a/arch/arm/mach-bcm/bcm_kona_smc.h b/arch/arm/mach-bcm/bcm_kona_smc.h
> new file mode 100644
> index 0000000..3bedbed
> --- /dev/null
> +++ b/arch/arm/mach-bcm/bcm_kona_smc.h
> @@ -0,0 +1,80 @@
> +/*
> + * Copyright (C) 2013 Broadcom Corporation
> + *
> + * 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 version 2.
> + *
> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
> + * kind, whether express or implied; without even the implied warranty
> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#ifndef BCM_KONA_SMC_H
> +#define BCM_KONA_SMC_H
> +
> +#include <linux/types.h>
> +#define FLAGS  (SEC_ROM_ICACHE_ENABLE_MASK | SEC_ROM_DCACHE_ENABLE_MASK | \
> +                       SEC_ROM_IRQ_ENABLE_MASK | SEC_ROM_FIQ_ENABLE_MASK)
> +
> +/*!
> + * Definitions for IRQ & FIQ Mask for ARM
> + */
> +
> +#define FIQ_IRQ_MASK                                           0xC0
> +#define FIQ_MASK                                               0x40
> +#define IRQ_MASK                                               0x80
> +
> +/*!
> + * Secure Mode FLAGs
> + */
> +
> +/* When set, enables ICache within the secure mode */
> +#define SEC_ROM_ICACHE_ENABLE_MASK                        0x00000001
> +
> +/* When set, enables DCache within the secure mode */
> +#define SEC_ROM_DCACHE_ENABLE_MASK                        0x00000002
> +
> +/* When set, enables IRQ within the secure mode */
> +#define SEC_ROM_IRQ_ENABLE_MASK                           0x00000004
> +
> +/* When set, enables FIQ within the secure mode */
> +#define SEC_ROM_FIQ_ENABLE_MASK                           0x00000008
> +
> +/* When set, enables Unified L2 cache within the secure mode */
> +#define SEC_ROM_UL2_CACHE_ENABLE_MASK                     0x00000010
> +
> +/* Broadcom Secure Service API Service IDs */
> +#define SSAPI_DORMANT_ENTRY_SERV                          0x01000000
> +#define SSAPI_PUBLIC_OTP_SERV                             0x01000001
> +#define SSAPI_ENABLE_L2_CACHE                             0x01000002
> +#define SSAPI_DISABLE_L2_CACHE                            0x01000003
> +#define SSAPI_WRITE_SCU_STATUS                            0x01000004
> +#define SSAPI_WRITE_PWR_GATE                              0x01000005
> +
> +/* Broadcom Secure Service API Return Codes */
> +#define SEC_ROM_RET_OK                 0x00000001
> +#define SEC_ROM_RET_FAIL               0x00000009
> +
> +#define SSAPI_RET_FROM_INT_SERV                0x4
> +#define SEC_EXIT_NORMAL                        0x1
> +
> +#define SSAPI_ROW_AES                  0x0E000006
> +#define SSAPI_BRCM_START_VC_CORE       0x0E000008
> +
> +#ifndef        __ASSEMBLY__
> +extern void bcm_kona_smc_init(void);
> +
> +extern unsigned bcm_kona_smc(unsigned service_id,
> +                            unsigned arg0,
> +                            unsigned arg1,
> +                            unsigned arg2,
> +                            unsigned arg3);
> +
> +extern int bcm_kona_smc_asm(u32 service_id,
> +                           u32 buffer_addr);
> +
> +#endif /* __ASSEMBLY__ */
> +
> +#endif /* BCM_KONA_SMC_H */
> diff --git a/arch/arm/mach-bcm/bcm_kona_smc_asm.S b/arch/arm/mach-bcm/bcm_kona_smc_asm.S
> new file mode 100644
> index 0000000..a160848
> --- /dev/null
> +++ b/arch/arm/mach-bcm/bcm_kona_smc_asm.S
> @@ -0,0 +1,41 @@
> +/*
> + * Copyright (C) 2013 Broadcom Corporation
> + *
> + * 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 version 2.
> + *
> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
> + * kind, whether express or implied; without even the implied warranty
> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include <linux/linkage.h>
> +#include "bcm_kona_smc.h"
> +
> +/*
> + * int bcm_kona_smc_asm(u32 service_id, u32 buffer_addr)
> + */
> +
> +ENTRY(bcm_kona_smc_asm)
> +       stmfd   sp!, {r4-r12, lr}
> +       mov     r4, r0          @ service_id
> +       mov     r5, #3          @ Keep IRQ and FIQ off in SM
> +       /*
> +        * Since interrupts are disabled in the open mode, we must keep
> +        * interrupts disabled in secure mode by setting R5=0x3. If interrupts
> +        * are enabled in open mode, we can set R5=0x0 to allow interrupts in
> +        * secure mode.  If we did this, the secure monitor would return back
> +        * control to the open mode to handle the interrupt prior to completing
> +        * the secure service. If this happened, R12 would not be
> +        * SEC_EXIT_NORMAL and we would need to call SMC again after resetting
> +        * R5 (it gets clobbered by the secure monitor) and setting R4 to
> +        * SSAPI_RET_FROM_INT_SERV to indicate that we want the secure monitor
> +        * to finish up the previous uncompleted secure service.
> +        */
> +       mov     r6, r1          @ buffer_addr
> +       smc     #0
> +       /* Check r12 for SEC_EXIT_NORMAL here if interrupts are enabled */
> +       ldmfd   sp!, {r4-r12, pc}
> +ENDPROC(bcm_kona_smc_asm)
> diff --git a/arch/arm/mach-bcm/board_bcm.c b/arch/arm/mach-bcm/board_bcm.c
> index 2595935..e2ddfec 100644
> --- a/arch/arm/mach-bcm/board_bcm.c
> +++ b/arch/arm/mach-bcm/board_bcm.c
> @@ -16,16 +16,39 @@
>  #include <linux/device.h>
>  #include <linux/platform_device.h>
>  #include <linux/irqchip.h>
> +#include <asm/hardware/cache-l2x0.h>
>  #include <linux/clocksource.h>
>
>  #include <asm/mach/arch.h>
>  #include <asm/mach/time.h>
>
>
> +#include "bcm_kona_smc.h"
> +
> +static int __init kona_l2_cache_init(void)
> +{
> +       if (!IS_ENABLED(CONFIG_CACHE_L2X0))
> +               return 0;
> +
> +       bcm_kona_smc(SSAPI_ENABLE_L2_CACHE, 0, 0, 0, 0);
> +
> +       /*
> +        * The aux_val and aux_mask have no effect since L2 cache is already
> +        * enabled.  Pass 0s for aux_val and 1s for aux_mask for default value.
> +        */
> +       l2x0_of_init(0, ~0);
> +
> +       return 0;
> +}
> +
>  static void __init board_init(void)
>  {
>         of_platform_populate(NULL, of_default_bus_match_table, NULL,
>                 &platform_bus);
> +
> +       bcm_kona_smc_init();
> +
> +       kona_l2_cache_init();
>  }
>
>  static const char * const bcm11351_dt_compat[] = { "bcm,bcm11351", NULL, };
> --
> 1.7.10.4
>
>

any willing reviewers ?

 Thanks,
   csd


From swarren at wwwdotorg.org  Wed Apr  3 17:20:01 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Wed, 03 Apr 2013 15:20:01 -0600
Subject: [PATCH V5 1/9] gpio: tegra: add gpio wakeup source handling
In-Reply-To: <515C5E43.1080904@wwwdotorg.org>
References: <1364901613-25080-1-git-send-email-josephl@nvidia.com>
 <1364901613-25080-2-git-send-email-josephl@nvidia.com>
 <CACRpkdYOLuUyBu7ER7hqLGZnAoYS0Z7XJ6LC2=ec3vxKzF1rqA@mail.gmail.com>
 <515C5E43.1080904@wwwdotorg.org>
Message-ID: <515C9D01.8090800@wwwdotorg.org>

On 04/03/2013 10:52 AM, Stephen Warren wrote:
> On 04/03/2013 10:29 AM, Linus Walleij wrote:
>> On Tue, Apr 2, 2013 at 1:20 PM, Joseph Lo <josephl at nvidia.com> wrote:
>>> This patch ad
>> d the gpio wakeup source handling for the Tegra platform. It
>>> was be done by enabling the irq for the gpio in the gpio controller and
>>> enabling the bank irq of the gpio in the Tegra legacy irq controller when
>>> the system going to suspend.
>>>
>>> Based on the work by:
>>> Varun Wadekar <vwadekar at nvidia.com>
>>>
>>> Cc: Grant Likely <grant.likely at secretlab.ca>
>>> Cc: Linus Walleij <linus.walleij at linaro.org>
>>> Signed-off-by: Joseph Lo <josephl at nvidia.com>
>>> Acked-by: Linus Walleij <linus.walleij at linaro.org>
>>> ---
>>> V5:
>>> * no change
>>> V4:
>>> * no change
>>> V3:
>>> * no change
>>> V2:
>>> * no change
>>
>> Shall I just apply this to the GPIO tree to stop these repetitive mails
>> from coming?
> 
> It's part of a series where other patches are being rev'd. I'll apply it
> to the Tegra tree with the series once it's final.

By the way, it's checked in now, so there won't be any more versions posted.

I guess I should have just applied this patch in an earlier iteration
since it was ack'd and only later patches in the series needed changes.


From maxime.ripard at free-electrons.com  Wed Apr  3 17:20:37 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Wed, 03 Apr 2013 23:20:37 +0200
Subject: [PATCH 4/6] pinctrl: sunxi: add clock support
In-Reply-To: <CACRpkda80EKT2LbsBCOng=gkdtdd+vbYwkMPiFZUBx7z_aqY+A@mail.gmail.com>
References: <1363962042-29536-1-git-send-email-emilio@elopez.com.ar>
 <1363962042-29536-5-git-send-email-emilio@elopez.com.ar>
 <CACRpkdbn9c_bAWUN8hTLkeidCnyZ=0nRQRBV39DMkK_0jBfoUQ@mail.gmail.com>
 <51535077.1050203@free-electrons.com>
 <CACRpkda80EKT2LbsBCOng=gkdtdd+vbYwkMPiFZUBx7z_aqY+A@mail.gmail.com>
Message-ID: <515C9D25.3050407@free-electrons.com>

Hi Linus,

Le 03/04/2013 13:59, Linus Walleij a ?crit :
> On Wed, Mar 27, 2013 at 9:03 PM, Maxime Ripard
> <maxime.ripard at free-electrons.com> wrote:
> 
>> Hi Linus,
>> Le 27/03/2013 14:14, Linus Walleij a ?crit :
>>> On Fri, Mar 22, 2013 at 3:20 PM, Emilio L?pez <emilio at elopez.com.ar> wrote:
>>>
>>>> For the port controller to work, we need to enable the apb0_pio gate.
>>>> This commit adds the ability to enable one clock specified on the device
>>>> tree to the pinctrl driver.
>>>>
>>>> Signed-off-by: Emilio L?pez <emilio at elopez.com.ar>
>>>
>>> Acked-by: Linus Walleij <linus.walleij at linaro.org>
>>>
>>> I guess you'll want to merge these as one series to some platform-specific
>>> tree, tell me if you want it merged in the pinctrl tree.
>>
>> The easiest would probably be to merge this patch through your patch,
>> with Mike taking the clock driver patches and me taking the dt ones,
>> once we agree on the other patches.
> 
> OK then, patch applied to the pinctrl tree, thanks!

Ouch, the previous patches aren't applied yet by Mike, and we didn't
have some comments from him about these patches, so I can't really say
if the previous patches will get merge by 3.10 or not... So we will
maybe end up with a broken pinctrl stuff.

Mike, do you have some comments on Emilio's patches?

If you do, we can still fix things up later by applying a slightly
modified version of patches 5/6 with a clock that is already there, for
it to load properly.

Thanks,
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


From swarren at wwwdotorg.org  Wed Apr  3 17:23:03 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Wed, 03 Apr 2013 15:23:03 -0600
Subject: [PATCHv5 0/7] arm: vt8500: Add support for pinctrl/gpio module
In-Reply-To: <CACRpkdZAtgpfA5rZ_C=eKDDOE9aDm=3k1QDava=EGL2BaoV+0g@mail.gmail.com>
References: <1364970291-17721-1-git-send-email-linux@prisktech.co.nz>
 <CACRpkdZAtgpfA5rZ_C=eKDDOE9aDm=3k1QDava=EGL2BaoV+0g@mail.gmail.com>
Message-ID: <515C9DB7.9000908@wwwdotorg.org>

On 04/03/2013 07:40 AM, Linus Walleij wrote:
> On Wed, Apr 3, 2013 at 8:24 AM, Tony Prisk <linux at prisktech.co.nz> wrote:
> 
>> v5 changes:
>> Changed as requested by Rob Herring:
>> Added of_find_property_value_of_size() to drivers/of/base.c to remove some
>> code that was being duplicated.
>>
>> Changed as requested by Stephen Warren:
>> Redid the kfree(maps) code as devm_kzalloc would cause issues. We now kzalloc
>> maps all at once, and configs as required. A call to wmt_pctl_dt_free_map() is
>> used to kfree the allocated blocks if we fail early.
> 
> This v5 series:
> Acked-by: Linus Walleij <linus.walleij at linaro.org>
> 
> I guess it will go in through the VT8500 tree eventually?
> 
> Maybe you could put Stephen's BCMring patch on top when sending
> it in (also Acked-by) so we can avoid having that dangling.

s/bcmring/bcm2835/ :-)


From khilman at linaro.org  Wed Apr  3 17:25:05 2013
From: khilman at linaro.org (Kevin Hilman)
Date: Wed, 03 Apr 2013 14:25:05 -0700
Subject: [PATCH v2 17/18] ARM: OMAP4+: CPUidle: Add OMAP5 idle driver
 support
In-Reply-To: <1364205910-32392-18-git-send-email-santosh.shilimkar@ti.com>
 (Santosh Shilimkar's message of "Mon, 25 Mar 2013 15:35:09 +0530")
References: <1364205910-32392-1-git-send-email-santosh.shilimkar@ti.com>
 <1364205910-32392-18-git-send-email-santosh.shilimkar@ti.com>
Message-ID: <87fvz7qpce.fsf@linaro.org>

Santosh Shilimkar <santosh.shilimkar at ti.com> writes:

> The OMAP5 idle driver can re-use OMAP4 CPUidle driver implementation thanks
> to compatible MPUSS design.
>
> Though unlike OMAP4, on OMAP5 devices, MPUSS CSWR (Close Switch
> Retention) power states can be achieved with respective power states
> on CPU0 and CPU1 power domain. This mode was broken on OMAP4 devices
> because of hardware limitation.

I'm a bit confused by the description here.

I gather from the code that this means that CPU0 and CPU1 can hit CSWR
independently, correct?

> Also there is no CPU low power entry order requirement like
> master CPU etc for CSWR C-state, which is icing on the cake. 

Even on secure devices?

> Code makes use of voting scheme for cluster low power state to support
> MPUSS CSWR C-state.

The voting scheme and associated locking should be better described
here, or commented in the code itself.

> Supported OMAP5 CPUidle C-states:
>         C1 - CPU0 ON(WFI) + CPU1 ON(WFI) + MPUSS ON
>         C2 - CPU0 CSWR + CPU1 CSWR + MPUSS CSWR
>         C3 - CPU0 OFF + CPU1 OFF + MPUSS OSWR
>
> Acked-by: Nishanth Menon <nm at ti.com>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>

[...]

> +static int omap_enter_idle_smp(struct cpuidle_device *dev,
> +			struct cpuidle_driver *drv,
> +			int index)
> +{
> +	struct idle_statedata *cx = state_ptr + index;
> +	int cpu_id = smp_processor_id();
> +	unsigned long flag;
> +
> +	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &cpu_id);

I think the CPUidle core handles the broadcast notification now.

> +	raw_spin_lock_irqsave(&mpu_lock, flag);
> +	cx->mpu_state_vote++;

How about using an atomic_t and atomic_inc()/atomic_dec() instead, which
will avoid the need for a spinlock.

Even with that, it still seems potentially racy.  Do you need a memory
barrier here to be sure that any changes from another CPU are visible
here, and vice versa?

> +	if (cx->mpu_state_vote == num_online_cpus()) {
> +		pwrdm_set_logic_retst(mpu_pd, cx->mpu_logic_state);
> +		omap_set_pwrdm_state(mpu_pd, cx->mpu_state);
> +	}
> +	raw_spin_unlock_irqrestore(&mpu_lock, flag);
> +
> +	omap4_enter_lowpower(dev->cpu, cx->cpu_state);
> +
> +	raw_spin_lock_irqsave(&mpu_lock, flag);
> +	if (cx->mpu_state_vote == num_online_cpus())
> +		omap_set_pwrdm_state(mpu_pd, PWRDM_POWER_ON);
> +	cx->mpu_state_vote--;
> +	raw_spin_unlock_irqrestore(&mpu_lock, flag);
> +
> +	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &cpu_id);
> +
> +	return index;
> +}

Kevin


From swarren at wwwdotorg.org  Wed Apr  3 17:25:12 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Wed, 03 Apr 2013 15:25:12 -0600
Subject: [PATCHv5 4/7] pinctrl: gpio: vt8500: Add pincontrol driver for
 arch-vt8500
In-Reply-To: <1364970291-17721-5-git-send-email-linux@prisktech.co.nz>
References: <1364970291-17721-1-git-send-email-linux@prisktech.co.nz>
 <1364970291-17721-5-git-send-email-linux@prisktech.co.nz>
Message-ID: <515C9E38.9060603@wwwdotorg.org>

On 04/03/2013 12:24 AM, Tony Prisk wrote:
> This patch adds support for the GPIO/pinmux controller found on the VIA
> VT8500 and Wondermedia WM8xxx-series SoCs.
> 
> Each pin within the controller is capable of operating as a GPIO or as
> an alternate function. The pins are numbered according to their control
> bank/bit so that if new pins are added, the existing numbering is maintained.
> 
> All currently supported SoCs are included: VT8500, WM8505, WM8650, WM8750 and
> WM8850.
> 
> Signed-off-by: Tony Prisk <linux at prisktech.co.nz>
> Reviewed-by: Stephen Warren <swarren at nvidia.com>

At a quick glance, the alloc/free stuff looks good in this patch, so I
re-affirm the reviewed-by above.


From mturquette at linaro.org  Wed Apr  3 17:34:12 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Wed, 03 Apr 2013 14:34:12 -0700
Subject: [RFC PATCH v1 0/3] clk: implement remuxing during set_rate
In-Reply-To: <CAAG0J99i-AwbGoerTzQvJ+JC9yj-3Owm3e5+6xTijo4Gihcx-Q@mail.gmail.com>
References: <1363967031-22781-1-git-send-email-james.hogan@imgtec.com>
 <515B8EAD.8020109@codeaurora.org>
 <CAAG0J99i-AwbGoerTzQvJ+JC9yj-3Owm3e5+6xTijo4Gihcx-Q@mail.gmail.com>
Message-ID: <20130403213412.3383.84823@quantum>

Quoting James Hogan (2013-04-03 14:08:17)
> On 3 April 2013 03:06, Stephen Boyd <sboyd at codeaurora.org> wrote:
> >
> > On 03/22/13 08:43, James Hogan wrote:
> > > This patchset adds support for automatic selection of the best parent
> > > for a clock mux, i.e. the one which can provide the closest clock rate
> > > to that requested. It can be controlled by a new CLK_SET_RATE_REMUX flag
> > > so that it doesn't happen unless explicitly allowed.
> > >
> > > This works by way of adding a parameter to the round_rate clock op which
> > > allows the clock driver to optionally select a different parent index.
> > > This is used in clk_calc_new_rates to decide whether to initiate a
> > > set_parent operation. This would obviously require the argument to be
> > > added to all users of round_rate, something this patchset doesn't do as
> > > I'm not sure if it's really the preferred method (hence the RFC).
> > >
> > > An alternative would be to add a new callback, but that would complicate
> > > the code in clk.c somewhat. I suppose it would also be possible for the
> > > round_rate callback to call a function to set a struct clk member to
> > > mark that the parent should change (it's all within mutex protected
> > > code after all). Comments anyone?
> >
> > It seems like you want to be able to call clk_set_rate() on a mux?
> 
> Yes, that's right.
> 
> > Usually when this comes up people say you should use clk_set_parent()
> > but I have a real use case (see below) and maybe you do too.
> 
> Agreed, it shouldn't be up to generic drivers to know what clocks to
> reparent to in order to get a given frequency.
> 
> >
> > This patch set caught my eye because we need to be able to switch
> > parents during clk_set_rate() on MSM. We usually have two or three PLLs
> > feed into a mux that might feed into a divider that feeds into one or
> > two gates. I want clk_set_rate() on these gates to propagate up through
> > the divider to the mux and then have the mux switch depending on the rate.
> 
> We have a similar sort of thing here too. With the hardware I'm
> working on, various clocks can be sourced from external oscillators,
> the system clock (usually derived form a PLL), or in some cases from
> other more complex clocks and PLLs, and are often fed into dividers
> and gates which are the clocks that drivers are provided with.
> 
> >
> > I would like to get away without writing any new code beyond the ops
> > that are already there though. Well, I may have to write one new op
> > because I have hardware that can change the mux and divider at the same
> > time.
> >
> > Can we push the code into the core? Perhaps by doing what you do in
> > clk-mux.c directly in clk_calc_new_rates()? We could store a new_parent
> > pointer in struct clk along with the new_rate when we find the best rate
> > and then when we propagate rates we can propagate the parent switch.
> > This part would be a little tricky if a clock has both a set_parent and
> > a set_rate op; what do you call first? The set_rate op? The set_parent
> > op? It matters for my hardware. We probably need to introduce a new
> > set_rate_and_parent op in case both parts of the equation change so that
> > the driver can do it atomically if desired (for my hardware) or in the
> > correct order (this part could be two generic functions like
> > generic_clk_rate_parent() and generic_clk_parent_rate() for the two
> > different orders, or two flags and the logic in the core, whatever).
> >

This has been discussed several times in the past and the core
definitely should handle this in a similar fashion to the way
clk->ops->recalc_rate can request a better parent rate.

One thought to not break compatibility might be something like:

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 0230c9d..0708fa3 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -1043,12 +1043,17 @@ static struct clk *clk_calc_new_rates(struct clk *clk, unsigned long rate)
 
 	/* never propagate up to the parent */
 	if (!(clk->flags & CLK_SET_RATE_PARENT)) {
-		if (!clk->ops->round_rate) {
+		if (clk->ops->determine_rate) {
+			new_rate = clk->ops->determine_rate(clk->hw, rate,
+					&best_parent_rate, &best_parent_clk);
+			goto out;
+		} else if (clk->ops->round_rate) {
+			new_rate = clk->ops->round_rate(clk->hw, rate, &best_parent_rate);
+			goto out;
+		} else {
 			clk->new_rate = clk->rate;
 			return NULL;
 		}
-		new_rate = clk->ops->round_rate(clk->hw, rate, &best_parent_rate);
-		goto out;
 	}
 
 	/* need clk->parent from here on out */
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 9fdfae7..1a19186 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -126,6 +126,9 @@ struct clk_ops {
 					unsigned long parent_rate);
 	long		(*round_rate)(struct clk_hw *hw, unsigned long,
 					unsigned long *);
+	s64		(*determine_rate)(struct clk_hw *hw, unsigned long rate,
+					unsigned long *best_parent_rate,
+					struct clk *best_parent_clk);
 	int		(*set_parent)(struct clk_hw *hw, u8 index);
 	u8		(*get_parent)(struct clk_hw *hw);
 	int		(*set_rate)(struct clk_hw *hw, unsigned long,

Obviously lots of stuff is missing there, but it would not force every
user of .round_rate to add a new best_parent_clk parameter.  Perhaps
.round_rate could be phased out in the future... or perhaps it would be
better to just do a mass update of all .round_rate implementations.  It
is worth pointing out that the top-level clk_round_rate api would not be
changed; the idea above only affects clk drivers using the common struct
clk.

> > I like keeping it in the core because we wouldn't need to change the
> > round_rate() function signature, it would be called in a loop with
> > different parent rates, and we wouldn't have to touch the clk-mux code
> > at all because it would all be done generically. Plus I get almost
> > everything for free for my hardware, I just need to write a new op that
> > does that atomic mux and rate switch. What do you think?
> 

Flags might be necessary to favor rate-change versus reparent, but that
is a small detail.

> I like this idea a lot. It feels cleaner, and as far as I can tell at
> a glance it should be possible. Thanks for the feedback, and comments
> about atomic changes, I'll certainly bear those issues in mind so I
> don't make it difficult to add that callback. I think it's probably
> best in the non-atomic case to default to the existing behaviour (set
> parent rate before child rate, which translates to setting parent
> before setting rate), and if somebody comes along with a different use
> case they can add the necessary flag or whatever to alter the
> behaviour.
> 
> I won't get any time to try this out for a couple of weeks as I'm on
> paternity leave at the moment.
> 

Congratulations!  Enjoy your leave, or at least try to not become sleep
deprived.

I'll add this to my stack but it's pretty far and away compared to other
items.  Feel free to beat me to it if you like.

Regards,
Mike

> Cheers
> James


From robherring2 at gmail.com  Wed Apr  3 17:34:24 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Wed, 03 Apr 2013 16:34:24 -0500
Subject: [PATCH] clocksource: tegra: enable arch_timer
In-Reply-To: <515C7363.4040404@wwwdotorg.org>
References: <1364988750-25058-1-git-send-email-josephl@nvidia.com>
 <515C2E8F.1030802@gmail.com> <515C7363.4040404@wwwdotorg.org>
Message-ID: <515CA060.7030100@gmail.com>

On 04/03/2013 01:22 PM, Stephen Warren wrote:
> On 04/03/2013 07:28 AM, Rob Herring wrote:
>> On 04/03/2013 06:32 AM, Joseph Lo wrote:
>>> Architected timer is the local timer for Cortex-A15. Adding the support
>>> for Tegra.
>>>
>>> Cc: John Stultz <john.stultz at linaro.org>
>>> Cc: Thomas Gleixner <tglx at linutronix.de>
>>> Signed-off-by: Joseph Lo <josephl at nvidia.com>
>>
>> My patch series to add CLOCKSOURCE_OF_DECLARE support to arch timer and
>> sched_clock enhancements will make this unnecessary:
>>
>> http://www.spinics.net/lists/arm-kernel/msg234597.html
>>
>> Testing would be appreciated.
> 
> Joseph (or Rob), what's the benefit of this change; what works with it
> and/or what breaks without it?

I assume you mean Joseph's change. Well, it enables local timers on A15.
But mine will too for Tegra if you have the arch timer in the dtb.

> Rob, if I did apply this change, and you also apply that series of
> yours, what is the result: compile-time breakage, run-time breakage,
> just some redundant code that needs to be removed again?

Compile-time breakage as the functions called here are being removed.

Rob



From linus.walleij at linaro.org  Wed Apr  3 17:36:20 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Wed, 3 Apr 2013 23:36:20 +0200
Subject: [PATCH 4/9] ARM: ux500: Move Snowball's thermal DT node into
 existing PRCMU one
In-Reply-To: <CACRpkdar=xD34yaMP2gOfUPkpxOhDymS6zTedKOEW7j2DNHusA@mail.gmail.com>
References: <1364908916-29803-1-git-send-email-lee.jones@linaro.org>
 <1364908916-29803-4-git-send-email-lee.jones@linaro.org>
 <CACRpkdar=xD34yaMP2gOfUPkpxOhDymS6zTedKOEW7j2DNHusA@mail.gmail.com>
Message-ID: <CACRpkda08Joe9aXRgYDUs622GELL+O1vZSnzzCBa++m1zZZi=g@mail.gmail.com>

On Wed, Apr 3, 2013 at 10:38 PM, Linus Walleij <linus.walleij at linaro.org> wrote:
> On Tue, Apr 2, 2013 at 3:21 PM, Lee Jones <lee.jones at linaro.org> wrote:
>
>> When the thermal DT node was inserted a new PRCMU node was created;
>> however, one already exists in the Snowball DTS file. Here we
>> amalgamate the two into a single consolidated node.
>>
>> Signed-off-by: Lee Jones <lee.jones at linaro.org>
>
> Patch applied.

After applying this I get this:

  DTC     arch/arm/boot/dts/snowball.dtb
Error: /home/elinwal/linux-stericsson/arch/arm/boot/dts/snowball.dts:351.3-352.1
syntax error
FATAL ERROR: Unable to parse input tree
make[3]: *** [arch/arm/boot/dts/snowball.dtb] Error 1
make[2]: *** [dtbs] Error 2
make[1]: *** [sub-make] Error 2
make[1]: Leaving directory `/home/elinwal/linux-stericsson'
make: *** [build-dtbs] Error 2

Does not appear prior to applying patch.

It doesn't quiet apply cleanly either, what is this based on?

Yours,
Linus Walleij


From khilman at linaro.org  Wed Apr  3 17:37:18 2013
From: khilman at linaro.org (Kevin Hilman)
Date: Wed, 03 Apr 2013 14:37:18 -0700
Subject: [PATCH v2 16/18] ARM: OMAP4+: CPUidle: Deprecate use of
 omap4_mpuss_read_prev_context_state()
In-Reply-To: <1364205910-32392-17-git-send-email-santosh.shilimkar@ti.com>
 (Santosh Shilimkar's message of "Mon, 25 Mar 2013 15:35:08 +0530")
References: <1364205910-32392-1-git-send-email-santosh.shilimkar@ti.com>
 <1364205910-32392-17-git-send-email-santosh.shilimkar@ti.com>
Message-ID: <876203qos1.fsf@linaro.org>

Santosh Shilimkar <santosh.shilimkar at ti.com> writes:

> Current OMAP4 CPUIdle driver is using omap4_mpuss_read_prev_context_state()
> function to check whether the MPU cluster lost context or not. Thanks to
> couple CPUIdle, cluster low power entry is almost guaranteed and hence
> the programmed cluster check is enough in idle exit path. The API was
> more of an optimization for corner cases, where if the cluster low power
> entry fails for some reason, the cluster context restore gets skipped.
>
> Moving forward, OMAP CPUidle drivers needs to be moved to drivers/idle/*
> once the PRM/CM code gets moved to drivers. This patch also reduces one
> dependency with platform code for idle driver movement.
>
> Acked-by: Nishanth Menon <nm at ti.com>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>

Looks good, but I find the changelog a bit confusing.

Below is a slightly modified patch (I only modified the changelog).  If
those changes are OK with you, I'll add it to my cpuidle branch as well.

Kevin

>From c01794dc249f826f0714578f26ff9efd35ea6296 Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar <santosh.shilimkar at ti.com>
Date: Mon, 25 Mar 2013 15:35:08 +0530
Subject: [PATCH] ARM: OMAP4+: CPUidle: Deprecate use of
 omap4_mpuss_read_prev_context_state()

Current OMAP4 CPUIdle driver is using omap4_mpuss_read_prev_context_state()
to check whether the MPU cluster lost context or not before calling
cpu_cluster_pm_exit().  This was initially done an optimization for
corner cases, where if the cluster low power entry fails for some
reason, the cluster context restore gets skipped.  However, since
reading the previous context is expensive (involving slow accesses to
the PRCM), it's better to avoid it and simply check the target cluster
state instead.

Moving forward, OMAP CPUidle drivers needs to be moved to drivers/idle/*
once the PRM/CM code gets moved to drivers. This patch also reduces one
dependency with platform code for idle driver movement.

Acked-by: Nishanth Menon <nm at ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
[khilman at linaro.org: minor changelog edits]
Signed-off-by: Kevin Hilman <khilman at linaro.org>
---
 arch/arm/mach-omap2/common.h              |  5 -----
 arch/arm/mach-omap2/cpuidle44xx.c         |  3 ++-
 arch/arm/mach-omap2/omap-mpuss-lowpower.c | 14 --------------
 3 files changed, 2 insertions(+), 20 deletions(-)

diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 40f4a03..f5c9983 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -249,7 +249,6 @@ extern int omap4_enter_lowpower(unsigned int cpu, unsigned int power_state);
 extern int omap4_finish_suspend(unsigned long cpu_state);
 extern void omap4_cpu_resume(void);
 extern int omap4_hotplug_cpu(unsigned int cpu, unsigned int power_state);
-extern u32 omap4_mpuss_read_prev_context_state(void);
 #else
 static inline int omap4_enter_lowpower(unsigned int cpu,
 					unsigned int power_state)
@@ -277,10 +276,6 @@ static inline int omap4_finish_suspend(unsigned long cpu_state)
 static inline void omap4_cpu_resume(void)
 {}
 
-static inline u32 omap4_mpuss_read_prev_context_state(void)
-{
-	return 0;
-}
 #endif
 
 struct omap_sdrc_params;
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c b/arch/arm/mach-omap2/cpuidle44xx.c
index 354517a..3cad103 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -149,7 +149,8 @@ static int omap4_enter_idle_coupled(struct cpuidle_device *dev,
 	 * Call idle CPU cluster PM exit notifier chain
 	 * to restore GIC and wakeupgen context.
 	 */
-	if (omap4_mpuss_read_prev_context_state())
+	if ((cx->mpu_state == PWRDM_POWER_RET) &&
+		(cx->mpu_logic_state == PWRDM_POWER_OFF))
 		cpu_cluster_pm_exit();
 
 	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &cpu_id);
diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index 8bcb64b..e80327b 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -139,20 +139,6 @@ static inline void cpu_clear_prev_logic_pwrst(unsigned int cpu_id)
 	}
 }
 
-/**
- * omap4_mpuss_read_prev_context_state:
- * Function returns the MPUSS previous context state
- */
-u32 omap4_mpuss_read_prev_context_state(void)
-{
-	u32 reg;
-
-	reg = omap4_prminst_read_inst_reg(OMAP4430_PRM_PARTITION,
-		OMAP4430_PRM_MPU_INST, OMAP4_RM_MPU_MPU_CONTEXT_OFFSET);
-	reg &= OMAP4430_LOSTCONTEXT_DFF_MASK;
-	return reg;
-}
-
 /*
  * Store the CPU cluster state for L2X0 low power operations.
  */
-- 
1.8.2



From tony at atomide.com  Wed Apr  3 17:40:37 2013
From: tony at atomide.com (Tony Lindgren)
Date: Wed, 3 Apr 2013 14:40:37 -0700
Subject: [GIT PULL] ARM: OMAP2+: GPMC updates
In-Reply-To: <515B0D92.6070503@ti.com>
References: <515B0D92.6070503@ti.com>
Message-ID: <20130403214036.GD10155@atomide.com>

* Jon Hunter <jon-hunter at ti.com> [130402 10:00]:
> The following changes since commit dca3a783400a18e2bf4503b1d4a85c4d0ca1a7e4:
> 
>   Merge commit '31d9adca82ce65e5c99d045b5fd917c702b6fce3' into tmp (2013-04-01 14:33:50 -0500)
> 
> are available in the git repository at:
> 
> 
>   git://github.com/jonhunter/linux.git omap-gpmc-for-v3.10
> 
> for you to fetch changes up to c67bd6e7cad2160c3bbfa2ac2bd954f918301c23:
> 
>   ARM: OMAP2+: Add GPMC DT support for Ethernet child nodes (2013-04-01 14:53:50 -0500)
> 
> ----------------------------------------------------------------
> Adds GPMC DT support for NOR flash and Ethernet and includes
> various GPMC cleans-up and fixes.
> 
> This series is dependent on commit 7185684 (ARM: OMAP: use
> consistent error checking) from RMK's clean-up branch and commit
> 31d9adc (ARM: OMAP2+: Fix broken gpmc support).

Looks good except it adds a new warning:

arch/arm/mach-omap2/gpmc.c: In function ?gpmc_read_timings_dt?:
arch/arm/mach-omap2/gpmc.c:1324: warning: ?p? may be used uninitialized in this function

Can you please take a look?

Regards,

Tony

> ----------------------------------------------------------------
> Ezequiel Garcia (8):
>       ARM: omap2: gpmc: Mark local scoped functions static
>       ARM: omap2: gpmc: Remove unused gpmc_round_ns_to_ticks() function
>       ARM: omap2: gpmc: Fix gpmc_cs_reserved() return value
>       ARM: omap2: gpmc-nand: Print something useful on CS request failure
>       ARM: omap2: gpmc-onenand: Print something useful on CS request failure
>       ARM: omap2: gpmc-onenand: Replace pr_err() with dev_err()
>       ARM: omap2: gpmc-onenand: Replace printk KERN_ERR with dev_warn()
>       ARM: omap2: gpmc: Remove redundant chip select out of range check
> 
> Javier Martinez Canillas (3):
>       ARM: OMAP2+: return -ENODEV if GPMC child device creation fails
>       ARM: OMAP2+: rename gpmc_probe_nor_child() to gpmc_probe_generic_child()
>       ARM: OMAP2+: Add GPMC DT support for Ethernet child nodes
> 
> Jon Hunter (17):
>       ARM: OMAP2+: Simplify code configuring ONENAND devices
>       ARM: OMAP2+: Add variable to store number of GPMC waitpins
>       ARM: OMAP2+: Add structure for storing GPMC settings
>       ARM: OMAP2+: Add function for configuring GPMC settings
>       ARM: OMAP2+: Convert ONENAND to use gpmc_cs_program_settings()
>       ARM: OMAP2+: Convert NAND to use gpmc_cs_program_settings()
>       ARM: OMAP2+: Convert SMC91x to use gpmc_cs_program_settings()
>       ARM: OMAP2+: Convert TUSB to use gpmc_cs_program_settings()
>       ARM: OMAP2+: Don't configure of chip-select options in gpmc_cs_configure()
>       ARM: OMAP2+: Add function to read GPMC settings from device-tree
>       ARM: OMAP2+: Add additional GPMC timing parameters
>       ARM: OMAP2+: Add device-tree support for NOR flash
>       ARM: OMAP2+: Convert NAND to retrieve GPMC settings from DT
>       ARM: OMAP2+: Convert ONENAND to retrieve GPMC settings from DT
>       ARM: OMAP2+: Detect incorrectly aligned GPMC base address
>       ARM: OMAP2+: Remove unnecesssary GPMC definitions and variable
>       ARM: OMAP2+: Allow GPMC probe to complete even if CS mapping fails
> 
> Mark Jackson (1):
>       ARM: OMAP: Clear GPMC bits when applying new setting.
> 
>  Documentation/devicetree/bindings/bus/ti-gpmc.txt  |  103 +++-
>  Documentation/devicetree/bindings/mtd/gpmc-nor.txt |   98 ++++
>  .../devicetree/bindings/mtd/gpmc-onenand.txt       |    3 +
>  Documentation/devicetree/bindings/net/gpmc-eth.txt |   97 ++++
>  arch/arm/mach-omap2/gpmc-nand.c                    |   42 +-
>  arch/arm/mach-omap2/gpmc-onenand.c                 |  118 ++---
>  arch/arm/mach-omap2/gpmc-smc91x.c                  |   30 +-
>  arch/arm/mach-omap2/gpmc.c                         |  544 ++++++++++++++------
>  arch/arm/mach-omap2/gpmc.h                         |   43 +-
>  arch/arm/mach-omap2/usb-tusb6010.c                 |   62 ++-
>  10 files changed, 831 insertions(+), 309 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/mtd/gpmc-nor.txt
>  create mode 100644 Documentation/devicetree/bindings/net/gpmc-eth.txt


From khilman at linaro.org  Wed Apr  3 17:43:41 2013
From: khilman at linaro.org (Kevin Hilman)
Date: Wed, 03 Apr 2013 14:43:41 -0700
Subject: [PATCH 8/9] ARM: omap3: cpuidle: enable time keeping
In-Reply-To: <515C95BF.6030103@linaro.org> (Daniel Lezcano's message of "Wed, 
 03 Apr 2013 22:49:03 +0200")
References: <1364991322-20585-1-git-send-email-daniel.lezcano@linaro.org>
 <1364991322-20585-8-git-send-email-daniel.lezcano@linaro.org>
 <87zjxfzetw.fsf@linaro.org> <515C95BF.6030103@linaro.org>
Message-ID: <87txnnp9wy.fsf@linaro.org>

Daniel Lezcano <daniel.lezcano at linaro.org> writes:

> On 04/03/2013 07:47 PM, Kevin Hilman wrote:
>> Daniel Lezcano <daniel.lezcano at linaro.org> writes:
>> 
>>> The TIME_VALID flag is specified for the different states but
>>> the time residency computation is not done, no tk flag, no time
>>> computation in the idle function.
>>>
>>> Set the en_core_tk_irqen flag to activate it.
>>>
>>> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
>>> Acked-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
>> 
>> Acked-by: Kevin Hilman <khilman at linaro.org>
>> 
>> Also, is this a regression fix that also needs to hit v3.9?
>
> Yes, I think so.

OK.

I've got a handful of other OMAP CPUidle fixes queued for v3.10[1] so
I'll add this one to the queue and Cc: stable.

Thanks,

Kevin

[1]
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git for_3.10/cleanup/cpuidle


From linus.walleij at linaro.org  Wed Apr  3 17:45:10 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Wed, 3 Apr 2013 23:45:10 +0200
Subject: [PATCH 4/9] ARM: ux500: Move Snowball's thermal DT node into
 existing PRCMU one
In-Reply-To: <CACRpkda08Joe9aXRgYDUs622GELL+O1vZSnzzCBa++m1zZZi=g@mail.gmail.com>
References: <1364908916-29803-1-git-send-email-lee.jones@linaro.org>
 <1364908916-29803-4-git-send-email-lee.jones@linaro.org>
 <CACRpkdar=xD34yaMP2gOfUPkpxOhDymS6zTedKOEW7j2DNHusA@mail.gmail.com>
 <CACRpkda08Joe9aXRgYDUs622GELL+O1vZSnzzCBa++m1zZZi=g@mail.gmail.com>
Message-ID: <CACRpkdYtxRbejCvEBRxSFd0FnvndLLQiJaWp1QJ3QBcfPw9msg@mail.gmail.com>

On Wed, Apr 3, 2013 at 11:36 PM, Linus Walleij <linus.walleij at linaro.org> wrote:
> On Wed, Apr 3, 2013 at 10:38 PM, Linus Walleij <linus.walleij at linaro.org> wrote:
>> On Tue, Apr 2, 2013 at 3:21 PM, Lee Jones <lee.jones at linaro.org> wrote:
>>
>>> When the thermal DT node was inserted a new PRCMU node was created;
>>> however, one already exists in the Snowball DTS file. Here we
>>> amalgamate the two into a single consolidated node.
>>>
>>> Signed-off-by: Lee Jones <lee.jones at linaro.org>
>>
>> Patch applied.
>
> After applying this I get this:
>
>   DTC     arch/arm/boot/dts/snowball.dtb
> Error: /home/elinwal/linux-stericsson/arch/arm/boot/dts/snowball.dts:351.3-352.1
> syntax error
> FATAL ERROR: Unable to parse input tree
> make[3]: *** [arch/arm/boot/dts/snowball.dtb] Error 1
> make[2]: *** [dtbs] Error 2
> make[1]: *** [sub-make] Error 2
> make[1]: Leaving directory `/home/elinwal/linux-stericsson'
> make: *** [build-dtbs] Error 2
>
> Does not appear prior to applying patch.
>
> It doesn't quiet apply cleanly either, what is this based on?

Hm looking closer at this there are even more problems in DT-land.

The fixes that were sent to Torvalds for -rc5, i.e. this stuff:
http://marc.info/?l=linux-arm-kernel&m=136441825019562&w=2

Will conflict with
stuff that is already in ARM SoC, i.e. this stuff:
http://marc.info/?l=linux-arm-kernel&m=136217923611845&w=2

That in turn both conflicts with this new stuff.

I will hold off any DT patches until I have some kind of baseline
in ARM SoC that has e.g. merged in the RC fixes with the other
device tree stuff and got it to compile.

I'll just not take any more DT stuff except for fixes
until after the v3.10 merge window to cool things down. I think there
will be enough trouble as it is. There is no point in keepin a finger
on the fast-forward button all the time, this can surely wait for
v3.11 unless someone suggests something else.

Yours,
Linus Walleij


From mturquette at linaro.org  Wed Apr  3 17:45:45 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Wed, 03 Apr 2013 14:45:45 -0700
Subject: [PATCH v2 0/6] clk: sunxi: gates support
In-Reply-To: <1364419243-18446-1-git-send-email-emilio@elopez.com.ar>
References: <1363962042-29536-1-git-send-email-emilio@elopez.com.ar>
 <1364419243-18446-1-git-send-email-emilio@elopez.com.ar>
Message-ID: <20130403214545.3383.95826@quantum>

Quoting Emilio L?pez (2013-03-27 14:20:36)
> Hi,
> 
> This patchset adds support for the main sunxi gates; namely, those found 
> on AXI, AHB, APB0 and APB1 clocks. The series depends on Maxime's UART 
> rework and on the basic sunxi clock driver by me.
> 
> Patches 1 and 2 implement the actual gate support, and patch 3 switches 
> the UARTs to use the correct gates now that they are available.
> 
> Patch 4 and 5 add clock support to our pinctrl driver, as we need to 
> keep the pio clock running for gpio to work.
> 
> Patch 6 drops the ignore flags; now that we have actual clock users that 
> will keep the important clocks running.
> 
> Patch 7 is an unrelated oneliner to remove an unnecesary kmalloc call.
> 
> The main changes from v1 are renamed compatible strings and a clarification
> on the documentation, see each individual patch for more details.
> 

Hi Emilio,

Which tree(s) did you want these patches to go through?

Regards,
Mike

> Thanks,
> 
> Emilio
> 
> Emilio L?pez (7):
>   clk: sunxi: Add support for AXI, AHB, APB0 and APB1 gates
>   arm: sunxi: Add clock definitions for AXI, AHB, APB0, APB1 gates
>   arm: sunxi: use the right clock phandles for UARTs
>   pinctrl: sunxi: add clock support
>   arm: sunxi: Add clock to pinctrl node
>   clk: sunxi: drop CLK_IGNORE_UNUSED
>   clk: sunxi: drop an unnecesary kmalloc


From sylvester.nawrocki at gmail.com  Wed Apr  3 17:46:31 2013
From: sylvester.nawrocki at gmail.com (Sylwester Nawrocki)
Date: Wed, 03 Apr 2013 23:46:31 +0200
Subject: [PATCH v5 1/6] drivers: phy: add generic PHY framework
In-Reply-To: <1364993634-6378-2-git-send-email-kishon@ti.com>
References: <1364993634-6378-1-git-send-email-kishon@ti.com>
 <1364993634-6378-2-git-send-email-kishon@ti.com>
Message-ID: <515CA337.1010504@gmail.com>

On 04/03/2013 02:53 PM, Kishon Vijay Abraham I wrote:
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/phy-bindings.txt
> @@ -0,0 +1,67 @@
> +This document explains only the dt data binding. For general information about

s/dt data/device tree ?

> +PHY subsystem refer Documentation/phy.txt

s/refer/refer to ?

> +
> +PHY device node
> +===============
> +
> +Required Properties:
> +#phy-cells:	Number of cells in a PHY specifier;  The meaning of all those
> +		cells is defined by the binding for the phy node. The PHY
> +		provider can use the values in cells to find the appropriate
> +		PHY.
> +
> +For example:
> +
> +phys: phy {
> +    compatible = "xxx";
> +    reg =<...>;
> +    .
> +    .
> +    #phy-cells =<1>;
> +    .
> +    .
> +};
> +
> +That node describes an IP block that implements 2 different PHYs. In order to
> +differentiate between these 2 PHYs, an additonal specifier should be given
> +while trying to get a reference to it.
> +
> +PHY user node
> +=============
> +
> +Required Properties:
> +phys : the phandle for the PHY device (used by the PHY subsystem)
> +
> +Optional properties:
> +phy-names : the names of the PHY corresponding to the PHYs present in the
> +	    *phys* phandle
> +
> +Example 1:
> +usb1: usb_otg_ss at xxx {
> +    compatible = "xxx";
> +    reg =<xxx>;
> +    .
> +    .
> +    phys =<&usb2_phy>,<&usb3_phy>;
> +    phy-names = "usb2phy", "usb3phy";
> +    .
> +    .
> +};
> +
> +This node represents a controller that uses two PHYs one for usb2 and one for

s/PHYs/PHYs,  ?

> +usb3.
> +
> +Example 2:
> +usb2: usb_otg_ss at xxx {
> +    compatible = "xxx";
> +    reg =<xxx>;
> +    .
> +    .
> +    phys =<&phys 1>;
> +    .
> +    .
> +};
> +
> +This node represents a controller that uses one of the PHYs which is defined
> +previously. Note that the phy handle has an additional specifier "1" to

I find it a bit difficult to parse. Perhaps

"This node represents a controller that uses one of the PHYs of the PHY 
provider
device defined previously. ..."

or something similar ?

> +differentiate between the two PHYs.

s/the two/the two available  ?

> diff --git a/Documentation/phy.txt b/Documentation/phy.txt
> new file mode 100644
> index 0000000..7785ec0
> --- /dev/null
> +++ b/Documentation/phy.txt
> @@ -0,0 +1,113 @@
> +			    PHY SUBSYSTEM
> +		  Kishon Vijay Abraham I<kishon at ti.com>
> +
> +This document explains the Generic PHY Framework along with the APIs provided,
> +and how-to-use.
> +
> +1. Introduction
> +
> +*PHY* is the abbreviation for physical layer. It is used to connect a device
> +to the physical medium e.g., the USB controller has a PHY to provide functions

Shouldn't it be "...medium, e.g. the USB..." ?

> +such as serialization, de-serialization, encoding, decoding and is responsible
> +for obtaining the required data transmission rate. Note that some USB
> +controller has PHY functionality embedded into it and others use an external

"controllers have PHY functionality embedded into them" ?

> +PHY. Other peripherals that uses a PHY include Wireless LAN, Ethernet,

s/uses/use ?

> +SATA etc.
> +
> +The intention of creating this framework is to bring the phy drivers spread
> +all over the Linux kernel to drivers/phy to increase code re-use and to
> +increase code maintainability.
> +
> +This framework will be of use only to devices that uses external PHY (PHY

s/uses/use ?

> +functionality is not embedded within the controller).
> +
> +2. Creating the PHY
> +
> +The PHY driver should create the PHY in order for other peripheral controllers
> +to make use of it. The PHY framework provides 2 APIs to create the PHY.
> +
> +struct phy *phy_create(struct device *dev, const char *label,
> +	struct device_node *of_node, int type, struct phy_ops *ops,
> +	void *priv);
> +struct phy *devm_phy_create(struct device *dev, const char *label,
> +	struct device_node *of_node, int type, struct phy_ops *ops,
> +	void *priv);
> +
> +The PHY drivers can use one of the above 2 APIs to create the PHY by passing
> +the device pointer, label, device node, type, phy ops and a driver data.
> +phy_ops is a set of function pointers for performing PHY operations such as
> +init, exit, suspend, resume, power_on and power_off.
> +
> +3. Binding the PHY to the controller
> +
> +The framework provides an API for binding the controller to the PHY in the
> +case of non dt boot.
> +
> +struct phy_bind *phy_bind(const char *dev_name, int index,
> +				const char *phy_dev_name);
> +
> +The API fills the phy_bind structure with the dev_name (device name of the
> +controller), index and phy_dev_name (device name of the PHY). This will
> +be used when the controller requests this phy. This API should be used by
> +platform specific initialization code (board file).
> +
> +In the case of dt boot, the binding information should be added in the dt
> +data of the controller.

s/in the dt data of/in the device tree node of ?

> +4. Getting a reference to the PHY
> +
> +Before the controller can make use of the PHY, it has to get a reference to
> +it. This framework provides 6 APIs to get a reference to the PHY.
> +
> +struct phy *phy_get(struct device *dev, int index);
> +struct phy *devm_phy_get(struct device *dev, int index);
> +struct phy *of_phy_get(struct device *dev, const char *phandle, int index);
> +struct phy *devm_of_phy_get(struct device *dev, const char *phandle, int index);

Why do we need separate functions for dt and non-dt ? Couldn't it be handled
internally by the framework ? So the PHY users can use same calls for dt
and non-dt, like in case of e.g. the regulators API ?

Also signatures of some functions are different now:

extern struct phy *phy_get(struct device *dev, int index);
extern struct phy *devm_phy_get(struct device *dev, int index);
extern struct phy *of_phy_get(struct device *dev, int index);
extern struct phy *devm_of_phy_get(struct device *dev, int index);

BTW, I think "extern" could be dropped, does it have any significance in
function declarations in header files ?

> +struct phy *of_phy_get_byname(struct device *dev, const char *string);
> +struct phy *devm_of_phy_get_byname(struct device *dev, const char *string);
> +
> +phy_get and devm_phy_get can be used to get the PHY in non-dt boot. This API
> +uses the binding information added using the phy_bind API to find and return
> +the appropriate PHY. The only difference between the two APIs is that
> +devm_phy_get associates the device with the PHY using devres on successful PHY
> +get. On driver detach, release function is invoked on the the devres data and

s/the the/the

> +devres data is freed.
> +
> +of_phy_get and devm_of_phy_get can be used to get the PHY in dt boot. These
> +APIs take the phandle and index to get a reference to the PHY. The only
> +difference between the two APIs is that devm_of_phy_get associates the device
> +with the PHY using devres on successful phy get. On driver detach, release
> +function is invoked on the devres data and it is freed.
> +
> +of_phy_get_byname and devm_of_phy_get_byname can also be used to get the PHY
> +in dt boot. It is same as the above API except that the user has to pass the
> +phy name as filled in "phy-names" phandle in dt data and the framework will

s/phandle/property ?

> +find the index and get the PHY.
> +
> +5. Releasing a reference to the PHY
> +
> +When the controller no longer needs the PHY, it has to release the reference
> +to the PHY it has obtained using the APIs mentioned in the above section. The
> +PHY framework provides 2 APIS to release a reference to the PHY.

s/APIS/APIs ?

> +
> +void phy_put(struct phy *phy);
> +void devm_phy_put(struct device *dev, struct phy *phy);
> +
> +Both these APIs are used to release a reference to the PHY and devm_phy_put
> +destroys the devres associated with this PHY.
> +
> +6. Destroying the PHY
> +
> +When the driver that created the PHY is unloaded, it should destroy the PHY it
> +created using one of the following 2 APIs.
> +
> +void phy_destroy(struct phy *phy);
> +void devm_phy_destroy(struct device *dev, struct phy *phy);
> +
> +Both these APIs destroys the PHY and devm_phy_destroy destroys the devres

s/APIs destroys/APIs destroy ?

> +associated with this PHY.
> +
> +7. DeviceTree Binding
> +
> +The documentation for PHY dt binding can be found @
> +Documentation/devicetree/bindings/phy/phy-bindings.txt

> --- /dev/null
> +++ b/drivers/phy/phy-core.c
> @@ -0,0 +1,616 @@

> +static struct phy *of_phy_lookup(struct device_node *node)
> +{
> +	struct phy *phy;
> +	struct device *dev;
> +	struct class_dev_iter iter;
> +
> +	class_dev_iter_init(&iter, phy_class, NULL, NULL);

There is currently nothing preventing a call to this function before
phy_class is initialized. It happened during my tests, and the nice
stack dump showed that it was the PHY user attempting to get the PHY
before the framework got initialized. So either phy_core_init should
be a subsys_initcall or we need a better protection against phy_class
being NULL or ERR_PTR in more places.

> +	while ((dev = class_dev_iter_next(&iter))) {
> +		phy = container_of(dev, struct phy, dev);
> +		if (node != phy->of_node)
> +			continue;
> +
> +		class_dev_iter_exit(&iter);
> +		return phy;
> +	}
> +
> +	class_dev_iter_exit(&iter);
> +	return ERR_PTR(-EPROBE_DEFER);
> +}

> +/**
> + * of_phy_get() - lookup and obtain a reference to a phy by phandle
> + * @dev: device that requests this phy
> + * @index: the index of the phy
> + *
> + * Returns the phy associated with the given phandle value,
> + * after getting a refcount to it or -ENODEV if there is no such phy or
> + * -EPROBE_DEFER if there is a phandle to the phy, but the device is
> + * not yet loaded.
> + */
> +struct phy *of_phy_get(struct device *dev, int index)
> +{
> +	int ret;
> +	struct phy *phy = NULL;
> +	struct phy_bind *phy_map = NULL;
> +	struct of_phandle_args args;
> +	struct device_node *node;
> +
> +	if (!dev->of_node) {
> +		dev_dbg(dev, "device does not have a device node entry\n");
> +		return ERR_PTR(-EINVAL);
> +	}
> +
> +	ret = of_parse_phandle_with_args(dev->of_node, "phys", "#phy-cells",
> +		index,&args);
> +	if (ret) {
> +		dev_dbg(dev, "failed to get phy in %s node\n",
> +			dev->of_node->full_name);
> +		return ERR_PTR(-ENODEV);
> +	}
> +
> +	phy = of_phy_lookup(args.np);
> +	if (IS_ERR(phy) || !try_module_get(phy->ops->owner)) {
> +		phy = ERR_PTR(-EPROBE_DEFER);
> +		goto err0;
> +	}
> +
> +	phy = phy->ops->of_xlate(phy,&args);
> +	if (IS_ERR(phy))
> +		goto err1;
> +
> +	phy_map = phy_bind(dev_name(dev), index, dev_name(&phy->dev));
> +	if (!IS_ERR(phy_map)) {
> +		phy_map->phy = phy;
> +		phy_map->auto_bind = true;

Shouldn't it be done with the phy_bind_mutex held ? I guess an unlocked
version of the phy_bind functions is needed, so it can be used internally.

> +	}
> +
> +	get_device(&phy->dev);
> +
> +err1:
> +	module_put(phy->ops->owner);
> +
> +err0:
> +	of_node_put(node);
> +
> +	return phy;
> +}
> +EXPORT_SYMBOL_GPL(of_phy_get);

> +/**
> + * phy_create() - create a new phy
> + * @dev: device that is creating the new phy
> + * @label: label given to phy
> + * @of_node: device node of the phy
> + * @type: specifies the phy type
> + * @ops: function pointers for performing phy operations
> + * @priv: private data from phy driver
> + *
> + * Called to create a phy using phy framework.
> + */
> +struct phy *phy_create(struct device *dev, const char *label,
> +	struct device_node *of_node, int type, struct phy_ops *ops,
> +	void *priv)
> +{
> +	int ret;
> +	struct phy *phy;
> +	struct phy_bind *phy_bind;
> +	const char *devname = NULL;
> +
> +	if (!dev) {
> +		dev_err(dev, "no device provided for PHY\n");
> +		ret = -EINVAL;
> +		goto err0;
> +	}
> +
> +	if (!ops || !ops->of_xlate || !priv) {
> +		dev_err(dev, "no PHY ops/PHY data provided\n");
> +		ret = -EINVAL;
> +		goto err0;
> +	}
> +
> +	if (!phy_class)
> +		phy_core_init();
> +
> +	phy = kzalloc(sizeof(*phy), GFP_KERNEL);
> +	if (!phy) {
> +		ret = -ENOMEM;
> +		goto err0;
> +	}
> +
> +	devname = dev_name(dev);

OK, a sort of serious issue here is that you can't call phy_create()
multiple times for same PHY provider device.

device_add() further will fail as sysfs won't let you create multiple
objects with same name. So I would assume we need to add a new argument
to phy_create() or rename @type to e.g. @phy_id, which could be
concatenated with dev_name(dev) to create a unique name of the phy
device.

And how is the PHY provider supposed to identify a PHY in its common PHY
ops, now when the struct phy port field is removed ? I have temporarily
(ab)used the type field in order to select proper registers within the
phy ops.

> +	device_initialize(&phy->dev);
> +
> +	phy->dev.class = phy_class;
> +	phy->dev.parent = dev;
> +	phy->label = label;

What about duplicating the string here ? That would make the API a bit
more convenient and the callers wouldn't be required to keep all the
labels around.

> +	phy->of_node = of_node;
> +	phy->type = type;
> +	phy->ops = ops;
> +
> +	dev_set_drvdata(&phy->dev, priv);
> +
> +	ret = dev_set_name(&phy->dev, "%s", devname);
> +	if (ret)
> +		goto err1;
> +
> +	mutex_lock(&phy_bind_mutex);
> +	list_for_each_entry(phy_bind,&phy_bind_list, list)
> +		if (!(strcmp(phy_bind->phy_dev_name, devname)))
> +			phy_bind->phy = phy;
> +	mutex_unlock(&phy_bind_mutex);
> +
> +	ret = device_add(&phy->dev);
> +	if (ret)
> +		goto err2;
> +
> +	return phy;
> +
> +err2:
> +	phy_bind->phy = NULL;
> +
> +err1:
> +	put_device(&phy->dev);
> +	kfree(phy);
> +
> +err0:
> +	return ERR_PTR(ret);
> +}
> +EXPORT_SYMBOL_GPL(phy_create);

> +/**
> + * devm_phy_create() - create a new phy
> + * @dev: device that is creating the new phy
> + * @dev: device that is creating the new phy

Duplicated line.

> + * @label: label given to phy
> + * @of_node: device node of the phy
> + * @type: specifies the phy type
> + * @ops: function pointers for performing phy operations
> + * @priv: private data from phy driver
> + *
> + * Creates a new PHY device adding it to the PHY class.
> + * While at that, it also associates the device with the phy using devres.
> + * On driver detach, release function is invoked on the devres data,
> + * then, devres data is freed.
> + */

> +/**
> + * phy_bind() - bind the phy and the controller that uses the phy
> + * @dev_name: the device name of the device that will bind to the phy
> + * @index: index to specify the port number
> + * @phy_dev_name: the device name of the phy
> + *
> + * Fills the phy_bind structure with the dev_name and phy_dev_name. This will
> + * be used when the phy driver registers the phy and when the controller
> + * requests this phy.
> + *
> + * To be used by platform specific initialization code.
> + */
> +struct phy_bind *phy_bind(const char *dev_name, int index,
> +				const char *phy_dev_name)
> +{
> +	struct phy_bind *phy_bind;
> +
> +	mutex_lock(&phy_bind_mutex);
> +	list_for_each_entry(phy_bind,&phy_bind_list, list) {
> +		if (!strcmp(phy_bind->dev_name, dev_name)&&  phy_bind->index ==
> +			index) {
> +			phy_bind->phy_dev_name = phy_dev_name;
> +			goto ret0;
> +		}
> +	}
> +
> +	phy_bind = kzalloc(sizeof(*phy_bind), GFP_KERNEL);
> +	if (!phy_bind) {
> +		phy_bind = ERR_PTR(-ENOMEM);
> +		goto ret0;
> +	}
> +
> +	phy_bind->dev_name = dev_name;
> +	phy_bind->phy_dev_name = phy_dev_name;
> +	phy_bind->index = index;
> +	phy_bind->auto_bind = false;
> +
> +	list_add_tail(&phy_bind->list,&phy_bind_list);
> +
> +ret0:
> +	mutex_unlock(&phy_bind_mutex);
> +	return phy_bind;
> +}
> +EXPORT_SYMBOL_GPL(phy_bind);

> +static ssize_t phy_bind_show(struct device *dev,
> +			     struct device_attribute *attr, char *buf)
> +{
> +	struct phy_bind *phy_bind;
> +	struct phy *phy;
> +	char *p = buf;
> +	int len;
> +
> +	phy = container_of(dev, struct phy, dev);
> +

Shouldn't this iteration also be protected with the phy_bind_mutex ?

> +	list_for_each_entry(phy_bind,&phy_bind_list, list)
> +		if (phy_bind->phy == phy)
> +			p += sprintf(p, "%s %d %s\n", phy_bind->dev_name,
> +				phy_bind->index, phy_bind->phy_dev_name);
> +	len = (p - buf);
> +
> +	return len;
> +}

> +static int phy_core_init(void)
> +{
> +	if (phy_class)
> +		return 0;
> +
> +	phy_class = class_create(THIS_MODULE, "phy");
> +	if (IS_ERR(phy_class)) {
> +		pr_err("failed to create phy class -->  %ld\n",
> +			PTR_ERR(phy_class));
> +		return PTR_ERR(phy_class);
> +	}
> +
> +	phy_class->dev_release = phy_release;
> +	phy_class->dev_attrs = phy_dev_attrs;
> +
> +	return 0;
> +}
> +module_init(phy_core_init);

Having this framework initialized before the PHY provider and consumer
drivers could save some unnecessary probe deferrals. I was wondering,
what is really an advantage of having it as module_init(), rather than
subsys_initcall() ?

> +static void __exit phy_core_exit(void)
> +{
> +	class_destroy(phy_class);
> +}
> +module_exit(phy_core_exit);
> +
> +MODULE_DESCRIPTION("Generic PHY Framework");
> +MODULE_AUTHOR("Kishon Vijay Abraham I<kishon at ti.com>");
> +MODULE_LICENSE("GPL v2");
> diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
> new file mode 100644
> index 0000000..97a48bd
> --- /dev/null
> +++ b/include/linux/phy/phy.h
> @@ -0,0 +1,228 @@
> +/*
> + * phy.h -- generic phy header file
> + *

> +/**
> + * struct phy - represent the phy device
> + * @dev: phy device
> + * @label: label given to phy
> + * @type: specifies the phy type
> + * @of_node: device node of the phy
> + * @ops: function pointers for performing phy operations
> + */
> +struct phy {
> +	struct device		dev;
> +	const char		*label;
> +	int			type;
> +	struct device_node	*of_node;
> +	struct phy_ops		*ops;

Something in this structure that would identify a PHY when a PHY provider
supports multiple PHYs is probably needed.

> +};
> +
> +/**
> + * struct phy_bind - represent the binding for the phy
> + * @dev_name: the device name of the device that will bind to the phy
> + * @phy_dev_name: the device name of the phy
> + * @index: used if a single controller uses multiple phys
> + * @auto_bind: tells if the binding is done explicitly from board file or not
> + * @phy: reference to the phy
> + * @list: to maintain a linked list of the binding information
> + */
> +struct phy_bind {
> +	const char	*dev_name;
> +	const char	*phy_dev_name;
> +	int		index;
> +	int		auto_bind:1;
> +	struct phy	*phy;
> +	struct list_head list;
> +};
> +
> +static inline int phy_poweron(struct phy *phy)

phy_power_on ? Just a humble suggestion...

> +{
> +	if (phy->ops->power_on)
> +		return phy->ops->power_on(phy);
> +
> +	return -EINVAL;
> +}
> +
> +static inline int phy_poweroff(struct phy *phy)

and phy_power_off ? :-)

> +{
> +	if (phy->ops->power_off)
> +		return phy->ops->power_off(phy);
> +
> +	return -EINVAL;
> +}
> +#endif /* __DRIVERS_PHY_H */

Thanks,
Sylwester


From mturquette at linaro.org  Wed Apr  3 17:48:15 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Wed, 03 Apr 2013 14:48:15 -0700
Subject: [PATCH v2 1/7] clk: sunxi: Add support for AXI, AHB,
 APB0 and APB1 gates
In-Reply-To: <1364419243-18446-2-git-send-email-emilio@elopez.com.ar>
References: <1363962042-29536-1-git-send-email-emilio@elopez.com.ar>
 <1364419243-18446-1-git-send-email-emilio@elopez.com.ar>
 <1364419243-18446-2-git-send-email-emilio@elopez.com.ar>
Message-ID: <20130403214815.3383.60153@quantum>

Quoting Emilio L?pez (2013-03-27 14:20:37)
> diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
> index d528a24..244de90 100644
> --- a/drivers/clk/sunxi/clk-sunxi.c
> +++ b/drivers/clk/sunxi/clk-sunxi.c
> @@ -302,6 +302,82 @@ static void __init sunxi_divider_clk_setup(struct device_node *node,
>  }
>  
>  
> +

A lot of white space between these functions.

> +/**
> + * sunxi_gates_clk_setup() - Setup function for leaf gates on clocks
> + */
> +
> +#define SUNXI_GATES_MAX_SIZE   64
> +
> +struct gates_data {
> +       DECLARE_BITMAP(mask, SUNXI_GATES_MAX_SIZE);
> +};
> +
> +static const __initconst struct gates_data axi_gates_data = {
> +       .mask = {1},
> +};
> +
> +static const __initconst struct gates_data ahb_gates_data = {
> +       .mask = {0x7F77FFF, 0x14FB3F},
> +};
> +
> +static const __initconst struct gates_data apb0_gates_data = {
> +       .mask = {0x4EF},
> +};
> +
> +static const __initconst struct gates_data apb1_gates_data = {
> +       .mask = {0xFF00F7},
> +};
> +
> +static void __init sunxi_gates_clk_setup(struct device_node *node,
> +                                        struct gates_data *data)
> +{
> +       struct clk_onecell_data *clk_data;
> +       const char *clk_parent;
> +       const char *clk_name;
> +       void *reg;
> +       int qty;
> +       int i = 0;
> +       int j = 0;
> +       int ignore;
> +
> +       reg = of_iomap(node, 0);
> +
> +       clk_parent = of_clk_get_parent_name(node, 0);
> +
> +       /* Worst-case size approximation and memory allocation */
> +       qty = find_last_bit(data->mask, SUNXI_GATES_MAX_SIZE);
> +       clk_data = kmalloc(sizeof(struct clk_onecell_data), GFP_KERNEL);
> +       if (!clk_data)
> +               return;
> +       clk_data->clks = kzalloc((qty+1) * sizeof(struct clk *), GFP_KERNEL);
> +       if (!clk_data->clks) {
> +               kfree(clk_data);
> +               return;
> +       }
> +
> +       for_each_set_bit(i, data->mask, SUNXI_GATES_MAX_SIZE) {
> +               of_property_read_string_index(node, "clock-output-names",
> +                                             j, &clk_name);
> +
> +               /* No driver claims this clock, but it should remain gated */

Should the comment read, "ungated" instead of "gated"?

> +               ignore = !strcmp("ahb_sdram", clk_name) ? CLK_IGNORE_UNUSED : 0;
> +
> +               clk_data->clks[i] = clk_register_gate(NULL, clk_name,
> +                                                     clk_parent, ignore,
> +                                                     reg + 4 * (i/32), i % 32,
> +                                                     0, &clk_lock);
> +               WARN_ON(IS_ERR(clk_data->clks[i]));
> +
> +               j++;
> +       }
> +
> +       /* Adjust to the real max */
> +       clk_data->clk_num = i;
> +
> +       of_clk_add_provider(node, of_clk_src_onecell_get, clk_data);
> +}
> +
>  /* Matches for of_clk_init */
>  static const __initconst struct of_device_id clk_match[] = {
>         {.compatible = "fixed-clock", .data = of_fixed_clk_setup,},
> @@ -331,6 +407,15 @@ static const __initconst struct of_device_id clk_mux_match[] = {
>         {}
>  };
>  
> +/* Matches for gate clocks */
> +static const __initconst struct of_device_id clk_gates_match[] = {
> +       {.compatible = "allwinner,sun4i-axi-gates-clk", .data = &axi_gates_data,},
> +       {.compatible = "allwinner,sun4i-ahb-gates-clk", .data = &ahb_gates_data,},
> +       {.compatible = "allwinner,sun4i-apb0-gates-clk", .data = &apb0_gates_data,},
> +       {.compatible = "allwinner,sun4i-apb1-gates-clk", .data = &apb1_gates_data,},
> +       {}
> +};
> +
>  static void __init of_sunxi_table_clock_setup(const struct of_device_id *clk_match,
>                                               void *function)
>  {
> @@ -359,4 +444,7 @@ void __init sunxi_init_clocks(void)
>  
>         /* Register mux clocks */
>         of_sunxi_table_clock_setup(clk_mux_match, sunxi_mux_clk_setup);
> +
> +       /* Register gate clocks */
> +       of_sunxi_table_clock_setup(clk_gates_match, sunxi_gates_clk_setup);

I'm still a device tree noob, so this may be a dumb question.  Can the
above be converted to of_clk_init?

Regards,
Mike

>  }
> -- 
> 1.8.2


From mturquette at linaro.org  Wed Apr  3 17:48:46 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Wed, 03 Apr 2013 14:48:46 -0700
Subject: [PATCH v2 6/7] clk: sunxi: drop CLK_IGNORE_UNUSED
In-Reply-To: <1364419243-18446-7-git-send-email-emilio@elopez.com.ar>
References: <1363962042-29536-1-git-send-email-emilio@elopez.com.ar>
 <1364419243-18446-1-git-send-email-emilio@elopez.com.ar>
 <1364419243-18446-7-git-send-email-emilio@elopez.com.ar>
Message-ID: <20130403214846.3383.2417@quantum>

Quoting Emilio L?pez (2013-03-27 14:20:42)
> This flag was in place to prevent important clocks from getting gated
> while they had no users. Now that the UART driver supports clocks
> properly, we can drop this.
> 
> Signed-off-by: Emilio L?pez <emilio at elopez.com.ar>

This change looks good to me.

Regards,
Mike

> ---
> 
> Changes from v1:
>   - no changes
> 
>  drivers/clk/sunxi/clk-sunxi.c | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
> index 244de90..daa51ab 100644
> --- a/drivers/clk/sunxi/clk-sunxi.c
> +++ b/drivers/clk/sunxi/clk-sunxi.c
> @@ -41,8 +41,8 @@ static void __init sunxi_osc_clk_setup(struct device_node *node)
>  
>         parent = of_clk_get_parent_name(node, 0);
>  
> -       clk = clk_register_gate(NULL, clk_name, parent, CLK_IGNORE_UNUSED,
> -                               reg, SUNXI_OSC24M_GATE, 0, &clk_lock);
> +       clk = clk_register_gate(NULL, clk_name, parent, 0, reg,
> +                               SUNXI_OSC24M_GATE, 0, &clk_lock);
>  
>         if (clk) {
>                 of_clk_add_provider(node, of_clk_src_simple_get, clk);
> @@ -198,8 +198,8 @@ static void __init sunxi_factors_clk_setup(struct device_node *node,
>  
>         parent = of_clk_get_parent_name(node, 0);
>  
> -       clk = clk_register_factors(NULL, clk_name, parent, CLK_IGNORE_UNUSED,
> -                                  reg, data->table, data->getter, &clk_lock);
> +       clk = clk_register_factors(NULL, clk_name, parent, 0, reg,
> +                                  data->table, data->getter, &clk_lock);
>  
>         if (clk) {
>                 of_clk_add_provider(node, of_clk_src_simple_get, clk);
> -- 
> 1.8.2


From mturquette at linaro.org  Wed Apr  3 17:49:23 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Wed, 03 Apr 2013 14:49:23 -0700
Subject: [PATCH v2 7/7] clk: sunxi: drop an unnecesary kmalloc
In-Reply-To: <1364419243-18446-8-git-send-email-emilio@elopez.com.ar>
References: <1363962042-29536-1-git-send-email-emilio@elopez.com.ar>
 <1364419243-18446-1-git-send-email-emilio@elopez.com.ar>
 <1364419243-18446-8-git-send-email-emilio@elopez.com.ar>
Message-ID: <20130403214923.3383.70847@quantum>

Quoting Emilio L?pez (2013-03-27 14:20:43)
> clk_register will copy this information, so we can just use a normal
> array and do one less dynamic allocation.
> 
> Signed-off-by: Emilio L?pez <emilio at elopez.com.ar>

Looks good to me.

Regards,
Mike

> ---
> 
> Changes from v1:
>   - this patch was not present on v1
> 
>  drivers/clk/sunxi/clk-sunxi.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
> index daa51ab..0bb0eb4 100644
> --- a/drivers/clk/sunxi/clk-sunxi.c
> +++ b/drivers/clk/sunxi/clk-sunxi.c
> @@ -232,7 +232,7 @@ static void __init sunxi_mux_clk_setup(struct device_node *node,
>  {
>         struct clk *clk;
>         const char *clk_name = node->name;
> -       const char **parents = kmalloc(sizeof(char *) * 5, GFP_KERNEL);
> +       const char *parents[5];
>         void *reg;
>         int i = 0;
>  
> -- 
> 1.8.2


From festevam at gmail.com  Wed Apr  3 18:01:12 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Wed,  3 Apr 2013 19:01:12 -0300
Subject: [PATCH 1/3] ARM: dts: imx28-evk: Use the standard gpio reset binding
Message-ID: <1365026474-3446-1-git-send-email-festevam@gmail.com>

From: Fabio Estevam <fabio.estevam at freescale.com>

Instead of using a custom binding for turning on a GPIO that activates the 
panel, use the standard one.

Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
---
 Documentation/devicetree/bindings/fb/mxsfb.txt |    5 +----
 arch/arm/boot/dts/imx23-evk.dts                |    8 +++++++-
 arch/arm/boot/dts/imx28-evk.dts                |    8 +++++++-
 3 files changed, 15 insertions(+), 6 deletions(-)

diff --git a/Documentation/devicetree/bindings/fb/mxsfb.txt b/Documentation/devicetree/bindings/fb/mxsfb.txt
index 7ba3b76..b15230c 100644
--- a/Documentation/devicetree/bindings/fb/mxsfb.txt
+++ b/Documentation/devicetree/bindings/fb/mxsfb.txt
@@ -8,9 +8,7 @@ Required properties:
 - display : phandle to display node (see below for details)
 
 Optional properties:
-- panel-enable-gpios : Should specify the gpio for panel enable
-
-* display node
+- display node
 
 Required properties:
 - bits-per-pixel : <16> for RGB565, <32> for RGB888/666.
@@ -25,7 +23,6 @@ lcdif at 80030000 {
 	compatible = "fsl,imx28-lcdif";
 	reg = <0x80030000 2000>;
 	interrupts = <38 86>;
-	panel-enable-gpios = <&gpio3 30 0>;
 
 	display: display {
 		bits-per-pixel = <32>;
diff --git a/arch/arm/boot/dts/imx23-evk.dts b/arch/arm/boot/dts/imx23-evk.dts
index 7880e17..28f9766 100644
--- a/arch/arm/boot/dts/imx23-evk.dts
+++ b/arch/arm/boot/dts/imx23-evk.dts
@@ -59,7 +59,7 @@
 			lcdif at 80030000 {
 				pinctrl-names = "default";
 				pinctrl-0 = <&lcdif_24bit_pins_a>;
-				panel-enable-gpios = <&gpio1 18 0>;
+				resets = <&gpio_reset 0>;
 				display = <&display>;
 				status = "okay";
 
@@ -89,6 +89,12 @@
 			};
 		};
 
+		gpio_reset: gpio-reset {
+			compatible = "gpio-reset";
+			reset-gpios = <&gpio1 18 1>;
+			#reset-cells = <1>;
+		};
+
 		apbx at 80040000 {
 			pwm: pwm at 80064000 {
 				pinctrl-names = "default";
diff --git a/arch/arm/boot/dts/imx28-evk.dts b/arch/arm/boot/dts/imx28-evk.dts
index 2d4ea3b..e373dd6 100644
--- a/arch/arm/boot/dts/imx28-evk.dts
+++ b/arch/arm/boot/dts/imx28-evk.dts
@@ -123,7 +123,7 @@
 				pinctrl-names = "default";
 				pinctrl-0 = <&lcdif_24bit_pins_a
 					     &lcdif_pins_evk>;
-				panel-enable-gpios = <&gpio3 30 0>;
+				resets = <&gpio_reset 0>;
 				display = <&display>;
 				status = "okay";
 
@@ -152,6 +152,12 @@
 				};
 			};
 
+			gpio_reset: gpio-reset {
+				compatible = "gpio-reset";
+				reset-gpios = <&gpio3 30 1>;
+				#reset-cells = <1>;
+			};
+
 			can0: can at 80032000 {
 				pinctrl-names = "default";
 				pinctrl-0 = <&can0_pins_a>;
-- 
1.7.9.5



From mturquette at linaro.org  Wed Apr  3 18:01:18 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Wed, 03 Apr 2013 15:01:18 -0700
Subject: [PATCH 00/21] Various fixes and extensions to Exynos4 clock
 driver
In-Reply-To: <22e101ce2f7c$5b6a0cd0$123e2670$%kim@samsung.com>
References: <1364382178-25248-1-git-send-email-t.figa@samsung.com>
 <CAJuYYwQap4pZ6qTgBPGeSWbMFm-ZhqLfv7wBMVYjK1v0YHr_kQ@mail.gmail.com>
 <1496108.NDegb7PXrt@flatron>
 <22e101ce2f7c$5b6a0cd0$123e2670$%kim@samsung.com>
Message-ID: <20130403220118.3383.10734@quantum>

Quoting Kukjin Kim (2013-04-02 01:30:39)
> Tomasz Figa wrote:
> > 
> > On Saturday 30 of March 2013 15:33:00 Thomas Abraham wrote:
> > > Hi Tomasz,
> > >
> > > On 27 March 2013 16:32, Tomasz Figa <t.figa at samsung.com> wrote:
> > > > This series is a collection of various fixes and extensions to Exynos4
> > > > clock driver, which improve coverage of clocks present on Exynos4 SoCs
> > > > and fix problems discovered during our internal work and testing.
> > >
> > > Nice series. Thanks for the improvements and fixes. Looking at the
> > > second patch in this series, I crossed checked again with the
> > > Exynos4412 user manual that I have. Your modifications are different
> > > from what the manual has listed. I suspect, you have a newer copy of
> > > the manual.
> > 
> > Right. I have checked revisions 0.0, 0.1 and 1.1 of the manual and indeed
> > there are differences in clock layout between 0.1 and 1.1. My patches are
> > based on revision 1.1.
> > 
> Correct...hmm...
> 
> > > For this series:
> > > Reviewed-by: Thomas Abraham <thomas.abraham at linaro.org>
> > 
> Yes, looks good to me but would be better if I could get Mike's ack on this
> series.
> 

Acked-by: Mike Turquette <mturquette at linaro.org>

> Thanks.
> 
> - Kukjin


From festevam at gmail.com  Wed Apr  3 18:01:14 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Wed,  3 Apr 2013 19:01:14 -0300
Subject: [PATCH 3/3] ARM: mxs_defconfig: Enable CONFIG_RESET_GPIO
In-Reply-To: <1365026474-3446-1-git-send-email-festevam@gmail.com>
References: <1365026474-3446-1-git-send-email-festevam@gmail.com>
Message-ID: <1365026474-3446-3-git-send-email-festevam@gmail.com>

From: Fabio Estevam <fabio.estevam at freescale.com>

CONFIG_RESET_GPIO is required in order to enable a GPIO to turn on a LCD, for
example.

Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
---
 arch/arm/configs/mxs_defconfig |    2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/configs/mxs_defconfig b/arch/arm/configs/mxs_defconfig
index b5f6e55..d2c4105 100644
--- a/arch/arm/configs/mxs_defconfig
+++ b/arch/arm/configs/mxs_defconfig
@@ -147,6 +147,8 @@ CONFIG_COMMON_CLK_DEBUG=y
 CONFIG_IIO=y
 CONFIG_PWM=y
 CONFIG_PWM_MXS=y
+CONFIG_RESET_CONTROLLER=y
+CONFIG_RESET_GPIO=y
 CONFIG_EXT2_FS=y
 CONFIG_EXT2_FS_XATTR=y
 CONFIG_EXT3_FS=y
-- 
1.7.9.5



From festevam at gmail.com  Wed Apr  3 18:01:13 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Wed,  3 Apr 2013 19:01:13 -0300
Subject: [PATCH 2/3] video: mxsfb: Remove custom method for retrieving GPIO
In-Reply-To: <1365026474-3446-1-git-send-email-festevam@gmail.com>
References: <1365026474-3446-1-git-send-email-festevam@gmail.com>
Message-ID: <1365026474-3446-2-git-send-email-festevam@gmail.com>

From: Fabio Estevam <fabio.estevam at freescale.com>

mxs device tree files should use the standard gpio reset binding, so no need to
have this code inside the driver anymore.

Cc: Florian Tobias Schandinat <FlorianSchandinat at gmx.de>
Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
---
 drivers/video/mxsfb.c |   19 -------------------
 1 file changed, 19 deletions(-)

diff --git a/drivers/video/mxsfb.c b/drivers/video/mxsfb.c
index eac7c1a..acfb871 100644
--- a/drivers/video/mxsfb.c
+++ b/drivers/video/mxsfb.c
@@ -42,7 +42,6 @@
 #include <linux/module.h>
 #include <linux/kernel.h>
 #include <linux/of_device.h>
-#include <linux/of_gpio.h>
 #include <video/of_display_timing.h>
 #include <linux/platform_device.h>
 #include <linux/clk.h>
@@ -859,8 +858,6 @@ static int mxsfb_probe(struct platform_device *pdev)
 	struct fb_info *fb_info;
 	struct fb_modelist *modelist;
 	struct pinctrl *pinctrl;
-	int panel_enable;
-	enum of_gpio_flags flags;
 	int ret;
 
 	if (of_id)
@@ -904,22 +901,6 @@ static int mxsfb_probe(struct platform_device *pdev)
 		goto fb_release;
 	}
 
-	panel_enable = of_get_named_gpio_flags(pdev->dev.of_node,
-					       "panel-enable-gpios", 0, &flags);
-	if (gpio_is_valid(panel_enable)) {
-		unsigned long f = GPIOF_OUT_INIT_HIGH;
-		if (flags == OF_GPIO_ACTIVE_LOW)
-			f = GPIOF_OUT_INIT_LOW;
-		ret = devm_gpio_request_one(&pdev->dev, panel_enable,
-					    f, "panel-enable");
-		if (ret) {
-			dev_err(&pdev->dev,
-				"failed to request gpio %d: %d\n",
-				panel_enable, ret);
-			goto fb_release;
-		}
-	}
-
 	fb_info->pseudo_palette = devm_kzalloc(&pdev->dev, sizeof(u32) * 16,
 					       GFP_KERNEL);
 	if (!fb_info->pseudo_palette) {
-- 
1.7.9.5



From emilio at elopez.com.ar  Wed Apr  3 18:13:42 2013
From: emilio at elopez.com.ar (=?UTF-8?B?RW1pbGlvIEzDs3Bleg==?=)
Date: Wed, 03 Apr 2013 19:13:42 -0300
Subject: [PATCH v2 0/6] clk: sunxi: gates support
In-Reply-To: <20130403214545.3383.95826@quantum>
References: <1363962042-29536-1-git-send-email-emilio@elopez.com.ar>
 <1364419243-18446-1-git-send-email-emilio@elopez.com.ar>
 <20130403214545.3383.95826@quantum>
Message-ID: <515CA996.6040300@elopez.com.ar>

Hi Mike,

El 03/04/13 18:45, Mike Turquette escribi?:
> Quoting Emilio L?pez (2013-03-27 14:20:36)
>> Hi,
>>
>> This patchset adds support for the main sunxi gates; namely, those found 
>> on AXI, AHB, APB0 and APB1 clocks. The series depends on Maxime's UART 
>> rework and on the basic sunxi clock driver by me.
>>
>> Patches 1 and 2 implement the actual gate support, and patch 3 switches 
>> the UARTs to use the correct gates now that they are available.
>>
>> Patch 4 and 5 add clock support to our pinctrl driver, as we need to 
>> keep the pio clock running for gpio to work.
>>
>> Patch 6 drops the ignore flags; now that we have actual clock users that 
>> will keep the important clocks running.
>>
>> Patch 7 is an unrelated oneliner to remove an unnecesary kmalloc call.
>>
>> The main changes from v1 are renamed compatible strings and a clarification
>> on the documentation, see each individual patch for more details.
>>
> 
> Hi Emilio,
> 
> Which tree(s) did you want these patches to go through?

The rest of the clk driver is on your tree, so I think 1, 6 and 7 should
go through there too, unless Maxime has any objection.

Thanks,

Emilio


From swarren at wwwdotorg.org  Wed Apr  3 18:48:06 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Wed, 03 Apr 2013 16:48:06 -0600
Subject: [PATCH] clocksource: tegra: enable arch_timer
In-Reply-To: <515CA060.7030100@gmail.com>
References: <1364988750-25058-1-git-send-email-josephl@nvidia.com>
 <515C2E8F.1030802@gmail.com> <515C7363.4040404@wwwdotorg.org>
 <515CA060.7030100@gmail.com>
Message-ID: <515CB1A6.6090308@wwwdotorg.org>

On 04/03/2013 03:34 PM, Rob Herring wrote:
> On 04/03/2013 01:22 PM, Stephen Warren wrote:
>> On 04/03/2013 07:28 AM, Rob Herring wrote:
>>> On 04/03/2013 06:32 AM, Joseph Lo wrote:
>>>> Architected timer is the local timer for Cortex-A15. Adding the support
>>>> for Tegra.
>>>>
>>>> Cc: John Stultz <john.stultz at linaro.org>
>>>> Cc: Thomas Gleixner <tglx at linutronix.de>
>>>> Signed-off-by: Joseph Lo <josephl at nvidia.com>
>>>
>>> My patch series to add CLOCKSOURCE_OF_DECLARE support to arch timer and
>>> sched_clock enhancements will make this unnecessary:
>>>
>>> http://www.spinics.net/lists/arm-kernel/msg234597.html
>>>
>>> Testing would be appreciated.
>>
>> Joseph (or Rob), what's the benefit of this change; what works with it
>> and/or what breaks without it?
> 
> I assume you mean Joseph's change.

Yes.

> Well, it enables local timers on A15.
> But mine will too for Tegra if you have the arch timer in the dtb.

Well, I meant what benefit would I see from enabling them, rather than
using the Tegra-specific timers as I believe is currently happening.

>> Rob, if I did apply this change, and you also apply that series of
>> yours, what is the result: compile-time breakage, run-time breakage,
>> just some redundant code that needs to be removed again?
> 
> Compile-time breakage as the functions called here are being removed.

OK, I definitely won't apply Joseph's patch then.

Aside from that, I took the git branch you mentioned in the patch you
linked to above, merged it into my dev tree, updated my bootloader to
actually initialize the TSC correctly, and I see the following during
boot, so I guess that's enough for:

Tested-by: Stephen Warren <swarren at nvidia.com>

on your patches.

> [    0.000000] sched_clock: 32 bits at 1000kHz, resolution 1000ns, wraps every 4294967ms
> [    0.000000] Architected local timer running at 12.00MHz (virt).
> [    0.000000] Switching to timer-based delay loop
> [  117.431229] Calibrating delay loop (skipped), value calculated using timer frequency.. 24.00 BogoMIPS (lpj=120000)
> [  117.987221] Switching to clocksource arch_sys_counter


From khilman at linaro.org  Wed Apr  3 18:52:58 2013
From: khilman at linaro.org (Kevin Hilman)
Date: Wed, 03 Apr 2013 15:52:58 -0700
Subject: [PATCH v2 00/18] ARM: OMAP5: PM: Add MPUSS suspend and CPUidle
 support
In-Reply-To: <1364205910-32392-1-git-send-email-santosh.shilimkar@ti.com>
 (Santosh Shilimkar's message of "Mon, 25 Mar 2013 15:34:52 +0530")
References: <1364205910-32392-1-git-send-email-santosh.shilimkar@ti.com>
Message-ID: <87hajnp6ph.fsf@linaro.org>

Hi Santosh,

Santosh Shilimkar <santosh.shilimkar at ti.com> writes:

> Here is the refreshed version(v2) of the OMAP5 PM suspport which was posted
> earlier (March 1st 2013). Patch-set incorporates comments from Nishant
> Menon (Thanks for review NM) and his acked-by tags. I would like to get this
> queued for 3.10 merge window if you are ok with the series.

I did a review of this series with several comments on the individual
patches.  

I've already queued most of the CPUidle fixes/cleanups in my
for_3.10/cleanup/cpuidle branch and will get that to Tony soon.  For the
rest, I suggest probably breaking it up into cleanup/consolidation stuff
and then OMAP5 support.  The latter will depend on all the OMAP5
data/headers but the cleanup/consolidation stuff could be merged sooner
(but probably a bit late for v3.10 now.)

Kevin


From cdall at cs.columbia.edu  Wed Apr  3 19:13:44 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Wed, 3 Apr 2013 16:13:44 -0700
Subject: [PATCH 1/7] ARM: KVM: simplify HYP mapping population
In-Reply-To: <1364909115-3810-2-git-send-email-marc.zyngier@arm.com>
References: <1364909115-3810-1-git-send-email-marc.zyngier@arm.com>
 <1364909115-3810-2-git-send-email-marc.zyngier@arm.com>
Message-ID: <20130403231344.GA29227@gmail.com>

On Tue, Apr 02, 2013 at 02:25:09PM +0100, Marc Zyngier wrote:
> The way we populate HYP mappings is a bit convoluted, to say the least.
> Passing a pointer around to keep track of the current PFN is quite
> odd, and we end-up having two different PTE accessors for no good
> reason.
> 
> Simplify the whole thing by unifying the two PTE accessors, passing
> a pgprot_t around, and moving the various validity checks to the
> upper layers.
> 
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> ---
>  arch/arm/kvm/mmu.c | 100 ++++++++++++++++++++++-------------------------------
>  1 file changed, 41 insertions(+), 59 deletions(-)
> 
> diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
> index 2f12e40..24811d1 100644
> --- a/arch/arm/kvm/mmu.c
> +++ b/arch/arm/kvm/mmu.c
> @@ -125,54 +125,34 @@ void free_hyp_pmds(void)
>  }
>  
>  static void create_hyp_pte_mappings(pmd_t *pmd, unsigned long start,
> -				    unsigned long end)
> +				    unsigned long end, unsigned long pfn,
> +				    pgprot_t prot)
>  {
>  	pte_t *pte;
>  	unsigned long addr;
> -	struct page *page;
>  
> -	for (addr = start & PAGE_MASK; addr < end; addr += PAGE_SIZE) {
> -		unsigned long hyp_addr = KERN_TO_HYP(addr);
> -
> -		pte = pte_offset_kernel(pmd, hyp_addr);
> -		BUG_ON(!virt_addr_valid(addr));
> -		page = virt_to_page(addr);
> -		kvm_set_pte(pte, mk_pte(page, PAGE_HYP));
> -	}
> -}
> -
> -static void create_hyp_io_pte_mappings(pmd_t *pmd, unsigned long start,
> -				       unsigned long end,
> -				       unsigned long *pfn_base)
> -{
> -	pte_t *pte;
> -	unsigned long addr;
> -
> -	for (addr = start & PAGE_MASK; addr < end; addr += PAGE_SIZE) {
> -		unsigned long hyp_addr = KERN_TO_HYP(addr);
> -
> -		pte = pte_offset_kernel(pmd, hyp_addr);
> -		BUG_ON(pfn_valid(*pfn_base));
> -		kvm_set_pte(pte, pfn_pte(*pfn_base, PAGE_HYP_DEVICE));
> -		(*pfn_base)++;
> +	for (addr = start; addr < end; addr += PAGE_SIZE) {
> +		pte = pte_offset_kernel(pmd, addr);
> +		kvm_set_pte(pte, pfn_pte(pfn, prot));
> +		pfn++;
>  	}
>  }
>  
>  static int create_hyp_pmd_mappings(pud_t *pud, unsigned long start,
> -				   unsigned long end, unsigned long *pfn_base)
> +				   unsigned long end, unsigned long pfn,
> +				   pgprot_t prot)
>  {
>  	pmd_t *pmd;
>  	pte_t *pte;
>  	unsigned long addr, next;
>  
>  	for (addr = start; addr < end; addr = next) {
> -		unsigned long hyp_addr = KERN_TO_HYP(addr);
> -		pmd = pmd_offset(pud, hyp_addr);
> +		pmd = pmd_offset(pud, addr);
>  
>  		BUG_ON(pmd_sect(*pmd));
>  
>  		if (pmd_none(*pmd)) {
> -			pte = pte_alloc_one_kernel(NULL, hyp_addr);
> +			pte = pte_alloc_one_kernel(NULL, addr);
>  			if (!pte) {
>  				kvm_err("Cannot allocate Hyp pte\n");
>  				return -ENOMEM;
> @@ -182,25 +162,17 @@ static int create_hyp_pmd_mappings(pud_t *pud, unsigned long start,
>  
>  		next = pmd_addr_end(addr, end);
>  
> -		/*
> -		 * If pfn_base is NULL, we map kernel pages into HYP with the
> -		 * virtual address. Otherwise, this is considered an I/O
> -		 * mapping and we map the physical region starting at
> -		 * *pfn_base to [start, end[.
> -		 */
> -		if (!pfn_base)
> -			create_hyp_pte_mappings(pmd, addr, next);
> -		else
> -			create_hyp_io_pte_mappings(pmd, addr, next, pfn_base);
> +		create_hyp_pte_mappings(pmd, addr, next, pfn, prot);
> +		pfn += (next - addr) >> PAGE_SHIFT;

so this scheme always assumes a physically contiguous memory reason,
and I wasn't sure if we ever wanted to support mapping vmalloc'ed
regions into Hyp mode, which is why I wrote the code the way it was
(which goes to your "for no good reason" comment above).

I'm fine with assuming that this only works for contiguous regions, but
I think it deserves a line in the comments on the exported functions
(the non-IO one anyway).

>  	}
>  
>  	return 0;
>  }
>  
> -static int __create_hyp_mappings(void *from, void *to, unsigned long *pfn_base)
> +static int __create_hyp_mappings(pgd_t *pgdp,
> +				 unsigned long start, unsigned long end,
> +				 unsigned long pfn, pgprot_t prot)
>  {
> -	unsigned long start = (unsigned long)from;
> -	unsigned long end = (unsigned long)to;
>  	pgd_t *pgd;
>  	pud_t *pud;
>  	pmd_t *pmd;
> @@ -209,21 +181,14 @@ static int __create_hyp_mappings(void *from, void *to, unsigned long *pfn_base)
>  
>  	if (start >= end)
>  		return -EINVAL;
> -	/* Check for a valid kernel memory mapping */
> -	if (!pfn_base && (!virt_addr_valid(from) || !virt_addr_valid(to - 1)))
> -		return -EINVAL;
> -	/* Check for a valid kernel IO mapping */
> -	if (pfn_base && (!is_vmalloc_addr(from) || !is_vmalloc_addr(to - 1)))
> -		return -EINVAL;
>  
>  	mutex_lock(&kvm_hyp_pgd_mutex);
> -	for (addr = start; addr < end; addr = next) {
> -		unsigned long hyp_addr = KERN_TO_HYP(addr);
> -		pgd = hyp_pgd + pgd_index(hyp_addr);
> -		pud = pud_offset(pgd, hyp_addr);
> +	for (addr = start & PAGE_MASK; addr < end; addr = next) {
> +		pgd = pgdp + pgd_index(addr);
> +		pud = pud_offset(pgd, addr);
>  
>  		if (pud_none_or_clear_bad(pud)) {
> -			pmd = pmd_alloc_one(NULL, hyp_addr);
> +			pmd = pmd_alloc_one(NULL, addr);
>  			if (!pmd) {
>  				kvm_err("Cannot allocate Hyp pmd\n");
>  				err = -ENOMEM;
> @@ -233,9 +198,10 @@ static int __create_hyp_mappings(void *from, void *to, unsigned long *pfn_base)
>  		}
>  
>  		next = pgd_addr_end(addr, end);
> -		err = create_hyp_pmd_mappings(pud, addr, next, pfn_base);
> +		err = create_hyp_pmd_mappings(pud, addr, next, pfn, prot);
>  		if (err)
>  			goto out;
> +		pfn += (next - addr) >> PAGE_SHIFT;

nit: consider passing a pointer to pfn instead?  Not sure if it's nicer.

>  	}
>  out:
>  	mutex_unlock(&kvm_hyp_pgd_mutex);
> @@ -255,7 +221,16 @@ out:
>   */
>  int create_hyp_mappings(void *from, void *to)
>  {
> -	return __create_hyp_mappings(from, to, NULL);
> +	unsigned long phys_addr = virt_to_phys(from);
> +	unsigned long start = KERN_TO_HYP((unsigned long)from);
> +	unsigned long end = KERN_TO_HYP((unsigned long)to);
> +
> +	/* Check for a valid kernel memory mapping */
> +	if (!virt_addr_valid(from) || !virt_addr_valid(to - 1))
> +		return -EINVAL;
> +
> +	return __create_hyp_mappings(hyp_pgd, start, end,
> +				     __phys_to_pfn(phys_addr), PAGE_HYP);
>  }
>  
>  /**
> @@ -267,10 +242,17 @@ int create_hyp_mappings(void *from, void *to)
>   * The resulting HYP VA is the same as the kernel VA, modulo
>   * HYP_PAGE_OFFSET.
>   */
> -int create_hyp_io_mappings(void *from, void *to, phys_addr_t addr)
> +int create_hyp_io_mappings(void *from, void *to, phys_addr_t phys_addr)

nit: change the parameter documentation name as well.

>  {
> -	unsigned long pfn = __phys_to_pfn(addr);
> -	return __create_hyp_mappings(from, to, &pfn);
> +	unsigned long start = KERN_TO_HYP((unsigned long)from);
> +	unsigned long end = KERN_TO_HYP((unsigned long)to);
> +
> +	/* Check for a valid kernel IO mapping */
> +	if (!is_vmalloc_addr(from) || !is_vmalloc_addr(to - 1))
> +		return -EINVAL;
> +
> +	return __create_hyp_mappings(hyp_pgd, start, end,
> +				     __phys_to_pfn(phys_addr), PAGE_HYP_DEVICE);
>  }
>  
>  /**
> -- 
> 1.8.1.4
> 

If the contigous thing is not a concern, then I'm happy about the
simplification.

-Christoffer



From cdall at cs.columbia.edu  Wed Apr  3 19:14:09 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Wed, 3 Apr 2013 16:14:09 -0700
Subject: [PATCH 2/7] ARM: KVM: fix HYP mapping limitations around zero
In-Reply-To: <1364909115-3810-3-git-send-email-marc.zyngier@arm.com>
References: <1364909115-3810-1-git-send-email-marc.zyngier@arm.com>
 <1364909115-3810-3-git-send-email-marc.zyngier@arm.com>
Message-ID: <20130403231409.GB29227@gmail.com>

On Tue, Apr 02, 2013 at 02:25:10PM +0100, Marc Zyngier wrote:
> The current code for creating HYP mapping doesn't like to wrap
> around zero, which prevents from mapping anything into the last
> page of the virtual address space.
> 
> It doesn't take much effort to remove this limitation, making
> the code more consistent with the rest of the kernel in the process.

This is quite funny, the code used to behave like this, but
reviewers said that this was old fashioned mm-style code that was
unwanted and wrapping around zero should be avoided for all costs :)

In any case, I welcome the familiarity.

-Christoffer


From cdall at cs.columbia.edu  Wed Apr  3 19:14:24 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Wed, 3 Apr 2013 16:14:24 -0700
Subject: [PATCH 3/7] ARM: KVM: move to a KVM provided HYP idmap
In-Reply-To: <1364909115-3810-4-git-send-email-marc.zyngier@arm.com>
References: <1364909115-3810-1-git-send-email-marc.zyngier@arm.com>
 <1364909115-3810-4-git-send-email-marc.zyngier@arm.com>
Message-ID: <20130403231424.GC29227@gmail.com>

On Tue, Apr 02, 2013 at 02:25:11PM +0100, Marc Zyngier wrote:
> After the HYP page table rework, it is pretty easy to let the KVM
> code provide its own idmap, rather than expecting the kernel to
> provide it. It takes actually less code to do so.
> 
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> ---
>  arch/arm/include/asm/idmap.h   |  1 -
>  arch/arm/include/asm/kvm_mmu.h |  1 -
>  arch/arm/kvm/mmu.c             | 24 +++++++++++++++++++++++-
>  arch/arm/mm/idmap.c            | 31 +------------------------------
>  4 files changed, 24 insertions(+), 33 deletions(-)
> 
> diff --git a/arch/arm/include/asm/idmap.h b/arch/arm/include/asm/idmap.h
> index 1a66f907..bf863ed 100644
> --- a/arch/arm/include/asm/idmap.h
> +++ b/arch/arm/include/asm/idmap.h
> @@ -8,7 +8,6 @@
>  #define __idmap __section(.idmap.text) noinline notrace
>  
>  extern pgd_t *idmap_pgd;
> -extern pgd_t *hyp_pgd;
>  
>  void setup_mm_for_reboot(void);
>  
> diff --git a/arch/arm/include/asm/kvm_mmu.h b/arch/arm/include/asm/kvm_mmu.h
> index 970f3b5..3c71a1d 100644
> --- a/arch/arm/include/asm/kvm_mmu.h
> +++ b/arch/arm/include/asm/kvm_mmu.h
> @@ -21,7 +21,6 @@
>  
>  #include <asm/cacheflush.h>
>  #include <asm/pgalloc.h>
> -#include <asm/idmap.h>
>  
>  /*
>   * We directly use the kernel VA for the HYP, as we can directly share
> diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
> index eb4f8fa..7d23480 100644
> --- a/arch/arm/kvm/mmu.c
> +++ b/arch/arm/kvm/mmu.c
> @@ -32,6 +32,7 @@
>  
>  extern char  __hyp_idmap_text_start[], __hyp_idmap_text_end[];
>  
> +static pgd_t *hyp_pgd;
>  static DEFINE_MUTEX(kvm_hyp_pgd_mutex);
>  
>  static void kvm_tlb_flush_vmid_ipa(struct kvm *kvm, phys_addr_t ipa)
> @@ -715,12 +716,33 @@ phys_addr_t kvm_mmu_get_httbr(void)
>  
>  int kvm_mmu_init(void)
>  {
> +	unsigned long hyp_idmap_start = virt_to_phys(__hyp_idmap_text_start);
> +	unsigned long hyp_idmap_end = virt_to_phys(__hyp_idmap_text_end);
> +	int err;
> +
> +	hyp_pgd = kzalloc(PTRS_PER_PGD * sizeof(pgd_t), GFP_KERNEL);
>  	if (!hyp_pgd) {
>  		kvm_err("Hyp mode PGD not allocated\n");
> -		return -ENOMEM;
> +		err = -ENOMEM;
> +		goto out;
> +	}
> +
> +	/* Create the idmap in the boot page tables */
> +	err = 	__create_hyp_mappings(boot_hyp_pgd,
> +				      hyp_idmap_start, hyp_idmap_end,
> +				      __phys_to_pfn(hyp_idmap_start),
> +				      PAGE_HYP);
> +
> +	if (err) {
> +		kvm_err("Failed to idmap %lx-%lx\n",
> +			hyp_idmap_start, hyp_idmap_end);
> +		goto out;
>  	}
>  
>  	return 0;
> +out:
> +	kfree(hyp_pgd);
> +	return err;
>  }
>  
>  /**
> diff --git a/arch/arm/mm/idmap.c b/arch/arm/mm/idmap.c
> index 5ee505c..9c467d0 100644
> --- a/arch/arm/mm/idmap.c
> +++ b/arch/arm/mm/idmap.c
> @@ -83,37 +83,10 @@ static void identity_mapping_add(pgd_t *pgd, const char *text_start,
>  	} while (pgd++, addr = next, addr != end);
>  }
>  
> -#if defined(CONFIG_ARM_VIRT_EXT) && defined(CONFIG_ARM_LPAE)
> -pgd_t *hyp_pgd;
> -
> -extern char  __hyp_idmap_text_start[], __hyp_idmap_text_end[];
> -
> -static int __init init_static_idmap_hyp(void)
> -{
> -	hyp_pgd = kzalloc(PTRS_PER_PGD * sizeof(pgd_t), GFP_KERNEL);
> -	if (!hyp_pgd)
> -		return -ENOMEM;
> -
> -	pr_info("Setting up static HYP identity map for 0x%p - 0x%p\n",
> -		__hyp_idmap_text_start, __hyp_idmap_text_end);
> -	identity_mapping_add(hyp_pgd, __hyp_idmap_text_start,
> -			     __hyp_idmap_text_end, PMD_SECT_AP1);
> -
> -	return 0;
> -}
> -#else
> -static int __init init_static_idmap_hyp(void)
> -{
> -	return 0;
> -}
> -#endif
> -
>  extern char  __idmap_text_start[], __idmap_text_end[];
>  
>  static int __init init_static_idmap(void)
>  {
> -	int ret;
> -
>  	idmap_pgd = pgd_alloc(&init_mm);
>  	if (!idmap_pgd)
>  		return -ENOMEM;
> @@ -123,12 +96,10 @@ static int __init init_static_idmap(void)
>  	identity_mapping_add(idmap_pgd, __idmap_text_start,
>  			     __idmap_text_end, 0);
>  
> -	ret = init_static_idmap_hyp();
> -
>  	/* Flush L1 for the hardware to see this page table content */
>  	flush_cache_louis();
>  
> -	return ret;
> +	return 0;
>  }
>  early_initcall(init_static_idmap);
>  
> -- 
> 1.8.1.4
> 
> 

Looks good to me, Russell, if you ack this one, I can send this through
the KVM tree, otherwise let me know if you want it through your tree.

-Christoffer


From cdall at cs.columbia.edu  Wed Apr  3 19:15:04 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Wed, 3 Apr 2013 16:15:04 -0700
Subject: [PATCH 4/7] ARM: KVM: enforce page alignment for identity mapped
 code
In-Reply-To: <515BFDC7.9020401@arm.com>
References: <1364909115-3810-1-git-send-email-marc.zyngier@arm.com>
 <1364909115-3810-5-git-send-email-marc.zyngier@arm.com>
 <20130403095024.GC11040@mudshark.cambridge.arm.com>
 <515BFDC7.9020401@arm.com>
Message-ID: <20130403231504.GD29227@gmail.com>

On Wed, Apr 03, 2013 at 11:00:39AM +0100, Marc Zyngier wrote:
> On 03/04/13 10:50, Will Deacon wrote:
> > On Tue, Apr 02, 2013 at 02:25:12PM +0100, Marc Zyngier wrote:
> >> We're about to move to a init procedure where we rely on the
> >> fact that the init code fits in a single page. Make sure we
> >> align the idmap text on a page boundary, and that the code is
> >> not bigger than a single page.
> >>
> >> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> >> ---
> >>  arch/arm/kernel/vmlinux.lds.S | 2 +-
> >>  arch/arm/kvm/init.S           | 7 +++++++
> >>  2 files changed, 8 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
> >> index b571484..d9dd265 100644
> >> --- a/arch/arm/kernel/vmlinux.lds.S
> >> +++ b/arch/arm/kernel/vmlinux.lds.S
> >> @@ -20,7 +20,7 @@
> >>  	VMLINUX_SYMBOL(__idmap_text_start) = .;				\
> >>  	*(.idmap.text)							\
> >>  	VMLINUX_SYMBOL(__idmap_text_end) = .;				\
> >> -	ALIGN_FUNCTION();						\
> >> +	. = ALIGN(PAGE_SIZE);						\
> >>  	VMLINUX_SYMBOL(__hyp_idmap_text_start) = .;			\
> >>  	*(.hyp.idmap.text)						\
> >>  	VMLINUX_SYMBOL(__hyp_idmap_text_end) = .;
> >> diff --git a/arch/arm/kvm/init.S b/arch/arm/kvm/init.S
> >> index 9f37a79..35a463f 100644
> >> --- a/arch/arm/kvm/init.S
> >> +++ b/arch/arm/kvm/init.S
> >> @@ -111,4 +111,11 @@ __do_hyp_init:
> >>  	.globl __kvm_hyp_init_end
> >>  __kvm_hyp_init_end:
> >>  
> >> +	/*
> >> +	 * The above code *must* fit in a single page for the trampoline
> >> +	 * madness to work. Whoever decides to change it must make sure
> >> +	 * we map the right amount of memory for the trampoline to work.
> >> +	 * The line below ensures any breakage will get noticed.

This comment is a little funny. What's this about changing it? And why
madness? OK, it's a little mad.

I think the nice thing to explain here is why .org would complain - I
had to look in the AS reference to figure out that it will complain if
the location pointer is forwarded outside the section - if that is the
right reason?

> >> +	 */
> >> +	.org	__kvm_hyp_init + PAGE_SIZE
> >>  	.popsection
> > 
> > What effect does this have on the size of the kernel image? I'd expect the
> > idmap code to be pretty small, so aligning to a page might be overkill a lot
> > of the time.
> 
> So we're indeed wasting memory between the kernel and the HYP idmaps.
> The reason for this is to ensure that the init code is not spread across
> two pages, which would make the trampoline harder to allocate.
> 
> If there's a way to ensure that the init.S code will fit a single page,
> then we can remove this ALIGN(PAGE_SIZE).

Just allocate a temporary page and copy the bit of code into there?  It
should be easy enough to make sure it's location independent.  We can
even give that page back later if we want and re-do the trick when a CPU
gets hot-plugged if we want. No?

-Christoffer


From cdall at cs.columbia.edu  Wed Apr  3 19:15:23 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Wed, 3 Apr 2013 16:15:23 -0700
Subject: [PATCH 5/7] ARM: KVM: parametrize HYP page table freeing
In-Reply-To: <1364909115-3810-6-git-send-email-marc.zyngier@arm.com>
References: <1364909115-3810-1-git-send-email-marc.zyngier@arm.com>
 <1364909115-3810-6-git-send-email-marc.zyngier@arm.com>
Message-ID: <20130403231523.GE29227@gmail.com>

On Tue, Apr 02, 2013 at 02:25:13PM +0100, Marc Zyngier wrote:
> In order to prepare for having to deal with multiple HYP page tables,
> pass the PGD parameter to the function performing the freeing of the
> page tables.
> 
> Also move the freeing of the PGD itself there, and rename the
> free_hyp_pmds to free_hyp_pgds.
> 
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> ---
>  arch/arm/include/asm/kvm_mmu.h |  2 +-
>  arch/arm/kvm/arm.c             |  2 +-
>  arch/arm/kvm/mmu.c             | 30 +++++++++++++++++-------------
>  3 files changed, 19 insertions(+), 15 deletions(-)
> 
> diff --git a/arch/arm/include/asm/kvm_mmu.h b/arch/arm/include/asm/kvm_mmu.h
> index 3c71a1d..92eb20d 100644
> --- a/arch/arm/include/asm/kvm_mmu.h
> +++ b/arch/arm/include/asm/kvm_mmu.h
> @@ -32,7 +32,7 @@
>  
>  int create_hyp_mappings(void *from, void *to);
>  int create_hyp_io_mappings(void *from, void *to, phys_addr_t);
> -void free_hyp_pmds(void);
> +void free_hyp_pgds(void);
>  
>  int kvm_alloc_stage2_pgd(struct kvm *kvm);
>  void kvm_free_stage2_pgd(struct kvm *kvm);
> diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
> index 2ce90bb..6eba879 100644
> --- a/arch/arm/kvm/arm.c
> +++ b/arch/arm/kvm/arm.c
> @@ -936,7 +936,7 @@ static int init_hyp_mode(void)
>  out_free_context:
>  	free_percpu(kvm_host_cpu_state);
>  out_free_mappings:
> -	free_hyp_pmds();
> +	free_hyp_pgds();
>  out_free_stack_pages:
>  	for_each_possible_cpu(cpu)
>  		free_page(per_cpu(kvm_arm_hyp_stack_page, cpu));
> diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
> index 7d23480..85b3553 100644
> --- a/arch/arm/kvm/mmu.c
> +++ b/arch/arm/kvm/mmu.c
> @@ -86,42 +86,46 @@ static void free_ptes(pmd_t *pmd, unsigned long addr)
>  	}
>  }
>  
> -static void free_hyp_pgd_entry(unsigned long addr)
> +static void free_hyp_pgd_entry(pgd_t *pgdp, unsigned long addr)
>  {
>  	pgd_t *pgd;
>  	pud_t *pud;
>  	pmd_t *pmd;
> -	unsigned long hyp_addr = KERN_TO_HYP(addr);
>  
> -	pgd = hyp_pgd + pgd_index(hyp_addr);
> -	pud = pud_offset(pgd, hyp_addr);
> +	pgd = pgdp + pgd_index(addr);
> +	pud = pud_offset(pgd, addr);
>  
>  	if (pud_none(*pud))
>  		return;
>  	BUG_ON(pud_bad(*pud));
>  
> -	pmd = pmd_offset(pud, hyp_addr);
> +	pmd = pmd_offset(pud, addr);
>  	free_ptes(pmd, addr);
>  	pmd_free(NULL, pmd);
>  	pud_clear(pud);
>  }
>  
>  /**
> - * free_hyp_pmds - free a Hyp-mode level-2 tables and child level-3 tables
> + * free_hyp_pgds - free Hyp-mode page tables
>   *
> - * Assumes this is a page table used strictly in Hyp-mode and therefore contains
> + * Assumes hyp_pgd is a page table used strictly in Hyp-mode and therefore contains
>   * either mappings in the kernel memory area (above PAGE_OFFSET), or
>   * device mappings in the vmalloc range (from VMALLOC_START to VMALLOC_END).
>   */
> -void free_hyp_pmds(void)
> +void free_hyp_pgds(void)
>  {
>  	unsigned long addr;
>  
>  	mutex_lock(&kvm_hyp_pgd_mutex);
> -	for (addr = PAGE_OFFSET; virt_addr_valid(addr); addr += PGDIR_SIZE)
> -		free_hyp_pgd_entry(addr);
> -	for (addr = VMALLOC_START; is_vmalloc_addr((void*)addr); addr += PGDIR_SIZE)
> -		free_hyp_pgd_entry(addr);
> +
> +	if (hyp_pgd) {
> +		for (addr = PAGE_OFFSET; virt_addr_valid(addr); addr += PGDIR_SIZE)
> +			free_hyp_pgd_entry(hyp_pgd, KERN_TO_HYP(addr));
> +		for (addr = VMALLOC_START; is_vmalloc_addr((void*)addr); addr += PGDIR_SIZE)
> +			free_hyp_pgd_entry(hyp_pgd, KERN_TO_HYP(addr));
> +		kfree(hyp_pgd);
> +	}
> +
>  	mutex_unlock(&kvm_hyp_pgd_mutex);
>  }
>  
> @@ -741,7 +745,7 @@ int kvm_mmu_init(void)
>  
>  	return 0;
>  out:
> -	kfree(hyp_pgd);
> +	free_hyp_pgds();
>  	return err;
>  }
>  
> -- 
> 1.8.1.4
> 
> 

Acked-by: Christoffer Dall <cdall at cs.columbia.edu>


From cdall at cs.columbia.edu  Wed Apr  3 19:15:44 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Wed, 3 Apr 2013 16:15:44 -0700
Subject: [PATCH 6/7] ARM: KVM: switch to a dual-step HYP init code
In-Reply-To: <1364909115-3810-7-git-send-email-marc.zyngier@arm.com>
References: <1364909115-3810-1-git-send-email-marc.zyngier@arm.com>
 <1364909115-3810-7-git-send-email-marc.zyngier@arm.com>
Message-ID: <20130403231544.GF29227@gmail.com>

On Tue, Apr 02, 2013 at 02:25:14PM +0100, Marc Zyngier wrote:
> Our HYP init code suffers from two major design issues:
> - it cannot support CPU hotplug, as we tear down the idmap very early
> - it cannot perform a TLB invalidation when switching from init to
>   runtime mappings, as pages are manipulated from PL1 exclusively
> 
> The hotplug problem mandates that we keep two sets of page tables
> (boot and runtime). The TLB problem mandates that we're able to
> transition from one PGD to another while in HYP, invalidating the TLBs
> in the process.
> 
> To be able to do this, we need to share a page between the two page
> tables. A page that will have the same VA in both configurations. All we
> need is a VA that has the following properties:
> - This VA can't be used to represent a kernel mapping.
> - This VA will not conflict with the physical address of the kernel text
> 
> The vectors page seems to satisfy this requirement:
> - The kernel never maps anything else there
> - The kernel text being copied at the beginning of the physical memory,
>   it is unlikely to use the last 64kB (I doubt we'll ever support KVM
>   on a system with something like 4MB of RAM, but patches are very
>   welcome).
> 
> Let's call this VA the trampoline VA.
> 
> Now, we map our init page at 3 locations:
> - idmap in the boot pgd
> - trampoline VA in the boot pgd
> - trampoline VA in the runtime pgd
> 
> The init scenario is now the following:
> - We jump in HYP with four parameters: boot HYP pgd, runtime HYP pgd,
>   runtime stack, runtime vectors
> - Enable the MMU with the boot pgd
> - Jump to a target into the trampoline page (remember, this is the same
>   physical page!)
> - Now switch to the runtime pgd (same VA, and still the same physical
>   page!)
> - Invalidate TLBs
> - Set stack and vectors
> - Profit! (or eret, if you only care about the code).

So I'm going to do my usual commenting routine. Was it an idea to insert
this commit text (which I really liked by the way!) into init.S where
the current comment is a little lacking giving the massive complexity
this is turning into, madness?

> 
> Note that we keep the boot mapping permanently (it is not strictly an
> idmap anymore) to allow for CPU hotplug in later patches.
> 
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> ---
>  arch/arm/include/asm/kvm_host.h | 18 ++++++++---
>  arch/arm/include/asm/kvm_mmu.h  | 21 ++++++++++--
>  arch/arm/kvm/arm.c              |  9 ++----
>  arch/arm/kvm/init.S             | 29 +++++++++++++++--
>  arch/arm/kvm/mmu.c              | 71 ++++++++++++++++++++++-------------------
>  5 files changed, 101 insertions(+), 47 deletions(-)
> 
> diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
> index a7a0bb5..3556684 100644
> --- a/arch/arm/include/asm/kvm_host.h
> +++ b/arch/arm/include/asm/kvm_host.h
> @@ -190,22 +190,32 @@ int kvm_arm_coproc_set_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *);
>  int handle_exit(struct kvm_vcpu *vcpu, struct kvm_run *run,
>  		int exception_index);
>  
> -static inline void __cpu_init_hyp_mode(unsigned long long pgd_ptr,
> +static inline void __cpu_init_hyp_mode(unsigned long long boot_pgd_ptr,
> +				       unsigned long long pgd_ptr,
>  				       unsigned long hyp_stack_ptr,
>  				       unsigned long vector_ptr)
>  {
>  	unsigned long pgd_low, pgd_high;
>  
> -	pgd_low = (pgd_ptr & ((1ULL << 32) - 1));
> -	pgd_high = (pgd_ptr >> 32ULL);
> +	pgd_low = (boot_pgd_ptr & ((1ULL << 32) - 1));
> +	pgd_high = (boot_pgd_ptr >> 32ULL);
>  
>  	/*
>  	 * Call initialization code, and switch to the full blown
>  	 * HYP code. The init code doesn't need to preserve these registers as
> -	 * r1-r3 and r12 are already callee save according to the AAPCS.
> +	 * r1-r3 and r12 are already callee saved according to the AAPCS.
>  	 * Note that we slightly misuse the prototype by casing the pgd_low to
>  	 * a void *.
> +	 *
> +	 * We don't have enough registers to perform the full init in one go.
> +	 * Install the boot PGD first, and then install the runtime PGD,
> +	 * stack pointer and vectors.
>  	 */
> +	kvm_call_hyp((void *)pgd_low, pgd_high, 0, 0);
> +
> +	pgd_low = (pgd_ptr & ((1ULL << 32) - 1));
> +	pgd_high = (pgd_ptr >> 32ULL);
> +
>  	kvm_call_hyp((void *)pgd_low, pgd_high, hyp_stack_ptr, vector_ptr);
>  }
>  
> diff --git a/arch/arm/include/asm/kvm_mmu.h b/arch/arm/include/asm/kvm_mmu.h
> index 92eb20d..3567a49 100644
> --- a/arch/arm/include/asm/kvm_mmu.h
> +++ b/arch/arm/include/asm/kvm_mmu.h
> @@ -19,17 +19,29 @@
>  #ifndef __ARM_KVM_MMU_H__
>  #define __ARM_KVM_MMU_H__
>  
> -#include <asm/cacheflush.h>
> -#include <asm/pgalloc.h>
> +#include <asm/memory.h>
> +#include <asm/page.h>
>  
>  /*
>   * We directly use the kernel VA for the HYP, as we can directly share
>   * the mapping (HTTBR "covers" TTBR1).
>   */
> -#define HYP_PAGE_OFFSET_MASK	(~0UL)
> +#define HYP_PAGE_OFFSET_MASK	UL(~0)
>  #define HYP_PAGE_OFFSET		PAGE_OFFSET
>  #define KERN_TO_HYP(kva)	(kva)
>  
> +/*
> + * Our virtual mapping for the boot-time MMU-enable code. Must be
> + * shared across all the page-tables. Conveniently, we use the vectors
> + * page, where no kernel data will ever be shared with HYP.
> + */
> +#define TRAMPOLINE_VA		UL(CONFIG_VECTORS_BASE)
> +
> +#ifndef __ASSEMBLY__
> +
> +#include <asm/cacheflush.h>
> +#include <asm/pgalloc.h>
> +
>  int create_hyp_mappings(void *from, void *to);
>  int create_hyp_io_mappings(void *from, void *to, phys_addr_t);
>  void free_hyp_pgds(void);
> @@ -44,6 +56,7 @@ int kvm_handle_guest_abort(struct kvm_vcpu *vcpu, struct kvm_run *run);
>  void kvm_mmu_free_memory_caches(struct kvm_vcpu *vcpu);
>  
>  phys_addr_t kvm_mmu_get_httbr(void);
> +phys_addr_t kvm_mmu_get_boot_httbr(void);
>  int kvm_mmu_init(void);
>  void kvm_clear_hyp_idmap(void);
>  
> @@ -113,4 +126,6 @@ static inline void coherent_icache_guest_page(struct kvm *kvm, gfn_t gfn)
>  	}
>  }
>  
> +#endif	/* !__ASSEMBLY__ */
> +
>  #endif /* __ARM_KVM_MMU_H__ */
> diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
> index 6eba879..f0f3290 100644
> --- a/arch/arm/kvm/arm.c
> +++ b/arch/arm/kvm/arm.c
> @@ -795,6 +795,7 @@ long kvm_arch_vm_ioctl(struct file *filp,
>  
>  static void cpu_init_hyp_mode(void *vector)
>  {
> +	unsigned long long boot_pgd_ptr;
>  	unsigned long long pgd_ptr;
>  	unsigned long hyp_stack_ptr;
>  	unsigned long stack_page;
> @@ -803,12 +804,13 @@ static void cpu_init_hyp_mode(void *vector)
>  	/* Switch from the HYP stub to our own HYP init vector */
>  	__hyp_set_vectors((unsigned long)vector);
>  
> +	boot_pgd_ptr = (unsigned long long)kvm_mmu_get_boot_httbr();
>  	pgd_ptr = (unsigned long long)kvm_mmu_get_httbr();
>  	stack_page = __get_cpu_var(kvm_arm_hyp_stack_page);
>  	hyp_stack_ptr = stack_page + PAGE_SIZE;
>  	vector_ptr = (unsigned long)__kvm_hyp_vector;
>  
> -	__cpu_init_hyp_mode(pgd_ptr, hyp_stack_ptr, vector_ptr);
> +	__cpu_init_hyp_mode(boot_pgd_ptr, pgd_ptr, hyp_stack_ptr, vector_ptr);
>  }
>  
>  /**
> @@ -862,11 +864,6 @@ static int init_hyp_mode(void)
>  	}
>  
>  	/*
> -	 * Unmap the identity mapping
> -	 */
> -	kvm_clear_hyp_idmap();
> -
> -	/*
>  	 * Map the Hyp-code called directly from the host
>  	 */
>  	err = create_hyp_mappings(__kvm_hyp_code_start, __kvm_hyp_code_end);
> diff --git a/arch/arm/kvm/init.S b/arch/arm/kvm/init.S
> index 35a463f..b2c6967 100644
> --- a/arch/arm/kvm/init.S
> +++ b/arch/arm/kvm/init.S
> @@ -21,6 +21,7 @@
>  #include <asm/asm-offsets.h>
>  #include <asm/kvm_asm.h>
>  #include <asm/kvm_arm.h>
> +#include <asm/kvm_mmu.h>
>  
>  /********************************************************************
>   * Hypervisor initialization
> @@ -47,6 +48,9 @@ __kvm_hyp_init:
>  	W(b)	.
>  
>  __do_hyp_init:
> +	cmp	r2, #0			@ We have a SP?
> +	bne	phase2			@ Yes, second stage init
> +
>  	@ Set the HTTBR to point to the hypervisor PGD pointer passed
>  	mcrr	p15, 4, r0, r1, c2
>  
> @@ -96,14 +100,35 @@ __do_hyp_init:
>  	orr	r0, r0, r1
>  	isb
>  	mcr	p15, 4, r0, c1, c0, 0	@ HSCR
> -	isb
>  
> -	@ Set stack pointer and return to the kernel
> +	eret

Could you add some comment here to indicate we're done with phase1, it
seems like this eret should not go unnoticed by casual readers (ok, they
shouldn't read this code casually, but anyway..., it will make me sleep
better)

> +
> +phase2:
> +	@ Set stack pointer
>  	mov	sp, r2
>  
>  	@ Set HVBAR to point to the HYP vectors
>  	mcr	p15, 4, r3, c12, c0, 0	@ HVBAR
>  
> +	@ Jump to the trampoline page
> +	ldr	r2, =#PAGE_MASK
> +	adr	r3, target
> +	bic	r3, r3, r2
> +	ldr	r2, =#TRAMPOLINE_VA
> +	add	r3, r3, r2
> +	mov	pc, r3
> +
> +	nop
> +
> +target:	@ We're now in the trampoline code, switch page tables
> +	mcrr	p15, 4, r0, r1, c2
> +	isb
> +
> +	@ Invalidate the old TLBs
> +	mcr	p15, 4, r0, c8, c7, 0	@ TLBIALLH
> +	dsb
> +	isb
> +
>  	eret
>  
>  	.ltorg
> diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
> index 85b3553..ed5587f 100644
> --- a/arch/arm/kvm/mmu.c
> +++ b/arch/arm/kvm/mmu.c
> @@ -32,6 +32,7 @@
>  
>  extern char  __hyp_idmap_text_start[], __hyp_idmap_text_end[];
>  
> +static pgd_t *boot_hyp_pgd;
>  static pgd_t *hyp_pgd;
>  static DEFINE_MUTEX(kvm_hyp_pgd_mutex);
>  
> @@ -111,6 +112,8 @@ static void free_hyp_pgd_entry(pgd_t *pgdp, unsigned long addr)
>   * Assumes hyp_pgd is a page table used strictly in Hyp-mode and therefore contains
>   * either mappings in the kernel memory area (above PAGE_OFFSET), or
>   * device mappings in the vmalloc range (from VMALLOC_START to VMALLOC_END).
> + *
> + * boot_hyp_pgd should only map two pages for the init code.
>   */
>  void free_hyp_pgds(void)
>  {
> @@ -118,6 +121,12 @@ void free_hyp_pgds(void)
>  
>  	mutex_lock(&kvm_hyp_pgd_mutex);
>  
> +	if (boot_hyp_pgd) {
> +		free_hyp_pgd_entry(boot_hyp_pgd, virt_to_phys(__hyp_idmap_text_start));
> +		free_hyp_pgd_entry(boot_hyp_pgd, TRAMPOLINE_VA);
> +		kfree(boot_hyp_pgd);
> +	}
> +
>  	if (hyp_pgd) {
>  		for (addr = PAGE_OFFSET; virt_addr_valid(addr); addr += PGDIR_SIZE)
>  			free_hyp_pgd_entry(hyp_pgd, KERN_TO_HYP(addr));
> @@ -718,6 +727,12 @@ phys_addr_t kvm_mmu_get_httbr(void)
>  	return virt_to_phys(hyp_pgd);
>  }
>  
> +phys_addr_t kvm_mmu_get_boot_httbr(void)
> +{
> +	VM_BUG_ON(!virt_addr_valid(boot_hyp_pgd));
> +	return virt_to_phys(boot_hyp_pgd);
> +}
> +
>  int kvm_mmu_init(void)
>  {
>  	unsigned long hyp_idmap_start = virt_to_phys(__hyp_idmap_text_start);
> @@ -725,7 +740,8 @@ int kvm_mmu_init(void)
>  	int err;
>  
>  	hyp_pgd = kzalloc(PTRS_PER_PGD * sizeof(pgd_t), GFP_KERNEL);
> -	if (!hyp_pgd) {
> +	boot_hyp_pgd = kzalloc(PTRS_PER_PGD * sizeof(pgd_t), GFP_KERNEL);
> +	if (!hyp_pgd || !boot_hyp_pgd) {
>  		kvm_err("Hyp mode PGD not allocated\n");
>  		err = -ENOMEM;
>  		goto out;
> @@ -743,39 +759,30 @@ int kvm_mmu_init(void)
>  		goto out;
>  	}
>  
> +	/* Map the very same page at the trampoline VA */
> +	err = 	__create_hyp_mappings(boot_hyp_pgd,
> +				      TRAMPOLINE_VA, TRAMPOLINE_VA + PAGE_SIZE,
> +				      __phys_to_pfn(hyp_idmap_start),
> +				      PAGE_HYP);
> +	if (err) {
> +		kvm_err("Failed to map trampoline @%lx into boot HYP pgd\n",
> +			TRAMPOLINE_VA);
> +		goto out;
> +	}
> +
> +	/* Map the same page again into the runtime page tables */
> +	err = 	__create_hyp_mappings(hyp_pgd,
> +				      TRAMPOLINE_VA, TRAMPOLINE_VA + PAGE_SIZE,
> +				      __phys_to_pfn(hyp_idmap_start),
> +				      PAGE_HYP);
> +	if (err) {
> +		kvm_err("Failed to map trampoline @%lx into runtime HYP pgd\n",
> +			TRAMPOLINE_VA);
> +		goto out;
> +	}
> +
>  	return 0;
>  out:
>  	free_hyp_pgds();
>  	return err;
>  }
> -
> -/**
> - * kvm_clear_idmap - remove all idmaps from the hyp pgd
> - *
> - * Free the underlying pmds for all pgds in range and clear the pgds (but
> - * don't free them) afterwards.
> - */
> -void kvm_clear_hyp_idmap(void)
> -{
> -	unsigned long addr, end;
> -	unsigned long next;
> -	pgd_t *pgd = hyp_pgd;
> -	pud_t *pud;
> -	pmd_t *pmd;
> -
> -	addr = virt_to_phys(__hyp_idmap_text_start);
> -	end = virt_to_phys(__hyp_idmap_text_end);
> -
> -	pgd += pgd_index(addr);
> -	do {
> -		next = pgd_addr_end(addr, end);
> -		if (pgd_none_or_clear_bad(pgd))
> -			continue;
> -		pud = pud_offset(pgd, addr);
> -		pmd = pmd_offset(pud, addr);
> -
> -		pud_clear(pud);
> -		kvm_clean_pmd_entry(pmd);
> -		pmd_free(NULL, (pmd_t *)((unsigned long)pmd & PAGE_MASK));
> -	} while (pgd++, addr = next, addr < end);
> -}
> -- 
> 1.8.1.4
> 
> 


From cdall at cs.columbia.edu  Wed Apr  3 19:15:59 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Wed, 3 Apr 2013 16:15:59 -0700
Subject: [PATCH 6/7] ARM: KVM: switch to a dual-step HYP init code
In-Reply-To: <515C06A6.5030807@arm.com>
References: <1364909115-3810-1-git-send-email-marc.zyngier@arm.com>
 <1364909115-3810-7-git-send-email-marc.zyngier@arm.com>
 <20130403100751.GD11040@mudshark.cambridge.arm.com>
 <515C06A6.5030807@arm.com>
Message-ID: <20130403231559.GG29227@gmail.com>

On Wed, Apr 03, 2013 at 11:38:30AM +0100, Marc Zyngier wrote:
> On 03/04/13 11:07, Will Deacon wrote:
> > On Tue, Apr 02, 2013 at 02:25:14PM +0100, Marc Zyngier wrote:
> >> Our HYP init code suffers from two major design issues:
> >> - it cannot support CPU hotplug, as we tear down the idmap very early
> >> - it cannot perform a TLB invalidation when switching from init to
> >>   runtime mappings, as pages are manipulated from PL1 exclusively
> > 
> > [...]
> > 
> >> diff --git a/arch/arm/kvm/init.S b/arch/arm/kvm/init.S
> >> index 35a463f..b2c6967 100644
> >> --- a/arch/arm/kvm/init.S
> >> +++ b/arch/arm/kvm/init.S
> >> @@ -21,6 +21,7 @@
> >>  #include <asm/asm-offsets.h>
> >>  #include <asm/kvm_asm.h>
> >>  #include <asm/kvm_arm.h>
> >> +#include <asm/kvm_mmu.h>
> >>  
> >>  /********************************************************************
> >>   * Hypervisor initialization
> >> @@ -47,6 +48,9 @@ __kvm_hyp_init:
> >>  	W(b)	.
> >>  
> >>  __do_hyp_init:
> >> +	cmp	r2, #0			@ We have a SP?
> >> +	bne	phase2			@ Yes, second stage init
> >> +
> >>  	@ Set the HTTBR to point to the hypervisor PGD pointer passed
> >>  	mcrr	p15, 4, r0, r1, c2
> >>  
> >> @@ -96,14 +100,35 @@ __do_hyp_init:
> >>  	orr	r0, r0, r1
> >>  	isb
> >>  	mcr	p15, 4, r0, c1, c0, 0	@ HSCR
> >> -	isb
> >>  
> >> -	@ Set stack pointer and return to the kernel
> >> +	eret
> >> +
> >> +phase2:
> >> +	@ Set stack pointer
> >>  	mov	sp, r2
> >>  
> >>  	@ Set HVBAR to point to the HYP vectors
> >>  	mcr	p15, 4, r3, c12, c0, 0	@ HVBAR
> >>  
> >> +	@ Jump to the trampoline page
> >> +	ldr	r2, =#PAGE_MASK
> > 
> > Shifting right by PAGE_SHIFT can avoid the load.
> 
> Not really. We're masking out the top bits of "target" and adding them
> to the trampoline base address, so shifting doesn't help.
> 
> But, as you suggested offline, BFI can come to the rescue and make that
> code totally fun and unreadable. How about (untested):
> 
> 	ldr	r2, =#TRAMPOLINE_VA
> 	adr	r3, target
> 	bfi	r2, r3, #0, #PAGE_SHIFT
> 	mov	pc, r2
> 
> I really like it! :)
> 

What kind of drugs are you on?

Ok, I actually like it too.

> > 
> >> +	adr	r3, target
> >> +	bic	r3, r3, r2
> >> +	ldr	r2, =#TRAMPOLINE_VA
> >> +	add	r3, r3, r2
> >> +	mov	pc, r3
> >> +
> >> +	nop
> > 
> > <insert dead chicken and voodoo chant here>
> 
> ... "You know I'll never sleep no more" ...
> 

Seriously, what kind of drugs are you guys on?


From cdall at cs.columbia.edu  Wed Apr  3 19:16:10 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Wed, 3 Apr 2013 16:16:10 -0700
Subject: [PATCH 7/7] ARM: KVM: perform HYP initilization for hotplugged
 CPUs
In-Reply-To: <1364909115-3810-8-git-send-email-marc.zyngier@arm.com>
References: <1364909115-3810-1-git-send-email-marc.zyngier@arm.com>
 <1364909115-3810-8-git-send-email-marc.zyngier@arm.com>
Message-ID: <20130403231610.GH29227@gmail.com>

On Tue, Apr 02, 2013 at 02:25:15PM +0100, Marc Zyngier wrote:
> Now that we have the necessary infrastructure to boot a hotplugged CPU
> at any point in time, wire a CPU notifier that will perform the HYP
> init for the incoming CPU.
> 
> Note that this depends on the platform code and/or firmware to boot the
> incoming CPU with HYP mode enabled and return to the kernel by following
> the normal boot path (HYP stub installed).
> 
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> ---
>  arch/arm/kvm/arm.c | 47 +++++++++++++++++++++++++++++++----------------
>  1 file changed, 31 insertions(+), 16 deletions(-)
> 
> diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
> index f0f3290..6cc076e 100644
> --- a/arch/arm/kvm/arm.c
> +++ b/arch/arm/kvm/arm.c
> @@ -793,8 +793,9 @@ long kvm_arch_vm_ioctl(struct file *filp,
>  	}
>  }
>  
> -static void cpu_init_hyp_mode(void *vector)
> +static void cpu_init_hyp_mode(void *dummy)
>  {
> +	phys_addr_t init_vector_addr = virt_to_phys(__kvm_hyp_init);
>  	unsigned long long boot_pgd_ptr;
>  	unsigned long long pgd_ptr;
>  	unsigned long hyp_stack_ptr;
> @@ -802,7 +803,7 @@ static void cpu_init_hyp_mode(void *vector)
>  	unsigned long vector_ptr;
>  
>  	/* Switch from the HYP stub to our own HYP init vector */
> -	__hyp_set_vectors((unsigned long)vector);
> +	__hyp_set_vectors(init_vector_addr);
>  
>  	boot_pgd_ptr = (unsigned long long)kvm_mmu_get_boot_httbr();
>  	pgd_ptr = (unsigned long long)kvm_mmu_get_httbr();
> @@ -813,12 +814,28 @@ static void cpu_init_hyp_mode(void *vector)
>  	__cpu_init_hyp_mode(boot_pgd_ptr, pgd_ptr, hyp_stack_ptr, vector_ptr);
>  }
>  
> +static int hyp_init_cpu_notify(struct notifier_block *self,
> +			       unsigned long action, void *cpu)
> +{
> +	switch (action) {
> +	case CPU_STARTING:
> +	case CPU_STARTING_FROZEN:
> +		cpu_init_hyp_mode(NULL);
> +		break;
> +	}
> +
> +	return NOTIFY_OK;
> +}
> +
> +static struct notifier_block hyp_init_cpu_nb = {
> +	.notifier_call = hyp_init_cpu_notify,
> +};
> +
>  /**
>   * Inits Hyp-mode on all online CPUs
>   */
>  static int init_hyp_mode(void)
>  {
> -	phys_addr_t init_phys_addr;
>  	int cpu;
>  	int err = 0;
>  
> @@ -851,19 +868,6 @@ static int init_hyp_mode(void)
>  	}
>  
>  	/*
> -	 * Execute the init code on each CPU.
> -	 *
> -	 * Note: The stack is not mapped yet, so don't do anything else than
> -	 * initializing the hypervisor mode on each CPU using a local stack
> -	 * space for temporary storage.
> -	 */
> -	init_phys_addr = virt_to_phys(__kvm_hyp_init);
> -	for_each_online_cpu(cpu) {
> -		smp_call_function_single(cpu, cpu_init_hyp_mode,
> -					 (void *)(long)init_phys_addr, 1);
> -	}
> -
> -	/*
>  	 * Map the Hyp-code called directly from the host
>  	 */
>  	err = create_hyp_mappings(__kvm_hyp_code_start, __kvm_hyp_code_end);
> @@ -908,6 +912,11 @@ static int init_hyp_mode(void)
>  	}
>  
>  	/*
> +	 * Execute the init code on each CPU.
> +	 */
> +	on_each_cpu(cpu_init_hyp_mode, NULL, 1);
> +
> +	/*
>  	 * Init HYP view of VGIC
>  	 */
>  	err = kvm_vgic_hyp_init();
> @@ -963,6 +972,12 @@ int kvm_arch_init(void *opaque)
>  	if (err)
>  		goto out_err;
>  
> +	err = register_cpu_notifier(&hyp_init_cpu_nb);
> +	if (err) {
> +		kvm_err("Cannot register HYP init CPU notifier (%d)\n", err);
> +		goto out_err;
> +	}
> +
>  	kvm_coproc_table_init();
>  	return 0;
>  out_err:
> -- 
> 1.8.1.4
> 
> 
Acked-by: Christoffer Dall <cdall at cs.columbia.edu>


From cdall at cs.columbia.edu  Wed Apr  3 19:17:25 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Wed, 3 Apr 2013 16:17:25 -0700
Subject: [PATCH] ARM: KVM: fix KVM_CAP_ARM_SET_DEVICE_ADDR reporting
In-Reply-To: <1364982193-21867-1-git-send-email-marc.zyngier@arm.com>
References: <1364982193-21867-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <20130403231725.GI29227@gmail.com>

On Wed, Apr 03, 2013 at 10:43:13AM +0100, Marc Zyngier wrote:
> Commit 3401d54696f9 (KVM: ARM: Introduce KVM_ARM_SET_DEVICE_ADDR
> ioctl) added support for the KVM_CAP_ARM_SET_DEVICE_ADDR capability,
> but failed to add a break in the relevant case statement, returning
> the number of CPUs instead.
> 
> Luckilly enough, the CONFIG_NR_CPUS=0 patch hasn't been merged yet
> (https://lkml.org/lkml/diff/2012/3/31/131/1), so the bug wasn't
> noticed.
> 
> Just give it a break!
> 
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> ---
>  arch/arm/kvm/arm.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
> index 6cc076e..d568e83 100644
> --- a/arch/arm/kvm/arm.c
> +++ b/arch/arm/kvm/arm.c
> @@ -198,6 +198,7 @@ int kvm_dev_ioctl_check_extension(long ext)
>  		break;
>  	case KVM_CAP_ARM_SET_DEVICE_ADDR:
>  		r = 1;
> +		break;
>  	case KVM_CAP_NR_VCPUS:
>  		r = num_online_cpus();
>  		break;
> -- 
> 1.8.1.4
> 
> 
Whoops, nice catch. Thanks.

-Christoffer


From cdall at cs.columbia.edu  Wed Apr  3 19:18:45 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Wed, 3 Apr 2013 16:18:45 -0700
Subject: [PATCH 0/7] ARM: KVM: Revamping the HYP init code for fun and
 profit
In-Reply-To: <1364909115-3810-1-git-send-email-marc.zyngier@arm.com>
References: <1364909115-3810-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <20130403231845.GJ29227@gmail.com>

On Tue, Apr 02, 2013 at 02:25:08PM +0100, Marc Zyngier wrote:
> Over the past few weeks, I've gradually realized how broken our HYP
> idmap code is. Badly broken.
> 
> The main problem is about supporting CPU hotplug. Imagine a CPU being
> initialized normally, running VMs, and then being powered down. So
> far, so good. Now mentally bring it back online. The CPU will come
> back via the secondary CPU boot path, and then what? We cannot use it
> anymore, because we need an idmap which is long gone, and because our
> page tables are now live, containing the world-switch code, VM
> structures, and other bits and pieces.
> 
> Another fun issue is that we don't have any TLB invalidation in the
> HYP init code. And guess what? we cannot do it! HYP TLB invalidation
> has to occur in HYP, and once we've installed the runtime page tables,
> it is already too late. It is actually fairly easy to construct a
> scenario where idmap and runtime pages have colliding translations.
> 
> The nail on the coffin was provided by Catalin Marinas who told me how
> much he disliked the arm64 HYP idmap code, and made me realize that we
> already have all the necessary code in arch/arm/kvm/mmu.c. It just
> needs a tiny bit of care and affection. With a chainsaw.
> 
> The solution to the first two issues is a bit tricky, but doesn't
> involve a lot of code. The hotplug problem mandates that we keep two
> sets of page tables (boot and runtime). The TLB problem mandates that
> we're able to transition from one PGD to another while in HYP,
> invalidating the TLBs in the process.
> 
> To be able to do this, we need to share a page between the two page
> tables. A page that will have the same VA in both configurations. All
> we need is a VA that has the following properties:
> - This VA can't be used to represent a kernel mapping.
> - This VA will not conflict with the physical address of the kernel
>   text
> 
> The vectors page VA seems to satisfy this requirement:
> - The kernel never maps anything else there
> - The kernel text being copied at the beginning of the physical
>   memory, it is unlikely to use the last 64kB (I doubt we'll ever
>   support KVM on a system with something like 4MB of RAM, but patches
>   are very welcome).
> 
> Let's call this VA the trampoline VA.
> 
> Now, we map our init page at 3 locations:
> - idmap in the boot pgd
> - trampoline VA in the boot pgd
> - trampoline VA in the runtime pgd
> 
> The init scenario is now the following:
> - We jump in HYP with four parameters: boot HYP pgd, runtime HYP pgd,
>   runtime stack, runtime vectors
> - Enable the MMU with the boot pgd
> - Jump to a target into the trampoline page (remember, this is the
>   same physical page!)
> - Now switch to the runtime pgd (same VA, and still the same physical
>   page!)
> - Invalidate TLBs
> - Set stack and vectors
> - Profit! (or eret, if you only care about the code).
> 
> Once we have this infrastructure in place, supporting CPU hot-plug is
> a piece of cake. Just wire a cpu-notifier in the existing code.
> 
> This has been tested on both arm (VE TC2) and arm64 (Foundation Model).
> 

So this looks quite good overall, thanks for taking care of this.  When
you send out a V2 it should be ready that I can take it in my tree and
send it further.

-Christoffer


From swarren at wwwdotorg.org  Wed Apr  3 19:23:05 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Wed, 03 Apr 2013 17:23:05 -0600
Subject: [PATCH v9 00/14] Tegra114 clockframework
In-Reply-To: <515C7495.8060106@wwwdotorg.org>
References: <1365000110-8916-1-git-send-email-pdeschrijver@nvidia.com>
 <515C6C6E.6060302@wwwdotorg.org> <515C7495.8060106@wwwdotorg.org>
Message-ID: <515CB9D9.90303@wwwdotorg.org>

On 04/03/2013 12:27 PM, Stephen Warren wrote:
> On 04/03/2013 11:52 AM, Stephen Warren wrote:
>> On 04/03/2013 08:40 AM, Peter De Schrijver wrote:
>>> This is the nineth version of the Tegra114 clockframework. It is based on the
>>> next-20130320-fixed branch of
>>> git://nv-tegra.nvidia.com/user/swarren/linux-2.6.git,
> ... [it depends on]
>>> http://patchwork.ozlabs.org/patch/233415/
>>
>> That is Joseph's "clocksource: tegra: enable arch_timer". Is this
>> actually a dependency, or an optimization, or ...?
>>
>> Rob Herring objected to that patch since it isn't necessary if his
>> series "ARM arch, sp804 and integrator timer CLKSRC_OF support" is applied.
>>
>> If I apply just your (Peter's) CCF series without Joseph's or Rob's
>> patches, will everything still work, or is this a hard dependency to
>> create a working system?
> 
> I manage to get this series applied on top of my local dev branch, based
> on next-20130328 (it was painful). Testing indicates that there is no
> dependency on Joseph's patch mentioned above; I could boot, log in, and
> play audio (with local patches) with /or/ without Joseph's patch applied.
> 
> However, I still find that I need to revert f7db706 ARM: "7674/1: smp:
> Avoid dummy clockevent being preferred over real hardware clock-event",
> or I get a hard system hang right after the root fs is mounted. As such,
> I not sure if it's worthwhile applying this series since it's unlikely
> to actually work once merged into Torvalds' tree.
> 
> Do you have any idea what the problem is here?
> 
> I'll try rebasing my local test branch on top of the latest linux-next
> just in case some other fix solved this already, but I'm not going to
> hold my breath.

I've found the problem. My bootloader wasn't initializing the TSC and
hence I guess it wasn't working properly, even with Joseph's patch to
add a call to the initialization function.

So, if I:

a) Fix my bootloader to enable TSC.

b) Merge Rob's patch series to enable the TSC. This is needed rather
than Joseph's patch since the two conflict, and I assume that Rob's
patch is going into 3.10.

c) Undo my local revert of "ARM: 7674/1: smp: Avoid dummy clockevent
being preferred over real hardware clock-event".

... then everything now works.

So the only remaining issues are:

1) Should the mux clocks still be defined in the binding document?
Prashant didn't seem to think so.

2) I need Mike's ack to apply this series to the Tegra tree.


From olof at lixom.net  Wed Apr  3 19:25:21 2013
From: olof at lixom.net (Olof Johansson)
Date: Wed, 3 Apr 2013 16:25:21 -0700
Subject: [GIT PULL] Reset controller API
In-Reply-To: <20130330112002.GA29752@pengutronix.de>
References: <20130330112002.GA29752@pengutronix.de>
Message-ID: <20130403232521.GA20093@quad.lixom.net>

On Sat, Mar 30, 2013 at 12:20:02PM +0100, Philipp Zabel wrote:
> Hi Olof,
> 
> the following changes since commit 8bb9660418e05bb1845ac1a2428444d78e322cc7:
> 
>   Linux 3.9-rc4 (2013-03-23 16:52:44 -0700)
> 
> are available in the git repository at:
> 
>   git://git.pengutronix.de/git/pza/linux.git reset/for_v3.10

Hi,

I don't see a review/ack by the devicetree maintainers on the new binding.

Rob, Grant, can you please review? It looks pretty sane to me but I'd prefer to
see your acks.


-Olof


From festevam at gmail.com  Wed Apr  3 19:30:39 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Wed,  3 Apr 2013 20:30:39 -0300
Subject: [PATCH v2 1/3] ARM: dts: mxs: Use the standard gpio reset binding
Message-ID: <1365031841-3864-1-git-send-email-festevam@gmail.com>

From: Fabio Estevam <fabio.estevam at freescale.com>

Instead of using a custom binding for turning on a GPIO that activates the 
panel, use the standard one.

Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
---
Changes since v1:
- Adjust Subject, since the change is not specific to mx28evk

 Documentation/devicetree/bindings/fb/mxsfb.txt |    5 +----
 arch/arm/boot/dts/imx23-evk.dts                |    8 +++++++-
 arch/arm/boot/dts/imx28-evk.dts                |    8 +++++++-
 3 files changed, 15 insertions(+), 6 deletions(-)

diff --git a/Documentation/devicetree/bindings/fb/mxsfb.txt b/Documentation/devicetree/bindings/fb/mxsfb.txt
index 7ba3b76..b15230c 100644
--- a/Documentation/devicetree/bindings/fb/mxsfb.txt
+++ b/Documentation/devicetree/bindings/fb/mxsfb.txt
@@ -8,9 +8,7 @@ Required properties:
 - display : phandle to display node (see below for details)
 
 Optional properties:
-- panel-enable-gpios : Should specify the gpio for panel enable
-
-* display node
+- display node
 
 Required properties:
 - bits-per-pixel : <16> for RGB565, <32> for RGB888/666.
@@ -25,7 +23,6 @@ lcdif at 80030000 {
 	compatible = "fsl,imx28-lcdif";
 	reg = <0x80030000 2000>;
 	interrupts = <38 86>;
-	panel-enable-gpios = <&gpio3 30 0>;
 
 	display: display {
 		bits-per-pixel = <32>;
diff --git a/arch/arm/boot/dts/imx23-evk.dts b/arch/arm/boot/dts/imx23-evk.dts
index 7880e17..28f9766 100644
--- a/arch/arm/boot/dts/imx23-evk.dts
+++ b/arch/arm/boot/dts/imx23-evk.dts
@@ -59,7 +59,7 @@
 			lcdif at 80030000 {
 				pinctrl-names = "default";
 				pinctrl-0 = <&lcdif_24bit_pins_a>;
-				panel-enable-gpios = <&gpio1 18 0>;
+				resets = <&gpio_reset 0>;
 				display = <&display>;
 				status = "okay";
 
@@ -89,6 +89,12 @@
 			};
 		};
 
+		gpio_reset: gpio-reset {
+			compatible = "gpio-reset";
+			reset-gpios = <&gpio1 18 1>;
+			#reset-cells = <1>;
+		};
+
 		apbx at 80040000 {
 			pwm: pwm at 80064000 {
 				pinctrl-names = "default";
diff --git a/arch/arm/boot/dts/imx28-evk.dts b/arch/arm/boot/dts/imx28-evk.dts
index 2d4ea3b..e373dd6 100644
--- a/arch/arm/boot/dts/imx28-evk.dts
+++ b/arch/arm/boot/dts/imx28-evk.dts
@@ -123,7 +123,7 @@
 				pinctrl-names = "default";
 				pinctrl-0 = <&lcdif_24bit_pins_a
 					     &lcdif_pins_evk>;
-				panel-enable-gpios = <&gpio3 30 0>;
+				resets = <&gpio_reset 0>;
 				display = <&display>;
 				status = "okay";
 
@@ -152,6 +152,12 @@
 				};
 			};
 
+			gpio_reset: gpio-reset {
+				compatible = "gpio-reset";
+				reset-gpios = <&gpio3 30 1>;
+				#reset-cells = <1>;
+			};
+
 			can0: can at 80032000 {
 				pinctrl-names = "default";
 				pinctrl-0 = <&can0_pins_a>;
-- 
1.7.9.5



From festevam at gmail.com  Wed Apr  3 19:30:40 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Wed,  3 Apr 2013 20:30:40 -0300
Subject: [PATCH v2 2/3] video: mxsfb: Remove custom method for retrieving GPIO
In-Reply-To: <1365031841-3864-1-git-send-email-festevam@gmail.com>
References: <1365031841-3864-1-git-send-email-festevam@gmail.com>
Message-ID: <1365031841-3864-2-git-send-email-festevam@gmail.com>

From: Fabio Estevam <fabio.estevam at freescale.com>

mxs device tree files should use the standard gpio reset binding, so no need to
have this code inside the driver anymore.

Cc: Florian Tobias Schandinat <FlorianSchandinat at gmx.de>
Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
---
Changes since v1:
- No changes
 drivers/video/mxsfb.c |   19 -------------------
 1 file changed, 19 deletions(-)

diff --git a/drivers/video/mxsfb.c b/drivers/video/mxsfb.c
index eac7c1a..acfb871 100644
--- a/drivers/video/mxsfb.c
+++ b/drivers/video/mxsfb.c
@@ -42,7 +42,6 @@
 #include <linux/module.h>
 #include <linux/kernel.h>
 #include <linux/of_device.h>
-#include <linux/of_gpio.h>
 #include <video/of_display_timing.h>
 #include <linux/platform_device.h>
 #include <linux/clk.h>
@@ -859,8 +858,6 @@ static int mxsfb_probe(struct platform_device *pdev)
 	struct fb_info *fb_info;
 	struct fb_modelist *modelist;
 	struct pinctrl *pinctrl;
-	int panel_enable;
-	enum of_gpio_flags flags;
 	int ret;
 
 	if (of_id)
@@ -904,22 +901,6 @@ static int mxsfb_probe(struct platform_device *pdev)
 		goto fb_release;
 	}
 
-	panel_enable = of_get_named_gpio_flags(pdev->dev.of_node,
-					       "panel-enable-gpios", 0, &flags);
-	if (gpio_is_valid(panel_enable)) {
-		unsigned long f = GPIOF_OUT_INIT_HIGH;
-		if (flags == OF_GPIO_ACTIVE_LOW)
-			f = GPIOF_OUT_INIT_LOW;
-		ret = devm_gpio_request_one(&pdev->dev, panel_enable,
-					    f, "panel-enable");
-		if (ret) {
-			dev_err(&pdev->dev,
-				"failed to request gpio %d: %d\n",
-				panel_enable, ret);
-			goto fb_release;
-		}
-	}
-
 	fb_info->pseudo_palette = devm_kzalloc(&pdev->dev, sizeof(u32) * 16,
 					       GFP_KERNEL);
 	if (!fb_info->pseudo_palette) {
-- 
1.7.9.5



From festevam at gmail.com  Wed Apr  3 19:30:41 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Wed,  3 Apr 2013 20:30:41 -0300
Subject: [PATCH v2 3/3] ARM: mxs_defconfig: Enable CONFIG_RESET_GPIO
In-Reply-To: <1365031841-3864-1-git-send-email-festevam@gmail.com>
References: <1365031841-3864-1-git-send-email-festevam@gmail.com>
Message-ID: <1365031841-3864-3-git-send-email-festevam@gmail.com>

From: Fabio Estevam <fabio.estevam at freescale.com>

CONFIG_RESET_GPIO is required in order to enable a GPIO to turn on a LCD, for
example.

Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
---
Changes since v1:
- No changes

 arch/arm/configs/mxs_defconfig |    2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/configs/mxs_defconfig b/arch/arm/configs/mxs_defconfig
index b5f6e55..d2c4105 100644
--- a/arch/arm/configs/mxs_defconfig
+++ b/arch/arm/configs/mxs_defconfig
@@ -147,6 +147,8 @@ CONFIG_COMMON_CLK_DEBUG=y
 CONFIG_IIO=y
 CONFIG_PWM=y
 CONFIG_PWM_MXS=y
+CONFIG_RESET_CONTROLLER=y
+CONFIG_RESET_GPIO=y
 CONFIG_EXT2_FS=y
 CONFIG_EXT2_FS_XATTR=y
 CONFIG_EXT3_FS=y
-- 
1.7.9.5



From swarren at wwwdotorg.org  Wed Apr  3 19:34:52 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Wed,  3 Apr 2013 17:34:52 -0600
Subject: [PATCH V2 1/7] kbuild: create an "include chroot" for DT bindings
Message-ID: <1365032098-22825-1-git-send-email-swarren@wwwdotorg.org>

From: Stephen Warren <swarren at nvidia.com>

The recent dtc+cpp support allows header files and C pre-processor
defines/macros to be used when compiling device tree files. These
headers will typically define various constants that are part of the
device tree bindings.

The original patch which set up the dtc+cpp include path only considered
using those headers from device tree files. However, most are also
useful for kernel code which needs to interpret the device tree.

In both the DT files and the kernel, I'd like to include the DT-related
headers in the same way, for example, <dt-bindings/gpio/tegra-gpio.h>.
That will simplify any text which discusses the DT header locations.

Creating a <dt-bindings/> for kernel source to use is as simple as
placing files into include/dt-bindings/.

However, when compiling DT files, the include path should be restricted
so that only the dt-bindings path is available; arbitrary kernel headers
shouldn't be exposed. For this reason, create a specific include
directory for use by dtc+cpp, and symlink dt-bindings from there to the
actual location of include/dt-bindings/. For want of a better location,
place this "include chroot" into the existing dts/ directory.

arch/*/boot/dts/include/dt-bindings -> ../../../../../include/dt-bindings

Some headers used by device tree files may not be useful to the kernel;
they may be used simply to aid in constructing the DT file (e.g. macros
to create a node), but not define any information that the kernel needs
to share. These may be placed directly into arch/*/boot/dts/ along with
the DT files themselves.

Cc: Shawn Guo <shawn.guo at linaro.org>
Cc: Hiroshi Doyu <hdoyu at nvidia.com>
Acked-by: Michal Marek <mmarek at suse.cz>
Acked-by: Shawn Guo <shawn.guo at linaro.org>
Acked-by: Rob Herring <rob.herring at calxeda.com>
Signed-off-by: Stephen Warren <swarren at nvidia.com>
---
Grant, Rob, Michal, I'm hoping for acks or comments from you so this
series can be placed into a topic branch in the arm-soc repo, for others
to build on during the 3.10 kernel cycle. Thanks.

This first patch was previously posted separately as V2. I'm including
it here to keep it with the whole series. I hope this series can be
applied as a topic branch in arm-soc.
---
 arch/arm/boot/dts/include/dt-bindings |    1 +
 scripts/Makefile.lib                  |    2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)
 create mode 120000 arch/arm/boot/dts/include/dt-bindings

diff --git a/arch/arm/boot/dts/include/dt-bindings b/arch/arm/boot/dts/include/dt-bindings
new file mode 120000
index 0000000..08c00e4
--- /dev/null
+++ b/arch/arm/boot/dts/include/dt-bindings
@@ -0,0 +1 @@
+../../../../../include/dt-bindings
\ No newline at end of file
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 07125e6..af35521 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -158,7 +158,7 @@ ld_flags       = $(LDFLAGS) $(ldflags-y)
 
 dtc_cpp_flags  = -Wp,-MD,$(depfile) -nostdinc                            \
 		 -I$(srctree)/arch/$(SRCARCH)/boot/dts                   \
-		 -I$(srctree)/arch/$(SRCARCH)/include/dts                \
+		 -I$(srctree)/arch/$(SRCARCH)/boot/dts/include           \
 		 -undef -D__DTS__
 
 # Finds the multi-part object the current object will be linked into
-- 
1.7.10.4



From swarren at wwwdotorg.org  Wed Apr  3 19:34:53 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Wed,  3 Apr 2013 17:34:53 -0600
Subject: [PATCH V2 2/7] kbuild: fixdep: support concatenated dep files
In-Reply-To: <1365032098-22825-1-git-send-email-swarren@wwwdotorg.org>
References: <1365032098-22825-1-git-send-email-swarren@wwwdotorg.org>
Message-ID: <1365032098-22825-2-git-send-email-swarren@wwwdotorg.org>

From: Stephen Warren <swarren at nvidia.com>

The current use-case for fixdep is: a source file is run through a single
processing step, which creates a single dependency file as a side-effect,
which fixdep transforms into the file used by the kernel build process.

In order to transparently run the C pre-processor on device-tree files,
we wish to run both gcc -E and dtc on a source file in a single rule.
This generates two dependency files, which must be transformed together
into the file used by the kernel build process. This change modifies
fixdep so it can process the concatenation of multiple separate input
dependency files, and produce a correct unified output.

The code changes have the slight benefit of transforming the loop in
parse_dep_file() into more of a lexer/tokenizer, with the loop body being
more of a parser. Previously, some of this logic was mixed together
before the loop. I also added some comments, which I hope are useful.

Benchmarking shows that on a cross-compiled ARM tegra_defconfig build,
there is less than 0.5 seconds speed decrease with this change, on top
of a build time of ~2m24s. This is probably within the noise.

Signed-off-by: Stephen Warren <swarren at nvidia.com>
---
 scripts/basic/fixdep.c |   93 +++++++++++++++++++++++++++++++-----------------
 1 file changed, 61 insertions(+), 32 deletions(-)

diff --git a/scripts/basic/fixdep.c b/scripts/basic/fixdep.c
index 7f6425e..078fe1d 100644
--- a/scripts/basic/fixdep.c
+++ b/scripts/basic/fixdep.c
@@ -320,49 +320,78 @@ static void parse_dep_file(void *map, size_t len)
 	char *end = m + len;
 	char *p;
 	char s[PATH_MAX];
-	int first;
-
-	p = strchr(m, ':');
-	if (!p) {
-		fprintf(stderr, "fixdep: parse error\n");
-		exit(1);
-	}
-	memcpy(s, m, p-m); s[p-m] = 0;
-	m = p+1;
+	int is_target;
+	int saw_any_target = 0;
+	int is_first_dep = 0;
 
 	clear_config();
 
-	first = 1;
 	while (m < end) {
+		/* Skip any "white space" */
 		while (m < end && (*m == ' ' || *m == '\\' || *m == '\n'))
 			m++;
+		/* Find next "white space" */
 		p = m;
-		while (p < end && *p != ' ') p++;
-		if (p == end) {
-			do p--; while (!isalnum(*p));
+		while (p < end && *p != ' ' && *p != '\\' && *p != '\n')
 			p++;
+		/* Is the token we found a target name? */
+		is_target = (*(p-1) == ':');
+		/* Don't write any target names into the dependency file */
+		if (is_target) {
+			/* The /next/ file is the first dependency */
+			is_first_dep = 1;
+		} else {
+			/* Save this token/filename */
+			memcpy(s, m, p-m);
+			s[p - m] = 0;
+
+			/* Ignore certain dependencies */
+			if (strrcmp(s, "include/generated/autoconf.h") &&
+			    strrcmp(s, "arch/um/include/uml-config.h") &&
+			    strrcmp(s, "include/linux/kconfig.h") &&
+			    strrcmp(s, ".ver")) {
+				/*
+				 * Do not list the source file as dependency,
+				 * so that kbuild is not confused if a .c file
+				 * is rewritten into .S or vice versa. Storing
+				 * it in source_* is needed for modpost to
+				 * compute srcversions.
+				 */
+				if (is_first_dep) {
+					/*
+					 * If processing the concatenation of
+					 * multiple dependency files, only
+					 * process the first target name, which
+					 * will be the original source name,
+					 * and ignore any other target names,
+					 * which will be intermediate temporary
+					 * files.
+					 */
+					if (!saw_any_target) {
+						saw_any_target = 1;
+						printf("source_%s := %s\n\n",
+							target, s);
+						printf("deps_%s := \\\n",
+							target);
+					}
+					is_first_dep = 0;
+				} else
+					printf("  %s \\\n", s);
+				do_config_file(s);
+			}
 		}
-		memcpy(s, m, p-m); s[p-m] = 0;
-		if (strrcmp(s, "include/generated/autoconf.h") &&
-		    strrcmp(s, "arch/um/include/uml-config.h") &&
-		    strrcmp(s, "include/linux/kconfig.h") &&
-		    strrcmp(s, ".ver")) {
-			/*
-			 * Do not list the source file as dependency, so that
-			 * kbuild is not confused if a .c file is rewritten
-			 * into .S or vice versa. Storing it in source_* is
-			 * needed for modpost to compute srcversions.
-			 */
-			if (first) {
-				printf("source_%s := %s\n\n", target, s);
-				printf("deps_%s := \\\n", target);
-			} else
-				printf("  %s \\\n", s);
-			do_config_file(s);
-		}
-		first = 0;
+		/*
+		 * Start searching for next token immediately after the first
+		 * "whitespace" character that follows this token.
+		 */
 		m = p + 1;
 	}
+
+	if (!saw_any_target) {
+		fprintf(stderr, "fixdep: parse error; no targets found\n");
+		exit(1);
+	}
+
 	printf("\n%s: $(deps_%s)\n\n", target, target);
 	printf("$(deps_%s):\n", target);
 }
-- 
1.7.10.4



From swarren at wwwdotorg.org  Wed Apr  3 19:34:54 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Wed,  3 Apr 2013 17:34:54 -0600
Subject: [PATCH V2 3/7] kbuild: cmd_dtc_cpp: extract deps from both gcc -E and
 dtc
In-Reply-To: <1365032098-22825-1-git-send-email-swarren@wwwdotorg.org>
References: <1365032098-22825-1-git-send-email-swarren@wwwdotorg.org>
Message-ID: <1365032098-22825-3-git-send-email-swarren@wwwdotorg.org>

From: Stephen Warren <swarren at nvidia.com>

Prior to this change, when compiling *.dts to *.dtb, the dependency
output from dtc would be used, and when compiling *.dtsp to *.dtb, the
dependency output from gcc -E alone would be used, despite dtc also
being invoked (on a temporary file that was guaranteed to have no
dependencies).

With this change, when compiling *.dtsp to *.dtb, the dependency files
from both gcc -E and dtc are used. This will allow cmd_dtc_cpp to
replace cmd_dtc in a future change. In turn, that will allow the C pre-
processor to be run transparently on *.dts, without the need to a
separate rule or file extension to trigger it.

Signed-off-by: Stephen Warren <swarren at nvidia.com>
---
 scripts/Makefile.lib |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index af35521..6104335 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -156,7 +156,7 @@ cpp_flags      = -Wp,-MD,$(depfile) $(NOSTDINC_FLAGS) $(LINUXINCLUDE)     \
 
 ld_flags       = $(LDFLAGS) $(ldflags-y)
 
-dtc_cpp_flags  = -Wp,-MD,$(depfile) -nostdinc                            \
+dtc_cpp_flags  = -Wp,-MD,$(depfile).pre -nostdinc                        \
 		 -I$(srctree)/arch/$(SRCARCH)/boot/dts                   \
 		 -I$(srctree)/arch/$(SRCARCH)/boot/dts/include           \
 		 -undef -D__DTS__
@@ -278,7 +278,8 @@ dtc-tmp = $(subst $(comma),_,$(dot-target).dts)
 
 quiet_cmd_dtc_cpp = DTC+CPP $@
 cmd_dtc_cpp = $(CPP) $(dtc_cpp_flags) -x assembler-with-cpp -o $(dtc-tmp) $< ; \
-	$(objtree)/scripts/dtc/dtc -O dtb -o $@ -b 0 $(DTC_FLAGS) $(dtc-tmp)
+	$(objtree)/scripts/dtc/dtc -O dtb -o $@ -b 0 $(DTC_FLAGS) -d $(depfile).dtc $(dtc-tmp) ; \
+	cat $(depfile).pre $(depfile).dtc > $(depfile)
 
 $(obj)/%.dtb: $(src)/%.dtsp FORCE
 	$(call if_changed_dep,dtc_cpp)
-- 
1.7.10.4



From swarren at wwwdotorg.org  Wed Apr  3 19:34:55 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Wed,  3 Apr 2013 17:34:55 -0600
Subject: [PATCH V2 4/7] kbuild: always run gcc -E on *.dts, remove cmd_dtc_cpp
In-Reply-To: <1365032098-22825-1-git-send-email-swarren@wwwdotorg.org>
References: <1365032098-22825-1-git-send-email-swarren@wwwdotorg.org>
Message-ID: <1365032098-22825-4-git-send-email-swarren@wwwdotorg.org>

From: Stephen Warren <swarren at nvidia.com>

Replace cmd_dtc with cmd_dtc_cpp, and delete the latter.

Previously, a special file extension (.dtsp) was required to trigger
the C pre-processor to run on device tree files. This was ugly. Now that
previous changes have enhanced cmd_dtc_cpp to collect dependency
information from both gcc -E and dtc, we can transparently run the pre-
processor on all device tree files, irrespective of whether they

Signed-off-by: Stephen Warren <swarren at nvidia.com>
---
v2: Add boot/dts from the source tree to dtc include path, so that make
    O= works; that puts the .dts file that's passed to dtc outside the
    source tree, so the include path adjustment is required to find
    include files in the source tree.
---
 scripts/Makefile.lib |   14 +++++---------
 1 file changed, 5 insertions(+), 9 deletions(-)

diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 6104335..3e73dfd 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -269,21 +269,17 @@ $(obj)/%.dtb.S: $(obj)/%.dtb
 	$(call cmd,dt_S_dtb)
 
 quiet_cmd_dtc = DTC     $@
-cmd_dtc = $(objtree)/scripts/dtc/dtc -O dtb -o $@ -b 0 $(DTC_FLAGS) -d $(depfile) $<
+cmd_dtc = $(CPP) $(dtc_cpp_flags) -x assembler-with-cpp -o $(dtc-tmp) $< ; \
+	$(objtree)/scripts/dtc/dtc -O dtb -o $@ -b 0 \
+		-i $(srctree)/arch/$(SRCARCH)/boot/dts $(DTC_FLAGS) \
+		-d $(depfile).dtc $(dtc-tmp) ; \
+	cat $(depfile).pre $(depfile).dtc > $(depfile)
 
 $(obj)/%.dtb: $(src)/%.dts FORCE
 	$(call if_changed_dep,dtc)
 
 dtc-tmp = $(subst $(comma),_,$(dot-target).dts)
 
-quiet_cmd_dtc_cpp = DTC+CPP $@
-cmd_dtc_cpp = $(CPP) $(dtc_cpp_flags) -x assembler-with-cpp -o $(dtc-tmp) $< ; \
-	$(objtree)/scripts/dtc/dtc -O dtb -o $@ -b 0 $(DTC_FLAGS) -d $(depfile).dtc $(dtc-tmp) ; \
-	cat $(depfile).pre $(depfile).dtc > $(depfile)
-
-$(obj)/%.dtb: $(src)/%.dtsp FORCE
-	$(call if_changed_dep,dtc_cpp)
-
 # Bzip2
 # ---------------------------------------------------------------------------
 
-- 
1.7.10.4



From swarren at wwwdotorg.org  Wed Apr  3 19:34:56 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Wed,  3 Apr 2013 17:34:56 -0600
Subject: [PATCH V2 5/7] ARM: dt: add header to define GPIO flags
In-Reply-To: <1365032098-22825-1-git-send-email-swarren@wwwdotorg.org>
References: <1365032098-22825-1-git-send-email-swarren@wwwdotorg.org>
Message-ID: <1365032098-22825-5-git-send-email-swarren@wwwdotorg.org>

From: Stephen Warren <swarren at nvidia.com>

Many GPIO device tree bindings use the same flags. Create a header to
define those.

Signed-off-by: Stephen Warren <swarren at nvidia.com>
---
v2: No change.
v1: Moved header. Added include guard.
    (this patch was previously posted separately, hence there are
    changes in v1!)
---
 include/dt-bindings/gpio/gpio.h |   15 +++++++++++++++
 1 file changed, 15 insertions(+)
 create mode 100644 include/dt-bindings/gpio/gpio.h

diff --git a/include/dt-bindings/gpio/gpio.h b/include/dt-bindings/gpio/gpio.h
new file mode 100644
index 0000000..e6b1e0a
--- /dev/null
+++ b/include/dt-bindings/gpio/gpio.h
@@ -0,0 +1,15 @@
+/*
+ * This header provides constants for most GPIO bindings.
+ *
+ * Most GPIO bindings include a flags cell as part of the GPIO specifier.
+ * In most cases, the format of the flags cell uses the standard values
+ * defined in this header.
+ */
+
+#ifndef _DT_BINDINGS_GPIO_GPIO_H
+#define _DT_BINDINGS_GPIO_GPIO_H
+
+#define GPIO_ACTIVE_HIGH 0
+#define GPIO_ACTIVE_LOW 1
+
+#endif
-- 
1.7.10.4



From swarren at wwwdotorg.org  Wed Apr  3 19:34:57 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Wed,  3 Apr 2013 17:34:57 -0600
Subject: [PATCH V2 6/7] ARM: dt: add header to define IRQ flags
In-Reply-To: <1365032098-22825-1-git-send-email-swarren@wwwdotorg.org>
References: <1365032098-22825-1-git-send-email-swarren@wwwdotorg.org>
Message-ID: <1365032098-22825-6-git-send-email-swarren@wwwdotorg.org>

From: Stephen Warren <swarren at nvidia.com>

Many IRQ device tree bindings use the same flags. Create a header to
define those.

Signed-off-by: Stephen Warren <swarren at nvidia.com>
---
v2: No change.
v1: Moved header. Added include guard.
    (this patch was previously posted separately, hence there are
    changes in v1!)
---
 include/dt-bindings/interrupt-controller/irq.h |   19 +++++++++++++++++++
 1 file changed, 19 insertions(+)
 create mode 100644 include/dt-bindings/interrupt-controller/irq.h

diff --git a/include/dt-bindings/interrupt-controller/irq.h b/include/dt-bindings/interrupt-controller/irq.h
new file mode 100644
index 0000000..33a1003
--- /dev/null
+++ b/include/dt-bindings/interrupt-controller/irq.h
@@ -0,0 +1,19 @@
+/*
+ * This header provides constants for most IRQ bindings.
+ *
+ * Most IRQ bindings include a flags cell as part of the IRQ specifier.
+ * In most cases, the format of the flags cell uses the standard values
+ * defined in this header.
+ */
+
+#ifndef _DT_BINDINGS_INTERRUPT_CONTROLLER_IRQ_H
+#define _DT_BINDINGS_INTERRUPT_CONTROLLER_IRQ_H
+
+#define IRQ_TYPE_NONE		0
+#define IRQ_TYPE_EDGE_RISING	1
+#define IRQ_TYPE_EDGE_FALLING	2
+#define IRQ_TYPE_EDGE_BOTH	(IRQ_TYPE_EDGE_FALLING | IRQ_TYPE_EDGE_RISING)
+#define IRQ_TYPE_LEVEL_HIGH	4
+#define IRQ_TYPE_LEVEL_LOW	8
+
+#endif
-- 
1.7.10.4



From swarren at wwwdotorg.org  Wed Apr  3 19:34:58 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Wed,  3 Apr 2013 17:34:58 -0600
Subject: [PATCH V2 7/7] ARM: dt: create a DT header for the GIC
In-Reply-To: <1365032098-22825-1-git-send-email-swarren@wwwdotorg.org>
References: <1365032098-22825-1-git-send-email-swarren@wwwdotorg.org>
Message-ID: <1365032098-22825-7-git-send-email-swarren@wwwdotorg.org>

From: Stephen Warren <swarren at nvidia.com>

The ARM GIC binding defines a few custom cells and flags for its IRQ
specifier. Provide names for those.

Signed-off-by: Stephen Warren <swarren at nvidia.com>
---
v2: No change.
v1: Moved header. Added include guard.
    (this patch was previously posted separately, hence there are
    changes in v1!)
---
 include/dt-bindings/interrupt-controller/arm-gic.h |   22 ++++++++++++++++++++
 1 file changed, 22 insertions(+)
 create mode 100644 include/dt-bindings/interrupt-controller/arm-gic.h

diff --git a/include/dt-bindings/interrupt-controller/arm-gic.h b/include/dt-bindings/interrupt-controller/arm-gic.h
new file mode 100644
index 0000000..1ea1b70
--- /dev/null
+++ b/include/dt-bindings/interrupt-controller/arm-gic.h
@@ -0,0 +1,22 @@
+/*
+ * This header provides constants for the ARM GIC.
+ */
+
+#ifndef _DT_BINDINGS_INTERRUPT_CONTROLLER_ARM_GIC_H
+#define _DT_BINDINGS_INTERRUPT_CONTROLLER_ARM_GIC_H
+
+#include <dt-bindings/interrupt-controller/irq.h>
+
+/* interrupt specific cell 0 */
+
+#define GIC_SPI 0
+#define GIC_PPI 1
+
+/*
+ * Interrupt specifier cell 2.
+ * The flaggs in irq.h are valid, plus those below.
+ */
+#define GIC_CPU_MASK_RAW(x) ((x) << 8)
+#define GIC_CPU_MASK_SIMPLE(num) GIC_CPU_MASK_RAW((1 << (num)) - 1)
+
+#endif
-- 
1.7.10.4



From cdall at cs.columbia.edu  Wed Apr  3 19:39:27 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Wed, 3 Apr 2013 16:39:27 -0700
Subject: [PATCH 2/5] ARM: KVM: arch_timers: zero CNTVOFF upon return to
 host
In-Reply-To: <1364404312-4427-3-git-send-email-mark.rutland@arm.com>
References: <1364404312-4427-1-git-send-email-mark.rutland@arm.com>
 <1364404312-4427-3-git-send-email-mark.rutland@arm.com>
Message-ID: <CAEDV+gKmi16juPvQUO46eMVwtNMR+q4ce8ND_yVM4_O8iOYUXw@mail.gmail.com>

On Wed, Mar 27, 2013 at 10:11 AM, Mark Rutland <mark.rutland at arm.com> wrote:
> To use the virtual counters from the host, we need to ensure that
> CNTVOFF doesn't change unexpectedly. When we change to a guest, we
> replace the host's CNTVOFF, but we don't restore it when returning to
> the host.
>
> As the host sets CNTVOFF to zero, and never changes it, we can simply
> zero CNTVOFF when returning to the host. This patch adds said zeroing to
> the return to host path.
>
> Signed-off-by: Mark Rutland <mark.rutland at arm.com>
> Acked-by: Marc Zyngier <marc.zyngier at arm.com>
> Cc: Christoffer Dall <cdall at cs.columbia.edu>
> ---
>  arch/arm/kvm/interrupts_head.S | 4 ++++
>  1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm/kvm/interrupts_head.S b/arch/arm/kvm/interrupts_head.S
> index 3c8f2f0..d43cfb5 100644
> --- a/arch/arm/kvm/interrupts_head.S
> +++ b/arch/arm/kvm/interrupts_head.S
> @@ -497,6 +497,10 @@ vcpu       .req    r0              @ vcpu pointer always in r0
>         add     r5, vcpu, r4
>         strd    r2, r3, [r5]
>
> +       @ Ensure host CNTVCT == CNTPCT
> +       mov     r2, #0
> +       mcrr    p15, 4, r2, r2, c14     @ CNTVOFF
> +
>  1:
>  #endif
>         @ Allow physical timer/counter access for the host
> --
> 1.8.1.1
>
>

looks good to me.

Merged into kvm-arm-fixes.

-Christoffer


From swarren at wwwdotorg.org  Wed Apr  3 19:42:41 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Wed, 03 Apr 2013 17:42:41 -0600
Subject: [PATCH v5 0/6] Generic PHY Framework
In-Reply-To: <1364993634-6378-1-git-send-email-kishon@ti.com>
References: <1364993634-6378-1-git-send-email-kishon@ti.com>
Message-ID: <515CBE71.9000401@wwwdotorg.org>

On 04/03/2013 06:53 AM, Kishon Vijay Abraham I wrote:
> Added a generic PHY framework that provides a set of APIs for the PHY drivers
> to create/destroy a PHY and APIs for the PHY users to obtain a reference to
> the PHY with or without using phandle. To obtain a reference to the PHY
> without using phandle, the platform specfic intialization code (say from board
> file) should have already called phy_bind with the binding information. The
> binding information consists of phy's device name, phy user device name and an
> index. The index is used when the same phy user binds to mulitple phys.
...
> Changes from v4:
> * removed of_phy_get_with_args/devm_of_phy_get_with_args. Now the *phy providers*
>   should use their custom implementation of of_xlate or use of_phy_xlate to get
>   *phy instance* from *phy providers*.
> * Added of_phy_xlate to be used by *phy providers* if it provides only one PHY.
> * changed phy_core from having subsys_initcall to module_init.

s/of_phy_xlate/of_phy_simple_xlate/ ? That would hightlight the fact
it's just /an/ implementation for the simple case, not /the/
implementation for all cases. It'd be consistent with e.g. drivers/gpio,
which has of_gpio_simple_xlate().


From tony at atomide.com  Wed Apr  3 19:42:43 2013
From: tony at atomide.com (Tony Lindgren)
Date: Wed, 3 Apr 2013 16:42:43 -0700
Subject: [RFC][PATCH 1/2] ARM: OMAP4: clock: Add device tree support
 for AUXCLKs
In-Reply-To: <1363703220-4777-2-git-send-email-rogerq@ti.com>
References: <1363703220-4777-1-git-send-email-rogerq@ti.com>
 <1363703220-4777-2-git-send-email-rogerq@ti.com>
Message-ID: <20130403234242.GE10155@atomide.com>

Hi,

* Roger Quadros <rogerq at ti.com> [130319 07:31]:
> Register a device tree clock provider for AUX clocks
> on the OMAP4 SoC. Also provide the binding information.
> 
> Signed-off-by: Roger Quadros <rogerq at ti.com>
> ---
>  .../devicetree/bindings/clock/omap4-clock.txt      |   32 ++++++++++++++++++
>  arch/arm/boot/dts/omap4.dtsi                       |    5 +++
>  arch/arm/mach-omap2/board-generic.c                |    2 +-
>  arch/arm/mach-omap2/cclock44xx_data.c              |   35 ++++++++++++++++++++
>  arch/arm/mach-omap2/clock44xx.h                    |    1 +
>  arch/arm/mach-omap2/common.h                       |    9 +++++
>  arch/arm/mach-omap2/io.c                           |    6 +++
>  7 files changed, 89 insertions(+), 1 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/clock/omap4-clock.txt
> 
...

> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/omap4-clock.txt

Is this really specific to omap4 and auxclk only?

Shouldn't it be just omap-clock.txt?

> --- a/arch/arm/mach-omap2/cclock44xx_data.c
> +++ b/arch/arm/mach-omap2/cclock44xx_data.c
> @@ -27,6 +27,7 @@
>  #include <linux/clk-private.h>
>  #include <linux/clkdev.h>
>  #include <linux/io.h>
> +#include <linux/of.h>
>  
>  #include "soc.h"
>  #include "iomap.h"
> @@ -1663,6 +1664,40 @@ static struct omap_clk omap44xx_clks[] = {
>  	CLK(NULL,	"cpufreq_ck",	&dpll_mpu_ck,	CK_443X),
>  };
>  
> +static struct clk *scrm_clks[] = {
> +	&auxclk0_ck,
> +	&auxclk1_ck,
> +	&auxclk2_ck,
> +	&auxclk3_ck,
> +	&auxclk4_ck,
> +	&auxclk5_ck,
> +};

Hmm I don't like the idea of specifying the auxclk both in the
cclock44xx_data.c and in DT..

> +static struct clk_onecell_data scrm_data;
> +
> +#ifdef CONFIG_OF
> +int __init omap4_clk_init_dt(void)
> +{
> +	struct device_node *np;
> +
> +	np = of_find_compatible_node(NULL, NULL, "ti,omap4-scrm");
> +	if (np) {
> +		scrm_data.clks = scrm_clks;
> +		scrm_data.clk_num = ARRAY_SIZE(scrm_clks);
> +		of_clk_add_provider(np, of_clk_src_onecell_get,	&scrm_data);
> +	}
> +
> +	return 0;
> +}
> +
> +#else
> +
> +int __init omap4_clk_init_dt(void)
> +{
> +	return 0;
> +}
> +#endif /* CONFIG_OF */
> +
>  int __init omap4xxx_clk_init(void)
>  {
>  	u32 cpu_clkflg;

.. and I'm not too keen on adding driver specific stuff to this file.

How about just add a minimal drivers/clk/omap/clk-xyz.c that takes
the configuration from DT and is based on the binding we already have in
Documentation/devicetree/bindings/clock/clock-bindings.txt?

Then as we add new bindings there we can drop them from current
cclock44xx_data.c, no? That is after omap4 is DT only..

Regards,

Tony


From cdall at cs.columbia.edu  Wed Apr  3 19:47:12 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Wed, 3 Apr 2013 16:47:12 -0700
Subject: [PATCH] arm: kvm: arch_timer: use symbolic constants
In-Reply-To: <1364399771-21456-1-git-send-email-mark.rutland@arm.com>
References: <1364399771-21456-1-git-send-email-mark.rutland@arm.com>
Message-ID: <20130403234712.GA1038@gmail.com>

On Wed, Mar 27, 2013 at 03:56:11PM +0000, Mark Rutland wrote:
> In clocksource/arm_arch_timer.h we define useful symbolic constants.
> Let's use them to make the KVM arch_timer code clearer.
> 
> Signed-off-by: Mark Rutland <mark.rutland at arm.com>
> Acked-by: Marc Zyngier <marc.zyngier at arm.com>
> Cc: Christoffer Dall <cdall at cs.columbia.edu>
> ---
>  arch/arm/kvm/arch_timer.c | 7 ++++---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/kvm/arch_timer.c b/arch/arm/kvm/arch_timer.c
> index 6ac938d..c55b608 100644
> --- a/arch/arm/kvm/arch_timer.c
> +++ b/arch/arm/kvm/arch_timer.c
> @@ -22,6 +22,7 @@
>  #include <linux/kvm_host.h>
>  #include <linux/interrupt.h>
>  
> +#include <clocksource/arm_arch_timer.h>
>  #include <asm/arch_timer.h>
>  
>  #include <asm/kvm_vgic.h>
> @@ -64,7 +65,7 @@ static void kvm_timer_inject_irq(struct kvm_vcpu *vcpu)
>  {
>  	struct arch_timer_cpu *timer = &vcpu->arch.timer_cpu;
>  
> -	timer->cntv_ctl |= 1 << 1; /* Mask the interrupt in the guest */
> +	timer->cntv_ctl |= ARCH_TIMER_CTRL_IT_MASK;
>  	kvm_vgic_inject_irq(vcpu->kvm, vcpu->vcpu_id,
>  			    vcpu->arch.timer_cpu.irq->irq,
>  			    vcpu->arch.timer_cpu.irq->level);
> @@ -133,8 +134,8 @@ void kvm_timer_sync_hwstate(struct kvm_vcpu *vcpu)
>  	cycle_t cval, now;
>  	u64 ns;
>  
> -	/* Check if the timer is enabled and unmasked first */
> -	if ((timer->cntv_ctl & 3) != 1)
> +	if ((timer->cntv_ctl & ARCH_TIMER_CTRL_IT_MASK) ||
> +		!(timer->cntv_ctl & ARCH_TIMER_CTRL_ENABLE))
>  		return;
>  
>  	cval = timer->cntv_cval;
> -- 
> 1.8.1.1
> 
> 

Looks good, I've merged it into kvm-arm-next.

-Christoffer


From swarren at wwwdotorg.org  Wed Apr  3 19:54:11 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Wed, 03 Apr 2013 17:54:11 -0600
Subject: [PATCH v5 1/6] drivers: phy: add generic PHY framework
In-Reply-To: <1364993634-6378-2-git-send-email-kishon@ti.com>
References: <1364993634-6378-1-git-send-email-kishon@ti.com>
 <1364993634-6378-2-git-send-email-kishon@ti.com>
Message-ID: <515CC123.4060402@wwwdotorg.org>

On 04/03/2013 06:53 AM, Kishon Vijay Abraham I wrote:
> The PHY framework provides a set of APIs for the PHY drivers to
> create/destroy a PHY and APIs for the PHY users to obtain a reference to the
> PHY with or without using phandle. To obtain a reference to the PHY without
> using phandle, the platform specfic intialization code (say from board file)
> should have already called phy_bind with the binding information. The binding
> information consists of phy's device name, phy user device name and an index.
> The index is used when the same phy user binds to mulitple phys.
> 
> PHY drivers should create the PHY by passing phy_descriptor that has
> describes the PHY (label, type etc..) and ops like init, exit, suspend, resume,
> power_on, power_off.
> 
> The documentation for the generic PHY framework is added in
> Documentation/phy.txt and the documentation for the sysfs entry is added
> in Documentation/ABI/testing/sysfs-class-phy and the documentation for
> dt binding is can be found at
> Documentation/devicetree/bindings/phy/phy-bindings.txt

> diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h

> +extern struct phy *devm_phy_create(struct device *dev, const char *label,
> +	struct device_node *of_node, int type, struct phy_ops *ops,
> +	void *priv);

Can't the function get of_node from dev->of_node?

I wonder if we shouldn't split up the registration a bit though:

A function which registers a PHY object itself. That's the function above.

A function which registers a DT-based PHY provider.

Then, the of_xlate op would be part of the PHY provider, not part of
some random PHY that happens to exist on that node. So:

struct phy {
	struct device *dev;
	struct module *owner;
	int	(*init)(struct phy *phy);
	int	(*exit)(struct phy *phy);
	int	(*suspend)(struct phy *phy);
	int	(*resume)(struct phy *phy);
	int	(*power_on)(struct phy *phy);
	int	(*power_off)(struct phy *phy);
};

int phy_register(struct phy *phy);

All PHY providers would use that API, whether running in a DT-base
system or not.

struct of_phy_provider {
	struct device *dev;
	struct phy * (*of_xlate)(struct of_phy_provider *provider,
			struct of_phandle_args *args);
};

int phy_register_of_provider(struct of_phy_provider *provider);

Only DT-based PHY providers would use that API.

... or something like that?

phy_get() would do something like:

	if dev->of_node:
		# look up using registerd of_phy_providers
		phy = phy_get_of(...)
		if phy: return phy
	# now look up using whatever other mapping table exists
	phy = ...
	return phy



From emilio at elopez.com.ar  Wed Apr  3 20:02:31 2013
From: emilio at elopez.com.ar (=?ISO-8859-1?Q?Emilio_L=F3pez?=)
Date: Wed, 03 Apr 2013 21:02:31 -0300
Subject: [PATCH V2 4/7] kbuild: always run gcc -E on *.dts,
 remove cmd_dtc_cpp
In-Reply-To: <1365032098-22825-4-git-send-email-swarren@wwwdotorg.org>
References: <1365032098-22825-1-git-send-email-swarren@wwwdotorg.org>
 <1365032098-22825-4-git-send-email-swarren@wwwdotorg.org>
Message-ID: <515CC317.2000703@elopez.com.ar>

Hi Stephen,

El 03/04/13 20:34, Stephen Warren escribi?:
> From: Stephen Warren <swarren at nvidia.com>
> 
> Replace cmd_dtc with cmd_dtc_cpp, and delete the latter.
> 
> Previously, a special file extension (.dtsp) was required to trigger
> the C pre-processor to run on device tree files. This was ugly. Now that
> previous changes have enhanced cmd_dtc_cpp to collect dependency
> information from both gcc -E and dtc, we can transparently run the pre-
> processor on all device tree files, irrespective of whether they
> 

I think a line got dropped on the commit description by mistake.

Regards,

Emilio


From kuninori.morimoto.gx at renesas.com  Wed Apr  3 20:27:02 2013
From: kuninori.morimoto.gx at renesas.com (Kuninori Morimoto)
Date: Wed, 03 Apr 2013 17:27:02 -0700 (PDT)
Subject: [PATCH/RFC 2/3] ARM: shmobile: initialise clock early on
 kzm9g-reference
In-Reply-To: <1365005636-17526-3-git-send-email-g.liakhovetski@gmx.de>
References: <1365005636-17526-1-git-send-email-g.liakhovetski@gmx.de>
 <1365005636-17526-3-git-send-email-g.liakhovetski@gmx.de>
Message-ID: <87zjxfdtt8.wl%kuninori.morimoto.gx@renesas.com>


Hi Guennadi

> To prepare to enable TWD on kzm9g-reference, clock initialisation has to be
> done early. Move it from .init_machine to .init_time stage.
> 
> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas at gmail.com>
> ---
(snip)
> +static void __init timer_init(void)
> +{
> +	sh73a0_clock_init();
> +	shmobile_timer_init();
> +}

I'm not sure detail,
but, shmobile_timer_init() will be removed.

Can you check these patch/email on SH-ML or ARM ML ?

Subject: [PATCH v2 02/13] ARM: convert arm/arm64 arch timer to use CLKSRC_OF init
Date:	Mon,  1 Apr 2013 17:21:12 -0500

Subject: [PATCH v2 02/13] ARM: convert arm/arm64 arch timer to use CLKSRC_OF init
Date:	Mon,  1 Apr 2013 17:21:12 -0500



Best regards
---
Kuninori Morimoto


From kgene.kim at samsung.com  Wed Apr  3 20:36:48 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Thu, 04 Apr 2013 09:36:48 +0900
Subject: [PATCH 00/21] Various fixes and extensions to Exynos4 clock
 driver
In-Reply-To: <20130403220118.3383.10734@quantum>
References: <1364382178-25248-1-git-send-email-t.figa@samsung.com>
 <CAJuYYwQap4pZ6qTgBPGeSWbMFm-ZhqLfv7wBMVYjK1v0YHr_kQ@mail.gmail.com>
 <1496108.NDegb7PXrt@flatron> <22e101ce2f7c$5b6a0cd0$123e2670$%kim@samsung.com>
 <20130403220118.3383.10734@quantum>
Message-ID: <26e501ce30cc$7e4d4d60$7ae7e820$%kim@samsung.com>

Mike Turquette wrote:
> 
> Quoting Kukjin Kim (2013-04-02 01:30:39)
> > Tomasz Figa wrote:
> > >
> > > On Saturday 30 of March 2013 15:33:00 Thomas Abraham wrote:
> > > > Hi Tomasz,
> > > >
> > > > On 27 March 2013 16:32, Tomasz Figa <t.figa at samsung.com> wrote:
> > > > > This series is a collection of various fixes and extensions to
> Exynos4
> > > > > clock driver, which improve coverage of clocks present on Exynos4
> SoCs
> > > > > and fix problems discovered during our internal work and testing.
> > > >
> > > > Nice series. Thanks for the improvements and fixes. Looking at the
> > > > second patch in this series, I crossed checked again with the
> > > > Exynos4412 user manual that I have. Your modifications are different
> > > > from what the manual has listed. I suspect, you have a newer copy of
> > > > the manual.
> > >
> > > Right. I have checked revisions 0.0, 0.1 and 1.1 of the manual and
> indeed
> > > there are differences in clock layout between 0.1 and 1.1. My patches
> are
> > > based on revision 1.1.
> > >
> > Correct...hmm...
> >
> > > > For this series:
> > > > Reviewed-by: Thomas Abraham <thomas.abraham at linaro.org>
> > >
> > Yes, looks good to me but would be better if I could get Mike's ack on
> this
> > series.
> >
> 
> Acked-by: Mike Turquette <mturquette at linaro.org>
> 
Thanks, applied.

- Kukjin



From mturquette at linaro.org  Wed Apr  3 20:49:10 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Wed, 03 Apr 2013 17:49:10 -0700
Subject: [PATCH 4/6] pinctrl: sunxi: add clock support
In-Reply-To: <515C9D25.3050407@free-electrons.com>
References: <1363962042-29536-1-git-send-email-emilio@elopez.com.ar>
 <1363962042-29536-5-git-send-email-emilio@elopez.com.ar>
 <CACRpkdbn9c_bAWUN8hTLkeidCnyZ=0nRQRBV39DMkK_0jBfoUQ@mail.gmail.com>
 <51535077.1050203@free-electrons.com>
 <CACRpkda80EKT2LbsBCOng=gkdtdd+vbYwkMPiFZUBx7z_aqY+A@mail.gmail.com>
 <515C9D25.3050407@free-electrons.com>
Message-ID: <20130404004910.3383.10381@quantum>

Quoting Maxime Ripard (2013-04-03 14:20:37)
> Hi Linus,
> 
> Le 03/04/2013 13:59, Linus Walleij a ?crit :
> > On Wed, Mar 27, 2013 at 9:03 PM, Maxime Ripard
> > <maxime.ripard at free-electrons.com> wrote:
> > 
> >> Hi Linus,
> >> Le 27/03/2013 14:14, Linus Walleij a ?crit :
> >>> On Fri, Mar 22, 2013 at 3:20 PM, Emilio L?pez <emilio at elopez.com.ar> wrote:
> >>>
> >>>> For the port controller to work, we need to enable the apb0_pio gate.
> >>>> This commit adds the ability to enable one clock specified on the device
> >>>> tree to the pinctrl driver.
> >>>>
> >>>> Signed-off-by: Emilio L?pez <emilio at elopez.com.ar>
> >>>
> >>> Acked-by: Linus Walleij <linus.walleij at linaro.org>
> >>>
> >>> I guess you'll want to merge these as one series to some platform-specific
> >>> tree, tell me if you want it merged in the pinctrl tree.
> >>
> >> The easiest would probably be to merge this patch through your patch,
> >> with Mike taking the clock driver patches and me taking the dt ones,
> >> once we agree on the other patches.
> > 
> > OK then, patch applied to the pinctrl tree, thanks!
> 
> Ouch, the previous patches aren't applied yet by Mike, and we didn't
> have some comments from him about these patches, so I can't really say
> if the previous patches will get merge by 3.10 or not... So we will
> maybe end up with a broken pinctrl stuff.
> 
> Mike, do you have some comments on Emilio's patches?
> 
> If you do, we can still fix things up later by applying a slightly
> modified version of patches 5/6 with a clock that is already there, for
> it to load properly.
> 

Hi Maxime,

I did leave some comments a few hours ago.  It would be better if the
fixes could be rolled in now, but if that is somehow impossible then I
don't mind taking them as-is with fixes at a later date.  Just let me
know.

Regards,
Mike

> Thanks,
> Maxime
> 
> -- 
> Maxime Ripard, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com


From jg1.han at samsung.com  Wed Apr  3 20:57:34 2013
From: jg1.han at samsung.com (Jingoo Han)
Date: Thu, 04 Apr 2013 09:57:34 +0900
Subject: [PATCH v3] of/pci: Provide support for parsing PCI DT ranges
 property
In-Reply-To: <20130327130418.GA10480@avionic-0098.mockup.avionic-design.de>
References: <20130326162022.GA25625@arm.com>
 <20130327130418.GA10480@avionic-0098.mockup.avionic-design.de>
Message-ID: <002b01ce30cf$64da6180$2e8f2480$%han@samsung.com>

On Wednesday, March 27, 2013 10:04 PM, Thierry Reding wrote:
> 
> On Tue, Mar 26, 2013 at 04:20:23PM +0000, Andrew Murray wrote:
> > This patch factors out common implementation patterns to reduce overall kernel
> > code and provide a means for host bridge drivers to directly obtain struct
> > resources from the DT's ranges property without relying on architecture specific
> > DT handling. This will make it easier to write archiecture independent host bridge
> > drivers and mitigate against further duplication of DT parsing code.
> >
> > This patch can be used in the following way:
> >
> > 	struct of_pci_range_parser parser;
> > 	struct of_pci_range range;
> >
> > 	if (of_pci_range_parser(&parser, np))
> > 		; //no ranges property
> >
> > 	for_each_of_pci_range(&parser, &range) {
> >
> > 		/*
> > 			directly access properties of the address range, e.g.:
> > 			range.pci_space, range.pci_addr, range.cpu_addr,
> > 			range.size, range.flags
> >
> > 			alternatively obtain a struct resource, e.g.:
> > 			struct resource res;
> > 			of_pci_range_to_resource(&range, np, &res);
> > 		*/
> > 	}
> >
> > Additionally the implementation takes care of adjacent ranges and merges them
> > into a single range (as was the case with powerpc and microblaze).
> >
> > The modifications to microblaze, mips and powerpc have not been tested.
> >
> > Signed-off-by: Andrew Murray <Andrew.Murray at arm.com>
> > Signed-off-by: Liviu Dudau <Liviu.Dudau at arm.com>
> > Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> 
> Tested-by: Thierry Reding <thierry.reding at avionic-design.de>

It works properly with Exynos5440.

Tested-by: Jingoo Han <jg1.han at samsung.com>





From kgene.kim at samsung.com  Wed Apr  3 21:01:48 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Thu, 04 Apr 2013 10:01:48 +0900
Subject: [PATCH 4/4] ARM: s3c24xx: Fix switching FIFO in
 arch_enable_uart_fifo function
In-Reply-To: <1362216174-10478-4-git-send-email-shc_work@mail.ru>
References: <1362216174-10478-1-git-send-email-shc_work@mail.ru>
 <1362216174-10478-4-git-send-email-shc_work@mail.ru>
Message-ID: <26f001ce30cf$fbfb3170$f3f19450$%kim@samsung.com>

Alexander Shiyan wrote:
> 
> When CONFIG_S3C_BOOT_UART_FORCE_FIFO symbol is set, we should
> enable FIFO but actually switch command is missing in the code.
> This patch adds this switch.
> 
> Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
> ---
>  arch/arm/plat-samsung/include/plat/uncompress.h | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/arch/arm/plat-samsung/include/plat/uncompress.h
> b/arch/arm/plat-samsung/include/plat/uncompress.h
> index 438b248..30fedd9 100644
> --- a/arch/arm/plat-samsung/include/plat/uncompress.h
> +++ b/arch/arm/plat-samsung/include/plat/uncompress.h
> @@ -130,6 +130,8 @@ static inline void arch_enable_uart_fifo(void)
>  			if (!(fifocon & S3C2410_UFCON_RESETBOTH))
>  				break;
>  		}
> +
> +		uart_wr(S3C2410_UFCON, S3C2410_UFCON_FIFOMODE);

Well, I think, if required, this should be moved into 'if (!(fifocon &
S3C2410_UFCON_FIFOMODE))'.

- Kukjin



From kgene.kim at samsung.com  Wed Apr  3 21:02:00 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Thu, 04 Apr 2013 10:02:00 +0900
Subject: [PATCH 1/4] ARM: s3c24xx: Removed unneeded dependency on
 ARCH_S3C24XX for boards
In-Reply-To: <1362225644.599345374@f82.mail.ru>
References: <1362216174-10478-1-git-send-email-shc_work@mail.ru>
 <201303021143.38390.arnd@arndb.de> <1362225644.599345374@f82.mail.ru>
Message-ID: <26f101ce30d0$0374a530$0a5def90$%kim@samsung.com>

Alexander Shiyan wrote:
> 
> > On Saturday 02 March 2013, Alexander Shiyan wrote:
> > > Board options are already under "if ARCH_S3C24XX" condition, so
> > > additional dependencies on this symbol can be removed.
> > >
> > > Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
> >
> > Hi Alexander,
> >
> > Is this just a cosmetic change that has no other consequences, or do you
> > have other follow-up patches that depend on patches 1-3?
> 
> Hello Arnd.
> Nothing more yet. Perhaps I'll do a merging some parts of the code for
> different versions of the CPU into one unit and some future changes
> may remove some Kconfig symbols, so it is only initial Kconfig cleaning.
> Thanks.
> 
Looks good to me on patches 1-3 but for 4th patch, see my comments on that.

Applied 1-3 patches, thanks.

- Kukjin



From emilio at elopez.com.ar  Wed Apr  3 21:19:22 2013
From: emilio at elopez.com.ar (=?UTF-8?B?RW1pbGlvIEzDs3Bleg==?=)
Date: Wed, 03 Apr 2013 22:19:22 -0300
Subject: [PATCH v2 1/7] clk: sunxi: Add support for AXI, AHB, APB0 and
 APB1 gates
In-Reply-To: <20130403214815.3383.60153@quantum>
References: <1363962042-29536-1-git-send-email-emilio@elopez.com.ar>
 <1364419243-18446-1-git-send-email-emilio@elopez.com.ar>
 <1364419243-18446-2-git-send-email-emilio@elopez.com.ar>
 <20130403214815.3383.60153@quantum>
Message-ID: <515CD51A.2070503@elopez.com.ar>

Hi Mike,

El 03/04/13 18:48, Mike Turquette escribi?:
> Quoting Emilio L?pez (2013-03-27 14:20:37)
>> diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
>> index d528a24..244de90 100644
>> --- a/drivers/clk/sunxi/clk-sunxi.c
>> +++ b/drivers/clk/sunxi/clk-sunxi.c
>> @@ -302,6 +302,82 @@ static void __init sunxi_divider_clk_setup(struct device_node *node,
>>  }
>>  
>>  
>> +
> 
> A lot of white space between these functions.

All of the function blocks are separated with three spaces on the file;
I thought it looked more readable that way, but I don't have any strong
opinion on separation. Is there any standard for this used on the kernel?

In any case, and to keep consistency, can we handle this on a follow-up
patch?

>> +/**
>> + * sunxi_gates_clk_setup() - Setup function for leaf gates on clocks
>> + */
>> +
>> +#define SUNXI_GATES_MAX_SIZE   64
>> +
>> +struct gates_data {
>> +       DECLARE_BITMAP(mask, SUNXI_GATES_MAX_SIZE);
>> +};
>> +
>> +static const __initconst struct gates_data axi_gates_data = {
>> +       .mask = {1},
>> +};
>> +
>> +static const __initconst struct gates_data ahb_gates_data = {
>> +       .mask = {0x7F77FFF, 0x14FB3F},
>> +};
>> +
>> +static const __initconst struct gates_data apb0_gates_data = {
>> +       .mask = {0x4EF},
>> +};
>> +
>> +static const __initconst struct gates_data apb1_gates_data = {
>> +       .mask = {0xFF00F7},
>> +};
>> +
>> +static void __init sunxi_gates_clk_setup(struct device_node *node,
>> +                                        struct gates_data *data)
>> +{
>> +       struct clk_onecell_data *clk_data;
>> +       const char *clk_parent;
>> +       const char *clk_name;
>> +       void *reg;
>> +       int qty;
>> +       int i = 0;
>> +       int j = 0;
>> +       int ignore;
>> +
>> +       reg = of_iomap(node, 0);
>> +
>> +       clk_parent = of_clk_get_parent_name(node, 0);
>> +
>> +       /* Worst-case size approximation and memory allocation */
>> +       qty = find_last_bit(data->mask, SUNXI_GATES_MAX_SIZE);
>> +       clk_data = kmalloc(sizeof(struct clk_onecell_data), GFP_KERNEL);
>> +       if (!clk_data)
>> +               return;
>> +       clk_data->clks = kzalloc((qty+1) * sizeof(struct clk *), GFP_KERNEL);
>> +       if (!clk_data->clks) {
>> +               kfree(clk_data);
>> +               return;
>> +       }
>> +
>> +       for_each_set_bit(i, data->mask, SUNXI_GATES_MAX_SIZE) {
>> +               of_property_read_string_index(node, "clock-output-names",
>> +                                             j, &clk_name);
>> +
>> +               /* No driver claims this clock, but it should remain gated */
> 
> Should the comment read, "ungated" instead of "gated"?

Indeed, good catch. Do you want me to resend the series, or can you
amend this when picking the patches?

>> +               ignore = !strcmp("ahb_sdram", clk_name) ? CLK_IGNORE_UNUSED : 0;
>> +
>> +               clk_data->clks[i] = clk_register_gate(NULL, clk_name,
>> +                                                     clk_parent, ignore,
>> +                                                     reg + 4 * (i/32), i % 32,
>> +                                                     0, &clk_lock);
>> +               WARN_ON(IS_ERR(clk_data->clks[i]));
>> +
>> +               j++;
>> +       }
>> +
>> +       /* Adjust to the real max */
>> +       clk_data->clk_num = i;
>> +
>> +       of_clk_add_provider(node, of_clk_src_onecell_get, clk_data);
>> +}
>> +
>>  /* Matches for of_clk_init */
>>  static const __initconst struct of_device_id clk_match[] = {
>>         {.compatible = "fixed-clock", .data = of_fixed_clk_setup,},
>> @@ -331,6 +407,15 @@ static const __initconst struct of_device_id clk_mux_match[] = {
>>         {}
>>  };
>>  
>> +/* Matches for gate clocks */
>> +static const __initconst struct of_device_id clk_gates_match[] = {
>> +       {.compatible = "allwinner,sun4i-axi-gates-clk", .data = &axi_gates_data,},
>> +       {.compatible = "allwinner,sun4i-ahb-gates-clk", .data = &ahb_gates_data,},
>> +       {.compatible = "allwinner,sun4i-apb0-gates-clk", .data = &apb0_gates_data,},
>> +       {.compatible = "allwinner,sun4i-apb1-gates-clk", .data = &apb1_gates_data,},
>> +       {}
>> +};
>> +
>>  static void __init of_sunxi_table_clock_setup(const struct of_device_id *clk_match,
>>                                               void *function)
>>  {
>> @@ -359,4 +444,7 @@ void __init sunxi_init_clocks(void)
>>  
>>         /* Register mux clocks */
>>         of_sunxi_table_clock_setup(clk_mux_match, sunxi_mux_clk_setup);
>> +
>> +       /* Register gate clocks */
>> +       of_sunxi_table_clock_setup(clk_gates_match, sunxi_gates_clk_setup);
> 
> I'm still a device tree noob, so this may be a dumb question.  Can the
> above be converted to of_clk_init?

As far as I know, you can't, because of_clk_init doesn't allow for
custom data to be passed to the functions. If we were to use of_clk_init
we would need one function per clock, and it would be mostly duplicated
code / wrappers. I've added Gregory on Cc, please correct me if this is
not the case.

Thanks for the review,

Emilio


From Milo.Kim at ti.com  Wed Apr  3 21:34:37 2013
From: Milo.Kim at ti.com (Kim, Milo)
Date: Thu, 4 Apr 2013 01:34:37 +0000
Subject: [PATCH v2] clk: add LP8788 clock driver
Message-ID: <A874F61F95741C4A9BA573A70FE3998F82E4AB29@DQHE02.ent.ti.com>

LP8788 PMU consists of regulator, battery charger, RTC, ADC, backlight driver
and current sinks.
Here is additional driver, clock.

* Clock source
LP8788 clock is generated by two clock source.
One is internal oscillator. The other is attached external crystal oscillator.
LP8788 provides automatic clock source selection through the I2C register.
This operation is executed in 'prepare' of common clock driver architecture.

* Clock rate
LP8788 generates a fixed 32768Hz clock which is used for the system.

* Supported operations
.prepare: Before the clock is enabled, automatic clock source selection is done
          by register access.
.unprepare: No register for disable or remove the clock source, so do nothing.
.recalc_rate: Fixed clock rate, 32.768KHz.

* clk_register_fixed_rate() vs devm_clk_register() and clkdev_add()
Fixed clock driver can be created by common clock helper function but
but LP8788 should be built as a module.
Using devm_clk_register() and clkdev_add() is more appropriate method to
implement LP8788 clock driver.

Patch v2.
  (a) Remove unnecessary 'is_enabled()' operation code.
  (b) Add CLK_IGNORE_UNUSED flag.
  (c) Add clock device detection code : lp8788_is_clk_device_ready()
      If the device is not ready, return as -ENODEV on loading the driver.

Patch v1.
  Initial patch

Signed-off-by: Milo(Woogyom) Kim <milo.kim at ti.com>
---
 drivers/clk/Kconfig        |    7 ++
 drivers/clk/Makefile       |    1 +
 drivers/clk/clk-lp8788.c   |  160 ++++++++++++++++++++++++++++++++++++++++++++
 drivers/mfd/lp8788.c       |    2 +
 include/linux/mfd/lp8788.h |    1 +
 5 files changed, 171 insertions(+)
 create mode 100644 drivers/clk/clk-lp8788.c

diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index a64caef..4b5109c 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -71,6 +71,13 @@ config COMMON_CLK_AXI_CLKGEN
 	  Support for the Analog Devices axi-clkgen pcore clock generator for Xilinx
 	  FPGAs. It is commonly used in Analog Devices' reference designs.
 
+config CLK_LP8788
+	tristate "Clock driver for TI LP8788 PMU"
+	depends on MFD_LP8788
+	---help---
+	  Supports the clock subsystem of TI LP8788. It generates the 32KHz
+	  clock output.
+
 endmenu
 
 source "drivers/clk/mvebu/Kconfig"
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 79e98e4..98f3883 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -37,3 +37,4 @@ obj-$(CONFIG_COMMON_CLK_AXI_CLKGEN) += clk-axi-clkgen.o
 obj-$(CONFIG_COMMON_CLK_WM831X) += clk-wm831x.o
 obj-$(CONFIG_COMMON_CLK_MAX77686) += clk-max77686.o
 obj-$(CONFIG_CLK_TWL6040)	+= clk-twl6040.o
+obj-$(CONFIG_CLK_LP8788)	+= clk-lp8788.o
diff --git a/drivers/clk/clk-lp8788.c b/drivers/clk/clk-lp8788.c
new file mode 100644
index 0000000..c636fd7
--- /dev/null
+++ b/drivers/clk/clk-lp8788.c
@@ -0,0 +1,160 @@
+/*
+ * TI LP8788 Clock Driver
+ *
+ * Copyright 2013 Texas Instruments
+ *
+ * Author: Milo(Woogyom) Kim <milo.kim at 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/clk.h>
+#include <linux/clkdev.h>
+#include <linux/clk-provider.h>
+#include <linux/mfd/lp8788.h>
+#include <linux/module.h>
+#include <linux/slab.h>
+#include <linux/platform_device.h>
+
+/* Registers */
+#define LP8788_REG_STATUS		0x06
+#define LP8788_OSC_WORKING		0x10
+
+#define LP8788_REG_CLKCTRL		0xA2
+#define LP8788_CLKMODE_MASK		0x02
+#define LP8788_CLKMODE_AUTO		0X02
+
+#define CLKOUT_32KHZ			32768
+
+struct lp8788_clk {
+	struct lp8788 *lp;
+	struct clk *clk;
+	struct clk_hw hw;
+	struct clk_lookup *lookup;
+};
+
+static int lp8788_clk_prepare(struct clk_hw *hw)
+{
+	struct lp8788_clk *pclk = container_of(hw, struct lp8788_clk, hw);
+
+	/* Automatic oscillator source selection */
+	return lp8788_update_bits(pclk->lp, LP8788_REG_CLKCTRL,
+				LP8788_CLKMODE_MASK, LP8788_CLKMODE_AUTO);
+}
+
+static void lp8788_clk_unprepare(struct clk_hw *hw)
+{
+	/* Do nothing */
+	return;
+}
+
+static unsigned long lp8788_clk_recalc_rate(struct clk_hw *hw,
+					unsigned long unused)
+{
+	return CLKOUT_32KHZ;
+}
+
+static const struct clk_ops lp8788_clk_ops = {
+	.prepare = lp8788_clk_prepare,
+	.unprepare = lp8788_clk_unprepare,
+	.recalc_rate = lp8788_clk_recalc_rate,
+};
+
+static struct clk_init_data lp8788_clk_cfg = {
+	.name = "32k_clk",
+	.ops = &lp8788_clk_ops,
+	.flags = CLK_IS_ROOT | CLK_IGNORE_UNUSED,
+};
+
+static int lp8788_clk_register(struct device *dev, struct lp8788_clk *pclk)
+{
+	struct clk_lookup *lookup;
+
+	pclk->hw.init = &lp8788_clk_cfg;
+	pclk->clk = devm_clk_register(dev, &pclk->hw);
+	if (IS_ERR(pclk->clk)) {
+		dev_err(dev, "clk register err\n");
+		return PTR_ERR(pclk->clk);
+	}
+
+	lookup = clkdev_alloc(pclk->clk, lp8788_clk_cfg.name, NULL);
+	if (!lookup) {
+		dev_err(dev, "clkdev_alloc err\n");
+		return -ENOMEM;
+	}
+	pclk->lookup = lookup;
+
+	clkdev_add(lookup);
+
+	return 0;
+}
+
+static void lp8788_clk_unregister(struct lp8788_clk *pclk)
+{
+	if (pclk->lookup)
+		clkdev_drop(pclk->lookup);
+}
+
+static bool lp8788_is_clk_device_ready(struct lp8788_clk *pclk)
+{
+	u8 val = 0;
+
+	lp8788_read_byte(pclk->lp, LP8788_REG_STATUS, &val);
+
+	return val & LP8788_OSC_WORKING;
+}
+
+static int lp8788_clk_probe(struct platform_device *pdev)
+{
+	struct lp8788 *lp = dev_get_drvdata(pdev->dev.parent);
+	struct lp8788_clk *pclk;
+
+	pclk = devm_kzalloc(&pdev->dev, sizeof(struct lp8788_clk), GFP_KERNEL);
+	if (!pclk)
+		return -ENOMEM;
+
+	pclk->lp = lp;
+	platform_set_drvdata(pdev, pclk);
+
+	if (!lp8788_is_clk_device_ready(pclk))
+		return -ENODEV;
+
+	return lp8788_clk_register(&pdev->dev, pclk);
+}
+
+static int lp8788_clk_remove(struct platform_device *pdev)
+{
+	struct lp8788_clk *pclk = platform_get_drvdata(pdev);
+
+	lp8788_clk_unregister(pclk);
+	return 0;
+}
+
+static struct platform_driver lp8788_clk_driver = {
+	.probe = lp8788_clk_probe,
+	.remove = lp8788_clk_remove,
+	.driver		= {
+		.name	= LP8788_DEV_CLK,
+		.owner	= THIS_MODULE,
+	},
+};
+
+static int __init lp8788_clk_init(void)
+{
+	return platform_driver_register(&lp8788_clk_driver);
+}
+subsys_initcall(lp8788_clk_init);
+
+static void __exit lp8788_clk_exit(void)
+{
+	platform_driver_unregister(&lp8788_clk_driver);
+}
+module_exit(lp8788_clk_exit);
+
+MODULE_DESCRIPTION("TI LP8788 Clock Driver");
+MODULE_AUTHOR("Milo Kim");
+MODULE_LICENSE("GPL");
+MODULE_ALIAS("platform:lp8788-clk");
diff --git a/drivers/mfd/lp8788.c b/drivers/mfd/lp8788.c
index c3d3c9b..9f5596e 100644
--- a/drivers/mfd/lp8788.c
+++ b/drivers/mfd/lp8788.c
@@ -72,6 +72,8 @@ static struct resource rtc_irqs[] = {
 };
 
 static struct mfd_cell lp8788_devs[] = {
+	MFD_DEV_SIMPLE(CLK),
+
 	/* 4 bucks */
 	MFD_DEV_WITH_ID(BUCK, 1),
 	MFD_DEV_WITH_ID(BUCK, 2),
diff --git a/include/linux/mfd/lp8788.h b/include/linux/mfd/lp8788.h
index 786bf66..5f33be8 100644
--- a/include/linux/mfd/lp8788.h
+++ b/include/linux/mfd/lp8788.h
@@ -28,6 +28,7 @@
 #define LP8788_DEV_VIBRATOR	"lp8788-vibrator"
 #define LP8788_DEV_KEYLED	"lp8788-keyled"
 #define LP8788_DEV_ADC		"lp8788-adc"
+#define LP8788_DEV_CLK		"lp8788-clk"
 
 #define LP8788_NUM_BUCKS	4
 #define LP8788_NUM_DLDOS	12
-- 
1.7.9.5


Best Regards,
Milo




From horms at verge.net.au  Wed Apr  3 22:00:20 2013
From: horms at verge.net.au (Simon Horman)
Date: Thu, 4 Apr 2013 11:00:20 +0900
Subject: APE6EVM and Runtime PM
Message-ID: <20130404020019.GA7163@verge.net.au>

Hi Magnus,

in the course of looking look at consolidating our defconfigs I
noticed that SMSC ethernet and rcar_thermal seem seem to not work when
runtime PM is enabled.

I'm wondering if you have any ideas of what might be the cause of this
or if you could give me some guidance on investigating this problem.

I assume that it relates to a clock or clocks not being enabled.


From horms+renesas at verge.net.au  Wed Apr  3 22:20:33 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Apr 2013 11:20:33 +0900
Subject: [PATCH] ARM: shmobile: kzm9d: resigser smsc911x platform device with
 id -1
Message-ID: <1365042033-29649-1-git-send-email-horms+renesas@verge.net.au>

As the kzm9d only has one smsc911x device it
may be registered as a platform device with id -1.

This allows the kzm9d board to access the smsc911x device
when CONFIG_REGULATOR (and CONFIG_REGULATOR_FIXED_VOLTAGE)
are set. The motivation for which is twofold: using regulators
seems to be generally a good thing; it will move the kzm9d defconfig
one step closer to being able to be consolidated with other
shmobile defconfigs.

An alternate but so far untested approach would be to
update the definition of dummy_supplies in board-kzm9d.c
to use "smsc911x.0" instead of "smsc911x".

Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/board-kzm9d.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-shmobile/board-kzm9d.c b/arch/arm/mach-shmobile/board-kzm9d.c
index c254782..2425d67 100644
--- a/arch/arm/mach-shmobile/board-kzm9d.c
+++ b/arch/arm/mach-shmobile/board-kzm9d.c
@@ -56,7 +56,7 @@ static struct smsc911x_platform_config smsc911x_platdata = {
 
 static struct platform_device smsc91x_device = {
 	.name	= "smsc911x",
-	.id	= 0,
+	.id	= -1,
 	.dev	= {
 		  .platform_data = &smsc911x_platdata,
 		},
-- 
1.7.10.4



From jon-hunter at ti.com  Wed Apr  3 22:20:59 2013
From: jon-hunter at ti.com (Jon Hunter)
Date: Wed, 3 Apr 2013 21:20:59 -0500
Subject: [GIT PULL] ARM: OMAP2+: GPMC updates
In-Reply-To: <20130403214036.GD10155@atomide.com>
References: <515B0D92.6070503@ti.com> <20130403214036.GD10155@atomide.com>
Message-ID: <515CE38B.3080400@ti.com>


On 04/03/2013 04:40 PM, Tony Lindgren wrote:
> * Jon Hunter <jon-hunter at ti.com> [130402 10:00]:
>> The following changes since commit dca3a783400a18e2bf4503b1d4a85c4d0ca1a7e4:
>>
>>   Merge commit '31d9adca82ce65e5c99d045b5fd917c702b6fce3' into tmp (2013-04-01 14:33:50 -0500)
>>
>> are available in the git repository at:
>>
>>
>>   git://github.com/jonhunter/linux.git omap-gpmc-for-v3.10
>>
>> for you to fetch changes up to c67bd6e7cad2160c3bbfa2ac2bd954f918301c23:
>>
>>   ARM: OMAP2+: Add GPMC DT support for Ethernet child nodes (2013-04-01 14:53:50 -0500)
>>
>> ----------------------------------------------------------------
>> Adds GPMC DT support for NOR flash and Ethernet and includes
>> various GPMC cleans-up and fixes.
>>
>> This series is dependent on commit 7185684 (ARM: OMAP: use
>> consistent error checking) from RMK's clean-up branch and commit
>> 31d9adc (ARM: OMAP2+: Fix broken gpmc support).
> 
> Looks good except it adds a new warning:
> 
> arch/arm/mach-omap2/gpmc.c: In function ?gpmc_read_timings_dt?:
> arch/arm/mach-omap2/gpmc.c:1324: warning: ?p? may be used uninitialized in this function
> 
> Can you please take a look?

No problem. I did not see get this warning, but I believe that 
there is a bug that needed to be fixed. Can you try the below?

Jon

The following changes since commit dca3a783400a18e2bf4503b1d4a85c4d0ca1a7e4:

  Merge commit '31d9adca82ce65e5c99d045b5fd917c702b6fce3' into tmp (2013-04-01 14:33:50 -0500)

are available in the git repository at:


  git://github.com/jonhunter/linux.git omap-gpmc-for-v3.10-take2

for you to fetch changes up to 5330dc161cb41e399e85d30e6908f1b93b956d1e:

  ARM: OMAP2+: Add GPMC DT support for Ethernet child nodes (2013-04-03 20:13:42 -0500)

----------------------------------------------------------------
Ezequiel Garcia (8):
      ARM: omap2: gpmc: Mark local scoped functions static
      ARM: omap2: gpmc: Remove unused gpmc_round_ns_to_ticks() function
      ARM: omap2: gpmc: Fix gpmc_cs_reserved() return value
      ARM: omap2: gpmc-nand: Print something useful on CS request failure
      ARM: omap2: gpmc-onenand: Print something useful on CS request failure
      ARM: omap2: gpmc-onenand: Replace pr_err() with dev_err()
      ARM: omap2: gpmc-onenand: Replace printk KERN_ERR with dev_warn()
      ARM: omap2: gpmc: Remove redundant chip select out of range check

Javier Martinez Canillas (3):
      ARM: OMAP2+: return -ENODEV if GPMC child device creation fails
      ARM: OMAP2+: rename gpmc_probe_nor_child() to gpmc_probe_generic_child()
      ARM: OMAP2+: Add GPMC DT support for Ethernet child nodes

Jon Hunter (17):
      ARM: OMAP2+: Simplify code configuring ONENAND devices
      ARM: OMAP2+: Add variable to store number of GPMC waitpins
      ARM: OMAP2+: Add structure for storing GPMC settings
      ARM: OMAP2+: Add function for configuring GPMC settings
      ARM: OMAP2+: Convert ONENAND to use gpmc_cs_program_settings()
      ARM: OMAP2+: Convert NAND to use gpmc_cs_program_settings()
      ARM: OMAP2+: Convert SMC91x to use gpmc_cs_program_settings()
      ARM: OMAP2+: Convert TUSB to use gpmc_cs_program_settings()
      ARM: OMAP2+: Don't configure of chip-select options in gpmc_cs_configure()
      ARM: OMAP2+: Add function to read GPMC settings from device-tree
      ARM: OMAP2+: Add additional GPMC timing parameters
      ARM: OMAP2+: Add device-tree support for NOR flash
      ARM: OMAP2+: Convert NAND to retrieve GPMC settings from DT
      ARM: OMAP2+: Convert ONENAND to retrieve GPMC settings from DT
      ARM: OMAP2+: Detect incorrectly aligned GPMC base address
      ARM: OMAP2+: Remove unnecesssary GPMC definitions and variable
      ARM: OMAP2+: Allow GPMC probe to complete even if CS mapping fails

Mark Jackson (1):
      ARM: OMAP: Clear GPMC bits when applying new setting.

 Documentation/devicetree/bindings/bus/ti-gpmc.txt  |  103 +++-
 Documentation/devicetree/bindings/mtd/gpmc-nor.txt |   98 ++++
 .../devicetree/bindings/mtd/gpmc-onenand.txt       |    3 +
 Documentation/devicetree/bindings/net/gpmc-eth.txt |   97 ++++
 arch/arm/mach-omap2/gpmc-nand.c                    |   42 +-
 arch/arm/mach-omap2/gpmc-onenand.c                 |  118 ++---
 arch/arm/mach-omap2/gpmc-smc91x.c                  |   30 +-
 arch/arm/mach-omap2/gpmc.c                         |  544 ++++++++++++++------
 arch/arm/mach-omap2/gpmc.h                         |   43 +-
 arch/arm/mach-omap2/usb-tusb6010.c                 |   62 ++-
 10 files changed, 831 insertions(+), 309 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/mtd/gpmc-nor.txt
 create mode 100644 Documentation/devicetree/bindings/net/gpmc-eth.txt


From swarren at wwwdotorg.org  Wed Apr  3 22:25:06 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Wed, 03 Apr 2013 20:25:06 -0600
Subject: [PATCH] video: implement a dumb framebuffer driver
In-Reply-To: <20130403064653.GA6263@quad.lixom.net>
References: <1364969830-6481-1-git-send-email-swarren@wwwdotorg.org>
 <20130403064653.GA6263@quad.lixom.net>
Message-ID: <515CE482.4030707@wwwdotorg.org>

On 04/03/2013 12:46 AM, Olof Johansson wrote:
> On Wed, Apr 03, 2013 at 12:17:10AM -0600, Stephen Warren wrote:
>> A dumb frame-buffer describes a raw memory region that may be rendered
>> to, with the assumption that the display hardware has already been set
>> up to scan out from that buffer.
>>
>> This is useful in cases where a bootloader exists and has set up the
>> display hardware, but a Linux driver doesn't yet exist for the display
>> hardware.
...
>> diff --git a/Documentation/devicetree/bindings/video/dumb-framebuffer.txt b/Documentation/devicetree/bindings/video/dumb-framebuffer.txt
...
>> +Required properties:
...
>> +- format: The format of the framebuffer surface. Valid values are:
>> +  r5g6b5: A 16bpp format.
> 
> Hm, I'm used to this being written as "rgb565", which is also the format
> string that the fsl-imx-drm binding seems to use.
> 
> I guess actual depth can easily be derived from format.

I'd prefer the bit-widths be interleaved with the component names; doing
so is a little more precise if you end up with 2-digit component widths,
e.g. 10-bit r/g/b plus 2-bit alpha, where the multi-digit numbers would
run together otherwise and hence aren't easily algorithmically parsable.
I believe this interleaved style is more common in the graphics world
too. The IMX binding doesn't seem like a good example; the other option
besides "rgb565" is "rgb24", which could be one one many different formats.

I'll address the dumb/simple naming issue and repost.


From swarren at wwwdotorg.org  Wed Apr  3 22:39:43 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Wed,  3 Apr 2013 20:39:43 -0600
Subject: [PATCH V2] video: implement a simple framebuffer driver
Message-ID: <1365043183-28905-1-git-send-email-swarren@wwwdotorg.org>

A simple frame-buffer describes a raw memory region that may be rendered
to, with the assumption that the display hardware has already been set
up to scan out from that buffer.

This is useful in cases where a bootloader exists and has set up the
display hardware, but a Linux driver doesn't yet exist for the display
hardware.

Signed-off-by: Stephen Warren <swarren at wwwdotorg.org>
---
v2: s/dumb/simple/ throughout. Provide more details on pixel format.

I ended up going with a separate FB driver:
* DRM/KMS look much more complex, and don't provide any benefit that I can
  tell for this simple driver.
* Creating a separate driver rather than adjusting offb.c to work allows a
  new clean binding to be defined, and doesn't require removing or ifdefing
  PPC-isms in offb.c.
---
 .../bindings/video/simple-framebuffer.txt          |   25 +++
 drivers/video/Kconfig                              |   17 ++
 drivers/video/Makefile                             |    1 +
 drivers/video/simplefb.c                           |  234 ++++++++++++++++++++
 4 files changed, 277 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/video/simple-framebuffer.txt
 create mode 100644 drivers/video/simplefb.c

diff --git a/Documentation/devicetree/bindings/video/simple-framebuffer.txt b/Documentation/devicetree/bindings/video/simple-framebuffer.txt
new file mode 100644
index 0000000..3ea4605
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/simple-framebuffer.txt
@@ -0,0 +1,25 @@
+Simple Framebuffer
+
+A simple frame-buffer describes a raw memory region that may be rendered to,
+with the assumption that the display hardware has already been set up to scan
+out from that buffer.
+
+Required properties:
+- compatible: "simple-framebuffer"
+- reg: Should contain the location and size of the framebuffer memory.
+- width: The width of the framebuffer in pixels.
+- height: The height of the framebuffer in pixels.
+- stride: The number of bytes in each line of the framebuffer.
+- format: The format of the framebuffer surface. Valid values are:
+  - r5g6b5 (16-bit pixels, d[15:11]=r, d[10:5]=g, d[4:0]=b).
+
+Example:
+
+	framebuffer {
+		compatible = "simple-framebuffer";
+		reg = <0x1d385000 (1600 * 1200 * 2)>;
+		width = <1600>;
+		height = <1200>;
+		stride = <(1600 * 2)>;
+		format = "r5g6b5";
+	};
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 0181a87..e946e9c 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -2462,6 +2462,23 @@ config FB_HYPERV
 	help
 	  This framebuffer driver supports Microsoft Hyper-V Synthetic Video.
 
+config FB_SIMPLE
+	bool "Simple framebuffer support"
+	depends on (FB = y) && OF
+	select FB_CFB_FILLRECT
+	select FB_CFB_COPYAREA
+	select FB_CFB_IMAGEBLIT
+	help
+	  Say Y if you want support for a simple frame-buffer.
+
+	  This driver assumes that the display hardware has been initialized
+	  before the kernel boots, and the kernel will simply render to the
+	  pre-allocated frame buffer surface.
+
+	  Configuration re: surface address, size, and format must be provided
+	  through device tree, or potentially plain old platform data in the
+	  future.
+
 source "drivers/video/omap/Kconfig"
 source "drivers/video/omap2/Kconfig"
 source "drivers/video/exynos/Kconfig"
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 97f7b6d..859f1fa 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -166,6 +166,7 @@ obj-$(CONFIG_FB_MX3)		  += mx3fb.o
 obj-$(CONFIG_FB_DA8XX)		  += da8xx-fb.o
 obj-$(CONFIG_FB_MXS)		  += mxsfb.o
 obj-$(CONFIG_FB_SSD1307)	  += ssd1307fb.o
+obj-$(CONFIG_FB_SIMPLE)           += simplefb.o
 
 # the test framebuffer is last
 obj-$(CONFIG_FB_VIRTUAL)          += vfb.o
diff --git a/drivers/video/simplefb.c b/drivers/video/simplefb.c
new file mode 100644
index 0000000..8105c3d
--- /dev/null
+++ b/drivers/video/simplefb.c
@@ -0,0 +1,234 @@
+/*
+ * Simplest possible simple frame-buffer driver, as a platform device
+ *
+ * Copyright (c) 2013, Stephen Warren
+ *
+ * Based on q40fb.c, which was:
+ * Copyright (C) 2001 Richard Zidlicky <rz at linux-m68k.org>
+ *
+ * Also based on offb.c, which was:
+ * Copyright (C) 1997 Geert Uytterhoeven
+ * Copyright (C) 1996 Paul Mackerras
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ */
+
+#include <linux/errno.h>
+#include <linux/fb.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+
+static struct fb_fix_screeninfo simplefb_fix = {
+	.id		= "simple",
+	.type		= FB_TYPE_PACKED_PIXELS,
+	.visual		= FB_VISUAL_TRUECOLOR,
+	.accel		= FB_ACCEL_NONE,
+};
+
+static struct fb_var_screeninfo simplefb_var = {
+	.height		= -1,
+	.width		= -1,
+	.activate	= FB_ACTIVATE_NOW,
+	.vmode		= FB_VMODE_NONINTERLACED,
+};
+
+static int simplefb_setcolreg(u_int regno, u_int red, u_int green, u_int blue,
+			      u_int transp, struct fb_info *info)
+{
+	u32 *pal = info->pseudo_palette;
+	u32 cr = red >> (16 - info->var.red.length);
+	u32 cg = green >> (16 - info->var.green.length);
+	u32 cb = blue >> (16 - info->var.blue.length);
+	u32 value;
+
+	if (regno >= 16)
+		return -EINVAL;
+
+	value = (cr << info->var.red.offset) |
+		(cg << info->var.green.offset) |
+		(cb << info->var.blue.offset);
+	if (info->var.transp.length > 0) {
+		u32 mask = (1 << info->var.transp.length) - 1;
+		mask <<= info->var.transp.offset;
+		value |= mask;
+	}
+	pal[regno] = value;
+
+	return 0;
+}
+
+static struct fb_ops simplefb_ops = {
+	.owner		= THIS_MODULE,
+	.fb_setcolreg	= simplefb_setcolreg,
+	.fb_fillrect	= cfb_fillrect,
+	.fb_copyarea	= cfb_copyarea,
+	.fb_imageblit	= cfb_imageblit,
+};
+
+struct simplefb_format {
+	const char *name;
+	u32 bits_per_pixel;
+	struct fb_bitfield red;
+	struct fb_bitfield green;
+	struct fb_bitfield blue;
+	struct fb_bitfield transp;
+};
+
+struct simplefb_format simplefb_formats[] = {
+	{ "r5g6b5", 16, {11, 5}, {5, 6}, {0, 5}, {0, 0} },
+};
+
+struct simplefb_params {
+	u32 width;
+	u32 height;
+	u32 stride;
+	struct simplefb_format *format;
+};
+
+static int simplefb_parse_dt(struct platform_device *pdev,
+			   struct simplefb_params *params)
+{
+	struct device_node *np = pdev->dev.of_node;
+	int ret;
+	const char *format;
+	int i;
+
+	ret = of_property_read_u32(np, "width", &params->width);
+	if (ret) {
+		dev_err(&pdev->dev, "Can't parse width property\n");
+		return ret;
+	}
+
+	ret = of_property_read_u32(np, "height", &params->height);
+	if (ret) {
+		dev_err(&pdev->dev, "Can't parse height property\n");
+		return ret;
+	}
+
+	ret = of_property_read_u32(np, "stride", &params->stride);
+	if (ret) {
+		dev_err(&pdev->dev, "Can't parse stride property\n");
+		return ret;
+	}
+
+	ret = of_property_read_string(np, "format", &format);
+	if (ret) {
+		dev_err(&pdev->dev, "Can't parse format property\n");
+		return ret;
+	}
+	params->format = NULL;
+	for (i = 0; i < ARRAY_SIZE(simplefb_formats); i++) {
+		if (strcmp(format, simplefb_formats[i].name))
+			continue;
+		params->format = &simplefb_formats[i];
+		break;
+	}
+	if (!params->format) {
+		dev_err(&pdev->dev, "Invalid format value\n");
+		return -EINVAL;
+	}
+
+	return 0;
+}
+
+static int simplefb_probe(struct platform_device *pdev)
+{
+	int ret;
+	struct simplefb_params params;
+	struct fb_info *info;
+	struct resource *mem;
+
+	if (fb_get_options("simplefb", NULL))
+		return -ENODEV;
+
+	ret = simplefb_parse_dt(pdev, &params);
+	if (ret)
+		return ret;
+
+	mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	if (!mem) {
+		dev_err(&pdev->dev, "No memory resource\n");
+		return -EINVAL;
+	}
+
+	info = framebuffer_alloc(sizeof(u32) * 16, &pdev->dev);
+	if (!info)
+		return -ENOMEM;
+	platform_set_drvdata(pdev, info);
+
+	info->fix = simplefb_fix;
+	info->fix.smem_start = mem->start;
+	info->fix.smem_len = resource_size(mem);
+	info->fix.line_length = params.stride;
+
+	info->var = simplefb_var;
+	info->var.xres = params.width;
+	info->var.yres = params.height;
+	info->var.xres_virtual = params.width;
+	info->var.yres_virtual = params.height;
+	info->var.bits_per_pixel = params.format->bits_per_pixel;
+	info->var.red = params.format->red;
+	info->var.green = params.format->green;
+	info->var.blue = params.format->blue;
+	info->var.transp = params.format->transp;
+
+	info->fbops = &simplefb_ops;
+	info->flags = FBINFO_DEFAULT;
+	info->screen_base = devm_ioremap(&pdev->dev, info->fix.smem_start,
+					 info->fix.smem_len);
+	if (!info->screen_base) {
+		framebuffer_release(info);
+		return -ENODEV;
+	}
+	info->pseudo_palette = (void *)(info + 1);
+
+	ret = register_framebuffer(info);
+	if (ret < 0) {
+		dev_err(&pdev->dev, "Unable to register simplefb: %d\n", ret);
+		framebuffer_release(info);
+		return ret;
+	}
+
+	dev_info(&pdev->dev, "fb%d: simplefb registered!\n", info->node);
+
+	return 0;
+}
+
+static int simplefb_remove(struct platform_device *pdev)
+{
+	struct fb_info *info = platform_get_drvdata(pdev);
+
+	unregister_framebuffer(info);
+	framebuffer_release(info);
+
+	return 0;
+}
+
+static const struct of_device_id simplefb_of_match[] = {
+	{ .compatible = "simple-framebuffer", },
+	{ },
+};
+MODULE_DEVICE_TABLE(of, simplefb_of_match);
+
+static struct platform_driver simplefb_driver = {
+	.driver = {
+		.name = "simple-framebuffer",
+		.owner = THIS_MODULE,
+		.of_match_table = simplefb_of_match,
+	},
+	.probe = simplefb_probe,
+	.remove = simplefb_remove,
+};
+module_platform_driver(simplefb_driver);
+
+MODULE_AUTHOR("Stephen Warren <swarren at wwwdotorg.org>");
+MODULE_DESCRIPTION("Simple framebuffer driver");
+MODULE_LICENSE("GPL v2");
-- 
1.7.10.4



From swarren at wwwdotorg.org  Wed Apr  3 22:40:56 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Wed,  3 Apr 2013 20:40:56 -0600
Subject: [PATCH V2 1/2] ARM: bcm2835: add simple framebuffer to device tree
Message-ID: <1365043257-29296-1-git-send-email-swarren@wwwdotorg.org>

Place a template simple-framebuffer device into the RPi device tree. The
bootloader is expected to fill in all the parameters at boot time.
Hence, disable the device by default, so if the bootloader doesn't do
this, the device isn't activated with invalid parameters.

Signed-off-by: Stephen Warren <swarren at wwwdotorg.org>
---
v2: s/dumb/simple/ throughout.
---
 arch/arm/boot/dts/bcm2835-rpi-b.dts |   11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/boot/dts/bcm2835-rpi-b.dts b/arch/arm/boot/dts/bcm2835-rpi-b.dts
index aafda17..09e0d40 100644
--- a/arch/arm/boot/dts/bcm2835-rpi-b.dts
+++ b/arch/arm/boot/dts/bcm2835-rpi-b.dts
@@ -8,6 +8,17 @@
 	memory {
 		reg = <0 0x10000000>;
 	};
+
+	framebuffer {
+		compatible = "simple-framebuffer";
+		status = "disabled";
+		/* The bootloader is expected to fill these in */
+		reg = <0 0>;
+		width = <0>;
+		height = <0>;
+		stride = <0>;
+		format = "";
+	};
 };
 
 &gpio {
-- 
1.7.10.4



From swarren at wwwdotorg.org  Wed Apr  3 22:40:57 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Wed,  3 Apr 2013 20:40:57 -0600
Subject: [PATCH V2 2/2] ARM: bcm2835: defconfig updates for simple framebuffer
In-Reply-To: <1365043257-29296-1-git-send-email-swarren@wwwdotorg.org>
References: <1365043257-29296-1-git-send-email-swarren@wwwdotorg.org>
Message-ID: <1365043257-29296-2-git-send-email-swarren@wwwdotorg.org>

Enable the simple framebuffer driver, fbconsole, and VT support.

Signed-off-by: Stephen Warren <swarren at wwwdotorg.org>
---
v2: s/dumb/simple/
---
 arch/arm/configs/bcm2835_defconfig |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/arm/configs/bcm2835_defconfig b/arch/arm/configs/bcm2835_defconfig
index 32b2c84..22242eb 100644
--- a/arch/arm/configs/bcm2835_defconfig
+++ b/arch/arm/configs/bcm2835_defconfig
@@ -55,7 +55,6 @@ CONFIG_DEVTMPFS_MOUNT=y
 # CONFIG_INPUT_KEYBOARD is not set
 # CONFIG_INPUT_MOUSE is not set
 # CONFIG_SERIO is not set
-# CONFIG_VT is not set
 # CONFIG_LEGACY_PTYS is not set
 # CONFIG_DEVKMEM is not set
 CONFIG_SERIAL_AMBA_PL011=y
@@ -69,6 +68,10 @@ CONFIG_SPI=y
 CONFIG_SPI_BCM2835=y
 CONFIG_GPIO_SYSFS=y
 # CONFIG_HWMON is not set
+CONFIG_FB=y
+CONFIG_FB_SIMPLE=y
+CONFIG_FRAMEBUFFER_CONSOLE=y
+CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y
 # CONFIG_USB_SUPPORT is not set
 CONFIG_MMC=y
 CONFIG_MMC_SDHCI=y
-- 
1.7.10.4



From mturquette at linaro.org  Wed Apr  3 22:46:58 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Wed, 03 Apr 2013 19:46:58 -0700
Subject: [PATCH v2 1/7] clk: sunxi: Add support for AXI, AHB,
 APB0 and APB1 gates
In-Reply-To: <515CD51A.2070503@elopez.com.ar>
References: <1363962042-29536-1-git-send-email-emilio@elopez.com.ar>
 <1364419243-18446-1-git-send-email-emilio@elopez.com.ar>
 <1364419243-18446-2-git-send-email-emilio@elopez.com.ar>
 <20130403214815.3383.60153@quantum> <515CD51A.2070503@elopez.com.ar>
Message-ID: <20130404024658.3383.63115@quantum>

Quoting Emilio L?pez (2013-04-03 18:19:22)
> Hi Mike,
> 
> El 03/04/13 18:48, Mike Turquette escribi?:
> > Quoting Emilio L?pez (2013-03-27 14:20:37)
> >> diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
> >> index d528a24..244de90 100644
> >> --- a/drivers/clk/sunxi/clk-sunxi.c
> >> +++ b/drivers/clk/sunxi/clk-sunxi.c
> >> @@ -302,6 +302,82 @@ static void __init sunxi_divider_clk_setup(struct device_node *node,
> >>  }
> >>  
> >>  
> >> +
> > 
> > A lot of white space between these functions.
> 
> All of the function blocks are separated with three spaces on the file;
> I thought it looked more readable that way, but I don't have any strong
> opinion on separation. Is there any standard for this used on the kernel?
> 
> In any case, and to keep consistency, can we handle this on a follow-up
> patch?
> 

If it's consistent throughout the file then go ahead and keep it.

> >> +/**
> >> + * sunxi_gates_clk_setup() - Setup function for leaf gates on clocks
> >> + */
> >> +
> >> +#define SUNXI_GATES_MAX_SIZE   64
> >> +
> >> +struct gates_data {
> >> +       DECLARE_BITMAP(mask, SUNXI_GATES_MAX_SIZE);
> >> +};
> >> +
> >> +static const __initconst struct gates_data axi_gates_data = {
> >> +       .mask = {1},
> >> +};
> >> +
> >> +static const __initconst struct gates_data ahb_gates_data = {
> >> +       .mask = {0x7F77FFF, 0x14FB3F},
> >> +};
> >> +
> >> +static const __initconst struct gates_data apb0_gates_data = {
> >> +       .mask = {0x4EF},
> >> +};
> >> +
> >> +static const __initconst struct gates_data apb1_gates_data = {
> >> +       .mask = {0xFF00F7},
> >> +};
> >> +
> >> +static void __init sunxi_gates_clk_setup(struct device_node *node,
> >> +                                        struct gates_data *data)
> >> +{
> >> +       struct clk_onecell_data *clk_data;
> >> +       const char *clk_parent;
> >> +       const char *clk_name;
> >> +       void *reg;
> >> +       int qty;
> >> +       int i = 0;
> >> +       int j = 0;
> >> +       int ignore;
> >> +
> >> +       reg = of_iomap(node, 0);
> >> +
> >> +       clk_parent = of_clk_get_parent_name(node, 0);
> >> +
> >> +       /* Worst-case size approximation and memory allocation */
> >> +       qty = find_last_bit(data->mask, SUNXI_GATES_MAX_SIZE);
> >> +       clk_data = kmalloc(sizeof(struct clk_onecell_data), GFP_KERNEL);
> >> +       if (!clk_data)
> >> +               return;
> >> +       clk_data->clks = kzalloc((qty+1) * sizeof(struct clk *), GFP_KERNEL);
> >> +       if (!clk_data->clks) {
> >> +               kfree(clk_data);
> >> +               return;
> >> +       }
> >> +
> >> +       for_each_set_bit(i, data->mask, SUNXI_GATES_MAX_SIZE) {
> >> +               of_property_read_string_index(node, "clock-output-names",
> >> +                                             j, &clk_name);
> >> +
> >> +               /* No driver claims this clock, but it should remain gated */
> > 
> > Should the comment read, "ungated" instead of "gated"?
> 
> Indeed, good catch. Do you want me to resend the series, or can you
> amend this when picking the patches?
> 

I can amend it, but I don't like to get into the habit of doing that too
often.

I'll wait on Gregory's response on the of_clk_init stuff before I do so.

Regards,
Mike

> >> +               ignore = !strcmp("ahb_sdram", clk_name) ? CLK_IGNORE_UNUSED : 0;
> >> +
> >> +               clk_data->clks[i] = clk_register_gate(NULL, clk_name,
> >> +                                                     clk_parent, ignore,
> >> +                                                     reg + 4 * (i/32), i % 32,
> >> +                                                     0, &clk_lock);
> >> +               WARN_ON(IS_ERR(clk_data->clks[i]));
> >> +
> >> +               j++;
> >> +       }
> >> +
> >> +       /* Adjust to the real max */
> >> +       clk_data->clk_num = i;
> >> +
> >> +       of_clk_add_provider(node, of_clk_src_onecell_get, clk_data);
> >> +}
> >> +
> >>  /* Matches for of_clk_init */
> >>  static const __initconst struct of_device_id clk_match[] = {
> >>         {.compatible = "fixed-clock", .data = of_fixed_clk_setup,},
> >> @@ -331,6 +407,15 @@ static const __initconst struct of_device_id clk_mux_match[] = {
> >>         {}
> >>  };
> >>  
> >> +/* Matches for gate clocks */
> >> +static const __initconst struct of_device_id clk_gates_match[] = {
> >> +       {.compatible = "allwinner,sun4i-axi-gates-clk", .data = &axi_gates_data,},
> >> +       {.compatible = "allwinner,sun4i-ahb-gates-clk", .data = &ahb_gates_data,},
> >> +       {.compatible = "allwinner,sun4i-apb0-gates-clk", .data = &apb0_gates_data,},
> >> +       {.compatible = "allwinner,sun4i-apb1-gates-clk", .data = &apb1_gates_data,},
> >> +       {}
> >> +};
> >> +
> >>  static void __init of_sunxi_table_clock_setup(const struct of_device_id *clk_match,
> >>                                               void *function)
> >>  {
> >> @@ -359,4 +444,7 @@ void __init sunxi_init_clocks(void)
> >>  
> >>         /* Register mux clocks */
> >>         of_sunxi_table_clock_setup(clk_mux_match, sunxi_mux_clk_setup);
> >> +
> >> +       /* Register gate clocks */
> >> +       of_sunxi_table_clock_setup(clk_gates_match, sunxi_gates_clk_setup);
> > 
> > I'm still a device tree noob, so this may be a dumb question.  Can the
> > above be converted to of_clk_init?
> 
> As far as I know, you can't, because of_clk_init doesn't allow for
> custom data to be passed to the functions. If we were to use of_clk_init
> we would need one function per clock, and it would be mostly duplicated
> code / wrappers. I've added Gregory on Cc, please correct me if this is
> not the case.
> 
> Thanks for the review,
> 
> Emilio


From kuninori.morimoto.gx at renesas.com  Wed Apr  3 23:26:39 2013
From: kuninori.morimoto.gx at renesas.com (Kuninori Morimoto)
Date: Wed, 03 Apr 2013 20:26:39 -0700 (PDT)
Subject: APE6EVM and Runtime PM
In-Reply-To: <20130404020019.GA7163@verge.net.au>
References: <20130404020019.GA7163@verge.net.au>
Message-ID: <87wqsjdlhv.wl%kuninori.morimoto.gx@renesas.com>


Hi Simon

> in the course of looking look at consolidating our defconfigs I
> noticed that SMSC ethernet and rcar_thermal seem seem to not work when
> runtime PM is enabled.
> 
> I'm wondering if you have any ideas of what might be the cause of this
> or if you could give me some guidance on investigating this problem.
> 
> I assume that it relates to a clock or clocks not being enabled.

About rcar_thermal, it needs my patch which was sent to PM ML.
I got email from Zhang that he accepted my patch (pm_runtime support for thermal).
But it seems he didn't push his branch yet...
I guess I explained this on my [PATCH 0/x] email.

Best regards
---
Kuninori Morimoto


From horms+renesas at verge.net.au  Wed Apr  3 23:29:47 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Apr 2013 12:29:47 +0900
Subject: [RFC/PATCH 1/7] ARM: shmobile: prune defconfig
In-Reply-To: <1365046193-19369-1-git-send-email-horms+renesas@verge.net.au>
References: <1365046193-19369-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1365046193-19369-2-git-send-email-horms+renesas@verge.net.au>

Remove a number of lines from the shmobile defconfig as they seem to
be orthogonal to shmobile, not necessary for booting boards,
and as far as I know not present in a number of the shmobile
board defconfigs.

Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/configs/shmobile_defconfig |   12 ------------
 1 file changed, 12 deletions(-)

diff --git a/arch/arm/configs/shmobile_defconfig b/arch/arm/configs/shmobile_defconfig
index 0f2d80d..90f5600 100644
--- a/arch/arm/configs/shmobile_defconfig
+++ b/arch/arm/configs/shmobile_defconfig
@@ -3,15 +3,9 @@ CONFIG_SYSVIPC=y
 CONFIG_IKCONFIG=y
 CONFIG_IKCONFIG_PROC=y
 CONFIG_LOG_BUF_SHIFT=16
-# CONFIG_UTS_NS is not set
-# CONFIG_IPC_NS is not set
-# CONFIG_PID_NS is not set
 CONFIG_CC_OPTIMIZE_FOR_SIZE=y
 CONFIG_PERF_EVENTS=y
 CONFIG_SLAB=y
-CONFIG_MODULES=y
-CONFIG_MODULE_UNLOAD=y
-CONFIG_MODULE_FORCE_UNLOAD=y
 # CONFIG_BLK_DEV_BSG is not set
 # CONFIG_IOSCHED_DEADLINE is not set
 # CONFIG_IOSCHED_CFQ is not set
@@ -145,9 +139,3 @@ CONFIG_NLS_ISO8859_1=y
 # CONFIG_ENABLE_WARN_DEPRECATED is not set
 # CONFIG_ENABLE_MUST_CHECK is not set
 # CONFIG_ARM_UNWIND is not set
-CONFIG_CRYPTO=y
-CONFIG_CRYPTO_CBC=y
-CONFIG_CRYPTO_MD5=y
-CONFIG_CRYPTO_DES=y
-CONFIG_CRYPTO_ANSI_CPRNG=y
-CONFIG_XZ_DEC=y
-- 
1.7.10.4



From horms+renesas at verge.net.au  Wed Apr  3 23:29:50 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Apr 2013 12:29:50 +0900
Subject: [RFC/PATCH 4/7] ARM: shmobile: Add mackerel to consolidated defconfig
In-Reply-To: <1365046193-19369-1-git-send-email-horms+renesas@verge.net.au>
References: <1365046193-19369-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1365046193-19369-5-git-send-email-horms+renesas@verge.net.au>

Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/configs/shmobile_defconfig |   12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/configs/shmobile_defconfig b/arch/arm/configs/shmobile_defconfig
index 8228e09..9b6219a 100644
--- a/arch/arm/configs/shmobile_defconfig
+++ b/arch/arm/configs/shmobile_defconfig
@@ -12,8 +12,10 @@ CONFIG_SLAB=y
 # CONFIG_IOSCHED_DEADLINE is not set
 # CONFIG_IOSCHED_CFQ is not set
 CONFIG_ARCH_SHMOBILE=y
+CONFIG_ARCH_SH7372=y
 CONFIG_ARCH_R8A7740=y
 CONFIG_ARCH_EMEV2=y
+CONFIG_MACH_MACKEREL=y
 CONFIG_MACH_ARMADILLO800EVA=y
 CONFIG_MACH_KZM9D=y
 # CONFIG_SH_TIMER_TMU is not set
@@ -58,6 +60,14 @@ CONFIG_IP_PNP_DHCP=y
 # CONFIG_IPV6 is not set
 # CONFIG_WIRELESS is not set
 CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
+CONFIG_MTD=y
+CONFIG_MTD_CHAR=y
+CONFIG_MTD_BLOCK=y
+CONFIG_MTD_CFI=y
+CONFIG_MTD_CFI_ADV_OPTIONS=y
+CONFIG_MTD_CFI_INTELEXT=y
+CONFIG_MTD_PHYSMAP=y
+CONFIG_MTD_BLOCK2MTD=y
 CONFIG_SCSI=y
 CONFIG_BLK_DEV_SD=y
 CONFIG_MD=y
@@ -116,7 +126,9 @@ CONFIG_LOGO=y
 # CONFIG_SND_ARM is not set
 CONFIG_SND_SOC_SH4_FSI=y
 CONFIG_USB=y
+CONFIG_USB_RENESAS_USBHS_HCD=y
 CONFIG_USB_RENESAS_USBHS=y
+CONFIG_USB_STORAGE=y
 CONFIG_USB_GADGET=y
 CONFIG_USB_RENESAS_USBHS_UDC=y
 CONFIG_USB_ETH=y
-- 
1.7.10.4



From horms+renesas at verge.net.au  Wed Apr  3 23:29:46 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Apr 2013 12:29:46 +0900
Subject: [RFC/PATCH 0/7] ARCH: shmobile: defconfig consolidation
Message-ID: <1365046193-19369-1-git-send-email-horms+renesas@verge.net.au>

Hi,

this is a first pass at consolidating the defconfigs of shmobile.

It covers the mackerel, amradillo800eva and kzm9d boards which meet
the following criteria:

* Have the same base memory address (0x40000000).
* Work with RUNTIME_PM, it is desirable to have that a common defconfig
* Are booted via DT, enabling the command line to be supplied in the dts.
  This is important to allow serial console and early printk settings,
  which vary wildly between boards, to be supplied.
* Boards I have to test.
  This didn't eliminate any candidates that met the above criteria.

I believe it should also be possible to add support for the APE6EVM
board to the consolidated defconfig once problems with RUNTIME_PM
have been isolated and resolved. I have send an email about this
in a separate thread "APE6EVM and Runtime PM".

I believe it may be possible to add support for the lager board
to the consolidated defconfig once I am able to bring that board up,
which should be rather soon. The lager board does not currently
have a defconfig.

Morimoto-san, I suspect it may be possible to add support for the
bockw board to the consolidated defconfig if its boot loader supports
booting using a zImage. In this case even though the base memory address
is not the same as the boards above it should be possible to specify
the base address from the boot loader. As I do not have a bockw board
I am wondering if you could investigate this.

Simon Horman (7):
  ARM: shmobile: prune defconfig
  ARM: shmobile: make defconfig canonical
  ARM: shmobile: Add kzm9d to consolidated defconfig
  ARM: shmobile: Add mackerel to consolidated defconfig
  ARM: shmobile: defconfig: Remove armadillo800eva defconfig
  ARM: shmobile: defconfig: Remove kzm9d defconfig
  ARM: shmobile: defconfig: Remove mackerel defconfig

 arch/arm/configs/armadillo800eva_defconfig |  153 ---------------------------
 arch/arm/configs/kzm9d_defconfig           |   88 ----------------
 arch/arm/configs/mackerel_defconfig        |  156 ----------------------------
 arch/arm/configs/shmobile_defconfig        |   51 +++++----
 4 files changed, 28 insertions(+), 420 deletions(-)
 delete mode 100644 arch/arm/configs/armadillo800eva_defconfig
 delete mode 100644 arch/arm/configs/kzm9d_defconfig
 delete mode 100644 arch/arm/configs/mackerel_defconfig

-- 
1.7.10.4



From horms+renesas at verge.net.au  Wed Apr  3 23:29:49 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Apr 2013 12:29:49 +0900
Subject: [RFC/PATCH 3/7] ARM: shmobile: Add kzm9d to consolidated defconfig
In-Reply-To: <1365046193-19369-1-git-send-email-horms+renesas@verge.net.au>
References: <1365046193-19369-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1365046193-19369-4-git-send-email-horms+renesas@verge.net.au>

Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/configs/shmobile_defconfig |   16 ++++++++++++++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/arch/arm/configs/shmobile_defconfig b/arch/arm/configs/shmobile_defconfig
index fd1c074..8228e09 100644
--- a/arch/arm/configs/shmobile_defconfig
+++ b/arch/arm/configs/shmobile_defconfig
@@ -1,8 +1,11 @@
 CONFIG_SYSVIPC=y
+CONFIG_NO_HZ=y
 CONFIG_IKCONFIG=y
 CONFIG_IKCONFIG_PROC=y
 CONFIG_LOG_BUF_SHIFT=16
 CONFIG_CC_OPTIMIZE_FOR_SIZE=y
+CONFIG_SYSCTL_SYSCALL=y
+CONFIG_EMBEDDED=y
 CONFIG_PERF_EVENTS=y
 CONFIG_SLAB=y
 # CONFIG_BLK_DEV_BSG is not set
@@ -10,8 +13,11 @@ CONFIG_SLAB=y
 # CONFIG_IOSCHED_CFQ is not set
 CONFIG_ARCH_SHMOBILE=y
 CONFIG_ARCH_R8A7740=y
+CONFIG_ARCH_EMEV2=y
 CONFIG_MACH_ARMADILLO800EVA=y
+CONFIG_MACH_KZM9D=y
 # CONFIG_SH_TIMER_TMU is not set
+# CONFIG_SWP_EMULATE is not set
 CONFIG_ARM_ERRATA_430973=y
 CONFIG_ARM_ERRATA_458693=y
 CONFIG_ARM_ERRATA_460075=y
@@ -24,6 +30,9 @@ CONFIG_PL310_ERRATA_753970=y
 CONFIG_ARM_ERRATA_754322=y
 CONFIG_PL310_ERRATA_769419=y
 CONFIG_ARM_ERRATA_775420=y
+CONFIG_SMP=y
+CONFIG_NR_CPUS=2
+# CONFIG_LOCAL_TIMERS is not set
 CONFIG_AEABI=y
 # CONFIG_OABI_COMPAT is not set
 CONFIG_FORCE_MAX_ZONEORDER=13
@@ -63,18 +72,20 @@ CONFIG_NETDEVICES=y
 # CONFIG_NET_VENDOR_NATSEMI is not set
 CONFIG_SH_ETH=y
 # CONFIG_NET_VENDOR_SEEQ is not set
-# CONFIG_NET_VENDOR_SMSC is not set
+CONFIG_SMSC911X=y
 # CONFIG_NET_VENDOR_STMICRO is not set
 # CONFIG_WLAN is not set
 # CONFIG_INPUT_MOUSEDEV_PSAUX is not set
 CONFIG_INPUT_EVDEV=y
 # CONFIG_KEYBOARD_ATKBD is not set
-CONFIG_KEYBOARD_GPIO=y
 # CONFIG_INPUT_MOUSE is not set
 CONFIG_INPUT_TOUCHSCREEN=y
 CONFIG_TOUCHSCREEN_ST1232=y
 # CONFIG_SERIO is not set
 # CONFIG_LEGACY_PTYS is not set
+CONFIG_SERIAL_8250=y
+CONFIG_SERIAL_8250_CONSOLE=y
+CONFIG_SERIAL_8250_EM=y
 CONFIG_SERIAL_SH_SCI=y
 CONFIG_SERIAL_SH_SCI_NR_UARTS=8
 CONFIG_SERIAL_SH_SCI_CONSOLE=y
@@ -82,6 +93,7 @@ CONFIG_SERIAL_SH_SCI_CONSOLE=y
 CONFIG_I2C=y
 CONFIG_I2C_GPIO=y
 CONFIG_I2C_SH_MOBILE=y
+CONFIG_GPIO_EM=y
 # CONFIG_HWMON is not set
 CONFIG_REGULATOR=y
 CONFIG_MEDIA_SUPPORT=y
-- 
1.7.10.4



From horms+renesas at verge.net.au  Wed Apr  3 23:29:48 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Apr 2013 12:29:48 +0900
Subject: [RFC/PATCH 2/7] ARM: shmobile: make defconfig canonical
In-Reply-To: <1365046193-19369-1-git-send-email-horms+renesas@verge.net.au>
References: <1365046193-19369-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1365046193-19369-3-git-send-email-horms+renesas@verge.net.au>

Use make savedefconfig to update the defconfig to the current
canonical form.

This is to aid the process of adding support for other boards.

Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/configs/shmobile_defconfig |   11 ++---------
 1 file changed, 2 insertions(+), 9 deletions(-)

diff --git a/arch/arm/configs/shmobile_defconfig b/arch/arm/configs/shmobile_defconfig
index 90f5600..fd1c074 100644
--- a/arch/arm/configs/shmobile_defconfig
+++ b/arch/arm/configs/shmobile_defconfig
@@ -1,4 +1,3 @@
-CONFIG_EXPERIMENTAL=y
 CONFIG_SYSVIPC=y
 CONFIG_IKCONFIG=y
 CONFIG_IKCONFIG_PROC=y
@@ -13,8 +12,6 @@ CONFIG_ARCH_SHMOBILE=y
 CONFIG_ARCH_R8A7740=y
 CONFIG_MACH_ARMADILLO800EVA=y
 # CONFIG_SH_TIMER_TMU is not set
-CONFIG_ARM_THUMB=y
-CONFIG_CACHE_L2X0=y
 CONFIG_ARM_ERRATA_430973=y
 CONFIG_ARM_ERRATA_458693=y
 CONFIG_ARM_ERRATA_460075=y
@@ -58,7 +55,6 @@ CONFIG_MD=y
 CONFIG_BLK_DEV_DM=y
 CONFIG_NETDEVICES=y
 # CONFIG_NET_VENDOR_BROADCOM is not set
-# CONFIG_NET_VENDOR_CHELSIO is not set
 # CONFIG_NET_VENDOR_CIRRUS is not set
 # CONFIG_NET_VENDOR_FARADAY is not set
 # CONFIG_NET_VENDOR_INTEL is not set
@@ -89,16 +85,14 @@ CONFIG_I2C_SH_MOBILE=y
 # CONFIG_HWMON is not set
 CONFIG_REGULATOR=y
 CONFIG_MEDIA_SUPPORT=y
-CONFIG_VIDEO_DEV=y
 CONFIG_MEDIA_CAMERA_SUPPORT=y
 CONFIG_V4L_PLATFORM_DRIVERS=y
 CONFIG_SOC_CAMERA=y
-CONFIG_SOC_CAMERA_MT9T112=y
 CONFIG_VIDEO_SH_MOBILE_CEU=y
+CONFIG_SOC_CAMERA_MT9T112=y
 CONFIG_FB=y
 CONFIG_FB_SH_MOBILE_LCDC=y
 CONFIG_FB_SH_MOBILE_HDMI=y
-CONFIG_LCD_CLASS_DEVICE=y
 CONFIG_FRAMEBUFFER_CONSOLE=y
 CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y
 CONFIG_LOGO=y
@@ -109,12 +103,11 @@ CONFIG_LOGO=y
 # CONFIG_SND_DRIVERS is not set
 # CONFIG_SND_ARM is not set
 CONFIG_SND_SOC_SH4_FSI=y
-# CONFIG_HID_SUPPORT is not set
 CONFIG_USB=y
 CONFIG_USB_RENESAS_USBHS=y
 CONFIG_USB_GADGET=y
 CONFIG_USB_RENESAS_USBHS_UDC=y
-CONFIG_USB_ETH=m
+CONFIG_USB_ETH=y
 CONFIG_MMC=y
 CONFIG_MMC_SDHI=y
 CONFIG_MMC_SH_MMCIF=y
-- 
1.7.10.4



From horms+renesas at verge.net.au  Wed Apr  3 23:29:52 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Apr 2013 12:29:52 +0900
Subject: [RFC/PATCH 6/7] ARM: shmobile: defconfig: Remove kzm9d defconfig
In-Reply-To: <1365046193-19369-1-git-send-email-horms+renesas@verge.net.au>
References: <1365046193-19369-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1365046193-19369-7-git-send-email-horms+renesas@verge.net.au>

Remove kzm9d defconfig as the shmobile defconfig may now be used instead.

Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/configs/kzm9d_defconfig |   88 --------------------------------------
 1 file changed, 88 deletions(-)
 delete mode 100644 arch/arm/configs/kzm9d_defconfig

diff --git a/arch/arm/configs/kzm9d_defconfig b/arch/arm/configs/kzm9d_defconfig
deleted file mode 100644
index 6c37f4a..0000000
--- a/arch/arm/configs/kzm9d_defconfig
+++ /dev/null
@@ -1,88 +0,0 @@
-# CONFIG_ARM_PATCH_PHYS_VIRT is not set
-CONFIG_EXPERIMENTAL=y
-CONFIG_SYSVIPC=y
-CONFIG_NO_HZ=y
-CONFIG_IKCONFIG=y
-CONFIG_IKCONFIG_PROC=y
-CONFIG_LOG_BUF_SHIFT=16
-CONFIG_CC_OPTIMIZE_FOR_SIZE=y
-CONFIG_SYSCTL_SYSCALL=y
-CONFIG_EMBEDDED=y
-CONFIG_PERF_EVENTS=y
-CONFIG_SLAB=y
-# CONFIG_BLK_DEV_BSG is not set
-# CONFIG_IOSCHED_DEADLINE is not set
-# CONFIG_IOSCHED_CFQ is not set
-CONFIG_ARCH_SHMOBILE=y
-CONFIG_ARCH_EMEV2=y
-CONFIG_MACH_KZM9D=y
-CONFIG_MEMORY_START=0x40000000
-CONFIG_MEMORY_SIZE=0x10000000
-# CONFIG_SH_TIMER_TMU is not set
-# CONFIG_SWP_EMULATE is not set
-# CONFIG_CACHE_L2X0 is not set
-CONFIG_SMP=y
-CONFIG_NR_CPUS=2
-CONFIG_HOTPLUG_CPU=y
-# CONFIG_LOCAL_TIMERS is not set
-CONFIG_AEABI=y
-# CONFIG_OABI_COMPAT is not set
-# CONFIG_CROSS_MEMORY_ATTACH is not set
-CONFIG_FORCE_MAX_ZONEORDER=13
-CONFIG_ZBOOT_ROM_TEXT=0x0
-CONFIG_ZBOOT_ROM_BSS=0x0
-CONFIG_ARM_APPENDED_DTB=y
-CONFIG_VFP=y
-# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
-CONFIG_PM_RUNTIME=y
-CONFIG_NET=y
-CONFIG_PACKET=y
-CONFIG_UNIX=y
-CONFIG_INET=y
-CONFIG_IP_PNP=y
-CONFIG_IP_PNP_DHCP=y
-# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
-# CONFIG_INET_XFRM_MODE_TUNNEL is not set
-# CONFIG_INET_XFRM_MODE_BEET is not set
-# CONFIG_INET_LRO is not set
-# CONFIG_INET_DIAG is not set
-# CONFIG_IPV6 is not set
-# CONFIG_WIRELESS is not set
-CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
-# CONFIG_BLK_DEV is not set
-CONFIG_NETDEVICES=y
-# CONFIG_NET_VENDOR_BROADCOM is not set
-# CONFIG_NET_VENDOR_CHELSIO is not set
-# CONFIG_NET_VENDOR_CIRRUS is not set
-# CONFIG_NET_VENDOR_FARADAY is not set
-# CONFIG_NET_VENDOR_INTEL is not set
-# CONFIG_NET_VENDOR_MARVELL is not set
-# CONFIG_NET_VENDOR_MICREL is not set
-# CONFIG_NET_VENDOR_NATSEMI is not set
-# CONFIG_NET_VENDOR_SEEQ is not set
-CONFIG_SMSC911X=y
-# CONFIG_NET_VENDOR_STMICRO is not set
-# CONFIG_NET_VENDOR_WIZNET is not set
-# CONFIG_WLAN is not set
-# CONFIG_INPUT_MOUSEDEV is not set
-# CONFIG_INPUT_KEYBOARD is not set
-# CONFIG_INPUT_MOUSE is not set
-# CONFIG_SERIO is not set
-# CONFIG_LEGACY_PTYS is not set
-# CONFIG_DEVKMEM is not set
-CONFIG_SERIAL_8250=y
-CONFIG_SERIAL_8250_CONSOLE=y
-CONFIG_SERIAL_8250_EM=y
-# CONFIG_HW_RANDOM is not set
-CONFIG_GPIOLIB=y
-CONFIG_GPIO_EM=y
-# CONFIG_HWMON is not set
-# CONFIG_HID_SUPPORT is not set
-# CONFIG_USB_SUPPORT is not set
-# CONFIG_IOMMU_SUPPORT is not set
-# CONFIG_DNOTIFY is not set
-CONFIG_TMPFS=y
-# CONFIG_MISC_FILESYSTEMS is not set
-CONFIG_NFS_FS=y
-CONFIG_ROOT_NFS=y
-# CONFIG_FTRACE is not set
-- 
1.7.10.4



From horms+renesas at verge.net.au  Wed Apr  3 23:29:53 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Apr 2013 12:29:53 +0900
Subject: [RFC/PATCH 7/7] ARM: shmobile: defconfig: Remove mackerel defconfig
In-Reply-To: <1365046193-19369-1-git-send-email-horms+renesas@verge.net.au>
References: <1365046193-19369-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1365046193-19369-8-git-send-email-horms+renesas@verge.net.au>

Remove mackerel defconfig as the shmobile defconfig may now be used instead.

Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/configs/mackerel_defconfig |  156 -----------------------------------
 1 file changed, 156 deletions(-)
 delete mode 100644 arch/arm/configs/mackerel_defconfig

diff --git a/arch/arm/configs/mackerel_defconfig b/arch/arm/configs/mackerel_defconfig
deleted file mode 100644
index 9fb1189..0000000
--- a/arch/arm/configs/mackerel_defconfig
+++ /dev/null
@@ -1,156 +0,0 @@
-CONFIG_EXPERIMENTAL=y
-CONFIG_SYSVIPC=y
-CONFIG_IKCONFIG=y
-CONFIG_IKCONFIG_PROC=y
-CONFIG_LOG_BUF_SHIFT=16
-# CONFIG_UTS_NS is not set
-# CONFIG_IPC_NS is not set
-# CONFIG_USER_NS is not set
-# CONFIG_PID_NS is not set
-# CONFIG_NET_NS is not set
-CONFIG_SLAB=y
-CONFIG_MODULES=y
-CONFIG_MODULE_UNLOAD=y
-# CONFIG_BLK_DEV_BSG is not set
-# CONFIG_IOSCHED_DEADLINE is not set
-# CONFIG_IOSCHED_CFQ is not set
-CONFIG_ARCH_SHMOBILE=y
-CONFIG_ARCH_SH7372=y
-CONFIG_MACH_MACKEREL=y
-CONFIG_MEMORY_SIZE=0x10000000
-CONFIG_AEABI=y
-# CONFIG_OABI_COMPAT is not set
-CONFIG_FORCE_MAX_ZONEORDER=15
-CONFIG_ZBOOT_ROM_TEXT=0x0
-CONFIG_ZBOOT_ROM_BSS=0x0
-CONFIG_ARM_APPENDED_DTB=y
-CONFIG_KEXEC=y
-CONFIG_VFP=y
-# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
-CONFIG_PM=y
-CONFIG_PM_RUNTIME=y
-CONFIG_NET=y
-CONFIG_PACKET=y
-CONFIG_UNIX=y
-CONFIG_INET=y
-CONFIG_IP_MULTICAST=y
-CONFIG_IP_PNP=y
-CONFIG_IP_PNP_DHCP=y
-# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
-# CONFIG_INET_XFRM_MODE_TUNNEL is not set
-# CONFIG_INET_XFRM_MODE_BEET is not set
-# CONFIG_IPV6 is not set
-# CONFIG_WIRELESS is not set
-CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
-# CONFIG_FIRMWARE_IN_KERNEL is not set
-CONFIG_MTD=y
-CONFIG_MTD_CONCAT=y
-CONFIG_MTD_PARTITIONS=y
-CONFIG_MTD_CHAR=y
-CONFIG_MTD_BLOCK=y
-CONFIG_MTD_CFI=y
-CONFIG_MTD_CFI_ADV_OPTIONS=y
-CONFIG_MTD_CFI_INTELEXT=y
-CONFIG_MTD_PHYSMAP=y
-CONFIG_MTD_ARM_INTEGRATOR=y
-CONFIG_MTD_BLOCK2MTD=y
-CONFIG_SCSI=y
-CONFIG_BLK_DEV_SD=y
-# CONFIG_SCSI_LOWLEVEL is not set
-CONFIG_NETDEVICES=y
-CONFIG_NET_ETHERNET=y
-CONFIG_SMSC911X=y
-# CONFIG_NETDEV_1000 is not set
-# CONFIG_NETDEV_10000 is not set
-# CONFIG_WLAN is not set
-# CONFIG_INPUT_MOUSEDEV_PSAUX is not set
-# CONFIG_INPUT_KEYBOARD is not set
-# CONFIG_INPUT_MOUSE is not set
-CONFIG_SERIAL_SH_SCI=y
-CONFIG_SERIAL_SH_SCI_NR_UARTS=8
-CONFIG_SERIAL_SH_SCI_CONSOLE=y
-# CONFIG_LEGACY_PTYS is not set
-# CONFIG_HW_RANDOM is not set
-CONFIG_I2C=y
-CONFIG_I2C_SH_MOBILE=y
-# CONFIG_HWMON is not set
-# CONFIG_MFD_SUPPORT is not set
-CONFIG_REGULATOR=y
-CONFIG_FB=y
-CONFIG_FB_MODE_HELPERS=y
-CONFIG_FB_SH_MOBILE_LCDC=y
-CONFIG_FB_SH_MOBILE_HDMI=y
-CONFIG_FRAMEBUFFER_CONSOLE=y
-CONFIG_LOGO=y
-# CONFIG_LOGO_LINUX_MONO is not set
-# CONFIG_LOGO_LINUX_CLUT224 is not set
-# CONFIG_SND_SUPPORT_OLD_API is not set
-# CONFIG_SND_VERBOSE_PROCFS is not set
-# CONFIG_SND_DRIVERS is not set
-# CONFIG_SND_ARM is not set
-CONFIG_SND_SOC_SH4_FSI=y
-CONFIG_USB=y
-CONFIG_USB_RENESAS_USBHS_HCD=y
-CONFIG_USB_RENESAS_USBHS=y
-CONFIG_USB_STORAGE=y
-CONFIG_USB_GADGET=y
-CONFIG_USB_RENESAS_USBHS_UDC=y
-CONFIG_MMC=y
-CONFIG_MMC_SDHI=y
-CONFIG_MMC_SH_MMCIF=y
-CONFIG_DMADEVICES=y
-CONFIG_SH_DMAE=y
-CONFIG_EXT2_FS=y
-CONFIG_EXT2_FS_XATTR=y
-CONFIG_EXT2_FS_POSIX_ACL=y
-CONFIG_EXT2_FS_SECURITY=y
-CONFIG_EXT2_FS_XIP=y
-CONFIG_EXT3_FS=y
-# CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set
-CONFIG_EXT3_FS_POSIX_ACL=y
-CONFIG_EXT3_FS_SECURITY=y
-# CONFIG_DNOTIFY is not set
-CONFIG_MSDOS_FS=y
-CONFIG_VFAT_FS=y
-CONFIG_TMPFS=y
-# CONFIG_MISC_FILESYSTEMS is not set
-CONFIG_NFS_FS=y
-CONFIG_NFS_V3=y
-CONFIG_NFS_V3_ACL=y
-CONFIG_NFS_V4=y
-CONFIG_NFS_V4_1=y
-CONFIG_ROOT_NFS=y
-CONFIG_NLS_CODEPAGE_437=y
-CONFIG_NLS_CODEPAGE_737=y
-CONFIG_NLS_CODEPAGE_775=y
-CONFIG_NLS_CODEPAGE_850=y
-CONFIG_NLS_CODEPAGE_852=y
-CONFIG_NLS_CODEPAGE_855=y
-CONFIG_NLS_CODEPAGE_857=y
-CONFIG_NLS_CODEPAGE_860=y
-CONFIG_NLS_CODEPAGE_861=y
-CONFIG_NLS_CODEPAGE_862=y
-CONFIG_NLS_CODEPAGE_863=y
-CONFIG_NLS_CODEPAGE_864=y
-CONFIG_NLS_CODEPAGE_865=y
-CONFIG_NLS_CODEPAGE_866=y
-CONFIG_NLS_CODEPAGE_869=y
-CONFIG_NLS_ISO8859_1=y
-CONFIG_NLS_ISO8859_2=y
-CONFIG_NLS_ISO8859_3=y
-CONFIG_NLS_ISO8859_4=y
-CONFIG_NLS_ISO8859_5=y
-CONFIG_NLS_ISO8859_6=y
-CONFIG_NLS_ISO8859_7=y
-CONFIG_NLS_ISO8859_9=y
-CONFIG_NLS_ISO8859_13=y
-CONFIG_NLS_ISO8859_14=y
-CONFIG_NLS_ISO8859_15=y
-CONFIG_NLS_KOI8_R=y
-CONFIG_NLS_KOI8_U=y
-CONFIG_NLS_UTF8=y
-# CONFIG_ENABLE_WARN_DEPRECATED is not set
-# CONFIG_ENABLE_MUST_CHECK is not set
-# CONFIG_ARM_UNWIND is not set
-CONFIG_CRYPTO=y
-CONFIG_CRYPTO_ANSI_CPRNG=y
-- 
1.7.10.4



From horms+renesas at verge.net.au  Wed Apr  3 23:29:51 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Apr 2013 12:29:51 +0900
Subject: [RFC/PATCH 5/7] ARM: shmobile: defconfig: Remove armadillo800eva
 defconfig
In-Reply-To: <1365046193-19369-1-git-send-email-horms+renesas@verge.net.au>
References: <1365046193-19369-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1365046193-19369-6-git-send-email-horms+renesas@verge.net.au>

Remove armadillo800eva defconfig as the shmobile defconfig may now be used
instead.

Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/configs/armadillo800eva_defconfig |  153 ----------------------------
 1 file changed, 153 deletions(-)
 delete mode 100644 arch/arm/configs/armadillo800eva_defconfig

diff --git a/arch/arm/configs/armadillo800eva_defconfig b/arch/arm/configs/armadillo800eva_defconfig
deleted file mode 100644
index 0f2d80d..0000000
--- a/arch/arm/configs/armadillo800eva_defconfig
+++ /dev/null
@@ -1,153 +0,0 @@
-CONFIG_EXPERIMENTAL=y
-CONFIG_SYSVIPC=y
-CONFIG_IKCONFIG=y
-CONFIG_IKCONFIG_PROC=y
-CONFIG_LOG_BUF_SHIFT=16
-# CONFIG_UTS_NS is not set
-# CONFIG_IPC_NS is not set
-# CONFIG_PID_NS is not set
-CONFIG_CC_OPTIMIZE_FOR_SIZE=y
-CONFIG_PERF_EVENTS=y
-CONFIG_SLAB=y
-CONFIG_MODULES=y
-CONFIG_MODULE_UNLOAD=y
-CONFIG_MODULE_FORCE_UNLOAD=y
-# CONFIG_BLK_DEV_BSG is not set
-# CONFIG_IOSCHED_DEADLINE is not set
-# CONFIG_IOSCHED_CFQ is not set
-CONFIG_ARCH_SHMOBILE=y
-CONFIG_ARCH_R8A7740=y
-CONFIG_MACH_ARMADILLO800EVA=y
-# CONFIG_SH_TIMER_TMU is not set
-CONFIG_ARM_THUMB=y
-CONFIG_CACHE_L2X0=y
-CONFIG_ARM_ERRATA_430973=y
-CONFIG_ARM_ERRATA_458693=y
-CONFIG_ARM_ERRATA_460075=y
-CONFIG_PL310_ERRATA_588369=y
-CONFIG_ARM_ERRATA_720789=y
-CONFIG_PL310_ERRATA_727915=y
-CONFIG_ARM_ERRATA_743622=y
-CONFIG_ARM_ERRATA_751472=y
-CONFIG_PL310_ERRATA_753970=y
-CONFIG_ARM_ERRATA_754322=y
-CONFIG_PL310_ERRATA_769419=y
-CONFIG_ARM_ERRATA_775420=y
-CONFIG_AEABI=y
-# CONFIG_OABI_COMPAT is not set
-CONFIG_FORCE_MAX_ZONEORDER=13
-CONFIG_ZBOOT_ROM_TEXT=0x0
-CONFIG_ZBOOT_ROM_BSS=0x0
-CONFIG_ARM_APPENDED_DTB=y
-CONFIG_KEXEC=y
-CONFIG_VFP=y
-CONFIG_NEON=y
-# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
-CONFIG_PM_RUNTIME=y
-CONFIG_NET=y
-CONFIG_PACKET=y
-CONFIG_UNIX=y
-CONFIG_INET=y
-CONFIG_IP_PNP=y
-CONFIG_IP_PNP_DHCP=y
-# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
-# CONFIG_INET_XFRM_MODE_TUNNEL is not set
-# CONFIG_INET_XFRM_MODE_BEET is not set
-# CONFIG_INET_LRO is not set
-# CONFIG_INET_DIAG is not set
-# CONFIG_IPV6 is not set
-# CONFIG_WIRELESS is not set
-CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
-CONFIG_SCSI=y
-CONFIG_BLK_DEV_SD=y
-CONFIG_MD=y
-CONFIG_BLK_DEV_DM=y
-CONFIG_NETDEVICES=y
-# CONFIG_NET_VENDOR_BROADCOM is not set
-# CONFIG_NET_VENDOR_CHELSIO is not set
-# CONFIG_NET_VENDOR_CIRRUS is not set
-# CONFIG_NET_VENDOR_FARADAY is not set
-# CONFIG_NET_VENDOR_INTEL is not set
-# CONFIG_NET_VENDOR_MARVELL is not set
-# CONFIG_NET_VENDOR_MICREL is not set
-# CONFIG_NET_VENDOR_NATSEMI is not set
-CONFIG_SH_ETH=y
-# CONFIG_NET_VENDOR_SEEQ is not set
-# CONFIG_NET_VENDOR_SMSC is not set
-# CONFIG_NET_VENDOR_STMICRO is not set
-# CONFIG_WLAN is not set
-# CONFIG_INPUT_MOUSEDEV_PSAUX is not set
-CONFIG_INPUT_EVDEV=y
-# CONFIG_KEYBOARD_ATKBD is not set
-CONFIG_KEYBOARD_GPIO=y
-# CONFIG_INPUT_MOUSE is not set
-CONFIG_INPUT_TOUCHSCREEN=y
-CONFIG_TOUCHSCREEN_ST1232=y
-# CONFIG_SERIO is not set
-# CONFIG_LEGACY_PTYS is not set
-CONFIG_SERIAL_SH_SCI=y
-CONFIG_SERIAL_SH_SCI_NR_UARTS=8
-CONFIG_SERIAL_SH_SCI_CONSOLE=y
-# CONFIG_HW_RANDOM is not set
-CONFIG_I2C=y
-CONFIG_I2C_GPIO=y
-CONFIG_I2C_SH_MOBILE=y
-# CONFIG_HWMON is not set
-CONFIG_REGULATOR=y
-CONFIG_MEDIA_SUPPORT=y
-CONFIG_VIDEO_DEV=y
-CONFIG_MEDIA_CAMERA_SUPPORT=y
-CONFIG_V4L_PLATFORM_DRIVERS=y
-CONFIG_SOC_CAMERA=y
-CONFIG_SOC_CAMERA_MT9T112=y
-CONFIG_VIDEO_SH_MOBILE_CEU=y
-CONFIG_FB=y
-CONFIG_FB_SH_MOBILE_LCDC=y
-CONFIG_FB_SH_MOBILE_HDMI=y
-CONFIG_LCD_CLASS_DEVICE=y
-CONFIG_FRAMEBUFFER_CONSOLE=y
-CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y
-CONFIG_LOGO=y
-# CONFIG_LOGO_LINUX_MONO is not set
-# CONFIG_LOGO_LINUX_VGA16 is not set
-# CONFIG_SND_SUPPORT_OLD_API is not set
-# CONFIG_SND_VERBOSE_PROCFS is not set
-# CONFIG_SND_DRIVERS is not set
-# CONFIG_SND_ARM is not set
-CONFIG_SND_SOC_SH4_FSI=y
-# CONFIG_HID_SUPPORT is not set
-CONFIG_USB=y
-CONFIG_USB_RENESAS_USBHS=y
-CONFIG_USB_GADGET=y
-CONFIG_USB_RENESAS_USBHS_UDC=y
-CONFIG_USB_ETH=m
-CONFIG_MMC=y
-CONFIG_MMC_SDHI=y
-CONFIG_MMC_SH_MMCIF=y
-CONFIG_RTC_CLASS=y
-CONFIG_RTC_DRV_S35390A=y
-CONFIG_DMADEVICES=y
-CONFIG_SH_DMAE=y
-CONFIG_UIO=y
-CONFIG_UIO_PDRV_GENIRQ=y
-# CONFIG_DNOTIFY is not set
-CONFIG_MSDOS_FS=y
-CONFIG_VFAT_FS=y
-CONFIG_TMPFS=y
-# CONFIG_MISC_FILESYSTEMS is not set
-CONFIG_NFS_FS=y
-CONFIG_NFS_V3_ACL=y
-CONFIG_NFS_V4=y
-CONFIG_NFS_V4_1=y
-CONFIG_ROOT_NFS=y
-CONFIG_NLS_CODEPAGE_437=y
-CONFIG_NLS_ISO8859_1=y
-# CONFIG_ENABLE_WARN_DEPRECATED is not set
-# CONFIG_ENABLE_MUST_CHECK is not set
-# CONFIG_ARM_UNWIND is not set
-CONFIG_CRYPTO=y
-CONFIG_CRYPTO_CBC=y
-CONFIG_CRYPTO_MD5=y
-CONFIG_CRYPTO_DES=y
-CONFIG_CRYPTO_ANSI_CPRNG=y
-CONFIG_XZ_DEC=y
-- 
1.7.10.4



From horms at verge.net.au  Wed Apr  3 23:32:00 2013
From: horms at verge.net.au (Simon Horman)
Date: Thu, 4 Apr 2013 12:32:00 +0900
Subject: [PATCH/RFC 2/3] ARM: shmobile: initialise clock early on
 kzm9g-reference
In-Reply-To: <1365005636-17526-3-git-send-email-g.liakhovetski@gmx.de>
References: <1365005636-17526-1-git-send-email-g.liakhovetski@gmx.de>
 <1365005636-17526-3-git-send-email-g.liakhovetski@gmx.de>
Message-ID: <20130404033158.GA28297@verge.net.au>

On Wed, Apr 03, 2013 at 06:13:55PM +0200, Guennadi Liakhovetski wrote:
> To prepare to enable TWD on kzm9g-reference, clock initialisation has to be
> done early. Move it from .init_machine to .init_time stage.

I'm pretty surprised by this given how much effort has
been made to avoid early clock initialisation.

> 
> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas at gmail.com>
> ---
>  arch/arm/mach-shmobile/board-kzm9g-reference.c |    8 +++++++-
>  arch/arm/mach-shmobile/setup-sh73a0.c          |   13 +++++++++----
>  2 files changed, 16 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/arm/mach-shmobile/board-kzm9g-reference.c b/arch/arm/mach-shmobile/board-kzm9g-reference.c
> index aefa50d..0f9b276 100644
> --- a/arch/arm/mach-shmobile/board-kzm9g-reference.c
> +++ b/arch/arm/mach-shmobile/board-kzm9g-reference.c
> @@ -90,6 +90,12 @@ static void __init kzm_init(void)
>  #endif
>  }
>  
> +static void __init timer_init(void)
> +{
> +	sh73a0_clock_init();
> +	shmobile_timer_init();
> +}
> +
>  static const char *kzm9g_boards_compat_dt[] __initdata = {
>  	"renesas,kzm9g-reference",
>  	NULL,
> @@ -102,6 +108,6 @@ DT_MACHINE_START(KZM9G_DT, "kzm9g-reference")
>  	.nr_irqs	= NR_IRQS_LEGACY,
>  	.init_irq	= irqchip_init,
>  	.init_machine	= kzm_init,
> -	.init_time	= shmobile_timer_init,
> +	.init_time	= timer_init,
>  	.dt_compat	= kzm9g_boards_compat_dt,
>  MACHINE_END
> diff --git a/arch/arm/mach-shmobile/setup-sh73a0.c b/arch/arm/mach-shmobile/setup-sh73a0.c
> index 0469e84..8a1bc1c 100644
> --- a/arch/arm/mach-shmobile/setup-sh73a0.c
> +++ b/arch/arm/mach-shmobile/setup-sh73a0.c
> @@ -1018,9 +1018,6 @@ void __init sh73a0_add_standard_devices_dt(void)
>  {
>  	struct platform_device_info devinfo = { .name = "cpufreq-cpu0", .id = -1, };
>  
> -	/* clocks are setup late during boot in the case of DT */
> -	sh73a0_clock_init();
> -
>  	platform_add_devices(sh73a0_devices_dt,
>  			     ARRAY_SIZE(sh73a0_devices_dt));
>  	of_platform_populate(NULL, of_default_bus_match_table,
> @@ -1030,6 +1027,14 @@ void __init sh73a0_add_standard_devices_dt(void)
>  	platform_device_register_full(&devinfo);
>  }
>  
> +static void __init add_standard_devices(void)
> +{
> +	/* clocks are setup late during boot in the case of DT */
> +	sh73a0_clock_init();
> +
> +	sh73a0_add_standard_devices_dt();
> +}
> +
>  static const char *sh73a0_boards_compat_dt[] __initdata = {
>  	"renesas,sh73a0",
>  	NULL,
> @@ -1041,7 +1046,7 @@ DT_MACHINE_START(SH73A0_DT, "Generic SH73A0 (Flattened Device Tree)")
>  	.init_early	= sh73a0_init_delay,
>  	.nr_irqs	= NR_IRQS_LEGACY,
>  	.init_irq	= irqchip_init,
> -	.init_machine	= sh73a0_add_standard_devices_dt,
> +	.init_machine	= add_standard_devices,
>  	.init_time	= shmobile_timer_init,
>  	.dt_compat	= sh73a0_boards_compat_dt,
>  MACHINE_END
> -- 
> 1.7.2.5
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


From horms at verge.net.au  Wed Apr  3 23:33:39 2013
From: horms at verge.net.au (Simon Horman)
Date: Thu, 4 Apr 2013 12:33:39 +0900
Subject: [GIT PULL v2] Renesas ARM SoC board updates for v3.10 #3
In-Reply-To: <20130403063059.GB29601@quad.lixom.net>
References: <1364954906-16014-1-git-send-email-horms+renesas@verge.net.au>
 <20130403063059.GB29601@quad.lixom.net>
Message-ID: <20130404033338.GB28297@verge.net.au>

On Tue, Apr 02, 2013 at 11:30:59PM -0700, Olof Johansson wrote:
> Hi,
> 
> On Wed, Apr 03, 2013 at 11:08:15AM +0900, Simon Horman wrote:
> > Hi Olof, Hi Arnd,
> > 
> > The following changes since commit eb0ae7280939fda741ad6ae9b108725517652f56:
> > 
> >   Merge tag 'renesas-pinmux2-for-v3.10' into boards-base (2013-04-03 10:49:18 +0900)
> > 
> > are available in the git repository at:
> > 
> > 
> >   git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-boards3-for-v3.10
> 
> Pulled in in a next/boards2 since it depends on next/soc2.
> 
> >  arch/arm/configs/bockw_defconfig             |   66 +++++++++++++++
> 
> shmobile is now up to 11 defconfigs in arch/arm/configs. It'd be nice if
> you could move towards what OMAP and many other platforms have started
> doing for a while now, with one superset defconfig for the platform
> (well, one for v4/v5 harware and one for v6+).

The not so good news is that there is one more in the pipeline for
the lager board.

The more positive news is that this morning I sent out a series
to try and kick of consolidation. I have CCed you on that series.



From marex at denx.de  Wed Apr  3 23:42:42 2013
From: marex at denx.de (Marek Vasut)
Date: Thu, 4 Apr 2013 05:42:42 +0200
Subject: [PATCH 2/3] ARM: dts: mx53qsb: Add support for parallel display
In-Reply-To: <1365003390-26964-2-git-send-email-rogerio.pimentel@freescale.com>
References: <1365003390-26964-1-git-send-email-rogerio.pimentel@freescale.com>
 <1365003390-26964-2-git-send-email-rogerio.pimentel@freescale.com>
Message-ID: <201304040542.42770.marex@denx.de>

Dear Rogerio Pimentel,

> Add support for CLAA WVGA display for i.MX53 QSB.
> 
> Signed-off-by: Rogerio Pimentel <rogerio.pimentel at freescale.com>
> ---
>  arch/arm/boot/dts/imx53-qsb.dtsp |   26 ++++++++++++++++++++++++++
>  arch/arm/boot/dts/imx53.dtsip    |   35
> +++++++++++++++++++++++++++++++++++ 2 files changed, 61 insertions(+)

Reviewed-by: Marek Vasut <marex at denx.de>

Best regards,
Marek Vasut


From horms at verge.net.au  Wed Apr  3 23:54:26 2013
From: horms at verge.net.au (Simon Horman)
Date: Thu, 4 Apr 2013 12:54:26 +0900
Subject: [PATCH/RFC 0/2] ARM: shmobile: DT irqpin for r8a7779 and
 marzen-reference
In-Reply-To: <Pine.LNX.4.64.1304031103590.10531@axis700.grange>
References: <Pine.LNX.4.64.1304031103590.10531@axis700.grange>
Message-ID: <20130404035426.GC28297@verge.net.au>

On Wed, Apr 03, 2013 at 11:18:57AM +0200, Guennadi Liakhovetski wrote:
> Hi
> 
> This 2 patches add DT irqpin support on marzen-reference. Only 
> compile-tested due to the lack of hardware. The patches can go 
> independently via their respective trees. irqpin on marzen will not work 
> if patch 2 is applied before patch 1, but as long as there are no devices, 
> using irqpin interrupts, no breakage will be caused.

I have applied both patches and the dependency I mention below.
I have also applied the small patch, inlined below, to hook-up
the LAN controller. Unfortunately it doesn't seem to be receiving
any interrupts. Perhaps I am missing something?


> 
> Guennadi Liakhovetski (2):
>       irqchip: renesas-intc-irqpin: DT binding for sense bitfield width

The above patch depends on "[1/3] ARM: shmobile: irqpin: fix handling of
spurious interrupts in DT case", right? Has there been any progress in your
discussions with Magnus about what to do about that patch?

>       ARM: shmobile: marzen-reference: add irqpin support in DT

LAN patch:

diff --git a/arch/arm/boot/dts/r8a7779-marzen-reference.dts b/arch/arm/boot/dts/r8a7779-marzen-reference.dts
index 72be4c8..3d98833 100644
--- a/arch/arm/boot/dts/r8a7779-marzen-reference.dts
+++ b/arch/arm/boot/dts/r8a7779-marzen-reference.dts
@@ -38,8 +38,8 @@
 		compatible = "smsc,lan9220", "smsc,lan9115";
 		reg = <0x18000000 0x100>;
 		phy-mode = "mii";
-		interrupt-parent = <&gic>;
-		interrupts = <0 28 0x4>;
+		interrupt-parent = <&irqpin0>;
+		interrupts = <28 0>;
 		reg-io-width = <4>;
 		vddvario-supply = <&fixedregulator3v3>;
 		vdd33a-supply = <&fixedregulator3v3>;


Boot log and /proc/interrupts with LAN patch (version without LAN patch is below):

Booting Linux on physical CPU 0x0
Linux version 3.9.0-rc2-00003-gd779a6cb-dirty (horms at ayumi.isobedori.kobe.vergenet.net) (gcc version 4.5.2 (Sourcery G++ Lite 2011.03-41) ) #1433 SMP Thu Apr 4 12:43:06 JST 2013
CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=10c53c7d
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
Machine: marzen, model: marzen
debug: ignoring loglevel setting.
Memory policy: ECC disabled, Data cache writealloc
On node 0 totalpages: 262144
free_area_init_node: node 0, pgdat c03cdb00, node_mem_map c055a000
  Normal zone: 1520 pages used for memmap
  Normal zone: 0 pages reserved
  Normal zone: 194560 pages, LIFO batch:31
  HighMem zone: 528 pages used for memmap
  HighMem zone: 67584 pages, LIFO batch:15
PERCPU: Embedded 5 pages/cpu @c0d62000 s6848 r0 d13632 u32768
pcpu-alloc: s6848 r0 d13632 u32768 alloc=8*4096
pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 260624
Kernel command line: console=ttySC2,115200 earlyprintk=sh-sci.2,115200 ignore_loglevel root=/dev/nfs ip=on
PID hash table entries: 4096 (order: 2, 16384 bytes)
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
__ex_table already sorted, skipping sort
Memory: 1024MB = 1024MB total
Memory: 1035404k/1035404k available, 13172k reserved, 270336K highmem
Virtual kernel memory layout:
    vector  : 0xffff0000 - 0xffff1000   (   4 kB)
    fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
    vmalloc : 0xf0000000 - 0xff000000   ( 240 MB)
    lowmem  : 0xc0000000 - 0xef800000   ( 760 MB)
    pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
      .text : 0xc0008000 - 0xc0380d20   (3556 kB)
      .init : 0xc0381000 - 0xc03a8ac0   ( 159 kB)
      .data : 0xc03aa000 - 0xc03ce6c0   ( 146 kB)
       .bss : 0xc03ce6c0 - 0xc03f9134   ( 171 kB)
Hierarchical RCU implementation.
NR_IRQS:16 nr_irqs:16 16
sched_clock: 32 bits at 1kHz, resolution 976562ns, wraps every 4194303999ms
Calibrating delay loop (skipped) preset value.. 1000.00 BogoMIPS (lpj=488000)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
Setting up static identity map for 0xc02dc328 - 0xc02dc380
CPU1: Booted secondary processor
CPU2: Booted secondary processor
CPU3: Booted secondary processor
Brought up 4 CPUs
SMP: Total of 4 processors activated (4000.00 BogoMIPS).
CPU: All CPU(s) started in SVC mode.
devtmpfs: initialized
pinctrl core: initialized pinctrl subsystem
NET: Registered protocol family 16
DMA: preallocated 256 KiB pool for atomic coherent allocations
sh-pfc pfc-r8a7779: r8a7779_pfc support registered
renesas_intc_irqpin fe78001c.irqpin: driving 4 irqs
------------[ cut here ]------------
WARNING: at kernel/irq/irqdomain.c:766 irq_linear_revmap+0x3c/0x44()
[<c000edc0>] (unwind_backtrace+0x0/0xf8) from [<c0017628>] (warn_slowpath_common+0x50/0x64)
[<c0017628>] (warn_slowpath_common+0x50/0x64) from [<c00176f0>] (warn_slowpath_null+0x1c/0x24)
[<c00176f0>] (warn_slowpath_null+0x1c/0x24) from [<c006356c>] (irq_linear_revmap+0x3c/0x44)
[<c006356c>] (irq_linear_revmap+0x3c/0x44) from [<c0063658>] (irq_create_mapping+0x20/0x118)
[<c0063658>] (irq_create_mapping+0x20/0x118) from [<c00637cc>] (irq_create_of_mapping+0x7c/0x100)
[<c00637cc>] (irq_create_of_mapping+0x7c/0x100) from [<c0224c00>] (irq_of_parse_and_map+0x30/0x38)
[<c0224c00>] (irq_of_parse_and_map+0x30/0x38) from [<c0224c20>] (of_irq_to_resource+0x18/0x74)
[<c0224c20>] (of_irq_to_resource+0x18/0x74) from [<c0224ca0>] (of_irq_count+0x24/0x34)
[<c0224ca0>] (of_irq_count+0x24/0x34) from [<c0225508>] (of_device_alloc+0x1b8/0x248)
[<c0225508>] (of_device_alloc+0x1b8/0x248) from [<c02255d4>] (of_platform_device_create_pdata+0x3c/0x80)
[<c02255d4>] (of_platform_device_create_pdata+0x3c/0x80) from [<c02256ec>] (of_platform_bus_create+0xd4/0x178)
[<c02256ec>] (of_platform_bus_create+0xd4/0x178) from [<c02258cc>] (of_platform_populate+0x60/0x98)
[<c02258cc>] (of_platform_populate+0x60/0x98) from [<c0382854>] (customize_machine+0x20/0x28)
[<c0382854>] (customize_machine+0x20/0x28) from [<c0381834>] (do_one_initcall+0xa0/0x16c)
[<c0381834>] (do_one_initcall+0xa0/0x16c) from [<c0381a2c>] (kernel_init_freeable+0x12c/0x1d0)
[<c0381a2c>] (kernel_init_freeable+0x12c/0x1d0) from [<c02cfd6c>] (kernel_init+0x8/0xe8)
[<c02cfd6c>] (kernel_init+0x8/0xe8) from [<c0009e18>] (ret_from_fork+0x14/0x3c)
---[ end trace a30592ddc9049899 ]---
------------[ cut here ]------------
WARNING: at kernel/irq/irqdomain.c:766 irq_linear_revmap+0x3c/0x44()
[<c000edc0>] (unwind_backtrace+0x0/0xf8) from [<c0017628>] (warn_slowpath_common+0x50/0x64)
[<c0017628>] (warn_slowpath_common+0x50/0x64) from [<c00176f0>] (warn_slowpath_null+0x1c/0x24)
[<c00176f0>] (warn_slowpath_null+0x1c/0x24) from [<c006356c>] (irq_linear_revmap+0x3c/0x44)
[<c006356c>] (irq_linear_revmap+0x3c/0x44) from [<c0063658>] (irq_create_mapping+0x20/0x118)
[<c0063658>] (irq_create_mapping+0x20/0x118) from [<c00637cc>] (irq_create_of_mapping+0x7c/0x100)
[<c00637cc>] (irq_create_of_mapping+0x7c/0x100) from [<c0224c00>] (irq_of_parse_and_map+0x30/0x38)
[<c0224c00>] (irq_of_parse_and_map+0x30/0x38) from [<c0224c20>] (of_irq_to_resource+0x18/0x74)
[<c0224c20>] (of_irq_to_resource+0x18/0x74) from [<c0224d28>] (of_irq_to_resource_table+0x78/0x94)
[<c0224d28>] (of_irq_to_resource_table+0x78/0x94) from [<c02254a4>] (of_device_alloc+0x154/0x248)
[<c02254a4>] (of_device_alloc+0x154/0x248) from [<c02255d4>] (of_platform_device_create_pdata+0x3c/0x80)
[<c02255d4>] (of_platform_device_create_pdata+0x3c/0x80) from [<c02256ec>] (of_platform_bus_create+0xd4/0x178)
[<c02256ec>] (of_platform_bus_create+0xd4/0x178) from [<c02258cc>] (of_platform_populate+0x60/0x98)
[<c02258cc>] (of_platform_populate+0x60/0x98) from [<c0382854>] (customize_machine+0x20/0x28)
[<c0382854>] (customize_machine+0x20/0x28) from [<c0381834>] (do_one_initcall+0xa0/0x16c)
[<c0381834>] (do_one_initcall+0xa0/0x16c) from [<c0381a2c>] (kernel_init_freeable+0x12c/0x1d0)
[<c0381a2c>] (kernel_init_freeable+0x12c/0x1d0) from [<c02cfd6c>] (kernel_init+0x8/0xe8)
[<c02cfd6c>] (kernel_init+0x8/0xe8) from [<c0009e18>] (ret_from_fork+0x14/0x3c)
---[ end trace a30592ddc904989a ]---
No ATAGs?
[<c0229260>] (of_platform_device_create_pdata+0x3c/0x80) from [<c0229378>] (of_platform_bus_create+0xd4/0x178)
[<c0229378>] (of_platform_bus_create+0xd4/0x178) from [<c0229558>] (of_platform_populate+0x60/0x98)
[<c0229558>] (of_platform_populate+0x60/0x98) from [<c0387714>] (customize_machine+0x20/0x28)
[<c0387714>] (customize_machine+0x20/0x28) from [<c0385888>] (do_one_initcall+0xa0/0x16c)
[<c0385888>] (do_one_initcall+0xa0/0x16c) from [<c0385a80>] (kernel_init_freeable+0x12c/0x1d0)
[<c0385a80>] (kernel_init_freeable+0x12c/0x1d0) from [<c02d39f8>] (kernel_init+0x8/0xe8)
[<c02d39f8>] (kernel_init+0x8/0xe8) from [<c0009e98>] (ret_from_fork+0x14/0x3c)
---[ end trace a30592ddc9049899 ]---
------------[ cut here ]------------
WARNING: at kernel/irq/irqdomain.c:766 irq_linear_revmap+0x3c/0x44()
[<c000ee40>] (unwind_backtrace+0x0/0xf8) from [<c0017888>] (warn_slowpath_common+0x50/0x64)
[<c0017888>] (warn_slowpath_common+0x50/0x64) from [<c0017950>] (warn_slowpath_null+0x1c/0x24)
[<c0017950>] (warn_slowpath_null+0x1c/0x24) from [<c00637cc>] (irq_linear_revmap+0x3c/0x44)
[<c00637cc>] (irq_linear_revmap+0x3c/0x44) from [<c00638b8>] (irq_create_mapping+0x20/0x118)
[<c00638b8>] (irq_create_mapping+0x20/0x118) from [<c0063a2c>] (irq_create_of_mapping+0x7c/0x100)
[<c0063a2c>] (irq_create_of_mapping+0x7c/0x100) from [<c022888c>] (irq_of_parse_and_map+0x30/0x38)
[<c022888c>] (irq_of_parse_and_map+0x30/0x38) from [<c02288ac>] (of_irq_to_resource+0x18/0x74)
[<c02288ac>] (of_irq_to_resource+0x18/0x74) from [<c02289b4>] (of_irq_to_resource_table+0x78/0x94)
[<c02289b4>] (of_irq_to_resource_table+0x78/0x94) from [<c0229130>] (of_device_alloc+0x154/0x248)
[<c0229130>] (of_device_alloc+0x154/0x248) from [<c0229260>] (of_platform_device_create_pdata+0x3c/0x80)
[<c0229260>] (of_platform_device_create_pdata+0x3c/0x80) from [<c0229378>] (of_platform_bus_create+0xd4/0x178)
[<c0229378>] (of_platform_bus_create+0xd4/0x178) from [<c0229558>] (of_platform_populate+0x60/0x98)
[<c0229558>] (of_platform_populate+0x60/0x98) from [<c0387714>] (customize_machine+0x20/0x28)
[<c0387714>] (customize_machine+0x20/0x28) from [<c0385888>] (do_one_initcall+0xa0/0x16c)
[<c0385888>] (do_one_initcall+0xa0/0x16c) from [<c0385a80>] (kernel_init_freeable+0x12c/0x1d0)
[<c0385a80>] (kernel_init_freeable+0x12c/0x1d0) from [<c02d39f8>] (kernel_init+0x8/0xe8)
[<c02d39f8>] (kernel_init+0x8/0xe8) from [<c0009e98>] (ret_from_fork+0x14/0x3c)
---[ end trace a30592ddc904989a ]---
No ATAGs?
bio: create slab <bio-0> at 0
SCSI subsystem initialized
libata version 3.00 loaded.
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
sh_tmu sh_tmu.0: used for clock events
sh_tmu sh_tmu.0: used for periodic clock events
sh_tmu sh_tmu.1: used as clock source
Switching to clocksource sh_tmu.1
Clockevents: could not switch to one-shot mode:
Clockevents: could not switch to one-shot mode:
Clockevents: could not switch to one-shot mode:
 dummy_timer is not functional.
 dummy_timer is not functional.
Clockevents: could not switch to one-shot mode: dummy_timer is not functional.
 dummy_timer is not functional.
NET: Registered protocol family 2
TCP established hash table entries: 8192 (order: 4, 65536 bytes)
TCP bind hash table entries: 8192 (order: 4, 65536 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
TCP: reno registered
UDP hash table entries: 512 (order: 2, 16384 bytes)
UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
bounce pool size: 64 pages
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 254)
io scheduler noop registered
io scheduler deadline registered (default)
gpio_rcar gpio_rcar.0: driving 32 GPIOs
gpio_rcar gpio_rcar.1: driving 32 GPIOs
gpio_rcar gpio_rcar.2: driving 32 GPIOs
gpio_rcar gpio_rcar.3: driving 32 GPIOs
gpio_rcar gpio_rcar.4: driving 32 GPIOs
gpio_rcar gpio_rcar.5: driving 32 GPIOs
gpio_rcar gpio_rcar.6: driving 9 GPIOs
SuperH SCI(F) driver initialized
sh-sci.0: ttySC0 at MMIO 0xffe40000 (irq = 120) is a scif
sh-sci.1: ttySC1 at MMIO 0xffe41000 (irq = 121) is a scif
sh-sci.2: ttySC2 at MMIO 0xffe42000 (irq = 122) is a scif
console [ttySC2] enabled
sh-sci.3: ttySC3 at MMIO 0xffe43000 (irq = 123) is a scif
sh-sci.4: ttySC4 at MMIO 0xffe44000 (irq = 124) is a scif
sh-sci.5: ttySC5 at MMIO 0xffe45000 (irq = 125) is a scif
scsi0 : sata_rcar
ata1: SATA max UDMA/133 irq 132
smsc911x: Driver version 2008-10-21
libphy: smsc911x-mdio: probed
smsc911x 18000000.lan0 eth0: attached PHY driver [Generic PHY] (mii_bus:phy_addr=18000000.lan0-ff:01, irq=-1)
smsc911x 18000000.lan0 eth0: MAC Address: 2e:09:0a:00:3c:de
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ehci-platform: EHCI generic platform driver
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
Initializing USB Mass Storage driver...
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
rcar_thermal ffc48000.thermal: 1 sensor proved
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
TCP: cubic registered
ata1: link resume succeeded after 1 retries
ata1: SATA link down (SStatus 0 SControl 300)
smsc911x 18000000.lan0 eth0: ISR failed signaling test (IRQ 257)
IP-Config: Failed to open eth0
IP-Config: No network devices available

Freeing init memory: 2916K


boot (Linux 3.9.0-rc2-00003-gd779a6cb-dirty, BusyBox v1.16.0.git, kexec-tools 2.0.1-git)
/ # 
/ # cat /proc/interrupts 
           CPU0       CPU1       CPU2       CPU3       
 59:          0          0          0          0       GIC  fe78001c.irqpin
 60:          0          0          0          0       GIC  fe78001c.irqpin
 61:          0          0          0          0       GIC  fe78001c.irqpin
 62:          0          0          0          0       GIC  fe78001c.irqpin
 64:       8493          0          0          0       GIC  sh_tmu.0
122:         48          0          0          0       GIC  sh-sci.2:mux
132:          0          0          0          0       GIC  sata_rcar
173:          0          0          0          0       GIC  gpio_rcar.0
174:          0          0          0          0       GIC  gpio_rcar.1
175:          0          0          0          0       GIC  gpio_rcar.2
176:          0          0          0          0       GIC  gpio_rcar.3
177:          0          0          0          0       GIC  gpio_rcar.4
178:          0          0          0          0       GIC  gpio_rcar.5
179:          0          0          0          0       GIC  gpio_rcar.6
257:          0          0          0          0  fe78001c.irqpin  eth0
IPI0:          0          0          0          0  CPU wakeup interrupts
IPI1:          0       7869       8493       8487  Timer broadcast interrupts
IPI2:        446        503         73         46  Rescheduling interrupts
IPI3:         21         37         54         56  Function call interrupts
IPI4:          0          0          0          0  Single function call interrupts
IPI5:          0          0          0          0  CPU stop interrupts
Err:          0
/ # 

Boot log and /proc/interrupts with LAN patch (version without LAN patch is below):

Booting Linux on physical CPU 0x0
Linux version 3.9.0-rc2-00003-gd779a6cb (horms at ayumi.isobedori.kobe.vergenet.net) (gcc version 4.5.2 (Sourcery G++ Lite 2011.03-41) ) #1435 SMP Thu Apr 4 12:51:52 JST 2013
CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=10c53c7d
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
Machine: marzen, model: marzen
debug: ignoring loglevel setting.
Memory policy: ECC disabled, Data cache writealloc
On node 0 totalpages: 262144
free_area_init_node: node 0, pgdat c0683b00, node_mem_map c08fb000
  Normal zone: 1520 pages used for memmap
  Normal zone: 0 pages reserved
  Normal zone: 194560 pages, LIFO batch:31
  HighMem zone: 528 pages used for memmap
  HighMem zone: 67584 pages, LIFO batch:15
PERCPU: Embedded 5 pages/cpu @c1103000 s6848 r0 d13632 u32768
pcpu-alloc: s6848 r0 d13632 u32768 alloc=8*4096
pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 260624
Kernel command line: console=ttySC2,115200 earlyprintk=sh-sci.2,115200 ignore_loglevel root=/dev/nfs ip=on
PID hash table entries: 4096 (order: 2, 16384 bytes)
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
__ex_table already sorted, skipping sort
Memory: 1024MB = 1024MB total
Memory: 1032628k/1032628k available, 15948k reserved, 270336K highmem
Virtual kernel memory layout:
    vector  : 0xffff0000 - 0xffff1000   (   4 kB)
    fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
    vmalloc : 0xf0000000 - 0xff000000   ( 240 MB)
    lowmem  : 0xc0000000 - 0xef800000   ( 760 MB)
    pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
      .text : 0xc0008000 - 0xc0384e4c   (3572 kB)
      .init : 0xc0385000 - 0xc065eac0   (2919 kB)
      .data : 0xc0660000 - 0xc06846c0   ( 146 kB)
       .bss : 0xc06846c0 - 0xc06af174   ( 171 kB)
Hierarchical RCU implementation.
NR_IRQS:16 nr_irqs:16 16
sched_clock: 32 bits at 1kHz, resolution 976562ns, wraps every 4194303999ms
Calibrating delay loop (skipped) preset value.. 1000.00 BogoMIPS (lpj=488000)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
Setting up static identity map for 0xc02df328 - 0xc02df380
CPU1: Booted secondary processor
CPU2: Booted secondary processor
CPU3: Booted secondary processor
Brought up 4 CPUs
SMP: Total of 4 processors activated (4000.00 BogoMIPS).
CPU: All CPU(s) started in SVC mode.
devtmpfs: initialized
pinctrl core: initialized pinctrl subsystem
NET: Registered protocol family 16
DMA: preallocated 256 KiB pool for atomic coherent allocations
sh-pfc pfc-r8a7779: r8a7779_pfc support registered
renesas_intc_irqpin fe78001c.irqpin: driving 4 irqs
No ATAGs?
bio: create slab <bio-0> at 0
SCSI subsystem initialized
libata version 3.00 loaded.
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
sh_tmu sh_tmu.0: used for clock events
sh_tmu sh_tmu.0: used for periodic clock events
sh_tmu sh_tmu.1: used as clock source
Switching to clocksource sh_tmu.1
Clockevents: could not switch to one-shot mode:
Clockevents: could not switch to one-shot mode:
Clockevents: could not switch to one-shot mode:
 dummy_timer is not functional.
 dummy_timer is not functional.
Clockevents: could not switch to one-shot mode: dummy_timer is not functional.
 dummy_timer is not functional.
NET: Registered protocol family 2
TCP established hash table entries: 8192 (order: 4, 65536 bytes)
TCP bind hash table entries: 8192 (order: 4, 65536 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
TCP: reno registered
UDP hash table entries: 512 (order: 2, 16384 bytes)
UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
bounce pool size: 64 pages
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 254)
io scheduler noop registered
io scheduler deadline registered (default)
gpio_rcar gpio_rcar.0: driving 32 GPIOs
gpio_rcar gpio_rcar.1: driving 32 GPIOs
gpio_rcar gpio_rcar.2: driving 32 GPIOs
gpio_rcar gpio_rcar.3: driving 32 GPIOs
gpio_rcar gpio_rcar.4: driving 32 GPIOs
gpio_rcar gpio_rcar.5: driving 32 GPIOs
gpio_rcar gpio_rcar.6: driving 9 GPIOs
SuperH SCI(F) driver initialized
sh-sci.0: ttySC0 at MMIO 0xffe40000 (irq = 120) is a scif
sh-sci.1: ttySC1 at MMIO 0xffe41000 (irq = 121) is a scif
sh-sci.2: ttySC2 at MMIO 0xffe42000 (irq = 122) is a scif
console [ttySC2] enabled
sh-sci.3: ttySC3 at MMIO 0xffe43000 (irq = 123) is a scif
sh-sci.4: ttySC4 at MMIO 0xffe44000 (irq = 124) is a scif
sh-sci.5: ttySC5 at MMIO 0xffe45000 (irq = 125) is a scif
scsi0 : sata_rcar
ata1: SATA max UDMA/133 irq 132
smsc911x: Driver version 2008-10-21
genirq: Flags mismatch irq 60. 00000080 (eth%d) vs. 00000000 (fe78001c.irqpin)
smsc911x: probe of 18000000.lan0 failed with error -16
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ehci-platform: EHCI generic platform driver
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
Initializing USB Mass Storage driver...
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
rcar_thermal ffc48000.thermal: 1 sensor proved
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
TCP: cubic registered
ata1: link resume succeeded after 1 retries
ata1: SATA link down (SStatus 0 SControl 300)
Freeing init memory: 2916K


boot (Linux 3.9.0-rc2-00003-gd779a6cb, BusyBox v1.16.0.git, kexec-tools 2.0.1-git)
/ # cat /proc/interrupts 
           CPU0       CPU1       CPU2       CPU3       
 59:          0          0          0          0       GIC  fe78001c.irqpin
 60:          0          0          0          0       GIC  fe78001c.irqpin
 61:          0          0          0          0       GIC  fe78001c.irqpin
 62:          0          0          0          0       GIC  fe78001c.irqpin
 64:      49198          0          0          0       GIC  sh_tmu.0
122:         45          0          0          0       GIC  sh-sci.2:mux
132:          0          0          0          0       GIC  sata_rcar
173:          0          0          0          0       GIC  gpio_rcar.0
174:          0          0          0          0       GIC  gpio_rcar.1
175:          0          0          0          0       GIC  gpio_rcar.2
176:          0          0          0          0       GIC  gpio_rcar.3
177:          0          0          0          0       GIC  gpio_rcar.4
178:          0          0          0          0       GIC  gpio_rcar.5
179:          0          0          0          0       GIC  gpio_rcar.6
IPI0:          0          0          0          0  CPU wakeup interrupts
IPI1:          0      49192      49198      48802  Timer broadcast interrupts
IPI2:        437        478         87         88  Rescheduling interrupts
IPI3:         56         37         36         39  Function call interrupts
IPI4:          0          0          0          0  Single function call interrupts
IPI5:          0          0          0          0  CPU stop interrupts
Err:  


From dgilbert at interlog.com  Wed Apr  3 23:54:45 2013
From: dgilbert at interlog.com (Douglas Gilbert)
Date: Wed, 03 Apr 2013 23:54:45 -0400
Subject: [PATCH] rtc: rtc-at91sam9.c add DT support
Message-ID: <515CF985.6050009@interlog.com>

Some members of the at91 SoCs use the Real Time Timer (RTT)
and the General Purpose Backup Registers (GPBR) to implement
a real time clock (RTC). The AT91SAM9G20 is one example.

Attached is a patch to add DT support to rtc-at91sam9.c .
The patch is against lk 3.9.0-rc5 .

Below is a snippet of DT code for the 'G20 that was observed
to work with this patch:

ahb {
	apb {

		rtc {
			compatible = "atmel,at91sam9-rtc";
                          /* RTTC followed by GPBR (backup registers) */
                          reg = <0xfffffd20 0x10>, <0xfffffd50 0x10>;
                          interrupts = <1 4 7>;
                          status = "okay";
		};
	}
};

Signed-off-by: Douglas Gilbert <dgilbert at interlog.com>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: fg20_rtc_at91sam9.patch
Type: text/x-patch
Size: 1015 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130403/2c30a653/attachment.bin>

From kgene.kim at samsung.com  Thu Apr  4 00:06:35 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Thu, 04 Apr 2013 13:06:35 +0900
Subject: [PATCH v2 0/4] clk: samsung: pm fixes and multiple aliases
In-Reply-To: <20130327005912.4014.60318@quantum>
References: <201303131458.18671.heiko@sntech.de>
 <176601ce293a$d7a0e190$86e2a4b0$%kim@samsung.com>
 <20130327005912.4014.60318@quantum>
Message-ID: <272701ce30e9$cc816b70$65844250$%kim@samsung.com>

Mike Turquette wrote:
> 
> Quoting Kukjin Kim (2013-03-25 02:26:34)
> > Heiko St?bner wrote:
> > >
> > > Second version of the fixes to address comments gathered from the
> first
> > > version, like not entering the dt code on non-dt platforms even if
> > > dt-support is present in the kernel.
> > >
> > > Patch 1 and 3 got "Reviewed-by" tags but I only included the one for
> > > patch 1, because patch 3 changed due to the changes in patch 2.
> > >
> > > Heiko Stuebner (4):
> > >   clk: samsung: register clk_div_tables for divider clocks
> > >   clk: samsung: fix pm init on non-dt platforms
> > >   clk: samsung: always allocate the clk_table
> > >   clk: samsung: add infrastructure to add separate aliases
> > >
> > >  drivers/clk/samsung/clk.c |   72 +++++++++++++++++++++++++++++++++++--
> ----
> > > ---
> > >  drivers/clk/samsung/clk.h |   34 ++++++++++++++++++--
> > >  2 files changed, 87 insertions(+), 19 deletions(-)
> > >
> > > --
> > > 1.7.2.3
> >
> > Looks good to me and applied into samsung tree based on samsung common
> clock by Thomas P Abraham for testing.
> >
> > But would be helpful to me if I could get Mike's ack on this series.
> >
> 
> Acked-by: Mike Turquette <mturquette at linaro.org>
> 
Applied, thanks.

- Kukjin



From linux at prisktech.co.nz  Thu Apr  4 00:30:04 2013
From: linux at prisktech.co.nz (Tony Prisk)
Date: Thu, 04 Apr 2013 17:30:04 +1300
Subject: [PATCHv5 0/7] arm: vt8500: Add support for pinctrl/gpio module
In-Reply-To: <515C9DB7.9000908@wwwdotorg.org>
References: <1364970291-17721-1-git-send-email-linux@prisktech.co.nz>
 <CACRpkdZAtgpfA5rZ_C=eKDDOE9aDm=3k1QDava=EGL2BaoV+0g@mail.gmail.com>
 <515C9DB7.9000908@wwwdotorg.org>
Message-ID: <515D01CC.2060606@prisktech.co.nz>

On 04/04/13 10:23, Stephen Warren wrote:
> On 04/03/2013 07:40 AM, Linus Walleij wrote:
>> On Wed, Apr 3, 2013 at 8:24 AM, Tony Prisk <linux at prisktech.co.nz> wrote:
>>
>>> v5 changes:
>>> Changed as requested by Rob Herring:
>>> Added of_find_property_value_of_size() to drivers/of/base.c to remove some
>>> code that was being duplicated.
>>>
>>> Changed as requested by Stephen Warren:
>>> Redid the kfree(maps) code as devm_kzalloc would cause issues. We now kzalloc
>>> maps all at once, and configs as required. A call to wmt_pctl_dt_free_map() is
>>> used to kfree the allocated blocks if we fail early.
>> This v5 series:
>> Acked-by: Linus Walleij <linus.walleij at linaro.org>
>>
>> I guess it will go in through the VT8500 tree eventually?
>>
>> Maybe you could put Stephen's BCMring patch on top when sending
>> it in (also Acked-by) so we can avoid having that dangling.
> s/bcmring/bcm2835/ :-)
Stephen,

Can you just confirm you want:

pinctrl: bcm2835: make use of of_property_read_u32_index()

to be included in the pull with this series. I'll get it sent out once 
you let me know.

Regards
Tony P


From horms at verge.net.au  Thu Apr  4 00:37:46 2013
From: horms at verge.net.au (Simon Horman)
Date: Thu, 4 Apr 2013 13:37:46 +0900
Subject: [PATCH v4 3/3] ARM: shmobile: kzm9g-reference: add CPUFreq support
In-Reply-To: <1364153255-20664-4-git-send-email-g.liakhovetski@gmx.de>
References: <1364153255-20664-1-git-send-email-g.liakhovetski@gmx.de>
 <1364153255-20664-4-git-send-email-g.liakhovetski@gmx.de>
Message-ID: <20130404043746.GD28297@verge.net.au>

On Sun, Mar 24, 2013 at 08:27:35PM +0100, Guennadi Liakhovetski wrote:
> This patch enables the use of the generic cpufreq-cpu0 driver on kzm9g.
> Providing a regulator, a list of OPPs in DT, combined with a virtual
> cpufreq-cpu0 platform device and a clock, attached to it is everything,
> the cpufreq-cpu0 driver needs.

I wonder if it would be possible to re-arange this patch a little.

1) vdd_dvfs is added in this patch but it appears to be used in the
   previous patch in the series. I wonder if this can be resolved
   by re-ordering the patches.

2) It includes both kzm9g board and sh73a0 SoC changes.
   I would prefer if the sh73a0 SoC portion (setup-sh73a0.c)
   was moved into a separate patch. The arm-soc people
   like to have separate board and SoC branches.

> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas at gmail.com>
> ---
> 
> v4: add a cpufreq-cpu0 platform device for the new cpufreq-cpu0 
> initialisation procedure
> 
>  arch/arm/boot/dts/sh73a0-kzm9g-reference.dts |    6 +++---
>  arch/arm/mach-shmobile/Kconfig               |    2 ++
>  arch/arm/mach-shmobile/setup-sh73a0.c        |    5 +++++
>  3 files changed, 10 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/sh73a0-kzm9g-reference.dts b/arch/arm/boot/dts/sh73a0-kzm9g-reference.dts
> index dd1cd80..b6f759e 100644
> --- a/arch/arm/boot/dts/sh73a0-kzm9g-reference.dts
> +++ b/arch/arm/boot/dts/sh73a0-kzm9g-reference.dts
> @@ -78,10 +78,10 @@
>  		reg = <0x40>;
>  
>  		regulators {
> -			sd1 {
> +			vdd_dvfs: sd1 {
>  				regulator-name = "1.315V CPU";
> -				regulator-min-microvolt = <1315000>;
> -				regulator-max-microvolt = <1335000>;
> +				regulator-min-microvolt = <1050000>;
> +				regulator-max-microvolt = <1350000>;
>  				regulator-always-on;
>  				regulator-boot-on;
>  			};
> diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
> index eb3a7ff..8a0420b 100644
> --- a/arch/arm/mach-shmobile/Kconfig
> +++ b/arch/arm/mach-shmobile/Kconfig
> @@ -134,6 +134,8 @@ config MACH_KZM9G
>  config MACH_KZM9G_REFERENCE
>  	bool "KZM-A9-GT board - Reference Device Tree Implementation"
>  	depends on ARCH_SH73A0
> +	select ARCH_HAS_CPUFREQ
> +	select ARCH_HAS_OPP
>  	select ARCH_REQUIRE_GPIOLIB
>  	select REGULATOR_FIXED_VOLTAGE if REGULATOR
>  	select SND_SOC_AK4642 if SND_SIMPLE_CARD
> diff --git a/arch/arm/mach-shmobile/setup-sh73a0.c b/arch/arm/mach-shmobile/setup-sh73a0.c
> index e8cd93a..0469e84 100644
> --- a/arch/arm/mach-shmobile/setup-sh73a0.c
> +++ b/arch/arm/mach-shmobile/setup-sh73a0.c
> @@ -1016,6 +1016,8 @@ static const struct of_dev_auxdata sh73a0_auxdata_lookup[] __initconst = {
>  
>  void __init sh73a0_add_standard_devices_dt(void)
>  {
> +	struct platform_device_info devinfo = { .name = "cpufreq-cpu0", .id = -1, };
> +
>  	/* clocks are setup late during boot in the case of DT */
>  	sh73a0_clock_init();
>  
> @@ -1023,6 +1025,9 @@ void __init sh73a0_add_standard_devices_dt(void)
>  			     ARRAY_SIZE(sh73a0_devices_dt));
>  	of_platform_populate(NULL, of_default_bus_match_table,
>  			     sh73a0_auxdata_lookup, NULL);
> +
> +	/* Instantiate cpufreq-cpu0 */
> +	platform_device_register_full(&devinfo);
>  }
>  
>  static const char *sh73a0_boards_compat_dt[] __initdata = {
> -- 
> 1.7.2.5
> 


From avinashphilip at ti.com  Thu Apr  4 00:39:05 2013
From: avinashphilip at ti.com (Philip, Avinash)
Date: Thu, 4 Apr 2013 04:39:05 +0000
Subject: [PATCH v3 0/3] Platform support for EHRPWM & ECAP devices in
 DAVINCI.
In-Reply-To: <515A983D.8040907@ti.com>
References: <1364197789-16783-1-git-send-email-avinashphilip@ti.com>
 <515A983D.8040907@ti.com>
Message-ID: <518397C60809E147AF5323E0420B992E3EAA7C39@DBDE01.ent.ti.com>

On Tue, Apr 02, 2013 at 14:05:09, Nori, Sekhar wrote:
> On 3/25/2013 1:19 PM, Philip Avinash wrote:
> > Add platform support for EHRPWM and ECAP by providing clock nodes and
> > device tree nodes.
> > This series depends on [1] and [2] and is available for testing at [3].
> > Tested for back light support in da850 EVM with EHRPWM PWM device.
> > 
> > [1] http://gitorious.org/linux-davinci/linux-davinci/trees/davinci-for-v3.9/dt-2
> > [2] https://gitorious.org/linux-pwm/linux-pwm/trees/for-next
> > [3] https://github.com/avinashphilip/am335x_linux/tree/davinci-for-v3.9_soc_pwm
> > 
> > Note:
> > DT support for EHRPWM backlight has not been added in da850-evm.dts as there is
> > conflicting pin-mux requirement with SPI flash.
> 
> Can you check if this is really true even in newer boards (have a look
> at the latest schematics)? I remember this used to be a problem in very
> early versions but was fixed later.

On looking schematics, panel has three power controls LCD_BACKLIGHT_PWR, LCD_PANEL_PWR,
LCD_PWM0. On latest schematic, LCD_PWM0 is connected to ECAP instance 2. So backlight
can control through ECAP2 (not conflicting with SPI1 cs0). Still for controlling
backlight, require support for LCD_BACKLIGHT_PWR & LCD_PANEL_PWR. These signals
to be controlled by GPIO 2[8] & GPIO 2[15]. In release platform callbacks used
to control GPIO functionality. But with DT support, I have to check how platform
callbacks can be used.

Thanks
Avinash

> 
> Thanks,
> Sekhar
> 


From horms at verge.net.au  Thu Apr  4 00:41:02 2013
From: horms at verge.net.au (Simon Horman)
Date: Thu, 4 Apr 2013 13:41:02 +0900
Subject: APE6EVM and Runtime PM
In-Reply-To: <87wqsjdlhv.wl%kuninori.morimoto.gx@renesas.com>
References: <20130404020019.GA7163@verge.net.au>
 <87wqsjdlhv.wl%kuninori.morimoto.gx@renesas.com>
Message-ID: <20130404044101.GG28297@verge.net.au>

On Wed, Apr 03, 2013 at 08:26:39PM -0700, Kuninori Morimoto wrote:
> 
> Hi Simon
> 
> > in the course of looking look at consolidating our defconfigs I
> > noticed that SMSC ethernet and rcar_thermal seem seem to not work when
> > runtime PM is enabled.
> > 
> > I'm wondering if you have any ideas of what might be the cause of this
> > or if you could give me some guidance on investigating this problem.
> > 
> > I assume that it relates to a clock or clocks not being enabled.
> 
> About rcar_thermal, it needs my patch which was sent to PM ML.
> I got email from Zhang that he accepted my patch (pm_runtime support for thermal).
> But it seems he didn't push his branch yet...
> I guess I explained this on my [PATCH 0/x] email.

Thanks, sorry for missing that.

I guess we are down to just SMSC then.


From moore at free.fr  Thu Apr  4 00:54:14 2013
From: moore at free.fr (Chris Moore)
Date: Thu, 04 Apr 2013 06:54:14 +0200
Subject: [PATCH] ARM: kirkwood: DT board setup for CloudBox
In-Reply-To: <20130402172454.GT13280@titan.lakedaemon.net>
References: <1364555206-5870-1-git-send-email-simon.guinot@sequanux.org>
 <20130329153132.GJ13280@titan.lakedaemon.net>
 <20130329184109.GA16404@kw.sim.vm.gnt> <51568B89.1060009@free.fr>
 <20130401163316.GC16404@kw.sim.vm.gnt> <515A5BC6.5000007@free.fr>
 <20130402114535.GR13280@titan.lakedaemon.net>
 <20130402125408.GH16404@kw.sim.vm.gnt>
 <20130402172454.GT13280@titan.lakedaemon.net>
Message-ID: <515D0776.7050208@free.fr>

Hi,

Le 02/04/2013 19:24, Jason Cooper a ?crit :
> On Tue, Apr 02, 2013 at 02:54:11PM +0200, Simon Guinot wrote:
>
...

>> There is two different LaCie boards. There is no relations between this
>> boards except their final product name (which is quite silly).
>>
>>  From a LaCie point, there is no board but only product naming. Here are
>> the different names used by LaCie for this two boards/products:
>>
>> 1: netspace_mini_v2 ->  SafeBox ->  CloudBox
>> 2: FamilyBox ->  CloudBox
>>
>> "1" is the oldest board.
> Got it.

I may be thick but I didn't realise that my old black CloudBox was 
already supported under the name netspace_mini_v2 :(
There is no reference to CloudBox anywhere in the kernel; only the 
SafeBox alias (of which I was also unaware) is given in Kconfig.

>> Under Linux, with my patch we are using the following names:
>>
>> 1: netspace_mini_v2
>> 2: cloudbox
>>
>> The problem raised by Chris is that the cloudbox name could be
>> confusing because one could try a "cloudbox" dtb on the board "1". For
>> my part I don't think it is an issue because "1" is rather confidential
>> (and it is an euphemism).
> Agreed.

I wasn't aware that the original CloudBox was so confidential.
I even saw them for sale in my local FNAC (a hi-tech and media shop 
present in most large French shopping centres).

>> It would be more confusing for users if the kernel name for "2" is not
>> cloudbox but cloudbox_{color,number,...} or even familybox. Moreover
>> netspace_mini_v2 is a correct name for "1".
>>
>> IMHO, we could let things as they are. Additionally, I could either
>> extend the Kconfig description and add a some comments in the dts files,
>> in order to to prevent any misunderstanding...
>>
>> Let me know if you agree or not.
> Yes, that makes more sense.  Thanks for clearing it up.  Please add the
> clarifying remarks to the dts.

I agree that it would be confusing to change the netspace_mini_v2 name now.

In view of all the above, please disregard my objection.
Sorry for the noise :(

> As for the model number for the public board (#2), why can't we append
> "-90003xx"?  See [1], Specifications tab.
>
> [1] http://www.lacie.com/us/products/product.htm?id=10597

This seems like a good idea to me but I don't think Simon favoured 
adding a model number.
In any case Simon would know better than me whether this covers the 
models correctly.
What do you think, Simon?

Cheers,
Chris



From swarren at wwwdotorg.org  Thu Apr  4 01:04:16 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Wed, 03 Apr 2013 23:04:16 -0600
Subject: [PATCHv5 0/7] arm: vt8500: Add support for pinctrl/gpio module
In-Reply-To: <515D01CC.2060606@prisktech.co.nz>
References: <1364970291-17721-1-git-send-email-linux@prisktech.co.nz>
 <CACRpkdZAtgpfA5rZ_C=eKDDOE9aDm=3k1QDava=EGL2BaoV+0g@mail.gmail.com>
 <515C9DB7.9000908@wwwdotorg.org> <515D01CC.2060606@prisktech.co.nz>
Message-ID: <cda13d16-0282-4483-bda7-98bb90875c77@email.android.com>

Tony Prisk <linux at prisktech.co.nz> wrote:
...
>Can you just confirm you want:
>
>pinctrl: bcm2835: make use of of_property_read_u32_index()
>
>to be included in the pull with this series. I'll get it sent out once 
>you let me know.

That sounds fine, thanks.


-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.


From linux at prisktech.co.nz  Thu Apr  4 01:18:33 2013
From: linux at prisktech.co.nz (Tony Prisk)
Date: Thu, 04 Apr 2013 18:18:33 +1300
Subject: [GIT PULL] arm: vt8500: Add support for pinctrl/gpio module
Message-ID: <515D0D29.8030203@prisktech.co.nz>

The following changes since commit 8bb9660418e05bb1845ac1a2428444d78e322cc7:

   Linux 3.9-rc4 (2013-03-23 16:52:44 -0700)

are available in the git repository at:

   git://server.prisktech.co.nz/git/linuxwmt.git tags/vt8500/pinctrl

for you to fetch changes up to ce63d6d4bb9f601de32d4b99f925a65182521873:

   pinctrl: bcm2835: make use of of_property_read_u32_index() 
(2013-04-04 18:05:26 +1300)

----------------------------------------------------------------
arm: vt8500: Add pinctrl driver for arch-vt8500

This series adds support for the pinctrl/gpio module on all arch-vt8500
supported SoCs. It also drops the existing GPIO only driver and binding.

As part of the review process, some tidy up is also done to
drivers/of/base.c to remove some code that is being constantly duplicated.

Also, a patch for the bcm2835 pinctrl driver is included to take advantage
of the new of/base.c code from Stephen W.

----------------------------------------------------------------
Stephen Warren (1):
       pinctrl: bcm2835: make use of of_property_read_u32_index()

Tony Prisk (7):
       of: Add support for reading a u32 from a multi-value property.
       of: Remove duplicated code for validating property and value
       arm: vt8500: Increase available GPIOs on arch-vt8500
       pinctrl: gpio: vt8500: Add pincontrol driver for arch-vt8500
       arm: dts: vt8500: Update Wondermedia SoC dtsi files for pinctrl 
driver
       arm: vt8500: Remove gpio devicetree nodes
       gpio: vt8500: Remove arch-vt8500 gpio driver

  .../devicetree/bindings/gpio/gpio-vt8500.txt       |   24 -
  .../devicetree/bindings/pinctrl/pinctrl-vt8500.txt |   57 ++
  arch/arm/Kconfig                                   |    3 +-
  arch/arm/boot/dts/vt8500.dtsi                      |   10 +-
  arch/arm/boot/dts/wm8505.dtsi                      |   10 +-
  arch/arm/boot/dts/wm8650.dtsi                      |   10 +-
  arch/arm/boot/dts/wm8850.dtsi                      |   10 +-
  arch/arm/mach-vt8500/Kconfig                       |    1 +
  drivers/gpio/Kconfig                               |    6 -
  drivers/gpio/Makefile                              |    1 -
  drivers/gpio/gpio-vt8500.c                         |  355 -----------
  drivers/of/base.c                                  |  111 ++--
  drivers/pinctrl/Kconfig                            |    1 +
  drivers/pinctrl/Makefile                           |    1 +
  drivers/pinctrl/pinctrl-bcm2835.c                  |   19 +-
  drivers/pinctrl/vt8500/Kconfig                     |   52 ++
  drivers/pinctrl/vt8500/Makefile                    |    8 +
  drivers/pinctrl/vt8500/pinctrl-vt8500.c            |  501 ++++++++++++++++
  drivers/pinctrl/vt8500/pinctrl-wm8505.c            |  532 ++++++++++++++++
  drivers/pinctrl/vt8500/pinctrl-wm8650.c            |  370 ++++++++++++
  drivers/pinctrl/vt8500/pinctrl-wm8750.c            |  409 +++++++++++++
  drivers/pinctrl/vt8500/pinctrl-wm8850.c            |  388 ++++++++++++
  drivers/pinctrl/vt8500/pinctrl-wmt.c               |  632 
++++++++++++++++++++
  drivers/pinctrl/vt8500/pinctrl-wmt.h               |   79 +++
  include/linux/of.h                                 |    9 +
  25 files changed, 3153 insertions(+), 446 deletions(-)
  delete mode 100644 Documentation/devicetree/bindings/gpio/gpio-vt8500.txt
  create mode 100644 
Documentation/devicetree/bindings/pinctrl/pinctrl-vt8500.txt
  delete mode 100644 drivers/gpio/gpio-vt8500.c
  create mode 100644 drivers/pinctrl/vt8500/Kconfig
  create mode 100644 drivers/pinctrl/vt8500/Makefile
  create mode 100644 drivers/pinctrl/vt8500/pinctrl-vt8500.c
  create mode 100644 drivers/pinctrl/vt8500/pinctrl-wm8505.c
  create mode 100644 drivers/pinctrl/vt8500/pinctrl-wm8650.c
  create mode 100644 drivers/pinctrl/vt8500/pinctrl-wm8750.c
  create mode 100644 drivers/pinctrl/vt8500/pinctrl-wm8850.c
  create mode 100644 drivers/pinctrl/vt8500/pinctrl-wmt.c
  create mode 100644 drivers/pinctrl/vt8500/pinctrl-wmt.h


From rnayak at ti.com  Thu Apr  4 01:20:10 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Thu, 4 Apr 2013 10:50:10 +0530
Subject: [RFC][PATCH 1/2] ARM: OMAP4: clock: Add device tree support for
 AUXCLKs
In-Reply-To: <20130403234242.GE10155@atomide.com>
References: <1363703220-4777-1-git-send-email-rogerq@ti.com>
 <1363703220-4777-2-git-send-email-rogerq@ti.com>
 <20130403234242.GE10155@atomide.com>
Message-ID: <515D0D8A.7030500@ti.com>

Hi Tony,

On Thursday 04 April 2013 05:12 AM, Tony Lindgren wrote:
> Hi,
> 
[]..

>> @@ -1663,6 +1664,40 @@ static struct omap_clk omap44xx_clks[] = {
>>  	CLK(NULL,	"cpufreq_ck",	&dpll_mpu_ck,	CK_443X),
>>  };
>>  
>> +static struct clk *scrm_clks[] = {
>> +	&auxclk0_ck,
>> +	&auxclk1_ck,
>> +	&auxclk2_ck,
>> +	&auxclk3_ck,
>> +	&auxclk4_ck,
>> +	&auxclk5_ck,
>> +};
> 
> Hmm I don't like the idea of specifying the auxclk both in the
> cclock44xx_data.c and in DT..
> 
>> +static struct clk_onecell_data scrm_data;
>> +
>> +#ifdef CONFIG_OF
>> +int __init omap4_clk_init_dt(void)
>> +{
>> +	struct device_node *np;
>> +
>> +	np = of_find_compatible_node(NULL, NULL, "ti,omap4-scrm");
>> +	if (np) {
>> +		scrm_data.clks = scrm_clks;
>> +		scrm_data.clk_num = ARRAY_SIZE(scrm_clks);
>> +		of_clk_add_provider(np, of_clk_src_onecell_get,	&scrm_data);
>> +	}
>> +
>> +	return 0;
>> +}
>> +
>> +#else
>> +
>> +int __init omap4_clk_init_dt(void)
>> +{
>> +	return 0;
>> +}
>> +#endif /* CONFIG_OF */
>> +
>>  int __init omap4xxx_clk_init(void)
>>  {
>>  	u32 cpu_clkflg;
> 
> .. and I'm not too keen on adding driver specific stuff to this file.
> 
> How about just add a minimal drivers/clk/omap/clk-xyz.c that takes
> the configuration from DT and is based on the binding we already have in
> Documentation/devicetree/bindings/clock/clock-bindings.txt?
> 
> Then as we add new bindings there we can drop them from current
> cclock44xx_data.c, no? That is after omap4 is DT only..

The patch just provides an alternative for clkdev mapping in case of DT.
Are you suggesting we move all *clock data* related to auxclks (and eventually
all clocks) into DT?
We have discussed this multiple times in the past, and moving 250 clock nodes
with each needing multiple register offsets, masks, shifts etc into DT makes it
completely un-readable. For me, having a way for devices to reference a clock that they
use for a device using DT makes sense, but not moving all clock data into dts files.

regards,
Rajendra

> 
> Regards,
> 
> Tony
> 



From linux at prisktech.co.nz  Thu Apr  4 01:27:58 2013
From: linux at prisktech.co.nz (Tony Prisk)
Date: Thu, 04 Apr 2013 18:27:58 +1300
Subject: [PATCHv3 0/6] fb: vt8500: patches for 3.10
In-Reply-To: <1364926838-6721-1-git-send-email-linux@prisktech.co.nz>
References: <1364926838-6721-1-git-send-email-linux@prisktech.co.nz>
Message-ID: <515D0F5E.5010805@prisktech.co.nz>

On 03/04/13 07:20, Tony Prisk wrote:
> V3 Changes:
> Tidied up patch 1 as requested by Jean-Christophe - Makes the patch much
> simpler.
>
> V2 Changes:
> Split the SoC and board portions of the binding into their respective files.
> Removed the forced non-interlaced code from wm8505fb.c and vt8500lcdfb.c
>
> Julia Lawall (1):
>    drivers/video/wm8505fb.c: use devm_ functions
>
> Tony Prisk (5):
>    video: vt8500: Make wmt_ge_rops optional
>    video: vt8500: Remove unused platform_data/video-vt8500lcdfb.h
>    video: vt8500: Correct descriptions in video/Kconfig
>    video: vt8500: Adjust contrast in wm8505 framebuffer driver.
>    video: fb: vt8500: Convert framebuffer drivers to standardized
>      binding
>
>   .../devicetree/bindings/video/via,vt8500-fb.txt    |   48 ++-----
>   .../devicetree/bindings/video/wm,wm8505-fb.txt     |   32 +++--
>   arch/arm/boot/dts/vt8500-bv07.dts                  |   34 ++---
>   arch/arm/boot/dts/vt8500.dtsi                      |    4 +-
>   arch/arm/boot/dts/wm8505-ref.dts                   |   34 ++---
>   arch/arm/boot/dts/wm8505.dtsi                      |    4 +-
>   arch/arm/boot/dts/wm8650-mid.dts                   |   36 +++--
>   arch/arm/boot/dts/wm8650.dtsi                      |    4 +-
>   arch/arm/boot/dts/wm8850-w70v2.dts                 |   40 +++---
>   arch/arm/boot/dts/wm8850.dtsi                      |    4 +-
>   drivers/video/Kconfig                              |   37 +++--
>   drivers/video/vt8500lcdfb.c                        |   55 +++-----
>   drivers/video/wm8505fb.c                           |  144 ++++++--------------
>   drivers/video/wmt_ge_rops.h                        |   23 ++++
>   include/linux/platform_data/video-vt8500lcdfb.h    |   31 -----
>   15 files changed, 211 insertions(+), 319 deletions(-)
>   delete mode 100644 include/linux/platform_data/video-vt8500lcdfb.h
>
Tomi,

If no one has any further comments, are you still prepared to take this 
series?
If so, I will send a pull-request.

With regards to the earlier concern about your current patch series, I 
think its easiest if you do take this series then you could do a fixup 
patch if this one is merged first. From what I remember of your series, 
it is basically a rename of of_get_display_timings() to 
of_get_display_timing() and some new code which I don't use. Seems a 
rather trivial patch for a fixup later.

Let me know what you want to do.

Regards
Tony P


From kuninori.morimoto.gx at renesas.com  Thu Apr  4 01:28:38 2013
From: kuninori.morimoto.gx at renesas.com (Kuninori Morimoto)
Date: Thu, 04 Apr 2013 14:28:38 +0900
Subject: APE6EVM and Runtime PM
In-Reply-To: <20130404044101.GG28297@verge.net.au>
References: <20130404020019.GA7163@verge.net.au>
 <87wqsjdlhv.wl%kuninori.morimoto.gx@renesas.com>
 <20130404044101.GG28297@verge.net.au>
Message-ID: <uy5cy7tkp.wl%kuninori.morimoto.gx@renesas.com>


Dear Simon

> > > in the course of looking look at consolidating our defconfigs I
> > > noticed that SMSC ethernet and rcar_thermal seem seem to not work when
> > > runtime PM is enabled.
> > > 
> > > I'm wondering if you have any ideas of what might be the cause of this
> > > or if you could give me some guidance on investigating this problem.
> > > 
> > > I assume that it relates to a clock or clocks not being enabled.
> > 
> > About rcar_thermal, it needs my patch which was sent to PM ML.
> > I got email from Zhang that he accepted my patch (pm_runtime support for thermal).
> > But it seems he didn't push his branch yet...
> > I guess I explained this on my [PATCH 0/x] email.
> 
> Thanks, sorry for missing that.
> 
> I guess we are down to just SMSC then.

I didn't check real board,
but I guess current SMSC IRQ came from IRQC,
and this IRQC needs MSTP 407.
But IRQC driver seems doesn't support PM_RUNTIME at this point.

Does your issue solve by adding MSTP 407 with CLK_ENABLE_ON_INIT ?
I'm not sure this is good solution, but quick-hack

Best regards
--
Kuninori Morimoto
 


From girishks2000 at gmail.com  Thu Apr  4 01:45:46 2013
From: girishks2000 at gmail.com (Girish KS)
Date: Thu, 4 Apr 2013 11:15:46 +0530
Subject: [PATCH V3 2/5] spi: s3c64xx: added support for polling mode
In-Reply-To: <20130403114935.GA11305@opensource.wolfsonmicro.com>
References: <1363157014-9615-1-git-send-email-ks.giri@samsung.com>
 <1363157014-9615-3-git-send-email-ks.giri@samsung.com>
 <20130401131207.GI18636@opensource.wolfsonmicro.com>
 <CAKrE-KdWe6aCg0p99BFEeQP-P2nwvdhs2itH3XnHsJMCUjWPAA@mail.gmail.com>
 <20130403114935.GA11305@opensource.wolfsonmicro.com>
Message-ID: <CAKrE-Kc-QJ1ZkAZ1jYjRy+7V+6SuVk0oytfD8_vcp3ZWf6aSPQ@mail.gmail.com>

On Wed, Apr 3, 2013 at 5:19 PM, Mark Brown
<broonie at opensource.wolfsonmicro.com> wrote:
> On Wed, Apr 03, 2013 at 05:00:04PM +0530, Girish KS wrote:
>> On Mon, Apr 1, 2013 at 6:42 PM, Mark Brown
>
>> >> -     if (!sdd->pdev->dev.of_node) {
>> >> +     if (!sdd->pdev->dev.of_node && !is_polling(sdd)) {
>> >>               res = platform_get_resource(pdev, IORESOURCE_DMA,  0);
>> >>               if (!res) {
>> >>                       dev_err(&pdev->dev, "Unable to get SPI tx dma "
>
>> > It seems like it'd be sensible to also handle failure to get the DMA
>> > resource by going into polling mode.
>
>> There are 2 cases currently i have identified and handled,
>> 1. The SoC's dont have DMA support for spi controller. For such SoC's we
>>  would not add the dma resource in the spi dts node. In this case the probe
>>  would return error if failure for DMA resuorce is handled.
>
> That's not what the code currently does...
>
>> 2. The SoC has a DMA support for SPI controller, but due to some x
>> reason(H/W bug),
>>  the driver would force polling mode by enabling
>> S3C64XX_SPI_QUIRK_POLL in driver
>>  data. For such SoC's there would be a dma entry in the spi controller
>> dts node, and
>>  probe can handle failure for DMA resource successfully.
>
>> To handle above both situations successfully if
>> (!sdd->pdev->dev.of_node && !is_polling(sdd)) is used.
>
> Right, that's what the code currently does but what I'm suggesting is
> that this isn't the most helpful thing to do and that printing a big
> warning then soldiering on in polling mode might be more useful.

Ok I got it. will do it.

Thanks Mark


From tgih.jun at samsung.com  Thu Apr  4 01:47:02 2013
From: tgih.jun at samsung.com (Seungwon Jeon)
Date: Thu, 04 Apr 2013 14:47:02 +0900
Subject: [PATCH v2] mmc: dwmmc: let device core setup the default pin
 configuration
In-Reply-To: <CAD=FV=Xck5XW3LPmvkMfP=dfmnDH+kG4VYkRetW+SJ-bAz7SqQ@mail.gmail.com>
References: <1364882999-31670-1-git-send-email-thomas.abraham@linaro.org>
 <CAD=FV=Xck5XW3LPmvkMfP=dfmnDH+kG4VYkRetW+SJ-bAz7SqQ@mail.gmail.com>
Message-ID: <004201ce30f7$d4beea20$7e3cbe60$%jun@samsung.com>

On Wednesday, April 03, 2013, Doug Anderson wrote:
> Thomas,
> 
> On Mon, Apr 1, 2013 at 11:09 PM, Thomas Abraham
> <thomas.abraham at linaro.org> wrote:
> > With device core now able to setup the default pin configuration,
> > the pin configuration code based on the deprecated Samsung specific
> > gpio bindings is removed.
> >
> > Signed-off-by: Thomas Abraham <thomas.abraham at linaro.org>
> > Acked-by: Linus Walleij <linus.walleij at linaro.org>
> > Reviewed-by: Doug Anderson <dianders at chromium.org>
> > Tested-by: Doug Anderson <dianders at chromium.org>
> 
> You missed Seungwon's other feedback.  Please change the title from
> "mmc: dwmmc: let device core setup the default pin configuration" to
> "mmc: dw_mmc: let device core setup the default pin configuration".
> He requested that the tag have the underscore in it for consistency.
> 
> If you're resending, it also seems like it might be nice to rebase this atop:
> 
> 0f6e73d mmc: dw_mmc: Add MSHC compatible for Exynos4412
> 
> ...just to avoid the simple merge conflict when applying?
> 
> Otherwise everything here looks great...
> 
> -Doug
Thomas,
It's a conflict to merge. Please do rebase the patch.

Thanks,
Seungwon Jeon



From nsekhar at ti.com  Thu Apr  4 01:49:44 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Thu, 4 Apr 2013 11:19:44 +0530
Subject: [PATCH v3 0/3] Platform support for EHRPWM & ECAP devices in
 DAVINCI.
In-Reply-To: <518397C60809E147AF5323E0420B992E3EAA7C39@DBDE01.ent.ti.com>
References: <1364197789-16783-1-git-send-email-avinashphilip@ti.com>
 <515A983D.8040907@ti.com>
 <518397C60809E147AF5323E0420B992E3EAA7C39@DBDE01.ent.ti.com>
Message-ID: <515D1478.4030700@ti.com>

On 4/4/2013 10:09 AM, Philip, Avinash wrote:
> On Tue, Apr 02, 2013 at 14:05:09, Nori, Sekhar wrote:
>> On 3/25/2013 1:19 PM, Philip Avinash wrote:
>>> Add platform support for EHRPWM and ECAP by providing clock nodes and
>>> device tree nodes.
>>> This series depends on [1] and [2] and is available for testing at [3].
>>> Tested for back light support in da850 EVM with EHRPWM PWM device.
>>>
>>> [1] http://gitorious.org/linux-davinci/linux-davinci/trees/davinci-for-v3.9/dt-2
>>> [2] https://gitorious.org/linux-pwm/linux-pwm/trees/for-next
>>> [3] https://github.com/avinashphilip/am335x_linux/tree/davinci-for-v3.9_soc_pwm
>>>
>>> Note:
>>> DT support for EHRPWM backlight has not been added in da850-evm.dts as there is
>>> conflicting pin-mux requirement with SPI flash.
>>
>> Can you check if this is really true even in newer boards (have a look
>> at the latest schematics)? I remember this used to be a problem in very
>> early versions but was fixed later.
> 
> On looking schematics, panel has three power controls LCD_BACKLIGHT_PWR, LCD_PANEL_PWR,
> LCD_PWM0. On latest schematic, LCD_PWM0 is connected to ECAP instance 2. So backlight
> can control through ECAP2 (not conflicting with SPI1 cs0). Still for controlling
> backlight, require support for LCD_BACKLIGHT_PWR & LCD_PANEL_PWR. These signals

By controlling above you mean "switching on/off"? Otherwise this seems
to be contradicting the statement just before.

> to be controlled by GPIO 2[8] & GPIO 2[15]. In release platform callbacks used
> to control GPIO functionality. But with DT support, I have to check how platform
> callbacks can be used.

Platform callbacks are not possible with DT. You can look at what
freescale mxsfb.c does. Look for panel-enable-gpios DT binding.

Thanks,
Sekhar


From maxime.ripard at free-electrons.com  Thu Apr  4 01:52:33 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Thu, 04 Apr 2013 07:52:33 +0200
Subject: [PATCH v2 0/6] clk: sunxi: gates support
In-Reply-To: <20130403214545.3383.95826@quantum>
References: <1363962042-29536-1-git-send-email-emilio@elopez.com.ar>
 <1364419243-18446-1-git-send-email-emilio@elopez.com.ar>
 <20130403214545.3383.95826@quantum>
Message-ID: <515D1521.60501@free-electrons.com>

Hi Mike

Le 03/04/2013 23:45, Mike Turquette a ?crit :
> Quoting Emilio L?pez (2013-03-27 14:20:36)
>> Hi,
>>
>> This patchset adds support for the main sunxi gates; namely, those found 
>> on AXI, AHB, APB0 and APB1 clocks. The series depends on Maxime's UART 
>> rework and on the basic sunxi clock driver by me.
>>
>> Patches 1 and 2 implement the actual gate support, and patch 3 switches 
>> the UARTs to use the correct gates now that they are available.
>>
>> Patch 4 and 5 add clock support to our pinctrl driver, as we need to 
>> keep the pio clock running for gpio to work.
>>
>> Patch 6 drops the ignore flags; now that we have actual clock users that 
>> will keep the important clocks running.
>>
>> Patch 7 is an unrelated oneliner to remove an unnecesary kmalloc call.
>>
>> The main changes from v1 are renamed compatible strings and a clarification
>> on the documentation, see each individual patch for more details.
>>
> 
> Hi Emilio,
> 
> Which tree(s) did you want these patches to go through?

1, 6 and 7 are changes on the clock driver in itself that depends on the
patches you have in your tree, so I guess you should take them through
your tree.

2,3 and 5 are dt patches, so I'll take them, and patch 4 has already
been applied by LinusW.

Thanks,
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


From horms at verge.net.au  Thu Apr  4 01:56:15 2013
From: horms at verge.net.au (Simon Horman)
Date: Thu, 4 Apr 2013 14:56:15 +0900
Subject: [PATCH v2 02/13] ARM: convert arm/arm64 arch timer to use
 CLKSRC_OF init
In-Reply-To: <1364854883-5961-3-git-send-email-robherring2@gmail.com>
References: <1364854883-5961-1-git-send-email-robherring2@gmail.com>
 <1364854883-5961-3-git-send-email-robherring2@gmail.com>
Message-ID: <20130404055615.GI28297@verge.net.au>

On Mon, Apr 01, 2013 at 05:21:12PM -0500, Rob Herring wrote:
> From: Rob Herring <rob.herring at calxeda.com>
> 
> This converts arm and arm64 to use CLKSRC_OF DT based initialization for
> the arch timer. A new function arch_timer_arch_init is added to allow for
> arch specific setup.
> 
> This has a side effect of enabling sched_clock on omap5 and exynos5. There
> should not be any reason not to use the arch timers for sched_clock.

Would it be possible for you to either delay the removal of
shmobile_timer_init. In general I am in favour of the following
approach to wide changes such as this one:

1. Add new feature
2. Convert users to new feature
3. Remove old feature.

If it is not possible to delay the removal of shmobile_timer_init could you
update your base such that you also remove its usage from the following
files:

arch/arm/mach-shmobile/board-kzm9g-reference.c
arch/arm/mach-shmobile/setup-r8a73a4.c
arch/arm/mach-shmobile/setup-r8a7779.c
arch/arm/mach-shmobile/board-lager.c
arch/arm/mach-shmobile/board-ape6evm.c
arch/arm/mach-shmobile/setup-r8a7778.c
arch/arm/mach-shmobile/board-marzen-reference.c
arch/arm/mach-shmobile/setup-r8a7790.c
arch/arm/mach-shmobile/board-bockw.c

The above files are all present in the arm-soc/next/boards2 branch
of the arm-soc tree which has pulled the renesas-boards3-for-v3.10 tag
of git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git.
I am happy for you use the later as a base if you wish.

> Signed-off-by: Rob Herring <rob.herring at calxeda.com>
> Cc: Russell King <linux at arm.linux.org.uk>
> Cc: Kukjin Kim <kgene.kim at samsung.com>
> Cc: Tony Lindgren <tony at atomide.com>
> Cc: Simon Horman <horms at verge.net.au>
> Cc: Magnus Damm <magnus.damm at gmail.com>
> Cc: Catalin Marinas <catalin.marinas at arm.com>
> Cc: Will Deacon <will.deacon at arm.com>
> Cc: John Stultz <john.stultz at linaro.org>
> Cc: Thomas Gleixner <tglx at linutronix.de>
> Cc: linux-samsung-soc at vger.kernel.org
> Cc: linux-omap at vger.kernel.org
> Cc: linux-sh at vger.kernel.org
> ---
>  arch/arm/include/asm/arch_timer.h            |   13 +------------
>  arch/arm/kernel/arch_timer.c                 |   17 +++--------------
>  arch/arm/mach-exynos/mach-exynos5-dt.c       |    1 -
>  arch/arm/mach-exynos/mct.c                   |    6 ------
>  arch/arm/mach-highbank/highbank.c            |    5 +----
>  arch/arm/mach-omap2/timer.c                  |    5 +----
>  arch/arm/mach-shmobile/board-kzm9d.c         |    1 -

I have boot tested the board-kzm9d change on the kzm9d board, it seems fine.

>  arch/arm/mach-shmobile/include/mach/common.h |    1 -
>  arch/arm/mach-shmobile/setup-emev2.c         |    1 -

I am not able to test the setup-emev2 portion properly at this time,
booting the kzm9d board without the board-kzm9d file seems broken without
your patch. However, your change seems reasonable to me.

>  arch/arm/mach-shmobile/setup-r8a7740.c       |    1 -

I am not able to test the setup-r8a7740 portion properly at this time,
booting the armadillo800eva board without the board-armadillo800eva file
seems broken without your patch. However, your change seems reasonable to
me.

>  arch/arm/mach-shmobile/setup-sh7372.c        |    1 -

I am not able to test the setup-sh7372 portion properly at this time,
booting the mackerel board without the board-mackerel file seems broken without
your patch. However, your change seems reasonable to me.

>  arch/arm/mach-shmobile/setup-sh73a0.c        |    1 -

I have boot tested the setup-sh73a0 change on the kzm9g board, it seems fine.


The tests above were made by merging

git://sources.calxeda.com/kernel/linux.git arm-timers
head commit: df3f518db302caf9fc0511917c5e9021037f6fcd
	     ("devtree: add binding documentation for sp804")

and the renesas-next-20130403 tag of the renesas tree (URL above).

>  arch/arm/mach-shmobile/timer.c               |    6 ------
>  arch/arm/mach-vexpress/v2m.c                 |    7 ++-----
>  arch/arm/mach-virt/virt.c                    |    9 ---------
>  arch/arm64/include/asm/arch_timer.h          |    5 +++++
>  arch/arm64/kernel/time.c                     |    6 ++++--
>  drivers/clocksource/Kconfig                  |    1 +
>  drivers/clocksource/arm_arch_timer.c         |   23 +++++++++--------------
>  include/clocksource/arm_arch_timer.h         |    6 ------
>  20 files changed, 27 insertions(+), 89 deletions(-)
> 
> diff --git a/arch/arm/include/asm/arch_timer.h b/arch/arm/include/asm/arch_timer.h
> index 7ade91d..7c1bfc0 100644
> --- a/arch/arm/include/asm/arch_timer.h
> +++ b/arch/arm/include/asm/arch_timer.h
> @@ -10,8 +10,7 @@
>  #include <clocksource/arm_arch_timer.h>
>  
>  #ifdef CONFIG_ARM_ARCH_TIMER
> -int arch_timer_of_register(void);
> -int arch_timer_sched_clock_init(void);
> +int arch_timer_arch_init(void);
>  
>  /*
>   * These register accessors are marked inline so the compiler can
> @@ -110,16 +109,6 @@ static inline void __cpuinit arch_counter_set_user_access(void)
>  
>  	asm volatile("mcr p15, 0, %0, c14, c1, 0" : : "r" (cntkctl));
>  }
> -#else
> -static inline int arch_timer_of_register(void)
> -{
> -	return -ENXIO;
> -}
> -
> -static inline int arch_timer_sched_clock_init(void)
> -{
> -	return -ENXIO;
> -}
>  #endif
>  
>  #endif
> diff --git a/arch/arm/kernel/arch_timer.c b/arch/arm/kernel/arch_timer.c
> index a7536d4..dc74048 100644
> --- a/arch/arm/kernel/arch_timer.c
> +++ b/arch/arm/kernel/arch_timer.c
> @@ -39,26 +39,15 @@ static void __init arch_timer_delay_timer_register(void)
>  	register_current_timer_delay(&arch_delay_timer);
>  }
>  
> -int __init arch_timer_of_register(void)
> -{
> -	int ret;
> -
> -	ret = arch_timer_init();
> -	if (ret)
> -		return ret;
> -
> -	arch_timer_delay_timer_register();
> -
> -	return 0;
> -}
> -
> -int __init arch_timer_sched_clock_init(void)
> +int __init arch_timer_arch_init(void)
>  {
>          u32 arch_timer_rate = arch_timer_get_rate();
>  
>  	if (arch_timer_rate == 0)
>  		return -ENXIO;
>  
> +	arch_timer_delay_timer_register();
> +
>  	/* Cache the sched_clock multiplier to save a divide in the hot path. */
>  	sched_clock_mult = NSEC_PER_SEC / arch_timer_rate;
>  	sched_clock_func = arch_timer_sched_clock;
> diff --git a/arch/arm/mach-exynos/mach-exynos5-dt.c b/arch/arm/mach-exynos/mach-exynos5-dt.c
> index acaeb14..4d97b43 100644
> --- a/arch/arm/mach-exynos/mach-exynos5-dt.c
> +++ b/arch/arm/mach-exynos/mach-exynos5-dt.c
> @@ -216,7 +216,6 @@ DT_MACHINE_START(EXYNOS5_DT, "SAMSUNG EXYNOS5 (Flattened Device Tree)")
>  	.map_io		= exynos5_dt_map_io,
>  	.init_machine	= exynos5_dt_machine_init,
>  	.init_late	= exynos_init_late,
> -	.init_time	= exynos4_timer_init,
>  	.dt_compat	= exynos5_dt_compat,
>  	.restart        = exynos5_restart,
>  	.reserve	= exynos5_reserve,
> diff --git a/arch/arm/mach-exynos/mct.c b/arch/arm/mach-exynos/mct.c
> index c9d6650..04aff6a 100644
> --- a/arch/arm/mach-exynos/mct.c
> +++ b/arch/arm/mach-exynos/mct.c
> @@ -21,7 +21,6 @@
>  #include <linux/percpu.h>
>  #include <linux/of.h>
>  
> -#include <asm/arch_timer.h>
>  #include <asm/localtimer.h>
>  
>  #include <plat/cpu.h>
> @@ -469,11 +468,6 @@ static void __init exynos4_timer_resources(void)
>  
>  void __init exynos4_timer_init(void)
>  {
> -	if (soc_is_exynos5440()) {
> -		arch_timer_of_register();
> -		return;
> -	}
> -
>  	if ((soc_is_exynos4210()) || (soc_is_exynos5250()))
>  		mct_int_type = MCT_INT_SPI;
>  	else
> diff --git a/arch/arm/mach-highbank/highbank.c b/arch/arm/mach-highbank/highbank.c
> index 76c1170..758150e 100644
> --- a/arch/arm/mach-highbank/highbank.c
> +++ b/arch/arm/mach-highbank/highbank.c
> @@ -15,6 +15,7 @@
>   */
>  #include <linux/clk.h>
>  #include <linux/clkdev.h>
> +#include <linux/clocksource.h>
>  #include <linux/dma-mapping.h>
>  #include <linux/io.h>
>  #include <linux/irq.h>
> @@ -28,7 +29,6 @@
>  #include <linux/amba/bus.h>
>  #include <linux/clk-provider.h>
>  
> -#include <asm/arch_timer.h>
>  #include <asm/cacheflush.h>
>  #include <asm/cputype.h>
>  #include <asm/smp_plat.h>
> @@ -118,9 +118,6 @@ static void __init highbank_timer_init(void)
>  	sp804_clocksource_and_sched_clock_init(timer_base + 0x20, "timer1");
>  	sp804_clockevents_init(timer_base, irq, "timer0");
>  
> -	arch_timer_of_register();
> -	arch_timer_sched_clock_init();
> -
>  	clocksource_of_init();
>  }
>  
> diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
> index 4fd8025..7dd6453 100644
> --- a/arch/arm/mach-omap2/timer.c
> +++ b/arch/arm/mach-omap2/timer.c
> @@ -46,7 +46,6 @@
>  #include <asm/smp_twd.h>
>  #include <asm/sched_clock.h>
>  
> -#include <asm/arch_timer.h>
>  #include "omap_hwmod.h"
>  #include "omap_device.h"
>  #include <plat/counter-32k.h>
> @@ -624,9 +623,7 @@ void __init omap5_realtime_timer_init(void)
>  	omap5_sync32k_timer_init();
>  	realtime_counter_init();
>  
> -	err = arch_timer_of_register();
> -	if (err)
> -		pr_err("%s: arch_timer_register failed %d\n", __func__, err);
> +        clocksource_of_init();
>  }
>  #endif /* CONFIG_SOC_OMAP5 */
>  
> diff --git a/arch/arm/mach-shmobile/board-kzm9d.c b/arch/arm/mach-shmobile/board-kzm9d.c
> index c254782..c016ccd 100644
> --- a/arch/arm/mach-shmobile/board-kzm9d.c
> +++ b/arch/arm/mach-shmobile/board-kzm9d.c
> @@ -90,6 +90,5 @@ DT_MACHINE_START(KZM9D_DT, "kzm9d")
>  	.init_irq	= emev2_init_irq,
>  	.init_machine	= kzm9d_add_standard_devices,
>  	.init_late	= shmobile_init_late,
> -	.init_time	= shmobile_timer_init,
>  	.dt_compat	= kzm9d_boards_compat_dt,
>  MACHINE_END
> diff --git a/arch/arm/mach-shmobile/include/mach/common.h b/arch/arm/mach-shmobile/include/mach/common.h
> index e48606d..5efc0f0 100644
> --- a/arch/arm/mach-shmobile/include/mach/common.h
> +++ b/arch/arm/mach-shmobile/include/mach/common.h
> @@ -2,7 +2,6 @@
>  #define __ARCH_MACH_COMMON_H
>  
>  extern void shmobile_earlytimer_init(void);
> -extern void shmobile_timer_init(void);
>  extern void shmobile_setup_delay(unsigned int max_cpu_core_mhz,
>  			 unsigned int mult, unsigned int div);
>  struct twd_local_timer;
> diff --git a/arch/arm/mach-shmobile/setup-emev2.c b/arch/arm/mach-shmobile/setup-emev2.c
> index 47662a5..4e38a66 100644
> --- a/arch/arm/mach-shmobile/setup-emev2.c
> +++ b/arch/arm/mach-shmobile/setup-emev2.c
> @@ -456,7 +456,6 @@ DT_MACHINE_START(EMEV2_DT, "Generic Emma Mobile EV2 (Flattened Device Tree)")
>  	.nr_irqs	= NR_IRQS_LEGACY,
>  	.init_irq	= irqchip_init,
>  	.init_machine	= emev2_add_standard_devices_dt,
> -	.init_time	= shmobile_timer_init,
>  	.dt_compat	= emev2_boards_compat_dt,
>  MACHINE_END
>  
> diff --git a/arch/arm/mach-shmobile/setup-r8a7740.c b/arch/arm/mach-shmobile/setup-r8a7740.c
> index 8b85d4d..104b474 100644
> --- a/arch/arm/mach-shmobile/setup-r8a7740.c
> +++ b/arch/arm/mach-shmobile/setup-r8a7740.c
> @@ -906,7 +906,6 @@ DT_MACHINE_START(R8A7740_DT, "Generic R8A7740 (Flattened Device Tree)")
>  	.init_irq	= r8a7740_init_irq,
>  	.handle_irq	= shmobile_handle_irq_intc,
>  	.init_machine	= r8a7740_add_standard_devices_dt,
> -	.init_time	= shmobile_timer_init,
>  	.dt_compat	= r8a7740_boards_compat_dt,
>  MACHINE_END
>  
> diff --git a/arch/arm/mach-shmobile/setup-sh7372.c b/arch/arm/mach-shmobile/setup-sh7372.c
> index 59c7146..5502d62 100644
> --- a/arch/arm/mach-shmobile/setup-sh7372.c
> +++ b/arch/arm/mach-shmobile/setup-sh7372.c
> @@ -1175,7 +1175,6 @@ DT_MACHINE_START(SH7372_DT, "Generic SH7372 (Flattened Device Tree)")
>  	.init_irq	= sh7372_init_irq,
>  	.handle_irq	= shmobile_handle_irq_intc,
>  	.init_machine	= sh7372_add_standard_devices_dt,
> -	.init_time	= shmobile_timer_init,
>  	.dt_compat	= sh7372_boards_compat_dt,
>  MACHINE_END
>  
> diff --git a/arch/arm/mach-shmobile/setup-sh73a0.c b/arch/arm/mach-shmobile/setup-sh73a0.c
> index bdab575..ea66316 100644
> --- a/arch/arm/mach-shmobile/setup-sh73a0.c
> +++ b/arch/arm/mach-shmobile/setup-sh73a0.c
> @@ -923,7 +923,6 @@ DT_MACHINE_START(SH73A0_DT, "Generic SH73A0 (Flattened Device Tree)")
>  	.nr_irqs	= NR_IRQS_LEGACY,
>  	.init_irq	= sh73a0_init_irq_dt,
>  	.init_machine	= sh73a0_add_standard_devices_dt,
> -	.init_time	= shmobile_timer_init,
>  	.dt_compat	= sh73a0_boards_compat_dt,
>  MACHINE_END
>  #endif /* CONFIG_USE_OF */
> diff --git a/arch/arm/mach-shmobile/timer.c b/arch/arm/mach-shmobile/timer.c
> index 3d16d4d..add2f15 100644
> --- a/arch/arm/mach-shmobile/timer.c
> +++ b/arch/arm/mach-shmobile/timer.c
> @@ -60,9 +60,3 @@ void __init shmobile_earlytimer_init(void)
>  {
>  	late_time_init = shmobile_late_time_init;
>  }
> -
> -void __init shmobile_timer_init(void)
> -{
> -	arch_timer_of_register();
> -	arch_timer_sched_clock_init();
> -}
> diff --git a/arch/arm/mach-vexpress/v2m.c b/arch/arm/mach-vexpress/v2m.c
> index d0ad789..6215717 100644
> --- a/arch/arm/mach-vexpress/v2m.c
> +++ b/arch/arm/mach-vexpress/v2m.c
> @@ -1,6 +1,7 @@
>  /*
>   * Versatile Express V2M Motherboard Support
>   */
> +#include <linux/clocksource.h>
>  #include <linux/device.h>
>  #include <linux/amba/bus.h>
>  #include <linux/amba/mmci.h>
> @@ -23,7 +24,6 @@
>  #include <linux/regulator/machine.h>
>  #include <linux/vexpress.h>
>  
> -#include <asm/arch_timer.h>
>  #include <asm/mach-types.h>
>  #include <asm/sizes.h>
>  #include <asm/mach/arch.h>
> @@ -446,10 +446,7 @@ static void __init v2m_dt_timer_init(void)
>  				irq_of_parse_and_map(node, 0));
>  	}
>  
> -	arch_timer_of_register();
> -
> -	if (arch_timer_sched_clock_init() != 0)
> -		versatile_sched_clock_init(vexpress_get_24mhz_clock_base(),
> +	versatile_sched_clock_init(vexpress_get_24mhz_clock_base(),
>  				24000000);
>  }
>  
> diff --git a/arch/arm/mach-virt/virt.c b/arch/arm/mach-virt/virt.c
> index 31666f6..adc0945 100644
> --- a/arch/arm/mach-virt/virt.c
> +++ b/arch/arm/mach-virt/virt.c
> @@ -23,21 +23,13 @@
>  #include <linux/of_platform.h>
>  #include <linux/smp.h>
>  
> -#include <asm/arch_timer.h>
>  #include <asm/mach/arch.h>
> -#include <asm/mach/time.h>
>  
>  static void __init virt_init(void)
>  {
>  	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
>  }
>  
> -static void __init virt_timer_init(void)
> -{
> -	WARN_ON(arch_timer_of_register() != 0);
> -	WARN_ON(arch_timer_sched_clock_init() != 0);
> -}
> -
>  static const char *virt_dt_match[] = {
>  	"linux,dummy-virt",
>  	NULL
> @@ -47,7 +39,6 @@ extern struct smp_operations virt_smp_ops;
>  
>  DT_MACHINE_START(VIRT, "Dummy Virtual Machine")
>  	.init_irq	= irqchip_init,
> -	.init_time	= virt_timer_init,
>  	.init_machine	= virt_init,
>  	.smp		= smp_ops(virt_smp_ops),
>  	.dt_compat	= virt_dt_match,
> diff --git a/arch/arm64/include/asm/arch_timer.h b/arch/arm64/include/asm/arch_timer.h
> index 91e2a6a..bf6ab242 100644
> --- a/arch/arm64/include/asm/arch_timer.h
> +++ b/arch/arm64/include/asm/arch_timer.h
> @@ -130,4 +130,9 @@ static inline u64 arch_counter_get_cntvct(void)
>  	return cval;
>  }
>  
> +static inline int arch_timer_arch_init(void)
> +{
> +	return 0;
> +}
> +
>  #endif
> diff --git a/arch/arm64/kernel/time.c b/arch/arm64/kernel/time.c
> index b0ef18d..a551f88 100644
> --- a/arch/arm64/kernel/time.c
> +++ b/arch/arm64/kernel/time.c
> @@ -32,6 +32,7 @@
>  #include <linux/timer.h>
>  #include <linux/irq.h>
>  #include <linux/delay.h>
> +#include <linux/clocksource.h>
>  
>  #include <clocksource/arm_arch_timer.h>
>  
> @@ -77,10 +78,11 @@ void __init time_init(void)
>  {
>  	u32 arch_timer_rate;
>  
> -	if (arch_timer_init())
> -		panic("Unable to initialise architected timer.\n");
> +	clocksource_of_init();
>  
>  	arch_timer_rate = arch_timer_get_rate();
> +	if (!arch_timer_rate)
> +		panic("Unable to initialise architected timer.\n");
>  
>  	/* Cache the sched_clock multiplier to save a divide in the hot path. */
>  	sched_clock_mult = NSEC_PER_SEC / arch_timer_rate;
> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
> index e507ab7..d98e7e1 100644
> --- a/drivers/clocksource/Kconfig
> +++ b/drivers/clocksource/Kconfig
> @@ -62,6 +62,7 @@ config CLKSRC_DBX500_PRCMU_SCHED_CLOCK
>  
>  config ARM_ARCH_TIMER
>  	bool
> +	select CLKSRC_OF if OF
>  
>  config CLKSRC_METAG_GENERIC
>  	def_bool y if METAG
> diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
> index d7ad425..122ff05 100644
> --- a/drivers/clocksource/arm_arch_timer.c
> +++ b/drivers/clocksource/arm_arch_timer.c
> @@ -337,22 +337,14 @@ out:
>  	return err;
>  }
>  
> -static const struct of_device_id arch_timer_of_match[] __initconst = {
> -	{ .compatible	= "arm,armv7-timer",	},
> -	{ .compatible	= "arm,armv8-timer",	},
> -	{},
> -};
> -
> -int __init arch_timer_init(void)
> +static void __init arch_timer_init(struct device_node *np)
>  {
> -	struct device_node *np;
>  	u32 freq;
>  	int i;
>  
> -	np = of_find_matching_node(NULL, arch_timer_of_match);
> -	if (!np) {
> -		pr_err("arch_timer: can't find DT node\n");
> -		return -ENODEV;
> +	if (arch_timer_get_rate()) {
> +		pr_warn("arch_timer: multiple nodes in dt, skipping\n");
> +		return;
>  	}
>  
>  	/* Try to determine the frequency from the device tree or CNTFRQ */
> @@ -378,7 +370,7 @@ int __init arch_timer_init(void)
>  		if (!arch_timer_ppi[PHYS_SECURE_PPI] ||
>  		    !arch_timer_ppi[PHYS_NONSECURE_PPI]) {
>  			pr_warn("arch_timer: No interrupt available, giving up\n");
> -			return -EINVAL;
> +			return;
>  		}
>  	}
>  
> @@ -387,5 +379,8 @@ int __init arch_timer_init(void)
>  	else
>  		arch_timer_read_counter = arch_counter_get_cntpct;
>  
> -	return arch_timer_register();
> +	arch_timer_register();
> +	arch_timer_arch_init();
>  }
> +CLOCKSOURCE_OF_DECLARE(armv7_arch_timer, "arm,armv7-timer", arch_timer_init);
> +CLOCKSOURCE_OF_DECLARE(armv8_arch_timer, "arm,armv8-timer", arch_timer_init);
> diff --git a/include/clocksource/arm_arch_timer.h b/include/clocksource/arm_arch_timer.h
> index 2603267..e6c9c4c 100644
> --- a/include/clocksource/arm_arch_timer.h
> +++ b/include/clocksource/arm_arch_timer.h
> @@ -31,18 +31,12 @@
>  
>  #ifdef CONFIG_ARM_ARCH_TIMER
>  
> -extern int arch_timer_init(void);
>  extern u32 arch_timer_get_rate(void);
>  extern u64 (*arch_timer_read_counter)(void);
>  extern struct timecounter *arch_timer_get_timecounter(void);
>  
>  #else
>  
> -static inline int arch_timer_init(void)
> -{
> -	return -ENXIO;
> -}
> -
>  static inline u32 arch_timer_get_rate(void)
>  {
>  	return 0;
> -- 
> 1.7.10.4
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


From horms at verge.net.au  Thu Apr  4 02:14:33 2013
From: horms at verge.net.au (Simon Horman)
Date: Thu, 4 Apr 2013 15:14:33 +0900
Subject: APE6EVM and Runtime PM
In-Reply-To: <uy5cy7tkp.wl%kuninori.morimoto.gx@renesas.com>
References: <20130404020019.GA7163@verge.net.au>
 <87wqsjdlhv.wl%kuninori.morimoto.gx@renesas.com>
 <20130404044101.GG28297@verge.net.au>
 <uy5cy7tkp.wl%kuninori.morimoto.gx@renesas.com>
Message-ID: <20130404061429.GJ28297@verge.net.au>

On Thu, Apr 04, 2013 at 02:28:38PM +0900, Kuninori Morimoto wrote:
> 
> Dear Simon
> 
> > > > in the course of looking look at consolidating our defconfigs I
> > > > noticed that SMSC ethernet and rcar_thermal seem seem to not work when
> > > > runtime PM is enabled.
> > > > 
> > > > I'm wondering if you have any ideas of what might be the cause of this
> > > > or if you could give me some guidance on investigating this problem.
> > > > 
> > > > I assume that it relates to a clock or clocks not being enabled.
> > > 
> > > About rcar_thermal, it needs my patch which was sent to PM ML.
> > > I got email from Zhang that he accepted my patch (pm_runtime support for thermal).
> > > But it seems he didn't push his branch yet...
> > > I guess I explained this on my [PATCH 0/x] email.
> > 
> > Thanks, sorry for missing that.
> > 
> > I guess we are down to just SMSC then.
> 
> I didn't check real board,
> but I guess current SMSC IRQ came from IRQC,
> and this IRQC needs MSTP 407.
> But IRQC driver seems doesn't support PM_RUNTIME at this point.
> 
> Does your issue solve by adding MSTP 407 with CLK_ENABLE_ON_INIT ?
> I'm not sure this is good solution, but quick-hack

Thanks!

I will post a patch to add pm_runtime support to the IRQC Driver.
It seems to allow SMSC + RUNTIME_PM to function on the APE6EVM.


From horms+renesas at verge.net.au  Thu Apr  4 02:21:06 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Apr 2013 15:21:06 +0900
Subject: [PATCH] irqchip: irqc: Add runtime PM support
Message-ID: <1365056466-23710-1-git-send-email-horms+renesas@verge.net.au>

This was tested using the SMSC LAN on the APE6EVM board.

Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 drivers/irqchip/irq-renesas-irqc.c |    8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/irqchip/irq-renesas-irqc.c b/drivers/irqchip/irq-renesas-irqc.c
index 927bff3..649cd69 100644
--- a/drivers/irqchip/irq-renesas-irqc.c
+++ b/drivers/irqchip/irq-renesas-irqc.c
@@ -19,6 +19,7 @@
 
 #include <linux/init.h>
 #include <linux/platform_device.h>
+#include <linux/pm_runtime.h>
 #include <linux/spinlock.h>
 #include <linux/interrupt.h>
 #include <linux/ioport.h>
@@ -181,6 +182,9 @@ static int irqc_probe(struct platform_device *pdev)
 		goto err1;
 	}
 
+	pm_runtime_enable(&pdev->dev);
+	pm_runtime_get_sync(&pdev->dev);
+
 	/* allow any number of IRQs between 1 and IRQC_IRQ_MAX */
 	for (k = 0; k < IRQC_IRQ_MAX; k++) {
 		irq = platform_get_resource(pdev, IORESOURCE_IRQ, k);
@@ -255,6 +259,8 @@ err3:
 err2:
 	iounmap(p->iomem);
 err1:
+	pm_runtime_put_sync(&pdev->dev);
+	pm_runtime_disable(&pdev->dev);
 	kfree(p);
 err0:
 	return ret;
@@ -270,6 +276,8 @@ static int irqc_remove(struct platform_device *pdev)
 
 	irq_domain_remove(p->irq_domain);
 	iounmap(p->iomem);
+	pm_runtime_put_sync(&pdev->dev);
+	pm_runtime_disable(&pdev->dev);
 	kfree(p);
 	return 0;
 }
-- 
1.7.10.4



From horms at verge.net.au  Thu Apr  4 02:21:42 2013
From: horms at verge.net.au (Simon Horman)
Date: Thu, 4 Apr 2013 15:21:42 +0900
Subject: APE6EVM and Runtime PM
In-Reply-To: <20130404061429.GJ28297@verge.net.au>
References: <20130404020019.GA7163@verge.net.au>
 <87wqsjdlhv.wl%kuninori.morimoto.gx@renesas.com>
 <20130404044101.GG28297@verge.net.au>
 <uy5cy7tkp.wl%kuninori.morimoto.gx@renesas.com>
 <20130404061429.GJ28297@verge.net.au>
Message-ID: <20130404062140.GK28297@verge.net.au>

On Thu, Apr 04, 2013 at 03:14:33PM +0900, Simon Horman wrote:
> On Thu, Apr 04, 2013 at 02:28:38PM +0900, Kuninori Morimoto wrote:
> > 
> > Dear Simon
> > 
> > > > > in the course of looking look at consolidating our defconfigs I
> > > > > noticed that SMSC ethernet and rcar_thermal seem seem to not work when
> > > > > runtime PM is enabled.
> > > > > 
> > > > > I'm wondering if you have any ideas of what might be the cause of this
> > > > > or if you could give me some guidance on investigating this problem.
> > > > > 
> > > > > I assume that it relates to a clock or clocks not being enabled.
> > > > 
> > > > About rcar_thermal, it needs my patch which was sent to PM ML.
> > > > I got email from Zhang that he accepted my patch (pm_runtime support for thermal).
> > > > But it seems he didn't push his branch yet...
> > > > I guess I explained this on my [PATCH 0/x] email.
> > > 
> > > Thanks, sorry for missing that.
> > > 
> > > I guess we are down to just SMSC then.
> > 
> > I didn't check real board,
> > but I guess current SMSC IRQ came from IRQC,
> > and this IRQC needs MSTP 407.
> > But IRQC driver seems doesn't support PM_RUNTIME at this point.
> > 
> > Does your issue solve by adding MSTP 407 with CLK_ENABLE_ON_INIT ?
> > I'm not sure this is good solution, but quick-hack
> 
> Thanks!
> 
> I will post a patch to add pm_runtime support to the IRQC Driver.
> It seems to allow SMSC + RUNTIME_PM to function on the APE6EVM.

For reference, I have posted "irqchip: irqc: Add runtime PM support"


From horms at verge.net.au  Thu Apr  4 02:24:42 2013
From: horms at verge.net.au (Simon Horman)
Date: Thu, 4 Apr 2013 15:24:42 +0900
Subject: [PATCH 00/04] ARM: shmobile: pinmux platform device cleanups
In-Reply-To: <20130403063246.2500.65318.sendpatchset@w520>
References: <20130403063246.2500.65318.sendpatchset@w520>
Message-ID: <20130404062441.GN28297@verge.net.au>

On Wed, Apr 03, 2013 at 03:32:46PM +0900, Magnus Damm wrote:
> ARM: shmobile: pinmux platform device cleanups
> 
> [PATCH 01/04] ARM: shmobile: r8a7740 pinmux platform device cleanup
> [PATCH 02/04] ARM: shmobile: r8a7779 pinmux platform device cleanup
> [PATCH 03/04] ARM: shmobile: sh7372 pinmux platform device cleanup
> [PATCH 04/04] ARM: shmobile: sh73a0 pinmux platform device cleanup
> 
> This series simply cleans up the pinmux platform device handling
> to save a couple of lines. Compile time tested on each SoC.
> 
> Signed-off-by: Magnus Damm <damm at opensource.se>

Laurent, could you review this series?


From tom.leiming at gmail.com  Thu Apr  4 02:31:29 2013
From: tom.leiming at gmail.com (Ming Lei)
Date: Thu, 4 Apr 2013 14:31:29 +0800
Subject: [PATCH v1] ARM: keep __my_cpu_offset consistent with generic one
In-Reply-To: <20130403161955.GE17995@n2100.arm.linux.org.uk>
References: <1362663356-21151-1-git-send-email-tom.leiming@gmail.com>
 <CACVXFVOhr222CVrzkVP_oLgVkdReD9BXXSBg7fmp6Wvx9_peCw@mail.gmail.com>
 <20130312105638.GQ4977@n2100.arm.linux.org.uk>
 <20130403161955.GE17995@n2100.arm.linux.org.uk>
Message-ID: <CACVXFVMMpqYFzP7KpCgvBRLPpWffZuM6q_h+8AS3vYFpk-4B_w@mail.gmail.com>

Hi,

On Thu, Apr 4, 2013 at 12:19 AM, Russell King - ARM Linux
<linux at arm.linux.org.uk> wrote:
>
> Still not convinced this is a proper fix.  Look, the problem is this:
>
> - Initially, set the CPU percpu offset to zero.  This means the boot
>   CPU reads and writes to the percpu data section in the kernel image.
>
> - The percpu areas are initialized, and the percpu data copied to each
>   percpu data - this will have any writes from the boot CPU included as
>   changes to the percpu data.
>
> - The boot CPU continues to read/write to the percpu data section.

No, the boot CPU switches to access percpu area after the area is
created(after setup_per_cpu_areas() and smp_prepare_boot_cpu()).

>
> - If the boot CPU suspends/resumes, cpu_init() gets called, which will
>   call set_my_cpu_offset(per_cpu_offset(cpu)); for the boot CPU.
>
> - The boot CPU now uses the allocated percpu data section and any
>   updates it did in the percpu data section in the kernel image are
>   lost to it.
>
> Your patch may be right on its own to solve the initial problem, but
> it leaves a _big_ hole.

Without the patch, looks the hols was still here, at least before commit
14318efb(ARM: 7587/1: implement optimized percpu variable access),
the per_cpu_offset() always return 0 before percpu area is created on ARM.
Same on other ARCHs too.

>
> Now, the big question here: is it right that the boot CPU should ever
> write to the static percpu data section in the kernel image?  What if

IMO, it isn't right, but as Tejun said, "it mostly due to historical
reasons rather than by design, as long as the data is in consistent
state by and during percpu setup, nothing will break."

As far as the lockdep case, it is a bit special since lock can
be used very early, and surely more early than creating percpu
area.

> there's a pointer in there, initially NULL, which then gets checked
> by each CPU and initialized if NULL - we'll end up sharing the same
> allocation amongst all CPUs, which probably isn't what was intended.
> If there's a list_head which gets added to, that too will be very bad.

Once lockstat is disabled, arm can boot well, that means no others might
access percpu data section early, so could we just treat it as a special case?

>
> Although you have uncovered a problem, I still think by setting the
> offset to zero initially, you're just papering over a much bigger
> can of worms.
>
> So, should percpu data be used this early in boot before the percpu
> stuff is properly initialized?  That feels _extremely_ unsafe.
>
> This, I think, needs to be addressed properly.  And part of that is
> knowing where things went wrong.  Will Deacon asked you for a backtrace
> showing where this problem occured.  Your response seems to be to
> resend the patch with a "v1" tag a no new information.

I have explained to Will Deacon, and looks no oops trace is generated
on the memory access exception during booting. And the hang
happened in mutex_unlock(&cgroup_mutex)(cgroup_init_subsys<-
cgroup_init_early).

> Sorry, not applying this until the above issue has been discussed
> and the location of these percpu accesses has been properly analysed.

No problem.

Thanks,
-- 
Ming Lei


From horms at verge.net.au  Thu Apr  4 02:34:10 2013
From: horms at verge.net.au (Simon Horman)
Date: Thu, 4 Apr 2013 15:34:10 +0900
Subject: [PATCH 1/2] ARM: shmobile: R8A7779: add Ether support
In-Reply-To: <515C2D0E.8010607@cogentembedded.com>
References: <201304020204.54546.sergei.shtylyov@cogentembedded.com>
 <87wqsl6ale.wl%kuninori.morimoto.gx@renesas.com>
 <515AC546.90905@cogentembedded.com>
 <87txnocw6n.wl%kuninori.morimoto.gx@renesas.com>
 <515C2D0E.8010607@cogentembedded.com>
Message-ID: <20130404063410.GP28297@verge.net.au>

On Wed, Apr 03, 2013 at 05:22:22PM +0400, Sergei Shtylyov wrote:
> Hello.
> 
> On 03-04-2013 4:08, Kuninori Morimoto wrote:
> 
> >>>Then, this (void *pdata) should be
> >>>(struct sh_eth_plat_data *pdata) IMO
> 
> >>     ether_device.dev.platform_data is 'void *'. I didn't want to bring in
> >>extra header for the little use.
> 
> >Not enough reason for me.
> 
> >"void *" means there is no pointer check,
> >and extra header is just 1 line. No ?
> 
>    There's no pointer check either if we just initialize the 'platform_data'
> member as part of the platfrom device initializer, so we can
> actually stuff pointer to any nonsense there. Why make this case
> different?
> 
> >If you want to use this style,
> >then, additional extra header is fate, IMO
> 
>    We can agree to disagree here. :-)

I would like void * changed to struct sh_eth_plat_data * so
that callers of r8a7779_add_ether_device() will get a warning
if they pass an argument of the wrong type.

Other than that I believe that I am happy with this patch.

Ditto for the similar patch for the R8A7778.

Thanks



From avinashphilip at ti.com  Thu Apr  4 02:38:24 2013
From: avinashphilip at ti.com (Philip, Avinash)
Date: Thu, 4 Apr 2013 06:38:24 +0000
Subject: [PATCH v3 0/3] Platform support for EHRPWM & ECAP devices in
 DAVINCI.
In-Reply-To: <515D1478.4030700@ti.com>
References: <1364197789-16783-1-git-send-email-avinashphilip@ti.com>
 <515A983D.8040907@ti.com>
 <518397C60809E147AF5323E0420B992E3EAA7C39@DBDE01.ent.ti.com>
 <515D1478.4030700@ti.com>
Message-ID: <518397C60809E147AF5323E0420B992E3EAA7CD5@DBDE01.ent.ti.com>

On Thu, Apr 04, 2013 at 11:19:44, Nori, Sekhar wrote:
> On 4/4/2013 10:09 AM, Philip, Avinash wrote:
> > On Tue, Apr 02, 2013 at 14:05:09, Nori, Sekhar wrote:
> >> On 3/25/2013 1:19 PM, Philip Avinash wrote:
> >>> Add platform support for EHRPWM and ECAP by providing clock nodes and
> >>> device tree nodes.
> >>> This series depends on [1] and [2] and is available for testing at [3].
> >>> Tested for back light support in da850 EVM with EHRPWM PWM device.
> >>>
> >>> [1] http://gitorious.org/linux-davinci/linux-davinci/trees/davinci-for-v3.9/dt-2
> >>> [2] https://gitorious.org/linux-pwm/linux-pwm/trees/for-next
> >>> [3] https://github.com/avinashphilip/am335x_linux/tree/davinci-for-v3.9_soc_pwm
> >>>
> >>> Note:
> >>> DT support for EHRPWM backlight has not been added in da850-evm.dts as there is
> >>> conflicting pin-mux requirement with SPI flash.
> >>
> >> Can you check if this is really true even in newer boards (have a look
> >> at the latest schematics)? I remember this used to be a problem in very
> >> early versions but was fixed later.
> > 
> > On looking schematics, panel has three power controls LCD_BACKLIGHT_PWR, LCD_PANEL_PWR,
> > LCD_PWM0. On latest schematic, LCD_PWM0 is connected to ECAP instance 2. So backlight
> > can control through ECAP2 (not conflicting with SPI1 cs0). Still for controlling
> > backlight, require support for LCD_BACKLIGHT_PWR & LCD_PANEL_PWR. These signals
> 
> By controlling above you mean "switching on/off"? Otherwise this seems
> to be contradicting the statement just before.

Yes these lines should be switching on/off.

> 
> > to be controlled by GPIO 2[8] & GPIO 2[15]. In release platform callbacks used
> > to control GPIO functionality. But with DT support, I have to check how platform
> > callbacks can be used.
> 
> Platform callbacks are not possible with DT.

Ok.

> You can look at what freescale mxsfb.c does. Look for panel-enable-gpios DT binding.

I will use GPIO pin configuration info from DT nodes. From probe GPIO pin make active and
in remove disable GPIO pin.

Thanks
Avinash

> 
> Thanks,
> Sekhar
> 


From g.liakhovetski at gmx.de  Thu Apr  4 02:47:22 2013
From: g.liakhovetski at gmx.de (Guennadi Liakhovetski)
Date: Thu, 4 Apr 2013 08:47:22 +0200 (CEST)
Subject: [PATCH/RFC 2/3] ARM: shmobile: initialise clock early on
 kzm9g-reference
In-Reply-To: <87zjxfdtt8.wl%kuninori.morimoto.gx@renesas.com>
References: <1365005636-17526-1-git-send-email-g.liakhovetski@gmx.de>
 <1365005636-17526-3-git-send-email-g.liakhovetski@gmx.de>
 <87zjxfdtt8.wl%kuninori.morimoto.gx@renesas.com>
Message-ID: <Pine.LNX.4.64.1304040830380.21548@axis700.grange>

Hi Morimoto-san

On Wed, 3 Apr 2013, Kuninori Morimoto wrote:

> Hi Guennadi
> 
> > To prepare to enable TWD on kzm9g-reference, clock initialisation has to be
> > done early. Move it from .init_machine to .init_time stage.
> > 
> > Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas at gmail.com>
> > ---
> (snip)
> > +static void __init timer_init(void)
> > +{
> > +	sh73a0_clock_init();
> > +	shmobile_timer_init();
> > +}
> 
> I'm not sure detail,
> but, shmobile_timer_init() will be removed.
> 
> Can you check these patch/email on SH-ML or ARM ML ?
> 
> Subject: [PATCH v2 02/13] ARM: convert arm/arm64 arch timer to use CLKSRC_OF init
> Date:	Mon,  1 Apr 2013 17:21:12 -0500
> 
> Subject: [PATCH v2 02/13] ARM: convert arm/arm64 arch timer to use CLKSRC_OF init
> Date:	Mon,  1 Apr 2013 17:21:12 -0500

Did you mean two different patches or was the duplication an accident? 
Anyway, thanks for a heads-up! I checked that patch, interesting. At least 
it's conflicting with this patch from Magnus:

"ARM: shmobile: Register DT TWD from timer.c"
https://patchwork.kernel.org/patch/2222551/

I know those patches are on a hold, but I was using the one above locally. 
If shmobile_timer_init() is removed, this won't be a huge problem for this 
work, I'll just have to call twd_local_timer_of_register() directly from 
.init_time, but whether these patches are good for upstream at all is 
another question, I'll expand on it a bit in a reply to Simon's mail.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/


From horms at verge.net.au  Thu Apr  4 02:52:23 2013
From: horms at verge.net.au (Simon Horman)
Date: Thu, 4 Apr 2013 15:52:23 +0900
Subject: [PATCH 0/5 v3] ARM: shmobile: Add SMSC support on Bock-W
In-Reply-To: <CANqRtoSEf7TuBN6DZ7Qn9S8h8ts_pxahpELEK2b4KgAVpN7svw@mail.gmail.com>
References: <87zjxvewko.wl%kuninori.morimoto.gx@renesas.com>
 <87fvzb56n3.wl%kuninori.morimoto.gx@renesas.com>
 <87sj395zvv.wl%kuninori.morimoto.gx@renesas.com>
 <CANqRtoSEf7TuBN6DZ7Qn9S8h8ts_pxahpELEK2b4KgAVpN7svw@mail.gmail.com>
Message-ID: <20130404065222.GR28297@verge.net.au>

On Wed, Apr 03, 2013 at 05:19:10PM +0900, Magnus Damm wrote:
> Hi Morimoto-san, Simon,
> 
> On Tue, Apr 2, 2013 at 1:18 PM, Kuninori Morimoto
> <kuninori.morimoto.gx at renesas.com> wrote:
> >
> > Hi Simon
> >
> > These patches are v3 of extpin support on r8a7778,
> > and enable SMSC ether support on Bock-W board
> >
> > This patch set is based latest simon/next
> >
> > Kuninori Morimoto (5):
> >       ARM: shmobile: r8a7778: remove pointless PLATFORM_INFO()
> >       ARM: shmobile: r8a7778: add r8a7778_init_irq_extpin()

	  Queued up in the soc-r8a7778 branch.

> >       ARM: shmobile: bockw: add SMSC ethernet support
> >       ARM: shmobile: bockw: enable network settings on bootargs

	  Queued up in the boards-bockw branch.

> >       ARM: shmobile: bockw: enable SMSC ethernet on defconfig

	  Queued up in the defconfig-bockw branch.

> Thanks, these are all fine with me.
> 
> Acked-by: Magnus Damm <damm at opensource.se>

I will endeavour to get this included in v3.10.


From kgene.kim at samsung.com  Thu Apr  4 02:57:23 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Thu, 04 Apr 2013 15:57:23 +0900
Subject: [PATCH 0/2] ARM: Exynos: Add DT based I/O mapping for Chip-ID
 controller
In-Reply-To: <1361174099-18749-1-git-send-email-thomas.abraham@linaro.org>
References: <1361174099-18749-1-git-send-email-thomas.abraham@linaro.org>
Message-ID: <27ea01ce3101$a8dae850$fa90b8f0$%kim@samsung.com>

Thomas Abraham wrote:
> 
> This patch series allows device tree enabled platforms to setup a runtime
> I/O mapping for the chip-id controller. This helps to remove statically
> defined I/O mapping for the Chip-ID controller.
> 
> Thomas Abraham (2):
>   ARM: Exynos: Create virtual I/O mapping for Chip-ID controller using
> device tree
>   ARM: dts: Add chip-id controller node on Exynos4/5 SoC
> 
>  .../arm/samsung/samsung,exynos4210-chipid.txt      |   15 ++++++
>  arch/arm/boot/dts/exynos4.dtsi                     |    5 ++
>  arch/arm/boot/dts/exynos5250.dtsi                  |    5 ++
>  arch/arm/mach-exynos/common.c                      |   53
+++++++++++---------
>  arch/arm/mach-exynos/include/mach/map.h            |    1 -
>  5 files changed, 55 insertions(+), 24 deletions(-)
>  create mode 100644
> Documentation/devicetree/bindings/arm/samsung/samsung,exynos4210-
> chipid.txt
> 
> --
> 1.7.5.4

Thomas,

Can you update this series can support exynos5440 as well? It should be done
together.

- Kukjin



From kuninori.morimoto.gx at renesas.com  Thu Apr  4 03:02:18 2013
From: kuninori.morimoto.gx at renesas.com (Kuninori Morimoto)
Date: Thu, 04 Apr 2013 00:02:18 -0700 (PDT)
Subject: [PATCH/RFC 2/3] ARM: shmobile: initialise clock early on
 kzm9g-reference
In-Reply-To: <Pine.LNX.4.64.1304040830380.21548@axis700.grange>
References: <1365005636-17526-1-git-send-email-g.liakhovetski@gmx.de>
 <1365005636-17526-3-git-send-email-g.liakhovetski@gmx.de>
 <87zjxfdtt8.wl%kuninori.morimoto.gx@renesas.com>
 <Pine.LNX.4.64.1304040830380.21548@axis700.grange>
Message-ID: <87vc82eq2x.wl%kuninori.morimoto.gx@renesas.com>


Hi Guennadi

> > Subject: [PATCH v2 02/13] ARM: convert arm/arm64 arch timer to use CLKSRC_OF init
> > Date:	Mon,  1 Apr 2013 17:21:12 -0500
> > 
> > Subject: [PATCH v2 02/13] ARM: convert arm/arm64 arch timer to use CLKSRC_OF init
> > Date:	Mon,  1 Apr 2013 17:21:12 -0500
> 
> Did you mean two different patches or was the duplication an accident? 

Sorry, it was my copy-paste fault

> Anyway, thanks for a heads-up! I checked that patch, interesting. At least 
> it's conflicting with this patch from Magnus:
> 
> "ARM: shmobile: Register DT TWD from timer.c"
> https://patchwork.kernel.org/patch/2222551/
> 
> I know those patches are on a hold, but I was using the one above locally. 
> If shmobile_timer_init() is removed, this won't be a huge problem for this 
> work, I'll just have to call twd_local_timer_of_register() directly from 
> .init_time, but whether these patches are good for upstream at all is 
> another question, I'll expand on it a bit in a reply to Simon's mail.

Thank you for your help !

Best regards
---
Kuninori Morimoto


From kuninori.morimoto.gx at renesas.com  Thu Apr  4 03:08:31 2013
From: kuninori.morimoto.gx at renesas.com (Kuninori Morimoto)
Date: Thu, 04 Apr 2013 00:08:31 -0700 (PDT)
Subject: APE6EVM and Runtime PM
In-Reply-To: <20130404061429.GJ28297@verge.net.au>
References: <20130404020019.GA7163@verge.net.au>
 <87wqsjdlhv.wl%kuninori.morimoto.gx@renesas.com>
 <20130404044101.GG28297@verge.net.au>
 <uy5cy7tkp.wl%kuninori.morimoto.gx@renesas.com>
 <20130404061429.GJ28297@verge.net.au>
Message-ID: <87r4iqepsk.wl%kuninori.morimoto.gx@renesas.com>


Hi Simon

> > I didn't check real board,
> > but I guess current SMSC IRQ came from IRQC,
> > and this IRQC needs MSTP 407.
> > But IRQC driver seems doesn't support PM_RUNTIME at this point.
> > 
> > Does your issue solve by adding MSTP 407 with CLK_ENABLE_ON_INIT ?
> > I'm not sure this is good solution, but quick-hack
> 
> Thanks!
> 
> I will post a patch to add pm_runtime support to the IRQC Driver.
> It seems to allow SMSC + RUNTIME_PM to function on the APE6EVM.

Cool !!
Thanks

Best regards
---
Kuninori Morimoto


From g.liakhovetski at gmx.de  Thu Apr  4 03:13:07 2013
From: g.liakhovetski at gmx.de (Guennadi Liakhovetski)
Date: Thu, 4 Apr 2013 09:13:07 +0200 (CEST)
Subject: [PATCH/RFC 2/3] ARM: shmobile: initialise clock early on
 kzm9g-reference
In-Reply-To: <20130404033158.GA28297@verge.net.au>
References: <1365005636-17526-1-git-send-email-g.liakhovetski@gmx.de>
 <1365005636-17526-3-git-send-email-g.liakhovetski@gmx.de>
 <20130404033158.GA28297@verge.net.au>
Message-ID: <Pine.LNX.4.64.1304040847260.21548@axis700.grange>

Hi Simon

On Thu, 4 Apr 2013, Simon Horman wrote:

> On Wed, Apr 03, 2013 at 06:13:55PM +0200, Guennadi Liakhovetski wrote:
> > To prepare to enable TWD on kzm9g-reference, clock initialisation has to be
> > done early. Move it from .init_machine to .init_time stage.
> 
> I'm pretty surprised by this given how much effort has
> been made to avoid early clock initialisation.

Yes, sorry, I probably failed to explain exactly the meaning of "RFC" in 
these patches. My goal was to find a way to activate the TWD on kzm9g in 
the "-reference" configuration, i.e. with DT, when TWD is also 
instantiated as a DT node. This didn't work out of the box by simply 
adding the respective DT node as in patch/rfc #3 in this series. Doing 
that just resulted in a lock up with no output. The reason was, that TWD 
was trying to initialise before any other timers / clocks and its 
calibration in twd_calibrate_rate() was cycling endlessly. So, I tried to 
find a way to fix this lock-up, which produced these RFCs. I'm perfectly 
aware, that this might not be what we want to have in the mainline, this 
is just an illustration, what I had to do to get TWD running with DT.

As for "avoid early clock initialisation" - I'm aware of this goal in 
principle, but I'm not sure about details - how early is too early and 
when it is already allowed, why is this important with DT and not with 
legacy (because we want to initialise all clocks from DT?), what are 
proper ways to solve problems like this one? Note, that TWD has to be 
registered before secondary_start_kernel() is run. So, we need a 
clocksource before that time for a successful TWD calibration.

Thanks
Guennadi

> > Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas at gmail.com>
> > ---
> >  arch/arm/mach-shmobile/board-kzm9g-reference.c |    8 +++++++-
> >  arch/arm/mach-shmobile/setup-sh73a0.c          |   13 +++++++++----
> >  2 files changed, 16 insertions(+), 5 deletions(-)
> > 
> > diff --git a/arch/arm/mach-shmobile/board-kzm9g-reference.c b/arch/arm/mach-shmobile/board-kzm9g-reference.c
> > index aefa50d..0f9b276 100644
> > --- a/arch/arm/mach-shmobile/board-kzm9g-reference.c
> > +++ b/arch/arm/mach-shmobile/board-kzm9g-reference.c
> > @@ -90,6 +90,12 @@ static void __init kzm_init(void)
> >  #endif
> >  }
> >  
> > +static void __init timer_init(void)
> > +{
> > +	sh73a0_clock_init();
> > +	shmobile_timer_init();
> > +}
> > +
> >  static const char *kzm9g_boards_compat_dt[] __initdata = {
> >  	"renesas,kzm9g-reference",
> >  	NULL,
> > @@ -102,6 +108,6 @@ DT_MACHINE_START(KZM9G_DT, "kzm9g-reference")
> >  	.nr_irqs	= NR_IRQS_LEGACY,
> >  	.init_irq	= irqchip_init,
> >  	.init_machine	= kzm_init,
> > -	.init_time	= shmobile_timer_init,
> > +	.init_time	= timer_init,
> >  	.dt_compat	= kzm9g_boards_compat_dt,
> >  MACHINE_END
> > diff --git a/arch/arm/mach-shmobile/setup-sh73a0.c b/arch/arm/mach-shmobile/setup-sh73a0.c
> > index 0469e84..8a1bc1c 100644
> > --- a/arch/arm/mach-shmobile/setup-sh73a0.c
> > +++ b/arch/arm/mach-shmobile/setup-sh73a0.c
> > @@ -1018,9 +1018,6 @@ void __init sh73a0_add_standard_devices_dt(void)
> >  {
> >  	struct platform_device_info devinfo = { .name = "cpufreq-cpu0", .id = -1, };
> >  
> > -	/* clocks are setup late during boot in the case of DT */
> > -	sh73a0_clock_init();
> > -
> >  	platform_add_devices(sh73a0_devices_dt,
> >  			     ARRAY_SIZE(sh73a0_devices_dt));
> >  	of_platform_populate(NULL, of_default_bus_match_table,
> > @@ -1030,6 +1027,14 @@ void __init sh73a0_add_standard_devices_dt(void)
> >  	platform_device_register_full(&devinfo);
> >  }
> >  
> > +static void __init add_standard_devices(void)
> > +{
> > +	/* clocks are setup late during boot in the case of DT */
> > +	sh73a0_clock_init();
> > +
> > +	sh73a0_add_standard_devices_dt();
> > +}
> > +
> >  static const char *sh73a0_boards_compat_dt[] __initdata = {
> >  	"renesas,sh73a0",
> >  	NULL,
> > @@ -1041,7 +1046,7 @@ DT_MACHINE_START(SH73A0_DT, "Generic SH73A0 (Flattened Device Tree)")
> >  	.init_early	= sh73a0_init_delay,
> >  	.nr_irqs	= NR_IRQS_LEGACY,
> >  	.init_irq	= irqchip_init,
> > -	.init_machine	= sh73a0_add_standard_devices_dt,
> > +	.init_machine	= add_standard_devices,
> >  	.init_time	= shmobile_timer_init,
> >  	.dt_compat	= sh73a0_boards_compat_dt,
> >  MACHINE_END
> > -- 
> > 1.7.2.5
> > 
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> > the body of a message to majordomo at vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > 
> 

---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/


From pgaikwad at nvidia.com  Thu Apr  4 03:14:06 2013
From: pgaikwad at nvidia.com (Prashant Gaikwad)
Date: Thu, 4 Apr 2013 12:44:06 +0530
Subject: [PATCH v8 10/14] ARM: tegra: Define Tegra114 CAR binding
In-Reply-To: <20130403141916.GS18519@tbergstrom-lnx.Nvidia.com>
References: <1363956029-31873-1-git-send-email-pdeschrijver@nvidia.com>
 <1363956029-31873-11-git-send-email-pdeschrijver@nvidia.com>
 <515031E3.40007@nvidia.com>
 <20130403141916.GS18519@tbergstrom-lnx.Nvidia.com>
Message-ID: <515D283E.5060209@nvidia.com>

On Wednesday 03 April 2013 07:49 PM, Peter De Schrijver wrote:
> On Mon, Mar 25, 2013 at 12:15:47PM +0100, Prashant Gaikwad wrote:
>> On Friday 22 March 2013 06:09 PM, Peter De Schrijver wrote:
>>> The device tree binding models Tegra114 CAR (Clock And Reset) as a single
>>> monolithic clock provider.
>>>
>>> Signed-off-by: Peter De Schrijver <pdeschrijver at nvidia.com>
>>> ---
>> <snip>
>>
>>> +  263	cclk_lp
>>> +  264	dfll_ref
>>> +  265	dfll_soc
>>> +
>> Peter,
>>
>> Please remove following clock IDs from binding.
>>
>>> +Mux clocks
>>> +
> ...
>>> +  306	clk_out_1_mux
> Is at least used by the init list. So we can't remove that?

Init list is internal to driver and does not use device tree, so we can 
keep that ID in enum but remove from DT binding so that we don't have to 
change the binding later.

>
> Cheers,
>
> Peter.



From balbi at ti.com  Thu Apr  4 03:15:34 2013
From: balbi at ti.com (Felipe Balbi)
Date: Thu, 4 Apr 2013 10:15:34 +0300
Subject: [PATCH v5 1/6] drivers: phy: add generic PHY framework
In-Reply-To: <515CC123.4060402@wwwdotorg.org>
References: <1364993634-6378-1-git-send-email-kishon@ti.com>
 <1364993634-6378-2-git-send-email-kishon@ti.com>
 <515CC123.4060402@wwwdotorg.org>
Message-ID: <20130404071534.GC30287@arwen.pp.htv.fi>

Hi,

On Wed, Apr 03, 2013 at 05:54:11PM -0600, Stephen Warren wrote:
> struct phy {
> 	struct device *dev;
> 	struct module *owner;
> 	int	(*init)(struct phy *phy);
> 	int	(*exit)(struct phy *phy);
> 	int	(*suspend)(struct phy *phy);
> 	int	(*resume)(struct phy *phy);

I wonder whether it makes sense to provide ->suspend/->resume callbacks
here. We already have dev_pm_ops providing those methods and we can just
wrap pm_runtime_* calls to be called by consumers.

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130404/c71b8872/attachment.sig>

From nsekhar at ti.com  Thu Apr  4 03:16:02 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Thu, 4 Apr 2013 12:46:02 +0530
Subject: [PATCH 6/9] ARM: davinci: cpuidle: fix wrong enter function
In-Reply-To: <1364991322-20585-6-git-send-email-daniel.lezcano@linaro.org>
References: <1364991322-20585-1-git-send-email-daniel.lezcano@linaro.org>
 <1364991322-20585-6-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <515D28B2.90408@ti.com>

On 4/3/2013 5:45 PM, Daniel Lezcano wrote:
> The davinci_enter_idle is called from the cpuidle with the
> cpuidle_wrap_enter function. This one does the time compution
> for entering and exiting the idle function and then we call
> again cpuidle_wrap_enter for cpu_do_idle. This is wrong, we
> are calling recursively cpuidle_wrap_enter for nothing and
> furthermore reenabling the local irq.
> 
> Remove this and replace it by the cpu_do_idle function.
> 
> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
> Acked-by: Santosh Shilimkar <santosh.shilimkar at ti.com>

Acked-by: Sekhar Nori <nsekhar at ti.com>

Thanks,
Sekhar


From lee.jones at linaro.org  Thu Apr  4 03:20:16 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Thu, 4 Apr 2013 08:20:16 +0100
Subject: [PATCH 4/9] ARM: ux500: Move Snowball's thermal DT node into
 existing PRCMU one
In-Reply-To: <CACRpkda08Joe9aXRgYDUs622GELL+O1vZSnzzCBa++m1zZZi=g@mail.gmail.com>
References: <1364908916-29803-1-git-send-email-lee.jones@linaro.org>
 <1364908916-29803-4-git-send-email-lee.jones@linaro.org>
 <CACRpkdar=xD34yaMP2gOfUPkpxOhDymS6zTedKOEW7j2DNHusA@mail.gmail.com>
 <CACRpkda08Joe9aXRgYDUs622GELL+O1vZSnzzCBa++m1zZZi=g@mail.gmail.com>
Message-ID: <20130404072016.GA3004@gmail.com>

On Wed, 03 Apr 2013, Linus Walleij wrote:

> On Wed, Apr 3, 2013 at 10:38 PM, Linus Walleij <linus.walleij at linaro.org> wrote:
> > On Tue, Apr 2, 2013 at 3:21 PM, Lee Jones <lee.jones at linaro.org> wrote:
> >
> >> When the thermal DT node was inserted a new PRCMU node was created;
> >> however, one already exists in the Snowball DTS file. Here we
> >> amalgamate the two into a single consolidated node.
> >>
> >> Signed-off-by: Lee Jones <lee.jones at linaro.org>
> >
> > Patch applied.
> 
> After applying this I get this:
> 
>   DTC     arch/arm/boot/dts/snowball.dtb
> Error: /home/elinwal/linux-stericsson/arch/arm/boot/dts/snowball.dts:351.3-352.1
> syntax error
> FATAL ERROR: Unable to parse input tree
> make[3]: *** [arch/arm/boot/dts/snowball.dtb] Error 1
> make[2]: *** [dtbs] Error 2
> make[1]: *** [sub-make] Error 2
> make[1]: Leaving directory `/home/elinwal/linux-stericsson'
> make: *** [build-dtbs] Error 2
> 
> Does not appear prior to applying patch.

That doesn't really tell me anything.

Can you paste the hunk to which the error is referring please?

> It doesn't quiet apply cleanly either, what is this based on?

It's based on 'arm-soc/fixes', which should be appearing in Mainline
rc:s any day now.

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From andrew at lunn.ch  Thu Apr  4 03:25:03 2013
From: andrew at lunn.ch (Andrew Lunn)
Date: Thu, 4 Apr 2013 09:25:03 +0200
Subject: [PATCH 2/6] rtc: rtc-m48t86: add hooks to support driver side
 memory mapping
In-Reply-To: <1364858565-17192-3-git-send-email-alex@digriz.org.uk>
References: <1364858565-17192-1-git-send-email-alex@digriz.org.uk>
 <1364858565-17192-3-git-send-email-alex@digriz.org.uk>
Message-ID: <20130404072503.GE28914@lunn.ch>

> -static int m48t86_rtc_probe(struct platform_device *dev)
> +static int m48t86_rtc_probe(struct platform_device *pdev)
>  {
>  	unsigned char reg;
> -	struct m48t86_ops *ops = dev->dev.platform_data;
> -	struct rtc_device *rtc = rtc_device_register("m48t86",
> -				&dev->dev, &m48t86_rtc_ops, THIS_MODULE);
> -
> -	if (IS_ERR(rtc))
> -		return PTR_ERR(rtc);
> -
> -	platform_set_drvdata(dev, rtc);
> +	int err;
> +	struct resource *res_index, *res_data;
> +	struct m48t86_rtc_private_data *priv;
> +
> +	/* Allocate memory for the device structure (and zero it) */
> +	priv = kzalloc(sizeof(struct m48t86_rtc_private_data), GFP_KERNEL);
> +	if (!priv)
> +		return -ENOMEM;
> +
> +	platform_set_drvdata(pdev, priv);
> +
> +	if (!pdev->dev.platform_data) {
> +		res_index = platform_get_resource_byname(
> +					pdev, IORESOURCE_MEM, "rtc_index");
> +		if (!res_index) {
> +			err = -ENXIO;
> +			goto out_free;
> +		}
> +
> +		res_data = platform_get_resource_byname(
> +					pdev, IORESOURCE_MEM, "rtc_data");
> +		if (!res_data) {
> +			err = -ENXIO;
> +			goto out_free;
> +		}
> +
> +		if (!request_mem_region(res_index->start,
> +					resource_size(res_index),
> +					dev_name(&pdev->dev))) {
> +			err = -EBUSY;
> +			goto out_free;
> +		}
> +
> +		if (!request_mem_region(res_data->start,
> +					resource_size(res_data),
> +					dev_name(&pdev->dev))) {
> +			err = -EBUSY;
> +			goto out_release_index;
> +		}
> +
> +		priv->io_index = ioremap(res_index->start,
> +					resource_size(res_index));
> +		if (!priv->io_index) {
> +			err = -EIO;
> +			goto out_release_data;
> +		}
> +
> +		priv->io_data = ioremap(res_data->start,
> +					resource_size(res_data));
> +		if (!priv->io_data) {
> +			err = -EIO;
> +			goto out_io_index;
> +		}
> +	} else

Hi Alexander

It would be good to use the devm_ functions here. It will make the
cleanup on error much simpler, solve your warnings problem, and simply
the remove function.


> +		priv->ops = pdev->dev.platform_data;
> +
> +	priv->rtc = rtc_device_register("m48t86",
> +				&pdev->dev, &m48t86_rtc_ops, THIS_MODULE);
> +	if (IS_ERR(priv->rtc)) {
> +		err = PTR_ERR(priv->rtc);
> +		if (!pdev->dev.platform_data)
> +			goto out_io_data;
> +		else
> +			goto out_free;
> +	}
>  
>  	/* read battery status */
> -	reg = ops->readbyte(M48T86_REG_D);
> -	dev_info(&dev->dev, "battery %s\n",
> +	reg = m48t86_rtc_readbyte(&pdev->dev, M48T86_REG_D);
> +	dev_info(&pdev->dev, "battery %s\n",
>  		(reg & M48T86_REG_D_VRT) ? "ok" : "exhausted");
>  
>  	return 0;
> +
> +out_io_data:
> +	iounmap(priv->io_data);
> +out_io_index:
> +	iounmap(priv->io_index);
> +out_release_data:
> +	release_mem_region(res_data->start, resource_size(res_data));
> +out_release_index:
> +	release_mem_region(res_index->start, resource_size(res_index));
> +out_free:
> +	platform_set_drvdata(pdev, NULL);
> +	kfree(priv);
> +	return err;
>  }
>  
> -static int m48t86_rtc_remove(struct platform_device *dev)
> +static int m48t86_rtc_remove(struct platform_device *pdev)
>  {
> -	struct rtc_device *rtc = platform_get_drvdata(dev);
> +	struct resource *res;
> +	struct m48t86_rtc_private_data *priv = platform_get_drvdata(pdev);
> +
> +	if (priv->rtc)
> +		rtc_device_unregister(priv->rtc);
> +
> +	if (priv->io_data) {
> +		iounmap(priv->io_data);
> +		res = platform_get_resource_byname(
> +					pdev, IORESOURCE_MEM, "rtc_data");
> +		release_mem_region(res->start, resource_size(res));
> +	}
> +
> +	if (priv->io_index) {
> +		iounmap(priv->io_index);
> +		res = platform_get_resource_byname(
> +					pdev, IORESOURCE_MEM, "rtc_index");
> +		release_mem_region(res->start, resource_size(res));
> +	}
>  
> - 	if (rtc)
> -		rtc_device_unregister(rtc);
> +	platform_set_drvdata(pdev, NULL);
>  
> -	platform_set_drvdata(dev, NULL);
> +	kfree(priv);
>  
>  	return 0;
>  }
> -- 
> 1.7.10.4
> 


From lee.jones at linaro.org  Thu Apr  4 03:29:07 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Thu, 4 Apr 2013 08:29:07 +0100
Subject: [PATCH] ARM: ux500: Supply a DTS file for the u8540 platform
In-Reply-To: <CACRpkdafSvT5Xb=7sqnkRHcc4UKkVzr8jzThMgWn6459RDmKGw@mail.gmail.com>
References: <1364908916-29803-1-git-send-email-lee.jones@linaro.org>
 <1364908916-29803-3-git-send-email-lee.jones@linaro.org>
 <CACRpkdafSvT5Xb=7sqnkRHcc4UKkVzr8jzThMgWn6459RDmKGw@mail.gmail.com>
Message-ID: <20130404072907.GB3004@gmail.com>

This is a skeleton DTS file which only enables serial. Just using
this simple file yields a terminal when booting u8540.

Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/boot/dts/ccu8540.dts |   36 ++++++++++++++++++++++++++++++++++++
 1 file changed, 36 insertions(+)
 create mode 100644 arch/arm/boot/dts/ccu8540.dts

diff --git a/arch/arm/boot/dts/ccu8540.dts b/arch/arm/boot/dts/ccu8540.dts
new file mode 100644
index 0000000..02e8e1a
--- /dev/null
+++ b/arch/arm/boot/dts/ccu8540.dts
@@ -0,0 +1,36 @@
+/*
+ * Copyright 2013 ST-Ericsson AB
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+/dts-v1/;
+/include/ "dbx5x0.dtsi"
+
+/ {
+  model = "ST-Ericsson U8540 platform with Device Tree";
+  compatible = "st-ericsson,u8540";
+
+	memory {
+	       reg = <0x00000000 0x20000000>;
+	       };
+
+	soc-u9500 {
+		  uart at 80120000 {
+					status = "okay";
+					       };
+
+		uart at 80121000 {
+				status = "okay";
+				       };
+
+		uart at 80007000 {
+				status = "okay";
+				       };
+				       };
+};
-- 
1.7.10.4


From lee.jones at linaro.org  Thu Apr  4 03:33:40 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Thu, 4 Apr 2013 08:33:40 +0100
Subject: [PATCH] ARM: ux500: Over-ride TCDM size when booting the DB8540
 platform
In-Reply-To: <CACRpkdbh-DJti2ny=uBe-b_vGkQBNL=emMuZ6+_cE5jvRsA4sA@mail.gmail.com>
References: <1364908916-29803-1-git-send-email-lee.jones@linaro.org>
 <1364908916-29803-5-git-send-email-lee.jones@linaro.org>
 <CACRpkdbh-DJti2ny=uBe-b_vGkQBNL=emMuZ6+_cE5jvRsA4sA@mail.gmail.com>
Message-ID: <20130404073340.GA6892@gmail.com>

The PRCMU's Tightly Coupled Data Memory on the DB8540 platform is
8kB larger than it's predecessor's. We need to reflect that in its
Device Tree. By re-specifying the address and size of the device
we effectively over-ride the previous values with more accurate
ones.

Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/boot/dts/ccu8540.dts |    5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/ccu8540.dts b/arch/arm/boot/dts/ccu8540.dts
index 02e8e1a..f829689 100644
--- a/arch/arm/boot/dts/ccu8540.dts
+++ b/arch/arm/boot/dts/ccu8540.dts
@@ -21,6 +21,11 @@
 	};
 
 	soc-u9500 {
+		prcmu at 80157000 {
+			reg = <0x80157000 0x2000>, <0x801b0000 0x8000>, <0x801b8000 0x3000>;
+			reg-names = "prcmu", "prcmu-tcpm-per4", "prcmu-tcdm-per4";
+		};
+
 		uart at 80120000 {
 			status = "okay";
 		};
-- 
1.7.10.4


From rogerq at ti.com  Thu Apr  4 03:35:12 2013
From: rogerq at ti.com (Roger Quadros)
Date: Thu, 4 Apr 2013 10:35:12 +0300
Subject: [RFC][PATCH 1/2] ARM: OMAP4: clock: Add device tree support for
 AUXCLKs
In-Reply-To: <20130403234242.GE10155@atomide.com>
References: <1363703220-4777-1-git-send-email-rogerq@ti.com>
 <1363703220-4777-2-git-send-email-rogerq@ti.com>
 <20130403234242.GE10155@atomide.com>
Message-ID: <515D2D30.3000306@ti.com>

Hi,

On 04/04/2013 02:42 AM, Tony Lindgren wrote:
> Hi,
> 
> * Roger Quadros <rogerq at ti.com> [130319 07:31]:
>> Register a device tree clock provider for AUX clocks
>> on the OMAP4 SoC. Also provide the binding information.
>>
>> Signed-off-by: Roger Quadros <rogerq at ti.com>
>> ---
>>  .../devicetree/bindings/clock/omap4-clock.txt      |   32 ++++++++++++++++++
>>  arch/arm/boot/dts/omap4.dtsi                       |    5 +++
>>  arch/arm/mach-omap2/board-generic.c                |    2 +-
>>  arch/arm/mach-omap2/cclock44xx_data.c              |   35 ++++++++++++++++++++
>>  arch/arm/mach-omap2/clock44xx.h                    |    1 +
>>  arch/arm/mach-omap2/common.h                       |    9 +++++
>>  arch/arm/mach-omap2/io.c                           |    6 +++
>>  7 files changed, 89 insertions(+), 1 deletions(-)
>>  create mode 100644 Documentation/devicetree/bindings/clock/omap4-clock.txt
>>
> ...
> 
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/clock/omap4-clock.txt
> 
> Is this really specific to omap4 and auxclk only?
> 
> Shouldn't it be just omap-clock.txt?

Yes, I've fixed this up in v2 of this patch.

> 
>> --- a/arch/arm/mach-omap2/cclock44xx_data.c
>> +++ b/arch/arm/mach-omap2/cclock44xx_data.c
>> @@ -27,6 +27,7 @@
>>  #include <linux/clk-private.h>
>>  #include <linux/clkdev.h>
>>  #include <linux/io.h>
>> +#include <linux/of.h>
>>  
>>  #include "soc.h"
>>  #include "iomap.h"
>> @@ -1663,6 +1664,40 @@ static struct omap_clk omap44xx_clks[] = {
>>  	CLK(NULL,	"cpufreq_ck",	&dpll_mpu_ck,	CK_443X),
>>  };
>>  
>> +static struct clk *scrm_clks[] = {
>> +	&auxclk0_ck,
>> +	&auxclk1_ck,
>> +	&auxclk2_ck,
>> +	&auxclk3_ck,
>> +	&auxclk4_ck,
>> +	&auxclk5_ck,
>> +};
> 
> Hmm I don't like the idea of specifying the auxclk both in the
> cclock44xx_data.c and in DT..

Right, but till we have all clocks moved to DT we only need this
approach for general purpose clocks that are not mapped to devices
by hwmod.

e.g. auxclk are required to be specified in DT nodes for USB PHY.
Without this we can't get USB host working on Panda.

As Rajendra points out, it seems moving entire clock data to DT is not
going to happen soon. So this is the simplistic way things can work.

cheers,
-roger


From p.zabel at pengutronix.de  Thu Apr  4 03:37:31 2013
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Thu, 04 Apr 2013 09:37:31 +0200
Subject: [PATCH 1/3] video: Make IPU KMS parse display-timings
In-Reply-To: <1365003390-26964-1-git-send-email-rogerio.pimentel@freescale.com>
References: <1365003390-26964-1-git-send-email-rogerio.pimentel@freescale.com>
Message-ID: <1365061051.4089.2.camel@pizza.hi.pengutronix.de>

Am Mittwoch, den 03.04.2013, 12:36 -0300 schrieb Rogerio Pimentel:
> From: Marek Vasut <marex at denx.de>
> 
> This patch adds support for parsing of the DT display-timings prop
> to IPU KMS driver.
> 
> Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
> Signed-off-by: Marek Vasut <marex at denx.de>
> ---
>  drivers/staging/imx-drm/parallel-display.c |   10 ++++++++++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/drivers/staging/imx-drm/parallel-display.c b/drivers/staging/imx-drm/parallel-display.c
> index a8064fc..2a25202 100644
> --- a/drivers/staging/imx-drm/parallel-display.c
> +++ b/drivers/staging/imx-drm/parallel-display.c
> @@ -57,6 +57,7 @@ static void imx_pd_connector_destroy(struct drm_connector *connector)
>  static int imx_pd_connector_get_modes(struct drm_connector *connector)
>  {
>  	struct imx_parallel_display *imxpd = con_to_imxpd(connector);
> +	struct device_node *np = imxpd->dev->of_node;
>  	int num_modes = 0;
>  
>  	if (imxpd->edid) {
> @@ -72,6 +73,15 @@ static int imx_pd_connector_get_modes(struct drm_connector *connector)
>  		num_modes++;
>  	}
>  
> +	if (np) {
> +		struct drm_display_mode *mode = drm_mode_create(connector->dev);
> +		of_get_drm_display_mode(np, &imxpd->mode, 0);

Since the mode is stored in imxpd->mode anyway, of_get_drm_display_mode
could be called once in the probe function instead of every time
get_modes is called.

> +		drm_mode_copy(mode, &imxpd->mode);
> +		mode->type |= DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED,
> +		drm_mode_probed_add(connector, mode);
> +		num_modes++;
> +	}
> +
>  	return num_modes;
>  }

regards
Philipp



From michal.simek at xilinx.com  Thu Apr  4 03:39:02 2013
From: michal.simek at xilinx.com (Michal Simek)
Date: Thu, 4 Apr 2013 09:39:02 +0200
Subject: [GIT PULL] arm-soc: Xilinx zynq timer changes for v3.10
Message-ID: <1e33aafc-ee95-42ab-b5d7-048c1d7d0664@CO9EHSMHS023.ehs.local>

Hi Arnd and Olof,

please pull these zynq timer changes to your arm-soc tree.

This tree is based on clksrc/cleanup branch because these changes related
on Rob changes in clksrc-of.c.

Please let me know if you have any problem with it.

Thanks,
Michal


The following changes since commit 3d5a96582303e28c48699f3faaf920ef7d43e6f2:

   clocksource: make CLOCKSOURCE_OF_DECLARE type safe (2013-03-28 12:01:06 +0100)

are available in the git repository at:

   git://git.xilinx.com/linux-xlnx.git zynq/clksrc/cleanup

for you to fetch changes up to 4f0f234fce1d263cc9881456352e8fd56ead0514:

   arm: zynq: Move timer to generic location (2013-04-04 09:22:09 +0200)

----------------------------------------------------------------
Michal Simek (4):
       arm: zynq: Use standard timer binding
       arm: zynq: Move timer to clocksource interface
       arm: zynq: Do not use xilinx specific function names
       arm: zynq: Move timer to generic location

  .../bindings/timer/cadence,ttc-timer.txt           |   17 +
  arch/arm/boot/dts/zynq-7000.dtsi                   |   45 +-
  arch/arm/boot/dts/zynq-zc702.dts                   |   10 -
  arch/arm/mach-zynq/Kconfig                         |    1 +
  arch/arm/mach-zynq/Makefile                        |    2 +-
  arch/arm/mach-zynq/common.c                        |    3 +-
  arch/arm/mach-zynq/common.h                        |    2 -
  arch/arm/mach-zynq/timer.c                         |  324 ---------------
  drivers/clocksource/Kconfig                        |    3 +
  drivers/clocksource/Makefile                       |    1 +
  drivers/clocksource/cadence_ttc_timer.c            |  436 ++++++++++++++++++++
  11 files changed, 467 insertions(+), 377 deletions(-)
  create mode 100644 Documentation/devicetree/bindings/timer/cadence,ttc-timer.txt
  delete mode 100644 arch/arm/mach-zynq/timer.c
  create mode 100644 drivers/clocksource/cadence_ttc_timer.c




From p.zabel at pengutronix.de  Thu Apr  4 03:40:17 2013
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Thu, 04 Apr 2013 09:40:17 +0200
Subject: [PATCH 2/3] ARM: dts: mx53qsb: Add support for parallel display
In-Reply-To: <1365003390-26964-2-git-send-email-rogerio.pimentel@freescale.com>
References: <1365003390-26964-1-git-send-email-rogerio.pimentel@freescale.com>
 <1365003390-26964-2-git-send-email-rogerio.pimentel@freescale.com>
Message-ID: <1365061217.4089.5.camel@pizza.hi.pengutronix.de>

Am Mittwoch, den 03.04.2013, 12:36 -0300 schrieb Rogerio Pimentel:
> Add support for CLAA WVGA display for i.MX53 QSB.
>
> Signed-off-by: Rogerio Pimentel <rogerio.pimentel at freescale.com>
> ---
>  arch/arm/boot/dts/imx53-qsb.dtsp |   26 ++++++++++++++++++++++++++
>  arch/arm/boot/dts/imx53.dtsip    |   35 +++++++++++++++++++++++++++++++++++
>  2 files changed, 61 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/imx53-qsb.dtsp b/arch/arm/boot/dts/imx53-qsb.dtsp
> index dae8d9f..f9449b0 100644
> --- a/arch/arm/boot/dts/imx53-qsb.dtsp
> +++ b/arch/arm/boot/dts/imx53-qsb.dtsp
> @@ -21,6 +21,32 @@
>  		reg = <0x70000000 0x40000000>;
>  	};
>  
> +	display at di0 {
> +		compatible = "fsl,imx-parallel-display";
> +		crtcs = <&ipu 0>;
> +		interface-pix-fmt = "rgb565";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&pinctrl_ipu_disp1_1>;

pinctrl_ipu_disp0_1, see below.

> +		display-timings {
> +			claawvga {
> +				native-mode;
> +				clock-frequency = <27000000>;
> +				hactive = <800>;
> +				vactive = <480>;
> +				hback-porch = <40>;
> +				hfront-porch = <60>;
> +				vback-porch = <10>;
> +				vfront-porch = <10>;
> +				hsync-len = <20>;
> +				vsync-len = <10>;
> +				hsync-active = <0>;
> +				vsync-active = <0>;
> +				de-active = <1>;
> +				pixelclk-active = <0>;
> +			};
> +		};
> +	};
> +
>  	gpio-keys {
>  		compatible = "gpio-keys";
>  
> diff --git a/arch/arm/boot/dts/imx53.dtsip b/arch/arm/boot/dts/imx53.dtsip
> index 6c73bee..d2cd67e 100644
> --- a/arch/arm/boot/dts/imx53.dtsip
> +++ b/arch/arm/boot/dts/imx53.dtsip
> @@ -441,6 +441,41 @@
>  					};
>  				};
>  
> +				ipu_disp1 {
> +					pinctrl_ipu_disp1_1: ipudisp1grp-1 {

This should be pinctrl_ipu_disp0_1: ipudisp0grp-1, since this is
configuring the DISP0 pads. pinctrl_ipu_disp1_1 should be used to
configure DISP1 pads instead.

> +						fsl,pins = <
> +						MX53_PAD_DI0_DISP_CLK__IPU_DI0_DISP_CLK 0x5
> +						MX53_PAD_DI0_PIN15__IPU_DI0_PIN15 0x5
> +						MX53_PAD_DI0_PIN2__IPU_DI0_PIN2 0x5
> +						MX53_PAD_DI0_PIN3__IPU_DI0_PIN3  0x5
> +						MX53_PAD_DISP0_DAT0__IPU_DISP0_DAT_0 0x5
> +						MX53_PAD_DISP0_DAT1__IPU_DISP0_DAT_1 0x5
> +						MX53_PAD_DISP0_DAT2__IPU_DISP0_DAT_2 0x5
> +						MX53_PAD_DISP0_DAT3__IPU_DISP0_DAT_3 0x5
> +						MX53_PAD_DISP0_DAT4__IPU_DISP0_DAT_4 0x5
> +						MX53_PAD_DISP0_DAT5__IPU_DISP0_DAT_5 0x5
> +						MX53_PAD_DISP0_DAT6__IPU_DISP0_DAT_6 0x5
> +						MX53_PAD_DISP0_DAT7__IPU_DISP0_DAT_7 0x5
> +						MX53_PAD_DISP0_DAT8__IPU_DISP0_DAT_8 0x5
> +						MX53_PAD_DISP0_DAT9__IPU_DISP0_DAT_9 0x5
> +						MX53_PAD_DISP0_DAT10__IPU_DISP0_DAT_10 0x5
> +						MX53_PAD_DISP0_DAT11__IPU_DISP0_DAT_11 0x5
> +						MX53_PAD_DISP0_DAT12__IPU_DISP0_DAT_12 0x5
> +						MX53_PAD_DISP0_DAT13__IPU_DISP0_DAT_13 0x5
> +						MX53_PAD_DISP0_DAT14__IPU_DISP0_DAT_14 0x5
> +						MX53_PAD_DISP0_DAT15__IPU_DISP0_DAT_15 0x5
> +						MX53_PAD_DISP0_DAT16__IPU_DISP0_DAT_16 0x5
> +						MX53_PAD_DISP0_DAT17__IPU_DISP0_DAT_17 0x5
> +						MX53_PAD_DISP0_DAT18__IPU_DISP0_DAT_18 0x5
> +						MX53_PAD_DISP0_DAT19__IPU_DISP0_DAT_19 0x5
> +						MX53_PAD_DISP0_DAT20__IPU_DISP0_DAT_20 0x5
> +						MX53_PAD_DISP0_DAT21__IPU_DISP0_DAT_21 0x5
> +						MX53_PAD_DISP0_DAT22__IPU_DISP0_DAT_22 0x5
> +						MX53_PAD_DISP0_DAT23__IPU_DISP0_DAT_23 0x5
> +						>;
> +					};
> +				};
> +
>  				owire {
>  					pinctrl_owire_1: owiregrp-1 {
>  						fsl,pins = <

regards
Philipp



From michal.simek at xilinx.com  Thu Apr  4 03:41:30 2013
From: michal.simek at xilinx.com (Michal Simek)
Date: Thu, 4 Apr 2013 09:41:30 +0200
Subject: [GIT PULL] arm-soc: Xilinx zynq core - pmu enable for v3.10
Message-ID: <8fadfba0-8f3d-4008-983b-259ed9e4f302@TX2EHSMHS012.ehs.local>

Hi Arnd and Olof,

please pull this dts change to your tree.
It enables pmu support for zynq.

Not sure if core branch is the correct one but feel free to rename it.

Thanks,
Michal


The following changes since commit f6161aa153581da4a3867a2d1a7caf4be19b6ec9:

   Linux 3.9-rc2 (2013-03-10 16:54:19 -0700)

are available in the git repository at:

   git://git.xilinx.com/linux-xlnx.git zynq/core

for you to fetch changes up to 268a820049531b130284943aeeb6ea38fd38e64c:

   arm: zynq: Add support for pmu (2013-04-04 09:23:44 +0200)

----------------------------------------------------------------
Michal Simek (1):
       arm: zynq: Add support for pmu

  arch/arm/boot/dts/zynq-7000.dtsi |    7 +++++++
  1 file changed, 7 insertions(+)




From horms+renesas at verge.net.au  Thu Apr  4 03:44:28 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Apr 2013 16:44:28 +0900
Subject: [RFC/PATCH 8/7] ARCH: shmobile: defconfig consolidation
In-Reply-To: <365046193-19369-1-git-send-email-horms+renesas@verge.net.au>
References: <365046193-19369-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1365061468-24235-1-git-send-email-horms+renesas@verge.net.au>

Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/configs/shmobile_defconfig |    2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/configs/shmobile_defconfig b/arch/arm/configs/shmobile_defconfig
index 9b6219a..7dba53f 100644
--- a/arch/arm/configs/shmobile_defconfig
+++ b/arch/arm/configs/shmobile_defconfig
@@ -14,9 +14,11 @@ CONFIG_SLAB=y
 CONFIG_ARCH_SHMOBILE=y
 CONFIG_ARCH_SH7372=y
 CONFIG_ARCH_R8A7740=y
+CONFIG_ARCH_R8A7790=y
 CONFIG_ARCH_EMEV2=y
 CONFIG_MACH_MACKEREL=y
 CONFIG_MACH_ARMADILLO800EVA=y
+CONFIG_MACH_LAGER=y
 CONFIG_MACH_KZM9D=y
 # CONFIG_SH_TIMER_TMU is not set
 # CONFIG_SWP_EMULATE is not set
-- 
1.7.10.4



From horms+renesas at verge.net.au  Thu Apr  4 03:46:44 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Apr 2013 16:46:44 +0900
Subject: [RFC/PATCH 8/7] ARCH: shmobile: defconfig consolidation (repost)
In-Reply-To: <1365046193-19369-1-git-send-email-horms+renesas@verge.net.au>
References: <1365046193-19369-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1365061604-24808-1-git-send-email-horms+renesas@verge.net.au>

Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/configs/shmobile_defconfig |    2 ++
 1 file changed, 2 insertions(+)

Reposted with correct In-Reply-To header (hopefully!)

diff --git a/arch/arm/configs/shmobile_defconfig b/arch/arm/configs/shmobile_defconfig
index 9b6219a..7dba53f 100644
--- a/arch/arm/configs/shmobile_defconfig
+++ b/arch/arm/configs/shmobile_defconfig
@@ -14,9 +14,11 @@ CONFIG_SLAB=y
 CONFIG_ARCH_SHMOBILE=y
 CONFIG_ARCH_SH7372=y
 CONFIG_ARCH_R8A7740=y
+CONFIG_ARCH_R8A7790=y
 CONFIG_ARCH_EMEV2=y
 CONFIG_MACH_MACKEREL=y
 CONFIG_MACH_ARMADILLO800EVA=y
+CONFIG_MACH_LAGER=y
 CONFIG_MACH_KZM9D=y
 # CONFIG_SH_TIMER_TMU is not set
 # CONFIG_SWP_EMULATE is not set
-- 
1.7.10.4



From michal.simek at xilinx.com  Thu Apr  4 03:47:09 2013
From: michal.simek at xilinx.com (Michal Simek)
Date: Thu, 4 Apr 2013 09:47:09 +0200
Subject: [GIT PULL] arm-soc: Xilinx zynq core - smp for v3.10
Message-ID: <890ef3b8-f536-4b00-9bd8-5ea50de3bf51@DB8EHSMHS032.ehs.local>

Hi Arnd and Olof,

please pull the following smp support to your arm-soc tree.

This branch is based on zynq/clksrc/cleanup parts because
there are some dependencies on moving timer to generic location.

I could based it on standard Linux tagged version but you will get
several conflicts you will have to resolve.
If you are OK to resolving these problems, please let me know
I will create another branch with core-smp changes which are not based
on zynq/clksrc/cleanup branch.

Thanks,
Michal


The following changes since commit 4f0f234fce1d263cc9881456352e8fd56ead0514:

   arm: zynq: Move timer to generic location (2013-04-04 09:22:09 +0200)

are available in the git repository at:

   git://git.xilinx.com/linux-xlnx.git zynq/core-smp

for you to fetch changes up to c7c28b0fdd06d8eb9414d21f8956b7c773ceea93:

   arm: zynq: Add hotplug support (2013-04-04 09:24:00 +0200)

----------------------------------------------------------------
Michal Simek (7):
       arm: zynq: Load scu baseaddress at run time
       arm: zynq: Move slcr initialization to separate file
       arm: zynq: Add support for system reset
       arm: zynq: Get rid of xilinx function prefix
       arm: zynq: Add smp_twd timer
       arm: zynq: Add smp support
       arm: zynq: Add hotplug support

  arch/arm/boot/dts/zynq-7000.dtsi |    7 ++
  arch/arm/mach-zynq/Kconfig       |    1 +
  arch/arm/mach-zynq/Makefile      |    6 +-
  arch/arm/mach-zynq/common.c      |   67 +++++++++--------
  arch/arm/mach-zynq/common.h      |   20 +++++
  arch/arm/mach-zynq/headsmp.S     |   24 ++++++
  arch/arm/mach-zynq/hotplug.c     |  104 ++++++++++++++++++++++++++
  arch/arm/mach-zynq/platsmp.c     |  152 ++++++++++++++++++++++++++++++++++++++
  arch/arm/mach-zynq/slcr.c        |  125 +++++++++++++++++++++++++++++++
  9 files changed, 476 insertions(+), 30 deletions(-)
  create mode 100644 arch/arm/mach-zynq/headsmp.S
  create mode 100644 arch/arm/mach-zynq/hotplug.c
  create mode 100644 arch/arm/mach-zynq/platsmp.c
  create mode 100644 arch/arm/mach-zynq/slcr.c




From p.zabel at pengutronix.de  Thu Apr  4 03:58:49 2013
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Thu, 04 Apr 2013 09:58:49 +0200
Subject: [PATCH 1/3] ARM: dts: imx28-evk: Use the standard gpio reset
 binding
In-Reply-To: <1365026474-3446-1-git-send-email-festevam@gmail.com>
References: <1365026474-3446-1-git-send-email-festevam@gmail.com>
Message-ID: <1365062329.4089.12.camel@pizza.hi.pengutronix.de>

Hi Fabio,

Am Mittwoch, den 03.04.2013, 19:01 -0300 schrieb Fabio Estevam:
> From: Fabio Estevam <fabio.estevam at freescale.com>
> 
> Instead of using a custom binding for turning on a GPIO that activates the 
> panel, use the standard one.

While this might fit well code wise, is a reset GPIO the right
abstraction for those panel enable GPIOs?

I guess the distinction between a GPIO that only holds the panel
controller in reset and one that also enables power supplies internally
can't be always made easily.

regards
Philipp

> Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
> ---
>  Documentation/devicetree/bindings/fb/mxsfb.txt |    5 +----
>  arch/arm/boot/dts/imx23-evk.dts                |    8 +++++++-
>  arch/arm/boot/dts/imx28-evk.dts                |    8 +++++++-
>  3 files changed, 15 insertions(+), 6 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/fb/mxsfb.txt b/Documentation/devicetree/bindings/fb/mxsfb.txt
> index 7ba3b76..b15230c 100644
> --- a/Documentation/devicetree/bindings/fb/mxsfb.txt
> +++ b/Documentation/devicetree/bindings/fb/mxsfb.txt
> @@ -8,9 +8,7 @@ Required properties:
>  - display : phandle to display node (see below for details)
>  
>  Optional properties:
> -- panel-enable-gpios : Should specify the gpio for panel enable
> -
> -* display node
> +- display node
>  
>  Required properties:
>  - bits-per-pixel : <16> for RGB565, <32> for RGB888/666.
> @@ -25,7 +23,6 @@ lcdif at 80030000 {
>  	compatible = "fsl,imx28-lcdif";
>  	reg = <0x80030000 2000>;
>  	interrupts = <38 86>;
> -	panel-enable-gpios = <&gpio3 30 0>;
>  
>  	display: display {
>  		bits-per-pixel = <32>;
> diff --git a/arch/arm/boot/dts/imx23-evk.dts b/arch/arm/boot/dts/imx23-evk.dts
> index 7880e17..28f9766 100644
> --- a/arch/arm/boot/dts/imx23-evk.dts
> +++ b/arch/arm/boot/dts/imx23-evk.dts
> @@ -59,7 +59,7 @@
>  			lcdif at 80030000 {
>  				pinctrl-names = "default";
>  				pinctrl-0 = <&lcdif_24bit_pins_a>;
> -				panel-enable-gpios = <&gpio1 18 0>;
> +				resets = <&gpio_reset 0>;
>  				display = <&display>;
>  				status = "okay";
>  
> @@ -89,6 +89,12 @@
>  			};
>  		};
>  
> +		gpio_reset: gpio-reset {
> +			compatible = "gpio-reset";
> +			reset-gpios = <&gpio1 18 1>;
> +			#reset-cells = <1>;
> +		};
> +
>  		apbx at 80040000 {
>  			pwm: pwm at 80064000 {
>  				pinctrl-names = "default";
> diff --git a/arch/arm/boot/dts/imx28-evk.dts b/arch/arm/boot/dts/imx28-evk.dts
> index 2d4ea3b..e373dd6 100644
> --- a/arch/arm/boot/dts/imx28-evk.dts
> +++ b/arch/arm/boot/dts/imx28-evk.dts
> @@ -123,7 +123,7 @@
>  				pinctrl-names = "default";
>  				pinctrl-0 = <&lcdif_24bit_pins_a
>  					     &lcdif_pins_evk>;
> -				panel-enable-gpios = <&gpio3 30 0>;
> +				resets = <&gpio_reset 0>;
>  				display = <&display>;
>  				status = "okay";
>  
> @@ -152,6 +152,12 @@
>  				};
>  			};
>  
> +			gpio_reset: gpio-reset {
> +				compatible = "gpio-reset";
> +				reset-gpios = <&gpio3 30 1>;
> +				#reset-cells = <1>;
> +			};
> +
>  			can0: can at 80032000 {
>  				pinctrl-names = "default";
>  				pinctrl-0 = <&can0_pins_a>;




From simon.guinot at sequanux.org  Thu Apr  4 04:00:58 2013
From: simon.guinot at sequanux.org (Simon Guinot)
Date: Thu, 4 Apr 2013 10:00:58 +0200
Subject: [PATCH] ARM: kirkwood: DT board setup for CloudBox
In-Reply-To: <515D0776.7050208@free.fr>
References: <1364555206-5870-1-git-send-email-simon.guinot@sequanux.org>
 <20130329153132.GJ13280@titan.lakedaemon.net>
 <20130329184109.GA16404@kw.sim.vm.gnt> <51568B89.1060009@free.fr>
 <20130401163316.GC16404@kw.sim.vm.gnt> <515A5BC6.5000007@free.fr>
 <20130402114535.GR13280@titan.lakedaemon.net>
 <20130402125408.GH16404@kw.sim.vm.gnt>
 <20130402172454.GT13280@titan.lakedaemon.net>
 <515D0776.7050208@free.fr>
Message-ID: <20130404080058.GJ16404@kw.sim.vm.gnt>

On Thu, Apr 04, 2013 at 06:54:14AM +0200, Chris Moore wrote:
> Hi,
> 
> Le 02/04/2013 19:24, Jason Cooper a ?crit :
> >On Tue, Apr 02, 2013 at 02:54:11PM +0200, Simon Guinot wrote:
> >
> ...
> 
> >>There is two different LaCie boards. There is no relations between this
> >>boards except their final product name (which is quite silly).
> >>
> >> From a LaCie point, there is no board but only product naming. Here are
> >>the different names used by LaCie for this two boards/products:
> >>
> >>1: netspace_mini_v2 ->  SafeBox ->  CloudBox
> >>2: FamilyBox ->  CloudBox
> >>
> >>"1" is the oldest board.
> >Got it.
> 
> I may be thick but I didn't realise that my old black CloudBox was
> already supported under the name netspace_mini_v2 :(
> There is no reference to CloudBox anywhere in the kernel; only the
> SafeBox alias (of which I was also unaware) is given in Kconfig.

Yes we will fix that.

> 
> >>Under Linux, with my patch we are using the following names:
> >>
> >>1: netspace_mini_v2
> >>2: cloudbox
> >>
> >>The problem raised by Chris is that the cloudbox name could be
> >>confusing because one could try a "cloudbox" dtb on the board "1". For
> >>my part I don't think it is an issue because "1" is rather confidential
> >>(and it is an euphemism).
> >Agreed.
> 
> I wasn't aware that the original CloudBox was so confidential.
> I even saw them for sale in my local FNAC (a hi-tech and media shop
> present in most large French shopping centres).

Yes they were available but only few of them have been sold. From a
LaCie point this product simply doesn't have existed. That's why the
name have been reused.

> 
> >>It would be more confusing for users if the kernel name for "2" is not
> >>cloudbox but cloudbox_{color,number,...} or even familybox. Moreover
> >>netspace_mini_v2 is a correct name for "1".
> >>
> >>IMHO, we could let things as they are. Additionally, I could either
> >>extend the Kconfig description and add a some comments in the dts files,
> >>in order to to prevent any misunderstanding...
> >>
> >>Let me know if you agree or not.
> >Yes, that makes more sense.  Thanks for clearing it up.  Please add the
> >clarifying remarks to the dts.
> 
> I agree that it would be confusing to change the netspace_mini_v2 name now.
> 
> In view of all the above, please disregard my objection.
> Sorry for the noise :(

No problems, this needs to be clarified.

> 
> >As for the model number for the public board (#2), why can't we append
> >"-90003xx"?  See [1], Specifications tab.
> >
> >[1] http://www.lacie.com/us/products/product.htm?id=10597
> 
> This seems like a good idea to me but I don't think Simon favoured
> adding a model number.
> In any case Simon would know better than me whether this covers the
> models correctly.
> What do you think, Simon?

I am currently working on this numbers. It _could_ work. Apparently the
product ID is encoded in the numbers... as well as the case color and
size. Today I should meet someone with more informations about the model
number format.

Regards,

Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130404/7cc2ab26/attachment.sig>

From nicolas.ferre at atmel.com  Thu Apr  4 04:11:46 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Thu, 4 Apr 2013 10:11:46 +0200
Subject: [PATCH] rtc: rtc-at91sam9.c add DT support
In-Reply-To: <515CF985.6050009@interlog.com>
References: <515CF985.6050009@interlog.com>
Message-ID: <515D35C2.7050405@atmel.com>

On 04/04/2013 05:54 AM, Douglas Gilbert :
> Some members of the at91 SoCs use the Real Time Timer (RTT)
> and the General Purpose Backup Registers (GPBR) to implement
> a real time clock (RTC). The AT91SAM9G20 is one example.
> 
> Attached is a patch to add DT support to rtc-at91sam9.c .
> The patch is against lk 3.9.0-rc5 .
> 
> Below is a snippet of DT code for the 'G20 that was observed
> to work with this patch:
> 
> ahb {
>     apb {
> 
>         rtc {
>             compatible = "atmel,at91sam9-rtc";

The compatible string has to be formed by the name of the first SoC
compatible with this IP. It turns to be the at91sam9260.
The second part of the string should be a name that reflects the nature
of the peripheral. For this binding, I would like to mention the "RTT"
in the compatibility string (because other drivers can use other RTT
with other uses).

What do you think about:
"atmel,at91sam9260-rtt-as-rtc"? or something shorter?

>                          /* RTTC followed by GPBR (backup registers) */
>                          reg = <0xfffffd20 0x10>, <0xfffffd50 0x10>;
>                          interrupts = <1 4 7>;
>                          status = "okay";

Last, but not least, when we add a DT binding, it is a requirement to
add the corresponding documentation in the
Documentation/devicetree/bindings/rtc/ directory.

>         };
>     }
> };
> 
> Signed-off-by: Douglas Gilbert <dgilbert at interlog.com>

Thanks, best regards,
-- 
Nicolas Ferre


From jhovold at gmail.com  Thu Apr  4 04:16:34 2013
From: jhovold at gmail.com (Johan Hovold)
Date: Thu, 4 Apr 2013 10:16:34 +0200
Subject: [PATCH] rtc: rtc-at91sam9.c add DT support
In-Reply-To: <515CF985.6050009@interlog.com>
References: <515CF985.6050009@interlog.com>
Message-ID: <20130404081634.GD27151@localhost>

On Wed, Apr 03, 2013 at 11:54:45PM -0400, Douglas Gilbert wrote:
> diff --git a/drivers/rtc/rtc-at91sam9.c b/drivers/rtc/rtc-at91sam9.c
> index 39cfd2e..69e9389 100644
> --- a/drivers/rtc/rtc-at91sam9.c
> +++ b/drivers/rtc/rtc-at91sam9.c
> @@ -20,6 +20,8 @@
>  #include <linux/ioctl.h>
>  #include <linux/slab.h>
>  #include <linux/platform_data/atmel.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>
>  
>  #include <mach/at91_rtt.h>
>  #include <mach/cpu.h>
> @@ -71,6 +73,17 @@ struct sam9_rtc {
>  #define gpbr_writel(rtc, val) \
>  	__raw_writel((val), (rtc)->gpbr)
>  
> +#ifdef CONFIG_OF
> +static const struct of_device_id at91sam9_rtc_dt_ids[] = {
> +        { .compatible = "atmel,at91sam9-rtc" },

This should probably be "atmel,at91sam9260-rtt".

> +        { /* sentinel */ }
> +};
> +MODULE_DEVICE_TABLE(of, at91sam9_rtc_dt_ids);
> +#else
> +#define at91sam9_rtc_dt_ids NULL
> +#endif  /* CONFIG_OF */

You don't need the else-clause when you use of_match_ptr below.

> +
> +
>  /*
>   * Read current time and date in RTC
>   */
> @@ -470,6 +483,7 @@ static struct platform_driver at91_rtc_driver = {
>  	.driver		= {
>  		.name	= "rtc-at91sam9",
>  		.owner	= THIS_MODULE,
> +		.of_match_table = of_match_ptr(at91sam9_rtc_dt_ids),
>  	},
>  };

Thanks,
Johan


From pdeschrijver at nvidia.com  Thu Apr  4 04:20:44 2013
From: pdeschrijver at nvidia.com (Peter De Schrijver)
Date: Thu, 4 Apr 2013 11:20:44 +0300
Subject: [PATCH v9 00/14] Tegra114 clockframework
In-Reply-To: <515CB9D9.90303@wwwdotorg.org>
References: <1365000110-8916-1-git-send-email-pdeschrijver@nvidia.com>
 <515C6C6E.6060302@wwwdotorg.org> <515C7495.8060106@wwwdotorg.org>
 <515CB9D9.90303@wwwdotorg.org>
Message-ID: <20130404082043.GY18519@tbergstrom-lnx.Nvidia.com>

On Thu, Apr 04, 2013 at 01:23:05AM +0200, Stephen Warren wrote:
> On 04/03/2013 12:27 PM, Stephen Warren wrote:
> > On 04/03/2013 11:52 AM, Stephen Warren wrote:
> >> On 04/03/2013 08:40 AM, Peter De Schrijver wrote:
> >>> This is the nineth version of the Tegra114 clockframework. It is based on the
> >>> next-20130320-fixed branch of
> >>> git://nv-tegra.nvidia.com/user/swarren/linux-2.6.git,
> > ... [it depends on]
> >>> http://patchwork.ozlabs.org/patch/233415/
> >>
> >> That is Joseph's "clocksource: tegra: enable arch_timer". Is this
> >> actually a dependency, or an optimization, or ...?
> >>
> >> Rob Herring objected to that patch since it isn't necessary if his
> >> series "ARM arch, sp804 and integrator timer CLKSRC_OF support" is applied.
> >>
> >> If I apply just your (Peter's) CCF series without Joseph's or Rob's
> >> patches, will everything still work, or is this a hard dependency to
> >> create a working system?
> > 
> > I manage to get this series applied on top of my local dev branch, based
> > on next-20130328 (it was painful). Testing indicates that there is no
> > dependency on Joseph's patch mentioned above; I could boot, log in, and
> > play audio (with local patches) with /or/ without Joseph's patch applied.
> > 
> > However, I still find that I need to revert f7db706 ARM: "7674/1: smp:
> > Avoid dummy clockevent being preferred over real hardware clock-event",
> > or I get a hard system hang right after the root fs is mounted. As such,
> > I not sure if it's worthwhile applying this series since it's unlikely
> > to actually work once merged into Torvalds' tree.
> > 
> > Do you have any idea what the problem is here?
> > 
> > I'll try rebasing my local test branch on top of the latest linux-next
> > just in case some other fix solved this already, but I'm not going to
> > hold my breath.
> 
> I've found the problem. My bootloader wasn't initializing the TSC and
> hence I guess it wasn't working properly, even with Joseph's patch to
> add a call to the initialization function.
> 

Ok.

> So, if I:
> 
> a) Fix my bootloader to enable TSC.
> 
> b) Merge Rob's patch series to enable the TSC. This is needed rather
> than Joseph's patch since the two conflict, and I assume that Rob's
> patch is going into 3.10.
> 
> c) Undo my local revert of "ARM: 7674/1: smp: Avoid dummy clockevent
> being preferred over real hardware clock-event".
> 

Ok. Good. That's close to what I have and works here. As well.

> ... then everything now works.
> 
> So the only remaining issues are:
> 
> 1) Should the mux clocks still be defined in the binding document?
> Prashant didn't seem to think so.
> 

I guess we should remove them then.

> 2) I need Mike's ack to apply this series to the Tegra tree.

Ok. Mike?

Cheers,

Peter.


From vaibhav.bedia at ti.com  Thu Apr  4 04:47:26 2013
From: vaibhav.bedia at ti.com (Bedia, Vaibhav)
Date: Thu, 4 Apr 2013 08:47:26 +0000
Subject: [RFC v2 16/18] ARM: OMAP2+: AM33XX: Basic suspend resume support
In-Reply-To: <CACTFLAM=69kZOGoJU8_tBfrJKmDTivpF8ZC8R95anHHA37f7_A@mail.gmail.com>
References: <1356959231-17335-1-git-send-email-vaibhav.bedia@ti.com>
 <1356959231-17335-17-git-send-email-vaibhav.bedia@ti.com>
 <CACTFLAM=69kZOGoJU8_tBfrJKmDTivpF8ZC8R95anHHA37f7_A@mail.gmail.com>
Message-ID: <B5906170F1614E41A8A28DE3B8D121433ED8AFAA@DBDE01.ent.ti.com>

Hi Daniel,

On Wed, Apr 03, 2013 at 17:22:41, Daniel Mack wrote:
> Hi Vaibhav,
> 
> On Mon, Dec 31, 2012 at 2:07 PM, Vaibhav Bedia <vaibhav.bedia at ti.com> wrote:
> > AM335x supports various low power modes as documented
> > in section 8.1.4.3 of the AM335x TRM which is available
> > @ http://www.ti.com/litv/pdf/spruh73f
> 
> May I ask about the plans for this series? Will you be re-spinning
> them for a current
> tree, and what's the planned merge window for it?
> 

I am tied up in some other stuff right now. I plan to address Kevin's comments
and repost the patches soon. Since rc5 is already out i think v3.10 is not
a realistic target any more but I do hope to have this accepted for v3.11.

Regards,
Vaibhav


From kishon at ti.com  Thu Apr  4 04:56:48 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Thu, 4 Apr 2013 14:26:48 +0530
Subject: [PATCH v5 1/6] drivers: phy: add generic PHY framework
In-Reply-To: <20130403154704.GD19093@arwen.pp.htv.fi>
References: <1364993634-6378-1-git-send-email-kishon@ti.com>
 <1364993634-6378-2-git-send-email-kishon@ti.com>
 <20130403134102.GC14680@arwen.pp.htv.fi> <515C3A42.4020404@ti.com>
 <20130403142747.GK14680@arwen.pp.htv.fi> <515C3D94.1060000@ti.com>
 <20130403154704.GD19093@arwen.pp.htv.fi>
Message-ID: <515D4050.7090506@ti.com>

Hi,

On Wednesday 03 April 2013 09:17 PM, Felipe Balbi wrote:
> Hi,
>
> On Wed, Apr 03, 2013 at 08:02:52PM +0530, Kishon Vijay Abraham I wrote:
>>>>>> +		ret = -EINVAL;
>>>>>> +		goto err0;
>>>>>> +	}
>>>>>> +
>>>>>> +	if (!phy_class)
>>>>>> +		phy_core_init();
>>>>>
>>>>> why don't you setup the class on module_init ? Then this would be a
>>>>> terrible error condition here :-)
>>>>
>>>> This is for the case where the PHY driver gets loaded before the PHY
>>>> framework. I could have returned EPROBE_DEFER here instead I thought
>>>> will have it this way.
>>>
>>> looks a bit weird IMO. Is it really possible for PHY to load before ?
>>
>> yeah. it actually happened when I tried with beagle and had all the
>> modules as built-in. Because twl4030 has subsys_initcall(), it loads
>> before PHY framework.
>
> that's a bug in twl4030.

right. Will fix it.

Thanks
Kishon


From dt.tangr at gmail.com  Thu Apr  4 05:01:50 2013
From: dt.tangr at gmail.com (Daniel Tang)
Date: Thu, 4 Apr 2013 20:01:50 +1100
Subject: [RFC PATCH arm: initial TI-Nspire support]
Message-ID: <6FE4B33E-A503-4A75-AEED-831CB2C06D83@gmail.com>

We're sending out for comments an early patch adding TI-Nspire support
to Linux.

Some words on the Nspire platform: it's a series of graphing
calculators, made of four models: "Clickpad" (2007-2010), "Touchpad"
(2010-2012?), "CX" (2011-), "CM-C" (2011-).

The main hardware characteristics are significantly outdated - and
yet, Nspires are the most powerful graphing calculators on the
market:
    * ARM926EJ-S based ASICs by LSI Logic, up to 200+ MHz;
    * 32 MB of SDRAM for Clickpad/Touchpad/CM-C, 64 MB of SDRAM for CX;
    * 512 KB of external NOR Flash for first-stage bootloader ("boot1")
      on the oldest models, internal since then;
    * NAND Flash for manufacturer data + boot2 (second-stage
      platform-specific bootloader) + "diags" (diagnostics software)
      + filesystem (containing OS): 32 MB for Clickpad / Touchpad,
      128 MB for CX. Multiple chip models are used.
    * 320x240 grayscale non-backlit DSTN screen for Clickpad / Touchpad
      (usually used in 4 bpp mode), 320x240 16 bpp backlit color screen
      for CX / CM-C;
    * USB OTG capable controller, for calc-to-calc transfers;
    * RS232 TTL and GPIO on proprietary-pitch "dock" connector.


From a software point of view, the Nspire is usually running a
proprietary Nucleus-based OS, which uses the proprietary Datalight
Reliance filesystem, layered on top of proprietary FlashFX.
TI uses RSA signature validation for boot2, diags and OS upgrades;
boot2 and diags are compressed, OS upgrades are encrypted (Blowfish).
On the CX, some chunks of the boot2 are encrypted with 3-DES.
The officially sanctioned programming abilities are pretty limited:
    * a BASIC which cannot draw pixels to the screen or read arbitrary
      keys from the keyboard (yes, we're talking about a calculator
      used for teaching purposes !!);
    * a proprietary Lua with significant two-way incompatibilities with
      standard Lua: no io.*, so no file I/O, and no os.*; but a
      proprietary framework for event-driven programming.

Native code is accessible on select OS versions (Ndless) or boot2
versions (nLaunch & nLaunch CX) through arbitrary native code execution
exploits.
TI actively fights attempts to use native code on the Nspire series.


Patch contents
--------------
This patch (against mainline, but it also applies to linux-next)
contains the essential support code required to boot Linux to a shell 
on all models, but contains nothing else at the moment.
Code containing drivers for other peripherals exists, and will
eventually be posted for review as well: we need to do a bit of
cleanup. If you prefer them to be posted here now, we'll do.
They're at https://github.com/tangrs/linux .

A possibly noteworthy fact is that despite the gradual shift to
using Device Tree definitions for ARM machine types, we've decided not
to use it, for the following reasons:

    * the (perceived) extra complexity and code size;
    * the fact that we're using our own, simple, bootloader, due to
      the impossibility to bootstrap on most models (because boot1
      is usually not modifiable) and the fact that the image is stored
      in a proprietary FS not supported by mainline Linux and
      common bootloaders...


TODO
----
    * Address review comments, of course ;-)
    * Expand and clean up the drivers that have been written so far
      (for instance, GPIO) and submit them for review.
    * Continue to reverse engineer and write drivers to support the
      remaining hardware. We still need to work on power management and
      the NAND Flash. The platform also has a SPI somewhere, probably
      another USB port, and more anecdotal, 3-DES and SHA-256 hardware
      acceleration.


Thanks in advance for reviews ;)

Signed-off-by: Daniel Tang <dt.tangr at gmail.com>
Signed-off-by: Fabian Vogt <fabian at ritter-vogt.de>
Signed-off-by: Lionel Debroux <lionel_debroux at yahoo.fr>
---
 arch/arm/Kconfig                                 |   17 +
 arch/arm/Makefile                                |    1 +
 arch/arm/mach-nspire/Kconfig                     |   36 +++
 arch/arm/mach-nspire/Makefile                    |   16 +
 arch/arm/mach-nspire/Makefile.boot               |    1 +
 arch/arm/mach-nspire/classic.c                   |  363 ++++++++++++++++++++++
 arch/arm/mach-nspire/classic.h                   |   23 ++
 arch/arm/mach-nspire/clock.c                     |   39 +++
 arch/arm/mach-nspire/clock.h                     |   10 +
 arch/arm/mach-nspire/common.c                    |  311 ++++++++++++++++++
 arch/arm/mach-nspire/common.h                    |   52 ++++
 arch/arm/mach-nspire/include/mach/clkdev.h       |   24 ++
 arch/arm/mach-nspire/include/mach/debug-macro.S  |   28 ++
 arch/arm/mach-nspire/include/mach/hardware.h     |   15 +
 arch/arm/mach-nspire/include/mach/irqs.h         |   34 ++
 arch/arm/mach-nspire/include/mach/keypad.h       |   31 ++
 arch/arm/mach-nspire/include/mach/memory.h       |   17 +
 arch/arm/mach-nspire/include/mach/nspire_clock.h |   52 ++++
 arch/arm/mach-nspire/include/mach/nspire_mmio.h  |   67 ++++
 arch/arm/mach-nspire/include/mach/sram.h         |   26 ++
 arch/arm/mach-nspire/include/mach/timex.h        |   15 +
 arch/arm/mach-nspire/include/mach/uncompress.h   |   42 +++
 arch/arm/mach-nspire/keypad.c                    |  100 ++++++
 arch/arm/mach-nspire/nspire_clp.c                |   57 ++++
 arch/arm/mach-nspire/nspire_cx.c                 |  316 +++++++++++++++++++
 arch/arm/mach-nspire/nspire_tp.c                 |   80 +++++
 arch/arm/mach-nspire/sram.c                      |   66 ++++
 arch/arm/mach-nspire/touchpad.c                  |   30 ++
 arch/arm/mach-nspire/touchpad.h                  |   17 +
 arch/arm/tools/mach-types                        |    3 +
 30 files changed, 1889 insertions(+)
 create mode 100644 arch/arm/mach-nspire/Kconfig
 create mode 100644 arch/arm/mach-nspire/Makefile
 create mode 100644 arch/arm/mach-nspire/Makefile.boot
 create mode 100644 arch/arm/mach-nspire/classic.c
 create mode 100644 arch/arm/mach-nspire/classic.h
 create mode 100644 arch/arm/mach-nspire/clock.c
 create mode 100644 arch/arm/mach-nspire/clock.h
 create mode 100644 arch/arm/mach-nspire/common.c
 create mode 100644 arch/arm/mach-nspire/common.h
 create mode 100644 arch/arm/mach-nspire/include/mach/clkdev.h
 create mode 100644 arch/arm/mach-nspire/include/mach/debug-macro.S
 create mode 100644 arch/arm/mach-nspire/include/mach/hardware.h
 create mode 100644 arch/arm/mach-nspire/include/mach/irqs.h
 create mode 100644 arch/arm/mach-nspire/include/mach/keypad.h
 create mode 100644 arch/arm/mach-nspire/include/mach/memory.h
 create mode 100644 arch/arm/mach-nspire/include/mach/nspire_clock.h
 create mode 100644 arch/arm/mach-nspire/include/mach/nspire_mmio.h
 create mode 100644 arch/arm/mach-nspire/include/mach/sram.h
 create mode 100644 arch/arm/mach-nspire/include/mach/timex.h
 create mode 100644 arch/arm/mach-nspire/include/mach/uncompress.h
 create mode 100644 arch/arm/mach-nspire/keypad.c
 create mode 100644 arch/arm/mach-nspire/nspire_clp.c
 create mode 100644 arch/arm/mach-nspire/nspire_cx.c
 create mode 100644 arch/arm/mach-nspire/nspire_tp.c
 create mode 100644 arch/arm/mach-nspire/sram.c
 create mode 100644 arch/arm/mach-nspire/touchpad.c
 create mode 100644 arch/arm/mach-nspire/touchpad.h

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 13b7394..4aa5029 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -492,6 +492,21 @@ config ARCH_NETX
 	help
 	  This enables support for systems based on the Hilscher NetX Soc

+config ARCH_NSPIRE
+	bool "TI-NSPIRE based"
+	depends on MMU
+	select CPU_ARM926T
+	select HAVE_MACH_CLKDEV
+	select CLKDEV_LOOKUP
+	select ARM_AMBA
+	select USB_ARCH_HAS_EHCI
+	select ARCH_WANT_OPTIONAL_GPIOLIB
+	select GENERIC_ALLOCATOR
+	select ARCH_HAS_CPUFREQ
+	select CPU_FREQ_TABLE
+	help
+	  This enables support for systems using the TI-NSPIRE CPU
+
 config ARCH_H720X
 	bool "Hynix HMS720x-based"
 	select ARCH_USES_GETTIMEOFFSET
@@ -1081,6 +1096,8 @@ source "arch/arm/mach-netx/Kconfig"

 source "arch/arm/mach-nomadik/Kconfig"

+source "arch/arm/mach-nspire/Kconfig"
+
 source "arch/arm/plat-omap/Kconfig"

 source "arch/arm/mach-omap1/Kconfig"
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index ee4605f..2580d2b 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -165,6 +165,7 @@ machine-$(CONFIG_ARCH_MXS)		+= mxs
 machine-$(CONFIG_ARCH_MVEBU)		+= mvebu
 machine-$(CONFIG_ARCH_NETX)		+= netx
 machine-$(CONFIG_ARCH_NOMADIK)		+= nomadik
+machine-$(CONFIG_ARCH_NSPIRE)		+= nspire
 machine-$(CONFIG_ARCH_OMAP1)		+= omap1
 machine-$(CONFIG_ARCH_OMAP2PLUS)	+= omap2
 machine-$(CONFIG_ARCH_ORION5X)		+= orion5x
diff --git a/arch/arm/mach-nspire/Kconfig b/arch/arm/mach-nspire/Kconfig
new file mode 100644
index 0000000..da032b7
--- /dev/null
+++ b/arch/arm/mach-nspire/Kconfig
@@ -0,0 +1,36 @@
+if ARCH_NSPIRE
+
+choice
+	prompt "Early printk and boot message serial interface"
+	help
+	  Early printk output interface
+	depends on EARLY_PRINTK
+	default NSPIRE_EARLYPRINTK_CX
+
+config NSPIRE_EARLYPRINTK_CLASSIC
+	bool "Classic"
+
+config NSPIRE_EARLYPRINTK_CX
+	bool "CX model"
+endchoice
+
+
+menu "Supported models"
+
+config MACH_NSPIRECX
+	select GENERIC_CLOCKEVENTS
+	select ARM_VIC
+	select ARM_TIMER_SP804
+	bool "CX/CX CAS"
+
+config MACH_NSPIRETP
+	select GENERIC_IRQ_CHIP
+	bool "Touchpad/Touchpad CAS"
+
+config MACH_NSPIRECLP
+	select GENERIC_IRQ_CHIP
+	bool "Clickpad/Clickpad CAS"
+
+endmenu
+
+endif
diff --git a/arch/arm/mach-nspire/Makefile b/arch/arm/mach-nspire/Makefile
new file mode 100644
index 0000000..f7108fe
--- /dev/null
+++ b/arch/arm/mach-nspire/Makefile
@@ -0,0 +1,16 @@
+obj-y				:=
+
+obj-y				+= common.o
+obj-y				+= clock.o
+obj-y				+= sram.o
+obj-y				+= keypad.o
+
+obj-$(CONFIG_MACH_NSPIRECX)	+= nspire_cx.o
+obj-$(CONFIG_MACH_NSPIRECX)	+= touchpad.o
+
+obj-$(CONFIG_MACH_NSPIRECLP)	+= nspire_clp.o
+obj-$(CONFIG_MACH_NSPIRECLP)	+= classic.o
+
+obj-$(CONFIG_MACH_NSPIRETP)	+= nspire_tp.o
+obj-$(CONFIG_MACH_NSPIRETP)	+= classic.o
+obj-$(CONFIG_MACH_NSPIRETP)	+= touchpad.o
diff --git a/arch/arm/mach-nspire/Makefile.boot b/arch/arm/mach-nspire/Makefile.boot
new file mode 100644
index 0000000..7db966b
--- /dev/null
+++ b/arch/arm/mach-nspire/Makefile.boot
@@ -0,0 +1 @@
+zreladdr-y	:= 0x10008000
diff --git a/arch/arm/mach-nspire/classic.c b/arch/arm/mach-nspire/classic.c
new file mode 100644
index 0000000..b1eddf3
--- /dev/null
+++ b/arch/arm/mach-nspire/classic.c
@@ -0,0 +1,363 @@
+/*
+ *	linux/arch/arm/mach-nspire/classic.c
+ *
+ *	Copyright (C) 2012 Daniel Tang <tangrs at tangrs.id.au>
+ *
+ * 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/io.h>
+#include <linux/clk.h>
+#include <linux/irq.h>
+#include <linux/irqdomain.h>
+#include <linux/clockchips.h>
+#include <linux/interrupt.h>
+#include <linux/cpumask.h>
+#include <linux/serial_8250.h>
+#include <linux/platform_device.h>
+#include <linux/amba/bus.h>
+#include <linux/amba/clcd.h>
+#include <linux/dma-mapping.h>
+
+#include <asm/mach/time.h>
+#include <asm/exception.h>
+
+#include <mach/nspire_mmio.h>
+#include <mach/nspire_clock.h>
+#include <mach/clkdev.h>
+#include <mach/keypad.h>
+#include <mach/irqs.h>
+
+#include "common.h"
+
+/* Clock */
+
+union reg_clk_speed {
+	unsigned long raw;
+	struct {
+		unsigned long __padding0:1;
+		unsigned long base_cpu_ratio:7;
+		unsigned long is_base_27mhz:1;
+		unsigned long __padding1:3;
+		unsigned long cpu_ahb_ratio:3;
+		unsigned long __padding2:1;
+		unsigned long base_val:5;
+	} val;
+};
+
+static struct nspire_clk_speeds classic_io_to_clocks(unsigned long val)
+{
+	struct nspire_clk_speeds clks;
+	union reg_clk_speed reg;
+
+	reg.raw = val;
+	reg.val.base_cpu_ratio *= 2;
+	reg.val.cpu_ahb_ratio++;
+
+	BUG_ON(reg.val.base_cpu_ratio == 0);
+
+	clks.base = reg.val.is_base_27mhz ? 27 : (300 - (6*reg.val.base_val));
+	clks.base *= 1000000; /* Convert to Hz */
+
+	clks.div.base_cpu = reg.val.base_cpu_ratio;
+	clks.div.cpu_ahb = reg.val.cpu_ahb_ratio;
+
+	return clks;
+}
+
+static unsigned long classic_clocks_to_io(struct nspire_clk_speeds *clks)
+{
+	union reg_clk_speed reg;
+
+	BUG_ON(clks->div.base_cpu < 2);
+	BUG_ON(clks->div.cpu_ahb < 1);
+
+	reg.raw = 0;
+	reg.val.base_cpu_ratio = clks->div.base_cpu / 2;
+	reg.val.cpu_ahb_ratio = clks->div.cpu_ahb - 1;
+	reg.val.is_base_27mhz = (clks->base <= 27000000);
+	reg.val.base_val = (300 - (clks->base / 1000000)) / 6;
+
+	return reg.raw;
+}
+
+/* Interrupt handling */
+
+static inline int check_interrupt(void __iomem *base, struct pt_regs *regs)
+{
+	if (readl(base + 0x0)) {
+		int irqnr = readl(base + 0x24);
+		unsigned prev_priority;
+		handle_IRQ(irqnr, regs);
+
+		/* Reset priorities */
+		prev_priority = readl(IOMEM(NSPIRE_INTERRUPT_VIRT_BASE + 0x28));
+		writel(prev_priority, IOMEM(NSPIRE_INTERRUPT_VIRT_BASE + 0x2c));
+		return 1;
+	}
+	return 0;
+}
+
+asmlinkage void __exception_irq_entry
+	nspire_classic_handle_irq(struct pt_regs *regs)
+{
+	int serviced;
+
+	do {
+		void __iomem *reg_base = IOMEM(NSPIRE_INTERRUPT_VIRT_BASE);
+		serviced = 0;
+
+		/* IRQ */
+		serviced += check_interrupt(reg_base, regs);
+		/* FIQ */
+		serviced += check_interrupt(reg_base + 0x100, regs);
+	} while (serviced > 0);
+}
+
+static void classic_irq_ack(struct irq_data *d)
+{
+	readl(IOMEM(NSPIRE_INTERRUPT_VIRT_BASE + 0x28));
+}
+
+static void __init classic_allocate_gc(void)
+{
+	struct irq_chip_generic *gc;
+	struct irq_chip_type *ct;
+
+	gc = irq_alloc_generic_chip("NINT", 1, 0,
+		IOMEM(NSPIRE_INTERRUPT_VIRT_BASE), handle_level_irq);
+
+	ct = gc->chip_types;
+	ct->chip.irq_ack = classic_irq_ack;
+	ct->chip.irq_mask = irq_gc_mask_disable_reg;
+	ct->chip.irq_unmask = irq_gc_unmask_enable_reg;
+
+	ct->regs.mask = 0x8;
+	ct->regs.enable = 0x8;
+	ct->regs.disable = 0xc;
+
+	irq_setup_generic_chip(gc, IRQ_MSK(NR_IRQS), IRQ_GC_INIT_MASK_CACHE,
+		IRQ_NOREQUEST, 0);
+}
+
+void __init nspire_classic_init_irq(void)
+{
+	/* No stickies */
+	writel(0, IOMEM(NSPIRE_INTERRUPT_VIRT_BASE + 0x204));
+
+	/* Disable all interrupts */
+	writel(~0, IOMEM(NSPIRE_INTERRUPT_VIRT_BASE + 0xc));
+	writel(~0, IOMEM(NSPIRE_INTERRUPT_VIRT_BASE + 0x10c));
+
+	/* Set all priorities to 0 */
+	memset_io(IOMEM(NSPIRE_INTERRUPT_VIRT_BASE + 0x300), 0, 0x7f);
+
+	/* Accept interrupts of all priorities */
+	writel(0xf, IOMEM(NSPIRE_INTERRUPT_VIRT_BASE + 0x2c));
+	writel(0xf, IOMEM(NSPIRE_INTERRUPT_VIRT_BASE + 0x12c));
+
+	/* Clear existing interrupts */
+	readl(IOMEM(NSPIRE_INTERRUPT_VIRT_BASE + 0x28));
+	readl(IOMEM(NSPIRE_INTERRUPT_VIRT_BASE + 0x128));
+
+	/* Add chip */
+	classic_allocate_gc();
+}
+
+
+/* Timer */
+
+static int classic_timer_set_event(unsigned long delta,
+				struct clock_event_device *dev)
+{
+	unsigned long flags;
+
+	local_irq_save(flags);
+	writel(delta, NSPIRE_APB_VIRTIO(NSPIRE_APB_TIMER2));
+	writel(1, NSPIRE_APB_VIRTIO(NSPIRE_APB_TIMER2 + 0x8));
+	writel(0, NSPIRE_APB_VIRTIO(NSPIRE_APB_TIMER2 + 0x18));
+	local_irq_restore(flags);
+
+	return 0;
+}
+static void classic_timer_set_mode(enum clock_event_mode mode,
+				 struct clock_event_device *evt)
+{
+	evt->mode = mode;
+}
+
+static struct clock_event_device nspire_clkevt = {
+	.name		= "clockevent",
+	.features	= CLOCK_EVT_FEAT_ONESHOT,
+	.shift		= 32,
+	.rating		= 400,
+	.set_next_event = classic_timer_set_event,
+	.set_mode	= classic_timer_set_mode,
+	.cpumask		= cpu_all_mask,
+};
+
+static irqreturn_t classic_timer_interrupt(int irq, void *dev_id)
+{
+	struct clock_event_device *c = dev_id;
+
+	/* Acknowledge */
+	writel((1<<0), NSPIRE_APB_VIRTIO(NSPIRE_APB_MISC + 0x20));
+
+	if (c->mode != CLOCK_EVT_FEAT_PERIODIC)
+		writel((1<<4) | 1, NSPIRE_APB_VIRTIO(NSPIRE_APB_TIMER2 + 0x08));
+
+	if (c->event_handler)
+		c->event_handler(c);
+
+	return IRQ_HANDLED;
+}
+
+static struct irqaction classic_timer_irq = {
+	.name			= "timer2",
+	.flags			= IRQF_DISABLED | IRQF_TIMER | IRQF_IRQPOLL,
+	.handler		= classic_timer_interrupt,
+	.dev_id			= &nspire_clkevt,
+};
+
+
+void __init nspire_classic_timer_init(void)
+{
+	struct clk *timer_clk;
+
+	/* Count down from 1 */
+	writel(1, NSPIRE_APB_VIRTIO(NSPIRE_APB_TIMER2));
+
+	/* Divider is zero */
+	writel(0, NSPIRE_APB_VIRTIO(NSPIRE_APB_TIMER2 + 0x4));
+
+	/* Decreasing timer and interrupt */
+	writel(1, NSPIRE_APB_VIRTIO(NSPIRE_APB_TIMER2 + 0x8));
+
+	/* Interrupt on timer value reaching 0 */
+	writel(0, NSPIRE_APB_VIRTIO(NSPIRE_APB_TIMER2 + 0x18));
+
+	/* Acknowledge existing interrupts */
+	writel(~0, NSPIRE_APB_VIRTIO(NSPIRE_APB_MISC + 0x20));
+
+	/* Set interrupt masks */
+	writel((1<<0), NSPIRE_APB_VIRTIO(NSPIRE_APB_MISC + 0x24));
+
+	setup_irq(NSPIRE_IRQ_TIMER2, &classic_timer_irq);
+
+	timer_clk = clk_get(NULL, "timer2");
+	clk_enable(timer_clk);
+
+	/* Set clocksource to zero */
+	writel(0, NSPIRE_APB_VIRTIO(NSPIRE_APB_TIMER2 + 0xc));
+
+	/* Divider is zero */
+	writel(0, NSPIRE_APB_VIRTIO(NSPIRE_APB_TIMER2 + 0x10));
+
+	/* Ever increasing timer */
+	writel((1<<3) | 7, NSPIRE_APB_VIRTIO(NSPIRE_APB_TIMER2 + 0x14));
+
+	clocksource_mmio_init(NSPIRE_APB_VIRTIO(NSPIRE_APB_TIMER2 + 0xc),
+		"clocksource", clk_get_rate(timer_clk), 200, 16,
+		clocksource_mmio_readw_up);
+
+	clockevents_config_and_register(&nspire_clkevt,
+		clk_get_rate(timer_clk), 0x0001, 0xfffe);
+}
+
+
+/* Serial */
+static struct plat_serial8250_port classic_serial_platform_data[] = {
+	{
+		.mapbase	= NSPIRE_APB_PHYS(NSPIRE_APB_UART),
+		.irq		= NSPIRE_IRQ_UART,
+		.uartclk	= 29491200,
+		.iotype		= UPIO_MEM,
+		.flags		= UPF_BOOT_AUTOCONF | UPF_SKIP_TEST |
+				UPF_IOREMAP,
+		.regshift	= 2
+	},
+	{ }
+};
+
+struct platform_device nspire_classic_serial_device = {
+	.name		= "serial8250",
+	.id			= PLAT8250_DEV_PLATFORM,
+	.dev = {
+		.platform_data = &classic_serial_platform_data
+	}
+};
+
+/* Framebuffer */
+static struct clcd_panel classic_lcd_panel = {
+	.mode		= {
+		.name		= "grayscale lcd",
+		.refresh	= 60,
+		.xres		= 320,
+		.yres		= 240,
+		.sync		= FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,
+		.vmode		= FB_VMODE_NONINTERLACED,
+		.pixclock	= 1,
+		.hsync_len	= 6,
+		.vsync_len	= 1,
+		.right_margin	= 6,
+		.left_margin	= 6,
+	},
+	.width		= 71, /* 7.11cm */
+	.height		= 53, /* 5.33cm */
+	.tim2		= 0x80007d0,
+	.cntl		= CNTL_LCDBPP8 | CNTL_LCDMONO8,
+	.bpp		= 8,
+	.grayscale	= 1
+};
+#define PANEL_SIZE (19 * SZ_4K)
+
+static int classic_clcd_setup(struct clcd_fb *fb)
+{
+	return nspire_clcd_setup(fb, PANEL_SIZE, &classic_lcd_panel);
+}
+
+static struct clcd_board classic_clcd_data = {
+	.name		= "lcd controller",
+	.check		= clcdfb_check,
+	.decode		= clcdfb_decode,
+	.setup		= classic_clcd_setup,
+	.mmap		= nspire_clcd_mmap,
+	.remove		= nspire_clcd_remove,
+};
+
+AMBA_AHB_DEVICE(fb, "fb", 0, NSPIRE_LCD_PHYS_BASE,
+	{ NSPIRE_IRQ_LCD }, &classic_clcd_data);
+
+/* Init */
+void __init nspire_classic_init_early(void)
+{
+	nspire_io_to_clocks = classic_io_to_clocks;
+	nspire_clocks_to_io = classic_clocks_to_io;
+
+	nspire_init_early();
+}
+
+void __init nspire_classic_init(void)
+{
+	/*
+	 * Temporarily disable NAND writes on classics to prevent
+	 * accidental bricking.
+	 */
+	writel((1<<7), NSPIRE_APB_VIRTIO(NSPIRE_APB_POWER + 0x18));
+
+	nspire_keypad_data.active_low = 1;
+
+	amba_device_register(&fb_device, &iomem_resource);
+	platform_device_register(&nspire_keypad_device);
+	platform_device_register(&nspire_classic_serial_device);
+
+	nspire_init();
+}
+
+void __init nspire_classic_init_late(void)
+{
+	nspire_init_late();
+}
diff --git a/arch/arm/mach-nspire/classic.h b/arch/arm/mach-nspire/classic.h
new file mode 100644
index 0000000..c440ebc
--- /dev/null
+++ b/arch/arm/mach-nspire/classic.h
@@ -0,0 +1,23 @@
+/*
+ *	linux/arch/arm/mach-nspire/classic.h
+ *
+ *	Copyright (C) 2012 Daniel Tang <tangrs at tangrs.id.au>
+ *
+ * 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 <asm/exception.h>
+
+void __init nspire_classic_init_irq(void);
+void __init nspire_classic_init_early(void);
+void __init nspire_classic_init(void);
+void __init nspire_classic_init_late(void);
+asmlinkage void __exception_irq_entry
+	nspire_classic_handle_irq(struct pt_regs *regs);
+
+void __init nspire_classic_timer_init(void);
+
+extern struct irq_chip nspire_classic_irq_chip;
diff --git a/arch/arm/mach-nspire/clock.c b/arch/arm/mach-nspire/clock.c
new file mode 100644
index 0000000..c679449
--- /dev/null
+++ b/arch/arm/mach-nspire/clock.c
@@ -0,0 +1,39 @@
+/*
+ *  linux/arch/arm/mach-nspire/clock.c
+ *
+ *  Copyright (C) 2012 Daniel Tang <tangrs at tangrs.id.au>
+ *
+ * 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 <asm-generic/errno.h>
+
+#include <mach/clkdev.h>
+
+void clk_disable(struct clk *clk)
+{
+}
+
+int clk_enable(struct clk *clk)
+{
+	return 0;
+}
+
+unsigned long clk_get_rate(struct clk *clk)
+{
+	if (clk->get_rate)
+		clk->get_rate(clk);
+
+	return clk->rate;
+}
+
+int clk_set_rate(struct clk *clk, unsigned long rate)
+{
+	if (clk->set_rate)
+		return clk->set_rate(clk, rate);
+
+	return -ENOSYS;
+}
diff --git a/arch/arm/mach-nspire/clock.h b/arch/arm/mach-nspire/clock.h
new file mode 100644
index 0000000..43e99bd
--- /dev/null
+++ b/arch/arm/mach-nspire/clock.h
@@ -0,0 +1,10 @@
+/*
+ *  linux/arch/arm/mach-nspire/clock.h
+ *
+ *  Copyright (C) 2012 Daniel Tang <tangrs at tangrs.id.au>
+ *
+ * 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.
+ *
+ */
diff --git a/arch/arm/mach-nspire/common.c b/arch/arm/mach-nspire/common.c
new file mode 100644
index 0000000..a7abc68
--- /dev/null
+++ b/arch/arm/mach-nspire/common.c
@@ -0,0 +1,311 @@
+/*
+ *	linux/arch/arm/mach-nspire/common.c
+ *
+ *	Copyright (C) 2012 Daniel Tang <tangrs at tangrs.id.au>
+ *
+ * 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/init.h>
+#include <linux/clkdev.h>
+#include <linux/platform_device.h>
+#include <linux/usb/ehci_pdriver.h>
+#include <linux/usb/chipidea.h>
+#include <linux/amba/bus.h>
+#include <linux/amba/clcd.h>
+#include <linux/dma-mapping.h>
+
+#include <mach/nspire_mmio.h>
+#include <mach/nspire_clock.h>
+#include <mach/irqs.h>
+#include <mach/clkdev.h>
+#include <mach/keypad.h>
+#include <mach/sram.h>
+
+#include <asm/mach/time.h>
+#include <asm/mach-types.h>
+#include <asm/mach/map.h>
+
+#include "common.h"
+#include "clock.h"
+
+/* Clocks */
+
+struct nspire_clk_speeds (*nspire_io_to_clocks)(unsigned long);
+unsigned long (*nspire_clocks_to_io)(struct nspire_clk_speeds *);
+
+/* AHB clock */
+static void ahb_get_rate(struct clk *clk)
+{
+	struct nspire_clk_speeds speeds = nspire_get_clocks();
+	clk->rate = CLK_GET_AHB(&speeds);
+}
+
+static struct clk ahb_clk = {
+	.get_rate = ahb_get_rate,
+};
+
+/* APB clock */
+
+static void apb_get_rate(struct clk *clk)
+{
+	clk->rate = clk_get_rate(&ahb_clk) / 2;
+}
+
+static struct clk apb_clk = {
+	.get_rate = apb_get_rate
+};
+
+/* Misc */
+
+static struct clk systimer_clk = {
+	.rate	= 32768,
+};
+
+static struct clk uart_clk = {
+	.rate	= 12000000,
+};
+
+#ifdef CONFIG_MACH_NSPIRECX
+static struct clk i2c_clk = {
+	/* Doesn't matter, we set it manually */
+	.rate	= 250000,
+};
+#endif
+
+static struct clk_lookup nspire_clk_lookup[] = {
+	{
+		.dev_id = "uart",
+		.clk = &uart_clk
+	},
+	{
+		.dev_id = "fb",
+		.clk = &ahb_clk
+	},
+	{
+		.con_id = "ahb",
+		.clk = &ahb_clk
+	},
+	{
+		.dev_id = "watchdog",
+		.clk = &apb_clk
+	},
+	{
+		.dev_id = "nspire-keypad.0",
+		.clk = &apb_clk
+	},
+#ifdef CONFIG_MACH_NSPIRECX
+	{
+		.dev_id = "sp804",
+		.con_id = "timer2",
+		.clk = &systimer_clk
+	},
+	{
+		.dev_id = "i2c_designware.0",
+		.clk = &i2c_clk
+	},
+#endif
+#if defined(CONFIG_MACH_NSPIRECLP) || defined(CONFIG_MACH_NSPIRETP)
+	{
+		.dev_id = NULL,
+		.con_id = "timer2",
+		.clk = &systimer_clk
+	},
+#endif
+};
+
+/* Keypad */
+static struct resource nspire_keypad_resources[] = {
+	{
+		.start	= NSPIRE_APB_PHYS(NSPIRE_APB_KEYPAD),
+		.end	= NSPIRE_APB_PHYS(NSPIRE_APB_KEYPAD + SZ_4K - 1),
+		.flags	= IORESOURCE_MEM,
+	},
+	RESOURCE_ENTRY_IRQ(KEYPAD)
+};
+
+struct nspire_keypad_data nspire_keypad_data = {
+	.scan_interval	= 1000,
+	.row_delay	= 200
+};
+
+struct platform_device nspire_keypad_device = {
+	.name		= "nspire-keypad",
+	.id		= 0,
+	.num_resources	= ARRAY_SIZE(nspire_keypad_resources),
+	.resource	= nspire_keypad_resources,
+	.dev = {
+		.platform_data = &nspire_keypad_data
+	}
+};
+
+
+/* GPIO */
+static struct resource nspire_gpio_resources[] = {
+	{
+		.start	= NSPIRE_APB_PHYS(NSPIRE_APB_GPIO),
+		.end	= NSPIRE_APB_PHYS(NSPIRE_APB_GPIO + SZ_4K - 1),
+		.flags	= IORESOURCE_MEM,
+	},
+	RESOURCE_ENTRY_IRQ(GPIO)
+};
+
+static struct platform_device nspire_gpio_device = {
+	.name		= "gpio-nspire",
+	.resource	= nspire_gpio_resources,
+	.num_resources	= ARRAY_SIZE(nspire_gpio_resources),
+};
+
+/* ADC */
+static struct resource nspire_adc_resources[] = {
+	RESOURCE_ENTRY_MEM(ADC),
+	RESOURCE_ENTRY_IRQ(ADC)
+};
+
+static struct platform_device nspire_adc_device = {
+	.name		= "nspire-adc",
+	.resource	= nspire_adc_resources,
+	.num_resources	= ARRAY_SIZE(nspire_adc_resources)
+};
+
+/* Framebuffer */
+int nspire_clcd_setup(struct clcd_fb *fb, unsigned panel_size,
+	struct clcd_panel *panel)
+{
+	dma_addr_t dma;
+
+	fb->fb.screen_base = dma_alloc_writecombine(&fb->dev->dev,
+		panel_size, &dma, GFP_KERNEL);
+	if (!fb->fb.screen_base) {
+		pr_err("CLCD: unable to map framebuffer\n");
+		return -ENOMEM;
+	}
+
+	fb->fb.fix.smem_start = dma;
+	fb->fb.fix.smem_len = panel_size;
+	fb->panel = panel;
+
+	return 0;
+}
+
+int nspire_clcd_mmap(struct clcd_fb *fb, struct vm_area_struct *vma)
+{
+	return dma_mmap_writecombine(&fb->dev->dev, vma,
+		fb->fb.screen_base, fb->fb.fix.smem_start,
+		fb->fb.fix.smem_len);
+}
+
+void nspire_clcd_remove(struct clcd_fb *fb)
+{
+	dma_free_writecombine(&fb->dev->dev, fb->fb.fix.smem_len,
+		fb->fb.screen_base, fb->fb.fix.smem_start);
+}
+
+/* Watchdog */
+
+AMBA_APB_DEVICE(watchdog, "watchdog", 0, NSPIRE_APB_PHYS(NSPIRE_APB_WATCHDOG),
+	{ NSPIRE_IRQ_WATCHDOG }, NULL);
+
+/* Generic OTG */
+
+u64 nspire_usb_dma_mask = ~(u32)0;
+
+static struct resource otg_resources[] = {
+	RESOURCE_ENTRY_MEM(OTG),
+	RESOURCE_ENTRY_IRQ(OTG)
+};
+
+static struct ci13xxx_platform_data otg_pdata = {
+	.name = "nspire_usb",
+	.capoffset = 0x100,
+	.flags = CI13XXX_REGS_SHARED,
+};
+
+
+struct platform_device nspire_otg_device = {
+	.name		= "ci_hdrc",
+	.id		= 0,
+	.dev = {
+		.platform_data = &otg_pdata,
+		.coherent_dma_mask = ~0,
+		.dma_mask = &nspire_usb_dma_mask
+	},
+	.resource = otg_resources,
+	.num_resources = ARRAY_SIZE(otg_resources)
+};
+
+struct platform_device nspire_usb_nop_xceiver = {
+	.name		= "nop_usb_xceiv",
+};
+
+/* RTC */
+static struct resource nspire_rtc_resources[] = {
+	{
+		.start	= NSPIRE_APB_PHYS(NSPIRE_APB_RTC),
+		.end	= NSPIRE_APB_PHYS(NSPIRE_APB_RTC + SZ_4K - 1),
+		.flags	= IORESOURCE_MEM,
+	},
+	RESOURCE_ENTRY_IRQ(RTC)
+};
+
+static struct platform_device nspire_rtc_device = {
+	.name		= "nspire-rtc",
+	.id		= 0,
+	.num_resources	= ARRAY_SIZE(nspire_rtc_resources),
+	.resource	= nspire_rtc_resources,
+};
+
+/* Memory mapped IO */
+struct map_desc nspire_io_regs[] __initdata = {
+	IOTABLE_ENTRY(ADC),
+	IOTABLE_ENTRY(APB),
+	IOTABLE_ENTRY(INTERRUPT),
+};
+
+void __init nspire_map_io(void)
+{
+	iotable_init(nspire_io_regs, ARRAY_SIZE(nspire_io_regs));
+}
+
+/* Clocks */
+void __init nspire_init_early(void)
+{
+	clkdev_add_table(nspire_clk_lookup, ARRAY_SIZE(nspire_clk_lookup));
+
+	/* Renable bus access to everything in case the OS disabled them */
+	writel(0, NSPIRE_APB_VIRTIO(NSPIRE_APB_POWER + 0x18));
+	writel(0, NSPIRE_APB_VIRTIO(NSPIRE_APB_POWER + 0x20));
+
+	/*
+	 * Ack some non-maskable clock speed change interrupts before cpufreq
+	 * driver is brought up to avoid a race condition between an interrupt
+	 * happening and driver init.
+	 */
+
+	writel(3, NSPIRE_APB_VIRTIO(NSPIRE_APB_POWER + 0x14));
+}
+
+/* Common init */
+void __init nspire_init(void)
+{
+	sram_init(NSPIRE_SRAM_PHYS_BASE, NSPIRE_SRAM_SIZE);
+	amba_device_register(&watchdog_device, &iomem_resource);
+
+	platform_device_register(&nspire_gpio_device);
+	platform_device_register(&nspire_rtc_device);
+	platform_device_register(&nspire_adc_device);
+
+}
+
+void __init nspire_init_late(void)
+{
+}
+
+/* Restart */
+void nspire_restart(char mode, const char *cmd)
+{
+	writel(2, NSPIRE_APB_VIRTIO(NSPIRE_APB_MISC + 0x8));
+}
diff --git a/arch/arm/mach-nspire/common.h b/arch/arm/mach-nspire/common.h
new file mode 100644
index 0000000..27e81b6
--- /dev/null
+++ b/arch/arm/mach-nspire/common.h
@@ -0,0 +1,52 @@
+/*
+ *	linux/arch/arm/mach-nspire/common.h
+ *
+ *	Copyright (C) 2012 Daniel Tang <tangrs at tangrs.id.au>
+ *
+ * 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.
+ *
+ */
+
+
+#define IOTABLE_ENTRY(t) \
+	{ \
+		.virtual	= NSPIRE_##t##_VIRT_BASE, \
+		.pfn		= __phys_to_pfn(NSPIRE_##t##_PHYS_BASE), \
+		.length		= NSPIRE_##t##_SIZE, \
+		.type		= MT_DEVICE \
+	}
+
+#define RESOURCE_ENTRY_IRQ(t) \
+	{ \
+		.start	= NSPIRE_IRQ_##t, \
+		.end	= NSPIRE_IRQ_##t, \
+		.flags	= IORESOURCE_IRQ \
+	}
+
+#define RESOURCE_ENTRY_MEM(t) \
+	{ \
+		.start	= NSPIRE_##t##_PHYS_BASE, \
+		.end	= NSPIRE_##t##_PHYS_BASE + NSPIRE_##t##_SIZE - 1, \
+		.flags	= IORESOURCE_MEM \
+	}
+
+extern struct platform_device nspire_keypad_device;
+extern struct platform_device nspire_otg_device;
+extern struct platform_device nspire_usb_nop_xceiver;
+extern struct nspire_keypad_data nspire_keypad_data;
+
+extern u64 nspire_usb_dma_mask;
+
+void __init nspire_map_io(void);
+void __init nspire_init_early(void);
+void __init nspire_init(void);
+void __init nspire_init_late(void);
+
+void nspire_restart(char mode, const char *cmd);
+
+int nspire_clcd_mmap(struct clcd_fb *fb, struct vm_area_struct *vma);
+void nspire_clcd_remove(struct clcd_fb *fb);
+int nspire_clcd_setup(struct clcd_fb *fb, unsigned panel_size,
+	struct clcd_panel *panel);
diff --git a/arch/arm/mach-nspire/include/mach/clkdev.h b/arch/arm/mach-nspire/include/mach/clkdev.h
new file mode 100644
index 0000000..b4afe65
--- /dev/null
+++ b/arch/arm/mach-nspire/include/mach/clkdev.h
@@ -0,0 +1,24 @@
+/*
+ *  linux/arch/arm/mach-nspire/include/mach/clkdev.h
+ *
+ *  Copyright (C) 2012 Daniel Tang <tangrs at tangrs.id.au>
+ *
+ * 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.
+ *
+ */
+
+#ifndef NSPIRE_CLKDEV_H
+#define NSPIRE_CLKDEV_H
+
+struct clk {
+	void (*get_rate)(struct clk *clk);
+	int (*set_rate)(struct clk *clk, unsigned long rate);
+	unsigned long rate;
+};
+
+#define __clk_get(clk) ({ 1; })
+#define __clk_put(clk) do { } while (0)
+
+#endif
diff --git a/arch/arm/mach-nspire/include/mach/debug-macro.S b/arch/arm/mach-nspire/include/mach/debug-macro.S
new file mode 100644
index 0000000..b71daa4
--- /dev/null
+++ b/arch/arm/mach-nspire/include/mach/debug-macro.S
@@ -0,0 +1,28 @@
+/*
+ *	linux/arch/arm/mach-nspire/include/mach/debug-macro.S
+ *
+ *	Copyright (C) 2012 Daniel Tang <tangrs at tangrs.id.au>
+ *
+ * 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.
+ *
+ */
+
+#define NSPIRE_EARLY_UART_PHYS_BASE	   0x90020000
+#define NSPIRE_EARLY_UART_VIRT_BASE	   0xfee20000
+
+.macro	addruart, rp, rv, tmp
+	ldr \rp, =(NSPIRE_EARLY_UART_PHYS_BASE)		@ physical base address
+	ldr \rv, =(NSPIRE_EARLY_UART_VIRT_BASE)		@ virtual base address
+.endm
+
+
+#ifdef CONFIG_NSPIRE_EARLYPRINTK_CX
+#include <asm/hardware/debug-pl01x.S>
+#endif
+
+#ifdef CONFIG_NSPIRE_EARLYPRINTK_CLASSIC
+#define UART_SHIFT 2
+#include <asm/hardware/debug-8250.S>
+#endif
diff --git a/arch/arm/mach-nspire/include/mach/hardware.h b/arch/arm/mach-nspire/include/mach/hardware.h
new file mode 100644
index 0000000..7c9c3b6
--- /dev/null
+++ b/arch/arm/mach-nspire/include/mach/hardware.h
@@ -0,0 +1,15 @@
+/*
+ *  linux/arch/arm/mach-nspire/include/mach/hardware.h
+ *
+ *  Copyright (C) 2012 Daniel Tang <tangrs at tangrs.id.au>
+ *
+ * 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.
+ *
+ */
+
+#ifndef NSPIRE_HARDWARE_H
+#define NSPIRE_HARDWARE_H
+
+#endif
diff --git a/arch/arm/mach-nspire/include/mach/irqs.h b/arch/arm/mach-nspire/include/mach/irqs.h
new file mode 100644
index 0000000..70be120
--- /dev/null
+++ b/arch/arm/mach-nspire/include/mach/irqs.h
@@ -0,0 +1,34 @@
+/*
+ *  linux/arch/arm/mach-nspire/include/mach/irqs.h
+ *
+ *  Copyright (C) 2012 Daniel Tang <tangrs at tangrs.id.au>
+ *
+ * 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.
+ *
+ */
+
+#ifndef NSPIRE_IRQS_H
+#define NSPIRE_IRQS_H
+
+#define NSPIRE_IRQ_MASK         0x007FEB9A
+
+enum {
+	NSPIRE_IRQ_UART = 1,
+	NSPIRE_IRQ_WATCHDOG = 3,
+	NSPIRE_IRQ_RTC = 4,
+	NSPIRE_IRQ_GPIO = 7,
+	NSPIRE_IRQ_OTG = 8,
+	NSPIRE_IRQ_HOSTUSB = 9,
+	NSPIRE_IRQ_ADC = 11,
+	NSPIRE_IRQ_PWR = 15,
+	NSPIRE_IRQ_KEYPAD = 16,
+	NSPIRE_IRQ_TIMER2 = 19,
+	NSPIRE_IRQ_I2C = 20,
+	NSPIRE_IRQ_LCD = 21
+};
+
+#define NR_IRQS 32
+
+#endif
diff --git a/arch/arm/mach-nspire/include/mach/keypad.h b/arch/arm/mach-nspire/include/mach/keypad.h
new file mode 100644
index 0000000..18cf3fd
--- /dev/null
+++ b/arch/arm/mach-nspire/include/mach/keypad.h
@@ -0,0 +1,31 @@
+/*
+ *  linux/arch/arm/mach-nspire/include/mach/keypad.h
+ *
+ *  Copyright (C) 2012 Daniel Tang <tangrs at tangrs.id.au>
+ *
+ * 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.
+ *
+ */
+
+#ifndef NSPIRE_KEYPAD_H
+#define NSPIRE_KEYPAD_H
+
+#define KEYPAD_BITMASK_COLS	11
+#define KEYPAD_BITMASK_ROWS	8
+
+struct nspire_keypad_data {
+	unsigned int (*evtcodes)[KEYPAD_BITMASK_COLS];
+
+	/* Maximum delay estimated assuming 33MHz APB */
+	unsigned short scan_interval;	/* In microseconds (~2000us max) */
+	unsigned short row_delay;	/* In microseconds (~500us max) */
+
+	bool active_low;
+};
+
+extern unsigned int nspire_touchpad_evtcode_map[][KEYPAD_BITMASK_COLS];
+extern unsigned int nspire_clickpad_evtcode_map[][KEYPAD_BITMASK_COLS];
+
+#endif
diff --git a/arch/arm/mach-nspire/include/mach/memory.h b/arch/arm/mach-nspire/include/mach/memory.h
new file mode 100644
index 0000000..eec3f36
--- /dev/null
+++ b/arch/arm/mach-nspire/include/mach/memory.h
@@ -0,0 +1,17 @@
+/*
+ *  linux/arch/arm/mach-nspire/include/mach/memory.h
+ *
+ *  Copyright (C) 2012 Daniel Tang <tangrs at tangrs.id.au>
+ *
+ * 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.
+ *
+ */
+
+#ifndef NSPIRE_MEMORY_H
+#define NSPIRE_MEMORY_H
+
+#define PLAT_PHYS_OFFSET 0x10000000
+
+#endif
diff --git a/arch/arm/mach-nspire/include/mach/nspire_clock.h b/arch/arm/mach-nspire/include/mach/nspire_clock.h
new file mode 100644
index 0000000..a96b089
--- /dev/null
+++ b/arch/arm/mach-nspire/include/mach/nspire_clock.h
@@ -0,0 +1,52 @@
+/*
+ *	linux/arch/arm/mach-nspire/include/mach/nspire_clock.h
+ *
+ *	Copyright (C) 2012 Daniel Tang <tangrs at tangrs.id.au>
+ *
+ * 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.
+ *
+ */
+
+#ifndef NSPIRE_CLOCK_H
+#define NSPIRE_CLOCK_H
+
+#include <linux/io.h>
+
+#include <mach/nspire_mmio.h>
+
+struct nspire_clk_divider {
+	unsigned char base_cpu, cpu_ahb;
+};
+
+struct nspire_clk_speeds {
+	unsigned long base;
+	struct nspire_clk_divider div;
+};
+
+#define CLK_GET_CPU(cs) ((cs)->base / (cs)->div.base_cpu)
+#define CLK_GET_AHB(cs) (CLK_GET_CPU(cs) / (cs)->div.cpu_ahb)
+
+extern struct nspire_clk_speeds (*nspire_io_to_clocks)(unsigned long);
+extern unsigned long (*nspire_clocks_to_io)(struct nspire_clk_speeds *);
+
+static inline struct nspire_clk_speeds nspire_get_clocks(void)
+{
+	unsigned long val = readl(NSPIRE_APB_VIRTIO(NSPIRE_APB_POWER + 0x00));
+	BUG_ON(!nspire_io_to_clocks);
+	return nspire_io_to_clocks(val);
+}
+
+static inline void nspire_set_clocks(struct nspire_clk_speeds *clks)
+{
+	unsigned long val;
+	BUG_ON(!nspire_io_to_clocks);
+
+	val = nspire_clocks_to_io(clks);
+
+	writel(val, NSPIRE_APB_VIRTIO(NSPIRE_APB_POWER + 0x00));
+	writel(4,   NSPIRE_APB_VIRTIO(NSPIRE_APB_POWER + 0x0c));
+}
+
+#endif
diff --git a/arch/arm/mach-nspire/include/mach/nspire_mmio.h b/arch/arm/mach-nspire/include/mach/nspire_mmio.h
new file mode 100644
index 0000000..eaeb100
--- /dev/null
+++ b/arch/arm/mach-nspire/include/mach/nspire_mmio.h
@@ -0,0 +1,67 @@
+/*
+ *	linux/arch/arm/mach-nspire/include/mach/nspire_mmio.h
+ *
+ *	Copyright (C) 2012 Daniel Tang <tangrs at tangrs.id.au>
+ *
+ * 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.
+ *
+ */
+
+#ifndef NSPIRE_MMIO_H
+#define NSPIRE_MMIO_H
+
+#include <asm-generic/sizes.h>
+
+/*
+	Memory map:
+	0xFEE00000 - 0xFF000000		0x90000000 - 0x90200000		(APB)
+	0xFEDFF000 - 0xFEE00000		0xDC000000 - 0xDC001000		(Interrupt Controller)
+	0xFED7F000 - 0xFEDFF000		0x00000000 - 0x00080000		(Boot1 ROM)
+	0xFED7E000 - 0xFED7F000		0xC4000000 - 0xC4001000		(ADC)
+*/
+#define NSPIRE_APB_PHYS_BASE		0x90000000
+#define NSPIRE_APB_SIZE			SZ_2M
+#define NSPIRE_APB_VIRT_BASE		0xFEE00000
+
+#define NSPIRE_APB_PHYS(x)		((NSPIRE_APB_PHYS_BASE) + (x))
+#define NSPIRE_APB_VIRT(x)		((NSPIRE_APB_VIRT_BASE) + (x))
+#define NSPIRE_APB_VIRTIO(x)		IOMEM(NSPIRE_APB_VIRT(x))
+
+
+#define NSPIRE_INTERRUPT_PHYS_BASE	0xDC000000
+#define NSPIRE_INTERRUPT_SIZE		SZ_4K
+#define NSPIRE_INTERRUPT_VIRT_BASE	0xFEDFF000
+
+#define NSPIRE_LCD_PHYS_BASE		0xC0000000
+
+#define NSPIRE_OTG_PHYS_BASE		0xB0000000
+#define NSPIRE_OTG_SIZE			SZ_8K
+
+#define NSPIRE_NAND_PHYS_BASE		0x81000000
+#define NSPIRE_NAND_SIZE		SZ_16M
+
+#define NSPIRE_BOOT1_PHYS_BASE		0x00000000
+#define NSPIRE_BOOT1_SIZE		0x00080000
+#define NSPIRE_BOOT1_VIRT_BASE		0xFED7F000
+
+#define NSPIRE_APB_GPIO			0x00000
+#define NSPIRE_APB_UART			0x20000
+#define NSPIRE_APB_I2C			0x50000
+#define NSPIRE_APB_WATCHDOG		0x60000
+#define NSPIRE_APB_RTC			0x90000
+#define NSPIRE_APB_MISC			0xA0000
+#define NSPIRE_APB_POWER		0xB0000
+#define NSPIRE_APB_TIMER2		0xD0000
+#define NSPIRE_APB_KEYPAD		0xE0000
+#define NSPIRE_APB_CONTRAST		0xF0000
+
+#define NSPIRE_SRAM_PHYS_BASE		0xA4000000
+#define NSPIRE_SRAM_SIZE		0x00020000
+
+#define NSPIRE_ADC_PHYS_BASE		0xC4000000
+#define NSPIRE_ADC_SIZE			SZ_4K
+#define NSPIRE_ADC_VIRT_BASE		0xFED7E000
+
+#endif
diff --git a/arch/arm/mach-nspire/include/mach/sram.h b/arch/arm/mach-nspire/include/mach/sram.h
new file mode 100644
index 0000000..2f652f3
--- /dev/null
+++ b/arch/arm/mach-nspire/include/mach/sram.h
@@ -0,0 +1,26 @@
+/*
+ * Copyright (C) 2010 Freescale Semiconductor, Inc. All Rights Reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
+ * MA 02110-1301, USA.
+ */
+#ifndef NSPIRE_SRAM_H
+#define NSPIRE_SRAM_H
+
+void *sram_alloc(unsigned int size, dma_addr_t *dma_addr);
+void sram_free(dma_addr_t addr, unsigned int size);
+int __init sram_init(unsigned long base, unsigned long size);
+
+#endif
diff --git a/arch/arm/mach-nspire/include/mach/timex.h b/arch/arm/mach-nspire/include/mach/timex.h
new file mode 100644
index 0000000..2d4449e
--- /dev/null
+++ b/arch/arm/mach-nspire/include/mach/timex.h
@@ -0,0 +1,15 @@
+/*
+ *  linux/arch/arm/mach-nspire/include/mach/timex.h
+ *
+ *  Copyright (C) 2012 Daniel Tang <tangrs at tangrs.id.au>
+ *
+ * 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.
+ *
+ */
+
+#ifndef NSPIRE_TIMEX_H
+#define NSPIRE_TIMEX_H
+
+#endif
diff --git a/arch/arm/mach-nspire/include/mach/uncompress.h b/arch/arm/mach-nspire/include/mach/uncompress.h
new file mode 100644
index 0000000..7be9d06
--- /dev/null
+++ b/arch/arm/mach-nspire/include/mach/uncompress.h
@@ -0,0 +1,42 @@
+/*
+ *	linux/arch/arm/mach-nspire/include/mach/uncompress.h
+ *
+ *	Copyright (C) 2012 Daniel Tang <tangrs at tangrs.id.au>
+ *	Copyright (C) 2013 Lionel Debroux <lionel_debroux at yahoo.fr>
+ *
+ * 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.
+ *
+ */
+
+#ifndef NSPIRE_UNCOMPRESS_H
+#define NSPIRE_UNCOMPRESS_H
+
+#include <mach/nspire_mmio.h>
+
+#define OFFSET_VAL(var, offset) ((var)[(offset)>>2])
+static inline void putc(int c)
+{
+	volatile unsigned __attribute__((unused)) *serial_base =
+		(volatile unsigned *) NSPIRE_APB_PHYS(NSPIRE_APB_UART);
+
+#ifdef CONFIG_NSPIRE_EARLYPRINTK_CLASSIC
+	OFFSET_VAL(serial_base, 0x00) = (unsigned char)c;
+	while (!(OFFSET_VAL(serial_base, 0x14) & (1<<5)))
+		barrier();
+#endif
+
+#ifdef CONFIG_NSPIRE_EARLYPRINTK_CX
+	OFFSET_VAL(serial_base, 0x00) = (unsigned char)c;
+	while (OFFSET_VAL(serial_base, 0x18) & (1<<5))
+		barrier();
+#endif
+
+}
+#undef OFFSET_VAL
+
+#define arch_decomp_setup()
+#define flush()
+
+#endif
diff --git a/arch/arm/mach-nspire/keypad.c b/arch/arm/mach-nspire/keypad.c
new file mode 100644
index 0000000..5cd9344
--- /dev/null
+++ b/arch/arm/mach-nspire/keypad.c
@@ -0,0 +1,100 @@
+/*
+ *	linux/arch/arm/mach-nspire/keypad.c
+ *
+ *	Copyright (C) 2012 Daniel Tang <tangrs at tangrs.id.au>
+ *
+ * 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/input.h>
+
+#include <mach/keypad.h>
+
+unsigned int nspire_touchpad_evtcode_map[][KEYPAD_BITMASK_COLS] = {
+	{
+		KEY_ENTER,	KEY_ENTER,	0,		0,
+		KEY_SPACE,	KEY_Z,		KEY_Y,		KEY_0,
+		KEY_TAB,	0,		0,
+	},
+	{
+		KEY_X,		KEY_W,		KEY_V,		KEY_3,
+		KEY_U,		KEY_T,		KEY_S,		KEY_1,
+		0,		0,		KEY_RIGHT
+	},
+	{
+		KEY_R,		KEY_Q,		KEY_P,		KEY_6,
+		KEY_O,		KEY_N,		KEY_M,		KEY_4,
+		KEY_APOSTROPHE, KEY_DOWN,	0
+	},
+	{
+		KEY_L,		KEY_K,		KEY_J,		KEY_9,
+		KEY_I,		KEY_H,		KEY_G,		KEY_7,
+		KEY_SLASH,	KEY_LEFT,	0
+	},
+	{
+		KEY_F,		KEY_E,		KEY_D,		0,
+		KEY_C,		KEY_B,		KEY_A,		KEY_EQUAL,
+		KEY_KPASTERISK, KEY_UP,		0
+	},
+	{
+		0,		KEY_LEFTALT,	KEY_MINUS,	KEY_RIGHTBRACE,
+		KEY_DOT,	KEY_LEFTBRACE,	KEY_5,		0,
+		KEY_SEMICOLON,	KEY_BACKSPACE,	KEY_DELETE
+	},
+	{
+		KEY_BACKSLASH,	0,		KEY_KPPLUS,	KEY_PAGEUP,
+		KEY_2,		KEY_PAGEDOWN,	KEY_8,		KEY_ESC,
+		0,		KEY_TAB,	0
+	},
+	{
+		0,		0,		0,		0,
+		0,		0,		0,		0,
+		KEY_LEFTSHIFT,	KEY_LEFTCTRL,	KEY_COMMA
+	},
+};
+
+unsigned int nspire_clickpad_evtcode_map[][KEYPAD_BITMASK_COLS] = {
+	{
+		KEY_ENTER,	KEY_ENTER,	KEY_SPACE,	0,
+		KEY_Z,		KEY_DOT,	KEY_Y,		KEY_0,
+		KEY_X,		0,		0,
+	},
+	{
+		KEY_COMMA,	KEY_KPPLUS,	KEY_W,		KEY_3,
+		KEY_V,		KEY_2,		KEY_U,		KEY_1,
+		KEY_T,		0,		0
+	},
+	{
+		KEY_KPSLASH,	KEY_MINUS,	KEY_S,		KEY_6,
+		KEY_R,		KEY_5,		KEY_Q,		KEY_4,
+		KEY_P,		0,		0
+	},
+	{
+		KEY_SEMICOLON,	KEY_KPASTERISK, KEY_O,		KEY_9,
+		KEY_N,		KEY_8,		KEY_M,		KEY_7,
+		KEY_L,		0,		0
+	},
+	{
+		KEY_APOSTROPHE, KEY_SLASH,	KEY_K,		0,
+		KEY_J,		0,		KEY_I,		0,
+		KEY_H,		0,		0
+	},
+	{
+		KEY_APOSTROPHE, 0,		KEY_G,		KEY_RIGHTBRACE,
+		KEY_F,		KEY_LEFTBRACE,	KEY_E,		KEY_DELETE,
+		KEY_D,		KEY_LEFTSHIFT,	0
+	},
+	{
+		0,		KEY_ENTER,	KEY_C,		KEY_PAGEUP,
+		KEY_B,		KEY_PAGEDOWN,	KEY_A,		KEY_ESC,
+		KEY_BACKSLASH,	KEY_TAB,	0
+	},
+	{
+		KEY_UP,		0,		KEY_RIGHT,	0,
+		KEY_DOWN,	0,		KEY_LEFT,	KEY_BACKSPACE,
+		KEY_LEFTCTRL,	0,		KEY_EQUAL
+	},
+};
diff --git a/arch/arm/mach-nspire/nspire_clp.c b/arch/arm/mach-nspire/nspire_clp.c
new file mode 100644
index 0000000..945ab5d
--- /dev/null
+++ b/arch/arm/mach-nspire/nspire_clp.c
@@ -0,0 +1,57 @@
+/*
+ *	linux/arch/arm/mach-nspire/nspire_clp.c
+ *
+ *	Copyright (C) 2012 Daniel Tang <tangrs at tangrs.id.au>
+ *
+ * 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/init.h>
+#include <linux/io.h>
+#include <linux/clkdev.h>
+#include <linux/interrupt.h>
+#include <linux/ioport.h>
+#include <linux/platform_device.h>
+#include <linux/dma-mapping.h>
+#include <linux/amba/bus.h>
+#include <linux/amba/clcd.h>
+#include <linux/input.h>
+#include <linux/usb/ehci_pdriver.h>
+#include <linux/mtd/nand.h>
+
+#include <mach/nspire_mmio.h>
+#include <mach/irqs.h>
+#include <mach/clkdev.h>
+#include <mach/sram.h>
+#include <mach/keypad.h>
+
+#include <asm/mach/time.h>
+#include <asm/mach/map.h>
+#include <asm/mach-types.h>
+#include <asm/mach/arch.h>
+
+#include "common.h"
+#include "classic.h"
+
+static void __init clp_init(void)
+{
+	nspire_keypad_data.evtcodes = nspire_clickpad_evtcode_map;
+	platform_device_register(&nspire_otg_device);
+	platform_device_register(&nspire_usb_nop_xceiver);
+
+	nspire_classic_init();
+}
+
+MACHINE_START(NSPIRECLP, "TI-NSPIRE Clickpad Calculator")
+	.map_io		= nspire_map_io,
+	.init_irq	= nspire_classic_init_irq,
+	.handle_irq	= nspire_classic_handle_irq,
+	.init_time	= nspire_classic_timer_init,
+	.init_early	= nspire_classic_init_early,
+	.init_machine	= clp_init,
+	.init_late	= nspire_classic_init_late,
+	.restart	= nspire_restart,
+MACHINE_END
diff --git a/arch/arm/mach-nspire/nspire_cx.c b/arch/arm/mach-nspire/nspire_cx.c
new file mode 100644
index 0000000..81bbbf8
--- /dev/null
+++ b/arch/arm/mach-nspire/nspire_cx.c
@@ -0,0 +1,316 @@
+/*
+ *	linux/arch/arm/mach-nspire/nspire_cx.c
+ *
+ *	Copyright (C) 2012 Daniel Tang <tangrs at tangrs.id.au>
+ *
+ * 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/init.h>
+#include <linux/io.h>
+#include <linux/clkdev.h>
+#include <linux/interrupt.h>
+#include <linux/ioport.h>
+#include <linux/platform_device.h>
+#include <linux/dma-mapping.h>
+#include <linux/amba/bus.h>
+#include <linux/amba/clcd.h>
+#include <linux/input.h>
+#include <linux/usb/ehci_pdriver.h>
+#include <linux/mtd/nand.h>
+#include <linux/irqchip/arm-vic.h>
+
+#include <mach/nspire_mmio.h>
+#include <mach/nspire_clock.h>
+#include <mach/irqs.h>
+#include <mach/clkdev.h>
+#include <mach/sram.h>
+#include <mach/keypad.h>
+
+#include <asm/mach/time.h>
+#include <asm/hardware/timer-sp.h>
+#include <asm/mach/map.h>
+#include <asm/mach-types.h>
+#include <asm/mach/arch.h>
+
+#include "common.h"
+#include "touchpad.h"
+
+/* Clock */
+
+union reg_clk_speed {
+	unsigned long raw;
+	struct {
+		unsigned long __padding0:1;
+		unsigned long base_cpu_ratio:7;
+		unsigned long is_base_48mhz:1;
+		unsigned long __padding1:3;
+		unsigned long cpu_ahb_ratio:3;
+		unsigned long base_val:6;
+		unsigned long unknown:2;
+	} val;
+};
+
+static struct nspire_clk_speeds cx_io_to_clocks(unsigned long val)
+{
+	struct nspire_clk_speeds clks;
+	union reg_clk_speed reg;
+
+	reg.raw = val;
+	reg.val.base_cpu_ratio *= reg.val.unknown;
+	reg.val.cpu_ahb_ratio++;
+
+	BUG_ON(reg.val.base_cpu_ratio == 0);
+
+	clks.base = reg.val.is_base_48mhz ? 48 : 6*reg.val.base_val;
+	clks.base *= 1000000; /* Convert to Hz */
+
+	clks.div.base_cpu = reg.val.base_cpu_ratio;
+	clks.div.cpu_ahb = reg.val.cpu_ahb_ratio;
+
+	return clks;
+}
+
+static unsigned long cx_clocks_to_io(struct nspire_clk_speeds *clks)
+{
+	union reg_clk_speed reg;
+
+	BUG_ON(clks->div.base_cpu < 1);
+	BUG_ON(clks->div.cpu_ahb < 1);
+
+	reg.raw = 0;
+	reg.val.unknown = (clks->div.base_cpu & 0x1) ? 0b01 : 0b10;
+	reg.val.base_cpu_ratio = clks->div.base_cpu / reg.val.unknown;
+	reg.val.cpu_ahb_ratio = clks->div.cpu_ahb - 1;
+	reg.val.is_base_48mhz = (clks->base <= 48000000);
+	reg.val.base_val = (clks->base / 6000000);
+
+	return reg.raw;
+}
+
+/* IRQ */
+static void __init cx_init_irq(void)
+{
+	vic_init(IOMEM(NSPIRE_INTERRUPT_VIRT_BASE), 0, NSPIRE_IRQ_MASK, 0);
+}
+
+/* UART */
+
+static AMBA_APB_DEVICE(uart, "uart", 0, NSPIRE_APB_PHYS(NSPIRE_APB_UART),
+	{ NSPIRE_IRQ_UART }, NULL);
+
+/* TIMER */
+
+void __init cx_timer_init(void)
+{
+	sp804_clockevents_init(NSPIRE_APB_VIRTIO(NSPIRE_APB_TIMER2),
+		NSPIRE_IRQ_TIMER2, "timer2");
+}
+
+/* FRAMEBUFFER */
+static struct clcd_panel cx_lcd_panel = {
+	.mode		= {
+		.name		= "color lcd",
+		.refresh	= 60,
+		.xres		= 320,
+		.yres		= 240,
+		.sync		= 0,
+		.vmode		= FB_VMODE_NONINTERLACED,
+		.pixclock	= 1,
+		.hsync_len	= 6,
+		.vsync_len	= 1,
+		.right_margin	= 50,
+		.left_margin	= 38,
+		.lower_margin	= 3,
+		.upper_margin	= 17,
+	},
+	.width		= 65, /* ~6.50 cm */
+	.height		= 49, /* ~4.87 cm */
+	.tim2		= TIM2_IPC,
+	.cntl		= (CNTL_BGR | CNTL_LCDTFT | CNTL_LCDVCOMP(1) |
+				CNTL_LCDBPP16_565),
+	.bpp		= 16,
+};
+#define PANEL_SIZE (38 * SZ_4K)
+
+static int cx_clcd_setup(struct clcd_fb *fb)
+{
+	return nspire_clcd_setup(fb, PANEL_SIZE, &cx_lcd_panel);
+}
+
+static struct clcd_board cx_clcd_data = {
+	.name		= "lcd controller",
+	.check		= clcdfb_check,
+	.decode		= clcdfb_decode,
+	.setup		= cx_clcd_setup,
+	.mmap		= nspire_clcd_mmap,
+	.remove		= nspire_clcd_remove,
+};
+
+static AMBA_AHB_DEVICE(fb, "fb", 0, NSPIRE_LCD_PHYS_BASE,
+	{ NSPIRE_IRQ_LCD }, &cx_clcd_data);
+
+/* USB HOST */
+
+static struct usb_ehci_pdata cxusbhost_pdata = {
+	.has_tt = 1,
+	.caps_offset = 0x100
+};
+
+static struct resource cxusbhost_resources_pdata[] = {
+	RESOURCE_ENTRY_MEM(OTG),
+	RESOURCE_ENTRY_IRQ(OTG)
+};
+
+static struct platform_device usbhost_device = {
+	.name		= "ehci-platform",
+	.id		= 0,
+	.dev = {
+		.platform_data = &cxusbhost_pdata,
+		.coherent_dma_mask = ~0,
+		.dma_mask = &nspire_usb_dma_mask
+	},
+	.resource = cxusbhost_resources_pdata,
+	.num_resources = ARRAY_SIZE(cxusbhost_resources_pdata)
+};
+
+
+static __init int cx_usb_init(void)
+{
+	int err = 0;
+	unsigned val;
+	void __iomem *hostusb_addr =
+		ioremap(NSPIRE_OTG_PHYS_BASE, NSPIRE_OTG_SIZE);
+
+	if (!hostusb_addr) {
+		pr_warn("Could not allocate enough memory to initialize NSPIRE host USB\n");
+		err = -ENOMEM;
+		goto out;
+	}
+
+	/* Disable OTG interrupts */
+	pr_info("Disable OTG interrupts\n");
+	val	 = readl(hostusb_addr + 0x1a4);
+	val &= ~(0x7f<<24);
+	writel(val, hostusb_addr + 0x1a4);
+
+	iounmap(hostusb_addr);
+
+	pr_info("Adding USB controller as platform device\n");
+	err = platform_device_register(&usbhost_device);
+out:
+
+	return err;
+}
+
+static __init int cx_usb_workaround(void)
+{
+	int err = 0;
+	unsigned val;
+	void __iomem *hostusb_addr =
+		ioremap(NSPIRE_OTG_PHYS_BASE, NSPIRE_OTG_SIZE);
+
+	if (!hostusb_addr) {
+		pr_warn("Could not do USB workaround\n");
+		err = -ENOMEM;
+		goto out;
+	}
+
+	pr_info("Temporary USB hack to force USB to connect as fullspeed\n");
+	val	 = readl(hostusb_addr + 0x184);
+	val |= (1<<24);
+	writel(val, hostusb_addr + 0x184);
+
+	iounmap(hostusb_addr);
+out:
+
+	return err;
+}
+
+/* Backlight driver */
+
+#define CX_BACKLIGHT_UPPER	0x1d0
+#define CX_BACKLIGHT_LOWER	0x100 /* Should be (around about) off */
+
+static void cx_set_backlight(int val)
+{
+	val += CX_BACKLIGHT_LOWER;
+
+	if (val <= CX_BACKLIGHT_UPPER)
+		writel(val, NSPIRE_APB_VIRTIO(NSPIRE_APB_CONTRAST + 0x20));
+}
+
+static struct generic_bl_info cx_bl = {
+	.name		= "nspire_backlight",
+	.max_intensity	= CX_BACKLIGHT_UPPER - CX_BACKLIGHT_LOWER,
+	.default_intensity = (CX_BACKLIGHT_UPPER - CX_BACKLIGHT_LOWER) / 2,
+	.set_bl_intensity = cx_set_backlight
+};
+
+static struct platform_device bl_device = {
+	.name		= "generic-bl",
+	.id		= 0,
+	.dev = {
+		.platform_data = &cx_bl,
+	}
+};
+
+/* Init */
+
+bool cx_use_otg;
+static int __init set_cx_otg(char *dummy __attribute__((unused)))
+{
+	cx_use_otg = 1;
+	return 0;
+}
+early_param("cx_use_otg", set_cx_otg);
+
+static void __init cx_early_init(void)
+{
+	nspire_io_to_clocks = cx_io_to_clocks;
+	nspire_clocks_to_io = cx_clocks_to_io;
+
+	nspire_init_early();
+}
+
+static void __init cx_init(void)
+{
+	nspire_init();
+	amba_device_register(&fb_device, &iomem_resource);
+	amba_device_register(&uart_device, &iomem_resource);
+
+	nspire_keypad_data.evtcodes = nspire_touchpad_evtcode_map;
+	platform_device_register(&nspire_keypad_device);
+	platform_device_register(&bl_device);
+	nspire_touchpad_init();
+
+	if (!cx_use_otg) {
+		pr_info("Selecting USB host only driver for CX\n");
+		cx_usb_init();
+	} else {
+		pr_info("Selecting USB OTG driver for CX\n");
+		platform_device_register(&nspire_otg_device);
+		platform_device_register(&nspire_usb_nop_xceiver);
+	}
+}
+
+static void __init cx_init_late(void)
+{
+	if (!cx_use_otg)
+		cx_usb_workaround();
+	nspire_init_late();
+}
+
+MACHINE_START(NSPIRECX, "TI-NSPIRE CX Calculator")
+	.nr_irqs	= NR_IRQS,
+	.map_io		= nspire_map_io,
+	.init_irq	= cx_init_irq,
+	.init_time	= cx_timer_init,
+	.init_early	= cx_early_init,
+	.init_machine	= cx_init,
+	.init_late	= cx_init_late,
+	.restart	= nspire_restart,
+MACHINE_END
diff --git a/arch/arm/mach-nspire/nspire_tp.c b/arch/arm/mach-nspire/nspire_tp.c
new file mode 100644
index 0000000..cec05b6
--- /dev/null
+++ b/arch/arm/mach-nspire/nspire_tp.c
@@ -0,0 +1,80 @@
+/*
+ *	linux/arch/arm/mach-nspire/nspire_clp.c
+ *
+ *	Copyright (C) 2012 Daniel Tang <tangrs at tangrs.id.au>
+ *
+ * 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/init.h>
+#include <linux/io.h>
+#include <linux/clkdev.h>
+#include <linux/interrupt.h>
+#include <linux/ioport.h>
+#include <linux/platform_device.h>
+#include <linux/dma-mapping.h>
+#include <linux/amba/bus.h>
+#include <linux/amba/clcd.h>
+#include <linux/input.h>
+#include <linux/usb/ehci_pdriver.h>
+#include <linux/mtd/nand.h>
+#include <linux/irq.h>
+#include <linux/i2c-gpio.h>
+
+#include <mach/nspire_mmio.h>
+#include <mach/irqs.h>
+#include <mach/clkdev.h>
+#include <mach/sram.h>
+#include <mach/keypad.h>
+
+#include <asm/mach/time.h>
+#include <asm/mach/map.h>
+#include <asm/mach-types.h>
+#include <asm/mach/arch.h>
+
+#include "common.h"
+#include "classic.h"
+#include "touchpad.h"
+
+/* I2C GPIO (touchpad) */
+
+static struct i2c_gpio_platform_data i2c_pdata = {
+	.sda_pin	= 3,
+	.scl_pin	= 1,
+	.udelay		= 1,
+	.timeout	= 1000,
+};
+
+static struct platform_device i2c_device = {
+	.name		= "i2c-gpio",
+	.id		= 0,
+	.dev = {
+		.platform_data = &i2c_pdata,
+	}
+};
+
+static void __init tp_init(void)
+{
+	nspire_keypad_data.evtcodes = nspire_touchpad_evtcode_map;
+	platform_device_register(&i2c_device);
+
+	platform_device_register(&nspire_otg_device);
+	platform_device_register(&nspire_usb_nop_xceiver);
+
+	nspire_classic_init();
+	nspire_touchpad_init();
+}
+
+MACHINE_START(NSPIRETP, "TI-NSPIRE Touchpad Calculator")
+	.map_io		= nspire_map_io,
+	.init_irq	= nspire_classic_init_irq,
+	.handle_irq	= nspire_classic_handle_irq,
+	.init_time	= nspire_classic_timer_init,
+	.init_early	= nspire_classic_init_early,
+	.init_machine	= tp_init,
+	.init_late	= nspire_classic_init_late,
+	.restart	= nspire_restart,
+MACHINE_END
diff --git a/arch/arm/mach-nspire/sram.c b/arch/arm/mach-nspire/sram.c
new file mode 100644
index 0000000..52b8e5c
--- /dev/null
+++ b/arch/arm/mach-nspire/sram.c
@@ -0,0 +1,66 @@
+/*
+ * Copyright (C) 2010 Freescale Semiconductor, Inc. All Rights Reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
+ * MA 02110-1301, USA.
+ */
+
+#include <linux/kernel.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/spinlock.h>
+#include <linux/genalloc.h>
+
+static unsigned long sram_phys_base;
+static __iomem void *sram_virt_base;
+static struct gen_pool *sram_pool;
+
+#define sram_phys_to_virt(p) (sram_virt_base + ((p) - sram_phys_base))
+
+void *sram_alloc(unsigned int size, dma_addr_t *dma_addr)
+{
+	if (!sram_pool)
+		return NULL;
+
+	*dma_addr = gen_pool_alloc(sram_pool, size);
+	pr_info("sram alloc - %dB at 0x%p\n", size, (void *)*dma_addr);
+	return sram_phys_to_virt(*dma_addr);
+}
+EXPORT_SYMBOL(sram_alloc);
+
+void sram_free(dma_addr_t addr, unsigned int size)
+{
+	if (!sram_pool)
+		return;
+
+	gen_pool_free(sram_pool, addr, size);
+}
+EXPORT_SYMBOL(sram_free);
+
+int __init sram_init(unsigned long base, unsigned long size)
+{
+	sram_phys_base = base;
+
+	sram_pool = gen_pool_create(10, -1);
+	if (!sram_pool) {
+		pr_warn("Cannot create sram pool!\n");
+		return -ENOMEM;
+	}
+	gen_pool_add(sram_pool, base, size, -1);
+	sram_virt_base = ioremap(sram_phys_base, size);
+
+	pr_info("sram pool: %ld KB at 0x%p\n", size / 1024, sram_virt_base);
+	return 0;
+}
diff --git a/arch/arm/mach-nspire/touchpad.c b/arch/arm/mach-nspire/touchpad.c
new file mode 100644
index 0000000..2330451
--- /dev/null
+++ b/arch/arm/mach-nspire/touchpad.c
@@ -0,0 +1,30 @@
+/*
+ *	linux/arch/arm/mach-nspire/touchpad.c
+ *
+ *	Copyright (C) 2012 Fabian Vogt <fabian at ritter-vogt.de>
+ *
+ * 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/i2c.h>
+
+#include "touchpad.h"
+
+#if defined(CONFIG_MOUSE_SYNAPTICS_I2C) || \
+	defined(CONFIG_MOUSE_SYNAPTICS_I2C_MODULE)
+static struct i2c_board_info synaptics_i2c = {
+	I2C_BOARD_INFO("synaptics_i2c", 0x20),
+	.irq    = 0,
+};
+
+void __init nspire_touchpad_init()
+{
+	i2c_register_board_info(0, &synaptics_i2c, 1);
+}
+
+#else
+inline void nspire_touchpad_init() {}
+#endif
diff --git a/arch/arm/mach-nspire/touchpad.h b/arch/arm/mach-nspire/touchpad.h
new file mode 100644
index 0000000..9222572
--- /dev/null
+++ b/arch/arm/mach-nspire/touchpad.h
@@ -0,0 +1,17 @@
+/*
+ *	linux/arch/arm/mach-nspire/touchpad.c
+ *
+ *	Copyright (C) 2012 Fabian Vogt <fabian at ritter-vogt.de>
+ *
+ * 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.
+ *
+ */
+
+#ifndef TOUCHPAD_H
+#define TOUCHPAD_H
+
+void __init nspire_touchpad_init(void);
+
+#endif
diff --git a/arch/arm/tools/mach-types b/arch/arm/tools/mach-types
index 831e1fd..e76c16b 100644
--- a/arch/arm/tools/mach-types
+++ b/arch/arm/tools/mach-types
@@ -1204,3 +1204,6 @@ baileys			MACH_BAILEYS		BAILEYS			4169
 familybox		MACH_FAMILYBOX		FAMILYBOX		4170
 ensemble_mx35		MACH_ENSEMBLE_MX35	ENSEMBLE_MX35		4171
 sc_sps_1		MACH_SC_SPS_1		SC_SPS_1		4172
+nspireclp		MACH_NSPIRECLP		NSPIRECLP		4441
+nspiretp		MACH_NSPIRETP		NSPIRETP		4442
+nspirecx		MACH_NSPIRECX		NSPIRECX		4443
--
1.7.9.6 (Apple Git-31.1)




From horms at verge.net.au  Thu Apr  4 05:03:17 2013
From: horms at verge.net.au (Simon Horman)
Date: Thu, 4 Apr 2013 18:03:17 +0900
Subject: [PATCH 1/2] ARM: shmobile: R8A7779: add Ether support
In-Reply-To: <515C2E24.1080108@cogentembedded.com>
References: <201304020204.54546.sergei.shtylyov@cogentembedded.com>
 <87y5d16b1d.wl%kuninori.morimoto.gx@renesas.com>
 <515AC4C8.1080803@cogentembedded.com>
 <87sj38cvfn.wl%kuninori.morimoto.gx@renesas.com>
 <515C2E24.1080108@cogentembedded.com>
Message-ID: <20130404090317.GB23848@verge.net.au>

On Wed, Apr 03, 2013 at 05:27:00PM +0400, Sergei Shtylyov wrote:
> Hello.
> 
> On 03-04-2013 4:25, Kuninori Morimoto wrote:
> 
> >>>Current ARM SoC is trying to not use platform_device_register()
> >>>Please use platform_device_register_xxx()
> >>>Same comment for [2/2]
> 
> >>     Is there some rationale to it? I don't find platform_device_register_xxx()
> >>especially handy to use.
> 
> >http://www.spinics.net/lists/linux-sh/msg16871.html
> 
>    I don't see there actual Greg KH's rationale for not using
> platform_register_device().

I'm sure that you can find the rationale if you look.
If not you can ask him, if it is important to you.
Failing that, I can ask him, if its important to you.

However, the point is that Arnd, who is the upstream for shmobile, has
indicated that he would prefer
platform_device_register_{full,resndata,data,simple} used instead of
platform_register_device(). And furthermore Magnus appears to have started
following this advice in his series "[PATCH 01/04] ARM: shmobile: r8a7740
pinmux platform device cleanup".

I would like you to update this patch to follow that advice too.
Likewise for the similar R8A7778 patch.



From horms at verge.net.au  Thu Apr  4 05:04:39 2013
From: horms at verge.net.au (Simon Horman)
Date: Thu, 4 Apr 2013 18:04:39 +0900
Subject: [PATCH 1/2] ARM: shmobile: R8A7779: add Ether support
In-Reply-To: <20130404063410.GP28297@verge.net.au>
References: <201304020204.54546.sergei.shtylyov@cogentembedded.com>
 <87wqsl6ale.wl%kuninori.morimoto.gx@renesas.com>
 <515AC546.90905@cogentembedded.com>
 <87txnocw6n.wl%kuninori.morimoto.gx@renesas.com>
 <515C2D0E.8010607@cogentembedded.com>
 <20130404063410.GP28297@verge.net.au>
Message-ID: <20130404090439.GC23848@verge.net.au>

On Thu, Apr 04, 2013 at 03:34:10PM +0900, Simon Horman wrote:
> On Wed, Apr 03, 2013 at 05:22:22PM +0400, Sergei Shtylyov wrote:
> > Hello.
> > 
> > On 03-04-2013 4:08, Kuninori Morimoto wrote:
> > 
> > >>>Then, this (void *pdata) should be
> > >>>(struct sh_eth_plat_data *pdata) IMO
> > 
> > >>     ether_device.dev.platform_data is 'void *'. I didn't want to bring in
> > >>extra header for the little use.
> > 
> > >Not enough reason for me.
> > 
> > >"void *" means there is no pointer check,
> > >and extra header is just 1 line. No ?
> > 
> >    There's no pointer check either if we just initialize the 'platform_data'
> > member as part of the platfrom device initializer, so we can
> > actually stuff pointer to any nonsense there. Why make this case
> > different?
> > 
> > >If you want to use this style,
> > >then, additional extra header is fate, IMO
> > 
> >    We can agree to disagree here. :-)
> 
> I would like void * changed to struct sh_eth_plat_data * so
> that callers of r8a7779_add_ether_device() will get a warning
> if they pass an argument of the wrong type.
> 
> Other than that I believe that I am happy with this patch.
>
> Ditto for the similar patch for the R8A7778.

As mentioned in a subsequent email in another subthread,
I would also like you to update the patches to not use
platform_register_device().



From pgaikwad at nvidia.com  Thu Apr  4 05:05:04 2013
From: pgaikwad at nvidia.com (Prashant Gaikwad)
Date: Thu, 4 Apr 2013 14:35:04 +0530
Subject: [PATCH] clk: tegra: Fix cdev1 and cdev2 IDs
Message-ID: <1365066304-2327-1-git-send-email-pgaikwad@nvidia.com>

Correct IDs for cdev1 and cdev2 are 94 and 93 respectively.

Signed-off-by: Prashant Gaikwad <pgaikwad at nvidia.com>
---

Stephen, tested this patch on Ventana and Cardhu, please verify if
I am not missing any platform which uses cdev1/cdev2.

---
 .../bindings/clock/nvidia,tegra20-car.txt          |    4 ++--
 arch/arm/boot/dts/tegra20-colibri-512.dtsi         |    2 +-
 arch/arm/boot/dts/tegra20-harmony.dts              |    2 +-
 arch/arm/boot/dts/tegra20-medcom-wide.dts          |    2 +-
 arch/arm/boot/dts/tegra20-paz00.dts                |    2 +-
 arch/arm/boot/dts/tegra20-plutux.dts               |    2 +-
 arch/arm/boot/dts/tegra20-seaboard.dts             |    2 +-
 arch/arm/boot/dts/tegra20-tec.dts                  |    2 +-
 arch/arm/boot/dts/tegra20-trimslice.dts            |    2 +-
 arch/arm/boot/dts/tegra20-ventana.dts              |    2 +-
 arch/arm/boot/dts/tegra20-whistler.dts             |    2 +-
 arch/arm/boot/dts/tegra20.dtsi                     |    2 +-
 drivers/clk/tegra/clk-tegra20.c                    |    2 +-
 drivers/clk/tegra/clk-tegra30.c                    |    2 +-
 14 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt b/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt
index 0921fac..e885680 100644
--- a/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt
+++ b/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt
@@ -120,8 +120,8 @@ Required properties :
   90	clk_d
   91	unassigned
   92	sus
-  93	cdev1
-  94	cdev2
+  93	cdev2
+  94	cdev1
   95	unassigned
 
   96	uart2
diff --git a/arch/arm/boot/dts/tegra20-colibri-512.dtsi b/arch/arm/boot/dts/tegra20-colibri-512.dtsi
index 79af149..7e96750 100644
--- a/arch/arm/boot/dts/tegra20-colibri-512.dtsi
+++ b/arch/arm/boot/dts/tegra20-colibri-512.dtsi
@@ -461,7 +461,7 @@
 
 		nvidia,ac97-controller = <&ac97>;
 
-		clocks = <&tegra_car 112>, <&tegra_car 113>, <&tegra_car 93>;
+		clocks = <&tegra_car 112>, <&tegra_car 113>, <&tegra_car 94>;
 		clock-names = "pll_a", "pll_a_out0", "mclk";
 	};
 
diff --git a/arch/arm/boot/dts/tegra20-harmony.dts b/arch/arm/boot/dts/tegra20-harmony.dts
index 5fb0888..c108dc8 100644
--- a/arch/arm/boot/dts/tegra20-harmony.dts
+++ b/arch/arm/boot/dts/tegra20-harmony.dts
@@ -657,7 +657,7 @@
 		nvidia,int-mic-en-gpios = <&gpio 184 0>; /*gpio PX0 */
 		nvidia,ext-mic-en-gpios = <&gpio 185 0>; /* gpio PX1 */
 
-		clocks = <&tegra_car 112>, <&tegra_car 113>, <&tegra_car 93>;
+		clocks = <&tegra_car 112>, <&tegra_car 113>, <&tegra_car 94>;
 		clock-names = "pll_a", "pll_a_out0", "mclk";
 	};
 };
diff --git a/arch/arm/boot/dts/tegra20-medcom-wide.dts b/arch/arm/boot/dts/tegra20-medcom-wide.dts
index 740ba7c..ace2343 100644
--- a/arch/arm/boot/dts/tegra20-medcom-wide.dts
+++ b/arch/arm/boot/dts/tegra20-medcom-wide.dts
@@ -59,7 +59,7 @@
 		nvidia,spkr-en-gpios = <&wm8903 2 0>;
 		nvidia,hp-det-gpios = <&gpio 178 0>; /* gpio PW2 */
 
-		clocks = <&tegra_car 112>, <&tegra_car 113>, <&tegra_car 93>;
+		clocks = <&tegra_car 112>, <&tegra_car 113>, <&tegra_car 94>;
 		clock-names = "pll_a", "pll_a_out0", "mclk";
 	};
 };
diff --git a/arch/arm/boot/dts/tegra20-paz00.dts b/arch/arm/boot/dts/tegra20-paz00.dts
index 43fd28b..59bd476 100644
--- a/arch/arm/boot/dts/tegra20-paz00.dts
+++ b/arch/arm/boot/dts/tegra20-paz00.dts
@@ -502,7 +502,7 @@
 		nvidia,i2s-controller = <&tegra_i2s1>;
 		nvidia,hp-det-gpios = <&gpio 178 0>; /* gpio PW2 */
 
-		clocks = <&tegra_car 112>, <&tegra_car 113>, <&tegra_car 93>;
+		clocks = <&tegra_car 112>, <&tegra_car 113>, <&tegra_car 94>;
 		clock-names = "pll_a", "pll_a_out0", "mclk";
 	};
 };
diff --git a/arch/arm/boot/dts/tegra20-plutux.dts b/arch/arm/boot/dts/tegra20-plutux.dts
index 7085ae5..1a17cc3 100644
--- a/arch/arm/boot/dts/tegra20-plutux.dts
+++ b/arch/arm/boot/dts/tegra20-plutux.dts
@@ -53,7 +53,7 @@
 		nvidia,spkr-en-gpios = <&wm8903 2 0>;
 		nvidia,hp-det-gpios = <&gpio 178 0>; /* gpio PW2 */
 
-		clocks = <&tegra_car 112>, <&tegra_car 113>, <&tegra_car 93>;
+		clocks = <&tegra_car 112>, <&tegra_car 113>, <&tegra_car 94>;
 		clock-names = "pll_a", "pll_a_out0", "mclk";
 	};
 };
diff --git a/arch/arm/boot/dts/tegra20-seaboard.dts b/arch/arm/boot/dts/tegra20-seaboard.dts
index 4f810a5..926cc6c 100644
--- a/arch/arm/boot/dts/tegra20-seaboard.dts
+++ b/arch/arm/boot/dts/tegra20-seaboard.dts
@@ -809,7 +809,7 @@
 		nvidia,spkr-en-gpios = <&wm8903 2 0>;
 		nvidia,hp-det-gpios = <&gpio 185 0>; /* gpio PX1 */
 
-		clocks = <&tegra_car 112>, <&tegra_car 113>, <&tegra_car 93>;
+		clocks = <&tegra_car 112>, <&tegra_car 113>, <&tegra_car 94>;
 		clock-names = "pll_a", "pll_a_out0", "mclk";
 	};
 };
diff --git a/arch/arm/boot/dts/tegra20-tec.dts b/arch/arm/boot/dts/tegra20-tec.dts
index 9be175d..742f0b3 100644
--- a/arch/arm/boot/dts/tegra20-tec.dts
+++ b/arch/arm/boot/dts/tegra20-tec.dts
@@ -53,7 +53,7 @@
 		nvidia,spkr-en-gpios = <&wm8903 2 0>;
 		nvidia,hp-det-gpios = <&gpio 178 0>; /* gpio PW2 */
 
-		clocks = <&tegra_car 112>, <&tegra_car 113>, <&tegra_car 93>;
+		clocks = <&tegra_car 112>, <&tegra_car 113>, <&tegra_car 94>;
 		clock-names = "pll_a", "pll_a_out0", "mclk";
 	};
 };
diff --git a/arch/arm/boot/dts/tegra20-trimslice.dts b/arch/arm/boot/dts/tegra20-trimslice.dts
index 955bf49..e703d73 100644
--- a/arch/arm/boot/dts/tegra20-trimslice.dts
+++ b/arch/arm/boot/dts/tegra20-trimslice.dts
@@ -364,7 +364,7 @@
 		nvidia,i2s-controller = <&tegra_i2s1>;
 		nvidia,audio-codec = <&codec>;
 
-		clocks = <&tegra_car 112>, <&tegra_car 113>, <&tegra_car 93>;
+		clocks = <&tegra_car 112>, <&tegra_car 113>, <&tegra_car 94>;
 		clock-names = "pll_a", "pll_a_out0", "mclk";
 	};
 };
diff --git a/arch/arm/boot/dts/tegra20-ventana.dts b/arch/arm/boot/dts/tegra20-ventana.dts
index 3f8ae10..02443be 100644
--- a/arch/arm/boot/dts/tegra20-ventana.dts
+++ b/arch/arm/boot/dts/tegra20-ventana.dts
@@ -608,7 +608,7 @@
 		nvidia,int-mic-en-gpios = <&gpio 184 0>; /* gpio PX0 */
 		nvidia,ext-mic-en-gpios = <&gpio 185 0>; /* gpio PX1 */
 
-		clocks = <&tegra_car 112>, <&tegra_car 113>, <&tegra_car 93>;
+		clocks = <&tegra_car 112>, <&tegra_car 113>, <&tegra_car 94>;
 		clock-names = "pll_a", "pll_a_out0", "mclk";
 	};
 };
diff --git a/arch/arm/boot/dts/tegra20-whistler.dts b/arch/arm/boot/dts/tegra20-whistler.dts
index 87e2d85..988e2d4 100644
--- a/arch/arm/boot/dts/tegra20-whistler.dts
+++ b/arch/arm/boot/dts/tegra20-whistler.dts
@@ -561,7 +561,7 @@
 		nvidia,i2s-controller = <&tegra_i2s1>;
 		nvidia,audio-codec = <&codec>;
 
-		clocks = <&tegra_car 112>, <&tegra_car 113>, <&tegra_car 93>;
+		clocks = <&tegra_car 112>, <&tegra_car 113>, <&tegra_car 94>;
 		clock-names = "pll_a", "pll_a_out0", "mclk";
 	};
 };
diff --git a/arch/arm/boot/dts/tegra20.dtsi b/arch/arm/boot/dts/tegra20.dtsi
index 26c1134..b788950 100644
--- a/arch/arm/boot/dts/tegra20.dtsi
+++ b/arch/arm/boot/dts/tegra20.dtsi
@@ -476,7 +476,7 @@
 		compatible = "nvidia,tegra20-usb-phy";
 		reg = <0xc5004400 0x3c00>;
 		phy_type = "ulpi";
-		clocks = <&tegra_car 94>, <&tegra_car 127>;
+		clocks = <&tegra_car 93>, <&tegra_car 127>;
 		clock-names = "phy", "pll_u";
 	};
 
diff --git a/drivers/clk/tegra/clk-tegra20.c b/drivers/clk/tegra/clk-tegra20.c
index b020beb..b324d3f 100644
--- a/drivers/clk/tegra/clk-tegra20.c
+++ b/drivers/clk/tegra/clk-tegra20.c
@@ -236,7 +236,7 @@ enum tegra20_clk {
 	dvc, dsi, mipi = 50, hdmi, csi, tvdac, i2c2, uartc, emc = 57, usb2,
 	usb3, mpe, vde, bsea, bsev, speedo, uartd, uarte, i2c3, sbc4, sdmmc3,
 	pex, owr, afi, csite, pcie_xclk, avpucq = 75, la, irama = 84, iramb,
-	iramc, iramd, cram2, audio_2x, clk_d, csus = 92, cdev1, cdev2,
+	iramc, iramd, cram2, audio_2x, clk_d, csus = 92, cdev2, cdev1,
 	uartb = 96, vfir, spdif_in, spdif_out, vi, vi_sensor, tvo, cve,
 	osc, clk_32k, clk_m, sclk, cclk, hclk, pclk, blink, pll_a, pll_a_out0,
 	pll_c, pll_c_out1, pll_d, pll_d_out0, pll_e, pll_m, pll_m_out1,
diff --git a/drivers/clk/tegra/clk-tegra30.c b/drivers/clk/tegra/clk-tegra30.c
index a0c54ad..0681935 100644
--- a/drivers/clk/tegra/clk-tegra30.c
+++ b/drivers/clk/tegra/clk-tegra30.c
@@ -329,7 +329,7 @@ enum tegra30_clk {
 	usb3, mpe, vde, bsea, bsev, speedo, uartd, uarte, i2c3, sbc4, sdmmc3,
 	pcie, owr, afi, csite, pciex, avpucq, la, dtv = 79, ndspeed, i2cslow,
 	dsib, irama = 84, iramb, iramc, iramd, cram2, audio_2x = 90, csus = 92,
-	cdev1, cdev2, cpu_g = 96, cpu_lp, gr3d2, mselect, tsensor, i2s3, i2s4,
+	cdev2, cdev1, cpu_g = 96, cpu_lp, gr3d2, mselect, tsensor, i2s3, i2s4,
 	i2c4, sbc5, sbc6, d_audio, apbif, dam0, dam1, dam2, hda2codec_2x,
 	atomics, audio0_2x, audio1_2x, audio2_2x, audio3_2x, audio4_2x,
 	spdif_2x, actmon, extern1, extern2, extern3, sata_oob, sata, hda,
-- 
1.7.4.1



From pgaikwad at nvidia.com  Thu Apr  4 05:05:33 2013
From: pgaikwad at nvidia.com (Prashant Gaikwad)
Date: Thu, 4 Apr 2013 14:35:33 +0530
Subject: [PATCH] clk: tegra: Add missing cdev1 and cdev2 clocks
Message-ID: <1365066333-2361-1-git-send-email-pgaikwad@nvidia.com>

Register cdev1 and cdev2 peripheral clocks.

Signed-off-by: Prashant Gaikwad <pgaikwad at nvidia.com>
---
 drivers/clk/tegra/clk-tegra30.c |   18 ++++++++++++++++++
 1 files changed, 18 insertions(+), 0 deletions(-)

diff --git a/drivers/clk/tegra/clk-tegra30.c b/drivers/clk/tegra/clk-tegra30.c
index 0681935..0e362ea 100644
--- a/drivers/clk/tegra/clk-tegra30.c
+++ b/drivers/clk/tegra/clk-tegra30.c
@@ -1591,6 +1591,24 @@ static void __init tegra30_periph_clk_init(void)
 	clk_register_clkdev(clk, "afi", "tegra-pcie");
 	clks[afi] = clk;
 
+	/* cdev1 */
+	clk = clk_register_fixed_rate(NULL, "cdev1_fixed", NULL, CLK_IS_ROOT,
+				      26000000);
+	clk = tegra_clk_register_periph_gate("cdev1", "cdev1_fixed", 0,
+				    clk_base, 0, 94, &periph_u_regs,
+				    periph_clk_enb_refcnt);
+	clk_register_clkdev(clk, "cdev1", NULL);
+	clks[cdev1] = clk;
+
+	/* cdev2 */
+	clk = clk_register_fixed_rate(NULL, "cdev2_fixed", NULL, CLK_IS_ROOT,
+				      26000000);
+	clk = tegra_clk_register_periph_gate("cdev2", "cdev2_fixed", 0,
+				    clk_base, 0, 93, &periph_u_regs,
+				    periph_clk_enb_refcnt);
+	clk_register_clkdev(clk, "cdev2", NULL);
+	clks[cdev2] = clk;
+
 	/* kfuse */
 	clk = tegra_clk_register_periph_gate("kfuse", "clk_m",
 				    TEGRA_PERIPH_ON_APB,
-- 
1.7.4.1



From pgaikwad at nvidia.com  Thu Apr  4 05:05:51 2013
From: pgaikwad at nvidia.com (Prashant Gaikwad)
Date: Thu, 4 Apr 2013 14:35:51 +0530
Subject: [PATCH] clk: tegra: Use common of_clk_init() function
Message-ID: <1365066351-2395-1-git-send-email-pgaikwad@nvidia.com>

Use common of_clk_init() function for clocks initialization.

Signed-off-by: Prashant Gaikwad <pgaikwad at nvidia.com>
---

Stephen, if T114 clock series is not going to make in 3.10 then I would
like Mike to take this patch. If T114 clock series makes it then I have
to rebase this patch on top of it.

---
 arch/arm/mach-tegra/common.c    |    4 ++--
 drivers/clk/tegra/clk-tegra20.c |    3 ++-
 drivers/clk/tegra/clk-tegra30.c |    3 ++-
 drivers/clk/tegra/clk.c         |   11 -----------
 drivers/clk/tegra/clk.h         |   12 ------------
 include/linux/clk/tegra.h       |    1 -
 6 files changed, 6 insertions(+), 28 deletions(-)

diff --git a/arch/arm/mach-tegra/common.c b/arch/arm/mach-tegra/common.c
index 7cc7563..1947de8 100644
--- a/arch/arm/mach-tegra/common.c
+++ b/arch/arm/mach-tegra/common.c
@@ -23,7 +23,7 @@
 #include <linux/clk.h>
 #include <linux/delay.h>
 #include <linux/irqchip.h>
-#include <linux/clk/tegra.h>
+#include <linux/clk-provider.h>
 
 #include <asm/hardware/cache-l2x0.h>
 
@@ -58,7 +58,7 @@ u32 tegra_uart_config[4] = {
 #ifdef CONFIG_OF
 void __init tegra_dt_init_irq(void)
 {
-	tegra_clocks_init();
+	of_clk_init(NULL);
 	tegra_init_irq();
 	irqchip_init();
 }
diff --git a/drivers/clk/tegra/clk-tegra20.c b/drivers/clk/tegra/clk-tegra20.c
index b324d3f..e0565e6 100644
--- a/drivers/clk/tegra/clk-tegra20.c
+++ b/drivers/clk/tegra/clk-tegra20.c
@@ -1270,7 +1270,7 @@ static const struct of_device_id pmc_match[] __initconst = {
 	{},
 };
 
-void __init tegra20_clock_init(struct device_node *np)
+static void __init tegra20_clock_init(struct device_node *np)
 {
 	int i;
 	struct device_node *node;
@@ -1322,3 +1322,4 @@ void __init tegra20_clock_init(struct device_node *np)
 
 	tegra_cpu_car_ops = &tegra20_cpu_car_ops;
 }
+CLK_OF_DECLARE(tegra20, "nvidia,tegra20-car", tegra20_clock_init);
diff --git a/drivers/clk/tegra/clk-tegra30.c b/drivers/clk/tegra/clk-tegra30.c
index 0e362ea..77dd080 100644
--- a/drivers/clk/tegra/clk-tegra30.c
+++ b/drivers/clk/tegra/clk-tegra30.c
@@ -1959,7 +1959,7 @@ static const struct of_device_id pmc_match[] __initconst = {
 	{},
 };
 
-void __init tegra30_clock_init(struct device_node *np)
+static void __init tegra30_clock_init(struct device_node *np)
 {
 	struct device_node *node;
 	int i;
@@ -2010,3 +2010,4 @@ void __init tegra30_clock_init(struct device_node *np)
 
 	tegra_cpu_car_ops = &tegra30_cpu_car_ops;
 }
+CLK_OF_DECLARE(tegra30, "nvidia,tegra30-car", tegra30_clock_init);
diff --git a/drivers/clk/tegra/clk.c b/drivers/clk/tegra/clk.c
index a603b9a..ce4441a 100644
--- a/drivers/clk/tegra/clk.c
+++ b/drivers/clk/tegra/clk.c
@@ -72,14 +72,3 @@ void __init tegra_init_from_table(struct tegra_clk_init_table *tbl,
 			}
 	}
 }
-
-static const struct of_device_id tegra_dt_clk_match[] = {
-	{ .compatible = "nvidia,tegra20-car", .data = tegra20_clock_init },
-	{ .compatible = "nvidia,tegra30-car", .data = tegra30_clock_init },
-	{ }
-};
-
-void __init tegra_clocks_init(void)
-{
-	of_clk_init(tegra_dt_clk_match);
-}
diff --git a/drivers/clk/tegra/clk.h b/drivers/clk/tegra/clk.h
index a09d7dc..35a04d8 100644
--- a/drivers/clk/tegra/clk.h
+++ b/drivers/clk/tegra/clk.h
@@ -498,16 +498,4 @@ void tegra_init_from_table(struct tegra_clk_init_table *tbl,
 void tegra_init_dup_clks(struct tegra_clk_duplicate *dup_list,
 		struct clk *clks[], int clk_max);
 
-#ifdef CONFIG_ARCH_TEGRA_2x_SOC
-void tegra20_clock_init(struct device_node *np);
-#else
-static inline void tegra20_clock_init(struct device_node *np) {}
-#endif /* CONFIG_ARCH_TEGRA_2x_SOC */
-
-#ifdef CONFIG_ARCH_TEGRA_3x_SOC
-void tegra30_clock_init(struct device_node *np);
-#else
-static inline void tegra30_clock_init(struct device_node *np) {}
-#endif /* CONFIG_ARCH_TEGRA_3x_SOC */
-
 #endif /* TEGRA_CLK_H */
diff --git a/include/linux/clk/tegra.h b/include/linux/clk/tegra.h
index 404d6f9..2e8b399 100644
--- a/include/linux/clk/tegra.h
+++ b/include/linux/clk/tegra.h
@@ -122,6 +122,5 @@ static inline void tegra_cpu_clock_resume(void)
 
 void tegra_periph_reset_deassert(struct clk *c);
 void tegra_periph_reset_assert(struct clk *c);
-void tegra_clocks_init(void);
 
 #endif /* __LINUX_CLK_TEGRA_H_ */
-- 
1.7.4.1



From nsekhar at ti.com  Thu Apr  4 05:17:56 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Thu, 4 Apr 2013 14:47:56 +0530
Subject: [PATCH v7 1/2] ARM: davinci: dm355: add support for v4l2 video
 display
In-Reply-To: <1364908504-14232-2-git-send-email-prabhakar.csengg@gmail.com>
References: <1364908504-14232-1-git-send-email-prabhakar.csengg@gmail.com>
 <1364908504-14232-2-git-send-email-prabhakar.csengg@gmail.com>
Message-ID: <515D4544.6000604@ti.com>

On 4/2/2013 6:45 PM, Prabhakar lad wrote:
> From: Lad, Prabhakar <prabhakar.csengg at gmail.com>
> 
> Create platform devices for various video modules like venc,osd,
> vpbe and v4l2 driver for dm355.
> 
> Signed-off-by: Lad, Prabhakar <prabhakar.csengg at gmail.com>
> ---
>  arch/arm/mach-davinci/board-dm355-evm.c |    4 +-
>  arch/arm/mach-davinci/davinci.h         |    3 +-
>  arch/arm/mach-davinci/dm355.c           |  173 ++++++++++++++++++++++++++++++-
>  3 files changed, 172 insertions(+), 8 deletions(-)
> 
> diff --git a/arch/arm/mach-davinci/board-dm355-evm.c b/arch/arm/mach-davinci/board-dm355-evm.c
> index 147b8e1..37d12cc 100644
> --- a/arch/arm/mach-davinci/board-dm355-evm.c
> +++ b/arch/arm/mach-davinci/board-dm355-evm.c
> @@ -253,8 +253,6 @@ static struct davinci_uart_config uart_config __initdata = {
>  
>  static void __init dm355_evm_map_io(void)
>  {
> -	/* setup input configuration for VPFE input devices */
> -	dm355_set_vpfe_config(&vpfe_cfg);
>  	dm355_init();
>  }
>  
> @@ -344,6 +342,8 @@ static __init void dm355_evm_init(void)
>  	davinci_setup_mmc(0, &dm355evm_mmc_config);
>  	davinci_setup_mmc(1, &dm355evm_mmc_config);
>  
> +	dm355_init_video(&vpfe_cfg, NULL);
> +
>  	dm355_init_spi0(BIT(0), dm355_evm_spi_info,
>  			ARRAY_SIZE(dm355_evm_spi_info));
>  
> diff --git a/arch/arm/mach-davinci/davinci.h b/arch/arm/mach-davinci/davinci.h
> index a9de512..5402592 100644
> --- a/arch/arm/mach-davinci/davinci.h
> +++ b/arch/arm/mach-davinci/davinci.h
> @@ -39,6 +39,7 @@
>  #define SYSMOD_VDAC_CONFIG		0x2c
>  #define SYSMOD_VIDCLKCTL		0x38
>  #define SYSMOD_VPSS_CLKCTL		0x44
> +#define VPSS_MUXSEL_EXTCLK_ENABLE	BIT(1)
>  #define VPSS_VENCCLKEN_ENABLE		BIT(3)
>  #define VPSS_DACCLKEN_ENABLE		BIT(4)
>  #define VPSS_PLLC2SYSCLK5_ENABLE	BIT(5)
> @@ -79,7 +80,7 @@ void __init dm355_init(void);
>  void dm355_init_spi0(unsigned chipselect_mask,
>  		const struct spi_board_info *info, unsigned len);
>  void __init dm355_init_asp1(u32 evt_enable, struct snd_platform_data *pdata);
> -void dm355_set_vpfe_config(struct vpfe_config *cfg);
> +int __init dm355_init_video(struct vpfe_config *, struct vpbe_config *);

Why do this especially after sending a big patch cleaning __init
annotation in function declaration all over mach-davinci?

>  
>  /* DM365 function declarations */
>  void __init dm365_init(void);
> diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
> index 8e98bb0..174ad02 100644
> --- a/arch/arm/mach-davinci/dm355.c
> +++ b/arch/arm/mach-davinci/dm355.c
> @@ -36,6 +36,10 @@
>  
>  #define DM355_UART2_BASE	(IO_PHYS + 0x206000)
>  
> +#define DM355_OSD_BASE			0x01c70200
> +

Drop the empty line here and after DM355_UART2_BASE. And be consistent
and add new definitions as (IO_PHYS + N)?

> +#define DM355_VENC_BASE			0x01c70400
> +
>  /*
>   * Device specific clocks
>   */
> @@ -744,11 +748,150 @@ static struct platform_device vpfe_capture_dev = {
>  	},
>  };
>  
> -void dm355_set_vpfe_config(struct vpfe_config *cfg)
> +static struct resource dm355_osd_resources[] = {
> +	{
> +		.start	= DM355_OSD_BASE,
> +		.end	= DM355_OSD_BASE + 0x17f,
> +		.flags	= IORESOURCE_MEM,
> +	},
> +};
> +
> +static struct platform_device dm355_osd_dev = {
> +	.name		= DM355_VPBE_OSD_SUBDEV_NAME,
> +	.id		= -1,
> +	.num_resources	= ARRAY_SIZE(dm355_osd_resources),
> +	.resource	= dm355_osd_resources,
> +	.dev		= {
> +		.dma_mask		= &vpfe_capture_dma_mask,
> +		.coherent_dma_mask	= DMA_BIT_MASK(32),
> +	},
> +};
> +
> +static struct resource dm355_venc_resources[] = {
> +	{
> +		.start	= IRQ_VENCINT,
> +		.end	= IRQ_VENCINT,
> +		.flags	= IORESOURCE_IRQ,
> +	},
> +	/* venc registers io space */
> +	{
> +		.start	= DM355_VENC_BASE,
> +		.end	= DM355_VENC_BASE + 0x17f,
> +		.flags	= IORESOURCE_MEM,
> +	},
> +	/* VDAC config register io space */
> +	{
> +		.start	= DAVINCI_SYSTEM_MODULE_BASE + SYSMOD_VDAC_CONFIG,
> +		.end	= DAVINCI_SYSTEM_MODULE_BASE + SYSMOD_VDAC_CONFIG + 3,
> +		.flags	= IORESOURCE_MEM,
> +	},
> +};
> +
> +static struct resource dm355_v4l2_disp_resources[] = {
> +	{
> +		.start	= IRQ_VENCINT,
> +		.end	= IRQ_VENCINT,
> +		.flags	= IORESOURCE_IRQ,
> +	},
> +	/* venc registers io space */
> +	{
> +		.start	= DM355_VENC_BASE,
> +		.end	= DM355_VENC_BASE + 0x17f,
> +		.flags	= IORESOURCE_MEM,
> +	},
> +};
> +
> +static int dm355_vpbe_setup_pinmux(enum v4l2_mbus_pixelcode if_type,
> +			    int field)
>  {
> -	vpfe_capture_dev.dev.platform_data = cfg;
> +	switch (if_type) {
> +	case V4L2_MBUS_FMT_SGRBG8_1X8:
> +		davinci_cfg_reg(DM355_VOUT_FIELD_G70);
> +		break;
> +
> +	case V4L2_MBUS_FMT_YUYV10_1X20:
> +		if (field)
> +			davinci_cfg_reg(DM355_VOUT_FIELD);
> +		else
> +			davinci_cfg_reg(DM355_VOUT_FIELD_G70);
> +		break;
> +
> +	default:
> +		return -EINVAL;
> +	}
> +
> +	davinci_cfg_reg(DM355_VOUT_COUTL_EN);
> +	davinci_cfg_reg(DM355_VOUT_COUTH_EN);
> +
> +	return 0;
> +}
> +
> +static int dm355_venc_setup_clock(enum vpbe_enc_timings_type type,
> +				   unsigned int pclock)
> +{
> +	void __iomem *vpss_clk_ctrl_reg;
> +
> +	vpss_clk_ctrl_reg = DAVINCI_SYSMOD_VIRT(SYSMOD_VPSS_CLKCTL);
> +
> +	switch (type) {
> +	case VPBE_ENC_STD:
> +		writel(VPSS_DACCLKEN_ENABLE |
> +		       VPSS_VENCCLKEN_ENABLE, vpss_clk_ctrl_reg);

Please don't break the line in middle of expression. Instead break it
after the first argument completes.

Rest of the patch looks good. Thank you for your patience with this.

Regards,
Sekhar


From nsekhar at ti.com  Thu Apr  4 05:20:13 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Thu, 4 Apr 2013 14:50:13 +0530
Subject: [PATCH v7 2/2] ARM: davinci: dm355 EVM: add support for VPBE
 display
In-Reply-To: <1364908504-14232-3-git-send-email-prabhakar.csengg@gmail.com>
References: <1364908504-14232-1-git-send-email-prabhakar.csengg@gmail.com>
 <1364908504-14232-3-git-send-email-prabhakar.csengg@gmail.com>
Message-ID: <515D45CD.6000407@ti.com>

On 4/2/2013 6:45 PM, Prabhakar lad wrote:
> From: Lad, Prabhakar <prabhakar.csengg at gmail.com>
> 
> add support for V4L2 video display to DM355 EVM.
> Support for SD modes is provided, along with Composite
> output
> 
> Signed-off-by: Lad, Prabhakar <prabhakar.csengg at gmail.com>

Looks good. Since you mentioned that you will take this through media
tree to manage driver dependencies, please add:

Acked-by: Sekhar Nori <nsekhar at ti.com>

Thanks,
Sekhar


From ezequiel.garcia at free-electrons.com  Thu Apr  4 05:16:40 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Thu, 4 Apr 2013 06:16:40 -0300
Subject: [RFCv1 00/11] MSI support for Marvell EBU PCIe driver
In-Reply-To: <1364316746-8702-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1364316746-8702-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <20130404091639.GA2245@localhost>

Thomas,

On Tue, Mar 26, 2013 at 05:52:15PM +0100, Thomas Petazzoni wrote:
> 
> This set of patches introduces Message Signaled Interrupt support in
> the Marvell EBU PCIe driver. It has been successfully tested on the
> Armada XP GP platform and the Armada 370 DB platform with an Intel
> e1000e PCIe network card that supports MSI.
> 
> This is based on work done by Lior Amsalem <alior at marvell.com>.
> 
> The patches do the following:
> 
>  * Patches 1, 2 and 3 move the IRQ controller driver of Armada 370/XP
>    platforms from arch/arm/mach-mvebu/ into drivers/irqchip/ and use
>    the proper irqchip infrastructure. Those changes are not strictly
>    needed to add MSI interrupts support, but since we will be touching
>    the IRQ controller driver anyway, it sounded like the right time to
>    do this move.
> 

Given the IRQ controller move to drivers/irqchip is independent of MSI
work, and that we've already agreed this move is fine (Arnd has acked
patch 2), may I suggest that you resend these three first patches
(and perhaps the fourth?) as a separate patchset to be included in v3.10.

This has the advantage that further development on IRQ controller can be
done directly on its proper place, and also the MSI patchset can be
simplified.

What do you think?
-- 
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com


From kishon at ti.com  Thu Apr  4 05:21:51 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Thu, 4 Apr 2013 14:51:51 +0530
Subject: [PATCH v5 1/6] drivers: phy: add generic PHY framework
In-Reply-To: <515CA337.1010504@gmail.com>
References: <1364993634-6378-1-git-send-email-kishon@ti.com>
 <1364993634-6378-2-git-send-email-kishon@ti.com> <515CA337.1010504@gmail.com>
Message-ID: <515D462F.9050109@ti.com>

Hi,

On Thursday 04 April 2013 03:16 AM, Sylwester Nawrocki wrote:
> On 04/03/2013 02:53 PM, Kishon Vijay Abraham I wrote:
.
.
<snip>
.
.
>> diff --git a/Documentation/phy.txt b/Documentation/phy.txt
>> new file mode 100644
>> index 0000000..7785ec0
>> --- /dev/null
>> +++ b/Documentation/phy.txt
>> @@ -0,0 +1,113 @@
>> +                PHY SUBSYSTEM
>> +          Kishon Vijay Abraham I<kishon at ti.com>
>> +
>> +This document explains the Generic PHY Framework along with the APIs
>> provided,
>> +and how-to-use.
>> +
>> +1. Introduction
>> +
>> +*PHY* is the abbreviation for physical layer. It is used to connect a
>> device
>> +to the physical medium e.g., the USB controller has a PHY to provide
>> functions
>
> Shouldn't it be "...medium, e.g. the USB..." ?
>
>> +such as serialization, de-serialization, encoding, decoding and is
>> responsible
>> +for obtaining the required data transmission rate. Note that some USB
>> +controller has PHY functionality embedded into it and others use an
>> external
>
> "controllers have PHY functionality embedded into them" ?
>
>> +PHY. Other peripherals that uses a PHY include Wireless LAN, Ethernet,
>
> s/uses/use ?
>
>> +SATA etc.
>> +
>> +The intention of creating this framework is to bring the phy drivers
>> spread
>> +all over the Linux kernel to drivers/phy to increase code re-use and to
>> +increase code maintainability.
>> +
>> +This framework will be of use only to devices that uses external PHY
>> (PHY
>
> s/uses/use ?
>
>> +functionality is not embedded within the controller).
>> +
>> +2. Creating the PHY
>> +
>> +The PHY driver should create the PHY in order for other peripheral
>> controllers
>> +to make use of it. The PHY framework provides 2 APIs to create the PHY.
>> +
>> +struct phy *phy_create(struct device *dev, const char *label,
>> +    struct device_node *of_node, int type, struct phy_ops *ops,
>> +    void *priv);
>> +struct phy *devm_phy_create(struct device *dev, const char *label,
>> +    struct device_node *of_node, int type, struct phy_ops *ops,
>> +    void *priv);
>> +
>> +The PHY drivers can use one of the above 2 APIs to create the PHY by
>> passing
>> +the device pointer, label, device node, type, phy ops and a driver data.
>> +phy_ops is a set of function pointers for performing PHY operations
>> such as
>> +init, exit, suspend, resume, power_on and power_off.
>> +
>> +3. Binding the PHY to the controller
>> +
>> +The framework provides an API for binding the controller to the PHY
>> in the
>> +case of non dt boot.
>> +
>> +struct phy_bind *phy_bind(const char *dev_name, int index,
>> +                const char *phy_dev_name);
>> +
>> +The API fills the phy_bind structure with the dev_name (device name
>> of the
>> +controller), index and phy_dev_name (device name of the PHY). This will
>> +be used when the controller requests this phy. This API should be
>> used by
>> +platform specific initialization code (board file).
>> +
>> +In the case of dt boot, the binding information should be added in
>> the dt
>> +data of the controller.
>
> s/in the dt data of/in the device tree node of ?
>
>> +4. Getting a reference to the PHY
>> +
>> +Before the controller can make use of the PHY, it has to get a
>> reference to
>> +it. This framework provides 6 APIs to get a reference to the PHY.
>> +
>> +struct phy *phy_get(struct device *dev, int index);
>> +struct phy *devm_phy_get(struct device *dev, int index);
>> +struct phy *of_phy_get(struct device *dev, const char *phandle, int
>> index);
>> +struct phy *devm_of_phy_get(struct device *dev, const char *phandle,
>> int index);
>
> Why do we need separate functions for dt and non-dt ? Couldn't it be
> handled
> internally by the framework ? So the PHY users can use same calls for dt
> and non-dt, like in case of e.g. the regulators API ?

yeah. Indeed it makes sense to do it that way.
>
> Also signatures of some functions are different now:
>
> extern struct phy *phy_get(struct device *dev, int index);
> extern struct phy *devm_phy_get(struct device *dev, int index);
> extern struct phy *of_phy_get(struct device *dev, int index);
> extern struct phy *devm_of_phy_get(struct device *dev, int index);

My bad :-(

>
> BTW, I think "extern" could be dropped, does it have any significance in
> function declarations in header files ?

it shouldn't have any effect I guess. It's harmless nevertheless.

>
>> +struct phy *of_phy_get_byname(struct device *dev, const char *string);
>> +struct phy *devm_of_phy_get_byname(struct device *dev, const char
>> *string);
>> +
>> +phy_get and devm_phy_get can be used to get the PHY in non-dt boot.
>> This API
>> +uses the binding information added using the phy_bind API to find and
>> return
>> +the appropriate PHY. The only difference between the two APIs is that
>> +devm_phy_get associates the device with the PHY using devres on
>> successful PHY
>> +get. On driver detach, release function is invoked on the the devres
>> data and
>
> s/the the/the
>
>> +devres data is freed.
>> +
>> +of_phy_get and devm_of_phy_get can be used to get the PHY in dt boot.
>> These
>> +APIs take the phandle and index to get a reference to the PHY. The only
>> +difference between the two APIs is that devm_of_phy_get associates
>> the device
>> +with the PHY using devres on successful phy get. On driver detach,
>> release
>> +function is invoked on the devres data and it is freed.
>> +
>> +of_phy_get_byname and devm_of_phy_get_byname can also be used to get
>> the PHY
>> +in dt boot. It is same as the above API except that the user has to
>> pass the
>> +phy name as filled in "phy-names" phandle in dt data and the
>> framework will
>
> s/phandle/property ?
>
>> +find the index and get the PHY.
>> +
>> +5. Releasing a reference to the PHY
>> +
>> +When the controller no longer needs the PHY, it has to release the
>> reference
>> +to the PHY it has obtained using the APIs mentioned in the above
>> section. The
>> +PHY framework provides 2 APIS to release a reference to the PHY.
>
> s/APIS/APIs ?
>
>> +
>> +void phy_put(struct phy *phy);
>> +void devm_phy_put(struct device *dev, struct phy *phy);
>> +
>> +Both these APIs are used to release a reference to the PHY and
>> devm_phy_put
>> +destroys the devres associated with this PHY.
>> +
>> +6. Destroying the PHY
>> +
>> +When the driver that created the PHY is unloaded, it should destroy
>> the PHY it
>> +created using one of the following 2 APIs.
>> +
>> +void phy_destroy(struct phy *phy);
>> +void devm_phy_destroy(struct device *dev, struct phy *phy);
>> +
>> +Both these APIs destroys the PHY and devm_phy_destroy destroys the
>> devres
>
> s/APIs destroys/APIs destroy ?
>
>> +associated with this PHY.
>> +
>> +7. DeviceTree Binding
>> +
>> +The documentation for PHY dt binding can be found @
>> +Documentation/devicetree/bindings/phy/phy-bindings.txt
>
>> --- /dev/null
>> +++ b/drivers/phy/phy-core.c
>> @@ -0,0 +1,616 @@
>
>> +static struct phy *of_phy_lookup(struct device_node *node)
>> +{
>> +    struct phy *phy;
>> +    struct device *dev;
>> +    struct class_dev_iter iter;
>> +
>> +    class_dev_iter_init(&iter, phy_class, NULL, NULL);
>
> There is currently nothing preventing a call to this function before
> phy_class is initialized. It happened during my tests, and the nice
> stack dump showed that it was the PHY user attempting to get the PHY
> before the framework got initialized. So either phy_core_init should
> be a subsys_initcall or we need a better protection against phy_class
> being NULL or ERR_PTR in more places.

Whats the initcall used in your PHY user? Looks like more people prefer 
having module_init and any issue because of it should be fixed in PHY 
providers and PHY users.
>
>> +    while ((dev = class_dev_iter_next(&iter))) {
>> +        phy = container_of(dev, struct phy, dev);
>> +        if (node != phy->of_node)
>> +            continue;
>> +
>> +        class_dev_iter_exit(&iter);
>> +        return phy;
>> +    }
>> +
>> +    class_dev_iter_exit(&iter);
>> +    return ERR_PTR(-EPROBE_DEFER);
>> +}
>
>> +/**
>> + * of_phy_get() - lookup and obtain a reference to a phy by phandle
>> + * @dev: device that requests this phy
>> + * @index: the index of the phy
>> + *
>> + * Returns the phy associated with the given phandle value,
>> + * after getting a refcount to it or -ENODEV if there is no such phy or
>> + * -EPROBE_DEFER if there is a phandle to the phy, but the device is
>> + * not yet loaded.
>> + */
>> +struct phy *of_phy_get(struct device *dev, int index)
>> +{
>> +    int ret;
>> +    struct phy *phy = NULL;
>> +    struct phy_bind *phy_map = NULL;
>> +    struct of_phandle_args args;
>> +    struct device_node *node;
>> +
>> +    if (!dev->of_node) {
>> +        dev_dbg(dev, "device does not have a device node entry\n");
>> +        return ERR_PTR(-EINVAL);
>> +    }
>> +
>> +    ret = of_parse_phandle_with_args(dev->of_node, "phys", "#phy-cells",
>> +        index,&args);
>> +    if (ret) {
>> +        dev_dbg(dev, "failed to get phy in %s node\n",
>> +            dev->of_node->full_name);
>> +        return ERR_PTR(-ENODEV);
>> +    }
>> +
>> +    phy = of_phy_lookup(args.np);
>> +    if (IS_ERR(phy) || !try_module_get(phy->ops->owner)) {
>> +        phy = ERR_PTR(-EPROBE_DEFER);
>> +        goto err0;
>> +    }
>> +
>> +    phy = phy->ops->of_xlate(phy,&args);
>> +    if (IS_ERR(phy))
>> +        goto err1;
>> +
>> +    phy_map = phy_bind(dev_name(dev), index, dev_name(&phy->dev));
>> +    if (!IS_ERR(phy_map)) {
>> +        phy_map->phy = phy;
>> +        phy_map->auto_bind = true;
>
> Shouldn't it be done with the phy_bind_mutex held ? I guess an unlocked
> version of the phy_bind functions is needed, so it can be used internally.

The locking is done inside phy_bind function. I'm not sure but I vaguely 
remember getting a dump stack (incorrect mutex ordering or something) 
when trying to have phy_bind_mutex here. I can check it again.
>
>> +    }
>> +
>> +    get_device(&phy->dev);
>> +
>> +err1:
>> +    module_put(phy->ops->owner);
>> +
>> +err0:
>> +    of_node_put(node);
>> +
>> +    return phy;
>> +}
>> +EXPORT_SYMBOL_GPL(of_phy_get);
>
>> +/**
>> + * phy_create() - create a new phy
>> + * @dev: device that is creating the new phy
>> + * @label: label given to phy
>> + * @of_node: device node of the phy
>> + * @type: specifies the phy type
>> + * @ops: function pointers for performing phy operations
>> + * @priv: private data from phy driver
>> + *
>> + * Called to create a phy using phy framework.
>> + */
>> +struct phy *phy_create(struct device *dev, const char *label,
>> +    struct device_node *of_node, int type, struct phy_ops *ops,
>> +    void *priv)
>> +{
>> +    int ret;
>> +    struct phy *phy;
>> +    struct phy_bind *phy_bind;
>> +    const char *devname = NULL;
>> +
>> +    if (!dev) {
>> +        dev_err(dev, "no device provided for PHY\n");
>> +        ret = -EINVAL;
>> +        goto err0;
>> +    }
>> +
>> +    if (!ops || !ops->of_xlate || !priv) {
>> +        dev_err(dev, "no PHY ops/PHY data provided\n");
>> +        ret = -EINVAL;
>> +        goto err0;
>> +    }
>> +
>> +    if (!phy_class)
>> +        phy_core_init();
>> +
>> +    phy = kzalloc(sizeof(*phy), GFP_KERNEL);
>> +    if (!phy) {
>> +        ret = -ENOMEM;
>> +        goto err0;
>> +    }
>> +
>> +    devname = dev_name(dev);
>
> OK, a sort of serious issue here is that you can't call phy_create()
> multiple times for same PHY provider device.

Ah.. right.
>
> device_add() further will fail as sysfs won't let you create multiple
> objects with same name. So I would assume we need to add a new argument
> to phy_create() or rename @type to e.g. @phy_id, which could be
> concatenated with dev_name(dev) to create a unique name of the phy
> device.

hmm.. ok
>
> And how is the PHY provider supposed to identify a PHY in its common PHY
> ops, now when the struct phy port field is removed ? I have temporarily
> (ab)used the type field in order to select proper registers within the
> phy ops.

Can't it be handled in the PHY provider driver without using struct phy 
*? Moreover the PHY ops passes on the *phy to phy provider right? Not 
sure I understand you here.
>
>> +    device_initialize(&phy->dev);
>> +
>> +    phy->dev.class = phy_class;
>> +    phy->dev.parent = dev;
>> +    phy->label = label;
>
> What about duplicating the string here ? That would make the API a bit
> more convenient and the callers wouldn't be required to keep all the
> labels around.

you mean use dev_name? The device names are sometime more cryptic so 
preferred to have it like this.
>
>> +    phy->of_node = of_node;
>> +    phy->type = type;
>> +    phy->ops = ops;
>> +
>> +    dev_set_drvdata(&phy->dev, priv);
>> +
>> +    ret = dev_set_name(&phy->dev, "%s", devname);
>> +    if (ret)
>> +        goto err1;
>> +
>> +    mutex_lock(&phy_bind_mutex);
>> +    list_for_each_entry(phy_bind,&phy_bind_list, list)
>> +        if (!(strcmp(phy_bind->phy_dev_name, devname)))
>> +            phy_bind->phy = phy;
>> +    mutex_unlock(&phy_bind_mutex);
>> +
>> +    ret = device_add(&phy->dev);
>> +    if (ret)
>> +        goto err2;
>> +
>> +    return phy;
>> +
>> +err2:
>> +    phy_bind->phy = NULL;
>> +
>> +err1:
>> +    put_device(&phy->dev);
>> +    kfree(phy);
>> +
>> +err0:
>> +    return ERR_PTR(ret);
>> +}
>> +EXPORT_SYMBOL_GPL(phy_create);
>
>> +/**
>> + * devm_phy_create() - create a new phy
>> + * @dev: device that is creating the new phy
>> + * @dev: device that is creating the new phy
>
> Duplicated line.
>
>> + * @label: label given to phy
>> + * @of_node: device node of the phy
>> + * @type: specifies the phy type
>> + * @ops: function pointers for performing phy operations
>> + * @priv: private data from phy driver
>> + *
>> + * Creates a new PHY device adding it to the PHY class.
>> + * While at that, it also associates the device with the phy using
>> devres.
>> + * On driver detach, release function is invoked on the devres data,
>> + * then, devres data is freed.
>> + */
>
>> +/**
>> + * phy_bind() - bind the phy and the controller that uses the phy
>> + * @dev_name: the device name of the device that will bind to the phy
>> + * @index: index to specify the port number
>> + * @phy_dev_name: the device name of the phy
>> + *
>> + * Fills the phy_bind structure with the dev_name and phy_dev_name.
>> This will
>> + * be used when the phy driver registers the phy and when the controller
>> + * requests this phy.
>> + *
>> + * To be used by platform specific initialization code.
>> + */
>> +struct phy_bind *phy_bind(const char *dev_name, int index,
>> +                const char *phy_dev_name)
>> +{
>> +    struct phy_bind *phy_bind;
>> +
>> +    mutex_lock(&phy_bind_mutex);
>> +    list_for_each_entry(phy_bind,&phy_bind_list, list) {
>> +        if (!strcmp(phy_bind->dev_name, dev_name)&&  phy_bind->index ==
>> +            index) {
>> +            phy_bind->phy_dev_name = phy_dev_name;
>> +            goto ret0;
>> +        }
>> +    }
>> +
>> +    phy_bind = kzalloc(sizeof(*phy_bind), GFP_KERNEL);
>> +    if (!phy_bind) {
>> +        phy_bind = ERR_PTR(-ENOMEM);
>> +        goto ret0;
>> +    }
>> +
>> +    phy_bind->dev_name = dev_name;
>> +    phy_bind->phy_dev_name = phy_dev_name;
>> +    phy_bind->index = index;
>> +    phy_bind->auto_bind = false;
>> +
>> +    list_add_tail(&phy_bind->list,&phy_bind_list);
>> +
>> +ret0:
>> +    mutex_unlock(&phy_bind_mutex);
>> +    return phy_bind;
>> +}
>> +EXPORT_SYMBOL_GPL(phy_bind);
>
>> +static ssize_t phy_bind_show(struct device *dev,
>> +                 struct device_attribute *attr, char *buf)
>> +{
>> +    struct phy_bind *phy_bind;
>> +    struct phy *phy;
>> +    char *p = buf;
>> +    int len;
>> +
>> +    phy = container_of(dev, struct phy, dev);
>> +
>
> Shouldn't this iteration also be protected with the phy_bind_mutex ?

Indeed.
>
>> +    list_for_each_entry(phy_bind,&phy_bind_list, list)
>> +        if (phy_bind->phy == phy)
>> +            p += sprintf(p, "%s %d %s\n", phy_bind->dev_name,
>> +                phy_bind->index, phy_bind->phy_dev_name);
>> +    len = (p - buf);
>> +
>> +    return len;
>> +}
>
>> +static int phy_core_init(void)
>> +{
>> +    if (phy_class)
>> +        return 0;
>> +
>> +    phy_class = class_create(THIS_MODULE, "phy");
>> +    if (IS_ERR(phy_class)) {
>> +        pr_err("failed to create phy class -->  %ld\n",
>> +            PTR_ERR(phy_class));
>> +        return PTR_ERR(phy_class);
>> +    }
>> +
>> +    phy_class->dev_release = phy_release;
>> +    phy_class->dev_attrs = phy_dev_attrs;
>> +
>> +    return 0;
>> +}
>> +module_init(phy_core_init);
>
> Having this framework initialized before the PHY provider and consumer
> drivers could save some unnecessary probe deferrals. I was wondering,
> what is really an advantage of having it as module_init(), rather than
> subsys_initcall() ?

I'm not sure of the exact reason but after the advent of EPROBE_DEFER, 
everyone recommends to use module_init only.

Thanks for the detailed review.

Regards
Kishon


From s.hauer at pengutronix.de  Thu Apr  4 05:25:03 2013
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Thu,  4 Apr 2013 11:25:03 +0200
Subject: [PATCH] i.MX PATA cleanup and i.MX51 support
Message-ID: <1365067509-10186-1-git-send-email-s.hauer@pengutronix.de>

The following contains some cleanup and devicetree support for the
i.MX PATA driver. Also i.MX51 PATA support is added.

The first four patches should go via the ata tree, the others through
arm-soc, they do not depend on each other.

Sascha

----------------------------------------------------------------
Sascha Hauer (6):
      ata: i.MX PATA: Use devm_clk_get
      ata: i.MX PATA: cleanup error path
      ata: i.MX PATA: use void __iomem * for regs
      ata: i.MX PATA: add devicetree support
      ARM: i.MX5: Add PATA and SRTC clocks
      ARM: i.MX51: Add PATA support

 Documentation/devicetree/bindings/ata/imx-pata.txt | 17 +++++++++
 .../devicetree/bindings/clock/imx5-clock.txt       |  2 +
 arch/arm/boot/dts/imx51.dtsi                       | 44 ++++++++++++++++++++++
 arch/arm/mach-imx/clk-imx51-imx53.c                |  4 +-
 drivers/ata/pata_imx.c                             | 36 +++++++++++++-----
 5 files changed, 92 insertions(+), 11 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/ata/imx-pata.txt


From s.hauer at pengutronix.de  Thu Apr  4 05:25:06 2013
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Thu,  4 Apr 2013 11:25:06 +0200
Subject: [PATCH 3/6] ata: i.MX PATA: use void __iomem * for regs
In-Reply-To: <1365067509-10186-1-git-send-email-s.hauer@pengutronix.de>
References: <1365067509-10186-1-git-send-email-s.hauer@pengutronix.de>
Message-ID: <1365067509-10186-4-git-send-email-s.hauer@pengutronix.de>

regs is returned from ioremap, so add a __iomem. Also, make it
void * instead of u8 *.

Signed-off-by: Sascha Hauer <s.hauer at pengutronix.de>
---
 drivers/ata/pata_imx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/ata/pata_imx.c b/drivers/ata/pata_imx.c
index f243496..adbb01d 100644
--- a/drivers/ata/pata_imx.c
+++ b/drivers/ata/pata_imx.c
@@ -37,7 +37,7 @@
 struct pata_imx_priv {
 	struct clk *clk;
 	/* timings/interrupt/control regs */
-	u8 *host_regs;
+	void __iomem *host_regs;
 	u32 ata_ctl;
 };
 
-- 
1.8.2.rc2



From s.hauer at pengutronix.de  Thu Apr  4 05:25:09 2013
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Thu,  4 Apr 2013 11:25:09 +0200
Subject: [PATCH 6/6] ARM: i.MX51: Add PATA support
In-Reply-To: <1365067509-10186-1-git-send-email-s.hauer@pengutronix.de>
References: <1365067509-10186-1-git-send-email-s.hauer@pengutronix.de>
Message-ID: <1365067509-10186-7-git-send-email-s.hauer@pengutronix.de>

This adds the PATA device and the pinctrl group for to the i.MX51 dts.

Signed-off-by: Sascha Hauer <s.hauer at pengutronix.de>
---
 arch/arm/boot/dts/imx51.dtsi | 44 ++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 44 insertions(+)

diff --git a/arch/arm/boot/dts/imx51.dtsi b/arch/arm/boot/dts/imx51.dtsi
index fcf035b..cc54f0d 100644
--- a/arch/arm/boot/dts/imx51.dtsi
+++ b/arch/arm/boot/dts/imx51.dtsi
@@ -411,6 +411,42 @@
 					};
 				};
 
+				pata {
+					pinctrl_pata_1: patagrp-1 {
+						fsl,pins = <
+							MX51_PAD_NANDF_WE_B__PATA_DIOW		0x2004
+							MX51_PAD_NANDF_RE_B__PATA_DIOR		0x2004
+							MX51_PAD_NANDF_ALE__PATA_BUFFER_EN	0x2004
+							MX51_PAD_NANDF_CLE__PATA_RESET_B	0x2004
+							MX51_PAD_NANDF_WP_B__PATA_DMACK		0x2004
+							MX51_PAD_NANDF_RB0__PATA_DMARQ		0x2004
+							MX51_PAD_NANDF_RB1__PATA_IORDY		0x2004
+							MX51_PAD_GPIO_NAND__PATA_INTRQ		0x2004
+							MX51_PAD_NANDF_CS2__PATA_CS_0		0x2004
+							MX51_PAD_NANDF_CS3__PATA_CS_1		0x2004
+							MX51_PAD_NANDF_CS4__PATA_DA_0		0x2004
+							MX51_PAD_NANDF_CS5__PATA_DA_1		0x2004
+							MX51_PAD_NANDF_CS6__PATA_DA_2		0x2004
+							MX51_PAD_NANDF_D15__PATA_DATA15		0x2004
+							MX51_PAD_NANDF_D14__PATA_DATA14		0x2004
+							MX51_PAD_NANDF_D13__PATA_DATA13		0x2004
+							MX51_PAD_NANDF_D12__PATA_DATA12		0x2004
+							MX51_PAD_NANDF_D11__PATA_DATA11		0x2004
+							MX51_PAD_NANDF_D10__PATA_DATA10		0x2004
+							MX51_PAD_NANDF_D9__PATA_DATA9		0x2004
+							MX51_PAD_NANDF_D8__PATA_DATA8		0x2004
+							MX51_PAD_NANDF_D7__PATA_DATA7		0x2004
+							MX51_PAD_NANDF_D6__PATA_DATA6		0x2004
+							MX51_PAD_NANDF_D5__PATA_DATA5		0x2004
+							MX51_PAD_NANDF_D4__PATA_DATA4		0x2004
+							MX51_PAD_NANDF_D3__PATA_DATA3		0x2004
+							MX51_PAD_NANDF_D2__PATA_DATA2		0x2004
+							MX51_PAD_NANDF_D1__PATA_DATA1		0x2004
+							MX51_PAD_NANDF_D0__PATA_DATA0		0x2004
+						>;
+					};
+				};
+
 				uart1 {
 					pinctrl_uart1_1: uart1grp-1 {
 						fsl,pins = <
@@ -591,6 +627,14 @@
 				status = "disabled";
 			};
 
+			pata: pata at 83fe0000 {
+				compatible = "fsl,imx51-pata", "fsl,imx27-pata";
+				reg = <0x83fe0000 0x4000>;
+				interrupts = <70>;
+				clocks = <&clks 161>;
+				status = "disabled";
+			};
+
 			ssi3: ssi at 83fe8000 {
 				compatible = "fsl,imx51-ssi", "fsl,imx21-ssi";
 				reg = <0x83fe8000 0x4000>;
-- 
1.8.2.rc2



From s.hauer at pengutronix.de  Thu Apr  4 05:25:04 2013
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Thu,  4 Apr 2013 11:25:04 +0200
Subject: [PATCH 1/6] ata: i.MX PATA: Use devm_clk_get
In-Reply-To: <1365067509-10186-1-git-send-email-s.hauer@pengutronix.de>
References: <1365067509-10186-1-git-send-email-s.hauer@pengutronix.de>
Message-ID: <1365067509-10186-2-git-send-email-s.hauer@pengutronix.de>

To make the error path a bit simpler.

Signed-off-by: Sascha Hauer <s.hauer at pengutronix.de>
---
 drivers/ata/pata_imx.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/ata/pata_imx.c b/drivers/ata/pata_imx.c
index 4084944..af893dd 100644
--- a/drivers/ata/pata_imx.c
+++ b/drivers/ata/pata_imx.c
@@ -112,7 +112,7 @@ static int pata_imx_probe(struct platform_device *pdev)
 	if (!priv)
 		return -ENOMEM;
 
-	priv->clk = clk_get(&pdev->dev, NULL);
+	priv->clk = devm_clk_get(&pdev->dev, NULL);
 	if (IS_ERR(priv->clk)) {
 		dev_err(&pdev->dev, "Failed to get clock\n");
 		return PTR_ERR(priv->clk);
@@ -163,7 +163,7 @@ static int pata_imx_probe(struct platform_device *pdev)
 
 free_priv:
 	clk_disable_unprepare(priv->clk);
-	clk_put(priv->clk);
+
 	return -ENOMEM;
 }
 
@@ -177,7 +177,6 @@ static int pata_imx_remove(struct platform_device *pdev)
 	__raw_writel(0, priv->host_regs + PATA_IMX_ATA_INT_EN);
 
 	clk_disable_unprepare(priv->clk);
-	clk_put(priv->clk);
 
 	return 0;
 }
-- 
1.8.2.rc2



From s.hauer at pengutronix.de  Thu Apr  4 05:25:08 2013
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Thu,  4 Apr 2013 11:25:08 +0200
Subject: [PATCH 5/6] ARM: i.MX5: Add PATA and SRTC clocks
In-Reply-To: <1365067509-10186-1-git-send-email-s.hauer@pengutronix.de>
References: <1365067509-10186-1-git-send-email-s.hauer@pengutronix.de>
Message-ID: <1365067509-10186-6-git-send-email-s.hauer@pengutronix.de>

This adds the clock gates and the binding documentation
for PATA and SRTC.

Signed-off-by: Sascha Hauer <s.hauer at pengutronix.de>
---
 Documentation/devicetree/bindings/clock/imx5-clock.txt | 2 ++
 arch/arm/mach-imx/clk-imx51-imx53.c                    | 4 +++-
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/clock/imx5-clock.txt b/Documentation/devicetree/bindings/clock/imx5-clock.txt
index 2a0c904..da5eb30 100644
--- a/Documentation/devicetree/bindings/clock/imx5-clock.txt
+++ b/Documentation/devicetree/bindings/clock/imx5-clock.txt
@@ -172,6 +172,8 @@ clocks and IDs.
 	can1_serial_gate	157
 	can1_ipg_gate		158
 	owire_gate		159
+	srtc_gate		160
+	pata_gate		161
 
 Examples (for mx53):
 
diff --git a/arch/arm/mach-imx/clk-imx51-imx53.c b/arch/arm/mach-imx/clk-imx51-imx53.c
index 0f39f8c..026a819 100644
--- a/arch/arm/mach-imx/clk-imx51-imx53.c
+++ b/arch/arm/mach-imx/clk-imx51-imx53.c
@@ -83,7 +83,7 @@ enum imx5_clks {
 	ssi2_root_gate, ssi3_root_gate, ssi_ext1_gate, ssi_ext2_gate,
 	epit1_ipg_gate, epit1_hf_gate, epit2_ipg_gate, epit2_hf_gate,
 	can_sel, can1_serial_gate, can1_ipg_gate,
-	owire_gate,
+	owire_gate, srtc_gate, pata_gate,
 	clk_max
 };
 
@@ -235,6 +235,8 @@ static void __init mx5_clocks_common_init(unsigned long rate_ckil,
 	clk[epit2_ipg_gate] = imx_clk_gate2("epit2_ipg_gate", "ipg", MXC_CCM_CCGR2, 6);
 	clk[epit2_hf_gate] = imx_clk_gate2("epit2_hf_gate", "per_root", MXC_CCM_CCGR2, 8);
 	clk[owire_gate] = imx_clk_gate2("owire_gate", "per_root", MXC_CCM_CCGR2, 22);
+	clk[srtc_gate] = imx_clk_gate2("srtc_gate", "per_root", MXC_CCM_CCGR4, 28);
+	clk[pata_gate] = imx_clk_gate2("pata_gate", "ipg", MXC_CCM_CCGR4, 0);
 
 	for (i = 0; i < ARRAY_SIZE(clk); i++)
 		if (IS_ERR(clk[i]))
-- 
1.8.2.rc2



From s.hauer at pengutronix.de  Thu Apr  4 05:25:07 2013
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Thu,  4 Apr 2013 11:25:07 +0200
Subject: [PATCH 4/6] ata: i.MX PATA: add devicetree support
In-Reply-To: <1365067509-10186-1-git-send-email-s.hauer@pengutronix.de>
References: <1365067509-10186-1-git-send-email-s.hauer@pengutronix.de>
Message-ID: <1365067509-10186-5-git-send-email-s.hauer@pengutronix.de>

Not much to do here, only the compatible entries have to be added.

Signed-off-by: Sascha Hauer <s.hauer at pengutronix.de>
---
 Documentation/devicetree/bindings/ata/imx-pata.txt | 17 +++++++++++++++++
 drivers/ata/pata_imx.c                             |  9 +++++++++
 2 files changed, 26 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/ata/imx-pata.txt

diff --git a/Documentation/devicetree/bindings/ata/imx-pata.txt b/Documentation/devicetree/bindings/ata/imx-pata.txt
new file mode 100644
index 0000000..e38d734
--- /dev/null
+++ b/Documentation/devicetree/bindings/ata/imx-pata.txt
@@ -0,0 +1,17 @@
+* Freescale i.MX PATA Controller
+
+Required properties:
+- compatible: "fsl,imx27-pata"
+- reg: Address range of the PATA Controller
+- interrupts: The interrupt of the PATA Controller
+- clocks: the clocks for the PATA Controller
+
+Example:
+
+	pata: pata at 83fe0000 {
+		compatible = "fsl,imx51-pata", "fsl,imx27-pata";
+		reg = <0x83fe0000 0x4000>;
+		interrupts = <70>;
+		clocks = <&clks 161>;
+		status = "disabled";
+	};
diff --git a/drivers/ata/pata_imx.c b/drivers/ata/pata_imx.c
index adbb01d..aa3d166 100644
--- a/drivers/ata/pata_imx.c
+++ b/drivers/ata/pata_imx.c
@@ -230,11 +230,20 @@ static const struct dev_pm_ops pata_imx_pm_ops = {
 };
 #endif
 
+static const struct of_device_id imx_pata_dt_ids[] = {
+	{
+		.compatible = "fsl,imx27-pata",
+	}, {
+		/* sentinel */
+	}
+};
+
 static struct platform_driver pata_imx_driver = {
 	.probe		= pata_imx_probe,
 	.remove		= pata_imx_remove,
 	.driver = {
 		.name		= DRV_NAME,
+		.of_match_table	= imx_pata_dt_ids,
 		.owner		= THIS_MODULE,
 #ifdef CONFIG_PM
 		.pm		= &pata_imx_pm_ops,
-- 
1.8.2.rc2



From s.hauer at pengutronix.de  Thu Apr  4 05:25:05 2013
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Thu,  4 Apr 2013 11:25:05 +0200
Subject: [PATCH 2/6] ata: i.MX PATA: cleanup error path
In-Reply-To: <1365067509-10186-1-git-send-email-s.hauer@pengutronix.de>
References: <1365067509-10186-1-git-send-email-s.hauer@pengutronix.de>
Message-ID: <1365067509-10186-3-git-send-email-s.hauer@pengutronix.de>

- rename free_priv label to 'err' since priv is allocated with devm_*
  and not freed here.
- add missing 'goto err' in case ata_host_activate fails
- add 'ret' variable to return correct error value instead of hardcoded
  -ENOMEM in error case.

Signed-off-by: Sascha Hauer <s.hauer at pengutronix.de>
---
 drivers/ata/pata_imx.c | 20 ++++++++++++++------
 1 file changed, 14 insertions(+), 6 deletions(-)

diff --git a/drivers/ata/pata_imx.c b/drivers/ata/pata_imx.c
index af893dd..f243496 100644
--- a/drivers/ata/pata_imx.c
+++ b/drivers/ata/pata_imx.c
@@ -98,6 +98,7 @@ static int pata_imx_probe(struct platform_device *pdev)
 	struct pata_imx_priv *priv;
 	int irq = 0;
 	struct resource *io_res;
+	int ret;
 
 	io_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 	if (io_res == NULL)
@@ -121,8 +122,10 @@ static int pata_imx_probe(struct platform_device *pdev)
 	clk_prepare_enable(priv->clk);
 
 	host = ata_host_alloc(&pdev->dev, 1);
-	if (!host)
-		goto free_priv;
+	if (!host) {
+		ret = -ENOMEM;
+		goto err;
+	}
 
 	host->private_data = priv;
 	ap = host->ports[0];
@@ -135,7 +138,8 @@ static int pata_imx_probe(struct platform_device *pdev)
 		resource_size(io_res));
 	if (!priv->host_regs) {
 		dev_err(&pdev->dev, "failed to map IO/CTL base\n");
-		goto free_priv;
+		ret = -EBUSY;
+		goto err;
 	}
 
 	ap->ioaddr.cmd_addr = priv->host_regs + PATA_IMX_DRIVE_DATA;
@@ -158,13 +162,17 @@ static int pata_imx_probe(struct platform_device *pdev)
 			priv->host_regs + PATA_IMX_ATA_INT_EN);
 
 	/* activate */
-	return ata_host_activate(host, irq, ata_sff_interrupt, 0,
+	ret = ata_host_activate(host, irq, ata_sff_interrupt, 0,
 				&pata_imx_sht);
 
-free_priv:
+	if (ret)
+		goto err;
+
+	return 0;
+err:
 	clk_disable_unprepare(priv->clk);
 
-	return -ENOMEM;
+	return ret;
 }
 
 static int pata_imx_remove(struct platform_device *pdev)
-- 
1.8.2.rc2



From thomas.petazzoni at free-electrons.com  Thu Apr  4 05:29:08 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Thu, 4 Apr 2013 11:29:08 +0200
Subject: [RFCv1 00/11] MSI support for Marvell EBU PCIe driver
In-Reply-To: <20130404091639.GA2245@localhost>
References: <1364316746-8702-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <20130404091639.GA2245@localhost>
Message-ID: <20130404112908.24c25c9a@skate>

Dear Ezequiel Garcia,

On Thu, 4 Apr 2013 06:16:40 -0300, Ezequiel Garcia wrote:

> Given the IRQ controller move to drivers/irqchip is independent of MSI
> work, and that we've already agreed this move is fine (Arnd has acked
> patch 2), may I suggest that you resend these three first patches
> (and perhaps the fourth?) as a separate patchset to be included in v3.10.
> 
> This has the advantage that further development on IRQ controller can be
> done directly on its proper place, and also the MSI patchset can be
> simplified.
> 
> What do you think?

Sounds like a good idea. I'll cook a patch set later today and I'll
send it.

Thanks for the suggestion!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From mark.rutland at arm.com  Thu Apr  4 05:29:39 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Thu, 4 Apr 2013 10:29:39 +0100
Subject: [PATCH 2/5] ARM: KVM: arch_timers: zero CNTVOFF upon return to
 host
In-Reply-To: <CAEDV+gKmi16juPvQUO46eMVwtNMR+q4ce8ND_yVM4_O8iOYUXw@mail.gmail.com>
References: <1364404312-4427-1-git-send-email-mark.rutland@arm.com>
 <1364404312-4427-3-git-send-email-mark.rutland@arm.com>
 <CAEDV+gKmi16juPvQUO46eMVwtNMR+q4ce8ND_yVM4_O8iOYUXw@mail.gmail.com>
Message-ID: <20130404092939.GB3341@e106331-lin.cambridge.arm.com>

Hi Christoffer,

On Thu, Apr 04, 2013 at 12:39:27AM +0100, Christoffer Dall wrote:
> On Wed, Mar 27, 2013 at 10:11 AM, Mark Rutland <mark.rutland at arm.com> wrote:
> > To use the virtual counters from the host, we need to ensure that
> > CNTVOFF doesn't change unexpectedly. When we change to a guest, we
> > replace the host's CNTVOFF, but we don't restore it when returning to
> > the host.
> >
> > As the host sets CNTVOFF to zero, and never changes it, we can simply
> > zero CNTVOFF when returning to the host. This patch adds said zeroing to
> > the return to host path.
> >
> > Signed-off-by: Mark Rutland <mark.rutland at arm.com>
> > Acked-by: Marc Zyngier <marc.zyngier at arm.com>
> > Cc: Christoffer Dall <cdall at cs.columbia.edu>
> > ---
> >  arch/arm/kvm/interrupts_head.S | 4 ++++
> >  1 file changed, 4 insertions(+)
> >
> > diff --git a/arch/arm/kvm/interrupts_head.S b/arch/arm/kvm/interrupts_head.S
> > index 3c8f2f0..d43cfb5 100644
> > --- a/arch/arm/kvm/interrupts_head.S
> > +++ b/arch/arm/kvm/interrupts_head.S
> > @@ -497,6 +497,10 @@ vcpu       .req    r0              @ vcpu pointer always in r0
> >         add     r5, vcpu, r4
> >         strd    r2, r3, [r5]
> >
> > +       @ Ensure host CNTVCT == CNTPCT
> > +       mov     r2, #0
> > +       mcrr    p15, 4, r2, r2, c14     @ CNTVOFF
> > +
> >  1:
> >  #endif
> >         @ Allow physical timer/counter access for the host
> > --
> > 1.8.1.1
> >
> >
> 
> looks good to me.
> 
> Merged into kvm-arm-fixes.

As this patch depends on the previous patch (which sets CNTVOFF to 0 in the hyp
stub), and the rest of the patches depend on both this patch and the previous
for correct operation, the series really needs to be taken together.

Would you be able to give your ack instead?

This patch is only required because the later patches in this series need it to
allow the host to use virtual counters, nothing else requires the host's
CNTVOFF to be 0 at the moment as both physical counters and timers are used by
the host.

Thanks,
Mark.


From lee.jones at linaro.org  Thu Apr  4 05:31:16 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Thu,  4 Apr 2013 10:31:16 +0100
Subject: [PATCH 1/2] mfd: db8500-prcmu: Return early if the TCPM cannot be
 located
Message-ID: <1365067877-29459-1-git-send-email-lee.jones@linaro.org>

Currently we check to see if we obtained the Tightly Coupled Program
Memory (TCPM) base and only execute the code within the check if we
have it. It's more traditional to return early if we don't have it.
This way we can flatten most of the function's code down to a single
tab spacing.

Cc: Samuel Ortiz <sameo at linux.intel.com>
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 drivers/mfd/db8500-prcmu.c |   40 +++++++++++++++++++++-------------------
 1 file changed, 21 insertions(+), 19 deletions(-)

diff --git a/drivers/mfd/db8500-prcmu.c b/drivers/mfd/db8500-prcmu.c
index 21f261b..1c4edbf8 100644
--- a/drivers/mfd/db8500-prcmu.c
+++ b/drivers/mfd/db8500-prcmu.c
@@ -2794,6 +2794,7 @@ static void dbx500_fw_version_init(struct platform_device *pdev,
 {
 	struct resource *res;
 	void __iomem *tcpm_base;
+	u32 version;
 
 	res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
 					   "prcmu-tcpm");
@@ -2803,26 +2804,27 @@ static void dbx500_fw_version_init(struct platform_device *pdev,
 		return;
 	}
 	tcpm_base = ioremap(res->start, resource_size(res));
-	if (tcpm_base != NULL) {
-		u32 version;
-
-		version = readl(tcpm_base + version_offset);
-		fw_info.version.project = (version & 0xFF);
-		fw_info.version.api_version = (version >> 8) & 0xFF;
-		fw_info.version.func_version = (version >> 16) & 0xFF;
-		fw_info.version.errata = (version >> 24) & 0xFF;
-		strncpy(fw_info.version.project_name,
-			fw_project_name(fw_info.version.project),
-			PRCMU_FW_PROJECT_NAME_LEN);
-		fw_info.valid = true;
-		pr_info("PRCMU firmware: %s(%d), version %d.%d.%d\n",
-			fw_info.version.project_name,
-			fw_info.version.project,
-			fw_info.version.api_version,
-			fw_info.version.func_version,
-			fw_info.version.errata);
-		iounmap(tcpm_base);
+	if (!tcpm_base) {
+		dev_err(&pdev->dev, "no prcmu tcpm mem region provided\n");
+		return;
 	}
+
+	version = readl(tcpm_base + version_offset);
+	fw_info.version.project = (version & 0xFF);
+	fw_info.version.api_version = (version >> 8) & 0xFF;
+	fw_info.version.func_version = (version >> 16) & 0xFF;
+	fw_info.version.errata = (version >> 24) & 0xFF;
+	strncpy(fw_info.version.project_name,
+		fw_project_name(fw_info.version.project),
+		PRCMU_FW_PROJECT_NAME_LEN);
+	fw_info.valid = true;
+	pr_info("PRCMU firmware: %s(%d), version %d.%d.%d\n",
+		fw_info.version.project_name,
+		fw_info.version.project,
+		fw_info.version.api_version,
+		fw_info.version.func_version,
+		fw_info.version.errata);
+	iounmap(tcpm_base);
 }
 
 void __init db8500_prcmu_early_init(void)
-- 
1.7.10.4



From lee.jones at linaro.org  Thu Apr  4 05:31:17 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Thu,  4 Apr 2013 10:31:17 +0100
Subject: [PATCH 2/2] mfd: db8500-prcmu: Support platform dependant device
 selection
In-Reply-To: <1365067877-29459-1-git-send-email-lee.jones@linaro.org>
References: <1365067877-29459-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1365067877-29459-2-git-send-email-lee.jones@linaro.org>

The main aim for this cycle is to have the u8540 booting to a
console. However, the u8540 doesn't support all of the u8500
platform devices yet. After this stage is complete we can then
fill in the inadequacies, such as specific clock support at a
later date. To achieve this we're placing devices supported by
all platforms into a common device structure and the remaining
ones into a platform specific one.

Cc: Samuel Ortiz <sameo at linux.intel.com>
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 drivers/mfd/db8500-prcmu.c |   46 +++++++++++++++++++++++++++++---------------
 1 file changed, 30 insertions(+), 16 deletions(-)

diff --git a/drivers/mfd/db8500-prcmu.c b/drivers/mfd/db8500-prcmu.c
index 1c4edbf8..37ece93 100644
--- a/drivers/mfd/db8500-prcmu.c
+++ b/drivers/mfd/db8500-prcmu.c
@@ -24,6 +24,7 @@
 #include <linux/jiffies.h>
 #include <linux/bitops.h>
 #include <linux/fs.h>
+#include <linux/of.h>
 #include <linux/platform_device.h>
 #include <linux/uaccess.h>
 #include <linux/irqchip/arm-gic.h>
@@ -3107,19 +3108,7 @@ static struct ux500_wdt_data db8500_wdt_pdata = {
 	.has_28_bits_resolution = true,
 };
 
-static struct mfd_cell db8500_prcmu_devs[] = {
-	{
-		.name = "db8500-prcmu-regulators",
-		.of_compatible = "stericsson,db8500-prcmu-regulator",
-		.platform_data = &db8500_regulators,
-		.pdata_size = sizeof(db8500_regulators),
-	},
-	{
-		.name = "cpufreq-ux500",
-		.of_compatible = "stericsson,cpufreq-ux500",
-		.platform_data = &db8500_cpufreq_table,
-		.pdata_size = sizeof(db8500_cpufreq_table),
-	},
+static struct mfd_cell common_prcmu_devs[] = {
 	{
 		.name = "ux500_wdt",
 		.platform_data = &db8500_wdt_pdata,
@@ -3135,6 +3124,21 @@ static struct mfd_cell db8500_prcmu_devs[] = {
 	},
 };
 
+static struct mfd_cell db8500_prcmu_devs[] = {
+	{
+		.name = "db8500-prcmu-regulators",
+		.of_compatible = "stericsson,db8500-prcmu-regulator",
+		.platform_data = &db8500_regulators,
+		.pdata_size = sizeof(db8500_regulators),
+	},
+	{
+		.name = "cpufreq-ux500",
+		.of_compatible = "stericsson,cpufreq-ux500",
+		.platform_data = &db8500_cpufreq_table,
+		.pdata_size = sizeof(db8500_cpufreq_table),
+	},
+};
+
 static void db8500_prcmu_update_cpufreq(void)
 {
 	if (prcmu_has_arm_maxopp()) {
@@ -3184,7 +3188,7 @@ static int db8500_prcmu_probe(struct platform_device *pdev)
 
 	db8500_irq_init(np);
 
-	for (i = 0; i < ARRAY_SIZE(db8500_prcmu_devs); i++) {
+	for (i = 0; i < ARRAY_SIZE(common_prcmu_devs); i++) {
 		if (!strcmp(db8500_prcmu_devs[i].name, "ab8500-core")) {
 			db8500_prcmu_devs[i].platform_data = pdata->ab_platdata;
 			db8500_prcmu_devs[i].pdata_size = sizeof(struct ab8500_platform_data);
@@ -3195,13 +3199,23 @@ static int db8500_prcmu_probe(struct platform_device *pdev)
 
 	db8500_prcmu_update_cpufreq();
 
-	err = mfd_add_devices(&pdev->dev, 0, db8500_prcmu_devs,
-			      ARRAY_SIZE(db8500_prcmu_devs), NULL, 0, NULL);
+	err = mfd_add_devices(&pdev->dev, 0, common_prcmu_devs,
+			      ARRAY_SIZE(common_prcmu_devs), NULL, 0, NULL);
 	if (err) {
 		pr_err("prcmu: Failed to add subdevices\n");
 		return err;
 	}
 
+	/* TODO: Remove restriction when clk definitions are available. */
+	if (!of_machine_is_compatible("st-ericsson,u8540")) {
+		err = mfd_add_devices(&pdev->dev, 0, db8500_prcmu_devs,
+				      ARRAY_SIZE(db8500_prcmu_devs), NULL, 0, NULL);
+		if (err) {
+			pr_err("prcmu: Failed to add subdevices\n");
+			return err;
+		}
+	}
+
 	pr_info("DB8500 PRCMU initialized\n");
 
 no_irq_return:
-- 
1.7.10.4



From nsekhar at ti.com  Thu Apr  4 05:33:25 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Thu, 4 Apr 2013 15:03:25 +0530
Subject: [PATCH v8 1/2] ARM: davinci: dm365: add support for v4l2 video
 display
In-Reply-To: <1364903681-13914-2-git-send-email-prabhakar.csengg@gmail.com>
References: <1364903681-13914-1-git-send-email-prabhakar.csengg@gmail.com>
 <1364903681-13914-2-git-send-email-prabhakar.csengg@gmail.com>
Message-ID: <515D48E5.1060700@ti.com>

On 4/2/2013 5:24 PM, Prabhakar lad wrote:
> From: Lad, Prabhakar <prabhakar.csengg at gmail.com>
> 
> Create platform devices for various video modules like venc,osd,
> vpbe and v4l2 driver for dm365.
> 
> Signed-off-by: Lad, Prabhakar <prabhakar.csengg at gmail.com>

Minor nits below:

> diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
> index c61dd94..786c860 100644
> --- a/arch/arm/mach-davinci/dm365.c
> +++ b/arch/arm/mach-davinci/dm365.c
> @@ -40,10 +40,14 @@
>  
>  #define DM365_REF_FREQ		24000000	/* 24 MHz on the DM365 EVM */
>  
> +#define DM365_RTC_BASE			0x01c69000
> +
>  /* Base of key scan register bank */
>  #define DM365_KEYSCAN_BASE		0x01c69400
>  
> -#define DM365_RTC_BASE			0x01c69000
> +#define DM365_OSD_BASE			0x01c71c00
> +
> +#define DM365_VENC_BASE			0x01c71e00
>  
>  #define DAVINCI_DM365_VC_BASE		0x01d0c000

No need of empty lines between these definitions. While at it you can
also remove the useless comment "/* Base of key scan register bank */"

> +static int dm365_vpbe_setup_pinmux(enum v4l2_mbus_pixelcode if_type,
> +			    int field)
> +{
> +	switch (if_type) {
> +	case V4L2_MBUS_FMT_SGRBG8_1X8:
> +		davinci_cfg_reg(DM365_VOUT_FIELD_G81);
> +		davinci_cfg_reg(DM365_VOUT_COUTL_EN);
> +		davinci_cfg_reg(DM365_VOUT_COUTH_EN);
> +		break;
> +

No need of these empty lines after 'break'. Here and other places below.

The patch looks good overall though so you can fix the nits and add:

Acked-by: Sekhar Nori <nsekhar at ti.com>

Thanks,
Sekhar


From simon.guinot at sequanux.org  Thu Apr  4 05:34:35 2013
From: simon.guinot at sequanux.org (Simon Guinot)
Date: Thu, 4 Apr 2013 11:34:35 +0200
Subject: [PATCH] ARM: kirkwood: DT board setup for CloudBox
In-Reply-To: <20130404080058.GJ16404@kw.sim.vm.gnt>
References: <20130329153132.GJ13280@titan.lakedaemon.net>
 <20130329184109.GA16404@kw.sim.vm.gnt> <51568B89.1060009@free.fr>
 <20130401163316.GC16404@kw.sim.vm.gnt> <515A5BC6.5000007@free.fr>
 <20130402114535.GR13280@titan.lakedaemon.net>
 <20130402125408.GH16404@kw.sim.vm.gnt>
 <20130402172454.GT13280@titan.lakedaemon.net>
 <515D0776.7050208@free.fr> <20130404080058.GJ16404@kw.sim.vm.gnt>
Message-ID: <20130404093435.GK16404@kw.sim.vm.gnt>

On Thu, Apr 04, 2013 at 10:00:58AM +0200, Simon Guinot wrote:
> On Thu, Apr 04, 2013 at 06:54:14AM +0200, Chris Moore wrote:
> > Hi,
> > 
> > Le 02/04/2013 19:24, Jason Cooper a ?crit :
> > >On Tue, Apr 02, 2013 at 02:54:11PM +0200, Simon Guinot wrote:
> > >
> > ...
> > 
> > >>There is two different LaCie boards. There is no relations between this
> > >>boards except their final product name (which is quite silly).
> > >>
> > >> From a LaCie point, there is no board but only product naming. Here are
> > >>the different names used by LaCie for this two boards/products:
> > >>
> > >>1: netspace_mini_v2 ->  SafeBox ->  CloudBox
> > >>2: FamilyBox ->  CloudBox
> > >>
> > >>"1" is the oldest board.
> > >Got it.
> > 
> > I may be thick but I didn't realise that my old black CloudBox was
> > already supported under the name netspace_mini_v2 :(
> > There is no reference to CloudBox anywhere in the kernel; only the
> > SafeBox alias (of which I was also unaware) is given in Kconfig.
> 
> Yes we will fix that.
> 
> > 
> > >>Under Linux, with my patch we are using the following names:
> > >>
> > >>1: netspace_mini_v2
> > >>2: cloudbox
> > >>
> > >>The problem raised by Chris is that the cloudbox name could be
> > >>confusing because one could try a "cloudbox" dtb on the board "1". For
> > >>my part I don't think it is an issue because "1" is rather confidential
> > >>(and it is an euphemism).
> > >Agreed.
> > 
> > I wasn't aware that the original CloudBox was so confidential.
> > I even saw them for sale in my local FNAC (a hi-tech and media shop
> > present in most large French shopping centres).
> 
> Yes they were available but only few of them have been sold. From a
> LaCie point this product simply doesn't have existed. That's why the
> name have been reused.
> 
> > 
> > >>It would be more confusing for users if the kernel name for "2" is not
> > >>cloudbox but cloudbox_{color,number,...} or even familybox. Moreover
> > >>netspace_mini_v2 is a correct name for "1".
> > >>
> > >>IMHO, we could let things as they are. Additionally, I could either
> > >>extend the Kconfig description and add a some comments in the dts files,
> > >>in order to to prevent any misunderstanding...
> > >>
> > >>Let me know if you agree or not.
> > >Yes, that makes more sense.  Thanks for clearing it up.  Please add the
> > >clarifying remarks to the dts.
> > 
> > I agree that it would be confusing to change the netspace_mini_v2 name now.
> > 
> > In view of all the above, please disregard my objection.
> > Sorry for the noise :(
> 
> No problems, this needs to be clarified.
> 
> > 
> > >As for the model number for the public board (#2), why can't we append
> > >"-90003xx"?  See [1], Specifications tab.
> > >
> > >[1] http://www.lacie.com/us/products/product.htm?id=10597
> > 
> > This seems like a good idea to me but I don't think Simon favoured
> > adding a model number.
> > In any case Simon would know better than me whether this covers the
> > models correctly.
> > What do you think, Simon?
> 
> I am currently working on this numbers. It _could_ work. Apparently the
> product ID is encoded in the numbers... as well as the case color and
> size. Today I should meet someone with more informations about the model
> number format.

Finally, the model number pattern "-90003xx" can't be used to match the
CloudBox product. The number is indeed unique. It encodes product ID,
storage capacity, case color and case size. But the pattern is not
usable. If tomorrow a red CloudBox is released, the first digits could
be completely different.

To illustrate that, have a look at:
http://www.lacie.com/products/product.htm?id=10584.

The item numbers are 2000345, 9000225 and 9000226.

Then we are back to the initial problem...

Maybe we could append some suffixes based on the version:

1: cloudbox-v1
2: cloudbox-v2

Or better, suffix based on the other code names:

1: cloudbox-ns2mini
2: cloudbox-familybox

Or even let the things as they are:

1: netspace_v2_mini
2: cloudbox

I agree with all this possibilities (and maybe others). Let me know your
preferences.

Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130404/1582155c/attachment.sig>

From nsekhar at ti.com  Thu Apr  4 05:35:03 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Thu, 4 Apr 2013 15:05:03 +0530
Subject: [PATCH v8 2/2] ARM: davinci: dm365 EVM: add support for VPBE
 display
In-Reply-To: <1364903681-13914-3-git-send-email-prabhakar.csengg@gmail.com>
References: <1364903681-13914-1-git-send-email-prabhakar.csengg@gmail.com>
 <1364903681-13914-3-git-send-email-prabhakar.csengg@gmail.com>
Message-ID: <515D4947.7070306@ti.com>

On 4/2/2013 5:24 PM, Prabhakar lad wrote:
> From: Lad, Prabhakar <prabhakar.csengg at gmail.com>
> 
> add support for V4L2 video display to DM365 EVM.
> Support for SD and ED modes is provided, along with Composite
> and Component outputs.
> 
> Signed-off-by: Lad, Prabhakar <prabhakar.csengg at gmail.com>

Acked-by: Sekhar Nori <nsekhar at ti.com>

Thanks,
Sekhar


From ezequiel.garcia at free-electrons.com  Thu Apr  4 05:31:31 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Thu, 4 Apr 2013 06:31:31 -0300
Subject: [PATCH v3 0/9] refactoring for mask_cache
In-Reply-To: <1363615255-18200-1-git-send-email-gerlando.falauto@keymile.com>
References: <1363277430-21325-1-git-send-email-holger.brunck@keymile.com>
 <1363615255-18200-1-git-send-email-gerlando.falauto@keymile.com>
Message-ID: <20130404093130.GB2245@localhost>

Hi Gerlando,

On Mon, Mar 18, 2013 at 03:00:46PM +0100, Gerlando Falauto wrote:
> Hi everyone,
> here is a patchset to address the issue found with Orion, in incremental
> stages as Thomas suggested.
> a) we introduce the new fields and pointer (though only the shared one is used)
> b) we convert all drivers to use it 
> c) we rename the field so to force the use of the per-ct pointer
> d) we add per-ct mask cache, provided the new flag 
>    IRQ_GC_SEPARATE_MASK_REGISTERS is enabled
> e) we enable the flag for orion-gpio and mvebu drivers
> 
> So even though I'm also providing changes for mvebu, I only
> tested the patch on a 3.0.40 kernel with the plat-orion/gpio.c driver.
> We currently do not have a working 3.6+ configuration for our Kirkwood
> boards (3.6 is apparently where this mvebu gpio driver was introduced),
> so I would be glad if someone could give it a try.
> I also have no idea whether the three Marvell variants all have separate
> mask registers (which is what the last patch assumes).
> 
> Gerlando Falauto (9):
>   genirq: cosmetic: remove cur_regs
>   genirq: add mask_cache and pmask_cache into struct irq_chip_type
>   gpio: mvebu: convert to usage of *pmask_cache within irq_chip_type
>   MIPS: JZ4740: convert to usage of *pmask_cache within irq_chip_type
>   ARM: SAMSUNG: convert to usage of *pmask_cache within irq_chip_type
>   genirq: rename mask_cache to shared_mask_cache
>   genirq: handle separate mask registers
>   orion-gpio: enable IRQ_GC_SEPARATE_MASK_REGISTERS
>   gpio: mvebu: enable IRQ_GC_SEPARATE_MASK_REGISTERS
> 
>  arch/arm/plat-orion/gpio.c            |    3 +-
>  arch/arm/plat-samsung/irq-vic-timer.c |    6 ++--
>  arch/mips/jz4740/irq.c                |    3 +-
>  drivers/gpio/gpio-mvebu.c             |   23 ++++++++------
>  include/linux/irq.h                   |    9 ++++--
>  kernel/irq/generic-chip.c             |   55 +++++++++++++++++++++------------
>  6 files changed, 64 insertions(+), 35 deletions(-)
> 

What's the plan for this patchset?

Given this fixes a long time issue, perhaps we might want to try to have
it included in v3.10, which is soon to come.

Thanks,
-- 
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com


From nicolas.ferre at atmel.com  Thu Apr  4 05:37:24 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Thu, 4 Apr 2013 11:37:24 +0200
Subject: [GIT PULL] at91: DT changes for 3.10 #2
In-Reply-To: <515BDE2C.9030904@atmel.com>
References: <1364569179-24773-1-git-send-email-nicolas.ferre@atmel.com>
 <20130402184947.GA8015@quad.lixom.net> <515BDE2C.9030904@atmel.com>
Message-ID: <515D49D4.5020208@atmel.com>

On 04/03/2013 09:45 AM, Nicolas Ferre :
> On 04/02/2013 08:49 PM, Olof Johansson :
>> On Fri, Mar 29, 2013 at 03:59:39PM +0100, Nicolas Ferre wrote:
>>> Arnd, Olof,
>>>
>>> Here is a pull-request for AT91 that is dedicated to Device Tree
>>> modifications. It is stacked on the material that you already have
>>> for 3.10 in your arm-soc/at91/dt branch.
>>> Following our discussion with Arnd, I added the non-urgent patches that I
>>> already proposed too late for 3.9. I also included the moving of macb node
>>> and kept the original patch.
>>>
>>> Thanks, best regards,
>>>
>>> The following changes since commit 6901d947be5ba1245a0f63271355b95f9056a362:
>>>
>>>   ARM: at91/at91sam9x5cm: add 1-wire chip on CM board (2013-03-21 16:07:15 +0100)
>>>
>>> are available in the git repository at:
>>>
>>>   git://github.com/at91linux/linux-at91.git tags/at91-dt
>>>
>>> for you to fetch changes up to cc2e191b0ccc5a987fdb29261ab9c264c608924d:
>>>
>>>   ARM: at91/dt: fix macb node declaration (2013-03-29 10:02:04 +0100)
>>>
>>> ----------------------------------------------------------------
>>> One macb DT node move for 9x5 family: 9g15 doesn't
>>> have an Ethernet interface.
>>> Little fixes mainly related to at91sam9x5 DT and the
>>> RTC addition.
>>> Addition of the Acme Systems Aria G25 board.
>>>
>>> ----------------------------------------------------------------
>>> Douglas Gilbert (1):
>>>       ARM: at91: add Acme Systems Aria G25 board
>>
>> Hi,
>>
>> I just replied to the above patch -- please prefix the dts files with the
>> platform so it's easier to navigate the directory.

I do not want to spark a debate here, but moving to directories per
"mach" earlier would have made things easier. If I recall well,
Jean-Christophe has proposed it a long time ago...

> Yes, I have to make sure that everybody agree on our side...

The difficult point with this prefix... well it is difficult to tell...
our product will never be called "at91" again!
So, yes, our Linux identity is still "at91" and we are pretty attached
to it but our newer products are named "sam" + "core" + "product family"
which results in our newer family: "sama5d3" (note the at91 is missing)...

=> anyway, we think that the at91 prefix is still vivid in Linux
community and we consider it as a good choice for now.
So, I may rename the newly introduced "sama5d3*.dts[i]" files with
"at91-sama5d3*.dts[i]" (while .c/.h files will remain the same).

>> Otherwise the branch contents looks good, so send a fresh request when you've
>> respun.
>>
>> Also, the new dts isn't added to the Makefile, please add it.
> 
> Ok, I will do. Maybe I can also stack a DT related patch about ADC
> support that I was planning to add in another pull-request covering the
> same topic.
> 
> Thanks, best regards,
> 


-- 
Nicolas Ferre


From lee.jones at linaro.org  Thu Apr  4 06:05:39 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Thu, 4 Apr 2013 11:05:39 +0100
Subject: [PATCH 1/2] mfd: db8500-prcmu: Return early if the TCPM cannot
 be located
In-Reply-To: <1365067877-29459-1-git-send-email-lee.jones@linaro.org>
References: <1365067877-29459-1-git-send-email-lee.jones@linaro.org>
Message-ID: <20130404100539.GA8921@gmail.com>

On Thu, 04 Apr 2013, Lee Jones wrote:

> Currently we check to see if we obtained the Tightly Coupled Program
> Memory (TCPM) base and only execute the code within the check if we
> have it. It's more traditional to return early if we don't have it.
> This way we can flatten most of the function's code down to a single
> tab spacing.
> 
> Cc: Samuel Ortiz <sameo at linux.intel.com>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>
> ---
>  drivers/mfd/db8500-prcmu.c |   40 +++++++++++++++++++++-------------------
>  1 file changed, 21 insertions(+), 19 deletions(-)

Withdrawn.

I'll resubmit.

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From lee.jones at linaro.org  Thu Apr  4 06:06:23 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Thu, 4 Apr 2013 11:06:23 +0100
Subject: [PATCH 2/2] mfd: db8500-prcmu: Support platform dependant device
 selection
In-Reply-To: <1365067877-29459-2-git-send-email-lee.jones@linaro.org>
References: <1365067877-29459-1-git-send-email-lee.jones@linaro.org>
 <1365067877-29459-2-git-send-email-lee.jones@linaro.org>
Message-ID: <20130404100623.GB8921@gmail.com>

On Thu, 04 Apr 2013, Lee Jones wrote:

> The main aim for this cycle is to have the u8540 booting to a
> console. However, the u8540 doesn't support all of the u8500
> platform devices yet. After this stage is complete we can then
> fill in the inadequacies, such as specific clock support at a
> later date. To achieve this we're placing devices supported by
> all platforms into a common device structure and the remaining
> ones into a platform specific one.
> 
> Cc: Samuel Ortiz <sameo at linux.intel.com>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>
> ---
>  drivers/mfd/db8500-prcmu.c |   46 +++++++++++++++++++++++++++++---------------
>  1 file changed, 30 insertions(+), 16 deletions(-)

Withdrawn.

I'll resubmit.

Sorry for the churn.

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From avinashphilip at ti.com  Thu Apr  4 06:10:17 2013
From: avinashphilip at ti.com (Philip, Avinash)
Date: Thu, 4 Apr 2013 10:10:17 +0000
Subject: [PATCH v3 0/3] Platform support for EHRPWM & ECAP devices in
 DAVINCI.
References: <1364197789-16783-1-git-send-email-avinashphilip@ti.com>
 <515A983D.8040907@ti.com>
 <518397C60809E147AF5323E0420B992E3EAA7C39@DBDE01.ent.ti.com>
 <515D1478.4030700@ti.com> 
Message-ID: <518397C60809E147AF5323E0420B992E3EAA7DC5@DBDE01.ent.ti.com>

On Thu, Apr 04, 2013 at 12:07:44, Philip, Avinash wrote:
> On Thu, Apr 04, 2013 at 11:19:44, Nori, Sekhar wrote:
> > On 4/4/2013 10:09 AM, Philip, Avinash wrote:
> > > On Tue, Apr 02, 2013 at 14:05:09, Nori, Sekhar wrote:
> > >> On 3/25/2013 1:19 PM, Philip Avinash wrote:
> > >>> Add platform support for EHRPWM and ECAP by providing clock nodes and
> > >>> device tree nodes.
> > >>> This series depends on [1] and [2] and is available for testing at [3].
> > >>> Tested for back light support in da850 EVM with EHRPWM PWM device.
> > >>>
> > >>> [1] http://gitorious.org/linux-davinci/linux-davinci/trees/davinci-for-v3.9/dt-2
> > >>> [2] https://gitorious.org/linux-pwm/linux-pwm/trees/for-next
> > >>> [3] https://github.com/avinashphilip/am335x_linux/tree/davinci-for-v3.9_soc_pwm
> > >>>
> > >>> Note:
> > >>> DT support for EHRPWM backlight has not been added in da850-evm.dts as there is
> > >>> conflicting pin-mux requirement with SPI flash.
> > >>
> > >> Can you check if this is really true even in newer boards (have a look
> > >> at the latest schematics)? I remember this used to be a problem in very
> > >> early versions but was fixed later.
> > > 
> > > On looking schematics, panel has three power controls LCD_BACKLIGHT_PWR, LCD_PANEL_PWR,
> > > LCD_PWM0. On latest schematic, LCD_PWM0 is connected to ECAP instance 2. So backlight
> > > can control through ECAP2 (not conflicting with SPI1 cs0). Still for controlling
> > > backlight, require support for LCD_BACKLIGHT_PWR & LCD_PANEL_PWR. These signals
> > 
> > By controlling above you mean "switching on/off"? Otherwise this seems
> > to be contradicting the statement just before.
> 
> Yes these lines should be switching on/off.
> 
> > 
> > > to be controlled by GPIO 2[8] & GPIO 2[15]. In release platform callbacks used
> > > to control GPIO functionality. But with DT support, I have to check how platform
> > > callbacks can be used.
> > 
> > Platform callbacks are not possible with DT.
> 
> Ok.
> 
> > You can look at what freescale mxsfb.c does. Look for panel-enable-gpios DT binding.
> 
> I will use GPIO pin configuration info from DT nodes. From probe GPIO pin make active and
> in remove disable GPIO pin.

For passing from GPIO pins from DT, GPIO DT node has to be populated. So this has dependency
on GPIO driver conversion for davinci platforms.

Thanks
Avinash

> 
> Thanks
> Avinash
> 
> > 
> > Thanks,
> > Sekhar
> > 
> 
> 


From laurent.pinchart at ideasonboard.com  Thu Apr  4 06:15:36 2013
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Thu, 04 Apr 2013 12:15:36 +0200
Subject: [PATCH 02/04] ARM: shmobile: r8a7779 pinmux platform device
 cleanup
In-Reply-To: <20130403063308.2500.76867.sendpatchset@w520>
References: <20130403063246.2500.65318.sendpatchset@w520>
 <20130403063308.2500.76867.sendpatchset@w520>
Message-ID: <3291720.vtipCVFTtu@avalon>

Hi Magnus,

Thanks for the patch.

On Wednesday 03 April 2013 15:33:08 Magnus Damm wrote:
> From: Magnus Damm <damm at opensource.se>
> 
> Use DEFINE_RES_MEM() to save a couple of lines of code.
> 
> Signed-off-by: Magnus Damm <damm at opensource.se>
> ---
> 
>  arch/arm/mach-shmobile/setup-r8a7779.c |   19 ++++---------------
>  1 file changed, 4 insertions(+), 15 deletions(-)
> 
> --- 0001/arch/arm/mach-shmobile/setup-r8a7779.c
> +++ work/arch/arm/mach-shmobile/setup-r8a7779.c	2013-04-03
> 15:30:16.000000000 +0900 @@ -63,12 +63,8 @@ void __init
> r8a7779_map_io(void)
>  	iotable_init(r8a7779_io_desc, ARRAY_SIZE(r8a7779_io_desc));
>  }
> 
> -static struct resource r8a7779_pfc_resources[] = {
> -	[0] = {
> -		.start	= 0xfffc0000,
> -		.end	= 0xfffc023b,
> -		.flags	= IORESOURCE_MEM,
> -	},
> +static const struct resource r8a7779_pfc_resources[] = {
> +	DEFINE_RES_MEM(0xfffc0000, 0x023c),

This generates a compilation warning, as the resources pointer in struct 
platform_device isn't const.

>  };
> 
>  static struct platform_device r8a7779_pfc_device = {
> @@ -80,15 +76,8 @@ static struct platform_device r8a7779_pf
> 
>  #define R8A7779_GPIO(idx, npins) \
>  static struct resource r8a7779_gpio##idx##_resources[] = {		\
> -	[0] = {								\
> -		.start	= 0xffc40000 + 0x1000 * (idx),			\
> -		.end	= 0xffc4002b + 0x1000 * (idx),			\
> -		.flags	= IORESOURCE_MEM,				\
> -	},								\
> -	[1] = {								\
> -		.start	= gic_iid(0xad + (idx)),			\
> -		.flags	= IORESOURCE_IRQ,				\
> -	}								\
> +	DEFINE_RES_MEM(0xffc40000 + (0x1000 * (idx)), 0x002c),		\
> +	DEFINE_RES_IRQ(gic_iid(0xad + (idx))),				\
>  };									\
>  									\
>  static struct gpio_rcar_config r8a7779_gpio##idx##_platform_data = {	\
-- 
Regards,

Laurent Pinchart



From lee.jones at linaro.org  Thu Apr  4 06:15:36 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Thu, 4 Apr 2013 11:15:36 +0100
Subject: [PATCH 9/9] mfd: db8500-prcmu: Support platform dependant device
 selection
In-Reply-To: <CACRpkdaRfBFMO+XnJVq9ccxsqw3+RS+OCPuF8ivrrRu=OxuJEQ@mail.gmail.com>
References: <1364908916-29803-1-git-send-email-lee.jones@linaro.org>
 <1364908916-29803-9-git-send-email-lee.jones@linaro.org>
 <CACRpkdaRfBFMO+XnJVq9ccxsqw3+RS+OCPuF8ivrrRu=OxuJEQ@mail.gmail.com>
Message-ID: <20130404101536.GC8921@gmail.com>

On Wed, 03 Apr 2013, Linus Walleij wrote:

> On Tue, Apr 2, 2013 at 3:21 PM, Lee Jones <lee.jones at linaro.org> wrote:
> 
> > The main aim for this cycle is to have the u8540 booting to a
> > console. However, the u8540 doesn't support all of the u8500
> > platform devices yet. After this stage is complete we can then
> > fill in the inadequacies, such as specific clock support at a
> > later date. To achieve this we're placing devices supported by
> > all platforms into a common device structure and the remaining
> > ones into a platform specific one.
> >
> > Cc: Samuel Ortiz <sameo at linux.intel.com>
> > Signed-off-by: Lee Jones <lee.jones at linaro.org>
> 
> Acked-by: Linus Walleij <linus.walleij at linaro.org>
> 
> This should also go through the MFD tree.

Right. I'll add your Ack and resubmit.

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From tomi.valkeinen at ti.com  Thu Apr  4 06:16:08 2013
From: tomi.valkeinen at ti.com (Tomi Valkeinen)
Date: Thu, 4 Apr 2013 13:16:08 +0300
Subject: [PATCHv3 0/6] fb: vt8500: patches for 3.10
In-Reply-To: <515D0F5E.5010805@prisktech.co.nz>
References: <1364926838-6721-1-git-send-email-linux@prisktech.co.nz>
 <515D0F5E.5010805@prisktech.co.nz>
Message-ID: <515D52E8.4010206@ti.com>

On 2013-04-04 08:27, Tony Prisk wrote:

> Tomi,
> 
> If no one has any further comments, are you still prepared to take this
> series?
> If so, I will send a pull-request.

Yes, I can take it. No need for pull-request, it was simple enough to
apply. I'll push it to linux-next today or tomorrow.

> With regards to the earlier concern about your current patch series, I
> think its easiest if you do take this series then you could do a fixup
> patch if this one is merged first. From what I remember of your series,
> it is basically a rename of of_get_display_timings() to
> of_get_display_timing() and some new code which I don't use. Seems a
> rather trivial patch for a fixup later.

Yes, I can fix it. Should be trivial.

 Tomi


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130404/a56e2ab5/attachment.sig>

From santosh.shilimkar at ti.com  Thu Apr  4 06:20:47 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Thu, 4 Apr 2013 15:50:47 +0530
Subject: [PATCH v2 00/12] ARM: OMAP5: hwmod,
 prm/cm data files and updates for 3.10
Message-ID: <1365070859-21790-1-git-send-email-santosh.shilimkar@ti.com>

Pual,

Here is the series which updates the minor updates you suggested.
As aligned on list with Tony, I have dropped clock data from the
series. That means for the boot, one clock data patch needs to be applied.
It is available on my git tree in 'out_of_tree/omap5_clk_data' branch.

Alsot, you will notice hwmod data loc has come down from ~6000 lines to
~2000 lines because of removal of iospace, irq, dma data as well as
unused hwmods. Few hwmods for which dt conversion is pending are
not added as well but those would add max ~400 loc in future.

Series has been tested boot on OMAP4 and OMAP5 devices and compile
tested for all the OMAP2/3/4/5 specific configs. For OMAP5 testing,
I have to pull in Tony's arm-soc pull requests, benoit's dt branch
and hence ended up creating a 'testing/3.10/omap5_int_rebuild' branch.

The following changes since commit a937536b868b8369b98967929045f1df54234323:

  Linux 3.9-rc3 (2013-03-17 15:59:32 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux.git for_3.10/omap5_data_files_v2

for you to fetch changes up to f97c560324a0e3c0607d57089930493db6ad7435:

  ARM: OMAP5: Enable build and frameowrk initialisations (2013-04-04 14:00:52 +0530)

----------------------------------------------------------------

Benoit Cousson (7):
  ARM: OMAP5: PRM: Add OMAP54XX register and bitfield files
  ARM: OMAP5: CM: Add OMAP54XX register and bitfield files
  ARM: OMAP5: PRCM: Add OMAP54XX local MPU PRCM registers
  ARM: OMAP5: SCRM: Add OMAP54XX header file.
  ARM: OMAP5: clockdomain data: Add OMAP54XX data and update the header
  ARM: OMAP5: powerdomain data: Add OMAP54XX data and update the header
  ARM: OMAP5: hwmod data: Create initial OMAP5 SOC hwmod data

Santosh Shilimkar (5):
  ARM: OMAP4+: PRM: Move function prototypes to common header for
    re-use
  ARM: OMAP4+: CM: Move function prototypes to common header for re-use
  ARM: OMAP4+: PRCM MPU: Move function prototypes to common header for
    re-use
  ARM: OMAP5: voltagedomain data: Add OMAP5 voltage domain data
  ARM: OMAP5: Enable build and frameowrk initialisations

 arch/arm/mach-omap2/Makefile                  |    4 +
 arch/arm/mach-omap2/clockdomain.h             |    1 +
 arch/arm/mach-omap2/clockdomains54xx_data.c   |  464 +++++
 arch/arm/mach-omap2/cm-regbits-54xx.h         | 1737 ++++++++++++++++
 arch/arm/mach-omap2/cm1_44xx.h                |    7 +-
 arch/arm/mach-omap2/cm1_54xx.h                |  218 ++
 arch/arm/mach-omap2/cm2_44xx.h                |    7 +-
 arch/arm/mach-omap2/cm2_54xx.h                |  394 ++++
 arch/arm/mach-omap2/cm_44xx_54xx.h            |   36 +
 arch/arm/mach-omap2/io.c                      |    7 +
 arch/arm/mach-omap2/omap_hwmod.h              |    1 +
 arch/arm/mach-omap2/omap_hwmod_54xx_data.c    | 2151 ++++++++++++++++++++
 arch/arm/mach-omap2/powerdomain.h             |    1 +
 arch/arm/mach-omap2/powerdomains54xx_data.c   |  331 +++
 arch/arm/mach-omap2/prcm44xx.h                |    6 +
 arch/arm/mach-omap2/prcm_mpu44xx.h            |   14 +-
 arch/arm/mach-omap2/prcm_mpu54xx.h            |   87 +
 arch/arm/mach-omap2/prcm_mpu_44xx_54xx.h      |   36 +
 arch/arm/mach-omap2/prm-regbits-54xx.h        | 2701 +++++++++++++++++++++++++
 arch/arm/mach-omap2/prm44xx.h                 |   33 +-
 arch/arm/mach-omap2/prm44xx_54xx.h            |   58 +
 arch/arm/mach-omap2/prm54xx.h                 |  421 ++++
 arch/arm/mach-omap2/scrm54xx.h                |  231 +++
 arch/arm/mach-omap2/voltage.h                 |    1 +
 arch/arm/mach-omap2/voltagedomains54xx_data.c |  102 +
 25 files changed, 8994 insertions(+), 55 deletions(-)
 create mode 100644 arch/arm/mach-omap2/clockdomains54xx_data.c
 create mode 100644 arch/arm/mach-omap2/cm-regbits-54xx.h
 create mode 100644 arch/arm/mach-omap2/cm1_54xx.h
 create mode 100644 arch/arm/mach-omap2/cm2_54xx.h
 create mode 100644 arch/arm/mach-omap2/cm_44xx_54xx.h
 create mode 100644 arch/arm/mach-omap2/omap_hwmod_54xx_data.c
 create mode 100644 arch/arm/mach-omap2/powerdomains54xx_data.c
 create mode 100644 arch/arm/mach-omap2/prcm_mpu54xx.h
 create mode 100644 arch/arm/mach-omap2/prcm_mpu_44xx_54xx.h
 create mode 100644 arch/arm/mach-omap2/prm-regbits-54xx.h
 create mode 100644 arch/arm/mach-omap2/prm44xx_54xx.h
 create mode 100644 arch/arm/mach-omap2/prm54xx.h
 create mode 100644 arch/arm/mach-omap2/scrm54xx.h
 create mode 100644 arch/arm/mach-omap2/voltagedomains54xx_data.c

-- 
1.7.9.5



From santosh.shilimkar at ti.com  Thu Apr  4 06:20:48 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Thu, 4 Apr 2013 15:50:48 +0530
Subject: [PATCH v2 01/12] ARM: OMAP4+: PRM: Move function prototypes to common
 header for re-use
In-Reply-To: <1365070859-21790-1-git-send-email-santosh.shilimkar@ti.com>
References: <1365070859-21790-1-git-send-email-santosh.shilimkar@ti.com>
Message-ID: <1365070859-21790-2-git-send-email-santosh.shilimkar@ti.com>

OMAP5 reuses OMAP4 PRM IP block which lets us re-use PRM functions.
So move the function prototypes from prm44xx.h to prm44xx_54xx.h
header. The suggestion came from Paul Walmsley as part of the
OMAP5 data file review.

This is preparatory  patch to add OMAP5 PRM data file.

Cc: Paul Walmsley <paul at pwsan.com>

Acked-by: Rajendra Nayak <rnayak at ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
---
 arch/arm/mach-omap2/prm44xx.h      |   33 +-------------------
 arch/arm/mach-omap2/prm44xx_54xx.h |   58 ++++++++++++++++++++++++++++++++++++
 2 files changed, 59 insertions(+), 32 deletions(-)
 create mode 100644 arch/arm/mach-omap2/prm44xx_54xx.h

diff --git a/arch/arm/mach-omap2/prm44xx.h b/arch/arm/mach-omap2/prm44xx.h
index 8ee1fbd..7db2422 100644
--- a/arch/arm/mach-omap2/prm44xx.h
+++ b/arch/arm/mach-omap2/prm44xx.h
@@ -25,6 +25,7 @@
 #ifndef __ARCH_ARM_MACH_OMAP2_PRM44XX_H
 #define __ARCH_ARM_MACH_OMAP2_PRM44XX_H
 
+#include "prm44xx_54xx.h"
 #include "prcm-common.h"
 #include "prm.h"
 
@@ -744,36 +745,4 @@
 #define OMAP4_PRM_VC_ERRST_OFFSET			0x00f8
 #define OMAP4430_PRM_VC_ERRST				OMAP44XX_PRM_REGADDR(OMAP4430_PRM_DEVICE_INST, 0x00f8)
 
-/* Function prototypes */
-# ifndef __ASSEMBLER__
-
-extern u32 omap4_prm_read_inst_reg(s16 inst, u16 idx);
-extern void omap4_prm_write_inst_reg(u32 val, s16 inst, u16 idx);
-extern u32 omap4_prm_rmw_inst_reg_bits(u32 mask, u32 bits, s16 inst, s16 idx);
-
-/* OMAP4-specific VP functions */
-u32 omap4_prm_vp_check_txdone(u8 vp_id);
-void omap4_prm_vp_clear_txdone(u8 vp_id);
-
-/*
- * OMAP4 access functions for voltage controller (VC) and
- * voltage proccessor (VP) in the PRM.
- */
-extern u32 omap4_prm_vcvp_read(u8 offset);
-extern void omap4_prm_vcvp_write(u32 val, u8 offset);
-extern u32 omap4_prm_vcvp_rmw(u32 mask, u32 bits, u8 offset);
-
-extern void omap44xx_prm_reconfigure_io_chain(void);
-
-/* PRM interrupt-related functions */
-extern void omap44xx_prm_read_pending_irqs(unsigned long *events);
-extern void omap44xx_prm_ocp_barrier(void);
-extern void omap44xx_prm_save_and_clear_irqen(u32 *saved_mask);
-extern void omap44xx_prm_restore_irqen(u32 *saved_mask);
-
-extern int __init omap44xx_prm_init(void);
-extern u32 omap44xx_prm_get_reset_sources(void);
-
-# endif
-
 #endif
diff --git a/arch/arm/mach-omap2/prm44xx_54xx.h b/arch/arm/mach-omap2/prm44xx_54xx.h
new file mode 100644
index 0000000..7cd22ab
--- /dev/null
+++ b/arch/arm/mach-omap2/prm44xx_54xx.h
@@ -0,0 +1,58 @@
+/*
+ * OMAP44xx and 54xx PRM common functions
+ *
+ * Copyright (C) 2009-2013 Texas Instruments, Inc.
+ * Copyright (C) 2009-2010 Nokia Corporation
+ *
+ * Paul Walmsley (paul at pwsan.com)
+ * Rajendra Nayak (rnayak at ti.com)
+ * Benoit Cousson (b-cousson at ti.com)
+ *
+ * This file is automatically generated from the OMAP hardware databases.
+ * We respectfully ask that any modifications to this file be coordinated
+ * with the public linux-omap at vger.kernel.org mailing list and the
+ * authors above to ensure that the autogeneration scripts are kept
+ * up-to-date with the file contents.
+ *
+ * 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.
+ *
+ */
+
+#ifndef __ARCH_ARM_MACH_OMAP2_PRM44XX_54XX_H
+#define __ARCH_ARM_MACH_OMAP2_PRM44XX_54XX_H
+
+/* Function prototypes */
+#ifndef __ASSEMBLER__
+
+extern u32 omap4_prm_read_inst_reg(s16 inst, u16 idx);
+extern void omap4_prm_write_inst_reg(u32 val, s16 inst, u16 idx);
+extern u32 omap4_prm_rmw_inst_reg_bits(u32 mask, u32 bits, s16 inst, s16 idx);
+
+/* OMAP4/OMAP5-specific VP functions */
+u32 omap4_prm_vp_check_txdone(u8 vp_id);
+void omap4_prm_vp_clear_txdone(u8 vp_id);
+
+/*
+ * OMAP4/OMAP5 access functions for voltage controller (VC) and
+ * voltage proccessor (VP) in the PRM.
+ */
+extern u32 omap4_prm_vcvp_read(u8 offset);
+extern void omap4_prm_vcvp_write(u32 val, u8 offset);
+extern u32 omap4_prm_vcvp_rmw(u32 mask, u32 bits, u8 offset);
+
+extern void omap44xx_prm_reconfigure_io_chain(void);
+
+/* PRM interrupt-related functions */
+extern void omap44xx_prm_read_pending_irqs(unsigned long *events);
+extern void omap44xx_prm_ocp_barrier(void);
+extern void omap44xx_prm_save_and_clear_irqen(u32 *saved_mask);
+extern void omap44xx_prm_restore_irqen(u32 *saved_mask);
+
+extern int __init omap44xx_prm_init(void);
+extern u32 omap44xx_prm_get_reset_sources(void);
+
+#endif
+
+#endif
-- 
1.7.9.5



From santosh.shilimkar at ti.com  Thu Apr  4 06:20:50 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Thu, 4 Apr 2013 15:50:50 +0530
Subject: [PATCH v2 03/12] ARM: OMAP4+: CM: Move function prototypes to common
 header for re-use
In-Reply-To: <1365070859-21790-1-git-send-email-santosh.shilimkar@ti.com>
References: <1365070859-21790-1-git-send-email-santosh.shilimkar@ti.com>
Message-ID: <1365070859-21790-4-git-send-email-santosh.shilimkar@ti.com>

OMAP5 reuses OMAP4 CM IP block which lets us re-use CM1/CM2 functions.
So move the function prototypes from cm1_44xx.h, cm2_44xx.h to
cm_prm44xx_54xx.h header. The suggestion came from Paul Walmsley
as part of the OMAP5 data file review.

This is preparatory  patch to add OMAP5 CM data file.

Cc: Paul Walmsley <paul at pwsan.com>

Acked-by: Rajendra Nayak <rnayak at ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
---
 arch/arm/mach-omap2/cm1_44xx.h     |    7 ++-----
 arch/arm/mach-omap2/cm2_44xx.h     |    7 ++-----
 arch/arm/mach-omap2/cm_44xx_54xx.h |   36 ++++++++++++++++++++++++++++++++++++
 3 files changed, 40 insertions(+), 10 deletions(-)
 create mode 100644 arch/arm/mach-omap2/cm_44xx_54xx.h

diff --git a/arch/arm/mach-omap2/cm1_44xx.h b/arch/arm/mach-omap2/cm1_44xx.h
index 1bc00dc..5ae8fe3 100644
--- a/arch/arm/mach-omap2/cm1_44xx.h
+++ b/arch/arm/mach-omap2/cm1_44xx.h
@@ -25,6 +25,8 @@
 #ifndef __ARCH_ARM_MACH_OMAP2_CM1_44XX_H
 #define __ARCH_ARM_MACH_OMAP2_CM1_44XX_H
 
+#include "cm_44xx_54xx.h"
+
 /* CM1 base address */
 #define OMAP4430_CM1_BASE		0x4a004000
 
@@ -217,9 +219,4 @@
 #define OMAP4_CM1_ABE_WDT3_CLKCTRL_OFFSET		0x0088
 #define OMAP4430_CM1_ABE_WDT3_CLKCTRL			OMAP44XX_CM1_REGADDR(OMAP4430_CM1_ABE_INST, 0x0088)
 
-/* Function prototypes */
-extern u32 omap4_cm1_read_inst_reg(s16 inst, u16 idx);
-extern void omap4_cm1_write_inst_reg(u32 val, s16 inst, u16 idx);
-extern u32 omap4_cm1_rmw_inst_reg_bits(u32 mask, u32 bits, s16 inst, s16 idx);
-
 #endif
diff --git a/arch/arm/mach-omap2/cm2_44xx.h b/arch/arm/mach-omap2/cm2_44xx.h
index b9de72d..ee5136d 100644
--- a/arch/arm/mach-omap2/cm2_44xx.h
+++ b/arch/arm/mach-omap2/cm2_44xx.h
@@ -25,6 +25,8 @@
 #ifndef __ARCH_ARM_MACH_OMAP2_CM2_44XX_H
 #define __ARCH_ARM_MACH_OMAP2_CM2_44XX_H
 
+#include "cm_44xx_54xx.h"
+
 /* CM2 base address */
 #define OMAP4430_CM2_BASE		0x4a008000
 
@@ -449,9 +451,4 @@
 #define OMAP4_CM_CEFUSE_CEFUSE_CLKCTRL_OFFSET		0x0020
 #define OMAP4430_CM_CEFUSE_CEFUSE_CLKCTRL		OMAP44XX_CM2_REGADDR(OMAP4430_CM2_CEFUSE_INST, 0x0020)
 
-/* Function prototypes */
-extern u32 omap4_cm2_read_inst_reg(s16 inst, u16 idx);
-extern void omap4_cm2_write_inst_reg(u32 val, s16 inst, u16 idx);
-extern u32 omap4_cm2_rmw_inst_reg_bits(u32 mask, u32 bits, s16 inst, s16 idx);
-
 #endif
diff --git a/arch/arm/mach-omap2/cm_44xx_54xx.h b/arch/arm/mach-omap2/cm_44xx_54xx.h
new file mode 100644
index 0000000..4154f86
--- /dev/null
+++ b/arch/arm/mach-omap2/cm_44xx_54xx.h
@@ -0,0 +1,36 @@
+/*
+ * OMAP44xx and OMAP54xx CM1/CM2 function prototypes
+ *
+ * Copyright (C) 2009-201333 Texas Instruments, Inc.
+ * Copyright (C) 2009-2010 Nokia Corporation
+ *
+ * Paul Walmsley (paul at pwsan.com)
+ * Rajendra Nayak (rnayak at ti.com)
+ * Benoit Cousson (b-cousson at ti.com)
+ *
+ * This file is automatically generated from the OMAP hardware databases.
+ * We respectfully ask that any modifications to this file be coordinated
+ * with the public linux-omap at vger.kernel.org mailing list and the
+ * authors above to ensure that the autogeneration scripts are kept
+ * up-to-date with the file contents.
+ *
+ * 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.
+ *
+ */
+
+#ifndef __ARCH_ARM_MACH_OMAP2_CM_44XX_54XX_H
+#define __ARCH_ARM_MACH_OMAP2_CM_44XX_55XX_H
+
+/* CM1 Function prototypes */
+extern u32 omap4_cm1_read_inst_reg(s16 inst, u16 idx);
+extern void omap4_cm1_write_inst_reg(u32 val, s16 inst, u16 idx);
+extern u32 omap4_cm1_rmw_inst_reg_bits(u32 mask, u32 bits, s16 inst, s16 idx);
+
+/* CM2 Function prototypes */
+extern u32 omap4_cm2_read_inst_reg(s16 inst, u16 idx);
+extern void omap4_cm2_write_inst_reg(u32 val, s16 inst, u16 idx);
+extern u32 omap4_cm2_rmw_inst_reg_bits(u32 mask, u32 bits, s16 inst, s16 idx);
+
+#endif
-- 
1.7.9.5



From santosh.shilimkar at ti.com  Thu Apr  4 06:20:52 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Thu, 4 Apr 2013 15:50:52 +0530
Subject: [PATCH v2 05/12] ARM: OMAP4+: PRCM MPU: Move function prototypes to
 common header for re-use
In-Reply-To: <1365070859-21790-1-git-send-email-santosh.shilimkar@ti.com>
References: <1365070859-21790-1-git-send-email-santosh.shilimkar@ti.com>
Message-ID: <1365070859-21790-6-git-send-email-santosh.shilimkar@ti.com>

OMAP5 reuses OMAP4 MPU PRCM IP block which lets us re-use functions.
So move the function prototypes from prcm_mpu44xx.h to prcm_mpu_44xx_54xx.h
header. The suggestion came from Paul Walmsley as part of the
OMAP5 data file review.

This is preparatory  patch to add OMAP5 MPU PRCM data file.

Cc: Paul Walmsley <paul at pwsan.com>

Acked-by: Rajendra Nayak <rnayak at ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
---
 arch/arm/mach-omap2/prcm_mpu44xx.h       |   14 +-----------
 arch/arm/mach-omap2/prcm_mpu_44xx_54xx.h |   36 ++++++++++++++++++++++++++++++
 2 files changed, 37 insertions(+), 13 deletions(-)
 create mode 100644 arch/arm/mach-omap2/prcm_mpu_44xx_54xx.h

diff --git a/arch/arm/mach-omap2/prcm_mpu44xx.h b/arch/arm/mach-omap2/prcm_mpu44xx.h
index 884af7b..059bd4f 100644
--- a/arch/arm/mach-omap2/prcm_mpu44xx.h
+++ b/arch/arm/mach-omap2/prcm_mpu44xx.h
@@ -25,12 +25,9 @@
 #ifndef __ARCH_ARM_MACH_OMAP2_PRCM_MPU44XX_H
 #define __ARCH_ARM_MACH_OMAP2_PRCM_MPU44XX_H
 
+#include "prcm_mpu_44xx_54xx.h"
 #include "common.h"
 
-# ifndef __ASSEMBLER__
-extern void __iomem *prcm_mpu_base;
-# endif
-
 #define OMAP4430_PRCM_MPU_BASE			0x48243000
 
 #define OMAP44XX_PRCM_MPU_REGADDR(inst, reg)				\
@@ -98,13 +95,4 @@ extern void __iomem *prcm_mpu_base;
 #define OMAP4_CM_CPU1_CLKSTCTRL_OFFSET		0x0018
 #define OMAP4430_CM_CPU1_CLKSTCTRL		OMAP44XX_PRCM_MPU_REGADDR(OMAP4430_PRCM_MPU_CPU1_INST, 0x0018)
 
-/* Function prototypes */
-# ifndef __ASSEMBLER__
-extern u32 omap4_prcm_mpu_read_inst_reg(s16 inst, u16 idx);
-extern void omap4_prcm_mpu_write_inst_reg(u32 val, s16 inst, u16 idx);
-extern u32 omap4_prcm_mpu_rmw_inst_reg_bits(u32 mask, u32 bits, s16 inst,
-					    s16 idx);
-extern void __init omap2_set_globals_prcm_mpu(void __iomem *prcm_mpu);
-# endif
-
 #endif
diff --git a/arch/arm/mach-omap2/prcm_mpu_44xx_54xx.h b/arch/arm/mach-omap2/prcm_mpu_44xx_54xx.h
new file mode 100644
index 0000000..ca149e7
--- /dev/null
+++ b/arch/arm/mach-omap2/prcm_mpu_44xx_54xx.h
@@ -0,0 +1,36 @@
+/*
+ * OMAP44xx and OMAP54xx PRCM MPU function prototypes
+ *
+ * Copyright (C) 2010, 2013 Texas Instruments, Inc.
+ * Copyright (C) 2010 Nokia Corporation
+ *
+ * Paul Walmsley (paul at pwsan.com)
+ * Rajendra Nayak (rnayak at ti.com)
+ * Benoit Cousson (b-cousson at ti.com)
+ *
+ * This file is automatically generated from the OMAP hardware databases.
+ * We respectfully ask that any modifications to this file be coordinated
+ * with the public linux-omap at vger.kernel.org mailing list and the
+ * authors above to ensure that the autogeneration scripts are kept
+ * up-to-date with the file contents.
+ *
+ * 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.
+ *
+ */
+
+#ifndef __ARCH_ARM_MACH_OMAP2_PRCM_MPU_44XX_54XX_H
+#define __ARCH_ARM_MACH_OMAP2_PRCM_MPU_44XX_54XX_H
+
+#ifndef __ASSEMBLER__
+extern void __iomem *prcm_mpu_base;
+
+extern u32 omap4_prcm_mpu_read_inst_reg(s16 inst, u16 idx);
+extern void omap4_prcm_mpu_write_inst_reg(u32 val, s16 inst, u16 idx);
+extern u32 omap4_prcm_mpu_rmw_inst_reg_bits(u32 mask, u32 bits, s16 inst,
+					    s16 idx);
+extern void __init omap2_set_globals_prcm_mpu(void __iomem *prcm_mpu);
+#endif
+
+#endif
-- 
1.7.9.5



From santosh.shilimkar at ti.com  Thu Apr  4 06:20:53 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Thu, 4 Apr 2013 15:50:53 +0530
Subject: [PATCH v2 06/12] ARM: OMAP5: PRCM: Add OMAP54XX local MPU PRCM
 registers
In-Reply-To: <1365070859-21790-1-git-send-email-santosh.shilimkar@ti.com>
References: <1365070859-21790-1-git-send-email-santosh.shilimkar@ti.com>
Message-ID: <1365070859-21790-7-git-send-email-santosh.shilimkar@ti.com>

From: Benoit Cousson <b-cousson at ti.com>

Add the PRCM MPU registers for OMAP54XX platforms.

Cc: Paul Walmsley <paul at pwsan.com>

Signed-off-by: Benoit Cousson <b-cousson at ti.com>
[santosh.shilimkar at ti.com: Generated es2.0 data]
Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
---
 arch/arm/mach-omap2/prcm44xx.h     |    6 +++
 arch/arm/mach-omap2/prcm_mpu54xx.h |   87 ++++++++++++++++++++++++++++++++++++
 2 files changed, 93 insertions(+)
 create mode 100644 arch/arm/mach-omap2/prcm_mpu54xx.h

diff --git a/arch/arm/mach-omap2/prcm44xx.h b/arch/arm/mach-omap2/prcm44xx.h
index 7334ffb..f429cdd 100644
--- a/arch/arm/mach-omap2/prcm44xx.h
+++ b/arch/arm/mach-omap2/prcm44xx.h
@@ -32,6 +32,12 @@
 #define OMAP4430_SCRM_PARTITION			4
 #define OMAP4430_PRCM_MPU_PARTITION		5
 
+#define OMAP54XX_PRM_PARTITION			1
+#define OMAP54XX_CM_CORE_AON_PARTITION		2
+#define OMAP54XX_CM_CORE_PARTITION		3
+#define OMAP54XX_SCRM_PARTITION			4
+#define OMAP54XX_PRCM_MPU_PARTITION		5
+
 /*
  * OMAP4_MAX_PRCM_PARTITIONS: set to the highest value of the PRCM partition
  * IDs, plus one
diff --git a/arch/arm/mach-omap2/prcm_mpu54xx.h b/arch/arm/mach-omap2/prcm_mpu54xx.h
new file mode 100644
index 0000000..bc2ce32
--- /dev/null
+++ b/arch/arm/mach-omap2/prcm_mpu54xx.h
@@ -0,0 +1,87 @@
+/*
+ * OMAP54xx PRCM MPU instance offset macros
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com
+ *
+ * Paul Walmsley (paul at pwsan.com)
+ * Rajendra Nayak (rnayak at ti.com)
+ * Benoit Cousson (b-cousson at ti.com)
+ *
+ * This file is automatically generated from the OMAP hardware databases.
+ * We respectfully ask that any modifications to this file be coordinated
+ * with the public linux-omap at vger.kernel.org mailing list and the
+ * authors above to ensure that the autogeneration scripts are kept
+ * up-to-date with the file contents.
+ *
+ * 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.
+ */
+
+#ifndef __ARCH_ARM_MACH_OMAP2_PRCM_MPU54XX_H
+#define __ARCH_ARM_MACH_OMAP2_PRCM_MPU54XX_H
+
+#include "prcm_mpu_44xx_54xx.h"
+#include "common.h"
+
+#define OMAP54XX_PRCM_MPU_BASE			0x48243000
+
+#define OMAP54XX_PRCM_MPU_REGADDR(inst, reg)				\
+	OMAP2_L4_IO_ADDRESS(OMAP54XX_PRCM_MPU_BASE + (inst) + (reg))
+
+/* PRCM_MPU instances */
+#define OMAP54XX_PRCM_MPU_OCP_SOCKET_INST	0x0000
+#define OMAP54XX_PRCM_MPU_DEVICE_INST		0x0200
+#define OMAP54XX_PRCM_MPU_PRM_C0_INST		0x0400
+#define OMAP54XX_PRCM_MPU_CM_C0_INST		0x0600
+#define OMAP54XX_PRCM_MPU_PRM_C1_INST		0x0800
+#define OMAP54XX_PRCM_MPU_CM_C1_INST		0x0a00
+
+/* PRCM_MPU clockdomain register offsets (from instance start) */
+#define OMAP54XX_PRCM_MPU_CM_C0_CPU0_CDOFFS	0x0000
+#define OMAP54XX_PRCM_MPU_CM_C1_CPU1_CDOFFS	0x0000
+
+
+/*
+ * PRCM_MPU
+ *
+ * The PRCM_MPU is a local PRCM inside the MPU subsystem. For the PRCM (global)
+ * point of view the PRCM_MPU is a single entity. It shares the same
+ * programming model as the global PRCM and thus can be assimilate as two new
+ * MOD inside the PRCM
+ */
+
+/* PRCM_MPU.PRCM_MPU_OCP_SOCKET register offsets */
+#define OMAP54XX_REVISION_PRCM_MPU_OFFSET			0x0000
+
+/* PRCM_MPU.PRCM_MPU_DEVICE register offsets */
+#define OMAP54XX_PRCM_MPU_PRM_RSTST_OFFSET			0x0000
+#define OMAP54XX_PRCM_MPU_PRM_PSCON_COUNT_OFFSET		0x0004
+#define OMAP54XX_PRM_FRAC_INCREMENTER_NUMERATOR_OFFSET		0x0010
+#define OMAP54XX_PRM_FRAC_INCREMENTER_DENUMERATOR_RELOAD_OFFSET	0x0014
+
+/* PRCM_MPU.PRCM_MPU_PRM_C0 register offsets */
+#define OMAP54XX_PM_CPU0_PWRSTCTRL_OFFSET			0x0000
+#define OMAP54XX_PM_CPU0_PWRSTST_OFFSET				0x0004
+#define OMAP54XX_RM_CPU0_CPU0_RSTCTRL_OFFSET			0x0010
+#define OMAP54XX_RM_CPU0_CPU0_RSTST_OFFSET			0x0014
+#define OMAP54XX_RM_CPU0_CPU0_CONTEXT_OFFSET			0x0024
+
+/* PRCM_MPU.PRCM_MPU_CM_C0 register offsets */
+#define OMAP54XX_CM_CPU0_CLKSTCTRL_OFFSET			0x0000
+#define OMAP54XX_CM_CPU0_CPU0_CLKCTRL_OFFSET			0x0020
+#define OMAP54XX_CM_CPU0_CPU0_CLKCTRL				OMAP54XX_PRCM_MPU_REGADDR(OMAP54XX_PRCM_MPU_CM_C0_INST, 0x0020)
+
+/* PRCM_MPU.PRCM_MPU_PRM_C1 register offsets */
+#define OMAP54XX_PM_CPU1_PWRSTCTRL_OFFSET			0x0000
+#define OMAP54XX_PM_CPU1_PWRSTST_OFFSET				0x0004
+#define OMAP54XX_RM_CPU1_CPU1_RSTCTRL_OFFSET			0x0010
+#define OMAP54XX_RM_CPU1_CPU1_RSTST_OFFSET			0x0014
+#define OMAP54XX_RM_CPU1_CPU1_CONTEXT_OFFSET			0x0024
+
+/* PRCM_MPU.PRCM_MPU_CM_C1 register offsets */
+#define OMAP54XX_CM_CPU1_CLKSTCTRL_OFFSET			0x0000
+#define OMAP54XX_CM_CPU1_CPU1_CLKCTRL_OFFSET			0x0020
+#define OMAP54XX_CM_CPU1_CPU1_CLKCTRL				OMAP54XX_PRCM_MPU_REGADDR(OMAP54XX_PRCM_MPU_CM_C1_INST, 0x0020)
+
+#endif
-- 
1.7.9.5



From santosh.shilimkar at ti.com  Thu Apr  4 06:20:54 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Thu, 4 Apr 2013 15:50:54 +0530
Subject: [PATCH v2 07/12] ARM: OMAP5: SCRM: Add OMAP54XX header file.
In-Reply-To: <1365070859-21790-1-git-send-email-santosh.shilimkar@ti.com>
References: <1365070859-21790-1-git-send-email-santosh.shilimkar@ti.com>
Message-ID: <1365070859-21790-8-git-send-email-santosh.shilimkar@ti.com>

From: Benoit Cousson <b-cousson at ti.com>

Adding the OMAP5 specific header for SCRM module.

Cc: Paul Walmsley <paul at pwsan.com>

Signed-off-by: Benoit Cousson <b-cousson at ti.com>
[santosh.shilimkar at ti.com: Generated es2.0 data]
Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
---
 arch/arm/mach-omap2/scrm54xx.h |  231 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 231 insertions(+)
 create mode 100644 arch/arm/mach-omap2/scrm54xx.h

diff --git a/arch/arm/mach-omap2/scrm54xx.h b/arch/arm/mach-omap2/scrm54xx.h
new file mode 100644
index 0000000..57e86c8
--- /dev/null
+++ b/arch/arm/mach-omap2/scrm54xx.h
@@ -0,0 +1,231 @@
+/*
+ * OMAP54XX SCRM registers and bitfields
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com
+ *
+ * Benoit Cousson (b-cousson at ti.com)
+ *
+ * This file is automatically generated from the OMAP hardware databases.
+ * We respectfully ask that any modifications to this file be coordinated
+ * with the public linux-omap at vger.kernel.org mailing list and the
+ * authors above to ensure that the autogeneration scripts are kept
+ * up-to-date with the file contents.
+ *
+ * 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.
+ */
+
+#ifndef __ARCH_ARM_MACH_OMAP2_SCRM_54XX_H
+#define __ARCH_ARM_MACH_OMAP2_SCRM_54XX_H
+
+#define OMAP5_SCRM_BASE		0x4ae0a000
+
+#define OMAP54XX_SCRM_REGADDR(reg)				\
+	OMAP2_L4_IO_ADDRESS(OMAP5_SCRM_BASE + (reg))
+
+/* SCRM */
+
+/* SCRM.SCRM register offsets */
+#define OMAP5_SCRM_REVISION_SCRM_OFFSET		0x0000
+#define OMAP5_SCRM_REVISION_SCRM		OMAP54XX_SCRM_REGADDR(0x0000)
+#define OMAP5_SCRM_CLKSETUPTIME_OFFSET		0x0100
+#define OMAP5_SCRM_CLKSETUPTIME			OMAP54XX_SCRM_REGADDR(0x0100)
+#define OMAP5_SCRM_PMICSETUPTIME_OFFSET		0x0104
+#define OMAP5_SCRM_PMICSETUPTIME		OMAP54XX_SCRM_REGADDR(0x0104)
+#define OMAP5_SCRM_ALTCLKSRC_OFFSET		0x0110
+#define OMAP5_SCRM_ALTCLKSRC			OMAP54XX_SCRM_REGADDR(0x0110)
+#define OMAP5_SCRM_MODEMCLKM_OFFSET		0x0118
+#define OMAP5_SCRM_MODEMCLKM			OMAP54XX_SCRM_REGADDR(0x0118)
+#define OMAP5_SCRM_D2DCLKM_OFFSET		0x011c
+#define OMAP5_SCRM_D2DCLKM			OMAP54XX_SCRM_REGADDR(0x011c)
+#define OMAP5_SCRM_EXTCLKREQ_OFFSET		0x0200
+#define OMAP5_SCRM_EXTCLKREQ			OMAP54XX_SCRM_REGADDR(0x0200)
+#define OMAP5_SCRM_ACCCLKREQ_OFFSET		0x0204
+#define OMAP5_SCRM_ACCCLKREQ			OMAP54XX_SCRM_REGADDR(0x0204)
+#define OMAP5_SCRM_PWRREQ_OFFSET		0x0208
+#define OMAP5_SCRM_PWRREQ			OMAP54XX_SCRM_REGADDR(0x0208)
+#define OMAP5_SCRM_AUXCLKREQ0_OFFSET		0x0210
+#define OMAP5_SCRM_AUXCLKREQ0			OMAP54XX_SCRM_REGADDR(0x0210)
+#define OMAP5_SCRM_AUXCLKREQ1_OFFSET		0x0214
+#define OMAP5_SCRM_AUXCLKREQ1			OMAP54XX_SCRM_REGADDR(0x0214)
+#define OMAP5_SCRM_AUXCLKREQ2_OFFSET		0x0218
+#define OMAP5_SCRM_AUXCLKREQ2			OMAP54XX_SCRM_REGADDR(0x0218)
+#define OMAP5_SCRM_AUXCLKREQ3_OFFSET		0x021c
+#define OMAP5_SCRM_AUXCLKREQ3			OMAP54XX_SCRM_REGADDR(0x021c)
+#define OMAP5_SCRM_AUXCLKREQ4_OFFSET		0x0220
+#define OMAP5_SCRM_AUXCLKREQ4			OMAP54XX_SCRM_REGADDR(0x0220)
+#define OMAP5_SCRM_AUXCLKREQ5_OFFSET		0x0224
+#define OMAP5_SCRM_AUXCLKREQ5			OMAP54XX_SCRM_REGADDR(0x0224)
+#define OMAP5_SCRM_D2DCLKREQ_OFFSET		0x0234
+#define OMAP5_SCRM_D2DCLKREQ			OMAP54XX_SCRM_REGADDR(0x0234)
+#define OMAP5_SCRM_AUXCLK0_OFFSET		0x0310
+#define OMAP5_SCRM_AUXCLK0			OMAP54XX_SCRM_REGADDR(0x0310)
+#define OMAP5_SCRM_AUXCLK1_OFFSET		0x0314
+#define OMAP5_SCRM_AUXCLK1			OMAP54XX_SCRM_REGADDR(0x0314)
+#define OMAP5_SCRM_AUXCLK2_OFFSET		0x0318
+#define OMAP5_SCRM_AUXCLK2			OMAP54XX_SCRM_REGADDR(0x0318)
+#define OMAP5_SCRM_AUXCLK3_OFFSET		0x031c
+#define OMAP5_SCRM_AUXCLK3			OMAP54XX_SCRM_REGADDR(0x031c)
+#define OMAP5_SCRM_AUXCLK4_OFFSET		0x0320
+#define OMAP5_SCRM_AUXCLK4			OMAP54XX_SCRM_REGADDR(0x0320)
+#define OMAP5_SCRM_AUXCLK5_OFFSET		0x0324
+#define OMAP5_SCRM_AUXCLK5			OMAP54XX_SCRM_REGADDR(0x0324)
+#define OMAP5_SCRM_RSTTIME_OFFSET		0x0400
+#define OMAP5_SCRM_RSTTIME			OMAP54XX_SCRM_REGADDR(0x0400)
+#define OMAP5_SCRM_MODEMRSTCTRL_OFFSET		0x0418
+#define OMAP5_SCRM_MODEMRSTCTRL			OMAP54XX_SCRM_REGADDR(0x0418)
+#define OMAP5_SCRM_D2DRSTCTRL_OFFSET		0x041c
+#define OMAP5_SCRM_D2DRSTCTRL			OMAP54XX_SCRM_REGADDR(0x041c)
+#define OMAP5_SCRM_EXTPWRONRSTCTRL_OFFSET	0x0420
+#define OMAP5_SCRM_EXTPWRONRSTCTRL		OMAP54XX_SCRM_REGADDR(0x0420)
+#define OMAP5_SCRM_EXTWARMRSTST_OFFSET		0x0510
+#define OMAP5_SCRM_EXTWARMRSTST			OMAP54XX_SCRM_REGADDR(0x0510)
+#define OMAP5_SCRM_APEWARMRSTST_OFFSET		0x0514
+#define OMAP5_SCRM_APEWARMRSTST			OMAP54XX_SCRM_REGADDR(0x0514)
+#define OMAP5_SCRM_MODEMWARMRSTST_OFFSET	0x0518
+#define OMAP5_SCRM_MODEMWARMRSTST		OMAP54XX_SCRM_REGADDR(0x0518)
+#define OMAP5_SCRM_D2DWARMRSTST_OFFSET		0x051c
+#define OMAP5_SCRM_D2DWARMRSTST			OMAP54XX_SCRM_REGADDR(0x051c)
+
+/*
+ * Used by AUXCLKREQ0, AUXCLKREQ1, AUXCLKREQ2, AUXCLKREQ3, AUXCLKREQ4,
+ * AUXCLKREQ5, D2DCLKREQ
+ */
+#define OMAP5_ACCURACY_SHIFT			1
+#define OMAP5_ACCURACY_WIDTH			0x1
+#define OMAP5_ACCURACY_MASK			(1 << 1)
+
+/* Used by APEWARMRSTST */
+#define OMAP5_APEWARMRSTST_SHIFT		1
+#define OMAP5_APEWARMRSTST_WIDTH		0x1
+#define OMAP5_APEWARMRSTST_MASK			(1 << 1)
+
+/* Used by AUXCLK0, AUXCLK1, AUXCLK2, AUXCLK3, AUXCLK4, AUXCLK5 */
+#define OMAP5_CLKDIV_SHIFT			16
+#define OMAP5_CLKDIV_WIDTH			0x4
+#define OMAP5_CLKDIV_MASK			(0xf << 16)
+
+/* Used by D2DCLKM, MODEMCLKM */
+#define OMAP5_CLK_32KHZ_SHIFT			0
+#define OMAP5_CLK_32KHZ_WIDTH			0x1
+#define OMAP5_CLK_32KHZ_MASK			(1 << 0)
+
+/* Used by D2DRSTCTRL, MODEMRSTCTRL */
+#define OMAP5_COLDRST_SHIFT			0
+#define OMAP5_COLDRST_WIDTH			0x1
+#define OMAP5_COLDRST_MASK			(1 << 0)
+
+/* Used by D2DWARMRSTST */
+#define OMAP5_D2DWARMRSTST_SHIFT		3
+#define OMAP5_D2DWARMRSTST_WIDTH		0x1
+#define OMAP5_D2DWARMRSTST_MASK			(1 << 3)
+
+/* Used by AUXCLK0 */
+#define OMAP5_DISABLECLK_SHIFT			9
+#define OMAP5_DISABLECLK_WIDTH			0x1
+#define OMAP5_DISABLECLK_MASK			(1 << 9)
+
+/* Used by CLKSETUPTIME */
+#define OMAP5_DOWNTIME_SHIFT			16
+#define OMAP5_DOWNTIME_WIDTH			0x6
+#define OMAP5_DOWNTIME_MASK			(0x3f << 16)
+
+/* Used by AUXCLK0, AUXCLK1, AUXCLK2, AUXCLK3, AUXCLK4, AUXCLK5 */
+#define OMAP5_ENABLE_SHIFT			8
+#define OMAP5_ENABLE_WIDTH			0x1
+#define OMAP5_ENABLE_MASK			(1 << 8)
+
+/* Renamed from ENABLE Used by EXTPWRONRSTCTRL */
+#define OMAP5_ENABLE_0_0_SHIFT			0
+#define OMAP5_ENABLE_0_0_WIDTH			0x1
+#define OMAP5_ENABLE_0_0_MASK			(1 << 0)
+
+/* Used by ALTCLKSRC */
+#define OMAP5_ENABLE_EXT_SHIFT			3
+#define OMAP5_ENABLE_EXT_WIDTH			0x1
+#define OMAP5_ENABLE_EXT_MASK			(1 << 3)
+
+/* Used by ALTCLKSRC */
+#define OMAP5_ENABLE_INT_SHIFT			2
+#define OMAP5_ENABLE_INT_WIDTH			0x1
+#define OMAP5_ENABLE_INT_MASK			(1 << 2)
+
+/* Used by EXTWARMRSTST */
+#define OMAP5_EXTWARMRSTST_SHIFT		0
+#define OMAP5_EXTWARMRSTST_WIDTH		0x1
+#define OMAP5_EXTWARMRSTST_MASK			(1 << 0)
+
+/*
+ * Used by AUXCLKREQ0, AUXCLKREQ1, AUXCLKREQ2, AUXCLKREQ3, AUXCLKREQ4,
+ * AUXCLKREQ5
+ */
+#define OMAP5_MAPPING_SHIFT			2
+#define OMAP5_MAPPING_WIDTH			0x3
+#define OMAP5_MAPPING_MASK			(0x7 << 2)
+
+/* Used by ALTCLKSRC */
+#define OMAP5_MODE_SHIFT			0
+#define OMAP5_MODE_WIDTH			0x2
+#define OMAP5_MODE_MASK				(0x3 << 0)
+
+/* Used by MODEMWARMRSTST */
+#define OMAP5_MODEMWARMRSTST_SHIFT		2
+#define OMAP5_MODEMWARMRSTST_WIDTH		0x1
+#define OMAP5_MODEMWARMRSTST_MASK		(1 << 2)
+
+/*
+ * Used by ACCCLKREQ, AUXCLK0, AUXCLK1, AUXCLK2, AUXCLK3, AUXCLK4, AUXCLK5,
+ * AUXCLKREQ0, AUXCLKREQ1, AUXCLKREQ2, AUXCLKREQ3, AUXCLKREQ4, AUXCLKREQ5,
+ * D2DCLKREQ, EXTCLKREQ, PWRREQ
+ */
+#define OMAP5_POLARITY_SHIFT			0
+#define OMAP5_POLARITY_WIDTH			0x1
+#define OMAP5_POLARITY_MASK			(1 << 0)
+
+/* Used by EXTPWRONRSTCTRL */
+#define OMAP5_PWRONRST_SHIFT			1
+#define OMAP5_PWRONRST_WIDTH			0x1
+#define OMAP5_PWRONRST_MASK			(1 << 1)
+
+/* Used by REVISION_SCRM */
+#define OMAP5_REV_SHIFT				0
+#define OMAP5_REV_WIDTH				0x8
+#define OMAP5_REV_MASK				(0xff << 0)
+
+/* Used by RSTTIME */
+#define OMAP5_RSTTIME_SHIFT			0
+#define OMAP5_RSTTIME_WIDTH			0x4
+#define OMAP5_RSTTIME_MASK			(0xf << 0)
+
+/* Used by CLKSETUPTIME */
+#define OMAP5_SETUPTIME_SHIFT			0
+#define OMAP5_SETUPTIME_WIDTH			0xc
+#define OMAP5_SETUPTIME_MASK			(0xfff << 0)
+
+/* Used by PMICSETUPTIME */
+#define OMAP5_SLEEPTIME_SHIFT			0
+#define OMAP5_SLEEPTIME_WIDTH			0x6
+#define OMAP5_SLEEPTIME_MASK			(0x3f << 0)
+
+/* Used by AUXCLK0, AUXCLK1, AUXCLK2, AUXCLK3, AUXCLK4, AUXCLK5 */
+#define OMAP5_SRCSELECT_SHIFT			1
+#define OMAP5_SRCSELECT_WIDTH			0x2
+#define OMAP5_SRCSELECT_MASK			(0x3 << 1)
+
+/* Used by D2DCLKM */
+#define OMAP5_SYSCLK_SHIFT			1
+#define OMAP5_SYSCLK_WIDTH			0x1
+#define OMAP5_SYSCLK_MASK			(1 << 1)
+
+/* Used by PMICSETUPTIME */
+#define OMAP5_WAKEUPTIME_SHIFT			16
+#define OMAP5_WAKEUPTIME_WIDTH			0x6
+#define OMAP5_WAKEUPTIME_MASK			(0x3f << 16)
+
+/* Used by D2DRSTCTRL, MODEMRSTCTRL */
+#define OMAP5_WARMRST_SHIFT			1
+#define OMAP5_WARMRST_WIDTH			0x1
+#define OMAP5_WARMRST_MASK			(1 << 1)
+
+#endif
-- 
1.7.9.5



From santosh.shilimkar at ti.com  Thu Apr  4 06:20:59 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Thu, 4 Apr 2013 15:50:59 +0530
Subject: [PATCH v2 12/12] ARM: OMAP5: Enable build and frameowrk
 initialisations
In-Reply-To: <1365070859-21790-1-git-send-email-santosh.shilimkar@ti.com>
References: <1365070859-21790-1-git-send-email-santosh.shilimkar@ti.com>
Message-ID: <1365070859-21790-13-git-send-email-santosh.shilimkar@ti.com>

Include the OMAP5 data files in build. Initialise the voltage, power,
clock domains.

Cc: Paul Walmsley <paul at pwsan.com>

Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
---
 arch/arm/mach-omap2/Makefile |    4 ++++
 arch/arm/mach-omap2/io.c     |    7 +++++++
 2 files changed, 11 insertions(+)

diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index b068b7f..5d5ff91 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -127,6 +127,7 @@ obj-$(CONFIG_ARCH_OMAP4)		+= voltagedomains44xx_data.o
 obj-$(CONFIG_SOC_AM33XX)		+= $(voltagedomain-common)
 obj-$(CONFIG_SOC_AM33XX)                += voltagedomains33xx_data.o
 obj-$(CONFIG_SOC_OMAP5)			+= $(voltagedomain-common)
+obj-$(CONFIG_SOC_OMAP5)                += voltagedomains54xx_data.o
 
 # OMAP powerdomain framework
 powerdomain-common			+= powerdomain.o powerdomain-common.o
@@ -141,6 +142,7 @@ obj-$(CONFIG_ARCH_OMAP4)		+= powerdomains44xx_data.o
 obj-$(CONFIG_SOC_AM33XX)		+= $(powerdomain-common)
 obj-$(CONFIG_SOC_AM33XX)		+= powerdomains33xx_data.o
 obj-$(CONFIG_SOC_OMAP5)			+= $(powerdomain-common)
+obj-$(CONFIG_SOC_OMAP5)			+= powerdomains54xx_data.o
 
 # PRCM clockdomain control
 clockdomain-common			+= clockdomain.o
@@ -156,6 +158,7 @@ obj-$(CONFIG_ARCH_OMAP4)		+= clockdomains44xx_data.o
 obj-$(CONFIG_SOC_AM33XX)		+= $(clockdomain-common)
 obj-$(CONFIG_SOC_AM33XX)		+= clockdomains33xx_data.o
 obj-$(CONFIG_SOC_OMAP5)			+= $(clockdomain-common)
+obj-$(CONFIG_SOC_OMAP5)			+= clockdomains54xx_data.o
 
 # Clock framework
 obj-$(CONFIG_ARCH_OMAP2)		+= $(clock-common) clock2xxx.o
@@ -198,6 +201,7 @@ obj-$(CONFIG_ARCH_OMAP3)		+= omap_hwmod_2xxx_3xxx_interconnect_data.o
 obj-$(CONFIG_ARCH_OMAP3)		+= omap_hwmod_3xxx_data.o
 obj-$(CONFIG_SOC_AM33XX)		+= omap_hwmod_33xx_data.o
 obj-$(CONFIG_ARCH_OMAP4)		+= omap_hwmod_44xx_data.o
+obj-$(CONFIG_SOC_OMAP5)			+= omap_hwmod_54xx_data.o
 
 # EMU peripherals
 obj-$(CONFIG_OMAP3_EMU)			+= emu.o
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 2c3fdd6..e0cea6f 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -618,7 +618,14 @@ void __init omap5_init_early(void)
 	omap2_set_globals_prcm_mpu(OMAP2_L4_IO_ADDRESS(OMAP54XX_PRCM_MPU_BASE));
 	omap_prm_base_init();
 	omap_cm_base_init();
+	omap44xx_prm_init();
 	omap5xxx_check_revision();
+	omap54xx_voltagedomains_init();
+	omap54xx_powerdomains_init();
+	omap54xx_clockdomains_init();
+	omap54xx_hwmod_init();
+	omap_hwmod_init_postsetup();
+
 }
 #endif
 
-- 
1.7.9.5



From santosh.shilimkar at ti.com  Thu Apr  4 06:20:56 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Thu, 4 Apr 2013 15:50:56 +0530
Subject: [PATCH v2 09/12] ARM: OMAP5: powerdomain data: Add OMAP54XX data and
 update the header
In-Reply-To: <1365070859-21790-1-git-send-email-santosh.shilimkar@ti.com>
References: <1365070859-21790-1-git-send-email-santosh.shilimkar@ti.com>
Message-ID: <1365070859-21790-10-git-send-email-santosh.shilimkar@ti.com>

From: Benoit Cousson <b-cousson at ti.com>

Add the data file to describe all power domains inside the OMAP54XX soc.

Cc: Paul Walmsley <paul at pwsan.com>

Signed-off-by: Benoit Cousson <b-cousson at ti.com>
[santosh.shilimkar at ti.com: Generated es2.0 data]
Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
---
 arch/arm/mach-omap2/powerdomain.h           |    1 +
 arch/arm/mach-omap2/powerdomains54xx_data.c |  331 +++++++++++++++++++++++++++
 2 files changed, 332 insertions(+)
 create mode 100644 arch/arm/mach-omap2/powerdomains54xx_data.c

diff --git a/arch/arm/mach-omap2/powerdomain.h b/arch/arm/mach-omap2/powerdomain.h
index 140c360..3d82f50 100644
--- a/arch/arm/mach-omap2/powerdomain.h
+++ b/arch/arm/mach-omap2/powerdomain.h
@@ -253,6 +253,7 @@ extern void omap243x_powerdomains_init(void);
 extern void omap3xxx_powerdomains_init(void);
 extern void am33xx_powerdomains_init(void);
 extern void omap44xx_powerdomains_init(void);
+extern void omap54xx_powerdomains_init(void);
 
 extern struct pwrdm_ops omap2_pwrdm_operations;
 extern struct pwrdm_ops omap3_pwrdm_operations;
diff --git a/arch/arm/mach-omap2/powerdomains54xx_data.c b/arch/arm/mach-omap2/powerdomains54xx_data.c
new file mode 100644
index 0000000..81f8a7c
--- /dev/null
+++ b/arch/arm/mach-omap2/powerdomains54xx_data.c
@@ -0,0 +1,331 @@
+/*
+ * OMAP54XX Power domains framework
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ *
+ * Abhijit Pagare (abhijitpagare at ti.com)
+ * Benoit Cousson (b-cousson at ti.com)
+ * Paul Walmsley (paul at pwsan.com)
+ *
+ * This file is automatically generated from the OMAP hardware databases.
+ * We respectfully ask that any modifications to this file be coordinated
+ * with the public linux-omap at vger.kernel.org mailing list and the
+ * authors above to ensure that the autogeneration scripts are kept
+ * up-to-date with the file contents.
+ *
+ * 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/init.h>
+
+#include "powerdomain.h"
+
+#include "prcm-common.h"
+#include "prcm44xx.h"
+#include "prm-regbits-54xx.h"
+#include "prm54xx.h"
+#include "prcm_mpu54xx.h"
+
+/* core_54xx_pwrdm: CORE power domain */
+static struct powerdomain core_54xx_pwrdm = {
+	.name		  = "core_pwrdm",
+	.voltdm		  = { .name = "core" },
+	.prcm_offs	  = OMAP54XX_PRM_CORE_INST,
+	.prcm_partition	  = OMAP54XX_PRM_PARTITION,
+	.pwrsts		  = PWRSTS_RET_ON,
+	.pwrsts_logic_ret = PWRSTS_OFF_RET,
+	.banks		  = 5,
+	.pwrsts_mem_ret	= {
+		[0] = PWRSTS_OFF_RET,	/* core_nret_bank */
+		[1] = PWRSTS_OFF_RET,	/* core_ocmram */
+		[2] = PWRSTS_OFF_RET,	/* core_other_bank */
+		[3] = PWRSTS_OFF_RET,	/* ipu_l2ram */
+		[4] = PWRSTS_OFF_RET,	/* ipu_unicache */
+	},
+	.pwrsts_mem_on	= {
+		[0] = PWRSTS_OFF_RET,	/* core_nret_bank */
+		[1] = PWRSTS_OFF_RET,	/* core_ocmram */
+		[2] = PWRSTS_OFF_RET,	/* core_other_bank */
+		[3] = PWRSTS_OFF_RET,	/* ipu_l2ram */
+		[4] = PWRSTS_OFF_RET,	/* ipu_unicache */
+	},
+	.flags		  = PWRDM_HAS_LOWPOWERSTATECHANGE,
+};
+
+/* abe_54xx_pwrdm: Audio back end power domain */
+static struct powerdomain abe_54xx_pwrdm = {
+	.name		  = "abe_pwrdm",
+	.voltdm		  = { .name = "core" },
+	.prcm_offs	  = OMAP54XX_PRM_ABE_INST,
+	.prcm_partition	  = OMAP54XX_PRM_PARTITION,
+	.pwrsts		  = PWRSTS_OFF_RET_ON,
+	.pwrsts_logic_ret = PWRSTS_OFF,
+	.banks		  = 2,
+	.pwrsts_mem_ret	= {
+		[0] = PWRSTS_OFF_RET,	/* aessmem */
+		[1] = PWRSTS_OFF_RET,	/* periphmem */
+	},
+	.pwrsts_mem_on	= {
+		[0] = PWRSTS_OFF_RET,	/* aessmem */
+		[1] = PWRSTS_OFF_RET,	/* periphmem */
+	},
+	.flags		  = PWRDM_HAS_LOWPOWERSTATECHANGE,
+};
+
+/* coreaon_54xx_pwrdm: Always ON logic that sits in VDD_CORE voltage domain */
+static struct powerdomain coreaon_54xx_pwrdm = {
+	.name		  = "coreaon_pwrdm",
+	.voltdm		  = { .name = "core" },
+	.prcm_offs	  = OMAP54XX_PRM_COREAON_INST,
+	.prcm_partition	  = OMAP54XX_PRM_PARTITION,
+	.pwrsts		  = PWRSTS_ON,
+};
+
+/* dss_54xx_pwrdm: Display subsystem power domain */
+static struct powerdomain dss_54xx_pwrdm = {
+	.name		  = "dss_pwrdm",
+	.voltdm		  = { .name = "core" },
+	.prcm_offs	  = OMAP54XX_PRM_DSS_INST,
+	.prcm_partition	  = OMAP54XX_PRM_PARTITION,
+	.pwrsts		  = PWRSTS_OFF_RET_ON,
+	.pwrsts_logic_ret = PWRSTS_OFF,
+	.banks		  = 1,
+	.pwrsts_mem_ret	= {
+		[0] = PWRSTS_OFF_RET,	/* dss_mem */
+	},
+	.pwrsts_mem_on	= {
+		[0] = PWRSTS_OFF_RET,	/* dss_mem */
+	},
+	.flags		  = PWRDM_HAS_LOWPOWERSTATECHANGE,
+};
+
+/* cpu0_54xx_pwrdm: MPU0 processor and Neon coprocessor power domain */
+static struct powerdomain cpu0_54xx_pwrdm = {
+	.name		  = "cpu0_pwrdm",
+	.voltdm		  = { .name = "mpu" },
+	.prcm_offs	  = OMAP54XX_PRCM_MPU_PRM_C0_INST,
+	.prcm_partition	  = OMAP54XX_PRCM_MPU_PARTITION,
+	.pwrsts		  = PWRSTS_OFF_RET_ON,
+	.pwrsts_logic_ret = PWRSTS_OFF_RET,
+	.banks		  = 1,
+	.pwrsts_mem_ret	= {
+		[0] = PWRSTS_OFF_RET,	/* cpu0_l1 */
+	},
+	.pwrsts_mem_on	= {
+		[0] = PWRSTS_ON,	/* cpu0_l1 */
+	},
+};
+
+/* cpu1_54xx_pwrdm: MPU1 processor and Neon coprocessor power domain */
+static struct powerdomain cpu1_54xx_pwrdm = {
+	.name		  = "cpu1_pwrdm",
+	.voltdm		  = { .name = "mpu" },
+	.prcm_offs	  = OMAP54XX_PRCM_MPU_PRM_C1_INST,
+	.prcm_partition	  = OMAP54XX_PRCM_MPU_PARTITION,
+	.pwrsts		  = PWRSTS_OFF_RET_ON,
+	.pwrsts_logic_ret = PWRSTS_OFF_RET,
+	.banks		  = 1,
+	.pwrsts_mem_ret	= {
+		[0] = PWRSTS_OFF_RET,	/* cpu1_l1 */
+	},
+	.pwrsts_mem_on	= {
+		[0] = PWRSTS_ON,	/* cpu1_l1 */
+	},
+};
+
+/* emu_54xx_pwrdm: Emulation power domain */
+static struct powerdomain emu_54xx_pwrdm = {
+	.name		  = "emu_pwrdm",
+	.voltdm		  = { .name = "wkup" },
+	.prcm_offs	  = OMAP54XX_PRM_EMU_INST,
+	.prcm_partition	  = OMAP54XX_PRM_PARTITION,
+	.pwrsts		  = PWRSTS_OFF_ON,
+	.banks		  = 1,
+	.pwrsts_mem_ret	= {
+		[0] = PWRSTS_OFF_RET,	/* emu_bank */
+	},
+	.pwrsts_mem_on	= {
+		[0] = PWRSTS_OFF_RET,	/* emu_bank */
+	},
+};
+
+/* mpu_54xx_pwrdm: Modena processor and the Neon coprocessor power domain */
+static struct powerdomain mpu_54xx_pwrdm = {
+	.name		  = "mpu_pwrdm",
+	.voltdm		  = { .name = "mpu" },
+	.prcm_offs	  = OMAP54XX_PRM_MPU_INST,
+	.prcm_partition	  = OMAP54XX_PRM_PARTITION,
+	.pwrsts		  = PWRSTS_RET_ON,
+	.pwrsts_logic_ret = PWRSTS_OFF_RET,
+	.banks		  = 2,
+	.pwrsts_mem_ret	= {
+		[0] = PWRSTS_OFF_RET,	/* mpu_l2 */
+		[1] = PWRSTS_RET,	/* mpu_ram */
+	},
+	.pwrsts_mem_on	= {
+		[0] = PWRSTS_OFF_RET,	/* mpu_l2 */
+		[1] = PWRSTS_OFF_RET,	/* mpu_ram */
+	},
+};
+
+/* custefuse_54xx_pwrdm: Customer efuse controller power domain */
+static struct powerdomain custefuse_54xx_pwrdm = {
+	.name		  = "custefuse_pwrdm",
+	.voltdm		  = { .name = "core" },
+	.prcm_offs	  = OMAP54XX_PRM_CUSTEFUSE_INST,
+	.prcm_partition	  = OMAP54XX_PRM_PARTITION,
+	.pwrsts		  = PWRSTS_OFF_ON,
+	.flags		  = PWRDM_HAS_LOWPOWERSTATECHANGE,
+};
+
+/* dsp_54xx_pwrdm: Tesla processor power domain */
+static struct powerdomain dsp_54xx_pwrdm = {
+	.name		  = "dsp_pwrdm",
+	.voltdm		  = { .name = "mm" },
+	.prcm_offs	  = OMAP54XX_PRM_DSP_INST,
+	.prcm_partition	  = OMAP54XX_PRM_PARTITION,
+	.pwrsts		  = PWRSTS_OFF_RET_ON,
+	.pwrsts_logic_ret = PWRSTS_OFF_RET,
+	.banks		  = 3,
+	.pwrsts_mem_ret	= {
+		[0] = PWRSTS_OFF_RET,	/* dsp_edma */
+		[1] = PWRSTS_OFF_RET,	/* dsp_l1 */
+		[2] = PWRSTS_OFF_RET,	/* dsp_l2 */
+	},
+	.pwrsts_mem_on	= {
+		[0] = PWRSTS_OFF_RET,	/* dsp_edma */
+		[1] = PWRSTS_OFF_RET,	/* dsp_l1 */
+		[2] = PWRSTS_OFF_RET,	/* dsp_l2 */
+	},
+	.flags		  = PWRDM_HAS_LOWPOWERSTATECHANGE,
+};
+
+/* cam_54xx_pwrdm: Camera subsystem power domain */
+static struct powerdomain cam_54xx_pwrdm = {
+	.name		  = "cam_pwrdm",
+	.voltdm		  = { .name = "core" },
+	.prcm_offs	  = OMAP54XX_PRM_CAM_INST,
+	.prcm_partition	  = OMAP54XX_PRM_PARTITION,
+	.pwrsts		  = PWRSTS_OFF_ON,
+	.banks		  = 1,
+	.pwrsts_mem_ret	= {
+		[0] = PWRSTS_OFF_RET,	/* cam_mem */
+	},
+	.pwrsts_mem_on	= {
+		[0] = PWRSTS_OFF_RET,	/* cam_mem */
+	},
+	.flags		  = PWRDM_HAS_LOWPOWERSTATECHANGE,
+};
+
+/* l3init_54xx_pwrdm: L3 initators pheripherals power domain  */
+static struct powerdomain l3init_54xx_pwrdm = {
+	.name		  = "l3init_pwrdm",
+	.voltdm		  = { .name = "core" },
+	.prcm_offs	  = OMAP54XX_PRM_L3INIT_INST,
+	.prcm_partition	  = OMAP54XX_PRM_PARTITION,
+	.pwrsts		  = PWRSTS_RET_ON,
+	.pwrsts_logic_ret = PWRSTS_OFF_RET,
+	.banks		  = 2,
+	.pwrsts_mem_ret	= {
+		[0] = PWRSTS_OFF_RET,	/* l3init_bank1 */
+		[1] = PWRSTS_OFF_RET,	/* l3init_bank2 */
+	},
+	.pwrsts_mem_on	= {
+		[0] = PWRSTS_OFF_RET,	/* l3init_bank1 */
+		[1] = PWRSTS_OFF_RET,	/* l3init_bank2 */
+	},
+	.flags		  = PWRDM_HAS_LOWPOWERSTATECHANGE,
+};
+
+/* gpu_54xx_pwrdm: 3D accelerator power domain */
+static struct powerdomain gpu_54xx_pwrdm = {
+	.name		  = "gpu_pwrdm",
+	.voltdm		  = { .name = "mm" },
+	.prcm_offs	  = OMAP54XX_PRM_GPU_INST,
+	.prcm_partition	  = OMAP54XX_PRM_PARTITION,
+	.pwrsts		  = PWRSTS_OFF_ON,
+	.banks		  = 1,
+	.pwrsts_mem_ret	= {
+		[0] = PWRSTS_OFF_RET,	/* gpu_mem */
+	},
+	.pwrsts_mem_on	= {
+		[0] = PWRSTS_OFF_RET,	/* gpu_mem */
+	},
+	.flags		  = PWRDM_HAS_LOWPOWERSTATECHANGE,
+};
+
+/* wkupaon_54xx_pwrdm: Wake-up power domain */
+static struct powerdomain wkupaon_54xx_pwrdm = {
+	.name		  = "wkupaon_pwrdm",
+	.voltdm		  = { .name = "wkup" },
+	.prcm_offs	  = OMAP54XX_PRM_WKUPAON_INST,
+	.prcm_partition	  = OMAP54XX_PRM_PARTITION,
+	.pwrsts		  = PWRSTS_ON,
+	.banks		  = 1,
+	.pwrsts_mem_ret	= {
+	},
+	.pwrsts_mem_on	= {
+		[0] = PWRSTS_ON,	/* wkup_bank */
+	},
+};
+
+/* iva_54xx_pwrdm: IVA-HD power domain */
+static struct powerdomain iva_54xx_pwrdm = {
+	.name		  = "iva_pwrdm",
+	.voltdm		  = { .name = "mm" },
+	.prcm_offs	  = OMAP54XX_PRM_IVA_INST,
+	.prcm_partition	  = OMAP54XX_PRM_PARTITION,
+	.pwrsts		  = PWRSTS_OFF_RET_ON,
+	.pwrsts_logic_ret = PWRSTS_OFF,
+	.banks		  = 4,
+	.pwrsts_mem_ret	= {
+		[0] = PWRSTS_OFF_RET,	/* hwa_mem */
+		[1] = PWRSTS_OFF_RET,	/* sl2_mem */
+		[2] = PWRSTS_OFF_RET,	/* tcm1_mem */
+		[3] = PWRSTS_OFF_RET,	/* tcm2_mem */
+	},
+	.pwrsts_mem_on	= {
+		[0] = PWRSTS_OFF_RET,	/* hwa_mem */
+		[1] = PWRSTS_OFF_RET,	/* sl2_mem */
+		[2] = PWRSTS_OFF_RET,	/* tcm1_mem */
+		[3] = PWRSTS_OFF_RET,	/* tcm2_mem */
+	},
+	.flags		  = PWRDM_HAS_LOWPOWERSTATECHANGE,
+};
+
+/*
+ * The following power domains are not under SW control
+ *
+ * mpuaon
+ * mmaon
+ */
+
+/* As powerdomains are added or removed above, this list must also be changed */
+static struct powerdomain *powerdomains_omap54xx[] __initdata = {
+	&core_54xx_pwrdm,
+	&abe_54xx_pwrdm,
+	&coreaon_54xx_pwrdm,
+	&dss_54xx_pwrdm,
+	&cpu0_54xx_pwrdm,
+	&cpu1_54xx_pwrdm,
+	&emu_54xx_pwrdm,
+	&mpu_54xx_pwrdm,
+	&custefuse_54xx_pwrdm,
+	&dsp_54xx_pwrdm,
+	&cam_54xx_pwrdm,
+	&l3init_54xx_pwrdm,
+	&gpu_54xx_pwrdm,
+	&wkupaon_54xx_pwrdm,
+	&iva_54xx_pwrdm,
+	NULL
+};
+
+void __init omap54xx_powerdomains_init(void)
+{
+	pwrdm_register_platform_funcs(&omap4_pwrdm_operations);
+	pwrdm_register_pwrdms(powerdomains_omap54xx);
+	pwrdm_complete_init();
+}
-- 
1.7.9.5



From santosh.shilimkar at ti.com  Thu Apr  4 06:20:58 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Thu, 4 Apr 2013 15:50:58 +0530
Subject: [PATCH v2 11/12] ARM: OMAP5: voltagedomain data: Add OMAP5 voltage
 domain data
In-Reply-To: <1365070859-21790-1-git-send-email-santosh.shilimkar@ti.com>
References: <1365070859-21790-1-git-send-email-santosh.shilimkar@ti.com>
Message-ID: <1365070859-21790-12-git-send-email-santosh.shilimkar@ti.com>

Add voltagedomain related data for OMAP54XX SOCs. OMAP4 OPP data is
used for now. OMAP5 OPP data will be added as part of OMAP5 DVFS
support.

Cc: Kevin Hilman <khilman at deeprootsystems.com>
Cc: Paul Walmsley <paul at pwsan.com>

Signed-off-by: Benoit Cousson <b-cousson at ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
---
 arch/arm/mach-omap2/voltage.h                 |    1 +
 arch/arm/mach-omap2/voltagedomains54xx_data.c |  102 +++++++++++++++++++++++++
 2 files changed, 103 insertions(+)
 create mode 100644 arch/arm/mach-omap2/voltagedomains54xx_data.c

diff --git a/arch/arm/mach-omap2/voltage.h b/arch/arm/mach-omap2/voltage.h
index a0ce4f1..5998eed 100644
--- a/arch/arm/mach-omap2/voltage.h
+++ b/arch/arm/mach-omap2/voltage.h
@@ -171,6 +171,7 @@ extern void omap2xxx_voltagedomains_init(void);
 extern void omap3xxx_voltagedomains_init(void);
 extern void am33xx_voltagedomains_init(void);
 extern void omap44xx_voltagedomains_init(void);
+extern void omap54xx_voltagedomains_init(void);
 
 struct voltagedomain *voltdm_lookup(const char *name);
 void voltdm_init(struct voltagedomain **voltdm_list);
diff --git a/arch/arm/mach-omap2/voltagedomains54xx_data.c b/arch/arm/mach-omap2/voltagedomains54xx_data.c
new file mode 100644
index 0000000..72b8971
--- /dev/null
+++ b/arch/arm/mach-omap2/voltagedomains54xx_data.c
@@ -0,0 +1,102 @@
+/*
+ * OMAP5 Voltage Management Routines
+ *
+ * Based on voltagedomains44xx_data.c
+ *
+ * Copyright (C) 2013 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/err.h>
+#include <linux/init.h>
+
+#include "common.h"
+
+#include "prm54xx.h"
+#include "voltage.h"
+#include "omap_opp_data.h"
+#include "vc.h"
+#include "vp.h"
+
+static const struct omap_vfsm_instance omap5_vdd_mpu_vfsm = {
+	.voltsetup_reg = OMAP54XX_PRM_VOLTSETUP_MPU_RET_SLEEP_OFFSET,
+};
+
+static const struct omap_vfsm_instance omap5_vdd_mm_vfsm = {
+	.voltsetup_reg = OMAP54XX_PRM_VOLTSETUP_MM_RET_SLEEP_OFFSET,
+};
+
+static const struct omap_vfsm_instance omap5_vdd_core_vfsm = {
+	.voltsetup_reg = OMAP54XX_PRM_VOLTSETUP_CORE_RET_SLEEP_OFFSET,
+};
+
+static struct voltagedomain omap5_voltdm_mpu = {
+	.name = "mpu",
+	.scalable = true,
+	.read = omap4_prm_vcvp_read,
+	.write = omap4_prm_vcvp_write,
+	.rmw = omap4_prm_vcvp_rmw,
+	.vc = &omap4_vc_mpu,
+	.vfsm = &omap5_vdd_mpu_vfsm,
+	.vp = &omap4_vp_mpu,
+};
+
+static struct voltagedomain omap5_voltdm_mm = {
+	.name = "mm",
+	.scalable = true,
+	.read = omap4_prm_vcvp_read,
+	.write = omap4_prm_vcvp_write,
+	.rmw = omap4_prm_vcvp_rmw,
+	.vc = &omap4_vc_iva,
+	.vfsm = &omap5_vdd_mm_vfsm,
+	.vp = &omap4_vp_iva,
+};
+
+static struct voltagedomain omap5_voltdm_core = {
+	.name = "core",
+	.scalable = true,
+	.read = omap4_prm_vcvp_read,
+	.write = omap4_prm_vcvp_write,
+	.rmw = omap4_prm_vcvp_rmw,
+	.vc = &omap4_vc_core,
+	.vfsm = &omap5_vdd_core_vfsm,
+	.vp = &omap4_vp_core,
+};
+
+static struct voltagedomain omap5_voltdm_wkup = {
+	.name = "wkup",
+};
+
+static struct voltagedomain *voltagedomains_omap5[] __initdata = {
+	&omap5_voltdm_mpu,
+	&omap5_voltdm_mm,
+	&omap5_voltdm_core,
+	&omap5_voltdm_wkup,
+	NULL,
+};
+
+static const char *sys_clk_name __initdata = "sys_clkin";
+
+void __init omap54xx_voltagedomains_init(void)
+{
+	struct voltagedomain *voltdm;
+	int i;
+
+	/*
+	 * XXX Will depend on the process, validation, and binning
+	 * for the currently-running IC. Use OMAP4 data for time being.
+	 */
+#ifdef CONFIG_PM_OPP
+	omap5_voltdm_mpu.volt_data = omap446x_vdd_mpu_volt_data;
+	omap5_voltdm_mm.volt_data = omap446x_vdd_iva_volt_data;
+	omap5_voltdm_core.volt_data = omap446x_vdd_core_volt_data;
+#endif
+
+	for (i = 0; voltdm = voltagedomains_omap5[i], voltdm; i++)
+		voltdm->sys_clk.name = sys_clk_name;
+
+	voltdm_init(voltagedomains_omap5);
+};
-- 
1.7.9.5



From santosh.shilimkar at ti.com  Thu Apr  4 06:20:55 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Thu, 4 Apr 2013 15:50:55 +0530
Subject: [PATCH v2 08/12] ARM: OMAP5: clockdomain data: Add OMAP54XX data and
 update the header
In-Reply-To: <1365070859-21790-1-git-send-email-santosh.shilimkar@ti.com>
References: <1365070859-21790-1-git-send-email-santosh.shilimkar@ti.com>
Message-ID: <1365070859-21790-9-git-send-email-santosh.shilimkar@ti.com>

From: Benoit Cousson <b-cousson at ti.com>

Add the data file to describe all clock domains inside the OMAP54XX soc.

Cc: Paul Walmsley <paul at pwsan.com>

Signed-off-by: Benoit Cousson <b-cousson at ti.com>
[santosh.shilimkar at ti.com: Generated es2.0 data]
Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
---
 arch/arm/mach-omap2/clockdomain.h           |    1 +
 arch/arm/mach-omap2/clockdomains54xx_data.c |  464 +++++++++++++++++++++++++++
 2 files changed, 465 insertions(+)
 create mode 100644 arch/arm/mach-omap2/clockdomains54xx_data.c

diff --git a/arch/arm/mach-omap2/clockdomain.h b/arch/arm/mach-omap2/clockdomain.h
index 2da3765..daeecf1 100644
--- a/arch/arm/mach-omap2/clockdomain.h
+++ b/arch/arm/mach-omap2/clockdomain.h
@@ -216,6 +216,7 @@ extern void __init omap243x_clockdomains_init(void);
 extern void __init omap3xxx_clockdomains_init(void);
 extern void __init am33xx_clockdomains_init(void);
 extern void __init omap44xx_clockdomains_init(void);
+extern void __init omap54xx_clockdomains_init(void);
 
 extern void clkdm_add_autodeps(struct clockdomain *clkdm);
 extern void clkdm_del_autodeps(struct clockdomain *clkdm);
diff --git a/arch/arm/mach-omap2/clockdomains54xx_data.c b/arch/arm/mach-omap2/clockdomains54xx_data.c
new file mode 100644
index 0000000..1a3c69d
--- /dev/null
+++ b/arch/arm/mach-omap2/clockdomains54xx_data.c
@@ -0,0 +1,464 @@
+/*
+ * OMAP54XX Clock domains framework
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ *
+ * Abhijit Pagare (abhijitpagare at ti.com)
+ * Benoit Cousson (b-cousson at ti.com)
+ * Paul Walmsley (paul at pwsan.com)
+ *
+ * This file is automatically generated from the OMAP hardware databases.
+ * We respectfully ask that any modifications to this file be coordinated
+ * with the public linux-omap at vger.kernel.org mailing list and the
+ * authors above to ensure that the autogeneration scripts are kept
+ * up-to-date with the file contents.
+ *
+ * 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 "clockdomain.h"
+#include "cm1_54xx.h"
+#include "cm2_54xx.h"
+
+#include "cm-regbits-54xx.h"
+#include "prm54xx.h"
+#include "prcm44xx.h"
+#include "prcm_mpu54xx.h"
+
+/* Static Dependencies for OMAP4 Clock Domains */
+
+static struct clkdm_dep c2c_wkup_sleep_deps[] = {
+	{ .clkdm_name = "abe_clkdm" },
+	{ .clkdm_name = "emif_clkdm" },
+	{ .clkdm_name = "iva_clkdm" },
+	{ .clkdm_name = "l3init_clkdm" },
+	{ .clkdm_name = "l3main1_clkdm" },
+	{ .clkdm_name = "l3main2_clkdm" },
+	{ .clkdm_name = "l4cfg_clkdm" },
+	{ .clkdm_name = "l4per_clkdm" },
+	{ NULL },
+};
+
+static struct clkdm_dep cam_wkup_sleep_deps[] = {
+	{ .clkdm_name = "emif_clkdm" },
+	{ .clkdm_name = "iva_clkdm" },
+	{ .clkdm_name = "l3main1_clkdm" },
+	{ NULL },
+};
+
+static struct clkdm_dep dma_wkup_sleep_deps[] = {
+	{ .clkdm_name = "abe_clkdm" },
+	{ .clkdm_name = "dss_clkdm" },
+	{ .clkdm_name = "emif_clkdm" },
+	{ .clkdm_name = "ipu_clkdm" },
+	{ .clkdm_name = "iva_clkdm" },
+	{ .clkdm_name = "l3init_clkdm" },
+	{ .clkdm_name = "l3main1_clkdm" },
+	{ .clkdm_name = "l4cfg_clkdm" },
+	{ .clkdm_name = "l4per_clkdm" },
+	{ .clkdm_name = "l4sec_clkdm" },
+	{ .clkdm_name = "wkupaon_clkdm" },
+	{ NULL },
+};
+
+static struct clkdm_dep dsp_wkup_sleep_deps[] = {
+	{ .clkdm_name = "abe_clkdm" },
+	{ .clkdm_name = "emif_clkdm" },
+	{ .clkdm_name = "iva_clkdm" },
+	{ .clkdm_name = "l3init_clkdm" },
+	{ .clkdm_name = "l3main1_clkdm" },
+	{ .clkdm_name = "l3main2_clkdm" },
+	{ .clkdm_name = "l4cfg_clkdm" },
+	{ .clkdm_name = "l4per_clkdm" },
+	{ .clkdm_name = "wkupaon_clkdm" },
+	{ NULL },
+};
+
+static struct clkdm_dep dss_wkup_sleep_deps[] = {
+	{ .clkdm_name = "emif_clkdm" },
+	{ .clkdm_name = "iva_clkdm" },
+	{ .clkdm_name = "l3main2_clkdm" },
+	{ NULL },
+};
+
+static struct clkdm_dep gpu_wkup_sleep_deps[] = {
+	{ .clkdm_name = "emif_clkdm" },
+	{ .clkdm_name = "iva_clkdm" },
+	{ .clkdm_name = "l3main1_clkdm" },
+	{ NULL },
+};
+
+static struct clkdm_dep ipu_wkup_sleep_deps[] = {
+	{ .clkdm_name = "abe_clkdm" },
+	{ .clkdm_name = "dsp_clkdm" },
+	{ .clkdm_name = "dss_clkdm" },
+	{ .clkdm_name = "emif_clkdm" },
+	{ .clkdm_name = "gpu_clkdm" },
+	{ .clkdm_name = "iva_clkdm" },
+	{ .clkdm_name = "l3init_clkdm" },
+	{ .clkdm_name = "l3main1_clkdm" },
+	{ .clkdm_name = "l3main2_clkdm" },
+	{ .clkdm_name = "l4cfg_clkdm" },
+	{ .clkdm_name = "l4per_clkdm" },
+	{ .clkdm_name = "l4sec_clkdm" },
+	{ .clkdm_name = "wkupaon_clkdm" },
+	{ NULL },
+};
+
+static struct clkdm_dep iva_wkup_sleep_deps[] = {
+	{ .clkdm_name = "emif_clkdm" },
+	{ .clkdm_name = "l3main1_clkdm" },
+	{ NULL },
+};
+
+static struct clkdm_dep l3init_wkup_sleep_deps[] = {
+	{ .clkdm_name = "abe_clkdm" },
+	{ .clkdm_name = "emif_clkdm" },
+	{ .clkdm_name = "iva_clkdm" },
+	{ .clkdm_name = "l4cfg_clkdm" },
+	{ .clkdm_name = "l4per_clkdm" },
+	{ .clkdm_name = "l4sec_clkdm" },
+	{ .clkdm_name = "wkupaon_clkdm" },
+	{ NULL },
+};
+
+static struct clkdm_dep l4sec_wkup_sleep_deps[] = {
+	{ .clkdm_name = "emif_clkdm" },
+	{ .clkdm_name = "l3main1_clkdm" },
+	{ .clkdm_name = "l4per_clkdm" },
+	{ NULL },
+};
+
+static struct clkdm_dep mipiext_wkup_sleep_deps[] = {
+	{ .clkdm_name = "abe_clkdm" },
+	{ .clkdm_name = "emif_clkdm" },
+	{ .clkdm_name = "iva_clkdm" },
+	{ .clkdm_name = "l3init_clkdm" },
+	{ .clkdm_name = "l3main1_clkdm" },
+	{ .clkdm_name = "l3main2_clkdm" },
+	{ .clkdm_name = "l4cfg_clkdm" },
+	{ .clkdm_name = "l4per_clkdm" },
+	{ NULL },
+};
+
+static struct clkdm_dep mpu_wkup_sleep_deps[] = {
+	{ .clkdm_name = "abe_clkdm" },
+	{ .clkdm_name = "dsp_clkdm" },
+	{ .clkdm_name = "dss_clkdm" },
+	{ .clkdm_name = "emif_clkdm" },
+	{ .clkdm_name = "gpu_clkdm" },
+	{ .clkdm_name = "ipu_clkdm" },
+	{ .clkdm_name = "iva_clkdm" },
+	{ .clkdm_name = "l3init_clkdm" },
+	{ .clkdm_name = "l3main1_clkdm" },
+	{ .clkdm_name = "l3main2_clkdm" },
+	{ .clkdm_name = "l4cfg_clkdm" },
+	{ .clkdm_name = "l4per_clkdm" },
+	{ .clkdm_name = "l4sec_clkdm" },
+	{ .clkdm_name = "wkupaon_clkdm" },
+	{ NULL },
+};
+
+static struct clockdomain l4sec_54xx_clkdm = {
+	.name		  = "l4sec_clkdm",
+	.pwrdm		  = { .name = "core_pwrdm" },
+	.prcm_partition	  = OMAP54XX_CM_CORE_PARTITION,
+	.cm_inst	  = OMAP54XX_CM_CORE_CORE_INST,
+	.clkdm_offs	  = OMAP54XX_CM_CORE_CORE_L4SEC_CDOFFS,
+	.dep_bit	  = OMAP54XX_L4SEC_STATDEP_SHIFT,
+	.wkdep_srcs	  = l4sec_wkup_sleep_deps,
+	.sleepdep_srcs	  = l4sec_wkup_sleep_deps,
+	.flags		  = CLKDM_CAN_HWSUP_SWSUP,
+};
+
+static struct clockdomain iva_54xx_clkdm = {
+	.name		  = "iva_clkdm",
+	.pwrdm		  = { .name = "iva_pwrdm" },
+	.prcm_partition	  = OMAP54XX_CM_CORE_PARTITION,
+	.cm_inst	  = OMAP54XX_CM_CORE_IVA_INST,
+	.clkdm_offs	  = OMAP54XX_CM_CORE_IVA_IVA_CDOFFS,
+	.dep_bit	  = OMAP54XX_IVA_STATDEP_SHIFT,
+	.wkdep_srcs	  = iva_wkup_sleep_deps,
+	.sleepdep_srcs	  = iva_wkup_sleep_deps,
+	.flags		  = CLKDM_CAN_HWSUP_SWSUP,
+};
+
+static struct clockdomain mipiext_54xx_clkdm = {
+	.name		  = "mipiext_clkdm",
+	.pwrdm		  = { .name = "core_pwrdm" },
+	.prcm_partition	  = OMAP54XX_CM_CORE_PARTITION,
+	.cm_inst	  = OMAP54XX_CM_CORE_CORE_INST,
+	.clkdm_offs	  = OMAP54XX_CM_CORE_CORE_MIPIEXT_CDOFFS,
+	.wkdep_srcs	  = mipiext_wkup_sleep_deps,
+	.sleepdep_srcs	  = mipiext_wkup_sleep_deps,
+	.flags		  = CLKDM_CAN_FORCE_WAKEUP | CLKDM_CAN_HWSUP,
+};
+
+static struct clockdomain l3main2_54xx_clkdm = {
+	.name		  = "l3main2_clkdm",
+	.pwrdm		  = { .name = "core_pwrdm" },
+	.prcm_partition	  = OMAP54XX_CM_CORE_PARTITION,
+	.cm_inst	  = OMAP54XX_CM_CORE_CORE_INST,
+	.clkdm_offs	  = OMAP54XX_CM_CORE_CORE_L3MAIN2_CDOFFS,
+	.dep_bit	  = OMAP54XX_L3MAIN2_STATDEP_SHIFT,
+	.flags		  = CLKDM_CAN_HWSUP,
+};
+
+static struct clockdomain l3main1_54xx_clkdm = {
+	.name		  = "l3main1_clkdm",
+	.pwrdm		  = { .name = "core_pwrdm" },
+	.prcm_partition	  = OMAP54XX_CM_CORE_PARTITION,
+	.cm_inst	  = OMAP54XX_CM_CORE_CORE_INST,
+	.clkdm_offs	  = OMAP54XX_CM_CORE_CORE_L3MAIN1_CDOFFS,
+	.dep_bit	  = OMAP54XX_L3MAIN1_STATDEP_SHIFT,
+	.flags		  = CLKDM_CAN_HWSUP,
+};
+
+static struct clockdomain custefuse_54xx_clkdm = {
+	.name		  = "custefuse_clkdm",
+	.pwrdm		  = { .name = "custefuse_pwrdm" },
+	.prcm_partition	  = OMAP54XX_CM_CORE_PARTITION,
+	.cm_inst	  = OMAP54XX_CM_CORE_CUSTEFUSE_INST,
+	.clkdm_offs	  = OMAP54XX_CM_CORE_CUSTEFUSE_CUSTEFUSE_CDOFFS,
+	.flags		  = CLKDM_CAN_FORCE_WAKEUP | CLKDM_CAN_HWSUP,
+};
+
+static struct clockdomain ipu_54xx_clkdm = {
+	.name		  = "ipu_clkdm",
+	.pwrdm		  = { .name = "core_pwrdm" },
+	.prcm_partition	  = OMAP54XX_CM_CORE_PARTITION,
+	.cm_inst	  = OMAP54XX_CM_CORE_CORE_INST,
+	.clkdm_offs	  = OMAP54XX_CM_CORE_CORE_IPU_CDOFFS,
+	.dep_bit	  = OMAP54XX_IPU_STATDEP_SHIFT,
+	.wkdep_srcs	  = ipu_wkup_sleep_deps,
+	.sleepdep_srcs	  = ipu_wkup_sleep_deps,
+	.flags		  = CLKDM_CAN_HWSUP_SWSUP,
+};
+
+static struct clockdomain l4cfg_54xx_clkdm = {
+	.name		  = "l4cfg_clkdm",
+	.pwrdm		  = { .name = "core_pwrdm" },
+	.prcm_partition	  = OMAP54XX_CM_CORE_PARTITION,
+	.cm_inst	  = OMAP54XX_CM_CORE_CORE_INST,
+	.clkdm_offs	  = OMAP54XX_CM_CORE_CORE_L4CFG_CDOFFS,
+	.dep_bit	  = OMAP54XX_L4CFG_STATDEP_SHIFT,
+	.flags		  = CLKDM_CAN_HWSUP,
+};
+
+static struct clockdomain abe_54xx_clkdm = {
+	.name		  = "abe_clkdm",
+	.pwrdm		  = { .name = "abe_pwrdm" },
+	.prcm_partition	  = OMAP54XX_CM_CORE_AON_PARTITION,
+	.cm_inst	  = OMAP54XX_CM_CORE_AON_ABE_INST,
+	.clkdm_offs	  = OMAP54XX_CM_CORE_AON_ABE_ABE_CDOFFS,
+	.dep_bit	  = OMAP54XX_ABE_STATDEP_SHIFT,
+	.flags		  = CLKDM_CAN_HWSUP_SWSUP,
+};
+
+static struct clockdomain dss_54xx_clkdm = {
+	.name		  = "dss_clkdm",
+	.pwrdm		  = { .name = "dss_pwrdm" },
+	.prcm_partition	  = OMAP54XX_CM_CORE_PARTITION,
+	.cm_inst	  = OMAP54XX_CM_CORE_DSS_INST,
+	.clkdm_offs	  = OMAP54XX_CM_CORE_DSS_DSS_CDOFFS,
+	.dep_bit	  = OMAP54XX_DSS_STATDEP_SHIFT,
+	.wkdep_srcs	  = dss_wkup_sleep_deps,
+	.sleepdep_srcs	  = dss_wkup_sleep_deps,
+	.flags		  = CLKDM_CAN_HWSUP_SWSUP,
+};
+
+static struct clockdomain dsp_54xx_clkdm = {
+	.name		  = "dsp_clkdm",
+	.pwrdm		  = { .name = "dsp_pwrdm" },
+	.prcm_partition	  = OMAP54XX_CM_CORE_AON_PARTITION,
+	.cm_inst	  = OMAP54XX_CM_CORE_AON_DSP_INST,
+	.clkdm_offs	  = OMAP54XX_CM_CORE_AON_DSP_DSP_CDOFFS,
+	.dep_bit	  = OMAP54XX_DSP_STATDEP_SHIFT,
+	.wkdep_srcs	  = dsp_wkup_sleep_deps,
+	.sleepdep_srcs	  = dsp_wkup_sleep_deps,
+	.flags		  = CLKDM_CAN_HWSUP_SWSUP,
+};
+
+static struct clockdomain c2c_54xx_clkdm = {
+	.name		  = "c2c_clkdm",
+	.pwrdm		  = { .name = "core_pwrdm" },
+	.prcm_partition	  = OMAP54XX_CM_CORE_PARTITION,
+	.cm_inst	  = OMAP54XX_CM_CORE_CORE_INST,
+	.clkdm_offs	  = OMAP54XX_CM_CORE_CORE_C2C_CDOFFS,
+	.wkdep_srcs	  = c2c_wkup_sleep_deps,
+	.sleepdep_srcs	  = c2c_wkup_sleep_deps,
+	.flags		  = CLKDM_CAN_FORCE_WAKEUP | CLKDM_CAN_HWSUP,
+};
+
+static struct clockdomain l4per_54xx_clkdm = {
+	.name		  = "l4per_clkdm",
+	.pwrdm		  = { .name = "core_pwrdm" },
+	.prcm_partition	  = OMAP54XX_CM_CORE_PARTITION,
+	.cm_inst	  = OMAP54XX_CM_CORE_CORE_INST,
+	.clkdm_offs	  = OMAP54XX_CM_CORE_CORE_L4PER_CDOFFS,
+	.dep_bit	  = OMAP54XX_L4PER_STATDEP_SHIFT,
+	.flags		  = CLKDM_CAN_HWSUP_SWSUP,
+};
+
+static struct clockdomain gpu_54xx_clkdm = {
+	.name		  = "gpu_clkdm",
+	.pwrdm		  = { .name = "gpu_pwrdm" },
+	.prcm_partition	  = OMAP54XX_CM_CORE_PARTITION,
+	.cm_inst	  = OMAP54XX_CM_CORE_GPU_INST,
+	.clkdm_offs	  = OMAP54XX_CM_CORE_GPU_GPU_CDOFFS,
+	.dep_bit	  = OMAP54XX_GPU_STATDEP_SHIFT,
+	.wkdep_srcs	  = gpu_wkup_sleep_deps,
+	.sleepdep_srcs	  = gpu_wkup_sleep_deps,
+	.flags		  = CLKDM_CAN_HWSUP_SWSUP,
+};
+
+static struct clockdomain wkupaon_54xx_clkdm = {
+	.name		  = "wkupaon_clkdm",
+	.pwrdm		  = { .name = "wkupaon_pwrdm" },
+	.prcm_partition	  = OMAP54XX_PRM_PARTITION,
+	.cm_inst	  = OMAP54XX_PRM_WKUPAON_CM_INST,
+	.clkdm_offs	  = OMAP54XX_PRM_WKUPAON_CM_WKUPAON_CDOFFS,
+	.dep_bit	  = OMAP54XX_WKUPAON_STATDEP_SHIFT,
+	.flags		  = CLKDM_CAN_FORCE_WAKEUP | CLKDM_CAN_HWSUP,
+};
+
+static struct clockdomain mpu0_54xx_clkdm = {
+	.name		  = "mpu0_clkdm",
+	.pwrdm		  = { .name = "cpu0_pwrdm" },
+	.prcm_partition	  = OMAP54XX_PRCM_MPU_PARTITION,
+	.cm_inst	  = OMAP54XX_PRCM_MPU_CM_C0_INST,
+	.clkdm_offs	  = OMAP54XX_PRCM_MPU_CM_C0_CPU0_CDOFFS,
+	.flags		  = CLKDM_CAN_FORCE_WAKEUP | CLKDM_CAN_HWSUP,
+};
+
+static struct clockdomain mpu1_54xx_clkdm = {
+	.name		  = "mpu1_clkdm",
+	.pwrdm		  = { .name = "cpu1_pwrdm" },
+	.prcm_partition	  = OMAP54XX_PRCM_MPU_PARTITION,
+	.cm_inst	  = OMAP54XX_PRCM_MPU_CM_C1_INST,
+	.clkdm_offs	  = OMAP54XX_PRCM_MPU_CM_C1_CPU1_CDOFFS,
+	.flags		  = CLKDM_CAN_FORCE_WAKEUP | CLKDM_CAN_HWSUP,
+};
+
+static struct clockdomain coreaon_54xx_clkdm = {
+	.name		  = "coreaon_clkdm",
+	.pwrdm		  = { .name = "coreaon_pwrdm" },
+	.prcm_partition	  = OMAP54XX_CM_CORE_PARTITION,
+	.cm_inst	  = OMAP54XX_CM_CORE_COREAON_INST,
+	.clkdm_offs	  = OMAP54XX_CM_CORE_COREAON_COREAON_CDOFFS,
+	.flags		  = CLKDM_CAN_FORCE_WAKEUP | CLKDM_CAN_HWSUP,
+};
+
+static struct clockdomain mpu_54xx_clkdm = {
+	.name		  = "mpu_clkdm",
+	.pwrdm		  = { .name = "mpu_pwrdm" },
+	.prcm_partition	  = OMAP54XX_CM_CORE_AON_PARTITION,
+	.cm_inst	  = OMAP54XX_CM_CORE_AON_MPU_INST,
+	.clkdm_offs	  = OMAP54XX_CM_CORE_AON_MPU_MPU_CDOFFS,
+	.wkdep_srcs	  = mpu_wkup_sleep_deps,
+	.sleepdep_srcs	  = mpu_wkup_sleep_deps,
+	.flags		  = CLKDM_CAN_FORCE_WAKEUP | CLKDM_CAN_HWSUP,
+};
+
+static struct clockdomain l3init_54xx_clkdm = {
+	.name		  = "l3init_clkdm",
+	.pwrdm		  = { .name = "l3init_pwrdm" },
+	.prcm_partition	  = OMAP54XX_CM_CORE_PARTITION,
+	.cm_inst	  = OMAP54XX_CM_CORE_L3INIT_INST,
+	.clkdm_offs	  = OMAP54XX_CM_CORE_L3INIT_L3INIT_CDOFFS,
+	.dep_bit	  = OMAP54XX_L3INIT_STATDEP_SHIFT,
+	.wkdep_srcs	  = l3init_wkup_sleep_deps,
+	.sleepdep_srcs	  = l3init_wkup_sleep_deps,
+	.flags		  = CLKDM_CAN_HWSUP_SWSUP,
+};
+
+static struct clockdomain dma_54xx_clkdm = {
+	.name		  = "dma_clkdm",
+	.pwrdm		  = { .name = "core_pwrdm" },
+	.prcm_partition	  = OMAP54XX_CM_CORE_PARTITION,
+	.cm_inst	  = OMAP54XX_CM_CORE_CORE_INST,
+	.clkdm_offs	  = OMAP54XX_CM_CORE_CORE_DMA_CDOFFS,
+	.wkdep_srcs	  = dma_wkup_sleep_deps,
+	.sleepdep_srcs	  = dma_wkup_sleep_deps,
+	.flags		  = CLKDM_CAN_FORCE_WAKEUP | CLKDM_CAN_HWSUP,
+};
+
+static struct clockdomain l3instr_54xx_clkdm = {
+	.name		  = "l3instr_clkdm",
+	.pwrdm		  = { .name = "core_pwrdm" },
+	.prcm_partition	  = OMAP54XX_CM_CORE_PARTITION,
+	.cm_inst	  = OMAP54XX_CM_CORE_CORE_INST,
+	.clkdm_offs	  = OMAP54XX_CM_CORE_CORE_L3INSTR_CDOFFS,
+};
+
+static struct clockdomain emif_54xx_clkdm = {
+	.name		  = "emif_clkdm",
+	.pwrdm		  = { .name = "core_pwrdm" },
+	.prcm_partition	  = OMAP54XX_CM_CORE_PARTITION,
+	.cm_inst	  = OMAP54XX_CM_CORE_CORE_INST,
+	.clkdm_offs	  = OMAP54XX_CM_CORE_CORE_EMIF_CDOFFS,
+	.dep_bit	  = OMAP54XX_EMIF_STATDEP_SHIFT,
+	.flags		  = CLKDM_CAN_FORCE_WAKEUP | CLKDM_CAN_HWSUP,
+};
+
+static struct clockdomain emu_54xx_clkdm = {
+	.name		  = "emu_clkdm",
+	.pwrdm		  = { .name = "emu_pwrdm" },
+	.prcm_partition	  = OMAP54XX_PRM_PARTITION,
+	.cm_inst	  = OMAP54XX_PRM_EMU_CM_INST,
+	.clkdm_offs	  = OMAP54XX_PRM_EMU_CM_EMU_CDOFFS,
+	.flags		  = CLKDM_CAN_FORCE_WAKEUP | CLKDM_CAN_HWSUP,
+};
+
+static struct clockdomain cam_54xx_clkdm = {
+	.name		  = "cam_clkdm",
+	.pwrdm		  = { .name = "cam_pwrdm" },
+	.prcm_partition	  = OMAP54XX_CM_CORE_PARTITION,
+	.cm_inst	  = OMAP54XX_CM_CORE_CAM_INST,
+	.clkdm_offs	  = OMAP54XX_CM_CORE_CAM_CAM_CDOFFS,
+	.wkdep_srcs	  = cam_wkup_sleep_deps,
+	.sleepdep_srcs	  = cam_wkup_sleep_deps,
+	.flags		  = CLKDM_CAN_HWSUP_SWSUP,
+};
+
+/* As clockdomains are added or removed above, this list must also be changed */
+static struct clockdomain *clockdomains_omap54xx[] __initdata = {
+	&l4sec_54xx_clkdm,
+	&iva_54xx_clkdm,
+	&mipiext_54xx_clkdm,
+	&l3main2_54xx_clkdm,
+	&l3main1_54xx_clkdm,
+	&custefuse_54xx_clkdm,
+	&ipu_54xx_clkdm,
+	&l4cfg_54xx_clkdm,
+	&abe_54xx_clkdm,
+	&dss_54xx_clkdm,
+	&dsp_54xx_clkdm,
+	&c2c_54xx_clkdm,
+	&l4per_54xx_clkdm,
+	&gpu_54xx_clkdm,
+	&wkupaon_54xx_clkdm,
+	&mpu0_54xx_clkdm,
+	&mpu1_54xx_clkdm,
+	&coreaon_54xx_clkdm,
+	&mpu_54xx_clkdm,
+	&l3init_54xx_clkdm,
+	&dma_54xx_clkdm,
+	&l3instr_54xx_clkdm,
+	&emif_54xx_clkdm,
+	&emu_54xx_clkdm,
+	&cam_54xx_clkdm,
+	NULL
+};
+
+void __init omap54xx_clockdomains_init(void)
+{
+	clkdm_register_platform_funcs(&omap4_clkdm_operations);
+	clkdm_register_clkdms(clockdomains_omap54xx);
+	clkdm_complete_init();
+}
-- 
1.7.9.5



From santosh.shilimkar at ti.com  Thu Apr  4 06:20:57 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Thu, 4 Apr 2013 15:50:57 +0530
Subject: [PATCH v2 10/12] ARM: OMAP5: hwmod data: Create initial OMAP5 SOC
 hwmod data
In-Reply-To: <1365070859-21790-1-git-send-email-santosh.shilimkar@ti.com>
References: <1365070859-21790-1-git-send-email-santosh.shilimkar@ti.com>
Message-ID: <1365070859-21790-11-git-send-email-santosh.shilimkar@ti.com>

From: Benoit Cousson <b-cousson at ti.com>

Adding the hwmod data for OMAP54xx SOCs.

Additional changes done on top of initial SOC data files.
- The IO resource information like dma request lines, irq number and
ocp address space can be populated via dt blob. So such data is stripped
from OMAP5 SOC hwmod data file.

- SDMA IO resource information is still kept since dmaengine work
is till ongoing. Once the legacy dma platform driver becomes obsolete,
SDMA io space information can be removed.

- The devices like dss, aess, usb which are missing the device tree bindings,
hwmod data is not added since OMAP5 is DT only build. When such devices add
the dt bindings, respective hwmod data can be added along with it.

With above update, we now need about ~2000 loc vs ~6000 loc with previous
version of the patch for OMAP5 hwmod data file. Ofcourse with addition of
few more drivers it can go upto ~2400 loc which is still better than the
earlier version.

Signed-off-by: Benoit Cousson <b-cousson at ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
---
 arch/arm/mach-omap2/omap_hwmod.h           |    1 +
 arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 2151 ++++++++++++++++++++++++++++
 2 files changed, 2152 insertions(+)
 create mode 100644 arch/arm/mach-omap2/omap_hwmod_54xx_data.c

diff --git a/arch/arm/mach-omap2/omap_hwmod.h b/arch/arm/mach-omap2/omap_hwmod.h
index d43d9b6..77888a9 100644
--- a/arch/arm/mach-omap2/omap_hwmod.h
+++ b/arch/arm/mach-omap2/omap_hwmod.h
@@ -695,6 +695,7 @@ extern int omap2420_hwmod_init(void);
 extern int omap2430_hwmod_init(void);
 extern int omap3xxx_hwmod_init(void);
 extern int omap44xx_hwmod_init(void);
+extern int omap54xx_hwmod_init(void);
 extern int am33xx_hwmod_init(void);
 
 extern int __init omap_hwmod_register_links(struct omap_hwmod_ocp_if **ois);
diff --git a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
new file mode 100644
index 0000000..a538692
--- /dev/null
+++ b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
@@ -0,0 +1,2151 @@
+/*
+ * Hardware modules present on the OMAP54xx chips
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com
+ *
+ * Paul Walmsley
+ * Benoit Cousson
+ *
+ * This file is automatically generated from the OMAP hardware databases.
+ * We respectfully ask that any modifications to this file be coordinated
+ * with the public linux-omap at vger.kernel.org mailing list and the
+ * authors above to ensure that the autogeneration scripts are kept
+ * up-to-date with the file contents.
+ *
+ * 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/io.h>
+#include <linux/platform_data/gpio-omap.h>
+#include <linux/power/smartreflex.h>
+#include <linux/platform_data/omap_ocp2scp.h>
+#include <linux/i2c-omap.h>
+
+#include <linux/omap-dma.h>
+#include <linux/platform_data/spi-omap2-mcspi.h>
+#include <linux/platform_data/asoc-ti-mcbsp.h>
+#include <plat/dmtimer.h>
+
+#include "omap_hwmod.h"
+#include "omap_hwmod_common_data.h"
+#include "cm1_54xx.h"
+#include "cm2_54xx.h"
+#include "prm54xx.h"
+#include "prm-regbits-54xx.h"
+#include "i2c.h"
+#include "mmc.h"
+#include "wd_timer.h"
+
+/* Base offset for all OMAP5 interrupts external to MPUSS */
+#define OMAP54XX_IRQ_GIC_START	32
+
+/* Base offset for all OMAP5 dma requests */
+#define OMAP54XX_DMA_REQ_START	1
+
+
+/*
+ * IP blocks
+ */
+
+/*
+ * 'dmm' class
+ * instance(s): dmm
+ */
+static struct omap_hwmod_class omap54xx_dmm_hwmod_class = {
+	.name	= "dmm",
+};
+
+/* dmm */
+static struct omap_hwmod omap54xx_dmm_hwmod = {
+	.name		= "dmm",
+	.class		= &omap54xx_dmm_hwmod_class,
+	.clkdm_name	= "emif_clkdm",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = OMAP54XX_CM_EMIF_DMM_CLKCTRL_OFFSET,
+			.context_offs = OMAP54XX_RM_EMIF_DMM_CONTEXT_OFFSET,
+		},
+	},
+};
+
+/*
+ * 'l3' class
+ * instance(s): l3_instr, l3_main_1, l3_main_2, l3_main_3
+ */
+static struct omap_hwmod_class omap54xx_l3_hwmod_class = {
+	.name	= "l3",
+};
+
+/* l3_instr */
+static struct omap_hwmod omap54xx_l3_instr_hwmod = {
+	.name		= "l3_instr",
+	.class		= &omap54xx_l3_hwmod_class,
+	.clkdm_name	= "l3instr_clkdm",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = OMAP54XX_CM_L3INSTR_L3_INSTR_CLKCTRL_OFFSET,
+			.context_offs = OMAP54XX_RM_L3INSTR_L3_INSTR_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_HWCTRL,
+		},
+	},
+};
+
+/* l3_main_1 */
+static struct omap_hwmod omap54xx_l3_main_1_hwmod = {
+	.name		= "l3_main_1",
+	.class		= &omap54xx_l3_hwmod_class,
+	.clkdm_name	= "l3main1_clkdm",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = OMAP54XX_CM_L3MAIN1_L3_MAIN_1_CLKCTRL_OFFSET,
+			.context_offs = OMAP54XX_RM_L3MAIN1_L3_MAIN_1_CONTEXT_OFFSET,
+		},
+	},
+};
+
+/* l3_main_2 */
+static struct omap_hwmod omap54xx_l3_main_2_hwmod = {
+	.name		= "l3_main_2",
+	.class		= &omap54xx_l3_hwmod_class,
+	.clkdm_name	= "l3main2_clkdm",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = OMAP54XX_CM_L3MAIN2_L3_MAIN_2_CLKCTRL_OFFSET,
+			.context_offs = OMAP54XX_RM_L3MAIN2_L3_MAIN_2_CONTEXT_OFFSET,
+		},
+	},
+};
+
+/* l3_main_3 */
+static struct omap_hwmod omap54xx_l3_main_3_hwmod = {
+	.name		= "l3_main_3",
+	.class		= &omap54xx_l3_hwmod_class,
+	.clkdm_name	= "l3instr_clkdm",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = OMAP54XX_CM_L3INSTR_L3_MAIN_3_CLKCTRL_OFFSET,
+			.context_offs = OMAP54XX_RM_L3INSTR_L3_MAIN_3_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_HWCTRL,
+		},
+	},
+};
+
+/*
+ * 'l4' class
+ * instance(s): l4_abe, l4_cfg, l4_per, l4_wkup
+ */
+static struct omap_hwmod_class omap54xx_l4_hwmod_class = {
+	.name	= "l4",
+};
+
+/* l4_abe */
+static struct omap_hwmod omap54xx_l4_abe_hwmod = {
+	.name		= "l4_abe",
+	.class		= &omap54xx_l4_hwmod_class,
+	.clkdm_name	= "abe_clkdm",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = OMAP54XX_CM_ABE_L4_ABE_CLKCTRL_OFFSET,
+			.flags = HWMOD_OMAP4_NO_CONTEXT_LOSS_BIT,
+		},
+	},
+};
+
+/* l4_cfg */
+static struct omap_hwmod omap54xx_l4_cfg_hwmod = {
+	.name		= "l4_cfg",
+	.class		= &omap54xx_l4_hwmod_class,
+	.clkdm_name	= "l4cfg_clkdm",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = OMAP54XX_CM_L4CFG_L4_CFG_CLKCTRL_OFFSET,
+			.context_offs = OMAP54XX_RM_L4CFG_L4_CFG_CONTEXT_OFFSET,
+		},
+	},
+};
+
+/* l4_per */
+static struct omap_hwmod omap54xx_l4_per_hwmod = {
+	.name		= "l4_per",
+	.class		= &omap54xx_l4_hwmod_class,
+	.clkdm_name	= "l4per_clkdm",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = OMAP54XX_CM_L4PER_L4_PER_CLKCTRL_OFFSET,
+			.context_offs = OMAP54XX_RM_L4PER_L4_PER_CONTEXT_OFFSET,
+		},
+	},
+};
+
+/* l4_wkup */
+static struct omap_hwmod omap54xx_l4_wkup_hwmod = {
+	.name		= "l4_wkup",
+	.class		= &omap54xx_l4_hwmod_class,
+	.clkdm_name	= "wkupaon_clkdm",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = OMAP54XX_CM_WKUPAON_L4_WKUP_CLKCTRL_OFFSET,
+			.context_offs = OMAP54XX_RM_WKUPAON_L4_WKUP_CONTEXT_OFFSET,
+		},
+	},
+};
+
+/*
+ * 'mpu_bus' class
+ * instance(s): mpu_private
+ */
+static struct omap_hwmod_class omap54xx_mpu_bus_hwmod_class = {
+	.name	= "mpu_bus",
+};
+
+/* mpu_private */
+static struct omap_hwmod omap54xx_mpu_private_hwmod = {
+	.name		= "mpu_private",
+	.class		= &omap54xx_mpu_bus_hwmod_class,
+	.clkdm_name	= "mpu_clkdm",
+	.prcm = {
+		.omap4 = {
+			.flags = HWMOD_OMAP4_NO_CONTEXT_LOSS_BIT,
+		},
+	},
+};
+
+/*
+ * 'counter' class
+ * 32-bit ordinary counter, clocked by the falling edge of the 32 khz clock
+ */
+
+static struct omap_hwmod_class_sysconfig omap54xx_counter_sysc = {
+	.rev_offs	= 0x0000,
+	.sysc_offs	= 0x0010,
+	.sysc_flags	= SYSC_HAS_SIDLEMODE,
+	.idlemodes	= (SIDLE_FORCE | SIDLE_NO),
+	.sysc_fields	= &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap54xx_counter_hwmod_class = {
+	.name	= "counter",
+	.sysc	= &omap54xx_counter_sysc,
+};
+
+/* counter_32k */
+static struct omap_hwmod omap54xx_counter_32k_hwmod = {
+	.name		= "counter_32k",
+	.class		= &omap54xx_counter_hwmod_class,
+	.clkdm_name	= "wkupaon_clkdm",
+	.flags		= HWMOD_SWSUP_SIDLE,
+	.main_clk	= "wkupaon_iclk_mux",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = OMAP54XX_CM_WKUPAON_COUNTER_32K_CLKCTRL_OFFSET,
+			.context_offs = OMAP54XX_RM_WKUPAON_COUNTER_32K_CONTEXT_OFFSET,
+		},
+	},
+};
+
+/*
+ * 'dma' class
+ * dma controller for data exchange between memory to memory (i.e. internal or
+ * external memory) and gp peripherals to memory or memory to gp peripherals
+ */
+
+static struct omap_hwmod_class_sysconfig omap54xx_dma_sysc = {
+	.rev_offs	= 0x0000,
+	.sysc_offs	= 0x002c,
+	.syss_offs	= 0x0028,
+	.sysc_flags	= (SYSC_HAS_AUTOIDLE | SYSC_HAS_CLOCKACTIVITY |
+			   SYSC_HAS_EMUFREE | SYSC_HAS_MIDLEMODE |
+			   SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET |
+			   SYSS_HAS_RESET_STATUS),
+	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+			   MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART),
+	.sysc_fields	= &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap54xx_dma_hwmod_class = {
+	.name	= "dma",
+	.sysc	= &omap54xx_dma_sysc,
+};
+
+/* dma dev_attr */
+static struct omap_dma_dev_attr dma_dev_attr = {
+	.dev_caps	= RESERVE_CHANNEL | DMA_LINKED_LCH | GLOBAL_PRIORITY |
+			  IS_CSSA_32 | IS_CDSA_32 | IS_RW_PRIORITY,
+	.lch_count	= 32,
+};
+
+/* dma_system */
+static struct omap_hwmod_irq_info omap54xx_dma_system_irqs[] = {
+	{ .name = "0", .irq = 12 + OMAP54XX_IRQ_GIC_START },
+	{ .name = "1", .irq = 13 + OMAP54XX_IRQ_GIC_START },
+	{ .name = "2", .irq = 14 + OMAP54XX_IRQ_GIC_START },
+	{ .name = "3", .irq = 15 + OMAP54XX_IRQ_GIC_START },
+	{ .irq = -1 }
+};
+
+static struct omap_hwmod omap54xx_dma_system_hwmod = {
+	.name		= "dma_system",
+	.class		= &omap54xx_dma_hwmod_class,
+	.clkdm_name	= "dma_clkdm",
+	.mpu_irqs	= omap54xx_dma_system_irqs,
+	.main_clk	= "l3_iclk_div",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = OMAP54XX_CM_DMA_DMA_SYSTEM_CLKCTRL_OFFSET,
+			.context_offs = OMAP54XX_RM_DMA_DMA_SYSTEM_CONTEXT_OFFSET,
+		},
+	},
+	.dev_attr	= &dma_dev_attr,
+};
+
+/*
+ * 'dmic' class
+ * digital microphone controller
+ */
+
+static struct omap_hwmod_class_sysconfig omap54xx_dmic_sysc = {
+	.rev_offs	= 0x0000,
+	.sysc_offs	= 0x0010,
+	.sysc_flags	= (SYSC_HAS_EMUFREE | SYSC_HAS_RESET_STATUS |
+			   SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET),
+	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+			   SIDLE_SMART_WKUP),
+	.sysc_fields	= &omap_hwmod_sysc_type2,
+};
+
+static struct omap_hwmod_class omap54xx_dmic_hwmod_class = {
+	.name	= "dmic",
+	.sysc	= &omap54xx_dmic_sysc,
+};
+
+/* dmic */
+static struct omap_hwmod omap54xx_dmic_hwmod = {
+	.name		= "dmic",
+	.class		= &omap54xx_dmic_hwmod_class,
+	.clkdm_name	= "abe_clkdm",
+	.main_clk	= "dmic_gfclk",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = OMAP54XX_CM_ABE_DMIC_CLKCTRL_OFFSET,
+			.context_offs = OMAP54XX_RM_ABE_DMIC_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+};
+
+/*
+ * 'emif' class
+ * external memory interface no1 (wrapper)
+ */
+
+static struct omap_hwmod_class_sysconfig omap54xx_emif_sysc = {
+	.rev_offs	= 0x0000,
+};
+
+static struct omap_hwmod_class omap54xx_emif_hwmod_class = {
+	.name	= "emif",
+	.sysc	= &omap54xx_emif_sysc,
+};
+
+/* emif1 */
+static struct omap_hwmod omap54xx_emif1_hwmod = {
+	.name		= "emif1",
+	.class		= &omap54xx_emif_hwmod_class,
+	.clkdm_name	= "emif_clkdm",
+	.flags		= HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET,
+	.main_clk	= "dpll_core_h11x2_ck",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = OMAP54XX_CM_EMIF_EMIF1_CLKCTRL_OFFSET,
+			.context_offs = OMAP54XX_RM_EMIF_EMIF1_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_HWCTRL,
+		},
+	},
+};
+
+/* emif2 */
+static struct omap_hwmod omap54xx_emif2_hwmod = {
+	.name		= "emif2",
+	.class		= &omap54xx_emif_hwmod_class,
+	.clkdm_name	= "emif_clkdm",
+	.flags		= HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET,
+	.main_clk	= "dpll_core_h11x2_ck",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = OMAP54XX_CM_EMIF_EMIF2_CLKCTRL_OFFSET,
+			.context_offs = OMAP54XX_RM_EMIF_EMIF2_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_HWCTRL,
+		},
+	},
+};
+
+/*
+ * 'gpio' class
+ * general purpose io module
+ */
+
+static struct omap_hwmod_class_sysconfig omap54xx_gpio_sysc = {
+	.rev_offs	= 0x0000,
+	.sysc_offs	= 0x0010,
+	.syss_offs	= 0x0114,
+	.sysc_flags	= (SYSC_HAS_AUTOIDLE | SYSC_HAS_ENAWAKEUP |
+			   SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET |
+			   SYSS_HAS_RESET_STATUS),
+	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+			   SIDLE_SMART_WKUP),
+	.sysc_fields	= &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap54xx_gpio_hwmod_class = {
+	.name	= "gpio",
+	.sysc	= &omap54xx_gpio_sysc,
+	.rev	= 2,
+};
+
+/* gpio dev_attr */
+static struct omap_gpio_dev_attr gpio_dev_attr = {
+	.bank_width	= 32,
+	.dbck_flag	= true,
+};
+
+/* gpio1 */
+static struct omap_hwmod_opt_clk gpio1_opt_clks[] = {
+	{ .role = "dbclk", .clk = "gpio1_dbclk" },
+};
+
+static struct omap_hwmod omap54xx_gpio1_hwmod = {
+	.name		= "gpio1",
+	.class		= &omap54xx_gpio_hwmod_class,
+	.clkdm_name	= "wkupaon_clkdm",
+	.main_clk	= "wkupaon_iclk_mux",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = OMAP54XX_CM_WKUPAON_GPIO1_CLKCTRL_OFFSET,
+			.context_offs = OMAP54XX_RM_WKUPAON_GPIO1_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_HWCTRL,
+		},
+	},
+	.opt_clks	= gpio1_opt_clks,
+	.opt_clks_cnt	= ARRAY_SIZE(gpio1_opt_clks),
+	.dev_attr	= &gpio_dev_attr,
+};
+
+/* gpio2 */
+static struct omap_hwmod_opt_clk gpio2_opt_clks[] = {
+	{ .role = "dbclk", .clk = "gpio2_dbclk" },
+};
+
+static struct omap_hwmod omap54xx_gpio2_hwmod = {
+	.name		= "gpio2",
+	.class		= &omap54xx_gpio_hwmod_class,
+	.clkdm_name	= "l4per_clkdm",
+	.flags		= HWMOD_CONTROL_OPT_CLKS_IN_RESET,
+	.main_clk	= "l4_root_clk_div",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = OMAP54XX_CM_L4PER_GPIO2_CLKCTRL_OFFSET,
+			.context_offs = OMAP54XX_RM_L4PER_GPIO2_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_HWCTRL,
+		},
+	},
+	.opt_clks	= gpio2_opt_clks,
+	.opt_clks_cnt	= ARRAY_SIZE(gpio2_opt_clks),
+	.dev_attr	= &gpio_dev_attr,
+};
+
+/* gpio3 */
+static struct omap_hwmod_opt_clk gpio3_opt_clks[] = {
+	{ .role = "dbclk", .clk = "gpio3_dbclk" },
+};
+
+static struct omap_hwmod omap54xx_gpio3_hwmod = {
+	.name		= "gpio3",
+	.class		= &omap54xx_gpio_hwmod_class,
+	.clkdm_name	= "l4per_clkdm",
+	.flags		= HWMOD_CONTROL_OPT_CLKS_IN_RESET,
+	.main_clk	= "l4_root_clk_div",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = OMAP54XX_CM_L4PER_GPIO3_CLKCTRL_OFFSET,
+			.context_offs = OMAP54XX_RM_L4PER_GPIO3_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_HWCTRL,
+		},
+	},
+	.opt_clks	= gpio3_opt_clks,
+	.opt_clks_cnt	= ARRAY_SIZE(gpio3_opt_clks),
+	.dev_attr	= &gpio_dev_attr,
+};
+
+/* gpio4 */
+static struct omap_hwmod_opt_clk gpio4_opt_clks[] = {
+	{ .role = "dbclk", .clk = "gpio4_dbclk" },
+};
+
+static struct omap_hwmod omap54xx_gpio4_hwmod = {
+	.name		= "gpio4",
+	.class		= &omap54xx_gpio_hwmod_class,
+	.clkdm_name	= "l4per_clkdm",
+	.flags		= HWMOD_CONTROL_OPT_CLKS_IN_RESET,
+	.main_clk	= "l4_root_clk_div",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = OMAP54XX_CM_L4PER_GPIO4_CLKCTRL_OFFSET,
+			.context_offs = OMAP54XX_RM_L4PER_GPIO4_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_HWCTRL,
+		},
+	},
+	.opt_clks	= gpio4_opt_clks,
+	.opt_clks_cnt	= ARRAY_SIZE(gpio4_opt_clks),
+	.dev_attr	= &gpio_dev_attr,
+};
+
+/* gpio5 */
+static struct omap_hwmod_opt_clk gpio5_opt_clks[] = {
+	{ .role = "dbclk", .clk = "gpio5_dbclk" },
+};
+
+static struct omap_hwmod omap54xx_gpio5_hwmod = {
+	.name		= "gpio5",
+	.class		= &omap54xx_gpio_hwmod_class,
+	.clkdm_name	= "l4per_clkdm",
+	.flags		= HWMOD_CONTROL_OPT_CLKS_IN_RESET,
+	.main_clk	= "l4_root_clk_div",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = OMAP54XX_CM_L4PER_GPIO5_CLKCTRL_OFFSET,
+			.context_offs = OMAP54XX_RM_L4PER_GPIO5_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_HWCTRL,
+		},
+	},
+	.opt_clks	= gpio5_opt_clks,
+	.opt_clks_cnt	= ARRAY_SIZE(gpio5_opt_clks),
+	.dev_attr	= &gpio_dev_attr,
+};
+
+/* gpio6 */
+static struct omap_hwmod_opt_clk gpio6_opt_clks[] = {
+	{ .role = "dbclk", .clk = "gpio6_dbclk" },
+};
+
+static struct omap_hwmod omap54xx_gpio6_hwmod = {
+	.name		= "gpio6",
+	.class		= &omap54xx_gpio_hwmod_class,
+	.clkdm_name	= "l4per_clkdm",
+	.flags		= HWMOD_CONTROL_OPT_CLKS_IN_RESET,
+	.main_clk	= "l4_root_clk_div",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = OMAP54XX_CM_L4PER_GPIO6_CLKCTRL_OFFSET,
+			.context_offs = OMAP54XX_RM_L4PER_GPIO6_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_HWCTRL,
+		},
+	},
+	.opt_clks	= gpio6_opt_clks,
+	.opt_clks_cnt	= ARRAY_SIZE(gpio6_opt_clks),
+	.dev_attr	= &gpio_dev_attr,
+};
+
+/* gpio7 */
+static struct omap_hwmod_opt_clk gpio7_opt_clks[] = {
+	{ .role = "dbclk", .clk = "gpio7_dbclk" },
+};
+
+static struct omap_hwmod omap54xx_gpio7_hwmod = {
+	.name		= "gpio7",
+	.class		= &omap54xx_gpio_hwmod_class,
+	.clkdm_name	= "l4per_clkdm",
+	.flags		= HWMOD_CONTROL_OPT_CLKS_IN_RESET,
+	.main_clk	= "l4_root_clk_div",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = OMAP54XX_CM_L4PER_GPIO7_CLKCTRL_OFFSET,
+			.context_offs = OMAP54XX_RM_L4PER_GPIO7_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_HWCTRL,
+		},
+	},
+	.opt_clks	= gpio7_opt_clks,
+	.opt_clks_cnt	= ARRAY_SIZE(gpio7_opt_clks),
+	.dev_attr	= &gpio_dev_attr,
+};
+
+/* gpio8 */
+static struct omap_hwmod_opt_clk gpio8_opt_clks[] = {
+	{ .role = "dbclk", .clk = "gpio8_dbclk" },
+};
+
+static struct omap_hwmod omap54xx_gpio8_hwmod = {
+	.name		= "gpio8",
+	.class		= &omap54xx_gpio_hwmod_class,
+	.clkdm_name	= "l4per_clkdm",
+	.flags		= HWMOD_CONTROL_OPT_CLKS_IN_RESET,
+	.main_clk	= "l4_root_clk_div",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = OMAP54XX_CM_L4PER_GPIO8_CLKCTRL_OFFSET,
+			.context_offs = OMAP54XX_RM_L4PER_GPIO8_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_HWCTRL,
+		},
+	},
+	.opt_clks	= gpio8_opt_clks,
+	.opt_clks_cnt	= ARRAY_SIZE(gpio8_opt_clks),
+	.dev_attr	= &gpio_dev_attr,
+};
+
+/*
+ * 'i2c' class
+ * multimaster high-speed i2c controller
+ */
+
+static struct omap_hwmod_class_sysconfig omap54xx_i2c_sysc = {
+	.sysc_offs	= 0x0010,
+	.syss_offs	= 0x0090,
+	.sysc_flags	= (SYSC_HAS_AUTOIDLE | SYSC_HAS_CLOCKACTIVITY |
+			   SYSC_HAS_ENAWAKEUP | SYSC_HAS_SIDLEMODE |
+			   SYSC_HAS_SOFTRESET | SYSS_HAS_RESET_STATUS),
+	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+			   SIDLE_SMART_WKUP),
+	.clockact	= CLOCKACT_TEST_ICLK,
+	.sysc_fields	= &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap54xx_i2c_hwmod_class = {
+	.name	= "i2c",
+	.sysc	= &omap54xx_i2c_sysc,
+	.reset	= &omap_i2c_reset,
+	.rev	= OMAP_I2C_IP_VERSION_2,
+};
+
+/* i2c dev_attr */
+static struct omap_i2c_dev_attr i2c_dev_attr = {
+	.flags	= OMAP_I2C_FLAG_BUS_SHIFT_NONE,
+};
+
+/* i2c1 */
+static struct omap_hwmod omap54xx_i2c1_hwmod = {
+	.name		= "i2c1",
+	.class		= &omap54xx_i2c_hwmod_class,
+	.clkdm_name	= "l4per_clkdm",
+	.flags		= HWMOD_16BIT_REG | HWMOD_SET_DEFAULT_CLOCKACT,
+	.main_clk	= "func_96m_fclk",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = OMAP54XX_CM_L4PER_I2C1_CLKCTRL_OFFSET,
+			.context_offs = OMAP54XX_RM_L4PER_I2C1_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+	.dev_attr	= &i2c_dev_attr,
+};
+
+/* i2c2 */
+static struct omap_hwmod omap54xx_i2c2_hwmod = {
+	.name		= "i2c2",
+	.class		= &omap54xx_i2c_hwmod_class,
+	.clkdm_name	= "l4per_clkdm",
+	.flags		= HWMOD_16BIT_REG | HWMOD_SET_DEFAULT_CLOCKACT,
+	.main_clk	= "func_96m_fclk",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = OMAP54XX_CM_L4PER_I2C2_CLKCTRL_OFFSET,
+			.context_offs = OMAP54XX_RM_L4PER_I2C2_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+	.dev_attr	= &i2c_dev_attr,
+};
+
+/* i2c3 */
+static struct omap_hwmod omap54xx_i2c3_hwmod = {
+	.name		= "i2c3",
+	.class		= &omap54xx_i2c_hwmod_class,
+	.clkdm_name	= "l4per_clkdm",
+	.flags		= HWMOD_16BIT_REG | HWMOD_SET_DEFAULT_CLOCKACT,
+	.main_clk	= "func_96m_fclk",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = OMAP54XX_CM_L4PER_I2C3_CLKCTRL_OFFSET,
+			.context_offs = OMAP54XX_RM_L4PER_I2C3_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+	.dev_attr	= &i2c_dev_attr,
+};
+
+/* i2c4 */
+static struct omap_hwmod omap54xx_i2c4_hwmod = {
+	.name		= "i2c4",
+	.class		= &omap54xx_i2c_hwmod_class,
+	.clkdm_name	= "l4per_clkdm",
+	.flags		= HWMOD_16BIT_REG | HWMOD_SET_DEFAULT_CLOCKACT,
+	.main_clk	= "func_96m_fclk",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = OMAP54XX_CM_L4PER_I2C4_CLKCTRL_OFFSET,
+			.context_offs = OMAP54XX_RM_L4PER_I2C4_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+	.dev_attr	= &i2c_dev_attr,
+};
+
+/* i2c5 */
+static struct omap_hwmod omap54xx_i2c5_hwmod = {
+	.name		= "i2c5",
+	.class		= &omap54xx_i2c_hwmod_class,
+	.clkdm_name	= "l4per_clkdm",
+	.flags		= HWMOD_16BIT_REG | HWMOD_SET_DEFAULT_CLOCKACT,
+	.main_clk	= "func_96m_fclk",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = OMAP54XX_CM_L4PER_I2C5_CLKCTRL_OFFSET,
+			.context_offs = OMAP54XX_RM_L4PER_I2C5_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+	.dev_attr	= &i2c_dev_attr,
+};
+
+/*
+ * 'kbd' class
+ * keyboard controller
+ */
+
+static struct omap_hwmod_class_sysconfig omap54xx_kbd_sysc = {
+	.rev_offs	= 0x0000,
+	.sysc_offs	= 0x0010,
+	.sysc_flags	= (SYSC_HAS_EMUFREE | SYSC_HAS_SIDLEMODE |
+			   SYSC_HAS_SOFTRESET),
+	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+	.sysc_fields	= &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap54xx_kbd_hwmod_class = {
+	.name	= "kbd",
+	.sysc	= &omap54xx_kbd_sysc,
+};
+
+/* kbd */
+static struct omap_hwmod omap54xx_kbd_hwmod = {
+	.name		= "kbd",
+	.class		= &omap54xx_kbd_hwmod_class,
+	.clkdm_name	= "wkupaon_clkdm",
+	.main_clk	= "sys_32k_ck",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = OMAP54XX_CM_WKUPAON_KBD_CLKCTRL_OFFSET,
+			.context_offs = OMAP54XX_RM_WKUPAON_KBD_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+};
+
+/*
+ * 'mcbsp' class
+ * multi channel buffered serial port controller
+ */
+
+static struct omap_hwmod_class_sysconfig omap54xx_mcbsp_sysc = {
+	.sysc_offs	= 0x008c,
+	.sysc_flags	= (SYSC_HAS_CLOCKACTIVITY | SYSC_HAS_ENAWAKEUP |
+			   SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET),
+	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+	.sysc_fields	= &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap54xx_mcbsp_hwmod_class = {
+	.name	= "mcbsp",
+	.sysc	= &omap54xx_mcbsp_sysc,
+	.rev	= MCBSP_CONFIG_TYPE4,
+};
+
+/* mcbsp1 */
+static struct omap_hwmod_opt_clk mcbsp1_opt_clks[] = {
+	{ .role = "pad_fck", .clk = "pad_clks_ck" },
+	{ .role = "prcm_fck", .clk = "mcbsp1_sync_mux_ck" },
+};
+
+static struct omap_hwmod omap54xx_mcbsp1_hwmod = {
+	.name		= "mcbsp1",
+	.class		= &omap54xx_mcbsp_hwmod_class,
+	.clkdm_name	= "abe_clkdm",
+	.main_clk	= "mcbsp1_gfclk",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = OMAP54XX_CM_ABE_MCBSP1_CLKCTRL_OFFSET,
+			.context_offs = OMAP54XX_RM_ABE_MCBSP1_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+	.opt_clks	= mcbsp1_opt_clks,
+	.opt_clks_cnt	= ARRAY_SIZE(mcbsp1_opt_clks),
+};
+
+/* mcbsp2 */
+static struct omap_hwmod_opt_clk mcbsp2_opt_clks[] = {
+	{ .role = "pad_fck", .clk = "pad_clks_ck" },
+	{ .role = "prcm_fck", .clk = "mcbsp2_sync_mux_ck" },
+};
+
+static struct omap_hwmod omap54xx_mcbsp2_hwmod = {
+	.name		= "mcbsp2",
+	.class		= &omap54xx_mcbsp_hwmod_class,
+	.clkdm_name	= "abe_clkdm",
+	.main_clk	= "mcbsp2_gfclk",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = OMAP54XX_CM_ABE_MCBSP2_CLKCTRL_OFFSET,
+			.context_offs = OMAP54XX_RM_ABE_MCBSP2_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+	.opt_clks	= mcbsp2_opt_clks,
+	.opt_clks_cnt	= ARRAY_SIZE(mcbsp2_opt_clks),
+};
+
+/* mcbsp3 */
+static struct omap_hwmod_opt_clk mcbsp3_opt_clks[] = {
+	{ .role = "pad_fck", .clk = "pad_clks_ck" },
+	{ .role = "prcm_fck", .clk = "mcbsp3_sync_mux_ck" },
+};
+
+static struct omap_hwmod omap54xx_mcbsp3_hwmod = {
+	.name		= "mcbsp3",
+	.class		= &omap54xx_mcbsp_hwmod_class,
+	.clkdm_name	= "abe_clkdm",
+	.main_clk	= "mcbsp3_gfclk",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = OMAP54XX_CM_ABE_MCBSP3_CLKCTRL_OFFSET,
+			.context_offs = OMAP54XX_RM_ABE_MCBSP3_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+	.opt_clks	= mcbsp3_opt_clks,
+	.opt_clks_cnt	= ARRAY_SIZE(mcbsp3_opt_clks),
+};
+
+/*
+ * 'mcpdm' class
+ * multi channel pdm controller (proprietary interface with phoenix power
+ * ic)
+ */
+
+static struct omap_hwmod_class_sysconfig omap54xx_mcpdm_sysc = {
+	.rev_offs	= 0x0000,
+	.sysc_offs	= 0x0010,
+	.sysc_flags	= (SYSC_HAS_EMUFREE | SYSC_HAS_RESET_STATUS |
+			   SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET),
+	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+			   SIDLE_SMART_WKUP),
+	.sysc_fields	= &omap_hwmod_sysc_type2,
+};
+
+static struct omap_hwmod_class omap54xx_mcpdm_hwmod_class = {
+	.name	= "mcpdm",
+	.sysc	= &omap54xx_mcpdm_sysc,
+};
+
+/* mcpdm */
+static struct omap_hwmod omap54xx_mcpdm_hwmod = {
+	.name		= "mcpdm",
+	.class		= &omap54xx_mcpdm_hwmod_class,
+	.clkdm_name	= "abe_clkdm",
+	/*
+	 * It's suspected that the McPDM requires an off-chip main
+	 * functional clock, controlled via I2C.  This IP block is
+	 * currently reset very early during boot, before I2C is
+	 * available, so it doesn't seem that we have any choice in
+	 * the kernel other than to avoid resetting it.  XXX This is
+	 * really a hardware issue workaround: every IP block should
+	 * be able to source its main functional clock from either
+	 * on-chip or off-chip sources.  McPDM seems to be the only
+	 * current exception.
+	 */
+
+	.flags		= HWMOD_EXT_OPT_MAIN_CLK,
+	.main_clk	= "pad_clks_ck",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = OMAP54XX_CM_ABE_MCPDM_CLKCTRL_OFFSET,
+			.context_offs = OMAP54XX_RM_ABE_MCPDM_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+};
+
+/*
+ * 'mcspi' class
+ * multichannel serial port interface (mcspi) / master/slave synchronous serial
+ * bus
+ */
+
+static struct omap_hwmod_class_sysconfig omap54xx_mcspi_sysc = {
+	.rev_offs	= 0x0000,
+	.sysc_offs	= 0x0010,
+	.sysc_flags	= (SYSC_HAS_EMUFREE | SYSC_HAS_RESET_STATUS |
+			   SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET),
+	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+			   SIDLE_SMART_WKUP),
+	.sysc_fields	= &omap_hwmod_sysc_type2,
+};
+
+static struct omap_hwmod_class omap54xx_mcspi_hwmod_class = {
+	.name	= "mcspi",
+	.sysc	= &omap54xx_mcspi_sysc,
+	.rev	= OMAP4_MCSPI_REV,
+};
+
+/* mcspi1 */
+/* mcspi1 dev_attr */
+static struct omap2_mcspi_dev_attr mcspi1_dev_attr = {
+	.num_chipselect	= 4,
+};
+
+static struct omap_hwmod omap54xx_mcspi1_hwmod = {
+	.name		= "mcspi1",
+	.class		= &omap54xx_mcspi_hwmod_class,
+	.clkdm_name	= "l4per_clkdm",
+	.main_clk	= "func_48m_fclk",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = OMAP54XX_CM_L4PER_MCSPI1_CLKCTRL_OFFSET,
+			.context_offs = OMAP54XX_RM_L4PER_MCSPI1_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+	.dev_attr	= &mcspi1_dev_attr,
+};
+
+/* mcspi2 */
+/* mcspi2 dev_attr */
+static struct omap2_mcspi_dev_attr mcspi2_dev_attr = {
+	.num_chipselect	= 2,
+};
+
+static struct omap_hwmod omap54xx_mcspi2_hwmod = {
+	.name		= "mcspi2",
+	.class		= &omap54xx_mcspi_hwmod_class,
+	.clkdm_name	= "l4per_clkdm",
+	.main_clk	= "func_48m_fclk",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = OMAP54XX_CM_L4PER_MCSPI2_CLKCTRL_OFFSET,
+			.context_offs = OMAP54XX_RM_L4PER_MCSPI2_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+	.dev_attr	= &mcspi2_dev_attr,
+};
+
+/* mcspi3 */
+/* mcspi3 dev_attr */
+static struct omap2_mcspi_dev_attr mcspi3_dev_attr = {
+	.num_chipselect	= 2,
+};
+
+static struct omap_hwmod omap54xx_mcspi3_hwmod = {
+	.name		= "mcspi3",
+	.class		= &omap54xx_mcspi_hwmod_class,
+	.clkdm_name	= "l4per_clkdm",
+	.main_clk	= "func_48m_fclk",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = OMAP54XX_CM_L4PER_MCSPI3_CLKCTRL_OFFSET,
+			.context_offs = OMAP54XX_RM_L4PER_MCSPI3_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+	.dev_attr	= &mcspi3_dev_attr,
+};
+
+/* mcspi4 */
+/* mcspi4 dev_attr */
+static struct omap2_mcspi_dev_attr mcspi4_dev_attr = {
+	.num_chipselect	= 1,
+};
+
+static struct omap_hwmod omap54xx_mcspi4_hwmod = {
+	.name		= "mcspi4",
+	.class		= &omap54xx_mcspi_hwmod_class,
+	.clkdm_name	= "l4per_clkdm",
+	.main_clk	= "func_48m_fclk",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = OMAP54XX_CM_L4PER_MCSPI4_CLKCTRL_OFFSET,
+			.context_offs = OMAP54XX_RM_L4PER_MCSPI4_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+	.dev_attr	= &mcspi4_dev_attr,
+};
+
+/*
+ * 'mmc' class
+ * multimedia card high-speed/sd/sdio (mmc/sd/sdio) host controller
+ */
+
+static struct omap_hwmod_class_sysconfig omap54xx_mmc_sysc = {
+	.rev_offs	= 0x0000,
+	.sysc_offs	= 0x0010,
+	.sysc_flags	= (SYSC_HAS_EMUFREE | SYSC_HAS_MIDLEMODE |
+			   SYSC_HAS_RESET_STATUS | SYSC_HAS_SIDLEMODE |
+			   SYSC_HAS_SOFTRESET),
+	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+			   SIDLE_SMART_WKUP | MSTANDBY_FORCE | MSTANDBY_NO |
+			   MSTANDBY_SMART | MSTANDBY_SMART_WKUP),
+	.sysc_fields	= &omap_hwmod_sysc_type2,
+};
+
+static struct omap_hwmod_class omap54xx_mmc_hwmod_class = {
+	.name	= "mmc",
+	.sysc	= &omap54xx_mmc_sysc,
+};
+
+/* mmc1 */
+static struct omap_hwmod_opt_clk mmc1_opt_clks[] = {
+	{ .role = "32khz_clk", .clk = "mmc1_32khz_clk" },
+};
+
+/* mmc1 dev_attr */
+static struct omap_mmc_dev_attr mmc1_dev_attr = {
+	.flags	= OMAP_HSMMC_SUPPORTS_DUAL_VOLT,
+};
+
+static struct omap_hwmod omap54xx_mmc1_hwmod = {
+	.name		= "mmc1",
+	.class		= &omap54xx_mmc_hwmod_class,
+	.clkdm_name	= "l3init_clkdm",
+	.main_clk	= "mmc1_fclk",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = OMAP54XX_CM_L3INIT_MMC1_CLKCTRL_OFFSET,
+			.context_offs = OMAP54XX_RM_L3INIT_MMC1_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+	.opt_clks	= mmc1_opt_clks,
+	.opt_clks_cnt	= ARRAY_SIZE(mmc1_opt_clks),
+	.dev_attr	= &mmc1_dev_attr,
+};
+
+/* mmc2 */
+static struct omap_hwmod omap54xx_mmc2_hwmod = {
+	.name		= "mmc2",
+	.class		= &omap54xx_mmc_hwmod_class,
+	.clkdm_name	= "l3init_clkdm",
+	.main_clk	= "mmc2_fclk",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = OMAP54XX_CM_L3INIT_MMC2_CLKCTRL_OFFSET,
+			.context_offs = OMAP54XX_RM_L3INIT_MMC2_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+};
+
+/* mmc3 */
+static struct omap_hwmod omap54xx_mmc3_hwmod = {
+	.name		= "mmc3",
+	.class		= &omap54xx_mmc_hwmod_class,
+	.clkdm_name	= "l4per_clkdm",
+	.main_clk	= "func_48m_fclk",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = OMAP54XX_CM_L4PER_MMC3_CLKCTRL_OFFSET,
+			.context_offs = OMAP54XX_RM_L4PER_MMC3_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+};
+
+/* mmc4 */
+static struct omap_hwmod omap54xx_mmc4_hwmod = {
+	.name		= "mmc4",
+	.class		= &omap54xx_mmc_hwmod_class,
+	.clkdm_name	= "l4per_clkdm",
+	.main_clk	= "func_48m_fclk",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = OMAP54XX_CM_L4PER_MMC4_CLKCTRL_OFFSET,
+			.context_offs = OMAP54XX_RM_L4PER_MMC4_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+};
+
+/* mmc5 */
+static struct omap_hwmod omap54xx_mmc5_hwmod = {
+	.name		= "mmc5",
+	.class		= &omap54xx_mmc_hwmod_class,
+	.clkdm_name	= "l4per_clkdm",
+	.main_clk	= "func_96m_fclk",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = OMAP54XX_CM_L4PER_MMC5_CLKCTRL_OFFSET,
+			.context_offs = OMAP54XX_RM_L4PER_MMC5_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+};
+
+/*
+ * 'mpu' class
+ * mpu sub-system
+ */
+
+static struct omap_hwmod_class omap54xx_mpu_hwmod_class = {
+	.name	= "mpu",
+};
+
+/* mpu */
+static struct omap_hwmod omap54xx_mpu_hwmod = {
+	.name		= "mpu",
+	.class		= &omap54xx_mpu_hwmod_class,
+	.clkdm_name	= "mpu_clkdm",
+	.flags		= HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET,
+	.main_clk	= "dpll_mpu_m2_ck",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = OMAP54XX_CM_MPU_MPU_CLKCTRL_OFFSET,
+			.context_offs = OMAP54XX_RM_MPU_MPU_CONTEXT_OFFSET,
+		},
+	},
+};
+
+/*
+ * 'timer' class
+ * general purpose timer module with accurate 1ms tick
+ * This class contains several variants: ['timer_1ms', 'timer']
+ */
+
+static struct omap_hwmod_class_sysconfig omap54xx_timer_1ms_sysc = {
+	.rev_offs	= 0x0000,
+	.sysc_offs	= 0x0010,
+	.sysc_flags	= (SYSC_HAS_EMUFREE | SYSC_HAS_RESET_STATUS |
+			   SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET),
+	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+			   SIDLE_SMART_WKUP),
+	.sysc_fields	= &omap_hwmod_sysc_type2,
+	.clockact	= CLOCKACT_TEST_ICLK,
+};
+
+static struct omap_hwmod_class omap54xx_timer_1ms_hwmod_class = {
+	.name	= "timer",
+	.sysc	= &omap54xx_timer_1ms_sysc,
+};
+
+static struct omap_hwmod_class_sysconfig omap54xx_timer_sysc = {
+	.rev_offs	= 0x0000,
+	.sysc_offs	= 0x0010,
+	.sysc_flags	= (SYSC_HAS_EMUFREE | SYSC_HAS_RESET_STATUS |
+			   SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET),
+	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+			   SIDLE_SMART_WKUP),
+	.sysc_fields	= &omap_hwmod_sysc_type2,
+};
+
+static struct omap_hwmod_class omap54xx_timer_hwmod_class = {
+	.name	= "timer",
+	.sysc	= &omap54xx_timer_sysc,
+};
+
+/* timer1 */
+static struct omap_hwmod omap54xx_timer1_hwmod = {
+	.name		= "timer1",
+	.class		= &omap54xx_timer_1ms_hwmod_class,
+	.clkdm_name	= "wkupaon_clkdm",
+	.main_clk	= "timer1_gfclk_mux",
+	.flags		= HWMOD_SET_DEFAULT_CLOCKACT,
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = OMAP54XX_CM_WKUPAON_TIMER1_CLKCTRL_OFFSET,
+			.context_offs = OMAP54XX_RM_WKUPAON_TIMER1_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+};
+
+/* timer2 */
+static struct omap_hwmod omap54xx_timer2_hwmod = {
+	.name		= "timer2",
+	.class		= &omap54xx_timer_1ms_hwmod_class,
+	.clkdm_name	= "l4per_clkdm",
+	.main_clk	= "timer2_gfclk_mux",
+	.flags		= HWMOD_SET_DEFAULT_CLOCKACT,
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = OMAP54XX_CM_L4PER_TIMER2_CLKCTRL_OFFSET,
+			.context_offs = OMAP54XX_RM_L4PER_TIMER2_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+};
+
+/* timer3 */
+static struct omap_hwmod omap54xx_timer3_hwmod = {
+	.name		= "timer3",
+	.class		= &omap54xx_timer_hwmod_class,
+	.clkdm_name	= "l4per_clkdm",
+	.main_clk	= "timer3_gfclk_mux",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = OMAP54XX_CM_L4PER_TIMER3_CLKCTRL_OFFSET,
+			.context_offs = OMAP54XX_RM_L4PER_TIMER3_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+};
+
+/* timer4 */
+static struct omap_hwmod omap54xx_timer4_hwmod = {
+	.name		= "timer4",
+	.class		= &omap54xx_timer_hwmod_class,
+	.clkdm_name	= "l4per_clkdm",
+	.main_clk	= "timer4_gfclk_mux",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = OMAP54XX_CM_L4PER_TIMER4_CLKCTRL_OFFSET,
+			.context_offs = OMAP54XX_RM_L4PER_TIMER4_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+};
+
+/* timer5 */
+static struct omap_hwmod omap54xx_timer5_hwmod = {
+	.name		= "timer5",
+	.class		= &omap54xx_timer_hwmod_class,
+	.clkdm_name	= "abe_clkdm",
+	.main_clk	= "timer5_gfclk_mux",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = OMAP54XX_CM_ABE_TIMER5_CLKCTRL_OFFSET,
+			.context_offs = OMAP54XX_RM_ABE_TIMER5_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+};
+
+/* timer6 */
+static struct omap_hwmod omap54xx_timer6_hwmod = {
+	.name		= "timer6",
+	.class		= &omap54xx_timer_hwmod_class,
+	.clkdm_name	= "abe_clkdm",
+	.main_clk	= "timer6_gfclk_mux",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = OMAP54XX_CM_ABE_TIMER6_CLKCTRL_OFFSET,
+			.context_offs = OMAP54XX_RM_ABE_TIMER6_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+};
+
+/* timer7 */
+static struct omap_hwmod omap54xx_timer7_hwmod = {
+	.name		= "timer7",
+	.class		= &omap54xx_timer_hwmod_class,
+	.clkdm_name	= "abe_clkdm",
+	.main_clk	= "timer7_gfclk_mux",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = OMAP54XX_CM_ABE_TIMER7_CLKCTRL_OFFSET,
+			.context_offs = OMAP54XX_RM_ABE_TIMER7_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+};
+
+/* timer8 */
+static struct omap_hwmod omap54xx_timer8_hwmod = {
+	.name		= "timer8",
+	.class		= &omap54xx_timer_hwmod_class,
+	.clkdm_name	= "abe_clkdm",
+	.main_clk	= "timer8_gfclk_mux",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = OMAP54XX_CM_ABE_TIMER8_CLKCTRL_OFFSET,
+			.context_offs = OMAP54XX_RM_ABE_TIMER8_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+};
+
+/* timer9 */
+static struct omap_hwmod omap54xx_timer9_hwmod = {
+	.name		= "timer9",
+	.class		= &omap54xx_timer_hwmod_class,
+	.clkdm_name	= "l4per_clkdm",
+	.main_clk	= "timer9_gfclk_mux",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = OMAP54XX_CM_L4PER_TIMER9_CLKCTRL_OFFSET,
+			.context_offs = OMAP54XX_RM_L4PER_TIMER9_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+};
+
+/* timer10 */
+static struct omap_hwmod omap54xx_timer10_hwmod = {
+	.name		= "timer10",
+	.class		= &omap54xx_timer_1ms_hwmod_class,
+	.clkdm_name	= "l4per_clkdm",
+	.main_clk	= "timer10_gfclk_mux",
+	.flags		= HWMOD_SET_DEFAULT_CLOCKACT,
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = OMAP54XX_CM_L4PER_TIMER10_CLKCTRL_OFFSET,
+			.context_offs = OMAP54XX_RM_L4PER_TIMER10_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+};
+
+/* timer11 */
+static struct omap_hwmod omap54xx_timer11_hwmod = {
+	.name		= "timer11",
+	.class		= &omap54xx_timer_hwmod_class,
+	.clkdm_name	= "l4per_clkdm",
+	.main_clk	= "timer11_gfclk_mux",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = OMAP54XX_CM_L4PER_TIMER11_CLKCTRL_OFFSET,
+			.context_offs = OMAP54XX_RM_L4PER_TIMER11_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+};
+
+/*
+ * 'uart' class
+ * universal asynchronous receiver/transmitter (uart)
+ */
+
+static struct omap_hwmod_class_sysconfig omap54xx_uart_sysc = {
+	.rev_offs	= 0x0050,
+	.sysc_offs	= 0x0054,
+	.syss_offs	= 0x0058,
+	.sysc_flags	= (SYSC_HAS_AUTOIDLE | SYSC_HAS_ENAWAKEUP |
+			   SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET |
+			   SYSS_HAS_RESET_STATUS),
+	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+			   SIDLE_SMART_WKUP),
+	.sysc_fields	= &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap54xx_uart_hwmod_class = {
+	.name	= "uart",
+	.sysc	= &omap54xx_uart_sysc,
+};
+
+/* uart1 */
+static struct omap_hwmod omap54xx_uart1_hwmod = {
+	.name		= "uart1",
+	.class		= &omap54xx_uart_hwmod_class,
+	.clkdm_name	= "l4per_clkdm",
+	.main_clk	= "func_48m_fclk",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = OMAP54XX_CM_L4PER_UART1_CLKCTRL_OFFSET,
+			.context_offs = OMAP54XX_RM_L4PER_UART1_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+};
+
+/* uart2 */
+static struct omap_hwmod omap54xx_uart2_hwmod = {
+	.name		= "uart2",
+	.class		= &omap54xx_uart_hwmod_class,
+	.clkdm_name	= "l4per_clkdm",
+	.main_clk	= "func_48m_fclk",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = OMAP54XX_CM_L4PER_UART2_CLKCTRL_OFFSET,
+			.context_offs = OMAP54XX_RM_L4PER_UART2_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+};
+
+/* uart3 */
+static struct omap_hwmod omap54xx_uart3_hwmod = {
+	.name		= "uart3",
+	.class		= &omap54xx_uart_hwmod_class,
+	.clkdm_name	= "l4per_clkdm",
+	.flags		= HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET,
+	.main_clk	= "func_48m_fclk",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = OMAP54XX_CM_L4PER_UART3_CLKCTRL_OFFSET,
+			.context_offs = OMAP54XX_RM_L4PER_UART3_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+};
+
+/* uart4 */
+static struct omap_hwmod omap54xx_uart4_hwmod = {
+	.name		= "uart4",
+	.class		= &omap54xx_uart_hwmod_class,
+	.clkdm_name	= "l4per_clkdm",
+	.main_clk	= "func_48m_fclk",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = OMAP54XX_CM_L4PER_UART4_CLKCTRL_OFFSET,
+			.context_offs = OMAP54XX_RM_L4PER_UART4_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+};
+
+/* uart5 */
+static struct omap_hwmod omap54xx_uart5_hwmod = {
+	.name		= "uart5",
+	.class		= &omap54xx_uart_hwmod_class,
+	.clkdm_name	= "l4per_clkdm",
+	.main_clk	= "func_48m_fclk",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = OMAP54XX_CM_L4PER_UART5_CLKCTRL_OFFSET,
+			.context_offs = OMAP54XX_RM_L4PER_UART5_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+};
+
+/* uart6 */
+static struct omap_hwmod omap54xx_uart6_hwmod = {
+	.name		= "uart6",
+	.class		= &omap54xx_uart_hwmod_class,
+	.clkdm_name	= "l4per_clkdm",
+	.main_clk	= "func_48m_fclk",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = OMAP54XX_CM_L4PER_UART6_CLKCTRL_OFFSET,
+			.context_offs = OMAP54XX_RM_L4PER_UART6_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+};
+
+/*
+ * 'usb_otg_ss' class
+ * 2.0 super speed (usb_otg_ss) controller
+ */
+
+static struct omap_hwmod_class_sysconfig omap54xx_usb_otg_ss_sysc = {
+	.rev_offs	= 0x0000,
+	.sysc_offs	= 0x0010,
+	.sysc_flags	= (SYSC_HAS_DMADISABLE | SYSC_HAS_MIDLEMODE |
+			   SYSC_HAS_SIDLEMODE),
+	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+			   SIDLE_SMART_WKUP | MSTANDBY_FORCE | MSTANDBY_NO |
+			   MSTANDBY_SMART | MSTANDBY_SMART_WKUP),
+	.sysc_fields	= &omap_hwmod_sysc_type2,
+};
+
+static struct omap_hwmod_class omap54xx_usb_otg_ss_hwmod_class = {
+	.name	= "usb_otg_ss",
+	.sysc	= &omap54xx_usb_otg_ss_sysc,
+};
+
+/* usb_otg_ss */
+static struct omap_hwmod_opt_clk usb_otg_ss_opt_clks[] = {
+	{ .role = "refclk960m", .clk = "usb_otg_ss_refclk960m" },
+};
+
+static struct omap_hwmod omap54xx_usb_otg_ss_hwmod = {
+	.name		= "usb_otg_ss",
+	.class		= &omap54xx_usb_otg_ss_hwmod_class,
+	.clkdm_name	= "l3init_clkdm",
+	.flags		= HWMOD_SWSUP_SIDLE,
+	.main_clk	= "dpll_core_h13x2_ck",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = OMAP54XX_CM_L3INIT_USB_OTG_SS_CLKCTRL_OFFSET,
+			.context_offs = OMAP54XX_RM_L3INIT_USB_OTG_SS_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_HWCTRL,
+		},
+	},
+	.opt_clks	= usb_otg_ss_opt_clks,
+	.opt_clks_cnt	= ARRAY_SIZE(usb_otg_ss_opt_clks),
+};
+
+/*
+ * 'wd_timer' class
+ * 32-bit watchdog upward counter that generates a pulse on the reset pin on
+ * overflow condition
+ */
+
+static struct omap_hwmod_class_sysconfig omap54xx_wd_timer_sysc = {
+	.rev_offs	= 0x0000,
+	.sysc_offs	= 0x0010,
+	.syss_offs	= 0x0014,
+	.sysc_flags	= (SYSC_HAS_EMUFREE | SYSC_HAS_SIDLEMODE |
+			   SYSC_HAS_SOFTRESET | SYSS_HAS_RESET_STATUS),
+	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+			   SIDLE_SMART_WKUP),
+	.sysc_fields	= &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap54xx_wd_timer_hwmod_class = {
+	.name		= "wd_timer",
+	.sysc		= &omap54xx_wd_timer_sysc,
+	.pre_shutdown	= &omap2_wd_timer_disable,
+};
+
+/* wd_timer2 */
+static struct omap_hwmod omap54xx_wd_timer2_hwmod = {
+	.name		= "wd_timer2",
+	.class		= &omap54xx_wd_timer_hwmod_class,
+	.clkdm_name	= "wkupaon_clkdm",
+	.main_clk	= "sys_32k_ck",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = OMAP54XX_CM_WKUPAON_WD_TIMER2_CLKCTRL_OFFSET,
+			.context_offs = OMAP54XX_RM_WKUPAON_WD_TIMER2_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+};
+
+
+/*
+ * Interfaces
+ */
+
+/* l3_main_1 -> dmm */
+static struct omap_hwmod_ocp_if omap54xx_l3_main_1__dmm = {
+	.master		= &omap54xx_l3_main_1_hwmod,
+	.slave		= &omap54xx_dmm_hwmod,
+	.clk		= "l3_iclk_div",
+	.user		= OCP_USER_SDMA,
+};
+
+/* l3_main_3 -> l3_instr */
+static struct omap_hwmod_ocp_if omap54xx_l3_main_3__l3_instr = {
+	.master		= &omap54xx_l3_main_3_hwmod,
+	.slave		= &omap54xx_l3_instr_hwmod,
+	.clk		= "l3_iclk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l3_main_2 -> l3_main_1 */
+static struct omap_hwmod_ocp_if omap54xx_l3_main_2__l3_main_1 = {
+	.master		= &omap54xx_l3_main_2_hwmod,
+	.slave		= &omap54xx_l3_main_1_hwmod,
+	.clk		= "l3_iclk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_cfg -> l3_main_1 */
+static struct omap_hwmod_ocp_if omap54xx_l4_cfg__l3_main_1 = {
+	.master		= &omap54xx_l4_cfg_hwmod,
+	.slave		= &omap54xx_l3_main_1_hwmod,
+	.clk		= "l3_iclk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* mpu -> l3_main_1 */
+static struct omap_hwmod_ocp_if omap54xx_mpu__l3_main_1 = {
+	.master		= &omap54xx_mpu_hwmod,
+	.slave		= &omap54xx_l3_main_1_hwmod,
+	.clk		= "l3_iclk_div",
+	.user		= OCP_USER_MPU,
+};
+
+/* l3_main_1 -> l3_main_2 */
+static struct omap_hwmod_ocp_if omap54xx_l3_main_1__l3_main_2 = {
+	.master		= &omap54xx_l3_main_1_hwmod,
+	.slave		= &omap54xx_l3_main_2_hwmod,
+	.clk		= "l3_iclk_div",
+	.user		= OCP_USER_MPU,
+};
+
+/* l4_cfg -> l3_main_2 */
+static struct omap_hwmod_ocp_if omap54xx_l4_cfg__l3_main_2 = {
+	.master		= &omap54xx_l4_cfg_hwmod,
+	.slave		= &omap54xx_l3_main_2_hwmod,
+	.clk		= "l3_iclk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l3_main_1 -> l3_main_3 */
+static struct omap_hwmod_ocp_if omap54xx_l3_main_1__l3_main_3 = {
+	.master		= &omap54xx_l3_main_1_hwmod,
+	.slave		= &omap54xx_l3_main_3_hwmod,
+	.clk		= "l3_iclk_div",
+	.user		= OCP_USER_MPU,
+};
+
+/* l3_main_2 -> l3_main_3 */
+static struct omap_hwmod_ocp_if omap54xx_l3_main_2__l3_main_3 = {
+	.master		= &omap54xx_l3_main_2_hwmod,
+	.slave		= &omap54xx_l3_main_3_hwmod,
+	.clk		= "l3_iclk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_cfg -> l3_main_3 */
+static struct omap_hwmod_ocp_if omap54xx_l4_cfg__l3_main_3 = {
+	.master		= &omap54xx_l4_cfg_hwmod,
+	.slave		= &omap54xx_l3_main_3_hwmod,
+	.clk		= "l3_iclk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l3_main_1 -> l4_abe */
+static struct omap_hwmod_ocp_if omap54xx_l3_main_1__l4_abe = {
+	.master		= &omap54xx_l3_main_1_hwmod,
+	.slave		= &omap54xx_l4_abe_hwmod,
+	.clk		= "abe_iclk",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* mpu -> l4_abe */
+static struct omap_hwmod_ocp_if omap54xx_mpu__l4_abe = {
+	.master		= &omap54xx_mpu_hwmod,
+	.slave		= &omap54xx_l4_abe_hwmod,
+	.clk		= "abe_iclk",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l3_main_1 -> l4_cfg */
+static struct omap_hwmod_ocp_if omap54xx_l3_main_1__l4_cfg = {
+	.master		= &omap54xx_l3_main_1_hwmod,
+	.slave		= &omap54xx_l4_cfg_hwmod,
+	.clk		= "l4_root_clk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l3_main_2 -> l4_per */
+static struct omap_hwmod_ocp_if omap54xx_l3_main_2__l4_per = {
+	.master		= &omap54xx_l3_main_2_hwmod,
+	.slave		= &omap54xx_l4_per_hwmod,
+	.clk		= "l4_root_clk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l3_main_1 -> l4_wkup */
+static struct omap_hwmod_ocp_if omap54xx_l3_main_1__l4_wkup = {
+	.master		= &omap54xx_l3_main_1_hwmod,
+	.slave		= &omap54xx_l4_wkup_hwmod,
+	.clk		= "wkupaon_iclk_mux",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* mpu -> mpu_private */
+static struct omap_hwmod_ocp_if omap54xx_mpu__mpu_private = {
+	.master		= &omap54xx_mpu_hwmod,
+	.slave		= &omap54xx_mpu_private_hwmod,
+	.clk		= "l3_iclk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_wkup -> counter_32k */
+static struct omap_hwmod_ocp_if omap54xx_l4_wkup__counter_32k = {
+	.master		= &omap54xx_l4_wkup_hwmod,
+	.slave		= &omap54xx_counter_32k_hwmod,
+	.clk		= "wkupaon_iclk_mux",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_addr_space omap54xx_dma_system_addrs[] = {
+	{
+		.pa_start	= 0x4a056000,
+		.pa_end		= 0x4a056fff,
+		.flags		= ADDR_TYPE_RT
+	},
+	{ }
+};
+
+/* l4_cfg -> dma_system */
+static struct omap_hwmod_ocp_if omap54xx_l4_cfg__dma_system = {
+	.master		= &omap54xx_l4_cfg_hwmod,
+	.slave		= &omap54xx_dma_system_hwmod,
+	.clk		= "l4_root_clk_div",
+	.addr		= omap54xx_dma_system_addrs,
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_abe -> dmic */
+static struct omap_hwmod_ocp_if omap54xx_l4_abe__dmic = {
+	.master		= &omap54xx_l4_abe_hwmod,
+	.slave		= &omap54xx_dmic_hwmod,
+	.clk		= "abe_iclk",
+	.user		= OCP_USER_MPU,
+};
+
+/* mpu -> emif1 */
+static struct omap_hwmod_ocp_if omap54xx_mpu__emif1 = {
+	.master		= &omap54xx_mpu_hwmod,
+	.slave		= &omap54xx_emif1_hwmod,
+	.clk		= "dpll_core_h11x2_ck",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* mpu -> emif2 */
+static struct omap_hwmod_ocp_if omap54xx_mpu__emif2 = {
+	.master		= &omap54xx_mpu_hwmod,
+	.slave		= &omap54xx_emif2_hwmod,
+	.clk		= "dpll_core_h11x2_ck",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_wkup -> gpio1 */
+static struct omap_hwmod_ocp_if omap54xx_l4_wkup__gpio1 = {
+	.master		= &omap54xx_l4_wkup_hwmod,
+	.slave		= &omap54xx_gpio1_hwmod,
+	.clk		= "wkupaon_iclk_mux",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per -> gpio2 */
+static struct omap_hwmod_ocp_if omap54xx_l4_per__gpio2 = {
+	.master		= &omap54xx_l4_per_hwmod,
+	.slave		= &omap54xx_gpio2_hwmod,
+	.clk		= "l4_root_clk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per -> gpio3 */
+static struct omap_hwmod_ocp_if omap54xx_l4_per__gpio3 = {
+	.master		= &omap54xx_l4_per_hwmod,
+	.slave		= &omap54xx_gpio3_hwmod,
+	.clk		= "l4_root_clk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per -> gpio4 */
+static struct omap_hwmod_ocp_if omap54xx_l4_per__gpio4 = {
+	.master		= &omap54xx_l4_per_hwmod,
+	.slave		= &omap54xx_gpio4_hwmod,
+	.clk		= "l4_root_clk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per -> gpio5 */
+static struct omap_hwmod_ocp_if omap54xx_l4_per__gpio5 = {
+	.master		= &omap54xx_l4_per_hwmod,
+	.slave		= &omap54xx_gpio5_hwmod,
+	.clk		= "l4_root_clk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per -> gpio6 */
+static struct omap_hwmod_ocp_if omap54xx_l4_per__gpio6 = {
+	.master		= &omap54xx_l4_per_hwmod,
+	.slave		= &omap54xx_gpio6_hwmod,
+	.clk		= "l4_root_clk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per -> gpio7 */
+static struct omap_hwmod_ocp_if omap54xx_l4_per__gpio7 = {
+	.master		= &omap54xx_l4_per_hwmod,
+	.slave		= &omap54xx_gpio7_hwmod,
+	.clk		= "l4_root_clk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per -> gpio8 */
+static struct omap_hwmod_ocp_if omap54xx_l4_per__gpio8 = {
+	.master		= &omap54xx_l4_per_hwmod,
+	.slave		= &omap54xx_gpio8_hwmod,
+	.clk		= "l4_root_clk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per -> i2c1 */
+static struct omap_hwmod_ocp_if omap54xx_l4_per__i2c1 = {
+	.master		= &omap54xx_l4_per_hwmod,
+	.slave		= &omap54xx_i2c1_hwmod,
+	.clk		= "l4_root_clk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per -> i2c2 */
+static struct omap_hwmod_ocp_if omap54xx_l4_per__i2c2 = {
+	.master		= &omap54xx_l4_per_hwmod,
+	.slave		= &omap54xx_i2c2_hwmod,
+	.clk		= "l4_root_clk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per -> i2c3 */
+static struct omap_hwmod_ocp_if omap54xx_l4_per__i2c3 = {
+	.master		= &omap54xx_l4_per_hwmod,
+	.slave		= &omap54xx_i2c3_hwmod,
+	.clk		= "l4_root_clk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per -> i2c4 */
+static struct omap_hwmod_ocp_if omap54xx_l4_per__i2c4 = {
+	.master		= &omap54xx_l4_per_hwmod,
+	.slave		= &omap54xx_i2c4_hwmod,
+	.clk		= "l4_root_clk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per -> i2c5 */
+static struct omap_hwmod_ocp_if omap54xx_l4_per__i2c5 = {
+	.master		= &omap54xx_l4_per_hwmod,
+	.slave		= &omap54xx_i2c5_hwmod,
+	.clk		= "l4_root_clk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_wkup -> kbd */
+static struct omap_hwmod_ocp_if omap54xx_l4_wkup__kbd = {
+	.master		= &omap54xx_l4_wkup_hwmod,
+	.slave		= &omap54xx_kbd_hwmod,
+	.clk		= "wkupaon_iclk_mux",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_abe -> mcbsp1 */
+static struct omap_hwmod_ocp_if omap54xx_l4_abe__mcbsp1 = {
+	.master		= &omap54xx_l4_abe_hwmod,
+	.slave		= &omap54xx_mcbsp1_hwmod,
+	.clk		= "abe_iclk",
+	.user		= OCP_USER_MPU,
+};
+
+/* l4_abe -> mcbsp2 */
+static struct omap_hwmod_ocp_if omap54xx_l4_abe__mcbsp2 = {
+	.master		= &omap54xx_l4_abe_hwmod,
+	.slave		= &omap54xx_mcbsp2_hwmod,
+	.clk		= "abe_iclk",
+	.user		= OCP_USER_MPU,
+};
+
+/* l4_abe -> mcbsp3 */
+static struct omap_hwmod_ocp_if omap54xx_l4_abe__mcbsp3 = {
+	.master		= &omap54xx_l4_abe_hwmod,
+	.slave		= &omap54xx_mcbsp3_hwmod,
+	.clk		= "abe_iclk",
+	.user		= OCP_USER_MPU,
+};
+
+/* l4_abe -> mcpdm */
+static struct omap_hwmod_ocp_if omap54xx_l4_abe__mcpdm = {
+	.master		= &omap54xx_l4_abe_hwmod,
+	.slave		= &omap54xx_mcpdm_hwmod,
+	.clk		= "abe_iclk",
+	.user		= OCP_USER_MPU,
+};
+
+/* l4_per -> mcspi1 */
+static struct omap_hwmod_ocp_if omap54xx_l4_per__mcspi1 = {
+	.master		= &omap54xx_l4_per_hwmod,
+	.slave		= &omap54xx_mcspi1_hwmod,
+	.clk		= "l4_root_clk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per -> mcspi2 */
+static struct omap_hwmod_ocp_if omap54xx_l4_per__mcspi2 = {
+	.master		= &omap54xx_l4_per_hwmod,
+	.slave		= &omap54xx_mcspi2_hwmod,
+	.clk		= "l4_root_clk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per -> mcspi3 */
+static struct omap_hwmod_ocp_if omap54xx_l4_per__mcspi3 = {
+	.master		= &omap54xx_l4_per_hwmod,
+	.slave		= &omap54xx_mcspi3_hwmod,
+	.clk		= "l4_root_clk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per -> mcspi4 */
+static struct omap_hwmod_ocp_if omap54xx_l4_per__mcspi4 = {
+	.master		= &omap54xx_l4_per_hwmod,
+	.slave		= &omap54xx_mcspi4_hwmod,
+	.clk		= "l4_root_clk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per -> mmc1 */
+static struct omap_hwmod_ocp_if omap54xx_l4_per__mmc1 = {
+	.master		= &omap54xx_l4_per_hwmod,
+	.slave		= &omap54xx_mmc1_hwmod,
+	.clk		= "l3_iclk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per -> mmc2 */
+static struct omap_hwmod_ocp_if omap54xx_l4_per__mmc2 = {
+	.master		= &omap54xx_l4_per_hwmod,
+	.slave		= &omap54xx_mmc2_hwmod,
+	.clk		= "l3_iclk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per -> mmc3 */
+static struct omap_hwmod_ocp_if omap54xx_l4_per__mmc3 = {
+	.master		= &omap54xx_l4_per_hwmod,
+	.slave		= &omap54xx_mmc3_hwmod,
+	.clk		= "l4_root_clk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per -> mmc4 */
+static struct omap_hwmod_ocp_if omap54xx_l4_per__mmc4 = {
+	.master		= &omap54xx_l4_per_hwmod,
+	.slave		= &omap54xx_mmc4_hwmod,
+	.clk		= "l4_root_clk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per -> mmc5 */
+static struct omap_hwmod_ocp_if omap54xx_l4_per__mmc5 = {
+	.master		= &omap54xx_l4_per_hwmod,
+	.slave		= &omap54xx_mmc5_hwmod,
+	.clk		= "l4_root_clk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_cfg -> mpu */
+static struct omap_hwmod_ocp_if omap54xx_l4_cfg__mpu = {
+	.master		= &omap54xx_l4_cfg_hwmod,
+	.slave		= &omap54xx_mpu_hwmod,
+	.clk		= "l4_root_clk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_wkup -> timer1 */
+static struct omap_hwmod_ocp_if omap54xx_l4_wkup__timer1 = {
+	.master		= &omap54xx_l4_wkup_hwmod,
+	.slave		= &omap54xx_timer1_hwmod,
+	.clk		= "wkupaon_iclk_mux",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per -> timer2 */
+static struct omap_hwmod_ocp_if omap54xx_l4_per__timer2 = {
+	.master		= &omap54xx_l4_per_hwmod,
+	.slave		= &omap54xx_timer2_hwmod,
+	.clk		= "l4_root_clk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per -> timer3 */
+static struct omap_hwmod_ocp_if omap54xx_l4_per__timer3 = {
+	.master		= &omap54xx_l4_per_hwmod,
+	.slave		= &omap54xx_timer3_hwmod,
+	.clk		= "l4_root_clk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per -> timer4 */
+static struct omap_hwmod_ocp_if omap54xx_l4_per__timer4 = {
+	.master		= &omap54xx_l4_per_hwmod,
+	.slave		= &omap54xx_timer4_hwmod,
+	.clk		= "l4_root_clk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_abe -> timer5 */
+static struct omap_hwmod_ocp_if omap54xx_l4_abe__timer5 = {
+	.master		= &omap54xx_l4_abe_hwmod,
+	.slave		= &omap54xx_timer5_hwmod,
+	.clk		= "abe_iclk",
+	.user		= OCP_USER_MPU,
+};
+
+/* l4_abe -> timer6 */
+static struct omap_hwmod_ocp_if omap54xx_l4_abe__timer6 = {
+	.master		= &omap54xx_l4_abe_hwmod,
+	.slave		= &omap54xx_timer6_hwmod,
+	.clk		= "abe_iclk",
+	.user		= OCP_USER_MPU,
+};
+
+/* l4_abe -> timer7 */
+static struct omap_hwmod_ocp_if omap54xx_l4_abe__timer7 = {
+	.master		= &omap54xx_l4_abe_hwmod,
+	.slave		= &omap54xx_timer7_hwmod,
+	.clk		= "abe_iclk",
+	.user		= OCP_USER_MPU,
+};
+
+/* l4_abe -> timer8 */
+static struct omap_hwmod_ocp_if omap54xx_l4_abe__timer8 = {
+	.master		= &omap54xx_l4_abe_hwmod,
+	.slave		= &omap54xx_timer8_hwmod,
+	.clk		= "abe_iclk",
+	.user		= OCP_USER_MPU,
+};
+
+/* l4_per -> timer9 */
+static struct omap_hwmod_ocp_if omap54xx_l4_per__timer9 = {
+	.master		= &omap54xx_l4_per_hwmod,
+	.slave		= &omap54xx_timer9_hwmod,
+	.clk		= "l4_root_clk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per -> timer10 */
+static struct omap_hwmod_ocp_if omap54xx_l4_per__timer10 = {
+	.master		= &omap54xx_l4_per_hwmod,
+	.slave		= &omap54xx_timer10_hwmod,
+	.clk		= "l4_root_clk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per -> timer11 */
+static struct omap_hwmod_ocp_if omap54xx_l4_per__timer11 = {
+	.master		= &omap54xx_l4_per_hwmod,
+	.slave		= &omap54xx_timer11_hwmod,
+	.clk		= "l4_root_clk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per -> uart1 */
+static struct omap_hwmod_ocp_if omap54xx_l4_per__uart1 = {
+	.master		= &omap54xx_l4_per_hwmod,
+	.slave		= &omap54xx_uart1_hwmod,
+	.clk		= "l4_root_clk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per -> uart2 */
+static struct omap_hwmod_ocp_if omap54xx_l4_per__uart2 = {
+	.master		= &omap54xx_l4_per_hwmod,
+	.slave		= &omap54xx_uart2_hwmod,
+	.clk		= "l4_root_clk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per -> uart3 */
+static struct omap_hwmod_ocp_if omap54xx_l4_per__uart3 = {
+	.master		= &omap54xx_l4_per_hwmod,
+	.slave		= &omap54xx_uart3_hwmod,
+	.clk		= "l4_root_clk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per -> uart4 */
+static struct omap_hwmod_ocp_if omap54xx_l4_per__uart4 = {
+	.master		= &omap54xx_l4_per_hwmod,
+	.slave		= &omap54xx_uart4_hwmod,
+	.clk		= "l4_root_clk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per -> uart5 */
+static struct omap_hwmod_ocp_if omap54xx_l4_per__uart5 = {
+	.master		= &omap54xx_l4_per_hwmod,
+	.slave		= &omap54xx_uart5_hwmod,
+	.clk		= "l4_root_clk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per -> uart6 */
+static struct omap_hwmod_ocp_if omap54xx_l4_per__uart6 = {
+	.master		= &omap54xx_l4_per_hwmod,
+	.slave		= &omap54xx_uart6_hwmod,
+	.clk		= "l4_root_clk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_cfg -> usb_otg_ss */
+static struct omap_hwmod_ocp_if omap54xx_l4_cfg__usb_otg_ss = {
+	.master		= &omap54xx_l4_cfg_hwmod,
+	.slave		= &omap54xx_usb_otg_ss_hwmod,
+	.clk		= "dpll_core_h13x2_ck",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_wkup -> wd_timer2 */
+static struct omap_hwmod_ocp_if omap54xx_l4_wkup__wd_timer2 = {
+	.master		= &omap54xx_l4_wkup_hwmod,
+	.slave		= &omap54xx_wd_timer2_hwmod,
+	.clk		= "wkupaon_iclk_mux",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_ocp_if *omap54xx_hwmod_ocp_ifs[] __initdata = {
+	&omap54xx_l3_main_1__dmm,
+	&omap54xx_l3_main_3__l3_instr,
+	&omap54xx_l3_main_2__l3_main_1,
+	&omap54xx_l4_cfg__l3_main_1,
+	&omap54xx_mpu__l3_main_1,
+	&omap54xx_l3_main_1__l3_main_2,
+	&omap54xx_l4_cfg__l3_main_2,
+	&omap54xx_l3_main_1__l3_main_3,
+	&omap54xx_l3_main_2__l3_main_3,
+	&omap54xx_l4_cfg__l3_main_3,
+	&omap54xx_l3_main_1__l4_abe,
+	&omap54xx_mpu__l4_abe,
+	&omap54xx_l3_main_1__l4_cfg,
+	&omap54xx_l3_main_2__l4_per,
+	&omap54xx_l3_main_1__l4_wkup,
+	&omap54xx_mpu__mpu_private,
+	&omap54xx_l4_wkup__counter_32k,
+	&omap54xx_l4_cfg__dma_system,
+	&omap54xx_l4_abe__dmic,
+	&omap54xx_mpu__emif1,
+	&omap54xx_mpu__emif2,
+	&omap54xx_l4_wkup__gpio1,
+	&omap54xx_l4_per__gpio2,
+	&omap54xx_l4_per__gpio3,
+	&omap54xx_l4_per__gpio4,
+	&omap54xx_l4_per__gpio5,
+	&omap54xx_l4_per__gpio6,
+	&omap54xx_l4_per__gpio7,
+	&omap54xx_l4_per__gpio8,
+	&omap54xx_l4_per__i2c1,
+	&omap54xx_l4_per__i2c2,
+	&omap54xx_l4_per__i2c3,
+	&omap54xx_l4_per__i2c4,
+	&omap54xx_l4_per__i2c5,
+	&omap54xx_l4_wkup__kbd,
+	&omap54xx_l4_abe__mcbsp1,
+	&omap54xx_l4_abe__mcbsp2,
+	&omap54xx_l4_abe__mcbsp3,
+	&omap54xx_l4_abe__mcpdm,
+	&omap54xx_l4_per__mcspi1,
+	&omap54xx_l4_per__mcspi2,
+	&omap54xx_l4_per__mcspi3,
+	&omap54xx_l4_per__mcspi4,
+	&omap54xx_l4_per__mmc1,
+	&omap54xx_l4_per__mmc2,
+	&omap54xx_l4_per__mmc3,
+	&omap54xx_l4_per__mmc4,
+	&omap54xx_l4_per__mmc5,
+	&omap54xx_l4_cfg__mpu,
+	&omap54xx_l4_wkup__timer1,
+	&omap54xx_l4_per__timer2,
+	&omap54xx_l4_per__timer3,
+	&omap54xx_l4_per__timer4,
+	&omap54xx_l4_abe__timer5,
+	&omap54xx_l4_abe__timer6,
+	&omap54xx_l4_abe__timer7,
+	&omap54xx_l4_abe__timer8,
+	&omap54xx_l4_per__timer9,
+	&omap54xx_l4_per__timer10,
+	&omap54xx_l4_per__timer11,
+	&omap54xx_l4_per__uart1,
+	&omap54xx_l4_per__uart2,
+	&omap54xx_l4_per__uart3,
+	&omap54xx_l4_per__uart4,
+	&omap54xx_l4_per__uart5,
+	&omap54xx_l4_per__uart6,
+	&omap54xx_l4_cfg__usb_otg_ss,
+	&omap54xx_l4_wkup__wd_timer2,
+	NULL,
+};
+
+int __init omap54xx_hwmod_init(void)
+{
+	omap_hwmod_init();
+	return omap_hwmod_register_links(omap54xx_hwmod_ocp_ifs);
+}
-- 
1.7.9.5



From laurent.pinchart at ideasonboard.com  Thu Apr  4 06:24:15 2013
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Thu, 04 Apr 2013 12:24:15 +0200
Subject: [PATCH 00/04] ARM: shmobile: pinmux platform device cleanups
In-Reply-To: <20130403063246.2500.65318.sendpatchset@w520>
References: <20130403063246.2500.65318.sendpatchset@w520>
Message-ID: <11100532.ubSdK9L5P1@avalon>

Hi Magnus,

Thanks for the patches.

On Wednesday 03 April 2013 15:32:46 Magnus Damm wrote:
> ARM: shmobile: pinmux platform device cleanups
> 
> [PATCH 01/04] ARM: shmobile: r8a7740 pinmux platform device cleanup
> [PATCH 02/04] ARM: shmobile: r8a7779 pinmux platform device cleanup
> [PATCH 03/04] ARM: shmobile: sh7372 pinmux platform device cleanup
> [PATCH 04/04] ARM: shmobile: sh73a0 pinmux platform device cleanup
> 
> This series simply cleans up the pinmux platform device handling
> to save a couple of lines. Compile time tested on each SoC.
> 
> Signed-off-by: Magnus Damm <damm at opensource.se>

Except for 2/4,

Acked-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>

> ---
> 
>  Written against renesas-next-20130403 in renesas.git
> 
>  arch/arm/mach-shmobile/setup-r8a7740.c |   24 +++++-------------------
>  arch/arm/mach-shmobile/setup-r8a7779.c |   19 ++++---------------
>  arch/arm/mach-shmobile/setup-sh7372.c  |   24 +++++-------------------
>  arch/arm/mach-shmobile/setup-sh73a0.c  |   25 ++++++-------------------
>  4 files changed, 20 insertions(+), 72 deletions(-)

-- 
Regards,

Laurent Pinchart



From florian at openwrt.org  Thu Apr  4 06:27:12 2013
From: florian at openwrt.org (Florian Fainelli)
Date: Thu,  4 Apr 2013 12:27:12 +0200
Subject: [PATCH 2/5] mv643xx_eth: update Device Tree bindings documentation
In-Reply-To: <1365071235-11611-1-git-send-email-florian@openwrt.org>
References: <1365071235-11611-1-git-send-email-florian@openwrt.org>
Message-ID: <1365071235-11611-3-git-send-email-florian@openwrt.org>

This patch updates the Device Tree bindings documentation for the
Marvell MV643xx ethernet controller node and makes the
"local-mac-address" and "phy" properties optional instead of required.
The absence of a "phy" node is legal and describes a MAC to switch
configuration, while not specifying the "local-mac-address" allows for
reuse of the MAC address already programmed into the Ethernet
controller.

Signed-off-by: Florian Fainelli <florian at openwrt.org>
---
 Documentation/devicetree/bindings/marvell.txt |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/marvell.txt b/Documentation/devicetree/bindings/marvell.txt
index e70a013..994b933 100644
--- a/Documentation/devicetree/bindings/marvell.txt
+++ b/Documentation/devicetree/bindings/marvell.txt
@@ -141,11 +141,11 @@ prefixed with the string "marvell,", for Marvell Technology Group Ltd.
      - interrupts : <a> where a is the interrupt number for the port.
      - interrupt-parent : the phandle for the interrupt controller
        that services interrupts for this device.
+
+   Optional properties:
      - phy : the phandle for the PHY connected to this ethernet
        controller.
      - local-mac-address : 6 bytes, MAC address
-
-   Optional properties:
      - clocks : Phandle to the clock control device and gate bit
      - clock-names : String describing the clock gate bit
      - speed : Speed to force the link (10, 100, 1000), used when no
-- 
1.7.10.4



From florian at openwrt.org  Thu Apr  4 06:27:13 2013
From: florian at openwrt.org (Florian Fainelli)
Date: Thu,  4 Apr 2013 12:27:13 +0200
Subject: [PATCH 3/5 v2] ARM: kirkwood: add device node entries for the gigabit
 interfaces
In-Reply-To: <1365071235-11611-1-git-send-email-florian@openwrt.org>
References: <1365071235-11611-1-git-send-email-florian@openwrt.org>
Message-ID: <1365071235-11611-4-git-send-email-florian@openwrt.org>

This patch modifies kirkwood.dtsi to specify the various gigabit
interfaces nodes available on kirkwood devices. They are disabled by
default and should be enabled on a per-board basis. egiga0 and egiga1
aliases are defined for convenience. The mdio node is also present and
should be enabled on a per-board basis as well.

Signed-off-by: Florian Fainelli <florian at openwrt.org>
---
Changes since v1:
- dropped change to arch/arm/mach-kirkwood/common.c to avoid merge conflicts
- fixed off-by 0x2000 ethernet-group nodes address

 arch/arm/boot/dts/kirkwood.dtsi |   46 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 46 insertions(+)

diff --git a/arch/arm/boot/dts/kirkwood.dtsi b/arch/arm/boot/dts/kirkwood.dtsi
index fada7e6..254f5a8 100644
--- a/arch/arm/boot/dts/kirkwood.dtsi
+++ b/arch/arm/boot/dts/kirkwood.dtsi
@@ -7,6 +7,8 @@
 	aliases {
 	       gpio0 = &gpio0;
 	       gpio1 = &gpio1;
+	       egiga0 = &egiga0;
+	       egiga1 = &egiga1;
 	};
 	intc: interrupt-controller {
 		compatible = "marvell,orion-intc", "marvell,intc";
@@ -202,5 +204,49 @@
 			clocks = <&gate_clk 4>;
 			status = "disabled";
 		};
+
+		mdio at 72004 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			compatible = "marvell,orion-mdio";
+			reg = <0x72004 0x84>;
+			status = "disabled";
+		};
+
+		ethernet-group at 72000 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			compatible = "marvell,mv643xx-eth-block";
+			reg = <0x72000 0x4000>;
+			tx-csum-limit = <1600>;
+			status = "disabled";
+
+			egiga0: egiga0 at 0 {
+				device_type = "network";
+				compatible = "marvell,mv643xx-eth";
+				reg = <0>;
+				interrupts = <11>;
+				clocks = <&gate_clk 0>;
+				clock-names = "0";
+			};
+		};
+
+		ethernet-group at 76000 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			compatible = "marvell,mv643xx-eth-block";
+			reg = <0x76000 0x4000>;
+			tx-csum-limit = <1600>;
+			status = "disabled";
+
+			egiga1: egiga1 at 0 {
+				device_type = "network";
+				compatible = "marvell,mv643xx-eth";
+				reg = <0>;
+				interrupts = <15>;
+				clocks = <&gate_clk 19>;
+				clock-names = "1";
+			};
+		};
 	};
 };
-- 
1.7.10.4



From florian at openwrt.org  Thu Apr  4 06:27:10 2013
From: florian at openwrt.org (Florian Fainelli)
Date: Thu,  4 Apr 2013 12:27:10 +0200
Subject: [PATCH 0/5 v2] mv643xx_eth: device tree bindings
Message-ID: <1365071235-11611-1-git-send-email-florian@openwrt.org>

Hi all,

This patch serie implements mv643xx_eth device tree bindings. I opted for
the reuse of the bindings already defined in
Documentation/devicetree/bindings/marvell.txt so that we do not create
any confusion.

For reference, I have included the mv643xx-eth related nodes in the
corresponding Kirkwood, Dove and Orion5x .dtsi files so you can more
easily test on your own platforms.

I tested these on a custom 88F6181-based boards.

Florian Fainelli (5):
  mv643xx_eth: add Device Tree bindings
  mv643xx_eth: update Device Tree bindings documentation
  ARM: kirkwood: add device node entries for the gigabit interfaces
  ARM: orion5x: add gigabit ethernet device tree node
  ARM: dove: add gigabit device tree nodes to dove.dtsi

 Documentation/devicetree/bindings/marvell.txt |   25 +++++-
 arch/arm/boot/dts/dove.dtsi                   |   25 ++++++
 arch/arm/boot/dts/kirkwood.dtsi               |   46 ++++++++++
 arch/arm/boot/dts/orion5x.dtsi                |   23 +++++
 drivers/net/ethernet/marvell/mv643xx_eth.c    |  120 ++++++++++++++++++++++++-
 5 files changed, 234 insertions(+), 5 deletions(-)

-- 
1.7.10.4



From florian at openwrt.org  Thu Apr  4 06:27:14 2013
From: florian at openwrt.org (Florian Fainelli)
Date: Thu,  4 Apr 2013 12:27:14 +0200
Subject: [PATCH 4/5 v2] ARM: orion5x: add gigabit ethernet device tree node
In-Reply-To: <1365071235-11611-1-git-send-email-florian@openwrt.org>
References: <1365071235-11611-1-git-send-email-florian@openwrt.org>
Message-ID: <1365071235-11611-5-git-send-email-florian@openwrt.org>

This patch adds the gigabit ethernet device tree node to orion5x.dtsi.
This node is disabled by default and must be enabled on a per-board
basis. For completeness and easier testing the MDIO node is also added
and disabled by default.

Signed-off-by: Florian Fainelli <florian at openwrt.org>
---
Changes since v1:
- fixed off-by 0x2000 address of the ethernet-group node

 arch/arm/boot/dts/orion5x.dtsi |   23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/arch/arm/boot/dts/orion5x.dtsi b/arch/arm/boot/dts/orion5x.dtsi
index f7bec3b..c49503e 100644
--- a/arch/arm/boot/dts/orion5x.dtsi
+++ b/arch/arm/boot/dts/orion5x.dtsi
@@ -99,5 +99,28 @@
 			interrupts = <28>;
 			status = "okay";
 		};
+
+		mdio at 72004 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			compatible = "marvell,orion-mdio";
+			reg = <0x72004 0x84>;
+			status = "disabled";
+		};
+
+		ethernet-group at 72000 {
+			#address-cells = <1>.
+			#size-cells = <0>;
+			compatible = "marvell,mv643xx-eth-block";
+			reg = <0x72000 0x4000>;
+			status = "disabled";
+
+			egiga0: ethernet at 0 {
+				device_type = "network";
+				compatible = "marvell,mv643xx-eth";
+				reg = <0>;
+				interrupts = <21>;
+			};
+		};
 	};
 };
-- 
1.7.10.4



From florian at openwrt.org  Thu Apr  4 06:27:15 2013
From: florian at openwrt.org (Florian Fainelli)
Date: Thu,  4 Apr 2013 12:27:15 +0200
Subject: [PATCH 5/5 v2] ARM: dove: add gigabit device tree nodes to dove.dtsi
In-Reply-To: <1365071235-11611-1-git-send-email-florian@openwrt.org>
References: <1365071235-11611-1-git-send-email-florian@openwrt.org>
Message-ID: <1365071235-11611-6-git-send-email-florian@openwrt.org>

This patch adds the gigabit ethernet device tree nodes to dove.dtsi in a
disabled state. The gigabit ethernet device tree node must be enabled on
a per-board basis. For completeness and easier testing the MDIO node is
also added in a disabled state.

Signed-off-by: Florian Fainelli <florian at openwrt.org>
---
Changes since v1:
- fixed off-by 0x2000 address of the ethernet-group node

 arch/arm/boot/dts/dove.dtsi |   25 +++++++++++++++++++++++++
 1 file changed, 25 insertions(+)

diff --git a/arch/arm/boot/dts/dove.dtsi b/arch/arm/boot/dts/dove.dtsi
index f7509ca..51de5f7 100644
--- a/arch/arm/boot/dts/dove.dtsi
+++ b/arch/arm/boot/dts/dove.dtsi
@@ -253,5 +253,30 @@
 				dmacap,xor;
 			};
 		};
+
+		mdio at 72004 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			compatible = "marvell,orion-mdio";
+			reg = <0x72004 0x84>;
+			status = "disabled";
+		};
+
+		ethernet-group at 72000 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			compatible = "marvell,mv643xx-eth-block";
+			reg = <0x72000 0x4000>;
+			tx-csum-limit = <1600>;
+			status = "disabled";
+
+			egiga0: ethernet at 0 {
+				device_type = "network";
+				compatible = "marvell,mv643xx-eth";
+				reg = <0>;
+				interrupts = <29>;
+				clocks = <&gate_clk 2>;
+			};
+		};
 	};
 };
-- 
1.7.10.4



From florian at openwrt.org  Thu Apr  4 06:27:11 2013
From: florian at openwrt.org (Florian Fainelli)
Date: Thu,  4 Apr 2013 12:27:11 +0200
Subject: [PATCH 1/5 v2] mv643xx_eth: add Device Tree bindings
In-Reply-To: <1365071235-11611-1-git-send-email-florian@openwrt.org>
References: <1365071235-11611-1-git-send-email-florian@openwrt.org>
Message-ID: <1365071235-11611-2-git-send-email-florian@openwrt.org>

This patch adds Device Tree bindings following the already defined
bindings at Documentation/devicetree/bindings/marvell.txt. The binding
documentation is also enhanced with new optionnal properties required
for supporting certain devices (RX/TX queue and SRAM). Since we now have
proper support for the orion MDIO bus driver, there is no need to fiddle
around with device tree phandles. PHY-less (MAC connected to switch)
configurations are supported by not specifying any phy phandle for an
ethernet node.

Signed-off-by: Florian Fainelli <florian at openwrt.org>
---
- properly ifdef of_platform_bus_probe with CONFIG_OF
- handle of_platform_bus_probe errors and cleanup accordingly
- use of_property_read_u32 where applicable
- parse "duplex" and "speed" property in PHY-less configuration

 Documentation/devicetree/bindings/marvell.txt |   25 +++++-
 drivers/net/ethernet/marvell/mv643xx_eth.c    |  120 ++++++++++++++++++++++++-
 2 files changed, 140 insertions(+), 5 deletions(-)

diff --git a/Documentation/devicetree/bindings/marvell.txt b/Documentation/devicetree/bindings/marvell.txt
index f1533d9..e70a013 100644
--- a/Documentation/devicetree/bindings/marvell.txt
+++ b/Documentation/devicetree/bindings/marvell.txt
@@ -112,9 +112,14 @@ prefixed with the string "marvell,", for Marvell Technology Group Ltd.
    Required properties:
      - #address-cells : <1>
      - #size-cells : <0>
-     - compatible : "marvell,mv64360-eth-block"
+     - compatible : "marvell,mv64360-eth-block", "marvell,mv64360-eth-group",
+		    "marvell,mv643xx-eth-block"
      - reg : Offset and length of the register set for this block
 
+   Optional properties:
+     - tx-csum-limit : Hardware limit above which transmit checksumming
+                       is disabled.
+
    Example Discovery Ethernet block node:
      ethernet-block at 2000 {
 	     #address-cells = <1>;
@@ -130,7 +135,7 @@ prefixed with the string "marvell,", for Marvell Technology Group Ltd.
 
    Required properties:
      - device_type : Should be "network".
-     - compatible : Should be "marvell,mv64360-eth".
+     - compatible : Should be "marvell,mv64360-eth", "marvell,mv643xx-eth".
      - reg : Should be <0>, <1>, or <2>, according to which registers
        within the silicon block the device uses.
      - interrupts : <a> where a is the interrupt number for the port.
@@ -140,6 +145,22 @@ prefixed with the string "marvell,", for Marvell Technology Group Ltd.
        controller.
      - local-mac-address : 6 bytes, MAC address
 
+   Optional properties:
+     - clocks : Phandle to the clock control device and gate bit
+     - clock-names : String describing the clock gate bit
+     - speed : Speed to force the link (10, 100, 1000), used when no
+               phy property is defined
+     - duplex : Duplex to force the link (0: half, 1: full), used when no
+               phy property is defined
+     - rx-queue-count : number of RX queues to use
+     - tx-queue-count : number of TX queues to use
+     - rx-queue-size : size of the RX queue (in bytes)
+     - tx-queue-size : size of the TX queue (in bytes)
+     - rx-sram-addr : address of the SRAM for RX path (non 0 means used)
+     - rx-sram-size : size of the SRAM for RX path (non 0 means used)
+     - tx-sram-addr : address of the SRAM for TX path (non 0 means used)
+     - tx-sram-size : size of the SRAM for TX path (non 0 means used)
+
    Example Discovery Ethernet port node:
      ethernet at 0 {
 	     device_type = "network";
diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c b/drivers/net/ethernet/marvell/mv643xx_eth.c
index aedbd82..75599a8 100644
--- a/drivers/net/ethernet/marvell/mv643xx_eth.c
+++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
@@ -60,6 +60,10 @@
 #include <linux/inet_lro.h>
 #include <linux/slab.h>
 #include <linux/clk.h>
+#include <linux/stringify.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
+#include <linux/of_net.h>
 
 static char mv643xx_eth_driver_name[] = "mv643xx_eth";
 static char mv643xx_eth_driver_version[] = "1.4";
@@ -2542,14 +2546,23 @@ static void infer_hw_params(struct mv643xx_eth_shared_private *msp)
 	}
 }
 
+static const struct of_device_id mv643xx_eth_match[] = {
+	{ .compatible = "marvell,mv64360-eth" },
+	{ .compatible = "marvell,mv643xx-eth" },
+	{ /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, mv643xx_eth_match);
+
 static int mv643xx_eth_shared_probe(struct platform_device *pdev)
 {
 	static int mv643xx_eth_version_printed;
+	struct device_node *np = pdev->dev.of_node;
 	struct mv643xx_eth_shared_platform_data *pd = pdev->dev.platform_data;
 	struct mv643xx_eth_shared_private *msp;
 	const struct mbus_dram_target_info *dram;
 	struct resource *res;
 	int ret;
+	int tx_csum_limit = 0;
 
 	if (!mv643xx_eth_version_printed++)
 		pr_notice("MV-643xx 10/100/1000 ethernet driver version %s\n",
@@ -2576,13 +2589,23 @@ static int mv643xx_eth_shared_probe(struct platform_device *pdev)
 	if (dram)
 		mv643xx_eth_conf_mbus_windows(msp, dram);
 
-	msp->tx_csum_limit = (pd != NULL && pd->tx_csum_limit) ?
-					pd->tx_csum_limit : 9 * 1024;
+	if (np)
+		of_property_read_u32(np, "tx-csum-limit", &tx_csum_limit);
+	else
+		tx_csum_limit = pd->tx_csum_limit;
+
+	msp->tx_csum_limit = tx_csum_limit ? tx_csum_limit : 9 * 1024;
 	infer_hw_params(msp);
 
 	platform_set_drvdata(pdev, msp);
+	ret = 0;
 
-	return 0;
+#ifdef CONFIG_OF
+	ret = of_platform_bus_probe(np, mv643xx_eth_match, &pdev->dev);
+	if (ret)
+		goto out_free;
+#endif
+	return ret;
 
 out_free:
 	kfree(msp);
@@ -2600,12 +2623,22 @@ static int mv643xx_eth_shared_remove(struct platform_device *pdev)
 	return 0;
 }
 
+static const struct of_device_id mv643xx_eth_shared_match[] = {
+	{ .compatible = "marvell,mv64360-eth-group" },
+	{ .compatible = "marvell,mv64360-eth-block" },
+	{ .compatible = "marvell,mv643xx-eth-group" },
+	{ .compatible = "marvell,mv643xx-eth-block" },
+	{ /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, mv643xx_eth_shared_match);
+
 static struct platform_driver mv643xx_eth_shared_driver = {
 	.probe		= mv643xx_eth_shared_probe,
 	.remove		= mv643xx_eth_shared_remove,
 	.driver = {
 		.name	= MV643XX_ETH_SHARED_NAME,
 		.owner	= THIS_MODULE,
+		.of_match_table = of_match_ptr(mv643xx_eth_shared_match),
 	},
 };
 
@@ -2764,6 +2797,74 @@ static const struct net_device_ops mv643xx_eth_netdev_ops = {
 #endif
 };
 
+#ifdef CONFIG_OF
+static int mv643xx_eth_of_probe(struct platform_device *pdev)
+{
+	struct mv643xx_eth_platform_data *pd;
+	struct device_node *np = pdev->dev.of_node;
+	struct device_node *shared = of_get_parent(np);
+	struct device_node *phy_node;
+	const int *prop;
+	const char *mac_addr;
+
+	if (!pdev->dev.of_node)
+		return 0;
+
+	pd = kzalloc(sizeof(*pd), GFP_KERNEL);
+	if (!pd)
+		return -ENOMEM;
+
+	pdev->dev.platform_data = pd;
+
+	pd->shared = of_find_device_by_node(shared);
+	if (!pd->shared)
+		return -ENODEV;
+
+	prop = of_get_property(np, "reg", NULL);
+	if (!prop)
+		return -EINVAL;
+
+	pd->port_number = be32_to_cpup(prop);
+
+	phy_node = of_parse_phandle(np, "phy", 0);
+	if (!phy_node) {
+		pd->phy_addr = MV643XX_ETH_PHY_NONE;
+
+		of_property_read_u32(np, "speed", &pd->speed);
+		of_property_read_u32(np, "duplex", &pd->duplex);
+	} else {
+		prop = of_get_property(phy_node, "reg", NULL);
+		if (prop)
+			pd->phy_addr = be32_to_cpup(prop);
+	}
+
+	mac_addr = of_get_mac_address(np);
+	if (mac_addr)
+		memcpy(pd->mac_addr, mac_addr, ETH_ALEN);
+
+#define rx_tx_queue_sram_property(_name)			\
+	prop = of_get_property(np, __stringify(_name), NULL);	\
+	if (prop)						\
+		pd->_name = be32_to_cpup(prop);
+
+	rx_tx_queue_sram_property(rx_queue_count);
+	rx_tx_queue_sram_property(tx_queue_count);
+	rx_tx_queue_sram_property(rx_queue_size);
+	rx_tx_queue_sram_property(tx_queue_size);
+	rx_tx_queue_sram_property(rx_sram_addr);
+	rx_tx_queue_sram_property(rx_sram_size);
+	rx_tx_queue_sram_property(tx_sram_addr);
+	rx_tx_queue_sram_property(rx_sram_size);
+
+	return 0;
+}
+#else
+static inline int mv643xx_eth_of_probe(struct platform_device *dev)
+{
+	return 0;
+}
+#endif
+
 static int mv643xx_eth_probe(struct platform_device *pdev)
 {
 	struct mv643xx_eth_platform_data *pd;
@@ -2772,7 +2873,12 @@ static int mv643xx_eth_probe(struct platform_device *pdev)
 	struct resource *res;
 	int err;
 
+	err = mv643xx_eth_of_probe(pdev);
+	if (err)
+		return err;
+
 	pd = pdev->dev.platform_data;
+
 	if (pd == NULL) {
 		dev_err(&pdev->dev, "no mv643xx_eth_platform_data\n");
 		return -ENODEV;
@@ -2896,6 +3002,8 @@ out:
 	}
 #endif
 	free_netdev(dev);
+	if (pdev->dev.of_node)
+		kfree(pd);
 
 	return err;
 }
@@ -2903,6 +3011,7 @@ out:
 static int mv643xx_eth_remove(struct platform_device *pdev)
 {
 	struct mv643xx_eth_private *mp = platform_get_drvdata(pdev);
+	struct mv643xx_eth_platform_data *pd = pdev->dev.platform_data;
 
 	unregister_netdev(mp->dev);
 	if (mp->phy != NULL)
@@ -2918,6 +3027,9 @@ static int mv643xx_eth_remove(struct platform_device *pdev)
 
 	free_netdev(mp->dev);
 
+	if (pdev->dev.of_node)
+		kfree(pd);
+
 	platform_set_drvdata(pdev, NULL);
 
 	return 0;
@@ -2935,6 +3047,7 @@ static void mv643xx_eth_shutdown(struct platform_device *pdev)
 		port_reset(mp);
 }
 
+
 static struct platform_driver mv643xx_eth_driver = {
 	.probe		= mv643xx_eth_probe,
 	.remove		= mv643xx_eth_remove,
@@ -2942,6 +3055,7 @@ static struct platform_driver mv643xx_eth_driver = {
 	.driver = {
 		.name	= MV643XX_ETH_NAME,
 		.owner	= THIS_MODULE,
+		.of_match_table = of_match_ptr(mv643xx_eth_match),
 	},
 };
 
-- 
1.7.10.4



From josephl at nvidia.com  Thu Apr  4 06:28:17 2013
From: josephl at nvidia.com (Joseph Lo)
Date: Thu, 4 Apr 2013 18:28:17 +0800
Subject: [PATCH] clocksource: tegra: enable arch_timer
In-Reply-To: <515CB1A6.6090308@wwwdotorg.org>
References: <1364988750-25058-1-git-send-email-josephl@nvidia.com>
 <515C2E8F.1030802@gmail.com> <515C7363.4040404@wwwdotorg.org>
 <515CA060.7030100@gmail.com>  <515CB1A6.6090308@wwwdotorg.org>
Message-ID: <1365071297.1602.1.camel@jlo-ubuntu-64.nvidia.com>

On Thu, 2013-04-04 at 06:48 +0800, Stephen Warren wrote:
> On 04/03/2013 03:34 PM, Rob Herring wrote:
> > On 04/03/2013 01:22 PM, Stephen Warren wrote:
> >> On 04/03/2013 07:28 AM, Rob Herring wrote:
> >>> On 04/03/2013 06:32 AM, Joseph Lo wrote:
> >> Rob, if I did apply this change, and you also apply that series of
> >> yours, what is the result: compile-time breakage, run-time breakage,
> >> just some redundant code that needs to be removed again?
> > 
> > Compile-time breakage as the functions called here are being removed.
> 
> OK, I definitely won't apply Joseph's patch then.

Agree. This patch is redundant, once Rob's patches go into mainline.
> 
> Aside from that, I took the git branch you mentioned in the patch you
> linked to above, merged it into my dev tree, updated my bootloader to
> actually initialize the TSC correctly, and I see the following during
> boot, so I guess that's enough for:
> 
> Tested-by: Stephen Warren <swarren at nvidia.com>
> 
> on your patches.
> 
> > [    0.000000] sched_clock: 32 bits at 1000kHz, resolution 1000ns, wraps every 4294967ms
> > [    0.000000] Architected local timer running at 12.00MHz (virt).
> > [    0.000000] Switching to timer-based delay loop
> > [  117.431229] Calibrating delay loop (skipped), value calculated using timer frequency.. 24.00 BogoMIPS (lpj=120000)
> > [  117.987221] Switching to clocksource arch_sys_counter




From santosh.shilimkar at ti.com  Thu Apr  4 06:34:26 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Thu, 4 Apr 2013 16:04:26 +0530
Subject: [GIT PULL] ARM: OMAP5: hwmod, prm/cm data files and updates for
 3.10
In-Reply-To: <alpine.DEB.2.00.1304031953010.16711@utopia.booyaka.com>
References: <1363768852-18125-1-git-send-email-santosh.shilimkar@ti.com>
 <alpine.DEB.2.00.1304031953010.16711@utopia.booyaka.com>
Message-ID: <515D5732.6000705@ti.com>

Paul,

On Thursday 04 April 2013 01:39 AM, Paul Walmsley wrote:
> cc Kevin
> 
> Hi
> 
> On Wed, 20 Mar 2013, Santosh Shilimkar wrote:
> 
>> Benoit Cousson (7):
>>       ARM: OMAP5: PRM: Add OMAP54XX register and bitfield files
> 
> So it looks like this patch never made it to the mailing list.  Was it too 
> big?  If so, please try splitting it into two or more pieces.  Looking at 
> the git branch that you posted for pulling, the patch adds two files, so 
> maybe you can just create one patch for each file?
> 
Size was not an issue mostly. Looks like that entire series got affected
because of the TI mailer issue which was reported by ARM list maintainer.
I lost many emails during that.

> Also, looking at the bottom of the arch/arm/mach-omap2/prm54xx.h from this 
> commit 600e78bb51c0ee081f0da14f879c3e4a1dee9896, there are a bunch of 
> function prototypes that reference OMAP44xx.  Shouldn't these reference 
> OMAP54xx, or be removed from this file?  If you're reusing the OMAP4 PRM 
> functions for OMAP5, then shouldn't they be moved out from the OMAP4 
> header files into a separate header file?
> 
Yes. I some how ignored this considering the files were auto-generated.
Have fixed this one now in v2 [1] which is posted on list

>>       ARM: OMAP5: CM: Add OMAP54XX register and bitfield files
> 
> There are similar problems with this patch.  It doesn't look like it ever 
> made it to the linux-omap list, in my inbox, anyway.  And again the 
> function prototypes make several references to OMAP4, when they should 
> refer to OMAP5 or be removed from this file.
> 
Fixed in v2

>>       ARM: OMAP5: PRCM: Add OMAP54XX local MPU PRCM registers
> 
> More duplicated OMAP4 function prototypes here.
> 
Fixed in v2

>>       ARM: OMAP5: SCRM: Add OMAP54XX header file.
> 
> Looks fine to me.
> 
>>       ARM: OMAP2+: clockdomain data: Add OMAP54XX data and update the header
>>       ARM: OMAP5: powerdomain data: Add OMAP54XX data and update the header
> 
> These two look okay to me based on a superficial inspection.  Is there a 
> public TRM posted for OMAP5?  It's not in the obvious place, so there's no 
> way to review these against the TRM:
> 
> http://www.ti.com/lsds/ti/omap-applications-processors/technical-documents.page?familyId=601&docCategoryId=6
> 
Public TRM got delayed becasue of recent changes at TI. As per the latest
I heard, April end the TRM should be public. But as you know auto-generated
data is often more accurate than TRM :)

>>       ARM: OMAP5: hwmod data: Create initial OMAP5 SOC hwmod data
> 
> Looks like this one hasn't been reposted after the changes that were made 
> to it after Tony's comments?  If I've just missed the list post, please 
> send a link.  Otherwise, the updated patch should be reposted.
> 
As mentioned earlier, the series was lost mostly because of mailer issue.
Posted v2 has this patch now.

>> Santosh Shilimkar (4):
>>       ARM: OMAP5: hwmod_data: Fix UART sysc settings
>>       ARM: OMAP5: hwmod-data: Add timer clock activity flags
> 
> These two should be rolled into the "ARM: OMAP5: hwmod data: Create 
> initial OMAP5 SOC hwmod data" patch.
> 
Folded in v2. 

>>       ARM: OMAP5: voltagedomain data: Add OMAP5 voltage domain data
> 
> This one needs to be acked by Kevin.
>
Kevin has been cc'ed on this one.
 
>>       ARM: OMAP5: Enable build and frameowrk initialisations
> 
> Looks fine to me.
> 
Thanks a lot for quick response. Please let me know if I missed any
of your comments in v2.

Regards,
Santosh

[1] http://www.spinics.net/lists/arm-kernel/msg235575.html





From santosh.shilimkar at ti.com  Thu Apr  4 06:36:24 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Thu, 4 Apr 2013 16:06:24 +0530
Subject: [PATCH 00/10] ARM: OMAP5: hwmod, clock and prm data files
In-Reply-To: <alpine.DEB.2.00.1304032012260.16711@utopia.booyaka.com>
References: <1358522856-12180-1-git-send-email-santosh.shilimkar@ti.com>
 <alpine.DEB.2.00.1304032012260.16711@utopia.booyaka.com>
Message-ID: <515D57A8.1090707@ti.com>

On Thursday 04 April 2013 01:43 AM, Paul Walmsley wrote:
> Hi,
> 
> On Fri, 18 Jan 2013, Santosh Shilimkar wrote:
> 
>> Series contains the hwmod, clock and prm data files for OMAP54xx SOCs.
>> This data was kept out of tree to be validated on es2.0 silicon version
>> and also to avoid the es1.0/es2.0 differences which are many.
>>
>> Benoit Cousson, Rajendra Nayak, Paul Walmesly and Mike have all contributed
>> to get the autogen scripts in shape for OMAP5.
>>
>> >From various discussion on the list, the clock data files are suppose
>> to be moved to drivers/clk/. Once the direction is clear, patch 8
>> can be updated accordingly.
>>
>> Patches are tested on OMAP5 sEVM and uEVM. For testing few additional patches
>> are needed. Same tree can be fetched from here [1]
>>
>> The following changes since commit 7d1f9aeff1ee4a20b1aeb377dd0f579fe9647619:
>>
>>   Linux 3.8-rc4 (2013-01-17 19:25:45 -0800)
>>
>> are available in the git repository at:
>>
>>   git://github.com/SantoshShilimkar/linux.git for_3.9/omap5_data_files
>>
>> for you to fetch changes up to 7f534e1ebeb2bc64250b56fe00eb7d4dfa585e8e:
>>
>>   ARM: OMAP5: Enable build and frameowrk initialisations (2013-01-18 19:45:48 +0530)
> 
> I've posted several comments on the patch contents themselves, all of 
> which are relatively minor, and should be easy to fix:
> 
Indeed the fixes were easy. Have posted v2 [1] with the updates.

Regards,
Santosh

[1] http://www.spinics.net/lists/arm-kernel/msg235575.html



From rajagopal.venkat at linaro.org  Thu Apr  4 06:35:38 2013
From: rajagopal.venkat at linaro.org (Rajagopal Venkat)
Date: Thu, 4 Apr 2013 16:05:38 +0530
Subject: [PATCH V4 3/3] clk: Fixup locking issues for clk_set_parent
In-Reply-To: <1364936979-20805-4-git-send-email-ulf.hansson@stericsson.com>
References: <1364936979-20805-1-git-send-email-ulf.hansson@stericsson.com>
 <1364936979-20805-4-git-send-email-ulf.hansson@stericsson.com>
Message-ID: <CA+Z25wWi7S1fcTmhs=63sOVbzjN9q8rtNJF67eNCLT70YZpPFw@mail.gmail.com>

On 3 April 2013 02:39, Ulf Hansson <ulf.hansson at stericsson.com> wrote:
> From: Ulf Hansson <ulf.hansson at linaro.org>
>
> Updating the clock tree topology must be protected with the spinlock
> when doing clk_set_parent, otherwise we can not handle the migration
> of the enable_count in a safe manner.

Why is not safe to update tree topology with no spinlock?

>
> While issuing the .set_parent callback to make the clk-hw perform the
> switch to the new parent, we can not hold the spinlock since it is must
> be allowed to be slow path. This complicates error handling, but is still
> possible to achieve.
>
> Signed-off-by: Ulf Hansson <ulf.hansson at linaro.org>
> Cc: Rajagopal Venkat <rajagopal.venkat at linaro.org>
> ---
>  drivers/clk/clk.c |   67 +++++++++++++++++++++++++++++++++++++++++------------
>  1 file changed, 52 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index c83e8e5..de6b459 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -1363,31 +1363,71 @@ static int __clk_set_parent(struct clk *clk, struct clk *parent, u8 p_index)
>         unsigned long flags;
>         int ret = 0;
>         struct clk *old_parent = clk->parent;
> +       bool migrated_enable = false;
>
> -       /* migrate prepare and enable */
> +       /* migrate prepare */
>         if (clk->prepare_count)
>                 __clk_prepare(parent);
>
> -       /* FIXME replace with clk_is_enabled(clk) someday */
>         flags = clk_enable_lock();
> -       if (clk->enable_count)
> +
> +       /* migrate enable */
> +       if (clk->enable_count) {
>                 __clk_enable(parent);
> +               migrated_enable = true;
> +       }
> +
> +       /* update the clk tree topology */
> +       clk_reparent(clk, parent);
> +
>         clk_enable_unlock(flags);
>
>         /* change clock input source */
>         if (parent && clk->ops->set_parent)
>                 ret = clk->ops->set_parent(clk->hw, p_index);
>
> -       /* clean up old prepare and enable */
> -       flags = clk_enable_lock();
> -       if (clk->enable_count)
> +       if (ret) {
> +               /*
> +                * The error handling is tricky due to that we need to release
> +                * the spinlock while issuing the .set_parent callback. This
> +                * means the new parent might have been enabled/disabled in

But then new parent is reference counted with  __clk_enable(parent)
isn't it? Even if other children are disabling newparent, it is still
alive. Am I missing anything here?

> +                * between, which must be considered when doing rollback.
> +                */
> +               flags = clk_enable_lock();
> +
> +               clk_reparent(clk, old_parent);
> +
> +               if (migrated_enable && clk->enable_count) {
> +                       __clk_disable(parent);
> +               } else if (migrated_enable && (clk->enable_count == 0)) {

Will this condition happen at all? the reference counting should
prevent this AFAICT. Can this error path be simplified?

> +                       __clk_disable(old_parent);
> +               } else if (!migrated_enable && clk->enable_count) {
> +                       __clk_disable(parent);
> +                       __clk_enable(old_parent);
> +               }
> +
> +               clk_enable_unlock(flags);
> +
> +               if (clk->prepare_count)
> +                       __clk_unprepare(parent);
> +
> +               return ret;
> +       }
> +
> +       /* clean up enable for old parent if migration was done */
> +       if (migrated_enable) {

Reaching here, the old_parent should be disabled in any case. Is this
'if (migrated_enable)' check required?

> +               flags = clk_enable_lock();
>                 __clk_disable(old_parent);
> -       clk_enable_unlock(flags);
> +               clk_enable_unlock(flags);
> +       }
>
> +       /* clean up prepare for old parent if migration was done */
>         if (clk->prepare_count)
>                 __clk_unprepare(old_parent);
>
> -       return ret;
> +       /* update debugfs with new clk tree topology */
> +       clk_debug_reparent(clk, parent);
> +       return 0;
>  }
>
>  /**
> @@ -1450,14 +1490,11 @@ int clk_set_parent(struct clk *clk, struct clk *parent)
>         /* do the re-parent */
>         ret = __clk_set_parent(clk, parent, p_index);
>
> -       /* propagate ABORT_RATE_CHANGE if .set_parent failed */
> -       if (ret) {
> +       /* propagate rate recalculation accordingly */
> +       if (ret)
>                 __clk_recalc_rates(clk, ABORT_RATE_CHANGE);
> -               goto out;
> -       }
> -
> -       /* propagate rate recalculation downstream */
> -       __clk_reparent(clk, parent);
> +       else
> +               __clk_recalc_rates(clk, POST_RATE_CHANGE);
>
>  out:
>         clk_prepare_unlock();
> --
> 1.7.10
>



-- 
Regards,
Rajagopal


From lee.jones at linaro.org  Thu Apr  4 06:39:01 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Thu,  4 Apr 2013 11:39:01 +0100
Subject: [PATCH 2/2] mfd: db8500-prcmu: Support platform dependant device
 selection
In-Reply-To: <1365071941-23475-1-git-send-email-lee.jones@linaro.org>
References: <1365071941-23475-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1365071941-23475-2-git-send-email-lee.jones@linaro.org>

The main aim for this cycle is to have the u8540 booting to a
console. However, the u8540 doesn't support all of the u8500
platform devices yet. After this stage is complete we can then
fill in the inadequacies, such as specific clock support at a
later date. To achieve this we're placing devices supported by
all platforms into a common device structure and the remaining
ones into a platform specific one.

Cc: Samuel Ortiz <sameo at linux.intel.com>
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 drivers/mfd/db8500-prcmu.c |   52 ++++++++++++++++++++++++++++----------------
 1 file changed, 33 insertions(+), 19 deletions(-)

diff --git a/drivers/mfd/db8500-prcmu.c b/drivers/mfd/db8500-prcmu.c
index 1c4edbf8..dec94d0 100644
--- a/drivers/mfd/db8500-prcmu.c
+++ b/drivers/mfd/db8500-prcmu.c
@@ -24,6 +24,7 @@
 #include <linux/jiffies.h>
 #include <linux/bitops.h>
 #include <linux/fs.h>
+#include <linux/of.h>
 #include <linux/platform_device.h>
 #include <linux/uaccess.h>
 #include <linux/irqchip/arm-gic.h>
@@ -3107,19 +3108,7 @@ static struct ux500_wdt_data db8500_wdt_pdata = {
 	.has_28_bits_resolution = true,
 };
 
-static struct mfd_cell db8500_prcmu_devs[] = {
-	{
-		.name = "db8500-prcmu-regulators",
-		.of_compatible = "stericsson,db8500-prcmu-regulator",
-		.platform_data = &db8500_regulators,
-		.pdata_size = sizeof(db8500_regulators),
-	},
-	{
-		.name = "cpufreq-ux500",
-		.of_compatible = "stericsson,cpufreq-ux500",
-		.platform_data = &db8500_cpufreq_table,
-		.pdata_size = sizeof(db8500_cpufreq_table),
-	},
+static struct mfd_cell common_prcmu_devs[] = {
 	{
 		.name = "ux500_wdt",
 		.platform_data = &db8500_wdt_pdata,
@@ -3135,6 +3124,21 @@ static struct mfd_cell db8500_prcmu_devs[] = {
 	},
 };
 
+static struct mfd_cell db8500_prcmu_devs[] = {
+	{
+		.name = "db8500-prcmu-regulators",
+		.of_compatible = "stericsson,db8500-prcmu-regulator",
+		.platform_data = &db8500_regulators,
+		.pdata_size = sizeof(db8500_regulators),
+	},
+	{
+		.name = "cpufreq-ux500",
+		.of_compatible = "stericsson,cpufreq-ux500",
+		.platform_data = &db8500_cpufreq_table,
+		.pdata_size = sizeof(db8500_cpufreq_table),
+	},
+};
+
 static void db8500_prcmu_update_cpufreq(void)
 {
 	if (prcmu_has_arm_maxopp()) {
@@ -3184,10 +3188,10 @@ static int db8500_prcmu_probe(struct platform_device *pdev)
 
 	db8500_irq_init(np);
 
-	for (i = 0; i < ARRAY_SIZE(db8500_prcmu_devs); i++) {
-		if (!strcmp(db8500_prcmu_devs[i].name, "ab8500-core")) {
-			db8500_prcmu_devs[i].platform_data = pdata->ab_platdata;
-			db8500_prcmu_devs[i].pdata_size = sizeof(struct ab8500_platform_data);
+	for (i = 0; i < ARRAY_SIZE(common_prcmu_devs); i++) {
+		if (!strcmp(common_prcmu_devs[i].name, "ab8500-core")) {
+			common_prcmu_devs[i].platform_data = pdata->ab_platdata;
+			common_prcmu_devs[i].pdata_size = sizeof(struct ab8500_platform_data);
 		}
 	}
 
@@ -3195,13 +3199,23 @@ static int db8500_prcmu_probe(struct platform_device *pdev)
 
 	db8500_prcmu_update_cpufreq();
 
-	err = mfd_add_devices(&pdev->dev, 0, db8500_prcmu_devs,
-			      ARRAY_SIZE(db8500_prcmu_devs), NULL, 0, NULL);
+	err = mfd_add_devices(&pdev->dev, 0, common_prcmu_devs,
+			      ARRAY_SIZE(common_prcmu_devs), NULL, 0, NULL);
 	if (err) {
 		pr_err("prcmu: Failed to add subdevices\n");
 		return err;
 	}
 
+	/* TODO: Remove restriction when clk definitions are available. */
+	if (!of_machine_is_compatible("st-ericsson,u8540")) {
+		err = mfd_add_devices(&pdev->dev, 0, db8500_prcmu_devs,
+				      ARRAY_SIZE(db8500_prcmu_devs), NULL, 0, NULL);
+		if (err) {
+			pr_err("prcmu: Failed to add subdevices\n");
+			return err;
+		}
+	}
+
 	pr_info("DB8500 PRCMU initialized\n");
 
 no_irq_return:
-- 
1.7.10.4



From lee.jones at linaro.org  Thu Apr  4 06:39:00 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Thu,  4 Apr 2013 11:39:00 +0100
Subject: [PATCH 1/2] mfd: db8500-prcmu: Return early if the TCPM cannot be
 located
Message-ID: <1365071941-23475-1-git-send-email-lee.jones@linaro.org>

Currently we check to see if we obtained the Tightly Coupled Program
Memory (TCPM) base and only execute the code within the check if we
have it. It's more traditional to return early if we don't have it.
This way we can flatten most of the function's code down to a single
tab spacing.

Cc: Samuel Ortiz <sameo at linux.intel.com>
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 drivers/mfd/db8500-prcmu.c |   40 +++++++++++++++++++++-------------------
 1 file changed, 21 insertions(+), 19 deletions(-)

diff --git a/drivers/mfd/db8500-prcmu.c b/drivers/mfd/db8500-prcmu.c
index 21f261b..1c4edbf8 100644
--- a/drivers/mfd/db8500-prcmu.c
+++ b/drivers/mfd/db8500-prcmu.c
@@ -2794,6 +2794,7 @@ static void dbx500_fw_version_init(struct platform_device *pdev,
 {
 	struct resource *res;
 	void __iomem *tcpm_base;
+	u32 version;
 
 	res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
 					   "prcmu-tcpm");
@@ -2803,26 +2804,27 @@ static void dbx500_fw_version_init(struct platform_device *pdev,
 		return;
 	}
 	tcpm_base = ioremap(res->start, resource_size(res));
-	if (tcpm_base != NULL) {
-		u32 version;
-
-		version = readl(tcpm_base + version_offset);
-		fw_info.version.project = (version & 0xFF);
-		fw_info.version.api_version = (version >> 8) & 0xFF;
-		fw_info.version.func_version = (version >> 16) & 0xFF;
-		fw_info.version.errata = (version >> 24) & 0xFF;
-		strncpy(fw_info.version.project_name,
-			fw_project_name(fw_info.version.project),
-			PRCMU_FW_PROJECT_NAME_LEN);
-		fw_info.valid = true;
-		pr_info("PRCMU firmware: %s(%d), version %d.%d.%d\n",
-			fw_info.version.project_name,
-			fw_info.version.project,
-			fw_info.version.api_version,
-			fw_info.version.func_version,
-			fw_info.version.errata);
-		iounmap(tcpm_base);
+	if (!tcpm_base) {
+		dev_err(&pdev->dev, "no prcmu tcpm mem region provided\n");
+		return;
 	}
+
+	version = readl(tcpm_base + version_offset);
+	fw_info.version.project = (version & 0xFF);
+	fw_info.version.api_version = (version >> 8) & 0xFF;
+	fw_info.version.func_version = (version >> 16) & 0xFF;
+	fw_info.version.errata = (version >> 24) & 0xFF;
+	strncpy(fw_info.version.project_name,
+		fw_project_name(fw_info.version.project),
+		PRCMU_FW_PROJECT_NAME_LEN);
+	fw_info.valid = true;
+	pr_info("PRCMU firmware: %s(%d), version %d.%d.%d\n",
+		fw_info.version.project_name,
+		fw_info.version.project,
+		fw_info.version.api_version,
+		fw_info.version.func_version,
+		fw_info.version.errata);
+	iounmap(tcpm_base);
 }
 
 void __init db8500_prcmu_early_init(void)
-- 
1.7.10.4



From s.nawrocki at samsung.com  Thu Apr  4 06:41:54 2013
From: s.nawrocki at samsung.com (Sylwester Nawrocki)
Date: Thu, 04 Apr 2013 12:41:54 +0200
Subject: [PATCH v5 1/6] drivers: phy: add generic PHY framework
In-Reply-To: <515D462F.9050109@ti.com>
References: <1364993634-6378-1-git-send-email-kishon@ti.com>
 <1364993634-6378-2-git-send-email-kishon@ti.com> <515CA337.1010504@gmail.com>
 <515D462F.9050109@ti.com>
Message-ID: <515D58F2.7030404@samsung.com>

Hi,

On 04/04/2013 11:21 AM, Kishon Vijay Abraham I wrote:
> On Thursday 04 April 2013 03:16 AM, Sylwester Nawrocki wrote:
>> On 04/03/2013 02:53 PM, Kishon Vijay Abraham I wrote:

>>> +4. Getting a reference to the PHY
>>> +
>>> +Before the controller can make use of the PHY, it has to get a
>>> reference to
>>> +it. This framework provides 6 APIs to get a reference to the PHY.
>>> +
>>> +struct phy *phy_get(struct device *dev, int index);
>>> +struct phy *devm_phy_get(struct device *dev, int index);
>>> +struct phy *of_phy_get(struct device *dev, const char *phandle, int
>>> index);
>>> +struct phy *devm_of_phy_get(struct device *dev, const char *phandle,
>>> int index);
>>
>> Why do we need separate functions for dt and non-dt ? Couldn't it be
>> handled
>> internally by the framework ? So the PHY users can use same calls for dt
>> and non-dt, like in case of e.g. the regulators API ?
> 
> yeah. Indeed it makes sense to do it that way.
>
>> Also signatures of some functions are different now:
>>
>> extern struct phy *phy_get(struct device *dev, int index);
>> extern struct phy *devm_phy_get(struct device *dev, int index);
>> extern struct phy *of_phy_get(struct device *dev, int index);
>> extern struct phy *devm_of_phy_get(struct device *dev, int index);
> 
> My bad :-(
> 
>> BTW, I think "extern" could be dropped, does it have any significance in
>> function declarations in header files ?
> 
> it shouldn't have any effect I guess. It's harmless nevertheless.

Yup.

>>> +struct phy *of_phy_get_byname(struct device *dev, const char *string);
>>> +struct phy *devm_of_phy_get_byname(struct device *dev, const char
>>> *string);

>>> --- /dev/null
>>> +++ b/drivers/phy/phy-core.c
>>> @@ -0,0 +1,616 @@
>>
>>> +static struct phy *of_phy_lookup(struct device_node *node)
>>> +{
>>> +    struct phy *phy;
>>> +    struct device *dev;
>>> +    struct class_dev_iter iter;
>>> +
>>> +    class_dev_iter_init(&iter, phy_class, NULL, NULL);
>>
>> There is currently nothing preventing a call to this function before
>> phy_class is initialized. It happened during my tests, and the nice
>> stack dump showed that it was the PHY user attempting to get the PHY
>> before the framework got initialized. So either phy_core_init should
>> be a subsys_initcall or we need a better protection against phy_class
>> being NULL or ERR_PTR in more places.
> 
> Whats the initcall used in your PHY user? Looks like more people prefer having

It happened in a regular platform driver probe() callback.

> module_init and any issue because of it should be fixed in PHY providers and
> PHY users.

OK. In fact this uncovered some issues in the MIPI DSI interface driver
(some unexpected interrupts). But this should just be fixed in those drivers
anyway. Now the DSI interface driver needs to wait for the PHY to be
registered and ready, so the initialization will likely be changed regardless
the framework initializes in module_init or earlier.

>>> +    while ((dev = class_dev_iter_next(&iter))) {
>>> +        phy = container_of(dev, struct phy, dev);
>>> +        if (node != phy->of_node)
>>> +            continue;
>>> +
>>> +        class_dev_iter_exit(&iter);
>>> +        return phy;
>>> +    }
>>> +
>>> +    class_dev_iter_exit(&iter);
>>> +    return ERR_PTR(-EPROBE_DEFER);
>>> +}
>>
>>> +/**
>>> + * of_phy_get() - lookup and obtain a reference to a phy by phandle
>>> + * @dev: device that requests this phy
>>> + * @index: the index of the phy
>>> + *
>>> + * Returns the phy associated with the given phandle value,
>>> + * after getting a refcount to it or -ENODEV if there is no such phy or
>>> + * -EPROBE_DEFER if there is a phandle to the phy, but the device is
>>> + * not yet loaded.
>>> + */
>>> +struct phy *of_phy_get(struct device *dev, int index)
>>> +{
>>> +    int ret;
>>> +    struct phy *phy = NULL;
>>> +    struct phy_bind *phy_map = NULL;
>>> +    struct of_phandle_args args;
>>> +    struct device_node *node;
>>> +
>>> +    if (!dev->of_node) {
>>> +        dev_dbg(dev, "device does not have a device node entry\n");
>>> +        return ERR_PTR(-EINVAL);
>>> +    }
>>> +
>>> +    ret = of_parse_phandle_with_args(dev->of_node, "phys", "#phy-cells",
>>> +        index,&args);
>>> +    if (ret) {
>>> +        dev_dbg(dev, "failed to get phy in %s node\n",
>>> +            dev->of_node->full_name);
>>> +        return ERR_PTR(-ENODEV);
>>> +    }
>>> +
>>> +    phy = of_phy_lookup(args.np);
>>> +    if (IS_ERR(phy) || !try_module_get(phy->ops->owner)) {
>>> +        phy = ERR_PTR(-EPROBE_DEFER);
>>> +        goto err0;
>>> +    }
>>> +
>>> +    phy = phy->ops->of_xlate(phy,&args);
>>> +    if (IS_ERR(phy))
>>> +        goto err1;
>>> +
>>> +    phy_map = phy_bind(dev_name(dev), index, dev_name(&phy->dev));
>>> +    if (!IS_ERR(phy_map)) {
>>> +        phy_map->phy = phy;
>>> +        phy_map->auto_bind = true;
>>
>> Shouldn't it be done with the phy_bind_mutex held ? I guess an unlocked
>> version of the phy_bind functions is needed, so it can be used internally.
> 
> The locking is done inside phy_bind function. I'm not sure but I vaguely
> remember getting a dump stack (incorrect mutex ordering or something) when
> trying to have phy_bind_mutex here. I can check it again.

Yes, IIUC the locking needs to be reworked a bit so "phy_map" is not modified
without the mutex held.

>>> +    }
>>> +
>>> +    get_device(&phy->dev);
>>> +
>>> +err1:
>>> +    module_put(phy->ops->owner);
>>> +
>>> +err0:
>>> +    of_node_put(node);
>>> +
>>> +    return phy;
>>> +}
>>> +EXPORT_SYMBOL_GPL(of_phy_get);
>>
>>> +/**
>>> + * phy_create() - create a new phy
>>> + * @dev: device that is creating the new phy
>>> + * @label: label given to phy
>>> + * @of_node: device node of the phy
>>> + * @type: specifies the phy type
>>> + * @ops: function pointers for performing phy operations
>>> + * @priv: private data from phy driver
>>> + *
>>> + * Called to create a phy using phy framework.
>>> + */
>>> +struct phy *phy_create(struct device *dev, const char *label,
>>> +    struct device_node *of_node, int type, struct phy_ops *ops,
>>> +    void *priv)
>>> +{
>>> +    int ret;
>>> +    struct phy *phy;
>>> +    struct phy_bind *phy_bind;
>>> +    const char *devname = NULL;
>>> +
>>> +    if (!dev) {
>>> +        dev_err(dev, "no device provided for PHY\n");
>>> +        ret = -EINVAL;
>>> +        goto err0;
>>> +    }
>>> +
>>> +    if (!ops || !ops->of_xlate || !priv) {
>>> +        dev_err(dev, "no PHY ops/PHY data provided\n");
>>> +        ret = -EINVAL;
>>> +        goto err0;
>>> +    }
>>> +
>>> +    if (!phy_class)
>>> +        phy_core_init();
>>> +
>>> +    phy = kzalloc(sizeof(*phy), GFP_KERNEL);
>>> +    if (!phy) {
>>> +        ret = -ENOMEM;
>>> +        goto err0;
>>> +    }
>>> +
>>> +    devname = dev_name(dev);
>>
>> OK, a sort of serious issue here is that you can't call phy_create()
>> multiple times for same PHY provider device.
> 
> Ah.. right.

The other question I had was why we needed struct device object for each
PHY. And if it wouldn't be enough to have only struct device * in
struct phy, and the real device would be the PHY provider only. I might
be missing some reasons behind this decision though, as I have not been
following your work since the beginning.

>> device_add() further will fail as sysfs won't let you create multiple
>> objects with same name. So I would assume we need to add a new argument
>> to phy_create() or rename @type to e.g. @phy_id, which could be
>> concatenated with dev_name(dev) to create a unique name of the phy
>> device.
> 
> hmm.. ok
>>
>> And how is the PHY provider supposed to identify a PHY in its common PHY
>> ops, now when the struct phy port field is removed ? I have temporarily
>> (ab)used the type field in order to select proper registers within the
>> phy ops.
> 
> Can't it be handled in the PHY provider driver without using struct phy *?

You need to select registers/bit fields corresponding to a specific PHY,
since the phy ops are common. So we need to know exactly with which phy
we deal at the moment and I can't see any other option to figure out that
than by dereferencing struct phy *... ;)

> Moreover the PHY ops passes on the *phy to phy provider right? Not sure I

Yes, all you get in the ops is phy *. I wanted to avoid global variables
in the provider driver and be able to get to any provider private data
from phy * only.

If I use something like below for the PHY provider private data then from
struct phy * only I would need to get an index. This could be looked up by
iterating over phys[] array, but that seems an unnecessary complication.
Maybe there are better/easier ways to resolve it, without adding a new
field to struct phy.

struct phy_povider_priv {
	struct phy *phys[4];
	...
};

static in phy_power_on(struct phy *phy)
{
	struct phy_provider_priv *priv = dev_get_drvdata(&phy->dev);
	int phy_id = ...
	....
}
...
struct phy_ops ops = {
	.power_on = phy_power_on,
	...
};

> understand you here.
>
>>> +    device_initialize(&phy->dev);
>>> +
>>> +    phy->dev.class = phy_class;
>>> +    phy->dev.parent = dev;
>>> +    phy->label = label;
>>
>> What about duplicating the string here ? That would make the API a bit
>> more convenient and the callers wouldn't be required to keep all the
>> labels around.
> 
> you mean use dev_name? The device names are sometime more cryptic so preferred
> to have it like this.

No, I meant something like:

phy->label = kstrdup(label, GFP_KERNEL);

>>> +static int phy_core_init(void)
>>> +{
>>> +    if (phy_class)
>>> +        return 0;
>>> +
>>> +    phy_class = class_create(THIS_MODULE, "phy");
>>> +    if (IS_ERR(phy_class)) {
>>> +        pr_err("failed to create phy class -->  %ld\n",
>>> +            PTR_ERR(phy_class));
>>> +        return PTR_ERR(phy_class);
>>> +    }
>>> +
>>> +    phy_class->dev_release = phy_release;
>>> +    phy_class->dev_attrs = phy_dev_attrs;
>>> +
>>> +    return 0;
>>> +}
>>> +module_init(phy_core_init);
>>
>> Having this framework initialized before the PHY provider and consumer
>> drivers could save some unnecessary probe deferrals. I was wondering,
>> what is really an advantage of having it as module_init(), rather than
>> subsys_initcall() ?
> 
> I'm not sure of the exact reason but after the advent of EPROBE_DEFER, everyone
> recommends to use module_init only.

Ah...OK. We just need to ensure the resources are properly checked before
they are used then.

> Thanks for the detailed review.

Regards,
Sylwester


From kgene.kim at samsung.com  Thu Apr  4 06:46:43 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Thu,  4 Apr 2013 19:46:43 +0900
Subject: [PATCH 0/4] ARM: dts: update device tree for exynos5440
Message-ID: <1365072407-4320-1-git-send-email-kgene.kim@samsung.com>

This patch updates device tree for exynos5440 including for PMU, PDMA0 and GMAC.

 arch/arm/boot/dts/exynos5440-ssdk5440.dts |    6 +----
 arch/arm/boot/dts/exynos5440.dtsi         |   35 ++++++++++++++++++++++------
 2 files changed, 28 insertions(+), 13 deletions(-)

[PATCH 1/4] ARM: dts: Add node for GMAC for exynos5440
[PATCH 2/4] ARM: dts: add PDMA0 changes for exynos5440
[PATCH 3/4] ARM: dts: add PMU support in exynos5440
[PATCH 4/4] ARM: dts: update bootargs to boot from sda2 for


From kgene.kim at samsung.com  Thu Apr  4 06:46:44 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Thu,  4 Apr 2013 19:46:44 +0900
Subject: [PATCH 1/4] ARM: dts: Add node for GMAC for exynos5440
In-Reply-To: <1365072407-4320-1-git-send-email-kgene.kim@samsung.com>
References: <1365072407-4320-1-git-send-email-kgene.kim@samsung.com>
Message-ID: <1365072407-4320-2-git-send-email-kgene.kim@samsung.com>

From: Byungho An <bh74.an at samsung.com>

This patch adds node for GMAC for exynos5440
EXYNOS5440 SoC supported by GMAC driver.

Signed-off-by: Byungho An <bh74.an at samsung.com>
Signed-off-by: Kukjin Kim <kgene.kim at samsung.com>
---
 arch/arm/boot/dts/exynos5440.dtsi |   11 +++++++++++
 1 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5440.dtsi b/arch/arm/boot/dts/exynos5440.dtsi
index 7132358..7bd1f3b 100644
--- a/arch/arm/boot/dts/exynos5440.dtsi
+++ b/arch/arm/boot/dts/exynos5440.dtsi
@@ -147,6 +147,17 @@
 		clock-names = "watchdog";
 	};
 
+	gmac: ethernet at 00230000 {
+		compatible = "snps,dwmac-3.70a";
+		reg = <0x00230000 0x8000>;
+		interrupt-parent = <&gic>;
+		interrupts = <0 31 4>;
+		interrupt-names = "macirq";
+		phy-mode = "sgmii";
+		clocks = <&clock 12>;
+		clock-names = "stmmaceth";
+	};
+
 	amba {
 		#address-cells = <1>;
 		#size-cells = <1>;
-- 
1.7.4.4



From kgene.kim at samsung.com  Thu Apr  4 06:46:45 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Thu,  4 Apr 2013 19:46:45 +0900
Subject: [PATCH 2/4] ARM: dts: add PDMA0 changes for exynos5440
In-Reply-To: <1365072407-4320-1-git-send-email-kgene.kim@samsung.com>
References: <1365072407-4320-1-git-send-email-kgene.kim@samsung.com>
Message-ID: <1365072407-4320-3-git-send-email-kgene.kim@samsung.com>

From: Subash Patel <subash.rp at samsung.com>

PDMA0 at 0x121000 changes are added into the architecture DTS file.

Signed-off-by: Subash Patel <subash.rp at samsung.com>
Signed-off-by: Kukjin Kim <kgene.kim at samsung.com>
---
 arch/arm/boot/dts/exynos5440.dtsi |   16 ++++++++--------
 1 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5440.dtsi b/arch/arm/boot/dts/exynos5440.dtsi
index 7bd1f3b..715ea15 100644
--- a/arch/arm/boot/dts/exynos5440.dtsi
+++ b/arch/arm/boot/dts/exynos5440.dtsi
@@ -165,22 +165,22 @@
 		interrupt-parent = <&gic>;
 		ranges;
 
-		pdma0: pdma at 121A0000 {
+		pdma0: pdma at 00121000 {
 			compatible = "arm,pl330", "arm,primecell";
-			reg = <0x120000 0x1000>;
-			interrupts = <0 34 0>;
-			clocks = <&clock 21>;
+			reg = <0x121000 0x1000>;
+			interrupts = <0 46 0>;
+			clocks = <&clock 8>;
 			clock-names = "apb_pclk";
 			#dma-cells = <1>;
 			#dma-channels = <8>;
 			#dma-requests = <32>;
 		};
 
-		pdma1: pdma at 121B0000 {
+		pdma1: pdma at 00120000 {
 			compatible = "arm,pl330", "arm,primecell";
-			reg = <0x121000 0x1000>;
-			interrupts = <0 35 0>;
-			clocks = <&clock 21>;
+			reg = <0x120000 0x1000>;
+			interrupts = <0 47 0>;
+			clocks = <&clock 8>;
 			clock-names = "apb_pclk";
 			#dma-cells = <1>;
 			#dma-channels = <8>;
-- 
1.7.4.4



From kgene.kim at samsung.com  Thu Apr  4 06:46:47 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Thu,  4 Apr 2013 19:46:47 +0900
Subject: [PATCH 4/4] ARM: dts: update bootargs to boot from sda2 for
 exynos5440-ssdk5440
In-Reply-To: <1365072407-4320-1-git-send-email-kgene.kim@samsung.com>
References: <1365072407-4320-1-git-send-email-kgene.kim@samsung.com>
Message-ID: <1365072407-4320-5-git-send-email-kgene.kim@samsung.com>

From: Subash Patel <subash.rp at samsung.com>

Updated the bootargs to boot the system with rootfs in hard-disk
instead of ramdisk.

Signed-off-by: Subash Patel <subash.rp at samsung.com>
Signed-off-by: Kukjin Kim <kgene.kim at samsung.com>
---
 arch/arm/boot/dts/exynos5440-ssdk5440.dts |    6 +-----
 1 files changed, 1 insertions(+), 5 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5440-ssdk5440.dts b/arch/arm/boot/dts/exynos5440-ssdk5440.dts
index a21eb4c..d55042b 100644
--- a/arch/arm/boot/dts/exynos5440-ssdk5440.dts
+++ b/arch/arm/boot/dts/exynos5440-ssdk5440.dts
@@ -16,12 +16,8 @@
 	model = "SAMSUNG SSDK5440 board based on EXYNOS5440";
 	compatible = "samsung,ssdk5440", "samsung,exynos5440";
 
-	memory {
-		reg = <0x80000000 0x80000000>;
-	};
-
 	chosen {
-		bootargs = "root=/dev/ram0 rw ramdisk=8192 initrd=0x81000000,8M console=ttySAC0,115200 init=/linuxrc";
+		bootargs = "root=/dev/sda2 rw rootwait ignore_loglevel early_printk no_console_suspend mem=2048M at 0x80000000 console=ttySAC0,115200";
 	};
 
 	spi {
-- 
1.7.4.4



From kgene.kim at samsung.com  Thu Apr  4 06:46:46 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Thu,  4 Apr 2013 19:46:46 +0900
Subject: [PATCH 3/4] ARM: dts: add PMU support in exynos5440
In-Reply-To: <1365072407-4320-1-git-send-email-kgene.kim@samsung.com>
References: <1365072407-4320-1-git-send-email-kgene.kim@samsung.com>
Message-ID: <1365072407-4320-4-git-send-email-kgene.kim@samsung.com>

From: Subash Patel <subash.rp at samsung.com>

PMU in exynos5440 generates one interrupt per core and needs to
be passed from DT to GIC to register it.

Signed-off-by: Subash Patel <subash.rp at samsung.com>
Signed-off-by: Kukjin Kim <kgene.kim at samsung.com>
---
 arch/arm/boot/dts/exynos5440.dtsi |    8 ++++++++
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5440.dtsi b/arch/arm/boot/dts/exynos5440.dtsi
index 715ea15..5a339f0 100644
--- a/arch/arm/boot/dts/exynos5440.dtsi
+++ b/arch/arm/boot/dts/exynos5440.dtsi
@@ -55,6 +55,14 @@
 		};
 	};
 
+	arm-pmu {
+		compatible = "arm,cortex-a15-pmu", "arm,cortex-a9-pmu";
+		interrupts = <0 52 4>,
+			     <0 53 4>,
+			     <0 54 4>,
+			     <0 55 4>;
+	};
+
 	timer {
 		compatible = "arm,cortex-a15-timer",
 			     "arm,armv7-timer";
-- 
1.7.4.4



From marc.zyngier at arm.com  Thu Apr  4 06:47:32 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu, 04 Apr 2013 11:47:32 +0100
Subject: [PATCH 4/7] ARM: KVM: enforce page alignment for identity mapped
 code
In-Reply-To: <20130403231504.GD29227@gmail.com>
References: <1364909115-3810-1-git-send-email-marc.zyngier@arm.com>
 <1364909115-3810-5-git-send-email-marc.zyngier@arm.com>
 <20130403095024.GC11040@mudshark.cambridge.arm.com>
 <515BFDC7.9020401@arm.com> <20130403231504.GD29227@gmail.com>
Message-ID: <515D5A44.9030909@arm.com>

On 04/04/13 00:15, Christoffer Dall wrote:
> On Wed, Apr 03, 2013 at 11:00:39AM +0100, Marc Zyngier wrote:
>> On 03/04/13 10:50, Will Deacon wrote:
>>> On Tue, Apr 02, 2013 at 02:25:12PM +0100, Marc Zyngier wrote:
>>>> We're about to move to a init procedure where we rely on the
>>>> fact that the init code fits in a single page. Make sure we
>>>> align the idmap text on a page boundary, and that the code is
>>>> not bigger than a single page.
>>>>
>>>> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
>>>> ---
>>>>  arch/arm/kernel/vmlinux.lds.S | 2 +-
>>>>  arch/arm/kvm/init.S           | 7 +++++++
>>>>  2 files changed, 8 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
>>>> index b571484..d9dd265 100644
>>>> --- a/arch/arm/kernel/vmlinux.lds.S
>>>> +++ b/arch/arm/kernel/vmlinux.lds.S
>>>> @@ -20,7 +20,7 @@
>>>>  	VMLINUX_SYMBOL(__idmap_text_start) = .;				\
>>>>  	*(.idmap.text)							\
>>>>  	VMLINUX_SYMBOL(__idmap_text_end) = .;				\
>>>> -	ALIGN_FUNCTION();						\
>>>> +	. = ALIGN(PAGE_SIZE);						\
>>>>  	VMLINUX_SYMBOL(__hyp_idmap_text_start) = .;			\
>>>>  	*(.hyp.idmap.text)						\
>>>>  	VMLINUX_SYMBOL(__hyp_idmap_text_end) = .;
>>>> diff --git a/arch/arm/kvm/init.S b/arch/arm/kvm/init.S
>>>> index 9f37a79..35a463f 100644
>>>> --- a/arch/arm/kvm/init.S
>>>> +++ b/arch/arm/kvm/init.S
>>>> @@ -111,4 +111,11 @@ __do_hyp_init:
>>>>  	.globl __kvm_hyp_init_end
>>>>  __kvm_hyp_init_end:
>>>>  
>>>> +	/*
>>>> +	 * The above code *must* fit in a single page for the trampoline
>>>> +	 * madness to work. Whoever decides to change it must make sure
>>>> +	 * we map the right amount of memory for the trampoline to work.
>>>> +	 * The line below ensures any breakage will get noticed.
> 
> This comment is a little funny. What's this about changing it? And why
> madness? OK, it's a little mad.
> 
> I think the nice thing to explain here is why .org would complain - I
> had to look in the AS reference to figure out that it will complain if
> the location pointer is forwarded outside the section - if that is the
> right reason?
> 
>>>> +	 */
>>>> +	.org	__kvm_hyp_init + PAGE_SIZE
>>>>  	.popsection
>>>
>>> What effect does this have on the size of the kernel image? I'd expect the
>>> idmap code to be pretty small, so aligning to a page might be overkill a lot
>>> of the time.
>>
>> So we're indeed wasting memory between the kernel and the HYP idmaps.
>> The reason for this is to ensure that the init code is not spread across
>> two pages, which would make the trampoline harder to allocate.
>>
>> If there's a way to ensure that the init.S code will fit a single page,
>> then we can remove this ALIGN(PAGE_SIZE).
> 
> Just allocate a temporary page and copy the bit of code into there?  It
> should be easy enough to make sure it's location independent.  We can
> even give that page back later if we want and re-do the trick when a CPU
> gets hot-plugged if we want. No?

I'd really like to avoid freeing stuff, because it gives us even more
chances to screw our TLBs (we'd have to invalidate on unmap, and deal
with potential races between CPUs coming up).

We could allocate this page *if* the HYP init code happens to cross a
page boundary, and only then. I'll have a look at implementing this as
it should solve Will's issue (which is even worse on arm64 with 64k pages).

	M.
-- 
Jazz is not dead. It just smells funny...



From kgene.kim at samsung.com  Thu Apr  4 06:51:44 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Thu,  4 Apr 2013 19:51:44 +0900
Subject: [PATCH 2/2] ARM: EXYNOS: force mac ip to 32bit dma
In-Reply-To: <1365072704-4568-1-git-send-email-kgene.kim@samsung.com>
References: <1365072704-4568-1-git-send-email-kgene.kim@samsung.com>
Message-ID: <1365072704-4568-2-git-send-email-kgene.kim@samsung.com>

From: Girish K S <ks.giri at samsung.com>

The synopsys gigabit ethernet ip is compatible
with only 32 bit buffers. so restrict the driver
to use only 32 bit dma mapping.

Signed-off-by: Girish K S <ks.giri at samsung.com>
Signed-off-by: Siva Reddy <siva.kallam at samsung.com>
Signed-off-by: Kukjin Kim <kgene.kim at samsung.com>
---
 arch/arm/mach-exynos/mach-exynos5-dt.c |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-exynos/mach-exynos5-dt.c b/arch/arm/mach-exynos/mach-exynos5-dt.c
index e47c2a5..9596861 100644
--- a/arch/arm/mach-exynos/mach-exynos5-dt.c
+++ b/arch/arm/mach-exynos/mach-exynos5-dt.c
@@ -25,6 +25,7 @@
 #include "common.h"
 
 static u64 dma_mask64 = DMA_BIT_MASK(64);
+static u64 dma_mask32 = DMA_BIT_MASK(32);
 
 static void __init exynos5_dt_map_io(void)
 {
@@ -41,6 +42,10 @@ static int exynos5440_platform_notifier(struct notifier_block *nb,
 
 	dev->dma_mask = &dma_mask64;
 	dev->coherent_dma_mask = DMA_BIT_MASK(64);
+
+	if (of_device_is_compatible(dev->of_node, "snps,dwmac-3.70a"))
+		dev->dma_mask = &dma_mask32;
+
 	return NOTIFY_OK;
 }
 
-- 
1.7.4.4



From kgene.kim at samsung.com  Thu Apr  4 06:51:43 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Thu,  4 Apr 2013 19:51:43 +0900
Subject: [PATCH 1/2] ARM: EXYNOS: Add a platform bus notifier to set dma masks
 for Exynos5440
Message-ID: <1365072704-4568-1-git-send-email-kgene.kim@samsung.com>

From: Thomas Abraham <thomas.ab at samsung.com>

Use a platform bus notifier callback function to set the correct dma_mask and
coherent_dma_mask for every device registered on Exynos5440 based machine.

Signed-off-by: Thomas Abraham <thomas.ab at samsung.com>
Signed-off-by: Kukjin Kim <kgene.kim at samsung.com>
---
 arch/arm/mach-exynos/mach-exynos5-dt.c |   23 +++++++++++++++++++++++
 1 files changed, 23 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-exynos/mach-exynos5-dt.c b/arch/arm/mach-exynos/mach-exynos5-dt.c
index 753b94f..e47c2a5 100644
--- a/arch/arm/mach-exynos/mach-exynos5-dt.c
+++ b/arch/arm/mach-exynos/mach-exynos5-dt.c
@@ -14,6 +14,7 @@
 #include <linux/memblock.h>
 #include <linux/io.h>
 #include <linux/clocksource.h>
+#include <linux/dma-mapping.h>
 
 #include <asm/mach/arch.h>
 #include <mach/regs-pmu.h>
@@ -23,11 +24,30 @@
 
 #include "common.h"
 
+static u64 dma_mask64 = DMA_BIT_MASK(64);
+
 static void __init exynos5_dt_map_io(void)
 {
 	exynos_init_io(NULL, 0);
 }
 
+static int exynos5440_platform_notifier(struct notifier_block *nb,
+				  unsigned long event, void *__dev)
+{
+	struct device *dev = __dev;
+
+	if (event != BUS_NOTIFY_ADD_DEVICE)
+		return NOTIFY_DONE;
+
+	dev->dma_mask = &dma_mask64;
+	dev->coherent_dma_mask = DMA_BIT_MASK(64);
+	return NOTIFY_OK;
+}
+
+static struct notifier_block exynos5440_platform_nb = {
+	.notifier_call = exynos5440_platform_notifier,
+};
+
 static void __init exynos5_dt_machine_init(void)
 {
 	struct device_node *i2c_np;
@@ -52,6 +72,9 @@ static void __init exynos5_dt_machine_init(void)
 		}
 	}
 
+	if (of_machine_is_compatible("samsung,exynos5440"))
+		bus_register_notifier(&platform_bus_type, &exynos5440_platform_nb);
+
 	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
 }
 
-- 
1.7.4.4



From notasas at gmail.com  Thu Apr  4 06:54:55 2013
From: notasas at gmail.com (Grazvydas Ignotas)
Date: Thu, 4 Apr 2013 13:54:55 +0300
Subject: [PATCH] Revert "OMAP/serial: Fix incorrect Rx FIFO threshold
 setting, LSR validation on Tx, and Tx FIFO IRQ generation"
In-Reply-To: <CAOmKuSr1NohJBZ_sU43b=6oNtk+P1mL=AOA6ZW6c1dLQBkw6Ng@mail.gmail.com>
References: <alpine.DEB.2.00.1304010519260.28273@utopia.booyaka.com>
 <CAOmKuSpttQJmrL=Htiz-Zc4voAF7CnG_GQYAO2onKpauwYjtvw@mail.gmail.com>
 <alpine.DEB.2.00.1304010844100.28273@utopia.booyaka.com>
 <CAOmKuSrABrPcZ=Yg1+LAHWbh9CdTYR0eUmJ2dd3z91oz0uu21g@mail.gmail.com>
 <alpine.DEB.2.00.1304011008230.28273@utopia.booyaka.com>
 <CAOmKuSrbDc025Tj9xsqDebJ_KZdp_VnWAOs_OO5UAegV43JcDQ@mail.gmail.com>
 <CAOmKuSpbaKutLxbNihBRDz+B0Wt0XiPss-PcEHc-efCTvciNFg@mail.gmail.com>
 <alpine.DEB.2.00.1304011654520.9148@utopia.booyaka.com>
 <CAOmKuSo4onVtk2Ke-i+0_1Ych33KuUYspRy+cySRHf4yWB5XDw@mail.gmail.com>
 <alpine.DEB.2.00.1304021821190.27146@utopia.booyaka.com>
 <CAOmKuSqd=gNYFutpgDref58pbAbDwDin4mvL_OEooD1XuwKtgQ@mail.gmail.com>
 <alpine.DEB.2.00.1304030933510.12727@utopia.booyaka.com>
 <CAOmKuSr1NohJBZ_sU43b=6oNtk+P1mL=AOA6ZW6c1dLQBkw6Ng@mail.gmail.com>
Message-ID: <CANOLnONgRtaBK8OpszJBsU=D+kSoQzQgb0ALQGMtwW67JEfP8g@mail.gmail.com>

On Thu, Apr 4, 2013 at 12:06 AM, Alexey Pelykh <alexey.pelykh at gmail.com> wrote:
>
> Is it possible to check behavior on 3.0-3.2 kernels?

We use 3.2 on pandora as production kernel and it doesn't have this
issue that 3.9 had. 3.2 serial PM code is vastly different from what's
in later ones though.

>
> On Wed, Apr 3, 2013 at 11:57 PM, Paul Walmsley <paul at pwsan.com> wrote:
>> Hi Alexey,
>>
>> On Wed, 3 Apr 2013, Alexey Pelykh wrote:
>>
>>> But, since we've found the issue, I suggest that we should look at it
>>> closer, especially since at this moment only you can reproduce it.
>>
>> Well probably no one else is testing it :-)
>>
>>> As far as I understand, but I may be wrong, this comment is wrong, since
>>> if to specify OMAP_UART_SCR_RX_TRIG_GRANU1_MASK, it effectively sets Rx
>>> threshold to 1 character, instead of 16. /* Set receive FIFO threshold
>>> to 16 characters and
>>>  * transmit FIFO threshold to 16 spaces
>>>  */
>>
>> Again it certainly would not surprise me... that UART IP block seems to be
>> poorly understood :-(  Bizarre, I know.
>>
>> - Paul

--
Gra?vydas


From kgene.kim at samsung.com  Thu Apr  4 06:56:40 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Thu, 04 Apr 2013 19:56:40 +0900
Subject: [PATCH RESEND] ARM: SAMSUNG: dma: Remove unnecessary code
In-Reply-To: <1364902239-16704-1-git-send-email-padma.v@samsung.com>
References: <1364902239-16704-1-git-send-email-padma.v@samsung.com>
Message-ID: <515D5C68.3030906@samsung.com>

On 04/02/13 20:30, Padmavathi Venna wrote:
> This patch removes the usage of DMACH_DT_PROP and dt_dmach_prop
> from dma code as the new generic dma dt binding support has been
> added.
>
> Signed-off-by: Padmavathi Venna<padma.v at samsung.com>
> Acked-by: Arnd Bergmann<arnd at arndb.de>
> ---
>   arch/arm/mach-s3c24xx/include/mach/dma.h       |    1 -
>   arch/arm/mach-s3c64xx/include/mach/dma.h       |    1 -
>   arch/arm/plat-samsung/dma-ops.c                |   10 +---------
>   arch/arm/plat-samsung/include/plat/dma-ops.h   |    1 -
>   arch/arm/plat-samsung/include/plat/dma-pl330.h |    1 -
>   5 files changed, 1 insertions(+), 13 deletions(-)
>

OK, applied.

Thanks.

- Kukjin


From marc.zyngier at arm.com  Thu Apr  4 07:02:50 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu, 04 Apr 2013 13:02:50 +0200
Subject: Device Passthrough latest ARMv7 tree
In-Reply-To: <2DDB038789B01B4B80B0D3F1FF7CBDC2064D2E56@lhreml509-mbb.china.huawei.com>
References: <2DDB038789B01B4B80B0D3F1FF7CBDC2064D2E19@lhreml509-mbb.china.huawei.com>
 <2DDB038789B01B4B80B0D3F1FF7CBDC2064D2E2C@lhreml509-mbb.china.huawei.com>
 <2DDB038789B01B4B80B0D3F1FF7CBDC2064D2E41@lhreml509-mbb.china.huawei.com>
 <2DDB038789B01B4B80B0D3F1FF7CBDC2064D2E56@lhreml509-mbb.china.huawei.com>
Message-ID: <d34ce246ed426f13acd0d3b556e36182@localhost>

Hi Mario,

On Thu, 4 Apr 2013 08:53:51 +0000, Mario Smarduch
<Mario.Smarduch at huawei.com> wrote:
> Hello,
>    I'm working on device passthrough, an initial patch is for host GIC.
> Separate interrupt prioritization from deactivation for guest
interrupts.
> Guest will execute as is. 
> 
> In short patch would affect GIC mainline kernel.
> Against what repo can I submit patches given it's for virt,
> but impacts mainline?

Please use the current mainline. 3.9 contains the KVM/ARM code, and should
be used for any new development.

Plus, given that the GIC has been moved to a common location to
accommodate for arm64, this will save you some hassle later on.

Cheers,

        M.
-- 
Fast, cheap, reliable. Pick two.


From deepthi at linux.vnet.ibm.com  Thu Apr  4 07:01:35 2013
From: deepthi at linux.vnet.ibm.com (Deepthi Dharwar)
Date: Thu, 04 Apr 2013 16:31:35 +0530
Subject: [PATCH 9/9] POWERPC: pseries: cpuidle: use time keeping flag
In-Reply-To: <515C3BF2.7040609@linaro.org>
References: <1364991322-20585-1-git-send-email-daniel.lezcano@linaro.org>
 <1364991322-20585-9-git-send-email-daniel.lezcano@linaro.org>
 <515C3BF2.7040609@linaro.org>
Message-ID: <515D5D8F.7010906@linux.vnet.ibm.com>

On 04/03/2013 07:55 PM, Daniel Lezcano wrote:
> On 04/03/2013 02:15 PM, Daniel Lezcano wrote:
>> The current code computes the idle time but that can be handled
>> by the cpuidle framework if we enable the .en_core_tk_irqen flag.
>>
>> Set the flag and remove the code related to the time computation.
>>
>> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
>> Signed-off-by: Deepthi Dharwar <deepthi at linux.vnet.ibm.com>
>> ---
> 
> Rafael,
> 
> Deepthi took the patch, did a fix and tested it, this is why there is
> its signed-off.
> 
> Deepthi, could you ack the patch for Rafael also ?
> 
> Thanks
> -- Daniel


Signed-off-by: Deepthi Dharwar <deepthi at linux.vnet.ibm.com>

>>  arch/powerpc/platforms/pseries/processor_idle.c |   35 ++++++++++-------------
>>  1 file changed, 15 insertions(+), 20 deletions(-)
>>
>> diff --git a/arch/powerpc/platforms/pseries/processor_idle.c b/arch/powerpc/platforms/pseries/processor_idle.c
>> index 4d806b4..a197120 100644
>> --- a/arch/powerpc/platforms/pseries/processor_idle.c
>> +++ b/arch/powerpc/platforms/pseries/processor_idle.c
>> @@ -23,8 +23,9 @@
>>  #include "pseries.h"
>>  
>>  struct cpuidle_driver pseries_idle_driver = {
>> -	.name =		"pseries_idle",
>> -	.owner =	THIS_MODULE,
>> +	.name             = "pseries_idle",
>> +	.owner            = THIS_MODULE,
>> +	.en_core_tk_irqen = 1,
>>  };
>>  
>>  #define MAX_IDLE_STATE_COUNT	2
>> @@ -33,10 +34,8 @@ static int max_idle_state = MAX_IDLE_STATE_COUNT - 1;
>>  static struct cpuidle_device __percpu *pseries_cpuidle_devices;
>>  static struct cpuidle_state *cpuidle_state_table;
>>  
>> -static inline void idle_loop_prolog(unsigned long *in_purr, ktime_t *kt_before)
>> +static inline void idle_loop_prolog(unsigned long *in_purr)
>>  {
>> -
>> -	*kt_before = ktime_get();
>>  	*in_purr = mfspr(SPRN_PURR);
>>  	/*
>>  	 * Indicate to the HV that we are idle. Now would be
>> @@ -45,12 +44,10 @@ static inline void idle_loop_prolog(unsigned long *in_purr, ktime_t *kt_before)
>>  	get_lppaca()->idle = 1;
>>  }
>>  
>> -static inline  s64 idle_loop_epilog(unsigned long in_purr, ktime_t kt_before)
>> +static inline void idle_loop_epilog(unsigned long in_purr)
>>  {
>>  	get_lppaca()->wait_state_cycles += mfspr(SPRN_PURR) - in_purr;
>>  	get_lppaca()->idle = 0;
>> -
>> -	return ktime_to_us(ktime_sub(ktime_get(), kt_before));
>>  }
>>  
>>  static int snooze_loop(struct cpuidle_device *dev,
>> @@ -58,10 +55,9 @@ static int snooze_loop(struct cpuidle_device *dev,
>>  			int index)
>>  {
>>  	unsigned long in_purr;
>> -	ktime_t kt_before;
>>  	int cpu = dev->cpu;
>>  
>> -	idle_loop_prolog(&in_purr, &kt_before);
>> +	idle_loop_prolog(&in_purr);
>>  	local_irq_enable();
>>  	set_thread_flag(TIF_POLLING_NRFLAG);
>>  
>> @@ -75,8 +71,8 @@ static int snooze_loop(struct cpuidle_device *dev,
>>  	clear_thread_flag(TIF_POLLING_NRFLAG);
>>  	smp_mb();
>>  
>> -	dev->last_residency =
>> -		(int)idle_loop_epilog(in_purr, kt_before);
>> +	idle_loop_epilog(in_purr);
>> +
>>  	return index;
>>  }
>>  
>> @@ -102,9 +98,8 @@ static int dedicated_cede_loop(struct cpuidle_device *dev,
>>  				int index)
>>  {
>>  	unsigned long in_purr;
>> -	ktime_t kt_before;
>>  
>> -	idle_loop_prolog(&in_purr, &kt_before);
>> +	idle_loop_prolog(&in_purr);
>>  	get_lppaca()->donate_dedicated_cpu = 1;
>>  
>>  	ppc64_runlatch_off();
>> @@ -112,8 +107,9 @@ static int dedicated_cede_loop(struct cpuidle_device *dev,
>>  	check_and_cede_processor();
>>  
>>  	get_lppaca()->donate_dedicated_cpu = 0;
>> -	dev->last_residency =
>> -		(int)idle_loop_epilog(in_purr, kt_before);
>> +
>> +	idle_loop_epilog(in_purr);
>> +
>>  	return index;
>>  }
>>  
>> @@ -122,9 +118,8 @@ static int shared_cede_loop(struct cpuidle_device *dev,
>>  			int index)
>>  {
>>  	unsigned long in_purr;
>> -	ktime_t kt_before;
>>  
>> -	idle_loop_prolog(&in_purr, &kt_before);
>> +	idle_loop_prolog(&in_purr);
>>  
>>  	/*
>>  	 * Yield the processor to the hypervisor.  We return if
>> @@ -135,8 +130,8 @@ static int shared_cede_loop(struct cpuidle_device *dev,
>>  	 */
>>  	check_and_cede_processor();
>>  
>> -	dev->last_residency =
>> -		(int)idle_loop_epilog(in_purr, kt_before);
>> +	idle_loop_epilog(in_purr);
>> +
>>  	return index;
>>  }
>>  
> 
> 



From marc.zyngier at arm.com  Thu Apr  4 07:05:41 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu, 04 Apr 2013 12:05:41 +0100
Subject: [PATCH 6/7] ARM: KVM: switch to a dual-step HYP init code
In-Reply-To: <20130403231559.GG29227@gmail.com>
References: <1364909115-3810-1-git-send-email-marc.zyngier@arm.com>
 <1364909115-3810-7-git-send-email-marc.zyngier@arm.com>
 <20130403100751.GD11040@mudshark.cambridge.arm.com>
 <515C06A6.5030807@arm.com> <20130403231559.GG29227@gmail.com>
Message-ID: <515D5E85.1030808@arm.com>

On 04/04/13 00:15, Christoffer Dall wrote:
> On Wed, Apr 03, 2013 at 11:38:30AM +0100, Marc Zyngier wrote:
>> On 03/04/13 11:07, Will Deacon wrote:
>>> On Tue, Apr 02, 2013 at 02:25:14PM +0100, Marc Zyngier wrote:
>>>> Our HYP init code suffers from two major design issues:
>>>> - it cannot support CPU hotplug, as we tear down the idmap very early
>>>> - it cannot perform a TLB invalidation when switching from init to
>>>>   runtime mappings, as pages are manipulated from PL1 exclusively
>>>
>>> [...]
>>>
>>>> diff --git a/arch/arm/kvm/init.S b/arch/arm/kvm/init.S
>>>> index 35a463f..b2c6967 100644
>>>> --- a/arch/arm/kvm/init.S
>>>> +++ b/arch/arm/kvm/init.S
>>>> @@ -21,6 +21,7 @@
>>>>  #include <asm/asm-offsets.h>
>>>>  #include <asm/kvm_asm.h>
>>>>  #include <asm/kvm_arm.h>
>>>> +#include <asm/kvm_mmu.h>
>>>>  
>>>>  /********************************************************************
>>>>   * Hypervisor initialization
>>>> @@ -47,6 +48,9 @@ __kvm_hyp_init:
>>>>  	W(b)	.
>>>>  
>>>>  __do_hyp_init:
>>>> +	cmp	r2, #0			@ We have a SP?
>>>> +	bne	phase2			@ Yes, second stage init
>>>> +
>>>>  	@ Set the HTTBR to point to the hypervisor PGD pointer passed
>>>>  	mcrr	p15, 4, r0, r1, c2
>>>>  
>>>> @@ -96,14 +100,35 @@ __do_hyp_init:
>>>>  	orr	r0, r0, r1
>>>>  	isb
>>>>  	mcr	p15, 4, r0, c1, c0, 0	@ HSCR
>>>> -	isb
>>>>  
>>>> -	@ Set stack pointer and return to the kernel
>>>> +	eret
>>>> +
>>>> +phase2:
>>>> +	@ Set stack pointer
>>>>  	mov	sp, r2
>>>>  
>>>>  	@ Set HVBAR to point to the HYP vectors
>>>>  	mcr	p15, 4, r3, c12, c0, 0	@ HVBAR
>>>>  
>>>> +	@ Jump to the trampoline page
>>>> +	ldr	r2, =#PAGE_MASK
>>>
>>> Shifting right by PAGE_SHIFT can avoid the load.
>>
>> Not really. We're masking out the top bits of "target" and adding them
>> to the trampoline base address, so shifting doesn't help.
>>
>> But, as you suggested offline, BFI can come to the rescue and make that
>> code totally fun and unreadable. How about (untested):
>>
>> 	ldr	r2, =#TRAMPOLINE_VA
>> 	adr	r3, target
>> 	bfi	r2, r3, #0, #PAGE_SHIFT
>> 	mov	pc, r2
>>
>> I really like it! :)
>>
> 
> What kind of drugs are you on?
> 
> Ok, I actually like it too.

Implemented, tested, works.

>>>
>>>> +	adr	r3, target
>>>> +	bic	r3, r3, r2
>>>> +	ldr	r2, =#TRAMPOLINE_VA
>>>> +	add	r3, r3, r2
>>>> +	mov	pc, r3
>>>> +
>>>> +	nop
>>>
>>> <insert dead chicken and voodoo chant here>
>>
>> ... "You know I'll never sleep no more" ...
>>
> 
> Seriously, what kind of drugs are you guys on?

Someone did comment last year about the quality of the water in
Cambridge. He may have been right. But in this occurrence, it's only a
mild case of Frank Zappatis (Zomby Woof variety).

	M.
-- 
Jazz is not dead. It just smells funny...



From daniel.lezcano at linaro.org  Thu Apr  4 07:06:51 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Thu, 04 Apr 2013 13:06:51 +0200
Subject: [PATCH v2 12/13] ARM: move sp804 and integrator timers to
 drivers/clocksource
In-Reply-To: <CACRpkdb0B1iZrTYuD=3d86_ipSfa23msm-sjanDWQarotHEqZA@mail.gmail.com>
References: <1364854883-5961-1-git-send-email-robherring2@gmail.com>
 <1364854883-5961-13-git-send-email-robherring2@gmail.com>
 <515A179A.8020800@linaro.org> <515B3637.8090603@gmail.com>
 <CACRpkdb0B1iZrTYuD=3d86_ipSfa23msm-sjanDWQarotHEqZA@mail.gmail.com>
Message-ID: <515D5ECB.5070509@linaro.org>

On 04/03/2013 06:52 PM, Linus Walleij wrote:
> On Tue, Apr 2, 2013 at 9:49 PM, Rob Herring <robherring2 at gmail.com> wrote:
>> On 04/01/2013 06:26 PM, John Stultz wrote:
> 
>>> So, most of the code here is really clockevent code and not clocksource
>>> code. I realize they were combined in the mach directory you're copying
>>> them from, but if we're going to move all this code out of the arch
>>> directory and into drivers/, I'd like to propose we not dump it all into
>>> drivers/clocksource.
>>
>> Arguably, half the h/w is used for clocksource and half for clockevent
>> so it is equal. :) The sp804 and integrator are somewhat separated that
>> carving them up may be possible, but there are examples like i.MX timers
>> where the implementations are tied more closely together (the clockevent
>> compare value is the clocksource counter + delta).
>>
>> Where do I put the init functions which need to know about both?
>>
>> What about all the other timers that are already in drivers/clocksource?
> 
> The other day I thought about this because I remembered discussing
> it with John, and thinking about how some drivers (like ours) combine
> clock source, clock event, sched_clock() hook and delay timers. The
> same hardware is incidentally used for all four.
> 
> Driver writers really like to think about a driver pertaining to a certain
> memory segment in the hardware, and that's causing some strain
> here and there in the kernel.
> 
> Anyway, I was thinking that the four classes of drivers were somehow
> related but not the same thing.
> 
> So what about renaming
> drivers/clocksource -> drivers/timer
> 
> Then create a subdirectory drivers/timer/clocksource
> for the pure clocksource code and any drivers falling into that
> category.
> 
> Thus drivers/timer/clockevent, drivers/timer/schedclock
> and drivers/timer/delay can be created to handle specialized
> hardware blocks.
> 
> But the best thing with that scheme would be that combined
> drivers doing several things at once could live directly in
> drivers/timer/* and not pollute drivers/clocksource.

That looks reasonable.

  -- Daniel


-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From santosh.shilimkar at ti.com  Thu Apr  4 07:12:32 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Thu, 4 Apr 2013 16:42:32 +0530
Subject: [GIT PULL] ARM: OMAP5: hwmod, prm/cm data files and updates for
 3.10
In-Reply-To: <alpine.DEB.2.00.1304031146230.2616@utopia.booyaka.com>
References: <1363768852-18125-1-git-send-email-santosh.shilimkar@ti.com>
 <20130401170539.GK10155@atomide.com> <515BA76D.3000302@ti.com>
 <alpine.DEB.2.00.1304031146230.2616@utopia.booyaka.com>
Message-ID: <515D6020.2030103@ti.com>

+ Tero and few more TI folks,

On Thursday 04 April 2013 01:12 AM, Paul Walmsley wrote:
> Hi Santosh
> 
> On Wed, 3 Apr 2013, Santosh Shilimkar wrote:
> 
>> Thes patchset has already missed last couple of merge windows and its the
>> biggest bottleneck in getting OMAP5 booting from mainline. So I request
>> you to please have a look it quickly so that Tony can line that up for
>> 3.10.
> 
> Looks like there are a few minor issues with the patches based on a quick 
> look.  I'll post those to the list shortly; they should be easy to fix.  
> But those issues aren't my real concern with this series.
> 
> What's harder to fix are the underlying process issues.  My main concern 
> is that these patches add almost 9,000 lines of code and data.  We've 
> received clear guidance from the upstream ARM SoC maintainers that any 
> significant new additions need to be balanced with moving a similar number 
> of lines of code and data out of arch/arm/{plat-,mach-}* into drivers/.  
> (Or the new patches should be accompanied with patches that show obvious 
> progress towards the goal of moving code and data out of 
> arch/arm/{plat-,mach-}*.)  We need to see more help from TI on the 
> prerequisites for this cleanup process.
>
I agree that we are not making faster progress but as part of the
$subject series itself, for DT only build, we removed around ~4000
lines of data from hwmod. After the merge window, we can trim
the AM33XX and then later OMAP4 when it is made DT only support.
That should give us another 6000 lines of negative diff.
At the same time removal of MUX data for OMAP4 should be
around 2000 lines of negative diff.

You might also notice, we dropped OMAP5 clock data considering
its move under drivers/clk/. Rajendra and Tero already posted
patches [1] for the same on the list. Ofcourse your feedback is
needed to make progress there.

> For example, as discussed last year with the TI upstream PM team, an 
> important first step in this process in my view is to get rid of the 
> direct PRM/CM register accesses in the OMAP PM code.  See commit 
> c4ceedcb18cf7a06059482a3a1828b9aad9f78cf ("ARM: OMAP2+: CM/clock: convert 
> _omap2_module_wait_ready() to use SoC-independent CM functions") as an 
> example of this process.  This should make it easier to get the PRM/CM 
> functionality into drivers/.  That in turn make it possible to move the 
> clockdomain, clock, powerdomain, and hwmod code to drivers/.ARM: OMAP2+: 
> CM/clock: convert _omap2_module_wait_ready() to use SoC-independent CM 
> functions.  So far as I can tell, there hasn't been any forward progress 
> on this.
>
On this part as well after my discussion with Tony, Tero picked it up
and he and Eduardo posted questions to you [2] considering you
already had some WIP patches as we learned from Tony. I suggest
you send any information on this to "Tero" since he is leading the
PM effort and has plans to work on these items.
 
> It's also necessary to see more TI contributions in finding and fixing 
> regressions.  Detecting and fixing regressions from the previous kernel 
> release should be done first, before working on cleanup series or new 
> feature/SoC additions.  Looking at the list of v3.9-rc regressions that 
> I've found, we've gotten very little organized help from TI on dealing 
> with them.  
> 
> This in turn robs the maintainers of time that could be spent doing patch 
> review or further cleanup work, which benefits no one in the end.  
> Ideally each regression would be assigned to a member of the TI upstream 
> team, and the whole process could be completed within one or two weeks.
>
I agree with you overall. 

On couple of specific issues though,

- BOOT-Loader version:  IMHO boot-loader should be upgraded here.
We always upgrade kernel for new/fixed features and bootloader should
be no exception.

- Co-processor Power issue: This one is also has boot-loader dependency
but here too, going on path where firmware needs to be loaded to idle
them isn't great idea. We never did that for OMAP2/3 where DSP, Tesla
was present. IMO, we should not bring these devices out of reset and
let the "remote_proc()" frame works take care of them when it is
available in kernel. Suman from TI is working on it to enable that.
 
> ...
> 
> So from my point of view, I'd like to see the following changes before we 
> accept any new patchsets that add a significant number of lines:
> 
> 1. Organized help from TI in finding and fixing regressions in the -rc 
> cycle, with the regressions dealt with before any new feature 
> pull-requests are sent
>
Agreed. Tero can help here to streamline the process for PM regressions.
Rest of the core regressions and MPU PM, feel free to pass it on to
Rajendra/me. We will try to address them on priority.

 
> 2. Help from TI on some of the cleanup work that we've mentioned in the 
> past, starting with the PRM/CM register access cleanup inside mach-omap2/
> 
Absolutely. As I mentioned earlier, Eduardo and Tero are waiting for your
inputs on this topic.

> 3. Pairing any large feature or SoC additions with at least an equal 
> removal of lines of code
> 
As listed in beginning of the email, there is an effort going on in this
direction. In fact removal of lines of code has to happen even without
any new feature. As Tony mentioned in past, we eventually want to support
DT only builds and that should also allow us significant loc removal
opportunity. But feel free to suggest ideas if you see more opportunities
apart from the obvious ones.

Thanks for all your help.

Regards,
Santosh

[1] http://www.mail-archive.com/linux-omap at vger.kernel.org/msg87110.html
[2] http://www.mail-archive.com/linux-omap at vger.kernel.org/msg85602.html


From kishon at ti.com  Thu Apr  4 07:11:18 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Thu, 4 Apr 2013 16:41:18 +0530
Subject: [PATCH v5 1/6] drivers: phy: add generic PHY framework
In-Reply-To: <515D58F2.7030404@samsung.com>
References: <1364993634-6378-1-git-send-email-kishon@ti.com>
 <1364993634-6378-2-git-send-email-kishon@ti.com> <515CA337.1010504@gmail.com>
 <515D462F.9050109@ti.com> <515D58F2.7030404@samsung.com>
Message-ID: <515D5FD6.4040909@ti.com>

Hi,

On Thursday 04 April 2013 04:11 PM, Sylwester Nawrocki wrote:
> Hi,
>
> On 04/04/2013 11:21 AM, Kishon Vijay Abraham I wrote:
>> On Thursday 04 April 2013 03:16 AM, Sylwester Nawrocki wrote:
>>> On 04/03/2013 02:53 PM, Kishon Vijay Abraham I wrote:
>
>>>> +4. Getting a reference to the PHY
>>>> +
>>>> +Before the controller can make use of the PHY, it has to get a
>>>> reference to
>>>> +it. This framework provides 6 APIs to get a reference to the PHY.
>>>> +
>>>> +struct phy *phy_get(struct device *dev, int index);
>>>> +struct phy *devm_phy_get(struct device *dev, int index);
>>>> +struct phy *of_phy_get(struct device *dev, const char *phandle, int
>>>> index);
>>>> +struct phy *devm_of_phy_get(struct device *dev, const char *phandle,
>>>> int index);
>>>
>>> Why do we need separate functions for dt and non-dt ? Couldn't it be
>>> handled
>>> internally by the framework ? So the PHY users can use same calls for dt
>>> and non-dt, like in case of e.g. the regulators API ?
>>
>> yeah. Indeed it makes sense to do it that way.
>>
>>> Also signatures of some functions are different now:
>>>
>>> extern struct phy *phy_get(struct device *dev, int index);
>>> extern struct phy *devm_phy_get(struct device *dev, int index);
>>> extern struct phy *of_phy_get(struct device *dev, int index);
>>> extern struct phy *devm_of_phy_get(struct device *dev, int index);
>>
>> My bad :-(
>>
>>> BTW, I think "extern" could be dropped, does it have any significance in
>>> function declarations in header files ?
>>
>> it shouldn't have any effect I guess. It's harmless nevertheless.
>
> Yup.
>
>>>> +struct phy *of_phy_get_byname(struct device *dev, const char *string);
>>>> +struct phy *devm_of_phy_get_byname(struct device *dev, const char
>>>> *string);
>
>>>> --- /dev/null
>>>> +++ b/drivers/phy/phy-core.c
>>>> @@ -0,0 +1,616 @@
>>>
>>>> +static struct phy *of_phy_lookup(struct device_node *node)
>>>> +{
>>>> +    struct phy *phy;
>>>> +    struct device *dev;
>>>> +    struct class_dev_iter iter;
>>>> +
>>>> +    class_dev_iter_init(&iter, phy_class, NULL, NULL);
>>>
>>> There is currently nothing preventing a call to this function before
>>> phy_class is initialized. It happened during my tests, and the nice
>>> stack dump showed that it was the PHY user attempting to get the PHY
>>> before the framework got initialized. So either phy_core_init should
>>> be a subsys_initcall or we need a better protection against phy_class
>>> being NULL or ERR_PTR in more places.
>>
>> Whats the initcall used in your PHY user? Looks like more people prefer having
>
> It happened in a regular platform driver probe() callback.
>
>> module_init and any issue because of it should be fixed in PHY providers and
>> PHY users.
>
> OK. In fact this uncovered some issues in the MIPI DSI interface driver
> (some unexpected interrupts). But this should just be fixed in those drivers
> anyway. Now the DSI interface driver needs to wait for the PHY to be
> registered and ready, so the initialization will likely be changed regardless
> the framework initializes in module_init or earlier.
>
>>>> +    while ((dev = class_dev_iter_next(&iter))) {
>>>> +        phy = container_of(dev, struct phy, dev);
>>>> +        if (node != phy->of_node)
>>>> +            continue;
>>>> +
>>>> +        class_dev_iter_exit(&iter);
>>>> +        return phy;
>>>> +    }
>>>> +
>>>> +    class_dev_iter_exit(&iter);
>>>> +    return ERR_PTR(-EPROBE_DEFER);
>>>> +}
>>>
>>>> +/**
>>>> + * of_phy_get() - lookup and obtain a reference to a phy by phandle
>>>> + * @dev: device that requests this phy
>>>> + * @index: the index of the phy
>>>> + *
>>>> + * Returns the phy associated with the given phandle value,
>>>> + * after getting a refcount to it or -ENODEV if there is no such phy or
>>>> + * -EPROBE_DEFER if there is a phandle to the phy, but the device is
>>>> + * not yet loaded.
>>>> + */
>>>> +struct phy *of_phy_get(struct device *dev, int index)
>>>> +{
>>>> +    int ret;
>>>> +    struct phy *phy = NULL;
>>>> +    struct phy_bind *phy_map = NULL;
>>>> +    struct of_phandle_args args;
>>>> +    struct device_node *node;
>>>> +
>>>> +    if (!dev->of_node) {
>>>> +        dev_dbg(dev, "device does not have a device node entry\n");
>>>> +        return ERR_PTR(-EINVAL);
>>>> +    }
>>>> +
>>>> +    ret = of_parse_phandle_with_args(dev->of_node, "phys", "#phy-cells",
>>>> +        index,&args);
>>>> +    if (ret) {
>>>> +        dev_dbg(dev, "failed to get phy in %s node\n",
>>>> +            dev->of_node->full_name);
>>>> +        return ERR_PTR(-ENODEV);
>>>> +    }
>>>> +
>>>> +    phy = of_phy_lookup(args.np);
>>>> +    if (IS_ERR(phy) || !try_module_get(phy->ops->owner)) {
>>>> +        phy = ERR_PTR(-EPROBE_DEFER);
>>>> +        goto err0;
>>>> +    }
>>>> +
>>>> +    phy = phy->ops->of_xlate(phy,&args);
>>>> +    if (IS_ERR(phy))
>>>> +        goto err1;
>>>> +
>>>> +    phy_map = phy_bind(dev_name(dev), index, dev_name(&phy->dev));
>>>> +    if (!IS_ERR(phy_map)) {
>>>> +        phy_map->phy = phy;
>>>> +        phy_map->auto_bind = true;
>>>
>>> Shouldn't it be done with the phy_bind_mutex held ? I guess an unlocked
>>> version of the phy_bind functions is needed, so it can be used internally.
>>
>> The locking is done inside phy_bind function. I'm not sure but I vaguely
>> remember getting a dump stack (incorrect mutex ordering or something) when
>> trying to have phy_bind_mutex here. I can check it again.
>
> Yes, IIUC the locking needs to be reworked a bit so "phy_map" is not modified
> without the mutex held.
>
>>>> +    }
>>>> +
>>>> +    get_device(&phy->dev);
>>>> +
>>>> +err1:
>>>> +    module_put(phy->ops->owner);
>>>> +
>>>> +err0:
>>>> +    of_node_put(node);
>>>> +
>>>> +    return phy;
>>>> +}
>>>> +EXPORT_SYMBOL_GPL(of_phy_get);
>>>
>>>> +/**
>>>> + * phy_create() - create a new phy
>>>> + * @dev: device that is creating the new phy
>>>> + * @label: label given to phy
>>>> + * @of_node: device node of the phy
>>>> + * @type: specifies the phy type
>>>> + * @ops: function pointers for performing phy operations
>>>> + * @priv: private data from phy driver
>>>> + *
>>>> + * Called to create a phy using phy framework.
>>>> + */
>>>> +struct phy *phy_create(struct device *dev, const char *label,
>>>> +    struct device_node *of_node, int type, struct phy_ops *ops,
>>>> +    void *priv)
>>>> +{
>>>> +    int ret;
>>>> +    struct phy *phy;
>>>> +    struct phy_bind *phy_bind;
>>>> +    const char *devname = NULL;
>>>> +
>>>> +    if (!dev) {
>>>> +        dev_err(dev, "no device provided for PHY\n");
>>>> +        ret = -EINVAL;
>>>> +        goto err0;
>>>> +    }
>>>> +
>>>> +    if (!ops || !ops->of_xlate || !priv) {
>>>> +        dev_err(dev, "no PHY ops/PHY data provided\n");
>>>> +        ret = -EINVAL;
>>>> +        goto err0;
>>>> +    }
>>>> +
>>>> +    if (!phy_class)
>>>> +        phy_core_init();
>>>> +
>>>> +    phy = kzalloc(sizeof(*phy), GFP_KERNEL);
>>>> +    if (!phy) {
>>>> +        ret = -ENOMEM;
>>>> +        goto err0;
>>>> +    }
>>>> +
>>>> +    devname = dev_name(dev);
>>>
>>> OK, a sort of serious issue here is that you can't call phy_create()
>>> multiple times for same PHY provider device.
>>
>> Ah.. right.
>
> The other question I had was why we needed struct device object for each
> PHY. And if it wouldn't be enough to have only struct device * in
> struct phy, and the real device would be the PHY provider only. I might

IMO the PHY framework shouldn't be modifying the properties of device of 
some other driver. Consider the case where the PHY provider implements 
other functions also (in addition to acting as a PHY) in which case the 
PHY provider entirely doesn't come under *PHY class* but only a part of 
it. There might be other reasons as well.

Thanks
Kishon




From arnd at arndb.de  Thu Apr  4 07:12:25 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 4 Apr 2013 11:12:25 +0000
Subject: [RFC PATCH arm: initial TI-Nspire support]
In-Reply-To: <6FE4B33E-A503-4A75-AEED-831CB2C06D83@gmail.com>
References: <6FE4B33E-A503-4A75-AEED-831CB2C06D83@gmail.com>
Message-ID: <201304041112.25780.arnd@arndb.de>

On Thursday 04 April 2013, Daniel Tang wrote:
> We're sending out for comments an early patch adding TI-Nspire support
> to Linux.
> 
> Some words on the Nspire platform: it's a series of graphing
> calculators, made of four models: "Clickpad" (2007-2010), "Touchpad"
> (2010-2012?), "CX" (2011-), "CM-C" (2011-).

Very cool! I hope we can get this merged.

> Patch contents
> --------------
> This patch (against mainline, but it also applies to linux-next)
> contains the essential support code required to boot Linux to a shell 
> on all models, but contains nothing else at the moment.
> Code containing drivers for other peripherals exists, and will
> eventually be posted for review as well: we need to do a bit of
> cleanup. If you prefer them to be posted here now, we'll do.
> They're at https://github.com/tangrs/linux .
> 
> A possibly noteworthy fact is that despite the gradual shift to
> using Device Tree definitions for ARM machine types, we've decided not
> to use it, for the following reasons:
> 
>     * the (perceived) extra complexity and code size;
>     * the fact that we're using our own, simple, bootloader, due to
>       the impossibility to bootstrap on most models (because boot1
>       is usually not modifiable) and the fact that the image is stored
>       in a proprietary FS not supported by mainline Linux and
>       common bootloaders...

For new platforms, we want to have only the absolute minimum amount of
code in arch/arm and move everything else into drivers. However, that
is only possible using device tree. It should not add any significant
complexity to your code, and you can easily bundle the device tree blob
with the kernel.
> 
> +config ARCH_NSPIRE
> +	bool "TI-NSPIRE based"
> +	depends on MMU
> +	select CPU_ARM926T
> +	select HAVE_MACH_CLKDEV
> +	select CLKDEV_LOOKUP
> +	select ARM_AMBA
> +	select USB_ARCH_HAS_EHCI
> +	select ARCH_WANT_OPTIONAL_GPIOLIB
> +	select GENERIC_ALLOCATOR
> +	select ARCH_HAS_CPUFREQ
> +	select CPU_FREQ_TABLE

Any new platform should use COMMON_CLK and SPARSE_IRQ in addition
to these.

> diff --git a/arch/arm/mach-nspire/Kconfig b/arch/arm/mach-nspire/Kconfig
> new file mode 100644
> index 0000000..da032b7
> --- /dev/null
> +++ b/arch/arm/mach-nspire/Kconfig
> @@ -0,0 +1,36 @@
> +if ARCH_NSPIRE
> +
> +choice
> +	prompt "Early printk and boot message serial interface"
> +	help
> +	  Early printk output interface
> +	depends on EARLY_PRINTK
> +	default NSPIRE_EARLYPRINTK_CX
> +
> +config NSPIRE_EARLYPRINTK_CLASSIC
> +	bool "Classic"
> +
> +config NSPIRE_EARLYPRINTK_CX
> +	bool "CX model"
> +endchoice

This should go into arch/arm/Kconfig.debug.

> +
> +menu "Supported models"
> +
> +config MACH_NSPIRECX
> +	select GENERIC_CLOCKEVENTS
> +	select ARM_VIC
> +	select ARM_TIMER_SP804
> +	bool "CX/CX CAS"

The SP804 driver is currently being changed in the move to drivers/clocksource,
which may impact your code as well.

> diff --git a/arch/arm/mach-nspire/Makefile.boot b/arch/arm/mach-nspire/Makefile.boot
> new file mode 100644
> index 0000000..7db966b
> --- /dev/null
> +++ b/arch/arm/mach-nspire/Makefile.boot
> @@ -0,0 +1 @@
> +zreladdr-y	:= 0x10008000

Please use AUTO_ZRELADDR

> +static unsigned long classic_clocks_to_io(struct nspire_clk_speeds *clks)
> +{
> +	union reg_clk_speed reg;
> +
> +	BUG_ON(clks->div.base_cpu < 2);
> +	BUG_ON(clks->div.cpu_ahb < 1);
> +
> +	reg.raw = 0;
> +	reg.val.base_cpu_ratio = clks->div.base_cpu / 2;
> +	reg.val.cpu_ahb_ratio = clks->div.cpu_ahb - 1;
> +	reg.val.is_base_27mhz = (clks->base <= 27000000);
> +	reg.val.base_val = (300 - (clks->base / 1000000)) / 6;
> +
> +	return reg.raw;
> +}

Clock code should live in drivers/clk/

> +/* Interrupt handling */
> +
> +static inline int check_interrupt(void __iomem *base, struct pt_regs *regs)
> +{
> +	if (readl(base + 0x0)) {
> +		int irqnr = readl(base + 0x24);
> +		unsigned prev_priority;
> +		handle_IRQ(irqnr, regs);
> +
> +		/* Reset priorities */
> +		prev_priority = readl(IOMEM(NSPIRE_INTERRUPT_VIRT_BASE + 0x28));
> +		writel(prev_priority, IOMEM(NSPIRE_INTERRUPT_VIRT_BASE + 0x2c));
> +		return 1;
> +	}
> +	return 0;
> +}

Interrupt code should live in drivers/irqchip/

Your method of doing "readl(IOMEM(NSPIRE_INTERRUPT_VIRT_BASE + 0x28));" has multiple
flaws:

* A FOO_VIRT_BASE constant should already be of type "void __iomem *" and not
  require another IOMEM()
* Normally the base address is generated at runtime using ioremap or of_iomap,
  since in  multiplatform kernel, you have no access to platform specific constants
  from a device driver
* You might want to define symbolic constants for "0x28".

> +void __init nspire_classic_init_irq(void)
> +{
> +	/* No stickies */
> +	writel(0, IOMEM(NSPIRE_INTERRUPT_VIRT_BASE + 0x204));
> +
> +	/* Disable all interrupts */
> +	writel(~0, IOMEM(NSPIRE_INTERRUPT_VIRT_BASE + 0xc));
> +	writel(~0, IOMEM(NSPIRE_INTERRUPT_VIRT_BASE + 0x10c));
> +
> +	/* Set all priorities to 0 */
> +	memset_io(IOMEM(NSPIRE_INTERRUPT_VIRT_BASE + 0x300), 0, 0x7f);
> +
> +	/* Accept interrupts of all priorities */
> +	writel(0xf, IOMEM(NSPIRE_INTERRUPT_VIRT_BASE + 0x2c));
> +	writel(0xf, IOMEM(NSPIRE_INTERRUPT_VIRT_BASE + 0x12c));
> +
> +	/* Clear existing interrupts */
> +	readl(IOMEM(NSPIRE_INTERRUPT_VIRT_BASE + 0x28));
> +	readl(IOMEM(NSPIRE_INTERRUPT_VIRT_BASE + 0x128));
> +
> +	/* Add chip */
> +	classic_allocate_gc();
> +}

For sparse irq and for devicetree, you need to allocate an irqdomain here.

> +
> +
> +static struct clock_event_device nspire_clkevt = {
> +	.name		= "clockevent",
> +	.features	= CLOCK_EVT_FEAT_ONESHOT,
> +	.shift		= 32,
> +	.rating		= 400,
> +	.set_next_event = classic_timer_set_event,
> +	.set_mode	= classic_timer_set_mode,
> +	.cpumask		= cpu_all_mask,
> +};

clockevent code should live in drivers/clocksource, although there
is ongoing discussion about creating a new directory for clockevent
separate from clocksource. Not in arch/arm though.

> +/* Serial */
> +static struct plat_serial8250_port classic_serial_platform_data[] = {
> +	{
> +		.mapbase	= NSPIRE_APB_PHYS(NSPIRE_APB_UART),
> +		.irq		= NSPIRE_IRQ_UART,
> +		.uartclk	= 29491200,
> +		.iotype		= UPIO_MEM,
> +		.flags		= UPF_BOOT_AUTOCONF | UPF_SKIP_TEST |
> +				UPF_IOREMAP,
> +		.regshift	= 2
> +	},
> +	{ }
> +};
> +
> +struct platform_device nspire_classic_serial_device = {
> +	.name		= "serial8250",
> +	.id			= PLAT8250_DEV_PLATFORM,
> +	.dev = {
> +		.platform_data = &classic_serial_platform_data
> +	}
> +};

You can use the of_serial driver to get that information from the device tree.

> > +/* Framebuffer */
> +static struct clcd_panel classic_lcd_panel = {
> +	.mode		= {
> +		.name		= "grayscale lcd",
> +		.refresh	= 60,
> +		.xres		= 320,
> +		.yres		= 240,
> +		.sync		= FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,
> +		.vmode		= FB_VMODE_NONINTERLACED,
> +		.pixclock	= 1,
> +		.hsync_len	= 6,
> +		.vsync_len	= 1,
> +		.right_margin	= 6,
> +		.left_margin	= 6,
> +	},
> +	.width		= 71, /* 7.11cm */
> +	.height		= 53, /* 5.33cm */
> +	.tim2		= 0x80007d0,
> +	.cntl		= CNTL_LCDBPP8 | CNTL_LCDMONO8,
> +	.bpp		= 8,
> +	.grayscale	= 1
> +};
> +#define PANEL_SIZE (19 * SZ_4K)
> +
> +static int classic_clcd_setup(struct clcd_fb *fb)
> +{
> +	return nspire_clcd_setup(fb, PANEL_SIZE, &classic_lcd_panel);
> +}

And drivers/video/of_display_timing.c for these.

> diff --git a/arch/arm/mach-nspire/clock.c b/arch/arm/mach-nspire/clock.c
> new file mode 100644
> index 0000000..c679449
> --- /dev/null
> +++ b/arch/arm/mach-nspire/clock.c

Not needed with COMMON_CLK


> +
> +#define IOTABLE_ENTRY(t) \
> +	{ \
> +		.virtual	= NSPIRE_##t##_VIRT_BASE, \
> +		.pfn		= __phys_to_pfn(NSPIRE_##t##_PHYS_BASE), \
> +		.length		= NSPIRE_##t##_SIZE, \
> +		.type		= MT_DEVICE \
> +	}
> +
> +#define RESOURCE_ENTRY_IRQ(t) \
> +	{ \
> +		.start	= NSPIRE_IRQ_##t, \
> +		.end	= NSPIRE_IRQ_##t, \
> +		.flags	= IORESOURCE_IRQ \
> +	}
> +
> +#define RESOURCE_ENTRY_MEM(t) \
> +	{ \
> +		.start	= NSPIRE_##t##_PHYS_BASE, \
> +		.end	= NSPIRE_##t##_PHYS_BASE + NSPIRE_##t##_SIZE - 1, \
> +		.flags	= IORESOURCE_MEM \
> +	}

Please don't define your own macros for generic functionality. If you think
that macros are good for these, you can submit a patch to make them available
for everyone.

For the resources, we already have macros in include/linux/ioport.h

> +extern struct platform_device nspire_keypad_device;
> +extern struct platform_device nspire_otg_device;
> +extern struct platform_device nspire_usb_nop_xceiver;
> +extern struct nspire_keypad_data nspire_keypad_data;

Do not define "struct platform_devices" as global data structures, it messes
up reference counting. Ideally all platform and AMBA devices get created
from device tree. If that should not be possible for one of them, you can
use platform_device_register_resndata or the associated functions.

> diff --git a/arch/arm/mach-nspire/include/mach/clkdev.h b/arch/arm/mach-nspire/include/mach/clkdev.h
> new file mode 100644
> index 0000000..b4afe65
> --- /dev/null
> +++ b/arch/arm/mach-nspire/include/mach/clkdev.h

Not needed with common clk.

> diff --git a/arch/arm/mach-nspire/include/mach/debug-macro.S b/arch/arm/mach-nspire/include/mach/debug-macro.S
> new file mode 100644
> index 0000000..b71daa4
> --- /dev/null
> +++ b/arch/arm/mach-nspire/include/mach/debug-macro.S

Move this to arch/arm/include/debug/

> diff --git a/arch/arm/mach-nspire/include/mach/hardware.h b/arch/arm/mach-nspire/include/mach/hardware.h
> new file mode 100644
> index 0000000..7c9c3b6
> --- /dev/null
> +++ b/arch/arm/mach-nspire/include/mach/hardware.h

delete this

> diff --git a/arch/arm/mach-nspire/include/mach/irqs.h b/arch/arm/mach-nspire/include/mach/irqs.h
> new file mode 100644
> index 0000000..70be120
> --- /dev/null
> +++ b/arch/arm/mach-nspire/include/mach/irqs.h
> @@ -0,0 +1,34 @@
> +/*
> + *  linux/arch/arm/mach-nspire/include/mach/irqs.h
> + *
> + *  Copyright (C) 2012 Daniel Tang <tangrs at tangrs.id.au>
> + *
> + * 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.
> + *
> + */
> +
> +#ifndef NSPIRE_IRQS_H
> +#define NSPIRE_IRQS_H
> +
> +#define NSPIRE_IRQ_MASK         0x007FEB9A
> +
> +enum {
> +	NSPIRE_IRQ_UART = 1,
> +	NSPIRE_IRQ_WATCHDOG = 3,
> +	NSPIRE_IRQ_RTC = 4,
> +	NSPIRE_IRQ_GPIO = 7,
> +	NSPIRE_IRQ_OTG = 8,
> +	NSPIRE_IRQ_HOSTUSB = 9,
> +	NSPIRE_IRQ_ADC = 11,
> +	NSPIRE_IRQ_PWR = 15,
> +	NSPIRE_IRQ_KEYPAD = 16,
> +	NSPIRE_IRQ_TIMER2 = 19,
> +	NSPIRE_IRQ_I2C = 20,
> +	NSPIRE_IRQ_LCD = 21
> +};
> +
> +#define NR_IRQS 32
> +
> +#endif

Not needed as a globally visible file with sparse IRQ.

> diff --git a/arch/arm/mach-nspire/include/mach/keypad.h b/arch/arm/mach-nspire/include/mach/keypad.h
> new file mode 100644
> index 0000000..18cf3fd
> --- /dev/null
> +++ b/arch/arm/mach-nspire/include/mach/keypad.h

Move this to include/linux/platform_data or delete this once you have converted
to device tree.


> diff --git a/arch/arm/mach-nspire/include/mach/memory.h b/arch/arm/mach-nspire/include/mach/memory.h
> new file mode 100644
> index 0000000..eec3f36
> --- /dev/null
> +++ b/arch/arm/mach-nspire/include/mach/memory.h
> @@ -0,0 +1,17 @@
> +/*
> + *  linux/arch/arm/mach-nspire/include/mach/memory.h
> + *
> + *  Copyright (C) 2012 Daniel Tang <tangrs at tangrs.id.au>
> + *
> + * 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.
> + *
> + */
> +
> +#ifndef NSPIRE_MEMORY_H
> +#define NSPIRE_MEMORY_H
> +
> +#define PLAT_PHYS_OFFSET 0x10000000
> +
> +#endif

I think you already don't use this.

> diff --git a/arch/arm/mach-nspire/include/mach/nspire_mmio.h b/arch/arm/mach-nspire/include/mach/nspire_mmio.h
> new file mode 100644
> index 0000000..eaeb100
> --- /dev/null
> +++ b/arch/arm/mach-nspire/include/mach/nspire_mmio.h

Move to arch/arm/mach-nspire/, drivers should not see this.

> diff --git a/arch/arm/mach-nspire/include/mach/sram.h b/arch/arm/mach-nspire/include/mach/sram.h
> new file mode 100644
> index 0000000..2f652f3
> --- /dev/null
> +++ b/arch/arm/mach-nspire/include/mach/sram.h

A new sram subsystem is getting added, so don't provide your own copy.

> diff --git a/arch/arm/mach-nspire/include/mach/timex.h b/arch/arm/mach-nspire/include/mach/timex.h
> new file mode 100644
> index 0000000..2d4449e
> --- /dev/null
> +++ b/arch/arm/mach-nspire/include/mach/timex.h

delete this.

> diff --git a/arch/arm/mach-nspire/include/mach/uncompress.h b/arch/arm/mach-nspire/include/mach/uncompress.h
> new file mode 100644
> index 0000000..7be9d06
> --- /dev/null
> +++ b/arch/arm/mach-nspire/include/mach/uncompress.h

You can delete this once you enable CONFIG_ARCH_MULTIPLATFORM

> +#if defined(CONFIG_MOUSE_SYNAPTICS_I2C) || \
> +	defined(CONFIG_MOUSE_SYNAPTICS_I2C_MODULE)
> +static struct i2c_board_info synaptics_i2c = {
> +	I2C_BOARD_INFO("synaptics_i2c", 0x20),
> +	.irq    = 0,
> +};
> +
> +void __init nspire_touchpad_init()
> +{
> +	i2c_register_board_info(0, &synaptics_i2c, 1);
> +}
> +
> +#else
> +inline void nspire_touchpad_init() {}
> +#endif

Device definitions should not be conditional on the presence of the driver.
This will of course be no issue once you move to DT.

	Arnd


From laurent.pinchart at ideasonboard.com  Thu Apr  4 07:20:44 2013
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Thu, 04 Apr 2013 13:20:44 +0200
Subject: [RFC/PATCH 0/7] ARCH: shmobile: defconfig consolidation
In-Reply-To: <1365046193-19369-1-git-send-email-horms+renesas@verge.net.au>
References: <1365046193-19369-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1374328.KVLKlOlad0@avalon>

Hi Simon,

On Thursday 04 April 2013 12:29:46 Simon Horman wrote:
> Hi,
> 
> this is a first pass at consolidating the defconfigs of shmobile.
> 
> It covers the mackerel, amradillo800eva and kzm9d boards which meet
> the following criteria:
> 
> * Have the same base memory address (0x40000000).

Do you know if there's any work being done on getting rid of the base memory 
address as a kernel config option ? It seriously hinders cross-SoC kernel 
testing.

> * Work with RUNTIME_PM, it is desirable to have that a common defconfig
> * Are booted via DT, enabling the command line to be supplied in the dts.
>   This is important to allow serial console and early printk settings,
>   which vary wildly between boards, to be supplied.
> * Boards I have to test.
>   This didn't eliminate any candidates that met the above criteria.
> 
> I believe it should also be possible to add support for the APE6EVM
> board to the consolidated defconfig once problems with RUNTIME_PM
> have been isolated and resolved. I have send an email about this
> in a separate thread "APE6EVM and Runtime PM".
> 
> I believe it may be possible to add support for the lager board
> to the consolidated defconfig once I am able to bring that board up,
> which should be rather soon. The lager board does not currently
> have a defconfig.
> 
> Morimoto-san, I suspect it may be possible to add support for the
> bockw board to the consolidated defconfig if its boot loader supports
> booting using a zImage. In this case even though the base memory address
> is not the same as the boards above it should be possible to specify
> the base address from the boot loader. As I do not have a bockw board
> I am wondering if you could investigate this.
> 
> Simon Horman (7):
>   ARM: shmobile: prune defconfig
>   ARM: shmobile: make defconfig canonical
>   ARM: shmobile: Add kzm9d to consolidated defconfig
>   ARM: shmobile: Add mackerel to consolidated defconfig
>   ARM: shmobile: defconfig: Remove armadillo800eva defconfig
>   ARM: shmobile: defconfig: Remove kzm9d defconfig
>   ARM: shmobile: defconfig: Remove mackerel defconfig
> 
>  arch/arm/configs/armadillo800eva_defconfig |  153 -------------------------
>  arch/arm/configs/kzm9d_defconfig           |   88 ----------------
>  arch/arm/configs/mackerel_defconfig        |  156 -------------------------
>  arch/arm/configs/shmobile_defconfig        |   51 +++++----
>  4 files changed, 28 insertions(+), 420 deletions(-)
>  delete mode 100644 arch/arm/configs/armadillo800eva_defconfig
>  delete mode 100644 arch/arm/configs/kzm9d_defconfig
>  delete mode 100644 arch/arm/configs/mackerel_defconfig
-- 
Regards,

Laurent Pinchart



From arnd at arndb.de  Thu Apr  4 07:23:53 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 4 Apr 2013 11:23:53 +0000
Subject: [PATCH V2 1/2] ARM: bcm281xx: Add L2 cache enable code
In-Reply-To: <CAGFynZ9pE_B8KQNQvWsyn4Yz7tdd5VQwm=c76S-SPsGKNgu9ug@mail.gmail.com>
References: <1363299268-10506-1-git-send-email-csd@broadcom.com>
 <CAGFynZ9pE_B8KQNQvWsyn4Yz7tdd5VQwm=c76S-SPsGKNgu9ug@mail.gmail.com>
Message-ID: <201304041123.53852.arnd@arndb.de>

On Wednesday 03 April 2013, Christian Daudt wrote:
> any willing reviewers ?

Looks ok to me,

Acked-by: Arnd Bergmann <arnd at arndb.de>

but please when you reply to a longer email with a single sentence, don't
include a full quote of the original email, it just takes a lot of time
to scan through it. (I realize a lot of people do this unfortunately)

	Arnd


From santosh.shilimkar at ti.com  Thu Apr  4 07:32:39 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Thu, 4 Apr 2013 17:02:39 +0530
Subject: [PATCH v2 01/18] ARM: OMAP4+: PM: Consolidate MPU subsystem PM
 code for re-use
In-Reply-To: <87a9pfxuts.fsf@linaro.org>
References: <1364205910-32392-1-git-send-email-santosh.shilimkar@ti.com>
 <1364205910-32392-2-git-send-email-santosh.shilimkar@ti.com>
 <87a9pfxuts.fsf@linaro.org>
Message-ID: <515D64D7.7050403@ti.com>

On Thursday 04 April 2013 01:14 AM, Kevin Hilman wrote:
> Hi Santosh,
> 
> Santosh Shilimkar <santosh.shilimkar at ti.com> writes:
> 
>> OMAP5 and future OMAP based SOCs has backward compatible MPUSS
>> IP block with OMAP4. It's programming model is mostly similar.
>> Hence consolidate the OMAP MPUSS code so that it can be re-used
>> on OMAP5 and future SOCs.
>>
>> No functional change.
>>
>> Acked-by: Nishanth Menon <nm at ti.com>
>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
>> ---
>>  arch/arm/mach-omap2/omap-mpuss-lowpower.c |   65 ++++++++++++++++++++++++-----
>>  1 file changed, 54 insertions(+), 11 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
>> index d650f91..d9e4843 100644
>> --- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
>> +++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
>> @@ -71,10 +71,46 @@ struct omap4_cpu_pm_info {
>>  	void (*secondary_startup)(void);
>>  };
>>  
>> +/**
>> + * struct cpu_pm_ops - CPU pm operations
>> + * @finish_suspend:	CPU suspend finisher function pointer
>> + * @resume:		CPU resume function pointer
>> + * @scu_prepare:	CPU Snoop Control program function pointer
>> + *
>> + * Structure holds functions pointer for CPU low power operations like
>> + * suspend, resume and scu programming.
>> + */
>> +struct cpu_pm_ops {
>> +	int (*finish_suspend)(unsigned long cpu_state);
>> +	void (*resume)(void);
>> +	void (*scu_prepare)(unsigned int cpu_id, unsigned int cpu_state);
>> +};
>> +
>> +extern int omap4_finish_suspend(unsigned long cpu_state);
>> +extern void omap4_cpu_resume(void);
> 
> checkpatch should've yelled at you for adding externs to .c files.
> 
It does. I didn't see they were already in header file and considering
they were shared between asm and mpuss file, I just kept it that way.
i have seen many places in kernel for asm exports, this is being used
and hence kept it.

> Also, aren't these already defined in common.h anyways?
>
Yep. I will just drop above hunk.
 
> Otherwise, patch looks fine.
> 
I will take that as an ack then ?

Regards,
Santosh


From festevam at gmail.com  Thu Apr  4 07:33:41 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Thu, 4 Apr 2013 08:33:41 -0300
Subject: [PATCH 1/3] ARM: dts: imx28-evk: Use the standard gpio reset
 binding
In-Reply-To: <1365062329.4089.12.camel@pizza.hi.pengutronix.de>
References: <1365026474-3446-1-git-send-email-festevam@gmail.com>
 <1365062329.4089.12.camel@pizza.hi.pengutronix.de>
Message-ID: <CAOMZO5AtpT6nmnoFKQPCnp9sLnUnOC5AoEtg0+BmhQbBcp8hzw@mail.gmail.com>

Hi Philipp,

On Thu, Apr 4, 2013 at 4:58 AM, Philipp Zabel <p.zabel at pengutronix.de> wrote:
> Hi Fabio,
>
> Am Mittwoch, den 03.04.2013, 19:01 -0300 schrieb Fabio Estevam:
>> From: Fabio Estevam <fabio.estevam at freescale.com>
>>
>> Instead of using a custom binding for turning on a GPIO that activates the
>> panel, use the standard one.
>
> While this might fit well code wise, is a reset GPIO the right
> abstraction for those panel enable GPIOs?
>
> I guess the distinction between a GPIO that only holds the panel
> controller in reset and one that also enables power supplies internally
> can't be always made easily.

Would gpio-regulator binding fit better in the case a GPIO is needed
for activating the LCD backlight?

Regards,

Fabio Estevam


From linus.walleij at linaro.org  Thu Apr  4 07:37:23 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 4 Apr 2013 13:37:23 +0200
Subject: [PATCH 4/6] pinctrl: sunxi: add clock support
In-Reply-To: <515C9D25.3050407@free-electrons.com>
References: <1363962042-29536-1-git-send-email-emilio@elopez.com.ar>
 <1363962042-29536-5-git-send-email-emilio@elopez.com.ar>
 <CACRpkdbn9c_bAWUN8hTLkeidCnyZ=0nRQRBV39DMkK_0jBfoUQ@mail.gmail.com>
 <51535077.1050203@free-electrons.com>
 <CACRpkda80EKT2LbsBCOng=gkdtdd+vbYwkMPiFZUBx7z_aqY+A@mail.gmail.com>
 <515C9D25.3050407@free-electrons.com>
Message-ID: <CACRpkdacuu9JwY5waFwch=v2G6MkTZOO=DXismdsfr0Ttoi9=g@mail.gmail.com>

On Wed, Apr 3, 2013 at 11:20 PM, Maxime Ripard
<maxime.ripard at free-electrons.com> wrote:
> Le 03/04/2013 13:59, Linus Walleij a ?crit :
>> On Wed, Mar 27, 2013 at 9:03 PM, Maxime Ripard
>> <maxime.ripard at free-electrons.com> wrote:
>>
>>> Hi Linus,
>>> Le 27/03/2013 14:14, Linus Walleij a ?crit :
>>>> On Fri, Mar 22, 2013 at 3:20 PM, Emilio L?pez <emilio at elopez.com.ar> wrote:
>>>>
>>>>> For the port controller to work, we need to enable the apb0_pio gate.
>>>>> This commit adds the ability to enable one clock specified on the device
>>>>> tree to the pinctrl driver.
>>>>>
>>>>> Signed-off-by: Emilio L?pez <emilio at elopez.com.ar>
>>>>
>>>> Acked-by: Linus Walleij <linus.walleij at linaro.org>
>>>>
>>>> I guess you'll want to merge these as one series to some platform-specific
>>>> tree, tell me if you want it merged in the pinctrl tree.
>>>
>>> The easiest would probably be to merge this patch through your patch,
>>> with Mike taking the clock driver patches and me taking the dt ones,
>>> once we agree on the other patches.
>>
>> OK then, patch applied to the pinctrl tree, thanks!
>
> Ouch, the previous patches aren't applied yet by Mike, and we didn't
> have some comments from him about these patches, so I can't really say
> if the previous patches will get merge by 3.10 or not... So we will
> maybe end up with a broken pinctrl stuff.

This is usually why we keep patches together and merge whole series
into one tree, such as ARM SoC.

Well, maybe I'll drop it then ...

Yours,
Linus Walleij


From shawn.guo at linaro.org  Thu Apr  4 07:45:22 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Thu, 4 Apr 2013 19:45:22 +0800
Subject: [PATCH 1/6] pinctrl: add pinctrl driver for imx6dl
In-Reply-To: <CACRpkdaoVSHQg11E6W-hVyU6ud51yoQQ8-SrgnrmiO47JqJdrg@mail.gmail.com>
References: <1364913079-26039-1-git-send-email-shawn.guo@linaro.org>
 <1364913079-26039-2-git-send-email-shawn.guo@linaro.org>
 <CACRpkdaoVSHQg11E6W-hVyU6ud51yoQQ8-SrgnrmiO47JqJdrg@mail.gmail.com>
Message-ID: <20130404114520.GB21790@S2101-09.ap.freescale.net>

On Wed, Apr 03, 2013 at 06:39:34PM +0200, Linus Walleij wrote:
> On Tue, Apr 2, 2013 at 4:31 PM, Shawn Guo <shawn.guo at linaro.org> wrote:
> 
> > The imx6dl is a derivative of imx6q with very limited difference.  These
> > two SoCs are so compatible that they can be handled as one platform in
> > software.  That said, we will not have target SOC_IMX6DL but just
> > reusing SOC_IMX6Q.   That's why the pinctrl-imx6dl driver is added here
> > with symbol PINCTRL_IMX6Q controlling the build of it.
> >
> > Signed-off-by: Shawn Guo <shawn.guo at linaro.org>
> 
> OK Acked-by: Linus Walleij <linus.walleij at linaro.org>
> 
> Also for patch 2.
> 
Thanks, Linus.

> Will you take this through the Freescale tree?
> 
Yes, I will.

Shawn



From santosh.shilimkar at ti.com  Thu Apr  4 07:51:51 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Thu, 4 Apr 2013 17:21:51 +0530
Subject: [PATCH v2 03/18] ARM: OMAP4+: PM: Consolidate and use OMAP4 PM
 code for OMAP5
In-Reply-To: <87li8zwel4.fsf@linaro.org>
References: <1364205910-32392-1-git-send-email-santosh.shilimkar@ti.com>
 <1364205910-32392-4-git-send-email-santosh.shilimkar@ti.com>
 <87li8zwel4.fsf@linaro.org>
Message-ID: <515D6957.5000802@ti.com>

On Thursday 04 April 2013 01:50 AM, Kevin Hilman wrote:
> Santosh Shilimkar <santosh.shilimkar at ti.com> writes:
> 
>> OMAP5 has backward compatible PRCM block and it's programming
>> model is mostly similar to OMAP4. Same is going to be maintained
>> for future OMAP4 based SOCs. Hence consolidate the OMAP4 power
>> management code so that it can be re-used on OMAP5 and later devices.
>>
>> With consolidated code, let basic power management code build
>> for OMAP5 devices. While at it, update the kernel-doc for omap4_pm_init().
>>
>> Acked-by: Nishanth Menon <nm at ti.com>
>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
>> ---
>>  arch/arm/mach-omap2/Makefile                       |    9 ++--
>>  arch/arm/mach-omap2/{pm44xx.c => pm_omap4plus.c}   |   54 ++++++++++++++++----
>>  .../mach-omap2/{sleep44xx.S => sleep_omap4plus.S}  |    0
>>  3 files changed, 49 insertions(+), 14 deletions(-)
>>  rename arch/arm/mach-omap2/{pm44xx.c => pm_omap4plus.c} (86%)
>>  rename arch/arm/mach-omap2/{sleep44xx.S => sleep_omap4plus.S} (100%)
>>

[..]

>> diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm_omap4plus.c
>> similarity index 86%
>> rename from arch/arm/mach-omap2/pm44xx.c
>> rename to arch/arm/mach-omap2/pm_omap4plus.c
>> index 5ba6d88..e920c34 100644
>> --- a/arch/arm/mach-omap2/pm44xx.c
>> +++ b/arch/arm/mach-omap2/pm_omap4plus.c
>> @@ -1,7 +1,7 @@
>>  /*
>> - * OMAP4 Power Management Routines
>> + * OMAP4PLUS Power Management Routines
> 
> nit: OMAP4+  (you only need to spell out "plus" in the filename.
> 
OK. I will replace '+' instead of 'PLUS' in rest of the places.
>>   *
>> - * Copyright (C) 2010-2011 Texas Instruments, Inc.
>> + * Copyright (C) 2010-2013 Texas Instruments, Inc.
>>   * Rajendra Nayak <rnayak at ti.com>
>>   * Santosh Shilimkar <santosh.shilimkar at ti.com>
>>   *
>> @@ -135,16 +135,16 @@ static void omap_default_idle(void)
>>  }
>>  
>>  /**
>> - * omap4_pm_init - Init routine for OMAP4 PM
>> + * omap4_init_static_deps - Add OMAP4 static dependencies
>>   *
>> - * Initializes all powerdomain and clockdomain target states
>> - * and all PRCM settings.
>> + * Add needed static clockdomain dependencies on OMAP4 devices.
>> + * Return: 0 on success or 'err' on failures
>>   */
>> -int __init omap4_pm_init(void)
>> +static inline int omap4_init_static_deps(void)
> 
> You dropped the __init here, but it's still only called from another
> __init function, so I suspect it should stay.
> 
Yep. Will keep that in next version.

Regards,
Santosh



From festevam at gmail.com  Thu Apr  4 07:50:29 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Thu, 4 Apr 2013 08:50:29 -0300
Subject: [PATCH 1/3] ARM: dts: imx28-evk: Use the standard gpio reset
 binding
In-Reply-To: <CAOMZO5AtpT6nmnoFKQPCnp9sLnUnOC5AoEtg0+BmhQbBcp8hzw@mail.gmail.com>
References: <1365026474-3446-1-git-send-email-festevam@gmail.com>
 <1365062329.4089.12.camel@pizza.hi.pengutronix.de>
 <CAOMZO5AtpT6nmnoFKQPCnp9sLnUnOC5AoEtg0+BmhQbBcp8hzw@mail.gmail.com>
Message-ID: <CAOMZO5Bm0bu=75dC4hOd1MZ4w3So_7RU4ufsLjHJBi3KL3YeEA@mail.gmail.com>

On Thu, Apr 4, 2013 at 8:33 AM, Fabio Estevam <festevam at gmail.com> wrote:
> Hi Philipp,
>
> On Thu, Apr 4, 2013 at 4:58 AM, Philipp Zabel <p.zabel at pengutronix.de> wrote:
>> Hi Fabio,
>>
>> Am Mittwoch, den 03.04.2013, 19:01 -0300 schrieb Fabio Estevam:
>>> From: Fabio Estevam <fabio.estevam at freescale.com>
>>>
>>> Instead of using a custom binding for turning on a GPIO that activates the
>>> panel, use the standard one.
>>
>> While this might fit well code wise, is a reset GPIO the right
>> abstraction for those panel enable GPIOs?
>>
>> I guess the distinction between a GPIO that only holds the panel
>> controller in reset and one that also enables power supplies internally
>> can't be always made easily.
>
> Would gpio-regulator binding fit better in the case a GPIO is needed
> for activating the LCD backlight?

It seems that "regulator-fixed" seems to fit better for this purpose.


From shawn.guo at linaro.org  Thu Apr  4 07:52:13 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Thu, 4 Apr 2013 19:52:13 +0800
Subject: [PATCH] ARM: imx: do not bring up unavailable cores
In-Reply-To: <515C280E.7000500@gmail.com>
References: <1364913146-26084-1-git-send-email-shawn.guo@linaro.org>
 <20130402151715.GB6608@mudshark.cambridge.arm.com>
 <20130403021348.GK24039@S2101-09.ap.freescale.net>
 <CAOMZO5AJjz4Z68GxkeCM3rH9p9-z6jaOM35MBSjN-UE_Dk4=eg@mail.gmail.com>
 <20130403024719.GF27148@S2101-09.ap.freescale.net>
 <CAOMZO5C5uVDWi1vXTeyQF5P8N=ARHvW-qMknVeyG4zY85KcEkw@mail.gmail.com>
 <515C280E.7000500@gmail.com>
Message-ID: <20130404115211.GC21790@S2101-09.ap.freescale.net>

On Wed, Apr 03, 2013 at 08:01:02AM -0500, Rob Herring wrote:
> On 04/02/2013 10:18 PM, Fabio Estevam wrote:
> > On Tue, Apr 2, 2013 at 11:47 PM, Shawn Guo <shawn.guo at linaro.org> wrote:
> > 
> >> Ah, great.  I haven't checked the U-Boot code for some time.  But does
> >> U-Boot remove cpu nodes of those unavailable cores from device tree
> >> before passing it to kernel?
> > 
> > No, it just uses the information from the SCU to print the name of the
> > mx6 variant on boot.
> 
> It is quite common and the correct place IMHO to do this dtb fixup in
> u-boot.

Yes, I agree.

> You can just add 'status = "disabled";' properties. I'm not sure
> that the kernel is checking the status though.
> 
No, I do not think that kernel is current checking property 'status'.

> Reading the core count from the SCU is the only reason the SCU needs to
> be statically mapped, so if you remove that you can remove the static
> mapping.

Yea, that's something desirable.  We can do that after both u-boot and
kernel get ready to manipulate 'status' property of cpu node.

Shawn



From santosh.shilimkar at ti.com  Thu Apr  4 07:55:31 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Thu, 4 Apr 2013 17:25:31 +0530
Subject: [PATCH v2 03/18] ARM: OMAP4+: PM: Consolidate and use OMAP4 PM
 code for OMAP5
In-Reply-To: <515D6957.5000802@ti.com>
References: <1364205910-32392-1-git-send-email-santosh.shilimkar@ti.com>
 <1364205910-32392-4-git-send-email-santosh.shilimkar@ti.com>
 <87li8zwel4.fsf@linaro.org> <515D6957.5000802@ti.com>
Message-ID: <515D6A33.1050405@ti.com>

On Thursday 04 April 2013 05:21 PM, Santosh Shilimkar wrote:
> On Thursday 04 April 2013 01:50 AM, Kevin Hilman wrote:
>> Santosh Shilimkar <santosh.shilimkar at ti.com> writes:
>>
>>> OMAP5 has backward compatible PRCM block and it's programming
>>> model is mostly similar to OMAP4. Same is going to be maintained
>>> for future OMAP4 based SOCs. Hence consolidate the OMAP4 power
>>> management code so that it can be re-used on OMAP5 and later devices.
>>>
>>> With consolidated code, let basic power management code build
>>> for OMAP5 devices. While at it, update the kernel-doc for omap4_pm_init().
>>>
>>> Acked-by: Nishanth Menon <nm at ti.com>
>>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
>>> ---
>>>  arch/arm/mach-omap2/Makefile                       |    9 ++--
>>>  arch/arm/mach-omap2/{pm44xx.c => pm_omap4plus.c}   |   54 ++++++++++++++++----
>>>  .../mach-omap2/{sleep44xx.S => sleep_omap4plus.S}  |    0
>>>  3 files changed, 49 insertions(+), 14 deletions(-)
>>>  rename arch/arm/mach-omap2/{pm44xx.c => pm_omap4plus.c} (86%)
>>>  rename arch/arm/mach-omap2/{sleep44xx.S => sleep_omap4plus.S} (100%)
>>>
> 
> [..]

>>>  
>>>  /**
>>> - * omap4_pm_init - Init routine for OMAP4 PM
>>> + * omap4_init_static_deps - Add OMAP4 static dependencies
>>>   *
>>> - * Initializes all powerdomain and clockdomain target states
>>> - * and all PRCM settings.
>>> + * Add needed static clockdomain dependencies on OMAP4 devices.
>>> + * Return: 0 on success or 'err' on failures
>>>   */
>>> -int __init omap4_pm_init(void)
>>> +static inline int omap4_init_static_deps(void)
>>
>> You dropped the __init here, but it's still only called from another
>> __init function, so I suspect it should stay.
>>
> Yep. Will keep that in next version.
> 
I was too quick to respond. The function is "static inline" so
there is no need to add __init here.

Regards,
Santosh



From santosh.shilimkar at ti.com  Thu Apr  4 08:02:49 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Thu, 4 Apr 2013 17:32:49 +0530
Subject: [PATCH v2 05/18] ARM: OMAP5: PM: Enables ES2 PM mode by default
In-Reply-To: <876203wedp.fsf@linaro.org>
References: <1364205910-32392-1-git-send-email-santosh.shilimkar@ti.com>
 <1364205910-32392-6-git-send-email-santosh.shilimkar@ti.com>
 <876203wedp.fsf@linaro.org>
Message-ID: <515D6BE9.2050009@ti.com>

On Thursday 04 April 2013 01:55 AM, Kevin Hilman wrote:
> Santosh Shilimkar <santosh.shilimkar at ti.com> writes:
> 
>> Enables MPUSS ES2 power management mode using ES2_PM_MODE in
>> AMBA_IF_MODE register.
>>
>> 0x0: ES1 behavior, CPU cores would enter and exit OFF mode together. Broken
> 
> What is broken?
> 
Should have added clarification here. Sorry. Changelog is updated as below

0x0: ES1 behavior, CPU cores would enter and exit OFF mode together.
0x1: ES2 behavior, CPU cores are allowed to enter/exit OFF mode independently.

ES1.0 CPUx OFF mode behavior never worked and after analysis by design team,
it was declared as a broken hardware feature. That lead to addition of
ES2.0 behavior which works.

>> 0x1: ES2 behavior, CPU cores are allowed to enter/exit OFF mode independently.
>>
>> The AMBA_IF_MODE register value is stored on SAR RAM and restored by
>> ROM code.
>>
>> Acked-by: Nishanth Menon <nm at ti.com>
>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
>> ---

[..]

>> diff --git a/arch/arm/mach-omap2/omap-wakeupgen.c b/arch/arm/mach-omap2/omap-wakeupgen.c
>> index f8bb3b9..8bcaa8c 100644
>> --- a/arch/arm/mach-omap2/omap-wakeupgen.c
>> +++ b/arch/arm/mach-omap2/omap-wakeupgen.c
>> @@ -42,6 +42,7 @@
>>  #define CPU1_ID			0x1
>>  #define OMAP4_NR_BANKS		4
>>  #define OMAP4_NR_IRQS		128
>> +#define OMAP5_AMBA_IF_PM_MODE	(1 << 5)
> 
> nit: use BIT()
> 
Ok.

Regards,
santosh



From santosh.shilimkar at ti.com  Thu Apr  4 08:08:50 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Thu, 4 Apr 2013 17:38:50 +0530
Subject: [PATCH v2 06/18] ARM: OMAP5: PM: Enable Mercury retention mode
 on CPUx powerdomains
In-Reply-To: <87k3ojuziu.fsf@linaro.org>
References: <1364205910-32392-1-git-send-email-santosh.shilimkar@ti.com>
 <1364205910-32392-7-git-send-email-santosh.shilimkar@ti.com>
 <87k3ojuziu.fsf@linaro.org>
Message-ID: <515D6D52.50902@ti.com>

On Thursday 04 April 2013 02:01 AM, Kevin Hilman wrote:
> Santosh Shilimkar <santosh.shilimkar at ti.com> writes:
> 
>> In addition to the standard power-management technique, the OMAP5
>> MPU subsystem also employs an SR3-APG (mercury) power management
>> technology to reduce leakage.
>>
>> It allows for full logic and memories retention on MPU_C0 and MPU_C1 and
>> is controlled by the PRCM_MPU.
>>
>> Acked-by: Nishanth Menon <nm at ti.com>
>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
>> ---
>>  arch/arm/mach-omap2/omap-mpuss-lowpower.c |   27 +++++++++++++++++++++++++++
>>  1 file changed, 27 insertions(+)
>>
>> diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
>> index b1441b1..d390d18 100644
>> --- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
>> +++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
>> @@ -62,6 +62,10 @@
>>  #include "prm44xx.h"
>>  #include "prm-regbits-44xx.h"
>>  
>> +/* Add defines needed for mercury mode. Refer MPU's PRM_PSCON_COUNT */
>> +#define PRM_PSCON_HG_EN		(1 << 24)
>> +#define PRM_PSCON_HG_RAMPUP	(1 << 25)
> 
> nit: use BIT()
> 
ok

>>  #ifdef CONFIG_SMP
>>  
>>  struct omap4_cpu_pm_info {
>> @@ -337,6 +341,28 @@ int __cpuinit omap4_hotplug_cpu(unsigned int cpu, unsigned int power_state)
>>  	return 0;
>>  }
>>  
>> +/**
>> + * enable_mercury_retention_mode: Enable OMAP5 mercury retention feature
>> + *
>> + * OMAP5 devices supports  SR3-APG (mercury) power management technology to
>> + * reduce leakage. It allows for full logic and memories retention on
>> + * MPU_C0 and MPU_C1 and is controlled by the PRCM_MPU. The function enable
>> + * the mercury retention feature.
>> + */
>> +static void enable_mercury_retention_mode(void)
> 
> __init ?
> 
yep.

> This is very OMAP5 specific (unless you generalize the offsets used) so
> should this have omap5_ prefix?
> 
Agree.

> 
>> +{
>> +	u32 reg;
>> +
>> +	/*
>> +	 * To enable mercury mode, both HG_EN and HG_RAMPUP needs to be
>> +	 * enabled from PRM_PSCON_COUNT register.
>> +	 */
>> +	reg = omap4_prcm_mpu_read_inst_reg(OMAP54XX_PRCM_MPU_DEVICE_INST,
>> +			OMAP54XX_PRCM_MPU_PRM_PSCON_COUNT_OFFSET);
>> +	reg |= PRM_PSCON_HG_EN | PRM_PSCON_HG_RAMPUP;
>> +	omap4_prcm_mpu_write_inst_reg(reg, OMAP54XX_PRCM_MPU_DEVICE_INST,
>> +			OMAP54XX_PRCM_MPU_PRM_PSCON_COUNT_OFFSET);
> 
> nit: when I see 'reg', I expect it to be a register/offset.  But this is
> a register value.  Maybe use 'val' instead as you've done elsewhere in
> this series.
> 
I generally use 'offset' if it is offset and 'reg' for actual register read.
Anyways, I have changed it to 'val' now.

Regards,
Santosh



From santosh.shilimkar at ti.com  Thu Apr  4 08:28:13 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Thu, 4 Apr 2013 17:58:13 +0530
Subject: [PATCH v2 07/18] ARM: OMAP5: Add init_late() hook to enable pm
 initialization
In-Reply-To: <87eheruzfx.fsf@linaro.org>
References: <1364205910-32392-1-git-send-email-santosh.shilimkar@ti.com>
 <1364205910-32392-8-git-send-email-santosh.shilimkar@ti.com>
 <87eheruzfx.fsf@linaro.org>
Message-ID: <515D71DD.7050206@ti.com>

On Thursday 04 April 2013 02:03 AM, Kevin Hilman wrote:
> Santosh Shilimkar <santosh.shilimkar at ti.com> writes:
> 
>> With consolidated code, now we can add the .init_late hook for
>> OMAP5 to enable power management and mux initialization.
>>
>> Acked-by: Nishanth Menon <nm at ti.com>
>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
>> ---
[..]

>> diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
>> index e948a39..cdd1264 100644
>> --- a/arch/arm/mach-omap2/io.c
>> +++ b/arch/arm/mach-omap2/io.c
>> @@ -636,6 +636,14 @@ void __init omap5_init_early(void)
>>  	omap_hwmod_init_postsetup();
>>  
>>  }
>> +
>> +void __init omap5_init_late(void)
>> +{
>> +	omap_mux_late_init();
>> +	omap2_common_pm_late_init();
>> +	omap4_pm_init();
>> +	omap2_clk_enable_autoidle_all();
>> +}
> 
> Since you're consolidating, why not rename omap4430_init_late to
> omap4plus_init_late and use it for both OMAP4 and OMAP5?
> 
Now re-looking again, I need to drop omap_mux_late_init()
since OMAP5 is DT only. And hence OMAP5 needs to be a
separate hook at least for now.

Regards,
Santosh



From marc.zyngier at arm.com  Thu Apr  4 08:35:17 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu, 04 Apr 2013 13:35:17 +0100
Subject: [PATCH 1/7] ARM: KVM: simplify HYP mapping population
In-Reply-To: <20130403231344.GA29227@gmail.com>
References: <1364909115-3810-1-git-send-email-marc.zyngier@arm.com>
 <1364909115-3810-2-git-send-email-marc.zyngier@arm.com>
 <20130403231344.GA29227@gmail.com>
Message-ID: <515D7385.5050403@arm.com>

On 04/04/13 00:13, Christoffer Dall wrote:
> On Tue, Apr 02, 2013 at 02:25:09PM +0100, Marc Zyngier wrote:
>> The way we populate HYP mappings is a bit convoluted, to say the least.
>> Passing a pointer around to keep track of the current PFN is quite
>> odd, and we end-up having two different PTE accessors for no good
>> reason.
>>
>> Simplify the whole thing by unifying the two PTE accessors, passing
>> a pgprot_t around, and moving the various validity checks to the
>> upper layers.
>>
>> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
>> ---
>>  arch/arm/kvm/mmu.c | 100 ++++++++++++++++++++++-------------------------------
>>  1 file changed, 41 insertions(+), 59 deletions(-)
>>
>> diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
>> index 2f12e40..24811d1 100644
>> --- a/arch/arm/kvm/mmu.c
>> +++ b/arch/arm/kvm/mmu.c
>> @@ -125,54 +125,34 @@ void free_hyp_pmds(void)
>>  }
>>  
>>  static void create_hyp_pte_mappings(pmd_t *pmd, unsigned long start,
>> -				    unsigned long end)
>> +				    unsigned long end, unsigned long pfn,
>> +				    pgprot_t prot)
>>  {
>>  	pte_t *pte;
>>  	unsigned long addr;
>> -	struct page *page;
>>  
>> -	for (addr = start & PAGE_MASK; addr < end; addr += PAGE_SIZE) {
>> -		unsigned long hyp_addr = KERN_TO_HYP(addr);
>> -
>> -		pte = pte_offset_kernel(pmd, hyp_addr);
>> -		BUG_ON(!virt_addr_valid(addr));
>> -		page = virt_to_page(addr);
>> -		kvm_set_pte(pte, mk_pte(page, PAGE_HYP));
>> -	}
>> -}
>> -
>> -static void create_hyp_io_pte_mappings(pmd_t *pmd, unsigned long start,
>> -				       unsigned long end,
>> -				       unsigned long *pfn_base)
>> -{
>> -	pte_t *pte;
>> -	unsigned long addr;
>> -
>> -	for (addr = start & PAGE_MASK; addr < end; addr += PAGE_SIZE) {
>> -		unsigned long hyp_addr = KERN_TO_HYP(addr);
>> -
>> -		pte = pte_offset_kernel(pmd, hyp_addr);
>> -		BUG_ON(pfn_valid(*pfn_base));
>> -		kvm_set_pte(pte, pfn_pte(*pfn_base, PAGE_HYP_DEVICE));
>> -		(*pfn_base)++;
>> +	for (addr = start; addr < end; addr += PAGE_SIZE) {
>> +		pte = pte_offset_kernel(pmd, addr);
>> +		kvm_set_pte(pte, pfn_pte(pfn, prot));
>> +		pfn++;
>>  	}
>>  }
>>  
>>  static int create_hyp_pmd_mappings(pud_t *pud, unsigned long start,
>> -				   unsigned long end, unsigned long *pfn_base)
>> +				   unsigned long end, unsigned long pfn,
>> +				   pgprot_t prot)
>>  {
>>  	pmd_t *pmd;
>>  	pte_t *pte;
>>  	unsigned long addr, next;
>>  
>>  	for (addr = start; addr < end; addr = next) {
>> -		unsigned long hyp_addr = KERN_TO_HYP(addr);
>> -		pmd = pmd_offset(pud, hyp_addr);
>> +		pmd = pmd_offset(pud, addr);
>>  
>>  		BUG_ON(pmd_sect(*pmd));
>>  
>>  		if (pmd_none(*pmd)) {
>> -			pte = pte_alloc_one_kernel(NULL, hyp_addr);
>> +			pte = pte_alloc_one_kernel(NULL, addr);
>>  			if (!pte) {
>>  				kvm_err("Cannot allocate Hyp pte\n");
>>  				return -ENOMEM;
>> @@ -182,25 +162,17 @@ static int create_hyp_pmd_mappings(pud_t *pud, unsigned long start,
>>  
>>  		next = pmd_addr_end(addr, end);
>>  
>> -		/*
>> -		 * If pfn_base is NULL, we map kernel pages into HYP with the
>> -		 * virtual address. Otherwise, this is considered an I/O
>> -		 * mapping and we map the physical region starting at
>> -		 * *pfn_base to [start, end[.
>> -		 */
>> -		if (!pfn_base)
>> -			create_hyp_pte_mappings(pmd, addr, next);
>> -		else
>> -			create_hyp_io_pte_mappings(pmd, addr, next, pfn_base);
>> +		create_hyp_pte_mappings(pmd, addr, next, pfn, prot);
>> +		pfn += (next - addr) >> PAGE_SHIFT;
> 
> so this scheme always assumes a physically contiguous memory reason,
> and I wasn't sure if we ever wanted to support mapping vmalloc'ed
> regions into Hyp mode, which is why I wrote the code the way it was
> (which goes to your "for no good reason" comment above).

So let's look at what we're actually mapping:
- kernel code/kmalloc-ed data: this is always physically contiguous
- MMIO: While this is mapped in the vmalloc region, this is actually
physically contiguous.

> I'm fine with assuming that this only works for contiguous regions, but
> I think it deserves a line in the comments on the exported functions
> (the non-IO one anyway).

Sure, I'll add that.

>>  	}
>>  
>>  	return 0;
>>  }
>>  
>> -static int __create_hyp_mappings(void *from, void *to, unsigned long *pfn_base)
>> +static int __create_hyp_mappings(pgd_t *pgdp,
>> +				 unsigned long start, unsigned long end,
>> +				 unsigned long pfn, pgprot_t prot)
>>  {
>> -	unsigned long start = (unsigned long)from;
>> -	unsigned long end = (unsigned long)to;
>>  	pgd_t *pgd;
>>  	pud_t *pud;
>>  	pmd_t *pmd;
>> @@ -209,21 +181,14 @@ static int __create_hyp_mappings(void *from, void *to, unsigned long *pfn_base)
>>  
>>  	if (start >= end)
>>  		return -EINVAL;
>> -	/* Check for a valid kernel memory mapping */
>> -	if (!pfn_base && (!virt_addr_valid(from) || !virt_addr_valid(to - 1)))
>> -		return -EINVAL;
>> -	/* Check for a valid kernel IO mapping */
>> -	if (pfn_base && (!is_vmalloc_addr(from) || !is_vmalloc_addr(to - 1)))
>> -		return -EINVAL;
>>  
>>  	mutex_lock(&kvm_hyp_pgd_mutex);
>> -	for (addr = start; addr < end; addr = next) {
>> -		unsigned long hyp_addr = KERN_TO_HYP(addr);
>> -		pgd = hyp_pgd + pgd_index(hyp_addr);
>> -		pud = pud_offset(pgd, hyp_addr);
>> +	for (addr = start & PAGE_MASK; addr < end; addr = next) {
>> +		pgd = pgdp + pgd_index(addr);
>> +		pud = pud_offset(pgd, addr);
>>  
>>  		if (pud_none_or_clear_bad(pud)) {
>> -			pmd = pmd_alloc_one(NULL, hyp_addr);
>> +			pmd = pmd_alloc_one(NULL, addr);
>>  			if (!pmd) {
>>  				kvm_err("Cannot allocate Hyp pmd\n");
>>  				err = -ENOMEM;
>> @@ -233,9 +198,10 @@ static int __create_hyp_mappings(void *from, void *to, unsigned long *pfn_base)
>>  		}
>>  
>>  		next = pgd_addr_end(addr, end);
>> -		err = create_hyp_pmd_mappings(pud, addr, next, pfn_base);
>> +		err = create_hyp_pmd_mappings(pud, addr, next, pfn, prot);
>>  		if (err)
>>  			goto out;
>> +		pfn += (next - addr) >> PAGE_SHIFT;
> 
> nit: consider passing a pointer to pfn instead?  Not sure if it's nicer.

That's what we had before, and it wasn't that nice...

>>  	}
>>  out:
>>  	mutex_unlock(&kvm_hyp_pgd_mutex);
>> @@ -255,7 +221,16 @@ out:
>>   */
>>  int create_hyp_mappings(void *from, void *to)
>>  {
>> -	return __create_hyp_mappings(from, to, NULL);
>> +	unsigned long phys_addr = virt_to_phys(from);
>> +	unsigned long start = KERN_TO_HYP((unsigned long)from);
>> +	unsigned long end = KERN_TO_HYP((unsigned long)to);
>> +
>> +	/* Check for a valid kernel memory mapping */
>> +	if (!virt_addr_valid(from) || !virt_addr_valid(to - 1))
>> +		return -EINVAL;
>> +
>> +	return __create_hyp_mappings(hyp_pgd, start, end,
>> +				     __phys_to_pfn(phys_addr), PAGE_HYP);
>>  }
>>  
>>  /**
>> @@ -267,10 +242,17 @@ int create_hyp_mappings(void *from, void *to)
>>   * The resulting HYP VA is the same as the kernel VA, modulo
>>   * HYP_PAGE_OFFSET.
>>   */
>> -int create_hyp_io_mappings(void *from, void *to, phys_addr_t addr)
>> +int create_hyp_io_mappings(void *from, void *to, phys_addr_t phys_addr)
> 
> nit: change the parameter documentation name as well.

Sure.

> 
>>  {
>> -	unsigned long pfn = __phys_to_pfn(addr);
>> -	return __create_hyp_mappings(from, to, &pfn);
>> +	unsigned long start = KERN_TO_HYP((unsigned long)from);
>> +	unsigned long end = KERN_TO_HYP((unsigned long)to);
>> +
>> +	/* Check for a valid kernel IO mapping */
>> +	if (!is_vmalloc_addr(from) || !is_vmalloc_addr(to - 1))
>> +		return -EINVAL;
>> +
>> +	return __create_hyp_mappings(hyp_pgd, start, end,
>> +				     __phys_to_pfn(phys_addr), PAGE_HYP_DEVICE);
>>  }
>>  
>>  /**
>> -- 
>> 1.8.1.4
>>
> 
> If the contigous thing is not a concern, then I'm happy about the
> simplification.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...



From marc.zyngier at arm.com  Thu Apr  4 08:40:18 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu, 04 Apr 2013 13:40:18 +0100
Subject: [PATCH 2/7] ARM: KVM: fix HYP mapping limitations around zero
In-Reply-To: <20130403231409.GB29227@gmail.com>
References: <1364909115-3810-1-git-send-email-marc.zyngier@arm.com>
 <1364909115-3810-3-git-send-email-marc.zyngier@arm.com>
 <20130403231409.GB29227@gmail.com>
Message-ID: <515D74B2.5030509@arm.com>

On 04/04/13 00:14, Christoffer Dall wrote:
> On Tue, Apr 02, 2013 at 02:25:10PM +0100, Marc Zyngier wrote:
>> The current code for creating HYP mapping doesn't like to wrap
>> around zero, which prevents from mapping anything into the last
>> page of the virtual address space.
>>
>> It doesn't take much effort to remove this limitation, making
>> the code more consistent with the rest of the kernel in the process.
> 
> This is quite funny, the code used to behave like this, but
> reviewers said that this was old fashioned mm-style code that was
> unwanted and wrapping around zero should be avoided for all costs :)

My original attempt at this series was using the very last page of the
memory, and it took me a while to notice that the code couldn't map
anything in the last page.

Just for this reason, the code needed to be fixed.

> In any case, I welcome the familiarity.

Amen.

	M.
-- 
Jazz is not dead. It just smells funny...



From marc.zyngier at arm.com  Thu Apr  4 08:52:02 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu, 04 Apr 2013 13:52:02 +0100
Subject: [PATCH 6/7] ARM: KVM: switch to a dual-step HYP init code
In-Reply-To: <20130403231544.GF29227@gmail.com>
References: <1364909115-3810-1-git-send-email-marc.zyngier@arm.com>
 <1364909115-3810-7-git-send-email-marc.zyngier@arm.com>
 <20130403231544.GF29227@gmail.com>
Message-ID: <515D7772.9020106@arm.com>

On 04/04/13 00:15, Christoffer Dall wrote:
> On Tue, Apr 02, 2013 at 02:25:14PM +0100, Marc Zyngier wrote:
>> Our HYP init code suffers from two major design issues:
>> - it cannot support CPU hotplug, as we tear down the idmap very early
>> - it cannot perform a TLB invalidation when switching from init to
>>   runtime mappings, as pages are manipulated from PL1 exclusively
>>
>> The hotplug problem mandates that we keep two sets of page tables
>> (boot and runtime). The TLB problem mandates that we're able to
>> transition from one PGD to another while in HYP, invalidating the TLBs
>> in the process.
>>
>> To be able to do this, we need to share a page between the two page
>> tables. A page that will have the same VA in both configurations. All we
>> need is a VA that has the following properties:
>> - This VA can't be used to represent a kernel mapping.
>> - This VA will not conflict with the physical address of the kernel text
>>
>> The vectors page seems to satisfy this requirement:
>> - The kernel never maps anything else there
>> - The kernel text being copied at the beginning of the physical memory,
>>   it is unlikely to use the last 64kB (I doubt we'll ever support KVM
>>   on a system with something like 4MB of RAM, but patches are very
>>   welcome).
>>
>> Let's call this VA the trampoline VA.
>>
>> Now, we map our init page at 3 locations:
>> - idmap in the boot pgd
>> - trampoline VA in the boot pgd
>> - trampoline VA in the runtime pgd
>>
>> The init scenario is now the following:
>> - We jump in HYP with four parameters: boot HYP pgd, runtime HYP pgd,
>>   runtime stack, runtime vectors
>> - Enable the MMU with the boot pgd
>> - Jump to a target into the trampoline page (remember, this is the same
>>   physical page!)
>> - Now switch to the runtime pgd (same VA, and still the same physical
>>   page!)
>> - Invalidate TLBs
>> - Set stack and vectors
>> - Profit! (or eret, if you only care about the code).
> 
> So I'm going to do my usual commenting routine. Was it an idea to insert
> this commit text (which I really liked by the way!) into init.S where
> the current comment is a little lacking giving the massive complexity
> this is turning into, madness?

Will do.

[...]

>> diff --git a/arch/arm/kvm/init.S b/arch/arm/kvm/init.S
>> index 35a463f..b2c6967 100644
>> --- a/arch/arm/kvm/init.S
>> +++ b/arch/arm/kvm/init.S
>> @@ -21,6 +21,7 @@
>>  #include <asm/asm-offsets.h>
>>  #include <asm/kvm_asm.h>
>>  #include <asm/kvm_arm.h>
>> +#include <asm/kvm_mmu.h>
>>
>>  /********************************************************************
>>   * Hypervisor initialization
>> @@ -47,6 +48,9 @@ __kvm_hyp_init:
>>       W(b)    .
>>
>>  __do_hyp_init:
>> +     cmp     r2, #0                  @ We have a SP?
>> +     bne     phase2                  @ Yes, second stage init
>> +
>>       @ Set the HTTBR to point to the hypervisor PGD pointer passed
>>       mcrr    p15, 4, r0, r1, c2
>>
>> @@ -96,14 +100,35 @@ __do_hyp_init:
>>       orr     r0, r0, r1
>>       isb
>>       mcr     p15, 4, r0, c1, c0, 0   @ HSCR
>> -     isb
>>
>> -     @ Set stack pointer and return to the kernel
>> +     eret
> 
> Could you add some comment here to indicate we're done with phase1, it
> seems like this eret should not go unnoticed by casual readers (ok, they
> shouldn't read this code casually, but anyway..., it will make me sleep
> better)

Sure, no problem.

	M.
-- 
Jazz is not dead. It just smells funny...



From shawn.guo at linaro.org  Thu Apr  4 08:53:33 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Thu, 4 Apr 2013 20:53:33 +0800
Subject: [PATCH v2] ARM: dts: Add initial support for Wandboard Dual-Lite
In-Reply-To: <1364992156-22852-1-git-send-email-fabio.estevam@freescale.com>
References: <1364992156-22852-1-git-send-email-fabio.estevam@freescale.com>
Message-ID: <20130404125331.GE21790@S2101-09.ap.freescale.net>

On Wed, Apr 03, 2013 at 09:29:16AM -0300, Fabio Estevam wrote:
> Wandboard is a development board that has two variants: one version based
> on mx6 dual lite and another one based on mx6 solo.
> 
> For more details about Wandboard, please refer to: http://www.wandboard.org/
> 
> Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>

Applied, thanks.



From viresh.kumar at linaro.org  Thu Apr  4 08:54:09 2013
From: viresh.kumar at linaro.org (Viresh Kumar)
Date: Thu,  4 Apr 2013 18:24:09 +0530
Subject: [PATCH 01/18] cpufreq: ARM: Arrange drivers in alphabetical order
In-Reply-To: <cover.1365079581.git.viresh.kumar@linaro.org>
References: <cover.1365079581.git.viresh.kumar@linaro.org>
Message-ID: <216bbdfc94c40cb1b4e0dd6544ad27001de1c519.1365079581.git.viresh.kumar@linaro.org>

Normally we keep drivers in alphabetical inside Kconfig and Makefile and over
time this was broken for ARM cpufreq drivers. Fix it.

Cc: linux-arm-kernel at lists.infradead.org
Signed-off-by: Viresh Kumar <viresh.kumar at linaro.org>
Acked-by: Stephen Warren <swarren at nvidia.com>
Tested-by: Stephen Warren <swarren at nvidia.com>
Acked-by: Arnd Bergmann <arnd at arndb.de>
---
 drivers/cpufreq/Kconfig.arm | 116 ++++++++++++++++++++++----------------------
 drivers/cpufreq/Makefile    |  10 ++--
 2 files changed, 63 insertions(+), 63 deletions(-)

diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index 87b7e48..25d866a 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -14,6 +14,64 @@ config ARM_DT_BL_CPUFREQ
 	  This enables the Generic CPUfreq driver for ARM big.LITTLE platform.
 	  This gets frequency tables from DT.
 
+config ARM_EXYNOS_CPUFREQ
+	bool "SAMSUNG EXYNOS SoCs"
+	depends on ARCH_EXYNOS
+	default y
+	help
+	  This adds the CPUFreq driver common part for Samsung
+	  EXYNOS SoCs.
+
+	  If in doubt, say N.
+
+config ARM_EXYNOS4210_CPUFREQ
+	def_bool CPU_EXYNOS4210
+	help
+	  This adds the CPUFreq driver for Samsung EXYNOS4210
+	  SoC (S5PV310 or S5PC210).
+
+config ARM_EXYNOS4X12_CPUFREQ
+	def_bool (SOC_EXYNOS4212 || SOC_EXYNOS4412)
+	help
+	  This adds the CPUFreq driver for Samsung EXYNOS4X12
+	  SoC (EXYNOS4212 or EXYNOS4412).
+
+config ARM_EXYNOS5250_CPUFREQ
+	def_bool SOC_EXYNOS5250
+	help
+	  This adds the CPUFreq driver for Samsung EXYNOS5250
+	  SoC.
+
+config ARM_HIGHBANK_CPUFREQ
+	tristate "Calxeda Highbank-based"
+	depends on ARCH_HIGHBANK
+	select CPU_FREQ_TABLE
+	select GENERIC_CPUFREQ_CPU0
+	select PM_OPP
+	select REGULATOR
+
+	default m
+	help
+	  This adds the CPUFreq driver for Calxeda Highbank SoC
+	  based boards.
+
+	  If in doubt, say N.
+
+config ARM_IMX6Q_CPUFREQ
+	tristate "Freescale i.MX6Q cpufreq support"
+	depends on SOC_IMX6Q
+	depends on REGULATOR_ANATOP
+	help
+	  This adds cpufreq driver support for Freescale i.MX6Q SOC.
+
+	  If in doubt, say N.
+
+config ARM_KIRKWOOD_CPUFREQ
+	def_bool ARCH_KIRKWOOD && OF
+	help
+	  This adds the CPUFreq driver for Marvell Kirkwood
+	  SoCs.
+
 config ARM_OMAP2PLUS_CPUFREQ
 	bool "TI OMAP2+"
 	depends on ARCH_OMAP2PLUS
@@ -61,67 +119,9 @@ config ARM_S5PV210_CPUFREQ
 
 	  If in doubt, say N.
 
-config ARM_EXYNOS_CPUFREQ
-	bool "SAMSUNG EXYNOS SoCs"
-	depends on ARCH_EXYNOS
-	default y
-	help
-	  This adds the CPUFreq driver common part for Samsung
-	  EXYNOS SoCs.
-
-	  If in doubt, say N.
-
-config ARM_EXYNOS4210_CPUFREQ
-	def_bool CPU_EXYNOS4210
-	help
-	  This adds the CPUFreq driver for Samsung EXYNOS4210
-	  SoC (S5PV310 or S5PC210).
-
-config ARM_EXYNOS4X12_CPUFREQ
-	def_bool (SOC_EXYNOS4212 || SOC_EXYNOS4412)
-	help
-	  This adds the CPUFreq driver for Samsung EXYNOS4X12
-	  SoC (EXYNOS4212 or EXYNOS4412).
-
-config ARM_EXYNOS5250_CPUFREQ
-	def_bool SOC_EXYNOS5250
-	help
-	  This adds the CPUFreq driver for Samsung EXYNOS5250
-	  SoC.
-
-config ARM_KIRKWOOD_CPUFREQ
-	def_bool ARCH_KIRKWOOD && OF
-	help
-	  This adds the CPUFreq driver for Marvell Kirkwood
-	  SoCs.
-
-config ARM_IMX6Q_CPUFREQ
-	tristate "Freescale i.MX6Q cpufreq support"
-	depends on SOC_IMX6Q
-	depends on REGULATOR_ANATOP
-	help
-	  This adds cpufreq driver support for Freescale i.MX6Q SOC.
-
-	  If in doubt, say N.
-
 config ARM_SPEAR_CPUFREQ
 	bool "SPEAr CPUFreq support"
 	depends on PLAT_SPEAR
 	default y
 	help
 	  This adds the CPUFreq driver support for SPEAr SOCs.
-
-config ARM_HIGHBANK_CPUFREQ
-	tristate "Calxeda Highbank-based"
-	depends on ARCH_HIGHBANK
-	select CPU_FREQ_TABLE
-	select GENERIC_CPUFREQ_CPU0
-	select PM_OPP
-	select REGULATOR
-
-	default m
-	help
-	  This adds the CPUFreq driver for Calxeda Highbank SoC
-	  based boards.
-
-	  If in doubt, say N.
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index ba9a3e1..2c25504 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -50,18 +50,18 @@ obj-$(CONFIG_ARM_BIG_LITTLE_CPUFREQ)	+= arm_big_little.o
 obj-$(CONFIG_ARM_DT_BL_CPUFREQ)		+= arm_big_little_dt.o
 
 obj-$(CONFIG_UX500_SOC_DB8500)		+= dbx500-cpufreq.o
-obj-$(CONFIG_ARM_S3C2416_CPUFREQ)	+= s3c2416-cpufreq.o
-obj-$(CONFIG_ARM_S3C64XX_CPUFREQ)	+= s3c64xx-cpufreq.o
-obj-$(CONFIG_ARM_S5PV210_CPUFREQ)	+= s5pv210-cpufreq.o
 obj-$(CONFIG_ARM_EXYNOS_CPUFREQ)	+= exynos-cpufreq.o
 obj-$(CONFIG_ARM_EXYNOS4210_CPUFREQ)	+= exynos4210-cpufreq.o
 obj-$(CONFIG_ARM_EXYNOS4X12_CPUFREQ)	+= exynos4x12-cpufreq.o
 obj-$(CONFIG_ARM_EXYNOS5250_CPUFREQ)	+= exynos5250-cpufreq.o
+obj-$(CONFIG_ARM_HIGHBANK_CPUFREQ)	+= highbank-cpufreq.o
+obj-$(CONFIG_ARM_IMX6Q_CPUFREQ)		+= imx6q-cpufreq.o
 obj-$(CONFIG_ARM_KIRKWOOD_CPUFREQ)	+= kirkwood-cpufreq.o
 obj-$(CONFIG_ARM_OMAP2PLUS_CPUFREQ)	+= omap-cpufreq.o
+obj-$(CONFIG_ARM_S3C2416_CPUFREQ)	+= s3c2416-cpufreq.o
+obj-$(CONFIG_ARM_S3C64XX_CPUFREQ)	+= s3c64xx-cpufreq.o
+obj-$(CONFIG_ARM_S5PV210_CPUFREQ)	+= s5pv210-cpufreq.o
 obj-$(CONFIG_ARM_SPEAR_CPUFREQ)		+= spear-cpufreq.o
-obj-$(CONFIG_ARM_HIGHBANK_CPUFREQ)	+= highbank-cpufreq.o
-obj-$(CONFIG_ARM_IMX6Q_CPUFREQ)		+= imx6q-cpufreq.o
 
 ##################################################################################
 # PowerPC platform drivers
-- 
1.7.12.rc2.18.g61b472e



From viresh.kumar at linaro.org  Thu Apr  4 08:54:10 2013
From: viresh.kumar at linaro.org (Viresh Kumar)
Date: Thu,  4 Apr 2013 18:24:10 +0530
Subject: [PATCH 02/18] cpufreq: tegra: Move driver to drivers/cpufreq
In-Reply-To: <cover.1365079581.git.viresh.kumar@linaro.org>
References: <cover.1365079581.git.viresh.kumar@linaro.org>
Message-ID: <64b0150f8052708fa606c59322e34bd023ee4b0b.1365079581.git.viresh.kumar@linaro.org>

This patch moves cpufreq driver of ARM based tegra platform to drivers/cpufreq.

Cc: Stephen Warren <swarren at wwwdotorg.org>
Cc: linux-arm-kernel at lists.infradead.org
Signed-off-by: Viresh Kumar <viresh.kumar at linaro.org>
Acked-by: Stephen Warren <swarren at nvidia.com>
Tested-by: Stephen Warren <swarren at nvidia.com>
Acked-by: Arnd Bergmann <arnd at arndb.de>
---
 arch/arm/mach-tegra/Makefile                                       | 1 -
 drivers/cpufreq/Makefile                                           | 1 +
 arch/arm/mach-tegra/cpu-tegra.c => drivers/cpufreq/tegra-cpufreq.c | 2 --
 3 files changed, 1 insertion(+), 3 deletions(-)
 rename arch/arm/mach-tegra/cpu-tegra.c => drivers/cpufreq/tegra-cpufreq.c (99%)

diff --git a/arch/arm/mach-tegra/Makefile b/arch/arm/mach-tegra/Makefile
index f6b46ae..09b578f 100644
--- a/arch/arm/mach-tegra/Makefile
+++ b/arch/arm/mach-tegra/Makefile
@@ -24,7 +24,6 @@ obj-$(CONFIG_ARCH_TEGRA_3x_SOC)		+= cpuidle-tegra30.o
 endif
 obj-$(CONFIG_SMP)			+= platsmp.o headsmp.o
 obj-$(CONFIG_HOTPLUG_CPU)               += hotplug.o
-obj-$(CONFIG_CPU_FREQ)                  += cpu-tegra.o
 obj-$(CONFIG_TEGRA_PCI)			+= pcie.o
 
 obj-$(CONFIG_ARCH_TEGRA_2x_SOC)		+= board-dt-tegra20.o
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index 2c25504..c34094b 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -62,6 +62,7 @@ obj-$(CONFIG_ARM_S3C2416_CPUFREQ)	+= s3c2416-cpufreq.o
 obj-$(CONFIG_ARM_S3C64XX_CPUFREQ)	+= s3c64xx-cpufreq.o
 obj-$(CONFIG_ARM_S5PV210_CPUFREQ)	+= s5pv210-cpufreq.o
 obj-$(CONFIG_ARM_SPEAR_CPUFREQ)		+= spear-cpufreq.o
+obj-$(CONFIG_ARCH_TEGRA)		+= tegra-cpufreq.o
 
 ##################################################################################
 # PowerPC platform drivers
diff --git a/arch/arm/mach-tegra/cpu-tegra.c b/drivers/cpufreq/tegra-cpufreq.c
similarity index 99%
rename from arch/arm/mach-tegra/cpu-tegra.c
rename to drivers/cpufreq/tegra-cpufreq.c
index 11ca730..c74c0e1 100644
--- a/arch/arm/mach-tegra/cpu-tegra.c
+++ b/drivers/cpufreq/tegra-cpufreq.c
@@ -1,6 +1,4 @@
 /*
- * arch/arm/mach-tegra/cpu-tegra.c
- *
  * Copyright (C) 2010 Google, Inc.
  *
  * Author:
-- 
1.7.12.rc2.18.g61b472e



From viresh.kumar at linaro.org  Thu Apr  4 08:54:11 2013
From: viresh.kumar at linaro.org (Viresh Kumar)
Date: Thu,  4 Apr 2013 18:24:11 +0530
Subject: [PATCH 03/18] cpufreq: davinci: move cpufreq driver to drivers/cpufreq
In-Reply-To: <cover.1365079581.git.viresh.kumar@linaro.org>
References: <cover.1365079581.git.viresh.kumar@linaro.org>
Message-ID: <eb5d22a8f338116621cdffdf46e4e3d50966e428.1365079581.git.viresh.kumar@linaro.org>

This patch moves cpufreq driver of ARM based davinci platform to
drivers/cpufreq.

Cc: Sekhar Nori <nsekhar at ti.com>
Cc: davinci-linux-open-source at linux.davincidsp.com
Cc: linux-arm-kernel at lists.infradead.org
Signed-off-by: Viresh Kumar <viresh.kumar at linaro.org>
Acked-by: Sekhar Nori <nsekhar at ti.com>
Acked-by: Arnd Bergmann <arnd at arndb.de>
---
 arch/arm/mach-davinci/Makefile                                       | 1 -
 drivers/cpufreq/Makefile                                             | 1 +
 arch/arm/mach-davinci/cpufreq.c => drivers/cpufreq/davinci-cpufreq.c | 2 --
 3 files changed, 1 insertion(+), 3 deletions(-)
 rename arch/arm/mach-davinci/cpufreq.c => drivers/cpufreq/davinci-cpufreq.c (99%)

diff --git a/arch/arm/mach-davinci/Makefile b/arch/arm/mach-davinci/Makefile
index fb5c1aa..dd1ffcc 100644
--- a/arch/arm/mach-davinci/Makefile
+++ b/arch/arm/mach-davinci/Makefile
@@ -37,7 +37,6 @@ obj-$(CONFIG_MACH_MITYOMAPL138)		+= board-mityomapl138.o
 obj-$(CONFIG_MACH_OMAPL138_HAWKBOARD)	+= board-omapl138-hawk.o
 
 # Power Management
-obj-$(CONFIG_CPU_FREQ)			+= cpufreq.o
 obj-$(CONFIG_CPU_IDLE)			+= cpuidle.o
 obj-$(CONFIG_SUSPEND)			+= pm.o sleep.o
 obj-$(CONFIG_HAVE_CLK)			+= pm_domain.o
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index c34094b..c0e8921 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -49,6 +49,7 @@ obj-$(CONFIG_ARM_BIG_LITTLE_CPUFREQ)	+= arm_big_little.o
 # LITTLE drivers, so that it is probed last.
 obj-$(CONFIG_ARM_DT_BL_CPUFREQ)		+= arm_big_little_dt.o
 
+obj-$(CONFIG_ARCH_DAVINCI_DA850)	+= davinci-cpufreq.o
 obj-$(CONFIG_UX500_SOC_DB8500)		+= dbx500-cpufreq.o
 obj-$(CONFIG_ARM_EXYNOS_CPUFREQ)	+= exynos-cpufreq.o
 obj-$(CONFIG_ARM_EXYNOS4210_CPUFREQ)	+= exynos4210-cpufreq.o
diff --git a/arch/arm/mach-davinci/cpufreq.c b/drivers/cpufreq/davinci-cpufreq.c
similarity index 99%
rename from arch/arm/mach-davinci/cpufreq.c
rename to drivers/cpufreq/davinci-cpufreq.c
index 7c2e943..c33c76c 100644
--- a/arch/arm/mach-davinci/cpufreq.c
+++ b/drivers/cpufreq/davinci-cpufreq.c
@@ -30,8 +30,6 @@
 #include <mach/cpufreq.h>
 #include <mach/common.h>
 
-#include "clock.h"
-
 struct davinci_cpufreq {
 	struct device *dev;
 	struct clk *armclk;
-- 
1.7.12.rc2.18.g61b472e



From viresh.kumar at linaro.org  Thu Apr  4 08:54:12 2013
From: viresh.kumar at linaro.org (Viresh Kumar)
Date: Thu,  4 Apr 2013 18:24:12 +0530
Subject: [PATCH 04/18] cpufreq: pxa3xx: move cpufreq driver to drivers/cpufreq
In-Reply-To: <cover.1365079581.git.viresh.kumar@linaro.org>
References: <cover.1365079581.git.viresh.kumar@linaro.org>
Message-ID: <5aa065e550ad6b9f443155913a383374235df865.1365079581.git.viresh.kumar@linaro.org>

This patch moves cpufreq driver of ARM based pxa3xx platform to drivers/cpufreq.

Cc: Eric Miao <eric.y.miao at gmail.com>
Cc: Haojian Zhuang <haojian.zhuang at gmail.com>
Cc: linux-arm-kernel at lists.infradead.org
Signed-off-by: Viresh Kumar <viresh.kumar at linaro.org>
Acked-by: Eric Miao <eric.y.miao at gmail.com>
Acked-by: Arnd Bergmann <arnd at arndb.de>
---
 arch/arm/mach-pxa/Makefile                                           | 1 -
 arch/arm/mach-pxa/include/mach/generic.h                             | 1 +
 drivers/cpufreq/Makefile                                             | 1 +
 .../mach-pxa/cpufreq-pxa3xx.c => drivers/cpufreq/pxa3xx-cpufreq.c    | 5 +----
 4 files changed, 3 insertions(+), 5 deletions(-)
 create mode 100644 arch/arm/mach-pxa/include/mach/generic.h
 rename arch/arm/mach-pxa/cpufreq-pxa3xx.c => drivers/cpufreq/pxa3xx-cpufreq.c (98%)

diff --git a/arch/arm/mach-pxa/Makefile b/arch/arm/mach-pxa/Makefile
index 12c5005..929e700 100644
--- a/arch/arm/mach-pxa/Makefile
+++ b/arch/arm/mach-pxa/Makefile
@@ -10,7 +10,6 @@ obj-$(CONFIG_PM)		+= pm.o sleep.o standby.o
 ifeq ($(CONFIG_CPU_FREQ),y)
 obj-$(CONFIG_PXA25x)		+= cpufreq-pxa2xx.o
 obj-$(CONFIG_PXA27x)		+= cpufreq-pxa2xx.o
-obj-$(CONFIG_PXA3xx)		+= cpufreq-pxa3xx.o
 endif
 
 # Generic drivers that other drivers may depend upon
diff --git a/arch/arm/mach-pxa/include/mach/generic.h b/arch/arm/mach-pxa/include/mach/generic.h
new file mode 100644
index 0000000..665542e
--- /dev/null
+++ b/arch/arm/mach-pxa/include/mach/generic.h
@@ -0,0 +1 @@
+#include "../../generic.h"
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index c0e8921..3458bf2 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -59,6 +59,7 @@ obj-$(CONFIG_ARM_HIGHBANK_CPUFREQ)	+= highbank-cpufreq.o
 obj-$(CONFIG_ARM_IMX6Q_CPUFREQ)		+= imx6q-cpufreq.o
 obj-$(CONFIG_ARM_KIRKWOOD_CPUFREQ)	+= kirkwood-cpufreq.o
 obj-$(CONFIG_ARM_OMAP2PLUS_CPUFREQ)	+= omap-cpufreq.o
+obj-$(CONFIG_PXA3xx)			+= pxa3xx-cpufreq.o
 obj-$(CONFIG_ARM_S3C2416_CPUFREQ)	+= s3c2416-cpufreq.o
 obj-$(CONFIG_ARM_S3C64XX_CPUFREQ)	+= s3c64xx-cpufreq.o
 obj-$(CONFIG_ARM_S5PV210_CPUFREQ)	+= s5pv210-cpufreq.o
diff --git a/arch/arm/mach-pxa/cpufreq-pxa3xx.c b/drivers/cpufreq/pxa3xx-cpufreq.c
similarity index 98%
rename from arch/arm/mach-pxa/cpufreq-pxa3xx.c
rename to drivers/cpufreq/pxa3xx-cpufreq.c
index 8c45b2b..15d60f8 100644
--- a/arch/arm/mach-pxa/cpufreq-pxa3xx.c
+++ b/drivers/cpufreq/pxa3xx-cpufreq.c
@@ -1,6 +1,4 @@
 /*
- * linux/arch/arm/mach-pxa/cpufreq-pxa3xx.c
- *
  * Copyright (C) 2008 Marvell International Ltd.
  *
  * This program is free software; you can redistribute it and/or modify
@@ -17,10 +15,9 @@
 #include <linux/slab.h>
 #include <linux/io.h>
 
+#include <mach/generic.h>
 #include <mach/pxa3xx-regs.h>
 
-#include "generic.h"
-
 #define HSS_104M	(0)
 #define HSS_156M	(1)
 #define HSS_208M	(2)
-- 
1.7.12.rc2.18.g61b472e



From viresh.kumar at linaro.org  Thu Apr  4 08:54:13 2013
From: viresh.kumar at linaro.org (Viresh Kumar)
Date: Thu,  4 Apr 2013 18:24:13 +0530
Subject: [PATCH 05/18] cpufreq: pxa2xx: move cpufreq driver to drivers/cpufreq
In-Reply-To: <cover.1365079581.git.viresh.kumar@linaro.org>
References: <cover.1365079581.git.viresh.kumar@linaro.org>
Message-ID: <41cb34556b2cb26923842fcaf38990f46dfbd7f1.1365079581.git.viresh.kumar@linaro.org>

This patch moves cpufreq driver of ARM based pxa2xx platform to drivers/cpufreq.

Cc: Eric Miao <eric.y.miao at gmail.com>
Cc: Haojian Zhuang <haojian.zhuang at gmail.com>
Cc: linux-arm-kernel at lists.infradead.org
Signed-off-by: Viresh Kumar <viresh.kumar at linaro.org>
Acked-by: Eric Miao <eric.y.miao at gmail.com>
Acked-by: Arnd Bergmann <arnd at arndb.de>
---
 arch/arm/Kconfig                                                   | 7 -------
 arch/arm/mach-pxa/Makefile                                         | 5 -----
 drivers/cpufreq/Makefile                                           | 2 ++
 .../mach-pxa/cpufreq-pxa2xx.c => drivers/cpufreq/pxa2xx-cpufreq.c  | 2 --
 4 files changed, 2 insertions(+), 14 deletions(-)
 rename arch/arm/mach-pxa/cpufreq-pxa2xx.c => drivers/cpufreq/pxa2xx-cpufreq.c (99%)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 13b7394..76eb836 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -2177,13 +2177,6 @@ config CPU_FREQ_INTEGRATOR
 
 	  If in doubt, say Y.
 
-config CPU_FREQ_PXA
-	bool
-	depends on CPU_FREQ && ARCH_PXA && PXA25x
-	default y
-	select CPU_FREQ_DEFAULT_GOV_USERSPACE
-	select CPU_FREQ_TABLE
-
 config CPU_FREQ_S3C
 	bool
 	help
diff --git a/arch/arm/mach-pxa/Makefile b/arch/arm/mach-pxa/Makefile
index 929e700..648867a 100644
--- a/arch/arm/mach-pxa/Makefile
+++ b/arch/arm/mach-pxa/Makefile
@@ -7,11 +7,6 @@ obj-y				+= clock.o devices.o generic.o irq.o \
 				   time.o reset.o
 obj-$(CONFIG_PM)		+= pm.o sleep.o standby.o
 
-ifeq ($(CONFIG_CPU_FREQ),y)
-obj-$(CONFIG_PXA25x)		+= cpufreq-pxa2xx.o
-obj-$(CONFIG_PXA27x)		+= cpufreq-pxa2xx.o
-endif
-
 # Generic drivers that other drivers may depend upon
 
 # SoC-specific code
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index 3458bf2..aa766fb 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -59,6 +59,8 @@ obj-$(CONFIG_ARM_HIGHBANK_CPUFREQ)	+= highbank-cpufreq.o
 obj-$(CONFIG_ARM_IMX6Q_CPUFREQ)		+= imx6q-cpufreq.o
 obj-$(CONFIG_ARM_KIRKWOOD_CPUFREQ)	+= kirkwood-cpufreq.o
 obj-$(CONFIG_ARM_OMAP2PLUS_CPUFREQ)	+= omap-cpufreq.o
+obj-$(CONFIG_PXA25x)			+= pxa2xx-cpufreq.o
+obj-$(CONFIG_PXA27x)			+= pxa2xx-cpufreq.o
 obj-$(CONFIG_PXA3xx)			+= pxa3xx-cpufreq.o
 obj-$(CONFIG_ARM_S3C2416_CPUFREQ)	+= s3c2416-cpufreq.o
 obj-$(CONFIG_ARM_S3C64XX_CPUFREQ)	+= s3c64xx-cpufreq.o
diff --git a/arch/arm/mach-pxa/cpufreq-pxa2xx.c b/drivers/cpufreq/pxa2xx-cpufreq.c
similarity index 99%
rename from arch/arm/mach-pxa/cpufreq-pxa2xx.c
rename to drivers/cpufreq/pxa2xx-cpufreq.c
index f1ca4da..fe4c55b 100644
--- a/arch/arm/mach-pxa/cpufreq-pxa2xx.c
+++ b/drivers/cpufreq/pxa2xx-cpufreq.c
@@ -1,6 +1,4 @@
 /*
- *  linux/arch/arm/mach-pxa/cpufreq-pxa2xx.c
- *
  *  Copyright (C) 2002,2003 Intrinsyc Software
  *
  * This program is free software; you can redistribute it and/or modify
-- 
1.7.12.rc2.18.g61b472e



From viresh.kumar at linaro.org  Thu Apr  4 08:54:14 2013
From: viresh.kumar at linaro.org (Viresh Kumar)
Date: Thu,  4 Apr 2013 18:24:14 +0530
Subject: [PATCH 06/18] cpufreq: integrator: move cpufreq driver to
 drivers/cpufreq
In-Reply-To: <cover.1365079581.git.viresh.kumar@linaro.org>
References: <cover.1365079581.git.viresh.kumar@linaro.org>
Message-ID: <062b894f52bcf748d2a5ba82e98319b9734356a9.1365079581.git.viresh.kumar@linaro.org>

This patch moves cpufreq driver of ARM based integrator platform to
drivers/cpufreq.

Cc: Russell King <linux at arm.linux.org.uk>
Cc: linux-arm-kernel at lists.infradead.org
Signed-off-by: Viresh Kumar <viresh.kumar at linaro.org>
Acked-by: Arnd Bergmann <arnd at arndb.de>
Acked-by: Linus Walleij <linus.walleij at linaro.org>
---
 arch/arm/Kconfig                                              | 11 -----------
 arch/arm/mach-integrator/Makefile                             |  1 -
 drivers/cpufreq/Kconfig.arm                                   |  8 ++++++++
 drivers/cpufreq/Makefile                                      |  1 +
 .../cpu.c => drivers/cpufreq/integrator-cpufreq.c             |  2 --
 5 files changed, 9 insertions(+), 14 deletions(-)
 rename arch/arm/mach-integrator/cpu.c => drivers/cpufreq/integrator-cpufreq.c (99%)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 76eb836..c3563f6 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -2166,17 +2166,6 @@ config CPU_FREQ_SA1100
 config CPU_FREQ_SA1110
 	bool
 
-config CPU_FREQ_INTEGRATOR
-	tristate "CPUfreq driver for ARM Integrator CPUs"
-	depends on ARCH_INTEGRATOR && CPU_FREQ
-	default y
-	help
-	  This enables the CPUfreq driver for ARM Integrator CPUs.
-
-	  For details, take a look at <file:Documentation/cpu-freq>.
-
-	  If in doubt, say Y.
-
 config CPU_FREQ_S3C
 	bool
 	help
diff --git a/arch/arm/mach-integrator/Makefile b/arch/arm/mach-integrator/Makefile
index 5521d18..d14d6b7 100644
--- a/arch/arm/mach-integrator/Makefile
+++ b/arch/arm/mach-integrator/Makefile
@@ -9,5 +9,4 @@ obj-$(CONFIG_ARCH_INTEGRATOR_AP)	+= integrator_ap.o
 obj-$(CONFIG_ARCH_INTEGRATOR_CP)	+= integrator_cp.o
 
 obj-$(CONFIG_PCI)			+= pci_v3.o pci.o
-obj-$(CONFIG_CPU_FREQ_INTEGRATOR)	+= cpu.o
 obj-$(CONFIG_INTEGRATOR_IMPD1)		+= impd1.o
diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index 25d866a..97f208d 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -66,6 +66,14 @@ config ARM_IMX6Q_CPUFREQ
 
 	  If in doubt, say N.
 
+config ARM_INTEGRATOR
+	tristate "CPUfreq driver for ARM Integrator CPUs"
+	depends on ARCH_INTEGRATOR
+	default y
+	help
+	  This enables the CPUfreq driver for ARM Integrator CPUs.
+	  If in doubt, say Y.
+
 config ARM_KIRKWOOD_CPUFREQ
 	def_bool ARCH_KIRKWOOD && OF
 	help
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index aa766fb..8d58016 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -57,6 +57,7 @@ obj-$(CONFIG_ARM_EXYNOS4X12_CPUFREQ)	+= exynos4x12-cpufreq.o
 obj-$(CONFIG_ARM_EXYNOS5250_CPUFREQ)	+= exynos5250-cpufreq.o
 obj-$(CONFIG_ARM_HIGHBANK_CPUFREQ)	+= highbank-cpufreq.o
 obj-$(CONFIG_ARM_IMX6Q_CPUFREQ)		+= imx6q-cpufreq.o
+obj-$(CONFIG_ARM_INTEGRATOR)		+= integrator-cpufreq.o
 obj-$(CONFIG_ARM_KIRKWOOD_CPUFREQ)	+= kirkwood-cpufreq.o
 obj-$(CONFIG_ARM_OMAP2PLUS_CPUFREQ)	+= omap-cpufreq.o
 obj-$(CONFIG_PXA25x)			+= pxa2xx-cpufreq.o
diff --git a/arch/arm/mach-integrator/cpu.c b/drivers/cpufreq/integrator-cpufreq.c
similarity index 99%
rename from arch/arm/mach-integrator/cpu.c
rename to drivers/cpufreq/integrator-cpufreq.c
index df863c3..f7c99df 100644
--- a/arch/arm/mach-integrator/cpu.c
+++ b/drivers/cpufreq/integrator-cpufreq.c
@@ -1,6 +1,4 @@
 /*
- *  linux/arch/arm/mach-integrator/cpu.c
- *
  *  Copyright (C) 2001-2002 Deep Blue Solutions Ltd.
  *
  * This program is free software; you can redistribute it and/or modify
-- 
1.7.12.rc2.18.g61b472e



From viresh.kumar at linaro.org  Thu Apr  4 08:54:15 2013
From: viresh.kumar at linaro.org (Viresh Kumar)
Date: Thu,  4 Apr 2013 18:24:15 +0530
Subject: [PATCH 07/18] cpufreq: s3c24xx: move cpufreq driver to drivers/cpufreq
In-Reply-To: <cover.1365079581.git.viresh.kumar@linaro.org>
References: <cover.1365079581.git.viresh.kumar@linaro.org>
Message-ID: <927100d30bf40d4fec477cc7d8d464669a22d167.1365079581.git.viresh.kumar@linaro.org>

This patch moves cpufreq driver of Samsung's ARM based s3c24xx platform to
drivers/cpufreq.

Cc: Ben Dooks <ben-linux at fluff.org>
Cc: Kukjin Kim <kgene.kim at samsung.com>
Cc: linux-samsung-soc at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Signed-off-by: Viresh Kumar <viresh.kumar at linaro.org>
Acked-by: Arnd Bergmann <arnd at arndb.de>
---
 arch/arm/Kconfig                                   | 46 ---------------
 arch/arm/mach-s3c24xx/Kconfig                      | 66 +++++++++-------------
 arch/arm/mach-s3c24xx/Makefile                     |  6 --
 arch/arm/mach-s3c24xx/{ => include/mach}/s3c2412.h |  0
 arch/arm/mach-s3c24xx/iotiming-s3c2412.c           |  2 +-
 arch/arm/plat-samsung/include/plat/cpu-freq-core.h | 10 ++--
 arch/arm/plat-samsung/include/plat/cpu-freq.h      |  6 +-
 drivers/cpufreq/Kconfig.arm                        | 58 +++++++++++++++++++
 drivers/cpufreq/Makefile                           |  5 ++
 .../cpufreq/s3c2410-cpufreq.c                      |  0
 .../cpufreq/s3c2412-cpufreq.c                      |  3 +-
 .../cpufreq/s3c2440-cpufreq.c                      |  0
 .../cpufreq/s3c24xx-cpufreq-debugfs.c              |  0
 .../cpufreq.c => drivers/cpufreq/s3c24xx-cpufreq.c |  0
 14 files changed, 100 insertions(+), 102 deletions(-)
 rename arch/arm/mach-s3c24xx/{ => include/mach}/s3c2412.h (100%)
 rename arch/arm/mach-s3c24xx/cpufreq-s3c2410.c => drivers/cpufreq/s3c2410-cpufreq.c (100%)
 rename arch/arm/mach-s3c24xx/cpufreq-s3c2412.c => drivers/cpufreq/s3c2412-cpufreq.c (99%)
 rename arch/arm/mach-s3c24xx/cpufreq-s3c2440.c => drivers/cpufreq/s3c2440-cpufreq.c (100%)
 rename arch/arm/mach-s3c24xx/cpufreq-debugfs.c => drivers/cpufreq/s3c24xx-cpufreq-debugfs.c (100%)
 rename arch/arm/mach-s3c24xx/cpufreq.c => drivers/cpufreq/s3c24xx-cpufreq.c (100%)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index c3563f6..70366b7 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -2166,52 +2166,6 @@ config CPU_FREQ_SA1100
 config CPU_FREQ_SA1110
 	bool
 
-config CPU_FREQ_S3C
-	bool
-	help
-	  Internal configuration node for common cpufreq on Samsung SoC
-
-config CPU_FREQ_S3C24XX
-	bool "CPUfreq driver for Samsung S3C24XX series CPUs (EXPERIMENTAL)"
-	depends on ARCH_S3C24XX && CPU_FREQ
-	select CPU_FREQ_S3C
-	help
-	  This enables the CPUfreq driver for the Samsung S3C24XX family
-	  of CPUs.
-
-	  For details, take a look at <file:Documentation/cpu-freq>.
-
-	  If in doubt, say N.
-
-config CPU_FREQ_S3C24XX_PLL
-	bool "Support CPUfreq changing of PLL frequency (EXPERIMENTAL)"
-	depends on CPU_FREQ_S3C24XX
-	help
-	  Compile in support for changing the PLL frequency from the
-	  S3C24XX series CPUfreq driver. The PLL takes time to settle
-	  after a frequency change, so by default it is not enabled.
-
-	  This also means that the PLL tables for the selected CPU(s) will
-	  be built which may increase the size of the kernel image.
-
-config CPU_FREQ_S3C24XX_DEBUG
-	bool "Debug CPUfreq Samsung driver core"
-	depends on CPU_FREQ_S3C24XX
-	help
-	  Enable s3c_freq_dbg for the Samsung S3C CPUfreq core
-
-config CPU_FREQ_S3C24XX_IODEBUG
-	bool "Debug CPUfreq Samsung driver IO timing"
-	depends on CPU_FREQ_S3C24XX
-	help
-	  Enable s3c_freq_iodbg for the Samsung S3C CPUfreq core
-
-config CPU_FREQ_S3C24XX_DEBUGFS
-	bool "Export debugfs for CPUFreq"
-	depends on CPU_FREQ_S3C24XX && DEBUG_FS
-	help
-	  Export status information via debugfs.
-
 endif
 
 source "drivers/cpuidle/Kconfig"
diff --git a/arch/arm/mach-s3c24xx/Kconfig b/arch/arm/mach-s3c24xx/Kconfig
index 37f513d..81d2f3c 100644
--- a/arch/arm/mach-s3c24xx/Kconfig
+++ b/arch/arm/mach-s3c24xx/Kconfig
@@ -28,7 +28,7 @@ config CPU_S3C2410
 	select CPU_ARM920T
 	select CPU_LLSERIAL_S3C2410
 	select S3C2410_CLOCK
-	select S3C2410_CPUFREQ if CPU_FREQ_S3C24XX
+	select ARM_S3C2410_CPUFREQ if ARM_S3C24XX_CPUFREQ
 	select S3C2410_PM if PM
 	help
 	  Support for S3C2410 and S3C2410A family from the S3C24XX line
@@ -202,27 +202,38 @@ config S3C24XX_GPIO_EXTRA128
 	  Add an extra 128 gpio numbers to the available GPIO pool. This is
 	  available for boards that need extra gpios for external devices.
 
+config S3C24XX_PLL
+	bool "Support CPUfreq changing of PLL frequency (EXPERIMENTAL)"
+	depends on ARM_S3C24XX
+	help
+	  Compile in support for changing the PLL frequency from the
+	  S3C24XX series CPUfreq driver. The PLL takes time to settle
+	  after a frequency change, so by default it is not enabled.
+
+	  This also means that the PLL tables for the selected CPU(s) will
+	  be built which may increase the size of the kernel image.
+
 # cpu frequency items common between s3c2410 and s3c2440/s3c2442
 
 config S3C2410_IOTIMING
 	bool
-	depends on CPU_FREQ_S3C24XX
+	depends on ARM_S3C24XX_CPUFREQ
 	help
 	  Internal node to select io timing code that is common to the s3c2410
 	  and s3c2440/s3c2442 cpu frequency support.
 
 config S3C2410_CPUFREQ_UTILS
-	bool
-	depends on CPU_FREQ_S3C24XX
-	help
-	  Internal node to select timing code that is common to the s3c2410
-	  and s3c2440/s3c244 cpu frequency support.
+       bool
+       depends on ARM_S3C24XX_CPUFREQ
+       help
+         Internal node to select timing code that is common to the s3c2410
+         and s3c2440/s3c244 cpu frequency support.
 
 # cpu frequency support common to s3c2412, s3c2413 and s3c2442
 
 config S3C2412_IOTIMING
 	bool
-	depends on CPU_FREQ_S3C24XX && (CPU_S3C2412 || CPU_S3C2443)
+	depends on ARM_S3C24XX_CPUFREQ && (CPU_S3C2412 || CPU_S3C2443)
 	help
 	  Intel node to select io timing code that is common to the s3c2412
 	  and the s3c2443.
@@ -231,16 +242,9 @@ config S3C2412_IOTIMING
 
 if CPU_S3C2410
 
-config S3C2410_CPUFREQ
-	bool
-	depends on CPU_FREQ_S3C24XX && CPU_S3C2410
-	select S3C2410_CPUFREQ_UTILS
-	help
-	  CPU Frequency scaling support for S3C2410
-
 config S3C2410_PLL
 	bool
-	depends on S3C2410_CPUFREQ && CPU_FREQ_S3C24XX_PLL
+	depends on ARM_S3C2410_CPUFREQ && S3C24XX_PLL
 	default y
 	help
 	  Select the PLL table for the S3C2410
@@ -276,7 +280,7 @@ config ARCH_BAST
 	bool "Simtec Electronics BAST (EB2410ITX)"
 	select ISA
 	select MACH_BAST_IDE
-	select S3C2410_IOTIMING if S3C2410_CPUFREQ
+	select S3C2410_IOTIMING if ARM_S3C2410_CPUFREQ
 	select S3C24XX_DCLK
 	select S3C24XX_SIMTEC_NOR
 	select S3C24XX_SIMTEC_PM if PM
@@ -385,14 +389,6 @@ config CPU_S3C2412_ONLY
 		   !CPU_S3C2443 && CPU_S3C2412
 	default y
 
-config S3C2412_CPUFREQ
-	bool
-	depends on CPU_FREQ_S3C24XX && CPU_S3C2412
-	default y
-	select S3C2412_IOTIMING
-	help
-	  CPU Frequency scaling support for S3C2412 and S3C2413 SoC CPUs.
-
 config S3C2412_DMA
 	bool
 	help
@@ -493,14 +489,6 @@ endif	# CPU_S3C2416
 
 if CPU_S3C2440
 
-config S3C2440_CPUFREQ
-	bool "S3C2440/S3C2442 CPU Frequency scaling support"
-	depends on CPU_FREQ_S3C24XX && (CPU_S3C2440 || CPU_S3C2442)
-	default y
-	select S3C2410_CPUFREQ_UTILS
-	help
-	  CPU Frequency scaling support for S3C2440 and S3C2442 SoC CPUs.
-
 config S3C2440_DMA
 	bool
 	help
@@ -520,15 +508,15 @@ config S3C2440_XTAL_16934400
 
 config S3C2440_PLL_12000000
 	bool
-	depends on S3C2440_CPUFREQ && S3C2440_XTAL_12000000
-	default y if CPU_FREQ_S3C24XX_PLL
+	depends on ARM_S3C2440_CPUFREQ && S3C2440_XTAL_12000000
+	default y if S3C24XX_PLL
 	help
 	  PLL tables for S3C2440 or S3C2442 CPUs with 12MHz crystals.
 
 config S3C2440_PLL_16934400
 	bool
-	depends on S3C2440_CPUFREQ && S3C2440_XTAL_16934400
-	default y if CPU_FREQ_S3C24XX_PLL
+	depends on ARM_S3C2440_CPUFREQ && S3C2440_XTAL_16934400
+	default y if S3C24XX_PLL
 	help
 	  PLL tables for S3C2440 or S3C2442 CPUs with 16.934MHz crystals.
 
@@ -582,7 +570,7 @@ config MACH_NEXCODER_2440
 
 config MACH_OSIRIS
 	bool "Simtec IM2440D20 (OSIRIS) module"
-	select S3C2410_IOTIMING if S3C2440_CPUFREQ
+	select S3C2410_IOTIMING if ARM_S3C2440_CPUFREQ
 	select S3C2440_XTAL_12000000
 	select S3C24XX_DCLK
 	select S3C24XX_GPIO_EXTRA128
@@ -655,7 +643,7 @@ config MACH_RX1950
 	bool "HP iPAQ rx1950"
 	select I2C
 	select PM_H1940 if PM
-	select S3C2410_IOTIMING if S3C2440_CPUFREQ
+	select S3C2410_IOTIMING if ARM_S3C2440_CPUFREQ
 	select S3C2440_XTAL_16934400
 	select S3C24XX_DCLK
 	select S3C24XX_PWM
diff --git a/arch/arm/mach-s3c24xx/Makefile b/arch/arm/mach-s3c24xx/Makefile
index af53d27..15ce13c 100644
--- a/arch/arm/mach-s3c24xx/Makefile
+++ b/arch/arm/mach-s3c24xx/Makefile
@@ -17,13 +17,11 @@ obj-				:=
 obj-y				+= common.o irq.o
 
 obj-$(CONFIG_CPU_S3C2410)	+= s3c2410.o
-obj-$(CONFIG_S3C2410_CPUFREQ)	+= cpufreq-s3c2410.o
 obj-$(CONFIG_S3C2410_DMA)	+= dma-s3c2410.o
 obj-$(CONFIG_S3C2410_PLL)	+= pll-s3c2410.o
 obj-$(CONFIG_S3C2410_PM)	+= pm-s3c2410.o sleep-s3c2410.o
 
 obj-$(CONFIG_CPU_S3C2412)	+= s3c2412.o irq-s3c2412.o clock-s3c2412.o
-obj-$(CONFIG_S3C2412_CPUFREQ)	+= cpufreq-s3c2412.o
 obj-$(CONFIG_S3C2412_DMA)	+= dma-s3c2412.o
 obj-$(CONFIG_S3C2412_PM)	+= pm-s3c2412.o
 obj-$(CONFIG_S3C2412_PM_SLEEP)	+= sleep-s3c2412.o
@@ -34,7 +32,6 @@ obj-$(CONFIG_S3C2416_PM)	+= pm-s3c2416.o
 obj-$(CONFIG_CPU_S3C2440)	+= s3c2440.o irq-s3c2440.o clock-s3c2440.o
 obj-$(CONFIG_CPU_S3C2442)	+= s3c2442.o
 obj-$(CONFIG_CPU_S3C244X)	+= s3c244x.o irq-s3c244x.o clock-s3c244x.o
-obj-$(CONFIG_S3C2440_CPUFREQ)	+= cpufreq-s3c2440.o
 obj-$(CONFIG_S3C2440_DMA)	+= dma-s3c2440.o
 obj-$(CONFIG_S3C2440_PLL_12000000) += pll-s3c2440-12000000.o
 obj-$(CONFIG_S3C2440_PLL_16934400) += pll-s3c2440-16934400.o
@@ -59,9 +56,6 @@ obj-$(CONFIG_S3C2412_IOTIMING)	+= iotiming-s3c2412.o
 obj-$(CONFIG_S3C2443_COMMON)	+= common-s3c2443.o
 obj-$(CONFIG_S3C2443_DMA)	+= dma-s3c2443.o
 
-obj-$(CONFIG_CPU_FREQ_S3C24XX)	+= cpufreq.o
-obj-$(CONFIG_CPU_FREQ_S3C24XX_DEBUGFS) += cpufreq-debugfs.o
-
 #
 # machine support
 # following is ordered alphabetically by option text.
diff --git a/arch/arm/mach-s3c24xx/s3c2412.h b/arch/arm/mach-s3c24xx/include/mach/s3c2412.h
similarity index 100%
rename from arch/arm/mach-s3c24xx/s3c2412.h
rename to arch/arm/mach-s3c24xx/include/mach/s3c2412.h
diff --git a/arch/arm/mach-s3c24xx/iotiming-s3c2412.c b/arch/arm/mach-s3c24xx/iotiming-s3c2412.c
index 663436d..bd064c0 100644
--- a/arch/arm/mach-s3c24xx/iotiming-s3c2412.c
+++ b/arch/arm/mach-s3c24xx/iotiming-s3c2412.c
@@ -31,7 +31,7 @@
 #include <plat/cpu-freq-core.h>
 #include <plat/clock.h>
 
-#include "s3c2412.h"
+#include <mach/s3c2412.h>
 
 #define print_ns(x) ((x) / 10), ((x) % 10)
 
diff --git a/arch/arm/plat-samsung/include/plat/cpu-freq-core.h b/arch/arm/plat-samsung/include/plat/cpu-freq-core.h
index 95509d8..d7e1715 100644
--- a/arch/arm/plat-samsung/include/plat/cpu-freq-core.h
+++ b/arch/arm/plat-samsung/include/plat/cpu-freq-core.h
@@ -202,7 +202,7 @@ extern int s3c_plltab_register(struct cpufreq_frequency_table *plls,
 extern struct s3c_cpufreq_config *s3c_cpufreq_getconfig(void);
 extern struct s3c_iotimings *s3c_cpufreq_getiotimings(void);
 
-#ifdef CONFIG_CPU_FREQ_S3C24XX_DEBUGFS
+#ifdef CONFIG_ARM_S3C24XX_CPUFREQ_DEBUGFS
 #define s3c_cpufreq_debugfs_call(x) x
 #else
 #define s3c_cpufreq_debugfs_call(x) NULL
@@ -259,17 +259,17 @@ extern void s3c2412_iotiming_set(struct s3c_cpufreq_config *cfg,
 #define s3c2412_iotiming_set NULL
 #endif /* CONFIG_S3C2412_IOTIMING */
 
-#ifdef CONFIG_CPU_FREQ_S3C24XX_DEBUG
+#ifdef CONFIG_ARM_S3C24XX_CPUFREQ_DEBUG
 #define s3c_freq_dbg(x...) printk(KERN_INFO x)
 #else
 #define s3c_freq_dbg(x...) do { if (0) printk(x); } while (0)
-#endif /* CONFIG_CPU_FREQ_S3C24XX_DEBUG */
+#endif /* CONFIG_ARM_S3C24XX_CPUFREQ_DEBUG */
 
-#ifdef CONFIG_CPU_FREQ_S3C24XX_IODEBUG
+#ifdef CONFIG_ARM_S3C24XX_CPUFREQ_IODEBUG
 #define s3c_freq_iodbg(x...) printk(KERN_INFO x)
 #else
 #define s3c_freq_iodbg(x...) do { if (0) printk(x); } while (0)
-#endif /* CONFIG_CPU_FREQ_S3C24XX_IODEBUG */
+#endif /* CONFIG_ARM_S3C24XX_CPUFREQ_IODEBUG */
 
 static inline int s3c_cpufreq_addfreq(struct cpufreq_frequency_table *table,
 				      int index, size_t table_size,
diff --git a/arch/arm/plat-samsung/include/plat/cpu-freq.h b/arch/arm/plat-samsung/include/plat/cpu-freq.h
index 80c4a80..85517ab 100644
--- a/arch/arm/plat-samsung/include/plat/cpu-freq.h
+++ b/arch/arm/plat-samsung/include/plat/cpu-freq.h
@@ -126,7 +126,7 @@ struct s3c_cpufreq_board {
 };
 
 /* Things depending on frequency scaling. */
-#ifdef CONFIG_CPU_FREQ_S3C
+#ifdef CONFIG_ARM_S3C_CPUFREQ
 #define __init_or_cpufreq
 #else
 #define __init_or_cpufreq __init
@@ -134,7 +134,7 @@ struct s3c_cpufreq_board {
 
 /* Board functions */
 
-#ifdef CONFIG_CPU_FREQ_S3C
+#ifdef CONFIG_ARM_S3C_CPUFREQ
 extern int s3c_cpufreq_setboard(struct s3c_cpufreq_board *board);
 #else
 
@@ -142,4 +142,4 @@ static inline int s3c_cpufreq_setboard(struct s3c_cpufreq_board *board)
 {
 	return 0;
 }
-#endif  /* CONFIG_CPU_FREQ_S3C */
+#endif  /* CONFIG_ARM_S3C_CPUFREQ */
diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index 97f208d..1ce61ba 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -86,6 +86,56 @@ config ARM_OMAP2PLUS_CPUFREQ
 	default ARCH_OMAP2PLUS
 	select CPU_FREQ_TABLE
 
+config ARM_S3C_CPUFREQ
+	bool
+	help
+	  Internal configuration node for common cpufreq on Samsung SoC
+
+config ARM_S3C24XX_CPUFREQ
+	bool "CPUfreq driver for Samsung S3C24XX series CPUs (EXPERIMENTAL)"
+	depends on ARCH_S3C24XX
+	select ARM_S3C_CPUFREQ
+	help
+	  This enables the CPUfreq driver for the Samsung S3C24XX family
+	  of CPUs.
+
+	  For details, take a look at <file:Documentation/cpu-freq>.
+
+	  If in doubt, say N.
+
+config ARM_S3C24XX_CPUFREQ_DEBUG
+	bool "Debug CPUfreq Samsung driver core"
+	depends on ARM_S3C24XX_CPUFREQ
+	help
+	  Enable s3c_freq_dbg for the Samsung S3C CPUfreq core
+
+config ARM_S3C24XX_CPUFREQ_IODEBUG
+	bool "Debug CPUfreq Samsung driver IO timing"
+	depends on ARM_S3C24XX_CPUFREQ
+	help
+	  Enable s3c_freq_iodbg for the Samsung S3C CPUfreq core
+
+config ARM_S3C24XX_CPUFREQ_DEBUGFS
+	bool "Export debugfs for CPUFreq"
+	depends on ARM_S3C24XX_CPUFREQ && DEBUG_FS
+	help
+	  Export status information via debugfs.
+
+config ARM_S3C2410_CPUFREQ
+	bool
+	depends on ARM_S3C24XX_CPUFREQ && CPU_S3C2410
+	select S3C2410_CPUFREQ_UTILS
+	help
+	  CPU Frequency scaling support for S3C2410
+
+config ARM_S3C2412_CPUFREQ
+	bool
+	depends on ARM_S3C24XX_CPUFREQ && CPU_S3C2412
+	default y
+	select S3C2412_IOTIMING
+	help
+	  CPU Frequency scaling support for S3C2412 and S3C2413 SoC CPUs.
+
 config ARM_S3C2416_CPUFREQ
 	bool "S3C2416 CPU Frequency scaling support"
 	depends on CPU_S3C2416
@@ -108,6 +158,14 @@ config ARM_S3C2416_CPUFREQ_VCORESCALE
 
 	  If in doubt, say N.
 
+config ARM_S3C2440_CPUFREQ
+	bool "S3C2440/S3C2442 CPU Frequency scaling support"
+	depends on ARM_S3C24XX_CPUFREQ && (CPU_S3C2440 || CPU_S3C2442)
+	select S3C2410_CPUFREQ_UTILS
+	default y
+	help
+	  CPU Frequency scaling support for S3C2440 and S3C2442 SoC CPUs.
+
 config ARM_S3C64XX_CPUFREQ
 	bool "Samsung S3C64XX"
 	depends on CPU_S3C6410
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index 8d58016..a55e3e8 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -63,7 +63,12 @@ obj-$(CONFIG_ARM_OMAP2PLUS_CPUFREQ)	+= omap-cpufreq.o
 obj-$(CONFIG_PXA25x)			+= pxa2xx-cpufreq.o
 obj-$(CONFIG_PXA27x)			+= pxa2xx-cpufreq.o
 obj-$(CONFIG_PXA3xx)			+= pxa3xx-cpufreq.o
+obj-$(CONFIG_ARM_S3C24XX_CPUFREQ)	+= s3c24xx-cpufreq.o
+obj-$(CONFIG_ARM_S3C24XX_CPUFREQ_DEBUGFS) += s3c24xx-cpufreq-debugfs.o
+obj-$(CONFIG_ARM_S3C2410_CPUFREQ)	+= s3c2410-cpufreq.o
+obj-$(CONFIG_ARM_S3C2412_CPUFREQ)	+= s3c2412-cpufreq.o
 obj-$(CONFIG_ARM_S3C2416_CPUFREQ)	+= s3c2416-cpufreq.o
+obj-$(CONFIG_ARM_S3C2440_CPUFREQ)	+= s3c2440-cpufreq.o
 obj-$(CONFIG_ARM_S3C64XX_CPUFREQ)	+= s3c64xx-cpufreq.o
 obj-$(CONFIG_ARM_S5PV210_CPUFREQ)	+= s5pv210-cpufreq.o
 obj-$(CONFIG_ARM_SPEAR_CPUFREQ)		+= spear-cpufreq.o
diff --git a/arch/arm/mach-s3c24xx/cpufreq-s3c2410.c b/drivers/cpufreq/s3c2410-cpufreq.c
similarity index 100%
rename from arch/arm/mach-s3c24xx/cpufreq-s3c2410.c
rename to drivers/cpufreq/s3c2410-cpufreq.c
diff --git a/arch/arm/mach-s3c24xx/cpufreq-s3c2412.c b/drivers/cpufreq/s3c2412-cpufreq.c
similarity index 99%
rename from arch/arm/mach-s3c24xx/cpufreq-s3c2412.c
rename to drivers/cpufreq/s3c2412-cpufreq.c
index 8bf0f3a..4645b48 100644
--- a/arch/arm/mach-s3c24xx/cpufreq-s3c2412.c
+++ b/drivers/cpufreq/s3c2412-cpufreq.c
@@ -25,13 +25,12 @@
 #include <asm/mach/map.h>
 
 #include <mach/regs-clock.h>
+#include <mach/s3c2412.h>
 
 #include <plat/cpu.h>
 #include <plat/clock.h>
 #include <plat/cpu-freq-core.h>
 
-#include "s3c2412.h"
-
 /* our clock resources. */
 static struct clk *xtal;
 static struct clk *fclk;
diff --git a/arch/arm/mach-s3c24xx/cpufreq-s3c2440.c b/drivers/cpufreq/s3c2440-cpufreq.c
similarity index 100%
rename from arch/arm/mach-s3c24xx/cpufreq-s3c2440.c
rename to drivers/cpufreq/s3c2440-cpufreq.c
diff --git a/arch/arm/mach-s3c24xx/cpufreq-debugfs.c b/drivers/cpufreq/s3c24xx-cpufreq-debugfs.c
similarity index 100%
rename from arch/arm/mach-s3c24xx/cpufreq-debugfs.c
rename to drivers/cpufreq/s3c24xx-cpufreq-debugfs.c
diff --git a/arch/arm/mach-s3c24xx/cpufreq.c b/drivers/cpufreq/s3c24xx-cpufreq.c
similarity index 100%
rename from arch/arm/mach-s3c24xx/cpufreq.c
rename to drivers/cpufreq/s3c24xx-cpufreq.c
-- 
1.7.12.rc2.18.g61b472e



From viresh.kumar at linaro.org  Thu Apr  4 08:54:16 2013
From: viresh.kumar at linaro.org (Viresh Kumar)
Date: Thu,  4 Apr 2013 18:24:16 +0530
Subject: [PATCH 08/18] cpufreq: sa11x0: move cpufreq driver to drivers/cpufreq
In-Reply-To: <cover.1365079581.git.viresh.kumar@linaro.org>
References: <cover.1365079581.git.viresh.kumar@linaro.org>
Message-ID: <b9e9ae96e4aade16c8c158872d998708479361be.1365079581.git.viresh.kumar@linaro.org>

This patch moves cpufreq driver of ARM based sa11x0 platform to drivers/cpufreq.

Cc: Russell King <linux at arm.linux.org.uk>
Cc: linux-arm-kernel at lists.infradead.org
Signed-off-by: Viresh Kumar <viresh.kumar at linaro.org>
Acked-by: Arnd Bergmann <arnd at arndb.de>
---
 arch/arm/Kconfig                                   |  8 -------
 arch/arm/mach-sa1100/Kconfig                       | 26 +++++++++++-----------
 arch/arm/mach-sa1100/Makefile                      |  3 ---
 arch/arm/mach-sa1100/include/mach/generic.h        |  1 +
 drivers/cpufreq/Kconfig.arm                        |  6 +++++
 drivers/cpufreq/Makefile                           |  2 ++
 .../cpufreq/sa1100-cpufreq.c                       |  3 +--
 .../cpufreq/sa1110-cpufreq.c                       |  3 +--
 8 files changed, 24 insertions(+), 28 deletions(-)
 create mode 100644 arch/arm/mach-sa1100/include/mach/generic.h
 rename arch/arm/mach-sa1100/cpu-sa1100.c => drivers/cpufreq/sa1100-cpufreq.c (99%)
 rename arch/arm/mach-sa1100/cpu-sa1110.c => drivers/cpufreq/sa1110-cpufreq.c (99%)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 70366b7..bbc8953 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -2150,7 +2150,6 @@ endmenu
 menu "CPU Power Management"
 
 if ARCH_HAS_CPUFREQ
-
 source "drivers/cpufreq/Kconfig"
 
 config CPU_FREQ_IMX
@@ -2159,13 +2158,6 @@ config CPU_FREQ_IMX
 	select CPU_FREQ_TABLE
 	help
 	  This enables the CPUfreq driver for i.MX CPUs.
-
-config CPU_FREQ_SA1100
-	bool
-
-config CPU_FREQ_SA1110
-	bool
-
 endif
 
 source "drivers/cpuidle/Kconfig"
diff --git a/arch/arm/mach-sa1100/Kconfig b/arch/arm/mach-sa1100/Kconfig
index ca14dbd..04f9784 100644
--- a/arch/arm/mach-sa1100/Kconfig
+++ b/arch/arm/mach-sa1100/Kconfig
@@ -4,7 +4,7 @@ menu "SA11x0 Implementations"
 
 config SA1100_ASSABET
 	bool "Assabet"
-	select CPU_FREQ_SA1110
+	select ARM_SA1110_CPUFREQ
 	help
 	  Say Y here if you are using the Intel(R) StrongARM(R) SA-1110
 	  Microprocessor Development Board (also known as the Assabet).
@@ -20,7 +20,7 @@ config ASSABET_NEPONSET
 
 config SA1100_CERF
 	bool "CerfBoard"
-	select CPU_FREQ_SA1110
+	select ARM_SA1110_CPUFREQ
 	help
 	  The Intrinsyc CerfBoard is based on the StrongARM 1110 (Discontinued).
 	  More information is available at:
@@ -47,7 +47,7 @@ endchoice
 
 config SA1100_COLLIE
 	bool "Sharp Zaurus SL5500"
-	# FIXME: select CPU_FREQ_SA11x0
+	# FIXME: select ARM_SA11x0_CPUFREQ
 	select SHARP_LOCOMO
 	select SHARP_PARAM
 	select SHARP_SCOOP
@@ -56,7 +56,7 @@ config SA1100_COLLIE
 
 config SA1100_H3100
 	bool "Compaq iPAQ H3100"
-	select CPU_FREQ_SA1110
+	select ARM_SA1110_CPUFREQ
 	select HTC_EGPIO
 	help
 	  Say Y here if you intend to run this kernel on the Compaq iPAQ
@@ -67,7 +67,7 @@ config SA1100_H3100
 
 config SA1100_H3600
 	bool "Compaq iPAQ H3600/H3700"
-	select CPU_FREQ_SA1110
+	select ARM_SA1110_CPUFREQ
 	select HTC_EGPIO
 	help
 	  Say Y here if you intend to run this kernel on the Compaq iPAQ
@@ -78,7 +78,7 @@ config SA1100_H3600
 
 config SA1100_BADGE4
 	bool "HP Labs BadgePAD 4"
-	select CPU_FREQ_SA1100
+	select ARM_SA1100_CPUFREQ
 	select SA1111
 	help
 	  Say Y here if you want to build a kernel for the HP Laboratories
@@ -86,7 +86,7 @@ config SA1100_BADGE4
 
 config SA1100_JORNADA720
 	bool "HP Jornada 720"
-	# FIXME: select CPU_FREQ_SA11x0
+	# FIXME: select ARM_SA11x0_CPUFREQ
 	select SA1111
 	help
 	  Say Y here if you want to build a kernel for the HP Jornada 720
@@ -105,14 +105,14 @@ config SA1100_JORNADA720_SSP
 
 config SA1100_HACKKIT
 	bool "HackKit Core CPU Board"
-	select CPU_FREQ_SA1100
+	select ARM_SA1100_CPUFREQ
 	help
 	  Say Y here to support the HackKit Core CPU Board
 	  <http://hackkit.eletztrick.de>;
 
 config SA1100_LART
 	bool "LART"
-	select CPU_FREQ_SA1100
+	select ARM_SA1100_CPUFREQ
 	help
 	  Say Y here if you are using the Linux Advanced Radio Terminal
 	  (also known as the LART).  See <http://www.lartmaker.nl/> for
@@ -120,7 +120,7 @@ config SA1100_LART
 
 config SA1100_NANOENGINE
 	bool "nanoEngine"
-	select CPU_FREQ_SA1110
+	select ARM_SA1110_CPUFREQ
 	select PCI
 	select PCI_NANOENGINE
 	help
@@ -130,7 +130,7 @@ config SA1100_NANOENGINE
 
 config SA1100_PLEB
 	bool "PLEB"
-	select CPU_FREQ_SA1100
+	select ARM_SA1100_CPUFREQ
 	help
 	  Say Y here if you are using version 1 of the Portable Linux
 	  Embedded Board (also known as PLEB).
@@ -139,7 +139,7 @@ config SA1100_PLEB
 
 config SA1100_SHANNON
 	bool "Shannon"
-	select CPU_FREQ_SA1100
+	select ARM_SA1100_CPUFREQ
 	help
 	  The Shannon (also known as a Tuxscreen, and also as a IS2630) was a
 	  limited edition webphone produced by Philips. The Shannon is a SA1100
@@ -148,7 +148,7 @@ config SA1100_SHANNON
 
 config SA1100_SIMPAD
 	bool "Simpad"
-	select CPU_FREQ_SA1110
+	select ARM_SA1110_CPUFREQ
 	help
 	  The SIEMENS webpad SIMpad is based on the StrongARM 1110. There
 	  are two different versions CL4 and SL4. CL4 has 32MB RAM and 16MB
diff --git a/arch/arm/mach-sa1100/Makefile b/arch/arm/mach-sa1100/Makefile
index 1aed9e7..2732eef 100644
--- a/arch/arm/mach-sa1100/Makefile
+++ b/arch/arm/mach-sa1100/Makefile
@@ -8,9 +8,6 @@ obj-m :=
 obj-n :=
 obj-  :=
 
-obj-$(CONFIG_CPU_FREQ_SA1100)		+= cpu-sa1100.o
-obj-$(CONFIG_CPU_FREQ_SA1110)		+= cpu-sa1110.o
-
 # Specific board support
 obj-$(CONFIG_SA1100_ASSABET)		+= assabet.o
 obj-$(CONFIG_ASSABET_NEPONSET)		+= neponset.o
diff --git a/arch/arm/mach-sa1100/include/mach/generic.h b/arch/arm/mach-sa1100/include/mach/generic.h
new file mode 100644
index 0000000..665542e
--- /dev/null
+++ b/arch/arm/mach-sa1100/include/mach/generic.h
@@ -0,0 +1 @@
+#include "../../generic.h"
diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index 1ce61ba..f3f3b14 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -185,6 +185,12 @@ config ARM_S5PV210_CPUFREQ
 
 	  If in doubt, say N.
 
+config ARM_SA1100_CPUFREQ
+	bool
+
+config ARM_SA1110_CPUFREQ
+	bool
+
 config ARM_SPEAR_CPUFREQ
 	bool "SPEAr CPUFreq support"
 	depends on PLAT_SPEAR
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index a55e3e8..7356e0a 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -71,6 +71,8 @@ obj-$(CONFIG_ARM_S3C2416_CPUFREQ)	+= s3c2416-cpufreq.o
 obj-$(CONFIG_ARM_S3C2440_CPUFREQ)	+= s3c2440-cpufreq.o
 obj-$(CONFIG_ARM_S3C64XX_CPUFREQ)	+= s3c64xx-cpufreq.o
 obj-$(CONFIG_ARM_S5PV210_CPUFREQ)	+= s5pv210-cpufreq.o
+obj-$(CONFIG_ARM_SA1100_CPUFREQ)	+= sa1100-cpufreq.o
+obj-$(CONFIG_ARM_SA1110_CPUFREQ)	+= sa1110-cpufreq.o
 obj-$(CONFIG_ARM_SPEAR_CPUFREQ)		+= spear-cpufreq.o
 obj-$(CONFIG_ARCH_TEGRA)		+= tegra-cpufreq.o
 
diff --git a/arch/arm/mach-sa1100/cpu-sa1100.c b/drivers/cpufreq/sa1100-cpufreq.c
similarity index 99%
rename from arch/arm/mach-sa1100/cpu-sa1100.c
rename to drivers/cpufreq/sa1100-cpufreq.c
index 3268761..cff18e8 100644
--- a/arch/arm/mach-sa1100/cpu-sa1100.c
+++ b/drivers/cpufreq/sa1100-cpufreq.c
@@ -91,10 +91,9 @@
 
 #include <asm/cputype.h>
 
+#include <mach/generic.h>
 #include <mach/hardware.h>
 
-#include "generic.h"
-
 struct sa1100_dram_regs {
 	int speed;
 	u32 mdcnfg;
diff --git a/arch/arm/mach-sa1100/cpu-sa1110.c b/drivers/cpufreq/sa1110-cpufreq.c
similarity index 99%
rename from arch/arm/mach-sa1100/cpu-sa1110.c
rename to drivers/cpufreq/sa1110-cpufreq.c
index 38a7733..39c90b6 100644
--- a/arch/arm/mach-sa1100/cpu-sa1110.c
+++ b/drivers/cpufreq/sa1110-cpufreq.c
@@ -27,10 +27,9 @@
 #include <asm/cputype.h>
 #include <asm/mach-types.h>
 
+#include <mach/generic.h>
 #include <mach/hardware.h>
 
-#include "generic.h"
-
 #undef DEBUG
 
 struct sdram_params {
-- 
1.7.12.rc2.18.g61b472e



From dgilbert at interlog.com  Thu Apr  4 09:04:15 2013
From: dgilbert at interlog.com (Douglas Gilbert)
Date: Thu, 04 Apr 2013 09:04:15 -0400
Subject: [PATCH] at91sam9260.dtsi: fix u(s)art pinctrl encoding
Message-ID: <515D7A4F.90707@interlog.com>

A pattern is emerging with sloppy at91 dts(i) files
with pinctrls: the comments are correct and the
corresponding encoding is wrong. The other example that
I fixed was at91sam9x5.dtsi . Makes you wonder how many
people are using this DT stuff in anger ...

This problem was found with AT91SAM9G20 SoCs (Acme's FoxG20).
The attached is against lk 3.9.0-rc5 .

Doug Gilbert
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sam9260_390rc5dg1.patch
Type: text/x-patch
Size: 1443 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130404/fd268187/attachment.bin>

From shawn.guo at linaro.org  Thu Apr  4 09:13:08 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Thu, 4 Apr 2013 21:13:08 +0800
Subject: [PATCH 5/6] ARM: i.MX5: Add PATA and SRTC clocks
In-Reply-To: <1365067509-10186-6-git-send-email-s.hauer@pengutronix.de>
References: <1365067509-10186-1-git-send-email-s.hauer@pengutronix.de>
 <1365067509-10186-6-git-send-email-s.hauer@pengutronix.de>
Message-ID: <20130404131306.GF21790@S2101-09.ap.freescale.net>

On Thu, Apr 04, 2013 at 11:25:08AM +0200, Sascha Hauer wrote:
> This adds the clock gates and the binding documentation
> for PATA and SRTC.
> 
> Signed-off-by: Sascha Hauer <s.hauer at pengutronix.de>

Patch #5 and #6 applied, thanks.



From santosh.shilimkar at ti.com  Thu Apr  4 09:23:26 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Thu, 4 Apr 2013 18:53:26 +0530
Subject: [PATCH v2 08/18] ARM: OMAP5: PM: Add CPU power off in hotplug path
In-Reply-To: <876203uypd.fsf@linaro.org>
References: <1364205910-32392-1-git-send-email-santosh.shilimkar@ti.com>
 <1364205910-32392-9-git-send-email-santosh.shilimkar@ti.com>
 <876203uypd.fsf@linaro.org>
Message-ID: <515D7ECE.6040503@ti.com>

On Thursday 04 April 2013 02:19 AM, Kevin Hilman wrote:
> Santosh Shilimkar <santosh.shilimkar at ti.com> writes:
> 
>> Add power management code to handle the CPU off mode to enable CPUP hotplug
>> mode for OMAP5 devices. Separate suspend finisher is used for OMAP5(Cortex-A15)
>> because it doesn't use SCU power status register and external PL310 L2 cache
>> which makes code flow bit different.
>>
>> Acked-by: Nishanth Menon <nm at ti.com>
>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
> 
> [...]
> 
>> @@ -436,14 +445,21 @@ int __init omap4_mpuss_init(void)
>>  
>>  	if (cpu_is_omap44xx()) {
>>  		omap_pm_ops.finish_suspend = omap4_finish_suspend;
>> +		omap_pm_ops.hotplug_restart = omap_secondary_startup;
>>  		omap_pm_ops.resume = omap4_cpu_resume;
>>  		omap_pm_ops.scu_prepare = scu_pwrst_prepare;
>>  		cpu_context_offset = OMAP4_RM_CPU0_CPU0_CONTEXT_OFFSET;
>>  	} else if (soc_is_omap54xx()) {
>> +		omap_pm_ops.finish_suspend = omap5_finish_suspend;
>> +		omap_pm_ops.hotplug_restart = omap5_secondary_startup;
>>  		cpu_context_offset = OMAP54XX_RM_CPU0_CPU0_CONTEXT_OFFSET;
>>  		enable_mercury_retention_mode();
>>  	}
>>  
>> +	/* Over-write the OMAP4 hook to take care of ROM BUG */
>> +	if (cpu_is_omap446x())
>> +		omap_pm_ops.hotplug_restart = omap_secondary_startup_4460;
> 
> A couple nits...
> 
> I think this would go better at the end of the 'if omap44xx' block
> above.
> 
Nishant commented on this as well. The indentation was looking ugly
and I thought its better to have this BUG hunk separate. I prefer
it this way though if you really insist, i have to change it.

> Also, while you're hear, maybe it's time to rename the current secondary 
> startup functions to match the new one.  IOW omap4_..., omap4460_... and omap5_...
> 
Good idea. Will do it in a separate patch since these have been there in few
files.

Regards,
Santosh



From dgilbert at interlog.com  Thu Apr  4 09:25:42 2013
From: dgilbert at interlog.com (Douglas Gilbert)
Date: Thu, 04 Apr 2013 09:25:42 -0400
Subject: [PATCH] rtc: rtc-at91sam9.c add DT support
In-Reply-To: <515D35C2.7050405@atmel.com>
References: <515CF985.6050009@interlog.com> <515D35C2.7050405@atmel.com>
Message-ID: <515D7F56.90702@interlog.com>

On 13-04-04 04:11 AM, Nicolas Ferre wrote:
> On 04/04/2013 05:54 AM, Douglas Gilbert :
>> Some members of the at91 SoCs use the Real Time Timer (RTT)
>> and the General Purpose Backup Registers (GPBR) to implement
>> a real time clock (RTC). The AT91SAM9G20 is one example.
>>
>> Attached is a patch to add DT support to rtc-at91sam9.c .
>> The patch is against lk 3.9.0-rc5 .
>>
>> Below is a snippet of DT code for the 'G20 that was observed
>> to work with this patch:
>>
>> ahb {
>>      apb {
>>
>>          rtc {
>>              compatible = "atmel,at91sam9-rtc";
>
> The compatible string has to be formed by the name of the first SoC
> compatible with this IP. It turns to be the at91sam9260.
> The second part of the string should be a name that reflects the nature
> of the peripheral. For this binding, I would like to mention the "RTT"
> in the compatibility string (because other drivers can use other RTT
> with other uses).
>
> What do you think about:
> "atmel,at91sam9260-rtt-as-rtc"? or something shorter?

Hi Nicolas,
Johan Hovold suggested:
    atmel,at91sam9260-rtt

I notice (in the G20 doco) that the acronym RTTC is also used
for the rtt registers. What do you want?

>
>>                           /* RTTC followed by GPBR (backup registers) */
>>                           reg = <0xfffffd20 0x10>, <0xfffffd50 0x10>;
>>                           interrupts = <1 4 7>;
>>                           status = "okay";
>
> Last, but not least, when we add a DT binding, it is a requirement to
> add the corresponding documentation in the
> Documentation/devicetree/bindings/rtc/ directory.

I have been underwhelmed by the accuracy and the organisation
of information in that documentation. And the examples are
often misleading given the actual hierarchy of real dtsi/dts
config files.
Give me working examples any day. You could (and should) test
what I gave on a g20ek board.

Also I note there is no "bindings" documentation for
rtc-at91rm9200.c :-) After you, sir ....

Doug Gilbert




From santosh.shilimkar at ti.com  Thu Apr  4 09:37:25 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Thu, 4 Apr 2013 19:07:25 +0530
Subject: [PATCH v2 09/18] ARM: OMAP4+: PM: Restore CPU power state to
 ON with clockdomain force wakeup method
In-Reply-To: <87mwtftjvy.fsf@linaro.org>
References: <1364205910-32392-1-git-send-email-santosh.shilimkar@ti.com>
 <1364205910-32392-10-git-send-email-santosh.shilimkar@ti.com>
 <87mwtftjvy.fsf@linaro.org>
Message-ID: <515D8215.10705@ti.com>

On Thursday 04 April 2013 02:24 AM, Kevin Hilman wrote:
> Santosh Shilimkar <santosh.shilimkar at ti.com> writes:
> 
>> While waking up CPU from off state using clock domain force wakeup, restore
>> the CPU power state to ON state before putting CPU clock domain under
>> hardware control. Otherwise CPU wakeup might fail. The change is recommended
>> for all OMAP4+ devices though the PRCM weakness was observed on OMAP5
>> devices first.
> 
> Sounds reasonable, but can you describe the "weakness" a little more?
> 
> IOW, what exactly happens if this is not done?  It sounds like the CPU
> might immediately go back to retention, but how does that happen unless
> it does a WFI?
> 
Its more of lock-up inside the hardware state machine and results
are UN-predictable. We have seen hard-locks most of the time where system
is just frozen. The hardware gets into wrong state machine if the power
domain state isn't restored. I will add this information to changelog.

> Also, this sounds like a fix to me, and should probably be broken out
> accordingly.
> 
Yeah. You mean a separate patch from the series, right ? This patch
actually can be independently added.

In case you decide to apply it for the fixes branch, updated patch
at end of the email.

Regards,
Santosh

>From a0cef44760d859b63a34603010f8c0621da4b8ab Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar <santosh.shilimkar at ti.com>
Date: Fri, 8 Feb 2013 22:50:58 +0530
Subject: [PATCH] ARM: OMAP4+: PM: Restore CPU power state to ON with
 clockdomain force wakeup method

While waking up CPU from off state using clock domain force wakeup, restore
the CPU power state to ON state before putting CPU clock domain under
hardware control. Otherwise CPU wakeup might fail. The change is recommended
for all OMAP4+ devices though the PRCM weakness was observed on OMAP5
devices first.

As a result of weakness, lock-up is observed inside the hardware state
machine of local CPU PRCM and results are UN-predictable as per designers.
In software testing, we have seen hard-locks most of the time where system
gets frozen. With power domain state restored, system behaves correctly.

So update the code accordingly.

Acked-by: Nishanth Menon <nm at ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
---
 arch/arm/mach-omap2/cpuidle44xx.c |    1 +
 arch/arm/mach-omap2/omap-smp.c    |   12 ++++++++++--
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/cpuidle44xx.c b/arch/arm/mach-omap2/cpuidle44xx.c
index 944e64a..9de47a7 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -131,6 +131,7 @@ static int omap4_enter_idle_coupled(struct cpuidle_device *dev,
 	/* Wakeup CPU1 only if it is not offlined */
 	if (dev->cpu == 0 && cpumask_test_cpu(1, cpu_online_mask)) {
 		clkdm_wakeup(cpu_clkdm[1]);
+		omap_set_pwrdm_state(cpu_pd[1], PWRDM_POWER_ON);
 		clkdm_allow_idle(cpu_clkdm[1]);
 	}
 
diff --git a/arch/arm/mach-omap2/omap-smp.c b/arch/arm/mach-omap2/omap-smp.c
index 5b20165..8106e8d 100644
--- a/arch/arm/mach-omap2/omap-smp.c
+++ b/arch/arm/mach-omap2/omap-smp.c
@@ -83,6 +83,7 @@ static int __cpuinit omap4_boot_secondary(unsigned int cpu, struct task_struct *
 {
 	static struct clockdomain *cpu1_clkdm;
 	static bool booted;
+	static struct powerdomain *cpu1_pwrdm;
 	void __iomem *base = omap_get_wakeupgen_base();
 
 	/*
@@ -102,8 +103,10 @@ static int __cpuinit omap4_boot_secondary(unsigned int cpu, struct task_struct *
 	else
 		__raw_writel(0x20, base + OMAP_AUX_CORE_BOOT_0);
 
-	if (!cpu1_clkdm)
+	if (!cpu1_clkdm && !cpu1_pwrdm) {
 		cpu1_clkdm = clkdm_lookup("mpu1_clkdm");
+		cpu1_pwrdm = pwrdm_lookup("cpu1_pwrdm");
+	}
 
 	/*
 	 * The SGI(Software Generated Interrupts) are not wakeup capable
@@ -116,7 +119,7 @@ static int __cpuinit omap4_boot_secondary(unsigned int cpu, struct task_struct *
 	 * Section :
 	 *	4.3.4.2 Power States of CPU0 and CPU1
 	 */
-	if (booted) {
+	if (booted && cpu1_pwrdm && cpu1_clkdm) {
 		/*
 		 * GIC distributor control register has changed between
 		 * CortexA9 r1pX and r2pX. The Control Register secure
@@ -137,7 +140,12 @@ static int __cpuinit omap4_boot_secondary(unsigned int cpu, struct task_struct *
 			gic_dist_disable();
 		}
 
+		/*
+		 * Ensure that CPU power state is set to ON to avoid CPU
+		 * powerdomain transition on wfi
+		 */
 		clkdm_wakeup(cpu1_clkdm);
+		omap_set_pwrdm_state(cpu1_pwrdm, PWRDM_POWER_ON);
 		clkdm_allow_idle(cpu1_clkdm);
 
 		if (IS_PM44XX_ERRATUM(PM_OMAP4_ROM_SMP_BOOT_ERRATUM_GICD)) {
-- 
1.7.9.5




From santosh.shilimkar at ti.com  Thu Apr  4 09:46:50 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Thu, 4 Apr 2013 19:16:50 +0530
Subject: [PATCH v2 11/18] ARM: OMAP5: PM: Add L2 memory power down support
In-Reply-To: <87ehertjpf.fsf@linaro.org>
References: <1364205910-32392-1-git-send-email-santosh.shilimkar@ti.com>
 <1364205910-32392-12-git-send-email-santosh.shilimkar@ti.com>
 <87ehertjpf.fsf@linaro.org>
Message-ID: <515D844A.4070407@ti.com>

On Thursday 04 April 2013 02:28 AM, Kevin Hilman wrote:
> Santosh Shilimkar <santosh.shilimkar at ti.com> writes:
> 
>> When the entire MPUSS cluster is powered down in device off state, L2 cache
>> memory looses it's content and hence while targetting such a state,
>> l2 cache needs to be flushed to main memory.
>>
>> Add the necessary low power code support for the same.
>>
>> Acked-by: Nishanth Menon <nm at ti.com>
>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
>> ---
>>  arch/arm/mach-omap2/omap-secure.h     |    1 +
>>  arch/arm/mach-omap2/sleep_omap4plus.S |   21 +++++++++++++++++++++
>>  2 files changed, 22 insertions(+)
>>
>> diff --git a/arch/arm/mach-omap2/omap-secure.h b/arch/arm/mach-omap2/omap-secure.h
>> index 1739468..a171a5a 100644
>> --- a/arch/arm/mach-omap2/omap-secure.h
>> +++ b/arch/arm/mach-omap2/omap-secure.h
>> @@ -47,6 +47,7 @@
>>  #define OMAP4_MON_L2X0_PREFETCH_INDEX	0x113
>>  #define OMAP5_MON_CACHES_CLEAN_INDEX	0x103
>>  #define OMAP5_MON_AUX_CTRL_INDEX	0x107
>> +#define OMAP5_MON_L2AUX_CTRL_INDEX	0x104
> 
> this #define is not used in this patch.
> 
Yep. Will drop above hunk.
I forgot to drop this one after dropping the L2X0
setting from last version. Its no longer needed on OMAP5
ES2.0.

Regards,
Santosh


From santosh.shilimkar at ti.com  Thu Apr  4 09:47:30 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Thu, 4 Apr 2013 19:17:30 +0530
Subject: [PATCH v2 12/18] ARM: OMAP4: CPUidle: Avoid double idle driver
 registration
In-Reply-To: <877gkjtjht.fsf@linaro.org>
References: <1364205910-32392-1-git-send-email-santosh.shilimkar@ti.com>
 <1364205910-32392-13-git-send-email-santosh.shilimkar@ti.com>
 <877gkjtjht.fsf@linaro.org>
Message-ID: <515D8472.4030204@ti.com>

On Thursday 04 April 2013 02:33 AM, Kevin Hilman wrote:
> Santosh Shilimkar <santosh.shilimkar at ti.com> writes:
> 
>> OMAP4 CPUidle driver registration call is under a loop which leads
>> to calling cpuidle_register_driver twice which is not intended.
>>
>> Fix it by moving the driver registration outside the loop.
>>
>> Reported-by: Nishanth Menon <nm at ti.com>
>> Acked-by: Nishanth Menon <nm at ti.com>
>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
> 
> Looks good.
> 
> I've already got a for_3.10/fixes/cpuidle branch going, so I'll apply
> this one there.
> 
ok.

Regards,
Santosh



From santosh.shilimkar at ti.com  Thu Apr  4 09:48:04 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Thu, 4 Apr 2013 19:18:04 +0530
Subject: [PATCH v2 13/18] ARM: OMAP: CPUidle: Unregister drivere on device
 registration failure
In-Reply-To: <871uartjgg.fsf@linaro.org>
References: <1364205910-32392-1-git-send-email-santosh.shilimkar@ti.com>
 <1364205910-32392-14-git-send-email-santosh.shilimkar@ti.com>
 <871uartjgg.fsf@linaro.org>
Message-ID: <515D8494.20305@ti.com>

On Thursday 04 April 2013 02:33 AM, Kevin Hilman wrote:
> Santosh Shilimkar <santosh.shilimkar at ti.com> writes:
> 
>> If the CPUidle device registration fails for some reason, we should
>> unregister the driver on error path.
>>
>> Fix the code accordingly. Also when at it, check of the driver registration
>> failure too.
>>
>> Acked-by: Nishanth Menon <nm at ti.com>
>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
> 
> Adding to my for_3.10/fixes/cpuidle branch.
> 
Thanks.

regards,
Santosh



From santosh.shilimkar at ti.com  Thu Apr  4 09:48:19 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Thu, 4 Apr 2013 19:18:19 +0530
Subject: [PATCH v2 14/18] ARM: OMAP4: CPUidle: Make C-state description
 field more precise
In-Reply-To: <87vc83s4sv.fsf@linaro.org>
References: <1364205910-32392-1-git-send-email-santosh.shilimkar@ti.com>
 <1364205910-32392-15-git-send-email-santosh.shilimkar@ti.com>
 <87vc83s4sv.fsf@linaro.org>
Message-ID: <515D84A3.6070007@ti.com>

On Thursday 04 April 2013 02:35 AM, Kevin Hilman wrote:
> Santosh Shilimkar <santosh.shilimkar at ti.com> writes:
> 
>> It is useful to know the CPU power state along with MPUSS power state
>> in a supported C-state. Since the data is available via sysfs, one can
>> avoid scrolling the source code for precise construction of C-state.
>>
>> Reported-by: Nishanth Menon <nm at ti.com>
>> Acked-by: Nishanth Menon <nm at ti.com>
>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
> 
> Nice.
> 
> Adding to for_3.10/fixes/cpuidle branch.
> 
Thanks.

regards,
Santosh


From hechtb at gmail.com  Thu Apr  4 09:47:34 2013
From: hechtb at gmail.com (Bastian Hecht)
Date: Thu, 4 Apr 2013 15:47:34 +0200
Subject: [PATCH v3 1/2] irqchip: intc-irqpin: Add support for shared
 interrupt lines
In-Reply-To: <20130403074604.GC30989@verge.net.au>
References: <1364296699-20919-1-git-send-email-hechtb+renesas@gmail.com>
 <20130327045942.GH25431@verge.net.au>
 <CABYn4sx_pRxgdM3kD3okmt8xbCFas+T0cczQO=RF75Q8Bt2e_Q@mail.gmail.com>
 <20130403074604.GC30989@verge.net.au>
Message-ID: <CABYn4szuJGFNTQUEoYcRAa34cj+fK=0RpaATDksu3mAM3L8vgg@mail.gmail.com>

Hi Simon,

ok I've sent out a patch series with the reference DT code. I've had
to adapt a couple of things and the device list is rather short. How
long do I have to augment it a bit before the merge window closes?

Thanks,

 Bastian


2013/4/3 Simon Horman <horms at verge.net.au>:
> On Wed, Mar 27, 2013 at 02:50:05PM +0100, Bastian Hecht wrote:
>> Hi Simon,
>>
>> 2013/3/27 Simon Horman <horms at verge.net.au>:
>> > On Tue, Mar 26, 2013 at 12:18:18PM +0100, Bastian Hecht wrote:
>> >> On some hardware we don't have a 1-1 mapping from the external
>> >> interrupts coming from INTC to the GIC SPI pins. We can however
>> >> share lines to demux incoming IRQs on these SoCs.
>> >>
>> >> This patch enables the intc_irqpin driver to detect requests for shared
>> >> interrupt lines and demuxes them properly by querying the INTC INTREQx0A
>> >> registers.
>> >>
>> >> If you need multiple shared intc_irqpin device instances, be sure to mask
>> >> out all interrupts on the INTC that share the one line before you start
>> >> to register them. Else you run into IRQ floods that would be caused by
>> >> interrupts for which no handler has been set up yet when the first
>> >> intc_irqpin device is registered.
>> >>
>> >> Signed-off-by: Bastian Hecht <hechtb+renesas at gmail.com>
>> >> Acked-by: Magnus Damm <damm at opensource.se>
>> >
>> > Thanks, I will see about queuing up these changes for v3.10.
>> >
>> >
>> > I believe that with these changes it should be possible to rebase/rework
>> > armadillo800eva-reference so that it no longer uses the unmerged INTC
>> > DT bindings. Would it be possible for you to see about making a fresh
>> > version of armadillo800eva-reference that is based on the next branch
>> > in the Renesas tree plus this series of two patches?
>>
>> yes ok, I'll prepare a new armadillo reference version. The patches
>> were based on all+next, but I'll post a v4 rebased on next.
>> I'll post a separate patch series for the reference code if you don't
>> mind, as this might take a few days to be done.
>
> Hi Bastian,
>
> gentle nudge with regards to a fresh armadillo-reference.


From robherring2 at gmail.com  Thu Apr  4 09:49:10 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Thu, 04 Apr 2013 08:49:10 -0500
Subject: [PATCH v6 1/8] dt: describe base reset signal binding
In-Reply-To: <1364488523-20310-2-git-send-email-p.zabel@pengutronix.de>
References: <1364488523-20310-1-git-send-email-p.zabel@pengutronix.de>
 <1364488523-20310-2-git-send-email-p.zabel@pengutronix.de>
Message-ID: <515D84D6.8090107@gmail.com>

On 03/28/2013 11:35 AM, Philipp Zabel wrote:
> From: Stephen Warren <swarren at nvidia.com>
> 
> This binding is intended to represent the hardware reset signals present
> internally in most IC (SoC, FPGA, ...) designs.
> It consists of a binding for a reset controller device (provider), and a
> pair of properties, "resets" and "reset-names", to link a device node
> (consumer) to its reset controller via phandle, similarly to the clock
> and interrupt bindings.
> 
> The reset controller has all information necessary to reset the consumer
> device. That could be provided via device tree, or it could be implemented
> in hardware.
> The aim is to enable device drivers to request a framework API to issue a
> reset simply by providing their struct device pointer as the most common
> case.
> 
> Signed-off-by: Stephen Warren <swarren at nvidia.com>
> Signed-off-by: Philipp Zabel <p.zabel at pengutronix.de>
> Reviewed-by: Shawn Guo <shawn.guo at linaro.org>
> Reviewed-by: Marek Vasut <marex at denx.de>

Looks good.

Acked-by: Rob Herring <rob.herring at calxeda.com>

Rob

> ---
>  Documentation/devicetree/bindings/reset/reset.txt | 75 +++++++++++++++++++++++
>  1 file changed, 75 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/reset/reset.txt
> 
> diff --git a/Documentation/devicetree/bindings/reset/reset.txt b/Documentation/devicetree/bindings/reset/reset.txt
> new file mode 100644
> index 0000000..31db6ff
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/reset/reset.txt
> @@ -0,0 +1,75 @@
> += Reset Signal Device Tree Bindings =
> +
> +This binding is intended to represent the hardware reset signals present
> +internally in most IC (SoC, FPGA, ...) designs. Reset signals for whole
> +standalone chips are most likely better represented as GPIOs, although there
> +are likely to be exceptions to this rule.
> +
> +Hardware blocks typically receive a reset signal. This signal is generated by
> +a reset provider (e.g. power management or clock module) and received by a
> +reset consumer (the module being reset, or a module managing when a sub-
> +ordinate module is reset). This binding exists to represent the provider and
> +consumer, and provide a way to couple the two together.
> +
> +A reset signal is represented by the phandle of the provider, plus a reset
> +specifier - a list of DT cells that represents the reset signal within the
> +provider. The length (number of cells) and semantics of the reset specifier
> +are dictated by the binding of the reset provider, although common schemes
> +are described below.
> +
> +A word on where to place reset signal consumers in device tree: It is possible
> +in hardware for a reset signal to affect multiple logically separate HW blocks
> +at once. In this case, it would be unwise to represent this reset signal in
> +the DT node of each affected HW block, since if activated, an unrelated block
> +may be reset. Instead, reset signals should be represented in the DT node
> +where it makes most sense to control it; this may be a bus node if all
> +children of the bus are affected by the reset signal, or an individual HW
> +block node for dedicated reset signals. The intent of this binding is to give
> +appropriate software access to the reset signals in order to manage the HW,
> +rather than to slavishly enumerate the reset signal that affects each HW
> +block.
> +
> += Reset providers =
> +
> +Required properties:
> +#reset-cells:	Number of cells in a reset specifier; Typically 0 for nodes
> +		with a single reset output and 1 for nodes with multiple
> +		reset outputs.
> +
> +For example:
> +
> +	rst: reset-controller {
> +		#reset-cells = <1>;
> +	};
> +
> += Reset consumers =
> +
> +Required properties:
> +resets:		List of phandle and reset specifier pairs, one pair
> +		for each reset signal that affects the device, or that the
> +		device manages. Note: if the reset provider specifies '0' for
> +		#reset-cells, then only the phandle portion of the pair will
> +		appear.
> +
> +Optional properties:
> +reset-names:	List of reset signal name strings sorted in the same order as
> +		the resets property. Consumers drivers will use reset-names to
> +		match reset signal names with reset specifiers.
> +
> +For example:
> +
> +	device {
> +		resets = <&rst 20>;
> +		reset-names = "reset";
> +	};
> +
> +This represents a device with a single reset signal named "reset".
> +
> +	bus {
> +		resets = <&rst 10> <&rst 11> <&rst 12> <&rst 11>;
> +		reset-names = "i2s1", "i2s2", "dma", "mixer";
> +	};
> +
> +This represents a bus that controls the reset signal of each of four sub-
> +ordinate devices. Consider for example a bus that fails to operate unless no
> +child device has reset asserted.
> 



From gregory.clement at free-electrons.com  Thu Apr  4 09:55:01 2013
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Thu, 04 Apr 2013 15:55:01 +0200
Subject: [PATCH] arm: mvebu: Fix the memory size on the Mirabox
In-Reply-To: <20130329193716.GA7127@localhost>
References: <1364579477-19018-1-git-send-email-ryan@presslab.us>
 <20130329180447.GK13280@titan.lakedaemon.net>
 <CABx3TkVK86b8Ku4EvUVe8OBtprwKW6YtJ7OU6YVHa3Bd5s7DsQ@mail.gmail.com>
 <20130329193716.GA7127@localhost>
Message-ID: <515D8635.4080903@free-electrons.com>

On 03/29/2013 08:37 PM, Ezequiel Garcia wrote:
> On Fri, Mar 29, 2013 at 11:09:23AM -0700, Ryan Press wrote:
>> Hi Jason,
>>
>> On Fri, Mar 29, 2013 at 11:04 AM, Jason Cooper <jason at lakedaemon.net> wrote:
>>> On Fri, Mar 29, 2013 at 10:51:17AM -0700, Ryan Press wrote:
>>>> The memory size in the device tree is only 512 MB, but the
>>>> Mirabox actually has 1 GB.
>>>>
>>>> Tested the change with memtester and no problems found.
>>>>
>>>> Signed-off-by: Ryan Press <ryan at presslab.us>
>>>> ---
>>>>  arch/arm/boot/dts/armada-370-mirabox.dts | 2 +-
>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> Thanks for the patch.  It looks good, but please don't forget to Cc: the
>>> maintainers (Andrew Lunn, Gregory Clemente, and myself).  I almost
>>> missed this one. :)
>>>
> 
> As far as I can remember, Gregory has a Mirabox with only 512 MiB,
> which means some boards were shipped with 512 MiB and some with 1 GiB.
> Moreover, apparently nothing can distinguish one from the other.
> 
> @Gregory: can you confirm this?

I saw that you eventually found a solution, but just in case you still
wait for my answer: I confirm that my board have only 512MiB (according to
U-Boot)

> 
> If Gregory confirms this, then we shouldn't apply this patch.
> Don't forget in-kernel DTS are only meant for developers and
> for reference. The vendor (Globalscale in this case) has to ship
> a proper DTS for each board.
> 
>>> thx,
>>>
>>> Jason.
>>
>> Okay I didn't know I needed to do that.  Thanks!
>>
> 
> Although it's not mandatory, you can do a 'git blame' on the file you're
> patching and find out who should you put on Cc.
> 


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From santosh.shilimkar at ti.com  Thu Apr  4 09:59:09 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Thu, 4 Apr 2013 19:29:09 +0530
Subject: [PATCH v2 16/18] ARM: OMAP4+: CPUidle: Deprecate use of
 omap4_mpuss_read_prev_context_state()
In-Reply-To: <876203qos1.fsf@linaro.org>
References: <1364205910-32392-1-git-send-email-santosh.shilimkar@ti.com>
 <1364205910-32392-17-git-send-email-santosh.shilimkar@ti.com>
 <876203qos1.fsf@linaro.org>
Message-ID: <515D872D.9070404@ti.com>

On Thursday 04 April 2013 03:07 AM, Kevin Hilman wrote:
> Santosh Shilimkar <santosh.shilimkar at ti.com> writes:
> 
>> Current OMAP4 CPUIdle driver is using omap4_mpuss_read_prev_context_state()
>> function to check whether the MPU cluster lost context or not. Thanks to
>> couple CPUIdle, cluster low power entry is almost guaranteed and hence
>> the programmed cluster check is enough in idle exit path. The API was
>> more of an optimization for corner cases, where if the cluster low power
>> entry fails for some reason, the cluster context restore gets skipped.
>>
>> Moving forward, OMAP CPUidle drivers needs to be moved to drivers/idle/*
>> once the PRM/CM code gets moved to drivers. This patch also reduces one
>> dependency with platform code for idle driver movement.
>>
>> Acked-by: Nishanth Menon <nm at ti.com>
>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
> 
> Looks good, but I find the changelog a bit confusing.
> 
> Below is a slightly modified patch (I only modified the changelog).  If
> those changes are OK with you, I'll add it to my cpuidle branch as well.
> 
Looks good to me Kevin. Thanks for the change-log update.

Regards,
Santosh



From santosh.shilimkar at ti.com  Thu Apr  4 10:04:47 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Thu, 4 Apr 2013 19:34:47 +0530
Subject: [PATCH v2 15/18] ARM: OMAP4+: CPUidle: Consolidate idle driver
 for OMAP5 support
In-Reply-To: <87ip43s4l8.fsf@linaro.org>
References: <1364205910-32392-1-git-send-email-santosh.shilimkar@ti.com>
 <1364205910-32392-16-git-send-email-santosh.shilimkar@ti.com>
 <87ip43s4l8.fsf@linaro.org>
Message-ID: <515D887F.8070901@ti.com>

On Thursday 04 April 2013 02:40 AM, Kevin Hilman wrote:
> Santosh Shilimkar <santosh.shilimkar at ti.com> writes:
> 
>> The OMAP5 idle driver can re-use most of OMAP4 CPUidle driver
>> implementation. Also the next derivative SOCs are going to re-use
>> the MPUSS so, same driver with minor updates can be re-used.
>>
>> Prepare the code so that its easier to add CPUidle support for
>> OMAP5 devices.
>>
>> Acked-by: Nishanth Menon <nm at ti.com>
>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
>> ---
>>  arch/arm/mach-omap2/cpuidle44xx.c |   31 ++++++++++++++++---------------
>>  1 file changed, 16 insertions(+), 15 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/cpuidle44xx.c b/arch/arm/mach-omap2/cpuidle44xx.c
>> index b8a22f0..ac6d526 100644
>> --- a/arch/arm/mach-omap2/cpuidle44xx.c
>> +++ b/arch/arm/mach-omap2/cpuidle44xx.c
>> @@ -1,7 +1,7 @@
>>  /*
>> - * OMAP4 CPU idle Routines
>> + * OMAP4PLUS CPU idle Routines
> 
> nit: s/PLUS/+/ 
> 
> in a few other places in this patch also.
> 
yes. Will update that.

>> @@ -24,13 +24,13 @@
>>  #include "clockdomain.h"
>>  
>>  /* Machine specific information */
>> -struct omap4_idle_statedata {
>> +struct idle_statedata {
>>  	u32 cpu_state;
>>  	u32 mpu_logic_state;
>>  	u32 mpu_state;
>>  };
>>  
>> -static struct omap4_idle_statedata omap4_idle_data[] = {
>> +static struct idle_statedata omap4_idle_data[] = {
>>  	{
>>  		.cpu_state = PWRDM_POWER_ON,
>>  		.mpu_state = PWRDM_POWER_ON,
>> @@ -53,11 +53,12 @@ static struct clockdomain *cpu_clkdm[NR_CPUS];
>>  
>>  static atomic_t abort_barrier;
>>  static bool cpu_done[NR_CPUS];
>> +static struct idle_statedata *state_ptr = &omap4_idle_data[0];
> 
> The assignment at init time (from the next patch) should be done here
> for 44xx, and the next patch can just add OMAP5 support.
> 
You don't need that to be differentiated at init at this
patch since only OMAP4 is supported and static assignment takes care
of it. Next patch ofcouse we need to differentiate and hence added
the checks there.

Regards,
Santosh





From dirk.behme at de.bosch.com  Thu Apr  4 10:03:29 2013
From: dirk.behme at de.bosch.com (Dirk Behme)
Date: Thu, 4 Apr 2013 16:03:29 +0200
Subject: [PATCH] ARM i.MX6: Fix ldb_di clock selection
Message-ID: <1365084209-27240-1-git-send-email-dirk.behme@de.bosch.com>

According to the recent i.MX6 Quad technical reference manual, mode 0x4 (100b)
of the CCM_CS2DCR register (address 0x020C402C) bits [11-9] and [14-12] select
the PLL3 clock, and not the PLL3 PFD1 540M clock. In our code, the PLL3 root
clock is named 'pll3_usb_otg', select this instead of the 540M clock.

Signed-off-by: Dirk Behme <dirk.behme at de.bosch.com>
CC: Shawn Guo <shawn.guo at linaro.org>
---
 arch/arm/mach-imx/clk-imx6q.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-imx/clk-imx6q.c b/arch/arm/mach-imx/clk-imx6q.c
index 2f9ff93..57bd680 100644
--- a/arch/arm/mach-imx/clk-imx6q.c
+++ b/arch/arm/mach-imx/clk-imx6q.c
@@ -115,7 +115,7 @@ static const char *gpu2d_core_sels[]	= { "axi", "pll3_usb_otg", "pll2_pfd0_352m"
 static const char *gpu3d_core_sels[]	= { "mmdc_ch0_axi", "pll3_usb_otg", "pll2_pfd1_594m", "pll2_pfd2_396m", };
 static const char *gpu3d_shader_sels[] = { "mmdc_ch0_axi", "pll3_usb_otg", "pll2_pfd1_594m", "pll2_pfd9_720m", };
 static const char *ipu_sels[]		= { "mmdc_ch0_axi", "pll2_pfd2_396m", "pll3_120m", "pll3_pfd1_540m", };
-static const char *ldb_di_sels[]	= { "pll5_video", "pll2_pfd0_352m", "pll2_pfd2_396m", "mmdc_ch1_axi", "pll3_pfd1_540m", };
+static const char *ldb_di_sels[]	= { "pll5_video", "pll2_pfd0_352m", "pll2_pfd2_396m", "mmdc_ch1_axi", "pll3_usb_otg", };
 static const char *ipu_di_pre_sels[]	= { "mmdc_ch0_axi", "pll3_usb_otg", "pll5_video", "pll2_pfd0_352m", "pll2_pfd2_396m", "pll3_pfd1_540m", };
 static const char *ipu1_di0_sels[]	= { "ipu1_di0_pre", "dummy", "dummy", "ldb_di0", "ldb_di1", };
 static const char *ipu1_di1_sels[]	= { "ipu1_di1_pre", "dummy", "dummy", "ldb_di0", "ldb_di1", };
-- 
1.8.2



From cjb at laptop.org  Thu Apr  4 10:07:16 2013
From: cjb at laptop.org (Chris Ball)
Date: Thu, 04 Apr 2013 10:07:16 -0400
Subject: [PATCH 2/2] mmc: mxs-mmc: add non-removeable property
In-Reply-To: <1364223751-28253-3-git-send-email-mkl@pengutronix.de> (Marc
 Kleine-Budde's message of "Mon, 25 Mar 2013 16:02:31 +0100")
References: <1364223751-28253-1-git-send-email-mkl@pengutronix.de>
 <1364223751-28253-3-git-send-email-mkl@pengutronix.de>
Message-ID: <87r4iqpey3.fsf@octavius.laptop.org>

Hi,

On Mon, Mar 25 2013, Marc Kleine-Budde wrote:
> +	host->non_removeable = of_property_read_bool(np, "non-removable");
> +	if (host->non_removeable)
> +		mmc->caps |= MMC_CAP_NONREMOVABLE;

The correct spelling is "non_removable", as used in the DT property.

Thanks,

- Chris.
-- 
Chris Ball   <cjb at laptop.org>   <http://printf.net/>
One Laptop Per Child


From nicolas.ferre at atmel.com  Thu Apr  4 10:08:04 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Thu, 4 Apr 2013 16:08:04 +0200
Subject: [PATCH] rtc: rtc-at91sam9.c add DT support
In-Reply-To: <515D7F56.90702@interlog.com>
References: <515CF985.6050009@interlog.com> <515D35C2.7050405@atmel.com>
 <515D7F56.90702@interlog.com>
Message-ID: <515D8944.2060308@atmel.com>

On 04/04/2013 03:25 PM, Douglas Gilbert :
> On 13-04-04 04:11 AM, Nicolas Ferre wrote:
>> On 04/04/2013 05:54 AM, Douglas Gilbert :
>>> Some members of the at91 SoCs use the Real Time Timer (RTT)
>>> and the General Purpose Backup Registers (GPBR) to implement
>>> a real time clock (RTC). The AT91SAM9G20 is one example.
>>>
>>> Attached is a patch to add DT support to rtc-at91sam9.c .
>>> The patch is against lk 3.9.0-rc5 .
>>>
>>> Below is a snippet of DT code for the 'G20 that was observed
>>> to work with this patch:
>>>
>>> ahb {
>>>      apb {
>>>
>>>          rtc {
>>>              compatible = "atmel,at91sam9-rtc";
>>
>> The compatible string has to be formed by the name of the first SoC
>> compatible with this IP. It turns to be the at91sam9260.
>> The second part of the string should be a name that reflects the nature
>> of the peripheral. For this binding, I would like to mention the "RTT"
>> in the compatibility string (because other drivers can use other RTT
>> with other uses).
>>
>> What do you think about:
>> "atmel,at91sam9260-rtt-as-rtc"? or something shorter?
> 
> Hi Nicolas,
> Johan Hovold suggested:
>    atmel,at91sam9260-rtt

Yes, but I fear this could bring confusion if someone is building a RTT
driver that is not targeted at acting as a RTC...

> I notice (in the G20 doco) that the acronym RTTC is also used

The "C" at the end stands for "Controller" (not very useful convention
in my opinion).

> for the rtt registers. What do you want?

I found xxx-rtt-as-rtc or xxx-rtt-rtc but not completely satisfied with
any of them...

>>>                           /* RTTC followed by GPBR (backup registers) */
>>>                           reg = <0xfffffd20 0x10>, <0xfffffd50 0x10>;
>>>                           interrupts = <1 4 7>;
>>>                           status = "okay";
>>
>> Last, but not least, when we add a DT binding, it is a requirement to
>> add the corresponding documentation in the
>> Documentation/devicetree/bindings/rtc/ directory.
> 
> I have been underwhelmed by the accuracy and the organisation
> of information in that documentation. And the examples are
> often misleading given the actual hierarchy of real dtsi/dts
> config files.

Oh, really? I will have a look one of those days...


> Give me working examples any day. You could (and should) test
> what I gave on a g20ek board.
> 
> Also I note there is no "bindings" documentation for
> rtc-at91rm9200.c :-) After you, sir ....

Already submitted, my dear ;-)
Here:
http://ozlabs.org/~akpm/mmots/broken-out/drivers-rtc-rtc-at91rm9200c-add-dt-support.patch

Bye,
-- 
Nicolas Ferre


From fabio.baltieri at linaro.org  Thu Apr  4 10:08:27 2013
From: fabio.baltieri at linaro.org (Fabio Baltieri)
Date: Thu, 4 Apr 2013 16:08:27 +0200
Subject: [PATCH 2/3] clk: ux500: abx500: Define clock tree for ab850x
In-Reply-To: <1364943987-1338-3-git-send-email-ulf.hansson@stericsson.com>
References: <1364943987-1338-1-git-send-email-ulf.hansson@stericsson.com>
 <1364943987-1338-3-git-send-email-ulf.hansson@stericsson.com>
Message-ID: <20130404140827.GA11868@balto.lan>

Hi Ulf,

On Wed, Apr 03, 2013 at 01:06:26AM +0200, Ulf Hansson wrote:
> From: Ulf Hansson <ulf.hansson at linaro.org>
> 
> The patch setups the first version of the clock tree for ab850x, which
> is used by u8500 platforms. Mainly sysctrl clocks are used.

I was just going to ask you if you had plans to develop this stuff, as I
was missing a clock for ab8500-usb.

This worked nice for me so, FWIW:

Tested-by: Fabio Baltieri <fabio.baltieri at linaro.org>

Thanks,
Fabio

> 
> Signed-off-by: Ulf Hansson <ulf.hansson at linaro.org>
> ---
>  drivers/clk/ux500/abx500-clk.c |   71 ++++++++++++++++++++++++++++++++++++++--
>  1 file changed, 68 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/clk/ux500/abx500-clk.c b/drivers/clk/ux500/abx500-clk.c
> index 9f7400d..a0fca00 100644
> --- a/drivers/clk/ux500/abx500-clk.c
> +++ b/drivers/clk/ux500/abx500-clk.c
> @@ -12,13 +12,78 @@
>  #include <linux/device.h>
>  #include <linux/platform_device.h>
>  #include <linux/mfd/abx500/ab8500.h>
> -
> -/* TODO: Add clock implementations here */
> -
> +#include <linux/mfd/abx500/ab8500-sysctrl.h>
> +#include <linux/clk.h>
> +#include <linux/clkdev.h>
> +#include <linux/clk-provider.h>
> +#include <linux/mfd/dbx500-prcmu.h>
> +#include "clk.h"
>  
>  /* Clock definitions for ab8500 */
>  static int ab8500_reg_clks(struct device *dev)
>  {
> +	int ret;
> +	struct clk *clk;
> +
> +	const char *intclk_parents[] = {"ab8500_sysclk", "ulpclk"};
> +	u16 intclk_reg_sel[] = {0 , AB8500_SYSULPCLKCTRL1};
> +	u8 intclk_reg_mask[] = {0 , AB8500_SYSULPCLKCTRL1_SYSULPCLKINTSEL_MASK};
> +	u8 intclk_reg_bits[] = {
> +		0 ,
> +		(1 << AB8500_SYSULPCLKCTRL1_SYSULPCLKINTSEL_SHIFT)
> +	};
> +
> +	dev_info(dev, "register clocks for ab850x\n");
> +
> +	/* Enable SWAT */
> +	ret = ab8500_sysctrl_set(AB8500_SWATCTRL, AB8500_SWATCTRL_SWATENABLE);
> +	if (ret)
> +		return ret;
> +
> +	/* ab8500_sysclk */
> +	clk = clk_reg_prcmu_gate("ab8500_sysclk", NULL, PRCMU_SYSCLK,
> +				CLK_IS_ROOT);
> +	clk_register_clkdev(clk, "sysclk", "ab8500-usb.0");
> +	clk_register_clkdev(clk, "sysclk", "ab-iddet.0");
> +	clk_register_clkdev(clk, "sysclk", "ab85xx-codec.0");
> +	clk_register_clkdev(clk, "sysclk", "shrm_bus");
> +
> +	/* ab8500_sysclk2 */
> +	clk = clk_reg_sysctrl_gate(dev , "ab8500_sysclk2", "ab8500_sysclk",
> +		AB8500_SYSULPCLKCTRL1, AB8500_SYSULPCLKCTRL1_SYSCLKBUF2REQ,
> +		AB8500_SYSULPCLKCTRL1_SYSCLKBUF2REQ, 0, 0);
> +	clk_register_clkdev(clk, "sysclk", "0-0070");
> +
> +	/* ab8500_sysclk3 */
> +	clk = clk_reg_sysctrl_gate(dev , "ab8500_sysclk3", "ab8500_sysclk",
> +		AB8500_SYSULPCLKCTRL1, AB8500_SYSULPCLKCTRL1_SYSCLKBUF3REQ,
> +		AB8500_SYSULPCLKCTRL1_SYSCLKBUF3REQ, 0, 0);
> +	clk_register_clkdev(clk, "sysclk", "cg1960_core.0");
> +
> +	/* ab8500_sysclk4 */
> +	clk = clk_reg_sysctrl_gate(dev , "ab8500_sysclk4", "ab8500_sysclk",
> +		AB8500_SYSULPCLKCTRL1, AB8500_SYSULPCLKCTRL1_SYSCLKBUF4REQ,
> +		AB8500_SYSULPCLKCTRL1_SYSCLKBUF4REQ, 0, 0);
> +
> +	/* ab_ulpclk */
> +	clk = clk_reg_sysctrl_gate_fixed_rate(dev, "ulpclk", NULL,
> +		AB8500_SYSULPCLKCTRL1, AB8500_SYSULPCLKCTRL1_ULPCLKREQ,
> +		AB8500_SYSULPCLKCTRL1_ULPCLKREQ,
> +		38400000, 9000, CLK_IS_ROOT);
> +	clk_register_clkdev(clk, "ulpclk", "ab85xx-codec.0");
> +
> +	/* ab8500_intclk */
> +	clk = clk_reg_sysctrl_set_parent(dev , "intclk", intclk_parents, 2,
> +		intclk_reg_sel, intclk_reg_mask, intclk_reg_bits, 0);
> +	clk_register_clkdev(clk, "intclk", "ab85xx-codec.0");
> +	clk_register_clkdev(clk, NULL, "ab8500-pwm.1");
> +
> +	/* ab8500_audioclk */
> +	clk = clk_reg_sysctrl_gate(dev , "audioclk", "intclk",
> +		AB8500_SYSULPCLKCTRL1, AB8500_SYSULPCLKCTRL1_AUDIOCLKENA,
> +		AB8500_SYSULPCLKCTRL1_AUDIOCLKENA, 0, 0);
> +	clk_register_clkdev(clk, "audioclk", "ab85xx-codec.0");
> +
>  	return 0;
>  }

-- 
Fabio Baltieri


From santosh.shilimkar at ti.com  Thu Apr  4 10:16:43 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Thu, 4 Apr 2013 19:46:43 +0530
Subject: [PATCH v2 17/18] ARM: OMAP4+: CPUidle: Add OMAP5 idle driver
 support
In-Reply-To: <87fvz7qpce.fsf@linaro.org>
References: <1364205910-32392-1-git-send-email-santosh.shilimkar@ti.com>
 <1364205910-32392-18-git-send-email-santosh.shilimkar@ti.com>
 <87fvz7qpce.fsf@linaro.org>
Message-ID: <515D8B4B.6000800@ti.com>

On Thursday 04 April 2013 02:55 AM, Kevin Hilman wrote:
> Santosh Shilimkar <santosh.shilimkar at ti.com> writes:
> 
>> The OMAP5 idle driver can re-use OMAP4 CPUidle driver implementation thanks
>> to compatible MPUSS design.
>>
>> Though unlike OMAP4, on OMAP5 devices, MPUSS CSWR (Close Switch
>> Retention) power states can be achieved with respective power states
>> on CPU0 and CPU1 power domain. This mode was broken on OMAP4 devices
>> because of hardware limitation.
> 
> I'm a bit confused by the description here.
> 
> I gather from the code that this means that CPU0 and CPU1 can hit CSWR
> independently, correct?
> 
They can be programmed independently without any ordering(like
CPU0 last etc), but the actual transition to the low power CSWR
happens together. Till that the first CPU hit WFI remains in WFI
state waiting for other CPU to hit WFI and then both transition
together.
Completely managed inside hardware.


>> Also there is no CPU low power entry order requirement like
>> master CPU etc for CSWR C-state, which is icing on the cake. 
> 
> Even on secure devices?
> 
Yes. On secure devices too. Actually since we don't loose context,
secure entry/exit doesn't come into picture.

>> Code makes use of voting scheme for cluster low power state to support
>> MPUSS CSWR C-state.
> 
> The voting scheme and associated locking should be better described
> here, or commented in the code itself.
> 
You are right. It deserves some description.

>> Supported OMAP5 CPUidle C-states:
>>         C1 - CPU0 ON(WFI) + CPU1 ON(WFI) + MPUSS ON
>>         C2 - CPU0 CSWR + CPU1 CSWR + MPUSS CSWR
>>         C3 - CPU0 OFF + CPU1 OFF + MPUSS OSWR
>>
>> Acked-by: Nishanth Menon <nm at ti.com>
>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
> 
> [...]
> 
>> +static int omap_enter_idle_smp(struct cpuidle_device *dev,
>> +			struct cpuidle_driver *drv,
>> +			int index)
>> +{
>> +	struct idle_statedata *cx = state_ptr + index;
>> +	int cpu_id = smp_processor_id();
>> +	unsigned long flag;
>> +
>> +	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &cpu_id);
> 
> I think the CPUidle core handles the broadcast notification now.
> 
Not in mainline yet. And those patches came after my patches and
I don't wanted un-necessary merge dependency, I avoided it. Its trivial
though to drop if from here once the idle next is merged.

>> +	raw_spin_lock_irqsave(&mpu_lock, flag);
>> +	cx->mpu_state_vote++;
> 
> How about using an atomic_t and atomic_inc()/atomic_dec() instead, which
> will avoid the need for a spinlock.
> 
Spin lock is not just for the vote variable. I had atomics opps in first
version I gave it to product team. But they found a race condition in
where MPU power state was getting overwritten by other CPU.

> Even with that, it still seems potentially racy.  Do you need a memory
> barrier here to be sure that any changes from another CPU are visible
> here, and vice versa?
> 
With locks, you don't need barriers since the updated copy is guaranteed.
Can you please elaborate on potential race ? I have given pretty hard
thought and didn't see any race which can be exposed with locks in place.

Regards,
Santosh


From mkl at pengutronix.de  Thu Apr  4 10:25:42 2013
From: mkl at pengutronix.de (Marc Kleine-Budde)
Date: Thu, 04 Apr 2013 16:25:42 +0200
Subject: [PATCH 2/2] mmc: mxs-mmc: add non-removeable property
In-Reply-To: <87r4iqpey3.fsf@octavius.laptop.org>
References: <1364223751-28253-1-git-send-email-mkl@pengutronix.de>
 <1364223751-28253-3-git-send-email-mkl@pengutronix.de>
 <87r4iqpey3.fsf@octavius.laptop.org>
Message-ID: <515D8D66.2040402@pengutronix.de>

On 04/04/2013 04:07 PM, Chris Ball wrote:
> Hi,
> 
> On Mon, Mar 25 2013, Marc Kleine-Budde wrote:
>> +	host->non_removeable = of_property_read_bool(np, "non-removable");
>> +	if (host->non_removeable)
>> +		mmc->caps |= MMC_CAP_NONREMOVABLE;
> 
> The correct spelling is "non_removable", as used in the DT property.
> 
> Thanks,

Will fix.

Marc

-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130404/0d412978/attachment.sig>

From santosh.shilimkar at ti.com  Thu Apr  4 10:34:08 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Thu, 4 Apr 2013 20:04:08 +0530
Subject: [PATCH v2 00/18] ARM: OMAP5: PM: Add MPUSS suspend and CPUidle
 support
In-Reply-To: <87hajnp6ph.fsf@linaro.org>
References: <1364205910-32392-1-git-send-email-santosh.shilimkar@ti.com>
 <87hajnp6ph.fsf@linaro.org>
Message-ID: <515D8F60.1080603@ti.com>

On Thursday 04 April 2013 04:22 AM, Kevin Hilman wrote:
> Hi Santosh,
> 
> Santosh Shilimkar <santosh.shilimkar at ti.com> writes:
> 
>> Here is the refreshed version(v2) of the OMAP5 PM suspport which was posted
>> earlier (March 1st 2013). Patch-set incorporates comments from Nishant
>> Menon (Thanks for review NM) and his acked-by tags. I would like to get this
>> queued for 3.10 merge window if you are ok with the series.
> 
> I did a review of this series with several comments on the individual
> patches.  
> 
Thanks a lot Kevin. I have addressed all the comments and have
updated patches ready.

> I've already queued most of the CPUidle fixes/cleanups in my
> for_3.10/cleanup/cpuidle branch and will get that to Tony soon.  For the
> rest, I suggest probably breaking it up into cleanup/consolidation stuff
> and then OMAP5 support.  The latter will depend on all the OMAP5
> data/headers but the cleanup/consolidation stuff could be merged sooner
> (but probably a bit late for v3.10 now.)
> 
I have already split the patch-set into 'consolidation' and 'OMAP5
support' since it was straight forward. Need to just build the
branches on top of your branches. So waiting for you to update
your 'for_3.10/*' branches.

For the merge, its your call:)
As you said OMAP5 support(couple of patches) has a dependency
on OMAP5 data files. I will at least make the branches ready on
top of yours.

Regards,
Santosh


From Mario.Smarduch at huawei.com  Thu Apr  4 10:48:18 2013
From: Mario.Smarduch at huawei.com (Mario Smarduch)
Date: Thu, 4 Apr 2013 14:48:18 +0000
Subject: Problem building 3.9rc5 - with CONFIG_AUTO_ZRELADDR
In-Reply-To: <2DDB038789B01B4B80B0D3F1FF7CBDC2064D2F5F@lhreml509-mbb.china.huawei.com>
References: <2DDB038789B01B4B80B0D3F1FF7CBDC2064D2F42@lhreml509-mbb.china.huawei.com>
 <2DDB038789B01B4B80B0D3F1FF7CBDC2064D2F5F@lhreml509-mbb.china.huawei.com>
Message-ID: <2DDB038789B01B4B80B0D3F1FF7CBDC2064D2F80@lhreml509-mbb.china.huawei.com>

Hello,

I'm building 3.9rc5 Host the build fails in arch/arm/boot/Makefile.
check_for_multiple_loadaddr (issued from uImage:) checks if $(UIMAGE_LOADADDR) -ne 1.
With CONFIG_AUTO_ZRELADDR set kernel decompressed load address is determine dynamically.
The build doesn't seem to take that into consideration it expects ZRELADDR set.
3.8rc4 had 'if $(UIMAGE_LOADADDR) -gt 1', what I would expect.

Does someone know what's hidden behind this subtle change? Before looking for workarounds.

- Mario


From dedekind1 at gmail.com  Thu Apr  4 11:23:37 2013
From: dedekind1 at gmail.com (Artem Bityutskiy)
Date: Thu, 04 Apr 2013 18:23:37 +0300
Subject: [PATCH 1/4] mtd: merge mtdchar module with mtdcore
In-Reply-To: <20130317215805.3246b0b5.shmulik.ladkani@gmail.com>
References: <1363260463-10609-1-git-send-email-dedekind1@gmail.com>
 <20130317215805.3246b0b5.shmulik.ladkani@gmail.com>
Message-ID: <1365089017.626.14.camel@sauron.fi.intel.com>

On Sun, 2013-03-17 at 21:58 +0200, Shmulik Ladkani wrote:
> On Thu, 14 Mar 2013 13:27:40 +0200 Artem Bityutskiy <dedekind1 at gmail.com> wrote:
> > Indeed, mtdchar is a module that allows user-space making use of MTD devices
> > via /dev/mtd* character devices. If users do not enable it, they simply cannot
> > use MTD devices at all. The cannot read or write the flash contents. Is it a
> 
> s/ The cannot/ They cannot/

Fixed.

> What about the defconfig files?

There are too many of them. I do not want to update them because it is
not necessary and the non-existing symbol will just be ignored by
Kbuild. People who support their defconfigs will eventually update them
eventually.

-- 
Best Regards,
Artem Bityutskiy



From cdall at cs.columbia.edu  Thu Apr  4 11:27:50 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Thu, 4 Apr 2013 08:27:50 -0700
Subject: [PATCH 2/5] ARM: KVM: arch_timers: zero CNTVOFF upon return to
 host
In-Reply-To: <20130404092939.GB3341@e106331-lin.cambridge.arm.com>
References: <1364404312-4427-1-git-send-email-mark.rutland@arm.com>
 <1364404312-4427-3-git-send-email-mark.rutland@arm.com>
 <CAEDV+gKmi16juPvQUO46eMVwtNMR+q4ce8ND_yVM4_O8iOYUXw@mail.gmail.com>
 <20130404092939.GB3341@e106331-lin.cambridge.arm.com>
Message-ID: <CAEDV+gJVq9N-ASm=m58q6umRhLo2aNn6iQNbecTXG9zejWiZCg@mail.gmail.com>

On Thu, Apr 4, 2013 at 2:29 AM, Mark Rutland <mark.rutland at arm.com> wrote:
> Hi Christoffer,
>
> On Thu, Apr 04, 2013 at 12:39:27AM +0100, Christoffer Dall wrote:
>> On Wed, Mar 27, 2013 at 10:11 AM, Mark Rutland <mark.rutland at arm.com> wrote:
>> > To use the virtual counters from the host, we need to ensure that
>> > CNTVOFF doesn't change unexpectedly. When we change to a guest, we
>> > replace the host's CNTVOFF, but we don't restore it when returning to
>> > the host.
>> >
>> > As the host sets CNTVOFF to zero, and never changes it, we can simply
>> > zero CNTVOFF when returning to the host. This patch adds said zeroing to
>> > the return to host path.
>> >
>> > Signed-off-by: Mark Rutland <mark.rutland at arm.com>
>> > Acked-by: Marc Zyngier <marc.zyngier at arm.com>
>> > Cc: Christoffer Dall <cdall at cs.columbia.edu>
>> > ---
>> >  arch/arm/kvm/interrupts_head.S | 4 ++++
>> >  1 file changed, 4 insertions(+)
>> >
>> > diff --git a/arch/arm/kvm/interrupts_head.S b/arch/arm/kvm/interrupts_head.S
>> > index 3c8f2f0..d43cfb5 100644
>> > --- a/arch/arm/kvm/interrupts_head.S
>> > +++ b/arch/arm/kvm/interrupts_head.S
>> > @@ -497,6 +497,10 @@ vcpu       .req    r0              @ vcpu pointer always in r0
>> >         add     r5, vcpu, r4
>> >         strd    r2, r3, [r5]
>> >
>> > +       @ Ensure host CNTVCT == CNTPCT
>> > +       mov     r2, #0
>> > +       mcrr    p15, 4, r2, r2, c14     @ CNTVOFF
>> > +
>> >  1:
>> >  #endif
>> >         @ Allow physical timer/counter access for the host
>> > --
>> > 1.8.1.1
>> >
>> >
>>
>> looks good to me.
>>
>> Merged into kvm-arm-fixes.
>
> As this patch depends on the previous patch (which sets CNTVOFF to 0 in the hyp
> stub), and the rest of the patches depend on both this patch and the previous
> for correct operation, the series really needs to be taken together.
>

I don't see why this patch depends on the prior patches, I see it the
other way around.

> Would you be able to give your ack instead?

But sure, I definitely ack the patch.

>
> This patch is only required because the later patches in this series need it to
> allow the host to use virtual counters, nothing else requires the host's
> CNTVOFF to be 0 at the moment as both physical counters and timers are used by
> the host.
>
I understand, it doesn't hurt either though.

-Christoffer


From arnd at arndb.de  Thu Apr  4 11:27:52 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 4 Apr 2013 15:27:52 +0000
Subject: [PATCH 11/11] RFC: ARM: get PCI device IRQs from device tree
In-Reply-To: <1365087696-9548-12-git-send-email-linus.walleij@linaro.org>
References: <1365087696-9548-1-git-send-email-linus.walleij@linaro.org>
 <1365087696-9548-11-git-send-email-linus.walleij@linaro.org>
 <1365087696-9548-12-git-send-email-linus.walleij@linaro.org>
Message-ID: <201304041527.52400.arnd@arndb.de>

On Thursday 04 April 2013, Linus Walleij wrote:
> This adds the interrupt-map property to the PCIv3 DTS file
> and makes the bridge obtain mappings from the device tree.
> 
> Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
> ---
> This currently bugs out - when trying to get the IRQs for
> devices of_irq_map_pci() reads the IRQ pin from the PCI config
> space successfully, then comes to trying to look up the parent
> PCI device by checking pdev->bus->self, which is NULL, then
> tries to treat it as a bridge doing pci_bus_to_OF_node(pdev->bus)
> which also results in NULL and it bails out.
> 
> No clue why this is so - some problem with the parent of this
> bus not being a PCI device in itself? Help.

All the PowerPC implementations I remember had the PCI bus
as a device under the root node. It's very possible that it's
just a bug in of_irq_map_pci().

	Arnd


From arnd at arndb.de  Thu Apr  4 11:29:00 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 4 Apr 2013 15:29:00 +0000
Subject: [PATCH 00/11] ARM: integrator PCI DT adaption
In-Reply-To: <1365087696-9548-1-git-send-email-linus.walleij@linaro.org>
References: <1365087696-9548-1-git-send-email-linus.walleij@linaro.org>
Message-ID: <201304041529.00900.arnd@arndb.de>

On Thursday 04 April 2013, Linus Walleij wrote:
> This patch series converts the Integrator/AP v3 PCI adapter
> to use device tree, up until the point where I try to set
> up the IRQ map and fail. Help on how to get the last patch
> working is appreciated.
> 
> This series is dependent on the first three patches for OF
> recently submitted by Thomas Petazzoni, I will not be able
> to submit them until that stuff is merged somewhere (like
> ARM SoC).

Looks very nice!

Acked-by: Arnd Bergmann <arnd at arndb.de>

including the last [RFC] patch, which also looks right to me,
even though you tell me it doesn't work ;-)


From nicolas.ferre at atmel.com  Thu Apr  4 11:29:56 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Thu, 4 Apr 2013 17:29:56 +0200
Subject: [PATCH v2] ARM: at91: add Acme Systems Aria G25 board
In-Reply-To: <515C7E94.6030702@interlog.com>
References: <1364201369-12047-1-git-send-email-nicolas.ferre@atmel.com>
 <1364297952-32473-1-git-send-email-nicolas.ferre@atmel.com>
 <CAOesGMj+etPUMWffx2CiDtbWbB9A5_6QPbkTsmbEqCiBnkhm3A@mail.gmail.com>
 <515C7E94.6030702@interlog.com>
Message-ID: <515D9C74.5050207@atmel.com>

On 04/03/2013 09:10 PM, Douglas Gilbert :
> On 13-04-02 02:48 PM, Olof Johansson wrote:
>> Hi,
>>
>> I just saw this since it came in through a pull request
>>
>> On Tue, Mar 26, 2013 at 4:39 AM, Nicolas Ferre
>> <nicolas.ferre at atmel.com> wrote:
>>> From: Douglas Gilbert <dgilbert at interlog.com>
>>>
>>> Signed-off-by: Douglas Gilbert <dgilbert at interlog.com>
>>> Signed-off-by: Nicolas Ferre <nicolas.ferre at atmel.com>
>>> ---
>>>   arch/arm/boot/dts/ariag25.dts | 175
>>> ++++++++++++++++++++++++++++++++++++++++++
>>>   1 file changed, 175 insertions(+)
>>>   create mode 100644 arch/arm/boot/dts/ariag25.dts
>>>
>>> diff --git a/arch/arm/boot/dts/ariag25.dts
>>> b/arch/arm/boot/dts/ariag25.dts
>>> new file mode 100644
>>> index 0000000..b43266f
>>> --- /dev/null
>>> +++ b/arch/arm/boot/dts/ariag25.dts
>>
>> Please prefix the boards with the platform. Most other SoCs already do
>> this, and I see now that some at91 boards haven't been prefixed in the
>> past, but it's a good idea to not add more of them.
>>
>> So, at91-ariag25.dts is a good name in this case.
> 
> That is fine with me. I have changed my working DT
> config file to at91-ariag25.dts and will push that
> out to Robert Nelson soon.
> 
> Also I'm working on a DT version of an existing Acme
> product called the FoxG20 which is based on the
> AT91SAM9G20 SoC. It already has non-DT support inside
> the mainline kernel. I am using at91-foxg20.dts for
> its DT config file.

Yep! Works for me.

Bye,
-- 
Nicolas Ferre


From cdall at cs.columbia.edu  Thu Apr  4 11:32:41 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Thu, 4 Apr 2013 08:32:41 -0700
Subject: [PATCH 4/7] ARM: KVM: enforce page alignment for identity mapped
 code
In-Reply-To: <515D5A44.9030909@arm.com>
References: <1364909115-3810-1-git-send-email-marc.zyngier@arm.com>
 <1364909115-3810-5-git-send-email-marc.zyngier@arm.com>
 <20130403095024.GC11040@mudshark.cambridge.arm.com>
 <515BFDC7.9020401@arm.com> <20130403231504.GD29227@gmail.com>
 <515D5A44.9030909@arm.com>
Message-ID: <CAEDV+gLG8zEzu2eUa5Kk18wQ6k3g=mMpWBdYKhyFk29ReLv6fA@mail.gmail.com>

On Thu, Apr 4, 2013 at 3:47 AM, Marc Zyngier <marc.zyngier at arm.com> wrote:
> On 04/04/13 00:15, Christoffer Dall wrote:
>> On Wed, Apr 03, 2013 at 11:00:39AM +0100, Marc Zyngier wrote:
>>> On 03/04/13 10:50, Will Deacon wrote:
>>>> On Tue, Apr 02, 2013 at 02:25:12PM +0100, Marc Zyngier wrote:
>>>>> We're about to move to a init procedure where we rely on the
>>>>> fact that the init code fits in a single page. Make sure we
>>>>> align the idmap text on a page boundary, and that the code is
>>>>> not bigger than a single page.
>>>>>
>>>>> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
>>>>> ---
>>>>>  arch/arm/kernel/vmlinux.lds.S | 2 +-
>>>>>  arch/arm/kvm/init.S           | 7 +++++++
>>>>>  2 files changed, 8 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
>>>>> index b571484..d9dd265 100644
>>>>> --- a/arch/arm/kernel/vmlinux.lds.S
>>>>> +++ b/arch/arm/kernel/vmlinux.lds.S
>>>>> @@ -20,7 +20,7 @@
>>>>>    VMLINUX_SYMBOL(__idmap_text_start) = .;                         \
>>>>>    *(.idmap.text)                                                  \
>>>>>    VMLINUX_SYMBOL(__idmap_text_end) = .;                           \
>>>>> -  ALIGN_FUNCTION();                                               \
>>>>> +  . = ALIGN(PAGE_SIZE);                                           \
>>>>>    VMLINUX_SYMBOL(__hyp_idmap_text_start) = .;                     \
>>>>>    *(.hyp.idmap.text)                                              \
>>>>>    VMLINUX_SYMBOL(__hyp_idmap_text_end) = .;
>>>>> diff --git a/arch/arm/kvm/init.S b/arch/arm/kvm/init.S
>>>>> index 9f37a79..35a463f 100644
>>>>> --- a/arch/arm/kvm/init.S
>>>>> +++ b/arch/arm/kvm/init.S
>>>>> @@ -111,4 +111,11 @@ __do_hyp_init:
>>>>>    .globl __kvm_hyp_init_end
>>>>>  __kvm_hyp_init_end:
>>>>>
>>>>> +  /*
>>>>> +   * The above code *must* fit in a single page for the trampoline
>>>>> +   * madness to work. Whoever decides to change it must make sure
>>>>> +   * we map the right amount of memory for the trampoline to work.
>>>>> +   * The line below ensures any breakage will get noticed.
>>
>> This comment is a little funny. What's this about changing it? And why
>> madness? OK, it's a little mad.
>>
>> I think the nice thing to explain here is why .org would complain - I
>> had to look in the AS reference to figure out that it will complain if
>> the location pointer is forwarded outside the section - if that is the
>> right reason?
>>
>>>>> +   */
>>>>> +  .org    __kvm_hyp_init + PAGE_SIZE
>>>>>    .popsection
>>>>
>>>> What effect does this have on the size of the kernel image? I'd expect the
>>>> idmap code to be pretty small, so aligning to a page might be overkill a lot
>>>> of the time.
>>>
>>> So we're indeed wasting memory between the kernel and the HYP idmaps.
>>> The reason for this is to ensure that the init code is not spread across
>>> two pages, which would make the trampoline harder to allocate.
>>>
>>> If there's a way to ensure that the init.S code will fit a single page,
>>> then we can remove this ALIGN(PAGE_SIZE).
>>
>> Just allocate a temporary page and copy the bit of code into there?  It
>> should be easy enough to make sure it's location independent.  We can
>> even give that page back later if we want and re-do the trick when a CPU
>> gets hot-plugged if we want. No?
>
> I'd really like to avoid freeing stuff, because it gives us even more
> chances to screw our TLBs (we'd have to invalidate on unmap, and deal
> with potential races between CPUs coming up).
>
> We could allocate this page *if* the HYP init code happens to cross a
> page boundary, and only then. I'll have a look at implementing this as
> it should solve Will's issue (which is even worse on arm64 with 64k pages).
>
The freeing stuff was a minor point, that I don't care much about, but
reducing the kernel size is a valid concern I guess.

-Christoffer


From cdall at cs.columbia.edu  Thu Apr  4 11:36:04 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Thu, 4 Apr 2013 08:36:04 -0700
Subject: Problem building 3.9rc5 - with CONFIG_AUTO_ZRELADDR
In-Reply-To: <2DDB038789B01B4B80B0D3F1FF7CBDC2064D2F80@lhreml509-mbb.china.huawei.com>
References: <2DDB038789B01B4B80B0D3F1FF7CBDC2064D2F42@lhreml509-mbb.china.huawei.com>
 <2DDB038789B01B4B80B0D3F1FF7CBDC2064D2F5F@lhreml509-mbb.china.huawei.com>
 <2DDB038789B01B4B80B0D3F1FF7CBDC2064D2F80@lhreml509-mbb.china.huawei.com>
Message-ID: <CAEDV+g+Amoc33GkvXS+e0+g7TEYtDN9RyTz8uOo4kk7Qr+iM8A@mail.gmail.com>

On Thu, Apr 4, 2013 at 7:48 AM, Mario Smarduch
<Mario.Smarduch at huawei.com> wrote:
> Hello,
>
> I'm building 3.9rc5 Host the build fails in arch/arm/boot/Makefile.
> check_for_multiple_loadaddr (issued from uImage:) checks if $(UIMAGE_LOADADDR) -ne 1.
> With CONFIG_AUTO_ZRELADDR set kernel decompressed load address is determine dynamically.
> The build doesn't seem to take that into consideration it expects ZRELADDR set.
> 3.8rc4 had 'if $(UIMAGE_LOADADDR) -gt 1', what I would expect.
>
> Does someone know what's hidden behind this subtle change? Before looking for workarounds.
>
Eh, this is a little hard to guess at. Can you send your kernel config?

-Christoffer


From sr at denx.de  Thu Apr  4 11:37:48 2013
From: sr at denx.de (Stefan Roese)
Date: Thu, 04 Apr 2013 17:37:48 +0200
Subject: [PATCH 1/5] net: Add EMAC ethernet driver found on Allwinner
 A10 SoC's
In-Reply-To: <201303242003.52827.florian@openwrt.org>
References: <1364077814-2233-1-git-send-email-maxime.ripard@free-electrons.com>
 <1364077814-2233-2-git-send-email-maxime.ripard@free-electrons.com>
 <201303242003.52827.florian@openwrt.org>
Message-ID: <515D9E4C.6000409@denx.de>

Hi Florian,

On 24.03.2013 20:03, Florian Fainelli wrote:
> Your phylib implementation looks good now, just some minor comments below:

Thanks for the review. I'll try to address your new comments in a few
days (currently swamped).

Thanks,
Stefan



From mark.rutland at arm.com  Thu Apr  4 11:38:18 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Thu, 4 Apr 2013 16:38:18 +0100
Subject: [PATCH 2/5] ARM: KVM: arch_timers: zero CNTVOFF upon return to
 host
In-Reply-To: <CAEDV+gJVq9N-ASm=m58q6umRhLo2aNn6iQNbecTXG9zejWiZCg@mail.gmail.com>
References: <1364404312-4427-1-git-send-email-mark.rutland@arm.com>
 <1364404312-4427-3-git-send-email-mark.rutland@arm.com>
 <CAEDV+gKmi16juPvQUO46eMVwtNMR+q4ce8ND_yVM4_O8iOYUXw@mail.gmail.com>
 <20130404092939.GB3341@e106331-lin.cambridge.arm.com>
 <CAEDV+gJVq9N-ASm=m58q6umRhLo2aNn6iQNbecTXG9zejWiZCg@mail.gmail.com>
Message-ID: <20130404153818.GA23725@e106331-lin.cambridge.arm.com>

On Thu, Apr 04, 2013 at 04:27:50PM +0100, Christoffer Dall wrote:
> On Thu, Apr 4, 2013 at 2:29 AM, Mark Rutland <mark.rutland at arm.com> wrote:
> > Hi Christoffer,
> >
> > On Thu, Apr 04, 2013 at 12:39:27AM +0100, Christoffer Dall wrote:
> >> On Wed, Mar 27, 2013 at 10:11 AM, Mark Rutland <mark.rutland at arm.com> wrote:
> >> > To use the virtual counters from the host, we need to ensure that
> >> > CNTVOFF doesn't change unexpectedly. When we change to a guest, we
> >> > replace the host's CNTVOFF, but we don't restore it when returning to
> >> > the host.
> >> >
> >> > As the host sets CNTVOFF to zero, and never changes it, we can simply
> >> > zero CNTVOFF when returning to the host. This patch adds said zeroing to
> >> > the return to host path.
> >> >
> >> > Signed-off-by: Mark Rutland <mark.rutland at arm.com>
> >> > Acked-by: Marc Zyngier <marc.zyngier at arm.com>
> >> > Cc: Christoffer Dall <cdall at cs.columbia.edu>
> >> > ---
> >> >  arch/arm/kvm/interrupts_head.S | 4 ++++
> >> >  1 file changed, 4 insertions(+)
> >> >
> >> > diff --git a/arch/arm/kvm/interrupts_head.S b/arch/arm/kvm/interrupts_head.S
> >> > index 3c8f2f0..d43cfb5 100644
> >> > --- a/arch/arm/kvm/interrupts_head.S
> >> > +++ b/arch/arm/kvm/interrupts_head.S
> >> > @@ -497,6 +497,10 @@ vcpu       .req    r0              @ vcpu pointer always in r0
> >> >         add     r5, vcpu, r4
> >> >         strd    r2, r3, [r5]
> >> >
> >> > +       @ Ensure host CNTVCT == CNTPCT
> >> > +       mov     r2, #0
> >> > +       mcrr    p15, 4, r2, r2, c14     @ CNTVOFF
> >> > +
> >> >  1:
> >> >  #endif
> >> >         @ Allow physical timer/counter access for the host
> >> > --
> >> > 1.8.1.1
> >> >
> >> >
> >>
> >> looks good to me.
> >>
> >> Merged into kvm-arm-fixes.
> >
> > As this patch depends on the previous patch (which sets CNTVOFF to 0 in the hyp
> > stub), and the rest of the patches depend on both this patch and the previous
> > for correct operation, the series really needs to be taken together.
> >
> 
> I don't see why this patch depends on the prior patches, I see it the
> other way around.

The patch itself doesn't stricly depend on the others, but the description
does: "As the host sets CNTVOFF to zero" - this is only true once the previous
patch has been applied. As the later patches have a dependence on this patch, I
don't think it makes sense for it to go in on its own -- if anything it makes
it more difficult to apply the rest of the series as it now has a dependence on
or conflict with kvm-arm-fixes.

> 
> > Would you be able to give your ack instead?
> 
> But sure, I definitely ack the patch.

Cheers.

Mark.


From nicolas.ferre at atmel.com  Thu Apr  4 11:42:33 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Thu, 4 Apr 2013 17:42:33 +0200
Subject: [PATCH v3] ARM: at91: add Acme Systems Aria G25 board
In-Reply-To: <20130402184947.GA8015@quad.lixom.net>
References: <20130402184947.GA8015@quad.lixom.net>
Message-ID: <1365090153-1807-1-git-send-email-nicolas.ferre@atmel.com>

From: Douglas Gilbert <dgilbert at interlog.com>

Signed-off-by: Douglas Gilbert <dgilbert at interlog.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre at atmel.com>
---
Hi all,

Here is the third revision of this patch. I plan to include it in a
pull-request real-soon-now!

v3: - move to "at91-" prefix for .dts[i] files
    - remove the rtc activation code because of the ongoing discussions
      about this IP and its DT binding.

 arch/arm/boot/dts/Makefile         |   1 +
 arch/arm/boot/dts/at91-ariag25.dts | 171 +++++++++++++++++++++++++++++++++++++
 2 files changed, 172 insertions(+)
 create mode 100644 arch/arm/boot/dts/at91-ariag25.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 4c7f8a8..b07f162 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -27,6 +27,7 @@ dtb-$(CONFIG_ARCH_AT91) += pm9g45.dtb
 # sam9n12
 dtb-$(CONFIG_ARCH_AT91) += at91sam9n12ek.dtb
 # sam9x5
+dtb-$(CONFIG_ARCH_AT91) += at91-ariag25.dtb
 dtb-$(CONFIG_ARCH_AT91) += at91sam9g15ek.dtb
 dtb-$(CONFIG_ARCH_AT91) += at91sam9g25ek.dtb
 dtb-$(CONFIG_ARCH_AT91) += at91sam9g35ek.dtb
diff --git a/arch/arm/boot/dts/at91-ariag25.dts b/arch/arm/boot/dts/at91-ariag25.dts
new file mode 100644
index 0000000..c7aebba
--- /dev/null
+++ b/arch/arm/boot/dts/at91-ariag25.dts
@@ -0,0 +1,171 @@
+/*
+ * at91-ariag25.dts - Device Tree file for Acme Systems Aria G25 (AT91SAM9G25 based)
+ *
+ * Copyright (C) 2013 Douglas Gilbert <dgilbert at interlog.com>,
+ *                    Robert Nelson <robertcnelson at gmail.com>
+ *
+ * Licensed under GPLv2 or later.
+ */
+/dts-v1/;
+/include/ "at91sam9g25.dtsi"
+
+/ {
+	model = "Acme Systems Aria G25";
+	compatible = "acme,ariag25", "atmel,at91sam9x5ek",
+		     "atmel,at91sam9x5", "atmel,at91sam9";
+
+	aliases {
+		serial0 = &dbgu;
+		serial1 = &usart0;
+		serial2 = &usart1;
+		serial3 = &usart2;
+		serial4 = &usart3;
+		serial5 = &uart0;
+	};
+
+	chosen {
+		bootargs = "console=ttyS0,115200 root=/dev/mmcblk0p2 rw rootwait";
+	};
+
+	memory {
+		/* 128 MB, change this for 256 MB revision */
+		reg = <0x20000000 0x8000000>;
+	};
+
+	clocks {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges;
+
+		main_clock: clock at 0 {
+			compatible = "atmel,osc", "fixed-clock";
+			clock-frequency = <12000000>;
+		};
+	};
+
+	ahb {
+		apb {
+			mmc0: mmc at f0008000 {
+				/* N.B. Aria has no SD card detect (CD), assumed present */
+
+				pinctrl-0 = <
+					&pinctrl_mmc0_slot0_clk_cmd_dat0
+					&pinctrl_mmc0_slot0_dat1_3>;
+				status = "okay";
+				slot at 0 {
+					reg = <0>;
+					bus-width = <4>;
+				};
+			};
+
+			i2c0: i2c at f8010000 {
+				status = "okay";
+			};
+
+			i2c1: i2c at f8014000 {
+				status = "okay";
+			};
+
+			/* TWD2+TCLK2 hidden behind ethernet, so no i2c2 */
+
+			usart0: serial at f801c000 {
+				pinctrl-0 = <&pinctrl_usart0
+					     &pinctrl_usart0_rts
+					     &pinctrl_usart0_cts>;
+				status = "okay";
+			};
+
+			usart1: serial at f8020000 {
+				pinctrl-0 = <&pinctrl_usart1
+					     /* &pinctrl_usart1_rts */
+					     /* &pinctrl_usart1_cts */
+					    >;
+				status = "okay";
+			};
+
+			usart2: serial at f8024000 {
+				/* cannot activate RTS2+CTS2, clash with
+				 * ethernet on PB0 and PB1 */
+				pinctrl-0 = <&pinctrl_usart2>;
+				status = "okay";
+			};
+
+			usart3: serial at f8028000 {
+				compatible = "atmel,at91sam9260-usart";
+				reg = <0xf8028000 0x200>;
+				interrupts = <8 4 5>;
+				pinctrl-names = "default";
+				pinctrl-0 = <&pinctrl_usart3
+					     /* &pinctrl_usart3_rts */
+					     /* &pinctrl_usart3_cts */
+					    >;
+				status = "okay";
+			};
+
+			macb0: ethernet at f802c000 {
+				phy-mode = "rmii";
+				/*
+				 * following can be overwritten by bootloader:
+				 * for example u-boot 'ftd set' command
+				 */
+				local-mac-address = [00 00 00 00 00 00];
+				status = "okay";
+			};
+
+			uart0: serial at f8040000 {
+				compatible = "atmel,at91sam9260-usart";
+				reg = <0xf8040000 0x200>;
+				interrupts = <15 4 5>;
+				pinctrl-names = "default";
+				pinctrl-0 = <&pinctrl_uart0>;
+				status = "okay";
+			};
+
+			adc0: adc at f804c000 {
+				status = "okay";
+				atmel,adc-channels-used = <0xf>;
+				atmel,adc-num-channels = <4>;
+			};
+
+			dbgu: serial at fffff200 {
+				status = "okay";
+			};
+
+			pinctrl at fffff400 {
+				w1_0 {
+					pinctrl_w1_0: w1_0-0 {
+						atmel,pins = <0 21 0x0 0x1>; /* PA21 PIO, pull-up */
+					};
+				};
+			};
+		};
+
+		usb0: ohci at 00600000 {
+			status = "okay";
+			num-ports = <3>;
+		};
+
+		usb1: ehci at 00700000 {
+			status = "okay";
+		};
+	};
+
+	leds {
+		compatible = "gpio-leds";
+
+		/* little green LED in middle of Aria G25 module */
+		aria_led {
+			label = "aria_led";
+			gpios = <&pioB 8 0>; /* PB8 */
+			linux,default-trigger = "heartbeat";
+		};
+
+	};
+
+	onewire at 0 {
+		compatible = "w1-gpio";
+		gpios = <&pioA 21 1>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_w1_0>;
+	};
+};
-- 
1.8.0



From arnd at arndb.de  Thu Apr  4 11:47:52 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 4 Apr 2013 15:47:52 +0000
Subject: [PATCH v2,
 part1 03/29] mm/ARM: use common help functions to free reserved pages
In-Reply-To: <1362896833-21104-4-git-send-email-jiang.liu@huawei.com>
References: <1362896833-21104-1-git-send-email-jiang.liu@huawei.com>
 <1362896833-21104-4-git-send-email-jiang.liu@huawei.com>
Message-ID: <201304041547.52539.arnd@arndb.de>

On Sunday 10 March 2013, Jiang Liu wrote:
> Use common help functions to free reserved pages.
> 
> Signed-off-by: Jiang Liu <jiang.liu at huawei.com>
> Cc: Russell King <linux at arm.linux.org.uk>
> Cc: Catalin Marinas <catalin.marinas at arm.com>
> Cc: Will Deacon <will.deacon at arm.com>
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-kernel at vger.kernel.org

Hello Jiang Liu,

I'm getting a few new build warnings from this patch in linux-next, can you please
have a look what's going on here? 

> @@ -609,8 +600,7 @@ void __init mem_init(void)
>  
>  #ifdef CONFIG_SA1111
>  	/* now that our DMA memory is actually so designated, we can free it */
> -	totalram_pages += free_area(PHYS_PFN_OFFSET,
> -				    __phys_to_pfn(__pa(swapper_pg_dir)), NULL);
> +	free_reserved_area(__va(PHYS_PFN_OFFSET), swapper_pg_dir, 0, NULL);
>  #endif

Using neponset_defconfig:

arch/arm/mm/init.c: In function 'mem_init':
arch/arm/mm/init.c:603:2: warning: passing argument 1 of 'free_reserved_area' makes integer from pointer without a cast [enabled by default]
  free_reserved_area(__va(PHYS_PFN_OFFSET), swapper_pg_dir, 0, NULL);
  ^
In file included from include/linux/mman.h:4:0,
                 from arch/arm/mm/init.c:15:
include/linux/mm.h:1301:22: note: expected 'long unsigned int' but argument is of type 'void *'
 extern unsigned long free_reserved_area(unsigned long start, unsigned long end,
                      ^

> @@ -738,16 +728,12 @@ void free_initmem(void)
>  	extern char __tcm_start, __tcm_end;
>  
>  	poison_init_mem(&__tcm_start, &__tcm_end - &__tcm_start);
> -	totalram_pages += free_area(__phys_to_pfn(__pa(&__tcm_start)),
> -				    __phys_to_pfn(__pa(&__tcm_end)),
> -				    "TCM link");
> +	free_reserved_area(&__tcm_start, &__tcm_end, 0, "TCM link");
>  #endif

Using one of {realview,s3c6400,u300}_defconfig:

/git/arm-soc/arch/arm/mm/init.c: In function 'free_initmem':
/git/arm-soc/arch/arm/mm/init.c:731:2: warning: passing argument 1 of 'free_reserved_area' makes integer from pointer without a cast [enabled by default]
  free_reserved_area(&__tcm_start, &__tcm_end, 0, "TCM link");
  ^
In file included from /git/arm-soc/include/linux/mman.h:4:0,
                 from /git/arm-soc/arch/arm/mm/init.c:15:
/git/arm-soc/include/linux/mm.h:1301:22: note: expected 'long unsigned int' but argument is of type 'char *'
 extern unsigned long free_reserved_area(unsigned long start, unsigned long end,
                      ^

	Arnd


From nicolas.ferre at atmel.com  Thu Apr  4 12:04:37 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Thu, 4 Apr 2013 18:04:37 +0200
Subject: [PATCH] at91sam9260.dtsi: fix u(s)art pinctrl encoding
In-Reply-To: <515D7A4F.90707@interlog.com>
References: <515D7A4F.90707@interlog.com>
Message-ID: <515DA495.8030205@atmel.com>

On 04/04/2013 03:04 PM, Douglas Gilbert :

> A pattern is emerging with sloppy at91 dts(i) files
> with pinctrls: the comments are correct and the
> corresponding encoding is wrong. The other example that
> I fixed was at91sam9x5.dtsi . Makes you wonder how many
> people are using this DT stuff in anger ...
> 
> This problem was found with AT91SAM9G20 SoCs (Acme's FoxG20).
> The attached is against lk 3.9.0-rc5 .


>  
>  					pinctrl_usart3_rts: usart3_rts-0 {
>  						atmel,pins =
> -							<3 8 0x2 0x0>;	/* PB8 periph B */
> +							<1 8 0x2 0x0>;	/* PB8 periph B */

Here both the comment and the encoding were wrong:
it is PC8 periph B ==> <2 8 0x2  0x0>

>  					};
>  
>  					pinctrl_usart3_cts: usart3_cts-0 {
>  						atmel,pins =
> -							<3 10 0x2 0x0>;	/* PB10 periph B */
> +							<1 10 0x2 0x0>;	/* PB10 periph B */

Same here:
it is PC10 periph B ==> <2 10 0x2  0x0>

>  					};
>  				};

I correct this in your patch and submit it right now.

Thanks, best regards,
-- 
Nicolas Ferre


From dinguyen at altera.com  Thu Apr  4 12:08:42 2013
From: dinguyen at altera.com (Dinh Nguyen)
Date: Thu, 4 Apr 2013 11:08:42 -0500
Subject: [PATCHv2 1/2] ARM: socfpga: Enable soft reset
In-Reply-To: <CAOesGMitpM=6w_81YYO9eYbCCS0oyfihT-6ZYcaeD9TQywChvw@mail.gmail.com>
References: <1363707936-17769-1-git-send-email-dinguyen@altera.com>
 <20130320152915.GA32083@amd.pavel.ucw.cz>
 <20130403185232.GA11360@quad.lixom.net>
 <20130403203234.GA7643@amd.pavel.ucw.cz>
 <CAOesGMitpM=6w_81YYO9eYbCCS0oyfihT-6ZYcaeD9TQywChvw@mail.gmail.com>
Message-ID: <1365091722.28577.17.camel@linux-builds1>

Hi Pavel,

On Wed, 2013-04-03 at 14:12 -0700, Olof Johansson wrote:
> On Wed, Apr 3, 2013 at 1:32 PM, Pavel Machek <pavel at denx.de> wrote:
> > Hi!
> >
> >> > +struct socfpga_rstmgr_hw {
> >> > +   u32 unk;
> >> > +   u32 ctrl;               /* 0x04 */
> >> > +   u32 unk2, unk3;
> >> > +/* MPU Module Reset Register */
> >> > +#define RSTMGR_MPUMODRST_CPU0      0x1     /* CPU0 Reset */
> >> > +#define RSTMGR_MPUMODRST_CPU1      0x2     /* CPU1 Reset */
> >> > +#define RSTMGR_MPUMODRST_WDS       0x4     /* Watchdog Reset */
> >> > +#define RSTMGR_MPUMODRST_SCUPER    0x8     /* SCU and periphs reset */
> >> > +#define RSTMGR_MPUMODRST_L2        0x10    /* L2 Cache reset */
> >> > +   u32 mpumodrst;          /* 0x10 */
> >> > +   u32 modperrst;          /* 0x14 */
> >> > +   u32 unk5;
> >> > +   u32 bgrmodrst;          /* 0x1c */
> >> > +};
> >>
> >> As Russell already replied, struct used to represent register layout is
> >> normally frowned upon in drivers.
> >
> > Well... as Russell also said, this is arch-specific code, so it is
> > actually ok.
> 
> Which is why I said "normally frowned upon" instead of "always frowned upon".
> 
> >> If you want to tighten up the code in this case, make a local helper
> >> function that just takes the register offset instead, i.e.:
> >>
> >> > -   temp = __raw_readl(rst_manager_base_addr + SOCFPGA_RSTMGR_CTRL);
> >> > +   temp = readl(&rst_manager_base_addr->ctrl);
> >>
> >>       temp = rst_readl(SOCFPGA_RSTMGR_CTRL);
> >>
> >> (and then have rst_readl/rst_writel do the math based on base
> >> address).
> >
> > That does not prevent mistake such as
> > rst_readl(SOCFPGA_SYSMGR_CTRL)... and with number of different
> > subsystems on socfpga (each with separate base address), I fear that
> > might be an issue.
> >
> > Unfortunately, C does not check type of enums, so they can't be used
> > to solve that.
> 
> That's no different from accidentally doing
> readl(&sys_manager_base_addr->ctrl) instead of
> rst_manager_base_addr->ctrl.
> 

I also don't really like to use structs for register offsets. So unless,
there's some standard to use them in machine code, I'm not going to use
them in mach-socfpga.

I apologize for not getting to a v3 for this patch series with Mike's
recommended change for using composite clocks as quickly as I would have
like. I hope to have a v3 by next week.

Dinh
> 
> -Olof
> 





From nicolas.ferre at atmel.com  Thu Apr  4 12:27:42 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Thu, 4 Apr 2013 18:27:42 +0200
Subject: [PATCH v2] ARM: at91/at91sam9260.dtsi: fix u(s)art pinctrl encoding
In-Reply-To: <515D7A4F.90707@interlog.com>
References: <515D7A4F.90707@interlog.com>
Message-ID: <1365092862-3479-1-git-send-email-nicolas.ferre@atmel.com>

From: Douglas Gilbert <dgilbert at interlog.com>

Signed-off-by: Douglas Gilbert <dgilbert at interlog.com>
[nicolas.ferre at atmel.com: fix rts/cts for usart3]
Signed-off-by: Nicolas Ferre <nicolas.ferre at atmel.com>
Cc: stable <stable at vger.kernel.org> #3.8+
---
Hi,

v2: - add commit message
    - correct rts/cts for usart3
    - add stable tag

 arch/arm/boot/dts/at91sam9260.dtsi | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/arch/arm/boot/dts/at91sam9260.dtsi b/arch/arm/boot/dts/at91sam9260.dtsi
index 367a604..3e2adfb 100644
--- a/arch/arm/boot/dts/at91sam9260.dtsi
+++ b/arch/arm/boot/dts/at91sam9260.dtsi
@@ -158,8 +158,8 @@
 				usart1 {
 					pinctrl_usart1: usart1-0 {
 						atmel,pins =
-							<2 6 0x1 0x1	/* PB6 periph A with pullup */
-							 2 7 0x1 0x0>;	/* PB7 periph A */
+							<1 6 0x1 0x1	/* PB6 periph A with pullup */
+							 1 7 0x1 0x0>;	/* PB7 periph A */
 					};
 
 					pinctrl_usart1_rts: usart1_rts-0 {
@@ -194,18 +194,18 @@
 				usart3 {
 					pinctrl_usart3: usart3-0 {
 						atmel,pins =
-							<2 10 0x1 0x1	/* PB10 periph A with pullup */
-							 2 11 0x1 0x0>;	/* PB11 periph A */
+							<1 10 0x1 0x1	/* PB10 periph A with pullup */
+							 1 11 0x1 0x0>;	/* PB11 periph A */
 					};
 
 					pinctrl_usart3_rts: usart3_rts-0 {
 						atmel,pins =
-							<3 8 0x2 0x0>;	/* PB8 periph B */
+							<2 8 0x2 0x0>;	/* PC8 periph B */
 					};
 
 					pinctrl_usart3_cts: usart3_cts-0 {
 						atmel,pins =
-							<3 10 0x2 0x0>;	/* PB10 periph B */
+							<2 10 0x2 0x0>;	/* PC10 periph B */
 					};
 				};
 
@@ -220,8 +220,8 @@
 				uart1 {
 					pinctrl_uart1: uart1-0 {
 						atmel,pins =
-							<2 12 0x1 0x1	/* PB12 periph A with pullup */
-							 2 13 0x1 0x0>;	/* PB13 periph A */
+							<1 12 0x1 0x1	/* PB12 periph A with pullup */
+							 1 13 0x1 0x0>;	/* PB13 periph A */
 					};
 				};
 
-- 
1.8.0



From tony at atomide.com  Thu Apr  4 12:33:46 2013
From: tony at atomide.com (Tony Lindgren)
Date: Thu, 4 Apr 2013 09:33:46 -0700
Subject: [RFC][PATCH 1/2] ARM: OMAP4: clock: Add device tree support
 for AUXCLKs
In-Reply-To: <515D0D8A.7030500@ti.com>
References: <1363703220-4777-1-git-send-email-rogerq@ti.com>
 <1363703220-4777-2-git-send-email-rogerq@ti.com>
 <20130403234242.GE10155@atomide.com> <515D0D8A.7030500@ti.com>
Message-ID: <20130404163346.GG10155@atomide.com>

* Rajendra Nayak <rnayak at ti.com> [130403 22:25]:
> On Thursday 04 April 2013 05:12 AM, Tony Lindgren wrote:
> > 
> > How about just add a minimal drivers/clk/omap/clk-xyz.c that takes
> > the configuration from DT and is based on the binding we already have in
> > Documentation/devicetree/bindings/clock/clock-bindings.txt?
> > 
> > Then as we add new bindings there we can drop them from current
> > cclock44xx_data.c, no? That is after omap4 is DT only..
> 
> The patch just provides an alternative for clkdev mapping in case of DT.
> Are you suggesting we move all *clock data* related to auxclks (and eventually
> all clocks) into DT?

Well I think we should have a driver that can take any defined clock binding
from DT at least for boottime clocks. We need at least the timer clocks
early during the boot, and probably the root device like MMC or possibly
Ethernet depending on the board.

The rest of the huge amount of clocks we can just load from /lib/firmware
after mounting intramfs or root on MMC. As long as we can define any
boottime clock in DT also, loading the rest of the clock data from
/lib/firmware should not cause issues with booting.

And as we get the clocks moved, we can drop them from cclock44xx_data.c.
AFAIK the new driver can just clk_get the parent clocks so those can
stay in cclock44xx_data.c for now?

So basically we can do the same as we are already doing with pinctrl-single.c,
but with addition of loading large amounts of data from /lib/firmware.
And eventually we can do the same with hwmod too.

Regarding the readability issue, we now have preprocessing support for
.dts files merged AFAIK, so they can be as readable as data structures :)

> We have discussed this multiple times in the past, and moving 250 clock nodes
> with each needing multiple register offsets, masks, shifts etc into DT makes it
> completely un-readable. For me, having a way for devices to reference a clock that they
> use for a device using DT makes sense, but not moving all clock data into dts files.

Yes that's why we should also support loading clocks from /lib/firmware.
Naturally the parent clocks can be allocated by the clock driver(s) at
least initially.

But the main reason I think we should do this is so we get out of the
flame path with these huge data files for every new SoC.

Regards,

Tony


From t.figa at samsung.com  Thu Apr  4 12:36:57 2013
From: t.figa at samsung.com (Tomasz Figa)
Date: Thu, 04 Apr 2013 18:36:57 +0200
Subject: [PATCH v4 00/14] ARM: samsung-time: Prepare for multiplatform support
Message-ID: <1365093431-30621-1-git-send-email-t.figa@samsung.com>

This series is an attempt to make the samsung-time clocksource driver ready
for multiplatform kernels. It moves the driver to drivers/clocksource, cleans
it up from uses of static platform-specific definitions, simplifies timer
interrupt handling and adds Device Tree support.

Only samsung-time driver is reworked to use the master driver at this time,
since the PWM driver can be already considered broken at the moment and
needs separate series of several patches to fix and clean it up, which
I am already working on.

Tested on Universal C210 board with Device Tree. Not tested without
Device Tree, since it has been already broken before this series.
Compile tested for other related SoCs.

Changes since v3:
(http://thread.gmane.org/gmane.linux.kernel.samsung-soc/16664/)
 - Changed the design to use common (master) driver for operations that
   can be done from both clocksource and PWM drivers (as suggested by
   Arnd Bergmann) - needed to properly synchronize access to PWM registers
 - Moved handling of PWM prescaler and divider to master driver

Changes since v2:
(http://thread.gmane.org/gmane.linux.kernel.samsung-soc/16158)
 - Addressed comments from Rob Herring and Mark Rutland
 - Removed unused register definitions
 - Replaced samsung,source-timer and samsung,event-timer properties
   with samsung,pwm-outputs property that defines which PWM channels
   are reserved for PWM outputs on particular platform
 - Split non-DT and DT initialization into two functions
 - Fixed a copy paste error

Changes since v1:
(http://thread.gmane.org/gmane.linux.kernel.samsung-soc/16005)
 - Addressed comments from Mark Rutland
 - Documented struct samsung_timer_variant
 - Dropped inactive mail addresses from CC

Tomasz Figa (14):
  ARM: SAMSUNG: Move samsung-time to drivers/clocksource
  clocksource: samsung-time: Drop useless defines from public header
  clocksource: samsung-time: Use local register definitions
  mfd: Add Samsung PWM/timer master driver
  ARM: SAMSUNG: Unify base address definitions of timer block
  ARM: SAMSUNG: Add new PWM platform device
  ARM: SAMSUNG: Set PWM platform data
  clocksource: samsung-time: Use Samsung PWM/timer master driver
  clocksource: samsung-time: Use variant data to get SoC-specific bits
  clocksource: samsung-time: Use master driver to configure dividers
  clocksource: samsung-time: Use clk_prepare_enable
  clocksource: samsung-time: Use master driver to control PWM channels
  clocksource: samsung-time: Move IRQ mask/ack handling to the driver
  ARM: SAMSUNG: Remove unused PWM timer IRQ chip code

 .../devicetree/bindings/pwm/pwm-samsung.txt        |  37 ++
 arch/arm/Kconfig                                   |   1 -
 arch/arm/mach-exynos/common.c                      |  10 +
 arch/arm/mach-exynos/include/mach/irqs.h           |   3 +-
 arch/arm/mach-exynos/include/mach/map.h            |   1 +
 arch/arm/mach-s3c24xx/common.c                     |  10 +
 arch/arm/mach-s3c24xx/include/mach/irqs.h          |   6 +
 arch/arm/mach-s3c24xx/include/mach/map.h           |   2 +
 arch/arm/mach-s3c64xx/common.c                     |  14 +-
 arch/arm/mach-s3c64xx/include/mach/irqs.h          |   8 -
 arch/arm/mach-s3c64xx/include/mach/map.h           |   1 +
 arch/arm/mach-s5p64x0/common.c                     |  10 +
 arch/arm/mach-s5p64x0/include/mach/irqs.h          |   2 -
 arch/arm/mach-s5p64x0/include/mach/map.h           |   1 +
 arch/arm/mach-s5pc100/common.c                     |  10 +
 arch/arm/mach-s5pc100/include/mach/irqs.h          |   2 -
 arch/arm/mach-s5pc100/include/mach/map.h           |   1 +
 arch/arm/mach-s5pv210/common.c                     |  10 +
 arch/arm/mach-s5pv210/include/mach/irqs.h          |   2 -
 arch/arm/mach-s5pv210/include/mach/map.h           |   1 +
 arch/arm/plat-samsung/Kconfig                      |  14 -
 arch/arm/plat-samsung/Makefile                     |   2 -
 arch/arm/plat-samsung/devs.c                       |  33 +-
 arch/arm/plat-samsung/include/plat/devs.h          |   1 +
 arch/arm/plat-samsung/include/plat/irq-vic-timer.h |  13 -
 arch/arm/plat-samsung/include/plat/irqs.h          |   9 -
 arch/arm/plat-samsung/include/plat/samsung-time.h  |  38 +-
 arch/arm/plat-samsung/irq-vic-timer.c              |  98 -----
 arch/arm/plat-samsung/s5p-irq.c                    |   3 -
 arch/arm/plat-samsung/samsung-time.c               | 394 ------------------
 drivers/clocksource/Kconfig                        |   8 +
 drivers/clocksource/Makefile                       |   1 +
 drivers/clocksource/samsung-time.c                 | 298 ++++++++++++++
 drivers/mfd/Kconfig                                |   3 +
 drivers/mfd/Makefile                               |   1 +
 drivers/mfd/samsung-pwm.c                          | 439 +++++++++++++++++++++
 drivers/pwm/Kconfig                                |   1 +
 include/linux/mfd/samsung-pwm.h                    |  49 +++
 include/linux/platform_data/samsung-pwm.h          |  29 ++
 39 files changed, 983 insertions(+), 583 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/pwm/pwm-samsung.txt
 delete mode 100644 arch/arm/plat-samsung/include/plat/irq-vic-timer.h
 delete mode 100644 arch/arm/plat-samsung/irq-vic-timer.c
 delete mode 100644 arch/arm/plat-samsung/samsung-time.c
 create mode 100644 drivers/clocksource/samsung-time.c
 create mode 100644 drivers/mfd/samsung-pwm.c
 create mode 100644 include/linux/mfd/samsung-pwm.h
 create mode 100644 include/linux/platform_data/samsung-pwm.h

-- 
1.8.1.5



From t.figa at samsung.com  Thu Apr  4 12:36:58 2013
From: t.figa at samsung.com (Tomasz Figa)
Date: Thu, 04 Apr 2013 18:36:58 +0200
Subject: [PATCH v4 01/14] ARM: SAMSUNG: Move samsung-time to
 drivers/clocksource
In-Reply-To: <1365093431-30621-1-git-send-email-t.figa@samsung.com>
References: <1365093431-30621-1-git-send-email-t.figa@samsung.com>
Message-ID: <1365093431-30621-2-git-send-email-t.figa@samsung.com>

This patch moves the Samsung PWM-based high resolution timer support
code from arch/arm/plat-samsung to drivers/clocksource.

This is a prerequisite for further work on making the driver more
multiplatform and Device Tree friendly.

Signed-off-by: Tomasz Figa <t.figa at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
---
 arch/arm/plat-samsung/Kconfig        |   8 -
 arch/arm/plat-samsung/Makefile       |   1 -
 arch/arm/plat-samsung/samsung-time.c | 394 -----------------------------------
 drivers/clocksource/Kconfig          |   7 +
 drivers/clocksource/Makefile         |   1 +
 drivers/clocksource/samsung-time.c   | 394 +++++++++++++++++++++++++++++++++++
 6 files changed, 402 insertions(+), 403 deletions(-)
 delete mode 100644 arch/arm/plat-samsung/samsung-time.c
 create mode 100644 drivers/clocksource/samsung-time.c

diff --git a/arch/arm/plat-samsung/Kconfig b/arch/arm/plat-samsung/Kconfig
index 54d1861..6f632ba 100644
--- a/arch/arm/plat-samsung/Kconfig
+++ b/arch/arm/plat-samsung/Kconfig
@@ -60,14 +60,6 @@ config S3C_LOWLEVEL_UART_PORT
 	  this configuration should be between zero and two. The port
 	  must have been initialised by the boot-loader before use.
 
-# timer options
-
-config SAMSUNG_HRT
-	bool
-	select SAMSUNG_DEV_PWM
-	help
-	  Use the High Resolution timer support
-
 # clock options
 
 config SAMSUNG_CLOCK
diff --git a/arch/arm/plat-samsung/Makefile b/arch/arm/plat-samsung/Makefile
index a23c460..87494e1 100644
--- a/arch/arm/plat-samsung/Makefile
+++ b/arch/arm/plat-samsung/Makefile
@@ -12,7 +12,6 @@ obj-				:=
 # Objects we always build independent of SoC choice
 
 obj-y				+= init.o cpu.o
-obj-$(CONFIG_SAMSUNG_HRT) 	+= samsung-time.o
 
 obj-$(CONFIG_SAMSUNG_CLOCK)	+= clock.o
 obj-$(CONFIG_SAMSUNG_CLOCK)	+= pwm-clock.o
diff --git a/arch/arm/plat-samsung/samsung-time.c b/arch/arm/plat-samsung/samsung-time.c
deleted file mode 100644
index f899cbc..0000000
--- a/arch/arm/plat-samsung/samsung-time.c
+++ /dev/null
@@ -1,394 +0,0 @@
-/*
- * Copyright (c) 2011 Samsung Electronics Co., Ltd.
- *		http://www.samsung.com/
- *
- * samsung - Common hr-timer support (s3c and s5p)
- *
- * 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/interrupt.h>
-#include <linux/irq.h>
-#include <linux/err.h>
-#include <linux/clk.h>
-#include <linux/clockchips.h>
-#include <linux/platform_device.h>
-
-#include <asm/smp_twd.h>
-#include <asm/mach/time.h>
-#include <asm/mach/arch.h>
-#include <asm/mach/map.h>
-#include <asm/sched_clock.h>
-
-#include <mach/map.h>
-#include <plat/devs.h>
-#include <plat/regs-timer.h>
-#include <plat/samsung-time.h>
-
-static struct clk *tin_event;
-static struct clk *tin_source;
-static struct clk *tdiv_event;
-static struct clk *tdiv_source;
-static struct clk *timerclk;
-static struct samsung_timer_source timer_source;
-static unsigned long clock_count_per_tick;
-static void samsung_timer_resume(void);
-
-static void samsung_time_stop(enum samsung_timer_mode mode)
-{
-	unsigned long tcon;
-
-	tcon = __raw_readl(S3C2410_TCON);
-
-	switch (mode) {
-	case SAMSUNG_PWM0:
-		tcon &= ~S3C2410_TCON_T0START;
-		break;
-
-	case SAMSUNG_PWM1:
-		tcon &= ~S3C2410_TCON_T1START;
-		break;
-
-	case SAMSUNG_PWM2:
-		tcon &= ~S3C2410_TCON_T2START;
-		break;
-
-	case SAMSUNG_PWM3:
-		tcon &= ~S3C2410_TCON_T3START;
-		break;
-
-	case SAMSUNG_PWM4:
-		tcon &= ~S3C2410_TCON_T4START;
-		break;
-
-	default:
-		printk(KERN_ERR "Invalid Timer %d\n", mode);
-		break;
-	}
-	__raw_writel(tcon, S3C2410_TCON);
-}
-
-static void samsung_time_setup(enum samsung_timer_mode mode, unsigned long tcnt)
-{
-	unsigned long tcon;
-
-	tcon = __raw_readl(S3C2410_TCON);
-
-	tcnt--;
-
-	switch (mode) {
-	case SAMSUNG_PWM0:
-		tcon &= ~(0x0f << 0);
-		tcon |= S3C2410_TCON_T0MANUALUPD;
-		break;
-
-	case SAMSUNG_PWM1:
-		tcon &= ~(0x0f << 8);
-		tcon |= S3C2410_TCON_T1MANUALUPD;
-		break;
-
-	case SAMSUNG_PWM2:
-		tcon &= ~(0x0f << 12);
-		tcon |= S3C2410_TCON_T2MANUALUPD;
-		break;
-
-	case SAMSUNG_PWM3:
-		tcon &= ~(0x0f << 16);
-		tcon |= S3C2410_TCON_T3MANUALUPD;
-		break;
-
-	case SAMSUNG_PWM4:
-		tcon &= ~(0x07 << 20);
-		tcon |= S3C2410_TCON_T4MANUALUPD;
-		break;
-
-	default:
-		printk(KERN_ERR "Invalid Timer %d\n", mode);
-		break;
-	}
-
-	__raw_writel(tcnt, S3C2410_TCNTB(mode));
-	__raw_writel(tcnt, S3C2410_TCMPB(mode));
-	__raw_writel(tcon, S3C2410_TCON);
-}
-
-static void samsung_time_start(enum samsung_timer_mode mode, bool periodic)
-{
-	unsigned long tcon;
-
-	tcon  = __raw_readl(S3C2410_TCON);
-
-	switch (mode) {
-	case SAMSUNG_PWM0:
-		tcon |= S3C2410_TCON_T0START;
-		tcon &= ~S3C2410_TCON_T0MANUALUPD;
-
-		if (periodic)
-			tcon |= S3C2410_TCON_T0RELOAD;
-		else
-			tcon &= ~S3C2410_TCON_T0RELOAD;
-		break;
-
-	case SAMSUNG_PWM1:
-		tcon |= S3C2410_TCON_T1START;
-		tcon &= ~S3C2410_TCON_T1MANUALUPD;
-
-		if (periodic)
-			tcon |= S3C2410_TCON_T1RELOAD;
-		else
-			tcon &= ~S3C2410_TCON_T1RELOAD;
-		break;
-
-	case SAMSUNG_PWM2:
-		tcon |= S3C2410_TCON_T2START;
-		tcon &= ~S3C2410_TCON_T2MANUALUPD;
-
-		if (periodic)
-			tcon |= S3C2410_TCON_T2RELOAD;
-		else
-			tcon &= ~S3C2410_TCON_T2RELOAD;
-		break;
-
-	case SAMSUNG_PWM3:
-		tcon |= S3C2410_TCON_T3START;
-		tcon &= ~S3C2410_TCON_T3MANUALUPD;
-
-		if (periodic)
-			tcon |= S3C2410_TCON_T3RELOAD;
-		else
-			tcon &= ~S3C2410_TCON_T3RELOAD;
-		break;
-
-	case SAMSUNG_PWM4:
-		tcon |= S3C2410_TCON_T4START;
-		tcon &= ~S3C2410_TCON_T4MANUALUPD;
-
-		if (periodic)
-			tcon |= S3C2410_TCON_T4RELOAD;
-		else
-			tcon &= ~S3C2410_TCON_T4RELOAD;
-		break;
-
-	default:
-		printk(KERN_ERR "Invalid Timer %d\n", mode);
-		break;
-	}
-	__raw_writel(tcon, S3C2410_TCON);
-}
-
-static int samsung_set_next_event(unsigned long cycles,
-				struct clock_event_device *evt)
-{
-	samsung_time_setup(timer_source.event_id, cycles);
-	samsung_time_start(timer_source.event_id, NON_PERIODIC);
-
-	return 0;
-}
-
-static void samsung_set_mode(enum clock_event_mode mode,
-				struct clock_event_device *evt)
-{
-	samsung_time_stop(timer_source.event_id);
-
-	switch (mode) {
-	case CLOCK_EVT_MODE_PERIODIC:
-		samsung_time_setup(timer_source.event_id, clock_count_per_tick);
-		samsung_time_start(timer_source.event_id, PERIODIC);
-		break;
-
-	case CLOCK_EVT_MODE_ONESHOT:
-		break;
-
-	case CLOCK_EVT_MODE_UNUSED:
-	case CLOCK_EVT_MODE_SHUTDOWN:
-		break;
-
-	case CLOCK_EVT_MODE_RESUME:
-		samsung_timer_resume();
-		break;
-	}
-}
-
-static void samsung_timer_resume(void)
-{
-	/* event timer restart */
-	samsung_time_setup(timer_source.event_id, clock_count_per_tick);
-	samsung_time_start(timer_source.event_id, PERIODIC);
-
-	/* source timer restart */
-	samsung_time_setup(timer_source.source_id, TCNT_MAX);
-	samsung_time_start(timer_source.source_id, PERIODIC);
-}
-
-void __init samsung_set_timer_source(enum samsung_timer_mode event,
-				 enum samsung_timer_mode source)
-{
-	s3c_device_timer[event].dev.bus = &platform_bus_type;
-	s3c_device_timer[source].dev.bus = &platform_bus_type;
-
-	timer_source.event_id = event;
-	timer_source.source_id = source;
-}
-
-static struct clock_event_device time_event_device = {
-	.name		= "samsung_event_timer",
-	.features	= CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT,
-	.rating		= 200,
-	.set_next_event	= samsung_set_next_event,
-	.set_mode	= samsung_set_mode,
-};
-
-static irqreturn_t samsung_clock_event_isr(int irq, void *dev_id)
-{
-	struct clock_event_device *evt = dev_id;
-
-	evt->event_handler(evt);
-
-	return IRQ_HANDLED;
-}
-
-static struct irqaction samsung_clock_event_irq = {
-	.name		= "samsung_time_irq",
-	.flags		= IRQF_DISABLED | IRQF_TIMER | IRQF_IRQPOLL,
-	.handler	= samsung_clock_event_isr,
-	.dev_id		= &time_event_device,
-};
-
-static void __init samsung_clockevent_init(void)
-{
-	unsigned long pclk;
-	unsigned long clock_rate;
-	unsigned int irq_number;
-	struct clk *tscaler;
-
-	pclk = clk_get_rate(timerclk);
-
-	tscaler = clk_get_parent(tdiv_event);
-
-	clk_set_rate(tscaler, pclk / TSCALER_DIV);
-	clk_set_rate(tdiv_event, pclk / TDIV);
-	clk_set_parent(tin_event, tdiv_event);
-
-	clock_rate = clk_get_rate(tin_event);
-	clock_count_per_tick = clock_rate / HZ;
-
-	time_event_device.cpumask = cpumask_of(0);
-	clockevents_config_and_register(&time_event_device, clock_rate, 1, -1);
-
-	irq_number = timer_source.event_id + IRQ_TIMER0;
-	setup_irq(irq_number, &samsung_clock_event_irq);
-}
-
-static void __iomem *samsung_timer_reg(void)
-{
-	unsigned long offset = 0;
-
-	switch (timer_source.source_id) {
-	case SAMSUNG_PWM0:
-	case SAMSUNG_PWM1:
-	case SAMSUNG_PWM2:
-	case SAMSUNG_PWM3:
-		offset = (timer_source.source_id * 0x0c) + 0x14;
-		break;
-
-	case SAMSUNG_PWM4:
-		offset = 0x40;
-		break;
-
-	default:
-		printk(KERN_ERR "Invalid Timer %d\n", timer_source.source_id);
-		return NULL;
-	}
-
-	return S3C_TIMERREG(offset);
-}
-
-/*
- * Override the global weak sched_clock symbol with this
- * local implementation which uses the clocksource to get some
- * better resolution when scheduling the kernel. We accept that
- * this wraps around for now, since it is just a relative time
- * stamp. (Inspired by U300 implementation.)
- */
-static u32 notrace samsung_read_sched_clock(void)
-{
-	void __iomem *reg = samsung_timer_reg();
-
-	if (!reg)
-		return 0;
-
-	return ~__raw_readl(reg);
-}
-
-static void __init samsung_clocksource_init(void)
-{
-	unsigned long pclk;
-	unsigned long clock_rate;
-
-	pclk = clk_get_rate(timerclk);
-
-	clk_set_rate(tdiv_source, pclk / TDIV);
-	clk_set_parent(tin_source, tdiv_source);
-
-	clock_rate = clk_get_rate(tin_source);
-
-	samsung_time_setup(timer_source.source_id, TCNT_MAX);
-	samsung_time_start(timer_source.source_id, PERIODIC);
-
-	setup_sched_clock(samsung_read_sched_clock, TSIZE, clock_rate);
-
-	if (clocksource_mmio_init(samsung_timer_reg(), "samsung_clocksource_timer",
-			clock_rate, 250, TSIZE, clocksource_mmio_readl_down))
-		panic("samsung_clocksource_timer: can't register clocksource\n");
-}
-
-static void __init samsung_timer_resources(void)
-{
-
-	unsigned long event_id = timer_source.event_id;
-	unsigned long source_id = timer_source.source_id;
-	char devname[15];
-
-	timerclk = clk_get(NULL, "timers");
-	if (IS_ERR(timerclk))
-		panic("failed to get timers clock for timer");
-
-	clk_enable(timerclk);
-
-	sprintf(devname, "s3c24xx-pwm.%lu", event_id);
-	s3c_device_timer[event_id].id = event_id;
-	s3c_device_timer[event_id].dev.init_name = devname;
-
-	tin_event = clk_get(&s3c_device_timer[event_id].dev, "pwm-tin");
-	if (IS_ERR(tin_event))
-		panic("failed to get pwm-tin clock for event timer");
-
-	tdiv_event = clk_get(&s3c_device_timer[event_id].dev, "pwm-tdiv");
-	if (IS_ERR(tdiv_event))
-		panic("failed to get pwm-tdiv clock for event timer");
-
-	clk_enable(tin_event);
-
-	sprintf(devname, "s3c24xx-pwm.%lu", source_id);
-	s3c_device_timer[source_id].id = source_id;
-	s3c_device_timer[source_id].dev.init_name = devname;
-
-	tin_source = clk_get(&s3c_device_timer[source_id].dev, "pwm-tin");
-	if (IS_ERR(tin_source))
-		panic("failed to get pwm-tin clock for source timer");
-
-	tdiv_source = clk_get(&s3c_device_timer[source_id].dev, "pwm-tdiv");
-	if (IS_ERR(tdiv_source))
-		panic("failed to get pwm-tdiv clock for source timer");
-
-	clk_enable(tin_source);
-}
-
-void __init samsung_timer_init(void)
-{
-	samsung_timer_resources();
-	samsung_clockevent_init();
-	samsung_clocksource_init();
-}
diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index e8c4532..dd20f6a 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -25,6 +25,13 @@ config DW_APB_TIMER_OF
 config ARMADA_370_XP_TIMER
 	bool
 
+config SAMSUNG_HRT
+	bool
+	depends on PLAT_SAMSUNG
+	select SAMSUNG_DEV_PWM
+	help
+	  Use the high resolution timer support on Samsung platforms.
+
 config SUNXI_TIMER
 	bool
 
diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index 1c1b15d..0d68580 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -16,6 +16,7 @@ obj-$(CONFIG_CLKSRC_NOMADIK_MTU)	+= nomadik-mtu.o
 obj-$(CONFIG_CLKSRC_DBX500_PRCMU)	+= clksrc-dbx500-prcmu.o
 obj-$(CONFIG_ARMADA_370_XP_TIMER)	+= time-armada-370-xp.o
 obj-$(CONFIG_ARCH_BCM2835)	+= bcm2835_timer.o
+obj-$(CONFIG_SAMSUNG_HRT) 	+= samsung-time.o
 obj-$(CONFIG_SUNXI_TIMER)	+= sunxi_timer.o
 obj-$(CONFIG_ARCH_TEGRA)	+= tegra20_timer.o
 obj-$(CONFIG_VT8500_TIMER)	+= vt8500_timer.o
diff --git a/drivers/clocksource/samsung-time.c b/drivers/clocksource/samsung-time.c
new file mode 100644
index 0000000..f899cbc
--- /dev/null
+++ b/drivers/clocksource/samsung-time.c
@@ -0,0 +1,394 @@
+/*
+ * Copyright (c) 2011 Samsung Electronics Co., Ltd.
+ *		http://www.samsung.com/
+ *
+ * samsung - Common hr-timer support (s3c and s5p)
+ *
+ * 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/interrupt.h>
+#include <linux/irq.h>
+#include <linux/err.h>
+#include <linux/clk.h>
+#include <linux/clockchips.h>
+#include <linux/platform_device.h>
+
+#include <asm/smp_twd.h>
+#include <asm/mach/time.h>
+#include <asm/mach/arch.h>
+#include <asm/mach/map.h>
+#include <asm/sched_clock.h>
+
+#include <mach/map.h>
+#include <plat/devs.h>
+#include <plat/regs-timer.h>
+#include <plat/samsung-time.h>
+
+static struct clk *tin_event;
+static struct clk *tin_source;
+static struct clk *tdiv_event;
+static struct clk *tdiv_source;
+static struct clk *timerclk;
+static struct samsung_timer_source timer_source;
+static unsigned long clock_count_per_tick;
+static void samsung_timer_resume(void);
+
+static void samsung_time_stop(enum samsung_timer_mode mode)
+{
+	unsigned long tcon;
+
+	tcon = __raw_readl(S3C2410_TCON);
+
+	switch (mode) {
+	case SAMSUNG_PWM0:
+		tcon &= ~S3C2410_TCON_T0START;
+		break;
+
+	case SAMSUNG_PWM1:
+		tcon &= ~S3C2410_TCON_T1START;
+		break;
+
+	case SAMSUNG_PWM2:
+		tcon &= ~S3C2410_TCON_T2START;
+		break;
+
+	case SAMSUNG_PWM3:
+		tcon &= ~S3C2410_TCON_T3START;
+		break;
+
+	case SAMSUNG_PWM4:
+		tcon &= ~S3C2410_TCON_T4START;
+		break;
+
+	default:
+		printk(KERN_ERR "Invalid Timer %d\n", mode);
+		break;
+	}
+	__raw_writel(tcon, S3C2410_TCON);
+}
+
+static void samsung_time_setup(enum samsung_timer_mode mode, unsigned long tcnt)
+{
+	unsigned long tcon;
+
+	tcon = __raw_readl(S3C2410_TCON);
+
+	tcnt--;
+
+	switch (mode) {
+	case SAMSUNG_PWM0:
+		tcon &= ~(0x0f << 0);
+		tcon |= S3C2410_TCON_T0MANUALUPD;
+		break;
+
+	case SAMSUNG_PWM1:
+		tcon &= ~(0x0f << 8);
+		tcon |= S3C2410_TCON_T1MANUALUPD;
+		break;
+
+	case SAMSUNG_PWM2:
+		tcon &= ~(0x0f << 12);
+		tcon |= S3C2410_TCON_T2MANUALUPD;
+		break;
+
+	case SAMSUNG_PWM3:
+		tcon &= ~(0x0f << 16);
+		tcon |= S3C2410_TCON_T3MANUALUPD;
+		break;
+
+	case SAMSUNG_PWM4:
+		tcon &= ~(0x07 << 20);
+		tcon |= S3C2410_TCON_T4MANUALUPD;
+		break;
+
+	default:
+		printk(KERN_ERR "Invalid Timer %d\n", mode);
+		break;
+	}
+
+	__raw_writel(tcnt, S3C2410_TCNTB(mode));
+	__raw_writel(tcnt, S3C2410_TCMPB(mode));
+	__raw_writel(tcon, S3C2410_TCON);
+}
+
+static void samsung_time_start(enum samsung_timer_mode mode, bool periodic)
+{
+	unsigned long tcon;
+
+	tcon  = __raw_readl(S3C2410_TCON);
+
+	switch (mode) {
+	case SAMSUNG_PWM0:
+		tcon |= S3C2410_TCON_T0START;
+		tcon &= ~S3C2410_TCON_T0MANUALUPD;
+
+		if (periodic)
+			tcon |= S3C2410_TCON_T0RELOAD;
+		else
+			tcon &= ~S3C2410_TCON_T0RELOAD;
+		break;
+
+	case SAMSUNG_PWM1:
+		tcon |= S3C2410_TCON_T1START;
+		tcon &= ~S3C2410_TCON_T1MANUALUPD;
+
+		if (periodic)
+			tcon |= S3C2410_TCON_T1RELOAD;
+		else
+			tcon &= ~S3C2410_TCON_T1RELOAD;
+		break;
+
+	case SAMSUNG_PWM2:
+		tcon |= S3C2410_TCON_T2START;
+		tcon &= ~S3C2410_TCON_T2MANUALUPD;
+
+		if (periodic)
+			tcon |= S3C2410_TCON_T2RELOAD;
+		else
+			tcon &= ~S3C2410_TCON_T2RELOAD;
+		break;
+
+	case SAMSUNG_PWM3:
+		tcon |= S3C2410_TCON_T3START;
+		tcon &= ~S3C2410_TCON_T3MANUALUPD;
+
+		if (periodic)
+			tcon |= S3C2410_TCON_T3RELOAD;
+		else
+			tcon &= ~S3C2410_TCON_T3RELOAD;
+		break;
+
+	case SAMSUNG_PWM4:
+		tcon |= S3C2410_TCON_T4START;
+		tcon &= ~S3C2410_TCON_T4MANUALUPD;
+
+		if (periodic)
+			tcon |= S3C2410_TCON_T4RELOAD;
+		else
+			tcon &= ~S3C2410_TCON_T4RELOAD;
+		break;
+
+	default:
+		printk(KERN_ERR "Invalid Timer %d\n", mode);
+		break;
+	}
+	__raw_writel(tcon, S3C2410_TCON);
+}
+
+static int samsung_set_next_event(unsigned long cycles,
+				struct clock_event_device *evt)
+{
+	samsung_time_setup(timer_source.event_id, cycles);
+	samsung_time_start(timer_source.event_id, NON_PERIODIC);
+
+	return 0;
+}
+
+static void samsung_set_mode(enum clock_event_mode mode,
+				struct clock_event_device *evt)
+{
+	samsung_time_stop(timer_source.event_id);
+
+	switch (mode) {
+	case CLOCK_EVT_MODE_PERIODIC:
+		samsung_time_setup(timer_source.event_id, clock_count_per_tick);
+		samsung_time_start(timer_source.event_id, PERIODIC);
+		break;
+
+	case CLOCK_EVT_MODE_ONESHOT:
+		break;
+
+	case CLOCK_EVT_MODE_UNUSED:
+	case CLOCK_EVT_MODE_SHUTDOWN:
+		break;
+
+	case CLOCK_EVT_MODE_RESUME:
+		samsung_timer_resume();
+		break;
+	}
+}
+
+static void samsung_timer_resume(void)
+{
+	/* event timer restart */
+	samsung_time_setup(timer_source.event_id, clock_count_per_tick);
+	samsung_time_start(timer_source.event_id, PERIODIC);
+
+	/* source timer restart */
+	samsung_time_setup(timer_source.source_id, TCNT_MAX);
+	samsung_time_start(timer_source.source_id, PERIODIC);
+}
+
+void __init samsung_set_timer_source(enum samsung_timer_mode event,
+				 enum samsung_timer_mode source)
+{
+	s3c_device_timer[event].dev.bus = &platform_bus_type;
+	s3c_device_timer[source].dev.bus = &platform_bus_type;
+
+	timer_source.event_id = event;
+	timer_source.source_id = source;
+}
+
+static struct clock_event_device time_event_device = {
+	.name		= "samsung_event_timer",
+	.features	= CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT,
+	.rating		= 200,
+	.set_next_event	= samsung_set_next_event,
+	.set_mode	= samsung_set_mode,
+};
+
+static irqreturn_t samsung_clock_event_isr(int irq, void *dev_id)
+{
+	struct clock_event_device *evt = dev_id;
+
+	evt->event_handler(evt);
+
+	return IRQ_HANDLED;
+}
+
+static struct irqaction samsung_clock_event_irq = {
+	.name		= "samsung_time_irq",
+	.flags		= IRQF_DISABLED | IRQF_TIMER | IRQF_IRQPOLL,
+	.handler	= samsung_clock_event_isr,
+	.dev_id		= &time_event_device,
+};
+
+static void __init samsung_clockevent_init(void)
+{
+	unsigned long pclk;
+	unsigned long clock_rate;
+	unsigned int irq_number;
+	struct clk *tscaler;
+
+	pclk = clk_get_rate(timerclk);
+
+	tscaler = clk_get_parent(tdiv_event);
+
+	clk_set_rate(tscaler, pclk / TSCALER_DIV);
+	clk_set_rate(tdiv_event, pclk / TDIV);
+	clk_set_parent(tin_event, tdiv_event);
+
+	clock_rate = clk_get_rate(tin_event);
+	clock_count_per_tick = clock_rate / HZ;
+
+	time_event_device.cpumask = cpumask_of(0);
+	clockevents_config_and_register(&time_event_device, clock_rate, 1, -1);
+
+	irq_number = timer_source.event_id + IRQ_TIMER0;
+	setup_irq(irq_number, &samsung_clock_event_irq);
+}
+
+static void __iomem *samsung_timer_reg(void)
+{
+	unsigned long offset = 0;
+
+	switch (timer_source.source_id) {
+	case SAMSUNG_PWM0:
+	case SAMSUNG_PWM1:
+	case SAMSUNG_PWM2:
+	case SAMSUNG_PWM3:
+		offset = (timer_source.source_id * 0x0c) + 0x14;
+		break;
+
+	case SAMSUNG_PWM4:
+		offset = 0x40;
+		break;
+
+	default:
+		printk(KERN_ERR "Invalid Timer %d\n", timer_source.source_id);
+		return NULL;
+	}
+
+	return S3C_TIMERREG(offset);
+}
+
+/*
+ * Override the global weak sched_clock symbol with this
+ * local implementation which uses the clocksource to get some
+ * better resolution when scheduling the kernel. We accept that
+ * this wraps around for now, since it is just a relative time
+ * stamp. (Inspired by U300 implementation.)
+ */
+static u32 notrace samsung_read_sched_clock(void)
+{
+	void __iomem *reg = samsung_timer_reg();
+
+	if (!reg)
+		return 0;
+
+	return ~__raw_readl(reg);
+}
+
+static void __init samsung_clocksource_init(void)
+{
+	unsigned long pclk;
+	unsigned long clock_rate;
+
+	pclk = clk_get_rate(timerclk);
+
+	clk_set_rate(tdiv_source, pclk / TDIV);
+	clk_set_parent(tin_source, tdiv_source);
+
+	clock_rate = clk_get_rate(tin_source);
+
+	samsung_time_setup(timer_source.source_id, TCNT_MAX);
+	samsung_time_start(timer_source.source_id, PERIODIC);
+
+	setup_sched_clock(samsung_read_sched_clock, TSIZE, clock_rate);
+
+	if (clocksource_mmio_init(samsung_timer_reg(), "samsung_clocksource_timer",
+			clock_rate, 250, TSIZE, clocksource_mmio_readl_down))
+		panic("samsung_clocksource_timer: can't register clocksource\n");
+}
+
+static void __init samsung_timer_resources(void)
+{
+
+	unsigned long event_id = timer_source.event_id;
+	unsigned long source_id = timer_source.source_id;
+	char devname[15];
+
+	timerclk = clk_get(NULL, "timers");
+	if (IS_ERR(timerclk))
+		panic("failed to get timers clock for timer");
+
+	clk_enable(timerclk);
+
+	sprintf(devname, "s3c24xx-pwm.%lu", event_id);
+	s3c_device_timer[event_id].id = event_id;
+	s3c_device_timer[event_id].dev.init_name = devname;
+
+	tin_event = clk_get(&s3c_device_timer[event_id].dev, "pwm-tin");
+	if (IS_ERR(tin_event))
+		panic("failed to get pwm-tin clock for event timer");
+
+	tdiv_event = clk_get(&s3c_device_timer[event_id].dev, "pwm-tdiv");
+	if (IS_ERR(tdiv_event))
+		panic("failed to get pwm-tdiv clock for event timer");
+
+	clk_enable(tin_event);
+
+	sprintf(devname, "s3c24xx-pwm.%lu", source_id);
+	s3c_device_timer[source_id].id = source_id;
+	s3c_device_timer[source_id].dev.init_name = devname;
+
+	tin_source = clk_get(&s3c_device_timer[source_id].dev, "pwm-tin");
+	if (IS_ERR(tin_source))
+		panic("failed to get pwm-tin clock for source timer");
+
+	tdiv_source = clk_get(&s3c_device_timer[source_id].dev, "pwm-tdiv");
+	if (IS_ERR(tdiv_source))
+		panic("failed to get pwm-tdiv clock for source timer");
+
+	clk_enable(tin_source);
+}
+
+void __init samsung_timer_init(void)
+{
+	samsung_timer_resources();
+	samsung_clockevent_init();
+	samsung_clocksource_init();
+}
-- 
1.8.1.5



From t.figa at samsung.com  Thu Apr  4 12:36:59 2013
From: t.figa at samsung.com (Tomasz Figa)
Date: Thu, 04 Apr 2013 18:36:59 +0200
Subject: [PATCH v4 02/14] clocksource: samsung-time: Drop useless defines from
 public header
In-Reply-To: <1365093431-30621-1-git-send-email-t.figa@samsung.com>
References: <1365093431-30621-1-git-send-email-t.figa@samsung.com>
Message-ID: <1365093431-30621-3-git-send-email-t.figa@samsung.com>

This patch cleans up public header from useless definitions.

Signed-off-by: Tomasz Figa <t.figa at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
---
 arch/arm/plat-samsung/include/plat/samsung-time.h |  6 ------
 drivers/clocksource/samsung-time.c                | 10 +++++-----
 2 files changed, 5 insertions(+), 11 deletions(-)

diff --git a/arch/arm/plat-samsung/include/plat/samsung-time.h b/arch/arm/plat-samsung/include/plat/samsung-time.h
index 4cc99bb..5d098ef 100644
--- a/arch/arm/plat-samsung/include/plat/samsung-time.h
+++ b/arch/arm/plat-samsung/include/plat/samsung-time.h
@@ -27,9 +27,6 @@ struct samsung_timer_source {
 	unsigned int source_id;
 };
 
-/* Be able to sleep for atleast 4 seconds (usually more) */
-#define SAMSUNG_TIMER_MIN_RANGE	4
-
 #if defined(CONFIG_ARCH_S3C24XX) || defined(CONFIG_ARCH_S5PC100)
 #define TCNT_MAX		0xffff
 #define TSCALER_DIV		25
@@ -42,9 +39,6 @@ struct samsung_timer_source {
 #define TSIZE			32
 #endif
 
-#define NON_PERIODIC		0
-#define PERIODIC		1
-
 extern void __init samsung_set_timer_source(enum samsung_timer_mode event,
 					enum samsung_timer_mode source);
 
diff --git a/drivers/clocksource/samsung-time.c b/drivers/clocksource/samsung-time.c
index f899cbc..d4d7e3e 100644
--- a/drivers/clocksource/samsung-time.c
+++ b/drivers/clocksource/samsung-time.c
@@ -182,7 +182,7 @@ static int samsung_set_next_event(unsigned long cycles,
 				struct clock_event_device *evt)
 {
 	samsung_time_setup(timer_source.event_id, cycles);
-	samsung_time_start(timer_source.event_id, NON_PERIODIC);
+	samsung_time_start(timer_source.event_id, false);
 
 	return 0;
 }
@@ -195,7 +195,7 @@ static void samsung_set_mode(enum clock_event_mode mode,
 	switch (mode) {
 	case CLOCK_EVT_MODE_PERIODIC:
 		samsung_time_setup(timer_source.event_id, clock_count_per_tick);
-		samsung_time_start(timer_source.event_id, PERIODIC);
+		samsung_time_start(timer_source.event_id, true);
 		break;
 
 	case CLOCK_EVT_MODE_ONESHOT:
@@ -215,11 +215,11 @@ static void samsung_timer_resume(void)
 {
 	/* event timer restart */
 	samsung_time_setup(timer_source.event_id, clock_count_per_tick);
-	samsung_time_start(timer_source.event_id, PERIODIC);
+	samsung_time_start(timer_source.event_id, true);
 
 	/* source timer restart */
 	samsung_time_setup(timer_source.source_id, TCNT_MAX);
-	samsung_time_start(timer_source.source_id, PERIODIC);
+	samsung_time_start(timer_source.source_id, true);
 }
 
 void __init samsung_set_timer_source(enum samsung_timer_mode event,
@@ -335,7 +335,7 @@ static void __init samsung_clocksource_init(void)
 	clock_rate = clk_get_rate(tin_source);
 
 	samsung_time_setup(timer_source.source_id, TCNT_MAX);
-	samsung_time_start(timer_source.source_id, PERIODIC);
+	samsung_time_start(timer_source.source_id, true);
 
 	setup_sched_clock(samsung_read_sched_clock, TSIZE, clock_rate);
 
-- 
1.8.1.5



From t.figa at samsung.com  Thu Apr  4 12:37:00 2013
From: t.figa at samsung.com (Tomasz Figa)
Date: Thu, 04 Apr 2013 18:37:00 +0200
Subject: [PATCH v4 03/14] clocksource: samsung-time: Use local register
 definitions
In-Reply-To: <1365093431-30621-1-git-send-email-t.figa@samsung.com>
References: <1365093431-30621-1-git-send-email-t.figa@samsung.com>
Message-ID: <1365093431-30621-4-git-send-email-t.figa@samsung.com>

This patch copies PWM timer register definitions to samsung-time.c. The
original header in plat is being kept for now, since it is also used by
other code that also needs to be reworked to be multiplatform-friendly.

Signed-off-by: Tomasz Figa <t.figa at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
---
 drivers/clocksource/samsung-time.c | 36 +++++++++++++++++++++++++++++++++++-
 1 file changed, 35 insertions(+), 1 deletion(-)

diff --git a/drivers/clocksource/samsung-time.c b/drivers/clocksource/samsung-time.c
index d4d7e3e..bccc291 100644
--- a/drivers/clocksource/samsung-time.c
+++ b/drivers/clocksource/samsung-time.c
@@ -24,9 +24,43 @@
 
 #include <mach/map.h>
 #include <plat/devs.h>
-#include <plat/regs-timer.h>
 #include <plat/samsung-time.h>
 
+#define S3C_TIMERREG(x) (S3C_VA_TIMER + (x))
+#define S3C_TIMERREG2(tmr,reg) S3C_TIMERREG((reg)+0x0c+((tmr)*0x0c))
+
+#define S3C2410_TCON	      S3C_TIMERREG(0x08)
+#define S3C64XX_TINT_CSTAT    S3C_TIMERREG(0x44)
+
+/* for each timer, we have an count buffer, an compare buffer and
+ * an observation buffer
+*/
+
+/* WARNING - timer 4 has no buffer reg, and it's observation is at +4 */
+
+#define S3C2410_TCNTB(tmr)    S3C_TIMERREG2(tmr, 0x00)
+#define S3C2410_TCMPB(tmr)    S3C_TIMERREG2(tmr, 0x04)
+
+#define S3C2410_TCON_T4RELOAD	  (1<<22)
+#define S3C2410_TCON_T4MANUALUPD  (1<<21)
+#define S3C2410_TCON_T4START	  (1<<20)
+
+#define S3C2410_TCON_T3RELOAD	  (1<<19)
+#define S3C2410_TCON_T3MANUALUPD  (1<<17)
+#define S3C2410_TCON_T3START	  (1<<16)
+
+#define S3C2410_TCON_T2RELOAD	  (1<<15)
+#define S3C2410_TCON_T2MANUALUPD  (1<<13)
+#define S3C2410_TCON_T2START	  (1<<12)
+
+#define S3C2410_TCON_T1RELOAD	  (1<<11)
+#define S3C2410_TCON_T1MANUALUPD  (1<<9)
+#define S3C2410_TCON_T1START	  (1<<8)
+
+#define S3C2410_TCON_T0RELOAD	  (1<<3)
+#define S3C2410_TCON_T0MANUALUPD  (1<<1)
+#define S3C2410_TCON_T0START	  (1<<0)
+
 static struct clk *tin_event;
 static struct clk *tin_source;
 static struct clk *tdiv_event;
-- 
1.8.1.5



From t.figa at samsung.com  Thu Apr  4 12:37:01 2013
From: t.figa at samsung.com (Tomasz Figa)
Date: Thu, 04 Apr 2013 18:37:01 +0200
Subject: [PATCH v4 04/14] mfd: Add Samsung PWM/timer master driver
In-Reply-To: <1365093431-30621-1-git-send-email-t.figa@samsung.com>
References: <1365093431-30621-1-git-send-email-t.figa@samsung.com>
Message-ID: <1365093431-30621-5-git-send-email-t.figa@samsung.com>

This patch adds master driver for PWM/timer block available on many
Samsung SoCs providing clocksource and PWM output capabilities.

Signed-off-by: Tomasz Figa <t.figa at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
---
 .../devicetree/bindings/pwm/pwm-samsung.txt        |  37 ++
 drivers/clocksource/Kconfig                        |   1 +
 drivers/mfd/Kconfig                                |   3 +
 drivers/mfd/Makefile                               |   1 +
 drivers/mfd/samsung-pwm.c                          | 439 +++++++++++++++++++++
 drivers/pwm/Kconfig                                |   1 +
 include/linux/mfd/samsung-pwm.h                    |  49 +++
 include/linux/platform_data/samsung-pwm.h          |  28 ++
 8 files changed, 559 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pwm/pwm-samsung.txt
 create mode 100644 drivers/mfd/samsung-pwm.c
 create mode 100644 include/linux/mfd/samsung-pwm.h
 create mode 100644 include/linux/platform_data/samsung-pwm.h

diff --git a/Documentation/devicetree/bindings/pwm/pwm-samsung.txt b/Documentation/devicetree/bindings/pwm/pwm-samsung.txt
new file mode 100644
index 0000000..8ed4c11
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/pwm-samsung.txt
@@ -0,0 +1,37 @@
+* Samsung PWM timers
+
+Samsung SoCs contain PWM timer blocks which can be used for system clock source
+and clock event timers, as well as to drive SoC outputs with PWM signal. Each
+PWM timer block provides 5 PWM channels (not all of them can drive physical
+outputs - see SoC and board manual).
+
+Be aware that this driver supports clock event only on CPU 0. It can
+provide SMP support together with ARM dummy_timer, but only in periodic tick
+mode.
+
+Required properties:
+- compatible : should be one of following:
+    samsung,s3c2410-pwm - for 16-bit timers present on S3C24xx SoCs
+    samsung,s3c6400-pwm - for 32-bit timers present on S3C64xx SoCs
+    samsung,s5p6440-pwm - for 32-bit timers present on S5P64x0 SoCs
+    samsung,s5pc100-pwm - for 32-bit timers present on S5PC100, S5PV210,
+			  Exynos4210, Exynos4x12 and Exynos5250 SoCs
+- reg: base address and size of register area
+- interrupts: list of timer interrupts (one interrupt per timer, starting at
+  timer 0)
+- #pwm-cells: number of cells used for PWM specifier - must be 2
+
+Optional properties:
+- samsung,pwm-outputs: list of PWM channels used as PWM outputs on particular
+    platform - an array of up to 5 elements being indices of PWM channels
+    (from 0 to 4), the order does not matter.
+
+Example:
+	pwm at 7f006000 {
+		compatible = "samsung,s3c6400-pwm";
+		reg = <0x7f006000 0x1000>;
+		interrupt-parent = <&vic0>;
+		interrupts = <23>, <24>, <25>, <27>, <28>;
+		samsung,pwm-outputs = <0>, <1>;
+		#pwm-cells = <2>;
+	}
diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index dd20f6a..a69a5b7 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -29,6 +29,7 @@ config SAMSUNG_HRT
 	bool
 	depends on PLAT_SAMSUNG
 	select SAMSUNG_DEV_PWM
+	select MFD_SAMSUNG_PWM
 	help
 	  Use the high resolution timer support on Samsung platforms.
 
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 3ab3a11..c25425c 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -1015,6 +1015,9 @@ config MFD_PM8XXX_IRQ
 	  This is required to use certain other PM 8xxx features, such as GPIO
 	  and MPP.
 
+config MFD_SAMSUNG_PWM
+	bool
+
 config TPS65911_COMPARATOR
 	tristate
 
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index b90409c..513d9c9 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -145,6 +145,7 @@ obj-$(CONFIG_MFD_RC5T583)	+= rc5t583.o rc5t583-irq.o
 obj-$(CONFIG_MFD_SEC_CORE)	+= sec-core.o sec-irq.o
 obj-$(CONFIG_MFD_SYSCON)	+= syscon.o
 obj-$(CONFIG_MFD_LM3533)	+= lm3533-core.o lm3533-ctrlbank.o
+obj-$(CONFIG_MFD_SAMSUNG_PWM)	+= samsung-pwm.o
 obj-$(CONFIG_VEXPRESS_CONFIG)	+= vexpress-config.o vexpress-sysreg.o
 obj-$(CONFIG_MFD_RETU)		+= retu-mfd.o
 obj-$(CONFIG_MFD_AS3711)	+= as3711.o
diff --git a/drivers/mfd/samsung-pwm.c b/drivers/mfd/samsung-pwm.c
new file mode 100644
index 0000000..ece426e
--- /dev/null
+++ b/drivers/mfd/samsung-pwm.c
@@ -0,0 +1,439 @@
+/*
+ * Samsung PWM/timers MFD driver
+ *
+ * Copyright (C) 2013 Samsung Electronics Co., Ltd.
+ *
+ * Author: Tomasz Figa <t.figa at samsung.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/err.h>
+#include <linux/io.h>
+#include <linux/list.h>
+#include <linux/mfd/samsung-pwm.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+#include <linux/of_platform.h>
+#include <linux/platform_data/samsung-pwm.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+#include <linux/spinlock.h>
+
+#define REG_TCFG0			0x00
+#define REG_TCFG1			0x04
+#define REG_TCON			0x08
+
+#define REG_TCNTB(chan)			(0x0c + 12 * (chan))
+#define REG_TCMPB(chan)			(0x10 + 12 * (chan))
+
+#define TCON_START(chan)		(1 << (4 * (chan) + 0))
+#define TCON_MANUALUPDATE(chan)		(1 << (4 * (chan) + 1))
+#define TCON_INVERT(chan)		(1 << (4 * (chan) + 2))
+#define TCON_AUTORELOAD(chan)		(1 << (4 * (chan) + 3))
+
+#define TCFG0_PRESCALER_MASK		0xff
+#define TCFG0_PRESCALER1_SHIFT		8
+
+#define TCFG1_SHIFT(x)	  		((x) * 4)
+#define TCFG1_MUX_MASK	  		0xf
+
+struct samsung_pwm_drvdata {
+	struct samsung_pwm pwm;
+	struct platform_device *pdev;
+	struct resource resource;
+	struct list_head list;
+	spinlock_t slock;
+	unsigned long request_mask;
+};
+
+static LIST_HEAD(pwm_list);
+
+static inline struct samsung_pwm_drvdata *to_drvdata(struct samsung_pwm *pwm)
+{
+	return container_of(pwm, struct samsung_pwm_drvdata, pwm);
+}
+
+void samsung_pwm_start(struct samsung_pwm *pwm,
+					unsigned int channel, bool periodic)
+{
+	struct samsung_pwm_drvdata *drvdata = to_drvdata(pwm);
+	unsigned long flags;
+	u32 reg;
+
+	if (channel > 0)
+		++channel;
+
+	spin_lock_irqsave(&drvdata->slock, flags);
+
+	reg = readl(pwm->base + REG_TCON);
+	reg &= ~TCON_MANUALUPDATE(channel);
+	reg |= TCON_START(channel);
+	if (periodic)
+		reg |= TCON_AUTORELOAD(channel);
+	else
+		reg &= ~TCON_AUTORELOAD(channel);
+	writel(reg, pwm->base + REG_TCON);
+
+	spin_unlock_irqrestore(&drvdata->slock, flags);
+}
+EXPORT_SYMBOL(samsung_pwm_start);
+
+void samsung_pwm_stop(struct samsung_pwm *pwm, unsigned int channel)
+{
+	struct samsung_pwm_drvdata *drvdata = to_drvdata(pwm);
+	unsigned long flags;
+	u32 reg;
+
+	if (channel > 0)
+		++channel;
+
+	spin_lock_irqsave(&drvdata->slock, flags);
+
+	reg = readl(pwm->base + REG_TCON);
+	reg &= ~TCON_START(channel);
+	writel(reg, pwm->base + REG_TCON);
+
+	spin_unlock_irqrestore(&drvdata->slock, flags);
+}
+EXPORT_SYMBOL(samsung_pwm_stop);
+
+void samsung_pwm_setup(struct samsung_pwm *pwm, unsigned int channel,
+							u32 tcmp, u32 tcnt)
+{
+	struct samsung_pwm_drvdata *drvdata = to_drvdata(pwm);
+	unsigned long flags;
+	u32 reg;
+
+	writel(tcnt, pwm->base + REG_TCNTB(channel));
+	writel(tcmp, pwm->base + REG_TCMPB(channel));
+
+	if (channel > 0)
+		++channel;
+
+	spin_lock_irqsave(&drvdata->slock, flags);
+
+	reg = readl(pwm->base + REG_TCON);
+	reg &= ~TCON_START(channel);
+	reg |= TCON_MANUALUPDATE(channel);
+	writel(reg, pwm->base + REG_TCON);
+
+	spin_unlock_irqrestore(&drvdata->slock, flags);
+}
+EXPORT_SYMBOL(samsung_pwm_setup);
+
+void samsung_pwm_set_flags(struct samsung_pwm *pwm,
+					unsigned int channel, u32 pwm_flags)
+{
+	struct samsung_pwm_drvdata *drvdata = to_drvdata(pwm);
+	unsigned long flags;
+	u32 reg;
+
+	if (channel > 0)
+		++channel;
+
+	spin_lock_irqsave(&drvdata->slock, flags);
+
+	reg = readl(pwm->base + REG_TCON);
+
+	if (pwm_flags & SAMSUNG_PWM_INVERT)
+		reg |= TCON_INVERT(channel);
+	else
+		reg &= ~TCON_INVERT(channel);
+
+	writel(reg, pwm->base + REG_TCON);
+
+	spin_unlock_irqrestore(&drvdata->slock, flags);
+}
+EXPORT_SYMBOL(samsung_pwm_set_flags);
+
+void samsung_pwm_set_prescale(struct samsung_pwm *pwm,
+					unsigned int channel, u16 prescale)
+{
+	struct samsung_pwm_drvdata *drvdata = to_drvdata(pwm);
+	unsigned long flags;
+	u8 shift = 0;
+	u32 reg;
+
+	if (channel >= 2)
+		shift = TCFG0_PRESCALER1_SHIFT;
+
+	spin_lock_irqsave(&drvdata->slock, flags);
+
+	reg = readl(pwm->base + REG_TCFG0);
+	reg &= ~(TCFG0_PRESCALER_MASK << shift);
+	reg |= (prescale - 1) << shift;
+	writel(reg, pwm->base + REG_TCFG0);
+
+	spin_unlock_irqrestore(&drvdata->slock, flags);
+}
+EXPORT_SYMBOL(samsung_pwm_set_prescale);
+
+void samsung_pwm_set_divisor(struct samsung_pwm *pwm,
+					unsigned int channel, u8 divisor)
+{
+	struct samsung_pwm_drvdata *drvdata = to_drvdata(pwm);
+	u8 shift = TCFG1_SHIFT(channel);
+	unsigned long flags;
+	u32 reg;
+	u8 bits;
+
+	bits = (fls(divisor) - 1) - pwm->variant.div_base;
+
+	spin_lock_irqsave(&drvdata->slock, flags);
+
+	reg = readl(pwm->base + REG_TCFG1);
+	reg &= ~(TCFG1_MUX_MASK << shift);
+	reg |= bits << shift;
+	writel(reg, pwm->base + REG_TCFG1);
+
+	spin_unlock_irqrestore(&drvdata->slock, flags);
+}
+EXPORT_SYMBOL(samsung_pwm_set_divisor);
+
+int samsung_pwm_request(struct samsung_pwm *pwm, unsigned int channel)
+{
+	struct samsung_pwm_drvdata *drvdata = to_drvdata(pwm);
+
+	if (test_and_set_bit(channel, &drvdata->request_mask))
+		return -EBUSY;
+
+	return 0;
+}
+EXPORT_SYMBOL(samsung_pwm_request);
+
+void samsung_pwm_free(struct samsung_pwm *pwm, unsigned int channel)
+{
+	struct samsung_pwm_drvdata *drvdata = to_drvdata(pwm);
+
+	clear_bit(channel, &drvdata->request_mask);
+}
+EXPORT_SYMBOL(samsung_pwm_free);
+
+#ifdef CONFIG_OF
+static int samsung_pwm_parse_dt(struct samsung_pwm *pwm)
+{
+	struct samsung_pwm_variant *variant = &pwm->variant;
+	struct device_node *np = pwm->of_node;
+	struct property *prop;
+	const __be32 *cur;
+	u32 val;
+	int i;
+
+	for (i = 0; i < SAMSUNG_PWM_NUM; ++i)
+		pwm->irq[i] = irq_of_parse_and_map(np, i);
+
+	of_property_for_each_u32(np, "samsung,pwm-outputs", prop, cur, val) {
+		if (val >= SAMSUNG_PWM_NUM) {
+			pr_warning("%s: invalid channel index in samsung,pwm-outputs property\n",
+								__func__);
+			continue;
+		}
+		variant->output_mask |= 1 << val;
+	}
+
+	return 0;
+}
+
+static const struct samsung_pwm_variant s3c24xx_variant = {
+	.bits		= 16,
+	.div_base	= 1,
+	.has_tint_cstat	= false,
+	.tclk_mask	= (1 << 4),
+};
+
+static const struct samsung_pwm_variant s3c64xx_variant = {
+	.bits		= 32,
+	.div_base	= 0,
+	.has_tint_cstat	= true,
+	.tclk_mask	= (1 << 7) | (1 << 6) | (1 << 5),
+};
+
+static const struct samsung_pwm_variant s5p64x0_variant = {
+	.bits		= 32,
+	.div_base	= 0,
+	.has_tint_cstat	= true,
+	.tclk_mask	= 0,
+};
+
+static const struct samsung_pwm_variant s5p_variant = {
+	.bits		= 32,
+	.div_base	= 0,
+	.has_tint_cstat	= true,
+	.tclk_mask	= (1 << 5),
+};
+
+static const struct of_device_id samsung_pwm_matches[] = {
+	{ .compatible = "samsung,s3c2410-pwm", .data = &s3c24xx_variant, },
+	{ .compatible = "samsung,s3c6400-pwm", .data = &s3c64xx_variant, },
+	{ .compatible = "samsung,s5p6440-pwm", .data = &s5p64x0_variant, },
+	{ .compatible = "samsung,s5pc100-pwm", .data = &s5p_variant, },
+	{},
+};
+
+static struct samsung_pwm_drvdata *samsung_pwm_of_add(struct device_node *np)
+{
+	const struct samsung_pwm_variant *variant;
+	const struct of_device_id *match;
+	struct samsung_pwm_drvdata *pwm;
+	int ret;
+
+	if (!np) {
+		np = of_find_matching_node(NULL, samsung_pwm_matches);
+		if (!np) {
+			pr_err("%s: could not find PWM device\n", __func__);
+			return ERR_PTR(-ENODEV);
+		}
+	}
+
+	match = of_match_node(samsung_pwm_matches, np);
+	if (!match) {
+		pr_err("%s: failed to match given OF node\n", __func__);
+		return ERR_PTR(-EINVAL);
+	}
+	variant = match->data;
+
+	pwm = kzalloc(sizeof(*pwm), GFP_KERNEL);
+	if (!pwm) {
+		pr_err("%s: could not allocate PWM device struct\n", __func__);
+		return ERR_PTR(-ENOMEM);
+	}
+
+	pwm->pwm.variant = *variant;
+	pwm->pwm.of_node = np;
+	spin_lock_init(&pwm->slock);
+
+	ret = of_address_to_resource(np, 0, &pwm->resource);
+	if (ret < 0) {
+		pr_err("%s: could not get IO resource\n", __func__);
+		goto err_free;
+	}
+
+	ret = samsung_pwm_parse_dt(&pwm->pwm);
+	if (ret < 0) {
+		pr_err("%s: failed to parse device tree node\n", __func__);
+		goto err_free;
+	}
+
+	list_add_tail(&pwm->list, &pwm_list);
+
+	return pwm;
+
+err_free:
+	kfree(pwm);
+
+	return ERR_PTR(ret);
+}
+#else
+static struct samsung_pwm_drvdata *samsung_pwm_of_add(struct device_node *np)
+{
+	return ERR_PTR(-ENODEV);
+}
+#endif
+
+static struct samsung_pwm_drvdata *samsung_pwm_add(struct platform_device *pdev)
+{
+	struct samsung_pwm_variant *variant = pdev->dev.platform_data;
+	struct samsung_pwm_drvdata *pwm;
+	struct resource *res;
+	int i;
+
+	if (!variant) {
+		pr_err("%s: no platform data specified\n", __func__);
+		return ERR_PTR(-EINVAL);
+	}
+
+	pwm = kzalloc(sizeof(*pwm), GFP_KERNEL);
+	if (!pwm) {
+		pr_err("%s: could not allocate PWM device struct\n", __func__);
+		return ERR_PTR(-ENOMEM);
+	}
+
+	pwm->pwm.variant = *variant;
+	pwm->pdev = pdev;
+	spin_lock_init(&pwm->slock);
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	if (!res) {
+		pr_err("%s: could not get IO resource\n", __func__);
+		kfree(pwm);
+		return ERR_PTR(-EINVAL);
+	}
+	pwm->resource = *res;
+
+	for (i = 0; i < SAMSUNG_PWM_NUM; ++i)
+		pwm->pwm.irq[i] = platform_get_irq(pdev, i);
+
+	list_add_tail(&pwm->list, &pwm_list);
+
+	return pwm;
+}
+
+static struct samsung_pwm_drvdata *samsung_pwm_find(struct platform_device *pdev)
+{
+	struct samsung_pwm_drvdata *pwm;
+	struct device_node *np = NULL;
+
+	list_for_each_entry(pwm, &pwm_list, list) {
+		if (!pdev || pwm->pdev == pdev)
+			return pwm;
+		if (pdev->dev.of_node && pdev->dev.of_node == pwm->pwm.of_node)
+			return pwm;
+	}
+
+	if (pdev) {
+		np = pdev->dev.of_node;
+		if (!np)
+			return samsung_pwm_add(pdev);
+	}
+
+	return samsung_pwm_of_add(np);
+}
+
+struct samsung_pwm *samsung_pwm_get(struct platform_device *pdev)
+{
+	struct samsung_pwm_drvdata *pwm;
+	struct resource *res;
+
+	pwm = samsung_pwm_find(pdev);
+	if (IS_ERR(pwm)) {
+		pr_err("%s: failed to instantiate PWM device\n", __func__);
+		return &pwm->pwm;
+	}
+
+	if (pwm->pwm.base)
+		return &pwm->pwm;
+
+	res = request_mem_region(pwm->resource.start,
+				resource_size(&pwm->resource), "samsung-pwm");
+	if (!res) {
+		pr_err("%s: failed to request IO mem region\n", __func__);
+		return ERR_PTR(-ENOMEM);
+	}
+
+	pwm->pwm.base = ioremap(res->start, resource_size(res));
+	if (!pwm->pwm.base) {
+		pr_err("%s: failed to map PWM registers\n", __func__);
+		release_mem_region(res->start, resource_size(res));
+		return ERR_PTR(-ENOMEM);
+	}
+
+	return &pwm->pwm;
+}
+EXPORT_SYMBOL(samsung_pwm_get);
+
+int samsung_pwm_register(struct platform_device *pdev)
+{
+	struct samsung_pwm_drvdata *pwm;
+
+	pwm = samsung_pwm_add(pdev);
+	if (IS_ERR(pwm))
+		return PTR_ERR(pwm);
+
+	return 0;
+}
+EXPORT_SYMBOL(samsung_pwm_register);
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 0e0bfa0..c80070b 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -118,6 +118,7 @@ config PWM_PXA
 config PWM_SAMSUNG
 	tristate "Samsung PWM support"
 	depends on PLAT_SAMSUNG
+	select MFD_SAMSUNG_PWM
 	help
 	  Generic PWM framework driver for Samsung.
 
diff --git a/include/linux/mfd/samsung-pwm.h b/include/linux/mfd/samsung-pwm.h
new file mode 100644
index 0000000..e54456e
--- /dev/null
+++ b/include/linux/mfd/samsung-pwm.h
@@ -0,0 +1,49 @@
+/*
+ * Samsung PWM/timers MFD driver
+ *
+ * Copyright (C) 2013 Samsung Electronics Co., Ltd.
+ *
+ * Author: Tomasz Figa <t.figa at samsung.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.
+ */
+
+#ifndef MFD_SAMSUNG_PWM_H_
+#define MFD_SAMSUNG_PWM_H_
+
+#include <linux/platform_data/samsung-pwm.h>
+
+#define SAMSUNG_PWM_NUM		5
+
+#define SAMSUNG_PWM_INVERT	(1 << 0)
+
+struct platform_device;
+
+struct samsung_pwm {
+	struct samsung_pwm_variant variant;
+	struct device_node *of_node;
+	void __iomem *base;
+	int irq[SAMSUNG_PWM_NUM];
+};
+
+extern void samsung_pwm_start(struct samsung_pwm *pwm,
+					unsigned int channel, bool periodic);
+extern void samsung_pwm_stop(struct samsung_pwm *pwm, unsigned int channel);
+extern void samsung_pwm_setup(struct samsung_pwm *pwm, unsigned int channel,
+							u32 tcmp, u32 tcnt);
+
+extern void samsung_pwm_set_flags(struct samsung_pwm *pwm,
+					unsigned int channel, u32 flags);
+extern void samsung_pwm_set_prescale(struct samsung_pwm *pwm,
+					unsigned int channel, u16 prescale);
+extern void samsung_pwm_set_divisor(struct samsung_pwm *pwm,
+					unsigned int channel, u8 divisor);
+
+extern int samsung_pwm_request(struct samsung_pwm *pwm, unsigned int channel);
+extern void samsung_pwm_free(struct samsung_pwm *pwm, unsigned int channel);
+
+extern struct samsung_pwm *samsung_pwm_get(struct platform_device *pdev);
+
+#endif
diff --git a/include/linux/platform_data/samsung-pwm.h b/include/linux/platform_data/samsung-pwm.h
new file mode 100644
index 0000000..8c48dbb
--- /dev/null
+++ b/include/linux/platform_data/samsung-pwm.h
@@ -0,0 +1,28 @@
+/*
+ * Samsung PWM/timers driver
+ *
+ * Copyright (C) 2013 Samsung Electronics Co., Ltd.
+ *
+ * Author: Tomasz Figa <t.figa at samsung.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.
+ */
+
+#ifndef PLATFORM_DATA_SAMSUNG_PWM_H_
+#define PLATFORM_DATA_SAMSUNG_PWM_H_
+
+struct platform_device;
+
+struct samsung_pwm_variant {
+	u8 bits;
+	u8 div_base;
+	u8 tclk_mask;
+	u8 output_mask;
+	bool has_tint_cstat;
+};
+
+extern int samsung_pwm_register(struct platform_device *pdev);
+
+#endif
-- 
1.8.1.5



From t.figa at samsung.com  Thu Apr  4 12:37:02 2013
From: t.figa at samsung.com (Tomasz Figa)
Date: Thu, 04 Apr 2013 18:37:02 +0200
Subject: [PATCH v4 05/14] ARM: SAMSUNG: Unify base address definitions of timer
 block
In-Reply-To: <1365093431-30621-1-git-send-email-t.figa@samsung.com>
References: <1365093431-30621-1-git-send-email-t.figa@samsung.com>
Message-ID: <1365093431-30621-6-git-send-email-t.figa@samsung.com>

This patch makes all defintions of timer block base address use the same
prefix to allow using the common name to define platform device
resource.

Signed-off-by: Tomasz Figa <t.figa at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
---
 arch/arm/mach-exynos/include/mach/map.h  | 1 +
 arch/arm/mach-s3c24xx/include/mach/map.h | 2 ++
 arch/arm/mach-s3c64xx/include/mach/map.h | 1 +
 arch/arm/mach-s5p64x0/include/mach/map.h | 1 +
 arch/arm/mach-s5pc100/include/mach/map.h | 1 +
 arch/arm/mach-s5pv210/include/mach/map.h | 1 +
 6 files changed, 7 insertions(+)

diff --git a/arch/arm/mach-exynos/include/mach/map.h b/arch/arm/mach-exynos/include/mach/map.h
index 99e0a79..7167aba 100644
--- a/arch/arm/mach-exynos/include/mach/map.h
+++ b/arch/arm/mach-exynos/include/mach/map.h
@@ -272,6 +272,7 @@
 #define SAMSUNG_PA_ADC			EXYNOS4_PA_ADC
 #define SAMSUNG_PA_ADC1			EXYNOS4_PA_ADC1
 #define SAMSUNG_PA_KEYPAD		EXYNOS4_PA_KEYPAD
+#define SAMSUNG_PA_TIMER		EXYNOS4_PA_TIMER
 
 /* Compatibility UART */
 
diff --git a/arch/arm/mach-s3c24xx/include/mach/map.h b/arch/arm/mach-s3c24xx/include/mach/map.h
index 8ba381f..444793f 100644
--- a/arch/arm/mach-s3c24xx/include/mach/map.h
+++ b/arch/arm/mach-s3c24xx/include/mach/map.h
@@ -167,4 +167,6 @@
 #define S3C_PA_SPI0		S3C2443_PA_SPI0
 #define S3C_PA_SPI1		S3C2443_PA_SPI1
 
+#define SAMSUNG_PA_TIMER	S3C2410_PA_TIMER
+
 #endif /* __ASM_ARCH_MAP_H */
diff --git a/arch/arm/mach-s3c64xx/include/mach/map.h b/arch/arm/mach-s3c64xx/include/mach/map.h
index 8e2097b..f55ccb1 100644
--- a/arch/arm/mach-s3c64xx/include/mach/map.h
+++ b/arch/arm/mach-s3c64xx/include/mach/map.h
@@ -121,5 +121,6 @@
 #define SAMSUNG_PA_ADC		S3C64XX_PA_ADC
 #define SAMSUNG_PA_CFCON	S3C64XX_PA_CFCON
 #define SAMSUNG_PA_KEYPAD	S3C64XX_PA_KEYPAD
+#define SAMSUNG_PA_TIMER	S3C64XX_PA_TIMER
 
 #endif /* __ASM_ARCH_6400_MAP_H */
diff --git a/arch/arm/mach-s5p64x0/include/mach/map.h b/arch/arm/mach-s5p64x0/include/mach/map.h
index 0c0175d..50a6e96 100644
--- a/arch/arm/mach-s5p64x0/include/mach/map.h
+++ b/arch/arm/mach-s5p64x0/include/mach/map.h
@@ -76,6 +76,7 @@
 #define S5P_PA_TIMER		S5P64X0_PA_TIMER
 
 #define SAMSUNG_PA_ADC		S5P64X0_PA_ADC
+#define SAMSUNG_PA_TIMER	S5P64X0_PA_TIMER
 
 /* UART */
 
diff --git a/arch/arm/mach-s5pc100/include/mach/map.h b/arch/arm/mach-s5pc100/include/mach/map.h
index 54bc4f8..2550b61 100644
--- a/arch/arm/mach-s5pc100/include/mach/map.h
+++ b/arch/arm/mach-s5pc100/include/mach/map.h
@@ -116,6 +116,7 @@
 #define SAMSUNG_PA_ADC			S5PC100_PA_TSADC
 #define SAMSUNG_PA_CFCON		S5PC100_PA_CFCON
 #define SAMSUNG_PA_KEYPAD		S5PC100_PA_KEYPAD
+#define SAMSUNG_PA_TIMER		S5PC100_PA_TIMER
 
 #define S5PC100_VA_OTHERS		(S3C_VA_SYS + 0x10000)
 
diff --git a/arch/arm/mach-s5pv210/include/mach/map.h b/arch/arm/mach-s5pv210/include/mach/map.h
index b7c8a19..763929a 100644
--- a/arch/arm/mach-s5pv210/include/mach/map.h
+++ b/arch/arm/mach-s5pv210/include/mach/map.h
@@ -139,6 +139,7 @@
 #define SAMSUNG_PA_ADC			S5PV210_PA_ADC
 #define SAMSUNG_PA_CFCON		S5PV210_PA_CFCON
 #define SAMSUNG_PA_KEYPAD		S5PV210_PA_KEYPAD
+#define SAMSUNG_PA_TIMER		S5PV210_PA_TIMER
 
 /* UART */
 
-- 
1.8.1.5



From t.figa at samsung.com  Thu Apr  4 12:37:03 2013
From: t.figa at samsung.com (Tomasz Figa)
Date: Thu, 04 Apr 2013 18:37:03 +0200
Subject: [PATCH v4 06/14] ARM: SAMSUNG: Add new PWM platform device
In-Reply-To: <1365093431-30621-1-git-send-email-t.figa@samsung.com>
References: <1365093431-30621-1-git-send-email-t.figa@samsung.com>
Message-ID: <1365093431-30621-7-git-send-email-t.figa@samsung.com>

This patch adds new samsung_device_pwm platform device that represents
the whole PWM/timer block and includes memory and IRQ resources.

Signed-off-by: Tomasz Figa <t.figa at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
---
 arch/arm/plat-samsung/devs.c              | 16 ++++++++++++++++
 arch/arm/plat-samsung/include/plat/devs.h |  1 +
 2 files changed, 17 insertions(+)

diff --git a/arch/arm/plat-samsung/devs.c b/arch/arm/plat-samsung/devs.c
index e1124d9..bfae4dd 100644
--- a/arch/arm/plat-samsung/devs.c
+++ b/arch/arm/plat-samsung/devs.c
@@ -1168,6 +1168,22 @@ struct platform_device s3c_device_timer[] = {
 };
 #endif /* CONFIG_SAMSUNG_DEV_PWM */
 
+static struct resource samsung_pwm_resource[] = {
+	DEFINE_RES_IRQ(IRQ_TIMER0),
+	DEFINE_RES_IRQ(IRQ_TIMER1),
+	DEFINE_RES_IRQ(IRQ_TIMER2),
+	DEFINE_RES_IRQ(IRQ_TIMER3),
+	DEFINE_RES_IRQ(IRQ_TIMER4),
+	DEFINE_RES_MEM(SAMSUNG_PA_TIMER, SZ_4K),
+};
+
+struct platform_device samsung_device_pwm = {
+	.name		= "samsung-pwm",
+	.id		= -1,
+	.num_resources	= ARRAY_SIZE(samsung_pwm_resource),
+	.resource	= samsung_pwm_resource,
+};
+
 /* RTC */
 
 #ifdef CONFIG_PLAT_S3C24XX
diff --git a/arch/arm/plat-samsung/include/plat/devs.h b/arch/arm/plat-samsung/include/plat/devs.h
index 87d501f..0dc4ac4 100644
--- a/arch/arm/plat-samsung/include/plat/devs.h
+++ b/arch/arm/plat-samsung/include/plat/devs.h
@@ -134,6 +134,7 @@ extern struct platform_device exynos4_device_spdif;
 
 extern struct platform_device samsung_asoc_idma;
 extern struct platform_device samsung_device_keypad;
+extern struct platform_device samsung_device_pwm;
 
 /* s3c2440 specific devices */
 
-- 
1.8.1.5



From t.figa at samsung.com  Thu Apr  4 12:37:04 2013
From: t.figa at samsung.com (Tomasz Figa)
Date: Thu, 04 Apr 2013 18:37:04 +0200
Subject: [PATCH v4 07/14] ARM: SAMSUNG: Set PWM platform data
In-Reply-To: <1365093431-30621-1-git-send-email-t.figa@samsung.com>
References: <1365093431-30621-1-git-send-email-t.figa@samsung.com>
Message-ID: <1365093431-30621-8-git-send-email-t.figa@samsung.com>

This patch adds PWM platform data needed for legacy (non-DT) platforms
to handle SoC-specific bits of the PWM/timer block.

Signed-off-by: Tomasz Figa <t.figa at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
---
 arch/arm/mach-exynos/common.c  | 10 ++++++++++
 arch/arm/mach-s3c24xx/common.c | 10 ++++++++++
 arch/arm/mach-s3c64xx/common.c | 10 ++++++++++
 arch/arm/mach-s5p64x0/common.c | 10 ++++++++++
 arch/arm/mach-s5pc100/common.c | 10 ++++++++++
 arch/arm/mach-s5pv210/common.c | 10 ++++++++++
 6 files changed, 60 insertions(+)

diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
index 9cd857e..2b1ef98 100644
--- a/arch/arm/mach-exynos/common.c
+++ b/arch/arm/mach-exynos/common.c
@@ -16,6 +16,7 @@
 #include <linux/io.h>
 #include <linux/device.h>
 #include <linux/gpio.h>
+#include <linux/platform_data/samsung-pwm.h>
 #include <linux/sched.h>
 #include <linux/serial_core.h>
 #include <linux/of.h>
@@ -378,6 +379,13 @@ void __init exynos_init_io(struct map_desc *mach_desc, int size)
 	s3c_init_cpu(samsung_cpu_id, cpu_ids, ARRAY_SIZE(cpu_ids));
 }
 
+static struct samsung_pwm_variant exynos4_pwm_variant = {
+	.bits		= 32,
+	.div_base	= 0,
+	.has_tint_cstat	= true,
+	.tclk_mask	= (1 << 5),
+};
+
 static void __init exynos4_map_io(void)
 {
 	iotable_init(exynos4_iodesc, ARRAY_SIZE(exynos4_iodesc));
@@ -419,6 +427,8 @@ static void __init exynos4_map_io(void)
 	s5p_hdmi_setname("exynos4-hdmi");
 
 	s3c64xx_spi_setname("exynos4210-spi");
+
+	samsung_device_pwm.dev.platform_data = &exynos4_pwm_variant;
 }
 
 static void __init exynos5_map_io(void)
diff --git a/arch/arm/mach-s3c24xx/common.c b/arch/arm/mach-s3c24xx/common.c
index d97533d..c09c6ba 100644
--- a/arch/arm/mach-s3c24xx/common.c
+++ b/arch/arm/mach-s3c24xx/common.c
@@ -27,6 +27,7 @@
 #include <linux/interrupt.h>
 #include <linux/ioport.h>
 #include <linux/serial_core.h>
+#include <linux/platform_data/samsung-pwm.h>
 #include <linux/platform_device.h>
 #include <linux/delay.h>
 #include <linux/io.h>
@@ -216,6 +217,13 @@ static void s3c24xx_default_idle(void)
 		     S3C2410_CLKCON);
 }
 
+static struct samsung_pwm_variant s3c24xx_pwm_variant = {
+	.bits		= 16,
+	.div_base	= 1,
+	.has_tint_cstat	= false,
+	.tclk_mask	= (1 << 4),
+};
+
 void __init s3c24xx_init_io(struct map_desc *mach_desc, int size)
 {
 	arm_pm_idle = s3c24xx_default_idle;
@@ -232,6 +240,8 @@ void __init s3c24xx_init_io(struct map_desc *mach_desc, int size)
 	s3c24xx_init_cpu();
 
 	s3c_init_cpu(samsung_cpu_id, cpu_ids, ARRAY_SIZE(cpu_ids));
+
+	samsung_device_pwm.dev.platform_data = &s3c24xx_pwm_variant;
 }
 
 /* Serial port registrations */
diff --git a/arch/arm/mach-s3c64xx/common.c b/arch/arm/mach-s3c64xx/common.c
index 0b9c0ba..526b45e 100644
--- a/arch/arm/mach-s3c64xx/common.c
+++ b/arch/arm/mach-s3c64xx/common.c
@@ -26,6 +26,7 @@
 #include <linux/irq.h>
 #include <linux/gpio.h>
 #include <linux/irqchip/arm-vic.h>
+#include <linux/platform_data/samsung-pwm.h>
 
 #include <asm/mach/arch.h>
 #include <asm/mach/map.h>
@@ -148,6 +149,13 @@ static struct device s3c64xx_dev = {
 	.bus	= &s3c64xx_subsys,
 };
 
+static struct samsung_pwm_variant s3c64xx_pwm_variant = {
+	.bits		= 32,
+	.div_base	= 0,
+	.has_tint_cstat	= true,
+	.tclk_mask	= (1 << 7) | (1 << 6) | (1 << 5),
+};
+
 /* read cpu identification code */
 
 void __init s3c64xx_init_io(struct map_desc *mach_desc, int size)
@@ -160,6 +168,8 @@ void __init s3c64xx_init_io(struct map_desc *mach_desc, int size)
 	s3c64xx_init_cpu();
 
 	s3c_init_cpu(samsung_cpu_id, cpu_ids, ARRAY_SIZE(cpu_ids));
+
+	samsung_device_pwm.dev.platform_data = &s3c64xx_pwm_variant;
 }
 
 static __init int s3c64xx_dev_init(void)
diff --git a/arch/arm/mach-s5p64x0/common.c b/arch/arm/mach-s5p64x0/common.c
index 8ae5800..5cd3048 100644
--- a/arch/arm/mach-s5p64x0/common.c
+++ b/arch/arm/mach-s5p64x0/common.c
@@ -19,6 +19,7 @@
 #include <linux/io.h>
 #include <linux/device.h>
 #include <linux/serial_core.h>
+#include <linux/platform_data/samsung-pwm.h>
 #include <linux/platform_device.h>
 #include <linux/sched.h>
 #include <linux/dma-mapping.h>
@@ -156,6 +157,13 @@ static void s5p64x0_idle(void)
 	cpu_do_idle();
 }
 
+static struct samsung_pwm_variant s5p64x0_pwm_variant = {
+	.bits		= 32,
+	.div_base	= 0,
+	.has_tint_cstat	= true,
+	.tclk_mask	= 0,
+};
+
 /*
  * s5p64x0_map_io
  *
@@ -173,6 +181,8 @@ void __init s5p64x0_init_io(struct map_desc *mach_desc, int size)
 	s5p_init_cpu(S5P64X0_SYS_ID);
 
 	s3c_init_cpu(samsung_cpu_id, cpu_ids, ARRAY_SIZE(cpu_ids));
+
+	samsung_device_pwm.dev.platform_data = &s5p64x0_pwm_variant;
 }
 
 void __init s5p6440_map_io(void)
diff --git a/arch/arm/mach-s5pc100/common.c b/arch/arm/mach-s5pc100/common.c
index cc6e561..d21938e 100644
--- a/arch/arm/mach-s5pc100/common.c
+++ b/arch/arm/mach-s5pc100/common.c
@@ -22,6 +22,7 @@
 #include <linux/io.h>
 #include <linux/device.h>
 #include <linux/serial_core.h>
+#include <linux/platform_data/samsung-pwm.h>
 #include <linux/platform_device.h>
 #include <linux/sched.h>
 
@@ -131,6 +132,13 @@ static struct map_desc s5pc100_iodesc[] __initdata = {
 	}
 };
 
+static struct samsung_pwm_variant s5pc100_pwm_variant = {
+	.bits		= 32,
+	.div_base	= 0,
+	.has_tint_cstat	= true,
+	.tclk_mask	= (1 << 5),
+};
+
 /*
  * s5pc100_map_io
  *
@@ -148,6 +156,8 @@ void __init s5pc100_init_io(struct map_desc *mach_desc, int size)
 	s5p_init_cpu(S5P_VA_CHIPID);
 
 	s3c_init_cpu(samsung_cpu_id, cpu_ids, ARRAY_SIZE(cpu_ids));
+
+	samsung_device_pwm.dev.platform_data = &s5pc100_pwm_variant;
 }
 
 void __init s5pc100_map_io(void)
diff --git a/arch/arm/mach-s5pv210/common.c b/arch/arm/mach-s5pv210/common.c
index 9dfe93e..a3fc208 100644
--- a/arch/arm/mach-s5pv210/common.c
+++ b/arch/arm/mach-s5pv210/common.c
@@ -19,6 +19,7 @@
 #include <linux/clk.h>
 #include <linux/io.h>
 #include <linux/device.h>
+#include <linux/platform_data/samsung-pwm.h>
 #include <linux/platform_device.h>
 #include <linux/sched.h>
 #include <linux/dma-mapping.h>
@@ -148,6 +149,13 @@ void s5pv210_restart(char mode, const char *cmd)
 	__raw_writel(0x1, S5P_SWRESET);
 }
 
+static struct samsung_pwm_variant s5pv210_pwm_variant = {
+	.bits		= 32,
+	.div_base	= 0,
+	.has_tint_cstat	= true,
+	.tclk_mask	= (1 << 5),
+};
+
 /*
  * s5pv210_map_io
  *
@@ -165,6 +173,8 @@ void __init s5pv210_init_io(struct map_desc *mach_desc, int size)
 	s5p_init_cpu(S5P_VA_CHIPID);
 
 	s3c_init_cpu(samsung_cpu_id, cpu_ids, ARRAY_SIZE(cpu_ids));
+
+	samsung_device_pwm.dev.platform_data = &s5pv210_pwm_variant;
 }
 
 void __init s5pv210_map_io(void)
-- 
1.8.1.5



From t.figa at samsung.com  Thu Apr  4 12:37:05 2013
From: t.figa at samsung.com (Tomasz Figa)
Date: Thu, 04 Apr 2013 18:37:05 +0200
Subject: [PATCH v4 08/14] clocksource: samsung-time: Use Samsung PWM/timer
 master driver
In-Reply-To: <1365093431-30621-1-git-send-email-t.figa@samsung.com>
References: <1365093431-30621-1-git-send-email-t.figa@samsung.com>
Message-ID: <1365093431-30621-9-git-send-email-t.figa@samsung.com>

This patch modifies the samsung-time clocksource driver to use the
interface provided by Samsung PWM/timer master driver to get platform
data.

Signed-off-by: Tomasz Figa <t.figa at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
---
 arch/arm/plat-samsung/devs.c                      |  7 ++++
 arch/arm/plat-samsung/include/plat/samsung-time.h | 17 +++++++--
 drivers/clocksource/samsung-time.c                | 44 ++++++++++++++---------
 include/linux/platform_data/samsung-pwm.h         |  1 +
 4 files changed, 51 insertions(+), 18 deletions(-)

diff --git a/arch/arm/plat-samsung/devs.c b/arch/arm/plat-samsung/devs.c
index bfae4dd..747763d 100644
--- a/arch/arm/plat-samsung/devs.c
+++ b/arch/arm/plat-samsung/devs.c
@@ -57,6 +57,7 @@
 #include <plat/keypad.h>
 #include <linux/platform_data/mmc-s3cmci.h>
 #include <linux/platform_data/mtd-nand-s3c2410.h>
+#include <plat/samsung-time.h>
 #include <plat/sdhci.h>
 #include <linux/platform_data/touchscreen-s3c2410.h>
 #include <linux/platform_data/usb-s3c2410_udc.h>
@@ -1184,6 +1185,12 @@ struct platform_device samsung_device_pwm = {
 	.resource	= samsung_pwm_resource,
 };
 
+void samsung_timer_init(void)
+{
+	samsung_pwm_register(&samsung_device_pwm);
+	samsung_time_init();
+}
+
 /* RTC */
 
 #ifdef CONFIG_PLAT_S3C24XX
diff --git a/arch/arm/plat-samsung/include/plat/samsung-time.h b/arch/arm/plat-samsung/include/plat/samsung-time.h
index 5d098ef..c0f35cc 100644
--- a/arch/arm/plat-samsung/include/plat/samsung-time.h
+++ b/arch/arm/plat-samsung/include/plat/samsung-time.h
@@ -13,6 +13,10 @@
 #ifndef __ASM_PLAT_SAMSUNG_TIME_H
 #define __ASM_PLAT_SAMSUNG_TIME_H __FILE__
 
+#include <linux/platform_data/samsung-pwm.h>
+
+#include <plat/devs.h>
+
 /* SAMSUNG HR-Timer Clock mode */
 enum samsung_timer_mode {
 	SAMSUNG_PWM0,
@@ -39,8 +43,17 @@ struct samsung_timer_source {
 #define TSIZE			32
 #endif
 
-extern void __init samsung_set_timer_source(enum samsung_timer_mode event,
-					enum samsung_timer_mode source);
+static inline void samsung_set_timer_source(enum samsung_timer_mode event,
+					enum samsung_timer_mode source)
+{
+	struct samsung_pwm_variant *variant;
+
+	variant = samsung_device_pwm.dev.platform_data;
+	BUG_ON(!variant);
+
+	variant->output_mask = (1 << 5) - 1;
+	variant->output_mask &= ~((1 << event) | (1 << source));
+}
 
 extern void __init samsung_timer_init(void);
 
diff --git a/drivers/clocksource/samsung-time.c b/drivers/clocksource/samsung-time.c
index bccc291..11d7a54 100644
--- a/drivers/clocksource/samsung-time.c
+++ b/drivers/clocksource/samsung-time.c
@@ -14,19 +14,14 @@
 #include <linux/err.h>
 #include <linux/clk.h>
 #include <linux/clockchips.h>
+#include <linux/mfd/samsung-pwm.h>
 #include <linux/platform_device.h>
 
-#include <asm/smp_twd.h>
-#include <asm/mach/time.h>
-#include <asm/mach/arch.h>
-#include <asm/mach/map.h>
 #include <asm/sched_clock.h>
 
-#include <mach/map.h>
 #include <plat/devs.h>
 #include <plat/samsung-time.h>
-
-#define S3C_TIMERREG(x) (S3C_VA_TIMER + (x))
+#define S3C_TIMERREG(x) (pwm->base + (x))
 #define S3C_TIMERREG2(tmr,reg) S3C_TIMERREG((reg)+0x0c+((tmr)*0x0c))
 
 #define S3C2410_TCON	      S3C_TIMERREG(0x08)
@@ -61,6 +56,7 @@
 #define S3C2410_TCON_T0MANUALUPD  (1<<1)
 #define S3C2410_TCON_T0START	  (1<<0)
 
+static struct samsung_pwm *pwm;
 static struct clk *tin_event;
 static struct clk *tin_source;
 static struct clk *tdiv_event;
@@ -256,16 +252,9 @@ static void samsung_timer_resume(void)
 	samsung_time_start(timer_source.source_id, true);
 }
 
-void __init samsung_set_timer_source(enum samsung_timer_mode event,
-				 enum samsung_timer_mode source)
-{
 	s3c_device_timer[event].dev.bus = &platform_bus_type;
 	s3c_device_timer[source].dev.bus = &platform_bus_type;
 
-	timer_source.event_id = event;
-	timer_source.source_id = source;
-}
-
 static struct clock_event_device time_event_device = {
 	.name		= "samsung_event_timer",
 	.features	= CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT,
@@ -311,7 +300,7 @@ static void __init samsung_clockevent_init(void)
 	time_event_device.cpumask = cpumask_of(0);
 	clockevents_config_and_register(&time_event_device, clock_rate, 1, -1);
 
-	irq_number = timer_source.event_id + IRQ_TIMER0;
+	irq_number = pwm->irq[timer_source.event_id];
 	setup_irq(irq_number, &samsung_clock_event_irq);
 }
 
@@ -420,8 +409,31 @@ static void __init samsung_timer_resources(void)
 	clk_enable(tin_source);
 }
 
-void __init samsung_timer_init(void)
+void __init samsung_time_init(void)
 {
+	u8 mask;
+	int channel;
+
+	pwm = samsung_pwm_get(NULL);
+	if (IS_ERR(pwm))
+		panic("failed to get PWM device");
+
+	mask = ~pwm->variant.output_mask & ((1 << SAMSUNG_PWM_NUM) - 1);
+	channel = fls(mask) - 1;
+	if (channel < 0)
+		panic("failed to find PWM channel for clocksource");
+	timer_source.source_id = channel;
+
+	samsung_pwm_request(pwm, channel);
+
+	mask &= ~(1 << channel);
+	channel = fls(mask) - 1;
+	if (channel < 0)
+		panic("failed to find PWM channel for clock event");
+	timer_source.event_id = channel;
+
+	samsung_pwm_request(pwm, channel);
+
 	samsung_timer_resources();
 	samsung_clockevent_init();
 	samsung_clocksource_init();
diff --git a/include/linux/platform_data/samsung-pwm.h b/include/linux/platform_data/samsung-pwm.h
index 8c48dbb..ca6c488 100644
--- a/include/linux/platform_data/samsung-pwm.h
+++ b/include/linux/platform_data/samsung-pwm.h
@@ -24,5 +24,6 @@ struct samsung_pwm_variant {
 };
 
 extern int samsung_pwm_register(struct platform_device *pdev);
+extern void samsung_time_init(void);
 
 #endif
-- 
1.8.1.5



From t.figa at samsung.com  Thu Apr  4 12:37:06 2013
From: t.figa at samsung.com (Tomasz Figa)
Date: Thu, 04 Apr 2013 18:37:06 +0200
Subject: [PATCH v4 09/14] clocksource: samsung-time: Use variant data to get
 SoC-specific bits
In-Reply-To: <1365093431-30621-1-git-send-email-t.figa@samsung.com>
References: <1365093431-30621-1-git-send-email-t.figa@samsung.com>
Message-ID: <1365093431-30621-10-git-send-email-t.figa@samsung.com>

This patch modifies the driver to calculate SoC-specific parameters from
variant data received from PWM/timer master driver.

Signed-off-by: Tomasz Figa <t.figa at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
---
 arch/arm/plat-samsung/include/plat/samsung-time.h | 17 --------
 drivers/clocksource/samsung-time.c                | 51 ++++++++++++++++++-----
 2 files changed, 41 insertions(+), 27 deletions(-)

diff --git a/arch/arm/plat-samsung/include/plat/samsung-time.h b/arch/arm/plat-samsung/include/plat/samsung-time.h
index c0f35cc..785c6b7 100644
--- a/arch/arm/plat-samsung/include/plat/samsung-time.h
+++ b/arch/arm/plat-samsung/include/plat/samsung-time.h
@@ -26,23 +26,6 @@ enum samsung_timer_mode {
 	SAMSUNG_PWM4,
 };
 
-struct samsung_timer_source {
-	unsigned int event_id;
-	unsigned int source_id;
-};
-
-#if defined(CONFIG_ARCH_S3C24XX) || defined(CONFIG_ARCH_S5PC100)
-#define TCNT_MAX		0xffff
-#define TSCALER_DIV		25
-#define TDIV			50
-#define TSIZE			16
-#else
-#define TCNT_MAX		0xffffffff
-#define TSCALER_DIV		2
-#define TDIV			2
-#define TSIZE			32
-#endif
-
 static inline void samsung_set_timer_source(enum samsung_timer_mode event,
 					enum samsung_timer_mode source)
 {
diff --git a/drivers/clocksource/samsung-time.c b/drivers/clocksource/samsung-time.c
index 11d7a54..4fa6f6f 100644
--- a/drivers/clocksource/samsung-time.c
+++ b/drivers/clocksource/samsung-time.c
@@ -20,7 +20,6 @@
 #include <asm/sched_clock.h>
 
 #include <plat/devs.h>
-#include <plat/samsung-time.h>
 #define S3C_TIMERREG(x) (pwm->base + (x))
 #define S3C_TIMERREG2(tmr,reg) S3C_TIMERREG((reg)+0x0c+((tmr)*0x0c))
 
@@ -56,6 +55,22 @@
 #define S3C2410_TCON_T0MANUALUPD  (1<<1)
 #define S3C2410_TCON_T0START	  (1<<0)
 
+enum samsung_timer_mode {
+	SAMSUNG_PWM0,
+	SAMSUNG_PWM1,
+	SAMSUNG_PWM2,
+	SAMSUNG_PWM3,
+	SAMSUNG_PWM4,
+};
+
+struct samsung_timer_source {
+	unsigned int event_id;
+	unsigned int source_id;
+	u32 tcnt_max;
+	u16 tscaler_div;
+	u16 tdiv;
+};
+
 static struct samsung_pwm *pwm;
 static struct clk *tin_event;
 static struct clk *tin_source;
@@ -248,7 +263,7 @@ static void samsung_timer_resume(void)
 	samsung_time_start(timer_source.event_id, true);
 
 	/* source timer restart */
-	samsung_time_setup(timer_source.source_id, TCNT_MAX);
+	samsung_time_setup(timer_source.source_id, timer_source.tcnt_max);
 	samsung_time_start(timer_source.source_id, true);
 }
 
@@ -290,15 +305,17 @@ static void __init samsung_clockevent_init(void)
 
 	tscaler = clk_get_parent(tdiv_event);
 
-	clk_set_rate(tscaler, pclk / TSCALER_DIV);
-	clk_set_rate(tdiv_event, pclk / TDIV);
+	clk_set_rate(tscaler, pclk / timer_source.tscaler_div);
+	clk_set_rate(tdiv_event,
+			pclk / (timer_source.tscaler_div * timer_source.tdiv));
 	clk_set_parent(tin_event, tdiv_event);
 
 	clock_rate = clk_get_rate(tin_event);
 	clock_count_per_tick = clock_rate / HZ;
 
 	time_event_device.cpumask = cpumask_of(0);
-	clockevents_config_and_register(&time_event_device, clock_rate, 1, -1);
+	clockevents_config_and_register(&time_event_device, clock_rate,
+						1, timer_source.tcnt_max);
 
 	irq_number = pwm->irq[timer_source.event_id];
 	setup_irq(irq_number, &samsung_clock_event_irq);
@@ -349,21 +366,26 @@ static void __init samsung_clocksource_init(void)
 {
 	unsigned long pclk;
 	unsigned long clock_rate;
+	int ret;
 
 	pclk = clk_get_rate(timerclk);
 
-	clk_set_rate(tdiv_source, pclk / TDIV);
+	clk_set_rate(tdiv_source,
+			pclk / (timer_source.tscaler_div * timer_source.tdiv));
 	clk_set_parent(tin_source, tdiv_source);
 
 	clock_rate = clk_get_rate(tin_source);
 
-	samsung_time_setup(timer_source.source_id, TCNT_MAX);
+	samsung_time_setup(timer_source.source_id, timer_source.tcnt_max);
 	samsung_time_start(timer_source.source_id, true);
 
-	setup_sched_clock(samsung_read_sched_clock, TSIZE, clock_rate);
+	setup_sched_clock(samsung_read_sched_clock,
+						pwm->variant.bits, clock_rate);
 
-	if (clocksource_mmio_init(samsung_timer_reg(), "samsung_clocksource_timer",
-			clock_rate, 250, TSIZE, clocksource_mmio_readl_down))
+	ret = clocksource_mmio_init(samsung_timer_reg(),
+			"samsung_clocksource_timer", clock_rate, 250,
+			pwm->variant.bits, clocksource_mmio_readl_down);
+	if (ret)
 		panic("samsung_clocksource_timer: can't register clocksource\n");
 }
 
@@ -407,6 +429,15 @@ static void __init samsung_timer_resources(void)
 		panic("failed to get pwm-tdiv clock for source timer");
 
 	clk_enable(tin_source);
+
+	timer_source.tcnt_max = (1UL << pwm->variant.bits) - 1;
+	if (pwm->variant.bits == 16) {
+		timer_source.tscaler_div = 25;
+		timer_source.tdiv = 2;
+	} else {
+		timer_source.tscaler_div = 2;
+		timer_source.tdiv = 1;
+	}
 }
 
 void __init samsung_time_init(void)
-- 
1.8.1.5



From t.figa at samsung.com  Thu Apr  4 12:37:07 2013
From: t.figa at samsung.com (Tomasz Figa)
Date: Thu, 04 Apr 2013 18:37:07 +0200
Subject: [PATCH v4 10/14] clocksource: samsung-time: Use master driver to
 configure dividers
In-Reply-To: <1365093431-30621-1-git-send-email-t.figa@samsung.com>
References: <1365093431-30621-1-git-send-email-t.figa@samsung.com>
Message-ID: <1365093431-30621-11-git-send-email-t.figa@samsung.com>

This patch modifies the driver to use functions provided by master
driver to configure PWM frequency dividers.

Signed-off-by: Tomasz Figa <t.figa at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
---
 drivers/clocksource/samsung-time.c | 61 +++++---------------------------------
 1 file changed, 8 insertions(+), 53 deletions(-)

diff --git a/drivers/clocksource/samsung-time.c b/drivers/clocksource/samsung-time.c
index 4fa6f6f..e617d37 100644
--- a/drivers/clocksource/samsung-time.c
+++ b/drivers/clocksource/samsung-time.c
@@ -19,7 +19,6 @@
 
 #include <asm/sched_clock.h>
 
-#include <plat/devs.h>
 #define S3C_TIMERREG(x) (pwm->base + (x))
 #define S3C_TIMERREG2(tmr,reg) S3C_TIMERREG((reg)+0x0c+((tmr)*0x0c))
 
@@ -72,10 +71,6 @@ struct samsung_timer_source {
 };
 
 static struct samsung_pwm *pwm;
-static struct clk *tin_event;
-static struct clk *tin_source;
-static struct clk *tdiv_event;
-static struct clk *tdiv_source;
 static struct clk *timerclk;
 static struct samsung_timer_source timer_source;
 static unsigned long clock_count_per_tick;
@@ -267,9 +262,6 @@ static void samsung_timer_resume(void)
 	samsung_time_start(timer_source.source_id, true);
 }
 
-	s3c_device_timer[event].dev.bus = &platform_bus_type;
-	s3c_device_timer[source].dev.bus = &platform_bus_type;
-
 static struct clock_event_device time_event_device = {
 	.name		= "samsung_event_timer",
 	.features	= CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT,
@@ -299,18 +291,14 @@ static void __init samsung_clockevent_init(void)
 	unsigned long pclk;
 	unsigned long clock_rate;
 	unsigned int irq_number;
-	struct clk *tscaler;
 
 	pclk = clk_get_rate(timerclk);
 
-	tscaler = clk_get_parent(tdiv_event);
-
-	clk_set_rate(tscaler, pclk / timer_source.tscaler_div);
-	clk_set_rate(tdiv_event,
-			pclk / (timer_source.tscaler_div * timer_source.tdiv));
-	clk_set_parent(tin_event, tdiv_event);
+	samsung_pwm_set_prescale(pwm, timer_source.event_id,
+						timer_source.tscaler_div);
+	samsung_pwm_set_divisor(pwm, timer_source.event_id, timer_source.tdiv);
 
-	clock_rate = clk_get_rate(tin_event);
+	clock_rate = pclk / (timer_source.tscaler_div * timer_source.tdiv);
 	clock_count_per_tick = clock_rate / HZ;
 
 	time_event_device.cpumask = cpumask_of(0);
@@ -370,11 +358,11 @@ static void __init samsung_clocksource_init(void)
 
 	pclk = clk_get_rate(timerclk);
 
-	clk_set_rate(tdiv_source,
-			pclk / (timer_source.tscaler_div * timer_source.tdiv));
-	clk_set_parent(tin_source, tdiv_source);
+	samsung_pwm_set_prescale(pwm, timer_source.source_id,
+						timer_source.tscaler_div);
+	samsung_pwm_set_divisor(pwm, timer_source.source_id, timer_source.tdiv);
 
-	clock_rate = clk_get_rate(tin_source);
+	clock_rate = pclk / (timer_source.tscaler_div * timer_source.tdiv);
 
 	samsung_time_setup(timer_source.source_id, timer_source.tcnt_max);
 	samsung_time_start(timer_source.source_id, true);
@@ -391,43 +379,10 @@ static void __init samsung_clocksource_init(void)
 
 static void __init samsung_timer_resources(void)
 {
-
-	unsigned long event_id = timer_source.event_id;
-	unsigned long source_id = timer_source.source_id;
-	char devname[15];
-
 	timerclk = clk_get(NULL, "timers");
 	if (IS_ERR(timerclk))
 		panic("failed to get timers clock for timer");
 
-	clk_enable(timerclk);
-
-	sprintf(devname, "s3c24xx-pwm.%lu", event_id);
-	s3c_device_timer[event_id].id = event_id;
-	s3c_device_timer[event_id].dev.init_name = devname;
-
-	tin_event = clk_get(&s3c_device_timer[event_id].dev, "pwm-tin");
-	if (IS_ERR(tin_event))
-		panic("failed to get pwm-tin clock for event timer");
-
-	tdiv_event = clk_get(&s3c_device_timer[event_id].dev, "pwm-tdiv");
-	if (IS_ERR(tdiv_event))
-		panic("failed to get pwm-tdiv clock for event timer");
-
-	clk_enable(tin_event);
-
-	sprintf(devname, "s3c24xx-pwm.%lu", source_id);
-	s3c_device_timer[source_id].id = source_id;
-	s3c_device_timer[source_id].dev.init_name = devname;
-
-	tin_source = clk_get(&s3c_device_timer[source_id].dev, "pwm-tin");
-	if (IS_ERR(tin_source))
-		panic("failed to get pwm-tin clock for source timer");
-
-	tdiv_source = clk_get(&s3c_device_timer[source_id].dev, "pwm-tdiv");
-	if (IS_ERR(tdiv_source))
-		panic("failed to get pwm-tdiv clock for source timer");
-
 	clk_enable(tin_source);
 
 	timer_source.tcnt_max = (1UL << pwm->variant.bits) - 1;
-- 
1.8.1.5



From t.figa at samsung.com  Thu Apr  4 12:37:08 2013
From: t.figa at samsung.com (Tomasz Figa)
Date: Thu, 04 Apr 2013 18:37:08 +0200
Subject: [PATCH v4 11/14] clocksource: samsung-time: Use clk_prepare_enable
In-Reply-To: <1365093431-30621-1-git-send-email-t.figa@samsung.com>
References: <1365093431-30621-1-git-send-email-t.figa@samsung.com>
Message-ID: <1365093431-30621-12-git-send-email-t.figa@samsung.com>

This patch modifies the driver to use clk_prepare_enable instead of
clk_enable, as required to be compliant with Common Clock Framework.

Signed-off-by: Tomasz Figa <t.figa at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
---
 drivers/clocksource/samsung-time.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clocksource/samsung-time.c b/drivers/clocksource/samsung-time.c
index e617d37..7674882 100644
--- a/drivers/clocksource/samsung-time.c
+++ b/drivers/clocksource/samsung-time.c
@@ -383,7 +383,7 @@ static void __init samsung_timer_resources(void)
 	if (IS_ERR(timerclk))
 		panic("failed to get timers clock for timer");
 
-	clk_enable(tin_source);
+	clk_prepare_enable(timerclk);
 
 	timer_source.tcnt_max = (1UL << pwm->variant.bits) - 1;
 	if (pwm->variant.bits == 16) {
-- 
1.8.1.5



From t.figa at samsung.com  Thu Apr  4 12:37:09 2013
From: t.figa at samsung.com (Tomasz Figa)
Date: Thu, 04 Apr 2013 18:37:09 +0200
Subject: [PATCH v4 12/14] clocksource: samsung-time: Use master driver to
 control PWM channels
In-Reply-To: <1365093431-30621-1-git-send-email-t.figa@samsung.com>
References: <1365093431-30621-1-git-send-email-t.figa@samsung.com>
Message-ID: <1365093431-30621-13-git-send-email-t.figa@samsung.com>

This patch modifies the driver to use functions provided by the master
driver to control status of PWM channels instead of modifying shared
registers directly.

Signed-off-by: Tomasz Figa <t.figa at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
---
 drivers/clocksource/samsung-time.c | 168 ++++---------------------------------
 1 file changed, 15 insertions(+), 153 deletions(-)

diff --git a/drivers/clocksource/samsung-time.c b/drivers/clocksource/samsung-time.c
index 7674882..9425955 100644
--- a/drivers/clocksource/samsung-time.c
+++ b/drivers/clocksource/samsung-time.c
@@ -76,153 +76,11 @@ static struct samsung_timer_source timer_source;
 static unsigned long clock_count_per_tick;
 static void samsung_timer_resume(void);
 
-static void samsung_time_stop(enum samsung_timer_mode mode)
-{
-	unsigned long tcon;
-
-	tcon = __raw_readl(S3C2410_TCON);
-
-	switch (mode) {
-	case SAMSUNG_PWM0:
-		tcon &= ~S3C2410_TCON_T0START;
-		break;
-
-	case SAMSUNG_PWM1:
-		tcon &= ~S3C2410_TCON_T1START;
-		break;
-
-	case SAMSUNG_PWM2:
-		tcon &= ~S3C2410_TCON_T2START;
-		break;
-
-	case SAMSUNG_PWM3:
-		tcon &= ~S3C2410_TCON_T3START;
-		break;
-
-	case SAMSUNG_PWM4:
-		tcon &= ~S3C2410_TCON_T4START;
-		break;
-
-	default:
-		printk(KERN_ERR "Invalid Timer %d\n", mode);
-		break;
-	}
-	__raw_writel(tcon, S3C2410_TCON);
-}
-
-static void samsung_time_setup(enum samsung_timer_mode mode, unsigned long tcnt)
-{
-	unsigned long tcon;
-
-	tcon = __raw_readl(S3C2410_TCON);
-
-	tcnt--;
-
-	switch (mode) {
-	case SAMSUNG_PWM0:
-		tcon &= ~(0x0f << 0);
-		tcon |= S3C2410_TCON_T0MANUALUPD;
-		break;
-
-	case SAMSUNG_PWM1:
-		tcon &= ~(0x0f << 8);
-		tcon |= S3C2410_TCON_T1MANUALUPD;
-		break;
-
-	case SAMSUNG_PWM2:
-		tcon &= ~(0x0f << 12);
-		tcon |= S3C2410_TCON_T2MANUALUPD;
-		break;
-
-	case SAMSUNG_PWM3:
-		tcon &= ~(0x0f << 16);
-		tcon |= S3C2410_TCON_T3MANUALUPD;
-		break;
-
-	case SAMSUNG_PWM4:
-		tcon &= ~(0x07 << 20);
-		tcon |= S3C2410_TCON_T4MANUALUPD;
-		break;
-
-	default:
-		printk(KERN_ERR "Invalid Timer %d\n", mode);
-		break;
-	}
-
-	__raw_writel(tcnt, S3C2410_TCNTB(mode));
-	__raw_writel(tcnt, S3C2410_TCMPB(mode));
-	__raw_writel(tcon, S3C2410_TCON);
-}
-
-static void samsung_time_start(enum samsung_timer_mode mode, bool periodic)
-{
-	unsigned long tcon;
-
-	tcon  = __raw_readl(S3C2410_TCON);
-
-	switch (mode) {
-	case SAMSUNG_PWM0:
-		tcon |= S3C2410_TCON_T0START;
-		tcon &= ~S3C2410_TCON_T0MANUALUPD;
-
-		if (periodic)
-			tcon |= S3C2410_TCON_T0RELOAD;
-		else
-			tcon &= ~S3C2410_TCON_T0RELOAD;
-		break;
-
-	case SAMSUNG_PWM1:
-		tcon |= S3C2410_TCON_T1START;
-		tcon &= ~S3C2410_TCON_T1MANUALUPD;
-
-		if (periodic)
-			tcon |= S3C2410_TCON_T1RELOAD;
-		else
-			tcon &= ~S3C2410_TCON_T1RELOAD;
-		break;
-
-	case SAMSUNG_PWM2:
-		tcon |= S3C2410_TCON_T2START;
-		tcon &= ~S3C2410_TCON_T2MANUALUPD;
-
-		if (periodic)
-			tcon |= S3C2410_TCON_T2RELOAD;
-		else
-			tcon &= ~S3C2410_TCON_T2RELOAD;
-		break;
-
-	case SAMSUNG_PWM3:
-		tcon |= S3C2410_TCON_T3START;
-		tcon &= ~S3C2410_TCON_T3MANUALUPD;
-
-		if (periodic)
-			tcon |= S3C2410_TCON_T3RELOAD;
-		else
-			tcon &= ~S3C2410_TCON_T3RELOAD;
-		break;
-
-	case SAMSUNG_PWM4:
-		tcon |= S3C2410_TCON_T4START;
-		tcon &= ~S3C2410_TCON_T4MANUALUPD;
-
-		if (periodic)
-			tcon |= S3C2410_TCON_T4RELOAD;
-		else
-			tcon &= ~S3C2410_TCON_T4RELOAD;
-		break;
-
-	default:
-		printk(KERN_ERR "Invalid Timer %d\n", mode);
-		break;
-	}
-	__raw_writel(tcon, S3C2410_TCON);
-}
-
 static int samsung_set_next_event(unsigned long cycles,
 				struct clock_event_device *evt)
 {
-	samsung_time_setup(timer_source.event_id, cycles);
-	samsung_time_start(timer_source.event_id, false);
+	samsung_pwm_setup(pwm, timer_source.event_id, cycles - 1, cycles - 1);
+	samsung_pwm_start(pwm, timer_source.event_id, false);
 
 	return 0;
 }
@@ -230,12 +88,13 @@ static int samsung_set_next_event(unsigned long cycles,
 static void samsung_set_mode(enum clock_event_mode mode,
 				struct clock_event_device *evt)
 {
-	samsung_time_stop(timer_source.event_id);
+	samsung_pwm_stop(pwm, timer_source.event_id);
 
 	switch (mode) {
 	case CLOCK_EVT_MODE_PERIODIC:
-		samsung_time_setup(timer_source.event_id, clock_count_per_tick);
-		samsung_time_start(timer_source.event_id, true);
+		samsung_pwm_setup(pwm, timer_source.event_id,
+			clock_count_per_tick - 1, clock_count_per_tick - 1);
+		samsung_pwm_start(pwm, timer_source.event_id, true);
 		break;
 
 	case CLOCK_EVT_MODE_ONESHOT:
@@ -254,12 +113,14 @@ static void samsung_set_mode(enum clock_event_mode mode,
 static void samsung_timer_resume(void)
 {
 	/* event timer restart */
-	samsung_time_setup(timer_source.event_id, clock_count_per_tick);
-	samsung_time_start(timer_source.event_id, true);
+	samsung_pwm_setup(pwm, timer_source.event_id,
+			clock_count_per_tick - 1, clock_count_per_tick - 1);
+	samsung_pwm_start(pwm, timer_source.event_id, true);
 
 	/* source timer restart */
-	samsung_time_setup(timer_source.source_id, timer_source.tcnt_max);
-	samsung_time_start(timer_source.source_id, true);
+	samsung_pwm_setup(pwm, timer_source.source_id,
+				timer_source.tcnt_max, timer_source.tcnt_max);
+	samsung_pwm_start(pwm, timer_source.source_id, true);
 }
 
 static struct clock_event_device time_event_device = {
@@ -364,8 +225,9 @@ static void __init samsung_clocksource_init(void)
 
 	clock_rate = pclk / (timer_source.tscaler_div * timer_source.tdiv);
 
-	samsung_time_setup(timer_source.source_id, timer_source.tcnt_max);
-	samsung_time_start(timer_source.source_id, true);
+	samsung_pwm_setup(pwm, timer_source.source_id,
+				timer_source.tcnt_max, timer_source.tcnt_max);
+	samsung_pwm_start(pwm, timer_source.source_id, true);
 
 	setup_sched_clock(samsung_read_sched_clock,
 						pwm->variant.bits, clock_rate);
-- 
1.8.1.5



From t.figa at samsung.com  Thu Apr  4 12:37:10 2013
From: t.figa at samsung.com (Tomasz Figa)
Date: Thu, 04 Apr 2013 18:37:10 +0200
Subject: [PATCH v4 13/14] clocksource: samsung-time: Move IRQ mask/ack handling
 to the driver
In-Reply-To: <1365093431-30621-1-git-send-email-t.figa@samsung.com>
References: <1365093431-30621-1-git-send-email-t.figa@samsung.com>
Message-ID: <1365093431-30621-14-git-send-email-t.figa@samsung.com>

Since the clocksource driver is the only user of PWM timer interrupts,
there is no need to create an IRQ chip for handling them.

This patch the way of PWM timer interrupt handling to use real VIC/GIC
interrupt signals and handle PWM mask/ack register internally in
samsung-time driver.

Signed-off-by: Tomasz Figa <t.figa at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
---
 arch/arm/mach-exynos/include/mach/irqs.h  |  3 +--
 arch/arm/mach-s3c24xx/include/mach/irqs.h |  6 ++++++
 arch/arm/mach-s3c64xx/common.c            |  3 ---
 arch/arm/mach-s3c64xx/include/mach/irqs.h |  8 --------
 arch/arm/mach-s5p64x0/include/mach/irqs.h |  2 --
 arch/arm/mach-s5pc100/include/mach/irqs.h |  2 --
 arch/arm/mach-s5pv210/include/mach/irqs.h |  2 --
 arch/arm/plat-samsung/devs.c              | 20 ++++++++++----------
 arch/arm/plat-samsung/include/plat/irqs.h |  9 ---------
 arch/arm/plat-samsung/s5p-irq.c           |  2 --
 drivers/clocksource/samsung-time.c        | 10 ++++++++++
 11 files changed, 27 insertions(+), 40 deletions(-)

diff --git a/arch/arm/mach-exynos/include/mach/irqs.h b/arch/arm/mach-exynos/include/mach/irqs.h
index 35fe6d5..6fbe229 100644
--- a/arch/arm/mach-exynos/include/mach/irqs.h
+++ b/arch/arm/mach-exynos/include/mach/irqs.h
@@ -464,10 +464,9 @@
 #define S5P_EINT_BASE2			(S5P_EINT_BASE1 + 16)
 #define S5P_GPIOINT_BASE		(S5P_EINT_BASE1 + 32)
 #define IRQ_GPIO_END			(S5P_GPIOINT_BASE + S5P_GPIOINT_COUNT)
-#define IRQ_TIMER_BASE			(IRQ_GPIO_END + 64)
 
 /* Set the default NR_IRQS */
 
-#define NR_IRQS				(IRQ_TIMER_BASE + IRQ_TIMER_COUNT)
+#define NR_IRQS				(IRQ_GPIO_END + 64)
 
 #endif /* __ASM_ARCH_IRQS_H */
diff --git a/arch/arm/mach-s3c24xx/include/mach/irqs.h b/arch/arm/mach-s3c24xx/include/mach/irqs.h
index 43cada8..1ecbadb 100644
--- a/arch/arm/mach-s3c24xx/include/mach/irqs.h
+++ b/arch/arm/mach-s3c24xx/include/mach/irqs.h
@@ -207,6 +207,12 @@
 #define IRQ_LCD_VSYNC		IRQ_S3C2443_LCD3
 #define IRQ_LCD_SYSTEM		IRQ_S3C2443_LCD2
 
+#define IRQ_TIMER0_VIC		IRQ_TIMER0
+#define IRQ_TIMER1_VIC		IRQ_TIMER1
+#define IRQ_TIMER2_VIC		IRQ_TIMER2
+#define IRQ_TIMER3_VIC		IRQ_TIMER3
+#define IRQ_TIMER4_VIC		IRQ_TIMER4
+
 #ifdef CONFIG_CPU_S3C2440
 #define IRQ_S3C244X_AC97 IRQ_S3C2440_AC97
 #else
diff --git a/arch/arm/mach-s3c64xx/common.c b/arch/arm/mach-s3c64xx/common.c
index 526b45e..5dca83a 100644
--- a/arch/arm/mach-s3c64xx/common.c
+++ b/arch/arm/mach-s3c64xx/common.c
@@ -198,9 +198,6 @@ void __init s3c64xx_init_irq(u32 vic0_valid, u32 vic1_valid)
 	/* initialise the pair of VICs */
 	vic_init(VA_VIC0, IRQ_VIC0_BASE, vic0_valid, IRQ_VIC0_RESUME);
 	vic_init(VA_VIC1, IRQ_VIC1_BASE, vic1_valid, IRQ_VIC1_RESUME);
-
-	/* add the timer sub-irqs */
-	s3c_init_vic_timer_irq(5, IRQ_TIMER0);
 }
 
 #define eint_offset(irq)	((irq) - IRQ_EINT(0))
diff --git a/arch/arm/mach-s3c64xx/include/mach/irqs.h b/arch/arm/mach-s3c64xx/include/mach/irqs.h
index 96d60e0..67bbd1d 100644
--- a/arch/arm/mach-s3c64xx/include/mach/irqs.h
+++ b/arch/arm/mach-s3c64xx/include/mach/irqs.h
@@ -107,14 +107,6 @@
 #define IRQ_TC			IRQ_PENDN
 #define IRQ_ADC			S3C64XX_IRQ_VIC1(31)
 
-#define S3C64XX_TIMER_IRQ(x)	S3C_IRQ(64 + (x))
-
-#define IRQ_TIMER0		S3C64XX_TIMER_IRQ(0)
-#define IRQ_TIMER1		S3C64XX_TIMER_IRQ(1)
-#define IRQ_TIMER2		S3C64XX_TIMER_IRQ(2)
-#define IRQ_TIMER3		S3C64XX_TIMER_IRQ(3)
-#define IRQ_TIMER4		S3C64XX_TIMER_IRQ(4)
-
 /* compatibility for device defines */
 
 #define IRQ_IIC1		IRQ_S3C6410_IIC1
diff --git a/arch/arm/mach-s5p64x0/include/mach/irqs.h b/arch/arm/mach-s5p64x0/include/mach/irqs.h
index 5b845e8..53982db 100644
--- a/arch/arm/mach-s5p64x0/include/mach/irqs.h
+++ b/arch/arm/mach-s5p64x0/include/mach/irqs.h
@@ -141,8 +141,6 @@
 
 #define IRQ_EINT_GROUP(grp, x)	(IRQ_EINT_GROUP##grp##_BASE + (x))
 
-#define IRQ_TIMER_BASE		(11)
-
 /* Set the default NR_IRQS */
 
 #define NR_IRQS			(IRQ_EINT_GROUP8_BASE + IRQ_EINT_GROUP8_NR + 1)
diff --git a/arch/arm/mach-s5pc100/include/mach/irqs.h b/arch/arm/mach-s5pc100/include/mach/irqs.h
index 2870f12..d2eb475 100644
--- a/arch/arm/mach-s5pc100/include/mach/irqs.h
+++ b/arch/arm/mach-s5pc100/include/mach/irqs.h
@@ -97,8 +97,6 @@
 #define IRQ_SDMFIQ		S5P_IRQ_VIC2(31)
 #define IRQ_VIC_END		S5P_IRQ_VIC2(31)
 
-#define IRQ_TIMER_BASE		(11)
-
 #define S5P_EINT_BASE1		(S5P_IRQ_VIC0(0))
 #define S5P_EINT_BASE2		(IRQ_VIC_END + 1)
 
diff --git a/arch/arm/mach-s5pv210/include/mach/irqs.h b/arch/arm/mach-s5pv210/include/mach/irqs.h
index e777e01..5e0de3a 100644
--- a/arch/arm/mach-s5pv210/include/mach/irqs.h
+++ b/arch/arm/mach-s5pv210/include/mach/irqs.h
@@ -118,8 +118,6 @@
 #define IRQ_MDNIE3		S5P_IRQ_VIC3(8)
 #define IRQ_VIC_END		S5P_IRQ_VIC3(31)
 
-#define IRQ_TIMER_BASE		(11)
-
 #define S5P_EINT_BASE1		(S5P_IRQ_VIC0(0))
 #define S5P_EINT_BASE2		(IRQ_VIC_END + 1)
 
diff --git a/arch/arm/plat-samsung/devs.c b/arch/arm/plat-samsung/devs.c
index 747763d..cdeaf26 100644
--- a/arch/arm/plat-samsung/devs.c
+++ b/arch/arm/plat-samsung/devs.c
@@ -1161,20 +1161,20 @@ arch_initcall(s5p_pmu_init);
  */
 
 struct platform_device s3c_device_timer[] = {
-	[0] = { DEFINE_S3C_TIMER(0, IRQ_TIMER0) },
-	[1] = { DEFINE_S3C_TIMER(1, IRQ_TIMER1) },
-	[2] = { DEFINE_S3C_TIMER(2, IRQ_TIMER2) },
-	[3] = { DEFINE_S3C_TIMER(3, IRQ_TIMER3) },
-	[4] = { DEFINE_S3C_TIMER(4, IRQ_TIMER4) },
+	[0] = { DEFINE_S3C_TIMER(0, IRQ_TIMER0_VIC) },
+	[1] = { DEFINE_S3C_TIMER(1, IRQ_TIMER1_VIC) },
+	[2] = { DEFINE_S3C_TIMER(2, IRQ_TIMER2_VIC) },
+	[3] = { DEFINE_S3C_TIMER(3, IRQ_TIMER3_VIC) },
+	[4] = { DEFINE_S3C_TIMER(4, IRQ_TIMER4_VIC) },
 };
 #endif /* CONFIG_SAMSUNG_DEV_PWM */
 
 static struct resource samsung_pwm_resource[] = {
-	DEFINE_RES_IRQ(IRQ_TIMER0),
-	DEFINE_RES_IRQ(IRQ_TIMER1),
-	DEFINE_RES_IRQ(IRQ_TIMER2),
-	DEFINE_RES_IRQ(IRQ_TIMER3),
-	DEFINE_RES_IRQ(IRQ_TIMER4),
+	DEFINE_RES_IRQ(IRQ_TIMER0_VIC),
+	DEFINE_RES_IRQ(IRQ_TIMER1_VIC),
+	DEFINE_RES_IRQ(IRQ_TIMER2_VIC),
+	DEFINE_RES_IRQ(IRQ_TIMER3_VIC),
+	DEFINE_RES_IRQ(IRQ_TIMER4_VIC),
 	DEFINE_RES_MEM(SAMSUNG_PA_TIMER, SZ_4K),
 };
 
diff --git a/arch/arm/plat-samsung/include/plat/irqs.h b/arch/arm/plat-samsung/include/plat/irqs.h
index df46b77..039001c 100644
--- a/arch/arm/plat-samsung/include/plat/irqs.h
+++ b/arch/arm/plat-samsung/include/plat/irqs.h
@@ -44,15 +44,6 @@
 #define S5P_IRQ_VIC2(x)		(S5P_VIC2_BASE + (x))
 #define S5P_IRQ_VIC3(x)		(S5P_VIC3_BASE + (x))
 
-#define S5P_TIMER_IRQ(x)	(IRQ_TIMER_BASE + (x))
-
-#define IRQ_TIMER0		S5P_TIMER_IRQ(0)
-#define IRQ_TIMER1		S5P_TIMER_IRQ(1)
-#define IRQ_TIMER2		S5P_TIMER_IRQ(2)
-#define IRQ_TIMER3		S5P_TIMER_IRQ(3)
-#define IRQ_TIMER4		S5P_TIMER_IRQ(4)
-#define IRQ_TIMER_COUNT		(5)
-
 #define IRQ_EINT(x)		((x) < 16 ? ((x) + S5P_EINT_BASE1) \
 					: ((x) - 16 + S5P_EINT_BASE2))
 
diff --git a/arch/arm/plat-samsung/s5p-irq.c b/arch/arm/plat-samsung/s5p-irq.c
index 103e371..ce8564d 100644
--- a/arch/arm/plat-samsung/s5p-irq.c
+++ b/arch/arm/plat-samsung/s5p-irq.c
@@ -29,6 +29,4 @@ void __init s5p_init_irq(u32 *vic, u32 num_vic)
 	for (irq = 0; irq < num_vic; irq++)
 		vic_init(VA_VIC(irq), VIC_BASE(irq), vic[irq], 0);
 #endif
-
-	s3c_init_vic_timer_irq(5, IRQ_TIMER0);
 }
diff --git a/drivers/clocksource/samsung-time.c b/drivers/clocksource/samsung-time.c
index 9425955..d9a3d60 100644
--- a/drivers/clocksource/samsung-time.c
+++ b/drivers/clocksource/samsung-time.c
@@ -135,6 +135,11 @@ static irqreturn_t samsung_clock_event_isr(int irq, void *dev_id)
 {
 	struct clock_event_device *evt = dev_id;
 
+	if (pwm->variant.has_tint_cstat) {
+		u32 mask = (1 << timer_source.event_id);
+		writel(mask | (mask << 5), S3C64XX_TINT_CSTAT);
+	}
+
 	evt->event_handler(evt);
 
 	return IRQ_HANDLED;
@@ -168,6 +173,11 @@ static void __init samsung_clockevent_init(void)
 
 	irq_number = pwm->irq[timer_source.event_id];
 	setup_irq(irq_number, &samsung_clock_event_irq);
+
+	if (pwm->variant.has_tint_cstat) {
+		u32 mask = (1 << timer_source.event_id);
+		writel(mask | (mask << 5), S3C64XX_TINT_CSTAT);
+	}
 }
 
 static void __iomem *samsung_timer_reg(void)
-- 
1.8.1.5



From t.figa at samsung.com  Thu Apr  4 12:37:11 2013
From: t.figa at samsung.com (Tomasz Figa)
Date: Thu, 04 Apr 2013 18:37:11 +0200
Subject: [PATCH v4 14/14] ARM: SAMSUNG: Remove unused PWM timer IRQ chip code
In-Reply-To: <1365093431-30621-1-git-send-email-t.figa@samsung.com>
References: <1365093431-30621-1-git-send-email-t.figa@samsung.com>
Message-ID: <1365093431-30621-15-git-send-email-t.figa@samsung.com>

As the need for an IRQ chip handling PWM timer interrupt chaining is
gone now, this patch removes all the code made unnecessary.

Signed-off-by: Tomasz Figa <t.figa at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
---
 arch/arm/Kconfig                                   |  1 -
 arch/arm/mach-s3c64xx/common.c                     |  1 -
 arch/arm/plat-samsung/Kconfig                      |  6 --
 arch/arm/plat-samsung/Makefile                     |  1 -
 arch/arm/plat-samsung/include/plat/irq-vic-timer.h | 13 ---
 arch/arm/plat-samsung/irq-vic-timer.c              | 98 ----------------------
 arch/arm/plat-samsung/s5p-irq.c                    |  1 -
 7 files changed, 121 deletions(-)
 delete mode 100644 arch/arm/plat-samsung/include/plat/irq-vic-timer.h
 delete mode 100644 arch/arm/plat-samsung/irq-vic-timer.c

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index dd68dec..ed584d4 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -806,7 +806,6 @@ config ARCH_S3C64XX
 	select S3C_GPIO_TRACK
 	select SAMSUNG_CLKSRC
 	select SAMSUNG_GPIOLIB_4BIT
-	select SAMSUNG_IRQ_VIC_TIMER
 	select USB_ARCH_HAS_OHCI
 	help
 	  Samsung S3C64XX series based systems
diff --git a/arch/arm/mach-s3c64xx/common.c b/arch/arm/mach-s3c64xx/common.c
index 5dca83a..e2134b0 100644
--- a/arch/arm/mach-s3c64xx/common.c
+++ b/arch/arm/mach-s3c64xx/common.c
@@ -42,7 +42,6 @@
 #include <plat/pm.h>
 #include <plat/gpio-cfg.h>
 #include <plat/irq-uart.h>
-#include <plat/irq-vic-timer.h>
 #include <plat/regs-irqtype.h>
 #include <plat/regs-serial.h>
 #include <plat/watchdog-reset.h>
diff --git a/arch/arm/plat-samsung/Kconfig b/arch/arm/plat-samsung/Kconfig
index 6f632ba..9951879 100644
--- a/arch/arm/plat-samsung/Kconfig
+++ b/arch/arm/plat-samsung/Kconfig
@@ -27,7 +27,6 @@ config PLAT_S5P
 	select S5P_GPIO_DRVSTR
 	select SAMSUNG_CLKSRC if !COMMON_CLK
 	select SAMSUNG_GPIOLIB_4BIT
-	select SAMSUNG_IRQ_VIC_TIMER
 	help
 	  Base platform code for Samsung's S5P series SoC.
 
@@ -79,11 +78,6 @@ config S5P_CLOCK
 
 # options for IRQ support
 
-config SAMSUNG_IRQ_VIC_TIMER
-       bool
-       help
-         Internal configuration to build the VIC timer interrupt code.
-
 config S5P_IRQ
 	def_bool (ARCH_S5P64X0 || ARCH_S5PC100 || ARCH_S5PV210 || ARCH_EXYNOS)
 	help
diff --git a/arch/arm/plat-samsung/Makefile b/arch/arm/plat-samsung/Makefile
index 87494e1..ae2a0fd 100644
--- a/arch/arm/plat-samsung/Makefile
+++ b/arch/arm/plat-samsung/Makefile
@@ -19,7 +19,6 @@ obj-$(CONFIG_SAMSUNG_CLOCK)	+= pwm-clock.o
 obj-$(CONFIG_SAMSUNG_CLKSRC)	+= clock-clksrc.o
 obj-$(CONFIG_S5P_CLOCK)		+= s5p-clock.o
 
-obj-$(CONFIG_SAMSUNG_IRQ_VIC_TIMER) += irq-vic-timer.o
 obj-$(CONFIG_S5P_IRQ)		+= s5p-irq.o
 obj-$(CONFIG_S5P_EXT_INT)	+= s5p-irq-eint.o
 obj-$(CONFIG_S5P_GPIO_INT)	+= s5p-irq-gpioint.o
diff --git a/arch/arm/plat-samsung/include/plat/irq-vic-timer.h b/arch/arm/plat-samsung/include/plat/irq-vic-timer.h
deleted file mode 100644
index 5b9c42f..0000000
--- a/arch/arm/plat-samsung/include/plat/irq-vic-timer.h
+++ /dev/null
@@ -1,13 +0,0 @@
-/* arch/arm/plat-samsung/include/plat/irq-vic-timer.h
- *
- * Copyright (c) 2010 Simtec Electronics
- *	Ben Dooks <ben at simtec.co.uk>
- *
- * Header file for Samsung SoC IRQ VIC timer
- *
- * 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.
-*/
-
-extern void s3c_init_vic_timer_irq(unsigned int num, unsigned int timer_irq);
diff --git a/arch/arm/plat-samsung/irq-vic-timer.c b/arch/arm/plat-samsung/irq-vic-timer.c
deleted file mode 100644
index f980cf3..0000000
--- a/arch/arm/plat-samsung/irq-vic-timer.c
+++ /dev/null
@@ -1,98 +0,0 @@
-/* arch/arm/plat-samsung/irq-vic-timer.c
- *	originally part of arch/arm/plat-s3c64xx/irq.c
- *
- * Copyright 2008 Openmoko, Inc.
- * Copyright 2008 Simtec Electronics
- *      Ben Dooks <ben at simtec.co.uk>
- *      http://armlinux.simtec.co.uk/
- *
- * S3C64XX - Interrupt handling
- *
- * 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/interrupt.h>
-#include <linux/irq.h>
-#include <linux/io.h>
-
-#include <mach/map.h>
-#include <plat/cpu.h>
-#include <plat/irq-vic-timer.h>
-#include <plat/regs-timer.h>
-
-#include <asm/mach/irq.h>
-
-static void s3c_irq_demux_vic_timer(unsigned int irq, struct irq_desc *desc)
-{
-	struct irq_chip *chip = irq_get_chip(irq);
-	chained_irq_enter(chip, desc);
-	generic_handle_irq((int)desc->irq_data.handler_data);
-	chained_irq_exit(chip, desc);
-}
-
-/* We assume the IRQ_TIMER0..IRQ_TIMER4 range is continuous. */
-static void s3c_irq_timer_ack(struct irq_data *d)
-{
-	struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
-	u32 mask = (1 << 5) << (d->irq - gc->irq_base);
-
-	irq_reg_writel(mask | gc->mask_cache, gc->reg_base);
-}
-
-/**
- * s3c_init_vic_timer_irq() - initialise timer irq chanined off VIC.\
- * @num: Number of timers to initialize
- * @timer_irq: Base IRQ number to be used for the timers.
- *
- * Register the necessary IRQ chaining and support for the timer IRQs
- * chained of the VIC.
- */
-void __init s3c_init_vic_timer_irq(unsigned int num, unsigned int timer_irq)
-{
-	unsigned int pirq[5] = { IRQ_TIMER0_VIC, IRQ_TIMER1_VIC, IRQ_TIMER2_VIC,
-				 IRQ_TIMER3_VIC, IRQ_TIMER4_VIC };
-	struct irq_chip_generic *s3c_tgc;
-	struct irq_chip_type *ct;
-	unsigned int i;
-
-#ifdef CONFIG_ARCH_EXYNOS
-	if (soc_is_exynos5250()) {
-		pirq[0] = EXYNOS5_IRQ_TIMER0_VIC;
-		pirq[1] = EXYNOS5_IRQ_TIMER1_VIC;
-		pirq[2] = EXYNOS5_IRQ_TIMER2_VIC;
-		pirq[3] = EXYNOS5_IRQ_TIMER3_VIC;
-		pirq[4] = EXYNOS5_IRQ_TIMER4_VIC;
-	} else {
-		pirq[0] = EXYNOS4_IRQ_TIMER0_VIC;
-		pirq[1] = EXYNOS4_IRQ_TIMER1_VIC;
-		pirq[2] = EXYNOS4_IRQ_TIMER2_VIC;
-		pirq[3] = EXYNOS4_IRQ_TIMER3_VIC;
-		pirq[4] = EXYNOS4_IRQ_TIMER4_VIC;
-	}
-#endif
-	s3c_tgc = irq_alloc_generic_chip("s3c-timer", 1, timer_irq,
-					 S3C64XX_TINT_CSTAT, handle_level_irq);
-
-	if (!s3c_tgc) {
-		pr_err("%s: irq_alloc_generic_chip for IRQ %d failed\n",
-		       __func__, timer_irq);
-		return;
-	}
-
-	ct = s3c_tgc->chip_types;
-	ct->chip.irq_mask = irq_gc_mask_clr_bit;
-	ct->chip.irq_unmask = irq_gc_mask_set_bit;
-	ct->chip.irq_ack = s3c_irq_timer_ack;
-	irq_setup_generic_chip(s3c_tgc, IRQ_MSK(num), IRQ_GC_INIT_MASK_CACHE,
-			       IRQ_NOREQUEST | IRQ_NOPROBE, 0);
-	/* Clear the upper bits of the mask_cache*/
-	s3c_tgc->mask_cache &= 0x1f;
-
-	for (i = 0; i < num; i++, timer_irq++) {
-		irq_set_chained_handler(pirq[i], s3c_irq_demux_vic_timer);
-		irq_set_handler_data(pirq[i], (void *)timer_irq);
-	}
-}
diff --git a/arch/arm/plat-samsung/s5p-irq.c b/arch/arm/plat-samsung/s5p-irq.c
index ce8564d..b1e2a82 100644
--- a/arch/arm/plat-samsung/s5p-irq.c
+++ b/arch/arm/plat-samsung/s5p-irq.c
@@ -18,7 +18,6 @@
 #include <mach/map.h>
 #include <plat/regs-timer.h>
 #include <plat/cpu.h>
-#include <plat/irq-vic-timer.h>
 
 void __init s5p_init_irq(u32 *vic, u32 num_vic)
 {
-- 
1.8.1.5



From tony at atomide.com  Thu Apr  4 12:41:38 2013
From: tony at atomide.com (Tony Lindgren)
Date: Thu, 4 Apr 2013 09:41:38 -0700
Subject: [RFC][PATCH 1/2] ARM: OMAP4: clock: Add device tree support
 for AUXCLKs
In-Reply-To: <515D2D30.3000306@ti.com>
References: <1363703220-4777-1-git-send-email-rogerq@ti.com>
 <1363703220-4777-2-git-send-email-rogerq@ti.com>
 <20130403234242.GE10155@atomide.com> <515D2D30.3000306@ti.com>
Message-ID: <20130404164137.GH10155@atomide.com>

* Roger Quadros <rogerq at ti.com> [130404 00:39]:
> On 04/04/2013 02:42 AM, Tony Lindgren wrote:
> >> --- a/arch/arm/mach-omap2/cclock44xx_data.c
> >> +++ b/arch/arm/mach-omap2/cclock44xx_data.c
> >> @@ -27,6 +27,7 @@
> >>  #include <linux/clk-private.h>
> >>  #include <linux/clkdev.h>
> >>  #include <linux/io.h>
> >> +#include <linux/of.h>
> >>  
> >>  #include "soc.h"
> >>  #include "iomap.h"
> >> @@ -1663,6 +1664,40 @@ static struct omap_clk omap44xx_clks[] = {
> >>  	CLK(NULL,	"cpufreq_ck",	&dpll_mpu_ck,	CK_443X),
> >>  };
> >>  
> >> +static struct clk *scrm_clks[] = {
> >> +	&auxclk0_ck,
> >> +	&auxclk1_ck,
> >> +	&auxclk2_ck,
> >> +	&auxclk3_ck,
> >> +	&auxclk4_ck,
> >> +	&auxclk5_ck,
> >> +};
> > 
> > Hmm I don't like the idea of specifying the auxclk both in the
> > cclock44xx_data.c and in DT..
> 
> Right, but till we have all clocks moved to DT we only need this
> approach for general purpose clocks that are not mapped to devices
> by hwmod.

For v3.10, let's just make sure that USB works with DT as then
after v3.10 we can make omap4 DT only and get rid of estimated
7K lines of code and data. I guess this is the last piece missing
for that, or are we also missing something else?

Can't you set up a clock alias for your device so it can find the
auxclk when requesting it with the dev entry?

For the DT clock driver if needed for v3.10, how about just do a
minimal drivers/clock/omap/ that uses the standard binding?
Then that driver can just do clk_get() from cclock44xx_data.c
for now? And then later on we'll just move all the clocks to a
combination of DT + /lib/firmware.

> e.g. auxclk are required to be specified in DT nodes for USB PHY.
> Without this we can't get USB host working on Panda.

OK. So if the USB PHY has a dev entry, can't you just set up a
clock alias in struct omap_clk omap44xx_clks[] for it?
 
> As Rajendra points out, it seems moving entire clock data to DT is not
> going to happen soon. So this is the simplistic way things can work.

Right but seems like we can get started there without moving
them all at once.

Regards,

Tony


From swarren at wwwdotorg.org  Thu Apr  4 12:41:49 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Thu, 04 Apr 2013 10:41:49 -0600
Subject: [PATCH V2 4/7] kbuild: always run gcc -E on *.dts,
 remove cmd_dtc_cpp
In-Reply-To: <515CC317.2000703@elopez.com.ar>
References: <1365032098-22825-1-git-send-email-swarren@wwwdotorg.org>
 <1365032098-22825-4-git-send-email-swarren@wwwdotorg.org>
 <515CC317.2000703@elopez.com.ar>
Message-ID: <515DAD4D.9020100@wwwdotorg.org>

On 04/03/2013 06:02 PM, Emilio L?pez wrote:
> Hi Stephen,
> 
> El 03/04/13 20:34, Stephen Warren escribi?:
>> From: Stephen Warren <swarren at nvidia.com>
>>
>> Replace cmd_dtc with cmd_dtc_cpp, and delete the latter.
>>
>> Previously, a special file extension (.dtsp) was required to trigger
>> the C pre-processor to run on device tree files. This was ugly. Now that
>> previous changes have enhanced cmd_dtc_cpp to collect dependency
>> information from both gcc -E and dtc, we can transparently run the pre-
>> processor on all device tree files, irrespective of whether they
>>
> 
> I think a line got dropped on the commit description by mistake.

Thanks for noticing. I've locally added the following line to the end of
the description, but won't repost unless there's some other reason, or
the series is ack'd enough to actually be applied:

use /include/ or #include syntax to include *.dtsi.



From santosh.shilimkar at ti.com  Thu Apr  4 12:49:25 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Thu, 4 Apr 2013 22:19:25 +0530
Subject: [PATCH v2 00/18] ARM: OMAP5: PM: Add MPUSS suspend and CPUidle
 support
In-Reply-To: <515D8F60.1080603@ti.com>
References: <1364205910-32392-1-git-send-email-santosh.shilimkar@ti.com>
 <87hajnp6ph.fsf@linaro.org> <515D8F60.1080603@ti.com>
Message-ID: <515DAF15.8000700@ti.com>

On Thursday 04 April 2013 08:04 PM, Santosh Shilimkar wrote:
> On Thursday 04 April 2013 04:22 AM, Kevin Hilman wrote:
>> Hi Santosh,
>>
>> Santosh Shilimkar <santosh.shilimkar at ti.com> writes:
>>
>>> Here is the refreshed version(v2) of the OMAP5 PM suspport which was posted
>>> earlier (March 1st 2013). Patch-set incorporates comments from Nishant
>>> Menon (Thanks for review NM) and his acked-by tags. I would like to get this
>>> queued for 3.10 merge window if you are ok with the series.
>>
>> I did a review of this series with several comments on the individual
>> patches.  
>>
> Thanks a lot Kevin. I have addressed all the comments and have
> updated patches ready.
> 
>> I've already queued most of the CPUidle fixes/cleanups in my
>> for_3.10/cleanup/cpuidle branch and will get that to Tony soon.  For the
>> rest, I suggest probably breaking it up into cleanup/consolidation stuff
>> and then OMAP5 support.  The latter will depend on all the OMAP5
>> data/headers but the cleanup/consolidation stuff could be merged sooner
>> (but probably a bit late for v3.10 now.)
>>
> I have already split the patch-set into 'consolidation' and 'OMAP5
> support' since it was straight forward. Need to just build the
> branches on top of your branches. So waiting for you to update
> your 'for_3.10/*' branches.
> 
> For the merge, its your call:)
> As you said OMAP5 support(couple of patches) has a dependency
> on OMAP5 data files. I will at least make the branches ready on
> top of yours.
> 
After looking at your tree, looks like the branches are already
there. Idle branch name is not for_3.10/fixes/cpuidle though :)

So I created 'for_3.10/omap_pm-cleanup' and 'for_3.10/omap5_pm_v2'
and pushed on my git tree [1] in case you would like to have
a look. I briefly tested them on OMAP4 device with
CPUidle enabled and they seems to work fine. Will do OMAP5
testing tomorrow and then post the updated patches on list.

Regards,
Santosh

[1] git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux.git



From will.deacon at arm.com  Thu Apr  4 12:50:59 2013
From: will.deacon at arm.com (Will Deacon)
Date: Thu,  4 Apr 2013 17:50:59 +0100
Subject: [PATCH] documentation: iommu: add description of ARM System MMU
 binding
Message-ID: <1365094259-24847-1-git-send-email-will.deacon@arm.com>

This patch adds a description of the device tree binding for the ARM
System MMU architecture.

Cc: Rob Herring <robherring2 at gmail.com>
Cc: Andreas Herrmann <andreas.herrmann at calxeda.com>
Signed-off-by: Will Deacon <will.deacon at arm.com>
---

Hello,

The driver for this is still a WIP. Both Andreas and myself have prototype
code, but we're planning to merge that together to get something more
general. Deciding on the binding is a good first step.

All comments welcome,

Will

 .../devicetree/bindings/iommu/arm,smmu.txt         | 61 ++++++++++++++++++++++
 1 file changed, 61 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iommu/arm,smmu.txt

diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
new file mode 100644
index 0000000..938325f
--- /dev/null
+++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
@@ -0,0 +1,61 @@
+* ARM System MMU Architecture Implementation
+
+ARM SoCs may contain an implementation of the ARM System Memory
+Management Unit Architecture, which can be used to provide 1 or 2 stages
+of address translation to bus masters external to the CPU.
+
+The SMMU may also raise interrupts in response to various fault
+conditions.
+
+** System MMU required properties:
+
+- compatible    : Should be one of "arm,smmu-v1" or "arm,smmu-v2"
+                  depending on the version of the architecture
+                  implemented.
+
+- reg           : Base address and size of the SMMU.
+
+- #global-interrupts : The number of global interrupts exposed by the
+                       device.
+
+- interrupts    : Interrupt list, with the first #global-irqs entries
+                  corresponding to the global interrupts and any
+                  following entries corresponding to context interrupts,
+                  specified in order of their indexing by the SMMU.
+
+- mmu-masters   : A list of phandles to device nodes representing bus
+                  masters for which the SMMU can provide a translation.
+
+- stream-ids    : A list of 16-bit values corresponding to the StreamIDs
+                  for the devices listed in the mmu-masters property.
+                  This list must be same length as mmu-masters, so
+                  masters with multiple stream-ids will have multiple
+                  entries in mmu-masters.
+
+** System MMU optional properties:
+
+- smmu-parent   : When multiple SMMUs are chained together, this
+                  property can be used to provide a phandle to the
+                  parent SMMU (that is the next SMMU on the path going
+                  from the mmu-masters towards memory) node for this
+                  SMMU.
+
+Example:
+
+        smmu {
+                compatible = "arm,smmu-v1";
+                reg = <0xba5e0000 0x10000>;
+                #global-interrupts = <2>;
+                interrupts = <0 32 4>,
+                             <0 33 4>,
+                             <0 34 4>, /* This is the first context interrupt */
+                             <0 35 4>,
+                             <0 36 4>,
+                             <0 37 4>;
+                mmu-masters = <&dma0>,
+                              <&dma0>,
+                              <&dma1>;
+                stream-ids  = <0xd01d>,
+                              <0xd01e>,
+                              <0xd11c>;
+        };
-- 
1.8.0



From t.figa at samsung.com  Thu Apr  4 12:51:12 2013
From: t.figa at samsung.com (Tomasz Figa)
Date: Thu, 04 Apr 2013 18:51:12 +0200
Subject: [PATCH 0/3] ARM: EXYNOS: DT-enabled support for Universal C210
Message-ID: <1365094275-4811-1-git-send-email-t.figa@samsung.com>

This series intends to add support for Universal C210 board using Device
Tree. Main difference from other boards based on Exynos 4210 is that
hardware revision of the SoC used on Universal C210 does not support MCT
timers and legacy PWM timers must be used instead.

First patch adds device tree node for PWM block available on Exynos 4 SoCs,
second patch adds support for Exynos4210 EVT0 SoC to mach-exynos4-dt and
third patch introduces initial device tree for Universal C210 board.

Depends on my series for PWM timers rework:
[PATCH v4 00/14] ARM: samsung-time: Prepare for multiplatform support
(http://thread.gmane.org/gmane.linux.kernel.samsung-soc/17464)

Tested on Universal C210 board.

Tomasz Figa (3):
  ARM: dts: exynos4: Add node for PWM device
  ARM: EXYNOS: Add support for Exynos4210 EVT0 SoC
  ARM: dts: exynos4210: Add basic dts file for universal_c210 board

 arch/arm/boot/dts/Makefile                      |   1 +
 arch/arm/boot/dts/exynos4.dtsi                  |   8 +
 arch/arm/boot/dts/exynos4210-universal_c210.dts | 353 ++++++++++++++++++++++++
 arch/arm/mach-exynos/Kconfig                    |   9 +
 arch/arm/mach-exynos/mach-exynos4-dt.c          |  33 +++
 5 files changed, 404 insertions(+)
 create mode 100644 arch/arm/boot/dts/exynos4210-universal_c210.dts

-- 
1.8.1.5



From t.figa at samsung.com  Thu Apr  4 12:51:13 2013
From: t.figa at samsung.com (Tomasz Figa)
Date: Thu, 04 Apr 2013 18:51:13 +0200
Subject: [PATCH 1/3] ARM: dts: exynos4: Add node for PWM device
In-Reply-To: <1365094275-4811-1-git-send-email-t.figa@samsung.com>
References: <1365094275-4811-1-git-send-email-t.figa@samsung.com>
Message-ID: <1365094275-4811-2-git-send-email-t.figa@samsung.com>

This patch adds device tree node for PWM block present on Exynos 4 SoCs.

Signed-off-by: Tomasz Figa <t.figa at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
---
 arch/arm/boot/dts/exynos4.dtsi | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index 800ff11..d1bedd4 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -331,6 +331,14 @@
 		status = "disabled";
 	};
 
+	pwm at 139D0000 {
+		compatible = "samsung,s5pc100-pwm";
+		reg = <0x139D0000 0x1000>;
+		interrupts = <0 37 0>, <0 38 0>, <0 39 0>, <0 40 0>, <0 41 0>;
+		#pwm-cells = <2>;
+		status = "disabled";
+	};
+
 	amba {
 		#address-cells = <1>;
 		#size-cells = <1>;
-- 
1.8.1.5



From t.figa at samsung.com  Thu Apr  4 12:51:14 2013
From: t.figa at samsung.com (Tomasz Figa)
Date: Thu, 04 Apr 2013 18:51:14 +0200
Subject: [PATCH 2/3] ARM: EXYNOS: Add support for Exynos4210 EVT0 SoC
In-Reply-To: <1365094275-4811-1-git-send-email-t.figa@samsung.com>
References: <1365094275-4811-1-git-send-email-t.figa@samsung.com>
Message-ID: <1365094275-4811-3-git-send-email-t.figa@samsung.com>

This patch extends mach-exynos4-dt generic board file with support for
Exynos4210 EVT0 SoC, which differs in availability of system timers and
needs different time initialization.

Signed-off-by: Tomasz Figa <t.figa at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
---
 arch/arm/mach-exynos/Kconfig           |  9 +++++++++
 arch/arm/mach-exynos/mach-exynos4-dt.c | 33 +++++++++++++++++++++++++++++++++
 2 files changed, 42 insertions(+)

diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index e538705..56920b3 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -39,6 +39,15 @@ config CPU_EXYNOS4210
 	help
 	  Enable EXYNOS4210 CPU support
 
+config SOC_EXYNOS4210_EVT0
+	bool "SAMSUNG EXYNOS4210 EVT0"
+	default y
+	select SOC_EXYNOS4210
+	select CLKSRC_MMIO
+	select SAMSUNG_HRT
+	help
+	  Enable EXYNOS4210 EVT0 SoC support
+
 config SOC_EXYNOS4212
 	bool "SAMSUNG EXYNOS4212"
 	default y
diff --git a/arch/arm/mach-exynos/mach-exynos4-dt.c b/arch/arm/mach-exynos/mach-exynos4-dt.c
index b9ed834..ec6dd17 100644
--- a/arch/arm/mach-exynos/mach-exynos4-dt.c
+++ b/arch/arm/mach-exynos/mach-exynos4-dt.c
@@ -16,10 +16,12 @@
 #include <linux/of_fdt.h>
 #include <linux/serial_core.h>
 #include <linux/memblock.h>
+#include <linux/clk-provider.h>
 #include <linux/clocksource.h>
 
 #include <asm/mach/arch.h>
 #include <plat/mfc.h>
+#include <plat/samsung-time.h>
 
 #include "common.h"
 
@@ -65,3 +67,34 @@ DT_MACHINE_START(EXYNOS4210_DT, "Samsung Exynos4 (Flattened Device Tree)")
 	.restart        = exynos4_restart,
 	.reserve	= exynos4_reserve,
 MACHINE_END
+
+#ifdef CONFIG_SOC_EXYNOS4210_EVT0
+static void __init exynos4210_evt0_init_time(void)
+{
+	of_clk_init(NULL);
+	samsung_time_init();
+}
+
+static void __init exynos4210_evt0_dt_map_io(void)
+{
+	exynos4_dt_map_io();
+}
+
+static char const *exynos4210_evt0_dt_compat[] __initdata = {
+	"samsung,exynos4210-evt0",
+	NULL
+};
+
+DT_MACHINE_START(EXYNOS4210_EVT0_DT, "Samsung Exynos4210 EVT0 (Device Tree)")
+	.smp		= smp_ops(exynos_smp_ops),
+	.init_irq	= exynos4_init_irq,
+	.map_io		= exynos4210_evt0_dt_map_io,
+	.init_early	= exynos_firmware_init,
+	.init_machine	= exynos4_dt_machine_init,
+	.init_late	= exynos_init_late,
+	.init_time	= exynos4210_evt0_init_time,
+	.dt_compat	= exynos4210_evt0_dt_compat,
+	.restart        = exynos4_restart,
+	.reserve	= exynos4_reserve,
+MACHINE_END
+#endif
-- 
1.8.1.5



From t.figa at samsung.com  Thu Apr  4 12:51:15 2013
From: t.figa at samsung.com (Tomasz Figa)
Date: Thu, 04 Apr 2013 18:51:15 +0200
Subject: [PATCH 3/3] ARM: dts: exynos4210: Add basic dts file for
 universal_c210 board
In-Reply-To: <1365094275-4811-1-git-send-email-t.figa@samsung.com>
References: <1365094275-4811-1-git-send-email-t.figa@samsung.com>
Message-ID: <1365094275-4811-4-git-send-email-t.figa@samsung.com>

This patch adds basic device tree sources for Universal C210 board.

Currently support includes:
- eMMC
- serial
- max8952 and max8998 voltage regulators.
- gpio-keys
- touchscreen

More support will be added in further patches.

Signed-off-by: Tomasz Figa <t.figa at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
---
 arch/arm/boot/dts/Makefile                      |   1 +
 arch/arm/boot/dts/exynos4210-universal_c210.dts | 353 ++++++++++++++++++++++++
 2 files changed, 354 insertions(+)
 create mode 100644 arch/arm/boot/dts/exynos4210-universal_c210.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index d3cd880..2d870f4 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -42,6 +42,7 @@ dtb-$(CONFIG_ARCH_DOVE) += dove-cm-a510.dtb \
 dtb-$(CONFIG_ARCH_EXYNOS) += exynos4210-origen.dtb \
 	exynos4210-smdkv310.dtb \
 	exynos4210-trats.dtb \
+	exynos4210-universal_c210.dtb \
 	exynos4412-odroidx.dtb \
 	exynos4412-smdk4412.dtb \
 	exynos4412-origen.dtb \
diff --git a/arch/arm/boot/dts/exynos4210-universal_c210.dts b/arch/arm/boot/dts/exynos4210-universal_c210.dts
new file mode 100644
index 0000000..81acb94
--- /dev/null
+++ b/arch/arm/boot/dts/exynos4210-universal_c210.dts
@@ -0,0 +1,353 @@
+/*
+ * Samsung's Exynos4210 based Universal C210 board device tree source
+ *
+ * Copyright (c) 2012 Samsung Electronics Co., Ltd.
+ *		http://www.samsung.com
+ *
+ * Device tree source file for Samsung's Universal C210 board which is based on
+ * Samsung's Exynos4210 EVT0 SoC.
+ *
+ * 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.
+*/
+
+/dts-v1/;
+/include/ "exynos4210.dtsi"
+
+/ {
+	model = "Samsung Universal C210 based on Exynos4210 EVT0";
+	compatible = "samsung,universal_c210", "samsung,exynos4210-evt0";
+
+	memory {
+		reg =  <0x40000000 0x10000000
+			0x50000000 0x10000000>;
+	};
+
+	chosen {
+		bootargs = "console=ttySAC2,115200N8 root=/dev/mmcblk0p5 rw rootwait earlyprintk panic=5 maxcpus=1";
+	};
+
+	fixed-rate-clocks {
+		xxti {
+			compatible = "samsung,clock-xxti";
+			clock-frequency = <0>;
+		};
+
+		xusbxti {
+			compatible = "samsung,clock-xusbxti";
+			clock-frequency = <24000000>;
+		};
+	};
+
+	vemmc_reg: voltage-regulator {
+	        compatible = "regulator-fixed";
+		regulator-name = "VMEM_VDD_2_8V";
+		regulator-min-microvolt = <2800000>;
+		regulator-max-microvolt = <2800000>;
+		gpio = <&gpe1 3 0>;
+		enable-active-high;
+	};
+
+	sdhci_emmc: sdhci at 12510000 {
+		bus-width = <8>;
+		non-removable;
+		pinctrl-0 = <&sd0_clk &sd0_cmd &sd0_bus8>;
+		pinctrl-names = "default";
+		vmmc-supply = <&vemmc_reg>;
+		status = "okay";
+	};
+
+	serial at 13800000 {
+		status = "okay";
+	};
+
+	serial at 13810000 {
+		status = "okay";
+	};
+
+	serial at 13820000 {
+		status = "okay";
+	};
+
+	serial at 13830000 {
+		status = "okay";
+	};
+
+	gpio-keys {
+		compatible = "gpio-keys";
+
+		vol-up-key {
+			gpios = <&gpx2 0 1>;
+			linux,code = <115>;
+			label = "volume up";
+			debounce-interval = <1>;
+		};
+
+		vol-down-key {
+			gpios = <&gpx2 1 1>;
+			linux,code = <114>;
+			label = "volume down";
+			debounce-interval = <1>;
+		};
+
+		config-key {
+			gpios = <&gpx2 2 1>;
+			linux,code = <171>;
+			label = "config";
+			debounce-interval = <1>;
+			gpio-key,wakeup;
+		};
+
+		camera-key {
+			gpios = <&gpx2 3 1>;
+			linux,code = <212>;
+			label = "camera";
+			debounce-interval = <1>;
+		};
+
+		ok-key {
+			gpios = <&gpx3 5 1>;
+			linux,code = <352>;
+			label = "ok";
+			debounce-interval = <1>;
+		};
+	};
+
+	tsp_reg: voltage-regulator {
+	        compatible = "regulator-fixed";
+		regulator-name = "TSP_2_8V";
+		regulator-min-microvolt = <2800000>;
+		regulator-max-microvolt = <2800000>;
+		gpio = <&gpe2 3 0>;
+		enable-active-high;
+	};
+
+	i2c at 13890000 {
+		samsung,i2c-sda-delay = <100>;
+		samsung,i2c-slave-addr = <0x10>;
+		samsung,i2c-max-bus-freq = <100000>;
+		pinctrl-0 = <&i2c3_bus>;
+		pinctrl-names = "default";
+		status = "okay";
+
+		tsp at 4a {
+			compatible = "atmel,maxtouch";
+			reg = <0x4a>;
+			interrupt-parent = <&gpe1>;
+			interrupts = <7 2>;
+
+			atmel,x-line = <19>;
+			atmel,y-line = <11>;
+			atmel,x-size = <800>;
+			atmel,y-size = <480>;
+			atmel,burst-length = <0x11>;
+			atmel,threshold = <0x28>;
+			atmel,orientation = <1>;
+
+			vdd-supply = <&tsp_reg>;
+		};
+	};
+
+	i2c at 138B0000 {
+		samsung,i2c-sda-delay = <100>;
+		samsung,i2c-slave-addr = <0x10>;
+		samsung,i2c-max-bus-freq = <100000>;
+		pinctrl-0 = <&i2c5_bus>;
+		pinctrl-names = "default";
+		status = "okay";
+
+		vdd_arm_reg: pmic at 60 {
+			compatible = "maxim,max8952";
+			reg = <0x60>;
+
+			max8952,vid-gpios = <&gpx0 3 0>, <&gpx0 4 0>;
+			max8952,default-mode = <0>;
+			max8952,dvs-mode-microvolt = <1250000>, <1200000>,
+							<1050000>, <950000>;
+			max8952,sync-freq = <0>;
+			max8952,ramp-speed = <0>;
+
+			regulator-name = "vdd_arm";
+			regulator-min-microvolt = <770000>;
+			regulator-max-microvolt = <1400000>;
+			regulator-always-on;
+			regulator-boot-on;
+		};
+
+		pmic at 66 {
+			compatible = "national,lp3974";
+			reg = <0x66>;
+
+			max8998,pmic-buck1-default-dvs-idx = <0>;
+			max8998,pmic-buck1-dvs-gpios = <&gpx0 5 0>,
+							<&gpx0 6 0>;
+			max8998,pmic-buck1-dvs-voltage = <1100000>, <1000000>,
+							<1100000>, <1000000>;
+
+			max8998,pmic-buck2-default-dvs-idx = <0>;
+			max8998,pmic-buck2-dvs-gpio = <&gpe2 0 0>;
+			max8998,pmic-buck2-dvs-voltage = <1200000>, <1100000>;
+
+			regulators {
+				ldo2_reg: LDO2 {
+					regulator-name = "VALIVE_1.2V";
+					regulator-min-microvolt = <1200000>;
+					regulator-max-microvolt = <1200000>;
+					regulator-always-on;
+				};
+
+				ldo3_reg: LDO3 {
+					regulator-name = "VUSB+MIPI_1.1V";
+					regulator-min-microvolt = <1100000>;
+					regulator-max-microvolt = <1100000>;
+				};
+
+				ldo4_reg: LDO4 {
+					regulator-name = "VADC_3.3V";
+					regulator-min-microvolt = <3300000>;
+					regulator-max-microvolt = <3300000>;
+				};
+
+				ldo5_reg: LDO5 {
+					regulator-name = "VTF_2.8V";
+					regulator-min-microvolt = <2800000>;
+					regulator-max-microvolt = <2800000>;
+				};
+
+				ldo6_reg: LDO6 {
+					regulator-name = "LDO6";
+					regulator-min-microvolt = <2000000>;
+					regulator-max-microvolt = <2000000>;
+				};
+
+				ldo7_reg: LDO7 {
+					regulator-name = "VLCD+VMIPI_1.8V";
+					regulator-min-microvolt = <1800000>;
+					regulator-max-microvolt = <1800000>;
+					regulator-always-on;
+				};
+
+				ldo8_reg: LDO8 {
+					regulator-name = "VUSB+VDAC_3.3V";
+					regulator-min-microvolt = <3300000>;
+					regulator-max-microvolt = <3300000>;
+				};
+
+				ldo9_reg: LDO9 {
+					regulator-name = "VCC_2.8V";
+					regulator-min-microvolt = <2800000>;
+					regulator-max-microvolt = <2800000>;
+					regulator-always-on;
+				};
+
+				ldo10_reg: LDO10 {
+					regulator-name = "VPLL_1.1V";
+					regulator-min-microvolt = <1100000>;
+					regulator-max-microvolt = <1100000>;
+					regulator-boot-on;
+					regulator-always-on;
+				};
+
+				ldo11_reg: LDO11 {
+					regulator-name = "CAM_AF_3.3V";
+					regulator-min-microvolt = <3300000>;
+					regulator-max-microvolt = <3300000>;
+				};
+
+				ldo12_reg: LDO12 {
+					regulator-name = "PS_2.8V";
+					regulator-min-microvolt = <2800000>;
+					regulator-max-microvolt = <2800000>;
+				};
+
+				ldo13_reg: LDO13 {
+					regulator-name = "VHIC_1.2V";
+					regulator-min-microvolt = <1200000>;
+					regulator-max-microvolt = <1200000>;
+				};
+
+				ldo14_reg: LDO14 {
+					regulator-name = "CAM_I_HOST_1.8V";
+					regulator-min-microvolt = <1800000>;
+					regulator-max-microvolt = <1800000>;
+				};
+
+				ldo15_reg: LDO15 {
+					regulator-name = "CAM_S_DIG+FM33_CORE_1.2V";
+					regulator-min-microvolt = <1200000>;
+					regulator-max-microvolt = <1200000>;
+				};
+
+				ldo16_reg: LDO16 {
+					regulator-name = "CAM_S_ANA_2.8V";
+					regulator-min-microvolt = <2800000>;
+					regulator-max-microvolt = <2800000>;
+				};
+
+				ldo17_reg: LDO17 {
+					regulator-name = "VCC_3.0V_LCD";
+					regulator-min-microvolt = <3000000>;
+					regulator-max-microvolt = <3000000>;
+					regulator-always-on;
+				};
+
+				buck1_reg: BUCK1 {
+					regulator-name = "VINT_1.1V";
+					regulator-min-microvolt = <750000>;
+					regulator-max-microvolt = <1500000>;
+					regulator-boot-on;
+					regulator-always-on;
+				};
+
+				buck2_reg: BUCK2 {
+					regulator-name = "VG3D_1.1V";
+					regulator-min-microvolt = <750000>;
+					regulator-max-microvolt = <1500000>;
+					regulator-boot-on;
+				};
+
+				buck3_reg: BUCK3 {
+					regulator-name = "VCC_1.8V";
+					regulator-min-microvolt = <1800000>;
+					regulator-max-microvolt = <1800000>;
+					regulator-always-on;
+				};
+
+				buck4_reg: BUCK4 {
+					regulator-name = "VMEM_1.2V";
+					regulator-min-microvolt = <1200000>;
+					regulator-max-microvolt = <1200000>;
+					regulator-always-on;
+				};
+
+				ap32khz_reg: EN32KHz-AP {
+					regulator-name = "32KHz AP";
+					regulator-always-on;
+				};
+
+				cp32khz_reg: EN32KHz-CP {
+					regulator-name = "32KHz CP";
+				};
+
+				vichg_reg: ENVICHG {
+					regulator-name = "VICHG";
+				};
+
+				safeout1_reg: ESAFEOUT1 {
+					regulator-name = "SAFEOUT1";
+					regulator-always-on;
+				};
+
+				safeout2_reg: ESAFEOUT2 {
+					regulator-name = "SAFEOUT2";
+					regulator-boot-on;
+				};
+			};
+		};
+	};
+
+	pwm at 139D0000 {
+		status = "okay";
+	};
+};
-- 
1.8.1.5



From tony at atomide.com  Thu Apr  4 12:52:09 2013
From: tony at atomide.com (Tony Lindgren)
Date: Thu, 4 Apr 2013 09:52:09 -0700
Subject: [GIT PULL] ARM: OMAP5: hwmod, prm/cm data files and updates
 for 3.10
In-Reply-To: <515D6020.2030103@ti.com>
References: <1363768852-18125-1-git-send-email-santosh.shilimkar@ti.com>
 <20130401170539.GK10155@atomide.com> <515BA76D.3000302@ti.com>
 <alpine.DEB.2.00.1304031146230.2616@utopia.booyaka.com>
 <515D6020.2030103@ti.com>
Message-ID: <20130404165208.GI10155@atomide.com>

* Santosh Shilimkar <santosh.shilimkar at ti.com> [130404 04:15]:
> + Tero and few more TI folks,
> 
> On Thursday 04 April 2013 01:12 AM, Paul Walmsley wrote:
> > Hi Santosh
> > 
> > On Wed, 3 Apr 2013, Santosh Shilimkar wrote:
> > 
> >> Thes patchset has already missed last couple of merge windows and its the
> >> biggest bottleneck in getting OMAP5 booting from mainline. So I request
> >> you to please have a look it quickly so that Tony can line that up for
> >> 3.10.
> > 
> > Looks like there are a few minor issues with the patches based on a quick 
> > look.  I'll post those to the list shortly; they should be easy to fix.  
> > But those issues aren't my real concern with this series.
> > 
> > What's harder to fix are the underlying process issues.  My main concern 
> > is that these patches add almost 9,000 lines of code and data.  We've 
> > received clear guidance from the upstream ARM SoC maintainers that any 
> > significant new additions need to be balanced with moving a similar number 
> > of lines of code and data out of arch/arm/{plat-,mach-}* into drivers/.  
> > (Or the new patches should be accompanied with patches that show obvious 
> > progress towards the goal of moving code and data out of 
> > arch/arm/{plat-,mach-}*.)  We need to see more help from TI on the 
> > prerequisites for this cleanup process.
> >
> I agree that we are not making faster progress but as part of the
> $subject series itself, for DT only build, we removed around ~4000
> lines of data from hwmod. After the merge window, we can trim
> the AM33XX and then later OMAP4 when it is made DT only support.
> That should give us another 6000 lines of negative diff.
> At the same time removal of MUX data for OMAP4 should be
> around 2000 lines of negative diff.

Can't we already trim the am33xx hwmod data after your patches for
v3.10 as am33xx is already DT only? Unfortunately we cannot create
negative diffstat in other ways for v3.10 merge window as we cannot
make omap4 DT only just quite yet.

FYI, I have some trivial patches here to drop board and mux support for
omap4 once we can make omap4 DT only, so that will be about 3000 lines
of reduction with estimated 1000 - 2000 lines once I go through the
unneeded platform init code for omap4 for things like MMC and USB.
 
The rest of the clean-up issues I believe we all agree, we just need
to get it done so we can avoid getting flamed for every new SoC for
the huge data files. To fix the data issue for good, it seems that we can
get started moving both the clock and hwmod data to simple drivers
that can get clocks and hwmod data both from DT and /lib/firmware.
It also seems that we don't need to move all the data at once, which
makes the task easier.

Cheers,

Tony


From santosh.shilimkar at ti.com  Thu Apr  4 12:57:52 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Thu, 4 Apr 2013 22:27:52 +0530
Subject: [GIT PULL] ARM: OMAP5: hwmod, prm/cm data files and updates for
 3.10
In-Reply-To: <20130404165208.GI10155@atomide.com>
References: <1363768852-18125-1-git-send-email-santosh.shilimkar@ti.com>
 <20130401170539.GK10155@atomide.com> <515BA76D.3000302@ti.com>
 <alpine.DEB.2.00.1304031146230.2616@utopia.booyaka.com>
 <515D6020.2030103@ti.com> <20130404165208.GI10155@atomide.com>
Message-ID: <515DB110.9000503@ti.com>

On Thursday 04 April 2013 10:22 PM, Tony Lindgren wrote:
> * Santosh Shilimkar <santosh.shilimkar at ti.com> [130404 04:15]:
>> + Tero and few more TI folks,
>>
>> On Thursday 04 April 2013 01:12 AM, Paul Walmsley wrote:
>>> Hi Santosh
>>>
>>> On Wed, 3 Apr 2013, Santosh Shilimkar wrote:
>>>
>>>> Thes patchset has already missed last couple of merge windows and its the
>>>> biggest bottleneck in getting OMAP5 booting from mainline. So I request
>>>> you to please have a look it quickly so that Tony can line that up for
>>>> 3.10.
>>>
>>> Looks like there are a few minor issues with the patches based on a quick 
>>> look.  I'll post those to the list shortly; they should be easy to fix.  
>>> But those issues aren't my real concern with this series.
>>>
>>> What's harder to fix are the underlying process issues.  My main concern 
>>> is that these patches add almost 9,000 lines of code and data.  We've 
>>> received clear guidance from the upstream ARM SoC maintainers that any 
>>> significant new additions need to be balanced with moving a similar number 
>>> of lines of code and data out of arch/arm/{plat-,mach-}* into drivers/.  
>>> (Or the new patches should be accompanied with patches that show obvious 
>>> progress towards the goal of moving code and data out of 
>>> arch/arm/{plat-,mach-}*.)  We need to see more help from TI on the 
>>> prerequisites for this cleanup process.
>>>
>> I agree that we are not making faster progress but as part of the
>> $subject series itself, for DT only build, we removed around ~4000
>> lines of data from hwmod. After the merge window, we can trim
>> the AM33XX and then later OMAP4 when it is made DT only support.
>> That should give us another 6000 lines of negative diff.
>> At the same time removal of MUX data for OMAP4 should be
>> around 2000 lines of negative diff.
> 
> Can't we already trim the am33xx hwmod data after your patches for
> v3.10 as am33xx is already DT only? Unfortunately we cannot create
> negative diffstat in other ways for v3.10 merge window as we cannot
> make omap4 DT only just quite yet.
> 
Yes we can and I can take a stab it tomorrow. The only thing is I
might need some support for testing but thats manageable. Will
take a stab at it tomorrow and if everything goes well, post a
patch for smae.

> FYI, I have some trivial patches here to drop board and mux support for
> omap4 once we can make omap4 DT only, so that will be about 3000 lines
> of reduction with estimated 1000 - 2000 lines once I go through the
> unneeded platform init code for omap4 for things like MMC and USB.
>  
Cool.

> The rest of the clean-up issues I believe we all agree, we just need
> to get it done so we can avoid getting flamed for every new SoC for
> the huge data files. To fix the data issue for good, it seems that we can
> get started moving both the clock and hwmod data to simple drivers
> that can get clocks and hwmod data both from DT and /lib/firmware.
> It also seems that we don't need to move all the data at once, which
> makes the task easier.
> 
Agree.


regards,
santosh



From nicolas.ferre at atmel.com  Thu Apr  4 12:59:59 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Thu, 4 Apr 2013 18:59:59 +0200
Subject: [GIT PULL] at91: DT changes for 3.10 #3
In-Reply-To: <20130402184947.GA8015@quad.lixom.net>
References: <20130402184947.GA8015@quad.lixom.net>
Message-ID: <1365094799-16940-1-git-send-email-nicolas.ferre@atmel.com>

Arnd, Olof,

Here is the refreshed pull-request for AT91 that is dedicated to Device Tree
modifications. It is stacked on the material that you already have
for 3.10 in your arm-soc/at91/dt branch.
Following our discussion with Arnd, I added the non-urgent patches that I
already proposed too late for 3.9. I also included the moving of macb node
and kept the original patch.

As Olof asked, I renamed the Aria board dts file: at91-ariag25.dts and placed
it in the Makefile. I also took the advantage of this delay to stack two more
DT related patches.

Thanks, best regards,

The following changes since commit 6901d947be5ba1245a0f63271355b95f9056a362:

  ARM: at91/at91sam9x5cm: add 1-wire chip on CM board (2013-03-21 16:07:15 +0100)

are available in the git repository at:

  git://github.com/at91linux/linux-at91.git tags/at91-dt

for you to fetch changes up to f10491fff07dcced77f8ab1b3bc1f8e18715bfb9:

  ARM: at91/at91sam9260.dtsi: fix u(s)art pinctrl encoding (2013-04-04 18:31:17 +0200)

----------------------------------------------------------------
One macb DT node move for 9x5 family: 9g15 doesn't
have an Ethernet interface.
Little fixes mainly related to at91sam9x5 DT, IIO ADC bindings,
pinctrl for at91sam9260/g20 DT and the RTC addition.
Addition of the Acme Systems Aria G25 board.

----------------------------------------------------------------
Douglas Gilbert (2):
      ARM: at91: add Acme Systems Aria G25 board
      ARM: at91/at91sam9260.dtsi: fix u(s)art pinctrl encoding

Ludovic Desroches (1):
      ARM: at91: dts: add adc resolution stuff

Nicolas Ferre (5):
      ARM: at91/at91sam9x5: add RTC node
      ARM: at91/trivial: typos in compatible property
      ARM: at91/trivial: fix model name for SAM9G15-EK
      ARM: at91: remove partial parameter in bootargs for at91sam9x5ek.dtsi
      ARM: at91/dt: fix macb node declaration

 arch/arm/boot/dts/Makefile          |   1 +
 arch/arm/boot/dts/at91-ariag25.dts  | 171 +++++++++++++++++++++++++++++++++++
 arch/arm/boot/dts/at91sam9260.dtsi  |  19 ++--
 arch/arm/boot/dts/at91sam9g15.dtsi  |   2 +-
 arch/arm/boot/dts/at91sam9g15ek.dts |   2 +-
 arch/arm/boot/dts/at91sam9g25.dtsi  |   2 +-
 arch/arm/boot/dts/at91sam9g25ek.dts |   9 ++
 arch/arm/boot/dts/at91sam9g35.dtsi  |   2 +-
 arch/arm/boot/dts/at91sam9g35ek.dts |   9 ++
 arch/arm/boot/dts/at91sam9g45.dtsi  |   3 +
 arch/arm/boot/dts/at91sam9x25.dtsi  |   2 +-
 arch/arm/boot/dts/at91sam9x25ek.dts |  14 +++
 arch/arm/boot/dts/at91sam9x35.dtsi  |   2 +-
 arch/arm/boot/dts/at91sam9x35ek.dts |   9 ++
 arch/arm/boot/dts/at91sam9x5.dtsi   |  10 ++
 arch/arm/boot/dts/at91sam9x5ek.dtsi |   7 +-
 16 files changed, 244 insertions(+), 20 deletions(-)
 create mode 100644 arch/arm/boot/dts/at91-ariag25.dts

-- 
Nicolas Ferre


From mturquette at linaro.org  Thu Apr  4 13:01:58 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Thu, 04 Apr 2013 10:01:58 -0700
Subject: [PATCH 4/6] pinctrl: sunxi: add clock support
In-Reply-To: <CACRpkdacuu9JwY5waFwch=v2G6MkTZOO=DXismdsfr0Ttoi9=g@mail.gmail.com>
References: <1363962042-29536-1-git-send-email-emilio@elopez.com.ar>
 <1363962042-29536-5-git-send-email-emilio@elopez.com.ar>
 <CACRpkdbn9c_bAWUN8hTLkeidCnyZ=0nRQRBV39DMkK_0jBfoUQ@mail.gmail.com>
 <51535077.1050203@free-electrons.com>
 <CACRpkda80EKT2LbsBCOng=gkdtdd+vbYwkMPiFZUBx7z_aqY+A@mail.gmail.com>
 <515C9D25.3050407@free-electrons.com>
 <CACRpkdacuu9JwY5waFwch=v2G6MkTZOO=DXismdsfr0Ttoi9=g@mail.gmail.com>
Message-ID: <20130404170158.8665.65205@quantum>

Quoting Linus Walleij (2013-04-04 04:37:23)
> On Wed, Apr 3, 2013 at 11:20 PM, Maxime Ripard
> <maxime.ripard at free-electrons.com> wrote:
> > Le 03/04/2013 13:59, Linus Walleij a ?crit :
> >> On Wed, Mar 27, 2013 at 9:03 PM, Maxime Ripard
> >> <maxime.ripard at free-electrons.com> wrote:
> >>
> >>> Hi Linus,
> >>> Le 27/03/2013 14:14, Linus Walleij a ?crit :
> >>>> On Fri, Mar 22, 2013 at 3:20 PM, Emilio L?pez <emilio at elopez.com.ar> wrote:
> >>>>
> >>>>> For the port controller to work, we need to enable the apb0_pio gate.
> >>>>> This commit adds the ability to enable one clock specified on the device
> >>>>> tree to the pinctrl driver.
> >>>>>
> >>>>> Signed-off-by: Emilio L?pez <emilio at elopez.com.ar>
> >>>>
> >>>> Acked-by: Linus Walleij <linus.walleij at linaro.org>
> >>>>
> >>>> I guess you'll want to merge these as one series to some platform-specific
> >>>> tree, tell me if you want it merged in the pinctrl tree.
> >>>
> >>> The easiest would probably be to merge this patch through your patch,
> >>> with Mike taking the clock driver patches and me taking the dt ones,
> >>> once we agree on the other patches.
> >>
> >> OK then, patch applied to the pinctrl tree, thanks!
> >
> > Ouch, the previous patches aren't applied yet by Mike, and we didn't
> > have some comments from him about these patches, so I can't really say
> > if the previous patches will get merge by 3.10 or not... So we will
> > maybe end up with a broken pinctrl stuff.
> 
> This is usually why we keep patches together and merge whole series
> into one tree, such as ARM SoC.
> 
> Well, maybe I'll drop it then ...
> 

I plan on taking in the three clk patches after getting final comments
from Gregory.  So maybe you do not need to drop the pinctrl patches?

Regards,
Mike

> Yours,
> Linus Walleij


From dgilbert at interlog.com  Thu Apr  4 13:03:04 2013
From: dgilbert at interlog.com (Douglas Gilbert)
Date: Thu, 04 Apr 2013 13:03:04 -0400
Subject: [PATCH v3] ARM: at91: add Acme Systems Aria G25 board
In-Reply-To: <1365090153-1807-1-git-send-email-nicolas.ferre@atmel.com>
References: <20130402184947.GA8015@quad.lixom.net>
 <1365090153-1807-1-git-send-email-nicolas.ferre@atmel.com>
Message-ID: <515DB248.6070105@interlog.com>

On 13-04-04 11:42 AM, Nicolas Ferre wrote:
> From: Douglas Gilbert <dgilbert at interlog.com>
>
> Signed-off-by: Douglas Gilbert <dgilbert at interlog.com>
> Signed-off-by: Nicolas Ferre <nicolas.ferre at atmel.com>
> ---
> Hi all,
>
> Here is the third revision of this patch. I plan to include it in a
> pull-request real-soon-now!
>
> v3: - move to "at91-" prefix for .dts[i] files
>      - remove the rtc activation code because of the ongoing discussions
>        about this IP and its DT binding.
>

Nicolas,
It's a pity that the rtc activation code is removed.
At worst:
                         rtc at fffffeb0 {
                                 status = "okay";
                         };

does nothing. Also it is unlikely to be changed by any
movement on the rtc-at91rm9200 front.


The lack of use of uart1 is for my own, private reasons.
I think it would be more generally useful to show uart1's
definition and disable it as shown in the attached patch
fragment.


I also note that my date line was removed. I like dates,
so when I add comments like "the i2c-at91 driver is broken
for the SAM9G20 ** and use the i2c-gpio driver instead" then
this is not taken as an eternal truth. It worked in the
past and hopefully it will work again in the future.

While on the subject of I2C, I'm getting tired of seeing
this oft-copied line:
    i2c-gpio,delay-us = <2>;        /* ~100 kHz */

It is the clock half period in microseconds and for the 100 kHz
(standard) I2C clock speed, it should be 5. Due to rounding
(up) that gives a measured clock speed of around 88 kHz on
my equipment. Crappy I2C devices *** seem to cope better
with 12% below the standard clock frequency than 80% above
it.

Doug Gilbert

** broken in my tests on the FoxG20 with lk 3.9.0-rc5

*** if my experience is anything to go by there are many
     dodgy I2C devices, probably using I2C bit banging
     code borrowed from Wikipedia.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: ariag25_390rc5_dg1.patch
Type: text/x-patch
Size: 1031 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130404/d55f77f4/attachment.bin>

From olof at lixom.net  Thu Apr  4 13:19:53 2013
From: olof at lixom.net (Olof Johansson)
Date: Thu, 4 Apr 2013 10:19:53 -0700
Subject: [GIT PULL] at91: DT changes for 3.10 #2
In-Reply-To: <515D49D4.5020208@atmel.com>
References: <1364569179-24773-1-git-send-email-nicolas.ferre@atmel.com>
 <20130402184947.GA8015@quad.lixom.net> <515BDE2C.9030904@atmel.com>
 <515D49D4.5020208@atmel.com>
Message-ID: <CAOesGMiDEER3++J80KtU3UDLWNADaJhGS7upArFm2RzM4Z_P=w@mail.gmail.com>

On Thu, Apr 4, 2013 at 2:37 AM, Nicolas Ferre <nicolas.ferre at atmel.com> wrote:
> On 04/03/2013 09:45 AM, Nicolas Ferre :
>> On 04/02/2013 08:49 PM, Olof Johansson :
>>> On Fri, Mar 29, 2013 at 03:59:39PM +0100, Nicolas Ferre wrote:
>>>> Arnd, Olof,
>>>>
>>>> Here is a pull-request for AT91 that is dedicated to Device Tree
>>>> modifications. It is stacked on the material that you already have
>>>> for 3.10 in your arm-soc/at91/dt branch.
>>>> Following our discussion with Arnd, I added the non-urgent patches that I
>>>> already proposed too late for 3.9. I also included the moving of macb node
>>>> and kept the original patch.
>>>>
>>>> Thanks, best regards,
>>>>
>>>> The following changes since commit 6901d947be5ba1245a0f63271355b95f9056a362:
>>>>
>>>>   ARM: at91/at91sam9x5cm: add 1-wire chip on CM board (2013-03-21 16:07:15 +0100)
>>>>
>>>> are available in the git repository at:
>>>>
>>>>   git://github.com/at91linux/linux-at91.git tags/at91-dt
>>>>
>>>> for you to fetch changes up to cc2e191b0ccc5a987fdb29261ab9c264c608924d:
>>>>
>>>>   ARM: at91/dt: fix macb node declaration (2013-03-29 10:02:04 +0100)
>>>>
>>>> ----------------------------------------------------------------
>>>> One macb DT node move for 9x5 family: 9g15 doesn't
>>>> have an Ethernet interface.
>>>> Little fixes mainly related to at91sam9x5 DT and the
>>>> RTC addition.
>>>> Addition of the Acme Systems Aria G25 board.
>>>>
>>>> ----------------------------------------------------------------
>>>> Douglas Gilbert (1):
>>>>       ARM: at91: add Acme Systems Aria G25 board
>>>
>>> Hi,
>>>
>>> I just replied to the above patch -- please prefix the dts files with the
>>> platform so it's easier to navigate the directory.
>
> I do not want to spark a debate here, but moving to directories per
> "mach" earlier would have made things easier. If I recall well,
> Jean-Christophe has proposed it a long time ago...

Yeah, we're at a size where it's starting to be warranted (powerpc
does so already). It does cut down on the cross-exposure and review
though and puts everyone in their own little sandbox, so there's some
benefit in keeping it flat.

I think that benefit is losing its appeal though. But let's hold off
for another couple of releases with the churn of moving things out in
subdirectories.

>> Yes, I have to make sure that everybody agree on our side...
>
> The difficult point with this prefix... well it is difficult to tell...
> our product will never be called "at91" again!

That's a marketing issue, not a technical kernel one. If we create
subdirectory it makes sense to name it 'atmel' instead of 'at91'
though, I'm sure.

> So, yes, our Linux identity is still "at91" and we are pretty attached
> to it but our newer products are named "sam" + "core" + "product family"
> which results in our newer family: "sama5d3" (note the at91 is missing)...
> => anyway, we think that the at91 prefix is still vivid in Linux
> community and we consider it as a good choice for now.
> So, I may rename the newly introduced "sama5d3*.dts[i]" files with
> "at91-sama5d3*.dts[i]" (while .c/.h files will remain the same).

Sounds reasonable, or stick to the same format as you already have
with at91sam9 families. When we move to subdirectories it might make
sense to stick them under 'atmel' instead of 'at91' though and drop
the prefix.



-Olof


From fabio.estevam at freescale.com  Thu Apr  4 13:30:42 2013
From: fabio.estevam at freescale.com (Fabio Estevam)
Date: Thu, 4 Apr 2013 14:30:42 -0300
Subject: [PATCH v3 1/2] ARM: dts: mxs: Use 'regulator-fixed' for turning on LCD
Message-ID: <1365096643-21361-1-git-send-email-fabio.estevam@freescale.com>

Instead of using a custom binding for turning on a GPIO that activates the
LCD, use the standard 'regulator-fixed'.

Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
---
Changes since v2:
- 
Changes since v1:
- Adjust Subject, since the change is not specific to mx28evk
 Documentation/devicetree/bindings/fb/mxsfb.txt |    5 +----
 arch/arm/boot/dts/imx23-evk.dts                |   10 +++++++++-
 arch/arm/boot/dts/imx28-evk.dts                |   10 +++++++++-
 3 files changed, 19 insertions(+), 6 deletions(-)

diff --git a/Documentation/devicetree/bindings/fb/mxsfb.txt b/Documentation/devicetree/bindings/fb/mxsfb.txt
index 7ba3b76..b15230c 100644
--- a/Documentation/devicetree/bindings/fb/mxsfb.txt
+++ b/Documentation/devicetree/bindings/fb/mxsfb.txt
@@ -8,9 +8,7 @@ Required properties:
 - display : phandle to display node (see below for details)
 
 Optional properties:
-- panel-enable-gpios : Should specify the gpio for panel enable
-
-* display node
+- display node
 
 Required properties:
 - bits-per-pixel : <16> for RGB565, <32> for RGB888/666.
@@ -25,7 +23,6 @@ lcdif at 80030000 {
 	compatible = "fsl,imx28-lcdif";
 	reg = <0x80030000 2000>;
 	interrupts = <38 86>;
-	panel-enable-gpios = <&gpio3 30 0>;
 
 	display: display {
 		bits-per-pixel = <32>;
diff --git a/arch/arm/boot/dts/imx23-evk.dts b/arch/arm/boot/dts/imx23-evk.dts
index 7880e17..ddc3416 100644
--- a/arch/arm/boot/dts/imx23-evk.dts
+++ b/arch/arm/boot/dts/imx23-evk.dts
@@ -59,7 +59,6 @@
 			lcdif at 80030000 {
 				pinctrl-names = "default";
 				pinctrl-0 = <&lcdif_24bit_pins_a>;
-				panel-enable-gpios = <&gpio1 18 0>;
 				display = <&display>;
 				status = "okay";
 
@@ -120,6 +119,15 @@
 			regulator-max-microvolt = <3300000>;
 			gpio = <&gpio1 29 0>;
 		};
+
+		reg_lcd: lcd {
+			compatible = "regulator-fixed";
+			regulator-name = "lcd";
+			regulator-min-microvolt = <3300000>;
+			regulator-max-microvolt = <3300000>;
+			gpio = <&gpio1 18 0>;
+			enable-active-high;
+		}
 	};
 
 	backlight {
diff --git a/arch/arm/boot/dts/imx28-evk.dts b/arch/arm/boot/dts/imx28-evk.dts
index 2d4ea3b..c886e9a 100644
--- a/arch/arm/boot/dts/imx28-evk.dts
+++ b/arch/arm/boot/dts/imx28-evk.dts
@@ -123,7 +123,6 @@
 				pinctrl-names = "default";
 				pinctrl-0 = <&lcdif_24bit_pins_a
 					     &lcdif_pins_evk>;
-				panel-enable-gpios = <&gpio3 30 0>;
 				display = <&display>;
 				status = "okay";
 
@@ -310,6 +309,15 @@
 			gpio = <&gpio3 8 0>;
 			enable-active-high;
 		};
+
+		reg_lcd: lcd {
+			compatible = "regulator-fixed";
+			regulator-name = "lcd";
+			regulator-min-microvolt = <3300000>;
+			regulator-max-microvolt = <3300000>;
+			gpio = <&gpio3 30 0>;
+			enable-active-high;
+		};
 	};
 
 	sound {
-- 
1.7.9.5




From fabio.estevam at freescale.com  Thu Apr  4 13:30:43 2013
From: fabio.estevam at freescale.com (Fabio Estevam)
Date: Thu, 4 Apr 2013 14:30:43 -0300
Subject: [PATCH v3 2/2] video: mxsfb: Use devm_regulator_get()
In-Reply-To: <1365096643-21361-1-git-send-email-fabio.estevam@freescale.com>
References: <1365096643-21361-1-git-send-email-fabio.estevam@freescale.com>
Message-ID: <1365096643-21361-2-git-send-email-fabio.estevam@freescale.com>

Instead of using a custom binding for retrieving the GPIO that activates the 
LCD from devicetree, use the standard devm_regulator_get().

This approach has the advantage to be more generic. 

For example: in the case of a board that has a PMIC supplying the LCD voltage, 
the current approach would not work, as it only searches for a GPIO pin.

Cc: Florian Tobias Schandinat <FlorianSchandinat at gmx.de>
Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
---
Changes since v2:
- Use devm_regulator_get()
Changes since v1:
- No changes
 drivers/video/mxsfb.c |   19 ++++++-------------
 1 file changed, 6 insertions(+), 13 deletions(-)

diff --git a/drivers/video/mxsfb.c b/drivers/video/mxsfb.c
index eac7c1a..c536887 100644
--- a/drivers/video/mxsfb.c
+++ b/drivers/video/mxsfb.c
@@ -42,7 +42,6 @@
 #include <linux/module.h>
 #include <linux/kernel.h>
 #include <linux/of_device.h>
-#include <linux/of_gpio.h>
 #include <video/of_display_timing.h>
 #include <linux/platform_device.h>
 #include <linux/clk.h>
@@ -51,6 +50,7 @@
 #include <linux/pinctrl/consumer.h>
 #include <linux/fb.h>
 #include <video/videomode.h>
+#include <linux/regulator/consumer.h>
 
 #define REG_SET	4
 #define REG_CLR	8
@@ -859,9 +859,8 @@ static int mxsfb_probe(struct platform_device *pdev)
 	struct fb_info *fb_info;
 	struct fb_modelist *modelist;
 	struct pinctrl *pinctrl;
-	int panel_enable;
-	enum of_gpio_flags flags;
 	int ret;
+	struct regulator *reg_lcd;
 
 	if (of_id)
 		pdev->id_entry = of_id->data;
@@ -904,18 +903,12 @@ static int mxsfb_probe(struct platform_device *pdev)
 		goto fb_release;
 	}
 
-	panel_enable = of_get_named_gpio_flags(pdev->dev.of_node,
-					       "panel-enable-gpios", 0, &flags);
-	if (gpio_is_valid(panel_enable)) {
-		unsigned long f = GPIOF_OUT_INIT_HIGH;
-		if (flags == OF_GPIO_ACTIVE_LOW)
-			f = GPIOF_OUT_INIT_LOW;
-		ret = devm_gpio_request_one(&pdev->dev, panel_enable,
-					    f, "panel-enable");
+	reg_lcd = devm_regulator_get(&pdev->dev, "lcd");
+	if (!IS_ERR(reg_lcd)) {
+		ret = regulator_enable(reg_lcd);
 		if (ret) {
 			dev_err(&pdev->dev,
-				"failed to request gpio %d: %d\n",
-				panel_enable, ret);
+				"Failed to enable lcd regulator: %d\n", ret);
 			goto fb_release;
 		}
 	}
-- 
1.7.9.5




From khilman at linaro.org  Thu Apr  4 13:31:00 2013
From: khilman at linaro.org (Kevin Hilman)
Date: Thu, 04 Apr 2013 10:31:00 -0700
Subject: [PATCH v2 08/18] ARM: OMAP5: PM: Add CPU power off in hotplug path
In-Reply-To: <515D7ECE.6040503@ti.com> (Santosh Shilimkar's message of "Thu, 4
 Apr 2013 18:53:26 +0530")
References: <1364205910-32392-1-git-send-email-santosh.shilimkar@ti.com>
 <1364205910-32392-9-git-send-email-santosh.shilimkar@ti.com>
 <876203uypd.fsf@linaro.org> <515D7ECE.6040503@ti.com>
Message-ID: <87vc82nqy3.fsf@linaro.org>

Santosh Shilimkar <santosh.shilimkar at ti.com> writes:

> On Thursday 04 April 2013 02:19 AM, Kevin Hilman wrote:
>> Santosh Shilimkar <santosh.shilimkar at ti.com> writes:
>> 
>>> Add power management code to handle the CPU off mode to enable CPUP hotplug
>>> mode for OMAP5 devices. Separate suspend finisher is used for OMAP5(Cortex-A15)
>>> because it doesn't use SCU power status register and external PL310 L2 cache
>>> which makes code flow bit different.
>>>
>>> Acked-by: Nishanth Menon <nm at ti.com>
>>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
>> 
>> [...]
>> 
>>> @@ -436,14 +445,21 @@ int __init omap4_mpuss_init(void)
>>>  
>>>  	if (cpu_is_omap44xx()) {
>>>  		omap_pm_ops.finish_suspend = omap4_finish_suspend;
>>> +		omap_pm_ops.hotplug_restart = omap_secondary_startup;
>>>  		omap_pm_ops.resume = omap4_cpu_resume;
>>>  		omap_pm_ops.scu_prepare = scu_pwrst_prepare;
>>>  		cpu_context_offset = OMAP4_RM_CPU0_CPU0_CONTEXT_OFFSET;
>>>  	} else if (soc_is_omap54xx()) {
>>> +		omap_pm_ops.finish_suspend = omap5_finish_suspend;
>>> +		omap_pm_ops.hotplug_restart = omap5_secondary_startup;
>>>  		cpu_context_offset = OMAP54XX_RM_CPU0_CPU0_CONTEXT_OFFSET;
>>>  		enable_mercury_retention_mode();
>>>  	}
>>>  
>>> +	/* Over-write the OMAP4 hook to take care of ROM BUG */
>>> +	if (cpu_is_omap446x())
>>> +		omap_pm_ops.hotplug_restart = omap_secondary_startup_4460;
>> 
>> A couple nits...
>> 
>> I think this would go better at the end of the 'if omap44xx' block
>> above.
>> 
> Nishant commented on this as well. The indentation was looking ugly
> and I thought its better to have this BUG hunk separate. I prefer
> it this way though if you really insist, i have to change it.

I insist.

>> Also, while you're hear, maybe it's time to rename the current secondary 
>> startup functions to match the new one.  IOW omap4_..., omap4460_... and omap5_...
>> 
> Good idea. Will do it in a separate patch since these have been there in few
> files.

OK.

Thanks,

Kevin


From khilman at linaro.org  Thu Apr  4 13:42:22 2013
From: khilman at linaro.org (Kevin Hilman)
Date: Thu, 04 Apr 2013 10:42:22 -0700
Subject: [PATCH v2 09/18] ARM: OMAP4+: PM: Restore CPU power state to ON
 with clockdomain force wakeup method
In-Reply-To: <515D8215.10705@ti.com> (Santosh Shilimkar's message of "Thu, 4
 Apr 2013 19:07:25 +0530")
References: <1364205910-32392-1-git-send-email-santosh.shilimkar@ti.com>
 <1364205910-32392-10-git-send-email-santosh.shilimkar@ti.com>
 <87mwtftjvy.fsf@linaro.org> <515D8215.10705@ti.com>
Message-ID: <87li8ynqf5.fsf@linaro.org>

Santosh Shilimkar <santosh.shilimkar at ti.com> writes:

> On Thursday 04 April 2013 02:24 AM, Kevin Hilman wrote:
>> Santosh Shilimkar <santosh.shilimkar at ti.com> writes:
>> 
>>> While waking up CPU from off state using clock domain force wakeup, restore
>>> the CPU power state to ON state before putting CPU clock domain under
>>> hardware control. Otherwise CPU wakeup might fail. The change is recommended
>>> for all OMAP4+ devices though the PRCM weakness was observed on OMAP5
>>> devices first.
>> 
>> Sounds reasonable, but can you describe the "weakness" a little more?
>> 
>> IOW, what exactly happens if this is not done?  It sounds like the CPU
>> might immediately go back to retention, but how does that happen unless
>> it does a WFI?
>> 
> Its more of lock-up inside the hardware state machine and results
> are UN-predictable. We have seen hard-locks most of the time where system
> is just frozen. The hardware gets into wrong state machine if the power
> domain state isn't restored. I will add this information to changelog.
>
>> Also, this sounds like a fix to me, and should probably be broken out
>> accordingly.
>> 
> Yeah. You mean a separate patch from the series, right ? This patch
> actually can be independently added.
>
> In case you decide to apply it for the fixes branch, updated patch
> at end of the email.

Curious which branch you applied it to?  It didn't apply cleanly to
v3.9-rc5 (but did with fuzz).

So I've now added it to my for_3.10/fixes/pm branch.

Kevin

> From a0cef44760d859b63a34603010f8c0621da4b8ab Mon Sep 17 00:00:00 2001
> From: Santosh Shilimkar <santosh.shilimkar at ti.com>
> Date: Fri, 8 Feb 2013 22:50:58 +0530
> Subject: [PATCH] ARM: OMAP4+: PM: Restore CPU power state to ON with
>  clockdomain force wakeup method
>
> While waking up CPU from off state using clock domain force wakeup, restore
> the CPU power state to ON state before putting CPU clock domain under
> hardware control. Otherwise CPU wakeup might fail. The change is recommended
> for all OMAP4+ devices though the PRCM weakness was observed on OMAP5
> devices first.
>
> As a result of weakness, lock-up is observed inside the hardware state
> machine of local CPU PRCM and results are UN-predictable as per designers.
> In software testing, we have seen hard-locks most of the time where system
> gets frozen. With power domain state restored, system behaves correctly.
>
> So update the code accordingly.
>
> Acked-by: Nishanth Menon <nm at ti.com>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
> ---
>  arch/arm/mach-omap2/cpuidle44xx.c |    1 +
>  arch/arm/mach-omap2/omap-smp.c    |   12 ++++++++++--
>  2 files changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/cpuidle44xx.c b/arch/arm/mach-omap2/cpuidle44xx.c
> index 944e64a..9de47a7 100644
> --- a/arch/arm/mach-omap2/cpuidle44xx.c
> +++ b/arch/arm/mach-omap2/cpuidle44xx.c
> @@ -131,6 +131,7 @@ static int omap4_enter_idle_coupled(struct cpuidle_device *dev,
>  	/* Wakeup CPU1 only if it is not offlined */
>  	if (dev->cpu == 0 && cpumask_test_cpu(1, cpu_online_mask)) {
>  		clkdm_wakeup(cpu_clkdm[1]);
> +		omap_set_pwrdm_state(cpu_pd[1], PWRDM_POWER_ON);
>  		clkdm_allow_idle(cpu_clkdm[1]);
>  	}
>  
> diff --git a/arch/arm/mach-omap2/omap-smp.c b/arch/arm/mach-omap2/omap-smp.c
> index 5b20165..8106e8d 100644
> --- a/arch/arm/mach-omap2/omap-smp.c
> +++ b/arch/arm/mach-omap2/omap-smp.c
> @@ -83,6 +83,7 @@ static int __cpuinit omap4_boot_secondary(unsigned int cpu, struct task_struct *
>  {
>  	static struct clockdomain *cpu1_clkdm;
>  	static bool booted;
> +	static struct powerdomain *cpu1_pwrdm;
>  	void __iomem *base = omap_get_wakeupgen_base();
>  
>  	/*
> @@ -102,8 +103,10 @@ static int __cpuinit omap4_boot_secondary(unsigned int cpu, struct task_struct *
>  	else
>  		__raw_writel(0x20, base + OMAP_AUX_CORE_BOOT_0);
>  
> -	if (!cpu1_clkdm)
> +	if (!cpu1_clkdm && !cpu1_pwrdm) {
>  		cpu1_clkdm = clkdm_lookup("mpu1_clkdm");
> +		cpu1_pwrdm = pwrdm_lookup("cpu1_pwrdm");
> +	}
>  
>  	/*
>  	 * The SGI(Software Generated Interrupts) are not wakeup capable
> @@ -116,7 +119,7 @@ static int __cpuinit omap4_boot_secondary(unsigned int cpu, struct task_struct *
>  	 * Section :
>  	 *	4.3.4.2 Power States of CPU0 and CPU1
>  	 */
> -	if (booted) {
> +	if (booted && cpu1_pwrdm && cpu1_clkdm) {
>  		/*
>  		 * GIC distributor control register has changed between
>  		 * CortexA9 r1pX and r2pX. The Control Register secure
> @@ -137,7 +140,12 @@ static int __cpuinit omap4_boot_secondary(unsigned int cpu, struct task_struct *
>  			gic_dist_disable();
>  		}
>  
> +		/*
> +		 * Ensure that CPU power state is set to ON to avoid CPU
> +		 * powerdomain transition on wfi
> +		 */
>  		clkdm_wakeup(cpu1_clkdm);
> +		omap_set_pwrdm_state(cpu1_pwrdm, PWRDM_POWER_ON);
>  		clkdm_allow_idle(cpu1_clkdm);
>  
>  		if (IS_PM44XX_ERRATUM(PM_OMAP4_ROM_SMP_BOOT_ERRATUM_GICD)) {


From pdeschrijver at nvidia.com  Thu Apr  4 13:52:06 2013
From: pdeschrijver at nvidia.com (Peter De Schrijver)
Date: Thu, 4 Apr 2013 20:52:06 +0300
Subject: [PATCH v7 00/12] Tegra114 clockframework
In-Reply-To: <20130219185034.27993.86892@quantum>
References: <1360931849-7090-1-git-send-email-pdeschrijver@nvidia.com>
 <5123C6E7.9070407@wwwdotorg.org>
 <20130219185034.27993.86892@quantum>
Message-ID: <20130404175206.GD18519@tbergstrom-lnx.Nvidia.com>

Hi Mike,

> Quoting Stephen Warren (2013-02-19 10:39:35)
> > On 02/15/2013 05:36 AM, Peter De Schrijver wrote:
> > > This is the seventh version of the Tegra114 clockframework. It is based on the
> > > for-next branch of
> > > git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra.git and
> > > http://www.spinics.net/lists/arm-kernel/msg220452.html.
> > 
> > Mike,
> > 
> > I think it'd be prudent to take this series through the Tegra tree again
> > for 3.10; patch 11 needs to go in as part of the series due to internal
> > dependencies, and I'm slightly worried that other Tegra DT changes might
> > conflict with that patch (if only for context). Taking this series (and
> > any other Tegra clk driver changes for 3.10) through the Tegra tree
> > could resolve that easily. Do you have a problem with that?
> > 
> 
> I was thinking the same thing.  I'll make time to review these now that
> 3.8 is out.
> 

I posted v9 of this yesterday (http://www.spinics.net/lists/linux-tegra/msg10891.html)
and posted a small binding doc update today 
'[PATCH v9b 10/14] ARM: tegra: Define Tegra114 CAR binding'. Can you ack these so
Stephen can take them in the Tegra tree?

Thanks!

Peter.


From khilman at linaro.org  Thu Apr  4 13:55:55 2013
From: khilman at linaro.org (Kevin Hilman)
Date: Thu, 04 Apr 2013 10:55:55 -0700
Subject: [PATCH v2 17/18] ARM: OMAP4+: CPUidle: Add OMAP5 idle driver
 support
In-Reply-To: <515D8B4B.6000800@ti.com> (Santosh Shilimkar's message of "Thu, 4
 Apr 2013 19:46:43 +0530")
References: <1364205910-32392-1-git-send-email-santosh.shilimkar@ti.com>
 <1364205910-32392-18-git-send-email-santosh.shilimkar@ti.com>
 <87fvz7qpce.fsf@linaro.org> <515D8B4B.6000800@ti.com>
Message-ID: <87li8ymb84.fsf@linaro.org>

Santosh Shilimkar <santosh.shilimkar at ti.com> writes:

> On Thursday 04 April 2013 02:55 AM, Kevin Hilman wrote:
>> Santosh Shilimkar <santosh.shilimkar at ti.com> writes:
>> 
>>> The OMAP5 idle driver can re-use OMAP4 CPUidle driver implementation thanks
>>> to compatible MPUSS design.
>>>
>>> Though unlike OMAP4, on OMAP5 devices, MPUSS CSWR (Close Switch
>>> Retention) power states can be achieved with respective power states
>>> on CPU0 and CPU1 power domain. This mode was broken on OMAP4 devices
>>> because of hardware limitation.
>> 
>> I'm a bit confused by the description here.
>> 
>> I gather from the code that this means that CPU0 and CPU1 can hit CSWR
>> independently, correct?
>> 
> They can be programmed independently without any ordering(like
> CPU0 last etc), but the actual transition to the low power CSWR
> happens together. Till that the first CPU hit WFI remains in WFI
> state waiting for other CPU to hit WFI and then both transition
> together.
> Completely managed inside hardware.

OK, elaborating this in the changelog would be helpful.  Use the "will I
understand this changelog in a year" rule to see if the changelog is
detailed enough.  Or better, "will Kevin understand this changelog in a
year."  (hint: the answer is usually no.)  ;)

>>> Also there is no CPU low power entry order requirement like
>>> master CPU etc for CSWR C-state, which is icing on the cake. 
>> 
>> Even on secure devices?
>> 
> Yes. On secure devices too. Actually since we don't loose context,
> secure entry/exit doesn't come into picture.
>
>>> Code makes use of voting scheme for cluster low power state to support
>>> MPUSS CSWR C-state.
>> 
>> The voting scheme and associated locking should be better described
>> here, or commented in the code itself.
>> 
> You are right. It deserves some description.
>
>>> Supported OMAP5 CPUidle C-states:
>>>         C1 - CPU0 ON(WFI) + CPU1 ON(WFI) + MPUSS ON
>>>         C2 - CPU0 CSWR + CPU1 CSWR + MPUSS CSWR
>>>         C3 - CPU0 OFF + CPU1 OFF + MPUSS OSWR
>>>
>>> Acked-by: Nishanth Menon <nm at ti.com>
>>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
>> 
>> [...]
>> 
>>> +static int omap_enter_idle_smp(struct cpuidle_device *dev,
>>> +			struct cpuidle_driver *drv,
>>> +			int index)
>>> +{
>>> +	struct idle_statedata *cx = state_ptr + index;
>>> +	int cpu_id = smp_processor_id();
>>> +	unsigned long flag;
>>> +
>>> +	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &cpu_id);
>> 
>> I think the CPUidle core handles the broadcast notification now.
>> 
> Not in mainline yet. And those patches came after my patches and
> I don't wanted un-necessary merge dependency, I avoided it. Its trivial
> though to drop if from here once the idle next is merged.

OK.

I believe that stuff is already queued, no?  Maybe ahave this as an
add-on separate patch that can be used for your loal testing, but does
not go upstream.

I would only include this if you're sure the other series is not going
upstream.

>>> +	raw_spin_lock_irqsave(&mpu_lock, flag);
>>> +	cx->mpu_state_vote++;
>> 
>> How about using an atomic_t and atomic_inc()/atomic_dec() instead, which
>> will avoid the need for a spinlock.
>> 
> Spin lock is not just for the vote variable. I had atomics opps in first
> version I gave it to product team. But they found a race condition in
> where MPU power state was getting overwritten by other CPU.
>
>> Even with that, it still seems potentially racy.  Do you need a memory
>> barrier here to be sure that any changes from another CPU are visible
>> here, and vice versa?
>> 
> With locks, you don't need barriers since the updated copy is guaranteed.

It's guaranteed because the spinlock implementation uses barriers. 

> Can you please elaborate on potential race ? I have given pretty hard
> thought and didn't see any race which can be exposed with locks in place.

I was referring to using atomic ops.  With atomic ops, you'd need an
explicit barrier (which you're getting inside the spinlock
implementation)

That being said, I have not thought through all the corner cases as you
have, so I'll defer to your choice (as long as it's well documented.)
If you decide to stick with spinlocks, be sure to describe all of what
the spinlock is protecting, and why.

Thanks,

Kevin


From khilman at linaro.org  Thu Apr  4 13:57:17 2013
From: khilman at linaro.org (Kevin Hilman)
Date: Thu, 04 Apr 2013 10:57:17 -0700
Subject: [PATCH v2 00/18] ARM: OMAP5: PM: Add MPUSS suspend and CPUidle
 support
In-Reply-To: <515DAF15.8000700@ti.com> (Santosh Shilimkar's message of "Thu, 4
 Apr 2013 22:19:25 +0530")
References: <1364205910-32392-1-git-send-email-santosh.shilimkar@ti.com>
 <87hajnp6ph.fsf@linaro.org> <515D8F60.1080603@ti.com>
 <515DAF15.8000700@ti.com>
Message-ID: <87eheqmb5u.fsf@linaro.org>

Santosh Shilimkar <santosh.shilimkar at ti.com> writes:

> On Thursday 04 April 2013 08:04 PM, Santosh Shilimkar wrote:
>> On Thursday 04 April 2013 04:22 AM, Kevin Hilman wrote:
>>> Hi Santosh,
>>>
>>> Santosh Shilimkar <santosh.shilimkar at ti.com> writes:
>>>
>>>> Here is the refreshed version(v2) of the OMAP5 PM suspport which was posted
>>>> earlier (March 1st 2013). Patch-set incorporates comments from Nishant
>>>> Menon (Thanks for review NM) and his acked-by tags. I would like to get this
>>>> queued for 3.10 merge window if you are ok with the series.
>>>
>>> I did a review of this series with several comments on the individual
>>> patches.  
>>>
>> Thanks a lot Kevin. I have addressed all the comments and have
>> updated patches ready.
>> 
>>> I've already queued most of the CPUidle fixes/cleanups in my
>>> for_3.10/cleanup/cpuidle branch and will get that to Tony soon.  For the
>>> rest, I suggest probably breaking it up into cleanup/consolidation stuff
>>> and then OMAP5 support.  The latter will depend on all the OMAP5
>>> data/headers but the cleanup/consolidation stuff could be merged sooner
>>> (but probably a bit late for v3.10 now.)
>>>
>> I have already split the patch-set into 'consolidation' and 'OMAP5
>> support' since it was straight forward. Need to just build the
>> branches on top of your branches. So waiting for you to update
>> your 'for_3.10/*' branches.
>> 
>> For the merge, its your call:)
>> As you said OMAP5 support(couple of patches) has a dependency
>> on OMAP5 data files. I will at least make the branches ready on
>> top of yours.
>> 
> After looking at your tree, looks like the branches are already
> there. Idle branch name is not for_3.10/fixes/cpuidle though :)

oh, sorry.  I changed it to 'cleanup'.

> So I created 'for_3.10/omap_pm-cleanup' and 'for_3.10/omap5_pm_v2'
> and pushed on my git tree [1] in case you would like to have
> a look. I briefly tested them on OMAP4 device with
> CPUidle enabled and they seems to work fine. Will do OMAP5
> testing tomorrow and then post the updated patches on list.

Perfect, thanks.

Kevin



From jon-hunter at ti.com  Thu Apr  4 14:06:30 2013
From: jon-hunter at ti.com (Jon Hunter)
Date: Thu, 4 Apr 2013 13:06:30 -0500
Subject: [PATCH] ARM: dts: OMAP4+: Correct L3 interrupts
Message-ID: <1365098790-9078-1-git-send-email-jon-hunter@ti.com>

The L3 interrupt numbers are incorrect for OMAP4+ and are conflicting
with some of the timer interrupts causing the allocation of timer
interrupts to fail.

The problem is caused by adding 32 to the interrupt number for the L3
interrupts to account for per processor interrupts (PPI) and software
generated interrupts (SGI) which typically are mapped to the first 32
interrupts in the ARM GIC. This is not necessary because the first
parameter of the ARM GIC interrupt property specifies the GIC interrupt
type (ie. SGI, PPI, etc). Hence, fix the interrupt number fo the L3
interrupts by substracting 32.

Cc: Santosh Shilimkar <santosh.shilimkar at ti.com>
Signed-off-by: Jon Hunter <jon-hunter at ti.com>
---

Please note that this problem is observed in Benoit's for_3.10/dts branch [1].

[1] http://git.kernel.org/cgit/linux/kernel/git/bcousson/linux-omap-dt.git

 arch/arm/boot/dts/omap4.dtsi |    4 ++--
 arch/arm/boot/dts/omap5.dtsi |    4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 3329140..3ae6a3f 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -97,8 +97,8 @@
 		reg = <0x44000000 0x1000>,
 		      <0x44800000 0x2000>,
 		      <0x45000000 0x1000>;
-		interrupts = <0 41 0x4>,
-			     <0 42 0x4>;
+		interrupts = <0 9 0x4>,
+			     <0 10 0x4>;
 
 		counter32k: counter at 4a304000 {
 			compatible = "ti,omap-counter32k";
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index f4c71d9..86f784e 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -90,8 +90,8 @@
 		reg = <0x44000000 0x2000>,
 		      <0x44800000 0x3000>,
 		      <0x45000000 0x4000>;
-		interrupts = <0 41 0x4>,
-			     <0 42 0x4>;
+		interrupts = <0 9 0x4>,
+			     <0 10 0x4>;
 
 		counter32k: counter at 4ae04000 {
 			compatible = "ti,omap-counter32k";
-- 
1.7.10.4



From fabio.estevam at freescale.com  Thu Apr  4 14:05:29 2013
From: fabio.estevam at freescale.com (Fabio Estevam)
Date: Thu, 4 Apr 2013 15:05:29 -0300
Subject: [PATCH] ARM: dts: imx28-evk: Fix the ethernet regulator name
Message-ID: <1365098729-21933-1-git-send-email-fabio.estevam@freescale.com>

FEC driver looks for "phy" as the regulator-name:

reg_phy = devm_regulator_get(&pdev->dev, "phy");

So adjust it properly.

Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
---
 arch/arm/boot/dts/imx28-evk.dts |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/imx28-evk.dts b/arch/arm/boot/dts/imx28-evk.dts
index c886e9a..fad5ed7 100644
--- a/arch/arm/boot/dts/imx28-evk.dts
+++ b/arch/arm/boot/dts/imx28-evk.dts
@@ -286,7 +286,7 @@
 
 		reg_fec_3v3: fec-3v3 {
 			compatible = "regulator-fixed";
-			regulator-name = "fec-3v3";
+			regulator-name = "phy";
 			regulator-min-microvolt = <3300000>;
 			regulator-max-microvolt = <3300000>;
 			gpio = <&gpio2 15 0>;
-- 
1.7.9.5




From swarren at wwwdotorg.org  Thu Apr  4 14:15:54 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Thu, 04 Apr 2013 12:15:54 -0600
Subject: [PATCH] clk: tegra: Fix cdev1 and cdev2 IDs
In-Reply-To: <1365066304-2327-1-git-send-email-pgaikwad@nvidia.com>
References: <1365066304-2327-1-git-send-email-pgaikwad@nvidia.com>
Message-ID: <515DC35A.4030301@wwwdotorg.org>

On 04/04/2013 03:05 AM, Prashant Gaikwad wrote:
> Correct IDs for cdev1 and cdev2 are 94 and 93 respectively.

This looks OK, but needs to be split up before I can apply it.

The binding change and driver changes will be applied to Tegra's
for-3.10/clk branch, since that's where clk changes are going.

The DT changes will be applied to Tegra's for-3.10/dt branch, since
that's where most of the DT content that's being edited here was
actually added, this kernel cycle.

There's no dependency between these two sets of changes, since the
clocks properties for the sound and USB PHY nodes aren't actually used
by the drivers yet; they're just being added this kernel cycle to avoid
dependencies in the next kernel version.

Mike, can you please ack this patch anyway, and I'll repost later in the
day when I get around to splitting it up and applying it. Thanks.


From swarren at wwwdotorg.org  Thu Apr  4 14:18:59 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Thu, 04 Apr 2013 12:18:59 -0600
Subject: [PATCH] clk: tegra: Add missing cdev1 and cdev2 clocks
In-Reply-To: <1365066333-2361-1-git-send-email-pgaikwad@nvidia.com>
References: <1365066333-2361-1-git-send-email-pgaikwad@nvidia.com>
Message-ID: <515DC413.8050600@wwwdotorg.org>

On 04/04/2013 03:05 AM, Prashant Gaikwad wrote:
> Register cdev1 and cdev2 peripheral clocks.

Can you please explain the relationship between the following clocks:

cdev1
extern1
clk_out1

The latter two clocks already exist in this driver. I think that
clk_out1 is meant to represent cdev1 already, although it's set up to
point at some PMC registers, rather than the CAR CLK_ENB registers.


From swarren at wwwdotorg.org  Thu Apr  4 14:20:35 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Thu, 04 Apr 2013 12:20:35 -0600
Subject: [PATCH] clk: tegra: Use common of_clk_init() function
In-Reply-To: <1365066351-2395-1-git-send-email-pgaikwad@nvidia.com>
References: <1365066351-2395-1-git-send-email-pgaikwad@nvidia.com>
Message-ID: <515DC473.8000104@wwwdotorg.org>

On 04/04/2013 03:05 AM, Prashant Gaikwad wrote:
> Use common of_clk_init() function for clocks initialization.
> 
> Signed-off-by: Prashant Gaikwad <pgaikwad at nvidia.com>
> ---
> 
> Stephen, if T114 clock series is not going to make in 3.10 then I would
> like Mike to take this patch. If T114 clock series makes it then I have
> to rebase this patch on top of it.

I'm still just hopeful that it the Tegra114 support can get into 3.10;
all I'm waiting on is Mike's ack to apply it. Let's hold off on this
patch until after that. Thanks.


From tony at atomide.com  Thu Apr  4 14:24:50 2013
From: tony at atomide.com (Tony Lindgren)
Date: Thu, 4 Apr 2013 11:24:50 -0700
Subject: [GIT PULL] ARM: OMAP2+: GPMC updates
In-Reply-To: <515CE38B.3080400@ti.com>
References: <515B0D92.6070503@ti.com> <20130403214036.GD10155@atomide.com>
 <515CE38B.3080400@ti.com>
Message-ID: <20130404182447.GN10155@atomide.com>

* Jon Hunter <jon-hunter at ti.com> [130403 19:25]:
> 
> On 04/03/2013 04:40 PM, Tony Lindgren wrote:
> > * Jon Hunter <jon-hunter at ti.com> [130402 10:00]:
> >> The following changes since commit dca3a783400a18e2bf4503b1d4a85c4d0ca1a7e4:
> >>
> >>   Merge commit '31d9adca82ce65e5c99d045b5fd917c702b6fce3' into tmp (2013-04-01 14:33:50 -0500)
> >>
> >> are available in the git repository at:
> >>
> >>
> >>   git://github.com/jonhunter/linux.git omap-gpmc-for-v3.10
> >>
> >> for you to fetch changes up to c67bd6e7cad2160c3bbfa2ac2bd954f918301c23:
> >>
> >>   ARM: OMAP2+: Add GPMC DT support for Ethernet child nodes (2013-04-01 14:53:50 -0500)
> >>
> >> ----------------------------------------------------------------
> >> Adds GPMC DT support for NOR flash and Ethernet and includes
> >> various GPMC cleans-up and fixes.
> >>
> >> This series is dependent on commit 7185684 (ARM: OMAP: use
> >> consistent error checking) from RMK's clean-up branch and commit
> >> 31d9adc (ARM: OMAP2+: Fix broken gpmc support).
> > 
> > Looks good except it adds a new warning:
> > 
> > arch/arm/mach-omap2/gpmc.c: In function ?gpmc_read_timings_dt?:
> > arch/arm/mach-omap2/gpmc.c:1324: warning: ?p? may be used uninitialized in this function
> > 
> > Can you please take a look?
> 
> No problem. I did not see get this warning, but I believe that 
> there is a bug that needed to be fixed. Can you try the below?

Thanks yes that works. Pulling into omap-for-v3.10/gpmc.

Regards,

Tony


From tony at atomide.com  Thu Apr  4 14:38:55 2013
From: tony at atomide.com (Tony Lindgren)
Date: Thu, 4 Apr 2013 11:38:55 -0700
Subject: [PATCH 0/5] ARM: OMAP: DMTIMER updates for v3.10
In-Reply-To: <1363714699-29622-1-git-send-email-jon-hunter@ti.com>
References: <1363714699-29622-1-git-send-email-jon-hunter@ti.com>
Message-ID: <20130404183855.GP10155@atomide.com>

* Jon Hunter <jon-hunter at ti.com> [130319 10:42]:
> Includes:
> - A couple fixes for DMTIMER context loss handling.
> - Populating DMTIMER errata when booting with device-tree.
> - A new function for requesting a DMTIMER by device-tree node.
> 
> Based upon v3.9-rc3.
> 
> Tested on OMAP5912 OSK, OMAP2420 H4, OMAP3430 SDP, OMAP4430 Blaze
> and AM335x EVM. Testing includes ...
> 1. Booting kernel on above boards
> 2. Testing of various DMTIMER request APIs
> 3. Testing the timer overflow and match interrupts.
> 4. Using different clock sources to operate the timer with.
> 
> Jon Hunter (4):
>   ARM: OMAP: Force dmtimer restore if context loss is not detectable
>   ARM: OMAP: Add function to request timer by node
>   ARM: dts: OMAP2+: Update DMTIMER compatibility property
>   ARM: OMAP2+: Populate DMTIMER errata when using device-tree
> 
> NeilBrown (1):
>   ARM: OMAP: Simplify dmtimer context-loss handling
> 
>  .../devicetree/bindings/arm/omap/timer.txt         |   17 +-
>  arch/arm/boot/dts/am33xx.dtsi                      |   14 +-
>  arch/arm/boot/dts/omap2.dtsi                       |   22 +-
>  arch/arm/boot/dts/omap2420.dtsi                    |    2 +-
>  arch/arm/boot/dts/omap2430.dtsi                    |    2 +-
>  arch/arm/boot/dts/omap3.dtsi                       |   24 +-
>  arch/arm/boot/dts/omap4.dtsi                       |   22 +-
>  arch/arm/boot/dts/omap5.dtsi                       |   22 +-
>  arch/arm/mach-omap2/timer.c                        |    7 +-
>  arch/arm/plat-omap/dmtimer.c                       |  241 ++++++++++++--------
>  arch/arm/plat-omap/include/plat/dmtimer.h          |    1 +
>  11 files changed, 220 insertions(+), 154 deletions(-)

For all these it sounds like it's best that Benoit queues
them with the .dts changes:

Acked-by: Tony Lindgren <tony at atomide.com>


From shc_work at mail.ru  Thu Apr  4 14:54:32 2013
From: shc_work at mail.ru (=?UTF-8?B?QWxleGFuZGVyIFNoaXlhbg==?=)
Date: Thu, 04 Apr 2013 22:54:32 +0400
Subject: =?UTF-8?B?UmVbMl06IFtQQVRDSCA0LzRdIEFSTTogczNjMjR4eDogRml4IHN3aXRjaGlu?=
 =?UTF-8?B?ZyBGSUZPIGluIGFyY2hfZW5hYmxlX3VhcnRfZmlmbyBmdW5jdGlvbg==?=
References: <1362216174-10478-1-git-send-email-shc_work@mail.ru>
 <1362216174-10478-4-git-send-email-shc_work@mail.ru>
Message-ID: <1365101672.722585953@f87.mail.ru>

Hello.

> Alexander Shiyan wrote:
> > 
> > When CONFIG_S3C_BOOT_UART_FORCE_FIFO symbol is set, we should
> > enable FIFO but actually switch command is missing in the code.
> > This patch adds this switch.
> > 
> > Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
> > ---
> >  arch/arm/plat-samsung/include/plat/uncompress.h | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/arch/arm/plat-samsung/include/plat/uncompress.h
> > b/arch/arm/plat-samsung/include/plat/uncompress.h
> > index 438b248..30fedd9 100644
> > --- a/arch/arm/plat-samsung/include/plat/uncompress.h
> > +++ b/arch/arm/plat-samsung/include/plat/uncompress.h
> > @@ -130,6 +130,8 @@ static inline void arch_enable_uart_fifo(void)
> >  			if (!(fifocon & S3C2410_UFCON_RESETBOTH))
> >  				break;
> >  		}
> > +
> > +		uart_wr(S3C2410_UFCON, S3C2410_UFCON_FIFOMODE);
> 
> Well, I think, if required, this should be moved into 'if (!(fifocon &
> S3C2410_UFCON_FIFOMODE))'.

Already here.

---

From sergei.shtylyov at cogentembedded.com  Thu Apr  4 14:53:50 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Thu, 4 Apr 2013 22:53:50 +0400
Subject: [PATCH v2 1/2] ARM: shmobile: R8A7779: add Ether support
Message-ID: <201304042253.50662.sergei.shtylyov@cogentembedded.com>

Add Ether clock and platform device for R8A7779 SoC; add a function to register
this device with board-specific platform data.

Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

---
This patch is atop of the 'renesas-next-20130404v2' tag of Simon Horman's
'renesas.git'.

Changes since original posting:
- use 'struct sh_eth_plat_data *' as an argument to r8a7779_add_ether_device();
- use platform_device_register_resndata() in r8a7779_add_ether_device().

 arch/arm/mach-shmobile/clock-r8a7779.c        |    4 +++-
 arch/arm/mach-shmobile/include/mach/r8a7779.h |    2 ++
 arch/arm/mach-shmobile/setup-r8a7779.c        |   23 ++++++++++++++++++++++-
 3 files changed, 27 insertions(+), 2 deletions(-)

Index: renesas/arch/arm/mach-shmobile/clock-r8a7779.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/clock-r8a7779.c
+++ renesas/arch/arm/mach-shmobile/clock-r8a7779.c
@@ -112,7 +112,7 @@ static struct clk *main_clks[] = {
 };
 
 enum { MSTP323, MSTP322, MSTP321, MSTP320,
-	MSTP115,
+	MSTP115, MSTP114,
 	MSTP103, MSTP101, MSTP100,
 	MSTP030,
 	MSTP029, MSTP028, MSTP027, MSTP026, MSTP025, MSTP024, MSTP023, MSTP022, MSTP021,
@@ -126,6 +126,7 @@ static struct clk mstp_clks[MSTP_NR] = {
 	[MSTP321] = SH_CLK_MSTP32(&clkp_clk, MSTPCR3, 21, 0), /* SDHI2 */
 	[MSTP320] = SH_CLK_MSTP32(&clkp_clk, MSTPCR3, 20, 0), /* SDHI3 */
 	[MSTP115] = SH_CLK_MSTP32(&clkp_clk, MSTPCR1, 15, 0), /* SATA */
+	[MSTP114] = SH_CLK_MSTP32(&clkp_clk, MSTPCR1, 14, 0), /* Ether */
 	[MSTP103] = SH_CLK_MSTP32(&clks_clk, MSTPCR1,  3, 0), /* DU */
 	[MSTP101] = SH_CLK_MSTP32(&clkp_clk, MSTPCR1,  1, 0), /* USB2 */
 	[MSTP100] = SH_CLK_MSTP32(&clkp_clk, MSTPCR1,  0, 0), /* USB0/1 */
@@ -162,6 +163,7 @@ static struct clk_lookup lookups[] = {
 	/* MSTP32 clocks */
 	CLKDEV_DEV_ID("sata_rcar", &mstp_clks[MSTP115]), /* SATA */
 	CLKDEV_DEV_ID("fc600000.sata", &mstp_clks[MSTP115]), /* SATA w/DT */
+	CLKDEV_DEV_ID("sh-eth", &mstp_clks[MSTP114]), /* Ether */
 	CLKDEV_DEV_ID("ehci-platform.1", &mstp_clks[MSTP101]), /* USB EHCI port2 */
 	CLKDEV_DEV_ID("ohci-platform.1", &mstp_clks[MSTP101]), /* USB OHCI port2 */
 	CLKDEV_DEV_ID("ehci-platform.0", &mstp_clks[MSTP100]), /* USB EHCI port0/1 */
Index: renesas/arch/arm/mach-shmobile/include/mach/r8a7779.h
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/include/mach/r8a7779.h
+++ renesas/arch/arm/mach-shmobile/include/mach/r8a7779.h
@@ -3,6 +3,7 @@
 
 #include <linux/sh_clk.h>
 #include <linux/pm_domain.h>
+#include <linux/sh_eth.h>
 
 struct platform_device;
 
@@ -31,6 +32,7 @@ extern void r8a7779_earlytimer_init(void
 extern void r8a7779_add_early_devices(void);
 extern void r8a7779_add_standard_devices(void);
 extern void r8a7779_add_standard_devices_dt(void);
+extern void r8a7779_add_ether_device(struct sh_eth_plat_data *pdata);
 extern void r8a7779_clock_init(void);
 extern void r8a7779_pinmux_init(void);
 extern void r8a7779_pm_init(void);
Index: renesas/arch/arm/mach-shmobile/setup-r8a7779.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/setup-r8a7779.c
+++ renesas/arch/arm/mach-shmobile/setup-r8a7779.c
@@ -1,8 +1,9 @@
 /*
  * r8a7779 processor support
  *
- * Copyright (C) 2011  Renesas Solutions Corp.
+ * Copyright (C) 2011, 2013  Renesas Solutions Corp.
  * Copyright (C) 2011  Magnus Damm
+ * Copyright (C) 2013  Cogent Embedded, Inc.
  *
  * 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
@@ -393,6 +394,18 @@ static struct platform_device sata_devic
 	},
 };
 
+/* Ether */
+static struct resource ether_resources[] = {
+	{
+		.start	= 0xfde00000,
+		.end	= 0xfde003ff,
+		.flags	= IORESOURCE_MEM,
+	}, {
+		.start	= gic_iid(0xb4),
+		.flags	= IORESOURCE_IRQ,
+	},
+};
+
 static struct platform_device *r8a7779_devices_dt[] __initdata = {
 	&scif0_device,
 	&scif1_device,
@@ -428,6 +441,14 @@ void __init r8a7779_add_standard_devices
 			    ARRAY_SIZE(r8a7779_late_devices));
 }
 
+void __init r8a7779_add_ether_device(struct sh_eth_plat_data *pdata)
+{
+	platform_device_register_resndata(&platform_bus, "sh_eth", -1,
+					  ether_resources,
+					  ARRAY_SIZE(ether_resources),
+					  pdata, sizeof(*pdata));
+}
+
 /* do nothing for !CONFIG_SMP or !CONFIG_HAVE_TWD */
 void __init __weak r8a7779_register_twd(void) { }
 


From sergei.shtylyov at cogentembedded.com  Thu Apr  4 14:55:46 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Thu, 4 Apr 2013 22:55:46 +0400
Subject: [PATCH v2 2/2] ARM: shmobile: R8A7778: add Ether support
Message-ID: <201304042255.46986.sergei.shtylyov@cogentembedded.com>

Add Ether clock and platform device for R8A7778 SoC; add a function to register
this device with board-specific platform data.

Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

---
This patch is atop of the 'renesas-next-20130404v2' tag of Simon Horman's
'renesas.git'.

Changes since original posting:
- use 'struct sh_eth_plat_data *' as an argument to r8a7778_add_ether_device();
- use platform_device_register_resndata() in r8a7778_add_ether_device().

 arch/arm/mach-shmobile/clock-r8a7778.c        |    3 +++
 arch/arm/mach-shmobile/include/mach/r8a7778.h |    3 +++
 arch/arm/mach-shmobile/setup-r8a7778.c        |   15 +++++++++++++++
 3 files changed, 21 insertions(+)

Index: renesas/arch/arm/mach-shmobile/clock-r8a7778.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/clock-r8a7778.c
+++ renesas/arch/arm/mach-shmobile/clock-r8a7778.c
@@ -58,11 +58,13 @@ static struct clk *main_clks[] = {
 };
 
 enum {
+	MSTP114,
 	MSTP026, MSTP025, MSTP024, MSTP023, MSTP022, MSTP021,
 	MSTP016, MSTP015,
 	MSTP_NR };
 
 static struct clk mstp_clks[MSTP_NR] = {
+	[MSTP114] = SH_CLK_MSTP32(&clkp, MSTPCR1, 14, 0), /* Ether */
 	[MSTP026] = SH_CLK_MSTP32(&clkp, MSTPCR0, 26, 0), /* SCIF0 */
 	[MSTP025] = SH_CLK_MSTP32(&clkp, MSTPCR0, 25, 0), /* SCIF1 */
 	[MSTP024] = SH_CLK_MSTP32(&clkp, MSTPCR0, 24, 0), /* SCIF2 */
@@ -75,6 +77,7 @@ static struct clk mstp_clks[MSTP_NR] = {
 
 static struct clk_lookup lookups[] = {
 	/* MSTP32 clocks */
+	CLKDEV_DEV_ID("sh-eth",	&mstp_clks[MSTP114]), /* Ether */
 	CLKDEV_DEV_ID("sh-sci.0", &mstp_clks[MSTP026]), /* SCIF0 */
 	CLKDEV_DEV_ID("sh-sci.1", &mstp_clks[MSTP025]), /* SCIF1 */
 	CLKDEV_DEV_ID("sh-sci.2", &mstp_clks[MSTP024]), /* SCIF2 */
Index: renesas/arch/arm/mach-shmobile/include/mach/r8a7778.h
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/include/mach/r8a7778.h
+++ renesas/arch/arm/mach-shmobile/include/mach/r8a7778.h
@@ -18,8 +18,11 @@
 #ifndef __ASM_R8A7778_H__
 #define __ASM_R8A7778_H__
 
+#include <linux/sh_eth.h>
+
 extern void r8a7778_add_standard_devices(void);
 extern void r8a7778_add_standard_devices_dt(void);
+extern void r8a7778_add_ether_device(struct sh_eth_plat_data *pdata);
 extern void r8a7778_init_delay(void);
 extern void r8a7778_init_irq(void);
 extern void r8a7778_init_irq_dt(void);
Index: renesas/arch/arm/mach-shmobile/setup-r8a7778.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/setup-r8a7778.c
+++ renesas/arch/arm/mach-shmobile/setup-r8a7778.c
@@ -3,6 +3,7 @@
  *
  * Copyright (C) 2013  Renesas Solutions Corp.
  * Copyright (C) 2013  Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
+ * Copyright (C) 2013  Cogent Embedded, Inc.
  *
  * 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
@@ -79,6 +80,12 @@ static struct sh_timer_config sh_tmu1_pl
 	.clocksource_rating	= 200,
 };
 
+/* Ether */
+static struct resource ether_resources[] = {
+	DEFINE_RES_MEM(0xfde00000, 0x400),
+	DEFINE_RES_IRQ(gic_iid(0x89)),
+};
+
 #define r8a7778_register_tmu(idx)			\
 	platform_device_register_resndata(		\
 		&platform_bus, "sh_tmu", idx,		\
@@ -111,6 +118,14 @@ void __init r8a7778_add_standard_devices
 	r8a7778_register_tmu(1);
 }
 
+void __init r8a7778_add_ether_device(struct sh_eth_plat_data *pdata)
+{
+	platform_device_register_resndata(&platform_bus, "sh_eth", -1,
+					  ether_resources,
+					  ARRAY_SIZE(ether_resources),
+					  pdata, sizeof(*pdata));
+}
+
 static struct renesas_intc_irqpin_config irqpin_platform_data = {
 	.irq_base = irq_pin(0), /* IRQ0 -> IRQ3 */
 	.sense_bitfield_width = 2,


From dgilbert at interlog.com  Thu Apr  4 15:14:14 2013
From: dgilbert at interlog.com (Douglas Gilbert)
Date: Thu, 04 Apr 2013 15:14:14 -0400
Subject: [PATCH] rtc: rtc-at91sam9.c add DT support
In-Reply-To: <515D8944.2060308@atmel.com>
References: <515CF985.6050009@interlog.com> <515D35C2.7050405@atmel.com>
 <515D7F56.90702@interlog.com> <515D8944.2060308@atmel.com>
Message-ID: <515DD106.1090603@interlog.com>

On 13-04-04 10:08 AM, Nicolas Ferre wrote:
> On 04/04/2013 03:25 PM, Douglas Gilbert :
>> On 13-04-04 04:11 AM, Nicolas Ferre wrote:
>>> On 04/04/2013 05:54 AM, Douglas Gilbert :
>>>> Some members of the at91 SoCs use the Real Time Timer (RTT)
>>>> and the General Purpose Backup Registers (GPBR) to implement
>>>> a real time clock (RTC). The AT91SAM9G20 is one example.
>>>>
>>>> Attached is a patch to add DT support to rtc-at91sam9.c .
>>>> The patch is against lk 3.9.0-rc5 .
>>>>
>>>> Below is a snippet of DT code for the 'G20 that was observed
>>>> to work with this patch:
>>>>
>>>> ahb {
>>>>       apb {
>>>>
>>>>           rtc {
>>>>               compatible = "atmel,at91sam9-rtc";
>>>
>>> The compatible string has to be formed by the name of the first SoC
>>> compatible with this IP. It turns to be the at91sam9260.
>>> The second part of the string should be a name that reflects the nature
>>> of the peripheral. For this binding, I would like to mention the "RTT"
>>> in the compatibility string (because other drivers can use other RTT
>>> with other uses).
>>>
>>> What do you think about:
>>> "atmel,at91sam9260-rtt-as-rtc"? or something shorter?
>>
>> Hi Nicolas,
>> Johan Hovold suggested:
>>     atmel,at91sam9260-rtt
>
> Yes, but I fear this could bring confusion if someone is building a RTT
> driver that is not targeted at acting as a RTC...
>
>> I notice (in the G20 doco) that the acronym RTTC is also used
>
> The "C" at the end stands for "Controller" (not very useful convention
> in my opinion).
>
>> for the rtt registers. What do you want?
>
> I found xxx-rtt-as-rtc or xxx-rtt-rtc but not completely satisfied with
> any of them...
>
>>>>                            /* RTTC followed by GPBR (backup registers) */
>>>>                            reg = <0xfffffd20 0x10>, <0xfffffd50 0x10>;
>>>>                            interrupts = <1 4 7>;
>>>>                            status = "okay";
>>>
>>> Last, but not least, when we add a DT binding, it is a requirement to
>>> add the corresponding documentation in the
>>> Documentation/devicetree/bindings/rtc/ directory.
>>
>> I have been underwhelmed by the accuracy and the organisation
>> of information in that documentation. And the examples are
>> often misleading given the actual hierarchy of real dtsi/dts
>> config files.
>
> Oh, really? I will have a look one of those days...
>
>
>> Give me working examples any day. You could (and should) test
>> what I gave on a g20ek board.
>>
>> Also I note there is no "bindings" documentation for
>> rtc-at91rm9200.c :-) After you, sir ....
>
> Already submitted, my dear ;-)
> Here:
> http://ozlabs.org/~akpm/mmots/broken-out/drivers-rtc-rtc-at91rm9200c-add-dt-support.patch

Good.

On a more serious note, looking at a dts file for working
hardware is useful _but_ it is not clear how a kernel should
be configured to fully utilize that dts file. Without a
defconfig a user may need to resort to several searches like
this:

   find <kernel_src> -name '*.c' -exec grep "atmel,at91sam9x5-rtc" {} \; -print

which is non-obvious to the novice. After a line like
that, the Makefile in that directory may need to be checked
to find out which CONFIG_ option needs to be set to get
the associated driver built in (or a module?). So is there
a policy _not_ to place "compat" strings in Kconfig files
where they might be searchable?

The "bindings" documentation and DT incantations are all
for nought if the associated driver is not configured.
Looking at the dmesg output is futile.

Doug Gilbert




From ulf.hansson at linaro.org  Thu Apr  4 15:28:06 2013
From: ulf.hansson at linaro.org (Ulf Hansson)
Date: Thu, 4 Apr 2013 21:28:06 +0200
Subject: [PATCH V4 3/3] clk: Fixup locking issues for clk_set_parent
In-Reply-To: <CA+Z25wWi7S1fcTmhs=63sOVbzjN9q8rtNJF67eNCLT70YZpPFw@mail.gmail.com>
References: <1364936979-20805-1-git-send-email-ulf.hansson@stericsson.com>
 <1364936979-20805-4-git-send-email-ulf.hansson@stericsson.com>
 <CA+Z25wWi7S1fcTmhs=63sOVbzjN9q8rtNJF67eNCLT70YZpPFw@mail.gmail.com>
Message-ID: <CAPDyKFq-R5u-cJruacApi3ZKfaQDshgCpdstTTMWgmg9fH4N3Q@mail.gmail.com>

On 4 April 2013 12:35, Rajagopal Venkat <rajagopal.venkat at linaro.org> wrote:
> On 3 April 2013 02:39, Ulf Hansson <ulf.hansson at stericsson.com> wrote:
>> From: Ulf Hansson <ulf.hansson at linaro.org>
>>
>> Updating the clock tree topology must be protected with the spinlock
>> when doing clk_set_parent, otherwise we can not handle the migration
>> of the enable_count in a safe manner.
>
> Why is not safe to update tree topology with no spinlock?

clk_enable|disable propagates upwards in the tree. While in the middle
of changing parents, you could end up in operating on more than one
parent. This must be prevented and is done by holding the enable lock.

>
>>
>> While issuing the .set_parent callback to make the clk-hw perform the
>> switch to the new parent, we can not hold the spinlock since it is must
>> be allowed to be slow path. This complicates error handling, but is still
>> possible to achieve.
>>
>> Signed-off-by: Ulf Hansson <ulf.hansson at linaro.org>
>> Cc: Rajagopal Venkat <rajagopal.venkat at linaro.org>
>> ---
>>  drivers/clk/clk.c |   67 +++++++++++++++++++++++++++++++++++++++++------------
>>  1 file changed, 52 insertions(+), 15 deletions(-)
>>
>> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
>> index c83e8e5..de6b459 100644
>> --- a/drivers/clk/clk.c
>> +++ b/drivers/clk/clk.c
>> @@ -1363,31 +1363,71 @@ static int __clk_set_parent(struct clk *clk, struct clk *parent, u8 p_index)
>>         unsigned long flags;
>>         int ret = 0;
>>         struct clk *old_parent = clk->parent;
>> +       bool migrated_enable = false;
>>
>> -       /* migrate prepare and enable */
>> +       /* migrate prepare */
>>         if (clk->prepare_count)
>>                 __clk_prepare(parent);
>>
>> -       /* FIXME replace with clk_is_enabled(clk) someday */
>>         flags = clk_enable_lock();
>> -       if (clk->enable_count)
>> +
>> +       /* migrate enable */
>> +       if (clk->enable_count) {
>>                 __clk_enable(parent);
>> +               migrated_enable = true;
>> +       }
>> +
>> +       /* update the clk tree topology */
>> +       clk_reparent(clk, parent);
>> +
>>         clk_enable_unlock(flags);
>>
>>         /* change clock input source */
>>         if (parent && clk->ops->set_parent)
>>                 ret = clk->ops->set_parent(clk->hw, p_index);
>>
>> -       /* clean up old prepare and enable */
>> -       flags = clk_enable_lock();
>> -       if (clk->enable_count)
>> +       if (ret) {
>> +               /*
>> +                * The error handling is tricky due to that we need to release
>> +                * the spinlock while issuing the .set_parent callback. This
>> +                * means the new parent might have been enabled/disabled in
>
> But then new parent is reference counted with  __clk_enable(parent)
> isn't it? Even if other children are disabling newparent, it is still
> alive. Am I missing anything here?

Since we have released and later fetched the enable_lock, the clk
might very well have been enabled|disabled in between. Thus we can not
solely trust the enable count.

If we have migrated the enable, we need to keep track of this so we
can roll back that change.

>
>> +                * between, which must be considered when doing rollback.
>> +                */
>> +               flags = clk_enable_lock();
>> +
>> +               clk_reparent(clk, old_parent);
>> +
>> +               if (migrated_enable && clk->enable_count) {
>> +                       __clk_disable(parent);
>> +               } else if (migrated_enable && (clk->enable_count == 0)) {
>
> Will this condition happen at all? the reference counting should
> prevent this AFAICT. Can this error path be simplified?

I am trying to handle the scenarios described below. If you think we
can simplify error handling please advise me, I know the code looks a
bit tricky.

Scenario 1 (migration done):

1. Fetch enable_lock.
2. clk->enable_count is > 0, so we decide to migrate it for the new parent.
3. Update clock tree topology.
4. Release enable_lock.

5 a. A client does clk_disable(clk) and clk->enable_count reaches 0.
Then a reference to the new parent will also be decreased.
5 b. A client does clk_enable(clk) so clk->enable_count is still > 0.
This means no reference change is propagated to the new parent.

6.  clk->ops->set_parent fails, we need error handling.
- If 5a, we need to decrease a reference for the old parent to reflect
that clk->enable_count has reached 0.
- If 5b, we need to revert the increased reference count for the new parent.


Scenario 2 (no migration):

1. Fetch enable_lock.
2. clk->enable_count is 0, so no migration done.
3. Update clock tree topology.
4. Release enable_lock.

5. A client does clk_enable(clk) so clk->enable_count is > 0.  Then a
reference to the new parent will also be increased.

6.  clk->ops->set_parent fails, we need error handling.
- We need to revert the reference change on the new parent and instead
transfer it to the old parent.

>
>> +                       __clk_disable(old_parent);
>> +               } else if (!migrated_enable && clk->enable_count) {
>> +                       __clk_disable(parent);
>> +                       __clk_enable(old_parent);
>> +               }
>> +
>> +               clk_enable_unlock(flags);
>> +
>> +               if (clk->prepare_count)
>> +                       __clk_unprepare(parent);
>> +
>> +               return ret;
>> +       }
>> +
>> +       /* clean up enable for old parent if migration was done */
>> +       if (migrated_enable) {
>
> Reaching here, the old_parent should be disabled in any case. Is this
> 'if (migrated_enable)' check required?

Why is it disabled?

Where did we decrease a reference to it?

>
>> +               flags = clk_enable_lock();
>>                 __clk_disable(old_parent);
>> -       clk_enable_unlock(flags);
>> +               clk_enable_unlock(flags);
>> +       }
>>
>> +       /* clean up prepare for old parent if migration was done */
>>         if (clk->prepare_count)
>>                 __clk_unprepare(old_parent);
>>
>> -       return ret;
>> +       /* update debugfs with new clk tree topology */
>> +       clk_debug_reparent(clk, parent);
>> +       return 0;
>>  }
>>
>>  /**
>> @@ -1450,14 +1490,11 @@ int clk_set_parent(struct clk *clk, struct clk *parent)
>>         /* do the re-parent */
>>         ret = __clk_set_parent(clk, parent, p_index);
>>
>> -       /* propagate ABORT_RATE_CHANGE if .set_parent failed */
>> -       if (ret) {
>> +       /* propagate rate recalculation accordingly */
>> +       if (ret)
>>                 __clk_recalc_rates(clk, ABORT_RATE_CHANGE);
>> -               goto out;
>> -       }
>> -
>> -       /* propagate rate recalculation downstream */
>> -       __clk_reparent(clk, parent);
>> +       else
>> +               __clk_recalc_rates(clk, POST_RATE_CHANGE);
>>
>>  out:
>>         clk_prepare_unlock();
>> --
>> 1.7.10
>>
>
>
>
> --
> Regards,
> Rajagopal

Kind regards
Ulf Hansson


From tony at atomide.com  Thu Apr  4 15:39:54 2013
From: tony at atomide.com (Tony Lindgren)
Date: Thu, 4 Apr 2013 12:39:54 -0700
Subject: [GIT PULL 1/3] omap usb platform init changes for v3.10 merge window
Message-ID: <pull-1365104396-577667>

The following changes since commit 1f0972f5b05a674d73e4eb314fa1b6c78e37aef1:

  usb: phy: nop: Add some parameters to platform data (2013-03-18 11:13:54 +0200)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.10/usb-signed

for you to fetch changes up to 2e5f78aeceb6f203b514ca03a48e3fd056025524:

  ARM: dts: omap3-beagle: Add USB Host support (2013-04-02 10:00:04 -0700)

----------------------------------------------------------------
EHCI platform data related changes for v3.10 merge window.
These are needed for the USB PHY support, and are based on
commit 1f0972f5 from Felipe Balbi's tree as agreed on the
mailing lists.

----------------------------------------------------------------
Roger Quadros (20):
      ARM: OMAP2+: omap-usb-host: Add usbhs_init_phys()
      ARM: OMAP2+: omap4panda: Adapt to ehci-omap changes
      ARM: OMAP3: Beagle: Adapt to ehci-omap changes
      ARM: OMAP3: 3430SDP: Adapt to ehci-omap changes
      ARM: OMAP3: 3630SDP: Adapt to ehci-omap changes
      ARM: OMAP: AM3517crane: Adapt to ehci-omap changes
      ARM: OMAP: AM3517evm: Adapt to ehci-omap changes
      ARM: OMAP3: cm-t35: Adapt to ehci-omap changes
      ARM: OMAP3: cm-t3517: Adapt to ehci-omap changes
      ARM: OMAP: devkit8000: Adapt to ehci-omap changes
      ARM: OMAP3: igep0020: Adapt to ehci-omap changes
      ARM: OMAP3: omap3evm: Adapt to ehci-omap changes
      ARM: OMAP3: omap3pandora: Adapt to ehci-omap changes
      ARM: OMAP3: omap3stalker: Adapt to ehci-omap changes
      ARM: OMAP3: omap3touchbook: Adapt to ehci-omap changes
      ARM: OMAP3: overo: Adapt to ehci-omap changes
      ARM: OMAP: zoom: Adapt to ehci-omap changes
      ARM: dts: OMAP4: Add HS USB Host IP nodes
      ARM: dts: OMAP3: Add HS USB Host IP nodes
      ARM: dts: omap3-beagle: Add USB Host support

 arch/arm/boot/dts/omap3-beagle.dts         |  71 +++++++++++++
 arch/arm/boot/dts/omap3.dtsi               |  31 ++++++
 arch/arm/boot/dts/omap4.dtsi               |  30 ++++++
 arch/arm/mach-omap2/board-3430sdp.c        |  21 ++--
 arch/arm/mach-omap2/board-3630sdp.c        |  21 ++--
 arch/arm/mach-omap2/board-am3517crane.c    |  24 ++---
 arch/arm/mach-omap2/board-am3517evm.c      |  17 +--
 arch/arm/mach-omap2/board-cm-t35.c         |  20 ++--
 arch/arm/mach-omap2/board-cm-t3517.c       |  20 ++--
 arch/arm/mach-omap2/board-devkit8000.c     |   8 --
 arch/arm/mach-omap2/board-igep0020.c       |  32 +++---
 arch/arm/mach-omap2/board-omap3beagle.c    |  32 ++++--
 arch/arm/mach-omap2/board-omap3evm.c       |  25 ++---
 arch/arm/mach-omap2/board-omap3pandora.c   |  21 ++--
 arch/arm/mach-omap2/board-omap3stalker.c   |  17 +--
 arch/arm/mach-omap2/board-omap3touchbook.c |  17 +--
 arch/arm/mach-omap2/board-omap4panda.c     |  55 ++++------
 arch/arm/mach-omap2/board-overo.c          |  16 +--
 arch/arm/mach-omap2/board-zoom.c           |  16 +--
 arch/arm/mach-omap2/usb-host.c             | 160 ++++++++++++++++++++++++++++-
 arch/arm/mach-omap2/usb.h                  |   9 ++
 21 files changed, 503 insertions(+), 160 deletions(-)


From tony at atomide.com  Thu Apr  4 15:39:55 2013
From: tony at atomide.com (Tony Lindgren)
Date: Thu, 4 Apr 2013 12:39:55 -0700
Subject: [GIT PULL 2/3] omap timer changes for v3.10 merge window
In-Reply-To: <pull-1365104396-577667>
Message-ID: <mailman.6.1365104409.1198.linux-arm-kernel@lists.infradead.org>

The following changes since commit 43231b5be657fde1c4ced180d829bbd59ceef9ad:

  Merge commit '7185684' into omap-for-v3.10/timer (2013-04-03 10:32:47 -0700)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.10/timer-signed

for you to fetch changes up to 7f585bbfc54fec9dcf387fd2edb2d6f4908badf8:

  Merge branch 'omap-timer-for-v3.10' of git://github.com/jonhunter/linux into omap-for-v3.10/timer (2013-04-03 10:47:59 -0700)

----------------------------------------------------------------

Clean-up for omap2+ timers from Jon Hunter <jon-hunter at ti.com>:

This series consists mainly of clean-ups for clockevents and
clocksource timers on OMAP2+ devices. The most significant change
in functionality comes from the 5th patch which is changing the
selection of the clocksource timer for OMAP3 and AM335x devices
when gptimers are used for clocksource.

Note that this series depends on 7185684 (ARM: OMAP: use
consistent error checking) in RMK's tree and 960cba6 (ARM:
OMAP5: timer: Update the clocksource name as per clock data)
in omap-for-v3.10/fixes-non-critical. So this branch is based
on a merge of 7185684 and omap-for-v3.10/fixes-non-critical
to avoid non-trivial merge conflicts.

----------------------------------------------------------------
Jon Hunter (8):
      Merge commit '6bb27d7349db51b50c40534710fe164ca0d58902' into omap-timer-for-v3.10
      ARM: OMAP2+: Display correct system timer name
      ARM: OMAP2+: Remove hard-coded test on timer ID
      ARM: OMAP2+: Simplify system timer clock definitions
      ARM: OMAP2+: Simplify system timers definitions
      ARM: OMAP3: Update clocksource timer selection
      ARM: OMAP2+: Store ID of system timers in timer structure
      ARM: OMAP4+: Fix sparse warning in system timers

Tony Lindgren (1):
      Merge branch 'omap-timer-for-v3.10' of git://github.com/jonhunter/linux into omap-for-v3.10/timer

 arch/arm/mach-omap2/board-cm-t3517.c |   2 +-
 arch/arm/mach-omap2/board-generic.c  |   2 +-
 arch/arm/mach-omap2/common.h         |   3 +-
 arch/arm/mach-omap2/timer.c          | 124 ++++++++++++++++++-----------------
 4 files changed, 66 insertions(+), 65 deletions(-)


From tony at atomide.com  Thu Apr  4 15:39:56 2013
From: tony at atomide.com (Tony Lindgren)
Date: Thu, 4 Apr 2013 12:39:56 -0700
Subject: [GIT PULL 3/3] omap gpmc changes for v3.10 merge window
In-Reply-To: <pull-1365104396-577667>
Message-ID: <mailman.7.1365104412.1198.linux-arm-kernel@lists.infradead.org>

The following changes since commit dca3a783400a18e2bf4503b1d4a85c4d0ca1a7e4:

  Merge commit '31d9adca82ce65e5c99d045b5fd917c702b6fce3' into tmp (2013-04-01 14:33:50 -0500)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.10/gpmc-signed

for you to fetch changes up to aecb65a34a780cd07fbaa652cc5d640f13f3ed5f:

  Merge branch 'omap-gpmc-for-v3.10-take2' of git://github.com/jonhunter/linux into omap-for-v3.10/gpmc (2013-04-04 11:22:33 -0700)

----------------------------------------------------------------

GPMC updates from Jon Hunter <jon-hunter at ti.com>:

Adds GPMC (General Purpose Memory Controller) DT support for
NOR flash and Ethernet and includes various GPMC cleans-up
and fixes.

This series is dependent on commit 7185684 (ARM: OMAP: use
consistent error checking) from RMK's clean-up branch and commit
31d9adc (ARM: OMAP2+: Fix broken gpmc support).

----------------------------------------------------------------
Ezequiel Garcia (8):
      ARM: omap2: gpmc: Mark local scoped functions static
      ARM: omap2: gpmc: Remove unused gpmc_round_ns_to_ticks() function
      ARM: omap2: gpmc: Fix gpmc_cs_reserved() return value
      ARM: omap2: gpmc-nand: Print something useful on CS request failure
      ARM: omap2: gpmc-onenand: Print something useful on CS request failure
      ARM: omap2: gpmc-onenand: Replace pr_err() with dev_err()
      ARM: omap2: gpmc-onenand: Replace printk KERN_ERR with dev_warn()
      ARM: omap2: gpmc: Remove redundant chip select out of range check

Javier Martinez Canillas (3):
      ARM: OMAP2+: return -ENODEV if GPMC child device creation fails
      ARM: OMAP2+: rename gpmc_probe_nor_child() to gpmc_probe_generic_child()
      ARM: OMAP2+: Add GPMC DT support for Ethernet child nodes

Jon Hunter (17):
      ARM: OMAP2+: Simplify code configuring ONENAND devices
      ARM: OMAP2+: Add variable to store number of GPMC waitpins
      ARM: OMAP2+: Add structure for storing GPMC settings
      ARM: OMAP2+: Add function for configuring GPMC settings
      ARM: OMAP2+: Convert ONENAND to use gpmc_cs_program_settings()
      ARM: OMAP2+: Convert NAND to use gpmc_cs_program_settings()
      ARM: OMAP2+: Convert SMC91x to use gpmc_cs_program_settings()
      ARM: OMAP2+: Convert TUSB to use gpmc_cs_program_settings()
      ARM: OMAP2+: Don't configure of chip-select options in gpmc_cs_configure()
      ARM: OMAP2+: Add function to read GPMC settings from device-tree
      ARM: OMAP2+: Add additional GPMC timing parameters
      ARM: OMAP2+: Add device-tree support for NOR flash
      ARM: OMAP2+: Convert NAND to retrieve GPMC settings from DT
      ARM: OMAP2+: Convert ONENAND to retrieve GPMC settings from DT
      ARM: OMAP2+: Detect incorrectly aligned GPMC base address
      ARM: OMAP2+: Remove unnecesssary GPMC definitions and variable
      ARM: OMAP2+: Allow GPMC probe to complete even if CS mapping fails

Mark Jackson (1):
      ARM: OMAP: Clear GPMC bits when applying new setting.

Tony Lindgren (1):
      Merge branch 'omap-gpmc-for-v3.10-take2' of git://github.com/jonhunter/linux into omap-for-v3.10/gpmc

 Documentation/devicetree/bindings/bus/ti-gpmc.txt  | 103 ++--
 Documentation/devicetree/bindings/mtd/gpmc-nor.txt |  98 ++++
 .../devicetree/bindings/mtd/gpmc-onenand.txt       |   3 +
 Documentation/devicetree/bindings/net/gpmc-eth.txt |  97 ++++
 arch/arm/mach-omap2/gpmc-nand.c                    |  42 +-
 arch/arm/mach-omap2/gpmc-onenand.c                 | 118 ++---
 arch/arm/mach-omap2/gpmc-smc91x.c                  |  30 +-
 arch/arm/mach-omap2/gpmc.c                         | 544 +++++++++++++++------
 arch/arm/mach-omap2/gpmc.h                         |  43 +-
 arch/arm/mach-omap2/usb-tusb6010.c                 |  62 ++-
 10 files changed, 831 insertions(+), 309 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/mtd/gpmc-nor.txt
 create mode 100644 Documentation/devicetree/bindings/net/gpmc-eth.txt


From wad at chromium.org  Thu Apr  4 15:58:46 2013
From: wad at chromium.org (Will Drewry)
Date: Thu, 4 Apr 2013 14:58:46 -0500
Subject: [PATCH V2 1/3] seccomp: add generic code for jitted seccomp
 filters.
In-Reply-To: <CAGXu5j+jpXrcLDyAV+p81pjapaQeKQTMz4+JXjKj03DV-yoC=w@mail.gmail.com>
References: <1363618233-6375-1-git-send-email-nschichan@freebox.fr>
 <1363618233-6375-2-git-send-email-nschichan@freebox.fr>
 <CAGXu5j+jpXrcLDyAV+p81pjapaQeKQTMz4+JXjKj03DV-yoC=w@mail.gmail.com>
Message-ID: <CABqD9hZp7FiQjvLrauV1rkUqgXZyCxmbOKA+6rzpDNEEfJ0NPw@mail.gmail.com>

On Mon, Apr 1, 2013 at 4:53 PM, Kees Cook <keescook at chromium.org> wrote:
> On Mon, Mar 18, 2013 at 7:50 AM, Nicolas Schichan <nschichan at freebox.fr> wrote:
>> Architecture must select HAVE_SECCOMP_FILTER_JIT and implement
>> seccomp_jit_compile() and seccomp_jit_free() if they intend to support
>> jitted seccomp filters.
>>
>> struct seccomp_filter has been moved to <linux/seccomp.h> to make its
>> content available to the jit compilation code.
>>
>> In a way similar to the net BPF, the jit compilation code is expected
>> to updates struct seccomp_filter.bpf_func pointer to the generated
>> code.
>>
>> Signed-off-by: Nicolas Schichan <nschichan at freebox.fr>
>
> Acked-by: Kees Cook <keescook at chromium.org>
>
> I'd love to see this for x86 too. I suspect it'd be a small change
> after this series lands.

Agreed - and thanks for working through the necessary changes!

Acked-By: Will Drewry <wad at chromium.org>
(for the series)


From jon-hunter at ti.com  Thu Apr  4 16:16:11 2013
From: jon-hunter at ti.com (Jon Hunter)
Date: Thu, 4 Apr 2013 15:16:11 -0500
Subject: [PATCH 0/5] gpio/omap: 2nd batch of updates for v3.10
Message-ID: <1365106576-31816-1-git-send-email-jon-hunter@ti.com>

Main change is ensuring that the state of a gpio bank is restored when
booting with device-tree. The rest of the patches are clean-ups and one
optimisation.

The patch modifying the *.dtsi files should go via Benoit Cousson's
for_3.10/dts branch [1] as it is dependent on changes in his branch but
I have included here for completeness.

Testing includes:
- Boot testing on OMAP5912 OSK, OMAP2420 H4, OMAP3430 SDP, OMAP4430 SDP
  and AM335x EVM.
- Verified that GPIO interrupts are working on OMAP5912 OSK, OMAP2420 H4,
  OMAP3430 SDP and OMAP4430 SDP by making sure networking was working
  correctly as these boards use a GPIO with the ethernet chips. Also
  checked /proc/interrupts to ensure GPIO interrupt counts are
  incrementing as expected.

[1] http://git.kernel.org/cgit/linux/kernel/git/bcousson/linux-omap-dt.git

Jon Hunter (4):
  gpio/omap: free irq domain in probe() failure paths
  gpio/omap: optimise interrupt service routine
  gpio/omap: force restore if context loss is not detectable
  ARM: dts: OMAP2+: Identify GPIO banks that are always powered

Tarun Kanti DebBarma (1):
  gpio/omap: remove extra context restores in *_runtime_resume()

 .../devicetree/bindings/gpio/gpio-omap.txt         |    7 ++-
 arch/arm/boot/dts/omap2420.dtsi                    |    4 ++
 arch/arm/boot/dts/omap2430.dtsi                    |    4 ++
 arch/arm/boot/dts/omap3.dtsi                       |    1 +
 arch/arm/boot/dts/omap4.dtsi                       |    1 +
 arch/arm/boot/dts/omap5.dtsi                       |    1 +
 drivers/gpio/gpio-omap.c                           |   49 +++++++++++---------
 7 files changed, 44 insertions(+), 23 deletions(-)

-- 
1.7.10.4



From jon-hunter at ti.com  Thu Apr  4 16:16:12 2013
From: jon-hunter at ti.com (Jon Hunter)
Date: Thu, 4 Apr 2013 15:16:12 -0500
Subject: [PATCH 1/5] gpio/omap: free irq domain in probe() failure paths
In-Reply-To: <1365106576-31816-1-git-send-email-jon-hunter@ti.com>
References: <1365106576-31816-1-git-send-email-jon-hunter@ti.com>
Message-ID: <1365106576-31816-2-git-send-email-jon-hunter@ti.com>

Currently the IRQ domain is not freed once allocated, in the case where
omap_gpio_probe() fails. Therefore, ensure we free the domain if the
probe does fail. Furthermore, the local variable "ret" is not needed
and so remove this.

Signed-off-by: Jon Hunter <jon-hunter at ti.com>
---
 drivers/gpio/gpio-omap.c |    6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 0d30c7a..1e666c8 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -1094,7 +1094,6 @@ static int omap_gpio_probe(struct platform_device *pdev)
 	const struct omap_gpio_platform_data *pdata;
 	struct resource *res;
 	struct gpio_bank *bank;
-	int ret = 0;
 
 	match = of_match_device(of_match_ptr(omap_gpio_match), dev);
 
@@ -1143,18 +1142,21 @@ static int omap_gpio_probe(struct platform_device *pdev)
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 	if (unlikely(!res)) {
 		dev_err(dev, "Invalid mem resource\n");
+		irq_domain_remove(bank->domain);
 		return -ENODEV;
 	}
 
 	if (!devm_request_mem_region(dev, res->start, resource_size(res),
 				     pdev->name)) {
 		dev_err(dev, "Region already claimed\n");
+		irq_domain_remove(bank->domain);
 		return -EBUSY;
 	}
 
 	bank->base = devm_ioremap(dev, res->start, resource_size(res));
 	if (!bank->base) {
 		dev_err(dev, "Could not ioremap\n");
+		irq_domain_remove(bank->domain);
 		return -ENOMEM;
 	}
 
@@ -1178,7 +1180,7 @@ static int omap_gpio_probe(struct platform_device *pdev)
 
 	list_add_tail(&bank->node, &omap_gpio_list);
 
-	return ret;
+	return 0;
 }
 
 #ifdef CONFIG_ARCH_OMAP2PLUS
-- 
1.7.10.4



From jon-hunter at ti.com  Thu Apr  4 16:16:13 2013
From: jon-hunter at ti.com (Jon Hunter)
Date: Thu, 4 Apr 2013 15:16:13 -0500
Subject: [PATCH 2/5] gpio/omap: remove extra context restores in
 *_runtime_resume()
In-Reply-To: <1365106576-31816-1-git-send-email-jon-hunter@ti.com>
References: <1365106576-31816-1-git-send-email-jon-hunter@ti.com>
Message-ID: <1365106576-31816-3-git-send-email-jon-hunter@ti.com>

From: Tarun Kanti DebBarma <tarun.kanti at ti.com>

68942edb09f69b6e09522d1d346665eb3aadde49 (gpio/omap: fix wakeups
on level-triggered GPIOs) already restores the fallingdetect and
risingdetect contexts in *_runtime_resume(). These registers were
modified in *_runtime_suspend() to include even those configured
as level-triggered since only edge-triggered gpios can generate
wakeup events. Therefore, the old context restores of the same
registers present later in the code is not needed any more.
Remove them.

Signed-off-by: Tarun Kanti DebBarma <tarun.kanti at ti.com>
Signed-off-by: Jon Hunter <jon-hunter at ti.com>
---
 drivers/gpio/gpio-omap.c |    4 ----
 1 file changed, 4 deletions(-)

diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 1e666c8..5af7acd 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -1292,10 +1292,6 @@ static int omap_gpio_runtime_resume(struct device *dev)
 		return 0;
 	}
 
-	__raw_writel(bank->context.fallingdetect,
-			bank->base + bank->regs->fallingdetect);
-	__raw_writel(bank->context.risingdetect,
-			bank->base + bank->regs->risingdetect);
 	l = __raw_readl(bank->base + bank->regs->datain);
 
 	/*
-- 
1.7.10.4



From jon-hunter at ti.com  Thu Apr  4 16:16:15 2013
From: jon-hunter at ti.com (Jon Hunter)
Date: Thu, 4 Apr 2013 15:16:15 -0500
Subject: [PATCH 4/5] gpio/omap: force restore if context loss is not detectable
In-Reply-To: <1365106576-31816-1-git-send-email-jon-hunter@ti.com>
References: <1365106576-31816-1-git-send-email-jon-hunter@ti.com>
Message-ID: <1365106576-31816-5-git-send-email-jon-hunter@ti.com>

When booting with device-tree the function pointer for detecting context
loss is not populated. Ideally, the pm_runtime framework should be
enhanced to allow a means for reporting context/state loss and we could
avoid populating such function pointers altogether. In the interim until
a generic non-device specific solution is in place, force a restore of
the gpio bank when enabling the gpio controller.

Adds a new device-tree property for the OMAP GPIO controller to indicate
if the GPIO controller is located in a power-domain that never loses
power and hence will always maintain its logic state.

Signed-off-by: Jon Hunter <jon-hunter at ti.com>
---
 .../devicetree/bindings/gpio/gpio-omap.txt         |    7 ++++--
 drivers/gpio/gpio-omap.c                           |   25 +++++++++++++-------
 2 files changed, 22 insertions(+), 10 deletions(-)

diff --git a/Documentation/devicetree/bindings/gpio/gpio-omap.txt b/Documentation/devicetree/bindings/gpio/gpio-omap.txt
index a56e3a5..8d95052 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-omap.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio-omap.txt
@@ -20,8 +20,11 @@ Required properties:
       8 = active low level-sensitive.
 
 OMAP specific properties:
-- ti,hwmods: Name of the hwmod associated to the GPIO:
-  "gpio<X>", <X> being the 1-based instance number from the HW spec
+- ti,hwmods:		Name of the hwmod associated to the GPIO:
+			"gpio<X>", <X> being the 1-based instance number
+			from the HW spec.
+- ti,gpio-always-on: 	Indicates if a GPIO bank is always powered and
+			so will never lose its logic state.
 
 
 Example:
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 685e850..0557529 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -1120,11 +1120,17 @@ static int omap_gpio_probe(struct platform_device *pdev)
 	bank->width = pdata->bank_width;
 	bank->is_mpuio = pdata->is_mpuio;
 	bank->non_wakeup_gpios = pdata->non_wakeup_gpios;
-	bank->loses_context = pdata->loses_context;
 	bank->regs = pdata->regs;
 #ifdef CONFIG_OF_GPIO
 	bank->chip.of_node = of_node_get(node);
 #endif
+	if (node) {
+		if (!of_property_read_bool(node, "ti,gpio-always-on"))
+			bank->loses_context = true;
+	} else {
+		bank->loses_context = pdata->loses_context;
+	}
+
 
 	bank->domain = irq_domain_add_linear(node, bank->width,
 					     &irq_domain_simple_ops, NULL);
@@ -1258,9 +1264,9 @@ static int omap_gpio_runtime_resume(struct device *dev)
 {
 	struct platform_device *pdev = to_platform_device(dev);
 	struct gpio_bank *bank = platform_get_drvdata(pdev);
-	int context_lost_cnt_after;
 	u32 l = 0, gen, gen0, gen1;
 	unsigned long flags;
+	int c;
 
 	spin_lock_irqsave(&bank->lock, flags);
 	_gpio_dbck_enable(bank);
@@ -1276,14 +1282,17 @@ static int omap_gpio_runtime_resume(struct device *dev)
 	__raw_writel(bank->context.risingdetect,
 		     bank->base + bank->regs->risingdetect);
 
-	if (bank->get_context_loss_count) {
-		context_lost_cnt_after =
-			bank->get_context_loss_count(bank->dev);
-		if (context_lost_cnt_after != bank->context_loss_count) {
+	if (bank->loses_context) {
+		if (!bank->get_context_loss_count) {
 			omap_gpio_restore_context(bank);
 		} else {
-			spin_unlock_irqrestore(&bank->lock, flags);
-			return 0;
+			c = bank->get_context_loss_count(bank->dev);
+			if (c != bank->context_loss_count) {
+				omap_gpio_restore_context(bank);
+			} else {
+				spin_unlock_irqrestore(&bank->lock, flags);
+				return 0;
+			}
 		}
 	}
 
-- 
1.7.10.4



From jon-hunter at ti.com  Thu Apr  4 16:16:14 2013
From: jon-hunter at ti.com (Jon Hunter)
Date: Thu, 4 Apr 2013 15:16:14 -0500
Subject: [PATCH 3/5] gpio/omap: optimise interrupt service routine
In-Reply-To: <1365106576-31816-1-git-send-email-jon-hunter@ti.com>
References: <1365106576-31816-1-git-send-email-jon-hunter@ti.com>
Message-ID: <1365106576-31816-4-git-send-email-jon-hunter@ti.com>

The OMAP GPIO interrupt service routine is checking each bit in the
GPIO interrupt status register to see which bits are set. It is not
efficient to check every bit especially if only a few bits are set.
Therefore, instead of checking every bit use the __ffs() function,
which returns the location of the first set bit, to find all the set
bits.

This optimisation was suggested-by and developed in collaboration
with Felipe Balbi.

Cc: Felipe Balbi <balbi at ti.com>

Signed-off-by: Jon Hunter <jon-hunter at ti.com>
---
 drivers/gpio/gpio-omap.c |   14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 5af7acd..685e850 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -689,7 +689,7 @@ static void gpio_irq_handler(unsigned int irq, struct irq_desc *desc)
 {
 	void __iomem *isr_reg = NULL;
 	u32 isr;
-	unsigned int i;
+	unsigned int bit;
 	struct gpio_bank *bank;
 	int unmasked = 0;
 	struct irq_chip *chip = irq_desc_get_chip(desc);
@@ -730,9 +730,9 @@ static void gpio_irq_handler(unsigned int irq, struct irq_desc *desc)
 		if (!isr)
 			break;
 
-		for (i = 0; isr != 0; isr >>= 1, i++) {
-			if (!(isr & 1))
-				continue;
+		while (isr) {
+			bit = __ffs(isr);
+			isr &= ~(1 << bit);
 
 			/*
 			 * Some chips can't respond to both rising and falling
@@ -741,10 +741,10 @@ static void gpio_irq_handler(unsigned int irq, struct irq_desc *desc)
 			 * to respond to the IRQ for the opposite direction.
 			 * This will be indicated in the bank toggle_mask.
 			 */
-			if (bank->toggle_mask & (1 << i))
-				_toggle_gpio_edge_triggering(bank, i);
+			if (bank->toggle_mask & (1 << bit))
+				_toggle_gpio_edge_triggering(bank, bit);
 
-			generic_handle_irq(irq_find_mapping(bank->domain, i));
+			generic_handle_irq(irq_find_mapping(bank->domain, bit));
 		}
 	}
 	/* if bank has any level sensitive GPIO pin interrupt
-- 
1.7.10.4



From jon-hunter at ti.com  Thu Apr  4 16:16:16 2013
From: jon-hunter at ti.com (Jon Hunter)
Date: Thu, 4 Apr 2013 15:16:16 -0500
Subject: [PATCH 5/5] ARM: dts: OMAP2+: Identify GPIO banks that are always
 powered
In-Reply-To: <1365106576-31816-1-git-send-email-jon-hunter@ti.com>
References: <1365106576-31816-1-git-send-email-jon-hunter@ti.com>
Message-ID: <1365106576-31816-6-git-send-email-jon-hunter@ti.com>

Add the "ti,gpio-always-on" property to the appropriate GPIO banks to
indicate which banks are always powered and will never lose logic state.

Cc: Benoit Cousson <b-cousson at ti.com>
Signed-off-by: Jon Hunter <jon-hunter at ti.com>
---
 arch/arm/boot/dts/omap2420.dtsi |    4 ++++
 arch/arm/boot/dts/omap2430.dtsi |    4 ++++
 arch/arm/boot/dts/omap3.dtsi    |    1 +
 arch/arm/boot/dts/omap4.dtsi    |    1 +
 arch/arm/boot/dts/omap5.dtsi    |    1 +
 5 files changed, 11 insertions(+)

diff --git a/arch/arm/boot/dts/omap2420.dtsi b/arch/arm/boot/dts/omap2420.dtsi
index 455b239..76446ff 100644
--- a/arch/arm/boot/dts/omap2420.dtsi
+++ b/arch/arm/boot/dts/omap2420.dtsi
@@ -34,6 +34,7 @@
 			reg = <0x48018000 0x200>;
 			interrupts = <29>;
 			ti,hwmods = "gpio1";
+			ti,gpio-always-on;
 			#gpio-cells = <2>;
 			gpio-controller;
 			#interrupt-cells = <2>;
@@ -45,6 +46,7 @@
 			reg = <0x4801a000 0x200>;
 			interrupts = <30>;
 			ti,hwmods = "gpio2";
+			ti,gpio-always-on;
 			#gpio-cells = <2>;
 			gpio-controller;
 			#interrupt-cells = <2>;
@@ -56,6 +58,7 @@
 			reg = <0x4801c000 0x200>;
 			interrupts = <31>;
 			ti,hwmods = "gpio3";
+			ti,gpio-always-on;
 			#gpio-cells = <2>;
 			gpio-controller;
 			#interrupt-cells = <2>;
@@ -67,6 +70,7 @@
 			reg = <0x4801e000 0x200>;
 			interrupts = <32>;
 			ti,hwmods = "gpio4";
+			ti,gpio-always-on;
 			#gpio-cells = <2>;
 			gpio-controller;
 			#interrupt-cells = <2>;
diff --git a/arch/arm/boot/dts/omap2430.dtsi b/arch/arm/boot/dts/omap2430.dtsi
index 477b120..ca2c4a3 100644
--- a/arch/arm/boot/dts/omap2430.dtsi
+++ b/arch/arm/boot/dts/omap2430.dtsi
@@ -34,6 +34,7 @@
 			reg = <0x4900c000 0x200>;
 			interrupts = <29>;
 			ti,hwmods = "gpio1";
+			ti,gpio-always-on;
 			#gpio-cells = <2>;
 			gpio-controller;
 			#interrupt-cells = <2>;
@@ -45,6 +46,7 @@
 			reg = <0x4900e000 0x200>;
 			interrupts = <30>;
 			ti,hwmods = "gpio2";
+			ti,gpio-always-on;
 			#gpio-cells = <2>;
 			gpio-controller;
 			#interrupt-cells = <2>;
@@ -56,6 +58,7 @@
 			reg = <0x49010000 0x200>;
 			interrupts = <31>;
 			ti,hwmods = "gpio3";
+			ti,gpio-always-on;
 			#gpio-cells = <2>;
 			gpio-controller;
 			#interrupt-cells = <2>;
@@ -67,6 +70,7 @@
 			reg = <0x49012000 0x200>;
 			interrupts = <32>;
 			ti,hwmods = "gpio4";
+			ti,gpio-always-on;
 			#gpio-cells = <2>;
 			gpio-controller;
 			#interrupt-cells = <2>;
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 3344f05..626406f 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -116,6 +116,7 @@
 			reg = <0x48310000 0x200>;
 			interrupts = <29>;
 			ti,hwmods = "gpio1";
+			ti,gpio-always-on;
 			gpio-controller;
 			#gpio-cells = <2>;
 			interrupt-controller;
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 3329140..627f6ca 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -140,6 +140,7 @@
 			reg = <0x4a310000 0x200>;
 			interrupts = <0 29 0x4>;
 			ti,hwmods = "gpio1";
+			ti,gpio-always-on;
 			gpio-controller;
 			#gpio-cells = <2>;
 			interrupt-controller;
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index f4c71d9..82a4b03 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -133,6 +133,7 @@
 			reg = <0x4ae10000 0x200>;
 			interrupts = <0 29 0x4>;
 			ti,hwmods = "gpio1";
+			ti,gpio-always-on;
 			gpio-controller;
 			#gpio-cells = <2>;
 			interrupt-controller;
-- 
1.7.10.4



From tony at atomide.com  Thu Apr  4 16:35:19 2013
From: tony at atomide.com (Tony Lindgren)
Date: Thu, 4 Apr 2013 13:35:19 -0700
Subject: [PATCH 5/5] ARM: dts: OMAP2+: Identify GPIO banks that are
 always powered
In-Reply-To: <1365106576-31816-6-git-send-email-jon-hunter@ti.com>
References: <1365106576-31816-1-git-send-email-jon-hunter@ti.com>
 <1365106576-31816-6-git-send-email-jon-hunter@ti.com>
Message-ID: <20130404203519.GR10155@atomide.com>

* Jon Hunter <jon-hunter at ti.com> [130404 13:21]:
> Add the "ti,gpio-always-on" property to the appropriate GPIO banks to
> indicate which banks are always powered and will never lose logic state.

This patch should be queued by Benoit as this will likely cause
pointless merge conflicts with the other .dts files.

Regards,

Tony
 
> Cc: Benoit Cousson <b-cousson at ti.com>
> Signed-off-by: Jon Hunter <jon-hunter at ti.com>
> ---
>  arch/arm/boot/dts/omap2420.dtsi |    4 ++++
>  arch/arm/boot/dts/omap2430.dtsi |    4 ++++
>  arch/arm/boot/dts/omap3.dtsi    |    1 +
>  arch/arm/boot/dts/omap4.dtsi    |    1 +
>  arch/arm/boot/dts/omap5.dtsi    |    1 +
>  5 files changed, 11 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/omap2420.dtsi b/arch/arm/boot/dts/omap2420.dtsi
> index 455b239..76446ff 100644
> --- a/arch/arm/boot/dts/omap2420.dtsi
> +++ b/arch/arm/boot/dts/omap2420.dtsi
> @@ -34,6 +34,7 @@
>  			reg = <0x48018000 0x200>;
>  			interrupts = <29>;
>  			ti,hwmods = "gpio1";
> +			ti,gpio-always-on;
>  			#gpio-cells = <2>;
>  			gpio-controller;
>  			#interrupt-cells = <2>;
> @@ -45,6 +46,7 @@
>  			reg = <0x4801a000 0x200>;
>  			interrupts = <30>;
>  			ti,hwmods = "gpio2";
> +			ti,gpio-always-on;
>  			#gpio-cells = <2>;
>  			gpio-controller;
>  			#interrupt-cells = <2>;
> @@ -56,6 +58,7 @@
>  			reg = <0x4801c000 0x200>;
>  			interrupts = <31>;
>  			ti,hwmods = "gpio3";
> +			ti,gpio-always-on;
>  			#gpio-cells = <2>;
>  			gpio-controller;
>  			#interrupt-cells = <2>;
> @@ -67,6 +70,7 @@
>  			reg = <0x4801e000 0x200>;
>  			interrupts = <32>;
>  			ti,hwmods = "gpio4";
> +			ti,gpio-always-on;
>  			#gpio-cells = <2>;
>  			gpio-controller;
>  			#interrupt-cells = <2>;
> diff --git a/arch/arm/boot/dts/omap2430.dtsi b/arch/arm/boot/dts/omap2430.dtsi
> index 477b120..ca2c4a3 100644
> --- a/arch/arm/boot/dts/omap2430.dtsi
> +++ b/arch/arm/boot/dts/omap2430.dtsi
> @@ -34,6 +34,7 @@
>  			reg = <0x4900c000 0x200>;
>  			interrupts = <29>;
>  			ti,hwmods = "gpio1";
> +			ti,gpio-always-on;
>  			#gpio-cells = <2>;
>  			gpio-controller;
>  			#interrupt-cells = <2>;
> @@ -45,6 +46,7 @@
>  			reg = <0x4900e000 0x200>;
>  			interrupts = <30>;
>  			ti,hwmods = "gpio2";
> +			ti,gpio-always-on;
>  			#gpio-cells = <2>;
>  			gpio-controller;
>  			#interrupt-cells = <2>;
> @@ -56,6 +58,7 @@
>  			reg = <0x49010000 0x200>;
>  			interrupts = <31>;
>  			ti,hwmods = "gpio3";
> +			ti,gpio-always-on;
>  			#gpio-cells = <2>;
>  			gpio-controller;
>  			#interrupt-cells = <2>;
> @@ -67,6 +70,7 @@
>  			reg = <0x49012000 0x200>;
>  			interrupts = <32>;
>  			ti,hwmods = "gpio4";
> +			ti,gpio-always-on;
>  			#gpio-cells = <2>;
>  			gpio-controller;
>  			#interrupt-cells = <2>;
> diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
> index 3344f05..626406f 100644
> --- a/arch/arm/boot/dts/omap3.dtsi
> +++ b/arch/arm/boot/dts/omap3.dtsi
> @@ -116,6 +116,7 @@
>  			reg = <0x48310000 0x200>;
>  			interrupts = <29>;
>  			ti,hwmods = "gpio1";
> +			ti,gpio-always-on;
>  			gpio-controller;
>  			#gpio-cells = <2>;
>  			interrupt-controller;
> diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
> index 3329140..627f6ca 100644
> --- a/arch/arm/boot/dts/omap4.dtsi
> +++ b/arch/arm/boot/dts/omap4.dtsi
> @@ -140,6 +140,7 @@
>  			reg = <0x4a310000 0x200>;
>  			interrupts = <0 29 0x4>;
>  			ti,hwmods = "gpio1";
> +			ti,gpio-always-on;
>  			gpio-controller;
>  			#gpio-cells = <2>;
>  			interrupt-controller;
> diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
> index f4c71d9..82a4b03 100644
> --- a/arch/arm/boot/dts/omap5.dtsi
> +++ b/arch/arm/boot/dts/omap5.dtsi
> @@ -133,6 +133,7 @@
>  			reg = <0x4ae10000 0x200>;
>  			interrupts = <0 29 0x4>;
>  			ti,hwmods = "gpio1";
> +			ti,gpio-always-on;
>  			gpio-controller;
>  			#gpio-cells = <2>;
>  			interrupt-controller;
> -- 
> 1.7.10.4
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


From gregory.clement at free-electrons.com  Thu Apr  4 16:45:24 2013
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Thu, 04 Apr 2013 22:45:24 +0200
Subject: [PATCH v2 1/7] clk: sunxi: Add support for AXI, AHB, APB0 and
 APB1 gates
In-Reply-To: <20130404024658.3383.63115@quantum>
References: <1363962042-29536-1-git-send-email-emilio@elopez.com.ar>
 <1364419243-18446-1-git-send-email-emilio@elopez.com.ar>
 <1364419243-18446-2-git-send-email-emilio@elopez.com.ar>
 <20130403214815.3383.60153@quantum> <515CD51A.2070503@elopez.com.ar>
 <20130404024658.3383.63115@quantum>
Message-ID: <515DE664.5040505@free-electrons.com>

On 04/04/2013 04:46 AM, Mike Turquette wrote:
> Quoting Emilio L??pez (2013-04-03 18:19:22)
>> Hi Mike,
>>
>> El 03/04/13 18:48, Mike Turquette escribi??:
>>> Quoting Emilio L??pez (2013-03-27 14:20:37)
>>>> diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
>>>> index d528a24..244de90 100644
>>>> --- a/drivers/clk/sunxi/clk-sunxi.c
>>>> +++ b/drivers/clk/sunxi/clk-sunxi.c
>>>> @@ -302,6 +302,82 @@ static void __init sunxi_divider_clk_setup(struct device_node *node,
>>>>  }
>>>>  
>>>>  
>>>> +
>>>
>>> A lot of white space between these functions.
>>
>> All of the function blocks are separated with three spaces on the file;
>> I thought it looked more readable that way, but I don't have any strong
>> opinion on separation. Is there any standard for this used on the kernel?
>>
>> In any case, and to keep consistency, can we handle this on a follow-up
>> patch?
>>
> 
> If it's consistent throughout the file then go ahead and keep it.
> 
>>>> +/**
>>>> + * sunxi_gates_clk_setup() - Setup function for leaf gates on clocks
>>>> + */
>>>> +
>>>> +#define SUNXI_GATES_MAX_SIZE   64
>>>> +
>>>> +struct gates_data {
>>>> +       DECLARE_BITMAP(mask, SUNXI_GATES_MAX_SIZE);
>>>> +};
>>>> +
>>>> +static const __initconst struct gates_data axi_gates_data = {
>>>> +       .mask = {1},
>>>> +};
>>>> +
>>>> +static const __initconst struct gates_data ahb_gates_data = {
>>>> +       .mask = {0x7F77FFF, 0x14FB3F},
>>>> +};
>>>> +
>>>> +static const __initconst struct gates_data apb0_gates_data = {
>>>> +       .mask = {0x4EF},
>>>> +};
>>>> +
>>>> +static const __initconst struct gates_data apb1_gates_data = {
>>>> +       .mask = {0xFF00F7},
>>>> +};
>>>> +
>>>> +static void __init sunxi_gates_clk_setup(struct device_node *node,
>>>> +                                        struct gates_data *data)
>>>> +{
>>>> +       struct clk_onecell_data *clk_data;
>>>> +       const char *clk_parent;
>>>> +       const char *clk_name;
>>>> +       void *reg;
>>>> +       int qty;
>>>> +       int i = 0;
>>>> +       int j = 0;
>>>> +       int ignore;
>>>> +
>>>> +       reg = of_iomap(node, 0);
>>>> +
>>>> +       clk_parent = of_clk_get_parent_name(node, 0);
>>>> +
>>>> +       /* Worst-case size approximation and memory allocation */
>>>> +       qty = find_last_bit(data->mask, SUNXI_GATES_MAX_SIZE);
>>>> +       clk_data = kmalloc(sizeof(struct clk_onecell_data), GFP_KERNEL);
>>>> +       if (!clk_data)
>>>> +               return;
>>>> +       clk_data->clks = kzalloc((qty+1) * sizeof(struct clk *), GFP_KERNEL);
>>>> +       if (!clk_data->clks) {
>>>> +               kfree(clk_data);
>>>> +               return;
>>>> +       }
>>>> +
>>>> +       for_each_set_bit(i, data->mask, SUNXI_GATES_MAX_SIZE) {
>>>> +               of_property_read_string_index(node, "clock-output-names",
>>>> +                                             j, &clk_name);
>>>> +
>>>> +               /* No driver claims this clock, but it should remain gated */
>>>
>>> Should the comment read, "ungated" instead of "gated"?
>>
>> Indeed, good catch. Do you want me to resend the series, or can you
>> amend this when picking the patches?
>>
> 
> I can amend it, but I don't like to get into the habit of doing that too
> often.
> 
> I'll wait on Gregory's response on the of_clk_init stuff before I do so.
> 
> Regards,
> Mike
> 
>>>> +               ignore = !strcmp("ahb_sdram", clk_name) ? CLK_IGNORE_UNUSED : 0;
>>>> +
>>>> +               clk_data->clks[i] = clk_register_gate(NULL, clk_name,
>>>> +                                                     clk_parent, ignore,
>>>> +                                                     reg + 4 * (i/32), i % 32,
>>>> +                                                     0, &clk_lock);
>>>> +               WARN_ON(IS_ERR(clk_data->clks[i]));
>>>> +
>>>> +               j++;
>>>> +       }
>>>> +
>>>> +       /* Adjust to the real max */
>>>> +       clk_data->clk_num = i;
>>>> +
>>>> +       of_clk_add_provider(node, of_clk_src_onecell_get, clk_data);
>>>> +}
>>>> +
>>>>  /* Matches for of_clk_init */
>>>>  static const __initconst struct of_device_id clk_match[] = {
>>>>         {.compatible = "fixed-clock", .data = of_fixed_clk_setup,},
>>>> @@ -331,6 +407,15 @@ static const __initconst struct of_device_id clk_mux_match[] = {
>>>>         {}
>>>>  };
>>>>  
>>>> +/* Matches for gate clocks */
>>>> +static const __initconst struct of_device_id clk_gates_match[] = {
>>>> +       {.compatible = "allwinner,sun4i-axi-gates-clk", .data = &axi_gates_data,},
>>>> +       {.compatible = "allwinner,sun4i-ahb-gates-clk", .data = &ahb_gates_data,},
>>>> +       {.compatible = "allwinner,sun4i-apb0-gates-clk", .data = &apb0_gates_data,},
>>>> +       {.compatible = "allwinner,sun4i-apb1-gates-clk", .data = &apb1_gates_data,},
>>>> +       {}
>>>> +};
>>>> +
>>>>  static void __init of_sunxi_table_clock_setup(const struct of_device_id *clk_match,
>>>>                                               void *function)
>>>>  {
>>>> @@ -359,4 +444,7 @@ void __init sunxi_init_clocks(void)
>>>>  
>>>>         /* Register mux clocks */
>>>>         of_sunxi_table_clock_setup(clk_mux_match, sunxi_mux_clk_setup);
>>>> +
>>>> +       /* Register gate clocks */
>>>> +       of_sunxi_table_clock_setup(clk_gates_match, sunxi_gates_clk_setup);
>>>
>>> I'm still a device tree noob, so this may be a dumb question.  Can the
>>> above be converted to of_clk_init?
>>
>> As far as I know, you can't, because of_clk_init doesn't allow for
>> custom data to be passed to the functions. If we were to use of_clk_init
>> we would need one function per clock, and it would be mostly duplicated
>> code / wrappers. I've added Gregory on Cc, please correct me if this is
>> not the case.

I confirm that the current implementation of of_clk_init only take setup
functions. That was also the reason why we didn't use it in mvebu/clk-core.c
for example.

Maybe it should be a good improvement to allow of_clk_init to receive
a function _and_ data for a given node. Something like that;

typedef void (*of_clk_init_cb_t)(struct device_node *, void *data);
struct clk_of_setup {
of_clk_init_cb_t clk_init_cb;
void* data;
}

void __init of_clk_init(const struct of_device_id *matches)
{
	struct device_node *np;

	if (!matches)
		matches = __clk_of_table;

	for_each_matching_node(np, matches) {
		const struct of_device_id *match = of_match_node(matches, np);
		match->clk_init_cb(np, match->data);
	}
}

I have just writen this code in this email I didn't even try to compile this code.
This was just a rough idea which could be use as a base for future patch for 3.11.
With a good coccinelle script it should be not too complicated.


But about this current patch, I am fine with it, and you can add my
Reviewed-by: Gregory CLEMENT <gregory.clement at free-electrons.com>


>>
>> Thanks for the review,
>>
>> Emilio


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From jon-hunter at ti.com  Thu Apr  4 17:01:17 2013
From: jon-hunter at ti.com (Jon Hunter)
Date: Thu, 4 Apr 2013 16:01:17 -0500
Subject: [PATCH 5/5] ARM: dts: OMAP2+: Identify GPIO banks that are always
 powered
In-Reply-To: <20130404203519.GR10155@atomide.com>
References: <1365106576-31816-1-git-send-email-jon-hunter@ti.com>
 <1365106576-31816-6-git-send-email-jon-hunter@ti.com>
 <20130404203519.GR10155@atomide.com>
Message-ID: <515DEA1D.9070001@ti.com>


On 04/04/2013 03:35 PM, Tony Lindgren wrote:
> * Jon Hunter <jon-hunter at ti.com> [130404 13:21]:
>> Add the "ti,gpio-always-on" property to the appropriate GPIO banks to
>> indicate which banks are always powered and will never lose logic state.
> 
> This patch should be queued by Benoit as this will likely cause
> pointless merge conflicts with the other .dts files.

Yes agreed. I mentioned that in the cover-letter.

Cheers
Jon


From tony at atomide.com  Thu Apr  4 17:08:03 2013
From: tony at atomide.com (Tony Lindgren)
Date: Thu, 4 Apr 2013 14:08:03 -0700
Subject: [PATCH 5/5] ARM: dts: OMAP2+: Identify GPIO banks that are
 always powered
In-Reply-To: <515DEA1D.9070001@ti.com>
References: <1365106576-31816-1-git-send-email-jon-hunter@ti.com>
 <1365106576-31816-6-git-send-email-jon-hunter@ti.com>
 <20130404203519.GR10155@atomide.com> <515DEA1D.9070001@ti.com>
Message-ID: <20130404210801.GT10155@atomide.com>

* Jon Hunter <jon-hunter at ti.com> [130404 14:05]:
> 
> On 04/04/2013 03:35 PM, Tony Lindgren wrote:
> > * Jon Hunter <jon-hunter at ti.com> [130404 13:21]:
> >> Add the "ti,gpio-always-on" property to the appropriate GPIO banks to
> >> indicate which banks are always powered and will never lose logic state.
> > 
> > This patch should be queued by Benoit as this will likely cause
> > pointless merge conflicts with the other .dts files.
> 
> Yes agreed. I mentioned that in the cover-letter.

OK thanks.

Tony


From swarren at wwwdotorg.org  Thu Apr  4 17:11:46 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Thu, 04 Apr 2013 15:11:46 -0600
Subject: [PATCH v2] pinctrl/pinconfig: add debug interface
In-Reply-To: <1365018447-28062-1-git-send-email-linus.walleij@stericsson.com>
References: <1365018447-28062-1-git-send-email-linus.walleij@stericsson.com>
Message-ID: <515DEC92.9010602@wwwdotorg.org>

On 04/03/2013 01:47 PM, Linus Walleij wrote:
> From: Laurent Meunier <laurent.meunier at st.com>
> 
> This update adds a debugfs interface to modify a pin configuration
> for a given state in the pinctrl map. This allows to modify the
> configuration for a non-active state, typically sleep state.
> This configuration is not applied right away, but only when the state
> will be entered.
> 
> This solution is mandated for us by HW validation: in order
> to test and verify several pin configurations during sleep without
> recompiling the software.
> 
> diff --git a/drivers/pinctrl/pinconf.c b/drivers/pinctrl/pinconf.c

> +enum pinconf_dbg_request_type {
> +	PINCONF_DBG_REQ_TYPE_INVALID,
> +	PINCONF_DBG_REQ_TYPE_MODIFY,
> +};

I'm not sure why that really needs an enum yet, since only one operation
is supported.

> +struct dbg_cfg {
> +	enum pinconf_dbg_request_type req_type;
> +	enum pinctrl_map_type map_type;
> +	char dev_name[MAX_NAME_LEN+1];
> +	char state_name[MAX_NAME_LEN+1];
> +	char pin_name[MAX_NAME_LEN+1];
> +	char config[MAX_NAME_LEN+1];
> +};

Many of those fields are only used internally to
pinconf_dbg_config_write(). Can't they be stored on the stack there
rather than globally.

> +/**
> + * pinconf_dbg_config_print() - display the pinctrl config from the pinctrl
> + * map, of a pin/state pair based on pinname and state that have been
> + * selected with the debugfs entries pinconf-name and pinconf-state
> + * @s: contains the 32bits config to be written
> + * @d: not used
> + */

This comment seems stale; I don't believe there are any pinconf-name and
pinconf-state files; aren't they part of the data written to the one
debugfs file each time?

> +static int pinconf_dbg_config_print(struct seq_file *s, void *d)

> +		if (strncmp(map->dev_name, dbg->dev_name, MAX_NAME_LEN) != 0)

Wouldn't it be simpler to always ensure dbg->dev_name was
NULL-terminated, and just use !strcmp() here? Same for dbg->state_name
below. Same comment for the other function below.

> +	mutex_unlock(&pinctrl_mutex);

Don't you need the lock held to call confops->xxx() below, to make sure
that the driver isn't unregistered between finding it, and calling the
confops function?

> +	if (!found) {
> +		seq_printf(s, "No config found for dev/state/pin, expected:\n");
> +		seq_printf(s, "modify config_pins devname " \
> +			   "state pinname value\n");
> +	}

Hmmm. At least including the parsed values that were being searched for
might be useful?

> +		confops->pin_config_config_dbg_show(pctldev,
> +						    s, config);

I think that function name is wrong; two "config_" in a row. Does this
compile?

> +/**
> + * pinconf_dbg_config_write() - overwrite the pinctrl config in the pinctrl
> + * map, of a pin/state pair based on pinname and state that have been
> + * selected with the debugfs entries pinconf-name and pinconf-state

Similar stale comment.

> + * @user_buf: contains 'modify configs_pin devicename state pinname newvalue'

It might be useful to say which parts of that are literal strings and
which are variables/values to be changed?

> +static int pinconf_dbg_config_write(struct file *file,
> +	const char __user *user_buf, size_t count, loff_t *ppos)

> +	/* Get arg: 'modify' */
> +	if (!strncmp(b, "modify ", strlen("modify "))) {
> +		dbg->req_type = PINCONF_DBG_REQ_TYPE_MODIFY;
> +		b += strlen("modify ");
> +	} else {
> +		return -EINVAL;
> +	}

There's rather a lot of duplication of strings and strlen calls there.
Why not:

a) Start using strsep() for the very first fields too, so everything is
consistent.

b) Put the error-path first.

In other words:

	token = strsep(&b, " ");
	if (!token)
		return -EINVAL;
	if (!strcmp(token, "modify"))
		return -EINVAL;

> +	/* Get arg type: "config_pin" type supported so far */
> +	if (!strncmp(b, "config_pins ", strlen("config_pins "))) {
> +		dbg->map_type = PIN_MAP_TYPE_CONFIGS_PIN;
> +		b += strlen("config_pins ");
> +	} else {
> +		return -EINVAL;
> +	}

That could be transformed the same way.

> +	/* get arg 'device_name' */
> +	token = strsep(&b, " ");
> +	if (token == NULL)
> +		return -EINVAL;
> +	if (strlen(token) < MAX_NAME_LEN)
> +		sscanf(token, "%s", dbg->dev_name);
> +	else
> +		return -EINVAL;

It might make sense to put the error-handling first, and why sscanf not
strcpy? So:

	token = strsep(&b, " ");
	if (token == NULL)
		return -EINVAL;
	if (strlen(token) >= MAX_NAME_LEN)
		return -EINVAL;
	strcpy(dbg->dev_name, token);

(or even just use strncpy followed by explicit NULL termination and
truncate text that's too long, or kstrdup() it to avoid limits?)

> +	if (confops && confops->pin_config_dbg_parse) {
> +		for (i = 0; i < configs->num_configs; i++) {
> +			confops->pin_config_dbg_parse(pctldev,
> +						    dbg->config,
> +						    &configs->configs[i]);

I assume that "parse" function is intended to actually write the new
result into configs->configs[i]. That's more than parsing.
s/dbg_parse/dbg_modify/ perhaps to make this more explicit, and also
mention this in the kerneldoc for the confops structure in the header?


From mturquette at linaro.org  Thu Apr  4 17:08:52 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Thu, 04 Apr 2013 14:08:52 -0700
Subject: [PATCH v2 1/7] clk: sunxi: Add support for AXI, AHB,
 APB0 and APB1 gates
In-Reply-To: <515DE664.5040505@free-electrons.com>
References: <1363962042-29536-1-git-send-email-emilio@elopez.com.ar>
 <1364419243-18446-1-git-send-email-emilio@elopez.com.ar>
 <1364419243-18446-2-git-send-email-emilio@elopez.com.ar>
 <20130403214815.3383.60153@quantum> <515CD51A.2070503@elopez.com.ar>
 <20130404024658.3383.63115@quantum> <515DE664.5040505@free-electrons.com>
Message-ID: <20130404210852.8665.57485@quantum>

Quoting Gregory CLEMENT (2013-04-04 13:45:24)
> On 04/04/2013 04:46 AM, Mike Turquette wrote:
> > Quoting Emilio L??pez (2013-04-03 18:19:22)
> >> Hi Mike,
> >>
> >> El 03/04/13 18:48, Mike Turquette escribi??:
> >>> Quoting Emilio L??pez (2013-03-27 14:20:37)
> >>>> diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
> >>>> index d528a24..244de90 100644
> >>>> --- a/drivers/clk/sunxi/clk-sunxi.c
> >>>> +++ b/drivers/clk/sunxi/clk-sunxi.c
> >>>> @@ -302,6 +302,82 @@ static void __init sunxi_divider_clk_setup(struct device_node *node,
> >>>>  }
> >>>>  
> >>>>  
> >>>> +
> >>>
> >>> A lot of white space between these functions.
> >>
> >> All of the function blocks are separated with three spaces on the file;
> >> I thought it looked more readable that way, but I don't have any strong
> >> opinion on separation. Is there any standard for this used on the kernel?
> >>
> >> In any case, and to keep consistency, can we handle this on a follow-up
> >> patch?
> >>
> > 
> > If it's consistent throughout the file then go ahead and keep it.
> > 
> >>>> +/**
> >>>> + * sunxi_gates_clk_setup() - Setup function for leaf gates on clocks
> >>>> + */
> >>>> +
> >>>> +#define SUNXI_GATES_MAX_SIZE   64
> >>>> +
> >>>> +struct gates_data {
> >>>> +       DECLARE_BITMAP(mask, SUNXI_GATES_MAX_SIZE);
> >>>> +};
> >>>> +
> >>>> +static const __initconst struct gates_data axi_gates_data = {
> >>>> +       .mask = {1},
> >>>> +};
> >>>> +
> >>>> +static const __initconst struct gates_data ahb_gates_data = {
> >>>> +       .mask = {0x7F77FFF, 0x14FB3F},
> >>>> +};
> >>>> +
> >>>> +static const __initconst struct gates_data apb0_gates_data = {
> >>>> +       .mask = {0x4EF},
> >>>> +};
> >>>> +
> >>>> +static const __initconst struct gates_data apb1_gates_data = {
> >>>> +       .mask = {0xFF00F7},
> >>>> +};
> >>>> +
> >>>> +static void __init sunxi_gates_clk_setup(struct device_node *node,
> >>>> +                                        struct gates_data *data)
> >>>> +{
> >>>> +       struct clk_onecell_data *clk_data;
> >>>> +       const char *clk_parent;
> >>>> +       const char *clk_name;
> >>>> +       void *reg;
> >>>> +       int qty;
> >>>> +       int i = 0;
> >>>> +       int j = 0;
> >>>> +       int ignore;
> >>>> +
> >>>> +       reg = of_iomap(node, 0);
> >>>> +
> >>>> +       clk_parent = of_clk_get_parent_name(node, 0);
> >>>> +
> >>>> +       /* Worst-case size approximation and memory allocation */
> >>>> +       qty = find_last_bit(data->mask, SUNXI_GATES_MAX_SIZE);
> >>>> +       clk_data = kmalloc(sizeof(struct clk_onecell_data), GFP_KERNEL);
> >>>> +       if (!clk_data)
> >>>> +               return;
> >>>> +       clk_data->clks = kzalloc((qty+1) * sizeof(struct clk *), GFP_KERNEL);
> >>>> +       if (!clk_data->clks) {
> >>>> +               kfree(clk_data);
> >>>> +               return;
> >>>> +       }
> >>>> +
> >>>> +       for_each_set_bit(i, data->mask, SUNXI_GATES_MAX_SIZE) {
> >>>> +               of_property_read_string_index(node, "clock-output-names",
> >>>> +                                             j, &clk_name);
> >>>> +
> >>>> +               /* No driver claims this clock, but it should remain gated */
> >>>
> >>> Should the comment read, "ungated" instead of "gated"?
> >>
> >> Indeed, good catch. Do you want me to resend the series, or can you
> >> amend this when picking the patches?
> >>
> > 
> > I can amend it, but I don't like to get into the habit of doing that too
> > often.
> > 
> > I'll wait on Gregory's response on the of_clk_init stuff before I do so.
> > 
> > Regards,
> > Mike
> > 
> >>>> +               ignore = !strcmp("ahb_sdram", clk_name) ? CLK_IGNORE_UNUSED : 0;
> >>>> +
> >>>> +               clk_data->clks[i] = clk_register_gate(NULL, clk_name,
> >>>> +                                                     clk_parent, ignore,
> >>>> +                                                     reg + 4 * (i/32), i % 32,
> >>>> +                                                     0, &clk_lock);
> >>>> +               WARN_ON(IS_ERR(clk_data->clks[i]));
> >>>> +
> >>>> +               j++;
> >>>> +       }
> >>>> +
> >>>> +       /* Adjust to the real max */
> >>>> +       clk_data->clk_num = i;
> >>>> +
> >>>> +       of_clk_add_provider(node, of_clk_src_onecell_get, clk_data);
> >>>> +}
> >>>> +
> >>>>  /* Matches for of_clk_init */
> >>>>  static const __initconst struct of_device_id clk_match[] = {
> >>>>         {.compatible = "fixed-clock", .data = of_fixed_clk_setup,},
> >>>> @@ -331,6 +407,15 @@ static const __initconst struct of_device_id clk_mux_match[] = {
> >>>>         {}
> >>>>  };
> >>>>  
> >>>> +/* Matches for gate clocks */
> >>>> +static const __initconst struct of_device_id clk_gates_match[] = {
> >>>> +       {.compatible = "allwinner,sun4i-axi-gates-clk", .data = &axi_gates_data,},
> >>>> +       {.compatible = "allwinner,sun4i-ahb-gates-clk", .data = &ahb_gates_data,},
> >>>> +       {.compatible = "allwinner,sun4i-apb0-gates-clk", .data = &apb0_gates_data,},
> >>>> +       {.compatible = "allwinner,sun4i-apb1-gates-clk", .data = &apb1_gates_data,},
> >>>> +       {}
> >>>> +};
> >>>> +
> >>>>  static void __init of_sunxi_table_clock_setup(const struct of_device_id *clk_match,
> >>>>                                               void *function)
> >>>>  {
> >>>> @@ -359,4 +444,7 @@ void __init sunxi_init_clocks(void)
> >>>>  
> >>>>         /* Register mux clocks */
> >>>>         of_sunxi_table_clock_setup(clk_mux_match, sunxi_mux_clk_setup);
> >>>> +
> >>>> +       /* Register gate clocks */
> >>>> +       of_sunxi_table_clock_setup(clk_gates_match, sunxi_gates_clk_setup);
> >>>
> >>> I'm still a device tree noob, so this may be a dumb question.  Can the
> >>> above be converted to of_clk_init?
> >>
> >> As far as I know, you can't, because of_clk_init doesn't allow for
> >> custom data to be passed to the functions. If we were to use of_clk_init
> >> we would need one function per clock, and it would be mostly duplicated
> >> code / wrappers. I've added Gregory on Cc, please correct me if this is
> >> not the case.
> 
> I confirm that the current implementation of of_clk_init only take setup
> functions. That was also the reason why we didn't use it in mvebu/clk-core.c
> for example.
> 
> Maybe it should be a good improvement to allow of_clk_init to receive
> a function _and_ data for a given node. Something like that;
> 
> typedef void (*of_clk_init_cb_t)(struct device_node *, void *data);
> struct clk_of_setup {
> of_clk_init_cb_t clk_init_cb;
> void* data;
> }
> 
> void __init of_clk_init(const struct of_device_id *matches)
> {
>         struct device_node *np;
> 
>         if (!matches)
>                 matches = __clk_of_table;
> 
>         for_each_matching_node(np, matches) {
>                 const struct of_device_id *match = of_match_node(matches, np);
>                 match->clk_init_cb(np, match->data);
>         }
> }
> 
> I have just writen this code in this email I didn't even try to compile this code.
> This was just a rough idea which could be use as a base for future patch for 3.11.
> With a good coccinelle script it should be not too complicated.
> 

Sure, maybe some solution can be found for 3.11.

> 
> But about this current patch, I am fine with it, and you can add my
> Reviewed-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
> 

Thanks.  The three clock patches have been pushed to clk-next.

Regards,
Mike

> 
> >>
> >> Thanks for the review,
> >>
> >> Emilio
> 
> 
> -- 
> Gregory Clement, Free Electrons
> Kernel, drivers, real-time and embedded Linux
> development, consulting, training and support.
> http://free-electrons.com


From mturquette at linaro.org  Thu Apr  4 17:20:02 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Thu, 04 Apr 2013 14:20:02 -0700
Subject: [PATCH v9 00/14] Tegra114 clockframework
In-Reply-To: <20130404082043.GY18519@tbergstrom-lnx.Nvidia.com>
References: <1365000110-8916-1-git-send-email-pdeschrijver@nvidia.com>
 <515C6C6E.6060302@wwwdotorg.org> <515C7495.8060106@wwwdotorg.org>
 <515CB9D9.90303@wwwdotorg.org>
 <20130404082043.GY18519@tbergstrom-lnx.Nvidia.com>
Message-ID: <20130404212002.8665.12387@quantum>

Quoting Peter De Schrijver (2013-04-04 01:20:44)
> On Thu, Apr 04, 2013 at 01:23:05AM +0200, Stephen Warren wrote:
> > On 04/03/2013 12:27 PM, Stephen Warren wrote:
> > > On 04/03/2013 11:52 AM, Stephen Warren wrote:
> > >> On 04/03/2013 08:40 AM, Peter De Schrijver wrote:
> > >>> This is the nineth version of the Tegra114 clockframework. It is based on the
> > >>> next-20130320-fixed branch of
> > >>> git://nv-tegra.nvidia.com/user/swarren/linux-2.6.git,
> > > ... [it depends on]
> > >>> http://patchwork.ozlabs.org/patch/233415/
> > >>
> > >> That is Joseph's "clocksource: tegra: enable arch_timer". Is this
> > >> actually a dependency, or an optimization, or ...?
> > >>
> > >> Rob Herring objected to that patch since it isn't necessary if his
> > >> series "ARM arch, sp804 and integrator timer CLKSRC_OF support" is applied.
> > >>
> > >> If I apply just your (Peter's) CCF series without Joseph's or Rob's
> > >> patches, will everything still work, or is this a hard dependency to
> > >> create a working system?
> > > 
> > > I manage to get this series applied on top of my local dev branch, based
> > > on next-20130328 (it was painful). Testing indicates that there is no
> > > dependency on Joseph's patch mentioned above; I could boot, log in, and
> > > play audio (with local patches) with /or/ without Joseph's patch applied.
> > > 
> > > However, I still find that I need to revert f7db706 ARM: "7674/1: smp:
> > > Avoid dummy clockevent being preferred over real hardware clock-event",
> > > or I get a hard system hang right after the root fs is mounted. As such,
> > > I not sure if it's worthwhile applying this series since it's unlikely
> > > to actually work once merged into Torvalds' tree.
> > > 
> > > Do you have any idea what the problem is here?
> > > 
> > > I'll try rebasing my local test branch on top of the latest linux-next
> > > just in case some other fix solved this already, but I'm not going to
> > > hold my breath.
> > 
> > I've found the problem. My bootloader wasn't initializing the TSC and
> > hence I guess it wasn't working properly, even with Joseph's patch to
> > add a call to the initialization function.
> > 
> 
> Ok.
> 
> > So, if I:
> > 
> > a) Fix my bootloader to enable TSC.
> > 
> > b) Merge Rob's patch series to enable the TSC. This is needed rather
> > than Joseph's patch since the two conflict, and I assume that Rob's
> > patch is going into 3.10.
> > 
> > c) Undo my local revert of "ARM: 7674/1: smp: Avoid dummy clockevent
> > being preferred over real hardware clock-event".
> > 
> 
> Ok. Good. That's close to what I have and works here. As well.
> 
> > ... then everything now works.
> > 
> > So the only remaining issues are:
> > 
> > 1) Should the mux clocks still be defined in the binding document?
> > Prashant didn't seem to think so.
> > 
> 
> I guess we should remove them then.
> 
> > 2) I need Mike's ack to apply this series to the Tegra tree.
> 
> Ok. Mike?
> 

Cool to see this come together!

For the drivers/clk bits:

Acked-by: Mike Turquette <mturquette at linaro.org>

> Cheers,
> 
> Peter.


From swarren at wwwdotorg.org  Thu Apr  4 17:28:54 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Thu, 04 Apr 2013 15:28:54 -0600
Subject: [PATCH v3 07/12] PCI: tegra: Move PCIe driver to drivers/pci/host
In-Reply-To: <1365000318-28256-8-git-send-email-thierry.reding@avionic-design.de>
References: <1365000318-28256-1-git-send-email-thierry.reding@avionic-design.de>
 <1365000318-28256-8-git-send-email-thierry.reding@avionic-design.de>
Message-ID: <515DF096.2000703@wwwdotorg.org>

On 04/03/2013 08:45 AM, Thierry Reding wrote:
> Move the PCIe driver from arch/arm/mach-tegra into the drivers/pci/host
> directory. The motivation is to collect various host controller drivers
> in the same location in order to facilitate refactoring.
> 
> The Tegra PCIe driver has been largely rewritten, both in order to turn
> it into a proper platform driver and to add MSI (based on code by
> Krishna Kishore <kthota at nvidia.com>) as well as device tree support.

>  arch/arm/boot/dts/tegra20.dtsi                     |   53 +

I guess this has to touch both the driver and the dtsi file so that
bisectabilty isn't broken? I guess that's OK.

> diff --git a/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt b/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt

> +Required properties:

> +- interrupts: the interrupt outputs of the controller
> +- interrupt-names: list of names to identify interrupts

The specification part of this file should define which interrupt
outputs must be included in this list, and the order they must appear in
the list. I believe that the entries in the interrupts property must
have a defined order, so I'm not sure whether interrupt-names is useful
here?

> +- ranges: describes the translation of addresses for root ports

Shouldn't there be some discussion re: how the range are expected to be
set up so that everything works? We shouldn't expect people to just
blindly copy the example without any way of understanding it.

> +- clocks: the clock inputs of the controller
> +- clock-names: list of names to identify clocks

The specification part of this file should define which clocks are
required, and not rely on the example below to do this. I would suggest
re-writing this as:

- clocks : Must contain an entry for each entry in clock-names.
- clock-names : Must include the following entries:
  "pex" (The Tegra clock of that name)
  "afi" (The Tegra clock of that name)
  "pcie_xclk" (The Tegra clock of that name)
  "pll_e" (The Tegra clock of that name)

> +Root ports are defined as subnodes of the PCIe controller node.
> +
> +Required properties:
...
> +- ranges: sub-ranges distributed from the PCIe controller node

Here, I think it's worth mentioning that an empty ranges is all that's
required.

> +Board DTS:
> +
> +	pcie-controller {
> +		status = "okay";
> +
> +		vdd-supply = <&pci_vdd_reg>;
> +		pex-clk-supply = <&pci_clk_reg>;
> +
> +		/* root port 00:01.0 */
> +		pci at 1,0 {
> +			status = "okay";

Is it worth putting a comment here stating that the explicit devices
included below in this example are entirely optional?

> diff --git a/arch/arm/mach-tegra/board-harmony-pcie.c b/arch/arm/mach-tegra/board-harmony-pcie.c
> deleted file mode 100644

Hmmm. Is this patch meant to include a change to tegra20-harmony.dtsi to
hook up all the regulators through device tree? Same for TrimSlice?

> diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
> diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile
> diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
> diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile

I think the creation of those files should be a separate patch, and
hopefully get into 3.10 to remove any dependencies. Otherwise, 3 or 4
different patches are all going to try and do the same thing. Didn't the
Marvell series split out the creation of drivers/pci/host/ into a
separate patch that's suitable for this, and could go into 3.10?

> diff --git a/drivers/pci/host/pci-tegra.c b/drivers/pci/host/pci-tegra.c

I'll review that file separately later.


From gmbnomis at gmail.com  Thu Apr  4 17:29:06 2013
From: gmbnomis at gmail.com (Simon Baatz)
Date: Thu, 4 Apr 2013 23:29:06 +0200
Subject: [PATCH 1/5 v2] mv643xx_eth: add Device Tree bindings
In-Reply-To: <1365071235-11611-2-git-send-email-florian@openwrt.org>
References: <1365071235-11611-1-git-send-email-florian@openwrt.org>
 <1365071235-11611-2-git-send-email-florian@openwrt.org>
Message-ID: <20130404212906.GA25904@schnuecks.de>

Hi Florian

On Thu, Apr 04, 2013 at 12:27:11PM +0200, Florian Fainelli wrote:
> This patch adds Device Tree bindings following the already defined
> bindings at Documentation/devicetree/bindings/marvell.txt. The binding
> documentation is also enhanced with new optionnal properties required
> for supporting certain devices (RX/TX queue and SRAM). Since we now have
> proper support for the orion MDIO bus driver, there is no need to fiddle
> around with device tree phandles. PHY-less (MAC connected to switch)
> configurations are supported by not specifying any phy phandle for an
> ethernet node.
> 
> Signed-off-by: Florian Fainelli <florian at openwrt.org>
> ---
> - properly ifdef of_platform_bus_probe with CONFIG_OF
> - handle of_platform_bus_probe errors and cleanup accordingly
> - use of_property_read_u32 where applicable
> - parse "duplex" and "speed" property in PHY-less configuration
> 
>  Documentation/devicetree/bindings/marvell.txt |   25 +++++-
>  drivers/net/ethernet/marvell/mv643xx_eth.c    |  120 ++++++++++++++++++++++++-
>  2 files changed, 140 insertions(+), 5 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/marvell.txt b/Documentation/devicetree/bindings/marvell.txt
> index f1533d9..e70a013 100644
> --- a/Documentation/devicetree/bindings/marvell.txt
> +++ b/Documentation/devicetree/bindings/marvell.txt
> @@ -112,9 +112,14 @@ prefixed with the string "marvell,", for Marvell Technology Group Ltd.
>     Required properties:
>       - #address-cells : <1>
>       - #size-cells : <0>
> -     - compatible : "marvell,mv64360-eth-block"
> +     - compatible : "marvell,mv64360-eth-block", "marvell,mv64360-eth-group",
> +		    "marvell,mv643xx-eth-block"
>       - reg : Offset and length of the register set for this block
>  
> +   Optional properties:
> +     - tx-csum-limit : Hardware limit above which transmit checksumming
> +                       is disabled.
> +
>     Example Discovery Ethernet block node:
>       ethernet-block at 2000 {
>  	     #address-cells = <1>;
> @@ -130,7 +135,7 @@ prefixed with the string "marvell,", for Marvell Technology Group Ltd.
>  
>     Required properties:
>       - device_type : Should be "network".
> -     - compatible : Should be "marvell,mv64360-eth".
> +     - compatible : Should be "marvell,mv64360-eth", "marvell,mv643xx-eth".
>       - reg : Should be <0>, <1>, or <2>, according to which registers
>         within the silicon block the device uses.
>       - interrupts : <a> where a is the interrupt number for the port.
> @@ -140,6 +145,22 @@ prefixed with the string "marvell,", for Marvell Technology Group Ltd.
>         controller.
>       - local-mac-address : 6 bytes, MAC address
>  
> +   Optional properties:
> +     - clocks : Phandle to the clock control device and gate bit
> +     - clock-names : String describing the clock gate bit
> +     - speed : Speed to force the link (10, 100, 1000), used when no
> +               phy property is defined
> +     - duplex : Duplex to force the link (0: half, 1: full), used when no
> +               phy property is defined
> +     - rx-queue-count : number of RX queues to use
> +     - tx-queue-count : number of TX queues to use
> +     - rx-queue-size : size of the RX queue (in bytes)
> +     - tx-queue-size : size of the TX queue (in bytes)
> +     - rx-sram-addr : address of the SRAM for RX path (non 0 means used)
> +     - rx-sram-size : size of the SRAM for RX path (non 0 means used)
> +     - tx-sram-addr : address of the SRAM for TX path (non 0 means used)
> +     - tx-sram-size : size of the SRAM for TX path (non 0 means used)
> +
>     Example Discovery Ethernet port node:
>       ethernet at 0 {
>  	     device_type = "network";
> diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c b/drivers/net/ethernet/marvell/mv643xx_eth.c
> index aedbd82..75599a8 100644
> --- a/drivers/net/ethernet/marvell/mv643xx_eth.c
> +++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
> @@ -60,6 +60,10 @@
>  #include <linux/inet_lro.h>
>  #include <linux/slab.h>
>  #include <linux/clk.h>
> +#include <linux/stringify.h>
> +#include <linux/of.h>
> +#include <linux/of_platform.h>
> +#include <linux/of_net.h>
>  
>  static char mv643xx_eth_driver_name[] = "mv643xx_eth";
>  static char mv643xx_eth_driver_version[] = "1.4";
> @@ -2542,14 +2546,23 @@ static void infer_hw_params(struct mv643xx_eth_shared_private *msp)
>  	}
>  }
>  
> +static const struct of_device_id mv643xx_eth_match[] = {
> +	{ .compatible = "marvell,mv64360-eth" },
> +	{ .compatible = "marvell,mv643xx-eth" },
> +	{ /* sentinel */ },
> +};
> +MODULE_DEVICE_TABLE(of, mv643xx_eth_match);
> +
>  static int mv643xx_eth_shared_probe(struct platform_device *pdev)
>  {
>  	static int mv643xx_eth_version_printed;
> +	struct device_node *np = pdev->dev.of_node;
>  	struct mv643xx_eth_shared_platform_data *pd = pdev->dev.platform_data;
>  	struct mv643xx_eth_shared_private *msp;
>  	const struct mbus_dram_target_info *dram;
>  	struct resource *res;
>  	int ret;
> +	int tx_csum_limit = 0;
>  
>  	if (!mv643xx_eth_version_printed++)
>  		pr_notice("MV-643xx 10/100/1000 ethernet driver version %s\n",

This is not related to your change, but there is a problem in this
function that has already been discussed in the past if I remember
correctly: The respective clock needs to be enabled here (at least
on Kirkwood), since accesses to the hardware are done below. 
Enabling the clock only in mv643xx_eth_probe() is too late.

As said, this is not a problem introduced by your changes (and which
is currently circumvented by enabling the respective clocks in
kirkwood_legacy_clk_init() and kirkwood_ge0x_init()), but we might
want to fix this now to get rid of unconditionally enabling the GE
clocks in the DT case.


> @@ -2576,13 +2589,23 @@ static int mv643xx_eth_shared_probe(struct platform_device *pdev)
>  	if (dram)
>  		mv643xx_eth_conf_mbus_windows(msp, dram);
>  
> -	msp->tx_csum_limit = (pd != NULL && pd->tx_csum_limit) ?
> -					pd->tx_csum_limit : 9 * 1024;
> +	if (np)
> +		of_property_read_u32(np, "tx-csum-limit", &tx_csum_limit);
> +	else
> +		tx_csum_limit = pd->tx_csum_limit;
> +
> +	msp->tx_csum_limit = tx_csum_limit ? tx_csum_limit : 9 * 1024;
>  	infer_hw_params(msp);
>  
>  	platform_set_drvdata(pdev, msp);
> +	ret = 0;
>  
> -	return 0;
> +#ifdef CONFIG_OF
> +	ret = of_platform_bus_probe(np, mv643xx_eth_match, &pdev->dev);
> +	if (ret)
> +		goto out_free;
> +#endif
> +	return ret;
>  
>  out_free:
>  	kfree(msp);
> @@ -2600,12 +2623,22 @@ static int mv643xx_eth_shared_remove(struct platform_device *pdev)
>  	return 0;
>  }
>  
> +static const struct of_device_id mv643xx_eth_shared_match[] = {
> +	{ .compatible = "marvell,mv64360-eth-group" },
> +	{ .compatible = "marvell,mv64360-eth-block" },
> +	{ .compatible = "marvell,mv643xx-eth-group" },
> +	{ .compatible = "marvell,mv643xx-eth-block" },
> +	{ /* sentinel */ },
> +};
> +MODULE_DEVICE_TABLE(of, mv643xx_eth_shared_match);
> +
>  static struct platform_driver mv643xx_eth_shared_driver = {
>  	.probe		= mv643xx_eth_shared_probe,
>  	.remove		= mv643xx_eth_shared_remove,
>  	.driver = {
>  		.name	= MV643XX_ETH_SHARED_NAME,
>  		.owner	= THIS_MODULE,
> +		.of_match_table = of_match_ptr(mv643xx_eth_shared_match),
>  	},
>  };
>  
> @@ -2764,6 +2797,74 @@ static const struct net_device_ops mv643xx_eth_netdev_ops = {
>  #endif
>  };
>  
> +#ifdef CONFIG_OF
> +static int mv643xx_eth_of_probe(struct platform_device *pdev)
> +{
> +	struct mv643xx_eth_platform_data *pd;
> +	struct device_node *np = pdev->dev.of_node;
> +	struct device_node *shared = of_get_parent(np);
> +	struct device_node *phy_node;
> +	const int *prop;
> +	const char *mac_addr;
> +
> +	if (!pdev->dev.of_node)
> +		return 0;
> +
> +	pd = kzalloc(sizeof(*pd), GFP_KERNEL);
> +	if (!pd)
> +		return -ENOMEM;
> +
> +	pdev->dev.platform_data = pd;
> +
> +	pd->shared = of_find_device_by_node(shared);
> +	if (!pd->shared)
> +		return -ENODEV;
> +
> +	prop = of_get_property(np, "reg", NULL);
> +	if (!prop)
> +		return -EINVAL;
> +
> +	pd->port_number = be32_to_cpup(prop);
> +
> +	phy_node = of_parse_phandle(np, "phy", 0);
> +	if (!phy_node) {
> +		pd->phy_addr = MV643XX_ETH_PHY_NONE;
> +
> +		of_property_read_u32(np, "speed", &pd->speed);
> +		of_property_read_u32(np, "duplex", &pd->duplex);
> +	} else {
> +		prop = of_get_property(phy_node, "reg", NULL);
> +		if (prop)
> +			pd->phy_addr = be32_to_cpup(prop);
> +	}
> +
> +	mac_addr = of_get_mac_address(np);
> +	if (mac_addr)
> +		memcpy(pd->mac_addr, mac_addr, ETH_ALEN);
> +
> +#define rx_tx_queue_sram_property(_name)			\
> +	prop = of_get_property(np, __stringify(_name), NULL);	\
> +	if (prop)						\
> +		pd->_name = be32_to_cpup(prop);
> +
> +	rx_tx_queue_sram_property(rx_queue_count);
> +	rx_tx_queue_sram_property(tx_queue_count);
> +	rx_tx_queue_sram_property(rx_queue_size);
> +	rx_tx_queue_sram_property(tx_queue_size);
> +	rx_tx_queue_sram_property(rx_sram_addr);
> +	rx_tx_queue_sram_property(rx_sram_size);
> +	rx_tx_queue_sram_property(tx_sram_addr);
> +	rx_tx_queue_sram_property(rx_sram_size);
> +
> +	return 0;
> +}
> +#else
> +static inline int mv643xx_eth_of_probe(struct platform_device *dev)
> +{
> +	return 0;
> +}
> +#endif
> +
>  static int mv643xx_eth_probe(struct platform_device *pdev)
>  {
>  	struct mv643xx_eth_platform_data *pd;
> @@ -2772,7 +2873,12 @@ static int mv643xx_eth_probe(struct platform_device *pdev)
>  	struct resource *res;
>  	int err;
>  
> +	err = mv643xx_eth_of_probe(pdev);
> +	if (err)
> +		return err;
> +
>  	pd = pdev->dev.platform_data;
> +
>  	if (pd == NULL) {
>  		dev_err(&pdev->dev, "no mv643xx_eth_platform_data\n");
>  		return -ENODEV;

You don't change the clk initialization here:

#if defined(CONFIG_HAVE_CLK)
	mp->clk = clk_get(&pdev->dev, (pdev->id ? "1" : "0"));
	if (!IS_ERR(mp->clk)) {
		clk_prepare_enable(mp->clk);
		mp->t_clk = clk_get_rate(mp->clk);
	}
#endif

Which, if I understand correctly, works in the DT case because you
assign "clock-names" to the clocks in the DTS. However, I wonder
whether this works for any but the first Ethernet device.

In the old platform device setup, the pdev->id was set when
initialiazing the platform_device structure in common.c.  Where is
this done in the DT case?


In phy_scan(), the phy is searched like this:

		snprintf(phy_id, sizeof(phy_id), PHY_ID_FMT,
				"orion-mdio-mii", addr);

		phydev = phy_connect(mp->dev, phy_id, mv643xx_eth_adjust_link,
				PHY_INTERFACE_MODE_GMII);

But "orion-mdio-mii:xx" is the name of the PHY if MDIO is setup via a
platform_device. I could not get this to work if the MDIO device is
setup via DT. Am I doing something wrong?


Additionally, in phy_scan() there is this:

	if (phy_addr == MV643XX_ETH_PHY_ADDR_DEFAULT) {
		start = phy_addr_get(mp) & 0x1f;
		num = 32;
	} else {
	...

MV643XX_ETH_PHY_ADDR_DEFAULT is defined as 0. However, many Kirkwood
devices use "MV643XX_ETH_PHY_ADDR(0)".  If the module probe is
deferred in mv643xx_eth because the MDIO driver is not yet loaded,
all 32 PHY addresses are scanned without success.  This is not needed
and clutters the log.


- Simon






From swarren at wwwdotorg.org  Thu Apr  4 17:30:01 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Thu, 04 Apr 2013 15:30:01 -0600
Subject: [PATCH v3 07/12] PCI: tegra: Move PCIe driver to drivers/pci/host
In-Reply-To: <515DF096.2000703@wwwdotorg.org>
References: <1365000318-28256-1-git-send-email-thierry.reding@avionic-design.de>
 <1365000318-28256-8-git-send-email-thierry.reding@avionic-design.de>
 <515DF096.2000703@wwwdotorg.org>
Message-ID: <515DF0D9.40007@wwwdotorg.org>

On 04/04/2013 03:28 PM, Stephen Warren wrote:
> On 04/03/2013 08:45 AM, Thierry Reding wrote:
>> Move the PCIe driver from arch/arm/mach-tegra into the drivers/pci/host
>> directory. The motivation is to collect various host controller drivers
>> in the same location in order to facilitate refactoring.
>>
>> The Tegra PCIe driver has been largely rewritten, both in order to turn
>> it into a proper platform driver and to add MSI (based on code by
>> Krishna Kishore <kthota at nvidia.com>) as well as device tree support.
> 
>>  arch/arm/boot/dts/tegra20.dtsi                     |   53 +
> 
> I guess this has to touch both the driver and the dtsi file so that
> bisectabilty isn't broken? I guess that's OK.

Actually, can't you move all the *.dts/*.dtsi changes to the start of
the series, then put the driver conversion patch last, to avoid any
bisectability issues and still keep code and DT changes separate?


From gmbnomis at gmail.com  Thu Apr  4 17:35:17 2013
From: gmbnomis at gmail.com (Simon Baatz)
Date: Thu, 4 Apr 2013 23:35:17 +0200
Subject: [PATCH 3/5 v2] ARM: kirkwood: add device node entries for the
 gigabit interfaces
In-Reply-To: <1365071235-11611-4-git-send-email-florian@openwrt.org>
References: <1365071235-11611-1-git-send-email-florian@openwrt.org>
 <1365071235-11611-4-git-send-email-florian@openwrt.org>
Message-ID: <20130404213517.GB25904@schnuecks.de>

Hi Florian,

On Thu, Apr 04, 2013 at 12:27:13PM +0200, Florian Fainelli wrote:
> This patch modifies kirkwood.dtsi to specify the various gigabit
> interfaces nodes available on kirkwood devices. They are disabled by
> default and should be enabled on a per-board basis. egiga0 and egiga1
> aliases are defined for convenience. The mdio node is also present and
> should be enabled on a per-board basis as well.
> 
> Signed-off-by: Florian Fainelli <florian at openwrt.org>
> ---
> Changes since v1:
> - dropped change to arch/arm/mach-kirkwood/common.c to avoid merge conflicts

I think we should remove the clock aliases in
kirkwood_legacy_clk_init() in mach-kirkwood/dt-board.c (once we have
proper clock support, see my other mail).

> - fixed off-by 0x2000 ethernet-group nodes address
> 
>  arch/arm/boot/dts/kirkwood.dtsi |   46 +++++++++++++++++++++++++++++++++++++++
>  1 file changed, 46 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/kirkwood.dtsi b/arch/arm/boot/dts/kirkwood.dtsi
> index fada7e6..254f5a8 100644
> --- a/arch/arm/boot/dts/kirkwood.dtsi
> +++ b/arch/arm/boot/dts/kirkwood.dtsi
> @@ -7,6 +7,8 @@
>  	aliases {
>  	       gpio0 = &gpio0;
>  	       gpio1 = &gpio1;
> +	       egiga0 = &egiga0;
> +	       egiga1 = &egiga1;
>  	};
>  	intc: interrupt-controller {
>  		compatible = "marvell,orion-intc", "marvell,intc";
> @@ -202,5 +204,49 @@
>  			clocks = <&gate_clk 4>;
>  			status = "disabled";
>  		};
> +
> +		mdio at 72004 {
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +			compatible = "marvell,orion-mdio";
> +			reg = <0x72004 0x84>;

Don't we need to add:

			interrupts = <46>;

here?


- Simon


From swarren at wwwdotorg.org  Thu Apr  4 17:35:39 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Thu,  4 Apr 2013 15:35:39 -0600
Subject: [PATCH V2] clk: tegra: defer application of init table
Message-ID: <1365111340-2143-1-git-send-email-swarren@wwwdotorg.org>

From: Stephen Warren <swarren at nvidia.com>

The Tegra clock driver is initialized during the ARM machine descriptor's
.init_irq() hook. It can't be initialized earlier, since dynamic memory
usage is required. It can't be initialized later, since the .init_timer()
hook needs the clocks initialized. However, at this time, udelay()
doesn't work.

The Tegra clock initialization table may enable some PLLs. Enabling a PLL
may require usage of udelay(). Hence, this can't happen right when the
clock driver is initialized.

To solve this, separate the clock driver initialization from the clock
table processing, so they can execute at separate times.

Signed-off-by: Stephen Warren <swarren at nvidia.com>
---
Mike, the Tegra114 CCF V9 series assume this is applied first. Hence, I'm
looking for an ack on this too. Thanks!

v2: Move this before the main Tegra114 CCF changes, since they assume this
has already been applied. The Tegra114 parts of this patch are now already
included in the Tegra114 driver series v9.

---
 arch/arm/mach-tegra/tegra.c     |    3 +++
 drivers/clk/tegra/clk-tegra20.c |    7 ++++++-
 drivers/clk/tegra/clk-tegra30.c |    7 ++++++-
 drivers/clk/tegra/clk.c         |   10 ++++++++++
 drivers/clk/tegra/clk.h         |    3 +++
 include/linux/clk/tegra.h       |    1 +
 6 files changed, 29 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-tegra/tegra.c b/arch/arm/mach-tegra/tegra.c
index 9cf1ab1..0d1e412 100644
--- a/arch/arm/mach-tegra/tegra.c
+++ b/arch/arm/mach-tegra/tegra.c
@@ -34,6 +34,7 @@
 #include <linux/slab.h>
 #include <linux/sys_soc.h>
 #include <linux/usb/tegra_usb_phy.h>
+#include <linux/clk/tegra.h>
 
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
@@ -85,6 +86,8 @@ static void __init tegra_dt_init(void)
 	struct soc_device *soc_dev;
 	struct device *parent = NULL;
 
+	tegra_clocks_apply_init_table();
+
 	soc_dev_attr = kzalloc(sizeof(*soc_dev_attr), GFP_KERNEL);
 	if (!soc_dev_attr)
 		goto out;
diff --git a/drivers/clk/tegra/clk-tegra20.c b/drivers/clk/tegra/clk-tegra20.c
index b020beb..e90ac64 100644
--- a/drivers/clk/tegra/clk-tegra20.c
+++ b/drivers/clk/tegra/clk-tegra20.c
@@ -1252,6 +1252,11 @@ static __initdata struct tegra_clk_init_table init_table[] = {
 	{clk_max, clk_max, 0, 0}, /* This MUST be the last entry */
 };
 
+static void __init tegra20_clock_apply_init_table(void)
+{
+	tegra_init_from_table(init_table, clks, clk_max);
+}
+
 /*
  * Some clocks may be used by different drivers depending on the board
  * configuration.  List those here to register them twice in the clock lookup
@@ -1318,7 +1323,7 @@ void __init tegra20_clock_init(struct device_node *np)
 	clk_data.clk_num = ARRAY_SIZE(clks);
 	of_clk_add_provider(np, of_clk_src_onecell_get, &clk_data);
 
-	tegra_init_from_table(init_table, clks, clk_max);
+	tegra_clk_apply_init_table = tegra20_clock_apply_init_table;
 
 	tegra_cpu_car_ops = &tegra20_cpu_car_ops;
 }
diff --git a/drivers/clk/tegra/clk-tegra30.c b/drivers/clk/tegra/clk-tegra30.c
index a0c54ad..c851151 100644
--- a/drivers/clk/tegra/clk-tegra30.c
+++ b/drivers/clk/tegra/clk-tegra30.c
@@ -1915,6 +1915,11 @@ static __initdata struct tegra_clk_init_table init_table[] = {
 	{clk_max, clk_max, 0, 0}, /* This MUST be the last entry. */
 };
 
+static void __init tegra30_clock_apply_init_table(void)
+{
+	tegra_init_from_table(init_table, clks, clk_max);
+}
+
 /*
  * Some clocks may be used by different drivers depending on the board
  * configuration.  List those here to register them twice in the clock lookup
@@ -1988,7 +1993,7 @@ void __init tegra30_clock_init(struct device_node *np)
 	clk_data.clk_num = ARRAY_SIZE(clks);
 	of_clk_add_provider(np, of_clk_src_onecell_get, &clk_data);
 
-	tegra_init_from_table(init_table, clks, clk_max);
+	tegra_clk_apply_init_table = tegra30_clock_apply_init_table;
 
 	tegra_cpu_car_ops = &tegra30_cpu_car_ops;
 }
diff --git a/drivers/clk/tegra/clk.c b/drivers/clk/tegra/clk.c
index a603b9a..4a61d15 100644
--- a/drivers/clk/tegra/clk.c
+++ b/drivers/clk/tegra/clk.c
@@ -83,3 +83,13 @@ void __init tegra_clocks_init(void)
 {
 	of_clk_init(tegra_dt_clk_match);
 }
+
+tegra_clk_apply_init_table_func tegra_clk_apply_init_table;
+
+void __init tegra_clocks_apply_init_table(void)
+{
+	if (!tegra_clk_apply_init_table)
+		return;
+
+	tegra_clk_apply_init_table();
+}
diff --git a/drivers/clk/tegra/clk.h b/drivers/clk/tegra/clk.h
index a09d7dc..3c566e2 100644
--- a/drivers/clk/tegra/clk.h
+++ b/drivers/clk/tegra/clk.h
@@ -510,4 +510,7 @@ void tegra30_clock_init(struct device_node *np);
 static inline void tegra30_clock_init(struct device_node *np) {}
 #endif /* CONFIG_ARCH_TEGRA_3x_SOC */
 
+typedef void (*tegra_clk_apply_init_table_func)(void);
+extern tegra_clk_apply_init_table_func tegra_clk_apply_init_table;
+
 #endif /* TEGRA_CLK_H */
diff --git a/include/linux/clk/tegra.h b/include/linux/clk/tegra.h
index 404d6f9..642789b 100644
--- a/include/linux/clk/tegra.h
+++ b/include/linux/clk/tegra.h
@@ -123,5 +123,6 @@ static inline void tegra_cpu_clock_resume(void)
 void tegra_periph_reset_deassert(struct clk *c);
 void tegra_periph_reset_assert(struct clk *c);
 void tegra_clocks_init(void);
+void tegra_clocks_apply_init_table(void);
 
 #endif /* __LINUX_CLK_TEGRA_H_ */
-- 
1.7.10.4



From g.liakhovetski at gmx.de  Thu Apr  4 17:47:05 2013
From: g.liakhovetski at gmx.de (Guennadi Liakhovetski)
Date: Thu, 4 Apr 2013 23:47:05 +0200 (CEST)
Subject: [PATCH/RFC 0/2] ARM: shmobile: DT irqpin for r8a7779 and
 marzen-reference
In-Reply-To: <20130404035426.GC28297@verge.net.au>
References: <Pine.LNX.4.64.1304031103590.10531@axis700.grange>
 <20130404035426.GC28297@verge.net.au>
Message-ID: <Pine.LNX.4.64.1304042325140.21548@axis700.grange>

Hi Simon

On Thu, 4 Apr 2013, Simon Horman wrote:

> On Wed, Apr 03, 2013 at 11:18:57AM +0200, Guennadi Liakhovetski wrote:
> > Hi
> > 
> > This 2 patches add DT irqpin support on marzen-reference. Only 
> > compile-tested due to the lack of hardware. The patches can go 
> > independently via their respective trees. irqpin on marzen will not work 
> > if patch 2 is applied before patch 1, but as long as there are no devices, 
> > using irqpin interrupts, no breakage will be caused.
> 
> I have applied both patches and the dependency I mention below.
> I have also applied the small patch, inlined below, to hook-up
> the LAN controller. Unfortunately it doesn't seem to be receiving
> any interrupts. Perhaps I am missing something?

Are you sure 28 is the correct number in the irqpin IRQ space? Seems 
strange to me. Should be 1 perhaps (counting from 0), or 2 - not sure how 
that mapping would look like.

> > Guennadi Liakhovetski (2):
> >       irqchip: renesas-intc-irqpin: DT binding for sense bitfield width
> 
> The above patch depends on "[1/3] ARM: shmobile: irqpin: fix handling of
> spurious interrupts in DT case", right?

Not functionally. Spurious interrupts occur on sh73a0, the sense bitfield 
is needed for r8a7779. But the latter won't apply without the former, 
that's right.

> Has there been any progress in your
> discussions with Magnus about what to do about that patch?

No, not yet.

Thanks
Guennadi

> >       ARM: shmobile: marzen-reference: add irqpin support in DT
> 
> LAN patch:
> 
> diff --git a/arch/arm/boot/dts/r8a7779-marzen-reference.dts b/arch/arm/boot/dts/r8a7779-marzen-reference.dts
> index 72be4c8..3d98833 100644
> --- a/arch/arm/boot/dts/r8a7779-marzen-reference.dts
> +++ b/arch/arm/boot/dts/r8a7779-marzen-reference.dts
> @@ -38,8 +38,8 @@
>  		compatible = "smsc,lan9220", "smsc,lan9115";
>  		reg = <0x18000000 0x100>;
>  		phy-mode = "mii";
> -		interrupt-parent = <&gic>;
> -		interrupts = <0 28 0x4>;
> +		interrupt-parent = <&irqpin0>;
> +		interrupts = <28 0>;
>  		reg-io-width = <4>;
>  		vddvario-supply = <&fixedregulator3v3>;
>  		vdd33a-supply = <&fixedregulator3v3>;
> 
> 
> Boot log and /proc/interrupts with LAN patch (version without LAN patch is below):
> 
> Booting Linux on physical CPU 0x0
> Linux version 3.9.0-rc2-00003-gd779a6cb-dirty (horms at ayumi.isobedori.kobe.vergenet.net) (gcc version 4.5.2 (Sourcery G++ Lite 2011.03-41) ) #1433 SMP Thu Apr 4 12:43:06 JST 2013
> CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=10c53c7d
> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
> Machine: marzen, model: marzen
> debug: ignoring loglevel setting.
> Memory policy: ECC disabled, Data cache writealloc
> On node 0 totalpages: 262144
> free_area_init_node: node 0, pgdat c03cdb00, node_mem_map c055a000
>   Normal zone: 1520 pages used for memmap
>   Normal zone: 0 pages reserved
>   Normal zone: 194560 pages, LIFO batch:31
>   HighMem zone: 528 pages used for memmap
>   HighMem zone: 67584 pages, LIFO batch:15
> PERCPU: Embedded 5 pages/cpu @c0d62000 s6848 r0 d13632 u32768
> pcpu-alloc: s6848 r0 d13632 u32768 alloc=8*4096
> pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 
> Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 260624
> Kernel command line: console=ttySC2,115200 earlyprintk=sh-sci.2,115200 ignore_loglevel root=/dev/nfs ip=on
> PID hash table entries: 4096 (order: 2, 16384 bytes)
> Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
> Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
> __ex_table already sorted, skipping sort
> Memory: 1024MB = 1024MB total
> Memory: 1035404k/1035404k available, 13172k reserved, 270336K highmem
> Virtual kernel memory layout:
>     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
>     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
>     vmalloc : 0xf0000000 - 0xff000000   ( 240 MB)
>     lowmem  : 0xc0000000 - 0xef800000   ( 760 MB)
>     pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
>       .text : 0xc0008000 - 0xc0380d20   (3556 kB)
>       .init : 0xc0381000 - 0xc03a8ac0   ( 159 kB)
>       .data : 0xc03aa000 - 0xc03ce6c0   ( 146 kB)
>        .bss : 0xc03ce6c0 - 0xc03f9134   ( 171 kB)
> Hierarchical RCU implementation.
> NR_IRQS:16 nr_irqs:16 16
> sched_clock: 32 bits at 1kHz, resolution 976562ns, wraps every 4194303999ms
> Calibrating delay loop (skipped) preset value.. 1000.00 BogoMIPS (lpj=488000)
> pid_max: default: 32768 minimum: 301
> Mount-cache hash table entries: 512
> CPU: Testing write buffer coherency: ok
> Setting up static identity map for 0xc02dc328 - 0xc02dc380
> CPU1: Booted secondary processor
> CPU2: Booted secondary processor
> CPU3: Booted secondary processor
> Brought up 4 CPUs
> SMP: Total of 4 processors activated (4000.00 BogoMIPS).
> CPU: All CPU(s) started in SVC mode.
> devtmpfs: initialized
> pinctrl core: initialized pinctrl subsystem
> NET: Registered protocol family 16
> DMA: preallocated 256 KiB pool for atomic coherent allocations
> sh-pfc pfc-r8a7779: r8a7779_pfc support registered
> renesas_intc_irqpin fe78001c.irqpin: driving 4 irqs
> ------------[ cut here ]------------
> WARNING: at kernel/irq/irqdomain.c:766 irq_linear_revmap+0x3c/0x44()
> [<c000edc0>] (unwind_backtrace+0x0/0xf8) from [<c0017628>] (warn_slowpath_common+0x50/0x64)
> [<c0017628>] (warn_slowpath_common+0x50/0x64) from [<c00176f0>] (warn_slowpath_null+0x1c/0x24)
> [<c00176f0>] (warn_slowpath_null+0x1c/0x24) from [<c006356c>] (irq_linear_revmap+0x3c/0x44)
> [<c006356c>] (irq_linear_revmap+0x3c/0x44) from [<c0063658>] (irq_create_mapping+0x20/0x118)
> [<c0063658>] (irq_create_mapping+0x20/0x118) from [<c00637cc>] (irq_create_of_mapping+0x7c/0x100)
> [<c00637cc>] (irq_create_of_mapping+0x7c/0x100) from [<c0224c00>] (irq_of_parse_and_map+0x30/0x38)
> [<c0224c00>] (irq_of_parse_and_map+0x30/0x38) from [<c0224c20>] (of_irq_to_resource+0x18/0x74)
> [<c0224c20>] (of_irq_to_resource+0x18/0x74) from [<c0224ca0>] (of_irq_count+0x24/0x34)
> [<c0224ca0>] (of_irq_count+0x24/0x34) from [<c0225508>] (of_device_alloc+0x1b8/0x248)
> [<c0225508>] (of_device_alloc+0x1b8/0x248) from [<c02255d4>] (of_platform_device_create_pdata+0x3c/0x80)
> [<c02255d4>] (of_platform_device_create_pdata+0x3c/0x80) from [<c02256ec>] (of_platform_bus_create+0xd4/0x178)
> [<c02256ec>] (of_platform_bus_create+0xd4/0x178) from [<c02258cc>] (of_platform_populate+0x60/0x98)
> [<c02258cc>] (of_platform_populate+0x60/0x98) from [<c0382854>] (customize_machine+0x20/0x28)
> [<c0382854>] (customize_machine+0x20/0x28) from [<c0381834>] (do_one_initcall+0xa0/0x16c)
> [<c0381834>] (do_one_initcall+0xa0/0x16c) from [<c0381a2c>] (kernel_init_freeable+0x12c/0x1d0)
> [<c0381a2c>] (kernel_init_freeable+0x12c/0x1d0) from [<c02cfd6c>] (kernel_init+0x8/0xe8)
> [<c02cfd6c>] (kernel_init+0x8/0xe8) from [<c0009e18>] (ret_from_fork+0x14/0x3c)
> ---[ end trace a30592ddc9049899 ]---
> ------------[ cut here ]------------
> WARNING: at kernel/irq/irqdomain.c:766 irq_linear_revmap+0x3c/0x44()
> [<c000edc0>] (unwind_backtrace+0x0/0xf8) from [<c0017628>] (warn_slowpath_common+0x50/0x64)
> [<c0017628>] (warn_slowpath_common+0x50/0x64) from [<c00176f0>] (warn_slowpath_null+0x1c/0x24)
> [<c00176f0>] (warn_slowpath_null+0x1c/0x24) from [<c006356c>] (irq_linear_revmap+0x3c/0x44)
> [<c006356c>] (irq_linear_revmap+0x3c/0x44) from [<c0063658>] (irq_create_mapping+0x20/0x118)
> [<c0063658>] (irq_create_mapping+0x20/0x118) from [<c00637cc>] (irq_create_of_mapping+0x7c/0x100)
> [<c00637cc>] (irq_create_of_mapping+0x7c/0x100) from [<c0224c00>] (irq_of_parse_and_map+0x30/0x38)
> [<c0224c00>] (irq_of_parse_and_map+0x30/0x38) from [<c0224c20>] (of_irq_to_resource+0x18/0x74)
> [<c0224c20>] (of_irq_to_resource+0x18/0x74) from [<c0224d28>] (of_irq_to_resource_table+0x78/0x94)
> [<c0224d28>] (of_irq_to_resource_table+0x78/0x94) from [<c02254a4>] (of_device_alloc+0x154/0x248)
> [<c02254a4>] (of_device_alloc+0x154/0x248) from [<c02255d4>] (of_platform_device_create_pdata+0x3c/0x80)
> [<c02255d4>] (of_platform_device_create_pdata+0x3c/0x80) from [<c02256ec>] (of_platform_bus_create+0xd4/0x178)
> [<c02256ec>] (of_platform_bus_create+0xd4/0x178) from [<c02258cc>] (of_platform_populate+0x60/0x98)
> [<c02258cc>] (of_platform_populate+0x60/0x98) from [<c0382854>] (customize_machine+0x20/0x28)
> [<c0382854>] (customize_machine+0x20/0x28) from [<c0381834>] (do_one_initcall+0xa0/0x16c)
> [<c0381834>] (do_one_initcall+0xa0/0x16c) from [<c0381a2c>] (kernel_init_freeable+0x12c/0x1d0)
> [<c0381a2c>] (kernel_init_freeable+0x12c/0x1d0) from [<c02cfd6c>] (kernel_init+0x8/0xe8)
> [<c02cfd6c>] (kernel_init+0x8/0xe8) from [<c0009e18>] (ret_from_fork+0x14/0x3c)
> ---[ end trace a30592ddc904989a ]---
> No ATAGs?
> [<c0229260>] (of_platform_device_create_pdata+0x3c/0x80) from [<c0229378>] (of_platform_bus_create+0xd4/0x178)
> [<c0229378>] (of_platform_bus_create+0xd4/0x178) from [<c0229558>] (of_platform_populate+0x60/0x98)
> [<c0229558>] (of_platform_populate+0x60/0x98) from [<c0387714>] (customize_machine+0x20/0x28)
> [<c0387714>] (customize_machine+0x20/0x28) from [<c0385888>] (do_one_initcall+0xa0/0x16c)
> [<c0385888>] (do_one_initcall+0xa0/0x16c) from [<c0385a80>] (kernel_init_freeable+0x12c/0x1d0)
> [<c0385a80>] (kernel_init_freeable+0x12c/0x1d0) from [<c02d39f8>] (kernel_init+0x8/0xe8)
> [<c02d39f8>] (kernel_init+0x8/0xe8) from [<c0009e98>] (ret_from_fork+0x14/0x3c)
> ---[ end trace a30592ddc9049899 ]---
> ------------[ cut here ]------------
> WARNING: at kernel/irq/irqdomain.c:766 irq_linear_revmap+0x3c/0x44()
> [<c000ee40>] (unwind_backtrace+0x0/0xf8) from [<c0017888>] (warn_slowpath_common+0x50/0x64)
> [<c0017888>] (warn_slowpath_common+0x50/0x64) from [<c0017950>] (warn_slowpath_null+0x1c/0x24)
> [<c0017950>] (warn_slowpath_null+0x1c/0x24) from [<c00637cc>] (irq_linear_revmap+0x3c/0x44)
> [<c00637cc>] (irq_linear_revmap+0x3c/0x44) from [<c00638b8>] (irq_create_mapping+0x20/0x118)
> [<c00638b8>] (irq_create_mapping+0x20/0x118) from [<c0063a2c>] (irq_create_of_mapping+0x7c/0x100)
> [<c0063a2c>] (irq_create_of_mapping+0x7c/0x100) from [<c022888c>] (irq_of_parse_and_map+0x30/0x38)
> [<c022888c>] (irq_of_parse_and_map+0x30/0x38) from [<c02288ac>] (of_irq_to_resource+0x18/0x74)
> [<c02288ac>] (of_irq_to_resource+0x18/0x74) from [<c02289b4>] (of_irq_to_resource_table+0x78/0x94)
> [<c02289b4>] (of_irq_to_resource_table+0x78/0x94) from [<c0229130>] (of_device_alloc+0x154/0x248)
> [<c0229130>] (of_device_alloc+0x154/0x248) from [<c0229260>] (of_platform_device_create_pdata+0x3c/0x80)
> [<c0229260>] (of_platform_device_create_pdata+0x3c/0x80) from [<c0229378>] (of_platform_bus_create+0xd4/0x178)
> [<c0229378>] (of_platform_bus_create+0xd4/0x178) from [<c0229558>] (of_platform_populate+0x60/0x98)
> [<c0229558>] (of_platform_populate+0x60/0x98) from [<c0387714>] (customize_machine+0x20/0x28)
> [<c0387714>] (customize_machine+0x20/0x28) from [<c0385888>] (do_one_initcall+0xa0/0x16c)
> [<c0385888>] (do_one_initcall+0xa0/0x16c) from [<c0385a80>] (kernel_init_freeable+0x12c/0x1d0)
> [<c0385a80>] (kernel_init_freeable+0x12c/0x1d0) from [<c02d39f8>] (kernel_init+0x8/0xe8)
> [<c02d39f8>] (kernel_init+0x8/0xe8) from [<c0009e98>] (ret_from_fork+0x14/0x3c)
> ---[ end trace a30592ddc904989a ]---
> No ATAGs?
> bio: create slab <bio-0> at 0
> SCSI subsystem initialized
> libata version 3.00 loaded.
> usbcore: registered new interface driver usbfs
> usbcore: registered new interface driver hub
> usbcore: registered new device driver usb
> sh_tmu sh_tmu.0: used for clock events
> sh_tmu sh_tmu.0: used for periodic clock events
> sh_tmu sh_tmu.1: used as clock source
> Switching to clocksource sh_tmu.1
> Clockevents: could not switch to one-shot mode:
> Clockevents: could not switch to one-shot mode:
> Clockevents: could not switch to one-shot mode:
>  dummy_timer is not functional.
>  dummy_timer is not functional.
> Clockevents: could not switch to one-shot mode: dummy_timer is not functional.
>  dummy_timer is not functional.
> NET: Registered protocol family 2
> TCP established hash table entries: 8192 (order: 4, 65536 bytes)
> TCP bind hash table entries: 8192 (order: 4, 65536 bytes)
> TCP: Hash tables configured (established 8192 bind 8192)
> TCP: reno registered
> UDP hash table entries: 512 (order: 2, 16384 bytes)
> UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
> NET: Registered protocol family 1
> RPC: Registered named UNIX socket transport module.
> RPC: Registered udp transport module.
> RPC: Registered tcp transport module.
> RPC: Registered tcp NFSv4.1 backchannel transport module.
> bounce pool size: 64 pages
> Block layer SCSI generic (bsg) driver version 0.4 loaded (major 254)
> io scheduler noop registered
> io scheduler deadline registered (default)
> gpio_rcar gpio_rcar.0: driving 32 GPIOs
> gpio_rcar gpio_rcar.1: driving 32 GPIOs
> gpio_rcar gpio_rcar.2: driving 32 GPIOs
> gpio_rcar gpio_rcar.3: driving 32 GPIOs
> gpio_rcar gpio_rcar.4: driving 32 GPIOs
> gpio_rcar gpio_rcar.5: driving 32 GPIOs
> gpio_rcar gpio_rcar.6: driving 9 GPIOs
> SuperH SCI(F) driver initialized
> sh-sci.0: ttySC0 at MMIO 0xffe40000 (irq = 120) is a scif
> sh-sci.1: ttySC1 at MMIO 0xffe41000 (irq = 121) is a scif
> sh-sci.2: ttySC2 at MMIO 0xffe42000 (irq = 122) is a scif
> console [ttySC2] enabled
> sh-sci.3: ttySC3 at MMIO 0xffe43000 (irq = 123) is a scif
> sh-sci.4: ttySC4 at MMIO 0xffe44000 (irq = 124) is a scif
> sh-sci.5: ttySC5 at MMIO 0xffe45000 (irq = 125) is a scif
> scsi0 : sata_rcar
> ata1: SATA max UDMA/133 irq 132
> smsc911x: Driver version 2008-10-21
> libphy: smsc911x-mdio: probed
> smsc911x 18000000.lan0 eth0: attached PHY driver [Generic PHY] (mii_bus:phy_addr=18000000.lan0-ff:01, irq=-1)
> smsc911x 18000000.lan0 eth0: MAC Address: 2e:09:0a:00:3c:de
> ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
> ehci-platform: EHCI generic platform driver
> ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
> Initializing USB Mass Storage driver...
> usbcore: registered new interface driver usb-storage
> USB Mass Storage support registered.
> rcar_thermal ffc48000.thermal: 1 sensor proved
> usbcore: registered new interface driver usbhid
> usbhid: USB HID core driver
> TCP: cubic registered
> ata1: link resume succeeded after 1 retries
> ata1: SATA link down (SStatus 0 SControl 300)
> smsc911x 18000000.lan0 eth0: ISR failed signaling test (IRQ 257)
> IP-Config: Failed to open eth0
> IP-Config: No network devices available
> 
> Freeing init memory: 2916K
> 
> 
> boot (Linux 3.9.0-rc2-00003-gd779a6cb-dirty, BusyBox v1.16.0.git, kexec-tools 2.0.1-git)
> / # 
> / # cat /proc/interrupts 
>            CPU0       CPU1       CPU2       CPU3       
>  59:          0          0          0          0       GIC  fe78001c.irqpin
>  60:          0          0          0          0       GIC  fe78001c.irqpin
>  61:          0          0          0          0       GIC  fe78001c.irqpin
>  62:          0          0          0          0       GIC  fe78001c.irqpin
>  64:       8493          0          0          0       GIC  sh_tmu.0
> 122:         48          0          0          0       GIC  sh-sci.2:mux
> 132:          0          0          0          0       GIC  sata_rcar
> 173:          0          0          0          0       GIC  gpio_rcar.0
> 174:          0          0          0          0       GIC  gpio_rcar.1
> 175:          0          0          0          0       GIC  gpio_rcar.2
> 176:          0          0          0          0       GIC  gpio_rcar.3
> 177:          0          0          0          0       GIC  gpio_rcar.4
> 178:          0          0          0          0       GIC  gpio_rcar.5
> 179:          0          0          0          0       GIC  gpio_rcar.6
> 257:          0          0          0          0  fe78001c.irqpin  eth0
> IPI0:          0          0          0          0  CPU wakeup interrupts
> IPI1:          0       7869       8493       8487  Timer broadcast interrupts
> IPI2:        446        503         73         46  Rescheduling interrupts
> IPI3:         21         37         54         56  Function call interrupts
> IPI4:          0          0          0          0  Single function call interrupts
> IPI5:          0          0          0          0  CPU stop interrupts
> Err:          0
> / # 
> 
> Boot log and /proc/interrupts with LAN patch (version without LAN patch is below):
> 
> Booting Linux on physical CPU 0x0
> Linux version 3.9.0-rc2-00003-gd779a6cb (horms at ayumi.isobedori.kobe.vergenet.net) (gcc version 4.5.2 (Sourcery G++ Lite 2011.03-41) ) #1435 SMP Thu Apr 4 12:51:52 JST 2013
> CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=10c53c7d
> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
> Machine: marzen, model: marzen
> debug: ignoring loglevel setting.
> Memory policy: ECC disabled, Data cache writealloc
> On node 0 totalpages: 262144
> free_area_init_node: node 0, pgdat c0683b00, node_mem_map c08fb000
>   Normal zone: 1520 pages used for memmap
>   Normal zone: 0 pages reserved
>   Normal zone: 194560 pages, LIFO batch:31
>   HighMem zone: 528 pages used for memmap
>   HighMem zone: 67584 pages, LIFO batch:15
> PERCPU: Embedded 5 pages/cpu @c1103000 s6848 r0 d13632 u32768
> pcpu-alloc: s6848 r0 d13632 u32768 alloc=8*4096
> pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 
> Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 260624
> Kernel command line: console=ttySC2,115200 earlyprintk=sh-sci.2,115200 ignore_loglevel root=/dev/nfs ip=on
> PID hash table entries: 4096 (order: 2, 16384 bytes)
> Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
> Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
> __ex_table already sorted, skipping sort
> Memory: 1024MB = 1024MB total
> Memory: 1032628k/1032628k available, 15948k reserved, 270336K highmem
> Virtual kernel memory layout:
>     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
>     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
>     vmalloc : 0xf0000000 - 0xff000000   ( 240 MB)
>     lowmem  : 0xc0000000 - 0xef800000   ( 760 MB)
>     pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
>       .text : 0xc0008000 - 0xc0384e4c   (3572 kB)
>       .init : 0xc0385000 - 0xc065eac0   (2919 kB)
>       .data : 0xc0660000 - 0xc06846c0   ( 146 kB)
>        .bss : 0xc06846c0 - 0xc06af174   ( 171 kB)
> Hierarchical RCU implementation.
> NR_IRQS:16 nr_irqs:16 16
> sched_clock: 32 bits at 1kHz, resolution 976562ns, wraps every 4194303999ms
> Calibrating delay loop (skipped) preset value.. 1000.00 BogoMIPS (lpj=488000)
> pid_max: default: 32768 minimum: 301
> Mount-cache hash table entries: 512
> CPU: Testing write buffer coherency: ok
> Setting up static identity map for 0xc02df328 - 0xc02df380
> CPU1: Booted secondary processor
> CPU2: Booted secondary processor
> CPU3: Booted secondary processor
> Brought up 4 CPUs
> SMP: Total of 4 processors activated (4000.00 BogoMIPS).
> CPU: All CPU(s) started in SVC mode.
> devtmpfs: initialized
> pinctrl core: initialized pinctrl subsystem
> NET: Registered protocol family 16
> DMA: preallocated 256 KiB pool for atomic coherent allocations
> sh-pfc pfc-r8a7779: r8a7779_pfc support registered
> renesas_intc_irqpin fe78001c.irqpin: driving 4 irqs
> No ATAGs?
> bio: create slab <bio-0> at 0
> SCSI subsystem initialized
> libata version 3.00 loaded.
> usbcore: registered new interface driver usbfs
> usbcore: registered new interface driver hub
> usbcore: registered new device driver usb
> sh_tmu sh_tmu.0: used for clock events
> sh_tmu sh_tmu.0: used for periodic clock events
> sh_tmu sh_tmu.1: used as clock source
> Switching to clocksource sh_tmu.1
> Clockevents: could not switch to one-shot mode:
> Clockevents: could not switch to one-shot mode:
> Clockevents: could not switch to one-shot mode:
>  dummy_timer is not functional.
>  dummy_timer is not functional.
> Clockevents: could not switch to one-shot mode: dummy_timer is not functional.
>  dummy_timer is not functional.
> NET: Registered protocol family 2
> TCP established hash table entries: 8192 (order: 4, 65536 bytes)
> TCP bind hash table entries: 8192 (order: 4, 65536 bytes)
> TCP: Hash tables configured (established 8192 bind 8192)
> TCP: reno registered
> UDP hash table entries: 512 (order: 2, 16384 bytes)
> UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
> NET: Registered protocol family 1
> RPC: Registered named UNIX socket transport module.
> RPC: Registered udp transport module.
> RPC: Registered tcp transport module.
> RPC: Registered tcp NFSv4.1 backchannel transport module.
> bounce pool size: 64 pages
> Block layer SCSI generic (bsg) driver version 0.4 loaded (major 254)
> io scheduler noop registered
> io scheduler deadline registered (default)
> gpio_rcar gpio_rcar.0: driving 32 GPIOs
> gpio_rcar gpio_rcar.1: driving 32 GPIOs
> gpio_rcar gpio_rcar.2: driving 32 GPIOs
> gpio_rcar gpio_rcar.3: driving 32 GPIOs
> gpio_rcar gpio_rcar.4: driving 32 GPIOs
> gpio_rcar gpio_rcar.5: driving 32 GPIOs
> gpio_rcar gpio_rcar.6: driving 9 GPIOs
> SuperH SCI(F) driver initialized
> sh-sci.0: ttySC0 at MMIO 0xffe40000 (irq = 120) is a scif
> sh-sci.1: ttySC1 at MMIO 0xffe41000 (irq = 121) is a scif
> sh-sci.2: ttySC2 at MMIO 0xffe42000 (irq = 122) is a scif
> console [ttySC2] enabled
> sh-sci.3: ttySC3 at MMIO 0xffe43000 (irq = 123) is a scif
> sh-sci.4: ttySC4 at MMIO 0xffe44000 (irq = 124) is a scif
> sh-sci.5: ttySC5 at MMIO 0xffe45000 (irq = 125) is a scif
> scsi0 : sata_rcar
> ata1: SATA max UDMA/133 irq 132
> smsc911x: Driver version 2008-10-21
> genirq: Flags mismatch irq 60. 00000080 (eth%d) vs. 00000000 (fe78001c.irqpin)
> smsc911x: probe of 18000000.lan0 failed with error -16
> ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
> ehci-platform: EHCI generic platform driver
> ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
> Initializing USB Mass Storage driver...
> usbcore: registered new interface driver usb-storage
> USB Mass Storage support registered.
> rcar_thermal ffc48000.thermal: 1 sensor proved
> usbcore: registered new interface driver usbhid
> usbhid: USB HID core driver
> TCP: cubic registered
> ata1: link resume succeeded after 1 retries
> ata1: SATA link down (SStatus 0 SControl 300)
> Freeing init memory: 2916K
> 
> 
> boot (Linux 3.9.0-rc2-00003-gd779a6cb, BusyBox v1.16.0.git, kexec-tools 2.0.1-git)
> / # cat /proc/interrupts 
>            CPU0       CPU1       CPU2       CPU3       
>  59:          0          0          0          0       GIC  fe78001c.irqpin
>  60:          0          0          0          0       GIC  fe78001c.irqpin
>  61:          0          0          0          0       GIC  fe78001c.irqpin
>  62:          0          0          0          0       GIC  fe78001c.irqpin
>  64:      49198          0          0          0       GIC  sh_tmu.0
> 122:         45          0          0          0       GIC  sh-sci.2:mux
> 132:          0          0          0          0       GIC  sata_rcar
> 173:          0          0          0          0       GIC  gpio_rcar.0
> 174:          0          0          0          0       GIC  gpio_rcar.1
> 175:          0          0          0          0       GIC  gpio_rcar.2
> 176:          0          0          0          0       GIC  gpio_rcar.3
> 177:          0          0          0          0       GIC  gpio_rcar.4
> 178:          0          0          0          0       GIC  gpio_rcar.5
> 179:          0          0          0          0       GIC  gpio_rcar.6
> IPI0:          0          0          0          0  CPU wakeup interrupts
> IPI1:          0      49192      49198      48802  Timer broadcast interrupts
> IPI2:        437        478         87         88  Rescheduling interrupts
> IPI3:         56         37         36         39  Function call interrupts
> IPI4:          0          0          0          0  Single function call interrupts
> IPI5:          0          0          0          0  CPU stop interrupts
> Err:  
> 

---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/


From s-anna at ti.com  Thu Apr  4 17:48:16 2013
From: s-anna at ti.com (Anna, Suman)
Date: Thu, 4 Apr 2013 21:48:16 +0000
Subject: [GIT PULL] mailbox driver framework for v3.10 merge window
Message-ID: <37C860A02101E749A747FA2D3C1E3C504A1971@DLEE11.ent.ti.com>

The following changes since commit f6161aa153581da4a3867a2d1a7caf4be19b6ec9: 

        Linux 3.9-rc2 (2013-03-10 16:54:19 -0700)

are available in the git repository at:

        git://github.com/sumananna/mailbox.git dbx500-prcmu-mailbox

for you to fetch changes up to c497eba5247728c67ba0e0de0907723dd114134a:

        mailbox: fix invalid use of sizeof in mailbox_msg_send() (2013-03-23 15:04:14 +0800)

------------------------------------------------------------------------------
OMAP and ST-Ericsson platforms are both using mailbox to communicate with some coprocessors. This series creates a consolidated framework, living under drivers/mailbox.
The changes mainly contain:
- create a mailbox framework independent from OMAP h/w
- creates dbx500 mailbox driver for ST-Ericsson platforms
- move the omap mailbox out of plat-omap/mach-omapX  adapting to the new framework.
- minor bug fixes in mailbox code

This series is needed for the work currently being done on the PRCMU driver.
------------------------------------------------------------------------------

Loic Pallardy (7):
  mailbox: rename omap_mbox in mailbox
  mailbox: create opened message type
  mailbox: change protection mechanisms
  mailbox: add shared memory mailbox type
  mailbox: add IRQF_NO_SUSPEND flag
  mailbox: add no_irq send message
  mailbox: create dbx500 mailbox driver

Omar Ramirez Luna (2):
  mailbox: OMAP: introduce mailbox framework
  mailbox: split internal header from API header

Suman Anna (5):
  mailbox: rename pl320-ipc specific mailbox.h
  ARM: OMAP2+: mbox: remove dependencies with soc.h
  mailbox/omap: check iomem resource before dereferencing it
  mailbox: check for NULL nb in mailbox_put
  mailbox: call request_irq after mbox queues are allocated

Wei Yongjun (1):
  mailbox: fix invalid use of sizeof in mailbox_msg_send()

 .../devicetree/bindings/mailbox/dbx500-mailbox.txt |  27 +
 arch/arm/configs/omap1_defconfig                   |   3 +-
 arch/arm/mach-omap1/Makefile                       |   4 -
 arch/arm/mach-omap1/mailbox.c                      | 199 -------
 arch/arm/mach-omap2/Makefile                       |   3 -
 arch/arm/mach-omap2/devices.c                      |  13 +-
 arch/arm/mach-omap2/mailbox.c                      | 430 --------------
 arch/arm/mach-omap2/omap_hwmod_2420_data.c         |  12 +
 arch/arm/mach-omap2/omap_hwmod_2430_data.c         |  11 +
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c         |  11 +
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c         |  13 +
 arch/arm/plat-omap/Kconfig                         |  16 -
 arch/arm/plat-omap/Makefile                        |   3 -
 arch/arm/plat-omap/include/plat/mailbox.h          | 105 ----
 arch/arm/plat-omap/mailbox.c                       | 435 --------------
 drivers/cpufreq/highbank-cpufreq.c                 |   2 +-
 drivers/mailbox/Kconfig                            |  41 ++
 drivers/mailbox/Makefile                           |   5 +
 drivers/mailbox/mailbox-dbx500.c                   | 648 +++++++++++++++++++++
 drivers/mailbox/mailbox-omap1.c                    | 229 ++++++++
 drivers/mailbox/mailbox-omap2.c                    | 370 ++++++++++++
 drivers/mailbox/mailbox.c                          | 552 ++++++++++++++++++
 drivers/mailbox/mailbox_internal.h                 |  70 +++
 drivers/mailbox/pl320-ipc.c                        |   2 +-
 drivers/remoteproc/Kconfig                         |   3 +-
 drivers/remoteproc/omap_remoteproc.c               |  36 +-
 drivers/staging/tidspbridge/Kconfig                |   3 +-
 drivers/staging/tidspbridge/core/_tiomap.h         |   2 +-
 drivers/staging/tidspbridge/core/chnl_sm.c         |   8 +-
 drivers/staging/tidspbridge/core/io_sm.c           |   5 +-
 drivers/staging/tidspbridge/core/tiomap3430.c      |   6 +-
 drivers/staging/tidspbridge/core/tiomap3430_pwr.c  |   6 +-
 drivers/staging/tidspbridge/core/tiomap_io.c       |   9 +-
 .../tidspbridge/include/dspbridge/host_os.h        |   2 +-
 include/linux/mailbox.h                            |  52 +-
 include/linux/pl320-ipc.h                          |  17 +
 include/linux/platform_data/mailbox-dbx500.h       |  12 +
 include/linux/platform_data/mailbox-omap.h         |  53 ++
 38 files changed, 2170 insertions(+), 1248 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/mailbox/dbx500-mailbox.txt
 delete mode 100644 arch/arm/mach-omap1/mailbox.c
 delete mode 100644 arch/arm/mach-omap2/mailbox.c
 delete mode 100644 arch/arm/plat-omap/include/plat/mailbox.h
 delete mode 100644 arch/arm/plat-omap/mailbox.c
 create mode 100644 drivers/mailbox/mailbox-dbx500.c
 create mode 100644 drivers/mailbox/mailbox-omap1.c
 create mode 100644 drivers/mailbox/mailbox-omap2.c
 create mode 100644 drivers/mailbox/mailbox.c
 create mode 100644 drivers/mailbox/mailbox_internal.h
 create mode 100644 include/linux/pl320-ipc.h
 create mode 100644 include/linux/platform_data/mailbox-dbx500.h
 create mode 100644 include/linux/platform_data/mailbox-omap.h

--


From g.liakhovetski at gmx.de  Thu Apr  4 17:54:20 2013
From: g.liakhovetski at gmx.de (Guennadi Liakhovetski)
Date: Thu, 4 Apr 2013 23:54:20 +0200 (CEST)
Subject: [PATCH v4 3/3] ARM: shmobile: kzm9g-reference: add CPUFreq support
In-Reply-To: <20130404043746.GD28297@verge.net.au>
References: <1364153255-20664-1-git-send-email-g.liakhovetski@gmx.de>
 <1364153255-20664-4-git-send-email-g.liakhovetski@gmx.de>
 <20130404043746.GD28297@verge.net.au>
Message-ID: <Pine.LNX.4.64.1304042352180.21548@axis700.grange>

Hi Simon

Thanks for the review

On Thu, 4 Apr 2013, Simon Horman wrote:

> On Sun, Mar 24, 2013 at 08:27:35PM +0100, Guennadi Liakhovetski wrote:
> > This patch enables the use of the generic cpufreq-cpu0 driver on kzm9g.
> > Providing a regulator, a list of OPPs in DT, combined with a virtual
> > cpufreq-cpu0 platform device and a clock, attached to it is everything,
> > the cpufreq-cpu0 driver needs.
> 
> I wonder if it would be possible to re-arange this patch a little.
> 
> 1) vdd_dvfs is added in this patch but it appears to be used in the
>    previous patch in the series. I wonder if this can be resolved
>    by re-ordering the patches.

Right, I'll change that.

> 2) It includes both kzm9g board and sh73a0 SoC changes.
>    I would prefer if the sh73a0 SoC portion (setup-sh73a0.c)
>    was moved into a separate patch. The arm-soc people
>    like to have separate board and SoC branches.

Yes, I'll probably just merge the sh73a0-kzm9g-reference.dts hunk into the 
previous patch.

Thanks
Guennadi

> 
> > Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas at gmail.com>
> > ---
> > 
> > v4: add a cpufreq-cpu0 platform device for the new cpufreq-cpu0 
> > initialisation procedure
> > 
> >  arch/arm/boot/dts/sh73a0-kzm9g-reference.dts |    6 +++---
> >  arch/arm/mach-shmobile/Kconfig               |    2 ++
> >  arch/arm/mach-shmobile/setup-sh73a0.c        |    5 +++++
> >  3 files changed, 10 insertions(+), 3 deletions(-)
> > 
> > diff --git a/arch/arm/boot/dts/sh73a0-kzm9g-reference.dts b/arch/arm/boot/dts/sh73a0-kzm9g-reference.dts
> > index dd1cd80..b6f759e 100644
> > --- a/arch/arm/boot/dts/sh73a0-kzm9g-reference.dts
> > +++ b/arch/arm/boot/dts/sh73a0-kzm9g-reference.dts
> > @@ -78,10 +78,10 @@
> >  		reg = <0x40>;
> >  
> >  		regulators {
> > -			sd1 {
> > +			vdd_dvfs: sd1 {
> >  				regulator-name = "1.315V CPU";
> > -				regulator-min-microvolt = <1315000>;
> > -				regulator-max-microvolt = <1335000>;
> > +				regulator-min-microvolt = <1050000>;
> > +				regulator-max-microvolt = <1350000>;
> >  				regulator-always-on;
> >  				regulator-boot-on;
> >  			};
> > diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
> > index eb3a7ff..8a0420b 100644
> > --- a/arch/arm/mach-shmobile/Kconfig
> > +++ b/arch/arm/mach-shmobile/Kconfig
> > @@ -134,6 +134,8 @@ config MACH_KZM9G
> >  config MACH_KZM9G_REFERENCE
> >  	bool "KZM-A9-GT board - Reference Device Tree Implementation"
> >  	depends on ARCH_SH73A0
> > +	select ARCH_HAS_CPUFREQ
> > +	select ARCH_HAS_OPP
> >  	select ARCH_REQUIRE_GPIOLIB
> >  	select REGULATOR_FIXED_VOLTAGE if REGULATOR
> >  	select SND_SOC_AK4642 if SND_SIMPLE_CARD
> > diff --git a/arch/arm/mach-shmobile/setup-sh73a0.c b/arch/arm/mach-shmobile/setup-sh73a0.c
> > index e8cd93a..0469e84 100644
> > --- a/arch/arm/mach-shmobile/setup-sh73a0.c
> > +++ b/arch/arm/mach-shmobile/setup-sh73a0.c
> > @@ -1016,6 +1016,8 @@ static const struct of_dev_auxdata sh73a0_auxdata_lookup[] __initconst = {
> >  
> >  void __init sh73a0_add_standard_devices_dt(void)
> >  {
> > +	struct platform_device_info devinfo = { .name = "cpufreq-cpu0", .id = -1, };
> > +
> >  	/* clocks are setup late during boot in the case of DT */
> >  	sh73a0_clock_init();
> >  
> > @@ -1023,6 +1025,9 @@ void __init sh73a0_add_standard_devices_dt(void)
> >  			     ARRAY_SIZE(sh73a0_devices_dt));
> >  	of_platform_populate(NULL, of_default_bus_match_table,
> >  			     sh73a0_auxdata_lookup, NULL);
> > +
> > +	/* Instantiate cpufreq-cpu0 */
> > +	platform_device_register_full(&devinfo);
> >  }
> >  
> >  static const char *sh73a0_boards_compat_dt[] __initdata = {
> > -- 
> > 1.7.2.5
> > 
> 

---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/


From maxime.ripard at free-electrons.com  Thu Apr  4 18:01:10 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Fri, 05 Apr 2013 00:01:10 +0200
Subject: [PATCH v2 0/6] clk: sunxi: gates support
In-Reply-To: <1364419243-18446-1-git-send-email-emilio@elopez.com.ar>
References: <1363962042-29536-1-git-send-email-emilio@elopez.com.ar>
 <1364419243-18446-1-git-send-email-emilio@elopez.com.ar>
Message-ID: <515DF826.2070408@free-electrons.com>

Hi,

Le 27/03/2013 22:20, Emilio L?pez a ?crit :
> Hi,
> 
> This patchset adds support for the main sunxi gates; namely, those found 
> on AXI, AHB, APB0 and APB1 clocks. The series depends on Maxime's UART 
> rework and on the basic sunxi clock driver by me.
> 
> Patches 1 and 2 implement the actual gate support, and patch 3 switches 
> the UARTs to use the correct gates now that they are available.
> 
> Patch 4 and 5 add clock support to our pinctrl driver, as we need to 
> keep the pio clock running for gpio to work.
> 
> Patch 6 drops the ignore flags; now that we have actual clock users that 
> will keep the important clocks running.
> 
> Patch 7 is an unrelated oneliner to remove an unnecesary kmalloc call.
> 
> The main changes from v1 are renamed compatible strings and a clarification
> on the documentation, see each individual patch for more details.

I merged the patches 2, 3 and 5 into my sunxi/dt-for-3.10 branch.

Thanks,
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


From geoff at infradead.org  Thu Apr  4 18:10:53 2013
From: geoff at infradead.org (Geoff Levand)
Date: Thu, 04 Apr 2013 15:10:53 -0700
Subject: [PATCH 6/7] ARM: KVM: switch to a dual-step HYP init code
In-Reply-To: <1364909115-3810-7-git-send-email-marc.zyngier@arm.com>
References: <1364909115-3810-1-git-send-email-marc.zyngier@arm.com>
 <1364909115-3810-7-git-send-email-marc.zyngier@arm.com>
Message-ID: <1365113453.24496.26.camel@smoke>

Hi,

On Tue, 2013-04-02 at 14:25 +0100, Marc Zyngier wrote:
> +	@ Jump to the trampoline page
> +	ldr	r2, =#PAGE_MASK
> +	adr	r3, target
> +	bic	r3, r3, r2
> +	ldr	r2, =#TRAMPOLINE_VA
> +	add	r3, r3, r2
> +	mov	pc, r3

I guess you need 'ldr r2, =PAGE_MASK'.

  arch/arm/kvm/init.S:114: Error: bad expression -- `ldr r2,=#(~((1<<12)-1))'
  arch/arm/kvm/init.S:117: Error: bad expression -- `ldr r2,=#0xffff0000'

-Geoff




From rjw at sisk.pl  Thu Apr  4 18:30:30 2013
From: rjw at sisk.pl (Rafael J. Wysocki)
Date: Fri, 05 Apr 2013 00:30:30 +0200
Subject: [PATCH 1/9] ARM: cpuidle: remove useless declaration
In-Reply-To: <1364991322-20585-1-git-send-email-daniel.lezcano@linaro.org>
References: <1364991322-20585-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <2872594.RzEdba6jp9@vostro.rjw.lan>

On Wednesday, April 03, 2013 02:15:14 PM Daniel Lezcano wrote:
> The noop functions code is not necessary because the header file is
> included in files which are compiled when CONFIG_CPU_IDLE is on.
> 
> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>

I need an ACK for this one.

Thanks,
Rafael


> ---
>  arch/arm/include/asm/cpuidle.h |    7 +------
>  1 file changed, 1 insertion(+), 6 deletions(-)
> 
> diff --git a/arch/arm/include/asm/cpuidle.h b/arch/arm/include/asm/cpuidle.h
> index 2fca60a..7367787 100644
> --- a/arch/arm/include/asm/cpuidle.h
> +++ b/arch/arm/include/asm/cpuidle.h
> @@ -1,13 +1,8 @@
>  #ifndef __ASM_ARM_CPUIDLE_H
>  #define __ASM_ARM_CPUIDLE_H
>  
> -#ifdef CONFIG_CPU_IDLE
>  extern int arm_cpuidle_simple_enter(struct cpuidle_device *dev,
> -		struct cpuidle_driver *drv, int index);
> -#else
> -static inline int arm_cpuidle_simple_enter(struct cpuidle_device *dev,
> -		struct cpuidle_driver *drv, int index) { return -ENODEV; }
> -#endif
> +				    struct cpuidle_driver *drv, int index);
>  
>  /* Common ARM WFI state */
>  #define ARM_CPUIDLE_WFI_STATE_PWR(p) {\
> 
-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.


From rjw at sisk.pl  Thu Apr  4 18:31:42 2013
From: rjw at sisk.pl (Rafael J. Wysocki)
Date: Fri, 05 Apr 2013 00:31:42 +0200
Subject: [PATCH 7/9] intel: cpuidle: remove stop/start critical timings
In-Reply-To: <1364991322-20585-7-git-send-email-daniel.lezcano@linaro.org>
References: <1364991322-20585-1-git-send-email-daniel.lezcano@linaro.org>
 <1364991322-20585-7-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <3375360.P4DAA9Jd5Y@vostro.rjw.lan>

On Wednesday, April 03, 2013 02:15:20 PM Daniel Lezcano wrote:
> The start/stop_critical_timings are called from arch/x86/kernel/process.c
> in the cpu_idle loop function.
> 
> Remove the ones in the cpuidle driver.
> 
> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>

For this one I need an ACK from Len.

Len, any objections?

Rafael


> ---
>  drivers/idle/intel_idle.c |    3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/drivers/idle/intel_idle.c b/drivers/idle/intel_idle.c
> index 5d66750..c99c31e 100644
> --- a/drivers/idle/intel_idle.c
> +++ b/drivers/idle/intel_idle.c
> @@ -339,7 +339,6 @@ static int intel_idle(struct cpuidle_device *dev,
>  	if (!(lapic_timer_reliable_states & (1 << (cstate))))
>  		clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &cpu);
>  
> -	stop_critical_timings();
>  	if (!need_resched()) {
>  
>  		__monitor((void *)&current_thread_info()->flags, 0, 0);
> @@ -348,8 +347,6 @@ static int intel_idle(struct cpuidle_device *dev,
>  			__mwait(eax, ecx);
>  	}
>  
> -	start_critical_timings();
> -
>  	if (!(lapic_timer_reliable_states & (1 << (cstate))))
>  		clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &cpu);
>  
> 
-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.


From sergei.shtylyov at cogentembedded.com  Thu Apr  4 18:51:43 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Fri, 5 Apr 2013 02:51:43 +0400
Subject: [PATCH 0/8] Reorganize R8A7779/Marzen USB code
Message-ID: <201304050251.44464.sergei.shtylyov@cogentembedded.com>

Hello.

   Here's the set of 4 patches against the Simon Horman's 'renesas.git' repo,
'renesas-next-20130404v2' tag and the 2 Ether patches I've reposted yesterday.
It was created to fix the shortcomings in the R8A7779/Marzen USB platform code
and R8A7779 USB common PHY driver, and so spans both arch/arm/mach-shmobile/
and drivers/usb/ subtrees (some patches have to touch both subtrees).
The patches were conceived with the complete bisectability goal in mind.

[1/8] ARM: shmobile:Marzen: move USB EHCI, OHCI, and PHY devices to R8A7779 code
[2/8] ehci-platform: add init() method to platform data
[3/8] ARM: shmobile: R8A7779: setup EHCI internal buffer
[4/8] rcar-phy: remove EHCI internal buffer setup
[5/8] rcar-phy: correct base address
[6/8] rcar-phy: add platform data
[7/8] ARM: shmobile: Marzen: pass platform data to USB PHY device
[8/8] rcar-phy: handle platform data

   I'm not sure thru which tree this patchset should be merged, however it turns
out that it's too late now to push it thru Felipe Balbi's USB tree for 3.10, so
maybe the patchset can be merged thru Simon's tree with Felipe's and Alan
Stern's ACKs.

WBR, Sergei


From sergei.shtylyov at cogentembedded.com  Thu Apr  4 18:57:00 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Fri, 5 Apr 2013 02:57:00 +0400
Subject: [PATCH 1/8] ARM: shmobile:Marzen: move USB EHCI, OHCI,
 and PHY devices to R8A7779 code
Message-ID: <201304050257.00799.sergei.shtylyov@cogentembedded.com>

USB EHCI, OHCI, and common PHY are the SoC devices but are wrongly defined and
registered in the Marzen board file.  Move the data and code to their proper
place in setup-r8a7779.c; while at it, we have to rename 8a7779_late_devices[]
to 8a7779_standard_devices[] -- this seems legitimate since they are registered
from r8a7779_add_standard_devices() anyway.

Note that I'm deliberately changing the USB PHY platform device's 'id' field
from (previously just omitted) 0 to -1 as the device is a single of its kind.

Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

---
 arch/arm/mach-shmobile/board-marzen.c         |  178 -------------------------
 arch/arm/mach-shmobile/include/mach/r8a7779.h |    1 
 arch/arm/mach-shmobile/setup-r8a7779.c        |  185 +++++++++++++++++++++++++-
 3 files changed, 184 insertions(+), 180 deletions(-)

Index: renesas/arch/arm/mach-shmobile/board-marzen.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/board-marzen.c
+++ renesas/arch/arm/mach-shmobile/board-marzen.c
@@ -36,10 +36,6 @@
 #include <linux/mmc/host.h>
 #include <linux/mmc/sh_mobile_sdhi.h>
 #include <linux/mfd/tmio.h>
-#include <linux/usb/otg.h>
-#include <linux/usb/ehci_pdriver.h>
-#include <linux/usb/ohci_pdriver.h>
-#include <linux/pm_runtime.h>
 #include <mach/hardware.h>
 #include <mach/r8a7779.h>
 #include <mach/common.h>
@@ -149,26 +145,6 @@ static struct platform_device hspi_devic
 	.num_resources	= ARRAY_SIZE(hspi_resources),
 };
 
-/* USB PHY */
-static struct resource usb_phy_resources[] = {
-	[0] = {
-		.start		= 0xffe70000,
-		.end		= 0xffe70900 - 1,
-		.flags		= IORESOURCE_MEM,
-	},
-	[1] = {
-		.start		= 0xfff70000,
-		.end		= 0xfff70900 - 1,
-		.flags		= IORESOURCE_MEM,
-	},
-};
-
-static struct platform_device usb_phy_device = {
-	.name		= "rcar_usb_phy",
-	.resource	= usb_phy_resources,
-	.num_resources	= ARRAY_SIZE(usb_phy_resources),
-};
-
 /* LEDS */
 static struct gpio_led marzen_leds[] = {
 	{
@@ -204,161 +180,9 @@ static struct platform_device *marzen_de
 	&sdhi0_device,
 	&thermal_device,
 	&hspi_device,
-	&usb_phy_device,
 	&leds_device,
 };
 
-/* USB */
-static struct usb_phy *phy;
-static int usb_power_on(struct platform_device *pdev)
-{
-	if (!phy)
-		return -EIO;
-
-	pm_runtime_enable(&pdev->dev);
-	pm_runtime_get_sync(&pdev->dev);
-
-	usb_phy_init(phy);
-
-	return 0;
-}
-
-static void usb_power_off(struct platform_device *pdev)
-{
-	if (!phy)
-		return;
-
-	usb_phy_shutdown(phy);
-
-	pm_runtime_put_sync(&pdev->dev);
-	pm_runtime_disable(&pdev->dev);
-}
-
-static struct usb_ehci_pdata ehcix_pdata = {
-	.power_on	= usb_power_on,
-	.power_off	= usb_power_off,
-	.power_suspend	= usb_power_off,
-};
-
-static struct resource ehci0_resources[] = {
-	[0] = {
-		.start	= 0xffe70000,
-		.end	= 0xffe70400 - 1,
-		.flags	= IORESOURCE_MEM,
-	},
-	[1] = {
-		.start	= gic_iid(0x4c),
-		.flags	= IORESOURCE_IRQ,
-	},
-};
-
-static struct platform_device ehci0_device = {
-	.name	= "ehci-platform",
-	.id	= 0,
-	.dev	= {
-		.dma_mask		= &ehci0_device.dev.coherent_dma_mask,
-		.coherent_dma_mask	= 0xffffffff,
-		.platform_data		= &ehcix_pdata,
-	},
-	.num_resources	= ARRAY_SIZE(ehci0_resources),
-	.resource	= ehci0_resources,
-};
-
-static struct resource ehci1_resources[] = {
-	[0] = {
-		.start	= 0xfff70000,
-		.end	= 0xfff70400 - 1,
-		.flags	= IORESOURCE_MEM,
-	},
-	[1] = {
-		.start	= gic_iid(0x4d),
-		.flags	= IORESOURCE_IRQ,
-	},
-};
-
-static struct platform_device ehci1_device = {
-	.name	= "ehci-platform",
-	.id	= 1,
-	.dev	= {
-		.dma_mask		= &ehci1_device.dev.coherent_dma_mask,
-		.coherent_dma_mask	= 0xffffffff,
-		.platform_data		= &ehcix_pdata,
-	},
-	.num_resources	= ARRAY_SIZE(ehci1_resources),
-	.resource	= ehci1_resources,
-};
-
-static struct usb_ohci_pdata ohcix_pdata = {
-	.power_on	= usb_power_on,
-	.power_off	= usb_power_off,
-	.power_suspend	= usb_power_off,
-};
-
-static struct resource ohci0_resources[] = {
-	[0] = {
-		.start	= 0xffe70400,
-		.end	= 0xffe70800 - 1,
-		.flags	= IORESOURCE_MEM,
-	},
-	[1] = {
-		.start	= gic_iid(0x4c),
-		.flags	= IORESOURCE_IRQ,
-	},
-};
-
-static struct platform_device ohci0_device = {
-	.name	= "ohci-platform",
-	.id	= 0,
-	.dev	= {
-		.dma_mask		= &ohci0_device.dev.coherent_dma_mask,
-		.coherent_dma_mask	= 0xffffffff,
-		.platform_data		= &ohcix_pdata,
-	},
-	.num_resources	= ARRAY_SIZE(ohci0_resources),
-	.resource	= ohci0_resources,
-};
-
-static struct resource ohci1_resources[] = {
-	[0] = {
-		.start	= 0xfff70400,
-		.end	= 0xfff70800 - 1,
-		.flags	= IORESOURCE_MEM,
-	},
-	[1] = {
-		.start	= gic_iid(0x4d),
-		.flags	= IORESOURCE_IRQ,
-	},
-};
-
-static struct platform_device ohci1_device = {
-	.name	= "ohci-platform",
-	.id	= 1,
-	.dev	= {
-		.dma_mask		= &ohci1_device.dev.coherent_dma_mask,
-		.coherent_dma_mask	= 0xffffffff,
-		.platform_data		= &ohcix_pdata,
-	},
-	.num_resources	= ARRAY_SIZE(ohci1_resources),
-	.resource	= ohci1_resources,
-};
-
-static struct platform_device *marzen_late_devices[] __initdata = {
-	&ehci0_device,
-	&ehci1_device,
-	&ohci0_device,
-	&ohci1_device,
-};
-
-void __init marzen_init_late(void)
-{
-	/* get usb phy */
-	phy = usb_get_phy(USB_PHY_TYPE_USB2);
-
-	shmobile_init_late();
-	platform_add_devices(marzen_late_devices,
-			     ARRAY_SIZE(marzen_late_devices));
-}
-
 static const struct pinctrl_map marzen_pinctrl_map[] = {
 	/* HSPI0 */
 	PIN_MAP_MUX_GROUP_DEFAULT("sh-hspi.0", "pfc-r8a7779",
@@ -416,6 +240,6 @@ MACHINE_START(MARZEN, "marzen")
 	.nr_irqs	= NR_IRQS_LEGACY,
 	.init_irq	= r8a7779_init_irq,
 	.init_machine	= marzen_init,
-	.init_late	= marzen_init_late,
+	.init_late	= r8a7779_init_late,
 	.init_time	= r8a7779_earlytimer_init,
 MACHINE_END
Index: renesas/arch/arm/mach-shmobile/include/mach/r8a7779.h
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/include/mach/r8a7779.h
+++ renesas/arch/arm/mach-shmobile/include/mach/r8a7779.h
@@ -33,6 +33,7 @@ extern void r8a7779_add_early_devices(vo
 extern void r8a7779_add_standard_devices(void);
 extern void r8a7779_add_standard_devices_dt(void);
 extern void r8a7779_add_ether_device(struct sh_eth_plat_data *pdata);
+extern void r8a7779_init_late(void);
 extern void r8a7779_clock_init(void);
 extern void r8a7779_pinmux_init(void);
 extern void r8a7779_pm_init(void);
Index: renesas/arch/arm/mach-shmobile/setup-r8a7779.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/setup-r8a7779.c
+++ renesas/arch/arm/mach-shmobile/setup-r8a7779.c
@@ -32,6 +32,10 @@
 #include <linux/sh_intc.h>
 #include <linux/sh_timer.h>
 #include <linux/dma-mapping.h>
+#include <linux/usb/otg.h>
+#include <linux/usb/ehci_pdriver.h>
+#include <linux/usb/ohci_pdriver.h>
+#include <linux/pm_runtime.h>
 #include <mach/hardware.h>
 #include <mach/irqs.h>
 #include <mach/r8a7779.h>
@@ -394,6 +398,162 @@ static struct platform_device sata_devic
 	},
 };
 
+/* USB PHY */
+static struct resource usb_phy_resources[] = {
+	[0] = {
+		.start		= 0xffe70000,
+		.end		= 0xffe70900 - 1,
+		.flags		= IORESOURCE_MEM,
+	},
+	[1] = {
+		.start		= 0xfff70000,
+		.end		= 0xfff70900 - 1,
+		.flags		= IORESOURCE_MEM,
+	},
+};
+
+static struct platform_device usb_phy_device = {
+	.name		= "rcar_usb_phy",
+	.id		= -1,
+	.resource	= usb_phy_resources,
+	.num_resources	= ARRAY_SIZE(usb_phy_resources),
+};
+
+/* USB */
+static struct usb_phy *phy;
+
+static int usb_power_on(struct platform_device *pdev)
+{
+	if (!phy)
+		return -EIO;
+
+	pm_runtime_enable(&pdev->dev);
+	pm_runtime_get_sync(&pdev->dev);
+
+	usb_phy_init(phy);
+
+	return 0;
+}
+
+static void usb_power_off(struct platform_device *pdev)
+{
+	if (!phy)
+		return;
+
+	usb_phy_shutdown(phy);
+
+	pm_runtime_put_sync(&pdev->dev);
+	pm_runtime_disable(&pdev->dev);
+}
+
+static struct usb_ehci_pdata ehcix_pdata = {
+	.power_on	= usb_power_on,
+	.power_off	= usb_power_off,
+	.power_suspend	= usb_power_off,
+};
+
+static struct resource ehci0_resources[] = {
+	[0] = {
+		.start	= 0xffe70000,
+		.end	= 0xffe70400 - 1,
+		.flags	= IORESOURCE_MEM,
+	},
+	[1] = {
+		.start	= gic_iid(0x4c),
+		.flags	= IORESOURCE_IRQ,
+	},
+};
+
+static struct platform_device ehci0_device = {
+	.name	= "ehci-platform",
+	.id	= 0,
+	.dev	= {
+		.dma_mask		= &ehci0_device.dev.coherent_dma_mask,
+		.coherent_dma_mask	= 0xffffffff,
+		.platform_data		= &ehcix_pdata,
+	},
+	.num_resources	= ARRAY_SIZE(ehci0_resources),
+	.resource	= ehci0_resources,
+};
+
+static struct resource ehci1_resources[] = {
+	[0] = {
+		.start	= 0xfff70000,
+		.end	= 0xfff70400 - 1,
+		.flags	= IORESOURCE_MEM,
+	},
+	[1] = {
+		.start	= gic_iid(0x4d),
+		.flags	= IORESOURCE_IRQ,
+	},
+};
+
+static struct platform_device ehci1_device = {
+	.name	= "ehci-platform",
+	.id	= 1,
+	.dev	= {
+		.dma_mask		= &ehci1_device.dev.coherent_dma_mask,
+		.coherent_dma_mask	= 0xffffffff,
+		.platform_data		= &ehcix_pdata,
+	},
+	.num_resources	= ARRAY_SIZE(ehci1_resources),
+	.resource	= ehci1_resources,
+};
+
+static struct usb_ohci_pdata ohcix_pdata = {
+	.power_on	= usb_power_on,
+	.power_off	= usb_power_off,
+	.power_suspend	= usb_power_off,
+};
+
+static struct resource ohci0_resources[] = {
+	[0] = {
+		.start	= 0xffe70400,
+		.end	= 0xffe70800 - 1,
+		.flags	= IORESOURCE_MEM,
+	},
+	[1] = {
+		.start	= gic_iid(0x4c),
+		.flags	= IORESOURCE_IRQ,
+	},
+};
+
+static struct platform_device ohci0_device = {
+	.name	= "ohci-platform",
+	.id	= 0,
+	.dev	= {
+		.dma_mask		= &ohci0_device.dev.coherent_dma_mask,
+		.coherent_dma_mask	= 0xffffffff,
+		.platform_data		= &ohcix_pdata,
+	},
+	.num_resources	= ARRAY_SIZE(ohci0_resources),
+	.resource	= ohci0_resources,
+};
+
+static struct resource ohci1_resources[] = {
+	[0] = {
+		.start	= 0xfff70400,
+		.end	= 0xfff70800 - 1,
+		.flags	= IORESOURCE_MEM,
+	},
+	[1] = {
+		.start	= gic_iid(0x4d),
+		.flags	= IORESOURCE_IRQ,
+	},
+};
+
+static struct platform_device ohci1_device = {
+	.name	= "ohci-platform",
+	.id	= 1,
+	.dev	= {
+		.dma_mask		= &ohci1_device.dev.coherent_dma_mask,
+		.coherent_dma_mask	= 0xffffffff,
+		.platform_data		= &ohcix_pdata,
+	},
+	.num_resources	= ARRAY_SIZE(ohci1_resources),
+	.resource	= ohci1_resources,
+};
+
 /* Ether */
 static struct resource ether_resources[] = {
 	{
@@ -415,9 +575,10 @@ static struct platform_device *r8a7779_d
 	&scif5_device,
 	&tmu00_device,
 	&tmu01_device,
+	&usb_phy_device,
 };
 
-static struct platform_device *r8a7779_late_devices[] __initdata = {
+static struct platform_device *r8a7779_standard_devices[] __initdata = {
 	&i2c0_device,
 	&i2c1_device,
 	&i2c2_device,
@@ -437,8 +598,8 @@ void __init r8a7779_add_standard_devices
 
 	platform_add_devices(r8a7779_devices_dt,
 			    ARRAY_SIZE(r8a7779_devices_dt));
-	platform_add_devices(r8a7779_late_devices,
-			    ARRAY_SIZE(r8a7779_late_devices));
+	platform_add_devices(r8a7779_standard_devices,
+			    ARRAY_SIZE(r8a7779_standard_devices));
 }
 
 void __init r8a7779_add_ether_device(struct sh_eth_plat_data *pdata)
@@ -481,6 +642,23 @@ void __init r8a7779_add_early_devices(vo
 	 */
 }
 
+static struct platform_device *r8a7779_late_devices[] __initdata = {
+	&ehci0_device,
+	&ehci1_device,
+	&ohci0_device,
+	&ohci1_device,
+};
+
+void __init r8a7779_init_late(void)
+{
+	/* get USB PHY */
+	phy = usb_get_phy(USB_PHY_TYPE_USB2);
+
+	shmobile_init_late();
+	platform_add_devices(r8a7779_late_devices,
+			     ARRAY_SIZE(r8a7779_late_devices));
+}
+
 #ifdef CONFIG_USE_OF
 void __init r8a7779_init_delay(void)
 {
@@ -514,6 +692,7 @@ DT_MACHINE_START(R8A7779_DT, "Generic R8
 	.init_irq	= r8a7779_init_irq_dt,
 	.init_machine	= r8a7779_add_standard_devices_dt,
 	.init_time	= shmobile_timer_init,
+	.init_late	= r8a7779_init_late,
 	.dt_compat	= r8a7779_compat_dt,
 MACHINE_END
 #endif /* CONFIG_USE_OF */


From sergei.shtylyov at cogentembedded.com  Thu Apr  4 19:01:59 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Fri, 5 Apr 2013 03:01:59 +0400
Subject: [PATCH 3/8] ARM: shmobile: R8A7779: setup EHCI internal buffer
Message-ID: <201304050301.59961.sergei.shtylyov@cogentembedded.com>

Setup the EHCI internal buffer (before EHCI driver has a chance to touch the
registers) using the init() method in 'struct usb_ehci_pdata'.

Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

---
 arch/arm/mach-shmobile/setup-r8a7779.c |   16 ++++++++++++++++
 1 file changed, 16 insertions(+)

Index: renesas/arch/arm/mach-shmobile/setup-r8a7779.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/setup-r8a7779.c
+++ renesas/arch/arm/mach-shmobile/setup-r8a7779.c
@@ -445,10 +445,26 @@ static void usb_power_off(struct platfor
 	pm_runtime_disable(&pdev->dev);
 }
 
+static int ehci_init_internal_buffer(struct platform_device *pdev,
+				     void __iomem *regs)
+{
+	/*
+	 * Below are recommended values from the datasheet;
+	 * see [USB :: Setting of EHCI Internal Buffer].
+	 */
+	/* EHCI IP internal buffer setting */
+	iowrite32(0x00ff0040, regs + 0x0094);
+	/* EHCI IP internal buffer enable */
+	iowrite32(0x00000001, regs + 0x009C);
+
+	return 0;
+}
+
 static struct usb_ehci_pdata ehcix_pdata = {
 	.power_on	= usb_power_on,
 	.power_off	= usb_power_off,
 	.power_suspend	= usb_power_off,
+	.init		= ehci_init_internal_buffer,
 };
 
 static struct resource ehci0_resources[] = {


From sergei.shtylyov at cogentembedded.com  Thu Apr  4 19:03:55 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Fri, 5 Apr 2013 03:03:55 +0400
Subject: [PATCH 4/8] rcar-phy: remove EHCI internal buffer setup
Message-ID: <201304050303.56515.sergei.shtylyov@cogentembedded.com>

Now that the EHCI internal buffer setup is done by the platform code, we  can
remove  such code from this driver as it never really belonged here.  We also
no longer need the 2nd memory region now (2nd EHCI controller is simply missing
in e.g. R8A7778 SoC).

Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

---
 arch/arm/mach-shmobile/setup-r8a7779.c |    5 -----
 drivers/usb/phy/rcar-phy.c             |   28 ++++------------------------
 2 files changed, 4 insertions(+), 29 deletions(-)

Index: renesas/arch/arm/mach-shmobile/setup-r8a7779.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/setup-r8a7779.c
+++ renesas/arch/arm/mach-shmobile/setup-r8a7779.c
@@ -405,11 +405,6 @@ static struct resource usb_phy_resources
 		.end		= 0xffe70900 - 1,
 		.flags		= IORESOURCE_MEM,
 	},
-	[1] = {
-		.start		= 0xfff70000,
-		.end		= 0xfff70900 - 1,
-		.flags		= IORESOURCE_MEM,
-	},
 };
 
 static struct platform_device usb_phy_device = {
Index: renesas/drivers/usb/phy/rcar-phy.c
===================================================================
--- renesas.orig/drivers/usb/phy/rcar-phy.c
+++ renesas/drivers/usb/phy/rcar-phy.c
@@ -23,8 +23,6 @@
 #define USBEH0		0x080C
 #define USBOH0		0x081C
 #define USBCTL0		0x0858
-#define EIIBC1		0x0094
-#define EIIBC2		0x009C
 
 /* USBPCTRL1 */
 #define PHY_RST		(1 << 2)
@@ -40,7 +38,6 @@ struct rcar_usb_phy_priv {
 	spinlock_t lock;
 
 	void __iomem *reg0;
-	void __iomem *reg1;
 	int counter;
 };
 
@@ -59,7 +56,6 @@ static int rcar_usb_phy_init(struct usb_
 	struct rcar_usb_phy_priv *priv = usb_phy_to_priv(phy);
 	struct device *dev = phy->dev;
 	void __iomem *reg0 = priv->reg0;
-	void __iomem *reg1 = priv->reg1;
 	int i;
 	u32 val;
 	unsigned long flags;
@@ -97,19 +93,6 @@ static int rcar_usb_phy_init(struct usb_
 		iowrite32(0x00000000, (reg0 + USBPCTRL0));
 
 		/*
-		 * EHCI IP internal buffer setting
-		 * EHCI IP internal buffer enable
-		 *
-		 * These are recommended value of a datasheet
-		 * see [USB :: EHCI internal buffer setting]
-		 */
-		iowrite32(0x00ff0040, (reg0 + EIIBC1));
-		iowrite32(0x00ff0040, (reg1 + EIIBC1));
-
-		iowrite32(0x00000001, (reg0 + EIIBC2));
-		iowrite32(0x00000001, (reg1 + EIIBC2));
-
-		/*
 		 * Bus alignment settings
 		 */
 
@@ -145,14 +128,13 @@ static void rcar_usb_phy_shutdown(struct
 static int rcar_usb_phy_probe(struct platform_device *pdev)
 {
 	struct rcar_usb_phy_priv *priv;
-	struct resource *res0, *res1;
+	struct resource *res0;
 	struct device *dev = &pdev->dev;
-	void __iomem *reg0, *reg1;
+	void __iomem *reg0;
 	int ret;
 
 	res0 = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-	res1 = platform_get_resource(pdev, IORESOURCE_MEM, 1);
-	if (!res0 || !res1) {
+	if (!res0) {
 		dev_err(dev, "Not enough platform resources\n");
 		return -EINVAL;
 	}
@@ -164,8 +146,7 @@ static int rcar_usb_phy_probe(struct pla
 	 * this driver can't use devm_request_and_ioremap(dev, res) here
 	 */
 	reg0 = devm_ioremap_nocache(dev, res0->start, resource_size(res0));
-	reg1 = devm_ioremap_nocache(dev, res1->start, resource_size(res1));
-	if (!reg0 || !reg1) {
+	if (!reg0) {
 		dev_err(dev, "ioremap error\n");
 		return -ENOMEM;
 	}
@@ -177,7 +158,6 @@ static int rcar_usb_phy_probe(struct pla
 	}
 
 	priv->reg0		= reg0;
-	priv->reg1		= reg1;
 	priv->counter		= 0;
 	priv->phy.dev		= dev;
 	priv->phy.label		= dev_name(dev);


From sergei.shtylyov at cogentembedded.com  Thu Apr  4 19:05:14 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Fri, 5 Apr 2013 03:05:14 +0400
Subject: [PATCH 5/8] rcar-phy: correct base address
Message-ID: <201304050305.15517.sergei.shtylyov@cogentembedded.com>

The memory region that is used by the driver overlaps EHCI and OHCI register
regions for absolutely no reason now  -- fix it by adding offset of 0x800 to
the base address, changing the register #define's accordingly. This has extra
positive effect that we now can use devm_ioremap_resource().

Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

---
 arch/arm/mach-shmobile/setup-r8a7779.c |    2 +-
 drivers/usb/phy/rcar-phy.c             |   28 ++++++++++------------------
 2 files changed, 11 insertions(+), 19 deletions(-)

Index: renesas/arch/arm/mach-shmobile/setup-r8a7779.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/setup-r8a7779.c
+++ renesas/arch/arm/mach-shmobile/setup-r8a7779.c
@@ -401,7 +401,7 @@ static struct platform_device sata_devic
 /* USB PHY */
 static struct resource usb_phy_resources[] = {
 	[0] = {
-		.start		= 0xffe70000,
+		.start		= 0xffe70800,
 		.end		= 0xffe70900 - 1,
 		.flags		= IORESOURCE_MEM,
 	},
Index: renesas/drivers/usb/phy/rcar-phy.c
===================================================================
--- renesas.orig/drivers/usb/phy/rcar-phy.c
+++ renesas/drivers/usb/phy/rcar-phy.c
@@ -16,13 +16,13 @@
 #include <linux/spinlock.h>
 #include <linux/module.h>
 
-/* USBH common register */
-#define USBPCTRL0	0x0800
-#define USBPCTRL1	0x0804
-#define USBST		0x0808
-#define USBEH0		0x080C
-#define USBOH0		0x081C
-#define USBCTL0		0x0858
+/* REGS block */
+#define USBPCTRL0	0x00
+#define USBPCTRL1	0x04
+#define USBST		0x08
+#define USBEH0		0x0C
+#define USBOH0		0x1C
+#define USBCTL0		0x58
 
 /* USBPCTRL1 */
 #define PHY_RST		(1 << 2)
@@ -139,17 +139,9 @@ static int rcar_usb_phy_probe(struct pla
 		return -EINVAL;
 	}
 
-	/*
-	 * CAUTION
-	 *
-	 * Because this phy address is also mapped under OHCI/EHCI address area,
-	 * this driver can't use devm_request_and_ioremap(dev, res) here
-	 */
-	reg0 = devm_ioremap_nocache(dev, res0->start, resource_size(res0));
-	if (!reg0) {
-		dev_err(dev, "ioremap error\n");
-		return -ENOMEM;
-	}
+	reg0 = devm_ioremap_resource(dev, res0);
+	if (IS_ERR(reg0))
+		return PTR_ERR(reg0);
 
 	priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
 	if (!priv) {


From festevam at gmail.com  Thu Apr  4 19:08:29 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Thu, 4 Apr 2013 20:08:29 -0300
Subject: [RFC PATCH] CLK: Allow parent clock and rate to be configured in
 DT.
In-Reply-To: <20130325101707.GZ1906@pengutronix.de>
References: <20130319170933.28337.50448.stgit@localhost>
 <20130325101707.GZ1906@pengutronix.de>
Message-ID: <CAOMZO5ASkvquyzPCEGObvB5Xh9bDPTJ2zx26eOUJT_Vb36Bn3Q@mail.gmail.com>

Hi Sascha,

On Mon, Mar 25, 2013 at 7:17 AM, Sascha Hauer <s.hauer at pengutronix.de> wrote:

>> +For example:
>> +     clock-configuration {
>> +             compatible = "clock-configuration";
>> +             clko1 {
>> +                     clocks = <&clks 160>; /* cko1_sel */
>> +                     parent = <&clks 114>; /* pll3_sw */
>> +             };
>> +
>> +             esdhca {
>> +                     clocks = <&clks 102>; /* esdhc_a_podf */
>> +                     clock-frequency = <200000000>;
>> +             };
>
> This example shows this. For some reason we adjust the esdhc frequency
> to 200MHz in the code currently, but this is because it matches our
> current usecase. Once you move this into devicetree, we can't change
> this anymore in the kernel, even if we find a much better way to adjust
> the frequency in the future (i.e. smaller values might be good for power
> savings, higher values might increase performance, we even might
> dynamically change this frequency).

What if we use Martin's idea, but without the "clock-frequency" option
and only pass the parent information? This way the driver can find the
better clock as you described. Something like:

     clock-parent {
             compatible = "clock-parent";
             clko1 {
                     clocks = <&clks 160>; /* cko1_sel */
                    parent = <&clks 114>; /* pll3_sw */
             };

This could be useful for removing the imx6q_sabrelite_cko1_setup()
function from arch/arm/mach-imx/mach-imx6q.c.

I would like to add audio support for another board and would like to
avoid to do the same as imx6q_sabrelite_cko1_setup()  for setting up
the CLKO, if possible.

Regards,

Fabio Estevam


From sergei.shtylyov at cogentembedded.com  Thu Apr  4 19:10:38 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Fri, 5 Apr 2013 03:10:38 +0400
Subject: [PATCH 7/8] ARM: shmobile: Marzen: pass platform data to USB PHY
 device
Message-ID: <201304050310.39289.sergei.shtylyov@cogentembedded.com>

Since we're now going to setup the USBPCTRL0 register using the USB PHY device's
platform data, we now need a way to pass those platform data from the board file
to the device which is situated in setup-r8a7779.c -- and what I'm suggesting is
r8a7779_add_usb_phy_device() that will register USB PHY platform device with the
passed platform data using platform_device_register_resndata() call; creating
this function involves deletion of 'usb_phy_device' from r8a7779_devices_dt[],
so that it will no longer be registered for the generic R8A7779 machine (where
we can't provide the platform data anyway), hence EHCI/OHCI drivers will fail
to load as well.

For the Marzen board, this new function will be called from marzen_init() to
register the USB PHY device early enough.

Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

---
 arch/arm/mach-shmobile/board-marzen.c         |    5 +++++
 arch/arm/mach-shmobile/include/mach/r8a7779.h |    2 ++
 arch/arm/mach-shmobile/setup-r8a7779.c        |   16 ++++++++--------
 3 files changed, 15 insertions(+), 8 deletions(-)

Index: renesas/arch/arm/mach-shmobile/board-marzen.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/board-marzen.c
+++ renesas/arch/arm/mach-shmobile/board-marzen.c
@@ -56,6 +56,10 @@ static struct regulator_consumer_supply 
 	REGULATOR_SUPPLY("vdd33a", "smsc911x"),
 };
 
+static struct rcar_phy_platform_data usb_phy_platform_data = {
+	.usbpctrl0	= 0,
+};
+
 /* SMSC LAN89218 */
 static struct resource smsc911x_resources[] = {
 	[0] = {
@@ -230,6 +234,7 @@ static void __init marzen_init(void)
 	r8a7779_pinmux_init();
 
 	r8a7779_add_standard_devices();
+	r8a7779_add_usb_phy_device(&usb_phy_platform_data);
 	platform_add_devices(marzen_devices, ARRAY_SIZE(marzen_devices));
 }
 
Index: renesas/arch/arm/mach-shmobile/include/mach/r8a7779.h
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/include/mach/r8a7779.h
+++ renesas/arch/arm/mach-shmobile/include/mach/r8a7779.h
@@ -4,6 +4,7 @@
 #include <linux/sh_clk.h>
 #include <linux/pm_domain.h>
 #include <linux/sh_eth.h>
+#include <linux/usb/rcar-phy.h>
 
 struct platform_device;
 
@@ -33,6 +34,7 @@ extern void r8a7779_add_early_devices(vo
 extern void r8a7779_add_standard_devices(void);
 extern void r8a7779_add_standard_devices_dt(void);
 extern void r8a7779_add_ether_device(struct sh_eth_plat_data *pdata);
+extern void r8a7779_add_usb_phy_device(struct rcar_phy_platform_data *pdata);
 extern void r8a7779_init_late(void);
 extern void r8a7779_clock_init(void);
 extern void r8a7779_pinmux_init(void);
Index: renesas/arch/arm/mach-shmobile/setup-r8a7779.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/setup-r8a7779.c
+++ renesas/arch/arm/mach-shmobile/setup-r8a7779.c
@@ -407,13 +407,6 @@ static struct resource usb_phy_resources
 	},
 };
 
-static struct platform_device usb_phy_device = {
-	.name		= "rcar_usb_phy",
-	.id		= -1,
-	.resource	= usb_phy_resources,
-	.num_resources	= ARRAY_SIZE(usb_phy_resources),
-};
-
 /* USB */
 static struct usb_phy *phy;
 
@@ -586,7 +579,6 @@ static struct platform_device *r8a7779_d
 	&scif5_device,
 	&tmu00_device,
 	&tmu01_device,
-	&usb_phy_device,
 };
 
 static struct platform_device *r8a7779_standard_devices[] __initdata = {
@@ -621,6 +613,14 @@ void __init r8a7779_add_ether_device(str
 					  pdata, sizeof(*pdata));
 }
 
+void __init r8a7779_add_usb_phy_device(struct rcar_phy_platform_data *pdata)
+{
+	platform_device_register_resndata(&platform_bus, "rcar_usb_phy", -1,
+					  usb_phy_resources,
+					  ARRAY_SIZE(usb_phy_resources),
+					  pdata, sizeof(*pdata));
+}
+
 /* do nothing for !CONFIG_SMP or !CONFIG_HAVE_TWD */
 void __init __weak r8a7779_register_twd(void) { }
 


From heiko at sntech.de  Thu Apr  4 19:15:02 2013
From: heiko at sntech.de (Heiko =?iso-8859-15?q?St=FCbner?=)
Date: Fri, 5 Apr 2013 01:15:02 +0200
Subject: [PATCH v4 00/14] ARM: samsung-time: Prepare for multiplatform
 support
In-Reply-To: <1365093431-30621-1-git-send-email-t.figa@samsung.com>
References: <1365093431-30621-1-git-send-email-t.figa@samsung.com>
Message-ID: <201304050115.03879.heiko@sntech.de>

Am Donnerstag, 4. April 2013, 18:36:57 schrieb Tomasz Figa:
> This series is an attempt to make the samsung-time clocksource driver ready
> for multiplatform kernels. It moves the driver to drivers/clocksource,
> cleans it up from uses of static platform-specific definitions, simplifies
> timer interrupt handling and adds Device Tree support.
> 
> Only samsung-time driver is reworked to use the master driver at this time,
> since the PWM driver can be already considered broken at the moment and
> needs separate series of several patches to fix and clean it up, which
> I am already working on.
> 
> Tested on Universal C210 board with Device Tree. Not tested without
> Device Tree, since it has been already broken before this series.
> Compile tested for other related SoCs.

Looks nice.

On a non-DT S3C2416 board:
Tested-by: Heiko Stuebner <heiko at sntech.de>


And just so I don't search myself silly, am I right in thinking that the 
driver does not use the generic clocksource registration yet and dt machines 
must still use samsung_timer_init at this point?


Heiko


From robherring2 at gmail.com  Thu Apr  4 19:17:14 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Thu, 04 Apr 2013 18:17:14 -0500
Subject: [PATCH V2 1/7] kbuild: create an "include chroot" for DT bindings
In-Reply-To: <1365032098-22825-1-git-send-email-swarren@wwwdotorg.org>
References: <1365032098-22825-1-git-send-email-swarren@wwwdotorg.org>
Message-ID: <515E09FA.1090408@gmail.com>

On 04/03/2013 06:34 PM, Stephen Warren wrote:
> From: Stephen Warren <swarren at nvidia.com>
> 
> The recent dtc+cpp support allows header files and C pre-processor
> defines/macros to be used when compiling device tree files. These
> headers will typically define various constants that are part of the
> device tree bindings.
> 
> The original patch which set up the dtc+cpp include path only considered
> using those headers from device tree files. However, most are also
> useful for kernel code which needs to interpret the device tree.
> 
> In both the DT files and the kernel, I'd like to include the DT-related
> headers in the same way, for example, <dt-bindings/gpio/tegra-gpio.h>.
> That will simplify any text which discusses the DT header locations.
> 
> Creating a <dt-bindings/> for kernel source to use is as simple as
> placing files into include/dt-bindings/.
> 
> However, when compiling DT files, the include path should be restricted
> so that only the dt-bindings path is available; arbitrary kernel headers
> shouldn't be exposed. For this reason, create a specific include
> directory for use by dtc+cpp, and symlink dt-bindings from there to the
> actual location of include/dt-bindings/. For want of a better location,
> place this "include chroot" into the existing dts/ directory.
> 
> arch/*/boot/dts/include/dt-bindings -> ../../../../../include/dt-bindings
> 
> Some headers used by device tree files may not be useful to the kernel;
> they may be used simply to aid in constructing the DT file (e.g. macros
> to create a node), but not define any information that the kernel needs
> to share. These may be placed directly into arch/*/boot/dts/ along with
> the DT files themselves.
> 
> Cc: Shawn Guo <shawn.guo at linaro.org>
> Cc: Hiroshi Doyu <hdoyu at nvidia.com>
> Acked-by: Michal Marek <mmarek at suse.cz>
> Acked-by: Shawn Guo <shawn.guo at linaro.org>
> Acked-by: Rob Herring <rob.herring at calxeda.com>
> Signed-off-by: Stephen Warren <swarren at nvidia.com>
> ---
> Grant, Rob, Michal, I'm hoping for acks or comments from you so this
> series can be placed into a topic branch in the arm-soc repo, for others
> to build on during the 3.10 kernel cycle. Thanks.

Well, you have mine here and the rest looks fine, so add it to the others.

Rob

> 
> This first patch was previously posted separately as V2. I'm including
> it here to keep it with the whole series. I hope this series can be
> applied as a topic branch in arm-soc.
> ---
>  arch/arm/boot/dts/include/dt-bindings |    1 +
>  scripts/Makefile.lib                  |    2 +-
>  2 files changed, 2 insertions(+), 1 deletion(-)
>  create mode 120000 arch/arm/boot/dts/include/dt-bindings
> 
> diff --git a/arch/arm/boot/dts/include/dt-bindings b/arch/arm/boot/dts/include/dt-bindings
> new file mode 120000
> index 0000000..08c00e4
> --- /dev/null
> +++ b/arch/arm/boot/dts/include/dt-bindings
> @@ -0,0 +1 @@
> +../../../../../include/dt-bindings
> \ No newline at end of file
> diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
> index 07125e6..af35521 100644
> --- a/scripts/Makefile.lib
> +++ b/scripts/Makefile.lib
> @@ -158,7 +158,7 @@ ld_flags       = $(LDFLAGS) $(ldflags-y)
>  
>  dtc_cpp_flags  = -Wp,-MD,$(depfile) -nostdinc                            \
>  		 -I$(srctree)/arch/$(SRCARCH)/boot/dts                   \
> -		 -I$(srctree)/arch/$(SRCARCH)/include/dts                \
> +		 -I$(srctree)/arch/$(SRCARCH)/boot/dts/include           \
>  		 -undef -D__DTS__
>  
>  # Finds the multi-part object the current object will be linked into
> 



From swarren at wwwdotorg.org  Thu Apr  4 19:26:58 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Thu,  4 Apr 2013 17:26:58 -0600
Subject: [PATCH] clk: tegra: Fix cdev1 and cdev2 IDs
Message-ID: <1365118019-5748-1-git-send-email-swarren@wwwdotorg.org>

From: Prashant Gaikwad <pgaikwad at nvidia.com>

Correct IDs for cdev1 and cdev2 are 94 and 93 respectively.

Signed-off-by: Prashant Gaikwad <pgaikwad at nvidia.com>
[swarren: split into separate driver and device-tree patches]
Signed-off-by: Stephen Warren <swarren at nvidia.com>
---
I split this patch in two when applying it. Reposting just so everyone
can see exactly what I applied. This is the patch from Tegra's
for-3.10/clk branch.

 Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt |    4 ++--
 drivers/clk/tegra/clk-tegra20.c                                |    2 +-
 drivers/clk/tegra/clk-tegra30.c                                |    2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt b/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt
index 0921fac..e885680 100644
--- a/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt
+++ b/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt
@@ -120,8 +120,8 @@ Required properties :
   90	clk_d
   91	unassigned
   92	sus
-  93	cdev1
-  94	cdev2
+  93	cdev2
+  94	cdev1
   95	unassigned
 
   96	uart2
diff --git a/drivers/clk/tegra/clk-tegra20.c b/drivers/clk/tegra/clk-tegra20.c
index f87bd4a..a7dc0a9 100644
--- a/drivers/clk/tegra/clk-tegra20.c
+++ b/drivers/clk/tegra/clk-tegra20.c
@@ -236,7 +236,7 @@ enum tegra20_clk {
 	dvc, dsi, mipi = 50, hdmi, csi, tvdac, i2c2, uartc, emc = 57, usb2,
 	usb3, mpe, vde, bsea, bsev, speedo, uartd, uarte, i2c3, sbc4, sdmmc3,
 	pex, owr, afi, csite, pcie_xclk, avpucq = 75, la, irama = 84, iramb,
-	iramc, iramd, cram2, audio_2x, clk_d, csus = 92, cdev1, cdev2,
+	iramc, iramd, cram2, audio_2x, clk_d, csus = 92, cdev2, cdev1,
 	uartb = 96, vfir, spdif_in, spdif_out, vi, vi_sensor, tvo, cve,
 	osc, clk_32k, clk_m, sclk, cclk, hclk, pclk, blink, pll_a, pll_a_out0,
 	pll_c, pll_c_out1, pll_d, pll_d_out0, pll_e, pll_m, pll_m_out1,
diff --git a/drivers/clk/tegra/clk-tegra30.c b/drivers/clk/tegra/clk-tegra30.c
index b8b241d..181a6ee 100644
--- a/drivers/clk/tegra/clk-tegra30.c
+++ b/drivers/clk/tegra/clk-tegra30.c
@@ -330,7 +330,7 @@ enum tegra30_clk {
 	usb3, mpe, vde, bsea, bsev, speedo, uartd, uarte, i2c3, sbc4, sdmmc3,
 	pcie, owr, afi, csite, pciex, avpucq, la, dtv = 79, ndspeed, i2cslow,
 	dsib, irama = 84, iramb, iramc, iramd, cram2, audio_2x = 90, csus = 92,
-	cdev1, cdev2, cpu_g = 96, cpu_lp, gr3d2, mselect, tsensor, i2s3, i2s4,
+	cdev2, cdev1, cpu_g = 96, cpu_lp, gr3d2, mselect, tsensor, i2s3, i2s4,
 	i2c4, sbc5, sbc6, d_audio, apbif, dam0, dam1, dam2, hda2codec_2x,
 	atomics, audio0_2x, audio1_2x, audio2_2x, audio3_2x, audio4_2x,
 	spdif_2x, actmon, extern1, extern2, extern3, sata_oob, sata, hda,
-- 
1.7.10.4



From swarren at wwwdotorg.org  Thu Apr  4 19:26:59 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Thu,  4 Apr 2013 17:26:59 -0600
Subject: [PATCH] clk: tegra: Fix cdev1 and cdev2 IDs
In-Reply-To: <1365118019-5748-1-git-send-email-swarren@wwwdotorg.org>
References: <1365118019-5748-1-git-send-email-swarren@wwwdotorg.org>
Message-ID: <1365118019-5748-2-git-send-email-swarren@wwwdotorg.org>

From: Prashant Gaikwad <pgaikwad at nvidia.com>

Correct IDs for cdev1 and cdev2 are 94 and 93 respectively.

Signed-off-by: Prashant Gaikwad <pgaikwad at nvidia.com>
[swarren: split into separate driver and device-tree patches]
Signed-off-by: Stephen Warren <swarren at nvidia.com>
---
I split this patch in two when applying it. Reposting just so everyone
can see exactly what I applied. This is the patch from Tegra's
for-3.10/dt branch.

 arch/arm/boot/dts/tegra20-colibri-512.dtsi |    2 +-
 arch/arm/boot/dts/tegra20-harmony.dts      |    2 +-
 arch/arm/boot/dts/tegra20-medcom-wide.dts  |    2 +-
 arch/arm/boot/dts/tegra20-paz00.dts        |    2 +-
 arch/arm/boot/dts/tegra20-plutux.dts       |    2 +-
 arch/arm/boot/dts/tegra20-seaboard.dts     |    2 +-
 arch/arm/boot/dts/tegra20-tec.dts          |    2 +-
 arch/arm/boot/dts/tegra20-trimslice.dts    |    2 +-
 arch/arm/boot/dts/tegra20-ventana.dts      |    2 +-
 arch/arm/boot/dts/tegra20-whistler.dts     |    2 +-
 arch/arm/boot/dts/tegra20.dtsi             |    2 +-
 11 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/arch/arm/boot/dts/tegra20-colibri-512.dtsi b/arch/arm/boot/dts/tegra20-colibri-512.dtsi
index a094787..a573b94 100644
--- a/arch/arm/boot/dts/tegra20-colibri-512.dtsi
+++ b/arch/arm/boot/dts/tegra20-colibri-512.dtsi
@@ -483,7 +483,7 @@
 
 		nvidia,ac97-controller = <&ac97>;
 
-		clocks = <&tegra_car 112>, <&tegra_car 113>, <&tegra_car 93>;
+		clocks = <&tegra_car 112>, <&tegra_car 113>, <&tegra_car 94>;
 		clock-names = "pll_a", "pll_a_out0", "mclk";
 	};
 
diff --git a/arch/arm/boot/dts/tegra20-harmony.dts b/arch/arm/boot/dts/tegra20-harmony.dts
index a44b54e..e7d5de4 100644
--- a/arch/arm/boot/dts/tegra20-harmony.dts
+++ b/arch/arm/boot/dts/tegra20-harmony.dts
@@ -687,7 +687,7 @@
 		nvidia,int-mic-en-gpios = <&gpio 184 0>; /*gpio PX0 */
 		nvidia,ext-mic-en-gpios = <&gpio 185 0>; /* gpio PX1 */
 
-		clocks = <&tegra_car 112>, <&tegra_car 113>, <&tegra_car 93>;
+		clocks = <&tegra_car 112>, <&tegra_car 113>, <&tegra_car 94>;
 		clock-names = "pll_a", "pll_a_out0", "mclk";
 	};
 };
diff --git a/arch/arm/boot/dts/tegra20-medcom-wide.dts b/arch/arm/boot/dts/tegra20-medcom-wide.dts
index 740ba7c..ace2343 100644
--- a/arch/arm/boot/dts/tegra20-medcom-wide.dts
+++ b/arch/arm/boot/dts/tegra20-medcom-wide.dts
@@ -59,7 +59,7 @@
 		nvidia,spkr-en-gpios = <&wm8903 2 0>;
 		nvidia,hp-det-gpios = <&gpio 178 0>; /* gpio PW2 */
 
-		clocks = <&tegra_car 112>, <&tegra_car 113>, <&tegra_car 93>;
+		clocks = <&tegra_car 112>, <&tegra_car 113>, <&tegra_car 94>;
 		clock-names = "pll_a", "pll_a_out0", "mclk";
 	};
 };
diff --git a/arch/arm/boot/dts/tegra20-paz00.dts b/arch/arm/boot/dts/tegra20-paz00.dts
index 8c0e9a2..e3e0c99 100644
--- a/arch/arm/boot/dts/tegra20-paz00.dts
+++ b/arch/arm/boot/dts/tegra20-paz00.dts
@@ -522,7 +522,7 @@
 		nvidia,i2s-controller = <&tegra_i2s1>;
 		nvidia,hp-det-gpios = <&gpio 178 0>; /* gpio PW2 */
 
-		clocks = <&tegra_car 112>, <&tegra_car 113>, <&tegra_car 93>;
+		clocks = <&tegra_car 112>, <&tegra_car 113>, <&tegra_car 94>;
 		clock-names = "pll_a", "pll_a_out0", "mclk";
 	};
 };
diff --git a/arch/arm/boot/dts/tegra20-plutux.dts b/arch/arm/boot/dts/tegra20-plutux.dts
index 7085ae5..1a17cc3 100644
--- a/arch/arm/boot/dts/tegra20-plutux.dts
+++ b/arch/arm/boot/dts/tegra20-plutux.dts
@@ -53,7 +53,7 @@
 		nvidia,spkr-en-gpios = <&wm8903 2 0>;
 		nvidia,hp-det-gpios = <&gpio 178 0>; /* gpio PW2 */
 
-		clocks = <&tegra_car 112>, <&tegra_car 113>, <&tegra_car 93>;
+		clocks = <&tegra_car 112>, <&tegra_car 113>, <&tegra_car 94>;
 		clock-names = "pll_a", "pll_a_out0", "mclk";
 	};
 };
diff --git a/arch/arm/boot/dts/tegra20-seaboard.dts b/arch/arm/boot/dts/tegra20-seaboard.dts
index c45b698..cee4c34 100644
--- a/arch/arm/boot/dts/tegra20-seaboard.dts
+++ b/arch/arm/boot/dts/tegra20-seaboard.dts
@@ -830,7 +830,7 @@
 		nvidia,spkr-en-gpios = <&wm8903 2 0>;
 		nvidia,hp-det-gpios = <&gpio 185 0>; /* gpio PX1 */
 
-		clocks = <&tegra_car 112>, <&tegra_car 113>, <&tegra_car 93>;
+		clocks = <&tegra_car 112>, <&tegra_car 113>, <&tegra_car 94>;
 		clock-names = "pll_a", "pll_a_out0", "mclk";
 	};
 };
diff --git a/arch/arm/boot/dts/tegra20-tec.dts b/arch/arm/boot/dts/tegra20-tec.dts
index 9be175d..742f0b3 100644
--- a/arch/arm/boot/dts/tegra20-tec.dts
+++ b/arch/arm/boot/dts/tegra20-tec.dts
@@ -53,7 +53,7 @@
 		nvidia,spkr-en-gpios = <&wm8903 2 0>;
 		nvidia,hp-det-gpios = <&gpio 178 0>; /* gpio PW2 */
 
-		clocks = <&tegra_car 112>, <&tegra_car 113>, <&tegra_car 93>;
+		clocks = <&tegra_car 112>, <&tegra_car 113>, <&tegra_car 94>;
 		clock-names = "pll_a", "pll_a_out0", "mclk";
 	};
 };
diff --git a/arch/arm/boot/dts/tegra20-trimslice.dts b/arch/arm/boot/dts/tegra20-trimslice.dts
index f2fbc38..9cc78a1 100644
--- a/arch/arm/boot/dts/tegra20-trimslice.dts
+++ b/arch/arm/boot/dts/tegra20-trimslice.dts
@@ -397,7 +397,7 @@
 		nvidia,i2s-controller = <&tegra_i2s1>;
 		nvidia,audio-codec = <&codec>;
 
-		clocks = <&tegra_car 112>, <&tegra_car 113>, <&tegra_car 93>;
+		clocks = <&tegra_car 112>, <&tegra_car 113>, <&tegra_car 94>;
 		clock-names = "pll_a", "pll_a_out0", "mclk";
 	};
 };
diff --git a/arch/arm/boot/dts/tegra20-ventana.dts b/arch/arm/boot/dts/tegra20-ventana.dts
index 395df48..dd38f1f 100644
--- a/arch/arm/boot/dts/tegra20-ventana.dts
+++ b/arch/arm/boot/dts/tegra20-ventana.dts
@@ -640,7 +640,7 @@
 		nvidia,int-mic-en-gpios = <&gpio 184 0>; /* gpio PX0 */
 		nvidia,ext-mic-en-gpios = <&gpio 185 0>; /* gpio PX1 */
 
-		clocks = <&tegra_car 112>, <&tegra_car 113>, <&tegra_car 93>;
+		clocks = <&tegra_car 112>, <&tegra_car 113>, <&tegra_car 94>;
 		clock-names = "pll_a", "pll_a_out0", "mclk";
 	};
 };
diff --git a/arch/arm/boot/dts/tegra20-whistler.dts b/arch/arm/boot/dts/tegra20-whistler.dts
index 2ed6bb8..d2567f8 100644
--- a/arch/arm/boot/dts/tegra20-whistler.dts
+++ b/arch/arm/boot/dts/tegra20-whistler.dts
@@ -584,7 +584,7 @@
 		nvidia,i2s-controller = <&tegra_i2s1>;
 		nvidia,audio-codec = <&codec>;
 
-		clocks = <&tegra_car 112>, <&tegra_car 113>, <&tegra_car 93>;
+		clocks = <&tegra_car 112>, <&tegra_car 113>, <&tegra_car 94>;
 		clock-names = "pll_a", "pll_a_out0", "mclk";
 	};
 };
diff --git a/arch/arm/boot/dts/tegra20.dtsi b/arch/arm/boot/dts/tegra20.dtsi
index 1911432..3e676a2 100644
--- a/arch/arm/boot/dts/tegra20.dtsi
+++ b/arch/arm/boot/dts/tegra20.dtsi
@@ -478,7 +478,7 @@
 		compatible = "nvidia,tegra20-usb-phy";
 		reg = <0xc5004400 0x3c00>;
 		phy_type = "ulpi";
-		clocks = <&tegra_car 94>, <&tegra_car 127>;
+		clocks = <&tegra_car 93>, <&tegra_car 127>;
 		clock-names = "phy", "pll_u";
 	};
 
-- 
1.7.10.4



From swarren at wwwdotorg.org  Thu Apr  4 19:27:55 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Thu, 04 Apr 2013 17:27:55 -0600
Subject: [PATCH] clk: tegra: Fix cdev1 and cdev2 IDs
In-Reply-To: <1365066304-2327-1-git-send-email-pgaikwad@nvidia.com>
References: <1365066304-2327-1-git-send-email-pgaikwad@nvidia.com>
Message-ID: <515E0C7B.6090005@wwwdotorg.org>

On 04/04/2013 03:05 AM, Prashant Gaikwad wrote:
> Correct IDs for cdev1 and cdev2 are 94 and 93 respectively.

I've applied this, split into the two patches I just posted.


From swarren at wwwdotorg.org  Thu Apr  4 19:29:06 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Thu, 04 Apr 2013 17:29:06 -0600
Subject: [PATCH v9 00/14] Tegra114 clockframework
In-Reply-To: <1365000110-8916-1-git-send-email-pdeschrijver@nvidia.com>
References: <1365000110-8916-1-git-send-email-pdeschrijver@nvidia.com>
Message-ID: <515E0CC2.4060006@wwwdotorg.org>

On 04/03/2013 08:40 AM, Peter De Schrijver wrote:
> This is the nineth version of the Tegra114 clockframework. It is based on the
> next-20130320-fixed branch of ...

I have applied this series to Tegra's for-3.10/clk branch, with patch
10/14 replaced by v9b.




From swarren at wwwdotorg.org  Thu Apr  4 19:31:13 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Thu,  4 Apr 2013 17:31:13 -0600
Subject: [PATCH] clk: tegra: fix enum tegra114_clk to match binding
Message-ID: <1365118274-5823-1-git-send-email-swarren@wwwdotorg.org>

From: Stephen Warren <swarren at nvidia.com>

A gap exists in the binding's clock ID definitions. Fix the clock driver
to be consistent. This allows pclk to be looked up through device tree
and prevents:

ERROR: could not get clock /pmc:pclk(0)

Signed-off-by: Stephen Warren <swarren at nvidia.com>
---
I have already applied this to Tegra's for-3.10/clk branch, since it's
such a trivial fix.

 drivers/clk/tegra/clk-tegra114.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/tegra/clk-tegra114.c b/drivers/clk/tegra/clk-tegra114.c
index 0db81dd..d78e16e 100644
--- a/drivers/clk/tegra/clk-tegra114.c
+++ b/drivers/clk/tegra/clk-tegra114.c
@@ -760,7 +760,7 @@ enum tegra114_clk {
 	pll_re_vco, pll_re_out, pll_e_out0, spdif_in_sync, i2s0_sync,
 	i2s1_sync, i2s2_sync, i2s3_sync, i2s4_sync, vimclk_sync, audio0,
 	audio1, audio2, audio3, audio4, spdif, clk_out_1, clk_out_2, clk_out_3,
-	blink, xusb_host_src, xusb_falcon_src, xusb_fs_src, xusb_ss_src,
+	blink, xusb_host_src = 252, xusb_falcon_src, xusb_fs_src, xusb_ss_src,
 	xusb_dev_src, xusb_dev, xusb_hs_src, sclk, hclk, pclk, cclk_g, cclk_lp,
 
 	/* Mux clocks */
-- 
1.7.10.4



From swarren at wwwdotorg.org  Thu Apr  4 19:33:51 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Thu, 04 Apr 2013 17:33:51 -0600
Subject: [PATCH V2] clk: tegra: defer application of init table
In-Reply-To: <1365111340-2143-1-git-send-email-swarren@wwwdotorg.org>
References: <1365111340-2143-1-git-send-email-swarren@wwwdotorg.org>
Message-ID: <515E0DDF.6050008@wwwdotorg.org>

On 04/04/2013 03:35 PM, Stephen Warren wrote:
> From: Stephen Warren <swarren at nvidia.com>
> 
> The Tegra clock driver is initialized during the ARM machine descriptor's
> .init_irq() hook. It can't be initialized earlier, since dynamic memory
> usage is required. It can't be initialized later, since the .init_timer()
> hook needs the clocks initialized. However, at this time, udelay()
> doesn't work.
> 
> The Tegra clock initialization table may enable some PLLs. Enabling a PLL
> may require usage of udelay(). Hence, this can't happen right when the
> clock driver is initialized.
> 
> To solve this, separate the clock driver initialization from the clock
> table processing, so they can execute at separate times.
> 
> Signed-off-by: Stephen Warren <swarren at nvidia.com>
> ---
> Mike, the Tegra114 CCF V9 series assume this is applied first. Hence, I'm
> looking for an ack on this too. Thanks!

I've applied this to Tegra's for-3.10/clk branch, since Mike already
acked the Tegra114 CCF V9, which requires this patch, and embodies use
of it anyway.


From horms at verge.net.au  Thu Apr  4 20:30:27 2013
From: horms at verge.net.au (Simon Horman)
Date: Fri, 5 Apr 2013 09:30:27 +0900
Subject: [RFC/PATCH 0/7] ARCH: shmobile: defconfig consolidation
In-Reply-To: <1374328.KVLKlOlad0@avalon>
References: <1365046193-19369-1-git-send-email-horms+renesas@verge.net.au>
 <1374328.KVLKlOlad0@avalon>
Message-ID: <20130405003027.GB29203@verge.net.au>

On Thu, Apr 04, 2013 at 01:20:44PM +0200, Laurent Pinchart wrote:
> Hi Simon,
> 
> On Thursday 04 April 2013 12:29:46 Simon Horman wrote:
> > Hi,
> > 
> > this is a first pass at consolidating the defconfigs of shmobile.
> > 
> > It covers the mackerel, amradillo800eva and kzm9d boards which meet
> > the following criteria:
> > 
> > * Have the same base memory address (0x40000000).
> 
> Do you know if there's any work being done on getting rid of the base memory 
> address as a kernel config option ? It seriously hinders cross-SoC kernel 
> testing.

As I understand things the main limitation is uImage which uses
the base memory address. There is some talk of creating uImages
at install time rather than build time. Which I believe would
remove most if not all the problem. However, its entirely unclear
to me what such an install process would look like. A new build target?
In tree script? Out of tree script? It seems very undefined to me.

Another, arguably better though not backwards compatible, option
is to boot using zImage (or even just Image) which do not rely
on the base address.

I'm not aware of any other work or discussion in this area although
it would not surprise me if there was some.

> > * Work with RUNTIME_PM, it is desirable to have that a common defconfig
> > * Are booted via DT, enabling the command line to be supplied in the dts.
> >   This is important to allow serial console and early printk settings,
> >   which vary wildly between boards, to be supplied.
> > * Boards I have to test.
> >   This didn't eliminate any candidates that met the above criteria.
> > 
> > I believe it should also be possible to add support for the APE6EVM
> > board to the consolidated defconfig once problems with RUNTIME_PM
> > have been isolated and resolved. I have send an email about this
> > in a separate thread "APE6EVM and Runtime PM".
> > 
> > I believe it may be possible to add support for the lager board
> > to the consolidated defconfig once I am able to bring that board up,
> > which should be rather soon. The lager board does not currently
> > have a defconfig.
> > 
> > Morimoto-san, I suspect it may be possible to add support for the
> > bockw board to the consolidated defconfig if its boot loader supports
> > booting using a zImage. In this case even though the base memory address
> > is not the same as the boards above it should be possible to specify
> > the base address from the boot loader. As I do not have a bockw board
> > I am wondering if you could investigate this.
> > 
> > Simon Horman (7):
> >   ARM: shmobile: prune defconfig
> >   ARM: shmobile: make defconfig canonical
> >   ARM: shmobile: Add kzm9d to consolidated defconfig
> >   ARM: shmobile: Add mackerel to consolidated defconfig
> >   ARM: shmobile: defconfig: Remove armadillo800eva defconfig
> >   ARM: shmobile: defconfig: Remove kzm9d defconfig
> >   ARM: shmobile: defconfig: Remove mackerel defconfig
> > 
> >  arch/arm/configs/armadillo800eva_defconfig |  153 -------------------------
> >  arch/arm/configs/kzm9d_defconfig           |   88 ----------------
> >  arch/arm/configs/mackerel_defconfig        |  156 -------------------------
> >  arch/arm/configs/shmobile_defconfig        |   51 +++++----
> >  4 files changed, 28 insertions(+), 420 deletions(-)
> >  delete mode 100644 arch/arm/configs/armadillo800eva_defconfig
> >  delete mode 100644 arch/arm/configs/kzm9d_defconfig
> >  delete mode 100644 arch/arm/configs/mackerel_defconfig
> -- 
> Regards,
> 
> Laurent Pinchart
> 


From horms at verge.net.au  Thu Apr  4 20:36:14 2013
From: horms at verge.net.au (Simon Horman)
Date: Fri, 5 Apr 2013 09:36:14 +0900
Subject: [PATCH v3 1/2] irqchip: intc-irqpin: Add support for shared
 interrupt lines
In-Reply-To: <CABYn4szuJGFNTQUEoYcRAa34cj+fK=0RpaATDksu3mAM3L8vgg@mail.gmail.com>
References: <1364296699-20919-1-git-send-email-hechtb+renesas@gmail.com>
 <20130327045942.GH25431@verge.net.au>
 <CABYn4sx_pRxgdM3kD3okmt8xbCFas+T0cczQO=RF75Q8Bt2e_Q@mail.gmail.com>
 <20130403074604.GC30989@verge.net.au>
 <CABYn4szuJGFNTQUEoYcRAa34cj+fK=0RpaATDksu3mAM3L8vgg@mail.gmail.com>
Message-ID: <20130405003614.GD29203@verge.net.au>

On Thu, Apr 04, 2013 at 03:47:34PM +0200, Bastian Hecht wrote:
> Hi Simon,
> 
> ok I've sent out a patch series with the reference DT code. I've had
> to adapt a couple of things and the device list is rather short. How
> long do I have to augment it a bit before the merge window closes?

The merge window is more or less closed. So I think we will have
to aim for v3.11. But I don't think that should affect the way
you write the code, please just base it on the latest renesas-next tag.

> Thanks,
> 
>  Bastian
> 
> 
> 2013/4/3 Simon Horman <horms at verge.net.au>:
> > On Wed, Mar 27, 2013 at 02:50:05PM +0100, Bastian Hecht wrote:
> >> Hi Simon,
> >>
> >> 2013/3/27 Simon Horman <horms at verge.net.au>:
> >> > On Tue, Mar 26, 2013 at 12:18:18PM +0100, Bastian Hecht wrote:
> >> >> On some hardware we don't have a 1-1 mapping from the external
> >> >> interrupts coming from INTC to the GIC SPI pins. We can however
> >> >> share lines to demux incoming IRQs on these SoCs.
> >> >>
> >> >> This patch enables the intc_irqpin driver to detect requests for shared
> >> >> interrupt lines and demuxes them properly by querying the INTC INTREQx0A
> >> >> registers.
> >> >>
> >> >> If you need multiple shared intc_irqpin device instances, be sure to mask
> >> >> out all interrupts on the INTC that share the one line before you start
> >> >> to register them. Else you run into IRQ floods that would be caused by
> >> >> interrupts for which no handler has been set up yet when the first
> >> >> intc_irqpin device is registered.
> >> >>
> >> >> Signed-off-by: Bastian Hecht <hechtb+renesas at gmail.com>
> >> >> Acked-by: Magnus Damm <damm at opensource.se>
> >> >
> >> > Thanks, I will see about queuing up these changes for v3.10.
> >> >
> >> >
> >> > I believe that with these changes it should be possible to rebase/rework
> >> > armadillo800eva-reference so that it no longer uses the unmerged INTC
> >> > DT bindings. Would it be possible for you to see about making a fresh
> >> > version of armadillo800eva-reference that is based on the next branch
> >> > in the Renesas tree plus this series of two patches?
> >>
> >> yes ok, I'll prepare a new armadillo reference version. The patches
> >> were based on all+next, but I'll post a v4 rebased on next.
> >> I'll post a separate patch series for the reference code if you don't
> >> mind, as this might take a few days to be done.
> >
> > Hi Bastian,
> >
> > gentle nudge with regards to a fresh armadillo-reference.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


From laurent.pinchart at ideasonboard.com  Thu Apr  4 20:37:38 2013
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Fri, 05 Apr 2013 02:37:38 +0200
Subject: [RFC/PATCH 0/7] ARCH: shmobile: defconfig consolidation
In-Reply-To: <20130405003027.GB29203@verge.net.au>
References: <1365046193-19369-1-git-send-email-horms+renesas@verge.net.au>
 <1374328.KVLKlOlad0@avalon> <20130405003027.GB29203@verge.net.au>
Message-ID: <2243996.H0VQ4NfsDe@avalon>

On Friday 05 April 2013 09:30:27 Simon Horman wrote:
> On Thu, Apr 04, 2013 at 01:20:44PM +0200, Laurent Pinchart wrote:
> > On Thursday 04 April 2013 12:29:46 Simon Horman wrote:
> > > Hi,
> > > 
> > > this is a first pass at consolidating the defconfigs of shmobile.
> > > 
> > > It covers the mackerel, amradillo800eva and kzm9d boards which meet
> > > the following criteria:
> > > 
> > > * Have the same base memory address (0x40000000).
> > 
> > Do you know if there's any work being done on getting rid of the base
> > memory address as a kernel config option ? It seriously hinders cross-SoC
> > kernel testing.
> 
> As I understand things the main limitation is uImage which uses
> the base memory address. There is some talk of creating uImages
> at install time rather than build time. Which I believe would
> remove most if not all the problem. However, its entirely unclear
> to me what such an install process would look like. A new build target?
> In tree script? Out of tree script? It seems very undefined to me.
> 
> Another, arguably better though not backwards compatible, option
> is to boot using zImage (or even just Image) which do not rely
> on the base address.

Don't we also need to get rid of CONFIG_MEMORY_START ? It's used in headsmp.S 
and headsmp-scu.S (through PLAT_PHYS_OFFSET).

> I'm not aware of any other work or discussion in this area although
> it would not surprise me if there was some.
>
> > > * Work with RUNTIME_PM, it is desirable to have that a common defconfig
> > > * Are booted via DT, enabling the command line to be supplied in the
> > > dts.
> > > 
> > >   This is important to allow serial console and early printk settings,
> > >   which vary wildly between boards, to be supplied.
> > > 
> > > * Boards I have to test.
> > > 
> > >   This didn't eliminate any candidates that met the above criteria.
> > > 
> > > I believe it should also be possible to add support for the APE6EVM
> > > board to the consolidated defconfig once problems with RUNTIME_PM
> > > have been isolated and resolved. I have send an email about this
> > > in a separate thread "APE6EVM and Runtime PM".
> > > 
> > > I believe it may be possible to add support for the lager board
> > > to the consolidated defconfig once I am able to bring that board up,
> > > which should be rather soon. The lager board does not currently
> > > have a defconfig.
> > > 
> > > Morimoto-san, I suspect it may be possible to add support for the
> > > bockw board to the consolidated defconfig if its boot loader supports
> > > booting using a zImage. In this case even though the base memory address
> > > is not the same as the boards above it should be possible to specify
> > > the base address from the boot loader. As I do not have a bockw board
> > > I am wondering if you could investigate this.
> > > 
> > > Simon Horman (7):
> > >   ARM: shmobile: prune defconfig
> > >   ARM: shmobile: make defconfig canonical
> > >   ARM: shmobile: Add kzm9d to consolidated defconfig
> > >   ARM: shmobile: Add mackerel to consolidated defconfig
> > >   ARM: shmobile: defconfig: Remove armadillo800eva defconfig
> > >   ARM: shmobile: defconfig: Remove kzm9d defconfig
> > >   ARM: shmobile: defconfig: Remove mackerel defconfig
> > >  
> > >  arch/arm/configs/armadillo800eva_defconfig |  153 ---------------------
> > >  arch/arm/configs/kzm9d_defconfig           |   88 ----------------
> > >  arch/arm/configs/mackerel_defconfig        |  156 ---------------------
> > >  arch/arm/configs/shmobile_defconfig        |   51 +++++----
> > >  4 files changed, 28 insertions(+), 420 deletions(-)
> > >  delete mode 100644 arch/arm/configs/armadillo800eva_defconfig
> > >  delete mode 100644 arch/arm/configs/kzm9d_defconfig
> > >  delete mode 100644 arch/arm/configs/mackerel_defconfig

-- 
Regards,

Laurent Pinchart



From horms at verge.net.au  Thu Apr  4 20:40:20 2013
From: horms at verge.net.au (Simon Horman)
Date: Fri, 5 Apr 2013 09:40:20 +0900
Subject: [PATCH v4 3/3] ARM: shmobile: kzm9g-reference: add CPUFreq support
In-Reply-To: <Pine.LNX.4.64.1304042352180.21548@axis700.grange>
References: <1364153255-20664-1-git-send-email-g.liakhovetski@gmx.de>
 <1364153255-20664-4-git-send-email-g.liakhovetski@gmx.de>
 <20130404043746.GD28297@verge.net.au>
 <Pine.LNX.4.64.1304042352180.21548@axis700.grange>
Message-ID: <20130405004020.GM29203@verge.net.au>

On Thu, Apr 04, 2013 at 11:54:20PM +0200, Guennadi Liakhovetski wrote:
> Hi Simon
> 
> Thanks for the review
> 
> On Thu, 4 Apr 2013, Simon Horman wrote:
> 
> > On Sun, Mar 24, 2013 at 08:27:35PM +0100, Guennadi Liakhovetski wrote:
> > > This patch enables the use of the generic cpufreq-cpu0 driver on kzm9g.
> > > Providing a regulator, a list of OPPs in DT, combined with a virtual
> > > cpufreq-cpu0 platform device and a clock, attached to it is everything,
> > > the cpufreq-cpu0 driver needs.
> > 
> > I wonder if it would be possible to re-arange this patch a little.
> > 
> > 1) vdd_dvfs is added in this patch but it appears to be used in the
> >    previous patch in the series. I wonder if this can be resolved
> >    by re-ordering the patches.
> 
> Right, I'll change that.
> 
> > 2) It includes both kzm9g board and sh73a0 SoC changes.
> >    I would prefer if the sh73a0 SoC portion (setup-sh73a0.c)
> >    was moved into a separate patch. The arm-soc people
> >    like to have separate board and SoC branches.
> 
> Yes, I'll probably just merge the sh73a0-kzm9g-reference.dts hunk into the 
> previous patch.

Thanks, I think that approach should work well.


From horms at verge.net.au  Thu Apr  4 20:41:47 2013
From: horms at verge.net.au (Simon Horman)
Date: Fri, 5 Apr 2013 09:41:47 +0900
Subject: [PATCH 1/8] ARM: shmobile:Marzen: move USB EHCI, OHCI, and PHY
 devices to R8A7779 code
In-Reply-To: <201304050257.00799.sergei.shtylyov@cogentembedded.com>
References: <201304050257.00799.sergei.shtylyov@cogentembedded.com>
Message-ID: <20130405004147.GN29203@verge.net.au>

On Fri, Apr 05, 2013 at 02:57:00AM +0400, Sergei Shtylyov wrote:
> USB EHCI, OHCI, and common PHY are the SoC devices but are wrongly defined and
> registered in the Marzen board file.  Move the data and code to their proper
> place in setup-r8a7779.c; while at it, we have to rename 8a7779_late_devices[]
> to 8a7779_standard_devices[] -- this seems legitimate since they are registered
> from r8a7779_add_standard_devices() anyway.
> 
> Note that I'm deliberately changing the USB PHY platform device's 'id' field
> from (previously just omitted) 0 to -1 as the device is a single of its kind.

Would it be possible to re-arange this patch so that
there is an SoC patch followed by a board patch?

> 
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
> 
> ---
>  arch/arm/mach-shmobile/board-marzen.c         |  178 -------------------------
>  arch/arm/mach-shmobile/include/mach/r8a7779.h |    1 
>  arch/arm/mach-shmobile/setup-r8a7779.c        |  185 +++++++++++++++++++++++++-
>  3 files changed, 184 insertions(+), 180 deletions(-)
> 
> Index: renesas/arch/arm/mach-shmobile/board-marzen.c
> ===================================================================
> --- renesas.orig/arch/arm/mach-shmobile/board-marzen.c
> +++ renesas/arch/arm/mach-shmobile/board-marzen.c
> @@ -36,10 +36,6 @@
>  #include <linux/mmc/host.h>
>  #include <linux/mmc/sh_mobile_sdhi.h>
>  #include <linux/mfd/tmio.h>
> -#include <linux/usb/otg.h>
> -#include <linux/usb/ehci_pdriver.h>
> -#include <linux/usb/ohci_pdriver.h>
> -#include <linux/pm_runtime.h>
>  #include <mach/hardware.h>
>  #include <mach/r8a7779.h>
>  #include <mach/common.h>
> @@ -149,26 +145,6 @@ static struct platform_device hspi_devic
>  	.num_resources	= ARRAY_SIZE(hspi_resources),
>  };
>  
> -/* USB PHY */
> -static struct resource usb_phy_resources[] = {
> -	[0] = {
> -		.start		= 0xffe70000,
> -		.end		= 0xffe70900 - 1,
> -		.flags		= IORESOURCE_MEM,
> -	},
> -	[1] = {
> -		.start		= 0xfff70000,
> -		.end		= 0xfff70900 - 1,
> -		.flags		= IORESOURCE_MEM,
> -	},
> -};
> -
> -static struct platform_device usb_phy_device = {
> -	.name		= "rcar_usb_phy",
> -	.resource	= usb_phy_resources,
> -	.num_resources	= ARRAY_SIZE(usb_phy_resources),
> -};
> -
>  /* LEDS */
>  static struct gpio_led marzen_leds[] = {
>  	{
> @@ -204,161 +180,9 @@ static struct platform_device *marzen_de
>  	&sdhi0_device,
>  	&thermal_device,
>  	&hspi_device,
> -	&usb_phy_device,
>  	&leds_device,
>  };
>  
> -/* USB */
> -static struct usb_phy *phy;
> -static int usb_power_on(struct platform_device *pdev)
> -{
> -	if (!phy)
> -		return -EIO;
> -
> -	pm_runtime_enable(&pdev->dev);
> -	pm_runtime_get_sync(&pdev->dev);
> -
> -	usb_phy_init(phy);
> -
> -	return 0;
> -}
> -
> -static void usb_power_off(struct platform_device *pdev)
> -{
> -	if (!phy)
> -		return;
> -
> -	usb_phy_shutdown(phy);
> -
> -	pm_runtime_put_sync(&pdev->dev);
> -	pm_runtime_disable(&pdev->dev);
> -}
> -
> -static struct usb_ehci_pdata ehcix_pdata = {
> -	.power_on	= usb_power_on,
> -	.power_off	= usb_power_off,
> -	.power_suspend	= usb_power_off,
> -};
> -
> -static struct resource ehci0_resources[] = {
> -	[0] = {
> -		.start	= 0xffe70000,
> -		.end	= 0xffe70400 - 1,
> -		.flags	= IORESOURCE_MEM,
> -	},
> -	[1] = {
> -		.start	= gic_iid(0x4c),
> -		.flags	= IORESOURCE_IRQ,
> -	},
> -};
> -
> -static struct platform_device ehci0_device = {
> -	.name	= "ehci-platform",
> -	.id	= 0,
> -	.dev	= {
> -		.dma_mask		= &ehci0_device.dev.coherent_dma_mask,
> -		.coherent_dma_mask	= 0xffffffff,
> -		.platform_data		= &ehcix_pdata,
> -	},
> -	.num_resources	= ARRAY_SIZE(ehci0_resources),
> -	.resource	= ehci0_resources,
> -};
> -
> -static struct resource ehci1_resources[] = {
> -	[0] = {
> -		.start	= 0xfff70000,
> -		.end	= 0xfff70400 - 1,
> -		.flags	= IORESOURCE_MEM,
> -	},
> -	[1] = {
> -		.start	= gic_iid(0x4d),
> -		.flags	= IORESOURCE_IRQ,
> -	},
> -};
> -
> -static struct platform_device ehci1_device = {
> -	.name	= "ehci-platform",
> -	.id	= 1,
> -	.dev	= {
> -		.dma_mask		= &ehci1_device.dev.coherent_dma_mask,
> -		.coherent_dma_mask	= 0xffffffff,
> -		.platform_data		= &ehcix_pdata,
> -	},
> -	.num_resources	= ARRAY_SIZE(ehci1_resources),
> -	.resource	= ehci1_resources,
> -};
> -
> -static struct usb_ohci_pdata ohcix_pdata = {
> -	.power_on	= usb_power_on,
> -	.power_off	= usb_power_off,
> -	.power_suspend	= usb_power_off,
> -};
> -
> -static struct resource ohci0_resources[] = {
> -	[0] = {
> -		.start	= 0xffe70400,
> -		.end	= 0xffe70800 - 1,
> -		.flags	= IORESOURCE_MEM,
> -	},
> -	[1] = {
> -		.start	= gic_iid(0x4c),
> -		.flags	= IORESOURCE_IRQ,
> -	},
> -};
> -
> -static struct platform_device ohci0_device = {
> -	.name	= "ohci-platform",
> -	.id	= 0,
> -	.dev	= {
> -		.dma_mask		= &ohci0_device.dev.coherent_dma_mask,
> -		.coherent_dma_mask	= 0xffffffff,
> -		.platform_data		= &ohcix_pdata,
> -	},
> -	.num_resources	= ARRAY_SIZE(ohci0_resources),
> -	.resource	= ohci0_resources,
> -};
> -
> -static struct resource ohci1_resources[] = {
> -	[0] = {
> -		.start	= 0xfff70400,
> -		.end	= 0xfff70800 - 1,
> -		.flags	= IORESOURCE_MEM,
> -	},
> -	[1] = {
> -		.start	= gic_iid(0x4d),
> -		.flags	= IORESOURCE_IRQ,
> -	},
> -};
> -
> -static struct platform_device ohci1_device = {
> -	.name	= "ohci-platform",
> -	.id	= 1,
> -	.dev	= {
> -		.dma_mask		= &ohci1_device.dev.coherent_dma_mask,
> -		.coherent_dma_mask	= 0xffffffff,
> -		.platform_data		= &ohcix_pdata,
> -	},
> -	.num_resources	= ARRAY_SIZE(ohci1_resources),
> -	.resource	= ohci1_resources,
> -};
> -
> -static struct platform_device *marzen_late_devices[] __initdata = {
> -	&ehci0_device,
> -	&ehci1_device,
> -	&ohci0_device,
> -	&ohci1_device,
> -};
> -
> -void __init marzen_init_late(void)
> -{
> -	/* get usb phy */
> -	phy = usb_get_phy(USB_PHY_TYPE_USB2);
> -
> -	shmobile_init_late();
> -	platform_add_devices(marzen_late_devices,
> -			     ARRAY_SIZE(marzen_late_devices));
> -}
> -
>  static const struct pinctrl_map marzen_pinctrl_map[] = {
>  	/* HSPI0 */
>  	PIN_MAP_MUX_GROUP_DEFAULT("sh-hspi.0", "pfc-r8a7779",
> @@ -416,6 +240,6 @@ MACHINE_START(MARZEN, "marzen")
>  	.nr_irqs	= NR_IRQS_LEGACY,
>  	.init_irq	= r8a7779_init_irq,
>  	.init_machine	= marzen_init,
> -	.init_late	= marzen_init_late,
> +	.init_late	= r8a7779_init_late,
>  	.init_time	= r8a7779_earlytimer_init,
>  MACHINE_END
> Index: renesas/arch/arm/mach-shmobile/include/mach/r8a7779.h
> ===================================================================
> --- renesas.orig/arch/arm/mach-shmobile/include/mach/r8a7779.h
> +++ renesas/arch/arm/mach-shmobile/include/mach/r8a7779.h
> @@ -33,6 +33,7 @@ extern void r8a7779_add_early_devices(vo
>  extern void r8a7779_add_standard_devices(void);
>  extern void r8a7779_add_standard_devices_dt(void);
>  extern void r8a7779_add_ether_device(struct sh_eth_plat_data *pdata);
> +extern void r8a7779_init_late(void);
>  extern void r8a7779_clock_init(void);
>  extern void r8a7779_pinmux_init(void);
>  extern void r8a7779_pm_init(void);
> Index: renesas/arch/arm/mach-shmobile/setup-r8a7779.c
> ===================================================================
> --- renesas.orig/arch/arm/mach-shmobile/setup-r8a7779.c
> +++ renesas/arch/arm/mach-shmobile/setup-r8a7779.c
> @@ -32,6 +32,10 @@
>  #include <linux/sh_intc.h>
>  #include <linux/sh_timer.h>
>  #include <linux/dma-mapping.h>
> +#include <linux/usb/otg.h>
> +#include <linux/usb/ehci_pdriver.h>
> +#include <linux/usb/ohci_pdriver.h>
> +#include <linux/pm_runtime.h>
>  #include <mach/hardware.h>
>  #include <mach/irqs.h>
>  #include <mach/r8a7779.h>
> @@ -394,6 +398,162 @@ static struct platform_device sata_devic
>  	},
>  };
>  
> +/* USB PHY */
> +static struct resource usb_phy_resources[] = {
> +	[0] = {
> +		.start		= 0xffe70000,
> +		.end		= 0xffe70900 - 1,
> +		.flags		= IORESOURCE_MEM,
> +	},
> +	[1] = {
> +		.start		= 0xfff70000,
> +		.end		= 0xfff70900 - 1,
> +		.flags		= IORESOURCE_MEM,
> +	},
> +};
> +
> +static struct platform_device usb_phy_device = {
> +	.name		= "rcar_usb_phy",
> +	.id		= -1,
> +	.resource	= usb_phy_resources,
> +	.num_resources	= ARRAY_SIZE(usb_phy_resources),
> +};
> +
> +/* USB */
> +static struct usb_phy *phy;
> +
> +static int usb_power_on(struct platform_device *pdev)
> +{
> +	if (!phy)
> +		return -EIO;
> +
> +	pm_runtime_enable(&pdev->dev);
> +	pm_runtime_get_sync(&pdev->dev);
> +
> +	usb_phy_init(phy);
> +
> +	return 0;
> +}
> +
> +static void usb_power_off(struct platform_device *pdev)
> +{
> +	if (!phy)
> +		return;
> +
> +	usb_phy_shutdown(phy);
> +
> +	pm_runtime_put_sync(&pdev->dev);
> +	pm_runtime_disable(&pdev->dev);
> +}
> +
> +static struct usb_ehci_pdata ehcix_pdata = {
> +	.power_on	= usb_power_on,
> +	.power_off	= usb_power_off,
> +	.power_suspend	= usb_power_off,
> +};
> +
> +static struct resource ehci0_resources[] = {
> +	[0] = {
> +		.start	= 0xffe70000,
> +		.end	= 0xffe70400 - 1,
> +		.flags	= IORESOURCE_MEM,
> +	},
> +	[1] = {
> +		.start	= gic_iid(0x4c),
> +		.flags	= IORESOURCE_IRQ,
> +	},
> +};
> +
> +static struct platform_device ehci0_device = {
> +	.name	= "ehci-platform",
> +	.id	= 0,
> +	.dev	= {
> +		.dma_mask		= &ehci0_device.dev.coherent_dma_mask,
> +		.coherent_dma_mask	= 0xffffffff,
> +		.platform_data		= &ehcix_pdata,
> +	},
> +	.num_resources	= ARRAY_SIZE(ehci0_resources),
> +	.resource	= ehci0_resources,
> +};
> +
> +static struct resource ehci1_resources[] = {
> +	[0] = {
> +		.start	= 0xfff70000,
> +		.end	= 0xfff70400 - 1,
> +		.flags	= IORESOURCE_MEM,
> +	},
> +	[1] = {
> +		.start	= gic_iid(0x4d),
> +		.flags	= IORESOURCE_IRQ,
> +	},
> +};
> +
> +static struct platform_device ehci1_device = {
> +	.name	= "ehci-platform",
> +	.id	= 1,
> +	.dev	= {
> +		.dma_mask		= &ehci1_device.dev.coherent_dma_mask,
> +		.coherent_dma_mask	= 0xffffffff,
> +		.platform_data		= &ehcix_pdata,
> +	},
> +	.num_resources	= ARRAY_SIZE(ehci1_resources),
> +	.resource	= ehci1_resources,
> +};
> +
> +static struct usb_ohci_pdata ohcix_pdata = {
> +	.power_on	= usb_power_on,
> +	.power_off	= usb_power_off,
> +	.power_suspend	= usb_power_off,
> +};
> +
> +static struct resource ohci0_resources[] = {
> +	[0] = {
> +		.start	= 0xffe70400,
> +		.end	= 0xffe70800 - 1,
> +		.flags	= IORESOURCE_MEM,
> +	},
> +	[1] = {
> +		.start	= gic_iid(0x4c),
> +		.flags	= IORESOURCE_IRQ,
> +	},
> +};
> +
> +static struct platform_device ohci0_device = {
> +	.name	= "ohci-platform",
> +	.id	= 0,
> +	.dev	= {
> +		.dma_mask		= &ohci0_device.dev.coherent_dma_mask,
> +		.coherent_dma_mask	= 0xffffffff,
> +		.platform_data		= &ohcix_pdata,
> +	},
> +	.num_resources	= ARRAY_SIZE(ohci0_resources),
> +	.resource	= ohci0_resources,
> +};
> +
> +static struct resource ohci1_resources[] = {
> +	[0] = {
> +		.start	= 0xfff70400,
> +		.end	= 0xfff70800 - 1,
> +		.flags	= IORESOURCE_MEM,
> +	},
> +	[1] = {
> +		.start	= gic_iid(0x4d),
> +		.flags	= IORESOURCE_IRQ,
> +	},
> +};
> +
> +static struct platform_device ohci1_device = {
> +	.name	= "ohci-platform",
> +	.id	= 1,
> +	.dev	= {
> +		.dma_mask		= &ohci1_device.dev.coherent_dma_mask,
> +		.coherent_dma_mask	= 0xffffffff,
> +		.platform_data		= &ohcix_pdata,
> +	},
> +	.num_resources	= ARRAY_SIZE(ohci1_resources),
> +	.resource	= ohci1_resources,
> +};
> +
>  /* Ether */
>  static struct resource ether_resources[] = {
>  	{
> @@ -415,9 +575,10 @@ static struct platform_device *r8a7779_d
>  	&scif5_device,
>  	&tmu00_device,
>  	&tmu01_device,
> +	&usb_phy_device,
>  };
>  
> -static struct platform_device *r8a7779_late_devices[] __initdata = {
> +static struct platform_device *r8a7779_standard_devices[] __initdata = {
>  	&i2c0_device,
>  	&i2c1_device,
>  	&i2c2_device,
> @@ -437,8 +598,8 @@ void __init r8a7779_add_standard_devices
>  
>  	platform_add_devices(r8a7779_devices_dt,
>  			    ARRAY_SIZE(r8a7779_devices_dt));
> -	platform_add_devices(r8a7779_late_devices,
> -			    ARRAY_SIZE(r8a7779_late_devices));
> +	platform_add_devices(r8a7779_standard_devices,
> +			    ARRAY_SIZE(r8a7779_standard_devices));
>  }
>  
>  void __init r8a7779_add_ether_device(struct sh_eth_plat_data *pdata)
> @@ -481,6 +642,23 @@ void __init r8a7779_add_early_devices(vo
>  	 */
>  }
>  
> +static struct platform_device *r8a7779_late_devices[] __initdata = {
> +	&ehci0_device,
> +	&ehci1_device,
> +	&ohci0_device,
> +	&ohci1_device,
> +};
> +
> +void __init r8a7779_init_late(void)
> +{
> +	/* get USB PHY */
> +	phy = usb_get_phy(USB_PHY_TYPE_USB2);
> +
> +	shmobile_init_late();
> +	platform_add_devices(r8a7779_late_devices,
> +			     ARRAY_SIZE(r8a7779_late_devices));
> +}
> +
>  #ifdef CONFIG_USE_OF
>  void __init r8a7779_init_delay(void)
>  {
> @@ -514,6 +692,7 @@ DT_MACHINE_START(R8A7779_DT, "Generic R8
>  	.init_irq	= r8a7779_init_irq_dt,
>  	.init_machine	= r8a7779_add_standard_devices_dt,
>  	.init_time	= shmobile_timer_init,
> +	.init_late	= r8a7779_init_late,
>  	.dt_compat	= r8a7779_compat_dt,
>  MACHINE_END
>  #endif /* CONFIG_USE_OF */
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


From horms at verge.net.au  Thu Apr  4 20:43:00 2013
From: horms at verge.net.au (Simon Horman)
Date: Fri, 5 Apr 2013 09:43:00 +0900
Subject: [PATCH 4/8] rcar-phy: remove EHCI internal buffer setup
In-Reply-To: <201304050303.56515.sergei.shtylyov@cogentembedded.com>
References: <201304050303.56515.sergei.shtylyov@cogentembedded.com>
Message-ID: <20130405004300.GO29203@verge.net.au>

On Fri, Apr 05, 2013 at 03:03:55AM +0400, Sergei Shtylyov wrote:
> Now that the EHCI internal buffer setup is done by the platform code, we  can
> remove  such code from this driver as it never really belonged here.  We also
> no longer need the 2nd memory region now (2nd EHCI controller is simply missing
> in e.g. R8A7778 SoC).

I wonder if this patch could be split into a driver patch
followed by an SoC patch. Or vice versa.

> 
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
> 
> ---
>  arch/arm/mach-shmobile/setup-r8a7779.c |    5 -----
>  drivers/usb/phy/rcar-phy.c             |   28 ++++------------------------
>  2 files changed, 4 insertions(+), 29 deletions(-)
> 
> Index: renesas/arch/arm/mach-shmobile/setup-r8a7779.c
> ===================================================================
> --- renesas.orig/arch/arm/mach-shmobile/setup-r8a7779.c
> +++ renesas/arch/arm/mach-shmobile/setup-r8a7779.c
> @@ -405,11 +405,6 @@ static struct resource usb_phy_resources
>  		.end		= 0xffe70900 - 1,
>  		.flags		= IORESOURCE_MEM,
>  	},
> -	[1] = {
> -		.start		= 0xfff70000,
> -		.end		= 0xfff70900 - 1,
> -		.flags		= IORESOURCE_MEM,
> -	},
>  };
>  
>  static struct platform_device usb_phy_device = {
> Index: renesas/drivers/usb/phy/rcar-phy.c
> ===================================================================
> --- renesas.orig/drivers/usb/phy/rcar-phy.c
> +++ renesas/drivers/usb/phy/rcar-phy.c
> @@ -23,8 +23,6 @@
>  #define USBEH0		0x080C
>  #define USBOH0		0x081C
>  #define USBCTL0		0x0858
> -#define EIIBC1		0x0094
> -#define EIIBC2		0x009C
>  
>  /* USBPCTRL1 */
>  #define PHY_RST		(1 << 2)
> @@ -40,7 +38,6 @@ struct rcar_usb_phy_priv {
>  	spinlock_t lock;
>  
>  	void __iomem *reg0;
> -	void __iomem *reg1;
>  	int counter;
>  };
>  
> @@ -59,7 +56,6 @@ static int rcar_usb_phy_init(struct usb_
>  	struct rcar_usb_phy_priv *priv = usb_phy_to_priv(phy);
>  	struct device *dev = phy->dev;
>  	void __iomem *reg0 = priv->reg0;
> -	void __iomem *reg1 = priv->reg1;
>  	int i;
>  	u32 val;
>  	unsigned long flags;
> @@ -97,19 +93,6 @@ static int rcar_usb_phy_init(struct usb_
>  		iowrite32(0x00000000, (reg0 + USBPCTRL0));
>  
>  		/*
> -		 * EHCI IP internal buffer setting
> -		 * EHCI IP internal buffer enable
> -		 *
> -		 * These are recommended value of a datasheet
> -		 * see [USB :: EHCI internal buffer setting]
> -		 */
> -		iowrite32(0x00ff0040, (reg0 + EIIBC1));
> -		iowrite32(0x00ff0040, (reg1 + EIIBC1));
> -
> -		iowrite32(0x00000001, (reg0 + EIIBC2));
> -		iowrite32(0x00000001, (reg1 + EIIBC2));
> -
> -		/*
>  		 * Bus alignment settings
>  		 */
>  
> @@ -145,14 +128,13 @@ static void rcar_usb_phy_shutdown(struct
>  static int rcar_usb_phy_probe(struct platform_device *pdev)
>  {
>  	struct rcar_usb_phy_priv *priv;
> -	struct resource *res0, *res1;
> +	struct resource *res0;
>  	struct device *dev = &pdev->dev;
> -	void __iomem *reg0, *reg1;
> +	void __iomem *reg0;
>  	int ret;
>  
>  	res0 = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> -	res1 = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> -	if (!res0 || !res1) {
> +	if (!res0) {
>  		dev_err(dev, "Not enough platform resources\n");
>  		return -EINVAL;
>  	}
> @@ -164,8 +146,7 @@ static int rcar_usb_phy_probe(struct pla
>  	 * this driver can't use devm_request_and_ioremap(dev, res) here
>  	 */
>  	reg0 = devm_ioremap_nocache(dev, res0->start, resource_size(res0));
> -	reg1 = devm_ioremap_nocache(dev, res1->start, resource_size(res1));
> -	if (!reg0 || !reg1) {
> +	if (!reg0) {
>  		dev_err(dev, "ioremap error\n");
>  		return -ENOMEM;
>  	}
> @@ -177,7 +158,6 @@ static int rcar_usb_phy_probe(struct pla
>  	}
>  
>  	priv->reg0		= reg0;
> -	priv->reg1		= reg1;
>  	priv->counter		= 0;
>  	priv->phy.dev		= dev;
>  	priv->phy.label		= dev_name(dev);
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


From horms at verge.net.au  Thu Apr  4 20:43:56 2013
From: horms at verge.net.au (Simon Horman)
Date: Fri, 5 Apr 2013 09:43:56 +0900
Subject: [PATCH 5/8] rcar-phy: correct base address
In-Reply-To: <201304050305.15517.sergei.shtylyov@cogentembedded.com>
References: <201304050305.15517.sergei.shtylyov@cogentembedded.com>
Message-ID: <20130405004356.GP29203@verge.net.au>

On Fri, Apr 05, 2013 at 03:05:14AM +0400, Sergei Shtylyov wrote:
> The memory region that is used by the driver overlaps EHCI and OHCI register
> regions for absolutely no reason now  -- fix it by adding offset of 0x800 to
> the base address, changing the register #define's accordingly. This has extra
> positive effect that we now can use devm_ioremap_resource().
> 
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

As per my comment regarding patch 4, I wonder if this
could be split into a driver patch and an SoC patch.

> 
> ---
>  arch/arm/mach-shmobile/setup-r8a7779.c |    2 +-
>  drivers/usb/phy/rcar-phy.c             |   28 ++++++++++------------------
>  2 files changed, 11 insertions(+), 19 deletions(-)
> 
> Index: renesas/arch/arm/mach-shmobile/setup-r8a7779.c
> ===================================================================
> --- renesas.orig/arch/arm/mach-shmobile/setup-r8a7779.c
> +++ renesas/arch/arm/mach-shmobile/setup-r8a7779.c
> @@ -401,7 +401,7 @@ static struct platform_device sata_devic
>  /* USB PHY */
>  static struct resource usb_phy_resources[] = {
>  	[0] = {
> -		.start		= 0xffe70000,
> +		.start		= 0xffe70800,
>  		.end		= 0xffe70900 - 1,
>  		.flags		= IORESOURCE_MEM,
>  	},
> Index: renesas/drivers/usb/phy/rcar-phy.c
> ===================================================================
> --- renesas.orig/drivers/usb/phy/rcar-phy.c
> +++ renesas/drivers/usb/phy/rcar-phy.c
> @@ -16,13 +16,13 @@
>  #include <linux/spinlock.h>
>  #include <linux/module.h>
>  
> -/* USBH common register */
> -#define USBPCTRL0	0x0800
> -#define USBPCTRL1	0x0804
> -#define USBST		0x0808
> -#define USBEH0		0x080C
> -#define USBOH0		0x081C
> -#define USBCTL0		0x0858
> +/* REGS block */
> +#define USBPCTRL0	0x00
> +#define USBPCTRL1	0x04
> +#define USBST		0x08
> +#define USBEH0		0x0C
> +#define USBOH0		0x1C
> +#define USBCTL0		0x58
>  
>  /* USBPCTRL1 */
>  #define PHY_RST		(1 << 2)
> @@ -139,17 +139,9 @@ static int rcar_usb_phy_probe(struct pla
>  		return -EINVAL;
>  	}
>  
> -	/*
> -	 * CAUTION
> -	 *
> -	 * Because this phy address is also mapped under OHCI/EHCI address area,
> -	 * this driver can't use devm_request_and_ioremap(dev, res) here
> -	 */
> -	reg0 = devm_ioremap_nocache(dev, res0->start, resource_size(res0));
> -	if (!reg0) {
> -		dev_err(dev, "ioremap error\n");
> -		return -ENOMEM;
> -	}
> +	reg0 = devm_ioremap_resource(dev, res0);
> +	if (IS_ERR(reg0))
> +		return PTR_ERR(reg0);
>  
>  	priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
>  	if (!priv) {
> 


From horms at verge.net.au  Thu Apr  4 20:44:45 2013
From: horms at verge.net.au (Simon Horman)
Date: Fri, 5 Apr 2013 09:44:45 +0900
Subject: [PATCH 7/8] ARM: shmobile: Marzen: pass platform data to USB PHY
 device
In-Reply-To: <201304050310.39289.sergei.shtylyov@cogentembedded.com>
References: <201304050310.39289.sergei.shtylyov@cogentembedded.com>
Message-ID: <20130405004445.GQ29203@verge.net.au>

On Fri, Apr 05, 2013 at 03:10:38AM +0400, Sergei Shtylyov wrote:
> Since we're now going to setup the USBPCTRL0 register using the USB PHY device's
> platform data, we now need a way to pass those platform data from the board file
> to the device which is situated in setup-r8a7779.c -- and what I'm suggesting is
> r8a7779_add_usb_phy_device() that will register USB PHY platform device with the
> passed platform data using platform_device_register_resndata() call; creating
> this function involves deletion of 'usb_phy_device' from r8a7779_devices_dt[],
> so that it will no longer be registered for the generic R8A7779 machine (where
> we can't provide the platform data anyway), hence EHCI/OHCI drivers will fail
> to load as well.
> 
> For the Marzen board, this new function will be called from marzen_init() to
> register the USB PHY device early enough.

As per my comment regarding patch 1, I wonder if this could
be split into an SoC patch and a board patch.

> 
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
> 
> ---
>  arch/arm/mach-shmobile/board-marzen.c         |    5 +++++
>  arch/arm/mach-shmobile/include/mach/r8a7779.h |    2 ++
>  arch/arm/mach-shmobile/setup-r8a7779.c        |   16 ++++++++--------
>  3 files changed, 15 insertions(+), 8 deletions(-)
> 
> Index: renesas/arch/arm/mach-shmobile/board-marzen.c
> ===================================================================
> --- renesas.orig/arch/arm/mach-shmobile/board-marzen.c
> +++ renesas/arch/arm/mach-shmobile/board-marzen.c
> @@ -56,6 +56,10 @@ static struct regulator_consumer_supply 
>  	REGULATOR_SUPPLY("vdd33a", "smsc911x"),
>  };
>  
> +static struct rcar_phy_platform_data usb_phy_platform_data = {
> +	.usbpctrl0	= 0,
> +};
> +
>  /* SMSC LAN89218 */
>  static struct resource smsc911x_resources[] = {
>  	[0] = {
> @@ -230,6 +234,7 @@ static void __init marzen_init(void)
>  	r8a7779_pinmux_init();
>  
>  	r8a7779_add_standard_devices();
> +	r8a7779_add_usb_phy_device(&usb_phy_platform_data);
>  	platform_add_devices(marzen_devices, ARRAY_SIZE(marzen_devices));
>  }
>  
> Index: renesas/arch/arm/mach-shmobile/include/mach/r8a7779.h
> ===================================================================
> --- renesas.orig/arch/arm/mach-shmobile/include/mach/r8a7779.h
> +++ renesas/arch/arm/mach-shmobile/include/mach/r8a7779.h
> @@ -4,6 +4,7 @@
>  #include <linux/sh_clk.h>
>  #include <linux/pm_domain.h>
>  #include <linux/sh_eth.h>
> +#include <linux/usb/rcar-phy.h>
>  
>  struct platform_device;
>  
> @@ -33,6 +34,7 @@ extern void r8a7779_add_early_devices(vo
>  extern void r8a7779_add_standard_devices(void);
>  extern void r8a7779_add_standard_devices_dt(void);
>  extern void r8a7779_add_ether_device(struct sh_eth_plat_data *pdata);
> +extern void r8a7779_add_usb_phy_device(struct rcar_phy_platform_data *pdata);
>  extern void r8a7779_init_late(void);
>  extern void r8a7779_clock_init(void);
>  extern void r8a7779_pinmux_init(void);
> Index: renesas/arch/arm/mach-shmobile/setup-r8a7779.c
> ===================================================================
> --- renesas.orig/arch/arm/mach-shmobile/setup-r8a7779.c
> +++ renesas/arch/arm/mach-shmobile/setup-r8a7779.c
> @@ -407,13 +407,6 @@ static struct resource usb_phy_resources
>  	},
>  };
>  
> -static struct platform_device usb_phy_device = {
> -	.name		= "rcar_usb_phy",
> -	.id		= -1,
> -	.resource	= usb_phy_resources,
> -	.num_resources	= ARRAY_SIZE(usb_phy_resources),
> -};
> -
>  /* USB */
>  static struct usb_phy *phy;
>  
> @@ -586,7 +579,6 @@ static struct platform_device *r8a7779_d
>  	&scif5_device,
>  	&tmu00_device,
>  	&tmu01_device,
> -	&usb_phy_device,
>  };
>  
>  static struct platform_device *r8a7779_standard_devices[] __initdata = {
> @@ -621,6 +613,14 @@ void __init r8a7779_add_ether_device(str
>  					  pdata, sizeof(*pdata));
>  }
>  
> +void __init r8a7779_add_usb_phy_device(struct rcar_phy_platform_data *pdata)
> +{
> +	platform_device_register_resndata(&platform_bus, "rcar_usb_phy", -1,
> +					  usb_phy_resources,
> +					  ARRAY_SIZE(usb_phy_resources),
> +					  pdata, sizeof(*pdata));
> +}
> +
>  /* do nothing for !CONFIG_SMP or !CONFIG_HAVE_TWD */
>  void __init __weak r8a7779_register_twd(void) { }
>  
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


From horms at verge.net.au  Thu Apr  4 20:49:31 2013
From: horms at verge.net.au (Simon Horman)
Date: Fri, 5 Apr 2013 09:49:31 +0900
Subject: [RFC/PATCH 0/7] ARCH: shmobile: defconfig consolidation
In-Reply-To: <2243996.H0VQ4NfsDe@avalon>
References: <1365046193-19369-1-git-send-email-horms+renesas@verge.net.au>
 <1374328.KVLKlOlad0@avalon> <20130405003027.GB29203@verge.net.au>
 <2243996.H0VQ4NfsDe@avalon>
Message-ID: <20130405004931.GR29203@verge.net.au>

On Fri, Apr 05, 2013 at 02:37:38AM +0200, Laurent Pinchart wrote:
> On Friday 05 April 2013 09:30:27 Simon Horman wrote:
> > On Thu, Apr 04, 2013 at 01:20:44PM +0200, Laurent Pinchart wrote:
> > > On Thursday 04 April 2013 12:29:46 Simon Horman wrote:
> > > > Hi,
> > > > 
> > > > this is a first pass at consolidating the defconfigs of shmobile.
> > > > 
> > > > It covers the mackerel, amradillo800eva and kzm9d boards which meet
> > > > the following criteria:
> > > > 
> > > > * Have the same base memory address (0x40000000).
> > > 
> > > Do you know if there's any work being done on getting rid of the base
> > > memory address as a kernel config option ? It seriously hinders cross-SoC
> > > kernel testing.
> > 
> > As I understand things the main limitation is uImage which uses
> > the base memory address. There is some talk of creating uImages
> > at install time rather than build time. Which I believe would
> > remove most if not all the problem. However, its entirely unclear
> > to me what such an install process would look like. A new build target?
> > In tree script? Out of tree script? It seems very undefined to me.
> > 
> > Another, arguably better though not backwards compatible, option
> > is to boot using zImage (or even just Image) which do not rely
> > on the base address.
> 
> Don't we also need to get rid of CONFIG_MEMORY_START ? It's used in headsmp.S 
> and headsmp-scu.S (through PLAT_PHYS_OFFSET).

Yes, I think so. Sorry for glossing over that.

I think it should be possible to remove that by evaluating it at runtime
somehow. But I have not though deeply about this.

> > I'm not aware of any other work or discussion in this area although
> > it would not surprise me if there was some.
> >
> > > > * Work with RUNTIME_PM, it is desirable to have that a common defconfig
> > > > * Are booted via DT, enabling the command line to be supplied in the
> > > > dts.
> > > > 
> > > >   This is important to allow serial console and early printk settings,
> > > >   which vary wildly between boards, to be supplied.
> > > > 
> > > > * Boards I have to test.
> > > > 
> > > >   This didn't eliminate any candidates that met the above criteria.
> > > > 
> > > > I believe it should also be possible to add support for the APE6EVM
> > > > board to the consolidated defconfig once problems with RUNTIME_PM
> > > > have been isolated and resolved. I have send an email about this
> > > > in a separate thread "APE6EVM and Runtime PM".
> > > > 
> > > > I believe it may be possible to add support for the lager board
> > > > to the consolidated defconfig once I am able to bring that board up,
> > > > which should be rather soon. The lager board does not currently
> > > > have a defconfig.
> > > > 
> > > > Morimoto-san, I suspect it may be possible to add support for the
> > > > bockw board to the consolidated defconfig if its boot loader supports
> > > > booting using a zImage. In this case even though the base memory address
> > > > is not the same as the boards above it should be possible to specify
> > > > the base address from the boot loader. As I do not have a bockw board
> > > > I am wondering if you could investigate this.
> > > > 
> > > > Simon Horman (7):
> > > >   ARM: shmobile: prune defconfig
> > > >   ARM: shmobile: make defconfig canonical
> > > >   ARM: shmobile: Add kzm9d to consolidated defconfig
> > > >   ARM: shmobile: Add mackerel to consolidated defconfig
> > > >   ARM: shmobile: defconfig: Remove armadillo800eva defconfig
> > > >   ARM: shmobile: defconfig: Remove kzm9d defconfig
> > > >   ARM: shmobile: defconfig: Remove mackerel defconfig
> > > >  
> > > >  arch/arm/configs/armadillo800eva_defconfig |  153 ---------------------
> > > >  arch/arm/configs/kzm9d_defconfig           |   88 ----------------
> > > >  arch/arm/configs/mackerel_defconfig        |  156 ---------------------
> > > >  arch/arm/configs/shmobile_defconfig        |   51 +++++----
> > > >  4 files changed, 28 insertions(+), 420 deletions(-)
> > > >  delete mode 100644 arch/arm/configs/armadillo800eva_defconfig
> > > >  delete mode 100644 arch/arm/configs/kzm9d_defconfig
> > > >  delete mode 100644 arch/arm/configs/mackerel_defconfig


From swarren at wwwdotorg.org  Thu Apr  4 21:01:11 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Thu, 04 Apr 2013 19:01:11 -0600
Subject: [PATCH V2 1/7] kbuild: create an "include chroot" for DT bindings
In-Reply-To: <515E09FA.1090408@gmail.com>
References: <1365032098-22825-1-git-send-email-swarren@wwwdotorg.org>
 <515E09FA.1090408@gmail.com>
Message-ID: <515E2257.4030607@wwwdotorg.org>

On 04/04/2013 05:17 PM, Rob Herring wrote:
> On 04/03/2013 06:34 PM, Stephen Warren wrote:
>> From: Stephen Warren <swarren at nvidia.com>
>>
>> The recent dtc+cpp support allows header files and C pre-processor
>> defines/macros to be used when compiling device tree files. These
>> headers will typically define various constants that are part of the
>> device tree bindings.
>>
>> The original patch which set up the dtc+cpp include path only considered
>> using those headers from device tree files. However, most are also
>> useful for kernel code which needs to interpret the device tree.
>>
>> In both the DT files and the kernel, I'd like to include the DT-related
>> headers in the same way, for example, <dt-bindings/gpio/tegra-gpio.h>.
>> That will simplify any text which discusses the DT header locations.
>>
>> Creating a <dt-bindings/> for kernel source to use is as simple as
>> placing files into include/dt-bindings/.
>>
>> However, when compiling DT files, the include path should be restricted
>> so that only the dt-bindings path is available; arbitrary kernel headers
>> shouldn't be exposed. For this reason, create a specific include
>> directory for use by dtc+cpp, and symlink dt-bindings from there to the
>> actual location of include/dt-bindings/. For want of a better location,
>> place this "include chroot" into the existing dts/ directory.
>>
>> arch/*/boot/dts/include/dt-bindings -> ../../../../../include/dt-bindings
>>
>> Some headers used by device tree files may not be useful to the kernel;
>> they may be used simply to aid in constructing the DT file (e.g. macros
>> to create a node), but not define any information that the kernel needs
>> to share. These may be placed directly into arch/*/boot/dts/ along with
>> the DT files themselves.
>>
>> Cc: Shawn Guo <shawn.guo at linaro.org>
>> Cc: Hiroshi Doyu <hdoyu at nvidia.com>
>> Acked-by: Michal Marek <mmarek at suse.cz>
>> Acked-by: Shawn Guo <shawn.guo at linaro.org>
>> Acked-by: Rob Herring <rob.herring at calxeda.com>
>> Signed-off-by: Stephen Warren <swarren at nvidia.com>
>> ---
>> Grant, Rob, Michal, I'm hoping for acks or comments from you so this
>> series can be placed into a topic branch in the arm-soc repo, for others
>> to build on during the 3.10 kernel cycle. Thanks.
> 
> Well, you have mine here and the rest looks fine, so add it to the others.

Rob,

I had originally hoped for this to go into an arm-soc branch so that a
number of SoCs could convert to use the feature in the same release,
hence I was looking for acks to let that happen.

However, it's too late in the 3.10 cycle now for that to happen. Can the
series be applied to the DT tree instead; people can convert during the
3.11 cycle.


From jason at lakedaemon.net  Thu Apr  4 21:11:43 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Thu, 4 Apr 2013 21:11:43 -0400
Subject: [PATCH] ARM: kirkwood: DT board setup for CloudBox
In-Reply-To: <20130404093435.GK16404@kw.sim.vm.gnt>
References: <20130329184109.GA16404@kw.sim.vm.gnt> <51568B89.1060009@free.fr>
 <20130401163316.GC16404@kw.sim.vm.gnt> <515A5BC6.5000007@free.fr>
 <20130402114535.GR13280@titan.lakedaemon.net>
 <20130402125408.GH16404@kw.sim.vm.gnt>
 <20130402172454.GT13280@titan.lakedaemon.net>
 <515D0776.7050208@free.fr> <20130404080058.GJ16404@kw.sim.vm.gnt>
 <20130404093435.GK16404@kw.sim.vm.gnt>
Message-ID: <20130405011143.GX13280@titan.lakedaemon.net>

On Thu, Apr 04, 2013 at 11:34:35AM +0200, Simon Guinot wrote:
> On Thu, Apr 04, 2013 at 10:00:58AM +0200, Simon Guinot wrote:
> > On Thu, Apr 04, 2013 at 06:54:14AM +0200, Chris Moore wrote:
> > > Le 02/04/2013 19:24, Jason Cooper a ?crit :
> > > >On Tue, Apr 02, 2013 at 02:54:11PM +0200, Simon Guinot wrote:
...
> > > >As for the model number for the public board (#2), why can't we append
> > > >"-90003xx"?  See [1], Specifications tab.
> > > >
> > > >[1] http://www.lacie.com/us/products/product.htm?id=10597
> > > 
> > > This seems like a good idea to me but I don't think Simon favoured
> > > adding a model number.
> > > In any case Simon would know better than me whether this covers the
> > > models correctly.
> > > What do you think, Simon?
> > 
> > I am currently working on this numbers. It _could_ work. Apparently the
> > product ID is encoded in the numbers... as well as the case color and
> > size. Today I should meet someone with more informations about the model
> > number format.
> 
> Finally, the model number pattern "-90003xx" can't be used to match the
> CloudBox product. The number is indeed unique. It encodes product ID,
> storage capacity, case color and case size. But the pattern is not
> usable. If tomorrow a red CloudBox is released, the first digits could
> be completely different.
> 
> To illustrate that, have a look at:
> http://www.lacie.com/products/product.htm?id=10584.
> 
> The item numbers are 2000345, 9000225 and 9000226.

Thank for digging into this.

> Then we are back to the initial problem...
> 
> Maybe we could append some suffixes based on the version:
> 
> 1: cloudbox-v1
> 2: cloudbox-v2
> 
> Or better, suffix based on the other code names:
> 
> 1: cloudbox-ns2mini
> 2: cloudbox-familybox
> 
> Or even let the things as they are:
> 
> 1: netspace_v2_mini
> 2: cloudbox

In light of the above info, let's got with the third option.  If we
discover a different LaCie Cloudbox board down the road, we can add an
appropriately more specific compatible string to differentiate.  As you
can tell, I'd prefer to have something more specific in the original
commit, but we can only work with what we're given. :(

thx,

Jason.


From kuninori.morimoto.gx at renesas.com  Thu Apr  4 21:21:14 2013
From: kuninori.morimoto.gx at renesas.com (Kuninori Morimoto)
Date: Fri, 05 Apr 2013 10:21:14 +0900
Subject: [PATCH v2 1/2] ARM: shmobile: R8A7779: add Ether support
In-Reply-To: <201304042253.50662.sergei.shtylyov@cogentembedded.com>
References: <201304042253.50662.sergei.shtylyov@cogentembedded.com>
Message-ID: <87y5cxkc1h.wl%kuninori.morimoto.gx@renesas.com>


Hi

> Add Ether clock and platform device for R8A7779 SoC; add a function to register
> this device with board-specific platform data.
> 
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
> 
> ---

Acked-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>


> This patch is atop of the 'renesas-next-20130404v2' tag of Simon Horman's
> 'renesas.git'.
> 
> Changes since original posting:
> - use 'struct sh_eth_plat_data *' as an argument to r8a7779_add_ether_device();
> - use platform_device_register_resndata() in r8a7779_add_ether_device().
> 
>  arch/arm/mach-shmobile/clock-r8a7779.c        |    4 +++-
>  arch/arm/mach-shmobile/include/mach/r8a7779.h |    2 ++
>  arch/arm/mach-shmobile/setup-r8a7779.c        |   23 ++++++++++++++++++++++-
>  3 files changed, 27 insertions(+), 2 deletions(-)
> 
> Index: renesas/arch/arm/mach-shmobile/clock-r8a7779.c
> ===================================================================
> --- renesas.orig/arch/arm/mach-shmobile/clock-r8a7779.c
> +++ renesas/arch/arm/mach-shmobile/clock-r8a7779.c
> @@ -112,7 +112,7 @@ static struct clk *main_clks[] = {
>  };
>  
>  enum { MSTP323, MSTP322, MSTP321, MSTP320,
> -	MSTP115,
> +	MSTP115, MSTP114,
>  	MSTP103, MSTP101, MSTP100,
>  	MSTP030,
>  	MSTP029, MSTP028, MSTP027, MSTP026, MSTP025, MSTP024, MSTP023, MSTP022, MSTP021,
> @@ -126,6 +126,7 @@ static struct clk mstp_clks[MSTP_NR] = {
>  	[MSTP321] = SH_CLK_MSTP32(&clkp_clk, MSTPCR3, 21, 0), /* SDHI2 */
>  	[MSTP320] = SH_CLK_MSTP32(&clkp_clk, MSTPCR3, 20, 0), /* SDHI3 */
>  	[MSTP115] = SH_CLK_MSTP32(&clkp_clk, MSTPCR1, 15, 0), /* SATA */
> +	[MSTP114] = SH_CLK_MSTP32(&clkp_clk, MSTPCR1, 14, 0), /* Ether */
>  	[MSTP103] = SH_CLK_MSTP32(&clks_clk, MSTPCR1,  3, 0), /* DU */
>  	[MSTP101] = SH_CLK_MSTP32(&clkp_clk, MSTPCR1,  1, 0), /* USB2 */
>  	[MSTP100] = SH_CLK_MSTP32(&clkp_clk, MSTPCR1,  0, 0), /* USB0/1 */
> @@ -162,6 +163,7 @@ static struct clk_lookup lookups[] = {
>  	/* MSTP32 clocks */
>  	CLKDEV_DEV_ID("sata_rcar", &mstp_clks[MSTP115]), /* SATA */
>  	CLKDEV_DEV_ID("fc600000.sata", &mstp_clks[MSTP115]), /* SATA w/DT */
> +	CLKDEV_DEV_ID("sh-eth", &mstp_clks[MSTP114]), /* Ether */
>  	CLKDEV_DEV_ID("ehci-platform.1", &mstp_clks[MSTP101]), /* USB EHCI port2 */
>  	CLKDEV_DEV_ID("ohci-platform.1", &mstp_clks[MSTP101]), /* USB OHCI port2 */
>  	CLKDEV_DEV_ID("ehci-platform.0", &mstp_clks[MSTP100]), /* USB EHCI port0/1 */
> Index: renesas/arch/arm/mach-shmobile/include/mach/r8a7779.h
> ===================================================================
> --- renesas.orig/arch/arm/mach-shmobile/include/mach/r8a7779.h
> +++ renesas/arch/arm/mach-shmobile/include/mach/r8a7779.h
> @@ -3,6 +3,7 @@
>  
>  #include <linux/sh_clk.h>
>  #include <linux/pm_domain.h>
> +#include <linux/sh_eth.h>
>  
>  struct platform_device;
>  
> @@ -31,6 +32,7 @@ extern void r8a7779_earlytimer_init(void
>  extern void r8a7779_add_early_devices(void);
>  extern void r8a7779_add_standard_devices(void);
>  extern void r8a7779_add_standard_devices_dt(void);
> +extern void r8a7779_add_ether_device(struct sh_eth_plat_data *pdata);
>  extern void r8a7779_clock_init(void);
>  extern void r8a7779_pinmux_init(void);
>  extern void r8a7779_pm_init(void);
> Index: renesas/arch/arm/mach-shmobile/setup-r8a7779.c
> ===================================================================
> --- renesas.orig/arch/arm/mach-shmobile/setup-r8a7779.c
> +++ renesas/arch/arm/mach-shmobile/setup-r8a7779.c
> @@ -1,8 +1,9 @@
>  /*
>   * r8a7779 processor support
>   *
> - * Copyright (C) 2011  Renesas Solutions Corp.
> + * Copyright (C) 2011, 2013  Renesas Solutions Corp.
>   * Copyright (C) 2011  Magnus Damm
> + * Copyright (C) 2013  Cogent Embedded, Inc.
>   *
>   * 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
> @@ -393,6 +394,18 @@ static struct platform_device sata_devic
>  	},
>  };
>  
> +/* Ether */
> +static struct resource ether_resources[] = {
> +	{
> +		.start	= 0xfde00000,
> +		.end	= 0xfde003ff,
> +		.flags	= IORESOURCE_MEM,
> +	}, {
> +		.start	= gic_iid(0xb4),
> +		.flags	= IORESOURCE_IRQ,
> +	},
> +};
> +
>  static struct platform_device *r8a7779_devices_dt[] __initdata = {
>  	&scif0_device,
>  	&scif1_device,
> @@ -428,6 +441,14 @@ void __init r8a7779_add_standard_devices
>  			    ARRAY_SIZE(r8a7779_late_devices));
>  }
>  
> +void __init r8a7779_add_ether_device(struct sh_eth_plat_data *pdata)
> +{
> +	platform_device_register_resndata(&platform_bus, "sh_eth", -1,
> +					  ether_resources,
> +					  ARRAY_SIZE(ether_resources),
> +					  pdata, sizeof(*pdata));
> +}
> +
>  /* do nothing for !CONFIG_SMP or !CONFIG_HAVE_TWD */
>  void __init __weak r8a7779_register_twd(void) { }
>  
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


From kuninori.morimoto.gx at renesas.com  Thu Apr  4 21:22:19 2013
From: kuninori.morimoto.gx at renesas.com (Kuninori Morimoto)
Date: Thu, 04 Apr 2013 18:22:19 -0700 (PDT)
Subject: [PATCH v2 2/2] ARM: shmobile: R8A7778: add Ether support
In-Reply-To: <201304042255.46986.sergei.shtylyov@cogentembedded.com>
References: <201304042255.46986.sergei.shtylyov@cogentembedded.com>
Message-ID: <87wqshkbzr.wl%kuninori.morimoto.gx@renesas.com>


Hi

> Add Ether clock and platform device for R8A7778 SoC; add a function to register
> this device with board-specific platform data.
> 
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
> 
> ---

Acked-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>

> This patch is atop of the 'renesas-next-20130404v2' tag of Simon Horman's
> 'renesas.git'.
> 
> Changes since original posting:
> - use 'struct sh_eth_plat_data *' as an argument to r8a7778_add_ether_device();
> - use platform_device_register_resndata() in r8a7778_add_ether_device().
> 
>  arch/arm/mach-shmobile/clock-r8a7778.c        |    3 +++
>  arch/arm/mach-shmobile/include/mach/r8a7778.h |    3 +++
>  arch/arm/mach-shmobile/setup-r8a7778.c        |   15 +++++++++++++++
>  3 files changed, 21 insertions(+)
> 
> Index: renesas/arch/arm/mach-shmobile/clock-r8a7778.c
> ===================================================================
> --- renesas.orig/arch/arm/mach-shmobile/clock-r8a7778.c
> +++ renesas/arch/arm/mach-shmobile/clock-r8a7778.c
> @@ -58,11 +58,13 @@ static struct clk *main_clks[] = {
>  };
>  
>  enum {
> +	MSTP114,
>  	MSTP026, MSTP025, MSTP024, MSTP023, MSTP022, MSTP021,
>  	MSTP016, MSTP015,
>  	MSTP_NR };
>  
>  static struct clk mstp_clks[MSTP_NR] = {
> +	[MSTP114] = SH_CLK_MSTP32(&clkp, MSTPCR1, 14, 0), /* Ether */
>  	[MSTP026] = SH_CLK_MSTP32(&clkp, MSTPCR0, 26, 0), /* SCIF0 */
>  	[MSTP025] = SH_CLK_MSTP32(&clkp, MSTPCR0, 25, 0), /* SCIF1 */
>  	[MSTP024] = SH_CLK_MSTP32(&clkp, MSTPCR0, 24, 0), /* SCIF2 */
> @@ -75,6 +77,7 @@ static struct clk mstp_clks[MSTP_NR] = {
>  
>  static struct clk_lookup lookups[] = {
>  	/* MSTP32 clocks */
> +	CLKDEV_DEV_ID("sh-eth",	&mstp_clks[MSTP114]), /* Ether */
>  	CLKDEV_DEV_ID("sh-sci.0", &mstp_clks[MSTP026]), /* SCIF0 */
>  	CLKDEV_DEV_ID("sh-sci.1", &mstp_clks[MSTP025]), /* SCIF1 */
>  	CLKDEV_DEV_ID("sh-sci.2", &mstp_clks[MSTP024]), /* SCIF2 */
> Index: renesas/arch/arm/mach-shmobile/include/mach/r8a7778.h
> ===================================================================
> --- renesas.orig/arch/arm/mach-shmobile/include/mach/r8a7778.h
> +++ renesas/arch/arm/mach-shmobile/include/mach/r8a7778.h
> @@ -18,8 +18,11 @@
>  #ifndef __ASM_R8A7778_H__
>  #define __ASM_R8A7778_H__
>  
> +#include <linux/sh_eth.h>
> +
>  extern void r8a7778_add_standard_devices(void);
>  extern void r8a7778_add_standard_devices_dt(void);
> +extern void r8a7778_add_ether_device(struct sh_eth_plat_data *pdata);
>  extern void r8a7778_init_delay(void);
>  extern void r8a7778_init_irq(void);
>  extern void r8a7778_init_irq_dt(void);
> Index: renesas/arch/arm/mach-shmobile/setup-r8a7778.c
> ===================================================================
> --- renesas.orig/arch/arm/mach-shmobile/setup-r8a7778.c
> +++ renesas/arch/arm/mach-shmobile/setup-r8a7778.c
> @@ -3,6 +3,7 @@
>   *
>   * Copyright (C) 2013  Renesas Solutions Corp.
>   * Copyright (C) 2013  Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
> + * Copyright (C) 2013  Cogent Embedded, Inc.
>   *
>   * 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
> @@ -79,6 +80,12 @@ static struct sh_timer_config sh_tmu1_pl
>  	.clocksource_rating	= 200,
>  };
>  
> +/* Ether */
> +static struct resource ether_resources[] = {
> +	DEFINE_RES_MEM(0xfde00000, 0x400),
> +	DEFINE_RES_IRQ(gic_iid(0x89)),
> +};
> +
>  #define r8a7778_register_tmu(idx)			\
>  	platform_device_register_resndata(		\
>  		&platform_bus, "sh_tmu", idx,		\
> @@ -111,6 +118,14 @@ void __init r8a7778_add_standard_devices
>  	r8a7778_register_tmu(1);
>  }
>  
> +void __init r8a7778_add_ether_device(struct sh_eth_plat_data *pdata)
> +{
> +	platform_device_register_resndata(&platform_bus, "sh_eth", -1,
> +					  ether_resources,
> +					  ARRAY_SIZE(ether_resources),
> +					  pdata, sizeof(*pdata));
> +}
> +
>  static struct renesas_intc_irqpin_config irqpin_platform_data = {
>  	.irq_base = irq_pin(0), /* IRQ0 -> IRQ3 */
>  	.sense_bitfield_width = 2,
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


From swarren at wwwdotorg.org  Thu Apr  4 21:28:56 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Thu,  4 Apr 2013 19:28:56 -0600
Subject: [GIT PULL 1/3] ARM: bcm2835: device tree updates
Message-ID: <1365125338-6668-1-git-send-email-swarren@wwwdotorg.org>

This branch adds two devices to the BCM2835 SoC device tree: the SPI
controller and the HW random number generator.

The SPI controller isn't actually instantiated in the Raspberry Pi
device tree, since there are no on-board SPI devices; it's up to the
end-user to modify their own device-tree to describe whatever they
have attached.

----------------------------------------------------------------

The following changes since commit f6161aa153581da4a3867a2d1a7caf4be19b6ec9:

  Linux 3.9-rc2

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-rpi.git bcm2835-for-3.10-dt

for you to fetch changes up to a1bf70828ea0547b4e3d7eaeb63ae3eb2400cb93:

  ARM: bcm2835: add Broadcom BCM2835 RNG to the device tree

----------------------------------------------------------------

Lubomir Rintel (1):
      ARM: bcm2835: add Broadcom BCM2835 RNG to the device tree

Stephen Warren (1):
      ARM: bcm2835: add SPI device to DT

 arch/arm/boot/dts/bcm2835.dtsi |   22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)


From swarren at wwwdotorg.org  Thu Apr  4 21:28:57 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Thu,  4 Apr 2013 19:28:57 -0600
Subject: [GIT PULL 2/3] ARM: bcm2835: convert to multi-platform
In-Reply-To: <1365125338-6668-1-git-send-email-swarren@wwwdotorg.org>
References: <1365125338-6668-1-git-send-email-swarren@wwwdotorg.org>
Message-ID: <1365125338-6668-2-git-send-email-swarren@wwwdotorg.org>

This branch (patch) converts BCM2835 to support being built into a
multi-platform single zImage. This mostly entails a few small Kconfig
tweaks, move the earlyprintk implementation to the standard multi-
platform location, and deleting some unnecessary files.

----------------------------------------------------------------

The following changes since commit f6161aa153581da4a3867a2d1a7caf4be19b6ec9:

  Linux 3.9-rc2

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-rpi.git bcm2835-for-3.10-multiplatform

for you to fetch changes up to f1ac922dec7ed36659344eadc65b9c06efe14d7f:

  ARM: bcm2835: convert to multi-platform

----------------------------------------------------------------

Stephen Warren (1):
      ARM: bcm2835: convert to multi-platform

 arch/arm/Kconfig                                |   22 +--------
 arch/arm/Kconfig.debug                          |    5 ++
 arch/arm/configs/bcm2835_defconfig              |    2 +
 .../debug-macro.S => include/debug/bcm2835.S}   |    3 +-
 arch/arm/mach-bcm2835/Kconfig                   |   15 ++++++
 arch/arm/mach-bcm2835/Makefile.boot             |    1 -
 arch/arm/mach-bcm2835/bcm2835.c                 |    6 ++-
 .../arm/mach-bcm2835/include/mach/bcm2835_soc.h |   29 ------------
 arch/arm/mach-bcm2835/include/mach/gpio.h       |    1 -
 arch/arm/mach-bcm2835/include/mach/timex.h      |   26 -----------
 arch/arm/mach-bcm2835/include/mach/uncompress.h |   44 ------------------
 11 files changed, 30 insertions(+), 124 deletions(-)
 rename arch/arm/{mach-bcm2835/include/mach/debug-macro.S => include/debug/bcm2835.S} (86%)
 create mode 100644 arch/arm/mach-bcm2835/Kconfig
 delete mode 100644 arch/arm/mach-bcm2835/Makefile.boot
 delete mode 100644 arch/arm/mach-bcm2835/include/mach/bcm2835_soc.h
 delete mode 100644 arch/arm/mach-bcm2835/include/mach/gpio.h
 delete mode 100644 arch/arm/mach-bcm2835/include/mach/timex.h
 delete mode 100644 arch/arm/mach-bcm2835/include/mach/uncompress.h


From swarren at wwwdotorg.org  Thu Apr  4 21:28:58 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Thu,  4 Apr 2013 19:28:58 -0600
Subject: [GIT PULL 3/3] ARM: bcm2835: defconfig updates
In-Reply-To: <1365125338-6668-1-git-send-email-swarren@wwwdotorg.org>
References: <1365125338-6668-1-git-send-email-swarren@wwwdotorg.org>
Message-ID: <1365125338-6668-3-git-send-email-swarren@wwwdotorg.org>

This branch (patch) updates bcm2835_defconfig to enable new features that
were added this kernel cycle. Namely, the SPI controller and HW random
number generator.

----------------------------------------------------------------

The following changes since commit f6161aa153581da4a3867a2d1a7caf4be19b6ec9:

  Linux 3.9-rc2

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-rpi.git bcm2835-for-3.10-defconfig

for you to fetch changes up to d8d6aec6d560fb66a25aad567f0630baee6785a1:

  ARM: bcm2835: defconfig updates

----------------------------------------------------------------

Stephen Warren (1):
      ARM: bcm2835: defconfig updates

 arch/arm/configs/bcm2835_defconfig |    9 ++++-----
 1 file changed, 4 insertions(+), 5 deletions(-)


From festevam at gmail.com  Thu Apr  4 21:29:25 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Thu, 4 Apr 2013 22:29:25 -0300
Subject: [PATCH] ARM: dts: imx28-evk: Fix the ethernet regulator name
In-Reply-To: <1365098729-21933-1-git-send-email-fabio.estevam@freescale.com>
References: <1365098729-21933-1-git-send-email-fabio.estevam@freescale.com>
Message-ID: <CAOMZO5AxTO1t8_Q5K46z_X=_ezEGKYoYfrBeGt5YDTj3CDHO5A@mail.gmail.com>

On Thu, Apr 4, 2013 at 3:05 PM, Fabio Estevam
<fabio.estevam at freescale.com> wrote:
> FEC driver looks for "phy" as the regulator-name:
>
> reg_phy = devm_regulator_get(&pdev->dev, "phy");
>
> So adjust it properly.

Please discard this one. Current code is correct.


From horms+renesas at verge.net.au  Thu Apr  4 21:39:20 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri,  5 Apr 2013 10:39:20 +0900
Subject: [PATCH] ARM: shmobile: marzen-reference: use irqpin for lan
Message-ID: <1365125960-25753-1-git-send-email-horms+renesas@verge.net.au>

This corrects the configuration of the SMSC lan controller
to use the newly added irqpin as its IRQ source.

Previously the lan controller did not work. Now it does.

Cc: Guennadi Liakhovetski <g.liakhovetski+renesas at gmail.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>

---

This depends on "[PATCH/RFC 0/2] ARM: shmobile: DT irqpin for r8a7779 and
marzen-reference".
---
 arch/arm/boot/dts/r8a7779-marzen-reference.dts |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7779-marzen-reference.dts b/arch/arm/boot/dts/r8a7779-marzen-reference.dts
index 72be4c8..6d9e4d0 100644
--- a/arch/arm/boot/dts/r8a7779-marzen-reference.dts
+++ b/arch/arm/boot/dts/r8a7779-marzen-reference.dts
@@ -38,8 +38,8 @@
 		compatible = "smsc,lan9220", "smsc,lan9115";
 		reg = <0x18000000 0x100>;
 		phy-mode = "mii";
-		interrupt-parent = <&gic>;
-		interrupts = <0 28 0x4>;
+		interrupt-parent = <&irqpin0>;
+		interrupts = <1 0>;
 		reg-io-width = <4>;
 		vddvario-supply = <&fixedregulator3v3>;
 		vdd33a-supply = <&fixedregulator3v3>;
-- 
1.7.10.4



From horms at verge.net.au  Thu Apr  4 21:44:29 2013
From: horms at verge.net.au (Simon Horman)
Date: Fri, 5 Apr 2013 10:44:29 +0900
Subject: [PATCH/RFC 0/2] ARM: shmobile: DT irqpin for r8a7779 and
 marzen-reference
In-Reply-To: <Pine.LNX.4.64.1304042325140.21548@axis700.grange>
References: <Pine.LNX.4.64.1304031103590.10531@axis700.grange>
 <20130404035426.GC28297@verge.net.au>
 <Pine.LNX.4.64.1304042325140.21548@axis700.grange>
Message-ID: <20130405014429.GV29203@verge.net.au>

On Thu, Apr 04, 2013 at 11:47:05PM +0200, Guennadi Liakhovetski wrote:
> Hi Simon
> 
> On Thu, 4 Apr 2013, Simon Horman wrote:
> 
> > On Wed, Apr 03, 2013 at 11:18:57AM +0200, Guennadi Liakhovetski wrote:
> > > Hi
> > > 
> > > This 2 patches add DT irqpin support on marzen-reference. Only 
> > > compile-tested due to the lack of hardware. The patches can go 
> > > independently via their respective trees. irqpin on marzen will not work 
> > > if patch 2 is applied before patch 1, but as long as there are no devices, 
> > > using irqpin interrupts, no breakage will be caused.
> > 
> > I have applied both patches and the dependency I mention below.
> > I have also applied the small patch, inlined below, to hook-up
> > the LAN controller. Unfortunately it doesn't seem to be receiving
> > any interrupts. Perhaps I am missing something?
> 
> Are you sure 28 is the correct number in the irqpin IRQ space? Seems 
> strange to me. Should be 1 perhaps (counting from 0), or 2 - not sure how 
> that mapping would look like.

Thanks!

0 seems to be the lucky number, I have SMSC (and NFS root) working
on marzen-reference.

I have posted "ARM: shmobile: marzen-reference: use irqpin for lan"

> > > Guennadi Liakhovetski (2):
> > >       irqchip: renesas-intc-irqpin: DT binding for sense bitfield width
> > 
> > The above patch depends on "[1/3] ARM: shmobile: irqpin: fix handling of
> > spurious interrupts in DT case", right?
> 
> Not functionally. Spurious interrupts occur on sh73a0, the sense bitfield 
> is needed for r8a7779. But the latter won't apply without the former, 
> that's right.

Thanks, could you reposts this series rebase so that it doesn't require
""[1/3] ARM: shmobile: irqpin: fix handling of spurious interrupts in DT case"
to apply cleanly.

Feel free to break the creation of
Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.txt
into a separate patch.

Please add "ARM: shmobile: marzen-reference: use irqpin for lan" to
the end of the series with an Ack if you have no objections to it.

> > Has there been any progress in your
> > discussions with Magnus about what to do about that patch?
> 
> No, not yet.

Thanks, understood.

And thanks doubly for this series.
It is very nice to have bouth irqpin and ethernet working on
marzen-reference.


From sboyd at codeaurora.org  Thu Apr  4 21:46:25 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Thu, 04 Apr 2013 18:46:25 -0700
Subject: [PATCHv3 01/10] clocksource: add generic dummy timer driver
In-Reply-To: <20130326112811.GD4065@e106331-lin.cambridge.arm.com>
References: <1363198676-30417-1-git-send-email-sboyd@codeaurora.org>
 <1363198676-30417-2-git-send-email-sboyd@codeaurora.org>
 <20130321180922.GB10716@e106331-lin.cambridge.arm.com>
 <514B4DBD.4060403@codeaurora.org>
 <20130322180305.GB1436@e106331-lin.cambridge.arm.com>
 <5150800E.2000905@codeaurora.org>
 <20130325180007.GA4065@e106331-lin.cambridge.arm.com>
 <5151049D.5040400@codeaurora.org>
 <20130326112811.GD4065@e106331-lin.cambridge.arm.com>
Message-ID: <515E2CF1.6030709@codeaurora.org>

On 03/26/13 04:28, Mark Rutland wrote:
> On Tue, Mar 26, 2013 at 02:14:53AM +0000, Stephen Boyd wrote:
>> Ok. Thanks for clearing up my confusion.
>>
>> Like you say, increasing the dummy timer rating seems like a hack. But
>> it also sounds like you want to keep the dummy timer driver fully self
>> contained. I'm not opposed to calling dummy_timer_register() at the
>> bottom of tick_init() if we have to, but it sounds like you don't like that.
> I'd like to keep the dummy timer driver self-contained if we can, but if it
> makes it more robust and/or easier to deal with by having an external call to
> register the driver, then I'm not opposed to that.
>
>> An alternative would be to push the dummy timer logic into the core
>> clockevents layer under the ifdef for arch has broadcast. This is
>> probably the correct approach because most devices don't want to have a
>> dummy timer sitting around unused. I might be able to take a look at
>> this tomorrow.
> I'm also not opposed to this idea.

What if we only check the rating if the two devices are for the same
CPU, i.e. always prefer percpu devices over global ones? This would make
your dummy timers into tick devices.

diff --git a/kernel/time/tick-common.c b/kernel/time/tick-common.c
index b1600a6..9ea59b9 100644
--- a/kernel/time/tick-common.c
+++ b/kernel/time/tick-common.c
@@ -251,9 +251,10 @@ static int tick_check_new_device(struct clock_event_device *newdev)
                    !(newdev->features & CLOCK_EVT_FEAT_ONESHOT))
                        goto out_bc;
                /*
-                * Check the rating
+                * Check the rating, but prefer CPU local devices
                 */
-               if (curdev->rating >= newdev->rating)
+               if (curdev->rating >= newdev->rating &&
+                   cpumask_equal(curdev->cpumask, newdev->cpumask))
                        goto out_bc;
        }
 

I think it will work with smp_twd, sp804, and dummy timers registered in
any order too.

> Though "broadcasting" to the same cpu is special-cased in tick_do_broadcast,
> which will call the tick device's event_handler directly rather than having the
> cpu attempt to IPI to itself.
>
> As you suggest, tick_switch_to_oneshot does complain:
>
> Clockevents: could not switch to one-shot mode: dummy_timer is not functional.
> Could not switch to high resolution mode on CPU 0
>
> To handle this case we could check cpu_possible_mask when initialising the
> dummy and only register it if more than 1 cpu is possible. That would be
> roughly in line with how we handle this case in smp.c.

Yes, this will work well enough. Squashed it into this patch.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation



From horms at verge.net.au  Thu Apr  4 21:47:51 2013
From: horms at verge.net.au (Simon Horman)
Date: Fri, 5 Apr 2013 10:47:51 +0900
Subject: [PATCH v2 1/2] ARM: shmobile: R8A7779: add Ether support
In-Reply-To: <87y5cxkc1h.wl%kuninori.morimoto.gx@renesas.com>
References: <201304042253.50662.sergei.shtylyov@cogentembedded.com>
 <87y5cxkc1h.wl%kuninori.morimoto.gx@renesas.com>
Message-ID: <20130405014749.GW29203@verge.net.au>

On Fri, Apr 05, 2013 at 10:21:14AM +0900, Kuninori Morimoto wrote:
> 
> Hi
> 
> > Add Ether clock and platform device for R8A7779 SoC; add a function to register
> > this device with board-specific platform data.
> > 
> > Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
> > 
> > ---
> 
> Acked-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>

Thanks, queued-up in the soc-r8a7779 branch.


From horms at verge.net.au  Thu Apr  4 21:55:36 2013
From: horms at verge.net.au (Simon Horman)
Date: Fri, 5 Apr 2013 10:55:36 +0900
Subject: [PATCH v2 2/2] ARM: shmobile: R8A7778: add Ether support
In-Reply-To: <87wqshkbzr.wl%kuninori.morimoto.gx@renesas.com>
References: <201304042255.46986.sergei.shtylyov@cogentembedded.com>
 <87wqshkbzr.wl%kuninori.morimoto.gx@renesas.com>
Message-ID: <20130405015535.GX29203@verge.net.au>

On Thu, Apr 04, 2013 at 06:22:19PM -0700, Kuninori Morimoto wrote:
> 
> Hi
> 
> > Add Ether clock and platform device for R8A7778 SoC; add a function to register
> > this device with board-specific platform data.
> > 
> > Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
> > 
> > ---
> 
> Acked-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
> 
> > This patch is atop of the 'renesas-next-20130404v2' tag of Simon Horman's
> > 'renesas.git'.
> > 
> > Changes since original posting:
> > - use 'struct sh_eth_plat_data *' as an argument to r8a7778_add_ether_device();
> > - use platform_device_register_resndata() in r8a7778_add_ether_device().

Thanks, queued-up in the soc-r8a7778 branch.


From kuninori.morimoto.gx at renesas.com  Thu Apr  4 22:01:27 2013
From: kuninori.morimoto.gx at renesas.com (Kuninori Morimoto)
Date: Thu, 04 Apr 2013 19:01:27 -0700 (PDT)
Subject: [PATCH 0/8] Reorganize R8A7779/Marzen USB code
In-Reply-To: <201304050251.44464.sergei.shtylyov@cogentembedded.com>
References: <201304050251.44464.sergei.shtylyov@cogentembedded.com>
Message-ID: <87vc81ka6k.wl%kuninori.morimoto.gx@renesas.com>


Hi

>    Here's the set of 4 patches against the Simon Horman's 'renesas.git' repo,
> 'renesas-next-20130404v2' tag and the 2 Ether patches I've reposted yesterday.
> It was created to fix the shortcomings in the R8A7779/Marzen USB platform code
> and R8A7779 USB common PHY driver, and so spans both arch/arm/mach-shmobile/
> and drivers/usb/ subtrees (some patches have to touch both subtrees).
> The patches were conceived with the complete bisectability goal in mind.
> 
> [1/8] ARM: shmobile:Marzen: move USB EHCI, OHCI, and PHY devices to R8A7779 code
> [2/8] ehci-platform: add init() method to platform data
> [3/8] ARM: shmobile: R8A7779: setup EHCI internal buffer
> [4/8] rcar-phy: remove EHCI internal buffer setup
> [5/8] rcar-phy: correct base address
> [6/8] rcar-phy: add platform data
> [7/8] ARM: shmobile: Marzen: pass platform data to USB PHY device
> [8/8] rcar-phy: handle platform data
> 
>    I'm not sure thru which tree this patchset should be merged, however it turns
> out that it's too late now to push it thru Felipe Balbi's USB tree for 3.10, so
> maybe the patchset can be merged thru Simon's tree with Felipe's and Alan
> Stern's ACKs.

I guess you already got request about patch style from Simon.
When you send v2 patch, could you please add "this patch is tested on xxxx bard"
on each patch's comment area ?

Then,
for all patches

Acked-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>

Best regards
---
Kuninori Morimoto


From nicolas.pitre at linaro.org  Thu Apr  4 22:03:54 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Thu, 4 Apr 2013 22:03:54 -0400 (EDT)
Subject: [GIT PULL] Multi Cluster Power Management infrastructure
In-Reply-To: <alpine.LFD.2.03.1304022258430.1171@syhkavp.arg>
References: <alpine.LFD.2.03.1303251219530.1372@syhkavp.arg>
 <20130328134808.GD16765@e102568-lin.cambridge.arm.com>
 <alpine.LFD.2.03.1304022258430.1171@syhkavp.arg>
Message-ID: <alpine.LFD.2.03.1304042138160.1171@syhkavp.arg>

I want to deplore a situation that highlights a bottleneck with our 
current upstreaming process on ARM affecting the MCPM patch series I'm 
maintaining.

This patch series has been extensively reviewed.

1st review cycle (10 Jan 2013):
http://news.gmane.org/group/gmane.linux.ports.arm.kernel/thread=208625

2nd review cycle (24 Jan 2013):
http://news.gmane.org/group/gmane.linux.ports.arm.kernel/thread=212196

3rd review cycle (29 Jan 2013):
http://news.gmane.org/group/gmane.linux.ports.arm.kernel/thread=213562

4th review cycle (5 Feb 2013):
http://news.gmane.org/group/gmane.linux.ports.arm.kernel/thread=215477

The following people were involved in the discussion:

  Achin Gupta
  Catalin Marinas
  Dave Martin
  Jon Medhurst
  Joseph Lo
  Lorenzo Pieralisi
  Saeed Bishara
  Santosh Shilimkar
  Stephen Boyd
  Rob Herring
  Pawel Moll
  Will Deacon

Resulting review comments were all addressed.  

So, a pull request for the v3.8 merge window was posted (6 Feb 2013):
http://article.gmane.org/gmane.linux.ports.arm.kernel/216061

This, however, didn't get merged in time due to some miscommunication
about non technical reasons.  I therefore won't expose those reasons 
here.  Suffice to say that a merge window was missed.

Therefore, this was followed by another pull request for the v3.9 merge window (25 Mar 2013):
http://article.gmane.org/gmane.linux.ports.arm.kernel/225873

Followed by a merge plan inquiry from Lorenzo (28 Mar 2013):
http://article.gmane.org/gmane.linux.ports.arm.kernel/227035

To end up with my ping (3 Apr 2013):
http://article.gmane.org/gmane.linux.ports.arm.kernel/228209

Russell mentioned having issues with the mailing list traffic and pull
request being buried.  He therefore suggested a special email alias
to filter pull requests (22 Mar 2013):
http://article.gmane.org/gmane.linux.ports.arm.kernel/225377

The last pull request used that alias, and the latest ping did use both 
the pull alias as well as his regular email address.

We're approaching v3.9-rc6, and there is still no sign of this patch set 
being headed for mainline yet.  The system is _not_ working if this 
series is to miss yet another merge window.

On March 28th, Russell mentioned he'd be sporadically away for the 
following two weeks, and suggested that the GIC patches go through the 
ARM SoC tree:
http://article.gmane.org/gmane.linux.ports.arm.kernel/227040

Given the lack of backup to pick up the load when Russell is unavailable 
(seeing the next merge window approaching and still no response from my 
latest pull request and its subsequent recalls), I'm questionning the 
current process scalability. Therefore, at this point, I'm suggesting 
that the MCPM series be merged in the ARM SoC tree as well, as a backup 
solution.

After all, this series is a prerequisite for more patches about platform 
specific patches meant for the ARM SoC tree but which currently are 
still waiting.  Having the prerequisite in the ARM SOC tree will allow 
for those patches to be exposed earlier.


Nicolas


From horms at verge.net.au  Thu Apr  4 22:07:17 2013
From: horms at verge.net.au (Simon Horman)
Date: Fri, 5 Apr 2013 11:07:17 +0900
Subject: [PATCH 00/04] ARM: shmobile: pinmux platform device cleanups
In-Reply-To: <11100532.ubSdK9L5P1@avalon>
References: <20130403063246.2500.65318.sendpatchset@w520>
 <11100532.ubSdK9L5P1@avalon>
Message-ID: <20130405020717.GY29203@verge.net.au>

On Thu, Apr 04, 2013 at 12:24:15PM +0200, Laurent Pinchart wrote:
> Hi Magnus,
> 
> Thanks for the patches.
> 
> On Wednesday 03 April 2013 15:32:46 Magnus Damm wrote:
> > ARM: shmobile: pinmux platform device cleanups
> > 
> > [PATCH 01/04] ARM: shmobile: r8a7740 pinmux platform device cleanup
> > [PATCH 02/04] ARM: shmobile: r8a7779 pinmux platform device cleanup
> > [PATCH 03/04] ARM: shmobile: sh7372 pinmux platform device cleanup
> > [PATCH 04/04] ARM: shmobile: sh73a0 pinmux platform device cleanup
> > 
> > This series simply cleans up the pinmux platform device handling
> > to save a couple of lines. Compile time tested on each SoC.
> > 
> > Signed-off-by: Magnus Damm <damm at opensource.se>
> 
> Except for 2/4,
> 
> Acked-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>

Thanks.

1/4: queued up in soc-r8a7740 branch
3/4: queued up in soc-sh7372 branch
4/4: queued up in soc-sh73a0 branch

> > ---
> > 
> >  Written against renesas-next-20130403 in renesas.git
> > 
> >  arch/arm/mach-shmobile/setup-r8a7740.c |   24 +++++-------------------
> >  arch/arm/mach-shmobile/setup-r8a7779.c |   19 ++++---------------
> >  arch/arm/mach-shmobile/setup-sh7372.c  |   24 +++++-------------------
> >  arch/arm/mach-shmobile/setup-sh73a0.c  |   25 ++++++-------------------
> >  4 files changed, 20 insertions(+), 72 deletions(-)


From horms at verge.net.au  Thu Apr  4 22:13:39 2013
From: horms at verge.net.au (Simon Horman)
Date: Fri, 5 Apr 2013 11:13:39 +0900
Subject: [PATCH/RFC 0/2] ARM: shmobile: DT irqpin for r8a7779 and
 marzen-reference
In-Reply-To: <20130405014429.GV29203@verge.net.au>
References: <Pine.LNX.4.64.1304031103590.10531@axis700.grange>
 <20130404035426.GC28297@verge.net.au>
 <Pine.LNX.4.64.1304042325140.21548@axis700.grange>
 <20130405014429.GV29203@verge.net.au>
Message-ID: <20130405021339.GZ29203@verge.net.au>

On Fri, Apr 05, 2013 at 10:44:29AM +0900, Simon Horman wrote:
> On Thu, Apr 04, 2013 at 11:47:05PM +0200, Guennadi Liakhovetski wrote:
> > Hi Simon
> > 
> > On Thu, 4 Apr 2013, Simon Horman wrote:
> > 
> > > On Wed, Apr 03, 2013 at 11:18:57AM +0200, Guennadi Liakhovetski wrote:
> > > > Hi
> > > > 
> > > > This 2 patches add DT irqpin support on marzen-reference. Only 
> > > > compile-tested due to the lack of hardware. The patches can go 
> > > > independently via their respective trees. irqpin on marzen will not work 
> > > > if patch 2 is applied before patch 1, but as long as there are no devices, 
> > > > using irqpin interrupts, no breakage will be caused.
> > > 
> > > I have applied both patches and the dependency I mention below.
> > > I have also applied the small patch, inlined below, to hook-up
> > > the LAN controller. Unfortunately it doesn't seem to be receiving
> > > any interrupts. Perhaps I am missing something?
> > 
> > Are you sure 28 is the correct number in the irqpin IRQ space? Seems 
> > strange to me. Should be 1 perhaps (counting from 0), or 2 - not sure how 
> > that mapping would look like.
> 
> Thanks!
> 
> 0 seems to be the lucky number, I have SMSC (and NFS root) working
> on marzen-reference.

s/0/1/

> I have posted "ARM: shmobile: marzen-reference: use irqpin for lan"
> 
> > > > Guennadi Liakhovetski (2):
> > > >       irqchip: renesas-intc-irqpin: DT binding for sense bitfield width
> > > 
> > > The above patch depends on "[1/3] ARM: shmobile: irqpin: fix handling of
> > > spurious interrupts in DT case", right?
> > 
> > Not functionally. Spurious interrupts occur on sh73a0, the sense bitfield 
> > is needed for r8a7779. But the latter won't apply without the former, 
> > that's right.
> 
> Thanks, could you reposts this series rebase so that it doesn't require
> ""[1/3] ARM: shmobile: irqpin: fix handling of spurious interrupts in DT case"
> to apply cleanly.
> 
> Feel free to break the creation of
> Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.txt
> into a separate patch.
> 
> Please add "ARM: shmobile: marzen-reference: use irqpin for lan" to
> the end of the series with an Ack if you have no objections to it.
> 
> > > Has there been any progress in your
> > > discussions with Magnus about what to do about that patch?
> > 
> > No, not yet.
> 
> Thanks, understood.
> 
> And thanks doubly for this series.
> It is very nice to have bouth irqpin and ethernet working on
> marzen-reference.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


From festevam at gmail.com  Thu Apr  4 22:20:54 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Thu,  4 Apr 2013 23:20:54 -0300
Subject: [PATCH v4 1/2] ARM: dts: mxs: Use 'regulator-fixed' for turning on LCD
Message-ID: <1365128456-8762-1-git-send-email-festevam@gmail.com>

From: Fabio Estevam <fabio.estevam at freescale.com>

Instead of using a custom binding for turning on a GPIO that activates the
LCD, use the standard 'regulator-fixed'.

Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
---
Changes since v3:
- Fix regulator bindings (use lcd-supply)
Changes since v2:
- Use regulator-fixed
Changes since v1:
- Adjust Subject, since the change is not specific to mx28evk
 Documentation/devicetree/bindings/fb/mxsfb.txt |    5 +----
 arch/arm/boot/dts/imx23-evk.dts                |   11 ++++++++++-
 arch/arm/boot/dts/imx28-evk.dts                |   11 ++++++++++-
 3 files changed, 21 insertions(+), 6 deletions(-)

diff --git a/Documentation/devicetree/bindings/fb/mxsfb.txt b/Documentation/devicetree/bindings/fb/mxsfb.txt
index 7ba3b76..b15230c 100644
--- a/Documentation/devicetree/bindings/fb/mxsfb.txt
+++ b/Documentation/devicetree/bindings/fb/mxsfb.txt
@@ -8,9 +8,7 @@ Required properties:
 - display : phandle to display node (see below for details)
 
 Optional properties:
-- panel-enable-gpios : Should specify the gpio for panel enable
-
-* display node
+- display node
 
 Required properties:
 - bits-per-pixel : <16> for RGB565, <32> for RGB888/666.
@@ -25,7 +23,6 @@ lcdif at 80030000 {
 	compatible = "fsl,imx28-lcdif";
 	reg = <0x80030000 2000>;
 	interrupts = <38 86>;
-	panel-enable-gpios = <&gpio3 30 0>;
 
 	display: display {
 		bits-per-pixel = <32>;
diff --git a/arch/arm/boot/dts/imx23-evk.dts b/arch/arm/boot/dts/imx23-evk.dts
index 7880e17..da0588a 100644
--- a/arch/arm/boot/dts/imx23-evk.dts
+++ b/arch/arm/boot/dts/imx23-evk.dts
@@ -59,7 +59,7 @@
 			lcdif at 80030000 {
 				pinctrl-names = "default";
 				pinctrl-0 = <&lcdif_24bit_pins_a>;
-				panel-enable-gpios = <&gpio1 18 0>;
+				lcd-supply = <&reg_lcd_3v3>;
 				display = <&display>;
 				status = "okay";
 
@@ -120,6 +120,15 @@
 			regulator-max-microvolt = <3300000>;
 			gpio = <&gpio1 29 0>;
 		};
+
+		reg_lcd_3v3: lcd-3v3 {
+			compatible = "regulator-fixed";
+			regulator-name = "lcd-3v3";
+			regulator-min-microvolt = <3300000>;
+			regulator-max-microvolt = <3300000>;
+			gpio = <&gpio1 18 0>;
+			enable-active-high;
+		};
 	};
 
 	backlight {
diff --git a/arch/arm/boot/dts/imx28-evk.dts b/arch/arm/boot/dts/imx28-evk.dts
index 2d4ea3b..3637bf3 100644
--- a/arch/arm/boot/dts/imx28-evk.dts
+++ b/arch/arm/boot/dts/imx28-evk.dts
@@ -123,7 +123,7 @@
 				pinctrl-names = "default";
 				pinctrl-0 = <&lcdif_24bit_pins_a
 					     &lcdif_pins_evk>;
-				panel-enable-gpios = <&gpio3 30 0>;
+				lcd-supply = <&reg_lcd_3v3>;
 				display = <&display>;
 				status = "okay";
 
@@ -310,6 +310,15 @@
 			gpio = <&gpio3 8 0>;
 			enable-active-high;
 		};
+
+		reg_lcd_3v3: lcd-3v3 {
+			compatible = "regulator-fixed";
+			regulator-name = "lcd-3v3";
+			regulator-min-microvolt = <3300000>;
+			regulator-max-microvolt = <3300000>;
+			gpio = <&gpio3 30 0>;
+			enable-active-high;
+		};
 	};
 
 	sound {
-- 
1.7.9.5



From festevam at gmail.com  Thu Apr  4 22:20:55 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Thu,  4 Apr 2013 23:20:55 -0300
Subject: [PATCH v4 2/2] video: mxsfb: Use devm_regulator_get()
In-Reply-To: <1365128456-8762-1-git-send-email-festevam@gmail.com>
References: <1365128456-8762-1-git-send-email-festevam@gmail.com>
Message-ID: <1365128456-8762-2-git-send-email-festevam@gmail.com>

From: Fabio Estevam <fabio.estevam at freescale.com>

Instead of using a custom binding for retrieving the GPIO that activates the 
LCD from devicetree, use the standard devm_regulator_get().

This approach has the advantage to be more generic. 

For example: in the case of a board that has a PMIC supplying the LCD voltage, 
the current approach would not work, as it only searches for a GPIO pin.

Cc: Florian Tobias Schandinat <FlorianSchandinat at gmx.de>
Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
---
Changes since v3:
- None
Changes since v2:
- Use devm_regulator_get()
Changes since v1:
- No changes
 drivers/video/mxsfb.c |   19 ++++++-------------
 1 file changed, 6 insertions(+), 13 deletions(-)

diff --git a/drivers/video/mxsfb.c b/drivers/video/mxsfb.c
index eac7c1a..c536887 100644
--- a/drivers/video/mxsfb.c
+++ b/drivers/video/mxsfb.c
@@ -42,7 +42,6 @@
 #include <linux/module.h>
 #include <linux/kernel.h>
 #include <linux/of_device.h>
-#include <linux/of_gpio.h>
 #include <video/of_display_timing.h>
 #include <linux/platform_device.h>
 #include <linux/clk.h>
@@ -51,6 +50,7 @@
 #include <linux/pinctrl/consumer.h>
 #include <linux/fb.h>
 #include <video/videomode.h>
+#include <linux/regulator/consumer.h>
 
 #define REG_SET	4
 #define REG_CLR	8
@@ -859,9 +859,8 @@ static int mxsfb_probe(struct platform_device *pdev)
 	struct fb_info *fb_info;
 	struct fb_modelist *modelist;
 	struct pinctrl *pinctrl;
-	int panel_enable;
-	enum of_gpio_flags flags;
 	int ret;
+	struct regulator *reg_lcd;
 
 	if (of_id)
 		pdev->id_entry = of_id->data;
@@ -904,18 +903,12 @@ static int mxsfb_probe(struct platform_device *pdev)
 		goto fb_release;
 	}
 
-	panel_enable = of_get_named_gpio_flags(pdev->dev.of_node,
-					       "panel-enable-gpios", 0, &flags);
-	if (gpio_is_valid(panel_enable)) {
-		unsigned long f = GPIOF_OUT_INIT_HIGH;
-		if (flags == OF_GPIO_ACTIVE_LOW)
-			f = GPIOF_OUT_INIT_LOW;
-		ret = devm_gpio_request_one(&pdev->dev, panel_enable,
-					    f, "panel-enable");
+	reg_lcd = devm_regulator_get(&pdev->dev, "lcd");
+	if (!IS_ERR(reg_lcd)) {
+		ret = regulator_enable(reg_lcd);
 		if (ret) {
 			dev_err(&pdev->dev,
-				"failed to request gpio %d: %d\n",
-				panel_enable, ret);
+				"Failed to enable lcd regulator: %d\n", ret);
 			goto fb_release;
 		}
 	}
-- 
1.7.9.5



From horms at verge.net.au  Thu Apr  4 22:22:53 2013
From: horms at verge.net.au (Simon Horman)
Date: Fri, 5 Apr 2013 11:22:53 +0900
Subject: [PATCH/RFC 2/3] ARM: shmobile: initialise clock early on
 kzm9g-reference
In-Reply-To: <Pine.LNX.4.64.1304040847260.21548@axis700.grange>
References: <1365005636-17526-1-git-send-email-g.liakhovetski@gmx.de>
 <1365005636-17526-3-git-send-email-g.liakhovetski@gmx.de>
 <20130404033158.GA28297@verge.net.au>
 <Pine.LNX.4.64.1304040847260.21548@axis700.grange>
Message-ID: <20130405022253.GA29203@verge.net.au>

On Thu, Apr 04, 2013 at 09:13:07AM +0200, Guennadi Liakhovetski wrote:
> Hi Simon
> 
> On Thu, 4 Apr 2013, Simon Horman wrote:
> 
> > On Wed, Apr 03, 2013 at 06:13:55PM +0200, Guennadi Liakhovetski wrote:
> > > To prepare to enable TWD on kzm9g-reference, clock initialisation has to be
> > > done early. Move it from .init_machine to .init_time stage.
> > 
> > I'm pretty surprised by this given how much effort has
> > been made to avoid early clock initialisation.
> 
> Yes, sorry, I probably failed to explain exactly the meaning of "RFC" in 
> these patches. My goal was to find a way to activate the TWD on kzm9g in 
> the "-reference" configuration, i.e. with DT, when TWD is also 
> instantiated as a DT node. This didn't work out of the box by simply 
> adding the respective DT node as in patch/rfc #3 in this series. Doing 
> that just resulted in a lock up with no output. The reason was, that TWD 
> was trying to initialise before any other timers / clocks and its 
> calibration in twd_calibrate_rate() was cycling endlessly. So, I tried to 
> find a way to fix this lock-up, which produced these RFCs. I'm perfectly 
> aware, that this might not be what we want to have in the mainline, this 
> is just an illustration, what I had to do to get TWD running with DT.

Thanks for the clarification, I understand.

> As for "avoid early clock initialisation" - I'm aware of this goal in 
> principle, but I'm not sure about details - how early is too early and 
> when it is already allowed, why is this important with DT and not with 
> legacy (because we want to initialise all clocks from DT?), what are 
> proper ways to solve problems like this one? Note, that TWD has to be 
> registered before secondary_start_kernel() is run. So, we need a 
> clocksource before that time for a successful TWD calibration.

I wonder if this problem can be resolved using init priorities?

In general I believe the idea is that early clocks can and should
be avoided because they should not be necessary. If they are necessary
in some cases then I assume we will use them.

Magnus, can you clarify this?

> Thanks
> Guennadi
> 
> > > Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas at gmail.com>
> > > ---
> > >  arch/arm/mach-shmobile/board-kzm9g-reference.c |    8 +++++++-
> > >  arch/arm/mach-shmobile/setup-sh73a0.c          |   13 +++++++++----
> > >  2 files changed, 16 insertions(+), 5 deletions(-)
> > > 
> > > diff --git a/arch/arm/mach-shmobile/board-kzm9g-reference.c b/arch/arm/mach-shmobile/board-kzm9g-reference.c
> > > index aefa50d..0f9b276 100644
> > > --- a/arch/arm/mach-shmobile/board-kzm9g-reference.c
> > > +++ b/arch/arm/mach-shmobile/board-kzm9g-reference.c
> > > @@ -90,6 +90,12 @@ static void __init kzm_init(void)
> > >  #endif
> > >  }
> > >  
> > > +static void __init timer_init(void)
> > > +{
> > > +	sh73a0_clock_init();
> > > +	shmobile_timer_init();
> > > +}
> > > +
> > >  static const char *kzm9g_boards_compat_dt[] __initdata = {
> > >  	"renesas,kzm9g-reference",
> > >  	NULL,
> > > @@ -102,6 +108,6 @@ DT_MACHINE_START(KZM9G_DT, "kzm9g-reference")
> > >  	.nr_irqs	= NR_IRQS_LEGACY,
> > >  	.init_irq	= irqchip_init,
> > >  	.init_machine	= kzm_init,
> > > -	.init_time	= shmobile_timer_init,
> > > +	.init_time	= timer_init,
> > >  	.dt_compat	= kzm9g_boards_compat_dt,
> > >  MACHINE_END
> > > diff --git a/arch/arm/mach-shmobile/setup-sh73a0.c b/arch/arm/mach-shmobile/setup-sh73a0.c
> > > index 0469e84..8a1bc1c 100644
> > > --- a/arch/arm/mach-shmobile/setup-sh73a0.c
> > > +++ b/arch/arm/mach-shmobile/setup-sh73a0.c
> > > @@ -1018,9 +1018,6 @@ void __init sh73a0_add_standard_devices_dt(void)
> > >  {
> > >  	struct platform_device_info devinfo = { .name = "cpufreq-cpu0", .id = -1, };
> > >  
> > > -	/* clocks are setup late during boot in the case of DT */
> > > -	sh73a0_clock_init();
> > > -
> > >  	platform_add_devices(sh73a0_devices_dt,
> > >  			     ARRAY_SIZE(sh73a0_devices_dt));
> > >  	of_platform_populate(NULL, of_default_bus_match_table,
> > > @@ -1030,6 +1027,14 @@ void __init sh73a0_add_standard_devices_dt(void)
> > >  	platform_device_register_full(&devinfo);
> > >  }
> > >  
> > > +static void __init add_standard_devices(void)
> > > +{
> > > +	/* clocks are setup late during boot in the case of DT */
> > > +	sh73a0_clock_init();
> > > +
> > > +	sh73a0_add_standard_devices_dt();
> > > +}
> > > +
> > >  static const char *sh73a0_boards_compat_dt[] __initdata = {
> > >  	"renesas,sh73a0",
> > >  	NULL,
> > > @@ -1041,7 +1046,7 @@ DT_MACHINE_START(SH73A0_DT, "Generic SH73A0 (Flattened Device Tree)")
> > >  	.init_early	= sh73a0_init_delay,
> > >  	.nr_irqs	= NR_IRQS_LEGACY,
> > >  	.init_irq	= irqchip_init,
> > > -	.init_machine	= sh73a0_add_standard_devices_dt,
> > > +	.init_machine	= add_standard_devices,
> > >  	.init_time	= shmobile_timer_init,
> > >  	.dt_compat	= sh73a0_boards_compat_dt,
> > >  MACHINE_END
> > > -- 
> > > 1.7.2.5
> > > 
> > > --
> > > To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> > > the body of a message to majordomo at vger.kernel.org
> > > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > > 
> > 
> 
> ---
> Guennadi Liakhovetski, Ph.D.
> Freelance Open-Source Software Developer
> http://www.open-technology.de/
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


From horms at verge.net.au  Thu Apr  4 22:23:29 2013
From: horms at verge.net.au (Simon Horman)
Date: Fri, 5 Apr 2013 11:23:29 +0900
Subject: [PATCH 1/3] ARM: also support TWD clock, instantiated from
 platform data
In-Reply-To: <1365005636-17526-2-git-send-email-g.liakhovetski@gmx.de>
References: <1365005636-17526-1-git-send-email-g.liakhovetski@gmx.de>
 <1365005636-17526-2-git-send-email-g.liakhovetski@gmx.de>
Message-ID: <20130405022329.GB29203@verge.net.au>

On Wed, Apr 03, 2013 at 06:13:54PM +0200, Guennadi Liakhovetski wrote:
> While gradually switching clock initialisation to DT some architectures
> can have TWD device in DT, but supplying clock initialised from platform
> data. This patch adds support for such configurations to ARM.
> 
> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas at gmail.com>
> Cc: Russell King <linux at arm.linux.org.uk>

Acked-by: Simon Horman <horms+renesas at verge.net.au>

> ---
>  arch/arm/kernel/smp_twd.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/arm/kernel/smp_twd.c b/arch/arm/kernel/smp_twd.c
> index 3f25650..8f12aa3 100644
> --- a/arch/arm/kernel/smp_twd.c
> +++ b/arch/arm/kernel/smp_twd.c
> @@ -244,7 +244,7 @@ static void twd_get_clock(struct device_node *np)
>  
>  	if (np)
>  		twd_clk = of_clk_get(np, 0);
> -	else
> +	if (IS_ERR(twd_clk))
>  		twd_clk = clk_get_sys("smp_twd", NULL);
>  
>  	if (IS_ERR(twd_clk)) {
> -- 
> 1.7.2.5
> 


From horms at verge.net.au  Thu Apr  4 22:25:25 2013
From: horms at verge.net.au (Simon Horman)
Date: Fri, 5 Apr 2013 11:25:25 +0900
Subject: [PATCH] ARM: shmobile: kzm9d: resigser smsc911x platform device
 with id -1
In-Reply-To: <1365042033-29649-1-git-send-email-horms+renesas@verge.net.au>
References: <1365042033-29649-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <20130405022525.GC29203@verge.net.au>

On Thu, Apr 04, 2013 at 11:20:33AM +0900, Simon Horman wrote:
> As the kzm9d only has one smsc911x device it
> may be registered as a platform device with id -1.
> 
> This allows the kzm9d board to access the smsc911x device
> when CONFIG_REGULATOR (and CONFIG_REGULATOR_FIXED_VOLTAGE)
> are set. The motivation for which is twofold: using regulators
> seems to be generally a good thing; it will move the kzm9d defconfig
> one step closer to being able to be consolidated with other
> shmobile defconfigs.
> 
> An alternate but so far untested approach would be to
> update the definition of dummy_supplies in board-kzm9d.c
> to use "smsc911x.0" instead of "smsc911x".
> 
> Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
> ---
>  arch/arm/mach-shmobile/board-kzm9d.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-shmobile/board-kzm9d.c b/arch/arm/mach-shmobile/board-kzm9d.c
> index c254782..2425d67 100644
> --- a/arch/arm/mach-shmobile/board-kzm9d.c
> +++ b/arch/arm/mach-shmobile/board-kzm9d.c
> @@ -56,7 +56,7 @@ static struct smsc911x_platform_config smsc911x_platdata = {
>  
>  static struct platform_device smsc91x_device = {
>  	.name	= "smsc911x",
> -	.id	= 0,
> +	.id	= -1,
>  	.dev	= {
>  		  .platform_data = &smsc911x_platdata,
>  		},
> -- 
> 1.7.10.4
> 

Queued up in the boards-kzm9d branch.


From horms at verge.net.au  Thu Apr  4 22:26:23 2013
From: horms at verge.net.au (Simon Horman)
Date: Fri, 5 Apr 2013 11:26:23 +0900
Subject: [PATCH] irqchip: irqc: Add runtime PM support
In-Reply-To: <1365056466-23710-1-git-send-email-horms+renesas@verge.net.au>
References: <1365056466-23710-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <20130405022623.GD29203@verge.net.au>

On Thu, Apr 04, 2013 at 03:21:06PM +0900, Simon Horman wrote:
> This was tested using the SMSC LAN on the APE6EVM board.
> 
> Signed-off-by: Simon Horman <horms+renesas at verge.net.au>

Magnus, Morimoto-san, could you review this?

> ---
>  drivers/irqchip/irq-renesas-irqc.c |    8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/irqchip/irq-renesas-irqc.c b/drivers/irqchip/irq-renesas-irqc.c
> index 927bff3..649cd69 100644
> --- a/drivers/irqchip/irq-renesas-irqc.c
> +++ b/drivers/irqchip/irq-renesas-irqc.c
> @@ -19,6 +19,7 @@
>  
>  #include <linux/init.h>
>  #include <linux/platform_device.h>
> +#include <linux/pm_runtime.h>
>  #include <linux/spinlock.h>
>  #include <linux/interrupt.h>
>  #include <linux/ioport.h>
> @@ -181,6 +182,9 @@ static int irqc_probe(struct platform_device *pdev)
>  		goto err1;
>  	}
>  
> +	pm_runtime_enable(&pdev->dev);
> +	pm_runtime_get_sync(&pdev->dev);
> +
>  	/* allow any number of IRQs between 1 and IRQC_IRQ_MAX */
>  	for (k = 0; k < IRQC_IRQ_MAX; k++) {
>  		irq = platform_get_resource(pdev, IORESOURCE_IRQ, k);
> @@ -255,6 +259,8 @@ err3:
>  err2:
>  	iounmap(p->iomem);
>  err1:
> +	pm_runtime_put_sync(&pdev->dev);
> +	pm_runtime_disable(&pdev->dev);
>  	kfree(p);
>  err0:
>  	return ret;
> @@ -270,6 +276,8 @@ static int irqc_remove(struct platform_device *pdev)
>  
>  	irq_domain_remove(p->irq_domain);
>  	iounmap(p->iomem);
> +	pm_runtime_put_sync(&pdev->dev);
> +	pm_runtime_disable(&pdev->dev);
>  	kfree(p);
>  	return 0;
>  }
> -- 
> 1.7.10.4
> 


From horms+renesas at verge.net.au  Thu Apr  4 22:56:22 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri,  5 Apr 2013 11:56:22 +0900
Subject: [GIT PULL] Renesas ARM based SoC bockw defconfig updates for v3.10
Message-ID: <1365130583-11257-1-git-send-email-horms+renesas@verge.net.au>

Hi Olof, Hi Arnd,

The following changes since commit 00ae962f8051bb143fa1c43c6a9c8274c3a9c593:

  ARM: shmobile: mackerel: clean up MMCIF vs. SDHI1 selection (2013-04-03 10:50:44 +0900)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas tags/renesas-defconfig-bockw-for-v3.10

for you to fetch changes up to e2f77f6ff54865870870aaff0c07e2c35c4e0cfa:

  ARM: shmobile: bockw: enable SMSC ethernet on defconfig (2013-04-04 15:51:12 +0900)

----------------------------------------------------------------
Renesas ARM based SoC bockw defconfig updates for v3.10

An update to the defconfig for the bockw board to enable SMSC ethernet.

This is based on:

git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas renesas-boards3-for-v3.10

The reason for using that base is that the bockw defconfig was added
in the boards branch instead of the defconfig branch, which was not ideal.

----------------------------------------------------------------
Kuninori Morimoto (1):
      ARM: shmobile: bockw: enable SMSC ethernet on defconfig

 arch/arm/configs/bockw_defconfig |   34 +++++++++++++++++++++++++++++++---
 1 file changed, 31 insertions(+), 3 deletions(-)


From horms+renesas at verge.net.au  Thu Apr  4 22:56:23 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri,  5 Apr 2013 11:56:23 +0900
Subject: [PATCH] ARM: shmobile: bockw: enable SMSC ethernet on defconfig
In-Reply-To: <1365130583-11257-1-git-send-email-horms+renesas@verge.net.au>
References: <1365130583-11257-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1365130583-11257-2-git-send-email-horms+renesas@verge.net.au>

From: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>

This patch adds SMSC ethernet support on Bock-W defconfig

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Acked-by: Magnus Damm <damm at opensource.se>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/configs/bockw_defconfig |   34 +++++++++++++++++++++++++++++++---
 1 file changed, 31 insertions(+), 3 deletions(-)

diff --git a/arch/arm/configs/bockw_defconfig b/arch/arm/configs/bockw_defconfig
index 6037705..6524cdf 100644
--- a/arch/arm/configs/bockw_defconfig
+++ b/arch/arm/configs/bockw_defconfig
@@ -27,16 +27,40 @@ CONFIG_HIGHMEM=y
 CONFIG_ZBOOT_ROM_TEXT=0x0
 CONFIG_ZBOOT_ROM_BSS=0x0
 CONFIG_ARM_APPENDED_DTB=y
-CONFIG_CMDLINE="console=ttySC0,115200 ignore_loglevel"
+CONFIG_CMDLINE="console=ttySC0,115200 ignore_loglevel root=/dev/nfs ip=dhcp"
 CONFIG_CMDLINE_FORCE=y
 # CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
 # CONFIG_SUSPEND is not set
+CONFIG_NET=y
+CONFIG_UNIX=y
+CONFIG_INET=y
+CONFIG_IP_PNP=y
+CONFIG_IP_PNP_DHCP=y
+# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
+# CONFIG_INET_XFRM_MODE_TUNNEL is not set
+# CONFIG_INET_XFRM_MODE_BEET is not set
+# CONFIG_INET_LRO is not set
+# CONFIG_INET_DIAG is not set
+# CONFIG_IPV6 is not set
 CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
 CONFIG_DEVTMPFS=y
 CONFIG_DEVTMPFS_MOUNT=y
 # CONFIG_STANDALONE is not set
 # CONFIG_PREVENT_FIRMWARE_BUILD is not set
 # CONFIG_FW_LOADER is not set
+CONFIG_NETDEVICES=y
+# CONFIG_NET_CADENCE is not set
+# CONFIG_NET_VENDOR_BROADCOM is not set
+# CONFIG_NET_VENDOR_CIRRUS is not set
+# CONFIG_NET_VENDOR_FARADAY is not set
+# CONFIG_NET_VENDOR_INTEL is not set
+# CONFIG_NET_VENDOR_MARVELL is not set
+# CONFIG_NET_VENDOR_MICREL is not set
+# CONFIG_NET_VENDOR_NATSEMI is not set
+# CONFIG_NET_VENDOR_SEEQ is not set
+CONFIG_SMSC911X=y
+# CONFIG_NET_VENDOR_STMICRO is not set
+# CONFIG_NET_VENDOR_WIZNET is not set
 # CONFIG_INPUT is not set
 # CONFIG_SERIO is not set
 # CONFIG_VT is not set
@@ -55,12 +79,16 @@ CONFIG_UIO_PDRV_GENIRQ=y
 # CONFIG_INOTIFY_USER is not set
 CONFIG_TMPFS=y
 # CONFIG_MISC_FILESYSTEMS is not set
+CONFIG_NFS_FS=y
+CONFIG_NFS_V3_ACL=y
+CONFIG_NFS_V4=y
+CONFIG_NFS_SWAP=y
+CONFIG_NFS_V4_1=y
+CONFIG_ROOT_NFS=y
 # CONFIG_ENABLE_WARN_DEPRECATED is not set
 # CONFIG_ENABLE_MUST_CHECK is not set
 # CONFIG_SCHED_DEBUG is not set
 # CONFIG_DEBUG_BUGVERBOSE is not set
 # CONFIG_FTRACE is not set
 # CONFIG_ARM_UNWIND is not set
-CONFIG_KEYS=y
-CONFIG_CRYPTO=y
 CONFIG_AVERAGE=y
-- 
1.7.10.4



From horms+renesas at verge.net.au  Thu Apr  4 22:57:47 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri,  5 Apr 2013 11:57:47 +0900
Subject: [GIT PULL] Renesas ARM r8a7779 SoC update for v3.10
Message-ID: <1365130669-11662-1-git-send-email-horms+renesas@verge.net.au>

Hi Olof, Hi Arnd,

The following changes since commit 8585deb18580d04209a2986430aa0959ef38fce2:

  ARM: shmobile: r8a7790 SoC 64-bit DT support (2013-04-02 11:02:21 +0900)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas tags/renesas-soc-r8a7779-for-v3.10

for you to fetch changes up to dace48d04dee46a3409d5e13cd98031522e46377:

  ARM: shmobile: R8A7779: add Ether support (2013-04-05 10:47:03 +0900)

----------------------------------------------------------------
Renesas ARM r8a7779 SoC update for v3.10

Update to the r8a7779 SoC:
* Add SH Ethernet support
* Add comment describing clock ratios

This pull request is based on:
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas renesas-soc2-for-v3.10

----------------------------------------------------------------
Kuninori Morimoto (1):
      ARM: shmobile: r8a7779: add each clocks ratio on comment area

Sergei Shtylyov (1):
      ARM: shmobile: R8A7779: add Ether support

 arch/arm/mach-shmobile/clock-r8a7779.c        |   23 ++++++++++++++++++++++-
 arch/arm/mach-shmobile/include/mach/r8a7779.h |    2 ++
 arch/arm/mach-shmobile/setup-r8a7779.c        |   23 ++++++++++++++++++++++-
 3 files changed, 46 insertions(+), 2 deletions(-)


From horms+renesas at verge.net.au  Thu Apr  4 22:57:49 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri,  5 Apr 2013 11:57:49 +0900
Subject: [PATCH 2/2] ARM: shmobile: R8A7779: add Ether support
In-Reply-To: <1365130669-11662-1-git-send-email-horms+renesas@verge.net.au>
References: <1365130669-11662-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1365130669-11662-3-git-send-email-horms+renesas@verge.net.au>

From: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

Add Ether clock and platform device for R8A7779 SoC; add a function to register
this device with board-specific platform data.

Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/clock-r8a7779.c        |    4 +++-
 arch/arm/mach-shmobile/include/mach/r8a7779.h |    2 ++
 arch/arm/mach-shmobile/setup-r8a7779.c        |   23 ++++++++++++++++++++++-
 3 files changed, 27 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-shmobile/clock-r8a7779.c b/arch/arm/mach-shmobile/clock-r8a7779.c
index 5436b51..31d5cd4 100644
--- a/arch/arm/mach-shmobile/clock-r8a7779.c
+++ b/arch/arm/mach-shmobile/clock-r8a7779.c
@@ -112,7 +112,7 @@ static struct clk *main_clks[] = {
 };
 
 enum { MSTP323, MSTP322, MSTP321, MSTP320,
-	MSTP115,
+	MSTP115, MSTP114,
 	MSTP103, MSTP101, MSTP100,
 	MSTP030,
 	MSTP029, MSTP028, MSTP027, MSTP026, MSTP025, MSTP024, MSTP023, MSTP022, MSTP021,
@@ -126,6 +126,7 @@ static struct clk mstp_clks[MSTP_NR] = {
 	[MSTP321] = SH_CLK_MSTP32(&clkp_clk, MSTPCR3, 21, 0), /* SDHI2 */
 	[MSTP320] = SH_CLK_MSTP32(&clkp_clk, MSTPCR3, 20, 0), /* SDHI3 */
 	[MSTP115] = SH_CLK_MSTP32(&clkp_clk, MSTPCR1, 15, 0), /* SATA */
+	[MSTP114] = SH_CLK_MSTP32(&clkp_clk, MSTPCR1, 14, 0), /* Ether */
 	[MSTP103] = SH_CLK_MSTP32(&clks_clk, MSTPCR1,  3, 0), /* DU */
 	[MSTP101] = SH_CLK_MSTP32(&clkp_clk, MSTPCR1,  1, 0), /* USB2 */
 	[MSTP100] = SH_CLK_MSTP32(&clkp_clk, MSTPCR1,  0, 0), /* USB0/1 */
@@ -162,6 +163,7 @@ static struct clk_lookup lookups[] = {
 	/* MSTP32 clocks */
 	CLKDEV_DEV_ID("sata_rcar", &mstp_clks[MSTP115]), /* SATA */
 	CLKDEV_DEV_ID("fc600000.sata", &mstp_clks[MSTP115]), /* SATA w/DT */
+	CLKDEV_DEV_ID("sh-eth", &mstp_clks[MSTP114]), /* Ether */
 	CLKDEV_DEV_ID("ehci-platform.1", &mstp_clks[MSTP101]), /* USB EHCI port2 */
 	CLKDEV_DEV_ID("ohci-platform.1", &mstp_clks[MSTP101]), /* USB OHCI port2 */
 	CLKDEV_DEV_ID("ehci-platform.0", &mstp_clks[MSTP100]), /* USB EHCI port0/1 */
diff --git a/arch/arm/mach-shmobile/include/mach/r8a7779.h b/arch/arm/mach-shmobile/include/mach/r8a7779.h
index af38750..b58a1f02 100644
--- a/arch/arm/mach-shmobile/include/mach/r8a7779.h
+++ b/arch/arm/mach-shmobile/include/mach/r8a7779.h
@@ -3,6 +3,7 @@
 
 #include <linux/sh_clk.h>
 #include <linux/pm_domain.h>
+#include <linux/sh_eth.h>
 
 /* Pin Function Controller:
  * GPIO_FN_xx - GPIO used to select pin function
@@ -352,6 +353,7 @@ extern void r8a7779_earlytimer_init(void);
 extern void r8a7779_add_early_devices(void);
 extern void r8a7779_add_standard_devices(void);
 extern void r8a7779_add_standard_devices_dt(void);
+extern void r8a7779_add_ether_device(struct sh_eth_plat_data *pdata);
 extern void r8a7779_clock_init(void);
 extern void r8a7779_pinmux_init(void);
 extern void r8a7779_pm_init(void);
diff --git a/arch/arm/mach-shmobile/setup-r8a7779.c b/arch/arm/mach-shmobile/setup-r8a7779.c
index 042df35..689ce67 100644
--- a/arch/arm/mach-shmobile/setup-r8a7779.c
+++ b/arch/arm/mach-shmobile/setup-r8a7779.c
@@ -1,8 +1,9 @@
 /*
  * r8a7779 processor support
  *
- * Copyright (C) 2011  Renesas Solutions Corp.
+ * Copyright (C) 2011, 2013  Renesas Solutions Corp.
  * Copyright (C) 2011  Magnus Damm
+ * Copyright (C) 2013  Cogent Embedded, Inc.
  *
  * 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
@@ -347,6 +348,18 @@ static struct platform_device sata_device = {
 	},
 };
 
+/* Ether */
+static struct resource ether_resources[] = {
+	{
+		.start	= 0xfde00000,
+		.end	= 0xfde003ff,
+		.flags	= IORESOURCE_MEM,
+	}, {
+		.start	= gic_iid(0xb4),
+		.flags	= IORESOURCE_IRQ,
+	},
+};
+
 static struct platform_device *r8a7779_devices_dt[] __initdata = {
 	&scif0_device,
 	&scif1_device,
@@ -382,6 +395,14 @@ void __init r8a7779_add_standard_devices(void)
 			    ARRAY_SIZE(r8a7779_late_devices));
 }
 
+void __init r8a7779_add_ether_device(struct sh_eth_plat_data *pdata)
+{
+	platform_device_register_resndata(&platform_bus, "sh_eth", -1,
+					  ether_resources,
+					  ARRAY_SIZE(ether_resources),
+					  pdata, sizeof(*pdata));
+}
+
 /* do nothing for !CONFIG_SMP or !CONFIG_HAVE_TWD */
 void __init __weak r8a7779_register_twd(void) { }
 
-- 
1.7.10.4



From horms+renesas at verge.net.au  Thu Apr  4 22:57:48 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri,  5 Apr 2013 11:57:48 +0900
Subject: [PATCH 1/2] ARM: shmobile: r8a7779: add each clocks ratio on comment
 area
In-Reply-To: <1365130669-11662-1-git-send-email-horms+renesas@verge.net.au>
References: <1365130669-11662-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1365130669-11662-2-git-send-email-horms+renesas@verge.net.au>

From: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>

Adding comment describing the r8a7779 clock frequencies depending on
MD pin settings.

Acked-by: Magnus Damm <damm at opensource.se>
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/clock-r8a7779.c |   19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/arch/arm/mach-shmobile/clock-r8a7779.c b/arch/arm/mach-shmobile/clock-r8a7779.c
index 7d86bfb..5436b51 100644
--- a/arch/arm/mach-shmobile/clock-r8a7779.c
+++ b/arch/arm/mach-shmobile/clock-r8a7779.c
@@ -26,6 +26,25 @@
 #include <mach/clock.h>
 #include <mach/common.h>
 
+/*
+ *		MD1 = 1			MD1 = 0
+ *		(PLLA = 1500)		(PLLA = 1600)
+ *		(MHz)			(MHz)
+ *------------------------------------------------+--------------------
+ * clkz		1000   (2/3)		800   (1/2)
+ * clkzs	 250   (1/6)		200   (1/8)
+ * clki		 750   (1/2)		800   (1/2)
+ * clks		 250   (1/6)		200   (1/8)
+ * clks1	 125   (1/12)		100   (1/16)
+ * clks3	 187.5 (1/8)		200   (1/8)
+ * clks4	  93.7 (1/16)		100   (1/16)
+ * clkp		  62.5 (1/24)		 50   (1/32)
+ * clkg		  62.5 (1/24)		 66.6 (1/24)
+ * clkb, CLKOUT
+ * (MD2 = 0)	  62.5 (1/24)		 66.6 (1/24)
+ * (MD2 = 1)	  41.6 (1/36)		 50   (1/32)
+*/
+
 #define MD(nr)	BIT(nr)
 
 #define FRQMR		IOMEM(0xffc80014)
-- 
1.7.10.4



From horms+renesas at verge.net.au  Thu Apr  4 23:04:30 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri,  5 Apr 2013 12:04:30 +0900
Subject: [PATCH 2/2] ARM: shmobile: bockw: enable network settings on bootargs
In-Reply-To: <1365131070-13142-1-git-send-email-horms+renesas@verge.net.au>
References: <1365131070-13142-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1365131070-13142-3-git-send-email-horms+renesas@verge.net.au>

From: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>

"ip" and "root" settings are useful for development

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Acked-by: Magnus Damm <damm at opensource.se>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7778-bockw.dts |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/r8a7778-bockw.dts b/arch/arm/boot/dts/r8a7778-bockw.dts
index 735c964..0076b1e 100644
--- a/arch/arm/boot/dts/r8a7778-bockw.dts
+++ b/arch/arm/boot/dts/r8a7778-bockw.dts
@@ -22,7 +22,7 @@
 	compatible = "renesas,bockw", "renesas,r8a7778";
 
 	chosen {
-		bootargs = "console=ttySC0,115200 ignore_loglevel";
+		bootargs = "console=ttySC0,115200 ignore_loglevel ip=dhcp root=/dev/nfs";
 	};
 
 	memory {
-- 
1.7.10.4



From horms+renesas at verge.net.au  Thu Apr  4 23:04:28 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri,  5 Apr 2013 12:04:28 +0900
Subject: [GIT PULL] Renesas ARM-based SoC bockw board updates for v3.10
Message-ID: <1365131070-13142-1-git-send-email-horms+renesas@verge.net.au>

Hi Olof, Hi Arnd,

The following changes since commit 5e3780ba6dded2636c939549e3bea16d736859fb:

  Merge branch 'soc-r8a7778' into boards-bockw-base (2013-04-05 11:32:38 +0900)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas tags/renesas-boards-bockw-for-v3.10

for you to fetch changes up to 446ee9b2d813a9378e304008fc433ce543ca68a1:

  ARM: shmobile: bockw: enable network settings on bootargs (2013-04-05 11:32:53 +0900)

----------------------------------------------------------------
Renesas ARM-based SoC bockw board updates for v3.10

Add SMSC ethernet support to the bockw board.

This pull request is based on a merge of:
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git renesas-soc-r8a7778-for-v3.10
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git renesas-boards3-for-v3.10

The reason for merging with renesas-soc-r8a7778-for-v3.10 is
to provide pre-requisite SoC code to configure IRQ pins for the
SMSC ethernet.

----------------------------------------------------------------
Kuninori Morimoto (2):
      ARM: shmobile: bockw: add SMSC ethernet support
      ARM: shmobile: bockw: enable network settings on bootargs

 arch/arm/boot/dts/r8a7778-bockw.dts  |    2 +-
 arch/arm/mach-shmobile/Kconfig       |    1 +
 arch/arm/mach-shmobile/board-bockw.c |   38 ++++++++++++++++++++++++++++++++++
 3 files changed, 40 insertions(+), 1 deletion(-)


From horms+renesas at verge.net.au  Thu Apr  4 23:04:29 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri,  5 Apr 2013 12:04:29 +0900
Subject: [PATCH 1/2] ARM: shmobile: bockw: add SMSC ethernet support
In-Reply-To: <1365131070-13142-1-git-send-email-horms+renesas@verge.net.au>
References: <1365131070-13142-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1365131070-13142-2-git-send-email-horms+renesas@verge.net.au>

From: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>

This patch adds SMSC ethernet support on Bock-W

Bock-W SMSC needs FPGA settings which enables interrupt.
This patch does it on bockw_init() function.
As notes for future, this FPGA settings should be updated,
since this FPGA is using cascaded interrupt.
Current code is assuming that this FPGA interrupt user is only SMSC.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Acked-by: Magnus Damm <damm at opensource.se>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/Kconfig       |    1 +
 arch/arm/mach-shmobile/board-bockw.c |   38 ++++++++++++++++++++++++++++++++++
 2 files changed, 39 insertions(+)

diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index 549e059..1a517e2 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -133,6 +133,7 @@ config MACH_BOCKW
 	bool "BOCK-W platform"
 	depends on ARCH_R8A7778
 	select ARCH_REQUIRE_GPIOLIB
+	select RENESAS_INTC_IRQPIN
 	select USE_OF
 
 config MACH_MARZEN
diff --git a/arch/arm/mach-shmobile/board-bockw.c b/arch/arm/mach-shmobile/board-bockw.c
index 56ab56e..38e5e50 100644
--- a/arch/arm/mach-shmobile/board-bockw.c
+++ b/arch/arm/mach-shmobile/board-bockw.c
@@ -19,14 +19,52 @@
  */
 
 #include <linux/platform_device.h>
+#include <linux/smsc911x.h>
 #include <mach/common.h>
+#include <mach/irqs.h>
 #include <mach/r8a7778.h>
 #include <asm/mach/arch.h>
 
+static struct smsc911x_platform_config smsc911x_data = {
+	.irq_polarity	= SMSC911X_IRQ_POLARITY_ACTIVE_LOW,
+	.irq_type	= SMSC911X_IRQ_TYPE_PUSH_PULL,
+	.flags		= SMSC911X_USE_32BIT,
+	.phy_interface	= PHY_INTERFACE_MODE_MII,
+};
+
+static struct resource smsc911x_resources[] = {
+	DEFINE_RES_MEM(0x18300000, 0x1000),
+	DEFINE_RES_IRQ(irq_pin(0)), /* IRQ 0 */
+};
+
+#define IRQ0MR	0x30
 static void __init bockw_init(void)
 {
+	void __iomem *fpga;
+
 	r8a7778_clock_init();
+	r8a7778_init_irq_extpin(1);
 	r8a7778_add_standard_devices();
+
+	fpga = ioremap_nocache(0x18200000, SZ_1M);
+	if (fpga) {
+		/*
+		 * CAUTION
+		 *
+		 * IRQ0/1 is cascaded interrupt from FPGA.
+		 * it should be cared in the future
+		 * Now, it is assuming IRQ0 was used only from SMSC.
+		 */
+		u16 val = ioread16(fpga + IRQ0MR);
+		val &= ~(1 << 4); /* enable SMSC911x */
+		iowrite16(val, fpga + IRQ0MR);
+		iounmap(fpga);
+
+		platform_device_register_resndata(
+			&platform_bus, "smsc911x", -1,
+			smsc911x_resources, ARRAY_SIZE(smsc911x_resources),
+			&smsc911x_data, sizeof(smsc911x_data));
+	}
 }
 
 static const char *bockw_boards_compat_dt[] __initdata = {
-- 
1.7.10.4



From horms at verge.net.au  Thu Apr  4 23:08:07 2013
From: horms at verge.net.au (Simon Horman)
Date: Fri, 5 Apr 2013 12:08:07 +0900
Subject: [RFC/PATCH 0/7] ARCH: shmobile: defconfig consolidation
In-Reply-To: <1365046193-19369-1-git-send-email-horms+renesas@verge.net.au>
References: <1365046193-19369-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <20130405030805.GA13760@verge.net.au>

On Thu, Apr 04, 2013 at 12:29:46PM +0900, Simon Horman wrote:
> Hi,
> 
> this is a first pass at consolidating the defconfigs of shmobile.
> 
> It covers the mackerel, amradillo800eva and kzm9d boards which meet
> the following criteria:
> 
> * Have the same base memory address (0x40000000).
> * Work with RUNTIME_PM, it is desirable to have that a common defconfig
> * Are booted via DT, enabling the command line to be supplied in the dts.
>   This is important to allow serial console and early printk settings,
>   which vary wildly between boards, to be supplied.
> * Boards I have to test.
>   This didn't eliminate any candidates that met the above criteria.
> 
> I believe it should also be possible to add support for the APE6EVM
> board to the consolidated defconfig once problems with RUNTIME_PM
> have been isolated and resolved. I have send an email about this
> in a separate thread "APE6EVM and Runtime PM".
> 
> I believe it may be possible to add support for the lager board
> to the consolidated defconfig once I am able to bring that board up,
> which should be rather soon. The lager board does not currently
> have a defconfig.
> 
> Morimoto-san, I suspect it may be possible to add support for the
> bockw board to the consolidated defconfig if its boot loader supports
> booting using a zImage. In this case even though the base memory address
> is not the same as the boards above it should be possible to specify
> the base address from the boot loader. As I do not have a bockw board
> I am wondering if you could investigate this.
> 
> Simon Horman (7):
>   ARM: shmobile: prune defconfig
>   ARM: shmobile: make defconfig canonical
>   ARM: shmobile: Add kzm9d to consolidated defconfig
>   ARM: shmobile: Add mackerel to consolidated defconfig
>   ARM: shmobile: defconfig: Remove armadillo800eva defconfig
>   ARM: shmobile: defconfig: Remove kzm9d defconfig
>   ARM: shmobile: defconfig: Remove mackerel defconfig
> 
>  arch/arm/configs/armadillo800eva_defconfig |  153 ---------------------------
>  arch/arm/configs/kzm9d_defconfig           |   88 ----------------
>  arch/arm/configs/mackerel_defconfig        |  156 ----------------------------
>  arch/arm/configs/shmobile_defconfig        |   51 +++++----
>  4 files changed, 28 insertions(+), 420 deletions(-)
>  delete mode 100644 arch/arm/configs/armadillo800eva_defconfig
>  delete mode 100644 arch/arm/configs/kzm9d_defconfig
>  delete mode 100644 arch/arm/configs/mackerel_defconfig

Magnus,

ideally I would like to queue-up this series and request
it be included in v3.10 as a path to add defconfig support for the lager
baord (added as an 8th patch after my original posting of the series).

Can I get some feedback from you?



From festevam at gmail.com  Thu Apr  4 23:39:46 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Fri, 5 Apr 2013 00:39:46 -0300
Subject: [PATCH v4 2/2] video: mxsfb: Use devm_regulator_get()
In-Reply-To: <1365128456-8762-2-git-send-email-festevam@gmail.com>
References: <1365128456-8762-1-git-send-email-festevam@gmail.com>
 <1365128456-8762-2-git-send-email-festevam@gmail.com>
Message-ID: <CAOMZO5AzgQTbx=6mk+1Uxw6CCiYecXzwy9NeusvUNF3Ha8q9=g@mail.gmail.com>

On Thu, Apr 4, 2013 at 11:20 PM, Fabio Estevam <festevam at gmail.com> wrote:
> From: Fabio Estevam <fabio.estevam at freescale.com>
>
> Instead of using a custom binding for retrieving the GPIO that activates the
> LCD from devicetree, use the standard devm_regulator_get().
>
> This approach has the advantage to be more generic.
>
> For example: in the case of a board that has a PMIC supplying the LCD voltage,
> the current approach would not work, as it only searches for a GPIO pin.
>
> Cc: Florian Tobias Schandinat <FlorianSchandinat at gmx.de>
> Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
> ---
> Changes since v3:
> - None
> Changes since v2:
> - Use devm_regulator_get()
> Changes since v1:
> - No changes
>  drivers/video/mxsfb.c |   19 ++++++-------------
>  1 file changed, 6 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/video/mxsfb.c b/drivers/video/mxsfb.c
> index eac7c1a..c536887 100644
> --- a/drivers/video/mxsfb.c
> +++ b/drivers/video/mxsfb.c
> @@ -42,7 +42,6 @@
>  #include <linux/module.h>
>  #include <linux/kernel.h>
>  #include <linux/of_device.h>
> -#include <linux/of_gpio.h>
>  #include <video/of_display_timing.h>
>  #include <linux/platform_device.h>
>  #include <linux/clk.h>
> @@ -51,6 +50,7 @@
>  #include <linux/pinctrl/consumer.h>
>  #include <linux/fb.h>
>  #include <video/videomode.h>
> +#include <linux/regulator/consumer.h>
>
>  #define REG_SET        4
>  #define REG_CLR        8
> @@ -859,9 +859,8 @@ static int mxsfb_probe(struct platform_device *pdev)
>         struct fb_info *fb_info;
>         struct fb_modelist *modelist;
>         struct pinctrl *pinctrl;
> -       int panel_enable;
> -       enum of_gpio_flags flags;
>         int ret;
> +       struct regulator *reg_lcd;
>
>         if (of_id)
>                 pdev->id_entry = of_id->data;
> @@ -904,18 +903,12 @@ static int mxsfb_probe(struct platform_device *pdev)
>                 goto fb_release;
>         }
>
> -       panel_enable = of_get_named_gpio_flags(pdev->dev.of_node,
> -                                              "panel-enable-gpios", 0, &flags);
> -       if (gpio_is_valid(panel_enable)) {
> -               unsigned long f = GPIOF_OUT_INIT_HIGH;
> -               if (flags == OF_GPIO_ACTIVE_LOW)
> -                       f = GPIOF_OUT_INIT_LOW;
> -               ret = devm_gpio_request_one(&pdev->dev, panel_enable,
> -                                           f, "panel-enable");
> +       reg_lcd = devm_regulator_get(&pdev->dev, "lcd");
> +       if (!IS_ERR(reg_lcd)) {
> +               ret = regulator_enable(reg_lcd);

I missed a regulator_disable() call. Will send a new version tomorrow.


From kuninori.morimoto.gx at renesas.com  Fri Apr  5 00:12:49 2013
From: kuninori.morimoto.gx at renesas.com (Kuninori Morimoto)
Date: Thu, 04 Apr 2013 21:12:49 -0700 (PDT)
Subject: [PATCH] irqchip: irqc: Add runtime PM support
In-Reply-To: <20130405022623.GD29203@verge.net.au>
References: <1365056466-23710-1-git-send-email-horms+renesas@verge.net.au>
 <20130405022623.GD29203@verge.net.au>
Message-ID: <87sj35k43m.wl%kuninori.morimoto.gx@renesas.com>


Hi

> On Thu, Apr 04, 2013 at 03:21:06PM +0900, Simon Horman wrote:
> > This was tested using the SMSC LAN on the APE6EVM board.
> > 
> > Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
> 
> Magnus, Morimoto-san, could you review this?

Acked-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>

> 
> > ---
> >  drivers/irqchip/irq-renesas-irqc.c |    8 ++++++++
> >  1 file changed, 8 insertions(+)
> > 
> > diff --git a/drivers/irqchip/irq-renesas-irqc.c b/drivers/irqchip/irq-renesas-irqc.c
> > index 927bff3..649cd69 100644
> > --- a/drivers/irqchip/irq-renesas-irqc.c
> > +++ b/drivers/irqchip/irq-renesas-irqc.c
> > @@ -19,6 +19,7 @@
> >  
> >  #include <linux/init.h>
> >  #include <linux/platform_device.h>
> > +#include <linux/pm_runtime.h>
> >  #include <linux/spinlock.h>
> >  #include <linux/interrupt.h>
> >  #include <linux/ioport.h>
> > @@ -181,6 +182,9 @@ static int irqc_probe(struct platform_device *pdev)
> >  		goto err1;
> >  	}
> >  
> > +	pm_runtime_enable(&pdev->dev);
> > +	pm_runtime_get_sync(&pdev->dev);
> > +
> >  	/* allow any number of IRQs between 1 and IRQC_IRQ_MAX */
> >  	for (k = 0; k < IRQC_IRQ_MAX; k++) {
> >  		irq = platform_get_resource(pdev, IORESOURCE_IRQ, k);
> > @@ -255,6 +259,8 @@ err3:
> >  err2:
> >  	iounmap(p->iomem);
> >  err1:
> > +	pm_runtime_put_sync(&pdev->dev);
> > +	pm_runtime_disable(&pdev->dev);
> >  	kfree(p);
> >  err0:
> >  	return ret;
> > @@ -270,6 +276,8 @@ static int irqc_remove(struct platform_device *pdev)
> >  
> >  	irq_domain_remove(p->irq_domain);
> >  	iounmap(p->iomem);
> > +	pm_runtime_put_sync(&pdev->dev);
> > +	pm_runtime_disable(&pdev->dev);
> >  	kfree(p);
> >  	return 0;
> >  }
> > -- 
> > 1.7.10.4
> > 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


Best regards
---
Kuninori Morimoto


From aletes.xgr at gmail.com  Fri Apr  5 00:16:53 2013
From: aletes.xgr at gmail.com (Alexandre Pereira da Silva)
Date: Fri,  5 Apr 2013 01:16:53 -0300
Subject: [PATCH] ARM: dts: imx23-olinuxino: Set the sdcard as non-removable
Message-ID: <1365135413-31493-1-git-send-email-aletes.xgr@gmail.com>

The imx23-olinuxino sdcard doesn't support card detect.

Signed-off-by: Alexandre Pereira da Silva <aletes.xgr at gmail.com>
---
 arch/arm/boot/dts/imx23-olinuxino.dts |    1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/imx23-olinuxino.dts b/arch/arm/boot/dts/imx23-olinuxino.dts
index e7484e4..03f55c2 100644
--- a/arch/arm/boot/dts/imx23-olinuxino.dts
+++ b/arch/arm/boot/dts/imx23-olinuxino.dts
@@ -29,6 +29,7 @@
 				pinctrl-names = "default";
 				pinctrl-0 = <&mmc0_4bit_pins_a &mmc0_pins_fixup>;
 				bus-width = <4>;
+				non-removable;
 				status = "okay";
 			};
 
-- 
1.7.10



From sfr at canb.auug.org.au  Fri Apr  5 00:33:35 2013
From: sfr at canb.auug.org.au (Stephen Rothwell)
Date: Fri, 5 Apr 2013 15:33:35 +1100
Subject: linux-next: manual merge of the arm-soc tree with the xilinx tree
Message-ID: <20130405153335.baf29606a97b1bee415f3546@canb.auug.org.au>

Hi all,

Today's linux-next merge of the arm-soc tree got a conflict in
arch/arm/mach-spear/spear13xx.c between commit c79e33b3e828 ("ARM:
smp_twd: convert to use CLKSRC_OF init") from the xilinx tree and commit
2b9c613c4ee1 ("ARM: spear: move generic.h and pl080.h into private dir")
from the arm-soc tree.

I fixed it up (just used the arm-soc tree version) and can carry the fix
as necessary (no action is required).

-- 
Cheers,
Stephen Rothwell                    sfr at canb.auug.org.au
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130405/f6f9d41f/attachment-0001.sig>

From sfr at canb.auug.org.au  Fri Apr  5 00:34:53 2013
From: sfr at canb.auug.org.au (Stephen Rothwell)
Date: Fri, 5 Apr 2013 15:34:53 +1100
Subject: linux-next: manual merge of the arm-soc tree with the xilinx tree
In-Reply-To: <20130405153335.baf29606a97b1bee415f3546@canb.auug.org.au>
References: <20130405153335.baf29606a97b1bee415f3546@canb.auug.org.au>
Message-ID: <20130405153453.75b76d68fe9adc6e981e02fb@canb.auug.org.au>

Hi all,

On Fri, 5 Apr 2013 15:33:35 +1100 Stephen Rothwell <sfr at canb.auug.org.au> wrote:
>
> Today's linux-next merge of the arm-soc tree got a conflict in
> arch/arm/mach-spear/spear13xx.c between commit c79e33b3e828 ("ARM:
> smp_twd: convert to use CLKSRC_OF init") from the xilinx tree and commit
> 2b9c613c4ee1 ("ARM: spear: move generic.h and pl080.h into private dir")
> from the arm-soc tree.

BTW, that xilinx tree commit has no "Signed-off-by" for the committer ...
-- 
Cheers,
Stephen Rothwell                    sfr at canb.auug.org.au
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130405/bdfc4265/attachment.sig>

From sfr at canb.auug.org.au  Fri Apr  5 00:39:04 2013
From: sfr at canb.auug.org.au (Stephen Rothwell)
Date: Fri, 5 Apr 2013 15:39:04 +1100
Subject: linux-next: manual merge of the arm-soc tree with the xilinx tree
In-Reply-To: <20130405153335.baf29606a97b1bee415f3546@canb.auug.org.au>
References: <20130405153335.baf29606a97b1bee415f3546@canb.auug.org.au>
Message-ID: <20130405153904.1fd5af8086cfede917c353af@canb.auug.org.au>

On Fri, 5 Apr 2013 15:33:35 +1100 Stephen Rothwell <sfr at canb.auug.org.au> wrote:
>

The copy to "John Linn <John.Linn at xilinx.com>" (my listed contact for the
xilinx tree) bounced.  Who should I use now?
-- 
Cheers,
Stephen Rothwell                    sfr at canb.auug.org.au
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130405/ce9ab3a4/attachment.sig>

From sfr at canb.auug.org.au  Fri Apr  5 01:02:56 2013
From: sfr at canb.auug.org.au (Stephen Rothwell)
Date: Fri, 5 Apr 2013 16:02:56 +1100
Subject: linux-next: manual merge of the samsung tree with the arm-soc tree
Message-ID: <20130405160256.7ca6f52e25e0d2231eb1fcfe@canb.auug.org.au>

Hi Kukjin,

Today's linux-next merge of the samsung tree got a conflict in
drivers/irqchip/irq-s3c24xx.c between commit de88cbb7b244 ("arm: Move
chained_irq_(enter|exit) to a generic file") from the arm-soc tree (where
it is called arch/arm/mach-s3c24xx/irq.c) and commit f0774d41da0e
("irqchip: s3c24xx: add devicetree support") from the samsung tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr at canb.auug.org.au

diff --cc drivers/irqchip/irq-s3c24xx.c
index 8296d94,5e40b34..0000000
--- a/drivers/irqchip/irq-s3c24xx.c
+++ b/drivers/irqchip/irq-s3c24xx.c
@@@ -25,8 -25,11 +25,12 @@@
  #include <linux/ioport.h>
  #include <linux/device.h>
  #include <linux/irqdomain.h>
 +#include <linux/irqchip/chained_irq.h>
+ #include <linux/of.h>
+ #include <linux/of_irq.h>
+ #include <linux/of_address.h>
  
+ #include <asm/exception.h>
  #include <asm/mach/irq.h>
  
  #include <mach/regs-irq.h>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130405/d09ba861/attachment.sig>

From nm at ti.com  Fri Apr  5 01:09:42 2013
From: nm at ti.com (Nishanth Menon)
Date: Fri, 5 Apr 2013 00:09:42 -0500
Subject: regulator: query on regulator re-entrance
Message-ID: <1365138582-10409-1-git-send-email-nm@ti.com>

Hi Liam, Mark,
TI platforms typically use Adaptive Voltage Scaling technique to determine
an optimal voltage on top of the traditional DVFS strategy to optimize power.

Depending on the SoC, we use AVS class 0, 1, 1.5, 2, 3. In general,
the AVS strategy is pretty much like a regulator which then gives command
to the PMIC for the optimal voltage to choose.

For example, on AM335x(beaglebone) platform, we use AVS class 2 strategy.
Ref[1]
If we ignore the details of the class 1.5 implementation, we will notice
a) regulator set_voltage equivalent set_voltage() is required.
b) this set_voltage does some 'magic stuff' depending on the SoC and AVS class
and calls the 'real regulator' which talks to the PMIC over i2c/spi etc..
in short the call sequence is more or less:

driver (cpufreq) -> AVS -> PMIC regulator.

By modeling AVS class drivers as an regulator, we then do not need to introduce
SoC specific hacks and APIs.
driver (cpufreq) -> AVS regulator -> PMIC regulator.
However, we then need ability to have regulator calls while in the context of
another regulator. Taking this to the next level we might want to chain
multiple regulators as well (example of additional strategy of ABB discussed
here[2]).

In short, an regulator which is also an consumer.

As a proof of concept, I wrote up a dummy AVS class 2 driver (without AVS
functionality)[3] - result is an lockdep warning[4].

I believe there'd be other similar user's who might find it useful to have
regulator chaining. However, considering that regulator framework has
been around for a while, the generic question is: are we ok to allow for
changes to let regulators be re-enterant? If this is interesting, then, I
am curious to know if there are any attempts to do this already in progress.
If interesting and no attempts, then we'd be interested in collaborating for it.

Ref:
[1] https://github.com/Angstrom-distribution/meta-ti/blob/master/recipes-kernel/linux/linux-am335x-3.2.0-psp04.06.00.08/0001-am33xx-Add-SmartReflex-support.patch
[2] http://marc.info/?t=136483993400003&r=1&w=2
[3] http://pastebin.com/yttSEQ0j
[4] lockdep warning
/sys/devices/system/cpu/cpu0/cpufreq # cat scaling_available_frequencies
300000 600000 800000 
/sys/devices/system/cpu/cpu0/cpufreq # echo -n "300000">scaling_setspeed
[   28.409606] 
[   28.411193] =============================================
[   28.416900] [ INFO: possible recursive locking detected ]
[   28.422607] 3.9.0-rc3-00064-g5e75410-dirty #39 Not tainted
[   28.428375] ---------------------------------------------
[   28.434082] sh/782 is trying to acquire lock:
[   28.438690]  (&rdev->mutex){+.+.+.}, at: [<c033e5d8>] regulator_get_voltage+0x18/0x38
[   28.447021] 
[   28.447021] but task is already holding lock:
[   28.453186]  (&rdev->mutex){+.+.+.}, at: [<c033e5d8>] regulator_get_voltage+0x18/0x38
[   28.461486] 
[   28.461486] other info that might help us debug this:
[   28.468414]  Possible unsafe locking scenario:
[   28.468414] 
[   28.474670]        CPU0
[   28.477264]        ----
[   28.479858]   lock(&rdev->mutex);
[   28.483367]   lock(&rdev->mutex);
[   28.486877] 
[   28.486877]  *** DEADLOCK ***
[   28.486877] 
[   28.493164]  May be due to missing lock nesting notation
[   28.493164] 
[   28.500335] 5 locks held by sh/782:
[   28.504028]  #0:  (&buffer->mutex){+.+.+.}, at: [<c01951a8>] sysfs_write_file+0x28/0xb4
[   28.512573]  #1:  (s_active#4){.+.+.+}, at: [<c01951dc>] sysfs_write_file+0x5c/0xb4
[   28.520721]  #2:  (&per_cpu(cpu_policy_rwsem, cpu)){++++..}, at: [<c0453260>] lock_policy_rwsem_write+0x30/0x44
[   28.531463]  #3:  (userspace_mutex){+.+...}, at: [<c045597c>] cpufreq_set+0x28/0xc8
[   28.539611]  #4:  (&rdev->mutex){+.+.+.}, at: [<c033e5d8>] regulator_get_voltage+0x18/0x38
[   28.548400] 
[   28.548400] stack backtrace:
[   28.553070] [<c001bc84>] (unwind_backtrace+0x0/0x130) from [<c009f4f0>] (print_deadlock_bug+0xcc/0xfc)
[   28.562927] [<c009f4f0>] (print_deadlock_bug+0xcc/0xfc) from [<c00a0d08>] (validate_chain.isra.27+0x3cc/0x67c)
[   28.573516] [<c00a0d08>] (validate_chain.isra.27+0x3cc/0x67c) from [<c00a3ce4>] (__lock_acquire+0x420/0xa24)
[   28.583923] [<c00a3ce4>] (__lock_acquire+0x420/0xa24) from [<c00a49dc>] (lock_acquire+0x9c/0x1f4)
[   28.593322] [<c00a49dc>] (lock_acquire+0x9c/0x1f4) from [<c058863c>] (mutex_lock_nested+0x78/0x3a0)
[   28.602874] [<c058863c>] (mutex_lock_nested+0x78/0x3a0) from [<c033e5d8>] (regulator_get_voltage+0x18/0x38)
[   28.613189] [<c033e5d8>] (regulator_get_voltage+0x18/0x38) from [<c033e0f0>] (_regulator_get_voltage+0x68/0x84)
[   28.623840] [<c033e0f0>] (_regulator_get_voltage+0x68/0x84) from [<c033e5e0>] (regulator_get_voltage+0x20/0x38)
[   28.634490] [<c033e5e0>] (regulator_get_voltage+0x20/0x38) from [<c0457d28>] (cpu0_set_target+0x184/0x490)
[   28.644714] [<c0457d28>] (cpu0_set_target+0x184/0x490) from [<c045284c>] (__cpufreq_driver_target+0x88/0xb8)
[   28.655090] [<c045284c>] (__cpufreq_driver_target+0x88/0xb8) from [<c04559dc>] (cpufreq_set+0x88/0xc8)
[   28.664916] [<c04559dc>] (cpufreq_set+0x88/0xc8) from [<c0452938>] (store_scaling_setspeed+0x5c/0x74)
[   28.674652] [<c0452938>] (store_scaling_setspeed+0x5c/0x74) from [<c0453308>] (store+0x5c/0x84)
[   28.683868] [<c0453308>] (store+0x5c/0x84) from [<c0195200>] (sysfs_write_file+0x80/0xb4)
[   28.692504] [<c0195200>] (sysfs_write_file+0x80/0xb4) from [<c012b0b4>] (vfs_write+0xa8/0x138)
[   28.701599] [<c012b0b4>] (vfs_write+0xa8/0x138) from [<c012b320>] (sys_write+0x40/0x68)
[   28.710052] [<c012b320>] (sys_write+0x40/0x68) from [<c0013d60>] (ret_fast_syscall+0x0/0x3c)

Cc: Greg Guyotte <gguyotte at ti.com>
Cc: Ulf Hansson <ulf.hansson at linaro.org>
Cc: linux-omap <linux-omap at vger.kernel.org>
Cc: linux-arm <linux-arm-kernel at lists.infradead.org>
Cc: lkml <linux-kernel at vger.kernel.org>

Regards,
Nishanth Menon


From sboyd at codeaurora.org  Fri Apr  5 01:11:24 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Thu, 04 Apr 2013 22:11:24 -0700
Subject: [PATCH] ARM: arch_timer: Silence debug preempt warnings
In-Reply-To: <1364934672-31554-1-git-send-email-sboyd@codeaurora.org>
References: <1364934672-31554-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <515E5CFC.4090900@codeaurora.org>

On 4/2/2013 1:31 PM, Stephen Boyd wrote:
> Hot-plugging with CONFIG_DEBUG_PREEMPT=y on a device with arm
> architected timers causes a slew of "using smp_processor_id() in
> preemptible" warnings:
>
>   BUG: using smp_processor_id() in preemptible [00000000] code: sh/111
>   caller is arch_timer_cpu_notify+0x14/0xc8
>
> This happens because sometimes the cpu notifier, arch_timer_cpu_notify(),
> is called in preemptible context but we use this_cpu_ptr()
> to retrieve the clockevent unconditionally. We're only going to
> actually use the pointer in non-preemptible context though,
> so use __this_cpu_ptr() instead to avoid the preemptible checks
> and silence the warning.
>
> Cc: Mark Rutland <mark.rutland at arm.com>
> Cc: Marc Zyngier <Marc.Zyngier at arm.com>
> Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
> ---

Anyone else seeing this one?

>  drivers/clocksource/arm_arch_timer.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
> index d7ad425..5928c29 100644
> --- a/drivers/clocksource/arm_arch_timer.c
> +++ b/drivers/clocksource/arm_arch_timer.c
> @@ -248,7 +248,7 @@ static void __cpuinit arch_timer_stop(struct clock_event_device *clk)
>  static int __cpuinit arch_timer_cpu_notify(struct notifier_block *self,
>  					   unsigned long action, void *hcpu)
>  {
> -	struct clock_event_device *evt = this_cpu_ptr(arch_timer_evt);
> +	struct clock_event_device *evt = __this_cpu_ptr(arch_timer_evt);
>  
>  	switch (action & ~CPU_TASKS_FROZEN) {
>  	case CPU_STARTING:

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation



From moore at free.fr  Fri Apr  5 01:14:17 2013
From: moore at free.fr (Chris Moore)
Date: Fri, 05 Apr 2013 07:14:17 +0200
Subject: [PATCH] ARM: kirkwood: DT board setup for CloudBox
In-Reply-To: <20130405011143.GX13280@titan.lakedaemon.net>
References: <20130329184109.GA16404@kw.sim.vm.gnt> <51568B89.1060009@free.fr>
 <20130401163316.GC16404@kw.sim.vm.gnt> <515A5BC6.5000007@free.fr>
 <20130402114535.GR13280@titan.lakedaemon.net>
 <20130402125408.GH16404@kw.sim.vm.gnt>
 <20130402172454.GT13280@titan.lakedaemon.net> <515D0776.7050208@free.fr>
 <20130404080058.GJ16404@kw.sim.vm.gnt> <20130404093435.GK16404@kw.sim.vm.gnt>
 <20130405011143.GX13280@titan.lakedaemon.net>
Message-ID: <515E5DA9.1000605@free.fr>

Le 05/04/2013 03:11, Jason Cooper a ?crit :
> On Thu, Apr 04, 2013 at 11:34:35AM +0200, Simon Guinot wrote:
>>
...

>> Then we are back to the initial problem...
>>
>> Maybe we could append some suffixes based on the version:
>>
>> 1: cloudbox-v1
>> 2: cloudbox-v2
>>
>> Or better, suffix based on the other code names:
>>
>> 1: cloudbox-ns2mini
>> 2: cloudbox-familybox
>>
>> Or even let the things as they are:
>>
>> 1: netspace_v2_mini
>> 2: cloudbox
> In light of the above info, let's got with the third option.  If we
> discover a different LaCie Cloudbox board down the road, we can add an
> appropriately more specific compatible string to differentiate.  As you
> can tell, I'd prefer to have something more specific in the original
> commit, but we can only work with what we're given. :(
>

This is now OK with me.
However I would like to have a more precise description somewhere; 
probably either in the Kconfig or, if this is obsolescent, in whatever 
replaces it.
I think that someone grepping the kernel sources for the commercial name 
"CloudBox" should find both versions and be able to decide which one he has.

Cheers,
Chris



From sebastian.hesselbarth at gmail.com  Fri Apr  5 01:22:12 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Fri,  5 Apr 2013 07:22:12 +0200
Subject: [PATCH] clk: add helper to set flags for clk-provider
Message-ID: <1365139332-17775-1-git-send-email-sebastian.hesselbarth@gmail.com>

Clock providers are not allowed to mess with struct clk internals directly
but using helpers provided by clk-provider.h. This patch adds a helper to
allow to set flags of a clock after registration. This is useful, if clock
flags change during runtime, e.g. ability to set parent clock after mux
switch.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
---
Cc: Mike Turquette <mturquette at linaro.org>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
---
 drivers/clk/clk.c            |    8 ++++++++
 include/linux/clk-provider.h |    1 +
 2 files changed, 9 insertions(+)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index ed87b24..780a0c0 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -451,6 +451,14 @@ unsigned long __clk_get_flags(struct clk *clk)
 	return !clk ? 0 : clk->flags;
 }
 
+void __clk_set_flags(struct clk *clk, unsigned long flags)
+{
+	if (!clk)
+		return;
+
+	clk->flags = flags;
+}
+
 bool __clk_is_enabled(struct clk *clk)
 {
 	int ret;
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 7f197d7..e862d9c 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -351,6 +351,7 @@ unsigned int __clk_get_enable_count(struct clk *clk);
 unsigned int __clk_get_prepare_count(struct clk *clk);
 unsigned long __clk_get_rate(struct clk *clk);
 unsigned long __clk_get_flags(struct clk *clk);
+void __clk_set_flags(struct clk *clk, unsigned long flags);
 bool __clk_is_enabled(struct clk *clk);
 struct clk *__clk_lookup(const char *name);
 
-- 
1.7.10.4



From sebastian.hesselbarth at gmail.com  Fri Apr  5 01:23:35 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Fri,  5 Apr 2013 07:23:35 +0200
Subject: [PATCH v5] clk: add si5351 i2c common clock driver
In-Reply-To: <1364050010-23919-1-git-send-email-sebastian.hesselbarth@gmail.com>
References: <1364050010-23919-1-git-send-email-sebastian.hesselbarth@gmail.com>
Message-ID: <1365139415-17815-1-git-send-email-sebastian.hesselbarth@gmail.com>

This patch adds a common clock driver for Silicon Labs Si5351a/b/c
i2c programmable clock generators. Currently, the driver supports
DT kernels only and VXCO feature of si5351b is not implemented. DT
bindings selectively allow to overwrite stored Si5351 configuration
which is very helpful for clock generators with empty eeprom
configuration. Corresponding device tree binding documentation is
also added.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
Tested-by: Daniel Mack <zonque at gmail.com>
---
Changes from v4:
- move from clk-private.h to clk-provider.h (Reported by Mike Turquette)
- use __clk_set_flags() helper

Changes from v3:
- add silabs prefix to custom DT properties (Reported by Lars-Peter Clausen)
- use sizeof(*foo) instead of sizeof(struct bar) (Reported by Lars-Peter Clausen)
- check return value of of_clk_add_provider (Reported by Lars-Peter Clausen)
- clean up i2c client init (Reported by Lars-Peter Clausen)
- silence successful probe (Suggested by Lars-Peter Clausen)
- make CONFIG_CLK_SI5351 depend on CONFIG_OF

Changes from v2:
- add curly brackets to if-else-statements (Reported by Daniel Mack)
- fix div-by-zero for clk6/clk7 (Reported by Daniel Mack)
- fix parameter address calculation for clk6/clk7

Changes from v1:
- remove .is_enabled functions as they read from i2c
  (Reported by Daniel Mack)
- add CLK_SET_RATE_PARENT on clkout reparent if clkout uses
  its own multisync

Cc: Grant Likely <grant.likely at secretlab.ca>
Cc: Rob Herring <rob.herring at calxeda.com>
Cc: Rob Landley <rob at landley.net>
Cc: Mike Turquette <mturquette at linaro.org>
Cc: Stephen Warren <swarren at nvidia.com>
Cc: Thierry Reding <thierry.reding at avionic-design.de>
Cc: Dom Cobley <popcornmix at gmail.com>
Cc: Linus Walleij <linus.walleij at linaro.org>
Cc: Arnd Bergmann <arnd at arndb.de>
Cc: Andrew Morton <akpm at linux-foundation.org>
Cc: Pawel Moll <pawel.moll at arm.com>
Cc: Mark Brown <broonie at opensource.wolfsonmicro.com>
Cc: Russell King - ARM Linux <linux at arm.linux.org.uk>
Cc: Rabeeh Khoury <rabeeh at solid-run.com>
Cc: Daniel Mack <zonque at gmail.com>
Cc: Jean-Francois Moine <moinejf at free.fr>
Cc: Lars-Peter Clausen <lars at metafoo.de>
Cc: devicetree-discuss at lists.ozlabs.org
Cc: linux-doc at vger.kernel.org
Cc: linux-kernel at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
---
 .../devicetree/bindings/clock/silabs,si5351.txt    |  114 ++
 .../devicetree/bindings/vendor-prefixes.txt        |    1 +
 drivers/clk/Kconfig                                |   10 +
 drivers/clk/Makefile                               |    1 +
 drivers/clk/clk-si5351.c                           | 1429 ++++++++++++++++++++
 drivers/clk/clk-si5351.h                           |  155 +++
 6 files changed, 1710 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/silabs,si5351.txt
 create mode 100644 drivers/clk/clk-si5351.c
 create mode 100644 drivers/clk/clk-si5351.h

diff --git a/Documentation/devicetree/bindings/clock/silabs,si5351.txt b/Documentation/devicetree/bindings/clock/silabs,si5351.txt
new file mode 100644
index 0000000..cc37465
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/silabs,si5351.txt
@@ -0,0 +1,114 @@
+Binding for Silicon Labs Si5351a/b/c programmable i2c clock generator.
+
+Reference
+[1] Si5351A/B/C Data Sheet
+    http://www.silabs.com/Support%20Documents/TechnicalDocs/Si5351.pdf
+
+The Si5351a/b/c are programmable i2c clock generators with upto 8 output
+clocks. Si5351a also has a reduced pin-count package (MSOP10) where only
+3 output clocks are accessible. The internal structure of the clock
+generators can be found in [1].
+
+==I2C device node==
+
+Required properties:
+- compatible: shall be one of "silabs,si5351{a,a-msop,b,c}".
+- reg: i2c device address, shall be 0x60 or 0x61.
+- #clock-cells: from common clock binding; shall be set to 1.
+- clocks: from common clock binding; list of parent clock
+  handles, shall be xtal reference clock or xtal and clkin for
+  si5351c only.
+- #address-cells: shall be set to 1.
+- #size-cells: shall be set to 0.
+
+Optional properties:
+- silabs,pll-source: pair of (number, source) for each pll. Allows
+  to overwrite clock source of pll A (number=0) or B (number=1).
+
+==Child nodes==
+
+Each of the clock outputs can be overwritten individually by
+using a child node to the I2C device node. If a child node for a clock
+output is not set, the eeprom configuration is not overwritten.
+
+Required child node properties:
+- reg: number of clock output.
+
+Optional child node properties:
+- silabs,clock-source: source clock of the output divider stage N, shall be
+  0 = multisynth N
+  1 = multisynth 0 for output clocks 0-3, else multisynth4
+  2 = xtal
+  3 = clkin (si5351c only)
+- silabs,drive-strength: output drive strength in mA, shall be one of {2,4,6,8}.
+- silabs,multisynth-source: source pll A(0) or B(1) of corresponding multisynth
+  divider.
+- silabs,pll-master: boolean, multisynth can change pll frequency.
+
+==Example==
+
+/* 25MHz reference crystal */
+ref25: ref25M {
+	compatible = "fixed-clock";
+	#clock-cells = <0>;
+	clock-frequency = <25000000>;
+};
+
+i2c-master-node {
+
+	/* Si5351a msop10 i2c clock generator */
+	si5351a: clock-generator at 60 {
+		compatible = "silabs,si5351a-msop";
+		reg = <0x60>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		#clock-cells = <1>;
+
+		/* connect xtal input to 25MHz reference */
+		clocks = <&ref25>;
+
+		/* connect xtal input as source of pll0 and pll1 */
+		silabs,pll-source = <0 0>, <1 0>;
+
+		/*
+		 * overwrite clkout0 configuration with:
+		 * - 8mA output drive strength
+		 * - pll0 as clock source of multisynth0
+		 * - multisynth0 as clock source of output divider
+		 * - multisynth0 can change pll0
+		 * - set initial clock frequency of 74.25MHz
+		 */
+		clkout0 {
+			reg = <0>;
+			silabs,drive-strength = <8>;
+			silabs,multisynth-source = <0>;
+			silabs,clock-source = <0>;
+			silabs,pll-master;
+			clock-frequency = <74250000>;
+		};
+
+		/*
+		 * overwrite clkout1 configuration with:
+		 * - 4mA output drive strength
+		 * - pll1 as clock source of multisynth1
+		 * - multisynth1 as clock source of output divider
+		 * - multisynth1 can change pll1
+		 */
+		clkout1 {
+			reg = <1>;
+			silabs,drive-strength = <4>;
+			silabs,multisynth-source = <1>;
+			silabs,clock-source = <0>;
+			pll-master;
+		};
+
+		/*
+		 * overwrite clkout2 configuration with:
+		 * - xtal as clock source of output divider
+		 */
+		clkout2 {
+			reg = <2>;
+			silabs,clock-source = <2>;
+		};
+	};
+};
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 19e1ef7..ca60849 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -48,6 +48,7 @@ samsung	Samsung Semiconductor
 sbs	Smart Battery System
 schindler	Schindler
 sil	Silicon Image
+silabs	Silicon Laboratories
 simtek
 sirf	SiRF Technology, Inc.
 snps 	Synopsys, Inc.
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index a47e6ee..6412f55 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -55,6 +55,16 @@ config COMMON_CLK_MAX77686
 	---help---
 	  This driver supports Maxim 77686 crystal oscillator clock. 
 
+config COMMON_CLK_SI5351
+	tristate "Clock driver for SiLabs 5351A/B/C"
+	depends on I2C
+	depends on OF
+	select REGMAP_I2C
+	select RATIONAL
+	---help---
+	  This driver supports Silicon Labs 5351A/B/C programmable clock
+	  generators.
+
 config CLK_TWL6040
 	tristate "External McPDM functional clock from twl6040"
 	depends on TWL6040_CORE
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 300d477..92ca698 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -33,4 +33,5 @@ obj-$(CONFIG_X86)		+= x86/
 # Chip specific
 obj-$(CONFIG_COMMON_CLK_WM831X) += clk-wm831x.o
 obj-$(CONFIG_COMMON_CLK_MAX77686) += clk-max77686.o
+obj-$(CONFIG_COMMON_CLK_SI5351) += clk-si5351.o
 obj-$(CONFIG_CLK_TWL6040)	+= clk-twl6040.o
diff --git a/drivers/clk/clk-si5351.c b/drivers/clk/clk-si5351.c
new file mode 100644
index 0000000..e259cec
--- /dev/null
+++ b/drivers/clk/clk-si5351.c
@@ -0,0 +1,1429 @@
+/*
+ * clk-si5351.c: Silicon Laboratories Si5351A/B/C I2C Clock Generator
+ *
+ * Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
+ * Rabeeh Khoury <rabeeh at solid-run.com>
+ *
+ * References:
+ * [1] "Si5351A/B/C Data Sheet"
+ *     http://www.silabs.com/Support%20Documents/TechnicalDocs/Si5351.pdf
+ * [2] "Manually Generating an Si5351 Register Map"
+ *     http://www.silabs.com/Support%20Documents/TechnicalDocs/AN619.pdf
+ *
+ * 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.
+ */
+
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/clk-provider.h>
+#include <linux/clkdev.h>
+#include <linux/delay.h>
+#include <linux/err.h>
+#include <linux/errno.h>
+#include <linux/rational.h>
+#include <linux/i2c.h>
+#include <linux/of_platform.h>
+#include <linux/regmap.h>
+#include <linux/slab.h>
+#include <linux/string.h>
+#include <asm/div64.h>
+
+#include "clk-si5351.h"
+
+enum si5351_variant {
+	SI5351_VARIANT_A = 1,
+	SI5351_VARIANT_A3 = 2,
+	SI5351_VARIANT_B = 3,
+	SI5351_VARIANT_C = 4,
+};
+
+struct si5351_driver_data;
+
+struct si5351_parameters {
+	unsigned long	p1;
+	unsigned long	p2;
+	unsigned long	p3;
+	int		valid;
+};
+
+struct si5351_hw_data {
+	struct clk_hw			hw;
+	struct si5351_driver_data	*drvdata;
+	struct si5351_parameters	params;
+	unsigned char			num;
+};
+
+struct si5351_driver_data {
+	enum si5351_variant	variant;
+	struct i2c_client	*client;
+	struct regmap		*regmap;
+	struct clk_onecell_data onecell;
+
+	struct clk		*pxtal;
+	const char		*pxtal_name;
+	struct clk_hw		xtal;
+	struct clk		*pclkin;
+	const char		*pclkin_name;
+	struct clk_hw		clkin;
+
+	struct si5351_hw_data	pll[2];
+	struct si5351_hw_data	*msynth;
+	struct si5351_hw_data	*clkout;
+};
+
+static const char const *si5351_input_names[] = {
+	"xtal", "clkin"
+};
+static const char const *si5351_pll_names[] = {
+	"plla", "pllb", "vxco"
+};
+static const char const *si5351_msynth_names[] = {
+	"ms0", "ms1", "ms2", "ms3", "ms4", "ms5", "ms6", "ms7"
+};
+static const char const *si5351_clkout_names[] = {
+	"clk0", "clk1", "clk2", "clk3", "clk4", "clk5", "clk6", "clk7"
+};
+
+/*
+ * Si5351 i2c regmap
+ */
+static inline unsigned char si5351_reg_read(struct si5351_driver_data *drvdata,
+	unsigned char reg)
+{
+	unsigned int val;
+	int ret;
+
+	ret = regmap_read(drvdata->regmap, reg, &val);
+	if (ret) {
+		dev_err(&drvdata->client->dev,
+			"unable to read from reg%02x\n", reg);
+		return 0;
+	}
+
+	return (unsigned char)val;
+}
+
+static inline int si5351_bulk_read(struct si5351_driver_data *drvdata,
+	unsigned char reg, unsigned char count, unsigned char *buf)
+{
+	return regmap_bulk_read(drvdata->regmap, reg, buf, count);
+}
+
+static inline int si5351_reg_write(struct si5351_driver_data *drvdata,
+	unsigned char reg, unsigned char val)
+{
+	return regmap_write(drvdata->regmap, reg, val);
+}
+
+static inline int si5351_bulk_write(struct si5351_driver_data *drvdata,
+	unsigned char reg, unsigned char count, const unsigned char *buf)
+{
+	return regmap_raw_write(drvdata->regmap, reg, buf, count);
+}
+
+static inline int si5351_set_bits(struct si5351_driver_data *drvdata,
+	unsigned char reg, unsigned char mask, unsigned char val)
+{
+	return regmap_update_bits(drvdata->regmap, reg, mask, val);
+}
+
+static inline unsigned char si5351_msynth_params_address(int num)
+{
+	if (num > 5)
+		return SI5351_CLK6_PARAMETERS + (num - 6);
+	return SI5351_CLK0_PARAMETERS + (SI5351_PARAMETERS_LENGTH * num);
+}
+
+static void si5351_read_parameters(struct si5351_driver_data *drvdata,
+	unsigned char reg, struct si5351_parameters *params)
+{
+	unsigned char buf[SI5351_PARAMETERS_LENGTH];
+
+	switch (reg) {
+	case SI5351_CLK6_PARAMETERS:
+	case SI5351_CLK7_PARAMETERS:
+		buf[0] = si5351_reg_read(drvdata, reg);
+		params->p1 = buf[0];
+		params->p2 = 0;
+		params->p3 = 1;
+		break;
+	default:
+		si5351_bulk_read(drvdata, reg, SI5351_PARAMETERS_LENGTH, buf);
+		params->p1 = ((buf[2] & 0x03) << 16) | (buf[3] << 8) | buf[4];
+		params->p2 = ((buf[5] & 0x0f) << 16) | (buf[6] << 8) | buf[7];
+		params->p3 = ((buf[5] & 0xf0) << 12) | (buf[0] << 8) | buf[1];
+	}
+	params->valid = 1;
+}
+
+static void si5351_write_parameters(struct si5351_driver_data *drvdata,
+	unsigned char reg, struct si5351_parameters *params)
+{
+	unsigned char buf[SI5351_PARAMETERS_LENGTH];
+
+	switch (reg) {
+	case SI5351_CLK6_PARAMETERS:
+	case SI5351_CLK7_PARAMETERS:
+		buf[0] = params->p1 & 0xff;
+		si5351_reg_write(drvdata, reg, buf[0]);
+		break;
+	default:
+		buf[0] = ((params->p3 & 0x0ff00) >> 8) & 0xff;
+		buf[1] = params->p3 & 0xff;
+		/* save rdiv and divby4 */
+		buf[2] = si5351_reg_read(drvdata, reg + 2) & ~0x03;
+		buf[2] |= ((params->p1 & 0x30000) >> 16) & 0x03;
+		buf[3] = ((params->p1 & 0x0ff00) >> 8) & 0xff;
+		buf[4] = params->p1 & 0xff;
+		buf[5] = ((params->p3 & 0xf0000) >> 12) |
+			((params->p2 & 0xf0000) >> 16);
+		buf[6] = ((params->p2 & 0x0ff00) >> 8) & 0xff;
+		buf[7] = params->p2 & 0xff;
+		si5351_bulk_write(drvdata, reg, SI5351_PARAMETERS_LENGTH, buf);
+	}
+}
+
+static bool si5351_regmap_is_volatile(struct device *dev, unsigned int reg)
+{
+	switch (reg) {
+	case SI5351_DEVICE_STATUS:
+	case SI5351_INTERRUPT_STATUS:
+	case SI5351_PLL_RESET:
+		return true;
+	}
+	return false;
+}
+
+static bool si5351_regmap_is_writeable(struct device *dev, unsigned int reg)
+{
+	/* reserved registers */
+	if (reg >= 4 && reg <= 8)
+		return false;
+	if (reg >= 10 && reg <= 14)
+		return false;
+	if (reg >= 173 && reg <= 176)
+		return false;
+	if (reg >= 178 && reg <= 182)
+		return false;
+	/* read-only */
+	if (reg == SI5351_DEVICE_STATUS)
+		return false;
+	return true;
+}
+
+static struct regmap_config si5351_regmap_config = {
+	.reg_bits = 8,
+	.val_bits = 8,
+	.cache_type = REGCACHE_RBTREE,
+	.max_register = 187,
+	.writeable_reg = si5351_regmap_is_writeable,
+	.volatile_reg = si5351_regmap_is_volatile,
+};
+
+/*
+ * Si5351 xtal clock input
+ */
+static int si5351_xtal_prepare(struct clk_hw *hw)
+{
+	struct si5351_driver_data *drvdata =
+		container_of(hw, struct si5351_driver_data, xtal);
+	si5351_set_bits(drvdata, SI5351_FANOUT_ENABLE,
+			SI5351_XTAL_ENABLE, SI5351_XTAL_ENABLE);
+	return 0;
+}
+
+static void si5351_xtal_unprepare(struct clk_hw *hw)
+{
+	struct si5351_driver_data *drvdata =
+		container_of(hw, struct si5351_driver_data, xtal);
+	si5351_set_bits(drvdata, SI5351_FANOUT_ENABLE,
+			SI5351_XTAL_ENABLE, 0);
+}
+
+static const struct clk_ops si5351_xtal_ops = {
+	.prepare = si5351_xtal_prepare,
+	.unprepare = si5351_xtal_unprepare,
+};
+
+/*
+ * Si5351 clkin clock input (Si5351C only)
+ */
+static int si5351_clkin_prepare(struct clk_hw *hw)
+{
+	struct si5351_driver_data *drvdata =
+		container_of(hw, struct si5351_driver_data, clkin);
+	si5351_set_bits(drvdata, SI5351_FANOUT_ENABLE,
+			SI5351_CLKIN_ENABLE, SI5351_CLKIN_ENABLE);
+	return 0;
+}
+
+static void si5351_clkin_unprepare(struct clk_hw *hw)
+{
+	struct si5351_driver_data *drvdata =
+		container_of(hw, struct si5351_driver_data, clkin);
+	si5351_set_bits(drvdata, SI5351_FANOUT_ENABLE,
+			SI5351_CLKIN_ENABLE, 0);
+}
+
+/*
+ * CMOS clock source constraints:
+ * The input frequency range of the PLL is 10Mhz to 40MHz.
+ * If CLKIN is >40MHz, the input divider must be used.
+ */
+static unsigned long si5351_clkin_recalc_rate(struct clk_hw *hw,
+					      unsigned long parent_rate)
+{
+	struct si5351_driver_data *drvdata =
+		container_of(hw, struct si5351_driver_data, clkin);
+	unsigned long rate;
+	unsigned char idiv;
+
+	rate = parent_rate;
+	if (parent_rate > 160000000) {
+		idiv = SI5351_CLKIN_DIV_8;
+		rate /= 8;
+	} else if (parent_rate > 80000000) {
+		idiv = SI5351_CLKIN_DIV_4;
+		rate /= 4;
+	} else if (parent_rate > 40000000) {
+		idiv = SI5351_CLKIN_DIV_2;
+		rate /= 2;
+	} else {
+		idiv = SI5351_CLKIN_DIV_1;
+	}
+
+	si5351_set_bits(drvdata, SI5351_PLL_INPUT_SOURCE,
+			SI5351_CLKIN_DIV_MASK, idiv);
+
+	dev_dbg(&drvdata->client->dev, "%s - clkin div = %d, rate = %lu\n",
+		__func__, (1 << (idiv >> 6)), rate);
+
+	return rate;
+}
+
+static const struct clk_ops si5351_clkin_ops = {
+	.prepare = si5351_clkin_prepare,
+	.unprepare = si5351_clkin_unprepare,
+	.recalc_rate = si5351_clkin_recalc_rate,
+};
+
+/*
+ * Si5351 vxco clock input (Si5351B only)
+ */
+
+static int si5351_vxco_prepare(struct clk_hw *hw)
+{
+	struct si5351_hw_data *hwdata =
+		container_of(hw, struct si5351_hw_data, hw);
+
+	dev_warn(&hwdata->drvdata->client->dev, "VXCO currently unsupported\n");
+
+	return 0;
+}
+
+static void si5351_vxco_unprepare(struct clk_hw *hw)
+{
+}
+
+static unsigned long si5351_vxco_recalc_rate(struct clk_hw *hw,
+					     unsigned long parent_rate)
+{
+	return 0;
+}
+
+static int si5351_vxco_set_rate(struct clk_hw *hw, unsigned long rate,
+				unsigned long parent)
+{
+	return 0;
+}
+
+static const struct clk_ops si5351_vxco_ops = {
+	.prepare = si5351_vxco_prepare,
+	.unprepare = si5351_vxco_unprepare,
+	.recalc_rate = si5351_vxco_recalc_rate,
+	.set_rate = si5351_vxco_set_rate,
+};
+
+/*
+ * Si5351 pll a/b
+ *
+ * Feedback Multisynth Divider Equations [2]
+ *
+ * fVCO = fIN * (a + b/c)
+ *
+ * with 15 + 0/1048575 <= (a + b/c) <= 90 + 0/1048575 and
+ * fIN = fXTAL or fIN = fCLKIN/CLKIN_DIV
+ *
+ * Feedback Multisynth Register Equations
+ *
+ * (1) MSNx_P1[17:0] = 128 * a + floor(128 * b/c) - 512
+ * (2) MSNx_P2[19:0] = 128 * b - c * floor(128 * b/c) = (128*b) mod c
+ * (3) MSNx_P3[19:0] = c
+ *
+ * Transposing (2) yields: (4) floor(128 * b/c) = (128 * b / MSNx_P2)/c
+ *
+ * Using (4) on (1) yields:
+ * MSNx_P1 = 128 * a + (128 * b/MSNx_P2)/c - 512
+ * MSNx_P1 + 512 + MSNx_P2/c = 128 * a + 128 * b/c
+ *
+ * a + b/c = (MSNx_P1 + MSNx_P2/MSNx_P3 + 512)/128
+ *         = (MSNx_P1*MSNx_P3 + MSNx_P2 + 512*MSNx_P3)/(128*MSNx_P3)
+ *
+ */
+static inline int _si5351_pll_reparent(struct si5351_driver_data *drvdata,
+				       unsigned char num, unsigned char parent)
+{
+	if (num > 2 ||
+	    (drvdata->variant == SI5351_VARIANT_B && num > 1))
+		return -EINVAL;
+
+	if (drvdata->variant != SI5351_VARIANT_C && parent > 0)
+		return -EINVAL;
+
+	return clk_set_parent(drvdata->pll[num].hw.clk, (parent) ?
+			      drvdata->clkin.clk : drvdata->xtal.clk);
+}
+
+static unsigned char si5351_pll_get_parent(struct clk_hw *hw)
+{
+	struct si5351_hw_data *hwdata =
+		container_of(hw, struct si5351_hw_data, hw);
+	unsigned char mask = (hwdata->num == 0) ?
+		SI5351_PLLA_SOURCE : SI5351_PLLB_SOURCE;
+	unsigned char val;
+
+	val = si5351_reg_read(hwdata->drvdata, SI5351_PLL_INPUT_SOURCE);
+
+	return (val & mask) ? 1 : 0;
+}
+
+static int si5351_pll_set_parent(struct clk_hw *hw, u8 index)
+{
+	struct si5351_hw_data *hwdata =
+		container_of(hw, struct si5351_hw_data, hw);
+	unsigned char mask = (hwdata->num == 0) ?
+		SI5351_PLLA_SOURCE : SI5351_PLLB_SOURCE;
+
+	if (hwdata->drvdata->variant != SI5351_VARIANT_C &&
+	    index > 0)
+		return -EPERM;
+
+	if (index > 1)
+		return -EINVAL;
+
+	si5351_set_bits(hwdata->drvdata, SI5351_PLL_INPUT_SOURCE,
+			mask, (index) ? 0 : mask);
+
+	return 0;
+}
+
+static unsigned long si5351_pll_recalc_rate(struct clk_hw *hw,
+					    unsigned long parent_rate)
+{
+	struct si5351_hw_data *hwdata =
+		container_of(hw, struct si5351_hw_data, hw);
+	unsigned char reg = (hwdata->num == 0) ?
+		SI5351_PLLA_PARAMETERS : SI5351_PLLB_PARAMETERS;
+	unsigned long long rate;
+
+	if (!hwdata->params.valid)
+		si5351_read_parameters(hwdata->drvdata, reg, &hwdata->params);
+
+	if (hwdata->params.p3 == 0)
+		return parent_rate;
+
+	/* fVCO = fIN * (P1*P3 + 512*P3 + P2)/(128*P3) */
+	rate  = hwdata->params.p1 * hwdata->params.p3;
+	rate += 512 * hwdata->params.p3;
+	rate += hwdata->params.p2;
+	rate *= parent_rate;
+	do_div(rate, 128 * hwdata->params.p3);
+
+	dev_dbg(&hwdata->drvdata->client->dev,
+		"%s - %s: p1 = %lu, p2 = %lu, p3 = %lu, parent_rate = %lu, rate = %lu\n",
+		__func__, __clk_get_name(hwdata->hw.clk),
+		hwdata->params.p1, hwdata->params.p2, hwdata->params.p3,
+		parent_rate, (unsigned long)rate);
+
+	return (unsigned long)rate;
+}
+
+static long si5351_pll_round_rate(struct clk_hw *hw, unsigned long rate,
+				  unsigned long *parent_rate)
+{
+	struct si5351_hw_data *hwdata =
+		container_of(hw, struct si5351_hw_data, hw);
+	unsigned long rfrac, denom, a, b, c;
+	unsigned long long lltmp;
+
+	if (rate < SI5351_PLL_VCO_MIN)
+		rate = SI5351_PLL_VCO_MIN;
+	if (rate > SI5351_PLL_VCO_MAX)
+		rate = SI5351_PLL_VCO_MAX;
+
+	/* determine integer part of feedback equation */
+	a = rate / *parent_rate;
+
+	if (a < SI5351_PLL_A_MIN)
+		rate = *parent_rate * SI5351_PLL_A_MIN;
+	if (a > SI5351_PLL_A_MAX)
+		rate = *parent_rate * SI5351_PLL_A_MAX;
+
+	/* find best approximation for b/c = fVCO mod fIN */
+	denom = 1000 * 1000;
+	lltmp = rate % (*parent_rate);
+	lltmp *= denom;
+	do_div(lltmp, *parent_rate);
+	rfrac = (unsigned long)lltmp;
+
+	b = 0;
+	c = 1;
+	if (rfrac)
+		rational_best_approximation(rfrac, denom,
+				    SI5351_PLL_B_MAX, SI5351_PLL_C_MAX, &b, &c);
+
+	/* calculate parameters */
+	hwdata->params.p3  = c;
+	hwdata->params.p2  = (128 * b) % c;
+	hwdata->params.p1  = 128 * a;
+	hwdata->params.p1 += (128 * b / c);
+	hwdata->params.p1 -= 512;
+
+	/* recalculate rate by fIN * (a + b/c) */
+	lltmp  = *parent_rate;
+	lltmp *= b;
+	do_div(lltmp, c);
+
+	rate  = (unsigned long)lltmp;
+	rate += *parent_rate * a;
+
+	dev_dbg(&hwdata->drvdata->client->dev,
+		"%s - %s: a = %lu, b = %lu, c = %lu, parent_rate = %lu, rate = %lu\n",
+		__func__, __clk_get_name(hwdata->hw.clk), a, b, c,
+		*parent_rate, rate);
+
+	return rate;
+}
+
+static int si5351_pll_set_rate(struct clk_hw *hw, unsigned long rate,
+			       unsigned long parent_rate)
+{
+	struct si5351_hw_data *hwdata =
+		container_of(hw, struct si5351_hw_data, hw);
+	unsigned char reg = (hwdata->num == 0) ?
+		SI5351_PLLA_PARAMETERS : SI5351_PLLB_PARAMETERS;
+	unsigned char val;
+
+	/* write multisynth parameters */
+	si5351_write_parameters(hwdata->drvdata, reg, &hwdata->params);
+
+	/* plla/pllb ctrl is in clk6/clk7 ctrl registers */
+	si5351_set_bits(hwdata->drvdata, SI5351_CLK6_CTRL + hwdata->num,
+		SI5351_CLK_INTEGER_MODE,
+		(hwdata->params.p2 == 0) ? SI5351_CLK_INTEGER_MODE : 0);
+
+	/* reset pll */
+	val = (hwdata->num == 0) ? SI5351_PLL_RESET_A : SI5351_PLL_RESET_B;
+	si5351_set_bits(hwdata->drvdata, SI5351_PLL_RESET, val, val);
+
+	dev_dbg(&hwdata->drvdata->client->dev,
+		"%s - %s: p1 = %lu, p2 = %lu, p3 = %lu, parent_rate = %lu, rate = %lu\n",
+		__func__, __clk_get_name(hwdata->hw.clk),
+		hwdata->params.p1, hwdata->params.p2, hwdata->params.p3,
+		parent_rate, rate);
+
+	return 0;
+}
+
+static const struct clk_ops si5351_pll_ops = {
+	.set_parent = si5351_pll_set_parent,
+	.get_parent = si5351_pll_get_parent,
+	.recalc_rate = si5351_pll_recalc_rate,
+	.round_rate = si5351_pll_round_rate,
+	.set_rate = si5351_pll_set_rate,
+};
+
+/*
+ * Si5351 multisync divider
+ *
+ * for fOUT <= 150 MHz:
+ *
+ * fOUT = (fIN * (a + b/c)) / CLKOUTDIV
+ *
+ * with 6 + 0/1048575 <= (a + b/c) <= 1800 + 0/1048575 and
+ * fIN = fVCO0, fVCO1, fXTAL or fCLKIN/CLKIN_DIV
+ *
+ * Output Clock Multisynth Register Equations
+ *
+ * MSx_P1[17:0] = 128 * a + floor(128 * b/c) - 512
+ * MSx_P2[19:0] = 128 * b - c * floor(128 * b/c) = (128*b) mod c
+ * MSx_P3[19:0] = c
+ *
+ * MS[6,7] are integer (P1) divide only, P2 = 0, P3 = 0
+ *
+ * for 150MHz < fOUT <= 160MHz:
+ *
+ * MSx_P1 = 0, MSx_P2 = 0, MSx_P3 = 1, MSx_INT = 1, MSx_DIVBY4 = 11b
+ */
+static inline void _si5351_msynth_set_pll_master(
+	struct si5351_driver_data *drvdata, unsigned char num, int is_master)
+{
+	unsigned long flags;
+
+	if (num > 8 ||
+	    (drvdata->variant == SI5351_VARIANT_A3 && num > 3))
+		return;
+
+	flags = __clk_get_flags(drvdata->msynth[num].hw.clk);
+	if (is_master)
+		flags |= CLK_SET_RATE_PARENT;
+	else
+		flags &= ~CLK_SET_RATE_PARENT;
+	__clk_set_flags(drvdata->msynth[num].hw.clk, flags);
+}
+
+static inline int _si5351_msynth_reparent(struct si5351_driver_data *drvdata,
+				  unsigned char num, unsigned char parent)
+{
+	if (parent > 2)
+		return -EINVAL;
+
+	if (num > 8 ||
+	    (drvdata->variant == SI5351_VARIANT_A3 && num > 3))
+		return -EINVAL;
+
+	return clk_set_parent(drvdata->msynth[num].hw.clk,
+			      drvdata->pll[parent].hw.clk);
+}
+
+static unsigned char si5351_msynth_get_parent(struct clk_hw *hw)
+{
+	struct si5351_hw_data *hwdata =
+		container_of(hw, struct si5351_hw_data, hw);
+	unsigned char val;
+
+	val = si5351_reg_read(hwdata->drvdata, SI5351_CLK0_CTRL + hwdata->num);
+
+	return (val & SI5351_CLK_PLL_SELECT) ? 1 : 0;
+}
+
+static int si5351_msynth_set_parent(struct clk_hw *hw, u8 index)
+{
+	struct si5351_hw_data *hwdata =
+		container_of(hw, struct si5351_hw_data, hw);
+
+	si5351_set_bits(hwdata->drvdata, SI5351_CLK0_CTRL + hwdata->num,
+			SI5351_CLK_PLL_SELECT,
+			(index) ? SI5351_CLK_PLL_SELECT : 0);
+
+	return 0;
+}
+
+static unsigned long si5351_msynth_recalc_rate(struct clk_hw *hw,
+					       unsigned long parent_rate)
+{
+	struct si5351_hw_data *hwdata =
+		container_of(hw, struct si5351_hw_data, hw);
+	unsigned char reg = si5351_msynth_params_address(hwdata->num);
+	unsigned long long rate;
+	unsigned long m;
+
+	if (!hwdata->params.valid)
+		si5351_read_parameters(hwdata->drvdata, reg, &hwdata->params);
+
+	if (hwdata->params.p3 == 0)
+		return parent_rate;
+
+	/*
+	 * multisync0-5: fOUT = (128 * P3 * fIN) / (P1*P3 + P2 + 512*P3)
+	 * multisync6-7: fOUT = fIN / P1
+	 */
+	rate = parent_rate;
+	if (hwdata->num > 5) {
+		m = hwdata->params.p1;
+	} else if ((si5351_reg_read(hwdata->drvdata, reg + 2) &
+		    SI5351_OUTPUT_CLK_DIVBY4) == SI5351_OUTPUT_CLK_DIVBY4) {
+		m = 4;
+	} else {
+		rate *= 128 * hwdata->params.p3;
+		m = hwdata->params.p1 * hwdata->params.p3;
+		m += hwdata->params.p2;
+		m += 512 * hwdata->params.p3;
+	}
+
+	if (m == 0)
+		return 0;
+	do_div(rate, m);
+
+	dev_dbg(&hwdata->drvdata->client->dev,
+		"%s - %s: p1 = %lu, p2 = %lu, p3 = %lu, m = %lu, parent_rate = %lu, rate = %lu\n",
+		__func__, __clk_get_name(hwdata->hw.clk),
+		hwdata->params.p1, hwdata->params.p2, hwdata->params.p3,
+		m, parent_rate, (unsigned long)rate);
+
+	return (unsigned long)rate;
+}
+
+static long si5351_msynth_round_rate(struct clk_hw *hw, unsigned long rate,
+				     unsigned long *parent_rate)
+{
+	struct si5351_hw_data *hwdata =
+		container_of(hw, struct si5351_hw_data, hw);
+	unsigned long long lltmp;
+	unsigned long a, b, c;
+	int divby4;
+
+	/* multisync6-7 can only handle freqencies < 150MHz */
+	if (hwdata->num >= 6 && rate > SI5351_MULTISYNTH67_MAX_FREQ)
+		rate = SI5351_MULTISYNTH67_MAX_FREQ;
+
+	/* multisync frequency is 1MHz .. 160MHz */
+	if (rate > SI5351_MULTISYNTH_MAX_FREQ)
+		rate = SI5351_MULTISYNTH_MAX_FREQ;
+	if (rate < SI5351_MULTISYNTH_MIN_FREQ)
+		rate = SI5351_MULTISYNTH_MIN_FREQ;
+
+	divby4 = 0;
+	if (rate > SI5351_MULTISYNTH_DIVBY4_FREQ)
+		divby4 = 1;
+
+	/* multisync can set pll */
+	if (__clk_get_flags(hwdata->hw.clk) & CLK_SET_RATE_PARENT) {
+		/*
+		 * find largest integer divider for max
+		 * vco frequency and given target rate
+		 */
+		if (divby4 == 0) {
+			lltmp = SI5351_PLL_VCO_MAX;
+			do_div(lltmp, rate);
+			a = (unsigned long)lltmp;
+		} else
+			a = 4;
+
+		b = 0;
+		c = 1;
+
+		*parent_rate = a * rate;
+	} else {
+		unsigned long rfrac, denom;
+
+		/* disable divby4 */
+		if (divby4) {
+			rate = SI5351_MULTISYNTH_DIVBY4_FREQ;
+			divby4 = 0;
+		}
+
+		/* determine integer part of divider equation */
+		a = *parent_rate / rate;
+		if (a < SI5351_MULTISYNTH_A_MIN)
+			a = SI5351_MULTISYNTH_A_MIN;
+		if (hwdata->num >= 6 && a > SI5351_MULTISYNTH67_A_MAX)
+			a = SI5351_MULTISYNTH67_A_MAX;
+		else if (a > SI5351_MULTISYNTH_A_MAX)
+			a = SI5351_MULTISYNTH_A_MAX;
+
+		/* find best approximation for b/c = fVCO mod fOUT */
+		denom = 1000 * 1000;
+		lltmp = (*parent_rate) % rate;
+		lltmp *= denom;
+		do_div(lltmp, rate);
+		rfrac = (unsigned long)lltmp;
+
+		b = 0;
+		c = 1;
+		if (rfrac)
+			rational_best_approximation(rfrac, denom,
+			    SI5351_MULTISYNTH_B_MAX, SI5351_MULTISYNTH_C_MAX,
+			    &b, &c);
+	}
+
+	/* recalculate rate by fOUT = fIN / (a + b/c) */
+	lltmp  = *parent_rate;
+	lltmp *= c;
+	do_div(lltmp, a * c + b);
+	rate  = (unsigned long)lltmp;
+
+	/* calculate parameters */
+	if (divby4) {
+		hwdata->params.p3 = 1;
+		hwdata->params.p2 = 0;
+		hwdata->params.p1 = 0;
+	} else {
+		hwdata->params.p3  = c;
+		hwdata->params.p2  = (128 * b) % c;
+		hwdata->params.p1  = 128 * a;
+		hwdata->params.p1 += (128 * b / c);
+		hwdata->params.p1 -= 512;
+	}
+
+	dev_dbg(&hwdata->drvdata->client->dev,
+		"%s - %s: a = %lu, b = %lu, c = %lu, divby4 = %d, parent_rate = %lu, rate = %lu\n",
+		__func__, __clk_get_name(hwdata->hw.clk), a, b, c, divby4,
+		*parent_rate, rate);
+
+	return rate;
+}
+
+static int si5351_msynth_set_rate(struct clk_hw *hw, unsigned long rate,
+				  unsigned long parent_rate)
+{
+	struct si5351_hw_data *hwdata =
+		container_of(hw, struct si5351_hw_data, hw);
+	unsigned char reg = si5351_msynth_params_address(hwdata->num);
+	int divby4 = 0;
+
+	/* write multisynth parameters */
+	si5351_write_parameters(hwdata->drvdata, reg, &hwdata->params);
+
+	if (rate > SI5351_MULTISYNTH_DIVBY4_FREQ)
+		divby4 = 1;
+
+	/* enable/disable integer mode and divby4 on multisynth0-5 */
+	if (hwdata->num < 6) {
+		si5351_set_bits(hwdata->drvdata, reg + 2,
+				SI5351_OUTPUT_CLK_DIVBY4,
+				(divby4) ? SI5351_OUTPUT_CLK_DIVBY4 : 0);
+		si5351_set_bits(hwdata->drvdata, SI5351_CLK0_CTRL + hwdata->num,
+			SI5351_CLK_INTEGER_MODE,
+			(hwdata->params.p2 == 0) ? SI5351_CLK_INTEGER_MODE : 0);
+	}
+
+	dev_dbg(&hwdata->drvdata->client->dev,
+		"%s - %s: p1 = %lu, p2 = %lu, p3 = %lu, divby4 = %d, parent_rate = %lu, rate = %lu\n",
+		__func__, __clk_get_name(hwdata->hw.clk),
+		hwdata->params.p1, hwdata->params.p2, hwdata->params.p3,
+		divby4, parent_rate, rate);
+
+	return 0;
+}
+
+static const struct clk_ops si5351_msynth_ops = {
+	.set_parent = si5351_msynth_set_parent,
+	.get_parent = si5351_msynth_get_parent,
+	.recalc_rate = si5351_msynth_recalc_rate,
+	.round_rate = si5351_msynth_round_rate,
+	.set_rate = si5351_msynth_set_rate,
+};
+
+/*
+ * Si5351 clkout divider
+ */
+static int _si5351_clkout_set_drive_strength(struct si5351_driver_data *drvdata,
+				     unsigned char num, unsigned char drive)
+{
+	if (num > 8 ||
+	    (drvdata->variant == SI5351_VARIANT_A3 && num > 3))
+		return -EINVAL;
+
+	switch (drive) {
+	case 2:
+		drive = SI5351_CLK_DRIVE_2MA;
+		break;
+	case 4:
+		drive = SI5351_CLK_DRIVE_4MA;
+		break;
+	case 6:
+		drive = SI5351_CLK_DRIVE_6MA;
+		break;
+	case 8:
+		drive = SI5351_CLK_DRIVE_8MA;
+		break;
+	default:
+		return -EINVAL;
+	}
+
+	si5351_set_bits(drvdata, SI5351_CLK0_CTRL + num,
+			SI5351_CLK_DRIVE_MASK, drive);
+
+	return 0;
+}
+
+static inline int _si5351_clkout_reparent(struct si5351_driver_data *drvdata,
+				  unsigned char num, unsigned char parent)
+{
+	struct clk *pclk;
+	unsigned long flags;
+
+	if (num > 8 ||
+	    (drvdata->variant == SI5351_VARIANT_A3 && num > 3))
+		return -EINVAL;
+
+	flags = __clk_get_flags(drvdata->clkout[num].hw.clk);
+	flags &= ~CLK_SET_RATE_PARENT;
+
+	switch (parent) {
+	case 0:
+		pclk = drvdata->msynth[num].hw.clk;
+		flags |= CLK_SET_RATE_PARENT;
+		break;
+	case 1:
+		pclk = drvdata->msynth[0].hw.clk;
+		if (num >= 4)
+			pclk = drvdata->msynth[4].hw.clk;
+		break;
+	case 2:
+		pclk = drvdata->xtal.clk;
+		break;
+	case 3:
+		if (drvdata->variant != SI5351_VARIANT_C)
+			return -EINVAL;
+		pclk = drvdata->clkin.clk;
+		break;
+	default:
+		return -EINVAL;
+	}
+
+	__clk_set_flags(drvdata->clkout[num].hw.clk, flags);
+	return clk_set_parent(drvdata->clkout[num].hw.clk, pclk);
+}
+
+static int si5351_clkout_prepare(struct clk_hw *hw)
+{
+	struct si5351_hw_data *hwdata =
+		container_of(hw, struct si5351_hw_data, hw);
+
+	si5351_set_bits(hwdata->drvdata, SI5351_CLK0_CTRL + hwdata->num,
+			SI5351_CLK_POWERDOWN, 0);
+	si5351_set_bits(hwdata->drvdata, SI5351_OUTPUT_ENABLE_CTRL,
+			(1 << hwdata->num), 0);
+	return 0;
+}
+
+static void si5351_clkout_unprepare(struct clk_hw *hw)
+{
+	struct si5351_hw_data *hwdata =
+		container_of(hw, struct si5351_hw_data, hw);
+
+	si5351_set_bits(hwdata->drvdata, SI5351_CLK0_CTRL + hwdata->num,
+			SI5351_CLK_POWERDOWN, SI5351_CLK_POWERDOWN);
+	si5351_set_bits(hwdata->drvdata, SI5351_OUTPUT_ENABLE_CTRL,
+			(1 << hwdata->num), (1 << hwdata->num));
+}
+
+static u8 si5351_clkout_get_parent(struct clk_hw *hw)
+{
+	struct si5351_hw_data *hwdata =
+		container_of(hw, struct si5351_hw_data, hw);
+	int index = 0;
+	unsigned char val;
+
+	val = si5351_reg_read(hwdata->drvdata, SI5351_CLK0_CTRL + hwdata->num);
+	switch (val & SI5351_CLK_INPUT_MASK) {
+	case SI5351_CLK_INPUT_MULTISYNTH_N:
+		index = 0;
+		break;
+	case SI5351_CLK_INPUT_MULTISYNTH_0_4:
+		index = 1;
+		break;
+	case SI5351_CLK_INPUT_XTAL:
+		index = 2;
+		break;
+	case SI5351_CLK_INPUT_CLKIN:
+		index = 3;
+		break;
+	}
+
+	return index;
+}
+
+static int si5351_clkout_set_parent(struct clk_hw *hw, u8 index)
+{
+	struct si5351_hw_data *hwdata =
+		container_of(hw, struct si5351_hw_data, hw);
+	unsigned long flags;
+	unsigned val = 0;
+
+	flags = __clk_get_flags(hw->clk) & ~CLK_SET_RATE_PARENT;
+
+	switch (index) {
+	case 0:
+		flags |= CLK_SET_RATE_PARENT;
+		val = SI5351_CLK_INPUT_MULTISYNTH_N;
+		break;
+	case 1:
+		/* clk0/clk4 can only connect to its own multisync */
+		if (hwdata->num == 0 || hwdata->num == 4)
+			val = SI5351_CLK_INPUT_MULTISYNTH_N;
+		else
+			val = SI5351_CLK_INPUT_MULTISYNTH_0_4;
+		break;
+	case 2:
+		val = SI5351_CLK_INPUT_XTAL;
+		break;
+	case 3:
+		val = SI5351_CLK_INPUT_CLKIN;
+		break;
+	}
+
+	si5351_set_bits(hwdata->drvdata, SI5351_CLK0_CTRL + hwdata->num,
+			SI5351_CLK_INPUT_MASK, val);
+	__clk_set_flags(hw->clk, flags);
+
+	return 0;
+}
+
+static unsigned long si5351_clkout_recalc_rate(struct clk_hw *hw,
+					       unsigned long parent_rate)
+{
+	struct si5351_hw_data *hwdata =
+		container_of(hw, struct si5351_hw_data, hw);
+	unsigned char reg;
+	unsigned char rdiv;
+
+	if (hwdata->num > 5)
+		reg = si5351_msynth_params_address(hwdata->num) + 2;
+	else
+		reg = SI5351_CLK6_7_OUTPUT_DIVIDER;
+
+	rdiv = si5351_reg_read(hwdata->drvdata, reg);
+	if (hwdata->num == 6) {
+		rdiv &= SI5351_OUTPUT_CLK6_DIV_MASK;
+	} else {
+		rdiv &= SI5351_OUTPUT_CLK_DIV_MASK;
+		rdiv >>= SI5351_OUTPUT_CLK_DIV_SHIFT;
+	}
+
+	return parent_rate >> rdiv;
+}
+
+static long si5351_clkout_round_rate(struct clk_hw *hw, unsigned long rate,
+				     unsigned long *parent_rate)
+{
+	struct si5351_hw_data *hwdata =
+		container_of(hw, struct si5351_hw_data, hw);
+	unsigned char rdiv;
+
+	/* clkout6/7 can only handle output freqencies < 150MHz */
+	if (hwdata->num >= 6 && rate > SI5351_CLKOUT67_MAX_FREQ)
+		rate = SI5351_CLKOUT67_MAX_FREQ;
+
+	/* clkout freqency is 8kHz - 160MHz */
+	if (rate > SI5351_CLKOUT_MAX_FREQ)
+		rate = SI5351_CLKOUT_MAX_FREQ;
+	if (rate < SI5351_CLKOUT_MIN_FREQ)
+		rate = SI5351_CLKOUT_MIN_FREQ;
+
+	/* request frequency if multisync master */
+	if (__clk_get_flags(hwdata->hw.clk) & CLK_SET_RATE_PARENT) {
+		/* use r divider for frequencies below 1MHz */
+		rdiv = SI5351_OUTPUT_CLK_DIV_1;
+		while (rate < SI5351_MULTISYNTH_MIN_FREQ &&
+		       rdiv < SI5351_OUTPUT_CLK_DIV_128) {
+			rdiv += 1;
+			rate *= 2;
+		}
+		*parent_rate = rate;
+	} else {
+		unsigned long new_rate, new_err, err;
+
+		/* round to closed rdiv */
+		rdiv = SI5351_OUTPUT_CLK_DIV_1;
+		new_rate = *parent_rate;
+		err = abs(new_rate - rate);
+		do {
+			new_rate >>= 1;
+			new_err = abs(new_rate - rate);
+			if (new_err > err || rdiv == SI5351_OUTPUT_CLK_DIV_128)
+				break;
+			rdiv++;
+			err = new_err;
+		} while (1);
+	}
+	rate = *parent_rate >> rdiv;
+
+	dev_dbg(&hwdata->drvdata->client->dev,
+		"%s - %s: rdiv = %u, parent_rate = %lu, rate = %lu\n",
+		__func__, __clk_get_name(hwdata->hw.clk), (1 << rdiv),
+		*parent_rate, rate);
+
+	return rate;
+}
+
+static int si5351_clkout_set_rate(struct clk_hw *hw, unsigned long rate,
+				  unsigned long parent_rate)
+{
+	struct si5351_hw_data *hwdata =
+		container_of(hw, struct si5351_hw_data, hw);
+	unsigned long new_rate, new_err, err;
+	unsigned char rdiv;
+
+	/* round to closed rdiv */
+	rdiv = SI5351_OUTPUT_CLK_DIV_1;
+	new_rate = parent_rate;
+	err = abs(new_rate - rate);
+	do {
+		new_rate >>= 1;
+		new_err = abs(new_rate - rate);
+		if (new_err > err || rdiv == SI5351_OUTPUT_CLK_DIV_128)
+			break;
+		rdiv++;
+		err = new_err;
+	} while (1);
+
+	/* powerdown clkout */
+	si5351_set_bits(hwdata->drvdata, SI5351_CLK0_CTRL + hwdata->num,
+			SI5351_CLK_POWERDOWN, SI5351_CLK_POWERDOWN);
+
+	/* write output divider */
+	switch (hwdata->num) {
+	case 6:
+		si5351_set_bits(hwdata->drvdata, SI5351_CLK6_7_OUTPUT_DIVIDER,
+				SI5351_OUTPUT_CLK6_DIV_MASK, rdiv);
+		break;
+	case 7:
+		si5351_set_bits(hwdata->drvdata, SI5351_CLK6_7_OUTPUT_DIVIDER,
+				SI5351_OUTPUT_CLK_DIV_MASK,
+				rdiv << SI5351_OUTPUT_CLK_DIV_SHIFT);
+		break;
+	default:
+		si5351_set_bits(hwdata->drvdata,
+				si5351_msynth_params_address(hwdata->num) + 2,
+				SI5351_OUTPUT_CLK_DIV_MASK,
+				rdiv << SI5351_OUTPUT_CLK_DIV_SHIFT);
+	}
+
+	/* powerup clkout */
+	si5351_set_bits(hwdata->drvdata, SI5351_CLK0_CTRL + hwdata->num,
+			SI5351_CLK_POWERDOWN, 0);
+
+	dev_dbg(&hwdata->drvdata->client->dev,
+		"%s - %s: rdiv = %u, parent_rate = %lu, rate = %lu\n",
+		__func__, __clk_get_name(hwdata->hw.clk), (1 << rdiv),
+		parent_rate, rate);
+
+	return 0;
+}
+
+static const struct clk_ops si5351_clkout_ops = {
+	.prepare = si5351_clkout_prepare,
+	.unprepare = si5351_clkout_unprepare,
+	.set_parent = si5351_clkout_set_parent,
+	.get_parent = si5351_clkout_get_parent,
+	.recalc_rate = si5351_clkout_recalc_rate,
+	.round_rate = si5351_clkout_round_rate,
+	.set_rate = si5351_clkout_set_rate,
+};
+
+/*
+ * Si5351 i2c probe and DT
+ */
+static void si5351_dt_setup(
+	struct i2c_client *client, struct si5351_driver_data *drvdata)
+{
+	struct device_node *np = client->dev.of_node;
+	struct property *prop;
+	const __be32 *p;
+	unsigned int num, val;
+
+	if (np == NULL)
+		return;
+
+	/*
+	 * property silabs,pll-source : <num src>, [<..>]
+	 * allow to selectively set pll source
+	 */
+	of_property_for_each_u32(client->dev.of_node, "silabs,pll-source",
+				 prop, p, num) {
+		if (num >= 2) {
+			dev_err(&client->dev,
+				"invalid pll %d on pll-source prop\n", num);
+			break;
+		}
+
+		p = of_prop_next_u32(prop, p, &val);
+		if (!p)
+			break;
+
+		if (_si5351_pll_reparent(drvdata, num, val))
+			dev_warn(&client->dev,
+				 "unable to reparent pll %d to %d\n",
+				 num, val);
+	}
+
+	for_each_child_of_node(client->dev.of_node, np) {
+		if (of_property_read_u32(np, "reg", &num)) {
+			dev_err(&client->dev, "missing reg property of %s\n",
+				np->full_name);
+			continue;
+		}
+
+		if (of_property_read_bool(np, "silabs,pll-master"))
+			_si5351_msynth_set_pll_master(drvdata, num, 1);
+
+		if (!of_property_read_u32(np, "silabs,drive-strength", &val)) {
+			if (_si5351_clkout_set_drive_strength(drvdata,
+							      num, val))
+				dev_warn(&client->dev,
+					 "unable to set drive strength of %d to %d\n",
+					 num, val);
+		}
+
+		if (!of_property_read_u32(np, "silabs,multisynth-source",
+					  &val)) {
+			if (_si5351_msynth_reparent(drvdata, num, val))
+				dev_warn(&client->dev,
+					 "unable to reparent multisynth %d to %d\n",
+					 num, val);
+		}
+
+		if (!of_property_read_u32(np, "silabs,clock-source", &val)) {
+			if (_si5351_clkout_reparent(drvdata, num, val))
+				dev_warn(&client->dev,
+					 "unable to reparent clockout %d to %d\n",
+					 num, val);
+		}
+
+		if (!of_property_read_u32(np, "clock-frequency", &val))
+			clk_set_rate(drvdata->onecell.clks[num], val);
+	}
+}
+
+static const struct of_device_id si5351_dt_ids[] = {
+	{ .compatible = "silabs,si5351a", .data = (void *)SI5351_VARIANT_A, },
+	{ .compatible = "silabs,si5351a-msop",
+					 .data = (void *)SI5351_VARIANT_A3, },
+	{ .compatible = "silabs,si5351b", .data = (void *)SI5351_VARIANT_B, },
+	{ .compatible = "silabs,si5351c", .data = (void *)SI5351_VARIANT_C, },
+	{ }
+};
+MODULE_DEVICE_TABLE(of, si5351_dt_ids);
+
+static int si5351_dt_parse(
+	struct i2c_client *client, struct si5351_driver_data *drvdata)
+{
+	struct device_node *np = client->dev.of_node;
+	const struct of_device_id *match;
+
+	if (np == NULL)
+		return -EINVAL;
+
+	match = of_match_node(si5351_dt_ids, np);
+	if (match == NULL)
+		return -EINVAL;
+
+	drvdata->variant = (enum si5351_variant)match->data;
+	drvdata->pxtal = of_clk_get(np, 0);
+	drvdata->pclkin = of_clk_get(np, 1);
+
+	return 0;
+}
+
+static int si5351_i2c_probe(struct i2c_client *client,
+			    const struct i2c_device_id *id)
+{
+	struct si5351_driver_data *drvdata;
+	struct clk_init_data init;
+	struct clk *clk;
+	const char *parent_names[4];
+	u8 num_parents, num_clocks;
+	int ret, n;
+
+	drvdata = devm_kzalloc(&client->dev, sizeof(*drvdata), GFP_KERNEL);
+	if (drvdata == NULL) {
+		dev_err(&client->dev, "unable to allocate driver data\n");
+		return -ENOMEM;
+	}
+
+	ret = si5351_dt_parse(client, drvdata);
+	if (ret)
+		return ret;
+
+	i2c_set_clientdata(client, drvdata);
+	drvdata->client = client;
+	drvdata->regmap = devm_regmap_init_i2c(client, &si5351_regmap_config);
+	if (IS_ERR(drvdata->regmap)) {
+		dev_err(&client->dev, "failed to allocate register map\n");
+		return PTR_ERR(drvdata->regmap);
+	}
+
+	/* Disable interrupts */
+	si5351_reg_write(drvdata, SI5351_INTERRUPT_MASK, 0xf0);
+	/* Set disabled output drivers to drive low */
+	si5351_reg_write(drvdata, SI5351_CLK3_0_DISABLE_STATE, 0x00);
+	si5351_reg_write(drvdata, SI5351_CLK7_4_DISABLE_STATE, 0x00);
+	/* Ensure pll select is on XTAL for Si5351A/B */
+	if (drvdata->variant != SI5351_VARIANT_C)
+		si5351_set_bits(drvdata, SI5351_PLL_INPUT_SOURCE,
+				SI5351_PLLA_SOURCE | SI5351_PLLB_SOURCE, 0);
+
+	/* register xtal input clock gate */
+	memset(&init, 0, sizeof(init));
+	init.name = si5351_input_names[0];
+	init.ops = &si5351_xtal_ops;
+	init.flags = 0;
+	if (!IS_ERR(drvdata->pxtal)) {
+		drvdata->pxtal_name = __clk_get_name(drvdata->pxtal);
+		init.parent_names = &drvdata->pxtal_name;
+		init.num_parents = 1;
+	}
+	drvdata->xtal.init = &init;
+	clk = devm_clk_register(&client->dev, &drvdata->xtal);
+	if (IS_ERR(clk)) {
+		dev_err(&client->dev, "unable to register %s\n", init.name);
+		return PTR_ERR(clk);
+	}
+
+	/* register clkin input clock gate */
+	if (drvdata->variant == SI5351_VARIANT_C) {
+		memset(&init, 0, sizeof(init));
+		init.name = si5351_input_names[1];
+		init.ops = &si5351_clkin_ops;
+		if (!IS_ERR(drvdata->pclkin)) {
+			drvdata->pclkin_name = __clk_get_name(drvdata->pclkin);
+			init.parent_names = &drvdata->pclkin_name;
+			init.num_parents = 1;
+		}
+		drvdata->clkin.init = &init;
+		clk = devm_clk_register(&client->dev, &drvdata->clkin);
+		if (IS_ERR(clk)) {
+			dev_err(&client->dev, "unable to register %s\n",
+				init.name);
+			return PTR_ERR(clk);
+		}
+	}
+
+	/* Si5351C allows to mux either xtal or clkin to PLL input */
+	num_parents = (drvdata->variant == SI5351_VARIANT_C) ? 2 : 1;
+	parent_names[0] = si5351_input_names[0];
+	parent_names[1] = si5351_input_names[1];
+
+	/* register PLLA */
+	drvdata->pll[0].num = 0;
+	drvdata->pll[0].drvdata = drvdata;
+	drvdata->pll[0].hw.init = &init;
+	memset(&init, 0, sizeof(init));
+	init.name = si5351_pll_names[0];
+	init.ops = &si5351_pll_ops;
+	init.flags = 0;
+	init.parent_names = parent_names;
+	init.num_parents = num_parents;
+	clk = devm_clk_register(&client->dev, &drvdata->pll[0].hw);
+	if (IS_ERR(clk)) {
+		dev_err(&client->dev, "unable to register %s\n", init.name);
+		return -EINVAL;
+	}
+
+	/* register PLLB or VXCO (Si5351B) */
+	drvdata->pll[1].num = 1;
+	drvdata->pll[1].drvdata = drvdata;
+	drvdata->pll[1].hw.init = &init;
+	memset(&init, 0, sizeof(init));
+	if (drvdata->variant == SI5351_VARIANT_B) {
+		init.name = si5351_pll_names[2];
+		init.ops = &si5351_vxco_ops;
+		init.flags = CLK_IS_ROOT;
+		init.parent_names = NULL;
+		init.num_parents = 0;
+	} else {
+		init.name = si5351_pll_names[1];
+		init.ops = &si5351_pll_ops;
+		init.flags = 0;
+		init.parent_names = parent_names;
+		init.num_parents = num_parents;
+	}
+	clk = devm_clk_register(&client->dev, &drvdata->pll[1].hw);
+	if (IS_ERR(clk)) {
+		dev_err(&client->dev, "unable to register %s\n", init.name);
+		return -EINVAL;
+	}
+
+	/* register clk multisync and clk out divider */
+	num_clocks = (drvdata->variant == SI5351_VARIANT_A3) ? 3 : 8;
+	parent_names[0] = si5351_pll_names[0];
+	if (drvdata->variant == SI5351_VARIANT_B)
+		parent_names[1] = si5351_pll_names[2];
+	else
+		parent_names[1] = si5351_pll_names[1];
+
+	drvdata->msynth = devm_kzalloc(&client->dev, num_clocks *
+				       sizeof(*drvdata->msynth), GFP_KERNEL);
+	drvdata->clkout = devm_kzalloc(&client->dev, num_clocks *
+				       sizeof(*drvdata->clkout), GFP_KERNEL);
+
+	drvdata->onecell.clk_num = num_clocks;
+	drvdata->onecell.clks = devm_kzalloc(&client->dev,
+		num_clocks * sizeof(*drvdata->onecell.clks), GFP_KERNEL);
+
+	if (WARN_ON(!drvdata->msynth || !drvdata->clkout ||
+		    !drvdata->onecell.clks))
+		return -ENOMEM;
+
+	for (n = 0; n < num_clocks; n++) {
+		drvdata->msynth[n].num = n;
+		drvdata->msynth[n].drvdata = drvdata;
+		drvdata->msynth[n].hw.init = &init;
+		memset(&init, 0, sizeof(init));
+		init.name = si5351_msynth_names[n];
+		init.ops = &si5351_msynth_ops;
+		init.flags = 0;
+		init.parent_names = parent_names;
+		init.num_parents = 2;
+		clk = devm_clk_register(&client->dev, &drvdata->msynth[n].hw);
+		if (IS_ERR(clk)) {
+			dev_err(&client->dev, "unable to register %s\n",
+				init.name);
+			return -EINVAL;
+		}
+	}
+
+	num_parents = (drvdata->variant == SI5351_VARIANT_C) ? 4 : 3;
+	parent_names[2] = si5351_input_names[0];
+	parent_names[3] = si5351_input_names[1];
+	for (n = 0; n < num_clocks; n++) {
+		parent_names[0] = si5351_msynth_names[n];
+		parent_names[1] = (n < 4) ? si5351_msynth_names[0] :
+			si5351_msynth_names[4];
+
+		drvdata->clkout[n].num = n;
+		drvdata->clkout[n].drvdata = drvdata;
+		drvdata->clkout[n].hw.init = &init;
+		memset(&init, 0, sizeof(init));
+		init.name = si5351_clkout_names[n];
+		init.ops = &si5351_clkout_ops;
+		init.flags = 0;
+		init.parent_names = parent_names;
+		init.num_parents = num_parents;
+		clk = devm_clk_register(&client->dev, &drvdata->clkout[n].hw);
+		if (IS_ERR(clk)) {
+			dev_err(&client->dev, "unable to register %s\n",
+				init.name);
+			return -EINVAL;
+		}
+		drvdata->onecell.clks[n] = clk;
+	}
+
+	/* setup clock setup from DT */
+	si5351_dt_setup(client, drvdata);
+
+	ret = of_clk_add_provider(client->dev.of_node, of_clk_src_onecell_get,
+				  &drvdata->onecell);
+	if (ret) {
+		dev_err(&client->dev, "unable to add clk provider\n");
+		return ret;
+	}
+
+	return 0;
+}
+
+static const struct i2c_device_id si5351_i2c_ids[] = {
+	{ "silabs,si5351", 0 },
+	{ }
+};
+MODULE_DEVICE_TABLE(i2c, si5351_i2c_ids);
+
+static struct i2c_driver si5351_driver = {
+	.driver = {
+		.name = "si5351",
+		.of_match_table = si5351_dt_ids,
+	},
+	.probe = si5351_i2c_probe,
+	.id_table = si5351_i2c_ids,
+};
+module_i2c_driver(si5351_driver);
+
+MODULE_AUTHOR("Sebastian Hesselbarth <sebastian.hesselbarth at gmail.de");
+MODULE_DESCRIPTION("Silicon Labs Si5351A/B/C clock generator driver");
+MODULE_LICENSE("GPL");
diff --git a/drivers/clk/clk-si5351.h b/drivers/clk/clk-si5351.h
new file mode 100644
index 0000000..424073c
--- /dev/null
+++ b/drivers/clk/clk-si5351.h
@@ -0,0 +1,155 @@
+/*
+ * clk-si5351.h: Silicon Laboratories Si5351A/B/C I2C Clock Generator
+ *
+ * Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
+ * Rabeeh Khoury <rabeeh at solid-run.com>
+ *
+ * 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.
+ */
+
+#ifndef _CLK_SI5351_H_
+#define _CLK_SI5351_H_
+
+#define SI5351_BUS_BASE_ADDR			0x60
+
+#define SI5351_PLL_VCO_MIN			600000000
+#define SI5351_PLL_VCO_MAX			900000000
+#define SI5351_MULTISYNTH_MIN_FREQ		1000000
+#define SI5351_MULTISYNTH_DIVBY4_FREQ		150000000
+#define SI5351_MULTISYNTH_MAX_FREQ		160000000
+#define SI5351_MULTISYNTH67_MAX_FREQ		SI5351_MULTISYNTH_DIVBY4_FREQ
+#define SI5351_CLKOUT_MIN_FREQ			8000
+#define SI5351_CLKOUT_MAX_FREQ			SI5351_MULTISYNTH_MAX_FREQ
+#define SI5351_CLKOUT67_MAX_FREQ		SI5351_MULTISYNTH67_MAX_FREQ
+
+#define SI5351_PLL_A_MIN			15
+#define SI5351_PLL_A_MAX			90
+#define SI5351_PLL_B_MAX			(SI5351_PLL_C_MAX-1)
+#define SI5351_PLL_C_MAX			1048575
+#define SI5351_MULTISYNTH_A_MIN			6
+#define SI5351_MULTISYNTH_A_MAX			1800
+#define SI5351_MULTISYNTH67_A_MAX		254
+#define SI5351_MULTISYNTH_B_MAX			(SI5351_MULTISYNTH_C_MAX-1)
+#define SI5351_MULTISYNTH_C_MAX			1048575
+#define SI5351_MULTISYNTH_P1_MAX		((1<<18)-1)
+#define SI5351_MULTISYNTH_P2_MAX		((1<<20)-1)
+#define SI5351_MULTISYNTH_P3_MAX		((1<<20)-1)
+
+#define SI5351_DEVICE_STATUS			0
+#define SI5351_INTERRUPT_STATUS			1
+#define SI5351_INTERRUPT_MASK			2
+#define  SI5351_STATUS_SYS_INIT			(1<<7)
+#define  SI5351_STATUS_LOL_B			(1<<6)
+#define  SI5351_STATUS_LOL_A			(1<<5)
+#define  SI5351_STATUS_LOS			(1<<4)
+#define SI5351_OUTPUT_ENABLE_CTRL		3
+#define SI5351_OEB_PIN_ENABLE_CTRL		9
+#define SI5351_PLL_INPUT_SOURCE			15
+#define  SI5351_CLKIN_DIV_MASK			(3<<6)
+#define  SI5351_CLKIN_DIV_1			(0<<6)
+#define  SI5351_CLKIN_DIV_2			(1<<6)
+#define  SI5351_CLKIN_DIV_4			(2<<6)
+#define  SI5351_CLKIN_DIV_8			(3<<6)
+#define  SI5351_PLLB_SOURCE			(1<<3)
+#define  SI5351_PLLA_SOURCE			(1<<2)
+
+#define SI5351_CLK0_CTRL			16
+#define SI5351_CLK1_CTRL			17
+#define SI5351_CLK2_CTRL			18
+#define SI5351_CLK3_CTRL			19
+#define SI5351_CLK4_CTRL			20
+#define SI5351_CLK5_CTRL			21
+#define SI5351_CLK6_CTRL			22
+#define SI5351_CLK7_CTRL			23
+#define  SI5351_CLK_POWERDOWN			(1<<7)
+#define  SI5351_CLK_INTEGER_MODE		(1<<6)
+#define  SI5351_CLK_PLL_SELECT			(1<<5)
+#define  SI5351_CLK_INVERT			(1<<4)
+#define  SI5351_CLK_INPUT_MASK			(3<<2)
+#define  SI5351_CLK_INPUT_XTAL			(0<<2)
+#define  SI5351_CLK_INPUT_CLKIN			(1<<2)
+#define  SI5351_CLK_INPUT_MULTISYNTH_0_4	(2<<2)
+#define  SI5351_CLK_INPUT_MULTISYNTH_N		(3<<2)
+#define  SI5351_CLK_DRIVE_MASK			(3<<0)
+#define  SI5351_CLK_DRIVE_2MA			(0<<0)
+#define  SI5351_CLK_DRIVE_4MA			(1<<0)
+#define  SI5351_CLK_DRIVE_6MA			(2<<0)
+#define  SI5351_CLK_DRIVE_8MA			(3<<0)
+
+#define SI5351_CLK3_0_DISABLE_STATE		24
+#define SI5351_CLK7_4_DISABLE_STATE		25
+#define  SI5351_CLK_DISABLE_STATE_LOW		0
+#define  SI5351_CLK_DISABLE_STATE_HIGH		1
+#define  SI5351_CLK_DISABLE_STATE_FLOAT		2
+#define  SI5351_CLK_DISABLE_STATE_NEVER		3
+
+#define SI5351_PARAMETERS_LENGTH		8
+#define SI5351_PLLA_PARAMETERS			26
+#define SI5351_PLLB_PARAMETERS			34
+#define SI5351_CLK0_PARAMETERS			42
+#define SI5351_CLK1_PARAMETERS			50
+#define SI5351_CLK2_PARAMETERS			58
+#define SI5351_CLK3_PARAMETERS			66
+#define SI5351_CLK4_PARAMETERS			74
+#define SI5351_CLK5_PARAMETERS			82
+#define SI5351_CLK6_PARAMETERS			90
+#define SI5351_CLK7_PARAMETERS			91
+#define SI5351_CLK6_7_OUTPUT_DIVIDER		92
+#define  SI5351_OUTPUT_CLK_DIV_MASK		(7 << 4)
+#define  SI5351_OUTPUT_CLK6_DIV_MASK		(7 << 0)
+#define  SI5351_OUTPUT_CLK_DIV_SHIFT		4
+#define  SI5351_OUTPUT_CLK_DIV6_SHIFT		0
+#define  SI5351_OUTPUT_CLK_DIV_1		0
+#define  SI5351_OUTPUT_CLK_DIV_2		1
+#define  SI5351_OUTPUT_CLK_DIV_4		2
+#define  SI5351_OUTPUT_CLK_DIV_8		3
+#define  SI5351_OUTPUT_CLK_DIV_16		4
+#define  SI5351_OUTPUT_CLK_DIV_32		5
+#define  SI5351_OUTPUT_CLK_DIV_64		6
+#define  SI5351_OUTPUT_CLK_DIV_128		7
+#define  SI5351_OUTPUT_CLK_DIVBY4		(3<<2)
+
+#define SI5351_SSC_PARAM0			149
+#define SI5351_SSC_PARAM1			150
+#define SI5351_SSC_PARAM2			151
+#define SI5351_SSC_PARAM3			152
+#define SI5351_SSC_PARAM4			153
+#define SI5351_SSC_PARAM5			154
+#define SI5351_SSC_PARAM6			155
+#define SI5351_SSC_PARAM7			156
+#define SI5351_SSC_PARAM8			157
+#define SI5351_SSC_PARAM9			158
+#define SI5351_SSC_PARAM10			159
+#define SI5351_SSC_PARAM11			160
+#define SI5351_SSC_PARAM12			161
+
+#define SI5351_VXCO_PARAMETERS_LOW		162
+#define SI5351_VXCO_PARAMETERS_MID		163
+#define SI5351_VXCO_PARAMETERS_HIGH		164
+
+#define SI5351_CLK0_PHASE_OFFSET		165
+#define SI5351_CLK1_PHASE_OFFSET		166
+#define SI5351_CLK2_PHASE_OFFSET		167
+#define SI5351_CLK3_PHASE_OFFSET		168
+#define SI5351_CLK4_PHASE_OFFSET		169
+#define SI5351_CLK5_PHASE_OFFSET		170
+
+#define SI5351_PLL_RESET			177
+#define  SI5351_PLL_RESET_B			(1<<7)
+#define  SI5351_PLL_RESET_A			(1<<5)
+
+#define SI5351_CRYSTAL_LOAD			183
+#define  SI5351_CRYSTAL_LOAD_MASK		(3<<6)
+#define  SI5351_CRYSTAL_LOAD_6PF		(1<<6)
+#define  SI5351_CRYSTAL_LOAD_8PF		(2<<6)
+#define  SI5351_CRYSTAL_LOAD_10PF		(3<<6)
+
+#define SI5351_FANOUT_ENABLE			187
+#define  SI5351_CLKIN_ENABLE			(1<<7)
+#define  SI5351_XTAL_ENABLE			(1<<6)
+#define  SI5351_MULTISYNTH_ENABLE		(1<<4)
+
+#endif
-- 
1.7.10.4



From sfr at canb.auug.org.au  Fri Apr  5 01:58:04 2013
From: sfr at canb.auug.org.au (Stephen Rothwell)
Date: Fri, 5 Apr 2013 16:58:04 +1100
Subject: linux-next: manual merge of the arm-soc tree with the xilinx tree
In-Reply-To: <CAHTX3d++6JWTKWkGOfgJj10z1Xtx325YXNQ6eMJjM8HO4q1diw@mail.gmail.com>
References: <20130405153335.baf29606a97b1bee415f3546@canb.auug.org.au>
 <20130405153453.75b76d68fe9adc6e981e02fb@canb.auug.org.au>
 <CAHTX3d++6JWTKWkGOfgJj10z1Xtx325YXNQ6eMJjM8HO4q1diw@mail.gmail.com>
Message-ID: <20130405165804.c4def5754d316e5da691ceee@canb.auug.org.au>

Hi Michal,

On Fri, 5 Apr 2013 07:52:34 +0200 Michal Simek <monstr at monstr.eu> wrote:
>
> 2013/4/5 Stephen Rothwell <sfr at canb.auug.org.au>
> >
> > BTW, that xilinx tree commit has no "Signed-off-by" for the committer ...
> 
> Interesting that you can't see Rob's Signed-off-by line.

Rob was the author, you were the committer ...

$ git cat-file -p c79e33b3e828c79cfedf858ef7d4df96df5fece7
tree 1e5e352eb501a2afa173989415a8b4896d4999a5
parent ab8a98cff21aedb787934e8d366c9879ad0e824c
author Rob Herring <rob.herring at calxeda.com> 1360207067 -0600
committer Michal Simek <michal.simek at xilinx.com> 1365060716 +0200

ARM: smp_twd: convert to use CLKSRC_OF init

Now that we have OF based init with CLKSRC_OF, convert smp_twd init
function to use it and covert all callers of
twd_local_timer_of_register.

Signed-off-by: Rob Herring <rob.herring at calxeda.com>
Cc: Shawn Guo <shawn.guo at linaro.org>
Cc: Sascha Hauer <kernel at pengutronix.de>
Cc: Russell King <linux at arm.linux.org.uk>
Cc: Viresh Kumar <viresh.linux at gmail.com>
Cc: Shiraz Hashim <shiraz.hashim at st.com>
Cc: Srinidhi Kasagar <srinidhi.kasagar at stericsson.com>
Cc: John Stultz <johnstul at us.ibm.com>
Cc: Thomas Gleixner <tglx at linutronix.de>
Cc: linux-omap at vger.kernel.org
Cc: spear-devel at list.st.com
Reviewed-by: Stephen Warren <swarren at nvidia.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
Acked-by: Tony Lindgren <tony at atomide.com>
Acked-by: Linus Walleij <linus.walleij at linaro.org>

-- 
Cheers,
Stephen Rothwell                    sfr at canb.auug.org.au
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130405/5632d0f7/attachment.sig>

From thierry.reding at avionic-design.de  Fri Apr  5 02:03:51 2013
From: thierry.reding at avionic-design.de (Thierry Reding)
Date: Fri, 5 Apr 2013 08:03:51 +0200
Subject: [PATCH v3 07/12] PCI: tegra: Move PCIe driver to drivers/pci/host
In-Reply-To: <515DF0D9.40007@wwwdotorg.org>
References: <1365000318-28256-1-git-send-email-thierry.reding@avionic-design.de>
 <1365000318-28256-8-git-send-email-thierry.reding@avionic-design.de>
 <515DF096.2000703@wwwdotorg.org> <515DF0D9.40007@wwwdotorg.org>
Message-ID: <20130405060351.GA15848@avionic-0098.mockup.avionic-design.de>

On Thu, Apr 04, 2013 at 03:30:01PM -0600, Stephen Warren wrote:
> On 04/04/2013 03:28 PM, Stephen Warren wrote:
> > On 04/03/2013 08:45 AM, Thierry Reding wrote:
> >> Move the PCIe driver from arch/arm/mach-tegra into the drivers/pci/host
> >> directory. The motivation is to collect various host controller drivers
> >> in the same location in order to facilitate refactoring.
> >>
> >> The Tegra PCIe driver has been largely rewritten, both in order to turn
> >> it into a proper platform driver and to add MSI (based on code by
> >> Krishna Kishore <kthota at nvidia.com>) as well as device tree support.
> > 
> >>  arch/arm/boot/dts/tegra20.dtsi                     |   53 +
> > 
> > I guess this has to touch both the driver and the dtsi file so that
> > bisectabilty isn't broken? I guess that's OK.
> 
> Actually, can't you move all the *.dts/*.dtsi changes to the start of
> the series, then put the driver conversion patch last, to avoid any
> bisectability issues and still keep code and DT changes separate?

I'm not sure if that'll work. There's this oddity in the Harmony DTS
where the regulator at 3 is disabled with a comment that this is a hack
required until board-harmony-pcie.c is removed. If we change the DTS
before the driver rewrite I think that would break requesting the GPIO
in the board file.

A possible workaround I can think of is accessing the regulator from
board-harmony-pcie.c instead of the GPIO directly. But perhaps such an
attempt already failed (deferred probing getting in the way?).

Since it looks like this series will not make it into 3.10, maybe we
should try and at least get these things ironed out so that the merge
can be done more easily in 3.11. One big step in that direction would
obviously be if we could get the DTS changes merged already which, as
you point out, should be independent of the driver rewrite itself.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130405/7d95d3ec/attachment.sig>

From sfr at canb.auug.org.au  Fri Apr  5 02:05:01 2013
From: sfr at canb.auug.org.au (Stephen Rothwell)
Date: Fri, 5 Apr 2013 17:05:01 +1100
Subject: linux-next: manual merge of the arm-soc tree with the xilinx tree
In-Reply-To: <CAHTX3d+rpF4D+GiB7nipE3m=yYesyZE4aj+STrpmLccHGb16JA@mail.gmail.com>
References: <20130405153335.baf29606a97b1bee415f3546@canb.auug.org.au>
 <20130405153904.1fd5af8086cfede917c353af@canb.auug.org.au>
 <CAHTX3d+rpF4D+GiB7nipE3m=yYesyZE4aj+STrpmLccHGb16JA@mail.gmail.com>
Message-ID: <20130405170501.962d95be0c9ec9be1acd9012@canb.auug.org.au>

Hi Michal,

On Fri, 5 Apr 2013 07:53:35 +0200 Michal Simek <michal.simek at xilinx.com> wrote:
>
> 2013/4/5 Stephen Rothwell <sfr at canb.auug.org.au>
> 
> > The copy to "John Linn <John.Linn at xilinx.com>" (my listed contact for the
> > xilinx tree) bounced.  Who should I use now?
> >
> 
> It is me.
> Your contact should be
> michal.simek at xilinx.com

Noted, thanks.

-- 
Cheers,
Stephen Rothwell                    sfr at canb.auug.org.au
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130405/6184b0ff/attachment.sig>

From horms+renesas at verge.net.au  Fri Apr  5 02:12:01 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri,  5 Apr 2013 15:12:01 +0900
Subject: [GIT PULL] Renesas ARM r8a7778 SoC update for v3.10
Message-ID: <1365142324-7286-1-git-send-email-horms+renesas@verge.net.au>

Hi Olof, Hi Arnd,

The following changes since commit 8585deb18580d04209a2986430aa0959ef38fce2:

  ARM: shmobile: r8a7790 SoC 64-bit DT support (2013-04-02 11:02:21 +0900)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas tags/renesas-soc-r8a7778-for-v3.10

for you to fetch changes up to 524219146a89aee5366326c225ccd71231419d89:

  ARM: shmobile: R8A7778: add Ether support (2013-04-05 10:57:05 +0900)

----------------------------------------------------------------
Renesas ARM r8a7778 SoC update for v3.10

Update to the r8a7778 SoC:
* Add SH Ethernet support
* Add r8a7778_init_irq_extpin() to allow configuration of IRQ0 - IRQ3
  - This is a requirement for SMSC ethernet support
* Cleanup: remove PLATFORM_INFO macro

This pull request is based on:
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas renesas-soc2-for-v3.10

----------------------------------------------------------------
Kuninori Morimoto (2):
      ARM: shmobile: r8a7778: remove pointless PLATFORM_INFO()
      ARM: shmobile: r8a7778: add r8a7778_init_irq_extpin()

Sergei Shtylyov (1):
      ARM: shmobile: R8A7778: add Ether support

 arch/arm/mach-shmobile/clock-r8a7778.c        |    3 +
 arch/arm/mach-shmobile/include/mach/r8a7778.h |    4 ++
 arch/arm/mach-shmobile/setup-r8a7778.c        |   83 ++++++++++++++++++++-----
 3 files changed, 74 insertions(+), 16 deletions(-)


From horms+renesas at verge.net.au  Fri Apr  5 02:12:02 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri,  5 Apr 2013 15:12:02 +0900
Subject: [PATCH 1/3] ARM: shmobile: r8a7778: remove pointless PLATFORM_INFO()
In-Reply-To: <1365142324-7286-1-git-send-email-horms+renesas@verge.net.au>
References: <1365142324-7286-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1365142324-7286-2-git-send-email-horms+renesas@verge.net.au>

From: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>

remove pointless PLATFORM_INFO() macro from setup-r8a7778,
and, used original platform_device_register_xxx()

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Acked-by: Magnus Damm <damm at opensource.se>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/setup-r8a7778.c |   26 +++++++++-----------------
 1 file changed, 9 insertions(+), 17 deletions(-)

diff --git a/arch/arm/mach-shmobile/setup-r8a7778.c b/arch/arm/mach-shmobile/setup-r8a7778.c
index 01c62be..57d6b0e 100644
--- a/arch/arm/mach-shmobile/setup-r8a7778.c
+++ b/arch/arm/mach-shmobile/setup-r8a7778.c
@@ -78,21 +78,13 @@ static struct sh_timer_config sh_tmu1_platform_data = {
 	.clocksource_rating	= 200,
 };
 
-#define PLATFORM_INFO(n, i)					\
-{								\
-	.parent		= &platform_bus,			\
-	.name		= #n,					\
-	.id		= i,					\
-	.res		= n ## i ## _resources,			\
-	.num_res	= ARRAY_SIZE(n ## i ##_resources),	\
-	.data		= &n ## i ##_platform_data,		\
-	.size_data	= sizeof(n ## i ## _platform_data),	\
-}
-
-struct platform_device_info platform_devinfo[] = {
-	PLATFORM_INFO(sh_tmu, 0),
-	PLATFORM_INFO(sh_tmu, 1),
-};
+#define r8a7778_register_tmu(idx)			\
+	platform_device_register_resndata(		\
+		&platform_bus, "sh_tmu", idx,		\
+		sh_tmu##idx##_resources,		\
+		ARRAY_SIZE(sh_tmu##idx##_resources),	\
+		&sh_tmu##idx##_platform_data,		\
+		sizeof(sh_tmu##idx##_platform_data))
 
 void __init r8a7778_add_standard_devices(void)
 {
@@ -114,8 +106,8 @@ void __init r8a7778_add_standard_devices(void)
 					      &scif_platform_data[i],
 					      sizeof(struct plat_sci_port));
 
-	for (i = 0; i < ARRAY_SIZE(platform_devinfo); i++)
-		platform_device_register_full(&platform_devinfo[i]);
+	r8a7778_register_tmu(0);
+	r8a7778_register_tmu(1);
 }
 
 #define INT2SMSKCR0	0x82288 /* 0xfe782288 */
-- 
1.7.10.4



From horms+renesas at verge.net.au  Fri Apr  5 02:12:04 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri,  5 Apr 2013 15:12:04 +0900
Subject: [PATCH 3/3] ARM: shmobile: R8A7778: add Ether support
In-Reply-To: <1365142324-7286-1-git-send-email-horms+renesas@verge.net.au>
References: <1365142324-7286-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1365142324-7286-4-git-send-email-horms+renesas@verge.net.au>

From: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

Add Ether clock and platform device for R8A7778 SoC; add a function to register
this device with board-specific platform data.

Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/clock-r8a7778.c        |    3 +++
 arch/arm/mach-shmobile/include/mach/r8a7778.h |    3 +++
 arch/arm/mach-shmobile/setup-r8a7778.c        |   15 +++++++++++++++
 3 files changed, 21 insertions(+)

diff --git a/arch/arm/mach-shmobile/clock-r8a7778.c b/arch/arm/mach-shmobile/clock-r8a7778.c
index f1277f4..cd68552 100644
--- a/arch/arm/mach-shmobile/clock-r8a7778.c
+++ b/arch/arm/mach-shmobile/clock-r8a7778.c
@@ -58,11 +58,13 @@ static struct clk *main_clks[] = {
 };
 
 enum {
+	MSTP114,
 	MSTP026, MSTP025, MSTP024, MSTP023, MSTP022, MSTP021,
 	MSTP016, MSTP015,
 	MSTP_NR };
 
 static struct clk mstp_clks[MSTP_NR] = {
+	[MSTP114] = SH_CLK_MSTP32(&clkp, MSTPCR1, 14, 0), /* Ether */
 	[MSTP026] = SH_CLK_MSTP32(&clkp, MSTPCR0, 26, 0), /* SCIF0 */
 	[MSTP025] = SH_CLK_MSTP32(&clkp, MSTPCR0, 25, 0), /* SCIF1 */
 	[MSTP024] = SH_CLK_MSTP32(&clkp, MSTPCR0, 24, 0), /* SCIF2 */
@@ -75,6 +77,7 @@ static struct clk mstp_clks[MSTP_NR] = {
 
 static struct clk_lookup lookups[] = {
 	/* MSTP32 clocks */
+	CLKDEV_DEV_ID("sh-eth",	&mstp_clks[MSTP114]), /* Ether */
 	CLKDEV_DEV_ID("sh-sci.0", &mstp_clks[MSTP026]), /* SCIF0 */
 	CLKDEV_DEV_ID("sh-sci.1", &mstp_clks[MSTP025]), /* SCIF1 */
 	CLKDEV_DEV_ID("sh-sci.2", &mstp_clks[MSTP024]), /* SCIF2 */
diff --git a/arch/arm/mach-shmobile/include/mach/r8a7778.h b/arch/arm/mach-shmobile/include/mach/r8a7778.h
index e0c6205..951149e 100644
--- a/arch/arm/mach-shmobile/include/mach/r8a7778.h
+++ b/arch/arm/mach-shmobile/include/mach/r8a7778.h
@@ -18,8 +18,11 @@
 #ifndef __ASM_R8A7778_H__
 #define __ASM_R8A7778_H__
 
+#include <linux/sh_eth.h>
+
 extern void r8a7778_add_standard_devices(void);
 extern void r8a7778_add_standard_devices_dt(void);
+extern void r8a7778_add_ether_device(struct sh_eth_plat_data *pdata);
 extern void r8a7778_init_delay(void);
 extern void r8a7778_init_irq(void);
 extern void r8a7778_init_irq_dt(void);
diff --git a/arch/arm/mach-shmobile/setup-r8a7778.c b/arch/arm/mach-shmobile/setup-r8a7778.c
index 2882305..30b4a33 100644
--- a/arch/arm/mach-shmobile/setup-r8a7778.c
+++ b/arch/arm/mach-shmobile/setup-r8a7778.c
@@ -3,6 +3,7 @@
  *
  * Copyright (C) 2013  Renesas Solutions Corp.
  * Copyright (C) 2013  Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
+ * Copyright (C) 2013  Cogent Embedded, Inc.
  *
  * 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
@@ -79,6 +80,12 @@ static struct sh_timer_config sh_tmu1_platform_data = {
 	.clocksource_rating	= 200,
 };
 
+/* Ether */
+static struct resource ether_resources[] = {
+	DEFINE_RES_MEM(0xfde00000, 0x400),
+	DEFINE_RES_IRQ(gic_iid(0x89)),
+};
+
 #define r8a7778_register_tmu(idx)			\
 	platform_device_register_resndata(		\
 		&platform_bus, "sh_tmu", idx,		\
@@ -111,6 +118,14 @@ void __init r8a7778_add_standard_devices(void)
 	r8a7778_register_tmu(1);
 }
 
+void __init r8a7778_add_ether_device(struct sh_eth_plat_data *pdata)
+{
+	platform_device_register_resndata(&platform_bus, "sh_eth", -1,
+					  ether_resources,
+					  ARRAY_SIZE(ether_resources),
+					  pdata, sizeof(*pdata));
+}
+
 static struct renesas_intc_irqpin_config irqpin_platform_data = {
 	.irq_base = irq_pin(0), /* IRQ0 -> IRQ3 */
 	.sense_bitfield_width = 2,
-- 
1.7.10.4



From horms+renesas at verge.net.au  Fri Apr  5 02:12:03 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri,  5 Apr 2013 15:12:03 +0900
Subject: [PATCH 2/3] ARM: shmobile: r8a7778: add r8a7778_init_irq_extpin()
In-Reply-To: <1365142324-7286-1-git-send-email-horms+renesas@verge.net.au>
References: <1365142324-7286-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1365142324-7286-3-git-send-email-horms+renesas@verge.net.au>

From: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>

This patch adds r8a7778_init_irq_extpin() for IRQ0 - IRQ3.
But this patch doesn't enable DT settings on r8a7778.dts,
because R8A7778 chip external IRQ depends on
IRQ0 - IRQ3 pin encoding which came from platform board
implementation.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Acked-by: Magnus Damm <damm at opensource.se>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/include/mach/r8a7778.h |    1 +
 arch/arm/mach-shmobile/setup-r8a7778.c        |   44 +++++++++++++++++++++++++
 2 files changed, 45 insertions(+)

diff --git a/arch/arm/mach-shmobile/include/mach/r8a7778.h b/arch/arm/mach-shmobile/include/mach/r8a7778.h
index a755dca..e0c6205 100644
--- a/arch/arm/mach-shmobile/include/mach/r8a7778.h
+++ b/arch/arm/mach-shmobile/include/mach/r8a7778.h
@@ -24,5 +24,6 @@ extern void r8a7778_init_delay(void);
 extern void r8a7778_init_irq(void);
 extern void r8a7778_init_irq_dt(void);
 extern void r8a7778_clock_init(void);
+extern void r8a7778_init_irq_extpin(int irlm);
 
 #endif /* __ASM_R8A7778_H__ */
diff --git a/arch/arm/mach-shmobile/setup-r8a7778.c b/arch/arm/mach-shmobile/setup-r8a7778.c
index 57d6b0e..2882305 100644
--- a/arch/arm/mach-shmobile/setup-r8a7778.c
+++ b/arch/arm/mach-shmobile/setup-r8a7778.c
@@ -23,6 +23,7 @@
 #include <linux/irqchip/arm-gic.h>
 #include <linux/of.h>
 #include <linux/of_platform.h>
+#include <linux/platform_data/irq-renesas-intc-irqpin.h>
 #include <linux/platform_device.h>
 #include <linux/irqchip.h>
 #include <linux/serial_sci.h>
@@ -110,6 +111,49 @@ void __init r8a7778_add_standard_devices(void)
 	r8a7778_register_tmu(1);
 }
 
+static struct renesas_intc_irqpin_config irqpin_platform_data = {
+	.irq_base = irq_pin(0), /* IRQ0 -> IRQ3 */
+	.sense_bitfield_width = 2,
+};
+
+static struct resource irqpin_resources[] = {
+	DEFINE_RES_MEM(0xfe78001c, 4), /* ICR1 */
+	DEFINE_RES_MEM(0xfe780010, 4), /* INTPRI */
+	DEFINE_RES_MEM(0xfe780024, 4), /* INTREQ */
+	DEFINE_RES_MEM(0xfe780044, 4), /* INTMSK0 */
+	DEFINE_RES_MEM(0xfe780064, 4), /* INTMSKCLR0 */
+	DEFINE_RES_IRQ(gic_iid(0x3b)), /* IRQ0 */
+	DEFINE_RES_IRQ(gic_iid(0x3c)), /* IRQ1 */
+	DEFINE_RES_IRQ(gic_iid(0x3d)), /* IRQ2 */
+	DEFINE_RES_IRQ(gic_iid(0x3e)), /* IRQ3 */
+};
+
+void __init r8a7778_init_irq_extpin(int irlm)
+{
+	void __iomem *icr0 = ioremap_nocache(0xfe780000, PAGE_SIZE);
+	unsigned long tmp;
+
+	if (!icr0) {
+		pr_warn("r8a7778: unable to setup external irq pin mode\n");
+		return;
+	}
+
+	tmp = ioread32(icr0);
+	if (irlm)
+		tmp |= 1 << 23; /* IRQ0 -> IRQ3 as individual pins */
+	else
+		tmp &= ~(1 << 23); /* IRL mode - not supported */
+	tmp |= (1 << 21); /* LVLMODE = 1 */
+	iowrite32(tmp, icr0);
+	iounmap(icr0);
+
+	if (irlm)
+		platform_device_register_resndata(
+			&platform_bus, "renesas_intc_irqpin", -1,
+			irqpin_resources, ARRAY_SIZE(irqpin_resources),
+			&irqpin_platform_data, sizeof(irqpin_platform_data));
+}
+
 #define INT2SMSKCR0	0x82288 /* 0xfe782288 */
 #define INT2SMSKCR1	0x8228c /* 0xfe78228c */
 
-- 
1.7.10.4



From tim at krieglstein.org  Fri Apr  5 02:13:02 2013
From: tim at krieglstein.org (Tim Sander)
Date: Fri, 05 Apr 2013 08:13:02 +0200
Subject: 3.8 no mach include directory anymore?
Message-ID: <15525047.PsIxlFA1vB@dabox>

Hi

I have a small driver which uses the MX35_IO_ADDRESS which had been defined in
#include <mach/mx35.h>
but while the mx35.h file still exist the include directory has vanished?

Any idea how to get the module compiling again with 3.8?

Thanks
Tim


From padma.v at samsung.com  Fri Apr  5 02:23:47 2013
From: padma.v at samsung.com (Padmavathi Venna)
Date: Fri, 05 Apr 2013 11:53:47 +0530
Subject: [PATCH 1/3] clk: exynos: register audio subsystem clocks using common
 clock framework
Message-ID: <1365143029-16936-1-git-send-email-padma.v@samsung.com>

Audio subsystem is introduced in exynos platforms. This has seperate
clock controller which can control i2s0 and pcm0 clocks. This patch
registers the audio subsystem clocks with the common clock framework.

Signed-off-by: Padmavathi Venna <padma.v at samsung.com>
---
 drivers/clk/samsung/Makefile           |    1 +
 drivers/clk/samsung/clk-exynos-audss.c |  139 ++++++++++++++++++++++++++++++++
 2 files changed, 140 insertions(+), 0 deletions(-)
 create mode 100644 drivers/clk/samsung/clk-exynos-audss.c

diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile
index b7c232e..1876810 100644
--- a/drivers/clk/samsung/Makefile
+++ b/drivers/clk/samsung/Makefile
@@ -6,3 +6,4 @@ obj-$(CONFIG_COMMON_CLK)	+= clk.o clk-pll.o
 obj-$(CONFIG_ARCH_EXYNOS4)	+= clk-exynos4.o
 obj-$(CONFIG_SOC_EXYNOS5250)	+= clk-exynos5250.o
 obj-$(CONFIG_SOC_EXYNOS5440)	+= clk-exynos5440.o
+obj-$(CONFIG_ARCH_EXYNOS)	+= clk-exynos-audss.o
diff --git a/drivers/clk/samsung/clk-exynos-audss.c b/drivers/clk/samsung/clk-exynos-audss.c
new file mode 100644
index 0000000..d7f9aa8
--- /dev/null
+++ b/drivers/clk/samsung/clk-exynos-audss.c
@@ -0,0 +1,139 @@
+/*
+ * Copyright (c) 2013 Samsung Electronics Co., Ltd.
+ * Author: Padmavathi Venna <padma.v at samsung.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.
+ *
+ * Common Clock Framework support for Audio clks.
+*/
+
+#include <linux/clkdev.h>
+#include <linux/io.h>
+#include <linux/clk-provider.h>
+#include <linux/of_address.h>
+#include <linux/syscore_ops.h>
+
+static DEFINE_SPINLOCK(lock);
+static struct clk **clk_table;
+static void __iomem *reg_base;
+#ifdef CONFIG_OF
+static struct clk_onecell_data clk_data;
+#endif
+
+#define ASS_CLK_SRC 0x0
+#define ASS_CLK_DIV 0x4
+#define ASS_CLK_GATE 0x8
+
+static unsigned long reg_save[][2] = {
+	{ASS_CLK_SRC,  0x0},
+	{ASS_CLK_DIV,  0x0},
+	{ASS_CLK_GATE, 0x0},
+};
+
+/*
+ * Let each supported clock get a unique id. This id is used to lookup the clock
+ * for device tree based platforms.
+ *
+ * When adding a new clock to this list, it is advised to add it to the end.
+ * That is because the device tree source file is referring to these ids and
+ * any change in the sequence number of existing clocks will require
+ * corresponding change in the device tree files. This limitation would go away
+ * when pre-processor support for dtc would be available.
+ */
+enum exynos_audss_clks {
+	/* audss clocks */
+	mout_audss, mout_i2s,
+	dout_srp, dout_bus, dout_i2s,
+	srp_clk, i2s_bus, sclk_i2s0,
+
+	nr_clks,
+};
+
+/* list of all parent clock list */
+static const char *mout_audss_p[] = { "fin_pll", "fout_epll" };
+static const char *mout_i2s_p[] = { "mout_audss", "cdclk0", "sclk_audio0" };
+
+#ifdef CONFIG_PM_SLEEP
+static int exynos_audss_clk_suspend(void)
+{
+	int i;
+
+	for (i = 0; i < 3; i++)
+		reg_save[i][1] = __raw_readl(reg_base + reg_save[i][0]);
+
+	return 0;
+}
+
+static void exynos_audss_clk_resume(void)
+{
+	int i;
+
+	for (i = 0; i < 3; i++)
+		__raw_writel(reg_save[i][1], reg_base + reg_save[i][0]);
+}
+
+static struct syscore_ops exynos_audss_clk_syscore_ops = {
+	.suspend	= exynos_audss_clk_suspend,
+	.resume		= exynos_audss_clk_resume,
+};
+#endif /* CONFIG_PM_SLEEP */
+
+/* register exynos_audss clocks */
+void __init exynos_audss_clk_init(struct device_node *np)
+{
+	if (np) {
+		reg_base = of_iomap(np, 0);
+		if (!reg_base)
+			panic("%s: failed to map registers\n", __func__);
+	} else
+		panic("%s: unable to determine soc\n", __func__);
+
+	clk_table = kzalloc(sizeof(struct clk *) * nr_clks, GFP_KERNEL);
+	if (!clk_table)
+		panic("could not allocate clock lookup table\n");
+
+	clk_data.clks = clk_table;
+	clk_data.clk_num = nr_clks;
+	of_clk_add_provider(np, of_clk_src_onecell_get, &clk_data);
+
+	clk_table[mout_audss] = clk_register_mux(NULL, "mout_audss",
+				mout_audss_p, ARRAY_SIZE(mout_audss_p), 0,
+				reg_base + ASS_CLK_SRC, 0, 1, 0, &lock);
+	clk_register_clkdev(clk_table[mout_audss], "mout_audss", NULL);
+
+	clk_table[mout_i2s] = clk_register_mux(NULL, "mout_i2s", mout_i2s_p,
+				ARRAY_SIZE(mout_i2s_p), 0,
+				reg_base + ASS_CLK_SRC, 2, 2, 0, &lock);
+	clk_register_clkdev(clk_table[mout_i2s], "mout_i2s", NULL);
+
+	clk_table[dout_srp] = clk_register_divider(NULL, "dout_srp",
+				"mout_audss", 0, reg_base + ASS_CLK_DIV, 0, 4,
+				0, &lock);
+
+	clk_table[dout_bus] = clk_register_divider(NULL, "dout_bus",
+				"dout_srp", 0, reg_base + ASS_CLK_DIV, 4, 4, 0,
+				&lock);
+
+	clk_table[dout_i2s] = clk_register_divider(NULL, "dout_i2s",
+				"mout_i2s", 0, reg_base + ASS_CLK_DIV, 8, 4, 0,
+				&lock);
+
+	clk_table[srp_clk] = clk_register_gate(NULL, "srp_clk", "dout_srp",
+				CLK_SET_RATE_PARENT, reg_base + ASS_CLK_GATE, 0,
+				0, &lock);
+
+	clk_table[i2s_bus] = clk_register_gate(NULL, "i2s_bus", "dout_bus",
+				CLK_SET_RATE_PARENT, reg_base + ASS_CLK_GATE, 2,
+				0, &lock);
+
+	clk_table[sclk_i2s0] = clk_register_gate(NULL, "sclk_i2s0", "dout_i2s",
+				CLK_SET_RATE_PARENT, reg_base + ASS_CLK_GATE, 3,
+				0, &lock);
+#ifdef CONFIG_PM_SLEEP
+	register_syscore_ops(&exynos_audss_clk_syscore_ops);
+#endif
+	pr_info("Exynos: Audss: clock setup completed\n");
+}
+CLK_OF_DECLARE(exynos_audss_clk, "samsung,exynos-audss-clock", exynos_audss_clk_init);
-- 
1.7.4.4



From padma.v at samsung.com  Fri Apr  5 02:23:48 2013
From: padma.v at samsung.com (Padmavathi Venna)
Date: Fri, 05 Apr 2013 11:53:48 +0530
Subject: [PATCH 2/3] ARM: dts: add Exynos audio subsystem clock controller node
In-Reply-To: <1365143029-16936-1-git-send-email-padma.v@samsung.com>
References: <1365143029-16936-1-git-send-email-padma.v@samsung.com>
Message-ID: <1365143029-16936-2-git-send-email-padma.v@samsung.com>

Audio subsystem introduced in exynos platforms which has a
internal clock controller. This patch adds a node for the same.

Signed-off-by: Padmavathi Venna <padma.v at samsung.com>
---
 arch/arm/boot/dts/exynos5250.dtsi |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi
index 7751e69..14d454c 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -67,6 +67,12 @@
 		#clock-cells = <1>;
 	};
 
+	clock_audss: audss-clock-controller at 0x03810000 {
+		compatible = "samsung,exynos-audss-clock";
+		reg = <0x03810000 0x100>;
+		#clock-cells = <1>;
+	};
+
 	gic:interrupt-controller at 10481000 {
 		compatible = "arm,cortex-a9-gic";
 		#interrupt-cells = <3>;
-- 
1.7.4.4



From padma.v at samsung.com  Fri Apr  5 02:23:49 2013
From: padma.v at samsung.com (Padmavathi Venna)
Date: Fri, 05 Apr 2013 11:53:49 +0530
Subject: [PATCH 3/3] ARM: dts: add clock provider information for i2s0
 controller in Exynos5250
In-Reply-To: <1365143029-16936-1-git-send-email-padma.v@samsung.com>
References: <1365143029-16936-1-git-send-email-padma.v@samsung.com>
Message-ID: <1365143029-16936-3-git-send-email-padma.v@samsung.com>

Add clock lookup information for i2s0 controller on exynos5250 SoC.

Signed-off-by: Padmavathi Venna <padma.v at samsung.com>
---
 arch/arm/boot/dts/exynos5250.dtsi |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi
index 14d454c..08e3b3f 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -387,6 +387,8 @@
 			&pdma0 9
 			&pdma0 8>;
 		dma-names = "tx", "rx", "tx-sec";
+		clocks = <&clock_audss 6>, <&clock_audss 6>, <&clock_audss 7>;
+		clock-names = "iis", "i2s_opclk0", "i2s_opclk1";
 		samsung,supports-6ch;
 		samsung,supports-rstclr;
 		samsung,supports-secdai;
-- 
1.7.4.4



From santosh.shilimkar at ti.com  Fri Apr  5 02:26:54 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Fri, 5 Apr 2013 11:56:54 +0530
Subject: [PATCH] ARM: dts: OMAP4+: Correct L3 interrupts
In-Reply-To: <1365098790-9078-1-git-send-email-jon-hunter@ti.com>
References: <1365098790-9078-1-git-send-email-jon-hunter@ti.com>
Message-ID: <515E6EAE.9000107@ti.com>

On Thursday 04 April 2013 11:36 PM, Jon Hunter wrote:
> The L3 interrupt numbers are incorrect for OMAP4+ and are conflicting
> with some of the timer interrupts causing the allocation of timer
> interrupts to fail.
> 
> The problem is caused by adding 32 to the interrupt number for the L3
> interrupts to account for per processor interrupts (PPI) and software
> generated interrupts (SGI) which typically are mapped to the first 32
> interrupts in the ARM GIC. This is not necessary because the first
> parameter of the ARM GIC interrupt property specifies the GIC interrupt
> type (ie. SGI, PPI, etc). Hence, fix the interrupt number fo the L3
> interrupts by substracting 32.
> 
> Cc: Santosh Shilimkar <santosh.shilimkar at ti.com>
> Signed-off-by: Jon Hunter <jon-hunter at ti.com>
> ---
> 
> Please note that this problem is observed in Benoit's for_3.10/dts branch [1].
> 
> [1] http://git.kernel.org/cgit/linux/kernel/git/bcousson/linux-omap-dt.git
> 
Thats correct. I overlooked the 32 addition part. This patch should
also be pulled into Benoit's 3.10 tree.

For the patch,
Acked-by: Santosh Shilimkar <santosh.shilimkar at ti.com>



From santosh.shilimkar at ti.com  Fri Apr  5 02:35:36 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Fri, 5 Apr 2013 12:05:36 +0530
Subject: [PATCH 0/5] gpio/omap: 2nd batch of updates for v3.10
In-Reply-To: <1365106576-31816-1-git-send-email-jon-hunter@ti.com>
References: <1365106576-31816-1-git-send-email-jon-hunter@ti.com>
Message-ID: <515E70B8.6060903@ti.com>

On Friday 05 April 2013 01:46 AM, Jon Hunter wrote:
> Main change is ensuring that the state of a gpio bank is restored when
> booting with device-tree. The rest of the patches are clean-ups and one
> optimisation.
> 
> The patch modifying the *.dtsi files should go via Benoit Cousson's
> for_3.10/dts branch [1] as it is dependent on changes in his branch but
> I have included here for completeness.
> 
> Testing includes:
> - Boot testing on OMAP5912 OSK, OMAP2420 H4, OMAP3430 SDP, OMAP4430 SDP
>   and AM335x EVM.
> - Verified that GPIO interrupts are working on OMAP5912 OSK, OMAP2420 H4,
>   OMAP3430 SDP and OMAP4430 SDP by making sure networking was working
>   correctly as these boards use a GPIO with the ethernet chips. Also
>   checked /proc/interrupts to ensure GPIO interrupt counts are
>   incrementing as expected.
> 
> [1] http://git.kernel.org/cgit/linux/kernel/git/bcousson/linux-omap-dt.git
> 
> Jon Hunter (4):
>   gpio/omap: free irq domain in probe() failure paths
>   gpio/omap: optimise interrupt service routine
>   gpio/omap: force restore if context loss is not detectable
>   ARM: dts: OMAP2+: Identify GPIO banks that are always powered
> 
> Tarun Kanti DebBarma (1):
>   gpio/omap: remove extra context restores in *_runtime_resume()
>

Thanks Jon for pulling the fixes. I suggest you to split the series so
that 'gpio/omap:*' can be pulled by Grant and 'ARM: dts:*' by Benoit.

All the 'gpio/omap:*' patches in the series looks fine to me.
FWIW,
Acked-by: Santosh Shilimkar <santosh.shilimkar at ti.com>




From marex at denx.de  Fri Apr  5 02:38:42 2013
From: marex at denx.de (Marek Vasut)
Date: Fri, 5 Apr 2013 08:38:42 +0200
Subject: [PATCH] ARM: dts: imx23-olinuxino: Set the sdcard as non-removable
In-Reply-To: <1365135413-31493-1-git-send-email-aletes.xgr@gmail.com>
References: <1365135413-31493-1-git-send-email-aletes.xgr@gmail.com>
Message-ID: <201304050838.42571.marex@denx.de>

Dear Alexandre Pereira da Silva,

> The imx23-olinuxino sdcard doesn't support card detect.
> 
> Signed-off-by: Alexandre Pereira da Silva <aletes.xgr at gmail.com>
> ---
>  arch/arm/boot/dts/imx23-olinuxino.dts |    1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/boot/dts/imx23-olinuxino.dts
> b/arch/arm/boot/dts/imx23-olinuxino.dts index e7484e4..03f55c2 100644
> --- a/arch/arm/boot/dts/imx23-olinuxino.dts
> +++ b/arch/arm/boot/dts/imx23-olinuxino.dts
> @@ -29,6 +29,7 @@
>  				pinctrl-names = "default";
>  				pinctrl-0 = <&mmc0_4bit_pins_a 
&mmc0_pins_fixup>;
>  				bus-width = <4>;
> +				non-removable;
>  				status = "okay";
>  			};

The card on mx23 olinuxino seems perfectly removable to me ... on all possible 
models and even prototypes and hybrids too ;-)

Best regards,
Marek Vasut


From padma.v at samsung.com  Fri Apr  5 02:40:43 2013
From: padma.v at samsung.com (Padmavathi Venna)
Date: Fri, 05 Apr 2013 12:10:43 +0530
Subject: [PATCH 0/3] clk: Exynos: Register audio subsytem clocks using common
 clk framework
Message-ID: <1365144043-17101-1-git-send-email-padma.v@samsung.com>

Samsung Exynos SoC has a separate subsystem for audio. This subsystem
has a internal clock controller which controls i2s0 and pcm0 clocks.
This patch series adds the Samsung Exynos SoC audio subsytem clock code
to the common clock framework and provides the I2S0 clock information in
the dtsi file.

Padmavathi Venna (3):
  clk: exynos: register audio subsystem clocks using common clock
    framework
  ARM: dts: add Exynos audio subsystem clock controller node
  ARM: dts: add clock provider information for i2s0 controller in
    Exynos5250

 arch/arm/boot/dts/exynos5250.dtsi      |    8 ++
 drivers/clk/samsung/Makefile           |    1 +
 drivers/clk/samsung/clk-exynos-audss.c |  139 ++++++++++++++++++++++++++++++++
 3 files changed, 148 insertions(+), 0 deletions(-)
 create mode 100644 drivers/clk/samsung/clk-exynos-audss.c

-- 
1.7.4.4



From kgene.kim at samsung.com  Fri Apr  5 02:48:29 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Fri, 05 Apr 2013 15:48:29 +0900
Subject: [PATCH 07/18] cpufreq: s3c24xx: move cpufreq driver to
 drivers/cpufreq
In-Reply-To: <927100d30bf40d4fec477cc7d8d464669a22d167.1365079581.git.viresh.kumar@linaro.org>
References: <cover.1365079581.git.viresh.kumar@linaro.org>
 <927100d30bf40d4fec477cc7d8d464669a22d167.1365079581.git.viresh.kumar@linaro.org>
Message-ID: <2a5901ce31c9$95160980$bf421c80$%kim@samsung.com>

Viresh Kumar wrote:
> 
> This patch moves cpufreq driver of Samsung's ARM based s3c24xx platform to
> drivers/cpufreq.
> 
> Cc: Ben Dooks <ben-linux at fluff.org>
> Cc: Kukjin Kim <kgene.kim at samsung.com>
> Cc: linux-samsung-soc at vger.kernel.org
> Cc: linux-arm-kernel at lists.infradead.org
> Signed-off-by: Viresh Kumar <viresh.kumar at linaro.org>
> Acked-by: Arnd Bergmann <arnd at arndb.de>
> ---
>  arch/arm/Kconfig                                   | 46 ---------------
>  arch/arm/mach-s3c24xx/Kconfig                      | 66
+++++++++-------------
>  arch/arm/mach-s3c24xx/Makefile                     |  6 --
>  arch/arm/mach-s3c24xx/{ => include/mach}/s3c2412.h |  0
>  arch/arm/mach-s3c24xx/iotiming-s3c2412.c           |  2 +-
>  arch/arm/plat-samsung/include/plat/cpu-freq-core.h | 10 ++--
>  arch/arm/plat-samsung/include/plat/cpu-freq.h      |  6 +-
>  drivers/cpufreq/Kconfig.arm                        | 58
+++++++++++++++++++
>  drivers/cpufreq/Makefile                           |  5 ++
>  .../cpufreq/s3c2410-cpufreq.c                      |  0
>  .../cpufreq/s3c2412-cpufreq.c                      |  3 +-
>  .../cpufreq/s3c2440-cpufreq.c                      |  0
>  .../cpufreq/s3c24xx-cpufreq-debugfs.c              |  0
>  .../cpufreq.c => drivers/cpufreq/s3c24xx-cpufreq.c |  0
>  14 files changed, 100 insertions(+), 102 deletions(-)
>  rename arch/arm/mach-s3c24xx/{ => include/mach}/s3c2412.h (100%)
>  rename arch/arm/mach-s3c24xx/cpufreq-s3c2410.c =>
> drivers/cpufreq/s3c2410-cpufreq.c (100%)
>  rename arch/arm/mach-s3c24xx/cpufreq-s3c2412.c =>
> drivers/cpufreq/s3c2412-cpufreq.c (99%)
>  rename arch/arm/mach-s3c24xx/cpufreq-s3c2440.c =>
> drivers/cpufreq/s3c2440-cpufreq.c (100%)
>  rename arch/arm/mach-s3c24xx/cpufreq-debugfs.c =>
> drivers/cpufreq/s3c24xx-cpufreq-debugfs.c (100%)
>  rename arch/arm/mach-s3c24xx/cpufreq.c => drivers/cpufreq/s3c24xx-
> cpufreq.c (100%)
> 
Basically, this moving looks good to me, but should be re-worked based on
for-next of samsung tree because this touches too many samsung stuff so this
should be sent to upstream via samsung tree.

See below,

Applying: cpufreq: s3c24xx: move cpufreq driver to drivers/cpufreq
error: patch failed: arch/arm/Kconfig:2166
error: arch/arm/Kconfig: patch does not apply
error: patch failed: arch/arm/mach-s3c24xx/Kconfig:28
error: arch/arm/mach-s3c24xx/Kconfig: patch does not apply
error: patch failed: arch/arm/mach-s3c24xx/Makefile:17
error: arch/arm/mach-s3c24xx/Makefile: patch does not apply
error: patch failed: drivers/cpufreq/Makefile:63
error: drivers/cpufreq/Makefile: patch does not apply
error: drivers/cpufreq/s3c2412-cpufreq.c: does not exist in index
Patch failed at 0001 cpufreq: s3c24xx: move cpufreq driver to
drivers/cpufreq

Thanks.

- Kukjin



From kgene.kim at samsung.com  Fri Apr  5 02:49:53 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Fri, 05 Apr 2013 15:49:53 +0900
Subject: linux-next: manual merge of the samsung tree with the arm-soc tree
In-Reply-To: <20130405160256.7ca6f52e25e0d2231eb1fcfe@canb.auug.org.au>
References: <20130405160256.7ca6f52e25e0d2231eb1fcfe@canb.auug.org.au>
Message-ID: <2a5a01ce31c9$c7051670$550f4350$%kim@samsung.com>

Stephen Rothwell wrote:
> 
> Hi Kukjin,
> 
Hi,

> Today's linux-next merge of the samsung tree got a conflict in
> drivers/irqchip/irq-s3c24xx.c between commit de88cbb7b244 ("arm: Move
> chained_irq_(enter|exit) to a generic file") from the arm-soc tree (where
> it is called arch/arm/mach-s3c24xx/irq.c) and commit f0774d41da0e
> ("irqchip: s3c24xx: add devicetree support") from the samsung tree.
> 
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
> 
Looks good to me, thanks.

- Kukjin



From weiyj.lk at gmail.com  Fri Apr  5 02:58:52 2013
From: weiyj.lk at gmail.com (Wei Yongjun)
Date: Fri, 5 Apr 2013 14:58:52 +0800
Subject: [PATCH -next] ARM: tegra: pm: remove duplicated include from pm.c
Message-ID: <CAPgLHd-FCVa-k1dBCgPrQOdDpmovvWwy+UjFmu8pj5ZCRad5EQ@mail.gmail.com>

From: Wei Yongjun <yongjun_wei at trendmicro.com.cn>

Remove duplicated include.

Signed-off-by: Wei Yongjun <yongjun_wei at trendmicro.com.cn>
---
 arch/arm/mach-tegra/pm.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/mach-tegra/pm.c b/arch/arm/mach-tegra/pm.c
index 6ce6beb..d647e9e 100644
--- a/arch/arm/mach-tegra/pm.c
+++ b/arch/arm/mach-tegra/pm.c
@@ -39,7 +39,6 @@
 #include "fuse.h"
 #include "pmc.h"
 #include "sleep.h"
-#include "pmc.h"
 
 #ifdef CONFIG_PM_SLEEP
 static DEFINE_SPINLOCK(tegra_lp2_lock);



From viresh.kumar at linaro.org  Fri Apr  5 03:06:34 2013
From: viresh.kumar at linaro.org (Viresh Kumar)
Date: Fri, 5 Apr 2013 12:36:34 +0530
Subject: [PATCH 07/18] cpufreq: s3c24xx: move cpufreq driver to
 drivers/cpufreq
In-Reply-To: <2a5901ce31c9$95160980$bf421c80$%kim@samsung.com>
References: <cover.1365079581.git.viresh.kumar@linaro.org>
 <927100d30bf40d4fec477cc7d8d464669a22d167.1365079581.git.viresh.kumar@linaro.org>
 <2a5901ce31c9$95160980$bf421c80$%kim@samsung.com>
Message-ID: <CAKohpokk1Q+0gRpeW=ts0a8D+rGAUpHu62X+7ejdpfom_B6FYA@mail.gmail.com>

On 5 April 2013 12:18, Kukjin Kim <kgene.kim at samsung.com> wrote:
> Basically, this moving looks good to me, but should be re-worked based on
> for-next of samsung tree because this touches too many samsung stuff so this
> should be sent to upstream via samsung tree.

Hmm... Its already applied in Rafael's tree. But it doesn't mean that
it can't be
moved to your tree if there is a issue.

What tree/branch? I used:

git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git for-next

> Applying: cpufreq: s3c24xx: move cpufreq driver to drivers/cpufreq
> error: patch failed: arch/arm/Kconfig:2166
> error: arch/arm/Kconfig: patch does not apply

above two are obvious as you haven't applied other patches in this series.

> error: patch failed: arch/arm/mach-s3c24xx/Kconfig:28
> error: arch/arm/mach-s3c24xx/Kconfig: patch does not apply
> error: patch failed: arch/arm/mach-s3c24xx/Makefile:17
> error: arch/arm/mach-s3c24xx/Makefile: patch does not apply
> error: patch failed: drivers/cpufreq/Makefile:63
> error: drivers/cpufreq/Makefile: patch does not apply

Same here.

> error: drivers/cpufreq/s3c2412-cpufreq.c: does not exist in index

I can still see it in for-next.

Attached is my patch based of your for-next
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-cpufreq-s3c24xx-move-cpufreq-driver-to-drivers-cpufr.patch
Type: application/octet-stream
Size: 18050 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130405/2fb30bb6/attachment-0001.obj>

From thierry.reding at avionic-design.de  Fri Apr  5 03:37:03 2013
From: thierry.reding at avionic-design.de (Thierry Reding)
Date: Fri, 5 Apr 2013 09:37:03 +0200
Subject: [PATCH v3 07/12] PCI: tegra: Move PCIe driver to drivers/pci/host
In-Reply-To: <515DF096.2000703@wwwdotorg.org>
References: <1365000318-28256-1-git-send-email-thierry.reding@avionic-design.de>
 <1365000318-28256-8-git-send-email-thierry.reding@avionic-design.de>
 <515DF096.2000703@wwwdotorg.org>
Message-ID: <20130405073703.GB15848@avionic-0098.mockup.avionic-design.de>

On Thu, Apr 04, 2013 at 03:28:54PM -0600, Stephen Warren wrote:
[...]
> > diff --git a/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt b/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt
> 
> > +Required properties:
> 
> > +- interrupts: the interrupt outputs of the controller
> > +- interrupt-names: list of names to identify interrupts
> 
> The specification part of this file should define which interrupt
> outputs must be included in this list, and the order they must appear in
> the list.

Okay, I can add such a description similar to what you propose below for
the clocks and clock-names properties. Something like this:

- interrupts: A list of interrupt outputs of the controller. Must contain an
  entry for each entry in the interrupt-names property.
- interrupt-names: Must include the following entries:
  "intr": The Tegra interrupt that is asserted for controller interrupts
  "msi": The Tegra interrupt that is asserted when an MSI is received

Would that be acceptable?

I should probably update the reg properties in a similar way. Maybe like
so:

- reg: A list of physical base address and length for each set of controller
  registers. Must contain an entry for each entry in the reg-names property.
- reg-names: Must include the following entries:
  "pads": PADS registers
  "afi": AFI registers
  "cs": configuration space region

> I believe that the entries in the interrupts property must
> have a defined order, so I'm not sure whether interrupt-names is useful
> here?

Actually the interrupt-names property is there specifically so that the
order doesn't matter. The driver uses platform_get_irq_byname(), using
"intr" and "msi" respectively so that they don't have to appear in a
specific order. I did this so that it is more in line with properties
such as clocks and reg.

> > +- ranges: describes the translation of addresses for root ports
> 
> Shouldn't there be some discussion re: how the range are expected to be
> set up so that everything works? We shouldn't expect people to just
> blindly copy the example without any way of understanding it.

Possibly. I wouldn't like to go too much into the details, though, since
the ranges property is not only rather complex but also well documented
in other places. But I could add some explanation about which entries
are expected and how they work together. In this case even order is
important. The port register entries need to be listed before the
non-prefetchable memory window entry, otherwise the ranges parser gets
confused. How does the following sound?

- ranges: Describes the translation of addresses for root ports and standard
  PCI regions. The entries must be 6 cells each, where the first three cells
  correspond to the address as described for the #address-cells property
  above, the fourth cell is the physical CPU address to translate to and the
  fifth and six cells are as described for the #size-cells property above.
  - The first two entries are expected to translate the addresses for the root
    port registers, which are referenced by the assigned-addresses property of
    the root port nodes (see below).
  - The remaining entries setup the mapping for the standard I/O, memory and
    prefetchable PCI regions. The first cell determines the type of region
    that is setup:
    - 0x81000000: I/O memory region
    - 0x82000000: non-prefetchable memory region
    - 0xc2000000: prefetchable memory region
  Please refer to the standard PCI bus binding document for a more detailed
  explanation.

> > +- clocks: the clock inputs of the controller
> > +- clock-names: list of names to identify clocks
> 
> The specification part of this file should define which clocks are
> required, and not rely on the example below to do this. I would suggest
> re-writing this as:
> 
> - clocks : Must contain an entry for each entry in clock-names.
> - clock-names : Must include the following entries:
>   "pex" (The Tegra clock of that name)
>   "afi" (The Tegra clock of that name)
>   "pcie_xclk" (The Tegra clock of that name)
>   "pll_e" (The Tegra clock of that name)

Okay, sounds good. Although the Tegra clocks are named somewhat
differently. "pex" is named "pcie" and "pcie_xclk" is "unassigned" (!)
according to the nvidia,tegra20-car.txt binding document. Perhaps I
should update the binding document to replace unassigned with pcie_xclk
for clock 74. And maybe rename pex in the PCIe binding to pcie to match
the CAR binding?

> > +Root ports are defined as subnodes of the PCIe controller node.
> > +
> > +Required properties:
> ...
> > +- ranges: sub-ranges distributed from the PCIe controller node
> 
> Here, I think it's worth mentioning that an empty ranges is all that's
> required.

Yes, that's a good idea.

> > +Board DTS:
> > +
> > +	pcie-controller {
> > +		status = "okay";
> > +
> > +		vdd-supply = <&pci_vdd_reg>;
> > +		pex-clk-supply = <&pci_clk_reg>;
> > +
> > +		/* root port 00:01.0 */
> > +		pci at 1,0 {
> > +			status = "okay";
> 
> Is it worth putting a comment here stating that the explicit devices
> included below in this example are entirely optional?

Would it be acceptable to annotate the 01:00.0 bridge with "optional"?
Like so:

	pcie-controller {
		...
		pci at 1,0 {
			...
			/* bridge 01:00.0 (optional) */
			pci at 0,0 {
				...
			};
		};
	};

Alternatively I could add something like below:

---snip---

Note that devices on the PCI bus are dynamically discovered using PCI's bus
enumeration and therefore don't need corresponding device nodes in DT. However
if a device on the PCI bus provides a non-probeable bus such as I2C or SPI,
device nodes need to be added in order to allow the bus' children to be
instantiated at the proper location in the operating system's device tree (as
illustrated by the optional nodes in the example above).

---snip---

Maybe I'll just do both.

> > diff --git a/arch/arm/mach-tegra/board-harmony-pcie.c b/arch/arm/mach-tegra/board-harmony-pcie.c
> > deleted file mode 100644
> 
> Hmmm. Is this patch meant to include a change to tegra20-harmony.dtsi to
> hook up all the regulators through device tree? Same for TrimSlice?

As discussed above I think it'd be preferrable, in order to keep
dependencies simpler, to separate the changes into different patches.
Aside from the oddity on Harmony I don't think there's anything that
prevents that.

> > diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
> > diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile
> > diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
> > diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
> 
> I think the creation of those files should be a separate patch, and
> hopefully get into 3.10 to remove any dependencies. Otherwise, 3 or 4
> different patches are all going to try and do the same thing. Didn't the
> Marvell series split out the creation of drivers/pci/host/ into a
> separate patch that's suitable for this, and could go into 3.10?

At the time when I wrote the patch to move the driver to drivers/pci,
there were no other drivers so I didn't think it necessary to split out
those changes. I had also been overly optimistic that the patches could
be merged at that point. Meanwhile there are a few more drivers that
will go into that directory, so yes they should go into a separate patch
like Thomas has done. If that makes it into 3.10, all the better.

> > diff --git a/drivers/pci/host/pci-tegra.c b/drivers/pci/host/pci-tegra.c
> 
> I'll review that file separately later.

Okay, thanks for reviewing.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130405/43bd0056/attachment.sig>

From horms at verge.net.au  Fri Apr  5 03:40:45 2013
From: horms at verge.net.au (Simon Horman)
Date: Fri, 5 Apr 2013 16:40:45 +0900
Subject: [PATCH] irqchip: irqc: Add runtime PM support
In-Reply-To: <87sj35k43m.wl%kuninori.morimoto.gx@renesas.com>
References: <1365056466-23710-1-git-send-email-horms+renesas@verge.net.au>
 <20130405022623.GD29203@verge.net.au>
 <87sj35k43m.wl%kuninori.morimoto.gx@renesas.com>
Message-ID: <20130405074044.GD23419@verge.net.au>

On Thu, Apr 04, 2013 at 09:12:49PM -0700, Kuninori Morimoto wrote:
> 
> Hi
> 
> > On Thu, Apr 04, 2013 at 03:21:06PM +0900, Simon Horman wrote:
> > > This was tested using the SMSC LAN on the APE6EVM board.
> > > 
> > > Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
> > 
> > Magnus, Morimoto-san, could you review this?
> 
> Acked-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>

Thanks, I have queued this up in the intc-external-irq branch.


From linus.walleij at linaro.org  Fri Apr  5 03:45:38 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Fri, 5 Apr 2013 09:45:38 +0200
Subject: [PATCH 4/6] pinctrl: sunxi: add clock support
In-Reply-To: <20130404170158.8665.65205@quantum>
References: <1363962042-29536-1-git-send-email-emilio@elopez.com.ar>
 <1363962042-29536-5-git-send-email-emilio@elopez.com.ar>
 <CACRpkdbn9c_bAWUN8hTLkeidCnyZ=0nRQRBV39DMkK_0jBfoUQ@mail.gmail.com>
 <51535077.1050203@free-electrons.com>
 <CACRpkda80EKT2LbsBCOng=gkdtdd+vbYwkMPiFZUBx7z_aqY+A@mail.gmail.com>
 <515C9D25.3050407@free-electrons.com>
 <CACRpkdacuu9JwY5waFwch=v2G6MkTZOO=DXismdsfr0Ttoi9=g@mail.gmail.com>
 <20130404170158.8665.65205@quantum>
Message-ID: <CACRpkdbBfOdcpdWKYiWczG1qkPGF-Y5Z1J=M_q9i=K4ZePc0vg@mail.gmail.com>

On Thu, Apr 4, 2013 at 7:01 PM, Mike Turquette <mturquette at linaro.org> wrote:
> Quoting Linus Walleij (2013-04-04 04:37:23)
>> On Wed, Apr 3, 2013 at 11:20 PM, Maxime Ripard
>> <maxime.ripard at free-electrons.com> wrote:
>> > Le 03/04/2013 13:59, Linus Walleij a ?crit :
>> >> On Wed, Mar 27, 2013 at 9:03 PM, Maxime Ripard
>> >> <maxime.ripard at free-electrons.com> wrote:
>> >>
>> >>> Hi Linus,
>> >>> Le 27/03/2013 14:14, Linus Walleij a ?crit :
>> >>>> On Fri, Mar 22, 2013 at 3:20 PM, Emilio L?pez <emilio at elopez.com.ar> wrote:
>> >>>>
>> >>>>> For the port controller to work, we need to enable the apb0_pio gate.
>> >>>>> This commit adds the ability to enable one clock specified on the device
>> >>>>> tree to the pinctrl driver.
>> >>>>>
>> >>>>> Signed-off-by: Emilio L?pez <emilio at elopez.com.ar>
>> >>>>
>> >>>> Acked-by: Linus Walleij <linus.walleij at linaro.org>
>> >>>>
>> >>>> I guess you'll want to merge these as one series to some platform-specific
>> >>>> tree, tell me if you want it merged in the pinctrl tree.
>> >>>
>> >>> The easiest would probably be to merge this patch through your patch,
>> >>> with Mike taking the clock driver patches and me taking the dt ones,
>> >>> once we agree on the other patches.
>> >>
>> >> OK then, patch applied to the pinctrl tree, thanks!
>> >
>> > Ouch, the previous patches aren't applied yet by Mike, and we didn't
>> > have some comments from him about these patches, so I can't really say
>> > if the previous patches will get merge by 3.10 or not... So we will
>> > maybe end up with a broken pinctrl stuff.
>>
>> This is usually why we keep patches together and merge whole series
>> into one tree, such as ARM SoC.
>>
>> Well, maybe I'll drop it then ...
>>
>
> I plan on taking in the three clk patches after getting final comments
> from Gregory.  So maybe you do not need to drop the pinctrl patches?

No, I'm keeping it around, no problem.

Thanks Mike,
Linus Walleij


From javier.martinez at collabora.co.uk  Fri Apr  5 03:48:08 2013
From: javier.martinez at collabora.co.uk (Javier Martinez Canillas)
Date: Fri,  5 Apr 2013 09:48:08 +0200
Subject: [PATCH 1/1] of/irq: store IRQ trigger/level in struct resource flags
Message-ID: <1365148088-11175-1-git-send-email-javier.martinez@collabora.co.uk>

According to Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
the "#interrupt-cells" property of an "interrupt-controller" is used
to define the number of cells needed to specify a single interrupt.

A commonly used variant is two cell on which #interrupt-cells = <2>
and the first cell defines the index of the interrupt in the controller
and the second cell is used to specify any of the following flags:

    - bits[3:0] trigger type and level flags
        1 = low-to-high edge triggered
        2 = high-to-low edge triggered
        4 = active high level-sensitive
        8 = active low level-sensitive

An example of an interrupt controller which use the two cell format is
the OMAP GPIO controller that allows GPIO lines to be used as IRQ
(Documentation/devicetree/bindings/gpio/gpio-omap.txt)

But setting #interrupt-cells = <2> on the OMAP GPIO device node and
specifying the GPIO-IRQ type and level flags on the second cell does not
store this value on the populated IORESOURCE_IRQ struct resource.

This is because when using an IRQ from an interrupt controller and
setting both cells (e.g:)

	interrupt-parent = <&gpio6>;
	interrupts = <16 8>;

A call to of_irq_to_resource() is made and this function calls to
irq_of_parse_and_map_type() to get the virtual IRQ mapped to the real
index for this interrupt controller. This IRQ number is populated on
the struct resource:

int of_irq_to_resource(struct device_node *dev, int index, struct resource *r)
{
	int irq = irq_of_parse_and_map(dev, index);
	..
	r->start = r->end = irq;
}

irq_of_parse_and_map() calls to irq_create_of_mapping() which calls to
the correct xlate function handler according to "#interrupt-cells"
(irq_domain_xlate_onecell or irq_domain_xlate_twocell) and to
irq_set_irq_type() to set the IRQ type.

But the type is never returned so it can't be saved on the IRQ struct
resource flags member.

This means that drivers that need the IRQ type/level flags defined in
the DT won't be able to get it.

Signed-off-by: Javier Martinez Canillas <javier.martinez at collabora.co.uk>
---
 drivers/of/irq.c       |   30 ++++++++++++++++++++++++------
 include/linux/of_irq.h |    4 ++++
 kernel/irq/irqdomain.c |   14 ++++++++++++--
 3 files changed, 40 insertions(+), 8 deletions(-)

diff --git a/drivers/of/irq.c b/drivers/of/irq.c
index a3c1c5a..6f6aa75 100644
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -27,22 +27,39 @@
 #include <linux/slab.h>
 
 /**
- * irq_of_parse_and_map - Parse and map an interrupt into linux virq space
+ * irq_of_parse_and_map_type - Parse and map an interrupt into linux virq space
  * @device: Device node of the device whose interrupt is to be mapped
  * @index: Index of the interrupt to map
+ * @type: Interrupt trigger type and level flags filled by this function
  *
  * This function is a wrapper that chains of_irq_map_one() and
  * irq_create_of_mapping() to make things easier to callers
  */
-unsigned int irq_of_parse_and_map(struct device_node *dev, int index)
+static unsigned int irq_of_parse_and_map_type(struct device_node *dev,
+					      int index, unsigned int *type)
 {
 	struct of_irq oirq;
+	unsigned int virq;
 
 	if (of_irq_map_one(dev, index, &oirq))
 		return 0;
 
-	return irq_create_of_mapping(oirq.controller, oirq.specifier,
-				     oirq.size);
+	virq = irq_create_of_mapping_type(oirq.controller, oirq.specifier,
+					  oirq.size, type);
+	return virq;
+}
+
+/**
+ * irq_of_parse_and_map - Parse and map an interrupt into linux virq space
+ * @device: Device node of the device whose interrupt is to be mapped
+ * @index: Index of the interrupt to map
+ *
+ * This function is a wrapper of irq_of_parse_and_map_type() when the IRQ
+ * type and level flags are not needed
+ */
+unsigned int irq_of_parse_and_map(struct device_node *dev, int index)
+{
+	return irq_of_parse_and_map_type(dev, index, NULL);
 }
 EXPORT_SYMBOL_GPL(irq_of_parse_and_map);
 
@@ -338,7 +355,8 @@ EXPORT_SYMBOL_GPL(of_irq_map_one);
  */
 int of_irq_to_resource(struct device_node *dev, int index, struct resource *r)
 {
-	int irq = irq_of_parse_and_map(dev, index);
+	int type = IRQ_TYPE_NONE;
+	int irq = irq_of_parse_and_map_type(dev, index, &type);
 
 	/* Only dereference the resource if both the
 	 * resource and the irq are valid. */
@@ -353,7 +371,7 @@ int of_irq_to_resource(struct device_node *dev, int index, struct resource *r)
 					      &name);
 
 		r->start = r->end = irq;
-		r->flags = IORESOURCE_IRQ;
+		r->flags = (IORESOURCE_IRQ | type);
 		r->name = name ? name : dev->full_name;
 	}
 
diff --git a/include/linux/of_irq.h b/include/linux/of_irq.h
index 535cecf..98aec57 100644
--- a/include/linux/of_irq.h
+++ b/include/linux/of_irq.h
@@ -66,6 +66,10 @@ extern int of_irq_map_one(struct device_node *device, int index,
 extern unsigned int irq_create_of_mapping(struct device_node *controller,
 					  const u32 *intspec,
 					  unsigned int intsize);
+extern unsigned int irq_create_of_mapping_type(struct device_node *controller,
+					       const u32 *intspec,
+					       unsigned int intsize,
+					       unsigned int *otype);
 extern int of_irq_to_resource(struct device_node *dev, int index,
 			      struct resource *r);
 extern int of_irq_count(struct device_node *dev);
diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index 96f3a1d..4a2f222 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -636,8 +636,9 @@ int irq_create_strict_mappings(struct irq_domain *domain, unsigned int irq_base,
 }
 EXPORT_SYMBOL_GPL(irq_create_strict_mappings);
 
-unsigned int irq_create_of_mapping(struct device_node *controller,
-				   const u32 *intspec, unsigned int intsize)
+unsigned int irq_create_of_mapping_type(struct device_node *controller,
+					const u32 *intspec, unsigned int intsize,
+					unsigned int *otype)
 {
 	struct irq_domain *domain;
 	irq_hw_number_t hwirq;
@@ -681,8 +682,17 @@ unsigned int irq_create_of_mapping(struct device_node *controller,
 	if (type != IRQ_TYPE_NONE &&
 	    type != (irqd_get_trigger_type(irq_get_irq_data(virq))))
 		irq_set_irq_type(virq, type);
+	if (otype)
+		*otype = type;
 	return virq;
 }
+EXPORT_SYMBOL_GPL(irq_create_of_mapping_type);
+
+unsigned int irq_create_of_mapping(struct device_node *controller,
+				   const u32 *intspec, unsigned int intsize)
+{
+	return irq_create_of_mapping_type(controller, intspec, intsize, NULL);
+}
 EXPORT_SYMBOL_GPL(irq_create_of_mapping);
 
 /**
-- 
1.7.7.6



From thierry.reding at avionic-design.de  Fri Apr  5 03:53:49 2013
From: thierry.reding at avionic-design.de (Thierry Reding)
Date: Fri, 5 Apr 2013 09:53:49 +0200
Subject: [PATCH v3 07/12] PCI: tegra: Move PCIe driver to drivers/pci/host
In-Reply-To: <20130405073703.GB15848@avionic-0098.mockup.avionic-design.de>
References: <1365000318-28256-1-git-send-email-thierry.reding@avionic-design.de>
 <1365000318-28256-8-git-send-email-thierry.reding@avionic-design.de>
 <515DF096.2000703@wwwdotorg.org>
 <20130405073703.GB15848@avionic-0098.mockup.avionic-design.de>
Message-ID: <20130405075348.GC15848@avionic-0098.mockup.avionic-design.de>

For reference, here's the new binding document with all your comments
addressed (I think).

Thierry
-------------- next part --------------
NVIDIA Tegra PCIe controller

Required properties:
- compatible: "nvidia,tegra20-pcie"
- device_type: Must be "pci"
- reg: A list of physical base address and length for each set of controller
  registers. Must contain an entry for each entry in the reg-names property.
- reg-names: Must include the following entries:
  "pads": PADS registers
  "afi": AFI registers
  "cs": configuration space region
- interrupts: A list of interrupt outputs of the controller. Must contain an
  entry for each entry in the interrupt-names property.
- interrupt-names: Must include the following entries:
  "intr": The Tegra interrupt that is asserted for controller interrupts
  "msi": The Tegra interrupt that is asserted when an MSI is received
- pex-clk-supply: Supply voltage for internal reference clock
- vdd-supply: Power supply for controller (1.05V)
- bus-range: Range of bus numbers associated with this controller
- #address-cells: Address representation for root ports (must be 3)
  - cell 0 specifies the bus and device numbers of the root port:
    [23:16]: bus number
    [15:11]: device number
  - cell 1 denotes the upper 32 address bits and should be 0
  - cell 2 contains the lower 32 address bits and is used to translate to the
    CPU address space
- #size-cells: Size representation for root ports (must be 2)
- ranges: Describes the translation of addresses for root ports and standard
  PCI regions. The entries must be 6 cells each, where the first three cells
  correspond to the address as described for the #address-cells property
  above, the fourth cell is the physical CPU address to translate to and the
  fifth and six cells are as described for the #size-cells property above.
  - The first two entries are expected to translate the addresses for the root
    port registers, which are referenced by the assigned-addresses property of
    the root port nodes (see below).
  - The remaining entries setup the mapping for the standard I/O, memory and
    prefetchable PCI regions. The first cell determines the type of region
    that is setup:
    - 0x81000000: I/O memory region
    - 0x82000000: non-prefetchable memory region
    - 0xc2000000: prefetchable memory region
  Please refer to the standard PCI bus binding document for a more detailed
  explanation.
- clocks: List of clock inputs of the controller. Must contain an entry for
  each entry in the clock-names property.
- clock-names: Must include the following entries:
  "pex": The Tegra clock of that name
  "afi": The Tegra clock of that name
  "pcie_xclk": The Tegra clock of that name
  "pll_e": The Tegra clock of that name

Root ports are defined as subnodes of the PCIe controller node.

Required properties:
- device_type: Must be "pci"
- assigned-addresses: Address and size of the port configuration registers
- reg: PCI bus address of the root port
- #address-cells: Must be 3
- #size-cells: Must be 2
- ranges: Sub-ranges distributed from the PCIe controller node. An empty
  property is sufficient.
- nvidia,num-lanes: Number of lanes to use for this port. Valid combinations
  are:
  - Root port 0 uses 4 lanes, root port 1 is unused.
  - Both root ports use 2 lanes.

Example:

SoC DTSI:

	pcie-controller {
		compatible = "nvidia,tegra20-pcie";
		device_type = "pci";
		reg = <0x80003000 0x00000800   /* PADS registers */
		       0x80003800 0x00000200   /* AFI registers */
		       0x90000000 0x10000000>; /* configuration space */
		reg-names = "pads", "afi", "cs";
		interrupts = <0 98 0x04   /* controller interrupt */
		              0 99 0x04>; /* MSI interrupt */
		interrupt-names = "intr", "msi";

		bus-range = <0x00 0xff>;
		#address-cells = <3>;
		#size-cells = <2>;

		ranges = <0x82000000 0 0x80000000 0x80000000 0 0x00001000   /* port 0 registers */
			  0x82000000 0 0x80001000 0x80001000 0 0x00001000   /* port 1 registers */
			  0x81000000 0 0          0x82000000 0 0x00010000   /* downstream I/O */
			  0x82000000 0 0xa0000000 0xa0000000 0 0x10000000   /* non-prefetchable memory */
			  0xc2000000 0 0xb0000000 0xb0000000 0 0x10000000>; /* prefetchable memory */

		clocks = <&tegra_car 70>, <&tegra_car 72>, <&tegra_car 74>,
			 <&tegra_car 118>;
		clock-names = "pex", "afi", "pcie_xclk", "pll_e";
		status = "disabled";

		pci at 1,0 {
			device_type = "pci";
			assigned-addresses = <0x82000800 0 0x80000000 0 0x1000>;
			reg = <0x000800 0 0 0 0>;
			status = "disabled";

			#address-cells = <3>;
			#size-cells = <2>;

			ranges;

			nvidia,num-lanes = <2>;
		};

		pci at 2,0 {
			device_type = "pci";
			assigned-addresses = <0x82001000 0 0x80001000 0 0x1000>;
			reg = <0x001000 0 0 0 0>;
			status = "disabled";

			#address-cells = <3>;
			#size-cells = <2>;

			ranges;

			nvidia,num-lanes = <2>;
		};
	};


Board DTS:

	pcie-controller {
		status = "okay";

		vdd-supply = <&pci_vdd_reg>;
		pex-clk-supply = <&pci_clk_reg>;

		/* root port 00:01.0 */
		pci at 1,0 {
			status = "okay";

			/* bridge 01:00.0 (optional) */
			pci at 0,0 {
				reg = <0x010000 0 0 0 0>;

				#address-cells = <3>;
				#size-cells = <2>;

				device_type = "pci";

				/* endpoint 02:00.0 */
				pci at 0,0 {
					reg = <0x020000 0 0 0 0>;
				};
			};
		};
	};

Note that devices on the PCI bus are dynamically discovered using PCI's bus
enumeration and therefore don't need corresponding device nodes in DT. However
if a device on the PCI bus provides a non-probeable bus such as I2C or SPI,
device nodes need to be added in order to allow the bus' children to be
instantiated at the proper location in the operating system's device tree (as
illustrated by the optional nodes in the example above).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130405/680dd637/attachment.sig>

From b-cousson at ti.com  Fri Apr  5 04:05:33 2013
From: b-cousson at ti.com (Benoit Cousson)
Date: Fri, 5 Apr 2013 10:05:33 +0200
Subject: [PATCH 0/5] ARM: OMAP: DMTIMER updates for v3.10
In-Reply-To: <20130404183855.GP10155@atomide.com>
References: <1363714699-29622-1-git-send-email-jon-hunter@ti.com>
 <20130404183855.GP10155@atomide.com>
Message-ID: <515E85CD.1060307@ti.com>

On 04/04/2013 08:38 PM, Tony Lindgren wrote:
> * Jon Hunter <jon-hunter at ti.com> [130319 10:42]:
>> Includes:
>> - A couple fixes for DMTIMER context loss handling.
>> - Populating DMTIMER errata when booting with device-tree.
>> - A new function for requesting a DMTIMER by device-tree node.
>>
>> Based upon v3.9-rc3.
>>
>> Tested on OMAP5912 OSK, OMAP2420 H4, OMAP3430 SDP, OMAP4430 Blaze
>> and AM335x EVM. Testing includes ...
>> 1. Booting kernel on above boards
>> 2. Testing of various DMTIMER request APIs
>> 3. Testing the timer overflow and match interrupts.
>> 4. Using different clock sources to operate the timer with.
>>
>> Jon Hunter (4):
>>   ARM: OMAP: Force dmtimer restore if context loss is not detectable
>>   ARM: OMAP: Add function to request timer by node
>>   ARM: dts: OMAP2+: Update DMTIMER compatibility property
>>   ARM: OMAP2+: Populate DMTIMER errata when using device-tree
>>
>> NeilBrown (1):
>>   ARM: OMAP: Simplify dmtimer context-loss handling
>>
>>  .../devicetree/bindings/arm/omap/timer.txt         |   17 +-
>>  arch/arm/boot/dts/am33xx.dtsi                      |   14 +-
>>  arch/arm/boot/dts/omap2.dtsi                       |   22 +-
>>  arch/arm/boot/dts/omap2420.dtsi                    |    2 +-
>>  arch/arm/boot/dts/omap2430.dtsi                    |    2 +-
>>  arch/arm/boot/dts/omap3.dtsi                       |   24 +-
>>  arch/arm/boot/dts/omap4.dtsi                       |   22 +-
>>  arch/arm/boot/dts/omap5.dtsi                       |   22 +-
>>  arch/arm/mach-omap2/timer.c                        |    7 +-
>>  arch/arm/plat-omap/dmtimer.c                       |  241 ++++++++++++--------
>>  arch/arm/plat-omap/include/plat/dmtimer.h          |    1 +
>>  11 files changed, 220 insertions(+), 154 deletions(-)
> 
> For all these it sounds like it's best that Benoit queues
> them with the .dts changes:
> 
> Acked-by: Tony Lindgren <tony at atomide.com>
> 

Great.

Jon,

I've just applied the whole series and will push it soon.

Thanks,
Benoit



From b-cousson at ti.com  Fri Apr  5 04:08:23 2013
From: b-cousson at ti.com (Benoit Cousson)
Date: Fri, 5 Apr 2013 10:08:23 +0200
Subject: [PATCH] ARM: dts: OMAP4+: Correct L3 interrupts
In-Reply-To: <515E6EAE.9000107@ti.com>
References: <1365098790-9078-1-git-send-email-jon-hunter@ti.com>
 <515E6EAE.9000107@ti.com>
Message-ID: <515E8677.40404@ti.com>

On 04/05/2013 08:26 AM, Santosh Shilimkar wrote:
> On Thursday 04 April 2013 11:36 PM, Jon Hunter wrote:
>> The L3 interrupt numbers are incorrect for OMAP4+ and are conflicting
>> with some of the timer interrupts causing the allocation of timer
>> interrupts to fail.
>>
>> The problem is caused by adding 32 to the interrupt number for the L3
>> interrupts to account for per processor interrupts (PPI) and software
>> generated interrupts (SGI) which typically are mapped to the first 32
>> interrupts in the ARM GIC. This is not necessary because the first
>> parameter of the ARM GIC interrupt property specifies the GIC interrupt
>> type (ie. SGI, PPI, etc). Hence, fix the interrupt number fo the L3
>> interrupts by substracting 32.
>>
>> Cc: Santosh Shilimkar <santosh.shilimkar at ti.com>
>> Signed-off-by: Jon Hunter <jon-hunter at ti.com>
>> ---
>>
>> Please note that this problem is observed in Benoit's for_3.10/dts branch [1].
>>
>> [1] http://git.kernel.org/cgit/linux/kernel/git/bcousson/linux-omap-dt.git
>>
> Thats correct. I overlooked the 32 addition part. This patch should
> also be pulled into Benoit's 3.10 tree.

Done. I've just applied it. But I will probably merge it with the
original patch, because having a broken patch and the fix in the same
pull request does not look right.

> For the patch,
> Acked-by: Santosh Shilimkar <santosh.shilimkar at ti.com>

Thanks,
Benoit




From b-cousson at ti.com  Fri Apr  5 04:22:18 2013
From: b-cousson at ti.com (Benoit Cousson)
Date: Fri, 5 Apr 2013 10:22:18 +0200
Subject: [PATCH] ARM: dts: OMAP4+: Correct L3 interrupts
In-Reply-To: <515E8677.40404@ti.com>
References: <1365098790-9078-1-git-send-email-jon-hunter@ti.com>
 <515E6EAE.9000107@ti.com> <515E8677.40404@ti.com>
Message-ID: <515E89BA.9010709@ti.com>

Santosh and Jon,

On 04/05/2013 10:08 AM, Benoit Cousson wrote:
> On 04/05/2013 08:26 AM, Santosh Shilimkar wrote:
>> On Thursday 04 April 2013 11:36 PM, Jon Hunter wrote:
>>> The L3 interrupt numbers are incorrect for OMAP4+ and are conflicting
>>> with some of the timer interrupts causing the allocation of timer
>>> interrupts to fail.
>>>
>>> The problem is caused by adding 32 to the interrupt number for the L3
>>> interrupts to account for per processor interrupts (PPI) and software
>>> generated interrupts (SGI) which typically are mapped to the first 32
>>> interrupts in the ARM GIC. This is not necessary because the first
>>> parameter of the ARM GIC interrupt property specifies the GIC interrupt
>>> type (ie. SGI, PPI, etc). Hence, fix the interrupt number fo the L3
>>> interrupts by substracting 32.
>>>
>>> Cc: Santosh Shilimkar <santosh.shilimkar at ti.com>
>>> Signed-off-by: Jon Hunter <jon-hunter at ti.com>
>>> ---
>>>
>>> Please note that this problem is observed in Benoit's for_3.10/dts branch [1].
>>>
>>> [1] http://git.kernel.org/cgit/linux/kernel/git/bcousson/linux-omap-dt.git
>>>
>> Thats correct. I overlooked the 32 addition part. This patch should
>> also be pulled into Benoit's 3.10 tree.
> 
> Done. I've just applied it. But I will probably merge it with the
> original patch, because having a broken patch and the fix in the same
> pull request does not look right.

Please find below the fixed version.

Regards,
Benoit


>From 90c2d172ef86d6c3283df43358d4425f9016be48 Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar <santosh.shilimkar at ti.com>
Date: Tue, 26 Feb 2013 17:36:14 +0530
Subject: [PATCH] ARM: dts: OMAP4/5: Update l3-noc DT nodes

Add l3-noc node for OMAP4 and OMAP5 devices.

Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>

[jon-hunter at ti.com: Fix the problem caused by adding 32 to the interrupt
number for the L3 interrupts to account for per processor interrupts (PPI)
and software generated interrupts (SGI) which typically are mapped to the
first 32 interrupts in the ARM GIC. This is not necessary because the first
parameter of the ARM GIC interrupt property specifies the GIC interrupt
type (ie. SGI, PPI, etc). Hence, fix the interrupt number for the L3
interrupts by substracting 32]
Signed-off-by: Jon Hunter <jon-hunter at ti.com>
Signed-off-by: Benoit Cousson <benoit.cousson at linaro.org>
---
 arch/arm/boot/dts/omap4.dtsi |    5 +++++
 arch/arm/boot/dts/omap5.dtsi |    5 +++++
 2 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index ddfc54a..3ae6a3f 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -94,6 +94,11 @@
 		#size-cells = <1>;
 		ranges;
 		ti,hwmods = "l3_main_1", "l3_main_2", "l3_main_3";
+		reg = <0x44000000 0x1000>,
+		      <0x44800000 0x2000>,
+		      <0x45000000 0x1000>;
+		interrupts = <0 9 0x4>,
+			     <0 10 0x4>;
 
 		counter32k: counter at 4a304000 {
 			compatible = "ti,omap-counter32k";
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index e539258..94b5ec9 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -87,6 +87,11 @@
 		#size-cells = <1>;
 		ranges;
 		ti,hwmods = "l3_main_1", "l3_main_2", "l3_main_3";
+		reg = <0x44000000 0x2000>,
+		      <0x44800000 0x3000>,
+		      <0x45000000 0x4000>;
+		interrupts = <0 9 0x4>,
+			     <0 10 0x4>;
 
 		counter32k: counter at 4ae04000 {
 			compatible = "ti,omap-counter32k";
-- 
1.7.0.4




From santosh.shilimkar at ti.com  Fri Apr  5 04:25:33 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Fri, 5 Apr 2013 13:55:33 +0530
Subject: [PATCH] ARM: dts: OMAP4+: Correct L3 interrupts
In-Reply-To: <515E89BA.9010709@ti.com>
References: <1365098790-9078-1-git-send-email-jon-hunter@ti.com>
 <515E6EAE.9000107@ti.com> <515E8677.40404@ti.com> <515E89BA.9010709@ti.com>
Message-ID: <515E8A7D.8000401@ti.com>

On Friday 05 April 2013 01:52 PM, Benoit Cousson wrote:
> Santosh and Jon,
> 
> On 04/05/2013 10:08 AM, Benoit Cousson wrote:
>> On 04/05/2013 08:26 AM, Santosh Shilimkar wrote:
>>> On Thursday 04 April 2013 11:36 PM, Jon Hunter wrote:
>>>> The L3 interrupt numbers are incorrect for OMAP4+ and are conflicting
>>>> with some of the timer interrupts causing the allocation of timer
>>>> interrupts to fail.
>>>>
>>>> The problem is caused by adding 32 to the interrupt number for the L3
>>>> interrupts to account for per processor interrupts (PPI) and software
>>>> generated interrupts (SGI) which typically are mapped to the first 32
>>>> interrupts in the ARM GIC. This is not necessary because the first
>>>> parameter of the ARM GIC interrupt property specifies the GIC interrupt
>>>> type (ie. SGI, PPI, etc). Hence, fix the interrupt number fo the L3
>>>> interrupts by substracting 32.
>>>>
>>>> Cc: Santosh Shilimkar <santosh.shilimkar at ti.com>
>>>> Signed-off-by: Jon Hunter <jon-hunter at ti.com>
>>>> ---
>>>>
>>>> Please note that this problem is observed in Benoit's for_3.10/dts branch [1].
>>>>
>>>> [1] http://git.kernel.org/cgit/linux/kernel/git/bcousson/linux-omap-dt.git
>>>>
>>> Thats correct. I overlooked the 32 addition part. This patch should
>>> also be pulled into Benoit's 3.10 tree.
>>
>> Done. I've just applied it. But I will probably merge it with the
>> original patch, because having a broken patch and the fix in the same
>> pull request does not look right.
> 
> Please find below the fixed version.
> 
Thanks Benoit. Patch looks fine to me.

Regards,
Santosh



From b-cousson at ti.com  Fri Apr  5 04:30:17 2013
From: b-cousson at ti.com (Benoit Cousson)
Date: Fri, 5 Apr 2013 10:30:17 +0200
Subject: [PATCH v4 00/21] ARM: OMAP2+: Adapt to ehci-omap changes for 3.10
In-Reply-To: <1363794300-31526-1-git-send-email-rogerq@ti.com>
References: <1363794300-31526-1-git-send-email-rogerq@ti.com>
Message-ID: <515E8B99.8080803@ti.com>

Hi Roger,

On 03/20/2013 04:44 PM, Roger Quadros wrote:
> Hi Tony,
> 
> These patches provide the SoC side code required to support
> the changes in the OMAP USB Host drivers done in [1], [2] & [3].
> 
> Device tree support is added for Beagleboard only. I've removed
> Panda device tree support till we have resolved the AUXCLK issue.
> 
> NOTE: The first patch needs to be shared between the
> OMAP tree and Felipe's USB tree.
> 
> v4:
> - Some more cleanup to usbhs_init_phys(). Moved repeated code into
> another helper function usbhs_add_regulator().
> - Removed patch for Panda device tree support for USB host since
> it is non functional.
> 
> v3:
> - Moved more functionality into usbhs_init_phys().
> 
> v2:
> - Added helper function usbhs_init_phys() that can be used by board files
> to simplify adding of PHY regulators for USB host ports.
> 
> [1] MFD side changes to omap-usb-host and omap-usb-tll
>   https://lkml.org/lkml/2013/3/12/179
> [2] USB EHCI side changes to ehci-omap 
>   http://www.mail-archive.com/linux-omap at vger.kernel.org/msg86265.html
> [3] USB PHY driver changes
>   http://www.mail-archive.com/linux-omap at vger.kernel.org/msg86293.html
> 
> The following changes since commit f6161aa153581da4a3867a2d1a7caf4be19b6ec9:
> 
>   Linux 3.9-rc2 (2013-03-10 16:54:19 -0700)
> 
> are available in the git repository at:
>   git://github.com/rogerq/linux.git usbhost-arm-next
> 
> Roger Quadros (21):
>   usb: phy: nop: Add some parameters to platform data
>   ARM: OMAP2+: omap-usb-host: Add usbhs_init_phys()
>   ARM: OMAP2+: omap4panda: Adapt to ehci-omap changes
>   ARM: OMAP3: Beagle: Adapt to ehci-omap changes
>   ARM: OMAP3: 3430SDP: Adapt to ehci-omap changes
>   ARM: OMAP3: 3630SDP: Adapt to ehci-omap changes
>   ARM: OMAP: AM3517crane: Adapt to ehci-omap changes
>   ARM: OMAP: AM3517evm: Adapt to ehci-omap changes
>   ARM: OMAP3: cm-t35: Adapt to ehci-omap changes
>   ARM: OMAP3: cm-t3517: Adapt to ehci-omap changes
>   ARM: OMAP: devkit8000: Adapt to ehci-omap changes
>   ARM: OMAP3: igep0020: Adapt to ehci-omap changes
>   ARM: OMAP3: omap3evm: Adapt to ehci-omap changes
>   ARM: OMAP3: omap3pandora: Adapt to ehci-omap changes
>   ARM: OMAP3: omap3stalker: Adapt to ehci-omap changes
>   ARM: OMAP3: omap3touchbook: Adapt to ehci-omap changes
>   ARM: OMAP3: overo: Adapt to ehci-omap changes
>   ARM: OMAP: zoom: Adapt to ehci-omap changes
>   ARM: dts: OMAP4: Add HS USB Host IP nodes
>   ARM: dts: OMAP3: Add HS USB Host IP nodes
>   ARM: dts: omap3-beagle: Add USB Host support

These 3 DTS patches are good to me, but I cannot applied them on top of
the already existing patches I queued for 3.10.

git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git
for_3.10/dts

Could you rebase these 3 ones only, and I will applied them.

Thanks,
Benoit


From rogerq at ti.com  Fri Apr  5 04:47:01 2013
From: rogerq at ti.com (Roger Quadros)
Date: Fri, 5 Apr 2013 11:47:01 +0300
Subject: [PATCH v2] ARM: OMAP4: clock: Add device tree support for AUXCLKs
In-Reply-To: <515A958B.5080905@ti.com>
References: <1363703220-4777-2-git-send-email-rogerq@ti.com>
 <1364293408-20677-1-git-send-email-rogerq@ti.com> <515A958B.5080905@ti.com>
Message-ID: <515E8F85.2060700@ti.com>

On 04/02/2013 11:23 AM, Roger Quadros wrote:
> + Paul
> 
> On 03/26/2013 12:23 PM, Roger Quadros wrote:
>> Register a device tree clock provider for the clocks
>> on the OMAP4 SoC. Also provide the binding information.
>>
>> For now we only provide AUXCLKs.

NOTE: this patch depends on
https://patchwork.kernel.org/patch/2312211/

>>
>> Signed-off-by: Roger Quadros <rogerq at ti.com>
>> ---
>>  .../devicetree/bindings/clock/omap4-clock.txt      |   33 ++++++++++++++++
>>  arch/arm/boot/dts/omap4.dtsi                       |    5 ++
>>  arch/arm/mach-omap2/cclock44xx_data.c              |   41 ++++++++++++++++++++
>>  3 files changed, 79 insertions(+), 0 deletions(-)
>>  create mode 100644 Documentation/devicetree/bindings/clock/omap4-clock.txt
>>

cheers,
-roger


From nm at ti.com  Fri Apr  5 04:48:36 2013
From: nm at ti.com (Nishanth Menon)
Date: Fri, 5 Apr 2013 03:48:36 -0500
Subject: [PATCH v2] ARM: OMAP4: clock: Add device tree support for AUXCLKs
In-Reply-To: <515E8F85.2060700@ti.com>
References: <1363703220-4777-2-git-send-email-rogerq@ti.com>
 <1364293408-20677-1-git-send-email-rogerq@ti.com>
 <515A958B.5080905@ti.com> <515E8F85.2060700@ti.com>
Message-ID: <20130405084836.GA11331@kahuna>

On 11:47-20130405, Roger Quadros wrote:
> On 04/02/2013 11:23 AM, Roger Quadros wrote:
> > + Paul
> > 
> > On 03/26/2013 12:23 PM, Roger Quadros wrote:
> >> Register a device tree clock provider for the clocks
> >> on the OMAP4 SoC. Also provide the binding information.
> >>
> >> For now we only provide AUXCLKs.
> 
> NOTE: this patch depends on
> https://patchwork.kernel.org/patch/2312211/
> 
> >>
> >> Signed-off-by: Roger Quadros <rogerq at ti.com>
> >> ---
> >>  .../devicetree/bindings/clock/omap4-clock.txt      |   33 ++++++++++++++++
> >>  arch/arm/boot/dts/omap4.dtsi                       |    5 ++
> >>  arch/arm/mach-omap2/cclock44xx_data.c              |   41 ++++++++++++++++++++
> >>  3 files changed, 79 insertions(+), 0 deletions(-)
> >>  create mode 100644 Documentation/devicetree/bindings/clock/omap4-clock.txt
If we are doing this, we might as well do for all platforms(OMAP3-5,
AM..) in an series, no?

-- 
Regards,
Nishanth Menon


From rogerq at ti.com  Fri Apr  5 04:50:59 2013
From: rogerq at ti.com (Roger Quadros)
Date: Fri, 5 Apr 2013 11:50:59 +0300
Subject: [PATCH v2] ARM: OMAP4: clock: Add device tree support for AUXCLKs
In-Reply-To: <20130405084836.GA11331@kahuna>
References: <1363703220-4777-2-git-send-email-rogerq@ti.com>
 <1364293408-20677-1-git-send-email-rogerq@ti.com> <515A958B.5080905@ti.com>
 <515E8F85.2060700@ti.com> <20130405084836.GA11331@kahuna>
Message-ID: <515E9073.8050504@ti.com>

On 04/05/2013 11:48 AM, Nishanth Menon wrote:
> On 11:47-20130405, Roger Quadros wrote:
>> On 04/02/2013 11:23 AM, Roger Quadros wrote:
>>> + Paul
>>>
>>> On 03/26/2013 12:23 PM, Roger Quadros wrote:
>>>> Register a device tree clock provider for the clocks
>>>> on the OMAP4 SoC. Also provide the binding information.
>>>>
>>>> For now we only provide AUXCLKs.
>>
>> NOTE: this patch depends on
>> https://patchwork.kernel.org/patch/2312211/
>>
>>>>
>>>> Signed-off-by: Roger Quadros <rogerq at ti.com>
>>>> ---
>>>>  .../devicetree/bindings/clock/omap4-clock.txt      |   33 ++++++++++++++++
>>>>  arch/arm/boot/dts/omap4.dtsi                       |    5 ++
>>>>  arch/arm/mach-omap2/cclock44xx_data.c              |   41 ++++++++++++++++++++
>>>>  3 files changed, 79 insertions(+), 0 deletions(-)
>>>>  create mode 100644 Documentation/devicetree/bindings/clock/omap4-clock.txt
> If we are doing this, we might as well do for all platforms(OMAP3-5,
> AM..) in an series, no?
> 
Yes, once we agree on the approach, I can write it for all OMAPs.

cheers,
-roger


From santosh.shilimkar at ti.com  Fri Apr  5 05:04:43 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Fri, 5 Apr 2013 14:34:43 +0530
Subject: [PATCH v2 08/18] ARM: OMAP5: PM: Add CPU power off in hotplug path
In-Reply-To: <87vc82nqy3.fsf@linaro.org>
References: <1364205910-32392-1-git-send-email-santosh.shilimkar@ti.com>
 <1364205910-32392-9-git-send-email-santosh.shilimkar@ti.com>
 <876203uypd.fsf@linaro.org> <515D7ECE.6040503@ti.com>
 <87vc82nqy3.fsf@linaro.org>
Message-ID: <515E93AB.8000008@ti.com>

On Thursday 04 April 2013 11:01 PM, Kevin Hilman wrote:
> Santosh Shilimkar <santosh.shilimkar at ti.com> writes:
> 
>> On Thursday 04 April 2013 02:19 AM, Kevin Hilman wrote:
>>> Santosh Shilimkar <santosh.shilimkar at ti.com> writes:
>>>
>>>> Add power management code to handle the CPU off mode to enable CPUP hotplug
>>>> mode for OMAP5 devices. Separate suspend finisher is used for OMAP5(Cortex-A15)
>>>> because it doesn't use SCU power status register and external PL310 L2 cache
>>>> which makes code flow bit different.
>>>>
>>>> Acked-by: Nishanth Menon <nm at ti.com>
>>>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
>>>
>>> [...]
>>>
>>>> @@ -436,14 +445,21 @@ int __init omap4_mpuss_init(void)
>>>>  
>>>>  	if (cpu_is_omap44xx()) {
>>>>  		omap_pm_ops.finish_suspend = omap4_finish_suspend;
>>>> +		omap_pm_ops.hotplug_restart = omap_secondary_startup;
>>>>  		omap_pm_ops.resume = omap4_cpu_resume;
>>>>  		omap_pm_ops.scu_prepare = scu_pwrst_prepare;
>>>>  		cpu_context_offset = OMAP4_RM_CPU0_CPU0_CONTEXT_OFFSET;
>>>>  	} else if (soc_is_omap54xx()) {
>>>> +		omap_pm_ops.finish_suspend = omap5_finish_suspend;
>>>> +		omap_pm_ops.hotplug_restart = omap5_secondary_startup;
>>>>  		cpu_context_offset = OMAP54XX_RM_CPU0_CPU0_CONTEXT_OFFSET;
>>>>  		enable_mercury_retention_mode();
>>>>  	}
>>>>  
>>>> +	/* Over-write the OMAP4 hook to take care of ROM BUG */
>>>> +	if (cpu_is_omap446x())
>>>> +		omap_pm_ops.hotplug_restart = omap_secondary_startup_4460;
>>>
>>> A couple nits...
>>>
>>> I think this would go better at the end of the 'if omap44xx' block
>>> above.
>>>
>> Nishant commented on this as well. The indentation was looking ugly
>> and I thought its better to have this BUG hunk separate. I prefer
>> it this way though if you really insist, i have to change it.
> 
> I insist.
> 
Will update the patch accordingly then.

Regards,
Santosh



From santosh.shilimkar at ti.com  Fri Apr  5 05:07:01 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Fri, 5 Apr 2013 14:37:01 +0530
Subject: [PATCH v2 09/18] ARM: OMAP4+: PM: Restore CPU power state to
 ON with clockdomain force wakeup method
In-Reply-To: <87li8ynqf5.fsf@linaro.org>
References: <1364205910-32392-1-git-send-email-santosh.shilimkar@ti.com>
 <1364205910-32392-10-git-send-email-santosh.shilimkar@ti.com>
 <87mwtftjvy.fsf@linaro.org> <515D8215.10705@ti.com>
 <87li8ynqf5.fsf@linaro.org>
Message-ID: <515E9435.6050007@ti.com>

On Thursday 04 April 2013 11:12 PM, Kevin Hilman wrote:
> Santosh Shilimkar <santosh.shilimkar at ti.com> writes:
> 
>> On Thursday 04 April 2013 02:24 AM, Kevin Hilman wrote:
>>> Santosh Shilimkar <santosh.shilimkar at ti.com> writes:
>>>
>>>> While waking up CPU from off state using clock domain force wakeup, restore
>>>> the CPU power state to ON state before putting CPU clock domain under
>>>> hardware control. Otherwise CPU wakeup might fail. The change is recommended
>>>> for all OMAP4+ devices though the PRCM weakness was observed on OMAP5
>>>> devices first.
>>>
>>> Sounds reasonable, but can you describe the "weakness" a little more?
>>>
>>> IOW, what exactly happens if this is not done?  It sounds like the CPU
>>> might immediately go back to retention, but how does that happen unless
>>> it does a WFI?
>>>
>> Its more of lock-up inside the hardware state machine and results
>> are UN-predictable. We have seen hard-locks most of the time where system
>> is just frozen. The hardware gets into wrong state machine if the power
>> domain state isn't restored. I will add this information to changelog.
>>
>>> Also, this sounds like a fix to me, and should probably be broken out
>>> accordingly.
>>>
>> Yeah. You mean a separate patch from the series, right ? This patch
>> actually can be independently added.
>>
>> In case you decide to apply it for the fixes branch, updated patch
>> at end of the email.
> 
> Curious which branch you applied it to?  It didn't apply cleanly to
> v3.9-rc5 (but did with fuzz).
> 
Mostly applied on top of the Tony's pull request branches.

> So I've now added it to my for_3.10/fixes/pm branch.
> 
Thanks. I will pull that in to re-base other patches.

Regards,
Santosh



From marc.zyngier at arm.com  Fri Apr  5 05:08:04 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Fri, 05 Apr 2013 10:08:04 +0100
Subject: [PATCH 6/7] ARM: KVM: switch to a dual-step HYP init code
In-Reply-To: <1365113453.24496.26.camel@smoke>
References: <1364909115-3810-1-git-send-email-marc.zyngier@arm.com>
 <1364909115-3810-7-git-send-email-marc.zyngier@arm.com>
 <1365113453.24496.26.camel@smoke>
Message-ID: <515E9474.2070100@arm.com>

On 04/04/13 23:10, Geoff Levand wrote:
> Hi,
> 
> On Tue, 2013-04-02 at 14:25 +0100, Marc Zyngier wrote:
>> +	@ Jump to the trampoline page
>> +	ldr	r2, =#PAGE_MASK
>> +	adr	r3, target
>> +	bic	r3, r3, r2
>> +	ldr	r2, =#TRAMPOLINE_VA
>> +	add	r3, r3, r2
>> +	mov	pc, r3
> 
> I guess you need 'ldr r2, =PAGE_MASK'.
> 
>   arch/arm/kvm/init.S:114: Error: bad expression -- `ldr r2,=#(~((1<<12)-1))'
>   arch/arm/kvm/init.S:117: Error: bad expression -- `ldr r2,=#0xffff0000'

Oddly enough, this code compiles perfectly fine on my box.
What's your compiler/binutils versions?

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...



From shawn.guo at linaro.org  Fri Apr  5 05:16:58 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Fri, 5 Apr 2013 17:16:58 +0800
Subject: [PATCH] ARM: dts: imx23-olinuxino: Set the sdcard as non-removable
In-Reply-To: <1365135413-31493-1-git-send-email-aletes.xgr@gmail.com>
References: <1365135413-31493-1-git-send-email-aletes.xgr@gmail.com>
Message-ID: <20130405091656.GD2667@S2101-09.ap.freescale.net>

On Fri, Apr 05, 2013 at 01:16:53AM -0300, Alexandre Pereira da Silva wrote:
> The imx23-olinuxino sdcard doesn't support card detect.
> 
So it sounds more like a "broken-cd" rather than "non-removable"?

Shawn

> Signed-off-by: Alexandre Pereira da Silva <aletes.xgr at gmail.com>
> ---
>  arch/arm/boot/dts/imx23-olinuxino.dts |    1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/boot/dts/imx23-olinuxino.dts b/arch/arm/boot/dts/imx23-olinuxino.dts
> index e7484e4..03f55c2 100644
> --- a/arch/arm/boot/dts/imx23-olinuxino.dts
> +++ b/arch/arm/boot/dts/imx23-olinuxino.dts
> @@ -29,6 +29,7 @@
>  				pinctrl-names = "default";
>  				pinctrl-0 = <&mmc0_4bit_pins_a &mmc0_pins_fixup>;
>  				bus-width = <4>;
> +				non-removable;
>  				status = "okay";
>  			};
>  
> -- 
> 1.7.10
> 



From balbi at ti.com  Fri Apr  5 05:19:02 2013
From: balbi at ti.com (Felipe Balbi)
Date: Fri, 5 Apr 2013 12:19:02 +0300
Subject: [PATCH 3/5] gpio/omap: optimise interrupt service routine
In-Reply-To: <1365106576-31816-4-git-send-email-jon-hunter@ti.com>
References: <1365106576-31816-1-git-send-email-jon-hunter@ti.com>
 <1365106576-31816-4-git-send-email-jon-hunter@ti.com>
Message-ID: <20130405091902.GA9626@arwen.pp.htv.fi>

On Thu, Apr 04, 2013 at 03:16:14PM -0500, Jon Hunter wrote:
> The OMAP GPIO interrupt service routine is checking each bit in the
> GPIO interrupt status register to see which bits are set. It is not
> efficient to check every bit especially if only a few bits are set.
> Therefore, instead of checking every bit use the __ffs() function,
> which returns the location of the first set bit, to find all the set
> bits.
> 
> This optimisation was suggested-by and developed in collaboration
> with Felipe Balbi.
> 
> Cc: Felipe Balbi <balbi at ti.com>
> 
> Signed-off-by: Jon Hunter <jon-hunter at ti.com>

looks alright:

Reviewed-by: Felipe Balbi <balbi at ti.com>

> ---
>  drivers/gpio/gpio-omap.c |   14 +++++++-------
>  1 file changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
> index 5af7acd..685e850 100644
> --- a/drivers/gpio/gpio-omap.c
> +++ b/drivers/gpio/gpio-omap.c
> @@ -689,7 +689,7 @@ static void gpio_irq_handler(unsigned int irq, struct irq_desc *desc)
>  {
>  	void __iomem *isr_reg = NULL;
>  	u32 isr;
> -	unsigned int i;
> +	unsigned int bit;
>  	struct gpio_bank *bank;
>  	int unmasked = 0;
>  	struct irq_chip *chip = irq_desc_get_chip(desc);
> @@ -730,9 +730,9 @@ static void gpio_irq_handler(unsigned int irq, struct irq_desc *desc)
>  		if (!isr)
>  			break;
>  
> -		for (i = 0; isr != 0; isr >>= 1, i++) {
> -			if (!(isr & 1))
> -				continue;
> +		while (isr) {
> +			bit = __ffs(isr);
> +			isr &= ~(1 << bit);
>  
>  			/*
>  			 * Some chips can't respond to both rising and falling
> @@ -741,10 +741,10 @@ static void gpio_irq_handler(unsigned int irq, struct irq_desc *desc)
>  			 * to respond to the IRQ for the opposite direction.
>  			 * This will be indicated in the bank toggle_mask.
>  			 */
> -			if (bank->toggle_mask & (1 << i))
> -				_toggle_gpio_edge_triggering(bank, i);
> +			if (bank->toggle_mask & (1 << bit))
> +				_toggle_gpio_edge_triggering(bank, bit);
>  
> -			generic_handle_irq(irq_find_mapping(bank->domain, i));
> +			generic_handle_irq(irq_find_mapping(bank->domain, bit));
>  		}
>  	}
>  	/* if bank has any level sensitive GPIO pin interrupt
> -- 
> 1.7.10.4
> 

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130405/1674148b/attachment.sig>

From s.hauer at pengutronix.de  Fri Apr  5 05:22:06 2013
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Fri, 5 Apr 2013 11:22:06 +0200
Subject: 3.8 no mach include directory anymore?
In-Reply-To: <15525047.PsIxlFA1vB@dabox>
References: <15525047.PsIxlFA1vB@dabox>
Message-ID: <20130405092206.GA10373@pengutronix.de>

Hi Tim,

On Fri, Apr 05, 2013 at 08:13:02AM +0200, Tim Sander wrote:
> Hi
> 
> I have a small driver which uses the MX35_IO_ADDRESS which had been defined in
> #include <mach/mx35.h>

A driver should never use MX35_IO_ADDRESS.

> but while the mx35.h file still exist the include directory has vanished?
> 
> Any idea how to get the module compiling again with 3.8?

Use ioremap, add whatever hack is necessary, or very much preferred:
Convert you board over to devicetree and retrieve the base address
properly from there.

Sascha


-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From shawn.guo at linaro.org  Fri Apr  5 05:21:33 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Fri, 5 Apr 2013 17:21:33 +0800
Subject: [PATCH v4 1/2] ARM: dts: mxs: Use 'regulator-fixed' for turning
 on LCD
In-Reply-To: <1365128456-8762-1-git-send-email-festevam@gmail.com>
References: <1365128456-8762-1-git-send-email-festevam@gmail.com>
Message-ID: <20130405092131.GE2667@S2101-09.ap.freescale.net>

On Thu, Apr 04, 2013 at 11:20:54PM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam at freescale.com>
> 
> Instead of using a custom binding for turning on a GPIO that activates the
> LCD, use the standard 'regulator-fixed'.
> 
> Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>

For sake of git bisect, I think you need to have these two patches be
one?

> ---
> Changes since v3:
> - Fix regulator bindings (use lcd-supply)
> Changes since v2:
> - Use regulator-fixed
> Changes since v1:
> - Adjust Subject, since the change is not specific to mx28evk
>  Documentation/devicetree/bindings/fb/mxsfb.txt |    5 +----
>  arch/arm/boot/dts/imx23-evk.dts                |   11 ++++++++++-
>  arch/arm/boot/dts/imx28-evk.dts                |   11 ++++++++++-
>  3 files changed, 21 insertions(+), 6 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/fb/mxsfb.txt b/Documentation/devicetree/bindings/fb/mxsfb.txt
> index 7ba3b76..b15230c 100644
> --- a/Documentation/devicetree/bindings/fb/mxsfb.txt
> +++ b/Documentation/devicetree/bindings/fb/mxsfb.txt
> @@ -8,9 +8,7 @@ Required properties:
>  - display : phandle to display node (see below for details)
>  
>  Optional properties:
> -- panel-enable-gpios : Should specify the gpio for panel enable
> -
> -* display node
> +- display node
>  
Is this change related?  You are turning a sub-node into a optional
property.  It does not look right.

Shawn

>  Required properties:
>  - bits-per-pixel : <16> for RGB565, <32> for RGB888/666.
> @@ -25,7 +23,6 @@ lcdif at 80030000 {
>  	compatible = "fsl,imx28-lcdif";
>  	reg = <0x80030000 2000>;
>  	interrupts = <38 86>;
> -	panel-enable-gpios = <&gpio3 30 0>;
>  
>  	display: display {
>  		bits-per-pixel = <32>;
> diff --git a/arch/arm/boot/dts/imx23-evk.dts b/arch/arm/boot/dts/imx23-evk.dts
> index 7880e17..da0588a 100644
> --- a/arch/arm/boot/dts/imx23-evk.dts
> +++ b/arch/arm/boot/dts/imx23-evk.dts
> @@ -59,7 +59,7 @@
>  			lcdif at 80030000 {
>  				pinctrl-names = "default";
>  				pinctrl-0 = <&lcdif_24bit_pins_a>;
> -				panel-enable-gpios = <&gpio1 18 0>;
> +				lcd-supply = <&reg_lcd_3v3>;
>  				display = <&display>;
>  				status = "okay";
>  
> @@ -120,6 +120,15 @@
>  			regulator-max-microvolt = <3300000>;
>  			gpio = <&gpio1 29 0>;
>  		};
> +
> +		reg_lcd_3v3: lcd-3v3 {
> +			compatible = "regulator-fixed";
> +			regulator-name = "lcd-3v3";
> +			regulator-min-microvolt = <3300000>;
> +			regulator-max-microvolt = <3300000>;
> +			gpio = <&gpio1 18 0>;
> +			enable-active-high;
> +		};
>  	};
>  
>  	backlight {
> diff --git a/arch/arm/boot/dts/imx28-evk.dts b/arch/arm/boot/dts/imx28-evk.dts
> index 2d4ea3b..3637bf3 100644
> --- a/arch/arm/boot/dts/imx28-evk.dts
> +++ b/arch/arm/boot/dts/imx28-evk.dts
> @@ -123,7 +123,7 @@
>  				pinctrl-names = "default";
>  				pinctrl-0 = <&lcdif_24bit_pins_a
>  					     &lcdif_pins_evk>;
> -				panel-enable-gpios = <&gpio3 30 0>;
> +				lcd-supply = <&reg_lcd_3v3>;
>  				display = <&display>;
>  				status = "okay";
>  
> @@ -310,6 +310,15 @@
>  			gpio = <&gpio3 8 0>;
>  			enable-active-high;
>  		};
> +
> +		reg_lcd_3v3: lcd-3v3 {
> +			compatible = "regulator-fixed";
> +			regulator-name = "lcd-3v3";
> +			regulator-min-microvolt = <3300000>;
> +			regulator-max-microvolt = <3300000>;
> +			gpio = <&gpio3 30 0>;
> +			enable-active-high;
> +		};
>  	};
>  
>  	sound {
> -- 
> 1.7.9.5
> 



From florian at openwrt.org  Fri Apr  5 05:21:50 2013
From: florian at openwrt.org (Florian Fainelli)
Date: Fri, 05 Apr 2013 11:21:50 +0200
Subject: [PATCH 3/5 v2] ARM: kirkwood: add device node entries for the
 gigabit interfaces
In-Reply-To: <20130404213517.GB25904@schnuecks.de>
References: <1365071235-11611-1-git-send-email-florian@openwrt.org>
 <1365071235-11611-4-git-send-email-florian@openwrt.org>
 <20130404213517.GB25904@schnuecks.de>
Message-ID: <515E97AE.4080608@openwrt.org>

Le 04/04/13 23:35, Simon Baatz a ?crit :
> Hi Florian,
>
> On Thu, Apr 04, 2013 at 12:27:13PM +0200, Florian Fainelli wrote:
>> This patch modifies kirkwood.dtsi to specify the various gigabit
>> interfaces nodes available on kirkwood devices. They are disabled by
>> default and should be enabled on a per-board basis. egiga0 and egiga1
>> aliases are defined for convenience. The mdio node is also present and
>> should be enabled on a per-board basis as well.
>>
>> Signed-off-by: Florian Fainelli <florian at openwrt.org>
>> ---
>> Changes since v1:
>> - dropped change to arch/arm/mach-kirkwood/common.c to avoid merge conflicts
>
> I think we should remove the clock aliases in
> kirkwood_legacy_clk_init() in mach-kirkwood/dt-board.c (once we have
> proper clock support, see my other mail).
>
[snip]
>
> Don't we need to add:
>
> 			interrupts = <46>;
>
> here?

Right this is missing, in fact it still works ok because the orion-mdio 
driver can do busy waiting instead of interrupt signaling. Will fix that 
in the next round, thanks!
--
Florian


From shawn.guo at linaro.org  Fri Apr  5 05:29:50 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Fri, 5 Apr 2013 17:29:50 +0800
Subject: [PATCH] ARM i.MX6: Fix ldb_di clock selection
In-Reply-To: <1365084209-27240-1-git-send-email-dirk.behme@de.bosch.com>
References: <1365084209-27240-1-git-send-email-dirk.behme@de.bosch.com>
Message-ID: <20130405092948.GF2667@S2101-09.ap.freescale.net>

Arnd, Olof,

Please help apply this as a fix for 3.9.

On Thu, Apr 04, 2013 at 04:03:29PM +0200, Dirk Behme wrote:
> According to the recent i.MX6 Quad technical reference manual, mode 0x4 (100b)
> of the CCM_CS2DCR register (address 0x020C402C) bits [11-9] and [14-12] select
> the PLL3 clock, and not the PLL3 PFD1 540M clock. In our code, the PLL3 root
> clock is named 'pll3_usb_otg', select this instead of the 540M clock.
> 
> Signed-off-by: Dirk Behme <dirk.behme at de.bosch.com>

Cc: <stable at vger.kernel.org>

Acked-by: Shawn Guo <shawn.guo at linaro.org>



From g.liakhovetski at gmx.de  Fri Apr  5 05:33:42 2013
From: g.liakhovetski at gmx.de (Guennadi Liakhovetski)
Date: Fri, 5 Apr 2013 11:33:42 +0200 (CEST)
Subject: [PATCH v2] irqchip: renesas-intc-irqpin: DT binding for sense bitfield
 width
Message-ID: <Pine.LNX.4.64.1304051128090.997@axis700.grange>

Most Renesas irqpin controllers have 4-bit sense fields, however, some
have different widths. This patch adds a DT binding to optionally
specify such non-standard values.

Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas at gmail.com>
---

v2: is no longer based on an earlier "ARM: shmobile: irqpin: fix handling 
of spurious interrupts in DT case" patch, which needs more work.

 .../interrupt-controller/renesas,intc-irqpin.txt   |   13 +++++++++++++
 drivers/irqchip/irq-renesas-intc-irqpin.c          |    5 +++++
 2 files changed, 18 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.txt

diff --git a/Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.txt b/Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.txt
new file mode 100644
index 0000000..c6f09b7
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.txt
@@ -0,0 +1,13 @@
+DT bindings for the R-/SH-Mobile irqpin controller
+
+Required properties:
+
+- compatible: has to be "renesas,intc-irqpin"
+- #interrupt-cells: has to be <2>
+
+Optional properties:
+
+- any properties, listed in interrupts.txt in this directory, and any standard
+  resource allocation properties
+- sense-bitfield-width: width of a single sense bitfield in the SENSE register,
+  if different from the default 4 bits
diff --git a/drivers/irqchip/irq-renesas-intc-irqpin.c b/drivers/irqchip/irq-renesas-intc-irqpin.c
index 5a68e5a..7a02dfe 100644
--- a/drivers/irqchip/irq-renesas-intc-irqpin.c
+++ b/drivers/irqchip/irq-renesas-intc-irqpin.c
@@ -18,6 +18,7 @@
  */
 
 #include <linux/init.h>
+#include <linux/of.h>
 #include <linux/platform_device.h>
 #include <linux/spinlock.h>
 #include <linux/interrupt.h>
@@ -429,6 +430,10 @@ static int intc_irqpin_probe(struct platform_device *pdev)
 		}
 	}
 
+	if (!pdata)
+		of_property_read_u32(pdev->dev.of_node, "sense-bitfield-width",
+				     &p->config.sense_bitfield_width);
+
 	/* use more severe masking method if requested */
 	if (p->config.control_parent) {
 		enable_fn = intc_irqpin_irq_enable_force;
-- 
1.7.2.5



From santosh.shilimkar at ti.com  Fri Apr  5 05:41:32 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Fri, 5 Apr 2013 15:11:32 +0530
Subject: [PATCH v2 17/18] ARM: OMAP4+: CPUidle: Add OMAP5 idle driver
 support
In-Reply-To: <87li8ymb84.fsf@linaro.org>
References: <1364205910-32392-1-git-send-email-santosh.shilimkar@ti.com>
 <1364205910-32392-18-git-send-email-santosh.shilimkar@ti.com>
 <87fvz7qpce.fsf@linaro.org> <515D8B4B.6000800@ti.com>
 <87li8ymb84.fsf@linaro.org>
Message-ID: <515E9C4C.3020709@ti.com>

On Thursday 04 April 2013 11:25 PM, Kevin Hilman wrote:
> Santosh Shilimkar <santosh.shilimkar at ti.com> writes:
> 
>> On Thursday 04 April 2013 02:55 AM, Kevin Hilman wrote:
>>> Santosh Shilimkar <santosh.shilimkar at ti.com> writes:
>>>
>>>> The OMAP5 idle driver can re-use OMAP4 CPUidle driver implementation thanks
>>>> to compatible MPUSS design.
>>>>
>>>> Though unlike OMAP4, on OMAP5 devices, MPUSS CSWR (Close Switch
>>>> Retention) power states can be achieved with respective power states
>>>> on CPU0 and CPU1 power domain. This mode was broken on OMAP4 devices
>>>> because of hardware limitation.
>>>
>>> I'm a bit confused by the description here.
>>>
>>> I gather from the code that this means that CPU0 and CPU1 can hit CSWR
>>> independently, correct?
>>>
>> They can be programmed independently without any ordering(like
>> CPU0 last etc), but the actual transition to the low power CSWR
>> happens together. Till that the first CPU hit WFI remains in WFI
>> state waiting for other CPU to hit WFI and then both transition
>> together.
>> Completely managed inside hardware.
> 
> OK, elaborating this in the changelog would be helpful.  Use the "will I
> understand this changelog in a year" rule to see if the changelog is
> detailed enough.  Or better, "will Kevin understand this changelog in a
> year."  (hint: the answer is usually no.)  ;)
> 
:-) I added above description in change-log.

>>>> Also there is no CPU low power entry order requirement like
>>>> master CPU etc for CSWR C-state, which is icing on the cake. 
>>>
>>> Even on secure devices?
>>>
>> Yes. On secure devices too. Actually since we don't loose context,
>> secure entry/exit doesn't come into picture.
>>
>>>> Code makes use of voting scheme for cluster low power state to support
>>>> MPUSS CSWR C-state.
>>>
>>> The voting scheme and associated locking should be better described
>>> here, or commented in the code itself.
>>>
>> You are right. It deserves some description.
>>
>>>> Supported OMAP5 CPUidle C-states:
>>>>         C1 - CPU0 ON(WFI) + CPU1 ON(WFI) + MPUSS ON
>>>>         C2 - CPU0 CSWR + CPU1 CSWR + MPUSS CSWR
>>>>         C3 - CPU0 OFF + CPU1 OFF + MPUSS OSWR
>>>>
>>>> Acked-by: Nishanth Menon <nm at ti.com>
>>>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
>>>
>>> [...]
>>>
>>>> +static int omap_enter_idle_smp(struct cpuidle_device *dev,
>>>> +			struct cpuidle_driver *drv,
>>>> +			int index)
>>>> +{
>>>> +	struct idle_statedata *cx = state_ptr + index;
>>>> +	int cpu_id = smp_processor_id();
>>>> +	unsigned long flag;
>>>> +
>>>> +	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &cpu_id);
>>>
>>> I think the CPUidle core handles the broadcast notification now.
>>>
>> Not in mainline yet. And those patches came after my patches and
>> I don't wanted un-necessary merge dependency, I avoided it. Its trivial
>> though to drop if from here once the idle next is merged.
> 
> OK.
> 
> I believe that stuff is already queued, no?  Maybe ahave this as an
> add-on separate patch that can be used for your loal testing, but does
> not go upstream.
> 
Will do.

> I would only include this if you're sure the other series is not going
> upstream.
>
It might go upstream so I will manually apply the patch or pull a branch
if available.
 
>>>> +	raw_spin_lock_irqsave(&mpu_lock, flag);
>>>> +	cx->mpu_state_vote++;
>>>
>>> How about using an atomic_t and atomic_inc()/atomic_dec() instead, which
>>> will avoid the need for a spinlock.
>>>
>> Spin lock is not just for the vote variable. I had atomics opps in first
>> version I gave it to product team. But they found a race condition in
>> where MPU power state was getting overwritten by other CPU.
>>
>>> Even with that, it still seems potentially racy.  Do you need a memory
>>> barrier here to be sure that any changes from another CPU are visible
>>> here, and vice versa?
>>>
>> With locks, you don't need barriers since the updated copy is guaranteed.
> 
> It's guaranteed because the spinlock implementation uses barriers. 
> 
Yeah.

>> Can you please elaborate on potential race ? I have given pretty hard
>> thought and didn't see any race which can be exposed with locks in place.
> 
> I was referring to using atomic ops.  With atomic ops, you'd need an
> explicit barrier (which you're getting inside the spinlock
> implementation)
> 
> That being said, I have not thought through all the corner cases as you
> have, so I'll defer to your choice (as long as it's well documented.)
> If you decide to stick with spinlocks, be sure to describe all of what
> the spinlock is protecting, and why.
> 
Have updated the change-log as well as code to elaborate the lock use.

Thanks for review.

Regards,
Santosh



From broonie at opensource.wolfsonmicro.com  Fri Apr  5 05:44:12 2013
From: broonie at opensource.wolfsonmicro.com (Mark Brown)
Date: Fri, 5 Apr 2013 10:44:12 +0100
Subject: regulator: query on regulator re-entrance
In-Reply-To: <1365138582-10409-1-git-send-email-nm@ti.com>
References: <1365138582-10409-1-git-send-email-nm@ti.com>
Message-ID: <20130405094411.GA6597@opensource.wolfsonmicro.com>

On Fri, Apr 05, 2013 at 12:09:42AM -0500, Nishanth Menon wrote:

> If we ignore the details of the class 1.5 implementation, we will notice
> a) regulator set_voltage equivalent set_voltage() is required.
> b) this set_voltage does some 'magic stuff' depending on the SoC and AVS class
> and calls the 'real regulator' which talks to the PMIC over i2c/spi etc..
> in short the call sequence is more or less:
> 
> driver (cpufreq) -> AVS -> PMIC regulator.
> 
> By modeling AVS class drivers as an regulator, we then do not need to introduce
> SoC specific hacks and APIs.

But you're shoehorning something into the regulator API which isn't
supposed to be there and causing yourself problems.  This just isn't a
good idea.  The regulator API already has a mechanism for supporting
regulators which are supplied by other regulators, if you can't model in
terms of that (adding something to support variability better) then
you're not using a regulator.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130405/1d9819c6/attachment.sig>

From linux at arm.linux.org.uk  Fri Apr  5 05:41:59 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Fri, 5 Apr 2013 10:41:59 +0100
Subject: [GIT PULL] Multi Cluster Power Management infrastructure
In-Reply-To: <alpine.LFD.2.03.1304042138160.1171@syhkavp.arg>
References: <alpine.LFD.2.03.1303251219530.1372@syhkavp.arg>
 <20130328134808.GD16765@e102568-lin.cambridge.arm.com>
 <alpine.LFD.2.03.1304022258430.1171@syhkavp.arg>
 <alpine.LFD.2.03.1304042138160.1171@syhkavp.arg>
Message-ID: <20130405094159.GH17995@n2100.arm.linux.org.uk>

Right, you force my hand.  None of the stuff below should be public, but
you give me no choice now but to publically defend myself against your
allegations.

The reason that I haven't merged it is that:

1. At the beginning of December, when the TI situation looked very
   uncertain, I approached Linaro to see whether it was possible to
   sort out a relationship with them.  Linaro were enthusiastic.

2. It took weeks for anything to really happen - indeed, the first
   sign of any kind of idea for any work was first mentioned at the
   beginning of January, the day that Nicolas posted these patches
   for review.  The work was going to be to review these patches.

3. As that was going to be the subject of the work, and there was no
   arrangement in place, I actively avoided reviewing these changes.

4. Along with this came the provision that I was to attend two Linaro
   connects a year.

5. It turns out that this provision was made based on rumour and gossip
   about my medical situation concerning my eye, based on travel that I
   had done last year.  Rather than *talk* to me and find out what the
   real situation was, Linaro decided to have internal discussions about
   this, based on this rumour and gossip.

6. It took a week or more to sort out that situation, which should never
   have arrisen if people didn't gossip and rumour.

7. The work (2) has now been withdrawn, and I'm now being left with being
   told "we have problems working out what work to give you".

So at this point, I view any kind of relationship with Linaro as being a
extremely poor, and probably no longer worth persuing - not because of
any fault of mine, but a total wreckage of our relationship due to bad
management behaviour within Linaro based on rumour and gossip.

Hence, I have never gone back and reviewed the patches Nicolas is
referring to, because I've *NO* idea what so ever what's going on with
Linaro.  If they can't think of anything they want me to work on, and
this stuff is still outstanding then... well... what hope is there?

Now, I'm currently on holiday.  I'm going to be on holday until after
mid-April.  I'm not pulling anything until then.  I'm not applying anything
until then.  I'm not even reading this mailbox - and given current mail
rates at 300-400 messages per day, I will *not* be reading back over a
fortnights worth of email.

The only reason I'm trying to this is because Will Deacon pointed it out
to me via IRC.

So, in summary, this situation has been created by Linaro *themselves*
and it's all their problem.  They can sort it out if they want to be
cooperative and give me the work that they were originally proposing.
If not... I'm not sure where we go.

But all that I get from you is "you must pull this stuff anyway, whether
you've reviewed it or not".  Sorry, no.

On Thu, Apr 04, 2013 at 10:03:54PM -0400, Nicolas Pitre wrote:
> I want to deplore a situation that highlights a bottleneck with our 
> current upstreaming process on ARM affecting the MCPM patch series I'm 
> maintaining.
> 
> This patch series has been extensively reviewed.
> 
> 1st review cycle (10 Jan 2013):
> http://news.gmane.org/group/gmane.linux.ports.arm.kernel/thread=208625
> 
> 2nd review cycle (24 Jan 2013):
> http://news.gmane.org/group/gmane.linux.ports.arm.kernel/thread=212196
> 
> 3rd review cycle (29 Jan 2013):
> http://news.gmane.org/group/gmane.linux.ports.arm.kernel/thread=213562
> 
> 4th review cycle (5 Feb 2013):
> http://news.gmane.org/group/gmane.linux.ports.arm.kernel/thread=215477
> 
> The following people were involved in the discussion:
> 
>   Achin Gupta
>   Catalin Marinas
>   Dave Martin
>   Jon Medhurst
>   Joseph Lo
>   Lorenzo Pieralisi
>   Saeed Bishara
>   Santosh Shilimkar
>   Stephen Boyd
>   Rob Herring
>   Pawel Moll
>   Will Deacon
> 
> Resulting review comments were all addressed.  
> 
> So, a pull request for the v3.8 merge window was posted (6 Feb 2013):
> http://article.gmane.org/gmane.linux.ports.arm.kernel/216061
> 
> This, however, didn't get merged in time due to some miscommunication
> about non technical reasons.  I therefore won't expose those reasons 
> here.  Suffice to say that a merge window was missed.
> 
> Therefore, this was followed by another pull request for the v3.9 merge window (25 Mar 2013):
> http://article.gmane.org/gmane.linux.ports.arm.kernel/225873
> 
> Followed by a merge plan inquiry from Lorenzo (28 Mar 2013):
> http://article.gmane.org/gmane.linux.ports.arm.kernel/227035
> 
> To end up with my ping (3 Apr 2013):
> http://article.gmane.org/gmane.linux.ports.arm.kernel/228209
> 
> Russell mentioned having issues with the mailing list traffic and pull
> request being buried.  He therefore suggested a special email alias
> to filter pull requests (22 Mar 2013):
> http://article.gmane.org/gmane.linux.ports.arm.kernel/225377
> 
> The last pull request used that alias, and the latest ping did use both 
> the pull alias as well as his regular email address.
> 
> We're approaching v3.9-rc6, and there is still no sign of this patch set 
> being headed for mainline yet.  The system is _not_ working if this 
> series is to miss yet another merge window.
> 
> On March 28th, Russell mentioned he'd be sporadically away for the 
> following two weeks, and suggested that the GIC patches go through the 
> ARM SoC tree:
> http://article.gmane.org/gmane.linux.ports.arm.kernel/227040
> 
> Given the lack of backup to pick up the load when Russell is unavailable 
> (seeing the next merge window approaching and still no response from my 
> latest pull request and its subsequent recalls), I'm questionning the 
> current process scalability. Therefore, at this point, I'm suggesting 
> that the MCPM series be merged in the ARM SoC tree as well, as a backup 
> solution.
> 
> After all, this series is a prerequisite for more patches about platform 
> specific patches meant for the ARM SoC tree but which currently are 
> still waiting.  Having the prerequisite in the ARM SOC tree will allow 
> for those patches to be exposed earlier.
> 
> 
> Nicolas


From b-cousson at ti.com  Fri Apr  5 05:56:01 2013
From: b-cousson at ti.com (Benoit Cousson)
Date: Fri, 5 Apr 2013 11:56:01 +0200
Subject: [PATCH v4 00/21] ARM: OMAP2+: Adapt to ehci-omap changes for 3.10
In-Reply-To: <515E8B99.8080803@ti.com>
References: <1363794300-31526-1-git-send-email-rogerq@ti.com>
 <515E8B99.8080803@ti.com>
Message-ID: <515E9FB1.2040803@ti.com>

Hi Roger,

On 04/05/2013 10:30 AM, Benoit Cousson wrote:

...

>>   ARM: dts: OMAP4: Add HS USB Host IP nodes
>>   ARM: dts: OMAP3: Add HS USB Host IP nodes
>>   ARM: dts: omap3-beagle: Add USB Host support
> 
> These 3 DTS patches are good to me, but I cannot applied them on top of
> the already existing patches I queued for 3.10.
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git
> for_3.10/dts
> 
> Could you rebase these 3 ones only, and I will applied them.

Mmm, in fact, I've just seen the pull request from Tony :-(


Tony,

Don't you want to remove these DTS patches from the pull-request?

Otherwise, I will have to rebase the whole DTS series on top of yours.
That being said, if the branch is not supposed to be rebased, it is doable.

Thanks,
Benoit



From florian at openwrt.org  Fri Apr  5 05:56:48 2013
From: florian at openwrt.org (Florian Fainelli)
Date: Fri, 05 Apr 2013 11:56:48 +0200
Subject: [PATCH 1/5 v2] mv643xx_eth: add Device Tree bindings
In-Reply-To: <20130404212906.GA25904@schnuecks.de>
References: <1365071235-11611-1-git-send-email-florian@openwrt.org>
 <1365071235-11611-2-git-send-email-florian@openwrt.org>
 <20130404212906.GA25904@schnuecks.de>
Message-ID: <515E9FE0.8050402@openwrt.org>

Hello Simon,

First of all, thanks for getting these patches a try!

Le 04/04/13 23:29, Simon Baatz a ?crit :
> Hi Florian
>

[snip]

>>   	if (!mv643xx_eth_version_printed++)
>>   		pr_notice("MV-643xx 10/100/1000 ethernet driver version %s\n",
>
> This is not related to your change, but there is a problem in this
> function that has already been discussed in the past if I remember
> correctly: The respective clock needs to be enabled here (at least
> on Kirkwood), since accesses to the hardware are done below.
> Enabling the clock only in mv643xx_eth_probe() is too late.
>
> As said, this is not a problem introduced by your changes (and which
> is currently circumvented by enabling the respective clocks in
> kirkwood_legacy_clk_init() and kirkwood_ge0x_init()), but we might
> want to fix this now to get rid of unconditionally enabling the GE
> clocks in the DT case.

I think there may have been some confusion between the "ethernet-group" 
clock and the actual Ethernet port inside the "ethernet-group". The 
mv643xx_eth driver assumes we have a per-port clock gating scheme, while 
I think we have a per "ethernet-group" clock gating scheme instead. Like 
you said, I think this should be addressed separately.

[snip]

>
> You don't change the clk initialization here:
>
> #if defined(CONFIG_HAVE_CLK)
> 	mp->clk = clk_get(&pdev->dev, (pdev->id ? "1" : "0"));
> 	if (!IS_ERR(mp->clk)) {
> 		clk_prepare_enable(mp->clk);
> 		mp->t_clk = clk_get_rate(mp->clk);
> 	}
> #endif
>
> Which, if I understand correctly, works in the DT case because you
> assign "clock-names" to the clocks in the DTS. However, I wonder
> whether this works for any but the first Ethernet device.
>
> In the old platform device setup, the pdev->id was set when
> initialiazing the platform_device structure in common.c.  Where is
> this done in the DT case?

Looks like you are right, in the DT case, I assume that we should lookup 
the clock using NULL instead of "1" or "0" so we match any clock instead 
of a specific one.

[snip]

>
>
> In phy_scan(), the phy is searched like this:
>
> 		snprintf(phy_id, sizeof(phy_id), PHY_ID_FMT,
> 				"orion-mdio-mii", addr);
>
> 		phydev = phy_connect(mp->dev, phy_id, mv643xx_eth_adjust_link,
> 				PHY_INTERFACE_MODE_GMII);
>
> But "orion-mdio-mii:xx" is the name of the PHY if MDIO is setup via a
> platform_device. I could not get this to work if the MDIO device is
> setup via DT. Am I doing something wrong?

I just missed updating this part of the code to probe for PHYs. The 
board I tested with uses a "PHY_NONE" configuration. I will add the 
missing bits for of_phy_connect() to be called here.

>
>
> Additionally, in phy_scan() there is this:
>
> 	if (phy_addr == MV643XX_ETH_PHY_ADDR_DEFAULT) {
> 		start = phy_addr_get(mp) & 0x1f;
> 		num = 32;
> 	} else {
> 	...
>
> MV643XX_ETH_PHY_ADDR_DEFAULT is defined as 0. However, many Kirkwood
> devices use "MV643XX_ETH_PHY_ADDR(0)".  If the module probe is
> deferred in mv643xx_eth because the MDIO driver is not yet loaded,
> all 32 PHY addresses are scanned without success.  This is not needed
> and clutters the log.

Ok, I am not sure how we can circumvent the log cluttering that happens, 
what would be your suggestion?
--
Florian


From nsekhar at ti.com  Fri Apr  5 06:00:17 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Fri, 5 Apr 2013 15:30:17 +0530
Subject: [GIT PULL 3/3] DaVinci board updates for v3.10
In-Reply-To: <1365156017-12149-1-git-send-email-nsekhar@ti.com>
References: <1365156017-12149-1-git-send-email-nsekhar@ti.com>
Message-ID: <1365156017-12149-3-git-send-email-nsekhar@ti.com>

The following changes since commit a937536b868b8369b98967929045f1df54234323:

  Linux 3.9-rc3 (2013-03-17 15:59:32 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-for-v3.10/board

for you to fetch changes up to a0a56db9771f57667daff41cfa2546dad1abe6d9:

  ARM: davinci: use is IS_ENABLED macro (2013-04-02 15:31:15 +0530)

----------------------------------------------------------------
v3.10 board updates for DaVinci

This pull request enables CGROUPS in defconfig and also
cleans up mach-davinci to use IS_ENABLED() macro.

----------------------------------------------------------------
Lad, Prabhakar (1):
      ARM: davinci: use is IS_ENABLED macro

Sekhar Nori (1):
      ARM: davinci: defconfig: enable CGROUPS

 arch/arm/configs/da8xx_omapl_defconfig    |    1 +
 arch/arm/configs/davinci_all_defconfig    |    1 +
 arch/arm/mach-davinci/board-da830-evm.c   |    6 +-----
 arch/arm/mach-davinci/board-da850-evm.c   |    7 +------
 arch/arm/mach-davinci/board-dm644x-evm.c  |   25 +++++--------------------
 arch/arm/mach-davinci/board-dm646x-evm.c  |    7 +------
 arch/arm/mach-davinci/board-neuros-osd2.c |   15 ++-------------
 arch/arm/mach-davinci/devices.c           |    2 +-
 arch/arm/mach-davinci/usb.c               |    2 +-
 9 files changed, 14 insertions(+), 52 deletions(-)


From nsekhar at ti.com  Fri Apr  5 06:00:16 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Fri, 5 Apr 2013 15:30:16 +0530
Subject: [GIT PULL 2/3] DaVinci DT updates for v3.10
In-Reply-To: <1365156017-12149-1-git-send-email-nsekhar@ti.com>
References: <1365156017-12149-1-git-send-email-nsekhar@ti.com>
Message-ID: <1365156017-12149-2-git-send-email-nsekhar@ti.com>

Here are the DT updates for v3.10. This depends on the
SoC updates from previous pull request.

Thanks,
Sekhar

The following changes since commit 93bd65150e4ee783b7366fd0e8172f347515df61:

  ARM: davinci: remove test for undefined Kconfig macro (2013-04-03 09:43:08 +0530)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-for-v3.10/dt

for you to fetch changes up to db4c8fa7c0214c83cbbc990ba630b3b613fcf7c5:

  ARM: davinci: da850: override mmc DT node device name (2013-04-04 16:58:10 +0530)

----------------------------------------------------------------
v3.10 DT updates for DaVinci

The pull request adds support for MMC/SD and regulator on DA850 EVM.

----------------------------------------------------------------
Manjunathappa, Prakash (3):
      mmc: davinci_mmc: add DT support
      ARM: davinci: da850: add mmc DT entries
      ARM: davinci: da850: override mmc DT node device name

Vishwanathrao Badarkhe, Manish (2):
      ARM: regulator: add tps6507x device tree data
      ARM: davinci: da850: add tps6507x regulator DT data

 .../devicetree/bindings/mmc/davinci_mmc.txt        |   33 +++++++++
 arch/arm/boot/dts/da850-evm.dts                    |   70 ++++++++++++++++++++
 arch/arm/boot/dts/da850.dtsi                       |   15 +++++
 arch/arm/boot/dts/tps6507x.dtsi                    |   47 +++++++++++++
 arch/arm/mach-davinci/da8xx-dt.c                   |    1 +
 drivers/mmc/host/davinci_mmc.c                     |   70 ++++++++++++++++++--
 6 files changed, 232 insertions(+), 4 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/mmc/davinci_mmc.txt
 create mode 100644 arch/arm/boot/dts/tps6507x.dtsi


From nsekhar at ti.com  Fri Apr  5 06:00:15 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Fri, 5 Apr 2013 15:30:15 +0530
Subject: [GIT PULL 1/3] DaVinci SoC updates for v3.10
Message-ID: <1365156017-12149-1-git-send-email-nsekhar@ti.com>

Hi Arnd, Olof,

Please pull the following DaVinci SoC updates for v3.10

Thanks,
Sekhar

The following changes since commit 07961ac7c0ee8b546658717034fe692fd12eefa9:

  Linux 3.9-rc5 (2013-03-31 15:12:43 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-for-v3.10/soc

for you to fetch changes up to 93bd65150e4ee783b7366fd0e8172f347515df61:

  ARM: davinci: remove test for undefined Kconfig macro (2013-04-03 09:43:08 +0530)

----------------------------------------------------------------
v3.10 SoC updates for DaVinci

a) adds support for eHRPWM clocks
b) Fix the way MMC/SD IP versions are communicated to driver
   in preparation for DT support
c) Minor cleanup in debug-macro.S

----------------------------------------------------------------
Manjunathappa, Prakash (1):
      ARM: davinci: mmc: derive version information from device name

Paul Bolle (1):
      ARM: davinci: remove test for undefined Kconfig macro

Philip Avinash (2):
      ARM: davinci: clk framework support for enable/disable functionality
      ARM: davinci: da850: add ECAP & EHRPWM clock nodes

 arch/arm/mach-davinci/board-da830-evm.c          |    1 -
 arch/arm/mach-davinci/board-da850-evm.c          |    2 -
 arch/arm/mach-davinci/board-dm355-evm.c          |    1 -
 arch/arm/mach-davinci/board-dm365-evm.c          |    1 -
 arch/arm/mach-davinci/board-dm644x-evm.c         |    1 -
 arch/arm/mach-davinci/board-neuros-osd2.c        |    1 -
 arch/arm/mach-davinci/board-omapl138-hawk.c      |    1 -
 arch/arm/mach-davinci/board-tnetv107x-evm.c      |    1 -
 arch/arm/mach-davinci/clock.c                    |   21 ++++++---
 arch/arm/mach-davinci/clock.h                    |    2 +
 arch/arm/mach-davinci/da830.c                    |    2 +-
 arch/arm/mach-davinci/da850.c                    |   50 +++++++++++++++++++++-
 arch/arm/mach-davinci/devices-da8xx.c            |    4 +-
 arch/arm/mach-davinci/devices-tnetv107x.c        |    4 +-
 arch/arm/mach-davinci/devices.c                  |    6 ++-
 arch/arm/mach-davinci/dm355.c                    |    4 +-
 arch/arm/mach-davinci/dm365.c                    |    4 +-
 arch/arm/mach-davinci/dm644x.c                   |    2 +-
 arch/arm/mach-davinci/include/mach/da8xx.h       |    1 +
 arch/arm/mach-davinci/include/mach/debug-macro.S |    2 -
 arch/arm/mach-davinci/tnetv107x.c                |    4 +-
 drivers/mmc/host/davinci_mmc.c                   |   18 +++++++-
 include/linux/platform_data/mmc-davinci.h        |    3 --
 23 files changed, 98 insertions(+), 38 deletions(-)


From g.liakhovetski at gmx.de  Fri Apr  5 06:00:37 2013
From: g.liakhovetski at gmx.de (Guennadi Liakhovetski)
Date: Fri,  5 Apr 2013 12:00:37 +0200
Subject: [PATCH v5 2/3] ARM: shmobile: kzm9g-reference: add AS3711 and CPUFreq
 DT bindings
In-Reply-To: <1365156038-12467-1-git-send-email-g.liakhovetski@gmx.de>
References: <1365156038-12467-1-git-send-email-g.liakhovetski@gmx.de>
Message-ID: <1365156038-12467-3-git-send-email-g.liakhovetski@gmx.de>

This adds DT bindings for an AS3711 PMIC, used for supplying power to the
CPU, some peripherals and the backlight, as well as extends the cpu0 DT
node with OPPs and a reference to the PMIC to support the CPUFreq and
CPU DVFS functions.

Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas at gmail.com>
---

v5: make the sd1 regulator immediately suitable for CPUFreq instead of
postponing it to an incremental patch.

 arch/arm/boot/dts/sh73a0-kzm9g-reference.dts |   86 ++++++++++++++++++++++++++
 1 files changed, 86 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/sh73a0-kzm9g-reference.dts b/arch/arm/boot/dts/sh73a0-kzm9g-reference.dts
index 5972abb..b6f759e 100644
--- a/arch/arm/boot/dts/sh73a0-kzm9g-reference.dts
+++ b/arch/arm/boot/dts/sh73a0-kzm9g-reference.dts
@@ -18,6 +18,19 @@
 	model = "KZM-A9-GT";
 	compatible = "renesas,kzm9g-reference", "renesas,sh73a0";
 
+	cpus {
+		cpu at 0 {
+			cpu0-supply = <&vdd_dvfs>;
+			operating-points = <
+				/* kHz  uV */
+				1196000 1315000
+				 598000 1175000
+				 398667 1065000
+			>;
+			voltage-tolerance = <1>; /* 1% */
+		};
+	};
+
 	chosen {
 		bootargs = "console=tty0 console=ttySC4,115200 root=/dev/nfs ip=dhcp ignore_loglevel earlyprintk=sh-sci.4,115200";
 	};
@@ -59,6 +72,79 @@
 	};
 };
 
+&i2c0 {
+	as3711 at 40 {
+		compatible = "ams,as3711";
+		reg = <0x40>;
+
+		regulators {
+			vdd_dvfs: sd1 {
+				regulator-name = "1.315V CPU";
+				regulator-min-microvolt = <1050000>;
+				regulator-max-microvolt = <1350000>;
+				regulator-always-on;
+				regulator-boot-on;
+			};
+			sd2 {
+				regulator-name = "1.8V";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-always-on;
+				regulator-boot-on;
+			};
+			sd4 {
+				regulator-name = "1.215V";
+				regulator-min-microvolt = <1215000>;
+				regulator-max-microvolt = <1235000>;
+				regulator-always-on;
+				regulator-boot-on;
+			};
+			ldo2 {
+				regulator-name = "2.8V CPU";
+				regulator-min-microvolt = <2800000>;
+				regulator-max-microvolt = <2800000>;
+				regulator-always-on;
+				regulator-boot-on;
+			};
+			ldo3 {
+				regulator-name = "3.0V CPU";
+				regulator-min-microvolt = <3000000>;
+				regulator-max-microvolt = <3000000>;
+				regulator-always-on;
+				regulator-boot-on;
+			};
+			ldo4 {
+				regulator-name = "2.8V";
+				regulator-min-microvolt = <2800000>;
+				regulator-max-microvolt = <2800000>;
+				regulator-always-on;
+				regulator-boot-on;
+			};
+			ldo5 {
+				regulator-name = "2.8V #2";
+				regulator-min-microvolt = <2800000>;
+				regulator-max-microvolt = <2800000>;
+				regulator-always-on;
+				regulator-boot-on;
+			};
+			ldo7 {
+				regulator-name = "1.15V CPU";
+				regulator-min-microvolt = <1150000>;
+				regulator-max-microvolt = <1150000>;
+				regulator-always-on;
+				regulator-boot-on;
+			};
+			ldo8 {
+				regulator-name = "1.15V CPU #2";
+				regulator-min-microvolt = <1150000>;
+				regulator-max-microvolt = <1150000>;
+				regulator-always-on;
+				regulator-boot-on;
+			};
+		};
+	};
+};
+
 &mmcif {
 	bus-width = <8>;
 	vmmc-supply = <&reg_1p8v>;
-- 
1.7.2.5



From g.liakhovetski at gmx.de  Fri Apr  5 06:00:35 2013
From: g.liakhovetski at gmx.de (Guennadi Liakhovetski)
Date: Fri,  5 Apr 2013 12:00:35 +0200
Subject: [PATCH v5 0/3] CPUFreq for sh73a0 / kzm9g, using cpufreq-cpu0
Message-ID: <1365156038-12467-1-git-send-email-g.liakhovetski@gmx.de>

v5: essentially identical to v4, one hunk has been moved from one patch
over to another one, patch #1 no longer depends on a different patch-
series, which will have to be updated.

Cc: Guennadi Liakhovetski <g.liakhovetski+renesas at gmail.com>

Guennadi Liakhovetski (3):
  ARM: shmobile: sh73a0: add support for adjusting CPU frequency
  ARM: shmobile: kzm9g-reference: add AS3711 and CPUFreq DT bindings
  ARM: shmobile: sh73a0: add CPUFreq support

 arch/arm/boot/dts/sh73a0-kzm9g-reference.dts |   86 +++++++++++++++++++++++
 arch/arm/mach-shmobile/Kconfig               |    2 +
 arch/arm/mach-shmobile/clock-sh73a0.c        |   95 +++++++++++++++++++++++++-
 arch/arm/mach-shmobile/setup-sh73a0.c        |    5 ++
 4 files changed, 186 insertions(+), 2 deletions(-)

-- 
1.7.2.5

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/


From g.liakhovetski at gmx.de  Fri Apr  5 06:00:36 2013
From: g.liakhovetski at gmx.de (Guennadi Liakhovetski)
Date: Fri,  5 Apr 2013 12:00:36 +0200
Subject: [PATCH v5 1/3] ARM: shmobile: sh73a0: add support for adjusting CPU
 frequency
In-Reply-To: <1365156038-12467-1-git-send-email-g.liakhovetski@gmx.de>
References: <1365156038-12467-1-git-send-email-g.liakhovetski@gmx.de>
Message-ID: <1365156038-12467-2-git-send-email-g.liakhovetski@gmx.de>

On SH73A0 the output of PLL0 is supplied to two dividers, feeding clock to
the CPU core and SGX. Lower CPU frequencies allow the use of lower supply
voltages and thus reduce power consumption.

Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas at gmail.com>
---

v5: not based on MSTP-waiting rework, it needs more work

 arch/arm/mach-shmobile/clock-sh73a0.c |   95 ++++++++++++++++++++++++++++++++-
 1 files changed, 93 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-shmobile/clock-sh73a0.c b/arch/arm/mach-shmobile/clock-sh73a0.c
index 784fbaa..acb9e09 100644
--- a/arch/arm/mach-shmobile/clock-sh73a0.c
+++ b/arch/arm/mach-shmobile/clock-sh73a0.c
@@ -228,6 +228,11 @@ enum { DIV4_I, DIV4_ZG, DIV4_M3, DIV4_B, DIV4_M1, DIV4_M2,
 
 static struct clk div4_clks[DIV4_NR] = {
 	[DIV4_I] = DIV4(FRQCRA, 20, 0xdff, CLK_ENABLE_ON_INIT),
+	/*
+	 * ZG clock is dividing PLL0 frequency to supply SGX. Make sure not to
+	 * exceed maximum frequencies of 201.5MHz for VDD_DVFS=1.175 and
+	 * 239.2MHz for VDD_DVFS=1.315V.
+	 */
 	[DIV4_ZG] = SH_CLK_DIV4(&pll0_clk, FRQCRA, 16, 0xd7f, CLK_ENABLE_ON_INIT),
 	[DIV4_M3] = DIV4(FRQCRA, 12, 0x1dff, CLK_ENABLE_ON_INIT),
 	[DIV4_B] = DIV4(FRQCRA, 8, 0xdff, CLK_ENABLE_ON_INIT),
@@ -252,6 +257,85 @@ static struct clk twd_clk = {
 	.ops = &twd_clk_ops,
 };
 
+static int (*div4_set_rate)(struct clk *clk, unsigned long rate);
+static unsigned long (*div4_recalc)(struct clk *clk);
+static long (*div4_round_rate)(struct clk *clk, unsigned long rate);
+
+static int zclk_set_rate(struct clk *clk, unsigned long rate)
+{
+	int ret;
+
+	if (!clk->parent || !__clk_get(clk->parent))
+		return -ENODEV;
+
+	if (readl(FRQCRB) & (1 << 31))
+		return -EBUSY;
+
+	if (rate == clk_get_rate(clk->parent)) {
+		/* 1:1 - switch off divider */
+		__raw_writel(__raw_readl(FRQCRB) & ~(1 << 28), FRQCRB);
+		/* nullify the divider to prepare for the next time */
+		ret = div4_set_rate(clk, rate / 2);
+		if (!ret)
+			ret = frqcr_kick();
+		if (ret > 0)
+			ret = 0;
+	} else {
+		/* Enable the divider */
+		__raw_writel(__raw_readl(FRQCRB) | (1 << 28), FRQCRB);
+
+		ret = frqcr_kick();
+		if (ret >= 0)
+			/*
+			 * set the divider - call the DIV4 method, it will kick
+			 * FRQCRB too
+			 */
+			ret = div4_set_rate(clk, rate);
+		if (ret < 0)
+			goto esetrate;
+	}
+
+esetrate:
+	__clk_put(clk->parent);
+	return ret;
+}
+
+static long zclk_round_rate(struct clk *clk, unsigned long rate)
+{
+	unsigned long div_freq = div4_round_rate(clk, rate),
+		parent_freq = clk_get_rate(clk->parent);
+
+	if (rate > div_freq && abs(parent_freq - rate) < rate - div_freq)
+		return parent_freq;
+
+	return div_freq;
+}
+
+static unsigned long zclk_recalc(struct clk *clk)
+{
+	/*
+	 * Must recalculate frequencies in case PLL0 has been changed, even if
+	 * the divisor is unused ATM!
+	 */
+	unsigned long div_freq = div4_recalc(clk);
+
+	if (__raw_readl(FRQCRB) & (1 << 28))
+		return div_freq;
+
+	return clk_get_rate(clk->parent);
+}
+
+static void zclk_extend(void)
+{
+	/* We extend the DIV4 clock with a 1:1 pass-through case */
+	div4_set_rate = div4_clks[DIV4_Z].ops->set_rate;
+	div4_round_rate = div4_clks[DIV4_Z].ops->round_rate;
+	div4_recalc = div4_clks[DIV4_Z].ops->recalc;
+	div4_clks[DIV4_Z].ops->set_rate = zclk_set_rate;
+	div4_clks[DIV4_Z].ops->round_rate = zclk_round_rate;
+	div4_clks[DIV4_Z].ops->recalc = zclk_recalc;
+}
+
 enum { DIV6_VCK1, DIV6_VCK2, DIV6_VCK3, DIV6_ZB1,
 	DIV6_FLCTL, DIV6_SDHI0, DIV6_SDHI1, DIV6_SDHI2,
 	DIV6_FSIA, DIV6_FSIB, DIV6_SUB,
@@ -450,7 +534,7 @@ static struct clk *late_main_clks[] = {
 };
 
 enum { MSTP001,
-	MSTP129, MSTP128, MSTP127, MSTP126, MSTP125, MSTP118, MSTP116, MSTP100,
+	MSTP129, MSTP128, MSTP127, MSTP126, MSTP125, MSTP118, MSTP116, MSTP112, MSTP100,
 	MSTP219, MSTP218, MSTP217,
 	MSTP207, MSTP206, MSTP204, MSTP203, MSTP202, MSTP201, MSTP200,
 	MSTP331, MSTP329, MSTP328, MSTP325, MSTP323, MSTP322,
@@ -471,6 +555,7 @@ static struct clk mstp_clks[MSTP_NR] = {
 	[MSTP125] = MSTP(&div6_clks[DIV6_SUB], SMSTPCR1, 25, 0), /* TMU0 */
 	[MSTP118] = MSTP(&div4_clks[DIV4_B], SMSTPCR1, 18, 0), /* DSITX0 */
 	[MSTP116] = MSTP(&div4_clks[DIV4_HP], SMSTPCR1, 16, 0), /* IIC0 */
+	[MSTP112] = MSTP(&div4_clks[DIV4_ZG], SMSTPCR1, 12, 0), /* SGX */
 	[MSTP100] = MSTP(&div4_clks[DIV4_B], SMSTPCR1, 0, 0), /* LCDC0 */
 	[MSTP219] = MSTP(&div6_clks[DIV6_SUB], SMSTPCR2, 19, 0), /* SCIFA7 */
 	[MSTP218] = MSTP(&div4_clks[DIV4_HP], SMSTPCR2, 18, 0), /* SY-DMAC */
@@ -513,6 +598,9 @@ static struct clk_lookup lookups[] = {
 	CLKDEV_CON_ID("r_clk", &r_clk),
 	CLKDEV_DEV_ID("smp_twd", &twd_clk), /* smp_twd */
 
+	/* DIV4 clocks */
+	CLKDEV_DEV_ID("cpufreq-cpu0", &div4_clks[DIV4_Z]),
+
 	/* DIV6 clocks */
 	CLKDEV_CON_ID("vck1_clk", &div6_clks[DIV6_VCK1]),
 	CLKDEV_CON_ID("vck2_clk", &div6_clks[DIV6_VCK2]),
@@ -604,8 +692,11 @@ void __init sh73a0_clock_init(void)
 	for (k = 0; !ret && (k < ARRAY_SIZE(main_clks)); k++)
 		ret = clk_register(main_clks[k]);
 
-	if (!ret)
+	if (!ret) {
 		ret = sh_clk_div4_register(div4_clks, DIV4_NR, &div4_table);
+		if (!ret)
+			zclk_extend();
+	}
 
 	if (!ret)
 		ret = sh_clk_div6_reparent_register(div6_clks, DIV6_NR);
-- 
1.7.2.5



From g.liakhovetski at gmx.de  Fri Apr  5 06:00:38 2013
From: g.liakhovetski at gmx.de (Guennadi Liakhovetski)
Date: Fri,  5 Apr 2013 12:00:38 +0200
Subject: [PATCH v5 3/3] ARM: shmobile: sh73a0: add CPUFreq support
In-Reply-To: <1365156038-12467-1-git-send-email-g.liakhovetski@gmx.de>
References: <1365156038-12467-1-git-send-email-g.liakhovetski@gmx.de>
Message-ID: <1365156038-12467-4-git-send-email-g.liakhovetski@gmx.de>

This patch enables the use of the generic cpufreq-cpu0 driver on sh73a0.
Providing a regulator, a list of OPPs in DT, combined with a virtual
cpufreq-cpu0 platform device and a clock, attached to it is everything,
the cpufreq-cpu0 driver needs. The first sh73a0 platform, implementing
such CPUFreq support is kzm9g-reference.

Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas at gmail.com>
---

v5: remove sh73a0-kzm9g-reference.dts hunk, it's now merged into patch 2/3

 arch/arm/mach-shmobile/Kconfig        |    2 ++
 arch/arm/mach-shmobile/setup-sh73a0.c |    5 +++++
 2 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index 1a517e2..4ac5bf9 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -177,6 +177,8 @@ config MACH_KZM9G
 config MACH_KZM9G_REFERENCE
 	bool "KZM-A9-GT board - Reference Device Tree Implementation"
 	depends on ARCH_SH73A0
+	select ARCH_HAS_CPUFREQ
+	select ARCH_HAS_OPP
 	select ARCH_REQUIRE_GPIOLIB
 	select REGULATOR_FIXED_VOLTAGE if REGULATOR
 	select SND_SOC_AK4642 if SND_SIMPLE_CARD
diff --git a/arch/arm/mach-shmobile/setup-sh73a0.c b/arch/arm/mach-shmobile/setup-sh73a0.c
index d10ded0..9a522f9 100644
--- a/arch/arm/mach-shmobile/setup-sh73a0.c
+++ b/arch/arm/mach-shmobile/setup-sh73a0.c
@@ -1003,6 +1003,8 @@ static const struct of_dev_auxdata sh73a0_auxdata_lookup[] __initconst = {
 
 void __init sh73a0_add_standard_devices_dt(void)
 {
+	struct platform_device_info devinfo = { .name = "cpufreq-cpu0", .id = -1, };
+
 	/* clocks are setup late during boot in the case of DT */
 	sh73a0_clock_init();
 
@@ -1010,6 +1012,9 @@ void __init sh73a0_add_standard_devices_dt(void)
 			     ARRAY_SIZE(sh73a0_devices_dt));
 	of_platform_populate(NULL, of_default_bus_match_table,
 			     sh73a0_auxdata_lookup, NULL);
+
+	/* Instantiate cpufreq-cpu0 */
+	platform_device_register_full(&devinfo);
 }
 
 static const char *sh73a0_boards_compat_dt[] __initdata = {
-- 
1.7.2.5



From marc.zyngier at arm.com  Fri Apr  5 06:04:05 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Fri, 05 Apr 2013 11:04:05 +0100
Subject: [PATCH] ARM: arch_timer: Silence debug preempt warnings
In-Reply-To: <515E5CFC.4090900@codeaurora.org>
References: <1364934672-31554-1-git-send-email-sboyd@codeaurora.org>
 <515E5CFC.4090900@codeaurora.org>
Message-ID: <515EA195.4010307@arm.com>

Hi Stephen,

On 05/04/13 06:11, Stephen Boyd wrote:
> On 4/2/2013 1:31 PM, Stephen Boyd wrote:
>> Hot-plugging with CONFIG_DEBUG_PREEMPT=y on a device with arm
>> architected timers causes a slew of "using smp_processor_id() in
>> preemptible" warnings:
>>
>>   BUG: using smp_processor_id() in preemptible [00000000] code: sh/111
>>   caller is arch_timer_cpu_notify+0x14/0xc8
>>
>> This happens because sometimes the cpu notifier, arch_timer_cpu_notify(),
>> is called in preemptible context but we use this_cpu_ptr()
>> to retrieve the clockevent unconditionally. We're only going to
>> actually use the pointer in non-preemptible context though,
>> so use __this_cpu_ptr() instead to avoid the preemptible checks
>> and silence the warning.
>>
>> Cc: Mark Rutland <mark.rutland at arm.com>
>> Cc: Marc Zyngier <Marc.Zyngier at arm.com>
>> Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
>> ---
> 
> Anyone else seeing this one?

Haven't seen this one occurring yet. I suspect my compiler is optimizing
the code in ways that prevent the breakage from being seen.

> 
>>  drivers/clocksource/arm_arch_timer.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
>> index d7ad425..5928c29 100644
>> --- a/drivers/clocksource/arm_arch_timer.c
>> +++ b/drivers/clocksource/arm_arch_timer.c
>> @@ -248,7 +248,7 @@ static void __cpuinit arch_timer_stop(struct clock_event_device *clk)
>>  static int __cpuinit arch_timer_cpu_notify(struct notifier_block *self,
>>  					   unsigned long action, void *hcpu)
>>  {
>> -	struct clock_event_device *evt = this_cpu_ptr(arch_timer_evt);
>> +	struct clock_event_device *evt = __this_cpu_ptr(arch_timer_evt);
>>  
>>  	switch (action & ~CPU_TASKS_FROZEN) {
>>  	case CPU_STARTING:

I'm afraid this would hide bugs if we start using the notifier for other
purposes than exclusivity non-preemptible contexts.

How about moving the this_cpu_ptr() down to the cases themselves, maybe
with a nice comment?

Cheers,

	M.
-- 
Jazz is not dead. It just smells funny...



From laurent.pinchart at ideasonboard.com  Fri Apr  5 06:07:23 2013
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Fri, 05 Apr 2013 12:07:23 +0200
Subject: [RFC/PATCH 0/7] ARCH: shmobile: defconfig consolidation
In-Reply-To: <20130405004931.GR29203@verge.net.au>
References: <1365046193-19369-1-git-send-email-horms+renesas@verge.net.au>
 <2243996.H0VQ4NfsDe@avalon> <20130405004931.GR29203@verge.net.au>
Message-ID: <3815682.nYPUHoztul@avalon>

Hi Simon,

On Friday 05 April 2013 09:49:31 Simon Horman wrote:
> On Fri, Apr 05, 2013 at 02:37:38AM +0200, Laurent Pinchart wrote:
> > On Friday 05 April 2013 09:30:27 Simon Horman wrote:
> > > On Thu, Apr 04, 2013 at 01:20:44PM +0200, Laurent Pinchart wrote:
> > > > On Thursday 04 April 2013 12:29:46 Simon Horman wrote:
> > > > > Hi,
> > > > > 
> > > > > this is a first pass at consolidating the defconfigs of shmobile.
> > > > > 
> > > > > It covers the mackerel, amradillo800eva and kzm9d boards which meet
> > > > > the following criteria:
> > > > > 
> > > > > * Have the same base memory address (0x40000000).
> > > > 
> > > > Do you know if there's any work being done on getting rid of the base
> > > > memory address as a kernel config option ? It seriously hinders
> > > > cross-SoC kernel testing.
> > > 
> > > As I understand things the main limitation is uImage which uses
> > > the base memory address. There is some talk of creating uImages
> > > at install time rather than build time. Which I believe would
> > > remove most if not all the problem. However, its entirely unclear
> > > to me what such an install process would look like. A new build target?
> > > In tree script? Out of tree script? It seems very undefined to me.
> > > 
> > > Another, arguably better though not backwards compatible, option
> > > is to boot using zImage (or even just Image) which do not rely
> > > on the base address.
> > 
> > Don't we also need to get rid of CONFIG_MEMORY_START ? It's used in
> > headsmp.S and headsmp-scu.S (through PLAT_PHYS_OFFSET).
> 
> Yes, I think so. Sorry for glossing over that.
> 
> I think it should be possible to remove that by evaluating it at runtime
> somehow. But I have not though deeply about this.

It would be really nice if someone could give it a try :-)

-- 
Regards,

Laurent Pinchart



From pebolle at tiscali.nl  Fri Apr  5 06:12:29 2013
From: pebolle at tiscali.nl (Paul Bolle)
Date: Fri, 05 Apr 2013 12:12:29 +0200
Subject: [PATCH] omap2+: Remove useless Makefile line
Message-ID: <1365156749.1830.60.camel@x61.thuisdomein>

Commit f41caddbe73f52a42f529d668ce47b4d693fd2c0 ("omap2+: Use Kconfig
symbol in Makefile instead of obj-y") reorganized this Makefile. But,
for some reason, it also added references to CONFIG_MACH_ENCORE and
board-omap3encore.o. But there's no Kconfig symbol MACH_ENCORE and
there's no file board-omap3encore.c. This line can safely be removed.

Signed-off-by: Paul Bolle <pebolle at tiscali.nl>
---
 arch/arm/mach-omap2/Makefile | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index b068b7f..3d0697c 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -229,7 +229,6 @@ obj-$(CONFIG_MACH_DEVKIT8000)     	+= board-devkit8000.o
 obj-$(CONFIG_MACH_OMAP_LDP)		+= board-ldp.o
 obj-$(CONFIG_MACH_OMAP3530_LV_SOM)      += board-omap3logic.o
 obj-$(CONFIG_MACH_OMAP3_TORPEDO)        += board-omap3logic.o
-obj-$(CONFIG_MACH_ENCORE)		+= board-omap3encore.o
 obj-$(CONFIG_MACH_OVERO)		+= board-overo.o
 obj-$(CONFIG_MACH_OMAP3EVM)		+= board-omap3evm.o
 obj-$(CONFIG_MACH_OMAP3_PANDORA)	+= board-omap3pandora.o
-- 
1.7.11.7





From pebolle at tiscali.nl  Fri Apr  5 06:16:32 2013
From: pebolle at tiscali.nl (Paul Bolle)
Date: Fri, 05 Apr 2013 12:16:32 +0200
Subject: [PATCH] omap2+: Remove useless Makefile line
Message-ID: <1365156992.1830.63.camel@x61.thuisdomein>

Merge commit 952414505f55afe5cd6dc004765076aa22b3ed7e ("Merge branch
'next/cleanup' of git://git.linaro.org/people/arnd/arm-soc") added
references to CONFIG_MACH_PCM049 and board-omap4pcm049.o to this
Makefile. But there's no Kconfig symbol MACH_PCM049 and there's no file
board-omap4pcm049.c. This line can safely be removed.

Signed-off-by: Paul Bolle <pebolle at tiscali.nl>
---
Note that MACH_PCM049 was removed from mach-types in v3.5.

 arch/arm/mach-omap2/Makefile | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 3d0697c..62bb352 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -254,8 +254,6 @@ obj-$(CONFIG_MACH_TOUCHBOOK)		+= board-omap3touchbook.o
 obj-$(CONFIG_MACH_OMAP_4430SDP)		+= board-4430sdp.o
 obj-$(CONFIG_MACH_OMAP4_PANDA)		+= board-omap4panda.o
 
-obj-$(CONFIG_MACH_PCM049)		+= board-omap4pcm049.o
-
 obj-$(CONFIG_MACH_OMAP3517EVM)		+= board-am3517evm.o
 
 obj-$(CONFIG_MACH_CRANEBOARD)		+= board-am3517crane.o
-- 
1.7.11.7



From mpa at pengutronix.de  Fri Apr  5 06:31:14 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Fri,  5 Apr 2013 12:31:14 +0200
Subject: [PATCH v3 0/2] video: imxfb DT support
Message-ID: <1365157876-1757-1-git-send-email-mpa@pengutronix.de>

Hi,

This series adds DT support for imxfb. Changes in v3 are
described in the notes of patch 2.

Regards,

Markus



From mpa at pengutronix.de  Fri Apr  5 06:31:16 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Fri,  5 Apr 2013 12:31:16 +0200
Subject: [PATCH v3 2/2] video: imxfb: Add DT support
In-Reply-To: <1365157876-1757-1-git-send-email-mpa@pengutronix.de>
References: <1365157876-1757-1-git-send-email-mpa@pengutronix.de>
Message-ID: <1365157876-1757-3-git-send-email-mpa@pengutronix.de>

Add devicetree support for imx framebuffer driver. It uses the generic
display bindings and helper functions.

Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
Cc: Fabio Estevam <festevam at gmail.com>
Cc: Mark Rutland <mark.rutland at arm.com>
---
 .../devicetree/bindings/video/fsl,imx-fb.txt       |  49 ++++++
 drivers/video/imxfb.c                              | 192 +++++++++++++++++----
 2 files changed, 207 insertions(+), 34 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/video/fsl,imx-fb.txt

diff --git a/Documentation/devicetree/bindings/video/fsl,imx-fb.txt b/Documentation/devicetree/bindings/video/fsl,imx-fb.txt
new file mode 100644
index 0000000..bde9c77
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/fsl,imx-fb.txt
@@ -0,0 +1,49 @@
+Freescale imx21 Framebuffer
+
+This framebuffer driver supports devices imx1, imx21, imx25, and imx27.
+
+Required properties:
+- compatible : "fsl,<chip>-fb", chip should be imx1 or imx21
+- reg : Should contain 1 register ranges(address and length)
+- interrupts : One interrupt of the fb dev
+
+Required nodes:
+- display: Phandle to a display node as described in
+	Documentation/devicetree/bindings/video/display-timing.txt
+	Additional, the display node has to define properties:
+	- fsl,bpp: Bits per pixel
+	- fsl,pcr: LCDC PCR value
+
+Optional properties:
+- dmacr-eukrea: Should be set for eukrea boards.
+
+Example:
+
+	imxfb: fb at 10021000 {
+		compatible = "fsl,imx27-fb", "fsl,imx21-fb";
+		interrupts = <61>;
+		reg = <0x10021000 0x1000>;
+		display = <&display0>;
+	};
+
+	...
+
+	display0: display0 {
+		model = "Primeview-PD050VL1";
+		native-mode = <&timing_disp0>;
+		fsl,bpp = <16>;		/* non-standard but required */
+		fsl,pcr = <0xf0c88080>;	/* non-standard but required */
+		display-timings {
+			timing_disp0: 640x480 {
+				hactive = <640>;
+				vactive = <480>;
+				hback-porch = <112>;
+				hfront-porch = <36>;
+				hsync-len = <32>;
+				vback-porch = <33>;
+				vfront-porch = <33>;
+				vsync-len = <2>;
+				clock-frequency = <25000000>;
+			};
+		};
+	};
diff --git a/drivers/video/imxfb.c b/drivers/video/imxfb.c
index ef2b587..5a9bc598 100644
--- a/drivers/video/imxfb.c
+++ b/drivers/video/imxfb.c
@@ -32,6 +32,12 @@
 #include <linux/io.h>
 #include <linux/math64.h>
 #include <linux/uaccess.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+
+#include <video/of_display_timing.h>
+#include <video/of_videomode.h>
+#include <video/videomode.h>
 
 #include <linux/platform_data/video-imxfb.h>
 
@@ -117,10 +123,13 @@
 #define LGWCR_GWAV(alpha)	(((alpha) & 0xff) << 24)
 #define LGWCR_GWE	(1 << 22)
 
+#define IMXFB_LSCR1_DEFAULT 0x00120300
+#define IMXFB_DMACR_DEFAULT 0x00020010
+#define IMXFB_DMACR_EUKREA_DEFAULT 0x00040060
+
 /* Used fb-mode. Can be set on kernel command line, therefore file-static. */
 static const char *fb_mode;
 
-
 /*
  * These are the bitfields for each
  * display depth that we support.
@@ -192,6 +201,19 @@ static struct platform_device_id imxfb_devtype[] = {
 };
 MODULE_DEVICE_TABLE(platform, imxfb_devtype);
 
+static struct of_device_id imxfb_of_dev_id[] = {
+	{
+		.compatible = "fsl,imx1-fb",
+		.data = &imxfb_devtype[IMX1_FB],
+	}, {
+		.compatible = "fsl,imx21-fb",
+		.data = &imxfb_devtype[IMX21_FB],
+	}, {
+		/* sentinel */
+	}
+};
+MODULE_DEVICE_TABLE(of, imxfb_of_dev_id);
+
 static inline int is_imx1_fb(struct imxfb_info *fbi)
 {
 	return fbi->devtype == IMX1_FB;
@@ -324,6 +346,9 @@ static const struct imx_fb_videomode *imxfb_find_mode(struct imxfb_info *fbi)
 	struct imx_fb_videomode *m;
 	int i;
 
+	if (!fb_mode)
+		return &fbi->mode[0];
+
 	for (i = 0, m = &fbi->mode[0]; i < fbi->num_modes; i++, m++) {
 		if (!strcmp(m->mode.name, fb_mode))
 			return m;
@@ -479,6 +504,9 @@ static int imxfb_bl_update_status(struct backlight_device *bl)
 	struct imxfb_info *fbi = bl_get_data(bl);
 	int brightness = bl->props.brightness;
 
+	if (!fbi->pwmr)
+		return 0;
+
 	if (bl->props.power != FB_BLANK_UNBLANK)
 		brightness = 0;
 	if (bl->props.fb_blank != FB_BLANK_UNBLANK)
@@ -719,7 +747,8 @@ static int imxfb_activate_var(struct fb_var_screeninfo *var, struct fb_info *inf
 
 	writel(fbi->pcr, fbi->regs + LCDC_PCR);
 #ifndef PWMR_BACKLIGHT_AVAILABLE
-	writel(fbi->pwmr, fbi->regs + LCDC_PWMR);
+	if (fbi->pwmr)
+		writel(fbi->pwmr, fbi->regs + LCDC_PWMR);
 #endif
 	writel(fbi->lscr1, fbi->regs + LCDC_LSCR1);
 	writel(fbi->dmacr, fbi->regs + LCDC_DMACR);
@@ -758,13 +787,12 @@ static int imxfb_resume(struct platform_device *dev)
 #define imxfb_resume	NULL
 #endif
 
-static int __init imxfb_init_fbinfo(struct platform_device *pdev)
+static int imxfb_init_fbinfo(struct platform_device *pdev)
 {
 	struct imx_fb_platform_data *pdata = pdev->dev.platform_data;
 	struct fb_info *info = dev_get_drvdata(&pdev->dev);
 	struct imxfb_info *fbi = info->par;
-	struct imx_fb_videomode *m;
-	int i;
+	struct device_node *np;
 
 	pr_debug("%s\n",__func__);
 
@@ -795,41 +823,96 @@ static int __init imxfb_init_fbinfo(struct platform_device *pdev)
 	info->fbops			= &imxfb_ops;
 	info->flags			= FBINFO_FLAG_DEFAULT |
 					  FBINFO_READS_FAST;
-	info->var.grayscale		= pdata->cmap_greyscale;
-	fbi->cmap_inverse		= pdata->cmap_inverse;
-	fbi->cmap_static		= pdata->cmap_static;
-	fbi->lscr1			= pdata->lscr1;
-	fbi->dmacr			= pdata->dmacr;
-	fbi->pwmr			= pdata->pwmr;
-	fbi->lcd_power			= pdata->lcd_power;
-	fbi->backlight_power		= pdata->backlight_power;
-
-	for (i = 0, m = &pdata->mode[0]; i < pdata->num_modes; i++, m++)
-		info->fix.smem_len = max_t(size_t, info->fix.smem_len,
-				m->mode.xres * m->mode.yres * m->bpp / 8);
+	if (pdata) {
+		info->var.grayscale		= pdata->cmap_greyscale;
+		fbi->cmap_inverse		= pdata->cmap_inverse;
+		fbi->cmap_static		= pdata->cmap_static;
+		fbi->lscr1			= pdata->lscr1;
+		fbi->dmacr			= pdata->dmacr;
+		fbi->pwmr			= pdata->pwmr;
+		fbi->lcd_power			= pdata->lcd_power;
+		fbi->backlight_power		= pdata->backlight_power;
+	} else {
+		np = pdev->dev.of_node;
+		info->var.grayscale = of_property_read_bool(np,
+						"cmap-greyscale");
+		fbi->cmap_inverse = of_property_read_bool(np, "cmap-inverse");
+		fbi->cmap_static = of_property_read_bool(np, "cmap-static");
+
+		fbi->lscr1 = IMXFB_LSCR1_DEFAULT;
+		if (of_property_read_bool(np, "dmacr-eukrea"))
+			fbi->dmacr = IMXFB_DMACR_EUKREA_DEFAULT;
+		else
+			fbi->dmacr = IMXFB_DMACR_DEFAULT;
+
+		/* These two function pointers could be used by some specific
+		 * platforms. */
+		fbi->lcd_power = NULL;
+		fbi->backlight_power = NULL;
+	}
+
+	return 0;
+}
+
+static int imxfb_of_read_mode(struct device *dev, struct device_node *np,
+		struct imx_fb_videomode *imxfb_mode)
+{
+	int ret;
+	struct fb_videomode *of_mode = &imxfb_mode->mode;
+	u32 bpp;
+	u32 pcr;
+
+	ret = of_property_read_string(np, "model", &of_mode->name);
+	if (ret)
+		of_mode->name = NULL;
+
+	ret = of_get_fb_videomode(np, of_mode, OF_USE_NATIVE_MODE);
+	if (ret) {
+		dev_err(dev, "Failed to get videomode from DT\n");
+		return ret;
+	}
+
+	ret = of_property_read_u32(np, "fsl,bpp", &bpp);
+	ret |= of_property_read_u32(np, "fsl,pcr", &pcr);
+
+	if (ret) {
+		dev_err(dev, "Failed to read bpp and pcr from DT\n");
+		return -EINVAL;
+	}
+
+	if (bpp < 1 || bpp > 255) {
+		dev_err(dev, "Bits per pixel have to be between 1 and 255\n");
+		return -EINVAL;
+	}
+
+	imxfb_mode->bpp = bpp;
+	imxfb_mode->pcr = pcr;
 
 	return 0;
 }
 
-static int __init imxfb_probe(struct platform_device *pdev)
+static int imxfb_probe(struct platform_device *pdev)
 {
 	struct imxfb_info *fbi;
 	struct fb_info *info;
 	struct imx_fb_platform_data *pdata;
 	struct resource *res;
+	struct imx_fb_videomode *m;
+	const struct of_device_id *of_id;
 	int ret, i;
+	int bytes_per_pixel;
 
 	dev_info(&pdev->dev, "i.MX Framebuffer driver\n");
 
+	of_id = of_match_device(imxfb_of_dev_id, &pdev->dev);
+	if (of_id)
+		pdev->id_entry = of_id->data;
+
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 	if (!res)
 		return -ENODEV;
 
 	pdata = pdev->dev.platform_data;
-	if (!pdata) {
-		dev_err(&pdev->dev,"No platform_data available\n");
-		return -ENOMEM;
-	}
 
 	info = framebuffer_alloc(sizeof(struct imxfb_info), &pdev->dev);
 	if (!info)
@@ -837,15 +920,55 @@ static int __init imxfb_probe(struct platform_device *pdev)
 
 	fbi = info->par;
 
-	if (!fb_mode)
-		fb_mode = pdata->mode[0].mode.name;
-
 	platform_set_drvdata(pdev, info);
 
 	ret = imxfb_init_fbinfo(pdev);
 	if (ret < 0)
 		goto failed_init;
 
+	if (pdata) {
+		if (!fb_mode)
+			fb_mode = pdata->mode[0].mode.name;
+
+		fbi->mode = pdata->mode;
+		fbi->num_modes = pdata->num_modes;
+	} else {
+		struct device_node *display_np;
+		fb_mode = NULL;
+
+		display_np = of_parse_phandle(pdev->dev.of_node, "display", 0);
+		if (!display_np) {
+			dev_err(&pdev->dev, "No display defined in devicetree\n");
+			ret = -EINVAL;
+			goto failed_of_parse;
+		}
+
+		/*
+		 * imxfb does not support more modes, we choose only the native
+		 * mode.
+		 */
+		fbi->num_modes = 1;
+
+		fbi->mode = devm_kzalloc(&pdev->dev,
+				sizeof(struct imx_fb_videomode), GFP_KERNEL);
+		if (!fbi->mode) {
+			ret = -ENOMEM;
+			goto failed_of_parse;
+		}
+
+		ret = imxfb_of_read_mode(&pdev->dev, display_np, fbi->mode);
+		if (ret)
+			goto failed_of_parse;
+	}
+
+	/* Calculate maximum bytes used per pixel. In most cases this should
+	 * be the same as m->bpp/8 */
+	m = &fbi->mode[0];
+	bytes_per_pixel = (m->bpp + 7) / 8;
+	for (i = 0; i < fbi->num_modes; i++, m++)
+		info->fix.smem_len = max_t(size_t, info->fix.smem_len,
+				m->mode.xres * m->mode.yres * bytes_per_pixel);
+
 	res = request_mem_region(res->start, resource_size(res),
 				DRIVER_NAME);
 	if (!res) {
@@ -878,7 +1001,8 @@ static int __init imxfb_probe(struct platform_device *pdev)
 		goto failed_ioremap;
 	}
 
-	if (!pdata->fixed_screen_cpu) {
+	/* Seems not being used by anyone, so no support for oftree */
+	if (!pdata || !pdata->fixed_screen_cpu) {
 		fbi->map_size = PAGE_ALIGN(info->fix.smem_len);
 		fbi->map_cpu = dma_alloc_writecombine(&pdev->dev,
 				fbi->map_size, &fbi->map_dma, GFP_KERNEL);
@@ -903,18 +1027,16 @@ static int __init imxfb_probe(struct platform_device *pdev)
 		info->fix.smem_start = fbi->screen_dma;
 	}
 
-	if (pdata->init) {
+	if (pdata && pdata->init) {
 		ret = pdata->init(fbi->pdev);
 		if (ret)
 			goto failed_platform_init;
 	}
 
-	fbi->mode = pdata->mode;
-	fbi->num_modes = pdata->num_modes;
 
 	INIT_LIST_HEAD(&info->modelist);
-	for (i = 0; i < pdata->num_modes; i++)
-		fb_add_videomode(&pdata->mode[i].mode, &info->modelist);
+	for (i = 0; i < fbi->num_modes; i++)
+		fb_add_videomode(&fbi->mode[i].mode, &info->modelist);
 
 	/*
 	 * This makes sure that our colour bitfield
@@ -944,10 +1066,10 @@ static int __init imxfb_probe(struct platform_device *pdev)
 failed_register:
 	fb_dealloc_cmap(&info->cmap);
 failed_cmap:
-	if (pdata->exit)
+	if (pdata && pdata->exit)
 		pdata->exit(fbi->pdev);
 failed_platform_init:
-	if (!pdata->fixed_screen_cpu)
+	if (pdata && !pdata->fixed_screen_cpu)
 		dma_free_writecombine(&pdev->dev,fbi->map_size,fbi->map_cpu,
 			fbi->map_dma);
 failed_map:
@@ -956,6 +1078,7 @@ failed_ioremap:
 failed_getclock:
 	release_mem_region(res->start, resource_size(res));
 failed_req:
+failed_of_parse:
 	kfree(info->pseudo_palette);
 failed_init:
 	platform_set_drvdata(pdev, NULL);
@@ -980,7 +1103,7 @@ static int imxfb_remove(struct platform_device *pdev)
 	unregister_framebuffer(info);
 
 	pdata = pdev->dev.platform_data;
-	if (pdata->exit)
+	if (pdata && pdata->exit)
 		pdata->exit(fbi->pdev);
 
 	fb_dealloc_cmap(&info->cmap);
@@ -1009,6 +1132,7 @@ static struct platform_driver imxfb_driver = {
 	.shutdown	= imxfb_shutdown,
 	.driver		= {
 		.name	= DRIVER_NAME,
+		.of_match_table = imxfb_of_dev_id,
 	},
 	.id_table	= imxfb_devtype,
 };
-- 
1.8.1.5



From mpa at pengutronix.de  Fri Apr  5 06:31:15 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Fri,  5 Apr 2013 12:31:15 +0200
Subject: [PATCH v3 1/2] imxfb: Set alpha value of the framebuffer
In-Reply-To: <1365157876-1757-1-git-send-email-mpa@pengutronix.de>
References: <1365157876-1757-1-git-send-email-mpa@pengutronix.de>
Message-ID: <1365157876-1757-2-git-send-email-mpa@pengutronix.de>

From: Christian Hemp <c.hemp at phytec.de>

Based on Sascha Hauer's patch i.MX27 clock: Do not disable lcd clocks during
startup.
This patch gives a interface to chance the alphavalue of the framebuffer.

Signed-off-by: Christian Hemp <c.hemp at phytec.de>

rebased to 3.7
Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
---
 drivers/video/imxfb.c                     | 35 +++++++++++++++++++++++++++++++
 include/linux/platform_data/video-imxfb.h |  3 +++
 2 files changed, 38 insertions(+)

diff --git a/drivers/video/imxfb.c b/drivers/video/imxfb.c
index 0abf2bf..ef2b587 100644
--- a/drivers/video/imxfb.c
+++ b/drivers/video/imxfb.c
@@ -31,6 +31,7 @@
 #include <linux/dma-mapping.h>
 #include <linux/io.h>
 #include <linux/math64.h>
+#include <linux/uaccess.h>
 
 #include <linux/platform_data/video-imxfb.h>
 
@@ -112,6 +113,10 @@
 #define LCDISR_EOF	(1<<1)
 #define LCDISR_BOF	(1<<0)
 
+#define LCDC_LGWCR	0x64
+#define LGWCR_GWAV(alpha)	(((alpha) & 0xff) << 24)
+#define LGWCR_GWE	(1 << 22)
+
 /* Used fb-mode. Can be set on kernel command line, therefore file-static. */
 static const char *fb_mode;
 
@@ -610,6 +615,35 @@ static int imxfb_blank(int blank, struct fb_info *info)
 	return 0;
 }
 
+static int imxfb_ioctl(struct fb_info *info, unsigned int cmd,
+			unsigned long arg)
+{
+	struct imxfb_info *fbi = info->par;
+	int alpha, ret = 0;
+	unsigned int tmp;
+
+	switch (cmd) {
+	case IMXFB_ALPHA:
+		if (get_user(alpha, (int __user *)arg)) {
+			ret = -EFAULT;
+		} else {
+			tmp = readl(fbi->regs + LCDC_LGWCR);
+			tmp &= ~LGWCR_GWAV(0xff);
+			tmp |= LGWCR_GWAV(alpha);
+			if (!alpha)
+				tmp &= ~LGWCR_GWE;
+			else
+				tmp |= LGWCR_GWE;
+			writel(tmp , fbi->regs + LCDC_LGWCR);
+		}
+		break;
+	default:
+		ret = -EINVAL;
+	}
+
+	return ret;
+}
+
 static struct fb_ops imxfb_ops = {
 	.owner		= THIS_MODULE,
 	.fb_check_var	= imxfb_check_var,
@@ -619,6 +653,7 @@ static struct fb_ops imxfb_ops = {
 	.fb_copyarea	= cfb_copyarea,
 	.fb_imageblit	= cfb_imageblit,
 	.fb_blank	= imxfb_blank,
+	.fb_ioctl	= imxfb_ioctl,
 };
 
 /*
diff --git a/include/linux/platform_data/video-imxfb.h b/include/linux/platform_data/video-imxfb.h
index 9de8f06..ce3875f 100644
--- a/include/linux/platform_data/video-imxfb.h
+++ b/include/linux/platform_data/video-imxfb.h
@@ -51,6 +51,9 @@
 #define DMACR_HM(x)	(((x) & 0xf) << 16)
 #define DMACR_TM(x)	((x) & 0xf)
 
+#define IMXFB_IOW(num, dtype)	_IOW('I', num, dtype)
+#define IMXFB_ALPHA		IMXFB_IOW(31, int)
+
 struct imx_fb_videomode {
 	struct fb_videomode mode;
 	u32 pcr;
-- 
1.8.1.5



From t.figa at samsung.com  Fri Apr  5 06:33:12 2013
From: t.figa at samsung.com (Tomasz Figa)
Date: Fri, 05 Apr 2013 12:33:12 +0200
Subject: [PATCH v4 00/14] ARM: samsung-time: Prepare for multiplatform
 support
In-Reply-To: <201304050115.03879.heiko@sntech.de>
References: <1365093431-30621-1-git-send-email-t.figa@samsung.com>
 <201304050115.03879.heiko@sntech.de>
Message-ID: <2744467.M5ElrZXicK@amdc1227>

Hi Heiko,

On Friday 05 of April 2013 01:15:02 Heiko St?bner wrote:
> Am Donnerstag, 4. April 2013, 18:36:57 schrieb Tomasz Figa:
> > This series is an attempt to make the samsung-time clocksource driver
> > ready
> > for multiplatform kernels. It moves the driver to drivers/clocksource,
> > cleans it up from uses of static platform-specific definitions, simplifies
> > timer interrupt handling and adds Device Tree support.
> > 
> > Only samsung-time driver is reworked to use the master driver at this
> > time,
> > since the PWM driver can be already considered broken at the moment and
> > needs separate series of several patches to fix and clean it up, which
> > I am already working on.
> > 
> > Tested on Universal C210 board with Device Tree. Not tested without
> > Device Tree, since it has been already broken before this series.
> > Compile tested for other related SoCs.
> 
> Looks nice.
> 
> On a non-DT S3C2416 board:
> Tested-by: Heiko Stuebner <heiko at sntech.de>

Thanks for testing.

> And just so I don't search myself silly, am I right in thinking that the
> driver does not use the generic clocksource registration yet and dt machines
> must still use samsung_timer_init at this point?

Yes. Because of the build failures it caused recently I have decided not to 
use it yet. It can be added with a small patch later, though.

Best regards,
-- 
Tomasz Figa
Samsung Poland R&D Center
SW Solution Development, Kernel and System Framework



From rogerq at ti.com  Fri Apr  5 06:39:31 2013
From: rogerq at ti.com (Roger Quadros)
Date: Fri, 5 Apr 2013 13:39:31 +0300
Subject: [RFC][PATCH 1/2] ARM: OMAP4: clock: Add device tree support for
 AUXCLKs
In-Reply-To: <20130404164137.GH10155@atomide.com>
References: <1363703220-4777-1-git-send-email-rogerq@ti.com>
 <1363703220-4777-2-git-send-email-rogerq@ti.com>
 <20130403234242.GE10155@atomide.com> <515D2D30.3000306@ti.com>
 <20130404164137.GH10155@atomide.com>
Message-ID: <515EA9E3.1010409@ti.com>

On 04/04/2013 07:41 PM, Tony Lindgren wrote:
> * Roger Quadros <rogerq at ti.com> [130404 00:39]:
>> On 04/04/2013 02:42 AM, Tony Lindgren wrote:
>>>> --- a/arch/arm/mach-omap2/cclock44xx_data.c
>>>> +++ b/arch/arm/mach-omap2/cclock44xx_data.c
>>>> @@ -27,6 +27,7 @@
>>>>  #include <linux/clk-private.h>
>>>>  #include <linux/clkdev.h>
>>>>  #include <linux/io.h>
>>>> +#include <linux/of.h>
>>>>  
>>>>  #include "soc.h"
>>>>  #include "iomap.h"
>>>> @@ -1663,6 +1664,40 @@ static struct omap_clk omap44xx_clks[] = {
>>>>  	CLK(NULL,	"cpufreq_ck",	&dpll_mpu_ck,	CK_443X),
>>>>  };
>>>>  
>>>> +static struct clk *scrm_clks[] = {
>>>> +	&auxclk0_ck,
>>>> +	&auxclk1_ck,
>>>> +	&auxclk2_ck,
>>>> +	&auxclk3_ck,
>>>> +	&auxclk4_ck,
>>>> +	&auxclk5_ck,
>>>> +};
>>>
>>> Hmm I don't like the idea of specifying the auxclk both in the
>>> cclock44xx_data.c and in DT..
>>
>> Right, but till we have all clocks moved to DT we only need this
>> approach for general purpose clocks that are not mapped to devices
>> by hwmod.
> 
> For v3.10, let's just make sure that USB works with DT as then
> after v3.10 we can make omap4 DT only and get rid of estimated
> 7K lines of code and data. I guess this is the last piece missing
> for that, or are we also missing something else?

For panda we just need a way to map the auxclk to the USB PHY device
and the relevant dts data to get USB host working with DT.
Beagle USB host should work already with DT without any changes.

> 
> Can't you set up a clock alias for your device so it can find the
> auxclk when requesting it with the dev entry?
> 

which clock is mapped to which PHY device depends on board design
and that cannot be per-determined at one place. This information
needs to come from the board.dts file.

There was an earlier attempt to provide a way of building clock aliases
at runtime from device tree [1], but the current approach is way better

[1]
https://lkml.org/lkml/2013/3/12/241

> For the DT clock driver if needed for v3.10, how about just do a
> minimal drivers/clock/omap/ that uses the standard binding?
> Then that driver can just do clk_get() from cclock44xx_data.c

I don't understand how to do it and why it is better than the current
approach.

How can that driver do clk_get() from cclock44xx_data.c?
from where does it get the clk_id to pass into clk_get()?

> for now? And then later on we'll just move all the clocks to a
> combination of DT + /lib/firmware.

What is the benefit of moving clock data to /lib/firmware? We could
as well just move it to DT only, no?

> 
>> e.g. auxclk are required to be specified in DT nodes for USB PHY.
>> Without this we can't get USB host working on Panda.
> 
> OK. So if the USB PHY has a dev entry, can't you just set up a
> clock alias in struct omap_clk omap44xx_clks[] for it?

I've explained why this can't be done above.

>  
>> As Rajendra points out, it seems moving entire clock data to DT is not
>> going to happen soon. So this is the simplistic way things can work.
> 
> Right but seems like we can get started there without moving
> them all at once.
> 
What if we provide a complete clock list instead of only auxclks in
dt_clks[]?

This approach is similar to arch/arm/mach-imx/clk-imx35.c

Device drivers can then use them as they migrate to DT. Then later
we could migrate clock data to DT, without impacting device drivers.

cheers,
-roger


From vincent.guittot at linaro.org  Fri Apr  5 07:08:02 2013
From: vincent.guittot at linaro.org (Vincent Guittot)
Date: Fri, 5 Apr 2013 13:08:02 +0200
Subject: [RFC PATCH v3 5/6] sched: pack the idle load balance
In-Reply-To: <1364308932.5053.46.camel@laptop>
References: <1363955155-18382-1-git-send-email-vincent.guittot@linaro.org>
 <1363955155-18382-6-git-send-email-vincent.guittot@linaro.org>
 <1364302359.5053.21.camel@laptop>
 <CAKfTPtD=_oS5gJeynUG=ft-Y1zEdxZEMhUPH9hSXx+H2pi4xgA@mail.gmail.com>
 <1364308932.5053.46.camel@laptop>
Message-ID: <CAKfTPtArtgkH5MU_xFAKjLDS-i32g2qQMdvyW=LLkG84tH8Hhg@mail.gmail.com>

Peter,

After some toughts about your comments,I can update the buddy cpu
during ILB or periofdic LB to a new idle core and extend the packing
mechanism  Does this additional mechanism sound better for you ?

Vincent

On 26 March 2013 15:42, Peter Zijlstra <peterz at infradead.org> wrote:
> On Tue, 2013-03-26 at 15:03 +0100, Vincent Guittot wrote:
>> > But ha! here's your NO_HZ link.. but does the above DTRT and ensure
>> > that the ILB is a little core when possible?
>>
>> The loop looks for an idle CPU as close as possible to the buddy CPU
>> and the buddy CPU is the 1st CPU has been chosen. So if your buddy is
>> a little and there is an idle little, the ILB will be this idle
>> little.
>
> Earlier you wrote:
>
>>       | Cluster 0   | Cluster 1   |
>>       | CPU0 | CPU1 | CPU2 | CPU3 |
>> -----------------------------------
>> buddy | CPU0 | CPU0 | CPU0 | CPU2 |
>
> So extrapolating that to a 4+4 big-little you'd get something like:
>
>       |   little  A9  ||   big A15     |
>       | 0 | 1 | 2 | 3 || 4 | 5 | 6 | 7 |
> ------+---+---+---+---++---+---+---+---+
> buddy | 0 | 0 | 0 | 0 || 0 | 4 | 4 | 4 |
>
> Right?
>
> So supposing the current ILB is 6, we'll only check 4, not 0-3, even
> though there might be a perfectly idle cpu in there.
>
> Also, your scheme fails to pack when cpus 0,4 are filled, even when
> there's idle cores around.
>
> If we'd use the ILB as packing cpu, we would simply select a next pack
> target once the old one fills up.
>


From steve.capper at arm.com  Fri Apr  5 07:11:59 2013
From: steve.capper at arm.com (Steve Capper)
Date: Fri, 5 Apr 2013 12:11:59 +0100
Subject: [PATCH] arm: mm: lockless get_user_pages_fast
In-Reply-To: <1360890012-4684-1-git-send-email-chanho61.park@samsung.com>
References: <1360890012-4684-1-git-send-email-chanho61.park@samsung.com>
Message-ID: <20130405111158.GA13428@e103986-lin>

Hi Chanho,

Apologies for the tardy response, this patch slipped past me.

On Fri, Feb 15, 2013 at 01:00:12AM +0000, Chanho Park wrote:
> This patch adds get_user_pages_fast(old name is "fast_gup") for ARM.
> The fast_gup can walk pagetable without taking mmap_sem or any locks. If there
> is not a pte with the correct permissions for the access, we fall back to slow
> path(get_user_pages) to get remaining pages. This patch is written on reference
> the x86's gup implementation. Traversing of hugepages is excluded because ARM
> haven't supported hugepages yet[1], just only RFC.
> 

I've tested this patch out, unfortunately it treats huge pmds as regular
pmds and attempts to traverse them rather than fall back to a slow path.
The fix for this is very minor, please see my suggestion below.

As an aside, I would like to extend this fast_gup to include full huge
page support and include a __get_user_pages_fast implementation. This
will hopefully fix a problem that was brought to my attention by
Grazvydas Ignotas whereby a FUTEX_WAIT on a THP tail page will cause
an infinite loop due to the stock implementation of __get_user_pages_fast
always returning 0.

> diff --git a/arch/arm/mm/gup.c b/arch/arm/mm/gup.c
> new file mode 100644
> index 0000000..ed54fd8

...

> +static int gup_pmd_range(pud_t *pudp, unsigned long addr, unsigned long end,
> +		int write, struct page **pages, int *nr)
> +{
> +	unsigned long next;
> +	pmd_t *pmdp;
> +
> +	pmdp = pmd_offset(pudp, addr);
> +	do {
> +		next = pmd_addr_end(addr, end);
> +		if (pmd_none(*pmdp))
> +			return 0;

I would suggest:
		if (pmd_none(*pmdp) || pmd_bad(*pmdp))
			return 0;
as this will pick up pmds that can't be traversed, and fall back to the slow path.

> +		else if (!gup_pte_range(pmdp, addr, next, write, pages, nr))
> +			return 0;
> +	} while (pmdp++, addr = next, addr != end);
> +
> +	return 1;
> +}
> +

Cheers,
-- 
Steve



From sambasiva.a at siennaecad.com  Fri Apr  5 07:19:42 2013
From: sambasiva.a at siennaecad.com (sambasiva.a at siennaecad.com)
Date: Fri, 5 Apr 2013 16:49:42 +0530 (IST)
Subject: Regarding the SPI initialization problem on sam9x5 2000 boards in 
 linux kernel 3.2.6
Message-ID: <48262.115.249.69.209.1365160782.squirrel@mail.siennaecad.com>

Hi,

when i execute the following command the sam9x5 2000 board will hang.

echo "test" > /dev/spidev0.1
I am facing this problem once  ported the sam9x5 code from 2.6.39 to 3.2.6
kernel .

Could you please tell me anyone how to move out from the hang state.

Regards
Samba



From rjw at sisk.pl  Fri Apr  5 07:36:29 2013
From: rjw at sisk.pl (Rafael J. Wysocki)
Date: Fri, 05 Apr 2013 13:36:29 +0200
Subject: [PATCH 07/18] cpufreq: s3c24xx: move cpufreq driver to
 drivers/cpufreq
In-Reply-To: <CAKohpokk1Q+0gRpeW=ts0a8D+rGAUpHu62X+7ejdpfom_B6FYA@mail.gmail.com>
References: <cover.1365079581.git.viresh.kumar@linaro.org>
 <2a5901ce31c9$95160980$bf421c80$%kim@samsung.com>
 <CAKohpokk1Q+0gRpeW=ts0a8D+rGAUpHu62X+7ejdpfom_B6FYA@mail.gmail.com>
Message-ID: <1769336.FkfMpuXqqb@vostro.rjw.lan>

On Friday, April 05, 2013 12:36:34 PM Viresh Kumar wrote:
> On 5 April 2013 12:18, Kukjin Kim <kgene.kim at samsung.com> wrote:
> > Basically, this moving looks good to me, but should be re-worked based on
> > for-next of samsung tree because this touches too many samsung stuff so this
> > should be sent to upstream via samsung tree.
> 
> Hmm... Its already applied in Rafael's tree. But it doesn't mean that
> it can't be
> moved to your tree if there is a issue.

Well, I'm dropping it.  Please merge via the Samsung tree.

Thanks,
Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.


From santosh.shilimkar at ti.com  Fri Apr  5 07:58:22 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Fri, 5 Apr 2013 17:28:22 +0530
Subject: [PATCH v2 09/18] ARM: OMAP4+: PM: Restore CPU power state to
 ON with clockdomain force wakeup method
In-Reply-To: <515E9435.6050007@ti.com>
References: <1364205910-32392-1-git-send-email-santosh.shilimkar@ti.com>
 <1364205910-32392-10-git-send-email-santosh.shilimkar@ti.com>
 <87mwtftjvy.fsf@linaro.org> <515D8215.10705@ti.com>
 <87li8ynqf5.fsf@linaro.org> <515E9435.6050007@ti.com>
Message-ID: <515EBC5E.6090705@ti.com>

On Friday 05 April 2013 02:37 PM, Santosh Shilimkar wrote:
> On Thursday 04 April 2013 11:12 PM, Kevin Hilman wrote:
>> Santosh Shilimkar <santosh.shilimkar at ti.com> writes:
>>
>>> On Thursday 04 April 2013 02:24 AM, Kevin Hilman wrote:
>>>> Santosh Shilimkar <santosh.shilimkar at ti.com> writes:
>>>>
>>>>> While waking up CPU from off state using clock domain force wakeup, restore
>>>>> the CPU power state to ON state before putting CPU clock domain under
>>>>> hardware control. Otherwise CPU wakeup might fail. The change is recommended
>>>>> for all OMAP4+ devices though the PRCM weakness was observed on OMAP5
>>>>> devices first.
>>>>
>>>> Sounds reasonable, but can you describe the "weakness" a little more?
>>>>
>>>> IOW, what exactly happens if this is not done?  It sounds like the CPU
>>>> might immediately go back to retention, but how does that happen unless
>>>> it does a WFI?
>>>>
>>> Its more of lock-up inside the hardware state machine and results
>>> are UN-predictable. We have seen hard-locks most of the time where system
>>> is just frozen. The hardware gets into wrong state machine if the power
>>> domain state isn't restored. I will add this information to changelog.
>>>
>>>> Also, this sounds like a fix to me, and should probably be broken out
>>>> accordingly.
>>>>
>>> Yeah. You mean a separate patch from the series, right ? This patch
>>> actually can be independently added.
>>>
>>> In case you decide to apply it for the fixes branch, updated patch
>>> at end of the email.
>>
>> Curious which branch you applied it to?  It didn't apply cleanly to
>> v3.9-rc5 (but did with fuzz).
>>
> Mostly applied on top of the Tony's pull request branches.
> 
>> So I've now added it to my for_3.10/fixes/pm branch.
>>
> Thanks. I will pull that in to re-base other patches.
> 
While pulling your 'for_3.10/fixes/pm' branch on top
of Tony's pull request[1] sent to arm-soc already.
In my tree, I had pulled Tony's couple of pull requests.

Regards,
Santosh

[1] http://www.spinics.net/lists/arm-kernel/msg235788.html


From mgherzan at gmail.com  Fri Apr  5 08:01:21 2013
From: mgherzan at gmail.com (Mircea Gherzan)
Date: Fri, 5 Apr 2013 14:01:21 +0200
Subject: [PATCH V2 2/3] ARM: net: bpf_jit: make code generation less
 dependent on struct sk_filter.
In-Reply-To: <1363618233-6375-3-git-send-email-nschichan@freebox.fr>
References: <1363618233-6375-1-git-send-email-nschichan@freebox.fr>
 <1363618233-6375-3-git-send-email-nschichan@freebox.fr>
Message-ID: <CAN9tCgT0kxJrowV1Y6RX2RhnBgxOCc0o-8Jb2t5-jryG3M95Pg@mail.gmail.com>

2013/3/18 Nicolas Schichan <nschichan at freebox.fr>:
> This is in preparation of bpf_jit support for seccomp filters.
>
> Signed-off-by: Nicolas Schichan <nschichan at freebox.fr>
> ---
>  arch/arm/net/bpf_jit_32.c |   46 ++++++++++++++++++++++++++++-----------------
>  1 file changed, 29 insertions(+), 17 deletions(-)
>
> diff --git a/arch/arm/net/bpf_jit_32.c b/arch/arm/net/bpf_jit_32.c
> index 6828ef6..0ea29e0 100644
> --- a/arch/arm/net/bpf_jit_32.c
> +++ b/arch/arm/net/bpf_jit_32.c
> @@ -55,7 +55,8 @@
>  #define FLAG_NEED_X_RESET      (1 << 0)
>
>  struct jit_ctx {
> -       const struct sk_filter *skf;
> +       unsigned short prog_len;
> +       struct sock_filter *prog_insns;
>         unsigned idx;
>         unsigned prologue_bytes;
>         int ret0_fp_idx;
> @@ -131,8 +132,8 @@ static u16 saved_regs(struct jit_ctx *ctx)
>  {
>         u16 ret = 0;
>
> -       if ((ctx->skf->len > 1) ||
> -           (ctx->skf->insns[0].code == BPF_S_RET_A))
> +       if ((ctx->prog_len > 1) ||
> +           (ctx->prog_insns[0].code == BPF_S_RET_A))
>                 ret |= 1 << r_A;
>
>  #ifdef CONFIG_FRAME_POINTER
> @@ -181,7 +182,7 @@ static inline bool is_load_to_a(u16 inst)
>  static void build_prologue(struct jit_ctx *ctx)
>  {
>         u16 reg_set = saved_regs(ctx);
> -       u16 first_inst = ctx->skf->insns[0].code;
> +       u16 first_inst = ctx->prog_insns[0].code;
>         u16 off;
>
>  #ifdef CONFIG_FRAME_POINTER
> @@ -279,7 +280,7 @@ static u16 imm_offset(u32 k, struct jit_ctx *ctx)
>                 ctx->imms[i] = k;
>
>         /* constants go just after the epilogue */
> -       offset =  ctx->offsets[ctx->skf->len];
> +       offset =  ctx->offsets[ctx->prog_len];
>         offset += ctx->prologue_bytes;
>         offset += ctx->epilogue_bytes;
>         offset += i * 4;
> @@ -419,7 +420,7 @@ static inline void emit_err_ret(u8 cond, struct jit_ctx *ctx)
>                 emit(ARM_MOV_R(ARM_R0, ARM_R0), ctx);
>         } else {
>                 _emit(cond, ARM_MOV_I(ARM_R0, 0), ctx);
> -               _emit(cond, ARM_B(b_imm(ctx->skf->len, ctx)), ctx);
> +               _emit(cond, ARM_B(b_imm(ctx->prog_len, ctx)), ctx);
>         }
>  }
>
> @@ -469,14 +470,13 @@ static inline void update_on_xread(struct jit_ctx *ctx)
>  static int build_body(struct jit_ctx *ctx)
>  {
>         void *load_func[] = {jit_get_skb_b, jit_get_skb_h, jit_get_skb_w};
> -       const struct sk_filter *prog = ctx->skf;
>         const struct sock_filter *inst;
>         unsigned i, load_order, off, condt;
>         int imm12;
>         u32 k;
>
> -       for (i = 0; i < prog->len; i++) {
> -               inst = &(prog->insns[i]);
> +       for (i = 0; i < ctx->prog_len; i++) {
> +               inst = &(ctx->prog_insns[i]);
>                 /* K as an immediate value operand */
>                 k = inst->k;
>
> @@ -769,8 +769,8 @@ cmp_x:
>                                 ctx->ret0_fp_idx = i;
>                         emit_mov_i(ARM_R0, k, ctx);
>  b_epilogue:
> -                       if (i != ctx->skf->len - 1)
> -                               emit(ARM_B(b_imm(prog->len, ctx)), ctx);
> +                       if (i != ctx->prog_len - 1)
> +                               emit(ARM_B(b_imm(ctx->prog_len, ctx)), ctx);
>                         break;
>                 case BPF_S_MISC_TAX:
>                         /* X = A */
> @@ -858,7 +858,7 @@ b_epilogue:
>  }
>
>
> -void bpf_jit_compile(struct sk_filter *fp)
> +static void __bpf_jit_compile(struct jit_ctx *out_ctx)
>  {
>         struct jit_ctx ctx;
>         unsigned tmp_idx;
> @@ -867,11 +867,10 @@ void bpf_jit_compile(struct sk_filter *fp)
>         if (!bpf_jit_enable)
>                 return;
>
> -       memset(&ctx, 0, sizeof(ctx));
> -       ctx.skf         = fp;
> +       ctx = *out_ctx;
>         ctx.ret0_fp_idx = -1;
>
> -       ctx.offsets = kzalloc(4 * (ctx.skf->len + 1), GFP_KERNEL);
> +       ctx.offsets = kzalloc(4 * (ctx.prog_len + 1), GFP_KERNEL);
>         if (ctx.offsets == NULL)
>                 return;
>
> @@ -921,13 +920,26 @@ void bpf_jit_compile(struct sk_filter *fp)
>                 print_hex_dump(KERN_INFO, "BPF JIT code: ",
>                                DUMP_PREFIX_ADDRESS, 16, 4, ctx.target,
>                                alloc_size, false);
> -
> -       fp->bpf_func = (void *)ctx.target;
>  out:
>         kfree(ctx.offsets);
> +
> +       *out_ctx = ctx;
>         return;
>  }
>
> +void bpf_jit_compile(struct sk_filter *fp)
> +{
> +       struct jit_ctx ctx;
> +
> +       memset(&ctx, 0, sizeof(ctx));
> +       ctx.prog_len = fp->len;
> +       ctx.prog_insns = fp->insns;
> +
> +       __bpf_jit_compile(&ctx);
> +       if (ctx.target)
> +               fp->bpf_func = (void*)ctx.target;
> +}
> +
>  static void bpf_jit_free_worker(struct work_struct *work)
>  {
>         module_free(NULL, work);
> --
> 1.7.10.4
>

Acked-by: Mircea Gherzan <mgherzan at gmail.com>


From mgherzan at gmail.com  Fri Apr  5 08:01:55 2013
From: mgherzan at gmail.com (Mircea Gherzan)
Date: Fri, 5 Apr 2013 14:01:55 +0200
Subject: [PATCH V2 3/3] ARM: net: bpf_jit: add support for jitted seccomp
 filters.
In-Reply-To: <1363618233-6375-4-git-send-email-nschichan@freebox.fr>
References: <1363618233-6375-1-git-send-email-nschichan@freebox.fr>
 <1363618233-6375-4-git-send-email-nschichan@freebox.fr>
Message-ID: <CAN9tCgQB1xa_AVBSjt4kYeJmXLPJ+X+oRp4T2PydsvVxWEfeSQ@mail.gmail.com>

2013/3/18 Nicolas Schichan <nschichan at freebox.fr>:
> This patch selects HAVE_SECCOMP_FILTER_JIT in the ARM Kconfig file,
> implements and seccomp_jit_compile() and seccomp_jit_free(), and adds
> support for BPF_S_ANC_SECCOMP_LD_W instruction.
>
> BPF_S_ANC_SECCOMP_LD_W instructions trigger the generation of a call
> to C function seccomp_bpf_load().
>
> Signed-off-by: Nicolas Schichan <nschichan at freebox.fr>
> ---
>  arch/arm/Kconfig          |    1 +
>  arch/arm/net/bpf_jit_32.c |   36 ++++++++++++++++++++++++++++++++++++
>  2 files changed, 37 insertions(+)
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index dedf02b..b3dce17 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -24,6 +24,7 @@ config ARM
>         select HAVE_ARCH_SECCOMP_FILTER
>         select HAVE_ARCH_TRACEHOOK
>         select HAVE_BPF_JIT
> +       select HAVE_SECCOMP_FILTER_JIT
>         select HAVE_C_RECORDMCOUNT
>         select HAVE_DEBUG_KMEMLEAK
>         select HAVE_DMA_API_DEBUG
> diff --git a/arch/arm/net/bpf_jit_32.c b/arch/arm/net/bpf_jit_32.c
> index 0ea29e0..86e3b78 100644
> --- a/arch/arm/net/bpf_jit_32.c
> +++ b/arch/arm/net/bpf_jit_32.c
> @@ -548,6 +548,15 @@ load_common:
>                         emit_err_ret(ARM_COND_NE, ctx);
>                         emit(ARM_MOV_R(r_A, ARM_R0), ctx);
>                         break;
> +#ifdef CONFIG_SECCOMP_FILTER_JIT
> +               case BPF_S_ANC_SECCOMP_LD_W:
> +                       ctx->seen |= SEEN_CALL;
> +                       emit_mov_i(ARM_R3, (u32)seccomp_bpf_load, ctx);
> +                       emit_mov_i(ARM_R0, k, ctx);
> +                       emit_blx_r(ARM_R3, ctx);
> +                       emit(ARM_MOV_R(r_A, ARM_R0), ctx);
> +                       break;
> +#endif
>                 case BPF_S_LD_W_IND:
>                         load_order = 2;
>                         goto load_ind;
> @@ -956,3 +965,30 @@ void bpf_jit_free(struct sk_filter *fp)
>                 schedule_work(work);
>         }
>  }
> +
> +#ifdef CONFIG_SECCOMP_FILTER_JIT
> +void seccomp_jit_compile(struct seccomp_filter *fp)
> +{
> +       struct jit_ctx ctx;
> +
> +       memset(&ctx, 0, sizeof(ctx));
> +       ctx.prog_len = fp->len;
> +       ctx.prog_insns = fp->insns;
> +
> +       __bpf_jit_compile(&ctx);
> +       if (ctx.target)
> +               fp->bpf_func = (void*)ctx.target;
> +}
> +
> +void seccomp_jit_free(struct seccomp_filter *fp)
> +{
> +       struct work_struct *work;
> +
> +       if (fp->bpf_func != sk_run_filter) {
> +               work = (struct work_struct *)fp->bpf_func;
> +
> +               INIT_WORK(work, bpf_jit_free_worker);
> +               schedule_work(work);
> +       }
> +}
> +#endif
> --
> 1.7.10.4
>

Acked-by: Mircea Gherzan <mgherzan at gmail.com>


From linus.walleij at stericsson.com  Fri Apr  5 08:06:35 2013
From: linus.walleij at stericsson.com (Linus Walleij)
Date: Fri, 5 Apr 2013 14:06:35 +0200
Subject: [PATCH] crypto: ux500: add missing comma
Message-ID: <1365163595-21926-1-git-send-email-linus.walleij@stericsson.com>

From: Linus Walleij <linus.walleij at linaro.org>

Commit 4f31f5b19eb0418a847b989abc9ac22af1991fe2
"PM / crypto / ux500: Use struct dev_pm_ops for power management"
add a new line to the driver struct but missed to add a
trailing comma, causing build errors when crypto is
selected. This adds the missing comma.

This was not noticed until now because the crypto block
is not in the ux500 defconfig. A separate patch will
be submitted to fix this.

Cc: <stable at vger.kernel.org> # 3.8.x
Cc: Rafael J. Wysocki <rjw at sisk.pl>
Cc: Magnus Myrstedt <magnus.p.persson at stericsson.com>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 drivers/crypto/ux500/cryp/cryp_core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/crypto/ux500/cryp/cryp_core.c b/drivers/crypto/ux500/cryp/cryp_core.c
index 8bc5fef..22c9063 100644
--- a/drivers/crypto/ux500/cryp/cryp_core.c
+++ b/drivers/crypto/ux500/cryp/cryp_core.c
@@ -1750,7 +1750,7 @@ static struct platform_driver cryp_driver = {
 	.shutdown = ux500_cryp_shutdown,
 	.driver = {
 		.owner = THIS_MODULE,
-		.name  = "cryp1"
+		.name  = "cryp1",
 		.pm    = &ux500_cryp_pm,
 	}
 };
-- 
1.7.11.3



From arnd at arndb.de  Fri Apr  5 08:09:37 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 5 Apr 2013 14:09:37 +0200
Subject: linux-next: manual merge of the arm-soc tree with the xilinx tree
In-Reply-To: <CAHTX3d+NK7b3RVMASZ4BARs1kHeVKGgxNwKTjAeiNB+44TPsFg@mail.gmail.com>
References: <20130405153335.baf29606a97b1bee415f3546@canb.auug.org.au>
 <CAHTX3d+NK7b3RVMASZ4BARs1kHeVKGgxNwKTjAeiNB+44TPsFg@mail.gmail.com>
Message-ID: <201304051409.37708.arnd@arndb.de>

On Friday 05 April 2013, Michal Simek wrote:
> Hi,
> 
> 2013/4/5 Stephen Rothwell <sfr at canb.auug.org.au>
> 
> > Hi all,
> >
> > Today's linux-next merge of the arm-soc tree got a conflict in
> > arch/arm/mach-spear/spear13xx.c between commit c79e33b3e828 ("ARM:
> > smp_twd: convert to use CLKSRC_OF init") from the xilinx tree and commit
> > 2b9c613c4ee1 ("ARM: spear: move generic.h and pl080.h into private dir")
> > from the arm-soc tree.
> >
> > I fixed it up (just used the arm-soc tree version) and can carry the fix
> > as necessary (no action is required).
> >  <sfr at canb.auug.org.au>
> 
> 
> Interesting. I rebased my arm-next branch based on 3.9-rc5
> with some Rob's + one Arnd patch from arm-soc - clksrc/cleanup branch.
> 
> I will fix my arm-next branch.

The for-next branch in arm-soc is not stable, you should never base
/anything/ on it. If you depend on some stable branch, that is in arm-soc,
then use just that branch, not one of the next/* branches or for-next.

	Arnd


From mkl at pengutronix.de  Fri Apr  5 08:14:06 2013
From: mkl at pengutronix.de (Marc Kleine-Budde)
Date: Fri, 05 Apr 2013 14:14:06 +0200
Subject: mmc: mxs-mmc: add non-removeable property
In-Reply-To: <CAAAP30HvkQNTS1+7QddAV4CZVo=g3vaJGjJNNFu3CCbGDHTqsQ@mail.gmail.com>
References: <CAAAP30HvkQNTS1+7QddAV4CZVo=g3vaJGjJNNFu3CCbGDHTqsQ@mail.gmail.com>
Message-ID: <515EC00E.5060009@pengutronix.de>

On 04/05/2013 02:01 PM, Alexandre Pereira da Silva wrote:
> I just sent a patch to fix the same thing to the list, without seeing
> yours first.
> 
> But in the discussion, I learned that I should be checking for
> broken-cd instead of non-removable.

I'm not subscribed to linux-mmc and on
http://news.gmane.org/gmane.linux.kernel.mmc I just see Marek's
Reviewed-by. Can you point me to the discussion?

In fact my board has an eMMC, which is soldered to the board and the
card detect is not connected...the documentation says:

>   - broken-cd: There is no card detection available; polling must be used.
>   - non-removable: non-removable slot (like eMMC); assume always present.

I see no point in using polling if the card is in deed always present.

> Would you like for me to send a separate patch for broken-cd or do you
> prefer to check on yours when you resubmit?

If your card detect is not connected and the card is removable, you
should use broken-cd and base you patch on mine.

Marc
-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130405/c8e8ab65/attachment.sig>

From jon-hunter at ti.com  Fri Apr  5 08:18:29 2013
From: jon-hunter at ti.com (Jon Hunter)
Date: Fri, 5 Apr 2013 07:18:29 -0500
Subject: [PATCH 0/5] gpio/omap: 2nd batch of updates for v3.10
In-Reply-To: <515E70B8.6060903@ti.com>
References: <1365106576-31816-1-git-send-email-jon-hunter@ti.com>
 <515E70B8.6060903@ti.com>
Message-ID: <515EC115.8040408@ti.com>


On 04/05/2013 01:35 AM, Santosh Shilimkar wrote:
> On Friday 05 April 2013 01:46 AM, Jon Hunter wrote:
>> Main change is ensuring that the state of a gpio bank is restored when
>> booting with device-tree. The rest of the patches are clean-ups and one
>> optimisation.
>>
>> The patch modifying the *.dtsi files should go via Benoit Cousson's
>> for_3.10/dts branch [1] as it is dependent on changes in his branch but
>> I have included here for completeness.
>>
>> Testing includes:
>> - Boot testing on OMAP5912 OSK, OMAP2420 H4, OMAP3430 SDP, OMAP4430 SDP
>>   and AM335x EVM.
>> - Verified that GPIO interrupts are working on OMAP5912 OSK, OMAP2420 H4,
>>   OMAP3430 SDP and OMAP4430 SDP by making sure networking was working
>>   correctly as these boards use a GPIO with the ethernet chips. Also
>>   checked /proc/interrupts to ensure GPIO interrupt counts are
>>   incrementing as expected.
>>
>> [1] http://git.kernel.org/cgit/linux/kernel/git/bcousson/linux-omap-dt.git
>>
>> Jon Hunter (4):
>>   gpio/omap: free irq domain in probe() failure paths
>>   gpio/omap: optimise interrupt service routine
>>   gpio/omap: force restore if context loss is not detectable
>>   ARM: dts: OMAP2+: Identify GPIO banks that are always powered
>>
>> Tarun Kanti DebBarma (1):
>>   gpio/omap: remove extra context restores in *_runtime_resume()
>>
> 
> Thanks Jon for pulling the fixes. I suggest you to split the series so
> that 'gpio/omap:*' can be pulled by Grant and 'ARM: dts:*' by Benoit.

Agreed. I had kept them altogether here for completeness as it would
have been odd to add a new property but not use it. If everyone is ok
with the changes, then I can either resend or Grant/Linus just pick up 1-4.

> All the 'gpio/omap:*' patches in the series looks fine to me.
> FWIW,
> Acked-by: Santosh Shilimkar <santosh.shilimkar at ti.com>

Thanks
Jon


From rjw at sisk.pl  Fri Apr  5 08:38:26 2013
From: rjw at sisk.pl (Rafael J. Wysocki)
Date: Fri, 05 Apr 2013 14:38:26 +0200
Subject: [PATCH V5 0/4] cpufreq: exynos5440: support for cpufreq driver
In-Reply-To: <1364457923-8499-1-git-send-email-amit.daniel@samsung.com>
References: <1364457923-8499-1-git-send-email-amit.daniel@samsung.com>
Message-ID: <2949363.nNl2A6XIoS@vostro.rjw.lan>

On Thursday, March 28, 2013 01:35:18 PM Amit Daniel Kachhap wrote:
> Submitting the V5 version of exynos5440 cpufreq driver. This patchset addresses
> all the coding and design concerns raised especially by Viresh.
> 
> Changes in V5:
> * Removed the unnecessary DT look up entry from mach-exynos5-dt.c.
> * Fixed all coding and comments issue raised by Viresh.
> 
> Changes in V4:
> * Added dev_err logs instead of pr_err.
> * Used the devm_ioremap_resource API.
> * Implemented several coding guidelines and minor error comments from Sylwester,
>   Russell and Viresh.
> 
> Changes in V3:
> * Converted the driver to probe based as suggested by Viresh. This is also
>   beneficial for multiplatform kernel.
> * Other coding guidelines related changes.
> * Moved the DT node outside cpu0 node as the driver is now a platform
>   driver.
> 
> Changes in V2:
> * Added OPP library support to parse DT parameters.
> * Removed a hack to handle interrupts in bootup.
> * Implemented other review comments from Viresh and Inder.
> 
> All these patches are dependent on Thomas Abraham common clock patches.
> (http://www.mail-archive.com/linux-samsung-soc at vger.kernel.org/msg15860.html)
> This whole patch series is based on 3.9-rc4.
> 
> Amit Daniel Kachhap (4):
>   cpufreq: exynos: Add cpufreq driver for exynos5440
>   cpufreq: exynos: Remove error return even if no soc is found
>   arm: exynos: Enable OPP library support for exynos5440
>   arm: dts: Add cpufreq controller node for Exynos5440 SoC
> 
>  .../bindings/cpufreq/cpufreq-exynos5440.txt        |   28 ++
>  arch/arm/boot/dts/exynos5440.dtsi                  |   12 +
>  arch/arm/mach-exynos/Kconfig                       |    2 +
>  drivers/cpufreq/Kconfig.arm                        |    9 +
>  drivers/cpufreq/Makefile                           |    1 +
>  drivers/cpufreq/exynos-cpufreq.c                   |    2 +-
>  drivers/cpufreq/exynos5440-cpufreq.c               |  474 ++++++++++++++++++++
>  7 files changed, 527 insertions(+), 1 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt
>  create mode 100644 drivers/cpufreq/exynos5440-cpufreq.c

Is this for me or the Samsung tree?

If it's for me, I need ACKs from the Samsung tree maintainers.  Also, please
address the Viresh's comments.

Thanks,
Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.


From gregory.clement at free-electrons.com  Fri Apr  5 08:32:51 2013
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Fri,  5 Apr 2013 14:32:51 +0200
Subject: [PATCH 3.9-rc6] arm: mvebu: Fix the irq map function in SMP mode
Message-ID: <1365165172-11447-1-git-send-email-gregory.clement@free-electrons.com>

Hi Jason,

This patch is a fix for 3.9-rc6 to solve the issue reported by Ryan
Press: GPIO IRQ were no longer delivered to the CPUs. It has been
tested by Ezequiel. See the commit log for all the details.

This patch was applied on 3.9-rc5 and the commit "arm: mvebu: Use
local interrupt only for the timer 0".

Thanks

Gregory CLEMENT (1):
  arm: mvebu: Fix the irq map function in SMP mode

 arch/arm/mach-mvebu/irq-armada-370-xp.c |   16 +++++-----------
 1 file changed, 5 insertions(+), 11 deletions(-)

-- 
1.7.9.5



From gregory.clement at free-electrons.com  Fri Apr  5 08:32:52 2013
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Fri,  5 Apr 2013 14:32:52 +0200
Subject: [PATCH] arm: mvebu: Fix the irq map function in SMP mode
In-Reply-To: <1365165172-11447-1-git-send-email-gregory.clement@free-electrons.com>
References: <1365165172-11447-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1365165172-11447-2-git-send-email-gregory.clement@free-electrons.com>

This patch fix the regression introduced by the commit 3202bf0157ccb
"arm: mvebu: Improve the SMP support of the interrupt controller":
GPIO IRQ were no longer delivered to the CPUs.

To be delivered to a CPU an interrupt must be enabled at CPU level and
at interrupt source level. Before the offending patch, all the
interrupts were enabled at source level during map() function. Mask()
and unmask() was done by handling the per-CPU part. It was fine when
running in UP with only one CPU.

The offending patch added support for SMP, in this case mask() and
unmask() was done by handling the interrupt source level part. The
per-CPU level part was handled by the affinity API to select the CPU
which will receive the interrupt. (Due to some hardware limitation
only one CPU at a time can received a given interrupt).

For "normal" interrupt __setup_irq() was called when an irq was
registered. irq_set_affinity() is called from this function, which
enabled the interrupt on one of the CPUs. Whereas for GPIO IRQ which
were chained interrupts, the irq_set_affinity() was never called and
none of the CPUs was selected to receive the interrupt.

With this patch all the interrupt are enable on the current CPU during
map() function. Enabling the interrupts on a CPU doesn't depend
anymore on irq_set_affinity() and then the chained irq are not anymore
a special case. However the CPU which will receive the irq can still
be modify later using irq_set_affinity().

Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
Reported-by: Ryan Press <ryan at presslab.us>
Investigated-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
Tested-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>

Tested with Mirabox (A370) and Openblocks AX3 (AXP), rootfs mounted
over NFS, compiled with CONFIG_SMP=y/N.
---
 arch/arm/mach-mvebu/irq-armada-370-xp.c |   16 +++++-----------
 1 file changed, 5 insertions(+), 11 deletions(-)

diff --git a/arch/arm/mach-mvebu/irq-armada-370-xp.c b/arch/arm/mach-mvebu/irq-armada-370-xp.c
index 6a9195e..d5970f5 100644
--- a/arch/arm/mach-mvebu/irq-armada-370-xp.c
+++ b/arch/arm/mach-mvebu/irq-armada-370-xp.c
@@ -61,7 +61,6 @@ static struct irq_domain *armada_370_xp_mpic_domain;
  */
 static void armada_370_xp_irq_mask(struct irq_data *d)
 {
-#ifdef CONFIG_SMP
 	irq_hw_number_t hwirq = irqd_to_hwirq(d);
 
 	if (hwirq != ARMADA_370_XP_TIMER0_PER_CPU_IRQ)
@@ -70,15 +69,10 @@ static void armada_370_xp_irq_mask(struct irq_data *d)
 	else
 		writel(hwirq, per_cpu_int_base +
 				ARMADA_370_XP_INT_SET_MASK_OFFS);
-#else
-	writel(irqd_to_hwirq(d),
-	       per_cpu_int_base + ARMADA_370_XP_INT_SET_MASK_OFFS);
-#endif
 }
 
 static void armada_370_xp_irq_unmask(struct irq_data *d)
 {
-#ifdef CONFIG_SMP
 	irq_hw_number_t hwirq = irqd_to_hwirq(d);
 
 	if (hwirq != ARMADA_370_XP_TIMER0_PER_CPU_IRQ)
@@ -87,10 +81,6 @@ static void armada_370_xp_irq_unmask(struct irq_data *d)
 	else
 		writel(hwirq, per_cpu_int_base +
 				ARMADA_370_XP_INT_CLEAR_MASK_OFFS);
-#else
-	writel(irqd_to_hwirq(d),
-	       per_cpu_int_base + ARMADA_370_XP_INT_CLEAR_MASK_OFFS);
-#endif
 }
 
 #ifdef CONFIG_SMP
@@ -146,7 +136,11 @@ static int armada_370_xp_mpic_irq_map(struct irq_domain *h,
 				      unsigned int virq, irq_hw_number_t hw)
 {
 	armada_370_xp_irq_mask(irq_get_irq_data(virq));
-	writel(hw, main_int_base + ARMADA_370_XP_INT_SET_ENABLE_OFFS);
+	if (hw != ARMADA_370_XP_TIMER0_PER_CPU_IRQ)
+		writel(hw, per_cpu_int_base +
+			ARMADA_370_XP_INT_CLEAR_MASK_OFFS);
+	else
+		writel(hw, main_int_base + ARMADA_370_XP_INT_SET_ENABLE_OFFS);
 	irq_set_status_flags(virq, IRQ_LEVEL);
 
 	if (hw == ARMADA_370_XP_TIMER0_PER_CPU_IRQ) {
-- 
1.7.9.5



From alexandre.belloni at free-electrons.com  Fri Apr  5 08:33:02 2013
From: alexandre.belloni at free-electrons.com (Alexandre Belloni)
Date: Fri,  5 Apr 2013 14:33:02 +0200
Subject: [PATCH] ARM: dts: cfa10036: Add touchscreen support to the CFA-10049
Message-ID: <1365165182-29502-1-git-send-email-alexandre.belloni@free-electrons.com>

Signed-off-by: Alexandre Belloni <alexandre.belloni at free-electrons.com>
---
 arch/arm/boot/dts/imx28-cfa10049.dts |    5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/imx28-cfa10049.dts b/arch/arm/boot/dts/imx28-cfa10049.dts
index b9dad4e..f16c1e2 100644
--- a/arch/arm/boot/dts/imx28-cfa10049.dts
+++ b/arch/arm/boot/dts/imx28-cfa10049.dts
@@ -192,6 +192,11 @@
 			usbphy1: usbphy at 8007e000 {
 				status = "okay";
 			};
+
+			lradc at 80050000 {
+				status = "okay";
+				fsl,lradc-touchscreen-wires = <4>;
+			};
 		};
 	};
 
-- 
1.7.10.4



From t-kristo at ti.com  Fri Apr  5 08:42:27 2013
From: t-kristo at ti.com (Tero Kristo)
Date: Fri, 5 Apr 2013 15:42:27 +0300
Subject: [GIT PULL] ARM: OMAP5: hwmod, prm/cm data files and updates
 for 3.10
In-Reply-To: <515D6020.2030103@ti.com>
References: <1363768852-18125-1-git-send-email-santosh.shilimkar@ti.com>
 <20130401170539.GK10155@atomide.com> <515BA76D.3000302@ti.com>
 <alpine.DEB.2.00.1304031146230.2616@utopia.booyaka.com>
 <515D6020.2030103@ti.com>
Message-ID: <1365165747.19492.117.camel@sokoban>

On Thu, 2013-04-04 at 16:42 +0530, Santosh Shilimkar wrote:
> + Tero and few more TI folks,

Hi,

Added some comments below.

> 
> On Thursday 04 April 2013 01:12 AM, Paul Walmsley wrote:
> > Hi Santosh
> > 
> > On Wed, 3 Apr 2013, Santosh Shilimkar wrote:
> > 
> >> Thes patchset has already missed last couple of merge windows and its the
> >> biggest bottleneck in getting OMAP5 booting from mainline. So I request
> >> you to please have a look it quickly so that Tony can line that up for
> >> 3.10.
> > 
> > Looks like there are a few minor issues with the patches based on a quick 
> > look.  I'll post those to the list shortly; they should be easy to fix.  
> > But those issues aren't my real concern with this series.
> > 
> > What's harder to fix are the underlying process issues.  My main concern 
> > is that these patches add almost 9,000 lines of code and data.  We've 
> > received clear guidance from the upstream ARM SoC maintainers that any 
> > significant new additions need to be balanced with moving a similar number 
> > of lines of code and data out of arch/arm/{plat-,mach-}* into drivers/.  
> > (Or the new patches should be accompanied with patches that show obvious 
> > progress towards the goal of moving code and data out of 
> > arch/arm/{plat-,mach-}*.)  We need to see more help from TI on the 
> > prerequisites for this cleanup process.
> >
> I agree that we are not making faster progress but as part of the
> $subject series itself, for DT only build, we removed around ~4000
> lines of data from hwmod. After the merge window, we can trim
> the AM33XX and then later OMAP4 when it is made DT only support.
> That should give us another 6000 lines of negative diff.
> At the same time removal of MUX data for OMAP4 should be
> around 2000 lines of negative diff.
> 
> You might also notice, we dropped OMAP5 clock data considering
> its move under drivers/clk/. Rajendra and Tero already posted
> patches [1] for the same on the list. Ofcourse your feedback is
> needed to make progress there.
> 
> > For example, as discussed last year with the TI upstream PM team, an 
> > important first step in this process in my view is to get rid of the 
> > direct PRM/CM register accesses in the OMAP PM code.  See commit 
> > c4ceedcb18cf7a06059482a3a1828b9aad9f78cf ("ARM: OMAP2+: CM/clock: convert 
> > _omap2_module_wait_ready() to use SoC-independent CM functions") as an 
> > example of this process.  This should make it easier to get the PRM/CM 
> > functionality into drivers/.  That in turn make it possible to move the 
> > clockdomain, clock, powerdomain, and hwmod code to drivers/.ARM: OMAP2+: 
> > CM/clock: convert _omap2_module_wait_ready() to use SoC-independent CM 
> > functions.  So far as I can tell, there hasn't been any forward progress 
> > on this.
> >
> On this part as well after my discussion with Tony, Tero picked it up
> and he and Eduardo posted questions to you [2] considering you
> already had some WIP patches as we learned from Tony. I suggest
> you send any information on this to "Tero" since he is leading the
> PM effort and has plans to work on these items.
>  
> > It's also necessary to see more TI contributions in finding and fixing 
> > regressions.  Detecting and fixing regressions from the previous kernel 
> > release should be done first, before working on cleanup series or new 
> > feature/SoC additions.  Looking at the list of v3.9-rc regressions that 
> > I've found, we've gotten very little organized help from TI on dealing 
> > with them.  
> > 
> > This in turn robs the maintainers of time that could be spent doing patch 
> > review or further cleanup work, which benefits no one in the end.  
> > Ideally each regression would be assigned to a member of the TI upstream 
> > team, and the whole process could be completed within one or two weeks.
> >
> I agree with you overall. 
> 
> On couple of specific issues though,
> 
> - BOOT-Loader version:  IMHO boot-loader should be upgraded here.
> We always upgrade kernel for new/fixed features and bootloader should
> be no exception.
>
> - Co-processor Power issue: This one is also has boot-loader dependency
> but here too, going on path where firmware needs to be loaded to idle
> them isn't great idea. We never did that for OMAP2/3 where DSP, Tesla
> was present. IMO, we should not bring these devices out of reset and
> let the "remote_proc()" frame works take care of them when it is
> available in kernel. Suman from TI is working on it to enable that.

I kind of understand why you insist keeping your old bootloader, as it
makes these issues visible, but well, nothing is going to happen for
them as far as I can see. If Suman can eventually provide a nice hack
that makes this happen, fine, but at least on the PM front, we can do
nothing. Even if we did, the implementation would most likely become so
ugly that it would be rejected by the maintainers anyway. I can't see
any point why to invest time on this.

> > ...
> > 
> > So from my point of view, I'd like to see the following changes before we 
> > accept any new patchsets that add a significant number of lines:
> > 
> > 1. Organized help from TI in finding and fixing regressions in the -rc 
> > cycle, with the regressions dealt with before any new feature 
> > pull-requests are sent
> >
> Agreed. Tero can help here to streamline the process for PM regressions.
> Rest of the core regressions and MPU PM, feel free to pass it on to
> Rajendra/me. We will try to address them on priority.

With this, I think we are able to only help partially. The problem is
the number of (in my view) obsolete platforms that are being used (read:
omap2.) We can't provide any support for the boards we don't have
available, and I can say from the list of your rc3 comments, that we
have access to only 4 of the boards you are using (pandas, bone and
beagle, and the panda problems you can most likely fix by updating your
bootloader.)

> 
>  
> > 2. Help from TI on some of the cleanup work that we've mentioned in the 
> > past, starting with the PRM/CM register access cleanup inside mach-omap2/
> > 
> Absolutely. As I mentioned earlier, Eduardo and Tero are waiting for your
> inputs on this topic.

Well, this part we started with moving the ccf data under drivers/clk.
prm/cm has not been started, but we have plans to work with this.

-Tero

> 
> > 3. Pairing any large feature or SoC additions with at least an equal 
> > removal of lines of code
> > 
> As listed in beginning of the email, there is an effort going on in this
> direction. In fact removal of lines of code has to happen even without
> any new feature. As Tony mentioned in past, we eventually want to support
> DT only builds and that should also allow us significant loc removal
> opportunity. But feel free to suggest ideas if you see more opportunities
> apart from the obvious ones.
> 
> Thanks for all your help.
> 
> Regards,
> Santosh
> 
> [1] http://www.mail-archive.com/linux-omap at vger.kernel.org/msg87110.html
> [2] http://www.mail-archive.com/linux-omap at vger.kernel.org/msg85602.html




From mkl at pengutronix.de  Fri Apr  5 08:49:22 2013
From: mkl at pengutronix.de (Marc Kleine-Budde)
Date: Fri, 05 Apr 2013 14:49:22 +0200
Subject: mmc: mxs-mmc: add non-removeable property
In-Reply-To: <CAAAP30GCRsS4JhAy0yP5su3mVm-NNTxtVS0cddxWGVwS3C6gNw@mail.gmail.com>
References: <CAAAP30HvkQNTS1+7QddAV4CZVo=g3vaJGjJNNFu3CCbGDHTqsQ@mail.gmail.com>
 <515EC00E.5060009@pengutronix.de>
 <CAAAP30GCRsS4JhAy0yP5su3mVm-NNTxtVS0cddxWGVwS3C6gNw@mail.gmail.com>
Message-ID: <515EC852.8080404@pengutronix.de>

On 04/05/2013 02:31 PM, Alexandre Pereira da Silva wrote:
> On Fri, Apr 5, 2013 at 9:14 AM, Marc Kleine-Budde <mkl at pengutronix.de>
> wrote:
>> I'm not subscribed to linux-mmc and on
>> http://news.gmane.org/gmane.linux.kernel.mmc I just see Marek's
>> Reviewed-by. Can you point me to the discussion?
> 
> http://marc.info/?l=linux-kernel&m=136515344220293&w=2

tnx

>> If your card detect is not connected and the card is removable, you
>> should use broken-cd and base you patch on mine.
> 
> Ok, I will do that.

I've just posted an updated series.

Marc
-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130405/4d5617ad/attachment.sig>

From s.nawrocki at samsung.com  Fri Apr  5 08:54:46 2013
From: s.nawrocki at samsung.com (Sylwester Nawrocki)
Date: Fri, 05 Apr 2013 14:54:46 +0200
Subject: [PATCH 0/3] clk: Exynos: Register audio subsytem clocks using
 common clk framework
In-Reply-To: <1365144043-17101-1-git-send-email-padma.v@samsung.com>
References: <1365144043-17101-1-git-send-email-padma.v@samsung.com>
Message-ID: <515EC996.8030904@samsung.com>

Hi Padmavathi,

On 04/05/2013 08:40 AM, Padmavathi Venna wrote:
> Samsung Exynos SoC has a separate subsystem for audio. This subsystem
> has a internal clock controller which controls i2s0 and pcm0 clocks.
> This patch series adds the Samsung Exynos SoC audio subsytem clock code
> to the common clock framework and provides the I2S0 clock information in
> the dtsi file.
> 
> Padmavathi Venna (3):
>   clk: exynos: register audio subsystem clocks using common clock
>     framework
>   ARM: dts: add Exynos audio subsystem clock controller node
>   ARM: dts: add clock provider information for i2s0 controller in
>     Exynos5250
> 
>  arch/arm/boot/dts/exynos5250.dtsi      |    8 ++
>  drivers/clk/samsung/Makefile           |    1 +
>  drivers/clk/samsung/clk-exynos-audss.c |  139 ++++++++++++++++++++++++++++++++
>  3 files changed, 148 insertions(+), 0 deletions(-)
>  create mode 100644 drivers/clk/samsung/clk-exynos-audss.c

It looks good, it's very similar what we have written recently for Exynos4.
It seems the binding documentation is missing in this patch set. I've included
below content of our .../bindings/clock/exynos4-audss-clock.txt file. Feel free
to reuse any parts of it. 

>From a brief look Exynos4 and Exynos5 Audio Subsystem CLKCON very similar.
I've just found bit 2 of 0x0381_0008 register is not used on Exynos5250.

Additionally the Audio Subsystem Clock controller is present on S5PV210
SoCs and IMO compatible property you used is too generic. I would propose
to use at least:

"samsung,s5pv210-audss-clock"    - for S5PV210 
"samsung,exynos4210-audss-clock" - for Exynos4
"samsung,exynos5250-audss-clock" - for Exynos5


8<---------------------------------------------------------------------------
* Samsung Exynos4 Audio Subsystem Clock Controller

The Exynos4 Audio Subsystem clock controller generates and supplies clocks
to Audio Subsystem block available in the Exynos4 SoCs. The clock binding
described here is applicable to all SoC's in the Exynos4 family.

Required Properties:

- compatible: should be one of the following:
  - "samsung,exynos4210-audss-clock" - controller compatible with all Exynos4 SoCs.

- reg: physical base address and length of the controller's register set.

- #clock-cells: should be 1.

The following is the list of clocks generated by the controller. Each clock is
assigned an identifier and client nodes use this identifier to specify the
clock which they consume. Some of the clocks are available only on a particular
Exynos4 SoC and this is specified where applicable.

Provided clocks:

Clock		ID	SoC (if specific)
-----------------------------------------------

mout_audss	0
dout_rp		1
dout_aud_bus	2
mout_i2s	3
dout_i2sclk0	4
clk_i2s0	5
clk_pcm0	6


Example 1: An example of a clock controller node is listed below.

clock_audss: clock-controller at 03810000 {
	compatible = "samsung,exynos4-audss-clock";
	reg = <0x03810000 0x0C>;
	#clock-cells = <1>;
};

Example 2: I2S controller node that consumes the clock generated by the clock
	   controller. Refer to the standard clock bindings for information
	   about 'clocks' and 'clock-names' property.

i2s0: i2s at 03830000 {
	compatible = "samsung,i2s-v5";
	reg = <0x03830000 0x100>;
	clocks = <&clock_audss 0>, <&clock_audss 3>, <&clock_audss 1>,
		<&clock_audss 2>, <&clock_audss 4>, <&clock_audss 2>;
	clock-names = "mout_audss", "mout_i2s", "dout_srp",
		"dout_bus", "dout_i2s", "i2s_opclk0";
};

8<---------------------------------------------------------------------------

Thanks,
Sylwester


From santosh.shilimkar at ti.com  Fri Apr  5 08:58:59 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Fri, 5 Apr 2013 18:28:59 +0530
Subject: [PATCH v3 0/4] ARM: OMAP4+: PM: Consolidate code for re-use on OMAP5
Message-ID: <1365166743-5940-1-git-send-email-santosh.shilimkar@ti.com>

Kevin,

As discussed on list, I split the v2 [1] series into cleanup and OMAP5 support.
This series contains the clean-up patches. I have rebased on top of Tony's
pull request and your 3.10/* branches. Series is tested on OMAP4430 SDP
with CPUIDLE and suspend. OMAP5 PM support I will post later since it has
a dependency with OMAP5 data files which are not pulled in yet.

Regards,
Santosh
[1] http://www.spinics.net/lists/linux-omap/msg88901.html


The following changes since commit 4b9ce8484d8122f2088cedf60265ae86f7822350:

  Merge branch 'for_3.10/fixes/pm' of git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm into for_3.10/omap_pm-cleanup (2013-04-05 18:10:34 +0530)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux.git 

for you to fetch changes up to 884ef029cb434aad124bf8413211a698597f8f7a:

  ARM: OMAP4+: CPUidle: Consolidate idle driver for OMAP5 support (2013-04-05 18:11:06 +0530)

----------------------------------------------------------------

Santosh Shilimkar (4):
  ARM: OMAP4+: PM: Consolidate MPU subsystem PM code for re-use
  ARM: OMAP4+: PM: Consolidate OMAP4 PM code to re-use it for OMAP5
  ARM: OMAP4+: Make secondary_startup function name more consistent
  ARM: OMAP4+: CPUidle: Consolidate idle driver for OMAP5 support

 arch/arm/mach-omap2/Makefile                       |    9 +--
 arch/arm/mach-omap2/common.h                       |    4 +-
 arch/arm/mach-omap2/cpuidle44xx.c                  |   31 ++++-----
 arch/arm/mach-omap2/omap-headsmp.S                 |    8 +--
 arch/arm/mach-omap2/omap-mpuss-lowpower.c          |   68 ++++++++++++++++----
 arch/arm/mach-omap2/omap-smp.c                     |    6 +-
 arch/arm/mach-omap2/{pm44xx.c => pm_omap4plus.c}   |   58 ++++++++++++++---
 .../mach-omap2/{sleep44xx.S => sleep_omap4plus.S}  |    0
 8 files changed, 132 insertions(+), 52 deletions(-)
 rename arch/arm/mach-omap2/{pm44xx.c => pm_omap4plus.c} (83%)
 rename arch/arm/mach-omap2/{sleep44xx.S => sleep_omap4plus.S} (100%)

-- 
1.7.9.5



From santosh.shilimkar at ti.com  Fri Apr  5 08:59:02 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Fri, 5 Apr 2013 18:29:02 +0530
Subject: [PATCH v3 3/4] ARM: OMAP4+: Make secondary_startup function name more
 consistent
In-Reply-To: <1365166743-5940-1-git-send-email-santosh.shilimkar@ti.com>
References: <1365166743-5940-1-git-send-email-santosh.shilimkar@ti.com>
Message-ID: <1365166743-5940-4-git-send-email-santosh.shilimkar@ti.com>

Current code has rather inconsistent function names for 'secondary_startup'
routines. Update it to make it more consistent.

Suggested by Kevin Hilman as part of OMAP5 PM patch review.

Cc: Kevin Hilman <khilman at deeprootsystems.com>

Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
---
 arch/arm/mach-omap2/common.h              |    4 ++--
 arch/arm/mach-omap2/omap-headsmp.S        |    8 ++++----
 arch/arm/mach-omap2/omap-mpuss-lowpower.c |    6 +++---
 arch/arm/mach-omap2/omap-smp.c            |    6 +++---
 4 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index f5c9983..1fe86be 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -230,8 +230,8 @@ extern void omap_do_wfi(void);
 
 #ifdef CONFIG_SMP
 /* Needed for secondary core boot */
-extern void omap_secondary_startup(void);
-extern void omap_secondary_startup_4460(void);
+extern void omap4_secondary_startup(void);
+extern void omap4460_secondary_startup(void);
 extern u32 omap_modify_auxcoreboot0(u32 set_mask, u32 clear_mask);
 extern void omap_auxcoreboot_addr(u32 cpu_addr);
 extern u32 omap_read_auxcoreboot0(void);
diff --git a/arch/arm/mach-omap2/omap-headsmp.S b/arch/arm/mach-omap2/omap-headsmp.S
index 0ea09fa..4ea3081 100644
--- a/arch/arm/mach-omap2/omap-headsmp.S
+++ b/arch/arm/mach-omap2/omap-headsmp.S
@@ -49,7 +49,7 @@ END(omap5_secondary_startup)
  * The primary core will update this flag using a hardware
  * register AuxCoreBoot0.
  */
-ENTRY(omap_secondary_startup)
+ENTRY(omap4_secondary_startup)
 hold:	ldr	r12,=0x103
 	dsb
 	smc	#0			@ read from AuxCoreBoot0
@@ -64,9 +64,9 @@ hold:	ldr	r12,=0x103
 	 * should now contain the SVC stack for this core
 	 */
 	b	secondary_startup
-ENDPROC(omap_secondary_startup)
+ENDPROC(omap4_secondary_startup)
 
-ENTRY(omap_secondary_startup_4460)
+ENTRY(omap4460_secondary_startup)
 hold_2:	ldr	r12,=0x103
 	dsb
 	smc	#0			@ read from AuxCoreBoot0
@@ -101,4 +101,4 @@ hold_2:	ldr	r12,=0x103
 	 * should now contain the SVC stack for this core
 	 */
 	b	secondary_startup
-ENDPROC(omap_secondary_startup_4460)
+ENDPROC(omap4460_secondary_startup)
diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index 391bf2d..f993a41 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -310,7 +310,7 @@ int __cpuinit omap4_hotplug_cpu(unsigned int cpu, unsigned int power_state)
 	/*
 	 * CPU never retuns back if targeted power state is OFF mode.
 	 * CPU ONLINE follows normal CPU ONLINE ptah via
-	 * omap_secondary_startup().
+	 * omap4_secondary_startup().
 	 */
 	omap_pm_ops.finish_suspend(cpu_state);
 
@@ -356,9 +356,9 @@ int __init omap4_mpuss_init(void)
 	pm_info->wkup_sar_addr = sar_base + CPU1_WAKEUP_NS_PA_ADDR_OFFSET;
 	pm_info->l2x0_sar_addr = sar_base + L2X0_SAVE_OFFSET1;
 	if (cpu_is_omap446x())
-		pm_info->secondary_startup = omap_secondary_startup_4460;
+		pm_info->secondary_startup = omap4460_secondary_startup;
 	else
-		pm_info->secondary_startup = omap_secondary_startup;
+		pm_info->secondary_startup = omap4_secondary_startup;
 
 	pm_info->pwrdm = pwrdm_lookup("cpu1_pwrdm");
 	if (!pm_info->pwrdm) {
diff --git a/arch/arm/mach-omap2/omap-smp.c b/arch/arm/mach-omap2/omap-smp.c
index e4441cc..8106e8d 100644
--- a/arch/arm/mach-omap2/omap-smp.c
+++ b/arch/arm/mach-omap2/omap-smp.c
@@ -94,7 +94,7 @@ static int __cpuinit omap4_boot_secondary(unsigned int cpu, struct task_struct *
 
 	/*
 	 * Update the AuxCoreBoot0 with boot state for secondary core.
-	 * omap_secondary_startup() routine will hold the secondary core till
+	 * omap4_secondary_startup() routine will hold the secondary core till
 	 * the AuxCoreBoot1 register is updated with cpu state
 	 * A barrier is added to ensure that write buffer is drained
 	 */
@@ -207,7 +207,7 @@ static void __init omap4_smp_init_cpus(void)
 
 static void __init omap4_smp_prepare_cpus(unsigned int max_cpus)
 {
-	void *startup_addr = omap_secondary_startup;
+	void *startup_addr = omap4_secondary_startup;
 	void __iomem *base = omap_get_wakeupgen_base();
 
 	/*
@@ -218,7 +218,7 @@ static void __init omap4_smp_prepare_cpus(unsigned int max_cpus)
 		scu_enable(scu_base);
 
 	if (cpu_is_omap446x()) {
-		startup_addr = omap_secondary_startup_4460;
+		startup_addr = omap4460_secondary_startup;
 		pm44xx_errata |= PM_OMAP4_ROM_SMP_BOOT_ERRATUM_GICD;
 	}
 
-- 
1.7.9.5



From santosh.shilimkar at ti.com  Fri Apr  5 08:59:03 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Fri, 5 Apr 2013 18:29:03 +0530
Subject: [PATCH v3 4/4] ARM: OMAP4+: CPUidle: Consolidate idle driver for
 OMAP5 support
In-Reply-To: <1365166743-5940-1-git-send-email-santosh.shilimkar@ti.com>
References: <1365166743-5940-1-git-send-email-santosh.shilimkar@ti.com>
Message-ID: <1365166743-5940-5-git-send-email-santosh.shilimkar@ti.com>

The OMAP5 idle driver can re-use most of OMAP4 CPUidle driver
implementation. Also the next derivative SOCs are going to re-use
the MPUSS so, same driver with minor updates can be re-used.

Prepare the code so that its easier to add CPUidle support for
OMAP5 devices.

Acked-by: Nishanth Menon <nm at ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
---
 arch/arm/mach-omap2/cpuidle44xx.c |   31 ++++++++++++++++---------------
 1 file changed, 16 insertions(+), 15 deletions(-)

diff --git a/arch/arm/mach-omap2/cpuidle44xx.c b/arch/arm/mach-omap2/cpuidle44xx.c
index 767f657..ca1551a 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -1,7 +1,7 @@
 /*
- * OMAP4 CPU idle Routines
+ * OMAP4+ CPU idle Routines
  *
- * Copyright (C) 2011 Texas Instruments, Inc.
+ * Copyright (C) 2011-2013 Texas Instruments, Inc.
  * Santosh Shilimkar <santosh.shilimkar at ti.com>
  * Rajendra Nayak <rnayak at ti.com>
  *
@@ -24,13 +24,13 @@
 #include "clockdomain.h"
 
 /* Machine specific information */
-struct omap4_idle_statedata {
+struct idle_statedata {
 	u32 cpu_state;
 	u32 mpu_logic_state;
 	u32 mpu_state;
 };
 
-static struct omap4_idle_statedata omap4_idle_data[] = {
+static struct idle_statedata omap4_idle_data[] = {
 	{
 		.cpu_state = PWRDM_POWER_ON,
 		.mpu_state = PWRDM_POWER_ON,
@@ -53,11 +53,12 @@ static struct clockdomain *cpu_clkdm[NR_CPUS];
 
 static atomic_t abort_barrier;
 static bool cpu_done[NR_CPUS];
+static struct idle_statedata *state_ptr = &omap4_idle_data[0];
 
 /* Private functions */
 
 /**
- * omap4_enter_idle_coupled_[simple/coupled] - OMAP4 cpuidle entry functions
+ * omap_enter_idle_[simple/coupled] - OMAP4PLUS cpuidle entry functions
  * @dev: cpuidle device
  * @drv: cpuidle driver
  * @index: the index of state to be entered
@@ -66,7 +67,7 @@ static bool cpu_done[NR_CPUS];
  * specified low power state selected by the governor.
  * Returns the amount of time spent in the low power state.
  */
-static int omap4_enter_idle_simple(struct cpuidle_device *dev,
+static int omap_enter_idle_simple(struct cpuidle_device *dev,
 			struct cpuidle_driver *drv,
 			int index)
 {
@@ -74,11 +75,11 @@ static int omap4_enter_idle_simple(struct cpuidle_device *dev,
 	return index;
 }
 
-static int omap4_enter_idle_coupled(struct cpuidle_device *dev,
+static int omap_enter_idle_coupled(struct cpuidle_device *dev,
 			struct cpuidle_driver *drv,
 			int index)
 {
-	struct omap4_idle_statedata *cx = &omap4_idle_data[index];
+	struct idle_statedata *cx = state_ptr + index;
 	int cpu_id = smp_processor_id();
 
 	/*
@@ -168,7 +169,7 @@ static void omap_setup_broadcast_timer(void *arg)
 	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ON, &cpu);
 }
 
-static DEFINE_PER_CPU(struct cpuidle_device, omap4_idle_dev);
+static DEFINE_PER_CPU(struct cpuidle_device, omap_idle_dev);
 
 static struct cpuidle_driver omap4_idle_driver = {
 	.name				= "omap4_idle",
@@ -180,7 +181,7 @@ static struct cpuidle_driver omap4_idle_driver = {
 			.exit_latency = 2 + 2,
 			.target_residency = 5,
 			.flags = CPUIDLE_FLAG_TIME_VALID,
-			.enter = omap4_enter_idle_simple,
+			.enter = omap_enter_idle_simple,
 			.name = "C1",
 			.desc = "CPUx ON, MPUSS ON"
 		},
@@ -189,7 +190,7 @@ static struct cpuidle_driver omap4_idle_driver = {
 			.exit_latency = 328 + 440,
 			.target_residency = 960,
 			.flags = CPUIDLE_FLAG_TIME_VALID | CPUIDLE_FLAG_COUPLED,
-			.enter = omap4_enter_idle_coupled,
+			.enter = omap_enter_idle_coupled,
 			.name = "C2",
 			.desc = "CPUx OFF, MPUSS CSWR",
 		},
@@ -198,7 +199,7 @@ static struct cpuidle_driver omap4_idle_driver = {
 			.exit_latency = 460 + 518,
 			.target_residency = 1100,
 			.flags = CPUIDLE_FLAG_TIME_VALID | CPUIDLE_FLAG_COUPLED,
-			.enter = omap4_enter_idle_coupled,
+			.enter = omap_enter_idle_coupled,
 			.name = "C3",
 			.desc = "CPUx OFF, MPUSS OSWR",
 		},
@@ -210,9 +211,9 @@ static struct cpuidle_driver omap4_idle_driver = {
 /* Public functions */
 
 /**
- * omap4_idle_init - Init routine for OMAP4 idle
+ * omap4_idle_init - Init routine for OMAP4+ idle
  *
- * Registers the OMAP4 specific cpuidle driver to the cpuidle
+ * Registers the OMAP4+ specific cpuidle driver to the cpuidle
  * framework with the valid set of states.
  */
 int __init omap4_idle_init(void)
@@ -240,7 +241,7 @@ int __init omap4_idle_init(void)
 	}
 
 	for_each_cpu(cpu_id, cpu_online_mask) {
-		dev = &per_cpu(omap4_idle_dev, cpu_id);
+		dev = &per_cpu(omap_idle_dev, cpu_id);
 		dev->cpu = cpu_id;
 #ifdef CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED
 		dev->coupled_cpus = *cpu_online_mask;
-- 
1.7.9.5



From santosh.shilimkar at ti.com  Fri Apr  5 08:59:00 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Fri, 5 Apr 2013 18:29:00 +0530
Subject: [PATCH v3 1/4] ARM: OMAP4+: PM: Consolidate MPU subsystem PM code for
 re-use
In-Reply-To: <1365166743-5940-1-git-send-email-santosh.shilimkar@ti.com>
References: <1365166743-5940-1-git-send-email-santosh.shilimkar@ti.com>
Message-ID: <1365166743-5940-2-git-send-email-santosh.shilimkar@ti.com>

OMAP5 and future OMAP based SOCs has backward compatible MPUSS
IP block with OMAP4. It's programming model is mostly similar.
Hence consolidate the OMAP MPUSS code so that it can be re-used
on OMAP5 and future SOCs.

No functional change.

Acked-by: Nishanth Menon <nm at ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
---
 arch/arm/mach-omap2/omap-mpuss-lowpower.c |   62 ++++++++++++++++++++++++-----
 1 file changed, 51 insertions(+), 11 deletions(-)

diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index a27fe72..391bf2d 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -71,10 +71,43 @@ struct omap4_cpu_pm_info {
 	void (*secondary_startup)(void);
 };
 
+/**
+ * struct cpu_pm_ops - CPU pm operations
+ * @finish_suspend:	CPU suspend finisher function pointer
+ * @resume:		CPU resume function pointer
+ * @scu_prepare:	CPU Snoop Control program function pointer
+ *
+ * Structure holds functions pointer for CPU low power operations like
+ * suspend, resume and scu programming.
+ */
+struct cpu_pm_ops {
+	int (*finish_suspend)(unsigned long cpu_state);
+	void (*resume)(void);
+	void (*scu_prepare)(unsigned int cpu_id, unsigned int cpu_state);
+};
+
 static DEFINE_PER_CPU(struct omap4_cpu_pm_info, omap4_pm_info);
 static struct powerdomain *mpuss_pd;
 static void __iomem *sar_base;
 
+static int default_finish_suspend(unsigned long cpu_state)
+{
+	omap_do_wfi();
+	return 0;
+}
+
+static void dummy_cpu_resume(void)
+{}
+
+static void dummy_scu_prepare(unsigned int cpu_id, unsigned int cpu_state)
+{}
+
+struct cpu_pm_ops omap_pm_ops = {
+	.finish_suspend		= default_finish_suspend,
+	.resume			= dummy_cpu_resume,
+	.scu_prepare		= dummy_scu_prepare,
+};
+
 /*
  * Program the wakeup routine address for the CPU0 and CPU1
  * used for OFF or DORMANT wakeup.
@@ -158,11 +191,12 @@ static void save_l2x0_context(void)
 {
 	u32 val;
 	void __iomem *l2x0_base = omap4_get_l2cache_base();
-
-	val = __raw_readl(l2x0_base + L2X0_AUX_CTRL);
-	__raw_writel(val, sar_base + L2X0_AUXCTRL_OFFSET);
-	val = __raw_readl(l2x0_base + L2X0_PREFETCH_CTRL);
-	__raw_writel(val, sar_base + L2X0_PREFETCH_CTRL_OFFSET);
+	if (l2x0_base) {
+		val = __raw_readl(l2x0_base + L2X0_AUX_CTRL);
+		__raw_writel(val, sar_base + L2X0_AUXCTRL_OFFSET);
+		val = __raw_readl(l2x0_base + L2X0_PREFETCH_CTRL);
+		__raw_writel(val, sar_base + L2X0_PREFETCH_CTRL_OFFSET);
+	}
 }
 #else
 static void save_l2x0_context(void)
@@ -225,17 +259,17 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int power_state)
 
 	cpu_clear_prev_logic_pwrst(cpu);
 	pwrdm_set_next_pwrst(pm_info->pwrdm, power_state);
-	set_cpu_wakeup_addr(cpu, virt_to_phys(omap4_cpu_resume));
-	scu_pwrst_prepare(cpu, power_state);
+	set_cpu_wakeup_addr(cpu, virt_to_phys(omap_pm_ops.resume));
+	omap_pm_ops.scu_prepare(cpu, power_state);
 	l2x0_pwrst_prepare(cpu, save_state);
 
 	/*
 	 * Call low level function  with targeted low power state.
 	 */
 	if (save_state)
-		cpu_suspend(save_state, omap4_finish_suspend);
+		cpu_suspend(save_state, omap_pm_ops.finish_suspend);
 	else
-		omap4_finish_suspend(save_state);
+		omap_pm_ops.finish_suspend(save_state);
 
 	/*
 	 * Restore the CPUx power state to ON otherwise CPUx
@@ -271,14 +305,14 @@ int __cpuinit omap4_hotplug_cpu(unsigned int cpu, unsigned int power_state)
 	pwrdm_clear_all_prev_pwrst(pm_info->pwrdm);
 	pwrdm_set_next_pwrst(pm_info->pwrdm, power_state);
 	set_cpu_wakeup_addr(cpu, virt_to_phys(pm_info->secondary_startup));
-	scu_pwrst_prepare(cpu, power_state);
+	omap_pm_ops.scu_prepare(cpu, power_state);
 
 	/*
 	 * CPU never retuns back if targeted power state is OFF mode.
 	 * CPU ONLINE follows normal CPU ONLINE ptah via
 	 * omap_secondary_startup().
 	 */
-	omap4_finish_suspend(cpu_state);
+	omap_pm_ops.finish_suspend(cpu_state);
 
 	pwrdm_set_next_pwrst(pm_info->pwrdm, PWRDM_POWER_ON);
 	return 0;
@@ -355,6 +389,12 @@ int __init omap4_mpuss_init(void)
 
 	save_l2x0_context();
 
+	if (cpu_is_omap44xx()) {
+		omap_pm_ops.finish_suspend = omap4_finish_suspend;
+		omap_pm_ops.resume = omap4_cpu_resume;
+		omap_pm_ops.scu_prepare = scu_pwrst_prepare;
+	}
+
 	return 0;
 }
 
-- 
1.7.9.5



From santosh.shilimkar at ti.com  Fri Apr  5 08:59:01 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Fri, 5 Apr 2013 18:29:01 +0530
Subject: [PATCH v3 2/4] ARM: OMAP4+: PM: Consolidate OMAP4 PM code to re-use
 it for OMAP5
In-Reply-To: <1365166743-5940-1-git-send-email-santosh.shilimkar@ti.com>
References: <1365166743-5940-1-git-send-email-santosh.shilimkar@ti.com>
Message-ID: <1365166743-5940-3-git-send-email-santosh.shilimkar@ti.com>

OMAP5 has backward compatible PRCM block and it's programming
model is mostly similar to OMAP4. Same is going to be maintained
for future OMAP4 based SOCs. Hence consolidate the OMAP4 power
management code so that it can be re-used on OMAP5 and later devices.

While at it, update the kernel-doc for omap4_pm_init().

Acked-by: Nishanth Menon <nm at ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
---
 arch/arm/mach-omap2/Makefile                       |    9 +--
 arch/arm/mach-omap2/{pm44xx.c => pm_omap4plus.c}   |   58 ++++++++++++++++----
 .../mach-omap2/{sleep44xx.S => sleep_omap4plus.S}  |    0
 3 files changed, 53 insertions(+), 14 deletions(-)
 rename arch/arm/mach-omap2/{pm44xx.c => pm_omap4plus.c} (83%)
 rename arch/arm/mach-omap2/{sleep44xx.S => sleep_omap4plus.S} (100%)

diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index b068b7f..3e59895 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -35,14 +35,14 @@ obj-$(CONFIG_SOC_HAS_OMAP2_SDRC)	+= sdrc.o
 obj-$(CONFIG_SMP)			+= omap-smp.o omap-headsmp.o
 obj-$(CONFIG_HOTPLUG_CPU)		+= omap-hotplug.o
 omap-4-5-common				=  omap4-common.o omap-wakeupgen.o \
-					   sleep44xx.o
+					   sleep_omap4plus.o
 obj-$(CONFIG_ARCH_OMAP4)		+= $(omap-4-5-common)
 obj-$(CONFIG_SOC_OMAP5)			+= $(omap-4-5-common)
 
 plus_sec := $(call as-instr,.arch_extension sec,+sec)
 AFLAGS_omap-headsmp.o			:=-Wa,-march=armv7-a$(plus_sec)
 AFLAGS_omap-smc.o			:=-Wa,-march=armv7-a$(plus_sec)
-AFLAGS_sleep44xx.o			:=-Wa,-march=armv7-a$(plus_sec)
+AFLAGS_sleep_omap4plus.o		:=-Wa,-march=armv7-a$(plus_sec)
 
 # Functions loaded to SRAM
 obj-$(CONFIG_SOC_OMAP2420)		+= sram242x.o
@@ -80,11 +80,12 @@ endif
 obj-$(CONFIG_OMAP_PM_NOOP)		+= omap-pm-noop.o
 
 ifeq ($(CONFIG_PM),y)
+omap4plus-common-pm			= omap-mpuss-lowpower.o pm_omap4plus.o
 obj-$(CONFIG_ARCH_OMAP2)		+= pm24xx.o
 obj-$(CONFIG_ARCH_OMAP2)		+= sleep24xx.o
 obj-$(CONFIG_ARCH_OMAP3)		+= pm34xx.o sleep34xx.o
-obj-$(CONFIG_ARCH_OMAP4)		+= pm44xx.o omap-mpuss-lowpower.o
-obj-$(CONFIG_SOC_OMAP5)			+= omap-mpuss-lowpower.o
+obj-$(CONFIG_ARCH_OMAP4)		+= $(omap4plus-common-pm)
+obj-$(CONFIG_SOC_OMAP5)			+= $(omap4plus-common-pm)
 obj-$(CONFIG_PM_DEBUG)			+= pm-debug.o
 
 obj-$(CONFIG_POWER_AVS_OMAP)		+= sr_device.o
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm_omap4plus.c
similarity index 83%
rename from arch/arm/mach-omap2/pm44xx.c
rename to arch/arm/mach-omap2/pm_omap4plus.c
index 5ba6d88..228deca 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm_omap4plus.c
@@ -1,7 +1,7 @@
 /*
- * OMAP4 Power Management Routines
+ * OMAP4+ Power Management Routines
  *
- * Copyright (C) 2010-2011 Texas Instruments, Inc.
+ * Copyright (C) 2010-2013 Texas Instruments, Inc.
  * Rajendra Nayak <rnayak at ti.com>
  * Santosh Shilimkar <santosh.shilimkar at ti.com>
  *
@@ -135,16 +135,16 @@ static void omap_default_idle(void)
 }
 
 /**
- * omap4_pm_init - Init routine for OMAP4 PM
+ * omap4_init_static_deps - Add OMAP4 static dependencies
  *
- * Initializes all powerdomain and clockdomain target states
- * and all PRCM settings.
+ * Add needed static clockdomain dependencies on OMAP4 devices.
+ * Return: 0 on success or 'err' on failures
  */
-int __init omap4_pm_init(void)
+static inline int omap4_init_static_deps(void)
 {
-	int ret;
 	struct clockdomain *emif_clkdm, *mpuss_clkdm, *l3_1_clkdm;
 	struct clockdomain *ducati_clkdm, *l3_2_clkdm;
+	int ret = 0;
 
 	if (omap_rev() == OMAP4430_REV_ES1_0) {
 		WARN(1, "Power Management not supported on OMAP4430 ES1.0\n");
@@ -163,7 +163,7 @@ int __init omap4_pm_init(void)
 	ret = pwrdm_for_each(pwrdms_setup, NULL);
 	if (ret) {
 		pr_err("Failed to setup powerdomains\n");
-		goto err2;
+		return ret;
 	}
 
 	/*
@@ -171,6 +171,10 @@ int __init omap4_pm_init(void)
 	 * MPUSS -> L4_PER/L3_* and DUCATI -> L3_* doesn't work as
 	 * expected. The hardware recommendation is to enable static
 	 * dependencies for these to avoid system lock ups or random crashes.
+	 * The L4 wakeup depedency is added to workaround the OCP sync hardware
+	 * BUG with 32K synctimer which lead to incorrect timer value read
+	 * from the 32K counter. The BUG applies for GPTIMER1 and WDT2 which
+	 * are part of L4 wakeup clockdomain.
 	 */
 	mpuss_clkdm = clkdm_lookup("mpuss_clkdm");
 	emif_clkdm = clkdm_lookup("l3_emif_clkdm");
@@ -179,7 +183,7 @@ int __init omap4_pm_init(void)
 	ducati_clkdm = clkdm_lookup("ducati_clkdm");
 	if ((!mpuss_clkdm) || (!emif_clkdm) || (!l3_1_clkdm) ||
 		(!l3_2_clkdm) || (!ducati_clkdm))
-		goto err2;
+		return -EINVAL;
 
 	ret = clkdm_add_wkdep(mpuss_clkdm, emif_clkdm);
 	ret |= clkdm_add_wkdep(mpuss_clkdm, l3_1_clkdm);
@@ -188,9 +192,42 @@ int __init omap4_pm_init(void)
 	ret |= clkdm_add_wkdep(ducati_clkdm, l3_2_clkdm);
 	if (ret) {
 		pr_err("Failed to add MPUSS -> L3/EMIF/L4PER, DUCATI -> L3 wakeup dependency\n");
+		return -EINVAL;
+	}
+
+	return ret;
+}
+
+/**
+ * omap4_pm_init - Init routine for OMAP4+ devices
+ *
+ * Initializes all powerdomain and clockdomain target states
+ * and all PRCM settings.
+ * Return: Returns the error code returned by called functions.
+ */
+int __init omap4_pm_init(void)
+{
+	int ret = 0;
+
+	if (omap_rev() == OMAP4430_REV_ES1_0) {
+		WARN(1, "Power Management not supported on OMAP4430 ES1.0\n");
+		return -ENODEV;
+	}
+
+	pr_info("Power Management for TI OMAP4+ devices.\n");
+
+	ret = pwrdm_for_each(pwrdms_setup, NULL);
+	if (ret) {
+		pr_err("Failed to setup powerdomains.\n");
 		goto err2;
 	}
 
+	if (cpu_is_omap44xx()) {
+		ret = omap4_init_static_deps();
+		if (ret)
+			goto err2;
+	}
+
 	ret = omap4_mpuss_init();
 	if (ret) {
 		pr_err("Failed to initialise OMAP4 MPUSS\n");
@@ -206,7 +243,8 @@ int __init omap4_pm_init(void)
 	/* Overwrite the default cpu_do_idle() */
 	arm_pm_idle = omap_default_idle;
 
-	omap4_idle_init();
+	if (cpu_is_omap44xx())
+		omap4_idle_init();
 
 err2:
 	return ret;
diff --git a/arch/arm/mach-omap2/sleep44xx.S b/arch/arm/mach-omap2/sleep_omap4plus.S
similarity index 100%
rename from arch/arm/mach-omap2/sleep44xx.S
rename to arch/arm/mach-omap2/sleep_omap4plus.S
-- 
1.7.9.5



From thomas.petazzoni at free-electrons.com  Fri Apr  5 09:02:00 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Fri, 5 Apr 2013 15:02:00 +0200
Subject: mvebu-mbus: defining a DT binding
Message-ID: <20130405150200.7b6dee63@skate>

Jason, Arnd,

Now that the non-DT version of mvebu-mbus has been picked up by Jason
Cooper for 3.10, I'd like to start working on a proper DT binding for
mvebu-mbus, probably targeting 3.11. I've already started writing a bit
of code just to see how things were going, and I have a couple of
questions.

The last proposal from Jason Gunthorpe was the following one:

========================================================================

/* MAPDEF is a 2 dw value, top DW encodes the target id, bottom dword is
   usally 0. The special target id of '0' is no target/no window. */
#define MAPDEF(x,y,z) ((x << 16) | (y << 8) | z) 0
#define MAPDEF_INTERNAL MAPDEF(...)
[..]
#define PCI_MMIO_APERTURE 0xe0000000
#define PCI_IO_APERTURE 0xe8000000

mbus {
  ranges = <MAPDEF_INTERNAL 0xf1000000 0x100000
            MAPDEF_NAND     0xf4000000 0x10000
            MAPDEF_CRYPTO   0xf5000000 0x10000

 	    /* These two are *not* mbus windows but are required to
   	       model the PCI aperture abstraction. Windows are
	       allocated within these regions dynamically
               as neeed. */
            0 PCI_MMIO_APERTURE PCI_MMIO_APERTURE 0x08000000
            0 PCI_IO_APERTURE PCI_MMIO_APERTURE 0x00100000>
  #address-cells = <2>;
  [..]

  // Internal regs special target
  internal_regs at f1000000 {
       compatible = "simple-bus";
       ranges = <0x00000000 MAPDEF_INTERNAL 0x100000>;
       #address-cells = <1>;

       serial at 12000 {
              compatible = "ns16550a";
              reg = <0x12000 0x100>;
              reg-shift = <2>;
              interrupts = <33>;
        };
       [..]
  }

  // All the PCI-E targets
  pcie-controller {
     compatible = "marvell,armada-370-pcie";
     reg = <MAPDEF_INTERNAL + 0x40000 0x2000>,
           <MAPDEF_INTERNAL + 0x80000 0x2000>;
     ranges = <0x82000000 0 PCI_MMIO_APERTURE PCI_MMIO_APERTURE 0 0x08000000   /* non-prefetchable memory */
               0x81000000 0 0                 PCI_IO_APERTURE 0  0x00100000>; /* downstream I/O */
     [..]
     pcie at 0,0 {
          reg = <0x0800 0 0 0 0>;
          marvell,mbus-targets = <MAPDEF_PCIE0_MEM MAPDEF_PCIE0_IO>;
     }
  }

  // Target id 1,0x2f
  nand at 0xf4000000 {
          #address-cells = <1>;
          #size-cells = <1>;
          cle = <0>;
          ale = <1>;
          bank-width = <1>;
          compatible = "marvell,orion-nand";
          reg = <MAPDEF_NAND 0x400>;
  };

  // Target id 0x3,0x1
  crypto at f5000000 {
          reg = <MAPDEF_INTERNAL + 0x30000 0x10000>,
                <MAPDEF_CRYPTO 0x800>;
  }
}

========================================================================

It raises the following questions:

 * The address decoding windows are in fact defined by the ranges =
   <...> property of the mbus node. Here, in the example provided by
   Jason, this ranges = <...> property is part of the SoC-level .dtsi.
   However, some boards will have to add some board-specific windows
   (adjusted to the size of their NOR, or FPGA, for example).

   As far as I know, we can 'extend' an existing property in a .dts
   file, we have to completely overload it. So this means that boards
   wanting to add an additional address decoding window will have to
   copy/paste the 'ranges' property from the included .dtsi file and
   add their own entry. This is of course possible, but it doesn't look
   very nice: if a new window is added in the SoC-level .dtsi file for
   some reason, this change will have to be replicated on all the
   including .dts files that overload this ranges property.

   Is this the intended behavior?

 * I am not sure to understand why the nand, crypto and pcie-controller
   nodes are outside of the internal registers. Well, I understand it's
   because those devices need a special address decoding window. But it
   sounds strange because those devices also have internal registers
   (which is why Jason used 'MAPDEF_INTERNAL + offset' in the reg
   property).

   Is this really the desired DT binding?

 * Regarding the PCIe binding, Jason Gunthorpe suggests the use of a
   'marvell,mbus-targets' attribute so that the PCIe driver knows what
   target/attribute values to use to create the window. Currently, the
   PCIe driver uses a name (like "pcie0.3") that it gives to the
   mvebu-mbus driver, which then translates this name to the real
   target/attribute values using per-SoC tables that associate names
   (pcie0.3) with values (say 0x4 / 0x42).

   Is this marvell,mbus-targets really the suggested solution? This
   would basically mean that the entire name -> value mapping tables of
   the driver would ultimately become useless (note that I'm not
   necessarily saying it is bad, I just want to check where we are
   going before doing useless work). Of course, those tables would
   remain at the beginning, once all platforms are converted to the
   mvebu-mbus DT binding, which may take a bit of time since it requires
   quite a lot of code movement in the .dtsi/.dts files.

I already have some basic code in the mvebu-mbus driver that parses the
ranges = <...> property and creates the corresponding windows, it seems
to work fine.

Thanks,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From herbert at gondor.apana.org.au  Fri Apr  5 09:02:39 2013
From: herbert at gondor.apana.org.au (Herbert Xu)
Date: Fri, 5 Apr 2013 21:02:39 +0800
Subject: [PATCH] crypto: ux500: add missing comma
In-Reply-To: <1365163595-21926-1-git-send-email-linus.walleij@stericsson.com>
References: <1365163595-21926-1-git-send-email-linus.walleij@stericsson.com>
Message-ID: <20130405130239.GA3181@gondor.apana.org.au>

On Fri, Apr 05, 2013 at 02:06:35PM +0200, Linus Walleij wrote:
> From: Linus Walleij <linus.walleij at linaro.org>
> 
> Commit 4f31f5b19eb0418a847b989abc9ac22af1991fe2
> "PM / crypto / ux500: Use struct dev_pm_ops for power management"
> add a new line to the driver struct but missed to add a
> trailing comma, causing build errors when crypto is
> selected. This adds the missing comma.
> 
> This was not noticed until now because the crypto block
> is not in the ux500 defconfig. A separate patch will
> be submitted to fix this.
> 
> Cc: <stable at vger.kernel.org> # 3.8.x
> Cc: Rafael J. Wysocki <rjw at sisk.pl>
> Cc: Magnus Myrstedt <magnus.p.persson at stericsson.com>
> Signed-off-by: Linus Walleij <linus.walleij at linaro.org>

Patch applied.  Thanks!
-- 
Email: Herbert Xu <herbert at gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


From thomas.petazzoni at free-electrons.com  Fri Apr  5 09:06:02 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Fri, 5 Apr 2013 15:06:02 +0200
Subject: [PATCH v3] of/pci: Provide support for parsing PCI DT ranges
 property
In-Reply-To: <20130326162022.GA25625@arm.com>
References: <20130326162022.GA25625@arm.com>
Message-ID: <20130405150602.056980fb@skate>

Dear Andrew Murray,

Intentionally private e-mail. I just pinged Rob Herring on IRC about
this patch, and his comments are:

14:52 < robher> kos_tom: my original comments and what Grant want have
not been addressed. We want pci_process_bridge_OF_ranges moved out of
powerpc and microblaze.

14:55 < robher> kos_tom: I'm fine if it has an ifdef around it for now.
Just unify those 2 arches and move the code out of the arch directories.

14:59 < kos_tom> robher: but isn't that a follow-up cleanup from the
introduction of the PCI range parsing functions?

15:01 < robher> so refactor 2 identical functions first and then
combine them into 1?

I asked him to reply to the patch to mention his comments, I don't know
if he'll be doing that.

Do you have the time to rework the patch according to Rob Herring's
comments?

Thanks!

Thomas

On Tue, 26 Mar 2013 16:20:23 +0000, Andrew Murray wrote:
> This patch factors out common implementation patterns to reduce overall kernel
> code and provide a means for host bridge drivers to directly obtain struct
> resources from the DT's ranges property without relying on architecture specific
> DT handling. This will make it easier to write archiecture independent host bridge
> drivers and mitigate against further duplication of DT parsing code.
> 
> This patch can be used in the following way:
> 
> 	struct of_pci_range_parser parser;
> 	struct of_pci_range range;
> 
> 	if (of_pci_range_parser(&parser, np))
> 		; //no ranges property
> 
> 	for_each_of_pci_range(&parser, &range) {
> 
> 		/*
> 			directly access properties of the address range, e.g.:
> 			range.pci_space, range.pci_addr, range.cpu_addr,
> 			range.size, range.flags
> 
> 			alternatively obtain a struct resource, e.g.:
> 			struct resource res;
> 			of_pci_range_to_resource(&range, np, &res);
> 		*/
> 	}
> 
> Additionally the implementation takes care of adjacent ranges and merges them
> into a single range (as was the case with powerpc and microblaze).
> 
> The modifications to microblaze, mips and powerpc have not been tested.
> 
> Signed-off-by: Andrew Murray <Andrew.Murray at arm.com>
> Signed-off-by: Liviu Dudau <Liviu.Dudau at arm.com>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> ---
> Compared to "[PATCH v5 01/17] of/pci: Provide support for parsing PCI DT
> ranges property", the following changes have been made:
> 
>  * Correct use of IORESOURCE_* as suggested by Russell King
> 
>  * Improved interface and naming as suggested by Thierry Reding
> 
> Compared to the v2 sent by Andrew Murray, Thomas Petazzoni did:
> 
>  * Add a memset() on the struct of_pci_range_iter when starting the
>    for loop in for_each_pci_range(). Otherwise, with an uninitialized
>    of_pci_range_iter, of_pci_process_ranges() may crash.
> 
>  * Add parenthesis around 'res', 'np' and 'iter' in the
>    for_each_of_pci_range macro definitions. Otherwise, passing
>    something like &foobar as 'res' didn't work.
> 
>  * Rebased on top of 3.9-rc2, which required fixing a few conflicts in
>    the Microblaze code.
> 
> v2:
>   This follows on from suggestions made by Grant Likely
>   (marc.info/?l=linux-kernel&m=136079602806328)
> ---
>  arch/microblaze/pci/pci-common.c |  110 +++++++++++++------------------------
>  arch/mips/pci/pci.c              |   50 ++++++------------
>  arch/powerpc/kernel/pci-common.c |   99 ++++++++++++----------------------
>  drivers/of/address.c             |   63 ++++++++++++++++++++++
>  include/linux/of_address.h       |   42 ++++++++++++++
>  5 files changed, 194 insertions(+), 170 deletions(-)
> 
> diff --git a/arch/microblaze/pci/pci-common.c b/arch/microblaze/pci/pci-common.c
> index 9ea521e..17a7ad1 100644
> --- a/arch/microblaze/pci/pci-common.c
> +++ b/arch/microblaze/pci/pci-common.c
> @@ -658,67 +658,43 @@ void pci_resource_to_user(const struct pci_dev *dev, int bar,
>  void pci_process_bridge_OF_ranges(struct pci_controller *hose,
>  				  struct device_node *dev, int primary)
>  {
> -	const u32 *ranges;
> -	int rlen;
> -	int pna = of_n_addr_cells(dev);
> -	int np = pna + 5;
>  	int memno = 0, isa_hole = -1;
> -	u32 pci_space;
> -	unsigned long long pci_addr, cpu_addr, pci_next, cpu_next, size;
>  	unsigned long long isa_mb = 0;
>  	struct resource *res;
> +	struct of_pci_range range;
> +	struct of_pci_range_parser parser;
> +	u32 res_type;
>  
>  	pr_info("PCI host bridge %s %s ranges:\n",
>  	       dev->full_name, primary ? "(primary)" : "");
>  
> -	/* Get ranges property */
> -	ranges = of_get_property(dev, "ranges", &rlen);
> -	if (ranges == NULL)
> +	/* Check for ranges property */
> +	if (of_pci_range_parser(&parser, dev))
>  		return;
>  
> -	/* Parse it */
>  	pr_debug("Parsing ranges property...\n");
> -	while ((rlen -= np * 4) >= 0) {
> +	for_each_of_pci_range(&parser, &range) {
>  		/* Read next ranges element */
> -		pci_space = ranges[0];
> -		pci_addr = of_read_number(ranges + 1, 2);
> -		cpu_addr = of_translate_address(dev, ranges + 3);
> -		size = of_read_number(ranges + pna + 3, 2);
> -
> -		pr_debug("pci_space: 0x%08x pci_addr:0x%016llx ",
> -				pci_space, pci_addr);
> -		pr_debug("cpu_addr:0x%016llx size:0x%016llx\n",
> -					cpu_addr, size);
> -
> -		ranges += np;
> +		pr_debug("pci_space: 0x%08x pci_addr: 0x%016llx ",
> +				range.pci_space, range.pci_addr);
> +		pr_debug("cpu_addr: 0x%016llx size: 0x%016llx\n",
> +				range.cpu_addr, range.size);
>  
>  		/* If we failed translation or got a zero-sized region
>  		 * (some FW try to feed us with non sensical zero sized regions
>  		 * such as power3 which look like some kind of attempt
>  		 * at exposing the VGA memory hole)
>  		 */
> -		if (cpu_addr == OF_BAD_ADDR || size == 0)
> +		if (range.cpu_addr == OF_BAD_ADDR || range.size == 0)
>  			continue;
>  
> -		/* Now consume following elements while they are contiguous */
> -		for (; rlen >= np * sizeof(u32);
> -		     ranges += np, rlen -= np * 4) {
> -			if (ranges[0] != pci_space)
> -				break;
> -			pci_next = of_read_number(ranges + 1, 2);
> -			cpu_next = of_translate_address(dev, ranges + 3);
> -			if (pci_next != pci_addr + size ||
> -			    cpu_next != cpu_addr + size)
> -				break;
> -			size += of_read_number(ranges + pna + 3, 2);
> -		}
> -
>  		/* Act based on address space type */
>  		res = NULL;
> -		switch ((pci_space >> 24) & 0x3) {
> -		case 1:		/* PCI IO space */
> +		res_type = range.flags & IORESOURCE_TYPE_BITS;
> +		if (res_type == IORESOURCE_IO) {
>  			pr_info("  IO 0x%016llx..0x%016llx -> 0x%016llx\n",
> -			       cpu_addr, cpu_addr + size - 1, pci_addr);
> +				range.cpu_addr, range.cpu_addr + range.size - 1,
> +				range.pci_addr);
>  
>  			/* We support only one IO range */
>  			if (hose->pci_io_size) {
> @@ -726,11 +702,12 @@ void pci_process_bridge_OF_ranges(struct pci_controller *hose,
>  				continue;
>  			}
>  			/* On 32 bits, limit I/O space to 16MB */
> -			if (size > 0x01000000)
> -				size = 0x01000000;
> +			if (range.size > 0x01000000)
> +				range.size = 0x01000000;
>  
>  			/* 32 bits needs to map IOs here */
> -			hose->io_base_virt = ioremap(cpu_addr, size);
> +			hose->io_base_virt = ioremap(range.cpu_addr,
> +						range.size);
>  
>  			/* Expect trouble if pci_addr is not 0 */
>  			if (primary)
> @@ -739,19 +716,18 @@ void pci_process_bridge_OF_ranges(struct pci_controller *hose,
>  			/* pci_io_size and io_base_phys always represent IO
>  			 * space starting at 0 so we factor in pci_addr
>  			 */
> -			hose->pci_io_size = pci_addr + size;
> -			hose->io_base_phys = cpu_addr - pci_addr;
> +			hose->pci_io_size = range.pci_addr + range.size;
> +			hose->io_base_phys = range.cpu_addr - range.pci_addr;
>  
>  			/* Build resource */
>  			res = &hose->io_resource;
> -			res->flags = IORESOURCE_IO;
> -			res->start = pci_addr;
> -			break;
> -		case 2:		/* PCI Memory space */
> -		case 3:		/* PCI 64 bits Memory space */
> +			range.cpu_addr = range.pci_addr;
> +		} else if (res_type == IORESOURCE_MEM) {
>  			pr_info(" MEM 0x%016llx..0x%016llx -> 0x%016llx %s\n",
> -			       cpu_addr, cpu_addr + size - 1, pci_addr,
> -			       (pci_space & 0x40000000) ? "Prefetch" : "");
> +				range.cpu_addr, range.cpu_addr + range.size - 1,
> +				range.pci_addr,
> +				(range.pci_space & 0x40000000) ?
> +				"Prefetch" : "");
>  
>  			/* We support only 3 memory ranges */
>  			if (memno >= 3) {
> @@ -759,13 +735,13 @@ void pci_process_bridge_OF_ranges(struct pci_controller *hose,
>  				continue;
>  			}
>  			/* Handles ISA memory hole space here */
> -			if (pci_addr == 0) {
> +			if (range.pci_addr == 0) {
>  				isa_mb = cpu_addr;
>  				isa_hole = memno;
>  				if (primary || isa_mem_base == 0)
> -					isa_mem_base = cpu_addr;
> -				hose->isa_mem_phys = cpu_addr;
> -				hose->isa_mem_size = size;
> +					isa_mem_base = range.cpu_addr;
> +				hose->isa_mem_phys = range.cpu_addr;
> +				hose->isa_mem_size = range.size;
>  			}
>  
>  			/* We get the PCI/Mem offset from the first range or
> @@ -773,30 +749,22 @@ void pci_process_bridge_OF_ranges(struct pci_controller *hose,
>  			 * hole. If they don't match, bugger.
>  			 */
>  			if (memno == 0 ||
> -			    (isa_hole >= 0 && pci_addr != 0 &&
> +			    (isa_hole >= 0 && range.pci_addr != 0 &&
>  			     hose->pci_mem_offset == isa_mb))
> -				hose->pci_mem_offset = cpu_addr - pci_addr;
> -			else if (pci_addr != 0 &&
> -				 hose->pci_mem_offset != cpu_addr - pci_addr) {
> +				hose->pci_mem_offset = range.cpu_addr
> +							- range.pci_addr;
> +			else if (range.pci_addr != 0 &&
> +				 hose->pci_mem_offset != range.cpu_addr
> +							- range.pci_addr) {
>  				pr_info(" \\--> Skipped (offset mismatch) !\n");
>  				continue;
>  			}
>  
>  			/* Build resource */
>  			res = &hose->mem_resources[memno++];
> -			res->flags = IORESOURCE_MEM;
> -			if (pci_space & 0x40000000)
> -				res->flags |= IORESOURCE_PREFETCH;
> -			res->start = cpu_addr;
> -			break;
> -		}
> -		if (res != NULL) {
> -			res->name = dev->full_name;
> -			res->end = res->start + size - 1;
> -			res->parent = NULL;
> -			res->sibling = NULL;
> -			res->child = NULL;
>  		}
> +		if (res != NULL)
> +			of_pci_range_to_resource(&range, dev, res);
>  	}
>  
>  	/* If there's an ISA hole and the pci_mem_offset is -not- matching
> diff --git a/arch/mips/pci/pci.c b/arch/mips/pci/pci.c
> index 0872f12..bee49a4 100644
> --- a/arch/mips/pci/pci.c
> +++ b/arch/mips/pci/pci.c
> @@ -122,51 +122,33 @@ static void pcibios_scanbus(struct pci_controller *hose)
>  #ifdef CONFIG_OF
>  void pci_load_of_ranges(struct pci_controller *hose, struct device_node *node)
>  {
> -	const __be32 *ranges;
> -	int rlen;
> -	int pna = of_n_addr_cells(node);
> -	int np = pna + 5;
> +	struct of_pci_range_range range;
> +	struct of_pci_range_parser parser;
> +	u32 res_type;
>  
>  	pr_info("PCI host bridge %s ranges:\n", node->full_name);
> -	ranges = of_get_property(node, "ranges", &rlen);
> -	if (ranges == NULL)
> -		return;
>  	hose->of_node = node;
>  
> -	while ((rlen -= np * 4) >= 0) {
> -		u32 pci_space;
> +	if (of_pci_range_parser(&parser, node))
> +		return;
> +
> +	for_each_of_pci_range(&parser, &range) {
>  		struct resource *res = NULL;
> -		u64 addr, size;
> -
> -		pci_space = be32_to_cpup(&ranges[0]);
> -		addr = of_translate_address(node, ranges + 3);
> -		size = of_read_number(ranges + pna + 3, 2);
> -		ranges += np;
> -		switch ((pci_space >> 24) & 0x3) {
> -		case 1:		/* PCI IO space */
> +
> +		res_type = range.flags & IORESOURCE_TYPE_BITS;
> +		if (res_type == IORESOURCE_IO) {
>  			pr_info("  IO 0x%016llx..0x%016llx\n",
> -					addr, addr + size - 1);
> +				range.addr, range.addr + range.size - 1);
>  			hose->io_map_base =
> -				(unsigned long)ioremap(addr, size);
> +				(unsigned long)ioremap(range.addr, range.size);
>  			res = hose->io_resource;
> -			res->flags = IORESOURCE_IO;
> -			break;
> -		case 2:		/* PCI Memory space */
> -		case 3:		/* PCI 64 bits Memory space */
> +		} else if (res_type == IORESOURCE_MEM) {
>  			pr_info(" MEM 0x%016llx..0x%016llx\n",
> -					addr, addr + size - 1);
> +				range.addr, range.addr + range.size - 1);
>  			res = hose->mem_resource;
> -			res->flags = IORESOURCE_MEM;
> -			break;
> -		}
> -		if (res != NULL) {
> -			res->start = addr;
> -			res->name = node->full_name;
> -			res->end = res->start + size - 1;
> -			res->parent = NULL;
> -			res->sibling = NULL;
> -			res->child = NULL;
>  		}
> +		if (res != NULL)
> +			of_pci_range_to_resource(&range, node, res);
>  	}
>  }
>  #endif
> diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
> index fa12ae4..878d530 100644
> --- a/arch/powerpc/kernel/pci-common.c
> +++ b/arch/powerpc/kernel/pci-common.c
> @@ -676,61 +676,37 @@ void pci_resource_to_user(const struct pci_dev *dev, int bar,
>  void pci_process_bridge_OF_ranges(struct pci_controller *hose,
>  				  struct device_node *dev, int primary)
>  {
> -	const u32 *ranges;
> -	int rlen;
> -	int pna = of_n_addr_cells(dev);
> -	int np = pna + 5;
>  	int memno = 0, isa_hole = -1;
> -	u32 pci_space;
> -	unsigned long long pci_addr, cpu_addr, pci_next, cpu_next, size;
>  	unsigned long long isa_mb = 0;
>  	struct resource *res;
> +	struct of_pci_range range;
> +	struct of_pci_range_parser parser;
> +	u32 res_type;
>  
>  	printk(KERN_INFO "PCI host bridge %s %s ranges:\n",
>  	       dev->full_name, primary ? "(primary)" : "");
>  
> -	/* Get ranges property */
> -	ranges = of_get_property(dev, "ranges", &rlen);
> -	if (ranges == NULL)
> +	/* Check for ranges property */
> +	if (of_pci_range_parser(&parser, dev))
>  		return;
>  
> -	/* Parse it */
> -	while ((rlen -= np * 4) >= 0) {
> -		/* Read next ranges element */
> -		pci_space = ranges[0];
> -		pci_addr = of_read_number(ranges + 1, 2);
> -		cpu_addr = of_translate_address(dev, ranges + 3);
> -		size = of_read_number(ranges + pna + 3, 2);
> -		ranges += np;
> -
> +	for_each_of_pci_range(&parser, &range) {
>  		/* If we failed translation or got a zero-sized region
>  		 * (some FW try to feed us with non sensical zero sized regions
>  		 * such as power3 which look like some kind of attempt at exposing
>  		 * the VGA memory hole)
>  		 */
> -		if (cpu_addr == OF_BAD_ADDR || size == 0)
> +		if (range.cpu_addr == OF_BAD_ADDR || range.size == 0)
>  			continue;
>  
> -		/* Now consume following elements while they are contiguous */
> -		for (; rlen >= np * sizeof(u32);
> -		     ranges += np, rlen -= np * 4) {
> -			if (ranges[0] != pci_space)
> -				break;
> -			pci_next = of_read_number(ranges + 1, 2);
> -			cpu_next = of_translate_address(dev, ranges + 3);
> -			if (pci_next != pci_addr + size ||
> -			    cpu_next != cpu_addr + size)
> -				break;
> -			size += of_read_number(ranges + pna + 3, 2);
> -		}
> -
>  		/* Act based on address space type */
>  		res = NULL;
> -		switch ((pci_space >> 24) & 0x3) {
> -		case 1:		/* PCI IO space */
> +		res_type = range.flags & IORESOURCE_TYPE_BITS;
> +		if (res_type == IORESOURCE_IO) {
>  			printk(KERN_INFO
>  			       "  IO 0x%016llx..0x%016llx -> 0x%016llx\n",
> -			       cpu_addr, cpu_addr + size - 1, pci_addr);
> +				range.cpu_addr, range.cpu_addr + range.size - 1,
> +				range.pci_addr);
>  
>  			/* We support only one IO range */
>  			if (hose->pci_io_size) {
> @@ -740,11 +716,12 @@ void pci_process_bridge_OF_ranges(struct pci_controller *hose,
>  			}
>  #ifdef CONFIG_PPC32
>  			/* On 32 bits, limit I/O space to 16MB */
> -			if (size > 0x01000000)
> -				size = 0x01000000;
> +			if (range.size > 0x01000000)
> +				range.size = 0x01000000;
>  
>  			/* 32 bits needs to map IOs here */
> -			hose->io_base_virt = ioremap(cpu_addr, size);
> +			hose->io_base_virt = ioremap(range.cpu_addr,
> +						range.size);
>  
>  			/* Expect trouble if pci_addr is not 0 */
>  			if (primary)
> @@ -754,20 +731,19 @@ void pci_process_bridge_OF_ranges(struct pci_controller *hose,
>  			/* pci_io_size and io_base_phys always represent IO
>  			 * space starting at 0 so we factor in pci_addr
>  			 */
> -			hose->pci_io_size = pci_addr + size;
> -			hose->io_base_phys = cpu_addr - pci_addr;
> +			hose->pci_io_size = range.pci_addr + range.size;
> +			hose->io_base_phys = range.cpu_addr - range.pci_addr;
>  
>  			/* Build resource */
>  			res = &hose->io_resource;
> -			res->flags = IORESOURCE_IO;
> -			res->start = pci_addr;
> -			break;
> -		case 2:		/* PCI Memory space */
> -		case 3:		/* PCI 64 bits Memory space */
> +			range.cpu_addr = range.pci_addr;
> +		} else if (res_type == IORESOURCE_MEM) {
>  			printk(KERN_INFO
>  			       " MEM 0x%016llx..0x%016llx -> 0x%016llx %s\n",
> -			       cpu_addr, cpu_addr + size - 1, pci_addr,
> -			       (pci_space & 0x40000000) ? "Prefetch" : "");
> +				range.cpu_addr, range.cpu_addr + range.size - 1,
> +				range.pci_addr,
> +				(range.pci_space & 0x40000000) ?
> +				"Prefetch" : "");
>  
>  			/* We support only 3 memory ranges */
>  			if (memno >= 3) {
> @@ -776,13 +752,13 @@ void pci_process_bridge_OF_ranges(struct pci_controller *hose,
>  				continue;
>  			}
>  			/* Handles ISA memory hole space here */
> -			if (pci_addr == 0) {
> +			if (range.pci_addr == 0) {
>  				isa_mb = cpu_addr;
>  				isa_hole = memno;
>  				if (primary || isa_mem_base == 0)
> -					isa_mem_base = cpu_addr;
> -				hose->isa_mem_phys = cpu_addr;
> -				hose->isa_mem_size = size;
> +					isa_mem_base = range.cpu_addr;
> +				hose->isa_mem_phys = range.cpu_addr;
> +				hose->isa_mem_size = range.size;
>  			}
>  
>  			/* We get the PCI/Mem offset from the first range or
> @@ -790,11 +766,13 @@ void pci_process_bridge_OF_ranges(struct pci_controller *hose,
>  			 * hole. If they don't match, bugger.
>  			 */
>  			if (memno == 0 ||
> -			    (isa_hole >= 0 && pci_addr != 0 &&
> +			(isa_hole >= 0 && range.pci_addr != 0 &&
>  			     hose->pci_mem_offset == isa_mb))
> -				hose->pci_mem_offset = cpu_addr - pci_addr;
> +				hose->pci_mem_offset = range.cpu_addr -
> +							range.pci_addr;
>  			else if (pci_addr != 0 &&
> -				 hose->pci_mem_offset != cpu_addr - pci_addr) {
> +				hose->pci_mem_offset != range.cpu_addr -
> +							range.pci_addr) {
>  				printk(KERN_INFO
>  				       " \\--> Skipped (offset mismatch) !\n");
>  				continue;
> @@ -802,19 +780,10 @@ void pci_process_bridge_OF_ranges(struct pci_controller *hose,
>  
>  			/* Build resource */
>  			res = &hose->mem_resources[memno++];
> -			res->flags = IORESOURCE_MEM;
> -			if (pci_space & 0x40000000)
> -				res->flags |= IORESOURCE_PREFETCH;
> -			res->start = cpu_addr;
>  			break;
>  		}
> -		if (res != NULL) {
> -			res->name = dev->full_name;
> -			res->end = res->start + size - 1;
> -			res->parent = NULL;
> -			res->sibling = NULL;
> -			res->child = NULL;
> -		}
> +		if (res != NULL)
> +			of_pci_range_to_resource(&range, dev, res);
>  	}
>  
>  	/* If there's an ISA hole and the pci_mem_offset is -not- matching
> diff --git a/drivers/of/address.c b/drivers/of/address.c
> index 04da786..e87f45e 100644
> --- a/drivers/of/address.c
> +++ b/drivers/of/address.c
> @@ -227,6 +227,69 @@ int of_pci_address_to_resource(struct device_node *dev, int bar,
>  	return __of_address_to_resource(dev, addrp, size, flags, NULL, r);
>  }
>  EXPORT_SYMBOL_GPL(of_pci_address_to_resource);
> +
> +int of_pci_range_parser(struct of_pci_range_parser *parser,
> +			struct device_node *node)
> +{
> +	const int na = 3, ns = 2;
> +	int rlen;
> +
> +	parser->node = node;
> +	parser->pna = of_n_addr_cells(node);
> +	parser->np = parser->pna + na + ns;
> +
> +	parser->range = of_get_property(node, "ranges", &rlen);
> +	if (parser->range == NULL)
> +		return -ENOENT;
> +
> +	parser->end = parser->range + rlen / sizeof(__be32);
> +
> +	return 0;
> +}
> +
> +struct of_pci_range *of_pci_process_ranges(struct of_pci_range_parser *parser,
> +						struct of_pci_range *range)
> +{
> +	const int na = 3, ns = 2;
> +
> +	if (!parser->range || parser->range + parser->np > parser->end)
> +		return NULL;
> +
> +	range->pci_space = be32_to_cpup(parser->range);
> +	range->flags = of_bus_pci_get_flags(parser->range);
> +	range->pci_addr = of_read_number(parser->range + 1, ns);
> +	range->cpu_addr = of_translate_address(parser->node,
> +				parser->range + na);
> +	range->size = of_read_number(parser->range + parser->pna + na, ns);
> +
> +	parser->range += parser->np;
> +
> +	/* Now consume following elements while they are contiguous */
> +	while (parser->range + parser->np <= parser->end) {
> +		u32 flags, pci_space;
> +		u64 pci_addr, cpu_addr, size;
> +
> +		pci_space = be32_to_cpup(parser->range);
> +		flags = of_bus_pci_get_flags(parser->range);
> +		pci_addr = of_read_number(parser->range + 1, ns);
> +		cpu_addr = of_translate_address(parser->node,
> +				parser->range + na);
> +		size = of_read_number(parser->range + parser->pna + na, ns);
> +
> +		if (flags != range->flags)
> +			break;
> +		if (pci_addr != range->pci_addr + range->size ||
> +		    cpu_addr != range->cpu_addr + range->size)
> +			break;
> +
> +		range->size += size;
> +		parser->range += parser->np;
> +	}
> +
> +	return range;
> +}
> +EXPORT_SYMBOL_GPL(of_pci_process_ranges);
> +
>  #endif /* CONFIG_PCI */
>  
>  /*
> diff --git a/include/linux/of_address.h b/include/linux/of_address.h
> index 0506eb5..c7003a3 100644
> --- a/include/linux/of_address.h
> +++ b/include/linux/of_address.h
> @@ -4,6 +4,32 @@
>  #include <linux/errno.h>
>  #include <linux/of.h>
>  
> +struct of_pci_range_parser {
> +	struct device_node *node;
> +	const __be32 *range, *end;
> +	int np, pna;
> +};
> +
> +struct of_pci_range {
> +	u32 pci_space;
> +	u64 pci_addr;
> +	u64 cpu_addr;
> +	u64 size;
> +	u32 flags;
> +};
> +
> +#define for_each_of_pci_range(parser, range) \
> +	for (; of_pci_process_ranges(parser, range);)
> +
> +#define of_pci_range_to_resource(range, np, res) \
> +	do { \
> +		(res)->flags = (range)->flags; \
> +		(res)->start = (range)->cpu_addr; \
> +		(res)->end = (range)->cpu_addr + (range)->size - 1; \
> +		(res)->parent = (res)->child = (res)->sibling = NULL; \
> +		(res)->name = (np)->full_name; \
> +	} while (0)
> +
>  #ifdef CONFIG_OF_ADDRESS
>  extern u64 of_translate_address(struct device_node *np, const __be32 *addr);
>  extern bool of_can_translate_address(struct device_node *dev);
> @@ -27,6 +53,10 @@ static inline unsigned long pci_address_to_pio(phys_addr_t addr) { return -1; }
>  #define pci_address_to_pio pci_address_to_pio
>  #endif
>  
> +int of_pci_range_parser(struct of_pci_range_parser *parser,
> +			struct device_node *node);
> +struct of_pci_range *of_pci_process_ranges(struct of_pci_range_parser *parser,
> +						struct of_pci_range *range);
>  #else /* CONFIG_OF_ADDRESS */
>  #ifndef of_address_to_resource
>  static inline int of_address_to_resource(struct device_node *dev, int index,
> @@ -53,6 +83,18 @@ static inline const __be32 *of_get_address(struct device_node *dev, int index,
>  {
>  	return NULL;
>  }
> +
> +int of_pci_range_parser(struct of_pci_range_parser *parser,
> +			struct device_noed *node)
> +{
> +	return -1;
> +}
> +
> +struct of_pci_range *of_pci_process_ranges(struct of_pci_range_parser *parser,
> +						struct of_pci_range *range)
> +{
> +	return NULL;
> +}
>  #endif /* CONFIG_OF_ADDRESS */
>  
>  



-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From stefano.stabellini at eu.citrix.com  Fri Apr  5 09:10:24 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Fri, 5 Apr 2013 14:10:24 +0100
Subject: [PATCH 0/4 v6] arm: introduce psci_smp_ops and use them on Xen
Message-ID: <alpine.DEB.2.02.1304031239550.5078@kaball.uk.xensource.com>

Hi all,
this is the sixth version of the patch series to move virt_smp_ops out of
mach-virt and make it a generic set of reusable PSCI based smp_ops.
psci_smp_ops are preferred over the platform smp_ops.
I added a patch to introduce smp_init to this series.
In the last patch I am using smp_init to switch to psci_smp_ops if Xen
is detected on the platform.


Jon Medhurst (1):
      ARM: Enable selection of SMP operations at boot time

Stefano Stabellini (3):
      arm: introduce psci_smp_ops
      arm: prefer psci_smp_ops over mdesc->smp
      xen/arm: introduce xen_early_init, use PSCI on xen

 arch/arm/Kconfig                      |    1 +
 arch/arm/include/asm/mach/arch.h      |    3 +
 arch/arm/include/asm/psci.h           |   29 ++++++++++++++
 arch/arm/include/asm/xen/hypervisor.h |    6 +++
 arch/arm/kernel/Makefile              |    5 ++-
 arch/arm/kernel/psci.c                |    7 +--
 arch/arm/kernel/psci_smp.c            |   67 +++++++++++++++++++++++++++++++++
 arch/arm/kernel/setup.c               |   12 +++++-
 arch/arm/mach-virt/Makefile           |    1 -
 arch/arm/mach-virt/platsmp.c          |   58 ----------------------------
 arch/arm/mach-virt/virt.c             |    3 -
 arch/arm/xen/enlighten.c              |   36 ++++++++++++++----
 12 files changed, 152 insertions(+), 76 deletions(-)

    
git://xenbits.xen.org/people/sstabellini/linux-pvhvm.git 3.9-rc3-smp-6


Cheers,

Stefano


From stefano.stabellini at eu.citrix.com  Fri Apr  5 09:11:35 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Fri, 5 Apr 2013 14:11:35 +0100
Subject: [PATCH v6 4/4] xen/arm: introduce xen_early_init, use PSCI on xen
In-Reply-To: <alpine.DEB.2.02.1304031239550.5078@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1304031239550.5078@kaball.uk.xensource.com>
Message-ID: <1365167495-18508-4-git-send-email-stefano.stabellini@eu.citrix.com>

Split xen_guest_init in two functions, one of them (xen_early_init) is
going to be called very early from setup_arch.

Change machine_desc->smp_init to xen_smp_init if Xen is present on the
platform. xen_smp_init just sets smp_ops to psci_smp_ops.

XEN selects ARM_PSCI.

Changes in v6:
- xen_smp_init: call smp_set_ops only ifdef CONFIG_SMP;
- move more of the initialization to xen_guest_init;
- select ARM_PSCI if XEN.

Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
---
 arch/arm/Kconfig                      |    1 +
 arch/arm/include/asm/xen/hypervisor.h |    6 +++++
 arch/arm/kernel/setup.c               |    3 ++
 arch/arm/xen/enlighten.c              |   36 +++++++++++++++++++++++++-------
 4 files changed, 38 insertions(+), 8 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 2c3bdce..344e299 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1892,6 +1892,7 @@ config XEN
 	depends on ARM && AEABI && OF
 	depends on CPU_V7 && !CPU_V6
 	depends on !GENERIC_ATOMIC64
+	select ARM_PSCI
 	help
 	  Say Y if you want to run Linux in a Virtual Machine on Xen on ARM.
 
diff --git a/arch/arm/include/asm/xen/hypervisor.h b/arch/arm/include/asm/xen/hypervisor.h
index d7ab99a..17b3ea2 100644
--- a/arch/arm/include/asm/xen/hypervisor.h
+++ b/arch/arm/include/asm/xen/hypervisor.h
@@ -16,4 +16,10 @@ static inline enum paravirt_lazy_mode paravirt_get_lazy_mode(void)
 	return PARAVIRT_LAZY_NONE;
 }
 
+#ifdef CONFIG_XEN
+void xen_early_init(void);
+#else
+static inline void xen_early_init(void) { return; }
+#endif
+
 #endif /* _ASM_ARM_XEN_HYPERVISOR_H */
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 2f738cb..336305e 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -55,6 +55,8 @@
 #include <asm/unwind.h>
 #include <asm/memblock.h>
 #include <asm/virt.h>
+#include <asm/xen/hypervisor.h>
+#include <xen/xen.h>
 
 #include "atags.h"
 #include "tcm.h"
@@ -768,6 +770,7 @@ void __init setup_arch(char **cmdline_p)
 
 	arm_dt_init_cpu_maps();
 	psci_init();
+	xen_early_init();
 #ifdef CONFIG_SMP
 	if (is_smp()) {
 		if (mdesc->smp_init)
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index b002822..fc1bc2a 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -11,6 +11,8 @@
 #include <xen/xenbus.h>
 #include <xen/page.h>
 #include <xen/xen-ops.h>
+#include <asm/mach/arch.h>
+#include <asm/psci.h>
 #include <asm/xen/hypervisor.h>
 #include <asm/xen/hypercall.h>
 #include <linux/interrupt.h>
@@ -176,11 +178,33 @@ static int __init xen_secondary_init(unsigned int cpu)
 	return 0;
 }
 
+static void __init xen_smp_init(void)
+{
+#ifdef CONFIG_SMP
+	if (psci_smp_available())
+		smp_set_ops(&psci_smp_ops);
+#endif
+}
+
 /*
  * see Documentation/devicetree/bindings/arm/xen.txt for the
  * documentation of the Xen Device Tree format.
  */
 #define GRANT_TABLE_PHYSADDR 0
+void __init xen_early_init(void)
+{
+	struct device_node *node;
+
+	node = of_find_compatible_node(NULL, NULL, "xen,xen");
+	if (!node) {
+		pr_debug("No Xen support\n");
+		return;
+	}
+
+	xen_domain_type = XEN_HVM_DOMAIN;
+	machine_desc->smp_init = xen_smp_init;
+}
+
 static int __init xen_guest_init(void)
 {
 	struct xen_add_to_physmap xatp;
@@ -194,25 +218,21 @@ static int __init xen_guest_init(void)
 	int i;
 
 	node = of_find_compatible_node(NULL, NULL, "xen,xen");
-	if (!node) {
-		pr_debug("No Xen support\n");
-		return 0;
-	}
+
 	s = of_get_property(node, "compatible", &len);
 	if (strlen(xen_prefix) + 3  < len &&
 			!strncmp(xen_prefix, s, strlen(xen_prefix)))
 		version = s + strlen(xen_prefix);
 	if (version == NULL) {
-		pr_debug("Xen version not found\n");
-		return 0;
+		pr_warn("Xen version not found\n");
+		return -EINVAL;
 	}
 	if (of_address_to_resource(node, GRANT_TABLE_PHYSADDR, &res))
-		return 0;
+		return -EINVAL;
 	xen_hvm_resume_frames = res.start >> PAGE_SHIFT;
 	xen_events_irq = irq_of_parse_and_map(node, 0);
 	pr_info("Xen %s support found, events_irq=%d gnttab_frame_pfn=%lx\n",
 			version, xen_events_irq, xen_hvm_resume_frames);
-	xen_domain_type = XEN_HVM_DOMAIN;
 
 	xen_setup_features();
 	if (xen_feature(XENFEAT_dom0))
-- 
1.7.2.5



From stefano.stabellini at eu.citrix.com  Fri Apr  5 09:11:33 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Fri, 5 Apr 2013 14:11:33 +0100
Subject: [PATCH v6 2/4] arm: prefer psci_smp_ops over mdesc->smp
In-Reply-To: <alpine.DEB.2.02.1304031239550.5078@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1304031239550.5078@kaball.uk.xensource.com>
Message-ID: <1365167495-18508-2-git-send-email-stefano.stabellini@eu.citrix.com>

If PSCI is available on the platform, prefer psci_smp_ops over the
platform smp_ops.

Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
---
 arch/arm/kernel/setup.c |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 341efaa..dad3048 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -770,10 +770,10 @@ void __init setup_arch(char **cmdline_p)
 	psci_init();
 #ifdef CONFIG_SMP
 	if (is_smp()) {
-		if (mdesc->smp)
-			smp_set_ops(mdesc->smp);
-		else if (psci_smp_available())
+		if (psci_smp_available())
 			smp_set_ops(&psci_smp_ops);
+		else if (mdesc->smp)
+			smp_set_ops(mdesc->smp);
 		smp_init_cpus();
 	}
 #endif
-- 
1.7.2.5



From stefano.stabellini at eu.citrix.com  Fri Apr  5 09:11:34 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Fri, 5 Apr 2013 14:11:34 +0100
Subject: [PATCH v6 3/4] ARM: Enable selection of SMP operations at boot time
In-Reply-To: <alpine.DEB.2.02.1304031239550.5078@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1304031239550.5078@kaball.uk.xensource.com>
Message-ID: <1365167495-18508-3-git-send-email-stefano.stabellini@eu.citrix.com>

From: Jon Medhurst <tixy at linaro.org>

Add a new 'smp_init' hook to machine_desc so platforms can specify a
function to be used to setup smp ops instead of having a statically
defined value.

If smp_init is set, use it instead of psci_smp_ops or mdesc->smp.

Signed-off-by: Jon Medhurst <tixy at linaro.org>
Signed-off-by: Nicolas Pitre <nicolas.pitre at linaro.org>
Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
Reviewed-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
---
 arch/arm/include/asm/mach/arch.h |    3 +++
 arch/arm/kernel/setup.c          |    4 +++-
 2 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/arch/arm/include/asm/mach/arch.h b/arch/arm/include/asm/mach/arch.h
index 308ad7d..c01bf53 100644
--- a/arch/arm/include/asm/mach/arch.h
+++ b/arch/arm/include/asm/mach/arch.h
@@ -16,8 +16,10 @@ struct pt_regs;
 struct smp_operations;
 #ifdef CONFIG_SMP
 #define smp_ops(ops) (&(ops))
+#define smp_init_ops(ops) (&(ops))
 #else
 #define smp_ops(ops) (struct smp_operations *)NULL
+#define smp_init_ops(ops) (void (*)(void))NULL
 #endif
 
 struct machine_desc {
@@ -41,6 +43,7 @@ struct machine_desc {
 	unsigned char		reserve_lp2 :1;	/* never has lp2	*/
 	char			restart_mode;	/* default restart mode	*/
 	struct smp_operations	*smp;		/* SMP operations	*/
+	void			(*smp_init)(void);
 	void			(*fixup)(struct tag *, char **,
 					 struct meminfo *);
 	void			(*reserve)(void);/* reserve mem blocks	*/
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index dad3048..2f738cb 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -770,7 +770,9 @@ void __init setup_arch(char **cmdline_p)
 	psci_init();
 #ifdef CONFIG_SMP
 	if (is_smp()) {
-		if (psci_smp_available())
+		if (mdesc->smp_init)
+			(*mdesc->smp_init)();
+		else if (psci_smp_available())
 			smp_set_ops(&psci_smp_ops);
 		else if (mdesc->smp)
 			smp_set_ops(mdesc->smp);
-- 
1.7.2.5



From stefano.stabellini at eu.citrix.com  Fri Apr  5 09:11:32 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Fri, 5 Apr 2013 14:11:32 +0100
Subject: [PATCH v6 1/4] arm: introduce psci_smp_ops
In-Reply-To: <alpine.DEB.2.02.1304031239550.5078@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1304031239550.5078@kaball.uk.xensource.com>
Message-ID: <1365167495-18508-1-git-send-email-stefano.stabellini@eu.citrix.com>

Rename virt_smp_ops to psci_smp_ops and move them to arch/arm/kernel/psci_smp.c.
Remove mach-virt/platsmp.c, now unused.
Compile psci_smp if CONFIG_ARM_PSCI and CONFIG_SMP.

Add a cpu_die smp_op based on psci_ops.cpu_off.

Initialize PSCI before setting smp_ops in setup_arch.
Use psci_smp_ops if the platform doesn't provide its own smp_ops.

Changes in v6:
- fixed return values for psci_smp_available and psci_init ifndef
CONFIG_ARM_PSCI.

Changes in v5:
- document psci_operations;
- psci_init returns NULL.

Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
Acked-by: Nicolas Pitre <nico at linaro.org>
Acked-by: Rob Herring <rob.herring at calxeda.com>
Reviewed-by: Will Deacon <will.deacon at arm.com>

CC: will.deacon at arm.com
CC: arnd at arndb.de
CC: marc.zyngier at arm.com
CC: linux at arm.linux.org.uk
CC: nico at linaro.org
---
 arch/arm/include/asm/psci.h  |   29 ++++++++++++++++++
 arch/arm/kernel/Makefile     |    5 ++-
 arch/arm/kernel/psci.c       |    7 ++--
 arch/arm/kernel/psci_smp.c   |   67 ++++++++++++++++++++++++++++++++++++++++++
 arch/arm/kernel/setup.c      |    7 ++++-
 arch/arm/mach-virt/Makefile  |    1 -
 arch/arm/mach-virt/platsmp.c |   58 ------------------------------------
 arch/arm/mach-virt/virt.c    |    3 --
 8 files changed, 109 insertions(+), 68 deletions(-)
 create mode 100644 arch/arm/kernel/psci_smp.c
 delete mode 100644 arch/arm/mach-virt/platsmp.c

diff --git a/arch/arm/include/asm/psci.h b/arch/arm/include/asm/psci.h
index ce0dbe7..fa44417 100644
--- a/arch/arm/include/asm/psci.h
+++ b/arch/arm/include/asm/psci.h
@@ -23,6 +23,26 @@ struct psci_power_state {
 	u8	affinity_level;
 };
 
+/*
+ * cpu_suspend   Suspend the execution on a CPU
+ * @state        we don't currently describe affinity levels, so just pass 0.
+ * @entry_point  the first instruction to be executed on return
+ * returns 0  success, < 0 on failure
+ *
+ * cpu_off       Power down a CPU
+ * @state        we don't currently describe affinity levels, so just pass 0.
+ * no return on successful call
+ *
+ * cpu_on        Power up a CPU
+ * @cpuid        cpuid of target CPU, as from MPIDR
+ * @entry_point  the first instruction to be executed on return
+ * returns 0  success, < 0 on failure
+ *
+ * migrate       Migrate the context to a different CPU
+ * @cpuid        cpuid of target CPU, as from MPIDR
+ * returns 0  success, < 0 on failure
+ *
+ */
 struct psci_operations {
 	int (*cpu_suspend)(struct psci_power_state state,
 			   unsigned long entry_point);
@@ -32,5 +52,14 @@ struct psci_operations {
 };
 
 extern struct psci_operations psci_ops;
+extern struct smp_operations psci_smp_ops;
+
+#ifdef CONFIG_ARM_PSCI
+void psci_init(void);
+bool psci_smp_available(void);
+#else
+static inline void psci_init(void) { }
+static inline bool psci_smp_available(void) { return false; }
+#endif
 
 #endif /* __ASM_ARM_PSCI_H */
diff --git a/arch/arm/kernel/Makefile b/arch/arm/kernel/Makefile
index 5f3338e..dd9d90a 100644
--- a/arch/arm/kernel/Makefile
+++ b/arch/arm/kernel/Makefile
@@ -82,6 +82,9 @@ obj-$(CONFIG_DEBUG_LL)	+= debug.o
 obj-$(CONFIG_EARLY_PRINTK)	+= early_printk.o
 
 obj-$(CONFIG_ARM_VIRT_EXT)	+= hyp-stub.o
-obj-$(CONFIG_ARM_PSCI)		+= psci.o
+ifeq ($(CONFIG_ARM_PSCI),y)
+obj-y				+= psci.o
+obj-$(CONFIG_SMP)		+= psci_smp.o
+endif
 
 extra-y := $(head-y) vmlinux.lds
diff --git a/arch/arm/kernel/psci.c b/arch/arm/kernel/psci.c
index 3653164..4693188 100644
--- a/arch/arm/kernel/psci.c
+++ b/arch/arm/kernel/psci.c
@@ -158,7 +158,7 @@ static const struct of_device_id psci_of_match[] __initconst = {
 	{},
 };
 
-static int __init psci_init(void)
+void __init psci_init(void)
 {
 	struct device_node *np;
 	const char *method;
@@ -166,7 +166,7 @@ static int __init psci_init(void)
 
 	np = of_find_matching_node(NULL, psci_of_match);
 	if (!np)
-		return 0;
+		return;
 
 	pr_info("probing function IDs from device-tree\n");
 
@@ -206,6 +206,5 @@ static int __init psci_init(void)
 
 out_put_node:
 	of_node_put(np);
-	return 0;
+	return;
 }
-early_initcall(psci_init);
diff --git a/arch/arm/kernel/psci_smp.c b/arch/arm/kernel/psci_smp.c
new file mode 100644
index 0000000..66b0f77
--- /dev/null
+++ b/arch/arm/kernel/psci_smp.c
@@ -0,0 +1,67 @@
+/*
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Copyright (C) 2012 ARM Limited
+ *
+ * Author: Will Deacon <will.deacon at arm.com>
+ */
+
+#include <linux/init.h>
+#include <linux/irqchip/arm-gic.h>
+#include <linux/smp.h>
+#include <linux/of.h>
+
+#include <asm/psci.h>
+#include <asm/smp_plat.h>
+
+extern void secondary_startup(void);
+
+static int __cpuinit psci_boot_secondary(unsigned int cpu,
+					 struct task_struct *idle)
+{
+	if (psci_ops.cpu_on)
+		return psci_ops.cpu_on(cpu_logical_map(cpu),
+				       __pa(secondary_startup));
+	return -ENODEV;
+}
+
+static void __cpuinit psci_secondary_init(unsigned int cpu)
+{
+	gic_secondary_init(0);
+}
+
+#ifdef CONFIG_HOTPLUG_CPU
+void __ref psci_cpu_die(unsigned int cpu)
+{
+       const struct psci_power_state ps = {
+               .type = PSCI_POWER_STATE_TYPE_POWER_DOWN,
+       };
+
+       if (psci_ops.cpu_off)
+               psci_ops.cpu_off(ps);
+
+       /* We should never return */
+       panic("psci: cpu %d failed to shutdown\n", cpu);
+}
+#else
+#define psci_cpu_die NULL
+#endif
+
+bool __init psci_smp_available(void)
+{
+	/* is cpu_on available at least? */
+	return (psci_ops.cpu_on != NULL);
+}
+
+struct smp_operations __initdata psci_smp_ops = {
+	.smp_secondary_init	= psci_secondary_init,
+	.smp_boot_secondary	= psci_boot_secondary,
+	.cpu_die		= psci_cpu_die,
+};
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 3f6cbb2..341efaa 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -36,6 +36,7 @@
 #include <asm/cputype.h>
 #include <asm/elf.h>
 #include <asm/procinfo.h>
+#include <asm/psci.h>
 #include <asm/sections.h>
 #include <asm/setup.h>
 #include <asm/smp_plat.h>
@@ -766,9 +767,13 @@ void __init setup_arch(char **cmdline_p)
 	unflatten_device_tree();
 
 	arm_dt_init_cpu_maps();
+	psci_init();
 #ifdef CONFIG_SMP
 	if (is_smp()) {
-		smp_set_ops(mdesc->smp);
+		if (mdesc->smp)
+			smp_set_ops(mdesc->smp);
+		else if (psci_smp_available())
+			smp_set_ops(&psci_smp_ops);
 		smp_init_cpus();
 	}
 #endif
diff --git a/arch/arm/mach-virt/Makefile b/arch/arm/mach-virt/Makefile
index 042afc1..7ddbfa6 100644
--- a/arch/arm/mach-virt/Makefile
+++ b/arch/arm/mach-virt/Makefile
@@ -3,4 +3,3 @@
 #
 
 obj-y					:= virt.o
-obj-$(CONFIG_SMP)			+= platsmp.o
diff --git a/arch/arm/mach-virt/platsmp.c b/arch/arm/mach-virt/platsmp.c
deleted file mode 100644
index 8badaab..0000000
--- a/arch/arm/mach-virt/platsmp.c
+++ /dev/null
@@ -1,58 +0,0 @@
-/*
- * Dummy Virtual Machine - does what it says on the tin.
- *
- * Copyright (C) 2012 ARM Ltd
- * Author: Will Deacon <will.deacon at arm.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.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program.  If not, see <http://www.gnu.org/licenses/>.
- */
-
-#include <linux/init.h>
-#include <linux/smp.h>
-#include <linux/of.h>
-
-#include <linux/irqchip/arm-gic.h>
-
-#include <asm/psci.h>
-#include <asm/smp_plat.h>
-
-extern void secondary_startup(void);
-
-static void __init virt_smp_init_cpus(void)
-{
-}
-
-static void __init virt_smp_prepare_cpus(unsigned int max_cpus)
-{
-}
-
-static int __cpuinit virt_boot_secondary(unsigned int cpu,
-					 struct task_struct *idle)
-{
-	if (psci_ops.cpu_on)
-		return psci_ops.cpu_on(cpu_logical_map(cpu),
-				       __pa(secondary_startup));
-	return -ENODEV;
-}
-
-static void __cpuinit virt_secondary_init(unsigned int cpu)
-{
-	gic_secondary_init(0);
-}
-
-struct smp_operations __initdata virt_smp_ops = {
-	.smp_init_cpus		= virt_smp_init_cpus,
-	.smp_prepare_cpus	= virt_smp_prepare_cpus,
-	.smp_secondary_init	= virt_secondary_init,
-	.smp_boot_secondary	= virt_boot_secondary,
-};
diff --git a/arch/arm/mach-virt/virt.c b/arch/arm/mach-virt/virt.c
index 528c05e..c417752 100644
--- a/arch/arm/mach-virt/virt.c
+++ b/arch/arm/mach-virt/virt.c
@@ -44,12 +44,9 @@ static const char *virt_dt_match[] = {
 	NULL
 };
 
-extern struct smp_operations virt_smp_ops;
-
 DT_MACHINE_START(VIRT, "Dummy Virtual Machine")
 	.init_irq	= irqchip_init,
 	.init_time	= virt_timer_init,
 	.init_machine	= virt_init,
-	.smp		= smp_ops(virt_smp_ops),
 	.dt_compat	= virt_dt_match,
 MACHINE_END
-- 
1.7.2.5



From arnd at arndb.de  Fri Apr  5 09:17:26 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 5 Apr 2013 15:17:26 +0200
Subject: mvebu-mbus: defining a DT binding
In-Reply-To: <20130405150200.7b6dee63@skate>
References: <20130405150200.7b6dee63@skate>
Message-ID: <201304051517.26838.arnd@arndb.de>

On Friday 05 April 2013, Thomas Petazzoni wrote:

> ========================================================================
> 
> It raises the following questions:
> 
>  * The address decoding windows are in fact defined by the ranges =
>    <...> property of the mbus node. Here, in the example provided by
>    Jason, this ranges = <...> property is part of the SoC-level .dtsi.
>    However, some boards will have to add some board-specific windows
>    (adjusted to the size of their NOR, or FPGA, for example).
> 
>    As far as I know, we can 'extend' an existing property in a .dts
>    file, we have to completely overload it. So this means that boards
>    wanting to add an additional address decoding window will have to
>    copy/paste the 'ranges' property from the included .dtsi file and
>    add their own entry. This is of course possible, but it doesn't look
>    very nice: if a new window is added in the SoC-level .dtsi file for
>    some reason, this change will have to be replicated on all the
>    including .dts files that overload this ranges property.
> 
>    Is this the intended behavior?

I don't have a good solution. Maybe we can work around this with the
new preprocessor support by letting the board file provide a macro
with the actual size?

Another option would be to not map them by default but let the
mbus driver do as many mappings as possible at boot time based
on the devices that are actually present as children of the mbus
device and not marked as status="disabled".

Do you know which children of the mbus node (if any) we actually
need to access before initializing mbus?

>  * I am not sure to understand why the nand, crypto and pcie-controller
>    nodes are outside of the internal registers. Well, I understand it's
>    because those devices need a special address decoding window. But it
>    sounds strange because those devices also have internal registers
>    (which is why Jason used 'MAPDEF_INTERNAL + offset' in the reg
>    property).
> 
>    Is this really the desired DT binding?

I don't understant what "internal registers" mean in this context.

>  * Regarding the PCIe binding, Jason Gunthorpe suggests the use of a
>    'marvell,mbus-targets' attribute so that the PCIe driver knows what
>    target/attribute values to use to create the window. Currently, the
>    PCIe driver uses a name (like "pcie0.3") that it gives to the
>    mvebu-mbus driver, which then translates this name to the real
>    target/attribute values using per-SoC tables that associate names
>    (pcie0.3) with values (say 0x4 / 0x42).
> 
>    Is this marvell,mbus-targets really the suggested solution? This
>    would basically mean that the entire name -> value mapping tables of
>    the driver would ultimately become useless (note that I'm not
>    necessarily saying it is bad, I just want to check where we are
>    going before doing useless work). Of course, those tables would
>    remain at the beginning, once all platforms are converted to the
>    mvebu-mbus DT binding, which may take a bit of time since it requires
>    quite a lot of code movement in the .dtsi/.dts files.

I think it would be much nicer to express the specific mbus target using
the ranges properties of the device nodes in PCI. Maybe I'm missing what
the problem is here. 

> I already have some basic code in the mvebu-mbus driver that parses the
> ranges = <...> property and creates the corresponding windows, it seems
> to work fine.

Ok, nice! So I guess the next step is to dynamically insert additional
ranges for devices that are only mapped at run time, right?

	Arnd


From balbi at ti.com  Fri Apr  5 09:19:36 2013
From: balbi at ti.com (Felipe Balbi)
Date: Fri, 5 Apr 2013 16:19:36 +0300
Subject: [PATCH v3 1/4] ARM: OMAP4+: PM: Consolidate MPU subsystem PM
 code for re-use
In-Reply-To: <1365166743-5940-2-git-send-email-santosh.shilimkar@ti.com>
References: <1365166743-5940-1-git-send-email-santosh.shilimkar@ti.com>
 <1365166743-5940-2-git-send-email-santosh.shilimkar@ti.com>
Message-ID: <20130405131935.GM11464@arwen.pp.htv.fi>

On Fri, Apr 05, 2013 at 06:29:00PM +0530, Santosh Shilimkar wrote:
> OMAP5 and future OMAP based SOCs has backward compatible MPUSS
> IP block with OMAP4. It's programming model is mostly similar.

s/It's/Its/
s/mostly //

(similar already expands to 'almost the same' :-)

> @@ -355,6 +389,12 @@ int __init omap4_mpuss_init(void)
>  
>  	save_l2x0_context();
>  
> +	if (cpu_is_omap44xx()) {
> +		omap_pm_ops.finish_suspend = omap4_finish_suspend;
> +		omap_pm_ops.resume = omap4_cpu_resume;
> +		omap_pm_ops.scu_prepare = scu_pwrst_prepare;
> +	}

why don't you just rename omap4_* into omap_* and add cpu-based checks
there in order to handle differences between omap4 and omap5?

If implementation will be almost the same for both, you might be able to
save on some more duplication, no ?

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130405/93830beb/attachment.sig>

From thomas.petazzoni at free-electrons.com  Fri Apr  5 09:21:20 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Fri, 5 Apr 2013 15:21:20 +0200
Subject: [PATCH v3] of/pci: Provide support for parsing PCI DT ranges
 property
In-Reply-To: <20130405150602.056980fb@skate>
References: <20130326162022.GA25625@arm.com>
	<20130405150602.056980fb@skate>
Message-ID: <20130405152120.12e7dc51@skate>

Hello,

On Fri, 5 Apr 2013 15:06:02 +0200, Thomas Petazzoni wrote:

> Intentionally private e-mail. I just pinged Rob Herring on IRC about
> this patch, and his comments are:

Of course, the 'intentionally private' failed miserably. Adding Andrew
in Cc so that at least he sees my e-mail.

Sorry for the noise,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From balbi at ti.com  Fri Apr  5 09:21:50 2013
From: balbi at ti.com (Felipe Balbi)
Date: Fri, 5 Apr 2013 16:21:50 +0300
Subject: [PATCH v3 2/4] ARM: OMAP4+: PM: Consolidate OMAP4 PM code to
 re-use it for OMAP5
In-Reply-To: <1365166743-5940-3-git-send-email-santosh.shilimkar@ti.com>
References: <1365166743-5940-1-git-send-email-santosh.shilimkar@ti.com>
 <1365166743-5940-3-git-send-email-santosh.shilimkar@ti.com>
Message-ID: <20130405132150.GN11464@arwen.pp.htv.fi>

On Fri, Apr 05, 2013 at 06:29:01PM +0530, Santosh Shilimkar wrote:
> OMAP5 has backward compatible PRCM block and it's programming
> model is mostly similar to OMAP4. Same is going to be maintained
> for future OMAP4 based SOCs. Hence consolidate the OMAP4 power
> management code so that it can be re-used on OMAP5 and later devices.
> 
> While at it, update the kernel-doc for omap4_pm_init().
> 
> Acked-by: Nishanth Menon <nm at ti.com>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
> ---
>  arch/arm/mach-omap2/Makefile                       |    9 +--
>  arch/arm/mach-omap2/{pm44xx.c => pm_omap4plus.c}   |   58 ++++++++++++++++----
>  .../mach-omap2/{sleep44xx.S => sleep_omap4plus.S}  |    0
>  3 files changed, 53 insertions(+), 14 deletions(-)
>  rename arch/arm/mach-omap2/{pm44xx.c => pm_omap4plus.c} (83%)
>  rename arch/arm/mach-omap2/{sleep44xx.S => sleep_omap4plus.S} (100%)
> 
> diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
> index b068b7f..3e59895 100644
> --- a/arch/arm/mach-omap2/Makefile
> +++ b/arch/arm/mach-omap2/Makefile
> @@ -35,14 +35,14 @@ obj-$(CONFIG_SOC_HAS_OMAP2_SDRC)	+= sdrc.o
>  obj-$(CONFIG_SMP)			+= omap-smp.o omap-headsmp.o
>  obj-$(CONFIG_HOTPLUG_CPU)		+= omap-hotplug.o
>  omap-4-5-common				=  omap4-common.o omap-wakeupgen.o \
> -					   sleep44xx.o
> +					   sleep_omap4plus.o
>  obj-$(CONFIG_ARCH_OMAP4)		+= $(omap-4-5-common)
>  obj-$(CONFIG_SOC_OMAP5)			+= $(omap-4-5-common)
>  
>  plus_sec := $(call as-instr,.arch_extension sec,+sec)
>  AFLAGS_omap-headsmp.o			:=-Wa,-march=armv7-a$(plus_sec)
>  AFLAGS_omap-smc.o			:=-Wa,-march=armv7-a$(plus_sec)
> -AFLAGS_sleep44xx.o			:=-Wa,-march=armv7-a$(plus_sec)
> +AFLAGS_sleep_omap4plus.o		:=-Wa,-march=armv7-a$(plus_sec)
>  
>  # Functions loaded to SRAM
>  obj-$(CONFIG_SOC_OMAP2420)		+= sram242x.o
> @@ -80,11 +80,12 @@ endif
>  obj-$(CONFIG_OMAP_PM_NOOP)		+= omap-pm-noop.o
>  
>  ifeq ($(CONFIG_PM),y)
> +omap4plus-common-pm			= omap-mpuss-lowpower.o pm_omap4plus.o
>  obj-$(CONFIG_ARCH_OMAP2)		+= pm24xx.o
>  obj-$(CONFIG_ARCH_OMAP2)		+= sleep24xx.o
>  obj-$(CONFIG_ARCH_OMAP3)		+= pm34xx.o sleep34xx.o
> -obj-$(CONFIG_ARCH_OMAP4)		+= pm44xx.o omap-mpuss-lowpower.o
> -obj-$(CONFIG_SOC_OMAP5)			+= omap-mpuss-lowpower.o
> +obj-$(CONFIG_ARCH_OMAP4)		+= $(omap4plus-common-pm)
> +obj-$(CONFIG_SOC_OMAP5)			+= $(omap4plus-common-pm)
>  obj-$(CONFIG_PM_DEBUG)			+= pm-debug.o
>  
>  obj-$(CONFIG_POWER_AVS_OMAP)		+= sr_device.o
> diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm_omap4plus.c
> similarity index 83%
> rename from arch/arm/mach-omap2/pm44xx.c
> rename to arch/arm/mach-omap2/pm_omap4plus.c
> index 5ba6d88..228deca 100644
> --- a/arch/arm/mach-omap2/pm44xx.c
> +++ b/arch/arm/mach-omap2/pm_omap4plus.c
> @@ -1,7 +1,7 @@
>  /*
> - * OMAP4 Power Management Routines
> + * OMAP4+ Power Management Routines
>   *
> - * Copyright (C) 2010-2011 Texas Instruments, Inc.
> + * Copyright (C) 2010-2013 Texas Instruments, Inc.
>   * Rajendra Nayak <rnayak at ti.com>
>   * Santosh Shilimkar <santosh.shilimkar at ti.com>
>   *
> @@ -135,16 +135,16 @@ static void omap_default_idle(void)
>  }
>  
>  /**
> - * omap4_pm_init - Init routine for OMAP4 PM
> + * omap4_init_static_deps - Add OMAP4 static dependencies
>   *
> - * Initializes all powerdomain and clockdomain target states
> - * and all PRCM settings.
> + * Add needed static clockdomain dependencies on OMAP4 devices.
> + * Return: 0 on success or 'err' on failures
>   */
> -int __init omap4_pm_init(void)
> +static inline int omap4_init_static_deps(void)

you can let compiler inline this if it chooses to, right ?? Otherwise,
if you really want to make sure this will be inlined, you could(should?)
be using __always_inline.

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130405/fa4fb3f8/attachment.sig>

From nicolas.pitre at linaro.org  Fri Apr  5 09:30:58 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Fri, 5 Apr 2013 09:30:58 -0400 (EDT)
Subject: [GIT PULL] Multi Cluster Power Management infrastructure
In-Reply-To: <20130405094159.GH17995@n2100.arm.linux.org.uk>
References: <alpine.LFD.2.03.1303251219530.1372@syhkavp.arg>
 <20130328134808.GD16765@e102568-lin.cambridge.arm.com>
 <alpine.LFD.2.03.1304022258430.1171@syhkavp.arg>
 <alpine.LFD.2.03.1304042138160.1171@syhkavp.arg>
 <20130405094159.GH17995@n2100.arm.linux.org.uk>
Message-ID: <alpine.LFD.2.03.1304050854590.1171@syhkavp.arg>

On Fri, 5 Apr 2013, Russell King - ARM Linux wrote:

> Right, you force my hand.  None of the stuff below should be public, but
> you give me no choice now but to publically defend myself against your
> allegations.
> 
> The reason that I haven't merged it is that:
> 
> 1. At the beginning of December, when the TI situation looked very
>    uncertain, I approached Linaro to see whether it was possible to
>    sort out a relationship with them.  Linaro were enthusiastic.
> 
> 2. It took weeks for anything to really happen - indeed, the first
>    sign of any kind of idea for any work was first mentioned at the
>    beginning of January, the day that Nicolas posted these patches
>    for review.  The work was going to be to review these patches.

I don't think the review of precisely those patches was put in any 
contract proposal.  That would have been way too limiting, and a waste 
of your competence.  But that shouldn't matter in this case as the 
problem lays elsewhere as far as the community is concerned.

> 3. As that was going to be the subject of the work, and there was no
>    arrangement in place, I actively avoided reviewing these changes.

That is unacceptable.  You are recognized as the ARM kernel maintainer.  
This role depends on the trust that the community puts in you, and _not_ 
based on any contractual arrangement with any company, be that Linaro or 
any other.

Patches are rejected or accepted in the mainline kernel based on their 
technical merits, period. As the ARM kernel upstream maintainer, you 
cannot use your position to block the merging of some patches based on a 
private matter between you and Linaro.  This is unethical and a direct 
conflict of interest.

And, as I've told you in private many times now, the work resulting in 
those patches is something of the past.  The world has moved on.  Any 
work assigned to you by contract from Linaro would be about something 
else, something new, and not something that used to be new a year ago.  
In fact Linaro is willing to give you money and give you full freedom to 
let you decide to work on anything you want if that improves Linux 
support on ARM.  Why this doesn't sounds good to you is beyond my 
understanding.

Anyway... The fact that quality people did review the MCPM patches 
extensively should be enough for trust to be applied in the decision to 
merge those patches now.  They've been circulated in public for 3 months 
now, they've missed a merge window already, I'm not going to accept they 
miss another one for non technical reasons.

[ legitimate but private issues with no relevance to the community 
  process skipped ]

> Now, I'm currently on holiday.  I'm going to be on holday until after
> mid-April.  I'm not pulling anything until then.  I'm not applying anything
> until then.  I'm not even reading this mailbox - and given current mail
> rates at 300-400 messages per day, I will *not* be reading back over a
> fortnights worth of email.

That is also unacceptable.  Again, you are the appointed ARM kernel 
maintainer.  You have to plan a backup when you are away.  If the load 
is too much, you have to delegate.  They do it for the X86 architecture 
with 3 maintainers despite the fact that the X86 architecture is much 
less active in that regard.

Part of your role as a maintainer is to ensure the community process is 
working well, not to obstruct to it.  And that _independently_ of any 
private engagement you might or might not have with any company.


Nicolas


From arnd at arndb.de  Fri Apr  5 09:32:45 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 5 Apr 2013 15:32:45 +0200
Subject: linux-next: manual merge of the arm-soc tree with the xilinx tree
In-Reply-To: <CAHTX3d+PZ=G6JYBo7Hvqe=G77udaCFJ4pD4z_sQw_FDGP-xt=A@mail.gmail.com>
References: <20130405153335.baf29606a97b1bee415f3546@canb.auug.org.au>
 <201304051409.37708.arnd@arndb.de>
 <CAHTX3d+PZ=G6JYBo7Hvqe=G77udaCFJ4pD4z_sQw_FDGP-xt=A@mail.gmail.com>
Message-ID: <201304051532.46156.arnd@arndb.de>

On Friday 05 April 2013, Michal Simek wrote:
> > > Interesting. I rebased my arm-next branch based on 3.9-rc5
> > > with some Rob's + one Arnd patch from arm-soc - clksrc/cleanup branch.
> > >
> > > I will fix my arm-next branch.
> >
> > The for-next branch in arm-soc is not stable, you should never base
> > anything on it. If you depend on some stable branch, that is in arm-soc,
> > then use just that branch, not one of the next/* branches or for-next.
> >
> 
> I haven't based on arm-soc for-next branch my arm-next branch.
> I just took all patches I need for zynq and done git rebase v3.5-rc5.
> Which caused that I have became commuter of that 4 patches
> and there is probably any conflict between your for-next branch and
> clksrc/cleanup
> which you have resolved in for-next branch.

Ah, I see. That was actually my fault, I'm sorry for causing trouble
here and then accusing you instead.

> And because of my rebase sha1 are different that's why Stephen
> had problem with it.
> I have changed my arm-next branch and will see on Monday if Stephen
> will report any problem or not.

Ok, thanks!

	Arnd


From santosh.shilimkar at ti.com  Fri Apr  5 09:35:22 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Fri, 5 Apr 2013 19:05:22 +0530
Subject: [PATCH v3 2/4] ARM: OMAP4+: PM: Consolidate OMAP4 PM code to
 re-use it for OMAP5
In-Reply-To: <20130405132150.GN11464@arwen.pp.htv.fi>
References: <1365166743-5940-1-git-send-email-santosh.shilimkar@ti.com>
 <1365166743-5940-3-git-send-email-santosh.shilimkar@ti.com>
 <20130405132150.GN11464@arwen.pp.htv.fi>
Message-ID: <515ED31A.3000307@ti.com>

On Friday 05 April 2013 06:51 PM, Felipe Balbi wrote:
> On Fri, Apr 05, 2013 at 06:29:01PM +0530, Santosh Shilimkar wrote:
>> OMAP5 has backward compatible PRCM block and it's programming
>> model is mostly similar to OMAP4. Same is going to be maintained
>> for future OMAP4 based SOCs. Hence consolidate the OMAP4 power
>> management code so that it can be re-used on OMAP5 and later devices.
>>
>> While at it, update the kernel-doc for omap4_pm_init().
>>
>> Acked-by: Nishanth Menon <nm at ti.com>
>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
>> ---
>>  arch/arm/mach-omap2/Makefile                       |    9 +--
>>  arch/arm/mach-omap2/{pm44xx.c => pm_omap4plus.c}   |   58 ++++++++++++++++----
>>  .../mach-omap2/{sleep44xx.S => sleep_omap4plus.S}  |    0
>>  3 files changed, 53 insertions(+), 14 deletions(-)
>>  rename arch/arm/mach-omap2/{pm44xx.c => pm_omap4plus.c} (83%)
>>  rename arch/arm/mach-omap2/{sleep44xx.S => sleep_omap4plus.S} (100%)
>>
>> diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
>> index b068b7f..3e59895 100644
>> --- a/arch/arm/mach-omap2/Makefile
>> +++ b/arch/arm/mach-omap2/Makefile
>> @@ -35,14 +35,14 @@ obj-$(CONFIG_SOC_HAS_OMAP2_SDRC)	+= sdrc.o
>>  obj-$(CONFIG_SMP)			+= omap-smp.o omap-headsmp.o
>>  obj-$(CONFIG_HOTPLUG_CPU)		+= omap-hotplug.o
>>  omap-4-5-common				=  omap4-common.o omap-wakeupgen.o \
>> -					   sleep44xx.o
>> +					   sleep_omap4plus.o
>>  obj-$(CONFIG_ARCH_OMAP4)		+= $(omap-4-5-common)
>>  obj-$(CONFIG_SOC_OMAP5)			+= $(omap-4-5-common)
>>  
>>  plus_sec := $(call as-instr,.arch_extension sec,+sec)
>>  AFLAGS_omap-headsmp.o			:=-Wa,-march=armv7-a$(plus_sec)
>>  AFLAGS_omap-smc.o			:=-Wa,-march=armv7-a$(plus_sec)
>> -AFLAGS_sleep44xx.o			:=-Wa,-march=armv7-a$(plus_sec)
>> +AFLAGS_sleep_omap4plus.o		:=-Wa,-march=armv7-a$(plus_sec)
>>  
>>  # Functions loaded to SRAM
>>  obj-$(CONFIG_SOC_OMAP2420)		+= sram242x.o
>> @@ -80,11 +80,12 @@ endif
>>  obj-$(CONFIG_OMAP_PM_NOOP)		+= omap-pm-noop.o
>>  
>>  ifeq ($(CONFIG_PM),y)
>> +omap4plus-common-pm			= omap-mpuss-lowpower.o pm_omap4plus.o
>>  obj-$(CONFIG_ARCH_OMAP2)		+= pm24xx.o
>>  obj-$(CONFIG_ARCH_OMAP2)		+= sleep24xx.o
>>  obj-$(CONFIG_ARCH_OMAP3)		+= pm34xx.o sleep34xx.o
>> -obj-$(CONFIG_ARCH_OMAP4)		+= pm44xx.o omap-mpuss-lowpower.o
>> -obj-$(CONFIG_SOC_OMAP5)			+= omap-mpuss-lowpower.o
>> +obj-$(CONFIG_ARCH_OMAP4)		+= $(omap4plus-common-pm)
>> +obj-$(CONFIG_SOC_OMAP5)			+= $(omap4plus-common-pm)
>>  obj-$(CONFIG_PM_DEBUG)			+= pm-debug.o
>>  
>>  obj-$(CONFIG_POWER_AVS_OMAP)		+= sr_device.o
>> diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm_omap4plus.c
>> similarity index 83%
>> rename from arch/arm/mach-omap2/pm44xx.c
>> rename to arch/arm/mach-omap2/pm_omap4plus.c
>> index 5ba6d88..228deca 100644
>> --- a/arch/arm/mach-omap2/pm44xx.c
>> +++ b/arch/arm/mach-omap2/pm_omap4plus.c
>> @@ -1,7 +1,7 @@
>>  /*
>> - * OMAP4 Power Management Routines
>> + * OMAP4+ Power Management Routines
>>   *
>> - * Copyright (C) 2010-2011 Texas Instruments, Inc.
>> + * Copyright (C) 2010-2013 Texas Instruments, Inc.
>>   * Rajendra Nayak <rnayak at ti.com>
>>   * Santosh Shilimkar <santosh.shilimkar at ti.com>
>>   *
>> @@ -135,16 +135,16 @@ static void omap_default_idle(void)
>>  }
>>  
>>  /**
>> - * omap4_pm_init - Init routine for OMAP4 PM
>> + * omap4_init_static_deps - Add OMAP4 static dependencies
>>   *
>> - * Initializes all powerdomain and clockdomain target states
>> - * and all PRCM settings.
>> + * Add needed static clockdomain dependencies on OMAP4 devices.
>> + * Return: 0 on success or 'err' on failures
>>   */
>> -int __init omap4_pm_init(void)
>> +static inline int omap4_init_static_deps(void)
> 
> you can let compiler inline this if it chooses to, right ?? Otherwise,
> if you really want to make sure this will be inlined, you could(should?)
> be using __always_inline.
> 
Compilers are smart now so that fine. 


From nm at ti.com  Fri Apr  5 09:35:11 2013
From: nm at ti.com (Nishanth Menon)
Date: Fri, 5 Apr 2013 08:35:11 -0500
Subject: [PATCH v3 1/4] ARM: OMAP4+: PM: Consolidate MPU subsystem PM
 code for re-use
In-Reply-To: <20130405131935.GM11464@arwen.pp.htv.fi>
References: <1365166743-5940-1-git-send-email-santosh.shilimkar@ti.com>
 <1365166743-5940-2-git-send-email-santosh.shilimkar@ti.com>
 <20130405131935.GM11464@arwen.pp.htv.fi>
Message-ID: <20130405133511.GA4143@kahuna>

On 16:19-20130405, Felipe Balbi wrote:
> On Fri, Apr 05, 2013 at 06:29:00PM +0530, Santosh Shilimkar wrote:
> > OMAP5 and future OMAP based SOCs has backward compatible MPUSS
> > IP block with OMAP4. It's programming model is mostly similar.
> 
> s/It's/Its/
> s/mostly //
> 
> (similar already expands to 'almost the same' :-)
> 
> > @@ -355,6 +389,12 @@ int __init omap4_mpuss_init(void)
> >  
> >  	save_l2x0_context();
> >  
> > +	if (cpu_is_omap44xx()) {
> > +		omap_pm_ops.finish_suspend = omap4_finish_suspend;
> > +		omap_pm_ops.resume = omap4_cpu_resume;
> > +		omap_pm_ops.scu_prepare = scu_pwrst_prepare;
> > +	}
> 
> why don't you just rename omap4_* into omap_* and add cpu-based checks
> there in order to handle differences between omap4 and omap5?
> 
> If implementation will be almost the same for both, you might be able to
> save on some more duplication, no ?
Jeez NO! finish_suspend is assembly, further, it is the hottest path in
cpuidle framework - for every WFI we invoke it. we definitely dont want
to add more overhead beyond what is necessary.
> 
> -- 
> balbi



-- 
Regards,
Nishanth Menon


From thomas.abraham at linaro.org  Fri Apr  5 09:53:35 2013
From: thomas.abraham at linaro.org (Thomas Abraham)
Date: Fri, 05 Apr 2013 19:23:35 +0530
Subject: [PATCH v3] mmc: dw_mmc: let device core setup the default pin
 configuration
Message-ID: <1365170015-3009-1-git-send-email-thomas.abraham@linaro.org>

With device core now able to setup the default pin configuration,
the pin configuration code based on the deprecated Samsung specific
gpio bindings is removed.

Signed-off-by: Thomas Abraham <thomas.abraham at linaro.org>
---
Changes since v2:
- Changed patch subject from "mmc: dwmmc: let..." to "mmc: dw_mmc: let..."
- Rebased to Chris's latest mmc-next branch.

 drivers/mmc/host/dw_mmc-exynos.c |   38 --------------------------------------
 drivers/mmc/host/dw_mmc.c        |   12 ++----------
 drivers/mmc/host/dw_mmc.h        |    3 ---
 3 files changed, 2 insertions(+), 51 deletions(-)

diff --git a/drivers/mmc/host/dw_mmc-exynos.c b/drivers/mmc/host/dw_mmc-exynos.c
index c7f0976..f013e7e 100644
--- a/drivers/mmc/host/dw_mmc-exynos.c
+++ b/drivers/mmc/host/dw_mmc-exynos.c
@@ -152,43 +152,6 @@ static int dw_mci_exynos_parse_dt(struct dw_mci *host)
 	return 0;
 }
 
-static int dw_mci_exynos_setup_bus(struct dw_mci *host,
-				struct device_node *slot_np, u8 bus_width)
-{
-	int idx, gpio, ret;
-
-	if (!slot_np)
-		return -EINVAL;
-
-	/* cmd + clock + bus-width pins */
-	for (idx = 0; idx < NUM_PINS(bus_width); idx++) {
-		gpio = of_get_gpio(slot_np, idx);
-		if (!gpio_is_valid(gpio)) {
-			dev_err(host->dev, "invalid gpio: %d\n", gpio);
-			return -EINVAL;
-		}
-
-		ret = devm_gpio_request(host->dev, gpio, "dw-mci-bus");
-		if (ret) {
-			dev_err(host->dev, "gpio [%d] request failed\n", gpio);
-			return -EBUSY;
-		}
-	}
-
-	if (host->pdata->quirks & DW_MCI_QUIRK_BROKEN_CARD_DETECTION)
-		return 0;
-
-	gpio = of_get_named_gpio(slot_np, "samsung,cd-pinmux-gpio", 0);
-	if (gpio_is_valid(gpio)) {
-		if (devm_gpio_request(host->dev, gpio, "dw-mci-cd"))
-			dev_err(host->dev, "gpio [%d] request failed\n", gpio);
-	} else {
-		dev_info(host->dev, "cd gpio not available");
-	}
-
-	return 0;
-}
-
 /* Common capabilities of Exynos4/Exynos5 SoC */
 static unsigned long exynos_dwmmc_caps[4] = {
 	MMC_CAP_UHS_DDR50 | MMC_CAP_1_8V_DDR |
@@ -205,7 +168,6 @@ static const struct dw_mci_drv_data exynos_drv_data = {
 	.prepare_command	= dw_mci_exynos_prepare_command,
 	.set_ios		= dw_mci_exynos_set_ios,
 	.parse_dt		= dw_mci_exynos_parse_dt,
-	.setup_bus		= dw_mci_exynos_setup_bus,
 };
 
 static const struct of_device_id dw_mci_exynos_match[] = {
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index a443820..2ed9989 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -1945,14 +1945,6 @@ static int dw_mci_init_slot(struct dw_mci *host, unsigned int id)
 	else
 		bus_width = 1;
 
-	if (drv_data && drv_data->setup_bus) {
-		struct device_node *slot_np;
-		slot_np = dw_mci_of_find_slot_node(host->dev, slot->id);
-		ret = drv_data->setup_bus(host, slot_np, bus_width);
-		if (ret)
-			goto err_setup_bus;
-	}
-
 	switch (bus_width) {
 	case 8:
 		mmc->caps |= MMC_CAP_8_BIT_DATA;
@@ -2002,7 +1994,7 @@ static int dw_mci_init_slot(struct dw_mci *host, unsigned int id)
 
 	ret = mmc_add_host(mmc);
 	if (ret)
-		goto err_setup_bus;
+		goto err_add_host;
 
 #if defined(CONFIG_DEBUG_FS)
 	dw_mci_init_debugfs(slot);
@@ -2019,7 +2011,7 @@ static int dw_mci_init_slot(struct dw_mci *host, unsigned int id)
 
 	return 0;
 
-err_setup_bus:
+err_add_host:
 	mmc_free_host(mmc);
 	return -EINVAL;
 }
diff --git a/drivers/mmc/host/dw_mmc.h b/drivers/mmc/host/dw_mmc.h
index 53b8fd9..0b74189 100644
--- a/drivers/mmc/host/dw_mmc.h
+++ b/drivers/mmc/host/dw_mmc.h
@@ -190,7 +190,6 @@ extern int dw_mci_resume(struct dw_mci *host);
  * @prepare_command: handle CMD register extensions.
  * @set_ios: handle bus specific extensions.
  * @parse_dt: parse implementation specific device tree properties.
- * @setup_bus: initialize io-interface
  *
  * Provide controller implementation specific extensions. The usage of this
  * data structure is fully optional and usage of each member in this structure
@@ -203,7 +202,5 @@ struct dw_mci_drv_data {
 	void		(*prepare_command)(struct dw_mci *host, u32 *cmdr);
 	void		(*set_ios)(struct dw_mci *host, struct mmc_ios *ios);
 	int		(*parse_dt)(struct dw_mci *host);
-	int		(*setup_bus)(struct dw_mci *host,
-				struct device_node *slot_np, u8 bus_width);
 };
 #endif /* _DW_MMC_H_ */
-- 
1.6.6.rc2



From santosh.shilimkar at ti.com  Fri Apr  5 09:37:57 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Fri, 5 Apr 2013 19:07:57 +0530
Subject: [PATCH v3 1/4] ARM: OMAP4+: PM: Consolidate MPU subsystem PM
 code for re-use
In-Reply-To: <20130405131935.GM11464@arwen.pp.htv.fi>
References: <1365166743-5940-1-git-send-email-santosh.shilimkar@ti.com>
 <1365166743-5940-2-git-send-email-santosh.shilimkar@ti.com>
 <20130405131935.GM11464@arwen.pp.htv.fi>
Message-ID: <515ED3B5.2040502@ti.com>

On Friday 05 April 2013 06:49 PM, Felipe Balbi wrote:
> On Fri, Apr 05, 2013 at 06:29:00PM +0530, Santosh Shilimkar wrote:
>> OMAP5 and future OMAP based SOCs has backward compatible MPUSS
>> IP block with OMAP4. It's programming model is mostly similar.
> 
> s/It's/Its/
> s/mostly //
> 
> (similar already expands to 'almost the same' :-)
> 
>> @@ -355,6 +389,12 @@ int __init omap4_mpuss_init(void)
>>  
>>  	save_l2x0_context();
>>  
>> +	if (cpu_is_omap44xx()) {
>> +		omap_pm_ops.finish_suspend = omap4_finish_suspend;
>> +		omap_pm_ops.resume = omap4_cpu_resume;
>> +		omap_pm_ops.scu_prepare = scu_pwrst_prepare;
>> +	}
> 
> why don't you just rename omap4_* into omap_* and add cpu-based checks
> there in order to handle differences between omap4 and omap5?
> 
The whole idea is to handle all these SOC specific stuff in init and
not sprinkle the checks in runtime code.

> If implementation will be almost the same for both, you might be able to
> save on some more duplication, no ?
> 
The implementation is not same and hence. If it was same, I wouldn't
have introduced function pointers :)

Regards,
Santosh


From santosh.shilimkar at ti.com  Fri Apr  5 09:39:19 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Fri, 5 Apr 2013 19:09:19 +0530
Subject: [PATCH v3 1/4] ARM: OMAP4+: PM: Consolidate MPU subsystem PM
 code for re-use
In-Reply-To: <20130405133511.GA4143@kahuna>
References: <1365166743-5940-1-git-send-email-santosh.shilimkar@ti.com>
 <1365166743-5940-2-git-send-email-santosh.shilimkar@ti.com>
 <20130405131935.GM11464@arwen.pp.htv.fi> <20130405133511.GA4143@kahuna>
Message-ID: <515ED407.5000609@ti.com>

On Friday 05 April 2013 07:05 PM, Nishanth Menon wrote:
> On 16:19-20130405, Felipe Balbi wrote:
>> On Fri, Apr 05, 2013 at 06:29:00PM +0530, Santosh Shilimkar wrote:
>>> OMAP5 and future OMAP based SOCs has backward compatible MPUSS
>>> IP block with OMAP4. It's programming model is mostly similar.
>>
>> s/It's/Its/
>> s/mostly //
>>
>> (similar already expands to 'almost the same' :-)
>>
>>> @@ -355,6 +389,12 @@ int __init omap4_mpuss_init(void)
>>>  
>>>  	save_l2x0_context();
>>>  
>>> +	if (cpu_is_omap44xx()) {
>>> +		omap_pm_ops.finish_suspend = omap4_finish_suspend;
>>> +		omap_pm_ops.resume = omap4_cpu_resume;
>>> +		omap_pm_ops.scu_prepare = scu_pwrst_prepare;
>>> +	}
>>
>> why don't you just rename omap4_* into omap_* and add cpu-based checks
>> there in order to handle differences between omap4 and omap5?
>>
>> If implementation will be almost the same for both, you might be able to
>> save on some more duplication, no ?
> Jeez NO! finish_suspend is assembly, further, it is the hottest path in
> cpuidle framework - for every WFI we invoke it. we definitely dont want
> to add more overhead beyond what is necessary.
:-)
Our emails crossed. I just said the same thing in other words.

Regards,
Santosh 



From thomas.petazzoni at free-electrons.com  Fri Apr  5 09:51:49 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Fri, 5 Apr 2013 15:51:49 +0200
Subject: mvebu-mbus: defining a DT binding
In-Reply-To: <201304051517.26838.arnd@arndb.de>
References: <20130405150200.7b6dee63@skate> <201304051517.26838.arnd@arndb.de>
Message-ID: <20130405155149.0b00a592@skate>

Dear Arnd Bergmann,

On Fri, 5 Apr 2013 15:17:26 +0200, Arnd Bergmann wrote:
> On Friday 05 April 2013, Thomas Petazzoni wrote:
> 
> > ========================================================================
> > 
> > It raises the following questions:
> > 
> >  * The address decoding windows are in fact defined by the ranges =
> >    <...> property of the mbus node. Here, in the example provided by
> >    Jason, this ranges = <...> property is part of the SoC-level .dtsi.
> >    However, some boards will have to add some board-specific windows
> >    (adjusted to the size of their NOR, or FPGA, for example).
> > 
> >    As far as I know, we can 'extend' an existing property in a .dts
> >    file, we have to completely overload it. So this means that boards
> >    wanting to add an additional address decoding window will have to
> >    copy/paste the 'ranges' property from the included .dtsi file and
> >    add their own entry. This is of course possible, but it doesn't look
> >    very nice: if a new window is added in the SoC-level .dtsi file for
> >    some reason, this change will have to be replicated on all the
> >    including .dts files that overload this ranges property.
> > 
> >    Is this the intended behavior?
> 
> I don't have a good solution. Maybe we can work around this with the
> new preprocessor support by letting the board file provide a macro
> with the actual size?

The thing is that we don't know how many NOR, FPGA and other device-bus
devices the board will use. So you mean we should define a size of 0 by
default (in which case no window would be created), and if a board
overrides that with a non-zero value, then we would use that one?

I don't find the solution of using pre-processor magic to do that very
pretty. The 'inheritance' property of the DT normally solves that
nicely... but since we're encoding everything with ranges, it doesn't
work very well.

Maybe the 'ranges' property should not contain any static window
definition at all, and instead some other DT properties would define
the windows, and the 'ranges' property would be reconstructed by the
mbus driver at initialization time? I admit I would really prefer if
windows were described by name ("pcie0.0", "devbus-cs0", "bootrom")
instead of by encoding the target/attribute values in the DT. This
would make the DT a lot easier to read, understand and modify by people
porting the kernel to new boards. But using a name is not possible in
the 'ranges' property.

> Another option would be to not map them by default but let the
> mbus driver do as many mappings as possible at boot time based
> on the devices that are actually present as children of the mbus
> device and not marked as status="disabled".

So the 'ranges' property would be more or less empty? How would the
mbus driver know the target/attribute values for each window?

> Do you know which children of the mbus node (if any) we actually
> need to access before initializing mbus?

I'm sorry but I don't understand this question. There's nothing to do
to 'initialize mbus'. We can add/remove address decoding windows
whenever we want.

> >  * I am not sure to understand why the nand, crypto and pcie-controller
> >    nodes are outside of the internal registers. Well, I understand it's
> >    because those devices need a special address decoding window. But it
> >    sounds strange because those devices also have internal registers
> >    (which is why Jason used 'MAPDEF_INTERNAL + offset' in the reg
> >    property).
> > 
> >    Is this really the desired DT binding?
> 
> I don't understant what "internal registers" mean in this context.

On Marvell HW, the physical address space is split in multiple windows:
PCIe memory, PCIe I/O, mapping of NOR, mapping of FPGA, special
memories like crypto-engine SRAM, etc. One very special window is
called the 'internal registers window'. It is set up by the bootloader,
and contains all the registers for all the devices: UART, PCIe
interfaces, USB, SDIO, Ethernet, everything. All the 0xd00yyyyy
addresses in the current Armada 370/XP .dts(i) are part of the internal
registers window.

> >  * Regarding the PCIe binding, Jason Gunthorpe suggests the use of a
> >    'marvell,mbus-targets' attribute so that the PCIe driver knows what
> >    target/attribute values to use to create the window. Currently, the
> >    PCIe driver uses a name (like "pcie0.3") that it gives to the
> >    mvebu-mbus driver, which then translates this name to the real
> >    target/attribute values using per-SoC tables that associate names
> >    (pcie0.3) with values (say 0x4 / 0x42).
> > 
> >    Is this marvell,mbus-targets really the suggested solution? This
> >    would basically mean that the entire name -> value mapping tables of
> >    the driver would ultimately become useless (note that I'm not
> >    necessarily saying it is bad, I just want to check where we are
> >    going before doing useless work). Of course, those tables would
> >    remain at the beginning, once all platforms are converted to the
> >    mvebu-mbus DT binding, which may take a bit of time since it requires
> >    quite a lot of code movement in the .dtsi/.dts files.
> 
> I think it would be much nicer to express the specific mbus target using
> the ranges properties of the device nodes in PCI. Maybe I'm missing what
> the problem is here. 

Hum, this has already been discussed when doing the PCIe driver.

Basically it's not possible because the target/attribute values are per
PCIe interface, while the ranges we need to PCIe are *global*. Since we
don't know how much memory and I/O each PCIe interface will need, we
can't provision the right windows statically in the DT. The windows are
created dynamically by the PCIe driver depending on what gets
enumerated on the downstream bus.

So in the DT we have *one* global range for PCIe memory and *one* global
range for PCIe I/O.

But then, the PCIe driver needs to know for *each* PCIe interface what
is the right target/attribute tuple to create a memory or I/O window
for that particular interface.

Does that make sense?

> > I already have some basic code in the mvebu-mbus driver that parses the
> > ranges = <...> property and creates the corresponding windows, it seems
> > to work fine.
> 
> Ok, nice! So I guess the next step is to dynamically insert additional
> ranges for devices that are only mapped at run time, right?

What would be the need of this? Nobody will ever read the 'ranges'
property again at runtime, so why bother? Of course, if you need it for
good DT-compliance, I'll do it, but I don't see the point of having
kernel code to update a data structure that will never be read again by
anybody else.

Thanks for your comments!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From s.nawrocki at samsung.com  Fri Apr  5 09:53:27 2013
From: s.nawrocki at samsung.com (Sylwester Nawrocki)
Date: Fri, 05 Apr 2013 15:53:27 +0200
Subject: [PATCH 1/3] clk: exynos: register audio subsystem clocks using
 common clock framework
In-Reply-To: <1365143029-16936-1-git-send-email-padma.v@samsung.com>
References: <1365143029-16936-1-git-send-email-padma.v@samsung.com>
Message-ID: <515ED757.9070708@samsung.com>

On 04/05/2013 08:23 AM, Padmavathi Venna wrote:
> Audio subsystem is introduced in exynos platforms. This has seperate
> clock controller which can control i2s0 and pcm0 clocks. This patch
> registers the audio subsystem clocks with the common clock framework.
> 
> Signed-off-by: Padmavathi Venna <padma.v at samsung.com>
> ---
>  drivers/clk/samsung/Makefile           |    1 +
>  drivers/clk/samsung/clk-exynos-audss.c |  139 ++++++++++++++++++++++++++++++++
>  2 files changed, 140 insertions(+), 0 deletions(-)
>  create mode 100644 drivers/clk/samsung/clk-exynos-audss.c
> 
> diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile
> index b7c232e..1876810 100644
> --- a/drivers/clk/samsung/Makefile
> +++ b/drivers/clk/samsung/Makefile
> @@ -6,3 +6,4 @@ obj-$(CONFIG_COMMON_CLK)	+= clk.o clk-pll.o
>  obj-$(CONFIG_ARCH_EXYNOS4)	+= clk-exynos4.o
>  obj-$(CONFIG_SOC_EXYNOS5250)	+= clk-exynos5250.o
>  obj-$(CONFIG_SOC_EXYNOS5440)	+= clk-exynos5440.o
> +obj-$(CONFIG_ARCH_EXYNOS)	+= clk-exynos-audss.o
> diff --git a/drivers/clk/samsung/clk-exynos-audss.c b/drivers/clk/samsung/clk-exynos-audss.c
> new file mode 100644
> index 0000000..d7f9aa8
> --- /dev/null
> +++ b/drivers/clk/samsung/clk-exynos-audss.c
> @@ -0,0 +1,139 @@
> +/*
> + * Copyright (c) 2013 Samsung Electronics Co., Ltd.
> + * Author: Padmavathi Venna <padma.v at samsung.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.
> + *
> + * Common Clock Framework support for Audio clks.

s/clks/Subsystem Clock Controller ?

> +*/
> +
> +#include <linux/clkdev.h>
> +#include <linux/io.h>
> +#include <linux/clk-provider.h>
> +#include <linux/of_address.h>
> +#include <linux/syscore_ops.h>
> +
> +static DEFINE_SPINLOCK(lock);
> +static struct clk **clk_table;
> +static void __iomem *reg_base;
> +#ifdef CONFIG_OF

Is this really required ? This driver is for ARCH_EXYNOS which is
going to be DT only anyway - presumably it would depend on OF.

> +static struct clk_onecell_data clk_data;
> +#endif
> +
> +#define ASS_CLK_SRC 0x0
> +#define ASS_CLK_DIV 0x4
> +#define ASS_CLK_GATE 0x8
> +
> +static unsigned long reg_save[][2] = {
> +	{ASS_CLK_SRC,  0x0},

nit: '0x' could be probably omitted.

> +	{ASS_CLK_DIV,  0x0},
> +	{ASS_CLK_GATE, 0x0},
> +};
> +
> +/*
> + * Let each supported clock get a unique id. This id is used to lookup the clock
> + * for device tree based platforms.
> + *
> + * When adding a new clock to this list, it is advised to add it to the end.
> + * That is because the device tree source file is referring to these ids and
> + * any change in the sequence number of existing clocks will require
> + * corresponding change in the device tree files. This limitation would go away
> + * when pre-processor support for dtc would be available.

It's already available. Also please see [1]. IMO the best would be to 
create a header file including #defines for all the clocks indexes as 
per enum exynos_audss_clks. This header would be put in a common location
so it can be included by the driver and the dts files.

> + */
> +enum exynos_audss_clks {
> +	/* audss clocks */
> +	mout_audss, mout_i2s,
> +	dout_srp, dout_bus, dout_i2s,
> +	srp_clk, i2s_bus, sclk_i2s0,
> +
> +	nr_clks,
> +};
> +
> +/* list of all parent clock list */
> +static const char *mout_audss_p[] = { "fin_pll", "fout_epll" };
> +static const char *mout_i2s_p[] = { "mout_audss", "cdclk0", "sclk_audio0" };
> +
> +#ifdef CONFIG_PM_SLEEP
> +static int exynos_audss_clk_suspend(void)
> +{
> +	int i;
> +
> +	for (i = 0; i < 3; i++)
> +		reg_save[i][1] = __raw_readl(reg_base + reg_save[i][0]);

Why using the __raw_* accessors ? I think it should be readl().

> +
> +	return 0;
> +}
> +
> +static void exynos_audss_clk_resume(void)
> +{
> +	int i;
> +
> +	for (i = 0; i < 3; i++)
> +		__raw_writel(reg_save[i][1], reg_base + reg_save[i][0]);

Same here, writel().

> +}
> +
> +static struct syscore_ops exynos_audss_clk_syscore_ops = {
> +	.suspend	= exynos_audss_clk_suspend,
> +	.resume		= exynos_audss_clk_resume,
> +};
> +#endif /* CONFIG_PM_SLEEP */
> +
> +/* register exynos_audss clocks */
> +void __init exynos_audss_clk_init(struct device_node *np)
> +{

Isn't it better to just do

	if (np == NULL)
		return;	

i.e. just skip the initialization altogether ? panic() seems 
unreasonable here.

> +	if (np) {
> +		reg_base = of_iomap(np, 0);
> +		if (!reg_base)
> +			panic("%s: failed to map registers\n", __func__);
> +	} else
> +		panic("%s: unable to determine soc\n", __func__);
> +
> +	clk_table = kzalloc(sizeof(struct clk *) * nr_clks, GFP_KERNEL);
> +	if (!clk_table)
> +		panic("could not allocate clock lookup table\n");
> +
> +	clk_data.clks = clk_table;
> +	clk_data.clk_num = nr_clks;
> +	of_clk_add_provider(np, of_clk_src_onecell_get, &clk_data);
> +
> +	clk_table[mout_audss] = clk_register_mux(NULL, "mout_audss",
> +				mout_audss_p, ARRAY_SIZE(mout_audss_p), 0,
> +				reg_base + ASS_CLK_SRC, 0, 1, 0, &lock);
> +	clk_register_clkdev(clk_table[mout_audss], "mout_audss", NULL);
> +
> +	clk_table[mout_i2s] = clk_register_mux(NULL, "mout_i2s", mout_i2s_p,
> +				ARRAY_SIZE(mout_i2s_p), 0,
> +				reg_base + ASS_CLK_SRC, 2, 2, 0, &lock);
> +	clk_register_clkdev(clk_table[mout_i2s], "mout_i2s", NULL);
> +
> +	clk_table[dout_srp] = clk_register_divider(NULL, "dout_srp",
> +				"mout_audss", 0, reg_base + ASS_CLK_DIV, 0, 4,
> +				0, &lock);
> +
> +	clk_table[dout_bus] = clk_register_divider(NULL, "dout_bus",
> +				"dout_srp", 0, reg_base + ASS_CLK_DIV, 4, 4, 0,
> +				&lock);
> +
> +	clk_table[dout_i2s] = clk_register_divider(NULL, "dout_i2s",
> +				"mout_i2s", 0, reg_base + ASS_CLK_DIV, 8, 4, 0,
> +				&lock);
> +
> +	clk_table[srp_clk] = clk_register_gate(NULL, "srp_clk", "dout_srp",
> +				CLK_SET_RATE_PARENT, reg_base + ASS_CLK_GATE, 0,
> +				0, &lock);
> +
> +	clk_table[i2s_bus] = clk_register_gate(NULL, "i2s_bus", "dout_bus",
> +				CLK_SET_RATE_PARENT, reg_base + ASS_CLK_GATE, 2,

Don't we need to handle also bit 3 of the ASS_CLK_GATE register ?

In some kernels I saw PCM special/PCM Bus and I2S special/I2S Bus bits
associated with same clocks. So there were 2-bit wide masks for each clock.

Tomasz had an idea to add a flag to the clock framework that would be passed
to clk_register_gate() and would indicate that the sixth argument is a bitmask,
rather than a bit index.

Perhaps we could just specify each bit of ASS_CLK_GATE as a separate clock.
Then the drivers would need to be modified. I'm not sure what's best approach.
And if it is really necessary to be enabling/disabling both special/bus clock
gate bits simultaneously. I'm adding Mike to Cc, so perhaps he could provide
us with some pointers.

> +				0, &lock);
> +
> +	clk_table[sclk_i2s0] = clk_register_gate(NULL, "sclk_i2s0", "dout_i2s",
> +				CLK_SET_RATE_PARENT, reg_base + ASS_CLK_GATE, 3,
> +				0, &lock);
> +#ifdef CONFIG_PM_SLEEP
> +	register_syscore_ops(&exynos_audss_clk_syscore_ops);
> +#endif
> +	pr_info("Exynos: Audss: clock setup completed\n");
> +}
> +CLK_OF_DECLARE(exynos_audss_clk, "samsung,exynos-audss-clock", exynos_audss_clk_init);


[1] http://www.spinics.net/lists/linux-kbuild/msg07616.html


From nicolas.ferre at atmel.com  Fri Apr  5 09:57:17 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Fri, 5 Apr 2013 15:57:17 +0200
Subject: Regarding the SPI initialization problem on sam9x5 2000 boards
 in linux kernel 3.2.6
In-Reply-To: <48262.115.249.69.209.1365160782.squirrel@mail.siennaecad.com>
References: <48262.115.249.69.209.1365160782.squirrel@mail.siennaecad.com>
Message-ID: <515ED83D.3010504@atmel.com>

On 04/05/2013 01:19 PM, sambasiva.a at siennaecad.com :
> Hi,
> 
> when i execute the following command the sam9x5 2000 board will hang.
> 
> echo "test" > /dev/spidev0.1
> I am facing this problem once  ported the sam9x5 code from 2.6.39 to 3.2.6
> kernel .
> 
> Could you please tell me anyone how to move out from the hang state.

You can test the consolidated 3.6 based kernel that we are deploying on
our github tree: branch: linux-3.6.9-at91

https://github.com/linux4sam/linux-at91/commits/linux-3.6.9-at91

The SPI code is being review on this mainling list: search for the
following patch series:

"spi/spi-atmel: add dmaengine support for atmel spi controller and to
test the device tree support"

Best regards,
-- 
Nicolas Ferre


From sebastian.hesselbarth at gmail.com  Fri Apr  5 09:58:03 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Fri, 5 Apr 2013 15:58:03 +0200
Subject: [PATCH 1/5 v2] mv643xx_eth: add Device Tree bindings
In-Reply-To: <515E9FE0.8050402@openwrt.org>
References: <1365071235-11611-1-git-send-email-florian@openwrt.org>
 <1365071235-11611-2-git-send-email-florian@openwrt.org>
 <20130404212906.GA25904@schnuecks.de>
 <515E9FE0.8050402@openwrt.org>
Message-ID: <CABJ1b_TdzE_Q9qLsdSGZy8byFpCTtVBUy5FtxiZAx7QqgG-rVg@mail.gmail.com>

On Fri, Apr 5, 2013 at 11:56 AM, Florian Fainelli <florian at openwrt.org> wrote:
> [snip]

Florian,

took me a while to try you patches out on Dove but now I fixed all
issues. I will
comment on all related patches but first I want to comment here.

One general note for Dove related patches: You didn't remove the registration of
ge platform_device from mach-dove/board-dt.c. That will lead to double
registration
of mdio and mv643xx_eth/shared, so you'll never be sure if DT or non-DT code is
executed. I haven't checked mach-kirkwood/board-dt.c or orion5x code.

>>>         if (!mv643xx_eth_version_printed++)
>>>                 pr_notice("MV-643xx 10/100/1000 ethernet driver version
>>> %s\n",
>>
>>
>> This is not related to your change, but there is a problem in this
>> function that has already been discussed in the past if I remember
>> correctly: The respective clock needs to be enabled here (at least
>> on Kirkwood), since accesses to the hardware are done below.
>> Enabling the clock only in mv643xx_eth_probe() is too late.
>>
>> As said, this is not a problem introduced by your changes (and which
>> is currently circumvented by enabling the respective clocks in
>> kirkwood_legacy_clk_init() and kirkwood_ge0x_init()), but we might
>> want to fix this now to get rid of unconditionally enabling the GE
>> clocks in the DT case.
>
>
> I think there may have been some confusion between the "ethernet-group"
> clock and the actual Ethernet port inside the "ethernet-group". The
> mv643xx_eth driver assumes we have a per-port clock gating scheme, while I
> think we have a per "ethernet-group" clock gating scheme instead. Like you
> said, I think this should be addressed separately.

IMHO, there should be a clocks property where ever you try to access registers,
i.e. in all three "parts" mv643xx_eth_shared (group), mv643xx_eth
(port) and mdio.
Since port depends on shared it would be ok to have it per group but that may
collide with other SoCs than Dove/Kirkwood that have per port clocks.

Is that separation (group/port) really required for any SoC?

>
> [snip]
>>
>> You don't change the clk initialization here:
>>
>> #if defined(CONFIG_HAVE_CLK)
>>         mp->clk = clk_get(&pdev->dev, (pdev->id ? "1" : "0"));
>>         if (!IS_ERR(mp->clk)) {
>>                 clk_prepare_enable(mp->clk);
>>                 mp->t_clk = clk_get_rate(mp->clk);
>>         }
>> #endif
>>
>> Which, if I understand correctly, works in the DT case because you
>> assign "clock-names" to the clocks in the DTS. However, I wonder
>> whether this works for any but the first Ethernet device.

Yes, it does. Assigned clocks from clocks property get a clock alias for
that device name (node name). Using anything else than NULL here is
IMHO just wrong. We should rather provide proper clock aliases for non-DT case.

>> In the old platform device setup, the pdev->id was set when
>> initialiazing the platform_device structure in common.c.  Where is
>> this done in the DT case?
>
> Looks like you are right, in the DT case, I assume that we should lookup the
> clock using NULL instead of "1" or "0" so we match any clock instead of a
> specific one.

Yes.

> [snip]
>>
>>
>> In phy_scan(), the phy is searched like this:
>>
>>                 snprintf(phy_id, sizeof(phy_id), PHY_ID_FMT,
>>                                 "orion-mdio-mii", addr);
>>
>>                 phydev = phy_connect(mp->dev, phy_id,
>> mv643xx_eth_adjust_link,
>>                                 PHY_INTERFACE_MODE_GMII);
>>
>> But "orion-mdio-mii:xx" is the name of the PHY if MDIO is setup via a
>> platform_device. I could not get this to work if the MDIO device is
>> setup via DT. Am I doing something wrong?
>
> I just missed updating this part of the code to probe for PHYs. The board I
> tested with uses a "PHY_NONE" configuration. I will add the missing bits for
> of_phy_connect() to be called here.

I don't think that the ethernet controller should probe the PHY's on mdio-bus
at all. At least not for DT enabled platforms. I had a look at DT and non-DT
mdio-bus sources, and realized that there is a bus scan for non-DT only.
of_mdiobus_register requires you to set (and know) the PHY address.

I prepared a patch for of_mdio_register that will allow you to probe mdio and
assign phy addresses to each node found. Currently, the heuristic for probing
is: assign each phy node the next probed phy_addr starting with 0. But that
will not allow to e.g. set some PHY addresses and probe the rest.

We had a similar discussion whether to probe or not for DT nodes, and I guess
there also will be some discussion about the above patch. OTOH we could just
(again) ask users of every kirkwood/orion5x/dove board to tell their
phy addresses
and fail to probe the phy for new boards...

I will prepare a proper patch soon and post it on the corresponding lists.

>> Additionally, in phy_scan() there is this:
>>
>>         if (phy_addr == MV643XX_ETH_PHY_ADDR_DEFAULT) {
>>                 start = phy_addr_get(mp) & 0x1f;
>>                 num = 32;
>>         } else {
>>         ...
>>
>> MV643XX_ETH_PHY_ADDR_DEFAULT is defined as 0. However, many Kirkwood
>> devices use "MV643XX_ETH_PHY_ADDR(0)".  If the module probe is
>> deferred in mv643xx_eth because the MDIO driver is not yet loaded,
>> all 32 PHY addresses are scanned without success.  This is not needed
>> and clutters the log.
>
>
> Ok, I am not sure how we can circumvent the log cluttering that happens,
> what would be your suggestion?

My suggestion is to change MV643XX_ETH_PHY_ADDR_DEFAULT from a valid
phy address (0)
to something invalid (32). I understand that using 0 helps if you
don't want to set it in mv643xx's platform_data
but it is always difficult to rely on that if 0 is a valid number.

Changing the above to 32 should just work because most (all?) boards
using phy_scan should also
already use MV643XX_ETH_PHY_ADDR_DEFAULT. I also suggest to rename
current define to a
better name, e.g. MV643XX_ETH_PHY_ADDR_AUTOSCAN.

Sebastian


From thomas.petazzoni at free-electrons.com  Fri Apr  5 09:58:33 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Fri, 5 Apr 2013 15:58:33 +0200
Subject: [PATCHv7 06/17] clk: mvebu: create parent-child relation for
 PCIe clocks on Armada 370
In-Reply-To: <1364395234-11195-7-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1364395234-11195-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1364395234-11195-7-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <20130405155833.6e6a4b75@skate>

Mike,

Could we have your opinion on this patch, and possibly a Acked-by to
pass it through arm-soc?

Thanks!

Thomas

On Wed, 27 Mar 2013 15:40:23 +0100, Thomas Petazzoni wrote:
> The Armada 370 has two gatable clocks for each PCIe interface, and we
> want both of them to be enabled. We therefore make one of the two
> clocks a child of the other, as we did for the sataX and sataXlnk
> clocks on Armada XP.
> 
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> Cc: Mike Turquette <mturquette at linaro.org>
> ---
>  drivers/clk/mvebu/clk-gating-ctrl.c |    4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/clk/mvebu/clk-gating-ctrl.c b/drivers/clk/mvebu/clk-gating-ctrl.c
> index ebf141d..b35785a 100644
> --- a/drivers/clk/mvebu/clk-gating-ctrl.c
> +++ b/drivers/clk/mvebu/clk-gating-ctrl.c
> @@ -119,8 +119,8 @@ static const struct mvebu_soc_descr __initconst armada_370_gating_descr[] = {
>  	{ "pex1_en", NULL,  2 },
>  	{ "ge1", NULL, 3 },
>  	{ "ge0", NULL, 4 },
> -	{ "pex0", NULL, 5 },
> -	{ "pex1", NULL, 9 },
> +	{ "pex0", "pex0_en", 5 },
> +	{ "pex1", "pex1_en", 9 },
>  	{ "sata0", NULL, 15 },
>  	{ "sdio", NULL, 17 },
>  	{ "tdm", NULL, 25 },



-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From balbi at ti.com  Fri Apr  5 10:04:20 2013
From: balbi at ti.com (Felipe Balbi)
Date: Fri, 5 Apr 2013 17:04:20 +0300
Subject: [PATCH v3 1/4] ARM: OMAP4+: PM: Consolidate MPU subsystem PM
 code for re-use
In-Reply-To: <20130405133511.GA4143@kahuna>
References: <1365166743-5940-1-git-send-email-santosh.shilimkar@ti.com>
 <1365166743-5940-2-git-send-email-santosh.shilimkar@ti.com>
 <20130405131935.GM11464@arwen.pp.htv.fi>
 <20130405133511.GA4143@kahuna>
Message-ID: <20130405140420.GB12229@arwen.pp.htv.fi>

Hi,

On Fri, Apr 05, 2013 at 08:35:11AM -0500, Nishanth Menon wrote:
> On 16:19-20130405, Felipe Balbi wrote:
> > On Fri, Apr 05, 2013 at 06:29:00PM +0530, Santosh Shilimkar wrote:
> > > OMAP5 and future OMAP based SOCs has backward compatible MPUSS
> > > IP block with OMAP4. It's programming model is mostly similar.
> > 
> > s/It's/Its/
> > s/mostly //
> > 
> > (similar already expands to 'almost the same' :-)
> > 
> > > @@ -355,6 +389,12 @@ int __init omap4_mpuss_init(void)
> > >  
> > >  	save_l2x0_context();
> > >  
> > > +	if (cpu_is_omap44xx()) {
> > > +		omap_pm_ops.finish_suspend = omap4_finish_suspend;
> > > +		omap_pm_ops.resume = omap4_cpu_resume;
> > > +		omap_pm_ops.scu_prepare = scu_pwrst_prepare;
> > > +	}
> > 
> > why don't you just rename omap4_* into omap_* and add cpu-based checks
> > there in order to handle differences between omap4 and omap5?
> > 
> > If implementation will be almost the same for both, you might be able to
> > save on some more duplication, no ?
> Jeez NO! finish_suspend is assembly, further, it is the hottest path in
> cpuidle framework - for every WFI we invoke it. we definitely dont want
> to add more overhead beyond what is necessary.

alright, settle down ;-) whoever suggested that isn't here anymore

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130405/40db40d5/attachment-0001.sig>

From marex at denx.de  Fri Apr  5 10:11:14 2013
From: marex at denx.de (Marek Vasut)
Date: Fri, 5 Apr 2013 16:11:14 +0200
Subject: [PATCH] ARM: dts: imx23-olinuxino: Set the sdcard as non-removable
In-Reply-To: <20130405091656.GD2667@S2101-09.ap.freescale.net>
References: <1365135413-31493-1-git-send-email-aletes.xgr@gmail.com>
 <20130405091656.GD2667@S2101-09.ap.freescale.net>
Message-ID: <201304051611.15003.marex@denx.de>

Dear Shawn Guo,

> On Fri, Apr 05, 2013 at 01:16:53AM -0300, Alexandre Pereira da Silva wrote:
> > The imx23-olinuxino sdcard doesn't support card detect.
> 
> So it sounds more like a "broken-cd" rather than "non-removable"?

The CD line is working perfectly well on this board, so I don't get it.

Best regards,
Marek Vasut


From nicolas.ferre at atmel.com  Fri Apr  5 10:14:35 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Fri, 5 Apr 2013 16:14:35 +0200
Subject: [PATCH] Revert "drivers/rtc/rtc-at91rm9200.c: use a variable
 for storing IMR"
In-Reply-To: <515C0208.2000605@atmel.com>
References: <20130403095150.GC27600@localhost>
 <1364982862-19759-1-git-send-email-jhovold@gmail.com>
 <515C0208.2000605@atmel.com>
Message-ID: <515EDC4B.3010508@atmel.com>

On 04/03/2013 12:18 PM, Nicolas Ferre :
> On 04/03/2013 11:54 AM, Johan Hovold :
>> This reverts commit 0ef1594c017521ea89278e80fe3f80dafb17abde.
>>
>> This patch introduced a few races which cannot be easily fixed with a
>> small follow-up patch. Furthermore, the SoC with the broken hardware
>> register, which this patch intended to add support for, can only be used
>> with device trees, which this driver currently does not support.
>>
>> Cc: stable <stable at vger.kernel.org>
>> Signed-off-by: Johan Hovold <jhovold at gmail.com>
> 
> Fair enough, after fighting to find a solution that can makes us move
> forward... your strong arguments convinced me.
> 
> So, Andrew, please can you take this "revert" patch for 3.9-rc ?
> And sorry for the noise.
> 
> Acked-by: Nicolas Ferre <nicolas.ferre at atmel.com>
> 
> (Andrew, I figured out that you are not in copy of the original email:
> do I need to send it back to you or can you pick it up in patchwork?
> https://patchwork.kernel.org/patch/2385921/
> )

Andrew, ping?

Thanks, best regards,

>> ---
>>  drivers/rtc/rtc-at91rm9200.c | 50 +++++++++++++++++---------------------------
>>  drivers/rtc/rtc-at91rm9200.h |  1 +
>>  2 files changed, 20 insertions(+), 31 deletions(-)
>>
>> diff --git a/drivers/rtc/rtc-at91rm9200.c b/drivers/rtc/rtc-at91rm9200.c
>> index 0a9f27e..434ebc3 100644
>> --- a/drivers/rtc/rtc-at91rm9200.c
>> +++ b/drivers/rtc/rtc-at91rm9200.c
>> @@ -44,7 +44,6 @@ static DECLARE_COMPLETION(at91_rtc_updated);
>>  static unsigned int at91_alarm_year = AT91_RTC_EPOCH;
>>  static void __iomem *at91_rtc_regs;
>>  static int irq;
>> -static u32 at91_rtc_imr;
>>  
>>  /*
>>   * Decode time/date into rtc_time structure
>> @@ -109,11 +108,9 @@ static int at91_rtc_settime(struct device *dev, struct rtc_time *tm)
>>  	cr = at91_rtc_read(AT91_RTC_CR);
>>  	at91_rtc_write(AT91_RTC_CR, cr | AT91_RTC_UPDCAL | AT91_RTC_UPDTIM);
>>  
>> -	at91_rtc_imr |= AT91_RTC_ACKUPD;
>>  	at91_rtc_write(AT91_RTC_IER, AT91_RTC_ACKUPD);
>>  	wait_for_completion(&at91_rtc_updated);	/* wait for ACKUPD interrupt */
>>  	at91_rtc_write(AT91_RTC_IDR, AT91_RTC_ACKUPD);
>> -	at91_rtc_imr &= ~AT91_RTC_ACKUPD;
>>  
>>  	at91_rtc_write(AT91_RTC_TIMR,
>>  			  bin2bcd(tm->tm_sec) << 0
>> @@ -145,7 +142,7 @@ static int at91_rtc_readalarm(struct device *dev, struct rtc_wkalrm *alrm)
>>  	tm->tm_yday = rtc_year_days(tm->tm_mday, tm->tm_mon, tm->tm_year);
>>  	tm->tm_year = at91_alarm_year - 1900;
>>  
>> -	alrm->enabled = (at91_rtc_imr & AT91_RTC_ALARM)
>> +	alrm->enabled = (at91_rtc_read(AT91_RTC_IMR) & AT91_RTC_ALARM)
>>  			? 1 : 0;
>>  
>>  	dev_dbg(dev, "%s(): %4d-%02d-%02d %02d:%02d:%02d\n", __func__,
>> @@ -171,7 +168,6 @@ static int at91_rtc_setalarm(struct device *dev, struct rtc_wkalrm *alrm)
>>  	tm.tm_sec = alrm->time.tm_sec;
>>  
>>  	at91_rtc_write(AT91_RTC_IDR, AT91_RTC_ALARM);
>> -	at91_rtc_imr &= ~AT91_RTC_ALARM;
>>  	at91_rtc_write(AT91_RTC_TIMALR,
>>  		  bin2bcd(tm.tm_sec) << 0
>>  		| bin2bcd(tm.tm_min) << 8
>> @@ -184,7 +180,6 @@ static int at91_rtc_setalarm(struct device *dev, struct rtc_wkalrm *alrm)
>>  
>>  	if (alrm->enabled) {
>>  		at91_rtc_write(AT91_RTC_SCCR, AT91_RTC_ALARM);
>> -		at91_rtc_imr |= AT91_RTC_ALARM;
>>  		at91_rtc_write(AT91_RTC_IER, AT91_RTC_ALARM);
>>  	}
>>  
>> @@ -201,12 +196,9 @@ static int at91_rtc_alarm_irq_enable(struct device *dev, unsigned int enabled)
>>  
>>  	if (enabled) {
>>  		at91_rtc_write(AT91_RTC_SCCR, AT91_RTC_ALARM);
>> -		at91_rtc_imr |= AT91_RTC_ALARM;
>>  		at91_rtc_write(AT91_RTC_IER, AT91_RTC_ALARM);
>> -	} else {
>> +	} else
>>  		at91_rtc_write(AT91_RTC_IDR, AT91_RTC_ALARM);
>> -		at91_rtc_imr &= ~AT91_RTC_ALARM;
>> -	}
>>  
>>  	return 0;
>>  }
>> @@ -215,10 +207,12 @@ static int at91_rtc_alarm_irq_enable(struct device *dev, unsigned int enabled)
>>   */
>>  static int at91_rtc_proc(struct device *dev, struct seq_file *seq)
>>  {
>> +	unsigned long imr = at91_rtc_read(AT91_RTC_IMR);
>> +
>>  	seq_printf(seq, "update_IRQ\t: %s\n",
>> -			(at91_rtc_imr & AT91_RTC_ACKUPD) ? "yes" : "no");
>> +			(imr & AT91_RTC_ACKUPD) ? "yes" : "no");
>>  	seq_printf(seq, "periodic_IRQ\t: %s\n",
>> -			(at91_rtc_imr & AT91_RTC_SECEV) ? "yes" : "no");
>> +			(imr & AT91_RTC_SECEV) ? "yes" : "no");
>>  
>>  	return 0;
>>  }
>> @@ -233,7 +227,7 @@ static irqreturn_t at91_rtc_interrupt(int irq, void *dev_id)
>>  	unsigned int rtsr;
>>  	unsigned long events = 0;
>>  
>> -	rtsr = at91_rtc_read(AT91_RTC_SR) & at91_rtc_imr;
>> +	rtsr = at91_rtc_read(AT91_RTC_SR) & at91_rtc_read(AT91_RTC_IMR);
>>  	if (rtsr) {		/* this interrupt is shared!  Is it ours? */
>>  		if (rtsr & AT91_RTC_ALARM)
>>  			events |= (RTC_AF | RTC_IRQF);
>> @@ -297,7 +291,6 @@ static int __init at91_rtc_probe(struct platform_device *pdev)
>>  	at91_rtc_write(AT91_RTC_IDR, AT91_RTC_ACKUPD | AT91_RTC_ALARM |
>>  					AT91_RTC_SECEV | AT91_RTC_TIMEV |
>>  					AT91_RTC_CALEV);
>> -	at91_rtc_imr = 0;
>>  
>>  	ret = request_irq(irq, at91_rtc_interrupt,
>>  				IRQF_SHARED,
>> @@ -336,7 +329,6 @@ static int __exit at91_rtc_remove(struct platform_device *pdev)
>>  	at91_rtc_write(AT91_RTC_IDR, AT91_RTC_ACKUPD | AT91_RTC_ALARM |
>>  					AT91_RTC_SECEV | AT91_RTC_TIMEV |
>>  					AT91_RTC_CALEV);
>> -	at91_rtc_imr = 0;
>>  	free_irq(irq, pdev);
>>  
>>  	rtc_device_unregister(rtc);
>> @@ -349,35 +341,31 @@ static int __exit at91_rtc_remove(struct platform_device *pdev)
>>  
>>  /* AT91RM9200 RTC Power management control */
>>  
>> -static u32 at91_rtc_bkpimr;
>> -
>> +static u32 at91_rtc_imr;
>>  
>>  static int at91_rtc_suspend(struct device *dev)
>>  {
>>  	/* this IRQ is shared with DBGU and other hardware which isn't
>>  	 * necessarily doing PM like we are...
>>  	 */
>> -	at91_rtc_bkpimr = at91_rtc_imr & (AT91_RTC_ALARM|AT91_RTC_SECEV);
>> -	if (at91_rtc_bkpimr) {
>> -		if (device_may_wakeup(dev)) {
>> +	at91_rtc_imr = at91_rtc_read(AT91_RTC_IMR)
>> +			& (AT91_RTC_ALARM|AT91_RTC_SECEV);
>> +	if (at91_rtc_imr) {
>> +		if (device_may_wakeup(dev))
>>  			enable_irq_wake(irq);
>> -		} else {
>> -			at91_rtc_write(AT91_RTC_IDR, at91_rtc_bkpimr);
>> -			at91_rtc_imr &= ~at91_rtc_bkpimr;
>> -		}
>> -}
>> +		else
>> +			at91_rtc_write(AT91_RTC_IDR, at91_rtc_imr);
>> +	}
>>  	return 0;
>>  }
>>  
>>  static int at91_rtc_resume(struct device *dev)
>>  {
>> -	if (at91_rtc_bkpimr) {
>> -		if (device_may_wakeup(dev)) {
>> +	if (at91_rtc_imr) {
>> +		if (device_may_wakeup(dev))
>>  			disable_irq_wake(irq);
>> -		} else {
>> -			at91_rtc_imr |= at91_rtc_bkpimr;
>> -			at91_rtc_write(AT91_RTC_IER, at91_rtc_bkpimr);
>> -		}
>> +		else
>> +			at91_rtc_write(AT91_RTC_IER, at91_rtc_imr);
>>  	}
>>  	return 0;
>>  }
>> diff --git a/drivers/rtc/rtc-at91rm9200.h b/drivers/rtc/rtc-at91rm9200.h
>> index 5f940b6..da1945e 100644
>> --- a/drivers/rtc/rtc-at91rm9200.h
>> +++ b/drivers/rtc/rtc-at91rm9200.h
>> @@ -64,6 +64,7 @@
>>  #define	AT91_RTC_SCCR		0x1c			/* Status Clear Command Register */
>>  #define	AT91_RTC_IER		0x20			/* Interrupt Enable Register */
>>  #define	AT91_RTC_IDR		0x24			/* Interrupt Disable Register */
>> +#define	AT91_RTC_IMR		0x28			/* Interrupt Mask Register */
>>  
>>  #define	AT91_RTC_VER		0x2c			/* Valid Entry Register */
>>  #define		AT91_RTC_NVTIM		(1 <<  0)		/* Non valid Time */
>>
> 
> 


-- 
Nicolas Ferre


From monstr at monstr.eu  Fri Apr  5 10:14:45 2013
From: monstr at monstr.eu (Michal Simek)
Date: Fri, 05 Apr 2013 16:14:45 +0200
Subject: linux-next: manual merge of the arm-soc tree with the xilinx tree
In-Reply-To: <201304051532.46156.arnd@arndb.de>
References: <20130405153335.baf29606a97b1bee415f3546@canb.auug.org.au>
 <201304051409.37708.arnd@arndb.de>
 <CAHTX3d+PZ=G6JYBo7Hvqe=G77udaCFJ4pD4z_sQw_FDGP-xt=A@mail.gmail.com>
 <201304051532.46156.arnd@arndb.de>
Message-ID: <515EDC55.7090609@monstr.eu>

On 04/05/2013 03:32 PM, Arnd Bergmann wrote:
> On Friday 05 April 2013, Michal Simek wrote:
>>>> Interesting. I rebased my arm-next branch based on 3.9-rc5
>>>> with some Rob's + one Arnd patch from arm-soc - clksrc/cleanup branch.
>>>>
>>>> I will fix my arm-next branch.
>>>
>>> The for-next branch in arm-soc is not stable, you should never base
>>> anything on it. If you depend on some stable branch, that is in arm-soc,
>>> then use just that branch, not one of the next/* branches or for-next.
>>>
>>
>> I haven't based on arm-soc for-next branch my arm-next branch.
>> I just took all patches I need for zynq and done git rebase v3.5-rc5.
>> Which caused that I have became commuter of that 4 patches
>> and there is probably any conflict between your for-next branch and
>> clksrc/cleanup
>> which you have resolved in for-next branch.
>
> Ah, I see. That was actually my fault, I'm sorry for causing trouble
> here and then accusing you instead.
>
>> And because of my rebase sha1 are different that's why Stephen
>> had problem with it.
>> I have changed my arm-next branch and will see on Monday if Stephen
>> will report any problem or not.
>
> Ok, thanks!

No worries.

Thanks,
Michal



-- 
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian


From nm at ti.com  Fri Apr  5 10:18:02 2013
From: nm at ti.com (Nishanth Menon)
Date: Fri, 5 Apr 2013 09:18:02 -0500
Subject: [PATCH v3 1/4] ARM: OMAP4+: PM: Consolidate MPU subsystem PM
 code for re-use
In-Reply-To: <20130405140420.GB12229@arwen.pp.htv.fi>
References: <1365166743-5940-1-git-send-email-santosh.shilimkar@ti.com>
 <1365166743-5940-2-git-send-email-santosh.shilimkar@ti.com>
 <20130405131935.GM11464@arwen.pp.htv.fi>
 <20130405133511.GA4143@kahuna>
 <20130405140420.GB12229@arwen.pp.htv.fi>
Message-ID: <20130405141801.GA4270@kahuna>

On 17:04-20130405, Felipe Balbi wrote:
> Hi,
> 
> On Fri, Apr 05, 2013 at 08:35:11AM -0500, Nishanth Menon wrote:
> > On 16:19-20130405, Felipe Balbi wrote:
> > > On Fri, Apr 05, 2013 at 06:29:00PM +0530, Santosh Shilimkar wrote:
> > > > OMAP5 and future OMAP based SOCs has backward compatible MPUSS
> > > > IP block with OMAP4. It's programming model is mostly similar.
> > > 
> > > s/It's/Its/
> > > s/mostly //
> > > 
> > > (similar already expands to 'almost the same' :-)
> > > 
> > > > @@ -355,6 +389,12 @@ int __init omap4_mpuss_init(void)
> > > >  
> > > >  	save_l2x0_context();
> > > >  
> > > > +	if (cpu_is_omap44xx()) {
> > > > +		omap_pm_ops.finish_suspend = omap4_finish_suspend;
> > > > +		omap_pm_ops.resume = omap4_cpu_resume;
> > > > +		omap_pm_ops.scu_prepare = scu_pwrst_prepare;
> > > > +	}
> > > 
> > > why don't you just rename omap4_* into omap_* and add cpu-based checks
> > > there in order to handle differences between omap4 and omap5?
> > > 
> > > If implementation will be almost the same for both, you might be able to
> > > save on some more duplication, no ?
> > Jeez NO! finish_suspend is assembly, further, it is the hottest path in
> > cpuidle framework - for every WFI we invoke it. we definitely dont want
> > to add more overhead beyond what is necessary.
> 
> alright, settle down ;-) whoever suggested that isn't here anymore
hehe, Apologies, I was'nt that stressed as the wording might have
indicated.. We spend tons of time evaluating with Lauterbach tracing to
weed out hot paths - folks who have been bitten by these tend to feel a
little defensive I guess and to have surprise regressions are painful to
find and fix - esp when around not-so-obvious paths ;)

-- 
Regards,
Nishanth Menon


From fabio.estevam at freescale.com  Fri Apr  5 10:19:47 2013
From: fabio.estevam at freescale.com (Fabio Estevam)
Date: Fri, 5 Apr 2013 11:19:47 -0300
Subject: [PATCH v5] video: mxsfb: Introduce regulator support
Message-ID: <1365171587-31833-1-git-send-email-fabio.estevam@freescale.com>

Instead of using a custom binding for retrieving the GPIO that activates the 
LCD from devicetree, use a standard regulator.

This approach has the advantage to be more generic. 

For example: in the case of a board that has a PMIC supplying the LCD voltage, 
the current approach would not work, as it only searches for a GPIO pin.

Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
---
Chages since v4:
- Merged the 2 previous patches into one in order not to break keep mxsfb functionality
- Remove unneeded change in mxsfb.txt
- Use regulator_disable to pair with regulator_enable
Changes since v3:
- None
Changes since v2:
- Use devm_regulator_get()
Changes since v1:
- No changes
 Documentation/devicetree/bindings/fb/mxsfb.txt |    2 --
 arch/arm/boot/dts/imx23-evk.dts                |   11 ++++++-
 arch/arm/boot/dts/imx28-evk.dts                |   11 ++++++-
 drivers/video/mxsfb.c                          |   41 +++++++++++++-----------
 4 files changed, 43 insertions(+), 22 deletions(-)

diff --git a/Documentation/devicetree/bindings/fb/mxsfb.txt b/Documentation/devicetree/bindings/fb/mxsfb.txt
index 7ba3b76..5d810eb 100644
--- a/Documentation/devicetree/bindings/fb/mxsfb.txt
+++ b/Documentation/devicetree/bindings/fb/mxsfb.txt
@@ -8,7 +8,6 @@ Required properties:
 - display : phandle to display node (see below for details)
 
 Optional properties:
-- panel-enable-gpios : Should specify the gpio for panel enable
 
 * display node
 
@@ -25,7 +24,6 @@ lcdif at 80030000 {
 	compatible = "fsl,imx28-lcdif";
 	reg = <0x80030000 2000>;
 	interrupts = <38 86>;
-	panel-enable-gpios = <&gpio3 30 0>;
 
 	display: display {
 		bits-per-pixel = <32>;
diff --git a/arch/arm/boot/dts/imx23-evk.dts b/arch/arm/boot/dts/imx23-evk.dts
index 7880e17..da0588a 100644
--- a/arch/arm/boot/dts/imx23-evk.dts
+++ b/arch/arm/boot/dts/imx23-evk.dts
@@ -59,7 +59,7 @@
 			lcdif at 80030000 {
 				pinctrl-names = "default";
 				pinctrl-0 = <&lcdif_24bit_pins_a>;
-				panel-enable-gpios = <&gpio1 18 0>;
+				lcd-supply = <&reg_lcd_3v3>;
 				display = <&display>;
 				status = "okay";
 
@@ -120,6 +120,15 @@
 			regulator-max-microvolt = <3300000>;
 			gpio = <&gpio1 29 0>;
 		};
+
+		reg_lcd_3v3: lcd-3v3 {
+			compatible = "regulator-fixed";
+			regulator-name = "lcd-3v3";
+			regulator-min-microvolt = <3300000>;
+			regulator-max-microvolt = <3300000>;
+			gpio = <&gpio1 18 0>;
+			enable-active-high;
+		};
 	};
 
 	backlight {
diff --git a/arch/arm/boot/dts/imx28-evk.dts b/arch/arm/boot/dts/imx28-evk.dts
index 2d4ea3b..3637bf3 100644
--- a/arch/arm/boot/dts/imx28-evk.dts
+++ b/arch/arm/boot/dts/imx28-evk.dts
@@ -123,7 +123,7 @@
 				pinctrl-names = "default";
 				pinctrl-0 = <&lcdif_24bit_pins_a
 					     &lcdif_pins_evk>;
-				panel-enable-gpios = <&gpio3 30 0>;
+				lcd-supply = <&reg_lcd_3v3>;
 				display = <&display>;
 				status = "okay";
 
@@ -310,6 +310,15 @@
 			gpio = <&gpio3 8 0>;
 			enable-active-high;
 		};
+
+		reg_lcd_3v3: lcd-3v3 {
+			compatible = "regulator-fixed";
+			regulator-name = "lcd-3v3";
+			regulator-min-microvolt = <3300000>;
+			regulator-max-microvolt = <3300000>;
+			gpio = <&gpio3 30 0>;
+			enable-active-high;
+		};
 	};
 
 	sound {
diff --git a/drivers/video/mxsfb.c b/drivers/video/mxsfb.c
index eac7c1a..74fbfd1 100644
--- a/drivers/video/mxsfb.c
+++ b/drivers/video/mxsfb.c
@@ -42,7 +42,6 @@
 #include <linux/module.h>
 #include <linux/kernel.h>
 #include <linux/of_device.h>
-#include <linux/of_gpio.h>
 #include <video/of_display_timing.h>
 #include <linux/platform_device.h>
 #include <linux/clk.h>
@@ -50,6 +49,7 @@
 #include <linux/io.h>
 #include <linux/pinctrl/consumer.h>
 #include <linux/fb.h>
+#include <linux/regulator/consumer.h>
 #include <video/videomode.h>
 
 #define REG_SET	4
@@ -179,6 +179,7 @@ struct mxsfb_info {
 	unsigned dotclk_delay;
 	const struct mxsfb_devdata *devdata;
 	u32 sync;
+	struct regulator *reg_lcd;
 };
 
 #define mxsfb_is_v3(host) (host->devdata->ipversion == 3)
@@ -338,9 +339,19 @@ static void mxsfb_enable_controller(struct fb_info *fb_info)
 {
 	struct mxsfb_info *host = to_imxfb_host(fb_info);
 	u32 reg;
+	int ret;
 
 	dev_dbg(&host->pdev->dev, "%s\n", __func__);
 
+	if (!IS_ERR(host->reg_lcd)) {
+		ret = regulator_enable(host->reg_lcd);
+		if (ret) {
+			dev_err(&host->pdev->dev,
+				"lcd regulator enable failed:	%d\n", ret);
+			return;
+		}
+	}
+
 	clk_prepare_enable(host->clk);
 	clk_set_rate(host->clk, PICOS2KHZ(fb_info->var.pixclock) * 1000U);
 
@@ -362,9 +373,19 @@ static void mxsfb_disable_controller(struct fb_info *fb_info)
 	struct mxsfb_info *host = to_imxfb_host(fb_info);
 	unsigned loop;
 	u32 reg;
+	int ret;
 
 	dev_dbg(&host->pdev->dev, "%s\n", __func__);
 
+	if (!IS_ERR(host->reg_lcd)) {
+		ret = regulator_disable(host->reg_lcd);
+		if (ret) {
+			dev_err(&host->pdev->dev,
+				"lcd regulator disable failed: %d\n", ret);
+			return;
+		}
+	}
+
 	/*
 	 * Even if we disable the controller here, it will still continue
 	 * until its FIFOs are running out of data
@@ -859,8 +880,6 @@ static int mxsfb_probe(struct platform_device *pdev)
 	struct fb_info *fb_info;
 	struct fb_modelist *modelist;
 	struct pinctrl *pinctrl;
-	int panel_enable;
-	enum of_gpio_flags flags;
 	int ret;
 
 	if (of_id)
@@ -904,21 +923,7 @@ static int mxsfb_probe(struct platform_device *pdev)
 		goto fb_release;
 	}
 
-	panel_enable = of_get_named_gpio_flags(pdev->dev.of_node,
-					       "panel-enable-gpios", 0, &flags);
-	if (gpio_is_valid(panel_enable)) {
-		unsigned long f = GPIOF_OUT_INIT_HIGH;
-		if (flags == OF_GPIO_ACTIVE_LOW)
-			f = GPIOF_OUT_INIT_LOW;
-		ret = devm_gpio_request_one(&pdev->dev, panel_enable,
-					    f, "panel-enable");
-		if (ret) {
-			dev_err(&pdev->dev,
-				"failed to request gpio %d: %d\n",
-				panel_enable, ret);
-			goto fb_release;
-		}
-	}
+	host->reg_lcd = devm_regulator_get(&pdev->dev, "lcd");
 
 	fb_info->pseudo_palette = devm_kzalloc(&pdev->dev, sizeof(u32) * 16,
 					       GFP_KERNEL);
-- 
1.7.9.5




From linus.walleij at stericsson.com  Fri Apr  5 10:22:43 2013
From: linus.walleij at stericsson.com (Linus Walleij)
Date: Fri, 5 Apr 2013 16:22:43 +0200
Subject: [PATCH 01/14] ARM: ux500: move debugmacro to debug includes
In-Reply-To: <1365171776-8463-1-git-send-email-linus.walleij@stericsson.com>
References: <1365171776-8463-1-git-send-email-linus.walleij@stericsson.com>
Message-ID: <1365171776-8463-2-git-send-email-linus.walleij@stericsson.com>

From: Linus Walleij <linus.walleij at linaro.org>

This moves the Ux500 debug macro to the debug headers to
make way for multiplatform support.

Acked-by: Arnd Bergmann <arnd at arndb.de>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 arch/arm/Kconfig.debug                                            | 8 ++++++++
 .../include/mach/debug-macro.S => include/debug/ux500.S}          | 0
 2 files changed, 8 insertions(+)
 rename arch/arm/{mach-ux500/include/mach/debug-macro.S => include/debug/ux500.S} (100%)

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index acdddda..a7b6f8b 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -414,6 +414,13 @@ choice
 		  Say Y here if you want the debug print routines to direct
 		  their output to the uart1 port on SiRFmarco devices.
 
+	config DEBUG_UX500_UART
+		depends on ARCH_U8500
+		bool "Use Ux500 UART for low-level debug"
+		help
+		  Say Y here if you want kernel low-level debugging support
+		  on Ux500 based platforms.
+
 	config DEBUG_VEXPRESS_UART0_DETECT
 		bool "Autodetect UART0 on Versatile Express Cortex-A core tiles"
 		depends on ARCH_VEXPRESS && CPU_CP15_MMU
@@ -598,6 +605,7 @@ config DEBUG_LL_INCLUDE
 		DEBUG_VEXPRESS_UART0_CA9 || DEBUG_VEXPRESS_UART0_RS1
 	default "debug/vt8500.S" if DEBUG_VT8500_UART0
 	default "debug/tegra.S" if DEBUG_TEGRA_UART
+	default "debug/ux500.S" if DEBUG_UX500_UART
 	default "debug/zynq.S" if DEBUG_ZYNQ_UART0 || DEBUG_ZYNQ_UART1
 	default "mach/debug-macro.S"
 
diff --git a/arch/arm/mach-ux500/include/mach/debug-macro.S b/arch/arm/include/debug/ux500.S
similarity index 100%
rename from arch/arm/mach-ux500/include/mach/debug-macro.S
rename to arch/arm/include/debug/ux500.S
-- 
1.7.11.3



From linus.walleij at stericsson.com  Fri Apr  5 10:22:50 2013
From: linus.walleij at stericsson.com (Linus Walleij)
Date: Fri, 5 Apr 2013 16:22:50 +0200
Subject: [PATCH 08/14] ARM: ux500: make debug macro stand-alone
In-Reply-To: <1365171776-8463-1-git-send-email-linus.walleij@stericsson.com>
References: <1365171776-8463-1-git-send-email-linus.walleij@stericsson.com>
Message-ID: <1365171776-8463-9-git-send-email-linus.walleij@stericsson.com>

From: Linus Walleij <linus.walleij at linaro.org>

This pushes the knowledge of physical addresses down into
the debug macro so we can get rid of the <mach/hardware.h>
dependency.

Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 arch/arm/include/debug/ux500.S | 23 ++++++++++++++++-------
 1 file changed, 16 insertions(+), 7 deletions(-)

diff --git a/arch/arm/include/debug/ux500.S b/arch/arm/include/debug/ux500.S
index 6703522..2848857 100644
--- a/arch/arm/include/debug/ux500.S
+++ b/arch/arm/include/debug/ux500.S
@@ -8,7 +8,7 @@
  * published by the Free Software Foundation.
  *
  */
-#include <mach/hardware.h>
+
 
 #if CONFIG_UX500_DEBUG_UART > 2
 #error Invalid Ux500 debug UART
@@ -21,19 +21,28 @@
  */
 
 #ifdef CONFIG_UX500_SOC_DB8500
-#define __UX500_UART(n)	U8500_UART##n##_BASE
+#define U8500_UART0_PHYS_BASE	(0x80120000)
+#define U8500_UART1_PHYS_BASE	(0x80121000)
+#define U8500_UART2_PHYS_BASE	(0x80007000)
+#define U8500_UART0_VIRT_BASE	(0xa8120000)
+#define U8500_UART1_VIRT_BASE	(0xa8121000)
+#define U8500_UART2_VIRT_BASE	(0xa8007000)
+#define __UX500_PHYS_UART(n)	U8500_UART##n##_PHYS_BASE
+#define __UX500_VIRT_UART(n)	U8500_UART##n##_VIRT_BASE
 #endif
 
-#ifndef __UX500_UART
+#if !defined(__UX500_PHYS_UART) || !defined(__UX500_VIRT_UART)
 #error Unknown SOC
 #endif
 
-#define UX500_UART(n)	__UX500_UART(n)
-#define UART_BASE	UX500_UART(CONFIG_UX500_DEBUG_UART)
+#define UX500_PHYS_UART(n)	__UX500_PHYS_UART(n)
+#define UX500_VIRT_UART(n)	__UX500_VIRT_UART(n)
+#define UART_PHYS_BASE	UX500_PHYS_UART(CONFIG_UX500_DEBUG_UART)
+#define UART_VIRT_BASE	UX500_VIRT_UART(CONFIG_UX500_DEBUG_UART)
 
 	.macro	addruart, rp, rv, tmp
-	ldr	\rp, =UART_BASE				@ no, physical address
-	ldr	\rv, =IO_ADDRESS(UART_BASE)		@ yes, virtual address
+	ldr	\rp, =UART_PHYS_BASE		@ no, physical address
+	ldr	\rv, =UART_VIRT_BASE		@ yes, virtual address
 	.endm
 
 #include <asm/hardware/debug-pl01x.S>
-- 
1.7.11.3



From linus.walleij at stericsson.com  Fri Apr  5 10:22:44 2013
From: linus.walleij at stericsson.com (Linus Walleij)
Date: Fri, 5 Apr 2013 16:22:44 +0200
Subject: [PATCH 02/14] clk: ux500: pass clock base adresses in init call
In-Reply-To: <1365171776-8463-1-git-send-email-linus.walleij@stericsson.com>
References: <1365171776-8463-1-git-send-email-linus.walleij@stericsson.com>
Message-ID: <1365171776-8463-3-git-send-email-linus.walleij@stericsson.com>

From: Linus Walleij <linus.walleij at linaro.org>

The ux500 clock driver was including <mach/db8500-regs.h>
which will not work when building for multiplatform support
since <mach/*> is going away.

Pass the base adresses in the init call instead.

Cc: Ulf Hansson <ulf.hansson at linaro.org>
Cc: Mike Turquette <mturquette at linaro.org>
Acked-by: Arnd Bergmann <arnd at arndb.de>
Acked-by: Ulf Hansson <ulf.hansson at linaro.org>
Acked-by: Mike Turquette <mturquette at linaro.org>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 arch/arm/mach-ux500/cpu.c               |   4 +-
 drivers/clk/ux500/u8500_clk.c           | 142 ++++++++++++++++----------------
 include/linux/platform_data/clk-ux500.h |   3 +-
 3 files changed, 76 insertions(+), 73 deletions(-)

diff --git a/arch/arm/mach-ux500/cpu.c b/arch/arm/mach-ux500/cpu.c
index 537870d..741d06a 100644
--- a/arch/arm/mach-ux500/cpu.c
+++ b/arch/arm/mach-ux500/cpu.c
@@ -72,7 +72,9 @@ void __init ux500_init_irq(void)
 		db8500_prcmu_early_init();
 
 	if (cpu_is_u8500_family() || cpu_is_u9540())
-		u8500_clk_init();
+		u8500_clk_init(U8500_CLKRST1_BASE, U8500_CLKRST2_BASE,
+			       U8500_CLKRST3_BASE, U8500_CLKRST5_BASE,
+			       U8500_CLKRST6_BASE);
 	else if (cpu_is_u8540())
 		u8540_clk_init();
 }
diff --git a/drivers/clk/ux500/u8500_clk.c b/drivers/clk/ux500/u8500_clk.c
index 6b889a0..0c9b83d 100644
--- a/drivers/clk/ux500/u8500_clk.c
+++ b/drivers/clk/ux500/u8500_clk.c
@@ -12,10 +12,10 @@
 #include <linux/clk-provider.h>
 #include <linux/mfd/dbx500-prcmu.h>
 #include <linux/platform_data/clk-ux500.h>
-#include <mach/db8500-regs.h>
 #include "clk.h"
 
-void u8500_clk_init(void)
+void u8500_clk_init(u32 clkrst1_base, u32 clkrst2_base, u32 clkrst3_base,
+		    u32 clkrst5_base, u32 clkrst6_base)
 {
 	struct prcmu_fw_version *fw_version;
 	const char *sgaclk_parent = NULL;
@@ -215,147 +215,147 @@ void u8500_clk_init(void)
 	 */
 
 	/* PRCC P-clocks */
-	clk = clk_reg_prcc_pclk("p1_pclk0", "per1clk", U8500_CLKRST1_BASE,
+	clk = clk_reg_prcc_pclk("p1_pclk0", "per1clk", clkrst1_base,
 				BIT(0), 0);
 	clk_register_clkdev(clk, "apb_pclk", "uart0");
 
-	clk = clk_reg_prcc_pclk("p1_pclk1", "per1clk", U8500_CLKRST1_BASE,
+	clk = clk_reg_prcc_pclk("p1_pclk1", "per1clk", clkrst1_base,
 				BIT(1), 0);
 	clk_register_clkdev(clk, "apb_pclk", "uart1");
 
-	clk = clk_reg_prcc_pclk("p1_pclk2", "per1clk", U8500_CLKRST1_BASE,
+	clk = clk_reg_prcc_pclk("p1_pclk2", "per1clk", clkrst1_base,
 				BIT(2), 0);
 	clk_register_clkdev(clk, "apb_pclk", "nmk-i2c.1");
 
-	clk = clk_reg_prcc_pclk("p1_pclk3", "per1clk", U8500_CLKRST1_BASE,
+	clk = clk_reg_prcc_pclk("p1_pclk3", "per1clk", clkrst1_base,
 				BIT(3), 0);
 	clk_register_clkdev(clk, "apb_pclk", "msp0");
 	clk_register_clkdev(clk, "apb_pclk", "ux500-msp-i2s.0");
 
-	clk = clk_reg_prcc_pclk("p1_pclk4", "per1clk", U8500_CLKRST1_BASE,
+	clk = clk_reg_prcc_pclk("p1_pclk4", "per1clk", clkrst1_base,
 				BIT(4), 0);
 	clk_register_clkdev(clk, "apb_pclk", "msp1");
 	clk_register_clkdev(clk, "apb_pclk", "ux500-msp-i2s.1");
 
-	clk = clk_reg_prcc_pclk("p1_pclk5", "per1clk", U8500_CLKRST1_BASE,
+	clk = clk_reg_prcc_pclk("p1_pclk5", "per1clk", clkrst1_base,
 				BIT(5), 0);
 	clk_register_clkdev(clk, "apb_pclk", "sdi0");
 
-	clk = clk_reg_prcc_pclk("p1_pclk6", "per1clk", U8500_CLKRST1_BASE,
+	clk = clk_reg_prcc_pclk("p1_pclk6", "per1clk", clkrst1_base,
 				BIT(6), 0);
 	clk_register_clkdev(clk, "apb_pclk", "nmk-i2c.2");
 
-	clk = clk_reg_prcc_pclk("p1_pclk7", "per1clk", U8500_CLKRST1_BASE,
+	clk = clk_reg_prcc_pclk("p1_pclk7", "per1clk", clkrst1_base,
 				BIT(7), 0);
 	clk_register_clkdev(clk, NULL, "spi3");
 
-	clk = clk_reg_prcc_pclk("p1_pclk8", "per1clk", U8500_CLKRST1_BASE,
+	clk = clk_reg_prcc_pclk("p1_pclk8", "per1clk", clkrst1_base,
 				BIT(8), 0);
 	clk_register_clkdev(clk, "apb_pclk", "slimbus0");
 
-	clk = clk_reg_prcc_pclk("p1_pclk9", "per1clk", U8500_CLKRST1_BASE,
+	clk = clk_reg_prcc_pclk("p1_pclk9", "per1clk", clkrst1_base,
 				BIT(9), 0);
 	clk_register_clkdev(clk, NULL, "gpio.0");
 	clk_register_clkdev(clk, NULL, "gpio.1");
 	clk_register_clkdev(clk, NULL, "gpioblock0");
 
-	clk = clk_reg_prcc_pclk("p1_pclk10", "per1clk", U8500_CLKRST1_BASE,
+	clk = clk_reg_prcc_pclk("p1_pclk10", "per1clk", clkrst1_base,
 				BIT(10), 0);
 	clk_register_clkdev(clk, "apb_pclk", "nmk-i2c.4");
 
-	clk = clk_reg_prcc_pclk("p1_pclk11", "per1clk", U8500_CLKRST1_BASE,
+	clk = clk_reg_prcc_pclk("p1_pclk11", "per1clk", clkrst1_base,
 				BIT(11), 0);
 	clk_register_clkdev(clk, "apb_pclk", "msp3");
 	clk_register_clkdev(clk, "apb_pclk", "ux500-msp-i2s.3");
 
-	clk = clk_reg_prcc_pclk("p2_pclk0", "per2clk", U8500_CLKRST2_BASE,
+	clk = clk_reg_prcc_pclk("p2_pclk0", "per2clk", clkrst2_base,
 				BIT(0), 0);
 	clk_register_clkdev(clk, "apb_pclk", "nmk-i2c.3");
 
-	clk = clk_reg_prcc_pclk("p2_pclk1", "per2clk", U8500_CLKRST2_BASE,
+	clk = clk_reg_prcc_pclk("p2_pclk1", "per2clk", clkrst2_base,
 				BIT(1), 0);
 	clk_register_clkdev(clk, NULL, "spi2");
 
-	clk = clk_reg_prcc_pclk("p2_pclk2", "per2clk", U8500_CLKRST2_BASE,
+	clk = clk_reg_prcc_pclk("p2_pclk2", "per2clk", clkrst2_base,
 				BIT(2), 0);
 	clk_register_clkdev(clk, NULL, "spi1");
 
-	clk = clk_reg_prcc_pclk("p2_pclk3", "per2clk", U8500_CLKRST2_BASE,
+	clk = clk_reg_prcc_pclk("p2_pclk3", "per2clk", clkrst2_base,
 				BIT(3), 0);
 	clk_register_clkdev(clk, NULL, "pwl");
 
-	clk = clk_reg_prcc_pclk("p2_pclk4", "per2clk", U8500_CLKRST2_BASE,
+	clk = clk_reg_prcc_pclk("p2_pclk4", "per2clk", clkrst2_base,
 				BIT(4), 0);
 	clk_register_clkdev(clk, "apb_pclk", "sdi4");
 
-	clk = clk_reg_prcc_pclk("p2_pclk5", "per2clk", U8500_CLKRST2_BASE,
+	clk = clk_reg_prcc_pclk("p2_pclk5", "per2clk", clkrst2_base,
 				BIT(5), 0);
 	clk_register_clkdev(clk, "apb_pclk", "msp2");
 	clk_register_clkdev(clk, "apb_pclk", "ux500-msp-i2s.2");
 
-	clk = clk_reg_prcc_pclk("p2_pclk6", "per2clk", U8500_CLKRST2_BASE,
+	clk = clk_reg_prcc_pclk("p2_pclk6", "per2clk", clkrst2_base,
 				BIT(6), 0);
 	clk_register_clkdev(clk, "apb_pclk", "sdi1");
 
-	clk = clk_reg_prcc_pclk("p2_pclk7", "per2clk", U8500_CLKRST2_BASE,
+	clk = clk_reg_prcc_pclk("p2_pclk7", "per2clk", clkrst2_base,
 				BIT(7), 0);
 	clk_register_clkdev(clk, "apb_pclk", "sdi3");
 
-	clk = clk_reg_prcc_pclk("p2_pclk8", "per2clk", U8500_CLKRST2_BASE,
+	clk = clk_reg_prcc_pclk("p2_pclk8", "per2clk", clkrst2_base,
 				BIT(8), 0);
 	clk_register_clkdev(clk, NULL, "spi0");
 
-	clk = clk_reg_prcc_pclk("p2_pclk9", "per2clk", U8500_CLKRST2_BASE,
+	clk = clk_reg_prcc_pclk("p2_pclk9", "per2clk", clkrst2_base,
 				BIT(9), 0);
 	clk_register_clkdev(clk, "hsir_hclk", "ste_hsi.0");
 
-	clk = clk_reg_prcc_pclk("p2_pclk10", "per2clk", U8500_CLKRST2_BASE,
+	clk = clk_reg_prcc_pclk("p2_pclk10", "per2clk", clkrst2_base,
 				BIT(10), 0);
 	clk_register_clkdev(clk, "hsit_hclk", "ste_hsi.0");
 
-	clk = clk_reg_prcc_pclk("p2_pclk11", "per2clk", U8500_CLKRST2_BASE,
+	clk = clk_reg_prcc_pclk("p2_pclk11", "per2clk", clkrst2_base,
 				BIT(11), 0);
 	clk_register_clkdev(clk, NULL, "gpio.6");
 	clk_register_clkdev(clk, NULL, "gpio.7");
 	clk_register_clkdev(clk, NULL, "gpioblock1");
 
-	clk = clk_reg_prcc_pclk("p2_pclk12", "per2clk", U8500_CLKRST2_BASE,
+	clk = clk_reg_prcc_pclk("p2_pclk12", "per2clk", clkrst2_base,
 				BIT(12), 0);
 
-	clk = clk_reg_prcc_pclk("p3_pclk0", "per3clk", U8500_CLKRST3_BASE,
+	clk = clk_reg_prcc_pclk("p3_pclk0", "per3clk", clkrst3_base,
 				BIT(0), 0);
 	clk_register_clkdev(clk, NULL, "fsmc");
 
-	clk = clk_reg_prcc_pclk("p3_pclk1", "per3clk", U8500_CLKRST3_BASE,
+	clk = clk_reg_prcc_pclk("p3_pclk1", "per3clk", clkrst3_base,
 				BIT(1), 0);
 	clk_register_clkdev(clk, "apb_pclk", "ssp0");
 
-	clk = clk_reg_prcc_pclk("p3_pclk2", "per3clk", U8500_CLKRST3_BASE,
+	clk = clk_reg_prcc_pclk("p3_pclk2", "per3clk", clkrst3_base,
 				BIT(2), 0);
 	clk_register_clkdev(clk, "apb_pclk", "ssp1");
 
-	clk = clk_reg_prcc_pclk("p3_pclk3", "per3clk", U8500_CLKRST3_BASE,
+	clk = clk_reg_prcc_pclk("p3_pclk3", "per3clk", clkrst3_base,
 				BIT(3), 0);
 	clk_register_clkdev(clk, "apb_pclk", "nmk-i2c.0");
 
-	clk = clk_reg_prcc_pclk("p3_pclk4", "per3clk", U8500_CLKRST3_BASE,
+	clk = clk_reg_prcc_pclk("p3_pclk4", "per3clk", clkrst3_base,
 				BIT(4), 0);
 	clk_register_clkdev(clk, "apb_pclk", "sdi2");
 
-	clk = clk_reg_prcc_pclk("p3_pclk5", "per3clk", U8500_CLKRST3_BASE,
+	clk = clk_reg_prcc_pclk("p3_pclk5", "per3clk", clkrst3_base,
 				BIT(5), 0);
 	clk_register_clkdev(clk, "apb_pclk", "ske");
 	clk_register_clkdev(clk, "apb_pclk", "nmk-ske-keypad");
 
-	clk = clk_reg_prcc_pclk("p3_pclk6", "per3clk", U8500_CLKRST3_BASE,
+	clk = clk_reg_prcc_pclk("p3_pclk6", "per3clk", clkrst3_base,
 				BIT(6), 0);
 	clk_register_clkdev(clk, "apb_pclk", "uart2");
 
-	clk = clk_reg_prcc_pclk("p3_pclk7", "per3clk", U8500_CLKRST3_BASE,
+	clk = clk_reg_prcc_pclk("p3_pclk7", "per3clk", clkrst3_base,
 				BIT(7), 0);
 	clk_register_clkdev(clk, "apb_pclk", "sdi5");
 
-	clk = clk_reg_prcc_pclk("p3_pclk8", "per3clk", U8500_CLKRST3_BASE,
+	clk = clk_reg_prcc_pclk("p3_pclk8", "per3clk", clkrst3_base,
 				BIT(8), 0);
 	clk_register_clkdev(clk, NULL, "gpio.2");
 	clk_register_clkdev(clk, NULL, "gpio.3");
@@ -363,45 +363,45 @@ void u8500_clk_init(void)
 	clk_register_clkdev(clk, NULL, "gpio.5");
 	clk_register_clkdev(clk, NULL, "gpioblock2");
 
-	clk = clk_reg_prcc_pclk("p5_pclk0", "per5clk", U8500_CLKRST5_BASE,
+	clk = clk_reg_prcc_pclk("p5_pclk0", "per5clk", clkrst5_base,
 				BIT(0), 0);
 	clk_register_clkdev(clk, "usb", "musb-ux500.0");
 
-	clk = clk_reg_prcc_pclk("p5_pclk1", "per5clk", U8500_CLKRST5_BASE,
+	clk = clk_reg_prcc_pclk("p5_pclk1", "per5clk", clkrst5_base,
 				BIT(1), 0);
 	clk_register_clkdev(clk, NULL, "gpio.8");
 	clk_register_clkdev(clk, NULL, "gpioblock3");
 
-	clk = clk_reg_prcc_pclk("p6_pclk0", "per6clk", U8500_CLKRST6_BASE,
+	clk = clk_reg_prcc_pclk("p6_pclk0", "per6clk", clkrst6_base,
 				BIT(0), 0);
 	clk_register_clkdev(clk, "apb_pclk", "rng");
 
-	clk = clk_reg_prcc_pclk("p6_pclk1", "per6clk", U8500_CLKRST6_BASE,
+	clk = clk_reg_prcc_pclk("p6_pclk1", "per6clk", clkrst6_base,
 				BIT(1), 0);
 	clk_register_clkdev(clk, NULL, "cryp0");
 	clk_register_clkdev(clk, NULL, "cryp1");
 
-	clk = clk_reg_prcc_pclk("p6_pclk2", "per6clk", U8500_CLKRST6_BASE,
+	clk = clk_reg_prcc_pclk("p6_pclk2", "per6clk", clkrst6_base,
 				BIT(2), 0);
 	clk_register_clkdev(clk, NULL, "hash0");
 
-	clk = clk_reg_prcc_pclk("p6_pclk3", "per6clk", U8500_CLKRST6_BASE,
+	clk = clk_reg_prcc_pclk("p6_pclk3", "per6clk", clkrst6_base,
 				BIT(3), 0);
 	clk_register_clkdev(clk, NULL, "pka");
 
-	clk = clk_reg_prcc_pclk("p6_pclk4", "per6clk", U8500_CLKRST6_BASE,
+	clk = clk_reg_prcc_pclk("p6_pclk4", "per6clk", clkrst6_base,
 				BIT(4), 0);
 	clk_register_clkdev(clk, NULL, "hash1");
 
-	clk = clk_reg_prcc_pclk("p6_pclk5", "per6clk", U8500_CLKRST6_BASE,
+	clk = clk_reg_prcc_pclk("p6_pclk5", "per6clk", clkrst6_base,
 				BIT(5), 0);
 	clk_register_clkdev(clk, NULL, "cfgreg");
 
-	clk = clk_reg_prcc_pclk("p6_pclk6", "per6clk", U8500_CLKRST6_BASE,
+	clk = clk_reg_prcc_pclk("p6_pclk6", "per6clk", clkrst6_base,
 				BIT(6), 0);
 	clk_register_clkdev(clk, "apb_pclk", "mtu0");
 
-	clk = clk_reg_prcc_pclk("p6_pclk7", "per6clk", U8500_CLKRST6_BASE,
+	clk = clk_reg_prcc_pclk("p6_pclk7", "per6clk", clkrst6_base,
 				BIT(7), 0);
 	clk_register_clkdev(clk, "apb_pclk", "mtu1");
 
@@ -415,110 +415,110 @@ void u8500_clk_init(void)
 
 	/* Periph1 */
 	clk = clk_reg_prcc_kclk("p1_uart0_kclk", "uartclk",
-			U8500_CLKRST1_BASE, BIT(0), CLK_SET_RATE_GATE);
+			clkrst1_base, BIT(0), CLK_SET_RATE_GATE);
 	clk_register_clkdev(clk, NULL, "uart0");
 
 	clk = clk_reg_prcc_kclk("p1_uart1_kclk", "uartclk",
-			U8500_CLKRST1_BASE, BIT(1), CLK_SET_RATE_GATE);
+			clkrst1_base, BIT(1), CLK_SET_RATE_GATE);
 	clk_register_clkdev(clk, NULL, "uart1");
 
 	clk = clk_reg_prcc_kclk("p1_i2c1_kclk", "i2cclk",
-			U8500_CLKRST1_BASE, BIT(2), CLK_SET_RATE_GATE);
+			clkrst1_base, BIT(2), CLK_SET_RATE_GATE);
 	clk_register_clkdev(clk, NULL, "nmk-i2c.1");
 
 	clk = clk_reg_prcc_kclk("p1_msp0_kclk", "msp02clk",
-			U8500_CLKRST1_BASE, BIT(3), CLK_SET_RATE_GATE);
+			clkrst1_base, BIT(3), CLK_SET_RATE_GATE);
 	clk_register_clkdev(clk, NULL, "msp0");
 	clk_register_clkdev(clk, NULL, "ux500-msp-i2s.0");
 
 	clk = clk_reg_prcc_kclk("p1_msp1_kclk", "msp1clk",
-			U8500_CLKRST1_BASE, BIT(4), CLK_SET_RATE_GATE);
+			clkrst1_base, BIT(4), CLK_SET_RATE_GATE);
 	clk_register_clkdev(clk, NULL, "msp1");
 	clk_register_clkdev(clk, NULL, "ux500-msp-i2s.1");
 
 	clk = clk_reg_prcc_kclk("p1_sdi0_kclk", "sdmmcclk",
-			U8500_CLKRST1_BASE, BIT(5), CLK_SET_RATE_GATE);
+			clkrst1_base, BIT(5), CLK_SET_RATE_GATE);
 	clk_register_clkdev(clk, NULL, "sdi0");
 
 	clk = clk_reg_prcc_kclk("p1_i2c2_kclk", "i2cclk",
-			U8500_CLKRST1_BASE, BIT(6), CLK_SET_RATE_GATE);
+			clkrst1_base, BIT(6), CLK_SET_RATE_GATE);
 	clk_register_clkdev(clk, NULL, "nmk-i2c.2");
 
 	clk = clk_reg_prcc_kclk("p1_slimbus0_kclk", "slimclk",
-			U8500_CLKRST1_BASE, BIT(8), CLK_SET_RATE_GATE);
+			clkrst1_base, BIT(8), CLK_SET_RATE_GATE);
 	clk_register_clkdev(clk, NULL, "slimbus0");
 
 	clk = clk_reg_prcc_kclk("p1_i2c4_kclk", "i2cclk",
-			U8500_CLKRST1_BASE, BIT(9), CLK_SET_RATE_GATE);
+			clkrst1_base, BIT(9), CLK_SET_RATE_GATE);
 	clk_register_clkdev(clk, NULL, "nmk-i2c.4");
 
 	clk = clk_reg_prcc_kclk("p1_msp3_kclk", "msp1clk",
-			U8500_CLKRST1_BASE, BIT(10), CLK_SET_RATE_GATE);
+			clkrst1_base, BIT(10), CLK_SET_RATE_GATE);
 	clk_register_clkdev(clk, NULL, "msp3");
 	clk_register_clkdev(clk, NULL, "ux500-msp-i2s.3");
 
 	/* Periph2 */
 	clk = clk_reg_prcc_kclk("p2_i2c3_kclk", "i2cclk",
-			U8500_CLKRST2_BASE, BIT(0), CLK_SET_RATE_GATE);
+			clkrst2_base, BIT(0), CLK_SET_RATE_GATE);
 	clk_register_clkdev(clk, NULL, "nmk-i2c.3");
 
 	clk = clk_reg_prcc_kclk("p2_sdi4_kclk", "sdmmcclk",
-			U8500_CLKRST2_BASE, BIT(2), CLK_SET_RATE_GATE);
+			clkrst2_base, BIT(2), CLK_SET_RATE_GATE);
 	clk_register_clkdev(clk, NULL, "sdi4");
 
 	clk = clk_reg_prcc_kclk("p2_msp2_kclk", "msp02clk",
-			U8500_CLKRST2_BASE, BIT(3), CLK_SET_RATE_GATE);
+			clkrst2_base, BIT(3), CLK_SET_RATE_GATE);
 	clk_register_clkdev(clk, NULL, "msp2");
 	clk_register_clkdev(clk, NULL, "ux500-msp-i2s.2");
 
 	clk = clk_reg_prcc_kclk("p2_sdi1_kclk", "sdmmcclk",
-			U8500_CLKRST2_BASE, BIT(4), CLK_SET_RATE_GATE);
+			clkrst2_base, BIT(4), CLK_SET_RATE_GATE);
 	clk_register_clkdev(clk, NULL, "sdi1");
 
 	clk = clk_reg_prcc_kclk("p2_sdi3_kclk", "sdmmcclk",
-			U8500_CLKRST2_BASE, BIT(5), CLK_SET_RATE_GATE);
+			clkrst2_base, BIT(5), CLK_SET_RATE_GATE);
 	clk_register_clkdev(clk, NULL, "sdi3");
 
 	/* Note that rate is received from parent. */
 	clk = clk_reg_prcc_kclk("p2_ssirx_kclk", "hsirxclk",
-			U8500_CLKRST2_BASE, BIT(6),
+			clkrst2_base, BIT(6),
 			CLK_SET_RATE_GATE|CLK_SET_RATE_PARENT);
 	clk = clk_reg_prcc_kclk("p2_ssitx_kclk", "hsitxclk",
-			U8500_CLKRST2_BASE, BIT(7),
+			clkrst2_base, BIT(7),
 			CLK_SET_RATE_GATE|CLK_SET_RATE_PARENT);
 
 	/* Periph3 */
 	clk = clk_reg_prcc_kclk("p3_ssp0_kclk", "sspclk",
-			U8500_CLKRST3_BASE, BIT(1), CLK_SET_RATE_GATE);
+			clkrst3_base, BIT(1), CLK_SET_RATE_GATE);
 	clk_register_clkdev(clk, NULL, "ssp0");
 
 	clk = clk_reg_prcc_kclk("p3_ssp1_kclk", "sspclk",
-			U8500_CLKRST3_BASE, BIT(2), CLK_SET_RATE_GATE);
+			clkrst3_base, BIT(2), CLK_SET_RATE_GATE);
 	clk_register_clkdev(clk, NULL, "ssp1");
 
 	clk = clk_reg_prcc_kclk("p3_i2c0_kclk", "i2cclk",
-			U8500_CLKRST3_BASE, BIT(3), CLK_SET_RATE_GATE);
+			clkrst3_base, BIT(3), CLK_SET_RATE_GATE);
 	clk_register_clkdev(clk, NULL, "nmk-i2c.0");
 
 	clk = clk_reg_prcc_kclk("p3_sdi2_kclk", "sdmmcclk",
-			U8500_CLKRST3_BASE, BIT(4), CLK_SET_RATE_GATE);
+			clkrst3_base, BIT(4), CLK_SET_RATE_GATE);
 	clk_register_clkdev(clk, NULL, "sdi2");
 
 	clk = clk_reg_prcc_kclk("p3_ske_kclk", "rtc32k",
-			U8500_CLKRST3_BASE, BIT(5), CLK_SET_RATE_GATE);
+			clkrst3_base, BIT(5), CLK_SET_RATE_GATE);
 	clk_register_clkdev(clk, NULL, "ske");
 	clk_register_clkdev(clk, NULL, "nmk-ske-keypad");
 
 	clk = clk_reg_prcc_kclk("p3_uart2_kclk", "uartclk",
-			U8500_CLKRST3_BASE, BIT(6), CLK_SET_RATE_GATE);
+			clkrst3_base, BIT(6), CLK_SET_RATE_GATE);
 	clk_register_clkdev(clk, NULL, "uart2");
 
 	clk = clk_reg_prcc_kclk("p3_sdi5_kclk", "sdmmcclk",
-			U8500_CLKRST3_BASE, BIT(7), CLK_SET_RATE_GATE);
+			clkrst3_base, BIT(7), CLK_SET_RATE_GATE);
 	clk_register_clkdev(clk, NULL, "sdi5");
 
 	/* Periph6 */
 	clk = clk_reg_prcc_kclk("p3_rng_kclk", "rngclk",
-			U8500_CLKRST6_BASE, BIT(0), CLK_SET_RATE_GATE);
+			clkrst6_base, BIT(0), CLK_SET_RATE_GATE);
 	clk_register_clkdev(clk, NULL, "rng");
 }
diff --git a/include/linux/platform_data/clk-ux500.h b/include/linux/platform_data/clk-ux500.h
index 3af0da1..320d9c3 100644
--- a/include/linux/platform_data/clk-ux500.h
+++ b/include/linux/platform_data/clk-ux500.h
@@ -10,7 +10,8 @@
 #ifndef __CLK_UX500_H
 #define __CLK_UX500_H
 
-void u8500_clk_init(void);
+void u8500_clk_init(u32 clkrst1_base, u32 clkrst2_base, u32 clkrst3_base,
+		    u32 clkrst5_base, u32 clkrst6_base);
 void u9540_clk_init(void);
 void u8540_clk_init(void);
 
-- 
1.7.11.3



From linus.walleij at stericsson.com  Fri Apr  5 10:22:53 2013
From: linus.walleij at stericsson.com (Linus Walleij)
Date: Fri, 5 Apr 2013 16:22:53 +0200
Subject: [PATCH 11/14] ARM: ux500: make irqs.h local to platform
In-Reply-To: <1365171776-8463-1-git-send-email-linus.walleij@stericsson.com>
References: <1365171776-8463-1-git-send-email-linus.walleij@stericsson.com>
Message-ID: <1365171776-8463-12-git-send-email-linus.walleij@stericsson.com>

From: Arnd Bergmann <arnd at arndb.de>

With the PRCMU out of the way, nothing outside of mach-ux500
uses mach/irqs.h any more, so we can make it a local header file,
including the two sub-headers.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 arch/arm/mach-ux500/board-mop500-audio.c                   | 2 +-
 arch/arm/mach-ux500/board-mop500-u8500uib.c                | 2 +-
 arch/arm/mach-ux500/board-mop500.c                         | 2 +-
 arch/arm/mach-ux500/board-mop500.h                         | 2 +-
 arch/arm/mach-ux500/cpu-db8500.c                           | 2 +-
 arch/arm/mach-ux500/devices-common.c                       | 2 +-
 arch/arm/mach-ux500/devices-db8500.c                       | 2 +-
 arch/arm/mach-ux500/devices-db8500.h                       | 2 +-
 arch/arm/mach-ux500/{include/mach => }/irqs-board-mop500.h | 0
 arch/arm/mach-ux500/{include/mach => }/irqs-db8500.h       | 0
 arch/arm/mach-ux500/{include/mach => }/irqs.h              | 4 ++--
 arch/arm/mach-ux500/timer.c                                | 2 +-
 12 files changed, 11 insertions(+), 11 deletions(-)
 rename arch/arm/mach-ux500/{include/mach => }/irqs-board-mop500.h (100%)
 rename arch/arm/mach-ux500/{include/mach => }/irqs-db8500.h (100%)
 rename arch/arm/mach-ux500/{include/mach => }/irqs.h (95%)

diff --git a/arch/arm/mach-ux500/board-mop500-audio.c b/arch/arm/mach-ux500/board-mop500-audio.c
index 96e62ef..def0637 100644
--- a/arch/arm/mach-ux500/board-mop500-audio.c
+++ b/arch/arm/mach-ux500/board-mop500-audio.c
@@ -11,7 +11,7 @@
 #include <linux/platform_data/dma-ste-dma40.h>
 
 #include <mach/devices.h>
-#include <mach/irqs.h>
+#include "irqs.h"
 #include <linux/platform_data/asoc-ux500-msp.h>
 
 #include "ste-dma40-db8500.h"
diff --git a/arch/arm/mach-ux500/board-mop500-u8500uib.c b/arch/arm/mach-ux500/board-mop500-u8500uib.c
index 0b5e14a..d397c19 100644
--- a/arch/arm/mach-ux500/board-mop500-u8500uib.c
+++ b/arch/arm/mach-ux500/board-mop500-u8500uib.c
@@ -12,7 +12,7 @@
 #include <linux/mfd/tc3589x.h>
 #include <linux/input/matrix_keypad.h>
 
-#include <mach/irqs.h>
+#include "irqs.h"
 
 #include "board-mop500.h"
 
diff --git a/arch/arm/mach-ux500/board-mop500.c b/arch/arm/mach-ux500/board-mop500.c
index e1b38ef..6e8ee11 100644
--- a/arch/arm/mach-ux500/board-mop500.c
+++ b/arch/arm/mach-ux500/board-mop500.c
@@ -43,7 +43,7 @@
 
 #include <mach/setup.h>
 #include <mach/devices.h>
-#include <mach/irqs.h>
+#include "irqs.h"
 #include <linux/platform_data/crypto-ux500.h>
 
 #include "ste-dma40-db8500.h"
diff --git a/arch/arm/mach-ux500/board-mop500.h b/arch/arm/mach-ux500/board-mop500.h
index eb81caf1..16bf1ac 100644
--- a/arch/arm/mach-ux500/board-mop500.h
+++ b/arch/arm/mach-ux500/board-mop500.h
@@ -8,7 +8,7 @@
 #define __BOARD_MOP500_H
 
 /* For NOMADIK_NR_GPIO */
-#include <mach/irqs.h>
+#include "irqs.h"
 #include <linux/platform_data/asoc-ux500-msp.h>
 #include <linux/amba/mmci.h>
 
diff --git a/arch/arm/mach-ux500/cpu-db8500.c b/arch/arm/mach-ux500/cpu-db8500.c
index d726c06..e11f87d 100644
--- a/arch/arm/mach-ux500/cpu-db8500.c
+++ b/arch/arm/mach-ux500/cpu-db8500.c
@@ -30,7 +30,7 @@
 
 #include <mach/setup.h>
 #include <mach/devices.h>
-#include <mach/irqs.h>
+#include "irqs.h"
 
 #include "devices-db8500.h"
 #include "ste-dma40-db8500.h"
diff --git a/arch/arm/mach-ux500/devices-common.c b/arch/arm/mach-ux500/devices-common.c
index 94868b7..f71b3d7 100644
--- a/arch/arm/mach-ux500/devices-common.c
+++ b/arch/arm/mach-ux500/devices-common.c
@@ -13,7 +13,7 @@
 #include <linux/platform_device.h>
 #include <linux/platform_data/pinctrl-nomadik.h>
 
-#include <mach/irqs.h>
+#include "irqs.h"
 
 #include "devices-common.h"
 
diff --git a/arch/arm/mach-ux500/devices-db8500.c b/arch/arm/mach-ux500/devices-db8500.c
index 4c0ef14..45ec955 100644
--- a/arch/arm/mach-ux500/devices-db8500.c
+++ b/arch/arm/mach-ux500/devices-db8500.c
@@ -16,7 +16,7 @@
 #include <linux/mfd/dbx500-prcmu.h>
 
 #include <mach/setup.h>
-#include <mach/irqs.h>
+#include "irqs.h"
 
 #include "db8500-regs.h"
 #include "devices-db8500.h"
diff --git a/arch/arm/mach-ux500/devices-db8500.h b/arch/arm/mach-ux500/devices-db8500.h
index c9db210..3219983 100644
--- a/arch/arm/mach-ux500/devices-db8500.h
+++ b/arch/arm/mach-ux500/devices-db8500.h
@@ -9,7 +9,7 @@
 #define __DEVICES_DB8500_H
 
 #include <linux/platform_data/usb-musb-ux500.h>
-#include <mach/irqs.h>
+#include "irqs.h"
 #include "db8500-regs.h"
 #include "devices-common.h"
 
diff --git a/arch/arm/mach-ux500/include/mach/irqs-board-mop500.h b/arch/arm/mach-ux500/irqs-board-mop500.h
similarity index 100%
rename from arch/arm/mach-ux500/include/mach/irqs-board-mop500.h
rename to arch/arm/mach-ux500/irqs-board-mop500.h
diff --git a/arch/arm/mach-ux500/include/mach/irqs-db8500.h b/arch/arm/mach-ux500/irqs-db8500.h
similarity index 100%
rename from arch/arm/mach-ux500/include/mach/irqs-db8500.h
rename to arch/arm/mach-ux500/irqs-db8500.h
diff --git a/arch/arm/mach-ux500/include/mach/irqs.h b/arch/arm/mach-ux500/irqs.h
similarity index 95%
rename from arch/arm/mach-ux500/include/mach/irqs.h
rename to arch/arm/mach-ux500/irqs.h
index 829947d..15b2af6 100644
--- a/arch/arm/mach-ux500/include/mach/irqs.h
+++ b/arch/arm/mach-ux500/irqs.h
@@ -34,14 +34,14 @@
 /* This will be overridden by SoC-specific irq headers */
 #define IRQ_SOC_END		IRQ_SOC_START
 
-#include <mach/irqs-db8500.h>
+#include "irqs-db8500.h"
 
 #define IRQ_BOARD_START		IRQ_SOC_END
 /* This will be overridden by board-specific irq headers */
 #define IRQ_BOARD_END		IRQ_BOARD_START
 
 #ifdef CONFIG_MACH_MOP500
-#include <mach/irqs-board-mop500.h>
+#include "irqs-board-mop500.h"
 #endif
 
 #define UX500_NR_IRQS		IRQ_BOARD_END
diff --git a/arch/arm/mach-ux500/timer.c b/arch/arm/mach-ux500/timer.c
index 5b91fac..2dbbaef 100644
--- a/arch/arm/mach-ux500/timer.c
+++ b/arch/arm/mach-ux500/timer.c
@@ -14,7 +14,7 @@
 #include <asm/smp_twd.h>
 
 #include <mach/setup.h>
-#include <mach/irqs.h>
+#include "irqs.h"
 
 #include "db8500-regs.h"
 #include "id.h"
-- 
1.7.11.3



From linus.walleij at stericsson.com  Fri Apr  5 10:22:42 2013
From: linus.walleij at stericsson.com (Linus Walleij)
Date: Fri, 5 Apr 2013 16:22:42 +0200
Subject: [PATCH 00/14] Ux500 multiplatform v2
Message-ID: <1365171776-8463-1-git-send-email-linus.walleij@stericsson.com>

From: Linus Walleij <linus.walleij at linaro.org>

This is the complete Ux500 multiplatform patchset.

The only thing missing is a few ACKs from the MFD
maintainer (Samuel Ortiz).

Arnd Bergmann (7):
  ARM: ux500: move mach/msp.h to <linux/platform_data/*>
  staging: ste_rmi4: kill platform_data hack
  ARM: ux500: split out prcmu initialization
  ARM: ux500: make irqs.h local to platform
  ARM: ux500: make remaining headers local
  ARM: ux500: move to multiplatform
  ARM: ux500: build hotplug.o for ARMv7-a

Linus Walleij (7):
  ARM: ux500: move debugmacro to debug includes
  clk: ux500: pass clock base adresses in init call
  mfd: prcmu: pass a base and size with the early initcall
  mfd: db8500-prcmu: get base address from resource
  ARM: ux500: move PM-related PRCMU functions to machine
  ARM: ux500: make debug macro stand-alone
  ARM: ux500: get rid of <mach/[hardware|db8500-regs].h>

 arch/arm/Kconfig                                   |  15 -
 arch/arm/Kconfig.debug                             |   8 +
 arch/arm/include/debug/ux500.S                     |  48 ++++
 arch/arm/mach-ux500/Kconfig                        |  14 +
 arch/arm/mach-ux500/Makefile                       |   4 +-
 arch/arm/mach-ux500/board-mop500-audio.c           |   7 +-
 arch/arm/mach-ux500/board-mop500-pins.c            |   2 -
 arch/arm/mach-ux500/board-mop500-sdi.c             |   4 +-
 arch/arm/mach-ux500/board-mop500-u8500uib.c        |   9 +-
 arch/arm/mach-ux500/board-mop500-uib.c             |   1 -
 arch/arm/mach-ux500/board-mop500.c                 |  66 +----
 arch/arm/mach-ux500/board-mop500.h                 |   4 +-
 arch/arm/mach-ux500/cache-l2x0.c                   |   2 +-
 arch/arm/mach-ux500/cpu-db8500.c                   |  12 +-
 arch/arm/mach-ux500/cpu.c                          |  33 ++-
 arch/arm/mach-ux500/cpuidle.c                      |   5 +-
 .../mach-ux500/{include/mach => }/db8500-regs.h    |  28 ++
 arch/arm/mach-ux500/devices-common.c               |   3 +-
 arch/arm/mach-ux500/devices-db8500.c               |   8 +-
 arch/arm/mach-ux500/devices-db8500.h               |   3 +-
 arch/arm/mach-ux500/devices.c                      |   5 +-
 arch/arm/mach-ux500/{include/mach => }/devices.h   |   0
 arch/arm/mach-ux500/hotplug.c                      |   2 +-
 arch/arm/mach-ux500/id.c                           |   4 +-
 arch/arm/mach-ux500/include/mach/debug-macro.S     |  39 ---
 arch/arm/mach-ux500/include/mach/hardware.h        |  47 ---
 arch/arm/mach-ux500/include/mach/timex.h           |   6 -
 arch/arm/mach-ux500/include/mach/uncompress.h      |  57 ----
 .../{include/mach => }/irqs-board-mop500.h         |   0
 .../mach-ux500/{include/mach => }/irqs-db8500.h    |  25 --
 arch/arm/mach-ux500/{include/mach => }/irqs.h      |   6 +-
 arch/arm/mach-ux500/platsmp.c                      |   4 +-
 arch/arm/mach-ux500/pm.c                           | 167 +++++++++++
 arch/arm/mach-ux500/{include/mach => }/setup.h     |   0
 arch/arm/mach-ux500/timer.c                        |   6 +-
 arch/arm/mach-ux500/usb.c                          |   2 +-
 drivers/clk/ux500/clk-prcc.c                       |   1 -
 drivers/clk/ux500/u8500_clk.c                      | 142 ++++-----
 drivers/clocksource/clksrc-dbx500-prcmu.c          |   3 -
 drivers/crypto/ux500/cryp/cryp.c                   |   2 -
 drivers/crypto/ux500/cryp/cryp_core.c              |   1 -
 drivers/crypto/ux500/hash/hash_core.c              |   1 -
 drivers/mfd/db8500-prcmu.c                         | 316 ++++++++++-----------
 drivers/mfd/dbx500-prcmu-regs.h                    | 204 ++++++-------
 drivers/staging/ste_rmi4/Makefile                  |   1 -
 .../staging/ste_rmi4/board-mop500-u8500uib-rmi4.c  |  31 --
 drivers/staging/ste_rmi4/synaptics_i2c_rmi4.c      |  31 +-
 drivers/staging/ste_rmi4/synaptics_i2c_rmi4.h      |   1 -
 include/linux/mfd/db8500-prcmu.h                   |  10 +-
 include/linux/mfd/dbx500-prcmu.h                   |  38 +--
 include/linux/platform_data/arm-ux500-pm.h         |  21 ++
 .../linux/platform_data/asoc-ux500-msp.h           |   0
 include/linux/platform_data/clk-ux500.h            |   3 +-
 sound/soc/ux500/mop500_ab8500.c                    |   2 -
 sound/soc/ux500/ux500_msp_dai.c                    |   4 +-
 sound/soc/ux500/ux500_msp_i2s.c                    |   4 +-
 sound/soc/ux500/ux500_msp_i2s.h                    |   2 -
 57 files changed, 699 insertions(+), 765 deletions(-)
 create mode 100644 arch/arm/include/debug/ux500.S
 rename arch/arm/mach-ux500/{include/mach => }/db8500-regs.h (88%)
 rename arch/arm/mach-ux500/{include/mach => }/devices.h (100%)
 delete mode 100644 arch/arm/mach-ux500/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-ux500/include/mach/hardware.h
 delete mode 100644 arch/arm/mach-ux500/include/mach/timex.h
 delete mode 100644 arch/arm/mach-ux500/include/mach/uncompress.h
 rename arch/arm/mach-ux500/{include/mach => }/irqs-board-mop500.h (100%)
 rename arch/arm/mach-ux500/{include/mach => }/irqs-db8500.h (83%)
 rename arch/arm/mach-ux500/{include/mach => }/irqs.h (93%)
 create mode 100644 arch/arm/mach-ux500/pm.c
 rename arch/arm/mach-ux500/{include/mach => }/setup.h (100%)
 delete mode 100644 drivers/staging/ste_rmi4/board-mop500-u8500uib-rmi4.c
 create mode 100644 include/linux/platform_data/arm-ux500-pm.h
 rename arch/arm/mach-ux500/include/mach/msp.h => include/linux/platform_data/asoc-ux500-msp.h (100%)

-- 
1.7.11.3



From linus.walleij at stericsson.com  Fri Apr  5 10:22:45 2013
From: linus.walleij at stericsson.com (Linus Walleij)
Date: Fri, 5 Apr 2013 16:22:45 +0200
Subject: [PATCH 03/14] ARM: ux500: move mach/msp.h to <linux/platform_data/*>
In-Reply-To: <1365171776-8463-1-git-send-email-linus.walleij@stericsson.com>
References: <1365171776-8463-1-git-send-email-linus.walleij@stericsson.com>
Message-ID: <1365171776-8463-4-git-send-email-linus.walleij@stericsson.com>

From: Arnd Bergmann <arnd at arndb.de>

This header file only contains platform data structure definitions,
so it's straightforward to move.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
[Delete one include rather than move it]
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 arch/arm/mach-ux500/board-mop500-audio.c                                | 2 +-
 arch/arm/mach-ux500/board-mop500.h                                      | 2 +-
 .../include/mach/msp.h => include/linux/platform_data/asoc-ux500-msp.h  | 0
 sound/soc/ux500/ux500_msp_dai.c                                         | 2 +-
 sound/soc/ux500/ux500_msp_i2s.c                                         | 2 +-
 sound/soc/ux500/ux500_msp_i2s.h                                         | 2 --
 6 files changed, 4 insertions(+), 6 deletions(-)
 rename arch/arm/mach-ux500/include/mach/msp.h => include/linux/platform_data/asoc-ux500-msp.h (100%)

diff --git a/arch/arm/mach-ux500/board-mop500-audio.c b/arch/arm/mach-ux500/board-mop500-audio.c
index 7209db7..43bbee1 100644
--- a/arch/arm/mach-ux500/board-mop500-audio.c
+++ b/arch/arm/mach-ux500/board-mop500-audio.c
@@ -13,7 +13,7 @@
 #include <mach/devices.h>
 #include <mach/hardware.h>
 #include <mach/irqs.h>
-#include <mach/msp.h>
+#include <linux/platform_data/asoc-ux500-msp.h>
 
 #include "ste-dma40-db8500.h"
 #include "board-mop500.h"
diff --git a/arch/arm/mach-ux500/board-mop500.h b/arch/arm/mach-ux500/board-mop500.h
index eaa605f..eb81caf1 100644
--- a/arch/arm/mach-ux500/board-mop500.h
+++ b/arch/arm/mach-ux500/board-mop500.h
@@ -9,7 +9,7 @@
 
 /* For NOMADIK_NR_GPIO */
 #include <mach/irqs.h>
-#include <mach/msp.h>
+#include <linux/platform_data/asoc-ux500-msp.h>
 #include <linux/amba/mmci.h>
 
 /* Snowball specific GPIO assignments, this board has no GPIO expander */
diff --git a/arch/arm/mach-ux500/include/mach/msp.h b/include/linux/platform_data/asoc-ux500-msp.h
similarity index 100%
rename from arch/arm/mach-ux500/include/mach/msp.h
rename to include/linux/platform_data/asoc-ux500-msp.h
diff --git a/sound/soc/ux500/ux500_msp_dai.c b/sound/soc/ux500/ux500_msp_dai.c
index 94a3e57..0d9713e 100644
--- a/sound/soc/ux500/ux500_msp_dai.c
+++ b/sound/soc/ux500/ux500_msp_dai.c
@@ -19,9 +19,9 @@
 #include <linux/clk.h>
 #include <linux/regulator/consumer.h>
 #include <linux/mfd/dbx500-prcmu.h>
+#include <linux/platform_data/asoc-ux500-msp.h>
 
 #include <mach/hardware.h>
-#include <mach/msp.h>
 
 #include <sound/soc.h>
 #include <sound/soc-dai.h>
diff --git a/sound/soc/ux500/ux500_msp_i2s.c b/sound/soc/ux500/ux500_msp_i2s.c
index a26c6bf..a582007 100644
--- a/sound/soc/ux500/ux500_msp_i2s.c
+++ b/sound/soc/ux500/ux500_msp_i2s.c
@@ -20,9 +20,9 @@
 #include <linux/slab.h>
 #include <linux/io.h>
 #include <linux/of.h>
+#include <linux/platform_data/asoc-ux500-msp.h>
 
 #include <mach/hardware.h>
-#include <mach/msp.h>
 
 #include <sound/soc.h>
 
diff --git a/sound/soc/ux500/ux500_msp_i2s.h b/sound/soc/ux500/ux500_msp_i2s.h
index 1311c0d..437f0c0 100644
--- a/sound/soc/ux500/ux500_msp_i2s.h
+++ b/sound/soc/ux500/ux500_msp_i2s.h
@@ -17,8 +17,6 @@
 
 #include <linux/platform_device.h>
 
-#include <mach/msp.h>
-
 #define MSP_INPUT_FREQ_APB 48000000
 
 /*** Stereo mode. Used for APB data accesses as 16 bits accesses (mono),
-- 
1.7.11.3



From linus.walleij at stericsson.com  Fri Apr  5 10:22:54 2013
From: linus.walleij at stericsson.com (Linus Walleij)
Date: Fri, 5 Apr 2013 16:22:54 +0200
Subject: [PATCH 12/14] ARM: ux500: make remaining headers local
In-Reply-To: <1365171776-8463-1-git-send-email-linus.walleij@stericsson.com>
References: <1365171776-8463-1-git-send-email-linus.walleij@stericsson.com>
Message-ID: <1365171776-8463-13-git-send-email-linus.walleij@stericsson.com>

From: Arnd Bergmann <arnd at arndb.de>

mach/setup.h and mach/devices.h are only needed from inside of mach-ux500
now, so we can simply move them out of the include/mach directory.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 arch/arm/mach-ux500/board-mop500-audio.c         | 2 +-
 arch/arm/mach-ux500/board-mop500-sdi.c           | 2 +-
 arch/arm/mach-ux500/board-mop500.c               | 4 ++--
 arch/arm/mach-ux500/cpu-db8500.c                 | 4 ++--
 arch/arm/mach-ux500/cpu.c                        | 4 ++--
 arch/arm/mach-ux500/devices-db8500.c             | 2 +-
 arch/arm/mach-ux500/devices.c                    | 2 +-
 arch/arm/mach-ux500/{include/mach => }/devices.h | 0
 arch/arm/mach-ux500/hotplug.c                    | 2 +-
 arch/arm/mach-ux500/id.c                         | 2 +-
 arch/arm/mach-ux500/platsmp.c                    | 2 +-
 arch/arm/mach-ux500/{include/mach => }/setup.h   | 0
 arch/arm/mach-ux500/timer.c                      | 2 +-
 drivers/clocksource/clksrc-dbx500-prcmu.c        | 2 --
 14 files changed, 14 insertions(+), 16 deletions(-)
 rename arch/arm/mach-ux500/{include/mach => }/devices.h (100%)
 rename arch/arm/mach-ux500/{include/mach => }/setup.h (100%)

diff --git a/arch/arm/mach-ux500/board-mop500-audio.c b/arch/arm/mach-ux500/board-mop500-audio.c
index def0637..aba9e56 100644
--- a/arch/arm/mach-ux500/board-mop500-audio.c
+++ b/arch/arm/mach-ux500/board-mop500-audio.c
@@ -10,7 +10,7 @@
 #include <linux/platform_data/pinctrl-nomadik.h>
 #include <linux/platform_data/dma-ste-dma40.h>
 
-#include <mach/devices.h>
+#include "devices.h"
 #include "irqs.h"
 #include <linux/platform_data/asoc-ux500-msp.h>
 
diff --git a/arch/arm/mach-ux500/board-mop500-sdi.c b/arch/arm/mach-ux500/board-mop500-sdi.c
index 0ada767..f76be4a 100644
--- a/arch/arm/mach-ux500/board-mop500-sdi.c
+++ b/arch/arm/mach-ux500/board-mop500-sdi.c
@@ -14,7 +14,7 @@
 #include <linux/platform_data/dma-ste-dma40.h>
 
 #include <asm/mach-types.h>
-#include <mach/devices.h>
+#include "devices.h"
 
 #include "db8500-regs.h"
 #include "devices-db8500.h"
diff --git a/arch/arm/mach-ux500/board-mop500.c b/arch/arm/mach-ux500/board-mop500.c
index 6e8ee11..0d59e1a 100644
--- a/arch/arm/mach-ux500/board-mop500.c
+++ b/arch/arm/mach-ux500/board-mop500.c
@@ -41,8 +41,8 @@
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
 
-#include <mach/setup.h>
-#include <mach/devices.h>
+#include "setup.h"
+#include "devices.h"
 #include "irqs.h"
 #include <linux/platform_data/crypto-ux500.h>
 
diff --git a/arch/arm/mach-ux500/cpu-db8500.c b/arch/arm/mach-ux500/cpu-db8500.c
index e11f87d..7a66a81 100644
--- a/arch/arm/mach-ux500/cpu-db8500.c
+++ b/arch/arm/mach-ux500/cpu-db8500.c
@@ -28,8 +28,8 @@
 #include <asm/mach/map.h>
 #include <asm/mach/arch.h>
 
-#include <mach/setup.h>
-#include <mach/devices.h>
+#include "setup.h"
+#include "devices.h"
 #include "irqs.h"
 
 #include "devices-db8500.h"
diff --git a/arch/arm/mach-ux500/cpu.c b/arch/arm/mach-ux500/cpu.c
index aa14c5f..915e263 100644
--- a/arch/arm/mach-ux500/cpu.c
+++ b/arch/arm/mach-ux500/cpu.c
@@ -24,8 +24,8 @@
 
 #include <asm/mach/map.h>
 
-#include <mach/setup.h>
-#include <mach/devices.h>
+#include "setup.h"
+#include "devices.h"
 
 #include "board-mop500.h"
 #include "db8500-regs.h"
diff --git a/arch/arm/mach-ux500/devices-db8500.c b/arch/arm/mach-ux500/devices-db8500.c
index 45ec955..1cf94ce 100644
--- a/arch/arm/mach-ux500/devices-db8500.c
+++ b/arch/arm/mach-ux500/devices-db8500.c
@@ -15,7 +15,7 @@
 #include <linux/platform_data/dma-ste-dma40.h>
 #include <linux/mfd/dbx500-prcmu.h>
 
-#include <mach/setup.h>
+#include "setup.h"
 #include "irqs.h"
 
 #include "db8500-regs.h"
diff --git a/arch/arm/mach-ux500/devices.c b/arch/arm/mach-ux500/devices.c
index f63a512..0f9e52b 100644
--- a/arch/arm/mach-ux500/devices.c
+++ b/arch/arm/mach-ux500/devices.c
@@ -11,7 +11,7 @@
 #include <linux/io.h>
 #include <linux/amba/bus.h>
 
-#include <mach/setup.h>
+#include "setup.h"
 
 #include "db8500-regs.h"
 
diff --git a/arch/arm/mach-ux500/include/mach/devices.h b/arch/arm/mach-ux500/devices.h
similarity index 100%
rename from arch/arm/mach-ux500/include/mach/devices.h
rename to arch/arm/mach-ux500/devices.h
diff --git a/arch/arm/mach-ux500/hotplug.c b/arch/arm/mach-ux500/hotplug.c
index 2f6af25..87abcf2 100644
--- a/arch/arm/mach-ux500/hotplug.c
+++ b/arch/arm/mach-ux500/hotplug.c
@@ -15,7 +15,7 @@
 #include <asm/cacheflush.h>
 #include <asm/smp_plat.h>
 
-#include <mach/setup.h>
+#include "setup.h"
 
 /*
  * platform-specific code to shutdown a CPU
diff --git a/arch/arm/mach-ux500/id.c b/arch/arm/mach-ux500/id.c
index a847cf2..0d33d1a 100644
--- a/arch/arm/mach-ux500/id.c
+++ b/arch/arm/mach-ux500/id.c
@@ -14,7 +14,7 @@
 #include <asm/cacheflush.h>
 #include <asm/mach/map.h>
 
-#include <mach/setup.h>
+#include "setup.h"
 
 #include "db8500-regs.h"
 #include "id.h"
diff --git a/arch/arm/mach-ux500/platsmp.c b/arch/arm/mach-ux500/platsmp.c
index 8a9c070..12ad8ad 100644
--- a/arch/arm/mach-ux500/platsmp.c
+++ b/arch/arm/mach-ux500/platsmp.c
@@ -22,7 +22,7 @@
 #include <asm/smp_plat.h>
 #include <asm/smp_scu.h>
 
-#include <mach/setup.h>
+#include "setup.h"
 
 #include "db8500-regs.h"
 #include "id.h"
diff --git a/arch/arm/mach-ux500/include/mach/setup.h b/arch/arm/mach-ux500/setup.h
similarity index 100%
rename from arch/arm/mach-ux500/include/mach/setup.h
rename to arch/arm/mach-ux500/setup.h
diff --git a/arch/arm/mach-ux500/timer.c b/arch/arm/mach-ux500/timer.c
index 2dbbaef..290b9c5 100644
--- a/arch/arm/mach-ux500/timer.c
+++ b/arch/arm/mach-ux500/timer.c
@@ -13,7 +13,7 @@
 
 #include <asm/smp_twd.h>
 
-#include <mach/setup.h>
+#include "setup.h"
 #include "irqs.h"
 
 #include "db8500-regs.h"
diff --git a/drivers/clocksource/clksrc-dbx500-prcmu.c b/drivers/clocksource/clksrc-dbx500-prcmu.c
index 4f34093..54f3d11 100644
--- a/drivers/clocksource/clksrc-dbx500-prcmu.c
+++ b/drivers/clocksource/clksrc-dbx500-prcmu.c
@@ -17,8 +17,6 @@
 
 #include <asm/sched_clock.h>
 
-#include <mach/setup.h>
-
 #define RATE_32K		32768
 
 #define TIMER_MODE_CONTINOUS	0x1
-- 
1.7.11.3



From linus.walleij at stericsson.com  Fri Apr  5 10:22:47 2013
From: linus.walleij at stericsson.com (Linus Walleij)
Date: Fri, 5 Apr 2013 16:22:47 +0200
Subject: [PATCH 05/14] mfd: prcmu: pass a base and size with the early initcall
In-Reply-To: <1365171776-8463-1-git-send-email-linus.walleij@stericsson.com>
References: <1365171776-8463-1-git-send-email-linus.walleij@stericsson.com>
Message-ID: <1365171776-8463-6-git-send-email-linus.walleij@stericsson.com>

From: Linus Walleij <linus.walleij at linaro.org>

This patch will make an early remapping of the PRCMU, to be
used when setting up the clocks, that will call down into parts
of the PRCMU driver before it is probed.

Going forward this will be removed like this:

- The mailbox subsystem need to be merged.
  http://marc.info/?l=linux-kernel&m=136314559201983&w=2

- At this point the PRCMU clock code can be moved over to the
  ux500 clock driver in drivers/clk/ux500/* and maintained
  there in a decentralized manner.

- This early initcall and PRCMU base parameters become part of
  the ux500_clk_init() call instead.

Cc: Suman Anna <s-anna at ti.com>
Cc: Loic Pallardy <loic.pallardy at st.com>
Cc: Samuel Ortiz <sameo at linux.intel.com>
Acked-by: Arnd Bergmann <arnd at arndb.de>
Acked-by: Ulf Hansson <ulf.hansson at linaro.org>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 arch/arm/mach-ux500/cpu.c        | 17 +++++++++++------
 drivers/mfd/db8500-prcmu.c       | 13 ++++++++++++-
 include/linux/mfd/db8500-prcmu.h |  4 ++--
 include/linux/mfd/dbx500-prcmu.h |  6 +++---
 4 files changed, 28 insertions(+), 12 deletions(-)

diff --git a/arch/arm/mach-ux500/cpu.c b/arch/arm/mach-ux500/cpu.c
index 741d06a..af13b6d 100644
--- a/arch/arm/mach-ux500/cpu.c
+++ b/arch/arm/mach-ux500/cpu.c
@@ -8,7 +8,7 @@
 
 #include <linux/platform_device.h>
 #include <linux/io.h>
-#include <linux/mfd/db8500-prcmu.h>
+#include <linux/mfd/dbx500-prcmu.h>
 #include <linux/clksrc-dbx500-prcmu.h>
 #include <linux/sys_soc.h>
 #include <linux/err.h>
@@ -68,15 +68,20 @@ void __init ux500_init_irq(void)
 	 * Init clocks here so that they are available for system timer
 	 * initialization.
 	 */
-	if (cpu_is_u8500_family() || cpu_is_u9540())
-		db8500_prcmu_early_init();
-
-	if (cpu_is_u8500_family() || cpu_is_u9540())
+	if (cpu_is_u8500_family()) {
+		prcmu_early_init(U8500_PRCMU_BASE, SZ_8K - 1);
 		u8500_clk_init(U8500_CLKRST1_BASE, U8500_CLKRST2_BASE,
 			       U8500_CLKRST3_BASE, U8500_CLKRST5_BASE,
 			       U8500_CLKRST6_BASE);
-	else if (cpu_is_u8540())
+	} else if (cpu_is_u9540()) {
+		prcmu_early_init(U8500_PRCMU_BASE, SZ_8K - 1);
+		u8500_clk_init(U8500_CLKRST1_BASE, U8500_CLKRST2_BASE,
+			       U8500_CLKRST3_BASE, U8500_CLKRST5_BASE,
+			       U8500_CLKRST6_BASE);
+	} else if (cpu_is_u8540()) {
+		prcmu_early_init(U8500_PRCMU_BASE, SZ_8K + SZ_4K - 1);
 		u8540_clk_init();
+	}
 }
 
 void __init ux500_init_late(void)
diff --git a/drivers/mfd/db8500-prcmu.c b/drivers/mfd/db8500-prcmu.c
index 21f261b..9166427 100644
--- a/drivers/mfd/db8500-prcmu.c
+++ b/drivers/mfd/db8500-prcmu.c
@@ -2825,8 +2825,19 @@ static void dbx500_fw_version_init(struct platform_device *pdev,
 	}
 }
 
-void __init db8500_prcmu_early_init(void)
+void __init db8500_prcmu_early_init(u32 phy_base, u32 size)
 {
+	/*
+	 * This is a temporary remap to bring up the clocks. It is
+	 * subsequently replaces with a real remap. After the merge of
+	 * the mailbox subsystem all of this early code goes away, and the
+	 * clock driver can probe independently. An early initcall will
+	 * still be needed, but it can be diverted into drivers/clk/ux500/*.
+	 */
+	prcmu_base = ioremap(phy_base, size);
+	if (!prcmu_base)
+		pr_err("%s: ioremap() of prcmu registers failed!\n", __func__);
+
 	spin_lock_init(&mb0_transfer.lock);
 	spin_lock_init(&mb0_transfer.dbb_irqs_lock);
 	mutex_init(&mb0_transfer.ac_wake_lock);
diff --git a/include/linux/mfd/db8500-prcmu.h b/include/linux/mfd/db8500-prcmu.h
index 77a46ae..ac943df 100644
--- a/include/linux/mfd/db8500-prcmu.h
+++ b/include/linux/mfd/db8500-prcmu.h
@@ -489,7 +489,7 @@ struct prcmu_auto_pm_config {
 
 #ifdef CONFIG_MFD_DB8500_PRCMU
 
-void db8500_prcmu_early_init(void);
+void db8500_prcmu_early_init(u32 phy_base, u32 size);
 int prcmu_set_rc_a2p(enum romcode_write);
 enum romcode_read prcmu_get_rc_p2a(void);
 enum ap_pwrst prcmu_get_xp70_current_state(void);
@@ -553,7 +553,7 @@ void db8500_prcmu_write_masked(unsigned int reg, u32 mask, u32 value);
 
 #else /* !CONFIG_MFD_DB8500_PRCMU */
 
-static inline void db8500_prcmu_early_init(void) {}
+static inline void db8500_prcmu_early_init(u32 phy_base, u32 size) {}
 
 static inline int prcmu_set_rc_a2p(enum romcode_write code)
 {
diff --git a/include/linux/mfd/dbx500-prcmu.h b/include/linux/mfd/dbx500-prcmu.h
index 3abcca9..8c546cb 100644
--- a/include/linux/mfd/dbx500-prcmu.h
+++ b/include/linux/mfd/dbx500-prcmu.h
@@ -276,9 +276,9 @@ struct prcmu_fw_version {
 
 #if defined(CONFIG_UX500_SOC_DB8500)
 
-static inline void __init prcmu_early_init(void)
+static inline void prcmu_early_init(u32 phy_base, u32 size)
 {
-	return db8500_prcmu_early_init();
+	return db8500_prcmu_early_init(phy_base, size);
 }
 
 static inline int prcmu_set_power_state(u8 state, bool keep_ulp_clk,
@@ -500,7 +500,7 @@ static inline int prcmu_config_a9wdog(u8 num, bool sleep_auto_off)
 }
 #else
 
-static inline void __init prcmu_early_init(void) {}
+static inline void prcmu_early_init(u32 phy_base, u32 size) {}
 
 static inline int prcmu_set_power_state(u8 state, bool keep_ulp_clk,
 	bool keep_ap_pll)
-- 
1.7.11.3



From linus.walleij at stericsson.com  Fri Apr  5 10:22:49 2013
From: linus.walleij at stericsson.com (Linus Walleij)
Date: Fri, 5 Apr 2013 16:22:49 +0200
Subject: [PATCH 07/14] ARM: ux500: move PM-related PRCMU functions to machine
In-Reply-To: <1365171776-8463-1-git-send-email-linus.walleij@stericsson.com>
References: <1365171776-8463-1-git-send-email-linus.walleij@stericsson.com>
Message-ID: <1365171776-8463-8-git-send-email-linus.walleij@stericsson.com>

From: Linus Walleij <linus.walleij at linaro.org>

We are trying to decompose and decentralize the code in
the DB8500 PRCMU out into subdrivers. The code moved in
this patch concerns a group of functions used for
decoupling and recoupling the IRQs from the GIC. During
sleep and idle the Ux500 system will transfer all IRQ
handling to the PRCMU using these functions.

Basically we are left with the two alternatives of code
placement as:

- arch/arm/mach-ux500/pm.c - this because the code is
  closely related to the GIC, and takes ownership of
  some of the registers from the PRCMU related to this
  PM functionality.

- drivers/mfd/db8500-prcmu-pm.c - because the code is
  affecting stuff in the PRCMU register range. But then
  this code needs to remap and handle GIC registers.

This patch implementation is taking the first approach.

Currently the cpuidle driver is the only piece of code
using this set of functions, but it will later also be
used by the suspend/resume code which is currently under
review.

The header file is moved to:
<linux/platform_data/arm-ux500-pm.h>
The function prototypes need to be placed in a globally
visible header since the CPUidle code is planned to move
out to drivers/cpuidle.

Cc: Samuel Ortiz <sameo at linux.intel.com>
Acked-by: Rickard Andersson <rickard.andersson at stericsson.com>
Acked-by: Daniel Lezcano <daniel.lezcano at linaro.org>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
Sam, I'm requesting an ACK for taking this through the
ARM SoC tree.
---
 arch/arm/mach-ux500/Makefile               |   2 +-
 arch/arm/mach-ux500/cpu.c                  |   4 +
 arch/arm/mach-ux500/cpuidle.c              |   3 +-
 arch/arm/mach-ux500/pm.c                   | 167 +++++++++++++++++++++++++++++
 drivers/mfd/db8500-prcmu.c                 | 114 --------------------
 include/linux/mfd/db8500-prcmu.h           |   6 --
 include/linux/mfd/dbx500-prcmu.h           |  30 ------
 include/linux/platform_data/arm-ux500-pm.h |  21 ++++
 8 files changed, 195 insertions(+), 152 deletions(-)
 create mode 100644 arch/arm/mach-ux500/pm.c
 create mode 100644 include/linux/platform_data/arm-ux500-pm.h

diff --git a/arch/arm/mach-ux500/Makefile b/arch/arm/mach-ux500/Makefile
index f24710d..580a4db 100644
--- a/arch/arm/mach-ux500/Makefile
+++ b/arch/arm/mach-ux500/Makefile
@@ -3,7 +3,7 @@
 #
 
 obj-y				:= cpu.o devices.o devices-common.o \
-				   id.o usb.o timer.o
+				   id.o usb.o timer.o pm.o
 obj-$(CONFIG_CPU_IDLE)          += cpuidle.o
 obj-$(CONFIG_CACHE_L2X0)	+= cache-l2x0.o
 obj-$(CONFIG_UX500_SOC_DB8500)	+= cpu-db8500.o devices-db8500.o
diff --git a/arch/arm/mach-ux500/cpu.c b/arch/arm/mach-ux500/cpu.c
index 38459e9..ee69439d 100644
--- a/arch/arm/mach-ux500/cpu.c
+++ b/arch/arm/mach-ux500/cpu.c
@@ -20,6 +20,7 @@
 #include <linux/irqchip.h>
 #include <linux/irqchip/arm-gic.h>
 #include <linux/platform_data/clk-ux500.h>
+#include <linux/platform_data/arm-ux500-pm.h>
 
 #include <asm/mach/map.h>
 
@@ -68,16 +69,19 @@ void __init ux500_init_irq(void)
 	 */
 	if (cpu_is_u8500_family()) {
 		prcmu_early_init(U8500_PRCMU_BASE, SZ_8K - 1);
+		ux500_pm_init(U8500_PRCMU_BASE, SZ_8K - 1);
 		u8500_clk_init(U8500_CLKRST1_BASE, U8500_CLKRST2_BASE,
 			       U8500_CLKRST3_BASE, U8500_CLKRST5_BASE,
 			       U8500_CLKRST6_BASE);
 	} else if (cpu_is_u9540()) {
 		prcmu_early_init(U8500_PRCMU_BASE, SZ_8K - 1);
+		ux500_pm_init(U8500_PRCMU_BASE, SZ_8K - 1);
 		u8500_clk_init(U8500_CLKRST1_BASE, U8500_CLKRST2_BASE,
 			       U8500_CLKRST3_BASE, U8500_CLKRST5_BASE,
 			       U8500_CLKRST6_BASE);
 	} else if (cpu_is_u8540()) {
 		prcmu_early_init(U8500_PRCMU_BASE, SZ_8K + SZ_4K - 1);
+		ux500_pm_init(U8500_PRCMU_BASE, SZ_8K + SZ_4K - 1);
 		u8540_clk_init();
 	}
 }
diff --git a/arch/arm/mach-ux500/cpuidle.c b/arch/arm/mach-ux500/cpuidle.c
index ce91493..1e5bb66 100644
--- a/arch/arm/mach-ux500/cpuidle.c
+++ b/arch/arm/mach-ux500/cpuidle.c
@@ -16,6 +16,7 @@
 #include <linux/atomic.h>
 #include <linux/smp.h>
 #include <linux/mfd/dbx500-prcmu.h>
+#include <linux/platform_data/arm-ux500-pm.h>
 
 #include <asm/cpuidle.h>
 #include <asm/proc-fns.h>
@@ -130,7 +131,7 @@ int __init ux500_idle_init(void)
 	int ret, cpu;
 	struct cpuidle_device *device;
 
-        /* Configure wake up reasons */
+	/* Configure wake up reasons */
 	prcmu_enable_wakeups(PRCMU_WAKEUP(ARM) | PRCMU_WAKEUP(RTC) |
 			     PRCMU_WAKEUP(ABB));
 
diff --git a/arch/arm/mach-ux500/pm.c b/arch/arm/mach-ux500/pm.c
new file mode 100644
index 0000000..6949a13
--- /dev/null
+++ b/arch/arm/mach-ux500/pm.c
@@ -0,0 +1,167 @@
+/*
+ * Copyright (C) ST-Ericsson SA 2010-2013
+ * Author: Rickard Andersson <rickard.andersson at stericsson.com> for
+ *         ST-Ericsson.
+ * Author: Daniel Lezcano <daniel.lezcano at linaro.org> for Linaro.
+ * License terms: GNU General Public License (GPL) version 2
+ *
+ */
+
+#include <linux/kernel.h>
+#include <linux/irqchip/arm-gic.h>
+#include <linux/delay.h>
+#include <linux/io.h>
+#include <linux/platform_data/arm-ux500-pm.h>
+
+#include <mach/hardware.h>
+
+/* ARM WFI Standby signal register */
+#define PRCM_ARM_WFI_STANDBY    (prcmu_base + 0x130)
+#define PRCM_ARM_WFI_STANDBY_WFI0		0x08
+#define PRCM_ARM_WFI_STANDBY_WFI1		0x10
+#define PRCM_IOCR		(prcmu_base + 0x310)
+#define PRCM_IOCR_IOFORCE			0x1
+
+/* Dual A9 core interrupt management unit registers */
+#define PRCM_A9_MASK_REQ	(prcmu_base + 0x328)
+#define PRCM_A9_MASK_REQ_PRCM_A9_MASK_REQ	0x1
+
+#define PRCM_A9_MASK_ACK	(prcmu_base + 0x32c)
+#define PRCM_ARMITMSK31TO0	(prcmu_base + 0x11c)
+#define PRCM_ARMITMSK63TO32	(prcmu_base + 0x120)
+#define PRCM_ARMITMSK95TO64	(prcmu_base + 0x124)
+#define PRCM_ARMITMSK127TO96	(prcmu_base + 0x128)
+#define PRCM_POWER_STATE_VAL	(prcmu_base + 0x25C)
+#define PRCM_ARMITVAL31TO0	(prcmu_base + 0x260)
+#define PRCM_ARMITVAL63TO32	(prcmu_base + 0x264)
+#define PRCM_ARMITVAL95TO64	(prcmu_base + 0x268)
+#define PRCM_ARMITVAL127TO96	(prcmu_base + 0x26C)
+
+static void __iomem *prcmu_base;
+
+/* This function decouple the gic from the prcmu */
+int prcmu_gic_decouple(void)
+{
+	u32 val = readl(PRCM_A9_MASK_REQ);
+
+	/* Set bit 0 register value to 1 */
+	writel(val | PRCM_A9_MASK_REQ_PRCM_A9_MASK_REQ,
+	       PRCM_A9_MASK_REQ);
+
+	/* Make sure the register is updated */
+	readl(PRCM_A9_MASK_REQ);
+
+	/* Wait a few cycles for the gic mask completion */
+	udelay(1);
+
+	return 0;
+}
+
+/* This function recouple the gic with the prcmu */
+int prcmu_gic_recouple(void)
+{
+	u32 val = readl(PRCM_A9_MASK_REQ);
+
+	/* Set bit 0 register value to 0 */
+	writel(val & ~PRCM_A9_MASK_REQ_PRCM_A9_MASK_REQ, PRCM_A9_MASK_REQ);
+
+	return 0;
+}
+
+#define PRCMU_GIC_NUMBER_REGS 5
+
+/*
+ * This function checks if there are pending irq on the gic. It only
+ * makes sense if the gic has been decoupled before with the
+ * db8500_prcmu_gic_decouple function. Disabling an interrupt only
+ * disables the forwarding of the interrupt to any CPU interface. It
+ * does not prevent the interrupt from changing state, for example
+ * becoming pending, or active and pending if it is already
+ * active. Hence, we have to check the interrupt is pending *and* is
+ * active.
+ */
+bool prcmu_gic_pending_irq(void)
+{
+	u32 pr; /* Pending register */
+	u32 er; /* Enable register */
+	void __iomem *dist_base = __io_address(U8500_GIC_DIST_BASE);
+	int i;
+
+	/* 5 registers. STI & PPI not skipped */
+	for (i = 0; i < PRCMU_GIC_NUMBER_REGS; i++) {
+
+		pr = readl_relaxed(dist_base + GIC_DIST_PENDING_SET + i * 4);
+		er = readl_relaxed(dist_base + GIC_DIST_ENABLE_SET + i * 4);
+
+		if (pr & er)
+			return true; /* There is a pending interrupt */
+	}
+
+	return false;
+}
+
+/*
+ * This function checks if there are pending interrupt on the
+ * prcmu which has been delegated to monitor the irqs with the
+ * db8500_prcmu_copy_gic_settings function.
+ */
+bool prcmu_pending_irq(void)
+{
+	u32 it, im;
+	int i;
+
+	for (i = 0; i < PRCMU_GIC_NUMBER_REGS - 1; i++) {
+		it = readl(PRCM_ARMITVAL31TO0 + i * 4);
+		im = readl(PRCM_ARMITMSK31TO0 + i * 4);
+		if (it & im)
+			return true; /* There is a pending interrupt */
+	}
+
+	return false;
+}
+
+/*
+ * This function checks if the specified cpu is in in WFI. It's usage
+ * makes sense only if the gic is decoupled with the db8500_prcmu_gic_decouple
+ * function. Of course passing smp_processor_id() to this function will
+ * always return false...
+ */
+bool prcmu_is_cpu_in_wfi(int cpu)
+{
+	return readl(PRCM_ARM_WFI_STANDBY) & cpu ? PRCM_ARM_WFI_STANDBY_WFI1 :
+		     PRCM_ARM_WFI_STANDBY_WFI0;
+}
+
+/*
+ * This function copies the gic SPI settings to the prcmu in order to
+ * monitor them and abort/finish the retention/off sequence or state.
+ */
+int prcmu_copy_gic_settings(void)
+{
+	u32 er; /* Enable register */
+	void __iomem *dist_base = __io_address(U8500_GIC_DIST_BASE);
+	int i;
+
+	/* We skip the STI and PPI */
+	for (i = 0; i < PRCMU_GIC_NUMBER_REGS - 1; i++) {
+		er = readl_relaxed(dist_base +
+				   GIC_DIST_ENABLE_SET + (i + 1) * 4);
+		writel(er, PRCM_ARMITMSK31TO0 + i * 4);
+	}
+
+	return 0;
+}
+
+void __init ux500_pm_init(u32 phy_base, u32 size)
+{
+	prcmu_base = ioremap(phy_base, size);
+	if (!prcmu_base) {
+		pr_err("could not remap PRCMU for PM functions\n");
+		return;
+	}
+	/*
+	 * On watchdog reboot the GIC is in some cases decoupled.
+	 * This will make sure that the GIC is correctly configured.
+	 */
+	prcmu_gic_recouple();
+}
diff --git a/drivers/mfd/db8500-prcmu.c b/drivers/mfd/db8500-prcmu.c
index acb8ef7..2d3a5f6 100644
--- a/drivers/mfd/db8500-prcmu.c
+++ b/drivers/mfd/db8500-prcmu.c
@@ -26,7 +26,6 @@
 #include <linux/fs.h>
 #include <linux/platform_device.h>
 #include <linux/uaccess.h>
-#include <linux/irqchip/arm-gic.h>
 #include <linux/mfd/core.h>
 #include <linux/mfd/dbx500-prcmu.h>
 #include <linux/mfd/abx500/ab8500.h>
@@ -794,119 +793,6 @@ u8 db8500_prcmu_get_power_state_result(void)
 	return readb(tcdm_base + PRCM_ACK_MB0_AP_PWRSTTR_STATUS);
 }
 
-/* This function decouple the gic from the prcmu */
-int db8500_prcmu_gic_decouple(void)
-{
-	u32 val = readl(PRCM_A9_MASK_REQ);
-
-	/* Set bit 0 register value to 1 */
-	writel(val | PRCM_A9_MASK_REQ_PRCM_A9_MASK_REQ,
-	       PRCM_A9_MASK_REQ);
-
-	/* Make sure the register is updated */
-	readl(PRCM_A9_MASK_REQ);
-
-	/* Wait a few cycles for the gic mask completion */
-	udelay(1);
-
-	return 0;
-}
-
-/* This function recouple the gic with the prcmu */
-int db8500_prcmu_gic_recouple(void)
-{
-	u32 val = readl(PRCM_A9_MASK_REQ);
-
-	/* Set bit 0 register value to 0 */
-	writel(val & ~PRCM_A9_MASK_REQ_PRCM_A9_MASK_REQ, PRCM_A9_MASK_REQ);
-
-	return 0;
-}
-
-#define PRCMU_GIC_NUMBER_REGS 5
-
-/*
- * This function checks if there are pending irq on the gic. It only
- * makes sense if the gic has been decoupled before with the
- * db8500_prcmu_gic_decouple function. Disabling an interrupt only
- * disables the forwarding of the interrupt to any CPU interface. It
- * does not prevent the interrupt from changing state, for example
- * becoming pending, or active and pending if it is already
- * active. Hence, we have to check the interrupt is pending *and* is
- * active.
- */
-bool db8500_prcmu_gic_pending_irq(void)
-{
-	u32 pr; /* Pending register */
-	u32 er; /* Enable register */
-	void __iomem *dist_base = __io_address(U8500_GIC_DIST_BASE);
-	int i;
-
-        /* 5 registers. STI & PPI not skipped */
-	for (i = 0; i < PRCMU_GIC_NUMBER_REGS; i++) {
-
-		pr = readl_relaxed(dist_base + GIC_DIST_PENDING_SET + i * 4);
-		er = readl_relaxed(dist_base + GIC_DIST_ENABLE_SET + i * 4);
-
-		if (pr & er)
-			return true; /* There is a pending interrupt */
-	}
-
-	return false;
-}
-
-/*
- * This function checks if there are pending interrupt on the
- * prcmu which has been delegated to monitor the irqs with the
- * db8500_prcmu_copy_gic_settings function.
- */
-bool db8500_prcmu_pending_irq(void)
-{
-	u32 it, im;
-	int i;
-
-	for (i = 0; i < PRCMU_GIC_NUMBER_REGS - 1; i++) {
-		it = readl(PRCM_ARMITVAL31TO0 + i * 4);
-		im = readl(PRCM_ARMITMSK31TO0 + i * 4);
-		if (it & im)
-			return true; /* There is a pending interrupt */
-	}
-
-	return false;
-}
-
-/*
- * This function checks if the specified cpu is in in WFI. It's usage
- * makes sense only if the gic is decoupled with the db8500_prcmu_gic_decouple
- * function. Of course passing smp_processor_id() to this function will
- * always return false...
- */
-bool db8500_prcmu_is_cpu_in_wfi(int cpu)
-{
-	return readl(PRCM_ARM_WFI_STANDBY) & cpu ? PRCM_ARM_WFI_STANDBY_WFI1 :
-		     PRCM_ARM_WFI_STANDBY_WFI0;
-}
-
-/*
- * This function copies the gic SPI settings to the prcmu in order to
- * monitor them and abort/finish the retention/off sequence or state.
- */
-int db8500_prcmu_copy_gic_settings(void)
-{
-	u32 er; /* Enable register */
-	void __iomem *dist_base = __io_address(U8500_GIC_DIST_BASE);
-	int i;
-
-        /* We skip the STI and PPI */
-	for (i = 0; i < PRCMU_GIC_NUMBER_REGS - 1; i++) {
-		er = readl_relaxed(dist_base +
-				   GIC_DIST_ENABLE_SET + (i + 1) * 4);
-		writel(er, PRCM_ARMITMSK31TO0 + i * 4);
-	}
-
-	return 0;
-}
-
 /* This function should only be called while mb0_transfer.lock is held. */
 static void config_wakeups(void)
 {
diff --git a/include/linux/mfd/db8500-prcmu.h b/include/linux/mfd/db8500-prcmu.h
index ac943df..0bd6944 100644
--- a/include/linux/mfd/db8500-prcmu.h
+++ b/include/linux/mfd/db8500-prcmu.h
@@ -522,12 +522,6 @@ int db8500_prcmu_load_a9wdog(u8 id, u32 val);
 void db8500_prcmu_system_reset(u16 reset_code);
 int db8500_prcmu_set_power_state(u8 state, bool keep_ulp_clk, bool keep_ap_pll);
 u8 db8500_prcmu_get_power_state_result(void);
-int db8500_prcmu_gic_decouple(void);
-int db8500_prcmu_gic_recouple(void);
-int db8500_prcmu_copy_gic_settings(void);
-bool db8500_prcmu_gic_pending_irq(void);
-bool db8500_prcmu_pending_irq(void);
-bool db8500_prcmu_is_cpu_in_wfi(int cpu);
 void db8500_prcmu_enable_wakeups(u32 wakeups);
 int db8500_prcmu_set_epod(u16 epod_id, u8 epod_state);
 int db8500_prcmu_request_clock(u8 clock, bool enable);
diff --git a/include/linux/mfd/dbx500-prcmu.h b/include/linux/mfd/dbx500-prcmu.h
index 8c546cb..fc43cec 100644
--- a/include/linux/mfd/dbx500-prcmu.h
+++ b/include/linux/mfd/dbx500-prcmu.h
@@ -293,36 +293,6 @@ static inline u8 prcmu_get_power_state_result(void)
 	return db8500_prcmu_get_power_state_result();
 }
 
-static inline int prcmu_gic_decouple(void)
-{
-	return db8500_prcmu_gic_decouple();
-}
-
-static inline int prcmu_gic_recouple(void)
-{
-	return db8500_prcmu_gic_recouple();
-}
-
-static inline bool prcmu_gic_pending_irq(void)
-{
-	return db8500_prcmu_gic_pending_irq();
-}
-
-static inline bool prcmu_is_cpu_in_wfi(int cpu)
-{
-	return db8500_prcmu_is_cpu_in_wfi(cpu);
-}
-
-static inline int prcmu_copy_gic_settings(void)
-{
-	return db8500_prcmu_copy_gic_settings();
-}
-
-static inline bool prcmu_pending_irq(void)
-{
-	return db8500_prcmu_pending_irq();
-}
-
 static inline int prcmu_set_epod(u16 epod_id, u8 epod_state)
 {
 	return db8500_prcmu_set_epod(epod_id, epod_state);
diff --git a/include/linux/platform_data/arm-ux500-pm.h b/include/linux/platform_data/arm-ux500-pm.h
new file mode 100644
index 0000000..8dff64b
--- /dev/null
+++ b/include/linux/platform_data/arm-ux500-pm.h
@@ -0,0 +1,21 @@
+/*
+ * Copyright (C) ST-Ericsson SA 2010-2013
+ * Author: Rickard Andersson <rickard.andersson at stericsson.com> for
+ *         ST-Ericsson.
+ * Author: Daniel Lezcano <daniel.lezcano at linaro.org> for Linaro.
+ * License terms: GNU General Public License (GPL) version 2
+ *
+ */
+
+#ifndef ARM_UX500_PM_H
+#define ARM_UX500_PM_H
+
+int prcmu_gic_decouple(void);
+int prcmu_gic_recouple(void);
+bool prcmu_gic_pending_irq(void);
+bool prcmu_pending_irq(void);
+bool prcmu_is_cpu_in_wfi(int cpu);
+int prcmu_copy_gic_settings(void);
+void ux500_pm_init(u32 phy_base, u32 size);
+
+#endif /* ARM_UX500_PM_H */
-- 
1.7.11.3



From linus.walleij at stericsson.com  Fri Apr  5 10:22:55 2013
From: linus.walleij at stericsson.com (Linus Walleij)
Date: Fri, 5 Apr 2013 16:22:55 +0200
Subject: [PATCH 13/14] ARM: ux500: move to multiplatform
In-Reply-To: <1365171776-8463-1-git-send-email-linus.walleij@stericsson.com>
References: <1365171776-8463-1-git-send-email-linus.walleij@stericsson.com>
Message-ID: <1365171776-8463-14-git-send-email-linus.walleij@stericsson.com>

From: Arnd Bergmann <arnd at arndb.de>

Nothing is holding us up any more, and we can make ux500 coexist
with the rest of the platforms. The timex.h and uncompress.h
headers are no longer needed now.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 arch/arm/Kconfig                              | 15 -------
 arch/arm/mach-ux500/Kconfig                   | 14 +++++++
 arch/arm/mach-ux500/include/mach/timex.h      |  6 ---
 arch/arm/mach-ux500/include/mach/uncompress.h | 58 ---------------------------
 4 files changed, 14 insertions(+), 79 deletions(-)
 delete mode 100644 arch/arm/mach-ux500/include/mach/timex.h
 delete mode 100644 arch/arm/mach-ux500/include/mach/uncompress.h

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 5b71469..65badde 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -901,21 +901,6 @@ config ARCH_U300
 	help
 	  Support for ST-Ericsson U300 series mobile platforms.
 
-config ARCH_U8500
-	bool "ST-Ericsson U8500 Series"
-	depends on MMU
-	select ARCH_HAS_CPUFREQ
-	select ARCH_REQUIRE_GPIOLIB
-	select ARM_AMBA
-	select CLKDEV_LOOKUP
-	select CPU_V7
-	select GENERIC_CLOCKEVENTS
-	select HAVE_SMP
-	select MIGHT_HAVE_CACHE_L2X0
-	select SPARSE_IRQ
-	help
-	  Support for ST-Ericsson's Ux500 architecture
-
 config ARCH_NOMADIK
 	bool "STMicroelectronics Nomadik"
 	select ARCH_REQUIRE_GPIOLIB
diff --git a/arch/arm/mach-ux500/Kconfig b/arch/arm/mach-ux500/Kconfig
index 3e5bbd0..eeea3bf 100644
--- a/arch/arm/mach-ux500/Kconfig
+++ b/arch/arm/mach-ux500/Kconfig
@@ -1,3 +1,17 @@
+config ARCH_U8500
+	bool "ST-Ericsson U8500 Series" if ARCH_MULTI_V7
+	depends on MMU
+	select ARCH_HAS_CPUFREQ
+	select ARCH_REQUIRE_GPIOLIB
+	select ARM_AMBA
+	select CLKDEV_LOOKUP
+	select CPU_V7
+	select GENERIC_CLOCKEVENTS
+	select HAVE_SMP
+	select MIGHT_HAVE_CACHE_L2X0
+	help
+	  Support for ST-Ericsson's Ux500 architecture
+
 if ARCH_U8500
 
 config UX500_SOC_COMMON
diff --git a/arch/arm/mach-ux500/include/mach/timex.h b/arch/arm/mach-ux500/include/mach/timex.h
deleted file mode 100644
index d0942c1..0000000
--- a/arch/arm/mach-ux500/include/mach/timex.h
+++ /dev/null
@@ -1,6 +0,0 @@
-#ifndef __ASM_ARCH_TIMEX_H
-#define __ASM_ARCH_TIMEX_H
-
-#define CLOCK_TICK_RATE		110000000
-
-#endif
diff --git a/arch/arm/mach-ux500/include/mach/uncompress.h b/arch/arm/mach-ux500/include/mach/uncompress.h
deleted file mode 100644
index 533a004..0000000
--- a/arch/arm/mach-ux500/include/mach/uncompress.h
+++ /dev/null
@@ -1,58 +0,0 @@
-/*
- *  Copyright (C) 2009 ST-Ericsson
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
- */
-#ifndef __ASM_ARCH_UNCOMPRESS_H
-#define __ASM_ARCH_UNCOMPRESS_H
-
-#include <asm/setup.h>
-#include <asm/mach-types.h>
-#include <linux/io.h>
-#include <linux/amba/serial.h>
-/* TODO: This goes away in multiplatform boot, this file gets deleted */
-#include "../../db8500-regs.h"
-
-void __iomem *ux500_uart_base;
-
-static void putc(const char c)
-{
-	/* Do nothing if the UART is not enabled. */
-	if (!(__raw_readb(ux500_uart_base + UART011_CR) & 0x1))
-		return;
-
-	if (c == '\n')
-		putc('\r');
-
-	while (__raw_readb(ux500_uart_base + UART01x_FR) & (1 << 5))
-		barrier();
-	__raw_writeb(c, ux500_uart_base + UART01x_DR);
-}
-
-static void flush(void)
-{
-	if (!(__raw_readb(ux500_uart_base + UART011_CR) & 0x1))
-		return;
-	while (__raw_readb(ux500_uart_base + UART01x_FR) & (1 << 3))
-		barrier();
-}
-
-static inline void arch_decomp_setup(void)
-{
-	/* Use machine_is_foo() macro if you need to switch base someday */
-	ux500_uart_base = (void __iomem *)U8500_UART2_BASE;
-}
-
-#endif /* __ASM_ARCH_UNCOMPRESS_H */
-- 
1.7.11.3



From linus.walleij at stericsson.com  Fri Apr  5 10:22:52 2013
From: linus.walleij at stericsson.com (Linus Walleij)
Date: Fri, 5 Apr 2013 16:22:52 +0200
Subject: [PATCH 10/14] ARM: ux500: split out prcmu initialization
In-Reply-To: <1365171776-8463-1-git-send-email-linus.walleij@stericsson.com>
References: <1365171776-8463-1-git-send-email-linus.walleij@stericsson.com>
Message-ID: <1365171776-8463-11-git-send-email-linus.walleij@stericsson.com>

From: Arnd Bergmann <arnd at arndb.de>

This untangles the final bits of the prcmu code from the platform
code:

* The IRQ_PRCMU_* definitions move from irqs-db8500.h into prcmu.c
  because they are only of local significance.
* u8500_thsens_device goes into the prcmu, because it uses a PRCMU
  IRQ that the platform does not see.
* IRQ_DB8500_AB8500 and IRQ_PRCMU_BASE go into the platform data
  because the PRCMU does not see it.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
[Fixed a oneliner bug]
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 arch/arm/mach-ux500/board-mop500.c             |  58 ----------
 arch/arm/mach-ux500/devices-db8500.c           |   2 +
 arch/arm/mach-ux500/include/mach/irqs-db8500.h |  25 -----
 drivers/mfd/db8500-prcmu.c                     | 142 +++++++++++++++++++------
 include/linux/mfd/dbx500-prcmu.h               |   2 +
 5 files changed, 116 insertions(+), 113 deletions(-)

diff --git a/arch/arm/mach-ux500/board-mop500.c b/arch/arm/mach-ux500/board-mop500.c
index caad80e..e1b38ef 100644
--- a/arch/arm/mach-ux500/board-mop500.c
+++ b/arch/arm/mach-ux500/board-mop500.c
@@ -206,63 +206,6 @@ struct ab8500_platform_data ab8500_platdata = {
 	.codec		= &ab8500_codec_pdata,
 };
 
-/*
- * Thermal Sensor
- */
-
-static struct resource db8500_thsens_resources[] = {
-	{
-		.name = "IRQ_HOTMON_LOW",
-		.start  = IRQ_PRCMU_HOTMON_LOW,
-		.end    = IRQ_PRCMU_HOTMON_LOW,
-		.flags  = IORESOURCE_IRQ,
-	},
-	{
-		.name = "IRQ_HOTMON_HIGH",
-		.start  = IRQ_PRCMU_HOTMON_HIGH,
-		.end    = IRQ_PRCMU_HOTMON_HIGH,
-		.flags  = IORESOURCE_IRQ,
-	},
-};
-
-static struct db8500_thsens_platform_data db8500_thsens_data = {
-	.trip_points[0] = {
-		.temp = 70000,
-		.type = THERMAL_TRIP_ACTIVE,
-		.cdev_name = {
-			[0] = "thermal-cpufreq-0",
-		},
-	},
-	.trip_points[1] = {
-		.temp = 75000,
-		.type = THERMAL_TRIP_ACTIVE,
-		.cdev_name = {
-			[0] = "thermal-cpufreq-0",
-		},
-	},
-	.trip_points[2] = {
-		.temp = 80000,
-		.type = THERMAL_TRIP_ACTIVE,
-		.cdev_name = {
-			[0] = "thermal-cpufreq-0",
-		},
-	},
-	.trip_points[3] = {
-		.temp = 85000,
-		.type = THERMAL_TRIP_CRITICAL,
-	},
-	.num_trips = 4,
-};
-
-static struct platform_device u8500_thsens_device = {
-	.name           = "db8500-thermal",
-	.resource       = db8500_thsens_resources,
-	.num_resources  = ARRAY_SIZE(db8500_thsens_resources),
-	.dev	= {
-		.platform_data	= &db8500_thsens_data,
-	},
-};
-
 static struct platform_device u8500_cpufreq_cooling_device = {
 	.name           = "db8500-cpufreq-cooling",
 };
@@ -622,7 +565,6 @@ static struct platform_device *snowball_platform_devs[] __initdata = {
 	&snowball_key_dev,
 	&snowball_sbnet_dev,
 	&snowball_gpio_en_3v3_regulator_dev,
-	&u8500_thsens_device,
 	&u8500_cpufreq_cooling_device,
 };
 
diff --git a/arch/arm/mach-ux500/devices-db8500.c b/arch/arm/mach-ux500/devices-db8500.c
index 38467bf..4c0ef14 100644
--- a/arch/arm/mach-ux500/devices-db8500.c
+++ b/arch/arm/mach-ux500/devices-db8500.c
@@ -199,6 +199,8 @@ struct platform_device u8500_ske_keypad_device = {
 
 struct prcmu_pdata db8500_prcmu_pdata = {
 	.ab_platdata	= &ab8500_platdata,
+	.ab_irq		= IRQ_DB8500_AB8500,
+	.irq_base	= IRQ_PRCMU_BASE,
 	.version_offset	= DB8500_PRCMU_FW_VERSION_OFFSET,
 	.legacy_offset	= DB8500_PRCMU_LEGACY_OFFSET,
 };
diff --git a/arch/arm/mach-ux500/include/mach/irqs-db8500.h b/arch/arm/mach-ux500/include/mach/irqs-db8500.h
index 68bc149..f3a9d59 100644
--- a/arch/arm/mach-ux500/include/mach/irqs-db8500.h
+++ b/arch/arm/mach-ux500/include/mach/irqs-db8500.h
@@ -109,31 +109,6 @@
 
 /* Virtual interrupts corresponding to the PRCMU wakeups.  */
 #define IRQ_PRCMU_BASE IRQ_SOC_START
-#define NUM_PRCMU_WAKEUPS (IRQ_PRCMU_END - IRQ_PRCMU_BASE)
-
-#define IRQ_PRCMU_RTC (IRQ_PRCMU_BASE)
-#define IRQ_PRCMU_RTT0 (IRQ_PRCMU_BASE + 1)
-#define IRQ_PRCMU_RTT1 (IRQ_PRCMU_BASE + 2)
-#define IRQ_PRCMU_HSI0 (IRQ_PRCMU_BASE + 3)
-#define IRQ_PRCMU_HSI1 (IRQ_PRCMU_BASE + 4)
-#define IRQ_PRCMU_CA_WAKE (IRQ_PRCMU_BASE + 5)
-#define IRQ_PRCMU_USB (IRQ_PRCMU_BASE + 6)
-#define IRQ_PRCMU_ABB (IRQ_PRCMU_BASE + 7)
-#define IRQ_PRCMU_ABB_FIFO (IRQ_PRCMU_BASE + 8)
-#define IRQ_PRCMU_ARM (IRQ_PRCMU_BASE + 9)
-#define IRQ_PRCMU_MODEM_SW_RESET_REQ (IRQ_PRCMU_BASE + 10)
-#define IRQ_PRCMU_GPIO0 (IRQ_PRCMU_BASE + 11)
-#define IRQ_PRCMU_GPIO1 (IRQ_PRCMU_BASE + 12)
-#define IRQ_PRCMU_GPIO2 (IRQ_PRCMU_BASE + 13)
-#define IRQ_PRCMU_GPIO3 (IRQ_PRCMU_BASE + 14)
-#define IRQ_PRCMU_GPIO4 (IRQ_PRCMU_BASE + 15)
-#define IRQ_PRCMU_GPIO5 (IRQ_PRCMU_BASE + 16)
-#define IRQ_PRCMU_GPIO6 (IRQ_PRCMU_BASE + 17)
-#define IRQ_PRCMU_GPIO7 (IRQ_PRCMU_BASE + 18)
-#define IRQ_PRCMU_GPIO8 (IRQ_PRCMU_BASE + 19)
-#define IRQ_PRCMU_CA_SLEEP (IRQ_PRCMU_BASE + 20)
-#define IRQ_PRCMU_HOTMON_LOW (IRQ_PRCMU_BASE + 21)
-#define IRQ_PRCMU_HOTMON_HIGH (IRQ_PRCMU_BASE + 22)
 #define IRQ_PRCMU_END (IRQ_PRCMU_BASE + 23)
 
 /*
diff --git a/drivers/mfd/db8500-prcmu.c b/drivers/mfd/db8500-prcmu.c
index 03e2aed..8eb8c49 100644
--- a/drivers/mfd/db8500-prcmu.c
+++ b/drivers/mfd/db8500-prcmu.c
@@ -33,7 +33,7 @@
 #include <linux/regulator/machine.h>
 #include <linux/cpufreq.h>
 #include <linux/platform_data/ux500_wdt.h>
-#include <mach/irqs.h>
+#include <linux/platform_data/db8500_thermal.h>
 #include "dbx500-prcmu-regs.h"
 
 /* Index of different voltages to be used when accessing AVSData */
@@ -273,8 +273,34 @@ static struct irq_domain *db8500_irq_domain;
  * the bits in the bit field are not. (The bits also have a tendency to move
  * around, to further complicate matters.)
  */
-#define IRQ_INDEX(_name) ((IRQ_PRCMU_##_name) - IRQ_PRCMU_BASE)
+#define IRQ_INDEX(_name) ((IRQ_PRCMU_##_name))
 #define IRQ_ENTRY(_name)[IRQ_INDEX(_name)] = (WAKEUP_BIT_##_name)
+
+#define IRQ_PRCMU_RTC 0
+#define IRQ_PRCMU_RTT0 1
+#define IRQ_PRCMU_RTT1 2
+#define IRQ_PRCMU_HSI0 3
+#define IRQ_PRCMU_HSI1 4
+#define IRQ_PRCMU_CA_WAKE 5
+#define IRQ_PRCMU_USB 6
+#define IRQ_PRCMU_ABB 7
+#define IRQ_PRCMU_ABB_FIFO 8
+#define IRQ_PRCMU_ARM 9
+#define IRQ_PRCMU_MODEM_SW_RESET_REQ 10
+#define IRQ_PRCMU_GPIO0 11
+#define IRQ_PRCMU_GPIO1 12
+#define IRQ_PRCMU_GPIO2 13
+#define IRQ_PRCMU_GPIO3 14
+#define IRQ_PRCMU_GPIO4 15
+#define IRQ_PRCMU_GPIO5 16
+#define IRQ_PRCMU_GPIO6 17
+#define IRQ_PRCMU_GPIO7 18
+#define IRQ_PRCMU_GPIO8 19
+#define IRQ_PRCMU_CA_SLEEP 20
+#define IRQ_PRCMU_HOTMON_LOW 21
+#define IRQ_PRCMU_HOTMON_HIGH 22
+#define NUM_PRCMU_WAKEUPS 23
+
 static u32 prcmu_irq_bit[NUM_PRCMU_WAKEUPS] = {
 	IRQ_ENTRY(RTC),
 	IRQ_ENTRY(RTT0),
@@ -2649,14 +2675,13 @@ static struct irq_domain_ops db8500_irq_ops = {
 	.xlate  = irq_domain_xlate_twocell,
 };
 
-static int db8500_irq_init(struct device_node *np)
+static int db8500_irq_init(struct device_node *np, int irq_base)
 {
-	int irq_base = 0;
 	int i;
 
 	/* In the device tree case, just take some IRQs */
-	if (!np)
-		irq_base = IRQ_PRCMU_BASE;
+	if (np)
+		irq_base = 0;
 
 	db8500_irq_domain = irq_domain_add_simple(
 		np, NUM_PRCMU_WAKEUPS, irq_base,
@@ -2717,7 +2742,7 @@ void __init db8500_prcmu_early_init(u32 phy_base, u32 size)
 	 * subsequently replaces with a real remap. After the merge of
 	 * the mailbox subsystem all of this early code goes away, and the
 	 * clock driver can probe independently. An early initcall will
-	 * still be needed, but it can be diverted into drivers/clk/ux500/*.
+	 * still be needed, but it can be diverted into drivers/clk/ux500/.
 	 */
 	prcmu_base = ioremap(phy_base, size);
 	if (!prcmu_base)
@@ -2988,18 +3013,57 @@ static struct regulator_init_data db8500_regulators[DB8500_NUM_REGULATORS] = {
 	},
 };
 
-static struct resource ab8500_resources[] = {
-	[0] = {
-		.start	= IRQ_DB8500_AB8500,
-		.end	= IRQ_DB8500_AB8500,
-		.flags	= IORESOURCE_IRQ
-	}
-};
-
 static struct ux500_wdt_data db8500_wdt_pdata = {
 	.timeout = 600, /* 10 minutes */
 	.has_28_bits_resolution = true,
 };
+/*
+ * Thermal Sensor
+ */
+
+static struct resource db8500_thsens_resources[] = {
+	{
+		.name = "IRQ_HOTMON_LOW",
+		.start  = IRQ_PRCMU_HOTMON_LOW,
+		.end    = IRQ_PRCMU_HOTMON_LOW,
+		.flags  = IORESOURCE_IRQ,
+	},
+	{
+		.name = "IRQ_HOTMON_HIGH",
+		.start  = IRQ_PRCMU_HOTMON_HIGH,
+		.end    = IRQ_PRCMU_HOTMON_HIGH,
+		.flags  = IORESOURCE_IRQ,
+	},
+};
+
+static struct db8500_thsens_platform_data db8500_thsens_data = {
+	.trip_points[0] = {
+		.temp = 70000,
+		.type = THERMAL_TRIP_ACTIVE,
+		.cdev_name = {
+			[0] = "thermal-cpufreq-0",
+		},
+	},
+	.trip_points[1] = {
+		.temp = 75000,
+		.type = THERMAL_TRIP_ACTIVE,
+		.cdev_name = {
+			[0] = "thermal-cpufreq-0",
+		},
+	},
+	.trip_points[2] = {
+		.temp = 80000,
+		.type = THERMAL_TRIP_ACTIVE,
+		.cdev_name = {
+			[0] = "thermal-cpufreq-0",
+		},
+	},
+	.trip_points[3] = {
+		.temp = 85000,
+		.type = THERMAL_TRIP_CRITICAL,
+	},
+	.num_trips = 4,
+};
 
 static struct mfd_cell db8500_prcmu_devs[] = {
 	{
@@ -3021,11 +3085,10 @@ static struct mfd_cell db8500_prcmu_devs[] = {
 		.id = -1,
 	},
 	{
-		.name = "ab8500-core",
-		.of_compatible = "stericsson,ab8500",
-		.num_resources = ARRAY_SIZE(ab8500_resources),
-		.resources = ab8500_resources,
-		.id = AB8500_VERSION_AB8500,
+		.name = "db8500-thermal",
+		.num_resources = ARRAY_SIZE(db8500_thsens_resources),
+		.resources = db8500_thsens_resources,
+		.platform_data = &db8500_thsens_data,
 	},
 };
 
@@ -3037,6 +3100,24 @@ static void db8500_prcmu_update_cpufreq(void)
 	}
 }
 
+static int db8500_prcmu_register_ab8500(struct device *parent,
+					struct ab8500_platform_data *pdata,
+					int irq)
+{
+	struct resource ab8500_resource = DEFINE_RES_IRQ(irq);
+	struct mfd_cell ab8500_cell = {
+		.name = "ab8500-core",
+		.of_compatible = "stericsson,ab8500",
+		.id = AB8500_VERSION_AB8500,
+		.platform_data = pdata,
+		.pdata_size = sizeof(struct ab8500_platform_data),
+		.resources = &ab8500_resource,
+		.num_resources = 1,
+	};
+
+	return mfd_add_devices(parent, 0, &ab8500_cell, 1, NULL, 0, NULL);
+}
+
 /**
  * prcmu_fw_init - arch init call for the Linux PRCMU fw init logic
  *
@@ -3045,7 +3126,7 @@ static int db8500_prcmu_probe(struct platform_device *pdev)
 {
 	struct device_node *np = pdev->dev.of_node;
 	struct prcmu_pdata *pdata = dev_get_platdata(&pdev->dev);
-	int irq = 0, err = 0, i;
+	int irq = 0, err = 0;
 	struct resource *res;
 
 	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "prcmu");
@@ -3086,26 +3167,27 @@ static int db8500_prcmu_probe(struct platform_device *pdev)
 		goto no_irq_return;
 	}
 
-	db8500_irq_init(np);
-
-	for (i = 0; i < ARRAY_SIZE(db8500_prcmu_devs); i++) {
-		if (!strcmp(db8500_prcmu_devs[i].name, "ab8500-core")) {
-			db8500_prcmu_devs[i].platform_data = pdata->ab_platdata;
-			db8500_prcmu_devs[i].pdata_size = sizeof(struct ab8500_platform_data);
-		}
-	}
+	db8500_irq_init(np, pdata->irq_base);
 
 	prcmu_config_esram0_deep_sleep(ESRAM0_DEEP_SLEEP_STATE_RET);
 
 	db8500_prcmu_update_cpufreq();
 
 	err = mfd_add_devices(&pdev->dev, 0, db8500_prcmu_devs,
-			      ARRAY_SIZE(db8500_prcmu_devs), NULL, 0, NULL);
+			      ARRAY_SIZE(db8500_prcmu_devs), NULL, 0, db8500_irq_domain);
 	if (err) {
 		pr_err("prcmu: Failed to add subdevices\n");
 		return err;
 	}
 
+	err = db8500_prcmu_register_ab8500(&pdev->dev, pdata->ab_platdata,
+					   pdata->ab_irq);
+	if (err) {
+		mfd_remove_devices(&pdev->dev);
+		pr_err("prcmu: Failed to add ab8500 subdevice\n");
+		goto no_irq_return;
+	}
+
 	pr_info("DB8500 PRCMU initialized\n");
 
 no_irq_return:
diff --git a/include/linux/mfd/dbx500-prcmu.h b/include/linux/mfd/dbx500-prcmu.h
index fc43cec..689e6a0 100644
--- a/include/linux/mfd/dbx500-prcmu.h
+++ b/include/linux/mfd/dbx500-prcmu.h
@@ -237,6 +237,8 @@ struct prcmu_pdata
 	bool enable_set_ddr_opp;
 	bool enable_ape_opp_100_voltage;
 	struct ab8500_platform_data *ab_platdata;
+	int ab_irq;
+	int irq_base;
 	u32 version_offset;
 	u32 legacy_offset;
 	u32 adt_offset;
-- 
1.7.11.3



From linus.walleij at stericsson.com  Fri Apr  5 10:22:56 2013
From: linus.walleij at stericsson.com (Linus Walleij)
Date: Fri, 5 Apr 2013 16:22:56 +0200
Subject: [PATCH 14/14] ARM: ux500: build hotplug.o for ARMv7-a
In-Reply-To: <1365171776-8463-1-git-send-email-linus.walleij@stericsson.com>
References: <1365171776-8463-1-git-send-email-linus.walleij@stericsson.com>
Message-ID: <1365171776-8463-15-git-send-email-linus.walleij@stericsson.com>

From: Arnd Bergmann <arnd at arndb.de>

If we try to build this file in a multiplatform configuration with
ARMv6 enabled, gas complains about the dsb operation being undefined.
Adding -march=armv7-a is safe because that code is only ever run
on ux500, which is Cortex-A9.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 arch/arm/mach-ux500/Makefile | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/mach-ux500/Makefile b/arch/arm/mach-ux500/Makefile
index 580a4db..bf9b6be 100644
--- a/arch/arm/mach-ux500/Makefile
+++ b/arch/arm/mach-ux500/Makefile
@@ -15,3 +15,5 @@ obj-$(CONFIG_MACH_MOP500)	+= board-mop500.o board-mop500-sdi.o \
 				board-mop500-audio.o
 obj-$(CONFIG_SMP)		+= platsmp.o headsmp.o
 obj-$(CONFIG_HOTPLUG_CPU)	+= hotplug.o
+
+CFLAGS_hotplug.o		+= -march=armv7-a
-- 
1.7.11.3



From linus.walleij at stericsson.com  Fri Apr  5 10:22:46 2013
From: linus.walleij at stericsson.com (Linus Walleij)
Date: Fri, 5 Apr 2013 16:22:46 +0200
Subject: [PATCH 04/14] staging: ste_rmi4: kill platform_data hack
In-Reply-To: <1365171776-8463-1-git-send-email-linus.walleij@stericsson.com>
References: <1365171776-8463-1-git-send-email-linus.walleij@stericsson.com>
Message-ID: <1365171776-8463-5-git-send-email-linus.walleij@stericsson.com>

From: Arnd Bergmann <arnd at arndb.de>

There is only one instance of the platform data for synaptics_i2c_rmi4
in the mainline kernel, so there is no point of pretending its
variable here. The only member that has a dependency on the platform
is actually the interrupt number, and there is a field in the
i2c_client structure that gets initialized from the board info,
so we can trivially move the board_into into the platform without
knowledge of the platform_data structure.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Acked-by: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 arch/arm/mach-ux500/board-mop500-u8500uib.c        |  7 +++--
 drivers/staging/ste_rmi4/Makefile                  |  1 -
 .../staging/ste_rmi4/board-mop500-u8500uib-rmi4.c  | 31 ----------------------
 drivers/staging/ste_rmi4/synaptics_i2c_rmi4.c      | 31 +++++++++++++---------
 drivers/staging/ste_rmi4/synaptics_i2c_rmi4.h      |  1 -
 5 files changed, 23 insertions(+), 48 deletions(-)
 delete mode 100644 drivers/staging/ste_rmi4/board-mop500-u8500uib-rmi4.c

diff --git a/arch/arm/mach-ux500/board-mop500-u8500uib.c b/arch/arm/mach-ux500/board-mop500-u8500uib.c
index ead91c9..0b5e14a 100644
--- a/arch/arm/mach-ux500/board-mop500-u8500uib.c
+++ b/arch/arm/mach-ux500/board-mop500-u8500uib.c
@@ -16,8 +16,11 @@
 
 #include "board-mop500.h"
 
-/* Dummy data that can be overridden by staging driver */
-struct i2c_board_info __initdata __weak mop500_i2c3_devices_u8500[] = {
+static struct i2c_board_info __initdata mop500_i2c3_devices_u8500[] = {
+	{
+		I2C_BOARD_INFO("synaptics_rmi4_i2c", 0x4B),
+		.irq = NOMADIK_GPIO_TO_IRQ(84),
+	},
 };
 
 /*
diff --git a/drivers/staging/ste_rmi4/Makefile b/drivers/staging/ste_rmi4/Makefile
index e4c0335..6cce2ed 100644
--- a/drivers/staging/ste_rmi4/Makefile
+++ b/drivers/staging/ste_rmi4/Makefile
@@ -2,4 +2,3 @@
 # Makefile for the RMI4 touchscreen driver.
 #
 obj-$(CONFIG_TOUCHSCREEN_SYNAPTICS_I2C_RMI4) += synaptics_i2c_rmi4.o
-obj-$(CONFIG_MACH_MOP500) += board-mop500-u8500uib-rmi4.o
diff --git a/drivers/staging/ste_rmi4/board-mop500-u8500uib-rmi4.c b/drivers/staging/ste_rmi4/board-mop500-u8500uib-rmi4.c
deleted file mode 100644
index 47439c3..0000000
--- a/drivers/staging/ste_rmi4/board-mop500-u8500uib-rmi4.c
+++ /dev/null
@@ -1,31 +0,0 @@
-/*
- * Some platform data for the RMI4 touchscreen that will override the __weak
- * platform data in the Ux500 machine if this driver is activated.
- */
-#include <linux/i2c.h>
-#include <linux/gpio.h>
-#include <linux/interrupt.h>
-#include <mach/irqs.h>
-#include "synaptics_i2c_rmi4.h"
-
-/*
- * Synaptics RMI4 touchscreen interface on the U8500 UIB
- */
-
-/*
- * Descriptor structure.
- * Describes the number of i2c devices on the bus that speak RMI.
- */
-static struct synaptics_rmi4_platform_data rmi4_i2c_dev_platformdata = {
-	.irq_number     = NOMADIK_GPIO_TO_IRQ(84),
-	.irq_type       = (IRQF_TRIGGER_FALLING | IRQF_SHARED),
-	.x_flip		= false,
-	.y_flip		= true,
-};
-
-struct i2c_board_info __initdata mop500_i2c3_devices_u8500[] = {
-	{
-		I2C_BOARD_INFO("synaptics_rmi4_i2c", 0x4B),
-		.platform_data = &rmi4_i2c_dev_platformdata,
-	},
-};
diff --git a/drivers/staging/ste_rmi4/synaptics_i2c_rmi4.c b/drivers/staging/ste_rmi4/synaptics_i2c_rmi4.c
index 6a21f67..2e35307 100644
--- a/drivers/staging/ste_rmi4/synaptics_i2c_rmi4.c
+++ b/drivers/staging/ste_rmi4/synaptics_i2c_rmi4.c
@@ -864,6 +864,16 @@ static int synaptics_rmi4_i2c_query_device(struct synaptics_rmi4_data *pdata)
 	return 0;
 }
 
+/*
+ * Descriptor structure.
+ * Describes the number of i2c devices on the bus that speak RMI.
+ */
+static struct synaptics_rmi4_platform_data synaptics_rmi4_platformdata = {
+	.irq_type       = (IRQF_TRIGGER_FALLING | IRQF_SHARED),
+	.x_flip		= false,
+	.y_flip		= true,
+};
+
 /**
  * synaptics_rmi4_probe() - Initialze the i2c-client touchscreen driver
  * @i2c: i2c client structure pointer
@@ -890,10 +900,8 @@ static int synaptics_rmi4_probe
 		return -EIO;
 	}
 
-	if (!platformdata) {
-		dev_err(&client->dev, "%s: no platform data\n", __func__);
-		return -EINVAL;
-	}
+	if (!platformdata)
+		platformdata = &synaptics_rmi4_platformdata;
 
 	/* Allocate and initialize the instance data for this client */
 	rmi4_data = kcalloc(2, sizeof(struct synaptics_rmi4_data),
@@ -977,13 +985,13 @@ static int synaptics_rmi4_probe
 	synaptics_rmi4_i2c_block_read(rmi4_data,
 			rmi4_data->fn01_data_base_addr + 1, intr_status,
 				rmi4_data->number_of_interrupt_register);
-	retval = request_threaded_irq(platformdata->irq_number, NULL,
+	retval = request_threaded_irq(client->irq, NULL,
 					synaptics_rmi4_irq,
 					platformdata->irq_type,
 					DRIVER_NAME, rmi4_data);
 	if (retval) {
 		dev_err(&client->dev, "%s:Unable to get attn irq %d\n",
-				__func__, platformdata->irq_number);
+				__func__, client->irq);
 		goto err_query_dev;
 	}
 
@@ -996,7 +1004,7 @@ static int synaptics_rmi4_probe
 	return retval;
 
 err_free_irq:
-	free_irq(platformdata->irq_number, rmi4_data);
+	free_irq(client->irq, rmi4_data);
 err_query_dev:
 	regulator_disable(rmi4_data->regulator);
 err_regulator_enable:
@@ -1019,11 +1027,10 @@ err_input:
 static int synaptics_rmi4_remove(struct i2c_client *client)
 {
 	struct synaptics_rmi4_data *rmi4_data = i2c_get_clientdata(client);
-	const struct synaptics_rmi4_platform_data *pdata = rmi4_data->board;
 
 	rmi4_data->touch_stopped = true;
 	wake_up(&rmi4_data->wait);
-	free_irq(pdata->irq_number, rmi4_data);
+	free_irq(client->irq, rmi4_data);
 	input_unregister_device(rmi4_data->input_dev);
 	regulator_disable(rmi4_data->regulator);
 	regulator_put(rmi4_data->regulator);
@@ -1046,10 +1053,9 @@ static int synaptics_rmi4_suspend(struct device *dev)
 	int retval;
 	unsigned char intr_status;
 	struct synaptics_rmi4_data *rmi4_data = dev_get_drvdata(dev);
-	const struct synaptics_rmi4_platform_data *pdata = rmi4_data->board;
 
 	rmi4_data->touch_stopped = true;
-	disable_irq(pdata->irq_number);
+	disable_irq(rmi4_data->i2c_client->irq);
 
 	retval = synaptics_rmi4_i2c_block_read(rmi4_data,
 				rmi4_data->fn01_data_base_addr + 1,
@@ -1080,11 +1086,10 @@ static int synaptics_rmi4_resume(struct device *dev)
 	int retval;
 	unsigned char intr_status;
 	struct synaptics_rmi4_data *rmi4_data = dev_get_drvdata(dev);
-	const struct synaptics_rmi4_platform_data *pdata = rmi4_data->board;
 
 	regulator_enable(rmi4_data->regulator);
 
-	enable_irq(pdata->irq_number);
+	enable_irq(rmi4_data->i2c_client->irq);
 	rmi4_data->touch_stopped = false;
 
 	retval = synaptics_rmi4_i2c_block_read(rmi4_data,
diff --git a/drivers/staging/ste_rmi4/synaptics_i2c_rmi4.h b/drivers/staging/ste_rmi4/synaptics_i2c_rmi4.h
index 384436e..8c9166b 100644
--- a/drivers/staging/ste_rmi4/synaptics_i2c_rmi4.h
+++ b/drivers/staging/ste_rmi4/synaptics_i2c_rmi4.h
@@ -38,7 +38,6 @@
  * This structure gives platform data for rmi4.
  */
 struct synaptics_rmi4_platform_data {
-	int irq_number;
 	int irq_type;
 	bool x_flip;
 	bool y_flip;
-- 
1.7.11.3



From florian at openwrt.org  Fri Apr  5 10:23:17 2013
From: florian at openwrt.org (Florian Fainelli)
Date: Fri, 05 Apr 2013 16:23:17 +0200
Subject: [PATCH 1/5 v2] mv643xx_eth: add Device Tree bindings
In-Reply-To: <CABJ1b_TdzE_Q9qLsdSGZy8byFpCTtVBUy5FtxiZAx7QqgG-rVg@mail.gmail.com>
References: <1365071235-11611-1-git-send-email-florian@openwrt.org>
 <1365071235-11611-2-git-send-email-florian@openwrt.org>
 <20130404212906.GA25904@schnuecks.de> <515E9FE0.8050402@openwrt.org>
 <CABJ1b_TdzE_Q9qLsdSGZy8byFpCTtVBUy5FtxiZAx7QqgG-rVg@mail.gmail.com>
Message-ID: <515EDE55.9030609@openwrt.org>

Hello Sebastian,

Le 04/05/13 15:58, Sebastian Hesselbarth a ?crit :
> On Fri, Apr 5, 2013 at 11:56 AM, Florian Fainelli <florian at openwrt.org> wrote:
>> [snip]
>
> Florian,
>
> took me a while to try you patches out on Dove but now I fixed all
> issues. I will
> comment on all related patches but first I want to comment here.
>
> One general note for Dove related patches: You didn't remove the registration of
> ge platform_device from mach-dove/board-dt.c. That will lead to double
> registration
> of mdio and mv643xx_eth/shared, so you'll never be sure if DT or non-DT code is
> executed. I haven't checked mach-kirkwood/board-dt.c or orion5x code.

This was intentional, this patchset is just preparatory in the sense 
that it does no conversion of the existing users of the mv643xx_eth 
platform driver over DT (have some patches to that though). I wanted to 
resume the discussion on these bindings first, then proceed with the 
conversion.

>
>>>>          if (!mv643xx_eth_version_printed++)
>>>>                  pr_notice("MV-643xx 10/100/1000 ethernet driver version
>>>> %s\n",
>>>
>>>
>>> This is not related to your change, but there is a problem in this
>>> function that has already been discussed in the past if I remember
>>> correctly: The respective clock needs to be enabled here (at least
>>> on Kirkwood), since accesses to the hardware are done below.
>>> Enabling the clock only in mv643xx_eth_probe() is too late.
>>>
>>> As said, this is not a problem introduced by your changes (and which
>>> is currently circumvented by enabling the respective clocks in
>>> kirkwood_legacy_clk_init() and kirkwood_ge0x_init()), but we might
>>> want to fix this now to get rid of unconditionally enabling the GE
>>> clocks in the DT case.
>>
>>
>> I think there may have been some confusion between the "ethernet-group"
>> clock and the actual Ethernet port inside the "ethernet-group". The
>> mv643xx_eth driver assumes we have a per-port clock gating scheme, while I
>> think we have a per "ethernet-group" clock gating scheme instead. Like you
>> said, I think this should be addressed separately.
>
> IMHO, there should be a clocks property where ever you try to access registers,
> i.e. in all three "parts" mv643xx_eth_shared (group), mv643xx_eth
> (port) and mdio.
> Since port depends on shared it would be ok to have it per group but that may
> collide with other SoCs than Dove/Kirkwood that have per port clocks.

Ok, which means that we should also teach mv643xx_eth_shared_probe() 
about it, as well as the orion-mdio driver. I don't have any particular 
objections since it should just make things safer with respect to clocking.

>
> Is that separation (group/port) really required for any SoC?

Probably not, it was not clear when I looked at mv78xx0 if it uses two 
ports per group or 4 groups and 1 port. Anyway, since we are re-using 
the existing Device Tree binding definition and that the hardware 
present itself as ethernet groups and ports, I don't see any problem 
with keeping that difference since it allows for fine-grained 
representation of the hardware.

>
>>
>> [snip]
>>>
>>> You don't change the clk initialization here:
>>>
>>> #if defined(CONFIG_HAVE_CLK)
>>>          mp->clk = clk_get(&pdev->dev, (pdev->id ? "1" : "0"));
>>>          if (!IS_ERR(mp->clk)) {
>>>                  clk_prepare_enable(mp->clk);
>>>                  mp->t_clk = clk_get_rate(mp->clk);
>>>          }
>>> #endif
>>>
>>> Which, if I understand correctly, works in the DT case because you
>>> assign "clock-names" to the clocks in the DTS. However, I wonder
>>> whether this works for any but the first Ethernet device.
>
> Yes, it does. Assigned clocks from clocks property get a clock alias for
> that device name (node name). Using anything else than NULL here is
> IMHO just wrong. We should rather provide proper clock aliases for non-DT case.
>
>>> In the old platform device setup, the pdev->id was set when
>>> initialiazing the platform_device structure in common.c.  Where is
>>> this done in the DT case?
>>
>> Looks like you are right, in the DT case, I assume that we should lookup the
>> clock using NULL instead of "1" or "0" so we match any clock instead of a
>> specific one.
>
> Yes.
>
>> [snip]
>>>
>>>
>>> In phy_scan(), the phy is searched like this:
>>>
>>>                  snprintf(phy_id, sizeof(phy_id), PHY_ID_FMT,
>>>                                  "orion-mdio-mii", addr);
>>>
>>>                  phydev = phy_connect(mp->dev, phy_id,
>>> mv643xx_eth_adjust_link,
>>>                                  PHY_INTERFACE_MODE_GMII);
>>>
>>> But "orion-mdio-mii:xx" is the name of the PHY if MDIO is setup via a
>>> platform_device. I could not get this to work if the MDIO device is
>>> setup via DT. Am I doing something wrong?
>>
>> I just missed updating this part of the code to probe for PHYs. The board I
>> tested with uses a "PHY_NONE" configuration. I will add the missing bits for
>> of_phy_connect() to be called here.
>
> I don't think that the ethernet controller should probe the PHY's on mdio-bus
> at all. At least not for DT enabled platforms. I had a look at DT and non-DT
> mdio-bus sources, and realized that there is a bus scan for non-DT only.
> of_mdiobus_register requires you to set (and know) the PHY address.

One reason the Ethernet controller could do the probing is in the case 
we need to apply quirks (e.g: using phydev->flags) for instance. This 
can be done even after the MDIO bus driver did probe PHY devices though.

>
> I prepared a patch for of_mdio_register that will allow you to probe mdio and
> assign phy addresses to each node found. Currently, the heuristic for probing
> is: assign each phy node the next probed phy_addr starting with 0. But that
> will not allow to e.g. set some PHY addresses and probe the rest.

Ok, we just need to make sure that this does not break any specific use 
case, I don't think it does, since it seems to be more accurate or 
equivalent to Ethernet driver doing the probing.

>
> We had a similar discussion whether to probe or not for DT nodes, and I guess
> there also will be some discussion about the above patch. OTOH we could just
> (again) ask users of every kirkwood/orion5x/dove board to tell their
> phy addresses
> and fail to probe the phy for new boards...
>
> I will prepare a proper patch soon and post it on the corresponding lists.

Cool, thanks!

>
>>> Additionally, in phy_scan() there is this:
>>>
>>>          if (phy_addr == MV643XX_ETH_PHY_ADDR_DEFAULT) {
>>>                  start = phy_addr_get(mp) & 0x1f;
>>>                  num = 32;
>>>          } else {
>>>          ...
>>>
>>> MV643XX_ETH_PHY_ADDR_DEFAULT is defined as 0. However, many Kirkwood
>>> devices use "MV643XX_ETH_PHY_ADDR(0)".  If the module probe is
>>> deferred in mv643xx_eth because the MDIO driver is not yet loaded,
>>> all 32 PHY addresses are scanned without success.  This is not needed
>>> and clutters the log.
>>
>>
>> Ok, I am not sure how we can circumvent the log cluttering that happens,
>> what would be your suggestion?
>
> My suggestion is to change MV643XX_ETH_PHY_ADDR_DEFAULT from a valid
> phy address (0)
> to something invalid (32). I understand that using 0 helps if you
> don't want to set it in mv643xx's platform_data
> but it is always difficult to rely on that if 0 is a valid number.
>
> Changing the above to 32 should just work because most (all?) boards
> using phy_scan should also
> already use MV643XX_ETH_PHY_ADDR_DEFAULT. I also suggest to rename
> current define to a
> better name, e.g. MV643XX_ETH_PHY_ADDR_AUTOSCAN.

Sounds good to me.
--
Florian


From linus.walleij at stericsson.com  Fri Apr  5 10:22:48 2013
From: linus.walleij at stericsson.com (Linus Walleij)
Date: Fri, 5 Apr 2013 16:22:48 +0200
Subject: [PATCH 06/14] mfd: db8500-prcmu: get base address from resource
In-Reply-To: <1365171776-8463-1-git-send-email-linus.walleij@stericsson.com>
References: <1365171776-8463-1-git-send-email-linus.walleij@stericsson.com>
Message-ID: <1365171776-8463-7-git-send-email-linus.walleij@stericsson.com>

From: Linus Walleij <linus.walleij at linaro.org>

We cannot use a global variable stored in <mach/hardware.h> to
find the base address of the PRCMU. The real resource is already
there from the board, so use this to look up the base address
instead.

Currently the patch is kept minimal so as not to interfere with
other work being done on refactoring this driver, but at a later
point the defines using (prcmu_base + 0xnnn) need to be replaced
by pure offset defined for (0xnnn) and the base inlined with the
readl()/writel() and similar codepaths.

Cc: Samuel Ortiz <sameo at linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
Sam, I'm requesting an ACK for taking this through the
ARM SoC tree.
---
 arch/arm/mach-ux500/cpu-db8500.c            |   2 -
 arch/arm/mach-ux500/cpu.c                   |   2 -
 arch/arm/mach-ux500/include/mach/hardware.h |   2 -
 drivers/mfd/db8500-prcmu.c                  |  47 ++++---
 drivers/mfd/dbx500-prcmu-regs.h             | 208 ++++++++++++++--------------
 5 files changed, 131 insertions(+), 130 deletions(-)

diff --git a/arch/arm/mach-ux500/cpu-db8500.c b/arch/arm/mach-ux500/cpu-db8500.c
index 19235cf..8c58dff 100644
--- a/arch/arm/mach-ux500/cpu-db8500.c
+++ b/arch/arm/mach-ux500/cpu-db8500.c
@@ -94,8 +94,6 @@ void __init u8500_map_io(void)
 		iotable_init(u9540_io_desc, ARRAY_SIZE(u9540_io_desc));
 	else
 		iotable_init(u8500_io_desc, ARRAY_SIZE(u8500_io_desc));
-
-	_PRCMU_BASE = __io_address(U8500_PRCMU_BASE);
 }
 
 static struct resource db8500_pmu_resources[] = {
diff --git a/arch/arm/mach-ux500/cpu.c b/arch/arm/mach-ux500/cpu.c
index af13b6d..38459e9 100644
--- a/arch/arm/mach-ux500/cpu.c
+++ b/arch/arm/mach-ux500/cpu.c
@@ -30,8 +30,6 @@
 #include "board-mop500.h"
 #include "id.h"
 
-void __iomem *_PRCMU_BASE;
-
 /*
  * FIXME: Should we set up the GPIO domain here?
  *
diff --git a/arch/arm/mach-ux500/include/mach/hardware.h b/arch/arm/mach-ux500/include/mach/hardware.h
index 5201dda..4eece2a 100644
--- a/arch/arm/mach-ux500/include/mach/hardware.h
+++ b/arch/arm/mach-ux500/include/mach/hardware.h
@@ -39,8 +39,6 @@
 
 #ifndef __ASSEMBLY__
 
-extern void __iomem *_PRCMU_BASE;
-
 #define ARRAY_AND_SIZE(x)	(x), ARRAY_SIZE(x)
 
 #endif				/* __ASSEMBLY__ */
diff --git a/drivers/mfd/db8500-prcmu.c b/drivers/mfd/db8500-prcmu.c
index 9166427..acb8ef7 100644
--- a/drivers/mfd/db8500-prcmu.c
+++ b/drivers/mfd/db8500-prcmu.c
@@ -422,9 +422,10 @@ static DEFINE_SPINLOCK(clkout_lock);
 
 /* Global var to runtime determine TCDM base for v2 or v1 */
 static __iomem void *tcdm_base;
+static __iomem void *prcmu_base;
 
 struct clk_mgt {
-	void __iomem *reg;
+	u32 offset;
 	u32 pllsw;
 	int branch;
 	bool clk38div;
@@ -599,9 +600,9 @@ int db8500_prcmu_set_display_clocks(void)
 	while ((readl(PRCM_SEM) & PRCM_SEM_PRCM_SEM) != 0)
 		cpu_relax();
 
-	writel(PRCMU_DSI_CLOCK_SETTING, PRCM_HDMICLK_MGT);
-	writel(PRCMU_DSI_LP_CLOCK_SETTING, PRCM_TVCLK_MGT);
-	writel(PRCMU_DPI_CLOCK_SETTING, PRCM_LCDCLK_MGT);
+	writel(PRCMU_DSI_CLOCK_SETTING, prcmu_base + PRCM_HDMICLK_MGT);
+	writel(PRCMU_DSI_LP_CLOCK_SETTING, prcmu_base + PRCM_TVCLK_MGT);
+	writel(PRCMU_DPI_CLOCK_SETTING, prcmu_base + PRCM_LCDCLK_MGT);
 
 	/* Release the HW semaphore. */
 	writel(0, PRCM_SEM);
@@ -613,7 +614,7 @@ int db8500_prcmu_set_display_clocks(void)
 
 u32 db8500_prcmu_read(unsigned int reg)
 {
-	return readl(_PRCMU_BASE + reg);
+	return readl(prcmu_base + reg);
 }
 
 void db8500_prcmu_write(unsigned int reg, u32 value)
@@ -621,7 +622,7 @@ void db8500_prcmu_write(unsigned int reg, u32 value)
 	unsigned long flags;
 
 	spin_lock_irqsave(&prcmu_lock, flags);
-	writel(value, (_PRCMU_BASE + reg));
+	writel(value, (prcmu_base + reg));
 	spin_unlock_irqrestore(&prcmu_lock, flags);
 }
 
@@ -631,9 +632,9 @@ void db8500_prcmu_write_masked(unsigned int reg, u32 mask, u32 value)
 	unsigned long flags;
 
 	spin_lock_irqsave(&prcmu_lock, flags);
-	val = readl(_PRCMU_BASE + reg);
+	val = readl(prcmu_base + reg);
 	val = ((val & ~mask) | (value & mask));
-	writel(val, (_PRCMU_BASE + reg));
+	writel(val, (prcmu_base + reg));
 	spin_unlock_irqrestore(&prcmu_lock, flags);
 }
 
@@ -1059,7 +1060,7 @@ int db8500_prcmu_set_ddr_opp(u8 opp)
 /* Divide the frequency of certain clocks by 2 for APE_50_PARTLY_25_OPP. */
 static void request_even_slower_clocks(bool enable)
 {
-	void __iomem *clock_reg[] = {
+	u32 clock_reg[] = {
 		PRCM_ACLK_MGT,
 		PRCM_DMACLK_MGT
 	};
@@ -1076,7 +1077,7 @@ static void request_even_slower_clocks(bool enable)
 		u32 val;
 		u32 div;
 
-		val = readl(clock_reg[i]);
+		val = readl(prcmu_base + clock_reg[i]);
 		div = (val & PRCM_CLK_MGT_CLKPLLDIV_MASK);
 		if (enable) {
 			if ((div <= 1) || (div > 15)) {
@@ -1092,7 +1093,7 @@ static void request_even_slower_clocks(bool enable)
 		}
 		val = ((val & ~PRCM_CLK_MGT_CLKPLLDIV_MASK) |
 			(div & PRCM_CLK_MGT_CLKPLLDIV_MASK));
-		writel(val, clock_reg[i]);
+		writel(val, prcmu_base + clock_reg[i]);
 	}
 
 unlock_and_return:
@@ -1446,14 +1447,14 @@ static int request_clock(u8 clock, bool enable)
 	while ((readl(PRCM_SEM) & PRCM_SEM_PRCM_SEM) != 0)
 		cpu_relax();
 
-	val = readl(clk_mgt[clock].reg);
+	val = readl(prcmu_base + clk_mgt[clock].offset);
 	if (enable) {
 		val |= (PRCM_CLK_MGT_CLKEN | clk_mgt[clock].pllsw);
 	} else {
 		clk_mgt[clock].pllsw = (val & PRCM_CLK_MGT_CLKPLLSW_MASK);
 		val &= ~(PRCM_CLK_MGT_CLKEN | PRCM_CLK_MGT_CLKPLLSW_MASK);
 	}
-	writel(val, clk_mgt[clock].reg);
+	writel(val, prcmu_base + clk_mgt[clock].offset);
 
 	/* Release the HW semaphore. */
 	writel(0, PRCM_SEM);
@@ -1629,7 +1630,7 @@ static unsigned long clock_rate(u8 clock)
 	u32 pllsw;
 	unsigned long rate = ROOT_CLOCK_RATE;
 
-	val = readl(clk_mgt[clock].reg);
+	val = readl(prcmu_base + clk_mgt[clock].offset);
 
 	if (val & PRCM_CLK_MGT_CLK38) {
 		if (clk_mgt[clock].clk38div && (val & PRCM_CLK_MGT_CLK38DIV))
@@ -1785,7 +1786,7 @@ static long round_clock_rate(u8 clock, unsigned long rate)
 	unsigned long src_rate;
 	long rounded_rate;
 
-	val = readl(clk_mgt[clock].reg);
+	val = readl(prcmu_base + clk_mgt[clock].offset);
 	src_rate = clock_source_rate((val | clk_mgt[clock].pllsw),
 		clk_mgt[clock].branch);
 	div = clock_divider(src_rate, rate);
@@ -1933,7 +1934,7 @@ static void set_clock_rate(u8 clock, unsigned long rate)
 	while ((readl(PRCM_SEM) & PRCM_SEM_PRCM_SEM) != 0)
 		cpu_relax();
 
-	val = readl(clk_mgt[clock].reg);
+	val = readl(prcmu_base + clk_mgt[clock].offset);
 	src_rate = clock_source_rate((val | clk_mgt[clock].pllsw),
 		clk_mgt[clock].branch);
 	div = clock_divider(src_rate, rate);
@@ -1961,7 +1962,7 @@ static void set_clock_rate(u8 clock, unsigned long rate)
 		val &= ~PRCM_CLK_MGT_CLKPLLDIV_MASK;
 		val |= min(div, (u32)31);
 	}
-	writel(val, clk_mgt[clock].reg);
+	writel(val, prcmu_base + clk_mgt[clock].offset);
 
 	/* Release the HW semaphore. */
 	writel(0, PRCM_SEM);
@@ -3163,8 +3164,18 @@ static int db8500_prcmu_probe(struct platform_device *pdev)
 	int irq = 0, err = 0, i;
 	struct resource *res;
 
+	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "prcmu");
+	if (!res) {
+		dev_err(&pdev->dev, "no prcmu memory region provided\n");
+		return -ENOENT;
+	}
+	prcmu_base = devm_ioremap(&pdev->dev, res->start, resource_size(res));
+	if (!prcmu_base) {
+		dev_err(&pdev->dev,
+			"failed to ioremap prcmu register memory\n");
+		return -ENOENT;
+	}
 	init_prcm_registers();
-
 	dbx500_fw_version_init(pdev, pdata->version_offset);
 	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "prcmu-tcdm");
 	if (!res) {
diff --git a/drivers/mfd/dbx500-prcmu-regs.h b/drivers/mfd/dbx500-prcmu-regs.h
index 79c76eb..439254d 100644
--- a/drivers/mfd/dbx500-prcmu-regs.h
+++ b/drivers/mfd/dbx500-prcmu-regs.h
@@ -13,136 +13,132 @@
 #ifndef __DB8500_PRCMU_REGS_H
 #define __DB8500_PRCMU_REGS_H
 
-#include <mach/hardware.h>
-
 #define BITS(_start, _end) ((BIT(_end) - BIT(_start)) + BIT(_end))
 
-#define PRCM_CLK_MGT(_offset) (void __iomem *)(IO_ADDRESS(U8500_PRCMU_BASE) \
-	+ _offset)
-#define PRCM_ACLK_MGT		PRCM_CLK_MGT(0x004)
-#define PRCM_SVACLK_MGT		PRCM_CLK_MGT(0x008)
-#define PRCM_SIACLK_MGT		PRCM_CLK_MGT(0x00C)
-#define PRCM_SGACLK_MGT		PRCM_CLK_MGT(0x014)
-#define PRCM_UARTCLK_MGT	PRCM_CLK_MGT(0x018)
-#define PRCM_MSP02CLK_MGT	PRCM_CLK_MGT(0x01C)
-#define PRCM_I2CCLK_MGT		PRCM_CLK_MGT(0x020)
-#define PRCM_SDMMCCLK_MGT	PRCM_CLK_MGT(0x024)
-#define PRCM_SLIMCLK_MGT	PRCM_CLK_MGT(0x028)
-#define PRCM_PER1CLK_MGT	PRCM_CLK_MGT(0x02C)
-#define PRCM_PER2CLK_MGT	PRCM_CLK_MGT(0x030)
-#define PRCM_PER3CLK_MGT	PRCM_CLK_MGT(0x034)
-#define PRCM_PER5CLK_MGT	PRCM_CLK_MGT(0x038)
-#define PRCM_PER6CLK_MGT	PRCM_CLK_MGT(0x03C)
-#define PRCM_PER7CLK_MGT	PRCM_CLK_MGT(0x040)
-#define PRCM_LCDCLK_MGT		PRCM_CLK_MGT(0x044)
-#define PRCM_BMLCLK_MGT		PRCM_CLK_MGT(0x04C)
-#define PRCM_HSITXCLK_MGT	PRCM_CLK_MGT(0x050)
-#define PRCM_HSIRXCLK_MGT	PRCM_CLK_MGT(0x054)
-#define PRCM_HDMICLK_MGT	PRCM_CLK_MGT(0x058)
-#define PRCM_APEATCLK_MGT	PRCM_CLK_MGT(0x05C)
-#define PRCM_APETRACECLK_MGT	PRCM_CLK_MGT(0x060)
-#define PRCM_MCDECLK_MGT	PRCM_CLK_MGT(0x064)
-#define PRCM_IPI2CCLK_MGT	PRCM_CLK_MGT(0x068)
-#define PRCM_DSIALTCLK_MGT	PRCM_CLK_MGT(0x06C)
-#define PRCM_DMACLK_MGT		PRCM_CLK_MGT(0x074)
-#define PRCM_B2R2CLK_MGT	PRCM_CLK_MGT(0x078)
-#define PRCM_TVCLK_MGT		PRCM_CLK_MGT(0x07C)
-#define PRCM_UNIPROCLK_MGT	PRCM_CLK_MGT(0x278)
-#define PRCM_SSPCLK_MGT		PRCM_CLK_MGT(0x280)
-#define PRCM_RNGCLK_MGT		PRCM_CLK_MGT(0x284)
-#define PRCM_UICCCLK_MGT	PRCM_CLK_MGT(0x27C)
-#define PRCM_MSP1CLK_MGT	PRCM_CLK_MGT(0x288)
-
-#define PRCM_ARM_PLLDIVPS	(_PRCMU_BASE + 0x118)
+#define PRCM_ACLK_MGT		(0x004)
+#define PRCM_SVACLK_MGT		(0x008)
+#define PRCM_SIACLK_MGT		(0x00C)
+#define PRCM_SGACLK_MGT		(0x014)
+#define PRCM_UARTCLK_MGT	(0x018)
+#define PRCM_MSP02CLK_MGT	(0x01C)
+#define PRCM_I2CCLK_MGT		(0x020)
+#define PRCM_SDMMCCLK_MGT	(0x024)
+#define PRCM_SLIMCLK_MGT	(0x028)
+#define PRCM_PER1CLK_MGT	(0x02C)
+#define PRCM_PER2CLK_MGT	(0x030)
+#define PRCM_PER3CLK_MGT	(0x034)
+#define PRCM_PER5CLK_MGT	(0x038)
+#define PRCM_PER6CLK_MGT	(0x03C)
+#define PRCM_PER7CLK_MGT	(0x040)
+#define PRCM_LCDCLK_MGT		(0x044)
+#define PRCM_BMLCLK_MGT		(0x04C)
+#define PRCM_HSITXCLK_MGT	(0x050)
+#define PRCM_HSIRXCLK_MGT	(0x054)
+#define PRCM_HDMICLK_MGT	(0x058)
+#define PRCM_APEATCLK_MGT	(0x05C)
+#define PRCM_APETRACECLK_MGT	(0x060)
+#define PRCM_MCDECLK_MGT	(0x064)
+#define PRCM_IPI2CCLK_MGT	(0x068)
+#define PRCM_DSIALTCLK_MGT	(0x06C)
+#define PRCM_DMACLK_MGT		(0x074)
+#define PRCM_B2R2CLK_MGT	(0x078)
+#define PRCM_TVCLK_MGT		(0x07C)
+#define PRCM_UNIPROCLK_MGT	(0x278)
+#define PRCM_SSPCLK_MGT		(0x280)
+#define PRCM_RNGCLK_MGT		(0x284)
+#define PRCM_UICCCLK_MGT	(0x27C)
+#define PRCM_MSP1CLK_MGT	(0x288)
+
+#define PRCM_ARM_PLLDIVPS	(prcmu_base + 0x118)
 #define PRCM_ARM_PLLDIVPS_ARM_BRM_RATE		0x3f
 #define PRCM_ARM_PLLDIVPS_MAX_MASK		0xf
 
-#define PRCM_PLLARM_LOCKP       (_PRCMU_BASE + 0x0a8)
+#define PRCM_PLLARM_LOCKP       (prcmu_base + 0x0a8)
 #define PRCM_PLLARM_LOCKP_PRCM_PLLARM_LOCKP3	0x2
 
-#define PRCM_ARM_CHGCLKREQ	(_PRCMU_BASE + 0x114)
+#define PRCM_ARM_CHGCLKREQ	(prcmu_base + 0x114)
 #define PRCM_ARM_CHGCLKREQ_PRCM_ARM_CHGCLKREQ	BIT(0)
 #define PRCM_ARM_CHGCLKREQ_PRCM_ARM_DIVSEL	BIT(16)
 
-#define PRCM_PLLARM_ENABLE	(_PRCMU_BASE + 0x98)
+#define PRCM_PLLARM_ENABLE	(prcmu_base + 0x98)
 #define PRCM_PLLARM_ENABLE_PRCM_PLLARM_ENABLE	0x1
 #define PRCM_PLLARM_ENABLE_PRCM_PLLARM_COUNTON	0x100
 
-#define PRCM_ARMCLKFIX_MGT	(_PRCMU_BASE + 0x0)
-#define PRCM_A9PL_FORCE_CLKEN	(_PRCMU_BASE + 0x19C)
-#define PRCM_A9_RESETN_CLR	(_PRCMU_BASE + 0x1f4)
-#define PRCM_A9_RESETN_SET	(_PRCMU_BASE + 0x1f0)
-#define PRCM_ARM_LS_CLAMP	(_PRCMU_BASE + 0x30c)
-#define PRCM_SRAM_A9		(_PRCMU_BASE + 0x308)
+#define PRCM_ARMCLKFIX_MGT	(prcmu_base + 0x0)
+#define PRCM_A9PL_FORCE_CLKEN	(prcmu_base + 0x19C)
+#define PRCM_A9_RESETN_CLR	(prcmu_base + 0x1f4)
+#define PRCM_A9_RESETN_SET	(prcmu_base + 0x1f0)
+#define PRCM_ARM_LS_CLAMP	(prcmu_base + 0x30c)
+#define PRCM_SRAM_A9		(prcmu_base + 0x308)
 
 #define PRCM_A9PL_FORCE_CLKEN_PRCM_A9PL_FORCE_CLKEN BIT(0)
 #define PRCM_A9PL_FORCE_CLKEN_PRCM_A9AXI_FORCE_CLKEN BIT(1)
 
 /* ARM WFI Standby signal register */
-#define PRCM_ARM_WFI_STANDBY    (_PRCMU_BASE + 0x130)
+#define PRCM_ARM_WFI_STANDBY    (prcmu_base + 0x130)
 #define PRCM_ARM_WFI_STANDBY_WFI0               0x08
 #define PRCM_ARM_WFI_STANDBY_WFI1               0x10
-#define PRCM_IOCR		(_PRCMU_BASE + 0x310)
+#define PRCM_IOCR		(prcmu_base + 0x310)
 #define PRCM_IOCR_IOFORCE			0x1
 
 /* CPU mailbox registers */
-#define PRCM_MBOX_CPU_VAL	(_PRCMU_BASE + 0x0fc)
-#define PRCM_MBOX_CPU_SET	(_PRCMU_BASE + 0x100)
-#define PRCM_MBOX_CPU_CLR	(_PRCMU_BASE + 0x104)
+#define PRCM_MBOX_CPU_VAL	(prcmu_base + 0x0fc)
+#define PRCM_MBOX_CPU_SET	(prcmu_base + 0x100)
+#define PRCM_MBOX_CPU_CLR	(prcmu_base + 0x104)
 
 /* Dual A9 core interrupt management unit registers */
-#define PRCM_A9_MASK_REQ	(_PRCMU_BASE + 0x328)
+#define PRCM_A9_MASK_REQ	(prcmu_base + 0x328)
 #define PRCM_A9_MASK_REQ_PRCM_A9_MASK_REQ	0x1
 
-#define PRCM_A9_MASK_ACK	(_PRCMU_BASE + 0x32c)
-#define PRCM_ARMITMSK31TO0	(_PRCMU_BASE + 0x11c)
-#define PRCM_ARMITMSK63TO32	(_PRCMU_BASE + 0x120)
-#define PRCM_ARMITMSK95TO64	(_PRCMU_BASE + 0x124)
-#define PRCM_ARMITMSK127TO96	(_PRCMU_BASE + 0x128)
-#define PRCM_POWER_STATE_VAL	(_PRCMU_BASE + 0x25C)
-#define PRCM_ARMITVAL31TO0	(_PRCMU_BASE + 0x260)
-#define PRCM_ARMITVAL63TO32	(_PRCMU_BASE + 0x264)
-#define PRCM_ARMITVAL95TO64	(_PRCMU_BASE + 0x268)
-#define PRCM_ARMITVAL127TO96	(_PRCMU_BASE + 0x26C)
-
-#define PRCM_HOSTACCESS_REQ	(_PRCMU_BASE + 0x334)
+#define PRCM_A9_MASK_ACK	(prcmu_base + 0x32c)
+#define PRCM_ARMITMSK31TO0	(prcmu_base + 0x11c)
+#define PRCM_ARMITMSK63TO32	(prcmu_base + 0x120)
+#define PRCM_ARMITMSK95TO64	(prcmu_base + 0x124)
+#define PRCM_ARMITMSK127TO96	(prcmu_base + 0x128)
+#define PRCM_POWER_STATE_VAL	(prcmu_base + 0x25C)
+#define PRCM_ARMITVAL31TO0	(prcmu_base + 0x260)
+#define PRCM_ARMITVAL63TO32	(prcmu_base + 0x264)
+#define PRCM_ARMITVAL95TO64	(prcmu_base + 0x268)
+#define PRCM_ARMITVAL127TO96	(prcmu_base + 0x26C)
+
+#define PRCM_HOSTACCESS_REQ	(prcmu_base + 0x334)
 #define PRCM_HOSTACCESS_REQ_HOSTACCESS_REQ 0x1
 #define PRCM_HOSTACCESS_REQ_WAKE_REQ	BIT(16)
 #define ARM_WAKEUP_MODEM	0x1
 
-#define PRCM_ARM_IT1_CLR	(_PRCMU_BASE + 0x48C)
-#define PRCM_ARM_IT1_VAL	(_PRCMU_BASE + 0x494)
-#define PRCM_HOLD_EVT		(_PRCMU_BASE + 0x174)
+#define PRCM_ARM_IT1_CLR	(prcmu_base + 0x48C)
+#define PRCM_ARM_IT1_VAL	(prcmu_base + 0x494)
+#define PRCM_HOLD_EVT		(prcmu_base + 0x174)
 
-#define PRCM_MOD_AWAKE_STATUS	(_PRCMU_BASE + 0x4A0)
+#define PRCM_MOD_AWAKE_STATUS	(prcmu_base + 0x4A0)
 #define PRCM_MOD_AWAKE_STATUS_PRCM_MOD_COREPD_AWAKE	BIT(0)
 #define PRCM_MOD_AWAKE_STATUS_PRCM_MOD_AAPD_AWAKE	BIT(1)
 #define PRCM_MOD_AWAKE_STATUS_PRCM_MOD_VMODEM_OFF_ISO	BIT(2)
 
-#define PRCM_ITSTATUS0		(_PRCMU_BASE + 0x148)
-#define PRCM_ITSTATUS1		(_PRCMU_BASE + 0x150)
-#define PRCM_ITSTATUS2		(_PRCMU_BASE + 0x158)
-#define PRCM_ITSTATUS3		(_PRCMU_BASE + 0x160)
-#define PRCM_ITSTATUS4		(_PRCMU_BASE + 0x168)
-#define PRCM_ITSTATUS5		(_PRCMU_BASE + 0x484)
-#define PRCM_ITCLEAR5		(_PRCMU_BASE + 0x488)
-#define PRCM_ARMIT_MASKXP70_IT	(_PRCMU_BASE + 0x1018)
+#define PRCM_ITSTATUS0		(prcmu_base + 0x148)
+#define PRCM_ITSTATUS1		(prcmu_base + 0x150)
+#define PRCM_ITSTATUS2		(prcmu_base + 0x158)
+#define PRCM_ITSTATUS3		(prcmu_base + 0x160)
+#define PRCM_ITSTATUS4		(prcmu_base + 0x168)
+#define PRCM_ITSTATUS5		(prcmu_base + 0x484)
+#define PRCM_ITCLEAR5		(prcmu_base + 0x488)
+#define PRCM_ARMIT_MASKXP70_IT	(prcmu_base + 0x1018)
 
 /* System reset register */
-#define PRCM_APE_SOFTRST	(_PRCMU_BASE + 0x228)
+#define PRCM_APE_SOFTRST	(prcmu_base + 0x228)
 
 /* Level shifter and clamp control registers */
-#define PRCM_MMIP_LS_CLAMP_SET     (_PRCMU_BASE + 0x420)
-#define PRCM_MMIP_LS_CLAMP_CLR     (_PRCMU_BASE + 0x424)
+#define PRCM_MMIP_LS_CLAMP_SET     (prcmu_base + 0x420)
+#define PRCM_MMIP_LS_CLAMP_CLR     (prcmu_base + 0x424)
 
 #define PRCM_MMIP_LS_CLAMP_DSIPLL_CLAMP		BIT(11)
 #define PRCM_MMIP_LS_CLAMP_DSIPLL_CLAMPI	BIT(22)
 
 /* PRCMU clock/PLL/reset registers */
-#define PRCM_PLLSOC0_FREQ	   (_PRCMU_BASE + 0x080)
-#define PRCM_PLLSOC1_FREQ	   (_PRCMU_BASE + 0x084)
-#define PRCM_PLLARM_FREQ	   (_PRCMU_BASE + 0x088)
-#define PRCM_PLLDDR_FREQ	   (_PRCMU_BASE + 0x08C)
+#define PRCM_PLLSOC0_FREQ	   (prcmu_base + 0x080)
+#define PRCM_PLLSOC1_FREQ	   (prcmu_base + 0x084)
+#define PRCM_PLLARM_FREQ	   (prcmu_base + 0x088)
+#define PRCM_PLLDDR_FREQ	   (prcmu_base + 0x08C)
 #define PRCM_PLL_FREQ_D_SHIFT	0
 #define PRCM_PLL_FREQ_D_MASK	BITS(0, 7)
 #define PRCM_PLL_FREQ_N_SHIFT	8
@@ -152,14 +148,14 @@
 #define PRCM_PLL_FREQ_SELDIV2	BIT(24)
 #define PRCM_PLL_FREQ_DIV2EN	BIT(25)
 
-#define PRCM_PLLDSI_FREQ           (_PRCMU_BASE + 0x500)
-#define PRCM_PLLDSI_ENABLE         (_PRCMU_BASE + 0x504)
-#define PRCM_PLLDSI_LOCKP          (_PRCMU_BASE + 0x508)
-#define PRCM_DSI_PLLOUT_SEL        (_PRCMU_BASE + 0x530)
-#define PRCM_DSITVCLK_DIV          (_PRCMU_BASE + 0x52C)
-#define PRCM_PLLDSI_LOCKP          (_PRCMU_BASE + 0x508)
-#define PRCM_APE_RESETN_SET        (_PRCMU_BASE + 0x1E4)
-#define PRCM_APE_RESETN_CLR        (_PRCMU_BASE + 0x1E8)
+#define PRCM_PLLDSI_FREQ           (prcmu_base + 0x500)
+#define PRCM_PLLDSI_ENABLE         (prcmu_base + 0x504)
+#define PRCM_PLLDSI_LOCKP          (prcmu_base + 0x508)
+#define PRCM_DSI_PLLOUT_SEL        (prcmu_base + 0x530)
+#define PRCM_DSITVCLK_DIV          (prcmu_base + 0x52C)
+#define PRCM_PLLDSI_LOCKP          (prcmu_base + 0x508)
+#define PRCM_APE_RESETN_SET        (prcmu_base + 0x1E4)
+#define PRCM_APE_RESETN_CLR        (prcmu_base + 0x1E8)
 
 #define PRCM_PLLDSI_ENABLE_PRCM_PLLDSI_ENABLE BIT(0)
 
@@ -188,30 +184,30 @@
 
 #define PRCM_APE_RESETN_DSIPLL_RESETN BIT(14)
 
-#define PRCM_CLKOCR		   (_PRCMU_BASE + 0x1CC)
+#define PRCM_CLKOCR		   (prcmu_base + 0x1CC)
 #define PRCM_CLKOCR_CLKOUT0_REF_CLK	(1 << 0)
 #define PRCM_CLKOCR_CLKOUT0_MASK	BITS(0, 13)
 #define PRCM_CLKOCR_CLKOUT1_REF_CLK	(1 << 16)
 #define PRCM_CLKOCR_CLKOUT1_MASK	BITS(16, 29)
 
 /* ePOD and memory power signal control registers */
-#define PRCM_EPOD_C_SET            (_PRCMU_BASE + 0x410)
-#define PRCM_SRAM_LS_SLEEP         (_PRCMU_BASE + 0x304)
+#define PRCM_EPOD_C_SET            (prcmu_base + 0x410)
+#define PRCM_SRAM_LS_SLEEP         (prcmu_base + 0x304)
 
 /* Debug power control unit registers */
-#define PRCM_POWER_STATE_SET       (_PRCMU_BASE + 0x254)
+#define PRCM_POWER_STATE_SET       (prcmu_base + 0x254)
 
 /* Miscellaneous unit registers */
-#define PRCM_DSI_SW_RESET          (_PRCMU_BASE + 0x324)
-#define PRCM_GPIOCR                (_PRCMU_BASE + 0x138)
+#define PRCM_DSI_SW_RESET          (prcmu_base + 0x324)
+#define PRCM_GPIOCR                (prcmu_base + 0x138)
 #define PRCM_GPIOCR_DBG_STM_MOD_CMD1            0x800
 #define PRCM_GPIOCR_DBG_UARTMOD_CMD0            0x1
 
 /* PRCMU HW semaphore */
-#define PRCM_SEM                   (_PRCMU_BASE + 0x400)
+#define PRCM_SEM                   (prcmu_base + 0x400)
 #define PRCM_SEM_PRCM_SEM BIT(0)
 
-#define PRCM_TCR                   (_PRCMU_BASE + 0x1C8)
+#define PRCM_TCR                   (prcmu_base + 0x1C8)
 #define PRCM_TCR_TENSEL_MASK       BITS(0, 7)
 #define PRCM_TCR_STOP_TIMERS       BIT(16)
 #define PRCM_TCR_DOZE_MODE         BIT(17)
@@ -239,15 +235,15 @@
 /* GPIOCR register */
 #define PRCM_GPIOCR_SPI2_SELECT BIT(23)
 
-#define PRCM_DDR_SUBSYS_APE_MINBW	(_PRCMU_BASE + 0x438)
-#define PRCM_CGATING_BYPASS		(_PRCMU_BASE + 0x134)
+#define PRCM_DDR_SUBSYS_APE_MINBW	(prcmu_base + 0x438)
+#define PRCM_CGATING_BYPASS		(prcmu_base + 0x134)
 #define PRCM_CGATING_BYPASS_ICN2	BIT(6)
 
 /* Miscellaneous unit registers */
-#define PRCM_RESOUTN_SET		(_PRCMU_BASE + 0x214)
-#define PRCM_RESOUTN_CLR		(_PRCMU_BASE + 0x218)
+#define PRCM_RESOUTN_SET		(prcmu_base + 0x214)
+#define PRCM_RESOUTN_CLR		(prcmu_base + 0x218)
 
 /* System reset register */
-#define PRCM_APE_SOFTRST		(_PRCMU_BASE + 0x228)
+#define PRCM_APE_SOFTRST		(prcmu_base + 0x228)
 
 #endif /* __DB8500_PRCMU_REGS_H */
-- 
1.7.11.3



From linus.walleij at stericsson.com  Fri Apr  5 10:22:51 2013
From: linus.walleij at stericsson.com (Linus Walleij)
Date: Fri, 5 Apr 2013 16:22:51 +0200
Subject: [PATCH 09/14] ARM: ux500: get rid of <mach/[hardware|db8500-regs].h>
In-Reply-To: <1365171776-8463-1-git-send-email-linus.walleij@stericsson.com>
References: <1365171776-8463-1-git-send-email-linus.walleij@stericsson.com>
Message-ID: <1365171776-8463-10-git-send-email-linus.walleij@stericsson.com>

From: Linus Walleij <linus.walleij at linaro.org>

This removes <mach/hardware.h> and <mach/db8500-regs.h>
from the Ux500, merging them into the local include
"db8500-regs.h" in mach-ux500. There is some impact
outside the ux500 machine, but most of it is dealt with
in earlier patches.

Contains portions of a clean-up patch from Arnd Bergmann.

Cc: Samuel Ortiz <sameo at linux.intel.com>
Cc: Ulf Hansson <ulf.hansson at linaro.org>
Acked-by: Mike Turquette <mturquette at linaro.org>
Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
ChangeLog v1->v2:
- Remove erroneous hunk adding the GIC distbase as resource
  to the PRCMU. This was done away with in the previous patch.
- Split debug-macro portions into a separate patch.

Sam: seeking your ACKs to take this through ARM SoC.
---
 arch/arm/mach-ux500/board-mop500-audio.c           |  1 -
 arch/arm/mach-ux500/board-mop500-pins.c            |  2 -
 arch/arm/mach-ux500/board-mop500-sdi.c             |  2 +-
 arch/arm/mach-ux500/board-mop500-uib.c             |  1 -
 arch/arm/mach-ux500/board-mop500.c                 |  2 +-
 arch/arm/mach-ux500/cache-l2x0.c                   |  2 +-
 arch/arm/mach-ux500/cpu-db8500.c                   |  4 +-
 arch/arm/mach-ux500/cpu.c                          |  2 +-
 arch/arm/mach-ux500/cpuidle.c                      |  2 +
 .../mach-ux500/{include/mach => }/db8500-regs.h    | 28 ++++++++++++++
 arch/arm/mach-ux500/devices-common.c               |  1 -
 arch/arm/mach-ux500/devices-db8500.c               |  2 +-
 arch/arm/mach-ux500/devices-db8500.h               |  1 +
 arch/arm/mach-ux500/devices.c                      |  3 +-
 arch/arm/mach-ux500/id.c                           |  2 +-
 arch/arm/mach-ux500/include/mach/hardware.h        | 45 ----------------------
 arch/arm/mach-ux500/include/mach/irqs.h            |  2 -
 arch/arm/mach-ux500/include/mach/uncompress.h      |  3 +-
 arch/arm/mach-ux500/platsmp.c                      |  2 +-
 arch/arm/mach-ux500/pm.c                           |  2 +-
 arch/arm/mach-ux500/timer.c                        |  2 +-
 arch/arm/mach-ux500/usb.c                          |  2 +-
 drivers/clk/ux500/clk-prcc.c                       |  1 -
 drivers/clocksource/clksrc-dbx500-prcmu.c          |  1 -
 drivers/crypto/ux500/cryp/cryp.c                   |  2 -
 drivers/crypto/ux500/cryp/cryp_core.c              |  1 -
 drivers/crypto/ux500/hash/hash_core.c              |  1 -
 drivers/mfd/db8500-prcmu.c                         |  2 -
 drivers/mfd/dbx500-prcmu-regs.h                    | 22 -----------
 sound/soc/ux500/mop500_ab8500.c                    |  2 -
 sound/soc/ux500/ux500_msp_dai.c                    |  2 -
 sound/soc/ux500/ux500_msp_i2s.c                    |  2 -
 32 files changed, 46 insertions(+), 103 deletions(-)
 rename arch/arm/mach-ux500/{include/mach => }/db8500-regs.h (88%)
 delete mode 100644 arch/arm/mach-ux500/include/mach/hardware.h

diff --git a/arch/arm/mach-ux500/board-mop500-audio.c b/arch/arm/mach-ux500/board-mop500-audio.c
index 43bbee1..96e62ef 100644
--- a/arch/arm/mach-ux500/board-mop500-audio.c
+++ b/arch/arm/mach-ux500/board-mop500-audio.c
@@ -11,7 +11,6 @@
 #include <linux/platform_data/dma-ste-dma40.h>
 
 #include <mach/devices.h>
-#include <mach/hardware.h>
 #include <mach/irqs.h>
 #include <linux/platform_data/asoc-ux500-msp.h>
 
diff --git a/arch/arm/mach-ux500/board-mop500-pins.c b/arch/arm/mach-ux500/board-mop500-pins.c
index 0a3f30d..f3976f9 100644
--- a/arch/arm/mach-ux500/board-mop500-pins.c
+++ b/arch/arm/mach-ux500/board-mop500-pins.c
@@ -13,8 +13,6 @@
 
 #include <asm/mach-types.h>
 
-#include <mach/hardware.h>
-
 #include "pins-db8500.h"
 #include "board-mop500.h"
 
diff --git a/arch/arm/mach-ux500/board-mop500-sdi.c b/arch/arm/mach-ux500/board-mop500-sdi.c
index 051b62c..0ada767 100644
--- a/arch/arm/mach-ux500/board-mop500-sdi.c
+++ b/arch/arm/mach-ux500/board-mop500-sdi.c
@@ -15,8 +15,8 @@
 
 #include <asm/mach-types.h>
 #include <mach/devices.h>
-#include <mach/hardware.h>
 
+#include "db8500-regs.h"
 #include "devices-db8500.h"
 #include "board-mop500.h"
 #include "ste-dma40-db8500.h"
diff --git a/arch/arm/mach-ux500/board-mop500-uib.c b/arch/arm/mach-ux500/board-mop500-uib.c
index 7037d36..bdaa422 100644
--- a/arch/arm/mach-ux500/board-mop500-uib.c
+++ b/arch/arm/mach-ux500/board-mop500-uib.c
@@ -11,7 +11,6 @@
 #include <linux/init.h>
 #include <linux/i2c.h>
 
-#include <mach/hardware.h>
 #include "board-mop500.h"
 #include "id.h"
 
diff --git a/arch/arm/mach-ux500/board-mop500.c b/arch/arm/mach-ux500/board-mop500.c
index b034578..caad80e 100644
--- a/arch/arm/mach-ux500/board-mop500.c
+++ b/arch/arm/mach-ux500/board-mop500.c
@@ -41,13 +41,13 @@
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
 
-#include <mach/hardware.h>
 #include <mach/setup.h>
 #include <mach/devices.h>
 #include <mach/irqs.h>
 #include <linux/platform_data/crypto-ux500.h>
 
 #include "ste-dma40-db8500.h"
+#include "db8500-regs.h"
 #include "devices-db8500.h"
 #include "board-mop500.h"
 #include "board-mop500-regulators.h"
diff --git a/arch/arm/mach-ux500/cache-l2x0.c b/arch/arm/mach-ux500/cache-l2x0.c
index 1c1609d..e12cc92 100644
--- a/arch/arm/mach-ux500/cache-l2x0.c
+++ b/arch/arm/mach-ux500/cache-l2x0.c
@@ -9,8 +9,8 @@
 
 #include <asm/cacheflush.h>
 #include <asm/hardware/cache-l2x0.h>
-#include <mach/hardware.h>
 
+#include "db8500-regs.h"
 #include "id.h"
 
 static void __iomem *l2x0_base;
diff --git a/arch/arm/mach-ux500/cpu-db8500.c b/arch/arm/mach-ux500/cpu-db8500.c
index 8c58dff..d726c06 100644
--- a/arch/arm/mach-ux500/cpu-db8500.c
+++ b/arch/arm/mach-ux500/cpu-db8500.c
@@ -28,15 +28,13 @@
 #include <asm/mach/map.h>
 #include <asm/mach/arch.h>
 
-#include <mach/hardware.h>
 #include <mach/setup.h>
 #include <mach/devices.h>
-#include <mach/db8500-regs.h>
 #include <mach/irqs.h>
 
 #include "devices-db8500.h"
 #include "ste-dma40-db8500.h"
-
+#include "db8500-regs.h"
 #include "board-mop500.h"
 #include "id.h"
 
diff --git a/arch/arm/mach-ux500/cpu.c b/arch/arm/mach-ux500/cpu.c
index ee69439d..aa14c5f 100644
--- a/arch/arm/mach-ux500/cpu.c
+++ b/arch/arm/mach-ux500/cpu.c
@@ -24,11 +24,11 @@
 
 #include <asm/mach/map.h>
 
-#include <mach/hardware.h>
 #include <mach/setup.h>
 #include <mach/devices.h>
 
 #include "board-mop500.h"
+#include "db8500-regs.h"
 #include "id.h"
 
 /*
diff --git a/arch/arm/mach-ux500/cpuidle.c b/arch/arm/mach-ux500/cpuidle.c
index 1e5bb66..654115a 100644
--- a/arch/arm/mach-ux500/cpuidle.c
+++ b/arch/arm/mach-ux500/cpuidle.c
@@ -21,6 +21,8 @@
 #include <asm/cpuidle.h>
 #include <asm/proc-fns.h>
 
+#include "db8500-regs.h"
+
 static atomic_t master = ATOMIC_INIT(0);
 static DEFINE_SPINLOCK(master_lock);
 static DEFINE_PER_CPU(struct cpuidle_device, ux500_cpuidle_device);
diff --git a/arch/arm/mach-ux500/include/mach/db8500-regs.h b/arch/arm/mach-ux500/db8500-regs.h
similarity index 88%
rename from arch/arm/mach-ux500/include/mach/db8500-regs.h
rename to arch/arm/mach-ux500/db8500-regs.h
index 1530d49..b2d7a0b 100644
--- a/arch/arm/mach-ux500/include/mach/db8500-regs.h
+++ b/arch/arm/mach-ux500/db8500-regs.h
@@ -170,4 +170,32 @@
 /* SoC identification number information */
 #define U8500_BB_UID_BASE      (U8500_BACKUPRAM1_BASE + 0xFC0)
 
+/* Offsets to specific addresses in some IP blocks for DMA */
+#define MSP_TX_RX_REG_OFFSET	0
+#define CRYP1_RX_REG_OFFSET	0x10
+#define CRYP1_TX_REG_OFFSET	0x8
+#define HASH1_TX_REG_OFFSET	0x4
+
+/*
+ * Macros to get at IO space when running virtually
+ * We dont map all the peripherals, let ioremap do
+ * this for us. We map only very basic peripherals here.
+ */
+#define U8500_IO_VIRTUAL	0xf0000000
+#define U8500_IO_PHYSICAL	0xa0000000
+/* This is where we map in the ROM to check ASIC IDs */
+#define UX500_VIRT_ROM		0xf0000000
+
+/* This macro is used in assembly, so no cast */
+#define IO_ADDRESS(x)           \
+	(((x) & 0x0fffffff) + (((x) >> 4) & 0x0f000000) + U8500_IO_VIRTUAL)
+
+/* typesafe io address */
+#define __io_address(n)		IOMEM(IO_ADDRESS(n))
+
+/* Used by some plat-nomadik code */
+#define io_p2v(n)		__io_address(n)
+
+#define ARRAY_AND_SIZE(x)	(x), ARRAY_SIZE(x)
+
 #endif
diff --git a/arch/arm/mach-ux500/devices-common.c b/arch/arm/mach-ux500/devices-common.c
index 16b5f71..94868b7 100644
--- a/arch/arm/mach-ux500/devices-common.c
+++ b/arch/arm/mach-ux500/devices-common.c
@@ -13,7 +13,6 @@
 #include <linux/platform_device.h>
 #include <linux/platform_data/pinctrl-nomadik.h>
 
-#include <mach/hardware.h>
 #include <mach/irqs.h>
 
 #include "devices-common.h"
diff --git a/arch/arm/mach-ux500/devices-db8500.c b/arch/arm/mach-ux500/devices-db8500.c
index f3d9419..38467bf 100644
--- a/arch/arm/mach-ux500/devices-db8500.c
+++ b/arch/arm/mach-ux500/devices-db8500.c
@@ -15,10 +15,10 @@
 #include <linux/platform_data/dma-ste-dma40.h>
 #include <linux/mfd/dbx500-prcmu.h>
 
-#include <mach/hardware.h>
 #include <mach/setup.h>
 #include <mach/irqs.h>
 
+#include "db8500-regs.h"
 #include "devices-db8500.h"
 #include "ste-dma40-db8500.h"
 
diff --git a/arch/arm/mach-ux500/devices-db8500.h b/arch/arm/mach-ux500/devices-db8500.h
index dbcb35c..c9db210 100644
--- a/arch/arm/mach-ux500/devices-db8500.h
+++ b/arch/arm/mach-ux500/devices-db8500.h
@@ -10,6 +10,7 @@
 
 #include <linux/platform_data/usb-musb-ux500.h>
 #include <mach/irqs.h>
+#include "db8500-regs.h"
 #include "devices-common.h"
 
 struct ske_keypad_platform_data;
diff --git a/arch/arm/mach-ux500/devices.c b/arch/arm/mach-ux500/devices.c
index ea0a2f9..f63a512 100644
--- a/arch/arm/mach-ux500/devices.c
+++ b/arch/arm/mach-ux500/devices.c
@@ -11,9 +11,10 @@
 #include <linux/io.h>
 #include <linux/amba/bus.h>
 
-#include <mach/hardware.h>
 #include <mach/setup.h>
 
+#include "db8500-regs.h"
+
 void __init amba_add_devices(struct amba_device *devs[], int num)
 {
 	int i;
diff --git a/arch/arm/mach-ux500/id.c b/arch/arm/mach-ux500/id.c
index 9f95184..a847cf2 100644
--- a/arch/arm/mach-ux500/id.c
+++ b/arch/arm/mach-ux500/id.c
@@ -14,9 +14,9 @@
 #include <asm/cacheflush.h>
 #include <asm/mach/map.h>
 
-#include <mach/hardware.h>
 #include <mach/setup.h>
 
+#include "db8500-regs.h"
 #include "id.h"
 
 struct dbx500_asic_id dbx500_id;
diff --git a/arch/arm/mach-ux500/include/mach/hardware.h b/arch/arm/mach-ux500/include/mach/hardware.h
deleted file mode 100644
index 4eece2a..0000000
--- a/arch/arm/mach-ux500/include/mach/hardware.h
+++ /dev/null
@@ -1,45 +0,0 @@
-/*
- * Copyright (C) 2009 ST-Ericsson.
- *
- * U8500 hardware definitions
- *
- * 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.
- */
-#ifndef __MACH_HARDWARE_H
-#define __MACH_HARDWARE_H
-
-/*
- * Macros to get at IO space when running virtually
- * We dont map all the peripherals, let ioremap do
- * this for us. We map only very basic peripherals here.
- */
-#define U8500_IO_VIRTUAL	0xf0000000
-#define U8500_IO_PHYSICAL	0xa0000000
-/* This is where we map in the ROM to check ASIC IDs */
-#define UX500_VIRT_ROM		0xf0000000
-
-/* This macro is used in assembly, so no cast */
-#define IO_ADDRESS(x)           \
-	(((x) & 0x0fffffff) + (((x) >> 4) & 0x0f000000) + U8500_IO_VIRTUAL)
-
-/* typesafe io address */
-#define __io_address(n)		IOMEM(IO_ADDRESS(n))
-
-/* Used by some plat-nomadik code */
-#define io_p2v(n)		__io_address(n)
-
-#include <mach/db8500-regs.h>
-
-#define MSP_TX_RX_REG_OFFSET	0
-#define CRYP1_RX_REG_OFFSET	0x10
-#define CRYP1_TX_REG_OFFSET	0x8
-#define HASH1_TX_REG_OFFSET	0x4
-
-#ifndef __ASSEMBLY__
-
-#define ARRAY_AND_SIZE(x)	(x), ARRAY_SIZE(x)
-
-#endif				/* __ASSEMBLY__ */
-#endif				/* __MACH_HARDWARE_H */
diff --git a/arch/arm/mach-ux500/include/mach/irqs.h b/arch/arm/mach-ux500/include/mach/irqs.h
index fc77b42..829947d 100644
--- a/arch/arm/mach-ux500/include/mach/irqs.h
+++ b/arch/arm/mach-ux500/include/mach/irqs.h
@@ -10,8 +10,6 @@
 #ifndef ASM_ARCH_IRQS_H
 #define ASM_ARCH_IRQS_H
 
-#include <mach/hardware.h>
-
 #define IRQ_LOCALTIMER			29
 #define IRQ_LOCALWDOG			30
 
diff --git a/arch/arm/mach-ux500/include/mach/uncompress.h b/arch/arm/mach-ux500/include/mach/uncompress.h
index 36969d5..533a004 100644
--- a/arch/arm/mach-ux500/include/mach/uncompress.h
+++ b/arch/arm/mach-ux500/include/mach/uncompress.h
@@ -22,7 +22,8 @@
 #include <asm/mach-types.h>
 #include <linux/io.h>
 #include <linux/amba/serial.h>
-#include <mach/hardware.h>
+/* TODO: This goes away in multiplatform boot, this file gets deleted */
+#include "../../db8500-regs.h"
 
 void __iomem *ux500_uart_base;
 
diff --git a/arch/arm/mach-ux500/platsmp.c b/arch/arm/mach-ux500/platsmp.c
index 18f7af3..8a9c070 100644
--- a/arch/arm/mach-ux500/platsmp.c
+++ b/arch/arm/mach-ux500/platsmp.c
@@ -22,9 +22,9 @@
 #include <asm/smp_plat.h>
 #include <asm/smp_scu.h>
 
-#include <mach/hardware.h>
 #include <mach/setup.h>
 
+#include "db8500-regs.h"
 #include "id.h"
 
 /* This is called from headsmp.S to wakeup the secondary core */
diff --git a/arch/arm/mach-ux500/pm.c b/arch/arm/mach-ux500/pm.c
index 6949a13..1a468f0 100644
--- a/arch/arm/mach-ux500/pm.c
+++ b/arch/arm/mach-ux500/pm.c
@@ -13,7 +13,7 @@
 #include <linux/io.h>
 #include <linux/platform_data/arm-ux500-pm.h>
 
-#include <mach/hardware.h>
+#include "db8500-regs.h"
 
 /* ARM WFI Standby signal register */
 #define PRCM_ARM_WFI_STANDBY    (prcmu_base + 0x130)
diff --git a/arch/arm/mach-ux500/timer.c b/arch/arm/mach-ux500/timer.c
index a6af0b8..5b91fac 100644
--- a/arch/arm/mach-ux500/timer.c
+++ b/arch/arm/mach-ux500/timer.c
@@ -14,9 +14,9 @@
 #include <asm/smp_twd.h>
 
 #include <mach/setup.h>
-#include <mach/hardware.h>
 #include <mach/irqs.h>
 
+#include "db8500-regs.h"
 #include "id.h"
 
 #ifdef CONFIG_HAVE_ARM_TWD
diff --git a/arch/arm/mach-ux500/usb.c b/arch/arm/mach-ux500/usb.c
index 78ac65f..2dfc72f 100644
--- a/arch/arm/mach-ux500/usb.c
+++ b/arch/arm/mach-ux500/usb.c
@@ -10,7 +10,7 @@
 #include <linux/platform_data/usb-musb-ux500.h>
 #include <linux/platform_data/dma-ste-dma40.h>
 
-#include <mach/hardware.h>
+#include "db8500-regs.h"
 
 #define MUSB_DMA40_RX_CH { \
 		.mode = STEDMA40_MODE_LOGICAL, \
diff --git a/drivers/clk/ux500/clk-prcc.c b/drivers/clk/ux500/clk-prcc.c
index 7eee7f7..bd4769a 100644
--- a/drivers/clk/ux500/clk-prcc.c
+++ b/drivers/clk/ux500/clk-prcc.c
@@ -13,7 +13,6 @@
 #include <linux/io.h>
 #include <linux/err.h>
 #include <linux/types.h>
-#include <mach/hardware.h>
 
 #include "clk.h"
 
diff --git a/drivers/clocksource/clksrc-dbx500-prcmu.c b/drivers/clocksource/clksrc-dbx500-prcmu.c
index c26c369..4f34093 100644
--- a/drivers/clocksource/clksrc-dbx500-prcmu.c
+++ b/drivers/clocksource/clksrc-dbx500-prcmu.c
@@ -18,7 +18,6 @@
 #include <asm/sched_clock.h>
 
 #include <mach/setup.h>
-#include <mach/hardware.h>
 
 #define RATE_32K		32768
 
diff --git a/drivers/crypto/ux500/cryp/cryp.c b/drivers/crypto/ux500/cryp/cryp.c
index e208cea..3eafa90 100644
--- a/drivers/crypto/ux500/cryp/cryp.c
+++ b/drivers/crypto/ux500/cryp/cryp.c
@@ -12,8 +12,6 @@
 #include <linux/kernel.h>
 #include <linux/types.h>
 
-#include <mach/hardware.h>
-
 #include "cryp_p.h"
 #include "cryp.h"
 
diff --git a/drivers/crypto/ux500/cryp/cryp_core.c b/drivers/crypto/ux500/cryp/cryp_core.c
index 8bc5fef..2809b19 100644
--- a/drivers/crypto/ux500/cryp/cryp_core.c
+++ b/drivers/crypto/ux500/cryp/cryp_core.c
@@ -32,7 +32,6 @@
 #include <crypto/scatterwalk.h>
 
 #include <linux/platform_data/crypto-ux500.h>
-#include <mach/hardware.h>
 
 #include "cryp_p.h"
 #include "cryp.h"
diff --git a/drivers/crypto/ux500/hash/hash_core.c b/drivers/crypto/ux500/hash/hash_core.c
index 632c333..1827e9f 100644
--- a/drivers/crypto/ux500/hash/hash_core.c
+++ b/drivers/crypto/ux500/hash/hash_core.c
@@ -32,7 +32,6 @@
 #include <crypto/algapi.h>
 
 #include <linux/platform_data/crypto-ux500.h>
-#include <mach/hardware.h>
 
 #include "hash_alg.h"
 
diff --git a/drivers/mfd/db8500-prcmu.c b/drivers/mfd/db8500-prcmu.c
index 2d3a5f6..03e2aed 100644
--- a/drivers/mfd/db8500-prcmu.c
+++ b/drivers/mfd/db8500-prcmu.c
@@ -33,9 +33,7 @@
 #include <linux/regulator/machine.h>
 #include <linux/cpufreq.h>
 #include <linux/platform_data/ux500_wdt.h>
-#include <mach/hardware.h>
 #include <mach/irqs.h>
-#include <mach/db8500-regs.h>
 #include "dbx500-prcmu-regs.h"
 
 /* Index of different voltages to be used when accessing AVSData */
diff --git a/drivers/mfd/dbx500-prcmu-regs.h b/drivers/mfd/dbx500-prcmu-regs.h
index 439254d..d14836e 100644
--- a/drivers/mfd/dbx500-prcmu-regs.h
+++ b/drivers/mfd/dbx500-prcmu-regs.h
@@ -74,33 +74,11 @@
 #define PRCM_A9PL_FORCE_CLKEN_PRCM_A9PL_FORCE_CLKEN BIT(0)
 #define PRCM_A9PL_FORCE_CLKEN_PRCM_A9AXI_FORCE_CLKEN BIT(1)
 
-/* ARM WFI Standby signal register */
-#define PRCM_ARM_WFI_STANDBY    (prcmu_base + 0x130)
-#define PRCM_ARM_WFI_STANDBY_WFI0               0x08
-#define PRCM_ARM_WFI_STANDBY_WFI1               0x10
-#define PRCM_IOCR		(prcmu_base + 0x310)
-#define PRCM_IOCR_IOFORCE			0x1
-
 /* CPU mailbox registers */
 #define PRCM_MBOX_CPU_VAL	(prcmu_base + 0x0fc)
 #define PRCM_MBOX_CPU_SET	(prcmu_base + 0x100)
 #define PRCM_MBOX_CPU_CLR	(prcmu_base + 0x104)
 
-/* Dual A9 core interrupt management unit registers */
-#define PRCM_A9_MASK_REQ	(prcmu_base + 0x328)
-#define PRCM_A9_MASK_REQ_PRCM_A9_MASK_REQ	0x1
-
-#define PRCM_A9_MASK_ACK	(prcmu_base + 0x32c)
-#define PRCM_ARMITMSK31TO0	(prcmu_base + 0x11c)
-#define PRCM_ARMITMSK63TO32	(prcmu_base + 0x120)
-#define PRCM_ARMITMSK95TO64	(prcmu_base + 0x124)
-#define PRCM_ARMITMSK127TO96	(prcmu_base + 0x128)
-#define PRCM_POWER_STATE_VAL	(prcmu_base + 0x25C)
-#define PRCM_ARMITVAL31TO0	(prcmu_base + 0x260)
-#define PRCM_ARMITVAL63TO32	(prcmu_base + 0x264)
-#define PRCM_ARMITVAL95TO64	(prcmu_base + 0x268)
-#define PRCM_ARMITVAL127TO96	(prcmu_base + 0x26C)
-
 #define PRCM_HOSTACCESS_REQ	(prcmu_base + 0x334)
 #define PRCM_HOSTACCESS_REQ_HOSTACCESS_REQ 0x1
 #define PRCM_HOSTACCESS_REQ_WAKE_REQ	BIT(16)
diff --git a/sound/soc/ux500/mop500_ab8500.c b/sound/soc/ux500/mop500_ab8500.c
index 78cce23..892ad9a 100644
--- a/sound/soc/ux500/mop500_ab8500.c
+++ b/sound/soc/ux500/mop500_ab8500.c
@@ -17,8 +17,6 @@
 #include <linux/io.h>
 #include <linux/clk.h>
 
-#include <mach/hardware.h>
-
 #include <sound/soc.h>
 #include <sound/soc-dapm.h>
 #include <sound/pcm.h>
diff --git a/sound/soc/ux500/ux500_msp_dai.c b/sound/soc/ux500/ux500_msp_dai.c
index 0d9713e..54028cf 100644
--- a/sound/soc/ux500/ux500_msp_dai.c
+++ b/sound/soc/ux500/ux500_msp_dai.c
@@ -21,8 +21,6 @@
 #include <linux/mfd/dbx500-prcmu.h>
 #include <linux/platform_data/asoc-ux500-msp.h>
 
-#include <mach/hardware.h>
-
 #include <sound/soc.h>
 #include <sound/soc-dai.h>
 
diff --git a/sound/soc/ux500/ux500_msp_i2s.c b/sound/soc/ux500/ux500_msp_i2s.c
index a582007..f2db6c9 100644
--- a/sound/soc/ux500/ux500_msp_i2s.c
+++ b/sound/soc/ux500/ux500_msp_i2s.c
@@ -22,8 +22,6 @@
 #include <linux/of.h>
 #include <linux/platform_data/asoc-ux500-msp.h>
 
-#include <mach/hardware.h>
-
 #include <sound/soc.h>
 
 #include "ux500_msp_i2s.h"
-- 
1.7.11.3



From balbi at ti.com  Fri Apr  5 10:29:44 2013
From: balbi at ti.com (Felipe Balbi)
Date: Fri, 5 Apr 2013 17:29:44 +0300
Subject: [PATCH v3 1/4] ARM: OMAP4+: PM: Consolidate MPU subsystem PM
 code for re-use
In-Reply-To: <20130405141801.GA4270@kahuna>
References: <1365166743-5940-1-git-send-email-santosh.shilimkar@ti.com>
 <1365166743-5940-2-git-send-email-santosh.shilimkar@ti.com>
 <20130405131935.GM11464@arwen.pp.htv.fi>
 <20130405133511.GA4143@kahuna>
 <20130405140420.GB12229@arwen.pp.htv.fi>
 <20130405141801.GA4270@kahuna>
Message-ID: <20130405142944.GC12229@arwen.pp.htv.fi>

On Fri, Apr 05, 2013 at 09:18:02AM -0500, Nishanth Menon wrote:
> On 17:04-20130405, Felipe Balbi wrote:
> > Hi,
> > 
> > On Fri, Apr 05, 2013 at 08:35:11AM -0500, Nishanth Menon wrote:
> > > On 16:19-20130405, Felipe Balbi wrote:
> > > > On Fri, Apr 05, 2013 at 06:29:00PM +0530, Santosh Shilimkar wrote:
> > > > > OMAP5 and future OMAP based SOCs has backward compatible MPUSS
> > > > > IP block with OMAP4. It's programming model is mostly similar.
> > > > 
> > > > s/It's/Its/
> > > > s/mostly //
> > > > 
> > > > (similar already expands to 'almost the same' :-)
> > > > 
> > > > > @@ -355,6 +389,12 @@ int __init omap4_mpuss_init(void)
> > > > >  
> > > > >  	save_l2x0_context();
> > > > >  
> > > > > +	if (cpu_is_omap44xx()) {
> > > > > +		omap_pm_ops.finish_suspend = omap4_finish_suspend;
> > > > > +		omap_pm_ops.resume = omap4_cpu_resume;
> > > > > +		omap_pm_ops.scu_prepare = scu_pwrst_prepare;
> > > > > +	}
> > > > 
> > > > why don't you just rename omap4_* into omap_* and add cpu-based checks
> > > > there in order to handle differences between omap4 and omap5?
> > > > 
> > > > If implementation will be almost the same for both, you might be able to
> > > > save on some more duplication, no ?
> > > Jeez NO! finish_suspend is assembly, further, it is the hottest path in
> > > cpuidle framework - for every WFI we invoke it. we definitely dont want
> > > to add more overhead beyond what is necessary.
> > 
> > alright, settle down ;-) whoever suggested that isn't here anymore
> hehe, Apologies, I was'nt that stressed as the wording might have
> indicated.. We spend tons of time evaluating with Lauterbach tracing to
> weed out hot paths - folks who have been bitten by these tend to feel a
> little defensive I guess and to have surprise regressions are painful to
> find and fix - esp when around not-so-obvious paths ;)

understood ;-)

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130405/a00aa6ff/attachment.sig>

From arnd at arndb.de  Fri Apr  5 10:36:56 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 5 Apr 2013 16:36:56 +0200
Subject: mvebu-mbus: defining a DT binding
In-Reply-To: <20130405155149.0b00a592@skate>
References: <20130405150200.7b6dee63@skate> <201304051517.26838.arnd@arndb.de>
 <20130405155149.0b00a592@skate>
Message-ID: <201304051636.56410.arnd@arndb.de>

On Friday 05 April 2013, Thomas Petazzoni wrote:
> On Fri, 5 Apr 2013 15:17:26 +0200, Arnd Bergmann wrote:
> > On Friday 05 April 2013, Thomas Petazzoni wrote:
> > I don't have a good solution. Maybe we can work around this with the
> > new preprocessor support by letting the board file provide a macro
> > with the actual size?
> 
> The thing is that we don't know how many NOR, FPGA and other device-bus
> devices the board will use. So you mean we should define a size of 0 by
> default (in which case no window would be created), and if a board
> overrides that with a non-zero value, then we would use that one?
> 
> I don't find the solution of using pre-processor magic to do that very
> pretty. The 'inheritance' property of the DT normally solves that
> nicely... but since we're encoding everything with ranges, it doesn't
> work very well.

Right.

> Maybe the 'ranges' property should not contain any static window
> definition at all, and instead some other DT properties would define
> the windows, and the 'ranges' property would be reconstructed by the
> mbus driver at initialization time? I admit I would really prefer if
> windows were described by name ("pcie0.0", "devbus-cs0", "bootrom")
> instead of by encoding the target/attribute values in the DT. This
> would make the DT a lot easier to read, understand and modify by people
> porting the kernel to new boards. But using a name is not possible in
> the 'ranges' property.

Yes, that is unfortunately something we cannot change any more.
Setting up a minimum number of windows from a different property
would be possible, but I don't see a strong reason to do that
instead of using the ranges property for it.

> > Another option would be to not map them by default but let the
> > mbus driver do as many mappings as possible at boot time based
> > on the devices that are actually present as children of the mbus
> > device and not marked as status="disabled".
> 
> So the 'ranges' property would be more or less empty? How would the
> mbus driver know the target/attribute values for each window?

I think ideally the ranges property would be completely empty
(absent actually, but that is a detail) at boot, and the mbus driver
would fill the ranges property as needed. I can see two ways to
do that:

a) The mbus driver does a for_each_child_of_node() loop to iterate
through its children and allocates a new physical address for each
"reg" property it finds on all devices that are not status="disabled".
Since the windows are all power-of-two pages in size, a simple
"first-fit" algorith should be just fine here. The definition of 
the mbus address space guarantees that the "reg" property has
all the information needed to do that mapping.

b) We explicitly make all devices under mbus aware of the fact that
they they are on mbus, and export a function that they have to call
to map the window, like

	phys_addr_t mbus_map_reg(struct device_node *dn, int index);

The mbus driver then allocates a free physical address (as in a)) and
maps the window based on the address referred to by the reg property.

We can add a convenience function that combines this with request_resource
and ioremap for drivers that would do those anyway.

> > Do you know which children of the mbus node (if any) we actually
> > need to access before initializing mbus?
> 
> I'm sorry but I don't understand this question. There's nothing to do
> to 'initialize mbus'. We can add/remove address decoding windows
> whenever we want.

Well, we have to set up the windows at one point during the boot process,
and we cannot access anything behind the windows until they are set up.

So if for instance the UART we use for DEBUG_LL is behind an MBUS window,
we cannot easily change its address. My question is which devices fall
into this category, if any.

> > >  * I am not sure to understand why the nand, crypto and pcie-controller
> > >    nodes are outside of the internal registers. Well, I understand it's
> > >    because those devices need a special address decoding window. But it
> > >    sounds strange because those devices also have internal registers
> > >    (which is why Jason used 'MAPDEF_INTERNAL + offset' in the reg
> > >    property).
> > > 
> > >    Is this really the desired DT binding?
> > 
> > I don't understant what "internal registers" mean in this context.
> 
> On Marvell HW, the physical address space is split in multiple windows:
> PCIe memory, PCIe I/O, mapping of NOR, mapping of FPGA, special
> memories like crypto-engine SRAM, etc. One very special window is
> called the 'internal registers window'. It is set up by the bootloader,
> and contains all the registers for all the devices: UART, PCIe
> interfaces, USB, SDIO, Ethernet, everything. All the 0xd00yyyyy
> addresses in the current Armada 370/XP .dts(i) are part of the internal
> registers window.

Ok, I see. Two follow-up questions:

Does the internal registers window contain the MMIO space of the mbus
device as well?

Do you expect that we always need just one window to map all the internal
registers, or would there be a reason to split it up into multiple windows
to reduce the amount of physical address space consumed?

> > I think it would be much nicer to express the specific mbus target using
> > the ranges properties of the device nodes in PCI. Maybe I'm missing what
> > the problem is here. 
> 
> Hum, this has already been discussed when doing the PCIe driver.
> 
> Basically it's not possible because the target/attribute values are per
> PCIe interface, while the ranges we need to PCIe are *global*. Since we
> don't know how much memory and I/O each PCIe interface will need, we
> can't provision the right windows statically in the DT. The windows are
> created dynamically by the PCIe driver depending on what gets
> enumerated on the downstream bus.
> 
> So in the DT we have *one* global range for PCIe memory and *one* global
> range for PCIe I/O.
> 
> But then, the PCIe driver needs to know for *each* PCIe interface what
> is the right target/attribute tuple to create a memory or I/O window
> for that particular interface.
> 
> Does that make sense?

I don't get it yet. I would assume that each PCIe port maps exactly to
one address window, which solves the problem you describe above very
nicely. We can do away with the fake "one range for memory" concept
and just let the mbus driver pick any physical address when we enable
or hot-plug one of the ports.

> > > I already have some basic code in the mvebu-mbus driver that parses the
> > > ranges = <...> property and creates the corresponding windows, it seems
> > > to work fine.
> > 
> > Ok, nice! So I guess the next step is to dynamically insert additional
> > ranges for devices that are only mapped at run time, right?
> 
> What would be the need of this? Nobody will ever read the 'ranges'
> property again at runtime, so why bother? Of course, if you need it for
> good DT-compliance, I'll do it, but I don't see the point of having
> kernel code to update a data structure that will never be read again by
> anybody else.

The ranges properties are required so a device driver can call of_iomap().
Without it, there is no way to convert an address in mbus space into a
CPU phys_addr_t.

	Arnd


From aletes.xgr at gmail.com  Fri Apr  5 10:53:47 2013
From: aletes.xgr at gmail.com (Alexandre Pereira da Silva)
Date: Fri, 5 Apr 2013 11:53:47 -0300
Subject: [PATCH] ARM: dts: imx23-olinuxino: Set the sdcard as non-removable
In-Reply-To: <201304051611.15003.marex@denx.de>
References: <1365135413-31493-1-git-send-email-aletes.xgr@gmail.com>
 <20130405091656.GD2667@S2101-09.ap.freescale.net>
 <201304051611.15003.marex@denx.de>
Message-ID: <CAAAP30FMObPdRg60eNov3FKRvycVrBxV-9DCu05Pb4Fx__H8Qw@mail.gmail.com>

On Fri, Apr 5, 2013 at 11:11 AM, Marek Vasut <marex at denx.de> wrote:
> The CD line is working perfectly well on this board, so I don't get it.

In the schematics of this board, the SSP1_DETECT pin is connected to
the green led. As I see, there is no way, the hardware can detect card
removal. Am I missing something here?


From thomas.petazzoni at free-electrons.com  Fri Apr  5 10:59:54 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Fri, 5 Apr 2013 16:59:54 +0200
Subject: [PATCHv7 07/17] clk: mvebu: add more PCIe clocks for Armada XP
In-Reply-To: <1364395234-11195-8-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1364395234-11195-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1364395234-11195-8-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <20130405165954.03e08f1a@skate>

Mike,

Could we have your opinion on the below patch, and possibly an Acked-by
to carry it through the arm-soc tree?

Thanks,

Thomas

On Wed, 27 Mar 2013 15:40:24 +0100, Thomas Petazzoni wrote:
> The current revision of the datasheet only mentions the gatable clocks
> for the PCIe 0.0, 0.1, 0.2 and 0.3 interfaces, and forgot to mention
> the ones for the PCIe 1.0, 1.1, 1.2, 1.3, 2.0 and 3.0
> interfaces. After confirmation with Marvell engineers, this patch adds
> the missing gatable clocks for those PCIe interfaces.
> 
> It also changes the name of the previously existing PCIe gatable
> clocks, in order to match the naming using the datasheets.
> 
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> ---
>  drivers/clk/mvebu/clk-gating-ctrl.c |   14 ++++++++++----
>  1 file changed, 10 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/clk/mvebu/clk-gating-ctrl.c b/drivers/clk/mvebu/clk-gating-ctrl.c
> index b35785a..2f03723 100644
> --- a/drivers/clk/mvebu/clk-gating-ctrl.c
> +++ b/drivers/clk/mvebu/clk-gating-ctrl.c
> @@ -137,10 +137,14 @@ static const struct mvebu_soc_descr __initconst armada_xp_gating_descr[] = {
>  	{ "ge2", NULL,  2 },
>  	{ "ge1", NULL, 3 },
>  	{ "ge0", NULL, 4 },
> -	{ "pex0", NULL, 5 },
> -	{ "pex1", NULL, 6 },
> -	{ "pex2", NULL, 7 },
> -	{ "pex3", NULL, 8 },
> +	{ "pex00", NULL, 5 },
> +	{ "pex01", NULL, 6 },
> +	{ "pex02", NULL, 7 },
> +	{ "pex03", NULL, 8 },
> +	{ "pex10", NULL, 9 },
> +	{ "pex11", NULL, 10 },
> +	{ "pex12", NULL, 11 },
> +	{ "pex13", NULL, 12 },
>  	{ "bp", NULL, 13 },
>  	{ "sata0lnk", NULL, 14 },
>  	{ "sata0", "sata0lnk", 15 },
> @@ -152,6 +156,8 @@ static const struct mvebu_soc_descr __initconst armada_xp_gating_descr[] = {
>  	{ "xor0", NULL, 22 },
>  	{ "crypto", NULL, 23 },
>  	{ "tdm", NULL, 25 },
> +	{ "pex20", NULL, 26 },
> +	{ "pex30", NULL, 27 },
>  	{ "xor1", NULL, 28 },
>  	{ "sata1lnk", NULL, 29 },
>  	{ "sata1", "sata1lnk", 30 },



-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From arnd at arndb.de  Fri Apr  5 11:13:54 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 5 Apr 2013 17:13:54 +0200
Subject: [PATCH 00/14] Ux500 multiplatform v2
In-Reply-To: <1365171776-8463-1-git-send-email-linus.walleij@stericsson.com>
References: <1365171776-8463-1-git-send-email-linus.walleij@stericsson.com>
Message-ID: <201304051713.54233.arnd@arndb.de>

On Friday 05 April 2013, Linus Walleij wrote:
> From: Linus Walleij <linus.walleij at linaro.org>
> 
> This is the complete Ux500 multiplatform patchset.
> 
> The only thing missing is a few ACKs from the MFD
> maintainer (Samuel Ortiz).

Ok, very nice!

I'd like to put them into arm-soc really soon to give it some
more time in linux-next before the merge window, but I don't
want to step on Sam's toes here.

Sam, can you send an ACK or NAK by Monday? If I don't hear back
from you, I'll put it into arm-soc as is, and we'll have to address
any further comments with add-on patches.

	Arnd


From gregkh at linuxfoundation.org  Fri Apr  5 11:35:47 2013
From: gregkh at linuxfoundation.org (Greg KH)
Date: Fri, 5 Apr 2013 08:35:47 -0700
Subject: [PATCH] Revert "drivers/rtc/rtc-at91rm9200.c: use a variable for
 storing IMR"
In-Reply-To: <515EDC4B.3010508@atmel.com>
References: <20130403095150.GC27600@localhost>
 <1364982862-19759-1-git-send-email-jhovold@gmail.com>
 <515C0208.2000605@atmel.com> <515EDC4B.3010508@atmel.com>
Message-ID: <20130405153547.GA515@kroah.com>

On Fri, Apr 05, 2013 at 04:14:35PM +0200, Nicolas Ferre wrote:
> On 04/03/2013 12:18 PM, Nicolas Ferre :
> > On 04/03/2013 11:54 AM, Johan Hovold :
> >> This reverts commit 0ef1594c017521ea89278e80fe3f80dafb17abde.
> >>
> >> This patch introduced a few races which cannot be easily fixed with a
> >> small follow-up patch. Furthermore, the SoC with the broken hardware
> >> register, which this patch intended to add support for, can only be used
> >> with device trees, which this driver currently does not support.
> >>
> >> Cc: stable <stable at vger.kernel.org>
> >> Signed-off-by: Johan Hovold <jhovold at gmail.com>
> > 
> > Fair enough, after fighting to find a solution that can makes us move
> > forward... your strong arguments convinced me.
> > 
> > So, Andrew, please can you take this "revert" patch for 3.9-rc ?
> > And sorry for the noise.
> > 
> > Acked-by: Nicolas Ferre <nicolas.ferre at atmel.com>
> > 
> > (Andrew, I figured out that you are not in copy of the original email:
> > do I need to send it back to you or can you pick it up in patchwork?
> > https://patchwork.kernel.org/patch/2385921/
> > )
> 
> Andrew, ping?

Andrew is on vacation for a few weeks, sorry.

Perhaps you should send this yourself?

greg k-h


From tony at atomide.com  Fri Apr  5 11:43:00 2013
From: tony at atomide.com (Tony Lindgren)
Date: Fri, 5 Apr 2013 08:43:00 -0700
Subject: [PATCH v4 00/21] ARM: OMAP2+: Adapt to ehci-omap changes for 3.10
In-Reply-To: <515E9FB1.2040803@ti.com>
References: <1363794300-31526-1-git-send-email-rogerq@ti.com>
 <515E8B99.8080803@ti.com> <515E9FB1.2040803@ti.com>
Message-ID: <20130405154259.GZ10155@atomide.com>

* Benoit Cousson <b-cousson at ti.com> [130405 03:00]:
> On 04/05/2013 10:30 AM, Benoit Cousson wrote:
> 
> ...
> 
> >>   ARM: dts: OMAP4: Add HS USB Host IP nodes
> >>   ARM: dts: OMAP3: Add HS USB Host IP nodes
> >>   ARM: dts: omap3-beagle: Add USB Host support
> > 
> > These 3 DTS patches are good to me, but I cannot applied them on top of
> > the already existing patches I queued for 3.10.
> > 
> > git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git
> > for_3.10/dts
> > 
> > Could you rebase these 3 ones only, and I will applied them.
> 
> Mmm, in fact, I've just seen the pull request from Tony :-(
> 
> 
> Tony,
> 
> Don't you want to remove these DTS patches from the pull-request?

Oops sorry :( Looks like I applied them mistakenly as I saved all
the patches into a mbox, then applied it. Anyways, too late to start
messing with it now.
 
> Otherwise, I will have to rebase the whole DTS series on top of yours.
> That being said, if the branch is not supposed to be rebased, it is doable.

I pulled in your for_3.10/dts for testing, and to me it looks like
it's just overlapping additions. So that should be OK to resolve while
pulling it in.

It seems there's no need to add omap-for-v3.10/usb as a dependency for
your for_3.10/dts unless the conflict gets non-trivial with some
additional patches.

Regards,

Tony


From sergei.shtylyov at cogentembedded.com  Fri Apr  5 11:47:35 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Fri, 05 Apr 2013 19:47:35 +0400
Subject: [PATCH 1/8] ARM: shmobile:Marzen: move USB EHCI, OHCI, and PHY
 devices to R8A7779 code
In-Reply-To: <20130405004147.GN29203@verge.net.au>
References: <201304050257.00799.sergei.shtylyov@cogentembedded.com>
 <20130405004147.GN29203@verge.net.au>
Message-ID: <515EF217.2010109@cogentembedded.com>

Hello.

On 05-04-2013 4:41, Simon Horman wrote:

>> USB EHCI, OHCI, and common PHY are the SoC devices but are wrongly defined and
>> registered in the Marzen board file.  Move the data and code to their proper
>> place in setup-r8a7779.c; while at it, we have to rename 8a7779_late_devices[]
>> to 8a7779_standard_devices[] -- this seems legitimate since they are registered
>> from r8a7779_add_standard_devices() anyway.

>> Note that I'm deliberately changing the USB PHY platform device's 'id' field
>> from (previously just omitted) 0 to -1 as the device is a single of its kind.

> Would it be possible to re-arange this patch so that
> there is an SoC patch followed by a board patch?

    I seriously doubt it, thought I'll try to think about it more. The patch 
adding the SoC devices to the board file should't have been accepted in the 
first place, so we wouldn't have to fix it eventually.

WBR, Sergei



From swarren at wwwdotorg.org  Fri Apr  5 11:48:37 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Fri, 05 Apr 2013 09:48:37 -0600
Subject: [PATCH -next] ARM: tegra: pm: remove duplicated include from pm.c
In-Reply-To: <CAPgLHd-FCVa-k1dBCgPrQOdDpmovvWwy+UjFmu8pj5ZCRad5EQ@mail.gmail.com>
References: <CAPgLHd-FCVa-k1dBCgPrQOdDpmovvWwy+UjFmu8pj5ZCRad5EQ@mail.gmail.com>
Message-ID: <515EF255.2010608@wwwdotorg.org>

On 04/05/2013 12:58 AM, Wei Yongjun wrote:
> Remove duplicated include.

Thanks. Applied to Tegra's for-3.10/soc branch.


From tony at atomide.com  Fri Apr  5 11:58:52 2013
From: tony at atomide.com (Tony Lindgren)
Date: Fri, 5 Apr 2013 08:58:52 -0700
Subject: [RFC][PATCH 1/2] ARM: OMAP4: clock: Add device tree support
 for AUXCLKs
In-Reply-To: <515EA9E3.1010409@ti.com>
References: <1363703220-4777-1-git-send-email-rogerq@ti.com>
 <1363703220-4777-2-git-send-email-rogerq@ti.com>
 <20130403234242.GE10155@atomide.com> <515D2D30.3000306@ti.com>
 <20130404164137.GH10155@atomide.com> <515EA9E3.1010409@ti.com>
Message-ID: <20130405155851.GA10155@atomide.com>

* Roger Quadros <rogerq at ti.com> [130405 03:44]:
> On 04/04/2013 07:41 PM, Tony Lindgren wrote:
> > * Roger Quadros <rogerq at ti.com> [130404 00:39]:
> >> On 04/04/2013 02:42 AM, Tony Lindgren wrote:
> > For v3.10, let's just make sure that USB works with DT as then
> > after v3.10 we can make omap4 DT only and get rid of estimated
> > 7K lines of code and data. I guess this is the last piece missing
> > for that, or are we also missing something else?
> 
> For panda we just need a way to map the auxclk to the USB PHY device
> and the relevant dts data to get USB host working with DT.
> Beagle USB host should work already with DT without any changes.
> 
> > 
> > Can't you set up a clock alias for your device so it can find the
> > auxclk when requesting it with the dev entry?
> > 
> 
> which clock is mapped to which PHY device depends on board design
> and that cannot be per-determined at one place. This information
> needs to come from the board.dts file.

OK that makes sense.
 
> There was an earlier attempt to provide a way of building clock aliases
> at runtime from device tree [1], but the current approach is way better
> 
> [1]
> https://lkml.org/lkml/2013/3/12/241
> 
> > For the DT clock driver if needed for v3.10, how about just do a
> > minimal drivers/clock/omap/ that uses the standard binding?
> > Then that driver can just do clk_get() from cclock44xx_data.c
> 
> I don't understand how to do it and why it is better than the current
> approach.

Well your approach is fine as a first step moving all the clock
code, but it needs to be a real driver under drivers/clock/omap.
And the DT binding needs to stay the same for the driver(s) in the
long term as we start moving clocks to DT + /lib/firmware.

If this all is too late for v3.10, I suggest you just set up the
right clock alias for panda with machine_is_compatible flag in
board-generic.c so we get EHCI working with DT for v3.10. Then
it's easy to to deal with it properly for v3.11.

> How can that driver do clk_get() from cclock44xx_data.c?
> from where does it get the clk_id to pass into clk_get()?

Can't you just use the clock name there to get it?
 
> > for now? And then later on we'll just move all the clocks to a
> > combination of DT + /lib/firmware.
> 
> What is the benefit of moving clock data to /lib/firmware? We could
> as well just move it to DT only, no?

DT only clocks option is naturally available with this too. It
just gets easily inefficient with such a huge number of clocks.
 
> >> e.g. auxclk are required to be specified in DT nodes for USB PHY.
> >> Without this we can't get USB host working on Panda.
> > 
> > OK. So if the USB PHY has a dev entry, can't you just set up a
> > clock alias in struct omap_clk omap44xx_clks[] for it?
> 
> I've explained why this can't be done above.

Yes I understand now, the clock is board specific. 
  
> >> As Rajendra points out, it seems moving entire clock data to DT is not
> >> going to happen soon. So this is the simplistic way things can work.
> > 
> > Right but seems like we can get started there without moving
> > them all at once.
> > 
> What if we provide a complete clock list instead of only auxclks in
> dt_clks[]?
> 
> This approach is similar to arch/arm/mach-imx/clk-imx35.c
> 
> Device drivers can then use them as they migrate to DT. Then later
> we could migrate clock data to DT, without impacting device drivers.

As long as the binding stays the same in the long run too, this
clock remapping approach is just fine as a starting point. And
the driver needs to go to drivers/clock/omap. But in the long run
we just want to get the huge amounts static data out of the kernel
for clocks and hwmod data to fix things for good.

Regards,

Tony


From stefano.stabellini at eu.citrix.com  Fri Apr  5 12:01:55 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Fri, 5 Apr 2013 17:01:55 +0100
Subject: [PATCH 0/4 v6] arm: introduce psci_smp_ops and use them on Xen
In-Reply-To: <alpine.DEB.2.02.1304031239550.5078@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1304031239550.5078@kaball.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1304051657230.21065@kaball.uk.xensource.com>

Russell,
sorry for not CC'ing you explicitly since v1 of this series, there have
been quite few lengthy discussions on this topic.

Do you have any opinions on this?
Do you feel that this work belong to your tree, or do you want me to go
via arm-soc?



On Fri, 5 Apr 2013, Stefano Stabellini wrote:
> Hi all,
> this is the sixth version of the patch series to move virt_smp_ops out of
> mach-virt and make it a generic set of reusable PSCI based smp_ops.
> psci_smp_ops are preferred over the platform smp_ops.
> I added a patch to introduce smp_init to this series.
> In the last patch I am using smp_init to switch to psci_smp_ops if Xen
> is detected on the platform.
> 
> 
> Jon Medhurst (1):
>       ARM: Enable selection of SMP operations at boot time
> 
> Stefano Stabellini (3):
>       arm: introduce psci_smp_ops
>       arm: prefer psci_smp_ops over mdesc->smp
>       xen/arm: introduce xen_early_init, use PSCI on xen
> 
>  arch/arm/Kconfig                      |    1 +
>  arch/arm/include/asm/mach/arch.h      |    3 +
>  arch/arm/include/asm/psci.h           |   29 ++++++++++++++
>  arch/arm/include/asm/xen/hypervisor.h |    6 +++
>  arch/arm/kernel/Makefile              |    5 ++-
>  arch/arm/kernel/psci.c                |    7 +--
>  arch/arm/kernel/psci_smp.c            |   67 +++++++++++++++++++++++++++++++++
>  arch/arm/kernel/setup.c               |   12 +++++-
>  arch/arm/mach-virt/Makefile           |    1 -
>  arch/arm/mach-virt/platsmp.c          |   58 ----------------------------
>  arch/arm/mach-virt/virt.c             |    3 -
>  arch/arm/xen/enlighten.c              |   36 ++++++++++++++----
>  12 files changed, 152 insertions(+), 76 deletions(-)
> 
>     
> git://xenbits.xen.org/people/sstabellini/linux-pvhvm.git 3.9-rc3-smp-6
> 
> 
> Cheers,
> 
> Stefano
> 


From robherring2 at gmail.com  Fri Apr  5 12:06:34 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Fri, 05 Apr 2013 11:06:34 -0500
Subject: [PATCH V2 1/7] kbuild: create an "include chroot" for DT bindings
In-Reply-To: <515E2257.4030607@wwwdotorg.org>
References: <1365032098-22825-1-git-send-email-swarren@wwwdotorg.org>
 <515E09FA.1090408@gmail.com> <515E2257.4030607@wwwdotorg.org>
Message-ID: <515EF68A.3020505@gmail.com>

On 04/04/2013 08:01 PM, Stephen Warren wrote:
> On 04/04/2013 05:17 PM, Rob Herring wrote:
>> On 04/03/2013 06:34 PM, Stephen Warren wrote:
>>> From: Stephen Warren <swarren at nvidia.com>
>>>
>>> The recent dtc+cpp support allows header files and C pre-processor
>>> defines/macros to be used when compiling device tree files. These
>>> headers will typically define various constants that are part of the
>>> device tree bindings.
>>>
>>> The original patch which set up the dtc+cpp include path only considered
>>> using those headers from device tree files. However, most are also
>>> useful for kernel code which needs to interpret the device tree.
>>>
>>> In both the DT files and the kernel, I'd like to include the DT-related
>>> headers in the same way, for example, <dt-bindings/gpio/tegra-gpio.h>.
>>> That will simplify any text which discusses the DT header locations.
>>>
>>> Creating a <dt-bindings/> for kernel source to use is as simple as
>>> placing files into include/dt-bindings/.
>>>
>>> However, when compiling DT files, the include path should be restricted
>>> so that only the dt-bindings path is available; arbitrary kernel headers
>>> shouldn't be exposed. For this reason, create a specific include
>>> directory for use by dtc+cpp, and symlink dt-bindings from there to the
>>> actual location of include/dt-bindings/. For want of a better location,
>>> place this "include chroot" into the existing dts/ directory.
>>>
>>> arch/*/boot/dts/include/dt-bindings -> ../../../../../include/dt-bindings
>>>
>>> Some headers used by device tree files may not be useful to the kernel;
>>> they may be used simply to aid in constructing the DT file (e.g. macros
>>> to create a node), but not define any information that the kernel needs
>>> to share. These may be placed directly into arch/*/boot/dts/ along with
>>> the DT files themselves.
>>>
>>> Cc: Shawn Guo <shawn.guo at linaro.org>
>>> Cc: Hiroshi Doyu <hdoyu at nvidia.com>
>>> Acked-by: Michal Marek <mmarek at suse.cz>
>>> Acked-by: Shawn Guo <shawn.guo at linaro.org>
>>> Acked-by: Rob Herring <rob.herring at calxeda.com>
>>> Signed-off-by: Stephen Warren <swarren at nvidia.com>
>>> ---
>>> Grant, Rob, Michal, I'm hoping for acks or comments from you so this
>>> series can be placed into a topic branch in the arm-soc repo, for others
>>> to build on during the 3.10 kernel cycle. Thanks.
>>
>> Well, you have mine here and the rest looks fine, so add it to the others.
> 
> Rob,
> 
> I had originally hoped for this to go into an arm-soc branch so that a
> number of SoCs could convert to use the feature in the same release,
> hence I was looking for acks to let that happen.
> 
> However, it's too late in the 3.10 cycle now for that to happen. Can the
> series be applied to the DT tree instead; people can convert during the
> 3.11 cycle.

That is fine. Can you send me a pull request.

Rob




From marex at denx.de  Fri Apr  5 12:08:15 2013
From: marex at denx.de (Marek Vasut)
Date: Fri, 5 Apr 2013 18:08:15 +0200
Subject: [PATCH] ARM: dts: imx23-olinuxino: Set the sdcard as non-removable
In-Reply-To: <CAAAP30FMObPdRg60eNov3FKRvycVrBxV-9DCu05Pb4Fx__H8Qw@mail.gmail.com>
References: <1365135413-31493-1-git-send-email-aletes.xgr@gmail.com>
 <201304051611.15003.marex@denx.de>
 <CAAAP30FMObPdRg60eNov3FKRvycVrBxV-9DCu05Pb4Fx__H8Qw@mail.gmail.com>
Message-ID: <201304051808.16034.marex@denx.de>

Dear Alexandre Pereira da Silva,

> On Fri, Apr 5, 2013 at 11:11 AM, Marek Vasut <marex at denx.de> wrote:
> > The CD line is working perfectly well on this board, so I don't get it.
> 
> In the schematics of this board, the SSP1_DETECT pin is connected to
> the green led. As I see, there is no way, the hardware can detect card
> removal. Am I missing something here?

You're right. Then the design is indeed defective. Sorry.

Best regards,
Marek Vasut


From sergei.shtylyov at cogentembedded.com  Fri Apr  5 12:07:34 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Fri, 05 Apr 2013 20:07:34 +0400
Subject: [PATCH v5 3/3] ARM: shmobile: sh73a0: add CPUFreq support
In-Reply-To: <1365156038-12467-4-git-send-email-g.liakhovetski@gmx.de>
References: <1365156038-12467-1-git-send-email-g.liakhovetski@gmx.de>
 <1365156038-12467-4-git-send-email-g.liakhovetski@gmx.de>
Message-ID: <515EF6C6.6050006@cogentembedded.com>

On 05-04-2013 14:00, Guennadi Liakhovetski wrote:

> This patch enables the use of the generic cpufreq-cpu0 driver on sh73a0.
> Providing a regulator, a list of OPPs in DT, combined with a virtual
> cpufreq-cpu0 platform device and a clock, attached to it is everything,
> the cpufreq-cpu0 driver needs. The first sh73a0 platform, implementing
> such CPUFreq support is kzm9g-reference.

> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas at gmail.com>
> ---

> v5: remove sh73a0-kzm9g-reference.dts hunk, it's now merged into patch 2/3

>   arch/arm/mach-shmobile/Kconfig        |    2 ++
>   arch/arm/mach-shmobile/setup-sh73a0.c |    5 +++++
>   2 files changed, 7 insertions(+), 0 deletions(-)

> diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
> index 1a517e2..4ac5bf9 100644
> --- a/arch/arm/mach-shmobile/Kconfig
> +++ b/arch/arm/mach-shmobile/Kconfig
[...]
> diff --git a/arch/arm/mach-shmobile/setup-sh73a0.c b/arch/arm/mach-shmobile/setup-sh73a0.c
> index d10ded0..9a522f9 100644
> --- a/arch/arm/mach-shmobile/setup-sh73a0.c
> +++ b/arch/arm/mach-shmobile/setup-sh73a0.c
> @@ -1003,6 +1003,8 @@ static const struct of_dev_auxdata sh73a0_auxdata_lookup[] __initconst = {
>
>   void __init sh73a0_add_standard_devices_dt(void)
>   {
> +	struct platform_device_info devinfo = { .name = "cpufreq-cpu0", .id = -1, };

    With NULL .parent? Shouldn't it be 'platform_bus'?

WBR, Sergei



From nicolas.pitre at linaro.org  Fri Apr  5 12:15:55 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Fri, 5 Apr 2013 12:15:55 -0400 (EDT)
Subject: [PATCH v6 2/4] arm: prefer psci_smp_ops over mdesc->smp
In-Reply-To: <1365167495-18508-2-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1304031239550.5078@kaball.uk.xensource.com>
 <1365167495-18508-2-git-send-email-stefano.stabellini@eu.citrix.com>
Message-ID: <alpine.LFD.2.03.1304051215270.1171@syhkavp.arg>

On Fri, 5 Apr 2013, Stefano Stabellini wrote:

> If PSCI is available on the platform, prefer psci_smp_ops over the
> platform smp_ops.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>

Acked-by: Nicolas Pitre <nico at linaro.org>

> ---
>  arch/arm/kernel/setup.c |    6 +++---
>  1 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> index 341efaa..dad3048 100644
> --- a/arch/arm/kernel/setup.c
> +++ b/arch/arm/kernel/setup.c
> @@ -770,10 +770,10 @@ void __init setup_arch(char **cmdline_p)
>  	psci_init();
>  #ifdef CONFIG_SMP
>  	if (is_smp()) {
> -		if (mdesc->smp)
> -			smp_set_ops(mdesc->smp);
> -		else if (psci_smp_available())
> +		if (psci_smp_available())
>  			smp_set_ops(&psci_smp_ops);
> +		else if (mdesc->smp)
> +			smp_set_ops(mdesc->smp);
>  		smp_init_cpus();
>  	}
>  #endif
> -- 
> 1.7.2.5
> 


From nicolas.ferre at atmel.com  Fri Apr  5 12:16:34 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Fri, 5 Apr 2013 18:16:34 +0200
Subject: [PATCH] Revert "drivers/rtc/rtc-at91rm9200.c: use a variable for
 storing IMR"
In-Reply-To: <20130405153547.GA515@kroah.com>
References: <20130405153547.GA515@kroah.com>
Message-ID: <1365178594-8468-1-git-send-email-nicolas.ferre@atmel.com>

From: Johan Hovold <jhovold at gmail.com>

This reverts commit 0ef1594.

This patch introduced a few races which cannot be easily fixed with a
small follow-up patch. Furthermore, the SoC with the broken hardware
register, which this patch intended to add support for, can only be used
with device trees, which this driver currently does not support.

Cc: stable <stable at vger.kernel.org>
Signed-off-by: Johan Hovold <jhovold at gmail.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre at atmel.com>
---
Linus,

As suggested by Greg, I send you directly this "revert" patch. I hope it will
join your tree before 3.9-final.

Here is the discussion that led to this "revert" patch.
https://lkml.org/lkml/2013/4/3/176

Thanks a lot, best regards,

 drivers/rtc/rtc-at91rm9200.c | 50 +++++++++++++++++---------------------------
 drivers/rtc/rtc-at91rm9200.h |  1 +
 2 files changed, 20 insertions(+), 31 deletions(-)

diff --git a/drivers/rtc/rtc-at91rm9200.c b/drivers/rtc/rtc-at91rm9200.c
index 0a9f27e..434ebc3 100644
--- a/drivers/rtc/rtc-at91rm9200.c
+++ b/drivers/rtc/rtc-at91rm9200.c
@@ -44,7 +44,6 @@ static DECLARE_COMPLETION(at91_rtc_updated);
 static unsigned int at91_alarm_year = AT91_RTC_EPOCH;
 static void __iomem *at91_rtc_regs;
 static int irq;
-static u32 at91_rtc_imr;
 
 /*
  * Decode time/date into rtc_time structure
@@ -109,11 +108,9 @@ static int at91_rtc_settime(struct device *dev, struct rtc_time *tm)
 	cr = at91_rtc_read(AT91_RTC_CR);
 	at91_rtc_write(AT91_RTC_CR, cr | AT91_RTC_UPDCAL | AT91_RTC_UPDTIM);
 
-	at91_rtc_imr |= AT91_RTC_ACKUPD;
 	at91_rtc_write(AT91_RTC_IER, AT91_RTC_ACKUPD);
 	wait_for_completion(&at91_rtc_updated);	/* wait for ACKUPD interrupt */
 	at91_rtc_write(AT91_RTC_IDR, AT91_RTC_ACKUPD);
-	at91_rtc_imr &= ~AT91_RTC_ACKUPD;
 
 	at91_rtc_write(AT91_RTC_TIMR,
 			  bin2bcd(tm->tm_sec) << 0
@@ -145,7 +142,7 @@ static int at91_rtc_readalarm(struct device *dev, struct rtc_wkalrm *alrm)
 	tm->tm_yday = rtc_year_days(tm->tm_mday, tm->tm_mon, tm->tm_year);
 	tm->tm_year = at91_alarm_year - 1900;
 
-	alrm->enabled = (at91_rtc_imr & AT91_RTC_ALARM)
+	alrm->enabled = (at91_rtc_read(AT91_RTC_IMR) & AT91_RTC_ALARM)
 			? 1 : 0;
 
 	dev_dbg(dev, "%s(): %4d-%02d-%02d %02d:%02d:%02d\n", __func__,
@@ -171,7 +168,6 @@ static int at91_rtc_setalarm(struct device *dev, struct rtc_wkalrm *alrm)
 	tm.tm_sec = alrm->time.tm_sec;
 
 	at91_rtc_write(AT91_RTC_IDR, AT91_RTC_ALARM);
-	at91_rtc_imr &= ~AT91_RTC_ALARM;
 	at91_rtc_write(AT91_RTC_TIMALR,
 		  bin2bcd(tm.tm_sec) << 0
 		| bin2bcd(tm.tm_min) << 8
@@ -184,7 +180,6 @@ static int at91_rtc_setalarm(struct device *dev, struct rtc_wkalrm *alrm)
 
 	if (alrm->enabled) {
 		at91_rtc_write(AT91_RTC_SCCR, AT91_RTC_ALARM);
-		at91_rtc_imr |= AT91_RTC_ALARM;
 		at91_rtc_write(AT91_RTC_IER, AT91_RTC_ALARM);
 	}
 
@@ -201,12 +196,9 @@ static int at91_rtc_alarm_irq_enable(struct device *dev, unsigned int enabled)
 
 	if (enabled) {
 		at91_rtc_write(AT91_RTC_SCCR, AT91_RTC_ALARM);
-		at91_rtc_imr |= AT91_RTC_ALARM;
 		at91_rtc_write(AT91_RTC_IER, AT91_RTC_ALARM);
-	} else {
+	} else
 		at91_rtc_write(AT91_RTC_IDR, AT91_RTC_ALARM);
-		at91_rtc_imr &= ~AT91_RTC_ALARM;
-	}
 
 	return 0;
 }
@@ -215,10 +207,12 @@ static int at91_rtc_alarm_irq_enable(struct device *dev, unsigned int enabled)
  */
 static int at91_rtc_proc(struct device *dev, struct seq_file *seq)
 {
+	unsigned long imr = at91_rtc_read(AT91_RTC_IMR);
+
 	seq_printf(seq, "update_IRQ\t: %s\n",
-			(at91_rtc_imr & AT91_RTC_ACKUPD) ? "yes" : "no");
+			(imr & AT91_RTC_ACKUPD) ? "yes" : "no");
 	seq_printf(seq, "periodic_IRQ\t: %s\n",
-			(at91_rtc_imr & AT91_RTC_SECEV) ? "yes" : "no");
+			(imr & AT91_RTC_SECEV) ? "yes" : "no");
 
 	return 0;
 }
@@ -233,7 +227,7 @@ static irqreturn_t at91_rtc_interrupt(int irq, void *dev_id)
 	unsigned int rtsr;
 	unsigned long events = 0;
 
-	rtsr = at91_rtc_read(AT91_RTC_SR) & at91_rtc_imr;
+	rtsr = at91_rtc_read(AT91_RTC_SR) & at91_rtc_read(AT91_RTC_IMR);
 	if (rtsr) {		/* this interrupt is shared!  Is it ours? */
 		if (rtsr & AT91_RTC_ALARM)
 			events |= (RTC_AF | RTC_IRQF);
@@ -297,7 +291,6 @@ static int __init at91_rtc_probe(struct platform_device *pdev)
 	at91_rtc_write(AT91_RTC_IDR, AT91_RTC_ACKUPD | AT91_RTC_ALARM |
 					AT91_RTC_SECEV | AT91_RTC_TIMEV |
 					AT91_RTC_CALEV);
-	at91_rtc_imr = 0;
 
 	ret = request_irq(irq, at91_rtc_interrupt,
 				IRQF_SHARED,
@@ -336,7 +329,6 @@ static int __exit at91_rtc_remove(struct platform_device *pdev)
 	at91_rtc_write(AT91_RTC_IDR, AT91_RTC_ACKUPD | AT91_RTC_ALARM |
 					AT91_RTC_SECEV | AT91_RTC_TIMEV |
 					AT91_RTC_CALEV);
-	at91_rtc_imr = 0;
 	free_irq(irq, pdev);
 
 	rtc_device_unregister(rtc);
@@ -349,35 +341,31 @@ static int __exit at91_rtc_remove(struct platform_device *pdev)
 
 /* AT91RM9200 RTC Power management control */
 
-static u32 at91_rtc_bkpimr;
-
+static u32 at91_rtc_imr;
 
 static int at91_rtc_suspend(struct device *dev)
 {
 	/* this IRQ is shared with DBGU and other hardware which isn't
 	 * necessarily doing PM like we are...
 	 */
-	at91_rtc_bkpimr = at91_rtc_imr & (AT91_RTC_ALARM|AT91_RTC_SECEV);
-	if (at91_rtc_bkpimr) {
-		if (device_may_wakeup(dev)) {
+	at91_rtc_imr = at91_rtc_read(AT91_RTC_IMR)
+			& (AT91_RTC_ALARM|AT91_RTC_SECEV);
+	if (at91_rtc_imr) {
+		if (device_may_wakeup(dev))
 			enable_irq_wake(irq);
-		} else {
-			at91_rtc_write(AT91_RTC_IDR, at91_rtc_bkpimr);
-			at91_rtc_imr &= ~at91_rtc_bkpimr;
-		}
-}
+		else
+			at91_rtc_write(AT91_RTC_IDR, at91_rtc_imr);
+	}
 	return 0;
 }
 
 static int at91_rtc_resume(struct device *dev)
 {
-	if (at91_rtc_bkpimr) {
-		if (device_may_wakeup(dev)) {
+	if (at91_rtc_imr) {
+		if (device_may_wakeup(dev))
 			disable_irq_wake(irq);
-		} else {
-			at91_rtc_imr |= at91_rtc_bkpimr;
-			at91_rtc_write(AT91_RTC_IER, at91_rtc_bkpimr);
-		}
+		else
+			at91_rtc_write(AT91_RTC_IER, at91_rtc_imr);
 	}
 	return 0;
 }
diff --git a/drivers/rtc/rtc-at91rm9200.h b/drivers/rtc/rtc-at91rm9200.h
index 5f940b6..da1945e 100644
--- a/drivers/rtc/rtc-at91rm9200.h
+++ b/drivers/rtc/rtc-at91rm9200.h
@@ -64,6 +64,7 @@
 #define	AT91_RTC_SCCR		0x1c			/* Status Clear Command Register */
 #define	AT91_RTC_IER		0x20			/* Interrupt Enable Register */
 #define	AT91_RTC_IDR		0x24			/* Interrupt Disable Register */
+#define	AT91_RTC_IMR		0x28			/* Interrupt Mask Register */
 
 #define	AT91_RTC_VER		0x2c			/* Valid Entry Register */
 #define		AT91_RTC_NVTIM		(1 <<  0)		/* Non valid Time */
-- 
1.8.0



From nicolas.pitre at linaro.org  Fri Apr  5 12:22:05 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Fri, 5 Apr 2013 12:22:05 -0400 (EDT)
Subject: [PATCH v6 4/4] xen/arm: introduce xen_early_init, use PSCI on xen
In-Reply-To: <1365167495-18508-4-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1304031239550.5078@kaball.uk.xensource.com>
 <1365167495-18508-4-git-send-email-stefano.stabellini@eu.citrix.com>
Message-ID: <alpine.LFD.2.03.1304051217560.1171@syhkavp.arg>

On Fri, 5 Apr 2013, Stefano Stabellini wrote:

> Split xen_guest_init in two functions, one of them (xen_early_init) is
> going to be called very early from setup_arch.
> 
> Change machine_desc->smp_init to xen_smp_init if Xen is present on the
> platform. xen_smp_init just sets smp_ops to psci_smp_ops.

I still think the above is redundant, especially since psci_smp_ops has 
priority over default mdesc->smp_ops.  And doing so does break MCPM. But 
we're apparently going in circle over this issue.


Nicolas


From jgunthorpe at obsidianresearch.com  Fri Apr  5 12:27:37 2013
From: jgunthorpe at obsidianresearch.com (Jason Gunthorpe)
Date: Fri, 5 Apr 2013 10:27:37 -0600
Subject: mvebu-mbus: defining a DT binding
In-Reply-To: <20130405150200.7b6dee63@skate>
References: <20130405150200.7b6dee63@skate>
Message-ID: <20130405162737.GA3598@obsidianresearch.com>

On Fri, Apr 05, 2013 at 03:02:00PM +0200, Thomas Petazzoni wrote:

>  * The address decoding windows are in fact defined by the ranges =
>    <...> property of the mbus node. Here, in the example provided by
>    Jason, this ranges = <...> property is part of the SoC-level .dtsi.
>    However, some boards will have to add some board-specific windows
>    (adjusted to the size of their NOR, or FPGA, for example).

Right. The things Linux does to try and re-use parts of the DT are
nice, but I don't think they should strongly guide the design of the
binding.. Someone recently said that the DT is designed to be machine
parseable not human readable..

In any event, the 'default' mbus window locations in the static DTB
should match the configuration the bootloader sets when it boots
Linux. Ideally some basic level of functionality should be possible
without the dynamic mbus driver..

So to me, this is already a guide that this might have to be board
specific anyhow.

>  * I am not sure to understand why the nand, crypto and pcie-controller
>    nodes are outside of the internal registers. Well, I understand it's
>    because those devices need a special address decoding window. But it
>    sounds strange because those devices also have internal registers
>    (which is why Jason used 'MAPDEF_INTERNAL + offset' in the reg
>    property).

This is a arbitary choice, of course. Arnd: The issue is how do you
refer to two MBUS windows in a single device node.

>From a design perspective, the chip has an internal regs blocks. I
modeled that block directly with a bus node (internal_regs at f1000000).
It has a single ranges, that is 0 based. This makes the 'regs' of the
children exactly match the datasheet.  Everything that couldn't fit in
there I treated as an exception, and placed directly under mbus
instead.

The main alternative made less sense to me:

mbus {
  ranges = <MAPDEF_INTERNAL 0xf1000000 0x100000
 [..]

  everything@?? {
       ranges = <0x00000000 MAPDEF_INTERNAL 0x100000
                 0x10000000 MAPDEF_CRYPTO 0x800>
  }
}

The 'everything' node is very muddled to me.

>  * Regarding the PCIe binding, Jason Gunthorpe suggests the use of a
>    'marvell,mbus-targets' attribute so that the PCIe driver knows what
>    target/attribute values to use to create the window. Currently, the
>    PCIe driver uses a name (like "pcie0.3") that it gives to the
>    mvebu-mbus driver, which then translates this name to the real
>    target/attribute values using per-SoC tables that associate names
>    (pcie0.3) with values (say 0x4 / 0x42).

Right, my intention with this was to eliminate the tables from the
mbus driver and move them into the DT. It made no sense to use the
MAPDEF stuff for the ranges, but then require driver hard-wiring for
PEX.

FWIW, I belive this should all be done on top of the nice stuff from
Steven Warren that enables the preprocessor for dts. That is why I
wrote the sample in preprocessor language.

Regards,
Jason


From sergei.shtylyov at cogentembedded.com  Fri Apr  5 12:28:19 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Fri, 05 Apr 2013 20:28:19 +0400
Subject: [PATCH 4/8] rcar-phy: remove EHCI internal buffer setup
In-Reply-To: <20130405004300.GO29203@verge.net.au>
References: <201304050303.56515.sergei.shtylyov@cogentembedded.com>
 <20130405004300.GO29203@verge.net.au>
Message-ID: <515EFBA3.7040702@cogentembedded.com>

Hello.

On 05-04-2013 4:43, Simon Horman wrote:

>> Now that the EHCI internal buffer setup is done by the platform code, we  can
>> remove  such code from this driver as it never really belonged here.  We also
>> no longer need the 2nd memory region now (2nd EHCI controller is simply missing
>> in e.g. R8A7778 SoC).

> I wonder if this patch could be split into a driver patch
> followed by an SoC patch. Or vice versa.

    This one indeed can, I just tried to somewhat save on patches. But not 
vice versa, of course, that'll break bisection. :-)

>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

WBR, Sergei



From sergei.shtylyov at cogentembedded.com  Fri Apr  5 12:30:00 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Fri, 05 Apr 2013 20:30:00 +0400
Subject: [PATCH 5/8] rcar-phy: correct base address
In-Reply-To: <20130405004356.GP29203@verge.net.au>
References: <201304050305.15517.sergei.shtylyov@cogentembedded.com>
 <20130405004356.GP29203@verge.net.au>
Message-ID: <515EFC08.8000308@cogentembedded.com>

Hello.

On 05-04-2013 4:43, Simon Horman wrote:

>> The memory region that is used by the driver overlaps EHCI and OHCI register
>> regions for absolutely no reason now  -- fix it by adding offset of 0x800 to
>> the base address, changing the register #define's accordingly. This has extra
>> positive effect that we now can use devm_ioremap_resource().

>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

> As per my comment regarding patch 4, I wonder if this
> could be split into a driver patch and an SoC patch.

    Absolutely not. That'll break bisection.

WBR, Sergei



From sameo at linux.intel.com  Fri Apr  5 12:30:56 2013
From: sameo at linux.intel.com (Samuel Ortiz)
Date: Fri, 5 Apr 2013 18:30:56 +0200
Subject: [PATCH v10 0/12] Palmas updates
In-Reply-To: <1363964122-19201-1-git-send-email-ian@slimlogic.co.uk>
References: <1363964122-19201-1-git-send-email-ian@slimlogic.co.uk>
Message-ID: <20130405163056.GN17363@zurbaran>

Hi Ian,

On Fri, Mar 22, 2013 at 02:55:10PM +0000, Ian Lartey wrote:
> This patchset adds to the support for the Palmas series of PMIC chips.
> 
> Some of the patches have previously been submitted individually.
> The DT bindings doc has been added first due to comments that it was missing.
> 
> Patches based on linux-next-20130319
Are you expecting all those patches to go through the MFD tree ?
Also, you stil have a few comments from Milo and Stephen to adress. Are you
planning to send a v11 ?

Cheers,
Samuel.

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


From sameo at linux.intel.com  Fri Apr  5 12:32:23 2013
From: sameo at linux.intel.com (Samuel Ortiz)
Date: Fri, 5 Apr 2013 18:32:23 +0200
Subject: [PATCH v10 03/12] mfd: palmas add variant and OTP detection
In-Reply-To: <1363964122-19201-4-git-send-email-ian@slimlogic.co.uk>
References: <1363964122-19201-1-git-send-email-ian@slimlogic.co.uk>
 <1363964122-19201-4-git-send-email-ian@slimlogic.co.uk>
Message-ID: <20130405163223.GO17363@zurbaran>

Hi Ian,

On Fri, Mar 22, 2013 at 02:55:13PM +0000, Ian Lartey wrote:
> @@ -278,20 +329,20 @@ static void palmas_dt_to_pdata(struct i2c_client *i2c,
>  	int ret;
>  	u32 prop;
>  
> -	ret = of_property_read_u32(node, "ti,mux_pad1", &prop);
> +	ret = of_property_read_u32(node, "ti,mux-pad1", &prop);
>  	if (!ret) {
>  		pdata->mux_from_pdata = 1;
>  		pdata->pad1 = prop;
>  	}
>  
> -	ret = of_property_read_u32(node, "ti,mux_pad2", &prop);
> +	ret = of_property_read_u32(node, "ti,mux-pad2", &prop);
>  	if (!ret) {
>  		pdata->mux_from_pdata = 1;
>  		pdata->pad2 = prop;
>  	}
>  
>  	/* The default for this register is all masked */
> -	ret = of_property_read_u32(node, "ti,power_ctrl", &prop);
> +	ret = of_property_read_u32(node, "ti,power-ctrl", &prop);
>  	if (!ret)
>  		pdata->power_ctrl = prop;
>  	else
> @@ -309,7 +360,7 @@ static int palmas_i2c_probe(struct i2c_client *i2c,
>  	struct palmas_platform_data *pdata;
>  	struct device_node *node = i2c->dev.of_node;
>  	int ret = 0, i;
> -	unsigned int reg, addr;
> +	unsigned int reg;
>  	int slave;
>  	struct mfd_cell *children;
The '-' to '_' fix has been sent by J Keerthy and is on my mfd-next tree
aready. Would you mind removing it from this patch ?

Cheers,
Samuel.

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


From sergei.shtylyov at cogentembedded.com  Fri Apr  5 12:33:39 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Fri, 05 Apr 2013 20:33:39 +0400
Subject: [PATCH 7/8] ARM: shmobile: Marzen: pass platform data to USB
 PHY device
In-Reply-To: <20130405004445.GQ29203@verge.net.au>
References: <201304050310.39289.sergei.shtylyov@cogentembedded.com>
 <20130405004445.GQ29203@verge.net.au>
Message-ID: <515EFCE3.4060805@cogentembedded.com>

Hello.

On 05-04-2013 4:44, Simon Horman wrote:

>> Since we're now going to setup the USBPCTRL0 register using the USB PHY device's
>> platform data, we now need a way to pass those platform data from the board file
>> to the device which is situated in setup-r8a7779.c -- and what I'm suggesting is
>> r8a7779_add_usb_phy_device() that will register USB PHY platform device with the
>> passed platform data using platform_device_register_resndata() call; creating
>> this function involves deletion of 'usb_phy_device' from r8a7779_devices_dt[],
>> so that it will no longer be registered for the generic R8A7779 machine (where
>> we can't provide the platform data anyway), hence EHCI/OHCI drivers will fail
>> to load as well.

>> For the Marzen board, this new function will be called from marzen_init() to
>> register the USB PHY device early enough.

> As per my comment regarding patch 1, I wonder if this could
> be split into an SoC patch and a board patch.

    No, that'll break bisection as it will cause the PHY driver to not be 
registered after the SoC patch, and hence EHCI/OHCI drivers won't load too.

>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

WBR, Sergei



From sameo at linux.intel.com  Fri Apr  5 12:39:58 2013
From: sameo at linux.intel.com (Samuel Ortiz)
Date: Fri, 5 Apr 2013 18:39:58 +0200
Subject: [PATCH v4 04/14] mfd: Add Samsung PWM/timer master driver
In-Reply-To: <1365093431-30621-5-git-send-email-t.figa@samsung.com>
References: <1365093431-30621-1-git-send-email-t.figa@samsung.com>
 <1365093431-30621-5-git-send-email-t.figa@samsung.com>
Message-ID: <20130405163958.GP17363@zurbaran>

Hi Tomasz,

On Thu, Apr 04, 2013 at 06:37:01PM +0200, Tomasz Figa wrote:
> This patch adds master driver for PWM/timer block available on many
> Samsung SoCs providing clocksource and PWM output capabilities.
> 
> Signed-off-by: Tomasz Figa <t.figa at samsung.com>
> Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
> ---
>  .../devicetree/bindings/pwm/pwm-samsung.txt        |  37 ++
>  drivers/clocksource/Kconfig                        |   1 +
>  drivers/mfd/Kconfig                                |   3 +
>  drivers/mfd/Makefile                               |   1 +
>  drivers/mfd/samsung-pwm.c                          | 439 +++++++++++++++++++++
>  drivers/pwm/Kconfig                                |   1 +
>  include/linux/mfd/samsung-pwm.h                    |  49 +++
>  include/linux/platform_data/samsung-pwm.h          |  28 ++
>  8 files changed, 559 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/pwm/pwm-samsung.txt
>  create mode 100644 drivers/mfd/samsung-pwm.c
>  create mode 100644 include/linux/mfd/samsung-pwm.h
>  create mode 100644 include/linux/platform_data/samsung-pwm.h
Why is that an MFD driver, and why aren't you using the PWM APIs for it ?
Also, you probably want to look at using the regmap APIs for your IO.

Cheers,
Samuel.

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


From sergei.shtylyov at cogentembedded.com  Fri Apr  5 12:40:13 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Fri, 05 Apr 2013 20:40:13 +0400
Subject: [PATCH 0/8] Reorganize R8A7779/Marzen USB code
In-Reply-To: <87vc81ka6k.wl%kuninori.morimoto.gx@renesas.com>
References: <201304050251.44464.sergei.shtylyov@cogentembedded.com>
 <87vc81ka6k.wl%kuninori.morimoto.gx@renesas.com>
Message-ID: <515EFE6D.4020006@cogentembedded.com>

Hello.

On 05-04-2013 6:01, Kuninori Morimoto wrote:

>>     Here's the set of 4 patches against the Simon Horman's 'renesas.git' repo,
>> 'renesas-next-20130404v2' tag and the 2 Ether patches I've reposted yesterday.
>> It was created to fix the shortcomings in the R8A7779/Marzen USB platform code
>> and R8A7779 USB common PHY driver, and so spans both arch/arm/mach-shmobile/
>> and drivers/usb/ subtrees (some patches have to touch both subtrees).
>> The patches were conceived with the complete bisectability goal in mind.

>> [1/8] ARM: shmobile:Marzen: move USB EHCI, OHCI, and PHY devices to R8A7779 code
>> [2/8] ehci-platform: add init() method to platform data
>> [3/8] ARM: shmobile: R8A7779: setup EHCI internal buffer
>> [4/8] rcar-phy: remove EHCI internal buffer setup
>> [5/8] rcar-phy: correct base address
>> [6/8] rcar-phy: add platform data
>> [7/8] ARM: shmobile: Marzen: pass platform data to USB PHY device
>> [8/8] rcar-phy: handle platform data

>>     I'm not sure thru which tree this patchset should be merged, however it turns
>> out that it's too late now to push it thru Felipe Balbi's USB tree for 3.10, so
>> maybe the patchset can be merged thru Simon's tree with Felipe's and Alan
>> Stern's ACKs.

> I guess you already got request about patch style from Simon.

    It's not about style. I tried to keep the series copmpletely bisectable, 
and granting almost all requests about splitting the patches would have broken 
the bisection.

> When you send v2 patch, could you please add "this patch is tested on xxxx bard"
> on each patch's comment area ?

    I'm not sure it's worth doing v2, although in one place I can indeed 
readily split the patch. All patches were tested on the Marzen board, I forgot 
to mention that in the cover letter.

> Then,
> for all patches

> Acked-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>

    Thanks.

WBR, Sergei



From robherring2 at gmail.com  Fri Apr  5 12:43:06 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Fri, 05 Apr 2013 11:43:06 -0500
Subject: [PATCH] documentation: iommu: add description of ARM System MMU
 binding
In-Reply-To: <1365094259-24847-1-git-send-email-will.deacon@arm.com>
References: <1365094259-24847-1-git-send-email-will.deacon@arm.com>
Message-ID: <515EFF1A.5030705@gmail.com>

On 04/04/2013 11:50 AM, Will Deacon wrote:
> This patch adds a description of the device tree binding for the ARM
> System MMU architecture.
> 
> Cc: Rob Herring <robherring2 at gmail.com>
> Cc: Andreas Herrmann <andreas.herrmann at calxeda.com>
> Signed-off-by: Will Deacon <will.deacon at arm.com>
> ---
> 
> Hello,
> 
> The driver for this is still a WIP. Both Andreas and myself have prototype
> code, but we're planning to merge that together to get something more
> general. Deciding on the binding is a good first step.

Thanks for getting this out.

> All comments welcome,
> 
> Will
> 
>  .../devicetree/bindings/iommu/arm,smmu.txt         | 61 ++++++++++++++++++++++
>  1 file changed, 61 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/iommu/arm,smmu.txt
> 
> diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> new file mode 100644
> index 0000000..938325f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> @@ -0,0 +1,61 @@
> +* ARM System MMU Architecture Implementation
> +
> +ARM SoCs may contain an implementation of the ARM System Memory
> +Management Unit Architecture, which can be used to provide 1 or 2 stages
> +of address translation to bus masters external to the CPU.
> +
> +The SMMU may also raise interrupts in response to various fault
> +conditions.
> +
> +** System MMU required properties:
> +
> +- compatible    : Should be one of "arm,smmu-v1" or "arm,smmu-v2"
> +                  depending on the version of the architecture
> +                  implemented.

We can keep these, but we should have specific models like arm,smmu-400,
etc. as well.

> +
> +- reg           : Base address and size of the SMMU.
> +
> +- #global-interrupts : The number of global interrupts exposed by the
> +                       device.
> +
> +- interrupts    : Interrupt list, with the first #global-irqs entries
> +                  corresponding to the global interrupts and any
> +                  following entries corresponding to context interrupts,
> +                  specified in order of their indexing by the SMMU.
> +
> +- mmu-masters   : A list of phandles to device nodes representing bus
> +                  masters for which the SMMU can provide a translation.
> +
> +- stream-ids    : A list of 16-bit values corresponding to the StreamIDs
> +                  for the devices listed in the mmu-masters property.
> +                  This list must be same length as mmu-masters, so
> +                  masters with multiple stream-ids will have multiple
> +                  entries in mmu-masters.

Your example below is actually 32-bit values in the DTB. You can
annotate them to actually be 16-bit if you want. But I would just leave
them as 32-bit.

> +
> +** System MMU optional properties:
> +
> +- smmu-parent   : When multiple SMMUs are chained together, this
> +                  property can be used to provide a phandle to the
> +                  parent SMMU (that is the next SMMU on the path going
> +                  from the mmu-masters towards memory) node for this
> +                  SMMU.

Does the SMMU need to know if it is coherent or not?

Rob

> +
> +Example:
> +
> +        smmu {
> +                compatible = "arm,smmu-v1";
> +                reg = <0xba5e0000 0x10000>;
> +                #global-interrupts = <2>;
> +                interrupts = <0 32 4>,
> +                             <0 33 4>,
> +                             <0 34 4>, /* This is the first context interrupt */
> +                             <0 35 4>,
> +                             <0 36 4>,
> +                             <0 37 4>;
> +                mmu-masters = <&dma0>,
> +                              <&dma0>,
> +                              <&dma1>;
> +                stream-ids  = <0xd01d>,
> +                              <0xd01e>,
> +                              <0xd11c>;
> +        };
> 



From geoff at infradead.org  Fri Apr  5 12:46:50 2013
From: geoff at infradead.org (Geoff Levand)
Date: Fri, 05 Apr 2013 09:46:50 -0700
Subject: [PATCH 6/7] ARM: KVM: switch to a dual-step HYP init code
In-Reply-To: <515E9474.2070100@arm.com>
References: <1364909115-3810-1-git-send-email-marc.zyngier@arm.com>
 <1364909115-3810-7-git-send-email-marc.zyngier@arm.com>
 <1365113453.24496.26.camel@smoke> <515E9474.2070100@arm.com>
Message-ID: <1365180410.24496.67.camel@smoke>

Hi Marc,

On Fri, 2013-04-05 at 10:08 +0100, Marc Zyngier wrote:
> On 04/04/13 23:10, Geoff Levand wrote:
> > On Tue, 2013-04-02 at 14:25 +0100, Marc Zyngier wrote:
> >> +	@ Jump to the trampoline page
> >> +	ldr	r2, =#PAGE_MASK
> >> +	adr	r3, target
> >> +	bic	r3, r3, r2
> >> +	ldr	r2, =#TRAMPOLINE_VA
> >> +	add	r3, r3, r2
> >> +	mov	pc, r3
> > 
> > I guess you need 'ldr r2, =PAGE_MASK'.
> > 
> >   arch/arm/kvm/init.S:114: Error: bad expression -- `ldr r2,=#(~((1<<12)-1))'
> >   arch/arm/kvm/init.S:117: Error: bad expression -- `ldr r2,=#0xffff0000'
> 
> Oddly enough, this code compiles perfectly fine on my box.
> What's your compiler/binutils versions?

I thought # was for an immediate value in instructions.  This
is an assembler pseudo-instruction, and based on the ARM manual
here I would think your coding should fail:

  http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0473i/Chdcegci.html

I use the current arm-linux-gnueabihf cross toolchain packages from
Ubuntu 12.04:

  arm-linux-gnueabihf-gcc-4.6 (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3
  GNU assembler (GNU Binutils for Ubuntu) 2.22

-Geoff




From santosh.shilimkar at ti.com  Fri Apr  5 12:50:00 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Fri, 5 Apr 2013 22:20:00 +0530
Subject: [GIT PULL] ARM: OMAP5: hwmod, prm/cm data files and updates for
 3.10
In-Reply-To: <515DB110.9000503@ti.com>
References: <1363768852-18125-1-git-send-email-santosh.shilimkar@ti.com>
 <20130401170539.GK10155@atomide.com> <515BA76D.3000302@ti.com>
 <alpine.DEB.2.00.1304031146230.2616@utopia.booyaka.com>
 <515D6020.2030103@ti.com> <20130404165208.GI10155@atomide.com>
 <515DB110.9000503@ti.com>
Message-ID: <515F00B8.3000501@ti.com>

On Thursday 04 April 2013 10:27 PM, Santosh Shilimkar wrote:
> On Thursday 04 April 2013 10:22 PM, Tony Lindgren wrote:
>> * Santosh Shilimkar <santosh.shilimkar at ti.com> [130404 04:15]:
[..]

>> Can't we already trim the am33xx hwmod data after your patches for
>> v3.10 as am33xx is already DT only? Unfortunately we cannot create
>> negative diffstat in other ways for v3.10 merge window as we cannot
>> make omap4 DT only just quite yet.
>>
> Yes we can and I can take a stab it tomorrow. The only thing is I
> might need some support for testing but thats manageable. Will
> take a stab at it tomorrow and if everything goes well, post a
> patch for smae.
> 
Patch for the AM33XX to trim is end of the email. Thanks to
Sricharan and Pekon for patch and testing. Looping both
Vaibhav's if they have any objection on the patch.

Regards,
Santosh

>From b95dd33fe59b8e77727eb3b1717d763bbf9a2893 Mon Sep 17 00:00:00 2001
From: Sricharan R <r.sricharan at ti.com>
Date: Fri, 5 Apr 2013 20:39:12 +0530
Subject: [PATCH] ARM: AM33XX: hwmod data: Clean up the data file

- The IO resource information like dma request lines, irq number and
ocp address space can be populated via dt blob. So such data can be stripped
from SOC hwmod data file.

- The devices like adc, mailbox, gpmc which are missing the device
tree bindings, hwmod data is not added since AM33XX is DT only build.
When such devices add the dt bindings, respective hwmod data can be
added along with it.

- The hwmod like firewall etc which are not useful are also dropped.

This gets us around ~2000 loc of negative diff. Patch is boot tested on
AM335X EVM.

Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
Signed-off-by: Sricharan R <r.sricharan at ti.com>
---
Patch has to be based of the dt branch and recent cleanups which are
already in 3.10 queue. The patch also can be found on my git tree.

git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux.git for_3.10/am33xx_hwmod_cleanup

 arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 1993 +---------------------------
 1 file changed, 13 insertions(+), 1980 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index 31bea1c..19a35e8 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -35,63 +35,6 @@
  */
 
 /*
- * 'emif_fw' class
- * instance(s): emif_fw
- */
-static struct omap_hwmod_class am33xx_emif_fw_hwmod_class = {
-	.name		= "emif_fw",
-};
-
-/* emif_fw */
-static struct omap_hwmod am33xx_emif_fw_hwmod = {
-	.name		= "emif_fw",
-	.class		= &am33xx_emif_fw_hwmod_class,
-	.clkdm_name	= "l4fw_clkdm",
-	.main_clk	= "l4fw_gclk",
-	.flags		= (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET),
-	.prcm		= {
-		.omap4	= {
-			.clkctrl_offs	= AM33XX_CM_PER_EMIF_FW_CLKCTRL_OFFSET,
-			.modulemode	= MODULEMODE_SWCTRL,
-		},
-	},
-};
-
-/*
- * 'emif' class
- * instance(s): emif
- */
-static struct omap_hwmod_class_sysconfig am33xx_emif_sysc = {
-	.rev_offs	= 0x0000,
-};
-
-static struct omap_hwmod_class am33xx_emif_hwmod_class = {
-	.name		= "emif",
-	.sysc		= &am33xx_emif_sysc,
-};
-
-static struct omap_hwmod_irq_info am33xx_emif_irqs[] = {
-	{ .name = "ddrerr0", .irq = 101 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
-/* emif */
-static struct omap_hwmod am33xx_emif_hwmod = {
-	.name		= "emif",
-	.class		= &am33xx_emif_hwmod_class,
-	.clkdm_name	= "l3_clkdm",
-	.flags		= (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET),
-	.mpu_irqs	= am33xx_emif_irqs,
-	.main_clk	= "dpll_ddr_m2_div2_ck",
-	.prcm		= {
-		.omap4	= {
-			.clkctrl_offs	= AM33XX_CM_PER_EMIF_CLKCTRL_OFFSET,
-			.modulemode	= MODULEMODE_SWCTRL,
-		},
-	},
-};
-
-/*
  * 'l3' class
  * instance(s): l3_main, l3_s, l3_instr
  */
@@ -99,19 +42,11 @@ static struct omap_hwmod_class am33xx_l3_hwmod_class = {
 	.name		= "l3",
 };
 
-/* l3_main (l3_fast) */
-static struct omap_hwmod_irq_info am33xx_l3_main_irqs[] = {
-	{ .name = "l3debug", .irq = 9 + OMAP_INTC_START, },
-	{ .name = "l3appint", .irq = 10 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
 static struct omap_hwmod am33xx_l3_main_hwmod = {
 	.name		= "l3_main",
 	.class		= &am33xx_l3_hwmod_class,
 	.clkdm_name	= "l3_clkdm",
 	.flags		= (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET),
-	.mpu_irqs	= am33xx_l3_main_irqs,
 	.main_clk	= "l3_gclk",
 	.prcm		= {
 		.omap4	= {
@@ -196,20 +131,6 @@ static struct omap_hwmod am33xx_l4_wkup_hwmod = {
 	},
 };
 
-/* l4_fw */
-static struct omap_hwmod am33xx_l4_fw_hwmod = {
-	.name		= "l4_fw",
-	.class		= &am33xx_l4_hwmod_class,
-	.clkdm_name	= "l4fw_clkdm",
-	.flags		= (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET),
-	.prcm		= {
-		.omap4	= {
-			.clkctrl_offs	= AM33XX_CM_PER_L4FW_CLKCTRL_OFFSET,
-			.modulemode	= MODULEMODE_SWCTRL,
-		},
-	},
-};
-
 /*
  * 'mpu' class
  */
@@ -217,21 +138,11 @@ static struct omap_hwmod_class am33xx_mpu_hwmod_class = {
 	.name	= "mpu",
 };
 
-/* mpu */
-static struct omap_hwmod_irq_info am33xx_mpu_irqs[] = {
-	{ .name = "emuint", .irq = 0 + OMAP_INTC_START, },
-	{ .name = "commtx", .irq = 1 + OMAP_INTC_START, },
-	{ .name = "commrx", .irq = 2 + OMAP_INTC_START, },
-	{ .name = "bench", .irq = 3 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
 static struct omap_hwmod am33xx_mpu_hwmod = {
 	.name		= "mpu",
 	.class		= &am33xx_mpu_hwmod_class,
 	.clkdm_name	= "mpu_clkdm",
 	.flags		= (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET),
-	.mpu_irqs	= am33xx_mpu_irqs,
 	.main_clk	= "dpll_mpu_m2_ck",
 	.prcm		= {
 		.omap4	= {
@@ -253,11 +164,6 @@ static struct omap_hwmod_rst_info am33xx_wkup_m3_resets[] = {
 	{ .name = "wkup_m3", .rst_shift = 3, .st_shift = 5 },
 };
 
-static struct omap_hwmod_irq_info am33xx_wkup_m3_irqs[] = {
-	{ .name = "txev", .irq = 78 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
 /* wkup_m3  */
 static struct omap_hwmod am33xx_wkup_m3_hwmod = {
 	.name		= "wkup_m3",
@@ -265,7 +171,6 @@ static struct omap_hwmod am33xx_wkup_m3_hwmod = {
 	.clkdm_name	= "l4_wkup_aon_clkdm",
 	/* Keep hardreset asserted */
 	.flags		= HWMOD_INIT_NO_RESET | HWMOD_NO_IDLEST,
-	.mpu_irqs	= am33xx_wkup_m3_irqs,
 	.main_clk	= "dpll_core_m4_div2_ck",
 	.prcm		= {
 		.omap4	= {
@@ -291,25 +196,12 @@ static struct omap_hwmod_rst_info am33xx_pruss_resets[] = {
 	{ .name = "pruss", .rst_shift = 1 },
 };
 
-static struct omap_hwmod_irq_info am33xx_pruss_irqs[] = {
-	{ .name = "evtout0", .irq = 20 + OMAP_INTC_START, },
-	{ .name = "evtout1", .irq = 21 + OMAP_INTC_START, },
-	{ .name = "evtout2", .irq = 22 + OMAP_INTC_START, },
-	{ .name = "evtout3", .irq = 23 + OMAP_INTC_START, },
-	{ .name = "evtout4", .irq = 24 + OMAP_INTC_START, },
-	{ .name = "evtout5", .irq = 25 + OMAP_INTC_START, },
-	{ .name = "evtout6", .irq = 26 + OMAP_INTC_START, },
-	{ .name = "evtout7", .irq = 27 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
 /* pru-icss */
 /* Pseudo hwmod for reset control purpose only */
 static struct omap_hwmod am33xx_pruss_hwmod = {
 	.name		= "pruss",
 	.class		= &am33xx_pruss_hwmod_class,
 	.clkdm_name	= "pruss_ocp_clkdm",
-	.mpu_irqs	= am33xx_pruss_irqs,
 	.main_clk	= "pruss_ocp_gclk",
 	.prcm		= {
 		.omap4	= {
@@ -332,16 +224,10 @@ static struct omap_hwmod_rst_info am33xx_gfx_resets[] = {
 	{ .name = "gfx", .rst_shift = 0 },
 };
 
-static struct omap_hwmod_irq_info am33xx_gfx_irqs[] = {
-	{ .name = "gfxint", .irq = 37 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
 static struct omap_hwmod am33xx_gfx_hwmod = {
 	.name		= "gfx",
 	.class		= &am33xx_gfx_hwmod_class,
 	.clkdm_name	= "gfx_l3_clkdm",
-	.mpu_irqs	= am33xx_gfx_irqs,
 	.main_clk	= "gfx_fck_div_ck",
 	.prcm		= {
 		.omap4	= {
@@ -370,43 +256,6 @@ static struct omap_hwmod am33xx_prcm_hwmod = {
 };
 
 /*
- * 'adc/tsc' class
- * TouchScreen Controller (Anolog-To-Digital Converter)
- */
-static struct omap_hwmod_class_sysconfig am33xx_adc_tsc_sysc = {
-	.rev_offs	= 0x00,
-	.sysc_offs	= 0x10,
-	.sysc_flags	= SYSC_HAS_SIDLEMODE,
-	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
-			SIDLE_SMART_WKUP),
-	.sysc_fields	= &omap_hwmod_sysc_type2,
-};
-
-static struct omap_hwmod_class am33xx_adc_tsc_hwmod_class = {
-	.name		= "adc_tsc",
-	.sysc		= &am33xx_adc_tsc_sysc,
-};
-
-static struct omap_hwmod_irq_info am33xx_adc_tsc_irqs[] = {
-	{ .irq = 16 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
-static struct omap_hwmod am33xx_adc_tsc_hwmod = {
-	.name		= "adc_tsc",
-	.class		= &am33xx_adc_tsc_hwmod_class,
-	.clkdm_name	= "l4_wkup_clkdm",
-	.mpu_irqs	= am33xx_adc_tsc_irqs,
-	.main_clk	= "adc_tsc_fck",
-	.prcm		= {
-		.omap4	= {
-			.clkctrl_offs	= AM33XX_CM_WKUP_ADC_TSC_CLKCTRL_OFFSET,
-			.modulemode	= MODULEMODE_SWCTRL,
-		},
-	},
-};
-
-/*
  * Modules omap_hwmod structures
  *
  * The following IPs are excluded for the moment because:
@@ -508,16 +357,10 @@ static struct omap_hwmod_class am33xx_aes_hwmod_class = {
 	.name		= "aes",
 };
 
-static struct omap_hwmod_irq_info am33xx_aes0_irqs[] = {
-	{ .irq = 102 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
 static struct omap_hwmod am33xx_aes0_hwmod = {
 	.name		= "aes0",
 	.class		= &am33xx_aes_hwmod_class,
 	.clkdm_name	= "l3_clkdm",
-	.mpu_irqs	= am33xx_aes0_irqs,
 	.main_clk	= "l3_gclk",
 	.prcm		= {
 		.omap4	= {
@@ -532,16 +375,10 @@ static struct omap_hwmod_class am33xx_sha0_hwmod_class = {
 	.name		= "sha0",
 };
 
-static struct omap_hwmod_irq_info am33xx_sha0_irqs[] = {
-	{ .irq = 108 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
 static struct omap_hwmod am33xx_sha0_hwmod = {
 	.name		= "sha0",
 	.class		= &am33xx_sha0_hwmod_class,
 	.clkdm_name	= "l3_clkdm",
-	.mpu_irqs	= am33xx_sha0_irqs,
 	.main_clk	= "l3_gclk",
 	.prcm		= {
 		.omap4	= {
@@ -577,17 +414,10 @@ static struct omap_hwmod_class am33xx_smartreflex_hwmod_class = {
 	.name		= "smartreflex",
 };
 
-/* smartreflex0 */
-static struct omap_hwmod_irq_info am33xx_smartreflex0_irqs[] = {
-	{ .irq = 120 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
 static struct omap_hwmod am33xx_smartreflex0_hwmod = {
 	.name		= "smartreflex0",
 	.class		= &am33xx_smartreflex_hwmod_class,
 	.clkdm_name	= "l4_wkup_clkdm",
-	.mpu_irqs	= am33xx_smartreflex0_irqs,
 	.main_clk	= "smartreflex0_fck",
 	.prcm		= {
 		.omap4	= {
@@ -597,17 +427,10 @@ static struct omap_hwmod am33xx_smartreflex0_hwmod = {
 	},
 };
 
-/* smartreflex1 */
-static struct omap_hwmod_irq_info am33xx_smartreflex1_irqs[] = {
-	{ .irq = 121 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
 static struct omap_hwmod am33xx_smartreflex1_hwmod = {
 	.name		= "smartreflex1",
 	.class		= &am33xx_smartreflex_hwmod_class,
 	.clkdm_name	= "l4_wkup_clkdm",
-	.mpu_irqs	= am33xx_smartreflex1_irqs,
 	.main_clk	= "smartreflex1_fck",
 	.prcm		= {
 		.omap4	= {
@@ -624,17 +447,11 @@ static struct omap_hwmod_class am33xx_control_hwmod_class = {
 	.name		= "control",
 };
 
-static struct omap_hwmod_irq_info am33xx_control_irqs[] = {
-	{ .irq = 8 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
 static struct omap_hwmod am33xx_control_hwmod = {
 	.name		= "control",
 	.class		= &am33xx_control_hwmod_class,
 	.clkdm_name	= "l4_wkup_clkdm",
 	.flags		= (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET),
-	.mpu_irqs	= am33xx_control_irqs,
 	.main_clk	= "dpll_core_m4_div2_ck",
 	.prcm		= {
 		.omap4	= {
@@ -664,20 +481,11 @@ static struct omap_hwmod_class am33xx_cpgmac0_hwmod_class = {
 	.sysc		= &am33xx_cpgmac_sysc,
 };
 
-static struct omap_hwmod_irq_info am33xx_cpgmac0_irqs[] = {
-	{ .name = "c0_rx_thresh_pend", .irq = 40 + OMAP_INTC_START, },
-	{ .name = "c0_rx_pend", .irq = 41 + OMAP_INTC_START, },
-	{ .name = "c0_tx_pend", .irq = 42 + OMAP_INTC_START, },
-	{ .name = "c0_misc_pend", .irq = 43 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
 static struct omap_hwmod am33xx_cpgmac0_hwmod = {
 	.name		= "cpgmac0",
 	.class		= &am33xx_cpgmac0_hwmod_class,
 	.clkdm_name	= "cpsw_125mhz_clkdm",
 	.flags		= (HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY),
-	.mpu_irqs	= am33xx_cpgmac0_irqs,
 	.main_clk	= "cpsw_125mhz_gclk",
 	.prcm		= {
 		.omap4	= {
@@ -708,18 +516,10 @@ static struct omap_hwmod_class am33xx_dcan_hwmod_class = {
 	.name = "d_can",
 };
 
-/* dcan0 */
-static struct omap_hwmod_irq_info am33xx_dcan0_irqs[] = {
-	{ .name = "d_can_ms", .irq = 52 + OMAP_INTC_START, },
-	{ .name = "d_can_mo", .irq = 53 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
 static struct omap_hwmod am33xx_dcan0_hwmod = {
 	.name		= "d_can0",
 	.class		= &am33xx_dcan_hwmod_class,
 	.clkdm_name	= "l4ls_clkdm",
-	.mpu_irqs	= am33xx_dcan0_irqs,
 	.main_clk	= "dcan0_fck",
 	.prcm		= {
 		.omap4	= {
@@ -729,17 +529,10 @@ static struct omap_hwmod am33xx_dcan0_hwmod = {
 	},
 };
 
-/* dcan1 */
-static struct omap_hwmod_irq_info am33xx_dcan1_irqs[] = {
-	{ .name = "d_can_ms", .irq = 55 + OMAP_INTC_START, },
-	{ .name = "d_can_mo", .irq = 56 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
 static struct omap_hwmod am33xx_dcan1_hwmod = {
 	.name		= "d_can1",
 	.class		= &am33xx_dcan_hwmod_class,
 	.clkdm_name	= "l4ls_clkdm",
-	.mpu_irqs	= am33xx_dcan1_irqs,
 	.main_clk	= "dcan1_fck",
 	.prcm		= {
 		.omap4	= {
@@ -749,241 +542,6 @@ static struct omap_hwmod am33xx_dcan1_hwmod = {
 	},
 };
 
-/* elm */
-static struct omap_hwmod_class_sysconfig am33xx_elm_sysc = {
-	.rev_offs	= 0x0000,
-	.sysc_offs	= 0x0010,
-	.syss_offs	= 0x0014,
-	.sysc_flags	= (SYSC_HAS_CLOCKACTIVITY | SYSC_HAS_SIDLEMODE |
-			SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE |
-			SYSS_HAS_RESET_STATUS),
-	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
-	.sysc_fields	= &omap_hwmod_sysc_type1,
-};
-
-static struct omap_hwmod_class am33xx_elm_hwmod_class = {
-	.name		= "elm",
-	.sysc		= &am33xx_elm_sysc,
-};
-
-static struct omap_hwmod_irq_info am33xx_elm_irqs[] = {
-	{ .irq = 4 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
-static struct omap_hwmod am33xx_elm_hwmod = {
-	.name		= "elm",
-	.class		= &am33xx_elm_hwmod_class,
-	.clkdm_name	= "l4ls_clkdm",
-	.mpu_irqs	= am33xx_elm_irqs,
-	.main_clk	= "l4ls_gclk",
-	.prcm		= {
-		.omap4	= {
-			.clkctrl_offs	= AM33XX_CM_PER_ELM_CLKCTRL_OFFSET,
-			.modulemode	= MODULEMODE_SWCTRL,
-		},
-	},
-};
-
-/* pwmss  */
-static struct omap_hwmod_class_sysconfig am33xx_epwmss_sysc = {
-	.rev_offs	= 0x0,
-	.sysc_offs	= 0x4,
-	.sysc_flags	= (SYSC_HAS_SIDLEMODE | SYSC_HAS_MIDLEMODE),
-	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
-			SIDLE_SMART_WKUP | MSTANDBY_FORCE | MSTANDBY_NO |
-			MSTANDBY_SMART | MSTANDBY_SMART_WKUP),
-	.sysc_fields	= &omap_hwmod_sysc_type2,
-};
-
-static struct omap_hwmod_class am33xx_epwmss_hwmod_class = {
-	.name		= "epwmss",
-	.sysc		= &am33xx_epwmss_sysc,
-};
-
-static struct omap_hwmod_class am33xx_ecap_hwmod_class = {
-	.name		= "ecap",
-};
-
-static struct omap_hwmod_class am33xx_eqep_hwmod_class = {
-	.name		= "eqep",
-};
-
-static struct omap_hwmod_class am33xx_ehrpwm_hwmod_class = {
-	.name		= "ehrpwm",
-};
-
-/* epwmss0 */
-static struct omap_hwmod am33xx_epwmss0_hwmod = {
-	.name		= "epwmss0",
-	.class		= &am33xx_epwmss_hwmod_class,
-	.clkdm_name	= "l4ls_clkdm",
-	.main_clk	= "l4ls_gclk",
-	.prcm		= {
-		.omap4	= {
-			.clkctrl_offs	= AM33XX_CM_PER_EPWMSS0_CLKCTRL_OFFSET,
-			.modulemode	= MODULEMODE_SWCTRL,
-		},
-	},
-};
-
-/* ecap0 */
-static struct omap_hwmod_irq_info am33xx_ecap0_irqs[] = {
-	{ .irq = 31 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
-static struct omap_hwmod am33xx_ecap0_hwmod = {
-	.name		= "ecap0",
-	.class		= &am33xx_ecap_hwmod_class,
-	.clkdm_name	= "l4ls_clkdm",
-	.mpu_irqs	= am33xx_ecap0_irqs,
-	.main_clk	= "l4ls_gclk",
-};
-
-/* eqep0 */
-static struct omap_hwmod_irq_info am33xx_eqep0_irqs[] = {
-	{ .irq = 79 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
-static struct omap_hwmod am33xx_eqep0_hwmod = {
-	.name		= "eqep0",
-	.class		= &am33xx_eqep_hwmod_class,
-	.clkdm_name	= "l4ls_clkdm",
-	.mpu_irqs	= am33xx_eqep0_irqs,
-	.main_clk	= "l4ls_gclk",
-};
-
-/* ehrpwm0 */
-static struct omap_hwmod_irq_info am33xx_ehrpwm0_irqs[] = {
-	{ .name = "int", .irq = 86 + OMAP_INTC_START, },
-	{ .name = "tzint", .irq = 58 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
-static struct omap_hwmod am33xx_ehrpwm0_hwmod = {
-	.name		= "ehrpwm0",
-	.class		= &am33xx_ehrpwm_hwmod_class,
-	.clkdm_name	= "l4ls_clkdm",
-	.mpu_irqs	= am33xx_ehrpwm0_irqs,
-	.main_clk	= "l4ls_gclk",
-};
-
-/* epwmss1 */
-static struct omap_hwmod am33xx_epwmss1_hwmod = {
-	.name		= "epwmss1",
-	.class		= &am33xx_epwmss_hwmod_class,
-	.clkdm_name	= "l4ls_clkdm",
-	.main_clk	= "l4ls_gclk",
-	.prcm		= {
-		.omap4	= {
-			.clkctrl_offs	= AM33XX_CM_PER_EPWMSS1_CLKCTRL_OFFSET,
-			.modulemode	= MODULEMODE_SWCTRL,
-		},
-	},
-};
-
-/* ecap1 */
-static struct omap_hwmod_irq_info am33xx_ecap1_irqs[] = {
-	{ .irq = 47 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
-static struct omap_hwmod am33xx_ecap1_hwmod = {
-	.name		= "ecap1",
-	.class		= &am33xx_ecap_hwmod_class,
-	.clkdm_name	= "l4ls_clkdm",
-	.mpu_irqs	= am33xx_ecap1_irqs,
-	.main_clk	= "l4ls_gclk",
-};
-
-/* eqep1 */
-static struct omap_hwmod_irq_info am33xx_eqep1_irqs[] = {
-	{ .irq = 88 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
-static struct omap_hwmod am33xx_eqep1_hwmod = {
-	.name		= "eqep1",
-	.class		= &am33xx_eqep_hwmod_class,
-	.clkdm_name	= "l4ls_clkdm",
-	.mpu_irqs	= am33xx_eqep1_irqs,
-	.main_clk	= "l4ls_gclk",
-};
-
-/* ehrpwm1 */
-static struct omap_hwmod_irq_info am33xx_ehrpwm1_irqs[] = {
-	{ .name = "int", .irq = 87 + OMAP_INTC_START, },
-	{ .name = "tzint", .irq = 59 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
-static struct omap_hwmod am33xx_ehrpwm1_hwmod = {
-	.name		= "ehrpwm1",
-	.class		= &am33xx_ehrpwm_hwmod_class,
-	.clkdm_name	= "l4ls_clkdm",
-	.mpu_irqs	= am33xx_ehrpwm1_irqs,
-	.main_clk	= "l4ls_gclk",
-};
-
-/* epwmss2 */
-static struct omap_hwmod am33xx_epwmss2_hwmod = {
-	.name		= "epwmss2",
-	.class		= &am33xx_epwmss_hwmod_class,
-	.clkdm_name	= "l4ls_clkdm",
-	.main_clk	= "l4ls_gclk",
-	.prcm		= {
-		.omap4	= {
-			.clkctrl_offs	= AM33XX_CM_PER_EPWMSS2_CLKCTRL_OFFSET,
-			.modulemode	= MODULEMODE_SWCTRL,
-		},
-	},
-};
-
-/* ecap2 */
-static struct omap_hwmod_irq_info am33xx_ecap2_irqs[] = {
-	{ .irq = 61 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
-static struct omap_hwmod am33xx_ecap2_hwmod = {
-	.name		= "ecap2",
-	.class		= &am33xx_ecap_hwmod_class,
-	.clkdm_name	= "l4ls_clkdm",
-	.mpu_irqs	= am33xx_ecap2_irqs,
-	.main_clk	= "l4ls_gclk",
-};
-
-/* eqep2 */
-static struct omap_hwmod_irq_info am33xx_eqep2_irqs[] = {
-	{ .irq = 89 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
-static struct omap_hwmod am33xx_eqep2_hwmod = {
-	.name		= "eqep2",
-	.class		= &am33xx_eqep_hwmod_class,
-	.clkdm_name	= "l4ls_clkdm",
-	.mpu_irqs	= am33xx_eqep2_irqs,
-	.main_clk	= "l4ls_gclk",
-};
-
-/* ehrpwm2 */
-static struct omap_hwmod_irq_info am33xx_ehrpwm2_irqs[] = {
-	{ .name = "int", .irq = 39 + OMAP_INTC_START, },
-	{ .name = "tzint", .irq = 60 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
-static struct omap_hwmod am33xx_ehrpwm2_hwmod = {
-	.name		= "ehrpwm2",
-	.class		= &am33xx_ehrpwm_hwmod_class,
-	.clkdm_name	= "l4ls_clkdm",
-	.mpu_irqs	= am33xx_ehrpwm2_irqs,
-	.main_clk	= "l4ls_gclk",
-};
-
 /*
  * 'gpio' class: for gpio 0,1,2,3
  */
@@ -1015,17 +573,11 @@ static struct omap_hwmod_opt_clk gpio0_opt_clks[] = {
 	{ .role = "dbclk", .clk = "gpio0_dbclk" },
 };
 
-static struct omap_hwmod_irq_info am33xx_gpio0_irqs[] = {
-	{ .irq = 96 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
 static struct omap_hwmod am33xx_gpio0_hwmod = {
 	.name		= "gpio1",
 	.class		= &am33xx_gpio_hwmod_class,
 	.clkdm_name	= "l4_wkup_clkdm",
 	.flags		= HWMOD_CONTROL_OPT_CLKS_IN_RESET,
-	.mpu_irqs	= am33xx_gpio0_irqs,
 	.main_clk	= "dpll_core_m4_div2_ck",
 	.prcm		= {
 		.omap4	= {
@@ -1039,11 +591,6 @@ static struct omap_hwmod am33xx_gpio0_hwmod = {
 };
 
 /* gpio1 */
-static struct omap_hwmod_irq_info am33xx_gpio1_irqs[] = {
-	{ .irq = 98 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
 static struct omap_hwmod_opt_clk gpio1_opt_clks[] = {
 	{ .role = "dbclk", .clk = "gpio1_dbclk" },
 };
@@ -1053,7 +600,6 @@ static struct omap_hwmod am33xx_gpio1_hwmod = {
 	.class		= &am33xx_gpio_hwmod_class,
 	.clkdm_name	= "l4ls_clkdm",
 	.flags		= HWMOD_CONTROL_OPT_CLKS_IN_RESET,
-	.mpu_irqs	= am33xx_gpio1_irqs,
 	.main_clk	= "l4ls_gclk",
 	.prcm		= {
 		.omap4	= {
@@ -1067,11 +613,6 @@ static struct omap_hwmod am33xx_gpio1_hwmod = {
 };
 
 /* gpio2 */
-static struct omap_hwmod_irq_info am33xx_gpio2_irqs[] = {
-	{ .irq = 32 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
 static struct omap_hwmod_opt_clk gpio2_opt_clks[] = {
 	{ .role = "dbclk", .clk = "gpio2_dbclk" },
 };
@@ -1081,7 +622,6 @@ static struct omap_hwmod am33xx_gpio2_hwmod = {
 	.class		= &am33xx_gpio_hwmod_class,
 	.clkdm_name	= "l4ls_clkdm",
 	.flags		= HWMOD_CONTROL_OPT_CLKS_IN_RESET,
-	.mpu_irqs	= am33xx_gpio2_irqs,
 	.main_clk	= "l4ls_gclk",
 	.prcm		= {
 		.omap4	= {
@@ -1095,11 +635,6 @@ static struct omap_hwmod am33xx_gpio2_hwmod = {
 };
 
 /* gpio3 */
-static struct omap_hwmod_irq_info am33xx_gpio3_irqs[] = {
-	{ .irq = 62 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
 static struct omap_hwmod_opt_clk gpio3_opt_clks[] = {
 	{ .role = "dbclk", .clk = "gpio3_dbclk" },
 };
@@ -1109,7 +644,6 @@ static struct omap_hwmod am33xx_gpio3_hwmod = {
 	.class		= &am33xx_gpio_hwmod_class,
 	.clkdm_name	= "l4ls_clkdm",
 	.flags		= HWMOD_CONTROL_OPT_CLKS_IN_RESET,
-	.mpu_irqs	= am33xx_gpio3_irqs,
 	.main_clk	= "l4ls_gclk",
 	.prcm		= {
 		.omap4	= {
@@ -1122,42 +656,6 @@ static struct omap_hwmod am33xx_gpio3_hwmod = {
 	.dev_attr	= &gpio_dev_attr,
 };
 
-/* gpmc */
-static struct omap_hwmod_class_sysconfig gpmc_sysc = {
-	.rev_offs	= 0x0,
-	.sysc_offs	= 0x10,
-	.syss_offs	= 0x14,
-	.sysc_flags	= (SYSC_HAS_AUTOIDLE | SYSC_HAS_SIDLEMODE |
-			SYSC_HAS_SOFTRESET | SYSS_HAS_RESET_STATUS),
-	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
-	.sysc_fields	= &omap_hwmod_sysc_type1,
-};
-
-static struct omap_hwmod_class am33xx_gpmc_hwmod_class = {
-	.name		= "gpmc",
-	.sysc		= &gpmc_sysc,
-};
-
-static struct omap_hwmod_irq_info am33xx_gpmc_irqs[] = {
-	{ .irq = 100 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
-static struct omap_hwmod am33xx_gpmc_hwmod = {
-	.name		= "gpmc",
-	.class		= &am33xx_gpmc_hwmod_class,
-	.clkdm_name	= "l3s_clkdm",
-	.flags		= (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET),
-	.mpu_irqs	= am33xx_gpmc_irqs,
-	.main_clk	= "l3s_gclk",
-	.prcm		= {
-		.omap4	= {
-			.clkctrl_offs	= AM33XX_CM_PER_GPMC_CLKCTRL_OFFSET,
-			.modulemode	= MODULEMODE_SWCTRL,
-		},
-	},
-};
-
 /* 'i2c' class */
 static struct omap_hwmod_class_sysconfig am33xx_i2c_sysc = {
 	.sysc_offs	= 0x0010,
@@ -1182,23 +680,10 @@ static struct omap_i2c_dev_attr i2c_dev_attr = {
 };
 
 /* i2c1 */
-static struct omap_hwmod_irq_info i2c1_mpu_irqs[] = {
-	{ .irq = 70 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
-static struct omap_hwmod_dma_info i2c1_edma_reqs[] = {
-	{ .name = "tx", .dma_req = 0, },
-	{ .name = "rx", .dma_req = 0, },
-	{ .dma_req = -1 }
-};
-
 static struct omap_hwmod am33xx_i2c1_hwmod = {
 	.name		= "i2c1",
 	.class		= &i2c_class,
 	.clkdm_name	= "l4_wkup_clkdm",
-	.mpu_irqs	= i2c1_mpu_irqs,
-	.sdma_reqs	= i2c1_edma_reqs,
 	.flags		= HWMOD_16BIT_REG | HWMOD_SET_DEFAULT_CLOCKACT,
 	.main_clk	= "dpll_per_m2_div4_wkupdm_ck",
 	.prcm		= {
@@ -1211,23 +696,10 @@ static struct omap_hwmod am33xx_i2c1_hwmod = {
 };
 
 /* i2c1 */
-static struct omap_hwmod_irq_info i2c2_mpu_irqs[] = {
-	{ .irq = 71 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
-static struct omap_hwmod_dma_info i2c2_edma_reqs[] = {
-	{ .name = "tx", .dma_req = 0, },
-	{ .name = "rx", .dma_req = 0, },
-	{ .dma_req = -1 }
-};
-
 static struct omap_hwmod am33xx_i2c2_hwmod = {
 	.name		= "i2c2",
 	.class		= &i2c_class,
 	.clkdm_name	= "l4ls_clkdm",
-	.mpu_irqs	= i2c2_mpu_irqs,
-	.sdma_reqs	= i2c2_edma_reqs,
 	.flags		= HWMOD_16BIT_REG | HWMOD_SET_DEFAULT_CLOCKACT,
 	.main_clk	= "dpll_per_m2_div4_ck",
 	.prcm		= {
@@ -1240,23 +712,10 @@ static struct omap_hwmod am33xx_i2c2_hwmod = {
 };
 
 /* i2c3 */
-static struct omap_hwmod_dma_info i2c3_edma_reqs[] = {
-	{ .name = "tx", .dma_req = 0, },
-	{ .name = "rx", .dma_req = 0, },
-	{ .dma_req = -1 }
-};
-
-static struct omap_hwmod_irq_info i2c3_mpu_irqs[] = {
-	{ .irq = 30 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
 static struct omap_hwmod am33xx_i2c3_hwmod = {
 	.name		= "i2c3",
 	.class		= &i2c_class,
 	.clkdm_name	= "l4ls_clkdm",
-	.mpu_irqs	= i2c3_mpu_irqs,
-	.sdma_reqs	= i2c3_edma_reqs,
 	.flags		= HWMOD_16BIT_REG | HWMOD_SET_DEFAULT_CLOCKACT,
 	.main_clk	= "dpll_per_m2_div4_ck",
 	.prcm		= {
@@ -1268,292 +727,28 @@ static struct omap_hwmod am33xx_i2c3_hwmod = {
 	.dev_attr	= &i2c_dev_attr,
 };
 
-
-/* lcdc */
-static struct omap_hwmod_class_sysconfig lcdc_sysc = {
-	.rev_offs	= 0x0,
-	.sysc_offs	= 0x54,
-	.sysc_flags	= (SYSC_HAS_SIDLEMODE | SYSC_HAS_MIDLEMODE),
-	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
-	.sysc_fields	= &omap_hwmod_sysc_type2,
-};
-
-static struct omap_hwmod_class am33xx_lcdc_hwmod_class = {
-	.name		= "lcdc",
-	.sysc		= &lcdc_sysc,
-};
-
-static struct omap_hwmod_irq_info am33xx_lcdc_irqs[] = {
-	{ .irq = 36 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
-static struct omap_hwmod am33xx_lcdc_hwmod = {
-	.name		= "lcdc",
-	.class		= &am33xx_lcdc_hwmod_class,
-	.clkdm_name	= "lcdc_clkdm",
-	.mpu_irqs	= am33xx_lcdc_irqs,
-	.flags		= HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY,
-	.main_clk	= "lcd_gclk",
-	.prcm		= {
-		.omap4	= {
-			.clkctrl_offs	= AM33XX_CM_PER_LCDC_CLKCTRL_OFFSET,
-			.modulemode	= MODULEMODE_SWCTRL,
-		},
-	},
-};
-
-/*
- * 'mailbox' class
- * mailbox module allowing communication between the on-chip processors using a
- * queued mailbox-interrupt mechanism.
- */
-static struct omap_hwmod_class_sysconfig am33xx_mailbox_sysc = {
-	.rev_offs	= 0x0000,
-	.sysc_offs	= 0x0010,
-	.sysc_flags	= (SYSC_HAS_RESET_STATUS | SYSC_HAS_SIDLEMODE |
-			  SYSC_HAS_SOFTRESET),
-	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
-	.sysc_fields	= &omap_hwmod_sysc_type2,
-};
-
-static struct omap_hwmod_class am33xx_mailbox_hwmod_class = {
-	.name	= "mailbox",
-	.sysc	= &am33xx_mailbox_sysc,
-};
-
-static struct omap_hwmod_irq_info am33xx_mailbox_irqs[] = {
-	{ .irq = 77 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
-static struct omap_hwmod am33xx_mailbox_hwmod = {
-	.name		= "mailbox",
-	.class		= &am33xx_mailbox_hwmod_class,
-	.clkdm_name	= "l4ls_clkdm",
-	.mpu_irqs	= am33xx_mailbox_irqs,
-	.main_clk	= "l4ls_gclk",
-	.prcm = {
-		.omap4 = {
-			.clkctrl_offs	= AM33XX_CM_PER_MAILBOX0_CLKCTRL_OFFSET,
-			.modulemode	= MODULEMODE_SWCTRL,
-		},
-	},
-};
-
-/*
- * 'mcasp' class
- */
-static struct omap_hwmod_class_sysconfig am33xx_mcasp_sysc = {
-	.rev_offs	= 0x0,
-	.sysc_offs	= 0x4,
-	.sysc_flags	= SYSC_HAS_SIDLEMODE,
-	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
-	.sysc_fields	= &omap_hwmod_sysc_type3,
-};
-
-static struct omap_hwmod_class am33xx_mcasp_hwmod_class = {
-	.name		= "mcasp",
-	.sysc		= &am33xx_mcasp_sysc,
-};
-
-/* mcasp0 */
-static struct omap_hwmod_irq_info am33xx_mcasp0_irqs[] = {
-	{ .name = "ax", .irq = 80 + OMAP_INTC_START, },
-	{ .name = "ar", .irq = 81 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
-static struct omap_hwmod_dma_info am33xx_mcasp0_edma_reqs[] = {
-	{ .name = "tx", .dma_req = 8, },
-	{ .name = "rx", .dma_req = 9, },
-	{ .dma_req = -1 }
-};
-
-static struct omap_hwmod am33xx_mcasp0_hwmod = {
-	.name		= "mcasp0",
-	.class		= &am33xx_mcasp_hwmod_class,
-	.clkdm_name	= "l3s_clkdm",
-	.mpu_irqs	= am33xx_mcasp0_irqs,
-	.sdma_reqs	= am33xx_mcasp0_edma_reqs,
-	.main_clk	= "mcasp0_fck",
-	.prcm		= {
-		.omap4	= {
-			.clkctrl_offs	= AM33XX_CM_PER_MCASP0_CLKCTRL_OFFSET,
-			.modulemode	= MODULEMODE_SWCTRL,
-		},
-	},
-};
-
-/* mcasp1 */
-static struct omap_hwmod_irq_info am33xx_mcasp1_irqs[] = {
-	{ .name = "ax", .irq = 82 + OMAP_INTC_START, },
-	{ .name = "ar", .irq = 83 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
-static struct omap_hwmod_dma_info am33xx_mcasp1_edma_reqs[] = {
-	{ .name = "tx", .dma_req = 10, },
-	{ .name = "rx", .dma_req = 11, },
-	{ .dma_req = -1 }
-};
-
-static struct omap_hwmod am33xx_mcasp1_hwmod = {
-	.name		= "mcasp1",
-	.class		= &am33xx_mcasp_hwmod_class,
-	.clkdm_name	= "l3s_clkdm",
-	.mpu_irqs	= am33xx_mcasp1_irqs,
-	.sdma_reqs	= am33xx_mcasp1_edma_reqs,
-	.main_clk	= "mcasp1_fck",
-	.prcm		= {
-		.omap4	= {
-			.clkctrl_offs	= AM33XX_CM_PER_MCASP1_CLKCTRL_OFFSET,
-			.modulemode	= MODULEMODE_SWCTRL,
-		},
-	},
-};
-
-/* 'mmc' class */
-static struct omap_hwmod_class_sysconfig am33xx_mmc_sysc = {
-	.rev_offs	= 0x1fc,
-	.sysc_offs	= 0x10,
-	.syss_offs	= 0x14,
-	.sysc_flags	= (SYSC_HAS_CLOCKACTIVITY | SYSC_HAS_SIDLEMODE |
-			  SYSC_HAS_ENAWAKEUP | SYSC_HAS_SOFTRESET |
-			  SYSC_HAS_AUTOIDLE | SYSS_HAS_RESET_STATUS),
-	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
-	.sysc_fields	= &omap_hwmod_sysc_type1,
-};
-
-static struct omap_hwmod_class am33xx_mmc_hwmod_class = {
-	.name		= "mmc",
-	.sysc		= &am33xx_mmc_sysc,
-};
-
-/* mmc0 */
-static struct omap_hwmod_irq_info am33xx_mmc0_irqs[] = {
-	{ .irq = 64 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
-static struct omap_hwmod_dma_info am33xx_mmc0_edma_reqs[] = {
-	{ .name = "tx", .dma_req = 24, },
-	{ .name = "rx", .dma_req = 25, },
-	{ .dma_req = -1 }
-};
-
-static struct omap_mmc_dev_attr am33xx_mmc0_dev_attr = {
-	.flags		= OMAP_HSMMC_SUPPORTS_DUAL_VOLT,
-};
-
-static struct omap_hwmod am33xx_mmc0_hwmod = {
-	.name		= "mmc1",
-	.class		= &am33xx_mmc_hwmod_class,
-	.clkdm_name	= "l4ls_clkdm",
-	.mpu_irqs	= am33xx_mmc0_irqs,
-	.sdma_reqs	= am33xx_mmc0_edma_reqs,
-	.main_clk	= "mmc_clk",
-	.prcm		= {
-		.omap4	= {
-			.clkctrl_offs	= AM33XX_CM_PER_MMC0_CLKCTRL_OFFSET,
-			.modulemode	= MODULEMODE_SWCTRL,
-		},
-	},
-	.dev_attr	= &am33xx_mmc0_dev_attr,
-};
-
-/* mmc1 */
-static struct omap_hwmod_irq_info am33xx_mmc1_irqs[] = {
-	{ .irq = 28 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
-static struct omap_hwmod_dma_info am33xx_mmc1_edma_reqs[] = {
-	{ .name = "tx", .dma_req = 2, },
-	{ .name = "rx", .dma_req = 3, },
-	{ .dma_req = -1 }
-};
-
-static struct omap_mmc_dev_attr am33xx_mmc1_dev_attr = {
-	.flags		= OMAP_HSMMC_SUPPORTS_DUAL_VOLT,
-};
-
-static struct omap_hwmod am33xx_mmc1_hwmod = {
-	.name		= "mmc2",
-	.class		= &am33xx_mmc_hwmod_class,
-	.clkdm_name	= "l4ls_clkdm",
-	.mpu_irqs	= am33xx_mmc1_irqs,
-	.sdma_reqs	= am33xx_mmc1_edma_reqs,
-	.main_clk	= "mmc_clk",
-	.prcm		= {
-		.omap4	= {
-			.clkctrl_offs	= AM33XX_CM_PER_MMC1_CLKCTRL_OFFSET,
-			.modulemode	= MODULEMODE_SWCTRL,
-		},
-	},
-	.dev_attr	= &am33xx_mmc1_dev_attr,
-};
-
-/* mmc2 */
-static struct omap_hwmod_irq_info am33xx_mmc2_irqs[] = {
-	{ .irq = 29 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
-static struct omap_hwmod_dma_info am33xx_mmc2_edma_reqs[] = {
-	{ .name = "tx", .dma_req = 64, },
-	{ .name = "rx", .dma_req = 65, },
-	{ .dma_req = -1 }
-};
-
-static struct omap_mmc_dev_attr am33xx_mmc2_dev_attr = {
-	.flags		= OMAP_HSMMC_SUPPORTS_DUAL_VOLT,
-};
-static struct omap_hwmod am33xx_mmc2_hwmod = {
-	.name		= "mmc3",
-	.class		= &am33xx_mmc_hwmod_class,
-	.clkdm_name	= "l3s_clkdm",
-	.mpu_irqs	= am33xx_mmc2_irqs,
-	.sdma_reqs	= am33xx_mmc2_edma_reqs,
-	.main_clk	= "mmc_clk",
-	.prcm		= {
-		.omap4	= {
-			.clkctrl_offs	= AM33XX_CM_PER_MMC2_CLKCTRL_OFFSET,
-			.modulemode	= MODULEMODE_SWCTRL,
-		},
-	},
-	.dev_attr	= &am33xx_mmc2_dev_attr,
-};
-
-/*
- * 'rtc' class
- * rtc subsystem
- */
-static struct omap_hwmod_class_sysconfig am33xx_rtc_sysc = {
-	.rev_offs	= 0x0074,
-	.sysc_offs	= 0x0078,
-	.sysc_flags	= SYSC_HAS_SIDLEMODE,
-	.idlemodes	= (SIDLE_FORCE | SIDLE_NO |
-			  SIDLE_SMART | SIDLE_SMART_WKUP),
-	.sysc_fields	= &omap_hwmod_sysc_type3,
-};
+/*
+ * 'rtc' class
+ * rtc subsystem
+ */
+static struct omap_hwmod_class_sysconfig am33xx_rtc_sysc = {
+	.rev_offs	= 0x0074,
+	.sysc_offs	= 0x0078,
+	.sysc_flags	= SYSC_HAS_SIDLEMODE,
+	.idlemodes	= (SIDLE_FORCE | SIDLE_NO |
+			  SIDLE_SMART | SIDLE_SMART_WKUP),
+	.sysc_fields	= &omap_hwmod_sysc_type3,
+};
 
 static struct omap_hwmod_class am33xx_rtc_hwmod_class = {
 	.name		= "rtc",
 	.sysc		= &am33xx_rtc_sysc,
 };
 
-static struct omap_hwmod_irq_info am33xx_rtc_irqs[] = {
-	{ .name = "rtcint", .irq = 75 + OMAP_INTC_START, },
-	{ .name = "rtcalarmint", .irq = 76 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
 static struct omap_hwmod am33xx_rtc_hwmod = {
 	.name		= "rtc",
 	.class		= &am33xx_rtc_hwmod_class,
 	.clkdm_name	= "l4_rtc_clkdm",
-	.mpu_irqs	= am33xx_rtc_irqs,
 	.main_clk	= "clk_32768_ck",
 	.prcm		= {
 		.omap4	= {
@@ -1582,19 +777,6 @@ static struct omap_hwmod_class am33xx_spi_hwmod_class = {
 };
 
 /* spi0 */
-static struct omap_hwmod_irq_info am33xx_spi0_irqs[] = {
-	{ .irq = 65 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
-static struct omap_hwmod_dma_info am33xx_mcspi0_edma_reqs[] = {
-	{ .name = "rx0", .dma_req = 17 },
-	{ .name = "tx0", .dma_req = 16 },
-	{ .name = "rx1", .dma_req = 19 },
-	{ .name = "tx1", .dma_req = 18 },
-	{ .dma_req = -1 }
-};
-
 static struct omap2_mcspi_dev_attr mcspi_attrib = {
 	.num_chipselect	= 2,
 };
@@ -1602,8 +784,6 @@ static struct omap_hwmod am33xx_spi0_hwmod = {
 	.name		= "spi0",
 	.class		= &am33xx_spi_hwmod_class,
 	.clkdm_name	= "l4ls_clkdm",
-	.mpu_irqs	= am33xx_spi0_irqs,
-	.sdma_reqs	= am33xx_mcspi0_edma_reqs,
 	.main_clk	= "dpll_per_m2_div4_ck",
 	.prcm		= {
 		.omap4	= {
@@ -1615,25 +795,10 @@ static struct omap_hwmod am33xx_spi0_hwmod = {
 };
 
 /* spi1 */
-static struct omap_hwmod_irq_info am33xx_spi1_irqs[] = {
-	{ .irq = 125 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
-static struct omap_hwmod_dma_info am33xx_mcspi1_edma_reqs[] = {
-	{ .name = "rx0", .dma_req = 43 },
-	{ .name = "tx0", .dma_req = 42 },
-	{ .name = "rx1", .dma_req = 45 },
-	{ .name = "tx1", .dma_req = 44 },
-	{ .dma_req = -1 }
-};
-
 static struct omap_hwmod am33xx_spi1_hwmod = {
 	.name		= "spi1",
 	.class		= &am33xx_spi_hwmod_class,
 	.clkdm_name	= "l4ls_clkdm",
-	.mpu_irqs	= am33xx_spi1_irqs,
-	.sdma_reqs	= am33xx_mcspi1_edma_reqs,
 	.main_clk	= "dpll_per_m2_div4_ck",
 	.prcm		= {
 		.omap4	= {
@@ -1699,16 +864,10 @@ static struct omap_hwmod_class am33xx_timer1ms_hwmod_class = {
 	.sysc		= &am33xx_timer1ms_sysc,
 };
 
-static struct omap_hwmod_irq_info am33xx_timer1_irqs[] = {
-	{ .irq = 67 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
 static struct omap_hwmod am33xx_timer1_hwmod = {
 	.name		= "timer1",
 	.class		= &am33xx_timer1ms_hwmod_class,
 	.clkdm_name	= "l4_wkup_clkdm",
-	.mpu_irqs	= am33xx_timer1_irqs,
 	.main_clk	= "timer1_fck",
 	.prcm		= {
 		.omap4	= {
@@ -1718,16 +877,10 @@ static struct omap_hwmod am33xx_timer1_hwmod = {
 	},
 };
 
-static struct omap_hwmod_irq_info am33xx_timer2_irqs[] = {
-	{ .irq = 68 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
 static struct omap_hwmod am33xx_timer2_hwmod = {
 	.name		= "timer2",
 	.class		= &am33xx_timer_hwmod_class,
 	.clkdm_name	= "l4ls_clkdm",
-	.mpu_irqs	= am33xx_timer2_irqs,
 	.main_clk	= "timer2_fck",
 	.prcm		= {
 		.omap4	= {
@@ -1737,16 +890,10 @@ static struct omap_hwmod am33xx_timer2_hwmod = {
 	},
 };
 
-static struct omap_hwmod_irq_info am33xx_timer3_irqs[] = {
-	{ .irq = 69 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
 static struct omap_hwmod am33xx_timer3_hwmod = {
 	.name		= "timer3",
 	.class		= &am33xx_timer_hwmod_class,
 	.clkdm_name	= "l4ls_clkdm",
-	.mpu_irqs	= am33xx_timer3_irqs,
 	.main_clk	= "timer3_fck",
 	.prcm		= {
 		.omap4	= {
@@ -1756,16 +903,10 @@ static struct omap_hwmod am33xx_timer3_hwmod = {
 	},
 };
 
-static struct omap_hwmod_irq_info am33xx_timer4_irqs[] = {
-	{ .irq = 92 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
 static struct omap_hwmod am33xx_timer4_hwmod = {
 	.name		= "timer4",
 	.class		= &am33xx_timer_hwmod_class,
 	.clkdm_name	= "l4ls_clkdm",
-	.mpu_irqs	= am33xx_timer4_irqs,
 	.main_clk	= "timer4_fck",
 	.prcm		= {
 		.omap4	= {
@@ -1775,16 +916,10 @@ static struct omap_hwmod am33xx_timer4_hwmod = {
 	},
 };
 
-static struct omap_hwmod_irq_info am33xx_timer5_irqs[] = {
-	{ .irq = 93 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
 static struct omap_hwmod am33xx_timer5_hwmod = {
 	.name		= "timer5",
 	.class		= &am33xx_timer_hwmod_class,
 	.clkdm_name	= "l4ls_clkdm",
-	.mpu_irqs	= am33xx_timer5_irqs,
 	.main_clk	= "timer5_fck",
 	.prcm		= {
 		.omap4	= {
@@ -1794,16 +929,10 @@ static struct omap_hwmod am33xx_timer5_hwmod = {
 	},
 };
 
-static struct omap_hwmod_irq_info am33xx_timer6_irqs[] = {
-	{ .irq = 94 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
 static struct omap_hwmod am33xx_timer6_hwmod = {
 	.name		= "timer6",
 	.class		= &am33xx_timer_hwmod_class,
 	.clkdm_name	= "l4ls_clkdm",
-	.mpu_irqs	= am33xx_timer6_irqs,
 	.main_clk	= "timer6_fck",
 	.prcm		= {
 		.omap4	= {
@@ -1813,16 +942,10 @@ static struct omap_hwmod am33xx_timer6_hwmod = {
 	},
 };
 
-static struct omap_hwmod_irq_info am33xx_timer7_irqs[] = {
-	{ .irq = 95 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
 static struct omap_hwmod am33xx_timer7_hwmod = {
 	.name		= "timer7",
 	.class		= &am33xx_timer_hwmod_class,
 	.clkdm_name	= "l4ls_clkdm",
-	.mpu_irqs	= am33xx_timer7_irqs,
 	.main_clk	= "timer7_fck",
 	.prcm		= {
 		.omap4	= {
@@ -1837,18 +960,10 @@ static struct omap_hwmod_class am33xx_tpcc_hwmod_class = {
 	.name		= "tpcc",
 };
 
-static struct omap_hwmod_irq_info am33xx_tpcc_irqs[] = {
-	{ .name	= "edma0", .irq = 12 + OMAP_INTC_START, },
-	{ .name = "edma0_mperr", .irq = 13 + OMAP_INTC_START, },
-	{ .name	= "edma0_err", .irq = 14 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
 static struct omap_hwmod am33xx_tpcc_hwmod = {
 	.name		= "tpcc",
 	.class		= &am33xx_tpcc_hwmod_class,
 	.clkdm_name	= "l3_clkdm",
-	.mpu_irqs	= am33xx_tpcc_irqs,
 	.main_clk	= "l3_gclk",
 	.prcm		= {
 		.omap4	= {
@@ -1858,84 +973,6 @@ static struct omap_hwmod am33xx_tpcc_hwmod = {
 	},
 };
 
-static struct omap_hwmod_class_sysconfig am33xx_tptc_sysc = {
-	.rev_offs	= 0x0,
-	.sysc_offs	= 0x10,
-	.sysc_flags	= (SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET |
-			  SYSC_HAS_MIDLEMODE),
-	.idlemodes	= (SIDLE_FORCE | SIDLE_SMART | MSTANDBY_FORCE),
-	.sysc_fields	= &omap_hwmod_sysc_type2,
-};
-
-/* 'tptc' class */
-static struct omap_hwmod_class am33xx_tptc_hwmod_class = {
-	.name		= "tptc",
-	.sysc		= &am33xx_tptc_sysc,
-};
-
-/* tptc0 */
-static struct omap_hwmod_irq_info am33xx_tptc0_irqs[] = {
-	{ .irq = 112 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
-static struct omap_hwmod am33xx_tptc0_hwmod = {
-	.name		= "tptc0",
-	.class		= &am33xx_tptc_hwmod_class,
-	.clkdm_name	= "l3_clkdm",
-	.mpu_irqs	= am33xx_tptc0_irqs,
-	.flags		= HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY,
-	.main_clk	= "l3_gclk",
-	.prcm		= {
-		.omap4	= {
-			.clkctrl_offs	= AM33XX_CM_PER_TPTC0_CLKCTRL_OFFSET,
-			.modulemode	= MODULEMODE_SWCTRL,
-		},
-	},
-};
-
-/* tptc1 */
-static struct omap_hwmod_irq_info am33xx_tptc1_irqs[] = {
-	{ .irq = 113 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
-static struct omap_hwmod am33xx_tptc1_hwmod = {
-	.name		= "tptc1",
-	.class		= &am33xx_tptc_hwmod_class,
-	.clkdm_name	= "l3_clkdm",
-	.mpu_irqs	= am33xx_tptc1_irqs,
-	.flags		= (HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY),
-	.main_clk	= "l3_gclk",
-	.prcm		= {
-		.omap4	= {
-			.clkctrl_offs	= AM33XX_CM_PER_TPTC1_CLKCTRL_OFFSET,
-			.modulemode	= MODULEMODE_SWCTRL,
-		},
-	},
-};
-
-/* tptc2 */
-static struct omap_hwmod_irq_info am33xx_tptc2_irqs[] = {
-	{ .irq = 114 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
-static struct omap_hwmod am33xx_tptc2_hwmod = {
-	.name		= "tptc2",
-	.class		= &am33xx_tptc_hwmod_class,
-	.clkdm_name	= "l3_clkdm",
-	.mpu_irqs	= am33xx_tptc2_irqs,
-	.flags		= (HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY),
-	.main_clk	= "l3_gclk",
-	.prcm		= {
-		.omap4	= {
-			.clkctrl_offs	= AM33XX_CM_PER_TPTC2_CLKCTRL_OFFSET,
-			.modulemode	= MODULEMODE_SWCTRL,
-		},
-	},
-};
-
 /* 'uart' class */
 static struct omap_hwmod_class_sysconfig uart_sysc = {
 	.rev_offs	= 0x50,
@@ -1954,23 +991,10 @@ static struct omap_hwmod_class uart_class = {
 };
 
 /* uart1 */
-static struct omap_hwmod_dma_info uart1_edma_reqs[] = {
-	{ .name = "tx",	.dma_req = 26, },
-	{ .name = "rx",	.dma_req = 27, },
-	{ .dma_req = -1 }
-};
-
-static struct omap_hwmod_irq_info am33xx_uart1_irqs[] = {
-	{ .irq = 72 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
 static struct omap_hwmod am33xx_uart1_hwmod = {
 	.name		= "uart1",
 	.class		= &uart_class,
 	.clkdm_name	= "l4_wkup_clkdm",
-	.mpu_irqs	= am33xx_uart1_irqs,
-	.sdma_reqs	= uart1_edma_reqs,
 	.main_clk	= "dpll_per_m2_div4_wkupdm_ck",
 	.prcm		= {
 		.omap4	= {
@@ -1980,17 +1004,10 @@ static struct omap_hwmod am33xx_uart1_hwmod = {
 	},
 };
 
-static struct omap_hwmod_irq_info am33xx_uart2_irqs[] = {
-	{ .irq = 73 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
 static struct omap_hwmod am33xx_uart2_hwmod = {
 	.name		= "uart2",
 	.class		= &uart_class,
 	.clkdm_name	= "l4ls_clkdm",
-	.mpu_irqs	= am33xx_uart2_irqs,
-	.sdma_reqs	= uart1_edma_reqs,
 	.main_clk	= "dpll_per_m2_div4_ck",
 	.prcm		= {
 		.omap4	= {
@@ -2001,23 +1018,10 @@ static struct omap_hwmod am33xx_uart2_hwmod = {
 };
 
 /* uart3 */
-static struct omap_hwmod_dma_info uart3_edma_reqs[] = {
-	{ .name = "tx",	.dma_req = 30, },
-	{ .name = "rx",	.dma_req = 31, },
-	{ .dma_req = -1 }
-};
-
-static struct omap_hwmod_irq_info am33xx_uart3_irqs[] = {
-	{ .irq = 74 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
 static struct omap_hwmod am33xx_uart3_hwmod = {
 	.name		= "uart3",
 	.class		= &uart_class,
 	.clkdm_name	= "l4ls_clkdm",
-	.mpu_irqs	= am33xx_uart3_irqs,
-	.sdma_reqs	= uart3_edma_reqs,
 	.main_clk	= "dpll_per_m2_div4_ck",
 	.prcm		= {
 		.omap4	= {
@@ -2027,17 +1031,10 @@ static struct omap_hwmod am33xx_uart3_hwmod = {
 	},
 };
 
-static struct omap_hwmod_irq_info am33xx_uart4_irqs[] = {
-	{ .irq = 44 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
 static struct omap_hwmod am33xx_uart4_hwmod = {
 	.name		= "uart4",
 	.class		= &uart_class,
 	.clkdm_name	= "l4ls_clkdm",
-	.mpu_irqs	= am33xx_uart4_irqs,
-	.sdma_reqs	= uart1_edma_reqs,
 	.main_clk	= "dpll_per_m2_div4_ck",
 	.prcm		= {
 		.omap4	= {
@@ -2047,17 +1044,10 @@ static struct omap_hwmod am33xx_uart4_hwmod = {
 	},
 };
 
-static struct omap_hwmod_irq_info am33xx_uart5_irqs[] = {
-	{ .irq = 45 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
 static struct omap_hwmod am33xx_uart5_hwmod = {
 	.name		= "uart5",
 	.class		= &uart_class,
 	.clkdm_name	= "l4ls_clkdm",
-	.mpu_irqs	= am33xx_uart5_irqs,
-	.sdma_reqs	= uart1_edma_reqs,
 	.main_clk	= "dpll_per_m2_div4_ck",
 	.prcm		= {
 		.omap4	= {
@@ -2067,17 +1057,10 @@ static struct omap_hwmod am33xx_uart5_hwmod = {
 	},
 };
 
-static struct omap_hwmod_irq_info am33xx_uart6_irqs[] = {
-	{ .irq = 46 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
 static struct omap_hwmod am33xx_uart6_hwmod = {
 	.name		= "uart6",
 	.class		= &uart_class,
 	.clkdm_name	= "l4ls_clkdm",
-	.mpu_irqs	= am33xx_uart6_irqs,
-	.sdma_reqs	= uart1_edma_reqs,
 	.main_clk	= "dpll_per_m2_div4_ck",
 	.prcm		= {
 		.omap4	= {
@@ -2123,7 +1106,7 @@ static struct omap_hwmod am33xx_wd_timer1_hwmod = {
 	},
 };
 
-/*
+ /*
  * 'usb_otg' class
  * high-speed on-the-go universal serial bus (usb_otg) controller
  */
@@ -2141,18 +1124,10 @@ static struct omap_hwmod_class am33xx_usbotg_class = {
 	.sysc		= &am33xx_usbhsotg_sysc,
 };
 
-static struct omap_hwmod_irq_info am33xx_usbss_mpu_irqs[] = {
-	{ .name = "usbss-irq", .irq = 17 + OMAP_INTC_START, },
-	{ .name = "musb0-irq", .irq = 18 + OMAP_INTC_START, },
-	{ .name = "musb1-irq", .irq = 19 + OMAP_INTC_START, },
-	{ .irq = -1, },
-};
-
 static struct omap_hwmod am33xx_usbss_hwmod = {
 	.name		= "usb_otg_hs",
 	.class		= &am33xx_usbotg_class,
 	.clkdm_name	= "l3s_clkdm",
-	.mpu_irqs	= am33xx_usbss_mpu_irqs,
 	.flags		= HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY,
 	.main_clk	= "usbotg_fck",
 	.prcm		= {
@@ -2163,36 +1138,9 @@ static struct omap_hwmod am33xx_usbss_hwmod = {
 	},
 };
 
-
 /*
  * Interfaces
  */
-
-/* l4 fw -> emif fw */
-static struct omap_hwmod_ocp_if am33xx_l4_fw__emif_fw = {
-	.master		= &am33xx_l4_fw_hwmod,
-	.slave		= &am33xx_emif_fw_hwmod,
-	.clk		= "l4fw_gclk",
-	.user		= OCP_USER_MPU,
-};
-
-static struct omap_hwmod_addr_space am33xx_emif_addrs[] = {
-	{
-		.pa_start	= 0x4c000000,
-		.pa_end		= 0x4c000fff,
-		.flags		= ADDR_TYPE_RT
-	},
-	{ }
-};
-/* l3 main -> emif */
-static struct omap_hwmod_ocp_if am33xx_l3_main__emif = {
-	.master		= &am33xx_l3_main_hwmod,
-	.slave		= &am33xx_emif_hwmod,
-	.clk		= "dpll_core_m4_ck",
-	.addr		= am33xx_emif_addrs,
-	.user		= OCP_USER_MPU | OCP_USER_SDMA,
-};
-
 /* mpu -> l3 main */
 static struct omap_hwmod_ocp_if am33xx_mpu__l3_main = {
 	.master		= &am33xx_mpu_hwmod,
@@ -2233,14 +1181,6 @@ static struct omap_hwmod_ocp_if am33xx_l3_s__l4_wkup = {
 	.user		= OCP_USER_MPU | OCP_USER_SDMA,
 };
 
-/* l3 s -> l4 fw */
-static struct omap_hwmod_ocp_if am33xx_l3_s__l4_fw = {
-	.master		= &am33xx_l3_s_hwmod,
-	.slave		= &am33xx_l4_fw_hwmod,
-	.clk		= "l3s_gclk",
-	.user		= OCP_USER_MPU | OCP_USER_SDMA,
-};
-
 /* l3 main -> l3 instr */
 static struct omap_hwmod_ocp_if am33xx_l3_main__l3_instr = {
 	.master		= &am33xx_l3_main_hwmod,
@@ -2290,1154 +1230,277 @@ static struct omap_hwmod_ocp_if am33xx_gfx__l3_main = {
 };
 
 /* l4 wkup -> wkup m3 */
-static struct omap_hwmod_addr_space am33xx_wkup_m3_addrs[] = {
-	{
-		.name		= "umem",
-		.pa_start	= 0x44d00000,
-		.pa_end		= 0x44d00000 + SZ_16K - 1,
-		.flags		= ADDR_TYPE_RT
-	},
-	{
-		.name		= "dmem",
-		.pa_start	= 0x44d80000,
-		.pa_end		= 0x44d80000 + SZ_8K - 1,
-		.flags		= ADDR_TYPE_RT
-	},
-	{ }
-};
-
 static struct omap_hwmod_ocp_if am33xx_l4_wkup__wkup_m3 = {
 	.master		= &am33xx_l4_wkup_hwmod,
 	.slave		= &am33xx_wkup_m3_hwmod,
 	.clk		= "dpll_core_m4_div2_ck",
-	.addr		= am33xx_wkup_m3_addrs,
 	.user		= OCP_USER_MPU | OCP_USER_SDMA,
 };
 
 /* l4 hs -> pru-icss */
-static struct omap_hwmod_addr_space am33xx_pruss_addrs[] = {
-	{
-		.pa_start	= 0x4a300000,
-		.pa_end		= 0x4a300000 + SZ_512K - 1,
-		.flags		= ADDR_TYPE_RT
-	},
-	{ }
-};
-
 static struct omap_hwmod_ocp_if am33xx_l4_hs__pruss = {
 	.master		= &am33xx_l4_hs_hwmod,
 	.slave		= &am33xx_pruss_hwmod,
 	.clk		= "dpll_core_m4_ck",
-	.addr		= am33xx_pruss_addrs,
 	.user		= OCP_USER_MPU | OCP_USER_SDMA,
 };
 
 /* l3 main -> gfx */
-static struct omap_hwmod_addr_space am33xx_gfx_addrs[] = {
-	{
-		.pa_start	= 0x56000000,
-		.pa_end		= 0x56000000 + SZ_16M - 1,
-		.flags		= ADDR_TYPE_RT
-	},
-	{ }
-};
-
 static struct omap_hwmod_ocp_if am33xx_l3_main__gfx = {
 	.master		= &am33xx_l3_main_hwmod,
 	.slave		= &am33xx_gfx_hwmod,
 	.clk		= "dpll_core_m4_ck",
-	.addr		= am33xx_gfx_addrs,
 	.user		= OCP_USER_MPU | OCP_USER_SDMA,
 };
 
 /* l4 wkup -> smartreflex0 */
-static struct omap_hwmod_addr_space am33xx_smartreflex0_addrs[] = {
-	{
-		.pa_start	= 0x44e37000,
-		.pa_end		= 0x44e37000 + SZ_4K - 1,
-		.flags		= ADDR_TYPE_RT
-	},
-	{ }
-};
-
 static struct omap_hwmod_ocp_if am33xx_l4_wkup__smartreflex0 = {
 	.master		= &am33xx_l4_wkup_hwmod,
 	.slave		= &am33xx_smartreflex0_hwmod,
 	.clk		= "dpll_core_m4_div2_ck",
-	.addr		= am33xx_smartreflex0_addrs,
 	.user		= OCP_USER_MPU,
 };
 
 /* l4 wkup -> smartreflex1 */
-static struct omap_hwmod_addr_space am33xx_smartreflex1_addrs[] = {
-	{
-		.pa_start	= 0x44e39000,
-		.pa_end		= 0x44e39000 + SZ_4K - 1,
-		.flags		= ADDR_TYPE_RT
-	},
-	{ }
-};
-
 static struct omap_hwmod_ocp_if am33xx_l4_wkup__smartreflex1 = {
 	.master		= &am33xx_l4_wkup_hwmod,
 	.slave		= &am33xx_smartreflex1_hwmod,
 	.clk		= "dpll_core_m4_div2_ck",
-	.addr		= am33xx_smartreflex1_addrs,
 	.user		= OCP_USER_MPU,
 };
 
 /* l4 wkup -> control */
-static struct omap_hwmod_addr_space am33xx_control_addrs[] = {
-	{
-		.pa_start	= 0x44e10000,
-		.pa_end		= 0x44e10000 + SZ_8K - 1,
-		.flags		= ADDR_TYPE_RT
-	},
-	{ }
-};
-
 static struct omap_hwmod_ocp_if am33xx_l4_wkup__control = {
 	.master		= &am33xx_l4_wkup_hwmod,
 	.slave		= &am33xx_control_hwmod,
 	.clk		= "dpll_core_m4_div2_ck",
-	.addr		= am33xx_control_addrs,
 	.user		= OCP_USER_MPU,
 };
 
 /* l4 wkup -> rtc */
-static struct omap_hwmod_addr_space am33xx_rtc_addrs[] = {
-	{
-		.pa_start	= 0x44e3e000,
-		.pa_end		= 0x44e3e000 + SZ_4K - 1,
-		.flags		= ADDR_TYPE_RT
-	},
-	{ }
-};
-
 static struct omap_hwmod_ocp_if am33xx_l4_wkup__rtc = {
 	.master		= &am33xx_l4_wkup_hwmod,
 	.slave		= &am33xx_rtc_hwmod,
 	.clk		= "clkdiv32k_ick",
-	.addr		= am33xx_rtc_addrs,
 	.user		= OCP_USER_MPU,
 };
 
 /* l4 per/ls -> DCAN0 */
-static struct omap_hwmod_addr_space am33xx_dcan0_addrs[] = {
-	{
-		.pa_start	= 0x481CC000,
-		.pa_end		= 0x481CC000 + SZ_4K - 1,
-		.flags		= ADDR_TYPE_RT
-	},
-	{ }
-};
-
 static struct omap_hwmod_ocp_if am33xx_l4_per__dcan0 = {
 	.master		= &am33xx_l4_ls_hwmod,
 	.slave		= &am33xx_dcan0_hwmod,
 	.clk		= "l4ls_gclk",
-	.addr		= am33xx_dcan0_addrs,
 	.user		= OCP_USER_MPU | OCP_USER_SDMA,
 };
 
 /* l4 per/ls -> DCAN1 */
-static struct omap_hwmod_addr_space am33xx_dcan1_addrs[] = {
-	{
-		.pa_start	= 0x481D0000,
-		.pa_end		= 0x481D0000 + SZ_4K - 1,
-		.flags		= ADDR_TYPE_RT
-	},
-	{ }
-};
-
 static struct omap_hwmod_ocp_if am33xx_l4_per__dcan1 = {
 	.master		= &am33xx_l4_ls_hwmod,
 	.slave		= &am33xx_dcan1_hwmod,
 	.clk		= "l4ls_gclk",
-	.addr		= am33xx_dcan1_addrs,
 	.user		= OCP_USER_MPU | OCP_USER_SDMA,
 };
 
 /* l4 per/ls -> GPIO2 */
-static struct omap_hwmod_addr_space am33xx_gpio1_addrs[] = {
-	{
-		.pa_start	= 0x4804C000,
-		.pa_end		= 0x4804C000 + SZ_4K - 1,
-		.flags		= ADDR_TYPE_RT,
-	},
-	{ }
-};
-
 static struct omap_hwmod_ocp_if am33xx_l4_per__gpio1 = {
 	.master		= &am33xx_l4_ls_hwmod,
 	.slave		= &am33xx_gpio1_hwmod,
 	.clk		= "l4ls_gclk",
-	.addr		= am33xx_gpio1_addrs,
 	.user		= OCP_USER_MPU | OCP_USER_SDMA,
 };
 
 /* l4 per/ls -> gpio3 */
-static struct omap_hwmod_addr_space am33xx_gpio2_addrs[] = {
-	{
-		.pa_start	= 0x481AC000,
-		.pa_end		= 0x481AC000 + SZ_4K - 1,
-		.flags		= ADDR_TYPE_RT,
-	},
-	{ }
-};
-
 static struct omap_hwmod_ocp_if am33xx_l4_per__gpio2 = {
 	.master		= &am33xx_l4_ls_hwmod,
 	.slave		= &am33xx_gpio2_hwmod,
 	.clk		= "l4ls_gclk",
-	.addr		= am33xx_gpio2_addrs,
 	.user		= OCP_USER_MPU | OCP_USER_SDMA,
 };
 
 /* l4 per/ls -> gpio4 */
-static struct omap_hwmod_addr_space am33xx_gpio3_addrs[] = {
-	{
-		.pa_start	= 0x481AE000,
-		.pa_end		= 0x481AE000 + SZ_4K - 1,
-		.flags		= ADDR_TYPE_RT,
-	},
-	{ }
-};
-
 static struct omap_hwmod_ocp_if am33xx_l4_per__gpio3 = {
 	.master		= &am33xx_l4_ls_hwmod,
 	.slave		= &am33xx_gpio3_hwmod,
 	.clk		= "l4ls_gclk",
-	.addr		= am33xx_gpio3_addrs,
 	.user		= OCP_USER_MPU | OCP_USER_SDMA,
 };
 
-/* L4 WKUP -> I2C1 */
-static struct omap_hwmod_addr_space am33xx_i2c1_addr_space[] = {
-	{
-		.pa_start	= 0x44E0B000,
-		.pa_end		= 0x44E0B000 + SZ_4K - 1,
-		.flags		= ADDR_TYPE_RT,
-	},
-	{ }
-};
-
 static struct omap_hwmod_ocp_if am33xx_l4_wkup__i2c1 = {
 	.master		= &am33xx_l4_wkup_hwmod,
 	.slave		= &am33xx_i2c1_hwmod,
 	.clk		= "dpll_core_m4_div2_ck",
-	.addr		= am33xx_i2c1_addr_space,
 	.user		= OCP_USER_MPU,
 };
 
 /* L4 WKUP -> GPIO1 */
-static struct omap_hwmod_addr_space am33xx_gpio0_addrs[] = {
-	{
-		.pa_start	= 0x44E07000,
-		.pa_end		= 0x44E07000 + SZ_4K - 1,
-		.flags		= ADDR_TYPE_RT,
-	},
-	{ }
-};
-
 static struct omap_hwmod_ocp_if am33xx_l4_wkup__gpio0 = {
 	.master		= &am33xx_l4_wkup_hwmod,
 	.slave		= &am33xx_gpio0_hwmod,
 	.clk		= "dpll_core_m4_div2_ck",
-	.addr		= am33xx_gpio0_addrs,
 	.user		= OCP_USER_MPU | OCP_USER_SDMA,
 };
 
-/* L4 WKUP -> ADC_TSC */
-static struct omap_hwmod_addr_space am33xx_adc_tsc_addrs[] = {
-	{
-		.pa_start	= 0x44E0D000,
-		.pa_end		= 0x44E0D000 + SZ_8K - 1,
-		.flags		= ADDR_TYPE_RT
-	},
-	{ }
-};
-
-static struct omap_hwmod_ocp_if am33xx_l4_wkup__adc_tsc = {
-	.master		= &am33xx_l4_wkup_hwmod,
-	.slave		= &am33xx_adc_tsc_hwmod,
-	.clk		= "dpll_core_m4_div2_ck",
-	.addr		= am33xx_adc_tsc_addrs,
-	.user		= OCP_USER_MPU,
-};
-
-static struct omap_hwmod_addr_space am33xx_cpgmac0_addr_space[] = {
-	/* cpsw ss */
-	{
-		.pa_start	= 0x4a100000,
-		.pa_end		= 0x4a100000 + SZ_2K - 1,
-	},
-	/* cpsw wr */
-	{
-		.pa_start	= 0x4a101200,
-		.pa_end		= 0x4a101200 + SZ_256 - 1,
-		.flags		= ADDR_TYPE_RT,
-	},
-	{ }
-};
-
 static struct omap_hwmod_ocp_if am33xx_l4_hs__cpgmac0 = {
 	.master		= &am33xx_l4_hs_hwmod,
 	.slave		= &am33xx_cpgmac0_hwmod,
 	.clk		= "cpsw_125mhz_gclk",
-	.addr		= am33xx_cpgmac0_addr_space,
 	.user		= OCP_USER_MPU,
 };
 
-static struct omap_hwmod_addr_space am33xx_mdio_addr_space[] = {
-	{
-		.pa_start	= 0x4A101000,
-		.pa_end		= 0x4A101000 + SZ_256 - 1,
-	},
-	{ }
-};
-
 static struct omap_hwmod_ocp_if am33xx_cpgmac0__mdio = {
 	.master		= &am33xx_cpgmac0_hwmod,
 	.slave		= &am33xx_mdio_hwmod,
-	.addr		= am33xx_mdio_addr_space,
-	.user		= OCP_USER_MPU,
-};
-
-static struct omap_hwmod_addr_space am33xx_elm_addr_space[] = {
-	{
-		.pa_start	= 0x48080000,
-		.pa_end		= 0x48080000 + SZ_8K - 1,
-		.flags		= ADDR_TYPE_RT
-	},
-	{ }
-};
-
-static struct omap_hwmod_ocp_if am33xx_l4_ls__elm = {
-	.master		= &am33xx_l4_ls_hwmod,
-	.slave		= &am33xx_elm_hwmod,
-	.clk		= "l4ls_gclk",
-	.addr		= am33xx_elm_addr_space,
-	.user		= OCP_USER_MPU,
-};
-
-static struct omap_hwmod_addr_space am33xx_epwmss0_addr_space[] = {
-	{
-		.pa_start	= 0x48300000,
-		.pa_end		= 0x48300000 + SZ_16 - 1,
-		.flags		= ADDR_TYPE_RT
-	},
-	{ }
-};
-
-static struct omap_hwmod_ocp_if am33xx_l4_ls__epwmss0 = {
-	.master		= &am33xx_l4_ls_hwmod,
-	.slave		= &am33xx_epwmss0_hwmod,
-	.clk		= "l4ls_gclk",
-	.addr		= am33xx_epwmss0_addr_space,
-	.user		= OCP_USER_MPU,
-};
-
-static struct omap_hwmod_addr_space am33xx_ecap0_addr_space[] = {
-	{
-		.pa_start	= 0x48300100,
-		.pa_end		= 0x48300100 + SZ_128 - 1,
-	},
-	{ }
-};
-
-static struct omap_hwmod_ocp_if am33xx_epwmss0__ecap0 = {
-	.master		= &am33xx_epwmss0_hwmod,
-	.slave		= &am33xx_ecap0_hwmod,
-	.clk		= "l4ls_gclk",
-	.addr		= am33xx_ecap0_addr_space,
 	.user		= OCP_USER_MPU,
 };
 
-static struct omap_hwmod_addr_space am33xx_eqep0_addr_space[] = {
-	{
-		.pa_start	= 0x48300180,
-		.pa_end		= 0x48300180 + SZ_128 - 1,
-	},
-	{ }
-};
-
-static struct omap_hwmod_ocp_if am33xx_epwmss0__eqep0 = {
-	.master		= &am33xx_epwmss0_hwmod,
-	.slave		= &am33xx_eqep0_hwmod,
-	.clk		= "l4ls_gclk",
-	.addr		= am33xx_eqep0_addr_space,
-	.user		= OCP_USER_MPU,
-};
-
-static struct omap_hwmod_addr_space am33xx_ehrpwm0_addr_space[] = {
-	{
-		.pa_start	= 0x48300200,
-		.pa_end		= 0x48300200 + SZ_128 - 1,
-	},
-	{ }
-};
-
-static struct omap_hwmod_ocp_if am33xx_epwmss0__ehrpwm0 = {
-	.master		= &am33xx_epwmss0_hwmod,
-	.slave		= &am33xx_ehrpwm0_hwmod,
-	.clk		= "l4ls_gclk",
-	.addr		= am33xx_ehrpwm0_addr_space,
-	.user		= OCP_USER_MPU,
-};
-
-
-static struct omap_hwmod_addr_space am33xx_epwmss1_addr_space[] = {
-	{
-		.pa_start	= 0x48302000,
-		.pa_end		= 0x48302000 + SZ_16 - 1,
-		.flags		= ADDR_TYPE_RT
-	},
-	{ }
-};
-
-static struct omap_hwmod_ocp_if am33xx_l4_ls__epwmss1 = {
-	.master		= &am33xx_l4_ls_hwmod,
-	.slave		= &am33xx_epwmss1_hwmod,
-	.clk		= "l4ls_gclk",
-	.addr		= am33xx_epwmss1_addr_space,
-	.user		= OCP_USER_MPU,
-};
-
-static struct omap_hwmod_addr_space am33xx_ecap1_addr_space[] = {
-	{
-		.pa_start	= 0x48302100,
-		.pa_end		= 0x48302100 + SZ_128 - 1,
-	},
-	{ }
-};
-
-static struct omap_hwmod_ocp_if am33xx_epwmss1__ecap1 = {
-	.master		= &am33xx_epwmss1_hwmod,
-	.slave		= &am33xx_ecap1_hwmod,
-	.clk		= "l4ls_gclk",
-	.addr		= am33xx_ecap1_addr_space,
-	.user		= OCP_USER_MPU,
-};
-
-static struct omap_hwmod_addr_space am33xx_eqep1_addr_space[] = {
-	{
-		.pa_start	= 0x48302180,
-		.pa_end		= 0x48302180 + SZ_128 - 1,
-	},
-	{ }
-};
-
-static struct omap_hwmod_ocp_if am33xx_epwmss1__eqep1 = {
-	.master		= &am33xx_epwmss1_hwmod,
-	.slave		= &am33xx_eqep1_hwmod,
-	.clk		= "l4ls_gclk",
-	.addr		= am33xx_eqep1_addr_space,
-	.user		= OCP_USER_MPU,
-};
-
-static struct omap_hwmod_addr_space am33xx_ehrpwm1_addr_space[] = {
-	{
-		.pa_start	= 0x48302200,
-		.pa_end		= 0x48302200 + SZ_128 - 1,
-	},
-	{ }
-};
-
-static struct omap_hwmod_ocp_if am33xx_epwmss1__ehrpwm1 = {
-	.master		= &am33xx_epwmss1_hwmod,
-	.slave		= &am33xx_ehrpwm1_hwmod,
-	.clk		= "l4ls_gclk",
-	.addr		= am33xx_ehrpwm1_addr_space,
-	.user		= OCP_USER_MPU,
-};
-
-static struct omap_hwmod_addr_space am33xx_epwmss2_addr_space[] = {
-	{
-		.pa_start	= 0x48304000,
-		.pa_end		= 0x48304000 + SZ_16 - 1,
-		.flags		= ADDR_TYPE_RT
-	},
-	{ }
-};
-
-static struct omap_hwmod_ocp_if am33xx_l4_ls__epwmss2 = {
-	.master		= &am33xx_l4_ls_hwmod,
-	.slave		= &am33xx_epwmss2_hwmod,
-	.clk		= "l4ls_gclk",
-	.addr		= am33xx_epwmss2_addr_space,
-	.user		= OCP_USER_MPU,
-};
-
-static struct omap_hwmod_addr_space am33xx_ecap2_addr_space[] = {
-	{
-		.pa_start	= 0x48304100,
-		.pa_end		= 0x48304100 + SZ_128 - 1,
-	},
-	{ }
-};
-
-static struct omap_hwmod_ocp_if am33xx_epwmss2__ecap2 = {
-	.master		= &am33xx_epwmss2_hwmod,
-	.slave		= &am33xx_ecap2_hwmod,
-	.clk		= "l4ls_gclk",
-	.addr		= am33xx_ecap2_addr_space,
-	.user		= OCP_USER_MPU,
-};
-
-static struct omap_hwmod_addr_space am33xx_eqep2_addr_space[] = {
-	{
-		.pa_start	= 0x48304180,
-		.pa_end		= 0x48304180 + SZ_128 - 1,
-	},
-	{ }
-};
-
-static struct omap_hwmod_ocp_if am33xx_epwmss2__eqep2 = {
-	.master		= &am33xx_epwmss2_hwmod,
-	.slave		= &am33xx_eqep2_hwmod,
-	.clk		= "l4ls_gclk",
-	.addr		= am33xx_eqep2_addr_space,
-	.user		= OCP_USER_MPU,
-};
-
-static struct omap_hwmod_addr_space am33xx_ehrpwm2_addr_space[] = {
-	{
-		.pa_start	= 0x48304200,
-		.pa_end		= 0x48304200 + SZ_128 - 1,
-	},
-	{ }
-};
-
-static struct omap_hwmod_ocp_if am33xx_epwmss2__ehrpwm2 = {
-	.master		= &am33xx_epwmss2_hwmod,
-	.slave		= &am33xx_ehrpwm2_hwmod,
-	.clk		= "l4ls_gclk",
-	.addr		= am33xx_ehrpwm2_addr_space,
-	.user		= OCP_USER_MPU,
-};
-
-/* l3s cfg -> gpmc */
-static struct omap_hwmod_addr_space am33xx_gpmc_addr_space[] = {
-	{
-		.pa_start	= 0x50000000,
-		.pa_end		= 0x50000000 + SZ_8K - 1,
-		.flags		= ADDR_TYPE_RT,
-	},
-	{ }
-};
-
-static struct omap_hwmod_ocp_if am33xx_l3_s__gpmc = {
-	.master		= &am33xx_l3_s_hwmod,
-	.slave		= &am33xx_gpmc_hwmod,
-	.clk		= "l3s_gclk",
-	.addr		= am33xx_gpmc_addr_space,
-	.user		= OCP_USER_MPU,
-};
-
-/* i2c2 */
-static struct omap_hwmod_addr_space am33xx_i2c2_addr_space[] = {
-	{
-		.pa_start	= 0x4802A000,
-		.pa_end		= 0x4802A000 + SZ_4K - 1,
-		.flags		= ADDR_TYPE_RT,
-	},
-	{ }
-};
-
 static struct omap_hwmod_ocp_if am33xx_l4_per__i2c2 = {
 	.master		= &am33xx_l4_ls_hwmod,
 	.slave		= &am33xx_i2c2_hwmod,
 	.clk		= "l4ls_gclk",
-	.addr		= am33xx_i2c2_addr_space,
 	.user		= OCP_USER_MPU,
 };
 
-static struct omap_hwmod_addr_space am33xx_i2c3_addr_space[] = {
-	{
-		.pa_start	= 0x4819C000,
-		.pa_end		= 0x4819C000 + SZ_4K - 1,
-		.flags		= ADDR_TYPE_RT
-	},
-	{ }
-};
-
 static struct omap_hwmod_ocp_if am33xx_l4_per__i2c3 = {
 	.master		= &am33xx_l4_ls_hwmod,
 	.slave		= &am33xx_i2c3_hwmod,
 	.clk		= "l4ls_gclk",
-	.addr		= am33xx_i2c3_addr_space,
-	.user		= OCP_USER_MPU,
-};
-
-static struct omap_hwmod_addr_space am33xx_lcdc_addr_space[] = {
-	{
-		.pa_start	= 0x4830E000,
-		.pa_end		= 0x4830E000 + SZ_8K - 1,
-		.flags		= ADDR_TYPE_RT,
-	},
-	{ }
-};
-
-static struct omap_hwmod_ocp_if am33xx_l3_main__lcdc = {
-	.master		= &am33xx_l3_main_hwmod,
-	.slave		= &am33xx_lcdc_hwmod,
-	.clk		= "dpll_core_m4_ck",
-	.addr		= am33xx_lcdc_addr_space,
-	.user		= OCP_USER_MPU,
-};
-
-static struct omap_hwmod_addr_space am33xx_mailbox_addrs[] = {
-	{
-		.pa_start	= 0x480C8000,
-		.pa_end		= 0x480C8000 + (SZ_4K - 1),
-		.flags		= ADDR_TYPE_RT
-	},
-	{ }
-};
-
-/* l4 ls -> mailbox */
-static struct omap_hwmod_ocp_if am33xx_l4_per__mailbox = {
-	.master		= &am33xx_l4_ls_hwmod,
-	.slave		= &am33xx_mailbox_hwmod,
-	.clk		= "l4ls_gclk",
-	.addr		= am33xx_mailbox_addrs,
 	.user		= OCP_USER_MPU,
 };
 
 /* l4 ls -> spinlock */
-static struct omap_hwmod_addr_space am33xx_spinlock_addrs[] = {
-	{
-		.pa_start	= 0x480Ca000,
-		.pa_end		= 0x480Ca000 + SZ_4K - 1,
-		.flags		= ADDR_TYPE_RT
-	},
-	{ }
-};
-
 static struct omap_hwmod_ocp_if am33xx_l4_ls__spinlock = {
 	.master		= &am33xx_l4_ls_hwmod,
 	.slave		= &am33xx_spinlock_hwmod,
 	.clk		= "l4ls_gclk",
-	.addr		= am33xx_spinlock_addrs,
 	.user		= OCP_USER_MPU,
 };
 
-/* l4 ls -> mcasp0 */
-static struct omap_hwmod_addr_space am33xx_mcasp0_addr_space[] = {
-	{
-		.pa_start	= 0x48038000,
-		.pa_end		= 0x48038000 + SZ_8K - 1,
-		.flags		= ADDR_TYPE_RT
-	},
-	{ }
-};
-
-static struct omap_hwmod_ocp_if am33xx_l4_ls__mcasp0 = {
-	.master		= &am33xx_l4_ls_hwmod,
-	.slave		= &am33xx_mcasp0_hwmod,
-	.clk		= "l4ls_gclk",
-	.addr		= am33xx_mcasp0_addr_space,
-	.user		= OCP_USER_MPU,
-};
-
-/* l3 s -> mcasp0 data */
-static struct omap_hwmod_addr_space am33xx_mcasp0_data_addr_space[] = {
-	{
-		.pa_start	= 0x46000000,
-		.pa_end		= 0x46000000 + SZ_4M - 1,
-		.flags		= ADDR_TYPE_RT
-	},
-	{ }
-};
-
-static struct omap_hwmod_ocp_if am33xx_l3_s__mcasp0_data = {
-	.master		= &am33xx_l3_s_hwmod,
-	.slave		= &am33xx_mcasp0_hwmod,
-	.clk		= "l3s_gclk",
-	.addr		= am33xx_mcasp0_data_addr_space,
-	.user		= OCP_USER_SDMA,
-};
-
-/* l4 ls -> mcasp1 */
-static struct omap_hwmod_addr_space am33xx_mcasp1_addr_space[] = {
-	{
-		.pa_start	= 0x4803C000,
-		.pa_end		= 0x4803C000 + SZ_8K - 1,
-		.flags		= ADDR_TYPE_RT
-	},
-	{ }
-};
-
-static struct omap_hwmod_ocp_if am33xx_l4_ls__mcasp1 = {
-	.master		= &am33xx_l4_ls_hwmod,
-	.slave		= &am33xx_mcasp1_hwmod,
-	.clk		= "l4ls_gclk",
-	.addr		= am33xx_mcasp1_addr_space,
-	.user		= OCP_USER_MPU,
-};
-
-/* l3 s -> mcasp1 data */
-static struct omap_hwmod_addr_space am33xx_mcasp1_data_addr_space[] = {
-	{
-		.pa_start	= 0x46400000,
-		.pa_end		= 0x46400000 + SZ_4M - 1,
-		.flags		= ADDR_TYPE_RT
-	},
-	{ }
-};
-
-static struct omap_hwmod_ocp_if am33xx_l3_s__mcasp1_data = {
-	.master		= &am33xx_l3_s_hwmod,
-	.slave		= &am33xx_mcasp1_hwmod,
-	.clk		= "l3s_gclk",
-	.addr		= am33xx_mcasp1_data_addr_space,
-	.user		= OCP_USER_SDMA,
-};
-
-/* l4 ls -> mmc0 */
-static struct omap_hwmod_addr_space am33xx_mmc0_addr_space[] = {
-	{
-		.pa_start	= 0x48060100,
-		.pa_end		= 0x48060100 + SZ_4K - 1,
-		.flags		= ADDR_TYPE_RT,
-	},
-	{ }
-};
-
-static struct omap_hwmod_ocp_if am33xx_l4_ls__mmc0 = {
-	.master		= &am33xx_l4_ls_hwmod,
-	.slave		= &am33xx_mmc0_hwmod,
-	.clk		= "l4ls_gclk",
-	.addr		= am33xx_mmc0_addr_space,
-	.user		= OCP_USER_MPU,
-};
-
-/* l4 ls -> mmc1 */
-static struct omap_hwmod_addr_space am33xx_mmc1_addr_space[] = {
-	{
-		.pa_start	= 0x481d8100,
-		.pa_end		= 0x481d8100 + SZ_4K - 1,
-		.flags		= ADDR_TYPE_RT,
-	},
-	{ }
-};
-
-static struct omap_hwmod_ocp_if am33xx_l4_ls__mmc1 = {
-	.master		= &am33xx_l4_ls_hwmod,
-	.slave		= &am33xx_mmc1_hwmod,
-	.clk		= "l4ls_gclk",
-	.addr		= am33xx_mmc1_addr_space,
-	.user		= OCP_USER_MPU,
-};
-
-/* l3 s -> mmc2 */
-static struct omap_hwmod_addr_space am33xx_mmc2_addr_space[] = {
-	{
-		.pa_start	= 0x47810100,
-		.pa_end		= 0x47810100 + SZ_64K - 1,
-		.flags		= ADDR_TYPE_RT,
-	},
-	{ }
-};
-
-static struct omap_hwmod_ocp_if am33xx_l3_s__mmc2 = {
-	.master		= &am33xx_l3_s_hwmod,
-	.slave		= &am33xx_mmc2_hwmod,
-	.clk		= "l3s_gclk",
-	.addr		= am33xx_mmc2_addr_space,
-	.user		= OCP_USER_MPU,
-};
-
-/* l4 ls -> mcspi0 */
-static struct omap_hwmod_addr_space am33xx_mcspi0_addr_space[] = {
-	{
-		.pa_start	= 0x48030000,
-		.pa_end		= 0x48030000 + SZ_1K - 1,
-		.flags		= ADDR_TYPE_RT,
-	},
-	{ }
-};
-
 static struct omap_hwmod_ocp_if am33xx_l4_ls__mcspi0 = {
 	.master		= &am33xx_l4_ls_hwmod,
 	.slave		= &am33xx_spi0_hwmod,
 	.clk		= "l4ls_gclk",
-	.addr		= am33xx_mcspi0_addr_space,
 	.user		= OCP_USER_MPU,
 };
 
-/* l4 ls -> mcspi1 */
-static struct omap_hwmod_addr_space am33xx_mcspi1_addr_space[] = {
-	{
-		.pa_start	= 0x481A0000,
-		.pa_end		= 0x481A0000 + SZ_1K - 1,
-		.flags		= ADDR_TYPE_RT,
-	},
-	{ }
-};
-
 static struct omap_hwmod_ocp_if am33xx_l4_ls__mcspi1 = {
 	.master		= &am33xx_l4_ls_hwmod,
 	.slave		= &am33xx_spi1_hwmod,
 	.clk		= "l4ls_gclk",
-	.addr		= am33xx_mcspi1_addr_space,
 	.user		= OCP_USER_MPU,
 };
 
-/* l4 wkup -> timer1 */
-static struct omap_hwmod_addr_space am33xx_timer1_addr_space[] = {
-	{
-		.pa_start	= 0x44E31000,
-		.pa_end		= 0x44E31000 + SZ_1K - 1,
-		.flags		= ADDR_TYPE_RT
-	},
-	{ }
-};
-
 static struct omap_hwmod_ocp_if am33xx_l4_wkup__timer1 = {
 	.master		= &am33xx_l4_wkup_hwmod,
 	.slave		= &am33xx_timer1_hwmod,
 	.clk		= "dpll_core_m4_div2_ck",
-	.addr		= am33xx_timer1_addr_space,
 	.user		= OCP_USER_MPU,
 };
 
-/* l4 per -> timer2 */
-static struct omap_hwmod_addr_space am33xx_timer2_addr_space[] = {
-	{
-		.pa_start	= 0x48040000,
-		.pa_end		= 0x48040000 + SZ_1K - 1,
-		.flags		= ADDR_TYPE_RT
-	},
-	{ }
-};
-
 static struct omap_hwmod_ocp_if am33xx_l4_ls__timer2 = {
 	.master		= &am33xx_l4_ls_hwmod,
 	.slave		= &am33xx_timer2_hwmod,
 	.clk		= "l4ls_gclk",
-	.addr		= am33xx_timer2_addr_space,
 	.user		= OCP_USER_MPU,
 };
 
-/* l4 per -> timer3 */
-static struct omap_hwmod_addr_space am33xx_timer3_addr_space[] = {
-	{
-		.pa_start	= 0x48042000,
-		.pa_end		= 0x48042000 + SZ_1K - 1,
-		.flags		= ADDR_TYPE_RT
-	},
-	{ }
-};
-
 static struct omap_hwmod_ocp_if am33xx_l4_ls__timer3 = {
 	.master		= &am33xx_l4_ls_hwmod,
 	.slave		= &am33xx_timer3_hwmod,
 	.clk		= "l4ls_gclk",
-	.addr		= am33xx_timer3_addr_space,
 	.user		= OCP_USER_MPU,
 };
 
-/* l4 per -> timer4 */
-static struct omap_hwmod_addr_space am33xx_timer4_addr_space[] = {
-	{
-		.pa_start	= 0x48044000,
-		.pa_end		= 0x48044000 + SZ_1K - 1,
-		.flags		= ADDR_TYPE_RT
-	},
-	{ }
-};
-
 static struct omap_hwmod_ocp_if am33xx_l4_ls__timer4 = {
 	.master		= &am33xx_l4_ls_hwmod,
 	.slave		= &am33xx_timer4_hwmod,
 	.clk		= "l4ls_gclk",
-	.addr		= am33xx_timer4_addr_space,
 	.user		= OCP_USER_MPU,
 };
 
-/* l4 per -> timer5 */
-static struct omap_hwmod_addr_space am33xx_timer5_addr_space[] = {
-	{
-		.pa_start	= 0x48046000,
-		.pa_end		= 0x48046000 + SZ_1K - 1,
-		.flags		= ADDR_TYPE_RT
-	},
-	{ }
-};
-
 static struct omap_hwmod_ocp_if am33xx_l4_ls__timer5 = {
 	.master		= &am33xx_l4_ls_hwmod,
 	.slave		= &am33xx_timer5_hwmod,
 	.clk		= "l4ls_gclk",
-	.addr		= am33xx_timer5_addr_space,
 	.user		= OCP_USER_MPU,
 };
 
-/* l4 per -> timer6 */
-static struct omap_hwmod_addr_space am33xx_timer6_addr_space[] = {
-	{
-		.pa_start	= 0x48048000,
-		.pa_end		= 0x48048000 + SZ_1K - 1,
-		.flags		= ADDR_TYPE_RT
-	},
-	{ }
-};
-
 static struct omap_hwmod_ocp_if am33xx_l4_ls__timer6 = {
 	.master		= &am33xx_l4_ls_hwmod,
 	.slave		= &am33xx_timer6_hwmod,
 	.clk		= "l4ls_gclk",
-	.addr		= am33xx_timer6_addr_space,
 	.user		= OCP_USER_MPU,
 };
 
-/* l4 per -> timer7 */
-static struct omap_hwmod_addr_space am33xx_timer7_addr_space[] = {
-	{
-		.pa_start	= 0x4804A000,
-		.pa_end		= 0x4804A000 + SZ_1K - 1,
-		.flags		= ADDR_TYPE_RT
-	},
-	{ }
-};
-
 static struct omap_hwmod_ocp_if am33xx_l4_ls__timer7 = {
 	.master		= &am33xx_l4_ls_hwmod,
 	.slave		= &am33xx_timer7_hwmod,
 	.clk		= "l4ls_gclk",
-	.addr		= am33xx_timer7_addr_space,
 	.user		= OCP_USER_MPU,
 };
 
-/* l3 main -> tpcc */
-static struct omap_hwmod_addr_space am33xx_tpcc_addr_space[] = {
-	{
-		.pa_start	= 0x49000000,
-		.pa_end		= 0x49000000 + SZ_32K - 1,
-		.flags		= ADDR_TYPE_RT
-	},
-	{ }
-};
-
 static struct omap_hwmod_ocp_if am33xx_l3_main__tpcc = {
 	.master		= &am33xx_l3_main_hwmod,
 	.slave		= &am33xx_tpcc_hwmod,
 	.clk		= "l3_gclk",
-	.addr		= am33xx_tpcc_addr_space,
-	.user		= OCP_USER_MPU,
-};
-
-/* l3 main -> tpcc0 */
-static struct omap_hwmod_addr_space am33xx_tptc0_addr_space[] = {
-	{
-		.pa_start	= 0x49800000,
-		.pa_end		= 0x49800000 + SZ_8K - 1,
-		.flags		= ADDR_TYPE_RT,
-	},
-	{ }
-};
-
-static struct omap_hwmod_ocp_if am33xx_l3_main__tptc0 = {
-	.master		= &am33xx_l3_main_hwmod,
-	.slave		= &am33xx_tptc0_hwmod,
-	.clk		= "l3_gclk",
-	.addr		= am33xx_tptc0_addr_space,
-	.user		= OCP_USER_MPU,
-};
-
-/* l3 main -> tpcc1 */
-static struct omap_hwmod_addr_space am33xx_tptc1_addr_space[] = {
-	{
-		.pa_start	= 0x49900000,
-		.pa_end		= 0x49900000 + SZ_8K - 1,
-		.flags		= ADDR_TYPE_RT,
-	},
-	{ }
-};
-
-static struct omap_hwmod_ocp_if am33xx_l3_main__tptc1 = {
-	.master		= &am33xx_l3_main_hwmod,
-	.slave		= &am33xx_tptc1_hwmod,
-	.clk		= "l3_gclk",
-	.addr		= am33xx_tptc1_addr_space,
 	.user		= OCP_USER_MPU,
 };
 
-/* l3 main -> tpcc2 */
-static struct omap_hwmod_addr_space am33xx_tptc2_addr_space[] = {
-	{
-		.pa_start	= 0x49a00000,
-		.pa_end		= 0x49a00000 + SZ_8K - 1,
-		.flags		= ADDR_TYPE_RT,
-	},
-	{ }
-};
-
-static struct omap_hwmod_ocp_if am33xx_l3_main__tptc2 = {
-	.master		= &am33xx_l3_main_hwmod,
-	.slave		= &am33xx_tptc2_hwmod,
-	.clk		= "l3_gclk",
-	.addr		= am33xx_tptc2_addr_space,
-	.user		= OCP_USER_MPU,
-};
-
-/* l4 wkup -> uart1 */
-static struct omap_hwmod_addr_space am33xx_uart1_addr_space[] = {
-	{
-		.pa_start	= 0x44E09000,
-		.pa_end		= 0x44E09000 + SZ_8K - 1,
-		.flags		= ADDR_TYPE_RT,
-	},
-	{ }
-};
-
 static struct omap_hwmod_ocp_if am33xx_l4_wkup__uart1 = {
 	.master		= &am33xx_l4_wkup_hwmod,
 	.slave		= &am33xx_uart1_hwmod,
 	.clk		= "dpll_core_m4_div2_ck",
-	.addr		= am33xx_uart1_addr_space,
 	.user		= OCP_USER_MPU,
 };
 
-/* l4 ls -> uart2 */
-static struct omap_hwmod_addr_space am33xx_uart2_addr_space[] = {
-	{
-		.pa_start	= 0x48022000,
-		.pa_end		= 0x48022000 + SZ_8K - 1,
-		.flags		= ADDR_TYPE_RT,
-	},
-	{ }
-};
-
 static struct omap_hwmod_ocp_if am33xx_l4_ls__uart2 = {
 	.master		= &am33xx_l4_ls_hwmod,
 	.slave		= &am33xx_uart2_hwmod,
 	.clk		= "l4ls_gclk",
-	.addr		= am33xx_uart2_addr_space,
 	.user		= OCP_USER_MPU,
 };
 
-/* l4 ls -> uart3 */
-static struct omap_hwmod_addr_space am33xx_uart3_addr_space[] = {
-	{
-		.pa_start	= 0x48024000,
-		.pa_end		= 0x48024000 + SZ_8K - 1,
-		.flags		= ADDR_TYPE_RT,
-	},
-	{ }
-};
-
 static struct omap_hwmod_ocp_if am33xx_l4_ls__uart3 = {
 	.master		= &am33xx_l4_ls_hwmod,
 	.slave		= &am33xx_uart3_hwmod,
 	.clk		= "l4ls_gclk",
-	.addr		= am33xx_uart3_addr_space,
 	.user		= OCP_USER_MPU,
 };
 
-/* l4 ls -> uart4 */
-static struct omap_hwmod_addr_space am33xx_uart4_addr_space[] = {
-	{
-		.pa_start	= 0x481A6000,
-		.pa_end		= 0x481A6000 + SZ_8K - 1,
-		.flags		= ADDR_TYPE_RT,
-	},
-	{ }
-};
-
 static struct omap_hwmod_ocp_if am33xx_l4_ls__uart4 = {
 	.master		= &am33xx_l4_ls_hwmod,
 	.slave		= &am33xx_uart4_hwmod,
 	.clk		= "l4ls_gclk",
-	.addr		= am33xx_uart4_addr_space,
 	.user		= OCP_USER_MPU,
 };
 
-/* l4 ls -> uart5 */
-static struct omap_hwmod_addr_space am33xx_uart5_addr_space[] = {
-	{
-		.pa_start	= 0x481A8000,
-		.pa_end		= 0x481A8000 + SZ_8K - 1,
-		.flags		= ADDR_TYPE_RT,
-	},
-	{ }
-};
-
 static struct omap_hwmod_ocp_if am33xx_l4_ls__uart5 = {
 	.master		= &am33xx_l4_ls_hwmod,
 	.slave		= &am33xx_uart5_hwmod,
 	.clk		= "l4ls_gclk",
-	.addr		= am33xx_uart5_addr_space,
 	.user		= OCP_USER_MPU,
 };
 
-/* l4 ls -> uart6 */
-static struct omap_hwmod_addr_space am33xx_uart6_addr_space[] = {
-	{
-		.pa_start	= 0x481aa000,
-		.pa_end		= 0x481aa000 + SZ_8K - 1,
-		.flags		= ADDR_TYPE_RT,
-	},
-	{ }
-};
-
 static struct omap_hwmod_ocp_if am33xx_l4_ls__uart6 = {
 	.master		= &am33xx_l4_ls_hwmod,
 	.slave		= &am33xx_uart6_hwmod,
 	.clk		= "l4ls_gclk",
-	.addr		= am33xx_uart6_addr_space,
 	.user		= OCP_USER_MPU,
 };
 
 /* l4 wkup -> wd_timer1 */
-static struct omap_hwmod_addr_space am33xx_wd_timer1_addrs[] = {
-	{
-		.pa_start	= 0x44e35000,
-		.pa_end		= 0x44e35000 + SZ_4K - 1,
-		.flags		= ADDR_TYPE_RT
-	},
-	{ }
-};
-
 static struct omap_hwmod_ocp_if am33xx_l4_wkup__wd_timer1 = {
 	.master		= &am33xx_l4_wkup_hwmod,
 	.slave		= &am33xx_wd_timer1_hwmod,
 	.clk		= "dpll_core_m4_div2_ck",
-	.addr		= am33xx_wd_timer1_addrs,
 	.user		= OCP_USER_MPU,
 };
 
 /* usbss */
 /* l3 s -> USBSS interface */
-static struct omap_hwmod_addr_space am33xx_usbss_addr_space[] = {
-	{
-		.name		= "usbss",
-		.pa_start	= 0x47400000,
-		.pa_end		= 0x47400000 + SZ_4K - 1,
-		.flags		= ADDR_TYPE_RT
-	},
-	{
-		.name		= "musb0",
-		.pa_start	= 0x47401000,
-		.pa_end		= 0x47401000 + SZ_2K - 1,
-		.flags		= ADDR_TYPE_RT
-	},
-	{
-		.name		= "musb1",
-		.pa_start	= 0x47401800,
-		.pa_end		= 0x47401800 + SZ_2K - 1,
-		.flags		= ADDR_TYPE_RT
-	},
-	{ }
-};
-
 static struct omap_hwmod_ocp_if am33xx_l3_s__usbss = {
 	.master		= &am33xx_l3_s_hwmod,
 	.slave		= &am33xx_usbss_hwmod,
 	.clk		= "l3s_gclk",
-	.addr		= am33xx_usbss_addr_space,
 	.user		= OCP_USER_MPU,
 	.flags		= OCPIF_SWSUP_IDLE,
 };
@@ -3450,13 +1513,10 @@ static struct omap_hwmod_ocp_if am33xx_l3_main__ocmc = {
 };
 
 static struct omap_hwmod_ocp_if *am33xx_hwmod_ocp_ifs[] __initdata = {
-	&am33xx_l4_fw__emif_fw,
-	&am33xx_l3_main__emif,
 	&am33xx_mpu__l3_main,
 	&am33xx_mpu__prcm,
 	&am33xx_l3_s__l4_ls,
 	&am33xx_l3_s__l4_wkup,
-	&am33xx_l3_s__l4_fw,
 	&am33xx_l3_main__l4_hs,
 	&am33xx_l3_main__l3_s,
 	&am33xx_l3_main__l3_instr,
@@ -3474,7 +1534,6 @@ static struct omap_hwmod_ocp_if *am33xx_hwmod_ocp_ifs[] __initdata = {
 	&am33xx_l4_wkup__rtc,
 	&am33xx_l4_wkup__i2c1,
 	&am33xx_l4_wkup__gpio0,
-	&am33xx_l4_wkup__adc_tsc,
 	&am33xx_l4_wkup__wd_timer1,
 	&am33xx_l4_hs__pruss,
 	&am33xx_l4_per__dcan0,
@@ -3484,14 +1543,6 @@ static struct omap_hwmod_ocp_if *am33xx_hwmod_ocp_ifs[] __initdata = {
 	&am33xx_l4_per__gpio3,
 	&am33xx_l4_per__i2c2,
 	&am33xx_l4_per__i2c3,
-	&am33xx_l4_per__mailbox,
-	&am33xx_l4_ls__mcasp0,
-	&am33xx_l3_s__mcasp0_data,
-	&am33xx_l4_ls__mcasp1,
-	&am33xx_l3_s__mcasp1_data,
-	&am33xx_l4_ls__mmc0,
-	&am33xx_l4_ls__mmc1,
-	&am33xx_l3_s__mmc2,
 	&am33xx_l4_ls__timer2,
 	&am33xx_l4_ls__timer3,
 	&am33xx_l4_ls__timer4,
@@ -3505,26 +1556,8 @@ static struct omap_hwmod_ocp_if *am33xx_hwmod_ocp_ifs[] __initdata = {
 	&am33xx_l4_ls__uart5,
 	&am33xx_l4_ls__uart6,
 	&am33xx_l4_ls__spinlock,
-	&am33xx_l4_ls__elm,
-	&am33xx_l4_ls__epwmss0,
-	&am33xx_epwmss0__ecap0,
-	&am33xx_epwmss0__eqep0,
-	&am33xx_epwmss0__ehrpwm0,
-	&am33xx_l4_ls__epwmss1,
-	&am33xx_epwmss1__ecap1,
-	&am33xx_epwmss1__eqep1,
-	&am33xx_epwmss1__ehrpwm1,
-	&am33xx_l4_ls__epwmss2,
-	&am33xx_epwmss2__ecap2,
-	&am33xx_epwmss2__eqep2,
-	&am33xx_epwmss2__ehrpwm2,
-	&am33xx_l3_s__gpmc,
-	&am33xx_l3_main__lcdc,
 	&am33xx_l4_ls__mcspi0,
 	&am33xx_l4_ls__mcspi1,
-	&am33xx_l3_main__tptc0,
-	&am33xx_l3_main__tptc1,
-	&am33xx_l3_main__tptc2,
 	&am33xx_l3_main__ocmc,
 	&am33xx_l3_s__usbss,
 	&am33xx_l4_hs__cpgmac0,
-- 
1.7.9.5



From maxime.ripard at free-electrons.com  Fri Apr  5 12:53:10 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Fri, 05 Apr 2013 18:53:10 +0200
Subject: [GIT PULL] ARM: sunxi: dt for 3.10, take 2
Message-ID: <515F0176.6060601@free-electrons.com>

Hi Arnd, Olof,

Please consider merging the following branch for 3.10

The following changes since commit 2c3b4d7a354015403d61e8d690044700db963598:

  arm: sunxi: Add clock definitions for the new clock driver (2013-03-23 09:39:00 +0100)

are available in the git repository at:

  git://github.com/mripard/linux.git tags/sunxi-dt-for-3.10-2

for you to fetch changes up to 36386d6e54d0ebcd5b2e0869f837800293d94c3c:

  arm: sunxi: Add clock to pinctrl node (2013-04-04 23:45:30 +0200)

----------------------------------------------------------------
ARM: sunxi: dt additions for 3.10, take 2

  - Rename the clock compatible introduced in the first pull request for 3.10
  - Complete the UART support for A13 and A10
  - Adds clock gates support

----------------------------------------------------------------
Emilio L?pez (5):
      arm: sunxi: rename clock compatible strings
      ARM: sunxi: cubieboard: Add UART muxing
      arm: sunxi: Add clock definitions for AXI, AHB, APB0, APB1 gates
      arm: sunxi: use the right clock phandles for UARTs
      arm: sunxi: Add clock to pinctrl node

Maxime Ripard (6):
      ARM: sunxi: dt: Use clocks property instead of clock-frequency for the UARTs
      ARM: sunxi: Rename uart nodes to serial
      ARM: sunxi: dt: Move uart0 to sun4i-a10.dtsi
      ARM: sunxi: dt: Add uart3 dt node
      ARM: sunxi: dt: Add A10 UARTs to the dtsi.
      ARM: sunxi: hackberry: Add UART muxing

 arch/arm/boot/dts/sun4i-a10-cubieboard.dts |    8 ++-
 arch/arm/boot/dts/sun4i-a10-hackberry.dts  |    4 +-
 arch/arm/boot/dts/sun4i-a10.dtsi           |   61 +++++++++++++++++++++
 arch/arm/boot/dts/sun5i-a13-olinuxino.dts  |    2 +-
 arch/arm/boot/dts/sun5i-a13.dtsi           |    1 +
 arch/arm/boot/dts/sunxi.dtsi               |   81 ++++++++++++++++++++++------
 6 files changed, 134 insertions(+), 23 deletions(-)


-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


From marc.zyngier at arm.com  Fri Apr  5 12:54:44 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Fri, 05 Apr 2013 17:54:44 +0100
Subject: [PATCH 6/7] ARM: KVM: switch to a dual-step HYP init code
In-Reply-To: <1365180410.24496.67.camel@smoke>
References: <1364909115-3810-1-git-send-email-marc.zyngier@arm.com>
 <1364909115-3810-7-git-send-email-marc.zyngier@arm.com>
 <1365113453.24496.26.camel@smoke> <515E9474.2070100@arm.com>
 <1365180410.24496.67.camel@smoke>
Message-ID: <515F01D4.8010706@arm.com>

On 05/04/13 17:46, Geoff Levand wrote:

Hi Geoff,

> On Fri, 2013-04-05 at 10:08 +0100, Marc Zyngier wrote:
>> On 04/04/13 23:10, Geoff Levand wrote:
>>> On Tue, 2013-04-02 at 14:25 +0100, Marc Zyngier wrote:
>>>> +	@ Jump to the trampoline page
>>>> +	ldr	r2, =#PAGE_MASK
>>>> +	adr	r3, target
>>>> +	bic	r3, r3, r2
>>>> +	ldr	r2, =#TRAMPOLINE_VA
>>>> +	add	r3, r3, r2
>>>> +	mov	pc, r3
>>>
>>> I guess you need 'ldr r2, =PAGE_MASK'.
>>>
>>>   arch/arm/kvm/init.S:114: Error: bad expression -- `ldr r2,=#(~((1<<12)-1))'
>>>   arch/arm/kvm/init.S:117: Error: bad expression -- `ldr r2,=#0xffff0000'
>>
>> Oddly enough, this code compiles perfectly fine on my box.
>> What's your compiler/binutils versions?
> 
> I thought # was for an immediate value in instructions.  This
> is an assembler pseudo-instruction, and based on the ARM manual
> here I would think your coding should fail:
> 
>   http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0473i/Chdcegci.html

I don't dispute the validity of your remark. I just find odd that my
compiler doesn't barf on this as it probably should.

> I use the current arm-linux-gnueabihf cross toolchain packages from
> Ubuntu 12.04:
> 
>   arm-linux-gnueabihf-gcc-4.6 (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3
>   GNU assembler (GNU Binutils for Ubuntu) 2.22

I'm using this:
arm-linux-gnueabihf-gcc (crosstool-NG linaro-1.13.1-4.7-2012.12-20121214
- Linaro GCC 2012.12) 4.7.3 20121205 (prerelease)
GNU assembler (crosstool-NG linaro-1.13.1-4.7-2012.12-20121214 - Linaro
GCC 2012.12) 2.22

Looks like there's a regression somewhere.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...



From t.figa at samsung.com  Fri Apr  5 12:53:31 2013
From: t.figa at samsung.com (Tomasz Figa)
Date: Fri, 05 Apr 2013 18:53:31 +0200
Subject: [PATCH v4 04/14] mfd: Add Samsung PWM/timer master driver
In-Reply-To: <20130405163958.GP17363@zurbaran>
References: <1365093431-30621-1-git-send-email-t.figa@samsung.com>
 <1365093431-30621-5-git-send-email-t.figa@samsung.com>
 <20130405163958.GP17363@zurbaran>
Message-ID: <5507947.WEhmSUi7vd@amdc1227>

Hi Samuel,

On Friday 05 of April 2013 18:39:58 Samuel Ortiz wrote:
> Hi Tomasz,
> 
> On Thu, Apr 04, 2013 at 06:37:01PM +0200, Tomasz Figa wrote:
> > This patch adds master driver for PWM/timer block available on many
> > Samsung SoCs providing clocksource and PWM output capabilities.
> > 
> > Signed-off-by: Tomasz Figa <t.figa at samsung.com>
> > Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
> > ---
> > 
> >  .../devicetree/bindings/pwm/pwm-samsung.txt        |  37 ++
> >  drivers/clocksource/Kconfig                        |   1 +
> >  drivers/mfd/Kconfig                                |   3 +
> >  drivers/mfd/Makefile                               |   1 +
> >  drivers/mfd/samsung-pwm.c                          | 439
> >  +++++++++++++++++++++ drivers/pwm/Kconfig                               
> >  |   1 +
> >  include/linux/mfd/samsung-pwm.h                    |  49 +++
> >  include/linux/platform_data/samsung-pwm.h          |  28 ++
> >  8 files changed, 559 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/pwm/pwm-samsung.txt
> >  create mode 100644 drivers/mfd/samsung-pwm.c
> >  create mode 100644 include/linux/mfd/samsung-pwm.h
> >  create mode 100644 include/linux/platform_data/samsung-pwm.h
> 
> Why is that an MFD driver, and why aren't you using the PWM APIs for it ?
> Also, you probably want to look at using the regmap APIs for your IO.

The case of Samsung PWM timers is rather complicated. It is a hardware block 
that can be used at the same time to generate PWM signal and as a system 
clocksource.

There was a discussion on how to solve the problem of sharing the hardware:
http://thread.gmane.org/gmane.linux.kernel.samsung-soc/16480/focus=16500
(see the linked post and replies to it).

Best regards,
-- 
Tomasz Figa
Samsung Poland R&D Center
SW Solution Development, Kernel and System Framework



From will.deacon at arm.com  Fri Apr  5 12:57:45 2013
From: will.deacon at arm.com (Will Deacon)
Date: Fri, 5 Apr 2013 17:57:45 +0100
Subject: [PATCH] documentation: iommu: add description of ARM System MMU
 binding
In-Reply-To: <515EFF1A.5030705@gmail.com>
References: <1365094259-24847-1-git-send-email-will.deacon@arm.com>
 <515EFF1A.5030705@gmail.com>
Message-ID: <20130405165745.GB17151@mudshark.cambridge.arm.com>

Hi Rob,

On Fri, Apr 05, 2013 at 05:43:06PM +0100, Rob Herring wrote:
> On 04/04/2013 11:50 AM, Will Deacon wrote:
> > This patch adds a description of the device tree binding for the ARM
> > System MMU architecture.
> > 
> > Cc: Rob Herring <robherring2 at gmail.com>
> > Cc: Andreas Herrmann <andreas.herrmann at calxeda.com>
> > Signed-off-by: Will Deacon <will.deacon at arm.com>
> > ---
> > 
> > Hello,
> > 
> > The driver for this is still a WIP. Both Andreas and myself have prototype
> > code, but we're planning to merge that together to get something more
> > general. Deciding on the binding is a good first step.
> 
> Thanks for getting this out.

No problem.

> > All comments welcome,
> > 
> > Will
> > 
> >  .../devicetree/bindings/iommu/arm,smmu.txt         | 61 ++++++++++++++++++++++
> >  1 file changed, 61 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/iommu/arm,smmu.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> > new file mode 100644
> > index 0000000..938325f
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> > @@ -0,0 +1,61 @@
> > +* ARM System MMU Architecture Implementation
> > +
> > +ARM SoCs may contain an implementation of the ARM System Memory
> > +Management Unit Architecture, which can be used to provide 1 or 2 stages
> > +of address translation to bus masters external to the CPU.
> > +
> > +The SMMU may also raise interrupts in response to various fault
> > +conditions.
> > +
> > +** System MMU required properties:
> > +
> > +- compatible    : Should be one of "arm,smmu-v1" or "arm,smmu-v2"
> > +                  depending on the version of the architecture
> > +                  implemented.
> 
> We can keep these, but we should have specific models like arm,smmu-400,
> etc. as well.

Ok, if distinctions need to be between MMU-400 and a v1 implementation, then
we can add those strings later.

> > +
> > +- reg           : Base address and size of the SMMU.
> > +
> > +- #global-interrupts : The number of global interrupts exposed by the
> > +                       device.
> > +
> > +- interrupts    : Interrupt list, with the first #global-irqs entries
> > +                  corresponding to the global interrupts and any
> > +                  following entries corresponding to context interrupts,
> > +                  specified in order of their indexing by the SMMU.
> > +
> > +- mmu-masters   : A list of phandles to device nodes representing bus
> > +                  masters for which the SMMU can provide a translation.
> > +
> > +- stream-ids    : A list of 16-bit values corresponding to the StreamIDs
> > +                  for the devices listed in the mmu-masters property.
> > +                  This list must be same length as mmu-masters, so
> > +                  masters with multiple stream-ids will have multiple
> > +                  entries in mmu-masters.
> 
> Your example below is actually 32-bit values in the DTB. You can
> annotate them to actually be 16-bit if you want. But I would just leave
> them as 32-bit.

I'm also parsing them as u32 in my driver, so yes, u32 it is!

> > +
> > +** System MMU optional properties:
> > +
> > +- smmu-parent   : When multiple SMMUs are chained together, this
> > +                  property can be used to provide a phandle to the
> > +                  parent SMMU (that is the next SMMU on the path going
> > +                  from the mmu-masters towards memory) node for this
> > +                  SMMU.
> 
> Does the SMMU need to know if it is coherent or not?

You mean with respect to table walks? That's actually probable from the
device (along with a whole bunch of other parameters) using SMMU_IDR0.

I'll fix up the other comments and send out a v2 next week.

Cheers for the review,

Will


From arnd at arndb.de  Fri Apr  5 12:58:05 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 5 Apr 2013 18:58:05 +0200
Subject: mvebu-mbus: defining a DT binding
In-Reply-To: <20130405162737.GA3598@obsidianresearch.com>
References: <20130405150200.7b6dee63@skate>
 <20130405162737.GA3598@obsidianresearch.com>
Message-ID: <201304051858.05567.arnd@arndb.de>

On Friday 05 April 2013, Jason Gunthorpe wrote:
> On Fri, Apr 05, 2013 at 03:02:00PM +0200, Thomas Petazzoni wrote:
> 
> >  * The address decoding windows are in fact defined by the ranges =
> >    <...> property of the mbus node. Here, in the example provided by
> >    Jason, this ranges = <...> property is part of the SoC-level .dtsi.
> >    However, some boards will have to add some board-specific windows
> >    (adjusted to the size of their NOR, or FPGA, for example).
> 
> Right. The things Linux does to try and re-use parts of the DT are
> nice, but I don't think they should strongly guide the design of the
> binding.. Someone recently said that the DT is designed to be machine
> parseable not human readable..
> 
> In any event, the 'default' mbus window locations in the static DTB
> should match the configuration the bootloader sets when it boots
> Linux. Ideally some basic level of functionality should be possible
> without the dynamic mbus driver..
> 
> So to me, this is already a guide that this might have to be board
> specific anyhow.

I mentioned three options before, what you describe is one of
them:

a) make the ranges in the DT refer to what the hardware is set to,
as you explain above. This makes it easy to run an OS without an
mbus driver, but somewhat harder to reassign the windows at run-time

b) set the ranges to the windows we want to have in Linux. This is closer
to what we have at the moment, where we basically configure mbus from
a static configuration, and allow the windows that are to be dynamic
(e.g. PCIe) to be left out of this.

c) Try to keep the ranges property empty at boot time, except possibly
the internal register window, and find the optimum address map at
boot time based on which devices are enabled.

> >  * I am not sure to understand why the nand, crypto and pcie-controller
> >    nodes are outside of the internal registers. Well, I understand it's
> >    because those devices need a special address decoding window. But it
> >    sounds strange because those devices also have internal registers
> >    (which is why Jason used 'MAPDEF_INTERNAL + offset' in the reg
> >    property).
> 
> This is a arbitary choice, of course. Arnd: The issue is how do you
> refer to two MBUS windows in a single device node.
> 
> From a design perspective, the chip has an internal regs blocks. I
> modeled that block directly with a bus node (internal_regs at f1000000).
> It has a single ranges, that is 0 based. This makes the 'regs' of the
> children exactly match the datasheet.  Everything that couldn't fit in
> there I treated as an exception, and placed directly under mbus
> instead.

Makes sense.
> The main alternative made less sense to me:
> 
> mbus {
>   ranges = <MAPDEF_INTERNAL 0xf1000000 0x100000
>  [..]
> 
>   everything@?? {
>        ranges = <0x00000000 MAPDEF_INTERNAL 0x100000
>                  0x10000000 MAPDEF_CRYPTO 0x800>
>   }
> }
> 
> The 'everything' node is very muddled to me.

Yes, that would neither clarify it to the reader nor actually
reflect what the hardware does.

	Arnd


From swarren at wwwdotorg.org  Fri Apr  5 13:03:39 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Fri,  5 Apr 2013 11:03:39 -0600
Subject: [GIT PULL 1/8] ARM: tegra: DT-related fixes needed by the MMC tree
Message-ID: <1365181426-11547-1-git-send-email-swarren@wwwdotorg.org>

In order to convert the Tegra MMC driver to using mmc_of_parse(), some
bugs in the Tegra device-tree content need to be fixed first; it's
currently wrong but unused, and mmc_of_parse() causes that data to be
used for the first time.

(This branch has also been merged into the MMC tree. I'm sending it as a
separate pull request as an FYI, but you can feel free to skip it and just
pull in 2/8 which is the main Tegra fixes branch and includes this)

----------------------------------------------------------------

The following changes since commit 6dbe51c251a327e012439c4772097a13df43c5b8:

  Linux 3.9-rc1

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra.git tegra-for-3.10-fixes-for-mmc

for you to fetch changes up to 908ab9368866e6edf0edebdd546adefd5f3128f9:

  ARM: dts: tegra: fix the activate polarity of cd-gpio in mmc host

----------------------------------------------------------------

Joseph Lo (1):
      ARM: dts: tegra: fix the activate polarity of cd-gpio in mmc host

 arch/arm/boot/dts/tegra20-colibri-512.dtsi |    2 +-
 arch/arm/boot/dts/tegra20-harmony.dts      |    4 ++--
 arch/arm/boot/dts/tegra20-paz00.dts        |    2 +-
 arch/arm/boot/dts/tegra20-seaboard.dts     |    2 +-
 arch/arm/boot/dts/tegra20-tamonten.dtsi    |    2 +-
 arch/arm/boot/dts/tegra20-trimslice.dts    |    2 +-
 arch/arm/boot/dts/tegra20-ventana.dts      |    2 +-
 arch/arm/boot/dts/tegra20-whistler.dts     |    1 +
 arch/arm/boot/dts/tegra30-beaver.dts       |    2 +-
 arch/arm/boot/dts/tegra30-cardhu.dtsi      |    2 +-
 10 files changed, 11 insertions(+), 10 deletions(-)


From swarren at wwwdotorg.org  Fri Apr  5 13:03:40 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Fri,  5 Apr 2013 11:03:40 -0600
Subject: [GIT PULL 2/8] ARM: tegra: minor fixes
In-Reply-To: <1365181426-11547-1-git-send-email-swarren@wwwdotorg.org>
References: <1365181426-11547-1-git-send-email-swarren@wwwdotorg.org>
Message-ID: <1365181426-11547-2-git-send-email-swarren@wwwdotorg.org>

This branch contains a variety of small build and run-time fixes that
weren't important enough for 3.9.

* Enable CPU errata WARs in secondary reset handler as a preparation
  for multi-platform support, and a related fix.
* Don't touch DBLGAR in reset/resume handlers, so enable the code to
  run on A15 cores.
* Minor build fixes.
* A fix to the Tegra clock driver.
* Some error-handling fixes.

This branch is based on the previous fixes-for-mmc pull request.

----------------------------------------------------------------

The following changes since commit 908ab9368866e6edf0edebdd546adefd5f3128f9:

  ARM: dts: tegra: fix the activate polarity of cd-gpio in mmc host

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra.git tegra-for-3.10-fixes

for you to fetch changes up to eebd1fda2342014a50ed3fd132e5dc6e8b5251e8:

  ARM: tegra: powergate: Don't error out if new state == old state

----------------------------------------------------------------

Hiroshi Doyu (2):
      ARM: tegra: Fix unchecked return value
      memory: tegra30: Fix build error w/o PM

Joseph Lo (2):
      ARM: tegra: don't unlock MMIO access to DBGLAR
      ARM: tegra: fix the logical detection of power on sequence of warm boot CPUs

Peter De Schrijver (1):
      clk: tegra: No 7.1 super clk dividers on Tegra20

Stephen Warren (3):
      ARM: tegra: add CPU errata WARs to Tegra reset handler
      ARM: tegra: remove save/restore of CPU diag register
      ARM: tegra: fix ignored return value of regulator_enable

Thierry Reding (2):
      ARM: tegra: Export tegra_powergate_sequence_power_up()
      ARM: tegra: powergate: Don't error out if new state == old state

 arch/arm/mach-tegra/board-harmony-pcie.c |    7 +++-
 arch/arm/mach-tegra/cpuidle-tegra30.c    |    4 ---
 arch/arm/mach-tegra/headsmp.S            |    3 --
 arch/arm/mach-tegra/platsmp.c            |    5 ++-
 arch/arm/mach-tegra/pm.c                 |   19 ----------
 arch/arm/mach-tegra/powergate.c          |    4 ++-
 arch/arm/mach-tegra/reset-handler.S      |   48 ++++++++++++++++++++-----
 drivers/clk/tegra/clk-tegra20.c          |   36 ++-----------------
 drivers/memory/tegra30-mc.c              |    2 ++
 9 files changed, 56 insertions(+), 72 deletions(-)


From swarren at wwwdotorg.org  Fri Apr  5 13:03:41 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Fri,  5 Apr 2013 11:03:41 -0600
Subject: [GIT PULL 3/8] ARM: tegra: cleanup
In-Reply-To: <1365181426-11547-1-git-send-email-swarren@wwwdotorg.org>
References: <1365181426-11547-1-git-send-email-swarren@wwwdotorg.org>
Message-ID: <1365181426-11547-3-git-send-email-swarren@wwwdotorg.org>

This branch includes various cleanup of the core Tegra support.

* Unification of the separate board-dt-tegra*.c files into a single
  tegra.c, now that everything is DT-driven and basically identical.
* Use of_clk_get() in the Tegra clocksource driver so that clocks are
  described in DT rather than hard-coding clock names.
* Some cleanup of the PMC-related code, with the aim that the PMC
  "driver" contains more of the code that touches PMC registers, rather
  than spreading PMC register accesses through other files.
* Conversion of the "PMC" driver to acquire resources describe in device
  tree rather than hard-coding them.
* Use of common code for the CPU sleep TLB invalidation.

This branch is based on the previous fixes pull request.

----------------------------------------------------------------

The following changes since commit 84b808da2dea7020211f1d73d015ff6c3ac207c4:

  ARM: tegra: fix ignored return value of regulator_enable

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra.git tegra-for-3.10-cleanup

for you to fetch changes up to 6affb4826405dc1f53bae0e5c302a18f734a44ca:

  ARM: tegra: use setup_mm_for_reboot rather than explicit pgd switch

----------------------------------------------------------------

Hiroshi Doyu (4):
      ARM: tegra: Unify tegra{20,30,114}_init_early()
      ARM: tegra: Rename board-dt-tegra20.c to tegra.c
      ARM: tegra: Unify Device tree board files
      ARM: tegra: refactor tegra{20,30}_boot_secondary

Joseph Lo (5):
      ARM: tegra: pmc: add specific compatible DT string for Tegra30 and Tegra114
      ARM: tegra: fix the PMC compatible string in DT
      ARM: tegra: pmc: convert PMC driver to support DT only
      ARM: tegra: pmc: add power on function for secondary CPUs
      ARM: tegra: replace the CPU power on function with PMC call

Peter De Schrijver (1):
      clocksource: tegra: move to of_clk_get

Will Deacon (1):
      ARM: tegra: use setup_mm_for_reboot rather than explicit pgd switch

 arch/arm/boot/dts/tegra114.dtsi                 |    2 +-
 arch/arm/boot/dts/tegra20.dtsi                  |    2 +
 arch/arm/boot/dts/tegra30.dtsi                  |    4 +-
 arch/arm/mach-tegra/Makefile                    |    4 +-
 arch/arm/mach-tegra/board-dt-tegra114.c         |   46 ------
 arch/arm/mach-tegra/board-dt-tegra30.c          |   60 -------
 arch/arm/mach-tegra/board.h                     |    4 +-
 arch/arm/mach-tegra/common.c                    |   26 +--
 arch/arm/mach-tegra/hotplug.c                   |   23 ++-
 arch/arm/mach-tegra/platsmp.c                   |  110 +++++--------
 arch/arm/mach-tegra/pm.c                        |    7 +-
 arch/arm/mach-tegra/pmc.c                       |  152 ++++++++++++++----
 arch/arm/mach-tegra/pmc.h                       |    4 +
 arch/arm/mach-tegra/sleep.h                     |   10 +-
 .../mach-tegra/{board-dt-tegra20.c => tegra.c}  |   16 +-
 drivers/clocksource/tegra20_timer.c             |    4 +-
 16 files changed, 207 insertions(+), 267 deletions(-)
 delete mode 100644 arch/arm/mach-tegra/board-dt-tegra114.c
 delete mode 100644 arch/arm/mach-tegra/board-dt-tegra30.c
 rename arch/arm/mach-tegra/{board-dt-tegra20.c => tegra.c} (89%)


From swarren at wwwdotorg.org  Fri Apr  5 13:03:42 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Fri,  5 Apr 2013 11:03:42 -0600
Subject: [GIT PULL 4/8] ARM: tegra: core SoC support development
In-Reply-To: <1365181426-11547-1-git-send-email-swarren@wwwdotorg.org>
References: <1365181426-11547-1-git-send-email-swarren@wwwdotorg.org>
Message-ID: <1365181426-11547-4-git-send-email-swarren@wwwdotorg.org>

This branch includes major development on the core Tegra SoC support code
in the mach-tegra directory:

* SMP support for Tegra114.
* Exposes SoC chip ID and revision through standard sysfs files.
* System-level suspend/resume for Tegra20/30. At present, this only
  supports "LP2" mode (CPU power-down), but provides the basis to
  implement "LP0"/"LP1" (various levels of core/chip power-down) in the
  hopefully near future.
* A minor cleanup of a duplicate include, which was introduced in this
  branch.

This branch is based on the previous cleanup pull request.

----------------------------------------------------------------

The following changes since commit 7e56474456221541aab7b2fe415ff400d7c9910a:

  ARM: tegra: replace the CPU power on function with PMC call

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra.git tegra-for-3.10-soc

for you to fetch changes up to 38be85de698ef3f2755ee0eabf520530757860aa:

  ARM: tegra: pm: remove duplicated include from pm.c

----------------------------------------------------------------

Danny Huang (2):
      ARM: tegra: expose chip ID and revision
      ARM: tegra: add speedo-based process id for Tegra114

Joseph Lo (8):
      ARM: tegra: bring up secondary CPU for Tegra114
      ARM: tegra: add clock source of PMC to device trees
      ARM: tegra: moving the CPU power timer function to PMC driver
      gpio: tegra: add gpio wakeup source handling
      ARM: tegra: irq: add wake up handling
      ARM: dt: tegra: add bindings of power management configurations for PMC
      ARM: tegra: pm: add platform suspend support
      ARM: tegra: cpuidle: remove redundant parameters for powered-down mode

Wei Yongjun (1):
      ARM: tegra: pm: remove duplicated include from pm.c

 .../bindings/arm/tegra/nvidia,tegra20-pmc.txt   |   67 +++++++-
 arch/arm/Kconfig                                |    1 +
 arch/arm/boot/dts/tegra114-dalmore.dts          |   13 ++
 arch/arm/boot/dts/tegra114-pluto.dts            |   13 ++
 arch/arm/boot/dts/tegra114.dtsi                 |    2 +
 arch/arm/boot/dts/tegra20-colibri-512.dtsi      |   13 ++
 arch/arm/boot/dts/tegra20-harmony.dts           |   13 ++
 arch/arm/boot/dts/tegra20-paz00.dts             |   13 ++
 arch/arm/boot/dts/tegra20-seaboard.dts          |   13 ++
 arch/arm/boot/dts/tegra20-tamonten.dtsi         |   13 ++
 arch/arm/boot/dts/tegra20-trimslice.dts         |   13 ++
 arch/arm/boot/dts/tegra20-ventana.dts           |   13 ++
 arch/arm/boot/dts/tegra20-whistler.dts          |   13 ++
 arch/arm/boot/dts/tegra20.dtsi                  |    2 +
 arch/arm/boot/dts/tegra30-beaver.dts            |   13 ++
 arch/arm/boot/dts/tegra30-cardhu.dtsi           |   13 ++
 arch/arm/boot/dts/tegra30.dtsi                  |    2 +
 arch/arm/mach-tegra/Makefile                    |    1 +
 arch/arm/mach-tegra/common.c                    |    5 +-
 arch/arm/mach-tegra/cpuidle-tegra20.c           |    6 +-
 arch/arm/mach-tegra/cpuidle-tegra30.c           |    6 +-
 arch/arm/mach-tegra/fuse.c                      |    4 +
 arch/arm/mach-tegra/fuse.h                      |    7 +
 arch/arm/mach-tegra/irq.c                       |   96 ++++++++++-
 arch/arm/mach-tegra/irq.h                       |    6 +
 arch/arm/mach-tegra/platsmp.c                   |    8 +
 arch/arm/mach-tegra/pm.c                        |  131 ++++++++------
 arch/arm/mach-tegra/pm.h                        |   17 +-
 arch/arm/mach-tegra/pmc.c                       |  162 ++++++++++++++++++
 arch/arm/mach-tegra/pmc.h                       |   14 ++
 arch/arm/mach-tegra/tegra.c                     |   29 +++-
 arch/arm/mach-tegra/tegra114_speedo.c           |  104 +++++++++++
 drivers/gpio/gpio-tegra.c                       |   21 ++-
 33 files changed, 780 insertions(+), 67 deletions(-)
 create mode 100644 arch/arm/mach-tegra/tegra114_speedo.c


From swarren at wwwdotorg.org  Fri Apr  5 13:03:43 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Fri,  5 Apr 2013 11:03:43 -0600
Subject: [GIT PULL 5/8] ARM: tegra: clock driver development
In-Reply-To: <1365181426-11547-1-git-send-email-swarren@wwwdotorg.org>
References: <1365181426-11547-1-git-send-email-swarren@wwwdotorg.org>
Message-ID: <1365181426-11547-5-git-send-email-swarren@wwwdotorg.org>

This branch contains most fixes and enhancements to the Tegra common
clock driver. The main new feature is a driver for Tegra114, which
coupled with later device tree changes enables many devices on that
chip, such as MMC, I2C, etc.

This branch depends on a patch in:

git://git.linaro.org/people/mturquette/linux.git clk-for-3.10

Mike has stated that this branch is stable, and is aware of this
dependency and merge.

Mike's branch is based on v3.9-rc3, which includes a USB change which
causes problems on Tegra. That problem was fixed in v3.9-rc4. Hence,
this branch pulls in v3.9-rc4 to ensure bisectability as much as
possible.

This branch is based on v3.9-rc4, followed by a merge of previous Tegra
"soc" pull request, followed by a merge of clk-for-3.10.

----------------------------------------------------------------

The following changes since commit 43089433b00a086980fc6e9571535477fb749e84:

  Merge remote-tracking branch 'linaro_mturquette_linux/clk-for-3.10' into for-3.10/clk

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra.git tegra-for-3.10-clk

for you to fetch changes up to 964ea47572b89589b61b553e44bbe9907d4f12a6:

  clk: tegra: fix enum tegra114_clk to match binding

----------------------------------------------------------------

Peter De Schrijver (14):
      clk: tegra: provide dummy cpu car ops
      clk: tegra: Refactor PLL programming code
      clk: tegra: Add TEGRA_PLL_BYPASS flag
      clk: tegra: introduce TEGRA_PLL_HAS_LOCK_ENABLE
      clk: tegra: Add PLL post divider table
      clk: tegra: move from a lock bit idx to a lock mask
      clk: tegra: Add new fields and PLL types for Tegra114
      clk: tegra: Add flags to tegra_clk_periph()
      clk: tegra: Workaround for Tegra114 MSENC problem
      ARM: tegra: Define Tegra114 CAR binding
      clk: tegra: Implement clocks for Tegra114
      clk: tegra: devicetree match for nvidia,tegra114-car
      ARM: dt: Add references to tegra_car clocks
      clk: tegra: Remove forced clk_enable of uartd

Prashant Gaikwad (1):
      clk: tegra: Fix cdev1 and cdev2 IDs

Stephen Warren (2):
      clk: tegra: defer application of init table
      clk: tegra: fix enum tegra114_clk to match binding

Thierry Reding (2):
      clk: tegra: Export peripheral reset functions
      clk: tegra: Make gr2d and gr3d clocks children of pll_c

Yen Lin (1):
      clk: tegra: Fix periph_clk_to_bit macro

 .../bindings/clock/nvidia,tegra114-car.txt      |  303 +++
 .../bindings/clock/nvidia,tegra20-car.txt       |    4 +-
 arch/arm/boot/dts/tegra114-dalmore.dts          |    1 -
 arch/arm/boot/dts/tegra114-pluto.dts            |    1 -
 arch/arm/boot/dts/tegra114.dtsi                 |    8 +-
 arch/arm/mach-tegra/tegra.c                     |    3 +
 drivers/clk/tegra/Makefile                      |    1 +
 drivers/clk/tegra/clk-periph-gate.c             |   11 +-
 drivers/clk/tegra/clk-periph.c                  |   14 +-
 drivers/clk/tegra/clk-pll.c                     | 1194 ++++++++--
 drivers/clk/tegra/clk-tegra114.c                | 2085 ++++++++++++++++++
 drivers/clk/tegra/clk-tegra20.c                 |  184 +-
 drivers/clk/tegra/clk-tegra30.c                 |  276 +--
 drivers/clk/tegra/clk.c                         |   14 +-
 drivers/clk/tegra/clk.h                         |   98 +-
 include/linux/clk/tegra.h                       |    1 +
 16 files changed, 3832 insertions(+), 366 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/clock/nvidia,tegra114-car.txt
 create mode 100644 drivers/clk/tegra/clk-tegra114.c


From swarren at wwwdotorg.org  Fri Apr  5 13:03:45 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Fri,  5 Apr 2013 11:03:45 -0600
Subject: [GIT PULL 7/8] ARM: tegra: multi-platform conversion
In-Reply-To: <1365181426-11547-1-git-send-email-swarren@wwwdotorg.org>
References: <1365181426-11547-1-git-send-email-swarren@wwwdotorg.org>
Message-ID: <1365181426-11547-7-git-send-email-swarren@wwwdotorg.org>

This branch converts Tegra to support multi-platform/single-zImage.

One header is made accessible to drivers. The earlyprintk implementation
is moved to the multi-platform location. Some Kconfig changes are made
to enable multi-platform. Some dead files are deleted.

The APIs exposed in the now-global tegra-powergate.h should be replaced
with standard reset and power domain APIs in the future.

This branch is based on (part of) the previous soc pull request.

----------------------------------------------------------------

The following changes since commit 7495b2eb0770b85e58af98b99faaf853e9563784:

  ARM: tegra: add speedo-based process id for Tegra114

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra.git tegra-for-3.10-multiplatform

for you to fetch changes up to 9002722560ba86a2f59811e3d11a2575bf47e1f6:

  ARM: tegra: convert to multi-platform

----------------------------------------------------------------

Stephen Warren (2):
      ARM: tegra: move <mach/powergate.h> to <linux/tegra-powergate.h>
      ARM: tegra: convert to multi-platform

 arch/arm/Kconfig                                |   19 --
 arch/arm/mach-tegra/Kconfig                     |   27 ++-
 arch/arm/mach-tegra/Makefile.boot               |    3 -
 arch/arm/mach-tegra/board.h                     |    1 +
 arch/arm/mach-tegra/common.c                    |    2 -
 arch/arm/mach-tegra/include/mach/timex.h        |   26 ---
 arch/arm/mach-tegra/include/mach/uncompress.h   |  175 ------------------
 arch/arm/mach-tegra/pcie.c                      |    3 +-
 arch/arm/mach-tegra/powergate.c                 |    3 +-
 drivers/clk/tegra/clk-tegra30.c                 |    3 +-
 .../linux/tegra-powergate.h                     |    5 -
 11 files changed, 24 insertions(+), 243 deletions(-)
 delete mode 100644 arch/arm/mach-tegra/Makefile.boot
 delete mode 100644 arch/arm/mach-tegra/include/mach/timex.h
 delete mode 100644 arch/arm/mach-tegra/include/mach/uncompress.h
 rename arch/arm/mach-tegra/include/mach/powergate.h => include/linux/tegra-powergate.h (92%)


From swarren at wwwdotorg.org  Fri Apr  5 13:03:44 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Fri,  5 Apr 2013 11:03:44 -0600
Subject: [GIT PULL 6/8] ARM: tegra: device tree changes
In-Reply-To: <1365181426-11547-1-git-send-email-swarren@wwwdotorg.org>
References: <1365181426-11547-1-git-send-email-swarren@wwwdotorg.org>
Message-ID: <1365181426-11547-6-git-send-email-swarren@wwwdotorg.org>

This branch contains the majority of the device tree changes for Tegra.
Highlights include:

* Many changes for Tegra114, and the Dalmore board, to enable pinctrl,
  SDHCI/MMC, PWM, DMA, I2C, KBC, SPI, battery, regulators.
* Adding or enabling suspend wakeup sources on many boards, and adding
  suspend timing parameters, to support the system suspend patches.
* Adding clocks to the audio-related nodes, so that in 3.11, the audio
  driver can pull these clocks from device tree rather than hard-coding
  clock names.
* Some small DT fixes/cleanup.

This branch is based on the previous clk pull request.

----------------------------------------------------------------

The following changes since commit 964ea47572b89589b61b553e44bbe9907d4f12a6:

  clk: tegra: fix enum tegra114_clk to match binding

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra.git tegra-for-3.10-dt

for you to fetch changes up to 1071b2df22aa45ffeaf34dfccc889d92586ca645:

  clk: tegra: Fix cdev1 and cdev2 IDs

----------------------------------------------------------------

Andrew Chew (2):
      ARM: tegra: fix the status of PWM DT nodes
      ARM: tegra: add PWM nodes to Tegra114 DT

Joseph Lo (4):
      ARM: tegra: add power gpio keys to DT
      ARM: tegra: whistler: add wakeup source for KBC
      ARM: tegra: add non-removable and keep-power-in-suspend property for MMC
      ARM: dts: tegra: add the PM configurations of PMC

Laxman Dewangan (9):
      ARM: tegra: add APB DMA nodes to Tegra114 DT
      ARM: tegra: add I2C nodes to Tegra114 DT
      ARM: tegra: add aliases and DMA requestor for serial nodes of Tegra114
      ARM: tegra: add KBC nodes to Tegra114 DT
      ARM: tegra: add SPI nodes to Tegra114 DT
      ARM: tegra: add DT binding for i2c-tegra
      ARM: tegra: dalmore: add cpu regulator node
      ARM: tegra: dalmore: add TPS65090 node
      ARM: tegra: dalmore: add fixed regulator node

Prashant Gaikwad (1):
      clk: tegra: Fix cdev1 and cdev2 IDs

Pritesh Raithatha (2):
      ARM: tegra: add default pinctrl nodes for Dalmore
      ARM: tegra: add SDHCI nodes with common properties

Rhyland Klein (2):
      ARM: tegra: add SDHCI support for Dalmore
      ARM: tegra: Add sbs-battery node to Dalmore

Stephen Warren (5):
      ARM: tegra: device tree whitespace cleanup
      ARM: tegra: fix sort order of USB PHY nodes
      ARM: tegra: add clocks property to sound nodes
      ARM: tegra: add clocks property to AC'97 sound nodes
      ARM: tegra: keep power on to SD slot on Dalmore

 .../bindings/i2c/nvidia,tegra20-i2c.txt         |   60 ++
 .../sound/nvidia,tegra-audio-alc5632.txt        |    8 +
 .../sound/nvidia,tegra-audio-trimslice.txt      |    7 +
 .../sound/nvidia,tegra-audio-wm8753.txt         |    8 +
 .../sound/nvidia,tegra-audio-wm8903.txt         |    8 +
 .../sound/nvidia,tegra-audio-wm9712.txt         |    8 +
 arch/arm/boot/dts/tegra114-dalmore.dts          |  891 ++++++++++++++++++
 arch/arm/boot/dts/tegra114.dtsi                 |  240 ++++-
 arch/arm/boot/dts/tegra20-colibri-512.dtsi      |   12 +
 arch/arm/boot/dts/tegra20-harmony.dts           |   20 +
 arch/arm/boot/dts/tegra20-medcom-wide.dts       |    7 +
 arch/arm/boot/dts/tegra20-paz00.dts             |   10 +
 arch/arm/boot/dts/tegra20-plutux.dts            |    3 +
 arch/arm/boot/dts/tegra20-seaboard.dts          |   11 +
 arch/arm/boot/dts/tegra20-tamonten.dtsi         |    6 +
 arch/arm/boot/dts/tegra20-tec.dts               |    3 +
 arch/arm/boot/dts/tegra20-trimslice.dts         |   23 +
 arch/arm/boot/dts/tegra20-ventana.dts           |   22 +
 arch/arm/boot/dts/tegra20-whistler.dts          |   13 +
 arch/arm/boot/dts/tegra20.dtsi                  |   53 +-
 arch/arm/boot/dts/tegra30-beaver.dts            |    8 +
 arch/arm/boot/dts/tegra30-cardhu-a02.dts        |    1 +
 arch/arm/boot/dts/tegra30-cardhu-a04.dts        |    1 +
 arch/arm/boot/dts/tegra30-cardhu.dtsi           |   11 +
 arch/arm/boot/dts/tegra30.dtsi                  |    1 +
 25 files changed, 1405 insertions(+), 30 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/i2c/nvidia,tegra20-i2c.txt


From swarren at wwwdotorg.org  Fri Apr  5 13:03:46 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Fri,  5 Apr 2013 11:03:46 -0600
Subject: [GIT PULL 8/8] ARM: tegra: defconfig changes
In-Reply-To: <1365181426-11547-1-git-send-email-swarren@wwwdotorg.org>
References: <1365181426-11547-1-git-send-email-swarren@wwwdotorg.org>
Message-ID: <1365181426-11547-8-git-send-email-swarren@wwwdotorg.org>

Various new features are enabled:

* Tegra114 support.
* Various PMICs and related options for Tegra114 platforms.
* KEYBOARD_GPIO, mainly as a suspend wakeup source.
* tegra_defconfig is rebuilt based on v3.9-rc1, which causes various
  layout changes.

This branch is based on v3.9-rc1.

----------------------------------------------------------------

The following changes since commit 6dbe51c251a327e012439c4772097a13df43c5b8:

  Linux 3.9-rc1

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra.git tegra-for-3.10-defconfig

for you to fetch changes up to e1eee65f1a0cce8e49624104b3497ba3f8d35199:

  ARM: tegra: defconfig updates

----------------------------------------------------------------

Stephen Warren (1):
      ARM: tegra: defconfig updates

 arch/arm/configs/tegra_defconfig |   18 ++++++++++--------
 1 file changed, 10 insertions(+), 8 deletions(-)


From arnd at arndb.de  Fri Apr  5 13:05:24 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 5 Apr 2013 19:05:24 +0200
Subject: [PATCH v4 04/14] mfd: Add Samsung PWM/timer master driver
In-Reply-To: <5507947.WEhmSUi7vd@amdc1227>
References: <1365093431-30621-1-git-send-email-t.figa@samsung.com>
 <20130405163958.GP17363@zurbaran> <5507947.WEhmSUi7vd@amdc1227>
Message-ID: <201304051905.24644.arnd@arndb.de>

On Friday 05 April 2013, Tomasz Figa wrote:
> On Friday 05 of April 2013 18:39:58 Samuel Ortiz wrote:
> > Hi Tomasz,
> > 
> > On Thu, Apr 04, 2013 at 06:37:01PM +0200, Tomasz Figa wrote:
> > > This patch adds master driver for PWM/timer block available on many
> > > Samsung SoCs providing clocksource and PWM output capabilities.
>
> > Why is that an MFD driver, and why aren't you using the PWM APIs for it ?
> > Also, you probably want to look at using the regmap APIs for your IO.
> 
> The case of Samsung PWM timers is rather complicated. It is a hardware block 
> that can be used at the same time to generate PWM signal and as a system 
> clocksource.
> 
> There was a discussion on how to solve the problem of sharing the hardware:
> http://thread.gmane.org/gmane.linux.kernel.samsung-soc/16480/focus=16500
> (see the linked post and replies to it).
> 

I don't think anyone ever suggested using a private API though. I think
it's ok if the driver lives in drivers/mfd when it doesn't fit anywhere
else easily, but you should really register it to the pwm subsystem to
expose that functionality, not export functions that can be used by
a pwm shim driver, which even seems to be missing from the series.

	Arnd


From jgunthorpe at obsidianresearch.com  Fri Apr  5 13:07:25 2013
From: jgunthorpe at obsidianresearch.com (Jason Gunthorpe)
Date: Fri, 5 Apr 2013 11:07:25 -0600
Subject: mvebu-mbus: defining a DT binding
In-Reply-To: <201304051636.56410.arnd@arndb.de>
References: <20130405150200.7b6dee63@skate> <201304051517.26838.arnd@arndb.de>
 <20130405155149.0b00a592@skate> <201304051636.56410.arnd@arndb.de>
Message-ID: <20130405170725.GB3598@obsidianresearch.com>

On Fri, Apr 05, 2013 at 04:36:56PM +0200, Arnd Bergmann wrote:

> > > Another option would be to not map them by default but let the
> > > mbus driver do as many mappings as possible at boot time based
> > > on the devices that are actually present as children of the mbus
> > > device and not marked as status="disabled".
> > 
> > So the 'ranges' property would be more or less empty? How would the
> > mbus driver know the target/attribute values for each window?
> 
> I think ideally the ranges property would be completely empty
> (absent actually, but that is a detail) at boot, and the mbus driver
> would fill the ranges property as needed. I can see two ways to
> do that:

At a minimum it needs to have the special internal regs target. The
mbus driver cannot relocate that memory, and must be told where the
bootloader left it.

Beyond that, things get muddled, IMHO. DT is being asked to do two
slightly conflicting things - represent the address map from the
bootloader and also provide enough information for Linux to
dynamically reconfigure it.

> a) The mbus driver does a for_each_child_of_node() loop to iterate
> through its children and allocates a new physical address for each
> "reg" property it finds on all devices that are not status="disabled".
> Since the windows are all power-of-two pages in size, a simple
> "first-fit" algorith should be just fine here. The definition of 
> the mbus address space guarantees that the "reg" property has
> all the information needed to do that mapping.

Certainly doable.. ranges would have to be parsed as well, and it is a
bit complex, but very doable.
 
> b) We explicitly make all devices under mbus aware of the fact that
> they they are on mbus, and export a function that they have to call
> to map the window, like

IMHO, this is the nuclear option - it should be avoided. Existing
general drivers like serial and MTD should not need special wrappers
to work..

> > > Do you know which children of the mbus node (if any) we actually
> > > need to access before initializing mbus?
> > 
> > I'm sorry but I don't understand this question. There's nothing to do
> > to 'initialize mbus'. We can add/remove address decoding windows
> > whenever we want.
> 
> Well, we have to set up the windows at one point during the boot process,
> and we cannot access anything behind the windows until they are set up.
> 
> So if for instance the UART we use for DEBUG_LL is behind an MBUS window,
> we cannot easily change its address. My question is which devices fall
> into this category, if any.

Agree, the mbus driver should parse the DTB and construct all the
'static' windows, update the ranges, then populate the children. As is
usual in Linux the bus driver should ensure everything is setup for
the child nodes before their probe function is called.

PEX is a special case, since it has 'dynamic' windows.

> Does the internal registers window contain the MMIO space of the mbus
> device as well?

Yes, the registers the MBUS driver accesses are part of the internal
regs target.

> Do you expect that we always need just one window to map all the internal
> registers, or would there be a reason to split it up into multiple windows
> to reduce the amount of physical address space consumed?

Internal regs is special. There is a single dedicated aperture
register for it. There can be only be one mapping.

> I don't get it yet. I would assume that each PCIe port maps exactly to
> one address window, which solves the problem you describe above very
> nicely. We can do away with the fake "one range for memory" concept
> and just let the mbus driver pick any physical address when we enable
> or hot-plug one of the ports.

The Linux PCI core requires a single host bridge aperture, that is
what the ranges indicate. It is up to the PCI core to select the
address window(s) the PEX will use. When it does this it tells the PCI
driver, which tells the MBUS driver, which ultimately creates the
window. The address selection must be slaved to the PCI core, the MBUS
driver cannot operate autonomously.

This is an unavoidable consequence of merging all the PEX's into a
single root complex. If you recall this was required to support the 10
PEX case. Cross port address assignment is necessary to avoid address
space exhaustion.

> The ranges properties are required so a device driver can call of_iomap().
> Without it, there is no way to convert an address in mbus space into a
> CPU phys_addr_t.

Right. When the mbus driver populates the children nodes, the standard
OF code should be immediately able to get the correct physical address
through all normal OF means.

So, for every target the mbus driver either forces the mbus registers
to match the DT or dynamically assigns a physical address and updates
the DT to reflect that.

Jason


From tony at atomide.com  Fri Apr  5 13:10:53 2013
From: tony at atomide.com (Tony Lindgren)
Date: Fri, 5 Apr 2013 10:10:53 -0700
Subject: [GIT PULL] ARM: OMAP5: hwmod, prm/cm data files and updates
 for 3.10
In-Reply-To: <515F00B8.3000501@ti.com>
References: <1363768852-18125-1-git-send-email-santosh.shilimkar@ti.com>
 <20130401170539.GK10155@atomide.com> <515BA76D.3000302@ti.com>
 <alpine.DEB.2.00.1304031146230.2616@utopia.booyaka.com>
 <515D6020.2030103@ti.com> <20130404165208.GI10155@atomide.com>
 <515DB110.9000503@ti.com> <515F00B8.3000501@ti.com>
Message-ID: <20130405171052.GD10155@atomide.com>

* Santosh Shilimkar <santosh.shilimkar at ti.com> [130405 09:52]:
> On Thursday 04 April 2013 10:27 PM, Santosh Shilimkar wrote:
> > On Thursday 04 April 2013 10:22 PM, Tony Lindgren wrote:
> >> * Santosh Shilimkar <santosh.shilimkar at ti.com> [130404 04:15]:
> [..]
> 
> >> Can't we already trim the am33xx hwmod data after your patches for
> >> v3.10 as am33xx is already DT only? Unfortunately we cannot create
> >> negative diffstat in other ways for v3.10 merge window as we cannot
> >> make omap4 DT only just quite yet.
> >>
> > Yes we can and I can take a stab it tomorrow. The only thing is I
> > might need some support for testing but thats manageable. Will
> > take a stab at it tomorrow and if everything goes well, post a
> > patch for smae.
> > 
> Patch for the AM33XX to trim is end of the email. Thanks to
> Sricharan and Pekon for patch and testing. Looping both
> Vaibhav's if they have any objection on the patch.
> 
> Regards,
> Santosh
> 
> From b95dd33fe59b8e77727eb3b1717d763bbf9a2893 Mon Sep 17 00:00:00 2001
> From: Sricharan R <r.sricharan at ti.com>
> Date: Fri, 5 Apr 2013 20:39:12 +0530
> Subject: [PATCH] ARM: AM33XX: hwmod data: Clean up the data file
> 
> - The IO resource information like dma request lines, irq number and
> ocp address space can be populated via dt blob. So such data can be stripped
> from SOC hwmod data file.
> 
> - The devices like adc, mailbox, gpmc which are missing the device
> tree bindings, hwmod data is not added since AM33XX is DT only build.
> When such devices add the dt bindings, respective hwmod data can be
> added along with it.
> 
> - The hwmod like firewall etc which are not useful are also dropped.
> 
> This gets us around ~2000 loc of negative diff. Patch is boot tested on
> AM335X EVM.

Great, that's a nice reduction :) Considering am33xx is DT only, it
should be safe.. But can the am33xx guys please test and ack it?

Regards,

Tony


From stefano.stabellini at eu.citrix.com  Fri Apr  5 13:16:45 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Fri, 5 Apr 2013 18:16:45 +0100
Subject: [PATCH v6 4/4] xen/arm: introduce xen_early_init, use PSCI on xen
In-Reply-To: <alpine.LFD.2.03.1304051217560.1171@syhkavp.arg>
References: <alpine.DEB.2.02.1304031239550.5078@kaball.uk.xensource.com>
 <1365167495-18508-4-git-send-email-stefano.stabellini@eu.citrix.com>
 <alpine.LFD.2.03.1304051217560.1171@syhkavp.arg>
Message-ID: <alpine.DEB.2.02.1304051725580.21065@kaball.uk.xensource.com>

On Fri, 5 Apr 2013, Nicolas Pitre wrote:
> On Fri, 5 Apr 2013, Stefano Stabellini wrote:
> 
> > Split xen_guest_init in two functions, one of them (xen_early_init) is
> > going to be called very early from setup_arch.
> > 
> > Change machine_desc->smp_init to xen_smp_init if Xen is present on the
> > platform. xen_smp_init just sets smp_ops to psci_smp_ops.
> 
> I still think the above is redundant, especially since psci_smp_ops has 
> priority over default mdesc->smp_ops.  And doing so does break MCPM. But 
> we're apparently going in circle over this issue.

Did you read my last email on this issue?

http://marc.info/?l=linux-arm-kernel&m=136500098703317&w=2


Let's examine the use cases here, assuming that your MCPM patch series
has been applied.


This is what happens:

- No Xen
Xen is not running on the platform and a Xen hypervisor node is not
available on device tree.
Everything keeps working seamlessly, this patch doesn't change anything.

- we are running on Xen
Xen is running on the platform, we are running as a guest on Xen and an
hypervisor node is available on device tree.
Let's also assume that there aren't any "arm,cci" compatible nodes on
device tree because Xen wouldn't export this kind of information to any
guests right now. Therefore PSCI should be used to boot secondary cpus.
Because the versatile express machine sets smp_init to
vexpress_smp_init_ops, vexpress_smp_init_ops will be called.
vexpress_smp_init_ops sets smp_ops to vexpress_smp_ops, that *break*
Xen.

With this patch, xen_smp_init will be called instead of
vexpress_smp_init_ops, and smp_ops will be set to psci_smp_ops,
therefore *unbreaking* Xen.

In fact what makes this patch really necessary is smp_init together with
the MCPM series.


Do you agree with me?


From csd_b at daudt.org  Fri Apr  5 13:16:55 2013
From: csd_b at daudt.org (Christian Daudt)
Date: Fri, 5 Apr 2013 10:16:55 -0700
Subject: [PATCH V2 2/2] ARM: bcm281xx: Add DT support for SMC handler
In-Reply-To: <1363299268-10506-2-git-send-email-csd@broadcom.com>
References: <1363299268-10506-1-git-send-email-csd@broadcom.com>
 <1363299268-10506-2-git-send-email-csd@broadcom.com>
Message-ID: <CAGFynZ8-vd=KdubW9E6UBHU3bntYpO3gwYtz0MFTCTn88A+Qtg@mail.gmail.com>

On Thu, Mar 14, 2013 at 3:14 PM, Christian Daudt <csd at broadcom.com> wrote:
> - Adds devicetree binding and documentation for the smc handler
>
> Updates from V1:
> - Created this separate patch for the DT portion
> - Added SoC compatible to smc binding
> ...
any willing reviewers ?

 Thanks,
   csd


From maxime.ripard at free-electrons.com  Fri Apr  5 13:17:55 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Fri, 05 Apr 2013 19:17:55 +0200
Subject: [PATCHv2 00/10] ARM: sunxi: Architecture cleanups and rework
In-Reply-To: <20130402183100.GM25867@quad.lixom.net>
References: <1364289198-11589-1-git-send-email-maxime.ripard@free-electrons.com>
 <51555CCF.2090005@free-electrons.com> <20130402183100.GM25867@quad.lixom.net>
Message-ID: <515F0743.4010509@free-electrons.com>

Le 02/04/2013 20:31, Olof Johansson a ?crit :
> On Fri, Mar 29, 2013 at 10:20:15AM +0100, Maxime Ripard wrote:
>> Hi Mike,
>>
>> Le 26/03/2013 10:13, Maxime Ripard a ?crit :
>>> Hi,
>>>
>>> This patchset is a serie of various cleanups and reworks in the sunxi
>>> architecture to prepare a clean landing for the next Allwinner SoC, the
>>> A31 (sun6i).
>>>
>>> The A31 is significantly different from the previous Allwinner SoC we
>>> supported, the A10 and A13, to no longer make the generic sunxi prefix
>>> we used in most compatible string relevant, while it should really have
>>> been sun4i in the first place.
>>>
>>> This set is also the occasion to cleanup the timer and irq code by
>>> switching to the recently introduced clocksource and irqchip
>>> infrastructures.
>>>
>>> This set depends on the UART patches I sent previously.
>>
>> I was meaning to take this branch, but some of the drivers changes in it
>> depends on the clock patches that Emilio sent and that are in clk-next.
>> Is it ok to merge clk-next into my branch?
> 
> All of of a <subsystem>-next branch is usually asking for trouble, since it'll
> cause all sorts of pain if the other maintianer is rebasing his for-next
> branch.
> 
> Best is to get those patches on just a minimal topic branch (that is still
> bisectable) that is shared between the trees.
> 
> Mike?

Mike, could you comment on that? I'd very much like to see this patches
come into 3.10.

Maxime


-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


From arnd at arndb.de  Fri Apr  5 13:28:13 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 5 Apr 2013 19:28:13 +0200
Subject: mvebu-mbus: defining a DT binding
In-Reply-To: <20130405170725.GB3598@obsidianresearch.com>
References: <20130405150200.7b6dee63@skate> <201304051636.56410.arnd@arndb.de>
 <20130405170725.GB3598@obsidianresearch.com>
Message-ID: <201304051928.14119.arnd@arndb.de>

On Friday 05 April 2013, Jason Gunthorpe wrote:
> On Fri, Apr 05, 2013 at 04:36:56PM +0200, Arnd Bergmann wrote:
> > I think ideally the ranges property would be completely empty
> > (absent actually, but that is a detail) at boot, and the mbus driver
> > would fill the ranges property as needed. I can see two ways to
> > do that:
> 
> At a minimum it needs to have the special internal regs target. The
> mbus driver cannot relocate that memory, and must be told where the
> bootloader left it.

Ok, I see.

> Beyond that, things get muddled, IMHO. DT is being asked to do two
> slightly conflicting things - represent the address map from the
> bootloader and also provide enough information for Linux to
> dynamically reconfigure it.

Right.

> > a) The mbus driver does a for_each_child_of_node() loop to iterate
> > through its children and allocates a new physical address for each
> > "reg" property it finds on all devices that are not status="disabled".
> > Since the windows are all power-of-two pages in size, a simple
> > "first-fit" algorith should be just fine here. The definition of 
> > the mbus address space guarantees that the "reg" property has
> > all the information needed to do that mapping.
> 
> Certainly doable.. ranges would have to be parsed as well, and it is a
> bit complex, but very doable.

One small complication that I realized now is that the windows on the
PCIe bus must be contiguous and not have other windows in the middle
because of the way that PCI resource allocation works in Linux at
the moment.

This means the mbus driver would probably need to sort the windows
by size first and allocate space from one end for all non-PCIe devices
and then we can let the PCIe driver announce the remaining space as
available for other devices to the PCIe core.

> > b) We explicitly make all devices under mbus aware of the fact that
> > they they are on mbus, and export a function that they have to call
> > to map the window, like
> 
> IMHO, this is the nuclear option - it should be avoided. Existing
> general drivers like serial and MTD should not need special wrappers
> to work..

If the internal regs have to be a special case, most of the devices
just stay regular platform devices and keep working as before, we'd
just have to special-case the drivers that are not on the internal
register window.

> > Well, we have to set up the windows at one point during the boot process,
> > and we cannot access anything behind the windows until they are set up.
> > 
> > So if for instance the UART we use for DEBUG_LL is behind an MBUS window,
> > we cannot easily change its address. My question is which devices fall
> > into this category, if any.
> 
> Agree, the mbus driver should parse the DTB and construct all the
> 'static' windows, update the ranges, then populate the children. As is
> usual in Linux the bus driver should ensure everything is setup for
> the child nodes before their probe function is called.

We should be able to handle this very easily if we don't call the mbus
device itself compatible="simple-bus" because it is not. Instead we
the probe function of the mbus device can assign all the windows and
then add its children by calling of_platform_populate() on itself.

> > Does the internal registers window contain the MMIO space of the mbus
> > device as well?
> 
> Yes, the registers the MBUS driver accesses are part of the internal
> regs target.

ok.

> > Do you expect that we always need just one window to map all the internal
> > registers, or would there be a reason to split it up into multiple windows
> > to reduce the amount of physical address space consumed?
> 
> Internal regs is special. There is a single dedicated aperture
> register for it. There can be only be one mapping.

Ok, that simplifies the number of options we have, which is probably
a good thing.

> > I don't get it yet. I would assume that each PCIe port maps exactly to
> > one address window, which solves the problem you describe above very
> > nicely. We can do away with the fake "one range for memory" concept
> > and just let the mbus driver pick any physical address when we enable
> > or hot-plug one of the ports.
> 
> The Linux PCI core requires a single host bridge aperture, that is
> what the ranges indicate. It is up to the PCI core to select the
> address window(s) the PEX will use. When it does this it tells the PCI
> driver, which tells the MBUS driver, which ultimately creates the
> window. The address selection must be slaved to the PCI core, the MBUS
> driver cannot operate autonomously.
> 
> This is an unavoidable consequence of merging all the PEX's into a
> single root complex. If you recall this was required to support the 10
> PEX case. Cross port address assignment is necessary to avoid address
> space exhaustion.

Right, I remembered that already and wrote above that we need to leave
a single phys_addr_t range for all the PCIe ranges after assigning
everything else. However, I think the DT representation should still
reflect what the hardware looks like, meaning that the ranges property
of the root complex can have one static range for each port, translating
the 4GB address space of the port to the 4GB mbus window.

When the PCIe core actually gets around to enable the port and assign
a PCIe memory resource, we can use the information from the ranges
property and the PCIe memory aperture to set up the mbus window.

	Arnd


From jgunthorpe at obsidianresearch.com  Fri Apr  5 13:29:16 2013
From: jgunthorpe at obsidianresearch.com (Jason Gunthorpe)
Date: Fri, 5 Apr 2013 11:29:16 -0600
Subject: mvebu-mbus: defining a DT binding
In-Reply-To: <201304051858.05567.arnd@arndb.de>
References: <20130405150200.7b6dee63@skate>
 <20130405162737.GA3598@obsidianresearch.com>
 <201304051858.05567.arnd@arndb.de>
Message-ID: <20130405172916.GC3598@obsidianresearch.com>

On Fri, Apr 05, 2013 at 06:58:05PM +0200, Arnd Bergmann wrote:

> > So to me, this is already a guide that this might have to be board
> > specific anyhow.
> 
> I mentioned three options before, what you describe is one of
> them:

There is also 

d) The DT contains the bootloader address map, but the mbus driver
   discards that and fully reassigns everything.

e) The DT contains the bootloader address map, but some targets may be
   missing. The address map is kept, and the missing targets are
   dynamically allocated.
 
> a) make the ranges in the DT refer to what the hardware is set to,
> as you explain above. This makes it easy to run an OS without an
> mbus driver, but somewhat harder to reassign the windows at run-time

I don't think it makes things harder, it is straightforward for the
driver to wipe and rewrite the ranges property based on actual
programming.

> b) set the ranges to the windows we want to have in Linux. This is closer
> to what we have at the moment, where we basically configure mbus from
> a static configuration, and allow the windows that are to be dynamic
> (e.g. PCIe) to be left out of this.

Keep in mind that in all cases the mbus driver will zero all the
windows and write its own information. This is necessary to ensure any
left over PEX windows are blown away, for instance. So from a
driver-design standpoint a and b are identical.

The only difference is what do you put in the board
file. Pragmatically it won't matter to many people, Both will work if
the kernel has the mbus driver.

> c) Try to keep the ranges property empty at boot time, except possibly
> the internal register window, and find the optimum address map at
> boot time based on which devices are enabled.

I think d or e is a better choice, since we marry the best feature of
a, and the best function of c.

For working on the driver a/b is certainly the simplest first
step. Adding future capability to go to d or e won't require a DT
change.

Jason


From stefano.stabellini at eu.citrix.com  Fri Apr  5 13:34:30 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Fri, 5 Apr 2013 18:34:30 +0100
Subject: [PATCH v6 4/4] xen/arm: introduce xen_early_init, use PSCI on xen
In-Reply-To: <alpine.DEB.2.02.1304051725580.21065@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1304031239550.5078@kaball.uk.xensource.com>
 <1365167495-18508-4-git-send-email-stefano.stabellini@eu.citrix.com>
 <alpine.LFD.2.03.1304051217560.1171@syhkavp.arg>
 <alpine.DEB.2.02.1304051725580.21065@kaball.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1304051825390.21065@kaball.uk.xensource.com>

On Fri, 5 Apr 2013, Stefano Stabellini wrote:
> On Fri, 5 Apr 2013, Nicolas Pitre wrote:
> > On Fri, 5 Apr 2013, Stefano Stabellini wrote:
> > 
> > > Split xen_guest_init in two functions, one of them (xen_early_init) is
> > > going to be called very early from setup_arch.
> > > 
> > > Change machine_desc->smp_init to xen_smp_init if Xen is present on the
> > > platform. xen_smp_init just sets smp_ops to psci_smp_ops.
> > 
> > I still think the above is redundant, especially since psci_smp_ops has 
> > priority over default mdesc->smp_ops.  And doing so does break MCPM. But 
> > we're apparently going in circle over this issue.
> 
> Did you read my last email on this issue?
> 
> http://marc.info/?l=linux-arm-kernel&m=136500098703317&w=2
> 
> 
> Let's examine the use cases here, assuming that your MCPM patch series
> has been applied.
> 
> 
> This is what happens:
> 
> - No Xen
> Xen is not running on the platform and a Xen hypervisor node is not
> available on device tree.
> Everything keeps working seamlessly, this patch doesn't change anything.
> 
> - we are running on Xen
> Xen is running on the platform, we are running as a guest on Xen and an
> hypervisor node is available on device tree.
> Let's also assume that there aren't any "arm,cci" compatible nodes on
> device tree because Xen wouldn't export this kind of information to any
> guests right now. Therefore PSCI should be used to boot secondary cpus.

Just in case this isn't clear enough: we don't have big.LITTLE support
in Xen right now, not in the hypervisor and certainly not in guests.
I'm keen on having big.LITTLE support in the hypervisor (thus some code
similar to your MCPM patch series will probably end up in Xen at some
point) but I doubt we'll expose big.LITTLE to guests any time soon.
It's going to be years, so I am not particularly worried about it right
now.


> Because the versatile express machine sets smp_init to
> vexpress_smp_init_ops, vexpress_smp_init_ops will be called.
> vexpress_smp_init_ops sets smp_ops to vexpress_smp_ops, that *break*
> Xen.
> 
> With this patch, xen_smp_init will be called instead of
> vexpress_smp_init_ops, and smp_ops will be set to psci_smp_ops,
> therefore *unbreaking* Xen.
> 
> In fact what makes this patch really necessary is smp_init together with
> the MCPM series.
> 
> 
> Do you agree with me?
> 


From t.figa at samsung.com  Fri Apr  5 13:35:41 2013
From: t.figa at samsung.com (Tomasz Figa)
Date: Fri, 05 Apr 2013 19:35:41 +0200
Subject: [PATCH v4 04/14] mfd: Add Samsung PWM/timer master driver
In-Reply-To: <201304051905.24644.arnd@arndb.de>
References: <1365093431-30621-1-git-send-email-t.figa@samsung.com>
 <5507947.WEhmSUi7vd@amdc1227> <201304051905.24644.arnd@arndb.de>
Message-ID: <19231120.yHlZtTPUMd@amdc1227>

On Friday 05 of April 2013 19:05:24 Arnd Bergmann wrote:
> On Friday 05 April 2013, Tomasz Figa wrote:
> > On Friday 05 of April 2013 18:39:58 Samuel Ortiz wrote:
> > > Hi Tomasz,
> > > 
> > > On Thu, Apr 04, 2013 at 06:37:01PM +0200, Tomasz Figa wrote:
> > > > This patch adds master driver for PWM/timer block available on many
> > > > Samsung SoCs providing clocksource and PWM output capabilities.
> > > 
> > > Why is that an MFD driver, and why aren't you using the PWM APIs for it
> > > ?
> > > Also, you probably want to look at using the regmap APIs for your IO.
> > 
> > The case of Samsung PWM timers is rather complicated. It is a hardware
> > block that can be used at the same time to generate PWM signal and as a
> > system clocksource.
> > 
> > There was a discussion on how to solve the problem of sharing the
> > hardware:
> > http://thread.gmane.org/gmane.linux.kernel.samsung-soc/16480/focus=16500
> > (see the linked post and replies to it).
> 
> I don't think anyone ever suggested using a private API though.

I must have gotten the last paragraph of
http://article.gmane.org/gmane.linux.kernel.samsung-soc/16638
wrong then. For me it seemed like the timer driver would expose a private API 
to the PWM driver.

> I think
> it's ok if the driver lives in drivers/mfd when it doesn't fit anywhere
> else easily, but you should really register it to the pwm subsystem to
> expose that functionality, not export functions that can be used by
> a pwm shim driver, which even seems to be missing from the series.

Anyway, using PWM API in a clocksource driver that needs to be running very 
early (before any initcalls get called) seems a bit weird for me, especially 
when PWM API doesn't provide such fine grained control over PWM timers that is 
required in the clocksource drivers.

Best regards,
-- 
Tomasz Figa
Samsung Poland R&D Center
SW Solution Development, Kernel and System Framework



From jgunthorpe at obsidianresearch.com  Fri Apr  5 13:48:45 2013
From: jgunthorpe at obsidianresearch.com (Jason Gunthorpe)
Date: Fri, 5 Apr 2013 11:48:45 -0600
Subject: mvebu-mbus: defining a DT binding
In-Reply-To: <201304051928.14119.arnd@arndb.de>
References: <20130405150200.7b6dee63@skate> <201304051636.56410.arnd@arndb.de>
 <20130405170725.GB3598@obsidianresearch.com>
 <201304051928.14119.arnd@arndb.de>
Message-ID: <20130405174845.GD3598@obsidianresearch.com>

On Fri, Apr 05, 2013 at 07:28:13PM +0200, Arnd Bergmann wrote:

> > The Linux PCI core requires a single host bridge aperture, that is
> > what the ranges indicate. It is up to the PCI core to select the
> > address window(s) the PEX will use. When it does this it tells the PCI
> > driver, which tells the MBUS driver, which ultimately creates the
> > window. The address selection must be slaved to the PCI core, the MBUS
> > driver cannot operate autonomously.
> > 
> > This is an unavoidable consequence of merging all the PEX's into a
> > single root complex. If you recall this was required to support the 10
> > PEX case. Cross port address assignment is necessary to avoid address
> > space exhaustion.
> 
> Right, I remembered that already and wrote above that we need to leave
> a single phys_addr_t range for all the PCIe ranges after assigning
> everything else. However, I think the DT representation should still
> reflect what the hardware looks like, meaning that the ranges property
> of the root complex can have one static range for each port, translating
> the 4GB address space of the port to the 4GB mbus window.

The DT representation reflects what the HW looks like 'from the view
point of the PCI-E specification' - which is appropriate since it is a
'device_type=pci' node and has special OF specifications governing its
behaviour.

PCI-E, and the OF PCI bindings want each port to be allocatable within
a 'host aperture', dynamically, based on need. Trying to statically
assign each port's address space in the DT is really struggling
against that :)

Further, there just isn't enough address space to do it. Example:

A system has 3GiB of low RAM, and should support a single VGA card
with a 256MiB BAR - plugged into any PEX port. It has about 512MiB of
low address space to allocate to the PCI host aperture and 10 ports.

It simply cannot be done statically. The kernel must go through all
the PEX's, find the VGA card, allocate 256MiB to that one PEX and then
allocate much smaller amounts to all others.

So, given all of this - can you write out an example PCI controller
DT binding that uses target id in ranges?

This is why I suggested to include the PEX target IDs as meta-data in
the PEX nodes, rather than trying to encode them in ranges.

Jason


From s.nawrocki at samsung.com  Fri Apr  5 13:49:45 2013
From: s.nawrocki at samsung.com (Sylwester Nawrocki)
Date: Fri, 05 Apr 2013 19:49:45 +0200
Subject: [PATCH] clk: exynos4: export clocks required for fimc-is
Message-ID: <1365184185-23794-1-git-send-email-s.nawrocki@samsung.com>

This patch adds clock indexes for ACLK_DIV0, ACLK_DIV1,
ACLK_400_MCUISP, ACLK_MCUISP_DIV0, ACLK_MCUISP_DIV1,
DIVACLK_400_MCUISP and DIVACLK_200 so these clocks are
available to the consumers (Exynos4x12 FIMC-IS subsystem).
While at it, indentation of the mux clocks table is
corrected.

Signed-off-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
---
Rebased onto git://git.kernel.org/pub/scm/linux/kernel/git/
kgene/linux-samsung.git for-next

 .../devicetree/bindings/clock/exynos4-clock.txt    |   42 +++++++++++++-------
 drivers/clk/samsung/clk-exynos4.c                  |   20 ++++++----
 2 files changed, 41 insertions(+), 21 deletions(-)

diff --git a/Documentation/devicetree/bindings/clock/exynos4-clock.txt b/Documentation/devicetree/bindings/clock/exynos4-clock.txt
index 662007e..ea5e26f 100644
--- a/Documentation/devicetree/bindings/clock/exynos4-clock.txt
+++ b/Documentation/devicetree/bindings/clock/exynos4-clock.txt
@@ -236,22 +236,36 @@ Exynos4 SoC and this is specified where applicable.
   spi1_isp_sclk       381     Exynos4x12
   uart_isp_sclk       382     Exynos4x12

-			[Mux Clocks]
+		[Mux Clocks]

-	Clock		ID	SoC (if specific)
-	-----------------------------------------------
+  Clock			ID	SoC (if specific)
+  -----------------------------------------------
+
+  mout_fimc0		384
+  mout_fimc1		385
+  mout_fimc2		386
+  mout_fimc3		387
+  mout_cam0		388
+  mout_cam1		389
+  mout_csis0		390
+  mout_csis1		391
+  mout_g3d0		392
+  mout_g3d1		393
+  mout_g3d		394
+  aclk400_mcuisp	395	Exynos4x12
+
+		[Div Clocks]
+
+  Clock			ID	SoC (if specific)
+  -----------------------------------------------
+
+  div_isp0		450	Exynos4x12
+  div_isp1		451	Exynos4x12
+  div_mcuisp0		452	Exynos4x12
+  div_mcuisp1		453	Exynos4x12
+  div_aclk200		454	Exynos4x12
+  div_aclk400_mcuisp	455	Exynos4x12

-	mout_fimc0	384
-	mout_fimc1	385
-	mout_fimc2	386
-	mout_fimc3	387
-	mout_cam0	388
-	mout_cam1	389
-	mout_csis0	390
-	mout_csis1	391
-	mout_g3d0	392
-	mout_g3d1	393
-	mout_g3d	394

 Example 1: An example of a clock controller node is listed below.

diff --git a/drivers/clk/samsung/clk-exynos4.c b/drivers/clk/samsung/clk-exynos4.c
index 17674da..7104669 100644
--- a/drivers/clk/samsung/clk-exynos4.c
+++ b/drivers/clk/samsung/clk-exynos4.c
@@ -175,6 +175,11 @@ enum exynos4_clks {
 	/* mux clocks */
 	mout_fimc0 = 384, mout_fimc1, mout_fimc2, mout_fimc3, mout_cam0,
 	mout_cam1, mout_csis0, mout_csis1, mout_g3d0, mout_g3d1, mout_g3d,
+	aclk400_mcuisp,
+
+	/* div clocks */
+	div_isp0 = 450, div_isp1, div_mcuisp0, div_mcuisp1, div_aclk200,
+	div_aclk400_mcuisp,

 	nr_clks,
 };
@@ -429,7 +434,7 @@ struct samsung_mux_clock exynos4x12_mux_clks[] __initdata = {
 	MUX(none, "mout_user_aclk266_gps", mout_user_aclk266_gps_p4x12,
 			SRC_TOP1, 16, 1),
 	MUX(aclk200, "aclk200", mout_user_aclk200_p4x12, SRC_TOP1, 20, 1),
-	MUX(none, "aclk400_mcuisp", mout_user_aclk400_mcuisp_p4x12,
+	MUX(aclk400_mcuisp, "aclk400_mcuisp", mout_user_aclk400_mcuisp_p4x12,
 			SRC_TOP1, 24, 1),
 	MUX(none, "mout_aclk200", aclk_p4412, SRC_TOP0, 12, 1),
 	MUX(none, "mout_aclk100", aclk_p4412, SRC_TOP0, 16, 1),
@@ -563,20 +568,21 @@ struct samsung_div_clock exynos4x12_div_clks[] __initdata = {
 	DIV(none, "div_mdnie_pwm_pre0", "div_mdnie_pwm0", DIV_LCD0, 12, 4),
 	DIV(none, "div_mipihsi", "mout_mipihsi", DIV_FSYS0, 20, 4),
 	DIV(none, "div_jpeg", "mout_jpeg", E4X12_DIV_CAM1, 0, 4),
-	DIV(none, "div_aclk200", "mout_aclk200", DIV_TOP, 0, 3),
+	DIV(div_aclk200, "div_aclk200", "mout_aclk200", DIV_TOP, 0, 3),
 	DIV(none, "div_aclk266_gps", "mout_aclk266_gps", DIV_TOP, 20, 3),
-	DIV(none, "div_aclk400_mcuisp", "mout_aclk400_mcuisp", DIV_TOP, 24, 3),
+	DIV(div_aclk400_mcuisp, "div_aclk400_mcuisp", "mout_aclk400_mcuisp",
+						DIV_TOP, 24, 3),
 	DIV(none, "div_pwm_isp", "mout_pwm_isp", E4X12_DIV_ISP, 0, 4),
 	DIV(none, "div_spi0_isp", "mout_spi0_isp", E4X12_DIV_ISP, 4, 4),
 	DIV(none, "div_spi0_isp_pre", "div_spi0_isp", E4X12_DIV_ISP, 8, 8),
 	DIV(none, "div_spi1_isp", "mout_spi1_isp", E4X12_DIV_ISP, 16, 4),
 	DIV(none, "div_spi1_isp_pre", "div_spi1_isp", E4X12_DIV_ISP, 20, 8),
 	DIV(none, "div_uart_isp", "mout_uart_isp", E4X12_DIV_ISP, 28, 4),
-	DIV(none, "div_isp0", "aclk200", E4X12_DIV_ISP0, 0, 3),
-	DIV(none, "div_isp1", "aclk200", E4X12_DIV_ISP0, 4, 3),
+	DIV(div_isp0, "div_isp0", "aclk200", E4X12_DIV_ISP0, 0, 3),
+	DIV(div_isp1, "div_isp1", "aclk200", E4X12_DIV_ISP0, 4, 3),
 	DIV(none, "div_mpwm", "div_isp1", E4X12_DIV_ISP1, 0, 3),
-	DIV(none, "div_mcuisp0", "aclk400_mcuisp", E4X12_DIV_ISP1, 4, 3),
-	DIV(none, "div_mcuisp1", "div_mcuisp0", E4X12_DIV_ISP1, 8, 3),
+	DIV(div_mcuisp0, "div_mcuisp0", "aclk400_mcuisp", E4X12_DIV_ISP1, 4, 3),
+	DIV(div_mcuisp1, "div_mcuisp1", "div_mcuisp0", E4X12_DIV_ISP1, 8, 3),
 };

 /* list of gate clocks supported in all exynos4 soc's */
--
1.7.9.5



From khilman at linaro.org  Fri Apr  5 13:56:03 2013
From: khilman at linaro.org (Kevin Hilman)
Date: Fri, 05 Apr 2013 10:56:03 -0700
Subject: [PATCH 0/5] gpio/omap: 2nd batch of updates for v3.10
In-Reply-To: <1365106576-31816-1-git-send-email-jon-hunter@ti.com> (Jon
 Hunter's message of "Thu, 4 Apr 2013 15:16:11 -0500")
References: <1365106576-31816-1-git-send-email-jon-hunter@ti.com>
Message-ID: <87hajklv4c.fsf@linaro.org>

Jon Hunter <jon-hunter at ti.com> writes:

> Main change is ensuring that the state of a gpio bank is restored when
> booting with device-tree. The rest of the patches are clean-ups and one
> optimisation.
>
> The patch modifying the *.dtsi files should go via Benoit Cousson's
> for_3.10/dts branch [1] as it is dependent on changes in his branch but
> I have included here for completeness.
>
> Testing includes:
> - Boot testing on OMAP5912 OSK, OMAP2420 H4, OMAP3430 SDP, OMAP4430 SDP
>   and AM335x EVM.
> - Verified that GPIO interrupts are working on OMAP5912 OSK, OMAP2420 H4,
>   OMAP3430 SDP and OMAP4430 SDP by making sure networking was working
>   correctly as these boards use a GPIO with the ethernet chips. Also
>   checked /proc/interrupts to ensure GPIO interrupt counts are
>   incrementing as expected.
>
> [1] http://git.kernel.org/cgit/linux/kernel/git/bcousson/linux-omap-dt.git
>
> Jon Hunter (4):
>   gpio/omap: free irq domain in probe() failure paths
>   gpio/omap: optimise interrupt service routine
>   gpio/omap: force restore if context loss is not detectable
>   ARM: dts: OMAP2+: Identify GPIO banks that are always powered
>
> Tarun Kanti DebBarma (1):
>   gpio/omap: remove extra context restores in *_runtime_resume()

For the gpio/omap patches

Reviewed-by: Kevin Hilman <khilman at linaro.org>




From grygorii.strashko at ti.com  Fri Apr  5 13:56:05 2013
From: grygorii.strashko at ti.com (Grygorii Strashko)
Date: Fri, 5 Apr 2013 20:56:05 +0300
Subject: [RFC][PATCH 1/2] ARM: OMAP4: clock: Add device tree support for
 AUXCLKs
In-Reply-To: <20130404164137.GH10155@atomide.com>
References: <1363703220-4777-1-git-send-email-rogerq@ti.com>
 <1363703220-4777-2-git-send-email-rogerq@ti.com>
 <20130403234242.GE10155@atomide.com> <515D2D30.3000306@ti.com>
 <20130404164137.GH10155@atomide.com>
Message-ID: <515F1035.8090500@ti.com>

On 04/04/2013 07:41 PM, Tony Lindgren wrote:
> * Roger Quadros <rogerq at ti.com> [130404 00:39]:
>> On 04/04/2013 02:42 AM, Tony Lindgren wrote:
>>>> --- a/arch/arm/mach-omap2/cclock44xx_data.c
>>>> +++ b/arch/arm/mach-omap2/cclock44xx_data.c
>>>> @@ -27,6 +27,7 @@
>>>>   #include <linux/clk-private.h>
>>>>   #include <linux/clkdev.h>
>>>>   #include <linux/io.h>
>>>> +#include <linux/of.h>
>>>>   
>>>>   #include "soc.h"
>>>>   #include "iomap.h"
>>>> @@ -1663,6 +1664,40 @@ static struct omap_clk omap44xx_clks[] = {
>>>>   	CLK(NULL,	"cpufreq_ck",	&dpll_mpu_ck,	CK_443X),
>>>>   };
>>>>   
>>>> +static struct clk *scrm_clks[] = {
>>>> +	&auxclk0_ck,
>>>> +	&auxclk1_ck,
>>>> +	&auxclk2_ck,
>>>> +	&auxclk3_ck,
>>>> +	&auxclk4_ck,
>>>> +	&auxclk5_ck,
>>>> +};
>>> Hmm I don't like the idea of specifying the auxclk both in the
>>> cclock44xx_data.c and in DT..
>> Right, but till we have all clocks moved to DT we only need this
>> approach for general purpose clocks that are not mapped to devices
>> by hwmod.
> For v3.10, let's just make sure that USB works with DT as then
> after v3.10 we can make omap4 DT only and get rid of estimated
> 7K lines of code and data. I guess this is the last piece missing
> for that, or are we also missing something else?
>
> Can't you set up a clock alias for your device so it can find the
> auxclk when requesting it with the dev entry?
>
> For the DT clock driver if needed for v3.10, how about just do a
> minimal drivers/clock/omap/ that uses the standard binding?
> Then that driver can just do clk_get() from cclock44xx_data.c
> for now? And then later on we'll just move all the clocks to a
> combination of DT + /lib/firmware.
>
Hi Roger, Rajendra, All

Sorry that disturbing you.

I'm supporting Android OMAP4 kernels (K3.0/K3.4) and like to clarify few
points regarding this approach (having into account possible future 
migrations
on newer Kernels and OMAP5).
If I understand everything right, this patch series allows to create 
clock binding
in DT using following syntax: clocks = <&aux_clks 3>
  - does it means that in worst case there will be ~200 clock IDs defined?
  - does it means that clock nodes binding using phandles 
(human-friendly notation)
isn't going to be supported?
for example:
     clocks = <&sys_clkin_ck>
     clocks = <&dss_sys_clk &dss_tv_clk &dss_dss_clk>)

I was horrified to think about the problems of this approach support
(in case if there would be more then ~30 IDs) - just miss with on digit
and weeks of debugging would be guaranteed.

Please, say me that i'm wrong.
And why clock DT data can't be auto-generated like all other OMAP data
to close this questions?

Thanks.

>> e.g. auxclk are required to be specified in DT nodes for USB PHY.
>> Without this we can't get USB host working on Panda.
> OK. So if the USB PHY has a dev entry, can't you just set up a
> clock alias in struct omap_clk omap44xx_clks[] for it?
>   
>> As Rajendra points out, it seems moving entire clock data to DT is not
>> going to happen soon. So this is the simplistic way things can work.
> Right but seems like we can get started there without moving
> them all at once.
>
> Regards,
>
> Tony
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



From g.liakhovetski at gmx.de  Fri Apr  5 14:04:10 2013
From: g.liakhovetski at gmx.de (Guennadi Liakhovetski)
Date: Fri, 5 Apr 2013 20:04:10 +0200 (CEST)
Subject: [PATCH v5 3/3] ARM: shmobile: sh73a0: add CPUFreq support
In-Reply-To: <515EF6C6.6050006@cogentembedded.com>
References: <1365156038-12467-1-git-send-email-g.liakhovetski@gmx.de>
 <1365156038-12467-4-git-send-email-g.liakhovetski@gmx.de>
 <515EF6C6.6050006@cogentembedded.com>
Message-ID: <Pine.LNX.4.64.1304051959500.997@axis700.grange>

Hi Sergei

On Fri, 5 Apr 2013, Sergei Shtylyov wrote:

> On 05-04-2013 14:00, Guennadi Liakhovetski wrote:
> 
> > This patch enables the use of the generic cpufreq-cpu0 driver on sh73a0.
> > Providing a regulator, a list of OPPs in DT, combined with a virtual
> > cpufreq-cpu0 platform device and a clock, attached to it is everything,
> > the cpufreq-cpu0 driver needs. The first sh73a0 platform, implementing
> > such CPUFreq support is kzm9g-reference.
> 
> > Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas at gmail.com>
> > ---
> 
> > v5: remove sh73a0-kzm9g-reference.dts hunk, it's now merged into patch 2/3
> 
> >   arch/arm/mach-shmobile/Kconfig        |    2 ++
> >   arch/arm/mach-shmobile/setup-sh73a0.c |    5 +++++
> >   2 files changed, 7 insertions(+), 0 deletions(-)
> 
> > diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
> > index 1a517e2..4ac5bf9 100644
> > --- a/arch/arm/mach-shmobile/Kconfig
> > +++ b/arch/arm/mach-shmobile/Kconfig
> [...]
> > diff --git a/arch/arm/mach-shmobile/setup-sh73a0.c
> > b/arch/arm/mach-shmobile/setup-sh73a0.c
> > index d10ded0..9a522f9 100644
> > --- a/arch/arm/mach-shmobile/setup-sh73a0.c
> > +++ b/arch/arm/mach-shmobile/setup-sh73a0.c
> > @@ -1003,6 +1003,8 @@ static const struct of_dev_auxdata
> > sh73a0_auxdata_lookup[] __initconst = {
> > 
> >   void __init sh73a0_add_standard_devices_dt(void)
> >   {
> > +	struct platform_device_info devinfo = { .name = "cpufreq-cpu0", .id =
> > -1, };
> 
>    With NULL .parent? Shouldn't it be 'platform_bus'?

Look at platform_device_add():

	if (!pdev->dev.parent)
		pdev->dev.parent = &platform_bus;

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/


From jgunthorpe at obsidianresearch.com  Fri Apr  5 14:04:43 2013
From: jgunthorpe at obsidianresearch.com (Jason Gunthorpe)
Date: Fri, 5 Apr 2013 12:04:43 -0600
Subject: [PATCH 1/5 v2] mv643xx_eth: add Device Tree bindings
In-Reply-To: <CABJ1b_TdzE_Q9qLsdSGZy8byFpCTtVBUy5FtxiZAx7QqgG-rVg@mail.gmail.com>
References: <1365071235-11611-1-git-send-email-florian@openwrt.org>
 <1365071235-11611-2-git-send-email-florian@openwrt.org>
 <20130404212906.GA25904@schnuecks.de>
 <515E9FE0.8050402@openwrt.org>
 <CABJ1b_TdzE_Q9qLsdSGZy8byFpCTtVBUy5FtxiZAx7QqgG-rVg@mail.gmail.com>
Message-ID: <20130405180443.GE3598@obsidianresearch.com>

On Fri, Apr 05, 2013 at 03:58:03PM +0200, Sebastian Hesselbarth wrote:

> I don't think that the ethernet controller should probe the PHY's on mdio-bus
> at all. At least not for DT enabled platforms. I had a look at DT and non-DT
> mdio-bus sources, and realized that there is a bus scan for non-DT only.
> of_mdiobus_register requires you to set (and know) the PHY address.

DT platforms should have the option to use the standard phy-phandle
connection:


		mdio at 72004 {
			#address-cells = <1>;
			#size-cells = <0>;
			compatible = "marvell,orion-mdio";
			reg = <0x72004 0x84>;
			status = "disabled";

+                        PHY1: ethernet-phy at 1 {
+                                reg = <1>;
+                                device_type = "ethernet-phy";
+                        };
		};

		ethernet-group at 72000 {
			#address-cells = <1>;
			#size-cells = <0>;
			compatible = "marvell,mv643xx-eth-block";
			reg = <0x72000 0x4000>;
			tx-csum-limit = <1600>;
			status = "disabled";

			egiga0: ethernet at 0 {
				device_type = "network";
				compatible = "marvell,mv643xx-eth";
				reg = <0>;
				interrupts = <29>;
				clocks = <&gate_clk 2>;
+	                        phy-handle = <&PHY1>;
			};
		};

When phy-handle is present the ethernet driver should not probe/scan for
phys.

There is standard code to handle all of this - an important gain is
that the phy driver now has access to a DT node and can apply
phy-specific properties.

> We had a similar discussion whether to probe or not for DT nodes,
> and I guess there also will be some discussion about the above
> patch. OTOH we could just (again) ask users of every
> kirkwood/orion5x/dove board to tell their phy addresses and fail to
> probe the phy for new boards...

Maybe print a warning and call the no-DT phy probe code if phy-handle
is nor present?

Not sure this should be in the common code, phy probing is sketchy, it
shouldn't be encouraged, IMHO..

Jason


From sergei.shtylyov at cogentembedded.com  Fri Apr  5 14:16:34 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Fri, 05 Apr 2013 22:16:34 +0400
Subject: [PATCH v5 3/3] ARM: shmobile: sh73a0: add CPUFreq support
In-Reply-To: <Pine.LNX.4.64.1304051959500.997@axis700.grange>
References: <1365156038-12467-1-git-send-email-g.liakhovetski@gmx.de>
 <1365156038-12467-4-git-send-email-g.liakhovetski@gmx.de>
 <515EF6C6.6050006@cogentembedded.com>
 <Pine.LNX.4.64.1304051959500.997@axis700.grange>
Message-ID: <515F1502.3080301@cogentembedded.com>

On 04/05/2013 10:04 PM, Guennadi Liakhovetski wrote:

>>> This patch enables the use of the generic cpufreq-cpu0 driver on sh73a0.
>>> Providing a regulator, a list of OPPs in DT, combined with a virtual
>>> cpufreq-cpu0 platform device and a clock, attached to it is everything,
>>> the cpufreq-cpu0 driver needs. The first sh73a0 platform, implementing
>>> such CPUFreq support is kzm9g-reference.
>>> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas at gmail.com>
>>> ---
>>> v5: remove sh73a0-kzm9g-reference.dts hunk, it's now merged into patch 2/3
>>>    arch/arm/mach-shmobile/Kconfig        |    2 ++
>>>    arch/arm/mach-shmobile/setup-sh73a0.c |    5 +++++
>>>    2 files changed, 7 insertions(+), 0 deletions(-)
>>> diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
>>> index 1a517e2..4ac5bf9 100644
>>> --- a/arch/arm/mach-shmobile/Kconfig
>>> +++ b/arch/arm/mach-shmobile/Kconfig
>> [...]
>>> diff --git a/arch/arm/mach-shmobile/setup-sh73a0.c
>>> b/arch/arm/mach-shmobile/setup-sh73a0.c
>>> index d10ded0..9a522f9 100644
>>> --- a/arch/arm/mach-shmobile/setup-sh73a0.c
>>> +++ b/arch/arm/mach-shmobile/setup-sh73a0.c
>>> @@ -1003,6 +1003,8 @@ static const struct of_dev_auxdata
>>> sh73a0_auxdata_lookup[] __initconst = {
>>>
>>>    void __init sh73a0_add_standard_devices_dt(void)
>>>    {
>>> +	struct platform_device_info devinfo = { .name = "cpufreq-cpu0", .id =
>>> -1, };
>>     With NULL .parent? Shouldn't it be 'platform_bus'?
> Look at platform_device_add():
>
> 	if (!pdev->dev.parent)
> 		pdev->dev.parent = &platform_bus;

    Ah, thanks for pointing that out -- I didn't follow the call chain.
I could have passed NULL to platform_device_register_resndata()
too then... Well, now it's too late, and it doesn't matter much anyway.

WBR, Sergei



From robherring2 at gmail.com  Fri Apr  5 14:25:26 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Fri, 05 Apr 2013 13:25:26 -0500
Subject: [PATCH] documentation: iommu: add description of ARM System MMU
 binding
In-Reply-To: <20130405165745.GB17151@mudshark.cambridge.arm.com>
References: <1365094259-24847-1-git-send-email-will.deacon@arm.com>
 <515EFF1A.5030705@gmail.com>
 <20130405165745.GB17151@mudshark.cambridge.arm.com>
Message-ID: <515F1716.70309@gmail.com>

On 04/05/2013 11:57 AM, Will Deacon wrote:
> Hi Rob,
> 
> On Fri, Apr 05, 2013 at 05:43:06PM +0100, Rob Herring wrote:

[...]

>>> +- compatible    : Should be one of "arm,smmu-v1" or "arm,smmu-v2"
>>> +                  depending on the version of the architecture
>>> +                  implemented.
>>
>> We can keep these, but we should have specific models like arm,smmu-400,
>> etc. as well.
> 
> Ok, if distinctions need to be between MMU-400 and a v1 implementation, then
> we can add those strings later.

No, you want to have specific values in the dtb's up front. If there is
something needed later in the kernel, you don't want to require a dtb
update then. Adding future parts later is fine, but we already know what
blocks we have.

Rob



From mturquette at linaro.org  Fri Apr  5 14:32:21 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Fri, 05 Apr 2013 11:32:21 -0700
Subject: [PATCH] clk: exynos4: export clocks required for fimc-is
In-Reply-To: <1365184185-23794-1-git-send-email-s.nawrocki@samsung.com>
References: <1365184185-23794-1-git-send-email-s.nawrocki@samsung.com>
Message-ID: <20130405183221.7302.97946@quantum>

Quoting Sylwester Nawrocki (2013-04-05 10:49:45)
> This patch adds clock indexes for ACLK_DIV0, ACLK_DIV1,
> ACLK_400_MCUISP, ACLK_MCUISP_DIV0, ACLK_MCUISP_DIV1,
> DIVACLK_400_MCUISP and DIVACLK_200 so these clocks are
> available to the consumers (Exynos4x12 FIMC-IS subsystem).
> While at it, indentation of the mux clocks table is
> corrected.
> 
> Signed-off-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
> Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>

Acked-by: Mike Turquette <mturquette at linaro.org>

> ---
> Rebased onto git://git.kernel.org/pub/scm/linux/kernel/git/
> kgene/linux-samsung.git for-next
> 
>  .../devicetree/bindings/clock/exynos4-clock.txt    |   42 +++++++++++++-------
>  drivers/clk/samsung/clk-exynos4.c                  |   20 ++++++----
>  2 files changed, 41 insertions(+), 21 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/clock/exynos4-clock.txt b/Documentation/devicetree/bindings/clock/exynos4-clock.txt
> index 662007e..ea5e26f 100644
> --- a/Documentation/devicetree/bindings/clock/exynos4-clock.txt
> +++ b/Documentation/devicetree/bindings/clock/exynos4-clock.txt
> @@ -236,22 +236,36 @@ Exynos4 SoC and this is specified where applicable.
>    spi1_isp_sclk       381     Exynos4x12
>    uart_isp_sclk       382     Exynos4x12
> 
> -                       [Mux Clocks]
> +               [Mux Clocks]
> 
> -       Clock           ID      SoC (if specific)
> -       -----------------------------------------------
> +  Clock                        ID      SoC (if specific)
> +  -----------------------------------------------
> +
> +  mout_fimc0           384
> +  mout_fimc1           385
> +  mout_fimc2           386
> +  mout_fimc3           387
> +  mout_cam0            388
> +  mout_cam1            389
> +  mout_csis0           390
> +  mout_csis1           391
> +  mout_g3d0            392
> +  mout_g3d1            393
> +  mout_g3d             394
> +  aclk400_mcuisp       395     Exynos4x12
> +
> +               [Div Clocks]
> +
> +  Clock                        ID      SoC (if specific)
> +  -----------------------------------------------
> +
> +  div_isp0             450     Exynos4x12
> +  div_isp1             451     Exynos4x12
> +  div_mcuisp0          452     Exynos4x12
> +  div_mcuisp1          453     Exynos4x12
> +  div_aclk200          454     Exynos4x12
> +  div_aclk400_mcuisp   455     Exynos4x12
> 
> -       mout_fimc0      384
> -       mout_fimc1      385
> -       mout_fimc2      386
> -       mout_fimc3      387
> -       mout_cam0       388
> -       mout_cam1       389
> -       mout_csis0      390
> -       mout_csis1      391
> -       mout_g3d0       392
> -       mout_g3d1       393
> -       mout_g3d        394
> 
>  Example 1: An example of a clock controller node is listed below.
> 
> diff --git a/drivers/clk/samsung/clk-exynos4.c b/drivers/clk/samsung/clk-exynos4.c
> index 17674da..7104669 100644
> --- a/drivers/clk/samsung/clk-exynos4.c
> +++ b/drivers/clk/samsung/clk-exynos4.c
> @@ -175,6 +175,11 @@ enum exynos4_clks {
>         /* mux clocks */
>         mout_fimc0 = 384, mout_fimc1, mout_fimc2, mout_fimc3, mout_cam0,
>         mout_cam1, mout_csis0, mout_csis1, mout_g3d0, mout_g3d1, mout_g3d,
> +       aclk400_mcuisp,
> +
> +       /* div clocks */
> +       div_isp0 = 450, div_isp1, div_mcuisp0, div_mcuisp1, div_aclk200,
> +       div_aclk400_mcuisp,
> 
>         nr_clks,
>  };
> @@ -429,7 +434,7 @@ struct samsung_mux_clock exynos4x12_mux_clks[] __initdata = {
>         MUX(none, "mout_user_aclk266_gps", mout_user_aclk266_gps_p4x12,
>                         SRC_TOP1, 16, 1),
>         MUX(aclk200, "aclk200", mout_user_aclk200_p4x12, SRC_TOP1, 20, 1),
> -       MUX(none, "aclk400_mcuisp", mout_user_aclk400_mcuisp_p4x12,
> +       MUX(aclk400_mcuisp, "aclk400_mcuisp", mout_user_aclk400_mcuisp_p4x12,
>                         SRC_TOP1, 24, 1),
>         MUX(none, "mout_aclk200", aclk_p4412, SRC_TOP0, 12, 1),
>         MUX(none, "mout_aclk100", aclk_p4412, SRC_TOP0, 16, 1),
> @@ -563,20 +568,21 @@ struct samsung_div_clock exynos4x12_div_clks[] __initdata = {
>         DIV(none, "div_mdnie_pwm_pre0", "div_mdnie_pwm0", DIV_LCD0, 12, 4),
>         DIV(none, "div_mipihsi", "mout_mipihsi", DIV_FSYS0, 20, 4),
>         DIV(none, "div_jpeg", "mout_jpeg", E4X12_DIV_CAM1, 0, 4),
> -       DIV(none, "div_aclk200", "mout_aclk200", DIV_TOP, 0, 3),
> +       DIV(div_aclk200, "div_aclk200", "mout_aclk200", DIV_TOP, 0, 3),
>         DIV(none, "div_aclk266_gps", "mout_aclk266_gps", DIV_TOP, 20, 3),
> -       DIV(none, "div_aclk400_mcuisp", "mout_aclk400_mcuisp", DIV_TOP, 24, 3),
> +       DIV(div_aclk400_mcuisp, "div_aclk400_mcuisp", "mout_aclk400_mcuisp",
> +                                               DIV_TOP, 24, 3),
>         DIV(none, "div_pwm_isp", "mout_pwm_isp", E4X12_DIV_ISP, 0, 4),
>         DIV(none, "div_spi0_isp", "mout_spi0_isp", E4X12_DIV_ISP, 4, 4),
>         DIV(none, "div_spi0_isp_pre", "div_spi0_isp", E4X12_DIV_ISP, 8, 8),
>         DIV(none, "div_spi1_isp", "mout_spi1_isp", E4X12_DIV_ISP, 16, 4),
>         DIV(none, "div_spi1_isp_pre", "div_spi1_isp", E4X12_DIV_ISP, 20, 8),
>         DIV(none, "div_uart_isp", "mout_uart_isp", E4X12_DIV_ISP, 28, 4),
> -       DIV(none, "div_isp0", "aclk200", E4X12_DIV_ISP0, 0, 3),
> -       DIV(none, "div_isp1", "aclk200", E4X12_DIV_ISP0, 4, 3),
> +       DIV(div_isp0, "div_isp0", "aclk200", E4X12_DIV_ISP0, 0, 3),
> +       DIV(div_isp1, "div_isp1", "aclk200", E4X12_DIV_ISP0, 4, 3),
>         DIV(none, "div_mpwm", "div_isp1", E4X12_DIV_ISP1, 0, 3),
> -       DIV(none, "div_mcuisp0", "aclk400_mcuisp", E4X12_DIV_ISP1, 4, 3),
> -       DIV(none, "div_mcuisp1", "div_mcuisp0", E4X12_DIV_ISP1, 8, 3),
> +       DIV(div_mcuisp0, "div_mcuisp0", "aclk400_mcuisp", E4X12_DIV_ISP1, 4, 3),
> +       DIV(div_mcuisp1, "div_mcuisp1", "div_mcuisp0", E4X12_DIV_ISP1, 8, 3),
>  };
> 
>  /* list of gate clocks supported in all exynos4 soc's */
> --
> 1.7.9.5


From sebastian.hesselbarth at gmail.com  Fri Apr  5 16:35:41 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Fri, 05 Apr 2013 22:35:41 +0200
Subject: [PATCH 1/5 v2] mv643xx_eth: add Device Tree bindings
In-Reply-To: <20130405180443.GE3598@obsidianresearch.com>
References: <1365071235-11611-1-git-send-email-florian@openwrt.org>
 <1365071235-11611-2-git-send-email-florian@openwrt.org>
 <20130404212906.GA25904@schnuecks.de> <515E9FE0.8050402@openwrt.org>
 <CABJ1b_TdzE_Q9qLsdSGZy8byFpCTtVBUy5FtxiZAx7QqgG-rVg@mail.gmail.com>
 <20130405180443.GE3598@obsidianresearch.com>
Message-ID: <515F359D.7000306@gmail.com>

On 04/05/2013 08:04 PM, Jason Gunthorpe wrote:
> On Fri, Apr 05, 2013 at 03:58:03PM +0200, Sebastian Hesselbarth wrote:
>> I don't think that the ethernet controller should probe the PHY's on mdio-bus
>> at all. At least not for DT enabled platforms. I had a look at DT and non-DT
>> mdio-bus sources, and realized that there is a bus scan for non-DT only.
>> of_mdiobus_register requires you to set (and know) the PHY address.
>
> DT platforms should have the option to use the standard phy-phandle
> connection:
>
>
> 		mdio at 72004 {
> 			#address-cells =<1>;
> 			#size-cells =<0>;
> 			compatible = "marvell,orion-mdio";
> 			reg =<0x72004 0x84>;
> 			status = "disabled";
>
> +                        PHY1: ethernet-phy at 1 {
> +                                reg =<1>;
> +                                device_type = "ethernet-phy";
> +                        };
> 		};
>
> 		ethernet-group at 72000 {
> 			#address-cells =<1>;
> 			#size-cells =<0>;
> 			compatible = "marvell,mv643xx-eth-block";
> 			reg =<0x72000 0x4000>;
> 			tx-csum-limit =<1600>;
> 			status = "disabled";
>
> 			egiga0: ethernet at 0 {
> 				device_type = "network";
> 				compatible = "marvell,mv643xx-eth";
> 				reg =<0>;
> 				interrupts =<29>;
> 				clocks =<&gate_clk 2>;
> +	                        phy-handle =<&PHY1>;
> 			};
> 		};
>
> When phy-handle is present the ethernet driver should not probe/scan for
> phys.
>
> There is standard code to handle all of this - an important gain is
> that the phy driver now has access to a DT node and can apply
> phy-specific properties.

The above is what I use as a modification of Florian's patches.
I compared of_mdiobus_register against mdiobus_register. The difference
is that DT version does not scan the bus for attached PHYs. That is ok,
if you know the phy_address of the PHY that you pass the handle of. But 
in most cases there will be only one PHY on the mdiobus and especially
for new boards probing will help here.

>> We had a similar discussion whether to probe or not for DT nodes,
>> and I guess there also will be some discussion about the above
>> patch. OTOH we could just (again) ask users of every
>> kirkwood/orion5x/dove board to tell their phy addresses and fail to
>> probe the phy for new boards...
>
> Maybe print a warning and call the no-DT phy probe code if phy-handle
> is nor present?

I think it would be best to spam each probing result during mdiobus
scan to encourage people to edit the DT and put in the phy_addr
directly. IMHO it will be best to have bus scan on mdiobus rather than
ethernet driver.

> Not sure this should be in the common code, phy probing is sketchy, it
> shouldn't be encouraged, IMHO..

Actually, it is in common code (non-DT case) and I think passing the
phy_addr by DT node like above is best. But for boards you don't
know the address (yet) probing helps a lot. If all phy nodes have their
reg property set, no probing will be performed.

For testing mdio bus probe, I used

mdio {
	...
	ethphy: ethernet-phy {
		reg = <32>;
	};
};

And 32 should be defined as OF_PHY_ADDR_AUTOSCAN. It is an invalid
address as max phy_addr is 31. I also thought about a bool property
but passing an invalid reg property in SoC file allows to overwrite
it in board file with the actual address easily.
And AFAIK bool properties cannot be removed later on by board specific
nodes.

Sebastian


From swarren at wwwdotorg.org  Fri Apr  5 14:46:50 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Fri,  5 Apr 2013 12:46:50 -0600
Subject: [GIT PULL] dt: run C pre-processor on *.dts,
 create some standard headers
Message-ID: <1365187610-29422-1-git-send-email-swarren@wwwdotorg.org>

Rob, it might be worth keeping this in a separate branch in linux-next
so you can pull it out if it causes any issues. I've been using these
patches for quite a while now, but there's always opportunity for
surprises on architectures I don't use. I did just fix a bug when
building with O= a few days back, hence the V2 that I posted as patches.

----------------------------------------------------------------

This branch enhances the support for running dtc on device tree files.

A dedicated directory is created for header files that provide constants
for device-tree bindings.

The kbuild dependency script processor is enhanced to support processing
the dependency outputs from multiple separate commands at once.

The kbuild dtc rule is modified so that the C pre-processor is always
applied when compiling any device tree.

Some standard headers are created which define common constants for GPIO,
IRQ, and ARM GIC device tree bindings.

----------------------------------------------------------------

The following changes since commit 6dbe51c251a327e012439c4772097a13df43c5b8:

  Linux 3.9-rc1

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra.git tegra-for-3.10-dtc-cpp-chroot-std-headers

for you to fetch changes up to 4be505d4fc7a07371a2b658469ca1dda99993ca3:

  ARM: dt: create a DT header for the GIC

----------------------------------------------------------------

Stephen Warren (7):
      kbuild: create an "include chroot" for DT bindings
      kbuild: fixdep: support concatenated dep files
      kbuild: cmd_dtc_cpp: extract deps from both gcc -E and dtc
      kbuild: always run gcc -E on *.dts, remove cmd_dtc_cpp
      ARM: dt: add header to define GPIO flags
      ARM: dt: add header to define IRQ flags
      ARM: dt: create a DT header for the GIC

 arch/arm/boot/dts/include/dt-bindings           |    1 +
 include/dt-bindings/gpio/gpio.h                 |   15 +++
 .../dt-bindings/interrupt-controller/arm-gic.h  |   22 +++++
 include/dt-bindings/interrupt-controller/irq.h  |   19 ++++
 scripts/Makefile.lib                            |   17 ++--
 scripts/basic/fixdep.c                          |   93 ++++++++++++------
 6 files changed, 125 insertions(+), 42 deletions(-)
 create mode 120000 arch/arm/boot/dts/include/dt-bindings
 create mode 100644 include/dt-bindings/gpio/gpio.h
 create mode 100644 include/dt-bindings/interrupt-controller/arm-gic.h
 create mode 100644 include/dt-bindings/interrupt-controller/irq.h


From sergei.shtylyov at cogentembedded.com  Fri Apr  5 14:46:37 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Fri, 05 Apr 2013 22:46:37 +0400
Subject: [PATCH 1/8] ARM: shmobile:Marzen: move USB EHCI, OHCI, and PHY
 devices to R8A7779 code
In-Reply-To: <515EF217.2010109@cogentembedded.com>
References: <201304050257.00799.sergei.shtylyov@cogentembedded.com>
 <20130405004147.GN29203@verge.net.au> <515EF217.2010109@cogentembedded.com>
Message-ID: <515F1C0D.4010703@cogentembedded.com>

On 04/05/2013 07:47 PM, Sergei Shtylyov wrote:

>
>>> USB EHCI, OHCI, and common PHY are the SoC devices but are wrongly 
>>> defined and
>>> registered in the Marzen board file.  Move the data and code to 
>>> their proper
>>> place in setup-r8a7779.c; while at it, we have to rename 
>>> 8a7779_late_devices[]
>>> to 8a7779_standard_devices[] -- this seems legitimate since they are 
>>> registered
>>> from r8a7779_add_standard_devices() anyway.
>
>>> Note that I'm deliberately changing the USB PHY platform device's 
>>> 'id' field
>>> from (previously just omitted) 0 to -1 as the device is a single of 
>>> its kind.
>
>> Would it be possible to re-arange this patch so that
>> there is an SoC patch followed by a board patch?
>
>    I seriously doubt it, thought I'll try to think about it more.

     I gave it an extra thought and came to nothing. The patch is 
completely atomic,
splitting it up in any way will break USB support on Marzen. Sorry to 
say that but the
code I'm fixing is really that messed up.

WBR, Sergei



From robherring2 at gmail.com  Fri Apr  5 14:54:45 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Fri, 05 Apr 2013 13:54:45 -0500
Subject: [GIT PULL] dt: run C pre-processor on *.dts, create some standard
 headers
In-Reply-To: <1365187610-29422-1-git-send-email-swarren@wwwdotorg.org>
References: <1365187610-29422-1-git-send-email-swarren@wwwdotorg.org>
Message-ID: <515F1DF5.3070601@gmail.com>

On 04/05/2013 01:46 PM, Stephen Warren wrote:
> Rob, it might be worth keeping this in a separate branch in linux-next
> so you can pull it out if it causes any issues. I've been using these
> patches for quite a while now, but there's always opportunity for
> surprises on architectures I don't use. I did just fix a bug when
> building with O= a few days back, hence the V2 that I posted as patches.
> 

No, you're on the hook to fix anything. :) My next branch is pulled by
Grant and is not rebased. Perhaps we should change that, but it's not
going to happen right away.

Rob

> ----------------------------------------------------------------
> 
> This branch enhances the support for running dtc on device tree files.
> 
> A dedicated directory is created for header files that provide constants
> for device-tree bindings.
> 
> The kbuild dependency script processor is enhanced to support processing
> the dependency outputs from multiple separate commands at once.
> 
> The kbuild dtc rule is modified so that the C pre-processor is always
> applied when compiling any device tree.
> 
> Some standard headers are created which define common constants for GPIO,
> IRQ, and ARM GIC device tree bindings.
> 
> ----------------------------------------------------------------
> 
> The following changes since commit 6dbe51c251a327e012439c4772097a13df43c5b8:
> 
>   Linux 3.9-rc1
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra.git tegra-for-3.10-dtc-cpp-chroot-std-headers
> 
> for you to fetch changes up to 4be505d4fc7a07371a2b658469ca1dda99993ca3:
> 
>   ARM: dt: create a DT header for the GIC
> 
> ----------------------------------------------------------------
> 
> Stephen Warren (7):
>       kbuild: create an "include chroot" for DT bindings
>       kbuild: fixdep: support concatenated dep files
>       kbuild: cmd_dtc_cpp: extract deps from both gcc -E and dtc
>       kbuild: always run gcc -E on *.dts, remove cmd_dtc_cpp
>       ARM: dt: add header to define GPIO flags
>       ARM: dt: add header to define IRQ flags
>       ARM: dt: create a DT header for the GIC
> 
>  arch/arm/boot/dts/include/dt-bindings           |    1 +
>  include/dt-bindings/gpio/gpio.h                 |   15 +++
>  .../dt-bindings/interrupt-controller/arm-gic.h  |   22 +++++
>  include/dt-bindings/interrupt-controller/irq.h  |   19 ++++
>  scripts/Makefile.lib                            |   17 ++--
>  scripts/basic/fixdep.c                          |   93 ++++++++++++------
>  6 files changed, 125 insertions(+), 42 deletions(-)
>  create mode 120000 arch/arm/boot/dts/include/dt-bindings
>  create mode 100644 include/dt-bindings/gpio/gpio.h
>  create mode 100644 include/dt-bindings/interrupt-controller/arm-gic.h
>  create mode 100644 include/dt-bindings/interrupt-controller/irq.h
> 



From nicolas.pitre at linaro.org  Fri Apr  5 15:36:06 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Fri, 5 Apr 2013 15:36:06 -0400 (EDT)
Subject: [PATCH v6 4/4] xen/arm: introduce xen_early_init, use PSCI on xen
In-Reply-To: <alpine.DEB.2.02.1304051725580.21065@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1304031239550.5078@kaball.uk.xensource.com>
 <1365167495-18508-4-git-send-email-stefano.stabellini@eu.citrix.com>
 <alpine.LFD.2.03.1304051217560.1171@syhkavp.arg>
 <alpine.DEB.2.02.1304051725580.21065@kaball.uk.xensource.com>
Message-ID: <alpine.LFD.2.03.1304051324190.1171@syhkavp.arg>

On Fri, 5 Apr 2013, Stefano Stabellini wrote:

> This is what happens:
> 
> - No Xen
> Xen is not running on the platform and a Xen hypervisor node is not
> available on device tree.
> Everything keeps working seamlessly, this patch doesn't change anything.
> 
> - we are running on Xen
> Xen is running on the platform, we are running as a guest on Xen and an
> hypervisor node is available on device tree.
> Let's also assume that there aren't any "arm,cci" compatible nodes on
> device tree because Xen wouldn't export this kind of information to any
> guests right now. Therefore PSCI should be used to boot secondary cpus.
> Because the versatile express machine sets smp_init to
> vexpress_smp_init_ops, vexpress_smp_init_ops will be called.
> vexpress_smp_init_ops sets smp_ops to vexpress_smp_ops, that *break*
> Xen.

OK I see.

> With this patch, xen_smp_init will be called instead of
> vexpress_smp_init_ops, and smp_ops will be set to psci_smp_ops,
> therefore *unbreaking* Xen.

However that breaks MCPM.

> In fact what makes this patch really necessary is smp_init together with
> the MCPM series.

Yes.

> Do you agree with me?

On the Xen issue, yes.


Nicolas


From nicolas.pitre at linaro.org  Fri Apr  5 15:41:36 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Fri, 5 Apr 2013 15:41:36 -0400 (EDT)
Subject: [PATCH v6 4/4] xen/arm: introduce xen_early_init, use PSCI on xen
In-Reply-To: <alpine.DEB.2.02.1304051825390.21065@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1304031239550.5078@kaball.uk.xensource.com>
 <1365167495-18508-4-git-send-email-stefano.stabellini@eu.citrix.com>
 <alpine.LFD.2.03.1304051217560.1171@syhkavp.arg>
 <alpine.DEB.2.02.1304051725580.21065@kaball.uk.xensource.com>
 <alpine.DEB.2.02.1304051825390.21065@kaball.uk.xensource.com>
Message-ID: <alpine.LFD.2.03.1304051536250.1171@syhkavp.arg>

On Fri, 5 Apr 2013, Stefano Stabellini wrote:

> On Fri, 5 Apr 2013, Stefano Stabellini wrote:
> > - we are running on Xen
> > Xen is running on the platform, we are running as a guest on Xen and an
> > hypervisor node is available on device tree.
> > Let's also assume that there aren't any "arm,cci" compatible nodes on
> > device tree because Xen wouldn't export this kind of information to any
> > guests right now. Therefore PSCI should be used to boot secondary cpus.
> 
> Just in case this isn't clear enough: we don't have big.LITTLE support 
> in Xen right now, not in the hypervisor and certainly not in guests. 
> I'm keen on having big.LITTLE support in the hypervisor (thus some 
> code similar to your MCPM patch series will probably end up in Xen at 
> some point) but I doubt we'll expose big.LITTLE to guests any time 
> soon. It's going to be years, so I am not particularly worried about 
> it right now.

I fully understand that it is unlikely that a Xen guest will "see" a 
big.LITTLE environment in the near future.

My concern is about a kernel that is _configured_ to run either on a 
native VExpress machine that might or might not be b.L, or as a Xen 
guest, in the same zImage binary.


Nicolas


From arnd at arndb.de  Fri Apr  5 15:49:33 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 5 Apr 2013 21:49:33 +0200
Subject: mvebu-mbus: defining a DT binding
In-Reply-To: <20130405174845.GD3598@obsidianresearch.com>
References: <20130405150200.7b6dee63@skate> <201304051928.14119.arnd@arndb.de>
 <20130405174845.GD3598@obsidianresearch.com>
Message-ID: <201304052149.33533.arnd@arndb.de>

On Friday 05 April 2013, Jason Gunthorpe wrote:
> The DT representation reflects what the HW looks like 'from the view
> point of the PCI-E specification' - which is appropriate since it is a
> 'device_type=pci' node and has special OF specifications governing its
> behaviour.
> 
> PCI-E, and the OF PCI bindings want each port to be allocatable within
> a 'host aperture', dynamically, based on need. Trying to statically
> assign each port's address space in the DT is really struggling
> against that :)

I did not say anything about assigning the phys_addr_t range of
the port in DT, quite the contrary. What I meant is to describe
how a bus address on any of the PCIe ports is wired to the
mbus, which is really a 4GB space per port.

> Further, there just isn't enough address space to do it. Example:
> 
> A system has 3GiB of low RAM, and should support a single VGA card
> with a 256MiB BAR - plugged into any PEX port. It has about 512MiB of
> low address space to allocate to the PCI host aperture and 10 ports.
> 
> It simply cannot be done statically. The kernel must go through all
> the PEX's, find the VGA card, allocate 256MiB to that one PEX and then
> allocate much smaller amounts to all others.

Not what I meant.

> So, given all of this - can you write out an example PCI controller
> DT binding that uses target id in ranges?
> 
> This is why I suggested to include the PEX target IDs as meta-data in
> the PEX nodes, rather than trying to encode them in ranges.

I mean something like

/ {
	#address-cells = <1>;
	#size-cells = <1>;

	mbus {
		#address-cells = <2>;
		#size-cells = <1>;

		/* ignore the specific encoding here */

		ranges = <0x1 0 0xd0000000 0x100000>, /* internal regs */
			 <0xa 0xc0000000 0xc0000000 0x10000> /* PCI port a,
							already assigned */


		internal-bus {
			#address-cells = <1>;
			#size-cells = <0>;
			ranges = <0x1 0 0 0x100000>;
	
			...
		};


		pcie {
			#address-cells = <3>;
			#size-cells = <2>;

			ranges = <0x82000800 0 0 0xa 0 0x1 0>, # port a
				 <0x82001000 0 0 0xb 0 0x1 0>, # port b
				 <0x82001800 0 0 0xc 0 0x1 0>, # port c
				 <0x82002000 0 0 0xd 0 0x1 0>, # port d
				 <0x82002800 0 0 0xe 0 0x1 0>; # port e

			pci { /* port a at device 000800*/
				/* only decodes range 0xc0000000 to 0xc0010000 */
				ranges = <0x82000800 0 0xc0000000 0x82000800 0 0xc0000000 0 0x10000>;
			};
			pci { /* port b at device 001000 */
				/* or just translate everything, to be more sloppy ;-) */
				ranges;
			};
		};
	};
};

	Arnd


From arnd at arndb.de  Fri Apr  5 15:54:21 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 5 Apr 2013 21:54:21 +0200
Subject: [PATCH v4 04/14] mfd: Add Samsung PWM/timer master driver
In-Reply-To: <19231120.yHlZtTPUMd@amdc1227>
References: <1365093431-30621-1-git-send-email-t.figa@samsung.com>
 <201304051905.24644.arnd@arndb.de> <19231120.yHlZtTPUMd@amdc1227>
Message-ID: <201304052154.21361.arnd@arndb.de>

On Friday 05 April 2013, Tomasz Figa wrote:
> > I don't think anyone ever suggested using a private API though.
> 
> I must have gotten the last paragraph of
> http://article.gmane.org/gmane.linux.kernel.samsung-soc/16638
> wrong then. For me it seemed like the timer driver would expose a private API 
> to the PWM driver.

Yes, sorry I wasn't clear enough. I meant a register-level interface
exposed from the base driver, not a high-level interface like you
did.

> > I think
> > it's ok if the driver lives in drivers/mfd when it doesn't fit anywhere
> > else easily, but you should really register it to the pwm subsystem to
> > expose that functionality, not export functions that can be used by
> > a pwm shim driver, which even seems to be missing from the series.
> 
> Anyway, using PWM API in a clocksource driver that needs to be running very 
> early (before any initcalls get called) seems a bit weird for me, especially 
> when PWM API doesn't provide such fine grained control over PWM timers that is 
> required in the clocksource drivers.

Exactly, that's why you should have a regular PWM driver that gets loaded
at a convenient time and just uses an interface exported by the base driver
to access the common registers.

	Arnd


From swarren at wwwdotorg.org  Fri Apr  5 15:55:24 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Fri, 05 Apr 2013 13:55:24 -0600
Subject: My vacation schedule Apr 17-May 1
Message-ID: <515F2C2C.5050605@wwwdotorg.org>

FYI, I'm on vacation/holiday Wed Apr 17th through Wed May 1st. It's
still TBD exactly how much email access I'll have during that time.
Hopefully some, but likely not high volume. I'm
unlikely-to-definitely-won't be doing much in the way of
review/coding/applying patches.

Since this co-incides mostly with the merge window, I don't anticipate
too many problems. Here's hoping:-)

(I'm in two minds whether to spam the main ARM kernel list with this;
hopefully I made the right choice!)


From sboyd at codeaurora.org  Fri Apr  5 16:12:05 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Fri, 05 Apr 2013 13:12:05 -0700
Subject: [PATCH] ARM: arch_timer: Silence debug preempt warnings
In-Reply-To: <515EA195.4010307@arm.com>
References: <1364934672-31554-1-git-send-email-sboyd@codeaurora.org>
 <515E5CFC.4090900@codeaurora.org> <515EA195.4010307@arm.com>
Message-ID: <515F3015.6010107@codeaurora.org>

On 04/05/13 03:04, Marc Zyngier wrote:
>
>>>  drivers/clocksource/arm_arch_timer.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
>>> index d7ad425..5928c29 100644
>>> --- a/drivers/clocksource/arm_arch_timer.c
>>> +++ b/drivers/clocksource/arm_arch_timer.c
>>> @@ -248,7 +248,7 @@ static void __cpuinit arch_timer_stop(struct clock_event_device *clk)
>>>  static int __cpuinit arch_timer_cpu_notify(struct notifier_block *self,
>>>  					   unsigned long action, void *hcpu)
>>>  {
>>> -	struct clock_event_device *evt = this_cpu_ptr(arch_timer_evt);
>>> +	struct clock_event_device *evt = __this_cpu_ptr(arch_timer_evt);
>>>  
>>>  	switch (action & ~CPU_TASKS_FROZEN) {
>>>  	case CPU_STARTING:
> I'm afraid this would hide bugs if we start using the notifier for other
> purposes than exclusivity non-preemptible contexts.
>
> How about moving the this_cpu_ptr() down to the cases themselves, maybe
> with a nice comment?

Ok. v2 coming up.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation



From gregory.clement at free-electrons.com  Fri Apr  5 16:23:56 2013
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Fri,  5 Apr 2013 22:23:56 +0200
Subject: [PATCH v2 1/9] arm: mvebu: Limit the DMA zone when LPAE is selected
In-Reply-To: <1365193444-13441-1-git-send-email-gregory.clement@free-electrons.com>
References: <1365193444-13441-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1365193444-13441-2-git-send-email-gregory.clement@free-electrons.com>

When LPAE is activated on Armada XP, all registers and IOs are still
32bit, the 40bit extension is on the CPU to DRAM path (windows) only.
That means that all the DMA transfer are restricted to the low 32 bits
address space. This is limitation is achieved by selecting ZONE_DMA.

Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
---
 arch/arm/mach-mvebu/Kconfig |    1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index 440b13e..db1bbc8 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -13,6 +13,7 @@ config ARCH_MVEBU
 	select MVEBU_CLK_CORE
 	select MVEBU_CLK_CPU
 	select MVEBU_CLK_GATING
+	select ZONE_DMA if ARM_LPAE
 
 if ARCH_MVEBU
 
-- 
1.7.9.5



From gregory.clement at free-electrons.com  Fri Apr  5 16:23:57 2013
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Fri,  5 Apr 2013 22:23:57 +0200
Subject: [PATCH v2 2/9] arm: mvebu: Align the internal registers virtual base
 to support LPAE
In-Reply-To: <1365193444-13441-1-git-send-email-gregory.clement@free-electrons.com>
References: <1365193444-13441-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1365193444-13441-3-git-send-email-gregory.clement@free-electrons.com>

From: Lior Amsalem <alior at marvell.com>

In order to be able to support he LPAE, the internal registers virtual
base must be aligned to 2MB.

Signed-off-by: Lior Amsalem <alior at marvell.com>
Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
---
 arch/arm/include/debug/mvebu.S      |    2 +-
 arch/arm/mach-mvebu/armada-370-xp.h |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/include/debug/mvebu.S b/arch/arm/include/debug/mvebu.S
index 865c6d0..df191af 100644
--- a/arch/arm/include/debug/mvebu.S
+++ b/arch/arm/include/debug/mvebu.S
@@ -12,7 +12,7 @@
 */
 
 #define ARMADA_370_XP_REGS_PHYS_BASE	0xd0000000
-#define ARMADA_370_XP_REGS_VIRT_BASE	0xfeb00000
+#define ARMADA_370_XP_REGS_VIRT_BASE	0xfec00000
 
 	.macro	addruart, rp, rv, tmp
 	ldr	\rp, =ARMADA_370_XP_REGS_PHYS_BASE
diff --git a/arch/arm/mach-mvebu/armada-370-xp.h b/arch/arm/mach-mvebu/armada-370-xp.h
index c6a7d74..c49c08e 100644
--- a/arch/arm/mach-mvebu/armada-370-xp.h
+++ b/arch/arm/mach-mvebu/armada-370-xp.h
@@ -16,7 +16,7 @@
 #define __MACH_ARMADA_370_XP_H
 
 #define ARMADA_370_XP_REGS_PHYS_BASE	0xd0000000
-#define ARMADA_370_XP_REGS_VIRT_BASE	IOMEM(0xfeb00000)
+#define ARMADA_370_XP_REGS_VIRT_BASE	IOMEM(0xfec00000)
 #define ARMADA_370_XP_REGS_SIZE		SZ_1M
 
 #ifdef CONFIG_SMP
-- 
1.7.9.5



From gregory.clement at free-electrons.com  Fri Apr  5 16:23:59 2013
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Fri,  5 Apr 2013 22:23:59 +0200
Subject: [PATCH v2 4/9] arm: dts: Add a 64 bits version of the skeleton device
 tree
In-Reply-To: <1365193444-13441-1-git-send-email-gregory.clement@free-electrons.com>
References: <1365193444-13441-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1365193444-13441-5-git-send-email-gregory.clement@free-electrons.com>

From: Lior Amsalem <alior at marvell.com>

In order to be able to use more than 4GB address-cells and size-cells
have to be set to 2

Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
Signed-off-by: Lior Amsalem <alior at marvell.com>
---
 arch/arm/boot/dts/skeleton64.dtsi |   13 +++++++++++++
 1 file changed, 13 insertions(+)
 create mode 100644 arch/arm/boot/dts/skeleton64.dtsi

diff --git a/arch/arm/boot/dts/skeleton64.dtsi b/arch/arm/boot/dts/skeleton64.dtsi
new file mode 100644
index 0000000..1599415
--- /dev/null
+++ b/arch/arm/boot/dts/skeleton64.dtsi
@@ -0,0 +1,13 @@
+/*
+ * Skeleton device tree in the 64 bits version; the bare minimum
+ * needed to boot; just include and add a compatible value.  The
+ * bootloader will typically populate the memory node.
+ */
+
+/ {
+	#address-cells = <2>;
+	#size-cells = <2>;
+	chosen { };
+	aliases { };
+	memory { device_type = "memory"; reg = <0 0>; };
+};
-- 
1.7.9.5



From gregory.clement at free-electrons.com  Fri Apr  5 16:23:58 2013
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Fri,  5 Apr 2013 22:23:58 +0200
Subject: [PATCH v2 3/9] arm: mvebu: Enable pj4b on LPAE compilations
In-Reply-To: <1365193444-13441-1-git-send-email-gregory.clement@free-electrons.com>
References: <1365193444-13441-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1365193444-13441-4-git-send-email-gregory.clement@free-electrons.com>

From: Lior Amsalem <alior at marvell.com>

pj4b cpus are LPAE capable so enable them on LPAE compilations

Signed-off-by: Lior Amsalem <alior at marvell.com>
Tested-by: Franklin <flin at marvell.com>
Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
---
 arch/arm/mm/proc-v7.S |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
index 3a3c015..159c747 100644
--- a/arch/arm/mm/proc-v7.S
+++ b/arch/arm/mm/proc-v7.S
@@ -402,6 +402,8 @@ __v7_ca9mp_proc_info:
 	__v7_proc __v7_ca9mp_setup
 	.size	__v7_ca9mp_proc_info, . - __v7_ca9mp_proc_info
 
+#endif	/* CONFIG_ARM_LPAE */
+
 	/*
 	 * Marvell PJ4B processor.
 	 */
@@ -411,7 +413,6 @@ __v7_pj4b_proc_info:
 	.long	0xfffffff0
 	__v7_proc __v7_pj4b_setup
 	.size	__v7_pj4b_proc_info, . - __v7_pj4b_proc_info
-#endif	/* CONFIG_ARM_LPAE */
 
 	/*
 	 * ARM Ltd. Cortex A7 processor.
-- 
1.7.9.5



From gregory.clement at free-electrons.com  Fri Apr  5 16:23:55 2013
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Fri,  5 Apr 2013 22:23:55 +0200
Subject: [PATCH v2 0/9] rm: mvebu: Enable LPAE support for Armada XP SoCs
Message-ID: <1365193444-13441-1-git-send-email-gregory.clement@free-electrons.com>

Hello,

The Armada XP SoCs have LPAE support. This is the second version patch
set whixh allow to run kernel on this SoCs with LPAE support.

The biggest changes are the conversion of the device tree file to 64
bits in order to be able to use more than 4GB of memory (without this
the LPAE is pointless).

The main change since the first version is the usage of the range
property as suggested by Rob Herring. As this massive change on the
dts file will have an impact on the mvebu-mbus driver binding, I also
added some patches from Thomas Petazzoni. The purpose is to avoid a
new big change in the devices tree files when Thomas will improve the
mvebu-mbus driver to rely on the device tree.

The other point is about DMA usage. LPAE allows to use 40bits address
only between CPU and DRAM. All the DMA transfer are restricted to the
low 32 bits address space. The first version try to use DMABOUNCE to
allows DMA transfer from any place in memory. There were a consensus
on the fact that was a something to avoid. The alternative was
swiotlb, however it will require a large rewrite of
arch/arm/mach-mvebu/coherency.c (our dma_map_ops was defined here),
and we are close the opening of the merge window. So I chose, in a
first phase, to use ZONE_DMA to limit the use of the DMA on the 32
bits address space. Later our dma_map_ops would be improve with
swiotlb.

This new patch set have been tested on a Armada XP GP board with 8GB
of DRAM with LPAE selected. It have been tested on Armada XP DB board
with 3GB of DRAM with and without LPAE. And also on the Armada 370 DB
board (without LPAE) to check that no regression appeared.

This patch set is based on 3.9-rc5 and is still 3.10 material. The git
branch called lpae-v2 is available at:

https://github.com/MISL-EBU-System-SW/mainline-public.git.

Thanks,

Changelog:
v1 -> v2:

* The patch to convert the mvebu device tree files to 64 bits was
  split in 3 parts:

    - "arm: dts: move all peripherals inside soc" from Thomas

	- then "arm: dts: Convert all the mvebu files to use the range
    property" which will allow to keep 32 bits addresses for the
    internal registers whereas the memory of the system will be 64
    bits

	- and finally "arm: dts: Convert mvebu device tree files to 64
      bits" which was the move to 64 bits itself.

* A new patch was added "arm: dts: introduce internal-regs node" based
  on the work of Thomas for the mvebu-mbus driver. It introduce a
  'internal-regs' subnode, under which all devices are moved. This is
  not really needed for now, but will be for the mvebu-mbus
  driver. This generates a lot of code movement since it's indenting
  by one more tab all the devices. So it was a good opportunity to fix
  all the bad indentation.

* New patch from Thomas "fix cpus section indentation" to finalize the
  fixing of the bad indentation

* For DMA transfer, DMA_ZONE was selected instead of DMABOUNCE: all
  the DMA transfer are restricted to the low 32 bits address space.


Gregory CLEMENT (4):
  arm: mvebu: Limit the DMA zone when LPAE is selected
  arm: dts: mvebu: Convert all the mvebu files to use the range
    property
  arm: dts: mvebu: introduce internal-regs node
  arm: dts: mvebu: Convert mvebu device tree files to 64 bits

Lior Amsalem (3):
  arm: mvebu: Align the internal registers virtual base to support LPAE
  arm: mvebu: Enable pj4b on LPAE compilations
  arm: dts: Add a 64 bits version of the skeleton device tree

Thomas Petazzoni (2):
  arm: dts: mvebu: move all peripherals inside soc
  arm: dts: mvebu: fix cpus section indentation

 arch/arm/boot/dts/armada-370-db.dts              |  110 +++++-----
 arch/arm/boot/dts/armada-370-mirabox.dts         |   80 +++----
 arch/arm/boot/dts/armada-370-rd.dts              |   18 +-
 arch/arm/boot/dts/armada-370-xp.dtsi             |  253 +++++++++++-----------
 arch/arm/boot/dts/armada-370.dtsi                |  211 +++++++++---------
 arch/arm/boot/dts/armada-xp-db.dts               |  156 ++++++-------
 arch/arm/boot/dts/armada-xp-gp.dts               |  138 ++++++------
 arch/arm/boot/dts/armada-xp-mv78230.dtsi         |   84 +++----
 arch/arm/boot/dts/armada-xp-mv78260.dtsi         |  110 +++++-----
 arch/arm/boot/dts/armada-xp-mv78460.dtsi         |  136 ++++++------
 arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts |  198 ++++++++---------
 arch/arm/boot/dts/armada-xp.dtsi                 |  191 ++++++++--------
 arch/arm/boot/dts/skeleton64.dtsi                |   13 ++
 arch/arm/include/debug/mvebu.S                   |    2 +-
 arch/arm/mach-mvebu/Kconfig                      |    1 +
 arch/arm/mach-mvebu/armada-370-xp.h              |    2 +-
 arch/arm/mm/proc-v7.S                            |    3 +-
 17 files changed, 873 insertions(+), 833 deletions(-)
 create mode 100644 arch/arm/boot/dts/skeleton64.dtsi

-- 
1.7.9.5



From gregory.clement at free-electrons.com  Fri Apr  5 16:24:00 2013
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Fri,  5 Apr 2013 22:24:00 +0200
Subject: [PATCH v2 5/9] arm: dts: mvebu: move all peripherals inside soc
In-Reply-To: <1365193444-13441-1-git-send-email-gregory.clement@free-electrons.com>
References: <1365193444-13441-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1365193444-13441-6-git-send-email-gregory.clement@free-electrons.com>

From: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 arch/arm/boot/dts/armada-370-xp.dtsi |   26 +++++++++++++-------------
 arch/arm/boot/dts/armada-370.dtsi    |   23 ++++++++++++-----------
 arch/arm/boot/dts/armada-xp.dtsi     |   32 ++++++++++++++++----------------
 3 files changed, 41 insertions(+), 40 deletions(-)

diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi b/arch/arm/boot/dts/armada-370-xp.dtsi
index 5b70820..bd26c48 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -28,19 +28,6 @@
 		};
 	};
 
-	mpic: interrupt-controller at d0020000 {
-	      compatible = "marvell,mpic";
-	      #interrupt-cells = <1>;
-	      #size-cells = <1>;
-	      interrupt-controller;
-	};
-
-	coherency-fabric at d0020200 {
-		compatible = "marvell,coherency-fabric";
-		reg = <0xd0020200 0xb0>,
-		      <0xd0021810 0x1c>;
-	};
-
 	soc {
 		#address-cells = <1>;
 		#size-cells = <1>;
@@ -48,6 +35,19 @@
 		interrupt-parent = <&mpic>;
 		ranges;
 
+		mpic: interrupt-controller at d0020000 {
+			compatible = "marvell,mpic";
+			#interrupt-cells = <1>;
+			#size-cells = <1>;
+			interrupt-controller;
+		};
+
+		coherency-fabric at d0020200 {
+			compatible = "marvell,coherency-fabric";
+			reg = <0xd0020200 0xb0>,
+			      <0xd0021810 0x1c>;
+		};
+
 		serial at d0012000 {
 				compatible = "snps,dw-apb-uart";
 				reg = <0xd0012000 0x100>;
diff --git a/arch/arm/boot/dts/armada-370.dtsi b/arch/arm/boot/dts/armada-370.dtsi
index 8188d13..03808aa 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -20,12 +20,6 @@
 / {
 	model = "Marvell Armada 370 family SoC";
 	compatible = "marvell,armada370", "marvell,armada-370-xp";
-	L2: l2-cache {
-		compatible = "marvell,aurora-outer-cache";
-		reg = <0xd0008000 0x1000>;
-		cache-id-part = <0x100>;
-		wt-override;
-	};
 
 	aliases {
 		gpio0 = &gpio0;
@@ -33,17 +27,24 @@
 		gpio2 = &gpio2;
 	};
 
-	mpic: interrupt-controller at d0020000 {
-	      reg = <0xd0020a00 0x1d0>,
-		    <0xd0021870 0x58>;
-	};
-
 	soc {
+		mpic: interrupt-controller at d0020000 {
+			reg = <0xd0020a00 0x1d0>,
+			      <0xd0021870 0x58>;
+		};
+
 		system-controller at d0018200 {
 				compatible = "marvell,armada-370-xp-system-controller";
 				reg = <0xd0018200 0x100>;
 		};
 
+		L2: l2-cache {
+			compatible = "marvell,aurora-outer-cache";
+			reg = <0xd0008000 0x1000>;
+			cache-id-part = <0x100>;
+			wt-override;
+		};
+
 		pinctrl {
 			compatible = "marvell,mv88f6710-pinctrl";
 			reg = <0xd0018000 0x38>;
diff --git a/arch/arm/boot/dts/armada-xp.dtsi b/arch/arm/boot/dts/armada-xp.dtsi
index ca00d83..e644cc5 100644
--- a/arch/arm/boot/dts/armada-xp.dtsi
+++ b/arch/arm/boot/dts/armada-xp.dtsi
@@ -22,25 +22,25 @@
 	model = "Marvell Armada XP family SoC";
 	compatible = "marvell,armadaxp", "marvell,armada-370-xp";
 
-	L2: l2-cache {
-		compatible = "marvell,aurora-system-cache";
-		reg = <0xd0008000 0x1000>;
-		cache-id-part = <0x100>;
-		wt-override;
-	};
+	soc {
+		L2: l2-cache {
+			compatible = "marvell,aurora-system-cache";
+			reg = <0xd0008000 0x1000>;
+			cache-id-part = <0x100>;
+			wt-override;
+		};
 
-	mpic: interrupt-controller at d0020000 {
-	      reg = <0xd0020a00 0x2d0>,
-		    <0xd0021070 0x58>;
-	};
+		mpic: interrupt-controller at d0020000 {
+		      reg = <0xd0020a00 0x2d0>,
+			    <0xd0021070 0x58>;
+		};
 
-	armada-370-xp-pmsu at d0022000 {
-		compatible = "marvell,armada-370-xp-pmsu";
-		reg = <0xd0022100 0x430>,
-		      <0xd0020800 0x20>;
-	};
+		armada-370-xp-pmsu at d0022000 {
+			compatible = "marvell,armada-370-xp-pmsu";
+			reg = <0xd0022100 0x430>,
+			      <0xd0020800 0x20>;
+		};
 
-	soc {
 		serial at d0012200 {
 				compatible = "snps,dw-apb-uart";
 				reg = <0xd0012200 0x100>;
-- 
1.7.9.5



From gregory.clement at free-electrons.com  Fri Apr  5 16:24:04 2013
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Fri,  5 Apr 2013 22:24:04 +0200
Subject: [PATCH v2 9/9] arm: dts: mvebu: Convert mvebu device tree files to 64
 bits
In-Reply-To: <1365193444-13441-1-git-send-email-gregory.clement@free-electrons.com>
References: <1365193444-13441-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1365193444-13441-10-git-send-email-gregory.clement@free-electrons.com>

In order to be able to use more than 4GB of RAM when the LPAE is
activated, the dts must be converted in 64 bits.

Armada XP and Armada 370 share a dtsi file which have also be
converted to 64 bits. This lead to convert all the device tree files
to 64 bits even the one used for Armada 370 (which don't support LPAE)

This was heavily based on the work of Lior Amsalem.

Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
---
 arch/arm/boot/dts/armada-370-db.dts              |    2 +-
 arch/arm/boot/dts/armada-370-mirabox.dts         |    2 +-
 arch/arm/boot/dts/armada-370-rd.dts              |    2 +-
 arch/arm/boot/dts/armada-370-xp.dtsi             |    4 ++--
 arch/arm/boot/dts/armada-xp-db.dts               |    2 +-
 arch/arm/boot/dts/armada-xp-gp.dts               |   14 ++++++++------
 arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts |    2 +-
 7 files changed, 15 insertions(+), 13 deletions(-)

diff --git a/arch/arm/boot/dts/armada-370-db.dts b/arch/arm/boot/dts/armada-370-db.dts
index 6c30a9f..c996c06 100644
--- a/arch/arm/boot/dts/armada-370-db.dts
+++ b/arch/arm/boot/dts/armada-370-db.dts
@@ -26,7 +26,7 @@
 
 	memory {
 		device_type = "memory";
-		reg = <0x00000000 0x40000000>; /* 1 GB */
+		reg = <0 0x00000000 0 0x40000000>; /* 1 GB */
 	};
 
 	soc {
diff --git a/arch/arm/boot/dts/armada-370-mirabox.dts b/arch/arm/boot/dts/armada-370-mirabox.dts
index 5a06e87..29b6b64 100644
--- a/arch/arm/boot/dts/armada-370-mirabox.dts
+++ b/arch/arm/boot/dts/armada-370-mirabox.dts
@@ -21,7 +21,7 @@
 
 	memory {
 		device_type = "memory";
-		reg = <0x00000000 0x20000000>; /* 512 MB */
+		reg = <0 0x00000000 0 0x20000000>; /* 512 MB */
 	};
 
 	soc {
diff --git a/arch/arm/boot/dts/armada-370-rd.dts b/arch/arm/boot/dts/armada-370-rd.dts
index 437dcd2..09e75fc 100644
--- a/arch/arm/boot/dts/armada-370-rd.dts
+++ b/arch/arm/boot/dts/armada-370-rd.dts
@@ -24,7 +24,7 @@
 
 	memory {
 		device_type = "memory";
-		reg = <0x00000000 0x20000000>; /* 512 MB */
+		reg = <0 0x00000000 0 0x20000000>; /* 512 MB */
 	};
 
 	soc {
diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi b/arch/arm/boot/dts/armada-370-xp.dtsi
index 8b9adc6..6a3b418 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -16,7 +16,7 @@
  * 370 and Armada XP SoC.
  */
 
-/include/ "skeleton.dtsi"
+/include/ "skeleton64.dtsi"
 
 / {
 	model = "Marvell Armada 370 and XP SoC";
@@ -33,7 +33,7 @@
 		#size-cells = <1>;
 		compatible = "simple-bus";
 		interrupt-parent = <&mpic>;
-		ranges = <0 0xd0000000 0x100000>;
+		ranges = <0 0 0xd0000000 0x100000>;
 
 		internal-regs {
 			compatible = "simple-bus";
diff --git a/arch/arm/boot/dts/armada-xp-db.dts b/arch/arm/boot/dts/armada-xp-db.dts
index fbd0f04..a2dd24e 100644
--- a/arch/arm/boot/dts/armada-xp-db.dts
+++ b/arch/arm/boot/dts/armada-xp-db.dts
@@ -26,7 +26,7 @@
 
 	memory {
 		device_type = "memory";
-		reg = <0x00000000 0x80000000>; /* 2 GB */
+		reg = <0 0x00000000 0 0x80000000>; /* 2 GB */
 	};
 
 	soc {
diff --git a/arch/arm/boot/dts/armada-xp-gp.dts b/arch/arm/boot/dts/armada-xp-gp.dts
index b0298d7..b022906 100644
--- a/arch/arm/boot/dts/armada-xp-gp.dts
+++ b/arch/arm/boot/dts/armada-xp-gp.dts
@@ -26,14 +26,16 @@
 
 	memory {
 		device_type = "memory";
-
 		/*
-		 * 4 GB of plug-in RAM modules by default but only 3GB
-		 * are visible, the amount of memory available can be
-		 * changed by the bootloader according the size of the
-		 * module actually plugged
+                 * 8 GB of plug-in RAM modules by default.The amount
+                 * of memory available can be changed by the
+                 * bootloader according the size of the module
+                 * actually plugged. Only 7GB are usable because
+                 * addresses from 0xC0000000 to 0xffffffff are used by
+                 * the internal registers of the SoC.
 		 */
-		reg = <0x00000000 0xC0000000>;
+		reg = <0x00000000 0x00000000 0x00000000 0xC0000000>,
+		      <0x00000001 0x00000000 0x00000001 0x00000000>;
 	};
 
 	soc {
diff --git a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
index e2eaf4f..1f274e7 100644
--- a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
+++ b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
@@ -23,7 +23,7 @@
 
 	memory {
 		device_type = "memory";
-		reg = <0x00000000 0xC0000000>; /* 3 GB */
+		reg = <0 0x00000000 0 0xC0000000>; /* 3 GB */
 	};
 
 	soc {
-- 
1.7.9.5



From gregory.clement at free-electrons.com  Fri Apr  5 16:24:03 2013
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Fri,  5 Apr 2013 22:24:03 +0200
Subject: [PATCH v2 8/9] arm: dts: mvebu: fix cpus section indentation
In-Reply-To: <1365193444-13441-1-git-send-email-gregory.clement@free-electrons.com>
References: <1365193444-13441-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1365193444-13441-9-git-send-email-gregory.clement@free-electrons.com>

From: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 arch/arm/boot/dts/armada-xp-mv78230.dtsi |   28 ++++++++--------
 arch/arm/boot/dts/armada-xp-mv78260.dtsi |   28 ++++++++--------
 arch/arm/boot/dts/armada-xp-mv78460.dtsi |   54 +++++++++++++++---------------
 3 files changed, 55 insertions(+), 55 deletions(-)

diff --git a/arch/arm/boot/dts/armada-xp-mv78230.dtsi b/arch/arm/boot/dts/armada-xp-mv78230.dtsi
index f0d38fb..392f118 100644
--- a/arch/arm/boot/dts/armada-xp-mv78230.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78230.dtsi
@@ -25,22 +25,22 @@
 	};
 
 	cpus {
-	    #address-cells = <1>;
-	    #size-cells = <0>;
+		#address-cells = <1>;
+		#size-cells = <0>;
 
-	    cpu at 0 {
-		device_type = "cpu";
-		compatible = "marvell,sheeva-v7";
-		reg = <0>;
-		clocks = <&cpuclk 0>;
-	    };
+		cpu at 0 {
+			device_type = "cpu";
+			compatible = "marvell,sheeva-v7";
+			reg = <0>;
+			clocks = <&cpuclk 0>;
+		};
 
-	    cpu at 1 {
-		device_type = "cpu";
-		compatible = "marvell,sheeva-v7";
-		reg = <1>;
-		clocks = <&cpuclk 1>;
-	    };
+		cpu at 1 {
+			device_type = "cpu";
+			compatible = "marvell,sheeva-v7";
+			reg = <1>;
+			clocks = <&cpuclk 1>;
+		};
 	};
 
 	soc {
diff --git a/arch/arm/boot/dts/armada-xp-mv78260.dtsi b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
index 2621bda..8fb7fea 100644
--- a/arch/arm/boot/dts/armada-xp-mv78260.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
@@ -26,22 +26,22 @@
 	};
 
 	cpus {
-	    #address-cells = <1>;
-	    #size-cells = <0>;
+		#address-cells = <1>;
+		#size-cells = <0>;
 
-	    cpu at 0 {
-		device_type = "cpu";
-		compatible = "marvell,sheeva-v7";
-		reg = <0>;
-		clocks = <&cpuclk 0>;
-	    };
+		cpu at 0 {
+			device_type = "cpu";
+			compatible = "marvell,sheeva-v7";
+			reg = <0>;
+			clocks = <&cpuclk 0>;
+		};
 
-	    cpu at 1 {
-		device_type = "cpu";
-		compatible = "marvell,sheeva-v7";
-		reg = <1>;
-		clocks = <&cpuclk 1>;
-	    };
+		cpu at 1 {
+			device_type = "cpu";
+			compatible = "marvell,sheeva-v7";
+			reg = <1>;
+			clocks = <&cpuclk 1>;
+		};
 	};
 
 	soc {
diff --git a/arch/arm/boot/dts/armada-xp-mv78460.dtsi b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
index ccb95ff..fa665cb 100644
--- a/arch/arm/boot/dts/armada-xp-mv78460.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
@@ -27,36 +27,36 @@
 
 
 	cpus {
-	    #address-cells = <1>;
-	    #size-cells = <0>;
+		#address-cells = <1>;
+		#size-cells = <0>;
 
-	    cpu at 0 {
-		device_type = "cpu";
-		compatible = "marvell,sheeva-v7";
-		reg = <0>;
-		clocks = <&cpuclk 0>;
-	    };
+		cpu at 0 {
+			device_type = "cpu";
+			compatible = "marvell,sheeva-v7";
+			reg = <0>;
+			clocks = <&cpuclk 0>;
+		};
 
-	    cpu at 1 {
-		device_type = "cpu";
-		compatible = "marvell,sheeva-v7";
-		reg = <1>;
-		clocks = <&cpuclk 1>;
-	    };
+		cpu at 1 {
+			device_type = "cpu";
+			compatible = "marvell,sheeva-v7";
+			reg = <1>;
+			clocks = <&cpuclk 1>;
+		};
 
-	    cpu at 2 {
-		device_type = "cpu";
-		compatible = "marvell,sheeva-v7";
-		reg = <2>;
-		clocks = <&cpuclk 2>;
-	    };
+		cpu at 2 {
+			device_type = "cpu";
+			compatible = "marvell,sheeva-v7";
+			reg = <2>;
+			clocks = <&cpuclk 2>;
+		};
 
-	    cpu at 3 {
-		device_type = "cpu";
-		compatible = "marvell,sheeva-v7";
-		reg = <3>;
-		clocks = <&cpuclk 3>;
-	    };
+		cpu at 3 {
+			device_type = "cpu";
+			compatible = "marvell,sheeva-v7";
+			reg = <3>;
+			clocks = <&cpuclk 3>;
+		};
 	};
 
 	soc {
@@ -114,4 +114,4 @@
 			};
 		};
 	};
- };
+};
-- 
1.7.9.5



From gregory.clement at free-electrons.com  Fri Apr  5 16:24:01 2013
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Fri,  5 Apr 2013 22:24:01 +0200
Subject: [PATCH v2 6/9] arm: dts: mvebu: Convert all the mvebu files to use
 the range property
In-Reply-To: <1365193444-13441-1-git-send-email-gregory.clement@free-electrons.com>
References: <1365193444-13441-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1365193444-13441-7-git-send-email-gregory.clement@free-electrons.com>

This conversion will allow to keep 32 bits addresses for the internal
registers whereas the memory of the system will be 64 bits.
Later it will also ease the move of the mvebu-mbus driver to the
device tree support.

Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
---
 arch/arm/boot/dts/armada-370-db.dts              |   16 ++---
 arch/arm/boot/dts/armada-370-mirabox.dts         |   14 ++--
 arch/arm/boot/dts/armada-370-rd.dts              |   14 ++--
 arch/arm/boot/dts/armada-370-xp.dtsi             |   83 +++++++++++-----------
 arch/arm/boot/dts/armada-370.dtsi                |   49 ++++++-------
 arch/arm/boot/dts/armada-xp-db.dts               |   28 ++++----
 arch/arm/boot/dts/armada-xp-gp.dts               |   20 +++---
 arch/arm/boot/dts/armada-xp-mv78230.dtsi         |   10 +--
 arch/arm/boot/dts/armada-xp-mv78260.dtsi         |   18 ++---
 arch/arm/boot/dts/armada-xp-mv78460.dtsi         |   18 ++---
 arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts |   22 +++---
 arch/arm/boot/dts/armada-xp.dtsi                 |   65 ++++++++---------
 12 files changed, 180 insertions(+), 177 deletions(-)

diff --git a/arch/arm/boot/dts/armada-370-db.dts b/arch/arm/boot/dts/armada-370-db.dts
index e34b280..183901c 100644
--- a/arch/arm/boot/dts/armada-370-db.dts
+++ b/arch/arm/boot/dts/armada-370-db.dts
@@ -30,11 +30,11 @@
 	};
 
 	soc {
-		serial at d0012000 {
+		serial at 12000 {
 			clock-frequency = <200000000>;
 			status = "okay";
 		};
-		sata at d00a0000 {
+		sata at a0000 {
 			nr-ports = <2>;
 			status = "okay";
 		};
@@ -49,18 +49,18 @@
 			};
 		};
 
-		ethernet at d0070000 {
+		ethernet at 70000 {
 			status = "okay";
 			phy = <&phy0>;
 			phy-mode = "rgmii-id";
 		};
-		ethernet at d0074000 {
+		ethernet at 74000 {
 			status = "okay";
 			phy = <&phy1>;
 			phy-mode = "rgmii-id";
 		};
 
-		mvsdio at d00d4000 {
+		mvsdio at d4000 {
 			pinctrl-0 = <&sdio_pins1>;
 			pinctrl-names = "default";
 			/*
@@ -75,15 +75,15 @@
 			/* No CD or WP GPIOs */
 		};
 
-		usb at d0050000 {
+		usb at 50000 {
 			status = "okay";
 		};
 
-		usb at d0051000 {
+		usb at 51000 {
 			status = "okay";
 		};
 
-		spi0: spi at d0010600 {
+		spi0: spi at 10600 {
 			status = "okay";
 
 			spi-flash at 0 {
diff --git a/arch/arm/boot/dts/armada-370-mirabox.dts b/arch/arm/boot/dts/armada-370-mirabox.dts
index dd0c57d..2773eee 100644
--- a/arch/arm/boot/dts/armada-370-mirabox.dts
+++ b/arch/arm/boot/dts/armada-370-mirabox.dts
@@ -25,11 +25,11 @@
 	};
 
 	soc {
-		serial at d0012000 {
+		serial at 12000 {
 			clock-frequency = <200000000>;
 			status = "okay";
 		};
-		timer at d0020300 {
+		timer at 20300 {
 			clock-frequency = <600000000>;
 			status = "okay";
 		};
@@ -42,18 +42,18 @@
 				reg = <1>;
 			};
 		};
-		ethernet at d0070000 {
+		ethernet at 70000 {
 			status = "okay";
 			phy = <&phy0>;
 			phy-mode = "rgmii-id";
 		};
-		ethernet at d0074000 {
+		ethernet at 74000 {
 			status = "okay";
 			phy = <&phy1>;
 			phy-mode = "rgmii-id";
 		};
 
-		mvsdio at d00d4000 {
+		mvsdio at d4000 {
 			pinctrl-0 = <&sdio_pins2>;
 			pinctrl-names = "default";
 			status = "okay";
@@ -63,11 +63,11 @@
 			 */
 		};
 
-		usb at d0050000 {
+		usb at 50000 {
 			status = "okay";
 		};
 
-		usb at d0051000 {
+		usb at 51000 {
 			status = "okay";
 		};
 	};
diff --git a/arch/arm/boot/dts/armada-370-rd.dts b/arch/arm/boot/dts/armada-370-rd.dts
index 070bba4..be209020 100644
--- a/arch/arm/boot/dts/armada-370-rd.dts
+++ b/arch/arm/boot/dts/armada-370-rd.dts
@@ -28,11 +28,11 @@
 	};
 
 	soc {
-		serial at d0012000 {
+		serial at 12000 {
 			clock-frequency = <200000000>;
 			status = "okay";
 		};
-		sata at d00a0000 {
+		sata at a0000 {
 			nr-ports = <2>;
 			status = "okay";
 		};
@@ -47,29 +47,29 @@
 			};
 		};
 
-		ethernet at d0070000 {
+		ethernet at 70000 {
 			status = "okay";
 			phy = <&phy0>;
 			phy-mode = "sgmii";
 		};
-		ethernet at d0074000 {
+		ethernet at 74000 {
 			status = "okay";
 			phy = <&phy1>;
 			phy-mode = "rgmii-id";
 		};
 
-		mvsdio at d00d4000 {
+		mvsdio at d4000 {
 			pinctrl-0 = <&sdio_pins1>;
 			pinctrl-names = "default";
 			status = "okay";
 			/* No CD or WP GPIOs */
 		};
 
-		usb at d0050000 {
+		usb at 50000 {
 			status = "okay";
 		};
 
-		usb at d0051000 {
+		usb at 51000 {
 			status = "okay";
 		};
 	};
diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi b/arch/arm/boot/dts/armada-370-xp.dtsi
index bd26c48..1874655 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -28,59 +28,60 @@
 		};
 	};
 
+
 	soc {
 		#address-cells = <1>;
 		#size-cells = <1>;
 		compatible = "simple-bus";
 		interrupt-parent = <&mpic>;
-		ranges;
+		ranges = <0 0xd0000000 0x100000>;
 
-		mpic: interrupt-controller at d0020000 {
-			compatible = "marvell,mpic";
-			#interrupt-cells = <1>;
-			#size-cells = <1>;
-			interrupt-controller;
+		mpic: interrupt-controller at 20000 {
+				compatible = "marvell,mpic";
+				#interrupt-cells = <1>;
+				#size-cells = <1>;
+				interrupt-controller;
 		};
 
-		coherency-fabric at d0020200 {
-			compatible = "marvell,coherency-fabric";
-			reg = <0xd0020200 0xb0>,
-			      <0xd0021810 0x1c>;
+		coherency-fabric at 20200 {
+				compatible = "marvell,coherency-fabric";
+				reg = <0x20200 0xb0>,
+				      <0x21810 0x1c>;
 		};
 
-		serial at d0012000 {
+		serial at 12000 {
 				compatible = "snps,dw-apb-uart";
-				reg = <0xd0012000 0x100>;
+				reg = <0x12000 0x100>;
 				reg-shift = <2>;
 				interrupts = <41>;
 				reg-io-width = <1>;
 				status = "disabled";
 		};
-		serial at d0012100 {
+		serial at 12100 {
 				compatible = "snps,dw-apb-uart";
-				reg = <0xd0012100 0x100>;
+				reg = <0x12100 0x100>;
 				reg-shift = <2>;
 				interrupts = <42>;
 				reg-io-width = <1>;
 				status = "disabled";
 		};
 
-		timer at d0020300 {
+		timer at 20300 {
 			       compatible = "marvell,armada-370-xp-timer";
-			       reg = <0xd0020300 0x30>,
-			       <0xd0021040 0x30>;
+			       reg = <0x20300 0x30>,
+			       <0x21040 0x30>;
 			       interrupts = <37>, <38>, <39>, <40>, <5>, <6>;
 			       clocks = <&coreclk 2>;
 		};
 
-		addr-decoding at d0020000 {
+		addr-decoding at 20000 {
 			compatible = "marvell,armada-addr-decoding-controller";
-			reg = <0xd0020000 0x258>;
+			reg = <0x20000 0x258>;
 		};
 
-		sata at d00a0000 {
+		sata at a0000 {
 			compatible = "marvell,orion-sata";
-			reg = <0xd00a0000 0x2400>;
+			reg = <0xa0000 0x2400>;
 			interrupts = <55>;
 			clocks = <&gateclk 15>, <&gateclk 30>;
 			clock-names = "0", "1";
@@ -91,28 +92,28 @@
 			#address-cells = <1>;
 			#size-cells = <0>;
 			compatible = "marvell,orion-mdio";
-			reg = <0xd0072004 0x4>;
+			reg = <0x72004 0x4>;
 		};
 
-		ethernet at d0070000 {
+		ethernet at 70000 {
 				compatible = "marvell,armada-370-neta";
-				reg = <0xd0070000 0x2500>;
+				reg = <0x70000 0x2500>;
 				interrupts = <8>;
 				clocks = <&gateclk 4>;
 				status = "disabled";
 		};
 
-		ethernet at d0074000 {
+		ethernet at 74000 {
 				compatible = "marvell,armada-370-neta";
-				reg = <0xd0074000 0x2500>;
+				reg = <0x74000 0x2500>;
 				interrupts = <10>;
 				clocks = <&gateclk 3>;
 				status = "disabled";
 		};
 
-		i2c0: i2c at d0011000 {
+		i2c0: i2c at 11000 {
 			compatible = "marvell,mv64xxx-i2c";
-			reg = <0xd0011000 0x20>;
+			reg = <0x11000 0x20>;
 			#address-cells = <1>;
 			#size-cells = <0>;
 			interrupts = <31>;
@@ -121,9 +122,9 @@
 			status = "disabled";
 		};
 
-		i2c1: i2c at d0011100 {
+		i2c1: i2c at 11100 {
 			compatible = "marvell,mv64xxx-i2c";
-			reg = <0xd0011100 0x20>;
+			reg = <0x11100 0x20>;
 			#address-cells = <1>;
 			#size-cells = <0>;
 			interrupts = <32>;
@@ -134,35 +135,35 @@
 
 		rtc at 10300 {
 			compatible = "marvell,orion-rtc";
-			reg = <0xd0010300 0x20>;
+			reg = <0x10300 0x20>;
 			interrupts = <50>;
 		};
 
-		mvsdio at d00d4000 {
+		mvsdio at d4000 {
 			compatible = "marvell,orion-sdio";
-			reg = <0xd00d4000 0x200>;
+			reg = <0xd4000 0x200>;
 			interrupts = <54>;
 			clocks = <&gateclk 17>;
 			status = "disabled";
 		};
 
-		usb at d0050000 {
+		usb at 50000 {
 			compatible = "marvell,orion-ehci";
-			reg = <0xd0050000 0x500>;
+			reg = <0x50000 0x500>;
 			interrupts = <45>;
 			status = "disabled";
 		};
 
-		usb at d0051000 {
+		usb at 51000 {
 			compatible = "marvell,orion-ehci";
-			reg = <0xd0051000 0x500>;
+			reg = <0x51000 0x500>;
 			interrupts = <46>;
 			status = "disabled";
 		};
 
-		spi0: spi at d0010600 {
+		spi0: spi at 10600 {
 			compatible = "marvell,orion-spi";
-			reg = <0xd0010600 0x28>;
+			reg = <0x10600 0x28>;
 			#address-cells = <1>;
 			#size-cells = <0>;
 			cell-index = <0>;
@@ -171,9 +172,9 @@
 			status = "disabled";
 		};
 
-		spi1: spi at d0010680 {
+		spi1: spi at 10680 {
 			compatible = "marvell,orion-spi";
-			reg = <0xd0010680 0x28>;
+			reg = <0x10680 0x28>;
 			#address-cells = <1>;
 			#size-cells = <0>;
 			cell-index = <1>;
diff --git a/arch/arm/boot/dts/armada-370.dtsi b/arch/arm/boot/dts/armada-370.dtsi
index 03808aa..661bdcb 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -28,14 +28,15 @@
 	};
 
 	soc {
-		mpic: interrupt-controller at d0020000 {
-			reg = <0xd0020a00 0x1d0>,
-			      <0xd0021870 0x58>;
+
+		mpic: interrupt-controller at 20000 {
+			reg = <0x20a00 0x1d0>,
+			      <0x21870 0x58>;
 		};
 
-		system-controller at d0018200 {
+		system-controller at 18200 {
 				compatible = "marvell,armada-370-xp-system-controller";
-				reg = <0xd0018200 0x100>;
+				reg = <0x18200 0x100>;
 		};
 
 		L2: l2-cache {
@@ -47,7 +48,7 @@
 
 		pinctrl {
 			compatible = "marvell,mv88f6710-pinctrl";
-			reg = <0xd0018000 0x38>;
+			reg = <0x18000 0x38>;
 
 			sdio_pins1: sdio-pins1 {
 			      marvell,pins = "mpp9",  "mpp11", "mpp12",
@@ -62,9 +63,9 @@
 			};
 	        };
 
-		gpio0: gpio at d0018100 {
+		gpio0: gpio at 18100 {
 			compatible = "marvell,orion-gpio";
-			reg = <0xd0018100 0x40>;
+			reg = <0x18100 0x40>;
 			ngpios = <32>;
 			gpio-controller;
 			#gpio-cells = <2>;
@@ -73,9 +74,9 @@
 			interrupts = <82>, <83>, <84>, <85>;
 		};
 
-		gpio1: gpio at d0018140 {
+		gpio1: gpio at 18140 {
 			compatible = "marvell,orion-gpio";
-			reg = <0xd0018140 0x40>;
+			reg = <0x18140 0x40>;
 			ngpios = <32>;
 			gpio-controller;
 			#gpio-cells = <2>;
@@ -84,9 +85,9 @@
 			interrupts = <87>, <88>, <89>, <90>;
 		};
 
-		gpio2: gpio at d0018180 {
+		gpio2: gpio at 18180 {
 			compatible = "marvell,orion-gpio";
-			reg = <0xd0018180 0x40>;
+			reg = <0x18180 0x40>;
 			ngpios = <2>;
 			gpio-controller;
 			#gpio-cells = <2>;
@@ -95,23 +96,23 @@
 			interrupts = <91>;
 		};
 
-		coreclk: mvebu-sar at d0018230 {
+		coreclk: mvebu-sar at 18230 {
 			compatible = "marvell,armada-370-core-clock";
-			reg = <0xd0018230 0x08>;
+			reg = <0x18230 0x08>;
 			#clock-cells = <1>;
 		};
 
-		gateclk: clock-gating-control at d0018220 {
+		gateclk: clock-gating-control at 18220 {
 			compatible = "marvell,armada-370-gating-clock";
-			reg = <0xd0018220 0x4>;
+			reg = <0x18220 0x4>;
 			clocks = <&coreclk 0>;
 			#clock-cells = <1>;
 		};
 
-		xor at d0060800 {
+		xor at 60800 {
 			compatible = "marvell,orion-xor";
-			reg = <0xd0060800 0x100
-			       0xd0060A00 0x100>;
+			reg = <0x60800 0x100
+			       0x60A00 0x100>;
 			status = "okay";
 
 			xor00 {
@@ -127,10 +128,10 @@
 			};
 		};
 
-		xor at d0060900 {
+		xor at 60900 {
 			compatible = "marvell,orion-xor";
-			reg = <0xd0060900 0x100
-			       0xd0060b00 0x100>;
+			reg = <0x60900 0x100
+			       0x60b00 0x100>;
 			status = "okay";
 
 			xor10 {
@@ -146,11 +147,11 @@
 			};
 		};
 
-		usb at d0050000 {
+		usb at 50000 {
 			clocks = <&coreclk 0>;
 		};
 
-		usb at d0051000 {
+		usb at 51000 {
 			clocks = <&coreclk 0>;
 		};
 
diff --git a/arch/arm/boot/dts/armada-xp-db.dts b/arch/arm/boot/dts/armada-xp-db.dts
index e83505e..5e2b595 100644
--- a/arch/arm/boot/dts/armada-xp-db.dts
+++ b/arch/arm/boot/dts/armada-xp-db.dts
@@ -30,24 +30,24 @@
 	};
 
 	soc {
-		serial at d0012000 {
+		serial at 12000 {
 			clock-frequency = <250000000>;
 			status = "okay";
 		};
-		serial at d0012100 {
+		serial at 12100 {
 			clock-frequency = <250000000>;
 			status = "okay";
 		};
-		serial at d0012200 {
+		serial at 12200 {
 			clock-frequency = <250000000>;
 			status = "okay";
 		};
-		serial at d0012300 {
+		serial at 12300 {
 			clock-frequency = <250000000>;
 			status = "okay";
 		};
 
-		sata at d00a0000 {
+		sata at a0000 {
 			nr-ports = <2>;
 			status = "okay";
 		};
@@ -70,47 +70,47 @@
 			};
 		};
 
-		ethernet at d0070000 {
+		ethernet at 70000 {
 			status = "okay";
 			phy = <&phy0>;
 			phy-mode = "rgmii-id";
 		};
-		ethernet at d0074000 {
+		ethernet at 74000 {
 			status = "okay";
 			phy = <&phy1>;
 			phy-mode = "rgmii-id";
 		};
-		ethernet at d0030000 {
+		ethernet at 30000 {
 			status = "okay";
 			phy = <&phy2>;
 			phy-mode = "sgmii";
 		};
-		ethernet at d0034000 {
+		ethernet at 34000 {
 			status = "okay";
 			phy = <&phy3>;
 			phy-mode = "sgmii";
 		};
 
-		mvsdio at d00d4000 {
+		mvsdio at d4000 {
 			pinctrl-0 = <&sdio_pins>;
 			pinctrl-names = "default";
 			status = "okay";
 			/* No CD or WP GPIOs */
 		};
 
-		usb at d0050000 {
+		usb at 50000 {
 			status = "okay";
 		};
 
-		usb at d0051000 {
+		usb at 51000 {
 			status = "okay";
 		};
 
-		usb at d0052000 {
+		usb at 52000 {
 			status = "okay";
 		};
 
-		spi0: spi at d0010600 {
+		spi0: spi at 10600 {
 			status = "okay";
 
 			spi-flash at 0 {
diff --git a/arch/arm/boot/dts/armada-xp-gp.dts b/arch/arm/boot/dts/armada-xp-gp.dts
index 1c8afe2..12b98d3 100644
--- a/arch/arm/boot/dts/armada-xp-gp.dts
+++ b/arch/arm/boot/dts/armada-xp-gp.dts
@@ -37,24 +37,24 @@
 	};
 
 	soc {
-		serial at d0012000 {
+		serial at 12000 {
 			clock-frequency = <250000000>;
 			status = "okay";
 		};
-		serial at d0012100 {
+		serial at 12100 {
 			clock-frequency = <250000000>;
 			status = "okay";
 		};
-		serial at d0012200 {
+		serial at 12200 {
 			clock-frequency = <250000000>;
 			status = "okay";
 		};
-		serial at d0012300 {
+		serial at 12300 {
 			clock-frequency = <250000000>;
 			status = "okay";
 		};
 
-		sata at d00a0000 {
+		sata at a0000 {
 			nr-ports = <2>;
 			status = "okay";
 		};
@@ -77,28 +77,28 @@
 			};
 		};
 
-		ethernet at d0070000 {
+		ethernet at 70000 {
 			status = "okay";
 			phy = <&phy0>;
 			phy-mode = "rgmii-id";
 		};
-		ethernet at d0074000 {
+		ethernet at 74000 {
 			status = "okay";
 			phy = <&phy1>;
 			phy-mode = "rgmii-id";
 		};
-		ethernet at d0030000 {
+		ethernet at 30000 {
 			status = "okay";
 			phy = <&phy2>;
 			phy-mode = "rgmii-id";
 		};
-		ethernet at d0034000 {
+		ethernet at 34000 {
 			status = "okay";
 			phy = <&phy3>;
 			phy-mode = "rgmii-id";
 		};
 
-		spi0: spi at d0010600 {
+		spi0: spi at 10600 {
 			status = "okay";
 
 			spi-flash at 0 {
diff --git a/arch/arm/boot/dts/armada-xp-mv78230.dtsi b/arch/arm/boot/dts/armada-xp-mv78230.dtsi
index f56c405..40fa72e 100644
--- a/arch/arm/boot/dts/armada-xp-mv78230.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78230.dtsi
@@ -46,7 +46,7 @@
 	soc {
 		pinctrl {
 			compatible = "marvell,mv78230-pinctrl";
-			reg = <0xd0018000 0x38>;
+			reg = <0x18000 0x38>;
 
 			sdio_pins: sdio-pins {
 				marvell,pins = "mpp30", "mpp31", "mpp32",
@@ -55,9 +55,9 @@
 			};
 		};
 
-		gpio0: gpio at d0018100 {
+		gpio0: gpio at 18100 {
 			compatible = "marvell,orion-gpio";
-			reg = <0xd0018100 0x40>;
+			reg = <0x18100 0x40>;
 			ngpios = <32>;
 			gpio-controller;
 			#gpio-cells = <2>;
@@ -66,9 +66,9 @@
 			interrupts = <82>, <83>, <84>, <85>;
 		};
 
-		gpio1: gpio at d0018140 {
+		gpio1: gpio at 18140 {
 			compatible = "marvell,orion-gpio";
-			reg = <0xd0018140 0x40>;
+			reg = <0x18140 0x40>;
 			ngpios = <17>;
 			gpio-controller;
 			#gpio-cells = <2>;
diff --git a/arch/arm/boot/dts/armada-xp-mv78260.dtsi b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
index f8f2b78..7578c21 100644
--- a/arch/arm/boot/dts/armada-xp-mv78260.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
@@ -47,7 +47,7 @@
 	soc {
 		pinctrl {
 			compatible = "marvell,mv78260-pinctrl";
-			reg = <0xd0018000 0x38>;
+			reg = <0x18000 0x38>;
 
 			sdio_pins: sdio-pins {
 				marvell,pins = "mpp30", "mpp31", "mpp32",
@@ -56,9 +56,9 @@
 			};
 		};
 
-		gpio0: gpio at d0018100 {
+		gpio0: gpio at 18100 {
 			compatible = "marvell,orion-gpio";
-			reg = <0xd0018100 0x40>;
+			reg = <0x18100 0x40>;
 			ngpios = <32>;
 			gpio-controller;
 			#gpio-cells = <2>;
@@ -67,9 +67,9 @@
 			interrupts = <82>, <83>, <84>, <85>;
 		};
 
-		gpio1: gpio at d0018140 {
+		gpio1: gpio at 18140 {
 			compatible = "marvell,orion-gpio";
-			reg = <0xd0018140 0x40>;
+			reg = <0x18140 0x40>;
 			ngpios = <32>;
 			gpio-controller;
 			#gpio-cells = <2>;
@@ -78,9 +78,9 @@
 			interrupts = <87>, <88>, <89>, <90>;
 		};
 
-		gpio2: gpio at d0018180 {
+		gpio2: gpio at 18180 {
 			compatible = "marvell,orion-gpio";
-			reg = <0xd0018180 0x40>;
+			reg = <0x18180 0x40>;
 			ngpios = <3>;
 			gpio-controller;
 			#gpio-cells = <2>;
@@ -89,9 +89,9 @@
 			interrupts = <91>;
 		};
 
-		ethernet at d0034000 {
+		ethernet at 34000 {
 				compatible = "marvell,armada-370-neta";
-				reg = <0xd0034000 0x2500>;
+				reg = <0x34000 0x2500>;
 				interrupts = <14>;
 				clocks = <&gateclk 1>;
 				status = "disabled";
diff --git a/arch/arm/boot/dts/armada-xp-mv78460.dtsi b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
index 936c25d..5280a4d 100644
--- a/arch/arm/boot/dts/armada-xp-mv78460.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
@@ -62,7 +62,7 @@
 	soc {
 		pinctrl {
 			compatible = "marvell,mv78460-pinctrl";
-			reg = <0xd0018000 0x38>;
+			reg = <0x18000 0x38>;
 
 			sdio_pins: sdio-pins {
 				marvell,pins = "mpp30", "mpp31", "mpp32",
@@ -71,9 +71,9 @@
 			};
 		};
 
-		gpio0: gpio at d0018100 {
+		gpio0: gpio at 18100 {
 			compatible = "marvell,orion-gpio";
-			reg = <0xd0018100 0x40>;
+			reg = <0x18100 0x40>;
 			ngpios = <32>;
 			gpio-controller;
 			#gpio-cells = <2>;
@@ -82,9 +82,9 @@
 			interrupts = <82>, <83>, <84>, <85>;
 		};
 
-		gpio1: gpio at d0018140 {
+		gpio1: gpio at 18140 {
 			compatible = "marvell,orion-gpio";
-			reg = <0xd0018140 0x40>;
+			reg = <0x18140 0x40>;
 			ngpios = <32>;
 			gpio-controller;
 			#gpio-cells = <2>;
@@ -93,9 +93,9 @@
 			interrupts = <87>, <88>, <89>, <90>;
 		};
 
-		gpio2: gpio at d0018180 {
+		gpio2: gpio at 18180 {
 			compatible = "marvell,orion-gpio";
-			reg = <0xd0018180 0x40>;
+			reg = <0x18180 0x40>;
 			ngpios = <3>;
 			gpio-controller;
 			#gpio-cells = <2>;
@@ -104,9 +104,9 @@
 			interrupts = <91>;
 		};
 
-		ethernet at d0034000 {
+		ethernet at 34000 {
 				compatible = "marvell,armada-370-neta";
-				reg = <0xd0034000 0x2500>;
+				reg = <0x34000 0x2500>;
 				interrupts = <14>;
 				clocks = <&gateclk 1>;
 				status = "disabled";
diff --git a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
index 3818a82..a7bade4 100644
--- a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
+++ b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
@@ -27,11 +27,11 @@
 	};
 
 	soc {
-		serial at d0012000 {
+		serial at 12000 {
 			clock-frequency = <250000000>;
 			status = "okay";
 		};
-		serial at d0012100 {
+		serial at 12100 {
 			clock-frequency = <250000000>;
 			status = "okay";
 		};
@@ -96,31 +96,31 @@
 			};
 		};
 
-		ethernet at d0070000 {
+		ethernet at 70000 {
 			status = "okay";
 			phy = <&phy0>;
 			phy-mode = "sgmii";
 		};
-		ethernet at d0074000 {
+		ethernet at 74000 {
 			status = "okay";
 			phy = <&phy1>;
 			phy-mode = "sgmii";
 		};
-		ethernet at d0030000 {
+		ethernet at 30000 {
 			status = "okay";
 			phy = <&phy2>;
 			phy-mode = "sgmii";
 		};
-		ethernet at d0034000 {
+		ethernet at 34000 {
 			status = "okay";
 			phy = <&phy3>;
 			phy-mode = "sgmii";
 		};
-		i2c at d0011000 {
+		i2c at 11000 {
 			status = "okay";
 			clock-frequency = <400000>;
 		};
-		i2c at d0011100 {
+		i2c at 11100 {
 			status = "okay";
 			clock-frequency = <400000>;
 
@@ -129,14 +129,14 @@
 				reg = <0x30>;
 			};
 		};
-		sata at d00a0000 {
+		sata at a0000 {
 			nr-ports = <2>;
 			status = "okay";
 		};
-		usb at d0050000 {
+		usb at 50000 {
 			status = "okay";
 		};
-		usb at d0051000 {
+		usb at 51000 {
 			status = "okay";
 		};
 	};
diff --git a/arch/arm/boot/dts/armada-xp.dtsi b/arch/arm/boot/dts/armada-xp.dtsi
index e644cc5..6ca6b7a 100644
--- a/arch/arm/boot/dts/armada-xp.dtsi
+++ b/arch/arm/boot/dts/armada-xp.dtsi
@@ -22,83 +22,84 @@
 	model = "Marvell Armada XP family SoC";
 	compatible = "marvell,armadaxp", "marvell,armada-370-xp";
 
+
 	soc {
 		L2: l2-cache {
 			compatible = "marvell,aurora-system-cache";
-			reg = <0xd0008000 0x1000>;
+			reg = <0x08000 0x1000>;
 			cache-id-part = <0x100>;
 			wt-override;
 		};
 
-		mpic: interrupt-controller at d0020000 {
-		      reg = <0xd0020a00 0x2d0>,
-			    <0xd0021070 0x58>;
+		mpic: interrupt-controller at 20000 {
+		      reg = <0x20a00 0x2d0>,
+			    <0x21070 0x58>;
 		};
 
-		armada-370-xp-pmsu at d0022000 {
+		armada-370-xp-pmsu at 22000 {
 			compatible = "marvell,armada-370-xp-pmsu";
-			reg = <0xd0022100 0x430>,
-			      <0xd0020800 0x20>;
+			reg = <0x22100 0x430>,
+			      <0x20800 0x20>;
 		};
 
-		serial at d0012200 {
+		serial at 12200 {
 				compatible = "snps,dw-apb-uart";
-				reg = <0xd0012200 0x100>;
+				reg = <0x12200 0x100>;
 				reg-shift = <2>;
 				interrupts = <43>;
 				reg-io-width = <1>;
 				status = "disabled";
 		};
-		serial at d0012300 {
+		serial at 12300 {
 				compatible = "snps,dw-apb-uart";
-				reg = <0xd0012300 0x100>;
+				reg = <0x12300 0x100>;
 				reg-shift = <2>;
 				interrupts = <44>;
 				reg-io-width = <1>;
 				status = "disabled";
 		};
 
-		timer at d0020300 {
+		timer at 20300 {
 				marvell,timer-25Mhz;
 		};
 
-		coreclk: mvebu-sar at d0018230 {
+		coreclk: mvebu-sar at 18230 {
 			compatible = "marvell,armada-xp-core-clock";
-			reg = <0xd0018230 0x08>;
+			reg = <0x18230 0x08>;
 			#clock-cells = <1>;
 		};
 
-		cpuclk: clock-complex at d0018700 {
+		cpuclk: clock-complex at 18700 {
 			#clock-cells = <1>;
 			compatible = "marvell,armada-xp-cpu-clock";
-			reg = <0xd0018700 0xA0>;
+			reg = <0x18700 0xA0>;
 			clocks = <&coreclk 1>;
 		};
 
-		gateclk: clock-gating-control at d0018220 {
+		gateclk: clock-gating-control at 18220 {
 			compatible = "marvell,armada-xp-gating-clock";
-			reg = <0xd0018220 0x4>;
+			reg = <0x18220 0x4>;
 			clocks = <&coreclk 0>;
 			#clock-cells = <1>;
 		};
 
-		system-controller at d0018200 {
+		system-controller at 18200 {
 				compatible = "marvell,armada-370-xp-system-controller";
-				reg = <0xd0018200 0x500>;
+				reg = <0x18200 0x500>;
 		};
 
-		ethernet at d0030000 {
+		ethernet at 30000 {
 				compatible = "marvell,armada-370-neta";
-				reg = <0xd0030000 0x2500>;
+				reg = <0x30000 0x2500>;
 				interrupts = <12>;
 				clocks = <&gateclk 2>;
 				status = "disabled";
 		};
 
-		xor at d0060900 {
+		xor at 60900 {
 			compatible = "marvell,orion-xor";
-			reg = <0xd0060900 0x100
-			       0xd0060b00 0x100>;
+			reg = <0x60900 0x100
+			       0x60b00 0x100>;
 			clocks = <&gateclk 22>;
 			status = "okay";
 
@@ -115,10 +116,10 @@
 			};
 		};
 
-		xor at d00f0900 {
+		xor at f0900 {
 			compatible = "marvell,orion-xor";
-			reg = <0xd00F0900 0x100
-			       0xd00F0B00 0x100>;
+			reg = <0xF0900 0x100
+			       0xF0B00 0x100>;
 			clocks = <&gateclk 28>;
 			status = "okay";
 
@@ -135,17 +136,17 @@
 			};
 		};
 
-		usb at d0050000 {
+		usb at 50000 {
 			clocks = <&gateclk 18>;
 		};
 
-		usb at d0051000 {
+		usb at 51000 {
 			clocks = <&gateclk 19>;
 		};
 
-		usb at d0052000 {
+		usb at 52000 {
 			compatible = "marvell,orion-ehci";
-			reg = <0xd0052000 0x500>;
+			reg = <0x52000 0x500>;
 			interrupts = <47>;
 			clocks = <&gateclk 20>;
 			status = "disabled";
-- 
1.7.9.5



From gregory.clement at free-electrons.com  Fri Apr  5 16:24:02 2013
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Fri,  5 Apr 2013 22:24:02 +0200
Subject: [PATCH v2 7/9] arm: dts: mvebu: introduce internal-regs node
In-Reply-To: <1365193444-13441-1-git-send-email-gregory.clement@free-electrons.com>
References: <1365193444-13441-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1365193444-13441-8-git-send-email-gregory.clement@free-electrons.com>

Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
---
 arch/arm/boot/dts/armada-370-db.dts              |  108 +++++-----
 arch/arm/boot/dts/armada-370-mirabox.dts         |   78 ++++----
 arch/arm/boot/dts/armada-370-rd.dts              |    2 +
 arch/arm/boot/dts/armada-370-xp.dtsi             |  228 +++++++++++-----------
 arch/arm/boot/dts/armada-370.dtsi                |  211 ++++++++++----------
 arch/arm/boot/dts/armada-xp-db.dts               |  154 +++++++--------
 arch/arm/boot/dts/armada-xp-gp.dts               |  124 ++++++------
 arch/arm/boot/dts/armada-xp-mv78230.dtsi         |   56 +++---
 arch/arm/boot/dts/armada-xp-mv78260.dtsi         |   80 ++++----
 arch/arm/boot/dts/armada-xp-mv78460.dtsi         |   80 ++++----
 arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts |  196 ++++++++++---------
 arch/arm/boot/dts/armada-xp.dtsi                 |  182 +++++++++--------
 12 files changed, 759 insertions(+), 740 deletions(-)

diff --git a/arch/arm/boot/dts/armada-370-db.dts b/arch/arm/boot/dts/armada-370-db.dts
index 183901c..6c30a9f 100644
--- a/arch/arm/boot/dts/armada-370-db.dts
+++ b/arch/arm/boot/dts/armada-370-db.dts
@@ -30,68 +30,70 @@
 	};
 
 	soc {
-		serial at 12000 {
-			clock-frequency = <200000000>;
-			status = "okay";
-		};
-		sata at a0000 {
-			nr-ports = <2>;
-			status = "okay";
-		};
-
-		mdio {
-			phy0: ethernet-phy at 0 {
-				reg = <0>;
+		internal-regs {
+			serial at 12000 {
+				clock-frequency = <200000000>;
+				status = "okay";
+			};
+			sata at a0000 {
+				nr-ports = <2>;
+				status = "okay";
 			};
 
-			phy1: ethernet-phy at 1 {
-				reg = <1>;
+			mdio {
+				phy0: ethernet-phy at 0 {
+					reg = <0>;
+				};
+
+				phy1: ethernet-phy at 1 {
+					reg = <1>;
+				};
 			};
-		};
 
-		ethernet at 70000 {
-			status = "okay";
-			phy = <&phy0>;
-			phy-mode = "rgmii-id";
-		};
-		ethernet at 74000 {
-			status = "okay";
-			phy = <&phy1>;
-			phy-mode = "rgmii-id";
-		};
+			ethernet at 70000 {
+				status = "okay";
+				phy = <&phy0>;
+				phy-mode = "rgmii-id";
+			};
+			ethernet at 74000 {
+				status = "okay";
+				phy = <&phy1>;
+				phy-mode = "rgmii-id";
+			};
 
-		mvsdio at d4000 {
-			pinctrl-0 = <&sdio_pins1>;
-			pinctrl-names = "default";
-			/*
-			 * This device is disabled by default, because
-			 * using the SD card connector requires
-			 * changing the default CON40 connector
-			 * "DB-88F6710_MPP_2xRGMII_DEVICE_Jumper" to a
-			 * different connector
-			 * "DB-88F6710_MPP_RGMII_SD_Jumper".
-			 */
-			status = "disabled";
-			/* No CD or WP GPIOs */
-		};
+			mvsdio at d4000 {
+				pinctrl-0 = <&sdio_pins1>;
+				pinctrl-names = "default";
+				/*
+				 * This device is disabled by default, because
+				 * using the SD card connector requires
+				 * changing the default CON40 connector
+				 * "DB-88F6710_MPP_2xRGMII_DEVICE_Jumper" to a
+				 * different connector
+				 * "DB-88F6710_MPP_RGMII_SD_Jumper".
+				 */
+				status = "disabled";
+				/* No CD or WP GPIOs */
+			};
 
-		usb at 50000 {
-			status = "okay";
-		};
+			usb at 50000 {
+				status = "okay";
+			};
 
-		usb at 51000 {
-			status = "okay";
-		};
+			usb at 51000 {
+				status = "okay";
+			};
 
-		spi0: spi at 10600 {
-			status = "okay";
+			spi0: spi at 10600 {
+				status = "okay";
 
-			spi-flash at 0 {
-				#address-cells = <1>;
-				#size-cells = <1>;
-				compatible = "mx25l25635e";
-				reg = <0>; /* Chip select 0 */
-				spi-max-frequency = <50000000>;
+				spi-flash at 0 {
+					#address-cells = <1>;
+					#size-cells = <1>;
+					compatible = "mx25l25635e";
+					reg = <0>; /* Chip select 0 */
+					spi-max-frequency = <50000000>;
+				};
 			};
 		};
 	};
diff --git a/arch/arm/boot/dts/armada-370-mirabox.dts b/arch/arm/boot/dts/armada-370-mirabox.dts
index 2773eee..5a06e87 100644
--- a/arch/arm/boot/dts/armada-370-mirabox.dts
+++ b/arch/arm/boot/dts/armada-370-mirabox.dts
@@ -25,50 +25,52 @@
 	};
 
 	soc {
-		serial at 12000 {
-			clock-frequency = <200000000>;
-			status = "okay";
-		};
-		timer at 20300 {
-			clock-frequency = <600000000>;
-			status = "okay";
-		};
-		mdio {
-			phy0: ethernet-phy at 0 {
-				reg = <0>;
+		internal-regs {
+			serial at 12000 {
+				clock-frequency = <200000000>;
+				status = "okay";
 			};
+			timer at 20300 {
+				clock-frequency = <600000000>;
+				status = "okay";
+			};
+			mdio {
+				phy0: ethernet-phy at 0 {
+					reg = <0>;
+				};
 
-			phy1: ethernet-phy at 1 {
-				reg = <1>;
+				phy1: ethernet-phy at 1 {
+					reg = <1>;
+				};
+			};
+			ethernet at 70000 {
+				status = "okay";
+				phy = <&phy0>;
+				phy-mode = "rgmii-id";
+			};
+			ethernet at 74000 {
+				status = "okay";
+				phy = <&phy1>;
+				phy-mode = "rgmii-id";
 			};
-		};
-		ethernet at 70000 {
-			status = "okay";
-			phy = <&phy0>;
-			phy-mode = "rgmii-id";
-		};
-		ethernet at 74000 {
-			status = "okay";
-			phy = <&phy1>;
-			phy-mode = "rgmii-id";
-		};
 
-		mvsdio at d4000 {
-			pinctrl-0 = <&sdio_pins2>;
-			pinctrl-names = "default";
-			status = "okay";
-			/*
-			 * No CD or WP GPIOs: SDIO interface used for
-			 * Wifi/Bluetooth chip
-			 */
-		};
+			mvsdio at d4000 {
+				pinctrl-0 = <&sdio_pins2>;
+				pinctrl-names = "default";
+				status = "okay";
+				/*
+				 * No CD or WP GPIOs: SDIO interface used for
+				 * Wifi/Bluetooth chip
+				 */
+			};
 
-		usb at 50000 {
-			status = "okay";
-		};
+			usb at 50000 {
+				status = "okay";
+			};
 
-		usb at 51000 {
-			status = "okay";
+			usb at 51000 {
+				status = "okay";
+			};
 		};
 	};
 };
diff --git a/arch/arm/boot/dts/armada-370-rd.dts b/arch/arm/boot/dts/armada-370-rd.dts
index be209020..437dcd2 100644
--- a/arch/arm/boot/dts/armada-370-rd.dts
+++ b/arch/arm/boot/dts/armada-370-rd.dts
@@ -28,6 +28,7 @@
 	};
 
 	soc {
+		internal-regs {
 		serial at 12000 {
 			clock-frequency = <200000000>;
 			status = "okay";
@@ -72,5 +73,6 @@
 		usb at 51000 {
 			status = "okay";
 		};
+		};
 	};
 };
diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi b/arch/arm/boot/dts/armada-370-xp.dtsi
index 1874655..8b9adc6 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -28,7 +28,6 @@
 		};
 	};
 
-
 	soc {
 		#address-cells = <1>;
 		#size-cells = <1>;
@@ -36,151 +35,156 @@
 		interrupt-parent = <&mpic>;
 		ranges = <0 0xd0000000 0x100000>;
 
-		mpic: interrupt-controller at 20000 {
+		internal-regs {
+			compatible = "simple-bus";
+			#address-cells = <1>;
+			#size-cells = <1>;
+			ranges;
+
+			mpic: interrupt-controller at 20000 {
 				compatible = "marvell,mpic";
 				#interrupt-cells = <1>;
 				#size-cells = <1>;
 				interrupt-controller;
-		};
+			};
 
-		coherency-fabric at 20200 {
+			coherency-fabric at 20200 {
 				compatible = "marvell,coherency-fabric";
-				reg = <0x20200 0xb0>,
-				      <0x21810 0x1c>;
-		};
+				reg = <0x20200 0xb0>, <0x21810 0x1c>;
+			};
 
-		serial at 12000 {
+			serial at 12000 {
 				compatible = "snps,dw-apb-uart";
 				reg = <0x12000 0x100>;
 				reg-shift = <2>;
 				interrupts = <41>;
 				reg-io-width = <1>;
 				status = "disabled";
-		};
-		serial at 12100 {
+			};
+			serial at 12100 {
 				compatible = "snps,dw-apb-uart";
 				reg = <0x12100 0x100>;
 				reg-shift = <2>;
 				interrupts = <42>;
 				reg-io-width = <1>;
 				status = "disabled";
-		};
-
-		timer at 20300 {
-			       compatible = "marvell,armada-370-xp-timer";
-			       reg = <0x20300 0x30>,
-			       <0x21040 0x30>;
-			       interrupts = <37>, <38>, <39>, <40>, <5>, <6>;
-			       clocks = <&coreclk 2>;
-		};
-
-		addr-decoding at 20000 {
-			compatible = "marvell,armada-addr-decoding-controller";
-			reg = <0x20000 0x258>;
-		};
-
-		sata at a0000 {
-			compatible = "marvell,orion-sata";
-			reg = <0xa0000 0x2400>;
-			interrupts = <55>;
-			clocks = <&gateclk 15>, <&gateclk 30>;
-			clock-names = "0", "1";
-			status = "disabled";
-		};
+			};
+
+			timer at 20300 {
+				compatible = "marvell,armada-370-xp-timer";
+				reg = <0x20300 0x30>, <0x21040 0x30>;
+				interrupts = <37>, <38>, <39>, <40>, <5>, <6>;
+				clocks = <&coreclk 2>;
+			};
+
+			addr-decoding at 20000 {
+				compatible = "marvell,armada-addr-decoding-controller";
+				reg = <0x20000 0x258>;
+			};
+
+			sata at a0000 {
+				compatible = "marvell,orion-sata";
+				reg = <0xa0000 0x2400>;
+				interrupts = <55>;
+				clocks = <&gateclk 15>, <&gateclk 30>;
+				clock-names = "0", "1";
+				status = "disabled";
+			};
 
-		mdio {
-			#address-cells = <1>;
-			#size-cells = <0>;
-			compatible = "marvell,orion-mdio";
-			reg = <0x72004 0x4>;
-		};
+			mdio {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "marvell,orion-mdio";
+				reg = <0x72004 0x4>;
+			};
 
-		ethernet at 70000 {
+			ethernet at 70000 {
 				compatible = "marvell,armada-370-neta";
 				reg = <0x70000 0x2500>;
 				interrupts = <8>;
 				clocks = <&gateclk 4>;
 				status = "disabled";
-		};
+			};
 
-		ethernet at 74000 {
+			ethernet at 74000 {
 				compatible = "marvell,armada-370-neta";
 				reg = <0x74000 0x2500>;
 				interrupts = <10>;
 				clocks = <&gateclk 3>;
 				status = "disabled";
-		};
-
-		i2c0: i2c at 11000 {
-			compatible = "marvell,mv64xxx-i2c";
-			reg = <0x11000 0x20>;
-			#address-cells = <1>;
-			#size-cells = <0>;
-			interrupts = <31>;
-			timeout-ms = <1000>;
-			clocks = <&coreclk 0>;
-			status = "disabled";
-		};
-
-		i2c1: i2c at 11100 {
-			compatible = "marvell,mv64xxx-i2c";
-			reg = <0x11100 0x20>;
-			#address-cells = <1>;
-			#size-cells = <0>;
-			interrupts = <32>;
-			timeout-ms = <1000>;
-			clocks = <&coreclk 0>;
-			status = "disabled";
-		};
-
-		rtc at 10300 {
-			compatible = "marvell,orion-rtc";
-			reg = <0x10300 0x20>;
-			interrupts = <50>;
-		};
-
-		mvsdio at d4000 {
-			compatible = "marvell,orion-sdio";
-			reg = <0xd4000 0x200>;
-			interrupts = <54>;
-			clocks = <&gateclk 17>;
-			status = "disabled";
-		};
-
-		usb at 50000 {
-			compatible = "marvell,orion-ehci";
-			reg = <0x50000 0x500>;
-			interrupts = <45>;
-			status = "disabled";
-		};
-
-		usb at 51000 {
-			compatible = "marvell,orion-ehci";
-			reg = <0x51000 0x500>;
-			interrupts = <46>;
-			status = "disabled";
-		};
+			};
+
+			i2c0: i2c at 11000 {
+				compatible = "marvell,mv64xxx-i2c";
+				reg = <0x11000 0x20>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+				interrupts = <31>;
+				timeout-ms = <1000>;
+				clocks = <&coreclk 0>;
+				status = "disabled";
+			};
+
+			i2c1: i2c at 11100 {
+				compatible = "marvell,mv64xxx-i2c";
+				reg = <0x11100 0x20>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+				interrupts = <32>;
+				timeout-ms = <1000>;
+				clocks = <&coreclk 0>;
+				status = "disabled";
+			};
+
+			rtc at 10300 {
+				compatible = "marvell,orion-rtc";
+				reg = <0x10300 0x20>;
+				interrupts = <50>;
+			};
+
+			mvsdio at d4000 {
+				compatible = "marvell,orion-sdio";
+				reg = <0xd4000 0x200>;
+				interrupts = <54>;
+				clocks = <&gateclk 17>;
+				status = "disabled";
+			};
 
-		spi0: spi at 10600 {
-			compatible = "marvell,orion-spi";
-			reg = <0x10600 0x28>;
-			#address-cells = <1>;
-			#size-cells = <0>;
-			cell-index = <0>;
-			interrupts = <30>;
-			clocks = <&coreclk 0>;
-			status = "disabled";
-		};
+			usb at 50000 {
+				compatible = "marvell,orion-ehci";
+				reg = <0x50000 0x500>;
+				interrupts = <45>;
+				status = "disabled";
+			};
 
-		spi1: spi at 10680 {
-			compatible = "marvell,orion-spi";
-			reg = <0x10680 0x28>;
-			#address-cells = <1>;
-			#size-cells = <0>;
-			cell-index = <1>;
-			interrupts = <92>;
-			clocks = <&coreclk 0>;
-			status = "disabled";
+			usb at 51000 {
+				compatible = "marvell,orion-ehci";
+				reg = <0x51000 0x500>;
+				interrupts = <46>;
+				status = "disabled";
+			};
+
+			spi0: spi at 10600 {
+				compatible = "marvell,orion-spi";
+				reg = <0x10600 0x28>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+				cell-index = <0>;
+				interrupts = <30>;
+				clocks = <&coreclk 0>;
+				status = "disabled";
+			};
+
+			spi1: spi at 10680 {
+				compatible = "marvell,orion-spi";
+				reg = <0x10680 0x28>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+				cell-index = <1>;
+				interrupts = <92>;
+				clocks = <&coreclk 0>;
+				status = "disabled";
+			};
 		};
 	};
 };
diff --git a/arch/arm/boot/dts/armada-370.dtsi b/arch/arm/boot/dts/armada-370.dtsi
index 661bdcb..296097d 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -28,132 +28,131 @@
 	};
 
 	soc {
-
-		mpic: interrupt-controller at 20000 {
-			reg = <0x20a00 0x1d0>,
-			      <0x21870 0x58>;
-		};
-
-		system-controller at 18200 {
+		internal-regs {
+			system-controller at 18200 {
 				compatible = "marvell,armada-370-xp-system-controller";
 				reg = <0x18200 0x100>;
-		};
-
-		L2: l2-cache {
-			compatible = "marvell,aurora-outer-cache";
-			reg = <0xd0008000 0x1000>;
-			cache-id-part = <0x100>;
-			wt-override;
-		};
-
-		pinctrl {
-			compatible = "marvell,mv88f6710-pinctrl";
-			reg = <0x18000 0x38>;
+			};
 
-			sdio_pins1: sdio-pins1 {
-			      marvell,pins = "mpp9",  "mpp11", "mpp12",
-					     "mpp13", "mpp14", "mpp15";
-			      marvell,function = "sd0";
+			L2: l2-cache {
+				compatible = "marvell,aurora-outer-cache";
+				reg = <0xd0008000 0x1000>;
+				cache-id-part = <0x100>;
+				wt-override;
 			};
 
-			sdio_pins2: sdio-pins2 {
-			      marvell,pins = "mpp47", "mpp48", "mpp49",
-					     "mpp50", "mpp51", "mpp52";
-			      marvell,function = "sd0";
+			mpic: interrupt-controller at 20000 {
+				reg = <0x20a00 0x1d0>, <0x21870 0x58>;
 			};
-	        };
-
-		gpio0: gpio at 18100 {
-			compatible = "marvell,orion-gpio";
-			reg = <0x18100 0x40>;
-			ngpios = <32>;
-			gpio-controller;
-			#gpio-cells = <2>;
-			interrupt-controller;
-			#interrupts-cells = <2>;
-			interrupts = <82>, <83>, <84>, <85>;
-		};
 
-		gpio1: gpio at 18140 {
-			compatible = "marvell,orion-gpio";
-			reg = <0x18140 0x40>;
-			ngpios = <32>;
-			gpio-controller;
-			#gpio-cells = <2>;
-			interrupt-controller;
-			#interrupts-cells = <2>;
-			interrupts = <87>, <88>, <89>, <90>;
-		};
+			pinctrl {
+				compatible = "marvell,mv88f6710-pinctrl";
+				reg = <0x18000 0x38>;
 
-		gpio2: gpio at 18180 {
-			compatible = "marvell,orion-gpio";
-			reg = <0x18180 0x40>;
-			ngpios = <2>;
-			gpio-controller;
-			#gpio-cells = <2>;
-			interrupt-controller;
-			#interrupts-cells = <2>;
-			interrupts = <91>;
-		};
+			sdio_pins1: sdio-pins1 {
+					marvell,pins = "mpp9",  "mpp11", "mpp12",
+						"mpp13", "mpp14", "mpp15";
+					marvell,function = "sd0";
+				};
 
-		coreclk: mvebu-sar at 18230 {
-			compatible = "marvell,armada-370-core-clock";
-			reg = <0x18230 0x08>;
-			#clock-cells = <1>;
-		};
+			sdio_pins2: sdio-pins2 {
+					marvell,pins = "mpp47", "mpp48", "mpp49",
+						"mpp50", "mpp51", "mpp52";
+					marvell,function = "sd0";
+				};
+			};
 
-		gateclk: clock-gating-control at 18220 {
-			compatible = "marvell,armada-370-gating-clock";
-			reg = <0x18220 0x4>;
-			clocks = <&coreclk 0>;
-			#clock-cells = <1>;
-		};
+			gpio0: gpio at 18100 {
+				compatible = "marvell,orion-gpio";
+				reg = <0x18100 0x40>;
+				ngpios = <32>;
+				gpio-controller;
+				#gpio-cells = <2>;
+				interrupt-controller;
+				#interrupts-cells = <2>;
+				interrupts = <82>, <83>, <84>, <85>;
+			};
 
-		xor at 60800 {
-			compatible = "marvell,orion-xor";
-			reg = <0x60800 0x100
-			       0x60A00 0x100>;
-			status = "okay";
+			gpio1: gpio at 18140 {
+				compatible = "marvell,orion-gpio";
+				reg = <0x18140 0x40>;
+				ngpios = <32>;
+				gpio-controller;
+				#gpio-cells = <2>;
+				interrupt-controller;
+				#interrupts-cells = <2>;
+				interrupts = <87>, <88>, <89>, <90>;
+			};
 
-			xor00 {
-				interrupts = <51>;
-				dmacap,memcpy;
-				dmacap,xor;
+			gpio2: gpio at 18180 {
+				compatible = "marvell,orion-gpio";
+				reg = <0x18180 0x40>;
+				ngpios = <2>;
+				gpio-controller;
+				#gpio-cells = <2>;
+				interrupt-controller;
+				#interrupts-cells = <2>;
+				interrupts = <91>;
 			};
-			xor01 {
-				interrupts = <52>;
-				dmacap,memcpy;
-				dmacap,xor;
-				dmacap,memset;
+
+			coreclk: mvebu-sar at 18230 {
+				compatible = "marvell,armada-370-core-clock";
+				reg = <0x18230 0x08>;
+				#clock-cells = <1>;
 			};
-		};
 
-		xor at 60900 {
-			compatible = "marvell,orion-xor";
-			reg = <0x60900 0x100
-			       0x60b00 0x100>;
-			status = "okay";
+			gateclk: clock-gating-control at 18220 {
+				compatible = "marvell,armada-370-gating-clock";
+				reg = <0x18220 0x4>;
+				clocks = <&coreclk 0>;
+				#clock-cells = <1>;
+			};
 
-			xor10 {
-				interrupts = <94>;
-				dmacap,memcpy;
-				dmacap,xor;
+			xor at 60800 {
+				compatible = "marvell,orion-xor";
+				reg = <0x60800 0x100
+				       0x60A00 0x100>;
+				status = "okay";
+
+				xor00 {
+					interrupts = <51>;
+					dmacap,memcpy;
+					dmacap,xor;
+				};
+				xor01 {
+					interrupts = <52>;
+					dmacap,memcpy;
+					dmacap,xor;
+					dmacap,memset;
+				};
 			};
-			xor11 {
-				interrupts = <95>;
-				dmacap,memcpy;
-				dmacap,xor;
-				dmacap,memset;
+
+			xor at 60900 {
+				compatible = "marvell,orion-xor";
+				reg = <0x60900 0x100
+				       0x60b00 0x100>;
+				status = "okay";
+
+				xor10 {
+					interrupts = <94>;
+					dmacap,memcpy;
+					dmacap,xor;
+				};
+				xor11 {
+					interrupts = <95>;
+					dmacap,memcpy;
+					dmacap,xor;
+					dmacap,memset;
+				};
 			};
-		};
 
-		usb at 50000 {
-			clocks = <&coreclk 0>;
-		};
+			usb at 50000 {
+				clocks = <&coreclk 0>;
+			};
 
-		usb at 51000 {
-			clocks = <&coreclk 0>;
+			usb at 51000 {
+				clocks = <&coreclk 0>;
+			};
 		};
-
 	};
 };
diff --git a/arch/arm/boot/dts/armada-xp-db.dts b/arch/arm/boot/dts/armada-xp-db.dts
index 5e2b595..fbd0f04 100644
--- a/arch/arm/boot/dts/armada-xp-db.dts
+++ b/arch/arm/boot/dts/armada-xp-db.dts
@@ -30,95 +30,97 @@
 	};
 
 	soc {
-		serial at 12000 {
-			clock-frequency = <250000000>;
-			status = "okay";
-		};
-		serial at 12100 {
-			clock-frequency = <250000000>;
-			status = "okay";
-		};
-		serial at 12200 {
-			clock-frequency = <250000000>;
-			status = "okay";
-		};
-		serial at 12300 {
-			clock-frequency = <250000000>;
-			status = "okay";
-		};
-
-		sata at a0000 {
-			nr-ports = <2>;
-			status = "okay";
-		};
-
-		mdio {
-			phy0: ethernet-phy at 0 {
-				reg = <0>;
+		internal-regs {
+			serial at 12000 {
+				clock-frequency = <250000000>;
+				status = "okay";
 			};
-
-			phy1: ethernet-phy at 1 {
-				reg = <1>;
+			serial at 12100 {
+				clock-frequency = <250000000>;
+				status = "okay";
+			};
+			serial at 12200 {
+				clock-frequency = <250000000>;
+				status = "okay";
+			};
+			serial at 12300 {
+				clock-frequency = <250000000>;
+				status = "okay";
 			};
 
-			phy2: ethernet-phy at 2 {
-				reg = <25>;
+			sata at a0000 {
+				nr-ports = <2>;
+				status = "okay";
 			};
 
-			phy3: ethernet-phy at 3 {
-				reg = <27>;
+			mdio {
+				phy0: ethernet-phy at 0 {
+					reg = <0>;
+				};
+
+				phy1: ethernet-phy at 1 {
+					reg = <1>;
+				};
+
+				phy2: ethernet-phy at 2 {
+					reg = <25>;
+				};
+
+				phy3: ethernet-phy at 3 {
+					reg = <27>;
+				};
 			};
-		};
 
-		ethernet at 70000 {
-			status = "okay";
-			phy = <&phy0>;
-			phy-mode = "rgmii-id";
-		};
-		ethernet at 74000 {
-			status = "okay";
-			phy = <&phy1>;
-			phy-mode = "rgmii-id";
-		};
-		ethernet at 30000 {
-			status = "okay";
-			phy = <&phy2>;
-			phy-mode = "sgmii";
-		};
-		ethernet at 34000 {
-			status = "okay";
-			phy = <&phy3>;
-			phy-mode = "sgmii";
-		};
+			ethernet at 70000 {
+				status = "okay";
+				phy = <&phy0>;
+				phy-mode = "rgmii-id";
+			};
+			ethernet at 74000 {
+				status = "okay";
+				phy = <&phy1>;
+				phy-mode = "rgmii-id";
+			};
+			ethernet at 30000 {
+				status = "okay";
+				phy = <&phy2>;
+				phy-mode = "sgmii";
+			};
+			ethernet at 34000 {
+				status = "okay";
+				phy = <&phy3>;
+				phy-mode = "sgmii";
+			};
 
-		mvsdio at d4000 {
-			pinctrl-0 = <&sdio_pins>;
-			pinctrl-names = "default";
-			status = "okay";
-			/* No CD or WP GPIOs */
-		};
+			mvsdio at d4000 {
+				pinctrl-0 = <&sdio_pins>;
+				pinctrl-names = "default";
+				status = "okay";
+				/* No CD or WP GPIOs */
+			};
 
-		usb at 50000 {
-			status = "okay";
-		};
+			usb at 50000 {
+				status = "okay";
+			};
 
-		usb at 51000 {
-			status = "okay";
-		};
+			usb at 51000 {
+				status = "okay";
+			};
 
-		usb at 52000 {
-			status = "okay";
-		};
+			usb at 52000 {
+				status = "okay";
+			};
 
-		spi0: spi at 10600 {
-			status = "okay";
+			spi0: spi at 10600 {
+				status = "okay";
 
-			spi-flash at 0 {
-				#address-cells = <1>;
-				#size-cells = <1>;
-				compatible = "m25p64";
-				reg = <0>; /* Chip select 0 */
-				spi-max-frequency = <20000000>;
+				spi-flash at 0 {
+					#address-cells = <1>;
+					#size-cells = <1>;
+					compatible = "m25p64";
+					reg = <0>; /* Chip select 0 */
+					spi-max-frequency = <20000000>;
+				};
 			};
 		};
 	};
diff --git a/arch/arm/boot/dts/armada-xp-gp.dts b/arch/arm/boot/dts/armada-xp-gp.dts
index 12b98d3..b0298d7 100644
--- a/arch/arm/boot/dts/armada-xp-gp.dts
+++ b/arch/arm/boot/dts/armada-xp-gp.dts
@@ -37,76 +37,78 @@
 	};
 
 	soc {
-		serial at 12000 {
-			clock-frequency = <250000000>;
-			status = "okay";
-		};
-		serial at 12100 {
-			clock-frequency = <250000000>;
-			status = "okay";
-		};
-		serial at 12200 {
-			clock-frequency = <250000000>;
-			status = "okay";
-		};
-		serial at 12300 {
-			clock-frequency = <250000000>;
-			status = "okay";
-		};
-
-		sata at a0000 {
-			nr-ports = <2>;
-			status = "okay";
-		};
-
-		mdio {
-			phy0: ethernet-phy at 0 {
-				reg = <16>;
+		internal-regs {
+			serial at 12000 {
+				clock-frequency = <250000000>;
+				status = "okay";
 			};
-
-			phy1: ethernet-phy at 1 {
-				reg = <17>;
+			serial at 12100 {
+				clock-frequency = <250000000>;
+				status = "okay";
+			};
+			serial at 12200 {
+				clock-frequency = <250000000>;
+				status = "okay";
+			};
+			serial at 12300 {
+				clock-frequency = <250000000>;
+				status = "okay";
 			};
 
-			phy2: ethernet-phy at 2 {
-				reg = <18>;
+			sata at a0000 {
+				nr-ports = <2>;
+				status = "okay";
 			};
 
-			phy3: ethernet-phy at 3 {
-				reg = <19>;
+			mdio {
+				phy0: ethernet-phy at 0 {
+					reg = <16>;
+				};
+
+				phy1: ethernet-phy at 1 {
+					reg = <17>;
+				};
+
+				phy2: ethernet-phy at 2 {
+					reg = <18>;
+				};
+
+				phy3: ethernet-phy at 3 {
+					reg = <19>;
+				};
 			};
-		};
 
-		ethernet at 70000 {
-			status = "okay";
-			phy = <&phy0>;
-			phy-mode = "rgmii-id";
-		};
-		ethernet at 74000 {
-			status = "okay";
-			phy = <&phy1>;
-			phy-mode = "rgmii-id";
-		};
-		ethernet at 30000 {
-			status = "okay";
-			phy = <&phy2>;
-			phy-mode = "rgmii-id";
-		};
-		ethernet at 34000 {
-			status = "okay";
-			phy = <&phy3>;
-			phy-mode = "rgmii-id";
-		};
+			ethernet at 70000 {
+				status = "okay";
+				phy = <&phy0>;
+				phy-mode = "rgmii-id";
+			};
+			ethernet at 74000 {
+				status = "okay";
+				phy = <&phy1>;
+				phy-mode = "rgmii-id";
+			};
+			ethernet at 30000 {
+				status = "okay";
+				phy = <&phy2>;
+				phy-mode = "rgmii-id";
+			};
+			ethernet at 34000 {
+				status = "okay";
+				phy = <&phy3>;
+				phy-mode = "rgmii-id";
+			};
 
-		spi0: spi at 10600 {
-			status = "okay";
+			spi0: spi at 10600 {
+				status = "okay";
 
-			spi-flash at 0 {
-				#address-cells = <1>;
-				#size-cells = <1>;
-				compatible = "n25q128a13";
-				reg = <0>; /* Chip select 0 */
-				spi-max-frequency = <108000000>;
+				spi-flash at 0 {
+					#address-cells = <1>;
+					#size-cells = <1>;
+					compatible = "n25q128a13";
+					reg = <0>; /* Chip select 0 */
+					spi-max-frequency = <108000000>;
+				};
 			};
 		};
 	};
diff --git a/arch/arm/boot/dts/armada-xp-mv78230.dtsi b/arch/arm/boot/dts/armada-xp-mv78230.dtsi
index 40fa72e..f0d38fb 100644
--- a/arch/arm/boot/dts/armada-xp-mv78230.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78230.dtsi
@@ -44,37 +44,39 @@
 	};
 
 	soc {
-		pinctrl {
-			compatible = "marvell,mv78230-pinctrl";
-			reg = <0x18000 0x38>;
+		internal-regs {
+			pinctrl {
+				compatible = "marvell,mv78230-pinctrl";
+				reg = <0x18000 0x38>;
 
-			sdio_pins: sdio-pins {
-				marvell,pins = "mpp30", "mpp31", "mpp32",
-					       "mpp33", "mpp34", "mpp35";
-				marvell,function = "sd0";
+				sdio_pins: sdio-pins {
+					marvell,pins = "mpp30", "mpp31", "mpp32",
+						       "mpp33", "mpp34", "mpp35";
+					marvell,function = "sd0";
+				};
 			};
-		};
 
-		gpio0: gpio at 18100 {
-			compatible = "marvell,orion-gpio";
-			reg = <0x18100 0x40>;
-			ngpios = <32>;
-			gpio-controller;
-			#gpio-cells = <2>;
-			interrupt-controller;
-			#interrupts-cells = <2>;
-			interrupts = <82>, <83>, <84>, <85>;
-		};
+			gpio0: gpio at 18100 {
+				compatible = "marvell,orion-gpio";
+				reg = <0x18100 0x40>;
+				ngpios = <32>;
+				gpio-controller;
+				#gpio-cells = <2>;
+				interrupt-controller;
+				#interrupts-cells = <2>;
+				interrupts = <82>, <83>, <84>, <85>;
+			};
 
-		gpio1: gpio at 18140 {
-			compatible = "marvell,orion-gpio";
-			reg = <0x18140 0x40>;
-			ngpios = <17>;
-			gpio-controller;
-			#gpio-cells = <2>;
-			interrupt-controller;
-			#interrupts-cells = <2>;
-			interrupts = <87>, <88>, <89>;
+			gpio1: gpio at 18140 {
+				compatible = "marvell,orion-gpio";
+				reg = <0x18140 0x40>;
+				ngpios = <17>;
+				gpio-controller;
+				#gpio-cells = <2>;
+				interrupt-controller;
+				#interrupts-cells = <2>;
+				interrupts = <87>, <88>, <89>;
+			};
 		};
 	};
 };
diff --git a/arch/arm/boot/dts/armada-xp-mv78260.dtsi b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
index 7578c21..2621bda 100644
--- a/arch/arm/boot/dts/armada-xp-mv78260.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
@@ -45,56 +45,58 @@
 	};
 
 	soc {
-		pinctrl {
-			compatible = "marvell,mv78260-pinctrl";
-			reg = <0x18000 0x38>;
+		internal-regs {
+			pinctrl {
+				compatible = "marvell,mv78260-pinctrl";
+				reg = <0x18000 0x38>;
 
-			sdio_pins: sdio-pins {
-				marvell,pins = "mpp30", "mpp31", "mpp32",
-					       "mpp33", "mpp34", "mpp35";
-				marvell,function = "sd0";
+				sdio_pins: sdio-pins {
+					marvell,pins = "mpp30", "mpp31", "mpp32",
+						       "mpp33", "mpp34", "mpp35";
+					marvell,function = "sd0";
+				};
 			};
-		};
 
-		gpio0: gpio at 18100 {
-			compatible = "marvell,orion-gpio";
-			reg = <0x18100 0x40>;
-			ngpios = <32>;
-			gpio-controller;
-			#gpio-cells = <2>;
-			interrupt-controller;
-			#interrupts-cells = <2>;
-			interrupts = <82>, <83>, <84>, <85>;
-		};
+			gpio0: gpio at 18100 {
+				compatible = "marvell,orion-gpio";
+				reg = <0x18100 0x40>;
+				ngpios = <32>;
+				gpio-controller;
+				#gpio-cells = <2>;
+				interrupt-controller;
+				#interrupts-cells = <2>;
+				interrupts = <82>, <83>, <84>, <85>;
+			};
 
-		gpio1: gpio at 18140 {
-			compatible = "marvell,orion-gpio";
-			reg = <0x18140 0x40>;
-			ngpios = <32>;
-			gpio-controller;
-			#gpio-cells = <2>;
-			interrupt-controller;
-			#interrupts-cells = <2>;
-			interrupts = <87>, <88>, <89>, <90>;
-		};
+			gpio1: gpio at 18140 {
+				compatible = "marvell,orion-gpio";
+				reg = <0x18140 0x40>;
+				ngpios = <32>;
+				gpio-controller;
+				#gpio-cells = <2>;
+				interrupt-controller;
+				#interrupts-cells = <2>;
+				interrupts = <87>, <88>, <89>, <90>;
+			};
 
-		gpio2: gpio at 18180 {
-			compatible = "marvell,orion-gpio";
-			reg = <0x18180 0x40>;
-			ngpios = <3>;
-			gpio-controller;
-			#gpio-cells = <2>;
-			interrupt-controller;
-			#interrupts-cells = <2>;
-			interrupts = <91>;
-		};
+			gpio2: gpio at 18180 {
+				compatible = "marvell,orion-gpio";
+				reg = <0x18180 0x40>;
+				ngpios = <3>;
+				gpio-controller;
+				#gpio-cells = <2>;
+				interrupt-controller;
+				#interrupts-cells = <2>;
+				interrupts = <91>;
+			};
 
-		ethernet at 34000 {
+			ethernet at 34000 {
 				compatible = "marvell,armada-370-neta";
 				reg = <0x34000 0x2500>;
 				interrupts = <14>;
 				clocks = <&gateclk 1>;
 				status = "disabled";
+			};
 		};
 	};
 };
diff --git a/arch/arm/boot/dts/armada-xp-mv78460.dtsi b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
index 5280a4d..ccb95ff 100644
--- a/arch/arm/boot/dts/armada-xp-mv78460.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
@@ -60,56 +60,58 @@
 	};
 
 	soc {
-		pinctrl {
-			compatible = "marvell,mv78460-pinctrl";
-			reg = <0x18000 0x38>;
+		internal-regs {
+			pinctrl {
+				compatible = "marvell,mv78460-pinctrl";
+				reg = <0x18000 0x38>;
 
-			sdio_pins: sdio-pins {
-				marvell,pins = "mpp30", "mpp31", "mpp32",
-					       "mpp33", "mpp34", "mpp35";
-				marvell,function = "sd0";
+				sdio_pins: sdio-pins {
+					marvell,pins = "mpp30", "mpp31", "mpp32",
+						       "mpp33", "mpp34", "mpp35";
+					marvell,function = "sd0";
+				};
 			};
-		};
 
-		gpio0: gpio at 18100 {
-			compatible = "marvell,orion-gpio";
-			reg = <0x18100 0x40>;
-			ngpios = <32>;
-			gpio-controller;
-			#gpio-cells = <2>;
-			interrupt-controller;
-			#interrupts-cells = <2>;
-			interrupts = <82>, <83>, <84>, <85>;
-		};
+			gpio0: gpio at 18100 {
+				compatible = "marvell,orion-gpio";
+				reg = <0x18100 0x40>;
+				ngpios = <32>;
+				gpio-controller;
+				#gpio-cells = <2>;
+				interrupt-controller;
+				#interrupts-cells = <2>;
+				interrupts = <82>, <83>, <84>, <85>;
+			};
 
-		gpio1: gpio at 18140 {
-			compatible = "marvell,orion-gpio";
-			reg = <0x18140 0x40>;
-			ngpios = <32>;
-			gpio-controller;
-			#gpio-cells = <2>;
-			interrupt-controller;
-			#interrupts-cells = <2>;
-			interrupts = <87>, <88>, <89>, <90>;
-		};
+			gpio1: gpio at 18140 {
+				compatible = "marvell,orion-gpio";
+				reg = <0x18140 0x40>;
+				ngpios = <32>;
+				gpio-controller;
+				#gpio-cells = <2>;
+				interrupt-controller;
+				#interrupts-cells = <2>;
+				interrupts = <87>, <88>, <89>, <90>;
+			};
 
-		gpio2: gpio at 18180 {
-			compatible = "marvell,orion-gpio";
-			reg = <0x18180 0x40>;
-			ngpios = <3>;
-			gpio-controller;
-			#gpio-cells = <2>;
-			interrupt-controller;
-			#interrupts-cells = <2>;
-			interrupts = <91>;
-		};
+			gpio2: gpio at 18180 {
+				compatible = "marvell,orion-gpio";
+				reg = <0x18180 0x40>;
+				ngpios = <3>;
+				gpio-controller;
+				#gpio-cells = <2>;
+				interrupt-controller;
+				#interrupts-cells = <2>;
+				interrupts = <91>;
+			};
 
-		ethernet at 34000 {
+			ethernet at 34000 {
 				compatible = "marvell,armada-370-neta";
 				reg = <0x34000 0x2500>;
 				interrupts = <14>;
 				clocks = <&gateclk 1>;
 				status = "disabled";
+			};
 		};
 	};
  };
diff --git a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
index a7bade4..e2eaf4f 100644
--- a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
+++ b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
@@ -27,117 +27,119 @@
 	};
 
 	soc {
-		serial at 12000 {
-			clock-frequency = <250000000>;
-			status = "okay";
-		};
-		serial at 12100 {
-			clock-frequency = <250000000>;
-			status = "okay";
-		};
-		pinctrl {
-			led_pins: led-pins-0 {
-				marvell,pins = "mpp49", "mpp51", "mpp53";
-				marvell,function = "gpio";
+		internal-regs {
+			serial at 12000 {
+				clock-frequency = <250000000>;
+				status = "okay";
 			};
-		};
-		leds {
-			compatible = "gpio-leds";
-			pinctrl-names = "default";
-			pinctrl-0 = <&led_pins>;
-
-			red_led {
-				label = "red_led";
-				gpios = <&gpio1 17 1>;
-				default-state = "off";
+			serial at 12100 {
+				clock-frequency = <250000000>;
+				status = "okay";
 			};
-
-			yellow_led {
-				label = "yellow_led";
-				gpios = <&gpio1 19 1>;
-				default-state = "off";
+			pinctrl {
+				led_pins: led-pins-0 {
+					marvell,pins = "mpp49", "mpp51", "mpp53";
+					marvell,function = "gpio";
+				};
 			};
-
-			green_led {
-				label = "green_led";
-				gpios = <&gpio1 21 1>;
-				default-state = "off";
-				linux,default-trigger = "heartbeat";
+			leds {
+				compatible = "gpio-leds";
+				pinctrl-names = "default";
+				pinctrl-0 = <&led_pins>;
+
+				red_led {
+					label = "red_led";
+					gpios = <&gpio1 17 1>;
+					default-state = "off";
+				};
+
+				yellow_led {
+					label = "yellow_led";
+					gpios = <&gpio1 19 1>;
+					default-state = "off";
+				};
+
+				green_led {
+					label = "green_led";
+					gpios = <&gpio1 21 1>;
+					default-state = "off";
+					linux,default-trigger = "heartbeat";
+				};
 			};
-		};
 
-		gpio_keys {
-			compatible = "gpio-keys";
-			#address-cells = <1>;
-			#size-cells = <0>;
+			gpio_keys {
+				compatible = "gpio-keys";
+				#address-cells = <1>;
+				#size-cells = <0>;
 
-			button at 1 {
-				label = "Init Button";
-				linux,code = <116>;
-				gpios = <&gpio1 28 0>;
+				button at 1 {
+					label = "Init Button";
+					linux,code = <116>;
+					gpios = <&gpio1 28 0>;
+				};
 			};
-		};
 
-		mdio {
-			phy0: ethernet-phy at 0 {
-				reg = <0>;
-			};
+			mdio {
+				phy0: ethernet-phy at 0 {
+					reg = <0>;
+				};
 
-			phy1: ethernet-phy at 1 {
-				reg = <1>;
-			};
+				phy1: ethernet-phy at 1 {
+					reg = <1>;
+				};
 
-			phy2: ethernet-phy at 2 {
-				reg = <2>;
-			};
+				phy2: ethernet-phy at 2 {
+					reg = <2>;
+				};
 
-			phy3: ethernet-phy at 3 {
-				reg = <3>;
+				phy3: ethernet-phy at 3 {
+					reg = <3>;
+				};
 			};
-		};
-
-		ethernet at 70000 {
-			status = "okay";
-			phy = <&phy0>;
-			phy-mode = "sgmii";
-		};
-		ethernet at 74000 {
-			status = "okay";
-			phy = <&phy1>;
-			phy-mode = "sgmii";
-		};
-		ethernet at 30000 {
-			status = "okay";
-			phy = <&phy2>;
-			phy-mode = "sgmii";
-		};
-		ethernet at 34000 {
-			status = "okay";
-			phy = <&phy3>;
-			phy-mode = "sgmii";
-		};
-		i2c at 11000 {
-			status = "okay";
-			clock-frequency = <400000>;
-		};
-		i2c at 11100 {
-			status = "okay";
-			clock-frequency = <400000>;
 
-			s35390a: s35390a at 30 {
-				compatible = "s35390a";
-				reg = <0x30>;
+			ethernet at 70000 {
+				status = "okay";
+				phy = <&phy0>;
+				phy-mode = "sgmii";
+			};
+			ethernet at 74000 {
+				status = "okay";
+				phy = <&phy1>;
+				phy-mode = "sgmii";
+			};
+			ethernet at 30000 {
+				status = "okay";
+				phy = <&phy2>;
+				phy-mode = "sgmii";
+			};
+			ethernet at 34000 {
+				status = "okay";
+				phy = <&phy3>;
+				phy-mode = "sgmii";
+			};
+			i2c at 11000 {
+				status = "okay";
+				clock-frequency = <400000>;
+			};
+			i2c at 11100 {
+				status = "okay";
+				clock-frequency = <400000>;
+
+				s35390a: s35390a at 30 {
+					compatible = "s35390a";
+					reg = <0x30>;
+				};
+			};
+			sata at a0000 {
+				nr-ports = <2>;
+				status = "okay";
+			};
+			usb at 50000 {
+				status = "okay";
+			};
+			usb at 51000 {
+				status = "okay";
 			};
-		};
-		sata at a0000 {
-			nr-ports = <2>;
-			status = "okay";
-		};
-		usb at 50000 {
-			status = "okay";
-		};
-		usb at 51000 {
-			status = "okay";
 		};
 	};
 };
diff --git a/arch/arm/boot/dts/armada-xp.dtsi b/arch/arm/boot/dts/armada-xp.dtsi
index 6ca6b7a..2b39dde 100644
--- a/arch/arm/boot/dts/armada-xp.dtsi
+++ b/arch/arm/boot/dts/armada-xp.dtsi
@@ -22,135 +22,133 @@
 	model = "Marvell Armada XP family SoC";
 	compatible = "marvell,armadaxp", "marvell,armada-370-xp";
 
-
 	soc {
-		L2: l2-cache {
-			compatible = "marvell,aurora-system-cache";
-			reg = <0x08000 0x1000>;
-			cache-id-part = <0x100>;
-			wt-override;
-		};
+		internal-regs {
+			L2: l2-cache {
+				compatible = "marvell,aurora-system-cache";
+				reg = <0x08000 0x1000>;
+				cache-id-part = <0x100>;
+				wt-override;
+			};
 
-		mpic: interrupt-controller at 20000 {
-		      reg = <0x20a00 0x2d0>,
-			    <0x21070 0x58>;
-		};
+			mpic: interrupt-controller at 20000 {
+			      reg = <0x20a00 0x2d0>, <0x21070 0x58>;
+			};
 
-		armada-370-xp-pmsu at 22000 {
-			compatible = "marvell,armada-370-xp-pmsu";
-			reg = <0x22100 0x430>,
-			      <0x20800 0x20>;
-		};
+			armada-370-xp-pmsu at 22000 {
+				compatible = "marvell,armada-370-xp-pmsu";
+				reg = <0x22100 0x430>, <0x20800 0x20>;
+			};
 
-		serial at 12200 {
+			serial at 12200 {
 				compatible = "snps,dw-apb-uart";
 				reg = <0x12200 0x100>;
 				reg-shift = <2>;
 				interrupts = <43>;
 				reg-io-width = <1>;
 				status = "disabled";
-		};
-		serial at 12300 {
+			};
+			serial at 12300 {
 				compatible = "snps,dw-apb-uart";
 				reg = <0x12300 0x100>;
 				reg-shift = <2>;
 				interrupts = <44>;
 				reg-io-width = <1>;
 				status = "disabled";
-		};
+			};
 
-		timer at 20300 {
+			timer at 20300 {
 				marvell,timer-25Mhz;
-		};
+			};
 
-		coreclk: mvebu-sar at 18230 {
-			compatible = "marvell,armada-xp-core-clock";
-			reg = <0x18230 0x08>;
-			#clock-cells = <1>;
-		};
+			coreclk: mvebu-sar at 18230 {
+				compatible = "marvell,armada-xp-core-clock";
+				reg = <0x18230 0x08>;
+				#clock-cells = <1>;
+			};
 
-		cpuclk: clock-complex at 18700 {
-			#clock-cells = <1>;
-			compatible = "marvell,armada-xp-cpu-clock";
-			reg = <0x18700 0xA0>;
-			clocks = <&coreclk 1>;
-		};
+			cpuclk: clock-complex at 18700 {
+				#clock-cells = <1>;
+				compatible = "marvell,armada-xp-cpu-clock";
+				reg = <0x18700 0xA0>;
+				clocks = <&coreclk 1>;
+			};
 
-		gateclk: clock-gating-control at 18220 {
-			compatible = "marvell,armada-xp-gating-clock";
-			reg = <0x18220 0x4>;
-			clocks = <&coreclk 0>;
-			#clock-cells = <1>;
-		};
+			gateclk: clock-gating-control at 18220 {
+				compatible = "marvell,armada-xp-gating-clock";
+				reg = <0x18220 0x4>;
+				clocks = <&coreclk 0>;
+				#clock-cells = <1>;
+			};
 
-		system-controller at 18200 {
+			system-controller at 18200 {
 				compatible = "marvell,armada-370-xp-system-controller";
 				reg = <0x18200 0x500>;
-		};
+			};
 
-		ethernet at 30000 {
+			ethernet at 30000 {
 				compatible = "marvell,armada-370-neta";
 				reg = <0x30000 0x2500>;
 				interrupts = <12>;
 				clocks = <&gateclk 2>;
 				status = "disabled";
-		};
-
-		xor at 60900 {
-			compatible = "marvell,orion-xor";
-			reg = <0x60900 0x100
-			       0x60b00 0x100>;
-			clocks = <&gateclk 22>;
-			status = "okay";
-
-			xor10 {
-				interrupts = <51>;
-				dmacap,memcpy;
-				dmacap,xor;
-			};
-			xor11 {
-				interrupts = <52>;
-				dmacap,memcpy;
-				dmacap,xor;
-				dmacap,memset;
 			};
-		};
-
-		xor at f0900 {
-			compatible = "marvell,orion-xor";
-			reg = <0xF0900 0x100
-			       0xF0B00 0x100>;
-			clocks = <&gateclk 28>;
-			status = "okay";
 
-			xor00 {
-				interrupts = <94>;
-				dmacap,memcpy;
-				dmacap,xor;
+			xor at 60900 {
+				compatible = "marvell,orion-xor";
+				reg = <0x60900 0x100
+				       0x60b00 0x100>;
+				clocks = <&gateclk 22>;
+				status = "okay";
+
+				xor10 {
+					interrupts = <51>;
+					dmacap,memcpy;
+					dmacap,xor;
+				};
+				xor11 {
+					interrupts = <52>;
+					dmacap,memcpy;
+					dmacap,xor;
+					dmacap,memset;
+				};
 			};
-			xor01 {
-				interrupts = <95>;
-				dmacap,memcpy;
-				dmacap,xor;
-				dmacap,memset;
+
+			xor at f0900 {
+				compatible = "marvell,orion-xor";
+				reg = <0xF0900 0x100
+				       0xF0B00 0x100>;
+				clocks = <&gateclk 28>;
+				status = "okay";
+
+				xor00 {
+					interrupts = <94>;
+					dmacap,memcpy;
+					dmacap,xor;
+				};
+				xor01 {
+					interrupts = <95>;
+					dmacap,memcpy;
+					dmacap,xor;
+					dmacap,memset;
+				};
 			};
-		};
 
-		usb at 50000 {
-			clocks = <&gateclk 18>;
-		};
+			usb at 50000 {
+				clocks = <&gateclk 18>;
+			};
 
-		usb at 51000 {
-			clocks = <&gateclk 19>;
-		};
+			usb at 51000 {
+				clocks = <&gateclk 19>;
+			};
 
-		usb at 52000 {
-			compatible = "marvell,orion-ehci";
-			reg = <0x52000 0x500>;
-			interrupts = <47>;
-			clocks = <&gateclk 20>;
-			status = "disabled";
+			usb at 52000 {
+				compatible = "marvell,orion-ehci";
+				reg = <0x52000 0x500>;
+				interrupts = <47>;
+				clocks = <&gateclk 20>;
+				status = "disabled";
+			};
 		};
-
 	};
 };
-- 
1.7.9.5



From arnd at arndb.de  Fri Apr  5 16:33:25 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 5 Apr 2013 22:33:25 +0200
Subject: [GIT PULL] Multi Cluster Power Management infrastructure
In-Reply-To: <20130405094159.GH17995@n2100.arm.linux.org.uk>
References: <alpine.LFD.2.03.1303251219530.1372@syhkavp.arg>
 <alpine.LFD.2.03.1304042138160.1171@syhkavp.arg>
 <20130405094159.GH17995@n2100.arm.linux.org.uk>
Message-ID: <201304052233.25630.arnd@arndb.de>

On Friday 05 April 2013, Russell King - ARM Linux wrote:
> 
> Now, I'm currently on holiday.  I'm going to be on holday until after
> mid-April.  I'm not pulling anything until then.  I'm not applying anything
> until then.  I'm not even reading this mailbox - and given current mail
> rates at 300-400 messages per day, I will *not* be reading back over a
> fortnights worth of email.

I haven't reviewed the patches before, and only heard of the controversy
from Nico's email yesterday. Independent of your personal situation and
who implemented the code, I think it's clear that a lot of people (not
just Linaro) want to see it get merged and not having it upstream is
blocking platform specific code from getting put into arm-soc.

Since you are currently on holiday, I think it's best if we at least put
it into asm-soc as a for-rmk/mcpm branch in order to give it coverage
in linux-next and let us merge the dependent platform code into "late"
branches for 3.10. I still hope the nontechnical issues can be resolved
in time to let you pull it into your tree before the merge window.

Having just looked over the code myself for the first time, it
seems extremely much self-contained, so I see very little risk of
regressions and I'm sure any comments you have can be addressed in
follow-on patches.

	Arnd


From jgunthorpe at obsidianresearch.com  Fri Apr  5 16:36:52 2013
From: jgunthorpe at obsidianresearch.com (Jason Gunthorpe)
Date: Fri, 5 Apr 2013 14:36:52 -0600
Subject: mvebu-mbus: defining a DT binding
In-Reply-To: <201304052149.33533.arnd@arndb.de>
References: <20130405150200.7b6dee63@skate> <201304051928.14119.arnd@arndb.de>
 <20130405174845.GD3598@obsidianresearch.com>
 <201304052149.33533.arnd@arndb.de>
Message-ID: <20130405203652.GA10505@obsidianresearch.com>

On Fri, Apr 05, 2013 at 09:49:33PM +0200, Arnd Bergmann wrote:

> > So, given all of this - can you write out an example PCI controller
> > DT binding that uses target id in ranges?
> > 
> > This is why I suggested to include the PEX target IDs as meta-data in
> > the PEX nodes, rather than trying to encode them in ranges.
> 
> I mean something like

Okay, I see now.. Bit more complex for the PCI driver.

Here is a version with more detail:

mbus {
  ranges = <MAPDEF_INTERNAL 0xf1000000 0x100000
            MAPDEF_PEX0     ......     0xFFFFFFFF
            MAPDEF_PEX0_IO  ......     0xFFFFFFFF
            MAPDEF_PEX1     ......     0xFFFFFFFF
            MAPDEF_PEX1_IO  ......     0xFFFFFFFF>

  pcie-controller {
     compatible = "marvell,armada-370-pcie";

     // Mandatory, we need to change to PCI 3dw addressing here
     ranges = <
          // For assigned-addresses
          0x82000000 MAPDEF_INTERNAL 0 0x100000
          // Non prefetchable memory
          0x82000000 MAPDEF_PEX0  MAPDEF_PEX0  0 0xFFFFFFFF
          0x82000000 MAPDEF_PEX1  MAPDEF_PEX1  0 0xFFFFFFFF
          // IO memory
          0x81000000 MAPDEF_PEX0_IO  MAPDEF_PEX0_IO  0 0xFFFFFFFF
          0x81000000 MAPDEF_PEX1_IO  MAPDEF_PEX1_IO  0 0xFFFFFFFF>

     pcie at 0,0 {
          reg = <0x0800 0 0 0 0>;
          /* Mandatory, the driver needs to parse this range to learn
	     the MAPDEF values. */
          ranges = <0x82000000 0 0  0x82000000 MAPDEF_PEX0  0xFFFFFFFF
                    0x81000000 0 0  0x81000000 MAPDEF_PEX0_IO 0xFFFFFFFF>;

          // The internal register block for this PEX
          assigned-addresses = <0x82000800 MAPDEF_INTERNAL + 0x40000  0 0x2000>,
     }
}

Notes
 - The PEX link cannot be encoded in the highest DWORD due to the OF
   PCI rules, lets just use the lower 2 dws instead. MAPDEP_X is a 2
   dword value.
 - The bridge ranges would be offset 0 length 4G-1 in the DT since
   the value is not known. However firmware could do PCI address
   assignment and fill in corrected values.
 - Although unnecessary for Linux, the PCI driver could fill in the bridge
   ranges to reflect the actual bridge setup.
 - The top level mbus ranges can reflect the address translation:

   MAPDEF_PEX0 + 0xC0000000   0xC0000000 0x10000 // Identity map MMIO
   MAPDEF_PEX0_IO             0xD0000000 0x10000 // Translate 0xD0000000 to IO 0
 - A full featured firmware could fill in the various ranges to
   represent a working PCI bus configuration

So the PCI driver would now have to dynamically determine on its own a
host bridge aperture based on available space in the resource tree,
this is done instead of parsing ranges. I guess we could have a
'linux,host-aperture' or something as a stop gap.

The driver should create each root bridge by pulling
 - reg = the device.fn of the config space
 - assigned-addresess = the PEX internal register block
 - ranges = The target ID's for the PEX

So there is no longer a need to assume in the DT binding that a
particular device.fn refers to a particular PEX.

If this is the way to go, I hope it can be a revision on top of the
existing PCI patch set?

Did I miss anything Arnd?

Jason


From arnd at arndb.de  Fri Apr  5 16:41:14 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 5 Apr 2013 22:41:14 +0200
Subject: [PATCH v2 1/9] arm: mvebu: Limit the DMA zone when LPAE is
 selected
In-Reply-To: <1365193444-13441-2-git-send-email-gregory.clement@free-electrons.com>
References: <1365193444-13441-1-git-send-email-gregory.clement@free-electrons.com>
 <1365193444-13441-2-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <201304052241.14865.arnd@arndb.de>

On Friday 05 April 2013, Gregory CLEMENT wrote:
> When LPAE is activated on Armada XP, all registers and IOs are still
> 32bit, the 40bit extension is on the CPU to DRAM path (windows) only.
> That means that all the DMA transfer are restricted to the low 32 bits
> address space. This is limitation is achieved by selecting ZONE_DMA.
> 
> Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>


Shouldn't that be ZONE_DMA32?

	Arnd


From arnd at arndb.de  Fri Apr  5 16:43:36 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 5 Apr 2013 22:43:36 +0200
Subject: [PATCH v2 7/9] arm: dts: mvebu: introduce internal-regs node
In-Reply-To: <1365193444-13441-8-git-send-email-gregory.clement@free-electrons.com>
References: <1365193444-13441-1-git-send-email-gregory.clement@free-electrons.com>
 <1365193444-13441-8-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <201304052243.37108.arnd@arndb.de>

On Friday 05 April 2013, Gregory CLEMENT wrote:
> Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>

The patch looks good but the description is a bit short.

	Arnd


From ohaugan at codeaurora.org  Fri Apr  5 16:44:49 2013
From: ohaugan at codeaurora.org (Olav Haugan)
Date: Fri, 05 Apr 2013 13:44:49 -0700
Subject: [PATCH] documentation: iommu: add description of ARM System MMU
 binding
In-Reply-To: <1365094259-24847-1-git-send-email-will.deacon@arm.com>
References: <1365094259-24847-1-git-send-email-will.deacon@arm.com>
Message-ID: <515F37C1.4000109@codeaurora.org>

On 4/4/2013 9:50 AM, Will Deacon wrote:
> This patch adds a description of the device tree binding for the ARM
> System MMU architecture.
> 
> Cc: Rob Herring <robherring2 at gmail.com>
> Cc: Andreas Herrmann <andreas.herrmann at calxeda.com>
> Signed-off-by: Will Deacon <will.deacon at arm.com>
> ---
> 
> Hello,
> 
> The driver for this is still a WIP. Both Andreas and myself have prototype
> code, but we're planning to merge that together to get something more
> general. Deciding on the binding is a good first step.
> 
> All comments welcome,
> 
> Will
> 
>  .../devicetree/bindings/iommu/arm,smmu.txt         | 61 ++++++++++++++++++++++
>  1 file changed, 61 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/iommu/arm,smmu.txt
> 
> diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> new file mode 100644
> index 0000000..938325f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> @@ -0,0 +1,61 @@
> +* ARM System MMU Architecture Implementation
> +
> +ARM SoCs may contain an implementation of the ARM System Memory
> +Management Unit Architecture, which can be used to provide 1 or 2 stages
> +of address translation to bus masters external to the CPU.
> +
> +The SMMU may also raise interrupts in response to various fault
> +conditions.
> +
> +** System MMU required properties:
> +
> +- compatible    : Should be one of "arm,smmu-v1" or "arm,smmu-v2"
> +                  depending on the version of the architecture
> +                  implemented.
> +
> +- reg           : Base address and size of the SMMU.
> +
> +- #global-interrupts : The number of global interrupts exposed by the
> +                       device.
> +
> +- interrupts    : Interrupt list, with the first #global-irqs entries
> +                  corresponding to the global interrupts and any
> +                  following entries corresponding to context interrupts,
> +                  specified in order of their indexing by the SMMU.
> +
> +- mmu-masters   : A list of phandles to device nodes representing bus
> +                  masters for which the SMMU can provide a translation.

I am not sure I understand the use of mmu-masters. I would imagine that
the bus masters themselves would have phandles to their respective SMMUs
that provides the translation.

> +
> +- stream-ids    : A list of 16-bit values corresponding to the StreamIDs
> +                  for the devices listed in the mmu-masters property.
> +                  This list must be same length as mmu-masters, so
> +                  masters with multiple stream-ids will have multiple
> +                  entries in mmu-masters.
> +

Why are the stream IDs (SIDs) coupled with the bus masters in this way?
You are probably following a different pattern than we do. Our SMMU
driver programs the SMMU SIDs and does not really know or care which
mmu-master it belongs to.

> +** System MMU optional properties:
> +
> +- smmu-parent   : When multiple SMMUs are chained together, this
> +                  property can be used to provide a phandle to the
> +                  parent SMMU (that is the next SMMU on the path going
> +                  from the mmu-masters towards memory) node for this
> +                  SMMU.
> +
> +Example:
> +
> +        smmu {
> +                compatible = "arm,smmu-v1";
> +                reg = <0xba5e0000 0x10000>;
> +                #global-interrupts = <2>;
> +                interrupts = <0 32 4>,
> +                             <0 33 4>,
> +                             <0 34 4>, /* This is the first context interrupt */
> +                             <0 35 4>,
> +                             <0 36 4>,
> +                             <0 37 4>;
> +                mmu-masters = <&dma0>,
> +                              <&dma0>,
> +                              <&dma1>;
> +                stream-ids  = <0xd01d>,
> +                              <0xd01e>,
> +                              <0xd11c>;
> +        };
> 

Hi Will,

Please see my comments above. I would like to work with you on defining
the bindings for System MMU. We have had System MMU DT bindings for some
time and I'd like to share what we are doing in hope that we can merge
something that works for all of us.

We use some of the same properties but we have a lot more. We also model
the context banks as children of each SMMU in an object-oriented way.

Here is our current binding for SMMUv1:

* Qualcomm MSM IOMMU v1

Required properties:
- compatible : one of:
	- "qcom,msm-smmu-v1"
- reg : offset and length of the register set for the device. Optional
	offset and length for clock register for additional clock that
	needs to be turned on for access to this IOMMU.
- reg-names: "iommu_base", "clk_base" (optional)
- label: name of this IOMMU instance.

Optional properties:
- qcom,iommu-secure-id : Secure identifier for the IOMMU block
- vdd-supply : vdd-supply: phandle to GDSC regulator controlling this IOMMU.
- qcom,alt-vdd-supply : Alternative regulator needed to access IOMMU
  configuration registers.
- interrupts : should contain the performance monitor overflow interrupt
number.
- qcom,iommu-enable-halt : Enable halt of the IOMMU before programming
certain	registers
- qcom,iommu-pmu-ngroups: Number of Performance Monitor Unit (PMU) groups.
- qcom,iommu-pmu-ncounters: Number of PMU counters per group.
- qcom,iommu-pmu-event-classes: List of event classes supported.
- qcom,needs-alt-core-clk : boolean to enable the secondary core clock
for access to the IOMMU configuration registers
- qcom,iommu-bfb-regs : An array of unsigned 32-bit integers
corresponding to BFB register addresses that need to be configured for
performance tuning purposes. If this property is present, the
qcom,iommu-bfb-data must also be present. Register addresses are
specified as an offset from the base of the IOMMU hardware block. This
property may be omitted if no BFB register configuration needs to be
done for a particular IOMMU hardware instance. The registers specified
by this property shall fall within the IOMMU implementation-defined
register region.
- qcom,iommu-bfb-data : An array of unsigned 32-bit integers
representing the values to be programmed into the corresponding
registers given by the qcom,iommu-bfb-regs property. If this property is
present, the qcom,iommu-bfb-regs property shall also be present, and the
lengths of both properties shall be the same.

- List of sub nodes, one for each of the translation context banks
supported.
  Each sub node has the following required properties:

  - reg : offset and length of the register set for the context bank.
  - interrupts : should contain the context bank interrupt.
  - qcom,iommu-ctx-sids : List of stream identifiers associated with
this translation context.
  - label : Name of the context bank

Optional sub-node properties:
   - qcom,secure-context : boolean indicating that a context is secure
 and programmed by the secure environment.

Example:

	qcom,iommu at fda64000 {
		compatible = "qcom,msm-smmu-v1";
		reg = <0xfda64000 0x10000>;
		reg-names = "iommu_base";
		vdd-supply = <&gdsc_iommu>;
		qcom,iommu-bfb-regs = <0x204c 0x2050>;
		qcom,iommu-bfb-data = <0xffff 0xffce>;
		label = "iommu_0";
		qcom,iommu-pmu-ngroups = <1>;
		qcom,iommu-pmu-ncounters = <8>;
		qcom,iommu-pmu-event-classes = <0x00,
						0x01>;

		qcom,iommu-ctx at fda6c000 {
			reg = <0xfda6c000 0x1000>;
			interrupts = <0 70 0>;
			qcom,iommu-ctx-sids = <0 2>;
			label = "ctx_0";
		};
		qcom,iommu-ctx at fda6d000 {
			reg = <0xfda6d000 0x1000>;
			interrupts = <0 70 0>;
			qcom,iommu-ctx-sids = <1>;
			label = "ctx_1";
		};
	};

Please let me know your thoughts on this.

Thanks,

Olav Haugan

-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation


From arnd at arndb.de  Fri Apr  5 16:45:07 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 5 Apr 2013 22:45:07 +0200
Subject: [PATCH v2 8/9] arm: dts: mvebu: fix cpus section indentation
In-Reply-To: <1365193444-13441-9-git-send-email-gregory.clement@free-electrons.com>
References: <1365193444-13441-1-git-send-email-gregory.clement@free-electrons.com>
 <1365193444-13441-9-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <201304052245.07775.arnd@arndb.de>

On Friday 05 April 2013, Gregory CLEMENT wrote:
> From: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> 
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>

This should have a description, even though it's completely trivial.
I would also recommend moving this patch first, as the general rule
is to do cleanups first.

	Arnd


From arnd at arndb.de  Fri Apr  5 16:46:12 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 5 Apr 2013 22:46:12 +0200
Subject: [PATCH v2 0/9] rm: mvebu: Enable LPAE support for Armada XP SoCs
In-Reply-To: <1365193444-13441-1-git-send-email-gregory.clement@free-electrons.com>
References: <1365193444-13441-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <201304052246.12731.arnd@arndb.de>

On Friday 05 April 2013, Gregory CLEMENT wrote:
> The Armada XP SoCs have LPAE support. This is the second version patch
> set whixh allow to run kernel on this SoCs with LPAE support.
> 
> The biggest changes are the conversion of the device tree file to 64
> bits in order to be able to use more than 4GB of memory (without this
> the LPAE is pointless).
> 

The series looks good overall, I've commented on trivial details.

Also, please use "ARM: mvebu: ..." in the subject rather than the lower-case
version.

	Arnd


From gregory.clement at free-electrons.com  Fri Apr  5 16:48:53 2013
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Fri, 05 Apr 2013 22:48:53 +0200
Subject: [PATCH v2 7/9] arm: dts: mvebu: introduce internal-regs node
In-Reply-To: <201304052243.37108.arnd@arndb.de>
References: <1365193444-13441-1-git-send-email-gregory.clement@free-electrons.com>
 <1365193444-13441-8-git-send-email-gregory.clement@free-electrons.com>
 <201304052243.37108.arnd@arndb.de>
Message-ID: <515F38B5.7030302@free-electrons.com>

On 04/05/2013 10:43 PM, Arnd Bergmann wrote:
> On Friday 05 April 2013, Gregory CLEMENT wrote:
>> Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
> 
> The patch looks good but the description is a bit short.
> 

It cannot be more brief! :)

I explained the purpose of this patch in the cover letter and forgot to
add this explanation here.

I will expand it for next version.

Thanks.
> 	Arnd
> 


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From robherring2 at gmail.com  Fri Apr  5 16:50:51 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Fri, 05 Apr 2013 15:50:51 -0500
Subject: [PATCH v6 4/4] xen/arm: introduce xen_early_init, use PSCI on xen
In-Reply-To: <alpine.LFD.2.03.1304051324190.1171@syhkavp.arg>
References: <alpine.DEB.2.02.1304031239550.5078@kaball.uk.xensource.com>
 <1365167495-18508-4-git-send-email-stefano.stabellini@eu.citrix.com>
 <alpine.LFD.2.03.1304051217560.1171@syhkavp.arg>
 <alpine.DEB.2.02.1304051725580.21065@kaball.uk.xensource.com>
 <alpine.LFD.2.03.1304051324190.1171@syhkavp.arg>
Message-ID: <515F392B.1030200@gmail.com>

On 04/05/2013 02:36 PM, Nicolas Pitre wrote:
> On Fri, 5 Apr 2013, Stefano Stabellini wrote:
> 
>> This is what happens:
>>
>> - No Xen
>> Xen is not running on the platform and a Xen hypervisor node is not
>> available on device tree.
>> Everything keeps working seamlessly, this patch doesn't change anything.
>>
>> - we are running on Xen
>> Xen is running on the platform, we are running as a guest on Xen and an
>> hypervisor node is available on device tree.
>> Let's also assume that there aren't any "arm,cci" compatible nodes on
>> device tree because Xen wouldn't export this kind of information to any
>> guests right now. Therefore PSCI should be used to boot secondary cpus.
>> Because the versatile express machine sets smp_init to
>> vexpress_smp_init_ops, vexpress_smp_init_ops will be called.
>> vexpress_smp_init_ops sets smp_ops to vexpress_smp_ops, that *break*
>> Xen.
> 
> OK I see.
> 
>> With this patch, xen_smp_init will be called instead of
>> vexpress_smp_init_ops, and smp_ops will be set to psci_smp_ops,
>> therefore *unbreaking* Xen.
> 
> However that breaks MCPM.

You mean on bare metal, right? For the bare metal, "xen,xen" property
would not be present and xen_smp_init is not used. So the vexpress MCPM
ops will be used. Aren't Dom0 cpu's basically virtual cpus? If Xen ever
needs the MCPM support, the Xen hook itself can figure out whether to
use MCPM support.

Rob



From arnd at arndb.de  Fri Apr  5 16:50:28 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 5 Apr 2013 22:50:28 +0200
Subject: [PATCH v2 2/9] arm: mvebu: Align the internal registers virtual
 base to support LPAE
In-Reply-To: <1365193444-13441-3-git-send-email-gregory.clement@free-electrons.com>
References: <1365193444-13441-1-git-send-email-gregory.clement@free-electrons.com>
 <1365193444-13441-3-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <201304052250.28641.arnd@arndb.de>

On Friday 05 April 2013, Gregory CLEMENT wrote:
> From: Lior Amsalem <alior at marvell.com>
> 
> In order to be able to support he LPAE, the internal registers virtual
> base must be aligned to 2MB.
> 
> Signed-off-by: Lior Amsalem <alior at marvell.com>
> Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>

This is a surprising limitation. Can you extend the above text to go into more
detail where that alignment requirement comes from?

	Arnd


From sboyd at codeaurora.org  Fri Apr  5 16:57:29 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Fri,  5 Apr 2013 13:57:29 -0700
Subject: [PATCHv2] ARM: arch_timer: Silence debug preempt warnings
Message-ID: <1365195449-6755-1-git-send-email-sboyd@codeaurora.org>

Hot-plugging with CONFIG_DEBUG_PREEMPT=y on a device with arm
architected timers causes a slew of "using smp_processor_id() in
preemptible" warnings:

  BUG: using smp_processor_id() in preemptible [00000000] code: sh/111
  caller is arch_timer_cpu_notify+0x14/0xc8

This happens because sometimes the cpu notifier,
arch_timer_cpu_notify(), is called in preemptible context and
other times in non-preemptible context but we use this_cpu_ptr()
to retrieve the clockevent in all cases. We're only going to
actually use the pointer in non-preemptible context though, so
push the this_cpu_ptr() access down into the cases to force the
checks to occur only in non-preemptible contexts.

Cc: Mark Rutland <mark.rutland at arm.com>
Cc: Marc Zyngier <Marc.Zyngier at arm.com>
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---

Changes since v1:
 * Pushed down this_cpu_ptr and added a comment

 drivers/clocksource/arm_arch_timer.c | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
index d7ad425..a65a710 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -248,14 +248,16 @@ static void __cpuinit arch_timer_stop(struct clock_event_device *clk)
 static int __cpuinit arch_timer_cpu_notify(struct notifier_block *self,
 					   unsigned long action, void *hcpu)
 {
-	struct clock_event_device *evt = this_cpu_ptr(arch_timer_evt);
-
+	/*
+	 * Grab cpu pointer in each case to avoid spurious
+	 * preemptible warnings
+	 */
 	switch (action & ~CPU_TASKS_FROZEN) {
 	case CPU_STARTING:
-		arch_timer_setup(evt);
+		arch_timer_setup(this_cpu_ptr(arch_timer_evt));
 		break;
 	case CPU_DYING:
-		arch_timer_stop(evt);
+		arch_timer_stop(this_cpu_ptr(arch_timer_evt));
 		break;
 	}
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From gregory.clement at free-electrons.com  Fri Apr  5 16:59:59 2013
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Fri, 05 Apr 2013 22:59:59 +0200
Subject: [PATCH v2 1/9] arm: mvebu: Limit the DMA zone when LPAE is
 selected
In-Reply-To: <201304052241.14865.arnd@arndb.de>
References: <1365193444-13441-1-git-send-email-gregory.clement@free-electrons.com>
 <1365193444-13441-2-git-send-email-gregory.clement@free-electrons.com>
 <201304052241.14865.arnd@arndb.de>
Message-ID: <515F3B4F.3070505@free-electrons.com>

On 04/05/2013 10:41 PM, Arnd Bergmann wrote:
> On Friday 05 April 2013, Gregory CLEMENT wrote:
>> When LPAE is activated on Armada XP, all registers and IOs are still
>> 32bit, the 40bit extension is on the CPU to DRAM path (windows) only.
>> That means that all the DMA transfer are restricted to the low 32 bits
>> address space. This is limitation is achieved by selecting ZONE_DMA.
>>
>> Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
> 
> 
> Shouldn't that be ZONE_DMA32?
> 

Well common code for ARM don't manage the ZONE_DMA32. Whereas with
ZONE_DMA, setup_dma_zone() in arch/arm/mm/init.c does exactly what
I want: setting arm_dma_limit to 0xffffffff.

ZONE_DMA32 is used on arm64 however.

> 	Arnd
> 


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From arnd at arndb.de  Fri Apr  5 17:01:27 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 5 Apr 2013 23:01:27 +0200
Subject: mvebu-mbus: defining a DT binding
In-Reply-To: <20130405203652.GA10505@obsidianresearch.com>
References: <20130405150200.7b6dee63@skate> <201304052149.33533.arnd@arndb.de>
 <20130405203652.GA10505@obsidianresearch.com>
Message-ID: <201304052301.27231.arnd@arndb.de>

On Friday 05 April 2013, Jason Gunthorpe wrote:
> On Fri, Apr 05, 2013 at 09:49:33PM +0200, Arnd Bergmann wrote:

> Notes
>  - The PEX link cannot be encoded in the highest DWORD due to the OF
>    PCI rules, lets just use the lower 2 dws instead. MAPDEP_X is a 2
>    dword value.

Ok, I wondered about whether it's allowed but then concluded that it
was ok for the root bridge but not for P2P bridges. Your solution
nicely sidesteps the problem.

>  - The bridge ranges would be offset 0 length 4G-1 in the DT since
>    the value is not known. However firmware could do PCI address
>    assignment and fill in corrected values.

I don't undestand this part. It would make the topmost byte in the
4GB bus space unadressable, which seems strange. Why can't we use
the entire 4GB? Maybe we should leave at least a page?

>  - Although unnecessary for Linux, the PCI driver could fill in the bridge
>    ranges to reflect the actual bridge setup.

Correct. The IEEE PCI binding talks about this, and it seems reasonable
for actual OF implementations, but I think we can be a little sloppy
here.

>  - The top level mbus ranges can reflect the address translation:
> 
>    MAPDEF_PEX0 + 0xC0000000   0xC0000000 0x10000 // Identity map MMIO
>    MAPDEF_PEX0_IO             0xD0000000 0x10000 // Translate 0xD0000000 to IO 0

Right.

>  - A full featured firmware could fill in the various ranges to
>    represent a working PCI bus configuration

Yes, although Linux normally doesn't expect the firmware to do that. On
PowerPC, we support both ways, either trusting the firmware to completely
probe the PCI bus and fill all the properties, or doing everything
ourselves. Given that Linux already has to do it for PCIe hotplug,
there is little value in the former unless you run under a hypervisor
that does not let you reconfigure the PCI resources (e.g. some
versions of IBM pSeries).

> So the PCI driver would now have to dynamically determine on its own a
> host bridge aperture based on available space in the resource tree,
> this is done instead of parsing ranges. I guess we could have a
> 'linux,host-aperture' or something as a stop gap.

The PCI driver already has to communicate with the MBUS driver, so
it can just ask MBUS to return the largest unassigned continugous 
physical address range.

> The driver should create each root bridge by pulling
>  - reg = the device.fn of the config space
>  - assigned-addresess = the PEX internal register block
>  - ranges = The target ID's for the PEX
> 
> So there is no longer a need to assume in the DT binding that a
> particular device.fn refers to a particular PEX.
> 
> If this is the way to go, I hope it can be a revision on top of the
> existing PCI patch set?

Sounds good to me.

> Did I miss anything Arnd?

The only part I'm unsure about is the question above about the missing
byte in the 4GB address space.

	Arnd


From gregory.clement at free-electrons.com  Fri Apr  5 17:10:48 2013
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Fri, 05 Apr 2013 23:10:48 +0200
Subject: [PATCH v2 0/9] rm: mvebu: Enable LPAE support for Armada XP SoCs
In-Reply-To: <201304052246.12731.arnd@arndb.de>
References: <1365193444-13441-1-git-send-email-gregory.clement@free-electrons.com>
 <201304052246.12731.arnd@arndb.de>
Message-ID: <515F3DD8.2040108@free-electrons.com>

On 04/05/2013 10:46 PM, Arnd Bergmann wrote:
> On Friday 05 April 2013, Gregory CLEMENT wrote:
>> The Armada XP SoCs have LPAE support. This is the second version patch
>> set whixh allow to run kernel on this SoCs with LPAE support.
>>
>> The biggest changes are the conversion of the device tree file to 64
>> bits in order to be able to use more than 4GB of memory (without this
>> the LPAE is pointless).
>>
> 
> The series looks good overall, I've commented on trivial details.

So there is still hope to have this patch set in 3.10 :)

> 
> Also, please use "ARM: mvebu: ..." in the subject rather than the lower-case
> version.

OK I will, but I saw a lot of 'arm' written in lower-case int the subject of emails
on the LAKML.
> 
> 	Arnd
> 


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From ezequiel.garcia at free-electrons.com  Fri Apr  5 17:11:55 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Fri,  5 Apr 2013 18:11:55 -0300
Subject: [PATCH v2 0/5] Device Bus support for Marvell EBU SoC
Message-ID: <1365196320-15084-1-git-send-email-ezequiel.garcia@free-electrons.com>

Now that the mbus driver has been added to manage address decoding
windows it's possible to introduce the Device Bus driver.
This driver allows to access several memories and I/O devices
such as NOR, NAND, SRAM and FPGAs.

Currently the SoCs that include this Device Bus controller are:

  * Discovery:    mv78100, mv78200
  * Armada XP:    mv78230, mv78260, mv78460
  * Armada 370:   88f6710. 88f6707, 88f6w11
  * Orion 5x:     88f5182, 88f5181, 88f5281

Please note that this patchset adds proper support for
Armada XP and Armada 370 SoC only.

This applies on top of v3.9-rc5 with mbus patches applied, which can 
be found in Jason Cooper's mvebus/soc branch.
If anyone wants to try this, there's a public branch available at:

  https://github.com/MISL-EBU-System-SW/mainline-public/tree/mvebu-devbus-v2

There has been a 'byzantine' discussion regarding the mbus driver DT binding
and the way to describe address windows, and this discussion is still not
settled.

However, since I'd like to see this in v3.10, and the only thing left
to solve seems to be the device tree binding for the mbus window,
this current patchset attempts a temporary workaround.

The decoding windows are handled by the devbus driver, through the mbus API,
using the information present in the 'ranges' property. For instance:

	device-bus at d0010400 {

		ranges = <0 0 0xf0000000 0x8000000>;
		/* ... */
	}

In the above example, when the device bus driver finds a child
node for chip select '0', he will request the mbus driver to allocate a window
as described by the 'ranges' property, starting at address 0xf0000000.

As this approach has been explicitly rejected by the maintainers,
it will be completely removed, as soon as the mbus bindings are decided
and the address windows are statically describe in the dts files.

Tested on an Armada XP GP board and Plathome Openblocks AX3.

In particular I'd like to know what's the chance of having this included
for v3.10. If the driver looks good and the temporary window handling
is accepted, then I can prepare a v3 rebased on top of Gregory's LPAE work,
or on top of any other required patches.

Changes from v1:

  * Added a remove() function to unregister childs and remove address windows,
    as suggested by Thomas Petazzoni.

  * Remove unneeded 'inline' prefix on functions as suggested by Thomas Petazzoni.

  * Timings parameters are now mandatory and expressed in picoseconds,
    as requested by Jason Gunthorpe.
    This is consistent with OMAP's GPMC dts binding.

  * Fix documentation as suggested by Jason Gunthorpe.

(Please note that I've droped Thomas' Tested-by since the driver has changed
quite a lot since v1).

Thanks!

Ezequiel Garcia (5):
  drivers: memory: Introduce Marvell EBU Device Bus driver
  ARM: mvebu: Add Device Bus support for Armada 370/XP SoC
  ARM: mvebu: Add support for NOR flash device on Armada XP-GP board
  ARM: mvebu: Add support for NOR flash device on Openblocks AX3 board
  ARM: mvebu: Add Device Bus and CFI flash memory support to defconfig

 .../bindings/memory-controllers/mvebu-devbus.txt   | 151 ++++++++++
 arch/arm/boot/dts/armada-370.dtsi                  |   8 +
 arch/arm/boot/dts/armada-xp-gp.dts                 |  29 ++
 arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts   |  29 ++
 arch/arm/boot/dts/armada-xp.dtsi                   |   8 +
 arch/arm/configs/mvebu_defconfig                   |   7 +
 drivers/memory/Kconfig                             |  10 +
 drivers/memory/Makefile                            |   1 +
 drivers/memory/mvebu-devbus.c                      | 330 +++++++++++++++++++++
 9 files changed, 573 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/memory-controllers/mvebu-devbus.txt
 create mode 100644 drivers/memory/mvebu-devbus.c

-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Fri Apr  5 17:11:56 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Fri,  5 Apr 2013 18:11:56 -0300
Subject: [PATCH v2 1/5] drivers: memory: Introduce Marvell EBU Device Bus
 driver
In-Reply-To: <1365196320-15084-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1365196320-15084-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1365196320-15084-2-git-send-email-ezequiel.garcia@free-electrons.com>

Marvell EBU SoCs such as Armada 370/XP, Orion5x (88f5xxx) and
Discovery (mv78xx0) supports a Device Bus controller to access several
kinds of memories and I/O devices (NOR, NAND, SRAM, FPGA).

This commit adds a driver to handle this controller. So far only
Armada 370, Armada XP SoCs are supported.

The driver must be registered through a device tree node;
as explained in the binding document.

For each child node in the device tree, this driver will:
  * set timing parameters
  * register a child device
  * setup an address decoding window, using the mbus driver

Keep in mind the address decoding window setup is only a temporary hack.
This code will be removed from this devbus driver as soon as a proper device
tree binding for the mbus driver is added.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
---
 .../bindings/memory-controllers/mvebu-devbus.txt   | 151 ++++++++++
 drivers/memory/Kconfig                             |  10 +
 drivers/memory/Makefile                            |   1 +
 drivers/memory/mvebu-devbus.c                      | 330 +++++++++++++++++++++
 4 files changed, 492 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/memory-controllers/mvebu-devbus.txt
 create mode 100644 drivers/memory/mvebu-devbus.c

diff --git a/Documentation/devicetree/bindings/memory-controllers/mvebu-devbus.txt b/Documentation/devicetree/bindings/memory-controllers/mvebu-devbus.txt
new file mode 100644
index 0000000..5b78940
--- /dev/null
+++ b/Documentation/devicetree/bindings/memory-controllers/mvebu-devbus.txt
@@ -0,0 +1,151 @@
+Device tree bindings for MVEBU Device Bus controllers
+
+The Device Bus controller available in some Marvell's SoC allows to control
+different types of standard memory and I/O devices such as NOR, NAND, and FPGA.
+The actual devices are instantiated from the child nodes of a Device Bus node.
+
+Required properties:
+
+ - compatible:          Should be set to one of the following:
+
+                        marvell,armada370-devbus
+                        marvell,armadaxp-devbus
+                        marvell,mv78xx0-devbus
+
+ - reg:                 A resource specifier for the register space
+                        (see the example below)
+ - #address-cells:      Must be set to 2 to allow memory address translation
+ - #size-cells:         Must be set to 1 to allow CS address passing
+ - ranges:              Must be set up to reflect the memory layout with four
+                        integer values for each chip-select line in use:
+                        <cs-number> 0 <physical address of mapping> <size>
+
+Mandatory timing properties for child nodes:
+
+Read parameters:
+
+ - devbus,turn-off-ps:  Defines the time during which the controller does not
+                        drive the AD bus after the completion of a device read.
+                        This prevents contentions on the Device Bus after a read
+                        cycle from a slow device.
+
+ - devbus,dev-width:    0x0 = 8-bit
+                        0x1 = 16-bit
+                        0x2 = 32-bit
+                        0x3 = Reserved
+
+ - devbus,badr-skew-ps: Defines the time delay from from A[2:0] toggle,
+                        to read data sample. This parameter is useful for
+                        synchronous pipelined devices, where the address
+                        precedes the read data by one or two cycles.
+
+ - devbus,acc-first-ps: Defines the time delay from the negation of
+                        ALE[0] to the cycle that the first read data is sampled
+                        by the controller.
+
+ - devbus,acc-next-ps:  Defines the time delay between the cycle that
+                        samples data N and the cycle that samples data N+1
+                        (in burst accesses).
+
+ - devbus,rd-setup-ps:  Defines the time delay between DEV_CSn assertion to
+			DEV_OEn assertion. If set to 0 (default),
+                        DEV_OEn and DEV_CSn are asserted at the same cycle.
+                        This parameter has no affect on <acc-first-ps> parameter
+                        (no affect on first data sample). Set <rd-setup-ps>
+                        to a value smaller than <acc-first-ps>.
+
+ - devbus,rd-hold-ps:   Defines the time between the last data sample to the
+			de-assertion of DEV_CSn. If set to 0 (default),
+			DEV_OEn and DEV_CSn are de-asserted at the same cycle
+			(the cycle of the last data sample).
+                        This parameter has no affect on DEV_OEn de-assertion.
+                        DEV_OEn is always de-asserted the next cycle after
+                        last data sampled. Also this parameter has no
+                        affect on <turn-off-ps> parameter.
+                        Set <rd-hold-ps> to a value smaller than <turn-off-ps>.
+
+Write parameters:
+
+ - devbus,ale-wr-ps:    Defines the time delay from the ALE[0] negation cycle
+			to the DEV_WEn assertion.
+
+ - devbus,wr-low-ps:    Defines the time during which DEV_WEn is active.
+                        A[2:0] and Data are kept valid as long as DEV_WEn
+                        is active. This parameter defines the setup time of
+                        address and data to DEV_WEn rise.
+
+ - devbus,wr-high-ps:   Defines the time during which DEV_WEn is kept
+                        inactive (high) between data beats of a burst write.
+                        DEV_A[2:0] and Data are kept valid (do not toggle) for
+                        <wr-high-ps> - <tick> ps.
+			This parameter defines the hold time of address and
+			data after DEV_WEn rise.
+
+ - devbus,sync-enable: Synchronous device enable.
+                       1: True
+                       0: False
+
+An example for an Armada XP GP board, with a 16 MiB NOR device as child
+is showed below. Note that the Device Bus driver is in charge of allocating
+the mbus address decoding window for each of its child devices.
+The window is created using the chip select specified in the child
+device node together with the base address and size specified in the ranges
+property. For instance, in the example below the allocated decoding window
+will start at base address 0xf0000000, with a size 0x1000000 (16 MiB)
+for chip select 0 (a.k.a DEV_BOOTCS).
+
+This address window handling is done in this mvebu-devbus only as a temporary
+solution. It will be removed when the support for mbus device tree binding is
+added.
+
+The reg property must specify the chip select as:
+
+  0: DEV_BOOTCS
+  1: DEV_CS0
+  2: DEV_CS1
+  3: DEV_CS2
+  4: DEV_CS3
+
+Example:
+
+	device-bus at d0010400 {
+		status = "okay";
+		ranges = <0 0 0xf0000000 0x1000000>; /* CS0 @addr 0xf0000000, size 0x1000000 */
+		#address-cells = <2>;
+		#size-cells = <1>;
+
+		nor at 0 {
+			compatible = "cfi-flash";
+
+			/* CS0, 16 MiB */
+			reg = <0 0 0x1000000>;
+			bank-width = <2>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+
+			/* Device Bus parameters are required */
+			devbus,dev-width = <1>;
+
+			/* Read parameters */
+			devbus,turn-off-ps  = <60000>;
+			devbus,badr-skew-ps = <0>;
+			devbus,acc-first-ps = <124000>;
+			devbus,acc-next-ps  = <248000>;
+			devbus,rd-setup-ps  = <0>;
+			devbus,rd-hold-ps   = <0>;
+
+			/*
+			 * We split the 16 MiB in two partitions,
+			 * just as an example.
+			 */
+			partition at 0 {
+				label = "First";
+				reg = <0 0x800000>;
+			};
+
+			partition at 800000 {
+				label = "Second";
+				reg = <0x800000 0x800000>;
+			};
+		};
+	};
diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig
index 067f311..9a81ab3 100644
--- a/drivers/memory/Kconfig
+++ b/drivers/memory/Kconfig
@@ -20,6 +20,16 @@ config TI_EMIF
 	  parameters and other settings during frequency, voltage and
 	  temperature changes
 
+config MVEBU_DEVBUS
+	tristate "Marvell EBU Device Bus Controller"
+	default y
+	depends on PLAT_ORION && OF
+	help
+	  This driver is for the Device Bus controller available in some
+	  Marvell EBU SoCs such as Discovery (mv78xx0), Orion (88f5xxx) and
+	  Armada 370 and Armada XP. This controller allows to handle flash
+	  devices such as NOR, NAND, SRAM, and FPGA.
+
 config TEGRA20_MC
 	bool "Tegra20 Memory Controller(MC) driver"
 	default y
diff --git a/drivers/memory/Makefile b/drivers/memory/Makefile
index 9cce5d7..969d923 100644
--- a/drivers/memory/Makefile
+++ b/drivers/memory/Makefile
@@ -6,5 +6,6 @@ ifeq ($(CONFIG_DDR),y)
 obj-$(CONFIG_OF)		+= of_memory.o
 endif
 obj-$(CONFIG_TI_EMIF)		+= emif.o
+obj-$(CONFIG_MVEBU_DEVBUS)	+= mvebu-devbus.o
 obj-$(CONFIG_TEGRA20_MC)	+= tegra20-mc.o
 obj-$(CONFIG_TEGRA30_MC)	+= tegra30-mc.o
diff --git a/drivers/memory/mvebu-devbus.c b/drivers/memory/mvebu-devbus.c
new file mode 100644
index 0000000..2a4c455
--- /dev/null
+++ b/drivers/memory/mvebu-devbus.c
@@ -0,0 +1,330 @@
+/*
+ * Marvell EBU SoC Device Bus Controller
+ * (memory controller for NOR/NAND/SRAM/FPGA devices)
+ *
+ * Copyright (C) 2013 Marvell
+ *
+ * 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 version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
+ *
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/slab.h>
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/clk.h>
+#include <linux/mbus.h>
+#include <linux/of_platform.h>
+#include <linux/of_address.h>
+#include <linux/platform_device.h>
+
+/* Register definitions */
+#define DEV_WIDTH_BIT		30
+#define BADR_SKEW_BIT		28
+#define RD_HOLD_BIT		23
+#define ACC_NEXT_BIT		17
+#define RD_SETUP_BIT		12
+#define ACC_FIRST_BIT		6
+
+#define SYNC_ENABLE_BIT		24
+#define WR_HIGH_BIT		16
+#define WR_LOW_BIT		8
+
+#define READ_PARAM_OFFSET(cs)	(0x0 + (cs << 3))
+#define WRITE_PARAM_OFFSET(cs)	(0x4 + (cs << 3))
+
+#define DEVBUS_MAXCHILDS_NR	5
+
+static const char * const devbus_wins[] = {
+	"devbus-boot",
+	"devbus-cs0",
+	"devbus-cs1",
+	"devbus-cs2",
+	"devbus-cs3",
+};
+
+struct devbus_read_params {
+	u32 dev_width;
+	u32 badr_skew;
+	u32 turn_off;
+	u32 acc_first;
+	u32 acc_next;
+	u32 rd_setup;
+	u32 rd_hold;
+};
+
+struct devbus_write_params {
+	u32 sync_enable;
+	u32 wr_high;
+	u32 wr_low;
+	u32 ale_wr;
+};
+
+struct devbus_child {
+	struct platform_device *pdev;
+	struct resource mem_res;
+};
+
+struct devbus {
+	struct device *dev;
+	void __iomem *base;
+	unsigned long tick_ps;
+
+	struct devbus_child childs[DEVBUS_MAXCHILDS_NR];
+};
+
+static void get_timing_param_ps(struct devbus *devbus,
+				struct device_node *node,
+				const char *name,
+				u32 *ticks)
+{
+	u32 time_ps;
+
+	of_property_read_u32(node, name, &time_ps);
+
+	*ticks = (time_ps + devbus->tick_ps - 1) / devbus->tick_ps;
+
+	dev_dbg(devbus->dev, "%s: %u ps -> 0x%x\n",
+		name, time_ps, *ticks);
+}
+
+static void devbus_set_timing_params(struct devbus *devbus,
+				     struct device_node *node,
+				     int cs)
+{
+	struct devbus_read_params r;
+	struct devbus_write_params w;
+	u32 value;
+
+	dev_dbg(devbus->dev, "Setting timing parameter, tick is %lu ps\n",
+		devbus->tick_ps);
+
+	of_property_read_u32(node, "devbus,dev-width", &r.dev_width);
+
+	/* Get read timings */
+	get_timing_param_ps(devbus, node, "devbus,badr-skew-ps", &r.badr_skew);
+	get_timing_param_ps(devbus, node, "devbus,turn-off-ps", &r.turn_off);
+	get_timing_param_ps(devbus, node, "devbus,acc-first-ps", &r.acc_first);
+	get_timing_param_ps(devbus, node, "devbus,acc-next-ps", &r.acc_next);
+	get_timing_param_ps(devbus, node, "devbus,rd-setup-ps", &r.rd_setup);
+	get_timing_param_ps(devbus, node, "devbus,rd-hold-ps", &r.rd_hold);
+
+	/* Get write timings */
+	get_timing_param_ps(devbus, node, "devbus,ale-wr-ps", &w.ale_wr);
+	get_timing_param_ps(devbus, node, "devbus,wr-low-ps", &w.wr_low);
+	get_timing_param_ps(devbus, node, "devbus,wr-high-ps", &w.wr_high);
+
+	of_property_read_u32(node, "devbus,sync-enable", &w.sync_enable);
+
+	/* Set read timings */
+	value = r.dev_width << DEV_WIDTH_BIT |
+		r.badr_skew << BADR_SKEW_BIT |
+		r.rd_hold   << RD_HOLD_BIT   |
+		r.acc_next  << ACC_NEXT_BIT  |
+		r.rd_setup  << RD_SETUP_BIT  |
+		r.acc_first << ACC_FIRST_BIT |
+		r.turn_off;
+
+	dev_dbg(devbus->dev, "CS%d read parameters register 0x%p = 0x%x\n",
+		cs, devbus->base + READ_PARAM_OFFSET(cs),
+		value);
+
+	writel(value, devbus->base + READ_PARAM_OFFSET(cs));
+
+	/* Set write timings */
+	value = w.sync_enable  << SYNC_ENABLE_BIT |
+		w.wr_low       << WR_LOW_BIT      |
+		w.wr_high      << WR_HIGH_BIT     |
+		w.ale_wr;
+
+	dev_dbg(devbus->dev, "CS%d write parameters register: 0x%p = 0x%x\n",
+		cs, devbus->base + WRITE_PARAM_OFFSET(cs),
+		value);
+
+	writel(value, devbus->base + WRITE_PARAM_OFFSET(cs));
+}
+
+static int devbus_probe_nor_child(struct devbus *devbus,
+				  struct platform_device *pdev,
+				  struct device_node *node)
+{
+	struct device *dev = &pdev->dev;
+	struct devbus_child *child;
+	int err;
+	int bank_width;
+	u32 cs;
+
+	/* Read chip select and size */
+	if (of_property_read_u32(node, "reg", &cs) < 0) {
+		dev_err(dev, "%s has no 'reg' property\n", node->full_name);
+		return -ENODEV;
+	}
+
+	/* Sanity checks */
+	if (cs >= DEVBUS_MAXCHILDS_NR)
+		return -ENODEV;
+
+	if (devbus->childs[cs].pdev)
+		return -EBUSY;
+
+	child = &devbus->childs[cs];
+
+	if (of_address_to_resource(node, 0, &child->mem_res)) {
+		dev_err(dev, "%s has malformed 'reg' property\n",
+			node->full_name);
+		return -ENODEV;
+	}
+
+	err = of_property_read_u32(node, "bank-width", &bank_width);
+	if (err) {
+		dev_err(dev, "error %d reading bank-width property\n", err);
+		return err;
+	}
+
+	/*
+	 * Allocate an address window for this device.
+	 * If the device probing fails, then we won't be able to
+	 * remove the allocated address decoding window.
+	 *
+	 * FIXME: This is only a temporary hack! We need to do this here
+	 * because we still don't have device tree bindings for mbus.
+	 * Once that support is added, we will declare these address windows
+	 * statically in the device tree, and remove the window configuration
+	 * from here.
+	 */
+	err = mvebu_mbus_add_window(devbus_wins[cs], child->mem_res.start,
+				    resource_size(&child->mem_res));
+	if (err < 0)
+		return err;
+
+	/* Read the device tree child node and set the new parameters */
+	devbus_set_timing_params(devbus, node, cs);
+
+	/*
+	 * If we manage to set 'simple-bus' compatible string
+	 * to device-bus node, then we don't really need this.
+	 */
+	child->pdev = of_platform_device_create(node, NULL, &pdev->dev);
+	if (!child->pdev) {
+		dev_warn(dev, "cannot create child device %s\n", node->name);
+		/* Remove the allocated window */
+		mvebu_mbus_del_window(child->mem_res.start,
+				      resource_size(&child->mem_res));
+	}
+
+	return 0;
+}
+
+static int mvebu_devbus_probe(struct platform_device *pdev)
+{
+	struct device_node *child;
+	struct devbus *devbus;
+	struct resource *res;
+	struct clk *clk;
+	unsigned long rate;
+	int err;
+
+	devbus = devm_kzalloc(&pdev->dev, sizeof(struct devbus), GFP_KERNEL);
+	if (!devbus)
+		return -ENOMEM;
+
+	devbus->dev = &pdev->dev;
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	devbus->base = devm_ioremap_resource(&pdev->dev, res);
+	if (IS_ERR(devbus->base))
+		return PTR_ERR(devbus->base);
+
+	clk = devm_clk_get(&pdev->dev, NULL);
+	if (IS_ERR(clk))
+		return PTR_ERR(clk);
+	clk_prepare_enable(clk);
+
+	/*
+	 * Obtain clock period in picoseconds,
+	 * we need this in order to convert timing
+	 * parameters from cycles to picoseconds.
+	 */
+	rate = clk_get_rate(clk) / 1000;
+	devbus->tick_ps = 1000000000 / rate;
+
+	/*
+	 * We probe NOR/NAND with different functions, because
+	 * we expect them to have some different parameters.
+	 * If this turns out not to be the case, we'll be able
+	 * to use any name for the child, and rename to devbus_probe_child().
+	 */
+	for_each_node_by_name(child, "nor") {
+		err = devbus_probe_nor_child(devbus, pdev, child);
+		if (err < 0) {
+			of_node_put(child);
+			return err;
+		}
+	}
+
+	platform_set_drvdata(pdev, devbus);
+
+	return 0;
+}
+
+static int mvebu_devbus_remove(struct platform_device *pdev)
+{
+	int i;
+	struct devbus *devbus = platform_get_drvdata(pdev);
+
+	for (i = 0; i < DEVBUS_MAXCHILDS_NR; i++) {
+		struct devbus_child *child;
+
+		if (!devbus->childs[i].pdev)
+			continue;
+
+		child = &devbus->childs[i];
+
+		/* Release device */
+		of_device_unregister(child->pdev);
+
+		/* Release window */
+		mvebu_mbus_del_window(child->mem_res.start,
+				      resource_size(&child->mem_res));
+
+		child->pdev = NULL;
+	}
+
+	platform_set_drvdata(pdev, NULL);
+
+	return 0;
+}
+
+/* Perhaps it makes sense to unify both compatible strins? */
+static const struct of_device_id mvebu_devbus_of_match[] = {
+	{ .compatible = "marvell,armada370-devbus"	 },
+	{ .compatible = "marvell,armadaxp-devbus"	 },
+	{},
+};
+MODULE_DEVICE_TABLE(of, mvebu_devbus_of_match);
+
+static struct platform_driver mvebu_devbus_driver = {
+	.probe		= mvebu_devbus_probe,
+	.remove		= mvebu_devbus_remove,
+	.driver		= {
+		.name	= "mvebu-devbus",
+		.owner	= THIS_MODULE,
+		.of_match_table = mvebu_devbus_of_match,
+	},
+};
+
+module_platform_driver(mvebu_devbus_driver);
+
+MODULE_LICENSE("GPL v2");
+MODULE_AUTHOR("Ezequiel Garcia <ezequiel.garcia at free-electrons.com>");
+MODULE_DESCRIPTION("Marvell EBU SoC Device Bus controller");
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Fri Apr  5 17:11:57 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Fri,  5 Apr 2013 18:11:57 -0300
Subject: [PATCH v2 2/5] ARM: mvebu: Add Device Bus support for Armada 370/XP
 SoC
In-Reply-To: <1365196320-15084-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1365196320-15084-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1365196320-15084-3-git-send-email-ezequiel.garcia@free-electrons.com>

Armada 370 and Armada XP SoC have a Device Bus controller to
handle NOR, NAND, SRAM and FPGA devices.
This patch adds the device tree node to enable the controller.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
---
 arch/arm/boot/dts/armada-370.dtsi | 8 ++++++++
 arch/arm/boot/dts/armada-xp.dtsi  | 8 ++++++++
 2 files changed, 16 insertions(+)

diff --git a/arch/arm/boot/dts/armada-370.dtsi b/arch/arm/boot/dts/armada-370.dtsi
index 8188d13..c40358c 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -153,5 +153,13 @@
 			clocks = <&coreclk 0>;
 		};
 
+		device-bus at d0010400 {
+			compatible = "marvell,armada370-devbus";
+			reg = <0xd0010400 0xe0>;
+			#address-cells = <2>;
+			#size-cells = <1>;
+			clocks = <&coreclk 0>;
+			status = "disabled";
+		};
 	};
 };
diff --git a/arch/arm/boot/dts/armada-xp.dtsi b/arch/arm/boot/dts/armada-xp.dtsi
index ca00d83..0c56cca 100644
--- a/arch/arm/boot/dts/armada-xp.dtsi
+++ b/arch/arm/boot/dts/armada-xp.dtsi
@@ -151,5 +151,13 @@
 			status = "disabled";
 		};
 
+		device-bus at d0010400 {
+			compatible = "marvell,armadaxp-devbus";
+			reg = <0xd0010400 0xe0>;
+			#address-cells = <2>;
+			#size-cells = <1>;
+			clocks = <&coreclk 0>;
+			status = "disabled";
+		};
 	};
 };
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Fri Apr  5 17:11:58 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Fri,  5 Apr 2013 18:11:58 -0300
Subject: [PATCH v2 3/5] ARM: mvebu: Add support for NOR flash device on Armada
 XP-GP board
In-Reply-To: <1365196320-15084-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1365196320-15084-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1365196320-15084-4-git-send-email-ezequiel.garcia@free-electrons.com>

The Armada XP Development Board DB-MV784MP-GP has a NOR flash device
connected to the Device Bus. This commit adds the device tree node
to support this device.

This SoC supports a flexible and dynamic decoding window allocation
scheme; but since this feature is still not implemented we need
to specify the window base address in the device tree node itself.

This base address has been selected in a completely arbitrary fashion.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
---
 arch/arm/boot/dts/armada-xp-gp.dts | 29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)

diff --git a/arch/arm/boot/dts/armada-xp-gp.dts b/arch/arm/boot/dts/armada-xp-gp.dts
index 1c8afe2..a2c3862 100644
--- a/arch/arm/boot/dts/armada-xp-gp.dts
+++ b/arch/arm/boot/dts/armada-xp-gp.dts
@@ -109,5 +109,34 @@
 				spi-max-frequency = <108000000>;
 			};
 		};
+
+		device-bus at d0010400 {
+			status = "okay";
+			ranges = <0 0 0xf0000000 0x01000000>; /* CS0 @addr 0xf000000, size 0x1000000 */
+
+			/* CS0, 16 MiB */
+			nor at 0 {
+				compatible = "cfi-flash";
+				reg = <0 0 0x01000000>;
+				bank-width = <2>;
+
+				/* Device Bus parameters are required */
+
+				/* Read parameters */
+				devbus,dev-width    = <1>;
+				devbus,turn-off-ps  = <60000>;
+				devbus,badr-skew-ps = <0>;
+				devbus,acc-first-ps = <124000>;
+				devbus,acc-next-ps  = <248000>;
+				devbus,rd-setup-ps  = <0>;
+				devbus,rd-hold-ps   = <0>;
+
+				/* Write parameters */
+				devbus,sync-enable = <0>;
+				devbus,wr-high-ps  = <60000>;
+				devbus,wr-low-ps   = <60000>;
+				devbus,ale-wr-ps   = <60000>;
+			};
+		};
 	};
 };
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Fri Apr  5 17:11:59 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Fri,  5 Apr 2013 18:11:59 -0300
Subject: [PATCH v2 4/5] ARM: mvebu: Add support for NOR flash device on
 Openblocks AX3 board
In-Reply-To: <1365196320-15084-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1365196320-15084-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1365196320-15084-5-git-send-email-ezequiel.garcia@free-electrons.com>

The Plat'home Openblocks AX3 has a 128 MiB NOR flash device connected
to the Device Bus. This commit adds the device tree node to support this device.

The SoC supports a flexible and dynamic decoding window allocation scheme;
but since this feature is still not implemented we need to specify the window
base address in the device tree node itself.
This base address has been selected in a completely arbitrary fashion.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
---
 arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 29 ++++++++++++++++++++++++
 1 file changed, 29 insertions(+)

diff --git a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
index 3818a82..53ad2a6 100644
--- a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
+++ b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
@@ -139,5 +139,34 @@
 		usb at d0051000 {
 			status = "okay";
 		};
+
+		device-bus at d0010400 {
+			status = "okay";
+			ranges = <0 0 0xf0000000 0x8000000>; /* CS0 @addr 0xf000000, size 0x8000000 */
+
+			/* CS0, 128 MiB */
+			nor at 0 {
+				compatible = "cfi-flash";
+				reg = <0 0 0x8000000>;
+				bank-width = <2>;
+
+				/* Device Bus parameters are required */
+
+				/* Read parameters */
+				devbus,dev-width    = <1>;
+				devbus,turn-off-ps  = <60000>;
+				devbus,badr-skew-ps = <0>;
+				devbus,acc-first-ps = <124000>;
+				devbus,acc-next-ps  = <248000>;
+				devbus,rd-setup-ps  = <0>;
+				devbus,rd-hold-ps   = <0>;
+
+				/* Write parameters */
+				devbus,sync-enable = <0>;
+				devbus,wr-high-ps  = <60000>;
+				devbus,wr-low-ps   = <60000>;
+				devbus,ale-wr-ps   = <60000>;
+			};
+		};
 	};
 };
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Fri Apr  5 17:12:00 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Fri,  5 Apr 2013 18:12:00 -0300
Subject: [PATCH v2 5/5] ARM: mvebu: Add Device Bus and CFI flash memory
 support to defconfig
In-Reply-To: <1365196320-15084-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1365196320-15084-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1365196320-15084-6-git-send-email-ezequiel.garcia@free-electrons.com>

This patch selects the devbus driver as part of the mvebu default
config, along with the required options to detect and support
CFI flash memories.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
---
 arch/arm/configs/mvebu_defconfig | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/configs/mvebu_defconfig b/arch/arm/configs/mvebu_defconfig
index 2ec8119..fe8ba26 100644
--- a/arch/arm/configs/mvebu_defconfig
+++ b/arch/arm/configs/mvebu_defconfig
@@ -46,6 +46,11 @@ CONFIG_I2C_MV64XXX=y
 CONFIG_MTD=y
 CONFIG_MTD_CHAR=y
 CONFIG_MTD_M25P80=y
+CONFIG_MTD_CFI=y
+CONFIG_MTD_CFI_INTELEXT=y
+CONFIG_MTD_CFI_AMDSTD=y
+CONFIG_MTD_CFI_STAA=y
+CONFIG_MTD_PHYSMAP_OF=y
 CONFIG_SERIAL_8250_DW=y
 CONFIG_GPIOLIB=y
 CONFIG_GPIO_SYSFS=y
@@ -65,6 +70,8 @@ CONFIG_RTC_DRV_S35390A=y
 CONFIG_RTC_DRV_MV=y
 CONFIG_DMADEVICES=y
 CONFIG_MV_XOR=y
+CONFIG_MEMORY=y
+CONFIG_MVEBU_DEVBUS=y
 # CONFIG_IOMMU_SUPPORT is not set
 CONFIG_EXT2_FS=y
 CONFIG_EXT3_FS=y
-- 
1.8.1.5



From gregory.clement at free-electrons.com  Fri Apr  5 17:13:58 2013
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Fri, 05 Apr 2013 23:13:58 +0200
Subject: [PATCH v2 2/9] arm: mvebu: Align the internal registers virtual
 base to support LPAE
In-Reply-To: <201304052250.28641.arnd@arndb.de>
References: <1365193444-13441-1-git-send-email-gregory.clement@free-electrons.com>
 <1365193444-13441-3-git-send-email-gregory.clement@free-electrons.com>
 <201304052250.28641.arnd@arndb.de>
Message-ID: <515F3E96.4040307@free-electrons.com>

On 04/05/2013 10:50 PM, Arnd Bergmann wrote:
> On Friday 05 April 2013, Gregory CLEMENT wrote:
>> From: Lior Amsalem <alior at marvell.com>
>>
>> In order to be able to support he LPAE, the internal registers virtual
>> base must be aligned to 2MB.
>>
>> Signed-off-by: Lior Amsalem <alior at marvell.com>
>> Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
> 
> This is a surprising limitation. Can you extend the above text to go into more
> detail where that alignment requirement comes from?
> 

The explanation I had was that in LPAE section size is 2MB, in earlyprintk we map
the internal registers and it must be section aligned.

> 	Arnd
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From olof at lixom.net  Fri Apr  5 17:07:44 2013
From: olof at lixom.net (Olof Johansson)
Date: Fri, 5 Apr 2013 14:07:44 -0700
Subject: [GIT PULL] Multi Cluster Power Management infrastructure
In-Reply-To: <201304052233.25630.arnd@arndb.de>
References: <alpine.LFD.2.03.1303251219530.1372@syhkavp.arg>
 <alpine.LFD.2.03.1304042138160.1171@syhkavp.arg>
 <20130405094159.GH17995@n2100.arm.linux.org.uk>
 <201304052233.25630.arnd@arndb.de>
Message-ID: <CAOesGMiN1oEMTjVVOiXs2ynccnvTgFgn=Fy1wGHhsGqL0XUATQ@mail.gmail.com>

On Fri, Apr 5, 2013 at 1:33 PM, Arnd Bergmann <arnd at arndb.de> wrote:
> On Friday 05 April 2013, Russell King - ARM Linux wrote:
>>
>> Now, I'm currently on holiday.  I'm going to be on holday until after
>> mid-April.  I'm not pulling anything until then.  I'm not applying anything
>> until then.  I'm not even reading this mailbox - and given current mail
>> rates at 300-400 messages per day, I will *not* be reading back over a
>> fortnights worth of email.
>
> I haven't reviewed the patches before, and only heard of the controversy
> from Nico's email yesterday. Independent of your personal situation and
> who implemented the code, I think it's clear that a lot of people (not
> just Linaro) want to see it get merged and not having it upstream is
> blocking platform specific code from getting put into arm-soc.

I'd prefer not to step into the middle of the personal controversy
either, but I do have some follow-on question and opinion on the code
that depends on this:

Can someone please provide a link or subject for the posted patch
series for the dependent platform code? I tried to search for it on
the lists but didn't have much luck.

> Since you are currently on holiday, I think it's best if we at least put
> it into asm-soc as a for-rmk/mcpm branch in order to give it coverage
> in linux-next and let us merge the dependent platform code into "late"
> branches for 3.10. I still hope the nontechnical issues can be resolved
> in time to let you pull it into your tree before the merge window.

I think platform code should wait until 3.11 instead of getting
crammed in at post-rc6. If it hasn't already been posted by now, it
should most definitely wait. That also saves on any contentious
dependency between the two.

> Having just looked over the code myself for the first time, it
> seems extremely much self-contained, so I see very little risk of
> regressions and I'm sure any comments you have can be addressed in
> follow-on patches.

I hope so too, but I would prefer to not build dependencies until
that's been dealt with.


-Olof


From nicolas.pitre at linaro.org  Fri Apr  5 17:21:15 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Fri, 5 Apr 2013 17:21:15 -0400 (EDT)
Subject: [PATCH v6 4/4] xen/arm: introduce xen_early_init, use PSCI on xen
In-Reply-To: <515F392B.1030200@gmail.com>
References: <alpine.DEB.2.02.1304031239550.5078@kaball.uk.xensource.com>
 <1365167495-18508-4-git-send-email-stefano.stabellini@eu.citrix.com>
 <alpine.LFD.2.03.1304051217560.1171@syhkavp.arg>
 <alpine.DEB.2.02.1304051725580.21065@kaball.uk.xensource.com>
 <alpine.LFD.2.03.1304051324190.1171@syhkavp.arg> <515F392B.1030200@gmail.com>
Message-ID: <alpine.LFD.2.03.1304051718020.1171@syhkavp.arg>

On Fri, 5 Apr 2013, Rob Herring wrote:

> On 04/05/2013 02:36 PM, Nicolas Pitre wrote:
> > On Fri, 5 Apr 2013, Stefano Stabellini wrote:
> > 
> >> This is what happens:
> >>
> >> - No Xen
> >> Xen is not running on the platform and a Xen hypervisor node is not
> >> available on device tree.
> >> Everything keeps working seamlessly, this patch doesn't change anything.
> >>
> >> - we are running on Xen
> >> Xen is running on the platform, we are running as a guest on Xen and an
> >> hypervisor node is available on device tree.
> >> Let's also assume that there aren't any "arm,cci" compatible nodes on
> >> device tree because Xen wouldn't export this kind of information to any
> >> guests right now. Therefore PSCI should be used to boot secondary cpus.
> >> Because the versatile express machine sets smp_init to
> >> vexpress_smp_init_ops, vexpress_smp_init_ops will be called.
> >> vexpress_smp_init_ops sets smp_ops to vexpress_smp_ops, that *break*
> >> Xen.
> > 
> > OK I see.
> > 
> >> With this patch, xen_smp_init will be called instead of
> >> vexpress_smp_init_ops, and smp_ops will be set to psci_smp_ops,
> >> therefore *unbreaking* Xen.
> > 
> > However that breaks MCPM.
> 
> You mean on bare metal, right? For the bare metal, "xen,xen" property
> would not be present and xen_smp_init is not used. So the vexpress MCPM
> ops will be used. Aren't Dom0 cpu's basically virtual cpus? If Xen ever
> needs the MCPM support, the Xen hook itself can figure out whether to
> use MCPM support.

Well, if Xen has its own mdesc distinct from the VExpress one then 
things
are indeed fine.


Nicolas


From jgunthorpe at obsidianresearch.com  Fri Apr  5 17:21:43 2013
From: jgunthorpe at obsidianresearch.com (Jason Gunthorpe)
Date: Fri, 5 Apr 2013 15:21:43 -0600
Subject: mvebu-mbus: defining a DT binding
In-Reply-To: <201304052301.27231.arnd@arndb.de>
References: <20130405150200.7b6dee63@skate> <201304052149.33533.arnd@arndb.de>
 <20130405203652.GA10505@obsidianresearch.com>
 <201304052301.27231.arnd@arndb.de>
Message-ID: <20130405212143.GA16221@obsidianresearch.com>

On Fri, Apr 05, 2013 at 11:01:27PM +0200, Arnd Bergmann wrote:

> >  - The bridge ranges would be offset 0 length 4G-1 in the DT since
> >    the value is not known. However firmware could do PCI address
> >    assignment and fill in corrected values.
> 
> I don't undestand this part. It would make the topmost byte in the
> 4GB bus space unadressable, which seems strange. Why can't we use
> the entire 4GB? Maybe we should leave at least a page?

Oh, sorry, that was just a mostly arbitary hacky choice to fit within
1 size cell. Using 2 size cells requires an upgrade to skeleton64 for
all mvebu platforms, eg kirkwood.

Realistically this size should never be used so it doesn't matter if
it is 4G or 4G-1 - though obviously 4G is preferred in cases where
size cells is 2. :)

> >  - A full featured firmware could fill in the various ranges to
> >    represent a working PCI bus configuration
> 
> Yes, although Linux normally doesn't expect the firmware to do that. On
> PowerPC, we support both ways, either trusting the firmware to completely
> probe the PCI bus and fill all the properties, or doing everything
> ourselves. Given that Linux already has to do it for PCIe hotplug,
> there is little value in the former unless you run under a hypervisor
> that does not let you reconfigure the PCI resources (e.g. some
> versions of IBM pSeries).

Well, x86 is sort of half and half. If Linux is happy with the
firmware values it uses them, otherwise things can change. Hotplug
tries to work within those values in some cases.

There is a real need for this, any time the firmware is re-entered it
could touch any of the address map. Moving things around could break
that. On x86 there are re-entry points in AHCI, EFI, and system
management mode.

ARM seems to be developing PSCI which is a similar firmware re-entry
point, and 'secure mode' seems to be another (???)

So.. I don't think it matters today for mvebu, but something to think
about - shuffling the firmware's address map could be dangerous.

> > So the PCI driver would now have to dynamically determine on its own a
> > host bridge aperture based on available space in the resource tree,
> > this is done instead of parsing ranges. I guess we could have a
> > 'linux,host-aperture' or something as a stop gap.
> 
> The PCI driver already has to communicate with the MBUS driver, so
> it can just ask MBUS to return the largest unassigned continugous 
> physical address range.

Right, this information should be in the resource tracking stuff as
well. (/proc/iomem should work properly, for instance)

Jason


From ezequiel.garcia at free-electrons.com  Fri Apr  5 17:26:17 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Fri, 5 Apr 2013 18:26:17 -0300
Subject: mvebu: Device bus driver resurrection
In-Reply-To: <20130326164505.GB30255@obsidianresearch.com>
References: <20130326124337.GD2454@localhost>
 <20130326164505.GB30255@obsidianresearch.com>
Message-ID: <20130405212616.GB2290@localhost>

Hi Jason,

On Tue, Mar 26, 2013 at 10:45:05AM -0600, Jason Gunthorpe wrote:
> On Tue, Mar 26, 2013 at 09:43:38AM -0300, Ezequiel Garcia wrote:
> > Hello everyone,
> > 
> > Now that we've all agreed on a mvebu mbus driver (or a first version of it)
> > I'd like to resurrect the Device Bus driver.
> > 
> > As far as I can remember, the last things said about this driver were:
> > 
> >   * The timing parameters should be in {nano,pico,etc} seconds,
> >     instead of ticks.
> 
> Yes, and I saw Rob Herring note that the DT parameters in cases like
> that should end in -ps
>  
> >   * Although not everyone agreed, this driver was a good thing to have
> >     so we no longer depend on the bootloader setting these parameters.
> 
> Please make the timing parameters mandatory, not optional. If boot
> loader set timing is going to be used then this driver should not be
> involved. Otherwise the timing should be fully specified and no values
> from the bootloader should be retained.
> 
> >   * The address decoding windows should *not* be setup by this driver,
> >     but rather be described in the device tree itself.
> 
> I'm going to suggest you send out a quick DT sample for what you are
> thinking, that might save lots of effort?
> 

I've just sent a v2 for the Device Bus work, which takes care of all
your comments, except for the quick DT sample.
I hope it looks better now!

I'm not sure how close we are to an agreed mbus DTS binding, but I hope
the Device Bus can still get merged as it is, so we can have NOR support
as early as possible. Since the proposed DTS is really minimal, I expect
it to be innocuous.

If at all possible, could you take a look at it and tell me what do you think?
-- 
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com


From khilman at linaro.org  Fri Apr  5 17:29:03 2013
From: khilman at linaro.org (Kevin Hilman)
Date: Fri, 05 Apr 2013 14:29:03 -0700
Subject: [PATCH v3 4/4] ARM: OMAP4+: CPUidle: Consolidate idle driver for
 OMAP5 support
In-Reply-To: <1365166743-5940-5-git-send-email-santosh.shilimkar@ti.com>
 (Santosh Shilimkar's message of "Fri, 5 Apr 2013 18:29:03 +0530")
References: <1365166743-5940-1-git-send-email-santosh.shilimkar@ti.com>
 <1365166743-5940-5-git-send-email-santosh.shilimkar@ti.com>
Message-ID: <878v4wll9c.fsf@linaro.org>

Santosh Shilimkar <santosh.shilimkar at ti.com> writes:

> The OMAP5 idle driver can re-use most of OMAP4 CPUidle driver
> implementation. Also the next derivative SOCs are going to re-use
> the MPUSS so, same driver with minor updates can be re-used.
>
> Prepare the code so that its easier to add CPUidle support for
> OMAP5 devices.
>
> Acked-by: Nishanth Menon <nm at ti.com>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>

Due to dependencies, I'll add this one to my for_3.10/cleanup/cpuidle
branch.

Kevin

> ---
>  arch/arm/mach-omap2/cpuidle44xx.c |   31 ++++++++++++++++---------------
>  1 file changed, 16 insertions(+), 15 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/cpuidle44xx.c b/arch/arm/mach-omap2/cpuidle44xx.c
> index 767f657..ca1551a 100644
> --- a/arch/arm/mach-omap2/cpuidle44xx.c
> +++ b/arch/arm/mach-omap2/cpuidle44xx.c
> @@ -1,7 +1,7 @@
>  /*
> - * OMAP4 CPU idle Routines
> + * OMAP4+ CPU idle Routines
>   *
> - * Copyright (C) 2011 Texas Instruments, Inc.
> + * Copyright (C) 2011-2013 Texas Instruments, Inc.
>   * Santosh Shilimkar <santosh.shilimkar at ti.com>
>   * Rajendra Nayak <rnayak at ti.com>
>   *
> @@ -24,13 +24,13 @@
>  #include "clockdomain.h"
>  
>  /* Machine specific information */
> -struct omap4_idle_statedata {
> +struct idle_statedata {
>  	u32 cpu_state;
>  	u32 mpu_logic_state;
>  	u32 mpu_state;
>  };
>  
> -static struct omap4_idle_statedata omap4_idle_data[] = {
> +static struct idle_statedata omap4_idle_data[] = {
>  	{
>  		.cpu_state = PWRDM_POWER_ON,
>  		.mpu_state = PWRDM_POWER_ON,
> @@ -53,11 +53,12 @@ static struct clockdomain *cpu_clkdm[NR_CPUS];
>  
>  static atomic_t abort_barrier;
>  static bool cpu_done[NR_CPUS];
> +static struct idle_statedata *state_ptr = &omap4_idle_data[0];
>  
>  /* Private functions */
>  
>  /**
> - * omap4_enter_idle_coupled_[simple/coupled] - OMAP4 cpuidle entry functions
> + * omap_enter_idle_[simple/coupled] - OMAP4PLUS cpuidle entry functions
>   * @dev: cpuidle device
>   * @drv: cpuidle driver
>   * @index: the index of state to be entered
> @@ -66,7 +67,7 @@ static bool cpu_done[NR_CPUS];
>   * specified low power state selected by the governor.
>   * Returns the amount of time spent in the low power state.
>   */
> -static int omap4_enter_idle_simple(struct cpuidle_device *dev,
> +static int omap_enter_idle_simple(struct cpuidle_device *dev,
>  			struct cpuidle_driver *drv,
>  			int index)
>  {
> @@ -74,11 +75,11 @@ static int omap4_enter_idle_simple(struct cpuidle_device *dev,
>  	return index;
>  }
>  
> -static int omap4_enter_idle_coupled(struct cpuidle_device *dev,
> +static int omap_enter_idle_coupled(struct cpuidle_device *dev,
>  			struct cpuidle_driver *drv,
>  			int index)
>  {
> -	struct omap4_idle_statedata *cx = &omap4_idle_data[index];
> +	struct idle_statedata *cx = state_ptr + index;
>  	int cpu_id = smp_processor_id();
>  
>  	/*
> @@ -168,7 +169,7 @@ static void omap_setup_broadcast_timer(void *arg)
>  	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ON, &cpu);
>  }
>  
> -static DEFINE_PER_CPU(struct cpuidle_device, omap4_idle_dev);
> +static DEFINE_PER_CPU(struct cpuidle_device, omap_idle_dev);
>  
>  static struct cpuidle_driver omap4_idle_driver = {
>  	.name				= "omap4_idle",
> @@ -180,7 +181,7 @@ static struct cpuidle_driver omap4_idle_driver = {
>  			.exit_latency = 2 + 2,
>  			.target_residency = 5,
>  			.flags = CPUIDLE_FLAG_TIME_VALID,
> -			.enter = omap4_enter_idle_simple,
> +			.enter = omap_enter_idle_simple,
>  			.name = "C1",
>  			.desc = "CPUx ON, MPUSS ON"
>  		},
> @@ -189,7 +190,7 @@ static struct cpuidle_driver omap4_idle_driver = {
>  			.exit_latency = 328 + 440,
>  			.target_residency = 960,
>  			.flags = CPUIDLE_FLAG_TIME_VALID | CPUIDLE_FLAG_COUPLED,
> -			.enter = omap4_enter_idle_coupled,
> +			.enter = omap_enter_idle_coupled,
>  			.name = "C2",
>  			.desc = "CPUx OFF, MPUSS CSWR",
>  		},
> @@ -198,7 +199,7 @@ static struct cpuidle_driver omap4_idle_driver = {
>  			.exit_latency = 460 + 518,
>  			.target_residency = 1100,
>  			.flags = CPUIDLE_FLAG_TIME_VALID | CPUIDLE_FLAG_COUPLED,
> -			.enter = omap4_enter_idle_coupled,
> +			.enter = omap_enter_idle_coupled,
>  			.name = "C3",
>  			.desc = "CPUx OFF, MPUSS OSWR",
>  		},
> @@ -210,9 +211,9 @@ static struct cpuidle_driver omap4_idle_driver = {
>  /* Public functions */
>  
>  /**
> - * omap4_idle_init - Init routine for OMAP4 idle
> + * omap4_idle_init - Init routine for OMAP4+ idle
>   *
> - * Registers the OMAP4 specific cpuidle driver to the cpuidle
> + * Registers the OMAP4+ specific cpuidle driver to the cpuidle
>   * framework with the valid set of states.
>   */
>  int __init omap4_idle_init(void)
> @@ -240,7 +241,7 @@ int __init omap4_idle_init(void)
>  	}
>  
>  	for_each_cpu(cpu_id, cpu_online_mask) {
> -		dev = &per_cpu(omap4_idle_dev, cpu_id);
> +		dev = &per_cpu(omap_idle_dev, cpu_id);
>  		dev->cpu = cpu_id;
>  #ifdef CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED
>  		dev->coupled_cpus = *cpu_online_mask;


From nicolas.pitre at linaro.org  Fri Apr  5 17:32:18 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Fri, 5 Apr 2013 17:32:18 -0400 (EDT)
Subject: [GIT PULL] Multi Cluster Power Management infrastructure
In-Reply-To: <CAOesGMiN1oEMTjVVOiXs2ynccnvTgFgn=Fy1wGHhsGqL0XUATQ@mail.gmail.com>
References: <alpine.LFD.2.03.1303251219530.1372@syhkavp.arg>
 <alpine.LFD.2.03.1304042138160.1171@syhkavp.arg>
 <20130405094159.GH17995@n2100.arm.linux.org.uk>
 <201304052233.25630.arnd@arndb.de>
 <CAOesGMiN1oEMTjVVOiXs2ynccnvTgFgn=Fy1wGHhsGqL0XUATQ@mail.gmail.com>
Message-ID: <alpine.LFD.2.03.1304051722330.1171@syhkavp.arg>

On Fri, 5 Apr 2013, Olof Johansson wrote:

> Can someone please provide a link or subject for the posted patch
> series for the dependent platform code? I tried to search for it on
> the lists but didn't have much luck.

As mentioned in my cover letter, the dependent platform code for RTSM 
has been publicly posted along with the MCPM patches in all 4 review 
cycles.  Those patches therefore were reviewed all together.  The plan 
was to have the MCPM into mainline during the previous merge window via 
Russell, and the platform code via ARM SoC either during the previous 
cycle time permitting, or this cycle otherwise.

Therefore the MCPM pull request includes only the MCPM patches.  Another 
pull request for the remaining patches is still pending for ARM SoC.

If you want to see all patches together, you may have a look at the 
following branch:

  git://git.linaro.org/people/nico/linux mcpm+dcscb

> I think platform code should wait until 3.11 instead of getting
> crammed in at post-rc6. If it hasn't already been posted by now, it
> should most definitely wait. That also saves on any contentious
> dependency between the two.

It was posted *tree* months ago.  It was reviewed *four* times already.


Nicolas


From tony at atomide.com  Fri Apr  5 17:34:34 2013
From: tony at atomide.com (Tony Lindgren)
Date: Fri, 5 Apr 2013 14:34:34 -0700
Subject: [PATCH v3 2/4] ARM: OMAP4+: PM: Consolidate OMAP4 PM code to
 re-use it for OMAP5
In-Reply-To: <1365166743-5940-3-git-send-email-santosh.shilimkar@ti.com>
References: <1365166743-5940-1-git-send-email-santosh.shilimkar@ti.com>
 <1365166743-5940-3-git-send-email-santosh.shilimkar@ti.com>
Message-ID: <20130405213433.GF10155@atomide.com>

* Santosh Shilimkar <santosh.shilimkar at ti.com> [130405 06:01]:
> OMAP5 has backward compatible PRCM block and it's programming
> model is mostly similar to OMAP4. Same is going to be maintained
> for future OMAP4 based SOCs. Hence consolidate the OMAP4 power
> management code so that it can be re-used on OMAP5 and later devices.
> 
> While at it, update the kernel-doc for omap4_pm_init().
> 
> Acked-by: Nishanth Menon <nm at ti.com>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
> ---
>  arch/arm/mach-omap2/Makefile                       |    9 +--
>  arch/arm/mach-omap2/{pm44xx.c => pm_omap4plus.c}   |   58 ++++++++++++++++----
>  .../mach-omap2/{sleep44xx.S => sleep_omap4plus.S}  |    0
>  3 files changed, 53 insertions(+), 14 deletions(-)
>  rename arch/arm/mach-omap2/{pm44xx.c => pm_omap4plus.c} (83%)
>  rename arch/arm/mach-omap2/{sleep44xx.S => sleep_omap4plus.S} (100%)

I suggest you leave out the rename. That just adds churn and has
flame potential.

Regards,

Tony


From lauraa at codeaurora.org  Fri Apr  5 17:42:51 2013
From: lauraa at codeaurora.org (Laura Abbott)
Date: Fri,  5 Apr 2013 14:42:51 -0700
Subject: [RFC][PATCH] arm: highmem: Add support for flushing kmap_atomic
 mappings
Message-ID: <1365198171-8469-1-git-send-email-lauraa@codeaurora.org>

The highmem code provides kmap_flush_unused to ensure all kmap
mappings are really removed if they are used. This code does not
handle kmap_atomic mappings since they are managed separately.
This prevents an issue for any code which relies on having absolutely
no mappings for a particular page. Rather than pay the penalty of
having CONFIG_DEBUG_HIGHMEM on all the time, add functionality
to remove the kmap_atomic mappings in a similar way to kmap_flush_unused.

This is intended to be an RFC to make sure this approach is
reasonable. The goal is to have kmap_atomic_flush_unused be a public
API.

Signed-off-by: Laura Abbott <lauraa at codeaurora.org>
---
 arch/arm/mm/highmem.c |   51 +++++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 51 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mm/highmem.c b/arch/arm/mm/highmem.c
index 21b9e1b..f4c0466 100644
--- a/arch/arm/mm/highmem.c
+++ b/arch/arm/mm/highmem.c
@@ -10,6 +10,7 @@
  * published by the Free Software Foundation.
  */
 
+#include <linux/cpu.h>
 #include <linux/module.h>
 #include <linux/highmem.h>
 #include <linux/interrupt.h>
@@ -135,3 +136,53 @@ struct page *kmap_atomic_to_page(const void *ptr)
 
 	return pte_page(get_top_pte(vaddr));
 }
+
+static void kmap_remove_unused_cpu(int cpu)
+{
+	int start_idx, idx, type;
+
+	pagefault_disable();
+	type = kmap_atomic_idx();
+	start_idx = type + 1 + KM_TYPE_NR * cpu;
+
+	for (idx = start_idx; idx < KM_TYPE_NR + KM_TYPE_NR * cpu; idx++) {
+		unsigned long vaddr = __fix_to_virt(FIX_KMAP_BEGIN + idx);
+		set_top_pte(vaddr, __pte(0));
+	}
+	pagefault_enable();
+}
+
+static void kmap_remove_unused(void *unused)
+{
+	kmap_remove_unused_cpu(smp_processor_id());
+}
+
+void kmap_atomic_flush_unused(void)
+{
+	on_each_cpu(kmap_remove_unused, NULL, 1);
+}
+
+static int hotplug_kmap_atomic_callback(struct notifier_block *nfb,
+                                unsigned long action, void *hcpu)
+{
+        switch (action & (~CPU_TASKS_FROZEN)) {
+        case CPU_DYING:
+		kmap_remove_unused_cpu((int)hcpu);
+                break;
+        default:
+                break;
+        }
+
+        return NOTIFY_OK;
+}
+
+static struct notifier_block hotplug_kmap_atomic_notifier = {
+        .notifier_call = hotplug_kmap_atomic_callback,
+};
+
+static int __init init_kmap_atomic(void)
+{
+
+        return register_hotcpu_notifier(&hotplug_kmap_atomic_notifier);
+}
+early_initcall(init_kmap_atomic);
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From jgunthorpe at obsidianresearch.com  Fri Apr  5 17:45:10 2013
From: jgunthorpe at obsidianresearch.com (Jason Gunthorpe)
Date: Fri, 5 Apr 2013 15:45:10 -0600
Subject: [PATCH v2 1/5] drivers: memory: Introduce Marvell EBU Device Bus
 driver
In-Reply-To: <1365196320-15084-2-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1365196320-15084-1-git-send-email-ezequiel.garcia@free-electrons.com>
 <1365196320-15084-2-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <20130405214510.GB16221@obsidianresearch.com>

On Fri, Apr 05, 2013 at 06:11:56PM -0300, Ezequiel Garcia wrote:

> +The reg property must specify the chip select as:
> +
> +  0: DEV_BOOTCS
> +  1: DEV_CS0
> +  2: DEV_CS1
> +  3: DEV_CS2
> +  4: DEV_CS3

I look at this and sort of go 'hmm'. These are basically register
offsets into the block starting at 0xd0010400. I don't see any
registers that are shared between targets. It would be simpler to keep
each target as a seperate node and seperate driver instance.

Combining that idea with the suggestion for target-id centric mbus DT
binding:

bootcs at d0010400 {
   compatible = "marvell,armada370-devbus";
   ranges = <0 MAPDEF_BOOTCS 0x1000>
   reg = <MAPDEF_INTERNAL + 0x10400 0x8>;  // boot cs register set
   devbus,dev-width = <1>;
   [..] etc

   rom at 0 {
      reg = <0 0x1000>
   }
}

bus_cs3 at d0010400 {
   compatible = "marvell,armada370-devbus";
   ranges = <0 MAPDEF_BUS_CS3 0x1000>
   reg = <MAPDEF_INTERNAL + 0x10408 0x8>; // cs3 register set
   devbus,dev-width = <1>;
   [..] etc

   device at 0 {
      reg = <0 0x1000>
   }
}

Which follows the usual DT convention that the parent bus sets up
properties that apply to all children.

This isn't a major point, but give it a think :)

> +static void get_timing_param_ps(struct devbus *devbus,
> +				struct device_node *node,
> +				const char *name,
> +				u32 *ticks)
> +{
> +	u32 time_ps;
> +
> +	of_property_read_u32(node, name, &time_ps);
> +
> +	*ticks = (time_ps + devbus->tick_ps - 1) / devbus->tick_ps;
> +
> +	dev_dbg(devbus->dev, "%s: %u ps -> 0x%x\n",
> +		name, time_ps, *ticks);
> +}

It looks like there is a problem here, if the properties are not
present then what value will be in time_ps?

The driver should probably fail to load if any timing parameter is
missing from the DT??

> +	/*
> +	 * We probe NOR/NAND with different functions, because
> +	 * we expect them to have some different parameters.
> +	 * If this turns out not to be the case, we'll be able
> +	 * to use any name for the child, and rename to devbus_probe_child().
> +	 */

This statement seems confusing, all this driver does is set
READ_PARAM_OFFSET/WRITE_PARAM_OFFSET - are there other NAND specific
registers? What NOR/NAND difference do you imagine?

I gave it all a quick look over and it looks broadly OK to me
otherwise.

Regards,
Jason


From ezequiel.garcia at free-electrons.com  Fri Apr  5 18:09:13 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Fri, 5 Apr 2013 19:09:13 -0300
Subject: [PATCH v2 1/5] drivers: memory: Introduce Marvell EBU Device Bus
 driver
In-Reply-To: <20130405214510.GB16221@obsidianresearch.com>
References: <1365196320-15084-1-git-send-email-ezequiel.garcia@free-electrons.com>
 <1365196320-15084-2-git-send-email-ezequiel.garcia@free-electrons.com>
 <20130405214510.GB16221@obsidianresearch.com>
Message-ID: <20130405220912.GA15162@localhost>

Hi Jason,

Thanks for the review.

On Fri, Apr 05, 2013 at 03:45:10PM -0600, Jason Gunthorpe wrote:
> On Fri, Apr 05, 2013 at 06:11:56PM -0300, Ezequiel Garcia wrote:
> 
> > +The reg property must specify the chip select as:
> > +
> > +  0: DEV_BOOTCS
> > +  1: DEV_CS0
> > +  2: DEV_CS1
> > +  3: DEV_CS2
> > +  4: DEV_CS3
> 
> I look at this and sort of go 'hmm'. These are basically register
> offsets into the block starting at 0xd0010400. I don't see any
> registers that are shared between targets. It would be simpler to keep
> each target as a seperate node and seperate driver instance.
> 

Mmm.. sounds sensible.

> Combining that idea with the suggestion for target-id centric mbus DT
> binding:
> 
> bootcs at d0010400 {
>    compatible = "marvell,armada370-devbus";
>    ranges = <0 MAPDEF_BOOTCS 0x1000>
>    reg = <MAPDEF_INTERNAL + 0x10400 0x8>;  // boot cs register set
>    devbus,dev-width = <1>;
>    [..] etc
> 
>    rom at 0 {
>       reg = <0 0x1000>
>    }
> }
> 
> bus_cs3 at d0010400 {
>    compatible = "marvell,armada370-devbus";
>    ranges = <0 MAPDEF_BUS_CS3 0x1000>
>    reg = <MAPDEF_INTERNAL + 0x10408 0x8>; // cs3 register set
>    devbus,dev-width = <1>;
>    [..] etc
> 
>    device at 0 {
>       reg = <0 0x1000>
>    }
> }
> 
> Which follows the usual DT convention that the parent bus sets up
> properties that apply to all children.
> 
> This isn't a major point, but give it a think :)
> 

Okey, I will.

> > +static void get_timing_param_ps(struct devbus *devbus,
> > +				struct device_node *node,
> > +				const char *name,
> > +				u32 *ticks)
> > +{
> > +	u32 time_ps;
> > +
> > +	of_property_read_u32(node, name, &time_ps);
> > +
> > +	*ticks = (time_ps + devbus->tick_ps - 1) / devbus->tick_ps;
> > +
> > +	dev_dbg(devbus->dev, "%s: %u ps -> 0x%x\n",
> > +		name, time_ps, *ticks);
> > +}
> 
> It looks like there is a problem here, if the properties are not
> present then what value will be in time_ps?
> 
> The driver should probably fail to load if any timing parameter is
> missing from the DT??
> 

Of course, I knew I was forgeting something. We should at least
zero every timing parameter by default.

I'll fix this in a soon to come v3.

Do you think it's also important/necessary to fail if *any*
parameter is missing? I guess it makes sense if we are making
these parameters mandatory.

> > +	/*
> > +	 * We probe NOR/NAND with different functions, because
> > +	 * we expect them to have some different parameters.
> > +	 * If this turns out not to be the case, we'll be able
> > +	 * to use any name for the child, and rename to devbus_probe_child().
> > +	 */
> 
> This statement seems confusing, all this driver does is set
> READ_PARAM_OFFSET/WRITE_PARAM_OFFSET - are there other NAND specific
> registers? What NOR/NAND difference do you imagine?
> 

Yes, you're probably right. Let me fix that too.

> I gave it all a quick look over and it looks broadly OK to me
> otherwise.
> 

Great, thanks!

-- 
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com


From tomasz.figa at gmail.com  Fri Apr  5 18:24:18 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Sat, 06 Apr 2013 00:24:18 +0200
Subject: [PATCH v4 04/14] mfd: Add Samsung PWM/timer master driver
In-Reply-To: <201304052154.21361.arnd@arndb.de>
References: <1365093431-30621-1-git-send-email-t.figa@samsung.com>
 <19231120.yHlZtTPUMd@amdc1227> <201304052154.21361.arnd@arndb.de>
Message-ID: <2359597.ofbj7Kvioz@flatron>

On Friday 05 of April 2013 21:54:21 Arnd Bergmann wrote:
> On Friday 05 April 2013, Tomasz Figa wrote:
> > > I don't think anyone ever suggested using a private API though.
> > 
> > I must have gotten the last paragraph of
> > http://article.gmane.org/gmane.linux.kernel.samsung-soc/16638
> > wrong then. For me it seemed like the timer driver would expose a
> > private API to the PWM driver.
> 
> Yes, sorry I wasn't clear enough. I meant a register-level interface
> exposed from the base driver, not a high-level interface like you
> did.

I'm not sure what you mean by a register-level interface. Something like 
samsung_pwm_update_reg(reg, mask, val), which modifies bitfields according 
to the mask and value with appropriate synchronization? If yes, this 
solves only the problem of access to shared registers.

The other problems that remain:

- negotiation of PWM channels to use for clock source and clock events,
  because each board can use different channels for PWM outputs,

- code duplication caused by both of the drivers doing mostly the same
  things and or having to parse the same data from device tree,

- both non-DT and DT platforms must be supported,

- how to keep the ability to load PWM driver as a module (or not load it
  at all when PWM is not used on particular board), while retaining
  everything that is needed for the clocksource driver in kernel,

- some platforms can't use PWM timers as system clocksources, while on
  others this is the only timekeeping hardware available.

> > > I think
> > > it's ok if the driver lives in drivers/mfd when it doesn't fit
> > > anywhere
> > > else easily, but you should really register it to the pwm subsystem
> > > to
> > > expose that functionality, not export functions that can be used by
> > > a pwm shim driver, which even seems to be missing from the series.
> > 
> > Anyway, using PWM API in a clocksource driver that needs to be running
> > very early (before any initcalls get called) seems a bit weird for
> > me, especially when PWM API doesn't provide such fine grained control
> > over PWM timers that is required in the clocksource drivers.
> 
> Exactly, that's why you should have a regular PWM driver that gets
> loaded at a convenient time and just uses an interface exported by the
> base driver to access the common registers.

Well, this is basically what my patches do, except that the PWM driver 
isn't reworked to use the base driver yet.

The private API exported to the samsung-time and pwm-samsung drivers isn't 
maybe the most fortunate one, but it clearly has the advantage of solving 
all the problems I mentioned before.

Same goes for calling this an MFD driver. It doesn't even use the MFD 
core, but there seems to be no better place to put it. Maybe 
drivers/platform/arm would be better, if it existed, just as currently 
available drivers/platform/x86?

Best regards,
Tomasz



From sergei.shtylyov at cogentembedded.com  Fri Apr  5 18:35:34 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Sat, 06 Apr 2013 02:35:34 +0400
Subject: [PATCH 0/8] Reorganize R8A7779/Marzen USB code
In-Reply-To: <515EFE6D.4020006@cogentembedded.com>
References: <201304050251.44464.sergei.shtylyov@cogentembedded.com>
 <87vc81ka6k.wl%kuninori.morimoto.gx@renesas.com>
 <515EFE6D.4020006@cogentembedded.com>
Message-ID: <515F51B6.5000302@cogentembedded.com>

Hello.

On 04/05/2013 08:40 PM, Sergei Shtylyov wrote:

>
>>>     Here's the set of 4 patches against the Simon Horman's 
>>> 'renesas.git' repo,
>>> 'renesas-next-20130404v2' tag and the 2 Ether patches I've reposted 
>>> yesterday.
>>> It was created to fix the shortcomings in the R8A7779/Marzen USB 
>>> platform code
>>> and R8A7779 USB common PHY driver, and so spans both 
>>> arch/arm/mach-shmobile/
>>> and drivers/usb/ subtrees (some patches have to touch both subtrees).
>>> The patches were conceived with the complete bisectability goal in 
>>> mind.
>
>>> [1/8] ARM: shmobile:Marzen: move USB EHCI, OHCI, and PHY devices to 
>>> R8A7779 code
>>> [2/8] ehci-platform: add init() method to platform data
>>> [3/8] ARM: shmobile: R8A7779: setup EHCI internal buffer
>>> [4/8] rcar-phy: remove EHCI internal buffer setup
>>> [5/8] rcar-phy: correct base address
>>> [6/8] rcar-phy: add platform data
>>> [7/8] ARM: shmobile: Marzen: pass platform data to USB PHY device
>>> [8/8] rcar-phy: handle platform data
>
>>>     I'm not sure thru which tree this patchset should be merged, 
>>> however it turns
>>> out that it's too late now to push it thru Felipe Balbi's USB tree 
>>> for 3.10, so
>>> maybe the patchset can be merged thru Simon's tree with Felipe's and 
>>> Alan
>>> Stern's ACKs.
>
>> I guess you already got request about patch style from Simon.
>
>    It's not about style. I tried to keep the series copmpletely 
> bisectable, and granting almost all requests about splitting the 
> patches would have broken the bisection.
>
>> When you send v2 patch, could you please add "this patch is tested on 
>> xxxx bard"
>> on each patch's comment area ?
>
>    I'm not sure it's worth doing v2, although in one place I can 
> indeed readily split the patch. All patches were tested on the Marzen 
> board, I forgot to mention that in the cover letter.

    Well, there's gonna be version 2 now, mainly because Alan Stern 
wasn't content with the patch #2.

WBR, Sergei



From olof at lixom.net  Fri Apr  5 18:43:48 2013
From: olof at lixom.net (Olof Johansson)
Date: Fri, 5 Apr 2013 15:43:48 -0700
Subject: [PATCH v4 14/15] ARM: Enable selection of SMP operations at boot
 time
In-Reply-To: <1360041732-17936-15-git-send-email-nicolas.pitre@linaro.org>
References: <1360041732-17936-1-git-send-email-nicolas.pitre@linaro.org>
 <1360041732-17936-15-git-send-email-nicolas.pitre@linaro.org>
Message-ID: <20130405224348.GA14308@quad.lixom.net>

On Tue, Feb 05, 2013 at 12:22:11AM -0500, Nicolas Pitre wrote:
> From: Jon Medhurst <tixy at linaro.org>
> 
> Add a new 'smp_init' hook to machine_desc so platforms can specify a
> function to be used to setup smp ops instead of having a statically
> defined value.
> 
> Signed-off-by: Jon Medhurst <tixy at linaro.org>
> Signed-off-by: Nicolas Pitre <nicolas.pitre at linaro.org>
> Reviewed-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
> ---
>  arch/arm/include/asm/mach/arch.h | 3 +++
>  arch/arm/kernel/setup.c          | 5 ++++-
>  2 files changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/include/asm/mach/arch.h b/arch/arm/include/asm/mach/arch.h
> index 917d4fcfd9..3d01c6d6c3 100644
> --- a/arch/arm/include/asm/mach/arch.h
> +++ b/arch/arm/include/asm/mach/arch.h
> @@ -17,8 +17,10 @@ struct pt_regs;
>  struct smp_operations;
>  #ifdef CONFIG_SMP
>  #define smp_ops(ops) (&(ops))
> +#define smp_init_ops(ops) (&(ops))
>  #else
>  #define smp_ops(ops) (struct smp_operations *)NULL
> +#define smp_init_ops(ops) (void (*)(void))NULL
>  #endif
>  
>  struct machine_desc {
> @@ -42,6 +44,7 @@ struct machine_desc {
>  	unsigned char		reserve_lp2 :1;	/* never has lp2	*/
>  	char			restart_mode;	/* default restart mode	*/
>  	struct smp_operations	*smp;		/* SMP operations	*/
> +	void			(*smp_init)(void);
>  	void			(*fixup)(struct tag *, char **,
>  					 struct meminfo *);
>  	void			(*reserve)(void);/* reserve mem blocks	*/
> diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> index 3f6cbb2e3e..41edca8582 100644
> --- a/arch/arm/kernel/setup.c
> +++ b/arch/arm/kernel/setup.c
> @@ -768,7 +768,10 @@ void __init setup_arch(char **cmdline_p)
>  	arm_dt_init_cpu_maps();
>  #ifdef CONFIG_SMP
>  	if (is_smp()) {
> -		smp_set_ops(mdesc->smp);
> +		if(mdesc->smp_init)

This will fail checkpatch: if() instead of if ().

> +			(*mdesc->smp_init)();

This is different calling style than init_early() below, which uses
mdesc->init_early(). Please be consistent.

> +		else
> +			smp_set_ops(mdesc->smp);


-Olof


From olof at lixom.net  Fri Apr  5 18:48:19 2013
From: olof at lixom.net (Olof Johansson)
Date: Fri, 5 Apr 2013 15:48:19 -0700
Subject: [PATCH v4 15/15] ARM: vexpress: Select multi-cluster SMP
 operation if required
In-Reply-To: <1360041732-17936-16-git-send-email-nicolas.pitre@linaro.org>
References: <1360041732-17936-1-git-send-email-nicolas.pitre@linaro.org>
 <1360041732-17936-16-git-send-email-nicolas.pitre@linaro.org>
Message-ID: <20130405224819.GB14308@quad.lixom.net>

On Tue, Feb 05, 2013 at 12:22:12AM -0500, Nicolas Pitre wrote:
> From: Jon Medhurst <tixy at linaro.org>
> 
> Signed-off-by: Jon Medhurst <tixy at linaro.org>
> Signed-off-by: Nicolas Pitre <nicolas.pitre at linaro.org>
> Reviewed-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
> ---
>  arch/arm/mach-vexpress/core.h    |  2 ++
>  arch/arm/mach-vexpress/platsmp.c | 12 ++++++++++++
>  arch/arm/mach-vexpress/v2m.c     |  2 +-
>  3 files changed, 15 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-vexpress/core.h b/arch/arm/mach-vexpress/core.h
> index f134cd4a85..3a761fd76c 100644
> --- a/arch/arm/mach-vexpress/core.h
> +++ b/arch/arm/mach-vexpress/core.h
> @@ -6,6 +6,8 @@
>  
>  void vexpress_dt_smp_map_io(void);
>  
> +void vexpress_smp_init_ops(void);
> +
>  extern struct smp_operations	vexpress_smp_ops;
>  
>  extern void vexpress_cpu_die(unsigned int cpu);
> diff --git a/arch/arm/mach-vexpress/platsmp.c b/arch/arm/mach-vexpress/platsmp.c
> index c5d70de9bb..667344b479 100644
> --- a/arch/arm/mach-vexpress/platsmp.c
> +++ b/arch/arm/mach-vexpress/platsmp.c
> @@ -12,6 +12,7 @@
>  #include <linux/errno.h>
>  #include <linux/smp.h>
>  #include <linux/io.h>
> +#include <linux/of.h>
>  #include <linux/of_fdt.h>
>  #include <linux/vexpress.h>
>  
> @@ -206,3 +207,14 @@ struct smp_operations __initdata vexpress_smp_ops = {
>  	.cpu_die		= vexpress_cpu_die,
>  #endif
>  };
> +
> +void __init vexpress_smp_init_ops(void)
> +{
> +	struct smp_operations *ops = &vexpress_smp_ops;
> +#ifdef CONFIG_CLUSTER_PM
> +	extern struct smp_operations mcpm_smp_ops;

Seems appropriate to put this prototype in a header file instead.

> +	if(of_find_compatible_node(NULL, NULL, "arm,cci"))

Another checkpatch error on if() whitespace.

Also, while bindings haven't been ironed out, checking for whether the
node/device is enabled or disabled could be appropriate here?

> +		ops = &mcpm_smp_ops;
> +#endif
> +	smp_set_ops(ops);
> +}
> diff --git a/arch/arm/mach-vexpress/v2m.c b/arch/arm/mach-vexpress/v2m.c
> index 011661a6c5..34172bd504 100644
> --- a/arch/arm/mach-vexpress/v2m.c
> +++ b/arch/arm/mach-vexpress/v2m.c
> @@ -494,7 +494,7 @@ static const char * const v2m_dt_match[] __initconst = {
>  
>  DT_MACHINE_START(VEXPRESS_DT, "ARM-Versatile Express")
>  	.dt_compat	= v2m_dt_match,
> -	.smp		= smp_ops(vexpress_smp_ops),
> +	.smp_init	= smp_init_ops(vexpress_smp_init_ops),
>  	.map_io		= v2m_dt_map_io,
>  	.init_early	= v2m_dt_init_early,
>  	.init_irq	= v2m_dt_init_irq,


-Olof


From tomasz.figa at gmail.com  Fri Apr  5 18:57:04 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Sat, 06 Apr 2013 00:57:04 +0200
Subject: [PATCH v4 00/14] ARM: samsung-time: Prepare for multiplatform
 support
In-Reply-To: <1365093431-30621-1-git-send-email-t.figa@samsung.com>
References: <1365093431-30621-1-git-send-email-t.figa@samsung.com>
Message-ID: <3831330.gb4oupANR9@flatron>

On Thursday 04 of April 2013 18:36:57 Tomasz Figa wrote:
> This series is an attempt to make the samsung-time clocksource driver
> ready for multiplatform kernels. It moves the driver to
> drivers/clocksource, cleans it up from uses of static platform-specific
> definitions, simplifies timer interrupt handling and adds Device Tree
> support.
> 
> Only samsung-time driver is reworked to use the master driver at this
> time, since the PWM driver can be already considered broken at the
> moment and needs separate series of several patches to fix and clean it
> up, which I am already working on.
> 
> Tested on Universal C210 board with Device Tree. Not tested without
> Device Tree, since it has been already broken before this series.
> Compile tested for other related SoCs.
> 
> Changes since v3:
> (http://thread.gmane.org/gmane.linux.kernel.samsung-soc/16664/)
>  - Changed the design to use common (master) driver for operations that
>    can be done from both clocksource and PWM drivers (as suggested by
>    Arnd Bergmann) - needed to properly synchronize access to PWM
> registers - Moved handling of PWM prescaler and divider to master
> driver
> 
> Changes since v2:
> (http://thread.gmane.org/gmane.linux.kernel.samsung-soc/16158)
>  - Addressed comments from Rob Herring and Mark Rutland
>  - Removed unused register definitions
>  - Replaced samsung,source-timer and samsung,event-timer properties
>    with samsung,pwm-outputs property that defines which PWM channels
>    are reserved for PWM outputs on particular platform
>  - Split non-DT and DT initialization into two functions
>  - Fixed a copy paste error
> 
> Changes since v1:
> (http://thread.gmane.org/gmane.linux.kernel.samsung-soc/16005)
>  - Addressed comments from Mark Rutland
>  - Documented struct samsung_timer_variant
>  - Dropped inactive mail addresses from CC
> 
> Tomasz Figa (14):
>   ARM: SAMSUNG: Move samsung-time to drivers/clocksource
>   clocksource: samsung-time: Drop useless defines from public header
>   clocksource: samsung-time: Use local register definitions
>   mfd: Add Samsung PWM/timer master driver
>   ARM: SAMSUNG: Unify base address definitions of timer block
>   ARM: SAMSUNG: Add new PWM platform device
>   ARM: SAMSUNG: Set PWM platform data
>   clocksource: samsung-time: Use Samsung PWM/timer master driver
>   clocksource: samsung-time: Use variant data to get SoC-specific bits
>   clocksource: samsung-time: Use master driver to configure dividers
>   clocksource: samsung-time: Use clk_prepare_enable
>   clocksource: samsung-time: Use master driver to control PWM channels
>   clocksource: samsung-time: Move IRQ mask/ack handling to the driver
>   ARM: SAMSUNG: Remove unused PWM timer IRQ chip code

On FriendlyARM's Tiny6410 board (Mini6410-compatible), both with (using my 
patches adding S3C64xx Device Tree and pinctrl support) and without Device 
Tree:

Tested-by: Tomasz Figa <tomasz.figa at gmail.com>

Best regards,
Tomasz



From olof at lixom.net  Fri Apr  5 19:00:17 2013
From: olof at lixom.net (Olof Johansson)
Date: Fri, 5 Apr 2013 16:00:17 -0700
Subject: [PATCH v4 03/15] ARM: mcpm: introduce helpers for platform
 coherency exit/setup
In-Reply-To: <1360041732-17936-4-git-send-email-nicolas.pitre@linaro.org>
References: <1360041732-17936-1-git-send-email-nicolas.pitre@linaro.org>
 <1360041732-17936-4-git-send-email-nicolas.pitre@linaro.org>
Message-ID: <20130405230017.GC14308@quad.lixom.net>

Hi,

Just two nits below. One could be fixed incrementally, the other is
a longer-term potential cleanup.

On Tue, Feb 05, 2013 at 12:22:00AM -0500, Nicolas Pitre wrote:

> diff --git a/arch/arm/include/asm/mcpm_entry.h b/arch/arm/include/asm/mcpm_entry.h
> index 3286d5eb91..e76652209d 100644
> --- a/arch/arm/include/asm/mcpm_entry.h
> +++ b/arch/arm/include/asm/mcpm_entry.h
> @@ -15,8 +15,37 @@
>  #define MAX_CPUS_PER_CLUSTER	4
>  #define MAX_NR_CLUSTERS		2
>  
> +/* Definitions for mcpm_sync_struct */
> +#define CPU_DOWN		0x11
> +#define CPU_COMING_UP		0x12
> +#define CPU_UP			0x13
> +#define CPU_GOING_DOWN		0x14
> +
> +#define CLUSTER_DOWN		0x21
> +#define CLUSTER_UP		0x22
> +#define CLUSTER_GOING_DOWN	0x23
> +
> +#define INBOUND_NOT_COMING_UP	0x31
> +#define INBOUND_COMING_UP	0x32
> +
> +/* This is a complete guess. */
> +#define __CACHE_WRITEBACK_ORDER	6
> +#define __CACHE_WRITEBACK_GRANULE (1 << __CACHE_WRITEBACK_ORDER)

Something a little more educational could be useful here. It needs to
be the max writeback/line size of the supported platforms of the binary
kernel, i.e. if someone builds an SoC with 128-byte L2 cache lines this
guess will break.

> +/* Offsets for the mcpm_sync_struct members, for use in asm: */
> +#define MCPM_SYNC_CLUSTER_CPUS	0
> +#define MCPM_SYNC_CPU_SIZE	__CACHE_WRITEBACK_GRANULE
> +#define MCPM_SYNC_CLUSTER_CLUSTER \
> +	(MCPM_SYNC_CLUSTER_CPUS + MCPM_SYNC_CPU_SIZE * MAX_CPUS_PER_CLUSTER)
> +#define MCPM_SYNC_CLUSTER_INBOUND \
> +	(MCPM_SYNC_CLUSTER_CLUSTER + __CACHE_WRITEBACK_GRANULE)
> +#define MCPM_SYNC_CLUSTER_SIZE \
> +	(MCPM_SYNC_CLUSTER_INBOUND + __CACHE_WRITEBACK_GRANULE)
> +
>  #ifndef __ASSEMBLY__
>  
> +#include <linux/types.h>
> +
>  /*
>   * Platform specific code should use this symbol to set up secondary
>   * entry location for processors to use when released from reset.
> @@ -123,5 +152,39 @@ struct mcpm_platform_ops {
>   */
>  int __init mcpm_platform_register(const struct mcpm_platform_ops *ops);
>  
> +/* Synchronisation structures for coordinating safe cluster setup/teardown: */
> +
> +/*
> + * When modifying this structure, make sure you update the MCPM_SYNC_ defines
> + * to match.
> + */

It would be nice to introduce something like arch/powerpc/kernel/asm-offsets.c
on ARM to generate the ASM-side automatically from the C struct instead for
this and other cases, but that's unrelated to this addition.

> +struct mcpm_sync_struct {
> +	/* individual CPU states */
> +	struct {
> +		volatile s8 cpu __aligned(__CACHE_WRITEBACK_GRANULE);
> +	} cpus[MAX_CPUS_PER_CLUSTER];
> +
> +	/* cluster state */
> +	volatile s8 cluster __aligned(__CACHE_WRITEBACK_GRANULE);
> +
> +	/* inbound-side state */
> +	volatile s8 inbound __aligned(__CACHE_WRITEBACK_GRANULE);
> +};


-Olof


From stefano.stabellini at eu.citrix.com  Fri Apr  5 19:15:45 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Sat, 6 Apr 2013 00:15:45 +0100
Subject: [PATCH v6 4/4] xen/arm: introduce xen_early_init, use PSCI on xen
In-Reply-To: <515F392B.1030200@gmail.com>
References: <alpine.DEB.2.02.1304031239550.5078@kaball.uk.xensource.com>
 <1365167495-18508-4-git-send-email-stefano.stabellini@eu.citrix.com>
 <alpine.LFD.2.03.1304051217560.1171@syhkavp.arg>
 <alpine.DEB.2.02.1304051725580.21065@kaball.uk.xensource.com>
 <alpine.LFD.2.03.1304051324190.1171@syhkavp.arg> <515F392B.1030200@gmail.com>
Message-ID: <alpine.DEB.2.02.1304060015150.5353@kaball.uk.xensource.com>

On Fri, 5 Apr 2013, Rob Herring wrote:
> On 04/05/2013 02:36 PM, Nicolas Pitre wrote:
> > On Fri, 5 Apr 2013, Stefano Stabellini wrote:
> > 
> >> This is what happens:
> >>
> >> - No Xen
> >> Xen is not running on the platform and a Xen hypervisor node is not
> >> available on device tree.
> >> Everything keeps working seamlessly, this patch doesn't change anything.
> >>
> >> - we are running on Xen
> >> Xen is running on the platform, we are running as a guest on Xen and an
> >> hypervisor node is available on device tree.
> >> Let's also assume that there aren't any "arm,cci" compatible nodes on
> >> device tree because Xen wouldn't export this kind of information to any
> >> guests right now. Therefore PSCI should be used to boot secondary cpus.
> >> Because the versatile express machine sets smp_init to
> >> vexpress_smp_init_ops, vexpress_smp_init_ops will be called.
> >> vexpress_smp_init_ops sets smp_ops to vexpress_smp_ops, that *break*
> >> Xen.
> > 
> > OK I see.
> > 
> >> With this patch, xen_smp_init will be called instead of
> >> vexpress_smp_init_ops, and smp_ops will be set to psci_smp_ops,
> >> therefore *unbreaking* Xen.
> > 
> > However that breaks MCPM.
> 
> You mean on bare metal, right? For the bare metal, "xen,xen" property
> would not be present and xen_smp_init is not used. So the vexpress MCPM
> ops will be used.

That is correct.


> Aren't Dom0 cpu's basically virtual cpus? If Xen ever
> needs the MCPM support, the Xen hook itself can figure out whether to
> use MCPM support.

Right.


From stefano.stabellini at eu.citrix.com  Fri Apr  5 19:20:58 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Sat, 6 Apr 2013 00:20:58 +0100
Subject: [PATCH v6 4/4] xen/arm: introduce xen_early_init, use PSCI on xen
In-Reply-To: <alpine.LFD.2.03.1304051718020.1171@syhkavp.arg>
References: <alpine.DEB.2.02.1304031239550.5078@kaball.uk.xensource.com>
 <1365167495-18508-4-git-send-email-stefano.stabellini@eu.citrix.com>
 <alpine.LFD.2.03.1304051217560.1171@syhkavp.arg>
 <alpine.DEB.2.02.1304051725580.21065@kaball.uk.xensource.com>
 <alpine.LFD.2.03.1304051324190.1171@syhkavp.arg> <515F392B.1030200@gmail.com>
 <alpine.LFD.2.03.1304051718020.1171@syhkavp.arg>
Message-ID: <alpine.DEB.2.02.1304060015490.5353@kaball.uk.xensource.com>

On Fri, 5 Apr 2013, Nicolas Pitre wrote:
> On Fri, 5 Apr 2013, Rob Herring wrote:
> 
> > On 04/05/2013 02:36 PM, Nicolas Pitre wrote:
> > > On Fri, 5 Apr 2013, Stefano Stabellini wrote:
> > > 
> > >> This is what happens:
> > >>
> > >> - No Xen
> > >> Xen is not running on the platform and a Xen hypervisor node is not
> > >> available on device tree.
> > >> Everything keeps working seamlessly, this patch doesn't change anything.
> > >>
> > >> - we are running on Xen
> > >> Xen is running on the platform, we are running as a guest on Xen and an
> > >> hypervisor node is available on device tree.
> > >> Let's also assume that there aren't any "arm,cci" compatible nodes on
> > >> device tree because Xen wouldn't export this kind of information to any
> > >> guests right now. Therefore PSCI should be used to boot secondary cpus.
> > >> Because the versatile express machine sets smp_init to
> > >> vexpress_smp_init_ops, vexpress_smp_init_ops will be called.
> > >> vexpress_smp_init_ops sets smp_ops to vexpress_smp_ops, that *break*
> > >> Xen.
> > > 
> > > OK I see.
> > > 
> > >> With this patch, xen_smp_init will be called instead of
> > >> vexpress_smp_init_ops, and smp_ops will be set to psci_smp_ops,
> > >> therefore *unbreaking* Xen.
> > > 
> > > However that breaks MCPM.
> > 
> > You mean on bare metal, right? For the bare metal, "xen,xen" property
> > would not be present and xen_smp_init is not used. So the vexpress MCPM
> > ops will be used. Aren't Dom0 cpu's basically virtual cpus? If Xen ever
> > needs the MCPM support, the Xen hook itself can figure out whether to
> > use MCPM support.
> 
> Well, if Xen has its own mdesc distinct from the VExpress one then 
> things
> are indeed fine.

It's not about the mdesc: Xen has its own hypervisor node on device tree
if and only if Xen is running on the platform, therefore the Xen early
hook is never going to do anything at all on native.

In other words, this patch should NOT change the behaviour of Linux on
native, and if it did, it would be a bug.


From khilman at linaro.org  Fri Apr  5 19:42:41 2013
From: khilman at linaro.org (Kevin Hilman)
Date: Fri, 05 Apr 2013 16:42:41 -0700
Subject: [PATCH v3 0/4] ARM: OMAP4+: PM: Consolidate code for re-use on
 OMAP5
In-Reply-To: <1365166743-5940-1-git-send-email-santosh.shilimkar@ti.com>
 (Santosh Shilimkar's message of "Fri, 5 Apr 2013 18:28:59 +0530")
References: <1365166743-5940-1-git-send-email-santosh.shilimkar@ti.com>
Message-ID: <87mwtck0i6.fsf@linaro.org>

Santosh Shilimkar <santosh.shilimkar at ti.com> writes:

> As discussed on list, I split the v2 [1] series into cleanup and OMAP5 support.

Thanks.

> This series contains the clean-up patches. I have rebased on top of Tony's
> pull request and your 3.10/* branches. Series is tested on OMAP4430 SDP
> with CPUIDLE and suspend. OMAP5 PM support I will post later since it has
> a dependency with OMAP5 data files which are not pulled in yet.

I've added 4/4 to my cpuidle branch and added 1,3/4 to my
for_3.10/cleanup/pm branch (now based on Tony's cleanup-v2 branch for
dependencies.)   Patch 2/4 needs a respin without the rename as per
Tony's comments.

Thanks,

Kevin


From khilman at linaro.org  Fri Apr  5 20:10:14 2013
From: khilman at linaro.org (Kevin Hilman)
Date: Fri, 05 Apr 2013 17:10:14 -0700
Subject: [GIT PULL] OMAP: PM: fixes for v3.10
Message-ID: <87hajkjz89.fsf@linaro.org>

Tony,

This OMAP PM fixes tag is based on your cleanup-v2 branch due to some
dependencies in the series from Santosh you already merged.

Kevin


The following changes since commit c309f7f46167e85d1aae2fd31f23e7d2b5cdfbe0:

  Merge branch 'for_3.10/omap_generic_cleanup_v2' of git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux into omap-for-v3.10/cleanup-v2 (2013-03-28 14:45:31 -0700)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git tags/omap-pm-v3.10/fixes/pm

for you to fetch changes up to b7806dc7cba840ea538706621486475d93a53c55:

  ARM: OMAP4+: PM: Restore CPU power state to ON with clockdomain force wakeup method (2013-04-05 14:19:25 -0700)

----------------------------------------------------------------
OMAP PM fixes for v3.10

----------------------------------------------------------------
Santosh Shilimkar (1):
      ARM: OMAP4+: PM: Restore CPU power state to ON with clockdomain force wakeup method

 arch/arm/mach-omap2/cpuidle44xx.c |  1 +
 arch/arm/mach-omap2/omap-smp.c    | 12 ++++++++++--
 2 files changed, 11 insertions(+), 2 deletions(-)


From khilman at linaro.org  Fri Apr  5 20:13:02 2013
From: khilman at linaro.org (Kevin Hilman)
Date: Fri, 05 Apr 2013 17:13:02 -0700
Subject: [GIT PULL] OMAP: PM: cpuidle cleanups for v3.10
Message-ID: <874nfkjz3l.fsf@linaro.org>

Tony,

Please pull the following changes for OMAP CPUidle for v3.10.

Kevin


The following changes since commit 07961ac7c0ee8b546658717034fe692fd12eefa9:

  Linux 3.9-rc5 (2013-03-31 15:12:43 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git tags/omap-pm-v3.10/cleanup/cpuidle

for you to fetch changes up to 2507386b7c01e3b0f6967d12c72467bf3f66c77e:

  ARM: OMAP4+: CPUidle: Consolidate idle driver for OMAP5 support (2013-04-05 13:37:33 -0700)

----------------------------------------------------------------
OMAP3/4 CPUidle cleanups for v3.10

----------------------------------------------------------------
Daniel Lezcano (1):
      ARM: omap3: cpuidle: enable time keeping

Santosh Shilimkar (5):
      ARM: OMAP4: CPUidle: Avoid double idle driver registration
      ARM: OMAP: CPUidle: Unregister drivere on device registration failure
      ARM: OMAP4: CPUidle: Make C-state description field more precise
      ARM: OMAP4+: CPUidle: Deprecate use of omap4_mpuss_read_prev_context_state()
      ARM: OMAP4+: CPUidle: Consolidate idle driver for OMAP5 support

 arch/arm/mach-omap2/common.h              |  5 ----
 arch/arm/mach-omap2/cpuidle34xx.c         | 11 +++++--
 arch/arm/mach-omap2/cpuidle44xx.c         | 48 +++++++++++++++++--------------
 arch/arm/mach-omap2/omap-mpuss-lowpower.c | 14 ---------
 4 files changed, 35 insertions(+), 43 deletions(-)


From nicolas.pitre at linaro.org  Fri Apr  5 20:15:51 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Fri, 5 Apr 2013 20:15:51 -0400 (EDT)
Subject: [PATCH v6 4/4] xen/arm: introduce xen_early_init, use PSCI on xen
In-Reply-To: <alpine.DEB.2.02.1304060015490.5353@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1304031239550.5078@kaball.uk.xensource.com>
 <1365167495-18508-4-git-send-email-stefano.stabellini@eu.citrix.com>
 <alpine.LFD.2.03.1304051217560.1171@syhkavp.arg>
 <alpine.DEB.2.02.1304051725580.21065@kaball.uk.xensource.com>
 <alpine.LFD.2.03.1304051324190.1171@syhkavp.arg> <515F392B.1030200@gmail.com>
 <alpine.LFD.2.03.1304051718020.1171@syhkavp.arg>
 <alpine.DEB.2.02.1304060015490.5353@kaball.uk.xensource.com>
Message-ID: <alpine.LFD.2.03.1304052015050.1171@syhkavp.arg>

On Sat, 6 Apr 2013, Stefano Stabellini wrote:

> On Fri, 5 Apr 2013, Nicolas Pitre wrote:
> > On Fri, 5 Apr 2013, Rob Herring wrote:
> > 
> > > On 04/05/2013 02:36 PM, Nicolas Pitre wrote:
> > > > On Fri, 5 Apr 2013, Stefano Stabellini wrote:
> > > > 
> > > >> This is what happens:
> > > >>
> > > >> - No Xen
> > > >> Xen is not running on the platform and a Xen hypervisor node is not
> > > >> available on device tree.
> > > >> Everything keeps working seamlessly, this patch doesn't change anything.
> > > >>
> > > >> - we are running on Xen
> > > >> Xen is running on the platform, we are running as a guest on Xen and an
> > > >> hypervisor node is available on device tree.
> > > >> Let's also assume that there aren't any "arm,cci" compatible nodes on
> > > >> device tree because Xen wouldn't export this kind of information to any
> > > >> guests right now. Therefore PSCI should be used to boot secondary cpus.
> > > >> Because the versatile express machine sets smp_init to
> > > >> vexpress_smp_init_ops, vexpress_smp_init_ops will be called.
> > > >> vexpress_smp_init_ops sets smp_ops to vexpress_smp_ops, that *break*
> > > >> Xen.
> > > > 
> > > > OK I see.
> > > > 
> > > >> With this patch, xen_smp_init will be called instead of
> > > >> vexpress_smp_init_ops, and smp_ops will be set to psci_smp_ops,
> > > >> therefore *unbreaking* Xen.
> > > > 
> > > > However that breaks MCPM.
> > > 
> > > You mean on bare metal, right? For the bare metal, "xen,xen" property
> > > would not be present and xen_smp_init is not used. So the vexpress MCPM
> > > ops will be used. Aren't Dom0 cpu's basically virtual cpus? If Xen ever
> > > needs the MCPM support, the Xen hook itself can figure out whether to
> > > use MCPM support.
> > 
> > Well, if Xen has its own mdesc distinct from the VExpress one then 
> > things
> > are indeed fine.
> 
> It's not about the mdesc: Xen has its own hypervisor node on device tree
> if and only if Xen is running on the platform, therefore the Xen early
> hook is never going to do anything at all on native.
> 
> In other words, this patch should NOT change the behaviour of Linux on
> native, and if it did, it would be a bug.

Perfect.


Nicolas


From dt.tangr at gmail.com  Fri Apr  5 20:26:19 2013
From: dt.tangr at gmail.com (Daniel Tang)
Date: Sat, 6 Apr 2013 11:26:19 +1100
Subject: [RFC PATCH arm: initial TI-Nspire support]
In-Reply-To: <201304041112.25780.arnd@arndb.de>
References: <6FE4B33E-A503-4A75-AEED-831CB2C06D83@gmail.com>
 <201304041112.25780.arnd@arndb.de>
Message-ID: <8FB21B56-58BC-4530-8C7A-71A32856210D@gmail.com>

Hi,

First of all, thank you for your comments!

On 04/04/2013, at 10:12 PM, Arnd Bergmann <arnd at arndb.de> wrote:

> For new platforms, we want to have only the absolute minimum amount of
> code in arch/arm and move everything else into drivers. However, that
> is only possible using device tree. It should not add any significant
> complexity to your code, and you can easily bundle the device tree blob
> with the kernel.

Given that most of your comments described some very fundamental changes (esp switching to DTB) to the structure of our port, we've decided we'll probably start from scratch and fix the issues you outlined as we reimplement our platform.

At the moment, we're working on getting a basic DTB-booting kernel working so our next patch will be starting from basics.

Cheers,
tangrs

From matt at genesi-usa.com  Fri Apr  5 21:07:09 2013
From: matt at genesi-usa.com (Matt Sealey)
Date: Fri, 5 Apr 2013 20:07:09 -0500
Subject: [RFC PATCH] CLK: Allow parent clock and rate to be configured in
 DT.
In-Reply-To: <CAOMZO5ASkvquyzPCEGObvB5Xh9bDPTJ2zx26eOUJT_Vb36Bn3Q@mail.gmail.com>
References: <20130319170933.28337.50448.stgit@localhost>
 <20130325101707.GZ1906@pengutronix.de>
 <CAOMZO5ASkvquyzPCEGObvB5Xh9bDPTJ2zx26eOUJT_Vb36Bn3Q@mail.gmail.com>
Message-ID: <CAKGA1bkWLrOs15ni=8D__BvuG6kvqkeeLZGOLrVZY9g0q0z4Bg@mail.gmail.com>

On Thu, Apr 4, 2013 at 6:08 PM, Fabio Estevam <festevam at gmail.com> wrote:
>
> This could be useful for removing the imx6q_sabrelite_cko1_setup()
> function from arch/arm/mach-imx/mach-imx6q.c.
>
> I would like to add audio support for another board and would like to
> avoid to do the same as imx6q_sabrelite_cko1_setup()  for setting up
> the CLKO, if possible.

You know, we have the same problem on one of our designs here (CLKO is
used on MX53 for audio codec and camera device, shared) - the current
solution is hack it into platform support in a BSP kernel.

If we move to device tree, we know and you know the solution already;
all this clock setup HAS to be done in the bootloader.

The device tree really, really is only a way to describe the
configuration as it exists or to describe alternatives - for instance,
a clock with 10 parents may be described as having 10 parents, and the
binding (in complicated cases) or driver (if it is simple as a value
from 0 to 7 and the field width is 3 bits for example) will determine
how that alternative can be selected (and by consequence, what the
current setting is).

The device tree concept is NOT a place to dump configuration items for
your board as hardcoded values to try and force something you could
have done elsewhere. On i.MX53 you cannot boot a kernel verbatim - you
at least have to run through the Boot ROM and supply a DCD table or
plugins first. This is where you figure things like this out.

In a case where you have, say, an audio codec and it has a dynamic
input clock that you want to change on the fly, first of all you would
not hardcode a frequency into a device tree, second of all there is
nothing stopping you from doing that right now anyway. If the clock is
static and fixed frequency and can only be turned on and off, there
are clock bindings for this already. If it is static and can never be
turned off, then there are clock bindings for this too, and in this
case the proviso is that the clock is ALREADY turned on and ALREADY
stable before you enter the kernel otherwise the description is by
it's very definition invalid.

If the clock frequency in hardware is not what you wanted when the
driver comes up, and you only have an on/off switch, it is not up to
the device tree binding to describe how to go about configuring the
system to make sure. You cannot in good conscience put a clock
frequency "to be set later" in the device tree along with a clock
phandle, simply because that means the device tree no longer describes
the hardware accurately - the clock phandle is a valid clock, the
hardware will tell you a frequency from registers in the clock driver,
the device tree will disagree. How do you know which one is the
correct value, or if the frequency in the tree is a suggestion rather
than a description?

I am totally against this (sorry Sascha..). Let's put some effort into
fixing the bootloaders rather than trying to use the device tree to
enforce the ridiculous assumption that "Linux kernel does not trust
the bootloader". Once the bindings and trees are out of the kernel
source, you're going to HAVE to trust what the bootloader passes, be
it pregenerated compiled blob (which needs to be written to match the
hardware state the bootloader finishes up at) or dynamically generated
at runtime during the boot process (which can describe to the bit what
the hardware is doing). If you are testing this on Beagle XM you can
fix your U-Boot easily. New boards will have to be designed *with the
idea of device trees and working configurations in mind* - that is a
fact of life, in fact this is how it should be in reality these days
anyway (most HW designers will do initial bringup of the board - at
least a minimal working configuration, in a restricted environment
where they can use test pads to measure clocks, voltage outputs and
levels of devices to ensure both production was successful and that
the design is in itself electrically sound. This code 99% of the time
ends up in the bootloader... sometimes not, when the board was
designed by one group and the software written by the community, but
in this case the community needs to learn board bringup and proper
behavior...)

-- 
Matt Sealey <matt at genesi-usa.com>
Product Development Analyst, Genesi USA, Inc.


From matt at genesi-usa.com  Fri Apr  5 21:33:36 2013
From: matt at genesi-usa.com (Matt Sealey)
Date: Fri, 5 Apr 2013 20:33:36 -0500
Subject: [RFC PATCH] CLK: Allow parent clock and rate to be configured in
 DT.
In-Reply-To: <CAKGA1bkWLrOs15ni=8D__BvuG6kvqkeeLZGOLrVZY9g0q0z4Bg@mail.gmail.com>
References: <20130319170933.28337.50448.stgit@localhost>
 <20130325101707.GZ1906@pengutronix.de>
 <CAOMZO5ASkvquyzPCEGObvB5Xh9bDPTJ2zx26eOUJT_Vb36Bn3Q@mail.gmail.com>
 <CAKGA1bkWLrOs15ni=8D__BvuG6kvqkeeLZGOLrVZY9g0q0z4Bg@mail.gmail.com>
Message-ID: <CAKGA1bntow29MwxBFWNKiP8HwMEQkPVL+KeW6=m0Ee0pfPTFeg@mail.gmail.com>

Okay now I have finished my criticism, I will make some productive
suggestions :)

How about we implement a system as follows; modify the clock framework
and bindings such that we not only describe all the parents possible
for a clock, we also enter into the device tree the current parent? I
actually didn't fully realise it until now, but that just isn't in
there (it's derived from the list in the parents property and the
current hardware setting!).

That way, at least on clock initialization it will be able to warn
that the parent in the device tree is not the one in hardware, and -
with suitable options or by default - warn that it is setting the
parent to the one in the device tree. That solves the "which parent I
want" problem without involving ACTUAL configuration, and meets
Sascha's requirement that it is not done by a back door of
configuration items. So to summarize, the process is

* Device tree describes all parents of a clock in parents property
* Device tree describes which parent is the "current" parent
* Linux parses the tree and registers the clock - checks if the parent
in HW is the same as the one in DT
 - if it is not the same, print a horrific warning to the kernel log
 - if we desire to (and it should be possible to make this a debug
option for clock subsystem) set the parent to the one in the DT (also
printing a horrific warning that it has done so)

To solve the issue of "setting clocks to fixed rates", I would suggest
we do it by way of a similar system to the cpu frequency drivers or
regulators, and use operating points or ranges. For a good chunk of
devices, actual clock gating, rate changing and power management are
possible and highly useful in myriad different ways depending on the
device. In this way, an audio codec may end up with a list of
"operating-points" in a node which describes all the valid clock
rates. For example the SGTL5000 can accept many input clocks, the
CS42L52 audio codec can also accept many input clock rates - and the
audio frequency support is determined by those clock rates. For the
latter example, this huge table;

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/sound/soc/codecs/cs42l52.c#n690

.. is a move-to-device-tree candidate. The driver could pick a
suitable operating point from a range (which it could determine by the
rates the clock phandle supports), and you can even "suggest" one the
same way we do for regulators - only supply a single value. That way,
everything looks like it is being done on the basis of power
management, WOULD be used as power management on a vast chunk of
devices, and can be "restricted" to only work for specific values on
systems which didn't have the dynamism of others (for instance the
MC13892 PMIC has many regulators with wide ranges of voltages, but on
most systems they are tied to specific, fixed voltage rails so giving
a range makes no sense, and there's no real driver that can take
responsibility for setting them. But some use cases may tie the same
regulator output to a dynamic voltage rail, so you can't get away with
just being fixed or just being totally rangey)

How does that sound (audio codec pun not entirely intentional..)?
Matt Sealey <matt at genesi-usa.com>
Product Development Analyst, Genesi USA, Inc.


On Fri, Apr 5, 2013 at 8:07 PM, Matt Sealey <matt at genesi-usa.com> wrote:
> On Thu, Apr 4, 2013 at 6:08 PM, Fabio Estevam <festevam at gmail.com> wrote:
>>
>> This could be useful for removing the imx6q_sabrelite_cko1_setup()
>> function from arch/arm/mach-imx/mach-imx6q.c.
>>
>> I would like to add audio support for another board and would like to
>> avoid to do the same as imx6q_sabrelite_cko1_setup()  for setting up
>> the CLKO, if possible.
>
> You know, we have the same problem on one of our designs here (CLKO is
> used on MX53 for audio codec and camera device, shared) - the current
> solution is hack it into platform support in a BSP kernel.
>
> If we move to device tree, we know and you know the solution already;
> all this clock setup HAS to be done in the bootloader.
>
> The device tree really, really is only a way to describe the
> configuration as it exists or to describe alternatives - for instance,
> a clock with 10 parents may be described as having 10 parents, and the
> binding (in complicated cases) or driver (if it is simple as a value
> from 0 to 7 and the field width is 3 bits for example) will determine
> how that alternative can be selected (and by consequence, what the
> current setting is).
>
> The device tree concept is NOT a place to dump configuration items for
> your board as hardcoded values to try and force something you could
> have done elsewhere. On i.MX53 you cannot boot a kernel verbatim - you
> at least have to run through the Boot ROM and supply a DCD table or
> plugins first. This is where you figure things like this out.
>
> In a case where you have, say, an audio codec and it has a dynamic
> input clock that you want to change on the fly, first of all you would
> not hardcode a frequency into a device tree, second of all there is
> nothing stopping you from doing that right now anyway. If the clock is
> static and fixed frequency and can only be turned on and off, there
> are clock bindings for this already. If it is static and can never be
> turned off, then there are clock bindings for this too, and in this
> case the proviso is that the clock is ALREADY turned on and ALREADY
> stable before you enter the kernel otherwise the description is by
> it's very definition invalid.
>
> If the clock frequency in hardware is not what you wanted when the
> driver comes up, and you only have an on/off switch, it is not up to
> the device tree binding to describe how to go about configuring the
> system to make sure. You cannot in good conscience put a clock
> frequency "to be set later" in the device tree along with a clock
> phandle, simply because that means the device tree no longer describes
> the hardware accurately - the clock phandle is a valid clock, the
> hardware will tell you a frequency from registers in the clock driver,
> the device tree will disagree. How do you know which one is the
> correct value, or if the frequency in the tree is a suggestion rather
> than a description?
>
> I am totally against this (sorry Sascha..). Let's put some effort into
> fixing the bootloaders rather than trying to use the device tree to
> enforce the ridiculous assumption that "Linux kernel does not trust
> the bootloader". Once the bindings and trees are out of the kernel
> source, you're going to HAVE to trust what the bootloader passes, be
> it pregenerated compiled blob (which needs to be written to match the
> hardware state the bootloader finishes up at) or dynamically generated
> at runtime during the boot process (which can describe to the bit what
> the hardware is doing). If you are testing this on Beagle XM you can
> fix your U-Boot easily. New boards will have to be designed *with the
> idea of device trees and working configurations in mind* - that is a
> fact of life, in fact this is how it should be in reality these days
> anyway (most HW designers will do initial bringup of the board - at
> least a minimal working configuration, in a restricted environment
> where they can use test pads to measure clocks, voltage outputs and
> levels of devices to ensure both production was successful and that
> the design is in itself electrically sound. This code 99% of the time
> ends up in the bootloader... sometimes not, when the board was
> designed by one group and the software written by the community, but
> in this case the community needs to learn board bringup and proper
> behavior...)
>
> --
> Matt Sealey <matt at genesi-usa.com>
> Product Development Analyst, Genesi USA, Inc.


From ryan at presslab.us  Fri Apr  5 22:14:39 2013
From: ryan at presslab.us (Ryan Press)
Date: Fri, 5 Apr 2013 19:14:39 -0700
Subject: [PATCH] arm: mvebu: Fix the irq map function in SMP mode
In-Reply-To: <1365165172-11447-2-git-send-email-gregory.clement@free-electrons.com>
References: <1365165172-11447-1-git-send-email-gregory.clement@free-electrons.com>
 <1365165172-11447-2-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <CABx3TkVscXg+EuF6s3K7_RDHMKD8H7tRe0BE1Zt3nQvA0oWJXg@mail.gmail.com>

On Fri, Apr 5, 2013 at 5:32 AM, Gregory CLEMENT
<gregory.clement at free-electrons.com> wrote:
> This patch fix the regression introduced by the commit 3202bf0157ccb
> "arm: mvebu: Improve the SMP support of the interrupt controller":
> GPIO IRQ were no longer delivered to the CPUs.
>
> To be delivered to a CPU an interrupt must be enabled at CPU level and
> at interrupt source level. Before the offending patch, all the
> interrupts were enabled at source level during map() function. Mask()
> and unmask() was done by handling the per-CPU part. It was fine when
> running in UP with only one CPU.
>
> The offending patch added support for SMP, in this case mask() and
> unmask() was done by handling the interrupt source level part. The
> per-CPU level part was handled by the affinity API to select the CPU
> which will receive the interrupt. (Due to some hardware limitation
> only one CPU at a time can received a given interrupt).
>
> For "normal" interrupt __setup_irq() was called when an irq was
> registered. irq_set_affinity() is called from this function, which
> enabled the interrupt on one of the CPUs. Whereas for GPIO IRQ which
> were chained interrupts, the irq_set_affinity() was never called and
> none of the CPUs was selected to receive the interrupt.
>
> With this patch all the interrupt are enable on the current CPU during
> map() function. Enabling the interrupts on a CPU doesn't depend
> anymore on irq_set_affinity() and then the chained irq are not anymore
> a special case. However the CPU which will receive the irq can still
> be modify later using irq_set_affinity().
>
> Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
> Reported-by: Ryan Press <ryan at presslab.us>
> Investigated-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
> Tested-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
>
> Tested with Mirabox (A370) and Openblocks AX3 (AXP), rootfs mounted
> over NFS, compiled with CONFIG_SMP=y/N.


Thanks guys, I turned CONFIG_SMP back on and the gpio-keys button now
works great!

Tested-by: Ryan Press <ryan at presslab.us>


Ryan


From shc_work at mail.ru  Sat Apr  6 02:13:31 2013
From: shc_work at mail.ru (Alexander Shiyan)
Date: Sat,  6 Apr 2013 10:13:31 +0400
Subject: [PATCH] mmc: mxcmmc: Fix bug when card is present during boot
Message-ID: <1365228811-10928-1-git-send-email-shc_work@mail.ru>

This patch fixes bug when card is present during boot.
Bug was introduced due commit "mmc: mxcmmc: fix bug that may block a
data transfer forever". When a card is present "mxcmci_setup_data"
function is executed, but the timer is not initialized.

...
i.MX SDHC driver
mmc0: SD Status: Invalid Allocation Unit size.
mmc0: new SD card at address b368
mmcblk0: mmc0:b368 SDC   1.91 GiB
------------[ cut here ]------------
kernel BUG at kernel/timer.c:729!
Internal error: Oops - BUG: 0 [#1] PREEMPT ARM
CPU: 0    Not tainted  (3.9.0-rc5-next-20130404 #2)
PC is at mod_timer+0x168/0x198
LR is at mxcmci_request+0x21c/0x328
pc : [<c0026d28>]    lr : [<c0261928>]    psr: 60000013
sp : c7933df0  ip : 00001000  fp : 00000001
r10: c0012edc  r9 : c7920400  r8 : c014f92c
r7 : c7920600  r6 : ffff8f8f  r5 : ffff8f8f  r4 : c79206a4
r3 : 00000000  r2 : 00000000  r1 : ffff8f8f  r0 : c79206a4
Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
Control: 0005317f  Table: a0004000  DAC: 00000017
Process mmcqd/0 (pid: 450, stack limit = 0xc79321b8)
Stack: (0xc7933df0 to 0xc7934000)
3de0:                                     c78260f8 00000000 00000001 c78dcce0
3e00: c78dcc2c 00000200 c7920600 c014f92c c0012edc c0261928 00000003 00000000
3e20: 00000000 c7874210 c78dc800 00000002 c790f720 c78dcc2c c7920400 00000001
3e40: c78dcd20 00000001 c7933ee4 00000000 c78dcc2c c02504f0 00000000 c7920400
3e60: 00000000 c0251588 c7a60138 c7920000 c78dcc2c c78dcc04 c78dcc00 00000000
3e80: 00000000 c025de34 c78dcc04 c7a60138 c78dcc28 c78dcc04 c7920000 c7a60138
3ea0: c7920400 c78dcc00 c78dcc2c c025ed3c c7933f44 00000000 c78dcc00 00000000
3ec0: 00000000 c0037af0 00000000 c7932000 40000013 c0250d50 c7933f6c 00000000
3ee0: c78cb6c0 c003f6b8 00100100 c7920000 c7a60138 c78dcc04 c78dcc00 120d0000
3f00: c7920400 c78dcc00 c78dcc0c c025f918 c7847d34 00000001 c7847d40 00000000
3f20: c7933f54 c78dcc04 c7a60138 c7932000 00000000 120d0000 c7996b80 00000001
3f40: c78dcc0c c0260410 00000000 c7847d2c 00000000 c78dcc04 c0260358 00000000
3f60: 00000000 00000000 00000000 c0037094 00000000 00000000 2d656761 c78dcc04
3f80: 00000000 c7933f84 c7933f84 00000000 c7933f90 c7933f90 c7933fac c7847d2c
3fa0: c0036ff0 00000000 00000000 c000e210 00000000 00000000 00000000 00000000
3fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
3fe0: 00000000 00000000 00000000 00000000 00000013 00000000 7ffff1e5 ef7b8ff9
[<c0026d28>] (mod_timer+0x168/0x198) from [<c0261928>] (mxcmci_request+0x21c/0x328)
[<c0261928>] (mxcmci_request+0x21c/0x328) from [<c02504f0>] (mmc_start_request+0xc4/0xe8)
[<c02504f0>] (mmc_start_request+0xc4/0xe8) from [<c0251588>] (mmc_start_req+0x2d0/0x380)
[<c0251588>] (mmc_start_req+0x2d0/0x380) from [<c025ed3c>] (mmc_blk_issue_rw_rq+0xb4/0xaf0)
[<c025ed3c>] (mmc_blk_issue_rw_rq+0xb4/0xaf0) from [<c025f918>] (mmc_blk_issue_rq+0x1a0/0x4ec)
[<c025f918>] (mmc_blk_issue_rq+0x1a0/0x4ec) from [<c0260410>] (mmc_queue_thread+0xb8/0x150)
[<c0260410>] (mmc_queue_thread+0xb8/0x150) from [<c0037094>] (kthread+0xa4/0xb0)
[<c0037094>] (kthread+0xa4/0xb0) from [<c000e210>] (ret_from_fork+0x14/0x24)
Code: e0065015 eaffffb3 e3a0a001 eaffffea (e7f001f2)
---[ end trace 29f2f8ea54d9d99e ]---

Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
---
 drivers/mmc/host/mxcmmc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/host/mxcmmc.c b/drivers/mmc/host/mxcmmc.c
index a72936e..28e527e 100644
--- a/drivers/mmc/host/mxcmmc.c
+++ b/drivers/mmc/host/mxcmmc.c
@@ -1052,12 +1052,12 @@ static int mxcmci_probe(struct platform_device *pdev)
 			goto out_free_irq;
 	}
 
-	mmc_add_host(mmc);
-
 	init_timer(&host->watchdog);
 	host->watchdog.function = &mxcmci_watchdog;
 	host->watchdog.data = (unsigned long)mmc;
 
+	mmc_add_host(mmc);
+
 	return 0;
 
 out_free_irq:
-- 
1.8.1.5



From arnd at arndb.de  Sat Apr  6 04:31:45 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Sat, 6 Apr 2013 10:31:45 +0200
Subject: [PATCH v2 2/9] arm: mvebu: Align the internal registers virtual
 base to support LPAE
In-Reply-To: <515F3E96.4040307@free-electrons.com>
References: <1365193444-13441-1-git-send-email-gregory.clement@free-electrons.com>
 <201304052250.28641.arnd@arndb.de> <515F3E96.4040307@free-electrons.com>
Message-ID: <201304061031.45598.arnd@arndb.de>

On Friday 05 April 2013, Gregory CLEMENT wrote:
> On 04/05/2013 10:50 PM, Arnd Bergmann wrote:
> > On Friday 05 April 2013, Gregory CLEMENT wrote:
> >> From: Lior Amsalem <alior at marvell.com>
> > 
> > This is a surprising limitation. Can you extend the above text to go into more
> > detail where that alignment requirement comes from?
> > 
> 
> The explanation I had was that in LPAE section size is 2MB, in earlyprintk we map
> the internal registers and it must be section aligned.
> 

Ah, I see. Please put that in the text then.

	Arnd


From arnd at arndb.de  Sat Apr  6 04:39:56 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Sat, 6 Apr 2013 10:39:56 +0200
Subject: mvebu-mbus: defining a DT binding
In-Reply-To: <20130405212143.GA16221@obsidianresearch.com>
References: <20130405150200.7b6dee63@skate> <201304052301.27231.arnd@arndb.de>
 <20130405212143.GA16221@obsidianresearch.com>
Message-ID: <201304061039.56241.arnd@arndb.de>

On Friday 05 April 2013, Jason Gunthorpe wrote:
> On Fri, Apr 05, 2013 at 11:01:27PM +0200, Arnd Bergmann wrote:
> 
> > >  - The bridge ranges would be offset 0 length 4G-1 in the DT since
> > >    the value is not known. However firmware could do PCI address
> > >    assignment and fill in corrected values.
> > 
> > I don't undestand this part. It would make the topmost byte in the
> > 4GB bus space unadressable, which seems strange. Why can't we use
> > the entire 4GB? Maybe we should leave at least a page?
> 
> Oh, sorry, that was just a mostly arbitary hacky choice to fit within
> 1 size cell. Using 2 size cells requires an upgrade to skeleton64 for
> all mvebu platforms, eg kirkwood.
> 
> Realistically this size should never be used so it doesn't matter if
> it is 4G or 4G-1 - though obviously 4G is preferred in cases where
> size cells is 2. :)

But the PCI bus already is required to have #size-cells=<2>, and
we would only use this in the ranges property of the PCI node, right?

> So.. I don't think it matters today for mvebu, but something to think
> about - shuffling the firmware's address map could be dangerous.

I would at least expect a secure-mode firmware to prevent the OS
from changing any mappings that the firmware relies on, but I see
what you mean.

	Arnd


From padma.kvr at gmail.com  Sat Apr  6 06:13:36 2013
From: padma.kvr at gmail.com (Padma Venkat)
Date: Sat, 6 Apr 2013 15:43:36 +0530
Subject: [PATCH 1/3] clk: exynos: register audio subsystem clocks using
 common clock framework
In-Reply-To: <515ED757.9070708@samsung.com>
References: <1365143029-16936-1-git-send-email-padma.v@samsung.com>
 <515ED757.9070708@samsung.com>
Message-ID: <CAAgF-Bcpaef_uTWjw6or_uonFN9HU=xSEhxFFTyiA+mu+7iYpw@mail.gmail.com>

Hi Sylwester,

On Fri, Apr 5, 2013 at 7:23 PM, Sylwester Nawrocki
<s.nawrocki at samsung.com> wrote:
> On 04/05/2013 08:23 AM, Padmavathi Venna wrote:
>> Audio subsystem is introduced in exynos platforms. This has seperate
>> clock controller which can control i2s0 and pcm0 clocks. This patch
>> registers the audio subsystem clocks with the common clock framework.
>>
>> Signed-off-by: Padmavathi Venna <padma.v at samsung.com>
>> ---
>>  drivers/clk/samsung/Makefile           |    1 +
>>  drivers/clk/samsung/clk-exynos-audss.c |  139 ++++++++++++++++++++++++++++++++
>>  2 files changed, 140 insertions(+), 0 deletions(-)
>>  create mode 100644 drivers/clk/samsung/clk-exynos-audss.c
>>
>> diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile
>> index b7c232e..1876810 100644
>> --- a/drivers/clk/samsung/Makefile
>> +++ b/drivers/clk/samsung/Makefile
>> @@ -6,3 +6,4 @@ obj-$(CONFIG_COMMON_CLK)      += clk.o clk-pll.o
>>  obj-$(CONFIG_ARCH_EXYNOS4)   += clk-exynos4.o
>>  obj-$(CONFIG_SOC_EXYNOS5250) += clk-exynos5250.o
>>  obj-$(CONFIG_SOC_EXYNOS5440) += clk-exynos5440.o
>> +obj-$(CONFIG_ARCH_EXYNOS)    += clk-exynos-audss.o
>> diff --git a/drivers/clk/samsung/clk-exynos-audss.c b/drivers/clk/samsung/clk-exynos-audss.c
>> new file mode 100644
>> index 0000000..d7f9aa8
>> --- /dev/null
>> +++ b/drivers/clk/samsung/clk-exynos-audss.c
>> @@ -0,0 +1,139 @@
>> +/*
>> + * Copyright (c) 2013 Samsung Electronics Co., Ltd.
>> + * Author: Padmavathi Venna <padma.v at samsung.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.
>> + *
>> + * Common Clock Framework support for Audio clks.
>
> s/clks/Subsystem Clock Controller ?

Ok. I will change this.

>
>> +*/
>> +
>> +#include <linux/clkdev.h>
>> +#include <linux/io.h>
>> +#include <linux/clk-provider.h>
>> +#include <linux/of_address.h>
>> +#include <linux/syscore_ops.h>
>> +
>> +static DEFINE_SPINLOCK(lock);
>> +static struct clk **clk_table;
>> +static void __iomem *reg_base;
>> +#ifdef CONFIG_OF
>
> Is this really required ? This driver is for ARCH_EXYNOS which is
> going to be DT only anyway - presumably it would depend on OF.

I missed out to delete this. It's not required.

>
>> +static struct clk_onecell_data clk_data;
>> +#endif
>> +
>> +#define ASS_CLK_SRC 0x0
>> +#define ASS_CLK_DIV 0x4
>> +#define ASS_CLK_GATE 0x8
>> +
>> +static unsigned long reg_save[][2] = {
>> +     {ASS_CLK_SRC,  0x0},
>
> nit: '0x' could be probably omitted.

Ok.

>
>> +     {ASS_CLK_DIV,  0x0},
>> +     {ASS_CLK_GATE, 0x0},
>> +};
>> +
>> +/*
>> + * Let each supported clock get a unique id. This id is used to lookup the clock
>> + * for device tree based platforms.
>> + *
>> + * When adding a new clock to this list, it is advised to add it to the end.
>> + * That is because the device tree source file is referring to these ids and
>> + * any change in the sequence number of existing clocks will require
>> + * corresponding change in the device tree files. This limitation would go away
>> + * when pre-processor support for dtc would be available.
>
> It's already available. Also please see [1]. IMO the best would be to
> create a header file including #defines for all the clocks indexes as
> per enum exynos_audss_clks. This header would be put in a common location
> so it can be included by the driver and the dts files.

Ok. I will include it.

>
>> + */
>> +enum exynos_audss_clks {
>> +     /* audss clocks */
>> +     mout_audss, mout_i2s,
>> +     dout_srp, dout_bus, dout_i2s,
>> +     srp_clk, i2s_bus, sclk_i2s0,
>> +
>> +     nr_clks,
>> +};
>> +
>> +/* list of all parent clock list */
>> +static const char *mout_audss_p[] = { "fin_pll", "fout_epll" };
>> +static const char *mout_i2s_p[] = { "mout_audss", "cdclk0", "sclk_audio0" };
>> +
>> +#ifdef CONFIG_PM_SLEEP
>> +static int exynos_audss_clk_suspend(void)
>> +{
>> +     int i;
>> +
>> +     for (i = 0; i < 3; i++)
>> +             reg_save[i][1] = __raw_readl(reg_base + reg_save[i][0]);
>
> Why using the __raw_* accessors ? I think it should be readl().

Ok. I will change this.

>
>> +
>> +     return 0;
>> +}
>> +
>> +static void exynos_audss_clk_resume(void)
>> +{
>> +     int i;
>> +
>> +     for (i = 0; i < 3; i++)
>> +             __raw_writel(reg_save[i][1], reg_base + reg_save[i][0]);
>
> Same here, writel().
>
>> +}
>> +
>> +static struct syscore_ops exynos_audss_clk_syscore_ops = {
>> +     .suspend        = exynos_audss_clk_suspend,
>> +     .resume         = exynos_audss_clk_resume,
>> +};
>> +#endif /* CONFIG_PM_SLEEP */
>> +
>> +/* register exynos_audss clocks */
>> +void __init exynos_audss_clk_init(struct device_node *np)
>> +{
>
> Isn't it better to just do
>
>         if (np == NULL)
>                 return;
>
> i.e. just skip the initialization altogether ? panic() seems
> unreasonable here.

Ok. I will change this.

>
>> +     if (np) {
>> +             reg_base = of_iomap(np, 0);
>> +             if (!reg_base)
>> +                     panic("%s: failed to map registers\n", __func__);
>> +     } else
>> +             panic("%s: unable to determine soc\n", __func__);
>> +
>> +     clk_table = kzalloc(sizeof(struct clk *) * nr_clks, GFP_KERNEL);
>> +     if (!clk_table)
>> +             panic("could not allocate clock lookup table\n");
>> +
>> +     clk_data.clks = clk_table;
>> +     clk_data.clk_num = nr_clks;
>> +     of_clk_add_provider(np, of_clk_src_onecell_get, &clk_data);
>> +
>> +     clk_table[mout_audss] = clk_register_mux(NULL, "mout_audss",
>> +                             mout_audss_p, ARRAY_SIZE(mout_audss_p), 0,
>> +                             reg_base + ASS_CLK_SRC, 0, 1, 0, &lock);
>> +     clk_register_clkdev(clk_table[mout_audss], "mout_audss", NULL);
>> +
>> +     clk_table[mout_i2s] = clk_register_mux(NULL, "mout_i2s", mout_i2s_p,
>> +                             ARRAY_SIZE(mout_i2s_p), 0,
>> +                             reg_base + ASS_CLK_SRC, 2, 2, 0, &lock);
>> +     clk_register_clkdev(clk_table[mout_i2s], "mout_i2s", NULL);
>> +
>> +     clk_table[dout_srp] = clk_register_divider(NULL, "dout_srp",
>> +                             "mout_audss", 0, reg_base + ASS_CLK_DIV, 0, 4,
>> +                             0, &lock);
>> +
>> +     clk_table[dout_bus] = clk_register_divider(NULL, "dout_bus",
>> +                             "dout_srp", 0, reg_base + ASS_CLK_DIV, 4, 4, 0,
>> +                             &lock);
>> +
>> +     clk_table[dout_i2s] = clk_register_divider(NULL, "dout_i2s",
>> +                             "mout_i2s", 0, reg_base + ASS_CLK_DIV, 8, 4, 0,
>> +                             &lock);
>> +
>> +     clk_table[srp_clk] = clk_register_gate(NULL, "srp_clk", "dout_srp",
>> +                             CLK_SET_RATE_PARENT, reg_base + ASS_CLK_GATE, 0,
>> +                             0, &lock);
>> +
>> +     clk_table[i2s_bus] = clk_register_gate(NULL, "i2s_bus", "dout_bus",
>> +                             CLK_SET_RATE_PARENT, reg_base + ASS_CLK_GATE, 2,
>
> Don't we need to handle also bit 3 of the ASS_CLK_GATE register ?

Bit 3 is handled below as sclk_i2s0.

>
> In some kernels I saw PCM special/PCM Bus and I2S special/I2S Bus bits
> associated with same clocks. So there were 2-bit wide masks for each clock.
>
> Tomasz had an idea to add a flag to the clock framework that would be passed
> to clk_register_gate() and would indicate that the sixth argument is a bitmask,
> rather than a bit index.

For I2S there are separate clock instances and bits in the clock
controller named as busclk[bit:2] and i2s_clk[bit:3].
But PCM case there are two bits available[bit 4 and 5] but I think
only one clock instance available(need to check
clk controller diagram). But anyway having the bitmask in the
clk_register_gate may be useful.

>
> Perhaps we could just specify each bit of ASS_CLK_GATE as a separate clock.
> Then the drivers would need to be modified. I'm not sure what's best approach.
> And if it is really necessary to be enabling/disabling both special/bus clock
> gate bits simultaneously. I'm adding Mike to Cc, so perhaps he could provide
> us with some pointers.
>
>> +                             0, &lock);
>> +
>> +     clk_table[sclk_i2s0] = clk_register_gate(NULL, "sclk_i2s0", "dout_i2s",
>> +                             CLK_SET_RATE_PARENT, reg_base + ASS_CLK_GATE, 3,
>> +                             0, &lock);
>> +#ifdef CONFIG_PM_SLEEP
>> +     register_syscore_ops(&exynos_audss_clk_syscore_ops);
>> +#endif
>> +     pr_info("Exynos: Audss: clock setup completed\n");
>> +}
>> +CLK_OF_DECLARE(exynos_audss_clk, "samsung,exynos-audss-clock", exynos_audss_clk_init);
>
>
> [1] http://www.spinics.net/lists/linux-kbuild/msg07616.html


From padma.kvr at gmail.com  Sat Apr  6 06:16:16 2013
From: padma.kvr at gmail.com (Padma Venkat)
Date: Sat, 6 Apr 2013 15:46:16 +0530
Subject: [PATCH 0/3] clk: Exynos: Register audio subsytem clocks using
 common clk framework
In-Reply-To: <515EC996.8030904@samsung.com>
References: <1365144043-17101-1-git-send-email-padma.v@samsung.com>
 <515EC996.8030904@samsung.com>
Message-ID: <CAAgF-Be1Hvkt=BDK913KTu66M4izxbuOuORQ8hyT-GZR1+ABnQ@mail.gmail.com>

Hi Sylwester,

On Fri, Apr 5, 2013 at 6:24 PM, Sylwester Nawrocki
<s.nawrocki at samsung.com> wrote:
> Hi Padmavathi,
>
> On 04/05/2013 08:40 AM, Padmavathi Venna wrote:
>> Samsung Exynos SoC has a separate subsystem for audio. This subsystem
>> has a internal clock controller which controls i2s0 and pcm0 clocks.
>> This patch series adds the Samsung Exynos SoC audio subsytem clock code
>> to the common clock framework and provides the I2S0 clock information in
>> the dtsi file.
>>
>> Padmavathi Venna (3):
>>   clk: exynos: register audio subsystem clocks using common clock
>>     framework
>>   ARM: dts: add Exynos audio subsystem clock controller node
>>   ARM: dts: add clock provider information for i2s0 controller in
>>     Exynos5250
>>
>>  arch/arm/boot/dts/exynos5250.dtsi      |    8 ++
>>  drivers/clk/samsung/Makefile           |    1 +
>>  drivers/clk/samsung/clk-exynos-audss.c |  139 ++++++++++++++++++++++++++++++++
>>  3 files changed, 148 insertions(+), 0 deletions(-)
>>  create mode 100644 drivers/clk/samsung/clk-exynos-audss.c
>
> It looks good, it's very similar what we have written recently for Exynos4.
> It seems the binding documentation is missing in this patch set. I've included
> below content of our .../bindings/clock/exynos4-audss-clock.txt file. Feel free
> to reuse any parts of it.

Thanks for your review and help. I forgot to include documentation
file. I will reuse your's.

>
> From a brief look Exynos4 and Exynos5 Audio Subsystem CLKCON very similar.
> I've just found bit 2 of 0x0381_0008 register is not used on Exynos5250.

I added bit 2 as i2s_bus gate clock or you are pointing to something else?

>
> Additionally the Audio Subsystem Clock controller is present on S5PV210
> SoCs and IMO compatible property you used is too generic. I would propose
> to use at least:
>
> "samsung,s5pv210-audss-clock"    - for S5PV210
> "samsung,exynos4210-audss-clock" - for Exynos4
> "samsung,exynos5250-audss-clock" - for Exynos5

Different compatible names means different driver files for exynos4 and 5??
I haven't seen any difference between Exynos4 and Exynos5 audio subsystem.
Can't we maintain one for both? If any extra clock instance is added
on newer SoCs
anyway it gets added at the end of the list of clocks. Please correct
me if I am wrong.

>
>
> 8<---------------------------------------------------------------------------
> * Samsung Exynos4 Audio Subsystem Clock Controller
>
> The Exynos4 Audio Subsystem clock controller generates and supplies clocks
> to Audio Subsystem block available in the Exynos4 SoCs. The clock binding
> described here is applicable to all SoC's in the Exynos4 family.
>
> Required Properties:
>
> - compatible: should be one of the following:
>   - "samsung,exynos4210-audss-clock" - controller compatible with all Exynos4 SoCs.
>
> - reg: physical base address and length of the controller's register set.
>
> - #clock-cells: should be 1.
>
> The following is the list of clocks generated by the controller. Each clock is
> assigned an identifier and client nodes use this identifier to specify the
> clock which they consume. Some of the clocks are available only on a particular
> Exynos4 SoC and this is specified where applicable.
>
> Provided clocks:
>
> Clock           ID      SoC (if specific)
> -----------------------------------------------
>
> mout_audss      0
> dout_rp         1
> dout_aud_bus    2
> mout_i2s        3
> dout_i2sclk0    4
> clk_i2s0        5
> clk_pcm0        6
>
>
> Example 1: An example of a clock controller node is listed below.
>
> clock_audss: clock-controller at 03810000 {
>         compatible = "samsung,exynos4-audss-clock";
>         reg = <0x03810000 0x0C>;
>         #clock-cells = <1>;
> };
>
> Example 2: I2S controller node that consumes the clock generated by the clock
>            controller. Refer to the standard clock bindings for information
>            about 'clocks' and 'clock-names' property.
>
> i2s0: i2s at 03830000 {
>         compatible = "samsung,i2s-v5";
>         reg = <0x03830000 0x100>;
>         clocks = <&clock_audss 0>, <&clock_audss 3>, <&clock_audss 1>,
>                 <&clock_audss 2>, <&clock_audss 4>, <&clock_audss 2>;
>         clock-names = "mout_audss", "mout_i2s", "dout_srp",
>                 "dout_bus", "dout_i2s", "i2s_opclk0";
> };
>
> 8<---------------------------------------------------------------------------
>
> Thanks,
> Sylwester

Thanks
Padma


From marc.zyngier at arm.com  Sat Apr  6 06:41:21 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Sat, 06 Apr 2013 12:41:21 +0200
Subject: [PATCHv2] ARM:
 =?UTF-8?Q?arch=5Ftimer=3A=20Silence=20debug=20preempt?=
 =?UTF-8?Q?=20warnings?=
In-Reply-To: <1365195449-6755-1-git-send-email-sboyd@codeaurora.org>
References: <1365195449-6755-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <211ac95efd49bd57933aec8c8e746648@localhost>

On Fri,  5 Apr 2013 13:57:29 -0700, Stephen Boyd <sboyd at codeaurora.org>
wrote:
> Hot-plugging with CONFIG_DEBUG_PREEMPT=y on a device with arm
> architected timers causes a slew of "using smp_processor_id() in
> preemptible" warnings:
> 
>   BUG: using smp_processor_id() in preemptible [00000000] code: sh/111
>   caller is arch_timer_cpu_notify+0x14/0xc8
> 
> This happens because sometimes the cpu notifier,
> arch_timer_cpu_notify(), is called in preemptible context and
> other times in non-preemptible context but we use this_cpu_ptr()
> to retrieve the clockevent in all cases. We're only going to
> actually use the pointer in non-preemptible context though, so
> push the this_cpu_ptr() access down into the cases to force the
> checks to occur only in non-preemptible contexts.
> 
> Cc: Mark Rutland <mark.rutland at arm.com>
> Cc: Marc Zyngier <Marc.Zyngier at arm.com>
> Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
> ---
> 
> Changes since v1:
>  * Pushed down this_cpu_ptr and added a comment
> 
>  drivers/clocksource/arm_arch_timer.c | 10 ++++++----
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/clocksource/arm_arch_timer.c
> b/drivers/clocksource/arm_arch_timer.c
> index d7ad425..a65a710 100644
> --- a/drivers/clocksource/arm_arch_timer.c
> +++ b/drivers/clocksource/arm_arch_timer.c
> @@ -248,14 +248,16 @@ static void __cpuinit arch_timer_stop(struct
> clock_event_device *clk)
>  static int __cpuinit arch_timer_cpu_notify(struct notifier_block *self,
>  					   unsigned long action, void *hcpu)
>  {
> -	struct clock_event_device *evt = this_cpu_ptr(arch_timer_evt);
> -
> +	/*
> +	 * Grab cpu pointer in each case to avoid spurious
> +	 * preemptible warnings
> +	 */
>  	switch (action & ~CPU_TASKS_FROZEN) {
>  	case CPU_STARTING:
> -		arch_timer_setup(evt);
> +		arch_timer_setup(this_cpu_ptr(arch_timer_evt));
>  		break;
>  	case CPU_DYING:
> -		arch_timer_stop(evt);
> +		arch_timer_stop(this_cpu_ptr(arch_timer_evt));
>  		break;
>  	}

Looks good to me.

Acked-by: Marc Zyngier <marc.zyngier at arm.com>

Cheers,

        M.
-- 
Fast, cheap, reliable. Pick two.


From ezequiel.garcia at free-electrons.com  Sat Apr  6 07:15:25 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Sat,  6 Apr 2013 08:15:25 -0300
Subject: [PATCH v3 0/5] Device Bus support for Marvell EBU SoC
Message-ID: <1365246930-13315-1-git-send-email-ezequiel.garcia@free-electrons.com>

Now that the mbus driver has been added to manage address decoding
windows it's possible to introduce the Device Bus driver.
This driver allows to access several memories and I/O devices
such as NOR, NAND, SRAM and FPGAs.

Currently the SoCs that include this Device Bus controller are:

  * Discovery:    mv78100, mv78200
  * Armada XP:    mv78230, mv78260, mv78460
  * Armada 370:   88f6710. 88f6707, 88f6w11
  * Orion 5x:     88f5182, 88f5181, 88f5281

Please note that this patchset adds proper support for
Armada XP and Armada 370 SoC only.

This applies on top of v3.9-rc5 with mbus patches applied, which can 
be found in Jason Cooper's mvebus/soc branch.
If anyone wants to try this, there's a public branch available at:

  https://github.com/MISL-EBU-System-SW/mainline-public/tree/mvebu-devbus-v3

There has been a 'byzantine' discussion regarding the mbus driver DT binding
and the way to describe address windows, and this discussion is still not
settled.

However, since I'd like to see this in v3.10, and the only thing left
to solve seems to be the device tree binding for the mbus window,
this current patchset attempts a temporary workaround.

The decoding windows are handled by the devbus driver, through the mbus API,
using the information present in the 'ranges' property. For instance:

	device-bus at d0010400 {

		ranges = <0 0 0xf0000000 0x8000000>;
		/* ... */
	}

In the above example, when the device bus driver finds a child
node for chip select '0', it will request the mbus driver to allocate a window
as described by the 'ranges' property, starting at address 0xf0000000.

As this approach has been explicitly rejected by the maintainers,
it will be completely removed as soon as the mbus bindings are decided
and the address windows are statically describe in the dts files.

Tested on an Armada XP GP board and Plathome Openblocks AX3.

In particular I'd like to know what's the chance of having this included
for v3.10. If the driver looks good and the temporary window handling
is accepted, then I can prepare a rebased patchset on top of Gregory's
LPAE work, or on top of any other required patches.

Changes from v2:

  * Replace the 'NOR' specific probe by a generic probe.
    Currently, we don't see anything specific to NOR in this driver.
    Suggested by Jason Gunthorpe.

  * Add a check to detect that every timing parameter is specified
    in the device tree node.
    Suggested by Jason Gunthorpe.

Changes from v1:

  * Added a remove() function to unregister childs and remove address windows,
    as suggested by Thomas Petazzoni.

  * Remove unneeded 'inline' prefix on functions as suggested by Thomas Petazzoni.

  * Timings parameters are now mandatory and expressed in picoseconds,
    as requested by Jason Gunthorpe.
    This is consistent with OMAP's GPMC dts binding.

  * Fix documentation as suggested by Jason Gunthorpe.

Thanks!

Ezequiel Garcia (5):
  drivers: memory: Introduce Marvell EBU Device Bus driver
  ARM: mvebu: Add Device Bus support for Armada 370/XP SoC
  ARM: mvebu: Add support for NOR flash device on Armada XP-GP board
  ARM: mvebu: Add support for NOR flash device on Openblocks AX3 board
  ARM: mvebu: Add Device Bus and CFI flash memory support to defconfig

 .../bindings/memory-controllers/mvebu-devbus.txt   | 157 +++++++++
 arch/arm/boot/dts/armada-370.dtsi                  |   8 +
 arch/arm/boot/dts/armada-xp-gp.dts                 |  29 ++
 arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts   |  29 ++
 arch/arm/boot/dts/armada-xp.dtsi                   |   8 +
 arch/arm/configs/mvebu_defconfig                   |   7 +
 drivers/memory/Kconfig                             |  10 +
 drivers/memory/Makefile                            |   1 +
 drivers/memory/mvebu-devbus.c                      | 383 +++++++++++++++++++++
 9 files changed, 632 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/memory-controllers/mvebu-devbus.txt
 create mode 100644 drivers/memory/mvebu-devbus.c

-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Sat Apr  6 07:15:26 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Sat,  6 Apr 2013 08:15:26 -0300
Subject: [PATCH v3 1/5] drivers: memory: Introduce Marvell EBU Device Bus
 driver
In-Reply-To: <1365246930-13315-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1365246930-13315-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1365246930-13315-2-git-send-email-ezequiel.garcia@free-electrons.com>

Marvell EBU SoCs such as Armada 370/XP, Orion5x (88f5xxx) and
Discovery (mv78xx0) supports a Device Bus controller to access several
kinds of memories and I/O devices (NOR, NAND, SRAM, FPGA).

This commit adds a driver to handle this controller. So far only
Armada 370, Armada XP and Discovery SoCs are supported.

The driver must be registered through a device tree node;
as explained in the binding document.

For each child node in the device tree, this driver will:
  * set timing parameters
  * register a child device
  * setup an address decoding window, using the mbus driver

Keep in mind the address decoding window setup is only a temporary hack.
This code will be removed from this devbus driver as soon as a proper device
tree binding for the mbus driver is added.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
---
 .../bindings/memory-controllers/mvebu-devbus.txt   | 157 +++++++++
 drivers/memory/Kconfig                             |  10 +
 drivers/memory/Makefile                            |   1 +
 drivers/memory/mvebu-devbus.c                      | 383 +++++++++++++++++++++
 4 files changed, 551 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/memory-controllers/mvebu-devbus.txt
 create mode 100644 drivers/memory/mvebu-devbus.c

diff --git a/Documentation/devicetree/bindings/memory-controllers/mvebu-devbus.txt b/Documentation/devicetree/bindings/memory-controllers/mvebu-devbus.txt
new file mode 100644
index 0000000..acaf59b
--- /dev/null
+++ b/Documentation/devicetree/bindings/memory-controllers/mvebu-devbus.txt
@@ -0,0 +1,157 @@
+Device tree bindings for MVEBU Device Bus controllers
+
+The Device Bus controller available in some Marvell's SoC allows to control
+different types of standard memory and I/O devices such as NOR, NAND, and FPGA.
+The actual devices are instantiated from the child nodes of a Device Bus node.
+
+Required properties:
+
+ - compatible:          Should be set to one of the following:
+
+                        marvell,armada370-devbus
+                        marvell,armadaxp-devbus
+                        marvell,mv78xx0-devbus
+
+ - reg:                 A resource specifier for the register space
+                        (see the example below)
+ - #address-cells:      Must be set to 2 to allow memory address translation
+ - #size-cells:         Must be set to 1 to allow CS address passing
+ - ranges:              Must be set up to reflect the memory layout with four
+                        integer values for each chip-select line in use:
+                        <cs-number> 0 <physical address of mapping> <size>
+
+Mandatory timing properties for child nodes:
+
+Read parameters:
+
+ - devbus,turn-off-ps:  Defines the time during which the controller does not
+                        drive the AD bus after the completion of a device read.
+                        This prevents contentions on the Device Bus after a read
+                        cycle from a slow device.
+
+ - devbus,dev-width:    0x0 = 8-bit
+                        0x1 = 16-bit
+                        0x2 = 32-bit
+                        0x3 = Reserved
+
+ - devbus,badr-skew-ps: Defines the time delay from from A[2:0] toggle,
+                        to read data sample. This parameter is useful for
+                        synchronous pipelined devices, where the address
+                        precedes the read data by one or two cycles.
+
+ - devbus,acc-first-ps: Defines the time delay from the negation of
+                        ALE[0] to the cycle that the first read data is sampled
+                        by the controller.
+
+ - devbus,acc-next-ps:  Defines the time delay between the cycle that
+                        samples data N and the cycle that samples data N+1
+                        (in burst accesses).
+
+ - devbus,rd-setup-ps:  Defines the time delay between DEV_CSn assertion to
+			DEV_OEn assertion. If set to 0 (default),
+                        DEV_OEn and DEV_CSn are asserted at the same cycle.
+                        This parameter has no affect on <acc-first-ps> parameter
+                        (no affect on first data sample). Set <rd-setup-ps>
+                        to a value smaller than <acc-first-ps>.
+
+ - devbus,rd-hold-ps:   Defines the time between the last data sample to the
+			de-assertion of DEV_CSn. If set to 0 (default),
+			DEV_OEn and DEV_CSn are de-asserted at the same cycle
+			(the cycle of the last data sample).
+                        This parameter has no affect on DEV_OEn de-assertion.
+                        DEV_OEn is always de-asserted the next cycle after
+                        last data sampled. Also this parameter has no
+                        affect on <turn-off-ps> parameter.
+                        Set <rd-hold-ps> to a value smaller than <turn-off-ps>.
+
+Write parameters:
+
+ - devbus,ale-wr-ps:    Defines the time delay from the ALE[0] negation cycle
+			to the DEV_WEn assertion.
+
+ - devbus,wr-low-ps:    Defines the time during which DEV_WEn is active.
+                        A[2:0] and Data are kept valid as long as DEV_WEn
+                        is active. This parameter defines the setup time of
+                        address and data to DEV_WEn rise.
+
+ - devbus,wr-high-ps:   Defines the time during which DEV_WEn is kept
+                        inactive (high) between data beats of a burst write.
+                        DEV_A[2:0] and Data are kept valid (do not toggle) for
+                        <wr-high-ps> - <tick> ps.
+			This parameter defines the hold time of address and
+			data after DEV_WEn rise.
+
+ - devbus,sync-enable: Synchronous device enable.
+                       1: True
+                       0: False
+
+An example for an Armada XP GP board, with a 16 MiB NOR device as child
+is showed below. Note that the Device Bus driver is in charge of allocating
+the mbus address decoding window for each of its child devices.
+The window is created using the chip select specified in the child
+device node together with the base address and size specified in the ranges
+property. For instance, in the example below the allocated decoding window
+will start at base address 0xf0000000, with a size 0x1000000 (16 MiB)
+for chip select 0 (a.k.a DEV_BOOTCS).
+
+This address window handling is done in this mvebu-devbus only as a temporary
+solution. It will be removed when the support for mbus device tree binding is
+added.
+
+The reg property must specify the chip select as:
+
+  0: DEV_BOOTCS
+  1: DEV_CS0
+  2: DEV_CS1
+  3: DEV_CS2
+  4: DEV_CS3
+
+Example:
+
+	device-bus at d0010400 {
+		status = "okay";
+		ranges = <0 0 0xf0000000 0x1000000>; /* CS0 @addr 0xf0000000, size 0x1000000 */
+		#address-cells = <2>;
+		#size-cells = <1>;
+
+		flash at 0 {
+			compatible = "cfi-flash";
+
+			/* CS0, 16 MiB */
+			reg = <0 0 0x1000000>;
+			bank-width = <2>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+
+			/* Device Bus parameters are required */
+
+			/* Read parameters */
+			devbus,dev-width    = <1>;
+			devbus,turn-off-ps  = <60000>;
+			devbus,badr-skew-ps = <0>;
+			devbus,acc-first-ps = <124000>;
+			devbus,acc-next-ps  = <248000>;
+			devbus,rd-setup-ps  = <0>;
+			devbus,rd-hold-ps   = <0>;
+
+			/* Write parameters */
+			devbus,sync-enable = <0>;
+			devbus,wr-high-ps  = <60000>;
+			devbus,wr-low-ps   = <60000>;
+			devbus,ale-wr-ps   = <60000>;
+
+			/*
+			 * We split the 16 MiB in two partitions,
+			 * just as an example.
+			 */
+			partition at 0 {
+				label = "First";
+				reg = <0 0x800000>;
+			};
+
+			partition at 800000 {
+				label = "Second";
+				reg = <0x800000 0x800000>;
+			};
+		};
+	};
diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig
index 067f311..9a81ab3 100644
--- a/drivers/memory/Kconfig
+++ b/drivers/memory/Kconfig
@@ -20,6 +20,16 @@ config TI_EMIF
 	  parameters and other settings during frequency, voltage and
 	  temperature changes
 
+config MVEBU_DEVBUS
+	tristate "Marvell EBU Device Bus Controller"
+	default y
+	depends on PLAT_ORION && OF
+	help
+	  This driver is for the Device Bus controller available in some
+	  Marvell EBU SoCs such as Discovery (mv78xx0), Orion (88f5xxx) and
+	  Armada 370 and Armada XP. This controller allows to handle flash
+	  devices such as NOR, NAND, SRAM, and FPGA.
+
 config TEGRA20_MC
 	bool "Tegra20 Memory Controller(MC) driver"
 	default y
diff --git a/drivers/memory/Makefile b/drivers/memory/Makefile
index 9cce5d7..969d923 100644
--- a/drivers/memory/Makefile
+++ b/drivers/memory/Makefile
@@ -6,5 +6,6 @@ ifeq ($(CONFIG_DDR),y)
 obj-$(CONFIG_OF)		+= of_memory.o
 endif
 obj-$(CONFIG_TI_EMIF)		+= emif.o
+obj-$(CONFIG_MVEBU_DEVBUS)	+= mvebu-devbus.o
 obj-$(CONFIG_TEGRA20_MC)	+= tegra20-mc.o
 obj-$(CONFIG_TEGRA30_MC)	+= tegra30-mc.o
diff --git a/drivers/memory/mvebu-devbus.c b/drivers/memory/mvebu-devbus.c
new file mode 100644
index 0000000..c2d848d
--- /dev/null
+++ b/drivers/memory/mvebu-devbus.c
@@ -0,0 +1,383 @@
+/*
+ * Marvell EBU SoC Device Bus Controller
+ * (memory controller for NOR/NAND/SRAM/FPGA devices)
+ *
+ * Copyright (C) 2013 Marvell
+ *
+ * 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 version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
+ *
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/slab.h>
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/clk.h>
+#include <linux/mbus.h>
+#include <linux/of_platform.h>
+#include <linux/of_address.h>
+#include <linux/platform_device.h>
+
+/* Register definitions */
+#define DEV_WIDTH_BIT		30
+#define BADR_SKEW_BIT		28
+#define RD_HOLD_BIT		23
+#define ACC_NEXT_BIT		17
+#define RD_SETUP_BIT		12
+#define ACC_FIRST_BIT		6
+
+#define SYNC_ENABLE_BIT		24
+#define WR_HIGH_BIT		16
+#define WR_LOW_BIT		8
+
+#define READ_PARAM_OFFSET(cs)	(0x0 + (cs << 3))
+#define WRITE_PARAM_OFFSET(cs)	(0x4 + (cs << 3))
+
+#define DEVBUS_MAXCHILDS_NR	5
+
+static const char * const devbus_wins[] = {
+	"devbus-boot",
+	"devbus-cs0",
+	"devbus-cs1",
+	"devbus-cs2",
+	"devbus-cs3",
+};
+
+struct devbus_read_params {
+	u32 dev_width;
+	u32 badr_skew;
+	u32 turn_off;
+	u32 acc_first;
+	u32 acc_next;
+	u32 rd_setup;
+	u32 rd_hold;
+};
+
+struct devbus_write_params {
+	u32 sync_enable;
+	u32 wr_high;
+	u32 wr_low;
+	u32 ale_wr;
+};
+
+struct devbus_child {
+	struct platform_device *pdev;
+	struct resource mem_res;
+};
+
+struct devbus {
+	struct device *dev;
+	void __iomem *base;
+	unsigned long tick_ps;
+
+	struct devbus_child childs[DEVBUS_MAXCHILDS_NR];
+};
+
+static int get_timing_param_ps(struct devbus *devbus,
+			       struct device_node *node,
+			       const char *name,
+			       u32 *ticks)
+{
+	u32 time_ps;
+	int err;
+
+	err = of_property_read_u32(node, name, &time_ps);
+	if (err < 0) {
+		dev_err(devbus->dev, "%s has no '%s' property\n",
+			name, node->full_name);
+		return err;
+	}
+
+	*ticks = (time_ps + devbus->tick_ps - 1) / devbus->tick_ps;
+
+	dev_dbg(devbus->dev, "%s: %u ps -> 0x%x\n",
+		name, time_ps, *ticks);
+	return 0;
+}
+
+static int devbus_set_timing_params(struct devbus *devbus,
+				    struct device_node *node,
+				    int cs)
+{
+	struct devbus_read_params r;
+	struct devbus_write_params w;
+	u32 value;
+	int err;
+
+	dev_dbg(devbus->dev, "Setting timing parameter, tick is %lu ps\n",
+		devbus->tick_ps);
+
+	/* Get read timings */
+	err = of_property_read_u32(node, "devbus,dev-width", &r.dev_width);
+	if (err < 0) {
+		dev_err(devbus->dev,
+			"%s has no 'devbus,dev-width' property\n",
+			node->full_name);
+		return err;
+	}
+
+	err = get_timing_param_ps(devbus, node, "devbus,badr-skew-ps",
+				 &r.badr_skew);
+	if (err < 0)
+		return err;
+
+	err = get_timing_param_ps(devbus, node, "devbus,turn-off-ps",
+				 &r.turn_off);
+	if (err < 0)
+		return err;
+
+	err = get_timing_param_ps(devbus, node, "devbus,acc-first-ps",
+				 &r.acc_first);
+	if (err < 0)
+		return err;
+
+	err = get_timing_param_ps(devbus, node, "devbus,acc-next-ps",
+				 &r.acc_next);
+	if (err < 0)
+		return err;
+
+	err = get_timing_param_ps(devbus, node, "devbus,rd-setup-ps",
+				 &r.rd_setup);
+	if (err < 0)
+		return err;
+
+	err = get_timing_param_ps(devbus, node, "devbus,rd-hold-ps",
+				 &r.rd_hold);
+	if (err < 0)
+		return err;
+
+	/* Get write timings */
+	err = of_property_read_u32(node, "devbus,sync-enable",
+				  &w.sync_enable);
+	if (err < 0) {
+		dev_err(devbus->dev,
+			"%s has no 'devbus,sync-enable' property\n",
+			node->full_name);
+		return err;
+	}
+
+	err = get_timing_param_ps(devbus, node, "devbus,ale-wr-ps",
+				 &w.ale_wr);
+	if (err < 0)
+		return err;
+
+	err = get_timing_param_ps(devbus, node, "devbus,wr-low-ps",
+				 &w.wr_low);
+	if (err < 0)
+		return err;
+
+	err = get_timing_param_ps(devbus, node, "devbus,wr-high-ps",
+				 &w.wr_high);
+	if (err < 0)
+		return err;
+
+	/* Set read timings */
+	value = r.dev_width << DEV_WIDTH_BIT |
+		r.badr_skew << BADR_SKEW_BIT |
+		r.rd_hold   << RD_HOLD_BIT   |
+		r.acc_next  << ACC_NEXT_BIT  |
+		r.rd_setup  << RD_SETUP_BIT  |
+		r.acc_first << ACC_FIRST_BIT |
+		r.turn_off;
+
+	dev_dbg(devbus->dev, "CS%d read parameters register 0x%p = 0x%x\n",
+		cs, devbus->base + READ_PARAM_OFFSET(cs),
+		value);
+
+	writel(value, devbus->base + READ_PARAM_OFFSET(cs));
+
+	/* Set write timings */
+	value = w.sync_enable  << SYNC_ENABLE_BIT |
+		w.wr_low       << WR_LOW_BIT      |
+		w.wr_high      << WR_HIGH_BIT     |
+		w.ale_wr;
+
+	dev_dbg(devbus->dev, "CS%d write parameters register: 0x%p = 0x%x\n",
+		cs, devbus->base + WRITE_PARAM_OFFSET(cs),
+		value);
+
+	writel(value, devbus->base + WRITE_PARAM_OFFSET(cs));
+
+	return 0;
+}
+
+static int devbus_probe_child(struct devbus *devbus,
+			      struct platform_device *pdev,
+			      struct device_node *node)
+{
+	struct device *dev = &pdev->dev;
+	struct devbus_child *child;
+	int err;
+	int bank_width;
+	u32 cs;
+
+	/* Read chip select and size */
+	if (of_property_read_u32(node, "reg", &cs) < 0) {
+		dev_err(dev, "%s has no 'reg' property\n", node->full_name);
+		return -EINVAL;
+	}
+
+	/* Sanity checks */
+	if (cs >= DEVBUS_MAXCHILDS_NR)
+		return -ENODEV;
+
+	if (devbus->childs[cs].pdev)
+		return -EBUSY;
+
+	child = &devbus->childs[cs];
+
+	if (of_address_to_resource(node, 0, &child->mem_res)) {
+		dev_err(dev, "%s has malformed 'reg' property\n",
+			node->full_name);
+		return -EINVAL;
+	}
+
+	err = of_property_read_u32(node, "bank-width", &bank_width);
+	if (err) {
+		dev_err(dev, "error %d reading bank-width property\n", err);
+		return err;
+	}
+
+	/* Read the device tree child node and set the new parameters */
+	err = devbus_set_timing_params(devbus, node, cs);
+	if (err < 0)
+		return err;
+
+	/*
+	 * Allocate an address window for this device.
+	 * If the device probing fails, then we won't be able to
+	 * remove the allocated address decoding window.
+	 *
+	 * FIXME: This is only a temporary hack! We need to do this here
+	 * because we still don't have device tree bindings for mbus.
+	 * Once that support is added, we will declare these address windows
+	 * statically in the device tree, and remove the window configuration
+	 * from here.
+	 */
+	err = mvebu_mbus_add_window(devbus_wins[cs], child->mem_res.start,
+				    resource_size(&child->mem_res));
+	if (err < 0)
+		return err;
+
+	/*
+	 * If we manage to set 'simple-bus' compatible string
+	 * to device-bus node, then we don't really need this.
+	 */
+	child->pdev = of_platform_device_create(node, NULL, &pdev->dev);
+	if (!child->pdev) {
+		dev_warn(dev, "cannot create child device %s\n", node->name);
+		/* Remove the allocated window */
+		mvebu_mbus_del_window(child->mem_res.start,
+				      resource_size(&child->mem_res));
+	}
+
+	return 0;
+}
+
+static int mvebu_devbus_probe(struct platform_device *pdev)
+{
+	struct device_node *child;
+	struct devbus *devbus;
+	struct resource *res;
+	struct clk *clk;
+	unsigned long rate;
+	int err;
+
+	devbus = devm_kzalloc(&pdev->dev, sizeof(struct devbus), GFP_KERNEL);
+	if (!devbus)
+		return -ENOMEM;
+
+	devbus->dev = &pdev->dev;
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	devbus->base = devm_ioremap_resource(&pdev->dev, res);
+	if (IS_ERR(devbus->base))
+		return PTR_ERR(devbus->base);
+
+	clk = devm_clk_get(&pdev->dev, NULL);
+	if (IS_ERR(clk))
+		return PTR_ERR(clk);
+	clk_prepare_enable(clk);
+
+	/*
+	 * Obtain clock period in picoseconds,
+	 * we need this in order to convert timing
+	 * parameters from cycles to picoseconds.
+	 */
+	rate = clk_get_rate(clk) / 1000;
+	devbus->tick_ps = 1000000000 / rate;
+
+	for_each_child_of_node(pdev->dev.of_node, child) {
+		err = devbus_probe_child(devbus, pdev, child);
+		if (err < 0) {
+			of_node_put(child);
+			return err;
+		}
+	}
+
+	platform_set_drvdata(pdev, devbus);
+
+	return 0;
+}
+
+static int mvebu_devbus_remove(struct platform_device *pdev)
+{
+	int i;
+	struct devbus *devbus = platform_get_drvdata(pdev);
+
+	for (i = 0; i < DEVBUS_MAXCHILDS_NR; i++) {
+		struct devbus_child *child;
+
+		if (!devbus->childs[i].pdev)
+			continue;
+
+		child = &devbus->childs[i];
+
+		/* Release device */
+		of_device_unregister(child->pdev);
+
+		/* Release window */
+		mvebu_mbus_del_window(child->mem_res.start,
+				      resource_size(&child->mem_res));
+
+		child->pdev = NULL;
+	}
+
+	platform_set_drvdata(pdev, NULL);
+
+	return 0;
+}
+
+/* Perhaps it makes sense to unify both compatible strins? */
+static const struct of_device_id mvebu_devbus_of_match[] = {
+	{ .compatible = "marvell,armada370-devbus"	 },
+	{ .compatible = "marvell,armadaxp-devbus"	 },
+	{},
+};
+MODULE_DEVICE_TABLE(of, mvebu_devbus_of_match);
+
+static struct platform_driver mvebu_devbus_driver = {
+	.probe		= mvebu_devbus_probe,
+	.remove		= mvebu_devbus_remove,
+	.driver		= {
+		.name	= "mvebu-devbus",
+		.owner	= THIS_MODULE,
+		.of_match_table = mvebu_devbus_of_match,
+	},
+};
+
+module_platform_driver(mvebu_devbus_driver);
+
+MODULE_LICENSE("GPL v2");
+MODULE_AUTHOR("Ezequiel Garcia <ezequiel.garcia at free-electrons.com>");
+MODULE_DESCRIPTION("Marvell EBU SoC Device Bus controller");
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Sat Apr  6 07:15:27 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Sat,  6 Apr 2013 08:15:27 -0300
Subject: [PATCH v3 2/5] ARM: mvebu: Add Device Bus support for Armada 370/XP
 SoC
In-Reply-To: <1365246930-13315-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1365246930-13315-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1365246930-13315-3-git-send-email-ezequiel.garcia@free-electrons.com>

Armada 370 and Armada XP SoC have a Device Bus controller to
handle NOR, NAND, SRAM and FPGA devices.
This patch adds the device tree node to enable the controller.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
---
 arch/arm/boot/dts/armada-370.dtsi | 8 ++++++++
 arch/arm/boot/dts/armada-xp.dtsi  | 8 ++++++++
 2 files changed, 16 insertions(+)

diff --git a/arch/arm/boot/dts/armada-370.dtsi b/arch/arm/boot/dts/armada-370.dtsi
index 8188d13..c40358c 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -153,5 +153,13 @@
 			clocks = <&coreclk 0>;
 		};
 
+		device-bus at d0010400 {
+			compatible = "marvell,armada370-devbus";
+			reg = <0xd0010400 0xe0>;
+			#address-cells = <2>;
+			#size-cells = <1>;
+			clocks = <&coreclk 0>;
+			status = "disabled";
+		};
 	};
 };
diff --git a/arch/arm/boot/dts/armada-xp.dtsi b/arch/arm/boot/dts/armada-xp.dtsi
index ca00d83..0c56cca 100644
--- a/arch/arm/boot/dts/armada-xp.dtsi
+++ b/arch/arm/boot/dts/armada-xp.dtsi
@@ -151,5 +151,13 @@
 			status = "disabled";
 		};
 
+		device-bus at d0010400 {
+			compatible = "marvell,armadaxp-devbus";
+			reg = <0xd0010400 0xe0>;
+			#address-cells = <2>;
+			#size-cells = <1>;
+			clocks = <&coreclk 0>;
+			status = "disabled";
+		};
 	};
 };
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Sat Apr  6 07:15:28 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Sat,  6 Apr 2013 08:15:28 -0300
Subject: [PATCH v3 3/5] ARM: mvebu: Add support for NOR flash device on Armada
 XP-GP board
In-Reply-To: <1365246930-13315-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1365246930-13315-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1365246930-13315-4-git-send-email-ezequiel.garcia@free-electrons.com>

The Armada XP Development Board DB-MV784MP-GP has a NOR flash device
connected to the Device Bus. This commit adds the device tree node
to support this device.

This SoC supports a flexible and dynamic decoding window allocation
scheme; but since this feature is still not implemented we need
to specify the window base address in the device tree node itself.

This base address has been selected in a completely arbitrary fashion.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
---
 arch/arm/boot/dts/armada-xp-gp.dts | 29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)

diff --git a/arch/arm/boot/dts/armada-xp-gp.dts b/arch/arm/boot/dts/armada-xp-gp.dts
index 1c8afe2..a2c3862 100644
--- a/arch/arm/boot/dts/armada-xp-gp.dts
+++ b/arch/arm/boot/dts/armada-xp-gp.dts
@@ -109,5 +109,34 @@
 				spi-max-frequency = <108000000>;
 			};
 		};
+
+		device-bus at d0010400 {
+			status = "okay";
+			ranges = <0 0 0xf0000000 0x01000000>; /* CS0 @addr 0xf000000, size 0x1000000 */
+
+			/* CS0, 16 MiB */
+			nor at 0 {
+				compatible = "cfi-flash";
+				reg = <0 0 0x01000000>;
+				bank-width = <2>;
+
+				/* Device Bus parameters are required */
+
+				/* Read parameters */
+				devbus,dev-width    = <1>;
+				devbus,turn-off-ps  = <60000>;
+				devbus,badr-skew-ps = <0>;
+				devbus,acc-first-ps = <124000>;
+				devbus,acc-next-ps  = <248000>;
+				devbus,rd-setup-ps  = <0>;
+				devbus,rd-hold-ps   = <0>;
+
+				/* Write parameters */
+				devbus,sync-enable = <0>;
+				devbus,wr-high-ps  = <60000>;
+				devbus,wr-low-ps   = <60000>;
+				devbus,ale-wr-ps   = <60000>;
+			};
+		};
 	};
 };
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Sat Apr  6 07:15:29 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Sat,  6 Apr 2013 08:15:29 -0300
Subject: [PATCH v3 4/5] ARM: mvebu: Add support for NOR flash device on
 Openblocks AX3 board
In-Reply-To: <1365246930-13315-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1365246930-13315-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1365246930-13315-5-git-send-email-ezequiel.garcia@free-electrons.com>

The Plat'home Openblocks AX3 has a 128 MiB NOR flash device connected
to the Device Bus. This commit adds the device tree node to support this device.

The SoC supports a flexible and dynamic decoding window allocation scheme;
but since this feature is still not implemented we need to specify the window
base address in the device tree node itself.
This base address has been selected in a completely arbitrary fashion.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
---
 arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 29 ++++++++++++++++++++++++
 1 file changed, 29 insertions(+)

diff --git a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
index 3818a82..53ad2a6 100644
--- a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
+++ b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
@@ -139,5 +139,34 @@
 		usb at d0051000 {
 			status = "okay";
 		};
+
+		device-bus at d0010400 {
+			status = "okay";
+			ranges = <0 0 0xf0000000 0x8000000>; /* CS0 @addr 0xf000000, size 0x8000000 */
+
+			/* CS0, 128 MiB */
+			nor at 0 {
+				compatible = "cfi-flash";
+				reg = <0 0 0x8000000>;
+				bank-width = <2>;
+
+				/* Device Bus parameters are required */
+
+				/* Read parameters */
+				devbus,dev-width    = <1>;
+				devbus,turn-off-ps  = <60000>;
+				devbus,badr-skew-ps = <0>;
+				devbus,acc-first-ps = <124000>;
+				devbus,acc-next-ps  = <248000>;
+				devbus,rd-setup-ps  = <0>;
+				devbus,rd-hold-ps   = <0>;
+
+				/* Write parameters */
+				devbus,sync-enable = <0>;
+				devbus,wr-high-ps  = <60000>;
+				devbus,wr-low-ps   = <60000>;
+				devbus,ale-wr-ps   = <60000>;
+			};
+		};
 	};
 };
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Sat Apr  6 07:15:30 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Sat,  6 Apr 2013 08:15:30 -0300
Subject: [PATCH v3 5/5] ARM: mvebu: Add Device Bus and CFI flash memory
 support to defconfig
In-Reply-To: <1365246930-13315-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1365246930-13315-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1365246930-13315-6-git-send-email-ezequiel.garcia@free-electrons.com>

This patch selects the devbus driver as part of the mvebu default
config, along with the required options to detect and support
CFI flash memories.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
---
 arch/arm/configs/mvebu_defconfig | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/configs/mvebu_defconfig b/arch/arm/configs/mvebu_defconfig
index 2ec8119..fe8ba26 100644
--- a/arch/arm/configs/mvebu_defconfig
+++ b/arch/arm/configs/mvebu_defconfig
@@ -46,6 +46,11 @@ CONFIG_I2C_MV64XXX=y
 CONFIG_MTD=y
 CONFIG_MTD_CHAR=y
 CONFIG_MTD_M25P80=y
+CONFIG_MTD_CFI=y
+CONFIG_MTD_CFI_INTELEXT=y
+CONFIG_MTD_CFI_AMDSTD=y
+CONFIG_MTD_CFI_STAA=y
+CONFIG_MTD_PHYSMAP_OF=y
 CONFIG_SERIAL_8250_DW=y
 CONFIG_GPIOLIB=y
 CONFIG_GPIO_SYSFS=y
@@ -65,6 +70,8 @@ CONFIG_RTC_DRV_S35390A=y
 CONFIG_RTC_DRV_MV=y
 CONFIG_DMADEVICES=y
 CONFIG_MV_XOR=y
+CONFIG_MEMORY=y
+CONFIG_MVEBU_DEVBUS=y
 # CONFIG_IOMMU_SUPPORT is not set
 CONFIG_EXT2_FS=y
 CONFIG_EXT3_FS=y
-- 
1.8.1.5



From arnd at arndb.de  Sat Apr  6 07:51:00 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Sat, 6 Apr 2013 13:51:00 +0200
Subject: [RFC PATCH arm: initial TI-Nspire support]
In-Reply-To: <8FB21B56-58BC-4530-8C7A-71A32856210D@gmail.com>
References: <6FE4B33E-A503-4A75-AEED-831CB2C06D83@gmail.com>
 <201304041112.25780.arnd@arndb.de>
 <8FB21B56-58BC-4530-8C7A-71A32856210D@gmail.com>
Message-ID: <201304061351.00889.arnd@arndb.de>

On Saturday 06 April 2013, Daniel Tang wrote:
> Hi,
> 
> First of all, thank you for your comments!
> 
> On 04/04/2013, at 10:12 PM, Arnd Bergmann <arnd at arndb.de> wrote:
> 
> > For new platforms, we want to have only the absolute minimum amount of
> > code in arch/arm and move everything else into drivers. However, that
> > is only possible using device tree. It should not add any significant
> > complexity to your code, and you can easily bundle the device tree blob
> > with the kernel.
> 
> Given that most of your comments described some very fundamental changes
> (esp switching to DTB) to the structure of our port, we've decided we'll
> probably start from scratch and fix the issues you outlined as we
> reimplement our platform.
> 
> At the moment, we're working on getting a basic DTB-booting kernel working
> so our next patch will be starting from basics.

Ok, whichever way you prefer. If you have questions while working on this,
feel free to join #armlinux on irc.freenode.net, there are usually other
people working on the same things.

	Arnd


From dt.tangr at gmail.com  Sat Apr  6 08:00:15 2013
From: dt.tangr at gmail.com (Daniel Tang)
Date: Sat, 6 Apr 2013 23:00:15 +1100
Subject: [RFC PATCH arm: initial TI-Nspire support]
In-Reply-To: <201304061351.00889.arnd@arndb.de>
References: <6FE4B33E-A503-4A75-AEED-831CB2C06D83@gmail.com>
 <201304041112.25780.arnd@arndb.de>
 <8FB21B56-58BC-4530-8C7A-71A32856210D@gmail.com>
 <201304061351.00889.arnd@arndb.de>
Message-ID: <F832F4F9-8162-43B8-B9E0-D5D8C8B8C77A@gmail.com>

Hi,


On 06/04/2013, at 10:51 PM, Arnd Bergmann <arnd at arndb.de> wrote:
> 
> Ok, whichever way you prefer. If you have questions while working on this,
> feel free to join #armlinux on irc.freenode.net, there are usually other
> people working on the same things.
> 

Cheers.

We already have something basic that boots successfully using device trees. 

Some comments before we continue would be greatly appreciated.

Signed-off-by: Daniel Tang <dt.tangr at gmail.com>
---
 arch/arm/Kconfig                                |   13 ++
 arch/arm/Makefile                               |    3 +-
 arch/arm/boot/dts/nspire-cx.dts                 |   85 +++++++++++++
 arch/arm/boot/dts/nspire.dtsi                   |  154 +++++++++++++++++++++++
 arch/arm/mach-nspire/Makefile                   |    3 +
 arch/arm/mach-nspire/include/mach/debug-macro.S |   25 ++++
 arch/arm/mach-nspire/include/mach/timex.h       |   15 +++
 arch/arm/mach-nspire/include/mach/uncompress.h  |   25 ++++
 arch/arm/mach-nspire/mmio.h                     |   13 ++
 arch/arm/mach-nspire/nspire.c                   |  107 ++++++++++++++++
 10 files changed, 442 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/nspire-cx.dts
 create mode 100644 arch/arm/boot/dts/nspire.dtsi
 create mode 100644 arch/arm/mach-nspire/Makefile
 create mode 100644 arch/arm/mach-nspire/Makefile.boot
 create mode 100644 arch/arm/mach-nspire/include/mach/debug-macro.S
 create mode 100644 arch/arm/mach-nspire/include/mach/timex.h
 create mode 100644 arch/arm/mach-nspire/include/mach/uncompress.h
 create mode 100644 arch/arm/mach-nspire/mmio.h
 create mode 100644 arch/arm/mach-nspire/nspire.c

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 1cacda4..e8ce316 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -980,6 +980,19 @@ config ARCH_OMAP1
 	help
 	  Support for older TI OMAP1 (omap7xx, omap15xx or omap16xx)
 
+config ARCH_NSPIRE
+	bool "TI-NSPIRE based"
+	depends on MMU
+	select CPU_ARM926T
+	select COMMON_CLK
+	select GENERIC_CLOCKEVENTS
+	select SPARSE_IRQ
+	select ARM_AMBA
+	select ARM_VIC
+	select ARM_TIMER_SP804
+	help
+	  This enables support for systems using the TI-NSPIRE CPU
+
 endchoice
 
 menu "Multiple platform selection"
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index ee4605f..f47a8a7 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -165,6 +165,7 @@ machine-$(CONFIG_ARCH_MXS)		+= mxs
 machine-$(CONFIG_ARCH_MVEBU)		+= mvebu
 machine-$(CONFIG_ARCH_NETX)		+= netx
 machine-$(CONFIG_ARCH_NOMADIK)		+= nomadik
+machine-$(CONFIG_ARCH_NSPIRE)		+= nspire
 machine-$(CONFIG_ARCH_OMAP1)		+= omap1
 machine-$(CONFIG_ARCH_OMAP2PLUS)	+= omap2
 machine-$(CONFIG_ARCH_ORION5X)		+= orion5x
@@ -313,7 +314,7 @@ define archhelp
   echo  '  Image         - Uncompressed kernel image (arch/$(ARCH)/boot/Image)'
   echo  '* xipImage      - XIP kernel image, if configured (arch/$(ARCH)/boot/xipImage)'
   echo  '  uImage        - U-Boot wrapped zImage'
-  echo  '  bootpImage    - Combined zImage and initial RAM disk' 
+  echo  '  bootpImage    - Combined zImage and initial RAM disk'
   echo  '                  (supply initrd image via make variable INITRD=<path>)'
   echo  '* dtbs          - Build device tree blobs for enabled boards'
   echo  '  install       - Install uncompressed kernel'
diff --git a/arch/arm/boot/dts/nspire-cx.dts b/arch/arm/boot/dts/nspire-cx.dts
new file mode 100644
index 0000000..6ab3c00
--- /dev/null
+++ b/arch/arm/boot/dts/nspire-cx.dts
@@ -0,0 +1,85 @@
+/*
+ *  linux/arch/arm/boot/nspire-cx.dts
+ *
+ *  Copyright (C) 2012 Daniel Tang <tangrs at tangrs.id.au>
+ *
+ * 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.
+ *
+ */
+/dts-v1/;
+
+/include/ "nspire.dtsi"
+
+/ {
+	model = "TI-NSPIRE CX";
+	compatible = "arm,nspire-cx";
+
+	memory {
+		device_type = "memory";
+		reg = <0x10000000 0x4000000>; /* 64 MB */
+	};
+
+	aliases {
+		uart0 = &uart0;
+		timer0 = &timer0;
+		timer1 = &timer1;
+		fast_timer = &fast_timer;
+	};
+
+	uart_clk: uart_clk {
+		#clock-cells = <0>;
+		compatible = "fixed-clock";
+		clock-frequency = <12000000>;
+	};
+
+	/* Not really a fixed clock but we'll fix this later */
+	apb_pclk: apb_pclk {
+		#clock-cells = <0>;
+		compatible = "fixed-clock";
+		clock-frequency = <33000000>;
+	};
+
+	ahb {
+		#address-cells = <1>;
+		#size-cells = <1>;
+
+		intc: interrupt-controller at DC000000 {
+			compatible = "arm,pl190-vic";
+			interrupt-controller;
+			reg = <0xDC000000 0x1000>;
+			#interrupt-cells = <1>;
+		};
+
+		apb at 90000000 {
+			#address-cells = <1>;
+			#size-cells = <1>;
+
+			i2c at 90050000 {
+				compatible = "snps,designware-i2c";
+				reg = <0x90050000 0x1000>;
+				interrupts = <20>;
+			};
+
+			fast_timer: timer at 90010000 {
+				compatible = "arm,sp804", "arm,primecell";
+			};
+
+			uart0: uart at 90020000 {
+				compatible = "arm,pl011", "arm,primecell";
+			};
+
+			timer0: timer0 at 900C0000 {
+				compatible = "arm,sp804", "arm,primecell";
+			};
+
+			timer1: timer1 at 900D0000 {
+				compatible = "arm,sp804", "arm,primecell";
+			};
+		};
+	};
+	chosen {
+		bootargs = "debug earlyprintk console=ttyAMA0,115200n8";
+	};
+};
diff --git a/arch/arm/boot/dts/nspire.dtsi b/arch/arm/boot/dts/nspire.dtsi
new file mode 100644
index 0000000..db7584a
--- /dev/null
+++ b/arch/arm/boot/dts/nspire.dtsi
@@ -0,0 +1,154 @@
+/*
+ *  linux/arch/arm/boot/nspire.dtsi
+ *
+ *  Copyright (C) 2012 Daniel Tang <tangrs at tangrs.id.au>
+ *
+ * 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/ "skeleton.dtsi"
+
+/ {
+	cpus {
+		cpu at 0 {
+			compatible = "arm,arm926";
+		};
+	};
+
+	bootrom: bootrom at 00000000 {
+		reg = <0x00000000 0x80000>;
+	};
+
+	sram: sram at A4000000 {
+		device = "memory";
+		reg = <0xA4000000 0x20000>;
+	};
+
+	timer_clk: timer_clk {
+		#clock-cells = <0>;
+		compatible = "fixed-clock";
+		clock-frequency = <32768>;
+	};
+
+	ahb {
+		compatible = "arm,amba-bus", "simple-bus";
+		interrupt-parent = <&intc>;
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges;
+
+		spi: spi at A9000000 {
+			reg = <0xA9000000 0x1000>;
+		};
+
+		usb0: usb at B0000000 {
+			reg = <0xB0000000 0x1000>;
+			interrupts = <8>;
+		};
+
+		usb1: usb at B4000000 {
+			reg = <0xB4000000 0x1000>;
+			interrupts = <9>;
+			status = "disabled";
+		};
+
+		lcd: lcd at C0000000 {
+			compatible = "arm,amba-primecell";
+			reg = <0xC0000000 0x1000>;
+			interrupts = <21>;
+		};
+
+		adc: adc at C4000000 {
+			reg = <0xC4000000 0x1000>;
+			interrupts = <11>;
+		};
+
+		tdes: tdes at C8010000 {
+			reg = <0xC8010000 0x1000>;
+		};
+
+		sha256: sha256 at CC000000 {
+			reg = <0xCC000000 0x1000>;
+		};
+
+		apb at 90000000 {
+			compatible = "arm,amba-bus", "simple-bus";
+			#address-cells = <1>;
+			#size-cells = <1>;
+			clocks = <&apb_pclk>;
+			clock-names = "apb_pclk";
+			clock-ranges;
+			ranges;
+
+			gpio: gpio at 90000000 {
+				reg = <0x90000000 0x1000>;
+				interrupts = <7>;
+			};
+
+			fast_timer: timer at 90010000 {
+				reg = <0x90010000 0x1000>;
+				interrupts = <17>;
+			};
+
+			uart: uart at 90020000 {
+				reg = <0x90020000 0x1000>;
+				interrupts = <1>;
+
+				clocks = <&uart_clk>;
+				clock-names = "uart_clk";
+			};
+
+			timer0: timer0 at 900C0000 {
+				reg = <0x900C0000 0x1000>;
+				interrupts = <18>;
+
+				clocks = <&timer_clk>;
+				clock-names = "timer_clk";
+			};
+
+			timer1: timer1 at 900D0000 {
+				reg = <0x900D0000 0x1000>;
+				interrupts = <19>;
+
+				clocks = <&timer_clk>;
+				clock-names = "timer_clk";
+			};
+
+			watchdog: watchdog at 90060000 {
+				compatible = "arm,amba-primecell";
+				reg = <0x90060000 0x1000>;
+				interrupts = <3>;
+			};
+
+			rtc: rtc at 90090000 {
+				reg = <0x90090000 0x1000>;
+				interrupts = <4>;
+			};
+
+			misc: misc at 900A0000 {
+				reg = <0x900A0000 0x1000>;
+			};
+
+			pwr: pwr at 900B0000 {
+				reg = <0x900B0000 0x1000>;
+				interrupts = <15>;
+			};
+
+			keypad: input at 900E0000 {
+				reg = <0x900E0000 0x1000>;
+				interrupts = <16>;
+			};
+
+			contrast: contrast at 900F0000 {
+				reg = <0x900F0000 0x1000>;
+			};
+
+			led: led at 90110000 {
+				reg = <0x90110000 0x1000>;
+			};
+		};
+	};
+};
diff --git a/arch/arm/mach-nspire/Makefile b/arch/arm/mach-nspire/Makefile
new file mode 100644
index 0000000..62b9baa
--- /dev/null
+++ b/arch/arm/mach-nspire/Makefile
@@ -0,0 +1,3 @@
+obj-y				:=
+
+obj-y				+= nspire.o
diff --git a/arch/arm/mach-nspire/Makefile.boot b/arch/arm/mach-nspire/Makefile.boot
new file mode 100644
index 0000000..e69de29
diff --git a/arch/arm/mach-nspire/include/mach/debug-macro.S b/arch/arm/mach-nspire/include/mach/debug-macro.S
new file mode 100644
index 0000000..d583485
--- /dev/null
+++ b/arch/arm/mach-nspire/include/mach/debug-macro.S
@@ -0,0 +1,25 @@
+/*
+ *	linux/arch/arm/mach-nspire/include/mach/debug-macro.S
+ *
+ *	Copyright (C) 2012 Daniel Tang <tangrs at tangrs.id.au>
+ *
+ * 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 "../../mmio.h"
+
+.macro	addruart, rp, rv, tmp
+	ldr \rp, =(NSPIRE_EARLY_UART_PHYS_BASE)		@ physical base address
+	ldr \rv, =(NSPIRE_EARLY_UART_VIRT_BASE)		@ virtual base address
+.endm
+
+#include <asm/hardware/debug-pl01x.S>
+
+
+/*
+#define UART_SHIFT 2
+#include <asm/hardware/debug-8250.S>
+*/
diff --git a/arch/arm/mach-nspire/include/mach/timex.h b/arch/arm/mach-nspire/include/mach/timex.h
new file mode 100644
index 0000000..2d4449e
--- /dev/null
+++ b/arch/arm/mach-nspire/include/mach/timex.h
@@ -0,0 +1,15 @@
+/*
+ *  linux/arch/arm/mach-nspire/include/mach/timex.h
+ *
+ *  Copyright (C) 2012 Daniel Tang <tangrs at tangrs.id.au>
+ *
+ * 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.
+ *
+ */
+
+#ifndef NSPIRE_TIMEX_H
+#define NSPIRE_TIMEX_H
+
+#endif
diff --git a/arch/arm/mach-nspire/include/mach/uncompress.h b/arch/arm/mach-nspire/include/mach/uncompress.h
new file mode 100644
index 0000000..d957214
--- /dev/null
+++ b/arch/arm/mach-nspire/include/mach/uncompress.h
@@ -0,0 +1,25 @@
+/*
+ *	linux/arch/arm/mach-nspire/include/mach/uncompress.h
+ *
+ *	Copyright (C) 2012 Daniel Tang <tangrs at tangrs.id.au>
+ *	Copyright (C) 2013 Lionel Debroux <lionel_debroux at yahoo.fr>
+ *
+ * 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.
+ *
+ */
+
+#ifndef NSPIRE_UNCOMPRESS_H
+#define NSPIRE_UNCOMPRESS_H
+
+#define OFFSET_VAL(var, offset) ((var)[(offset)>>2])
+static inline void putc(int c)
+{
+}
+#undef OFFSET_VAL
+
+#define arch_decomp_setup()
+#define flush()
+
+#endif
diff --git a/arch/arm/mach-nspire/mmio.h b/arch/arm/mach-nspire/mmio.h
new file mode 100644
index 0000000..6e2fe95
--- /dev/null
+++ b/arch/arm/mach-nspire/mmio.h
@@ -0,0 +1,13 @@
+/*
+ *	linux/arch/arm/mach-nspire/mmio.h
+ *
+ *	Copyright (C) 2012 Daniel Tang <tangrs at tangrs.id.au>
+ *
+ * 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.
+ *
+ */
+
+#define NSPIRE_EARLY_UART_PHYS_BASE	   0x90020000
+#define NSPIRE_EARLY_UART_VIRT_BASE	   0xfee20000
diff --git a/arch/arm/mach-nspire/nspire.c b/arch/arm/mach-nspire/nspire.c
new file mode 100644
index 0000000..ec7734a
--- /dev/null
+++ b/arch/arm/mach-nspire/nspire.c
@@ -0,0 +1,107 @@
+/*
+ *	linux/arch/arm/mach-nspire/nspire.c
+ *
+ *	Copyright (C) 2012 Daniel Tang <tangrs at tangrs.id.au>
+ *
+ * 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/init.h>
+#include <linux/of_irq.h>
+#include <linux/of_address.h>
+#include <linux/of_platform.h>
+#include <linux/irqchip.h>
+#include <linux/irqchip/arm-vic.h>
+#include <linux/clk-provider.h>
+#include <linux/clkdev.h>
+
+#include <asm/mach/arch.h>
+#include <asm/mach-types.h>
+#include <asm/mach/map.h>
+
+#include <asm/hardware/timer-sp.h>
+
+#include "mmio.h"
+
+static const char *nspire_dt_match[] __initconst = {
+	"arm,nspire",
+	"arm,nspire-cx",
+	"arm,nspire-tp",
+	"arm,nspire-clp",
+	NULL,
+};
+
+static struct map_desc nspire_io_desc[] __initdata = {
+	{
+		.virtual	=  NSPIRE_EARLY_UART_VIRT_BASE,
+		.pfn		= __phys_to_pfn(NSPIRE_EARLY_UART_PHYS_BASE),
+		.length		= SZ_4K,
+		.type		= MT_DEVICE
+	}
+};
+
+static void __init nspire_init_timer(void)
+{
+	struct device_node *timer;
+	void __iomem *base;
+	const char *path;
+	struct clk *clk;
+	int irq, err;
+
+	of_clk_init(NULL);
+
+	err = of_property_read_string(of_aliases, "timer0", &path);
+	if (WARN_ON(err))
+		return;
+
+	timer = of_find_node_by_path(path);
+	base = of_iomap(timer, 0);
+	if (WARN_ON(!base))
+		return;
+
+	clk = of_clk_get_by_name(timer, NULL);
+	clk_register_clkdev(clk, timer->name, "sp804");
+
+	sp804_clocksource_init(base, timer->name);
+
+	err = of_property_read_string(of_aliases, "timer1", &path);
+	if (WARN_ON(err))
+		return;
+
+	timer = of_find_node_by_path(path);
+	base = of_iomap(timer, 0);
+	if (WARN_ON(!base))
+		return;
+
+	clk = of_clk_get_by_name(timer, NULL);
+	clk_register_clkdev(clk, timer->name, "sp804");
+
+	irq = irq_of_parse_and_map(timer, 0);
+	sp804_clockevents_init(base, irq, timer->name);
+}
+
+static void __init nspire_map_io(void)
+{
+	iotable_init(nspire_io_desc, ARRAY_SIZE(nspire_io_desc));
+}
+
+static void __init nspire_init(void)
+{
+	of_platform_populate(NULL, of_default_bus_match_table,
+			NULL, NULL);
+}
+
+static void nspire_restart(char mode, const char *cmd)
+{
+}
+
+DT_MACHINE_START(NSPIRE, "TI-NSPIRE")
+	.map_io		= nspire_map_io,
+	.init_irq	= irqchip_init,
+	.init_time	= nspire_init_timer,
+	.init_machine	= nspire_init,
+	.dt_compat	= nspire_dt_match,
+	.restart	= nspire_restart,
+MACHINE_END
-- 
1.7.9.6 (Apple Git-31.1)




From kevin at bracey.fi  Sat Apr  6 08:37:03 2013
From: kevin at bracey.fi (Kevin Bracey)
Date: Sat,  6 Apr 2013 15:37:03 +0300
Subject: [PATCH] cpu_kill/cpu_die coordination
Message-ID: <1365251824-4852-1-git-send-email-kevin@bracey.fi>

I've been having problems handshaking between cpu_kill and cpu_die, due to the
fact that they don't always occur together. It seems to me that this patch is
basically what's needed. I'm working on 3.4-based code, but the logic doesn't
seem to have changed since then.

Searches didn't show much activity in this area - it appears that I'm on the
only upstream platform actually implementing cpu_kill, which may explain why
it's not been noticed.

Only related topic I found was this discussion:

     https://patchwork.kernel.org/patch/1898311/

which could maybe be short-circuited by this patch.

Kevin Bracey (1):
  ARM: smp: call platform's cpu_die in ipi_cpu_stop

 arch/arm/kernel/smp.c | 3 +++
 1 file changed, 3 insertions(+)

-- 
1.8.2.445.gfcda34b



From kevin at bracey.fi  Sat Apr  6 08:37:04 2013
From: kevin at bracey.fi (Kevin Bracey)
Date: Sat,  6 Apr 2013 15:37:04 +0300
Subject: [PATCH] ARM: smp: call platform's cpu_die in ipi_cpu_stop
In-Reply-To: <1365251824-4852-1-git-send-email-kevin@bracey.fi>
References: <1365251824-4852-1-git-send-email-kevin@bracey.fi>
Message-ID: <1365251824-4852-2-git-send-email-kevin@bracey.fi>

When hotplugging out, both cpu_kill and cpu_die have always been called.
But when smp_send_stop was used in machine_shutdown or panic, only
cpu_kill was called.

This causes problems for co-ordination between cpu_kill and cpu_die, as
attempted by shmobile. So add cpu_die call to ipi_cpu_stop, to ensure
that cpu_kill and cpu_die calls always occur together.

Signed-off-by: Kevin Bracey <kevin at bracey.fi>
---
 arch/arm/kernel/smp.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
index 84f4cbf..6692bba 100644
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -572,6 +572,9 @@ static void ipi_cpu_stop(unsigned int cpu)
 	local_fiq_disable();
 	local_irq_disable();
 
+	if (smp_ops.cpu_die)
+		smp_ops.cpu_die(cpu);
+
 	while (1)
 		cpu_relax();
 }
-- 
1.8.2.445.gfcda34b



From arnd at arndb.de  Sat Apr  6 09:05:33 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Sat, 6 Apr 2013 15:05:33 +0200
Subject: [PATCH v3 1/5] drivers: memory: Introduce Marvell EBU Device Bus
 driver
In-Reply-To: <1365246930-13315-2-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1365246930-13315-1-git-send-email-ezequiel.garcia@free-electrons.com>
 <1365246930-13315-2-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <201304061505.33946.arnd@arndb.de>

On Saturday 06 April 2013, Ezequiel Garcia wrote:

> + - devbus,dev-width:    0x0 = 8-bit
> +                        0x1 = 16-bit
> +                        0x2 = 32-bit
> +                        0x3 = Reserved

I think by convention this should be called "bus-width" and allow the
values <8>, <16> and <32>, each referrring to the width in bits.

> +/* Perhaps it makes sense to unify both compatible strins? */
> +static const struct of_device_id mvebu_devbus_of_match[] = {
> +	{ .compatible = "marvell,armada370-devbus"	 },
> +	{ .compatible = "marvell,armadaxp-devbus"	 },
> +	{},
> +};
> +MODULE_DEVICE_TABLE(of, mvebu_devbus_of_match);

Yes, if the hardware behaves identically and all the differences are
described in the other properties, just name it after the first soc
that had this devbus.

	Arnd


From arnd at arndb.de  Sat Apr  6 09:09:39 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Sat, 6 Apr 2013 15:09:39 +0200
Subject: [PATCH v3 0/5] Device Bus support for Marvell EBU SoC
In-Reply-To: <1365246930-13315-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1365246930-13315-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <201304061509.39253.arnd@arndb.de>

On Saturday 06 April 2013, Ezequiel Garcia wrote:
> Now that the mbus driver has been added to manage address decoding
> windows it's possible to introduce the Device Bus driver.
> This driver allows to access several memories and I/O devices
> such as NOR, NAND, SRAM and FPGAs.

Yes, I think this is good, I only have two trivial comments for the first
patch that I'd like you to address.

The ranges property for the devbus itself will obviously change later
when the mbus driver is there, but that should not impact the binding
for the devbus, so from my point of view it can go into 3.10.

	Arnd


From tomasz.figa at gmail.com  Sat Apr  6 09:21:19 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Sat, 06 Apr 2013 15:21:19 +0200
Subject: [RFC PATCH] CLK: Allow parent clock and rate to be configured in
 DT.
In-Reply-To: <CAKGA1bkWLrOs15ni=8D__BvuG6kvqkeeLZGOLrVZY9g0q0z4Bg@mail.gmail.com>
References: <20130319170933.28337.50448.stgit@localhost>
 <CAOMZO5ASkvquyzPCEGObvB5Xh9bDPTJ2zx26eOUJT_Vb36Bn3Q@mail.gmail.com>
 <CAKGA1bkWLrOs15ni=8D__BvuG6kvqkeeLZGOLrVZY9g0q0z4Bg@mail.gmail.com>
Message-ID: <6581638.FPkNsv6peb@flatron>

Hi,

[RANT]

I tend to disagree about this whole hype about device tree usage for other 
things than pure hardware description. I don't think device tree should be  
a way to force some kind of new world order, but rather a more convenient 
and more maintainable (than board files) way of support hardware platforms 
in Linux kernel.

On Friday 05 of April 2013 20:07:09 Matt Sealey wrote:
> On Thu, Apr 4, 2013 at 6:08 PM, Fabio Estevam <festevam at gmail.com> 
wrote:
> > This could be useful for removing the imx6q_sabrelite_cko1_setup()
> > function from arch/arm/mach-imx/mach-imx6q.c.
> > 
> > I would like to add audio support for another board and would like to
> > avoid to do the same as imx6q_sabrelite_cko1_setup()  for setting up
> > the CLKO, if possible.
> 
> You know, we have the same problem on one of our designs here (CLKO is
> used on MX53 for audio codec and camera device, shared) - the current
> solution is hack it into platform support in a BSP kernel.
> 
> If we move to device tree, we know and you know the solution already;
> all this clock setup HAS to be done in the bootloader.

Assuming that you can change the bootloader... Isn't bootloader this piece 
of code that you shouldn't touch if it's working (especially in production 
environments)?

> The device tree really, really is only a way to describe the
> configuration as it exists or to describe alternatives - for instance,
> a clock with 10 parents may be described as having 10 parents, and the
> binding (in complicated cases) or driver (if it is simple as a value
> from 0 to 7 and the field width is 3 bits for example) will determine
> how that alternative can be selected (and by consequence, what the
> current setting is).
> 
> The device tree concept is NOT a place to dump configuration items for
> your board as hardcoded values to try and force something you could
> have done elsewhere. On i.MX53 you cannot boot a kernel verbatim - you
> at least have to run through the Boot ROM and supply a DCD table or
> plugins first. This is where you figure things like this out.

Why not? For Linux and most of ARM-based platforms device tree is just a 
replacement for board files. They are not going to be used with any other 
imaginary kernel supporting device tree. On many of them even the device 
tree blob will be distributed along with kernel image, if not simply 
appended to the zImage.

I think it should be up to the board/platform maintainer whether they want 
to limit device tree on particular boards/platforms just to hardware 
description or extend it to handle everything that was originally handled 
by board files.

> In a case where you have, say, an audio codec and it has a dynamic
> input clock that you want to change on the fly, first of all you would
> not hardcode a frequency into a device tree, second of all there is
> nothing stopping you from doing that right now anyway. If the clock is
> static and fixed frequency and can only be turned on and off, there
> are clock bindings for this already. If it is static and can never be
> turned off, then there are clock bindings for this too, and in this
> case the proviso is that the clock is ALREADY turned on and ALREADY
> stable before you enter the kernel otherwise the description is by
> it's very definition invalid.
> 
> If the clock frequency in hardware is not what you wanted when the
> driver comes up, and you only have an on/off switch, it is not up to
> the device tree binding to describe how to go about configuring the
> system to make sure. You cannot in good conscience put a clock
> frequency "to be set later" in the device tree along with a clock
> phandle, simply because that means the device tree no longer describes
> the hardware accurately - the clock phandle is a valid clock, the
> hardware will tell you a frequency from registers in the clock driver,
> the device tree will disagree. How do you know which one is the
> correct value, or if the frequency in the tree is a suggestion rather
> than a description?

Sure. This is (and has always been) something to account for when bringing 
up new platforms from the ground up.

But you can't always have control over the bootloader. What's wrong in 
letting the kernel configure the board itself? It must configure most of 
the hardware anyway, based on platform data (either located in board files 
or parsed from device tree).

Why not to make the kernel independent from the bootloader at all? Then 
the bootloader could just do some minimal initialization needed to load a 
kernel image from flash memory and launch it (+ some code to allow 
flashing of new images).

> I am totally against this (sorry Sascha..). Let's put some effort into
> fixing the bootloaders rather than trying to use the device tree to
> enforce the ridiculous assumption that "Linux kernel does not trust
> the bootloader". Once the bindings and trees are out of the kernel
> source, you're going to HAVE to trust what the bootloader passes, be
> it pregenerated compiled blob (which needs to be written to match the
> hardware state the bootloader finishes up at) or dynamically generated
> at runtime during the boot process (which can describe to the bit what
> the hardware is doing). If you are testing this on Beagle XM you can
> fix your U-Boot easily. New boards will have to be designed *with the
> idea of device trees and working configurations in mind* - that is a
> fact of life, in fact this is how it should be in reality these days
> anyway (most HW designers will do initial bringup of the board - at
> least a minimal working configuration, in a restricted environment
> where they can use test pads to measure clocks, voltage outputs and
> levels of devices to ensure both production was successful and that
> the design is in itself electrically sound. This code 99% of the time
> ends up in the bootloader... sometimes not, when the board was
> designed by one group and the software written by the community, but
> in this case the community needs to learn board bringup and proper
> behavior...)

Well, so you are basically suggesting to throw away Linux support for 
boards/platforms designed without device tree in mind and on which 
replacing the bootloader is simply infeasible or sometimes even 
impossible.

I don't think that ARM Linux is adopting device tree just to have device 
tree. There are many problems that can be solved using device tree, like 
multiplatform support, separation of board support from kernel code, 
binding consumers with providers (PHYs, GPIOs, clocks, etc.). Why do we 
have to cover all these advantages behind a curtain of new problems?

[/RANT]

Best regards,
Tomasz



From arnd at arndb.de  Sat Apr  6 09:24:56 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Sat, 6 Apr 2013 15:24:56 +0200
Subject: [RFC PATCH arm: initial TI-Nspire support]
In-Reply-To: <F832F4F9-8162-43B8-B9E0-D5D8C8B8C77A@gmail.com>
References: <6FE4B33E-A503-4A75-AEED-831CB2C06D83@gmail.com>
 <201304061351.00889.arnd@arndb.de>
 <F832F4F9-8162-43B8-B9E0-D5D8C8B8C77A@gmail.com>
Message-ID: <201304061524.56502.arnd@arndb.de>

On Saturday 06 April 2013, Daniel Tang wrote:
> Hi,
> 
> 
> On 06/04/2013, at 10:51 PM, Arnd Bergmann <arnd at arndb.de> wrote:
> > 
> > Ok, whichever way you prefer. If you have questions while working on this,
> > feel free to join #armlinux on irc.freenode.net, there are usually other
> > people working on the same things.
> > 
> 
> Cheers.
> 
> We already have something basic that boots successfully using device trees. 
> 
> Some comments before we continue would be greatly appreciated.
> 
> Signed-off-by: Daniel Tang <dt.tangr at gmail.com>

Wow, that was quick!

The patch looks great overall, I just found a few details and have some comments
that you might find helpful.

>  arch/arm/Kconfig                                |   13 ++
>  arch/arm/Makefile                               |    3 +-
>  arch/arm/boot/dts/nspire-cx.dts                 |   85 +++++++++++++
>  arch/arm/boot/dts/nspire.dtsi                   |  154 +++++++++++++++++++++++
>  arch/arm/mach-nspire/Makefile                   |    3 +
>  arch/arm/mach-nspire/include/mach/debug-macro.S |   25 ++++
>  arch/arm/mach-nspire/include/mach/timex.h       |   15 +++
>  arch/arm/mach-nspire/include/mach/uncompress.h  |   25 ++++
>  arch/arm/mach-nspire/mmio.h                     |   13 ++
>  arch/arm/mach-nspire/nspire.c                   |  107 ++++++++++++++++

A good next step before doing anything else might be to put it under
CONFIG_ARCH_MULTIPLATFORM and remove the include/mach directory.

The only requirement for that should be to move debug-macro.S to
include/debug/nspire.S

> +config ARCH_NSPIRE
> +	bool "TI-NSPIRE based"
> +	depends on MMU
> +	select CPU_ARM926T
> +	select COMMON_CLK
> +	select GENERIC_CLOCKEVENTS
> +	select SPARSE_IRQ
> +	select ARM_AMBA
> +	select ARM_VIC
> +	select ARM_TIMER_SP804
> +	help
> +	  This enables support for systems using the TI-NSPIRE CPU

Since this has all the required changes already.

> @@ -313,7 +314,7 @@ define archhelp
>    echo  '  Image         - Uncompressed kernel image (arch/$(ARCH)/boot/Image)'
>    echo  '* xipImage      - XIP kernel image, if configured (arch/$(ARCH)/boot/xipImage)'
>    echo  '  uImage        - U-Boot wrapped zImage'
> -  echo  '  bootpImage    - Combined zImage and initial RAM disk' 
> +  echo  '  bootpImage    - Combined zImage and initial RAM disk'
>    echo  '                  (supply initrd image via make variable INITRD=<path>)'
>    echo  '* dtbs          - Build device tree blobs for enabled boards'
>    echo  '  install       - Install uncompressed kernel'

This looks like it wasn't meant to be in the patch.

> +		tdes: tdes at C8010000 {
> +			reg = <0xC8010000 0x1000>;
> +		};
> +
> +		sha256: sha256 at CC000000 {
> +			reg = <0xCC000000 0x1000>;
> +		};

maybe rename the actual nodes to "crypto at c...". The device name should
be a really generic word in general.

> +			uart: uart at 90020000 {
> +				reg = <0x90020000 0x1000>;
> +				interrupts = <1>;
> +
> +				clocks = <&uart_clk>;
> +				clock-names = "uart_clk";
> +			};

The name for a uart should be "serial". Since this is a pl01x, please add
the required properties for the device, e.g. 

	compatible = "arm,pl011", "arm,primecell";

You will need the "arm,primecell" bit to make the device appear on the
amba bus rather than the platform bus.

> +			timer0: timer0 at 900C0000 {
> +				reg = <0x900C0000 0x1000>;
> +				interrupts = <18>;
> +
> +				clocks = <&timer_clk>;
> +				clock-names = "timer_clk";
> +			};
> +
> +			timer1: timer1 at 900D0000 {
> +				reg = <0x900D0000 0x1000>;
> +				interrupts = <19>;
> +
> +				clocks = <&timer_clk>;
> +				clock-names = "timer_clk";
> +			};

Name the devices "timer", not "timer0" and "timer1", the address after @ is
used to disambiguate them. There are currently patches for sp804 under
discussion on the mailing list, you should probably watch those.

> --- /dev/null
> +++ b/arch/arm/mach-nspire/Makefile
> @@ -0,0 +1,3 @@
> +obj-y				:=
> +
> +obj-y				+= nspire.o

The first line is not actually needed.

> +
> +#include "../../mmio.h"
> +
> +.macro	addruart, rp, rv, tmp
> +	ldr \rp, =(NSPIRE_EARLY_UART_PHYS_BASE)		@ physical base address
> +	ldr \rv, =(NSPIRE_EARLY_UART_VIRT_BASE)		@ virtual base address
> +.endm
> +
> +#include <asm/hardware/debug-pl01x.S>
> +

There is no nice solution for getting the addresses here, but the consensus
was to just define the macros in this file rather than try to include a
header from elsewhere.


> +	err = of_property_read_string(of_aliases, "timer0", &path);
> +	if (WARN_ON(err))
> +		return;
> +
> +	timer = of_find_node_by_path(path);
> +	base = of_iomap(timer, 0);
> +	if (WARN_ON(!base))
> +		return;
> +
> +	clk = of_clk_get_by_name(timer, NULL);
> +	clk_register_clkdev(clk, timer->name, "sp804");
> +
> +	sp804_clocksource_init(base, timer->name);
> +
> +	err = of_property_read_string(of_aliases, "timer1", &path);
> +	if (WARN_ON(err))
> +		return;

In particular, I think the method of using aliases to pick the right sp804
instance is being deprecated now. If both timers are identical, the kernel
will now just pick one of them.

	Arnd


From tomasz.figa at gmail.com  Sat Apr  6 09:31:31 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Sat, 06 Apr 2013 15:31:31 +0200
Subject: [RFC PATCH] CLK: Allow parent clock and rate to be configured in
 DT.
In-Reply-To: <6581638.FPkNsv6peb@flatron>
References: <20130319170933.28337.50448.stgit@localhost>
 <CAKGA1bkWLrOs15ni=8D__BvuG6kvqkeeLZGOLrVZY9g0q0z4Bg@mail.gmail.com>
 <6581638.FPkNsv6peb@flatron>
Message-ID: <1516548.VF4d2XopCk@flatron>

CCing Sylwester and Mike (correctly)

On Saturday 06 of April 2013 15:21:19 Tomasz Figa wrote:
> Hi,
> 
> [RANT]
> 
> I tend to disagree about this whole hype about device tree usage for
> other things than pure hardware description. I don't think device tree
> should be a way to force some kind of new world order, but rather a
> more convenient and more maintainable (than board files) way of support
> hardware platforms in Linux kernel.
> 
> On Friday 05 of April 2013 20:07:09 Matt Sealey wrote:
> > On Thu, Apr 4, 2013 at 6:08 PM, Fabio Estevam <festevam at gmail.com>
> 
> wrote:
> > > This could be useful for removing the imx6q_sabrelite_cko1_setup()
> > > function from arch/arm/mach-imx/mach-imx6q.c.
> > > 
> > > I would like to add audio support for another board and would like
> > > to
> > > avoid to do the same as imx6q_sabrelite_cko1_setup()  for setting up
> > > the CLKO, if possible.
> > 
> > You know, we have the same problem on one of our designs here (CLKO is
> > used on MX53 for audio codec and camera device, shared) - the current
> > solution is hack it into platform support in a BSP kernel.
> > 
> > If we move to device tree, we know and you know the solution already;
> > all this clock setup HAS to be done in the bootloader.
> 
> Assuming that you can change the bootloader... Isn't bootloader this
> piece of code that you shouldn't touch if it's working (especially in
> production environments)?
> 
> > The device tree really, really is only a way to describe the
> > configuration as it exists or to describe alternatives - for instance,
> > a clock with 10 parents may be described as having 10 parents, and the
> > binding (in complicated cases) or driver (if it is simple as a value
> > from 0 to 7 and the field width is 3 bits for example) will determine
> > how that alternative can be selected (and by consequence, what the
> > current setting is).
> > 
> > The device tree concept is NOT a place to dump configuration items for
> > your board as hardcoded values to try and force something you could
> > have done elsewhere. On i.MX53 you cannot boot a kernel verbatim - you
> > at least have to run through the Boot ROM and supply a DCD table or
> > plugins first. This is where you figure things like this out.
> 
> Why not? For Linux and most of ARM-based platforms device tree is just a
> replacement for board files. They are not going to be used with any
> other imaginary kernel supporting device tree. On many of them even the
> device tree blob will be distributed along with kernel image, if not
> simply appended to the zImage.
> 
> I think it should be up to the board/platform maintainer whether they
> want to limit device tree on particular boards/platforms just to
> hardware description or extend it to handle everything that was
> originally handled by board files.
> 
> > In a case where you have, say, an audio codec and it has a dynamic
> > input clock that you want to change on the fly, first of all you would
> > not hardcode a frequency into a device tree, second of all there is
> > nothing stopping you from doing that right now anyway. If the clock is
> > static and fixed frequency and can only be turned on and off, there
> > are clock bindings for this already. If it is static and can never be
> > turned off, then there are clock bindings for this too, and in this
> > case the proviso is that the clock is ALREADY turned on and ALREADY
> > stable before you enter the kernel otherwise the description is by
> > it's very definition invalid.
> > 
> > If the clock frequency in hardware is not what you wanted when the
> > driver comes up, and you only have an on/off switch, it is not up to
> > the device tree binding to describe how to go about configuring the
> > system to make sure. You cannot in good conscience put a clock
> > frequency "to be set later" in the device tree along with a clock
> > phandle, simply because that means the device tree no longer describes
> > the hardware accurately - the clock phandle is a valid clock, the
> > hardware will tell you a frequency from registers in the clock driver,
> > the device tree will disagree. How do you know which one is the
> > correct value, or if the frequency in the tree is a suggestion rather
> > than a description?
> 
> Sure. This is (and has always been) something to account for when
> bringing up new platforms from the ground up.
> 
> But you can't always have control over the bootloader. What's wrong in
> letting the kernel configure the board itself? It must configure most of
> the hardware anyway, based on platform data (either located in board
> files or parsed from device tree).
> 
> Why not to make the kernel independent from the bootloader at all? Then
> the bootloader could just do some minimal initialization needed to load
> a kernel image from flash memory and launch it (+ some code to allow
> flashing of new images).
> 
> > I am totally against this (sorry Sascha..). Let's put some effort into
> > fixing the bootloaders rather than trying to use the device tree to
> > enforce the ridiculous assumption that "Linux kernel does not trust
> > the bootloader". Once the bindings and trees are out of the kernel
> > source, you're going to HAVE to trust what the bootloader passes, be
> > it pregenerated compiled blob (which needs to be written to match the
> > hardware state the bootloader finishes up at) or dynamically generated
> > at runtime during the boot process (which can describe to the bit what
> > the hardware is doing). If you are testing this on Beagle XM you can
> > fix your U-Boot easily. New boards will have to be designed *with the
> > idea of device trees and working configurations in mind* - that is a
> > fact of life, in fact this is how it should be in reality these days
> > anyway (most HW designers will do initial bringup of the board - at
> > least a minimal working configuration, in a restricted environment
> > where they can use test pads to measure clocks, voltage outputs and
> > levels of devices to ensure both production was successful and that
> > the design is in itself electrically sound. This code 99% of the time
> > ends up in the bootloader... sometimes not, when the board was
> > designed by one group and the software written by the community, but
> > in this case the community needs to learn board bringup and proper
> > behavior...)
> 
> Well, so you are basically suggesting to throw away Linux support for
> boards/platforms designed without device tree in mind and on which
> replacing the bootloader is simply infeasible or sometimes even
> impossible.
> 
> I don't think that ARM Linux is adopting device tree just to have device
> tree. There are many problems that can be solved using device tree,
> like multiplatform support, separation of board support from kernel
> code, binding consumers with providers (PHYs, GPIOs, clocks, etc.). Why
> do we have to cover all these advantages behind a curtain of new
> problems?
> 
> [/RANT]
> 
> Best regards,
> Tomasz


From arnd at arndb.de  Sat Apr  6 09:32:06 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Sat, 6 Apr 2013 15:32:06 +0200
Subject: [PATCH v2 1/5] drivers: memory: Introduce Marvell EBU Device Bus
 driver
In-Reply-To: <20130405214510.GB16221@obsidianresearch.com>
References: <1365196320-15084-1-git-send-email-ezequiel.garcia@free-electrons.com>
 <1365196320-15084-2-git-send-email-ezequiel.garcia@free-electrons.com>
 <20130405214510.GB16221@obsidianresearch.com>
Message-ID: <201304061532.06280.arnd@arndb.de>

On Friday 05 April 2013, Jason Gunthorpe wrote:
> I look at this and sort of go 'hmm'. These are basically register
> offsets into the block starting at 0xd0010400. I don't see any
> registers that are shared between targets. It would be simpler to keep
> each target as a seperate node and seperate driver instance.
> 
> Combining that idea with the suggestion for target-id centric mbus DT
> binding:
> 
> bootcs at d0010400 {
>    compatible = "marvell,armada370-devbus";
>    ranges = <0 MAPDEF_BOOTCS 0x1000>
>    reg = <MAPDEF_INTERNAL + 0x10400 0x8>;  // boot cs register set
>    devbus,dev-width = <1>;
>    [..] etc
> 
>    rom at 0 {
>       reg = <0 0x1000>
>    }
> }

+1

Good idea


	Arnd


From arnd at arndb.de  Sat Apr  6 09:34:36 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Sat, 6 Apr 2013 15:34:36 +0200
Subject: [PATCH v3 1/5] drivers: memory: Introduce Marvell EBU Device Bus
 driver
In-Reply-To: <1365246930-13315-2-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1365246930-13315-1-git-send-email-ezequiel.garcia@free-electrons.com>
 <1365246930-13315-2-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <201304061534.36682.arnd@arndb.de>

On Saturday 06 April 2013, Ezequiel Garcia wrote:
> +       device-bus at d0010400 {
> +               status = "okay";
> +               ranges = <0 0 0xf0000000 0x1000000>; /* CS0 @addr 0xf0000000, size 0x1000000 */
> +               #address-cells = <2>;
> +               #size-cells = <1>;
> +
> +               flash at 0 {
> +                       compatible = "cfi-flash";
> +
> +                       /* CS0, 16 MiB */
> +                       reg = <0 0 0x1000000>;
> +                       bank-width = <2>;
> +                       #address-cells = <1>;
> +                       #size-cells = <1>;
> +
> +                       /* Device Bus parameters are required */
> +
> +                       /* Read parameters */
> +                       devbus,dev-width    = <1>;
> +                       devbus,turn-off-ps  = <60000>;
> +                       devbus,badr-skew-ps = <0>;
> +                       devbus,acc-first-ps = <124000>;
> +                       devbus,acc-next-ps  = <248000>;
> +                       devbus,rd-setup-ps  = <0>;
> +                       devbus,rd-hold-ps   = <0>;

I just read the email from Jason Gunthorpe suggesting to have a separate
device-bus instance for each CS under it.

I think the implication of that is that all the "devbus,..." properties can
now be moved into the parent node, which makes the split between the
devbus node and its attached device clearer.

	Arnd


From nicolas.pitre at linaro.org  Sat Apr  6 09:41:25 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Sat, 6 Apr 2013 09:41:25 -0400 (EDT)
Subject: [PATCH v4 03/15] ARM: mcpm: introduce helpers for platform
 coherency exit/setup
In-Reply-To: <20130405230017.GC14308@quad.lixom.net>
References: <1360041732-17936-1-git-send-email-nicolas.pitre@linaro.org>
 <1360041732-17936-4-git-send-email-nicolas.pitre@linaro.org>
 <20130405230017.GC14308@quad.lixom.net>
Message-ID: <alpine.LFD.2.03.1304051917520.1171@syhkavp.arg>

On Fri, 5 Apr 2013, Olof Johansson wrote:

> Hi,
> 
> Just two nits below. One could be fixed incrementally, the other is
> a longer-term potential cleanup.

I've updated my branch directly.  Especially the comment addition is 
best presented in the original patch to avoid confusion.

> 
> On Tue, Feb 05, 2013 at 12:22:00AM -0500, Nicolas Pitre wrote:
> 
> > diff --git a/arch/arm/include/asm/mcpm_entry.h b/arch/arm/include/asm/mcpm_entry.h
> > index 3286d5eb91..e76652209d 100644
> > --- a/arch/arm/include/asm/mcpm_entry.h
> > +++ b/arch/arm/include/asm/mcpm_entry.h
> > @@ -15,8 +15,37 @@
> >  #define MAX_CPUS_PER_CLUSTER	4
> >  #define MAX_NR_CLUSTERS		2
> >  
> > +/* Definitions for mcpm_sync_struct */
> > +#define CPU_DOWN		0x11
> > +#define CPU_COMING_UP		0x12
> > +#define CPU_UP			0x13
> > +#define CPU_GOING_DOWN		0x14
> > +
> > +#define CLUSTER_DOWN		0x21
> > +#define CLUSTER_UP		0x22
> > +#define CLUSTER_GOING_DOWN	0x23
> > +
> > +#define INBOUND_NOT_COMING_UP	0x31
> > +#define INBOUND_COMING_UP	0x32
> > +
> > +/* This is a complete guess. */
> > +#define __CACHE_WRITEBACK_ORDER	6
> > +#define __CACHE_WRITEBACK_GRANULE (1 << __CACHE_WRITEBACK_ORDER)
> 
> Something a little more educational could be useful here. It needs to
> be the max writeback/line size of the supported platforms of the binary
> kernel, i.e. if someone builds an SoC with 128-byte L2 cache lines this
> guess will break.

The commit log says:

|Also, in order to prevent a cached writer from interfering with an
|adjacent non-cached writer, we ensure each state variable is located to
|a separate cache line.

Although a more explicit comment here would be helpful indeed.

Fixed.

Yet, that part will be reworked once we move to dynamic allocation 
anyway.  But for the time being it is best to keep the code simple while 
people get familiar with it.

> > +/* Offsets for the mcpm_sync_struct members, for use in asm: */
> > +#define MCPM_SYNC_CLUSTER_CPUS	0
> > +#define MCPM_SYNC_CPU_SIZE	__CACHE_WRITEBACK_GRANULE
> > +#define MCPM_SYNC_CLUSTER_CLUSTER \
> > +	(MCPM_SYNC_CLUSTER_CPUS + MCPM_SYNC_CPU_SIZE * MAX_CPUS_PER_CLUSTER)
> > +#define MCPM_SYNC_CLUSTER_INBOUND \
> > +	(MCPM_SYNC_CLUSTER_CLUSTER + __CACHE_WRITEBACK_GRANULE)
> > +#define MCPM_SYNC_CLUSTER_SIZE \
> > +	(MCPM_SYNC_CLUSTER_INBOUND + __CACHE_WRITEBACK_GRANULE)
> > +
> >  #ifndef __ASSEMBLY__
> >  
> > +#include <linux/types.h>
> > +
> >  /*
> >   * Platform specific code should use this symbol to set up secondary
> >   * entry location for processors to use when released from reset.
> > @@ -123,5 +152,39 @@ struct mcpm_platform_ops {
> >   */
> >  int __init mcpm_platform_register(const struct mcpm_platform_ops *ops);
> >  
> > +/* Synchronisation structures for coordinating safe cluster setup/teardown: */
> > +
> > +/*
> > + * When modifying this structure, make sure you update the MCPM_SYNC_ defines
> > + * to match.
> > + */
> 
> It would be nice to introduce something like arch/powerpc/kernel/asm-offsets.c
> on ARM to generate the ASM-side automatically from the C struct instead for
> this and other cases, but that's unrelated to this addition.

There is a arch/arm/kernel/asm-offsets.c already.

Here's the answer I provided before:
http://article.gmane.org/gmane.linux.ports.arm.kernel/209009

|That's how that was done initially. But that ended up cluttering
|asm-offsets.h for stuff that actually is really a local implementation
|detail which doesn't need kernel wide scope.  In other words, the end
|result looked worse.
|
|One could argue that they are still exposed too much as the only files
|that need to know about those defines are bL_head.S and bL_entry.c.


Nicolas


From aletes.xgr at gmail.com  Sat Apr  6 09:42:10 2013
From: aletes.xgr at gmail.com (Alexandre Pereira da Silva)
Date: Sat,  6 Apr 2013 10:42:10 -0300
Subject: [PATCH] ARM: dts: imx23-olinuxino: mark sdcard cd as broken
Message-ID: <1365255730-6299-1-git-send-email-aletes.xgr@gmail.com>

The imx23-olinuxino sdcard doesn't have card detect.

Signed-off-by: Alexandre Pereira da Silva <aletes.xgr at gmail.com>
---
 arch/arm/boot/dts/imx23-olinuxino.dts |    1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/imx23-olinuxino.dts b/arch/arm/boot/dts/imx23-olinuxino.dts
index a43141a..d4cc9f8 100644
--- a/arch/arm/boot/dts/imx23-olinuxino.dts
+++ b/arch/arm/boot/dts/imx23-olinuxino.dts
@@ -29,6 +29,7 @@
 				pinctrl-names = "default";
 				pinctrl-0 = <&mmc0_4bit_pins_a &mmc0_pins_fixup>;
 				bus-width = <4>;
+				broken-cd;
 				status = "okay";
 			};
 
-- 
1.7.10



From nicolas.pitre at linaro.org  Sat Apr  6 09:43:26 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Sat, 6 Apr 2013 09:43:26 -0400 (EDT)
Subject: [PATCH v4 14/15] ARM: Enable selection of SMP operations at boot
 time
In-Reply-To: <20130405224348.GA14308@quad.lixom.net>
References: <1360041732-17936-1-git-send-email-nicolas.pitre@linaro.org>
 <1360041732-17936-15-git-send-email-nicolas.pitre@linaro.org>
 <20130405224348.GA14308@quad.lixom.net>
Message-ID: <alpine.LFD.2.03.1304060942340.1171@syhkavp.arg>

On Fri, 5 Apr 2013, Olof Johansson wrote:

> On Tue, Feb 05, 2013 at 12:22:11AM -0500, Nicolas Pitre wrote:
> > From: Jon Medhurst <tixy at linaro.org>
> > 
> > Add a new 'smp_init' hook to machine_desc so platforms can specify a
> > function to be used to setup smp ops instead of having a statically
> > defined value.
> > 
> > Signed-off-by: Jon Medhurst <tixy at linaro.org>
> > Signed-off-by: Nicolas Pitre <nicolas.pitre at linaro.org>
> > Reviewed-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
> > ---
> >  arch/arm/include/asm/mach/arch.h | 3 +++
> >  arch/arm/kernel/setup.c          | 5 ++++-
> >  2 files changed, 7 insertions(+), 1 deletion(-)
> > 
> > diff --git a/arch/arm/include/asm/mach/arch.h b/arch/arm/include/asm/mach/arch.h
> > index 917d4fcfd9..3d01c6d6c3 100644
> > --- a/arch/arm/include/asm/mach/arch.h
> > +++ b/arch/arm/include/asm/mach/arch.h
> > @@ -17,8 +17,10 @@ struct pt_regs;
> >  struct smp_operations;
> >  #ifdef CONFIG_SMP
> >  #define smp_ops(ops) (&(ops))
> > +#define smp_init_ops(ops) (&(ops))
> >  #else
> >  #define smp_ops(ops) (struct smp_operations *)NULL
> > +#define smp_init_ops(ops) (void (*)(void))NULL
> >  #endif
> >  
> >  struct machine_desc {
> > @@ -42,6 +44,7 @@ struct machine_desc {
> >  	unsigned char		reserve_lp2 :1;	/* never has lp2	*/
> >  	char			restart_mode;	/* default restart mode	*/
> >  	struct smp_operations	*smp;		/* SMP operations	*/
> > +	void			(*smp_init)(void);
> >  	void			(*fixup)(struct tag *, char **,
> >  					 struct meminfo *);
> >  	void			(*reserve)(void);/* reserve mem blocks	*/
> > diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> > index 3f6cbb2e3e..41edca8582 100644
> > --- a/arch/arm/kernel/setup.c
> > +++ b/arch/arm/kernel/setup.c
> > @@ -768,7 +768,10 @@ void __init setup_arch(char **cmdline_p)
> >  	arm_dt_init_cpu_maps();
> >  #ifdef CONFIG_SMP
> >  	if (is_smp()) {
> > -		smp_set_ops(mdesc->smp);
> > +		if(mdesc->smp_init)
> 
> This will fail checkpatch: if() instead of if ().

Indeed.

> > +			(*mdesc->smp_init)();
> 
> This is different calling style than init_early() below, which uses
> mdesc->init_early(). Please be consistent.

Fixed in my tree now.

Thanks.


Nicolas


From liuj97 at gmail.com  Sat Apr  6 09:54:55 2013
From: liuj97 at gmail.com (Jiang Liu)
Date: Sat,  6 Apr 2013 21:54:55 +0800
Subject: [PATCH v4,
 part3 01/15] mm: fix build warnings caused by free_reserved_area()
In-Reply-To: <1365256509-29024-1-git-send-email-jiang.liu@huawei.com>
References: <1365256509-29024-1-git-send-email-jiang.liu@huawei.com>
Message-ID: <1365256509-29024-2-git-send-email-jiang.liu@huawei.com>

Fix following build warnings cuased by free_reserved_area():

arch/arm/mm/init.c: In function 'mem_init':
arch/arm/mm/init.c:603:2: warning: passing argument 1 of 'free_reserved_area' makes integer from pointer without a cast [enabled by default]
  free_reserved_area(__va(PHYS_PFN_OFFSET), swapper_pg_dir, 0, NULL);
  ^
In file included from include/linux/mman.h:4:0,
                 from arch/arm/mm/init.c:15:
include/linux/mm.h:1301:22: note: expected 'long unsigned int' but argument is of type 'void *'
 extern unsigned long free_reserved_area(unsigned long start, unsigned long end,

   mm/page_alloc.c: In function 'free_reserved_area':
>> mm/page_alloc.c:5134:3: warning: passing argument 1 of 'virt_to_phys' makes pointer from integer without a cast [enabled by default]
   In file included from arch/mips/include/asm/page.h:49:0,
                    from include/linux/mmzone.h:20,
                    from include/linux/gfp.h:4,
                    from include/linux/mm.h:8,
                    from mm/page_alloc.c:18:
   arch/mips/include/asm/io.h:119:29: note: expected 'const volatile void *' but argument is of type 'long unsigned int'
   mm/page_alloc.c: In function 'free_area_init_nodes':
   mm/page_alloc.c:5030:34: warning: array subscript is below array bounds [-Warray-bounds]

Signed-off-by: Jiang Liu <jiang.liu at huawei.com>
Reported-by: Arnd Bergmann <arnd at arndb.de>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
Cc: linux-mm at kvack.org
---
 arch/arm/mm/init.c |    6 ++++--
 mm/page_alloc.c    |    2 +-
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index 9a5cdc0..7a82fcd 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -600,7 +600,8 @@ void __init mem_init(void)
 
 #ifdef CONFIG_SA1111
 	/* now that our DMA memory is actually so designated, we can free it */
-	free_reserved_area(__va(PHYS_PFN_OFFSET), swapper_pg_dir, 0, NULL);
+	free_reserved_area((unsigned long)__va(PHYS_PFN_OFFSET),
+			   (unsigned long)swapper_pg_dir, 0, NULL);
 #endif
 
 	free_highpages();
@@ -728,7 +729,8 @@ void free_initmem(void)
 	extern char __tcm_start, __tcm_end;
 
 	poison_init_mem(&__tcm_start, &__tcm_end - &__tcm_start);
-	free_reserved_area(&__tcm_start, &__tcm_end, 0, "TCM link");
+	free_reserved_area((unsigned long)&__tcm_start,
+			   (unsigned long)&__tcm_end, 0, "TCM link");
 #endif
 
 	poison_init_mem(__init_begin, __init_end - __init_begin);
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index e4923e9..8bf7956 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -5196,7 +5196,7 @@ unsigned long free_reserved_area(unsigned long start, unsigned long end,
 	for (pages = 0; pos < end; pos += PAGE_SIZE, pages++) {
 		if (poison)
 			memset((void *)pos, poison, PAGE_SIZE);
-		free_reserved_page(virt_to_page(pos));
+		free_reserved_page(virt_to_page((void *)pos));
 	}
 
 	if (pages && s)
-- 
1.7.9.5



From liuj97 at gmail.com  Sat Apr  6 09:54:57 2013
From: liuj97 at gmail.com (Jiang Liu)
Date: Sat,  6 Apr 2013 21:54:57 +0800
Subject: [PATCH v4, part3 03/15] mm/ARM64: kill poison_init_mem()
In-Reply-To: <1365256509-29024-1-git-send-email-jiang.liu@huawei.com>
References: <1365256509-29024-1-git-send-email-jiang.liu@huawei.com>
Message-ID: <1365256509-29024-4-git-send-email-jiang.liu@huawei.com>

Use free_reserved_area() to poison initmem memory pages and kill
poison_init_mem() on ARM64.

Signed-off-by: Jiang Liu <jiang.liu at huawei.com>
Cc: Catalin Marinas <catalin.marinas at arm.com>
Cc: Will Deacon <will.deacon at arm.com>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
---
 arch/arm64/mm/init.c |   17 +++--------------
 1 file changed, 3 insertions(+), 14 deletions(-)

diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index e58dd7f..b87bdb8 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -197,14 +197,6 @@ void __init bootmem_init(void)
 	max_pfn = max_low_pfn = max;
 }
 
-/*
- * Poison init memory with an undefined instruction (0x0).
- */
-static inline void poison_init_mem(void *s, size_t count)
-{
-	memset(s, 0, count);
-}
-
 #ifndef CONFIG_SPARSEMEM_VMEMMAP
 static inline void free_memmap(unsigned long start_pfn, unsigned long end_pfn)
 {
@@ -386,8 +378,7 @@ void __init mem_init(void)
 
 void free_initmem(void)
 {
-	poison_init_mem(__init_begin, __init_end - __init_begin);
-	free_initmem_default(-1);
+	free_initmem_default(0);
 }
 
 #ifdef CONFIG_BLK_DEV_INITRD
@@ -396,10 +387,8 @@ static int keep_initrd;
 
 void free_initrd_mem(unsigned long start, unsigned long end)
 {
-	if (!keep_initrd) {
-		poison_init_mem((void *)start, PAGE_ALIGN(end) - start);
-		free_reserved_area(start, end, -1, "initrd");
-	}
+	if (!keep_initrd)
+		free_reserved_area(start, end, 0, "initrd");
 }
 
 static int __init keepinitrd_setup(char *__unused)
-- 
1.7.9.5



From nicolas.pitre at linaro.org  Sat Apr  6 10:02:48 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Sat, 6 Apr 2013 10:02:48 -0400 (EDT)
Subject: [PATCH v4 15/15] ARM: vexpress: Select multi-cluster SMP operation
 if required
In-Reply-To: <20130405224819.GB14308@quad.lixom.net>
References: <1360041732-17936-1-git-send-email-nicolas.pitre@linaro.org>
 <1360041732-17936-16-git-send-email-nicolas.pitre@linaro.org>
 <20130405224819.GB14308@quad.lixom.net>
Message-ID: <alpine.LFD.2.03.1304060943370.1171@syhkavp.arg>

On Fri, 5 Apr 2013, Olof Johansson wrote:

> On Tue, Feb 05, 2013 at 12:22:12AM -0500, Nicolas Pitre wrote:
> > From: Jon Medhurst <tixy at linaro.org>
> > 
> > Signed-off-by: Jon Medhurst <tixy at linaro.org>
> > Signed-off-by: Nicolas Pitre <nicolas.pitre at linaro.org>
> > Reviewed-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
> > ---
> >  arch/arm/mach-vexpress/core.h    |  2 ++
> >  arch/arm/mach-vexpress/platsmp.c | 12 ++++++++++++
> >  arch/arm/mach-vexpress/v2m.c     |  2 +-
> >  3 files changed, 15 insertions(+), 1 deletion(-)
> > 
> > diff --git a/arch/arm/mach-vexpress/core.h b/arch/arm/mach-vexpress/core.h
> > index f134cd4a85..3a761fd76c 100644
> > --- a/arch/arm/mach-vexpress/core.h
> > +++ b/arch/arm/mach-vexpress/core.h
> > @@ -6,6 +6,8 @@
> >  
> >  void vexpress_dt_smp_map_io(void);
> >  
> > +void vexpress_smp_init_ops(void);
> > +
> >  extern struct smp_operations	vexpress_smp_ops;
> >  
> >  extern void vexpress_cpu_die(unsigned int cpu);
> > diff --git a/arch/arm/mach-vexpress/platsmp.c b/arch/arm/mach-vexpress/platsmp.c
> > index c5d70de9bb..667344b479 100644
> > --- a/arch/arm/mach-vexpress/platsmp.c
> > +++ b/arch/arm/mach-vexpress/platsmp.c
> > @@ -12,6 +12,7 @@
> >  #include <linux/errno.h>
> >  #include <linux/smp.h>
> >  #include <linux/io.h>
> > +#include <linux/of.h>
> >  #include <linux/of_fdt.h>
> >  #include <linux/vexpress.h>
> >  
> > @@ -206,3 +207,14 @@ struct smp_operations __initdata vexpress_smp_ops = {
> >  	.cpu_die		= vexpress_cpu_die,
> >  #endif
> >  };
> > +
> > +void __init vexpress_smp_init_ops(void)
> > +{
> > +	struct smp_operations *ops = &vexpress_smp_ops;
> > +#ifdef CONFIG_CLUSTER_PM
> > +	extern struct smp_operations mcpm_smp_ops;
> 
> Seems appropriate to put this prototype in a header file instead.
> 
> > +	if(of_find_compatible_node(NULL, NULL, "arm,cci"))
> 
> Another checkpatch error on if() whitespace.
> 
> Also, while bindings haven't been ironed out, checking for whether the
> node/device is enabled or disabled could be appropriate here?

Right.

I've amended this patch slightly so to:

1) Keep the default .smp = &vexpress_smp_ops and only perform an 
   override in vexpress_smp_init_ops() when appropriate.  This should
   remove one potential issue with Xen support that was highlighted 
   recently.

2) Add a mcpm_smp_set_ops() instead of installing mcpm_smp_ops directly
   for better abstraction.

3) Added a comment about and checked for the CCI node being enabled.

That results in the patch below.  Given those are minor changes, I kept 
the existing review tags.

From: Jon Medhurst <tixy at linaro.org>
Date: Wed, 30 Jan 2013 09:12:55 +0000
Subject: [PATCH] ARM: vexpress: Select multi-cluster SMP operation if required

Signed-off-by: Jon Medhurst <tixy at linaro.org>
Signed-off-by: Nicolas Pitre <nicolas.pitre at linaro.org>
Reviewed-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
Acked-by: Pawel Moll <pawel.moll at arm.com>

diff --git a/arch/arm/common/mcpm_platsmp.c b/arch/arm/common/mcpm_platsmp.c
index 34f236af09..cc82040877 100644
--- a/arch/arm/common/mcpm_platsmp.c
+++ b/arch/arm/common/mcpm_platsmp.c
@@ -85,3 +85,8 @@ struct smp_operations __initdata mcpm_smp_ops = {
 	.cpu_die		= mcpm_cpu_die,
 #endif
 };
+
+void __init mcpm_smp_set_ops(void)
+{
+	smp_set_ops(&mcpm_smp_ops);
+}
diff --git a/arch/arm/include/asm/mcpm_entry.h b/arch/arm/include/asm/mcpm_entry.h
index 814623e6a1..34dfb86ff5 100644
--- a/arch/arm/include/asm/mcpm_entry.h
+++ b/arch/arm/include/asm/mcpm_entry.h
@@ -190,5 +190,7 @@ int __mcpm_cluster_state(unsigned int cluster);
 int __init mcpm_sync_init(
 	void (*power_up_setup)(unsigned int affinity_level));
 
+void __init mcpm_smp_set_ops(void);
+
 #endif /* ! __ASSEMBLY__ */
 #endif
diff --git a/arch/arm/mach-vexpress/core.h b/arch/arm/mach-vexpress/core.h
index f134cd4a85..3a761fd76c 100644
--- a/arch/arm/mach-vexpress/core.h
+++ b/arch/arm/mach-vexpress/core.h
@@ -6,6 +6,8 @@
 
 void vexpress_dt_smp_map_io(void);
 
+void vexpress_smp_init_ops(void);
+
 extern struct smp_operations	vexpress_smp_ops;
 
 extern void vexpress_cpu_die(unsigned int cpu);
diff --git a/arch/arm/mach-vexpress/platsmp.c b/arch/arm/mach-vexpress/platsmp.c
index dc1ace55d5..06317bc714 100644
--- a/arch/arm/mach-vexpress/platsmp.c
+++ b/arch/arm/mach-vexpress/platsmp.c
@@ -12,9 +12,11 @@
 #include <linux/errno.h>
 #include <linux/smp.h>
 #include <linux/io.h>
+#include <linux/of.h>
 #include <linux/of_fdt.h>
 #include <linux/vexpress.h>
 
+#include <asm/mcpm_entry.h>
 #include <asm/smp_scu.h>
 #include <asm/mach/map.h>
 
@@ -203,3 +205,18 @@ struct smp_operations __initdata vexpress_smp_ops = {
 	.cpu_die		= vexpress_cpu_die,
 #endif
 };
+
+void __init vexpress_smp_init_ops(void)
+{
+#ifdef CONFIG_MCPM
+	/*
+	 * The best way to detect a multi-cluster configuration at the moment
+	 * is to look for the presence of a CCI in the system.
+	 * Override the default vexpress_smp_ops if so.
+	 */
+	struct device_node *node;
+	node = of_find_compatible_node(NULL, NULL, "arm,cci");
+	if (node && of_device_is_available(node))
+		mcpm_smp_set_ops();
+#endif
+}
diff --git a/arch/arm/mach-vexpress/v2m.c b/arch/arm/mach-vexpress/v2m.c
index 915683cb67..16b42c10e0 100644
--- a/arch/arm/mach-vexpress/v2m.c
+++ b/arch/arm/mach-vexpress/v2m.c
@@ -476,6 +476,7 @@ static const char * const v2m_dt_match[] __initconst = {
 DT_MACHINE_START(VEXPRESS_DT, "ARM-Versatile Express")
 	.dt_compat	= v2m_dt_match,
 	.smp		= smp_ops(vexpress_smp_ops),
+	.smp_init	= smp_init_ops(vexpress_smp_init_ops),
 	.map_io		= v2m_dt_map_io,
 	.init_early	= v2m_dt_init_early,
 	.init_irq	= irqchip_init,


From liuj97 at gmail.com  Sat Apr  6 10:07:15 2013
From: liuj97 at gmail.com (Jiang Liu)
Date: Sat, 06 Apr 2013 22:07:15 +0800
Subject: [PATCH v2, part1 03/29] mm/ARM: use common help functions to
 free reserved pages
In-Reply-To: <201304041547.52539.arnd@arndb.de>
References: <1362896833-21104-1-git-send-email-jiang.liu@huawei.com>
 <1362896833-21104-4-git-send-email-jiang.liu@huawei.com>
 <201304041547.52539.arnd@arndb.de>
Message-ID: <51602C13.7030907@gmail.com>

Hi Arnd,
	Missed some type casts for ARM. Could you please help check the patch at
http://marc.info/?l=linux-mm&m=136525654717201&w=2?
	Thanks!
	Gerry

On 04/04/2013 11:47 PM, Arnd Bergmann wrote:
> On Sunday 10 March 2013, Jiang Liu wrote:
>> Use common help functions to free reserved pages.
>>
>> Signed-off-by: Jiang Liu <jiang.liu at huawei.com>
>> Cc: Russell King <linux at arm.linux.org.uk>
>> Cc: Catalin Marinas <catalin.marinas at arm.com>
>> Cc: Will Deacon <will.deacon at arm.com>
>> Cc: linux-arm-kernel at lists.infradead.org
>> Cc: linux-kernel at vger.kernel.org
> 
> Hello Jiang Liu,
> 
> I'm getting a few new build warnings from this patch in linux-next, can you please
> have a look what's going on here? 
> 
>> @@ -609,8 +600,7 @@ void __init mem_init(void)
>>  
>>  #ifdef CONFIG_SA1111
>>  	/* now that our DMA memory is actually so designated, we can free it */
>> -	totalram_pages += free_area(PHYS_PFN_OFFSET,
>> -				    __phys_to_pfn(__pa(swapper_pg_dir)), NULL);
>> +	free_reserved_area(__va(PHYS_PFN_OFFSET), swapper_pg_dir, 0, NULL);
>>  #endif
> 
> Using neponset_defconfig:
> 
> arch/arm/mm/init.c: In function 'mem_init':
> arch/arm/mm/init.c:603:2: warning: passing argument 1 of 'free_reserved_area' makes integer from pointer without a cast [enabled by default]
>   free_reserved_area(__va(PHYS_PFN_OFFSET), swapper_pg_dir, 0, NULL);
>   ^
> In file included from include/linux/mman.h:4:0,
>                  from arch/arm/mm/init.c:15:
> include/linux/mm.h:1301:22: note: expected 'long unsigned int' but argument is of type 'void *'
>  extern unsigned long free_reserved_area(unsigned long start, unsigned long end,
>                       ^
> 
>> @@ -738,16 +728,12 @@ void free_initmem(void)
>>  	extern char __tcm_start, __tcm_end;
>>  
>>  	poison_init_mem(&__tcm_start, &__tcm_end - &__tcm_start);
>> -	totalram_pages += free_area(__phys_to_pfn(__pa(&__tcm_start)),
>> -				    __phys_to_pfn(__pa(&__tcm_end)),
>> -				    "TCM link");
>> +	free_reserved_area(&__tcm_start, &__tcm_end, 0, "TCM link");
>>  #endif
> 
> Using one of {realview,s3c6400,u300}_defconfig:
> 
> /git/arm-soc/arch/arm/mm/init.c: In function 'free_initmem':
> /git/arm-soc/arch/arm/mm/init.c:731:2: warning: passing argument 1 of 'free_reserved_area' makes integer from pointer without a cast [enabled by default]
>   free_reserved_area(&__tcm_start, &__tcm_end, 0, "TCM link");
>   ^
> In file included from /git/arm-soc/include/linux/mman.h:4:0,
>                  from /git/arm-soc/arch/arm/mm/init.c:15:
> /git/arm-soc/include/linux/mm.h:1301:22: note: expected 'long unsigned int' but argument is of type 'char *'
>  extern unsigned long free_reserved_area(unsigned long start, unsigned long end,
>                       ^
> 
> 	Arnd
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 



From nicolas.pitre at linaro.org  Sat Apr  6 10:22:00 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Sat, 6 Apr 2013 10:22:00 -0400 (EDT)
Subject: [RFC][PATCH] arm: highmem: Add support for flushing kmap_atomic
 mappings
In-Reply-To: <1365198171-8469-1-git-send-email-lauraa@codeaurora.org>
References: <1365198171-8469-1-git-send-email-lauraa@codeaurora.org>
Message-ID: <alpine.LFD.2.03.1304061006530.1171@syhkavp.arg>

On Fri, 5 Apr 2013, Laura Abbott wrote:

> The highmem code provides kmap_flush_unused to ensure all kmap
> mappings are really removed if they are used. This code does not

You meant "if they are *not* used", right?

> handle kmap_atomic mappings since they are managed separately.
> This prevents an issue for any code which relies on having absolutely
> no mappings for a particular page. Rather than pay the penalty of
> having CONFIG_DEBUG_HIGHMEM on all the time, add functionality
> to remove the kmap_atomic mappings in a similar way to kmap_flush_unused.

Could you elaborate on that code that relies on having absolutely no 
mappings for a particular page please?

> This is intended to be an RFC to make sure this approach is
> reasonable. The goal is to have kmap_atomic_flush_unused be a public
> API.

The clearing code is going to be costly since you do a 
set_top_pte(vaddr, __pte(0)) unconditionally on the whole range, 
regardless if the PTE is already set to 0.

Using it via an hotplug callback is rather strange, but I'm assuming 
that this was only for testing?


Nicolas


From liuj97 at gmail.com  Sat Apr  6 10:32:12 2013
From: liuj97 at gmail.com (Jiang Liu)
Date: Sat,  6 Apr 2013 22:32:12 +0800
Subject: [PATCH v4,
 part3 13/41] mm/ARM: prepare for removing num_physpages and simplify
 mem_init()
In-Reply-To: <1365258760-30821-1-git-send-email-jiang.liu@huawei.com>
References: <1365258760-30821-1-git-send-email-jiang.liu@huawei.com>
Message-ID: <1365258760-30821-14-git-send-email-jiang.liu@huawei.com>

Prepare for removing num_physpages and simplify mem_init().

Signed-off-by: Jiang Liu <jiang.liu at huawei.com>
Cc: Russell King <linux at arm.linux.org.uk>
Cc: Catalin Marinas <catalin.marinas at arm.com>
Cc: Will Deacon <will.deacon at arm.com>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
---
 arch/arm/mm/init.c |   47 ++---------------------------------------------
 1 file changed, 2 insertions(+), 45 deletions(-)

diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index add4fcb..7a911d1 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -582,9 +582,6 @@ static void __init free_highpages(void)
  */
 void __init mem_init(void)
 {
-	unsigned long reserved_pages, free_pages;
-	struct memblock_region *reg;
-	int i;
 #ifdef CONFIG_HAVE_TCM
 	/* These pointers are filled in on TCM detection */
 	extern u32 dtcm_end;
@@ -605,47 +602,7 @@ void __init mem_init(void)
 
 	free_highpages();
 
-	reserved_pages = free_pages = 0;
-
-	for_each_bank(i, &meminfo) {
-		struct membank *bank = &meminfo.bank[i];
-		unsigned int pfn1, pfn2;
-		struct page *page, *end;
-
-		pfn1 = bank_pfn_start(bank);
-		pfn2 = bank_pfn_end(bank);
-
-		page = pfn_to_page(pfn1);
-		end  = pfn_to_page(pfn2 - 1) + 1;
-
-		do {
-			if (PageReserved(page))
-				reserved_pages++;
-			else if (!page_count(page))
-				free_pages++;
-			page++;
-		} while (page < end);
-	}
-
-	/*
-	 * Since our memory may not be contiguous, calculate the
-	 * real number of pages we have in this system
-	 */
-	printk(KERN_INFO "Memory:");
-	num_physpages = 0;
-	for_each_memblock(memory, reg) {
-		unsigned long pages = memblock_region_memory_end_pfn(reg) -
-			memblock_region_memory_base_pfn(reg);
-		num_physpages += pages;
-		printk(" %ldMB", pages >> (20 - PAGE_SHIFT));
-	}
-	printk(" = %luMB total\n", num_physpages >> (20 - PAGE_SHIFT));
-
-	printk(KERN_NOTICE "Memory: %luk/%luk available, %luk reserved, %luK highmem\n",
-		nr_free_pages() << (PAGE_SHIFT-10),
-		free_pages << (PAGE_SHIFT-10),
-		reserved_pages << (PAGE_SHIFT-10),
-		totalhigh_pages << (PAGE_SHIFT-10));
+	mem_init_print_info(NULL);
 
 #define MLK(b, t) b, t, ((t) - (b)) >> 10
 #define MLM(b, t) b, t, ((t) - (b)) >> 20
@@ -711,7 +668,7 @@ void __init mem_init(void)
 	BUG_ON(PKMAP_BASE + LAST_PKMAP * PAGE_SIZE	> PAGE_OFFSET);
 #endif
 
-	if (PAGE_SIZE >= 16384 && num_physpages <= 128) {
+	if (PAGE_SIZE >= 16384 && get_num_physpages() <= 128) {
 		extern int sysctl_overcommit_memory;
 		/*
 		 * On a machine this small we won't get
-- 
1.7.9.5



From liuj97 at gmail.com  Sat Apr  6 10:32:13 2013
From: liuj97 at gmail.com (Jiang Liu)
Date: Sat,  6 Apr 2013 22:32:13 +0800
Subject: [PATCH v4,
 part3 14/41] mm/ARM64: prepare for removing num_physpages and
 simplify mem_init()
In-Reply-To: <1365258760-30821-1-git-send-email-jiang.liu@huawei.com>
References: <1365258760-30821-1-git-send-email-jiang.liu@huawei.com>
Message-ID: <1365258760-30821-15-git-send-email-jiang.liu@huawei.com>

Prepare for removing num_physpages and simplify mem_init().

Signed-off-by: Jiang Liu <jiang.liu at huawei.com>
Cc: Russell King <linux at arm.linux.org.uk>
Cc: Catalin Marinas <catalin.marinas at arm.com>
Cc: Will Deacon <will.deacon at arm.com>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
---
 arch/arm64/mm/init.c |   48 +++---------------------------------------------
 1 file changed, 3 insertions(+), 45 deletions(-)

diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 0f2cf5d..821e788 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -272,59 +272,17 @@ static void __init free_unused_memmap(void)
  */
 void __init mem_init(void)
 {
-	unsigned long reserved_pages, free_pages;
-	struct memblock_region *reg;
-
 	arm64_swiotlb_init();
 
 	max_mapnr   = pfn_to_page(max_pfn + PHYS_PFN_OFFSET) - mem_map;
 
 #ifndef CONFIG_SPARSEMEM_VMEMMAP
-	/* this will put all unused low memory onto the freelists */
 	free_unused_memmap();
 #endif
-
+	/* this will put all unused low memory onto the freelists */
 	free_all_bootmem();
 
-	reserved_pages = free_pages = 0;
-
-	for_each_memblock(memory, reg) {
-		unsigned int pfn1, pfn2;
-		struct page *page, *end;
-
-		pfn1 = __phys_to_pfn(reg->base);
-		pfn2 = pfn1 + __phys_to_pfn(reg->size);
-
-		page = pfn_to_page(pfn1);
-		end  = pfn_to_page(pfn2 - 1) + 1;
-
-		do {
-			if (PageReserved(page))
-				reserved_pages++;
-			else if (!page_count(page))
-				free_pages++;
-			page++;
-		} while (page < end);
-	}
-
-	/*
-	 * Since our memory may not be contiguous, calculate the real number
-	 * of pages we have in this system.
-	 */
-	pr_info("Memory:");
-	num_physpages = 0;
-	for_each_memblock(memory, reg) {
-		unsigned long pages = memblock_region_memory_end_pfn(reg) -
-			memblock_region_memory_base_pfn(reg);
-		num_physpages += pages;
-		printk(" %ldMB", pages >> (20 - PAGE_SHIFT));
-	}
-	printk(" = %luMB total\n", num_physpages >> (20 - PAGE_SHIFT));
-
-	pr_notice("Memory: %luk/%luk available, %luk reserved\n",
-		  nr_free_pages() << (PAGE_SHIFT-10),
-		  free_pages << (PAGE_SHIFT-10),
-		  reserved_pages << (PAGE_SHIFT-10));
+	mem_init_print_info();
 
 #define MLK(b, t) b, t, ((t) - (b)) >> 10
 #define MLM(b, t) b, t, ((t) - (b)) >> 20
@@ -366,7 +324,7 @@ void __init mem_init(void)
 	BUILD_BUG_ON(TASK_SIZE_64			> MODULES_VADDR);
 	BUG_ON(TASK_SIZE_64				> MODULES_VADDR);
 
-	if (PAGE_SIZE >= 16384 && num_physpages <= 128) {
+	if (PAGE_SIZE >= 16384 && get_num_physpages() <= 128) {
 		extern int sysctl_overcommit_memory;
 		/*
 		 * On a machine this small we won't get anywhere without
-- 
1.7.9.5



From ezequiel.garcia at free-electrons.com  Sat Apr  6 10:50:52 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Sat, 6 Apr 2013 11:50:52 -0300
Subject: [PATCH v3 1/5] drivers: memory: Introduce Marvell EBU Device Bus
 driver
In-Reply-To: <201304061534.36682.arnd@arndb.de>
References: <1365246930-13315-1-git-send-email-ezequiel.garcia@free-electrons.com>
 <1365246930-13315-2-git-send-email-ezequiel.garcia@free-electrons.com>
 <201304061534.36682.arnd@arndb.de>
Message-ID: <20130406145051.GA2358@localhost>

Hi Arnd,

On Sat, Apr 06, 2013 at 03:34:36PM +0200, Arnd Bergmann wrote:
> On Saturday 06 April 2013, Ezequiel Garcia wrote:
> > +       device-bus at d0010400 {
> > +               status = "okay";
> > +               ranges = <0 0 0xf0000000 0x1000000>; /* CS0 @addr 0xf0000000, size 0x1000000 */
> > +               #address-cells = <2>;
> > +               #size-cells = <1>;
> > +
> > +               flash at 0 {
> > +                       compatible = "cfi-flash";
> > +
> > +                       /* CS0, 16 MiB */
> > +                       reg = <0 0 0x1000000>;
> > +                       bank-width = <2>;
> > +                       #address-cells = <1>;
> > +                       #size-cells = <1>;
> > +
> > +                       /* Device Bus parameters are required */
> > +
> > +                       /* Read parameters */
> > +                       devbus,dev-width    = <1>;
> > +                       devbus,turn-off-ps  = <60000>;
> > +                       devbus,badr-skew-ps = <0>;
> > +                       devbus,acc-first-ps = <124000>;
> > +                       devbus,acc-next-ps  = <248000>;
> > +                       devbus,rd-setup-ps  = <0>;
> > +                       devbus,rd-hold-ps   = <0>;
> 
> I just read the email from Jason Gunthorpe suggesting to have a separate
> device-bus instance for each CS under it.
> 
> I think the implication of that is that all the "devbus,..." properties can
> now be moved into the parent node, which makes the split between the
> devbus node and its attached device clearer.
> 

Okey, I'll send a v4 fixing all your comments and implementing Jason's idea.

Thanks for the review!
-- 
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com


From grant.likely at secretlab.ca  Sat Apr  6 13:46:52 2013
From: grant.likely at secretlab.ca (Grant Likely)
Date: Sat, 6 Apr 2013 18:46:52 +0100
Subject: [GIT PULL] Multi Cluster Power Management infrastructure
In-Reply-To: <201304052233.25630.arnd@arndb.de>
References: <alpine.LFD.2.03.1303251219530.1372@syhkavp.arg>
 <alpine.LFD.2.03.1304042138160.1171@syhkavp.arg>
 <20130405094159.GH17995@n2100.arm.linux.org.uk>
 <201304052233.25630.arnd@arndb.de>
Message-ID: <CACxGe6sg==Zb56vVXeege29HovOpwtcosJk7ssw=wGCLV38j3A@mail.gmail.com>

On Fri, Apr 5, 2013 at 9:33 PM, Arnd Bergmann <arnd at arndb.de> wrote:
> On Friday 05 April 2013, Russell King - ARM Linux wrote:
>>
>> Now, I'm currently on holiday.  I'm going to be on holday until after
>> mid-April.  I'm not pulling anything until then.  I'm not applying anything
>> until then.  I'm not even reading this mailbox - and given current mail
>> rates at 300-400 messages per day, I will *not* be reading back over a
>> fortnights worth of email.
>
> I haven't reviewed the patches before, and only heard of the controversy
> from Nico's email yesterday. Independent of your personal situation and
> who implemented the code, I think it's clear that a lot of people (not
> just Linaro) want to see it get merged and not having it upstream is
> blocking platform specific code from getting put into arm-soc.
>
> Since you are currently on holiday, I think it's best if we at least put
> it into asm-soc as a for-rmk/mcpm branch in order to give it coverage
> in linux-next and let us merge the dependent platform code into "late"
> branches for 3.10. I still hope the nontechnical issues can be resolved
> in time to let you pull it into your tree before the merge window.

I agree. This makes the most sense. There is no reason for mcpm to be
excluded from linux-next before this issue is resolved.

g.


From mfuzzey at gmail.com  Sat Apr  6 13:51:55 2013
From: mfuzzey at gmail.com (Martin Fuzzey)
Date: Sat, 6 Apr 2013 19:51:55 +0200
Subject: [RFC PATCH] CLK: Allow parent clock and rate to be configured in
 DT.
In-Reply-To: <6581638.FPkNsv6peb@flatron>
References: <20130319170933.28337.50448.stgit@localhost>
 <CAOMZO5ASkvquyzPCEGObvB5Xh9bDPTJ2zx26eOUJT_Vb36Bn3Q@mail.gmail.com>
 <CAKGA1bkWLrOs15ni=8D__BvuG6kvqkeeLZGOLrVZY9g0q0z4Bg@mail.gmail.com>
 <6581638.FPkNsv6peb@flatron>
Message-ID: <CALBypN4mHwWZNiAQqErh1bL1sPHNuRbO5-yxzY+R1enQqEJOSQ@mail.gmail.com>

On Sat, Apr 6, 2013 at 3:21 PM, Tomasz Figa <tomasz.figa at gmail.com> wrote:
> Hi,
>
> [RANT]
>
> I tend to disagree about this whole hype about device tree usage for other
> things than pure hardware description. I don't think device tree should be
> a way to force some kind of new world order, but rather a more convenient
> and more maintainable (than board files) way of support hardware platforms
> in Linux kernel.
>
Totally agree

> On Friday 05 of April 2013 20:07:09 Matt Sealey wrote:
>>
>> The device tree concept is NOT a place to dump configuration items for
>> your board as hardcoded values to try and force something you could
>> have done elsewhere. On i.MX53 you cannot boot a kernel verbatim - you
>> at least have to run through the Boot ROM and supply a DCD table or
>> plugins first. This is where you figure things like this out.
>

You're suggesting setting the frequencies, parents etc in the DCD table??
Why?
IMHO that's horribly unreadable.

> But you can't always have control over the bootloader. What's wrong in
> letting the kernel configure the board itself? It must configure most of
> the hardware anyway, based on platform data (either located in board files
> or parsed from device tree).
>
> Why not to make the kernel independent from the bootloader at all? Then
> the bootloader could just do some minimal initialization needed to load a
> kernel image from flash memory and launch it (+ some code to allow
> flashing of new images).
>

Yes that's my opinion too.

I think the bootloader should really do as little as possible since:
* It's generally harder and/or riskier to update the bootloader than
the kernel (althugh somewhat less true these days with boot from SD)
* There are multiple bootloaders (u-boot, barebox, ...) but only one kernel
* It makes it easier to do product families where you have a common
bootloader and kernel image with different DTBs per variant. You can
then put all the DTBs in the boot partition and use a bootloader
variable to chose the right one.

>> I am totally against this (sorry Sascha..). Let's put some effort into
>> fixing the bootloaders rather than trying to use the device tree to
>> enforce the ridiculous assumption that "Linux kernel does not trust
>> the bootloader".
Why is this "rediculous" IMHO the kernel shouldn't trust the
bootloader, beyond having setting up the hardware sufficiently to
reliably and safely execute code.

>> Once the bindings and trees are out of the kernel
>> source, you're going to HAVE to trust what the bootloader passes, be
>> it pregenerated compiled blob (which needs to be written to match the
>> hardware state the bootloader finishes up at) or dynamically generated
>> at runtime during the boot process (which can describe to the bit what
>> the hardware is doing).

You have to trust the DTB yes but that is not the same as trusting the
bootloader to have setup the hardware.
I fail to see what difference it makes if the DTS is inside or outside
the kernel source. Even today you can compile a DTB from out of tree
DTS and pass it to a mainline kernel.


Regards,

Martin


From linux at prisktech.co.nz  Sat Apr  6 14:33:35 2013
From: linux at prisktech.co.nz (Tony Prisk)
Date: Sun, 07 Apr 2013 06:33:35 +1200
Subject: PWM backlight build warning
Message-ID: <51606A7F.3050803@prisktech.co.nz>

Hi Thierry,

Sorry it's taken so long to report this but I've been tied up with other 
patches recently. I noticed a build warning on the pwm_bl driver in 
3.9-rcX but I'm not sure what the correct resolution would be. This patch:

commit e2c17bc6f717a8847df2a867caec6ba4fe85f3fc
backlight: convert pwm_bl to dev_pm_ops

Should be no functional changes, mainly a reorganisation to support 
future work.

[akpm at linux-foundation.org: fix CONFIG_PM=n build]
Signed-off-by: Mark Brown <broonie at opensource.wolfsonmicro.com>
Cc: Richard Purdie <rpurdie at rpsys.net>
Cc: Florian Tobias Schandinat <FlorianSchandinat at gmx.de>
Signed-off-by: Andrew Morton <akpm at linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds at linux-foundation.org>

has introduced a two build warnings in my config:
drivers/video/backlight/pwm_bl.c:278:12: warning: 
?pwm_backlight_suspend? defined but not used [-Wunused-function]
drivers/video/backlight/pwm_bl.c:292:12: warning: ?pwm_backlight_resume? 
defined but not used [-Wunused-function]

Although I noticed it doesn't have your acked-by ;)


Selecting "Run-time PM core functionality" without "Suspend to RAM and 
standby" causes the unused function warning.
With CONFIG_PM=n, no warnings. With CONFIG_PM=y and CONFIG_PM_SLEEP=y, 
no warnings.

The problem occurs because when CONFIG_PM=y but CONFIG_PM_SLEEP=n:

#define SIMPLE_DEV_PM_OPS(name, suspend_fn, resume_fn) \
const struct dev_pm_ops name = { \
SET_SYSTEM_SLEEP_PM_OPS(syspend_fn, resume_fn) \
}

#ifdef CONFIG_PM_SLEEP
#define SET_SYSTEM_SLEEP_PM_OPS(suspend_fn, resume_fn) \
.suspend = suspend_fn, \
.resume = resume_fn, \
.freeze = suspend_fn, \
.thaw = resume_fn, \
.poweroff = suspend_fn, \
.restore = resume_fn,
#else
#define SET_SYSTEM_SLEEP_PM_OPS(suspend_fn, resume_fn)
#endif

I guess this would be a problem on every driver that has been converted 
to SIMPLE_DEV_PM_OPS.
I don't know enough about the PM code to offer a fix, or whethermy 
chosen config is just 'invalid'.

Regards
Tony P


From matt at genesi-usa.com  Sat Apr  6 15:24:36 2013
From: matt at genesi-usa.com (Matt Sealey)
Date: Sat, 6 Apr 2013 14:24:36 -0500
Subject: [RFC PATCH] CLK: Allow parent clock and rate to be configured in
 DT.
In-Reply-To: <CALBypN4mHwWZNiAQqErh1bL1sPHNuRbO5-yxzY+R1enQqEJOSQ@mail.gmail.com>
References: <20130319170933.28337.50448.stgit@localhost>
 <CAOMZO5ASkvquyzPCEGObvB5Xh9bDPTJ2zx26eOUJT_Vb36Bn3Q@mail.gmail.com>
 <CAKGA1bkWLrOs15ni=8D__BvuG6kvqkeeLZGOLrVZY9g0q0z4Bg@mail.gmail.com>
 <6581638.FPkNsv6peb@flatron>
 <CALBypN4mHwWZNiAQqErh1bL1sPHNuRbO5-yxzY+R1enQqEJOSQ@mail.gmail.com>
Message-ID: <CAKGA1b=Z4M6t4BVFyfqxq=iZ6MHGbgHf5WodGbTCSaC7E_b7FA@mail.gmail.com>

On Sat, Apr 6, 2013 at 12:51 PM, Martin Fuzzey <mfuzzey at gmail.com> wrote:
> On Sat, Apr 6, 2013 at 3:21 PM, Tomasz Figa <tomasz.figa at gmail.com> wrote:
>> Hi,
>>
>> [RANT]
>>
>> I tend to disagree about this whole hype about device tree usage for other
>> things than pure hardware description. I don't think device tree should be
>> a way to force some kind of new world order, but rather a more convenient
>> and more maintainable (than board files) way of support hardware platforms
>> in Linux kernel.
>>
> Totally agree
>
>> On Friday 05 of April 2013 20:07:09 Matt Sealey wrote:
>>>
>>> The device tree concept is NOT a place to dump configuration items for
>>> your board as hardcoded values to try and force something you could
>>> have done elsewhere. On i.MX53 you cannot boot a kernel verbatim - you
>>> at least have to run through the Boot ROM and supply a DCD table or
>>> plugins first. This is where you figure things like this out.
>>
>
> You're suggesting setting the frequencies, parents etc in the DCD table??

It's one option.. you should also be doing IOMUX somewhere very early
too for *everything* you can, as changing pad settings on the fly can
be electrically problematic. You wouldn't change an input to an output
8 seconds into the board's boot process if you could do it 8ns into
it. Our HW designers constantly freak out over doing pinctrl stuff so
late in the process..

> Why?

Because the earlier you do it, the better.

> IMHO that's horribly unreadable.

So is most of the low level init code for anything; fact of life. Have
you ever looked at the lib/ and kernel/ directories in the kernel
tree? The code that deals with low-level debug and earlyprintk?

The device tree isn't meant to make that part easier it's to describe
what you did there (and potentially verify it ;)

>> Why not to make the kernel independent from the bootloader at all? Then
>> the bootloader could just do some minimal initialization needed to load a
>> kernel image from flash memory and launch it (+ some code to allow
>> flashing of new images).
>
> Yes that's my opinion too.
>
> I think the bootloader should really do as little as possible since:
> * It's generally harder and/or riskier to update the bootloader than
> the kernel (althugh somewhat less true these days with boot from SD)

Although you cannot guarantee your system can even boot from SD (or
even has an SD slot to do so). It could be SPI NOR or MLC NAND on some
bus, or something more esoteric. Updating a bootloader is not really
that risky anymore - I would agree outright that it is undesirable to
do too often, but there are ways around this that don't involve adding
to the device tree in such a way that you are basically explaining all
the items the bootloader forgot (or was so badly written, it did not
do). If you want USB networking, you need to bring up USB. If you want
to store the environment, you need to set up some environment storage.
You're configuring the memory controller, memory clock, regulators and
getting to the point you have a serial console that will effectively
load a kernel from your chosen place to memory and execute it - at
this point I don't understand why setting CLKO's parent and it's
divider (two.. register.. writes...) is somehow so difficult and
requires a device tree binding.

Once it's set up, as I said there are bindings for fixed
always-running clocks, fixed toggled clocks, and dynamic clocks, which
covers all cases.

> * There are multiple bootloaders (u-boot, barebox, ...) but only one kernel

No, I can think of multiple operating systems that could possibly run
here.. VxWorks, Integrity, QNX, L4 (Fiasco, Pistachio), NetBSD,
FreeBSD,  and in Sascha's example, OpenBSD.. Darwin/XNU? We're walkng
further into territory of "it will never happen anyway" but I know the
first 7 boot on a ton of i.MX processors and they could all use device
tree at some point.

All of which need to do the same setup anyway - Linux requires one
hell of a lot of low level initialization of the CPU on ARM and x86
platforms; if we're moving errata fixes out to the bootloader to deal
with TrustZone on ARM, then there is already a lot of "unreadable"
assembly code in there. To boot Linux from SD card on i.MX you need to
set up the SD card IOMUX (Boot ROM does this for the one you for the
one you chose, but if you did not choose it, it isn't set up).

The fragmentation of bootloaders (U-Boot, barebox, moboot..) is not a
technology issue but a political one. The stuff we're talking about
here is usually cut & pastable and if the vendor of the hardware
releases an opensource bootloader - eminently so. If it's a closed
bootloader, well... you're SOL. That is a problem, but that is not a
problem the device tree is meant to solve. The correct way to deal
with that is refuse Linux support until they do things right, or have
things broken until they do things right. Eventually they will figure
it out.. but the idea would be to not have a lot of platform setup
code living in the kernel and moving around between DIFFERENT kernels.
The device tree is one solution - describe an interface between
unknown bootloader "foo" and operating system kernel "bar" - but that
doesn't mean it replaces the concept that it needs

> * It makes it easier to do product families where you have a common
> bootloader and kernel image with different DTBs per variant. You can
> then put all the DTBs in the boot partition and use a bootloader
> variable to chose the right one.

That doesn't mean you can't have the bootloader know which
device/board it is running on. How does that variable get set? If that
variable is set at runtime, surely then it can perform all this setup
before it sets the variable?

>>> I am totally against this (sorry Sascha..). Let's put some effort into
>>> fixing the bootloaders rather than trying to use the device tree to
>>> enforce the ridiculous assumption that "Linux kernel does not trust
>>> the bootloader".
>
> Why is this "rediculous" IMHO the kernel shouldn't trust the
> bootloader, beyond having setting up the hardware sufficiently to
> reliably and safely execute code.

Here we are merely differing on the definition of "sufficiently to
reliably and safely execute code".

We're in an age of SoCs, I remember in the desktop PowerPC days and
older x86 days of northbridges, southbridges and peripherals you only
had responsibility to bring up the CPU, but again you had to configure
a PCI host controller, USB, IDE drives, display, mouse and keyboard of
some kind... and setting up one clock that's not used right now but
will be by the OS is NOT a lot of code on top of all that. Now most of
that is basically, practically required.. on most of the boards we're
looking at supporting in the Linux ARM DT kernel support right now,
it's pretty much all esoteric development boards with more pin headers
than actual features, and Android development kits that are just
tablets without cases - they are designed to have you mess with the
bootloader.

If we don't support those boards properly by properly implementing
bootloader support and setup, it means consumer devices based on them
do not follow the best practises of doing this stuff in the bootloader
before the OS - which is a more lean, easier to test environment
anyway. We're talking here about one device where we want a clock
output for a codec from the SoC, did anyone even sit down, put a scope
on a test pad and be sure that the clock is stable, not full of
jitter, and has the right logic levels? The best place to do that is
after you set it up, no-autoboot U-Boot in most of these cases and for
more proprietary systems, since most hardware designers end up doing
this anyway, usually the code is around somewhere.

>>> Once the bindings and trees are out of the kernel
>>> source, you're going to HAVE to trust what the bootloader passes, be
>>> it pregenerated compiled blob (which needs to be written to match the
>>> hardware state the bootloader finishes up at) or dynamically generated
>>> at runtime during the boot process (which can describe to the bit what
>>> the hardware is doing).
>
> You have to trust the DTB yes but that is not the same as trusting the
> bootloader to have setup the hardware.
>
> I fail to see what difference it makes if the DTS is inside or outside
> the kernel source. Even today you can compile a DTB from out of tree
> DTS and pass it to a mainline kernel.

Indeed, but you can guarantee in the time it took you to do that
someone changed a binding because the source code for the DTS, and the
documentation for the binding, is still part of Linux and it means
Linux "hack it in and we'll do it properly later" design methodology
comes into play.

If you have a fixed clock which cannot change, and the bare minimum
functionality implemented is gating, you need to set this up in the
bootloader and - at option, depending on if it's needed to boot - gate
it. Then tell Linux there's a fixed rate clock and it can turn it on
and off via the device tree.. that's the solution here, it's already
written and has bindings, we don't need new ones to cover the case
whereby someone forgot to do so.

I am going to stand by my little proposal; we modify the clock
initialization so effectively check whether the parent in the DTB is
the same as the one in hardware, and if not then report this fact (and
optionally set that clock's parent to the one in the DTB). This is a
sly back-door approach in one sense, but in the future when people
build a board, put initial revision of bootloader code on the board,
boot a kernel with a device tree that is not describing the hardware,
they will see warnings; "Your clock "fooclk" isn't the same as your DT
says it is. Fix the bootloader, please."

And they will. This means the bootloader gets easier to trust for
every new board.

As for giving devices some configuration so they can "force" a clock
frequency, I don't like that idea. In the event it is derived from a
clock somewhere, in the audio codec case and in many others it is
better to do this on the basis of power management or configuration
"selection" - you describe all the possible ways it can be configured
for certain features (for instance, 27MHz clock frequency allows audio
rates of 8000, 16000, 32000, 44100, 48000Hz and 24MHz allows 8000,
16000, 32000, 44100, 48000, 88200, 96000Hz) and the driver can make an
assessment of what clock it has - clk_get_rate tells it which clock it
has (lets assume the board booted with a 27MHz clock). If it can set
the clock to one that supports more rates, it can do so - in this
case, it would decide it wants 96KHz support, so it clk_set_rate it to
24MHz. The frequency support (and bit format support too) should be in
the device tree so that given a supplied clock phandle it can find out
the current rate, derive supported modes, and then set a better rate
if that's functional. "Setting the clock rate based on configuration
items in some clock-configuration tree" is too much of a specific fix,
for in this case one particular device. But most devices can support a
list of potential configurations FOR THAT DEVICE (the same way a clock
can have many parents already, but only one can be set) and the DT is
exactly there to describe these, and the best practise code in the
driver would basically - by the back door - fix the clock for us.

I still say the desired clock, implemented by the HW designer, should
be done in the bootloader though (that way no clock changes happen
inside Linux) and we can figure a much, MUCH more consistent way of
allowing drivers to actually "set the clock it wants" without it being
a clock-subsystem thing. It is the device that has the requirement for
the clock frequency after all, not the clock subsystem.

-- 
Matt Sealey <matt at genesi-usa.com>


From w at 1wt.eu  Sat Apr  6 15:29:57 2013
From: w at 1wt.eu (Willy Tarreau)
Date: Sat, 6 Apr 2013 21:29:57 +0200
Subject: [PATCH] ARM: makefile: add tuning options for Armada 370/XP
Message-ID: <20130406192957.GQ11459@1wt.eu>

Hi,

A patch from Marvell was merged in GCC 4.8 to add support for their
PJ4 CPU core used in Armada370 and XP. I noticed a steady 2% network
performance increase using -mcpu=marvell-pj4 and around 1% when using
-mtune=xscale instead. I have no idea whether it provides anything to
the Dove platform and I don't have one to test, so I didn't touch it.

Now that 4.8 is released, it would be nice to have this option used
when supported.

Regards,
Willy

>From b5b34f87e753fbd756f3c23536e731bb1aa6bf7f Mon Sep 17 00:00:00 2001
From: Willy Tarreau <w at 1wt.eu>
Date: Sun, 3 Mar 2013 23:26:41 +0100
Subject: [PATCH] ARM: makefile: add tuning options for Armada 370/XP

Let's pass -mcpu=marvell-pj4 and fall back to -mtune=xscale for Armada370
and ArmadaXP. Both settings have shown an improvement over the default
setting on these chips using gcc-4.7 with and without the Marvell patch
(typically 2% on network traffic).

Signed-off-by: Willy Tarreau <w at 1wt.eu>
---
 arch/arm/Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 15747d9..7dd5418 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -93,6 +93,7 @@ tune-$(CONFIG_CPU_XSC3)		:=$(call cc-option,-mtune=xscale,-mtune=strongarm110) -
 tune-$(CONFIG_CPU_FEROCEON)	:=$(call cc-option,-mtune=marvell-f,-mtune=xscale)
 tune-$(CONFIG_CPU_V6)		:=$(call cc-option,-mtune=arm1136j-s,-mtune=strongarm)
 tune-$(CONFIG_CPU_V6K)		:=$(call cc-option,-mtune=arm1136j-s,-mtune=strongarm)
+tune-$(CONFIG_MACH_ARMADA_370_XP)	:=$(call cc-option,-mcpu=marvell-pj4,-mtune=xscale)
 
 ifeq ($(CONFIG_AEABI),y)
 CFLAGS_ABI	:=-mabi=aapcs-linux -mno-thumb-interwork
-- 
1.7.12.2.21.g234cd45.dirty



From festevam at gmail.com  Sat Apr  6 15:40:48 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Sat, 6 Apr 2013 16:40:48 -0300
Subject: [RFC PATCH] CLK: Allow parent clock and rate to be configured in
 DT.
In-Reply-To: <CAKGA1b=Z4M6t4BVFyfqxq=iZ6MHGbgHf5WodGbTCSaC7E_b7FA@mail.gmail.com>
References: <20130319170933.28337.50448.stgit@localhost>
 <CAOMZO5ASkvquyzPCEGObvB5Xh9bDPTJ2zx26eOUJT_Vb36Bn3Q@mail.gmail.com>
 <CAKGA1bkWLrOs15ni=8D__BvuG6kvqkeeLZGOLrVZY9g0q0z4Bg@mail.gmail.com>
 <6581638.FPkNsv6peb@flatron>
 <CALBypN4mHwWZNiAQqErh1bL1sPHNuRbO5-yxzY+R1enQqEJOSQ@mail.gmail.com>
 <CAKGA1b=Z4M6t4BVFyfqxq=iZ6MHGbgHf5WodGbTCSaC7E_b7FA@mail.gmail.com>
Message-ID: <CAOMZO5CcQgf+sTBNKhwXb8FWN3XN4f2Sgjfp5KHup6feOs4h9A@mail.gmail.com>

Matt,

On Sat, Apr 6, 2013 at 4:24 PM, Matt Sealey <matt at genesi-usa.com> wrote:

> Indeed, but you can guarantee in the time it took you to do that
> someone changed a binding because the source code for the DTS, and the
> documentation for the binding, is still part of Linux and it means
> Linux "hack it in and we'll do it properly later" design methodology
> comes into play.
>
> If you have a fixed clock which cannot change, and the bare minimum
> functionality implemented is gating, you need to set this up in the
> bootloader and - at option, depending on if it's needed to boot - gate
> it. Then tell Linux there's a fixed rate clock and it can turn it on
> and off via the device tree.. that's the solution here, it's already
> written and has bindings, we don't need new ones to cover the case
> whereby someone forgot to do so.
>
> I am going to stand by my little proposal; we modify the clock
> initialization so effectively check whether the parent in the DTB is
> the same as the one in hardware, and if not then report this fact (and
> optionally set that clock's parent to the one in the DTB). This is a
> sly back-door approach in one sense, but in the future when people
> build a board, put initial revision of bootloader code on the board,
> boot a kernel with a device tree that is not describing the hardware,
> they will see warnings; "Your clock "fooclk" isn't the same as your DT
> says it is. Fix the bootloader, please."

Care to submit a patch about your proposal for the codec clock example, please?

It makes much easier to get comments/testing, etc in a real patch format.

I will be glad to test your proposal if you submit a patch for it.

Thanks,

Fabio Estevam


From broonie at opensource.wolfsonmicro.com  Sat Apr  6 16:02:51 2013
From: broonie at opensource.wolfsonmicro.com (Mark Brown)
Date: Sat, 6 Apr 2013 21:02:51 +0100
Subject: PWM backlight build warning
In-Reply-To: <51606A7F.3050803@prisktech.co.nz>
References: <51606A7F.3050803@prisktech.co.nz>
Message-ID: <20130406200251.GO6597@opensource.wolfsonmicro.com>

On Sun, Apr 07, 2013 at 06:33:35AM +1200, Tony Prisk wrote:

> The problem occurs because when CONFIG_PM=y but CONFIG_PM_SLEEP=n:

> I guess this would be a problem on every driver that has been
> converted to SIMPLE_DEV_PM_OPS.
> I don't know enough about the PM code to offer a fix, or whethermy
> chosen config is just 'invalid'.

You just need to put the system suspend functions inside an ifdef
CONFIG_PM_SLEEP instead of CONFIG_PM.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130406/4475b2d3/attachment.sig>

From festevam at gmail.com  Sat Apr  6 16:21:37 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Sat, 6 Apr 2013 17:21:37 -0300
Subject: [PATCH v2 0/3] Get rid of big array from imx pinctrl driver
In-Reply-To: <1361533888-18073-1-git-send-email-shawn.guo@linaro.org>
References: <1361533888-18073-1-git-send-email-shawn.guo@linaro.org>
Message-ID: <CAOMZO5D1+baoM0vMdPW9bAd4DX8C82BF9H87igFNo78+8D_N3Q@mail.gmail.com>

Hi Shawn,

On Fri, Feb 22, 2013 at 8:51 AM, Shawn Guo <shawn.guo at linaro.org> wrote:
> Changes since v1:
>  * Remove the absolute path of imxXX-pinfunc.h in binding doc
>  * Remove the pin id from PIN_FUNC_ID/macro
>
> Shawn Guo (3):
>   ARM: dts: imx: use pre-processor for device trees
>   ARM: dts: imx: replace magic number with pin function name
>   pinctrl: imx: move hard-coding data into device tree

The last patch breaks audio on mx6qsabrelite: after a aplay command
the processor hangs.


From thierry.reding at avionic-design.de  Sat Apr  6 17:10:42 2013
From: thierry.reding at avionic-design.de (Thierry Reding)
Date: Sat, 6 Apr 2013 23:10:42 +0200
Subject: PWM backlight build warning
In-Reply-To: <20130406200251.GO6597@opensource.wolfsonmicro.com>
References: <51606A7F.3050803@prisktech.co.nz>
 <20130406200251.GO6597@opensource.wolfsonmicro.com>
Message-ID: <20130406211041.GA15987@avionic-0098.mockup.avionic-design.de>

On Sat, Apr 06, 2013 at 09:02:51PM +0100, Mark Brown wrote:
> On Sun, Apr 07, 2013 at 06:33:35AM +1200, Tony Prisk wrote:
> 
> > The problem occurs because when CONFIG_PM=y but CONFIG_PM_SLEEP=n:
> 
> > I guess this would be a problem on every driver that has been
> > converted to SIMPLE_DEV_PM_OPS.
> > I don't know enough about the PM code to offer a fix, or whethermy
> > chosen config is just 'invalid'.
> 
> You just need to put the system suspend functions inside an ifdef
> CONFIG_PM_SLEEP instead of CONFIG_PM.

I carry a fix for that in my for-next branch.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130406/9787f143/attachment.sig>

From gregory.clement at free-electrons.com  Sat Apr  6 17:48:28 2013
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Sat, 06 Apr 2013 23:48:28 +0200
Subject: [PATCH] ARM: makefile: add tuning options for Armada 370/XP
In-Reply-To: <20130406192957.GQ11459@1wt.eu>
References: <20130406192957.GQ11459@1wt.eu>
Message-ID: <5160982C.9090702@free-electrons.com>

Hi Willy,

On 04/06/2013 09:29 PM, Willy Tarreau wrote:
> Hi,
> 
> A patch from Marvell was merged in GCC 4.8 to add support for their
> PJ4 CPU core used in Armada370 and XP. I noticed a steady 2% network
> performance increase using -mcpu=marvell-pj4 and around 1% when using
> -mtune=xscale instead. I have no idea whether it provides anything to
> the Dove platform and I don't have one to test, so I didn't touch it.
> 
> Now that 4.8 is released, it would be nice to have this option used
> when supported.

Sure it will be very nice! But what happens when the kernel is built
in multiarch?
It seems to me that in this case gcc will tune the code for PJ4 whereas
the kernel built can also be run on a Cortex-A, a Scorpion or a Krait.

Regards,
> 
> Regards,
> Willy
> 
> From b5b34f87e753fbd756f3c23536e731bb1aa6bf7f Mon Sep 17 00:00:00 2001
> From: Willy Tarreau <w at 1wt.eu>
> Date: Sun, 3 Mar 2013 23:26:41 +0100
> Subject: [PATCH] ARM: makefile: add tuning options for Armada 370/XP
> 
> Let's pass -mcpu=marvell-pj4 and fall back to -mtune=xscale for Armada370
> and ArmadaXP. Both settings have shown an improvement over the default
> setting on these chips using gcc-4.7 with and without the Marvell patch
> (typically 2% on network traffic).
> 
> Signed-off-by: Willy Tarreau <w at 1wt.eu>
> ---
>  arch/arm/Makefile | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> index 15747d9..7dd5418 100644
> --- a/arch/arm/Makefile
> +++ b/arch/arm/Makefile
> @@ -93,6 +93,7 @@ tune-$(CONFIG_CPU_XSC3)		:=$(call cc-option,-mtune=xscale,-mtune=strongarm110) -
>  tune-$(CONFIG_CPU_FEROCEON)	:=$(call cc-option,-mtune=marvell-f,-mtune=xscale)
>  tune-$(CONFIG_CPU_V6)		:=$(call cc-option,-mtune=arm1136j-s,-mtune=strongarm)
>  tune-$(CONFIG_CPU_V6K)		:=$(call cc-option,-mtune=arm1136j-s,-mtune=strongarm)
> +tune-$(CONFIG_MACH_ARMADA_370_XP)	:=$(call cc-option,-mcpu=marvell-pj4,-mtune=xscale)
>  
>  ifeq ($(CONFIG_AEABI),y)
>  CFLAGS_ABI	:=-mabi=aapcs-linux -mno-thumb-interwork
> 


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From w at 1wt.eu  Sat Apr  6 17:54:43 2013
From: w at 1wt.eu (Willy Tarreau)
Date: Sat, 6 Apr 2013 23:54:43 +0200
Subject: [PATCH] ARM: makefile: add tuning options for Armada 370/XP
In-Reply-To: <5160982C.9090702@free-electrons.com>
References: <20130406192957.GQ11459@1wt.eu>
 <5160982C.9090702@free-electrons.com>
Message-ID: <20130406215443.GT11459@1wt.eu>

Hi Gr?gory,

On Sat, Apr 06, 2013 at 11:48:28PM +0200, Gregory CLEMENT wrote:
> Hi Willy,
> 
> On 04/06/2013 09:29 PM, Willy Tarreau wrote:
> > Hi,
> > 
> > A patch from Marvell was merged in GCC 4.8 to add support for their
> > PJ4 CPU core used in Armada370 and XP. I noticed a steady 2% network
> > performance increase using -mcpu=marvell-pj4 and around 1% when using
> > -mtune=xscale instead. I have no idea whether it provides anything to
> > the Dove platform and I don't have one to test, so I didn't touch it.
> > 
> > Now that 4.8 is released, it would be nice to have this option used
> > when supported.
> 
> Sure it will be very nice! But what happens when the kernel is built
> in multiarch?
> It seems to me that in this case gcc will tune the code for PJ4 whereas
> the kernel built can also be run on a Cortex-A, a Scorpion or a Krait.

I have not thought about that. Maybe we're already reaching the limits of
the multiarch mode ? After all, pj4 is not a cortex-a, which probably is
the reason that justifies having specific gcc optimizations that are
different from cortex-a.

So in the end, I'm starting to wonder whether it makes sense to permit
non-100% compatible armv7 chips to coexist in the same kernel :-/

Otherwise we could do what already exists on x86, which is to let the
user select which chip he wants to optimize for. I have no idea on the
subject to be honnest.

Best regards,
Willy



From linux at prisktech.co.nz  Sat Apr  6 18:06:57 2013
From: linux at prisktech.co.nz (Tony Prisk)
Date: Sun, 07 Apr 2013 10:06:57 +1200
Subject: PWM backlight build warning
In-Reply-To: <20130406211041.GA15987@avionic-0098.mockup.avionic-design.de>
References: <51606A7F.3050803@prisktech.co.nz>
 <20130406200251.GO6597@opensource.wolfsonmicro.com>
 <20130406211041.GA15987@avionic-0098.mockup.avionic-design.de>
Message-ID: <51609C81.5030207@prisktech.co.nz>

On 07/04/13 09:10, Thierry Reding wrote:
> On Sat, Apr 06, 2013 at 09:02:51PM +0100, Mark Brown wrote:
>> On Sun, Apr 07, 2013 at 06:33:35AM +1200, Tony Prisk wrote:
>>
>>> The problem occurs because when CONFIG_PM=y but CONFIG_PM_SLEEP=n:
>>> I guess this would be a problem on every driver that has been
>>> converted to SIMPLE_DEV_PM_OPS.
>>> I don't know enough about the PM code to offer a fix, or whethermy
>>> chosen config is just 'invalid'.
>> You just need to put the system suspend functions inside an ifdef
>> CONFIG_PM_SLEEP instead of CONFIG_PM.
> I carry a fix for that in my for-next branch.
>
> Thierry
Ahh ok, all is good then.

Regards
Tony P


From linux at arm.linux.org.uk  Sat Apr  6 20:02:38 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Sun, 7 Apr 2013 01:02:38 +0100
Subject: [GIT PULL] Multi Cluster Power Management infrastructure
In-Reply-To: <201304052233.25630.arnd@arndb.de>
References: <alpine.LFD.2.03.1303251219530.1372@syhkavp.arg>
 <alpine.LFD.2.03.1304042138160.1171@syhkavp.arg>
 <20130405094159.GH17995@n2100.arm.linux.org.uk>
 <201304052233.25630.arnd@arndb.de>
Message-ID: <20130407000237.GI17995@n2100.arm.linux.org.uk>

On Fri, Apr 05, 2013 at 10:33:25PM +0200, Arnd Bergmann wrote:
> On Friday 05 April 2013, Russell King - ARM Linux wrote:
> > 
> > Now, I'm currently on holiday.  I'm going to be on holday until after
> > mid-April.  I'm not pulling anything until then.  I'm not applying anything
> > until then.  I'm not even reading this mailbox - and given current mail
> > rates at 300-400 messages per day, I will *not* be reading back over a
> > fortnights worth of email.
> 
> I haven't reviewed the patches before, and only heard of the controversy
> from Nico's email yesterday. Independent of your personal situation and
> who implemented the code, I think it's clear that a lot of people (not
> just Linaro) want to see it get merged and not having it upstream is
> blocking platform specific code from getting put into arm-soc.

Nicolas is doing what he always does when he doesn't get his own way - he
tries to force his way.  This is exactly what's going on here...

> Since you are currently on holiday, I think it's best if we at least put
> it into asm-soc as a for-rmk/mcpm branch in order to give it coverage
> in linux-next and let us merge the dependent platform code into "late"
> branches for 3.10. I still hope the nontechnical issues can be resolved
> in time to let you pull it into your tree before the merge window.

I doubt it will.  The way I now feel, I feel betrayed by Linaro, and
I feel that they have done me a great disservice.  I don't see that
there's anything Linaro has to offer me in way of work (if they could,
then they would be able to tell me what areas they have available -
but they can't even do that.)

How can this be resolved?  I've no idea, that's entirely up to Linaro
and its management to work out whether they actually have any work
available.  My conclusion, given the sparseness of any kind of idea of
work is that they do not have much idea about any kind of work, and
I suspect that they have no knowledge themselves as to what work
really needs to be done.

If there was one, then it would be nice and simple to include in an
email a list of work items that were available - but that's not what
has been done ove rthe last 4 months.

So no, _I_ can't resolve it until Linaro gets a handle on what the hell
that organization wants to do.

But the whole message here is: if you fuck me around commercially, you
can't *not* expect it to have an impact on what I volunteer to do, and
you'd better *not* put work-items on the table and then take them away
again, and then end up demanding that they be done for gratis just
because of my position.  *That* is grossly unfair.


From dt.tangr at gmail.com  Sat Apr  6 20:06:22 2013
From: dt.tangr at gmail.com (Daniel Tang)
Date: Sun, 7 Apr 2013 10:06:22 +1000
Subject: [RFC PATCH arm: initial TI-Nspire support]
In-Reply-To: <201304061524.56502.arnd@arndb.de>
References: <6FE4B33E-A503-4A75-AEED-831CB2C06D83@gmail.com>
 <201304061351.00889.arnd@arndb.de>
 <F832F4F9-8162-43B8-B9E0-D5D8C8B8C77A@gmail.com>
 <201304061524.56502.arnd@arndb.de>
Message-ID: <4B3FD561-84FC-40CD-B747-13851692D673@gmail.com>

Hi,

On 07/04/2013, at 12:24 AM, Arnd Bergmann <arnd at arndb.de> wrote:

>> arch/arm/Kconfig                                |   13 ++
>> arch/arm/Makefile                               |    3 +-
>> arch/arm/boot/dts/nspire-cx.dts                 |   85 +++++++++++++
>> arch/arm/boot/dts/nspire.dtsi                   |  154 +++++++++++++++++++++++
>> arch/arm/mach-nspire/Makefile                   |    3 +
>> arch/arm/mach-nspire/include/mach/debug-macro.S |   25 ++++
>> arch/arm/mach-nspire/include/mach/timex.h       |   15 +++
>> arch/arm/mach-nspire/include/mach/uncompress.h  |   25 ++++
>> arch/arm/mach-nspire/mmio.h                     |   13 ++
>> arch/arm/mach-nspire/nspire.c                   |  107 ++++++++++++++++
> 
> A good next step before doing anything else might be to put it under
> CONFIG_ARCH_MULTIPLATFORM and remove the include/mach directory.
> 
> The only requirement for that should be to move debug-macro.S to
> include/debug/nspire.S
> 

Done.
> 
> 
>> @@ -313,7 +314,7 @@ define archhelp
>>   echo  '  Image         - Uncompressed kernel image (arch/$(ARCH)/boot/Image)'
>>   echo  '* xipImage      - XIP kernel image, if configured (arch/$(ARCH)/boot/xipImage)'
>>   echo  '  uImage        - U-Boot wrapped zImage'
>> -  echo  '  bootpImage    - Combined zImage and initial RAM disk' 
>> +  echo  '  bootpImage    - Combined zImage and initial RAM disk'
>>   echo  '                  (supply initrd image via make variable INITRD=<path>)'
>>   echo  '* dtbs          - Build device tree blobs for enabled boards'
>>   echo  '  install       - Install uncompressed kernel'
> 
> This looks like it wasn't meant to be in the patch.

It probably isn't. I think there was trailing whitespace on that and my editor happened to remove it automatically.

Should this be a separate patch to fix up formatting or should I leave it in as a drive-by fix?

> 
>> +		tdes: tdes at C8010000 {
>> +			reg = <0xC8010000 0x1000>;
>> +		};
>> +
>> +		sha256: sha256 at CC000000 {
>> +			reg = <0xCC000000 0x1000>;
>> +		};
> 
> maybe rename the actual nodes to "crypto at c...". The device name should
> be a really generic word in general.

Done.

> 
>> +			uart: uart at 90020000 {
>> +				reg = <0x90020000 0x1000>;
>> +				interrupts = <1>;
>> +
>> +				clocks = <&uart_clk>;
>> +				clock-names = "uart_clk";
>> +			};
> 
> The name for a uart should be "serial". Since this is a pl01x, please add
> the required properties for the device, e.g. 
> 
> 	compatible = "arm,pl011", "arm,primecell";
> 
> You will need the "arm,primecell" bit to make the device appear on the
> amba bus rather than the platform bus.

That was actually deliberate because different models of the TI-NSPIRE have different serial hardware. On the newer CX models, it is a PL01x and on the older models, it has a 8250-like interface. They all reside at the same address with the same IRQ though.

I thought it might be cleaner to specify the interrupts and registers in the common file and leave it to the board specific ones to implement the "compatible" property.

> 
>> +			timer0: timer0 at 900C0000 {
>> +				reg = <0x900C0000 0x1000>;
>> +				interrupts = <18>;
>> +
>> +				clocks = <&timer_clk>;
>> +				clock-names = "timer_clk";
>> +			};
>> +
>> +			timer1: timer1 at 900D0000 {
>> +				reg = <0x900D0000 0x1000>;
>> +				interrupts = <19>;
>> +
>> +				clocks = <&timer_clk>;
>> +				clock-names = "timer_clk";
>> +			};
> 
> Name the devices "timer", not "timer0" and "timer1", the address after @ is
> used to disambiguate them. There are currently patches for sp804 under
> discussion on the mailing list, you should probably watch those.
> 

Done. Yep, I also noticed there were patches to have device tree bindings for SP804. I'll integrate them once they're in mainline.

>> --- /dev/null
>> +++ b/arch/arm/mach-nspire/Makefile
>> @@ -0,0 +1,3 @@
>> +obj-y				:=
>> +
>> +obj-y				+= nspire.o
> 
> The first line is not actually needed.

Done.

> 
>> +
>> +#include "../../mmio.h"
>> +
>> +.macro	addruart, rp, rv, tmp
>> +	ldr \rp, =(NSPIRE_EARLY_UART_PHYS_BASE)		@ physical base address
>> +	ldr \rv, =(NSPIRE_EARLY_UART_VIRT_BASE)		@ virtual base address
>> +.endm
>> +
>> +#include <asm/hardware/debug-pl01x.S>
>> +
> 
> There is no nice solution for getting the addresses here, but the consensus
> was to just define the macros in this file rather than try to include a
> header from elsewhere.
> 

Fair enough, I've added the macros in.

> 
>> +	err = of_property_read_string(of_aliases, "timer0", &path);
>> +	if (WARN_ON(err))
>> +		return;
>> +
>> +	timer = of_find_node_by_path(path);
>> +	base = of_iomap(timer, 0);
>> +	if (WARN_ON(!base))
>> +		return;
>> +
>> +	clk = of_clk_get_by_name(timer, NULL);
>> +	clk_register_clkdev(clk, timer->name, "sp804");
>> +
>> +	sp804_clocksource_init(base, timer->name);
>> +
>> +	err = of_property_read_string(of_aliases, "timer1", &path);
>> +	if (WARN_ON(err))
>> +		return;
> 
> In particular, I think the method of using aliases to pick the right sp804
> instance is being deprecated now. If both timers are identical, the kernel
> will now just pick one of them.

Sorry, I don't quite understand. 

Out of the timers, I want to add one as a clocksource and one as a clockevent. If they're identical (i.e. without using aliases), how should I tell the kernel, "Take the first timer you see and make it a clocksource, take the next one you see and make it a clockevent"?

> 
> 	Arnd

Here's an updated patch:

Signed-off-by: Daniel Tang <dt.tangr at gmail.com>
---
 arch/arm/Kconfig                   |   2 +
 arch/arm/Kconfig.debug             |  16 ++++
 arch/arm/Makefile                  |   3 +-
 arch/arm/boot/dts/nspire-cx.dts    |  85 ++++++++++++++++++++
 arch/arm/boot/dts/nspire.dtsi      | 154 +++++++++++++++++++++++++++++++++++++
 arch/arm/include/debug/nspire.S    |  28 +++++++
 arch/arm/mach-nspire/Kconfig       |  12 +++
 arch/arm/mach-nspire/Makefile      |   1 +
 arch/arm/mach-nspire/Makefile.boot |   0
 arch/arm/mach-nspire/mmio.h        |  13 ++++
 arch/arm/mach-nspire/nspire.c      | 107 ++++++++++++++++++++++++++
 11 files changed, 420 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/nspire-cx.dts
 create mode 100644 arch/arm/boot/dts/nspire.dtsi
 create mode 100644 arch/arm/include/debug/nspire.S
 create mode 100644 arch/arm/mach-nspire/Kconfig
 create mode 100644 arch/arm/mach-nspire/Makefile
 create mode 100644 arch/arm/mach-nspire/Makefile.boot
 create mode 100644 arch/arm/mach-nspire/mmio.h
 create mode 100644 arch/arm/mach-nspire/nspire.c

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 1cacda4..3f0cd8c 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1081,6 +1081,8 @@ source "arch/arm/mach-netx/Kconfig"
 
 source "arch/arm/mach-nomadik/Kconfig"
 
+source "arch/arm/mach-nspire/Kconfig"
+
 source "arch/arm/plat-omap/Kconfig"
 
 source "arch/arm/mach-omap1/Kconfig"
diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 9b31f43..5da3a50 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -298,6 +298,20 @@ choice
 		  Say Y here if you want kernel low-level debugging support
 		  on MVEBU based platforms.
 
+	config DEBUG_NSPIRE_CLASSIC_UART
+		bool "Kernel low-level debugging via TI-NSPIRE 8250 UART"
+		depends on ARCH_NSPIRE
+		help
+		  Say Y here if you want kernel low-level debugging support
+		  on TI-NSPIRE classic models.
+
+	config DEBUG_NSPIRE_CX_UART
+		bool "Kernel low-level debugging via TI-NSPIRE PL011 UART"
+		depends on ARCH_NSPIRE
+		help
+		  Say Y here if you want kernel low-level debugging support
+		  on TI-NSPIRE CX models.
+
 	config DEBUG_OMAP2PLUS_UART
 		bool "Kernel low-level debugging messages via OMAP2PLUS UART"
 		depends on ARCH_OMAP2PLUS
@@ -591,6 +605,8 @@ config DEBUG_LL_INCLUDE
 				 DEBUG_IMX6Q_UART
 	default "debug/highbank.S" if DEBUG_HIGHBANK_UART
 	default "debug/mvebu.S" if DEBUG_MVEBU_UART
+	default "debug/nspire.S" if 	DEBUG_NSPIRE_CX_UART || \
+					DEBUG_NSPIRE_CLASSIC_UART
 	default "debug/omap2plus.S" if DEBUG_OMAP2PLUS_UART
 	default "debug/picoxcell.S" if DEBUG_PICOXCELL_UART
 	default "debug/socfpga.S" if DEBUG_SOCFPGA_UART
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index ee4605f..f47a8a7 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -165,6 +165,7 @@ machine-$(CONFIG_ARCH_MXS)		+= mxs
 machine-$(CONFIG_ARCH_MVEBU)		+= mvebu
 machine-$(CONFIG_ARCH_NETX)		+= netx
 machine-$(CONFIG_ARCH_NOMADIK)		+= nomadik
+machine-$(CONFIG_ARCH_NSPIRE)		+= nspire
 machine-$(CONFIG_ARCH_OMAP1)		+= omap1
 machine-$(CONFIG_ARCH_OMAP2PLUS)	+= omap2
 machine-$(CONFIG_ARCH_ORION5X)		+= orion5x
@@ -313,7 +314,7 @@ define archhelp
   echo  '  Image         - Uncompressed kernel image (arch/$(ARCH)/boot/Image)'
   echo  '* xipImage      - XIP kernel image, if configured (arch/$(ARCH)/boot/xipImage)'
   echo  '  uImage        - U-Boot wrapped zImage'
-  echo  '  bootpImage    - Combined zImage and initial RAM disk' 
+  echo  '  bootpImage    - Combined zImage and initial RAM disk'
   echo  '                  (supply initrd image via make variable INITRD=<path>)'
   echo  '* dtbs          - Build device tree blobs for enabled boards'
   echo  '  install       - Install uncompressed kernel'
diff --git a/arch/arm/boot/dts/nspire-cx.dts b/arch/arm/boot/dts/nspire-cx.dts
new file mode 100644
index 0000000..0a80488
--- /dev/null
+++ b/arch/arm/boot/dts/nspire-cx.dts
@@ -0,0 +1,85 @@
+/*
+ *  linux/arch/arm/boot/nspire-cx.dts
+ *
+ *  Copyright (C) 2012 Daniel Tang <tangrs at tangrs.id.au>
+ *
+ * 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.
+ *
+ */
+/dts-v1/;
+
+/include/ "nspire.dtsi"
+
+/ {
+	model = "TI-NSPIRE CX";
+	compatible = "arm,nspire-cx";
+
+	memory {
+		device_type = "memory";
+		reg = <0x10000000 0x4000000>; /* 64 MB */
+	};
+
+	aliases {
+		uart0 = &uart0;
+		timer0 = &timer0;
+		timer1 = &timer1;
+		fast_timer = &fast_timer;
+	};
+
+	uart_clk: uart_clk {
+		#clock-cells = <0>;
+		compatible = "fixed-clock";
+		clock-frequency = <12000000>;
+	};
+
+	/* Not really a fixed clock but we'll fix this later */
+	apb_pclk: apb_pclk {
+		#clock-cells = <0>;
+		compatible = "fixed-clock";
+		clock-frequency = <33000000>;
+	};
+
+	ahb {
+		#address-cells = <1>;
+		#size-cells = <1>;
+
+		intc: interrupt-controller at DC000000 {
+			compatible = "arm,pl190-vic";
+			interrupt-controller;
+			reg = <0xDC000000 0x1000>;
+			#interrupt-cells = <1>;
+		};
+
+		apb at 90000000 {
+			#address-cells = <1>;
+			#size-cells = <1>;
+
+			i2c at 90050000 {
+				compatible = "snps,designware-i2c";
+				reg = <0x90050000 0x1000>;
+				interrupts = <20>;
+			};
+
+			fast_timer: timer at 90010000 {
+				compatible = "arm,sp804", "arm,primecell";
+			};
+
+			uart0: serial at 90020000 {
+				compatible = "arm,pl011", "arm,primecell";
+			};
+
+			timer0: timer at 900C0000 {
+				compatible = "arm,sp804", "arm,primecell";
+			};
+
+			timer1: timer at 900D0000 {
+				compatible = "arm,sp804", "arm,primecell";
+			};
+		};
+	};
+	chosen {
+		bootargs = "debug earlyprintk console=ttyAMA0,115200n8";
+	};
+};
diff --git a/arch/arm/boot/dts/nspire.dtsi b/arch/arm/boot/dts/nspire.dtsi
new file mode 100644
index 0000000..7e9681f
--- /dev/null
+++ b/arch/arm/boot/dts/nspire.dtsi
@@ -0,0 +1,154 @@
+/*
+ *  linux/arch/arm/boot/nspire.dtsi
+ *
+ *  Copyright (C) 2012 Daniel Tang <tangrs at tangrs.id.au>
+ *
+ * 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/ "skeleton.dtsi"
+
+/ {
+	cpus {
+		cpu at 0 {
+			compatible = "arm,arm926";
+		};
+	};
+
+	bootrom: bootrom at 00000000 {
+		reg = <0x00000000 0x80000>;
+	};
+
+	sram: sram at A4000000 {
+		device = "memory";
+		reg = <0xA4000000 0x20000>;
+	};
+
+	timer_clk: timer_clk {
+		#clock-cells = <0>;
+		compatible = "fixed-clock";
+		clock-frequency = <32768>;
+	};
+
+	ahb {
+		compatible = "arm,amba-bus", "simple-bus";
+		interrupt-parent = <&intc>;
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges;
+
+		spi: spi at A9000000 {
+			reg = <0xA9000000 0x1000>;
+		};
+
+		usb0: usb at B0000000 {
+			reg = <0xB0000000 0x1000>;
+			interrupts = <8>;
+		};
+
+		usb1: usb at B4000000 {
+			reg = <0xB4000000 0x1000>;
+			interrupts = <9>;
+			status = "disabled";
+		};
+
+		lcd: lcd at C0000000 {
+			compatible = "arm,amba-primecell";
+			reg = <0xC0000000 0x1000>;
+			interrupts = <21>;
+		};
+
+		adc: adc at C4000000 {
+			reg = <0xC4000000 0x1000>;
+			interrupts = <11>;
+		};
+
+		tdes: crypto at C8010000 {
+			reg = <0xC8010000 0x1000>;
+		};
+
+		sha256: crypto at CC000000 {
+			reg = <0xCC000000 0x1000>;
+		};
+
+		apb at 90000000 {
+			compatible = "arm,amba-bus", "simple-bus";
+			#address-cells = <1>;
+			#size-cells = <1>;
+			clocks = <&apb_pclk>;
+			clock-names = "apb_pclk";
+			clock-ranges;
+			ranges;
+
+			gpio: gpio at 90000000 {
+				reg = <0x90000000 0x1000>;
+				interrupts = <7>;
+			};
+
+			fast_timer: timer at 90010000 {
+				reg = <0x90010000 0x1000>;
+				interrupts = <17>;
+			};
+
+			uart: serial at 90020000 {
+				reg = <0x90020000 0x1000>;
+				interrupts = <1>;
+
+				clocks = <&uart_clk>;
+				clock-names = "uart_clk";
+			};
+
+			timer0: timer at 900C0000 {
+				reg = <0x900C0000 0x1000>;
+				interrupts = <18>;
+
+				clocks = <&timer_clk>;
+				clock-names = "timer_clk";
+			};
+
+			timer1: timer at 900D0000 {
+				reg = <0x900D0000 0x1000>;
+				interrupts = <19>;
+
+				clocks = <&timer_clk>;
+				clock-names = "timer_clk";
+			};
+
+			watchdog: watchdog at 90060000 {
+				compatible = "arm,amba-primecell";
+				reg = <0x90060000 0x1000>;
+				interrupts = <3>;
+			};
+
+			rtc: rtc at 90090000 {
+				reg = <0x90090000 0x1000>;
+				interrupts = <4>;
+			};
+
+			misc: misc at 900A0000 {
+				reg = <0x900A0000 0x1000>;
+			};
+
+			pwr: pwr at 900B0000 {
+				reg = <0x900B0000 0x1000>;
+				interrupts = <15>;
+			};
+
+			keypad: input at 900E0000 {
+				reg = <0x900E0000 0x1000>;
+				interrupts = <16>;
+			};
+
+			contrast: contrast at 900F0000 {
+				reg = <0x900F0000 0x1000>;
+			};
+
+			led: led at 90110000 {
+				reg = <0x90110000 0x1000>;
+			};
+		};
+	};
+};
diff --git a/arch/arm/include/debug/nspire.S b/arch/arm/include/debug/nspire.S
new file mode 100644
index 0000000..3a9729c
--- /dev/null
+++ b/arch/arm/include/debug/nspire.S
@@ -0,0 +1,28 @@
+/*
+ *	linux/arch/arm/include/debug/nspire.S
+ *
+ *	Copyright (C) 2012 Daniel Tang <tangrs at tangrs.id.au>
+ *
+ * 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.
+ *
+ */
+
+#define NSPIRE_EARLY_UART_PHYS_BASE	   0x90020000
+#define NSPIRE_EARLY_UART_VIRT_BASE	   0xfee20000
+
+.macro	addruart, rp, rv, tmp
+	ldr \rp, =(NSPIRE_EARLY_UART_PHYS_BASE)		@ physical base address
+	ldr \rv, =(NSPIRE_EARLY_UART_VIRT_BASE)		@ virtual base address
+.endm
+
+
+#ifdef CONFIG_DEBUG_NSPIRE_CX_UART
+#include <asm/hardware/debug-pl01x.S>
+#endif
+
+#ifdef CONFIG_DEBUG_NSPIRE_CLASSIC_UART
+#define UART_SHIFT 2
+#include <asm/hardware/debug-8250.S>
+#endif
diff --git a/arch/arm/mach-nspire/Kconfig b/arch/arm/mach-nspire/Kconfig
new file mode 100644
index 0000000..b6bf06c
--- /dev/null
+++ b/arch/arm/mach-nspire/Kconfig
@@ -0,0 +1,12 @@
+config ARCH_NSPIRE
+	bool "TI-NSPIRE based"
+	depends on MMU
+	select CPU_ARM926T
+	select COMMON_CLK
+	select GENERIC_CLOCKEVENTS
+	select SPARSE_IRQ
+	select ARM_AMBA
+	select ARM_VIC
+	select ARM_TIMER_SP804
+	help
+	  This enables support for systems using the TI-NSPIRE CPU
diff --git a/arch/arm/mach-nspire/Makefile b/arch/arm/mach-nspire/Makefile
new file mode 100644
index 0000000..c96c2c4
--- /dev/null
+++ b/arch/arm/mach-nspire/Makefile
@@ -0,0 +1 @@
+obj-y				+= nspire.o
diff --git a/arch/arm/mach-nspire/Makefile.boot b/arch/arm/mach-nspire/Makefile.boot
new file mode 100644
index 0000000..e69de29
diff --git a/arch/arm/mach-nspire/mmio.h b/arch/arm/mach-nspire/mmio.h
new file mode 100644
index 0000000..6e2fe95
--- /dev/null
+++ b/arch/arm/mach-nspire/mmio.h
@@ -0,0 +1,13 @@
+/*
+ *	linux/arch/arm/mach-nspire/mmio.h
+ *
+ *	Copyright (C) 2012 Daniel Tang <tangrs at tangrs.id.au>
+ *
+ * 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.
+ *
+ */
+
+#define NSPIRE_EARLY_UART_PHYS_BASE	   0x90020000
+#define NSPIRE_EARLY_UART_VIRT_BASE	   0xfee20000
diff --git a/arch/arm/mach-nspire/nspire.c b/arch/arm/mach-nspire/nspire.c
new file mode 100644
index 0000000..ec7734a
--- /dev/null
+++ b/arch/arm/mach-nspire/nspire.c
@@ -0,0 +1,107 @@
+/*
+ *	linux/arch/arm/mach-nspire/nspire.c
+ *
+ *	Copyright (C) 2012 Daniel Tang <tangrs at tangrs.id.au>
+ *
+ * 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/init.h>
+#include <linux/of_irq.h>
+#include <linux/of_address.h>
+#include <linux/of_platform.h>
+#include <linux/irqchip.h>
+#include <linux/irqchip/arm-vic.h>
+#include <linux/clk-provider.h>
+#include <linux/clkdev.h>
+
+#include <asm/mach/arch.h>
+#include <asm/mach-types.h>
+#include <asm/mach/map.h>
+
+#include <asm/hardware/timer-sp.h>
+
+#include "mmio.h"
+
+static const char *nspire_dt_match[] __initconst = {
+	"arm,nspire",
+	"arm,nspire-cx",
+	"arm,nspire-tp",
+	"arm,nspire-clp",
+	NULL,
+};
+
+static struct map_desc nspire_io_desc[] __initdata = {
+	{
+		.virtual	=  NSPIRE_EARLY_UART_VIRT_BASE,
+		.pfn		= __phys_to_pfn(NSPIRE_EARLY_UART_PHYS_BASE),
+		.length		= SZ_4K,
+		.type		= MT_DEVICE
+	}
+};
+
+static void __init nspire_init_timer(void)
+{
+	struct device_node *timer;
+	void __iomem *base;
+	const char *path;
+	struct clk *clk;
+	int irq, err;
+
+	of_clk_init(NULL);
+
+	err = of_property_read_string(of_aliases, "timer0", &path);
+	if (WARN_ON(err))
+		return;
+
+	timer = of_find_node_by_path(path);
+	base = of_iomap(timer, 0);
+	if (WARN_ON(!base))
+		return;
+
+	clk = of_clk_get_by_name(timer, NULL);
+	clk_register_clkdev(clk, timer->name, "sp804");
+
+	sp804_clocksource_init(base, timer->name);
+
+	err = of_property_read_string(of_aliases, "timer1", &path);
+	if (WARN_ON(err))
+		return;
+
+	timer = of_find_node_by_path(path);
+	base = of_iomap(timer, 0);
+	if (WARN_ON(!base))
+		return;
+
+	clk = of_clk_get_by_name(timer, NULL);
+	clk_register_clkdev(clk, timer->name, "sp804");
+
+	irq = irq_of_parse_and_map(timer, 0);
+	sp804_clockevents_init(base, irq, timer->name);
+}
+
+static void __init nspire_map_io(void)
+{
+	iotable_init(nspire_io_desc, ARRAY_SIZE(nspire_io_desc));
+}
+
+static void __init nspire_init(void)
+{
+	of_platform_populate(NULL, of_default_bus_match_table,
+			NULL, NULL);
+}
+
+static void nspire_restart(char mode, const char *cmd)
+{
+}
+
+DT_MACHINE_START(NSPIRE, "TI-NSPIRE")
+	.map_io		= nspire_map_io,
+	.init_irq	= irqchip_init,
+	.init_time	= nspire_init_timer,
+	.init_machine	= nspire_init,
+	.dt_compat	= nspire_dt_match,
+	.restart	= nspire_restart,
+MACHINE_END
-- 
1.8.1.3


From linux at arm.linux.org.uk  Sat Apr  6 20:23:42 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Sun, 7 Apr 2013 01:23:42 +0100
Subject: [GIT PULL] Multi Cluster Power Management infrastructure
In-Reply-To: <alpine.LFD.2.03.1304050854590.1171@syhkavp.arg>
References: <alpine.LFD.2.03.1303251219530.1372@syhkavp.arg>
 <20130328134808.GD16765@e102568-lin.cambridge.arm.com>
 <alpine.LFD.2.03.1304022258430.1171@syhkavp.arg>
 <alpine.LFD.2.03.1304042138160.1171@syhkavp.arg>
 <20130405094159.GH17995@n2100.arm.linux.org.uk>
 <alpine.LFD.2.03.1304050854590.1171@syhkavp.arg>
Message-ID: <20130407002342.GJ17995@n2100.arm.linux.org.uk>

On Fri, Apr 05, 2013 at 09:30:58AM -0400, Nicolas Pitre wrote:
> > Now, I'm currently on holiday.  I'm going to be on holday until after
> > mid-April.  I'm not pulling anything until then.  I'm not applying anything
> > until then.  I'm not even reading this mailbox - and given current mail
> > rates at 300-400 messages per day, I will *not* be reading back over a
> > fortnights worth of email.
> 
> That is also unacceptable.  Again, you are the appointed ARM kernel 
> maintainer.  You have to plan a backup when you are away.  If the load 
> is too much, you have to delegate.

Thank you for showing what a self-centred individual you are.

Tell me, how do I delegate the physical act of scanning through email
to someone else to find out those emails which I may want to reply to?

Now, just take a moment to do the math.  At 400 messages per day, with
an average of one minute a message, that's 6.5 hours.  Four days of that
and you're looking at 20 hours to catch up - realistically two days.
Meanwhile another 13 hours of messages (800) have arrived.  So that's
another day and a bit of nothing but scanning, during which time more
than 6.5 hours of messages have again arrived...

I've said this before, and I've done the above before - over a much
longer period.  Other kernel developers do this too - they will actively
remove their mailboxes after returning from a vacation because its
too painful to catch up by reading mail.  Linus will also do the same -
he will require things to be (re-)sent when he's returned from vacation.

Yet _you_ seem to think that this is not acceptable behaviour?  Sorry,
I disagree - it's the _only_ sensible and sane way.


From linux at arm.linux.org.uk  Sat Apr  6 20:32:39 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Sun, 7 Apr 2013 01:32:39 +0100
Subject: [GIT PULL] Multi Cluster Power Management infrastructure
In-Reply-To: <20130407002342.GJ17995@n2100.arm.linux.org.uk>
References: <alpine.LFD.2.03.1303251219530.1372@syhkavp.arg>
 <20130328134808.GD16765@e102568-lin.cambridge.arm.com>
 <alpine.LFD.2.03.1304022258430.1171@syhkavp.arg>
 <alpine.LFD.2.03.1304042138160.1171@syhkavp.arg>
 <20130405094159.GH17995@n2100.arm.linux.org.uk>
 <alpine.LFD.2.03.1304050854590.1171@syhkavp.arg>
 <20130407002342.GJ17995@n2100.arm.linux.org.uk>
Message-ID: <20130407003239.GA25225@n2100.arm.linux.org.uk>

On Sun, Apr 07, 2013 at 01:23:42AM +0100, Russell King - ARM Linux wrote:
> On Fri, Apr 05, 2013 at 09:30:58AM -0400, Nicolas Pitre wrote:
> > > Now, I'm currently on holiday.  I'm going to be on holday until after
> > > mid-April.  I'm not pulling anything until then.  I'm not applying anything
> > > until then.  I'm not even reading this mailbox - and given current mail
> > > rates at 300-400 messages per day, I will *not* be reading back over a
> > > fortnights worth of email.
> > 
> > That is also unacceptable.  Again, you are the appointed ARM kernel 
> > maintainer.  You have to plan a backup when you are away.  If the load 
> > is too much, you have to delegate.
> 
> Thank you for showing what a self-centred individual you are.
> 
> Tell me, how do I delegate the physical act of scanning through email
> to someone else to find out those emails which I may want to reply to?
> 
> Now, just take a moment to do the math.  At 400 messages per day, with
> an average of one minute a message, that's 6.5 hours.  Four days of that
> and you're looking at 20 hours to catch up - realistically two days.
> Meanwhile another 13 hours of messages (800) have arrived.  So that's
> another day and a bit of nothing but scanning, during which time more
> than 6.5 hours of messages have again arrived...
> 
> I've said this before, and I've done the above before - over a much
> longer period.  Other kernel developers do this too - they will actively
> remove their mailboxes after returning from a vacation because its
> too painful to catch up by reading mail.  Linus will also do the same -
> he will require things to be (re-)sent when he's returned from vacation.
> 
> Yet _you_ seem to think that this is not acceptable behaviour?  Sorry,
> I disagree - it's the _only_ sensible and sane way.

And the last thing to mentoion is that this is the last night before I
drive back home, and I've just spent the last *two* hours dealing with your
crap emails.  It's now 1:30am.  If I have an accident as a result of
this lack of sleep then I hold you responsible for it, because obviously
your patches are far more important than anything else in the whole damned
world.


From 21cnbao at gmail.com  Sat Apr  6 23:03:30 2013
From: 21cnbao at gmail.com (Barry Song)
Date: Sun, 7 Apr 2013 11:03:30 +0800
Subject: [PATCH] pinctrl:sirf:re-arch and add support for new SiRFatlas6
 SoC
In-Reply-To: <CACRpkdaMYTXpnfg8MhRP5Fs_Qn2gwv=Xuk3YSYejxt+vK9D6+w@mail.gmail.com>
References: <1363597988-7409-1-git-send-email-Barry.Song@csr.com>
 <CACRpkdYUTQ_7V1CbKbx05zgBONj6iUi=ekzSwmZz8dqeRx7ZJw@mail.gmail.com>
 <CAGsJ_4wmn-LxxX-JeSJzdkVFSUeJ=vQrKHJr9yUtsoxG2BFHtw@mail.gmail.com>
 <CACRpkdaMYTXpnfg8MhRP5Fs_Qn2gwv=Xuk3YSYejxt+vK9D6+w@mail.gmail.com>
Message-ID: <CAGsJ_4xSk_fXjhM2kxy0Hd36e9BsGshfmM97KgcU3cC5avmxtQ@mail.gmail.com>

2013/4/3 Linus Walleij <linus.walleij at linaro.org>:
> On Thu, Mar 28, 2013 at 7:27 AM, Barry Song <21cnbao at gmail.com> wrote:
>> 2013/3/28, Linus Walleij <linus.walleij at linaro.org>:
>
>>>> Signed-off-by: Barry Song <Baohua.Song at csr.com>
>>>
>>> This is OK but can you please:
>>
>> ok. one issue is recently Arnd has given another changes in
>> pinctrl-sirf in arm-soc multiple platform branch:
>> https://git.kernel.org/cgit/linux/kernel/git/arm/arm-soc.git/commit/?h=prima2/multiplatform&id=67d71344fd09223820eb9de39b597ec29f035e89
>>
>> it makes us easily to get merging conflict. what is your suggestion
>> about taking all these changes in 3.10?
>
> Please send this to where the rest of the patches are with my ACK
> (I guess the ARM SoC tree?)

unfortunately, this is not in arm soc:
Wei Yongjun <yongjun_wei at trendmicro.com.cn>
pinctrl: sirf: using for_each_set_bit to simplify the code

https://git.kernel.org/cgit/linux/kernel/git/linusw/linux-pinctrl.git/commit/?h=for-next&id=3dcbd6f5789839c7fea8841088ed3a28688f81ed

i think there will still be some merge conflict. so to make people
easy, i might wait for 3.11 and resend the patch with your ack, then
you apply it on pinctrl tree.

>
> Acked-by: Linus Walleij <linus.walleij at linaro.org>
>
> Yours,
> Linus Walleij

-barry


From baozich at gmail.com  Sat Apr  6 23:23:04 2013
From: baozich at gmail.com (Chen Baozi)
Date: Sun, 7 Apr 2013 11:23:04 +0800
Subject: [PATCH 0/3] gpio: remove GENERIC_GPIO completely
In-Reply-To: <1364562678-8945-1-git-send-email-acourbot@nvidia.com>
References: <1364562678-8945-1-git-send-email-acourbot@nvidia.com>
Message-ID: <20130407032304.GA11500@cbz-workstation>

On Fri, Mar 29, 2013 at 06:11:15AM -0700, Alexandre Courbot wrote:
> Another issue, I could not update the Chinese documentation in a satisfying
> manner due to my absence of Chinese skills. Hope that will be forgiven.
> 
Hi Alexandre,

I have changed the Chinese documentation according to your update as
follows. Hopefully it would be helpful, :)

---
 Documentation/zh_CN/gpio.txt | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/Documentation/zh_CN/gpio.txt b/Documentation/zh_CN/gpio.txt
index 4fa7b4e..d5b8f01 100644
--- a/Documentation/zh_CN/gpio.txt
+++ b/Documentation/zh_CN/gpio.txt
@@ -84,10 +84,10 @@ GPIO ??
 ?????????????(??????????????????,???
 ????????? GPIO ????????????????????)
 
-????,?????????????????????????????
-??? Kconfig ???? GENERIC_GPIO??? (??? true)????
-?? <asm/gpio.h> ????????? GPIO ???????? Kconfig
-???????GENERIC_GPIO????????:
+????,????????????????????????????????
+??? Kconfig ??? ARCH_REQUIRE_GPIOLIB ?? ARCH_WANT_OPTIONAL_GPIOLIB
+????????? GPIO ???????? Kconfig
???????GENERIC_GPIO?
+???????:
 
        #include <linux/gpio.h>
  


From dt.tangr at gmail.com  Sat Apr  6 23:56:12 2013
From: dt.tangr at gmail.com (Daniel Tang)
Date: Sun, 7 Apr 2013 13:56:12 +1000
Subject: [RFC PATCH arm: initial TI-Nspire support]
In-Reply-To: <4B3FD561-84FC-40CD-B747-13851692D673@gmail.com>
References: <6FE4B33E-A503-4A75-AEED-831CB2C06D83@gmail.com>
 <201304061351.00889.arnd@arndb.de>
 <F832F4F9-8162-43B8-B9E0-D5D8C8B8C77A@gmail.com>
 <201304061524.56502.arnd@arndb.de>
 <4B3FD561-84FC-40CD-B747-13851692D673@gmail.com>
Message-ID: <521DFDFC-7E9E-47EA-ACDA-C91BBDC8454E@gmail.com>

Here's an updated patch that enables support for the LCD.

I looked into drivers/video/of_display_timing.c but it doesn't have the fields to describe the PL11x specific options needed in struct clcd_panel. At the moment, it is implemented by hardcoding the values in the kernel and using the device tree to select the correct configuration.

Signed-off-by: Daniel Tang <dt.tangr at gmail.com>
---
 arch/arm/Kconfig                   |   2 +
 arch/arm/Kconfig.debug             |  16 +++
 arch/arm/Makefile                  |   3 +-
 arch/arm/boot/dts/nspire-cx.dts    |  89 ++++++++++++++
 arch/arm/boot/dts/nspire.dtsi      | 157 +++++++++++++++++++++++++
 arch/arm/include/debug/nspire.S    |  28 +++++
 arch/arm/mach-nspire/Kconfig       |  12 ++
 arch/arm/mach-nspire/Makefile      |   1 +
 arch/arm/mach-nspire/Makefile.boot |   0
 arch/arm/mach-nspire/mmio.h        |  15 +++
 arch/arm/mach-nspire/nspire.c      | 233 +++++++++++++++++++++++++++++++++++++
 11 files changed, 555 insertions(+), 1 deletion(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 1cacda4..3f0cd8c 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1081,6 +1081,8 @@ source "arch/arm/mach-netx/Kconfig"
 
 source "arch/arm/mach-nomadik/Kconfig"
 
+source "arch/arm/mach-nspire/Kconfig"
+
 source "arch/arm/plat-omap/Kconfig"
 
 source "arch/arm/mach-omap1/Kconfig"
diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 9b31f43..5da3a50 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -298,6 +298,20 @@ choice
 		  Say Y here if you want kernel low-level debugging support
 		  on MVEBU based platforms.
 
+	config DEBUG_NSPIRE_CLASSIC_UART
+		bool "Kernel low-level debugging via TI-NSPIRE 8250 UART"
+		depends on ARCH_NSPIRE
+		help
+		  Say Y here if you want kernel low-level debugging support
+		  on TI-NSPIRE classic models.
+
+	config DEBUG_NSPIRE_CX_UART
+		bool "Kernel low-level debugging via TI-NSPIRE PL011 UART"
+		depends on ARCH_NSPIRE
+		help
+		  Say Y here if you want kernel low-level debugging support
+		  on TI-NSPIRE CX models.
+
 	config DEBUG_OMAP2PLUS_UART
 		bool "Kernel low-level debugging messages via OMAP2PLUS UART"
 		depends on ARCH_OMAP2PLUS
@@ -591,6 +605,8 @@ config DEBUG_LL_INCLUDE
 				 DEBUG_IMX6Q_UART
 	default "debug/highbank.S" if DEBUG_HIGHBANK_UART
 	default "debug/mvebu.S" if DEBUG_MVEBU_UART
+	default "debug/nspire.S" if 	DEBUG_NSPIRE_CX_UART || \
+					DEBUG_NSPIRE_CLASSIC_UART
 	default "debug/omap2plus.S" if DEBUG_OMAP2PLUS_UART
 	default "debug/picoxcell.S" if DEBUG_PICOXCELL_UART
 	default "debug/socfpga.S" if DEBUG_SOCFPGA_UART
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index ee4605f..f47a8a7 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -165,6 +165,7 @@ machine-$(CONFIG_ARCH_MXS)		+= mxs
 machine-$(CONFIG_ARCH_MVEBU)		+= mvebu
 machine-$(CONFIG_ARCH_NETX)		+= netx
 machine-$(CONFIG_ARCH_NOMADIK)		+= nomadik
+machine-$(CONFIG_ARCH_NSPIRE)		+= nspire
 machine-$(CONFIG_ARCH_OMAP1)		+= omap1
 machine-$(CONFIG_ARCH_OMAP2PLUS)	+= omap2
 machine-$(CONFIG_ARCH_ORION5X)		+= orion5x
@@ -313,7 +314,7 @@ define archhelp
   echo  '  Image         - Uncompressed kernel image (arch/$(ARCH)/boot/Image)'
   echo  '* xipImage      - XIP kernel image, if configured (arch/$(ARCH)/boot/xipImage)'
   echo  '  uImage        - U-Boot wrapped zImage'
-  echo  '  bootpImage    - Combined zImage and initial RAM disk' 
+  echo  '  bootpImage    - Combined zImage and initial RAM disk'
   echo  '                  (supply initrd image via make variable INITRD=<path>)'
   echo  '* dtbs          - Build device tree blobs for enabled boards'
   echo  '  install       - Install uncompressed kernel'
diff --git a/arch/arm/boot/dts/nspire-cx.dts b/arch/arm/boot/dts/nspire-cx.dts
new file mode 100644
index 0000000..d843e60
--- /dev/null
+++ b/arch/arm/boot/dts/nspire-cx.dts
@@ -0,0 +1,89 @@
+/*
+ *  linux/arch/arm/boot/nspire-cx.dts
+ *
+ *  Copyright (C) 2012 Daniel Tang <tangrs at tangrs.id.au>
+ *
+ * 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.
+ *
+ */
+/dts-v1/;
+
+/include/ "nspire.dtsi"
+
+/ {
+	model = "TI-NSPIRE CX";
+	compatible = "arm,nspire-cx";
+
+	memory {
+		device_type = "memory";
+		reg = <0x10000000 0x4000000>; /* 64 MB */
+	};
+
+	aliases {
+		uart0 = &uart0;
+		timer0 = &timer0;
+		timer1 = &timer1;
+		fast_timer = &fast_timer;
+	};
+
+	uart_clk: uart_clk {
+		#clock-cells = <0>;
+		compatible = "fixed-clock";
+		clock-frequency = <12000000>;
+	};
+
+	/* Not really a fixed clock but we'll fix this later */
+	apb_pclk: apb_pclk {
+		#clock-cells = <0>;
+		compatible = "fixed-clock";
+		clock-frequency = <33000000>;
+	};
+
+	ahb {
+		#address-cells = <1>;
+		#size-cells = <1>;
+
+		intc: interrupt-controller at DC000000 {
+			compatible = "arm,pl190-vic";
+			interrupt-controller;
+			reg = <0xDC000000 0x1000>;
+			#interrupt-cells = <1>;
+		};
+
+		lcd: lcd at C0000000 {
+			lcd-type = "cx";
+		};
+
+		apb at 90000000 {
+			#address-cells = <1>;
+			#size-cells = <1>;
+
+			i2c at 90050000 {
+				compatible = "snps,designware-i2c";
+				reg = <0x90050000 0x1000>;
+				interrupts = <20>;
+			};
+
+			fast_timer: timer at 90010000 {
+				compatible = "arm,sp804", "arm,primecell";
+			};
+
+			uart0: serial at 90020000 {
+				compatible = "arm,pl011", "arm,primecell";
+			};
+
+			timer0: timer at 900C0000 {
+				compatible = "arm,sp804", "arm,primecell";
+			};
+
+			timer1: timer at 900D0000 {
+				compatible = "arm,sp804", "arm,primecell";
+			};
+		};
+	};
+	chosen {
+		bootargs = "debug earlyprintk console=ttyAMA0,115200n8 console=tty0";
+	};
+};
diff --git a/arch/arm/boot/dts/nspire.dtsi b/arch/arm/boot/dts/nspire.dtsi
new file mode 100644
index 0000000..5b6fad7
--- /dev/null
+++ b/arch/arm/boot/dts/nspire.dtsi
@@ -0,0 +1,157 @@
+/*
+ *  linux/arch/arm/boot/nspire.dtsi
+ *
+ *  Copyright (C) 2012 Daniel Tang <tangrs at tangrs.id.au>
+ *
+ * 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/ "skeleton.dtsi"
+
+/ {
+	cpus {
+		cpu at 0 {
+			compatible = "arm,arm926";
+		};
+	};
+
+	bootrom: bootrom at 00000000 {
+		reg = <0x00000000 0x80000>;
+	};
+
+	sram: sram at A4000000 {
+		device = "memory";
+		reg = <0xA4000000 0x20000>;
+	};
+
+	timer_clk: timer_clk {
+		#clock-cells = <0>;
+		compatible = "fixed-clock";
+		clock-frequency = <32768>;
+	};
+
+	ahb {
+		compatible = "arm,amba-bus", "simple-bus";
+		interrupt-parent = <&intc>;
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges;
+
+		spi: spi at A9000000 {
+			reg = <0xA9000000 0x1000>;
+		};
+
+		usb0: usb at B0000000 {
+			reg = <0xB0000000 0x1000>;
+			interrupts = <8>;
+		};
+
+		usb1: usb at B4000000 {
+			reg = <0xB4000000 0x1000>;
+			interrupts = <9>;
+			status = "disabled";
+		};
+
+		lcd: lcd at C0000000 {
+			compatible = "arm,pl111", "arm,primecell";
+			reg = <0xC0000000 0x1000>;
+			interrupts = <21>;
+
+			clocks = <&apb_pclk>;
+			clock-names = "apb_pclk";
+		};
+
+		adc: adc at C4000000 {
+			reg = <0xC4000000 0x1000>;
+			interrupts = <11>;
+		};
+
+		tdes: crypto at C8010000 {
+			reg = <0xC8010000 0x1000>;
+		};
+
+		sha256: crypto at CC000000 {
+			reg = <0xCC000000 0x1000>;
+		};
+
+		apb at 90000000 {
+			compatible = "arm,amba-bus", "simple-bus";
+			#address-cells = <1>;
+			#size-cells = <1>;
+			clocks = <&apb_pclk>;
+			clock-names = "apb_pclk";
+			clock-ranges;
+			ranges;
+
+			gpio: gpio at 90000000 {
+				reg = <0x90000000 0x1000>;
+				interrupts = <7>;
+			};
+
+			fast_timer: timer at 90010000 {
+				reg = <0x90010000 0x1000>;
+				interrupts = <17>;
+			};
+
+			uart: serial at 90020000 {
+				reg = <0x90020000 0x1000>;
+				interrupts = <1>;
+
+				clocks = <&uart_clk>;
+				clock-names = "uart_clk";
+			};
+
+			timer0: timer at 900C0000 {
+				reg = <0x900C0000 0x1000>;
+				interrupts = <18>;
+
+				clocks = <&timer_clk>;
+				clock-names = "timer_clk";
+			};
+
+			timer1: timer at 900D0000 {
+				reg = <0x900D0000 0x1000>;
+				interrupts = <19>;
+
+				clocks = <&timer_clk>;
+				clock-names = "timer_clk";
+			};
+
+			watchdog: watchdog at 90060000 {
+				compatible = "arm,amba-primecell";
+				reg = <0x90060000 0x1000>;
+				interrupts = <3>;
+			};
+
+			rtc: rtc at 90090000 {
+				reg = <0x90090000 0x1000>;
+				interrupts = <4>;
+			};
+
+			misc: misc at 900A0000 {
+				reg = <0x900A0000 0x1000>;
+			};
+
+			pwr: pwr at 900B0000 {
+				reg = <0x900B0000 0x1000>;
+				interrupts = <15>;
+			};
+
+			keypad: input at 900E0000 {
+				reg = <0x900E0000 0x1000>;
+				interrupts = <16>;
+			};
+
+			contrast: contrast at 900F0000 {
+				reg = <0x900F0000 0x1000>;
+			};
+
+			led: led at 90110000 {
+				reg = <0x90110000 0x1000>;
+			};
+		};
+	};
+};
diff --git a/arch/arm/include/debug/nspire.S b/arch/arm/include/debug/nspire.S
new file mode 100644
index 0000000..3a9729c
--- /dev/null
+++ b/arch/arm/include/debug/nspire.S
@@ -0,0 +1,28 @@
+/*
+ *	linux/arch/arm/include/debug/nspire.S
+ *
+ *	Copyright (C) 2012 Daniel Tang <tangrs at tangrs.id.au>
+ *
+ * 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.
+ *
+ */
+
+#define NSPIRE_EARLY_UART_PHYS_BASE	   0x90020000
+#define NSPIRE_EARLY_UART_VIRT_BASE	   0xfee20000
+
+.macro	addruart, rp, rv, tmp
+	ldr \rp, =(NSPIRE_EARLY_UART_PHYS_BASE)		@ physical base address
+	ldr \rv, =(NSPIRE_EARLY_UART_VIRT_BASE)		@ virtual base address
+.endm
+
+
+#ifdef CONFIG_DEBUG_NSPIRE_CX_UART
+#include <asm/hardware/debug-pl01x.S>
+#endif
+
+#ifdef CONFIG_DEBUG_NSPIRE_CLASSIC_UART
+#define UART_SHIFT 2
+#include <asm/hardware/debug-8250.S>
+#endif
diff --git a/arch/arm/mach-nspire/Kconfig b/arch/arm/mach-nspire/Kconfig
new file mode 100644
index 0000000..b6bf06c
--- /dev/null
+++ b/arch/arm/mach-nspire/Kconfig
@@ -0,0 +1,12 @@
+config ARCH_NSPIRE
+	bool "TI-NSPIRE based"
+	depends on MMU
+	select CPU_ARM926T
+	select COMMON_CLK
+	select GENERIC_CLOCKEVENTS
+	select SPARSE_IRQ
+	select ARM_AMBA
+	select ARM_VIC
+	select ARM_TIMER_SP804
+	help
+	  This enables support for systems using the TI-NSPIRE CPU
diff --git a/arch/arm/mach-nspire/Makefile b/arch/arm/mach-nspire/Makefile
new file mode 100644
index 0000000..c96c2c4
--- /dev/null
+++ b/arch/arm/mach-nspire/Makefile
@@ -0,0 +1 @@
+obj-y				+= nspire.o
diff --git a/arch/arm/mach-nspire/Makefile.boot b/arch/arm/mach-nspire/Makefile.boot
new file mode 100644
index 0000000..e69de29
diff --git a/arch/arm/mach-nspire/mmio.h b/arch/arm/mach-nspire/mmio.h
new file mode 100644
index 0000000..f0a1fa5
--- /dev/null
+++ b/arch/arm/mach-nspire/mmio.h
@@ -0,0 +1,15 @@
+/*
+ *	linux/arch/arm/mach-nspire/mmio.h
+ *
+ *	Copyright (C) 2012 Daniel Tang <tangrs at tangrs.id.au>
+ *
+ * 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.
+ *
+ */
+
+#define NSPIRE_EARLY_UART_PHYS_BASE	0x90020000
+#define NSPIRE_EARLY_UART_VIRT_BASE	0xfee20000
+
+#define NSPIRE_LCD_PHYS_BASE		0xC0000000
diff --git a/arch/arm/mach-nspire/nspire.c b/arch/arm/mach-nspire/nspire.c
new file mode 100644
index 0000000..e349c80
--- /dev/null
+++ b/arch/arm/mach-nspire/nspire.c
@@ -0,0 +1,233 @@
+/*
+ *	linux/arch/arm/mach-nspire/nspire.c
+ *
+ *	Copyright (C) 2012 Daniel Tang <tangrs at tangrs.id.au>
+ *
+ * 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/init.h>
+#include <linux/of_irq.h>
+#include <linux/of_address.h>
+#include <linux/of_platform.h>
+#include <linux/irqchip.h>
+#include <linux/irqchip/arm-vic.h>
+#include <linux/clk-provider.h>
+#include <linux/clkdev.h>
+#include <linux/amba/bus.h>
+#include <linux/amba/clcd.h>
+#include <linux/dma-mapping.h>
+
+#include <asm/mach/arch.h>
+#include <asm/mach-types.h>
+#include <asm/mach/map.h>
+
+#include <asm/hardware/timer-sp.h>
+
+#include "mmio.h"
+
+static const char *nspire_dt_match[] __initconst = {
+	"arm,nspire",
+	"arm,nspire-cx",
+	"arm,nspire-tp",
+	"arm,nspire-clp",
+	NULL,
+};
+
+static struct map_desc nspire_io_desc[] __initdata = {
+	{
+		.virtual	=  NSPIRE_EARLY_UART_VIRT_BASE,
+		.pfn		= __phys_to_pfn(NSPIRE_EARLY_UART_PHYS_BASE),
+		.length		= SZ_4K,
+		.type		= MT_DEVICE
+	}
+};
+
+static void __init nspire_init_timer(void)
+{
+	struct device_node *timer;
+	void __iomem *base;
+	const char *path;
+	struct clk *clk;
+	int irq, err;
+
+	of_clk_init(NULL);
+
+	err = of_property_read_string(of_aliases, "timer0", &path);
+	if (WARN_ON(err))
+		return;
+
+	timer = of_find_node_by_path(path);
+	base = of_iomap(timer, 0);
+	if (WARN_ON(!base))
+		return;
+
+	clk = of_clk_get_by_name(timer, NULL);
+	clk_register_clkdev(clk, timer->name, "sp804");
+
+	sp804_clocksource_init(base, timer->name);
+
+	err = of_property_read_string(of_aliases, "timer1", &path);
+	if (WARN_ON(err))
+		return;
+
+	timer = of_find_node_by_path(path);
+	base = of_iomap(timer, 0);
+	if (WARN_ON(!base))
+		return;
+
+	clk = of_clk_get_by_name(timer, NULL);
+	clk_register_clkdev(clk, timer->name, "sp804");
+
+	irq = irq_of_parse_and_map(timer, 0);
+	sp804_clockevents_init(base, irq, timer->name);
+}
+
+static void __init nspire_map_io(void)
+{
+	iotable_init(nspire_io_desc, ARRAY_SIZE(nspire_io_desc));
+}
+
+static struct clcd_panel nspire_cx_lcd_panel = {
+	.mode		= {
+		.name		= "Color LCD",
+		.refresh	= 60,
+		.xres		= 320,
+		.yres		= 240,
+		.sync		= 0,
+		.vmode		= FB_VMODE_NONINTERLACED,
+		.pixclock	= 1,
+		.hsync_len	= 6,
+		.vsync_len	= 1,
+		.right_margin	= 50,
+		.left_margin	= 38,
+		.lower_margin	= 3,
+		.upper_margin	= 17,
+	},
+	.width		= 65, /* ~6.50 cm */
+	.height		= 49, /* ~4.87 cm */
+	.tim2		= TIM2_IPC,
+	.cntl		= (CNTL_BGR | CNTL_LCDTFT | CNTL_LCDVCOMP(1) |
+				CNTL_LCDBPP16_565),
+	.bpp		= 16,
+};
+
+static struct clcd_panel nspire_classic_lcd_panel = {
+	.mode		= {
+		.name		= "Grayscale LCD",
+		.refresh	= 60,
+		.xres		= 320,
+		.yres		= 240,
+		.sync		= FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,
+		.vmode		= FB_VMODE_NONINTERLACED,
+		.pixclock	= 1,
+		.hsync_len	= 6,
+		.vsync_len	= 1,
+		.right_margin	= 6,
+		.left_margin	= 6,
+	},
+	.width		= 71, /* 7.11cm */
+	.height		= 53, /* 5.33cm */
+	.tim2		= 0x80007d0,
+	.cntl		= CNTL_LCDBPP8 | CNTL_LCDMONO8,
+	.bpp		= 8,
+	.grayscale	= 1
+};
+
+static int nspire_clcd_setup(struct clcd_fb *fb)
+{
+	struct clcd_panel *panel;
+	size_t panel_size;
+	const char *type;
+	dma_addr_t dma;
+	int err;
+
+	BUG_ON(!fb->dev->dev.of_node);
+
+	err = of_property_read_string(fb->dev->dev.of_node, "lcd-type", &type);
+	if (err) {
+		pr_err("CLCD: Could not find lcd-type property\n");
+		return err;
+	}
+
+	if (!strcmp(type, "cx"))
+	{
+		panel = &nspire_cx_lcd_panel;
+	}
+	else if (!strcmp(type, "classic"))
+	{
+		panel = &nspire_classic_lcd_panel;
+	}
+	else
+	{
+		pr_err("CLCD: Unknown lcd-type %s\n", type);
+		return -EINVAL;
+	}
+
+	panel_size = ((panel->mode.xres * panel->mode.yres) * panel->bpp) / 8;
+	panel_size = ALIGN(panel_size, PAGE_SIZE);
+
+	fb->fb.screen_base = dma_alloc_writecombine(&fb->dev->dev,
+		panel_size, &dma, GFP_KERNEL);
+
+	if (!fb->fb.screen_base) {
+		pr_err("CLCD: unable to map framebuffer\n");
+		return -ENOMEM;
+	}
+
+	fb->fb.fix.smem_start = dma;
+	fb->fb.fix.smem_len = panel_size;
+	fb->panel = panel;
+
+	return 0;
+}
+
+int nspire_clcd_mmap(struct clcd_fb *fb, struct vm_area_struct *vma)
+{
+	return dma_mmap_writecombine(&fb->dev->dev, vma,
+		fb->fb.screen_base, fb->fb.fix.smem_start,
+		fb->fb.fix.smem_len);
+}
+
+void nspire_clcd_remove(struct clcd_fb *fb)
+{
+	dma_free_writecombine(&fb->dev->dev, fb->fb.fix.smem_len,
+		fb->fb.screen_base, fb->fb.fix.smem_start);
+}
+
+static struct clcd_board nspire_clcd_data = {
+	.name		= "LCD",
+	.check		= clcdfb_check,
+	.decode		= clcdfb_decode,
+	.setup		= nspire_clcd_setup,
+	.mmap		= nspire_clcd_mmap,
+	.remove		= nspire_clcd_remove,
+};
+
+
+static struct of_dev_auxdata nspire_auxdata[] __initdata = {
+	OF_DEV_AUXDATA("arm,pl111", NSPIRE_LCD_PHYS_BASE,
+			NULL, &nspire_clcd_data),
+	{ }
+};
+
+static void __init nspire_init(void)
+{
+	of_platform_populate(NULL, of_default_bus_match_table,
+			nspire_auxdata, NULL);
+}
+
+static void nspire_restart(char mode, const char *cmd)
+{
+}
+
+DT_MACHINE_START(NSPIRE, "TI-NSPIRE")
+	.map_io		= nspire_map_io,
+	.init_irq	= irqchip_init,
+	.init_time	= nspire_init_timer,
+	.init_machine	= nspire_init,
+	.dt_compat	= nspire_dt_match,
+	.restart	= nspire_restart,
+MACHINE_END



From shawn.guo at linaro.org  Sun Apr  7 02:16:27 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Sun, 7 Apr 2013 14:16:27 +0800
Subject: [PATCH] ARM: dts: imx23-olinuxino: mark sdcard cd as broken
In-Reply-To: <1365255730-6299-1-git-send-email-aletes.xgr@gmail.com>
References: <1365255730-6299-1-git-send-email-aletes.xgr@gmail.com>
Message-ID: <20130407061625.GA11898@S2101-09.ap.freescale.net>

On Sat, Apr 06, 2013 at 10:42:10AM -0300, Alexandre Pereira da Silva wrote:
> The imx23-olinuxino sdcard doesn't have card detect.
> 
> Signed-off-by: Alexandre Pereira da Silva <aletes.xgr at gmail.com>

Applied, thanks.

> ---
>  arch/arm/boot/dts/imx23-olinuxino.dts |    1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/boot/dts/imx23-olinuxino.dts b/arch/arm/boot/dts/imx23-olinuxino.dts
> index a43141a..d4cc9f8 100644
> --- a/arch/arm/boot/dts/imx23-olinuxino.dts
> +++ b/arch/arm/boot/dts/imx23-olinuxino.dts
> @@ -29,6 +29,7 @@
>  				pinctrl-names = "default";
>  				pinctrl-0 = <&mmc0_4bit_pins_a &mmc0_pins_fixup>;
>  				bus-width = <4>;
> +				broken-cd;
>  				status = "okay";
>  			};
>  
> -- 
> 1.7.10
> 



From shawn.guo at linaro.org  Sun Apr  7 02:19:13 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Sun, 7 Apr 2013 14:19:13 +0800
Subject: [PATCH] ARM: dts: cfa10036: Add touchscreen support to the
 CFA-10049
In-Reply-To: <1365165182-29502-1-git-send-email-alexandre.belloni@free-electrons.com>
References: <1365165182-29502-1-git-send-email-alexandre.belloni@free-electrons.com>
Message-ID: <20130407061911.GB11898@S2101-09.ap.freescale.net>

On Fri, Apr 05, 2013 at 02:33:02PM +0200, Alexandre Belloni wrote:
> Signed-off-by: Alexandre Belloni <alexandre.belloni at free-electrons.com>

Applied, thanks.

> ---
>  arch/arm/boot/dts/imx28-cfa10049.dts |    5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/imx28-cfa10049.dts b/arch/arm/boot/dts/imx28-cfa10049.dts
> index b9dad4e..f16c1e2 100644
> --- a/arch/arm/boot/dts/imx28-cfa10049.dts
> +++ b/arch/arm/boot/dts/imx28-cfa10049.dts
> @@ -192,6 +192,11 @@
>  			usbphy1: usbphy at 8007e000 {
>  				status = "okay";
>  			};
> +
> +			lradc at 80050000 {
> +				status = "okay";
> +				fsl,lradc-touchscreen-wires = <4>;
> +			};
>  		};
>  	};
>  
> -- 
> 1.7.10.4
> 



From shawn.guo at linaro.org  Sun Apr  7 02:33:44 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Sun, 7 Apr 2013 14:33:44 +0800
Subject: [PATCH v5] video: mxsfb: Introduce regulator support
In-Reply-To: <1365171587-31833-1-git-send-email-fabio.estevam@freescale.com>
References: <1365171587-31833-1-git-send-email-fabio.estevam@freescale.com>
Message-ID: <20130407063342.GC11898@S2101-09.ap.freescale.net>

On Fri, Apr 05, 2013 at 11:19:47AM -0300, Fabio Estevam wrote:
> Instead of using a custom binding for retrieving the GPIO that activates the 
> LCD from devicetree, use a standard regulator.
> 
> This approach has the advantage to be more generic. 
> 
> For example: in the case of a board that has a PMIC supplying the LCD voltage, 
> the current approach would not work, as it only searches for a GPIO pin.
> 
> Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
> ---
> Chages since v4:
> - Merged the 2 previous patches into one in order not to break keep mxsfb functionality
> - Remove unneeded change in mxsfb.txt
> - Use regulator_disable to pair with regulator_enable
> Changes since v3:
> - None
> Changes since v2:
> - Use devm_regulator_get()
> Changes since v1:
> - No changes
>  Documentation/devicetree/bindings/fb/mxsfb.txt |    2 --
>  arch/arm/boot/dts/imx23-evk.dts                |   11 ++++++-
>  arch/arm/boot/dts/imx28-evk.dts                |   11 ++++++-
>  drivers/video/mxsfb.c                          |   41 +++++++++++++-----------
>  4 files changed, 43 insertions(+), 22 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/fb/mxsfb.txt b/Documentation/devicetree/bindings/fb/mxsfb.txt
> index 7ba3b76..5d810eb 100644
> --- a/Documentation/devicetree/bindings/fb/mxsfb.txt
> +++ b/Documentation/devicetree/bindings/fb/mxsfb.txt
> @@ -8,7 +8,6 @@ Required properties:
>  - display : phandle to display node (see below for details)
>  
>  Optional properties:

So this line should be removed together?

> -- panel-enable-gpios : Should specify the gpio for panel enable
>  
>  * display node
>  
> @@ -25,7 +24,6 @@ lcdif at 80030000 {
>  	compatible = "fsl,imx28-lcdif";
>  	reg = <0x80030000 2000>;
>  	interrupts = <38 86>;
> -	panel-enable-gpios = <&gpio3 30 0>;
>  
>  	display: display {
>  		bits-per-pixel = <32>;
> diff --git a/arch/arm/boot/dts/imx23-evk.dts b/arch/arm/boot/dts/imx23-evk.dts
> index 7880e17..da0588a 100644
> --- a/arch/arm/boot/dts/imx23-evk.dts
> +++ b/arch/arm/boot/dts/imx23-evk.dts
> @@ -59,7 +59,7 @@
>  			lcdif at 80030000 {
>  				pinctrl-names = "default";
>  				pinctrl-0 = <&lcdif_24bit_pins_a>;
> -				panel-enable-gpios = <&gpio1 18 0>;
> +				lcd-supply = <&reg_lcd_3v3>;
>  				display = <&display>;
>  				status = "okay";
>  
> @@ -120,6 +120,15 @@
>  			regulator-max-microvolt = <3300000>;
>  			gpio = <&gpio1 29 0>;
>  		};
> +
> +		reg_lcd_3v3: lcd-3v3 {
> +			compatible = "regulator-fixed";
> +			regulator-name = "lcd-3v3";
> +			regulator-min-microvolt = <3300000>;
> +			regulator-max-microvolt = <3300000>;
> +			gpio = <&gpio1 18 0>;
> +			enable-active-high;
> +		};
>  	};
>  
>  	backlight {
> diff --git a/arch/arm/boot/dts/imx28-evk.dts b/arch/arm/boot/dts/imx28-evk.dts
> index 2d4ea3b..3637bf3 100644
> --- a/arch/arm/boot/dts/imx28-evk.dts
> +++ b/arch/arm/boot/dts/imx28-evk.dts
> @@ -123,7 +123,7 @@
>  				pinctrl-names = "default";
>  				pinctrl-0 = <&lcdif_24bit_pins_a
>  					     &lcdif_pins_evk>;
> -				panel-enable-gpios = <&gpio3 30 0>;
> +				lcd-supply = <&reg_lcd_3v3>;
>  				display = <&display>;
>  				status = "okay";
>  
> @@ -310,6 +310,15 @@
>  			gpio = <&gpio3 8 0>;
>  			enable-active-high;
>  		};
> +
> +		reg_lcd_3v3: lcd-3v3 {
> +			compatible = "regulator-fixed";
> +			regulator-name = "lcd-3v3";
> +			regulator-min-microvolt = <3300000>;
> +			regulator-max-microvolt = <3300000>;
> +			gpio = <&gpio3 30 0>;
> +			enable-active-high;
> +		};
>  	};
>  
>  	sound {
> diff --git a/drivers/video/mxsfb.c b/drivers/video/mxsfb.c
> index eac7c1a..74fbfd1 100644
> --- a/drivers/video/mxsfb.c
> +++ b/drivers/video/mxsfb.c
> @@ -42,7 +42,6 @@
>  #include <linux/module.h>
>  #include <linux/kernel.h>
>  #include <linux/of_device.h>
> -#include <linux/of_gpio.h>
>  #include <video/of_display_timing.h>
>  #include <linux/platform_device.h>
>  #include <linux/clk.h>
> @@ -50,6 +49,7 @@
>  #include <linux/io.h>
>  #include <linux/pinctrl/consumer.h>
>  #include <linux/fb.h>
> +#include <linux/regulator/consumer.h>
>  #include <video/videomode.h>
>  
>  #define REG_SET	4
> @@ -179,6 +179,7 @@ struct mxsfb_info {
>  	unsigned dotclk_delay;
>  	const struct mxsfb_devdata *devdata;
>  	u32 sync;
> +	struct regulator *reg_lcd;
>  };
>  
>  #define mxsfb_is_v3(host) (host->devdata->ipversion == 3)
> @@ -338,9 +339,19 @@ static void mxsfb_enable_controller(struct fb_info *fb_info)
>  {
>  	struct mxsfb_info *host = to_imxfb_host(fb_info);
>  	u32 reg;
> +	int ret;
>  
>  	dev_dbg(&host->pdev->dev, "%s\n", __func__);
>  
> +	if (!IS_ERR(host->reg_lcd)) {
> +		ret = regulator_enable(host->reg_lcd);
> +		if (ret) {
> +			dev_err(&host->pdev->dev,
> +				"lcd regulator enable failed:	%d\n", ret);
> +			return;
> +		}
> +	}
> +
>  	clk_prepare_enable(host->clk);
>  	clk_set_rate(host->clk, PICOS2KHZ(fb_info->var.pixclock) * 1000U);
>  
> @@ -362,9 +373,19 @@ static void mxsfb_disable_controller(struct fb_info *fb_info)
>  	struct mxsfb_info *host = to_imxfb_host(fb_info);
>  	unsigned loop;
>  	u32 reg;
> +	int ret;
>  
>  	dev_dbg(&host->pdev->dev, "%s\n", __func__);
>  
> +	if (!IS_ERR(host->reg_lcd)) {
> +		ret = regulator_disable(host->reg_lcd);
> +		if (ret) {
> +			dev_err(&host->pdev->dev,
> +				"lcd regulator disable failed: %d\n", ret);
> +			return;
> +		}
> +	}
> +
Shouldn't this be done as the last step of disabling?

>  	/*
>  	 * Even if we disable the controller here, it will still continue
>  	 * until its FIFOs are running out of data
> @@ -859,8 +880,6 @@ static int mxsfb_probe(struct platform_device *pdev)
>  	struct fb_info *fb_info;
>  	struct fb_modelist *modelist;
>  	struct pinctrl *pinctrl;
> -	int panel_enable;
> -	enum of_gpio_flags flags;
>  	int ret;
>  
>  	if (of_id)
> @@ -904,21 +923,7 @@ static int mxsfb_probe(struct platform_device *pdev)
>  		goto fb_release;
>  	}
>  
> -	panel_enable = of_get_named_gpio_flags(pdev->dev.of_node,
> -					       "panel-enable-gpios", 0, &flags);
> -	if (gpio_is_valid(panel_enable)) {
> -		unsigned long f = GPIOF_OUT_INIT_HIGH;
> -		if (flags == OF_GPIO_ACTIVE_LOW)
> -			f = GPIOF_OUT_INIT_LOW;
> -		ret = devm_gpio_request_one(&pdev->dev, panel_enable,
> -					    f, "panel-enable");
> -		if (ret) {
> -			dev_err(&pdev->dev,
> -				"failed to request gpio %d: %d\n",
> -				panel_enable, ret);
> -			goto fb_release;
> -		}
> -	}
> +	host->reg_lcd = devm_regulator_get(&pdev->dev, "lcd");

I prefer to check return here ...

	if (IS_ERR(host->reg_lcd))
		host->reg_lcd = NULL;

... and then use if (host->reg_lcd) in mxsfb_enable[disable]_controller().

Shawn

>  
>  	fb_info->pseudo_palette = devm_kzalloc(&pdev->dev, sizeof(u32) * 16,
>  					       GFP_KERNEL);
> -- 
> 1.7.9.5
> 
> 



From shawn.guo at linaro.org  Sun Apr  7 03:10:30 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Sun, 7 Apr 2013 15:10:30 +0800
Subject: [PATCH v2 0/3] Get rid of big array from imx pinctrl driver
In-Reply-To: <CAOMZO5D1+baoM0vMdPW9bAd4DX8C82BF9H87igFNo78+8D_N3Q@mail.gmail.com>
References: <1361533888-18073-1-git-send-email-shawn.guo@linaro.org>
 <CAOMZO5D1+baoM0vMdPW9bAd4DX8C82BF9H87igFNo78+8D_N3Q@mail.gmail.com>
Message-ID: <20130407071028.GD11898@S2101-09.ap.freescale.net>

On Sat, Apr 06, 2013 at 05:21:37PM -0300, Fabio Estevam wrote:
> Hi Shawn,
> 
> On Fri, Feb 22, 2013 at 8:51 AM, Shawn Guo <shawn.guo at linaro.org> wrote:
> > Changes since v1:
> >  * Remove the absolute path of imxXX-pinfunc.h in binding doc
> >  * Remove the pin id from PIN_FUNC_ID/macro
> >
> > Shawn Guo (3):
> >   ARM: dts: imx: use pre-processor for device trees
> >   ARM: dts: imx: replace magic number with pin function name
> >   pinctrl: imx: move hard-coding data into device tree
> 
> The last patch breaks audio on mx6qsabrelite: after a aplay command
> the processor hangs.

Thanks for spotting it, Fabio.

There is indeed a bug with the patch.  The select input register should
not be defined in imx_pin_reg, because the same pad may have multiple
select input registers for different mux setting values.  So it should
be something defined with pin group.  The following code change should
fix the problem.

I just rebuilt imx/dt branch with the problem fixed and also had the
branch based on Stephen Warren's for-3.10/dtc-cpp-chroot-std-headers
branch so avoid all those dts files renaming.

Shawn

--8<----

diff --git a/drivers/pinctrl/pinctrl-imx.c b/drivers/pinctrl/pinctrl-imx.c
index 479ceb6..b83be7c 100644
--- a/drivers/pinctrl/pinctrl-imx.c
+++ b/drivers/pinctrl/pinctrl-imx.c
@@ -198,6 +198,7 @@ static int imx_pmx_enable(struct pinctrl_dev *pctldev, unsigned selector,
 	const struct imx_pinctrl_soc_info *info = ipctl->info;
 	const struct imx_pin_reg *pin_reg;
 	const unsigned *pins, *mux, *input_val;
+	u16 *input_reg;
 	unsigned int npins, pin_id;
 	int i;
 
@@ -209,6 +210,7 @@ static int imx_pmx_enable(struct pinctrl_dev *pctldev, unsigned selector,
 	npins = info->groups[group].npins;
 	mux = info->groups[group].mux_mode;
 	input_val = info->groups[group].input_val;
+	input_reg = info->groups[group].input_reg;
 
 	WARN_ON(!pins || !npins || !mux || !input_val);
 
@@ -230,11 +232,11 @@ static int imx_pmx_enable(struct pinctrl_dev *pctldev, unsigned selector,
 			pin_reg->mux_reg, mux[i]);
 
 		/* some pins also need select input setting, set it if found */
-		if (pin_reg->input_reg) {
-			writel(input_val[i], ipctl->base + pin_reg->input_reg);
+		if (input_reg[i]) {
+			writel(input_val[i], ipctl->base + input_reg[i]);
 			dev_dbg(ipctl->dev,
 				"==>select_input: offset 0x%x val 0x%x\n",
-				pin_reg->input_reg, input_val[i]);
+				input_reg[i], input_val[i]);
 		}
 	}
 
@@ -411,6 +413,8 @@ static int imx_pinctrl_parse_groups(struct device_node *np,
 				GFP_KERNEL);
 	grp->mux_mode = devm_kzalloc(info->dev, grp->npins * sizeof(unsigned int),
 				GFP_KERNEL);
+	grp->input_reg = devm_kzalloc(info->dev, grp->npins * sizeof(u16),
+				GFP_KERNEL);
 	grp->input_val = devm_kzalloc(info->dev, grp->npins * sizeof(unsigned int),
 				GFP_KERNEL);
 	grp->configs = devm_kzalloc(info->dev, grp->npins * sizeof(unsigned long),
@@ -424,7 +428,7 @@ static int imx_pinctrl_parse_groups(struct device_node *np,
 		grp->pins[i] = pin_id;
 		pin_reg->mux_reg = mux_reg;
 		pin_reg->conf_reg = conf_reg;
-		pin_reg->input_reg = be32_to_cpu(*list++);
+		grp->input_reg[i] = be32_to_cpu(*list++);
 		grp->mux_mode[i] = be32_to_cpu(*list++);
 		grp->input_val[i] = be32_to_cpu(*list++);
 
diff --git a/drivers/pinctrl/pinctrl-imx.h b/drivers/pinctrl/pinctrl-imx.h
index 4749b0a..1f27f24 100644
--- a/drivers/pinctrl/pinctrl-imx.h
+++ b/drivers/pinctrl/pinctrl-imx.h
@@ -26,6 +26,8 @@ struct platform_device;
  *	elements in .pins so we can iterate over that array
  * @mux_mode: the mux mode for each pin in this group. The size of this
  *	array is the same as pins.
+ * @input_reg: select input register offset for this mux if any
+ *	0 if no select input setting needed.
  * @input_val: the select input value for each pin in this group. The size of
  *	this array is the same as pins.
  * @configs: the config for each pin in this group. The size of this
@@ -36,6 +38,7 @@ struct imx_pin_group {
 	unsigned int *pins;
 	unsigned npins;
 	unsigned int *mux_mode;
+	u16 *input_reg;
 	unsigned int *input_val;
 	unsigned long *configs;
 };
@@ -56,13 +59,10 @@ struct imx_pmx_func {
  * struct imx_pin_reg - describe a pin reg map
  * @mux_reg: mux register offset
  * @conf_reg: config register offset
- * @input_reg: select input register offset for this mux if any
- *  0 if no select input setting needed.
  */
 struct imx_pin_reg {
 	u16 mux_reg;
 	u16 conf_reg;
-	u16 input_reg;
 };
 
 struct imx_pinctrl_soc_info {
-- 
1.7.9.5




From shawn.guo at linaro.org  Sun Apr  7 03:15:45 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Sun, 7 Apr 2013 15:15:45 +0800
Subject: [GIT PULL] dt: run C pre-processor on *.dts, create some
 standard headers
In-Reply-To: <1365187610-29422-1-git-send-email-swarren@wwwdotorg.org>
References: <1365187610-29422-1-git-send-email-swarren@wwwdotorg.org>
Message-ID: <20130407071542.GA4214@S2101-09.ap.freescale.net>

On Fri, Apr 05, 2013 at 12:46:50PM -0600, Stephen Warren wrote:
> Rob, it might be worth keeping this in a separate branch in linux-next
> so you can pull it out if it causes any issues. I've been using these
> patches for quite a while now, but there's always opportunity for
> surprises on architectures I don't use. I did just fix a bug when
> building with O= a few days back, hence the V2 that I posted as patches.
> 
> ----------------------------------------------------------------
> 
> This branch enhances the support for running dtc on device tree files.
> 
> A dedicated directory is created for header files that provide constants
> for device-tree bindings.
> 
> The kbuild dependency script processor is enhanced to support processing
> the dependency outputs from multiple separate commands at once.
> 
> The kbuild dtc rule is modified so that the C pre-processor is always
> applied when compiling any device tree.
> 
> Some standard headers are created which define common constants for GPIO,
> IRQ, and ARM GIC device tree bindings.
> 
> ----------------------------------------------------------------
> 
> The following changes since commit 6dbe51c251a327e012439c4772097a13df43c5b8:
> 
>   Linux 3.9-rc1
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra.git tegra-for-3.10-dtc-cpp-chroot-std-headers
> 
I just rebuilt my imx/dt branch based on this to avoid all those dts
files renaming.  So regardless of the path it goes to mainline, I will
need it as a dependency in arm-soc tree.

Shawn

> for you to fetch changes up to 4be505d4fc7a07371a2b658469ca1dda99993ca3:
> 
>   ARM: dt: create a DT header for the GIC
> 
> ----------------------------------------------------------------
> 
> Stephen Warren (7):
>       kbuild: create an "include chroot" for DT bindings
>       kbuild: fixdep: support concatenated dep files
>       kbuild: cmd_dtc_cpp: extract deps from both gcc -E and dtc
>       kbuild: always run gcc -E on *.dts, remove cmd_dtc_cpp
>       ARM: dt: add header to define GPIO flags
>       ARM: dt: add header to define IRQ flags
>       ARM: dt: create a DT header for the GIC
> 
>  arch/arm/boot/dts/include/dt-bindings           |    1 +
>  include/dt-bindings/gpio/gpio.h                 |   15 +++
>  .../dt-bindings/interrupt-controller/arm-gic.h  |   22 +++++
>  include/dt-bindings/interrupt-controller/irq.h  |   19 ++++
>  scripts/Makefile.lib                            |   17 ++--
>  scripts/basic/fixdep.c                          |   93 ++++++++++++------
>  6 files changed, 125 insertions(+), 42 deletions(-)
>  create mode 120000 arch/arm/boot/dts/include/dt-bindings
>  create mode 100644 include/dt-bindings/gpio/gpio.h
>  create mode 100644 include/dt-bindings/interrupt-controller/arm-gic.h
>  create mode 100644 include/dt-bindings/interrupt-controller/irq.h
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss



From jassisinghbrar at gmail.com  Sun Apr  7 05:50:54 2013
From: jassisinghbrar at gmail.com (Jassi Brar)
Date: Sun, 7 Apr 2013 15:20:54 +0530
Subject: [PATCH 0/2] Support device_prep_dma_sg for pl330
In-Reply-To: <1364904076-3130-1-git-send-email-chanho61.park@samsung.com>
References: <1364904076-3130-1-git-send-email-chanho61.park@samsung.com>
Message-ID: <CABb+yY1NA0VDwuHYtoGSA6L80cyjL2TP_kWP89EdMqvA6fQHiw@mail.gmail.com>

On Tue, Apr 2, 2013 at 5:31 PM, Chanho Park <chanho61.park at samsung.com> wrote:
> This patchset support device_prep_dma_sg functionality for pl330 dmaengine
> driver. The prep_dma_sg function prepares descriptors to transfer between src
> and dest memory which consists of scatter/gather list. The patchset contains
> code clean-up to eliminate duplications.
>
> Chanho Park (2):
>   dma: pl330: split off common code to give back descriptors
>   dma: pl330: add pl330_prep_dma_sg to transfer from sglist to sglist
>
>  drivers/dma/pl330.c |  209 ++++++++++++++++++++++++++++++++++++++-------------
>  1 file changed, 157 insertions(+), 52 deletions(-)
>
Acked-by : Jassi Brar <jassisinghbrar at gmail.com>


From chao.xie at marvell.com  Sun Apr  7 06:29:39 2013
From: chao.xie at marvell.com (Chao Xie)
Date: Sun, 7 Apr 2013 06:29:39 -0400
Subject: [V9 PATCH 05/12] usb: phy: phy-mv-usb: use USB2 PHY driver for otg
In-Reply-To: <1365330586-649-1-git-send-email-chao.xie@marvell.com>
References: <1365330586-649-1-git-send-email-chao.xie@marvell.com>
Message-ID: <1365330586-649-6-git-send-email-chao.xie@marvell.com>

Originaly, otg driver will call the callbacks in platform data
for PHY initialization and shut down.
With PHY driver, it will call the APIs provided by PHY driver
for PHY initialization and shut down. It removes the callbacks
in platform data, and at same time it removes one block in the
way of enabling device tree for otg driver.

Signed-off-by: Chao Xie <chao.xie at marvell.com>
---
 drivers/usb/phy/phy-mv-usb.c |   53 ++++++++++++++++++-----------------------
 drivers/usb/phy/phy-mv-usb.h |    2 +-
 2 files changed, 24 insertions(+), 31 deletions(-)

diff --git a/drivers/usb/phy/phy-mv-usb.c b/drivers/usb/phy/phy-mv-usb.c
index c987bbe..9938904 100644
--- a/drivers/usb/phy/phy-mv-usb.c
+++ b/drivers/usb/phy/phy-mv-usb.c
@@ -25,6 +25,7 @@
 #include <linux/usb/otg.h>
 #include <linux/usb/gadget.h>
 #include <linux/usb/hcd.h>
+#include <linux/usb/mv_usb2.h>
 #include <linux/platform_data/mv_usb.h>
 
 #include "phy-mv-usb.h"
@@ -255,15 +256,14 @@ static int mv_otg_enable_internal(struct mv_otg *mvotg)
 	dev_dbg(&mvotg->pdev->dev, "otg enabled\n");
 
 	otg_clock_enable(mvotg);
-	if (mvotg->pdata->phy_init) {
-		retval = mvotg->pdata->phy_init(mvotg->phy_regs);
-		if (retval) {
-			dev_err(&mvotg->pdev->dev,
-				"init phy error %d\n", retval);
-			otg_clock_disable(mvotg);
-			return retval;
-		}
+	retval = usb_phy_init(mvotg->outer_phy);
+	if (retval) {
+		dev_err(&mvotg->pdev->dev,
+			"failed to initialize phy %d\n", retval);
+		otg_clock_disable(mvotg);
+		return retval;
 	}
+
 	mvotg->active = 1;
 
 	return 0;
@@ -282,8 +282,7 @@ static void mv_otg_disable_internal(struct mv_otg *mvotg)
 {
 	if (mvotg->active) {
 		dev_dbg(&mvotg->pdev->dev, "otg disabled\n");
-		if (mvotg->pdata->phy_deinit)
-			mvotg->pdata->phy_deinit(mvotg->phy_regs);
+		usb_phy_shutdown(mvotg->outer_phy);
 		otg_clock_disable(mvotg);
 		mvotg->active = 0;
 	}
@@ -715,6 +714,7 @@ static int mv_otg_probe(struct platform_device *pdev)
 	/* OTG common part */
 	mvotg->pdev = pdev;
 	mvotg->phy.dev = &pdev->dev;
+	mvotg->phy.type = USB_PHY_TYPE_USB2;
 	mvotg->phy.otg = otg;
 	mvotg->phy.label = driver_name;
 	mvotg->phy.state = OTG_STATE_UNDEFINED;
@@ -727,23 +727,8 @@ static int mv_otg_probe(struct platform_device *pdev)
 	for (i = 0; i < OTG_TIMER_NUM; i++)
 		init_timer(&mvotg->otg_ctrl.timer[i]);
 
-	r = platform_get_resource_byname(mvotg->pdev,
-					 IORESOURCE_MEM, "phyregs");
-	if (r == NULL) {
-		dev_err(&pdev->dev, "no phy I/O memory resource defined\n");
-		retval = -ENODEV;
-		goto err_destroy_workqueue;
-	}
-
-	mvotg->phy_regs = devm_ioremap(&pdev->dev, r->start, resource_size(r));
-	if (mvotg->phy_regs == NULL) {
-		dev_err(&pdev->dev, "failed to map phy I/O memory\n");
-		retval = -EFAULT;
-		goto err_destroy_workqueue;
-	}
-
-	r = platform_get_resource_byname(mvotg->pdev,
-					 IORESOURCE_MEM, "capregs");
+	r = platform_get_resource(mvotg->pdev,
+					 IORESOURCE_MEM, 0);
 	if (r == NULL) {
 		dev_err(&pdev->dev, "no I/O memory resource defined\n");
 		retval = -ENODEV;
@@ -757,6 +742,14 @@ static int mv_otg_probe(struct platform_device *pdev)
 		goto err_destroy_workqueue;
 	}
 
+	mvotg->outer_phy = devm_usb_get_phy_dev(&pdev->dev, MV_USB2_PHY_INDEX);
+	if (IS_ERR_OR_NULL(mvotg->outer_phy)) {
+		retval = PTR_ERR(mvotg->outer_phy);
+		if (retval != -EPROBE_DEFER)
+			dev_err(&pdev->dev, "can not find outer phy\n");
+		goto err_destroy_workqueue;
+	}
+
 	/* we will acces controller register, so enable the udc controller */
 	retval = mv_otg_enable_internal(mvotg);
 	if (retval) {
@@ -816,7 +809,7 @@ static int mv_otg_probe(struct platform_device *pdev)
 		goto err_disable_clk;
 	}
 
-	retval = usb_add_phy(&mvotg->phy, USB_PHY_TYPE_USB2);
+	retval = usb_add_phy_dev(&mvotg->phy);
 	if (retval < 0) {
 		dev_err(&pdev->dev, "can't register transceiver, %d\n",
 			retval);
@@ -827,7 +820,7 @@ static int mv_otg_probe(struct platform_device *pdev)
 	if (retval < 0) {
 		dev_dbg(&pdev->dev,
 			"Can't register sysfs attr group: %d\n", retval);
-		goto err_remove_phy;
+		goto err_remove_otg_phy;
 	}
 
 	spin_lock_init(&mvotg->wq_lock);
@@ -842,7 +835,7 @@ static int mv_otg_probe(struct platform_device *pdev)
 
 	return 0;
 
-err_remove_phy:
+err_remove_otg_phy:
 	usb_remove_phy(&mvotg->phy);
 err_disable_clk:
 	mv_otg_disable_internal(mvotg);
diff --git a/drivers/usb/phy/phy-mv-usb.h b/drivers/usb/phy/phy-mv-usb.h
index 551da6e..6df6219 100644
--- a/drivers/usb/phy/phy-mv-usb.h
+++ b/drivers/usb/phy/phy-mv-usb.h
@@ -137,10 +137,10 @@ struct mv_otg_regs {
 
 struct mv_otg {
 	struct usb_phy phy;
+	struct usb_phy *outer_phy;
 	struct mv_otg_ctrl otg_ctrl;
 
 	/* base address */
-	void __iomem *phy_regs;
 	void __iomem *cap_regs;
 	struct mv_otg_regs __iomem *op_regs;
 
-- 
1.7.4.1



From chao.xie at marvell.com  Sun Apr  7 06:29:43 2013
From: chao.xie at marvell.com (Chao Xie)
Date: Sun, 7 Apr 2013 06:29:43 -0400
Subject: [V9 PATCH 09/12] arm: ttc_dkb: modify usb support
In-Reply-To: <1365330586-649-1-git-send-email-chao.xie@marvell.com>
References: <1365330586-649-1-git-send-email-chao.xie@marvell.com>
Message-ID: <1365330586-649-10-git-send-email-chao.xie@marvell.com>

for ttc_dkb board, we use phy driver for usb support.
Modify the usb support for udc/otg/ehci support.

Signed-off-by: Chao Xie <chao.xie at marvell.com>
---
 arch/arm/mach-mmp/ttc_dkb.c |   39 ++++++++++++++++++++++++++++++---------
 1 files changed, 30 insertions(+), 9 deletions(-)

diff --git a/arch/arm/mach-mmp/ttc_dkb.c b/arch/arm/mach-mmp/ttc_dkb.c
index 6528a5f..c8b9ed8 100644
--- a/arch/arm/mach-mmp/ttc_dkb.c
+++ b/arch/arm/mach-mmp/ttc_dkb.c
@@ -18,6 +18,8 @@
 #include <linux/i2c/pca953x.h>
 #include <linux/gpio.h>
 #include <linux/mfd/88pm860x.h>
+#include <linux/usb/phy.h>
+#include <linux/usb/mv_usb2.h>
 #include <linux/platform_data/mv_usb.h>
 #include <linux/spi/spi.h>
 #include <linux/delay.h>
@@ -29,7 +31,6 @@
 #include <mach/mfp-pxa910.h>
 #include <mach/pxa910.h>
 #include <mach/irqs.h>
-#include <mach/regs-usb.h>
 
 #include "common.h"
 
@@ -166,8 +167,6 @@ static struct mv_usb_platform_data ttc_usb_pdata = {
 	.vbus		= NULL,
 	.mode		= MV_USB_MODE_OTG,
 	.otg_force_a_bus_req = 1,
-	.phy_init	= pxa_usb_phy_init,
-	.phy_deinit	= pxa_usb_phy_deinit,
 	.set_vbus	= NULL,
 };
 #endif
@@ -280,19 +279,41 @@ static void __init ttc_dkb_init(void)
 	pxa910_add_twsi(0, NULL, ARRAY_AND_SIZE(ttc_dkb_i2c_info));
 	platform_add_devices(ARRAY_AND_SIZE(ttc_dkb_devices));
 
+#ifdef CONFIG_USB_SUPPORT
+	pxa_register_device(&pxa910_device_u2ophy, NULL, 0);
+#endif
+
 #ifdef CONFIG_USB_MV_UDC
-	pxa168_device_u2o.dev.platform_data = &ttc_usb_pdata;
-	platform_device_register(&pxa168_device_u2o);
+	/* for usb2 phy */
+	usb_bind_phy(pxa910_device_u2o.drv_name, MV_USB2_PHY_INDEX,
+		     pxa910_device_u2ophy.drv_name);
+#ifdef CONFIG_USB_MV_OTG
+	/* for usb2 otg phy */
+	usb_bind_phy(pxa910_device_u2o.drv_name, MV_USB2_OTG_PHY_INDEX,
+		     pxa910_device_u2ootg.drv_name);
+#endif
+	pxa_register_device(&pxa910_device_u2o, &ttc_usb_pdata,
+			    sizeof(ttc_usb_pdata));
 #endif
 
 #ifdef CONFIG_USB_EHCI_MV_U2O
-	pxa168_device_u2oehci.dev.platform_data = &ttc_usb_pdata;
-	platform_device_register(&pxa168_device_u2oehci);
+	/* for usb2 phy */
+	usb_bind_phy(pxa910_device_u2oehci.drv_name, MV_USB2_PHY_INDEX,
+		     pxa910_device_u2ophy.drv_name);
+#ifdef CONFIG_USB_MV_OTG
+	/* for usb2 otg phy */
+	usb_bind_phy(pxa910_device_u2oehci.drv_name, MV_USB2_OTG_PHY_INDEX,
+		     pxa910_device_u2ootg.drv_name);
+#endif
+	pxa_register_device(&pxa910_device_u2oehci, &ttc_usb_pdata,
+			    sizeof(ttc_usb_pdata));
 #endif
 
 #ifdef CONFIG_USB_MV_OTG
-	pxa168_device_u2ootg.dev.platform_data = &ttc_usb_pdata;
-	platform_device_register(&pxa168_device_u2ootg);
+	usb_bind_phy(pxa910_device_u2ootg.drv_name, MV_USB2_PHY_INDEX,
+		     pxa910_device_u2ophy.drv_name);
+	pxa_register_device(&pxa910_device_u2ootg, &ttc_usb_pdata,
+			    sizeof(ttc_usb_pdata));
 #endif
 
 #ifdef CONFIG_MMP_DISP
-- 
1.7.4.1



From chao.xie at marvell.com  Sun Apr  7 06:29:44 2013
From: chao.xie at marvell.com (Chao Xie)
Date: Sun, 7 Apr 2013 06:29:44 -0400
Subject: [V9 PATCH 10/12] arm: mmp: remove unused usb devices
In-Reply-To: <1365330586-649-1-git-send-email-chao.xie@marvell.com>
References: <1365330586-649-1-git-send-email-chao.xie@marvell.com>
Message-ID: <1365330586-649-11-git-send-email-chao.xie@marvell.com>

We defined new usb devices for usb ehci/udc/otg/phy.
So remove the old definitions.

Signed-off-by: Chao Xie <chao.xie at marvell.com>
---
 arch/arm/mach-mmp/include/mach/pxa910.h |    3 ---
 1 files changed, 0 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-mmp/include/mach/pxa910.h b/arch/arm/mach-mmp/include/mach/pxa910.h
index c695982..d17ffee 100644
--- a/arch/arm/mach-mmp/include/mach/pxa910.h
+++ b/arch/arm/mach-mmp/include/mach/pxa910.h
@@ -19,9 +19,6 @@ extern struct pxa_device_desc pxa910_device_pwm2;
 extern struct pxa_device_desc pxa910_device_pwm3;
 extern struct pxa_device_desc pxa910_device_pwm4;
 extern struct pxa_device_desc pxa910_device_nand;
-extern struct platform_device pxa168_device_u2o;
-extern struct platform_device pxa168_device_u2ootg;
-extern struct platform_device pxa168_device_u2oehci;
 extern struct pxa_device_desc pxa910_device_u2o;
 extern struct pxa_device_desc pxa910_device_u2ootg;
 extern struct pxa_device_desc pxa910_device_u2oehci;
-- 
1.7.4.1



From chao.xie at marvell.com  Sun Apr  7 06:29:45 2013
From: chao.xie at marvell.com (Chao Xie)
Date: Sun, 7 Apr 2013 06:29:45 -0400
Subject: [V9 PATCH 11/12] arm: brownstone: add usb support for the board
In-Reply-To: <1365330586-649-1-git-send-email-chao.xie@marvell.com>
References: <1365330586-649-1-git-send-email-chao.xie@marvell.com>
Message-ID: <1365330586-649-12-git-send-email-chao.xie@marvell.com>

for brownstone board, add the udc/otg/ehci support

Signed-off-by: Chao Xie <chao.xie at marvell.com>
---
 arch/arm/mach-mmp/brownstone.c |   56 ++++++++++++++++++++++++++++++++++++++++
 1 files changed, 56 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-mmp/brownstone.c b/arch/arm/mach-mmp/brownstone.c
index 2358011..aed553a 100644
--- a/arch/arm/mach-mmp/brownstone.c
+++ b/arch/arm/mach-mmp/brownstone.c
@@ -18,6 +18,9 @@
 #include <linux/regulator/max8649.h>
 #include <linux/regulator/fixed.h>
 #include <linux/mfd/max8925.h>
+#include <linux/usb/phy.h>
+#include <linux/usb/mv_usb2.h>
+#include <linux/platform_data/mv_usb.h>
 
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
@@ -195,6 +198,20 @@ static struct sram_platdata mmp2_isram_platdata = {
 	.granularity	= SRAM_GRANULARITY,
 };
 
+#ifdef CONFIG_USB_SUPPORT
+
+#if defined(CONFIG_USB_MV_UDC) || defined(CONFIG_USB_EHCI_MV_U2O)
+
+static struct mv_usb_platform_data brownstone_usb_pdata = {
+	.vbus		= NULL,
+	.mode		= MV_USB_MODE_OTG,
+	.otg_force_a_bus_req = 1,
+	.set_vbus	= NULL,
+};
+#endif
+#endif
+
+
 static void __init brownstone_init(void)
 {
 	mfp_config(ARRAY_AND_SIZE(brownstone_pin_config));
@@ -211,6 +228,45 @@ static void __init brownstone_init(void)
 
 	/* enable 5v regulator */
 	platform_device_register(&brownstone_v_5vp_device);
+
+#ifdef CONFIG_USB_SUPPORT
+	pxa_register_device(&mmp2_device_u2ophy, NULL, 0);
+#endif
+
+#ifdef CONFIG_USB_MV_UDC
+	/* for usb2 phy */
+	usb_bind_phy(mmp2_device_u2o.drv_name, MV_USB2_PHY_INDEX,
+		     mmp2_device_u2ophy.drv_name);
+#ifdef CONFIG_USB_MV_OTG
+	/* for usb2 otg phy */
+	usb_bind_phy(mmp2_device_u2o.drv_name, MV_USB2_OTG_PHY_INDEX,
+		     mmp2_device_u2ootg.drv_name);
+#endif
+	pxa_register_device(&mmp2_device_u2o, &brownstone_usb_pdata,
+			    sizeof(brownstone_usb_pdata));
+#endif
+
+#ifdef CONFIG_USB_EHCI_MV_U2O
+	/* for usb2 phy */
+	usb_bind_phy(mmp2_device_u2oehci.dev_name, MV_USB2_PHY_INDEX,
+		     mmp2_device_u2ophy.dev_name);
+#ifdef CONFIG_USB_MV_OTG
+	/* for usb2 otg phy */
+	usb_bind_phy(mmp2_device_u2oehci.drv_name, MV_USB2_OTG_PHY_INDEX,
+		     mmp2_device_u2ootg.drv_name);
+#endif
+	pxa_register_device(&mmp2_device_u2oehci, &brownstone_usb_pdata,
+			    sizeof(brownstone_usb_pdata));
+#endif
+
+#ifdef CONFIG_USB_MV_OTG
+	/* for usb2 phy */
+	usb_bind_phy(mmp2_device_u2ootg.dev_name, MV_USB2_PHY_INDEX,
+		     mmp2_device_u2ophy.dev_name);
+	pxa_register_device(&mmp2_device_u2ootg, &brownstone_usb_pdata,
+			    sizeof(brownstone_usb_pdata));
+#endif
+
 }
 
 MACHINE_START(BROWNSTONE, "Brownstone Development Platform")
-- 
1.7.4.1



From chao.xie at marvell.com  Sun Apr  7 06:29:46 2013
From: chao.xie at marvell.com (Chao Xie)
Date: Sun, 7 Apr 2013 06:29:46 -0400
Subject: [V9 PATCH 12/12] usb: mv_usb: remove the phy callbacks in pdata
In-Reply-To: <1365330586-649-1-git-send-email-chao.xie@marvell.com>
References: <1365330586-649-1-git-send-email-chao.xie@marvell.com>
Message-ID: <1365330586-649-13-git-send-email-chao.xie@marvell.com>

The phy initialization code will be done by phy driver.

Signed-off-by: Chao Xie <chao.xie at marvell.com>
---
 include/linux/platform_data/mv_usb.h |    3 ---
 1 files changed, 0 insertions(+), 3 deletions(-)

diff --git a/include/linux/platform_data/mv_usb.h b/include/linux/platform_data/mv_usb.h
index 98b7925..b4b5d6f 100644
--- a/include/linux/platform_data/mv_usb.h
+++ b/include/linux/platform_data/mv_usb.h
@@ -45,9 +45,6 @@ struct mv_usb_platform_data {
 	/* Force a_bus_req to be asserted */
 	 unsigned int    otg_force_a_bus_req:1;
 
-	int	(*phy_init)(void __iomem *regbase);
-	void	(*phy_deinit)(void __iomem *regbase);
 	int	(*set_vbus)(unsigned int vbus);
-	int     (*private_init)(void __iomem *opregs, void __iomem *phyregs);
 };
 #endif
-- 
1.7.4.1



From chao.xie at marvell.com  Sun Apr  7 06:29:35 2013
From: chao.xie at marvell.com (Chao Xie)
Date: Sun, 7 Apr 2013 06:29:35 -0400
Subject: [V9 PATCH 01/12] usb: phy: protect phy init and shutdown for mutiple
 deivces
In-Reply-To: <1365330586-649-1-git-send-email-chao.xie@marvell.com>
References: <1365330586-649-1-git-send-email-chao.xie@marvell.com>
Message-ID: <1365330586-649-2-git-send-email-chao.xie@marvell.com>

Some USB devices will share same phy, so make the ->init
and ->shutdown to be protected.
Only first device will initialize the phy, and only last device
can shutdown phy.

Signed-off-by: Chao Xie <chao.xie at marvell.com>
---
 drivers/usb/phy/phy.c   |    6 ++++++
 include/linux/usb/phy.h |   22 ++++++++++++++++++----
 2 files changed, 24 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/phy/phy.c b/drivers/usb/phy/phy.c
index f52c006..168332b 100644
--- a/drivers/usb/phy/phy.c
+++ b/drivers/usb/phy/phy.c
@@ -329,6 +329,9 @@ int usb_add_phy(struct usb_phy *x, enum usb_phy_type type)
 		return -EINVAL;
 	}
 
+	mutex_init(&x->phy_mutex);
+	x->refcount = 0;
+
 	spin_lock_irqsave(&phy_lock, flags);
 
 	list_for_each_entry(phy, &phy_list, head) {
@@ -367,6 +370,9 @@ int usb_add_phy_dev(struct usb_phy *x)
 		return -EINVAL;
 	}
 
+	mutex_init(&x->phy_mutex);
+	x->refcount = 0;
+
 	spin_lock_irqsave(&phy_lock, flags);
 	list_for_each_entry(phy_bind, &phy_bind_list, list)
 		if (!(strcmp(phy_bind->phy_dev_name, dev_name(x->dev))))
diff --git a/include/linux/usb/phy.h b/include/linux/usb/phy.h
index 6b5978f..98d7e60 100644
--- a/include/linux/usb/phy.h
+++ b/include/linux/usb/phy.h
@@ -87,6 +87,14 @@ struct usb_phy {
 	/* to support controllers that have multiple transceivers */
 	struct list_head	head;
 
+	/*
+	 * PHY may be shared by multiple devices.
+	 * mutex and refcount are used to make sure PHY only initialize or
+	 * shutdown once.
+	 */
+	struct mutex		phy_mutex;
+	unsigned int		refcount;
+
 	/* initialize/shutdown the OTG controller */
 	int	(*init)(struct usb_phy *x);
 	void	(*shutdown)(struct usb_phy *x);
@@ -150,17 +158,23 @@ static inline int usb_phy_io_write(struct usb_phy *x, u32 val, u32 reg)
 static inline int
 usb_phy_init(struct usb_phy *x)
 {
-	if (x->init)
-		return x->init(x);
+	int ret = 0;
 
-	return 0;
+	mutex_lock(&x->phy_mutex);
+	if (x->refcount++ == 0 && x->init)
+		ret = x->init(x);
+	mutex_unlock(&x->phy_mutex);
+
+	return ret;
 }
 
 static inline void
 usb_phy_shutdown(struct usb_phy *x)
 {
-	if (x->shutdown)
+	mutex_lock(&x->phy_mutex);
+	if (--x->refcount == 0 && x->shutdown)
 		x->shutdown(x);
+	mutex_unlock(&x->phy_mutex);
 }
 
 static inline int
-- 
1.7.4.1



From chao.xie at marvell.com  Sun Apr  7 06:29:36 2013
From: chao.xie at marvell.com (Chao Xie)
Date: Sun, 7 Apr 2013 06:29:36 -0400
Subject: [V9 PATCH 02/12] usb: phy: mv_usb2: add PHY driver for marvell usb2
 controller
In-Reply-To: <1365330586-649-1-git-send-email-chao.xie@marvell.com>
References: <1365330586-649-1-git-send-email-chao.xie@marvell.com>
Message-ID: <1365330586-649-3-git-send-email-chao.xie@marvell.com>

The PHY is seperated from usb controller.
The usb controller used in marvell pxa168/pxa910/mmp2 are same,
but PHY initialization may be different.
the usb controller can support udc/otg/ehci, and for each of
the mode, it need PHY to initialized before use the controller.
Direclty writing the phy driver will make the usb controller
driver to be simple and portable.
The PHY driver will be used by marvell udc/otg/ehci.

Signed-off-by: Chao Xie <chao.xie at marvell.com>
---
 drivers/usb/phy/Kconfig       |    9 +
 drivers/usb/phy/Makefile      |    1 +
 drivers/usb/phy/phy-mv-usb2.c |  379 +++++++++++++++++++++++++++++++++++++++++
 include/linux/usb/mv_usb2.h   |   29 +++
 4 files changed, 418 insertions(+), 0 deletions(-)
 create mode 100644 drivers/usb/phy/phy-mv-usb2.c
 create mode 100644 include/linux/usb/mv_usb2.h

diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index 372db48..bdc7603 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -170,6 +170,15 @@ config USB_MV_OTG
 
 	  To compile this driver as a module, choose M here.
 
+config MV_USB2_PHY
+	tristate "Marvell USB 2.0 PHY Driver"
+	help
+	  Enable this to support Marvell USB 2.0 phy driver for Marvell
+	  SoC. This driver will do the PHY initialization and shutdown.
+	  The PHY driver will be used by Marvell udc/ehci/otg driver.
+
+	  To compile this driver as a module, choose M here.
+
 config USB_MXS_PHY
 	tristate "Freescale MXS USB PHY support"
 	depends on ARCH_MXC || ARCH_MXS
diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
index 33863c0..90cc5f5 100644
--- a/drivers/usb/phy/Makefile
+++ b/drivers/usb/phy/Makefile
@@ -26,6 +26,7 @@ obj-$(CONFIG_USB_EHCI_TEGRA)		+= phy-tegra-usb.o
 obj-$(CONFIG_USB_GPIO_VBUS)		+= phy-gpio-vbus-usb.o
 obj-$(CONFIG_USB_ISP1301)		+= phy-isp1301.o
 obj-$(CONFIG_USB_MSM_OTG)		+= phy-msm-usb.o
+obj-$(CONFIG_MV_USB2_PHY)		+= phy-mv-usb2.o
 obj-$(CONFIG_USB_MV_OTG)		+= phy-mv-usb.o
 obj-$(CONFIG_USB_MXS_PHY)		+= phy-mxs-usb.o
 obj-$(CONFIG_USB_RCAR_PHY)		+= phy-rcar-usb.o
diff --git a/drivers/usb/phy/phy-mv-usb2.c b/drivers/usb/phy/phy-mv-usb2.c
new file mode 100644
index 0000000..43459ef
--- /dev/null
+++ b/drivers/usb/phy/phy-mv-usb2.c
@@ -0,0 +1,379 @@
+/*
+ * Copyright (C) 2013 Marvell Inc.
+ *
+ * Author:
+ *	Chao Xie <xiechao.mail at gmail.com>
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include <linux/resource.h>
+#include <linux/delay.h>
+#include <linux/slab.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/io.h>
+#include <linux/err.h>
+#include <linux/clk.h>
+#include <linux/export.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/platform_data/mv_usb.h>
+#include <linux/usb/phy.h>
+#include <linux/usb/mv_usb2.h>
+
+/* phy regs */
+/* for pxa910 and mmp2, there is no revision register */
+#define MV_USB2_UTMI_REVISION		0x0
+#define MV_USB2_UTMI_CTRL		0x4
+#define MV_USB2_UTMI_PLL		0x8
+#define MV_USB2_UTMI_TX			0xc
+#define MV_USB2_UTMI_RX			0x10
+#define MV_USB2_UTMI_IVREF		0x14
+#define MV_USB2_UTMI_T0			0x18
+#define MV_USB2_UTMI_T1			0x1c
+#define MV_USB2_UTMI_T2			0x20
+#define MV_USB2_UTMI_T3			0x24
+#define MV_USB2_UTMI_T4			0x28
+#define MV_USB2_UTMI_T5			0x2c
+#define MV_USB2_UTMI_RESERVE		0x30
+#define MV_USB2_UTMI_USB_INT		0x34
+#define MV_USB2_UTMI_DBG_CTL		0x38
+#define MV_USB2_UTMI_OTG_ADDON		0x3c
+
+/* For UTMICTRL Register */
+#define MV_USB2_UTMI_CTRL_USB_CLK_EN			(1 << 31)
+/* pxa168 */
+#define MV_USB2_UTMI_CTRL_SUSPEND_SET1			(1 << 30)
+#define MV_USB2_UTMI_CTRL_SUSPEND_SET2			(1 << 29)
+#define MV_USB2_UTMI_CTRL_RXBUF_PDWN			(1 << 24)
+#define MV_USB2_UTMI_CTRL_TXBUF_PDWN			(1 << 11)
+
+#define MV_USB2_UTMI_CTRL_INPKT_DELAY_SHIFT		30
+#define MV_USB2_UTMI_CTRL_INPKT_DELAY_SOF_SHIFT		28
+#define MV_USB2_UTMI_CTRL_PU_REF_SHIFT			20
+#define MV_USB2_UTMI_CTRL_ARC_PULLDN_SHIFT		12
+#define MV_USB2_UTMI_CTRL_PLL_PWR_UP_SHIFT		1
+#define MV_USB2_UTMI_CTRL_PWR_UP_SHIFT			0
+
+/* For UTMI_PLL Register */
+#define MV_USB2_UTMI_PLL_PLLCALI12_SHIFT		29
+#define MV_USB2_UTMI_PLL_PLLCALI12_MASK			(0x3 << 29)
+
+#define MV_USB2_UTMI_PLL_PLLVDD18_SHIFT			27
+#define MV_USB2_UTMI_PLL_PLLVDD18_MASK			(0x3 << 27)
+
+#define MV_USB2_UTMI_PLL_PLLVDD12_SHIFT			25
+#define MV_USB2_UTMI_PLL_PLLVDD12_MASK			(0x3 << 25)
+
+#define MV_USB2_UTMI_PLL_PLL_READY			(0x1 << 23)
+#define MV_USB2_UTMI_PLL_KVCO_EXT			(0x1 << 22)
+#define MV_USB2_UTMI_PLL_VCOCAL_START			(0x1 << 21)
+
+#define MV_USB2_UTMI_PLL_KVCO_SHIFT			15
+#define MV_USB2_UTMI_PLL_KVCO_MASK			(0x7 << 15)
+
+#define MV_USB2_UTMI_PLL_ICP_SHIFT			12
+#define MV_USB2_UTMI_PLL_ICP_MASK			(0x7 << 12)
+
+#define MV_USB2_UTMI_PLL_FBDIV_SHIFT			4
+#define MV_USB2_UTMI_PLL_FBDIV_MASK			(0xFF << 4)
+
+#define MV_USB2_UTMI_PLL_REFDIV_SHIFT			0
+#define MV_USB2_UTMI_PLL_REFDIV_MASK			(0xF << 0)
+
+/* For UTMI_TX Register */
+#define MV_USB2_UTMI_TX_REG_EXT_FS_RCAL_SHIFT		27
+#define MV_USB2_UTMI_TX_REG_EXT_FS_RCAL_MASK		(0xf << 27)
+
+#define MV_USB2_UTMI_TX_REG_EXT_FS_RCAL_EN_SHIFT	26
+#define MV_USB2_UTMI_TX_REG_EXT_FS_RCAL_EN_MASK		(0x1 << 26)
+
+#define MV_USB2_UTMI_TX_TXVDD12_SHIFT			22
+#define MV_USB2_UTMI_TX_TXVDD12_MASK			(0x3 << 22)
+
+#define MV_USB2_UTMI_TX_CK60_PHSEL_SHIFT		17
+#define MV_USB2_UTMI_TX_CK60_PHSEL_MASK			(0xf << 17)
+
+#define MV_USB2_UTMI_TX_IMPCAL_VTH_SHIFT		14
+#define MV_USB2_UTMI_TX_IMPCAL_VTH_MASK			(0x7 << 14)
+
+#define MV_USB2_UTMI_TX_REG_RCAL_START			(0x1 << 12)
+
+#define MV_USB2_UTMI_TX_LOW_VDD_EN_SHIFT		11
+
+#define MV_USB2_UTMI_TX_AMP_SHIFT			0
+#define MV_USB2_UTMI_TX_AMP_MASK			(0x7 << 0)
+
+/* For UTMI_RX Register */
+#define MV_USB2_UTMI_RX_REG_SQ_LENGTH_SHIFT		15
+#define MV_USB2_UTMI_RX_REG_SQ_LENGTH_MASK		(0x3 << 15)
+
+#define MV_USB2_UTMI_RX_SQ_THRESH_SHIFT			4
+#define MV_USB2_UTMI_RX_SQ_THRESH_MASK			(0xf << 4)
+
+/* For UTMI_OTG_ADDON Register. Only for pxa168 */
+#define MV_USB2_UTMI_OTG_ADDON_OTG_ON			(1 << 0)
+
+enum mv_usb2_phy_type {
+	PXA168_USB,
+	PXA910_USB,
+	MMP2_USB,
+};
+
+static int _mv_usb2_phy_init(struct mv_usb2_phy *mv_phy)
+{
+	struct platform_device *pdev = mv_phy->pdev;
+	unsigned int loops = 0;
+	void __iomem *base = mv_phy->base;
+	unsigned int val;
+
+	val = readl(base + MV_USB2_UTMI_CTRL);
+	/* Initialize the USB PHY power */
+	if (mv_phy->type == PXA910_USB) {
+		val |= (1 << MV_USB2_UTMI_CTRL_INPKT_DELAY_SOF_SHIFT)
+			| (1 << MV_USB2_UTMI_CTRL_PU_REF_SHIFT);
+	}
+
+	val |= (1 << MV_USB2_UTMI_CTRL_PLL_PWR_UP_SHIFT)
+		| (1 << MV_USB2_UTMI_CTRL_PWR_UP_SHIFT);
+	writel(val, base + MV_USB2_UTMI_CTRL);
+
+	/* UTMI_PLL settings */
+	val = readl(base + MV_USB2_UTMI_PLL);
+	val &= ~(MV_USB2_UTMI_PLL_PLLVDD18_MASK
+		| MV_USB2_UTMI_PLL_PLLVDD12_MASK
+		| MV_USB2_UTMI_PLL_PLLCALI12_MASK
+		| MV_USB2_UTMI_PLL_FBDIV_MASK
+		| MV_USB2_UTMI_PLL_REFDIV_MASK
+		| MV_USB2_UTMI_PLL_ICP_MASK
+		| MV_USB2_UTMI_PLL_KVCO_MASK
+		| MV_USB2_UTMI_PLL_VCOCAL_START);
+
+	val |= (0xee << MV_USB2_UTMI_PLL_FBDIV_SHIFT)
+		| (0xb << MV_USB2_UTMI_PLL_REFDIV_SHIFT)
+		| (3 << MV_USB2_UTMI_PLL_PLLVDD18_SHIFT)
+		| (3 << MV_USB2_UTMI_PLL_PLLVDD12_SHIFT)
+		| (3 << MV_USB2_UTMI_PLL_PLLCALI12_SHIFT)
+		| (1 << MV_USB2_UTMI_PLL_ICP_SHIFT)
+		| (3 << MV_USB2_UTMI_PLL_KVCO_SHIFT);
+	writel(val, base + MV_USB2_UTMI_PLL);
+
+	/* UTMI_TX */
+	val = readl(base + MV_USB2_UTMI_TX);
+	val &= ~(MV_USB2_UTMI_TX_REG_EXT_FS_RCAL_EN_MASK
+		| MV_USB2_UTMI_TX_TXVDD12_MASK
+		| MV_USB2_UTMI_TX_CK60_PHSEL_MASK
+		| MV_USB2_UTMI_TX_IMPCAL_VTH_MASK
+		| MV_USB2_UTMI_TX_REG_EXT_FS_RCAL_MASK
+		| MV_USB2_UTMI_TX_AMP_MASK
+		| MV_USB2_UTMI_TX_REG_RCAL_START);
+	val |= (3 << MV_USB2_UTMI_TX_TXVDD12_SHIFT)
+		| (4 << MV_USB2_UTMI_TX_CK60_PHSEL_SHIFT)
+		| (4 << MV_USB2_UTMI_TX_IMPCAL_VTH_SHIFT)
+		| (8 << MV_USB2_UTMI_TX_REG_EXT_FS_RCAL_SHIFT)
+		| (3 << MV_USB2_UTMI_TX_AMP_SHIFT);
+	writel(val, base + MV_USB2_UTMI_TX);
+
+	/* UTMI_RX */
+	val = readl(base + MV_USB2_UTMI_RX);
+	val &= ~(MV_USB2_UTMI_RX_SQ_THRESH_MASK
+		| MV_USB2_UTMI_RX_REG_SQ_LENGTH_MASK);
+	val |= (7 << MV_USB2_UTMI_RX_SQ_THRESH_SHIFT)
+		| (2 << MV_USB2_UTMI_RX_REG_SQ_LENGTH_SHIFT);
+	writel(val, base + MV_USB2_UTMI_RX);
+
+	/* UTMI_IVREF */
+	if (mv_phy->type == PXA168_USB)
+		/*
+		 * Fixing Microsoft Altair board interface with NEC hub issue -
+		 * Set UTMI_IVREF from 0x4a3 to 0x4bf.
+		 */
+		writel(0x4bf, base + MV_USB2_UTMI_IVREF);
+
+	/*
+	 * Toggle VCOCAL_START bit of UTMI_PLL. It is active at rising edge.
+	 * It is low level by UTMI_PLL initialization above.
+	 */
+	val = readl(base + MV_USB2_UTMI_PLL);
+	/*
+	 * Delay 200us for low level, and 40us for high level.
+	 * Make sure we can get a effective rising edege.
+	 * It should be set to low after issue rising edge.
+	 * The delay value is suggested by DE.
+	 */
+	usleep_range(200, 300);
+	val |= MV_USB2_UTMI_PLL_VCOCAL_START;
+	writel(val, base + MV_USB2_UTMI_PLL);
+	usleep_range(40, 50);
+	val &= ~MV_USB2_UTMI_PLL_VCOCAL_START;
+	writel(val, base + MV_USB2_UTMI_PLL);
+
+	/*
+	 * Toggle REG_RCAL_START bit of UTMI_TX.
+	 * it is low level by UTMI_TX initialization above.
+	 */
+	val = readl(base + MV_USB2_UTMI_TX);
+	/* same as VCOCAL_START, except it is triggered by low->high->low */
+	usleep_range(400, 500);
+	val |= MV_USB2_UTMI_TX_REG_RCAL_START;
+	writel(val, base + MV_USB2_UTMI_TX);
+	usleep_range(40, 50);
+	val &= ~MV_USB2_UTMI_TX_REG_RCAL_START;
+	writel(val, base + MV_USB2_UTMI_TX);
+	usleep_range(400, 500);
+
+	/* Make sure PHY PLL is ready */
+	loops = 0;
+	while (1) {
+		val = readl(base + MV_USB2_UTMI_PLL);
+		if (val & MV_USB2_UTMI_PLL_PLL_READY)
+			break;
+		usleep_range(1000, 1100);
+		loops++;
+		if (loops > 100) {
+			dev_warn(&pdev->dev, "calibrate timeout, UTMI_PLL %x\n",
+				 readl(base + MV_USB2_UTMI_PLL));
+			return -ETIME;
+		}
+	}
+
+	if (mv_phy->type == PXA168_USB) {
+		val = readl(base + MV_USB2_UTMI_RESERVE);
+		val |= (1 << 5);
+		writel(val, base + MV_USB2_UTMI_RESERVE);
+		/* Turn on UTMI PHY OTG extension */
+		writel(MV_USB2_UTMI_OTG_ADDON_OTG_ON,
+		       base + MV_USB2_UTMI_OTG_ADDON);
+	}
+
+	return 0;
+}
+
+static int _mv_usb2_phy_shutdown(struct mv_usb2_phy *mv_phy)
+{
+	void __iomem *base = mv_phy->base;
+	unsigned int val;
+
+	if (mv_phy->type == PXA168_USB)
+		writel(0, base + MV_USB2_UTMI_OTG_ADDON);
+
+	val = readl(base + MV_USB2_UTMI_CTRL);
+	val &= ~(MV_USB2_UTMI_CTRL_RXBUF_PDWN
+		| MV_USB2_UTMI_CTRL_TXBUF_PDWN
+		| MV_USB2_UTMI_CTRL_USB_CLK_EN
+		| (1 << MV_USB2_UTMI_CTRL_PWR_UP_SHIFT)
+		| (1 << MV_USB2_UTMI_CTRL_PLL_PWR_UP_SHIFT));
+
+	writel(val, base + MV_USB2_UTMI_CTRL);
+
+	return 0;
+}
+
+static int mv_usb2_phy_init(struct usb_phy *phy)
+{
+	struct mv_usb2_phy *mv_phy = container_of(phy, struct mv_usb2_phy, phy);
+
+	clk_prepare_enable(mv_phy->clk);
+	_mv_usb2_phy_init(mv_phy);
+
+	return 0;
+}
+
+static void mv_usb2_phy_shutdown(struct usb_phy *phy)
+{
+	struct mv_usb2_phy *mv_phy = container_of(phy, struct mv_usb2_phy, phy);
+
+	_mv_usb2_phy_shutdown(mv_phy);
+	clk_disable_unprepare(mv_phy->clk);
+}
+
+static int mv_usb2_phy_probe(struct platform_device *pdev)
+{
+	struct mv_usb2_phy *mv_phy;
+	struct resource *r;
+	const struct platform_device_id *id;
+
+	mv_phy = devm_kzalloc(&pdev->dev, sizeof(*mv_phy), GFP_KERNEL);
+	if (mv_phy == NULL) {
+		dev_err(&pdev->dev, "failed to allocate memory\n");
+		return -ENOMEM;
+	}
+
+	id = platform_get_device_id(pdev);
+
+	if (id == NULL) {
+		dev_err(&pdev->dev, "missing id_entry\n");
+		return -ENODEV;
+	}
+
+	mv_phy->type = (unsigned int)(id->driver_data);
+	mv_phy->clk = devm_clk_get(&pdev->dev, NULL);
+	if (IS_ERR(mv_phy->clk)) {
+		dev_err(&pdev->dev, "failed to get clock.\n");
+		return PTR_ERR(mv_phy->clk);
+	}
+	r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	if (r == NULL) {
+		dev_err(&pdev->dev, "no phy I/O memory resource defined\n");
+		return -ENODEV;
+	}
+	mv_phy->base = devm_ioremap_resource(&pdev->dev, r);
+	if (mv_phy->base == NULL) {
+		dev_err(&pdev->dev, "error map register base\n");
+		return -EBUSY;
+	}
+
+	mv_phy->phy.dev = &pdev->dev;
+	mv_phy->phy.label = "mv-usb2";
+	mv_phy->phy.type = USB_PHY_TYPE_USB2;
+	mv_phy->phy.init = mv_usb2_phy_init;
+	mv_phy->phy.shutdown = mv_usb2_phy_shutdown;
+
+	usb_add_phy_dev(&mv_phy->phy);
+
+	platform_set_drvdata(pdev, mv_phy);
+
+	return 0;
+}
+
+static int mv_usb2_phy_remove(struct platform_device *pdev)
+{
+	struct mv_usb2_phy *mv_phy = platform_get_drvdata(pdev);
+
+	usb_remove_phy(&mv_phy->phy);
+
+	platform_set_drvdata(pdev, NULL);
+
+	return 0;
+}
+
+static struct platform_device_id mv_usb2_phy_ids[] = {
+	{ .name = "pxa168-usb-phy",	.driver_data = PXA168_USB },
+	{ .name = "pxa910-usb-phy",	.driver_data = PXA910_USB },
+	{ .name = "mmp2-usb-phy",	.driver_data = MMP2_USB },
+	{}
+};
+
+static struct platform_driver mv_usb2_phy_driver = {
+	.probe	= mv_usb2_phy_probe,
+	.remove = mv_usb2_phy_remove,
+	.driver = {
+		.name   = "pxa168-usb-phy",
+	},
+	.id_table = mv_usb2_phy_ids,
+};
+
+module_platform_driver(mv_usb2_phy_driver);
+MODULE_ALIAS("platform: mv_usb2");
+MODULE_AUTHOR("Marvell Inc.");
+MODULE_DESCRIPTION("Marvell USB2 phy driver");
+MODULE_LICENSE("GPL v2");
diff --git a/include/linux/usb/mv_usb2.h b/include/linux/usb/mv_usb2.h
new file mode 100644
index 0000000..dfabd4e
--- /dev/null
+++ b/include/linux/usb/mv_usb2.h
@@ -0,0 +1,29 @@
+/*
+ * Copyright (C) 2013 Marvell Inc.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#ifndef __MV_USB2_H
+#define __MV_USB2_H
+
+#define MV_USB2_PHY_INDEX	0
+#define MV_USB2_OTG_PHY_INDEX	1
+
+struct mv_usb2_phy {
+	struct usb_phy		phy;
+	struct platform_device	*pdev;
+	unsigned int		type;
+	void __iomem		*base;
+	struct clk		*clk;
+};
+
+#endif
-- 
1.7.4.1



From chao.xie at marvell.com  Sun Apr  7 06:29:34 2013
From: chao.xie at marvell.com (Chao Xie)
Date: Sun, 7 Apr 2013 06:29:34 -0400
Subject: [V9 PATCH 00/12] mv-usb phy driver
Message-ID: <1365330586-649-1-git-send-email-chao.xie@marvell.com>

The patches create the mv-usb phy driver

The patches remove the callbacks in the platform data for phy
initialization and shutdown, and directly write a phy driver
and make udc/ehci/otg to call it.

  usb: phy: protect phy init and shutdown for mutiple deivces
  usb: phy: mv_usb2: add PHY driver for marvell usb2 controller
Above patches are marvell usb PHY driver support.

  usb: gadget: mv_udc: use PHY driver for udc
  usb: ehci: ehci-mv: use PHY driver for ehci
  usb: phy: phy-mv-usb: use USB2 PHY driver for otg
Above patches modify the udc/ehci/otg drivers to make use of PHY
driver.

  usb: mv_u3d: usb phy drivers for phy operation
Above patch is the fix for marvel usb3 gadget driver. It will make
use of PHY driver.

  arm: mmp2: change the defintion of usb devices
  arm: pxa910: change the defintion of usb devices
  arm: ttc_dkb: modify usb support
  arm: mmp: remove unused usb devices
  arm: brownstone: add usb support for the board
Above patches are the changes from SOCes.

  usb: mv_usb: remove the phy callbacks in pdata
Above patch finally remove the callbacks for PHY in pdata.

V2->V1:
  Change the Signed-off-by to be right email address

v3->v2
  re-format the patches to new code base

v4->v3
  1. make mv udc gadget driver depend on ARCH_PXA and ARCH_MMP
  2. remove __devinit and __devexit
  3. make the driver compiled successful if CONFIG_MV_USB2_PHY is not defined.
  The modified patches are
  usb: gadget: mv_udc: make mv_udc depends on ARCH_MMP or ARCH_PXA
  usb: phy: mv_usb2: add PHY driver for marvell usb2 controller

v5->v4
  make the struct mv_usb2_extern_chip member ->head to be
  struct atomic_notifier_head instead of struct atomic_notifier_head *.

v6->v5
  the bug fix patches are merged.
  Removed the dependcy of ARCH_MMP and ARCH_PXA, and make the driver can be
  compiled for x86.
  The device tree support patches need modification, remove them from this
  patch series, and they will be submitted in another series.


v7->v6
  Use usb_add_phy_dev and related APIs to add PHY drivers.
  Removed the device tree support in PHY driver. It will be added in another
  patch series.

v8->v7
  bugs fix in phy driver.
  directly use devm_usb_get_phy_dev return value for error return.

v9->v8
  Remove u2o_xxx.
  Add prefix for register definition
  Move mutex to common PHY layer
  Use module_platform_driver() to register driver
  Use usleep_range to replace udelay

Chao Xie (12):
  usb: phy: protect phy init and shutdown for mutiple deivces
  usb: phy: mv_usb2: add PHY driver for marvell usb2 controller
  usb: gadget: mv_udc: use PHY driver for udc
  usb: ehci: ehci-mv: use PHY driver for ehci
  usb: phy: phy-mv-usb: use USB2 PHY driver for otg
  usb: mv_u3d: usb phy drivers for phy operation
  arm: mmp2: change the defintion of usb devices
  arm: pxa910: change the defintion of usb devices
  arm: ttc_dkb: modify usb support
  arm: mmp: remove unused usb devices
  arm: brownstone: add usb support for the board
  usb: mv_usb: remove the phy callbacks in pdata

 arch/arm/mach-mmp/brownstone.c          |   56 +++++
 arch/arm/mach-mmp/include/mach/mmp2.h   |    4 +
 arch/arm/mach-mmp/include/mach/pxa910.h |    7 +-
 arch/arm/mach-mmp/mmp2.c                |    4 +
 arch/arm/mach-mmp/pxa910.c              |    4 +
 arch/arm/mach-mmp/ttc_dkb.c             |   39 +++-
 drivers/usb/gadget/mv_u3d.h             |    3 +-
 drivers/usb/gadget/mv_u3d_core.c        |   54 ++---
 drivers/usb/gadget/mv_udc.h             |    2 +-
 drivers/usb/gadget/mv_udc_core.c        |   50 ++---
 drivers/usb/host/ehci-mv.c              |   49 ++---
 drivers/usb/phy/Kconfig                 |    6 +
 drivers/usb/phy/Makefile                |    1 +
 drivers/usb/phy/phy-mv-usb.c            |   53 ++---
 drivers/usb/phy/phy-mv-usb.h            |    2 +-
 drivers/usb/phy/phy-mv-usb2.c           |  380 +++++++++++++++++++++++++++++++
 drivers/usb/phy/phy.c                   |    6 +
 include/linux/platform_data/mv_usb.h    |    3 -
 include/linux/usb/mv_usb2.h             |   29 +++
 include/linux/usb/phy.h                 |   22 ++-
 20 files changed, 624 insertions(+), 150 deletions(-)
 create mode 100644 drivers/usb/phy/phy-mv-usb2.c
 create mode 100644 include/linux/usb/mv_usb2.h

-- 
1.7.4.1



From chao.xie at marvell.com  Sun Apr  7 06:29:37 2013
From: chao.xie at marvell.com (Chao Xie)
Date: Sun, 7 Apr 2013 06:29:37 -0400
Subject: [V9 PATCH 03/12] usb: gadget: mv_udc: use PHY driver for udc
In-Reply-To: <1365330586-649-1-git-send-email-chao.xie@marvell.com>
References: <1365330586-649-1-git-send-email-chao.xie@marvell.com>
Message-ID: <1365330586-649-4-git-send-email-chao.xie@marvell.com>

Originaly, udc driver will call the callbacks in platform data
for PHY initialization and shut down.
With PHY driver, it will call the APIs provided by PHY driver
for PHY initialization and shut down. It removes the callbacks
in platform data, and at same time it removes one block in the
way of enabling device tree for udc driver.

Signed-off-by: Chao Xie <chao.xie at marvell.com>
---
 drivers/usb/gadget/mv_udc.h      |    2 +-
 drivers/usb/gadget/mv_udc_core.c |   50 +++++++++++++-------------------------
 2 files changed, 18 insertions(+), 34 deletions(-)

diff --git a/drivers/usb/gadget/mv_udc.h b/drivers/usb/gadget/mv_udc.h
index be77f20..02f36fe 100644
--- a/drivers/usb/gadget/mv_udc.h
+++ b/drivers/usb/gadget/mv_udc.h
@@ -180,7 +180,6 @@ struct mv_udc {
 
 	struct mv_cap_regs __iomem	*cap_regs;
 	struct mv_op_regs __iomem	*op_regs;
-	void __iomem                    *phy_regs;
 	unsigned int			max_eps;
 	struct mv_dqh			*ep_dqh;
 	size_t				ep_dqh_size;
@@ -217,6 +216,7 @@ struct mv_udc {
 	struct work_struct	vbus_work;
 	struct workqueue_struct *qwork;
 
+	struct usb_phy		*phy;
 	struct usb_phy		*transceiver;
 
 	struct mv_usb_platform_data     *pdata;
diff --git a/drivers/usb/gadget/mv_udc_core.c b/drivers/usb/gadget/mv_udc_core.c
index c2a5702..a6beef6 100644
--- a/drivers/usb/gadget/mv_udc_core.c
+++ b/drivers/usb/gadget/mv_udc_core.c
@@ -35,6 +35,7 @@
 #include <linux/platform_device.h>
 #include <linux/clk.h>
 #include <linux/platform_data/mv_usb.h>
+#include <linux/usb/mv_usb2.h>
 #include <asm/unaligned.h>
 
 #include "mv_udc.h"
@@ -1083,15 +1084,14 @@ static int mv_udc_enable_internal(struct mv_udc *udc)
 
 	dev_dbg(&udc->dev->dev, "enable udc\n");
 	udc_clock_enable(udc);
-	if (udc->pdata->phy_init) {
-		retval = udc->pdata->phy_init(udc->phy_regs);
-		if (retval) {
-			dev_err(&udc->dev->dev,
-				"init phy error %d\n", retval);
-			udc_clock_disable(udc);
-			return retval;
-		}
+	retval = usb_phy_init(udc->phy);
+	if (retval) {
+		dev_err(&udc->dev->dev,
+			"init phy error %d\n", retval);
+		udc_clock_disable(udc);
+		return retval;
 	}
+
 	udc->active = 1;
 
 	return 0;
@@ -1109,8 +1109,7 @@ static void mv_udc_disable_internal(struct mv_udc *udc)
 {
 	if (udc->active) {
 		dev_dbg(&udc->dev->dev, "disable udc\n");
-		if (udc->pdata->phy_deinit)
-			udc->pdata->phy_deinit(udc->phy_regs);
+		usb_phy_shutdown(udc->phy);
 		udc_clock_disable(udc);
 		udc->active = 0;
 	}
@@ -2124,17 +2123,10 @@ static int mv_udc_probe(struct platform_device *pdev)
 	udc->dev = pdev;
 
 	if (pdata->mode == MV_USB_MODE_OTG) {
-		udc->transceiver = devm_usb_get_phy(&pdev->dev,
-					USB_PHY_TYPE_USB2);
-		if (IS_ERR(udc->transceiver)) {
-			retval = PTR_ERR(udc->transceiver);
-
-			if (retval == -ENXIO)
-				return retval;
-
-			udc->transceiver = NULL;
-			return -EPROBE_DEFER;
-		}
+		udc->transceiver = devm_usb_get_phy_dev(&pdev->dev,
+					MV_USB2_OTG_PHY_INDEX);
+		if (IS_ERR_OR_NULL(udc->transceiver))
+			return PTR_ERR(udc->transceiver);
 	}
 
 	/* udc only have one sysclk. */
@@ -2142,7 +2134,7 @@ static int mv_udc_probe(struct platform_device *pdev)
 	if (IS_ERR(udc->clk))
 		return PTR_ERR(udc->clk);
 
-	r = platform_get_resource_byname(udc->dev, IORESOURCE_MEM, "capregs");
+	r = platform_get_resource(udc->dev, IORESOURCE_MEM, 0);
 	if (r == NULL) {
 		dev_err(&pdev->dev, "no I/O memory resource defined\n");
 		return -ENODEV;
@@ -2155,17 +2147,9 @@ static int mv_udc_probe(struct platform_device *pdev)
 		return -EBUSY;
 	}
 
-	r = platform_get_resource_byname(udc->dev, IORESOURCE_MEM, "phyregs");
-	if (r == NULL) {
-		dev_err(&pdev->dev, "no phy I/O memory resource defined\n");
-		return -ENODEV;
-	}
-
-	udc->phy_regs = ioremap(r->start, resource_size(r));
-	if (udc->phy_regs == NULL) {
-		dev_err(&pdev->dev, "failed to map phy I/O memory\n");
-		return -EBUSY;
-	}
+	udc->phy = devm_usb_get_phy_dev(&pdev->dev, MV_USB2_PHY_INDEX);
+	if (IS_ERR_OR_NULL(udc->phy))
+		return PTR_ERR(udc->phy);
 
 	/* we will acces controller register, so enable the clk */
 	retval = mv_udc_enable_internal(udc);
-- 
1.7.4.1



From chao.xie at marvell.com  Sun Apr  7 06:29:40 2013
From: chao.xie at marvell.com (Chao Xie)
Date: Sun, 7 Apr 2013 06:29:40 -0400
Subject: [V9 PATCH 06/12] usb: mv_u3d: usb phy drivers for phy operation
In-Reply-To: <1365330586-649-1-git-send-email-chao.xie@marvell.com>
References: <1365330586-649-1-git-send-email-chao.xie@marvell.com>
Message-ID: <1365330586-649-7-git-send-email-chao.xie@marvell.com>

The phy_init and phy_deinit APIs are removed from the pdata.
Directly get the phy driver and invoke the callbacks of phy
drivers for phy initialization and shutdown.

Signed-off-by: Chao Xie <chao.xie at marvell.com>
---
 drivers/usb/gadget/mv_u3d.h      |    3 +-
 drivers/usb/gadget/mv_u3d_core.c |   54 ++++++++++++++-----------------------
 2 files changed, 23 insertions(+), 34 deletions(-)

diff --git a/drivers/usb/gadget/mv_u3d.h b/drivers/usb/gadget/mv_u3d.h
index e32a787..0a0c7e3 100644
--- a/drivers/usb/gadget/mv_u3d.h
+++ b/drivers/usb/gadget/mv_u3d.h
@@ -251,7 +251,6 @@ struct mv_u3d {
 	struct mv_u3d_cap_regs __iomem	*cap_regs;
 	struct mv_u3d_op_regs __iomem	*op_regs;
 	struct mv_u3d_vuc_regs __iomem	*vuc_regs;
-	void __iomem			*phy_regs;
 
 	unsigned int			max_eps;
 	struct mv_u3d_ep_context	*ep_context;
@@ -283,6 +282,8 @@ struct mv_u3d {
 	struct mv_usb_addon_irq *vbus;
 	unsigned int		power;
 
+	struct usb_phy		*phy;
+
 	struct clk		*clk;
 };
 
diff --git a/drivers/usb/gadget/mv_u3d_core.c b/drivers/usb/gadget/mv_u3d_core.c
index 58288e9..bb92c5b 100644
--- a/drivers/usb/gadget/mv_u3d_core.c
+++ b/drivers/usb/gadget/mv_u3d_core.c
@@ -24,6 +24,7 @@
 #include <linux/device.h>
 #include <linux/usb/ch9.h>
 #include <linux/usb/gadget.h>
+#include <linux/usb/phy.h>
 #include <linux/pm.h>
 #include <linux/io.h>
 #include <linux/irq.h>
@@ -1109,7 +1110,6 @@ static int mv_u3d_controller_reset(struct mv_u3d *u3d)
 
 static int mv_u3d_enable(struct mv_u3d *u3d)
 {
-	struct mv_usb_platform_data *pdata = u3d->dev->platform_data;
 	int retval;
 
 	if (u3d->active)
@@ -1122,14 +1122,12 @@ static int mv_u3d_enable(struct mv_u3d *u3d)
 
 	dev_dbg(u3d->dev, "enable u3d\n");
 	clk_enable(u3d->clk);
-	if (pdata->phy_init) {
-		retval = pdata->phy_init(u3d->phy_regs);
-		if (retval) {
-			dev_err(u3d->dev,
-				"init phy error %d\n", retval);
-			clk_disable(u3d->clk);
-			return retval;
-		}
+	retval = usb_phy_init(u3d->phy);
+	if (retval) {
+		dev_err(u3d->dev,
+			"init phy error %d\n", retval);
+		clk_disable(u3d->clk);
+		return retval;
 	}
 	u3d->active = 1;
 
@@ -1138,11 +1136,9 @@ static int mv_u3d_enable(struct mv_u3d *u3d)
 
 static void mv_u3d_disable(struct mv_u3d *u3d)
 {
-	struct mv_usb_platform_data *pdata = u3d->dev->platform_data;
 	if (u3d->clock_gating && u3d->active) {
 		dev_dbg(u3d->dev, "disable u3d\n");
-		if (pdata->phy_deinit)
-			pdata->phy_deinit(u3d->phy_regs);
+		usb_phy_shutdown(u3d->phy);
 		clk_disable(u3d->clk);
 		u3d->active = 0;
 	}
@@ -1246,7 +1242,6 @@ static int mv_u3d_start(struct usb_gadget *g,
 		struct usb_gadget_driver *driver)
 {
 	struct mv_u3d *u3d = container_of(g, struct mv_u3d, gadget);
-	struct mv_usb_platform_data *pdata = u3d->dev->platform_data;
 	unsigned long flags;
 
 	if (u3d->driver)
@@ -1256,8 +1251,7 @@ static int mv_u3d_start(struct usb_gadget *g,
 
 	if (!u3d->clock_gating) {
 		clk_enable(u3d->clk);
-		if (pdata->phy_init)
-			pdata->phy_init(u3d->phy_regs);
+		usb_phy_init(u3d->phy);
 	}
 
 	/* hook up the driver ... */
@@ -1277,7 +1271,6 @@ static int mv_u3d_stop(struct usb_gadget *g,
 		struct usb_gadget_driver *driver)
 {
 	struct mv_u3d *u3d = container_of(g, struct mv_u3d, gadget);
-	struct mv_usb_platform_data *pdata = u3d->dev->platform_data;
 	unsigned long flags;
 
 	u3d->vbus_valid_detect = 0;
@@ -1285,8 +1278,7 @@ static int mv_u3d_stop(struct usb_gadget *g,
 
 	/* enable clock to access controller register */
 	clk_enable(u3d->clk);
-	if (pdata->phy_init)
-		pdata->phy_init(u3d->phy_regs);
+	usb_phy_init(u3d->phy);
 
 	mv_u3d_controller_stop(u3d);
 	/* stop all usb activities */
@@ -1294,8 +1286,7 @@ static int mv_u3d_stop(struct usb_gadget *g,
 	mv_u3d_stop_activity(u3d, driver);
 	mv_u3d_disable(u3d);
 
-	if (pdata->phy_deinit)
-		pdata->phy_deinit(u3d->phy_regs);
+	usb_phy_shutdown(u3d->phy);
 	clk_disable(u3d->clk);
 
 	spin_unlock_irqrestore(&u3d->lock, flags);
@@ -1827,7 +1818,7 @@ static int mv_u3d_probe(struct platform_device *dev)
 		goto err_get_clk;
 	}
 
-	r = platform_get_resource_byname(dev, IORESOURCE_MEM, "capregs");
+	r = platform_get_resource_byname(dev, IORESOURCE_MEM, 0);
 	if (!r) {
 		dev_err(&dev->dev, "no I/O memory resource defined\n");
 		retval = -ENODEV;
@@ -1846,15 +1837,14 @@ static int mv_u3d_probe(struct platform_device *dev)
 			(unsigned long) u3d->cap_regs);
 	}
 
-	/* we will access controller register, so enable the u3d controller */
-	clk_enable(u3d->clk);
+	u3d->phy = devm_usb_get_phy(&dev->dev, USB_PHY_TYPE_USB3);
+	if (IS_ERR_OR_NULL(u3d->phy))
+		goto err_u3d_enable;
 
-	if (pdata->phy_init) {
-		retval = pdata->phy_init(u3d->phy_regs);
-		if (retval) {
-			dev_err(&dev->dev, "init phy error %d\n", retval);
-			goto err_u3d_enable;
-		}
+	retval = usb_phy_init(u3d->phy);
+	if (retval) {
+		dev_err(&dev->dev, "init phy error %d\n", retval);
+		goto err_u3d_enable;
 	}
 
 	u3d->op_regs = (struct mv_u3d_op_regs __iomem *)(u3d->cap_regs
@@ -1872,8 +1862,7 @@ static int mv_u3d_probe(struct platform_device *dev)
 	mv_u3d_controller_stop(u3d);
 	iowrite32(0xFFFFFFFF, &u3d->vuc_regs->intrcause);
 
-	if (pdata->phy_deinit)
-		pdata->phy_deinit(u3d->phy_regs);
+	usb_phy_shutdown(u3d->phy);
 	clk_disable(u3d->clk);
 
 	size = u3d->max_eps * sizeof(struct mv_u3d_ep_context) * 2;
@@ -1988,8 +1977,7 @@ err_alloc_trb_pool:
 	dma_free_coherent(&dev->dev, u3d->ep_context_size,
 		u3d->ep_context, u3d->ep_context_dma);
 err_alloc_ep_context:
-	if (pdata->phy_deinit)
-		pdata->phy_deinit(u3d->phy_regs);
+	usb_phy_shutdown(u3d->phy);
 	clk_disable(u3d->clk);
 err_u3d_enable:
 	iounmap(u3d->cap_regs);
-- 
1.7.4.1



From chao.xie at marvell.com  Sun Apr  7 06:29:41 2013
From: chao.xie at marvell.com (Chao Xie)
Date: Sun, 7 Apr 2013 06:29:41 -0400
Subject: [V9 PATCH 07/12] arm: mmp2: change the defintion of usb devices
In-Reply-To: <1365330586-649-1-git-send-email-chao.xie@marvell.com>
References: <1365330586-649-1-git-send-email-chao.xie@marvell.com>
Message-ID: <1365330586-649-8-git-send-email-chao.xie@marvell.com>

add the udc/otg/ehci devices for mmp2

Signed-off-by: Chao Xie <chao.xie at marvell.com>
---
 arch/arm/mach-mmp/include/mach/mmp2.h |    4 ++++
 arch/arm/mach-mmp/mmp2.c              |    4 ++++
 2 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-mmp/include/mach/mmp2.h b/arch/arm/mach-mmp/include/mach/mmp2.h
index 0764f4e..95b6bd7 100644
--- a/arch/arm/mach-mmp/include/mach/mmp2.h
+++ b/arch/arm/mach-mmp/include/mach/mmp2.h
@@ -29,6 +29,10 @@ extern struct pxa_device_desc mmp2_device_sdh2;
 extern struct pxa_device_desc mmp2_device_sdh3;
 extern struct pxa_device_desc mmp2_device_asram;
 extern struct pxa_device_desc mmp2_device_isram;
+extern struct pxa_device_desc mmp2_device_u2o;
+extern struct pxa_device_desc mmp2_device_u2ootg;
+extern struct pxa_device_desc mmp2_device_u2oehci;
+extern struct pxa_device_desc mmp2_device_u2ophy;
 
 extern struct platform_device mmp2_device_gpio;
 
diff --git a/arch/arm/mach-mmp/mmp2.c b/arch/arm/mach-mmp/mmp2.c
index d94d114..e7b7642 100644
--- a/arch/arm/mach-mmp/mmp2.c
+++ b/arch/arm/mach-mmp/mmp2.c
@@ -149,6 +149,10 @@ MMP2_DEVICE(sdh3, "sdhci-pxav3", 3, MMC4, 0xd4281800, 0x120);
 MMP2_DEVICE(asram, "asram", -1, NONE, 0xe0000000, 0x4000);
 /* 0xd1000000 ~ 0xd101ffff is reserved for secure processor */
 MMP2_DEVICE(isram, "isram", -1, NONE, 0xd1020000, 0x18000);
+MMP2_DEVICE(u2ophy, "mmp2-usb-phy", -1, NONE, 0xd4207000, 0x1ff);
+MMP2_DEVICE(u2o, "mv-udc", -1, USB_OTG, 0xd4208100, 0x1ff);
+MMP2_DEVICE(u2ootg, "mv-otg", -1, USB_OTG, 0xd4208100, 0x1ff);
+MMP2_DEVICE(u2oehci, "mv-ehci", -1, USB_OTG, 0xd4208100, 0x1ff);
 
 struct resource mmp2_resource_gpio[] = {
 	{
-- 
1.7.4.1



From chao.xie at marvell.com  Sun Apr  7 06:29:38 2013
From: chao.xie at marvell.com (Chao Xie)
Date: Sun, 7 Apr 2013 06:29:38 -0400
Subject: [V9 PATCH 04/12] usb: ehci: ehci-mv: use PHY driver for ehci
In-Reply-To: <1365330586-649-1-git-send-email-chao.xie@marvell.com>
References: <1365330586-649-1-git-send-email-chao.xie@marvell.com>
Message-ID: <1365330586-649-5-git-send-email-chao.xie@marvell.com>

Originaly, ehci driver will call the callbacks in platform data
for PHY initialization and shut down.
With PHY driver, it will call the APIs provided by PHY driver
for PHY initialization and shut down. It removes the callbacks
in platform data, and at same time it removes one block in the
way of enabling device tree for ehci driver.

Signed-off-by: Chao Xie <chao.xie at marvell.com>
---
 drivers/usb/host/ehci-mv.c |   49 +++++++++++++++----------------------------
 1 files changed, 17 insertions(+), 32 deletions(-)

diff --git a/drivers/usb/host/ehci-mv.c b/drivers/usb/host/ehci-mv.c
index 6bad41a..adfc11f 100644
--- a/drivers/usb/host/ehci-mv.c
+++ b/drivers/usb/host/ehci-mv.c
@@ -15,17 +15,18 @@
 #include <linux/clk.h>
 #include <linux/err.h>
 #include <linux/usb/otg.h>
+#include <linux/usb/mv_usb2.h>
 #include <linux/platform_data/mv_usb.h>
 
 #define CAPLENGTH_MASK         (0xff)
 
 struct ehci_hcd_mv {
 	struct usb_hcd *hcd;
+	struct usb_phy *phy;
 
 	/* Which mode does this ehci running OTG/Host ? */
 	int mode;
 
-	void __iomem *phy_regs;
 	void __iomem *cap_regs;
 	void __iomem *op_regs;
 
@@ -48,22 +49,15 @@ static void ehci_clock_disable(struct ehci_hcd_mv *ehci_mv)
 
 static int mv_ehci_enable(struct ehci_hcd_mv *ehci_mv)
 {
-	int retval;
-
 	ehci_clock_enable(ehci_mv);
-	if (ehci_mv->pdata->phy_init) {
-		retval = ehci_mv->pdata->phy_init(ehci_mv->phy_regs);
-		if (retval)
-			return retval;
-	}
 
-	return 0;
+	return usb_phy_init(ehci_mv->phy);
 }
 
 static void mv_ehci_disable(struct ehci_hcd_mv *ehci_mv)
 {
-	if (ehci_mv->pdata->phy_deinit)
-		ehci_mv->pdata->phy_deinit(ehci_mv->phy_regs);
+	usb_phy_shutdown(ehci_mv->phy);
+
 	ehci_clock_disable(ehci_mv);
 }
 
@@ -169,22 +163,7 @@ static int mv_ehci_probe(struct platform_device *pdev)
 		goto err_clear_drvdata;
 	}
 
-	r = platform_get_resource_byname(pdev, IORESOURCE_MEM, "phyregs");
-	if (r == NULL) {
-		dev_err(&pdev->dev, "no phy I/O memory resource defined\n");
-		retval = -ENODEV;
-		goto err_clear_drvdata;
-	}
-
-	ehci_mv->phy_regs = devm_ioremap(&pdev->dev, r->start,
-					 resource_size(r));
-	if (ehci_mv->phy_regs == 0) {
-		dev_err(&pdev->dev, "failed to map phy I/O memory\n");
-		retval = -EFAULT;
-		goto err_clear_drvdata;
-	}
-
-	r = platform_get_resource_byname(pdev, IORESOURCE_MEM, "capregs");
+	r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 	if (!r) {
 		dev_err(&pdev->dev, "no I/O memory resource defined\n");
 		retval = -ENODEV;
@@ -199,6 +178,14 @@ static int mv_ehci_probe(struct platform_device *pdev)
 		goto err_clear_drvdata;
 	}
 
+	ehci_mv->phy = devm_usb_get_phy_dev(&pdev->dev, MV_USB2_PHY_INDEX);
+	if (IS_ERR_OR_NULL(ehci_mv->phy)) {
+		retval = PTR_ERR(ehci_mv->phy);
+		if (retval != -EPROBE_DEFER)
+			dev_err(&pdev->dev, "failed to get the outer phy\n");
+		goto err_clear_drvdata;
+	}
+
 	retval = mv_ehci_enable(ehci_mv);
 	if (retval) {
 		dev_err(&pdev->dev, "init phy error %d\n", retval);
@@ -225,14 +212,15 @@ static int mv_ehci_probe(struct platform_device *pdev)
 
 	ehci_mv->mode = pdata->mode;
 	if (ehci_mv->mode == MV_USB_MODE_OTG) {
-		ehci_mv->otg = devm_usb_get_phy(&pdev->dev, USB_PHY_TYPE_USB2);
+		ehci_mv->otg = devm_usb_get_phy_dev(&pdev->dev,
+						MV_USB2_OTG_PHY_INDEX);
 		if (IS_ERR(ehci_mv->otg)) {
 			retval = PTR_ERR(ehci_mv->otg);
 
 			if (retval == -ENXIO)
 				dev_info(&pdev->dev, "MV_USB_MODE_OTG "
 						"must have CONFIG_USB_PHY enabled\n");
-			else
+			else if (retval != -EPROBE_DEFER)
 				dev_err(&pdev->dev,
 						"unable to find transceiver\n");
 			goto err_disable_clk;
@@ -259,9 +247,6 @@ static int mv_ehci_probe(struct platform_device *pdev)
 		}
 	}
 
-	if (pdata->private_init)
-		pdata->private_init(ehci_mv->op_regs, ehci_mv->phy_regs);
-
 	dev_info(&pdev->dev,
 		 "successful find EHCI device with regs 0x%p irq %d"
 		 " working in %s mode\n", hcd->regs, hcd->irq,
-- 
1.7.4.1



From chao.xie at marvell.com  Sun Apr  7 06:29:42 2013
From: chao.xie at marvell.com (Chao Xie)
Date: Sun, 7 Apr 2013 06:29:42 -0400
Subject: [V9 PATCH 08/12] arm: pxa910: change the defintion of usb devices
In-Reply-To: <1365330586-649-1-git-send-email-chao.xie@marvell.com>
References: <1365330586-649-1-git-send-email-chao.xie@marvell.com>
Message-ID: <1365330586-649-9-git-send-email-chao.xie@marvell.com>

because phy is seperated from the usb controller driver,
we can use the common pxa_device_desc for device register.

Signed-off-by: Chao Xie <chao.xie at marvell.com>
---
 arch/arm/mach-mmp/include/mach/pxa910.h |    4 ++++
 arch/arm/mach-mmp/pxa910.c              |    4 ++++
 2 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-mmp/include/mach/pxa910.h b/arch/arm/mach-mmp/include/mach/pxa910.h
index b914afa..c695982 100644
--- a/arch/arm/mach-mmp/include/mach/pxa910.h
+++ b/arch/arm/mach-mmp/include/mach/pxa910.h
@@ -22,6 +22,10 @@ extern struct pxa_device_desc pxa910_device_nand;
 extern struct platform_device pxa168_device_u2o;
 extern struct platform_device pxa168_device_u2ootg;
 extern struct platform_device pxa168_device_u2oehci;
+extern struct pxa_device_desc pxa910_device_u2o;
+extern struct pxa_device_desc pxa910_device_u2ootg;
+extern struct pxa_device_desc pxa910_device_u2oehci;
+extern struct pxa_device_desc pxa910_device_u2ophy;
 extern struct pxa_device_desc pxa910_device_disp;
 extern struct pxa_device_desc pxa910_device_fb;
 extern struct pxa_device_desc pxa910_device_panel;
diff --git a/arch/arm/mach-mmp/pxa910.c b/arch/arm/mach-mmp/pxa910.c
index 36cb321..28fdce5 100644
--- a/arch/arm/mach-mmp/pxa910.c
+++ b/arch/arm/mach-mmp/pxa910.c
@@ -134,6 +134,10 @@ PXA910_DEVICE(pwm2, "pxa910-pwm", 1, NONE, 0xd401a400, 0x10);
 PXA910_DEVICE(pwm3, "pxa910-pwm", 2, NONE, 0xd401a800, 0x10);
 PXA910_DEVICE(pwm4, "pxa910-pwm", 3, NONE, 0xd401ac00, 0x10);
 PXA910_DEVICE(nand, "pxa3xx-nand", -1, NAND, 0xd4283000, 0x80, 97, 99);
+PXA910_DEVICE(u2ophy, "pxa910-usb-phy", -1, NONE, 0xd4207000, 0x1ff);
+PXA910_DEVICE(u2o, "mv-udc", -1, USB1, 0xd4208100, 0x1ff);
+PXA910_DEVICE(u2ootg, "mv-otg", -1, USB1, 0xd4208100, 0x1ff);
+PXA910_DEVICE(u2oehci, "mv-ehci", -1, USB1, 0xd4208100, 0x1ff);
 PXA910_DEVICE(disp, "mmp-disp", 0, LCD, 0xd420b000, 0x1ec);
 PXA910_DEVICE(fb, "mmp-fb", -1, NONE, 0, 0);
 PXA910_DEVICE(panel, "tpo-hvga", -1, NONE, 0, 0);
-- 
1.7.4.1



From ohad at wizery.com  Sun Apr  7 08:13:44 2013
From: ohad at wizery.com (Ohad Ben-Cohen)
Date: Sun, 7 Apr 2013 15:13:44 +0300
Subject: [PATCH v9 2/6] remoteproc: Change typo FW_CONFIG to FW_LOADER for
 REMOTEPROC
In-Reply-To: <1364521307-1219-3-git-send-email-rtivy@ti.com>
References: <1364521307-1219-1-git-send-email-rtivy@ti.com>
 <1364521307-1219-3-git-send-email-rtivy@ti.com>
Message-ID: <CAK=WgbbavgN0pDKvn7f1CrxYKUCpAhVYaEteg=1TVu75RoJuVA@mail.gmail.com>

On Fri, Mar 29, 2013 at 4:41 AM, Robert Tivy <rtivy at ti.com> wrote:
> Fix obvious typo introduced in commit e121aefa7d9f10eee5cf26ed47129237a05d940b
> ("remoteproc: fix missing CONFIG_FW_LOADER configurations").
>
> Signed-off-by: Robert Tivy <rtivy at ti.com>

Applied, thanks.

BTW - we don't usually want to directly cc stable at vger.kernel.org.
Instead we just add a Cc tag in the commit log (fixed before
applying).


From ohad at wizery.com  Sun Apr  7 08:39:41 2013
From: ohad at wizery.com (Ohad Ben-Cohen)
Date: Sun, 7 Apr 2013 15:39:41 +0300
Subject: [PATCH v9 3/6] remoteproc: Add support to rproc_alloc() for a
 default firmware name
In-Reply-To: <1364521307-1219-4-git-send-email-rtivy@ti.com>
References: <1364521307-1219-1-git-send-email-rtivy@ti.com>
 <1364521307-1219-4-git-send-email-rtivy@ti.com>
Message-ID: <CAK=WgbZ0dK8b=RRaXQTJ5rrJVDfKkM0=YPZLuG3mpNQt2P9spQ@mail.gmail.com>

On Fri, Mar 29, 2013 at 4:41 AM, Robert Tivy <rtivy at ti.com> wrote:
> Signed-off-by: Robert Tivy <rtivy at ti.com>

Applied with the following changes:
- add commit log
- document change in function description
- use snprintf instead
- minor style change

Thanks!


From ohad at wizery.com  Sun Apr  7 08:50:45 2013
From: ohad at wizery.com (Ohad Ben-Cohen)
Date: Sun, 7 Apr 2013 15:50:45 +0300
Subject: [PATCH v9 1/6] rpmsg: Process all available messages in virtqueue
 callback
In-Reply-To: <1364521307-1219-2-git-send-email-rtivy@ti.com>
References: <1364521307-1219-1-git-send-email-rtivy@ti.com>
 <1364521307-1219-2-git-send-email-rtivy@ti.com>
Message-ID: <CAK=WgbaCtACsvt9cqQmGqXsADFb_3bfnNKeWq9iijR2vkYVuQQ@mail.gmail.com>

On Fri, Mar 29, 2013 at 4:41 AM, Robert Tivy <rtivy at ti.com> wrote:
> Change virtqueue callback function rpmsg_recv_done() to process all
> available messages instead of just one message.
>
> Signed-off-by: Robert Tivy <rtivy at ti.com>

I'm thinking instead of adding an indentation level, let's split the
_recv function.

This is what I have in mind - let me know if it works for you - thanks:

diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c b/drivers/rpmsg/virtio_rpmsg_bus.c
index a59684b..42b9872 100644
--- a/drivers/rpmsg/virtio_rpmsg_bus.c
+++ b/drivers/rpmsg/virtio_rpmsg_bus.c
@@ -776,22 +776,11 @@ out:
 }
 EXPORT_SYMBOL(rpmsg_send_offchannel_raw);

-/* called when an rx buffer is used, and it's time to digest a message */
-static void rpmsg_recv_done(struct virtqueue *rvq)
+static int rpmsg_recv_single(struct virtproc_info *vrp, struct device *dev,
+                            struct rpmsg_hdr *msg, unsigned int len)
 {
-       struct rpmsg_hdr *msg;
-       unsigned int len;
        struct rpmsg_endpoint *ept;
        struct scatterlist sg;
-       struct virtproc_info *vrp = rvq->vdev->priv;
-       struct device *dev = &rvq->vdev->dev;
-       int err;
-
-       msg = virtqueue_get_buf(rvq, &len);
-       if (!msg) {
-               dev_err(dev, "uhm, incoming signal, but no used buffer ?\n");
-               return;
-       }

        dev_dbg(dev, "From: 0x%x, To: 0x%x, Len: %d, Flags: %d, Reserved: %d\n",
                                        msg->src, msg->dst, msg->len,
@@ -806,7 +795,7 @@ static void rpmsg_recv_done(struct virtqueue *rvq)
        if (len > RPMSG_BUF_SIZE ||
                msg->len > (len - sizeof(struct rpmsg_hdr))) {
                dev_warn(dev, "inbound msg too big: (%d, %d)\n", len, msg->len);
-               return;
+               return -EINVAL;
        }

        /* use the dst addr to fetch the callback of the appropriate user */
@@ -842,9 +831,39 @@ static void rpmsg_recv_done(struct virtqueue *rvq)
        err = virtqueue_add_buf(vrp->rvq, &sg, 0, 1, msg, GFP_KERNEL);
        if (err < 0) {
                dev_err(dev, "failed to add a virtqueue buffer: %d\n", err);
+               return err;
+       }
+
+       return 0;
+}
+
+/* called when an rx buffer is used, and it's time to digest a message */
+static void rpmsg_recv_done(struct virtqueue *rvq)
+{
+       struct virtproc_info *vrp = rvq->vdev->priv;
+       struct device *dev = &rvq->vdev->dev;
+       struct rpmsg_hdr *msg;
+       unsigned int len, msgs_received = 0;
+       int err;
+
+       msg = virtqueue_get_buf(rvq, &len);
+       if (!msg) {
+               dev_err(dev, "uhm, incoming signal, but no used buffer ?\n");
                return;
        }

+       while (msg) {
+               err = rpmsg_recv_single(vrp, dev, msg, len);
+               if (err)
+                       break;
+
+               msgs_received++;
+
+               msg = virtqueue_get_buf(rvq, &len);
+       };
+
+       dev_dbg(dev, "Received %u messages\n", msgs_received);
+
        /* tell the remote processor we added another available rx buffer */
        virtqueue_kick(vrp->rvq);
 }


From ohad at wizery.com  Sun Apr  7 09:02:43 2013
From: ohad at wizery.com (Ohad Ben-Cohen)
Date: Sun, 7 Apr 2013 16:02:43 +0300
Subject: [PATCH v9 4/6] ARM: davinci: Add a remoteproc driver
 implementation for OMAP-L13x DSP
In-Reply-To: <1364521307-1219-5-git-send-email-rtivy@ti.com>
References: <1364521307-1219-1-git-send-email-rtivy@ti.com>
 <1364521307-1219-5-git-send-email-rtivy@ti.com>
Message-ID: <CAK=WgbZme2UkMeP-JB2h3xnmcpzAaYeOcy7gxh60muJ8KZbr_A@mail.gmail.com>

Hi Rob,

On Fri, Mar 29, 2013 at 4:41 AM, Robert Tivy <rtivy at ti.com> wrote:> +
> +static int da8xx_rproc_probe(struct platform_device *pdev)
> +{
> +       struct device *dev = &pdev->dev;
> +       struct da8xx_rproc *drproc;
> +       struct rproc *rproc;
> +       struct irq_data *irq_data;
> +       struct resource *bootreg_res;
> +       struct resource *chipsig_res;
> +       struct clk *dsp_clk;
> +       void __iomem *chipsig;
> +       void __iomem *bootreg;
> +       int irq;
> +       int ret;
> +
> +       irq = platform_get_irq(pdev, 0);
> +       if (irq < 0) {
> +               dev_err(dev, "platform_get_irq(pdev, 0) error: %d\n", irq);
> +               return irq;
> +       }
> +
> +       irq_data = irq_get_irq_data(irq);
> +       if (!irq_data) {
> +               dev_err(dev, "irq_get_irq_data(%d): NULL\n", irq);
> +               return -EINVAL;
> +       }
> +
> +       bootreg_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +       if (!bootreg_res) {
> +               dev_err(dev,
> +                       "platform_get_resource(IORESOURCE_MEM, 0): NULL\n");
> +               return -EADDRNOTAVAIL;
> +       }
> +
> +       chipsig_res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> +       if (!chipsig_res) {
> +               dev_err(dev,
> +                       "platform_get_resource(IORESOURCE_MEM, 1): NULL\n");
> +               return -EADDRNOTAVAIL;
> +       }
> +
> +       bootreg = devm_request_and_ioremap(dev, bootreg_res);
> +       if (!bootreg) {
> +               dev_err(dev, "unable to map boot register\n");
> +               return -EADDRNOTAVAIL;
> +       }
> +
> +       chipsig = devm_request_and_ioremap(dev, chipsig_res);
> +       if (!chipsig) {
> +               dev_err(dev, "unable to map CHIPSIG register\n");
> +               return -EADDRNOTAVAIL;
> +       }
> +
> +       dsp_clk = devm_clk_get(dev, NULL);
> +       if (IS_ERR(dsp_clk)) {
> +               dev_err(dev, "clk_get error: %ld\n", PTR_ERR(dsp_clk));
> +
> +               return PTR_RET(dsp_clk);
> +       }
> +
> +       rproc = rproc_alloc(dev, "dsp", &da8xx_rproc_ops, da8xx_fw_name,
> +               sizeof(*drproc));
> +       if (!rproc)
> +               return -ENOMEM;
> +
> +       drproc = rproc->priv;
> +       drproc->rproc = rproc;
> +
> +       platform_set_drvdata(pdev, rproc);
> +
> +       /* everything the ISR needs is now setup, so hook it up */
> +       ret = devm_request_threaded_irq(dev, irq, da8xx_rproc_callback,
> +               handle_event, 0, "da8xx-remoteproc", rproc);
> +       if (ret) {
> +               dev_err(dev, "devm_request_threaded_irq error: %d\n", ret);
> +               goto free_rproc;
> +       }
> +
> +       /*
> +        * rproc_add() can end up enabling the DSP's clk with the DSP
> +        * *not* in reset, but da8xx_rproc_start() needs the DSP to be
> +        * held in reset at the time it is called.
> +        */
> +       ret = reset_assert(dev);
> +       if (ret)
> +               goto free_rproc;
> +
> +       ret = rproc_add(rproc);
> +       if (ret) {
> +               dev_err(dev, "rproc_add failed: %d\n", ret);
> +               goto free_rproc;
> +       }
> +
> +       drproc->chipsig = chipsig;
> +       drproc->bootreg = bootreg;
> +       drproc->ack_fxn = irq_data->chip->irq_ack;
> +       drproc->irq_data = irq_data;
> +       drproc->irq = irq;
> +       drproc->dsp_clk = dsp_clk;
> +
> +       return 0;
> +
> +free_rproc:
> +       rproc_put(rproc);
> +
> +       return ret;
> +}

Two small changes please:

- could you please fix the error path of probe? it seems that some
resources are taken but not freed in case a failure shows up
subsequently
- seems like it's safer to set drproc before calling rproc_add
otherwise you have a small race there

If you could respin this one quickly it'd be great, thanks!

Ohad.


From ohad at wizery.com  Sun Apr  7 09:07:44 2013
From: ohad at wizery.com (Ohad Ben-Cohen)
Date: Sun, 7 Apr 2013 16:07:44 +0300
Subject: [PATCH v9 0/6] ARM: davinci: remoteproc support
In-Reply-To: <1364521307-1219-1-git-send-email-rtivy@ti.com>
References: <1364521307-1219-1-git-send-email-rtivy@ti.com>
Message-ID: <CAK=WgbYW4=1GyBGOHyR1vFaPHjhGdAP493+Jh4mSQSOeX7uJjw@mail.gmail.com>

Hi Rob,

On Fri, Mar 29, 2013 at 4:41 AM, Robert Tivy <rtivy at ti.com> wrote:
> This patch series adds remoteproc support for OMAP-L13x, along with needed
> supporting mach-davinci infrastructure.

Patches look good, thanks for pushing.

I'm applying 2 and 3 now. Please ack the change I've done for 1 and
I'll apply it too. No. 4 just needs a small change, if you could
please respin quickly I'll apply it immediately.

I prefer patches 5 and 6 go through Sekhar, guess after I'll have no.
4 applied in an immutable branch Sekhar could pull it and apply 5 and
6.

Thanks,
Ohad.


From s.hauer at pengutronix.de  Sun Apr  7 09:26:23 2013
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Sun, 7 Apr 2013 15:26:23 +0200
Subject: [RFC PATCH] CLK: Allow parent clock and rate to be configured in
 DT.
In-Reply-To: <6581638.FPkNsv6peb@flatron>
References: <20130319170933.28337.50448.stgit@localhost>
 <CAOMZO5ASkvquyzPCEGObvB5Xh9bDPTJ2zx26eOUJT_Vb36Bn3Q@mail.gmail.com>
 <CAKGA1bkWLrOs15ni=8D__BvuG6kvqkeeLZGOLrVZY9g0q0z4Bg@mail.gmail.com>
 <6581638.FPkNsv6peb@flatron>
Message-ID: <20130407132623.GP1906@pengutronix.de>

On Sat, Apr 06, 2013 at 03:21:19PM +0200, Tomasz Figa wrote:
> Hi,
> 
> [RANT]
> 
> I tend to disagree about this whole hype about device tree usage for other 
> things than pure hardware description. I don't think device tree should be  
> a way to force some kind of new world order, but rather a more convenient 
> and more maintainable (than board files) way of support hardware platforms 
> in Linux kernel.

Honestly I'm annoyed by this aswell. The devicetree contains a nice and
complete hardware description and it seems convenient to put hardware
related configuration data there aswell.

The problem is that hardware description and configuration data are two
completely different sets of data. The hardware description is static
for a given board and should (ideally) never change. The configuration
data instead is often usecase specific and changes over the lifetime of
a board. The configuration data can only handle a single (or maybe a
table of) static setup(s). It's a good way to specify a sane default or
a very special setup, but doesn't handle the case when some OS (or
version thereof) wants to have a static setup and another wants to
figure out the same data dynamically.

For these reasons I am against throwing the two data sets into a single
pot. Still I also want to have the devicetree way to configure some
static setup items.

People are already working on devicetree overlays.  Maybe it would be
possible to have some kind of configuration overlay for the devicetree.
This would make it possible to store the data in different places and to
exchange the configuration data while keeping the hardware description.
Also board designers could describe the hardware and give one or more
usage hints without forcing anybody to actually use them.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From festevam at gmail.com  Sun Apr  7 09:53:33 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Sun, 7 Apr 2013 10:53:33 -0300
Subject: [PATCH v2 0/3] Get rid of big array from imx pinctrl driver
In-Reply-To: <20130407071028.GD11898@S2101-09.ap.freescale.net>
References: <1361533888-18073-1-git-send-email-shawn.guo@linaro.org>
 <CAOMZO5D1+baoM0vMdPW9bAd4DX8C82BF9H87igFNo78+8D_N3Q@mail.gmail.com>
 <20130407071028.GD11898@S2101-09.ap.freescale.net>
Message-ID: <CAOMZO5Bxfj9ZGrVOcNirsVHFLWaHWBdkFpKSiVQ9iS4paT0Y6g@mail.gmail.com>

On Sun, Apr 7, 2013 at 4:10 AM, Shawn Guo <shawn.guo at linaro.org> wrote:

> Thanks for spotting it, Fabio.
>
> There is indeed a bug with the patch.  The select input register should
> not be defined in imx_pin_reg, because the same pad may have multiple
> select input registers for different mux setting values.  So it should
> be something defined with pin group.  The following code change should
> fix the problem.
>
> I just rebuilt imx/dt branch with the problem fixed and also had the
> branch based on Stephen Warren's for-3.10/dtc-cpp-chroot-std-headers
> branch so avoid all those dts files renaming.

With this change the audmux input registers are set and I can get
audio functional again.

I still see a different issue though:

In 3.6-rc5 we get:

imx6q-pinctrl 20e0000.iomuxc: maps: function i2c1 group i2c1grp-1 num 3
imx6q-pinctrl 20e0000.iomuxc: enable function i2c1 group i2c1grp-1
imx6q-pinctrl 20e0000.iomuxc: write: offset 0xa4 val 0x16
imx6q-pinctrl 20e0000.iomuxc: ==>select_input: offset 0x898 val 0x0
imx6q-pinctrl 20e0000.iomuxc: write: offset 0xc4 val 0x11
imx6q-pinctrl 20e0000.iomuxc: ==>select_input: offset 0x89c val 0x0
imx6q-pinctrl 20e0000.iomuxc: pinconf set pin MX6Q_PAD_EIM_D21
imx6q-pinctrl 20e0000.iomuxc: write: offset 0x3b8 val 0x1b8b1
imx6q-pinctrl 20e0000.iomuxc: pinconf set pin MX6Q_PAD_EIM_D28
imx6q-pinctrl 20e0000.iomuxc: write: offset 0x3d8 val 0x1b8b1

,but we get the following on your branch:

imx6q-pinctrl 20e0000.iomuxc: maps: function i2c1 group i2c1grp-1 num 3
imx6q-pinctrl 20e0000.iomuxc: enable function i2c1 group i2c1grp-1
imx6q-pinctrl 20e0000.iomuxc: write: offset 0xa4 val 0x16
imx6q-pinctrl 20e0000.iomuxc: ==>select_input: offset 0x898 val 0x0
imx6q-pinctrl 20e0000.iomuxc: write: offset 0xc4 val 0x11
imx6q-pinctrl 20e0000.iomuxc: ==>select_input: offset 0x89c val 0x0
imx6q-pinctrl 20e0000.iomuxc: pinconf set pin MX6Q_PAD_EIM_A17
imx6q-pinctrl 20e0000.iomuxc: write: offset 0x3b8 val 0x1b8b1
imx6q-pinctrl 20e0000.iomuxc: pinconf set pin MX6Q_PAD_EIM_EB1
imx6q-pinctrl 20e0000.iomuxc: write: offset 0x3d8 val 0x1b8b1

The pin name passed in the 'pinconf set pin' line is wrong.

On 3.6-rc5 MX6Q_PAD_EIM_D21 is number 22 and MX6Q_PAD_EIM_A17 is 41.

On your branch: MX6Q_PAD_EIM_D21 is 41 and MX6Q_PAD_EIM_A17 is 60

So this offset of 19 is causing troubles and I can see that you added
this offset  in the enum:

enum imx6q_pads {
	MX6Q_PAD_SD2_DAT1 = 19,
	MX6Q_PAD_SD2_DAT2 = 20,
	MX6Q_PAD_SD2_DAT0 = 21,
	MX6Q_PAD_RGMII_TXC = 22,
	MX6Q_PAD_RGMII_TD0 = 23,
	MX6Q_PAD_RGMII_TD1 = 24,
	MX6Q_PAD_RGMII_TD2 = 25,


From shawn.guo at linaro.org  Sun Apr  7 10:26:12 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Sun, 7 Apr 2013 22:26:12 +0800
Subject: [PATCH v2 0/3] Get rid of big array from imx pinctrl driver
In-Reply-To: <CAOMZO5Bxfj9ZGrVOcNirsVHFLWaHWBdkFpKSiVQ9iS4paT0Y6g@mail.gmail.com>
References: <1361533888-18073-1-git-send-email-shawn.guo@linaro.org>
 <CAOMZO5D1+baoM0vMdPW9bAd4DX8C82BF9H87igFNo78+8D_N3Q@mail.gmail.com>
 <20130407071028.GD11898@S2101-09.ap.freescale.net>
 <CAOMZO5Bxfj9ZGrVOcNirsVHFLWaHWBdkFpKSiVQ9iS4paT0Y6g@mail.gmail.com>
Message-ID: <20130407142610.GE11898@S2101-09.ap.freescale.net>

On Sun, Apr 07, 2013 at 10:53:33AM -0300, Fabio Estevam wrote:
> On Sun, Apr 7, 2013 at 4:10 AM, Shawn Guo <shawn.guo at linaro.org> wrote:
> 
> > Thanks for spotting it, Fabio.
> >
> > There is indeed a bug with the patch.  The select input register should
> > not be defined in imx_pin_reg, because the same pad may have multiple
> > select input registers for different mux setting values.  So it should
> > be something defined with pin group.  The following code change should
> > fix the problem.
> >
> > I just rebuilt imx/dt branch with the problem fixed and also had the
> > branch based on Stephen Warren's for-3.10/dtc-cpp-chroot-std-headers
> > branch so avoid all those dts files renaming.
> 
> With this change the audmux input registers are set and I can get
> audio functional again.
> 
> I still see a different issue though:
> 
That's expected, as the pin ID gets re-numbered based on offset of
mux/conf register, so that we can determine the pin ID at runtime and
avoid encoding it in device tree.

Shawn

> In 3.6-rc5 we get:
> 
> imx6q-pinctrl 20e0000.iomuxc: maps: function i2c1 group i2c1grp-1 num 3
> imx6q-pinctrl 20e0000.iomuxc: enable function i2c1 group i2c1grp-1
> imx6q-pinctrl 20e0000.iomuxc: write: offset 0xa4 val 0x16
> imx6q-pinctrl 20e0000.iomuxc: ==>select_input: offset 0x898 val 0x0
> imx6q-pinctrl 20e0000.iomuxc: write: offset 0xc4 val 0x11
> imx6q-pinctrl 20e0000.iomuxc: ==>select_input: offset 0x89c val 0x0
> imx6q-pinctrl 20e0000.iomuxc: pinconf set pin MX6Q_PAD_EIM_D21
> imx6q-pinctrl 20e0000.iomuxc: write: offset 0x3b8 val 0x1b8b1
> imx6q-pinctrl 20e0000.iomuxc: pinconf set pin MX6Q_PAD_EIM_D28
> imx6q-pinctrl 20e0000.iomuxc: write: offset 0x3d8 val 0x1b8b1
> 
> ,but we get the following on your branch:
> 
> imx6q-pinctrl 20e0000.iomuxc: maps: function i2c1 group i2c1grp-1 num 3
> imx6q-pinctrl 20e0000.iomuxc: enable function i2c1 group i2c1grp-1
> imx6q-pinctrl 20e0000.iomuxc: write: offset 0xa4 val 0x16
> imx6q-pinctrl 20e0000.iomuxc: ==>select_input: offset 0x898 val 0x0
> imx6q-pinctrl 20e0000.iomuxc: write: offset 0xc4 val 0x11
> imx6q-pinctrl 20e0000.iomuxc: ==>select_input: offset 0x89c val 0x0
> imx6q-pinctrl 20e0000.iomuxc: pinconf set pin MX6Q_PAD_EIM_A17
> imx6q-pinctrl 20e0000.iomuxc: write: offset 0x3b8 val 0x1b8b1
> imx6q-pinctrl 20e0000.iomuxc: pinconf set pin MX6Q_PAD_EIM_EB1
> imx6q-pinctrl 20e0000.iomuxc: write: offset 0x3d8 val 0x1b8b1
> 
> The pin name passed in the 'pinconf set pin' line is wrong.
> 
> On 3.6-rc5 MX6Q_PAD_EIM_D21 is number 22 and MX6Q_PAD_EIM_A17 is 41.
> 
> On your branch: MX6Q_PAD_EIM_D21 is 41 and MX6Q_PAD_EIM_A17 is 60
> 
> So this offset of 19 is causing troubles and I can see that you added
> this offset  in the enum:
> 
> enum imx6q_pads {
> 	MX6Q_PAD_SD2_DAT1 = 19,
> 	MX6Q_PAD_SD2_DAT2 = 20,
> 	MX6Q_PAD_SD2_DAT0 = 21,
> 	MX6Q_PAD_RGMII_TXC = 22,
> 	MX6Q_PAD_RGMII_TD0 = 23,
> 	MX6Q_PAD_RGMII_TD1 = 24,
> 	MX6Q_PAD_RGMII_TD2 = 25,



From festevam at gmail.com  Sun Apr  7 10:32:45 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Sun, 7 Apr 2013 11:32:45 -0300
Subject: [PATCH v2 0/3] Get rid of big array from imx pinctrl driver
In-Reply-To: <20130407142610.GE11898@S2101-09.ap.freescale.net>
References: <1361533888-18073-1-git-send-email-shawn.guo@linaro.org>
 <CAOMZO5D1+baoM0vMdPW9bAd4DX8C82BF9H87igFNo78+8D_N3Q@mail.gmail.com>
 <20130407071028.GD11898@S2101-09.ap.freescale.net>
 <CAOMZO5Bxfj9ZGrVOcNirsVHFLWaHWBdkFpKSiVQ9iS4paT0Y6g@mail.gmail.com>
 <20130407142610.GE11898@S2101-09.ap.freescale.net>
Message-ID: <CAOMZO5A-nwmb=6G-D_2LBNsPYH4C8Z686BjS3vd3WhzvnDFfqw@mail.gmail.com>

On Sun, Apr 7, 2013 at 11:26 AM, Shawn Guo <shawn.guo at linaro.org> wrote:

> That's expected, as the pin ID gets re-numbered based on offset of
> mux/conf register, so that we can determine the pin ID at runtime and
> avoid encoding it in device tree.

but debug messages seems buggy now:

Prior to the patch we had:

imx6q-pinctrl 20e0000.iomuxc: pinconf set pin MX6Q_PAD_EIM_D21

and now we have:

imx6q-pinctrl 20e0000.iomuxc: pinconf set pin MX6Q_PAD_EIM_A17

MX6Q_PAD_EIM_A17 has nothing to do with I2C, so we should print
MX6Q_PAD_EIM_A17 when we are actually configuring MX6Q_PAD_EIM_D21.

Also, where does the 19 offset in the  imx6q_pads enum come from?


From arnd at arndb.de  Sun Apr  7 10:32:55 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Sun, 7 Apr 2013 16:32:55 +0200
Subject: [RFC PATCH arm: initial TI-Nspire support]
In-Reply-To: <4B3FD561-84FC-40CD-B747-13851692D673@gmail.com>
References: <6FE4B33E-A503-4A75-AEED-831CB2C06D83@gmail.com>
 <201304061524.56502.arnd@arndb.de>
 <4B3FD561-84FC-40CD-B747-13851692D673@gmail.com>
Message-ID: <201304071632.55922.arnd@arndb.de>

On Sunday 07 April 2013, Daniel Tang wrote:
> On 07/04/2013, at 12:24 AM, Arnd Bergmann <arnd at arndb.de> wrote:
> > 
> >> @@ -313,7 +314,7 @@ define archhelp
> >>   echo  '  Image         - Uncompressed kernel image (arch/$(ARCH)/boot/Image)'
> >>   echo  '* xipImage      - XIP kernel image, if configured (arch/$(ARCH)/boot/xipImage)'
> >>   echo  '  uImage        - U-Boot wrapped zImage'
> >> -  echo  '  bootpImage    - Combined zImage and initial RAM disk' 
> >> +  echo  '  bootpImage    - Combined zImage and initial RAM disk'
> >>   echo  '                  (supply initrd image via make variable INITRD=<path>)'
> >>   echo  '* dtbs          - Build device tree blobs for enabled boards'
> >>   echo  '  install       - Install uncompressed kernel'
> > 
> > This looks like it wasn't meant to be in the patch.
> 
> It probably isn't. I think there was trailing whitespace on that and my editor happened to remove it automatically.
> 
> Should this be a separate patch to fix up formatting or should I leave it in as a drive-by fix?

Any cleanups like this should be separate patches, and ideally even
part of a different patch series.

> > 
> >> +			uart: uart at 90020000 {
> >> +				reg = <0x90020000 0x1000>;
> >> +				interrupts = <1>;
> >> +
> >> +				clocks = <&uart_clk>;
> >> +				clock-names = "uart_clk";
> >> +			};
> > 
> > The name for a uart should be "serial". Since this is a pl01x, please add
> > the required properties for the device, e.g. 
> > 
> > 	compatible = "arm,pl011", "arm,primecell";
> > 
> > You will need the "arm,primecell" bit to make the device appear on the
> > amba bus rather than the platform bus.
> 
> That was actually deliberate because different models of the TI-NSPIRE have different
> serial hardware. On the newer CX models, it is a PL01x and on the older models, it has
> a 8250-like interface. They all reside at the same address with the same IRQ though.
> 
> I thought it might be cleaner to specify the interrupts and registers in the common file
> and leave it to the board specific ones to implement the "compatible" property.

I see. It seems a little confusing to the reader though. I don't have a good answer,
but there are two other options how this can be handled:

* Put both devices in the devicetree and mark them as status="disabled" in the main file,
but enable one of them in the version specific files.

* leave them out of the .dtsi file and only define them in the specific .dts files.
> >> +	err = of_property_read_string(of_aliases, "timer0", &path);
> >> +	if (WARN_ON(err))
> >> +		return;
> >> +
> >> +	timer = of_find_node_by_path(path);
> >> +	base = of_iomap(timer, 0);
> >> +	if (WARN_ON(!base))
> >> +		return;
> >> +
> >> +	clk = of_clk_get_by_name(timer, NULL);
> >> +	clk_register_clkdev(clk, timer->name, "sp804");
> >> +
> >> +	sp804_clocksource_init(base, timer->name);
> >> +
> >> +	err = of_property_read_string(of_aliases, "timer1", &path);
> >> +	if (WARN_ON(err))
> >> +		return;
> > 
> > In particular, I think the method of using aliases to pick the right sp804
> > instance is being deprecated now. If both timers are identical, the kernel
> > will now just pick one of them.
> 
> Sorry, I don't quite understand. 
> 
> Out of the timers, I want to add one as a clocksource and one as a clockevent.
> If they're identical (i.e. without using aliases), how should I tell the kernel,
> "Take the first timer you see and make it a clocksource, take the next one you
> see and make it a clockevent"?

The modified sp804 driver will have logic to do that. I think in the end we
decided that the driver should first look for any device that can be used as
a clocksource and use it that way. If it finds a second device, that can be
used as clockevent.

	Arnd


From festevam at gmail.com  Sun Apr  7 10:33:34 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Sun, 7 Apr 2013 11:33:34 -0300
Subject: [PATCH v2 0/3] Get rid of big array from imx pinctrl driver
In-Reply-To: <CAOMZO5A-nwmb=6G-D_2LBNsPYH4C8Z686BjS3vd3WhzvnDFfqw@mail.gmail.com>
References: <1361533888-18073-1-git-send-email-shawn.guo@linaro.org>
 <CAOMZO5D1+baoM0vMdPW9bAd4DX8C82BF9H87igFNo78+8D_N3Q@mail.gmail.com>
 <20130407071028.GD11898@S2101-09.ap.freescale.net>
 <CAOMZO5Bxfj9ZGrVOcNirsVHFLWaHWBdkFpKSiVQ9iS4paT0Y6g@mail.gmail.com>
 <20130407142610.GE11898@S2101-09.ap.freescale.net>
 <CAOMZO5A-nwmb=6G-D_2LBNsPYH4C8Z686BjS3vd3WhzvnDFfqw@mail.gmail.com>
Message-ID: <CAOMZO5BCAPuEmV=3xNdEf-VM-RFneBmpato7+sGOhfVaj32pMA@mail.gmail.com>

On Sun, Apr 7, 2013 at 11:32 AM, Fabio Estevam <festevam at gmail.com> wrote:
> On Sun, Apr 7, 2013 at 11:26 AM, Shawn Guo <shawn.guo at linaro.org> wrote:
>
>> That's expected, as the pin ID gets re-numbered based on offset of
>> mux/conf register, so that we can determine the pin ID at runtime and
>> avoid encoding it in device tree.
>
> but debug messages seems buggy now:
>
> Prior to the patch we had:
>
> imx6q-pinctrl 20e0000.iomuxc: pinconf set pin MX6Q_PAD_EIM_D21
>
> and now we have:
>
> imx6q-pinctrl 20e0000.iomuxc: pinconf set pin MX6Q_PAD_EIM_A17
>
> MX6Q_PAD_EIM_A17 has nothing to do with I2C, so we should print
/s/should/should not/

> MX6Q_PAD_EIM_A17 when we are actually configuring MX6Q_PAD_EIM_D21.
>
> Also, where does the 19 offset in the  imx6q_pads enum come from?


From jhovold at gmail.com  Sun Apr  7 10:49:59 2013
From: jhovold at gmail.com (Johan Hovold)
Date: Sun,  7 Apr 2013 16:49:59 +0200
Subject: [PATCH 2/2] ARM: at91: remove trailing semicolon from macros
In-Reply-To: <1365346199-29525-1-git-send-email-jhovold@gmail.com>
References: <1365346199-29525-1-git-send-email-jhovold@gmail.com>
Message-ID: <1365346199-29525-2-git-send-email-jhovold@gmail.com>

Remove trailing semicolon from register-access macros.

Signed-off-by: Johan Hovold <jhovold at gmail.com>
---
 arch/arm/mach-at91/at91_rstc.h                | 2 +-
 arch/arm/mach-at91/at91_shdwc.h               | 2 +-
 arch/arm/mach-at91/at91x40_time.c             | 2 +-
 arch/arm/mach-at91/include/mach/at91_matrix.h | 2 +-
 arch/arm/mach-at91/include/mach/at91_st.h     | 2 +-
 5 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-at91/at91_rstc.h b/arch/arm/mach-at91/at91_rstc.h
index 875fa33..a600e69 100644
--- a/arch/arm/mach-at91/at91_rstc.h
+++ b/arch/arm/mach-at91/at91_rstc.h
@@ -23,7 +23,7 @@ extern void __iomem *at91_rstc_base;
 	__raw_readl(at91_rstc_base + field)
 
 #define at91_rstc_write(field, value) \
-	__raw_writel(value, at91_rstc_base + field);
+	__raw_writel(value, at91_rstc_base + field)
 #else
 .extern at91_rstc_base
 #endif
diff --git a/arch/arm/mach-at91/at91_shdwc.h b/arch/arm/mach-at91/at91_shdwc.h
index 60478ea..9e29f31 100644
--- a/arch/arm/mach-at91/at91_shdwc.h
+++ b/arch/arm/mach-at91/at91_shdwc.h
@@ -23,7 +23,7 @@ extern void __iomem *at91_shdwc_base;
 	__raw_readl(at91_shdwc_base + field)
 
 #define at91_shdwc_write(field, value) \
-	__raw_writel(value, at91_shdwc_base + field);
+	__raw_writel(value, at91_shdwc_base + field)
 #endif
 
 #define AT91_SHDW_CR		0x00			/* Shut Down Control Register */
diff --git a/arch/arm/mach-at91/at91x40_time.c b/arch/arm/mach-at91/at91x40_time.c
index 0e57e44..f4c81c2 100644
--- a/arch/arm/mach-at91/at91x40_time.c
+++ b/arch/arm/mach-at91/at91x40_time.c
@@ -33,7 +33,7 @@
 	__raw_readl(AT91_IO_P2V(AT91_TC) + field)
 
 #define at91_tc_write(field, value) \
-	__raw_writel(value, AT91_IO_P2V(AT91_TC) + field);
+	__raw_writel(value, AT91_IO_P2V(AT91_TC) + field)
 
 /*
  *	3 counter/timer units present.
diff --git a/arch/arm/mach-at91/include/mach/at91_matrix.h b/arch/arm/mach-at91/include/mach/at91_matrix.h
index 02fae9d..f8996c9 100644
--- a/arch/arm/mach-at91/include/mach/at91_matrix.h
+++ b/arch/arm/mach-at91/include/mach/at91_matrix.h
@@ -14,7 +14,7 @@ extern void __iomem *at91_matrix_base;
 	__raw_readl(at91_matrix_base + field)
 
 #define at91_matrix_write(field, value) \
-	__raw_writel(value, at91_matrix_base + field);
+	__raw_writel(value, at91_matrix_base + field)
 
 #else
 .extern at91_matrix_base
diff --git a/arch/arm/mach-at91/include/mach/at91_st.h b/arch/arm/mach-at91/include/mach/at91_st.h
index 969aac2..67fdbd1 100644
--- a/arch/arm/mach-at91/include/mach/at91_st.h
+++ b/arch/arm/mach-at91/include/mach/at91_st.h
@@ -23,7 +23,7 @@ extern void __iomem *at91_st_base;
 	__raw_readl(at91_st_base + field)
 
 #define at91_st_write(field, value) \
-	__raw_writel(value, at91_st_base + field);
+	__raw_writel(value, at91_st_base + field)
 #else
 .extern at91_st_base
 #endif
-- 
1.8.1.5



From jhovold at gmail.com  Sun Apr  7 10:49:58 2013
From: jhovold at gmail.com (Johan Hovold)
Date: Sun,  7 Apr 2013 16:49:58 +0200
Subject: [PATCH 1/2] ARM: at91/setup: fix trivial typos
Message-ID: <1365346199-29525-1-git-send-email-jhovold@gmail.com>

Fix a few trivial typos in panic, warning and debug messages.

Signed-off-by: Johan Hovold <jhovold at gmail.com>
---
 arch/arm/mach-at91/setup.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-at91/setup.c b/arch/arm/mach-at91/setup.c
index 4b67847..9e7c1e1 100644
--- a/arch/arm/mach-at91/setup.c
+++ b/arch/arm/mach-at91/setup.c
@@ -333,7 +333,7 @@ static void at91_dt_rstc(void)
 
 	of_id = of_match_node(rstc_ids, np);
 	if (!of_id)
-		panic("AT91: rtsc no restart function availlable\n");
+		panic("AT91: rtsc no restart function available\n");
 
 	arm_pm_restart = of_id->data;
 
@@ -353,7 +353,7 @@ static void at91_dt_ramc(void)
 
 	np = of_find_matching_node(NULL, ramc_ids);
 	if (!np)
-		panic("unable to find compatible ram conroller node in dtb\n");
+		panic("unable to find compatible ram controller node in dtb\n");
 
 	at91_ramc_base[0] = of_iomap(np, 0);
 	if (!at91_ramc_base[0])
@@ -403,7 +403,7 @@ static void at91_dt_shdwc(void)
 
 	np = of_find_matching_node(NULL, shdwc_ids);
 	if (!np) {
-		pr_debug("AT91: unable to find compatible shutdown (shdwc) conroller node in dtb\n");
+		pr_debug("AT91: unable to find compatible shutdown (shdwc) controller node in dtb\n");
 		return;
 	}
 
@@ -419,7 +419,7 @@ static void at91_dt_shdwc(void)
 
 	if (!of_property_read_u32(np, "atmel,wakeup-counter", &reg)) {
 		if (reg > AT91_SHDW_CPTWK0_MAX) {
-			pr_warn("AT91: shdwc wakeup conter 0x%x > 0x%x reduce it to 0x%x\n",
+			pr_warn("AT91: shdwc wakeup counter 0x%x > 0x%x reduce it to 0x%x\n",
 				reg, AT91_SHDW_CPTWK0_MAX, AT91_SHDW_CPTWK0_MAX);
 			reg = AT91_SHDW_CPTWK0_MAX;
 		}
-- 
1.8.1.5



From jhovold at gmail.com  Sun Apr  7 11:09:38 2013
From: jhovold at gmail.com (Johan Hovold)
Date: Sun, 7 Apr 2013 17:09:38 +0200
Subject: [PATCH] rtc: rtc-at91sam9.c add DT support
In-Reply-To: <515D8944.2060308@atmel.com>
References: <515CF985.6050009@interlog.com> <515D35C2.7050405@atmel.com>
 <515D7F56.90702@interlog.com> <515D8944.2060308@atmel.com>
Message-ID: <20130407150938.GA25605@localhost>

On Thu, Apr 04, 2013 at 04:08:04PM +0200, Nicolas Ferre wrote:
> On 04/04/2013 03:25 PM, Douglas Gilbert :
> > On 13-04-04 04:11 AM, Nicolas Ferre wrote:
> >> On 04/04/2013 05:54 AM, Douglas Gilbert :
> >>> Some members of the at91 SoCs use the Real Time Timer (RTT)
> >>> and the General Purpose Backup Registers (GPBR) to implement
> >>> a real time clock (RTC). The AT91SAM9G20 is one example.
> >>>
> >>> Attached is a patch to add DT support to rtc-at91sam9.c .
> >>> The patch is against lk 3.9.0-rc5 .
> >>>
> >>> Below is a snippet of DT code for the 'G20 that was observed
> >>> to work with this patch:
> >>>
> >>> ahb {
> >>>      apb {
> >>>
> >>>          rtc {
> >>>              compatible = "atmel,at91sam9-rtc";
> >>
> >> The compatible string has to be formed by the name of the first SoC
> >> compatible with this IP. It turns to be the at91sam9260.
> >> The second part of the string should be a name that reflects the nature
> >> of the peripheral. For this binding, I would like to mention the "RTT"
> >> in the compatibility string (because other drivers can use other RTT
> >> with other uses).
> >>
> >> What do you think about:
> >> "atmel,at91sam9260-rtt-as-rtc"? or something shorter?
> > 
> > Hi Nicolas,
> > Johan Hovold suggested:
> >    atmel,at91sam9260-rtt
> 
> Yes, but I fear this could bring confusion if someone is building a RTT
> driver that is not targeted at acting as a RTC...

But isn't the compatible property supposed to describe the peripheral in
a completely platform-agnostic way?

In fact, it seems it should be on the form

	compatible = "atmel,at91sam9g45-rtt", "atmel,at91sam9260-rtt";

where an exact description (the actual SoC-IP) is followed by a more
generic compatible description (e.g. the first SoC that introduced the
IP that is still compatible) (see [1]). This policy seems not have been
followed for at91 though, as only the second (first compatible SoC)
string is generally used. 

Either way, this still leaves open the question of which driver gets
bound to a device if there are more than one driver that matches the
compatible property. I guess this could be solved with a property set
or overridden by the board description. For example:

at91sam9g45.dtsi:

	rtt at fffffd20 {
		compatible = "atmel,at91sam9g45-rtt", "atmel,at91sam9260-rtt";
		reg = <0xfffffd20 0x10>;
		interrupts = <1 4 7>;
		status = "disabled";
	};

at91sam9m10g45ek.dts:

	rtt at fffffd20 {
		atmel,at91-rtt-as-rtc;
		status = "okay";
	};

If the device-specific property atmel,at91-rtt-as-rtc is missing,
the rtc-at91sam9 driver probe should fail so that any other matching
driver is probed. Of course, this will only work if the other matching
rtt-drivers also add device-specific properties so that they can be
disabled as well (should the probe order be reversed), for instance:

	atmel,at91-rtt-as-<xxx>;

> >>>                           /* RTTC followed by GPBR (backup registers) */
> >>>                           reg = <0xfffffd20 0x10>, <0xfffffd50 0x10>;
> >>>                           interrupts = <1 4 7>;
> >>>                           status = "okay";

Which backup register (GPBR) the RTC-time base should be stored in is
currently configurable using CONFIG_RTC_DRV_AT91SAM9_GPBR (and the
address arguably not even a property of the rtt) so the register address
should in any case not be set in the rtt-node of the dtsi.

Instead I think we need the arch code to map the backup-registers and
thus to add a new gpbr-node:

	gpbr at fffffd60 {
		compatible = "atmel,at91sam9g45-gpbr", "atmel,at91sam9260-gpbr";
		reg = <0xfffffd60 0x10>;
	};

We could then use CONFIG_RTC_DRV_AT91SAM9_GPBR for non-DT as before, and
add a new property (or simply replace the boolean) to the rtt-nodes in
the board descriptions:

	rtt at fffffd20 {
		atmel,at91-rtt-as-rtc;
		atmel,at91-rtt-as-rtc-gpbr = <n>;
		status = "okay";
	};

to select which of the four (sam9263 has 20) backup registers to use.

I'm responding to this mail with an RFC-implementing the GPBR and
RTT-as-RTC DT support as outlined above.

Finally, for the record: There are currently no other rtt-drivers, but I
have posted a patch series a while ago to fix hanged boot due to early
spurious RTT (or RTC) interrupts (see [2]). The series uses
"atmel,at91sam9260-rtt" to detect the SoCs that are affected by the
problem, and I guess that is an example of why the compatible string
should merely describe the peripheral (and not its use).

Thanks,
Johan

[1] http://www.devicetree.org/Device_Tree_Usage#Understanding_the_compatible_Property
[2] http://marc.info/?l=linux-arm-kernel&m=136302554825979&w=2


From shc_work at mail.ru  Sun Apr  7 11:29:13 2013
From: shc_work at mail.ru (Alexander Shiyan)
Date: Sun,  7 Apr 2013 19:29:13 +0400
Subject: [PATCH 2/3] ARM: dts: Add SPI support for i.MX27 Phytec PCM038 module
In-Reply-To: <1365348554-24345-1-git-send-email-shc_work@mail.ru>
References: <1365348554-24345-1-git-send-email-shc_work@mail.ru>
Message-ID: <1365348554-24345-2-git-send-email-shc_work@mail.ru>

Added SPI node to imx27-phytec-phycore DT file.

Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
---
 arch/arm/boot/dts/imx27-phytec-phycore.dtsp | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/imx27-phytec-phycore.dtsp b/arch/arm/boot/dts/imx27-phytec-phycore.dtsp
index 7228153..354dc77 100644
--- a/arch/arm/boot/dts/imx27-phytec-phycore.dtsp
+++ b/arch/arm/boot/dts/imx27-phytec-phycore.dtsp
@@ -77,3 +77,9 @@
 	nand-ecc-mode = "hw";
 	status = "okay";
 };
+
+&cspi1 {
+	fsl,spi-num-chipselects = <1>;
+	cs-gpios = <&gpio4 28 0>;
+	status = "okay";
+};
-- 
1.8.1.5



From shc_work at mail.ru  Sun Apr  7 11:29:12 2013
From: shc_work at mail.ru (Alexander Shiyan)
Date: Sun,  7 Apr 2013 19:29:12 +0400
Subject: [PATCH 1/3] ARM: dts: Add NFC support for i.MX27 Phytec PCM038 module
Message-ID: <1365348554-24345-1-git-send-email-shc_work@mail.ru>

Added NFC node to imx27-phytec-phycore DT file.

Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
---
 arch/arm/boot/dts/imx27-phytec-phycore.dtsp | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/imx27-phytec-phycore.dtsp b/arch/arm/boot/dts/imx27-phytec-phycore.dtsp
index 924097a..7228153 100644
--- a/arch/arm/boot/dts/imx27-phytec-phycore.dtsp
+++ b/arch/arm/boot/dts/imx27-phytec-phycore.dtsp
@@ -71,3 +71,9 @@
 		#size-cells = <1>;
 	};
 };
+
+&nfc {
+	nand-bus-width = <8>;
+	nand-ecc-mode = "hw";
+	status = "okay";
+};
-- 
1.8.1.5



From shc_work at mail.ru  Sun Apr  7 11:29:14 2013
From: shc_work at mail.ru (Alexander Shiyan)
Date: Sun,  7 Apr 2013 19:29:14 +0400
Subject: [PATCH 3/3] ARM: dts: Add missing imx27-phytec-phycore dtb target
In-Reply-To: <1365348554-24345-1-git-send-email-shc_work@mail.ru>
References: <1365348554-24345-1-git-send-email-shc_work@mail.ru>
Message-ID: <1365348554-24345-3-git-send-email-shc_work@mail.ru>

The patch adds missing imx27-phytec-phycore dtb target into Makefile.

Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
---
 arch/arm/boot/dts/Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 35976f0..a06d9f1 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -98,6 +98,7 @@ dtb-$(CONFIG_ARCH_MXC) += \
 	imx27-apf27.dtb \
 	imx27-apf27dev.dtb \
 	imx27-pdk.dtb \
+	imx27-phytec-phycore.dtb \
 	imx31-bug.dtb \
 	imx51-apf51.dtb \
 	imx51-apf51dev.dtb \
-- 
1.8.1.5



From matt at genesi-usa.com  Sun Apr  7 11:50:32 2013
From: matt at genesi-usa.com (Matt Sealey)
Date: Sun, 7 Apr 2013 10:50:32 -0500
Subject: [RFC PATCH] CLK: Allow parent clock and rate to be configured in
 DT.
In-Reply-To: <20130407132623.GP1906@pengutronix.de>
References: <20130319170933.28337.50448.stgit@localhost>
 <CAOMZO5ASkvquyzPCEGObvB5Xh9bDPTJ2zx26eOUJT_Vb36Bn3Q@mail.gmail.com>
 <CAKGA1bkWLrOs15ni=8D__BvuG6kvqkeeLZGOLrVZY9g0q0z4Bg@mail.gmail.com>
 <6581638.FPkNsv6peb@flatron> <20130407132623.GP1906@pengutronix.de>
Message-ID: <CAKGA1b=AcQsA-P-pR+in+9CzqW=XfEBhdoR+AC7QCLYfUhQqJg@mail.gmail.com>

On Sun, Apr 7, 2013 at 8:26 AM, Sascha Hauer <s.hauer at pengutronix.de> wrote:
> On Sat, Apr 06, 2013 at 03:21:19PM +0200, Tomasz Figa wrote:
>> Hi,
>>
>> [RANT]
>>
>> I tend to disagree about this whole hype about device tree usage for other
>> things than pure hardware description. I don't think device tree should be
>> a way to force some kind of new world order, but rather a more convenient
>> and more maintainable (than board files) way of support hardware platforms
>> in Linux kernel.
>
> Honestly I'm annoyed by this aswell. The devicetree contains a nice and
> complete hardware description and it seems convenient to put hardware
> related configuration data there aswell.

It's convenient because it means less work for one person; but I posit
that the work has already been done or the board would have never
passed post-production testing i.e. does this clock output correctly?
If so, then the code was written to make it do so. if it was not
integrated into the bootloader, this is an engineering problem easier
tackled by doing that than creating a whole new device tree binding.

The reason device tree, in my opinion, is not for "telling the OS how
to force reconfiguration of the hardware so it works," is simply
because engineering problems as above do not get tackled at all. If
you can write a completely awful bootloader that mis-configures the
board and causes myriad problems, but then get trapped in a cycle of
"Linux works fine, and we have a deadline, so.. fuck it" then what
you're doing is forcing the kind of awful code that we ended up with
in BSPs, the kind of awful code that existed BEFORE the move to device
tree.

In the case where we could "move the clko setup for SabreLite into the
device tree," this is an impetus we all agree on that we should not be
doing board-specific hacks if we can help it. But you don't move one
hack to another place and suddenly it quits being a hack. It will just
be someone else's responsibility.

> The problem is that hardware description and configuration data are two
> completely different sets of data. The hardware description is static
> for a given board and should (ideally) never change. The configuration
> data instead is often usecase specific and changes over the lifetime of
> a board. The configuration data can only handle a single (or maybe a
> table of) static setup(s). It's a good way to specify a sane default or
> a very special setup, but doesn't handle the case when some OS (or
> version thereof) wants to have a static setup and another wants to
> figure out the same data dynamically.



> For these reasons I am against throwing the two data sets into a single
> pot. Still I also want to have the devicetree way to configure some
> static setup items.

Well as I proposed, instead of having a special magic configuration
data and a backdoor to re-doing work that should be done elsewhere, we
should basically turn one of them into a kind of sanity check - it is
much, much more desirable for Linux to fudge around weirdly described
hardware and warn about it and there are many examples of this in the
Linux kernel. Embarrassingly, two of the examples are for Genesi
platforms on PowerPC, and one that immediately springs to mind is the
one about piix_smbus not finding a configured smbus address. This is a
problem in most VM BIOS implementations, since they do not have fans
to control, they don't bother implementing or virtualizing it or
telling the OS something is there (and it would require supporting a
ton of different fan controllers to figure different operating
systems), but Linux will always, always pop this warning up for me.
And it is correct to do so.. there are real life BIOS implementations
that do not contain any data about where the smbus controller is, and
most "A*** Super Overclock Fan Utility" on Windows are hardcoded for a
very specific PC model to work around this.

The sanity check is, in a properly described clock, you would list
it's suitable parents and the parent you THINK your hardware has set
right now - or, the only one your hardware CAN support. You can hijack
this a little such that if the parent is not the one in the DTB then
it gets set, with a warning (and for nitpickers like me, never turn on
this since we would prefer to fix our bootloader until it doesn't spit
a warning AND everything works).

For magic clock-frequency definition at the device level, this is best
done with power management in mind, the method will work everywhere
and have the same basic concept and binding, but it HAS to be
device-specific - not clock-specific or clock-subsystem specific. I do
not think it is the DTB's place to "tell Linux how to configure the
clock subsystem", just tell it where those clocks are and what the
current hardware settings are if they are not derivable from the
hardware itself. In the case we cannot tell by reading a register what
the current configuration is, or it is fundamentally more complicated
at the time of single clock initialization, then we need to provide
this data in the DTB anyway, and this binding would suit the
complicated version AND all the dirt simple implementations
(complicated version = has distinct benefit by abstracting the
hardware, simple version = effects a sanity check).

If we're dealing with audio codecs, fix the audio codec to accept a
*table* of possible clock values and if that hardware operates
differently per clock value, then add that data in there too (like the
cs42l52 audio codec). Where the software and hardware is a little more
dynamic, the same binding works here - and the usual trick is just
force one configuration possible out of many. The board designer can
look at all the possibilities and choose the one or two or all that
will work with the design, and it can go into the device tree.

In the case where we have a board design here where the clock
frequency MUST be set and MUST be fixed and MUST NEVER be changed
while it is running (i.e. audio codec and camera sharing a master
clock, and glitching the audio clock just to set it to the "right"
frequency would make the camera stop working), I can't approve of
anything proposed so far as it does not take this into account.
Remember, your device may not own the clock it is trying to use, and
you make it more difficult to coordinate between subsystems when
you're basically blanket hardcoding values in places. And I think the
"little overlay with configuration data" makes no sense when this is
entirely a bootloader vs. driver-that-doesn't-do-enough problem.

There are ways around every specific problem we're discussing here
without having magic, forced configuration tables. There will be ways
around having magic, forced configuration tables for everything else,
I guarantee it..

> Also board designers could describe the hardware and give one or more
> usage hints without forcing anybody to actually use them.

Usually the "hint" from a board designer is not really a hint, but the
only way the board was designed to work. You can't just "modify" their
suggestion on what clock to use, or the restrictions in place on
routing, signalling etc. at a whim just because it is configurable at
the SoC level. The device tree serves to tell Linux how the board was
designed, where things have been placed so it can abstract the
thousands upon thousands of lines of duplicated
platform_device_register lines and static data floating around. But
the original concept was that as the firmware booted, and initialized
all the devices capable of being used in the system, it would add each
one with it's post-initialization data to the device tree and pass
this to the OS so that it would not need to guess, or re-perform
initialization. And this is the point I would like to see stick -
Linux should not be manually re-initializing everything, reconfiguring
every little thing when the bootloader so carefully did it already.
There is a use case for catching fundamental flaws in the bootloader
setup and fixing them, but then you have a heady mix of boards which
specify EVERY configuration item possible and some which are very
simply descriptions of valid, usable state at bootloader->kernel
transition time.

That is a weird dichotomy to have and a decision to be made; do we put
all our effort into making the data fit into device tree or do we just
do it in the bootloader (which we would have had to have coded as real
platform test code before the boards passed production testing
anyway)? It is not a world I want to live in where the answer is NOT
to use the code written to pass production test in the bootloader.
Doing it in the device tree just means people who never learned about
board production, low level testing never, ever learn about that, and
those people TEND to make very strange decisions about what data needs
to be in the device tree. We already have with pinctrl - if the
bootloader set up pins already to boot from SD card, why do we specify
those pins again in Linux for it to configure them exactly the same
way, again? I know there are only a couple of blobs in the Babbage DT
that really need setting because U-Boot has already configured them
but they're in there - and Linux sets all those values again. Some of
the things it is setting up again, *IF* (and it is possible) it causes
a glitch in logic or an I/O direction change at any point can put the
board electrically in a completely undesirable state. 50,000 times
later your board is burnt, but how would you ever know this caused it?

I should also note, it is NOT simpler to add an entry to device tree
for configuration, since you need to write a binding that describes it
and a driver on the other side to parse the data the way the binding
describes to implement that configuration. Then you need to add the
entry to the device tree to test it. Why not use the minimal code
required to just set that hardware at a low level to the configuration
you wanted, at Boot ROM or Bootloader time, and describe that with the
bindings that already exist?

--
Matt Sealey <matt at genesi-usa.com>
Product Development Analyst, Genesi USA, Inc.


From festevam at gmail.com  Sun Apr  7 12:00:41 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Sun, 7 Apr 2013 13:00:41 -0300
Subject: [RFC PATCH] CLK: Allow parent clock and rate to be configured in
 DT.
In-Reply-To: <CAKGA1b=AcQsA-P-pR+in+9CzqW=XfEBhdoR+AC7QCLYfUhQqJg@mail.gmail.com>
References: <20130319170933.28337.50448.stgit@localhost>
 <CAOMZO5ASkvquyzPCEGObvB5Xh9bDPTJ2zx26eOUJT_Vb36Bn3Q@mail.gmail.com>
 <CAKGA1bkWLrOs15ni=8D__BvuG6kvqkeeLZGOLrVZY9g0q0z4Bg@mail.gmail.com>
 <6581638.FPkNsv6peb@flatron> <20130407132623.GP1906@pengutronix.de>
 <CAKGA1b=AcQsA-P-pR+in+9CzqW=XfEBhdoR+AC7QCLYfUhQqJg@mail.gmail.com>
Message-ID: <CAOMZO5ARwOLdSg4Np_HB2m7zvTNE94bJBUh3R-oG=xcP4R6Y-Q@mail.gmail.com>

On Sun, Apr 7, 2013 at 12:50 PM, Matt Sealey <matt at genesi-usa.com> wrote:

> If we're dealing with audio codecs, fix the audio codec to accept a
> *table* of possible clock values and if that hardware operates
> differently per clock value, then add that data in there too (like the
> cs42l52 audio codec). Where the software and hardware is a little more
> dynamic, the same binding works here - and the usual trick is just
> force one configuration possible out of many. The board designer can
> look at all the possibilities and choose the one or two or all that
> will work with the design, and it can go into the device tree.

Sorry, but I have a hard time following a so long response.

Can't you just send patches to the list with your proposal so that we
can move forward with the idea?


From matt at genesi-usa.com  Sun Apr  7 12:23:25 2013
From: matt at genesi-usa.com (Matt Sealey)
Date: Sun, 7 Apr 2013 11:23:25 -0500
Subject: [RFC PATCH] CLK: Allow parent clock and rate to be configured in
 DT.
In-Reply-To: <CAOMZO5ARwOLdSg4Np_HB2m7zvTNE94bJBUh3R-oG=xcP4R6Y-Q@mail.gmail.com>
References: <20130319170933.28337.50448.stgit@localhost>
 <CAOMZO5ASkvquyzPCEGObvB5Xh9bDPTJ2zx26eOUJT_Vb36Bn3Q@mail.gmail.com>
 <CAKGA1bkWLrOs15ni=8D__BvuG6kvqkeeLZGOLrVZY9g0q0z4Bg@mail.gmail.com>
 <6581638.FPkNsv6peb@flatron> <20130407132623.GP1906@pengutronix.de>
 <CAKGA1b=AcQsA-P-pR+in+9CzqW=XfEBhdoR+AC7QCLYfUhQqJg@mail.gmail.com>
 <CAOMZO5ARwOLdSg4Np_HB2m7zvTNE94bJBUh3R-oG=xcP4R6Y-Q@mail.gmail.com>
Message-ID: <CAKGA1bnt_wrNPg2JdAu=ac+WiUm8pVaGh3Tjrt3NvgdFeLxB8A@mail.gmail.com>

On Sun, Apr 7, 2013 at 11:00 AM, Fabio Estevam <festevam at gmail.com> wrote:
> On Sun, Apr 7, 2013 at 12:50 PM, Matt Sealey <matt at genesi-usa.com> wrote:
>
>> If we're dealing with audio codecs, fix the audio codec to accept a
>> *table* of possible clock values and if that hardware operates
>> differently per clock value, then add that data in there too (like the
>> cs42l52 audio codec). Where the software and hardware is a little more
>> dynamic, the same binding works here - and the usual trick is just
>> force one configuration possible out of many. The board designer can
>> look at all the possibilities and choose the one or two or all that
>> will work with the design, and it can go into the device tree.
>
> Sorry, but I have a hard time following a so long response.
>
> Can't you just send patches to the list with your proposal so that we
> can move forward with the idea?

Sure.

-- 
Matt Sealey <matt at genesi-usa.com>
Product Development Analyst, Genesi USA, Inc.


From matt at genesi-usa.com  Sun Apr  7 12:34:14 2013
From: matt at genesi-usa.com (Matt Sealey)
Date: Sun, 7 Apr 2013 11:34:14 -0500
Subject: [RFC PATCH] CLK: Allow parent clock and rate to be configured in
 DT.
In-Reply-To: <CAKGA1bnt_wrNPg2JdAu=ac+WiUm8pVaGh3Tjrt3NvgdFeLxB8A@mail.gmail.com>
References: <20130319170933.28337.50448.stgit@localhost>
 <CAOMZO5ASkvquyzPCEGObvB5Xh9bDPTJ2zx26eOUJT_Vb36Bn3Q@mail.gmail.com>
 <CAKGA1bkWLrOs15ni=8D__BvuG6kvqkeeLZGOLrVZY9g0q0z4Bg@mail.gmail.com>
 <6581638.FPkNsv6peb@flatron> <20130407132623.GP1906@pengutronix.de>
 <CAKGA1b=AcQsA-P-pR+in+9CzqW=XfEBhdoR+AC7QCLYfUhQqJg@mail.gmail.com>
 <CAOMZO5ARwOLdSg4Np_HB2m7zvTNE94bJBUh3R-oG=xcP4R6Y-Q@mail.gmail.com>
 <CAKGA1bnt_wrNPg2JdAu=ac+WiUm8pVaGh3Tjrt3NvgdFeLxB8A@mail.gmail.com>
Message-ID: <CAKGA1bnhMz-18RvUq1Bx-b_AztwspYC+Q+3QGYf=kBtMe1nq2w@mail.gmail.com>

Or actually, let me rephrase that; sure, when we decide that the
actual clock tree is described IN the device tree and not in Linux -
the only thing I have to test this on is i.MX and OMAP and it's all a
huge table in the Linux kernel which the DT uses to reference
arbitrary indices into a provider array...

I could add desired parents to the provider array but that wouldn't
really fix the configuration problem. Can we get an agreement that
actually, no matter how "unwieldy" or "unreadable" some people think
it might be, that the entire clock tree for a board should end up in
it's device tree (muxes, selects, gates and all) with suitable
bindings? This is the only way you'll get clock "hacks" out of the
source.

I do have a kernel tree for some 3.8-rc (which you know of already)
which started work on this and I had some success with it. I'll need a
little while to move it forward after Shawn moved some things around,
rebase all the work.. there are more problems to fix with how
everything "works" right now than just a need for configuration data,
which is why I am so opposed to adding that configuration data. It
supposes that we are giving complete descriptions already anyway, and
my proposal relies on having complete descriptions anyway, when we are
not in either case. Give me a couple weeks and I'll probably have it
done, if nothing moves under my feet again..

At the point where we have two proposals here; implement 100 clocks as
device tree nodes, or implement multiple ways of providing clock
reparenting and frequency setting information as a configuration
clock, I would rather implement those 100 clocks as nodes..
Matt Sealey <matt at genesi-usa.com>
Product Development Analyst, Genesi USA, Inc.


On Sun, Apr 7, 2013 at 11:23 AM, Matt Sealey <matt at genesi-usa.com> wrote:
> On Sun, Apr 7, 2013 at 11:00 AM, Fabio Estevam <festevam at gmail.com> wrote:
>> On Sun, Apr 7, 2013 at 12:50 PM, Matt Sealey <matt at genesi-usa.com> wrote:
>>
>>> If we're dealing with audio codecs, fix the audio codec to accept a
>>> *table* of possible clock values and if that hardware operates
>>> differently per clock value, then add that data in there too (like the
>>> cs42l52 audio codec). Where the software and hardware is a little more
>>> dynamic, the same binding works here - and the usual trick is just
>>> force one configuration possible out of many. The board designer can
>>> look at all the possibilities and choose the one or two or all that
>>> will work with the design, and it can go into the device tree.
>>
>> Sorry, but I have a hard time following a so long response.
>>
>> Can't you just send patches to the list with your proposal so that we
>> can move forward with the idea?
>
> Sure.
>
> --
> Matt Sealey <matt at genesi-usa.com>
> Product Development Analyst, Genesi USA, Inc.


From shc_work at mail.ru  Sun Apr  7 13:02:11 2013
From: shc_work at mail.ru (Alexander Shiyan)
Date: Sun,  7 Apr 2013 21:02:11 +0400
Subject: [PATCH] regulator: mc13783: Add device tree probe support
Message-ID: <1365354131-9770-1-git-send-email-shc_work@mail.ru>

Patch adds device tree probe support for mc13783-regulator driver.

Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
---
 drivers/regulator/mc13783-regulator.c      | 55 ++++++++++++++++++++++--------
 drivers/regulator/mc13xxx-regulator-core.c |  2 ++
 2 files changed, 42 insertions(+), 15 deletions(-)

diff --git a/drivers/regulator/mc13783-regulator.c b/drivers/regulator/mc13783-regulator.c
index c46c670..fba8d5e 100644
--- a/drivers/regulator/mc13783-regulator.c
+++ b/drivers/regulator/mc13783-regulator.c
@@ -398,33 +398,62 @@ static int mc13783_regulator_probe(struct platform_device *pdev)
 	struct mc13xxx *mc13783 = dev_get_drvdata(pdev->dev.parent);
 	struct mc13xxx_regulator_platform_data *pdata =
 		dev_get_platdata(&pdev->dev);
-	struct mc13xxx_regulator_init_data *init_data;
+	struct mc13xxx_regulator_init_data *mc13xxx_data;
 	struct regulator_config config = { };
-	int i, ret;
+	int i, ret, num_regulators, num_parsed;
 
-	dev_dbg(&pdev->dev, "%s id %d\n", __func__, pdev->id);
+	num_regulators = mc13xxx_get_num_regulators_dt(pdev);
 
-	if (!pdata)
+	if (num_regulators <= 0 && pdata)
+		num_regulators = pdata->num_regulators;
+	if (num_regulators <= 0)
 		return -EINVAL;
 
+	num_parsed = num_regulators;
+
 	priv = devm_kzalloc(&pdev->dev, sizeof(*priv) +
-			pdata->num_regulators * sizeof(priv->regulators[0]),
+			num_regulators * sizeof(priv->regulators[0]),
 			GFP_KERNEL);
 	if (!priv)
 		return -ENOMEM;
 
+	priv->num_regulators = num_regulators;
 	priv->mc13xxx_regulators = mc13783_regulators;
 	priv->mc13xxx = mc13783;
+	platform_set_drvdata(pdev, priv);
 
-	for (i = 0; i < pdata->num_regulators; i++) {
-		struct regulator_desc *desc;
+	mc13xxx_data = mc13xxx_parse_regulators_dt(pdev, mc13783_regulators,
+					ARRAY_SIZE(mc13783_regulators),
+					&num_parsed);
+	if (num_parsed != num_regulators) {
+		dev_warn(&pdev->dev,
+		"parsed %d != regulators %d - check your device tree!\n",
+			num_parsed, num_regulators);
 
-		init_data = &pdata->regulators[i];
-		desc = &mc13783_regulators[init_data->id].desc;
+		num_regulators = num_parsed;
+		priv->num_regulators = num_regulators;
+	}
+
+	for (i = 0; i < num_regulators; i++) {
+		struct regulator_init_data *init_data;
+		struct regulator_desc *desc;
+		struct device_node *node = NULL;
+		int id;
+
+		if (mc13xxx_data) {
+			id = mc13xxx_data[i].id;
+			init_data = mc13xxx_data[i].init_data;
+			node = mc13xxx_data[i].node;
+		} else {
+			id = pdata->regulators[i].id;
+			init_data = pdata->regulators[i].init_data;
+		}
+		desc = &mc13783_regulators[id].desc;
 
 		config.dev = &pdev->dev;
-		config.init_data = init_data->init_data;
+		config.init_data = init_data;
 		config.driver_data = priv;
+		config.of_node = node;
 
 		priv->regulators[i] = regulator_register(desc, &config);
 		if (IS_ERR(priv->regulators[i])) {
@@ -435,8 +464,6 @@ static int mc13783_regulator_probe(struct platform_device *pdev)
 		}
 	}
 
-	platform_set_drvdata(pdev, priv);
-
 	return 0;
 err:
 	while (--i >= 0)
@@ -448,13 +475,11 @@ err:
 static int mc13783_regulator_remove(struct platform_device *pdev)
 {
 	struct mc13xxx_regulator_priv *priv = platform_get_drvdata(pdev);
-	struct mc13xxx_regulator_platform_data *pdata =
-		dev_get_platdata(&pdev->dev);
 	int i;
 
 	platform_set_drvdata(pdev, NULL);
 
-	for (i = 0; i < pdata->num_regulators; i++)
+	for (i = 0; i < priv->num_regulators; i++)
 		regulator_unregister(priv->regulators[i]);
 
 	return 0;
diff --git a/drivers/regulator/mc13xxx-regulator-core.c b/drivers/regulator/mc13xxx-regulator-core.c
index 23cf9f9..836e21e 100644
--- a/drivers/regulator/mc13xxx-regulator-core.c
+++ b/drivers/regulator/mc13xxx-regulator-core.c
@@ -205,6 +205,8 @@ struct mc13xxx_regulator_init_data *mc13xxx_parse_regulators_dt(
 
 	for_each_child_of_node(parent, child) {
 		for (i = 0; i < num_regulators; i++) {
+			if (!regulators[i].desc.name)
+				continue;
 			if (!of_node_cmp(child->name,
 					 regulators[i].desc.name)) {
 
-- 
1.8.1.5



From sergei.shtylyov at cogentembedded.com  Sun Apr  7 13:55:08 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Sun, 07 Apr 2013 21:55:08 +0400
Subject: [PATCH v9 4/6] ARM: davinci: Add a remoteproc driver
 implementation for OMAP-L13x DSP
In-Reply-To: <CAK=WgbZme2UkMeP-JB2h3xnmcpzAaYeOcy7gxh60muJ8KZbr_A@mail.gmail.com>
References: <1364521307-1219-1-git-send-email-rtivy@ti.com>
 <1364521307-1219-5-git-send-email-rtivy@ti.com>
 <CAK=WgbZme2UkMeP-JB2h3xnmcpzAaYeOcy7gxh60muJ8KZbr_A@mail.gmail.com>
Message-ID: <5161B2FC.2090605@cogentembedded.com>

Hello.

On 04/07/2013 05:02 PM, Ohad Ben-Cohen wrote:

>
>> +static int da8xx_rproc_probe(struct platform_device *pdev)
>> +{
>> +       struct device *dev = &pdev->dev;
>> +       struct da8xx_rproc *drproc;
>> +       struct rproc *rproc;
>> +       struct irq_data *irq_data;
>> +       struct resource *bootreg_res;
>> +       struct resource *chipsig_res;
>> +       struct clk *dsp_clk;
>> +       void __iomem *chipsig;
>> +       void __iomem *bootreg;
>> +       int irq;
>> +       int ret;
>> +
[...]
>> +       bootreg = devm_request_and_ioremap(dev, bootreg_res);
>> +       if (!bootreg) {
>> +               dev_err(dev, "unable to map boot register\n");
>> +               return -EADDRNOTAVAIL;
>> +       }
>> +
>> +       chipsig = devm_request_and_ioremap(dev, chipsig_res);

    I suggest that you use more modern (yes, already a newer interface :-)
devm_ioremap_resource() instead -- it returns the error code (as a pointer)
in case of error, and it certainly doesn't require you to print error 
messages.

>> +       if (!chipsig) {
>> +               dev_err(dev, "unable to map CHIPSIG register\n");
>> +               return -EADDRNOTAVAIL;
>> +       }
>>

WBR, Sergei



From linus.walleij at linaro.org  Sun Apr  7 14:43:37 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Sun, 7 Apr 2013 20:43:37 +0200
Subject: [PATCH 11/11] RFC: ARM: get PCI device IRQs from device tree
In-Reply-To: <201304041527.52400.arnd@arndb.de>
References: <1365087696-9548-1-git-send-email-linus.walleij@linaro.org>
 <1365087696-9548-11-git-send-email-linus.walleij@linaro.org>
 <1365087696-9548-12-git-send-email-linus.walleij@linaro.org>
 <201304041527.52400.arnd@arndb.de>
Message-ID: <CACRpkdYYmVpQkKngQSt-mQbhE=PXcy1U8P735Ws6tqw55nWvmA@mail.gmail.com>

On Thu, Apr 4, 2013 at 5:27 PM, Arnd Bergmann <arnd at arndb.de> wrote:
> On Thursday 04 April 2013, Linus Walleij wrote:
>> This adds the interrupt-map property to the PCIv3 DTS file
>> and makes the bridge obtain mappings from the device tree.
>>
>> Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
>> ---
>> This currently bugs out - when trying to get the IRQs for
>> devices of_irq_map_pci() reads the IRQ pin from the PCI config
>> space successfully, then comes to trying to look up the parent
>> PCI device by checking pdev->bus->self, which is NULL, then
>> tries to treat it as a bridge doing pci_bus_to_OF_node(pdev->bus)
>> which also results in NULL and it bails out.
>>
>> No clue why this is so - some problem with the parent of this
>> bus not being a PCI device in itself? Help.
>
> All the PowerPC implementations I remember had the PCI bus
> as a device under the root node. It's very possible that it's
> just a bug in of_irq_map_pci().

Hm, quite hard to figure this one out.

Benjamin, any hints?

Yours,
Linus Walleij


From festevam at gmail.com  Sun Apr  7 14:44:59 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Sun,  7 Apr 2013 15:44:59 -0300
Subject: [PATCH v6] video: mxsfb: Introduce regulator support
Message-ID: <1365360299-8707-1-git-send-email-festevam@gmail.com>

From: Fabio Estevam <fabio.estevam at freescale.com>

Instead of using a custom binding for retrieving the GPIO that activates the 
LCD from devicetree, use a standard regulator.

This approach has the advantage to be more generic. 

For example: in the case of a board that has a PMIC supplying the LCD voltage, 
the current approach would not work, as it only searches for a GPIO pin.

Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
---
Changes since v5:
- Remove 'Optional properties' line from mxsfb.txt
- Place regultar_disable in the end of mxsfb_disable_controller
- Check for IS_ERR((IS_ERR(host->reg_lcd)) inside probe
Chages since v4:
- Merged the 2 previous patches into one in order not to break keep mxsfb functionality
- Remove unneeded change in mxsfb.txt
- Use regulator_disable to pair with regulator_enable
Changes since v3:
- None
Changes since v2:
- Use devm_regulator_get()
Changes since v1:
- No changes
 Documentation/devicetree/bindings/fb/mxsfb.txt |    4 ---
 arch/arm/boot/dts/imx23-evk.dts                |   11 ++++++-
 arch/arm/boot/dts/imx28-evk.dts                |   11 ++++++-
 drivers/video/mxsfb.c                          |   41 +++++++++++++-----------
 4 files changed, 43 insertions(+), 24 deletions(-)

diff --git a/Documentation/devicetree/bindings/fb/mxsfb.txt b/Documentation/devicetree/bindings/fb/mxsfb.txt
index 7ba3b76..96ec517 100644
--- a/Documentation/devicetree/bindings/fb/mxsfb.txt
+++ b/Documentation/devicetree/bindings/fb/mxsfb.txt
@@ -7,9 +7,6 @@ Required properties:
 - interrupts: Should contain lcdif interrupts
 - display : phandle to display node (see below for details)
 
-Optional properties:
-- panel-enable-gpios : Should specify the gpio for panel enable
-
 * display node
 
 Required properties:
@@ -25,7 +22,6 @@ lcdif at 80030000 {
 	compatible = "fsl,imx28-lcdif";
 	reg = <0x80030000 2000>;
 	interrupts = <38 86>;
-	panel-enable-gpios = <&gpio3 30 0>;
 
 	display: display {
 		bits-per-pixel = <32>;
diff --git a/arch/arm/boot/dts/imx23-evk.dts b/arch/arm/boot/dts/imx23-evk.dts
index 7880e17..da0588a 100644
--- a/arch/arm/boot/dts/imx23-evk.dts
+++ b/arch/arm/boot/dts/imx23-evk.dts
@@ -59,7 +59,7 @@
 			lcdif at 80030000 {
 				pinctrl-names = "default";
 				pinctrl-0 = <&lcdif_24bit_pins_a>;
-				panel-enable-gpios = <&gpio1 18 0>;
+				lcd-supply = <&reg_lcd_3v3>;
 				display = <&display>;
 				status = "okay";
 
@@ -120,6 +120,15 @@
 			regulator-max-microvolt = <3300000>;
 			gpio = <&gpio1 29 0>;
 		};
+
+		reg_lcd_3v3: lcd-3v3 {
+			compatible = "regulator-fixed";
+			regulator-name = "lcd-3v3";
+			regulator-min-microvolt = <3300000>;
+			regulator-max-microvolt = <3300000>;
+			gpio = <&gpio1 18 0>;
+			enable-active-high;
+		};
 	};
 
 	backlight {
diff --git a/arch/arm/boot/dts/imx28-evk.dts b/arch/arm/boot/dts/imx28-evk.dts
index 2d4ea3b..3637bf3 100644
--- a/arch/arm/boot/dts/imx28-evk.dts
+++ b/arch/arm/boot/dts/imx28-evk.dts
@@ -123,7 +123,7 @@
 				pinctrl-names = "default";
 				pinctrl-0 = <&lcdif_24bit_pins_a
 					     &lcdif_pins_evk>;
-				panel-enable-gpios = <&gpio3 30 0>;
+				lcd-supply = <&reg_lcd_3v3>;
 				display = <&display>;
 				status = "okay";
 
@@ -310,6 +310,15 @@
 			gpio = <&gpio3 8 0>;
 			enable-active-high;
 		};
+
+		reg_lcd_3v3: lcd-3v3 {
+			compatible = "regulator-fixed";
+			regulator-name = "lcd-3v3";
+			regulator-min-microvolt = <3300000>;
+			regulator-max-microvolt = <3300000>;
+			gpio = <&gpio3 30 0>;
+			enable-active-high;
+		};
 	};
 
 	sound {
diff --git a/drivers/video/mxsfb.c b/drivers/video/mxsfb.c
index eac7c1a..1b2c26d 100644
--- a/drivers/video/mxsfb.c
+++ b/drivers/video/mxsfb.c
@@ -42,7 +42,6 @@
 #include <linux/module.h>
 #include <linux/kernel.h>
 #include <linux/of_device.h>
-#include <linux/of_gpio.h>
 #include <video/of_display_timing.h>
 #include <linux/platform_device.h>
 #include <linux/clk.h>
@@ -50,6 +49,7 @@
 #include <linux/io.h>
 #include <linux/pinctrl/consumer.h>
 #include <linux/fb.h>
+#include <linux/regulator/consumer.h>
 #include <video/videomode.h>
 
 #define REG_SET	4
@@ -179,6 +179,7 @@ struct mxsfb_info {
 	unsigned dotclk_delay;
 	const struct mxsfb_devdata *devdata;
 	u32 sync;
+	struct regulator *reg_lcd;
 };
 
 #define mxsfb_is_v3(host) (host->devdata->ipversion == 3)
@@ -338,9 +339,19 @@ static void mxsfb_enable_controller(struct fb_info *fb_info)
 {
 	struct mxsfb_info *host = to_imxfb_host(fb_info);
 	u32 reg;
+	int ret;
 
 	dev_dbg(&host->pdev->dev, "%s\n", __func__);
 
+	if (host->reg_lcd) {
+		ret = regulator_enable(host->reg_lcd);
+		if (ret) {
+			dev_err(&host->pdev->dev,
+				"lcd regulator enable failed:	%d\n", ret);
+			return;
+		}
+	}
+
 	clk_prepare_enable(host->clk);
 	clk_set_rate(host->clk, PICOS2KHZ(fb_info->var.pixclock) * 1000U);
 
@@ -362,6 +373,7 @@ static void mxsfb_disable_controller(struct fb_info *fb_info)
 	struct mxsfb_info *host = to_imxfb_host(fb_info);
 	unsigned loop;
 	u32 reg;
+	int ret;
 
 	dev_dbg(&host->pdev->dev, "%s\n", __func__);
 
@@ -385,6 +397,13 @@ static void mxsfb_disable_controller(struct fb_info *fb_info)
 	clk_disable_unprepare(host->clk);
 
 	host->enabled = 0;
+
+	if (host->reg_lcd) {
+		ret = regulator_disable(host->reg_lcd);
+		if (ret)
+			dev_err(&host->pdev->dev,
+				"lcd regulator disable failed: %d\n", ret);
+	}
 }
 
 static int mxsfb_set_par(struct fb_info *fb_info)
@@ -859,8 +878,6 @@ static int mxsfb_probe(struct platform_device *pdev)
 	struct fb_info *fb_info;
 	struct fb_modelist *modelist;
 	struct pinctrl *pinctrl;
-	int panel_enable;
-	enum of_gpio_flags flags;
 	int ret;
 
 	if (of_id)
@@ -904,21 +921,9 @@ static int mxsfb_probe(struct platform_device *pdev)
 		goto fb_release;
 	}
 
-	panel_enable = of_get_named_gpio_flags(pdev->dev.of_node,
-					       "panel-enable-gpios", 0, &flags);
-	if (gpio_is_valid(panel_enable)) {
-		unsigned long f = GPIOF_OUT_INIT_HIGH;
-		if (flags == OF_GPIO_ACTIVE_LOW)
-			f = GPIOF_OUT_INIT_LOW;
-		ret = devm_gpio_request_one(&pdev->dev, panel_enable,
-					    f, "panel-enable");
-		if (ret) {
-			dev_err(&pdev->dev,
-				"failed to request gpio %d: %d\n",
-				panel_enable, ret);
-			goto fb_release;
-		}
-	}
+	host->reg_lcd = devm_regulator_get(&pdev->dev, "lcd");
+	if (IS_ERR(host->reg_lcd))
+		host->reg_lcd = NULL;
 
 	fb_info->pseudo_palette = devm_kzalloc(&pdev->dev, sizeof(u32) * 16,
 					       GFP_KERNEL);
-- 
1.7.9.5



From broonie at opensource.wolfsonmicro.com  Sun Apr  7 15:21:58 2013
From: broonie at opensource.wolfsonmicro.com (Mark Brown)
Date: Sun, 7 Apr 2013 20:21:58 +0100
Subject: [PATCH] regulator: mc13783: Add device tree probe support
In-Reply-To: <1365354131-9770-1-git-send-email-shc_work@mail.ru>
References: <1365354131-9770-1-git-send-email-shc_work@mail.ru>
Message-ID: <20130407192157.GQ6597@opensource.wolfsonmicro.com>

On Sun, Apr 07, 2013 at 09:02:11PM +0400, Alexander Shiyan wrote:
> Patch adds device tree probe support for mc13783-regulator driver.

I'd expect to see a document describing the binding for any new binding.

> +	if (num_parsed != num_regulators) {
> +		dev_warn(&pdev->dev,
> +		"parsed %d != regulators %d - check your device tree!\n",
> +			num_parsed, num_regulators);
>  
> -		init_data = &pdata->regulators[i];
> -		desc = &mc13783_regulators[init_data->id].desc;
> +		num_regulators = num_parsed;
> +		priv->num_regulators = num_regulators;

Why is this something we warn about?  Users should be able to omit
unused regulators, no point in adding nodes that don't have any real
information.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130407/e27f66d2/attachment.sig>

From mpa at pengutronix.de  Sun Apr  7 15:25:12 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Sun,  7 Apr 2013 21:25:12 +0200
Subject: [PATCH v2 02/11] ASoC: imx-pcm-dma: Add support for DMA init by
 device node
In-Reply-To: <1365362721-3731-1-git-send-email-mpa@pengutronix.de>
References: <1365362721-3731-1-git-send-email-mpa@pengutronix.de>
Message-ID: <1365362721-3731-3-git-send-email-mpa@pengutronix.de>

Add support for DMA initialization using devicetree node.

This patch adds two fields to imx_pcm_dma_params to pass device node
information from other imx drivers to this one. If the dma_node is set,
this driver tries to initialize a PCM DMA substream based on the
dma_node and name.

Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
---

Notes:
    Changes in v2:
     - Use snd_dmaengine_generic_pcm_open instead of of_snd_dmaengine_pcm_open.
     - Pass the device in imx_pcm_dma_params.

 sound/soc/fsl/imx-pcm-dma.c | 31 ++++++++++++++++++++-----------
 sound/soc/fsl/imx-pcm.h     |  6 ++++++
 2 files changed, 26 insertions(+), 11 deletions(-)

diff --git a/sound/soc/fsl/imx-pcm-dma.c b/sound/soc/fsl/imx-pcm-dma.c
index 500f8ce..2d15ca5 100644
--- a/sound/soc/fsl/imx-pcm-dma.c
+++ b/sound/soc/fsl/imx-pcm-dma.c
@@ -101,26 +101,35 @@ static int snd_imx_open(struct snd_pcm_substream *substream)
 {
 	struct snd_soc_pcm_runtime *rtd = substream->private_data;
 	struct imx_pcm_dma_params *dma_params;
-	struct imx_dma_data *dma_data;
+	struct imx_dma_data *dma_data = NULL;
 	int ret;
 
 	snd_soc_set_runtime_hwparams(substream, &snd_imx_hardware);
 
 	dma_params = snd_soc_dai_get_dma_data(rtd->cpu_dai, substream);
 
-	dma_data = kzalloc(sizeof(*dma_data), GFP_KERNEL);
-	if (!dma_data)
-		return -ENOMEM;
+	if (dma_params->dma_client_dev) {
+		ret = snd_dmaengine_generic_pcm_open(substream,
+				dma_params->dma_client_dev,
+				dma_params->dma_req_name);
+		if (ret)
+			return ret;
+	} else {
+		dma_data = kzalloc(sizeof(*dma_data), GFP_KERNEL);
+		if (!dma_data)
+			return -ENOMEM;
 
-	dma_data->peripheral_type = dma_params->shared_peripheral ?
+		dma_data->peripheral_type = dma_params->shared_peripheral ?
 					IMX_DMATYPE_SSI_SP : IMX_DMATYPE_SSI;
-	dma_data->priority = DMA_PRIO_HIGH;
-	dma_data->dma_request = dma_params->dma;
+		dma_data->priority = DMA_PRIO_HIGH;
+		dma_data->dma_request = dma_params->dma;
 
-	ret = snd_dmaengine_pcm_open(substream, filter, dma_data);
-	if (ret) {
-		kfree(dma_data);
-		return ret;
+		ret = snd_dmaengine_pcm_open(substream, filter, dma_data);
+
+		if (ret) {
+			kfree(dma_data);
+			return ret;
+		}
 	}
 
 	snd_dmaengine_pcm_set_data(substream, dma_data);
diff --git a/sound/soc/fsl/imx-pcm.h b/sound/soc/fsl/imx-pcm.h
index 5ae13a1..ff0cfdf 100644
--- a/sound/soc/fsl/imx-pcm.h
+++ b/sound/soc/fsl/imx-pcm.h
@@ -23,6 +23,12 @@ struct imx_pcm_dma_params {
 	unsigned long dma_addr;
 	int burstsize;
 	bool shared_peripheral;	/* The peripheral is on SPBA bus */
+
+	/* If set, the DMA channel is requested using the generic handler while
+	 * ignoring fields 'dma' and 'shared_peripheral'. They have to be set
+	 * in devicetree according to the DMA Controller devicetree bindings. */
+	struct device *dma_client_dev;
+	const char *dma_req_name; /* DMA Request name from devicetree */
 };
 
 int snd_imx_pcm_mmap(struct snd_pcm_substream *substream,
-- 
1.8.1.5



From mpa at pengutronix.de  Sun Apr  7 15:25:14 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Sun,  7 Apr 2013 21:25:14 +0200
Subject: [PATCH v2 04/11] ASoC: fsl-ssi: Add SACNT definitions
In-Reply-To: <1365362721-3731-1-git-send-email-mpa@pengutronix.de>
References: <1365362721-3731-1-git-send-email-mpa@pengutronix.de>
Message-ID: <1365362721-3731-5-git-send-email-mpa@pengutronix.de>

Add definitions for AC97 control register.

Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
---
 sound/soc/fsl/fsl_ssi.h | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/sound/soc/fsl/fsl_ssi.h b/sound/soc/fsl/fsl_ssi.h
index 2173000..e6b9a69 100644
--- a/sound/soc/fsl/fsl_ssi.h
+++ b/sound/soc/fsl/fsl_ssi.h
@@ -196,5 +196,13 @@ struct ccsr_ssi {
 #define CCSR_SSI_SOR_WAIT(x) (((x) & 3) << CCSR_SSI_SOR_WAIT_SHIFT)
 #define CCSR_SSI_SOR_SYNRST 		0x00000001
 
+#define CCSR_SSI_SACNT_FRDIV(x)		(((x) & 0x3f) << 5)
+#define CCSR_SSI_SACNT_WR		0x00000010
+#define CCSR_SSI_SACNT_RD		0x00000008
+#define CCSR_SSI_SACNT_RDWR_MASK	0x00000018
+#define CCSR_SSI_SACNT_TIF		0x00000004
+#define CCSR_SSI_SACNT_FV		0x00000002
+#define CCSR_SSI_SACNT_AC97EN		0x00000001
+
 #endif
 
-- 
1.8.1.5



From mpa at pengutronix.de  Sun Apr  7 15:25:13 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Sun,  7 Apr 2013 21:25:13 +0200
Subject: [PATCH v2 03/11] ASoC: imx-pcm-fiq: Introduce pcm-fiq-params
In-Reply-To: <1365362721-3731-1-git-send-email-mpa@pengutronix.de>
References: <1365362721-3731-1-git-send-email-mpa@pengutronix.de>
Message-ID: <1365362721-3731-4-git-send-email-mpa@pengutronix.de>

Cleaner parameter passing for imx-pcm-fiq. Create a seperated fiq-params
struct to pass all arguments.

Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
---
 sound/soc/fsl/imx-pcm-fiq.c | 14 +++++++-------
 sound/soc/fsl/imx-pcm.h     |  9 +++++++++
 sound/soc/fsl/imx-ssi.c     |  7 ++++++-
 sound/soc/fsl/imx-ssi.h     |  1 +
 4 files changed, 23 insertions(+), 8 deletions(-)

diff --git a/sound/soc/fsl/imx-pcm-fiq.c b/sound/soc/fsl/imx-pcm-fiq.c
index 920f945..995ed35 100644
--- a/sound/soc/fsl/imx-pcm-fiq.c
+++ b/sound/soc/fsl/imx-pcm-fiq.c
@@ -283,7 +283,7 @@ static struct snd_soc_platform_driver imx_soc_platform_fiq = {
 
 int imx_pcm_fiq_init(struct platform_device *pdev)
 {
-	struct imx_ssi *ssi = platform_get_drvdata(pdev);
+	struct imx_pcm_fiq_params *params = platform_get_drvdata(pdev);
 	int ret;
 
 	ret = claim_fiq(&fh);
@@ -292,15 +292,15 @@ int imx_pcm_fiq_init(struct platform_device *pdev)
 		return ret;
 	}
 
-	mxc_set_irq_fiq(ssi->irq, 1);
-	ssi_irq = ssi->irq;
+	mxc_set_irq_fiq(params->irq, 1);
+	ssi_irq = params->irq;
 
-	imx_pcm_fiq = ssi->irq;
+	imx_pcm_fiq = params->irq;
 
-	imx_ssi_fiq_base = (unsigned long)ssi->base;
+	imx_ssi_fiq_base = (unsigned long)params->base;
 
-	ssi->dma_params_tx.burstsize = 4;
-	ssi->dma_params_rx.burstsize = 6;
+	params->dma_params_tx->burstsize = 4;
+	params->dma_params_rx->burstsize = 6;
 
 	ret = snd_soc_register_platform(&pdev->dev, &imx_soc_platform_fiq);
 	if (ret)
diff --git a/sound/soc/fsl/imx-pcm.h b/sound/soc/fsl/imx-pcm.h
index ff0cfdf..f568a0e 100644
--- a/sound/soc/fsl/imx-pcm.h
+++ b/sound/soc/fsl/imx-pcm.h
@@ -31,6 +31,15 @@ struct imx_pcm_dma_params {
 	const char *dma_req_name; /* DMA Request name from devicetree */
 };
 
+struct imx_pcm_fiq_params {
+	int irq;
+	void __iomem *base;
+
+	/* Pointer to original ssi driver to setup tx rx sizes */
+	struct imx_pcm_dma_params *dma_params_tx;
+	struct imx_pcm_dma_params *dma_params_rx;
+};
+
 int snd_imx_pcm_mmap(struct snd_pcm_substream *substream,
 		     struct vm_area_struct *vma);
 int imx_pcm_new(struct snd_soc_pcm_runtime *rtd);
diff --git a/sound/soc/fsl/imx-ssi.c b/sound/soc/fsl/imx-ssi.c
index 96e24a3..93f7562 100644
--- a/sound/soc/fsl/imx-ssi.c
+++ b/sound/soc/fsl/imx-ssi.c
@@ -608,7 +608,12 @@ static int imx_ssi_probe(struct platform_device *pdev)
 		goto failed_pdev_fiq_alloc;
 	}
 
-	platform_set_drvdata(ssi->soc_platform_pdev_fiq, ssi);
+	ssi->fiq_params.irq = ssi->irq;
+	ssi->fiq_params.base = ssi->base;
+	ssi->fiq_params.dma_params_rx = &ssi->dma_params_rx;
+	ssi->fiq_params.dma_params_tx = &ssi->dma_params_tx;
+
+	platform_set_drvdata(ssi->soc_platform_pdev_fiq, &ssi->fiq_params);
 	ret = platform_device_add(ssi->soc_platform_pdev_fiq);
 	if (ret) {
 		dev_err(&pdev->dev, "failed to add platform device\n");
diff --git a/sound/soc/fsl/imx-ssi.h b/sound/soc/fsl/imx-ssi.h
index dc114bd..90a45ef 100644
--- a/sound/soc/fsl/imx-ssi.h
+++ b/sound/soc/fsl/imx-ssi.h
@@ -206,6 +206,7 @@ struct imx_ssi {
 
 	struct imx_pcm_dma_params	dma_params_rx;
 	struct imx_pcm_dma_params	dma_params_tx;
+	struct imx_pcm_fiq_params	fiq_params;
 
 	int enabled;
 
-- 
1.8.1.5



From mpa at pengutronix.de  Sun Apr  7 15:25:17 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Sun,  7 Apr 2013 21:25:17 +0200
Subject: [PATCH v2 07/11] ARM: imx: Export ac97 reset functions
In-Reply-To: <1365362721-3731-1-git-send-email-mpa@pengutronix.de>
References: <1365362721-3731-1-git-send-email-mpa@pengutronix.de>
Message-ID: <1365362721-3731-8-git-send-email-mpa@pengutronix.de>

Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
---
 arch/arm/mach-imx/mach-pca100.c | 7 +++++--
 arch/arm/mach-imx/mach-pcm043.c | 7 +++++--
 2 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-imx/mach-pca100.c b/arch/arm/mach-imx/mach-pca100.c
index b8b15bb..68badf8 100644
--- a/arch/arm/mach-imx/mach-pca100.c
+++ b/arch/arm/mach-imx/mach-pca100.c
@@ -22,6 +22,7 @@
 #include <linux/i2c.h>
 #include <linux/i2c/at24.h>
 #include <linux/dma-mapping.h>
+#include <linux/export.h>
 #include <linux/spi/spi.h>
 #include <linux/spi/eeprom.h>
 #include <linux/irq.h>
@@ -208,7 +209,7 @@ static const struct spi_imx_master pca100_spi0_data __initconst = {
 	.num_chipselect = ARRAY_SIZE(pca100_spi_cs),
 };
 
-static void pca100_ac97_warm_reset(struct snd_ac97 *ac97)
+void pca100_ac97_warm_reset(struct snd_ac97 *ac97)
 {
 	mxc_gpio_mode(GPIO_PORTC | 20 | GPIO_GPIO | GPIO_OUT);
 	gpio_set_value(GPIO_PORTC + 20, 1);
@@ -217,8 +218,9 @@ static void pca100_ac97_warm_reset(struct snd_ac97 *ac97)
 	mxc_gpio_mode(PC20_PF_SSI1_FS);
 	msleep(2);
 }
+EXPORT_SYMBOL(pca100_ac97_warm_reset);
 
-static void pca100_ac97_cold_reset(struct snd_ac97 *ac97)
+void pca100_ac97_cold_reset(struct snd_ac97 *ac97)
 {
 	mxc_gpio_mode(GPIO_PORTC | 20 | GPIO_GPIO | GPIO_OUT);  /* FS */
 	gpio_set_value(GPIO_PORTC + 20, 0);
@@ -232,6 +234,7 @@ static void pca100_ac97_cold_reset(struct snd_ac97 *ac97)
 	mxc_gpio_mode(PC22_PF_SSI1_TXD);
 	msleep(2);
 }
+EXPORT_SYMBOL(pca100_ac97_cold_reset);
 
 static const struct imx_ssi_platform_data pca100_ssi_pdata __initconst = {
 	.ac97_reset		= pca100_ac97_cold_reset,
diff --git a/arch/arm/mach-imx/mach-pcm043.c b/arch/arm/mach-imx/mach-pcm043.c
index 8ed533f..4f318ca 100644
--- a/arch/arm/mach-imx/mach-pcm043.c
+++ b/arch/arm/mach-imx/mach-pcm043.c
@@ -27,6 +27,7 @@
 #include <linux/i2c/at24.h>
 #include <linux/usb/otg.h>
 #include <linux/usb/ulpi.h>
+#include <linux/export.h>
 
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
@@ -217,7 +218,7 @@ static iomux_v3_cfg_t pcm043_pads[] = {
 #define SD1_GPIO_WP	IMX_GPIO_NR(2, 23)
 #define SD1_GPIO_CD	IMX_GPIO_NR(2, 24)
 
-static void pcm043_ac97_warm_reset(struct snd_ac97 *ac97)
+void pcm043_ac97_warm_reset(struct snd_ac97 *ac97)
 {
 	iomux_v3_cfg_t txfs_gpio = MX35_PAD_STXFS4__GPIO2_31;
 	iomux_v3_cfg_t txfs = MX35_PAD_STXFS4__AUDMUX_AUD4_TXFS;
@@ -239,8 +240,9 @@ static void pcm043_ac97_warm_reset(struct snd_ac97 *ac97)
 	gpio_free(AC97_GPIO_TXFS);
 	mxc_iomux_v3_setup_pad(txfs);
 }
+EXPORT_SYMBOL(pcm043_ac97_warm_reset);
 
-static void pcm043_ac97_cold_reset(struct snd_ac97 *ac97)
+void pcm043_ac97_cold_reset(struct snd_ac97 *ac97)
 {
 	iomux_v3_cfg_t txfs_gpio = MX35_PAD_STXFS4__GPIO2_31;
 	iomux_v3_cfg_t txfs = MX35_PAD_STXFS4__AUDMUX_AUD4_TXFS;
@@ -286,6 +288,7 @@ err1:
 		printk("%s failed with %d\n", __func__, ret);
 	mdelay(1);
 }
+EXPORT_SYMBOL(pcm043_ac97_cold_reset);
 
 static const struct imx_ssi_platform_data pcm043_ssi_pdata __initconst = {
 	.ac97_reset = pcm043_ac97_cold_reset,
-- 
1.8.1.5



From mpa at pengutronix.de  Sun Apr  7 15:25:20 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Sun,  7 Apr 2013 21:25:20 +0200
Subject: [PATCH v2 10/11] ASoC: fsl: Move fsl-ssi binding doc to sound/
In-Reply-To: <1365362721-3731-1-git-send-email-mpa@pengutronix.de>
References: <1365362721-3731-1-git-send-email-mpa@pengutronix.de>
Message-ID: <1365362721-3731-11-git-send-email-mpa@pengutronix.de>

fsl-ssi was located in powerpc/fsl/ssi.txt. This is no powerpc specific
device, so it should be moved to sound/ as it connects to differen audio
codecs.

Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
---
 .../devicetree/bindings/powerpc/fsl/ssi.txt        | 73 ----------------------
 .../devicetree/bindings/sound/fsl,ssi.txt          | 73 ++++++++++++++++++++++
 2 files changed, 73 insertions(+), 73 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/powerpc/fsl/ssi.txt
 create mode 100644 Documentation/devicetree/bindings/sound/fsl,ssi.txt

diff --git a/Documentation/devicetree/bindings/powerpc/fsl/ssi.txt b/Documentation/devicetree/bindings/powerpc/fsl/ssi.txt
deleted file mode 100644
index 5ff76c9..0000000
--- a/Documentation/devicetree/bindings/powerpc/fsl/ssi.txt
+++ /dev/null
@@ -1,73 +0,0 @@
-Freescale Synchronous Serial Interface
-
-The SSI is a serial device that communicates with audio codecs.  It can
-be programmed in AC97, I2S, left-justified, or right-justified modes.
-
-Required properties:
-- compatible:       Compatible list, contains "fsl,ssi".
-- cell-index:       The SSI, <0> = SSI1, <1> = SSI2, and so on.
-- reg:              Offset and length of the register set for the device.
-- 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.  This should be
-                    encoded based on the information in section 2)
-                    depending on the type of interrupt controller you
-                    have.
-- interrupt-parent: The phandle for the interrupt controller that
-                    services interrupts for this device.
-- fsl,mode:         The operating mode for the SSI interface.
-                    "i2s-slave" - I2S mode, SSI is clock slave
-                    "i2s-master" - I2S mode, SSI is clock master
-                    "lj-slave" - left-justified mode, SSI is clock slave
-                    "lj-master" - l.j. mode, SSI is clock master
-                    "rj-slave" - right-justified mode, SSI is clock slave
-                    "rj-master" - r.j., SSI is clock master
-                    "ac97-slave" - AC97 mode, SSI is clock slave
-                    "ac97-master" - AC97 mode, SSI is clock master
-- fsl,playback-dma: Phandle to a node for the DMA channel to use for
-                    playback of audio.  This is typically dictated by SOC
-                    design.  See the notes below.
-- fsl,capture-dma:  Phandle to a node for the DMA channel to use for
-                    capture (recording) of audio.  This is typically dictated
-                    by SOC design.  See the notes below.
-- fsl,fifo-depth:   The number of elements in the transmit and receive FIFOs.
-                    This number is the maximum allowed value for SFCSR[TFWM0].
-- fsl,ssi-asynchronous:
-                    If specified, the SSI is to be programmed in asynchronous
-                    mode.  In this mode, pins SRCK, STCK, SRFS, and STFS must
-                    all be connected to valid signals.  In synchronous mode,
-                    SRCK and SRFS are ignored.  Asynchronous mode allows
-                    playback and capture to use different sample sizes and
-                    sample rates.  Some drivers may require that SRCK and STCK
-                    be connected together, and SRFS and STFS be connected
-                    together.  This would still allow different sample sizes,
-                    but not different sample rates.
-
-Optional properties:
-- codec-handle:     Phandle to a 'codec' node that defines an audio
-                    codec connected to this SSI.  This node is typically
-                    a child of an I2C or other control node.
-
-Child 'codec' node required properties:
-- compatible:       Compatible list, contains the name of the codec
-
-Child 'codec' node optional properties:
-- clock-frequency:  The frequency of the input clock, which typically comes
-                    from an on-board dedicated oscillator.
-
-Notes on fsl,playback-dma and fsl,capture-dma:
-
-On SOCs that have an SSI, specific DMA channels are hard-wired for playback
-and capture.  On the MPC8610, for example, SSI1 must use DMA channel 0 for
-playback and DMA channel 1 for capture.  SSI2 must use DMA channel 2 for
-playback and DMA channel 3 for capture.  The developer can choose which
-DMA controller to use, but the channels themselves are hard-wired.  The
-purpose of these two properties is to represent this hardware design.
-
-The device tree nodes for the DMA channels that are referenced by
-"fsl,playback-dma" and "fsl,capture-dma" must be marked as compatible with
-"fsl,ssi-dma-channel".  The SOC-specific compatible string (e.g.
-"fsl,mpc8610-dma-channel") can remain.  If these nodes are left as
-"fsl,elo-dma-channel" or "fsl,eloplus-dma-channel", then the generic Elo DMA
-drivers (fsldma) will attempt to use them, and it will conflict with the
-sound drivers.
diff --git a/Documentation/devicetree/bindings/sound/fsl,ssi.txt b/Documentation/devicetree/bindings/sound/fsl,ssi.txt
new file mode 100644
index 0000000..5ff76c9
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/fsl,ssi.txt
@@ -0,0 +1,73 @@
+Freescale Synchronous Serial Interface
+
+The SSI is a serial device that communicates with audio codecs.  It can
+be programmed in AC97, I2S, left-justified, or right-justified modes.
+
+Required properties:
+- compatible:       Compatible list, contains "fsl,ssi".
+- cell-index:       The SSI, <0> = SSI1, <1> = SSI2, and so on.
+- reg:              Offset and length of the register set for the device.
+- 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.  This should be
+                    encoded based on the information in section 2)
+                    depending on the type of interrupt controller you
+                    have.
+- interrupt-parent: The phandle for the interrupt controller that
+                    services interrupts for this device.
+- fsl,mode:         The operating mode for the SSI interface.
+                    "i2s-slave" - I2S mode, SSI is clock slave
+                    "i2s-master" - I2S mode, SSI is clock master
+                    "lj-slave" - left-justified mode, SSI is clock slave
+                    "lj-master" - l.j. mode, SSI is clock master
+                    "rj-slave" - right-justified mode, SSI is clock slave
+                    "rj-master" - r.j., SSI is clock master
+                    "ac97-slave" - AC97 mode, SSI is clock slave
+                    "ac97-master" - AC97 mode, SSI is clock master
+- fsl,playback-dma: Phandle to a node for the DMA channel to use for
+                    playback of audio.  This is typically dictated by SOC
+                    design.  See the notes below.
+- fsl,capture-dma:  Phandle to a node for the DMA channel to use for
+                    capture (recording) of audio.  This is typically dictated
+                    by SOC design.  See the notes below.
+- fsl,fifo-depth:   The number of elements in the transmit and receive FIFOs.
+                    This number is the maximum allowed value for SFCSR[TFWM0].
+- fsl,ssi-asynchronous:
+                    If specified, the SSI is to be programmed in asynchronous
+                    mode.  In this mode, pins SRCK, STCK, SRFS, and STFS must
+                    all be connected to valid signals.  In synchronous mode,
+                    SRCK and SRFS are ignored.  Asynchronous mode allows
+                    playback and capture to use different sample sizes and
+                    sample rates.  Some drivers may require that SRCK and STCK
+                    be connected together, and SRFS and STFS be connected
+                    together.  This would still allow different sample sizes,
+                    but not different sample rates.
+
+Optional properties:
+- codec-handle:     Phandle to a 'codec' node that defines an audio
+                    codec connected to this SSI.  This node is typically
+                    a child of an I2C or other control node.
+
+Child 'codec' node required properties:
+- compatible:       Compatible list, contains the name of the codec
+
+Child 'codec' node optional properties:
+- clock-frequency:  The frequency of the input clock, which typically comes
+                    from an on-board dedicated oscillator.
+
+Notes on fsl,playback-dma and fsl,capture-dma:
+
+On SOCs that have an SSI, specific DMA channels are hard-wired for playback
+and capture.  On the MPC8610, for example, SSI1 must use DMA channel 0 for
+playback and DMA channel 1 for capture.  SSI2 must use DMA channel 2 for
+playback and DMA channel 3 for capture.  The developer can choose which
+DMA controller to use, but the channels themselves are hard-wired.  The
+purpose of these two properties is to represent this hardware design.
+
+The device tree nodes for the DMA channels that are referenced by
+"fsl,playback-dma" and "fsl,capture-dma" must be marked as compatible with
+"fsl,ssi-dma-channel".  The SOC-specific compatible string (e.g.
+"fsl,mpc8610-dma-channel") can remain.  If these nodes are left as
+"fsl,elo-dma-channel" or "fsl,eloplus-dma-channel", then the generic Elo DMA
+drivers (fsldma) will attempt to use them, and it will conflict with the
+sound drivers.
-- 
1.8.1.5



From mpa at pengutronix.de  Sun Apr  7 15:25:19 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Sun,  7 Apr 2013 21:25:19 +0200
Subject: [PATCH v2 09/11] ASoC: fsl: Kconfig: Use fsl-ssi for phycore-ac97
In-Reply-To: <1365362721-3731-1-git-send-email-mpa@pengutronix.de>
References: <1365362721-3731-1-git-send-email-mpa@pengutronix.de>
Message-ID: <1365362721-3731-10-git-send-email-mpa@pengutronix.de>

Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
---
 sound/soc/fsl/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig
index 3b98159..5ace408 100644
--- a/sound/soc/fsl/Kconfig
+++ b/sound/soc/fsl/Kconfig
@@ -153,7 +153,7 @@ config SND_SOC_PHYCORE_AC97
 	select SND_SOC_WM9712
 	select SND_SOC_IMX_PCM_FIQ
 	select SND_SOC_IMX_AUDMUX
-	select SND_SOC_IMX_SSI
+	select SND_SOC_FSL_SSI
 	help
 	  Say Y if you want to add support for SoC audio on Phytec phyCORE
 	  and phyCARD boards in AC97 mode
-- 
1.8.1.5



From mpa at pengutronix.de  Sun Apr  7 15:25:16 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Sun,  7 Apr 2013 21:25:16 +0200
Subject: [PATCH v2 06/11] ASoC: fsl-ssi: Setup generic imx dma params
In-Reply-To: <1365362721-3731-1-git-send-email-mpa@pengutronix.de>
References: <1365362721-3731-1-git-send-email-mpa@pengutronix.de>
Message-ID: <1365362721-3731-7-git-send-email-mpa@pengutronix.de>

Use device pointer as parameter for imx-pcm-dma. This allows usage of
the generic DMA DT bindings.

Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
---
 sound/soc/fsl/fsl_ssi.c | 19 +++++--------------
 1 file changed, 5 insertions(+), 14 deletions(-)

diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index afb5a23..bb9a1e0 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -742,7 +742,6 @@ static int fsl_ssi_probe(struct platform_device *pdev)
 		ssi_private->fifo_depth = 8;
 
 	if (of_device_is_compatible(pdev->dev.of_node, "fsl,imx21-ssi")) {
-		u32 dma_events[2];
 		ssi_private->ssi_on_imx = true;
 
 		ssi_private->clk = clk_get(&pdev->dev, NULL);
@@ -765,18 +764,11 @@ static int fsl_ssi_probe(struct platform_device *pdev)
 			ssi_private->ssi_phys + offsetof(struct ccsr_ssi, stx0);
 		ssi_private->dma_params_rx.dma_addr =
 			ssi_private->ssi_phys + offsetof(struct ccsr_ssi, srx0);
-		/*
-		 * TODO: This is a temporary solution and should be changed
-		 * to use generic DMA binding later when the helplers get in.
-		 */
-		ret = of_property_read_u32_array(pdev->dev.of_node,
-					"fsl,ssi-dma-events", dma_events, 2);
-		if (ret) {
-			dev_err(&pdev->dev, "could not get dma events\n");
-			goto error_clk;
-		}
-		ssi_private->dma_params_tx.dma = dma_events[0];
-		ssi_private->dma_params_rx.dma = dma_events[1];
+
+		ssi_private->dma_params_rx.dma_client_dev = &pdev->dev;
+		ssi_private->dma_params_rx.dma_req_name = "rx";
+		ssi_private->dma_params_tx.dma_client_dev = &pdev->dev;
+		ssi_private->dma_params_tx.dma_req_name = "tx";
 
 		ssi_private->dma_params_tx.shared_peripheral =
 				of_device_is_compatible(of_get_parent(np),
@@ -887,7 +879,6 @@ error_dev:
 	dev_set_drvdata(&pdev->dev, NULL);
 	device_remove_file(&pdev->dev, dev_attr);
 
-error_clk:
 	if (ssi_private->ssi_on_imx) {
 		clk_disable_unprepare(ssi_private->clk);
 		clk_put(ssi_private->clk);
-- 
1.8.1.5



From mpa at pengutronix.de  Sun Apr  7 15:25:21 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Sun,  7 Apr 2013 21:25:21 +0200
Subject: [PATCH v2 11/11] ASoC: fsl: Update fsl-ssi binding doc
In-Reply-To: <1365362721-3731-1-git-send-email-mpa@pengutronix.de>
References: <1365362721-3731-1-git-send-email-mpa@pengutronix.de>
Message-ID: <1365362721-3731-12-git-send-email-mpa@pengutronix.de>

Update the fsl-ssi bindings. DMA is no required property anymore and
uses the generic DMA bindings. imx-fiq is a new alternative to DMA

Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
---
 Documentation/devicetree/bindings/sound/fsl,ssi.txt | 13 +++++++------
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/Documentation/devicetree/bindings/sound/fsl,ssi.txt b/Documentation/devicetree/bindings/sound/fsl,ssi.txt
index 5ff76c9..46282ec 100644
--- a/Documentation/devicetree/bindings/sound/fsl,ssi.txt
+++ b/Documentation/devicetree/bindings/sound/fsl,ssi.txt
@@ -24,12 +24,6 @@ Required properties:
                     "rj-master" - r.j., SSI is clock master
                     "ac97-slave" - AC97 mode, SSI is clock slave
                     "ac97-master" - AC97 mode, SSI is clock master
-- fsl,playback-dma: Phandle to a node for the DMA channel to use for
-                    playback of audio.  This is typically dictated by SOC
-                    design.  See the notes below.
-- fsl,capture-dma:  Phandle to a node for the DMA channel to use for
-                    capture (recording) of audio.  This is typically dictated
-                    by SOC design.  See the notes below.
 - fsl,fifo-depth:   The number of elements in the transmit and receive FIFOs.
                     This number is the maximum allowed value for SFCSR[TFWM0].
 - fsl,ssi-asynchronous:
@@ -43,10 +37,17 @@ Required properties:
                     together.  This would still allow different sample sizes,
                     but not different sample rates.
 
+Note that either dmas, dma-names or fsl,imx-fiq are required.
+
 Optional properties:
 - codec-handle:     Phandle to a 'codec' node that defines an audio
                     codec connected to this SSI.  This node is typically
                     a child of an I2C or other control node.
+- dmas:		    Generic dma devicetree binding as described in
+		    Documentation/devicetree/bindings/dma/dma.txt.
+- dma-names:	    Two dmas have to be defined, "tx" and "rx", if fsl,imx-fiq
+		    is not defined.
+- fsl,imx-fiq:	    Bool property. Use imx-pcm-fiq instead of imx-pcm-dma.
 
 Child 'codec' node required properties:
 - compatible:       Compatible list, contains the name of the codec
-- 
1.8.1.5



From mpa at pengutronix.de  Sun Apr  7 15:25:18 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Sun,  7 Apr 2013 21:25:18 +0200
Subject: [PATCH v2 08/11] ASoC: fsl-ssi: imx ac97 support
In-Reply-To: <1365362721-3731-1-git-send-email-mpa@pengutronix.de>
References: <1365362721-3731-1-git-send-email-mpa@pengutronix.de>
Message-ID: <1365362721-3731-9-git-send-email-mpa@pengutronix.de>

This patch copies some parts from imx-ssi to support AC97 on
imx27-pca100 and imx27-pcm043. It is activated with a new fsl,imx-ac97
bool property. It was tested on imx27-pca100.

Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
---
 sound/soc/fsl/fsl_ssi.c | 360 +++++++++++++++++++++++++++++++++++++-----------
 1 file changed, 279 insertions(+), 81 deletions(-)

diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index bb9a1e0..06f52ce 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -120,6 +120,7 @@ struct fsl_ssi_private {
 
 	bool new_binding;
 	bool ssi_on_imx;
+	bool imx_ac97;
 	bool dma;
 	struct clk *clk;
 	struct platform_device *imx_pcm_pdev;
@@ -127,6 +128,9 @@ struct fsl_ssi_private {
 	struct imx_pcm_dma_params dma_params_rx;
 	struct imx_pcm_fiq_params fiq_params;
 
+	void (*ac97_reset) (struct snd_ac97 *ac97);
+	void (*ac97_warm_reset)(struct snd_ac97 *ac97);
+
 	struct {
 		unsigned int rfrc;
 		unsigned int tfrc;
@@ -323,67 +327,76 @@ static int fsl_ssi_startup(struct snd_pcm_substream *substream,
 
 		ssi_private->first_stream = substream;
 
-		/*
-		 * Section 16.5 of the MPC8610 reference manual says that the
-		 * SSI needs to be disabled before updating the registers we set
-		 * here.
-		 */
-		write_ssi_mask(&ssi->scr, CCSR_SSI_SCR_SSIEN, 0);
-
-		/*
-		 * Program the SSI into I2S Slave Non-Network Synchronous mode.
-		 * Also enable the transmit and receive FIFO.
-		 *
-		 * FIXME: Little-endian samples require a different shift dir
-		 */
-		write_ssi_mask(&ssi->scr,
-			CCSR_SSI_SCR_I2S_MODE_MASK | CCSR_SSI_SCR_SYN,
-			CCSR_SSI_SCR_TFR_CLK_DIS | CCSR_SSI_SCR_I2S_MODE_SLAVE
-			| (synchronous ? CCSR_SSI_SCR_SYN : 0));
+		/* If we use AC97, the registers are already setup correctly */
+		if (!ssi_private->imx_ac97) {
+			/*
+			 * Section 16.5 of the MPC8610 reference manual says
+			 * that the SSI needs to be disabled before updating
+			 * the registers we set here.
+			 */
+			write_ssi_mask(&ssi->scr, CCSR_SSI_SCR_SSIEN, 0);
 
-		write_ssi(CCSR_SSI_STCR_TXBIT0 | CCSR_SSI_STCR_TFEN0 |
-			 CCSR_SSI_STCR_TFSI | CCSR_SSI_STCR_TEFS |
-			 CCSR_SSI_STCR_TSCKP, &ssi->stcr);
+			/*
+			 * Program the SSI into I2S Slave Non-Network
+			 * Synchronous mode. Also enable the transmit and
+			 * receive FIFO.
+			 *
+			 * FIXME: Little-endian samples require a different
+			 * shift dir
+			 */
+			write_ssi_mask(&ssi->scr,
+				CCSR_SSI_SCR_I2S_MODE_MASK | CCSR_SSI_SCR_SYN,
+				CCSR_SSI_SCR_TFR_CLK_DIS |
+				CCSR_SSI_SCR_I2S_MODE_SLAVE |
+				(synchronous ? CCSR_SSI_SCR_SYN : 0));
+
+			write_ssi(CCSR_SSI_STCR_TXBIT0 | CCSR_SSI_STCR_TFEN0 |
+				 CCSR_SSI_STCR_TFSI | CCSR_SSI_STCR_TEFS |
+				 CCSR_SSI_STCR_TSCKP, &ssi->stcr);
+
+			write_ssi(CCSR_SSI_SRCR_RXBIT0 | CCSR_SSI_SRCR_RFEN0 |
+				 CCSR_SSI_SRCR_RFSI | CCSR_SSI_SRCR_REFS |
+				 CCSR_SSI_SRCR_RSCKP, &ssi->srcr);
+			/*
+			 * The DC and PM bits are only used if the SSI is the
+			 * clock master.
+			 */
 
-		write_ssi(CCSR_SSI_SRCR_RXBIT0 | CCSR_SSI_SRCR_RFEN0 |
-			 CCSR_SSI_SRCR_RFSI | CCSR_SSI_SRCR_REFS |
-			 CCSR_SSI_SRCR_RSCKP, &ssi->srcr);
+			/*
+			 * Set the watermark for transmit FIFI 0 and receive
+			 * FIFO 0. We don't use FIFO 1. We program the
+			 * transmit water to signal a DMA transfer if there are
+			 * only two (or fewer) elements left in the FIFO. Two
+			 * elements equals one frame (left channel, right
+			 * channel). This value, however, depends on the depth
+			 * of the transmit buffer.
+			 *
+			 * We program the receive FIFO to notify us if at least
+			 * two elements (one frame) have been written to the
+			 * FIFO. We could make this value larger (and maybe we
+			 * should), but this way data will be written to memory
+			 * as soon as it's available.
+			 */
+			write_ssi(CCSR_SSI_SFCSR_TFWM0(ssi_private->fifo_depth - 2) |
+				CCSR_SSI_SFCSR_RFWM0(ssi_private->fifo_depth - 2),
+				&ssi->sfcsr);
 
-		/*
-		 * The DC and PM bits are only used if the SSI is the clock
-		 * master.
-		 */
+			/*
+			 * We keep the SSI disabled because if we enable it,
+			 * then the DMA controller will start. It's not
+			 * supposed to start until the SCR.TE (or SCR.RE) bit
+			 * is set, but it does anyway. The DMA controller will
+			 * transfer one "BWC" of data (i.e. the amount of data
+			 * that the MR.BWC bits are set to). The reason this
+			 * is bad is because at this point, the PCM driver has
+			 * not finished initializing the DMA controller.
+			 */
+		}
 
 		/* Enable the interrupts and DMA requests */
 		if (ssi_private->dma)
 			write_ssi(SIER_FLAGS, &ssi->sier);
 
-		/*
-		 * Set the watermark for transmit FIFI 0 and receive FIFO 0. We
-		 * don't use FIFO 1.  We program the transmit water to signal a
-		 * DMA transfer if there are only two (or fewer) elements left
-		 * in the FIFO.  Two elements equals one frame (left channel,
-		 * right channel).  This value, however, depends on the depth of
-		 * the transmit buffer.
-		 *
-		 * We program the receive FIFO to notify us if at least two
-		 * elements (one frame) have been written to the FIFO.  We could
-		 * make this value larger (and maybe we should), but this way
-		 * data will be written to memory as soon as it's available.
-		 */
-		write_ssi(CCSR_SSI_SFCSR_TFWM0(ssi_private->fifo_depth - 2) |
-			CCSR_SSI_SFCSR_RFWM0(ssi_private->fifo_depth - 2),
-			&ssi->sfcsr);
-
-		/*
-		 * We keep the SSI disabled because if we enable it, then the
-		 * DMA controller will start.  It's not supposed to start until
-		 * the SCR.TE (or SCR.RE) bit is set, but it does anyway.  The
-		 * DMA controller will transfer one "BWC" of data (i.e. the
-		 * amount of data that the MR.BWC bits are set to).  The reason
-		 * this is bad is because at this point, the PCM driver has not
-		 * finished initializing the DMA controller.
-		 */
 	} else {
 		if (synchronous) {
 			struct snd_pcm_runtime *first_runtime =
@@ -500,27 +513,29 @@ static int fsl_ssi_trigger(struct snd_pcm_substream *substream, int cmd,
 	struct fsl_ssi_private *ssi_private = snd_soc_dai_get_drvdata(rtd->cpu_dai);
 	struct ccsr_ssi __iomem *ssi = ssi_private->ssi;
 
-	switch (cmd) {
-	case SNDRV_PCM_TRIGGER_START:
-	case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
-		if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
-			write_ssi_mask(&ssi->scr, 0,
-				CCSR_SSI_SCR_SSIEN | CCSR_SSI_SCR_TE);
-		else
-			write_ssi_mask(&ssi->scr, 0,
-				CCSR_SSI_SCR_SSIEN | CCSR_SSI_SCR_RE);
-		break;
-
-	case SNDRV_PCM_TRIGGER_STOP:
-	case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
-		if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
-			write_ssi_mask(&ssi->scr, CCSR_SSI_SCR_TE, 0);
-		else
-			write_ssi_mask(&ssi->scr, CCSR_SSI_SCR_RE, 0);
-		break;
-
-	default:
-		return -EINVAL;
+	if (!ssi_private->imx_ac97) {
+		switch (cmd) {
+		case SNDRV_PCM_TRIGGER_START:
+		case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
+			if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
+				write_ssi_mask(&ssi->scr, 0,
+					CCSR_SSI_SCR_SSIEN | CCSR_SSI_SCR_TE);
+			else
+				write_ssi_mask(&ssi->scr, 0,
+					CCSR_SSI_SCR_SSIEN | CCSR_SSI_SCR_RE);
+			break;
+
+		case SNDRV_PCM_TRIGGER_STOP:
+		case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
+			if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
+				write_ssi_mask(&ssi->scr, CCSR_SSI_SCR_TE, 0);
+			else
+				write_ssi_mask(&ssi->scr, CCSR_SSI_SCR_RE, 0);
+			break;
+
+		default:
+			return -EINVAL;
+		}
 	}
 
 	if (!ssi_private->dma) {
@@ -556,8 +571,9 @@ static void fsl_ssi_shutdown(struct snd_pcm_substream *substream,
 
 	/*
 	 * If this is the last active substream, disable the SSI.
+	 * If AC97 is active, we don't want to disable SSI.
 	 */
-	if (!ssi_private->first_stream) {
+	if (!ssi_private->first_stream && !ssi_private->imx_ac97) {
 		struct ccsr_ssi __iomem *ssi = ssi_private->ssi;
 
 		write_ssi_mask(&ssi->scr, CCSR_SSI_SCR_SSIEN, 0);
@@ -589,6 +605,152 @@ static struct snd_soc_dai_driver fsl_ssi_dai_template = {
 	.ops = &fsl_ssi_dai_ops,
 };
 
+static struct snd_soc_dai_driver fsl_ssi_ac97_dai = {
+	.ac97_control = 1,
+	.playback = {
+		.stream_name = "AC97 Playback",
+		.channels_min = 2,
+		.channels_max = 2,
+		.rates = SNDRV_PCM_RATE_8000_48000,
+		.formats = SNDRV_PCM_FMTBIT_S16_LE,
+	},
+	.capture = {
+		.stream_name = "AC97 Capture",
+		.channels_min = 2,
+		.channels_max = 2,
+		.rates = SNDRV_PCM_RATE_48000,
+		.formats = SNDRV_PCM_FMTBIT_S16_LE,
+	},
+	.ops = &fsl_ssi_dai_ops,
+};
+
+
+static struct fsl_ssi_private *fsl_ac97_data;
+
+static void fsl_ssi_ac97_setup(struct ccsr_ssi *ssi)
+{
+	write_ssi(0x0, &ssi->scr);
+	write_ssi(0x0, &ssi->stcr);
+	write_ssi(0x0, &ssi->srcr);
+
+	write_ssi(CCSR_SSI_SCR_SYN | CCSR_SSI_SCR_NET, &ssi->scr);
+
+	write_ssi(CCSR_SSI_SFCSR_RFWM0(8) | CCSR_SSI_SFCSR_TFWM0(8) |
+			CCSR_SSI_SFCSR_RFWM1(8) | CCSR_SSI_SFCSR_TFWM1(8),
+			&ssi->sfcsr);
+
+	write_ssi(CCSR_SSI_SxCCR_WL(17) | CCSR_SSI_SxCCR_DC(13),
+			&ssi->stccr);
+	write_ssi(CCSR_SSI_SxCCR_WL(17) | CCSR_SSI_SxCCR_DC(13),
+			&ssi->srccr);
+
+	write_ssi(CCSR_SSI_SCR_SYN | CCSR_SSI_SCR_NET |
+			CCSR_SSI_SCR_SSIEN, &ssi->scr);
+	write_ssi(CCSR_SSI_SOR_WAIT(3), &ssi->sor);
+
+	write_ssi(CCSR_SSI_SCR_SYN | CCSR_SSI_SCR_NET |
+			CCSR_SSI_SCR_SSIEN | CCSR_SSI_SCR_TE |
+			CCSR_SSI_SCR_RE, &ssi->scr);
+
+	write_ssi(CCSR_SSI_SACNT_AC97EN | CCSR_SSI_SACNT_FV,
+			&ssi->sacnt);
+	write_ssi(0xff, &ssi->saccdis);
+	write_ssi(0x300, &ssi->saccen);
+
+	write_ssi(0x0, &ssi->sier);
+}
+
+static void fsl_ssi_ac97_write(struct snd_ac97 *ac97, unsigned short reg,
+		unsigned short val)
+{
+	struct ccsr_ssi *ssi = fsl_ac97_data->ssi;
+	unsigned int lreg;
+	unsigned int lval;
+
+	if (reg > 0x7f)
+		return;
+
+
+	lreg = reg <<  12;
+	write_ssi(lreg, &ssi->sacadd);
+
+	lval = val << 4;
+	write_ssi(lval , &ssi->sacdat);
+
+	write_ssi_mask(&ssi->sacnt, CCSR_SSI_SACNT_RDWR_MASK,
+			CCSR_SSI_SACNT_WR);
+	udelay(100);
+}
+
+static unsigned short fsl_ssi_ac97_read(struct snd_ac97 *ac97,
+		unsigned short reg)
+{
+	struct ccsr_ssi *ssi = fsl_ac97_data->ssi;
+
+	unsigned short val = -1;
+	unsigned int lreg;
+
+	lreg = (reg & 0x7f) <<  12 ;
+	write_ssi(lreg, &ssi->sacadd);
+	write_ssi_mask(&ssi->sacnt, CCSR_SSI_SACNT_RDWR_MASK,
+			CCSR_SSI_SACNT_RD);
+
+	udelay(100);
+
+	val = (read_ssi(&ssi->sacdat) >> 4) & 0xffff;
+
+	return val;
+}
+
+static void fsl_ssi_ac97_reset(struct snd_ac97 *ac97)
+{
+	struct fsl_ssi_private *ssi_private = fsl_ac97_data;
+
+	if (ssi_private->ac97_reset)
+		ssi_private->ac97_reset(ac97);
+	/* First read sometimes fails, do a dummy read */
+	fsl_ssi_ac97_read(ac97, 0);
+}
+
+static void fsl_ssi_ac97_warm_reset(struct snd_ac97 *ac97)
+{
+	struct fsl_ssi_private *ssi_private = fsl_ac97_data;
+
+	if (ssi_private->ac97_warm_reset)
+		ssi_private->ac97_warm_reset(ac97);
+
+	/* First read sometimes fails, do a dummy read */
+	fsl_ssi_ac97_read(ac97, 0);
+}
+
+struct snd_ac97_bus_ops soc_ac97_ops = {
+	.read		= fsl_ssi_ac97_read,
+	.write		= fsl_ssi_ac97_write,
+	.reset		= fsl_ssi_ac97_reset,
+	.warm_reset	= fsl_ssi_ac97_warm_reset
+};
+EXPORT_SYMBOL_GPL(soc_ac97_ops);
+
+/*
+ * Pointer to AC97 reset functions for specific boards
+ */
+#if IS_ENABLED(CONFIG_MACH_PCA100)
+extern void pca100_ac97_cold_reset(struct snd_ac97 *ac97);
+extern void pca100_ac97_warm_reset(struct snd_ac97 *ac97);
+#else
+void pca100_ac97_cold_reset(struct snd_ac97 *ac97) { }
+void pca100_ac97_warm_reset(struct snd_ac97 *ac97) { }
+#endif
+
+#if IS_ENABLED(CONFIG_MACH_PCM043)
+extern void pcm043_ac97_cold_reset(struct snd_ac97 *ac97);
+extern void pcm043_ac97_warm_reset(struct snd_ac97 *ac97);
+#else
+void pcm043_ac97_cold_reset(struct snd_ac97 *ac97) { }
+void pcm043_ac97_warm_reset(struct snd_ac97 *ac97) { }
+#endif
+
+
 /* Show the statistics of a flag only if its interrupt is enabled.  The
  * compiler will optimze this code to a no-op if the interrupt is not
  * enabled.
@@ -664,6 +826,7 @@ static int fsl_ssi_probe(struct platform_device *pdev)
 	const uint32_t *iprop;
 	struct resource res;
 	char name[64];
+	bool ac97 = false;
 
 	/* SSIs that are not connected on the board should have a
 	 *      status = "disabled"
@@ -674,7 +837,13 @@ static int fsl_ssi_probe(struct platform_device *pdev)
 
 	/* We only support the SSI in "I2S Slave" mode */
 	sprop = of_get_property(np, "fsl,mode", NULL);
-	if (!sprop || strcmp(sprop, "i2s-slave")) {
+	if (!sprop) {
+		dev_err(&pdev->dev, "fsl,mode property is necessary\n");
+		return -EINVAL;
+	}
+	if (!strcmp(sprop, "ac97-slave")) {
+		ac97 = true;
+	} else if (strcmp(sprop, "i2s-slave")) {
 		dev_notice(&pdev->dev, "mode %s is unsupported\n", sprop);
 		return -ENODEV;
 	}
@@ -690,13 +859,39 @@ static int fsl_ssi_probe(struct platform_device *pdev)
 
 	strcpy(ssi_private->name, p);
 
-	/* Initialize this copy of the CPU DAI driver structure */
-	memcpy(&ssi_private->cpu_dai_drv, &fsl_ssi_dai_template,
-	       sizeof(fsl_ssi_dai_template));
-	ssi_private->cpu_dai_drv.name = ssi_private->name;
-
 	ssi_private->dma = !of_property_read_bool(np, "fsl,imx-fiq");
 
+	if (ac97) {
+		sprop = of_get_property(of_find_node_by_path("/"), "compatible",
+				NULL);
+		p = strrchr(sprop, ',');
+		if (p)
+			sprop = p + 1;
+
+		if (!strcmp(sprop, "imx27-pca100")) {
+			ssi_private->ac97_reset = pca100_ac97_cold_reset;
+			ssi_private->ac97_warm_reset = pca100_ac97_warm_reset;
+		} else if (!strcmp(sprop, "imx27-pcm043")) {
+			ssi_private->ac97_reset = pcm043_ac97_cold_reset;
+			ssi_private->ac97_warm_reset = pcm043_ac97_warm_reset;
+		} else {
+			dev_err(&pdev->dev, "Failed to enable ssi AC97 mode, unknown board.\n");
+			ret = -EINVAL;
+			goto error_kmalloc;
+		}
+
+		memcpy(&ssi_private->cpu_dai_drv, &fsl_ssi_ac97_dai,
+				sizeof(fsl_ssi_ac97_dai));
+
+		fsl_ac97_data = ssi_private;
+		ssi_private->imx_ac97 = true;
+	} else {
+		/* Initialize this copy of the CPU DAI driver structure */
+		memcpy(&ssi_private->cpu_dai_drv, &fsl_ssi_dai_template,
+		       sizeof(fsl_ssi_dai_template));
+	}
+	ssi_private->cpu_dai_drv.name = ssi_private->name;
+
 	/* Get the addresses and IRQ */
 	ret = of_address_to_resource(np, 0, &res);
 	if (ret) {
@@ -729,6 +924,9 @@ static int fsl_ssi_probe(struct platform_device *pdev)
 		}
 	}
 
+	if (ssi_private->imx_ac97)
+		fsl_ssi_ac97_setup(ssi_private->ssi);
+
 	/* Are the RX and the TX clocks locked? */
 	if (!of_find_property(np, "fsl,ssi-asynchronous", NULL))
 		ssi_private->cpu_dai_drv.symmetric_rates = 1;
-- 
1.8.1.5



From mpa at pengutronix.de  Sun Apr  7 15:25:10 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Sun,  7 Apr 2013 21:25:10 +0200
Subject: [PATCH v2 00/11] ASoC: fsl-ssi: ac97-slave support
Message-ID: <1365362721-3731-1-git-send-email-mpa@pengutronix.de>

Hi,

This series adds DT support for phycore-ac97 using the fsl-ssi driver. In
version 2 I discarded most of the imx-ssi work and integrated the ac97-slave
support in fsl-ssi, including support for imx-pcm-fiq as alternative to dma.
There are some other changes to get phycore-ac97 working. The first two patches
have notes about the detailed changes since version 1. The rest of the patches
is new and necessary for the ac97-slave support.

Regards,

Markus


Markus Pargmann (11):
  ASoC: phycore-ac97: Add DT support
  ASoC: imx-pcm-dma: Add support for DMA init by
  ASoC: imx-pcm-fiq: Introduce pcm-fiq-params
  ASoC: fsl-ssi: Add SACNT definitions
  ASoC: fsl-ssi: Add support for imx-pcm-fiq
  ASoC: fsl-ssi: Setup generic imx dma params
  ARM: imx: Export ac97 reset functions
  ASoC: fsl-ssi: imx ac97 support
  ASoC: fsl: Kconfig: Use fsl-ssi for phycore-ac97
  ASoC: fsl: Move fsl-ssi binding doc to sound/
  ASoC: fsl: Update fsl-ssi binding doc

 Documentation/devicetree/bindings/powerpc/fsl/ssi.txt             |   73 -
 Documentation/devicetree/bindings/sound/fsl,ssi.txt               |   13 
 b/Documentation/devicetree/bindings/sound/fsl,ssi.txt             |   73 +
 b/Documentation/devicetree/bindings/sound/phytec,phycore-ac97.txt |   12 
 b/arch/arm/mach-imx/mach-pca100.c                                 |    7 
 b/arch/arm/mach-imx/mach-pcm043.c                                 |    7 
 b/sound/soc/fsl/Kconfig                                           |    2 
 b/sound/soc/fsl/fsl_ssi.c                                         |   70 +
 b/sound/soc/fsl/fsl_ssi.h                                         |    8 
 b/sound/soc/fsl/imx-pcm-dma.c                                     |   31 
 b/sound/soc/fsl/imx-pcm-fiq.c                                     |   14 
 b/sound/soc/fsl/imx-pcm.h                                         |    6 
 b/sound/soc/fsl/imx-ssi.c                                         |    7 
 b/sound/soc/fsl/imx-ssi.h                                         |    1 
 b/sound/soc/fsl/phycore-ac97.c                                    |  185 ++++
 sound/soc/fsl/fsl_ssi.c                                           |  379 +++++++---
 sound/soc/fsl/imx-pcm.h                                           |    9 
 17 files changed, 664 insertions(+), 233 deletions(-)



From mpa at pengutronix.de  Sun Apr  7 15:25:11 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Sun,  7 Apr 2013 21:25:11 +0200
Subject: [PATCH v2 01/11] ASoC: phycore-ac97: Add DT support
In-Reply-To: <1365362721-3731-1-git-send-email-mpa@pengutronix.de>
References: <1365362721-3731-1-git-send-email-mpa@pengutronix.de>
Message-ID: <1365362721-3731-2-git-send-email-mpa@pengutronix.de>

Add devicetree support for this audio soc fabric driver.

Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
---

Notes:
    Changes in v2:
     - Simplify the driver, by combining audmux port configurations. The
       audmux driver actually knows on which platform he is running and
       will return the appropriate error code if we use functions for
       another platform. So we don't need to have the knowledge about it
       in phycore-ac97 and can try both functions. This removes the need
       of different compatibilities and renames it to imx27-ac97.
     - Use a phandle for the cpu_dai link.
     - Add devicetree binding documentation.
     - Rename binding to phytec,phycore-ac97 and fsl,ssi to phytec,ssi

 .../bindings/sound/phytec,phycore-ac97.txt         |  12 ++
 sound/soc/fsl/phycore-ac97.c                       | 185 ++++++++++++++++++---
 2 files changed, 174 insertions(+), 23 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/sound/phytec,phycore-ac97.txt

diff --git a/Documentation/devicetree/bindings/sound/phytec,phycore-ac97.txt b/Documentation/devicetree/bindings/sound/phytec,phycore-ac97.txt
new file mode 100644
index 0000000..e04221d
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/phytec,phycore-ac97.txt
@@ -0,0 +1,12 @@
+Phytec phycore AC97
+
+Required properties:
+- compatible: "phytec,phycore-ac97"
+- phytec,ssi: A phandle to the ssi device that is connected to ac97.
+
+Example:
+
+sound {
+	compatible = "phytec,phycore-ac97";
+	phytec,ssi = <&ssi1>;
+};
diff --git a/sound/soc/fsl/phycore-ac97.c b/sound/soc/fsl/phycore-ac97.c
index d146cec..123af2b 100644
--- a/sound/soc/fsl/phycore-ac97.c
+++ b/sound/soc/fsl/phycore-ac97.c
@@ -21,7 +21,10 @@
 
 #include "imx-audmux.h"
 
+#define DRV_NAME "phycore-audio-fabric"
+
 static struct snd_soc_card imx_phycore;
+static struct device_node *phycore_dai_cpu_node;
 
 static struct snd_soc_ops imx_phycore_hifi_ops = {
 };
@@ -32,8 +35,12 @@ static struct snd_soc_dai_link imx_phycore_dai_ac97[] = {
 		.stream_name	= "HiFi",
 		.codec_dai_name		= "wm9712-hifi",
 		.codec_name	= "wm9712-codec",
+#ifdef CONFIG_MACH_IMX27_DT
+		.platform_name	= "imx-fiq-pcm-audio",
+#else
 		.cpu_dai_name	= "imx-ssi.0",
 		.platform_name	= "imx-fiq-pcm-audio.0",
+#endif
 		.ops		= &imx_phycore_hifi_ops,
 	},
 };
@@ -45,41 +52,83 @@ static struct snd_soc_card imx_phycore = {
 	.num_links	= ARRAY_SIZE(imx_phycore_dai_ac97),
 };
 
-static struct platform_device *imx_phycore_snd_ac97_device;
+static int phycore_ac97_pca100_audmux(void)
+{
+	int ret;
+
+	ret = imx_audmux_v1_configure_port(MX27_AUDMUX_HPCR1_SSI0,
+		IMX_AUDMUX_V1_PCR_SYN | /* 4wire mode */
+		IMX_AUDMUX_V1_PCR_TFCSEL(3) |
+		IMX_AUDMUX_V1_PCR_TCLKDIR | /* clock is output */
+		IMX_AUDMUX_V1_PCR_RXDSEL(3));
+	if (ret)
+		return ret;
+
+	ret = imx_audmux_v1_configure_port(3,
+		IMX_AUDMUX_V1_PCR_SYN | /* 4wire mode */
+		IMX_AUDMUX_V1_PCR_TFCSEL(0) |
+		IMX_AUDMUX_V1_PCR_TFSDIR |
+		IMX_AUDMUX_V1_PCR_RXDSEL(0));
+	return ret;
+}
+
+static int phycore_ac97_pcm043_audmux(void)
+{
+	int ret;
+
+	ret = imx_audmux_v2_configure_port(3,
+		IMX_AUDMUX_V2_PTCR_SYN | /* 4wire mode */
+		IMX_AUDMUX_V2_PTCR_TFSEL(0) |
+		IMX_AUDMUX_V2_PTCR_TFSDIR,
+		IMX_AUDMUX_V2_PDCR_RXDSEL(0));
+	if (ret)
+		return ret;
+
+	ret = imx_audmux_v2_configure_port(0,
+		IMX_AUDMUX_V2_PTCR_SYN | /* 4wire mode */
+		IMX_AUDMUX_V2_PTCR_TCSEL(3) |
+		IMX_AUDMUX_V2_PTCR_TCLKDIR, /* clock is output */
+		IMX_AUDMUX_V2_PDCR_RXDSEL(3));
+	return ret;
+}
+
+static __maybe_unused int phycore_ac97_init_audmux(void)
+{
+	int ret;
+
+	/*
+	 * This driver doesn't need to know which actual hardware is used.
+	 * The audmux driver has knowledge about it's type, and returns
+	 * an error if executed on the wrong type of hardware.
+	 */
+	ret = phycore_ac97_pca100_audmux();
+	if (!ret)
+		return 0;
+
+	ret = phycore_ac97_pcm043_audmux();
+
+	return ret;
+}
+
 static struct platform_device *imx_phycore_snd_device;
 
+#ifndef CONFIG_MACH_IMX27_DT
+
+static struct platform_device *imx_phycore_snd_ac97_device;
+
 static int __init imx_phycore_init(void)
 {
 	int ret;
 
 	if (machine_is_pca100()) {
-		imx_audmux_v1_configure_port(MX27_AUDMUX_HPCR1_SSI0,
-			IMX_AUDMUX_V1_PCR_SYN | /* 4wire mode */
-			IMX_AUDMUX_V1_PCR_TFCSEL(3) |
-			IMX_AUDMUX_V1_PCR_TCLKDIR | /* clock is output */
-			IMX_AUDMUX_V1_PCR_RXDSEL(3));
-		imx_audmux_v1_configure_port(3,
-			IMX_AUDMUX_V1_PCR_SYN | /* 4wire mode */
-			IMX_AUDMUX_V1_PCR_TFCSEL(0) |
-			IMX_AUDMUX_V1_PCR_TFSDIR |
-			IMX_AUDMUX_V1_PCR_RXDSEL(0));
+		phycore_ac97_pca100_audmux();
 	} else if (machine_is_pcm043()) {
-		imx_audmux_v2_configure_port(3,
-			IMX_AUDMUX_V2_PTCR_SYN | /* 4wire mode */
-			IMX_AUDMUX_V2_PTCR_TFSEL(0) |
-			IMX_AUDMUX_V2_PTCR_TFSDIR,
-			IMX_AUDMUX_V2_PDCR_RXDSEL(0));
-		imx_audmux_v2_configure_port(0,
-			IMX_AUDMUX_V2_PTCR_SYN | /* 4wire mode */
-			IMX_AUDMUX_V2_PTCR_TCSEL(3) |
-			IMX_AUDMUX_V2_PTCR_TCLKDIR, /* clock is output */
-			IMX_AUDMUX_V2_PDCR_RXDSEL(3));
+		phycore_ac97_pcm043_audmux();
 	} else {
 		/* return happy. We might run on a totally different machine */
 		return 0;
 	}
 
-
 	/*
 	 * First add codec driver, otherwise soc-audio may be deferred and fails
 	 * to load.
@@ -125,6 +174,96 @@ static void __exit imx_phycore_exit(void)
 late_initcall(imx_phycore_init);
 module_exit(imx_phycore_exit);
 
+#else  /* !CONFIG_MACH_IMX27_DT */
+
+static const struct of_device_id imx_phycore_ac97_of_dev_id[] = {
+	{
+		.compatible = "phytec,phycore-ac97",
+	}, {
+		/* sentinel */
+	}
+};
+MODULE_DEVICE_TABLE(of, imx_phycore_ac97_of_dev_id);
+
+static int phycore_ac97_setup_devices(struct platform_device *pdev)
+{
+	int ret;
+
+	imx_phycore_snd_device = platform_device_alloc("wm9712-codec", -1);
+	if (!imx_phycore_snd_device)
+		return -ENOMEM;
+
+	ret = platform_device_add(imx_phycore_snd_device);
+	if (ret) {
+		dev_err(&pdev->dev, "ASoC: Platform device allocation failed\n");
+		goto fail1;
+	}
+
+	ret = snd_soc_register_card(&imx_phycore);
+	if (ret) {
+		dev_err(&pdev->dev, "ASoC: soc card registration failed\n");
+		goto fail2;
+	}
+	return 0;
+
+fail2:
+	platform_device_del(imx_phycore_snd_device);
+fail1:
+	platform_device_put(imx_phycore_snd_device);
+	return ret;
+}
+
+static int imx_phycore_ac97_probe(struct platform_device *pdev)
+{
+	int ret;
+	struct device_node *ssi_np;
+
+	imx_phycore.dev = &pdev->dev;
+
+	ret = phycore_ac97_init_audmux();
+	if (ret) {
+		dev_err(&pdev->dev, "Failed to initialize audmux\n");
+		return ret;
+	}
+
+	ssi_np = of_parse_phandle(pdev->dev.of_node, "phytec,ssi", 0);
+	if (!ssi_np) {
+		dev_err(&pdev->dev, "No valid ssi phandle found\n");
+		return -EINVAL;
+	}
+
+	imx_phycore_dai_ac97[0].cpu_of_node = ssi_np;
+	phycore_dai_cpu_node = ssi_np;
+
+
+	ret = phycore_ac97_setup_devices(pdev);
+	if (ret)
+		of_node_put(phycore_dai_cpu_node);
+
+	return ret;
+}
+
+static int imx_phycore_ac97_remove(struct platform_device *pdev)
+{
+	of_node_put(phycore_dai_cpu_node);
+	platform_device_unregister(imx_phycore_snd_device);
+	return 0;
+}
+
+static struct platform_driver imx_phycore_ac97_driver = {
+	.probe		= imx_phycore_ac97_probe,
+	.remove		= imx_phycore_ac97_remove,
+	.driver		= {
+		.name	= DRV_NAME,
+		.owner	= THIS_MODULE,
+		.of_match_table = imx_phycore_ac97_of_dev_id,
+	},
+};
+
+module_platform_driver(imx_phycore_ac97_driver);
+
+#endif  /* CONFIG_MACH_IMX27_DT */
+
 MODULE_AUTHOR("Sascha Hauer <s.hauer at pengutronix.de>");
-MODULE_DESCRIPTION("PhyCORE ALSA SoC driver");
+MODULE_DESCRIPTION(DRV_NAME ": PhyCORE ALSA SoC fabric driver");
 MODULE_LICENSE("GPL");
-- 
1.8.1.5



From mpa at pengutronix.de  Sun Apr  7 15:25:15 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Sun,  7 Apr 2013 21:25:15 +0200
Subject: [PATCH v2 05/11] ASoC: fsl-ssi: Add support for imx-pcm-fiq
In-Reply-To: <1365362721-3731-1-git-send-email-mpa@pengutronix.de>
References: <1365362721-3731-1-git-send-email-mpa@pengutronix.de>
Message-ID: <1365362721-3731-6-git-send-email-mpa@pengutronix.de>

Add support for non-dma pcm for imx platforms with imx-pcm-fiq support.
Instead of imx-pcm-audio, in this case imx-pcm-fiq-audio device is added
and the SIER flags are set differently.

Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
---
 sound/soc/fsl/fsl_ssi.c | 70 ++++++++++++++++++++++++++++++++++++++++---------
 1 file changed, 58 insertions(+), 12 deletions(-)

diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index 7decbd9..afb5a23 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -120,10 +120,12 @@ struct fsl_ssi_private {
 
 	bool new_binding;
 	bool ssi_on_imx;
+	bool dma;
 	struct clk *clk;
 	struct platform_device *imx_pcm_pdev;
 	struct imx_pcm_dma_params dma_params_tx;
 	struct imx_pcm_dma_params dma_params_rx;
+	struct imx_pcm_fiq_params fiq_params;
 
 	struct {
 		unsigned int rfrc;
@@ -353,7 +355,8 @@ static int fsl_ssi_startup(struct snd_pcm_substream *substream,
 		 */
 
 		/* Enable the interrupts and DMA requests */
-		write_ssi(SIER_FLAGS, &ssi->sier);
+		if (ssi_private->dma)
+			write_ssi(SIER_FLAGS, &ssi->sier);
 
 		/*
 		 * Set the watermark for transmit FIFI 0 and receive FIFO 0. We
@@ -520,6 +523,18 @@ static int fsl_ssi_trigger(struct snd_pcm_substream *substream, int cmd,
 		return -EINVAL;
 	}
 
+	if (!ssi_private->dma) {
+		if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
+			write_ssi(CCSR_SSI_SOR_TX_CLR, &ssi->sor);
+			write_ssi(CCSR_SSI_SIER_TIE | CCSR_SSI_SIER_TFE0_EN,
+					&ssi->sier);
+		} else {
+			write_ssi(CCSR_SSI_SOR_RX_CLR, &ssi->sor);
+			write_ssi(CCSR_SSI_SIER_RIE | CCSR_SSI_SIER_RFF0_EN,
+					&ssi->sier);
+		}
+	}
+
 	return 0;
 }
 
@@ -680,6 +695,8 @@ static int fsl_ssi_probe(struct platform_device *pdev)
 	       sizeof(fsl_ssi_dai_template));
 	ssi_private->cpu_dai_drv.name = ssi_private->name;
 
+	ssi_private->dma = !of_property_read_bool(np, "fsl,imx-fiq");
+
 	/* Get the addresses and IRQ */
 	ret = of_address_to_resource(np, 0, &res);
 	if (ret) {
@@ -701,12 +718,15 @@ static int fsl_ssi_probe(struct platform_device *pdev)
 		goto error_iomap;
 	}
 
-	/* The 'name' should not have any slashes in it. */
-	ret = request_irq(ssi_private->irq, fsl_ssi_isr, 0, ssi_private->name,
-			  ssi_private);
-	if (ret < 0) {
-		dev_err(&pdev->dev, "could not claim irq %u\n", ssi_private->irq);
-		goto error_irqmap;
+	if (ssi_private->dma) {
+		/* The 'name' should not have any slashes in it. */
+		ret = request_irq(ssi_private->irq, fsl_ssi_isr, 0,
+				ssi_private->name, ssi_private);
+		if (ret < 0) {
+			dev_err(&pdev->dev, "could not claim irq %u\n",
+					ssi_private->irq);
+			goto error_irqmap;
+		}
 	}
 
 	/* Are the RX and the TX clocks locked? */
@@ -789,12 +809,38 @@ static int fsl_ssi_probe(struct platform_device *pdev)
 	}
 
 	if (ssi_private->ssi_on_imx) {
-		ssi_private->imx_pcm_pdev =
-			platform_device_register_simple("imx-pcm-audio",
+		if (!ssi_private->dma) {
+			ssi_private->imx_pcm_pdev = platform_device_alloc(
+							"imx-fiq-pcm-audio",
+							pdev->id);
+			if (!ssi_private->imx_pcm_pdev) {
+				ret = -ENOMEM;
+				goto error_dev;
+			}
+
+			ssi_private->fiq_params.irq = ssi_private->irq;
+			ssi_private->fiq_params.base = ssi_private->ssi;
+			ssi_private->fiq_params.dma_params_rx =
+				&ssi_private->dma_params_rx;
+			ssi_private->fiq_params.dma_params_tx =
+				&ssi_private->dma_params_tx;
+
+			platform_set_drvdata(ssi_private->imx_pcm_pdev,
+					&ssi_private->fiq_params);
+			ret = platform_device_add(ssi_private->imx_pcm_pdev);
+			if (ret) {
+				dev_err(&pdev->dev, "Failed to add imx-fiq-pcm-audio device\n");
+				platform_device_put(ssi_private->imx_pcm_pdev);
+				goto error_dev;
+			}
+		} else {
+			ssi_private->imx_pcm_pdev =
+				platform_device_register_simple("imx-pcm-audio",
 							-1, NULL, 0);
-		if (IS_ERR(ssi_private->imx_pcm_pdev)) {
-			ret = PTR_ERR(ssi_private->imx_pcm_pdev);
-			goto error_dev;
+			if (IS_ERR(ssi_private->imx_pcm_pdev)) {
+				ret = PTR_ERR(ssi_private->imx_pcm_pdev);
+				goto error_dev;
+			}
 		}
 	}
 
-- 
1.8.1.5



From lars at metafoo.de  Sun Apr  7 15:39:31 2013
From: lars at metafoo.de (Lars-Peter Clausen)
Date: Sun, 07 Apr 2013 21:39:31 +0200
Subject: [alsa-devel] [PATCH v2 00/11] ASoC: fsl-ssi: ac97-slave support
In-Reply-To: <1365362721-3731-1-git-send-email-mpa@pengutronix.de>
References: <1365362721-3731-1-git-send-email-mpa@pengutronix.de>
Message-ID: <5161CB73.4000302@metafoo.de>

On 04/07/2013 09:25 PM, Markus Pargmann wrote:
> Hi,
> 
> This series adds DT support for phycore-ac97 using the fsl-ssi driver. In
> version 2 I discarded most of the imx-ssi work and integrated the ac97-slave
> support in fsl-ssi, including support for imx-pcm-fiq as alternative to dma.
> There are some other changes to get phycore-ac97 working. The first two patches
> have notes about the detailed changes since version 1. The rest of the patches
> is new and necessary for the ac97-slave support.
> 
> Regards,
> 
> Markus
> 

Hi,

The DMA PCM related changes won't apply anymore due to the recent dmaengine
PCM cleanups. I've also been working on a more generic dmaengine PCM driver
which has DT support and can be used by imx. The work in progress patches
can be found here:
https://github.com/lclausen-adi/linux-2.6/commits/asoc-dmaengine-cleanups

- Lars

> 
> Markus Pargmann (11):
>   ASoC: phycore-ac97: Add DT support
>   ASoC: imx-pcm-dma: Add support for DMA init by
>   ASoC: imx-pcm-fiq: Introduce pcm-fiq-params
>   ASoC: fsl-ssi: Add SACNT definitions
>   ASoC: fsl-ssi: Add support for imx-pcm-fiq
>   ASoC: fsl-ssi: Setup generic imx dma params
>   ARM: imx: Export ac97 reset functions
>   ASoC: fsl-ssi: imx ac97 support
>   ASoC: fsl: Kconfig: Use fsl-ssi for phycore-ac97
>   ASoC: fsl: Move fsl-ssi binding doc to sound/
>   ASoC: fsl: Update fsl-ssi binding doc
> 
>  Documentation/devicetree/bindings/powerpc/fsl/ssi.txt             |   73 -
>  Documentation/devicetree/bindings/sound/fsl,ssi.txt               |   13 
>  b/Documentation/devicetree/bindings/sound/fsl,ssi.txt             |   73 +
>  b/Documentation/devicetree/bindings/sound/phytec,phycore-ac97.txt |   12 
>  b/arch/arm/mach-imx/mach-pca100.c                                 |    7 
>  b/arch/arm/mach-imx/mach-pcm043.c                                 |    7 
>  b/sound/soc/fsl/Kconfig                                           |    2 
>  b/sound/soc/fsl/fsl_ssi.c                                         |   70 +
>  b/sound/soc/fsl/fsl_ssi.h                                         |    8 
>  b/sound/soc/fsl/imx-pcm-dma.c                                     |   31 
>  b/sound/soc/fsl/imx-pcm-fiq.c                                     |   14 
>  b/sound/soc/fsl/imx-pcm.h                                         |    6 
>  b/sound/soc/fsl/imx-ssi.c                                         |    7 
>  b/sound/soc/fsl/imx-ssi.h                                         |    1 
>  b/sound/soc/fsl/phycore-ac97.c                                    |  185 ++++
>  sound/soc/fsl/fsl_ssi.c                                           |  379 +++++++---
>  sound/soc/fsl/imx-pcm.h                                           |    9 
>  17 files changed, 664 insertions(+), 233 deletions(-)
> 
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel at alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel



From festevam at gmail.com  Sun Apr  7 15:56:12 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Sun, 7 Apr 2013 16:56:12 -0300
Subject: [PATCH v2 0/3] Get rid of big array from imx pinctrl driver
In-Reply-To: <20130407071028.GD11898@S2101-09.ap.freescale.net>
References: <1361533888-18073-1-git-send-email-shawn.guo@linaro.org>
 <CAOMZO5D1+baoM0vMdPW9bAd4DX8C82BF9H87igFNo78+8D_N3Q@mail.gmail.com>
 <20130407071028.GD11898@S2101-09.ap.freescale.net>
Message-ID: <CAOMZO5BCQiRMp8KG-beDkDyX8VSq7Arzs+vJ+xU+SYXRPjgDzA@mail.gmail.com>

On Sun, Apr 7, 2013 at 4:10 AM, Shawn Guo <shawn.guo at linaro.org> wrote:

> I just rebuilt imx/dt branch with the problem fixed and also had the
> branch based on Stephen Warren's for-3.10/dtc-cpp-chroot-std-headers
> branch so avoid all those dts files renaming.

Does imx6dl boot for you in your updated imx/dt branch?

It used to boot previously, but after the update it no longer boots.


From mpa at pengutronix.de  Sun Apr  7 15:56:45 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Sun,  7 Apr 2013 21:56:45 +0200
Subject: [PATCH] ARM: dts: imx51 cpu node
Message-ID: <1365364605-10087-1-git-send-email-mpa@pengutronix.de>

This patch adds a cpus/cpu at 0 node for imx51 with default operating
points for the cpufreq-cpu0 driver. There is currently no regulator
support, so the voltages are 0 here.

Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
---
 arch/arm/boot/dts/imx51.dtsi | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/arch/arm/boot/dts/imx51.dtsi b/arch/arm/boot/dts/imx51.dtsi
index fcf035b..0c7ac0d 100644
--- a/arch/arm/boot/dts/imx51.dtsi
+++ b/arch/arm/boot/dts/imx51.dtsi
@@ -55,6 +55,24 @@
 		};
 	};
 
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		cpu at 0 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a8";
+			reg = <0>;
+			clock-latency = <61036>; /* two CLK32 periods */
+			clocks = <&clks 24>;
+			clock-names = "cpu";
+			operating-points = <
+				/* kHz  uV (No regulator support) */
+				160000  0
+				800000  0
+			>;
+		};
+	};
+
 	soc {
 		#address-cells = <1>;
 		#size-cells = <1>;
-- 
1.8.1.5



From mpa at pengutronix.de  Sun Apr  7 16:08:43 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Sun, 7 Apr 2013 22:08:43 +0200
Subject: [alsa-devel] [PATCH v2 00/11] ASoC: fsl-ssi: ac97-slave support
In-Reply-To: <5161CB73.4000302@metafoo.de>
References: <1365362721-3731-1-git-send-email-mpa@pengutronix.de>
 <5161CB73.4000302@metafoo.de>
Message-ID: <20130407200843.GA8350@pengutronix.de>

Hi,

On Sun, Apr 07, 2013 at 09:39:31PM +0200, Lars-Peter Clausen wrote:
> On 04/07/2013 09:25 PM, Markus Pargmann wrote:
> > Hi,
> > 
> > This series adds DT support for phycore-ac97 using the fsl-ssi driver. In
> > version 2 I discarded most of the imx-ssi work and integrated the ac97-slave
> > support in fsl-ssi, including support for imx-pcm-fiq as alternative to dma.
> > There are some other changes to get phycore-ac97 working. The first two patches
> > have notes about the detailed changes since version 1. The rest of the patches
> > is new and necessary for the ac97-slave support.
> > 
> > Regards,
> > 
> > Markus
> > 
> 
> Hi,
> 
> The DMA PCM related changes won't apply anymore due to the recent dmaengine
> PCM cleanups. I've also been working on a more generic dmaengine PCM driver
> which has DT support and can be used by imx. The work in progress patches
> can be found here:
> https://github.com/lclausen-adi/linux-2.6/commits/asoc-dmaengine-cleanups
> 
> - Lars

Okay, I will rebase it for v3 onto your committed cleanups and will have
a look on your latest patches.

Regards,

Markus

> 
> > 
> > Markus Pargmann (11):
> >   ASoC: phycore-ac97: Add DT support
> >   ASoC: imx-pcm-dma: Add support for DMA init by
> >   ASoC: imx-pcm-fiq: Introduce pcm-fiq-params
> >   ASoC: fsl-ssi: Add SACNT definitions
> >   ASoC: fsl-ssi: Add support for imx-pcm-fiq
> >   ASoC: fsl-ssi: Setup generic imx dma params
> >   ARM: imx: Export ac97 reset functions
> >   ASoC: fsl-ssi: imx ac97 support
> >   ASoC: fsl: Kconfig: Use fsl-ssi for phycore-ac97
> >   ASoC: fsl: Move fsl-ssi binding doc to sound/
> >   ASoC: fsl: Update fsl-ssi binding doc
> > 
> >  Documentation/devicetree/bindings/powerpc/fsl/ssi.txt             |   73 -
> >  Documentation/devicetree/bindings/sound/fsl,ssi.txt               |   13 
> >  b/Documentation/devicetree/bindings/sound/fsl,ssi.txt             |   73 +
> >  b/Documentation/devicetree/bindings/sound/phytec,phycore-ac97.txt |   12 
> >  b/arch/arm/mach-imx/mach-pca100.c                                 |    7 
> >  b/arch/arm/mach-imx/mach-pcm043.c                                 |    7 
> >  b/sound/soc/fsl/Kconfig                                           |    2 
> >  b/sound/soc/fsl/fsl_ssi.c                                         |   70 +
> >  b/sound/soc/fsl/fsl_ssi.h                                         |    8 
> >  b/sound/soc/fsl/imx-pcm-dma.c                                     |   31 
> >  b/sound/soc/fsl/imx-pcm-fiq.c                                     |   14 
> >  b/sound/soc/fsl/imx-pcm.h                                         |    6 
> >  b/sound/soc/fsl/imx-ssi.c                                         |    7 
> >  b/sound/soc/fsl/imx-ssi.h                                         |    1 
> >  b/sound/soc/fsl/phycore-ac97.c                                    |  185 ++++
> >  sound/soc/fsl/fsl_ssi.c                                           |  379 +++++++---
> >  sound/soc/fsl/imx-pcm.h                                           |    9 
> >  17 files changed, 664 insertions(+), 233 deletions(-)
> > 
> > _______________________________________________
> > Alsa-devel mailing list
> > Alsa-devel at alsa-project.org
> > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> 
> 

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From sylvester.nawrocki at gmail.com  Sun Apr  7 16:22:50 2013
From: sylvester.nawrocki at gmail.com (Sylwester Nawrocki)
Date: Sun,  7 Apr 2013 22:22:50 +0200
Subject: [PATCH] ARM: S3C24XX: Correct NR_IRQS definition for s3c2440
Message-ID: <1365366170-9682-1-git-send-email-s.nawrocki@samsung.com>

Due to NR_IRQS being incorrectly defined not all IRQ domains can
be registered for S3C2440. It causes following errors on a s3c2440
SoC based board:

NR_IRQS:89
S3C2440: IRQ Support
irq: clearing pending status 00000002
------------[ cut here ]------------
WARNING: at kernel/irq/irqdomain.c:234 0xc0056ed0()
...
irq: could not create irq-domain
...
s3c2410-wdt s3c2410-wdt: failed to install irq (-22)
s3c2410-wdt: probe of s3c2410-wdt failed with error -22
...
samsung-uart s3c2440-uart.0: cannot get irq 74

Fix this by increasing NR_IRQS to at least (IRQ_S3C2443_AC97 + 1)
if CPU_S3C2440 is selected, so the subintc IRQ domain gets properly
registered.

Cc: Heiko St?bner <heiko at sntech.de>
Signed-off-by: Tomasz Figa <tomasz.figa at gmail.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
---
 arch/arm/mach-s3c24xx/include/mach/irqs.h |    4 +---
 1 files changed, 1 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-s3c24xx/include/mach/irqs.h b/arch/arm/mach-s3c24xx/include/mach/irqs.h
index 43cada8..b6dd4cb 100644
--- a/arch/arm/mach-s3c24xx/include/mach/irqs.h
+++ b/arch/arm/mach-s3c24xx/include/mach/irqs.h
@@ -192,10 +192,8 @@
 
 #if defined(CONFIG_CPU_S3C2416)
 #define NR_IRQS (IRQ_S3C2416_I2S1 + 1)
-#elif defined(CONFIG_CPU_S3C2443)
-#define NR_IRQS (IRQ_S3C2443_AC97+1)
 #else
-#define NR_IRQS (IRQ_S3C2440_AC97+1)
+#define NR_IRQS (IRQ_S3C2443_AC97 + 1)
 #endif
 
 /* compatibility define. */
-- 
1.7.4.1



From sylvester.nawrocki at gmail.com  Sun Apr  7 16:27:22 2013
From: sylvester.nawrocki at gmail.com (Sylwester Nawrocki)
Date: Sun,  7 Apr 2013 22:27:22 +0200
Subject: [PATCH] ARM: Samsung: Select ARM_CPU_SUSPEND when required
Message-ID: <1365366442-16025-1-git-send-email-s.nawrocki@samsung.com>

The power management code of S3C24XX, S3C64XX, S5PV210 platform in
arch/arm/plat-samsung/, arch/arm/mach-s3c24xx/, arch/arm/mach-s3c64xx/
directories uses generic cpu_suspend routine. Make sure it is compiled
in when building with power management support. Without this patch
compilation fails with errors as below. It can be reproduced by using
default config files with CONFIG_SUSPEND disabled and CONFIG_PM_RUNTIME
enabled.

 - s5pv210_defconfig
 arch/arm/plat-samsung/built-in.o: In function `s3c_pm_enter':
 arch/arm/plat-samsung/pm.c:304: undefined reference to `cpu_suspend'
 arch/arm/plat-samsung/built-in.o: In function `s3c_cpu_resume':
 arch/arm/plat-samsung/s5p-sleep.S:74: undefined reference to `cpu_resume'

 - s3c24xx_defconfig
 arch/arm/mach-s3c24xx/built-in.o: In function `s3c_cpu_resume':
 arch/arm/mach-s3c24xx/sleep.S:83: undefined reference to `cpu_resume'
 arch/arm/plat-samsung/built-in.o: In function `s3c_pm_enter':
 arch/arm/plat-samsung/pm.c:304: undefined reference to `cpu_suspend'

 - s3c64xx_defconfig
 arch/arm/mach-s3c64xx/built-in.o: In function `s3c_cpu_resume':
 arch/arm/mach-s3c64xx/sleep.S:72: undefined reference to `cpu_resume'
 arch/arm/plat-samsung/built-in.o: In function `s3c_pm_enter':
 arch/arm/plat-samsung/pm.c:304: undefined reference to `cpu_suspend'

To fix this issue select ARM_CPU_SUSPEND for PLAT_SAMSUNG when PM is set.

The build break occurs for kernels at least back to v3.0, however this
patch applies without conflicts only back to v3.7.

Signed-off-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
Cc: stable at vger.kernel.org
---
 arch/arm/plat-samsung/Kconfig |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/arm/plat-samsung/Kconfig b/arch/arm/plat-samsung/Kconfig
index 54d1861..02355ba 100644
--- a/arch/arm/plat-samsung/Kconfig
+++ b/arch/arm/plat-samsung/Kconfig
@@ -10,6 +10,7 @@ config PLAT_SAMSUNG
 	default y
 	select GENERIC_IRQ_CHIP
 	select NO_IOPORT
+	select ARM_CPU_SUSPEND if PM
 	help
 	  Base platform code for all Samsung SoC based systems
 
-- 
1.7.4.1



From sylvester.nawrocki at gmail.com  Sun Apr  7 16:29:48 2013
From: sylvester.nawrocki at gmail.com (Sylwester Nawrocki)
Date: Sun,  7 Apr 2013 22:29:48 +0200
Subject: [PATCH] ARM: S3C24XX: Remove unused GPIO drive strength register
 definitions
Message-ID: <1365366588-19517-1-git-send-email-s.nawrocki@samsung.com>

There is currently no users of these definitions so remove them.

Signed-off-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
---
 arch/arm/mach-s3c24xx/regs-dsc.h |  203 +-------------------------------------
 1 files changed, 4 insertions(+), 199 deletions(-)

diff --git a/arch/arm/mach-s3c24xx/regs-dsc.h b/arch/arm/mach-s3c24xx/regs-dsc.h
index 98fd4a0..61b3d13 100644
--- a/arch/arm/mach-s3c24xx/regs-dsc.h
+++ b/arch/arm/mach-s3c24xx/regs-dsc.h
@@ -1,5 +1,4 @@
-/* arch/arm/mach-s3c2410/include/mach/regs-dsc.h
- *
+/*
  * Copyright (c) 2004 Simtec Electronics <linux at simtec.co.uk>
  *		      http://www.simtec.co.uk/products/SWLINUX/
  *
@@ -12,209 +11,15 @@
 
 
 #ifndef __ASM_ARCH_REGS_DSC_H
-#define __ASM_ARCH_REGS_DSC_H "2440-dsc"
+#define __ASM_ARCH_REGS_DSC_H __FILE__
 
-#if defined(CONFIG_CPU_S3C2412)
+/* S3C2412 */
 #define S3C2412_DSC0	   S3C2410_GPIOREG(0xdc)
 #define S3C2412_DSC1	   S3C2410_GPIOREG(0xe0)
-#endif
-
-#if defined(CONFIG_CPU_S3C2416)
-#define S3C2416_DSC0	   S3C2410_GPIOREG(0xc0)
-#define S3C2416_DSC1	   S3C2410_GPIOREG(0xc4)
-#define S3C2416_DSC2	   S3C2410_GPIOREG(0xc8)
-#define S3C2416_DSC3	   S3C2410_GPIOREG(0x110)
-
-#define S3C2416_SELECT_DSC0	(0 << 30)
-#define S3C2416_SELECT_DSC1	(1 << 30)
-#define S3C2416_SELECT_DSC2	(2 << 30)
-#define S3C2416_SELECT_DSC3	(3 << 30)
-
-#define S3C2416_DSC_GETSHIFT(x)	(x & 30)
-
-#define S3C2416_DSC0_CF		(S3C2416_SELECT_DSC0 | 28)
-#define	S3C2416_DSC0_CF_5mA	(0 << 28)
-#define	S3C2416_DSC0_CF_10mA	(1 << 28)
-#define	S3C2416_DSC0_CF_15mA	(2 << 28)
-#define	S3C2416_DSC0_CF_21mA	(3 << 28)
-#define	S3C2416_DSC0_CF_MASK	(3 << 28)
-
-#define S3C2416_DSC0_nRBE	(S3C2416_SELECT_DSC0 | 26)
-#define	S3C2416_DSC0_nRBE_5mA	(0 << 26)
-#define	S3C2416_DSC0_nRBE_10mA	(1 << 26)
-#define	S3C2416_DSC0_nRBE_15mA	(2 << 26)
-#define	S3C2416_DSC0_nRBE_21mA	(3 << 26)
-#define	S3C2416_DSC0_nRBE_MASK	(3 << 26)
-
-#define S3C2416_DSC0_nROE	(S3C2416_SELECT_DSC0 | 24)
-#define	S3C2416_DSC0_nROE_5mA	(0 << 24)
-#define	S3C2416_DSC0_nROE_10mA	(1 << 24)
-#define	S3C2416_DSC0_nROE_15mA	(2 << 24)
-#define	S3C2416_DSC0_nROE_21mA	(3 << 24)
-#define	S3C2416_DSC0_nROE_MASK	(3 << 24)
-
-#endif
-
-#if defined(CONFIG_CPU_S3C244X)
 
+/* S3C2440 */
 #define S3C2440_DSC0	   S3C2410_GPIOREG(0xc4)
 #define S3C2440_DSC1	   S3C2410_GPIOREG(0xc8)
 
-#define S3C2440_SELECT_DSC0 (0)
-#define S3C2440_SELECT_DSC1 (1<<31)
-
-#define S3C2440_DSC_GETSHIFT(x) ((x) & 31)
-
-#define S3C2440_DSC0_DISABLE	(1<<31)
-
-#define S3C2440_DSC0_ADDR       (S3C2440_SELECT_DSC0 | 8)
-#define S3C2440_DSC0_ADDR_12mA  (0<<8)
-#define S3C2440_DSC0_ADDR_10mA  (1<<8)
-#define S3C2440_DSC0_ADDR_8mA   (2<<8)
-#define S3C2440_DSC0_ADDR_6mA   (3<<8)
-#define S3C2440_DSC0_ADDR_MASK  (3<<8)
-
-/* D24..D31 */
-#define S3C2440_DSC0_DATA3      (S3C2440_SELECT_DSC0 | 6)
-#define S3C2440_DSC0_DATA3_12mA (0<<6)
-#define S3C2440_DSC0_DATA3_10mA (1<<6)
-#define S3C2440_DSC0_DATA3_8mA  (2<<6)
-#define S3C2440_DSC0_DATA3_6mA  (3<<6)
-#define S3C2440_DSC0_DATA3_MASK (3<<6)
-
-/* D16..D23 */
-#define S3C2440_DSC0_DATA2      (S3C2440_SELECT_DSC0 | 4)
-#define S3C2440_DSC0_DATA2_12mA (0<<4)
-#define S3C2440_DSC0_DATA2_10mA (1<<4)
-#define S3C2440_DSC0_DATA2_8mA  (2<<4)
-#define S3C2440_DSC0_DATA2_6mA  (3<<4)
-#define S3C2440_DSC0_DATA2_MASK (3<<4)
-
-/* D8..D15 */
-#define S3C2440_DSC0_DATA1      (S3C2440_SELECT_DSC0 | 2)
-#define S3C2440_DSC0_DATA1_12mA (0<<2)
-#define S3C2440_DSC0_DATA1_10mA (1<<2)
-#define S3C2440_DSC0_DATA1_8mA  (2<<2)
-#define S3C2440_DSC0_DATA1_6mA  (3<<2)
-#define S3C2440_DSC0_DATA1_MASK (3<<2)
-
-/* D0..D7 */
-#define S3C2440_DSC0_DATA0      (S3C2440_SELECT_DSC0 | 0)
-#define S3C2440_DSC0_DATA0_12mA (0<<0)
-#define S3C2440_DSC0_DATA0_10mA (1<<0)
-#define S3C2440_DSC0_DATA0_8mA  (2<<0)
-#define S3C2440_DSC0_DATA0_6mA  (3<<0)
-#define S3C2440_DSC0_DATA0_MASK (3<<0)
-
-#define S3C2440_DSC1_SCK1       (S3C2440_SELECT_DSC1 | 28)
-#define S3C2440_DSC1_SCK1_12mA  (0<<28)
-#define S3C2440_DSC1_SCK1_10mA  (1<<28)
-#define S3C2440_DSC1_SCK1_8mA   (2<<28)
-#define S3C2440_DSC1_SCK1_6mA   (3<<28)
-#define S3C2440_DSC1_SCK1_MASK  (3<<28)
-
-#define S3C2440_DSC1_SCK0       (S3C2440_SELECT_DSC1 | 26)
-#define S3C2440_DSC1_SCK0_12mA  (0<<26)
-#define S3C2440_DSC1_SCK0_10mA  (1<<26)
-#define S3C2440_DSC1_SCK0_8mA   (2<<26)
-#define S3C2440_DSC1_SCK0_6mA   (3<<26)
-#define S3C2440_DSC1_SCK0_MASK  (3<<26)
-
-#define S3C2440_DSC1_SCKE       (S3C2440_SELECT_DSC1 | 24)
-#define S3C2440_DSC1_SCKE_10mA  (0<<24)
-#define S3C2440_DSC1_SCKE_8mA   (1<<24)
-#define S3C2440_DSC1_SCKE_6mA   (2<<24)
-#define S3C2440_DSC1_SCKE_4mA   (3<<24)
-#define S3C2440_DSC1_SCKE_MASK  (3<<24)
-
-/* SDRAM nRAS/nCAS */
-#define S3C2440_DSC1_SDR        (S3C2440_SELECT_DSC1 | 22)
-#define S3C2440_DSC1_SDR_10mA   (0<<22)
-#define S3C2440_DSC1_SDR_8mA    (1<<22)
-#define S3C2440_DSC1_SDR_6mA    (2<<22)
-#define S3C2440_DSC1_SDR_4mA    (3<<22)
-#define S3C2440_DSC1_SDR_MASK   (3<<22)
-
-/* NAND Flash Controller */
-#define S3C2440_DSC1_NFC        (S3C2440_SELECT_DSC1 | 20)
-#define S3C2440_DSC1_NFC_10mA   (0<<20)
-#define S3C2440_DSC1_NFC_8mA    (1<<20)
-#define S3C2440_DSC1_NFC_6mA    (2<<20)
-#define S3C2440_DSC1_NFC_4mA    (3<<20)
-#define S3C2440_DSC1_NFC_MASK   (3<<20)
-
-/* nBE[0..3] */
-#define S3C2440_DSC1_nBE        (S3C2440_SELECT_DSC1 | 18)
-#define S3C2440_DSC1_nBE_10mA   (0<<18)
-#define S3C2440_DSC1_nBE_8mA    (1<<18)
-#define S3C2440_DSC1_nBE_6mA    (2<<18)
-#define S3C2440_DSC1_nBE_4mA    (3<<18)
-#define S3C2440_DSC1_nBE_MASK   (3<<18)
-
-#define S3C2440_DSC1_WOE        (S3C2440_SELECT_DSC1 | 16)
-#define S3C2440_DSC1_WOE_10mA   (0<<16)
-#define S3C2440_DSC1_WOE_8mA    (1<<16)
-#define S3C2440_DSC1_WOE_6mA    (2<<16)
-#define S3C2440_DSC1_WOE_4mA    (3<<16)
-#define S3C2440_DSC1_WOE_MASK   (3<<16)
-
-#define S3C2440_DSC1_CS7        (S3C2440_SELECT_DSC1 | 14)
-#define S3C2440_DSC1_CS7_10mA   (0<<14)
-#define S3C2440_DSC1_CS7_8mA    (1<<14)
-#define S3C2440_DSC1_CS7_6mA    (2<<14)
-#define S3C2440_DSC1_CS7_4mA    (3<<14)
-#define S3C2440_DSC1_CS7_MASK   (3<<14)
-
-#define S3C2440_DSC1_CS6        (S3C2440_SELECT_DSC1 | 12)
-#define S3C2440_DSC1_CS6_10mA   (0<<12)
-#define S3C2440_DSC1_CS6_8mA    (1<<12)
-#define S3C2440_DSC1_CS6_6mA    (2<<12)
-#define S3C2440_DSC1_CS6_4mA    (3<<12)
-#define S3C2440_DSC1_CS6_MASK   (3<<12)
-
-#define S3C2440_DSC1_CS5        (S3C2440_SELECT_DSC1 | 10)
-#define S3C2440_DSC1_CS5_10mA   (0<<10)
-#define S3C2440_DSC1_CS5_8mA    (1<<10)
-#define S3C2440_DSC1_CS5_6mA    (2<<10)
-#define S3C2440_DSC1_CS5_4mA    (3<<10)
-#define S3C2440_DSC1_CS5_MASK   (3<<10)
-
-#define S3C2440_DSC1_CS4        (S3C2440_SELECT_DSC1 | 8)
-#define S3C2440_DSC1_CS4_10mA   (0<<8)
-#define S3C2440_DSC1_CS4_8mA    (1<<8)
-#define S3C2440_DSC1_CS4_6mA    (2<<8)
-#define S3C2440_DSC1_CS4_4mA    (3<<8)
-#define S3C2440_DSC1_CS4_MASK   (3<<8)
-
-#define S3C2440_DSC1_CS3        (S3C2440_SELECT_DSC1 | 6)
-#define S3C2440_DSC1_CS3_10mA   (0<<6)
-#define S3C2440_DSC1_CS3_8mA    (1<<6)
-#define S3C2440_DSC1_CS3_6mA    (2<<6)
-#define S3C2440_DSC1_CS3_4mA    (3<<6)
-#define S3C2440_DSC1_CS3_MASK   (3<<6)
-
-#define S3C2440_DSC1_CS2        (S3C2440_SELECT_DSC1 | 4)
-#define S3C2440_DSC1_CS2_10mA   (0<<4)
-#define S3C2440_DSC1_CS2_8mA    (1<<4)
-#define S3C2440_DSC1_CS2_6mA    (2<<4)
-#define S3C2440_DSC1_CS2_4mA    (3<<4)
-#define S3C2440_DSC1_CS2_MASK   (3<<4)
-
-#define S3C2440_DSC1_CS1        (S3C2440_SELECT_DSC1 | 2)
-#define S3C2440_DSC1_CS1_10mA   (0<<2)
-#define S3C2440_DSC1_CS1_8mA    (1<<2)
-#define S3C2440_DSC1_CS1_6mA    (2<<2)
-#define S3C2440_DSC1_CS1_4mA    (3<<2)
-#define S3C2440_DSC1_CS1_MASK   (3<<2)
-
-#define S3C2440_DSC1_CS0        (S3C2440_SELECT_DSC1 | 0)
-#define S3C2440_DSC1_CS0_10mA   (0<<0)
-#define S3C2440_DSC1_CS0_8mA    (1<<0)
-#define S3C2440_DSC1_CS0_6mA    (2<<0)
-#define S3C2440_DSC1_CS0_4mA    (3<<0)
-#define S3C2440_DSC1_CS0_MASK   (3<<0)
-
-#endif /* CONFIG_CPU_S3C2440 */
-
 #endif	/* __ASM_ARCH_REGS_DSC_H */
 
-- 
1.7.4.1



From heiko at sntech.de  Sun Apr  7 16:35:01 2013
From: heiko at sntech.de (Heiko =?utf-8?q?St=C3=BCbner?=)
Date: Sun, 7 Apr 2013 22:35:01 +0200
Subject: [PATCH] ARM: S3C24XX: Correct NR_IRQS definition for s3c2440
In-Reply-To: <1365366170-9682-1-git-send-email-s.nawrocki@samsung.com>
References: <1365366170-9682-1-git-send-email-s.nawrocki@samsung.com>
Message-ID: <201304072235.02218.heiko@sntech.de>

Am Sonntag, 7. April 2013, 22:22:50 schrieb Sylwester Nawrocki:
> Due to NR_IRQS being incorrectly defined not all IRQ domains can
> be registered for S3C2440. It causes following errors on a s3c2440
> SoC based board:
> 
> NR_IRQS:89
> S3C2440: IRQ Support
> irq: clearing pending status 00000002
> ------------[ cut here ]------------
> WARNING: at kernel/irq/irqdomain.c:234 0xc0056ed0()
> ...
> irq: could not create irq-domain
> ...
> s3c2410-wdt s3c2410-wdt: failed to install irq (-22)
> s3c2410-wdt: probe of s3c2410-wdt failed with error -22
> ...
> samsung-uart s3c2440-uart.0: cannot get irq 74
> 
> Fix this by increasing NR_IRQS to at least (IRQ_S3C2443_AC97 + 1)
> if CPU_S3C2440 is selected, so the subintc IRQ domain gets properly
> registered.
> 
> Cc: Heiko St?bner <heiko at sntech.de>
> Signed-off-by: Tomasz Figa <tomasz.figa at gmail.com>
> Signed-off-by: Sylwester Nawrocki <s.nawrocki at samsung.com>

Thanks for testing the irq changes on another subarchitecture and fixing the 
glitch.

Acked-by: Heiko Stuebner <heiko at sntech.de>


> ---
>  arch/arm/mach-s3c24xx/include/mach/irqs.h |    4 +---
>  1 files changed, 1 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/mach-s3c24xx/include/mach/irqs.h
> b/arch/arm/mach-s3c24xx/include/mach/irqs.h index 43cada8..b6dd4cb 100644
> --- a/arch/arm/mach-s3c24xx/include/mach/irqs.h
> +++ b/arch/arm/mach-s3c24xx/include/mach/irqs.h
> @@ -192,10 +192,8 @@
> 
>  #if defined(CONFIG_CPU_S3C2416)
>  #define NR_IRQS (IRQ_S3C2416_I2S1 + 1)
> -#elif defined(CONFIG_CPU_S3C2443)
> -#define NR_IRQS (IRQ_S3C2443_AC97+1)
>  #else
> -#define NR_IRQS (IRQ_S3C2440_AC97+1)
> +#define NR_IRQS (IRQ_S3C2443_AC97 + 1)
>  #endif
> 
>  /* compatibility define. */



From lars at metafoo.de  Sun Apr  7 16:35:02 2013
From: lars at metafoo.de (Lars-Peter Clausen)
Date: Sun, 07 Apr 2013 22:35:02 +0200
Subject: [alsa-devel] [PATCH v2 00/11] ASoC: fsl-ssi: ac97-slave support
In-Reply-To: <20130407200843.GA8350@pengutronix.de>
References: <1365362721-3731-1-git-send-email-mpa@pengutronix.de>
 <5161CB73.4000302@metafoo.de> <20130407200843.GA8350@pengutronix.de>
Message-ID: <5161D876.6020007@metafoo.de>

On 04/07/2013 10:08 PM, Markus Pargmann wrote:
> Hi,
> 
> On Sun, Apr 07, 2013 at 09:39:31PM +0200, Lars-Peter Clausen wrote:
>> On 04/07/2013 09:25 PM, Markus Pargmann wrote:
>>> Hi,
>>>
>>> This series adds DT support for phycore-ac97 using the fsl-ssi driver. In
>>> version 2 I discarded most of the imx-ssi work and integrated the ac97-slave
>>> support in fsl-ssi, including support for imx-pcm-fiq as alternative to dma.
>>> There are some other changes to get phycore-ac97 working. The first two patches
>>> have notes about the detailed changes since version 1. The rest of the patches
>>> is new and necessary for the ac97-slave support.
>>>
>>> Regards,
>>>
>>> Markus
>>>
>>
>> Hi,
>>
>> The DMA PCM related changes won't apply anymore due to the recent dmaengine
>> PCM cleanups. I've also been working on a more generic dmaengine PCM driver
>> which has DT support and can be used by imx. The work in progress patches
>> can be found here:
>> https://github.com/lclausen-adi/linux-2.6/commits/asoc-dmaengine-cleanups
>>
>> - Lars
> 
> Okay, I will rebase it for v3 onto your committed cleanups and will have
> a look on your latest patches.
> 

It might be a good idea to rebase it ontop of the generic dmaengine driver
patches right away, since it will simplify things quite a bit.

- Lars

> Regards,
> 
> Markus
> 
>>
>>>
>>> Markus Pargmann (11):
>>>   ASoC: phycore-ac97: Add DT support
>>>   ASoC: imx-pcm-dma: Add support for DMA init by
>>>   ASoC: imx-pcm-fiq: Introduce pcm-fiq-params
>>>   ASoC: fsl-ssi: Add SACNT definitions
>>>   ASoC: fsl-ssi: Add support for imx-pcm-fiq
>>>   ASoC: fsl-ssi: Setup generic imx dma params
>>>   ARM: imx: Export ac97 reset functions
>>>   ASoC: fsl-ssi: imx ac97 support
>>>   ASoC: fsl: Kconfig: Use fsl-ssi for phycore-ac97
>>>   ASoC: fsl: Move fsl-ssi binding doc to sound/
>>>   ASoC: fsl: Update fsl-ssi binding doc
>>>
>>>  Documentation/devicetree/bindings/powerpc/fsl/ssi.txt             |   73 -
>>>  Documentation/devicetree/bindings/sound/fsl,ssi.txt               |   13 
>>>  b/Documentation/devicetree/bindings/sound/fsl,ssi.txt             |   73 +
>>>  b/Documentation/devicetree/bindings/sound/phytec,phycore-ac97.txt |   12 
>>>  b/arch/arm/mach-imx/mach-pca100.c                                 |    7 
>>>  b/arch/arm/mach-imx/mach-pcm043.c                                 |    7 
>>>  b/sound/soc/fsl/Kconfig                                           |    2 
>>>  b/sound/soc/fsl/fsl_ssi.c                                         |   70 +
>>>  b/sound/soc/fsl/fsl_ssi.h                                         |    8 
>>>  b/sound/soc/fsl/imx-pcm-dma.c                                     |   31 
>>>  b/sound/soc/fsl/imx-pcm-fiq.c                                     |   14 
>>>  b/sound/soc/fsl/imx-pcm.h                                         |    6 
>>>  b/sound/soc/fsl/imx-ssi.c                                         |    7 
>>>  b/sound/soc/fsl/imx-ssi.h                                         |    1 
>>>  b/sound/soc/fsl/phycore-ac97.c                                    |  185 ++++
>>>  sound/soc/fsl/fsl_ssi.c                                           |  379 +++++++---
>>>  sound/soc/fsl/imx-pcm.h                                           |    9 
>>>  17 files changed, 664 insertions(+), 233 deletions(-)
>>>
>>> _______________________________________________
>>> Alsa-devel mailing list
>>> Alsa-devel at alsa-project.org
>>> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>>
>>
> 



From sameo at linux.intel.com  Sun Apr  7 16:52:16 2013
From: sameo at linux.intel.com (Samuel Ortiz)
Date: Sun, 7 Apr 2013 22:52:16 +0200
Subject: [PATCH 00/14] Ux500 multiplatform v2
In-Reply-To: <201304051713.54233.arnd@arndb.de>
References: <1365171776-8463-1-git-send-email-linus.walleij@stericsson.com>
 <201304051713.54233.arnd@arndb.de>
Message-ID: <20130407205216.GB24058@zurbaran>

Hi Arnd,

On Fri, Apr 05, 2013 at 05:13:54PM +0200, Arnd Bergmann wrote:
> On Friday 05 April 2013, Linus Walleij wrote:
> > From: Linus Walleij <linus.walleij at linaro.org>
> > 
> > This is the complete Ux500 multiplatform patchset.
> > 
> > The only thing missing is a few ACKs from the MFD
> > maintainer (Samuel Ortiz).
> 
> Ok, very nice!
> 
> I'd like to put them into arm-soc really soon to give it some
> more time in linux-next before the merge window, but I don't
> want to step on Sam's toes here.
> 
> Sam, can you send an ACK or NAK by Monday? 
Acked-by: Samuel Ortiz <sameo at linux.intel.com> for the 4 patches.

I am fine with Linus' changes. Would it be possible for you to setup a branch
where I could also pull those changes from ? Or are the interdependencies too
strong to do so ?
I'd like to avoid potential conflicts as much as possible...

Cheers,
Samuel.

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


From daniel.lezcano at linaro.org  Sun Apr  7 16:52:44 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Sun, 07 Apr 2013 22:52:44 +0200
Subject: [PATCH 7/9] intel: cpuidle: remove stop/start critical timings
In-Reply-To: <3375360.P4DAA9Jd5Y@vostro.rjw.lan>
References: <1364991322-20585-1-git-send-email-daniel.lezcano@linaro.org>
 <1364991322-20585-7-git-send-email-daniel.lezcano@linaro.org>
 <3375360.P4DAA9Jd5Y@vostro.rjw.lan>
Message-ID: <5161DC9C.3020703@linaro.org>

On 04/05/2013 12:31 AM, Rafael J. Wysocki wrote:
> On Wednesday, April 03, 2013 02:15:20 PM Daniel Lezcano wrote:
>> The start/stop_critical_timings are called from arch/x86/kernel/process.c
>> in the cpu_idle loop function.
>>
>> Remove the ones in the cpuidle driver.
>>
>> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
> 
> For this one I need an ACK from Len.
> 
> Len, any objections?


Len ? ping ...

>> ---
>>  drivers/idle/intel_idle.c |    3 ---
>>  1 file changed, 3 deletions(-)
>>
>> diff --git a/drivers/idle/intel_idle.c b/drivers/idle/intel_idle.c
>> index 5d66750..c99c31e 100644
>> --- a/drivers/idle/intel_idle.c
>> +++ b/drivers/idle/intel_idle.c
>> @@ -339,7 +339,6 @@ static int intel_idle(struct cpuidle_device *dev,
>>  	if (!(lapic_timer_reliable_states & (1 << (cstate))))
>>  		clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &cpu);
>>  
>> -	stop_critical_timings();
>>  	if (!need_resched()) {
>>  
>>  		__monitor((void *)&current_thread_info()->flags, 0, 0);
>> @@ -348,8 +347,6 @@ static int intel_idle(struct cpuidle_device *dev,
>>  			__mwait(eax, ecx);
>>  	}
>>  
>> -	start_critical_timings();
>> -
>>  	if (!(lapic_timer_reliable_states & (1 << (cstate))))
>>  		clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &cpu);
>>  
>>


-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

  * English - detected
  * English
  * French

  * English
  * French

 <javascript:void(0);> <#>


From arnd at arndb.de  Sun Apr  7 17:04:45 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Sun, 7 Apr 2013 23:04:45 +0200
Subject: [PATCH 00/14] Ux500 multiplatform v2
In-Reply-To: <20130407205216.GB24058@zurbaran>
References: <1365171776-8463-1-git-send-email-linus.walleij@stericsson.com>
 <201304051713.54233.arnd@arndb.de> <20130407205216.GB24058@zurbaran>
Message-ID: <201304072304.46159.arnd@arndb.de>

On Sunday 07 April 2013, Samuel Ortiz wrote:
> On Fri, Apr 05, 2013 at 05:13:54PM +0200, Arnd Bergmann wrote:
> > On Friday 05 April 2013, Linus Walleij wrote:

> I am fine with Linus' changes. Would it be possible for you to setup a branch
> where I could also pull those changes from ? Or are the interdependencies too
> strong to do so ?

Sure, I always create a stable branch for each pull request I get for this
purpose anyway. Actually it might be nice if Linus could produce two branches:
One that has the MFD changes only, and the second one based on the first that
adds all the remaining changes. Then you can pull in just the first branch
and don't need to add too many changes outside of drivers/mfd to your tree.

I don't think that the patches depend on anything that is already in arm-soc,
but we might need to add other changes on top.

	Arnd


From tomasz.figa at gmail.com  Sun Apr  7 17:14:22 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Sun, 07 Apr 2013 23:14:22 +0200
Subject: [RFC PATCH] CLK: Allow parent clock and rate to be configured in
 DT.
In-Reply-To: <CAKGA1bnhMz-18RvUq1Bx-b_AztwspYC+Q+3QGYf=kBtMe1nq2w@mail.gmail.com>
References: <20130319170933.28337.50448.stgit@localhost>
 <CAKGA1bnt_wrNPg2JdAu=ac+WiUm8pVaGh3Tjrt3NvgdFeLxB8A@mail.gmail.com>
 <CAKGA1bnhMz-18RvUq1Bx-b_AztwspYC+Q+3QGYf=kBtMe1nq2w@mail.gmail.com>
Message-ID: <8699707.bKlCq77L0P@flatron>

On Sunday 07 of April 2013 11:34:14 Matt Sealey wrote:
> Or actually, let me rephrase that; sure, when we decide that the
> actual clock tree is described IN the device tree and not in Linux -
> the only thing I have to test this on is i.MX and OMAP and it's all a
> huge table in the Linux kernel which the DT uses to reference
> arbitrary indices into a provider array...

I'm not sure what's wrong with that.

> I could add desired parents to the provider array but that wouldn't
> really fix the configuration problem.

I'm not really seeing any configuration problem here. This is an 
artificial problem created by looking at device tree way too 
conservatively, without any significant reason.

> Can we get an agreement that
> actually, no matter how "unwieldy" or "unreadable" some people think
> it might be, that the entire clock tree for a board should end up in
> it's device tree (muxes, selects, gates and all) with suitable
> bindings? This is the only way you'll get clock "hacks" out of the
> source.

Hardware initialization is not really a hack...

Going this way, why to keep any initialization code inside drivers at all? 
Let's initialize USB, MMC, display controllers in the bootloader and just 
make the driver handle user requests assuming that the hardware is already 
initialized.

> I do have a kernel tree for some 3.8-rc (which you know of already)
> which started work on this and I had some success with it. I'll need a
> little while to move it forward after Shawn moved some things around,
> rebase all the work.. there are more problems to fix with how
> everything "works" right now than just a need for configuration data,
> which is why I am so opposed to adding that configuration data. It
> supposes that we are giving complete descriptions already anyway, and
> my proposal relies on having complete descriptions anyway, when we are
> not in either case. Give me a couple weeks and I'll probably have it
> done, if nothing moves under my feet again..
> 
> At the point where we have two proposals here; implement 100 clocks as
> device tree nodes, or implement multiple ways of providing clock
> reparenting and frequency setting information as a configuration
> clock, I would rather implement those 100 clocks as nodes..

...or 200 or 300 or 400... (yes, there are platforms which have so many 
elements in their clock networks and they are not uncommon), good luck 
with parsing this at runtime (either with CPU or yourself when reading
a dts file).

It would make some sense if all those basic elements (divs, muxes, gates) 
on all platforms would be identical, but each platform will have its own 
specific quirks, for which such uber-generic binding would have to 
account.

Now, why the other option is to have multiple ways? What's holding us from 
defining a single way of doing so?

Best regards,
Tomasz

> Matt Sealey <matt at genesi-usa.com>
> Product Development Analyst, Genesi USA, Inc.
> 
> On Sun, Apr 7, 2013 at 11:23 AM, Matt Sealey <matt at genesi-usa.com> 
wrote:
> > On Sun, Apr 7, 2013 at 11:00 AM, Fabio Estevam <festevam at gmail.com> 
wrote:
> >> On Sun, Apr 7, 2013 at 12:50 PM, Matt Sealey <matt at genesi-usa.com> 
wrote:
> >>> If we're dealing with audio codecs, fix the audio codec to accept a
> >>> *table* of possible clock values and if that hardware operates
> >>> differently per clock value, then add that data in there too (like
> >>> the
> >>> cs42l52 audio codec). Where the software and hardware is a little
> >>> more
> >>> dynamic, the same binding works here - and the usual trick is just
> >>> force one configuration possible out of many. The board designer can
> >>> look at all the possibilities and choose the one or two or all that
> >>> will work with the design, and it can go into the device tree.
> >> 
> >> Sorry, but I have a hard time following a so long response.
> >> 
> >> Can't you just send patches to the list with your proposal so that we
> >> can move forward with the idea?
> > 
> > Sure.
> > 
> > --
> > Matt Sealey <matt at genesi-usa.com>
> > Product Development Analyst, Genesi USA, Inc.


From arnd at arndb.de  Sun Apr  7 17:23:41 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Sun, 7 Apr 2013 23:23:41 +0200
Subject: [RFC PATCH arm: initial TI-Nspire support]
In-Reply-To: <521DFDFC-7E9E-47EA-ACDA-C91BBDC8454E@gmail.com>
References: <6FE4B33E-A503-4A75-AEED-831CB2C06D83@gmail.com>
 <4B3FD561-84FC-40CD-B747-13851692D673@gmail.com>
 <521DFDFC-7E9E-47EA-ACDA-C91BBDC8454E@gmail.com>
Message-ID: <201304072323.42173.arnd@arndb.de>

On Sunday 07 April 2013, Daniel Tang wrote:
> Here's an updated patch that enables support for the LCD.
> 
> I looked into drivers/video/of_display_timing.c but it doesn't have the fields to describe the PL11x specific options needed in struct clcd_panel. At the moment, it is implemented by hardcoding the values in the kernel and using the device tree to select the correct configuration.
> 
> Signed-off-by: Daniel Tang <dt.tangr at gmail.com>

I think you should for now keep the clcd stuff in a separate file,
since it will be replaced with DT logic eventually. For now, the
auxdata method is ok, but Linus Walleij might already have thought
about how pl111 should get all its data from the device tree.

	Arnd


From gnurou at gmail.com  Sun Apr  7 17:25:39 2013
From: gnurou at gmail.com (Alexandre Courbot)
Date: Sun, 7 Apr 2013 14:25:39 -0700
Subject: [PATCH 0/3] gpio: remove GENERIC_GPIO completely
In-Reply-To: <20130407032304.GA11500@cbz-workstation>
References: <1364562678-8945-1-git-send-email-acourbot@nvidia.com>
 <20130407032304.GA11500@cbz-workstation>
Message-ID: <CAAVeFuL185oiZfmv9waN9kOqVqfhnbC11JEs3Y59gpXNfiW34Q@mail.gmail.com>

Hi Chen,

Cool, thanks! Can you send a formatted patch to include in the series,
or do you prefer me to squash it in the relevant patch and add your
signoff for this file?

Alex.

2013/4/6 Chen Baozi <baozich at gmail.com>:
> On Fri, Mar 29, 2013 at 06:11:15AM -0700, Alexandre Courbot wrote:
>> Another issue, I could not update the Chinese documentation in a satisfying
>> manner due to my absence of Chinese skills. Hope that will be forgiven.
>>
> Hi Alexandre,
>
> I have changed the Chinese documentation according to your update as
> follows. Hopefully it would be helpful, :)
>
> ---
>  Documentation/zh_CN/gpio.txt | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/zh_CN/gpio.txt b/Documentation/zh_CN/gpio.txt
> index 4fa7b4e..d5b8f01 100644
> --- a/Documentation/zh_CN/gpio.txt
> +++ b/Documentation/zh_CN/gpio.txt
> @@ -84,10 +84,10 @@ GPIO ??
>  ?????????????(??????????????????,???
>  ????????? GPIO ????????????????????)
>
> -????,?????????????????????????????
> -??? Kconfig ???? GENERIC_GPIO??? (??? true)????
> -?? <asm/gpio.h> ????????? GPIO ???????? Kconfig
> -???????GENERIC_GPIO????????:
> +????,????????????????????????????????
> +??? Kconfig ??? ARCH_REQUIRE_GPIOLIB ?? ARCH_WANT_OPTIONAL_GPIOLIB
> +????????? GPIO ???????? Kconfig
> ???????GENERIC_GPIO?
> +???????:
>
>         #include <linux/gpio.h>
>

From sylvester.nawrocki at gmail.com  Sun Apr  7 17:42:58 2013
From: sylvester.nawrocki at gmail.com (Sylwester Nawrocki)
Date: Sun, 07 Apr 2013 23:42:58 +0200
Subject: [PATCH] ARM: S3C24XX: Correct NR_IRQS definition for s3c2440
In-Reply-To: <201304072235.02218.heiko@sntech.de>
References: <1365366170-9682-1-git-send-email-s.nawrocki@samsung.com>
 <201304072235.02218.heiko@sntech.de>
Message-ID: <5161E862.9060905@gmail.com>

On 04/07/2013 10:35 PM, Heiko St?bner wrote:
> Am Sonntag, 7. April 2013, 22:22:50 schrieb Sylwester Nawrocki:
[...]
> Thanks for testing the irq changes on another subarchitecture and fixing the
> glitch.

And thanks for your effort in adding DT support for s3c24xx!

I'm still debugging one more issue, which prevents the ethernet controller
from working properly. I.e. currently booting stops on starting network 
interfaces.
There is some problem with the external interrupts handling on s3c2440. 
In my
case EINT7 does not trigger any interrupts, even though gpcon_reg and 
extint_reg
seem to be configured properly.


Regards,
Sylwester


From sameo at linux.intel.com  Sun Apr  7 17:46:57 2013
From: sameo at linux.intel.com (Samuel Ortiz)
Date: Sun, 7 Apr 2013 23:46:57 +0200
Subject: [PATCH 00/14] Ux500 multiplatform v2
In-Reply-To: <201304072304.46159.arnd@arndb.de>
References: <1365171776-8463-1-git-send-email-linus.walleij@stericsson.com>
 <201304051713.54233.arnd@arndb.de>
 <20130407205216.GB24058@zurbaran>
 <201304072304.46159.arnd@arndb.de>
Message-ID: <20130407214657.GD24058@zurbaran>

On Sun, Apr 07, 2013 at 11:04:45PM +0200, Arnd Bergmann wrote:
> On Sunday 07 April 2013, Samuel Ortiz wrote:
> > On Fri, Apr 05, 2013 at 05:13:54PM +0200, Arnd Bergmann wrote:
> > > On Friday 05 April 2013, Linus Walleij wrote:
> 
> > I am fine with Linus' changes. Would it be possible for you to setup a branch
> > where I could also pull those changes from ? Or are the interdependencies too
> > strong to do so ?
> 
> Sure, I always create a stable branch for each pull request I get for this
> purpose anyway. Actually it might be nice if Linus could produce two branches:
> One that has the MFD changes only, and the second one based on the first that
> adds all the remaining changes. 
That would be ideal, yes.

Cheers,
Samuel.

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


From festevam at gmail.com  Sun Apr  7 17:52:11 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Sun, 7 Apr 2013 18:52:11 -0300
Subject: [PATCH v2 0/3] Get rid of big array from imx pinctrl driver
In-Reply-To: <CAOMZO5BCQiRMp8KG-beDkDyX8VSq7Arzs+vJ+xU+SYXRPjgDzA@mail.gmail.com>
References: <1361533888-18073-1-git-send-email-shawn.guo@linaro.org>
 <CAOMZO5D1+baoM0vMdPW9bAd4DX8C82BF9H87igFNo78+8D_N3Q@mail.gmail.com>
 <20130407071028.GD11898@S2101-09.ap.freescale.net>
 <CAOMZO5BCQiRMp8KG-beDkDyX8VSq7Arzs+vJ+xU+SYXRPjgDzA@mail.gmail.com>
Message-ID: <CAOMZO5AVra7Hrf5rJvr5UWP=B2m18Dyw2tb4jC8JwxFVNr5i3Q@mail.gmail.com>

On Sun, Apr 7, 2013 at 4:56 PM, Fabio Estevam <festevam at gmail.com> wrote:
> On Sun, Apr 7, 2013 at 4:10 AM, Shawn Guo <shawn.guo at linaro.org> wrote:
>
>> I just rebuilt imx/dt branch with the problem fixed and also had the
>> branch based on Stephen Warren's for-3.10/dtc-cpp-chroot-std-headers
>> branch so avoid all those dts files renaming.
>
> Does imx6dl boot for you in your updated imx/dt branch?
>
> It used to boot previously, but after the update it no longer boots.

Your updated branch missed:

[PATCH 3/6] ARM: imx: add initial imx6dl support


From mathias at openismus.com  Sun Apr  7 17:59:39 2013
From: mathias at openismus.com (Mathias Hasselmann)
Date: Sun, 07 Apr 2013 23:59:39 +0200
Subject: [PATCH 3/6] ARM: imx: add initial imx6dl support
In-Reply-To: <1364913079-26039-4-git-send-email-shawn.guo@linaro.org>
References: <1364913079-26039-1-git-send-email-shawn.guo@linaro.org>
 <1364913079-26039-4-git-send-email-shawn.guo@linaro.org>
Message-ID: <1365371979.4457.4.camel@smarty>

Am Dienstag, den 02.04.2013, 22:31 +0800 schrieb Shawn Guo:
> diff --git a/arch/arm/mach-imx/mxc.h b/arch/arm/mach-imx/mxc.h
> index 7dce17a..8629e5b 100644
> --- a/arch/arm/mach-imx/mxc.h
> +++ b/arch/arm/mach-imx/mxc.h
> @@ -34,6 +34,8 @@
>  #define MXC_CPU_MX35		35
>  #define MXC_CPU_MX51		51
>  #define MXC_CPU_MX53		53
> +#define MXC_CPU_IMX6DL		0x61
> +#define MXC_CPU_IMX6Q		0x63
>  
>  #define IMX_CHIP_REVISION_1_0		0x10
>  #define IMX_CHIP_REVISION_1_1		0x11

Hi Shawn,

Are the hexadecimal values for MXC_CPU_IMX6DL and MXC_CPU_IMX6Q correct?
I ask because Freescale's imx_3.0.35_1.1.0 kernel defines MXC_CPU_MX6DL
and MXC_CPU_MX6Q with the decimal numbers 61 and 63.

Ciao,
Mathias



From linux at roeck-us.net  Sun Apr  7 18:50:46 2013
From: linux at roeck-us.net (Guenter Roeck)
Date: Sun, 7 Apr 2013 15:50:46 -0700
Subject: [v5] clk: add si5351 i2c common clock driver
In-Reply-To: <1365139415-17815-1-git-send-email-sebastian.hesselbarth@gmail.com>
References: <1365139415-17815-1-git-send-email-sebastian.hesselbarth@gmail.com>
Message-ID: <20130407225046.GA16326@roeck-us.net>

On Fri, Apr 05, 2013 at 05:23:35AM -0000, Sebastian Hesselbarth wrote:
> This patch adds a common clock driver for Silicon Labs Si5351a/b/c
> i2c programmable clock generators. Currently, the driver supports
> DT kernels only and VXCO feature of si5351b is not implemented. DT
> bindings selectively allow to overwrite stored Si5351 configuration
> which is very helpful for clock generators with empty eeprom
> configuration. Corresponding device tree binding documentation is
> also added.
> 
> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
> Tested-by: Daniel Mack <zonque at gmail.com>
>
[ ... ]

> +static inline void _si5351_msynth_set_pll_master(
> +	struct si5351_driver_data *drvdata, unsigned char num, int is_master)
> +{
> +	unsigned long flags;
> +
> +	if (num > 8 ||
> +	    (drvdata->variant == SI5351_VARIANT_A3 && num > 3))
> +		return;
> +
> +	flags = __clk_get_flags(drvdata->msynth[num].hw.clk);
> +	if (is_master)
> +		flags |= CLK_SET_RATE_PARENT;
> +	else
> +		flags &= ~CLK_SET_RATE_PARENT;
> +	__clk_set_flags(drvdata->msynth[num].hw.clk, flags);
> +}
> +
Unless I am missing something, neither __clk_get_flags() nor the new
__clk_set_flags is exported.

Did you try to build and load the driver as module ?

Thanks,
Guenter


From festevam at gmail.com  Sun Apr  7 19:13:45 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Sun,  7 Apr 2013 20:13:45 -0300
Subject: [PATCH] ARM: dts: imx6dl-wandboard: Add USB Host support
Message-ID: <1365376426-13919-1-git-send-email-festevam@gmail.com>

From: Fabio Estevam <fabio.estevam at freescale.com>

Add USB Host1 port support.

Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
---
 arch/arm/boot/dts/imx6dl-wandboard.dts |    4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/imx6dl-wandboard.dts b/arch/arm/boot/dts/imx6dl-wandboard.dts
index d3ea90a..735911b 100644
--- a/arch/arm/boot/dts/imx6dl-wandboard.dts
+++ b/arch/arm/boot/dts/imx6dl-wandboard.dts
@@ -38,3 +38,7 @@
 	pinctrl-0 = <&pinctrl_usdhc3_2>;
 	status = "okay";
 };
+
+&usbh1 {
+	status = "okay";
+};
-- 
1.7.9.5



From ben at decadent.org.uk  Sun Apr  7 18:45:42 2013
From: ben at decadent.org.uk (Ben Hutchings)
Date: Sun, 07 Apr 2013 23:45:42 +0100
Subject: [01/74] clockevents: Don't allow dummy broadcast timers
In-Reply-To: <lsq.1365374742.214522651@decadent.org.uk>
Message-ID: <lsq.1365374742.974515383@decadent.org.uk>

3.2.43-rc1 review patch.  If anyone has any objections, please let me know.

------------------

From: Mark Rutland <mark.rutland at arm.com>

commit a7dc19b8652c862d5b7c4d2339bd3c428bd29c4a upstream.

Currently tick_check_broadcast_device doesn't reject clock_event_devices
with CLOCK_EVT_FEAT_DUMMY, and may select them in preference to real
hardware if they have a higher rating value. In this situation, the
dummy timer is responsible for broadcasting to itself, and the core
clockevents code may attempt to call non-existent callbacks for
programming the dummy, eventually leading to a panic.

This patch makes tick_check_broadcast_device always reject dummy timers,
preventing this problem.

Signed-off-by: Mark Rutland <mark.rutland at arm.com>
Cc: linux-arm-kernel at lists.infradead.org
Cc: Jon Medhurst (Tixy) <tixy at linaro.org>
Signed-off-by: Thomas Gleixner <tglx at linutronix.de>
Signed-off-by: Ben Hutchings <ben at decadent.org.uk>
---
 kernel/time/tick-broadcast.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/kernel/time/tick-broadcast.c
+++ b/kernel/time/tick-broadcast.c
@@ -66,7 +66,8 @@ static void tick_broadcast_start_periodi
  */
 int tick_check_broadcast_device(struct clock_event_device *dev)
 {
-	if ((tick_broadcast_device.evtdev &&
+	if ((dev->features & CLOCK_EVT_FEAT_DUMMY) ||
+	    (tick_broadcast_device.evtdev &&
 	     tick_broadcast_device.evtdev->rating >= dev->rating) ||
 	     (dev->features & CLOCK_EVT_FEAT_C3STOP))
 		return 0;



From sebastian.hesselbarth at gmail.com  Sun Apr  7 19:49:24 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Mon, 08 Apr 2013 01:49:24 +0200
Subject: [v5] clk: add si5351 i2c common clock driver
In-Reply-To: <20130407225046.GA16326@roeck-us.net>
References: <1365139415-17815-1-git-send-email-sebastian.hesselbarth@gmail.com>
 <20130407225046.GA16326@roeck-us.net>
Message-ID: <51620604.4070204@gmail.com>

On 04/08/2013 12:50 AM, Guenter Roeck wrote:
> On Fri, Apr 05, 2013 at 05:23:35AM -0000, Sebastian Hesselbarth wrote:
>> This patch adds a common clock driver for Silicon Labs Si5351a/b/c
>> i2c programmable clock generators. Currently, the driver supports
>> DT kernels only and VXCO feature of si5351b is not implemented. DT
>> bindings selectively allow to overwrite stored Si5351 configuration
>> which is very helpful for clock generators with empty eeprom
>> configuration. Corresponding device tree binding documentation is
>> also added.
>>
>> Signed-off-by: Sebastian Hesselbarth<sebastian.hesselbarth at gmail.com>
>> Tested-by: Daniel Mack<zonque at gmail.com>
>>
> [ ... ]
>
>> +static inline void _si5351_msynth_set_pll_master(
>> +	struct si5351_driver_data *drvdata, unsigned char num, int is_master)
>> +{
>> +	unsigned long flags;
>> +
>> +	if (num>  8 ||
>> +	    (drvdata->variant == SI5351_VARIANT_A3&&  num>  3))
>> +		return;
>> +
>> +	flags = __clk_get_flags(drvdata->msynth[num].hw.clk);
>> +	if (is_master)
>> +		flags |= CLK_SET_RATE_PARENT;
>> +	else
>> +		flags&= ~CLK_SET_RATE_PARENT;
>> +	__clk_set_flags(drvdata->msynth[num].hw.clk, flags);
>> +}
>> +
> Unless I am missing something, neither __clk_get_flags() nor the new
> __clk_set_flags is exported.
>
> Did you try to build and load the driver as module ?

Well, good catch. I didn't try to build v5 as a module, but I guess it
will fail. But I consider this as something that has to be addressed in
clk framework itself, not in this patch. There will be other
clk-providers built as module in the future for sure.

Sebastian


From timur at tabi.org  Sun Apr  7 20:13:38 2013
From: timur at tabi.org (Timur Tabi)
Date: Sun, 07 Apr 2013 19:13:38 -0500
Subject: [PATCH v2 04/11] ASoC: fsl-ssi: Add SACNT definitions
In-Reply-To: <1365362721-3731-5-git-send-email-mpa@pengutronix.de>
References: <1365362721-3731-1-git-send-email-mpa@pengutronix.de>
 <1365362721-3731-5-git-send-email-mpa@pengutronix.de>
Message-ID: <51620BB2.5070900@tabi.org>

Markus Pargmann wrote:
> Add definitions for AC97 control register.
>
> Signed-off-by: Markus Pargmann<mpa at pengutronix.de>

Acked-by: Timur Tabi <timur at tabi.org>

-- 
Timur Tabi


From linux at roeck-us.net  Sun Apr  7 20:17:25 2013
From: linux at roeck-us.net (Guenter Roeck)
Date: Sun, 7 Apr 2013 17:17:25 -0700
Subject: [v5] clk: add si5351 i2c common clock driver
In-Reply-To: <51620604.4070204@gmail.com>
References: <1365139415-17815-1-git-send-email-sebastian.hesselbarth@gmail.com>
 <20130407225046.GA16326@roeck-us.net> <51620604.4070204@gmail.com>
Message-ID: <20130408001725.GA16648@roeck-us.net>

On Mon, Apr 08, 2013 at 01:49:24AM +0200, Sebastian Hesselbarth wrote:
> On 04/08/2013 12:50 AM, Guenter Roeck wrote:
> >On Fri, Apr 05, 2013 at 05:23:35AM -0000, Sebastian Hesselbarth wrote:
> >>This patch adds a common clock driver for Silicon Labs Si5351a/b/c
> >>i2c programmable clock generators. Currently, the driver supports
> >>DT kernels only and VXCO feature of si5351b is not implemented. DT
> >>bindings selectively allow to overwrite stored Si5351 configuration
> >>which is very helpful for clock generators with empty eeprom
> >>configuration. Corresponding device tree binding documentation is
> >>also added.
> >>
> >>Signed-off-by: Sebastian Hesselbarth<sebastian.hesselbarth at gmail.com>
> >>Tested-by: Daniel Mack<zonque at gmail.com>
> >>
> >[ ... ]
> >
> >>+static inline void _si5351_msynth_set_pll_master(
> >>+	struct si5351_driver_data *drvdata, unsigned char num, int is_master)
> >>+{
> >>+	unsigned long flags;
> >>+
> >>+	if (num>  8 ||
> >>+	    (drvdata->variant == SI5351_VARIANT_A3&&  num>  3))
> >>+		return;
> >>+
> >>+	flags = __clk_get_flags(drvdata->msynth[num].hw.clk);
> >>+	if (is_master)
> >>+		flags |= CLK_SET_RATE_PARENT;
> >>+	else
> >>+		flags&= ~CLK_SET_RATE_PARENT;
> >>+	__clk_set_flags(drvdata->msynth[num].hw.clk, flags);
> >>+}
> >>+
> >Unless I am missing something, neither __clk_get_flags() nor the new
> >__clk_set_flags is exported.
> >
> >Did you try to build and load the driver as module ?
> 
> Well, good catch. I didn't try to build v5 as a module, but I guess it
> will fail. But I consider this as something that has to be addressed in
> clk framework itself, not in this patch. There will be other
> clk-providers built as module in the future for sure.
> 
Sure, but you provided the patch to make __clk_set_flags global. To avoid
build failures, I would suggest to either submit a patch to export the
missing functions, or to remove the ability to build the driver as module.

On a side note, do you happen to know anyone working on drivers for Si5319 or
Si5368 ?

Thanks,
Guenter


From timur at tabi.org  Sun Apr  7 20:18:50 2013
From: timur at tabi.org (Timur Tabi)
Date: Sun, 07 Apr 2013 19:18:50 -0500
Subject: [PATCH v2 05/11] ASoC: fsl-ssi: Add support for imx-pcm-fiq
In-Reply-To: <1365362721-3731-6-git-send-email-mpa@pengutronix.de>
References: <1365362721-3731-1-git-send-email-mpa@pengutronix.de>
 <1365362721-3731-6-git-send-email-mpa@pengutronix.de>
Message-ID: <51620CEA.3010703@tabi.org>

Markus Pargmann wrote:
> Add support for non-dma pcm for imx platforms with imx-pcm-fiq support.
> Instead of imx-pcm-audio, in this case imx-pcm-fiq-audio device is added
> and the SIER flags are set differently.

So just to be clear, this is interrupt-driven SSI audio?  So you're 
generating an interrupt every time the transmit FIFO goes below the threshold?

I wonder if it makes sense to enable both FIFOs, so that you take half as 
many interrupts per second.

>
> Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
> ---
>   sound/soc/fsl/fsl_ssi.c | 70 ++++++++++++++++++++++++++++++++++++++++---------
>   1 file changed, 58 insertions(+), 12 deletions(-)
>
> diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
> index 7decbd9..afb5a23 100644
> --- a/sound/soc/fsl/fsl_ssi.c
> +++ b/sound/soc/fsl/fsl_ssi.c
> @@ -120,10 +120,12 @@ struct fsl_ssi_private {
>
>   	bool new_binding;
>   	bool ssi_on_imx;
> +	bool dma;

Can you rename this to "use_dma" or something like that?

>   	struct clk *clk;
>   	struct platform_device *imx_pcm_pdev;
>   	struct imx_pcm_dma_params dma_params_tx;
>   	struct imx_pcm_dma_params dma_params_rx;
> +	struct imx_pcm_fiq_params fiq_params;
>
>   	struct {
>   		unsigned int rfrc;
> @@ -353,7 +355,8 @@ static int fsl_ssi_startup(struct snd_pcm_substream *substream,
>   		 */
>
>   		/* Enable the interrupts and DMA requests */
> -		write_ssi(SIER_FLAGS, &ssi->sier);
> +		if (ssi_private->dma)
> +			write_ssi(SIER_FLAGS, &ssi->sier);
>
>   		/*
>   		 * Set the watermark for transmit FIFI 0 and receive FIFO 0. We
> @@ -520,6 +523,18 @@ static int fsl_ssi_trigger(struct snd_pcm_substream *substream, int cmd,
>   		return -EINVAL;
>   	}
>
> +	if (!ssi_private->dma) {
> +		if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
> +			write_ssi(CCSR_SSI_SOR_TX_CLR, &ssi->sor);
> +			write_ssi(CCSR_SSI_SIER_TIE | CCSR_SSI_SIER_TFE0_EN,
> +					&ssi->sier);
> +		} else {
> +			write_ssi(CCSR_SSI_SOR_RX_CLR, &ssi->sor);
> +			write_ssi(CCSR_SSI_SIER_RIE | CCSR_SSI_SIER_RFF0_EN,
> +					&ssi->sier);
> +		}
> +	}
> +
>   	return 0;
>   }
>
> @@ -680,6 +695,8 @@ static int fsl_ssi_probe(struct platform_device *pdev)
>   	       sizeof(fsl_ssi_dai_template));
>   	ssi_private->cpu_dai_drv.name = ssi_private->name;
>
> +	ssi_private->dma = !of_property_read_bool(np, "fsl,imx-fiq");

Instead of looking for the FIQ property, maybe you should just look for 
the absence of a DMA property/node, and then default to interrupts if 
there is no DMA.  That would make it more generic, and even work on 
non-IMX systems.

-- 
Timur Tabi


From timur at tabi.org  Sun Apr  7 20:20:20 2013
From: timur at tabi.org (Timur Tabi)
Date: Sun, 07 Apr 2013 19:20:20 -0500
Subject: [PATCH v2 10/11] ASoC: fsl: Move fsl-ssi binding doc to sound/
In-Reply-To: <1365362721-3731-11-git-send-email-mpa@pengutronix.de>
References: <1365362721-3731-1-git-send-email-mpa@pengutronix.de>
 <1365362721-3731-11-git-send-email-mpa@pengutronix.de>
Message-ID: <51620D44.3030105@tabi.org>

Markus Pargmann wrote:
> fsl-ssi was located in powerpc/fsl/ssi.txt. This is no powerpc specific
> device, so it should be moved to sound/ as it connects to differen audio
> codecs.

The only problem with this is that the driver supports two bindings, the 
original binding and a newer one.  The original binding is used only on 
PowerPC.

I'm not sure that's relevant, though.

-- 
Timur Tabi


From magnus.damm at gmail.com  Sun Apr  7 20:55:38 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Mon, 8 Apr 2013 09:55:38 +0900
Subject: [PATCH] irqchip: irqc: Add runtime PM support
In-Reply-To: <20130405022623.GD29203@verge.net.au>
References: <1365056466-23710-1-git-send-email-horms+renesas@verge.net.au>
 <20130405022623.GD29203@verge.net.au>
Message-ID: <CANqRtoRBX6tmickt5bApnMc+dhtL27GCMojmh52jfY3P8tPx2Q@mail.gmail.com>

Hi Simon,

On Fri, Apr 5, 2013 at 11:26 AM, Simon Horman <horms at verge.net.au> wrote:
> On Thu, Apr 04, 2013 at 03:21:06PM +0900, Simon Horman wrote:
>> This was tested using the SMSC LAN on the APE6EVM board.
>>
>> Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
>
> Magnus, Morimoto-san, could you review this?

Thanks for working on Runtime PM for the IRQC driver, this code looks
fine to me. In the future we probably want to try control the usage
count based on enable()/disable() callbacks in a more fine grained
fashion, but I wonder how much that would actually help us since I
don't think we can turn off the power domain where IRQC is located
anyway.

Simon, please remember to also merge your code for IRQC MSTP bit
control on r8a73a4 and/or r8a7790. Without that I can't really see how
Runtime PM can control any actual hardware.

Thanks,

/ magnus


From magnus.damm at gmail.com  Sun Apr  7 21:03:43 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Mon, 8 Apr 2013 10:03:43 +0900
Subject: [PATCH v2] irqchip: renesas-intc-irqpin: DT binding for sense
 bitfield width
In-Reply-To: <Pine.LNX.4.64.1304051128090.997@axis700.grange>
References: <Pine.LNX.4.64.1304051128090.997@axis700.grange>
Message-ID: <CANqRtoQtvNPPFxoe9st3M2g8gTek3LYucRLupV_p6GgfoiCY6A@mail.gmail.com>

Hi Guennadi,

On Fri, Apr 5, 2013 at 6:33 PM, Guennadi Liakhovetski
<g.liakhovetski at gmx.de> wrote:
> Most Renesas irqpin controllers have 4-bit sense fields, however, some
> have different widths. This patch adds a DT binding to optionally
> specify such non-standard values.
>
> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas at gmail.com>
> ---
>
> v2: is no longer based on an earlier "ARM: shmobile: irqpin: fix handling
> of spurious interrupts in DT case" patch, which needs more work.
>
>  .../interrupt-controller/renesas,intc-irqpin.txt   |   13 +++++++++++++
>  drivers/irqchip/irq-renesas-intc-irqpin.c          |    5 +++++
>  2 files changed, 18 insertions(+), 0 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.txt
>
> diff --git a/Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.txt b/Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.txt
> new file mode 100644
> index 0000000..c6f09b7
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.txt
> @@ -0,0 +1,13 @@
> +DT bindings for the R-/SH-Mobile irqpin controller
> +
> +Required properties:
> +
> +- compatible: has to be "renesas,intc-irqpin"
> +- #interrupt-cells: has to be <2>
> +
> +Optional properties:
> +
> +- any properties, listed in interrupts.txt in this directory, and any standard
> +  resource allocation properties
> +- sense-bitfield-width: width of a single sense bitfield in the SENSE register,
> +  if different from the default 4 bits
> diff --git a/drivers/irqchip/irq-renesas-intc-irqpin.c b/drivers/irqchip/irq-renesas-intc-irqpin.c
> index 5a68e5a..7a02dfe 100644
> --- a/drivers/irqchip/irq-renesas-intc-irqpin.c
> +++ b/drivers/irqchip/irq-renesas-intc-irqpin.c
> @@ -18,6 +18,7 @@
>   */
>
>  #include <linux/init.h>
> +#include <linux/of.h>
>  #include <linux/platform_device.h>
>  #include <linux/spinlock.h>
>  #include <linux/interrupt.h>
> @@ -429,6 +430,10 @@ static int intc_irqpin_probe(struct platform_device *pdev)
>                 }
>         }
>
> +       if (!pdata)
> +               of_property_read_u32(pdev->dev.of_node, "sense-bitfield-width",
> +                                    &p->config.sense_bitfield_width);
> +

Thanks for remaking this patch into V2. I am OK with the actual code,
but I wonder why you don't keep the above together with the rest of
the configuration setup code somewhere below the comment "/* deal with
driver instance configuration */".

Cheers,

/ magnus


From kuninori.morimoto.gx at renesas.com  Sun Apr  7 21:07:16 2013
From: kuninori.morimoto.gx at renesas.com (Kuninori Morimoto)
Date: Sun, 07 Apr 2013 18:07:16 -0700 (PDT)
Subject: [RFC/PATCH 0/7] ARCH: shmobile: defconfig consolidation
In-Reply-To: <1365046193-19369-1-git-send-email-horms+renesas@verge.net.au>
References: <1365046193-19369-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <87sj31omnz.wl%kuninori.morimoto.gx@renesas.com>


Hi Simon

> Simon Horman (7):
>  ARM: shmobile: prune defconfig
>  ARM: shmobile: make defconfig canonical
>  ARM: shmobile: Add kzm9d to consolidated defconfig
>  ARM: shmobile: Add mackerel to consolidated defconfig
>  ARM: shmobile: defconfig: Remove armadillo800eva defconfig
>  ARM: shmobile: defconfig: Remove kzm9d defconfig
>  ARM: shmobile: defconfig: Remove mackerel defconfig
(snip)
> Morimoto-san, I suspect it may be possible to add support for the
> bockw board to the consolidated defconfig if its boot loader supports
> booting using a zImage. In this case even though the base memory address
> is not the same as the boards above it should be possible to specify
> the base address from the boot loader. As I do not have a bockw board
> I am wondering if you could investigate this.

I tested shmobile_defconfig on Bock-W board.
It works with...

 1) I added R8A7778 SoC on .config
 2) I added Bock-W on .config
 3) I fixuped CONFIG_MEMORY_START, CONFIG_MEMORY_SIZE value on .config

It is correct method ?

Best regards
---
Kuninori Morimoto


From jon-hunter at ti.com  Sun Apr  7 21:17:08 2013
From: jon-hunter at ti.com (Jon Hunter)
Date: Sun, 7 Apr 2013 20:17:08 -0500
Subject: [PATCH 3/3] ARM: dts: Add OMAP3430 SDP NOR flash memory binding
In-Reply-To: <1365383828-25627-1-git-send-email-jon-hunter@ti.com>
References: <1365383828-25627-1-git-send-email-jon-hunter@ti.com>
Message-ID: <1365383828-25627-3-git-send-email-jon-hunter@ti.com>

Add device-tree node for the 128MB NOR on the OMAP3423-SDP board.

Signed-off-by: Jon Hunter <jon-hunter at ti.com>
---
 arch/arm/boot/dts/omap3430-sdp.dts |   51 +++++++++++++++++++++++++++++++++++-
 1 file changed, 50 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/omap3430-sdp.dts b/arch/arm/boot/dts/omap3430-sdp.dts
index 44d2191..144ae43 100644
--- a/arch/arm/boot/dts/omap3430-sdp.dts
+++ b/arch/arm/boot/dts/omap3430-sdp.dts
@@ -45,9 +45,58 @@
 };
 
 &gpmc {
-	ranges = <1 0 0x28000000 0x08000000>,
+	ranges = <0 0 0x10000000 0x08000000>,
+		 <1 0 0x28000000 0x08000000>,
 		 <2 0 0x20000000 0x10000000>;
 
+	nor at 0,0 {
+		compatible = "cfi-flash";
+		linux,mtd-name= "intel,pf48f6000m0y1be";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		reg = <0 0 0x08000000>;
+		bank-width = <2>;
+
+		gpmc,mux-add-data = <2>;
+		gpmc,cs-on-ns = <0>;
+		gpmc,cs-rd-off-ns = <186>;
+		gpmc,cs-wr-off-ns = <186>;
+		gpmc,adv-on-ns = <12>;
+		gpmc,adv-rd-off-ns = <48>;
+		gpmc,adv-wr-off-ns = <48>;
+		gpmc,oe-on-ns = <54>;
+		gpmc,oe-off-ns = <168>;
+		gpmc,we-on-ns = <54>;
+		gpmc,we-off-ns = <168>;
+		gpmc,rd-cycle-ns = <186>;
+		gpmc,wr-cycle-ns = <186>;
+		gpmc,access-ns = <114>;
+		gpmc,page-burst-access-ns = <6>;
+		gpmc,bus-turnaround-ns = <12>;
+		gpmc,cycle2cycle-delay-ns = <18>;
+		gpmc,wr-data-mux-bus-ns = <90>;
+		gpmc,wr-access-ns = <186>;
+		gpmc,cycle2cycle-samecsen;
+		gpmc,cycle2cycle-diffcsen;
+
+		partition at 0 {
+			label = "bootloader-nor";
+			reg = <0 0x40000>;
+		};
+		partition at 0x40000 {
+			label = "params-nor";
+			reg = <0x40000 0x40000>;
+		};
+		partition at 0x80000 {
+			label = "kernel-nor";
+			reg = <0x80000 0x200000>;
+		};
+		partition at 0x280000 {
+			label = "filesystem-nor";
+			reg = <0x240000 0x7d80000>;
+		};
+	};
+
 	nand at 1,0 {
 		linux,mtd-name= "micron,mt29f1g08abb";
 		#address-cells = <1>;
-- 
1.7.10.4



From jon-hunter at ti.com  Sun Apr  7 21:17:07 2013
From: jon-hunter at ti.com (Jon Hunter)
Date: Sun, 7 Apr 2013 20:17:07 -0500
Subject: [PATCH 2/3] ARM: dts: Add NOR flash bindings for OMAP2420 H4
In-Reply-To: <1365383828-25627-1-git-send-email-jon-hunter@ti.com>
References: <1365383828-25627-1-git-send-email-jon-hunter@ti.com>
Message-ID: <1365383828-25627-2-git-send-email-jon-hunter@ti.com>

Add device-tree node for the 64MB NOR on the OMAP2420-H4 board.

Signed-off-by: Jon Hunter <jon-hunter at ti.com>
---
 arch/arm/boot/dts/omap2420-h4.dts |   46 +++++++++++++++++++++++++++++++++++++
 1 file changed, 46 insertions(+)

diff --git a/arch/arm/boot/dts/omap2420-h4.dts b/arch/arm/boot/dts/omap2420-h4.dts
index 9b0d077..68282ee 100644
--- a/arch/arm/boot/dts/omap2420-h4.dts
+++ b/arch/arm/boot/dts/omap2420-h4.dts
@@ -18,3 +18,49 @@
 		reg = <0x80000000 0x4000000>; /* 64 MB */
 	};
 };
+
+&gpmc {
+	ranges = <0 0 0x08000000 0x04000000>;
+
+	nor at 0,0 {
+		compatible = "cfi-flash";
+		linux,mtd-name= "intel,ge28f256l18b85";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		reg = <0 0 0x04000000>;
+		bank-width = <2>;
+
+		gpmc,mux-add-data = <2>;
+		gpmc,cs-on-ns = <10>;
+		gpmc,cs-rd-off-ns = <160>;
+		gpmc,cs-wr-off-ns = <160>;
+		gpmc,adv-on-ns = <20>;
+		gpmc,adv-rd-off-ns = <50>;
+		gpmc,adv-wr-off-ns = <50>;
+		gpmc,oe-on-ns = <60>;
+		gpmc,oe-off-ns = <120>;
+		gpmc,we-on-ns = <60>;
+		gpmc,we-off-ns = <120>;
+		gpmc,rd-cycle-ns = <170>;
+		gpmc,wr-cycle-ns = <170>;
+		gpmc,access-ns = <150>;
+		gpmc,page-burst-access-ns = <10>;
+
+		partition at 0 {
+			label = "bootloader";
+			reg = <0 0x20000>;
+		};
+		partition at 0x20000 {
+			label = "params";
+			reg = <0x20000 0x20000>;
+		};
+		partition at 0x40000 {
+			label = "kernel";
+			reg = <0x40000 0x200000>;
+		};
+		partition at 0x240000 {
+			label = "file-system";
+			reg = <0x240000 0x3dc0000>;
+		};
+	};
+};
-- 
1.7.10.4



From magnus.damm at gmail.com  Sun Apr  7 21:23:18 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Mon, 08 Apr 2013 10:23:18 +0900
Subject: [PATCH 00/02] ARM: shmobile: r8a7790 Lager arch timer fixes
Message-ID: <20130408012318.13555.58237.sendpatchset@w520>

ARM: shmobile: r8a7790 Lager arch timer fixes

[PATCH 01/02] ARM: shmobile: force enable of r8a7790 arch timer 
[PATCH 02/02] ARM: shmobile: use r8a7790 timer setup code on Lager

This mini-series contains fixes to start the arch timer on
r8a7790 and the Lager board regardless of boot loader setting.

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 Written against renesas-next-20130405v2 in renesas.git
 
 arch/arm/mach-shmobile/board-lager.c          |    2 +-
 arch/arm/mach-shmobile/include/mach/r8a7790.h |    1 +
 arch/arm/mach-shmobile/setup-r8a7790.c        |   14 +++++++++++++-
 3 files changed, 15 insertions(+), 2 deletions(-)


From magnus.damm at gmail.com  Sun Apr  7 21:23:28 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Mon, 08 Apr 2013 10:23:28 +0900
Subject: [PATCH 01/02] ARM: shmobile: force enable of r8a7790 arch timer
In-Reply-To: <20130408012318.13555.58237.sendpatchset@w520>
References: <20130408012318.13555.58237.sendpatchset@w520>
Message-ID: <20130408012328.13555.44487.sendpatchset@w520>

From: Magnus Damm <damm at opensource.se>

Implement a SoC-specific timer init function for
r8a7790 that makes sure the architected timer
is started regardless of boot loader setting.

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 arch/arm/mach-shmobile/include/mach/r8a7790.h |    1 +
 arch/arm/mach-shmobile/setup-r8a7790.c        |   14 +++++++++++++-
 2 files changed, 14 insertions(+), 1 deletion(-)

--- 0001/arch/arm/mach-shmobile/include/mach/r8a7790.h
+++ work/arch/arm/mach-shmobile/include/mach/r8a7790.h	2013-04-08 10:13:38.000000000 +0900
@@ -4,5 +4,6 @@
 void r8a7790_add_standard_devices(void);
 void r8a7790_clock_init(void);
 void r8a7790_pinmux_init(void);
+void r8a7790_timer_init(void);
 
 #endif /* __ASM_R8A7790_H__ */
--- 0001/arch/arm/mach-shmobile/setup-r8a7790.c
+++ work/arch/arm/mach-shmobile/setup-r8a7790.c	2013-04-08 10:13:38.000000000 +0900
@@ -117,6 +117,18 @@ void __init r8a7790_add_standard_devices
 	r8a7790_register_irqc(0);
 }
 
+void __init r8a7790_timer_init(void)
+{
+	void __iomem *cntcr;
+
+	/* make sure arch timer is started by setting bit 0 of CNTCT */
+	cntcr = ioremap(0xe6080000, PAGE_SIZE);
+	iowrite32(1, cntcr);
+	iounmap(cntcr);
+
+	shmobile_timer_init();
+}
+
 #ifdef CONFIG_USE_OF
 void __init r8a7790_add_standard_devices_dt(void)
 {
@@ -131,7 +143,7 @@ static const char *r8a7790_boards_compat
 DT_MACHINE_START(R8A7790_DT, "Generic R8A7790 (Flattened Device Tree)")
 	.init_irq	= irqchip_init,
 	.init_machine	= r8a7790_add_standard_devices_dt,
-	.init_time	= shmobile_timer_init,
+	.init_time	= r8a7790_timer_init,
 	.dt_compat	= r8a7790_boards_compat_dt,
 MACHINE_END
 #endif /* CONFIG_USE_OF */


From jon-hunter at ti.com  Sun Apr  7 21:17:06 2013
From: jon-hunter at ti.com (Jon Hunter)
Date: Sun, 7 Apr 2013 20:17:06 -0500
Subject: [PATCH 1/3] ARM: dts: Update OMAP3430 SDP NAND and ONENAND properties
Message-ID: <1365383828-25627-1-git-send-email-jon-hunter@ti.com>

The GPMC timing properties for device-tree have been updated by adding
a "-ns" or "-ps" suffix to indicate the units of time the property
represents (as suggested by Rob Herring). Therefore, update the timing
property names for the OMAP3430 SDP NAND and ONENAND devices.

Signed-off-by: Jon Hunter <jon-hunter at ti.com>
---

Hi Benoit, this is a changed that is going to be introduced for v3.10.
Feel free to squash this with the patch "ARM: dts: OMAP3: Add support
for OMAP3430 SDP board" that you have queued for v3.10 if you prefer.

 arch/arm/boot/dts/omap3430-sdp.dts |   56 ++++++++++++++++++------------------
 1 file changed, 28 insertions(+), 28 deletions(-)

diff --git a/arch/arm/boot/dts/omap3430-sdp.dts b/arch/arm/boot/dts/omap3430-sdp.dts
index 05cd8ba..44d2191 100644
--- a/arch/arm/boot/dts/omap3430-sdp.dts
+++ b/arch/arm/boot/dts/omap3430-sdp.dts
@@ -57,20 +57,20 @@
 
 		ti,nand-ecc-opt = "sw";
 		gpmc,device-nand;
-		gpmc,cs-on = <0>;
-		gpmc,cs-rd-off = <36>;
-		gpmc,cs-wr-off = <36>;
-		gpmc,adv-on = <6>;
-		gpmc,adv-rd-off = <24>;
-		gpmc,adv-wr-off = <36>;
-		gpmc,oe-on = <6>;
-		gpmc,oe-off = <48>;
-		gpmc,we-on = <6>;
-		gpmc,we-off = <30>;
-		gpmc,rd-cycle = <72>;
-		gpmc,wr-cycle = <72>;
-		gpmc,access = <54>;
-		gpmc,wr-access = <30>;
+		gpmc,cs-on-ns = <0>;
+		gpmc,cs-rd-off-ns = <36>;
+		gpmc,cs-wr-off-ns = <36>;
+		gpmc,adv-on-ns = <6>;
+		gpmc,adv-rd-off-ns = <24>;
+		gpmc,adv-wr-off-ns = <36>;
+		gpmc,oe-on-ns = <6>;
+		gpmc,oe-off-ns = <48>;
+		gpmc,we-on-ns = <6>;
+		gpmc,we-off-ns = <30>;
+		gpmc,rd-cycle-ns = <72>;
+		gpmc,wr-cycle-ns = <72>;
+		gpmc,access-ns = <54>;
+		gpmc,wr-access-ns = <30>;
 
 		partition at 0 {
 			label = "xloader-nand";
@@ -102,20 +102,20 @@
 
 		gpmc,device-width = <2>;
 		gpmc,mux-add-data = <2>;
-		gpmc,cs-on = <0>;
-		gpmc,cs-rd-off = <84>;
-		gpmc,cs-wr-off = <72>;
-		gpmc,adv-on = <0>;
-		gpmc,adv-rd-off = <18>;
-		gpmc,adv-wr-off = <18>;
-		gpmc,oe-on = <30>;
-		gpmc,oe-off = <84>;
-		gpmc,we-on = <0>;
-		gpmc,we-off = <42>;
-		gpmc,rd-cycle = <108>;
-		gpmc,wr-cycle = <96>;
-		gpmc,access = <78>;
-		gpmc,wr-data-mux-bus = <30>;
+		gpmc,cs-on-ns = <0>;
+		gpmc,cs-rd-off-ns = <84>;
+		gpmc,cs-wr-off-ns = <72>;
+		gpmc,adv-on-ns = <0>;
+		gpmc,adv-rd-off-ns = <18>;
+		gpmc,adv-wr-off-ns = <18>;
+		gpmc,oe-on-ns = <30>;
+		gpmc,oe-off-ns = <84>;
+		gpmc,we-on-ns = <0>;
+		gpmc,we-off-ns = <42>;
+		gpmc,rd-cycle-ns = <108>;
+		gpmc,wr-cycle-ns = <96>;
+		gpmc,access-ns = <78>;
+		gpmc,wr-data-mux-bus-ns = <30>;
 
 		partition at 0 {
 			label = "xloader-onenand";
-- 
1.7.10.4



From magnus.damm at gmail.com  Sun Apr  7 21:23:37 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Mon, 08 Apr 2013 10:23:37 +0900
Subject: [PATCH 02/02] ARM: shmobile: use r8a7790 timer setup code on Lager
In-Reply-To: <20130408012318.13555.58237.sendpatchset@w520>
References: <20130408012318.13555.58237.sendpatchset@w520>
Message-ID: <20130408012337.13555.70590.sendpatchset@w520>

From: Magnus Damm <damm at opensource.se>

Use the r8a7790 timer init function on Lager
to make sure the architected timer is started
regardless of boot loader setting.

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 arch/arm/mach-shmobile/board-lager.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- 0001/arch/arm/mach-shmobile/board-lager.c
+++ work/arch/arm/mach-shmobile/board-lager.c	2013-04-08 10:15:49.000000000 +0900
@@ -40,7 +40,7 @@ static const char *lager_boards_compat_d
 
 DT_MACHINE_START(LAGER_DT, "lager")
 	.init_irq	= irqchip_init,
-	.init_time	= shmobile_timer_init,
+	.init_time	= r8a7790_timer_init,
 	.init_machine	= lager_add_standard_devices,
 	.dt_compat	= lager_boards_compat_dt,
 MACHINE_END


From baozich at gmail.com  Sun Apr  7 21:22:53 2013
From: baozich at gmail.com (Chen Baozi)
Date: Mon, 8 Apr 2013 09:22:53 +0800
Subject: [PATCH] gpio: update gpio Chinese documentation
Message-ID: <20130408012253.GA2545@cbz-workstation>

Since the GENERIC_GPIO has been removed and the documentation of it
has been modified, this patch updates the corresponding documentation of
gpio in Chinese.

Signed-off-by: Chen Baozi <baozich at gmail.com>
---
 Documentation/zh_CN/gpio.txt | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/Documentation/zh_CN/gpio.txt b/Documentation/zh_CN/gpio.txt
index 4fa7b4e..d5b8f01 100644
--- a/Documentation/zh_CN/gpio.txt
+++ b/Documentation/zh_CN/gpio.txt
@@ -84,10 +84,10 @@ GPIO ??
 ?????????????(??????????????????,???
 ????????? GPIO ????????????????????)
 
-????,?????????????????????????????
-??? Kconfig ???? GENERIC_GPIO??? (??? true)????
-?? <asm/gpio.h> ????????? GPIO ???????? Kconfig
-???????GENERIC_GPIO????????:
+????,????????????????????????????????
+??? Kconfig ??? ARCH_REQUIRE_GPIOLIB ?? ARCH_WANT_OPTIONAL_GPIOLIB
+????????? GPIO ???????? Kconfig ???????GENERIC_GPIO?
+???????:
 
 	#include <linux/gpio.h>
 
-- 
1.8.1.4



From horms at verge.net.au  Sun Apr  7 21:26:52 2013
From: horms at verge.net.au (Simon Horman)
Date: Mon, 8 Apr 2013 10:26:52 +0900
Subject: [PATCH] irqchip: irqc: Add runtime PM support
In-Reply-To: <CANqRtoRBX6tmickt5bApnMc+dhtL27GCMojmh52jfY3P8tPx2Q@mail.gmail.com>
References: <1365056466-23710-1-git-send-email-horms+renesas@verge.net.au>
 <20130405022623.GD29203@verge.net.au>
 <CANqRtoRBX6tmickt5bApnMc+dhtL27GCMojmh52jfY3P8tPx2Q@mail.gmail.com>
Message-ID: <20130408012651.GB26935@verge.net.au>

On Mon, Apr 08, 2013 at 09:55:38AM +0900, Magnus Damm wrote:
> Hi Simon,
> 
> On Fri, Apr 5, 2013 at 11:26 AM, Simon Horman <horms at verge.net.au> wrote:
> > On Thu, Apr 04, 2013 at 03:21:06PM +0900, Simon Horman wrote:
> >> This was tested using the SMSC LAN on the APE6EVM board.
> >>
> >> Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
> >
> > Magnus, Morimoto-san, could you review this?
> 
> Thanks for working on Runtime PM for the IRQC driver, this code looks
> fine to me. In the future we probably want to try control the usage
> count based on enable()/disable() callbacks in a more fine grained
> fashion, but I wonder how much that would actually help us since I
> don't think we can turn off the power domain where IRQC is located
> anyway.
> 
> Simon, please remember to also merge your code for IRQC MSTP bit
> control on r8a73a4 and/or r8a7790. Without that I can't really see how
> Runtime PM can control any actual hardware.

I'm unsure which code you are referring to.


From kuninori.morimoto.gx at renesas.com  Sun Apr  7 21:29:46 2013
From: kuninori.morimoto.gx at renesas.com (Kuninori Morimoto)
Date: Sun, 07 Apr 2013 18:29:46 -0700 (PDT)
Subject: [PATCH 00/02] ARM: shmobile: r8a7790 Lager arch timer fixes
In-Reply-To: <20130408012318.13555.58237.sendpatchset@w520>
References: <20130408012318.13555.58237.sendpatchset@w520>
Message-ID: <87r4ilolmh.wl%kuninori.morimoto.gx@renesas.com>


Hi

> ARM: shmobile: r8a7790 Lager arch timer fixes
> 
> [PATCH 01/02] ARM: shmobile: force enable of r8a7790 arch timer 
> [PATCH 02/02] ARM: shmobile: use r8a7790 timer setup code on Lager
> 
> This mini-series contains fixes to start the arch timer on
> r8a7790 and the Lager board regardless of boot loader setting.
> 
> Signed-off-by: Magnus Damm <damm at opensource.se>
> ---

I guess shmobile_timer_init() will be conflict (or compile error)
on next (?) merge window thought...
but, for current code/branch

Tested-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>


Best regards
---
Kuninori Morimoto


From jon-hunter at ti.com  Sun Apr  7 21:30:00 2013
From: jon-hunter at ti.com (Jon Hunter)
Date: Sun, 7 Apr 2013 20:30:00 -0500
Subject: [PATCH 3/3] ARM: dts: Add OMAP3430 SDP NOR flash memory binding
In-Reply-To: <1365383828-25627-3-git-send-email-jon-hunter@ti.com>
References: <1365383828-25627-1-git-send-email-jon-hunter@ti.com>
 <1365383828-25627-3-git-send-email-jon-hunter@ti.com>
Message-ID: <51621D98.80403@ti.com>


On 04/07/2013 08:17 PM, Jon Hunter wrote:
> Add device-tree node for the 128MB NOR on the OMAP3423-SDP board.

Bugger ... it seems I have invented and new board. OMAP3423 SDP
does not exist. Fixed below.

Jon

>From 4f486b5dddc5d960d786504b4e3e97a28b63c1c0 Mon Sep 17 00:00:00 2001
From: Jon Hunter <jon-hunter at ti.com>
Date: Thu, 21 Feb 2013 18:52:05 -0600
Subject: [PATCH 3/3] ARM: dts: Add OMAP3430 SDP NOR flash memory binding

Add device-tree node for the 128MB NOR on the OMAP3430-SDP board.

Signed-off-by: Jon Hunter <jon-hunter at ti.com>
---
 arch/arm/boot/dts/omap3430-sdp.dts |   51 +++++++++++++++++++++++++++++++++++-
 1 file changed, 50 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/omap3430-sdp.dts b/arch/arm/boot/dts/omap3430-sdp.dts
index 44d2191..144ae43 100644
--- a/arch/arm/boot/dts/omap3430-sdp.dts
+++ b/arch/arm/boot/dts/omap3430-sdp.dts
@@ -45,9 +45,58 @@
 };
 
 &gpmc {
-	ranges = <1 0 0x28000000 0x08000000>,
+	ranges = <0 0 0x10000000 0x08000000>,
+		 <1 0 0x28000000 0x08000000>,
 		 <2 0 0x20000000 0x10000000>;
 
+	nor at 0,0 {
+		compatible = "cfi-flash";
+		linux,mtd-name= "intel,pf48f6000m0y1be";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		reg = <0 0 0x08000000>;
+		bank-width = <2>;
+
+		gpmc,mux-add-data = <2>;
+		gpmc,cs-on-ns = <0>;
+		gpmc,cs-rd-off-ns = <186>;
+		gpmc,cs-wr-off-ns = <186>;
+		gpmc,adv-on-ns = <12>;
+		gpmc,adv-rd-off-ns = <48>;
+		gpmc,adv-wr-off-ns = <48>;
+		gpmc,oe-on-ns = <54>;
+		gpmc,oe-off-ns = <168>;
+		gpmc,we-on-ns = <54>;
+		gpmc,we-off-ns = <168>;
+		gpmc,rd-cycle-ns = <186>;
+		gpmc,wr-cycle-ns = <186>;
+		gpmc,access-ns = <114>;
+		gpmc,page-burst-access-ns = <6>;
+		gpmc,bus-turnaround-ns = <12>;
+		gpmc,cycle2cycle-delay-ns = <18>;
+		gpmc,wr-data-mux-bus-ns = <90>;
+		gpmc,wr-access-ns = <186>;
+		gpmc,cycle2cycle-samecsen;
+		gpmc,cycle2cycle-diffcsen;
+
+		partition at 0 {
+			label = "bootloader-nor";
+			reg = <0 0x40000>;
+		};
+		partition at 0x40000 {
+			label = "params-nor";
+			reg = <0x40000 0x40000>;
+		};
+		partition at 0x80000 {
+			label = "kernel-nor";
+			reg = <0x80000 0x200000>;
+		};
+		partition at 0x280000 {
+			label = "filesystem-nor";
+			reg = <0x240000 0x7d80000>;
+		};
+	};
+
 	nand at 1,0 {
 		linux,mtd-name= "micron,mt29f1g08abb";
 		#address-cells = <1>;
-- 
1.7.10.4


From horms at verge.net.au  Sun Apr  7 21:33:55 2013
From: horms at verge.net.au (Simon Horman)
Date: Mon, 8 Apr 2013 10:33:55 +0900
Subject: [PATCH 00/02] ARM: shmobile: r8a7790 Lager arch timer fixes
In-Reply-To: <20130408012318.13555.58237.sendpatchset@w520>
References: <20130408012318.13555.58237.sendpatchset@w520>
Message-ID: <20130408013354.GA13103@verge.net.au>

On Mon, Apr 08, 2013 at 10:23:18AM +0900, Magnus Damm wrote:
> ARM: shmobile: r8a7790 Lager arch timer fixes
> 
> [PATCH 01/02] ARM: shmobile: force enable of r8a7790 arch timer 
> [PATCH 02/02] ARM: shmobile: use r8a7790 timer setup code on Lager
> 
> This mini-series contains fixes to start the arch timer on
> r8a7790 and the Lager board regardless of boot loader setting.
> 
> Signed-off-by: Magnus Damm <damm at opensource.se>
> ---
> 
>  Written against renesas-next-20130405v2 in renesas.git

Hi Magnus,

I have tested that these patches allow the lager board to boot.
Should I queue them up?


From magnus.damm at gmail.com  Sun Apr  7 21:44:44 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Mon, 08 Apr 2013 10:44:44 +0900
Subject: [PATCH] ARM: shmobile: Include all 2 GiB of memory on APE6EVM
Message-ID: <20130408014444.18767.64441.sendpatchset@w520>

From: Takashi Yoshii <takashi.yoshii.zj at renesas.com>

Add 1GiB of DRAM at 0x2_0000_0000

Signed-off-by: Takashi Yoshii <takashi.yoshii.zj at renesas.com>
Signed-off-by: Magnus Damm <damm at opensource.se>
---

 This patch simply updates the DTS to describe the actual board
 hardware. If we want to make use of the memory we also need to
 enable LPAE in the kernel configuration, but that is seen as a
 separate step.

 arch/arm/boot/dts/r8a73a4-ape6evm.dts |    5 +++++
 1 file changed, 5 insertions(+)

--- 0001/arch/arm/boot/dts/r8a73a4-ape6evm.dts
+++ work/arch/arm/boot/dts/r8a73a4-ape6evm.dts	2013-04-08 10:27:20.000000000 +0900
@@ -24,6 +24,11 @@
 		reg = <0 0x40000000 0 0x40000000>;
 	};
 
+	memory at 200000000 {
+		device_type = "memory";
+		reg = <2 0x00000000 0 0x40000000>;
+	};
+
 	ape6evm_fixed_3v3: fixedregulator at 0 {
 		compatible = "regulator-fixed";
 		regulator-name = "3V3";


From horms at verge.net.au  Sun Apr  7 22:06:38 2013
From: horms at verge.net.au (Simon Horman)
Date: Mon, 8 Apr 2013 11:06:38 +0900
Subject: [PATCH 00/02] ARM: shmobile: r8a7790 Lager arch timer fixes
In-Reply-To: <87r4ilolmh.wl%kuninori.morimoto.gx@renesas.com>
References: <20130408012318.13555.58237.sendpatchset@w520>
 <87r4ilolmh.wl%kuninori.morimoto.gx@renesas.com>
Message-ID: <20130408020637.GF13103@verge.net.au>

On Sun, Apr 07, 2013 at 06:29:46PM -0700, Kuninori Morimoto wrote:
> 
> Hi
> 
> > ARM: shmobile: r8a7790 Lager arch timer fixes
> > 
> > [PATCH 01/02] ARM: shmobile: force enable of r8a7790 arch timer 
> > [PATCH 02/02] ARM: shmobile: use r8a7790 timer setup code on Lager
> > 
> > This mini-series contains fixes to start the arch timer on
> > r8a7790 and the Lager board regardless of boot loader setting.
> > 
> > Signed-off-by: Magnus Damm <damm at opensource.se>
> > ---
> 
> I guess shmobile_timer_init() will be conflict (or compile error)
> on next (?) merge window thought...
> but, for current code/branch

I guess that the solution is to ensure that patch 1 is applied
before patch 2. Am I missing something?

> Tested-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>


From horms at verge.net.au  Sun Apr  7 22:16:32 2013
From: horms at verge.net.au (Simon Horman)
Date: Mon, 8 Apr 2013 11:16:32 +0900
Subject: [RFC/PATCH 0/7] ARCH: shmobile: defconfig consolidation
In-Reply-To: <87sj31omnz.wl%kuninori.morimoto.gx@renesas.com>
References: <1365046193-19369-1-git-send-email-horms+renesas@verge.net.au>
 <87sj31omnz.wl%kuninori.morimoto.gx@renesas.com>
Message-ID: <20130408021630.GI13103@verge.net.au>

On Sun, Apr 07, 2013 at 06:07:16PM -0700, Kuninori Morimoto wrote:
> 
> Hi Simon
> 
> > Simon Horman (7):
> >  ARM: shmobile: prune defconfig
> >  ARM: shmobile: make defconfig canonical
> >  ARM: shmobile: Add kzm9d to consolidated defconfig
> >  ARM: shmobile: Add mackerel to consolidated defconfig
> >  ARM: shmobile: defconfig: Remove armadillo800eva defconfig
> >  ARM: shmobile: defconfig: Remove kzm9d defconfig
> >  ARM: shmobile: defconfig: Remove mackerel defconfig
> (snip)
> > Morimoto-san, I suspect it may be possible to add support for the
> > bockw board to the consolidated defconfig if its boot loader supports
> > booting using a zImage. In this case even though the base memory address
> > is not the same as the boards above it should be possible to specify
> > the base address from the boot loader. As I do not have a bockw board
> > I am wondering if you could investigate this.
> 
> I tested shmobile_defconfig on Bock-W board.
> It works with...
> 
>  1) I added R8A7778 SoC on .config
>  2) I added Bock-W on .config
>  3) I fixuped CONFIG_MEMORY_START, CONFIG_MEMORY_SIZE value on .config
> 
> It is correct method ?

Unfortunately not, the idea is not to modify CONFIG_MEMORY_START
or CONFIG_MEMORY_SIZE.

My understanding is that if you load a zImage at the correct
start address (0x60000000 IIRC) and then execute it using bootz
then the kernel should relocate and run from that address.


From shawn.guo at linaro.org  Sun Apr  7 22:20:03 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Mon, 8 Apr 2013 10:20:03 +0800
Subject: [PATCH v2 0/3] Get rid of big array from imx pinctrl driver
In-Reply-To: <CAOMZO5AVra7Hrf5rJvr5UWP=B2m18Dyw2tb4jC8JwxFVNr5i3Q@mail.gmail.com>
References: <1361533888-18073-1-git-send-email-shawn.guo@linaro.org>
 <CAOMZO5D1+baoM0vMdPW9bAd4DX8C82BF9H87igFNo78+8D_N3Q@mail.gmail.com>
 <20130407071028.GD11898@S2101-09.ap.freescale.net>
 <CAOMZO5BCQiRMp8KG-beDkDyX8VSq7Arzs+vJ+xU+SYXRPjgDzA@mail.gmail.com>
 <CAOMZO5AVra7Hrf5rJvr5UWP=B2m18Dyw2tb4jC8JwxFVNr5i3Q@mail.gmail.com>
Message-ID: <20130408022001.GF11898@S2101-09.ap.freescale.net>

On Sun, Apr 07, 2013 at 06:52:11PM -0300, Fabio Estevam wrote:
> On Sun, Apr 7, 2013 at 4:56 PM, Fabio Estevam <festevam at gmail.com> wrote:
> > On Sun, Apr 7, 2013 at 4:10 AM, Shawn Guo <shawn.guo at linaro.org> wrote:
> >
> >> I just rebuilt imx/dt branch with the problem fixed and also had the
> >> branch based on Stephen Warren's for-3.10/dtc-cpp-chroot-std-headers
> >> branch so avoid all those dts files renaming.
> >
> > Does imx6dl boot for you in your updated imx/dt branch?
> >
> > It used to boot previously, but after the update it no longer boots.
> 
> Your updated branch missed:
> 
> [PATCH 3/6] ARM: imx: add initial imx6dl support

It's never been on imx/dt branch but imx/soc.  So for-next can be used
to boot imx6dl.

Shawn



From horms at verge.net.au  Sun Apr  7 22:33:44 2013
From: horms at verge.net.au (Simon Horman)
Date: Mon, 8 Apr 2013 11:33:44 +0900
Subject: [PATCH 0/8] Reorganize R8A7779/Marzen USB code
In-Reply-To: <515F51B6.5000302@cogentembedded.com>
References: <201304050251.44464.sergei.shtylyov@cogentembedded.com>
 <87vc81ka6k.wl%kuninori.morimoto.gx@renesas.com>
 <515EFE6D.4020006@cogentembedded.com>
 <515F51B6.5000302@cogentembedded.com>
Message-ID: <20130408023344.GK13103@verge.net.au>

On Sat, Apr 06, 2013 at 02:35:34AM +0400, Sergei Shtylyov wrote:
> Hello.
> 
> On 04/05/2013 08:40 PM, Sergei Shtylyov wrote:
> 
> >
> >>>    Here's the set of 4 patches against the Simon Horman's
> >>>'renesas.git' repo,
> >>>'renesas-next-20130404v2' tag and the 2 Ether patches I've
> >>>reposted yesterday.
> >>>It was created to fix the shortcomings in the R8A7779/Marzen
> >>>USB platform code
> >>>and R8A7779 USB common PHY driver, and so spans both
> >>>arch/arm/mach-shmobile/
> >>>and drivers/usb/ subtrees (some patches have to touch both subtrees).
> >>>The patches were conceived with the complete bisectability
> >>>goal in mind.
> >
> >>>[1/8] ARM: shmobile:Marzen: move USB EHCI, OHCI, and PHY
> >>>devices to R8A7779 code
> >>>[2/8] ehci-platform: add init() method to platform data
> >>>[3/8] ARM: shmobile: R8A7779: setup EHCI internal buffer
> >>>[4/8] rcar-phy: remove EHCI internal buffer setup
> >>>[5/8] rcar-phy: correct base address
> >>>[6/8] rcar-phy: add platform data
> >>>[7/8] ARM: shmobile: Marzen: pass platform data to USB PHY device
> >>>[8/8] rcar-phy: handle platform data
> >
> >>>    I'm not sure thru which tree this patchset should be
> >>>merged, however it turns
> >>>out that it's too late now to push it thru Felipe Balbi's USB
> >>>tree for 3.10, so
> >>>maybe the patchset can be merged thru Simon's tree with
> >>>Felipe's and Alan
> >>>Stern's ACKs.
> >
> >>I guess you already got request about patch style from Simon.
> >
> >   It's not about style. I tried to keep the series copmpletely
> >bisectable, and granting almost all requests about splitting the
> >patches would have broken the bisection.
> >
> >>When you send v2 patch, could you please add "this patch is
> >>tested on xxxx bard"
> >>on each patch's comment area ?
> >
> >   I'm not sure it's worth doing v2, although in one place I can
> >indeed readily split the patch. All patches were tested on the
> >Marzen board, I forgot to mention that in the cover letter.
> 
>    Well, there's gonna be version 2 now, mainly because Alan Stern
> wasn't content with the patch #2.

When you spin v2 could you note in the change log of each patch that
includes both SoC and board of SoC and river code that the reason for this
is to avoid breaking bisection?

Thanks.


From kuninori.morimoto.gx at renesas.com  Sun Apr  7 22:35:53 2013
From: kuninori.morimoto.gx at renesas.com (Kuninori Morimoto)
Date: Sun, 07 Apr 2013 19:35:53 -0700 (PDT)
Subject: [PATCH 00/02] ARM: shmobile: r8a7790 Lager arch timer fixes
In-Reply-To: <20130408020637.GF13103@verge.net.au>
References: <20130408012318.13555.58237.sendpatchset@w520>
 <87r4ilolmh.wl%kuninori.morimoto.gx@renesas.com>
 <20130408020637.GF13103@verge.net.au>
Message-ID: <87ppy5oika.wl%kuninori.morimoto.gx@renesas.com>


Hi Simon

> > I guess shmobile_timer_init() will be conflict (or compile error)
> > on next (?) merge window thought...
> > but, for current code/branch
> 
> I guess that the solution is to ensure that patch 1 is applied
> before patch 2. Am I missing something?

Sorry for my confusion
I meant shmobile_timer_init() will be removed from ARM SoC side.
But I'm not sure for detail

Best regards
---
Kuninori Morimoto


From timur at tabi.org  Sun Apr  7 22:49:03 2013
From: timur at tabi.org (Timur Tabi)
Date: Sun, 07 Apr 2013 21:49:03 -0500
Subject: [PATCH v2 08/11] ASoC: fsl-ssi: imx ac97 support
In-Reply-To: <1365362721-3731-9-git-send-email-mpa@pengutronix.de>
References: <1365362721-3731-1-git-send-email-mpa@pengutronix.de>
 <1365362721-3731-9-git-send-email-mpa@pengutronix.de>
Message-ID: <5162301F.9090000@tabi.org>

Markus Pargmann wrote:
> This patch copies some parts from imx-ssi to support AC97 on
> imx27-pca100 and imx27-pcm043. It is activated with a new fsl,imx-ac97
> bool property. It was tested on imx27-pca100.

I'm not crazy about this patch -- it seems a bit hackish.  There are too 
many "if (imx_ac97)" clauses.  Large pieces of code that don't appear to 
be related to AC97 are indented in an if-clause.  I especially don't like 
the "If we use AC97, the registers are already setup correctly".

-- 
Timur Tabi


From timur at tabi.org  Sun Apr  7 22:50:19 2013
From: timur at tabi.org (Timur Tabi)
Date: Sun, 07 Apr 2013 21:50:19 -0500
Subject: [PATCH v2 06/11] ASoC: fsl-ssi: Setup generic imx dma params
In-Reply-To: <1365362721-3731-7-git-send-email-mpa@pengutronix.de>
References: <1365362721-3731-1-git-send-email-mpa@pengutronix.de>
 <1365362721-3731-7-git-send-email-mpa@pengutronix.de>
Message-ID: <5162306B.6090207@tabi.org>

Markus Pargmann wrote:
> -		ret = of_property_read_u32_array(pdev->dev.of_node,
> -					"fsl,ssi-dma-events", dma_events, 2);

Does this mean that the "fsl,ssi-dma-events" property is no longer used?

-- 
Timur Tabi


From timur at tabi.org  Sun Apr  7 22:52:17 2013
From: timur at tabi.org (Timur Tabi)
Date: Sun, 07 Apr 2013 21:52:17 -0500
Subject: [PATCH v2 01/11] ASoC: phycore-ac97: Add DT support
In-Reply-To: <1365362721-3731-2-git-send-email-mpa@pengutronix.de>
References: <1365362721-3731-1-git-send-email-mpa@pengutronix.de>
 <1365362721-3731-2-git-send-email-mpa@pengutronix.de>
Message-ID: <516230E1.3070509@tabi.org>

Markus Pargmann wrote:
> Notes:
>     Changes in v2:
>      - Simplify the driver, by combining audmux port configurations. The
>        audmux driver actually knows on which platform he is running and
>        will return the appropriate error code if we use functions for
>        another platform. So we don't need to have the knowledge about it
>        in phycore-ac97 and can try both functions. This removes the need
>        of different compatibilities and renames it to imx27-ac97.
>      - Use a phandle for the cpu_dai link.
>      - Add devicetree binding documentation.
>      - Rename binding to phytec,phycore-ac97 and fsl,ssi to phytec,ssi

I think some of this information belongs in the changelog.

> +#ifdef CONFIG_MACH_IMX27_DT
> +		.platform_name	= "imx-fiq-pcm-audio",
> +#else
>   		.cpu_dai_name	= "imx-ssi.0",
>   		.platform_name	= "imx-fiq-pcm-audio.0",
> +#endif

What's the difference between "imx-fiq-pcm-audio" and "imx-fiq-pcm-audio.0"?

-- 
Timur Tabi


From kuninori.morimoto.gx at renesas.com  Sun Apr  7 22:52:18 2013
From: kuninori.morimoto.gx at renesas.com (Kuninori Morimoto)
Date: Sun, 07 Apr 2013 19:52:18 -0700 (PDT)
Subject: [RFC/PATCH 0/7] ARCH: shmobile: defconfig consolidation
In-Reply-To: <20130408021630.GI13103@verge.net.au>
References: <1365046193-19369-1-git-send-email-horms+renesas@verge.net.au>
 <87sj31omnz.wl%kuninori.morimoto.gx@renesas.com>
 <20130408021630.GI13103@verge.net.au>
Message-ID: <87mwt9ohsx.wl%kuninori.morimoto.gx@renesas.com>


Hi Simon

> > > Morimoto-san, I suspect it may be possible to add support for the
> > > bockw board to the consolidated defconfig if its boot loader supports
> > > booting using a zImage. In this case even though the base memory address
> > > is not the same as the boards above it should be possible to specify
> > > the base address from the boot loader. As I do not have a bockw board
> > > I am wondering if you could investigate this.
> > 
> > I tested shmobile_defconfig on Bock-W board.
> > It works with...
> > 
> >  1) I added R8A7778 SoC on .config
> >  2) I added Bock-W on .config
> >  3) I fixuped CONFIG_MEMORY_START, CONFIG_MEMORY_SIZE value on .config
> > 
> > It is correct method ?
> 
> Unfortunately not, the idea is not to modify CONFIG_MEMORY_START
> or CONFIG_MEMORY_SIZE.
> 
> My understanding is that if you load a zImage at the correct
> start address (0x60000000 IIRC) and then execute it using bootz
> then the kernel should relocate and run from that address.

Hmm...
This means 3) is not needed, but it didn't work without 3)
Is it R8A7778 or Bock-W DT code issue ?


Best regards
---
Kuninori Morimoto


From kuninori.morimoto.gx at renesas.com  Sun Apr  7 23:16:41 2013
From: kuninori.morimoto.gx at renesas.com (Kuninori Morimoto)
Date: Sun, 07 Apr 2013 20:16:41 -0700 (PDT)
Subject: [RFC/PATCH 0/7] ARCH: shmobile: defconfig consolidation
In-Reply-To: <87mwt9ohsx.wl%kuninori.morimoto.gx@renesas.com>
References: <1365046193-19369-1-git-send-email-horms+renesas@verge.net.au>
 <87sj31omnz.wl%kuninori.morimoto.gx@renesas.com>
 <20130408021630.GI13103@verge.net.au>
 <87mwt9ohsx.wl%kuninori.morimoto.gx@renesas.com>
Message-ID: <87li8togoa.wl%kuninori.morimoto.gx@renesas.com>


Hi Simon

> > Unfortunately not, the idea is not to modify CONFIG_MEMORY_START
> > or CONFIG_MEMORY_SIZE.
> > 
> > My understanding is that if you load a zImage at the correct
> > start address (0x60000000 IIRC) and then execute it using bootz
> > then the kernel should relocate and run from that address.
> 
> Hmm...
> This means 3) is not needed, but it didn't work without 3)
> Is it R8A7778 or Bock-W DT code issue ?

Now, Bock-W start works with attached patch
Is it correct for you ?

I used simon/topic/defconfig-consolidation+next-20130403
(I guess there is no tag for it ?)

-- for bock-w ---------------------------
diff --git a/arch/arm/boot/dts/r8a7778-bockw.dts b/arch/arm/boot/dts/r8a7778-bockw.dts
index 0076b1e..1242940 100644
--- a/arch/arm/boot/dts/r8a7778-bockw.dts
+++ b/arch/arm/boot/dts/r8a7778-bockw.dts
@@ -27,6 +27,6 @@
 
 	memory {
 		device_type = "memory";
-		reg = <0x60000000 0x10000000>;
+		reg = <0x40000000 0x10000000>;
 	};
 };
diff --git a/arch/arm/configs/shmobile_defconfig b/arch/arm/configs/shmobile_defconfig
index 7dba53f..c4b9940 100644
--- a/arch/arm/configs/shmobile_defconfig
+++ b/arch/arm/configs/shmobile_defconfig
@@ -14,10 +14,12 @@ CONFIG_SLAB=y
 CONFIG_ARCH_SHMOBILE=y
 CONFIG_ARCH_SH7372=y
 CONFIG_ARCH_R8A7740=y
+CONFIG_ARCH_R8A7778=y
 CONFIG_ARCH_R8A7790=y
 CONFIG_ARCH_EMEV2=y
 CONFIG_MACH_MACKEREL=y
 CONFIG_MACH_ARMADILLO800EVA=y
+CONFIG_MACH_BOCKW=y
 CONFIG_MACH_LAGER=y
 CONFIG_MACH_KZM9D=y
 # CONFIG_SH_TIMER_TMU is not set


Best regards
---
Kuninori Morimoto


From horms at verge.net.au  Sun Apr  7 23:32:09 2013
From: horms at verge.net.au (Simon Horman)
Date: Mon, 8 Apr 2013 12:32:09 +0900
Subject: [PATCH 00/02] ARM: shmobile: r8a7790 Lager arch timer fixes
In-Reply-To: <87ppy5oika.wl%kuninori.morimoto.gx@renesas.com>
References: <20130408012318.13555.58237.sendpatchset@w520>
 <87r4ilolmh.wl%kuninori.morimoto.gx@renesas.com>
 <20130408020637.GF13103@verge.net.au>
 <87ppy5oika.wl%kuninori.morimoto.gx@renesas.com>
Message-ID: <20130408033207.GA10151@verge.net.au>

On Sun, Apr 07, 2013 at 07:35:53PM -0700, Kuninori Morimoto wrote:
> 
> Hi Simon
> 
> > > I guess shmobile_timer_init() will be conflict (or compile error)
> > > on next (?) merge window thought...
> > > but, for current code/branch
> > 
> > I guess that the solution is to ensure that patch 1 is applied
> > before patch 2. Am I missing something?
> 
> Sorry for my confusion
> I meant shmobile_timer_init() will be removed from ARM SoC side.
> But I'm not sure for detail

Ah yes.

That already causes multiple breakages in renesas-next.
I have responded to the thread on removing shmobile_timer_init()
accordingly.


From dt.tangr at gmail.com  Sun Apr  7 23:55:15 2013
From: dt.tangr at gmail.com (Daniel Tang)
Date: Mon, 8 Apr 2013 13:55:15 +1000
Subject: [PATCH] Remove trailing whitespace in arch/arm/Makefile
Message-ID: <979FD146-5650-409C-B18E-F1CDBBE67236@gmail.com>

Signed-off-by: Daniel Tang <dt.tangr at gmail.com>
---
 arch/arm/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index ee4605f..479b209 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -313,7 +313,7 @@ define archhelp
   echo  '  Image         - Uncompressed kernel image (arch/$(ARCH)/boot/Image)'
   echo  '* xipImage      - XIP kernel image, if configured (arch/$(ARCH)/boot/xipImage)'
   echo  '  uImage        - U-Boot wrapped zImage'
-  echo  '  bootpImage    - Combined zImage and initial RAM disk' 
+  echo  '  bootpImage    - Combined zImage and initial RAM disk'
   echo  '                  (supply initrd image via make variable INITRD=<path>)'
   echo  '* dtbs          - Build device tree blobs for enabled boards'
   echo  '  install       - Install uncompressed kernel'
-- 
1.8.1.3




From mturquette at linaro.org  Sun Apr  7 23:59:58 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Sun, 07 Apr 2013 20:59:58 -0700
Subject: [PATCH] clk: add helper to set flags for clk-provider
In-Reply-To: <1365139332-17775-1-git-send-email-sebastian.hesselbarth@gmail.com>
References: <1365139332-17775-1-git-send-email-sebastian.hesselbarth@gmail.com>
Message-ID: <20130408035958.14359.85310@quantum>

Quoting Sebastian Hesselbarth (2013-04-04 22:22:12)
> Clock providers are not allowed to mess with struct clk internals directly
> but using helpers provided by clk-provider.h. This patch adds a helper to
> allow to set flags of a clock after registration. This is useful, if clock
> flags change during runtime, e.g. ability to set parent clock after mux
> switch.

Hi Sebastian,

I do not like this change.  There are a few reasons why.  Firstly the
clk flags have never been advertised as changing at runtime.  On that
note, can you expand your example of "ability to set parent clock after
mux switch"?  I do not follow what you mean.

Secondly, it is possible to need flags during __clk_init.  This exists
today for root clocks that use the CLK_IS_ROOT flag.  So setting that
flag after registration is too late.

Finally, how can we make sure that this api is not abused?  I'm
concerned about drivers which use __clk_set_flags in a hacky way, when
in fact the flags are supposed to be permanent properties of that clock.

Do you truly need the ability to change clock flags at runtime, or do
you instead need a way to express flags in DT?  I'm sure the clock
bindings are not the first binding to run up against flags or properties
that do not strictly match the hardware description.  Maybe solving that
problem is the right way?

Regards,
Mike

> 
> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
> ---
> Cc: Mike Turquette <mturquette at linaro.org>
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-kernel at vger.kernel.org
> ---
>  drivers/clk/clk.c            |    8 ++++++++
>  include/linux/clk-provider.h |    1 +
>  2 files changed, 9 insertions(+)
> 
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index ed87b24..780a0c0 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -451,6 +451,14 @@ unsigned long __clk_get_flags(struct clk *clk)
>         return !clk ? 0 : clk->flags;
>  }
>  
> +void __clk_set_flags(struct clk *clk, unsigned long flags)
> +{
> +       if (!clk)
> +               return;
> +
> +       clk->flags = flags;
> +}
> +
>  bool __clk_is_enabled(struct clk *clk)
>  {
>         int ret;
> diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
> index 7f197d7..e862d9c 100644
> --- a/include/linux/clk-provider.h
> +++ b/include/linux/clk-provider.h
> @@ -351,6 +351,7 @@ unsigned int __clk_get_enable_count(struct clk *clk);
>  unsigned int __clk_get_prepare_count(struct clk *clk);
>  unsigned long __clk_get_rate(struct clk *clk);
>  unsigned long __clk_get_flags(struct clk *clk);
> +void __clk_set_flags(struct clk *clk, unsigned long flags);
>  bool __clk_is_enabled(struct clk *clk);
>  struct clk *__clk_lookup(const char *name);
>  
> -- 
> 1.7.10.4


From viresh.kumar at linaro.org  Mon Apr  8 00:54:38 2013
From: viresh.kumar at linaro.org (Viresh Kumar)
Date: Mon, 8 Apr 2013 10:24:38 +0530
Subject: [PATCH 07/18] cpufreq: s3c24xx: move cpufreq driver to
 drivers/cpufreq
In-Reply-To: <CAKohpokk1Q+0gRpeW=ts0a8D+rGAUpHu62X+7ejdpfom_B6FYA@mail.gmail.com>
References: <cover.1365079581.git.viresh.kumar@linaro.org>
 <927100d30bf40d4fec477cc7d8d464669a22d167.1365079581.git.viresh.kumar@linaro.org>
 <2a5901ce31c9$95160980$bf421c80$%kim@samsung.com>
 <CAKohpokk1Q+0gRpeW=ts0a8D+rGAUpHu62X+7ejdpfom_B6FYA@mail.gmail.com>
Message-ID: <CAKohpomgqWi9jfpqtW8cxu7BeJQCEySqbdDNVK=4Fh1ji1FyMg@mail.gmail.com>

On 5 April 2013 12:36, Viresh Kumar <viresh.kumar at linaro.org> wrote:
> On 5 April 2013 12:18, Kukjin Kim <kgene.kim at samsung.com> wrote:
>> Basically, this moving looks good to me, but should be re-worked based on
>> for-next of samsung tree because this touches too many samsung stuff so this
>> should be sent to upstream via samsung tree.
>
> Hmm... Its already applied in Rafael's tree. But it doesn't mean that
> it can't be
> moved to your tree if there is a issue.
>
> What tree/branch? I used:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git for-next
>
>> Applying: cpufreq: s3c24xx: move cpufreq driver to drivers/cpufreq
>> error: patch failed: arch/arm/Kconfig:2166
>> error: arch/arm/Kconfig: patch does not apply
>
> above two are obvious as you haven't applied other patches in this series.
>
>> error: patch failed: arch/arm/mach-s3c24xx/Kconfig:28
>> error: arch/arm/mach-s3c24xx/Kconfig: patch does not apply
>> error: patch failed: arch/arm/mach-s3c24xx/Makefile:17
>> error: arch/arm/mach-s3c24xx/Makefile: patch does not apply
>> error: patch failed: drivers/cpufreq/Makefile:63
>> error: drivers/cpufreq/Makefile: patch does not apply
>
> Same here.
>
>> error: drivers/cpufreq/s3c2412-cpufreq.c: does not exist in index
>
> I can still see it in for-next.
>
> Attached is my patch based of your for-next

Kukjin,

As Rafael has already dropped it, can you apply it at your end and make sure
it doesn't miss the merge cycle?


From prabhakar.csengg at gmail.com  Mon Apr  8 01:11:35 2013
From: prabhakar.csengg at gmail.com (Prabhakar Lad)
Date: Mon, 8 Apr 2013 10:41:35 +0530
Subject: [PATCH v8 1/2] ARM: davinci: dm365: add support for v4l2 video
 display
In-Reply-To: <515D48E5.1060700@ti.com>
References: <1364903681-13914-1-git-send-email-prabhakar.csengg@gmail.com>
 <1364903681-13914-2-git-send-email-prabhakar.csengg@gmail.com>
 <515D48E5.1060700@ti.com>
Message-ID: <CA+V-a8siF1HSRbpA=Oe-OMwtr_HuNP3scf3Qochb7He2Y+zwKQ@mail.gmail.com>

Sekhar,

On Thu, Apr 4, 2013 at 3:03 PM, Sekhar Nori <nsekhar at ti.com> wrote:
> On 4/2/2013 5:24 PM, Prabhakar lad wrote:
>> From: Lad, Prabhakar <prabhakar.csengg at gmail.com>
>>
>> Create platform devices for various video modules like venc,osd,
>> vpbe and v4l2 driver for dm365.
>>
>> Signed-off-by: Lad, Prabhakar <prabhakar.csengg at gmail.com>
>
> Minor nits below:
>
>> diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
>> index c61dd94..786c860 100644
>> --- a/arch/arm/mach-davinci/dm365.c
>> +++ b/arch/arm/mach-davinci/dm365.c
>> @@ -40,10 +40,14 @@
>>
>>  #define DM365_REF_FREQ               24000000        /* 24 MHz on the DM365 EVM */
>>
>> +#define DM365_RTC_BASE                       0x01c69000
>> +
>>  /* Base of key scan register bank */
>>  #define DM365_KEYSCAN_BASE           0x01c69400
>>
>> -#define DM365_RTC_BASE                       0x01c69000
>> +#define DM365_OSD_BASE                       0x01c71c00
>> +
>> +#define DM365_VENC_BASE                      0x01c71e00
>>
>>  #define DAVINCI_DM365_VC_BASE                0x01d0c000
>
> No need of empty lines between these definitions. While at it you can
> also remove the useless comment "/* Base of key scan register bank */"
>
OK

>> +static int dm365_vpbe_setup_pinmux(enum v4l2_mbus_pixelcode if_type,
>> +                         int field)
>> +{
>> +     switch (if_type) {
>> +     case V4L2_MBUS_FMT_SGRBG8_1X8:
>> +             davinci_cfg_reg(DM365_VOUT_FIELD_G81);
>> +             davinci_cfg_reg(DM365_VOUT_COUTL_EN);
>> +             davinci_cfg_reg(DM365_VOUT_COUTH_EN);
>> +             break;
>> +
>
> No need of these empty lines after 'break'. Here and other places below.
>
OK

> The patch looks good overall though so you can fix the nits and add:
>
> Acked-by: Sekhar Nori <nsekhar at ti.com>

Thanks.

Regards,
--Prabhakar

>
> Thanks,
> Sekhar


From avinashphilip at ti.com  Mon Apr  8 01:56:39 2013
From: avinashphilip at ti.com (Philip, Avinash)
Date: Mon, 8 Apr 2013 05:56:39 +0000
Subject: [PATCH 0/2] Update device tree binding document for
 pwm-tiehrpwm & pwm-tiecap
In-Reply-To: <1364195093-1357-1-git-send-email-avinashphilip@ti.com>
References: <1364195093-1357-1-git-send-email-avinashphilip@ti.com>
Message-ID: <518397C60809E147AF5323E0420B992E3EAA8DDE@DBDE01.ent.ti.com>

Thierry,

On Mon, Mar 25, 2013 at 12:34:51, Philip, Avinash wrote:
> Update device tree document of pwm-tiehrpwm & pwm-tiecap in order to reflect the
> usage of similar modules in both da850 and am33xx platforms.

Can you accept both documentation update patches with Peter Korsgaard's Ack.

Thanks
Avinash
> 
> Philip Avinash (2):
>   pwm: pwm-tiecap: Update device-tree binding document
>   pwm: pwm-tiehrpwm: Update device-tree binding document
> 
>  .../devicetree/bindings/pwm/pwm-tiecap.txt         |   12 ++++++++++--
>  .../devicetree/bindings/pwm/pwm-tiehrpwm.txt       |   12 ++++++++++--
>  2 files changed, 20 insertions(+), 4 deletions(-)
> 
> -- 
> 1.7.9.5
> 
> 



From shawn.guo at linaro.org  Mon Apr  8 02:09:00 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Mon, 8 Apr 2013 14:09:00 +0800
Subject: [PATCH v2 0/3] Get rid of big array from imx pinctrl driver
In-Reply-To: <CAOMZO5A-nwmb=6G-D_2LBNsPYH4C8Z686BjS3vd3WhzvnDFfqw@mail.gmail.com>
References: <1361533888-18073-1-git-send-email-shawn.guo@linaro.org>
 <CAOMZO5D1+baoM0vMdPW9bAd4DX8C82BF9H87igFNo78+8D_N3Q@mail.gmail.com>
 <20130407071028.GD11898@S2101-09.ap.freescale.net>
 <CAOMZO5Bxfj9ZGrVOcNirsVHFLWaHWBdkFpKSiVQ9iS4paT0Y6g@mail.gmail.com>
 <20130407142610.GE11898@S2101-09.ap.freescale.net>
 <CAOMZO5A-nwmb=6G-D_2LBNsPYH4C8Z686BjS3vd3WhzvnDFfqw@mail.gmail.com>
Message-ID: <20130408060857.GA5047@S2101-09.ap.freescale.net>

On Sun, Apr 07, 2013 at 11:32:45AM -0300, Fabio Estevam wrote:
> On Sun, Apr 7, 2013 at 11:26 AM, Shawn Guo <shawn.guo at linaro.org> wrote:
> 
> > That's expected, as the pin ID gets re-numbered based on offset of
> > mux/conf register, so that we can determine the pin ID at runtime and
> > avoid encoding it in device tree.
> 
> but debug messages seems buggy now:
> 
Yes, you are right.  The change attached below should fix the problem.
I am fixing it up for all imx pinctrl drivers on imx/dt branch.

> Prior to the patch we had:
> 
> imx6q-pinctrl 20e0000.iomuxc: pinconf set pin MX6Q_PAD_EIM_D21
> 
> and now we have:
> 
> imx6q-pinctrl 20e0000.iomuxc: pinconf set pin MX6Q_PAD_EIM_A17
> 
> MX6Q_PAD_EIM_A17 has nothing to do with I2C, so we should print
> MX6Q_PAD_EIM_A17 when we are actually configuring MX6Q_PAD_EIM_D21.
> 
> Also, where does the 19 offset in the  imx6q_pads enum come from?

We choose to have the pin ID simply calculated from register offset.
For example, the mux register offset for MX6Q_PAD_SD2_DAT1 is 0x4c, and
the ID would be 0x4c / 4 = 19.

Shawn

--8<-----

diff --git a/drivers/pinctrl/pinctrl-imx6q.c b/drivers/pinctrl/pinctrl-imx6q.c
index f00f532..76dd9c4 100644
--- a/drivers/pinctrl/pinctrl-imx6q.c
+++ b/drivers/pinctrl/pinctrl-imx6q.c
@@ -23,6 +23,25 @@
 #include "pinctrl-imx.h"
 
 enum imx6q_pads {
+	MX6Q_PAD_RESERVE0 = 0,
+	MX6Q_PAD_RESERVE1 = 1,
+	MX6Q_PAD_RESERVE2 = 2,
+	MX6Q_PAD_RESERVE3 = 3,
+	MX6Q_PAD_RESERVE4 = 4,
+	MX6Q_PAD_RESERVE5 = 5,
+	MX6Q_PAD_RESERVE6 = 6,
+	MX6Q_PAD_RESERVE7 = 7,
+	MX6Q_PAD_RESERVE8 = 8,
+	MX6Q_PAD_RESERVE9 = 9,
+	MX6Q_PAD_RESERVE10 = 10,
+	MX6Q_PAD_RESERVE11 = 11,
+	MX6Q_PAD_RESERVE12 = 12,
+	MX6Q_PAD_RESERVE13 = 13,
+	MX6Q_PAD_RESERVE14 = 14,
+	MX6Q_PAD_RESERVE15 = 15,
+	MX6Q_PAD_RESERVE16 = 16,
+	MX6Q_PAD_RESERVE17 = 17,
+	MX6Q_PAD_RESERVE18 = 18,
 	MX6Q_PAD_SD2_DAT1 = 19,
 	MX6Q_PAD_SD2_DAT2 = 20,
 	MX6Q_PAD_SD2_DAT0 = 21,
@@ -224,6 +243,25 @@ enum imx6q_pads {
 
 /* Pad names for the pinmux subsystem */
 static const struct pinctrl_pin_desc imx6q_pinctrl_pads[] = {
+	IMX_PINCTRL_PIN(MX6Q_PAD_RESERVE0),
+	IMX_PINCTRL_PIN(MX6Q_PAD_RESERVE1),
+	IMX_PINCTRL_PIN(MX6Q_PAD_RESERVE2),
+	IMX_PINCTRL_PIN(MX6Q_PAD_RESERVE3),
+	IMX_PINCTRL_PIN(MX6Q_PAD_RESERVE4),
+	IMX_PINCTRL_PIN(MX6Q_PAD_RESERVE5),
+	IMX_PINCTRL_PIN(MX6Q_PAD_RESERVE6),
+	IMX_PINCTRL_PIN(MX6Q_PAD_RESERVE7),
+	IMX_PINCTRL_PIN(MX6Q_PAD_RESERVE8),
+	IMX_PINCTRL_PIN(MX6Q_PAD_RESERVE9),
+	IMX_PINCTRL_PIN(MX6Q_PAD_RESERVE10),
+	IMX_PINCTRL_PIN(MX6Q_PAD_RESERVE11),
+	IMX_PINCTRL_PIN(MX6Q_PAD_RESERVE12),
+	IMX_PINCTRL_PIN(MX6Q_PAD_RESERVE13),
+	IMX_PINCTRL_PIN(MX6Q_PAD_RESERVE14),
+	IMX_PINCTRL_PIN(MX6Q_PAD_RESERVE15),
+	IMX_PINCTRL_PIN(MX6Q_PAD_RESERVE16),
+	IMX_PINCTRL_PIN(MX6Q_PAD_RESERVE17),
+	IMX_PINCTRL_PIN(MX6Q_PAD_RESERVE18),
 	IMX_PINCTRL_PIN(MX6Q_PAD_SD2_DAT1),
 	IMX_PINCTRL_PIN(MX6Q_PAD_SD2_DAT2),
 	IMX_PINCTRL_PIN(MX6Q_PAD_SD2_DAT0),



From sebastian.hesselbarth at gmail.com  Mon Apr  8 02:11:38 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Mon, 08 Apr 2013 08:11:38 +0200
Subject: [v5] clk: add si5351 i2c common clock driver
In-Reply-To: <20130408001725.GA16648@roeck-us.net>
References: <1365139415-17815-1-git-send-email-sebastian.hesselbarth@gmail.com>
 <20130407225046.GA16326@roeck-us.net> <51620604.4070204@gmail.com>
 <20130408001725.GA16648@roeck-us.net>
Message-ID: <51625F9A.1050308@gmail.com>

On 04/08/2013 02:17 AM, Guenter Roeck wrote:
> On Mon, Apr 08, 2013 at 01:49:24AM +0200, Sebastian Hesselbarth wrote:
>> On 04/08/2013 12:50 AM, Guenter Roeck wrote:
>>> On Fri, Apr 05, 2013 at 05:23:35AM -0000, Sebastian Hesselbarth wrote:
>>>> This patch adds a common clock driver for Silicon Labs Si5351a/b/c
>>>> i2c programmable clock generators. Currently, the driver supports
>>>> DT kernels only and VXCO feature of si5351b is not implemented. DT
>>>> bindings selectively allow to overwrite stored Si5351 configuration
>>>> which is very helpful for clock generators with empty eeprom
>>>> configuration. Corresponding device tree binding documentation is
>>>> also added.
>>>>
>>>> Signed-off-by: Sebastian Hesselbarth<sebastian.hesselbarth at gmail.com>
>>>> Tested-by: Daniel Mack<zonque at gmail.com>
>>>>
>>> [ ... ]
>>>
>>>> +static inline void _si5351_msynth_set_pll_master(
>>>> +	struct si5351_driver_data *drvdata, unsigned char num, int is_master)
>>>> +{
>>>> +	unsigned long flags;
>>>> +
>>>> +	if (num>   8 ||
>>>> +	    (drvdata->variant == SI5351_VARIANT_A3&&   num>   3))
>>>> +		return;
>>>> +
>>>> +	flags = __clk_get_flags(drvdata->msynth[num].hw.clk);
>>>> +	if (is_master)
>>>> +		flags |= CLK_SET_RATE_PARENT;
>>>> +	else
>>>> +		flags&= ~CLK_SET_RATE_PARENT;
>>>> +	__clk_set_flags(drvdata->msynth[num].hw.clk, flags);
>>>> +}
>>>> +
>>> Unless I am missing something, neither __clk_get_flags() nor the new
>>> __clk_set_flags is exported.
>>>
>>> Did you try to build and load the driver as module ?
>>
>> Well, good catch. I didn't try to build v5 as a module, but I guess it
>> will fail. But I consider this as something that has to be addressed in
>> clk framework itself, not in this patch. There will be other
>> clk-providers built as module in the future for sure.
>>
> Sure, but you provided the patch to make __clk_set_flags global. To avoid
> build failures, I would suggest to either submit a patch to export the
> missing functions, or to remove the ability to build the driver as module.

Actually, I knew that __clk_set_flags patch will not be accepted before 
posting it ;)

> On a side note, do you happen to know anyone working on drivers for Si5319 or
> Si5368 ?

No.

> Thanks,
> Guenter



From sebastian.hesselbarth at gmail.com  Mon Apr  8 02:27:33 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Mon, 08 Apr 2013 08:27:33 +0200
Subject: [PATCH] clk: add helper to set flags for clk-provider
In-Reply-To: <20130408035958.14359.85310@quantum>
References: <1365139332-17775-1-git-send-email-sebastian.hesselbarth@gmail.com>
 <20130408035958.14359.85310@quantum>
Message-ID: <51626355.8060000@gmail.com>

On 04/08/2013 05:59 AM, Mike Turquette wrote:
> Quoting Sebastian Hesselbarth (2013-04-04 22:22:12)
>> Clock providers are not allowed to mess with struct clk internals directly
>> but using helpers provided by clk-provider.h. This patch adds a helper to
>> allow to set flags of a clock after registration. This is useful, if clock
>> flags change during runtime, e.g. ability to set parent clock after mux
>> switch.
>
> Hi Sebastian,
>
> I do not like this change.  There are a few reasons why.  Firstly the
> clk flags have never been advertised as changing at runtime.  On that
> note, can you expand your example of "ability to set parent clock after
> mux switch"?  I do not follow what you mean.

Mike,

I knew you wouldn't like it. I just wanted to raise this discussion.

Consider a clock mux like in si5351 where each output clock can be muxed
to either it's own pll clock divider, the pll clock divider of clk0,
xtal, or clkin. And consider you want to allow to configure the mux at
runtime (si5351 driver doesn't, but just think about it).

Now, for it's own pll clock divider you want CLK_SET_PARENT_RATE while
for clk0's pll clock divider you want ~CLK_SET_PARENT_RATE because it
will break clk0's output rate. How can you have two sets of flags in the
current API?

> Secondly, it is possible to need flags during __clk_init.  This exists
> today for root clocks that use the CLK_IS_ROOT flag.  So setting that
> flag after registration is too late.

Sure, but some others work just fine if you change them during runtime.

> Finally, how can we make sure that this api is not abused?  I'm
> concerned about drivers which use __clk_set_flags in a hacky way, when
> in fact the flags are supposed to be permanent properties of that clock.

How can you ever make sure, the API is not abused? For the si5351 patch
at least, you pointed out not to use clk-private.h and now rejected v5
again.

I am asking, if those clock flags are really permanent properties? Not
that any current driver uses this, but especially clk muxes are meant
to switch to another clock that may have/require different flags.

> Do you truly need the ability to change clock flags at runtime, or do
> you instead need a way to express flags in DT?  I'm sure the clock
> bindings are not the first binding to run up against flags or properties
> that do not strictly match the hardware description.  Maybe solving that
> problem is the right way?

Of course, I can parse the flags prior registration and store them in
some struct. I was just re-working v4 of si5351 patch and wanted this
discussion first.

Sebastian


From shawn.guo at linaro.org  Mon Apr  8 02:33:42 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Mon, 8 Apr 2013 14:33:42 +0800
Subject: [PATCH 1/3] ARM: dts: Add NFC support for i.MX27 Phytec PCM038
 module
In-Reply-To: <1365348554-24345-1-git-send-email-shc_work@mail.ru>
References: <1365348554-24345-1-git-send-email-shc_work@mail.ru>
Message-ID: <20130408063340.GB5047@S2101-09.ap.freescale.net>

On Sun, Apr 07, 2013 at 07:29:12PM +0400, Alexander Shiyan wrote:
> Added NFC node to imx27-phytec-phycore DT file.
> 
> Signed-off-by: Alexander Shiyan <shc_work at mail.ru>

Applied, thanks.

> ---
>  arch/arm/boot/dts/imx27-phytec-phycore.dtsp | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/imx27-phytec-phycore.dtsp b/arch/arm/boot/dts/imx27-phytec-phycore.dtsp
> index 924097a..7228153 100644
> --- a/arch/arm/boot/dts/imx27-phytec-phycore.dtsp
> +++ b/arch/arm/boot/dts/imx27-phytec-phycore.dtsp
> @@ -71,3 +71,9 @@
>  		#size-cells = <1>;
>  	};
>  };
> +
> +&nfc {
> +	nand-bus-width = <8>;
> +	nand-ecc-mode = "hw";
> +	status = "okay";
> +};
> -- 
> 1.8.1.5
> 
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss



From shawn.guo at linaro.org  Mon Apr  8 02:35:59 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Mon, 8 Apr 2013 14:35:59 +0800
Subject: [PATCH 2/3] ARM: dts: Add SPI support for i.MX27 Phytec PCM038
 module
In-Reply-To: <1365348554-24345-2-git-send-email-shc_work@mail.ru>
References: <1365348554-24345-1-git-send-email-shc_work@mail.ru>
 <1365348554-24345-2-git-send-email-shc_work@mail.ru>
Message-ID: <20130408063557.GC5047@S2101-09.ap.freescale.net>

On Sun, Apr 07, 2013 at 07:29:13PM +0400, Alexander Shiyan wrote:
> Added SPI node to imx27-phytec-phycore DT file.
> 
> Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
> ---
>  arch/arm/boot/dts/imx27-phytec-phycore.dtsp | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/imx27-phytec-phycore.dtsp b/arch/arm/boot/dts/imx27-phytec-phycore.dtsp
> index 7228153..354dc77 100644
> --- a/arch/arm/boot/dts/imx27-phytec-phycore.dtsp
> +++ b/arch/arm/boot/dts/imx27-phytec-phycore.dtsp
> @@ -77,3 +77,9 @@
>  	nand-ecc-mode = "hw";
>  	status = "okay";
>  };
> +
> +&cspi1 {
> +	fsl,spi-num-chipselects = <1>;
> +	cs-gpios = <&gpio4 28 0>;
> +	status = "okay";
> +};

I would suggest these codes be sorted in alphabet order of label name.
IOW, &cspi1 should be put before &nfc. 

Shawn

> -- 
> 1.8.1.5
> 
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss



From shawn.guo at linaro.org  Mon Apr  8 02:36:24 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Mon, 8 Apr 2013 14:36:24 +0800
Subject: [PATCH 3/3] ARM: dts: Add missing imx27-phytec-phycore dtb target
In-Reply-To: <1365348554-24345-3-git-send-email-shc_work@mail.ru>
References: <1365348554-24345-1-git-send-email-shc_work@mail.ru>
 <1365348554-24345-3-git-send-email-shc_work@mail.ru>
Message-ID: <20130408063621.GD5047@S2101-09.ap.freescale.net>

On Sun, Apr 07, 2013 at 07:29:14PM +0400, Alexander Shiyan wrote:
> The patch adds missing imx27-phytec-phycore dtb target into Makefile.
> 
> Signed-off-by: Alexander Shiyan <shc_work at mail.ru>

Applied, thanks.

> ---
>  arch/arm/boot/dts/Makefile | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 35976f0..a06d9f1 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -98,6 +98,7 @@ dtb-$(CONFIG_ARCH_MXC) += \
>  	imx27-apf27.dtb \
>  	imx27-apf27dev.dtb \
>  	imx27-pdk.dtb \
> +	imx27-phytec-phycore.dtb \
>  	imx31-bug.dtb \
>  	imx51-apf51.dtb \
>  	imx51-apf51dev.dtb \
> -- 
> 1.8.1.5
> 
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss



From shawn.guo at linaro.org  Mon Apr  8 02:43:56 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Mon, 8 Apr 2013 14:43:56 +0800
Subject: [PATCH] ARM: dts: imx51 cpu node
In-Reply-To: <1365364605-10087-1-git-send-email-mpa@pengutronix.de>
References: <1365364605-10087-1-git-send-email-mpa@pengutronix.de>
Message-ID: <20130408064353.GE5047@S2101-09.ap.freescale.net>

On Sun, Apr 07, 2013 at 09:56:45PM +0200, Markus Pargmann wrote:
> This patch adds a cpus/cpu at 0 node for imx51 with default operating
> points for the cpufreq-cpu0 driver. There is currently no regulator
> support, so the voltages are 0 here.
> 
> Signed-off-by: Markus Pargmann <mpa at pengutronix.de>

Applied, thanks.



From ludovic.desroches at atmel.com  Mon Apr  8 02:43:29 2013
From: ludovic.desroches at atmel.com (ludovic.desroches at atmel.com)
Date: Mon, 8 Apr 2013 08:43:29 +0200
Subject: [RFC v2 PATCH] at_hdmac: move to generic DMA binding
Message-ID: <1365403409-18381-1-git-send-email-ludovic.desroches@atmel.com>

From: Ludovic Desroches <ludovic.desroches at atmel.com>

Signed-off-by: Ludovic Desroches <ludovic.desroches at atmel.com>
---

Hi,

Here is a second try to move at_hdmac to generic DMA binding. I have updated
bindings according to Arnd comments ie I have removed chunk transfer size.

I have added the implementation but I am not very happy with the translation
function. I have tried to not break old stuff: slave ask for a channel giving
an atslave structure (passed through pdata) as a parameter for the filter
function which saves this structure into chan->private. Then chan->private
contains the configuration for the channel CFG register which is done when
calling device_alloc_chan_resources.

If I allocate the atslave structure in the xlate function, where should be the
right place to deallocate it? For the moment, I choose to add the atslave
structure to the at_dma_chan structure but I am not happy with writing the
channel configuration register into the xlate function. I would like to keep
the same path as before.

Regards

Ludovic


 .../devicetree/bindings/dma/atmel-dma.txt          | 27 +++++++-
 arch/arm/boot/dts/sama5d3.dtsi                     |  2 +
 drivers/dma/at_hdmac.c                             | 71 ++++++++++++++++++++--
 drivers/dma/at_hdmac_regs.h                        |  7 +++
 4 files changed, 99 insertions(+), 8 deletions(-)

diff --git a/Documentation/devicetree/bindings/dma/atmel-dma.txt b/Documentation/devicetree/bindings/dma/atmel-dma.txt
index 3c046ee..2d6f0f3 100644
--- a/Documentation/devicetree/bindings/dma/atmel-dma.txt
+++ b/Documentation/devicetree/bindings/dma/atmel-dma.txt
@@ -4,11 +4,34 @@ Required properties:
 - compatible: Should be "atmel,<chip>-dma"
 - reg: Should contain DMA registers location and length
 - interrupts: Should contain DMA interrupt
+- #dma-cells: Must be <2>
 
-Examples:
+Example:
 
-dma at ffffec00 {
+dma0: dma at ffffec00 {
 	compatible = "atmel,at91sam9g45-dma";
 	reg = <0xffffec00 0x200>;
 	interrupts = <21>;
+	#dma-cells = <2>;
+};
+
+DMA clients connected to the Atmel DMA controller must use the format
+described in the dma.txt file, using a three-cell specifier for each channel.
+The three cells in order are:
+
+1. A phandle pointing to the DMA controller
+2. The memory interface (16 most significant bits), the peripheral interface
+(16 less significant bits)
+3. The peripheral identifier (can be different for tx and rx)
+
+Example:
+
+i2c0 at i2c@f8010000 {
+	compatible = "atmel,at91sam9x5-i2c";
+	reg = <0xf8010000 0x100>;
+	interrupts = <9 4 6>;
+	dmas = <&dma0 1 7>,
+	       <&dma0 1 8>;
+	dma-names = "tx", "rx"
 };
diff --git a/arch/arm/boot/dts/sama5d3.dtsi b/arch/arm/boot/dts/sama5d3.dtsi
index 39b0458..9232143 100644
--- a/arch/arm/boot/dts/sama5d3.dtsi
+++ b/arch/arm/boot/dts/sama5d3.dtsi
@@ -349,6 +349,7 @@
 				reg = <0xffffe600 0x200>;
 				interrupts = <30 4 0>;
 				#dma-cells = <1>;
+				#dma-cells = <2>;
 			};
 
 			dma1: dma-controller at ffffe800 {
@@ -356,6 +357,7 @@
 				reg = <0xffffe800 0x200>;
 				interrupts = <31 4 0>;
 				#dma-cells = <1>;
+				#dma-cells = <2>;
 			};
 
 			ramc0: ramc at ffffea00 {
diff --git a/drivers/dma/at_hdmac.c b/drivers/dma/at_hdmac.c
index 8415467..ec7f561 100644
--- a/drivers/dma/at_hdmac.c
+++ b/drivers/dma/at_hdmac.c
@@ -24,6 +24,7 @@
 #include <linux/slab.h>
 #include <linux/of.h>
 #include <linux/of_device.h>
+#include <linux/of_dma.h>
 
 #include "at_hdmac_regs.h"
 #include "dmaengine.h"
@@ -676,7 +677,7 @@ atc_prep_slave_sg(struct dma_chan *chan, struct scatterlist *sgl,
 		ctrlb |=  ATC_DST_ADDR_MODE_FIXED
 			| ATC_SRC_ADDR_MODE_INCR
 			| ATC_FC_MEM2PER
-			| ATC_SIF(AT_DMA_MEM_IF) | ATC_DIF(AT_DMA_PER_IF);
+			| ATC_SIF(atchan->mem_if) | ATC_DIF(atchan->per_if);
 		reg = sconfig->dst_addr;
 		for_each_sg(sgl, sg, sg_len, i) {
 			struct at_desc	*desc;
@@ -715,7 +716,7 @@ atc_prep_slave_sg(struct dma_chan *chan, struct scatterlist *sgl,
 		ctrlb |=  ATC_DST_ADDR_MODE_INCR
 			| ATC_SRC_ADDR_MODE_FIXED
 			| ATC_FC_PER2MEM
-			| ATC_SIF(AT_DMA_PER_IF) | ATC_DIF(AT_DMA_MEM_IF);
+			| ATC_SIF(atchan->per_if) | ATC_DIF(atchan->mem_if);
 
 		reg = sconfig->src_addr;
 		for_each_sg(sgl, sg, sg_len, i) {
@@ -821,8 +822,8 @@ atc_dma_cyclic_fill_desc(struct dma_chan *chan, struct at_desc *desc,
 		desc->lli.ctrlb = ATC_DST_ADDR_MODE_FIXED
 				| ATC_SRC_ADDR_MODE_INCR
 				| ATC_FC_MEM2PER
-				| ATC_SIF(AT_DMA_MEM_IF)
-				| ATC_DIF(AT_DMA_PER_IF);
+				| ATC_SIF(atchan->mem_if)
+				| ATC_DIF(atchan->per_if);
 		break;
 
 	case DMA_DEV_TO_MEM:
@@ -832,8 +833,8 @@ atc_dma_cyclic_fill_desc(struct dma_chan *chan, struct at_desc *desc,
 		desc->lli.ctrlb = ATC_DST_ADDR_MODE_INCR
 				| ATC_SRC_ADDR_MODE_FIXED
 				| ATC_FC_PER2MEM
-				| ATC_SIF(AT_DMA_PER_IF)
-				| ATC_DIF(AT_DMA_MEM_IF);
+				| ATC_SIF(atchan->per_if)
+				| ATC_DIF(atchan->mem_if);
 		break;
 
 	default:
@@ -1189,6 +1190,55 @@ static void atc_free_chan_resources(struct dma_chan *chan)
 	dev_vdbg(chan2dev(chan), "free_chan_resources: done\n");
 }
 
+static bool at_dma_filter(struct dma_chan *chan, void *dma_dev)
+{
+	if (dma_dev == chan->device->dev)
+		return true;
+	else
+		return false;
+}
+
+static struct dma_chan *at_dma_xlate(struct of_phandle_args *dma_spec,
+				     struct of_dma *of_dma)
+{
+	struct dma_chan *chan;
+	struct at_dma_chan *atchan;
+	struct at_dma_slave *atslave;
+	dma_cap_mask_t mask;
+	unsigned int per_id;
+	struct platform_device *dmac_pdev;
+
+	if (dma_spec->args_count != 2)
+		return NULL;
+
+	dmac_pdev = of_find_device_by_node(dma_spec->np);
+
+	dma_cap_zero(mask);
+	dma_cap_set(DMA_SLAVE, mask);
+
+	chan = dma_request_channel(mask, at_dma_filter, &dmac_pdev->dev);
+	if (!chan)
+		return NULL;
+
+	atchan = to_at_dma_chan(chan);
+	atchan->per_if = dma_spec->args[0] & 0xff;
+	atchan->mem_if = (dma_spec->args[0] >> 16) & 0xff;
+
+	atslave = &atchan->atslave;
+	/*
+	 * We can fill both SRC_PER and DST_PER, one of these fields will be
+	 * ignored depending on DMA transfer direction.
+	 */
+	per_id = dma_spec->args[1];
+	atslave->cfg = ATC_FIFOCFG_HALFFIFO | ATC_DST_H2SEL_HW
+		      | ATC_SRC_H2SEL_HW | ATC_DST_PER(per_id)
+		      | ATC_SRC_PER(per_id);
+	atslave->dma_dev = &dmac_pdev->dev;
+	chan->private = atslave;
+	channel_writel(atchan, CFG, atslave->cfg);
+
+	return chan;
+}
 
 /*--  Module Management  -----------------------------------------------*/
 
@@ -1389,6 +1439,15 @@ static int __init at_dma_probe(struct platform_device *pdev)
 
 	dma_async_device_register(&atdma->dma_common);
 
+	if (pdev->dev.of_node) {
+		printk("=== of_dma_controller_register ===\n");
+		err = of_dma_controller_register(pdev->dev.of_node,
+						 at_dma_xlate, atdma);
+		if (err && err != -ENODEV)
+			dev_err(&pdev->dev,
+				"could not register of_dma_controller\n");
+	}
+
 	return 0;
 
 err_pool_create:
diff --git a/drivers/dma/at_hdmac_regs.h b/drivers/dma/at_hdmac_regs.h
index 0eb3c13..e3d2f12 100644
--- a/drivers/dma/at_hdmac_regs.h
+++ b/drivers/dma/at_hdmac_regs.h
@@ -220,6 +220,8 @@ enum atc_status {
  * @device: parent device
  * @ch_regs: memory mapped register base
  * @mask: channel index in a mask
+ * @per_if: peripheral interface
+ * @mem_if: memory interface
  * @status: transmit status information from irq/prep* functions
  *                to tasklet (use atomic operations)
  * @tasklet: bottom half to finish transaction work
@@ -227,6 +229,8 @@ enum atc_status {
  * @save_dscr: for cyclic operations, preserve next descriptor address in
  *             the cyclic list on suspend/resume cycle
  * @dma_sconfig: configuration for slave transfers, passed via DMA_SLAVE_CONFIG
+ * @atslave: hardware configuration for slave transfers which is not passed via
+ * DMA_SLAVE_CONFIG
  * @lock: serializes enqueue/dequeue operations to descriptors lists
  * @active_list: list of descriptors dmaengine is being running on
  * @queue: list of descriptors ready to be submitted to engine
@@ -238,11 +242,14 @@ struct at_dma_chan {
 	struct at_dma		*device;
 	void __iomem		*ch_regs;
 	u8			mask;
+	u8			per_if;
+	u8			mem_if;
 	unsigned long		status;
 	struct tasklet_struct	tasklet;
 	u32			save_cfg;
 	u32			save_dscr;
 	struct dma_slave_config dma_sconfig;
+	struct at_dma_slave	atslave;
 
 	spinlock_t		lock;
 
-- 
1.7.11.3



From shawn.guo at linaro.org  Mon Apr  8 02:44:55 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Mon, 8 Apr 2013 14:44:55 +0800
Subject: [PATCH] ARM: dts: imx6dl-wandboard: Add USB Host support
In-Reply-To: <1365376426-13919-1-git-send-email-festevam@gmail.com>
References: <1365376426-13919-1-git-send-email-festevam@gmail.com>
Message-ID: <20130408064452.GF5047@S2101-09.ap.freescale.net>

On Sun, Apr 07, 2013 at 08:13:45PM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam at freescale.com>
> 
> Add USB Host1 port support.
> 
> Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
> ---
>  arch/arm/boot/dts/imx6dl-wandboard.dts |    4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/imx6dl-wandboard.dts b/arch/arm/boot/dts/imx6dl-wandboard.dts
> index d3ea90a..735911b 100644
> --- a/arch/arm/boot/dts/imx6dl-wandboard.dts
> +++ b/arch/arm/boot/dts/imx6dl-wandboard.dts
> @@ -38,3 +38,7 @@
>  	pinctrl-0 = <&pinctrl_usdhc3_2>;
>  	status = "okay";
>  };
> +
> +&usbh1 {
> +	status = "okay";
> +};

Applied, but moved the node before usdhc3 to have them sorted in
alphabet.

Shawn



From peter.ujfalusi at ti.com  Mon Apr  8 03:11:04 2013
From: peter.ujfalusi at ti.com (Peter Ujfalusi)
Date: Mon, 8 Apr 2013 09:11:04 +0200
Subject: [RFC v2] dmaengine: omap-dma: Start DMA without delay for cyclic
 channels
In-Reply-To: <1364987862-14597-1-git-send-email-peter.ujfalusi@ti.com>
References: <1364987862-14597-1-git-send-email-peter.ujfalusi@ti.com>
Message-ID: <51626D88.8020809@ti.com>

Russell,

On 04/03/2013 01:17 PM, Peter Ujfalusi wrote:
> cyclic DMA is only used by audio which needs DMA to be started without a
> delay.
> If the DMA for audio is started using the tasklet we experience random
> channel switch (to be more precise: channel shift).
> 
> Reported-by: Peter Meerwald <pmeerw at pmeerw.net>
> Signed-off-by: Peter Ujfalusi <peter.ujfalusi at ti.com>
> ---
> Hi Russell,
> 
> Instead of removing the tasklet we can identify the DMA channel used by audio
> based on the cyclic flag of the channel.
> I think this can be used as a short term solution to fix the audio channel shift
> issue and later when we have the dynamic DMA channel allocation we can adjust
> the code.

Could you, please look at this patch?

Thank you,
P?ter

> Regards,
> Peter
> 
>  drivers/dma/omap-dma.c | 20 ++++++++++++++------
>  1 file changed, 14 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
> index 2ea3d7e..ec3fc4f 100644
> --- a/drivers/dma/omap-dma.c
> +++ b/drivers/dma/omap-dma.c
> @@ -282,12 +282,20 @@ static void omap_dma_issue_pending(struct dma_chan *chan)
>  
>  	spin_lock_irqsave(&c->vc.lock, flags);
>  	if (vchan_issue_pending(&c->vc) && !c->desc) {
> -		struct omap_dmadev *d = to_omap_dma_dev(chan->device);
> -		spin_lock(&d->lock);
> -		if (list_empty(&c->node))
> -			list_add_tail(&c->node, &d->pending);
> -		spin_unlock(&d->lock);
> -		tasklet_schedule(&d->task);
> +		/*
> +		 * c->cyclic is used only by audio and in this case the DMA need
> +		 * to be started without delay.
> +		 */
> +		if (!c->cyclic) {
> +			struct omap_dmadev *d = to_omap_dma_dev(chan->device);
> +			spin_lock(&d->lock);
> +			if (list_empty(&c->node))
> +				list_add_tail(&c->node, &d->pending);
> +			spin_unlock(&d->lock);
> +			tasklet_schedule(&d->task);
> +		} else {
> +			omap_dma_start_desc(c);
> +		}
>  	}
>  	spin_unlock_irqrestore(&c->vc.lock, flags);
>  }
> 



From kgene.kim at samsung.com  Mon Apr  8 03:22:51 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Mon, 08 Apr 2013 16:22:51 +0900
Subject: [PATCH] clk: exynos4: export clocks required for fimc-is
In-Reply-To: <20130405183221.7302.97946@quantum>
References: <1365184185-23794-1-git-send-email-s.nawrocki@samsung.com>
 <20130405183221.7302.97946@quantum>
Message-ID: <2c8f01ce3429$e110ef50$a332cdf0$%kim@samsung.com>

Mike Turquette wrote:
> 
> Quoting Sylwester Nawrocki (2013-04-05 10:49:45)
> > This patch adds clock indexes for ACLK_DIV0, ACLK_DIV1,
> > ACLK_400_MCUISP, ACLK_MCUISP_DIV0, ACLK_MCUISP_DIV1,
> > DIVACLK_400_MCUISP and DIVACLK_200 so these clocks are
> > available to the consumers (Exynos4x12 FIMC-IS subsystem).
> > While at it, indentation of the mux clocks table is
> > corrected.
> >
> > Signed-off-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
> > Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
> 
> Acked-by: Mike Turquette <mturquette at linaro.org>
> 
Thanks, applied into next/clk-exynos.

- Kukjin



From kgene.kim at samsung.com  Mon Apr  8 03:23:53 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Mon, 08 Apr 2013 16:23:53 +0900
Subject: [PATCH] ARM: dts: add device tree file for SD5v1 board
Message-ID: <2c9301ce342a$06432ea0$12c98be0$%kim@samsung.com>


This patch adds SD5v1.dts file for supporting SD5v1(Exynos5440) board.

Signed-off-by: Kukjin Kim <kgene.kim at samsung.com>
---
 arch/arm/boot/dts/Makefile             |    1 +
 arch/arm/boot/dts/exynos5440-sd5v1.dts |   39 ++++++++++++++++++++++++++++++++
 2 files changed, 40 insertions(+)
 create mode 100644 arch/arm/boot/dts/exynos5440-sd5v1.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index d3cd880..11fef62 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -46,6 +46,7 @@ dtb-$(CONFIG_ARCH_EXYNOS) += exynos4210-origen.dtb \
 	exynos4412-smdk4412.dtb \
 	exynos4412-origen.dtb \
 	exynos5250-arndale.dtb \
+	exynos5440-sd5v1.dtb \
 	exynos5250-smdk5250.dtb \
 	exynos5250-snow.dtb \
 	exynos5440-ssdk5440.dtb
diff --git a/arch/arm/boot/dts/exynos5440-sd5v1.dts b/arch/arm/boot/dts/exynos5440-sd5v1.dts
new file mode 100644
index 0000000..ef747b5
--- /dev/null
+++ b/arch/arm/boot/dts/exynos5440-sd5v1.dts
@@ -0,0 +1,39 @@
+/*
+ * SAMSUNG SD5v1 board device tree source
+ *
+ * Copyright (c) 2013 Samsung Electronics Co., Ltd.
+ *		http://www.samsung.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.
+*/
+
+/dts-v1/;
+/include/ "exynos5440.dtsi"
+
+/ {
+	model = "SAMSUNG SD5v1 board based on EXYNOS5440";
+	compatible = "samsung,sd5v1", "samsung,exynos5440";
+
+	chosen {
+		bootargs = "root=/dev/sda2 rw rootwait ignore_loglevel early_printk no_console_suspend mem=2048M at 0x80000000
console=ttySAC0,115200";
+	};
+
+	fixed-rate-clocks {
+		xtal {
+			compatible = "samsung,clock-xtal";
+			clock-frequency = <50000000>;
+		};
+	};
+
+	gmac: ethernet at 00230000 {
+		fixed_phy;
+		phy_addr = <1>;
+	};
+
+	spi {
+		status = "disabled";
+	};
+
+};
-- 
1.7.10.4



From plagnioj at jcrosoft.com  Mon Apr  8 03:33:29 2013
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Mon, 8 Apr 2013 09:33:29 +0200
Subject: [RFC 1/5] ARM: at91: add general purpose backup register
 (GPBR) support
In-Reply-To: <1365347572-14972-1-git-send-email-jhovold@gmail.com>
References: <20130407150938.GA25605@localhost>
 <1365347572-14972-1-git-send-email-jhovold@gmail.com>
Message-ID: <20130408073329.GO20693@game.jcrosoft.org>

On 17:12 Sun 07 Apr     , Johan Hovold wrote:
> 
> Add General Purpose Backup Register (GPBR) support.
> 
> Most at91 SoCs have at least four 32-bit General Purpose Backup
> Registers (GPBR) powered by backup-power (VDDBU). One such register is
> currently used by rtc-at91sam9 driver to store the RTC time base.
> 
> Make sure the registers are mapped by arch setup code and add generic
> accessors for in-kernel use.
> 
> This is a step in adding device-tree support to the rtc-at91sam9 driver.
> 
This is a regression

we loose the tracking of what request and use the GPBR

Best Regsards,
J.
> Signed-off-by: Johan Hovold <jhovold at gmail.com>
> ---
>  arch/arm/mach-at91/at91sam9260.c            |  1 +
>  arch/arm/mach-at91/at91sam9260_devices.c    | 15 +++--------
>  arch/arm/mach-at91/at91sam9261.c            |  1 +
>  arch/arm/mach-at91/at91sam9261_devices.c    | 15 +++--------
>  arch/arm/mach-at91/at91sam9263.c            |  1 +
>  arch/arm/mach-at91/at91sam9263_devices.c    | 18 +++----------
>  arch/arm/mach-at91/at91sam9g45.c            |  1 +
>  arch/arm/mach-at91/at91sam9g45_devices.c    | 15 +++--------
>  arch/arm/mach-at91/at91sam9rl.c             |  1 +
>  arch/arm/mach-at91/at91sam9rl_devices.c     | 15 +++--------
>  arch/arm/mach-at91/generic.h                |  3 +++
>  arch/arm/mach-at91/include/mach/at91_gpbr.h | 29 ++++++++++++++++++++
>  arch/arm/mach-at91/setup.c                  | 10 +++++++
>  drivers/rtc/rtc-at91sam9.c                  | 41 +++++++++--------------------
>  14 files changed, 76 insertions(+), 90 deletions(-)
>  create mode 100644 arch/arm/mach-at91/include/mach/at91_gpbr.h
> 
> diff --git a/arch/arm/mach-at91/at91sam9260.c b/arch/arm/mach-at91/at91sam9260.c
> index b67cd53..984b0d5 100644
> --- a/arch/arm/mach-at91/at91sam9260.c
> +++ b/arch/arm/mach-at91/at91sam9260.c
> @@ -334,6 +334,7 @@ static void __init at91sam9260_map_io(void)
>  
>  static void __init at91sam9260_ioremap_registers(void)
>  {
> +	at91_ioremap_gpbr(AT91SAM9260_BASE_GPBR, 0x10);
>  	at91_ioremap_shdwc(AT91SAM9260_BASE_SHDWC);
>  	at91_ioremap_rstc(AT91SAM9260_BASE_RSTC);
>  	at91_ioremap_ramc(0, AT91SAM9260_BASE_SDRAMC, 512);
> diff --git a/arch/arm/mach-at91/at91sam9260_devices.c b/arch/arm/mach-at91/at91sam9260_devices.c
> index eda8d16..10c71a8 100644
> --- a/arch/arm/mach-at91/at91sam9260_devices.c
> +++ b/arch/arm/mach-at91/at91sam9260_devices.c
> @@ -649,8 +649,6 @@ static struct resource rtt_resources[] = {
>  		.end	= AT91SAM9260_BASE_RTT + SZ_16 - 1,
>  		.flags	= IORESOURCE_MEM,
>  	}, {
> -		.flags	= IORESOURCE_MEM,
> -	}, {
>  		.flags  = IORESOURCE_IRQ,
>  	},
>  };
> @@ -666,16 +664,9 @@ static struct platform_device at91sam9260_rtt_device = {
>  static void __init at91_add_device_rtt_rtc(void)
>  {
>  	at91sam9260_rtt_device.name = "rtc-at91sam9";
> -	/*
> -	 * The second resource is needed:
> -	 * GPBR will serve as the storage for RTC time offset
> -	 */
> -	at91sam9260_rtt_device.num_resources = 3;
> -	rtt_resources[1].start = AT91SAM9260_BASE_GPBR +
> -				 4 * CONFIG_RTC_DRV_AT91SAM9_GPBR;
> -	rtt_resources[1].end = rtt_resources[1].start + 3;
> -	rtt_resources[2].start = NR_IRQS_LEGACY + AT91_ID_SYS;
> -	rtt_resources[2].end = NR_IRQS_LEGACY + AT91_ID_SYS;
> +	at91sam9260_rtt_device.num_resources = 2;
> +	rtt_resources[1].start = NR_IRQS_LEGACY + AT91_ID_SYS;
> +	rtt_resources[1].end = NR_IRQS_LEGACY + AT91_ID_SYS;
>  }
>  #else
>  static void __init at91_add_device_rtt_rtc(void)
> diff --git a/arch/arm/mach-at91/at91sam9261.c b/arch/arm/mach-at91/at91sam9261.c
> index 0204f4c..b234c5d 100644
> --- a/arch/arm/mach-at91/at91sam9261.c
> +++ b/arch/arm/mach-at91/at91sam9261.c
> @@ -278,6 +278,7 @@ static void __init at91sam9261_map_io(void)
>  
>  static void __init at91sam9261_ioremap_registers(void)
>  {
> +	at91_ioremap_gpbr(AT91SAM9261_BASE_GPBR, 0x10);
>  	at91_ioremap_shdwc(AT91SAM9261_BASE_SHDWC);
>  	at91_ioremap_rstc(AT91SAM9261_BASE_RSTC);
>  	at91_ioremap_ramc(0, AT91SAM9261_BASE_SDRAMC, 512);
> diff --git a/arch/arm/mach-at91/at91sam9261_devices.c b/arch/arm/mach-at91/at91sam9261_devices.c
> index 629ea5f..e8ff5e7 100644
> --- a/arch/arm/mach-at91/at91sam9261_devices.c
> +++ b/arch/arm/mach-at91/at91sam9261_devices.c
> @@ -618,8 +618,6 @@ static struct resource rtt_resources[] = {
>  		.end	= AT91SAM9261_BASE_RTT + SZ_16 - 1,
>  		.flags	= IORESOURCE_MEM,
>  	}, {
> -		.flags	= IORESOURCE_MEM,
> -	}, {
>  		.flags  = IORESOURCE_IRQ,
>  	}
>  };
> @@ -634,16 +632,9 @@ static struct platform_device at91sam9261_rtt_device = {
>  static void __init at91_add_device_rtt_rtc(void)
>  {
>  	at91sam9261_rtt_device.name = "rtc-at91sam9";
> -	/*
> -	 * The second resource is needed:
> -	 * GPBR will serve as the storage for RTC time offset
> -	 */
> -	at91sam9261_rtt_device.num_resources = 3;
> -	rtt_resources[1].start = AT91SAM9261_BASE_GPBR +
> -				 4 * CONFIG_RTC_DRV_AT91SAM9_GPBR;
> -	rtt_resources[1].end = rtt_resources[1].start + 3;
> -	rtt_resources[2].start = NR_IRQS_LEGACY + AT91_ID_SYS;
> -	rtt_resources[2].end = NR_IRQS_LEGACY + AT91_ID_SYS;
> +	at91sam9261_rtt_device.num_resources = 2;
> +	rtt_resources[1].start = NR_IRQS_LEGACY + AT91_ID_SYS;
> +	rtt_resources[1].end = NR_IRQS_LEGACY + AT91_ID_SYS;
>  }
>  #else
>  static void __init at91_add_device_rtt_rtc(void)
> diff --git a/arch/arm/mach-at91/at91sam9263.c b/arch/arm/mach-at91/at91sam9263.c
> index c0cbb81..42d09f5 100644
> --- a/arch/arm/mach-at91/at91sam9263.c
> +++ b/arch/arm/mach-at91/at91sam9263.c
> @@ -315,6 +315,7 @@ static void __init at91sam9263_map_io(void)
>  
>  static void __init at91sam9263_ioremap_registers(void)
>  {
> +	at91_ioremap_gpbr(AT91SAM9263_BASE_GPBR, 0x50);
>  	at91_ioremap_shdwc(AT91SAM9263_BASE_SHDWC);
>  	at91_ioremap_rstc(AT91SAM9263_BASE_RSTC);
>  	at91_ioremap_ramc(0, AT91SAM9263_BASE_SDRAMC0, 512);
> diff --git a/arch/arm/mach-at91/at91sam9263_devices.c b/arch/arm/mach-at91/at91sam9263_devices.c
> index 858c8aa..374fe56 100644
> --- a/arch/arm/mach-at91/at91sam9263_devices.c
> +++ b/arch/arm/mach-at91/at91sam9263_devices.c
> @@ -1014,8 +1014,6 @@ static struct resource rtt0_resources[] = {
>  		.end	= AT91SAM9263_BASE_RTT0 + SZ_16 - 1,
>  		.flags	= IORESOURCE_MEM,
>  	}, {
> -		.flags	= IORESOURCE_MEM,
> -	}, {
>  		.flags  = IORESOURCE_IRQ,
>  	}
>  };
> @@ -1032,8 +1030,6 @@ static struct resource rtt1_resources[] = {
>  		.end	= AT91SAM9263_BASE_RTT1 + SZ_16 - 1,
>  		.flags	= IORESOURCE_MEM,
>  	}, {
> -		.flags	= IORESOURCE_MEM,
> -	}, {
>  		.flags  = IORESOURCE_IRQ,
>  	}
>  };
> @@ -1052,18 +1048,14 @@ static void __init at91_add_device_rtt_rtc(void)
>  
>  	switch (CONFIG_RTC_DRV_AT91SAM9_RTT) {
>  	case 0:
> -		/*
> -		 * The second resource is needed only for the chosen RTT:
> -		 * GPBR will serve as the storage for RTC time offset
> -		 */
> -		at91sam9263_rtt0_device.num_resources = 3;
> +		at91sam9263_rtt0_device.num_resources = 2;
>  		at91sam9263_rtt1_device.num_resources = 1;
>  		pdev = &at91sam9263_rtt0_device;
>  		r = rtt0_resources;
>  		break;
>  	case 1:
>  		at91sam9263_rtt0_device.num_resources = 1;
> -		at91sam9263_rtt1_device.num_resources = 3;
> +		at91sam9263_rtt1_device.num_resources = 2;
>  		pdev = &at91sam9263_rtt1_device;
>  		r = rtt1_resources;
>  		break;
> @@ -1074,10 +1066,8 @@ static void __init at91_add_device_rtt_rtc(void)
>  	}
>  
>  	pdev->name = "rtc-at91sam9";
> -	r[1].start = AT91SAM9263_BASE_GPBR + 4 * CONFIG_RTC_DRV_AT91SAM9_GPBR;
> -	r[1].end = r[1].start + 3;
> -	r[2].start = NR_IRQS_LEGACY + AT91_ID_SYS;
> -	r[2].end = NR_IRQS_LEGACY + AT91_ID_SYS;
> +	r[1].start = NR_IRQS_LEGACY + AT91_ID_SYS;
> +	r[1].end = NR_IRQS_LEGACY + AT91_ID_SYS;
>  }
>  #else
>  static void __init at91_add_device_rtt_rtc(void)
> diff --git a/arch/arm/mach-at91/at91sam9g45.c b/arch/arm/mach-at91/at91sam9g45.c
> index b4968aa..4b9547f 100644
> --- a/arch/arm/mach-at91/at91sam9g45.c
> +++ b/arch/arm/mach-at91/at91sam9g45.c
> @@ -361,6 +361,7 @@ static void __init at91sam9g45_map_io(void)
>  
>  static void __init at91sam9g45_ioremap_registers(void)
>  {
> +	at91_ioremap_gpbr(AT91SAM9G45_BASE_GPBR, 0x10);
>  	at91_ioremap_shdwc(AT91SAM9G45_BASE_SHDWC);
>  	at91_ioremap_rstc(AT91SAM9G45_BASE_RSTC);
>  	at91_ioremap_ramc(0, AT91SAM9G45_BASE_DDRSDRC1, 512);
> diff --git a/arch/arm/mach-at91/at91sam9g45_devices.c b/arch/arm/mach-at91/at91sam9g45_devices.c
> index fe626d4..65d700b 100644
> --- a/arch/arm/mach-at91/at91sam9g45_devices.c
> +++ b/arch/arm/mach-at91/at91sam9g45_devices.c
> @@ -1290,8 +1290,6 @@ static struct resource rtt_resources[] = {
>  		.end	= AT91SAM9G45_BASE_RTT + SZ_16 - 1,
>  		.flags	= IORESOURCE_MEM,
>  	}, {
> -		.flags	= IORESOURCE_MEM,
> -	}, {
>  		.flags  = IORESOURCE_IRQ,
>  	}
>  };
> @@ -1306,16 +1304,9 @@ static struct platform_device at91sam9g45_rtt_device = {
>  static void __init at91_add_device_rtt_rtc(void)
>  {
>  	at91sam9g45_rtt_device.name = "rtc-at91sam9";
> -	/*
> -	 * The second resource is needed:
> -	 * GPBR will serve as the storage for RTC time offset
> -	 */
> -	at91sam9g45_rtt_device.num_resources = 3;
> -	rtt_resources[1].start = AT91SAM9G45_BASE_GPBR +
> -				 4 * CONFIG_RTC_DRV_AT91SAM9_GPBR;
> -	rtt_resources[1].end = rtt_resources[1].start + 3;
> -	rtt_resources[2].start = NR_IRQS_LEGACY + AT91_ID_SYS;
> -	rtt_resources[2].end = NR_IRQS_LEGACY + AT91_ID_SYS;
> +	at91sam9g45_rtt_device.num_resources = 2;
> +	rtt_resources[1].start = NR_IRQS_LEGACY + AT91_ID_SYS;
> +	rtt_resources[1].end = NR_IRQS_LEGACY + AT91_ID_SYS;
>  }
>  #else
>  static void __init at91_add_device_rtt_rtc(void)
> diff --git a/arch/arm/mach-at91/at91sam9rl.c b/arch/arm/mach-at91/at91sam9rl.c
> index 3de3e04..bf7e555 100644
> --- a/arch/arm/mach-at91/at91sam9rl.c
> +++ b/arch/arm/mach-at91/at91sam9rl.c
> @@ -281,6 +281,7 @@ static void __init at91sam9rl_map_io(void)
>  
>  static void __init at91sam9rl_ioremap_registers(void)
>  {
> +	at91_ioremap_gpbr(AT91SAM9RL_BASE_GPBR, 0x10);
>  	at91_ioremap_shdwc(AT91SAM9RL_BASE_SHDWC);
>  	at91_ioremap_rstc(AT91SAM9RL_BASE_RSTC);
>  	at91_ioremap_ramc(0, AT91SAM9RL_BASE_SDRAMC, 512);
> diff --git a/arch/arm/mach-at91/at91sam9rl_devices.c b/arch/arm/mach-at91/at91sam9rl_devices.c
> index 352468f..533948c 100644
> --- a/arch/arm/mach-at91/at91sam9rl_devices.c
> +++ b/arch/arm/mach-at91/at91sam9rl_devices.c
> @@ -687,8 +687,6 @@ static struct resource rtt_resources[] = {
>  		.end	= AT91SAM9RL_BASE_RTT + SZ_16 - 1,
>  		.flags	= IORESOURCE_MEM,
>  	}, {
> -		.flags	= IORESOURCE_MEM,
> -	}, {
>  		.flags  = IORESOURCE_IRQ,
>  	}
>  };
> @@ -703,16 +701,9 @@ static struct platform_device at91sam9rl_rtt_device = {
>  static void __init at91_add_device_rtt_rtc(void)
>  {
>  	at91sam9rl_rtt_device.name = "rtc-at91sam9";
> -	/*
> -	 * The second resource is needed:
> -	 * GPBR will serve as the storage for RTC time offset
> -	 */
> -	at91sam9rl_rtt_device.num_resources = 3;
> -	rtt_resources[1].start = AT91SAM9RL_BASE_GPBR +
> -				 4 * CONFIG_RTC_DRV_AT91SAM9_GPBR;
> -	rtt_resources[1].end = rtt_resources[1].start + 3;
> -	rtt_resources[2].start = NR_IRQS_LEGACY + AT91_ID_SYS;
> -	rtt_resources[2].end = NR_IRQS_LEGACY + AT91_ID_SYS;
> +	at91sam9rl_rtt_device.num_resources = 2;
> +	rtt_resources[1].start = NR_IRQS_LEGACY + AT91_ID_SYS;
> +	rtt_resources[1].end = NR_IRQS_LEGACY + AT91_ID_SYS;
>  }
>  #else
>  static void __init at91_add_device_rtt_rtc(void)
> diff --git a/arch/arm/mach-at91/generic.h b/arch/arm/mach-at91/generic.h
> index fc593d6..6d444cc 100644
> --- a/arch/arm/mach-at91/generic.h
> +++ b/arch/arm/mach-at91/generic.h
> @@ -59,6 +59,9 @@ extern void at91_irq_resume(void);
>  /* idle */
>  extern void at91sam9_idle(void);
>  
> +/* backup registers */
> +extern void at91_ioremap_gpbr(u32 base_addr, u32 size);
> +
>  /* reset */
>  extern void at91_ioremap_rstc(u32 base_addr);
>  extern void at91sam9_alt_restart(char, const char *);
> diff --git a/arch/arm/mach-at91/include/mach/at91_gpbr.h b/arch/arm/mach-at91/include/mach/at91_gpbr.h
> new file mode 100644
> index 0000000..f4b4895
> --- /dev/null
> +++ b/arch/arm/mach-at91/include/mach/at91_gpbr.h
> @@ -0,0 +1,29 @@
> +/*
> + * arch/arm/mach-at91/include/mach/at91_gpbr.h
> + *
> + * Copyright (C) 2013 Johan Hovold <jhovold at gmail.com>
> + *
> + * General Purpose Backup Registers (GPBR)
> + *
> + * 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.
> + */
> +
> +#ifndef AT91_GPBR_H
> +#define AT91_GPBR_H
> +
> +extern void __iomem *at91_gpbr_base;
> +
> +static inline u32 at91_gpbr_read(unsigned nr)
> +{
> +	return __raw_readl(at91_gpbr_base + ((nr) << 2));
> +}
> +
> +static inline void at91_gpbr_write(unsigned nr, u32 value)
> +{
> +	__raw_writel(value, at91_gpbr_base + ((nr) << 2));
> +}
> +
> +#endif	/* AT91_GPBR_H */
> diff --git a/arch/arm/mach-at91/setup.c b/arch/arm/mach-at91/setup.c
> index 9e7c1e1..b01f4aa 100644
> --- a/arch/arm/mach-at91/setup.c
> +++ b/arch/arm/mach-at91/setup.c
> @@ -18,6 +18,7 @@
>  #include <mach/hardware.h>
>  #include <mach/cpu.h>
>  #include <mach/at91_dbgu.h>
> +#include <mach/at91_gpbr.h>
>  #include <mach/at91_pmc.h>
>  
>  #include "at91_shdwc.h"
> @@ -277,6 +278,15 @@ void __init at91_map_io(void)
>  		at91_boot_soc.map_io();
>  }
>  
> +void __iomem *at91_gpbr_base;
> +
> +void __init at91_ioremap_gpbr(u32 base_addr, u32 size)
> +{
> +	at91_gpbr_base = ioremap(base_addr, size);
> +	if (!at91_gpbr_base)
> +		panic("AT91: Failed to ioremap gpbr registers\n");
> +}
> +
>  void __iomem *at91_shdwc_base = NULL;
>  
>  static void at91sam9_poweroff(void)
> diff --git a/drivers/rtc/rtc-at91sam9.c b/drivers/rtc/rtc-at91sam9.c
> index 39cfd2e..983667b 100644
> --- a/drivers/rtc/rtc-at91sam9.c
> +++ b/drivers/rtc/rtc-at91sam9.c
> @@ -21,6 +21,7 @@
>  #include <linux/slab.h>
>  #include <linux/platform_data/atmel.h>
>  
> +#include <mach/at91_gpbr.h>
>  #include <mach/at91_rtt.h>
>  #include <mach/cpu.h>
>  
> @@ -57,7 +58,7 @@ struct sam9_rtc {
>  	void __iomem		*rtt;
>  	struct rtc_device	*rtcdev;
>  	u32			imr;
> -	void __iomem		*gpbr;
> +	unsigned		gpbr;
>  	int 			irq;
>  };
>  
> @@ -66,11 +67,6 @@ struct sam9_rtc {
>  #define rtt_writel(rtc, field, val) \
>  	__raw_writel((val), (rtc)->rtt + AT91_RTT_ ## field)
>  
> -#define gpbr_readl(rtc) \
> -	__raw_readl((rtc)->gpbr)
> -#define gpbr_writel(rtc, val) \
> -	__raw_writel((val), (rtc)->gpbr)
> -
>  /*
>   * Read current time and date in RTC
>   */
> @@ -81,7 +77,7 @@ static int at91_rtc_readtime(struct device *dev, struct rtc_time *tm)
>  	u32 offset;
>  
>  	/* read current time offset */
> -	offset = gpbr_readl(rtc);
> +	offset = at91_gpbr_read(rtc->gpbr);
>  	if (offset == 0)
>  		return -EILSEQ;
>  
> @@ -124,11 +120,11 @@ static int at91_rtc_settime(struct device *dev, struct rtc_time *tm)
>  	rtt_writel(rtc, MR, mr & ~(AT91_RTT_ALMIEN | AT91_RTT_RTTINCIEN));
>  
>  	/* read current time offset */
> -	offset = gpbr_readl(rtc);
> +	offset = at91_gpbr_read(rtc->gpbr);
>  
>  	/* store the new base time in a battery backup register */
>  	secs += 1;
> -	gpbr_writel(rtc, secs);
> +	at91_gpbr_write(rtc->gpbr, secs);
>  
>  	/* adjust the alarm time for the new base */
>  	alarm = rtt_readl(rtc, AR);
> @@ -160,7 +156,7 @@ static int at91_rtc_readalarm(struct device *dev, struct rtc_wkalrm *alrm)
>  	u32 alarm = rtt_readl(rtc, AR);
>  	u32 offset;
>  
> -	offset = gpbr_readl(rtc);
> +	offset = at91_gpbr_read(rtc->gpbr);
>  	if (offset == 0)
>  		return -EILSEQ;
>  
> @@ -192,7 +188,7 @@ static int at91_rtc_setalarm(struct device *dev, struct rtc_wkalrm *alrm)
>  	if (err != 0)
>  		return err;
>  
> -	offset = gpbr_readl(rtc);
> +	offset = at91_gpbr_read(rtc->gpbr);
>  	if (offset == 0) {
>  		/* time is not set */
>  		return -EILSEQ;
> @@ -291,17 +287,14 @@ static const struct rtc_class_ops at91_rtc_ops = {
>   */
>  static int at91_rtc_probe(struct platform_device *pdev)
>  {
> -	struct resource	*r, *r_gpbr;
> +	struct resource	*r;
>  	struct sam9_rtc	*rtc;
>  	int		ret, irq;
>  	u32		mr;
>  
>  	r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> -	r_gpbr = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> -	if (!r || !r_gpbr) {
> -		dev_err(&pdev->dev, "need 2 ressources\n");
> -		return -ENODEV;
> -	}
> +	if (!r)
> +		return -ENXIO;
>  
>  	irq = platform_get_irq(pdev, 0);
>  	if (irq < 0) {
> @@ -327,19 +320,14 @@ static int at91_rtc_probe(struct platform_device *pdev)
>  		goto fail;
>  	}
>  
> -	rtc->gpbr = ioremap(r_gpbr->start, resource_size(r_gpbr));
> -	if (!rtc->gpbr) {
> -		dev_err(&pdev->dev, "failed to map gpbr registers, aborting.\n");
> -		ret = -ENOMEM;
> -		goto fail_gpbr;
> -	}
> +	rtc->gpbr = CONFIG_RTC_DRV_AT91SAM9_GPBR;
>  
>  	mr = rtt_readl(rtc, MR);
>  
>  	/* unless RTT is counting at 1 Hz, re-initialize it */
>  	if ((mr & AT91_RTT_RTPRES) != AT91_SLOW_CLOCK) {
>  		mr = AT91_RTT_RTTRST | (AT91_SLOW_CLOCK & AT91_RTT_RTPRES);
> -		gpbr_writel(rtc, 0);
> +		at91_gpbr_write(rtc->gpbr, 0);
>  	}
>  
>  	/* disable all interrupts (same as on shutdown path) */
> @@ -368,15 +356,13 @@ static int at91_rtc_probe(struct platform_device *pdev)
>  	 * clock, discrete RTC, etc
>  	 */
>  
> -	if (gpbr_readl(rtc) == 0)
> +	if (at91_gpbr_read(rtc->gpbr) == 0)
>  		dev_warn(&pdev->dev, "%s: SET TIME!\n",
>  				dev_name(&rtc->rtcdev->dev));
>  
>  	return 0;
>  
>  fail_register:
> -	iounmap(rtc->gpbr);
> -fail_gpbr:
>  	iounmap(rtc->rtt);
>  fail:
>  	platform_set_drvdata(pdev, NULL);
> @@ -398,7 +384,6 @@ static int at91_rtc_remove(struct platform_device *pdev)
>  
>  	rtc_device_unregister(rtc->rtcdev);
>  
> -	iounmap(rtc->gpbr);
>  	iounmap(rtc->rtt);
>  	platform_set_drvdata(pdev, NULL);
>  	kfree(rtc);
> -- 
> 1.8.1.5
> 


From plagnioj at jcrosoft.com  Mon Apr  8 03:35:39 2013
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Mon, 8 Apr 2013 09:35:39 +0200
Subject: [RFC 2/5] ARM: at91/dts: add general purpose backup register
 (GPBR) support
In-Reply-To: <1365347572-14972-2-git-send-email-jhovold@gmail.com>
References: <20130407150938.GA25605@localhost>
 <1365347572-14972-1-git-send-email-jhovold@gmail.com>
 <1365347572-14972-2-git-send-email-jhovold@gmail.com>
Message-ID: <20130408073539.GP20693@game.jcrosoft.org>

On 17:12 Sun 07 Apr     , Johan Hovold wrote:
> Add arch device-tree setup code and DT-nodes for the General Purpose
> Backup Registers (GPBR).
> 
> Note that all AT91 SoCs but at91rm9200 have these backup-powered
> registers.
> 
> Signed-off-by: Johan Hovold <jhovold at gmail.com>
> ---
>  .../devicetree/bindings/arm/atmel-at91.txt          |  4 ++++
>  arch/arm/boot/dts/at91sam9260.dtsi                  |  5 +++++
>  arch/arm/boot/dts/at91sam9263.dtsi                  |  5 +++++
>  arch/arm/boot/dts/at91sam9g45.dtsi                  |  5 +++++
>  arch/arm/boot/dts/at91sam9n12.dtsi                  |  5 +++++
>  arch/arm/boot/dts/at91sam9x5.dtsi                   |  5 +++++
>  arch/arm/mach-at91/setup.c                          | 21 +++++++++++++++++++++
>  7 files changed, 50 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/arm/atmel-at91.txt b/Documentation/devicetree/bindings/arm/atmel-at91.txt
> index 1196290..fe64d0a 100644
> --- a/Documentation/devicetree/bindings/arm/atmel-at91.txt
> +++ b/Documentation/devicetree/bindings/arm/atmel-at91.txt
> @@ -1,6 +1,10 @@
>  Atmel AT91 device tree bindings.
>  ================================
>  
> +General Purpose Backup Registers (GPBR) required properties:
> +- compatible: Should be "atmel,at91sam9260-gpbr"
> +- reg: Should contain register location and length
> +
>  PIT Timer required properties:
>  - compatible: Should be "atmel,at91sam9260-pit"
>  - reg: Should contain registers location and length
> diff --git a/arch/arm/boot/dts/at91sam9260.dtsi b/arch/arm/boot/dts/at91sam9260.dtsi
> index cb7bcc5..48ef04d 100644
> --- a/arch/arm/boot/dts/at91sam9260.dtsi
> +++ b/arch/arm/boot/dts/at91sam9260.dtsi
> @@ -87,6 +87,11 @@
>  				interrupts = <1 4 7>;
>  			};
>  
> +			gpbr at fffffd50 {
> +				compatible = "atmel,at91sam9260-gpbr";
> +				reg = <0xfffffd50 0x10>;
> +			};
> +
>  			tcb0: timer at fffa0000 {
>  				compatible = "atmel,at91rm9200-tcb";
>  				reg = <0xfffa0000 0x100>;
> diff --git a/arch/arm/boot/dts/at91sam9263.dtsi b/arch/arm/boot/dts/at91sam9263.dtsi
> index 271d4de..e9676ba 100644
> --- a/arch/arm/boot/dts/at91sam9263.dtsi
> +++ b/arch/arm/boot/dts/at91sam9263.dtsi
> @@ -75,6 +75,11 @@
>  				interrupts = <1 4 7>;
>  			};
>  
> +			gpbr at fffffd60 {
> +				compatible = "atmel,at91sam9260-gpbr";
> +				reg = <0xfffffd60 0x50>;
> +			};
> +
>  			tcb0: timer at fff7c000 {
>  				compatible = "atmel,at91rm9200-tcb";
>  				reg = <0xfff7c000 0x100>;
> diff --git a/arch/arm/boot/dts/at91sam9g45.dtsi b/arch/arm/boot/dts/at91sam9g45.dtsi
> index 6b1d4ca..d5e37ce 100644
> --- a/arch/arm/boot/dts/at91sam9g45.dtsi
> +++ b/arch/arm/boot/dts/at91sam9g45.dtsi
> @@ -92,6 +92,11 @@
>  				reg = <0xfffffd10 0x10>;
>  			};
>  
> +			gpbr at fffffd60 {
> +				compatible = "atmel,at91sam9260-gpbr";
> +				reg = <0xfffffd60 0x10>;
> +			};
> +
>  			tcb0: timer at fff7c000 {
>  				compatible = "atmel,at91rm9200-tcb";
>  				reg = <0xfff7c000 0x100>;
> diff --git a/arch/arm/boot/dts/at91sam9n12.dtsi b/arch/arm/boot/dts/at91sam9n12.dtsi
> index 4801717..ac122a6 100644
> --- a/arch/arm/boot/dts/at91sam9n12.dtsi
> +++ b/arch/arm/boot/dts/at91sam9n12.dtsi
> @@ -85,6 +85,11 @@
>  				reg = <0xfffffe10 0x10>;
>  			};
>  
> +			gpbr at fffffe60 {
> +				compatible = "atmel,at91sam9260-gpbr";
> +				reg = <0xfffffe60 0x10>;
> +			};
> +
>  			mmc0: mmc at f0008000 {
>  				compatible = "atmel,hsmci";
>  				reg = <0xf0008000 0x600>;
> diff --git a/arch/arm/boot/dts/at91sam9x5.dtsi b/arch/arm/boot/dts/at91sam9x5.dtsi
> index c461e11..13d069e 100644
> --- a/arch/arm/boot/dts/at91sam9x5.dtsi
> +++ b/arch/arm/boot/dts/at91sam9x5.dtsi
> @@ -88,6 +88,11 @@
>  				interrupts = <1 4 7>;
>  			};
>  
> +			gpbr at fffffe60 {
> +				compatible = "atmel,at91sam9260-gpbr";
> +				reg = <0xfffffe60 0x10>;
> +			};
> +
>  			tcb0: timer at f8008000 {
>  				compatible = "atmel,at91sam9x5-tcb";
>  				reg = <0xf8008000 0x100>;
> diff --git a/arch/arm/mach-at91/setup.c b/arch/arm/mach-at91/setup.c
> index b01f4aa..a525390 100644
> --- a/arch/arm/mach-at91/setup.c
> +++ b/arch/arm/mach-at91/setup.c
> @@ -374,6 +374,26 @@ static void at91_dt_ramc(void)
>  	of_node_put(np);
>  }
>  
> +static struct of_device_id gpbr_ids[] = {
> +	{ .compatible = "atmel,at91sam9260-gpbr", },
> +	{ /* sentinel */ }
> +};
> +
> +static void at91_dt_gpbr(void)
> +{
> +	struct device_node *np;
> +
> +	np = of_find_matching_node(NULL, gpbr_ids);
> +	if (!np)
> +		panic("AT91: failed to find compatible gpbr node in dtb\n");
> +
> +	at91_gpbr_base = of_iomap(np, 0);
> +	if (!at91_gpbr_base)
> +		panic("AT91: Failed to map gpbr registers\n");
> +
> +	of_node_put(np);
> +}

binding ok this NO
no global pointer unless no choice

we need a framework

Best Regards,
J.
> +
>  static struct of_device_id shdwc_ids[] = {
>  	{ .compatible = "atmel,at91sam9260-shdwc", },
>  	{ .compatible = "atmel,at91sam9rl-shdwc", },
> @@ -468,6 +488,7 @@ void __init at91_dt_initialize(void)
>  	at91_dt_rstc();
>  	at91_dt_ramc();
>  	at91_dt_shdwc();
> +	at91_dt_gpbr();
>  
>  	/* Init clock subsystem */
>  	at91_dt_clock_init();
> -- 
> 1.8.1.5
> 


From plagnioj at jcrosoft.com  Mon Apr  8 03:38:07 2013
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Mon, 8 Apr 2013 09:38:07 +0200
Subject: [RFC 4/5] RTC: rtc-at91sam9: add device-tree support
In-Reply-To: <1365347572-14972-4-git-send-email-jhovold@gmail.com>
References: <20130407150938.GA25605@localhost>
 <1365347572-14972-1-git-send-email-jhovold@gmail.com>
 <1365347572-14972-4-git-send-email-jhovold@gmail.com>
Message-ID: <20130408073807.GQ20693@game.jcrosoft.org>

On 17:12 Sun 07 Apr     , Johan Hovold wrote:
> Add device-tree support.
> 
> The AT91 RTT can be used as an RTC if the atmel,at91-rtt-as-rtc-gpbr
> property is present and set to the general-purpose backup register to
> use to store the RTC time base.
> 
> Signed-off-by: Johan Hovold <jhovold at gmail.com>
> ---
>  .../devicetree/bindings/rtc/rtc-at91sam9.txt       | 19 ++++++++++++
>  drivers/rtc/rtc-at91sam9.c                         | 36 +++++++++++++++++++++-
>  2 files changed, 54 insertions(+), 1 deletion(-)
>  create mode 100644 Documentation/devicetree/bindings/rtc/rtc-at91sam9.txt
> 
> diff --git a/Documentation/devicetree/bindings/rtc/rtc-at91sam9.txt b/Documentation/devicetree/bindings/rtc/rtc-at91sam9.txt
> new file mode 100644
> index 0000000..0f54988
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/rtc/rtc-at91sam9.txt
> @@ -0,0 +1,19 @@
> +Atmel AT91 RTT as RTC
> +=====================
> +
> +Required properties:
> +- compatible: Should be "atmel,at91sam9260-rtt"
> +- reg: Should contain register location and length
> +- interrupts: Should contain interrupt for the RTT which is the IRQ line
> +  shared across all System Controller members.
> +- atmel,rtt-as-rtc-gpbr: Should contain the backup-register to use to store
> +  the RTC time base
> +
> +Example:
> +
> +rtt at fffffd20 {
> +		compatible = "atmel,at91sam9g45-rtt", "atmel,at91sam9260-rtt";
> +		reg = <0xfffffd20 0x10>;
> +		interrupts = <1 4 7>;
> +		atmel,at91-rtt-as-rtc-gpbr = <0>;
no you miss the point of the DT

you need to describe the hardware no a particular use of it

the RTT is a general purpose timer backuped that we use in linux as a RTC with a gpbr
to store the time


you need 2 binding on for the RTT one the RTT-rtc
> +	};
> diff --git a/drivers/rtc/rtc-at91sam9.c b/drivers/rtc/rtc-at91sam9.c
> index 983667b..7ccce19 100644
> --- a/drivers/rtc/rtc-at91sam9.c
> +++ b/drivers/rtc/rtc-at91sam9.c
> @@ -13,6 +13,7 @@
>  
>  #include <linux/module.h>
>  #include <linux/kernel.h>
> +#include <linux/of.h>
>  #include <linux/platform_device.h>
>  #include <linux/time.h>
>  #include <linux/rtc.h>
> @@ -282,6 +283,29 @@ static const struct rtc_class_ops at91_rtc_ops = {
>  	.alarm_irq_enable = at91_rtc_alarm_irq_enable,
>  };
>  
> +
> +#ifdef CONFIG_OF
> +static struct of_device_id at91_rtc_of_match[] = {
> +	{ .compatible = "atmel,at91sam9260-rtt", },
> +	{ },
> +};
> +MODULE_DEVICE_TABLE(of, at91_rtc_of_match);
> +#endif
> +
> +static int at91_rtc_parse_dt(struct device_node *node, unsigned *gpbr)
> +{
> +	u32 val;
> +	int res;
> +
> +	res = of_property_read_u32(node, "atmel,at91-rtt-as-rtc-gpbr", &val);
> +	if (!res)
> +		return -ENODEV;
> +
> +	*gpbr = val;
> +
> +	return 0;
> +}
> +
>  /*
>   * Initialize and install RTC driver
>   */
> @@ -291,6 +315,15 @@ static int at91_rtc_probe(struct platform_device *pdev)
>  	struct sam9_rtc	*rtc;
>  	int		ret, irq;
>  	u32		mr;
> +	unsigned	gpbr;
> +
> +	if (pdev->dev.of_node) {
> +		ret = at91_rtc_parse_dt(pdev->dev.of_node, &gpbr);
> +		if (ret)
> +			return ret;
> +	} else {
> +		gpbr = CONFIG_RTC_DRV_AT91SAM9_GPBR;
> +	}
>  
>  	r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>  	if (!r)
> @@ -320,7 +353,7 @@ static int at91_rtc_probe(struct platform_device *pdev)
>  		goto fail;
>  	}
>  
> -	rtc->gpbr = CONFIG_RTC_DRV_AT91SAM9_GPBR;
> +	rtc->gpbr = gpbr;
>  
>  	mr = rtt_readl(rtc, MR);
>  
> @@ -455,6 +488,7 @@ static struct platform_driver at91_rtc_driver = {
>  	.driver		= {
>  		.name	= "rtc-at91sam9",
>  		.owner	= THIS_MODULE,
> +		.of_match_table = of_match_ptr(at91_rtc_of_match),
>  	},
>  };
>  
> -- 
> 1.8.1.5
> 


From plagnioj at jcrosoft.com  Mon Apr  8 03:57:42 2013
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Mon, 8 Apr 2013 09:57:42 +0200
Subject: [PATCH v3 2/2] video: imxfb: Add DT support
In-Reply-To: <1365157876-1757-3-git-send-email-mpa@pengutronix.de>
References: <1365157876-1757-1-git-send-email-mpa@pengutronix.de>
 <1365157876-1757-3-git-send-email-mpa@pengutronix.de>
Message-ID: <20130408075742.GR20693@game.jcrosoft.org>

On 12:31 Fri 05 Apr     , Markus Pargmann wrote:
> Add devicetree support for imx framebuffer driver. It uses the generic
> display bindings and helper functions.
> 
> Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
> Cc: Fabio Estevam <festevam at gmail.com>
> Cc: Mark Rutland <mark.rutland at arm.com>
> ---
>  .../devicetree/bindings/video/fsl,imx-fb.txt       |  49 ++++++
>  drivers/video/imxfb.c                              | 192 +++++++++++++++++----
>  2 files changed, 207 insertions(+), 34 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/video/fsl,imx-fb.txt
> 
> diff --git a/Documentation/devicetree/bindings/video/fsl,imx-fb.txt b/Documentation/devicetree/bindings/video/fsl,imx-fb.txt
> new file mode 100644
> index 0000000..bde9c77
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/fsl,imx-fb.txt
> @@ -0,0 +1,49 @@
> +Freescale imx21 Framebuffer
> +
> +This framebuffer driver supports devices imx1, imx21, imx25, and imx27.
> +
> +Required properties:
> +- compatible : "fsl,<chip>-fb", chip should be imx1 or imx21
> +- reg : Should contain 1 register ranges(address and length)
> +- interrupts : One interrupt of the fb dev
> +
> +Required nodes:
> +- display: Phandle to a display node as described in
> +	Documentation/devicetree/bindings/video/display-timing.txt
> +	Additional, the display node has to define properties:
> +	- fsl,bpp: Bits per pixel
> +	- fsl,pcr: LCDC PCR value
> +
> +Optional properties:
> +- dmacr-eukrea: Should be set for eukrea boards.
why ?

and This should be prefix by yhe Vendor here Eukrea
> +
> +Example:
> +
> +	imxfb: fb at 10021000 {
> +		compatible = "fsl,imx27-fb", "fsl,imx21-fb";
> +		interrupts = <61>;
> +		reg = <0x10021000 0x1000>;
> +		display = <&display0>;
> +	};
> +
> +	...
> +
> +	display0: display0 {
> +		model = "Primeview-PD050VL1";
> +		native-mode = <&timing_disp0>;
> +		fsl,bpp = <16>;		/* non-standard but required */
> +		fsl,pcr = <0xf0c88080>;	/* non-standard but required */
> +		display-timings {
> +			timing_disp0: 640x480 {
> +				hactive = <640>;
> +				vactive = <480>;
> +				hback-porch = <112>;
> +				hfront-porch = <36>;
> +				hsync-len = <32>;
> +				vback-porch = <33>;
> +				vfront-porch = <33>;
> +				vsync-len = <2>;
> +				clock-frequency = <25000000>;
> +			};
> +		};
> +	};
> diff --git a/drivers/video/imxfb.c b/drivers/video/imxfb.c
> index ef2b587..5a9bc598 100644
> --- a/drivers/video/imxfb.c
> +++ b/drivers/video/imxfb.c
> @@ -32,6 +32,12 @@
>  #include <linux/io.h>
>  #include <linux/math64.h>
>  #include <linux/uaccess.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>
> +
> +#include <video/of_display_timing.h>
> +#include <video/of_videomode.h>
> +#include <video/videomode.h>
>  
>  #include <linux/platform_data/video-imxfb.h>
>  
> @@ -117,10 +123,13 @@
>  #define LGWCR_GWAV(alpha)	(((alpha) & 0xff) << 24)
>  #define LGWCR_GWE	(1 << 22)
>  
> +#define IMXFB_LSCR1_DEFAULT 0x00120300
> +#define IMXFB_DMACR_DEFAULT 0x00020010
> +#define IMXFB_DMACR_EUKREA_DEFAULT 0x00040060
> +
>  /* Used fb-mode. Can be set on kernel command line, therefore file-static. */
>  static const char *fb_mode;
>  
> -
>  /*
>   * These are the bitfields for each
>   * display depth that we support.
> @@ -192,6 +201,19 @@ static struct platform_device_id imxfb_devtype[] = {
>  };
>  MODULE_DEVICE_TABLE(platform, imxfb_devtype);
>  
> +static struct of_device_id imxfb_of_dev_id[] = {
> +	{
> +		.compatible = "fsl,imx1-fb",
> +		.data = &imxfb_devtype[IMX1_FB],
> +	}, {
> +		.compatible = "fsl,imx21-fb",
> +		.data = &imxfb_devtype[IMX21_FB],
> +	}, {
> +		/* sentinel */
> +	}
> +};
> +MODULE_DEVICE_TABLE(of, imxfb_of_dev_id);
> +
>  static inline int is_imx1_fb(struct imxfb_info *fbi)
>  {
>  	return fbi->devtype == IMX1_FB;
> @@ -324,6 +346,9 @@ static const struct imx_fb_videomode *imxfb_find_mode(struct imxfb_info *fbi)
>  	struct imx_fb_videomode *m;
>  	int i;
>  
> +	if (!fb_mode)
> +		return &fbi->mode[0];
> +
>  	for (i = 0, m = &fbi->mode[0]; i < fbi->num_modes; i++, m++) {
>  		if (!strcmp(m->mode.name, fb_mode))
>  			return m;
> @@ -479,6 +504,9 @@ static int imxfb_bl_update_status(struct backlight_device *bl)
>  	struct imxfb_info *fbi = bl_get_data(bl);
>  	int brightness = bl->props.brightness;
>  
> +	if (!fbi->pwmr)
> +		return 0;
> +
>  	if (bl->props.power != FB_BLANK_UNBLANK)
>  		brightness = 0;
>  	if (bl->props.fb_blank != FB_BLANK_UNBLANK)
> @@ -719,7 +747,8 @@ static int imxfb_activate_var(struct fb_var_screeninfo *var, struct fb_info *inf
>  
>  	writel(fbi->pcr, fbi->regs + LCDC_PCR);
>  #ifndef PWMR_BACKLIGHT_AVAILABLE
> -	writel(fbi->pwmr, fbi->regs + LCDC_PWMR);
> +	if (fbi->pwmr)
> +		writel(fbi->pwmr, fbi->regs + LCDC_PWMR);
>  #endif
>  	writel(fbi->lscr1, fbi->regs + LCDC_LSCR1);
>  	writel(fbi->dmacr, fbi->regs + LCDC_DMACR);
> @@ -758,13 +787,12 @@ static int imxfb_resume(struct platform_device *dev)
>  #define imxfb_resume	NULL
>  #endif
>  
> -static int __init imxfb_init_fbinfo(struct platform_device *pdev)
> +static int imxfb_init_fbinfo(struct platform_device *pdev)
>  {
>  	struct imx_fb_platform_data *pdata = pdev->dev.platform_data;
>  	struct fb_info *info = dev_get_drvdata(&pdev->dev);
>  	struct imxfb_info *fbi = info->par;
> -	struct imx_fb_videomode *m;
> -	int i;
> +	struct device_node *np;
>  
>  	pr_debug("%s\n",__func__);
>  
> @@ -795,41 +823,96 @@ static int __init imxfb_init_fbinfo(struct platform_device *pdev)
>  	info->fbops			= &imxfb_ops;
>  	info->flags			= FBINFO_FLAG_DEFAULT |
>  					  FBINFO_READS_FAST;
> -	info->var.grayscale		= pdata->cmap_greyscale;
> -	fbi->cmap_inverse		= pdata->cmap_inverse;
> -	fbi->cmap_static		= pdata->cmap_static;
> -	fbi->lscr1			= pdata->lscr1;
> -	fbi->dmacr			= pdata->dmacr;
> -	fbi->pwmr			= pdata->pwmr;
> -	fbi->lcd_power			= pdata->lcd_power;
> -	fbi->backlight_power		= pdata->backlight_power;
> -
> -	for (i = 0, m = &pdata->mode[0]; i < pdata->num_modes; i++, m++)
> -		info->fix.smem_len = max_t(size_t, info->fix.smem_len,
> -				m->mode.xres * m->mode.yres * m->bpp / 8);
> +	if (pdata) {
> +		info->var.grayscale		= pdata->cmap_greyscale;
> +		fbi->cmap_inverse		= pdata->cmap_inverse;
> +		fbi->cmap_static		= pdata->cmap_static;
> +		fbi->lscr1			= pdata->lscr1;
> +		fbi->dmacr			= pdata->dmacr;
> +		fbi->pwmr			= pdata->pwmr;
> +		fbi->lcd_power			= pdata->lcd_power;
> +		fbi->backlight_power		= pdata->backlight_power;
> +	} else {
> +		np = pdev->dev.of_node;
> +		info->var.grayscale = of_property_read_bool(np,
> +						"cmap-greyscale");
> +		fbi->cmap_inverse = of_property_read_bool(np, "cmap-inverse");
> +		fbi->cmap_static = of_property_read_bool(np, "cmap-static");
> +
> +		fbi->lscr1 = IMXFB_LSCR1_DEFAULT;
> +		if (of_property_read_bool(np, "dmacr-eukrea"))
> +			fbi->dmacr = IMXFB_DMACR_EUKREA_DEFAULT;
> +		else
> +			fbi->dmacr = IMXFB_DMACR_DEFAULT;
> +
> +		/* These two function pointers could be used by some specific
> +		 * platforms. */
> +		fbi->lcd_power = NULL;
> +		fbi->backlight_power = NULL;
> +	}
> +
> +	return 0;
> +}
> +
> +static int imxfb_of_read_mode(struct device *dev, struct device_node *np,
> +		struct imx_fb_videomode *imxfb_mode)
> +{
> +	int ret;
> +	struct fb_videomode *of_mode = &imxfb_mode->mode;
> +	u32 bpp;
> +	u32 pcr;
> +
> +	ret = of_property_read_string(np, "model", &of_mode->name);
> +	if (ret)
> +		of_mode->name = NULL;
> +
> +	ret = of_get_fb_videomode(np, of_mode, OF_USE_NATIVE_MODE);
> +	if (ret) {
> +		dev_err(dev, "Failed to get videomode from DT\n");
> +		return ret;
> +	}
> +
> +	ret = of_property_read_u32(np, "fsl,bpp", &bpp);
> +	ret |= of_property_read_u32(np, "fsl,pcr", &pcr);
> +
> +	if (ret) {
> +		dev_err(dev, "Failed to read bpp and pcr from DT\n");
> +		return -EINVAL;
> +	}
> +
> +	if (bpp < 1 || bpp > 255) {
> +		dev_err(dev, "Bits per pixel have to be between 1 and 255\n");
> +		return -EINVAL;
> +	}
> +
> +	imxfb_mode->bpp = bpp;
> +	imxfb_mode->pcr = pcr;
>  
>  	return 0;
>  }
>  
> -static int __init imxfb_probe(struct platform_device *pdev)
> +static int imxfb_probe(struct platform_device *pdev)
>  {
>  	struct imxfb_info *fbi;
>  	struct fb_info *info;
>  	struct imx_fb_platform_data *pdata;
>  	struct resource *res;
> +	struct imx_fb_videomode *m;
> +	const struct of_device_id *of_id;
>  	int ret, i;
> +	int bytes_per_pixel;
>  
>  	dev_info(&pdev->dev, "i.MX Framebuffer driver\n");
>  
> +	of_id = of_match_device(imxfb_of_dev_id, &pdev->dev);
> +	if (of_id)
> +		pdev->id_entry = of_id->data;
> +
>  	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>  	if (!res)
>  		return -ENODEV;
>  
>  	pdata = pdev->dev.platform_data;
> -	if (!pdata) {
> -		dev_err(&pdev->dev,"No platform_data available\n");
> -		return -ENOMEM;
> -	}
>  
>  	info = framebuffer_alloc(sizeof(struct imxfb_info), &pdev->dev);
>  	if (!info)
> @@ -837,15 +920,55 @@ static int __init imxfb_probe(struct platform_device *pdev)
>  
>  	fbi = info->par;
>  
> -	if (!fb_mode)
> -		fb_mode = pdata->mode[0].mode.name;
> -
>  	platform_set_drvdata(pdev, info);
>  
>  	ret = imxfb_init_fbinfo(pdev);
>  	if (ret < 0)
>  		goto failed_init;
>  
> +	if (pdata) {
> +		if (!fb_mode)
> +			fb_mode = pdata->mode[0].mode.name;
> +
> +		fbi->mode = pdata->mode;
> +		fbi->num_modes = pdata->num_modes;
> +	} else {
> +		struct device_node *display_np;
> +		fb_mode = NULL;
> +
> +		display_np = of_parse_phandle(pdev->dev.of_node, "display", 0);
> +		if (!display_np) {
> +			dev_err(&pdev->dev, "No display defined in devicetree\n");
> +			ret = -EINVAL;
> +			goto failed_of_parse;
> +		}
> +
> +		/*
> +		 * imxfb does not support more modes, we choose only the native
> +		 * mode.
> +		 */
> +		fbi->num_modes = 1;
> +
> +		fbi->mode = devm_kzalloc(&pdev->dev,
> +				sizeof(struct imx_fb_videomode), GFP_KERNEL);
> +		if (!fbi->mode) {
> +			ret = -ENOMEM;
> +			goto failed_of_parse;
> +		}
> +
> +		ret = imxfb_of_read_mode(&pdev->dev, display_np, fbi->mode);
> +		if (ret)
> +			goto failed_of_parse;
> +	}
> +
> +	/* Calculate maximum bytes used per pixel. In most cases this should
> +	 * be the same as m->bpp/8 */
> +	m = &fbi->mode[0];
> +	bytes_per_pixel = (m->bpp + 7) / 8;
> +	for (i = 0; i < fbi->num_modes; i++, m++)
> +		info->fix.smem_len = max_t(size_t, info->fix.smem_len,
> +				m->mode.xres * m->mode.yres * bytes_per_pixel);
> +
>  	res = request_mem_region(res->start, resource_size(res),
>  				DRIVER_NAME);
>  	if (!res) {
> @@ -878,7 +1001,8 @@ static int __init imxfb_probe(struct platform_device *pdev)
>  		goto failed_ioremap;
>  	}
>  
> -	if (!pdata->fixed_screen_cpu) {
> +	/* Seems not being used by anyone, so no support for oftree */
> +	if (!pdata || !pdata->fixed_screen_cpu) {
>  		fbi->map_size = PAGE_ALIGN(info->fix.smem_len);
>  		fbi->map_cpu = dma_alloc_writecombine(&pdev->dev,
>  				fbi->map_size, &fbi->map_dma, GFP_KERNEL);
> @@ -903,18 +1027,16 @@ static int __init imxfb_probe(struct platform_device *pdev)
>  		info->fix.smem_start = fbi->screen_dma;
>  	}
>  
> -	if (pdata->init) {
> +	if (pdata && pdata->init) {
>  		ret = pdata->init(fbi->pdev);
>  		if (ret)
>  			goto failed_platform_init;
>  	}
>  
> -	fbi->mode = pdata->mode;
> -	fbi->num_modes = pdata->num_modes;
>  
>  	INIT_LIST_HEAD(&info->modelist);
> -	for (i = 0; i < pdata->num_modes; i++)
> -		fb_add_videomode(&pdata->mode[i].mode, &info->modelist);
> +	for (i = 0; i < fbi->num_modes; i++)
> +		fb_add_videomode(&fbi->mode[i].mode, &info->modelist);
>  
>  	/*
>  	 * This makes sure that our colour bitfield
> @@ -944,10 +1066,10 @@ static int __init imxfb_probe(struct platform_device *pdev)
>  failed_register:
>  	fb_dealloc_cmap(&info->cmap);
>  failed_cmap:
> -	if (pdata->exit)
> +	if (pdata && pdata->exit)
>  		pdata->exit(fbi->pdev);
>  failed_platform_init:
> -	if (!pdata->fixed_screen_cpu)
> +	if (pdata && !pdata->fixed_screen_cpu)
>  		dma_free_writecombine(&pdev->dev,fbi->map_size,fbi->map_cpu,
>  			fbi->map_dma);
>  failed_map:
> @@ -956,6 +1078,7 @@ failed_ioremap:
>  failed_getclock:
>  	release_mem_region(res->start, resource_size(res));
>  failed_req:
> +failed_of_parse:
>  	kfree(info->pseudo_palette);
>  failed_init:
>  	platform_set_drvdata(pdev, NULL);
> @@ -980,7 +1103,7 @@ static int imxfb_remove(struct platform_device *pdev)
>  	unregister_framebuffer(info);
>  
>  	pdata = pdev->dev.platform_data;
> -	if (pdata->exit)
> +	if (pdata && pdata->exit)
>  		pdata->exit(fbi->pdev);
>  
>  	fb_dealloc_cmap(&info->cmap);
> @@ -1009,6 +1132,7 @@ static struct platform_driver imxfb_driver = {
>  	.shutdown	= imxfb_shutdown,
>  	.driver		= {
>  		.name	= DRIVER_NAME,
> +		.of_match_table = imxfb_of_dev_id,
>  	},
>  	.id_table	= imxfb_devtype,
>  };
> -- 
> 1.8.1.5
> 
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss


From nsekhar at ti.com  Mon Apr  8 04:08:14 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Mon, 8 Apr 2013 13:38:14 +0530
Subject: [PATCH v9 0/6] ARM: davinci: remoteproc support
In-Reply-To: <CAK=WgbYW4=1GyBGOHyR1vFaPHjhGdAP493+Jh4mSQSOeX7uJjw@mail.gmail.com>
References: <1364521307-1219-1-git-send-email-rtivy@ti.com>
 <CAK=WgbYW4=1GyBGOHyR1vFaPHjhGdAP493+Jh4mSQSOeX7uJjw@mail.gmail.com>
Message-ID: <51627AEE.4090804@ti.com>

On 4/7/2013 6:37 PM, Ohad Ben-Cohen wrote:
> Hi Rob,
> 
> On Fri, Mar 29, 2013 at 4:41 AM, Robert Tivy <rtivy at ti.com> wrote:
>> This patch series adds remoteproc support for OMAP-L13x, along with needed
>> supporting mach-davinci infrastructure.
> 
> Patches look good, thanks for pushing.
> 
> I'm applying 2 and 3 now. Please ack the change I've done for 1 and
> I'll apply it too. No. 4 just needs a small change, if you could
> please respin quickly I'll apply it immediately.
> 
> I prefer patches 5 and 6 go through Sekhar, guess after I'll have no.
> 4 applied in an immutable branch Sekhar could pull it and apply 5 and
> 6.

That should be fine. Please let me know once you have the immutable branch.

Thanks,
Sekhar


From g.liakhovetski at gmx.de  Mon Apr  8 04:08:40 2013
From: g.liakhovetski at gmx.de (Guennadi Liakhovetski)
Date: Mon, 8 Apr 2013 10:08:40 +0200 (CEST)
Subject: [PATCH v3] irqchip: renesas-intc-irqpin: DT binding for sense bitfield
 width
Message-ID: <Pine.LNX.4.64.1304081002190.29945@axis700.grange>

Most Renesas irqpin controllers have 4-bit sense fields, however, some
have different widths. This patch adds a DT binding to optionally
specify such non-standard values.

Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas at gmail.com>
---

v3: move the code to a common location, where device configuration 
parameters are retrieved

 .../interrupt-controller/renesas,intc-irqpin.txt   |   13 +++++++++++++
 drivers/irqchip/irq-renesas-intc-irqpin.c          |    4 ++++
 2 files changed, 17 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.txt

diff --git a/Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.txt b/Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.txt
new file mode 100644
index 0000000..c6f09b7
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.txt
@@ -0,0 +1,13 @@
+DT bindings for the R-/SH-Mobile irqpin controller
+
+Required properties:
+
+- compatible: has to be "renesas,intc-irqpin"
+- #interrupt-cells: has to be <2>
+
+Optional properties:
+
+- any properties, listed in interrupts.txt in this directory, and any standard
+  resource allocation properties
+- sense-bitfield-width: width of a single sense bitfield in the SENSE register,
+  if different from the default 4 bits
diff --git a/drivers/irqchip/irq-renesas-intc-irqpin.c b/drivers/irqchip/irq-renesas-intc-irqpin.c
index 5a68e5a..4aca1b2 100644
--- a/drivers/irqchip/irq-renesas-intc-irqpin.c
+++ b/drivers/irqchip/irq-renesas-intc-irqpin.c
@@ -18,6 +18,7 @@
  */
 
 #include <linux/init.h>
+#include <linux/of.h>
 #include <linux/platform_device.h>
 #include <linux/spinlock.h>
 #include <linux/interrupt.h>
@@ -349,6 +350,9 @@ static int intc_irqpin_probe(struct platform_device *pdev)
 	/* deal with driver instance configuration */
 	if (pdata)
 		memcpy(&p->config, pdata, sizeof(*pdata));
+	else
+		of_property_read_u32(pdev->dev.of_node, "sense-bitfield-width",
+				     &p->config.sense_bitfield_width);
 	if (!p->config.sense_bitfield_width)
 		p->config.sense_bitfield_width = 4; /* default to 4 bits */
 
-- 
1.7.2.5



From amit.daniel at samsung.com  Mon Apr  8 04:17:34 2013
From: amit.daniel at samsung.com (Amit Daniel Kachhap)
Date: Mon,  8 Apr 2013 13:47:34 +0530
Subject: [PATCH V6 0/4] cpufreq: exynos5440: support for cpufreq driver
Message-ID: <1365409058-32643-1-git-send-email-amit.daniel@samsung.com>

Submitting the V6 version of exynos5440 cpufreq driver. This patchset addresses
all the coding and design concerns raised especially by Viresh.

Changes in V6:
* Used cpufreq post-change notifier call back in case of failure as pointed by
  Viresh.
* Called cpufreq_frequency_table_cpuinfo before calling
  cpufreq_frequency_table_get_attr as pointed by Viresh.
* Used modified API cpufreq_notify_transition.

Changes in V5:
* Removed the unnecessary DT look up entry from mach-exynos5-dt.c.
* Fixed all coding and comments issue raised by Viresh.

Changes in V4:
* Added dev_err logs instead of pr_err.
* Used the devm_ioremap_resource API.
* Implemented several coding guidelines and minor error comments from Sylwester,
  Russell and Viresh.

Changes in V3:
* Converted the driver to probe based as suggested by Viresh. This is also
  beneficial for multiplatform kernel.
* Other coding guidelines related changes.
* Moved the DT node outside cpu0 node as the driver is now a platform
  driver.

Changes in V2:
* Added OPP library support to parse DT parameters.
* Removed a hack to handle interrupts in bootup.
* Implemented other review comments from Viresh and Inder.

All these patches are dependent on Thomas Abraham common clock patches.
(http://www.mail-archive.com/linux-samsung-soc at vger.kernel.org/msg15860.html)
This whole patch series is based on Rafael tree.
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git bleeding-edge

Amit Daniel Kachhap (4):
  cpufreq: exynos: Add cpufreq driver for exynos5440
  cpufreq: exynos: Remove error return even if no soc is found
  arm: exynos: Enable OPP library support for exynos5440
  arm: dts: Add cpufreq controller node for Exynos5440 SoC

 .../bindings/cpufreq/cpufreq-exynos5440.txt        |   28 ++
 arch/arm/boot/dts/exynos5440.dtsi                  |   12 +
 arch/arm/mach-exynos/Kconfig                       |    2 +
 drivers/cpufreq/Kconfig.arm                        |    9 +
 drivers/cpufreq/Makefile                           |    1 +
 drivers/cpufreq/exynos-cpufreq.c                   |    2 +-
 drivers/cpufreq/exynos5440-cpufreq.c               |  479 ++++++++++++++++++++
 7 files changed, 532 insertions(+), 1 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt
 create mode 100644 drivers/cpufreq/exynos5440-cpufreq.c



From amit.daniel at samsung.com  Mon Apr  8 04:17:35 2013
From: amit.daniel at samsung.com (Amit Daniel Kachhap)
Date: Mon,  8 Apr 2013 13:47:35 +0530
Subject: [PATCH V6 1/4] cpufreq: exynos: Add cpufreq driver for exynos5440
In-Reply-To: <1365409058-32643-1-git-send-email-amit.daniel@samsung.com>
References: <1365409058-32643-1-git-send-email-amit.daniel@samsung.com>
Message-ID: <1365409058-32643-2-git-send-email-amit.daniel@samsung.com>

This patch adds dvfs support for exynos5440 SOC. This soc has 4 cores and
they scale at same frequency. The nature of exynos5440 clock controller is
different from previous exynos controllers so not using the common exynos
cpufreq framework. The major difference being interrupt notification for
frequency change. Also, OPP library is used for device tree parsing to get
different parameters like frequency, voltage etc. Since the opp library sorts
the frequency table in ascending order so they are again re-arranged in
descending order. This will have one-to-one mapping with the clock controller
state management logic.

Cc: Viresh Kumar <viresh.kumar at linaro.org>
Cc: Rafael J. Wysocki <rjw at sisk.pl>
Cc: Kukjin Kim <kgene.kim at samsung.com>
Signed-off-by: Amit Daniel Kachhap <amit.daniel at samsung.com>
---
 .../bindings/cpufreq/cpufreq-exynos5440.txt        |   28 ++
 drivers/cpufreq/Kconfig.arm                        |    9 +
 drivers/cpufreq/Makefile                           |    1 +
 drivers/cpufreq/exynos5440-cpufreq.c               |  479 ++++++++++++++++++++
 4 files changed, 517 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt
 create mode 100644 drivers/cpufreq/exynos5440-cpufreq.c

diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt b/Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt
new file mode 100644
index 0000000..caff1a5
--- /dev/null
+++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt
@@ -0,0 +1,28 @@
+
+Exynos5440 cpufreq driver
+-------------------
+
+Exynos5440 SoC cpufreq driver for CPU frequency scaling.
+
+Required properties:
+- interrupts: Interrupt to know the completion of cpu frequency change.
+- operating-points: Table of frequencies and voltage CPU could be transitioned into,
+	in the decreasing order. Frequency should be in KHz units and voltage
+	should be in microvolts.
+
+Optional properties:
+- clock-latency: Clock monitor latency in microsecond.
+
+All the required listed above must be defined under node cpufreq.
+
+Example:
+--------
+	cpufreq at 160000 {
+		compatible = "samsung,exynos5440-cpufreq";
+		reg = <0x160000 0x1000>;
+		interrupts = <0 57 0>;
+		operating-points = <
+				1000000 975000
+				800000  925000>;
+		clock-latency = <100000>;
+	};
diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index f3f3b14..bce2195 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -42,6 +42,15 @@ config ARM_EXYNOS5250_CPUFREQ
 	  This adds the CPUFreq driver for Samsung EXYNOS5250
 	  SoC.
 
+config ARM_EXYNOS5440_CPUFREQ
+	def_bool SOC_EXYNOS5440
+	depends on HAVE_CLK && PM_OPP && OF
+	help
+	  This adds the CPUFreq driver for Samsung EXYNOS5440
+	  SoC. The nature of exynos5440 clock controller is
+	  different than previous exynos controllers so not using
+	  the common exynos framework.
+
 config ARM_HIGHBANK_CPUFREQ
 	tristate "Calxeda Highbank-based"
 	depends on ARCH_HIGHBANK
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index 5db1f1f..6ad0b91 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -56,6 +56,7 @@ obj-$(CONFIG_ARM_EXYNOS_CPUFREQ)	+= exynos-cpufreq.o
 obj-$(CONFIG_ARM_EXYNOS4210_CPUFREQ)	+= exynos4210-cpufreq.o
 obj-$(CONFIG_ARM_EXYNOS4X12_CPUFREQ)	+= exynos4x12-cpufreq.o
 obj-$(CONFIG_ARM_EXYNOS5250_CPUFREQ)	+= exynos5250-cpufreq.o
+obj-$(CONFIG_ARM_EXYNOS5440_CPUFREQ)	+= exynos5440-cpufreq.o
 obj-$(CONFIG_ARM_HIGHBANK_CPUFREQ)	+= highbank-cpufreq.o
 obj-$(CONFIG_ARM_IMX6Q_CPUFREQ)		+= imx6q-cpufreq.o
 obj-$(CONFIG_ARM_INTEGRATOR)		+= integrator-cpufreq.o
diff --git a/drivers/cpufreq/exynos5440-cpufreq.c b/drivers/cpufreq/exynos5440-cpufreq.c
new file mode 100644
index 0000000..9c37825
--- /dev/null
+++ b/drivers/cpufreq/exynos5440-cpufreq.c
@@ -0,0 +1,479 @@
+/*
+ * Copyright (c) 2013 Samsung Electronics Co., Ltd.
+ *		http://www.samsung.com
+ *
+ * Amit Daniel Kachhap <amit.daniel at samsung.com>
+ *
+ * EXYNOS5440 - CPU frequency scaling support
+ *
+ * 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/clk.h>
+#include <linux/cpu.h>
+#include <linux/cpufreq.h>
+#include <linux/err.h>
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+#include <linux/opp.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+
+/* Register definitions */
+#define XMU_DVFS_CTRL		0x0060
+#define XMU_PMU_P0_7		0x0064
+#define XMU_C0_3_PSTATE		0x0090
+#define XMU_P_LIMIT		0x00a0
+#define XMU_P_STATUS		0x00a4
+#define XMU_PMUEVTEN		0x00d0
+#define XMU_PMUIRQEN		0x00d4
+#define XMU_PMUIRQ		0x00d8
+
+/* PMU mask and shift definations */
+#define P_VALUE_MASK		0x7
+
+#define XMU_DVFS_CTRL_EN_SHIFT	0
+
+#define P0_7_CPUCLKDEV_SHIFT	21
+#define P0_7_CPUCLKDEV_MASK	0x7
+#define P0_7_ATBCLKDEV_SHIFT	18
+#define P0_7_ATBCLKDEV_MASK	0x7
+#define P0_7_CSCLKDEV_SHIFT	15
+#define P0_7_CSCLKDEV_MASK	0x7
+#define P0_7_CPUEMA_SHIFT	28
+#define P0_7_CPUEMA_MASK	0xf
+#define P0_7_L2EMA_SHIFT	24
+#define P0_7_L2EMA_MASK		0xf
+#define P0_7_VDD_SHIFT		8
+#define P0_7_VDD_MASK		0x7f
+#define P0_7_FREQ_SHIFT		0
+#define P0_7_FREQ_MASK		0xff
+
+#define C0_3_PSTATE_VALID_SHIFT	8
+#define C0_3_PSTATE_CURR_SHIFT	4
+#define C0_3_PSTATE_NEW_SHIFT	0
+
+#define PSTATE_CHANGED_EVTEN_SHIFT	0
+
+#define PSTATE_CHANGED_IRQEN_SHIFT	0
+
+#define PSTATE_CHANGED_SHIFT		0
+
+/* some constant values for clock divider calculation */
+#define CPU_DIV_FREQ_MAX	500
+#define CPU_DBG_FREQ_MAX	375
+#define CPU_ATB_FREQ_MAX	500
+
+#define PMIC_LOW_VOLT		0x30
+#define PMIC_HIGH_VOLT		0x28
+
+#define CPUEMA_HIGH		0x2
+#define CPUEMA_MID		0x4
+#define CPUEMA_LOW		0x7
+
+#define L2EMA_HIGH		0x1
+#define L2EMA_MID		0x3
+#define L2EMA_LOW		0x4
+
+#define DIV_TAB_MAX	2
+/* frequency unit is 20MHZ */
+#define FREQ_UNIT	20
+#define MAX_VOLTAGE	1550000 /* In microvolt */
+#define VOLTAGE_STEP	12500	/* In microvolt */
+
+#define CPUFREQ_NAME		"exynos5440_dvfs"
+#define DEF_TRANS_LATENCY	100000
+
+enum cpufreq_level_index {
+	L0, L1, L2, L3, L4,
+	L5, L6, L7, L8, L9,
+};
+#define CPUFREQ_LEVEL_END	(L7 + 1)
+
+struct exynos_dvfs_data {
+	void __iomem *base;
+	struct resource *mem;
+	int irq;
+	struct clk *cpu_clk;
+	unsigned int cur_frequency;
+	unsigned int latency;
+	struct cpufreq_frequency_table *freq_table;
+	unsigned int freq_count;
+	struct device *dev;
+	bool dvfs_enabled;
+	struct work_struct irq_work;
+};
+
+static struct exynos_dvfs_data *dvfs_info;
+static DEFINE_MUTEX(cpufreq_lock);
+static struct cpufreq_freqs freqs;
+
+static int init_div_table(void)
+{
+	struct cpufreq_frequency_table *freq_tbl = dvfs_info->freq_table;
+	unsigned int tmp, clk_div, ema_div, freq, volt_id;
+	int i = 0;
+	struct opp *opp;
+
+	for (i = 0; freq_tbl[i].frequency != CPUFREQ_TABLE_END; i++) {
+
+		opp = opp_find_freq_exact(dvfs_info->dev,
+					freq_tbl[i].frequency * 1000, true);
+		if (IS_ERR(opp)) {
+			dev_err(dvfs_info->dev,
+				"failed to find valid OPP for %u KHZ\n",
+				freq_tbl[i].frequency);
+			return PTR_ERR(opp);
+		}
+
+		freq = freq_tbl[i].frequency / 1000; /* In MHZ */
+		clk_div = ((freq / CPU_DIV_FREQ_MAX) & P0_7_CPUCLKDEV_MASK)
+					<< P0_7_CPUCLKDEV_SHIFT;
+		clk_div |= ((freq / CPU_ATB_FREQ_MAX) & P0_7_ATBCLKDEV_MASK)
+					<< P0_7_ATBCLKDEV_SHIFT;
+		clk_div |= ((freq / CPU_DBG_FREQ_MAX) & P0_7_CSCLKDEV_MASK)
+					<< P0_7_CSCLKDEV_SHIFT;
+
+		/* Calculate EMA */
+		volt_id = opp_get_voltage(opp);
+		volt_id = (MAX_VOLTAGE - volt_id) / VOLTAGE_STEP;
+		if (volt_id < PMIC_HIGH_VOLT) {
+			ema_div = (CPUEMA_HIGH << P0_7_CPUEMA_SHIFT) |
+				(L2EMA_HIGH << P0_7_L2EMA_SHIFT);
+		} else if (volt_id > PMIC_LOW_VOLT) {
+			ema_div = (CPUEMA_LOW << P0_7_CPUEMA_SHIFT) |
+				(L2EMA_LOW << P0_7_L2EMA_SHIFT);
+		} else {
+			ema_div = (CPUEMA_MID << P0_7_CPUEMA_SHIFT) |
+				(L2EMA_MID << P0_7_L2EMA_SHIFT);
+		}
+
+		tmp = (clk_div | ema_div | (volt_id << P0_7_VDD_SHIFT)
+			| ((freq / FREQ_UNIT) << P0_7_FREQ_SHIFT));
+
+		__raw_writel(tmp, dvfs_info->base + XMU_PMU_P0_7 + 4 * i);
+	}
+
+	return 0;
+}
+
+static void exynos_enable_dvfs(void)
+{
+	unsigned int tmp, i, cpu;
+	struct cpufreq_frequency_table *freq_table = dvfs_info->freq_table;
+	/* Disable DVFS */
+	__raw_writel(0,	dvfs_info->base + XMU_DVFS_CTRL);
+
+	/* Enable PSTATE Change Event */
+	tmp = __raw_readl(dvfs_info->base + XMU_PMUEVTEN);
+	tmp |= (1 << PSTATE_CHANGED_EVTEN_SHIFT);
+	 __raw_writel(tmp, dvfs_info->base + XMU_PMUEVTEN);
+
+	/* Enable PSTATE Change IRQ */
+	tmp = __raw_readl(dvfs_info->base + XMU_PMUIRQEN);
+	tmp |= (1 << PSTATE_CHANGED_IRQEN_SHIFT);
+	 __raw_writel(tmp, dvfs_info->base + XMU_PMUIRQEN);
+
+	/* Set initial performance index */
+	for (i = 0; freq_table[i].frequency != CPUFREQ_TABLE_END; i++)
+		if (freq_table[i].frequency == dvfs_info->cur_frequency)
+			break;
+
+	if (freq_table[i].frequency == CPUFREQ_TABLE_END) {
+		dev_crit(dvfs_info->dev, "Boot up frequency not supported\n");
+		/* Assign the highest frequency */
+		i = 0;
+		dvfs_info->cur_frequency = freq_table[i].frequency;
+	}
+
+	dev_info(dvfs_info->dev, "Setting dvfs initial frequency = %uKHZ",
+						dvfs_info->cur_frequency);
+
+	for (cpu = 0; cpu < CONFIG_NR_CPUS; cpu++) {
+		tmp = __raw_readl(dvfs_info->base + XMU_C0_3_PSTATE + cpu * 4);
+		tmp &= ~(P_VALUE_MASK << C0_3_PSTATE_NEW_SHIFT);
+		tmp |= (i << C0_3_PSTATE_NEW_SHIFT);
+		__raw_writel(tmp, dvfs_info->base + XMU_C0_3_PSTATE + cpu * 4);
+	}
+
+	/* Enable DVFS */
+	__raw_writel(1 << XMU_DVFS_CTRL_EN_SHIFT,
+				dvfs_info->base + XMU_DVFS_CTRL);
+}
+
+static int exynos_verify_speed(struct cpufreq_policy *policy)
+{
+	return cpufreq_frequency_table_verify(policy,
+					      dvfs_info->freq_table);
+}
+
+static unsigned int exynos_getspeed(unsigned int cpu)
+{
+	return dvfs_info->cur_frequency;
+}
+
+static int exynos_target(struct cpufreq_policy *policy,
+			  unsigned int target_freq,
+			  unsigned int relation)
+{
+	unsigned int index, tmp;
+	int ret = 0, i;
+	struct cpufreq_frequency_table *freq_table = dvfs_info->freq_table;
+
+	mutex_lock(&cpufreq_lock);
+	freqs.old = dvfs_info->cur_frequency;
+
+	ret = cpufreq_frequency_table_target(policy, freq_table,
+					   target_freq, relation, &index);
+	if (ret)
+		goto out;
+
+	freqs.new = freq_table[index].frequency;
+	freqs.cpu = policy->cpu;
+
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);
+
+	/* Set the target frequency in all C0_3_PSTATE register */
+	for_each_cpu(i, policy->cpus) {
+		tmp = __raw_readl(dvfs_info->base + XMU_C0_3_PSTATE + i * 4);
+		tmp &= ~(P_VALUE_MASK << C0_3_PSTATE_NEW_SHIFT);
+		tmp |= (index << C0_3_PSTATE_NEW_SHIFT);
+
+		__raw_writel(tmp, dvfs_info->base + XMU_C0_3_PSTATE + i * 4);
+	}
+out:
+	mutex_unlock(&cpufreq_lock);
+	return ret;
+}
+
+static void exynos_cpufreq_work(struct work_struct *work)
+{
+	unsigned int cur_pstate, index;
+	struct cpufreq_policy *policy = cpufreq_cpu_get(0); /* boot CPU */
+	struct cpufreq_frequency_table *freq_table = dvfs_info->freq_table;
+
+	/* Ensure we can access cpufreq structures */
+	if (unlikely(dvfs_info->dvfs_enabled == false))
+		goto skip_work;
+
+	mutex_lock(&cpufreq_lock);
+	freqs.old = dvfs_info->cur_frequency;
+
+	cur_pstate = __raw_readl(dvfs_info->base + XMU_P_STATUS);
+	if (cur_pstate >> C0_3_PSTATE_VALID_SHIFT & 0x1)
+		index = (cur_pstate >> C0_3_PSTATE_CURR_SHIFT) & P_VALUE_MASK;
+	else
+		index = (cur_pstate >> C0_3_PSTATE_NEW_SHIFT) & P_VALUE_MASK;
+
+	if (likely(index < dvfs_info->freq_count)) {
+		freqs.new = freq_table[index].frequency;
+		dvfs_info->cur_frequency = freqs.new;
+	} else {
+		dev_crit(dvfs_info->dev, "New frequency out of range\n");
+		freqs.new = dvfs_info->cur_frequency;
+	}
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_POSTCHANGE);
+
+	cpufreq_cpu_put(policy);
+	mutex_unlock(&cpufreq_lock);
+skip_work:
+	enable_irq(dvfs_info->irq);
+}
+
+static irqreturn_t exynos_cpufreq_irq(int irq, void *id)
+{
+	unsigned int tmp;
+
+	tmp = __raw_readl(dvfs_info->base + XMU_PMUIRQ);
+	if (tmp >> PSTATE_CHANGED_SHIFT & 0x1) {
+		__raw_writel(tmp, dvfs_info->base + XMU_PMUIRQ);
+		disable_irq_nosync(irq);
+		schedule_work(&dvfs_info->irq_work);
+	}
+	return IRQ_HANDLED;
+}
+
+static void exynos_sort_descend_freq_table(void)
+{
+	struct cpufreq_frequency_table *freq_tbl = dvfs_info->freq_table;
+	int i = 0, index;
+	unsigned int tmp_freq;
+	/*
+	 * Exynos5440 clock controller state logic expects the cpufreq table to
+	 * be in descending order. But the OPP library constructs the table in
+	 * ascending order. So to make the table descending we just need to
+	 * swap the i element with the N - i element.
+	 */
+	for (i = 0; i < dvfs_info->freq_count / 2; i++) {
+		index = dvfs_info->freq_count - i - 1;
+		tmp_freq = freq_tbl[i].frequency;
+		freq_tbl[i].frequency = freq_tbl[index].frequency;
+		freq_tbl[index].frequency = tmp_freq;
+	}
+}
+
+static int exynos_cpufreq_cpu_init(struct cpufreq_policy *policy)
+{
+	int ret;
+
+	ret = cpufreq_frequency_table_cpuinfo(policy, dvfs_info->freq_table);
+	if (ret) {
+		dev_err(dvfs_info->dev, "Invalid frequency table: %d\n", ret);
+		return ret;
+	}
+
+	policy->cur = dvfs_info->cur_frequency;
+	policy->cpuinfo.transition_latency = dvfs_info->latency;
+	cpumask_setall(policy->cpus);
+
+	cpufreq_frequency_table_get_attr(dvfs_info->freq_table, policy->cpu);
+
+	return 0;
+}
+
+static struct cpufreq_driver exynos_driver = {
+	.flags		= CPUFREQ_STICKY,
+	.verify		= exynos_verify_speed,
+	.target		= exynos_target,
+	.get		= exynos_getspeed,
+	.init		= exynos_cpufreq_cpu_init,
+	.name		= CPUFREQ_NAME,
+};
+
+static const struct of_device_id exynos_cpufreq_match[] = {
+	{
+		.compatible = "samsung,exynos5440-cpufreq",
+	},
+	{},
+};
+MODULE_DEVICE_TABLE(of, exynos_cpufreq_match);
+
+static int exynos_cpufreq_probe(struct platform_device *pdev)
+{
+	int ret = -EINVAL;
+	struct device_node *np;
+	struct resource res;
+
+	np =  pdev->dev.of_node;
+	if (!np)
+		return -ENODEV;
+
+	dvfs_info = devm_kzalloc(&pdev->dev, sizeof(*dvfs_info), GFP_KERNEL);
+	if (!dvfs_info) {
+		ret = -ENOMEM;
+		goto err_put_node;
+	}
+
+	dvfs_info->dev = &pdev->dev;
+
+	ret = of_address_to_resource(np, 0, &res);
+	if (ret)
+		goto err_put_node;
+
+	dvfs_info->base = devm_ioremap_resource(dvfs_info->dev, &res);
+	if (IS_ERR(dvfs_info->base)) {
+		ret = PTR_ERR(dvfs_info->base);
+		goto err_put_node;
+	}
+
+	dvfs_info->irq = irq_of_parse_and_map(np, 0);
+	if (!dvfs_info->irq) {
+		dev_err(dvfs_info->dev, "No cpufreq irq found\n");
+		ret = -ENODEV;
+		goto err_put_node;
+	}
+
+	ret = of_init_opp_table(dvfs_info->dev);
+	if (ret) {
+		dev_err(dvfs_info->dev, "failed to init OPP table: %d\n", ret);
+		goto err_put_node;
+	}
+
+	ret = opp_init_cpufreq_table(dvfs_info->dev, &dvfs_info->freq_table);
+	if (ret) {
+		dev_err(dvfs_info->dev,
+			"failed to init cpufreq table: %d\n", ret);
+		goto err_put_node;
+	}
+	dvfs_info->freq_count = opp_get_opp_count(dvfs_info->dev);
+	exynos_sort_descend_freq_table();
+
+	if (of_property_read_u32(np, "clock-latency", &dvfs_info->latency))
+		dvfs_info->latency = DEF_TRANS_LATENCY;
+
+	dvfs_info->cpu_clk = devm_clk_get(dvfs_info->dev, "armclk");
+	if (IS_ERR(dvfs_info->cpu_clk)) {
+		dev_err(dvfs_info->dev, "Failed to get cpu clock\n");
+		ret = PTR_ERR(dvfs_info->cpu_clk);
+		goto err_free_table;
+	}
+
+	dvfs_info->cur_frequency = clk_get_rate(dvfs_info->cpu_clk);
+	if (!dvfs_info->cur_frequency) {
+		dev_err(dvfs_info->dev, "Failed to get clock rate\n");
+		ret = -EINVAL;
+		goto err_free_table;
+	}
+	dvfs_info->cur_frequency /= 1000;
+
+	INIT_WORK(&dvfs_info->irq_work, exynos_cpufreq_work);
+	ret = devm_request_irq(dvfs_info->dev, dvfs_info->irq,
+				exynos_cpufreq_irq, IRQF_TRIGGER_NONE,
+				CPUFREQ_NAME, dvfs_info);
+	if (ret) {
+		dev_err(dvfs_info->dev, "Failed to register IRQ\n");
+		goto err_free_table;
+	}
+
+	ret = init_div_table();
+	if (ret) {
+		dev_err(dvfs_info->dev, "Failed to initialise div table\n");
+		goto err_free_table;
+	}
+
+	exynos_enable_dvfs();
+	ret = cpufreq_register_driver(&exynos_driver);
+	if (ret) {
+		dev_err(dvfs_info->dev,
+			"%s: failed to register cpufreq driver\n", __func__);
+		goto err_free_table;
+	}
+
+	of_node_put(np);
+	dvfs_info->dvfs_enabled = true;
+	return 0;
+
+err_free_table:
+	opp_free_cpufreq_table(dvfs_info->dev, &dvfs_info->freq_table);
+err_put_node:
+	of_node_put(np);
+	dev_err(dvfs_info->dev, "%s: failed initialization\n", __func__);
+	return ret;
+}
+
+static int exynos_cpufreq_remove(struct platform_device *pdev)
+{
+	cpufreq_unregister_driver(&exynos_driver);
+	opp_free_cpufreq_table(dvfs_info->dev, &dvfs_info->freq_table);
+	return 0;
+}
+
+static struct platform_driver exynos_cpufreq_platdrv = {
+	.driver = {
+		.name	= "exynos5440-cpufreq",
+		.owner	= THIS_MODULE,
+		.of_match_table = exynos_cpufreq_match,
+	},
+	.probe		= exynos_cpufreq_probe,
+	.remove		= exynos_cpufreq_remove,
+};
+module_platform_driver(exynos_cpufreq_platdrv);
+
+MODULE_AUTHOR("Amit Daniel Kachhap <amit.daniel at samsung.com>");
+MODULE_DESCRIPTION("Exynos5440 cpufreq driver");
+MODULE_LICENSE("GPL");
-- 
1.7.1



From amit.daniel at samsung.com  Mon Apr  8 04:17:36 2013
From: amit.daniel at samsung.com (Amit Daniel Kachhap)
Date: Mon,  8 Apr 2013 13:47:36 +0530
Subject: [PATCH V6 2/4] cpufreq: exynos: Remove error return even if no soc is
 found
In-Reply-To: <1365409058-32643-1-git-send-email-amit.daniel@samsung.com>
References: <1365409058-32643-1-git-send-email-amit.daniel@samsung.com>
Message-ID: <1365409058-32643-3-git-send-email-amit.daniel@samsung.com>

This patch helps to have single binary for exynos5440 and previous
exynos soc's. This change is needed for adding exynos5440 cpufreq driver
which does not uses exynos-cpufreq common file and adds it own driver.

Cc: Viresh Kumar <viresh.kumar at linaro.org>
Cc: Rafael J. Wysocki <rjw at sisk.pl>
Cc: Kukjin Kim <kgene.kim at samsung.com>
Signed-off-by: Amit Daniel Kachhap <amit.daniel at samsung.com>
---
 drivers/cpufreq/exynos-cpufreq.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/cpufreq/exynos-cpufreq.c b/drivers/cpufreq/exynos-cpufreq.c
index c0c4ce5..475b4f6 100644
--- a/drivers/cpufreq/exynos-cpufreq.c
+++ b/drivers/cpufreq/exynos-cpufreq.c
@@ -294,7 +294,7 @@ static int __init exynos_cpufreq_init(void)
 	else if (soc_is_exynos5250())
 		ret = exynos5250_cpufreq_init(exynos_info);
 	else
-		pr_err("%s: CPU type not found\n", __func__);
+		return 0;
 
 	if (ret)
 		goto err_vdd_arm;
-- 
1.7.1



From amit.daniel at samsung.com  Mon Apr  8 04:17:37 2013
From: amit.daniel at samsung.com (Amit Daniel Kachhap)
Date: Mon,  8 Apr 2013 13:47:37 +0530
Subject: [PATCH V6 3/4] arm: exynos: Enable OPP library support for exynos5440
In-Reply-To: <1365409058-32643-1-git-send-email-amit.daniel@samsung.com>
References: <1365409058-32643-1-git-send-email-amit.daniel@samsung.com>
Message-ID: <1365409058-32643-4-git-send-email-amit.daniel@samsung.com>

The OPP library support is needed for exynos5440 cpu frequency
dynamic scaling driver.

Cc: Viresh Kumar <viresh.kumar at linaro.org>
Cc: Rafael J. Wysocki <rjw at sisk.pl>
Cc: Kukjin Kim <kgene.kim at samsung.com>
Signed-off-by: Amit Daniel Kachhap <amit.daniel at samsung.com>
---
 arch/arm/mach-exynos/Kconfig |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index 70f94c8..d5dde07 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -72,10 +72,12 @@ config SOC_EXYNOS5440
 	bool "SAMSUNG EXYNOS5440"
 	default y
 	depends on ARCH_EXYNOS5
+	select ARCH_HAS_OPP
 	select ARM_ARCH_TIMER
 	select AUTO_ZRELADDR
 	select PINCTRL
 	select PINCTRL_EXYNOS5440
+	select PM_OPP
 	help
 	  Enable EXYNOS5440 SoC support
 
-- 
1.7.1



From amit.daniel at samsung.com  Mon Apr  8 04:17:38 2013
From: amit.daniel at samsung.com (Amit Daniel Kachhap)
Date: Mon,  8 Apr 2013 13:47:38 +0530
Subject: [PATCH V6 4/4] arm: dts: Add cpufreq controller node for Exynos5440
 SoC
In-Reply-To: <1365409058-32643-1-git-send-email-amit.daniel@samsung.com>
References: <1365409058-32643-1-git-send-email-amit.daniel@samsung.com>
Message-ID: <1365409058-32643-5-git-send-email-amit.daniel@samsung.com>

Add cpufreq controller device node for Exynos5440 SoC for passing
parameters like controller base address, interrupt and cpufreq
table. This node is added outside cpu0 as this driver is now a platform
driver and a new device structure is needed.

Cc: Viresh Kumar <viresh.kumar at linaro.org>
Cc: Rafael J. Wysocki <rjw at sisk.pl>
Cc: Kukjin Kim <kgene.kim at samsung.com>
Signed-off-by: Amit Daniel Kachhap <amit.daniel at samsung.com>
---
 arch/arm/boot/dts/exynos5440.dtsi |   12 ++++++++++++
 1 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5440.dtsi b/arch/arm/boot/dts/exynos5440.dtsi
index 9a99755..94074ea 100644
--- a/arch/arm/boot/dts/exynos5440.dtsi
+++ b/arch/arm/boot/dts/exynos5440.dtsi
@@ -63,6 +63,18 @@
 
 	};
 
+	cpufreq at 160000 {
+		compatible = "samsung,exynos5440-cpufreq";
+		reg = <0x160000 0x1000>;
+		interrupts = <0 57 0>;
+		operating-points = <
+				/* KHz	  uV */
+				1200000 1025000
+				1000000 975000
+				800000  925000
+		>;
+	};
+
 	serial at B0000 {
 		compatible = "samsung,exynos4210-uart";
 		reg = <0xB0000 0x1000>;
-- 
1.7.1



From thierry.reding at avionic-design.de  Mon Apr  8 04:23:20 2013
From: thierry.reding at avionic-design.de (Thierry Reding)
Date: Mon, 8 Apr 2013 10:23:20 +0200
Subject: [PATCH 0/2] Update device tree binding document for pwm-tiehrpwm
 & pwm-tiecap
In-Reply-To: <518397C60809E147AF5323E0420B992E3EAA8DDE@DBDE01.ent.ti.com>
References: <1364195093-1357-1-git-send-email-avinashphilip@ti.com>
 <518397C60809E147AF5323E0420B992E3EAA8DDE@DBDE01.ent.ti.com>
Message-ID: <20130408082320.GB21392@avionic-0098.mockup.avionic-design.de>

On Mon, Apr 08, 2013 at 05:56:39AM +0000, Philip, Avinash wrote:
> Thierry,
> 
> On Mon, Mar 25, 2013 at 12:34:51, Philip, Avinash wrote:
> > Update device tree document of pwm-tiehrpwm & pwm-tiecap in order to reflect the
> > usage of similar modules in both da850 and am33xx platforms.
> 
> Can you accept both documentation update patches with Peter Korsgaard's Ack.

Thanks for the reminder. Both patches applied.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130408/973156cc/attachment.sig>

From amit.daniel at samsung.com  Mon Apr  8 04:25:10 2013
From: amit.daniel at samsung.com (amit daniel kachhap)
Date: Mon, 8 Apr 2013 13:55:10 +0530
Subject: [PATCH V5 1/4] cpufreq: exynos: Add cpufreq driver for exynos5440
In-Reply-To: <CAKohpon5BYW0Ypx8SbBsSUuugUnmYU=rBCMizz-CxuHjCzObpQ@mail.gmail.com>
References: <1364457923-8499-1-git-send-email-amit.daniel@samsung.com>
 <1364457923-8499-2-git-send-email-amit.daniel@samsung.com>
 <CAKohpon5BYW0Ypx8SbBsSUuugUnmYU=rBCMizz-CxuHjCzObpQ@mail.gmail.com>
Message-ID: <CADGdYn7PCAPPuAe6Y+VTGq=98i0_6YvDdJsRiLcwMyfsoohbag@mail.gmail.com>

On Thu, Mar 28, 2013 at 6:12 PM, Viresh Kumar <viresh.kumar at linaro.org> wrote:
>
> On 28 March 2013 13:35, Amit Daniel Kachhap <amit.daniel at samsung.com> wrote:
> > +++ b/drivers/cpufreq/exynos5440-cpufreq.c
> > +static int exynos_cpufreq_cpu_init(struct cpufreq_policy *policy)
> > +{
> > +       policy->cur = dvfs_info->cur_frequency;
> > +       cpufreq_frequency_table_get_attr(dvfs_info->freq_table, policy->cpu);
> > +
> > +       /* set the transition latency value */
> > +       policy->cpuinfo.transition_latency = dvfs_info->latency;
> > +
> > +       cpumask_setall(policy->cpus);
> > +
> > +       return cpufreq_frequency_table_cpuinfo(policy, dvfs_info->freq_table);
>
> I missed this earlier and saw this mistake in yet another driver.
> You need to call cpufreq_frequency_table_get_attr() only when
> cpufreq_frequency_table_cpuinfo() has passed.

ok. Submitted the V6 version with this change.

>
>
> > +}
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


From ezequiel.garcia at free-electrons.com  Mon Apr  8 04:26:22 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Mon, 8 Apr 2013 05:26:22 -0300
Subject: [PATCH v2 1/4] thermal: Add driver for Armada 370/XP SoC thermal
 management
In-Reply-To: <1364907910.2190.37.camel@rzhang1-mobl4>
References: <1364292988-8358-1-git-send-email-ezequiel.garcia@free-electrons.com>
 <1364292988-8358-2-git-send-email-ezequiel.garcia@free-electrons.com>
 <1364435017.2275.20.camel@rzhang1-mobl4>
 <20130402013740.GA28373@localhost>
 <1364907910.2190.37.camel@rzhang1-mobl4>
Message-ID: <20130408082621.GA2259@localhost>

Hi Zhang,

On Tue, Apr 02, 2013 at 09:05:10PM +0800, Zhang Rui wrote:
> On Mon, 2013-04-01 at 22:37 -0300, Ezequiel Garcia wrote:
> > On Thu, Mar 28, 2013 at 09:43:37AM +0800, Zhang Rui wrote:
> > > On Tue, 2013-03-26 at 07:16 -0300, Ezequiel Garcia wrote:
> > > > This driver supports both Armada 370 and Armada XP SoC
> > > > thermal management controllers.
> > > > 
> > > > Armada 370 has a register to check a valid temperature, whereas
> > > > Armada XP does not. Each has a different initialization (i.e. calibration)
> > > > function. The temperature conversion formula is the same for both.
> > > > 
> > > > The controller present in each SoC have a very similar feature set,
> > > > so it corresponds to have one driver to support both of them.
> > > > 
> > > > Although this driver may present similarities to Dove and Kirkwood
> > > > thermal driver, the exact differences and coincidences are not fully
> > > > known. For this reason, support is given through a separate driver.
> > > > 
> > > > Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
> 
> patch applied.
> 

I'm not seeing this patch applied on any branch.

Where have you applied this? Or perhaps there's anything left to fix?

-- 
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com


From shawn.guo at linaro.org  Mon Apr  8 04:35:05 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Mon, 8 Apr 2013 16:35:05 +0800
Subject: [PATCH v6] video: mxsfb: Introduce regulator support
In-Reply-To: <1365360299-8707-1-git-send-email-festevam@gmail.com>
References: <1365360299-8707-1-git-send-email-festevam@gmail.com>
Message-ID: <20130408083502.GG5047@S2101-09.ap.freescale.net>

On Sun, Apr 07, 2013 at 03:44:59PM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam at freescale.com>
> 
> Instead of using a custom binding for retrieving the GPIO that activates the 
> LCD from devicetree, use a standard regulator.
> 
> This approach has the advantage to be more generic. 
> 
> For example: in the case of a board that has a PMIC supplying the LCD voltage, 
> the current approach would not work, as it only searches for a GPIO pin.
> 
> Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>

Applied, thanks.



From amit.daniel at samsung.com  Mon Apr  8 04:36:38 2013
From: amit.daniel at samsung.com (amit daniel kachhap)
Date: Mon, 8 Apr 2013 14:06:38 +0530
Subject: [PATCH V5 0/4] cpufreq: exynos5440: support for cpufreq driver
In-Reply-To: <2949363.nNl2A6XIoS@vostro.rjw.lan>
References: <1364457923-8499-1-git-send-email-amit.daniel@samsung.com>
 <2949363.nNl2A6XIoS@vostro.rjw.lan>
Message-ID: <CADGdYn7ZRCSymU7k3Sn4mbS6B=dxy1N+vhQuyiFnhOQLLzrTbw@mail.gmail.com>

On Fri, Apr 5, 2013 at 6:08 PM, Rafael J. Wysocki <rjw at sisk.pl> wrote:
> On Thursday, March 28, 2013 01:35:18 PM Amit Daniel Kachhap wrote:
>> Submitting the V5 version of exynos5440 cpufreq driver. This patchset addresses
>> all the coding and design concerns raised especially by Viresh.
>>
>> Changes in V5:
>> * Removed the unnecessary DT look up entry from mach-exynos5-dt.c.
>> * Fixed all coding and comments issue raised by Viresh.
>>
>> Changes in V4:
>> * Added dev_err logs instead of pr_err.
>> * Used the devm_ioremap_resource API.
>> * Implemented several coding guidelines and minor error comments from Sylwester,
>>   Russell and Viresh.
>>
>> Changes in V3:
>> * Converted the driver to probe based as suggested by Viresh. This is also
>>   beneficial for multiplatform kernel.
>> * Other coding guidelines related changes.
>> * Moved the DT node outside cpu0 node as the driver is now a platform
>>   driver.
>>
>> Changes in V2:
>> * Added OPP library support to parse DT parameters.
>> * Removed a hack to handle interrupts in bootup.
>> * Implemented other review comments from Viresh and Inder.
>>
>> All these patches are dependent on Thomas Abraham common clock patches.
>> (http://www.mail-archive.com/linux-samsung-soc at vger.kernel.org/msg15860.html)
>> This whole patch series is based on 3.9-rc4.
>>
>> Amit Daniel Kachhap (4):
>>   cpufreq: exynos: Add cpufreq driver for exynos5440
>>   cpufreq: exynos: Remove error return even if no soc is found
>>   arm: exynos: Enable OPP library support for exynos5440
>>   arm: dts: Add cpufreq controller node for Exynos5440 SoC
>>
>>  .../bindings/cpufreq/cpufreq-exynos5440.txt        |   28 ++
>>  arch/arm/boot/dts/exynos5440.dtsi                  |   12 +
>>  arch/arm/mach-exynos/Kconfig                       |    2 +
>>  drivers/cpufreq/Kconfig.arm                        |    9 +
>>  drivers/cpufreq/Makefile                           |    1 +
>>  drivers/cpufreq/exynos-cpufreq.c                   |    2 +-
>>  drivers/cpufreq/exynos5440-cpufreq.c               |  474 ++++++++++++++++++++
>>  7 files changed, 527 insertions(+), 1 deletions(-)
>>  create mode 100644 Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt
>>  create mode 100644 drivers/cpufreq/exynos5440-cpufreq.c
>
> Is this for me or the Samsung tree?
>
> If it's for me, I need ACKs from the Samsung tree maintainers.  Also, please
> address the Viresh's comments.
>
> Thanks,
> Rafael
>
Hi Rafael,

I submitted the V6 version with all comments from Viresh addressed.

Hi Kukjin Kim,

Any suggestion on how this patch should be merged. In my opinion it
should go via Rafael's tree as this patch uses some fixes present in
Rafael's tree like modified cpufreq_notify_transition API.

Thanks,
Amit Daniel
>
> --
> I speak only for myself.
> Rafael J. Wysocki, Intel Open Source Technology Center.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/


From viresh.kumar at linaro.org  Mon Apr  8 04:47:06 2013
From: viresh.kumar at linaro.org (Viresh Kumar)
Date: Mon, 8 Apr 2013 14:17:06 +0530
Subject: [PATCH V6 1/4] cpufreq: exynos: Add cpufreq driver for exynos5440
In-Reply-To: <1365409058-32643-2-git-send-email-amit.daniel@samsung.com>
References: <1365409058-32643-1-git-send-email-amit.daniel@samsung.com>
 <1365409058-32643-2-git-send-email-amit.daniel@samsung.com>
Message-ID: <CAKohpo=CFTo2UCnECeeuKdz34cuedV_tqn7zGA9bzU_PiJ46qg@mail.gmail.com>

On 8 April 2013 13:47, Amit Daniel Kachhap <amit.daniel at samsung.com> wrote:

> diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
> index f3f3b14..bce2195 100644
> --- a/drivers/cpufreq/Kconfig.arm
> +++ b/drivers/cpufreq/Kconfig.arm
> @@ -42,6 +42,15 @@ config ARM_EXYNOS5250_CPUFREQ
>           This adds the CPUFreq driver for Samsung EXYNOS5250
>           SoC.
>
> +config ARM_EXYNOS5440_CPUFREQ
> +       def_bool SOC_EXYNOS5440
> +       depends on HAVE_CLK && PM_OPP && OF

Don't you need a depend on your Soc or mach or arch? Don't send another
version for this now.. Just send a new patch over this patchset.

> diff --git a/drivers/cpufreq/exynos5440-cpufreq.c b/drivers/cpufreq/exynos5440-cpufreq.c

> +static int exynos_target(struct cpufreq_policy *policy,
> +                         unsigned int target_freq,
> +                         unsigned int relation)
> +{
> +       unsigned int index, tmp;
> +       int ret = 0, i;
> +       struct cpufreq_frequency_table *freq_table = dvfs_info->freq_table;
> +
> +       mutex_lock(&cpufreq_lock);
> +       freqs.old = dvfs_info->cur_frequency;
> +
> +       ret = cpufreq_frequency_table_target(policy, freq_table,
> +                                          target_freq, relation, &index);
> +       if (ret)
> +               goto out;
> +

Move freqs.old = *** here.

> +       freqs.new = freq_table[index].frequency;
> +       freqs.cpu = policy->cpu;

You don't need this. Below call takes care of it.

Rest is fine.. Just resend this patch with all above issues fixed and i will Ack
it without any further reviews :)

Don't wait for few days for doing this, send it right now. :)


From jhovold at gmail.com  Mon Apr  8 04:46:18 2013
From: jhovold at gmail.com (Johan Hovold)
Date: Mon, 8 Apr 2013 10:46:18 +0200
Subject: [RFC 1/5] ARM: at91: add general purpose backup register (GPBR)
 support
In-Reply-To: <20130408073329.GO20693@game.jcrosoft.org>
References: <20130407150938.GA25605@localhost>
 <1365347572-14972-1-git-send-email-jhovold@gmail.com>
 <20130408073329.GO20693@game.jcrosoft.org>
Message-ID: <20130408084618.GB25605@localhost>

On Mon, Apr 08, 2013 at 09:33:29AM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 17:12 Sun 07 Apr     , Johan Hovold wrote:
> > 
> > Add General Purpose Backup Register (GPBR) support.
> > 
> > Most at91 SoCs have at least four 32-bit General Purpose Backup
> > Registers (GPBR) powered by backup-power (VDDBU). One such register is
> > currently used by rtc-at91sam9 driver to store the RTC time base.
> > 
> > Make sure the registers are mapped by arch setup code and add generic
> > accessors for in-kernel use.
> > 
> > This is a step in adding device-tree support to the rtc-at91sam9 driver.
> > 
> This is a regression
> 
> we loose the tracking of what request and use the GPBR

Implementing the GPBR accessors using a simple global resource was one
quick way forward to decouple and generalise the GPBR. Of course, this
could be turned into a more elaborate framework or driver where
registers are requested and released by other drivers and possibly also
by user-space.

Thanks,
Johan


From will.deacon at arm.com  Mon Apr  8 04:59:46 2013
From: will.deacon at arm.com (Will Deacon)
Date: Mon, 8 Apr 2013 09:59:46 +0100
Subject: [PATCH] documentation: iommu: add description of ARM System MMU
 binding
In-Reply-To: <515F1716.70309@gmail.com>
References: <1365094259-24847-1-git-send-email-will.deacon@arm.com>
 <515EFF1A.5030705@gmail.com>
 <20130405165745.GB17151@mudshark.cambridge.arm.com>
 <515F1716.70309@gmail.com>
Message-ID: <20130408085946.GA17208@mudshark.cambridge.arm.com>

On Fri, Apr 05, 2013 at 07:25:26PM +0100, Rob Herring wrote:
> On 04/05/2013 11:57 AM, Will Deacon wrote:
> > Hi Rob,
> > 
> > On Fri, Apr 05, 2013 at 05:43:06PM +0100, Rob Herring wrote:
> 
> [...]
> 
> >>> +- compatible    : Should be one of "arm,smmu-v1" or "arm,smmu-v2"
> >>> +                  depending on the version of the architecture
> >>> +                  implemented.
> >>
> >> We can keep these, but we should have specific models like arm,smmu-400,
> >> etc. as well.
> > 
> > Ok, if distinctions need to be between MMU-400 and a v1 implementation, then
> > we can add those strings later.
> 
> No, you want to have specific values in the dtb's up front. If there is
> something needed later in the kernel, you don't want to require a dtb
> update then. Adding future parts later is fine, but we already know what
> blocks we have.

Yes, you're right. I'll add those for v2.

Cheers,

Will


From shawn.guo at linaro.org  Mon Apr  8 05:00:18 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Mon, 8 Apr 2013 17:00:18 +0800
Subject: [GIT PULL 1/4] ARM: mxs: cleanup for 3.10
Message-ID: <1365411621-18422-1-git-send-email-shawn.guo@linaro.org>

Hi Arnd, Olof,

This is the mxs cleanup material for 3.10.  It's based on clksrc/cleanup
branch in arm-soc tree.  Please pull, thanks.

Shawn

The following changes since commit 3ed628a8122112ee796cd643e2478c4a6def234c:

  Merge remote-tracking branch 'arm-soc/clksrc/cleanup' into mxs/cleanup (2013-04-01 16:29:56 +0800)

are available in the git repository at:


  git://git.linaro.org/people/shawnguo/linux-2.6.git tags/mxs-cleanup-3.10

for you to fetch changes up to e933a1a12a02f42e0013cda87bba37ccb59efc47:

  clocksource: mxs_timer: Add semicolon at end of line (2013-04-03 10:30:08 +0800)

----------------------------------------------------------------
The mxs cleanup for 3.10:

* Clean up timer code and move it into drivers/clocksource
* Clean up icoll code and move it into drivers/irqchip
* Clean up clock code to not include <mach/*> headers
* Clean up rtc-stmp3xxx, mxs-lradc and mxs-saif to not include <mach/*>
  headers
* Clean up mach-mxs code to get it prepared for multiplatform support

----------------------------------------------------------------
Fabio Estevam (1):
      clocksource: mxs_timer: Add semicolon at end of line

Shawn Guo (25):
      ARM: mxs: use CLKSRC_OF helper to initialize timer
      ARM: mxs: look up timrot clock from device tree
      ARM: mxs: get timrot base address from device tree
      ARM: mxs: remove cpu_is_mx23() call from timer code
      ARM: mxs: select STMP_DEVICE and use it for timer code
      ARM: mxs: move timer driver into drivers/clocksource
      ARM: mxs: get icoll base address from device tree
      ARM: mxs: call stmp_reset_block() in icoll
      ARM: mxs: move icoll driver into drivers/irqchip
      ARM: mxs: remove unneeded mach-types.h inclusion
      clk: mxs: get base address from device tree
      clk: mxs: remove the use of mach level IO accessor
      rtc: stmp3xxx: use stmp_reset_block() instead
      iio: mxs-lradc: remove unneeded mach header inclusion
      ASoC: mxs-saif: remove mach header inclusion
      ARM: mxs: remove empty hardware.h
      ARM: mxs: get reset address from device tree
      ARM: mxs: remove system.c
      ARM: mxs: get ocotp base address from device tree
      ARM: mxs: use debug_ll_io_init for low-level debug
      ARM: mxs: remove mm.c
      ARM: mxs: move mxs_get_ocotp() into mach-mxs.c
      ARM: mxs: remove common.h
      ARM: mxs: merge imx23 and imx28 into one machine_desc
      ARM: mxs: remove unused headers

 arch/arm/Kconfig                                   |    2 +
 arch/arm/boot/dts/imx23.dtsi                       |    5 +-
 arch/arm/boot/dts/imx28.dtsi                       |    5 +-
 arch/arm/mach-mxs/Makefile                         |    4 -
 arch/arm/mach-mxs/include/mach/common.h            |   29 ---
 arch/arm/mach-mxs/include/mach/debug-macro.S       |    9 +-
 arch/arm/mach-mxs/include/mach/digctl.h            |   22 --
 arch/arm/mach-mxs/include/mach/hardware.h          |   23 --
 arch/arm/mach-mxs/include/mach/mx23.h              |  169 ---------------
 arch/arm/mach-mxs/include/mach/mx28.h              |  225 --------------------
 arch/arm/mach-mxs/include/mach/mxs.h               |  117 ----------
 arch/arm/mach-mxs/mach-mxs.c                       |  185 +++++++++++++---
 arch/arm/mach-mxs/mm.c                             |   52 -----
 arch/arm/mach-mxs/ocotp.c                          |   93 --------
 arch/arm/mach-mxs/system.c                         |  139 ------------
 drivers/clk/mxs/clk-imx23.c                        |   42 ++--
 drivers/clk/mxs/clk-imx28.c                        |   42 ++--
 drivers/clocksource/Makefile                       |    1 +
 .../timer.c => drivers/clocksource/mxs_timer.c     |   36 ++--
 drivers/irqchip/Makefile                           |    1 +
 .../mach-mxs/icoll.c => drivers/irqchip/irq-mxs.c  |   24 +--
 drivers/rtc/rtc-stmp3xxx.c                         |    6 +-
 drivers/staging/iio/adc/mxs-lradc.c                |    3 -
 include/linux/clk/mxs.h                            |   16 ++
 include/linux/irqchip/mxs.h                        |   14 ++
 sound/soc/mxs/mxs-saif.c                           |    5 +-
 26 files changed, 279 insertions(+), 990 deletions(-)
 delete mode 100644 arch/arm/mach-mxs/include/mach/common.h
 delete mode 100644 arch/arm/mach-mxs/include/mach/digctl.h
 delete mode 100644 arch/arm/mach-mxs/include/mach/hardware.h
 delete mode 100644 arch/arm/mach-mxs/include/mach/mx23.h
 delete mode 100644 arch/arm/mach-mxs/include/mach/mx28.h
 delete mode 100644 arch/arm/mach-mxs/include/mach/mxs.h
 delete mode 100644 arch/arm/mach-mxs/mm.c
 delete mode 100644 arch/arm/mach-mxs/ocotp.c
 delete mode 100644 arch/arm/mach-mxs/system.c
 rename arch/arm/mach-mxs/timer.c => drivers/clocksource/mxs_timer.c (91%)
 rename arch/arm/mach-mxs/icoll.c => drivers/irqchip/irq-mxs.c (89%)
 create mode 100644 include/linux/clk/mxs.h
 create mode 100644 include/linux/irqchip/mxs.h



From shawn.guo at linaro.org  Mon Apr  8 05:00:19 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Mon, 8 Apr 2013 17:00:19 +0800
Subject: [GIT PULL 2/4] ARM: mxs: multiplatform for 3.10
In-Reply-To: <1365411621-18422-1-git-send-email-shawn.guo@linaro.org>
References: <1365411621-18422-1-git-send-email-shawn.guo@linaro.org>
Message-ID: <1365411621-18422-2-git-send-email-shawn.guo@linaro.org>

Hi Arnd, Olof,

It's based on mxs-cleanup-3.10 to enable multiplatform build for
mach-mxs. Please pull, thanks.

Shawn

The following changes since commit e933a1a12a02f42e0013cda87bba37ccb59efc47:

  clocksource: mxs_timer: Add semicolon at end of line (2013-04-03 10:30:08 +0800)

are available in the git repository at:

  git://git.linaro.org/people/shawnguo/linux-2.6.git tags/mxs-multiplatform-3.10

for you to fetch changes up to d696e3f6585ddeb7bddbf0783b649fa669459a5c:

  ARM: mxs: enable multiplatform build (2013-04-04 21:15:58 +0800)

----------------------------------------------------------------
The mxs multiplatform support for 3.10:

* It enables the multiplatform build for mach-mxs platform.

----------------------------------------------------------------
Shawn Guo (3):
      ARM: mxs: call mxs_pm_init() as a machine_desc hook
      ARM: mxs: rename debug-macro.S for multiplatform build
      ARM: mxs: enable multiplatform build

 arch/arm/Kconfig                                   |   17 -----
 arch/arm/Kconfig.debug                             |    1 +
 arch/arm/configs/mxs_defconfig                     |    2 +-
 .../mach/debug-macro.S => include/debug/mxs.S}     |    0
 arch/arm/mach-mxs/Kconfig                          |   22 +++---
 arch/arm/mach-mxs/Makefile                         |    2 +-
 arch/arm/mach-mxs/Makefile.boot                    |    1 -
 arch/arm/mach-mxs/include/mach/timex.h             |   21 ------
 arch/arm/mach-mxs/include/mach/uncompress.h        |   76 --------------------
 arch/arm/mach-mxs/mach-mxs.c                       |    3 +
 arch/arm/mach-mxs/pm.c                             |    4 +-
 arch/arm/mach-mxs/pm.h                             |   14 ++++
 12 files changed, 33 insertions(+), 130 deletions(-)
 rename arch/arm/{mach-mxs/include/mach/debug-macro.S => include/debug/mxs.S} (100%)
 delete mode 100644 arch/arm/mach-mxs/Makefile.boot
 delete mode 100644 arch/arm/mach-mxs/include/mach/timex.h
 delete mode 100644 arch/arm/mach-mxs/include/mach/uncompress.h
 create mode 100644 arch/arm/mach-mxs/pm.h



From shawn.guo at linaro.org  Mon Apr  8 05:00:21 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Mon, 8 Apr 2013 17:00:21 +0800
Subject: [GIT PULL 4/4] ARM: mxs: device tree changes for 3.10
In-Reply-To: <1365411621-18422-1-git-send-email-shawn.guo@linaro.org>
References: <1365411621-18422-1-git-send-email-shawn.guo@linaro.org>
Message-ID: <1365411621-18422-4-git-send-email-shawn.guo@linaro.org>

Hi Arnd, Olof,

This is the mxs device tree changes for 3.10.  It's based on
mxs-cleanup-3.10 to avoid some nasty conflicts.  Please pull, thanks.

Shawn

The following changes since commit e933a1a12a02f42e0013cda87bba37ccb59efc47:

  clocksource: mxs_timer: Add semicolon at end of line (2013-04-03 10:30:08 +0800)

are available in the git repository at:

  git://git.linaro.org/people/shawnguo/linux-2.6.git tags/mxs-dt-3.10

for you to fetch changes up to 4344429d3d926d219671f607125cff51223a140a:

  video: mxsfb: Introduce regulator support (2013-04-08 15:44:55 +0800)

----------------------------------------------------------------
The mxs device tree changes for 3.10:

* Move enet_out clk into device tree and have fec driver handle it.
* Convert mxsfb driver to generic display timings bindings, and remove
  the mxsfb auxdata from platform code.
* Add generic DMA device tree binding for mxs-dma, and convert the most
  of client device drivers to it.
* Change mxsfb driver to use regulator for controlling power of panel.
* A few device tree source updates

----------------------------------------------------------------
Alexandre Belloni (3):
      ARM: cfa10036: add one wire bitbanging to the cfa10049
      pinctrl: pinctrl-mxs: document the missing pull-ups
      ARM: dts: cfa10036: Add touchscreen support to the CFA-10049

Alexandre Pereira da Silva (1):
      ARM: dts: imx23-olinuxino: mark sdcard cd as broken

Fabio Estevam (1):
      video: mxsfb: Introduce regulator support

Shawn Guo (16):
      net: fec: handle optional clk_ptp more gracefully
      ARM: mxs: remove unneeded enet_out clk initialization
      video: mxsfb: use devm_* managed functions
      video: mxsfb: remove fb_phys/fb_size from platform_data
      video: mxsfb: remove dotclk_delay from platform_data
      video: mxsfb: get display timings from device tree
      ARM: mxs: move display timing configurations into device tree
      video: mxsfb: remove mxsfb_platform_data
      ARM: dts: add generic DMA device tree binding for mxs-dma
      dma: mxs-dma: use devm_* managed functions
      dma: mxs-dma: move to generic device tree binding
      mmc: mxs-mmc: move to use generic DMA helper
      spi: mxs-spi: move to use generic DMA helper
      i2c: i2c-mxs: move to use generic DMA helper
      mtd: gpmi: move to use generic DMA helper
      serial: mxs-auart: move to use generic DMA helper

Wolfram Sang (2):
      net: freescale: fec: add support for optional enet_out clk
      ARM: dts: mxs: add enet_out clock to devicetree

 .../devicetree/bindings/dma/fsl-mxs-dma.txt        |   49 +++-
 Documentation/devicetree/bindings/fb/mxsfb.txt     |   36 ++-
 Documentation/devicetree/bindings/i2c/i2c-mxs.txt  |   12 +-
 Documentation/devicetree/bindings/mmc/mxs-mmc.txt  |   12 +-
 .../devicetree/bindings/mtd/gpmi-nand.txt          |   17 +-
 .../bindings/pinctrl/fsl,mxs-pinctrl.txt           |    4 +
 Documentation/devicetree/bindings/spi/mxs-spi.txt  |   12 +-
 .../bindings/tty/serial/fsl-mxs-auart.txt          |   16 +-
 arch/arm/boot/dts/imx23-evk.dts                    |   36 ++-
 arch/arm/boot/dts/imx23-olinuxino.dts              |    1 +
 arch/arm/boot/dts/imx23.dtsi                       |   42 +++-
 arch/arm/boot/dts/imx28-apf28dev.dts               |   25 ++
 arch/arm/boot/dts/imx28-apx4devkit.dts             |   25 ++
 arch/arm/boot/dts/imx28-cfa10049.dts               |   50 +++-
 arch/arm/boot/dts/imx28-evk.dts                    |   36 ++-
 arch/arm/boot/dts/imx28-m28evk.dts                 |   27 ++
 arch/arm/boot/dts/imx28.dtsi                       |   62 ++++-
 arch/arm/boot/dts/imx6qdl.dtsi                     |    8 +-
 arch/arm/mach-mxs/mach-mxs.c                       |  170 -------------
 drivers/dma/mxs-dma.c                              |  109 +++++---
 drivers/i2c/busses/i2c-mxs.c                       |   40 +--
 drivers/mmc/host/mxs-mmc.c                         |   48 +---
 drivers/mtd/nand/gpmi-nand/gpmi-nand.c             |   51 +---
 drivers/mtd/nand/gpmi-nand/gpmi-nand.h             |    3 +-
 drivers/net/ethernet/freescale/fec.c               |   18 +-
 drivers/net/ethernet/freescale/fec.h               |    1 +
 drivers/spi/spi-mxs.c                              |   60 +----
 drivers/tty/serial/mxs-auart.c                     |   52 +---
 drivers/video/Kconfig                              |    2 +
 drivers/video/mxsfb.c                              |  260 ++++++++++++--------
 include/linux/mxsfb.h                              |   52 ----
 include/linux/spi/mxs-spi.h                        |    4 +-
 32 files changed, 696 insertions(+), 644 deletions(-)
 delete mode 100644 include/linux/mxsfb.h



From shawn.guo at linaro.org  Mon Apr  8 05:00:20 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Mon, 8 Apr 2013 17:00:20 +0800
Subject: [GIT PULL 3/4] ARM: mxs: soc changes for 3.10
In-Reply-To: <1365411621-18422-1-git-send-email-shawn.guo@linaro.org>
References: <1365411621-18422-1-git-send-email-shawn.guo@linaro.org>
Message-ID: <1365411621-18422-3-git-send-email-shawn.guo@linaro.org>

The following changes since commit 07961ac7c0ee8b546658717034fe692fd12eefa9:

  Linux 3.9-rc5 (2013-03-31 15:12:43 -0700)

are available in the git repository at:

  git://git.linaro.org/people/shawnguo/linux-2.6.git tags/mxs-soc-3.10

for you to fetch changes up to 656c284c5c517460245db159e122b0207f06f998:

  ARM: mxs_defconfig: Select watchdog driver (2013-04-01 16:31:04 +0800)

----------------------------------------------------------------
The mxs soc changes for 3.10:

* A few mxs_defconfig changes
* Select ARM_CPU_SUSPEND for suspend testing

----------------------------------------------------------------
Fabio Estevam (4):
      ARM: mxs: Select ARM_CPU_SUSPEND
      ARM: mxs_defconfig: Build CONFIG_INPUT_EVDEV as built-in
      ARM: mxs_defconfig: Select CONFIG_MMC_UNSAFE_RESUME
      ARM: mxs_defconfig: Select watchdog driver

 arch/arm/configs/mxs_defconfig |    5 ++++-
 arch/arm/mach-mxs/Kconfig      |    2 ++
 2 files changed, 6 insertions(+), 1 deletion(-)



From jhovold at gmail.com  Mon Apr  8 05:00:23 2013
From: jhovold at gmail.com (Johan Hovold)
Date: Mon, 8 Apr 2013 11:00:23 +0200
Subject: [RFC 4/5] RTC: rtc-at91sam9: add device-tree support
In-Reply-To: <20130408073807.GQ20693@game.jcrosoft.org>
References: <20130407150938.GA25605@localhost>
 <1365347572-14972-1-git-send-email-jhovold@gmail.com>
 <1365347572-14972-4-git-send-email-jhovold@gmail.com>
 <20130408073807.GQ20693@game.jcrosoft.org>
Message-ID: <20130408090023.GC25605@localhost>

On Mon, Apr 08, 2013 at 09:38:07AM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 17:12 Sun 07 Apr     , Johan Hovold wrote:
> > Add device-tree support.
> > 
> > The AT91 RTT can be used as an RTC if the atmel,at91-rtt-as-rtc-gpbr
> > property is present and set to the general-purpose backup register to
> > use to store the RTC time base.
> > 
> > Signed-off-by: Johan Hovold <jhovold at gmail.com>
> > ---
> >  .../devicetree/bindings/rtc/rtc-at91sam9.txt       | 19 ++++++++++++
> >  drivers/rtc/rtc-at91sam9.c                         | 36 +++++++++++++++++++++-
> >  2 files changed, 54 insertions(+), 1 deletion(-)
> >  create mode 100644 Documentation/devicetree/bindings/rtc/rtc-at91sam9.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/rtc/rtc-at91sam9.txt b/Documentation/devicetree/bindings/rtc/rtc-at91sam9.txt
> > new file mode 100644
> > index 0000000..0f54988
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/rtc/rtc-at91sam9.txt
> > @@ -0,0 +1,19 @@
> > +Atmel AT91 RTT as RTC
> > +=====================
> > +
> > +Required properties:
> > +- compatible: Should be "atmel,at91sam9260-rtt"
> > +- reg: Should contain register location and length
> > +- interrupts: Should contain interrupt for the RTT which is the IRQ line
> > +  shared across all System Controller members.
> > +- atmel,rtt-as-rtc-gpbr: Should contain the backup-register to use to store
> > +  the RTC time base
> > +
> > +Example:
> > +
> > +rtt at fffffd20 {
> > +		compatible = "atmel,at91sam9g45-rtt", "atmel,at91sam9260-rtt";
> > +		reg = <0xfffffd20 0x10>;
> > +		interrupts = <1 4 7>;
> > +		atmel,at91-rtt-as-rtc-gpbr = <0>;
> no you miss the point of the DT
> 
> you need to describe the hardware no a particular use of it

That was what I was trying to achieve by adding the two use-neutral
rtt and gpbr-nodes. But then the question is how would you influence
which out of two rtt-drivers to use?

Adding a property as above in the final board descriptions seemed
preferable to adding rtt-as-rtc to the compatible string of the rtt as
that would mean describing use rather than just hardware.

> the RTT is a general purpose timer backuped that we use in linux as a
> RTC with a gpbr to store the time
> 
> you need 2 binding on for the RTT one the RTT-rtc

As in adding some virtual hardware-node which uses the rtt and gpbr as
resources?

Thanks,
Johan


From jg1.han at samsung.com  Mon Apr  8 05:08:53 2013
From: jg1.han at samsung.com (Jingoo Han)
Date: Mon, 08 Apr 2013 18:08:53 +0900
Subject: [PATCH 6/6] ARM: dts: Add pcie controller node for Samsung
 EXYNOS5440 SoC
In-Reply-To: <00c501ce277c$30e49dc0$92add940$%han@samsung.com>
References: <00c001ce277b$92b26ab0$b8174010$%han@samsung.com>
 <00c501ce277c$30e49dc0$92add940$%han@samsung.com>
Message-ID: <000001ce3438$b136e1e0$13a4a5a0$%han@samsung.com>

On Saturday, March 23, 2013 1:09 PM, Jingoo Han wrote:
> 
> Exynos5440 has two PCIe controllers which can be used as root complex
> for PCIe interface.
> 
> Signed-off-by: Jingoo Han <jg1.han at samsung.com>
> ---
>  arch/arm/boot/dts/exynos5440-ssdk5440.dts |    8 +++++++
>  arch/arm/boot/dts/exynos5440.dtsi         |   32 +++++++++++++++++++++++++++++
>  2 files changed, 40 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/exynos5440-ssdk5440.dts b/arch/arm/boot/dts/exynos5440-ssdk5440.dts
> index a21eb4c..746f9fc 100644
> --- a/arch/arm/boot/dts/exynos5440-ssdk5440.dts
> +++ b/arch/arm/boot/dts/exynos5440-ssdk5440.dts
> @@ -34,4 +34,12 @@
>  			clock-frequency = <50000000>;
>  		};
>  	};
> +
> +	pcie0 at 40000000 {
> +		reset-gpio = <5>;
> +	};
> +
> +	pcie1 at 60000000 {
> +		reset-gpio = <22>;
> +	};
>  };
> diff --git a/arch/arm/boot/dts/exynos5440.dtsi b/arch/arm/boot/dts/exynos5440.dtsi
> index c374a31..41b2d2c 100644
> --- a/arch/arm/boot/dts/exynos5440.dtsi
> +++ b/arch/arm/boot/dts/exynos5440.dtsi
> @@ -178,4 +178,36 @@
>  		clocks = <&clock 21>;
>  		clock-names = "rtc";
>  	};
> +
> +	pcie0 at 40000000 {
> +		compatible = "samsung,exynos5440-pcie";
> +		reg = <0x40000000 0x4000
> +			0x290000 0x1000
> +			0x270000 0x1000
> +			0x271000 0x40>;
> +		interrupts = <0 20 0>, <0 21 0>, <0 22 0>;
> +		#address-cells = <3>;
> +		#size-cells = <2>;
> +		device_type = "pci";
> +		bus-range = <0x0 0xf>;
> +		ranges = <0x00000800 0 0x40000000 0x40000000 0 0x00200000   /* configuration space */
> +			  0x81000000 0 0	  0x40200000 0 0x00004000   /* downstream I/O */
> +			  0x82000000 0 0	  0x40204000 0 0x10000000>; /* non-prefetchable memory */
> +	};
> +
> +	pcie1 at 60000000 {
> +		compatible = "samsung,exynos5440-pcie";
> +		reg = <0x60000000 0x4000
> +			0x2a0000 0x1000
> +			0x272000 0x1000
> +			0x271040 0x40>;
> +		interrupts = <0 23 0>, <0 24 0>, <0 25 0>;
> +		#address-cells = <3>;
> +		#size-cells = <2>;
> +		device_type = "pci";
> +		bus-range = <0x0 0xf>;
> +		ranges = <0x00000800 0 0x60000000 0x60000000 0 0x00200000   /* configuration space */
> +			  0x81000000 0 0	  0x60200000 0 0x00004000   /* downstream I/O */
> +			  0x82000000 0 0	  0x60204000 0 0x10000000>; /* non-prefetchable memory */
> +	};

Hi Jason,

I have a question.
Now, I am reviewing the Tegra PCIe, Marvell PCIe patchset.
However, in the case of Exynos PCIe,
'downstream I/O' and 'non-prefetchable memory' are different between PCIe0 and PCIe1.
These regions are not shared.

PCIe0:
	ranges = <0x00000800 0 0x40000000 0x40000000 0 0x00200000   /* configuration space */
		  0x81000000 0 0	  0x40200000 0 0x00004000   /* downstream I/O */
		  0x82000000 0 0	  0x40204000 0 0x10000000>; /* non-prefetchable memory */

PCIe1:
	ranges = <0x00000800 0 0x40000000 0x40000000 0 0x00200000   /* configuration space */
		  0x81000000 0 0	  0x40200000 0 0x00004000   /* downstream I/O */
		  0x82000000 0 0	  0x40204000 0 0x10000000>; /* non-prefetchable memory */

PCIe0 uses 0x40000000~0x5fffffff, PCI1 uses 0x60000000~0x7fffffff.

How can I handle this? :)
The following is right?

+       pcie-controller {
		.....
+               ranges = <0x82000000 0 0x40000000 0x40000000 0 0x00200000   /* port 0 registers */
+                         0x82000000 0 0x60000000 0x60000000 0 0x00200000   /* port 1 registers */
+                         0x81000000 0 0          0x40200000 0 0x00004000   /* port 0 downstream I/O */
+                         0x81000000 0 0          0x60200000 0 0x00004000   /* port 1 downstream I/O */
+                         0x82000000 0 0x40204000 0x40204000 0 0x10000000>; /* port 0 non-prefetchable memory */
+                         0x82000000 0 0x40204000 0x60204000 0 0x10000000>; /* port 1 non-prefetchable memory */
+
+               pci at 1,0 {
+                       device_type = "pci";
+                       assigned-addresses = <0x82000800 0 0x40000000 0 0x00200000
+                                                 0x81000800 0 0x40200000 0 0x00004000
+                                                 0x81000800 0 0x40204000 0 0x10000000>;
		.....
+               pci at 2,0 {
+                       device_type = "pci";
+                       assigned-addresses = <0x82000800 0 0x60000000 0 0x00200000
+                                                 0x81000800 0 0x60200000 0 0x00004000
+                                                 0x81000800 0 0x60204000 0 0x10000000>;

Best regards,
Jingoo Han


>  };
> --
> 1.7.2.5




From tixy at linaro.org  Mon Apr  8 05:10:11 2013
From: tixy at linaro.org (Jon Medhurst (Tixy))
Date: Mon, 08 Apr 2013 10:10:11 +0100
Subject: [PATCH v4 15/15] ARM: vexpress: Select multi-cluster SMP
 operation if required
In-Reply-To: <alpine.LFD.2.03.1304060943370.1171@syhkavp.arg>
References: <1360041732-17936-1-git-send-email-nicolas.pitre@linaro.org>
 <1360041732-17936-16-git-send-email-nicolas.pitre@linaro.org>
 <20130405224819.GB14308@quad.lixom.net>
 <alpine.LFD.2.03.1304060943370.1171@syhkavp.arg>
Message-ID: <1365412211.3384.16.camel@linaro1.home>

On Sat, 2013-04-06 at 10:02 -0400, Nicolas Pitre wrote:
> I've amended this patch slightly so to:
> 
> 1) Keep the default .smp = &vexpress_smp_ops and only perform an 
>    override in vexpress_smp_init_ops() when appropriate.  This should
>    remove one potential issue with Xen support that was highlighted 
>    recently.
> 
> 2) Add a mcpm_smp_set_ops() instead of installing mcpm_smp_ops directly
>    for better abstraction.
>
> 3) Added a comment about and checked for the CCI node being enabled.
> 
> That results in the patch below.  Given those are minor changes, I kept 
> the existing review tags.
>
> From: Jon Medhurst <tixy at linaro.org>
> Date: Wed, 30 Jan 2013 09:12:55 +0000
> Subject: [PATCH] ARM: vexpress: Select multi-cluster SMP operation if required
> 
> Signed-off-by: Jon Medhurst <tixy at linaro.org>
> Signed-off-by: Nicolas Pitre <nicolas.pitre at linaro.org>
> Reviewed-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
> Acked-by: Pawel Moll <pawel.moll at arm.com>
>
> diff --git a/arch/arm/common/mcpm_platsmp.c b/arch/arm/common/mcpm_platsmp.c
> index 34f236af09..cc82040877 100644
> --- a/arch/arm/common/mcpm_platsmp.c
> +++ b/arch/arm/common/mcpm_platsmp.c
> @@ -85,3 +85,8 @@ struct smp_operations __initdata mcpm_smp_ops = {
>  	.cpu_die		= mcpm_cpu_die,
>  #endif
>  };
> +
> +void __init mcpm_smp_set_ops(void)
> +{
> +	smp_set_ops(&mcpm_smp_ops);
> +}
> diff --git a/arch/arm/include/asm/mcpm_entry.h b/arch/arm/include/asm/mcpm_entry.h
> index 814623e6a1..34dfb86ff5 100644
> --- a/arch/arm/include/asm/mcpm_entry.h
> +++ b/arch/arm/include/asm/mcpm_entry.h
> @@ -190,5 +190,7 @@ int __mcpm_cluster_state(unsigned int cluster);
>  int __init mcpm_sync_init(
>  	void (*power_up_setup)(unsigned int affinity_level));
>  
> +void __init mcpm_smp_set_ops(void);
> +
>  #endif /* ! __ASSEMBLY__ */
>  #endif


Do the changes to the above mcpm files want to be in a separate patch as
it's generic ARM code, not vexpress specific?

> diff --git a/arch/arm/mach-vexpress/core.h b/arch/arm/mach-vexpress/core.h
> index f134cd4a85..3a761fd76c 100644
> --- a/arch/arm/mach-vexpress/core.h
> +++ b/arch/arm/mach-vexpress/core.h
> @@ -6,6 +6,8 @@
>  
>  void vexpress_dt_smp_map_io(void);
>  
> +void vexpress_smp_init_ops(void);
> +
>  extern struct smp_operations	vexpress_smp_ops;
>  
>  extern void vexpress_cpu_die(unsigned int cpu);
> diff --git a/arch/arm/mach-vexpress/platsmp.c b/arch/arm/mach-vexpress/platsmp.c
> index dc1ace55d5..06317bc714 100644
> --- a/arch/arm/mach-vexpress/platsmp.c
> +++ b/arch/arm/mach-vexpress/platsmp.c
> @@ -12,9 +12,11 @@
>  #include <linux/errno.h>
>  #include <linux/smp.h>
>  #include <linux/io.h>
> +#include <linux/of.h>
>  #include <linux/of_fdt.h>
>  #include <linux/vexpress.h>
>  
> +#include <asm/mcpm_entry.h>
>  #include <asm/smp_scu.h>
>  #include <asm/mach/map.h>
>  
> @@ -203,3 +205,18 @@ struct smp_operations __initdata vexpress_smp_ops = {
>  	.cpu_die		= vexpress_cpu_die,
>  #endif
>  };
> +
> +void __init vexpress_smp_init_ops(void)
> +{
> +#ifdef CONFIG_MCPM
> +	/*
> +	 * The best way to detect a multi-cluster configuration at the moment
> +	 * is to look for the presence of a CCI in the system.
> +	 * Override the default vexpress_smp_ops if so.
> +	 */
> +	struct device_node *node;
> +	node = of_find_compatible_node(NULL, NULL, "arm,cci");
> +	if (node && of_device_is_available(node))
> +		mcpm_smp_set_ops();
> +#endif
> +}

What now sets smp_ops if mcpm_smp_set_ops doesn't get called above? I
know there are umpteen versions of the patch "ARM: Enable selection of
SMP operations at boot time", but none of them seem to resolve that
issue.

> diff --git a/arch/arm/mach-vexpress/v2m.c b/arch/arm/mach-vexpress/v2m.c
> index 915683cb67..16b42c10e0 100644
> --- a/arch/arm/mach-vexpress/v2m.c
> +++ b/arch/arm/mach-vexpress/v2m.c
> @@ -476,6 +476,7 @@ static const char * const v2m_dt_match[] __initconst = {
>  DT_MACHINE_START(VEXPRESS_DT, "ARM-Versatile Express")
>  	.dt_compat	= v2m_dt_match,
>  	.smp		= smp_ops(vexpress_smp_ops),
> +	.smp_init	= smp_init_ops(vexpress_smp_init_ops),
>  	.map_io		= v2m_dt_map_io,
>  	.init_early	= v2m_dt_init_early,
>  	.init_irq	= irqchip_init,

-- 
Tixy



From avinashphilip at ti.com  Mon Apr  8 05:09:59 2013
From: avinashphilip at ti.com (Philip, Avinash)
Date: Mon, 8 Apr 2013 09:09:59 +0000
Subject: [PATCH v3 3/3] ARM: davinci: da850: add EHRPWM & ECAP DT node
In-Reply-To: <515A97DE.1080403@ti.com>
References: <1364197789-16783-1-git-send-email-avinashphilip@ti.com>
 <1364197789-16783-4-git-send-email-avinashphilip@ti.com>
 <515A97DE.1080403@ti.com>
Message-ID: <518397C60809E147AF5323E0420B992E3EAA91B6@DBDE01.ent.ti.com>

On Tue, Apr 02, 2013 at 14:03:34, Nori, Sekhar wrote:
> On 3/25/2013 1:19 PM, Philip Avinash wrote:
> > Add da850 EHRPWM & ECAP DT node.
> > Also adds OF_DEV_AUXDATA for EHRPWM & ECAP driver to use EHRPWM & ECAP
> > clock.
> 
> This looks fine to me but I will wait for the bindings to get accepted
> before taking this one.

Sekhar,

Binding document got accepted in PWM tree [1].
Can you accept this patch?

1. https://gitorious.org/linux-pwm

Thanks
Avinash

> 
> Thanks,
> Sekhar
> 


From kgene.kim at samsung.com  Mon Apr  8 05:15:09 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Mon, 08 Apr 2013 18:15:09 +0900
Subject: [PATCH 07/18] cpufreq: s3c24xx: move cpufreq driver to
 drivers/cpufreq
In-Reply-To: <1769336.FkfMpuXqqb@vostro.rjw.lan>
References: <cover.1365079581.git.viresh.kumar@linaro.org>
 <2a5901ce31c9$95160980$bf421c80$%kim@samsung.com>
 <CAKohpokk1Q+0gRpeW=ts0a8D+rGAUpHu62X+7ejdpfom_B6FYA@mail.gmail.com>
 <1769336.FkfMpuXqqb@vostro.rjw.lan>
Message-ID: <2ccd01ce3439$911b51b0$b351f510$%kim@samsung.com>

Rafael J. Wysocki wrote:
> 
> On Friday, April 05, 2013 12:36:34 PM Viresh Kumar wrote:
> > On 5 April 2013 12:18, Kukjin Kim <kgene.kim at samsung.com> wrote:
> > > Basically, this moving looks good to me, but should be re-worked based
> on
> > > for-next of samsung tree because this touches too many samsung stuff
> so this
> > > should be sent to upstream via samsung tree.
> >
> > Hmm... Its already applied in Rafael's tree. But it doesn't mean that
> > it can't be
> > moved to your tree if there is a issue.
> 
> Well, I'm dropping it.  Please merge via the Samsung tree.
> 
OK, I will.

I got patch file from Viresh, and there is a sign from Rafael, but it should be ack. So Rafael, let me use your ack on this patch when I apply. If any problems, please let me know.

Thanks.

- Kukjin



From viresh.kumar at linaro.org  Mon Apr  8 05:16:33 2013
From: viresh.kumar at linaro.org (Viresh Kumar)
Date: Mon, 8 Apr 2013 14:46:33 +0530
Subject: [PATCH V6 1/4] cpufreq: exynos: Add cpufreq driver for exynos5440
In-Reply-To: <CAKohpo=CFTo2UCnECeeuKdz34cuedV_tqn7zGA9bzU_PiJ46qg@mail.gmail.com>
References: <1365409058-32643-1-git-send-email-amit.daniel@samsung.com>
 <1365409058-32643-2-git-send-email-amit.daniel@samsung.com>
 <CAKohpo=CFTo2UCnECeeuKdz34cuedV_tqn7zGA9bzU_PiJ46qg@mail.gmail.com>
Message-ID: <CAKohpo=t_YTCTRCfnwQ+GPF=frsTGDigT3RZHJuVQ+R+YZU7Hg@mail.gmail.com>

On 8 April 2013 14:17, Viresh Kumar <viresh.kumar at linaro.org> wrote:
> On 8 April 2013 13:47, Amit Daniel Kachhap <amit.daniel at samsung.com> wrote:
>
>> diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
>> index f3f3b14..bce2195 100644
>> --- a/drivers/cpufreq/Kconfig.arm
>> +++ b/drivers/cpufreq/Kconfig.arm
>> @@ -42,6 +42,15 @@ config ARM_EXYNOS5250_CPUFREQ
>>           This adds the CPUFreq driver for Samsung EXYNOS5250
>>           SoC.
>>
>> +config ARM_EXYNOS5440_CPUFREQ
>> +       def_bool SOC_EXYNOS5440
>> +       depends on HAVE_CLK && PM_OPP && OF
>
> Don't you need a depend on your Soc or mach or arch? Don't send another
> version for this now.. Just send a new patch over this patchset.

Sorry, i overlooked def_bool... This comments stands invalid.


From prabhakar.csengg at gmail.com  Mon Apr  8 05:17:14 2013
From: prabhakar.csengg at gmail.com (Prabhakar lad)
Date: Mon,  8 Apr 2013 14:47:14 +0530
Subject: [PATCH v9 0/2] ARM: davinci: add support for dm365 vpbe display
Message-ID: <1365412636-3468-1-git-send-email-prabhakar.csengg@gmail.com>

From: Lad, Prabhakar <prabhakar.csengg at gmail.com>

This patch series enables VPBE display driver on DM365.

Changes for v9:
1: Removed extra line after break's and defines as pointed
   by Sekhar.
2: Included Ack's from Sekhar.

Changes for v8:
1: Fixed nits pointed by Sekhar.

Changes for v7:
1: Fixed nits pointed by Sekhar.

Changes for v6:
1: Fixed review comments pointed by Sekhar.

Changes for v5:
1: pass different platform names to handle different ip's.
2: Fixed review comments pointed by Sekhar.

Changes for v4:
1: Replaced the obsolete preset API by timings API.

Changes for v3:
1: Removed VPSS clock alias for master and slave which was
   sent for VPSS driver. since this patch was dependent on
   patch[1]. I will revist this patch once MC(captrure driver)
   goes into mainline.
[1] http://www.spinics.net/lists/linux-media/msg50562.html

Changes for v2:
1: Added VPSS clock so that capture and display
   can work independent.


Lad, Prabhakar (2):
  ARM: davinci: dm365: add support for v4l2 video display
  ARM: davinci: dm365 EVM: add support for VPBE display

 arch/arm/mach-davinci/board-dm365-evm.c |  166 +++++++++++++++++++++++++++-
 arch/arm/mach-davinci/davinci.h         |    7 +-
 arch/arm/mach-davinci/dm365.c           |  184 ++++++++++++++++++++++++++++---
 3 files changed, 340 insertions(+), 17 deletions(-)

-- 
1.7.4.1



From prabhakar.csengg at gmail.com  Mon Apr  8 05:17:15 2013
From: prabhakar.csengg at gmail.com (Prabhakar lad)
Date: Mon,  8 Apr 2013 14:47:15 +0530
Subject: [PATCH v9 1/2] ARM: davinci: dm365: add support for v4l2 video display
In-Reply-To: <1365412636-3468-1-git-send-email-prabhakar.csengg@gmail.com>
References: <1365412636-3468-1-git-send-email-prabhakar.csengg@gmail.com>
Message-ID: <1365412636-3468-2-git-send-email-prabhakar.csengg@gmail.com>

From: Lad, Prabhakar <prabhakar.csengg at gmail.com>

Create platform devices for various video modules like venc,osd,
vpbe and v4l2 driver for dm365.

Signed-off-by: Lad, Prabhakar <prabhakar.csengg at gmail.com>
Acked-by: Sekhar Nori <nsekhar at ti.com>
---
 arch/arm/mach-davinci/board-dm365-evm.c |    4 +-
 arch/arm/mach-davinci/davinci.h         |    7 +-
 arch/arm/mach-davinci/dm365.c           |  184 ++++++++++++++++++++++++++++---
 3 files changed, 178 insertions(+), 17 deletions(-)

diff --git a/arch/arm/mach-davinci/board-dm365-evm.c b/arch/arm/mach-davinci/board-dm365-evm.c
index c2d4958..cf77c46 100644
--- a/arch/arm/mach-davinci/board-dm365-evm.c
+++ b/arch/arm/mach-davinci/board-dm365-evm.c
@@ -564,8 +564,6 @@ static struct davinci_uart_config uart_config __initdata = {
 
 static void __init dm365_evm_map_io(void)
 {
-	/* setup input configuration for VPFE input devices */
-	dm365_set_vpfe_config(&vpfe_cfg);
 	dm365_init();
 }
 
@@ -597,6 +595,8 @@ static __init void dm365_evm_init(void)
 
 	davinci_setup_mmc(0, &dm365evm_mmc_config);
 
+	dm365_init_video(&vpfe_cfg, NULL);
+
 	/* maybe setup mmc1/etc ... _after_ mmc0 */
 	evm_init_cpld();
 
diff --git a/arch/arm/mach-davinci/davinci.h b/arch/arm/mach-davinci/davinci.h
index 12d544b..a9de512 100644
--- a/arch/arm/mach-davinci/davinci.h
+++ b/arch/arm/mach-davinci/davinci.h
@@ -36,8 +36,13 @@
 #include <media/davinci/vpbe_osd.h>
 
 #define DAVINCI_SYSTEM_MODULE_BASE	0x01c40000
+#define SYSMOD_VDAC_CONFIG		0x2c
 #define SYSMOD_VIDCLKCTL		0x38
 #define SYSMOD_VPSS_CLKCTL		0x44
+#define VPSS_VENCCLKEN_ENABLE		BIT(3)
+#define VPSS_DACCLKEN_ENABLE		BIT(4)
+#define VPSS_PLLC2SYSCLK5_ENABLE	BIT(5)
+
 #define SYSMOD_VDD3P3VPWDN		0x48
 #define SYSMOD_VSCLKDIS			0x6c
 #define SYSMOD_PUPDCTL1			0x7c
@@ -84,7 +89,7 @@ void __init dm365_init_ks(struct davinci_ks_platform_data *pdata);
 void __init dm365_init_rtc(void);
 void dm365_init_spi0(unsigned chipselect_mask,
 			const struct spi_board_info *info, unsigned len);
-void dm365_set_vpfe_config(struct vpfe_config *cfg);
+int dm365_init_video(struct vpfe_config *, struct vpbe_config *);
 
 /* DM644x function declarations */
 void __init dm644x_init(void);
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index c61dd94..ff771ce 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -39,16 +39,13 @@
 #include "asp.h"
 
 #define DM365_REF_FREQ		24000000	/* 24 MHz on the DM365 EVM */
-
-/* Base of key scan register bank */
-#define DM365_KEYSCAN_BASE		0x01c69400
-
 #define DM365_RTC_BASE			0x01c69000
-
+#define DM365_KEYSCAN_BASE		0x01c69400
+#define DM365_OSD_BASE			0x01c71c00
+#define DM365_VENC_BASE			0x01c71e00
 #define DAVINCI_DM365_VC_BASE		0x01d0c000
 #define DAVINCI_DMA_VC_TX		2
 #define DAVINCI_DMA_VC_RX		3
-
 #define DM365_EMAC_BASE			0x01d07000
 #define DM365_EMAC_MDIO_BASE		(DM365_EMAC_BASE + 0x4000)
 #define DM365_EMAC_CNTRL_OFFSET		0x0000
@@ -1233,6 +1230,173 @@ static struct platform_device dm365_isif_dev = {
 	},
 };
 
+static struct resource dm365_osd_resources[] = {
+	{
+		.start = DM365_OSD_BASE,
+		.end   = DM365_OSD_BASE + 0xff,
+		.flags = IORESOURCE_MEM,
+	},
+};
+
+static u64 dm365_video_dma_mask = DMA_BIT_MASK(32);
+
+static struct platform_device dm365_osd_dev = {
+	.name		= DM365_VPBE_OSD_SUBDEV_NAME,
+	.id		= -1,
+	.num_resources	= ARRAY_SIZE(dm365_osd_resources),
+	.resource	= dm365_osd_resources,
+	.dev		= {
+		.dma_mask		= &dm365_video_dma_mask,
+		.coherent_dma_mask	= DMA_BIT_MASK(32),
+	},
+};
+
+static struct resource dm365_venc_resources[] = {
+	{
+		.start = IRQ_VENCINT,
+		.end   = IRQ_VENCINT,
+		.flags = IORESOURCE_IRQ,
+	},
+	/* venc registers io space */
+	{
+		.start = DM365_VENC_BASE,
+		.end   = DM365_VENC_BASE + 0x177,
+		.flags = IORESOURCE_MEM,
+	},
+	/* vdaccfg registers io space */
+	{
+		.start = DAVINCI_SYSTEM_MODULE_BASE + SYSMOD_VDAC_CONFIG,
+		.end   = DAVINCI_SYSTEM_MODULE_BASE + SYSMOD_VDAC_CONFIG + 3,
+		.flags = IORESOURCE_MEM,
+	},
+};
+
+static struct resource dm365_v4l2_disp_resources[] = {
+	{
+		.start = IRQ_VENCINT,
+		.end   = IRQ_VENCINT,
+		.flags = IORESOURCE_IRQ,
+	},
+	/* venc registers io space */
+	{
+		.start = DM365_VENC_BASE,
+		.end   = DM365_VENC_BASE + 0x177,
+		.flags = IORESOURCE_MEM,
+	},
+};
+
+static int dm365_vpbe_setup_pinmux(enum v4l2_mbus_pixelcode if_type,
+			    int field)
+{
+	switch (if_type) {
+	case V4L2_MBUS_FMT_SGRBG8_1X8:
+		davinci_cfg_reg(DM365_VOUT_FIELD_G81);
+		davinci_cfg_reg(DM365_VOUT_COUTL_EN);
+		davinci_cfg_reg(DM365_VOUT_COUTH_EN);
+		break;
+	case V4L2_MBUS_FMT_YUYV10_1X20:
+		if (field)
+			davinci_cfg_reg(DM365_VOUT_FIELD);
+		else
+			davinci_cfg_reg(DM365_VOUT_FIELD_G81);
+		davinci_cfg_reg(DM365_VOUT_COUTL_EN);
+		davinci_cfg_reg(DM365_VOUT_COUTH_EN);
+		break;
+	default:
+		return -EINVAL;
+	}
+
+	return 0;
+}
+
+static int dm365_venc_setup_clock(enum vpbe_enc_timings_type type,
+				  unsigned int pclock)
+{
+	void __iomem *vpss_clkctl_reg;
+	u32 val;
+
+	vpss_clkctl_reg = DAVINCI_SYSMOD_VIRT(SYSMOD_VPSS_CLKCTL);
+
+	switch (type) {
+	case VPBE_ENC_STD:
+		val = VPSS_VENCCLKEN_ENABLE | VPSS_DACCLKEN_ENABLE;
+		break;
+	case VPBE_ENC_DV_TIMINGS:
+		if (pclock <= 27000000) {
+			val = VPSS_VENCCLKEN_ENABLE | VPSS_DACCLKEN_ENABLE;
+		} else {
+			/* set sysclk4 to output 74.25 MHz from pll1 */
+			val = VPSS_PLLC2SYSCLK5_ENABLE | VPSS_DACCLKEN_ENABLE |
+			      VPSS_VENCCLKEN_ENABLE;
+		}
+		break;
+	default:
+		return -EINVAL;
+	}
+	writel(val, vpss_clkctl_reg);
+
+	return 0;
+}
+
+static struct platform_device dm365_vpbe_display = {
+	.name		= "vpbe-v4l2",
+	.id		= -1,
+	.num_resources  = ARRAY_SIZE(dm365_v4l2_disp_resources),
+	.resource	= dm365_v4l2_disp_resources,
+	.dev		= {
+		.dma_mask		= &dm365_video_dma_mask,
+		.coherent_dma_mask	= DMA_BIT_MASK(32),
+	},
+};
+
+struct venc_platform_data dm365_venc_pdata = {
+	.setup_pinmux	= dm365_vpbe_setup_pinmux,
+	.setup_clock	= dm365_venc_setup_clock,
+};
+
+static struct platform_device dm365_venc_dev = {
+	.name		= DM365_VPBE_VENC_SUBDEV_NAME,
+	.id		= -1,
+	.num_resources	= ARRAY_SIZE(dm365_venc_resources),
+	.resource	= dm365_venc_resources,
+	.dev		= {
+		.dma_mask		= &dm365_video_dma_mask,
+		.coherent_dma_mask	= DMA_BIT_MASK(32),
+		.platform_data		= (void *)&dm365_venc_pdata,
+	},
+};
+
+static struct platform_device dm365_vpbe_dev = {
+	.name		= "vpbe_controller",
+	.id		= -1,
+	.dev		= {
+		.dma_mask		= &dm365_video_dma_mask,
+		.coherent_dma_mask	= DMA_BIT_MASK(32),
+	},
+};
+
+int __init dm365_init_video(struct vpfe_config *vpfe_cfg,
+				struct vpbe_config *vpbe_cfg)
+{
+	if (vpfe_cfg || vpbe_cfg)
+		platform_device_register(&dm365_vpss_device);
+
+	if (vpfe_cfg) {
+		vpfe_capture_dev.dev.platform_data = vpfe_cfg;
+		platform_device_register(&dm365_isif_dev);
+		platform_device_register(&vpfe_capture_dev);
+	}
+	if (vpbe_cfg) {
+		dm365_vpbe_dev.dev.platform_data = vpbe_cfg;
+		platform_device_register(&dm365_osd_dev);
+		platform_device_register(&dm365_venc_dev);
+		platform_device_register(&dm365_vpbe_dev);
+		platform_device_register(&dm365_vpbe_display);
+	}
+
+	return 0;
+}
+
 static int __init dm365_init_devices(void)
 {
 	if (!cpu_is_davinci_dm365())
@@ -1246,14 +1410,6 @@ static int __init dm365_init_devices(void)
 	clk_add_alias(NULL, dev_name(&dm365_mdio_device.dev),
 		      NULL, &dm365_emac_device.dev);
 
-	platform_device_register(&dm365_vpss_device);
-	platform_device_register(&dm365_isif_dev);
-	platform_device_register(&vpfe_capture_dev);
 	return 0;
 }
 postcore_initcall(dm365_init_devices);
-
-void dm365_set_vpfe_config(struct vpfe_config *cfg)
-{
-       vpfe_capture_dev.dev.platform_data = cfg;
-}
-- 
1.7.4.1



From prabhakar.csengg at gmail.com  Mon Apr  8 05:17:16 2013
From: prabhakar.csengg at gmail.com (Prabhakar lad)
Date: Mon,  8 Apr 2013 14:47:16 +0530
Subject: [PATCH v9 2/2] ARM: davinci: dm365 EVM: add support for VPBE display
In-Reply-To: <1365412636-3468-1-git-send-email-prabhakar.csengg@gmail.com>
References: <1365412636-3468-1-git-send-email-prabhakar.csengg@gmail.com>
Message-ID: <1365412636-3468-3-git-send-email-prabhakar.csengg@gmail.com>

From: Lad, Prabhakar <prabhakar.csengg at gmail.com>

add support for V4L2 video display to DM365 EVM.
Support for SD and ED modes is provided, along with Composite
and Component outputs.

Signed-off-by: Lad, Prabhakar <prabhakar.csengg at gmail.com>
Acked-by: Sekhar Nori <nsekhar at ti.com>
---
 arch/arm/mach-davinci/board-dm365-evm.c |  164 ++++++++++++++++++++++++++++++-
 1 files changed, 163 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-davinci/board-dm365-evm.c b/arch/arm/mach-davinci/board-dm365-evm.c
index cf77c46..0518ce5 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/v4l2-dv-timings.h>
 
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
@@ -39,6 +40,7 @@
 #include <linux/platform_data/mtd-davinci.h>
 #include <linux/platform_data/keyscan-davinci.h>
 
+#include <media/ths7303.h>
 #include <media/tvp514x.h>
 
 #include "davinci.h"
@@ -374,6 +376,166 @@ static struct vpfe_config vpfe_cfg = {
 	.ccdc = "ISIF",
 };
 
+/* venc standards timings */
+static struct vpbe_enc_mode_info dm365evm_enc_std_timing[] = {
+	{
+		.name		= "ntsc",
+		.timings_type	= VPBE_ENC_STD,
+		.std_id		= 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,
+		.std_id		= V4L2_STD_625_50,
+		.interlaced	= 1,
+		.xres		= 720,
+		.yres		= 576,
+		.aspect		= {54, 59},
+		.fps		= {25, 1},
+		.left_margin	= 0x7E,
+		.upper_margin	= 0x16,
+	},
+};
+
+/* venc dv timings */
+static struct vpbe_enc_mode_info dm365evm_enc_preset_timing[] = {
+	{
+		.name		= "480p59_94",
+		.timings_type	= VPBE_ENC_DV_TIMINGS,
+		.dv_timings	= V4L2_DV_BT_CEA_720X480P59_94,
+		.interlaced	= 0,
+		.xres		= 720,
+		.yres		= 480,
+		.aspect		= {1, 1},
+		.fps		= {5994, 100},
+		.left_margin	= 0x8F,
+		.upper_margin	= 0x2D,
+	},
+	{
+		.name		= "576p50",
+		.timings_type	= VPBE_ENC_DV_TIMINGS,
+		.dv_timings	= V4L2_DV_BT_CEA_720X576P50,
+		.interlaced	= 0,
+		.xres		= 720,
+		.yres		= 576,
+		.aspect		= {1, 1},
+		.fps		= {50, 1},
+		.left_margin	= 0x8C,
+		.upper_margin   = 0x36,
+	},
+	{
+		.name		= "720p60",
+		.timings_type	= VPBE_ENC_DV_TIMINGS,
+		.dv_timings	= V4L2_DV_BT_CEA_1280X720P60,
+		.interlaced	= 0,
+		.xres		= 1280,
+		.yres		= 720,
+		.aspect		= {1, 1},
+		.fps		= {60, 1},
+		.left_margin	= 0x117,
+		.right_margin	= 70,
+		.upper_margin	= 38,
+		.lower_margin	= 3,
+		.hsync_len	= 80,
+		.vsync_len	= 5,
+	},
+	{
+		.name		= "1080i60",
+		.timings_type	= VPBE_ENC_DV_TIMINGS,
+		.dv_timings	= V4L2_DV_BT_CEA_1920X1080I60,
+		.interlaced	= 1,
+		.xres		= 1920,
+		.yres		= 1080,
+		.aspect		= {1, 1},
+		.fps		= {30, 1},
+		.left_margin	= 0xc9,
+		.right_margin	= 80,
+		.upper_margin	= 30,
+		.lower_margin	= 3,
+		.hsync_len	= 88,
+		.vsync_len	= 5,
+	},
+};
+
+#define VENC_STD_ALL	(V4L2_STD_NTSC | V4L2_STD_PAL)
+
+/*
+ * The outputs available from VPBE + ecnoders. Keep the
+ * 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 dm365evm_vpbe_outputs[] = {
+	{
+		.output		= {
+			.index		= 0,
+			.name		= "Composite",
+			.type		= V4L2_OUTPUT_TYPE_ANALOG,
+			.std		= VENC_STD_ALL,
+			.capabilities	= V4L2_OUT_CAP_STD,
+		},
+		.subdev_name	= DM365_VPBE_VENC_SUBDEV_NAME,
+		.default_mode	= "ntsc",
+		.num_modes	= ARRAY_SIZE(dm365evm_enc_std_timing),
+		.modes		= dm365evm_enc_std_timing,
+		.if_params	= V4L2_MBUS_FMT_FIXED,
+	},
+	{
+		.output		= {
+			.index		= 1,
+			.name		= "Component",
+			.type		= V4L2_OUTPUT_TYPE_ANALOG,
+			.capabilities	= V4L2_OUT_CAP_DV_TIMINGS,
+		},
+		.subdev_name	= DM365_VPBE_VENC_SUBDEV_NAME,
+		.default_mode	= "480p59_94",
+		.num_modes	= ARRAY_SIZE(dm365evm_enc_preset_timing),
+		.modes		= dm365evm_enc_preset_timing,
+		.if_params	= V4L2_MBUS_FMT_FIXED,
+	},
+};
+
+/*
+ * Amplifiers on the board
+ */
+struct ths7303_platform_data ths7303_pdata = {
+	.ch_1 = 3,
+	.ch_2 = 3,
+	.ch_3 = 3,
+	.init_enable = 1,
+};
+
+static struct amp_config_info vpbe_amp = {
+	.module_name	= "ths7303",
+	.is_i2c		= 1,
+	.board_info	= {
+		I2C_BOARD_INFO("ths7303", 0x2c),
+		.platform_data = &ths7303_pdata,
+	}
+};
+
+static struct vpbe_config dm365evm_display_cfg = {
+	.module_name	= "dm365-vpbe-display",
+	.i2c_adapter_id	= 1,
+	.amp		= &vpbe_amp,
+	.osd		= {
+		.module_name	= DM365_VPBE_OSD_SUBDEV_NAME,
+	},
+	.venc		= {
+		.module_name	= DM365_VPBE_VENC_SUBDEV_NAME,
+	},
+	.num_outputs	= ARRAY_SIZE(dm365evm_vpbe_outputs),
+	.outputs	= dm365evm_vpbe_outputs,
+};
+
 static void __init evm_init_i2c(void)
 {
 	davinci_init_i2c(&i2c_pdata);
@@ -595,7 +757,7 @@ static __init void dm365_evm_init(void)
 
 	davinci_setup_mmc(0, &dm365evm_mmc_config);
 
-	dm365_init_video(&vpfe_cfg, NULL);
+	dm365_init_video(&vpfe_cfg, &dm365evm_display_cfg);
 
 	/* maybe setup mmc1/etc ... _after_ mmc0 */
 	evm_init_cpld();
-- 
1.7.4.1



From viresh.kumar at linaro.org  Mon Apr  8 05:18:08 2013
From: viresh.kumar at linaro.org (Viresh Kumar)
Date: Mon, 8 Apr 2013 14:48:08 +0530
Subject: [PATCH 07/18] cpufreq: s3c24xx: move cpufreq driver to
 drivers/cpufreq
In-Reply-To: <2ccd01ce3439$911b51b0$b351f510$%kim@samsung.com>
References: <cover.1365079581.git.viresh.kumar@linaro.org>
 <2a5901ce31c9$95160980$bf421c80$%kim@samsung.com>
 <CAKohpokk1Q+0gRpeW=ts0a8D+rGAUpHu62X+7ejdpfom_B6FYA@mail.gmail.com>
 <1769336.FkfMpuXqqb@vostro.rjw.lan>
 <2ccd01ce3439$911b51b0$b351f510$%kim@samsung.com>
Message-ID: <CAKohpomcSF-o3piHeOONZuFubJ0xkBjHJRG7j7FN=NaXBiJPiw@mail.gmail.com>

On 8 April 2013 14:45, Kukjin Kim <kgene.kim at samsung.com> wrote:
> Rafael J. Wysocki wrote:
>> Well, I'm dropping it.  Please merge via the Samsung tree.
>>
> OK, I will.
>
> I got patch file from Viresh, and there is a sign from Rafael, but it should be ack. So Rafael, let me use your ack on this patch when I apply. If any problems, please let me know.

Ahh.. I forgot to remove it. I picked the initial patch from Rafael's tree.
But yes, you need it anyway :)


From sameo at linux.intel.com  Mon Apr  8 05:18:51 2013
From: sameo at linux.intel.com (Samuel Ortiz)
Date: Mon, 8 Apr 2013 11:18:51 +0200
Subject: [GIT PULL] AB8500 Power and MFD related updates
In-Reply-To: <20130307043859.GA11944@gmail.com>
References: <20130307043859.GA11944@gmail.com>
Message-ID: <20130408091851.GI24058@zurbaran>

Hi Lee,

On Thu, Mar 07, 2013 at 12:38:59PM +0800, Lee Jones wrote:
> The following changes since commit 6dbe51c251a327e012439c4772097a13df43c5b8:
> 
>   Linux 3.9-rc1 (2013-03-03 15:11:05 -0800)
> 
> are available in the git repository at:
> 
>   git://git.linaro.org/people/ljones/linux-3.0-ux500.git for-mfd-and-power
I was expecting to get an MFD only branch (Basically what your for-mfd branch
looks like, and then the for-mfd-and-power one to be based on the mfd only
with the power patches applied on top of it.
Now, I have to pull the power patches as well, which is no big deal but not
ideal neither.
Anyway, I pulled this branch into mfd-next, with a tiny conflict.

Cheers,
Samuel.

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


From will.deacon at arm.com  Mon Apr  8 05:25:35 2013
From: will.deacon at arm.com (Will Deacon)
Date: Mon, 8 Apr 2013 10:25:35 +0100
Subject: [PATCH] documentation: iommu: add description of ARM System MMU
 binding
In-Reply-To: <515F37C1.4000109@codeaurora.org>
References: <1365094259-24847-1-git-send-email-will.deacon@arm.com>
 <515F37C1.4000109@codeaurora.org>
Message-ID: <20130408092535.GA17476@mudshark.cambridge.arm.com>

Hi Olav,

On Fri, Apr 05, 2013 at 09:44:49PM +0100, Olav Haugan wrote:
> On 4/4/2013 9:50 AM, Will Deacon wrote:
> > diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> > new file mode 100644
> > index 0000000..938325f
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> > @@ -0,0 +1,61 @@
> > +* ARM System MMU Architecture Implementation
> > +
> > +ARM SoCs may contain an implementation of the ARM System Memory
> > +Management Unit Architecture, which can be used to provide 1 or 2 stages
> > +of address translation to bus masters external to the CPU.
> > +
> > +The SMMU may also raise interrupts in response to various fault
> > +conditions.
> > +
> > +** System MMU required properties:
> > +
> > +- compatible    : Should be one of "arm,smmu-v1" or "arm,smmu-v2"
> > +                  depending on the version of the architecture
> > +                  implemented.
> > +
> > +- reg           : Base address and size of the SMMU.
> > +
> > +- #global-interrupts : The number of global interrupts exposed by the
> > +                       device.
> > +
> > +- interrupts    : Interrupt list, with the first #global-irqs entries
> > +                  corresponding to the global interrupts and any
> > +                  following entries corresponding to context interrupts,
> > +                  specified in order of their indexing by the SMMU.
> > +
> > +- mmu-masters   : A list of phandles to device nodes representing bus
> > +                  masters for which the SMMU can provide a translation.
> 
> I am not sure I understand the use of mmu-masters. I would imagine that
> the bus masters themselves would have phandles to their respective SMMUs
> that provides the translation.

The problem with that is when you have chained SMMUs. E.g., a separate SMMU
for stage 1 and stage 2, where the StreamIDs are not the same going into the
second SMMU on the chain. The set of masters and StreamIDs coming into a
system MMU is really a property of that system MMU, and is determined at
integration time.

> > +
> > +- stream-ids    : A list of 16-bit values corresponding to the StreamIDs
> > +                  for the devices listed in the mmu-masters property.
> > +                  This list must be same length as mmu-masters, so
> > +                  masters with multiple stream-ids will have multiple
> > +                  entries in mmu-masters.
> > +
> 
> Why are the stream IDs (SIDs) coupled with the bus masters in this way?
> You are probably following a different pattern than we do. Our SMMU
> driver programs the SMMU SIDs and does not really know or care which
> mmu-master it belongs to.

Generally, the StreamIDs are fixed in hardware (as a function of various AXI
bits -- see the SMMU integration guide) and cannot be set by software.
Furthermore, when the StreamIDs have an implicit effect on IOMMU domain
configuration, since stream-matching may not be always be able to identify a
master uniquely.

> Please see my comments above. I would like to work with you on defining
> the bindings for System MMU. We have had System MMU DT bindings for some
> time and I'd like to share what we are doing in hope that we can merge
> something that works for all of us.
> 
> We use some of the same properties but we have a lot more. We also model
> the context banks as children of each SMMU in an object-oriented way.

Hmm, what you have looks really... complicated. Why do you need so much stuff?

> Here is our current binding for SMMUv1:
> 
> * Qualcomm MSM IOMMU v1
> 
> Required properties:
> - compatible : one of:
> 	- "qcom,msm-smmu-v1"
> - reg : offset and length of the register set for the device. Optional
> 	offset and length for clock register for additional clock that
> 	needs to be turned on for access to this IOMMU.
> - reg-names: "iommu_base", "clk_base" (optional)

Since I'm just working on a software model, I've not gone near clocks.
However, clocks are fairly well understood so we could easily add those
later if they're needed.

> - label: name of this IOMMU instance.

What?

> Optional properties:
> - qcom,iommu-secure-id : Secure identifier for the IOMMU block
> - vdd-supply : vdd-supply: phandle to GDSC regulator controlling this IOMMU.
> - qcom,alt-vdd-supply : Alternative regulator needed to access IOMMU
>   configuration registers.
> - interrupts : should contain the performance monitor overflow interrupt
> number.
> - qcom,iommu-enable-halt : Enable halt of the IOMMU before programming
> certain	registers
> - qcom,iommu-pmu-ngroups: Number of Performance Monitor Unit (PMU) groups.
> - qcom,iommu-pmu-ncounters: Number of PMU counters per group.
> - qcom,iommu-pmu-event-classes: List of event classes supported.
> - qcom,needs-alt-core-clk : boolean to enable the secondary core clock
> for access to the IOMMU configuration registers
> - qcom,iommu-bfb-regs : An array of unsigned 32-bit integers
> corresponding to BFB register addresses that need to be configured for
> performance tuning purposes. If this property is present, the
> qcom,iommu-bfb-data must also be present. Register addresses are
> specified as an offset from the base of the IOMMU hardware block. This
> property may be omitted if no BFB register configuration needs to be
> done for a particular IOMMU hardware instance. The registers specified
> by this property shall fall within the IOMMU implementation-defined
> register region.
> - qcom,iommu-bfb-data : An array of unsigned 32-bit integers
> representing the values to be programmed into the corresponding
> registers given by the qcom,iommu-bfb-regs property. If this property is
> present, the qcom,iommu-bfb-regs property shall also be present, and the
> lengths of both properties shall be the same.

This really looks specific to your implementation/integration and I can't
see that we'd want this in the binding to be honest. It would be good to
have PMU support in the future, but I've not thought about that part yet.

> - List of sub nodes, one for each of the translation context banks
> supported.
>   Each sub node has the following required properties:
> 
>   - reg : offset and length of the register set for the context bank.

Why do you need this? The structure of the context banks is well defined by
the SMMU architecture.

>   - interrupts : should contain the context bank interrupt.
>   - qcom,iommu-ctx-sids : List of stream identifiers associated with
> this translation context.

StreamIDs aren't statically associated with a translation context. Why do
you put them here? Also, how do this interact with stream matching?

>   - label : Name of the context bank

Again: what?

> Optional sub-node properties:
>    - qcom,secure-context : boolean indicating that a context is secure
>  and programmed by the secure environment.

Why does Linux care about this?

> Please let me know your thoughts on this.

I'd really rather start off small, and describe precisely what we need to
get architecturally-compliant SMMUs off the ground. Then, as the code grows
to use more features (PM, PMU, ...) then we can extend the binding.
Otherwise, we paint ourselves into a corner with the binding before we've
developed any driver code.

Will


From prabhakar.csengg at gmail.com  Mon Apr  8 05:26:53 2013
From: prabhakar.csengg at gmail.com (Prabhakar lad)
Date: Mon,  8 Apr 2013 14:56:53 +0530
Subject: [PATCH v8 0/2] ARM: davinci: dm355: add support for vpbe display
Message-ID: <1365413215-3632-1-git-send-email-prabhakar.csengg@gmail.com>

From: Lad, Prabhakar <prabhakar.csengg at gmail.com>

This patch series enables VPBE display driver on DM355.

This patch series is dependent on VPSS clock cleanup patches
(http://www.mail-archive.com/davinci-linux-open-source at linux.davincidsp.com/msg25613.html)
posted.

Changes for v8:
1: Removed extra line after break's and defines as pointed
   by Sekhar.
2: Included Ack from Sekhar for the second patch of the series.

Changes for v7:
1: Fixed nits pointed by Sekhar for DM365 series.

Changes for v6:
1: Fixed nits pointed by Sekhar.

Changes for v5:
1: Rebased on 3.9, fix review comments pointed by Sekhar for DM365 series.

Changes for v4:
1: pass different platform names to handle different ip's.

Changes for v3:
1: Replaced obsolete preset API by timings API.

Changes for v2:
1: Removed VPSS clock alias for master and slave which was
   sent for VPSS driver. since this patch was dependent on
   patch[1]. I will revist this patch once MC(captrure driver)
   goes into mainline.
   [1] http://www.spinics.net/lists/linux-media/msg50562.html

Lad, Prabhakar (2):
  ARM: davinci: dm355: add support for v4l2 video display
  ARM: davinci: dm355 EVM: add support for VPBE display

 arch/arm/mach-davinci/board-dm355-evm.c |   71 +++++++++++++-
 arch/arm/mach-davinci/davinci.h         |    3 +-
 arch/arm/mach-davinci/dm355.c           |  167 ++++++++++++++++++++++++++++++-
 3 files changed, 233 insertions(+), 8 deletions(-)

-- 
1.7.4.1



From prabhakar.csengg at gmail.com  Mon Apr  8 05:26:54 2013
From: prabhakar.csengg at gmail.com (Prabhakar lad)
Date: Mon,  8 Apr 2013 14:56:54 +0530
Subject: [PATCH v8 1/2] ARM: davinci: dm355: add support for v4l2 video display
In-Reply-To: <1365413215-3632-1-git-send-email-prabhakar.csengg@gmail.com>
References: <1365413215-3632-1-git-send-email-prabhakar.csengg@gmail.com>
Message-ID: <1365413215-3632-2-git-send-email-prabhakar.csengg@gmail.com>

From: Lad, Prabhakar <prabhakar.csengg at gmail.com>

Create platform devices for various video modules like venc,osd,
vpbe and v4l2 driver for dm355.

Signed-off-by: Lad, Prabhakar <prabhakar.csengg at gmail.com>
---
 arch/arm/mach-davinci/board-dm355-evm.c |    4 +-
 arch/arm/mach-davinci/davinci.h         |    3 +-
 arch/arm/mach-davinci/dm355.c           |  167 ++++++++++++++++++++++++++++++-
 3 files changed, 166 insertions(+), 8 deletions(-)

diff --git a/arch/arm/mach-davinci/board-dm355-evm.c b/arch/arm/mach-davinci/board-dm355-evm.c
index 147b8e1..37d12cc 100644
--- a/arch/arm/mach-davinci/board-dm355-evm.c
+++ b/arch/arm/mach-davinci/board-dm355-evm.c
@@ -253,8 +253,6 @@ static struct davinci_uart_config uart_config __initdata = {
 
 static void __init dm355_evm_map_io(void)
 {
-	/* setup input configuration for VPFE input devices */
-	dm355_set_vpfe_config(&vpfe_cfg);
 	dm355_init();
 }
 
@@ -344,6 +342,8 @@ static __init void dm355_evm_init(void)
 	davinci_setup_mmc(0, &dm355evm_mmc_config);
 	davinci_setup_mmc(1, &dm355evm_mmc_config);
 
+	dm355_init_video(&vpfe_cfg, NULL);
+
 	dm355_init_spi0(BIT(0), dm355_evm_spi_info,
 			ARRAY_SIZE(dm355_evm_spi_info));
 
diff --git a/arch/arm/mach-davinci/davinci.h b/arch/arm/mach-davinci/davinci.h
index a9de512..c4d9be5 100644
--- a/arch/arm/mach-davinci/davinci.h
+++ b/arch/arm/mach-davinci/davinci.h
@@ -39,6 +39,7 @@
 #define SYSMOD_VDAC_CONFIG		0x2c
 #define SYSMOD_VIDCLKCTL		0x38
 #define SYSMOD_VPSS_CLKCTL		0x44
+#define VPSS_MUXSEL_EXTCLK_ENABLE	BIT(1)
 #define VPSS_VENCCLKEN_ENABLE		BIT(3)
 #define VPSS_DACCLKEN_ENABLE		BIT(4)
 #define VPSS_PLLC2SYSCLK5_ENABLE	BIT(5)
@@ -79,7 +80,7 @@ void __init dm355_init(void);
 void dm355_init_spi0(unsigned chipselect_mask,
 		const struct spi_board_info *info, unsigned len);
 void __init dm355_init_asp1(u32 evt_enable, struct snd_platform_data *pdata);
-void dm355_set_vpfe_config(struct vpfe_config *cfg);
+int dm355_init_video(struct vpfe_config *, struct vpbe_config *);
 
 /* DM365 function declarations */
 void __init dm365_init(void);
diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index 8e98bb0..bf9a9d4 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -35,6 +35,8 @@
 #include "asp.h"
 
 #define DM355_UART2_BASE	(IO_PHYS + 0x206000)
+#define DM355_OSD_BASE		(IO_PHYS + 0x70200)
+#define DM355_VENC_BASE		(IO_PHYS + 0x70400)
 
 /*
  * Device specific clocks
@@ -744,11 +746,146 @@ static struct platform_device vpfe_capture_dev = {
 	},
 };
 
-void dm355_set_vpfe_config(struct vpfe_config *cfg)
+static struct resource dm355_osd_resources[] = {
+	{
+		.start	= DM355_OSD_BASE,
+		.end	= DM355_OSD_BASE + 0x17f,
+		.flags	= IORESOURCE_MEM,
+	},
+};
+
+static struct platform_device dm355_osd_dev = {
+	.name		= DM355_VPBE_OSD_SUBDEV_NAME,
+	.id		= -1,
+	.num_resources	= ARRAY_SIZE(dm355_osd_resources),
+	.resource	= dm355_osd_resources,
+	.dev		= {
+		.dma_mask		= &vpfe_capture_dma_mask,
+		.coherent_dma_mask	= DMA_BIT_MASK(32),
+	},
+};
+
+static struct resource dm355_venc_resources[] = {
+	{
+		.start	= IRQ_VENCINT,
+		.end	= IRQ_VENCINT,
+		.flags	= IORESOURCE_IRQ,
+	},
+	/* venc registers io space */
+	{
+		.start	= DM355_VENC_BASE,
+		.end	= DM355_VENC_BASE + 0x17f,
+		.flags	= IORESOURCE_MEM,
+	},
+	/* VDAC config register io space */
+	{
+		.start	= DAVINCI_SYSTEM_MODULE_BASE + SYSMOD_VDAC_CONFIG,
+		.end	= DAVINCI_SYSTEM_MODULE_BASE + SYSMOD_VDAC_CONFIG + 3,
+		.flags	= IORESOURCE_MEM,
+	},
+};
+
+static struct resource dm355_v4l2_disp_resources[] = {
+	{
+		.start	= IRQ_VENCINT,
+		.end	= IRQ_VENCINT,
+		.flags	= IORESOURCE_IRQ,
+	},
+	/* venc registers io space */
+	{
+		.start	= DM355_VENC_BASE,
+		.end	= DM355_VENC_BASE + 0x17f,
+		.flags	= IORESOURCE_MEM,
+	},
+};
+
+static int dm355_vpbe_setup_pinmux(enum v4l2_mbus_pixelcode if_type,
+			    int field)
+{
+	switch (if_type) {
+	case V4L2_MBUS_FMT_SGRBG8_1X8:
+		davinci_cfg_reg(DM355_VOUT_FIELD_G70);
+		break;
+	case V4L2_MBUS_FMT_YUYV10_1X20:
+		if (field)
+			davinci_cfg_reg(DM355_VOUT_FIELD);
+		else
+			davinci_cfg_reg(DM355_VOUT_FIELD_G70);
+		break;
+	default:
+		return -EINVAL;
+	}
+
+	davinci_cfg_reg(DM355_VOUT_COUTL_EN);
+	davinci_cfg_reg(DM355_VOUT_COUTH_EN);
+
+	return 0;
+}
+
+static int dm355_venc_setup_clock(enum vpbe_enc_timings_type type,
+				   unsigned int pclock)
 {
-	vpfe_capture_dev.dev.platform_data = cfg;
+	void __iomem *vpss_clk_ctrl_reg;
+
+	vpss_clk_ctrl_reg = DAVINCI_SYSMOD_VIRT(SYSMOD_VPSS_CLKCTL);
+
+	switch (type) {
+	case VPBE_ENC_STD:
+		writel(VPSS_DACCLKEN_ENABLE | VPSS_VENCCLKEN_ENABLE,
+		       vpss_clk_ctrl_reg);
+		break;
+	case VPBE_ENC_DV_TIMINGS:
+		if (pclock > 27000000)
+			/*
+			 * For HD, use external clock source since we cannot
+			 * support HD mode with internal clocks.
+			 */
+			writel(VPSS_MUXSEL_EXTCLK_ENABLE, vpss_clk_ctrl_reg);
+		break;
+	default:
+		return -EINVAL;
+	}
+
+	return 0;
 }
 
+static struct platform_device dm355_vpbe_display = {
+	.name		= "vpbe-v4l2",
+	.id		= -1,
+	.num_resources	= ARRAY_SIZE(dm355_v4l2_disp_resources),
+	.resource	= dm355_v4l2_disp_resources,
+	.dev		= {
+		.dma_mask		= &vpfe_capture_dma_mask,
+		.coherent_dma_mask	= DMA_BIT_MASK(32),
+	},
+};
+
+struct venc_platform_data dm355_venc_pdata = {
+	.setup_pinmux	= dm355_vpbe_setup_pinmux,
+	.setup_clock	= dm355_venc_setup_clock,
+};
+
+static struct platform_device dm355_venc_dev = {
+	.name		= DM355_VPBE_VENC_SUBDEV_NAME,
+	.id		= -1,
+	.num_resources	= ARRAY_SIZE(dm355_venc_resources),
+	.resource	= dm355_venc_resources,
+	.dev		= {
+		.dma_mask		= &vpfe_capture_dma_mask,
+		.coherent_dma_mask	= DMA_BIT_MASK(32),
+		.platform_data		= (void *)&dm355_venc_pdata,
+	},
+};
+
+static struct platform_device dm355_vpbe_dev = {
+	.name		= "vpbe_controller",
+	.id		= -1,
+	.dev		= {
+		.dma_mask		= &vpfe_capture_dma_mask,
+		.coherent_dma_mask	= DMA_BIT_MASK(32),
+	},
+};
+
 /*----------------------------------------------------------------------*/
 
 static struct map_desc dm355_io_desc[] = {
@@ -868,6 +1005,29 @@ void __init dm355_init(void)
 	davinci_map_sysmod();
 }
 
+int __init dm355_init_video(struct vpfe_config *vpfe_cfg,
+				struct vpbe_config *vpbe_cfg)
+{
+	if (vpfe_cfg || vpbe_cfg)
+		platform_device_register(&dm355_vpss_device);
+
+	if (vpfe_cfg) {
+		vpfe_capture_dev.dev.platform_data = vpfe_cfg;
+		platform_device_register(&dm355_ccdc_dev);
+		platform_device_register(&vpfe_capture_dev);
+	}
+
+	if (vpbe_cfg) {
+		dm355_vpbe_dev.dev.platform_data = vpbe_cfg;
+		platform_device_register(&dm355_osd_dev);
+		platform_device_register(&dm355_venc_dev);
+		platform_device_register(&dm355_vpbe_dev);
+		platform_device_register(&dm355_vpbe_display);
+	}
+
+	return 0;
+}
+
 static int __init dm355_init_devices(void)
 {
 	if (!cpu_is_davinci_dm355())
@@ -875,9 +1035,6 @@ static int __init dm355_init_devices(void)
 
 	davinci_cfg_reg(DM355_INT_EDMA_CC);
 	platform_device_register(&dm355_edma_device);
-	platform_device_register(&dm355_vpss_device);
-	platform_device_register(&dm355_ccdc_dev);
-	platform_device_register(&vpfe_capture_dev);
 
 	return 0;
 }
-- 
1.7.4.1



From prabhakar.csengg at gmail.com  Mon Apr  8 05:26:55 2013
From: prabhakar.csengg at gmail.com (Prabhakar lad)
Date: Mon,  8 Apr 2013 14:56:55 +0530
Subject: [PATCH v8 2/2] ARM: davinci: dm355 EVM: add support for VPBE display
In-Reply-To: <1365413215-3632-1-git-send-email-prabhakar.csengg@gmail.com>
References: <1365413215-3632-1-git-send-email-prabhakar.csengg@gmail.com>
Message-ID: <1365413215-3632-3-git-send-email-prabhakar.csengg@gmail.com>

From: Lad, Prabhakar <prabhakar.csengg at gmail.com>

add support for V4L2 video display to DM355 EVM.
Support for SD modes is provided, along with Composite
output

Signed-off-by: Lad, Prabhakar <prabhakar.csengg at gmail.com>
Acked-by: Sekhar Nori <nsekhar at ti.com>
---
 arch/arm/mach-davinci/board-dm355-evm.c |   69 ++++++++++++++++++++++++++++++-
 1 files changed, 68 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-davinci/board-dm355-evm.c b/arch/arm/mach-davinci/board-dm355-evm.c
index 37d12cc..1043506 100644
--- a/arch/arm/mach-davinci/board-dm355-evm.c
+++ b/arch/arm/mach-davinci/board-dm355-evm.c
@@ -242,6 +242,73 @@ static struct vpfe_config vpfe_cfg = {
 	.ccdc = "DM355 CCDC",
 };
 
+/* venc standards timings */
+static struct vpbe_enc_mode_info dm355evm_enc_preset_timing[] = {
+	{
+		.name		= "ntsc",
+		.timings_type	= VPBE_ENC_STD,
+		.std_id		= 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,
+		.std_id		= V4L2_STD_625_50,
+		.interlaced	= 1,
+		.xres		= 720,
+		.yres		= 576,
+		.aspect		= {54, 59},
+		.fps		= {25, 1},
+		.left_margin	= 0x7E,
+		.upper_margin	= 0x16
+	},
+};
+
+#define VENC_STD_ALL	(V4L2_STD_NTSC | V4L2_STD_PAL)
+
+/*
+ * The outputs available from VPBE + ecnoders. Keep the
+ * 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 dm355evm_vpbe_outputs[] = {
+	{
+		.output		= {
+			.index		= 0,
+			.name		= "Composite",
+			.type		= V4L2_OUTPUT_TYPE_ANALOG,
+			.std		= VENC_STD_ALL,
+			.capabilities	= V4L2_OUT_CAP_STD,
+		},
+		.subdev_name	= DM355_VPBE_VENC_SUBDEV_NAME,
+		.default_mode	= "ntsc",
+		.num_modes	= ARRAY_SIZE(dm355evm_enc_preset_timing),
+		.modes		= dm355evm_enc_preset_timing,
+		.if_params	= V4L2_MBUS_FMT_FIXED,
+	},
+};
+
+static struct vpbe_config dm355evm_display_cfg = {
+	.module_name	= "dm355-vpbe-display",
+	.i2c_adapter_id	= 1,
+	.osd		= {
+		.module_name	= DM355_VPBE_OSD_SUBDEV_NAME,
+	},
+	.venc		= {
+		.module_name	= DM355_VPBE_VENC_SUBDEV_NAME,
+	},
+	.num_outputs	= ARRAY_SIZE(dm355evm_vpbe_outputs),
+	.outputs	= dm355evm_vpbe_outputs,
+};
+
 static struct platform_device *davinci_evm_devices[] __initdata = {
 	&dm355evm_dm9000,
 	&davinci_nand_device,
@@ -342,7 +409,7 @@ static __init void dm355_evm_init(void)
 	davinci_setup_mmc(0, &dm355evm_mmc_config);
 	davinci_setup_mmc(1, &dm355evm_mmc_config);
 
-	dm355_init_video(&vpfe_cfg, NULL);
+	dm355_init_video(&vpfe_cfg, &dm355evm_display_cfg);
 
 	dm355_init_spi0(BIT(0), dm355_evm_spi_info,
 			ARRAY_SIZE(dm355_evm_spi_info));
-- 
1.7.4.1



From lee.jones at linaro.org  Mon Apr  8 05:33:03 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Mon, 8 Apr 2013 10:33:03 +0100
Subject: [GIT PULL] AB8500 Power and MFD related updates
In-Reply-To: <20130408091851.GI24058@zurbaran>
References: <20130307043859.GA11944@gmail.com>
 <20130408091851.GI24058@zurbaran>
Message-ID: <20130408093303.GF3084@gmail.com>

Hi Sam,

> > The following changes since commit 6dbe51c251a327e012439c4772097a13df43c5b8:
> > 
> >   Linux 3.9-rc1 (2013-03-03 15:11:05 -0800)
> > 
> > are available in the git repository at:
> > 
> >   git://git.linaro.org/people/ljones/linux-3.0-ux500.git for-mfd-and-power
> I was expecting to get an MFD only branch (Basically what your for-mfd branch
> looks like, and then the for-mfd-and-power one to be based on the mfd only
> with the power patches applied on top of it.
> Now, I have to pull the power patches as well, which is no big deal but not
> ideal neither.

Sorry Sam, I guess I understood you differently:

"I can Ack the MFD parts, they look good to me. And then you can take
the whole thing through your tree, but I'd prefer you to do so by
pulling the branch Lee prepared for us. I want to avoid conflicts this
way."

When you said you wanted the "whole thing" to go through Anton's Tree,
I thought that's what you meant?

> Anyway, I pulled this branch into mfd-next, with a tiny conflict.

Okay, that's good.

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From mfuzzey at parkeon.com  Mon Apr  8 05:35:29 2013
From: mfuzzey at parkeon.com (Martin Fuzzey)
Date: Mon, 08 Apr 2013 11:35:29 +0200
Subject: [RFC PATCH] CLK: Allow parent clock and rate to be configured
 in DT.
In-Reply-To: <20130407132623.GP1906@pengutronix.de>
References: <20130319170933.28337.50448.stgit@localhost>
 <CAOMZO5ASkvquyzPCEGObvB5Xh9bDPTJ2zx26eOUJT_Vb36Bn3Q@mail.gmail.com>
 <CAKGA1bkWLrOs15ni=8D__BvuG6kvqkeeLZGOLrVZY9g0q0z4Bg@mail.gmail.com>
 <6581638.FPkNsv6peb@flatron> <20130407132623.GP1906@pengutronix.de>
Message-ID: <51628F61.9000300@parkeon.com>

On 07/04/13 15:26, Sascha Hauer wrote:
>
> Honestly I'm annoyed by this aswell. The devicetree contains a nice and
> complete hardware description and it seems convenient to put hardware
> related configuration data there aswell.
Yes
> The problem is that hardware description and configuration data are two
> completely different sets of data. The hardware description is static
> for a given board and should (ideally) never change. The configuration
> data instead is often usecase specific and changes over the lifetime of
> a board. The configuration data can only handle a single (or maybe a
> table of) static setup(s). It's a good way to specify a sane default or
> a very special setup, but doesn't handle the case when some OS (or
> version thereof) wants to have a static setup and another wants to
> figure out the same data dynamically.
Agreed
> For these reasons I am against throwing the two data sets into a single
> pot. Still I also want to have the devicetree way to configure some
> static setup items.
Sure but why does using the DT for both mean "throwing them into a 
single pot?"

I think we need to seperate the ideas of "DT as a container format" and 
"semantics of DT nodes".

The format is the same everywhere but the semantics could change in 
different parts of the tree.

Since the DT is a tree structure surely all we need to do is agree on a 
designated configuration root node
"linux-config" for example under which we put all configuration related 
stuff specific to linux whilst
retaining the "hardware description only" rule for the rest of the DT.

Martin




From kgene.kim at samsung.com  Mon Apr  8 05:45:20 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Mon, 08 Apr 2013 18:45:20 +0900
Subject: [PATCH] ARM: S3C24XX: Correct NR_IRQS definition for s3c2440
In-Reply-To: <201304072235.02218.heiko@sntech.de>
References: <1365366170-9682-1-git-send-email-s.nawrocki@samsung.com>
 <201304072235.02218.heiko@sntech.de>
Message-ID: <2cd501ce343d$c8efc810$5acf5830$%kim@samsung.com>

Heiko St?bner wrote:
> 
> Am Sonntag, 7. April 2013, 22:22:50 schrieb Sylwester Nawrocki:
> > Due to NR_IRQS being incorrectly defined not all IRQ domains can
> > be registered for S3C2440. It causes following errors on a s3c2440
> > SoC based board:
> >
> > NR_IRQS:89
> > S3C2440: IRQ Support
> > irq: clearing pending status 00000002
> > ------------[ cut here ]------------
> > WARNING: at kernel/irq/irqdomain.c:234 0xc0056ed0()
> > ...
> > irq: could not create irq-domain
> > ...
> > s3c2410-wdt s3c2410-wdt: failed to install irq (-22)
> > s3c2410-wdt: probe of s3c2410-wdt failed with error -22
> > ...
> > samsung-uart s3c2440-uart.0: cannot get irq 74
> >
> > Fix this by increasing NR_IRQS to at least (IRQ_S3C2443_AC97 + 1)
> > if CPU_S3C2440 is selected, so the subintc IRQ domain gets properly
> > registered.
> >
> > Cc: Heiko St?bner <heiko at sntech.de>
> > Signed-off-by: Tomasz Figa <tomasz.figa at gmail.com>
> > Signed-off-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
> 
> Thanks for testing the irq changes on another subarchitecture and fixing
> the
> glitch.
> 
> Acked-by: Heiko Stuebner <heiko at sntech.de>
> 
> 
Thanks for you guys' effort.

Applied.

- Kukjin



From sameo at linux.intel.com  Mon Apr  8 05:46:21 2013
From: sameo at linux.intel.com (Samuel Ortiz)
Date: Mon, 8 Apr 2013 11:46:21 +0200
Subject: [GIT PULL] AB8500 Power and MFD related updates
In-Reply-To: <20130408093303.GF3084@gmail.com>
References: <20130307043859.GA11944@gmail.com>
 <20130408091851.GI24058@zurbaran> <20130408093303.GF3084@gmail.com>
Message-ID: <20130408094621.GN24058@zurbaran>

On Mon, Apr 08, 2013 at 10:33:03AM +0100, Lee Jones wrote:
> > > The following changes since commit 6dbe51c251a327e012439c4772097a13df43c5b8:
> > > 
> > >   Linux 3.9-rc1 (2013-03-03 15:11:05 -0800)
> > > 
> > > are available in the git repository at:
> > > 
> > >   git://git.linaro.org/people/ljones/linux-3.0-ux500.git for-mfd-and-power
> > I was expecting to get an MFD only branch (Basically what your for-mfd branch
> > looks like, and then the for-mfd-and-power one to be based on the mfd only
> > with the power patches applied on top of it.
> > Now, I have to pull the power patches as well, which is no big deal but not
> > ideal neither.
> 
> Sorry Sam, I guess I understood you differently:
> 
> "I can Ack the MFD parts, they look good to me. And then you can take
> the whole thing through your tree, but I'd prefer you to do so by
> pulling the branch Lee prepared for us. I want to avoid conflicts this
> way."
I realize this was not very clear from me, sorry.
I meant I'm fine with Anton taking the whole thing, but by pulling from what
is your current for-mfd-and-power branch. Anton did that and that's all good.
Now, to prevent being flamed to death by Linus, I need to carry the MFD
patches from this branch as well, and that should have come from a common
for-mfd branch.
Basically, what I had in mind:

- You create a for-mfd branch with all the MFD patches need for the
  power patches to be applied properly.
- You create a for-mfd-and-power branch, where you first merge your for-mfd
  branch and then apply the power patches.
- Anton pulls from for-mfd-and-power.
- I pull from for-mfd.
- Anton and me carry the exact same set of MFD patches and regardless of who
  Linus pulls from first, it should work fine.

That should still work from your for-mfd-and-power branch, just slightly
less clean imo, as I will carry power patches I really don't need.

Cheers,
Samuel.

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


From luis.henriques at canonical.com  Mon Apr  8 05:49:16 2013
From: luis.henriques at canonical.com (Luis Henriques)
Date: Mon,  8 Apr 2013 10:49:16 +0100
Subject: [PATCH 001/102] clockevents: Don't allow dummy broadcast timers
In-Reply-To: <1365414657-29191-1-git-send-email-luis.henriques@canonical.com>
References: <1365414657-29191-1-git-send-email-luis.henriques@canonical.com>
Message-ID: <1365414657-29191-2-git-send-email-luis.henriques@canonical.com>

3.5.7.10 -stable review patch.  If anyone has any objections, please let me know.

------------------

From: Mark Rutland <mark.rutland at arm.com>

commit a7dc19b8652c862d5b7c4d2339bd3c428bd29c4a upstream.

Currently tick_check_broadcast_device doesn't reject clock_event_devices
with CLOCK_EVT_FEAT_DUMMY, and may select them in preference to real
hardware if they have a higher rating value. In this situation, the
dummy timer is responsible for broadcasting to itself, and the core
clockevents code may attempt to call non-existent callbacks for
programming the dummy, eventually leading to a panic.

This patch makes tick_check_broadcast_device always reject dummy timers,
preventing this problem.

Signed-off-by: Mark Rutland <mark.rutland at arm.com>
Cc: linux-arm-kernel at lists.infradead.org
Cc: Jon Medhurst (Tixy) <tixy at linaro.org>
Signed-off-by: Thomas Gleixner <tglx at linutronix.de>
Signed-off-by: Luis Henriques <luis.henriques at canonical.com>
---
 kernel/time/tick-broadcast.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/kernel/time/tick-broadcast.c b/kernel/time/tick-broadcast.c
index f113755..a13987a 100644
--- a/kernel/time/tick-broadcast.c
+++ b/kernel/time/tick-broadcast.c
@@ -66,7 +66,8 @@ static void tick_broadcast_start_periodic(struct clock_event_device *bc)
  */
 int tick_check_broadcast_device(struct clock_event_device *dev)
 {
-	if ((tick_broadcast_device.evtdev &&
+	if ((dev->features & CLOCK_EVT_FEAT_DUMMY) ||
+	    (tick_broadcast_device.evtdev &&
 	     tick_broadcast_device.evtdev->rating >= dev->rating) ||
 	     (dev->features & CLOCK_EVT_FEAT_C3STOP))
 		return 0;
-- 
1.8.1.2



From girishks2000 at gmail.com  Mon Apr  8 05:51:03 2013
From: girishks2000 at gmail.com (Girish KS)
Date: Mon, 8 Apr 2013 15:21:03 +0530
Subject: [PATCH V3 4/5] spi: s3c64xx: Added provision for dedicated cs pin
In-Reply-To: <20130401125744.GG18636@opensource.wolfsonmicro.com>
References: <1363157014-9615-1-git-send-email-ks.giri@samsung.com>
 <1363157014-9615-5-git-send-email-ks.giri@samsung.com>
 <20130401125744.GG18636@opensource.wolfsonmicro.com>
Message-ID: <CAKrE-Kd+YAFmteDdh3odtV+YU1=OjoMuQV9usF4NmUse+TXhTg@mail.gmail.com>

On Mon, Apr 1, 2013 at 6:27 PM, Mark Brown
<broonie at opensource.wolfsonmicro.com> wrote:
> On Wed, Mar 13, 2013 at 12:13:33PM +0530, Girish K S wrote:
>> From: Girish K S <girishks2000 at gmail.com>
>>
>> The existing driver supports gpio based /cs signal.
>> For controller's that have one device per controller,
>> the slave device's /cs signal might be internally controlled
>> by the chip select bit of slave select register. They are not
>> externally asserted/deasserted using gpio pin.
>
> Applying this patch breaks my S3C64xx based system (Cragganmore, a
> non-DT platform).  It'll break all existing non-DT platforms since...

sure will rebase and take care of the non-dt case

>
>> + * @cs_gpio: CS line status, 'true' if CS line is asserted by gpio.
>> + *        'false' if asserted by internal dedicated pin.
>>   * @line: Custom 'identity' of the CS line.
>>   *
>>   * This is per SPI-Slave Chipselect information.
>> @@ -25,6 +27,7 @@ struct platform_device;
>>   */
>>  struct s3c64xx_spi_csinfo {
>>       u8 fb_delay;
>> +     bool cs_gpio;
>>       unsigned line;
>>  };
>
> ...you've added this new cs_gpio field to the platform data but not
> updated any of the existing users (including Cragganmore).  It would
> seem better to make the default behaviour stay as per the current
> default and make the new behaviour optional but at a minimum all
> existing in-tree users need to be updated.
>
> It's also a bit odd that we end up checking cs_gpio and then using line
> in the code, it'd be more idiomatic if cs_gpio were the GPIO number.

In the original driver it was assumed that the cs line is always a gpio pin.
But the current controller that i am working on has no gpio pin for cs
selection.
All the lines to the device are internally connected. There is no
option to select
the cs signal. So cs-gpio property parsing has to skipped for this
controller, that means
cs_gpio cannot be a GPIO number. If it has to be a number then it has
to be < 0 to say
it is not gpio. Any >= 0 number implies it is a valid gpio (in reality
for this controller it is not.)

So i introduced a new member cs_gpio. I will checkout the possibility
to avoid this member.


From laurent.pinchart at ideasonboard.com  Mon Apr  8 05:56:26 2013
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Mon, 08 Apr 2013 11:56:26 +0200
Subject: [PATCH v3] irqchip: renesas-intc-irqpin: DT binding for sense
 bitfield width
In-Reply-To: <Pine.LNX.4.64.1304081002190.29945@axis700.grange>
References: <Pine.LNX.4.64.1304081002190.29945@axis700.grange>
Message-ID: <1694336.shM2ct4pzX@avalon>

Hi Guennadi,

Thanks for the patch.

On Monday 08 April 2013 10:08:40 Guennadi Liakhovetski wrote:
> Most Renesas irqpin controllers have 4-bit sense fields, however, some
> have different widths. This patch adds a DT binding to optionally
> specify such non-standard values.
> 
> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas at gmail.com>
> ---
> 
> v3: move the code to a common location, where device configuration
> parameters are retrieved
> 
>  .../interrupt-controller/renesas,intc-irqpin.txt   |   13 +++++++++++++
>  drivers/irqchip/irq-renesas-intc-irqpin.c          |    4 ++++
>  2 files changed, 17 insertions(+), 0 deletions(-)
>  create mode 100644
> Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.
> txt
> 
> diff --git
> a/Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpi
> n.txt
> b/Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpi
> n.txt new file mode 100644
> index 0000000..c6f09b7
> --- /dev/null
> +++
> b/Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpi
> n.txt @@ -0,0 +1,13 @@
> +DT bindings for the R-/SH-Mobile irqpin controller
> +
> +Required properties:
> +
> +- compatible: has to be "renesas,intc-irqpin"
> +- #interrupt-cells: has to be <2>
> +
> +Optional properties:
> +
> +- any properties, listed in interrupts.txt in this directory, and any
> standard
> +  resource allocation properties
> +- sense-bitfield-width: width of a single sense bitfield in the SENSE
> register,
> +  if different from the default 4 bits

Wouldn't it be better to define per-SoC compatible strings, and infer the 
sense bitfield width from that ?

> diff --git a/drivers/irqchip/irq-renesas-intc-irqpin.c
> b/drivers/irqchip/irq-renesas-intc-irqpin.c index 5a68e5a..4aca1b2 100644
> --- a/drivers/irqchip/irq-renesas-intc-irqpin.c
> +++ b/drivers/irqchip/irq-renesas-intc-irqpin.c
> @@ -18,6 +18,7 @@
>   */
> 
>  #include <linux/init.h>
> +#include <linux/of.h>
>  #include <linux/platform_device.h>
>  #include <linux/spinlock.h>
>  #include <linux/interrupt.h>
> @@ -349,6 +350,9 @@ static int intc_irqpin_probe(struct platform_device
> *pdev) /* deal with driver instance configuration */
>  	if (pdata)
>  		memcpy(&p->config, pdata, sizeof(*pdata));
> +	else
> +		of_property_read_u32(pdev->dev.of_node, "sense-bitfield-width",
> +				     &p->config.sense_bitfield_width);
>  	if (!p->config.sense_bitfield_width)
>  		p->config.sense_bitfield_width = 4; /* default to 4 bits */
-- 
Regards,

Laurent Pinchart



From nicolas.ferre at atmel.com  Mon Apr  8 05:57:06 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Mon, 8 Apr 2013 11:57:06 +0200
Subject: [RFC 4/5] RTC: rtc-at91sam9: add device-tree support
In-Reply-To: <20130408090023.GC25605@localhost>
References: <20130407150938.GA25605@localhost>
 <1365347572-14972-1-git-send-email-jhovold@gmail.com>
 <1365347572-14972-4-git-send-email-jhovold@gmail.com>
 <20130408073807.GQ20693@game.jcrosoft.org> <20130408090023.GC25605@localhost>
Message-ID: <51629472.3070404@atmel.com>

On 04/08/2013 11:00 AM, Johan Hovold :
> On Mon, Apr 08, 2013 at 09:38:07AM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
>> On 17:12 Sun 07 Apr     , Johan Hovold wrote:
>>> Add device-tree support.
>>>
>>> The AT91 RTT can be used as an RTC if the atmel,at91-rtt-as-rtc-gpbr
>>> property is present and set to the general-purpose backup register to
>>> use to store the RTC time base.
>>>
>>> Signed-off-by: Johan Hovold <jhovold at gmail.com>
>>> ---
>>>  .../devicetree/bindings/rtc/rtc-at91sam9.txt       | 19 ++++++++++++
>>>  drivers/rtc/rtc-at91sam9.c                         | 36 +++++++++++++++++++++-
>>>  2 files changed, 54 insertions(+), 1 deletion(-)
>>>  create mode 100644 Documentation/devicetree/bindings/rtc/rtc-at91sam9.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/rtc/rtc-at91sam9.txt b/Documentation/devicetree/bindings/rtc/rtc-at91sam9.txt
>>> new file mode 100644
>>> index 0000000..0f54988
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/rtc/rtc-at91sam9.txt
>>> @@ -0,0 +1,19 @@
>>> +Atmel AT91 RTT as RTC
>>> +=====================
>>> +
>>> +Required properties:
>>> +- compatible: Should be "atmel,at91sam9260-rtt"
>>> +- reg: Should contain register location and length
>>> +- interrupts: Should contain interrupt for the RTT which is the IRQ line
>>> +  shared across all System Controller members.
>>> +- atmel,rtt-as-rtc-gpbr: Should contain the backup-register to use to store
>>> +  the RTC time base
>>> +
>>> +Example:
>>> +
>>> +rtt at fffffd20 {
>>> +		compatible = "atmel,at91sam9g45-rtt", "atmel,at91sam9260-rtt";

No, there is no visible difference between the sam9g45 RTT and the
sam9260 one. So the most precise compatibility string is still sam9260.
If one day we feel the need for a advanced feature that exists on a more
recent SoC, we have the possibility to add it at that time...

>>> +		reg = <0xfffffd20 0x10>;
>>> +		interrupts = <1 4 7>;
>>> +		atmel,at91-rtt-as-rtc-gpbr = <0>;
>> no you miss the point of the DT
>>
>> you need to describe the hardware no a particular use of it
> 
> That was what I was trying to achieve by adding the two use-neutral
> rtt and gpbr-nodes. But then the question is how would you influence
> which out of two rtt-drivers to use?
> 
> Adding a property as above in the final board descriptions seemed
> preferable to adding rtt-as-rtc to the compatible string of the rtt as
> that would mean describing use rather than just hardware.

Well, re-reading the Device_Tree_Usage page, I found this sentence:
"
Understanding the compatible Property

Every node in the tree that represents a device is required to have the
compatible property. compatible is the key an operating system uses to
decide which device driver to bind to a device.
"
or ePARP:

"
The compatible property value consists of one or more strings that
define the specific programming model for the device.
"

We have the notion of link between hardware and software in this
*compatible* sting, even if the *node* itself is about hardware description.

>> the RTT is a general purpose timer backuped that we use in linux as a
>> RTC with a gpbr to store the time
>>
>> you need 2 binding on for the RTT one the RTT-rtc
> 
> As in adding some virtual hardware-node which uses the rtt and gpbr as
> resources?

So, why not simply having a compatibility string that collects the uses
of this RTT node:

compatible = "atmel,at91sam9260-rtt-as-rtc", "atmel,at91sam9260-rtt";

And then "decide which device driver to bind to [the RTT] device"...
If the rtt-as-rtc driver is not selected, the device can still be used
as a simple "rtt". The board .dts can overload a compatibility string
according to the use, etc.

Then the way do describe which GPBR to use has still to be discussed.
But for the RTT itself, I would keep it simple like that.

Best regards,
-- 
Nicolas Ferre


From kgene.kim at samsung.com  Mon Apr  8 05:57:33 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Mon, 08 Apr 2013 18:57:33 +0900
Subject: [PATCH] ARM: Samsung: Select ARM_CPU_SUSPEND when required
In-Reply-To: <1365366442-16025-1-git-send-email-s.nawrocki@samsung.com>
References: <1365366442-16025-1-git-send-email-s.nawrocki@samsung.com>
Message-ID: <2cd601ce343f$7d6aac50$784004f0$%kim@samsung.com>

Sylwester Nawrocki wrote:
> 
> The power management code of S3C24XX, S3C64XX, S5PV210 platform in
> arch/arm/plat-samsung/, arch/arm/mach-s3c24xx/, arch/arm/mach-s3c64xx/
> directories uses generic cpu_suspend routine. Make sure it is compiled
> in when building with power management support. Without this patch
> compilation fails with errors as below. It can be reproduced by using
> default config files with CONFIG_SUSPEND disabled and CONFIG_PM_RUNTIME
> enabled.
> 
>  - s5pv210_defconfig
>  arch/arm/plat-samsung/built-in.o: In function `s3c_pm_enter':
>  arch/arm/plat-samsung/pm.c:304: undefined reference to `cpu_suspend'
>  arch/arm/plat-samsung/built-in.o: In function `s3c_cpu_resume':
>  arch/arm/plat-samsung/s5p-sleep.S:74: undefined reference to `cpu_resume'
> 
>  - s3c24xx_defconfig
>  arch/arm/mach-s3c24xx/built-in.o: In function `s3c_cpu_resume':
>  arch/arm/mach-s3c24xx/sleep.S:83: undefined reference to `cpu_resume'
>  arch/arm/plat-samsung/built-in.o: In function `s3c_pm_enter':
>  arch/arm/plat-samsung/pm.c:304: undefined reference to `cpu_suspend'
> 
>  - s3c64xx_defconfig
>  arch/arm/mach-s3c64xx/built-in.o: In function `s3c_cpu_resume':
>  arch/arm/mach-s3c64xx/sleep.S:72: undefined reference to `cpu_resume'
>  arch/arm/plat-samsung/built-in.o: In function `s3c_pm_enter':
>  arch/arm/plat-samsung/pm.c:304: undefined reference to `cpu_suspend'
> 
> To fix this issue select ARM_CPU_SUSPEND for PLAT_SAMSUNG when PM is set.
> 
> The build break occurs for kernels at least back to v3.0, however this
> patch applies without conflicts only back to v3.7.
> 
> Signed-off-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
> Cc: stable at vger.kernel.org
> ---
>  arch/arm/plat-samsung/Kconfig |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/plat-samsung/Kconfig b/arch/arm/plat-samsung/Kconfig
> index 54d1861..02355ba 100644
> --- a/arch/arm/plat-samsung/Kconfig
> +++ b/arch/arm/plat-samsung/Kconfig
> @@ -10,6 +10,7 @@ config PLAT_SAMSUNG
>  	default y
>  	select GENERIC_IRQ_CHIP
>  	select NO_IOPORT
> +	select ARM_CPU_SUSPEND if PM
>  	help
>  	  Base platform code for all Samsung SoC based systems
> 
> --
> 1.7.4.1

Yes, right. The pm.c in plat-samsung should be built with
arch/arm/kernel/sleep.S and suspend.c.

BTW it should be shown in alphabetical order and we don't need more
following in mach-exynos.

--------8<----------------8<--------
diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index 2f45906..bc0a8b2 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -31,7 +31,6 @@ config CPU_EXYNOS4210
 	bool "SAMSUNG EXYNOS4210"
 	default y
 	depends on ARCH_EXYNOS4
-	select ARM_CPU_SUSPEND if PM
 	select PM_GENERIC_DOMAINS
 	select S5P_PM if PM
 	select S5P_SLEEP if PM
diff --git a/arch/arm/plat-samsung/Kconfig b/arch/arm/plat-samsung/Kconfig
index b708b3e..30a976d 100644
--- a/arch/arm/plat-samsung/Kconfig
+++ b/arch/arm/plat-samsung/Kconfig
@@ -8,6 +8,7 @@ config PLAT_SAMSUNG
 	Bool
 	depends on PLAT_S3C24XX || ARCH_S3C64XX || PLAT_S5P
	default y
+	select ARM_CPU_SUSPEND if PM
 	select GENERIC_IRQ_CHIP
 	select NO_IOPORT
 	help
--------8<----------------8<--------

If you have any objections, let me know.

Thanks.

- Kukjin



From amit.daniel at samsung.com  Mon Apr  8 05:57:34 2013
From: amit.daniel at samsung.com (Amit Daniel Kachhap)
Date: Mon,  8 Apr 2013 15:27:34 +0530
Subject: [RESEND PATCH V6 1/4] cpufreq: exynos: Add cpufreq driver for
 exynos5440
In-Reply-To: <CAKohpo=t_YTCTRCfnwQ+GPF=frsTGDigT3RZHJuVQ+R+YZU7Hg@mail.gmail.com>
References: <CAKohpo=t_YTCTRCfnwQ+GPF=frsTGDigT3RZHJuVQ+R+YZU7Hg@mail.gmail.com>
Message-ID: <1365415054-30771-1-git-send-email-amit.daniel@samsung.com>

This patch adds dvfs support for exynos5440 SOC. This soc has 4 cores and
they scale at same frequency. The nature of exynos5440 clock controller is
different from previous exynos controllers so not using the common exynos
cpufreq framework. The major difference being interrupt notification for
frequency change. Also, OPP library is used for device tree parsing to get
different parameters like frequency, voltage etc. Since the opp library sorts
the frequency table in ascending order so they are again re-arranged in
descending order. This will have one-to-one mapping with the clock controller
state management logic.

Cc: Viresh Kumar <viresh.kumar at linaro.org>
Cc: Rafael J. Wysocki <rjw at sisk.pl>
Cc: Kukjin Kim <kgene.kim at samsung.com>
Signed-off-by: Amit Daniel Kachhap <amit.daniel at samsung.com>
---

Re-sending this patch with a minor comment from Viresh about the correct usage
of cpufreq_notify_transition API. 

 .../bindings/cpufreq/cpufreq-exynos5440.txt        |   28 ++
 drivers/cpufreq/Kconfig.arm                        |    9 +
 drivers/cpufreq/Makefile                           |    1 +
 drivers/cpufreq/exynos5440-cpufreq.c               |  478 ++++++++++++++++++++
 4 files changed, 516 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt
 create mode 100644 drivers/cpufreq/exynos5440-cpufreq.c

diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt b/Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt
new file mode 100644
index 0000000..caff1a5
--- /dev/null
+++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt
@@ -0,0 +1,28 @@
+
+Exynos5440 cpufreq driver
+-------------------
+
+Exynos5440 SoC cpufreq driver for CPU frequency scaling.
+
+Required properties:
+- interrupts: Interrupt to know the completion of cpu frequency change.
+- operating-points: Table of frequencies and voltage CPU could be transitioned into,
+	in the decreasing order. Frequency should be in KHz units and voltage
+	should be in microvolts.
+
+Optional properties:
+- clock-latency: Clock monitor latency in microsecond.
+
+All the required listed above must be defined under node cpufreq.
+
+Example:
+--------
+	cpufreq at 160000 {
+		compatible = "samsung,exynos5440-cpufreq";
+		reg = <0x160000 0x1000>;
+		interrupts = <0 57 0>;
+		operating-points = <
+				1000000 975000
+				800000  925000>;
+		clock-latency = <100000>;
+	};
diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index f3f3b14..bce2195 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -42,6 +42,15 @@ config ARM_EXYNOS5250_CPUFREQ
 	  This adds the CPUFreq driver for Samsung EXYNOS5250
 	  SoC.
 
+config ARM_EXYNOS5440_CPUFREQ
+	def_bool SOC_EXYNOS5440
+	depends on HAVE_CLK && PM_OPP && OF
+	help
+	  This adds the CPUFreq driver for Samsung EXYNOS5440
+	  SoC. The nature of exynos5440 clock controller is
+	  different than previous exynos controllers so not using
+	  the common exynos framework.
+
 config ARM_HIGHBANK_CPUFREQ
 	tristate "Calxeda Highbank-based"
 	depends on ARCH_HIGHBANK
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index 5db1f1f..6ad0b91 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -56,6 +56,7 @@ obj-$(CONFIG_ARM_EXYNOS_CPUFREQ)	+= exynos-cpufreq.o
 obj-$(CONFIG_ARM_EXYNOS4210_CPUFREQ)	+= exynos4210-cpufreq.o
 obj-$(CONFIG_ARM_EXYNOS4X12_CPUFREQ)	+= exynos4x12-cpufreq.o
 obj-$(CONFIG_ARM_EXYNOS5250_CPUFREQ)	+= exynos5250-cpufreq.o
+obj-$(CONFIG_ARM_EXYNOS5440_CPUFREQ)	+= exynos5440-cpufreq.o
 obj-$(CONFIG_ARM_HIGHBANK_CPUFREQ)	+= highbank-cpufreq.o
 obj-$(CONFIG_ARM_IMX6Q_CPUFREQ)		+= imx6q-cpufreq.o
 obj-$(CONFIG_ARM_INTEGRATOR)		+= integrator-cpufreq.o
diff --git a/drivers/cpufreq/exynos5440-cpufreq.c b/drivers/cpufreq/exynos5440-cpufreq.c
new file mode 100644
index 0000000..ead7ed4
--- /dev/null
+++ b/drivers/cpufreq/exynos5440-cpufreq.c
@@ -0,0 +1,478 @@
+/*
+ * Copyright (c) 2013 Samsung Electronics Co., Ltd.
+ *		http://www.samsung.com
+ *
+ * Amit Daniel Kachhap <amit.daniel at samsung.com>
+ *
+ * EXYNOS5440 - CPU frequency scaling support
+ *
+ * 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/clk.h>
+#include <linux/cpu.h>
+#include <linux/cpufreq.h>
+#include <linux/err.h>
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+#include <linux/opp.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+
+/* Register definitions */
+#define XMU_DVFS_CTRL		0x0060
+#define XMU_PMU_P0_7		0x0064
+#define XMU_C0_3_PSTATE		0x0090
+#define XMU_P_LIMIT		0x00a0
+#define XMU_P_STATUS		0x00a4
+#define XMU_PMUEVTEN		0x00d0
+#define XMU_PMUIRQEN		0x00d4
+#define XMU_PMUIRQ		0x00d8
+
+/* PMU mask and shift definations */
+#define P_VALUE_MASK		0x7
+
+#define XMU_DVFS_CTRL_EN_SHIFT	0
+
+#define P0_7_CPUCLKDEV_SHIFT	21
+#define P0_7_CPUCLKDEV_MASK	0x7
+#define P0_7_ATBCLKDEV_SHIFT	18
+#define P0_7_ATBCLKDEV_MASK	0x7
+#define P0_7_CSCLKDEV_SHIFT	15
+#define P0_7_CSCLKDEV_MASK	0x7
+#define P0_7_CPUEMA_SHIFT	28
+#define P0_7_CPUEMA_MASK	0xf
+#define P0_7_L2EMA_SHIFT	24
+#define P0_7_L2EMA_MASK		0xf
+#define P0_7_VDD_SHIFT		8
+#define P0_7_VDD_MASK		0x7f
+#define P0_7_FREQ_SHIFT		0
+#define P0_7_FREQ_MASK		0xff
+
+#define C0_3_PSTATE_VALID_SHIFT	8
+#define C0_3_PSTATE_CURR_SHIFT	4
+#define C0_3_PSTATE_NEW_SHIFT	0
+
+#define PSTATE_CHANGED_EVTEN_SHIFT	0
+
+#define PSTATE_CHANGED_IRQEN_SHIFT	0
+
+#define PSTATE_CHANGED_SHIFT		0
+
+/* some constant values for clock divider calculation */
+#define CPU_DIV_FREQ_MAX	500
+#define CPU_DBG_FREQ_MAX	375
+#define CPU_ATB_FREQ_MAX	500
+
+#define PMIC_LOW_VOLT		0x30
+#define PMIC_HIGH_VOLT		0x28
+
+#define CPUEMA_HIGH		0x2
+#define CPUEMA_MID		0x4
+#define CPUEMA_LOW		0x7
+
+#define L2EMA_HIGH		0x1
+#define L2EMA_MID		0x3
+#define L2EMA_LOW		0x4
+
+#define DIV_TAB_MAX	2
+/* frequency unit is 20MHZ */
+#define FREQ_UNIT	20
+#define MAX_VOLTAGE	1550000 /* In microvolt */
+#define VOLTAGE_STEP	12500	/* In microvolt */
+
+#define CPUFREQ_NAME		"exynos5440_dvfs"
+#define DEF_TRANS_LATENCY	100000
+
+enum cpufreq_level_index {
+	L0, L1, L2, L3, L4,
+	L5, L6, L7, L8, L9,
+};
+#define CPUFREQ_LEVEL_END	(L7 + 1)
+
+struct exynos_dvfs_data {
+	void __iomem *base;
+	struct resource *mem;
+	int irq;
+	struct clk *cpu_clk;
+	unsigned int cur_frequency;
+	unsigned int latency;
+	struct cpufreq_frequency_table *freq_table;
+	unsigned int freq_count;
+	struct device *dev;
+	bool dvfs_enabled;
+	struct work_struct irq_work;
+};
+
+static struct exynos_dvfs_data *dvfs_info;
+static DEFINE_MUTEX(cpufreq_lock);
+static struct cpufreq_freqs freqs;
+
+static int init_div_table(void)
+{
+	struct cpufreq_frequency_table *freq_tbl = dvfs_info->freq_table;
+	unsigned int tmp, clk_div, ema_div, freq, volt_id;
+	int i = 0;
+	struct opp *opp;
+
+	for (i = 0; freq_tbl[i].frequency != CPUFREQ_TABLE_END; i++) {
+
+		opp = opp_find_freq_exact(dvfs_info->dev,
+					freq_tbl[i].frequency * 1000, true);
+		if (IS_ERR(opp)) {
+			dev_err(dvfs_info->dev,
+				"failed to find valid OPP for %u KHZ\n",
+				freq_tbl[i].frequency);
+			return PTR_ERR(opp);
+		}
+
+		freq = freq_tbl[i].frequency / 1000; /* In MHZ */
+		clk_div = ((freq / CPU_DIV_FREQ_MAX) & P0_7_CPUCLKDEV_MASK)
+					<< P0_7_CPUCLKDEV_SHIFT;
+		clk_div |= ((freq / CPU_ATB_FREQ_MAX) & P0_7_ATBCLKDEV_MASK)
+					<< P0_7_ATBCLKDEV_SHIFT;
+		clk_div |= ((freq / CPU_DBG_FREQ_MAX) & P0_7_CSCLKDEV_MASK)
+					<< P0_7_CSCLKDEV_SHIFT;
+
+		/* Calculate EMA */
+		volt_id = opp_get_voltage(opp);
+		volt_id = (MAX_VOLTAGE - volt_id) / VOLTAGE_STEP;
+		if (volt_id < PMIC_HIGH_VOLT) {
+			ema_div = (CPUEMA_HIGH << P0_7_CPUEMA_SHIFT) |
+				(L2EMA_HIGH << P0_7_L2EMA_SHIFT);
+		} else if (volt_id > PMIC_LOW_VOLT) {
+			ema_div = (CPUEMA_LOW << P0_7_CPUEMA_SHIFT) |
+				(L2EMA_LOW << P0_7_L2EMA_SHIFT);
+		} else {
+			ema_div = (CPUEMA_MID << P0_7_CPUEMA_SHIFT) |
+				(L2EMA_MID << P0_7_L2EMA_SHIFT);
+		}
+
+		tmp = (clk_div | ema_div | (volt_id << P0_7_VDD_SHIFT)
+			| ((freq / FREQ_UNIT) << P0_7_FREQ_SHIFT));
+
+		__raw_writel(tmp, dvfs_info->base + XMU_PMU_P0_7 + 4 * i);
+	}
+
+	return 0;
+}
+
+static void exynos_enable_dvfs(void)
+{
+	unsigned int tmp, i, cpu;
+	struct cpufreq_frequency_table *freq_table = dvfs_info->freq_table;
+	/* Disable DVFS */
+	__raw_writel(0,	dvfs_info->base + XMU_DVFS_CTRL);
+
+	/* Enable PSTATE Change Event */
+	tmp = __raw_readl(dvfs_info->base + XMU_PMUEVTEN);
+	tmp |= (1 << PSTATE_CHANGED_EVTEN_SHIFT);
+	 __raw_writel(tmp, dvfs_info->base + XMU_PMUEVTEN);
+
+	/* Enable PSTATE Change IRQ */
+	tmp = __raw_readl(dvfs_info->base + XMU_PMUIRQEN);
+	tmp |= (1 << PSTATE_CHANGED_IRQEN_SHIFT);
+	 __raw_writel(tmp, dvfs_info->base + XMU_PMUIRQEN);
+
+	/* Set initial performance index */
+	for (i = 0; freq_table[i].frequency != CPUFREQ_TABLE_END; i++)
+		if (freq_table[i].frequency == dvfs_info->cur_frequency)
+			break;
+
+	if (freq_table[i].frequency == CPUFREQ_TABLE_END) {
+		dev_crit(dvfs_info->dev, "Boot up frequency not supported\n");
+		/* Assign the highest frequency */
+		i = 0;
+		dvfs_info->cur_frequency = freq_table[i].frequency;
+	}
+
+	dev_info(dvfs_info->dev, "Setting dvfs initial frequency = %uKHZ",
+						dvfs_info->cur_frequency);
+
+	for (cpu = 0; cpu < CONFIG_NR_CPUS; cpu++) {
+		tmp = __raw_readl(dvfs_info->base + XMU_C0_3_PSTATE + cpu * 4);
+		tmp &= ~(P_VALUE_MASK << C0_3_PSTATE_NEW_SHIFT);
+		tmp |= (i << C0_3_PSTATE_NEW_SHIFT);
+		__raw_writel(tmp, dvfs_info->base + XMU_C0_3_PSTATE + cpu * 4);
+	}
+
+	/* Enable DVFS */
+	__raw_writel(1 << XMU_DVFS_CTRL_EN_SHIFT,
+				dvfs_info->base + XMU_DVFS_CTRL);
+}
+
+static int exynos_verify_speed(struct cpufreq_policy *policy)
+{
+	return cpufreq_frequency_table_verify(policy,
+					      dvfs_info->freq_table);
+}
+
+static unsigned int exynos_getspeed(unsigned int cpu)
+{
+	return dvfs_info->cur_frequency;
+}
+
+static int exynos_target(struct cpufreq_policy *policy,
+			  unsigned int target_freq,
+			  unsigned int relation)
+{
+	unsigned int index, tmp;
+	int ret = 0, i;
+	struct cpufreq_frequency_table *freq_table = dvfs_info->freq_table;
+
+	mutex_lock(&cpufreq_lock);
+
+	ret = cpufreq_frequency_table_target(policy, freq_table,
+					   target_freq, relation, &index);
+	if (ret)
+		goto out;
+
+	freqs.old = dvfs_info->cur_frequency;
+	freqs.new = freq_table[index].frequency;
+
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);
+
+	/* Set the target frequency in all C0_3_PSTATE register */
+	for_each_cpu(i, policy->cpus) {
+		tmp = __raw_readl(dvfs_info->base + XMU_C0_3_PSTATE + i * 4);
+		tmp &= ~(P_VALUE_MASK << C0_3_PSTATE_NEW_SHIFT);
+		tmp |= (index << C0_3_PSTATE_NEW_SHIFT);
+
+		__raw_writel(tmp, dvfs_info->base + XMU_C0_3_PSTATE + i * 4);
+	}
+out:
+	mutex_unlock(&cpufreq_lock);
+	return ret;
+}
+
+static void exynos_cpufreq_work(struct work_struct *work)
+{
+	unsigned int cur_pstate, index;
+	struct cpufreq_policy *policy = cpufreq_cpu_get(0); /* boot CPU */
+	struct cpufreq_frequency_table *freq_table = dvfs_info->freq_table;
+
+	/* Ensure we can access cpufreq structures */
+	if (unlikely(dvfs_info->dvfs_enabled == false))
+		goto skip_work;
+
+	mutex_lock(&cpufreq_lock);
+	freqs.old = dvfs_info->cur_frequency;
+
+	cur_pstate = __raw_readl(dvfs_info->base + XMU_P_STATUS);
+	if (cur_pstate >> C0_3_PSTATE_VALID_SHIFT & 0x1)
+		index = (cur_pstate >> C0_3_PSTATE_CURR_SHIFT) & P_VALUE_MASK;
+	else
+		index = (cur_pstate >> C0_3_PSTATE_NEW_SHIFT) & P_VALUE_MASK;
+
+	if (likely(index < dvfs_info->freq_count)) {
+		freqs.new = freq_table[index].frequency;
+		dvfs_info->cur_frequency = freqs.new;
+	} else {
+		dev_crit(dvfs_info->dev, "New frequency out of range\n");
+		freqs.new = dvfs_info->cur_frequency;
+	}
+	cpufreq_notify_transition(policy, &freqs, CPUFREQ_POSTCHANGE);
+
+	cpufreq_cpu_put(policy);
+	mutex_unlock(&cpufreq_lock);
+skip_work:
+	enable_irq(dvfs_info->irq);
+}
+
+static irqreturn_t exynos_cpufreq_irq(int irq, void *id)
+{
+	unsigned int tmp;
+
+	tmp = __raw_readl(dvfs_info->base + XMU_PMUIRQ);
+	if (tmp >> PSTATE_CHANGED_SHIFT & 0x1) {
+		__raw_writel(tmp, dvfs_info->base + XMU_PMUIRQ);
+		disable_irq_nosync(irq);
+		schedule_work(&dvfs_info->irq_work);
+	}
+	return IRQ_HANDLED;
+}
+
+static void exynos_sort_descend_freq_table(void)
+{
+	struct cpufreq_frequency_table *freq_tbl = dvfs_info->freq_table;
+	int i = 0, index;
+	unsigned int tmp_freq;
+	/*
+	 * Exynos5440 clock controller state logic expects the cpufreq table to
+	 * be in descending order. But the OPP library constructs the table in
+	 * ascending order. So to make the table descending we just need to
+	 * swap the i element with the N - i element.
+	 */
+	for (i = 0; i < dvfs_info->freq_count / 2; i++) {
+		index = dvfs_info->freq_count - i - 1;
+		tmp_freq = freq_tbl[i].frequency;
+		freq_tbl[i].frequency = freq_tbl[index].frequency;
+		freq_tbl[index].frequency = tmp_freq;
+	}
+}
+
+static int exynos_cpufreq_cpu_init(struct cpufreq_policy *policy)
+{
+	int ret;
+
+	ret = cpufreq_frequency_table_cpuinfo(policy, dvfs_info->freq_table);
+	if (ret) {
+		dev_err(dvfs_info->dev, "Invalid frequency table: %d\n", ret);
+		return ret;
+	}
+
+	policy->cur = dvfs_info->cur_frequency;
+	policy->cpuinfo.transition_latency = dvfs_info->latency;
+	cpumask_setall(policy->cpus);
+
+	cpufreq_frequency_table_get_attr(dvfs_info->freq_table, policy->cpu);
+
+	return 0;
+}
+
+static struct cpufreq_driver exynos_driver = {
+	.flags		= CPUFREQ_STICKY,
+	.verify		= exynos_verify_speed,
+	.target		= exynos_target,
+	.get		= exynos_getspeed,
+	.init		= exynos_cpufreq_cpu_init,
+	.name		= CPUFREQ_NAME,
+};
+
+static const struct of_device_id exynos_cpufreq_match[] = {
+	{
+		.compatible = "samsung,exynos5440-cpufreq",
+	},
+	{},
+};
+MODULE_DEVICE_TABLE(of, exynos_cpufreq_match);
+
+static int exynos_cpufreq_probe(struct platform_device *pdev)
+{
+	int ret = -EINVAL;
+	struct device_node *np;
+	struct resource res;
+
+	np =  pdev->dev.of_node;
+	if (!np)
+		return -ENODEV;
+
+	dvfs_info = devm_kzalloc(&pdev->dev, sizeof(*dvfs_info), GFP_KERNEL);
+	if (!dvfs_info) {
+		ret = -ENOMEM;
+		goto err_put_node;
+	}
+
+	dvfs_info->dev = &pdev->dev;
+
+	ret = of_address_to_resource(np, 0, &res);
+	if (ret)
+		goto err_put_node;
+
+	dvfs_info->base = devm_ioremap_resource(dvfs_info->dev, &res);
+	if (IS_ERR(dvfs_info->base)) {
+		ret = PTR_ERR(dvfs_info->base);
+		goto err_put_node;
+	}
+
+	dvfs_info->irq = irq_of_parse_and_map(np, 0);
+	if (!dvfs_info->irq) {
+		dev_err(dvfs_info->dev, "No cpufreq irq found\n");
+		ret = -ENODEV;
+		goto err_put_node;
+	}
+
+	ret = of_init_opp_table(dvfs_info->dev);
+	if (ret) {
+		dev_err(dvfs_info->dev, "failed to init OPP table: %d\n", ret);
+		goto err_put_node;
+	}
+
+	ret = opp_init_cpufreq_table(dvfs_info->dev, &dvfs_info->freq_table);
+	if (ret) {
+		dev_err(dvfs_info->dev,
+			"failed to init cpufreq table: %d\n", ret);
+		goto err_put_node;
+	}
+	dvfs_info->freq_count = opp_get_opp_count(dvfs_info->dev);
+	exynos_sort_descend_freq_table();
+
+	if (of_property_read_u32(np, "clock-latency", &dvfs_info->latency))
+		dvfs_info->latency = DEF_TRANS_LATENCY;
+
+	dvfs_info->cpu_clk = devm_clk_get(dvfs_info->dev, "armclk");
+	if (IS_ERR(dvfs_info->cpu_clk)) {
+		dev_err(dvfs_info->dev, "Failed to get cpu clock\n");
+		ret = PTR_ERR(dvfs_info->cpu_clk);
+		goto err_free_table;
+	}
+
+	dvfs_info->cur_frequency = clk_get_rate(dvfs_info->cpu_clk);
+	if (!dvfs_info->cur_frequency) {
+		dev_err(dvfs_info->dev, "Failed to get clock rate\n");
+		ret = -EINVAL;
+		goto err_free_table;
+	}
+	dvfs_info->cur_frequency /= 1000;
+
+	INIT_WORK(&dvfs_info->irq_work, exynos_cpufreq_work);
+	ret = devm_request_irq(dvfs_info->dev, dvfs_info->irq,
+				exynos_cpufreq_irq, IRQF_TRIGGER_NONE,
+				CPUFREQ_NAME, dvfs_info);
+	if (ret) {
+		dev_err(dvfs_info->dev, "Failed to register IRQ\n");
+		goto err_free_table;
+	}
+
+	ret = init_div_table();
+	if (ret) {
+		dev_err(dvfs_info->dev, "Failed to initialise div table\n");
+		goto err_free_table;
+	}
+
+	exynos_enable_dvfs();
+	ret = cpufreq_register_driver(&exynos_driver);
+	if (ret) {
+		dev_err(dvfs_info->dev,
+			"%s: failed to register cpufreq driver\n", __func__);
+		goto err_free_table;
+	}
+
+	of_node_put(np);
+	dvfs_info->dvfs_enabled = true;
+	return 0;
+
+err_free_table:
+	opp_free_cpufreq_table(dvfs_info->dev, &dvfs_info->freq_table);
+err_put_node:
+	of_node_put(np);
+	dev_err(dvfs_info->dev, "%s: failed initialization\n", __func__);
+	return ret;
+}
+
+static int exynos_cpufreq_remove(struct platform_device *pdev)
+{
+	cpufreq_unregister_driver(&exynos_driver);
+	opp_free_cpufreq_table(dvfs_info->dev, &dvfs_info->freq_table);
+	return 0;
+}
+
+static struct platform_driver exynos_cpufreq_platdrv = {
+	.driver = {
+		.name	= "exynos5440-cpufreq",
+		.owner	= THIS_MODULE,
+		.of_match_table = exynos_cpufreq_match,
+	},
+	.probe		= exynos_cpufreq_probe,
+	.remove		= exynos_cpufreq_remove,
+};
+module_platform_driver(exynos_cpufreq_platdrv);
+
+MODULE_AUTHOR("Amit Daniel Kachhap <amit.daniel at samsung.com>");
+MODULE_DESCRIPTION("Exynos5440 cpufreq driver");
+MODULE_LICENSE("GPL");
-- 
1.7.1



From amit.daniel at samsung.com  Mon Apr  8 05:59:22 2013
From: amit.daniel at samsung.com (amit daniel kachhap)
Date: Mon, 8 Apr 2013 15:29:22 +0530
Subject: [PATCH V6 1/4] cpufreq: exynos: Add cpufreq driver for exynos5440
In-Reply-To: <CAKohpo=t_YTCTRCfnwQ+GPF=frsTGDigT3RZHJuVQ+R+YZU7Hg@mail.gmail.com>
References: <1365409058-32643-1-git-send-email-amit.daniel@samsung.com>
 <1365409058-32643-2-git-send-email-amit.daniel@samsung.com>
 <CAKohpo=CFTo2UCnECeeuKdz34cuedV_tqn7zGA9bzU_PiJ46qg@mail.gmail.com>
 <CAKohpo=t_YTCTRCfnwQ+GPF=frsTGDigT3RZHJuVQ+R+YZU7Hg@mail.gmail.com>
Message-ID: <CADGdYn63Ck-5GXctYyvzq2V2U7Su3aHqyhrA_TgsS_krtKRcAA@mail.gmail.com>

On Mon, Apr 8, 2013 at 2:46 PM, Viresh Kumar <viresh.kumar at linaro.org> wrote:
> On 8 April 2013 14:17, Viresh Kumar <viresh.kumar at linaro.org> wrote:
>> On 8 April 2013 13:47, Amit Daniel Kachhap <amit.daniel at samsung.com> wrote:
>>
>>> diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
>>> index f3f3b14..bce2195 100644
>>> --- a/drivers/cpufreq/Kconfig.arm
>>> +++ b/drivers/cpufreq/Kconfig.arm
>>> @@ -42,6 +42,15 @@ config ARM_EXYNOS5250_CPUFREQ
>>>           This adds the CPUFreq driver for Samsung EXYNOS5250
>>>           SoC.
>>>
>>> +config ARM_EXYNOS5440_CPUFREQ
>>> +       def_bool SOC_EXYNOS5440
>>> +       depends on HAVE_CLK && PM_OPP && OF
>>
>> Don't you need a depend on your Soc or mach or arch? Don't send another
>> version for this now.. Just send a new patch over this patchset.
>
> Sorry, i overlooked def_bool... This comments stands invalid.
Ok, I resend this patch addressing all comments.

Thanks,
Amit
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From linfeng at cn.fujitsu.com  Mon Apr  8 05:56:38 2013
From: linfeng at cn.fujitsu.com (Lin Feng)
Date: Mon, 8 Apr 2013 17:56:38 +0800
Subject: [PATCH 0/2] mm: vmemmap: add vmemmap_verify check for hot-add
 node/memory case
Message-ID: <1365415000-10389-1-git-send-email-linfeng@cn.fujitsu.com>

In hot add node(memory) case, vmemmap pages are always allocated from other
node, but the current logic just skip vmemmap_verify check. 
So we should also issue "potential offnode page_structs" warning messages
if we are the case

Lin Feng (2):
  mm: vmemmap: x86: add vmemmap_verify check for hot-add node case
  mm: vmemmap: arm64: add vmemmap_verify check for hot-add node case

 arch/arm64/mm/mmu.c   | 4 ++--
 arch/x86/mm/init_64.c | 6 ++++--
 2 files changed, 6 insertions(+), 4 deletions(-)

-- 
1.8.0.1



From linfeng at cn.fujitsu.com  Mon Apr  8 05:56:40 2013
From: linfeng at cn.fujitsu.com (Lin Feng)
Date: Mon, 8 Apr 2013 17:56:40 +0800
Subject: [PATCH 2/2] mm: vmemmap: arm64: add vmemmap_verify check for hot-add
 node case
In-Reply-To: <1365415000-10389-1-git-send-email-linfeng@cn.fujitsu.com>
References: <1365415000-10389-1-git-send-email-linfeng@cn.fujitsu.com>
Message-ID: <1365415000-10389-3-git-send-email-linfeng@cn.fujitsu.com>

In hot add node(memory) case, vmemmap pages are always allocated from other
node, but the current logic just skip vmemmap_verify check. 
So we should also issue "potential offnode page_structs" warning messages
if we are the case.

Cc: Christoph Lameter <cl at linux.com>
Cc: Catalin Marinas <catalin.marinas at arm.com>
Cc: Will Deacon <will.deacon at arm.com>
Cc: Arnd Bergmann <arnd at arndb.de>
Cc: Tony Lindgren <tony at atomide.com>
Cc: Ben Hutchings <ben at decadent.org.uk>
Cc: Andrew Morton <akpm at linux-foundation.org>
Reported-by: Yasuaki Ishimatsu <isimatu.yasuaki at jp.fujitsu.com>
Signed-off-by: Lin Feng <linfeng at cn.fujitsu.com>
---
 arch/arm64/mm/mmu.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 70b8cd4..9f1e417 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -427,8 +427,8 @@ int __meminit vmemmap_populate(struct page *start_page,
 				return -ENOMEM;
 
 			set_pmd(pmd, __pmd(__pa(p) | prot_sect_kernel));
-		} else
-			vmemmap_verify((pte_t *)pmd, node, addr, next);
+		}
+		vmemmap_verify((pte_t *)pmd, node, addr, next);
 	} while (addr = next, addr != end);
 
 	return 0;
-- 
1.8.0.1



From linfeng at cn.fujitsu.com  Mon Apr  8 05:56:39 2013
From: linfeng at cn.fujitsu.com (Lin Feng)
Date: Mon, 8 Apr 2013 17:56:39 +0800
Subject: [PATCH 1/2] mm: vmemmap: x86: add vmemmap_verify check for hot-add
 node case
In-Reply-To: <1365415000-10389-1-git-send-email-linfeng@cn.fujitsu.com>
References: <1365415000-10389-1-git-send-email-linfeng@cn.fujitsu.com>
Message-ID: <1365415000-10389-2-git-send-email-linfeng@cn.fujitsu.com>

In hot add node(memory) case, vmemmap pages are always allocated from other
node, but the current logic just skip vmemmap_verify check.
So we should also issue "potential offnode page_structs" warning messages
if we are the case.

Cc: Christoph Lameter <cl at linux.com>
Cc: Thomas Gleixner <tglx at linutronix.de>
Cc: Ingo Molnar <mingo at redhat.com>
Cc: "H. Peter Anvin" <hpa at zytor.com>
Cc: Yinghai Lu <yinghai at kernel.org>
Cc: Andrew Morton <akpm at linux-foundation.org>
Reported-by: Yasuaki Ishimatsu <isimatu.yasuaki at jp.fujitsu.com>
Signed-off-by: Lin Feng <linfeng at cn.fujitsu.com>
---
 arch/x86/mm/init_64.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index 474e28f..e2a7277 100644
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -1318,6 +1318,8 @@ vmemmap_populate(struct page *start_page, unsigned long size, int node)
 			if (!p)
 				return -ENOMEM;
 
+			vmemmap_verify((pte_t *)p, node, addr, addr + PAGE_SIZE);
+
 			addr_end = addr + PAGE_SIZE;
 			p_end = p + PAGE_SIZE;
 		} else {
@@ -1347,8 +1349,8 @@ vmemmap_populate(struct page *start_page, unsigned long size, int node)
 
 				addr_end = addr + PMD_SIZE;
 				p_end = p + PMD_SIZE;
-			} else
-				vmemmap_verify((pte_t *)pmd, node, addr, next);
+			}
+			vmemmap_verify((pte_t *)pmd, node, addr, next);
 		}
 
 	}
-- 
1.8.0.1



From viresh.kumar at linaro.org  Mon Apr  8 06:00:45 2013
From: viresh.kumar at linaro.org (Viresh Kumar)
Date: Mon, 8 Apr 2013 15:30:45 +0530
Subject: [PATCH V6 0/4] cpufreq: exynos5440: support for cpufreq driver
In-Reply-To: <1365409058-32643-1-git-send-email-amit.daniel@samsung.com>
References: <1365409058-32643-1-git-send-email-amit.daniel@samsung.com>
Message-ID: <CAKohpo==g5AvKdNpi49P6t8TP4i-2pDtNZ30iRyip+mXF8uKEQ@mail.gmail.com>

On 8 April 2013 13:47, Amit Daniel Kachhap <amit.daniel at samsung.com> wrote:
> Submitting the V6 version of exynos5440 cpufreq driver. This patchset addresses
> all the coding and design concerns raised especially by Viresh.
>
> Changes in V6:
> * Used cpufreq post-change notifier call back in case of failure as pointed by
>   Viresh.
> * Called cpufreq_frequency_table_cpuinfo before calling
>   cpufreq_frequency_table_get_attr as pointed by Viresh.
> * Used modified API cpufreq_notify_transition.
>
> Changes in V5:
> * Removed the unnecessary DT look up entry from mach-exynos5-dt.c.
> * Fixed all coding and comments issue raised by Viresh.
>
> Changes in V4:
> * Added dev_err logs instead of pr_err.
> * Used the devm_ioremap_resource API.
> * Implemented several coding guidelines and minor error comments from Sylwester,
>   Russell and Viresh.
>
> Changes in V3:
> * Converted the driver to probe based as suggested by Viresh. This is also
>   beneficial for multiplatform kernel.
> * Other coding guidelines related changes.
> * Moved the DT node outside cpu0 node as the driver is now a platform
>   driver.
>
> Changes in V2:
> * Added OPP library support to parse DT parameters.
> * Removed a hack to handle interrupts in bootup.
> * Implemented other review comments from Viresh and Inder.
>
> All these patches are dependent on Thomas Abraham common clock patches.
> (http://www.mail-archive.com/linux-samsung-soc at vger.kernel.org/msg15860.html)
> This whole patch series is based on Rafael tree.
> git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git bleeding-edge
>
> Amit Daniel Kachhap (4):
>   cpufreq: exynos: Add cpufreq driver for exynos5440
>   cpufreq: exynos: Remove error return even if no soc is found
>   arm: exynos: Enable OPP library support for exynos5440
>   arm: dts: Add cpufreq controller node for Exynos5440 SoC
>
>  .../bindings/cpufreq/cpufreq-exynos5440.txt        |   28 ++
>  arch/arm/boot/dts/exynos5440.dtsi                  |   12 +
>  arch/arm/mach-exynos/Kconfig                       |    2 +
>  drivers/cpufreq/Kconfig.arm                        |    9 +
>  drivers/cpufreq/Makefile                           |    1 +
>  drivers/cpufreq/exynos-cpufreq.c                   |    2 +-
>  drivers/cpufreq/exynos5440-cpufreq.c               |  479 ++++++++++++++++++++
>  7 files changed, 532 insertions(+), 1 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt
>  create mode 100644 drivers/cpufreq/exynos5440-cpufreq.c

With the resent of 1/4,

Acked-by: Viresh Kumar <viresh.kumar at linaro.org>


From kgene.kim at samsung.com  Mon Apr  8 06:01:02 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Mon, 08 Apr 2013 19:01:02 +0900
Subject: [PATCH] ARM: S3C24XX: Remove unused GPIO drive strength register
 definitions
In-Reply-To: <1365366588-19517-1-git-send-email-s.nawrocki@samsung.com>
References: <1365366588-19517-1-git-send-email-s.nawrocki@samsung.com>
Message-ID: <2cd801ce343f$fa20a330$ee61e990$%kim@samsung.com>

Sylwester Nawrocki wrote:
> 
> There is currently no users of these definitions so remove them.
> 
> Signed-off-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
> ---
>  arch/arm/mach-s3c24xx/regs-dsc.h |  203 +--------------------------------
> -----
>  1 files changed, 4 insertions(+), 199 deletions(-)
> 
Thanks for your cleanup ;-)

Applied.

- Kukjin



From plagnioj at jcrosoft.com  Mon Apr  8 06:03:01 2013
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Mon, 8 Apr 2013 12:03:01 +0200
Subject: [RFC 4/5] RTC: rtc-at91sam9: add device-tree support
In-Reply-To: <51629472.3070404@atmel.com>
References: <20130407150938.GA25605@localhost>
 <1365347572-14972-1-git-send-email-jhovold@gmail.com>
 <1365347572-14972-4-git-send-email-jhovold@gmail.com>
 <20130408073807.GQ20693@game.jcrosoft.org>
 <20130408090023.GC25605@localhost> <51629472.3070404@atmel.com>
Message-ID: <20130408100301.GS20693@game.jcrosoft.org>

On 11:57 Mon 08 Apr     , Nicolas Ferre wrote:
> On 04/08/2013 11:00 AM, Johan Hovold :
> > On Mon, Apr 08, 2013 at 09:38:07AM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> >> On 17:12 Sun 07 Apr     , Johan Hovold wrote:
> >>> Add device-tree support.
> >>>
> >>> The AT91 RTT can be used as an RTC if the atmel,at91-rtt-as-rtc-gpbr
> >>> property is present and set to the general-purpose backup register to
> >>> use to store the RTC time base.
> >>>
> >>> Signed-off-by: Johan Hovold <jhovold at gmail.com>
> >>> ---
> >>>  .../devicetree/bindings/rtc/rtc-at91sam9.txt       | 19 ++++++++++++
> >>>  drivers/rtc/rtc-at91sam9.c                         | 36 +++++++++++++++++++++-
> >>>  2 files changed, 54 insertions(+), 1 deletion(-)
> >>>  create mode 100644 Documentation/devicetree/bindings/rtc/rtc-at91sam9.txt
> >>>
> >>> diff --git a/Documentation/devicetree/bindings/rtc/rtc-at91sam9.txt b/Documentation/devicetree/bindings/rtc/rtc-at91sam9.txt
> >>> new file mode 100644
> >>> index 0000000..0f54988
> >>> --- /dev/null
> >>> +++ b/Documentation/devicetree/bindings/rtc/rtc-at91sam9.txt
> >>> @@ -0,0 +1,19 @@
> >>> +Atmel AT91 RTT as RTC
> >>> +=====================
> >>> +
> >>> +Required properties:
> >>> +- compatible: Should be "atmel,at91sam9260-rtt"
> >>> +- reg: Should contain register location and length
> >>> +- interrupts: Should contain interrupt for the RTT which is the IRQ line
> >>> +  shared across all System Controller members.
> >>> +- atmel,rtt-as-rtc-gpbr: Should contain the backup-register to use to store
> >>> +  the RTC time base
> >>> +
> >>> +Example:
> >>> +
> >>> +rtt at fffffd20 {
> >>> +		compatible = "atmel,at91sam9g45-rtt", "atmel,at91sam9260-rtt";
> 
> No, there is no visible difference between the sam9g45 RTT and the
> sam9260 one. So the most precise compatibility string is still sam9260.
> If one day we feel the need for a advanced feature that exists on a more
> recent SoC, we have the possibility to add it at that time...
> 
> >>> +		reg = <0xfffffd20 0x10>;
> >>> +		interrupts = <1 4 7>;
> >>> +		atmel,at91-rtt-as-rtc-gpbr = <0>;
> >> no you miss the point of the DT
> >>
> >> you need to describe the hardware no a particular use of it
> > 
> > That was what I was trying to achieve by adding the two use-neutral
> > rtt and gpbr-nodes. But then the question is how would you influence
> > which out of two rtt-drivers to use?
> > 
> > Adding a property as above in the final board descriptions seemed
> > preferable to adding rtt-as-rtc to the compatible string of the rtt as
> > that would mean describing use rather than just hardware.
> 
> Well, re-reading the Device_Tree_Usage page, I found this sentence:
> "
> Understanding the compatible Property
> 
> Every node in the tree that represents a device is required to have the
> compatible property. compatible is the key an operating system uses to
> decide which device driver to bind to a device.
> "
> or ePARP:
> 
> "
> The compatible property value consists of one or more strings that
> define the specific programming model for the device.
> "
> 
> We have the notion of link between hardware and software in this
> *compatible* sting, even if the *node* itself is about hardware description.
> 
> >> the RTT is a general purpose timer backuped that we use in linux as a
> >> RTC with a gpbr to store the time
> >>
> >> you need 2 binding on for the RTT one the RTT-rtc
> > 
> > As in adding some virtual hardware-node which uses the rtt and gpbr as
> > resources?
> 
> So, why not simply having a compatibility string that collects the uses
> of this RTT node:
> 
> compatible = "atmel,at91sam9260-rtt-as-rtc", "atmel,at91sam9260-rtt";
> 
> And then "decide which device driver to bind to [the RTT] device"...
> If the rtt-as-rtc driver is not selected, the device can still be used
> as a simple "rtt". The board .dts can overload a compatibility string
> according to the use, etc.
> 
> Then the way do describe which GPBR to use has still to be discussed.
> But for the RTT itself, I would keep it simple like that.

no as infact the rtc-at91sam9 should not even exist
as this is much more generic

we use a backped register and a timer to emulate a RTC this can be unsed by
any one

and I can use any backuped timer

we need to have frameworks
where the gpbr are tracked and the rtt

	for you describe the resources

	rtt0: rtt at fffffd20 {
		compatible = "atmel,at91sam9260-rtt";
		reg = <0xfffffd20 0x10>;
		interrupts = <1 4 7>;
	};

	rtc-timer {
		compatible = "linux,rtc-timer";
		timer = <&rtt0>;
		backuped-register = <&gpbr 0>;
	};

this need to SoC implemetation generic


From plagnioj at jcrosoft.com  Mon Apr  8 06:04:17 2013
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Mon, 8 Apr 2013 12:04:17 +0200
Subject: [RFC 1/5] ARM: at91: add general purpose backup register
 (GPBR) support
In-Reply-To: <20130408084618.GB25605@localhost>
References: <20130407150938.GA25605@localhost>
 <1365347572-14972-1-git-send-email-jhovold@gmail.com>
 <20130408073329.GO20693@game.jcrosoft.org>
 <20130408084618.GB25605@localhost>
Message-ID: <20130408100417.GT20693@game.jcrosoft.org>

On 10:46 Mon 08 Apr     , Johan Hovold wrote:
> On Mon, Apr 08, 2013 at 09:33:29AM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > On 17:12 Sun 07 Apr     , Johan Hovold wrote:
> > > 
> > > Add General Purpose Backup Register (GPBR) support.
> > > 
> > > Most at91 SoCs have at least four 32-bit General Purpose Backup
> > > Registers (GPBR) powered by backup-power (VDDBU). One such register is
> > > currently used by rtc-at91sam9 driver to store the RTC time base.
> > > 
> > > Make sure the registers are mapped by arch setup code and add generic
> > > accessors for in-kernel use.
> > > 
> > > This is a step in adding device-tree support to the rtc-at91sam9 driver.
> > > 
> > This is a regression
> > 
> > we loose the tracking of what request and use the GPBR
> 
> Implementing the GPBR accessors using a simple global resource was one
> quick way forward to decouple and generalise the GPBR. Of course, this
> could be turned into a more elaborate framework or driver where
> registers are requested and released by other drivers and possibly also
> by user-space.
yes must as we used on SAMA5 to pass the boot source from the firstage of the boot
loader to the other software


From broonie at opensource.wolfsonmicro.com  Mon Apr  8 06:15:30 2013
From: broonie at opensource.wolfsonmicro.com (Mark Brown)
Date: Mon, 8 Apr 2013 11:15:30 +0100
Subject: [PATCH V3 4/5] spi: s3c64xx: Added provision for dedicated cs pin
In-Reply-To: <CAKrE-Kd+YAFmteDdh3odtV+YU1=OjoMuQV9usF4NmUse+TXhTg@mail.gmail.com>
References: <1363157014-9615-1-git-send-email-ks.giri@samsung.com>
 <1363157014-9615-5-git-send-email-ks.giri@samsung.com>
 <20130401125744.GG18636@opensource.wolfsonmicro.com>
 <CAKrE-Kd+YAFmteDdh3odtV+YU1=OjoMuQV9usF4NmUse+TXhTg@mail.gmail.com>
Message-ID: <20130408101530.GC9243@opensource.wolfsonmicro.com>

On Mon, Apr 08, 2013 at 03:21:03PM +0530, Girish KS wrote:
> On Mon, Apr 1, 2013 at 6:27 PM, Mark Brown

> > It's also a bit odd that we end up checking cs_gpio and then using line
> > in the code, it'd be more idiomatic if cs_gpio were the GPIO number.

> In the original driver it was assumed that the cs line is always a gpio pin.
> But the current controller that i am working on has no gpio pin for cs
> selection.
> All the lines to the device are internally connected. There is no
> option to select
> the cs signal. So cs-gpio property parsing has to skipped for this
> controller, that means
> cs_gpio cannot be a GPIO number. If it has to be a number then it has
> to be < 0 to say
> it is not gpio. Any >= 0 number implies it is a valid gpio (in reality
> for this controller it is not.)

Two options here, one is to just assume nobody will use GPIO 0 and the
other is to set the number appopriately during probe so that only probe
needs to worry about the issue.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130408/8343d432/attachment.sig>

From viresh.kumar at linaro.org  Mon Apr  8 06:19:18 2013
From: viresh.kumar at linaro.org (Viresh Kumar)
Date: Mon, 8 Apr 2013 15:49:18 +0530
Subject: [PATCH 2/3] CLK: uninline clk_prepare_enable() and
 clk_disable_unprepare()
In-Reply-To: <20121217054240.GA13300@core.coreip.homeip.net>
References: <1353403339-11679-1-git-send-email-dmitry.torokhov@gmail.com>
 <1353403339-11679-3-git-send-email-dmitry.torokhov@gmail.com>
 <CAKohpomA=vSGuKfD-_zwiSnXGkqAQjtiVqxT2Po=D-LDA_FESg@mail.gmail.com>
 <20121216115756.GO14363@n2100.arm.linux.org.uk>
 <CAKohpok7Lh_ozuBFZdObpPRj0u_B-MNqgWjmaaSik3v4SmgJcw@mail.gmail.com>
 <20121216124013.GP14363@n2100.arm.linux.org.uk>
 <CAKohpom37Liqhz38YthaL9q+iFh4=iYHoUmrTOMq2=Ut-D0Dhg@mail.gmail.com>
 <20121217054240.GA13300@core.coreip.homeip.net>
Message-ID: <CAKohponJ5n6Vr56nFJT7nXX5ByOCFHDET7-E_=xsfGK80X3jag@mail.gmail.com>

On 17 December 2012 11:12, Dmitry Torokhov <dmitry.torokhov at gmail.com> wrote:
> They do not _have_ to be non-inline, I think we should simply drop the
> first 2 patches and I will refresh and ressend the 3rd one.

I haven't seen this patch since a long time? Any updates?


From linfeng at cn.fujitsu.com  Mon Apr  8 06:23:16 2013
From: linfeng at cn.fujitsu.com (Lin Feng)
Date: Mon, 08 Apr 2013 18:23:16 +0800
Subject: [PATCH 1/2] mm: vmemmap: x86: add vmemmap_verify check for hot-add
 node case
In-Reply-To: <1365415000-10389-2-git-send-email-linfeng@cn.fujitsu.com>
References: <1365415000-10389-1-git-send-email-linfeng@cn.fujitsu.com>
 <1365415000-10389-2-git-send-email-linfeng@cn.fujitsu.com>
Message-ID: <51629A94.5000200@cn.fujitsu.com>

Hi all,

On 04/08/2013 05:56 PM, Lin Feng wrote:
> diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
> index 474e28f..e2a7277 100644
> --- a/arch/x86/mm/init_64.c
> +++ b/arch/x86/mm/init_64.c
> @@ -1318,6 +1318,8 @@ vmemmap_populate(struct page *start_page, unsigned long size, int node)
>  			if (!p)
>  				return -ENOMEM;
>  
> +			vmemmap_verify((pte_t *)p, node, addr, addr + PAGE_SIZE);
> +
>  			addr_end = addr + PAGE_SIZE;
>  			p_end = p + PAGE_SIZE;
>  		} else {
IIUC it seems that the original 'p_end = p + PAGE_SIZE' assignment is buggy, because:

1309                 if (!cpu_has_pse) {
1310                         next = (addr + PAGE_SIZE) & PAGE_MASK;
1311                         pmd = vmemmap_pmd_populate(pud, addr, node);
1312 
1313                         if (!pmd)
1314                                 return -ENOMEM;
1315 
1316                         p = vmemmap_pte_populate(pmd, addr, node);
1317 
1318                         if (!p)
1319                                 return -ENOMEM;
1320 
1321                         addr_end = addr + PAGE_SIZE;
1322                         p_end = p + PAGE_SIZE;

The return value of vmemmap_pte_populate() is the virtual address of pte, not the allocated
virtual address, which is different from vmemmap_alloc_block_buf() in cpu_has_pse case, so
the addition PAGE_SIZE in !cpu_has_pse case is nonsense.

Or am I missing something?

thanks,
linfeng


From nsekhar at ti.com  Mon Apr  8 06:26:05 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Mon, 8 Apr 2013 15:56:05 +0530
Subject: [PATCH v2 1/3] media: davinci: vpss: enable vpss clocks
In-Reply-To: <1364903044-13752-2-git-send-email-prabhakar.csengg@gmail.com>
References: <1364903044-13752-1-git-send-email-prabhakar.csengg@gmail.com>
 <1364903044-13752-2-git-send-email-prabhakar.csengg@gmail.com>
Message-ID: <51629B3D.4080905@ti.com>

On 4/2/2013 5:14 PM, Prabhakar lad wrote:
> From: Lad, Prabhakar <prabhakar.csengg at gmail.com>
> 
> By default the VPSS clocks were enabled in capture driver
> for davinci family which creates duplicates for dm355/dm365/dm644x.
> This patch adds support to enable the VPSS clocks in VPSS driver,
> which avoids duplication of code and also adding clock aliases.
> 
> This patch uses PM runtime API to enable/disable instead common clock
> framework. con_ids for master and slave clocks of vpss is added in pm_domain

Common clock framework in not (yet) used on DaVinci, so this is misleading.

> diff --git a/arch/arm/mach-davinci/pm_domain.c b/arch/arm/mach-davinci/pm_domain.c
> index c90250e..445b10b 100644
> --- a/arch/arm/mach-davinci/pm_domain.c
> +++ b/arch/arm/mach-davinci/pm_domain.c
> @@ -53,7 +53,7 @@ static struct dev_pm_domain davinci_pm_domain = {
>  
>  static struct pm_clk_notifier_block platform_bus_notifier = {
>  	.pm_domain = &davinci_pm_domain,
> -	.con_ids = { "fck", NULL, },
> +	.con_ids = { "fck", "master", "slave", NULL, },

NULL is sentinel so you can drop the ',' after that. Apart from that,
for the mach-davinci parts:

Acked-by: Sekhar Nori <nsekhar at ti.com>

Thanks,
Sekhar


From s.nawrocki at samsung.com  Mon Apr  8 06:27:34 2013
From: s.nawrocki at samsung.com (Sylwester Nawrocki)
Date: Mon, 08 Apr 2013 12:27:34 +0200
Subject: [PATCH] ARM: Samsung: Select ARM_CPU_SUSPEND when required
In-Reply-To: <2cd601ce343f$7d6aac50$784004f0$%kim@samsung.com>
References: <1365366442-16025-1-git-send-email-s.nawrocki@samsung.com>
 <2cd601ce343f$7d6aac50$784004f0$%kim@samsung.com>
Message-ID: <51629B96.9050504@samsung.com>

On 04/08/2013 11:57 AM, Kukjin Kim wrote:
> Sylwester Nawrocki wrote:
[...]
> Yes, right. The pm.c in plat-samsung should be built with
> arch/arm/kernel/sleep.S and suspend.c.
> 
> BTW it should be shown in alphabetical order and we don't need more
> following in mach-exynos.
> 
> --------8<----------------8<--------
> diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
> index 2f45906..bc0a8b2 100644
> --- a/arch/arm/mach-exynos/Kconfig
> +++ b/arch/arm/mach-exynos/Kconfig
> @@ -31,7 +31,6 @@ config CPU_EXYNOS4210
>  	bool "SAMSUNG EXYNOS4210"
>  	default y
>  	depends on ARCH_EXYNOS4
> -	select ARM_CPU_SUSPEND if PM
>  	select PM_GENERIC_DOMAINS
>  	select S5P_PM if PM
>  	select S5P_SLEEP if PM
> diff --git a/arch/arm/plat-samsung/Kconfig b/arch/arm/plat-samsung/Kconfig
> index b708b3e..30a976d 100644
> --- a/arch/arm/plat-samsung/Kconfig
> +++ b/arch/arm/plat-samsung/Kconfig
> @@ -8,6 +8,7 @@ config PLAT_SAMSUNG
>  	Bool
>  	depends on PLAT_S3C24XX || ARCH_S3C64XX || PLAT_S5P
> 	default y
> +	select ARM_CPU_SUSPEND if PM
>  	select GENERIC_IRQ_CHIP
>  	select NO_IOPORT
>  	help
> --------8<----------------8<--------
> 
> If you have any objections, let me know.

Yes, this looks better. However after posting this patch I noticed linker
errors in some builds due to undefined cpu_arm920_do_suspend,
cpu_arm920_do_resume routines.

It seems it is because various cpu_*_do_suspend routines are selected by
CONFIG_PM_SLEEP.  And the PM code in arch/arm/mach-s3c24xx, arch/arm/mach-
s3c64xx is selected by CONFIG_PM.

$ git grep -1 "ENTRY(cpu_.*_do_suspend"
arch/arm/mm/proc-arm920.S-#ifdef CONFIG_PM_SLEEP
arch/arm/mm/proc-arm920.S:ENTRY(cpu_arm920_do_suspend)
arch/arm/mm/proc-arm920.S-      stmfd   sp!, {r4 - r6, lr}
--
arch/arm/mm/proc-arm926.S-#ifdef CONFIG_PM_SLEEP
arch/arm/mm/proc-arm926.S:ENTRY(cpu_arm926_do_suspend)
arch/arm/mm/proc-arm926.S-      stmfd   sp!, {r4 - r6, lr}
--
arch/arm/mm/proc-mohawk.S-#ifdef CONFIG_PM_SLEEP
arch/arm/mm/proc-mohawk.S:ENTRY(cpu_mohawk_do_suspend)
arch/arm/mm/proc-mohawk.S-      stmfd   sp!, {r4 - r9, lr}
--
arch/arm/mm/proc-sa1100.S-#ifdef CONFIG_PM_SLEEP
arch/arm/mm/proc-sa1100.S:ENTRY(cpu_sa1100_do_suspend)
arch/arm/mm/proc-sa1100.S-      stmfd   sp!, {r4 - r6, lr}
--
arch/arm/mm/proc-v6.S-#ifdef CONFIG_PM_SLEEP
arch/arm/mm/proc-v6.S:ENTRY(cpu_v6_do_suspend)
arch/arm/mm/proc-v6.S-  stmfd   sp!, {r4 - r9, lr}
--
arch/arm/mm/proc-v7.S-#ifdef CONFIG_ARM_CPU_SUSPEND
arch/arm/mm/proc-v7.S:ENTRY(cpu_v7_do_suspend)
arch/arm/mm/proc-v7.S-  stmfd   sp!, {r4 - r10, lr}
--
arch/arm/mm/proc-xsc3.S-#ifdef CONFIG_PM_SLEEP
arch/arm/mm/proc-xsc3.S:ENTRY(cpu_xsc3_do_suspend)
arch/arm/mm/proc-xsc3.S-        stmfd   sp!, {r4 - r9, lr}
--
arch/arm/mm/proc-xscale.S-#ifdef CONFIG_PM_SLEEP
arch/arm/mm/proc-xscale.S:ENTRY(cpu_xscale_do_suspend)
arch/arm/mm/proc-xscale.S-      stmfd   sp!, {r4 - r9, lr}

However I can't reproduce it now :-/ Anyway the $subject patch fixes
the main issue, which I can easily reproduce here as well. So I'll
prepare another patch if needed when I get back to this later.

Thanks,
Sylwester


From nsekhar at ti.com  Mon Apr  8 06:36:24 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Mon, 8 Apr 2013 16:06:24 +0530
Subject: [PATCH v8 0/2] ARM: davinci: dm355: add support for vpbe display
In-Reply-To: <1365413215-3632-1-git-send-email-prabhakar.csengg@gmail.com>
References: <1365413215-3632-1-git-send-email-prabhakar.csengg@gmail.com>
Message-ID: <51629DA8.3040806@ti.com>

On 4/8/2013 2:56 PM, Prabhakar lad wrote:
> From: Lad, Prabhakar <prabhakar.csengg at gmail.com>
> 
> This patch series enables VPBE display driver on DM355.

These (this and the DM365 one) patches look good to me. I need to get an
immutable branch from Mauro where dependencies are queued and then I can
generate a pull request for these for ARM SoC.

Thanks,
Sekhar



From rjw at sisk.pl  Mon Apr  8 06:46:38 2013
From: rjw at sisk.pl (Rafael J. Wysocki)
Date: Mon, 08 Apr 2013 12:46:38 +0200
Subject: [PATCH 07/18] cpufreq: s3c24xx: move cpufreq driver to
 drivers/cpufreq
In-Reply-To: <2ccd01ce3439$911b51b0$b351f510$%kim@samsung.com>
References: <cover.1365079581.git.viresh.kumar@linaro.org>
 <1769336.FkfMpuXqqb@vostro.rjw.lan>
 <2ccd01ce3439$911b51b0$b351f510$%kim@samsung.com>
Message-ID: <2166815.0SZ6SYhSDN@vostro.rjw.lan>

On Monday, April 08, 2013 06:15:09 PM Kukjin Kim wrote:
> Rafael J. Wysocki wrote:
> > 
> > On Friday, April 05, 2013 12:36:34 PM Viresh Kumar wrote:
> > > On 5 April 2013 12:18, Kukjin Kim <kgene.kim at samsung.com> wrote:
> > > > Basically, this moving looks good to me, but should be re-worked based
> > on
> > > > for-next of samsung tree because this touches too many samsung stuff
> > so this
> > > > should be sent to upstream via samsung tree.
> > >
> > > Hmm... Its already applied in Rafael's tree. But it doesn't mean that
> > > it can't be
> > > moved to your tree if there is a issue.
> > 
> > Well, I'm dropping it.  Please merge via the Samsung tree.
> > 
> OK, I will.
> 
> I got patch file from Viresh, and there is a sign from Rafael,
> but it should be ack. So Rafael, let me use your ack on this patch when
> I apply. If any problems, please let me know.

Since it was signed-off by me before, you can assume it's been ACKed as well.

Thanks,
Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.


From jhovold at gmail.com  Mon Apr  8 06:38:47 2013
From: jhovold at gmail.com (Johan Hovold)
Date: Mon, 8 Apr 2013 12:38:47 +0200
Subject: [RFC 4/5] RTC: rtc-at91sam9: add device-tree support
In-Reply-To: <51629472.3070404@atmel.com>
References: <20130407150938.GA25605@localhost>
 <1365347572-14972-1-git-send-email-jhovold@gmail.com>
 <1365347572-14972-4-git-send-email-jhovold@gmail.com>
 <20130408073807.GQ20693@game.jcrosoft.org>
 <20130408090023.GC25605@localhost> <51629472.3070404@atmel.com>
Message-ID: <20130408103847.GE25605@localhost>

On Mon, Apr 08, 2013 at 11:57:06AM +0200, Nicolas Ferre wrote:
> On 04/08/2013 11:00 AM, Johan Hovold :
> > On Mon, Apr 08, 2013 at 09:38:07AM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> >> On 17:12 Sun 07 Apr     , Johan Hovold wrote:
> >>> Add device-tree support.
> >>>
> >>> The AT91 RTT can be used as an RTC if the atmel,at91-rtt-as-rtc-gpbr
> >>> property is present and set to the general-purpose backup register to
> >>> use to store the RTC time base.
> >>>
> >>> Signed-off-by: Johan Hovold <jhovold at gmail.com>
> >>> ---
> >>>  .../devicetree/bindings/rtc/rtc-at91sam9.txt       | 19 ++++++++++++
> >>>  drivers/rtc/rtc-at91sam9.c                         | 36 +++++++++++++++++++++-
> >>>  2 files changed, 54 insertions(+), 1 deletion(-)
> >>>  create mode 100644 Documentation/devicetree/bindings/rtc/rtc-at91sam9.txt > >>>
> >>> diff --git
> >>> a/Documentation/devicetree/bindings/rtc/rtc-at91sam9.txt
> >>> b/Documentation/devicetree/bindings/rtc/rtc-at91sam9.txt > >>> new
> >>> file mode 100644
> >>> index 0000000..0f54988
> >>> --- /dev/null
> >>> +++ b/Documentation/devicetree/bindings/rtc/rtc-at91sam9.txt
> >>> @@ -0,0 +1,19 @@
> >>> +Atmel AT91 RTT as RTC
> >>> +=====================
> >>> +
> >>> +Required properties:
> >>> +- compatible: Should be "atmel,at91sam9260-rtt"
> >>> +- reg: Should contain register location and length
> >>> +- interrupts: Should contain interrupt for the RTT which is the IRQ line
> >>> +  shared across all System Controller members.
> >>> +- atmel,rtt-as-rtc-gpbr: Should contain the backup-register to use to store
> >>> +  the RTC time base
> >>> +
> >>> +Example:
> >>> +
> >>> +rtt at fffffd20 {
> >>> +		compatible = "atmel,at91sam9g45-rtt", "atmel,at91sam9260-rtt";
> 
> No, there is no visible difference between the sam9g45 RTT and the
> sam9260 one. So the most precise compatibility string is still sam9260.
> If one day we feel the need for a advanced feature that exists on a more
> recent SoC, we have the possibility to add it at that time...

Yes, this should be just "atmel,at91sam9260-rtt" to follow the current
practise in AT91. However, as I mentioned in an earlier mail one could
interpret

	"The first string in the list specifies the exact device that
	the node represents in the form "<manufacturer>,<model>". The
	following strings represent other devices that the device is
	compatible with.

	For example, the Freescale MPC8349 System on Chip (SoC) has a
	serial device which implements the National Semiconductor
	ns16550 register interface. The compatible property for the
	MPC8349 serial device should therefore be: compatible =
	"fsl,mpc8349-uart", "ns16550". In this case, fsl,mpc8349-uart
	specifies the exact device, and ns16550 states that it is
	register-level compatible with a National Semiconductor 16550
	UART."

	http://www.devicetree.org/Device_Tree_Usage#Understanding_the_compatible_Property

to mean that the compatible property should always be exact SoC-IP
followed by the first (most generic) compatible one.

> >>> +		reg = <0xfffffd20 0x10>;
> >>> +		interrupts = <1 4 7>;
> >>> +		atmel,at91-rtt-as-rtc-gpbr = <0>;
> >> no you miss the point of the DT
> >>
> >> you need to describe the hardware no a particular use of it
> > 
> > That was what I was trying to achieve by adding the two use-neutral
> > rtt and gpbr-nodes. But then the question is how would you influence
> > which out of two rtt-drivers to use?
> > 
> > Adding a property as above in the final board descriptions seemed
> > preferable to adding rtt-as-rtc to the compatible string of the rtt as
> > that would mean describing use rather than just hardware.
> 
> Well, re-reading the Device_Tree_Usage page, I found this sentence:
> "
> Understanding the compatible Property
> 
> Every node in the tree that represents a device is required to have the
> compatible property. compatible is the key an operating system uses to
> decide which device driver to bind to a device.
> "
> or ePARP:
> 
> "
> The compatible property value consists of one or more strings that
> define the specific programming model for the device.
> "
> 
> We have the notion of link between hardware and software in this
> *compatible* sting, even if the *node* itself is about hardware description.
> 
> >> the RTT is a general purpose timer backuped that we use in linux as a
> >> RTC with a gpbr to store the time
> >>
> >> you need 2 binding on for the RTT one the RTT-rtc
> > 
> > As in adding some virtual hardware-node which uses the rtt and gpbr as
> > resources?
> 
> So, why not simply having a compatibility string that collects the uses
> of this RTT node:
> 
> compatible = "atmel,at91sam9260-rtt-as-rtc", "atmel,at91sam9260-rtt";
> 
> And then "decide which device driver to bind to [the RTT] device"...
> If the rtt-as-rtc driver is not selected, the device can still be used
> as a simple "rtt". The board .dts can overload a compatibility string
> according to the use, etc.
> 
> Then the way do describe which GPBR to use has still to be discussed.
> But for the RTT itself, I would keep it simple like that.

Yes, this would also work but it just appears to me that it would
violate the above mentioned description of the compatible property:

	"The first string in the list specifies the exact device that
	the node represents in the form "<manufacturer>,<model>". The
	following strings represent other devices that the device is
	compatible with."

Thanks,
Johan


From kgene.kim at samsung.com  Mon Apr  8 06:41:29 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Mon, 08 Apr 2013 19:41:29 +0900
Subject: [PATCH 07/18] cpufreq: s3c24xx: move cpufreq driver to
 drivers/cpufreq
In-Reply-To: <2166815.0SZ6SYhSDN@vostro.rjw.lan>
References: <cover.1365079581.git.viresh.kumar@linaro.org>
 <1769336.FkfMpuXqqb@vostro.rjw.lan>
 <2ccd01ce3439$911b51b0$b351f510$%kim@samsung.com>
 <2166815.0SZ6SYhSDN@vostro.rjw.lan>
Message-ID: <2cf001ce3445$a115eec0$e341cc40$%kim@samsung.com>

Rafael J. Wysocki wrote:

[...]

> > >
> > > Well, I'm dropping it.  Please merge via the Samsung tree.
> > >
> > OK, I will.
> >
> > I got patch file from Viresh, and there is a sign from Rafael,
> > but it should be ack. So Rafael, let me use your ack on this patch when
> > I apply. If any problems, please let me know.
> 
> Since it was signed-off by me before, you can assume it's been ACKed as
> well.
> 
Thanks.

- Kukjin



From nicolas.ferre at atmel.com  Mon Apr  8 06:42:06 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Mon, 8 Apr 2013 12:42:06 +0200
Subject: [RFC 4/5] RTC: rtc-at91sam9: add device-tree support
In-Reply-To: <20130408100301.GS20693@game.jcrosoft.org>
References: <20130407150938.GA25605@localhost>
 <1365347572-14972-1-git-send-email-jhovold@gmail.com>
 <1365347572-14972-4-git-send-email-jhovold@gmail.com>
 <20130408073807.GQ20693@game.jcrosoft.org> <20130408090023.GC25605@localhost>
 <51629472.3070404@atmel.com> <20130408100301.GS20693@game.jcrosoft.org>
Message-ID: <51629EFE.9000508@atmel.com>

On 04/08/2013 12:03 PM, Jean-Christophe PLAGNIOL-VILLARD :
> On 11:57 Mon 08 Apr     , Nicolas Ferre wrote:
>> On 04/08/2013 11:00 AM, Johan Hovold :
>>> On Mon, Apr 08, 2013 at 09:38:07AM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
>>>> On 17:12 Sun 07 Apr     , Johan Hovold wrote:
>>>>> Add device-tree support.
>>>>>
>>>>> The AT91 RTT can be used as an RTC if the atmel,at91-rtt-as-rtc-gpbr
>>>>> property is present and set to the general-purpose backup register to
>>>>> use to store the RTC time base.
>>>>>
>>>>> Signed-off-by: Johan Hovold <jhovold at gmail.com>
>>>>> ---
>>>>>  .../devicetree/bindings/rtc/rtc-at91sam9.txt       | 19 ++++++++++++
>>>>>  drivers/rtc/rtc-at91sam9.c                         | 36 +++++++++++++++++++++-
>>>>>  2 files changed, 54 insertions(+), 1 deletion(-)
>>>>>  create mode 100644 Documentation/devicetree/bindings/rtc/rtc-at91sam9.txt
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/rtc/rtc-at91sam9.txt b/Documentation/devicetree/bindings/rtc/rtc-at91sam9.txt
>>>>> new file mode 100644
>>>>> index 0000000..0f54988
>>>>> --- /dev/null
>>>>> +++ b/Documentation/devicetree/bindings/rtc/rtc-at91sam9.txt
>>>>> @@ -0,0 +1,19 @@
>>>>> +Atmel AT91 RTT as RTC
>>>>> +=====================
>>>>> +
>>>>> +Required properties:
>>>>> +- compatible: Should be "atmel,at91sam9260-rtt"
>>>>> +- reg: Should contain register location and length
>>>>> +- interrupts: Should contain interrupt for the RTT which is the IRQ line
>>>>> +  shared across all System Controller members.
>>>>> +- atmel,rtt-as-rtc-gpbr: Should contain the backup-register to use to store
>>>>> +  the RTC time base
>>>>> +
>>>>> +Example:
>>>>> +
>>>>> +rtt at fffffd20 {
>>>>> +		compatible = "atmel,at91sam9g45-rtt", "atmel,at91sam9260-rtt";
>>
>> No, there is no visible difference between the sam9g45 RTT and the
>> sam9260 one. So the most precise compatibility string is still sam9260.
>> If one day we feel the need for a advanced feature that exists on a more
>> recent SoC, we have the possibility to add it at that time...
>>
>>>>> +		reg = <0xfffffd20 0x10>;
>>>>> +		interrupts = <1 4 7>;
>>>>> +		atmel,at91-rtt-as-rtc-gpbr = <0>;
>>>> no you miss the point of the DT
>>>>
>>>> you need to describe the hardware no a particular use of it
>>>
>>> That was what I was trying to achieve by adding the two use-neutral
>>> rtt and gpbr-nodes. But then the question is how would you influence
>>> which out of two rtt-drivers to use?
>>>
>>> Adding a property as above in the final board descriptions seemed
>>> preferable to adding rtt-as-rtc to the compatible string of the rtt as
>>> that would mean describing use rather than just hardware.
>>
>> Well, re-reading the Device_Tree_Usage page, I found this sentence:
>> "
>> Understanding the compatible Property
>>
>> Every node in the tree that represents a device is required to have the
>> compatible property. compatible is the key an operating system uses to
>> decide which device driver to bind to a device.
>> "
>> or ePARP:
>>
>> "
>> The compatible property value consists of one or more strings that
>> define the specific programming model for the device.
>> "
>>
>> We have the notion of link between hardware and software in this
>> *compatible* sting, even if the *node* itself is about hardware description.
>>
>>>> the RTT is a general purpose timer backuped that we use in linux as a
>>>> RTC with a gpbr to store the time
>>>>
>>>> you need 2 binding on for the RTT one the RTT-rtc
>>>
>>> As in adding some virtual hardware-node which uses the rtt and gpbr as
>>> resources?
>>
>> So, why not simply having a compatibility string that collects the uses
>> of this RTT node:
>>
>> compatible = "atmel,at91sam9260-rtt-as-rtc", "atmel,at91sam9260-rtt";
>>
>> And then "decide which device driver to bind to [the RTT] device"...
>> If the rtt-as-rtc driver is not selected, the device can still be used
>> as a simple "rtt". The board .dts can overload a compatibility string
>> according to the use, etc.
>>
>> Then the way do describe which GPBR to use has still to be discussed.
>> But for the RTT itself, I would keep it simple like that.
> 
> no as infact the rtc-at91sam9 should not even exist
> as this is much more generic
> 
> we use a backped register and a timer to emulate a RTC this can be unsed by
> any one
> 
> and I can use any backuped timer
> 
> we need to have frameworks

Is it possible to focus on the current problem instead of calling for
the creation for Yet Another Framework?

> where the gpbr are tracked and the rtt
> 
> 	for you describe the resources
> 
> 	rtt0: rtt at fffffd20 {
> 		compatible = "atmel,at91sam9260-rtt";
> 		reg = <0xfffffd20 0x10>;
> 		interrupts = <1 4 7>;
> 	};
> 
> 	rtc-timer {
> 		compatible = "linux,rtc-timer";
> 		timer = <&rtt0>;
> 		backuped-register = <&gpbr 0>;
> 	};
> 
> this need to SoC implemetation generic

OMG, so well, we will have to re-write the whole rtc-at91sam9 now??!! Oh
yes, I see, we do not have more urgent things to do...

Please stop trying re-inventing things that will do everything but
solving the real issues: why not agree on a sort term solution about
this rtt/rtc thing: I have *never* heard complains about this precise
driver. And we must concentrate now on problem solving.

Bye,
-- 
Nicolas Ferre


From santosh.shilimkar at ti.com  Mon Apr  8 06:48:51 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Mon, 8 Apr 2013 16:18:51 +0530
Subject: [PATCH v3 2/4] ARM: OMAP4+: PM: Consolidate OMAP4 PM code to
 re-use it for OMAP5
In-Reply-To: <20130405213433.GF10155@atomide.com>
References: <1365166743-5940-1-git-send-email-santosh.shilimkar@ti.com>
 <1365166743-5940-3-git-send-email-santosh.shilimkar@ti.com>
 <20130405213433.GF10155@atomide.com>
Message-ID: <5162A093.7090808@ti.com>

On Saturday 06 April 2013 03:04 AM, Tony Lindgren wrote:
> * Santosh Shilimkar <santosh.shilimkar at ti.com> [130405 06:01]:
>> OMAP5 has backward compatible PRCM block and it's programming
>> model is mostly similar to OMAP4. Same is going to be maintained
>> for future OMAP4 based SOCs. Hence consolidate the OMAP4 power
>> management code so that it can be re-used on OMAP5 and later devices.
>>
>> While at it, update the kernel-doc for omap4_pm_init().
>>
>> Acked-by: Nishanth Menon <nm at ti.com>
>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
>> ---
>>  arch/arm/mach-omap2/Makefile                       |    9 +--
>>  arch/arm/mach-omap2/{pm44xx.c => pm_omap4plus.c}   |   58 ++++++++++++++++----
>>  .../mach-omap2/{sleep44xx.S => sleep_omap4plus.S}  |    0
>>  3 files changed, 53 insertions(+), 14 deletions(-)
>>  rename arch/arm/mach-omap2/{pm44xx.c => pm_omap4plus.c} (83%)
>>  rename arch/arm/mach-omap2/{sleep44xx.S => sleep_omap4plus.S} (100%)
> 
> I suggest you leave out the rename. That just adds churn and has
> flame potential.
> 
OK. I can leave that mow but have to do renames anyways when
I add OMAP5 support. OMAP54XX support inside pm44xx.c and sleep44x.S
will be really odd.

Let me know if you have concern on renaming it while OMAP5 support
gets added ?

Regards,
Santosh



From s.nawrocki at samsung.com  Mon Apr  8 06:48:41 2013
From: s.nawrocki at samsung.com (Sylwester Nawrocki)
Date: Mon, 08 Apr 2013 12:48:41 +0200
Subject: [PATCH 0/3] clk: Exynos: Register audio subsytem clocks using
 common clk framework
In-Reply-To: <CAAgF-Be1Hvkt=BDK913KTu66M4izxbuOuORQ8hyT-GZR1+ABnQ@mail.gmail.com>
References: <1365144043-17101-1-git-send-email-padma.v@samsung.com>
 <515EC996.8030904@samsung.com>
 <CAAgF-Be1Hvkt=BDK913KTu66M4izxbuOuORQ8hyT-GZR1+ABnQ@mail.gmail.com>
Message-ID: <5162A089.4030405@samsung.com>

Hi,

On 04/06/2013 12:16 PM, Padma Venkat wrote:
> On Fri, Apr 5, 2013 at 6:24 PM, Sylwester Nawrocki
> <s.nawrocki at samsung.com> wrote:
>>
>> From a brief look Exynos4 and Exynos5 Audio Subsystem CLKCON very similar.
>> I've just found bit 2 of 0x0381_0008 register is not used on Exynos5250.
> 
> I added bit 2 as i2s_bus gate clock or you are pointing to something else?

Sorry, I should have written "bit 1".

>> Additionally the Audio Subsystem Clock controller is present on S5PV210
>> SoCs and IMO compatible property you used is too generic. I would propose
>> to use at least:
>>
>> "samsung,s5pv210-audss-clock"    - for S5PV210
>> "samsung,exynos4210-audss-clock" - for Exynos4
>> "samsung,exynos5250-audss-clock" - for Exynos5
> 
> Different compatible names means different driver files for exynos4 and 5??

No, it would be same driver but with multiple entries in the of_match_table.

> I haven't seen any difference between Exynos4 and Exynos5 audio subsystem.
> Can't we maintain one for both? If any extra clock instance is added
> on newer SoCs
> anyway it gets added at the end of the list of clocks. Please correct
> me if I am wrong.

Sure, the differences between Exynos4 and Exynos5 audio subsystem are very
minor ones. So we could easily use one clock driver for those. Probably same
driver can be used for S5PV210, an any differences could be handled in the
driver based on the compatible property.


Thanks,
Sylwester

-- 
Sylwester Nawrocki
Samsung Poland R&D Center


From jhovold at gmail.com  Mon Apr  8 06:48:23 2013
From: jhovold at gmail.com (Johan Hovold)
Date: Mon, 8 Apr 2013 12:48:23 +0200
Subject: [RFC 4/5] RTC: rtc-at91sam9: add device-tree support
In-Reply-To: <20130408100301.GS20693@game.jcrosoft.org>
References: <20130407150938.GA25605@localhost>
 <1365347572-14972-1-git-send-email-jhovold@gmail.com>
 <1365347572-14972-4-git-send-email-jhovold@gmail.com>
 <20130408073807.GQ20693@game.jcrosoft.org>
 <20130408090023.GC25605@localhost> <51629472.3070404@atmel.com>
 <20130408100301.GS20693@game.jcrosoft.org>
Message-ID: <20130408104823.GF25605@localhost>

On Mon, Apr 08, 2013 at 12:03:01PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 11:57 Mon 08 Apr     , Nicolas Ferre wrote:
> > On 04/08/2013 11:00 AM, Johan Hovold :
> > > On Mon, Apr 08, 2013 at 09:38:07AM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > >> On 17:12 Sun 07 Apr     , Johan Hovold wrote:

[...]

> > >> the RTT is a general purpose timer backuped that we use in linux as a
> > >> RTC with a gpbr to store the time
> > >>
> > >> you need 2 binding on for the RTT one the RTT-rtc
> > > 
> > > As in adding some virtual hardware-node which uses the rtt and gpbr as
> > > resources?
> > 
> > So, why not simply having a compatibility string that collects the uses
> > of this RTT node:
> > 
> > compatible = "atmel,at91sam9260-rtt-as-rtc", "atmel,at91sam9260-rtt";
> > 
> > And then "decide which device driver to bind to [the RTT] device"...
> > If the rtt-as-rtc driver is not selected, the device can still be used
> > as a simple "rtt". The board .dts can overload a compatibility string
> > according to the use, etc.
> > 
> > Then the way do describe which GPBR to use has still to be discussed.
> > But for the RTT itself, I would keep it simple like that.
> 
> no as infact the rtc-at91sam9 should not even exist
> as this is much more generic
> 
> we use a backped register and a timer to emulate a RTC this can be unsed by
> any one
> 
> and I can use any backuped timer
> 
> we need to have frameworks
> where the gpbr are tracked and the rtt
> 
> 	for you describe the resources
> 
> 	rtt0: rtt at fffffd20 {
> 		compatible = "atmel,at91sam9260-rtt";
> 		reg = <0xfffffd20 0x10>;
> 		interrupts = <1 4 7>;
> 	};
> 
> 	rtc-timer {
> 		compatible = "linux,rtc-timer";
> 		timer = <&rtt0>;
> 		backuped-register = <&gpbr 0>;
> 	};
> 
> this need to SoC implemetation generic

This would indeed be a neat solution, albeit one that requires a lot
work to be realised as both a backup-register and backed-up-timer
framework would need to be implemented.

Thanks,
Johan


From mchehab at redhat.com  Mon Apr  8 06:56:06 2013
From: mchehab at redhat.com (Mauro Carvalho Chehab)
Date: Mon, 8 Apr 2013 07:56:06 -0300
Subject: [PATCH v8 0/2] ARM: davinci: dm355: add support for vpbe display
In-Reply-To: <51629DA8.3040806@ti.com>
References: <1365413215-3632-1-git-send-email-prabhakar.csengg@gmail.com>
 <51629DA8.3040806@ti.com>
Message-ID: <20130408075606.5a59d32c@redhat.com>

Hi Sekhar,

Em Mon, 8 Apr 2013 16:06:24 +0530
Sekhar Nori <nsekhar at ti.com> escreveu:

> On 4/8/2013 2:56 PM, Prabhakar lad wrote:
> > From: Lad, Prabhakar <prabhakar.csengg at gmail.com>
> > 
> > This patch series enables VPBE display driver on DM355.
> 
> These (this and the DM365 one) patches look good to me. I need to get an
> immutable branch from Mauro where dependencies are queued and then I can
> generate a pull request for these for ARM SoC.

Are you mean a branch at the media development tree for you to sent
pull requests for me? If so, just use the "master" branch at the media
tree:
	http://git.linuxtv.org/media_tree.git

The master branch there is never rebased. I'll likely start to have
topic branches on the next Kernel cycle, also at the same tree.

Regards,
Mauro


From will.deacon at arm.com  Mon Apr  8 06:55:57 2013
From: will.deacon at arm.com (Will Deacon)
Date: Mon, 8 Apr 2013 11:55:57 +0100
Subject: [PATCH 2/2] mm: vmemmap: arm64: add vmemmap_verify check for
 hot-add node case
In-Reply-To: <1365415000-10389-3-git-send-email-linfeng@cn.fujitsu.com>
References: <1365415000-10389-1-git-send-email-linfeng@cn.fujitsu.com>
 <1365415000-10389-3-git-send-email-linfeng@cn.fujitsu.com>
Message-ID: <20130408105556.GB17476@mudshark.cambridge.arm.com>

Hello,

On Mon, Apr 08, 2013 at 10:56:40AM +0100, Lin Feng wrote:
> In hot add node(memory) case, vmemmap pages are always allocated from other
> node, but the current logic just skip vmemmap_verify check. 
> So we should also issue "potential offnode page_structs" warning messages
> if we are the case.
> 
> Cc: Christoph Lameter <cl at linux.com>
> Cc: Catalin Marinas <catalin.marinas at arm.com>
> Cc: Will Deacon <will.deacon at arm.com>
> Cc: Arnd Bergmann <arnd at arndb.de>
> Cc: Tony Lindgren <tony at atomide.com>
> Cc: Ben Hutchings <ben at decadent.org.uk>
> Cc: Andrew Morton <akpm at linux-foundation.org>
> Reported-by: Yasuaki Ishimatsu <isimatu.yasuaki at jp.fujitsu.com>
> Signed-off-by: Lin Feng <linfeng at cn.fujitsu.com>
> ---
>  arch/arm64/mm/mmu.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index 70b8cd4..9f1e417 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -427,8 +427,8 @@ int __meminit vmemmap_populate(struct page *start_page,
>  				return -ENOMEM;
>  
>  			set_pmd(pmd, __pmd(__pa(p) | prot_sect_kernel));
> -		} else
> -			vmemmap_verify((pte_t *)pmd, node, addr, next);
> +		}
> +		vmemmap_verify((pte_t *)pmd, node, addr, next);
>  	} while (addr = next, addr != end);
>  
>  	return 0;

Given that we don't have NUMA support or memory-hotplug on arm64 yet, I'm
not sure that this change makes much sense at the moment. early_pfn_to_nid
will always return 0 and we only ever have one node.

To be honest, I'm not sure what that vmemmap_verify check is trying to
achieve anyway. ia64 does some funky node affinity initialisation early on
but, for the rest of us, it looks like we always just check the distance
from node 0.

Will


From plagnioj at jcrosoft.com  Mon Apr  8 06:55:15 2013
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Mon, 8 Apr 2013 12:55:15 +0200
Subject: [RFC v2 PATCH] at_hdmac: move to generic DMA binding
In-Reply-To: <1365403409-18381-1-git-send-email-ludovic.desroches@atmel.com>
References: <1365403409-18381-1-git-send-email-ludovic.desroches@atmel.com>
Message-ID: <20130408105515.GU20693@game.jcrosoft.org>

On 08:43 Mon 08 Apr     , ludovic.desroches at atmel.com wrote:
> From: Ludovic Desroches <ludovic.desroches at atmel.com>
> 
> Signed-off-by: Ludovic Desroches <ludovic.desroches at atmel.com>
> ---
> 
> Hi,
> 
> Here is a second try to move at_hdmac to generic DMA binding. I have updated
> bindings according to Arnd comments ie I have removed chunk transfer size.
> 
> I have added the implementation but I am not very happy with the translation
> function. I have tried to not break old stuff: slave ask for a channel giving
> an atslave structure (passed through pdata) as a parameter for the filter
> function which saves this structure into chan->private. Then chan->private
> contains the configuration for the channel CFG register which is done when
> calling device_alloc_chan_resources.
> 
> If I allocate the atslave structure in the xlate function, where should be the
> right place to deallocate it? For the moment, I choose to add the atslave
> structure to the at_dma_chan structure but I am not happy with writing the
> channel configuration register into the xlate function. I would like to keep
> the same path as before.
so allow with devm_
> 
> Regards
> 
> Ludovic
> 
> 
>  .../devicetree/bindings/dma/atmel-dma.txt          | 27 +++++++-
>  arch/arm/boot/dts/sama5d3.dtsi                     |  2 +
>  drivers/dma/at_hdmac.c                             | 71 ++++++++++++++++++++--
>  drivers/dma/at_hdmac_regs.h                        |  7 +++
>  4 files changed, 99 insertions(+), 8 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/dma/atmel-dma.txt b/Documentation/devicetree/bindings/dma/atmel-dma.txt
> index 3c046ee..2d6f0f3 100644
> --- a/Documentation/devicetree/bindings/dma/atmel-dma.txt
> +++ b/Documentation/devicetree/bindings/dma/atmel-dma.txt
> @@ -4,11 +4,34 @@ Required properties:
>  - compatible: Should be "atmel,<chip>-dma"
>  - reg: Should contain DMA registers location and length
>  - interrupts: Should contain DMA interrupt
> +- #dma-cells: Must be <2>
>  
> -Examples:
> +Example:
>  
> -dma at ffffec00 {
> +dma0: dma at ffffec00 {
>  	compatible = "atmel,at91sam9g45-dma";
>  	reg = <0xffffec00 0x200>;
>  	interrupts = <21>;
> +	#dma-cells = <2>;
> +};
> +
> +DMA clients connected to the Atmel DMA controller must use the format
> +described in the dma.txt file, using a three-cell specifier for each channel.
> +The three cells in order are:
> +
> +1. A phandle pointing to the DMA controller
> +2. The memory interface (16 most significant bits), the peripheral interface
> +(16 less significant bits)
> +3. The peripheral identifier (can be different for tx and rx)
> +
> +Example:
> +
> +i2c0 at i2c@f8010000 {
> +	compatible = "atmel,at91sam9x5-i2c";
> +	reg = <0xf8010000 0x100>;
> +	interrupts = <9 4 6>;
> +	dmas = <&dma0 1 7>,
> +	       <&dma0 1 8>;
> +	dma-names = "tx", "rx"
>  };
> diff --git a/arch/arm/boot/dts/sama5d3.dtsi b/arch/arm/boot/dts/sama5d3.dtsi
> index 39b0458..9232143 100644
> --- a/arch/arm/boot/dts/sama5d3.dtsi
> +++ b/arch/arm/boot/dts/sama5d3.dtsi
> @@ -349,6 +349,7 @@
>  				reg = <0xffffe600 0x200>;
>  				interrupts = <30 4 0>;
>  				#dma-cells = <1>;
> +				#dma-cells = <2>;
??

2 dma-cells?
>  			};
>  
>  			dma1: dma-controller at ffffe800 {
> @@ -356,6 +357,7 @@
>  				reg = <0xffffe800 0x200>;
>  				interrupts = <31 4 0>;
>  				#dma-cells = <1>;
> +				#dma-cells = <2>;
ditto
>  			};
>  
>  			ramc0: ramc at ffffea00 {
> diff --git a/drivers/dma/at_hdmac.c b/drivers/dma/at_hdmac.c
> index 8415467..ec7f561 100644
> --- a/drivers/dma/at_hdmac.c
> +++ b/drivers/dma/at_hdmac.c
> @@ -24,6 +24,7 @@
>  #include <linux/slab.h>
>  #include <linux/of.h>
>  #include <linux/of_device.h>
> +#include <linux/of_dma.h>
>  
>  #include "at_hdmac_regs.h"
>  #include "dmaengine.h"
> @@ -676,7 +677,7 @@ atc_prep_slave_sg(struct dma_chan *chan, struct scatterlist *sgl,
>  		ctrlb |=  ATC_DST_ADDR_MODE_FIXED
>  			| ATC_SRC_ADDR_MODE_INCR
>  			| ATC_FC_MEM2PER
> -			| ATC_SIF(AT_DMA_MEM_IF) | ATC_DIF(AT_DMA_PER_IF);
> +			| ATC_SIF(atchan->mem_if) | ATC_DIF(atchan->per_if);
>  		reg = sconfig->dst_addr;
>  		for_each_sg(sgl, sg, sg_len, i) {
>  			struct at_desc	*desc;
> @@ -715,7 +716,7 @@ atc_prep_slave_sg(struct dma_chan *chan, struct scatterlist *sgl,
>  		ctrlb |=  ATC_DST_ADDR_MODE_INCR
>  			| ATC_SRC_ADDR_MODE_FIXED
>  			| ATC_FC_PER2MEM
> -			| ATC_SIF(AT_DMA_PER_IF) | ATC_DIF(AT_DMA_MEM_IF);
> +			| ATC_SIF(atchan->per_if) | ATC_DIF(atchan->mem_if);
>  
>  		reg = sconfig->src_addr;
>  		for_each_sg(sgl, sg, sg_len, i) {
> @@ -821,8 +822,8 @@ atc_dma_cyclic_fill_desc(struct dma_chan *chan, struct at_desc *desc,
>  		desc->lli.ctrlb = ATC_DST_ADDR_MODE_FIXED
>  				| ATC_SRC_ADDR_MODE_INCR
>  				| ATC_FC_MEM2PER
> -				| ATC_SIF(AT_DMA_MEM_IF)
> -				| ATC_DIF(AT_DMA_PER_IF);
> +				| ATC_SIF(atchan->mem_if)
> +				| ATC_DIF(atchan->per_if);
>  		break;
>  
>  	case DMA_DEV_TO_MEM:
> @@ -832,8 +833,8 @@ atc_dma_cyclic_fill_desc(struct dma_chan *chan, struct at_desc *desc,
>  		desc->lli.ctrlb = ATC_DST_ADDR_MODE_INCR
>  				| ATC_SRC_ADDR_MODE_FIXED
>  				| ATC_FC_PER2MEM
> -				| ATC_SIF(AT_DMA_PER_IF)
> -				| ATC_DIF(AT_DMA_MEM_IF);
> +				| ATC_SIF(atchan->per_if)
> +				| ATC_DIF(atchan->mem_if);
>  		break;
>  
>  	default:
> @@ -1189,6 +1190,55 @@ static void atc_free_chan_resources(struct dma_chan *chan)
>  	dev_vdbg(chan2dev(chan), "free_chan_resources: done\n");
>  }
>  
> +static bool at_dma_filter(struct dma_chan *chan, void *dma_dev)
> +{
> +	if (dma_dev == chan->device->dev)
> +		return true;
> +	else
> +		return false;
> +}
> +
> +static struct dma_chan *at_dma_xlate(struct of_phandle_args *dma_spec,
> +				     struct of_dma *of_dma)
> +{
> +	struct dma_chan *chan;
> +	struct at_dma_chan *atchan;
> +	struct at_dma_slave *atslave;
> +	dma_cap_mask_t mask;
> +	unsigned int per_id;
> +	struct platform_device *dmac_pdev;
> +
> +	if (dma_spec->args_count != 2)
> +		return NULL;
> +
> +	dmac_pdev = of_find_device_by_node(dma_spec->np);
> +
> +	dma_cap_zero(mask);
> +	dma_cap_set(DMA_SLAVE, mask);
> +
> +	chan = dma_request_channel(mask, at_dma_filter, &dmac_pdev->dev);
> +	if (!chan)
> +		return NULL;
> +
> +	atchan = to_at_dma_chan(chan);
> +	atchan->per_if = dma_spec->args[0] & 0xff;
> +	atchan->mem_if = (dma_spec->args[0] >> 16) & 0xff;
> +
> +	atslave = &atchan->atslave;
> +	/*
> +	 * We can fill both SRC_PER and DST_PER, one of these fields will be
> +	 * ignored depending on DMA transfer direction.
> +	 */
> +	per_id = dma_spec->args[1];
> +	atslave->cfg = ATC_FIFOCFG_HALFFIFO | ATC_DST_H2SEL_HW
> +		      | ATC_SRC_H2SEL_HW | ATC_DST_PER(per_id)
> +		      | ATC_SRC_PER(per_id);
> +	atslave->dma_dev = &dmac_pdev->dev;
> +	chan->private = atslave;
> +	channel_writel(atchan, CFG, atslave->cfg);
> +
> +	return chan;
> +}
>  
>  /*--  Module Management  -----------------------------------------------*/
>  
> @@ -1389,6 +1439,15 @@ static int __init at_dma_probe(struct platform_device *pdev)
>  
>  	dma_async_device_register(&atdma->dma_common);
>  
> +	if (pdev->dev.of_node) {
more simple return if NULL
> +		printk("=== of_dma_controller_register ===\n");
drop this
> +		err = of_dma_controller_register(pdev->dev.of_node,
> +						 at_dma_xlate, atdma);
> +		if (err && err != -ENODEV)
> +			dev_err(&pdev->dev,
> +				"could not register of_dma_controller\n");
		if err you need to return err
> +	}
> +
>  	return 0;
>  
>  err_pool_create:
> diff --git a/drivers/dma/at_hdmac_regs.h b/drivers/dma/at_hdmac_regs.h
> index 0eb3c13..e3d2f12 100644
> --- a/drivers/dma/at_hdmac_regs.h
> +++ b/drivers/dma/at_hdmac_regs.h
> @@ -220,6 +220,8 @@ enum atc_status {
>   * @device: parent device
>   * @ch_regs: memory mapped register base
>   * @mask: channel index in a mask
> + * @per_if: peripheral interface
> + * @mem_if: memory interface
>   * @status: transmit status information from irq/prep* functions
>   *                to tasklet (use atomic operations)
>   * @tasklet: bottom half to finish transaction work
> @@ -227,6 +229,8 @@ enum atc_status {
>   * @save_dscr: for cyclic operations, preserve next descriptor address in
>   *             the cyclic list on suspend/resume cycle
>   * @dma_sconfig: configuration for slave transfers, passed via DMA_SLAVE_CONFIG
> + * @atslave: hardware configuration for slave transfers which is not passed via
> + * DMA_SLAVE_CONFIG
>   * @lock: serializes enqueue/dequeue operations to descriptors lists
>   * @active_list: list of descriptors dmaengine is being running on
>   * @queue: list of descriptors ready to be submitted to engine
> @@ -238,11 +242,14 @@ struct at_dma_chan {
>  	struct at_dma		*device;
>  	void __iomem		*ch_regs;
>  	u8			mask;
> +	u8			per_if;
> +	u8			mem_if;
>  	unsigned long		status;
>  	struct tasklet_struct	tasklet;
>  	u32			save_cfg;
>  	u32			save_dscr;
>  	struct dma_slave_config dma_sconfig;
> +	struct at_dma_slave	atslave;
>  
>  	spinlock_t		lock;
>  
> -- 
> 1.7.11.3
> 


From santosh.shilimkar at ti.com  Mon Apr  8 07:03:53 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Mon, 8 Apr 2013 16:33:53 +0530
Subject: [PATCH v3 0/4] ARM: OMAP4+: PM: Consolidate code for re-use on
 OMAP5
In-Reply-To: <87mwtck0i6.fsf@linaro.org>
References: <1365166743-5940-1-git-send-email-santosh.shilimkar@ti.com>
 <87mwtck0i6.fsf@linaro.org>
Message-ID: <5162A419.6040504@ti.com>

On Saturday 06 April 2013 05:12 AM, Kevin Hilman wrote:
> Santosh Shilimkar <santosh.shilimkar at ti.com> writes:
> 
>> As discussed on list, I split the v2 [1] series into cleanup and OMAP5 support.
> 
> Thanks.
> 
>> This series contains the clean-up patches. I have rebased on top of Tony's
>> pull request and your 3.10/* branches. Series is tested on OMAP4430 SDP
>> with CPUIDLE and suspend. OMAP5 PM support I will post later since it has
>> a dependency with OMAP5 data files which are not pulled in yet.
> 
> I've added 4/4 to my cpuidle branch and added 1,3/4 to my
> for_3.10/cleanup/pm branch (now based on Tony's cleanup-v2 branch for
> dependencies.)   Patch 2/4 needs a respin without the rename as per
> Tony's comments.
> 
OK. Here is an updated patch against your "for_3.10/cleanup/pm"
branch. Attachment as well just in case mailer eat tabs.

Regards,
Santosh


>From 428289ddf30a6a34f7e459720e5f6bf59ce4fe63 Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar <santosh.shilimkar at ti.com>
Date: Thu, 12 Apr 2012 16:51:47 +0530
Subject: [PATCH] ARM: OMAP4+: PM: Consolidate OMAP4 PM code to re-use it for
 OMAP5

OMAP5 has backward compatible PRCM block and it's programming
model is mostly similar to OMAP4. Same is going to be maintained
for future OMAP4 based SOCs. Hence consolidate the OMAP4 power
management code so that it can be re-used on OMAP5 and later devices.

While at it, update the kernel-doc for omap4_pm_init().

Acked-by: Nishanth Menon <nm at ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
---
 arch/arm/mach-omap2/pm44xx.c |   58 ++++++++++++++++++++++++++++++++++--------
 1 file changed, 48 insertions(+), 10 deletions(-)

diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index 5ba6d88..228deca 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -1,7 +1,7 @@
 /*
- * OMAP4 Power Management Routines
+ * OMAP4+ Power Management Routines
  *
- * Copyright (C) 2010-2011 Texas Instruments, Inc.
+ * Copyright (C) 2010-2013 Texas Instruments, Inc.
  * Rajendra Nayak <rnayak at ti.com>
  * Santosh Shilimkar <santosh.shilimkar at ti.com>
  *
@@ -135,16 +135,16 @@ static void omap_default_idle(void)
 }
 
 /**
- * omap4_pm_init - Init routine for OMAP4 PM
+ * omap4_init_static_deps - Add OMAP4 static dependencies
  *
- * Initializes all powerdomain and clockdomain target states
- * and all PRCM settings.
+ * Add needed static clockdomain dependencies on OMAP4 devices.
+ * Return: 0 on success or 'err' on failures
  */
-int __init omap4_pm_init(void)
+static inline int omap4_init_static_deps(void)
 {
-	int ret;
 	struct clockdomain *emif_clkdm, *mpuss_clkdm, *l3_1_clkdm;
 	struct clockdomain *ducati_clkdm, *l3_2_clkdm;
+	int ret = 0;
 
 	if (omap_rev() == OMAP4430_REV_ES1_0) {
 		WARN(1, "Power Management not supported on OMAP4430 ES1.0\n");
@@ -163,7 +163,7 @@ int __init omap4_pm_init(void)
 	ret = pwrdm_for_each(pwrdms_setup, NULL);
 	if (ret) {
 		pr_err("Failed to setup powerdomains\n");
-		goto err2;
+		return ret;
 	}
 
 	/*
@@ -171,6 +171,10 @@ int __init omap4_pm_init(void)
 	 * MPUSS -> L4_PER/L3_* and DUCATI -> L3_* doesn't work as
 	 * expected. The hardware recommendation is to enable static
 	 * dependencies for these to avoid system lock ups or random crashes.
+	 * The L4 wakeup depedency is added to workaround the OCP sync hardware
+	 * BUG with 32K synctimer which lead to incorrect timer value read
+	 * from the 32K counter. The BUG applies for GPTIMER1 and WDT2 which
+	 * are part of L4 wakeup clockdomain.
 	 */
 	mpuss_clkdm = clkdm_lookup("mpuss_clkdm");
 	emif_clkdm = clkdm_lookup("l3_emif_clkdm");
@@ -179,7 +183,7 @@ int __init omap4_pm_init(void)
 	ducati_clkdm = clkdm_lookup("ducati_clkdm");
 	if ((!mpuss_clkdm) || (!emif_clkdm) || (!l3_1_clkdm) ||
 		(!l3_2_clkdm) || (!ducati_clkdm))
-		goto err2;
+		return -EINVAL;
 
 	ret = clkdm_add_wkdep(mpuss_clkdm, emif_clkdm);
 	ret |= clkdm_add_wkdep(mpuss_clkdm, l3_1_clkdm);
@@ -188,9 +192,42 @@ int __init omap4_pm_init(void)
 	ret |= clkdm_add_wkdep(ducati_clkdm, l3_2_clkdm);
 	if (ret) {
 		pr_err("Failed to add MPUSS -> L3/EMIF/L4PER, DUCATI -> L3 wakeup dependency\n");
+		return -EINVAL;
+	}
+
+	return ret;
+}
+
+/**
+ * omap4_pm_init - Init routine for OMAP4+ devices
+ *
+ * Initializes all powerdomain and clockdomain target states
+ * and all PRCM settings.
+ * Return: Returns the error code returned by called functions.
+ */
+int __init omap4_pm_init(void)
+{
+	int ret = 0;
+
+	if (omap_rev() == OMAP4430_REV_ES1_0) {
+		WARN(1, "Power Management not supported on OMAP4430 ES1.0\n");
+		return -ENODEV;
+	}
+
+	pr_info("Power Management for TI OMAP4+ devices.\n");
+
+	ret = pwrdm_for_each(pwrdms_setup, NULL);
+	if (ret) {
+		pr_err("Failed to setup powerdomains.\n");
 		goto err2;
 	}
 
+	if (cpu_is_omap44xx()) {
+		ret = omap4_init_static_deps();
+		if (ret)
+			goto err2;
+	}
+
 	ret = omap4_mpuss_init();
 	if (ret) {
 		pr_err("Failed to initialise OMAP4 MPUSS\n");
@@ -206,7 +243,8 @@ int __init omap4_pm_init(void)
 	/* Overwrite the default cpu_do_idle() */
 	arm_pm_idle = omap_default_idle;
 
-	omap4_idle_init();
+	if (cpu_is_omap44xx())
+		omap4_idle_init();
 
 err2:
 	return ret;
-- 
1.7.9.5


-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-ARM-OMAP4-PM-Consolidate-OMAP4-PM-code-to-re-use-it-.patch
Type: text/x-patch
Size: 4344 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130408/ab185ebf/attachment.bin>

From hechtb at gmail.com  Mon Apr  8 07:03:22 2013
From: hechtb at gmail.com (Bastian Hecht)
Date: Mon, 8 Apr 2013 13:03:22 +0200
Subject: [PATCH v3 1/2] irqchip: intc-irqpin: Add support for shared
 interrupt lines
In-Reply-To: <20130405003614.GD29203@verge.net.au>
References: <1364296699-20919-1-git-send-email-hechtb+renesas@gmail.com>
 <20130327045942.GH25431@verge.net.au>
 <CABYn4sx_pRxgdM3kD3okmt8xbCFas+T0cczQO=RF75Q8Bt2e_Q@mail.gmail.com>
 <20130403074604.GC30989@verge.net.au>
 <CABYn4szuJGFNTQUEoYcRAa34cj+fK=0RpaATDksu3mAM3L8vgg@mail.gmail.com>
 <20130405003614.GD29203@verge.net.au>
Message-ID: <CABYn4sxX8e1Fi=msZ2WB18Cw5X3naSPrhHfCnp7TYnWgoL8KsQ@mail.gmail.com>

2013/4/5 Simon Horman <horms at verge.net.au>:
> On Thu, Apr 04, 2013 at 03:47:34PM +0200, Bastian Hecht wrote:
>> Hi Simon,
>>
>> ok I've sent out a patch series with the reference DT code. I've had
>> to adapt a couple of things and the device list is rather short. How
>> long do I have to augment it a bit before the merge window closes?
>
> The merge window is more or less closed. So I think we will have
> to aim for v3.11. But I don't think that should affect the way
> you write the code, please just base it on the latest renesas-next tag.

Ok thanks for the info, Simon.

>> Thanks,
>>
>>  Bastian
>>
>>
>> 2013/4/3 Simon Horman <horms at verge.net.au>:
>> > On Wed, Mar 27, 2013 at 02:50:05PM +0100, Bastian Hecht wrote:
>> >> Hi Simon,
>> >>
>> >> 2013/3/27 Simon Horman <horms at verge.net.au>:
>> >> > On Tue, Mar 26, 2013 at 12:18:18PM +0100, Bastian Hecht wrote:
>> >> >> On some hardware we don't have a 1-1 mapping from the external
>> >> >> interrupts coming from INTC to the GIC SPI pins. We can however
>> >> >> share lines to demux incoming IRQs on these SoCs.
>> >> >>
>> >> >> This patch enables the intc_irqpin driver to detect requests for shared
>> >> >> interrupt lines and demuxes them properly by querying the INTC INTREQx0A
>> >> >> registers.
>> >> >>
>> >> >> If you need multiple shared intc_irqpin device instances, be sure to mask
>> >> >> out all interrupts on the INTC that share the one line before you start
>> >> >> to register them. Else you run into IRQ floods that would be caused by
>> >> >> interrupts for which no handler has been set up yet when the first
>> >> >> intc_irqpin device is registered.
>> >> >>
>> >> >> Signed-off-by: Bastian Hecht <hechtb+renesas at gmail.com>
>> >> >> Acked-by: Magnus Damm <damm at opensource.se>
>> >> >
>> >> > Thanks, I will see about queuing up these changes for v3.10.
>> >> >
>> >> >
>> >> > I believe that with these changes it should be possible to rebase/rework
>> >> > armadillo800eva-reference so that it no longer uses the unmerged INTC
>> >> > DT bindings. Would it be possible for you to see about making a fresh
>> >> > version of armadillo800eva-reference that is based on the next branch
>> >> > in the Renesas tree plus this series of two patches?
>> >>
>> >> yes ok, I'll prepare a new armadillo reference version. The patches
>> >> were based on all+next, but I'll post a v4 rebased on next.
>> >> I'll post a separate patch series for the reference code if you don't
>> >> mind, as this might take a few days to be done.
>> >
>> > Hi Bastian,
>> >
>> > gentle nudge with regards to a fresh armadillo-reference.
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


From linux at arm.linux.org.uk  Mon Apr  8 07:00:32 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Mon, 8 Apr 2013 12:00:32 +0100
Subject: [PATCH] ARM: Samsung: Select ARM_CPU_SUSPEND when required
In-Reply-To: <51629B96.9050504@samsung.com>
References: <1365366442-16025-1-git-send-email-s.nawrocki@samsung.com>
 <2cd601ce343f$7d6aac50$784004f0$%kim@samsung.com>
 <51629B96.9050504@samsung.com>
Message-ID: <20130408110032.GK17995@n2100.arm.linux.org.uk>

On Mon, Apr 08, 2013 at 12:27:34PM +0200, Sylwester Nawrocki wrote:
> On 04/08/2013 11:57 AM, Kukjin Kim wrote:
> Yes, this looks better. However after posting this patch I noticed linker
> errors in some builds due to undefined cpu_arm920_do_suspend,
> cpu_arm920_do_resume routines.
> 
> It seems it is because various cpu_*_do_suspend routines are selected by
> CONFIG_PM_SLEEP.  And the PM code in arch/arm/mach-s3c24xx, arch/arm/mach-
> s3c64xx is selected by CONFIG_PM.
> 
> $ git grep -1 "ENTRY(cpu_.*_do_suspend"
> arch/arm/mm/proc-arm920.S-#ifdef CONFIG_PM_SLEEP
> arch/arm/mm/proc-arm920.S:ENTRY(cpu_arm920_do_suspend)
> arch/arm/mm/proc-arm920.S-      stmfd   sp!, {r4 - r6, lr}
> --
> arch/arm/mm/proc-arm926.S-#ifdef CONFIG_PM_SLEEP
> arch/arm/mm/proc-arm926.S:ENTRY(cpu_arm926_do_suspend)
> arch/arm/mm/proc-arm926.S-      stmfd   sp!, {r4 - r6, lr}
> --
> arch/arm/mm/proc-mohawk.S-#ifdef CONFIG_PM_SLEEP
> arch/arm/mm/proc-mohawk.S:ENTRY(cpu_mohawk_do_suspend)
> arch/arm/mm/proc-mohawk.S-      stmfd   sp!, {r4 - r9, lr}
> --
> arch/arm/mm/proc-sa1100.S-#ifdef CONFIG_PM_SLEEP
> arch/arm/mm/proc-sa1100.S:ENTRY(cpu_sa1100_do_suspend)
> arch/arm/mm/proc-sa1100.S-      stmfd   sp!, {r4 - r6, lr}
> --
> arch/arm/mm/proc-v6.S-#ifdef CONFIG_PM_SLEEP
> arch/arm/mm/proc-v6.S:ENTRY(cpu_v6_do_suspend)
> arch/arm/mm/proc-v6.S-  stmfd   sp!, {r4 - r9, lr}
> --
> arch/arm/mm/proc-v7.S-#ifdef CONFIG_ARM_CPU_SUSPEND
> arch/arm/mm/proc-v7.S:ENTRY(cpu_v7_do_suspend)
> arch/arm/mm/proc-v7.S-  stmfd   sp!, {r4 - r10, lr}
> --
> arch/arm/mm/proc-xsc3.S-#ifdef CONFIG_PM_SLEEP
> arch/arm/mm/proc-xsc3.S:ENTRY(cpu_xsc3_do_suspend)
> arch/arm/mm/proc-xsc3.S-        stmfd   sp!, {r4 - r9, lr}
> --
> arch/arm/mm/proc-xscale.S-#ifdef CONFIG_PM_SLEEP
> arch/arm/mm/proc-xscale.S:ENTRY(cpu_xscale_do_suspend)
> arch/arm/mm/proc-xscale.S-      stmfd   sp!, {r4 - r9, lr}
> 
> However I can't reproduce it now :-/ Anyway the $subject patch fixes
> the main issue, which I can easily reproduce here as well. So I'll
> prepare another patch if needed when I get back to this later.

Sigh.  This stuff looks rather screwed up now:

$ grep -B1 'ENTRY.*do_suspend' arch/arm/mm/proc*.S
arch/arm/mm/proc-arm920.S-#ifdef CONFIG_PM_SLEEP
arch/arm/mm/proc-arm920.S:ENTRY(cpu_arm920_do_suspend)
--
arch/arm/mm/proc-arm926.S-#ifdef CONFIG_PM_SLEEP
arch/arm/mm/proc-arm926.S:ENTRY(cpu_arm926_do_suspend)
--
arch/arm/mm/proc-mohawk.S-#ifdef CONFIG_PM_SLEEP
arch/arm/mm/proc-mohawk.S:ENTRY(cpu_mohawk_do_suspend)
--
arch/arm/mm/proc-sa1100.S-#ifdef CONFIG_PM_SLEEP
arch/arm/mm/proc-sa1100.S:ENTRY(cpu_sa1100_do_suspend)
--
arch/arm/mm/proc-v6.S-#ifdef CONFIG_PM_SLEEP
arch/arm/mm/proc-v6.S:ENTRY(cpu_v6_do_suspend)
--
arch/arm/mm/proc-v7.S-#ifdef CONFIG_ARM_CPU_SUSPEND
arch/arm/mm/proc-v7.S:ENTRY(cpu_v7_do_suspend)
--
arch/arm/mm/proc-xsc3.S-#ifdef CONFIG_PM_SLEEP
arch/arm/mm/proc-xsc3.S:ENTRY(cpu_xsc3_do_suspend)
--
arch/arm/mm/proc-xscale.S-#ifdef CONFIG_PM_SLEEP
arch/arm/mm/proc-xscale.S:ENTRY(cpu_xscale_do_suspend)

Now, CONFIG_PM_SLEEP is fine if this stuff only ever gets used when PM_SLEEP
is enabled - that's what it was designed for in the first place.  However,
as we can see from the earlier patches in this thread, the cpu_suspend
stuff is being selected when PM is enabled (which is arguably wrong), and
also in some cases when CPU_IDLE is enabled.

Therefore, making this code depend on ARM_CPU_SUSPEND seems sensible.
However, So, how did proc-v7.S and only that file end up doing something
different?

commit 15e0d9e37c7fe9711b60f47221c394d45553ad8c
Author: Arnd Bergmann <arnd at arndb.de>
Date:   Sat Oct 1 21:09:39 2011 +0200

    ARM: pm: let platforms select cpu_suspend support

    Support for the cpu_suspend functions is only built-in
    when CONFIG_PM_SLEEP is enabled, but omap3/4, exynos4
    and pxa always call cpu_suspend when CONFIG_PM is enabled.

    Signed-off-by: Arnd Bergmann <arnd at arndb.de>

...
diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
index a30e785..591accd 100644
--- a/arch/arm/mm/proc-v7.S
+++ b/arch/arm/mm/proc-v7.S
@@ -217,7 +217,7 @@ ENDPROC(cpu_v7_set_pte_ext)
 /* Suspend/resume support: derived from arch/arm/mach-s5pv210/sleep.S */
 .globl cpu_v7_suspend_size
 .equ   cpu_v7_suspend_size, 4 * 9
-#ifdef CONFIG_PM_SLEEP
+#ifdef CONFIG_ARM_CPU_SUSPEND
 ENTRY(cpu_v7_do_suspend)
...

As far as this commit goes, it looks sane at the time that it was written,
but as soon as we have *any* other selections of ARM_CPU_SUSPEND, the
whole idea becomes extremely fragile - hence the reason for your build
errors.

Moreover, with the above commit, there is _no_ sense what so ever in not
applying the same change to all proc-*.S files, thereby entirely avoiding
this fragility.  I would argue that the original commit should have made
the same change to _all_ proc-*.S files.

Let's do the job properly - hence this is now queued for -rc:

8<===
From: Russell King <rmk+kernel at arm.linux.org.uk>
Subject: [PATCH] ARM: Do 15e0d9e37c (ARM: pm: let platforms select cpu_suspend support) properly

Let's do the changes properly and fix the same problem everywhere, not
just for one case.

Cc: <stable at vger.kernel.org> # kernels containing 15e0d9e37c7fe or equivalent
Signed-off-by: Russell King <rmk+kernel at arm.linux.org.uk>
---
 arch/arm/mm/proc-arm920.S |    2 +-
 arch/arm/mm/proc-arm926.S |    2 +-
 arch/arm/mm/proc-mohawk.S |    2 +-
 arch/arm/mm/proc-sa1100.S |    2 +-
 arch/arm/mm/proc-v6.S     |    2 +-
 arch/arm/mm/proc-xsc3.S   |    2 +-
 arch/arm/mm/proc-xscale.S |    2 +-
 7 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/arm/mm/proc-arm920.S b/arch/arm/mm/proc-arm920.S
index 2c3b942..2556cf1 100644
--- a/arch/arm/mm/proc-arm920.S
+++ b/arch/arm/mm/proc-arm920.S
@@ -387,7 +387,7 @@ ENTRY(cpu_arm920_set_pte_ext)
 /* Suspend/resume support: taken from arch/arm/plat-s3c24xx/sleep.S */
 .globl	cpu_arm920_suspend_size
 .equ	cpu_arm920_suspend_size, 4 * 3
-#ifdef CONFIG_PM_SLEEP
+#ifdef CONFIG_ARM_CPU_SUSPEND
 ENTRY(cpu_arm920_do_suspend)
 	stmfd	sp!, {r4 - r6, lr}
 	mrc	p15, 0, r4, c13, c0, 0	@ PID
diff --git a/arch/arm/mm/proc-arm926.S b/arch/arm/mm/proc-arm926.S
index f1803f7..344c8a5 100644
--- a/arch/arm/mm/proc-arm926.S
+++ b/arch/arm/mm/proc-arm926.S
@@ -402,7 +402,7 @@ ENTRY(cpu_arm926_set_pte_ext)
 /* Suspend/resume support: taken from arch/arm/plat-s3c24xx/sleep.S */
 .globl	cpu_arm926_suspend_size
 .equ	cpu_arm926_suspend_size, 4 * 3
-#ifdef CONFIG_PM_SLEEP
+#ifdef CONFIG_ARM_CPU_SUSPEND
 ENTRY(cpu_arm926_do_suspend)
 	stmfd	sp!, {r4 - r6, lr}
 	mrc	p15, 0, r4, c13, c0, 0	@ PID
diff --git a/arch/arm/mm/proc-mohawk.S b/arch/arm/mm/proc-mohawk.S
index 82f9cdc..0b60dd3 100644
--- a/arch/arm/mm/proc-mohawk.S
+++ b/arch/arm/mm/proc-mohawk.S
@@ -350,7 +350,7 @@ ENTRY(cpu_mohawk_set_pte_ext)
 
 .globl	cpu_mohawk_suspend_size
 .equ	cpu_mohawk_suspend_size, 4 * 6
-#ifdef CONFIG_PM_SLEEP
+#ifdef CONFIG_ARM_CPU_SUSPEND
 ENTRY(cpu_mohawk_do_suspend)
 	stmfd	sp!, {r4 - r9, lr}
 	mrc	p14, 0, r4, c6, c0, 0	@ clock configuration, for turbo mode
diff --git a/arch/arm/mm/proc-sa1100.S b/arch/arm/mm/proc-sa1100.S
index 3aa0da1..d92dfd0 100644
--- a/arch/arm/mm/proc-sa1100.S
+++ b/arch/arm/mm/proc-sa1100.S
@@ -172,7 +172,7 @@ ENTRY(cpu_sa1100_set_pte_ext)
 
 .globl	cpu_sa1100_suspend_size
 .equ	cpu_sa1100_suspend_size, 4 * 3
-#ifdef CONFIG_PM_SLEEP
+#ifdef CONFIG_ARM_CPU_SUSPEND
 ENTRY(cpu_sa1100_do_suspend)
 	stmfd	sp!, {r4 - r6, lr}
 	mrc	p15, 0, r4, c3, c0, 0		@ domain ID
diff --git a/arch/arm/mm/proc-v6.S b/arch/arm/mm/proc-v6.S
index bcaaa8d..5c07ee4 100644
--- a/arch/arm/mm/proc-v6.S
+++ b/arch/arm/mm/proc-v6.S
@@ -138,7 +138,7 @@ ENTRY(cpu_v6_set_pte_ext)
 /* Suspend/resume support: taken from arch/arm/mach-s3c64xx/sleep.S */
 .globl	cpu_v6_suspend_size
 .equ	cpu_v6_suspend_size, 4 * 6
-#ifdef CONFIG_PM_SLEEP
+#ifdef CONFIG_ARM_CPU_SUSPEND
 ENTRY(cpu_v6_do_suspend)
 	stmfd	sp!, {r4 - r9, lr}
 	mrc	p15, 0, r4, c13, c0, 0	@ FCSE/PID
diff --git a/arch/arm/mm/proc-xsc3.S b/arch/arm/mm/proc-xsc3.S
index eb93d64..e8efd83 100644
--- a/arch/arm/mm/proc-xsc3.S
+++ b/arch/arm/mm/proc-xsc3.S
@@ -413,7 +413,7 @@ ENTRY(cpu_xsc3_set_pte_ext)
 
 .globl	cpu_xsc3_suspend_size
 .equ	cpu_xsc3_suspend_size, 4 * 6
-#ifdef CONFIG_PM_SLEEP
+#ifdef CONFIG_ARM_CPU_SUSPEND
 ENTRY(cpu_xsc3_do_suspend)
 	stmfd	sp!, {r4 - r9, lr}
 	mrc	p14, 0, r4, c6, c0, 0	@ clock configuration, for turbo mode
diff --git a/arch/arm/mm/proc-xscale.S b/arch/arm/mm/proc-xscale.S
index 2551036..e766f88 100644
--- a/arch/arm/mm/proc-xscale.S
+++ b/arch/arm/mm/proc-xscale.S
@@ -528,7 +528,7 @@ ENTRY(cpu_xscale_set_pte_ext)
 
 .globl	cpu_xscale_suspend_size
 .equ	cpu_xscale_suspend_size, 4 * 6
-#ifdef CONFIG_PM_SLEEP
+#ifdef CONFIG_ARM_CPU_SUSPEND
 ENTRY(cpu_xscale_do_suspend)
 	stmfd	sp!, {r4 - r9, lr}
 	mrc	p14, 0, r4, c6, c0, 0	@ clock configuration, for turbo mode
-- 
1.7.4.4


From stefano.stabellini at eu.citrix.com  Mon Apr  8 07:05:17 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Mon, 8 Apr 2013 12:05:17 +0100
Subject: [PATCH 0/4 v6] arm: introduce psci_smp_ops and use them on Xen
In-Reply-To: <alpine.DEB.2.02.1304031239550.5078@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1304031239550.5078@kaball.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1304081102500.5353@kaball.uk.xensource.com>

Arnd, Olof,
do you have any thoughts on this series?
Would you be happy to carry it in the arm-soc tree?

The last patch, "xen/arm: introduce xen_early_init, use PSCI on xen" has
a (small) dependency on this series:

http://marc.info/?l=linux-kernel&m=136430893610688&w=2

would you be OK with taking that one too, or should that go through the
Xen tree?

Cheers,

Stefano

On Fri, 5 Apr 2013, Stefano Stabellini wrote:
> Hi all,
> this is the sixth version of the patch series to move virt_smp_ops out of
> mach-virt and make it a generic set of reusable PSCI based smp_ops.
> psci_smp_ops are preferred over the platform smp_ops.
> I added a patch to introduce smp_init to this series.
> In the last patch I am using smp_init to switch to psci_smp_ops if Xen
> is detected on the platform.
> 
> 
> Jon Medhurst (1):
>       ARM: Enable selection of SMP operations at boot time
> 
> Stefano Stabellini (3):
>       arm: introduce psci_smp_ops
>       arm: prefer psci_smp_ops over mdesc->smp
>       xen/arm: introduce xen_early_init, use PSCI on xen
> 
>  arch/arm/Kconfig                      |    1 +
>  arch/arm/include/asm/mach/arch.h      |    3 +
>  arch/arm/include/asm/psci.h           |   29 ++++++++++++++
>  arch/arm/include/asm/xen/hypervisor.h |    6 +++
>  arch/arm/kernel/Makefile              |    5 ++-
>  arch/arm/kernel/psci.c                |    7 +--
>  arch/arm/kernel/psci_smp.c            |   67 +++++++++++++++++++++++++++++++++
>  arch/arm/kernel/setup.c               |   12 +++++-
>  arch/arm/mach-virt/Makefile           |    1 -
>  arch/arm/mach-virt/platsmp.c          |   58 ----------------------------
>  arch/arm/mach-virt/virt.c             |    3 -
>  arch/arm/xen/enlighten.c              |   36 ++++++++++++++----
>  12 files changed, 152 insertions(+), 76 deletions(-)
> 
>     
> git://xenbits.xen.org/people/sstabellini/linux-pvhvm.git 3.9-rc3-smp-6
> 
> 
> Cheers,
> 
> Stefano
> 


From plagnioj at jcrosoft.com  Mon Apr  8 07:02:51 2013
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Mon, 8 Apr 2013 13:02:51 +0200
Subject: [RFC 4/5] RTC: rtc-at91sam9: add device-tree support
In-Reply-To: <51629EFE.9000508@atmel.com>
References: <20130407150938.GA25605@localhost>
 <1365347572-14972-1-git-send-email-jhovold@gmail.com>
 <1365347572-14972-4-git-send-email-jhovold@gmail.com>
 <20130408073807.GQ20693@game.jcrosoft.org>
 <20130408090023.GC25605@localhost> <51629472.3070404@atmel.com>
 <20130408100301.GS20693@game.jcrosoft.org>
 <51629EFE.9000508@atmel.com>
Message-ID: <20130408110251.GV20693@game.jcrosoft.org>

On 12:42 Mon 08 Apr     , Nicolas Ferre wrote:
> On 04/08/2013 12:03 PM, Jean-Christophe PLAGNIOL-VILLARD :
> > On 11:57 Mon 08 Apr     , Nicolas Ferre wrote:
> >> On 04/08/2013 11:00 AM, Johan Hovold :
> >>> On Mon, Apr 08, 2013 at 09:38:07AM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> >>>> On 17:12 Sun 07 Apr     , Johan Hovold wrote:
> >>>>> Add device-tree support.
> >>>>>
> >>>>> The AT91 RTT can be used as an RTC if the atmel,at91-rtt-as-rtc-gpbr
> >>>>> property is present and set to the general-purpose backup register to
> >>>>> use to store the RTC time base.
> >>>>>
> >>>>> Signed-off-by: Johan Hovold <jhovold at gmail.com>
> >>>>> ---
> >>>>>  .../devicetree/bindings/rtc/rtc-at91sam9.txt       | 19 ++++++++++++
> >>>>>  drivers/rtc/rtc-at91sam9.c                         | 36 +++++++++++++++++++++-
> >>>>>  2 files changed, 54 insertions(+), 1 deletion(-)
> >>>>>  create mode 100644 Documentation/devicetree/bindings/rtc/rtc-at91sam9.txt
> >>>>>
> >>>>> diff --git a/Documentation/devicetree/bindings/rtc/rtc-at91sam9.txt b/Documentation/devicetree/bindings/rtc/rtc-at91sam9.txt
> >>>>> new file mode 100644
> >>>>> index 0000000..0f54988
> >>>>> --- /dev/null
> >>>>> +++ b/Documentation/devicetree/bindings/rtc/rtc-at91sam9.txt
> >>>>> @@ -0,0 +1,19 @@
> >>>>> +Atmel AT91 RTT as RTC
> >>>>> +=====================
> >>>>> +
> >>>>> +Required properties:
> >>>>> +- compatible: Should be "atmel,at91sam9260-rtt"
> >>>>> +- reg: Should contain register location and length
> >>>>> +- interrupts: Should contain interrupt for the RTT which is the IRQ line
> >>>>> +  shared across all System Controller members.
> >>>>> +- atmel,rtt-as-rtc-gpbr: Should contain the backup-register to use to store
> >>>>> +  the RTC time base
> >>>>> +
> >>>>> +Example:
> >>>>> +
> >>>>> +rtt at fffffd20 {
> >>>>> +		compatible = "atmel,at91sam9g45-rtt", "atmel,at91sam9260-rtt";
> >>
> >> No, there is no visible difference between the sam9g45 RTT and the
> >> sam9260 one. So the most precise compatibility string is still sam9260.
> >> If one day we feel the need for a advanced feature that exists on a more
> >> recent SoC, we have the possibility to add it at that time...
> >>
> >>>>> +		reg = <0xfffffd20 0x10>;
> >>>>> +		interrupts = <1 4 7>;
> >>>>> +		atmel,at91-rtt-as-rtc-gpbr = <0>;
> >>>> no you miss the point of the DT
> >>>>
> >>>> you need to describe the hardware no a particular use of it
> >>>
> >>> That was what I was trying to achieve by adding the two use-neutral
> >>> rtt and gpbr-nodes. But then the question is how would you influence
> >>> which out of two rtt-drivers to use?
> >>>
> >>> Adding a property as above in the final board descriptions seemed
> >>> preferable to adding rtt-as-rtc to the compatible string of the rtt as
> >>> that would mean describing use rather than just hardware.
> >>
> >> Well, re-reading the Device_Tree_Usage page, I found this sentence:
> >> "
> >> Understanding the compatible Property
> >>
> >> Every node in the tree that represents a device is required to have the
> >> compatible property. compatible is the key an operating system uses to
> >> decide which device driver to bind to a device.
> >> "
> >> or ePARP:
> >>
> >> "
> >> The compatible property value consists of one or more strings that
> >> define the specific programming model for the device.
> >> "
> >>
> >> We have the notion of link between hardware and software in this
> >> *compatible* sting, even if the *node* itself is about hardware description.
> >>
> >>>> the RTT is a general purpose timer backuped that we use in linux as a
> >>>> RTC with a gpbr to store the time
> >>>>
> >>>> you need 2 binding on for the RTT one the RTT-rtc
> >>>
> >>> As in adding some virtual hardware-node which uses the rtt and gpbr as
> >>> resources?
> >>
> >> So, why not simply having a compatibility string that collects the uses
> >> of this RTT node:
> >>
> >> compatible = "atmel,at91sam9260-rtt-as-rtc", "atmel,at91sam9260-rtt";
> >>
> >> And then "decide which device driver to bind to [the RTT] device"...
> >> If the rtt-as-rtc driver is not selected, the device can still be used
> >> as a simple "rtt". The board .dts can overload a compatibility string
> >> according to the use, etc.
> >>
> >> Then the way do describe which GPBR to use has still to be discussed.
> >> But for the RTT itself, I would keep it simple like that.
> > 
> > no as infact the rtc-at91sam9 should not even exist
> > as this is much more generic
> > 
> > we use a backped register and a timer to emulate a RTC this can be unsed by
> > any one
> > 
> > and I can use any backuped timer
> > 
> > we need to have frameworks
> 
> Is it possible to focus on the current problem instead of calling for
> the creation for Yet Another Framework?
> 
> > where the gpbr are tracked and the rtt
> > 
> > 	for you describe the resources
> > 
> > 	rtt0: rtt at fffffd20 {
> > 		compatible = "atmel,at91sam9260-rtt";
> > 		reg = <0xfffffd20 0x10>;
> > 		interrupts = <1 4 7>;
> > 	};
> > 
> > 	rtc-timer {
> > 		compatible = "linux,rtc-timer";
> > 		timer = <&rtt0>;
> > 		backuped-register = <&gpbr 0>;
> > 	};
> > 
> > this need to SoC implemetation generic
> 
> OMG, so well, we will have to re-write the whole rtc-at91sam9 now??!! Oh
> yes, I see, we do not have more urgent things to do...
> 
> Please stop trying re-inventing things that will do everything but
> solving the real issues: why not agree on a sort term solution about
> this rtt/rtc thing: I have *never* heard complains about this precise
> driver. And we must concentrate now on problem solving.

no the current driver is badly design this need to be cleanup

switch to DT does mean do the stuff CLEAN no quirk hack

we did the same for pinctrl/dma/fb. This need to be done correctly

DT is to describe hardware not software implentation

Best Regards,
J.


From ezequiel.garcia at free-electrons.com  Mon Apr  8 07:06:29 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Mon,  8 Apr 2013 08:06:29 -0300
Subject: [PATCH v4 0/5] Device Bus support for Marvell EBU SoC
Message-ID: <1365419194-20871-1-git-send-email-ezequiel.garcia@free-electrons.com>

This patchset continues the effort to add Device Bus support
on Marvell EBU SoC.

If you're reading this for the first time you can grab the full details here:

  http://www.spinics.net/lists/arm-kernel/msg236151.html

This new version changes the way each chip select is described in the DT.
Now there's a separate node for each Device Bus chip select, like this:

	devbus-bootcs at d0010400 {
		compatible = "marvell,mvebu-devbus";
		reg = <0xd0010400 0x8>;
		ranges = <0 0 0xf0000000 0x8000000>; /* CS0 @addr 0xf000000, size 0x8000000 */

		device at 0 {
			reg = <0 0 0x8000000>;
		}
	};

	// ...

	devbus-cs1 at d0010410 {
		compatible = "marvell,mvebu-devbus";
		reg = <0xd0010410 0x8>;
	};

In particular, please note that once the window handling is properly added
to the DT, and we remove the mbus usage from this driver, in the above DT nodes
the ranges property value will have to be changed, but the ABI will be the same.

This applies on top of v3.9-rc5 with mbus patches applied, which can 
be found in Jason Cooper's mvebus/soc branch.
If anyone wants to try this, there's a public branch available at:

  https://github.com/MISL-EBU-System-SW/mainline-public/tree/mvebu-devbus-v4

How does this version look regarding its inclusion in v3.10?
@Jason, @Arnd: if you think this v4 meets your expectation,
I'd like to have your Ack so I can ask Jason Cooper to apply this.

If the driver looks good and the temporary window handling is accepted,
then I can prepare a rebased patchset on top of Gregory's LPAE work,
or on top of any other required patches.

Changes from v3:

  * Rename devbus,dev-width to devbus,bus-width and changed the
    parameter value from bytes to bits: <8>, <16>, ...
    Suggested by Arnd Bergmann.

  * As suggested by Jason Gunthorpe and agreed by Arnd Bergmann.
    Reworked the whole devbus child chip-select device tree design.
    Now there's a separate devbus at addr DT node for each controller
    chip select. The impact of this is:
      1. Timing parameters now go into the parent node.
      2. There can only be one child per devbus node.

  * Remove unneeded bank-width parameter read.

Changes from v2:

  * Replace the 'NOR' specific probe by a generic probe.
    Currently, we don't see anything specific to NOR in this driver.
    Suggested by Jason Gunthorpe.

  * Add a check to detect that every timing parameter is specified
    in the device tree node.
    Suggested by Jason Gunthorpe.

Changes from v1:

  * Added a remove() function to unregister childs and remove address windows,
    as suggested by Thomas Petazzoni.

  * Remove unneeded 'inline' prefix on functions as suggested by Thomas Petazzoni.

  * Timings parameters are now mandatory and expressed in picoseconds,
    as requested by Jason Gunthorpe.
    This is consistent with OMAP's GPMC dts binding.

  * Fix documentation as suggested by Jason Gunthorpe.

Thanks!

Ezequiel Garcia (5):
  drivers: memory: Introduce Marvell EBU Device Bus driver
  ARM: mvebu: Add Device Bus support for Armada 370/XP SoC
  ARM: mvebu: Add support for NOR flash device on Armada XP-GP board
  ARM: mvebu: Add support for NOR flash device on Openblocks AX3 board
  ARM: mvebu: Add Device Bus and CFI flash memory support to defconfig

 .../bindings/memory-controllers/mvebu-devbus.txt   | 156 ++++++++++
 arch/arm/boot/dts/armada-370-xp.dtsi               |  45 +++
 arch/arm/boot/dts/armada-xp-gp.dts                 |  29 ++
 arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts   |  29 ++
 arch/arm/configs/mvebu_defconfig                   |   7 +
 drivers/memory/Kconfig                             |  10 +
 drivers/memory/Makefile                            |   1 +
 drivers/memory/mvebu-devbus.c                      | 344 +++++++++++++++++++++
 8 files changed, 621 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/memory-controllers/mvebu-devbus.txt
 create mode 100644 drivers/memory/mvebu-devbus.c

-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Mon Apr  8 07:06:30 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Mon,  8 Apr 2013 08:06:30 -0300
Subject: [PATCH v4 1/5] drivers: memory: Introduce Marvell EBU Device Bus
 driver
In-Reply-To: <1365419194-20871-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1365419194-20871-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1365419194-20871-2-git-send-email-ezequiel.garcia@free-electrons.com>

Marvell EBU SoCs such as Armada 370/XP, Orion5x (88f5xxx) and
Discovery (mv78xx0) supports a Device Bus controller to access several
kinds of memories and I/O devices (NOR, NAND, SRAM, FPGA).

This commit adds a driver to handle this controller. So far only
Armada 370, Armada XP and Discovery SoCs are supported.

The driver must be registered through a device tree node;
as explained in the binding document.

Each Device Bus node in the device tree, represents a chip select.
For each node, the driver will:
  * set timing parameters
  * register one child device
  * setup an address decoding window, using the mbus driver

Keep in mind the address decoding window setup is only a temporary hack.
This code will be removed from this devbus driver as soon as a proper device
tree binding for the mbus driver is added.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
---
 .../bindings/memory-controllers/mvebu-devbus.txt   | 156 ++++++++++
 drivers/memory/Kconfig                             |  10 +
 drivers/memory/Makefile                            |   1 +
 drivers/memory/mvebu-devbus.c                      | 344 +++++++++++++++++++++
 4 files changed, 511 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/memory-controllers/mvebu-devbus.txt
 create mode 100644 drivers/memory/mvebu-devbus.c

diff --git a/Documentation/devicetree/bindings/memory-controllers/mvebu-devbus.txt b/Documentation/devicetree/bindings/memory-controllers/mvebu-devbus.txt
new file mode 100644
index 0000000..9ddcd6c
--- /dev/null
+++ b/Documentation/devicetree/bindings/memory-controllers/mvebu-devbus.txt
@@ -0,0 +1,156 @@
+Device tree bindings for MVEBU Device Bus controllers
+
+The Device Bus controller available in some Marvell's SoC allows to control
+different types of standard memory and I/O devices such as NOR, NAND, and FPGA.
+The actual devices are instantiated from the child nodes of a Device Bus node.
+
+Required properties:
+
+ - compatible:          Currently only Armada 370/XP SoC are supported,
+                        with this compatible string:
+
+                        marvell,mvebu-devbus
+
+ - reg:                 A resource specifier for the register space.
+                        This is the base address of a chip select within
+			the controller's register space.
+                        (see the example below)
+
+ - #address-cells:      Must be set to 2 to allow memory address translation
+ - #size-cells:         Must be set to 1 to allow CS address passing
+ - ranges:              Must be set up to reflect the memory layout with four
+                        integer values for each chip-select line in use:
+                        <cs-number> 0 <physical address of mapping> <size>
+
+Mandatory timing properties for child nodes:
+
+Read parameters:
+
+ - devbus,turn-off-ps:  Defines the time during which the controller does not
+                        drive the AD bus after the completion of a device read.
+                        This prevents contentions on the Device Bus after a read
+                        cycle from a slow device.
+
+ - devbus,bus-width:    Defines the bus width (e.g. <16>)
+
+ - devbus,badr-skew-ps: Defines the time delay from from A[2:0] toggle,
+                        to read data sample. This parameter is useful for
+                        synchronous pipelined devices, where the address
+                        precedes the read data by one or two cycles.
+
+ - devbus,acc-first-ps: Defines the time delay from the negation of
+                        ALE[0] to the cycle that the first read data is sampled
+                        by the controller.
+
+ - devbus,acc-next-ps:  Defines the time delay between the cycle that
+                        samples data N and the cycle that samples data N+1
+                        (in burst accesses).
+
+ - devbus,rd-setup-ps:  Defines the time delay between DEV_CSn assertion to
+			DEV_OEn assertion. If set to 0 (default),
+                        DEV_OEn and DEV_CSn are asserted at the same cycle.
+                        This parameter has no affect on <acc-first-ps> parameter
+                        (no affect on first data sample). Set <rd-setup-ps>
+                        to a value smaller than <acc-first-ps>.
+
+ - devbus,rd-hold-ps:   Defines the time between the last data sample to the
+			de-assertion of DEV_CSn. If set to 0 (default),
+			DEV_OEn and DEV_CSn are de-asserted at the same cycle
+			(the cycle of the last data sample).
+                        This parameter has no affect on DEV_OEn de-assertion.
+                        DEV_OEn is always de-asserted the next cycle after
+                        last data sampled. Also this parameter has no
+                        affect on <turn-off-ps> parameter.
+                        Set <rd-hold-ps> to a value smaller than <turn-off-ps>.
+
+Write parameters:
+
+ - devbus,ale-wr-ps:    Defines the time delay from the ALE[0] negation cycle
+			to the DEV_WEn assertion.
+
+ - devbus,wr-low-ps:    Defines the time during which DEV_WEn is active.
+                        A[2:0] and Data are kept valid as long as DEV_WEn
+                        is active. This parameter defines the setup time of
+                        address and data to DEV_WEn rise.
+
+ - devbus,wr-high-ps:   Defines the time during which DEV_WEn is kept
+                        inactive (high) between data beats of a burst write.
+                        DEV_A[2:0] and Data are kept valid (do not toggle) for
+                        <wr-high-ps> - <tick> ps.
+			This parameter defines the hold time of address and
+			data after DEV_WEn rise.
+
+ - devbus,sync-enable: Synchronous device enable.
+                       1: True
+                       0: False
+
+An example for an Armada XP GP board, with a 16 MiB NOR device as child
+is showed below. Note that the Device Bus driver is in charge of allocating
+the mbus address decoding window for each of its child devices.
+The window is created using the chip select specified in the child
+device node together with the base address and size specified in the ranges
+property. For instance, in the example below the allocated decoding window
+will start at base address 0xf0000000, with a size 0x1000000 (16 MiB)
+for chip select 0 (a.k.a DEV_BOOTCS).
+
+This address window handling is done in this mvebu-devbus only as a temporary
+solution. It will be removed when the support for mbus device tree binding is
+added.
+
+The reg property implicitly specifies the chip select as this:
+
+  0x10400: DEV_BOOTCS
+  0x10408: DEV_CS0
+  0x10410: DEV_CS1
+  0x10418: DEV_CS2
+  0x10420: DEV_CS3
+
+Example:
+
+	devbus-bootcs at d0010400 {
+		status = "okay";
+		ranges = <0 0 0xf0000000 0x1000000>; /* CS0 @addr 0xf0000000, size 0x1000000 */
+		#address-cells = <2>;
+		#size-cells = <1>;
+
+		/* Device Bus parameters are required */
+
+		/* Read parameters */
+		devbus,bus-width    = <8>;
+		devbus,turn-off-ps  = <60000>;
+		devbus,badr-skew-ps = <0>;
+		devbus,acc-first-ps = <124000>;
+		devbus,acc-next-ps  = <248000>;
+		devbus,rd-setup-ps  = <0>;
+		devbus,rd-hold-ps   = <0>;
+
+		/* Write parameters */
+		devbus,sync-enable = <0>;
+		devbus,wr-high-ps  = <60000>;
+		devbus,wr-low-ps   = <60000>;
+		devbus,ale-wr-ps   = <60000>;
+
+		flash at 0 {
+			compatible = "cfi-flash";
+
+			/* CS0, 16 MiB */
+			reg = <0 0 0x1000000>;
+			bank-width = <2>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+
+			/*
+			 * We split the 16 MiB in two partitions,
+			 * just as an example.
+			 */
+			partition at 0 {
+				label = "First";
+				reg = <0 0x800000>;
+			};
+
+			partition at 800000 {
+				label = "Second";
+				reg = <0x800000 0x800000>;
+			};
+		};
+	};
diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig
index 067f311..9a81ab3 100644
--- a/drivers/memory/Kconfig
+++ b/drivers/memory/Kconfig
@@ -20,6 +20,16 @@ config TI_EMIF
 	  parameters and other settings during frequency, voltage and
 	  temperature changes
 
+config MVEBU_DEVBUS
+	tristate "Marvell EBU Device Bus Controller"
+	default y
+	depends on PLAT_ORION && OF
+	help
+	  This driver is for the Device Bus controller available in some
+	  Marvell EBU SoCs such as Discovery (mv78xx0), Orion (88f5xxx) and
+	  Armada 370 and Armada XP. This controller allows to handle flash
+	  devices such as NOR, NAND, SRAM, and FPGA.
+
 config TEGRA20_MC
 	bool "Tegra20 Memory Controller(MC) driver"
 	default y
diff --git a/drivers/memory/Makefile b/drivers/memory/Makefile
index 9cce5d7..969d923 100644
--- a/drivers/memory/Makefile
+++ b/drivers/memory/Makefile
@@ -6,5 +6,6 @@ ifeq ($(CONFIG_DDR),y)
 obj-$(CONFIG_OF)		+= of_memory.o
 endif
 obj-$(CONFIG_TI_EMIF)		+= emif.o
+obj-$(CONFIG_MVEBU_DEVBUS)	+= mvebu-devbus.o
 obj-$(CONFIG_TEGRA20_MC)	+= tegra20-mc.o
 obj-$(CONFIG_TEGRA30_MC)	+= tegra30-mc.o
diff --git a/drivers/memory/mvebu-devbus.c b/drivers/memory/mvebu-devbus.c
new file mode 100644
index 0000000..2f8ce3a
--- /dev/null
+++ b/drivers/memory/mvebu-devbus.c
@@ -0,0 +1,344 @@
+/*
+ * Marvell EBU SoC Device Bus Controller
+ * (memory controller for NOR/NAND/SRAM/FPGA devices)
+ *
+ * Copyright (C) 2013 Marvell
+ *
+ * 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 version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
+ *
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/slab.h>
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/clk.h>
+#include <linux/mbus.h>
+#include <linux/of_platform.h>
+#include <linux/of_address.h>
+#include <linux/platform_device.h>
+
+/* Register definitions */
+#define DEV_WIDTH_BIT		30
+#define BADR_SKEW_BIT		28
+#define RD_HOLD_BIT		23
+#define ACC_NEXT_BIT		17
+#define RD_SETUP_BIT		12
+#define ACC_FIRST_BIT		6
+
+#define SYNC_ENABLE_BIT		24
+#define WR_HIGH_BIT		16
+#define WR_LOW_BIT		8
+
+#define READ_PARAM_OFFSET	0x0
+#define WRITE_PARAM_OFFSET	0x4
+
+static const char * const devbus_wins[] = {
+	"devbus-boot",
+	"devbus-cs0",
+	"devbus-cs1",
+	"devbus-cs2",
+	"devbus-cs3",
+};
+
+struct devbus_read_params {
+	u32 bus_width;
+	u32 badr_skew;
+	u32 turn_off;
+	u32 acc_first;
+	u32 acc_next;
+	u32 rd_setup;
+	u32 rd_hold;
+};
+
+struct devbus_write_params {
+	u32 sync_enable;
+	u32 wr_high;
+	u32 wr_low;
+	u32 ale_wr;
+};
+
+struct devbus {
+	struct device *dev;
+	void __iomem *base;
+	unsigned long tick_ps;
+
+	/*
+	 * Remove this once the allocation window handling
+	 * is moved out of here, to be described in the DT.
+	 */
+	struct resource child_mem;
+	struct platform_device *child;
+};
+
+static int get_timing_param_ps(struct devbus *devbus,
+			       struct device_node *node,
+			       const char *name,
+			       u32 *ticks)
+{
+	u32 time_ps;
+	int err;
+
+	err = of_property_read_u32(node, name, &time_ps);
+	if (err < 0) {
+		dev_err(devbus->dev, "%s has no '%s' property\n",
+			name, node->full_name);
+		return err;
+	}
+
+	*ticks = (time_ps + devbus->tick_ps - 1) / devbus->tick_ps;
+
+	dev_dbg(devbus->dev, "%s: %u ps -> 0x%x\n",
+		name, time_ps, *ticks);
+	return 0;
+}
+
+static int devbus_set_timing_params(struct devbus *devbus,
+				    struct device_node *node)
+{
+	struct devbus_read_params r;
+	struct devbus_write_params w;
+	u32 value;
+	int err;
+
+	dev_dbg(devbus->dev, "Setting timing parameter, tick is %lu ps\n",
+		devbus->tick_ps);
+
+	/* Get read timings */
+	err = of_property_read_u32(node, "devbus,bus-width", &r.bus_width);
+	if (err < 0) {
+		dev_err(devbus->dev,
+			"%s has no 'devbus,bus-width' property\n",
+			node->full_name);
+		return err;
+	}
+	/* Convert bit width to byte width */
+	r.bus_width /= 8;
+
+	err = get_timing_param_ps(devbus, node, "devbus,badr-skew-ps",
+				 &r.badr_skew);
+	if (err < 0)
+		return err;
+
+	err = get_timing_param_ps(devbus, node, "devbus,turn-off-ps",
+				 &r.turn_off);
+	if (err < 0)
+		return err;
+
+	err = get_timing_param_ps(devbus, node, "devbus,acc-first-ps",
+				 &r.acc_first);
+	if (err < 0)
+		return err;
+
+	err = get_timing_param_ps(devbus, node, "devbus,acc-next-ps",
+				 &r.acc_next);
+	if (err < 0)
+		return err;
+
+	err = get_timing_param_ps(devbus, node, "devbus,rd-setup-ps",
+				 &r.rd_setup);
+	if (err < 0)
+		return err;
+
+	err = get_timing_param_ps(devbus, node, "devbus,rd-hold-ps",
+				 &r.rd_hold);
+	if (err < 0)
+		return err;
+
+	/* Get write timings */
+	err = of_property_read_u32(node, "devbus,sync-enable",
+				  &w.sync_enable);
+	if (err < 0) {
+		dev_err(devbus->dev,
+			"%s has no 'devbus,sync-enable' property\n",
+			node->full_name);
+		return err;
+	}
+
+	err = get_timing_param_ps(devbus, node, "devbus,ale-wr-ps",
+				 &w.ale_wr);
+	if (err < 0)
+		return err;
+
+	err = get_timing_param_ps(devbus, node, "devbus,wr-low-ps",
+				 &w.wr_low);
+	if (err < 0)
+		return err;
+
+	err = get_timing_param_ps(devbus, node, "devbus,wr-high-ps",
+				 &w.wr_high);
+	if (err < 0)
+		return err;
+
+	/* Set read timings */
+	value = r.bus_width << DEV_WIDTH_BIT |
+		r.badr_skew << BADR_SKEW_BIT |
+		r.rd_hold   << RD_HOLD_BIT   |
+		r.acc_next  << ACC_NEXT_BIT  |
+		r.rd_setup  << RD_SETUP_BIT  |
+		r.acc_first << ACC_FIRST_BIT |
+		r.turn_off;
+
+	dev_dbg(devbus->dev, "read parameters register 0x%p = 0x%x\n",
+		devbus->base + READ_PARAM_OFFSET,
+		value);
+
+	writel(value, devbus->base + READ_PARAM_OFFSET);
+
+	/* Set write timings */
+	value = w.sync_enable  << SYNC_ENABLE_BIT |
+		w.wr_low       << WR_LOW_BIT      |
+		w.wr_high      << WR_HIGH_BIT     |
+		w.ale_wr;
+
+	dev_dbg(devbus->dev, "write parameters register: 0x%p = 0x%x\n",
+		devbus->base + WRITE_PARAM_OFFSET,
+		value);
+
+	writel(value, devbus->base + WRITE_PARAM_OFFSET);
+
+	return 0;
+}
+
+static int mvebu_devbus_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct device_node *node = pdev->dev.of_node;
+	struct device_node *child;
+	struct devbus *devbus;
+	struct resource *res;
+	struct clk *clk;
+	unsigned long rate;
+	int err, cs;
+
+	devbus = devm_kzalloc(&pdev->dev, sizeof(struct devbus), GFP_KERNEL);
+	if (!devbus)
+		return -ENOMEM;
+
+	devbus->dev = dev;
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	devbus->base = devm_ioremap_resource(&pdev->dev, res);
+	if (IS_ERR(devbus->base))
+		return PTR_ERR(devbus->base);
+
+	clk = devm_clk_get(&pdev->dev, NULL);
+	if (IS_ERR(clk))
+		return PTR_ERR(clk);
+	clk_prepare_enable(clk);
+
+	/*
+	 * Obtain clock period in picoseconds,
+	 * we need this in order to convert timing
+	 * parameters from cycles to picoseconds.
+	 */
+	rate = clk_get_rate(clk) / 1000;
+	devbus->tick_ps = 1000000000 / rate;
+
+	/* We only need the first child */
+	if (of_get_child_count(node) > 1) {
+		dev_err(dev, "%s has more than one child\n", node->full_name);
+		return -EINVAL;
+	}
+
+	child = of_get_next_child(node, NULL);
+	if (!child) {
+		dev_err(dev, "%s has no childs\n", node->full_name);
+		return -EINVAL;
+	}
+
+	/* Read the device tree node and set the new timing parameters */
+	err = devbus_set_timing_params(devbus, node);
+	if (err < 0)
+		return err;
+
+	/*
+	 * Allocate an address window for this device.
+	 * If the device probing fails, then we won't be able to
+	 * remove the allocated address decoding window.
+	 *
+	 * FIXME: This is only a temporary hack! We need to do this here
+	 * because we still don't have device tree bindings for mbus.
+	 * Once that support is added, we will declare these address windows
+	 * statically in the device tree, and remove the window configuration
+	 * from here.
+	 */
+
+	/* Get the CS to choose the window string */
+	err = of_property_read_u32(node, "ranges", &cs);
+	if (err < 0)
+		return err;
+
+	/* Translate the child's memory region to create the window */
+	if (of_address_to_resource(child, 0, &devbus->child_mem)) {
+		dev_err(dev, "%s has malformed 'reg' property\n",
+			child->full_name);
+		return -EINVAL;
+	}
+
+	err = mvebu_mbus_add_window(devbus_wins[cs], devbus->child_mem.start,
+				    resource_size(&devbus->child_mem));
+	if (err < 0)
+		return err;
+
+	devbus->child = of_platform_device_create(child, NULL, &pdev->dev);
+	if (!devbus->child) {
+		dev_warn(dev, "cannot create child device %s\n", child->name);
+		/* Remove the allocated window */
+		mvebu_mbus_del_window(devbus->child_mem.start,
+				      resource_size(&devbus->child_mem));
+	}
+
+	platform_set_drvdata(pdev, devbus);
+
+	return 0;
+}
+
+static int mvebu_devbus_remove(struct platform_device *pdev)
+{
+	struct devbus *devbus = platform_get_drvdata(pdev);
+
+	/* Release device */
+	of_device_unregister(devbus->child);
+
+	/* Release window */
+	mvebu_mbus_del_window(devbus->child_mem.start,
+			      resource_size(&devbus->child_mem));
+
+	devbus->child = NULL;
+	platform_set_drvdata(pdev, NULL);
+
+	return 0;
+}
+
+static const struct of_device_id mvebu_devbus_of_match[] = {
+	{ .compatible = "marvell,mvebu-devbus" },
+	{},
+};
+MODULE_DEVICE_TABLE(of, mvebu_devbus_of_match);
+
+static struct platform_driver mvebu_devbus_driver = {
+	.probe		= mvebu_devbus_probe,
+	.remove		= mvebu_devbus_remove,
+	.driver		= {
+		.name	= "mvebu-devbus",
+		.owner	= THIS_MODULE,
+		.of_match_table = mvebu_devbus_of_match,
+	},
+};
+
+module_platform_driver(mvebu_devbus_driver);
+
+MODULE_LICENSE("GPL v2");
+MODULE_AUTHOR("Ezequiel Garcia <ezequiel.garcia at free-electrons.com>");
+MODULE_DESCRIPTION("Marvell EBU SoC Device Bus controller");
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Mon Apr  8 07:06:31 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Mon,  8 Apr 2013 08:06:31 -0300
Subject: [PATCH v4 2/5] ARM: mvebu: Add Device Bus support for Armada 370/XP
 SoC
In-Reply-To: <1365419194-20871-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1365419194-20871-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1365419194-20871-3-git-send-email-ezequiel.garcia@free-electrons.com>

Armada 370 and Armada XP SoC have a Device Bus controller to
handle NOR, NAND, SRAM and FPGA devices.

This patch adds the device tree nodes to enable the controller,
where each node in the device tree, represents a chip select.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
---
 arch/arm/boot/dts/armada-370-xp.dtsi | 45 ++++++++++++++++++++++++++++++++++++
 1 file changed, 45 insertions(+)

diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi b/arch/arm/boot/dts/armada-370-xp.dtsi
index 7704829..fe90b64 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -176,6 +176,51 @@
 			clocks = <&coreclk 0>;
 			status = "disabled";
 		};
+
+		devbus-bootcs at d0010400 {
+			compatible = "marvell,mvebu-devbus";
+			reg = <0xd0010400 0x8>;
+			#address-cells = <2>;
+			#size-cells = <1>;
+			clocks = <&coreclk 0>;
+			status = "disabled";
+		};
+
+		devbus-cs0 at d0010408 {
+			compatible = "marvell,mvebu-devbus";
+			reg = <0xd0010408 0x8>;
+			#address-cells = <2>;
+			#size-cells = <1>;
+			clocks = <&coreclk 0>;
+			status = "disabled";
+		};
+
+		devbus-cs1 at d0010410 {
+			compatible = "marvell,mvebu-devbus";
+			reg = <0xd0010410 0x8>;
+			#address-cells = <2>;
+			#size-cells = <1>;
+			clocks = <&coreclk 0>;
+			status = "disabled";
+		};
+
+		devbus-cs2 at d0010418 {
+			compatible = "marvell,mvebu-devbus";
+			reg = <0xd0010418 0x8>;
+			#address-cells = <2>;
+			#size-cells = <1>;
+			clocks = <&coreclk 0>;
+			status = "disabled";
+		};
+
+		devbus-cs3 at d0010420 {
+			compatible = "marvell,mvebu-devbus";
+			reg = <0xd0010420 0x8>;
+			#address-cells = <2>;
+			#size-cells = <1>;
+			clocks = <&coreclk 0>;
+			status = "disabled";
+		};
 	};
 };
 
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Mon Apr  8 07:06:32 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Mon,  8 Apr 2013 08:06:32 -0300
Subject: [PATCH v4 3/5] ARM: mvebu: Add support for NOR flash device on Armada
 XP-GP board
In-Reply-To: <1365419194-20871-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1365419194-20871-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1365419194-20871-4-git-send-email-ezequiel.garcia@free-electrons.com>

The Armada XP Development Board DB-MV784MP-GP has a NOR flash device
connected to the Device Bus. This commit adds the device tree node
to support this device.

This SoC supports a flexible and dynamic decoding window allocation
scheme; but since this feature is still not implemented we need
to specify the window base address in the device tree node itself.

This base address has been selected in a completely arbitrary fashion.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
---
 arch/arm/boot/dts/armada-xp-gp.dts | 29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)

diff --git a/arch/arm/boot/dts/armada-xp-gp.dts b/arch/arm/boot/dts/armada-xp-gp.dts
index 1c8afe2..39f6a4d 100644
--- a/arch/arm/boot/dts/armada-xp-gp.dts
+++ b/arch/arm/boot/dts/armada-xp-gp.dts
@@ -109,5 +109,34 @@
 				spi-max-frequency = <108000000>;
 			};
 		};
+
+		devbus-bootcs at d0010400 {
+			status = "okay";
+			ranges = <0 0 0xf0000000 0x1000000>; /* CS0 @addr 0xf000000, size 0x1000000 */
+
+			/* Device Bus parameters are required */
+
+			/* Read parameters */
+			devbus,bus-width    = <8>;
+			devbus,turn-off-ps  = <60000>;
+			devbus,badr-skew-ps = <0>;
+			devbus,acc-first-ps = <124000>;
+			devbus,acc-next-ps  = <248000>;
+			devbus,rd-setup-ps  = <0>;
+			devbus,rd-hold-ps   = <0>;
+
+			/* Write parameters */
+			devbus,sync-enable = <0>;
+			devbus,wr-high-ps  = <60000>;
+			devbus,wr-low-ps   = <60000>;
+			devbus,ale-wr-ps   = <60000>;
+
+			/* NOR 16 MiB */
+			nor at 0 {
+				compatible = "cfi-flash";
+				reg = <0 0 0x1000000>;
+				bank-width = <2>;
+			};
+		};
 	};
 };
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Mon Apr  8 07:06:33 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Mon,  8 Apr 2013 08:06:33 -0300
Subject: [PATCH v4 4/5] ARM: mvebu: Add support for NOR flash device on
 Openblocks AX3 board
In-Reply-To: <1365419194-20871-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1365419194-20871-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1365419194-20871-5-git-send-email-ezequiel.garcia@free-electrons.com>

The Plat'home Openblocks AX3 has a 128 MiB NOR flash device connected
to the Device Bus. This commit adds the device tree node to support this device.

The SoC supports a flexible and dynamic decoding window allocation scheme;
but since this feature is still not implemented we need to specify the window
base address in the device tree node itself.
This base address has been selected in a completely arbitrary fashion.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
---
 arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 29 ++++++++++++++++++++++++
 1 file changed, 29 insertions(+)

diff --git a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
index 3818a82..04576c2 100644
--- a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
+++ b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
@@ -139,5 +139,34 @@
 		usb at d0051000 {
 			status = "okay";
 		};
+
+		devbus-bootcs at d0010400 {
+			status = "okay";
+			ranges = <0 0 0xf0000000 0x8000000>; /* CS0 @addr 0xf000000, size 0x8000000 */
+
+			/* Device Bus parameters are required */
+
+			/* Read parameters */
+			devbus,bus-width    = <8>;
+			devbus,turn-off-ps  = <60000>;
+			devbus,badr-skew-ps = <0>;
+			devbus,acc-first-ps = <124000>;
+			devbus,acc-next-ps  = <248000>;
+			devbus,rd-setup-ps  = <0>;
+			devbus,rd-hold-ps   = <0>;
+
+			/* Write parameters */
+			devbus,sync-enable = <0>;
+			devbus,wr-high-ps  = <60000>;
+			devbus,wr-low-ps   = <60000>;
+			devbus,ale-wr-ps   = <60000>;
+
+			/* NOR 128 MiB */
+			nor at 0 {
+				compatible = "cfi-flash";
+				reg = <0 0 0x8000000>;
+				bank-width = <2>;
+			};
+		};
 	};
 };
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Mon Apr  8 07:06:34 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Mon,  8 Apr 2013 08:06:34 -0300
Subject: [PATCH v4 5/5] ARM: mvebu: Add Device Bus and CFI flash memory
 support to defconfig
In-Reply-To: <1365419194-20871-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1365419194-20871-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1365419194-20871-6-git-send-email-ezequiel.garcia@free-electrons.com>

This patch selects the devbus driver as part of the mvebu default
config, along with the required options to detect and support
CFI flash memories.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
---
 arch/arm/configs/mvebu_defconfig | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/configs/mvebu_defconfig b/arch/arm/configs/mvebu_defconfig
index 2ec8119..fe8ba26 100644
--- a/arch/arm/configs/mvebu_defconfig
+++ b/arch/arm/configs/mvebu_defconfig
@@ -46,6 +46,11 @@ CONFIG_I2C_MV64XXX=y
 CONFIG_MTD=y
 CONFIG_MTD_CHAR=y
 CONFIG_MTD_M25P80=y
+CONFIG_MTD_CFI=y
+CONFIG_MTD_CFI_INTELEXT=y
+CONFIG_MTD_CFI_AMDSTD=y
+CONFIG_MTD_CFI_STAA=y
+CONFIG_MTD_PHYSMAP_OF=y
 CONFIG_SERIAL_8250_DW=y
 CONFIG_GPIOLIB=y
 CONFIG_GPIO_SYSFS=y
@@ -65,6 +70,8 @@ CONFIG_RTC_DRV_S35390A=y
 CONFIG_RTC_DRV_MV=y
 CONFIG_DMADEVICES=y
 CONFIG_MV_XOR=y
+CONFIG_MEMORY=y
+CONFIG_MVEBU_DEVBUS=y
 # CONFIG_IOMMU_SUPPORT is not set
 CONFIG_EXT2_FS=y
 CONFIG_EXT3_FS=y
-- 
1.8.1.5



From plagnioj at jcrosoft.com  Mon Apr  8 07:08:55 2013
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Mon, 8 Apr 2013 13:08:55 +0200
Subject: [RFC 4/5] RTC: rtc-at91sam9: add device-tree support
In-Reply-To: <20130408104823.GF25605@localhost>
References: <20130407150938.GA25605@localhost>
 <1365347572-14972-1-git-send-email-jhovold@gmail.com>
 <1365347572-14972-4-git-send-email-jhovold@gmail.com>
 <20130408073807.GQ20693@game.jcrosoft.org>
 <20130408090023.GC25605@localhost> <51629472.3070404@atmel.com>
 <20130408100301.GS20693@game.jcrosoft.org>
 <20130408104823.GF25605@localhost>
Message-ID: <20130408110855.GW20693@game.jcrosoft.org>

On 12:48 Mon 08 Apr     , Johan Hovold wrote:
> On Mon, Apr 08, 2013 at 12:03:01PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > On 11:57 Mon 08 Apr     , Nicolas Ferre wrote:
> > > On 04/08/2013 11:00 AM, Johan Hovold :
> > > > On Mon, Apr 08, 2013 at 09:38:07AM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > > >> On 17:12 Sun 07 Apr     , Johan Hovold wrote:
> 
> [...]
> 
> > > >> the RTT is a general purpose timer backuped that we use in linux as a
> > > >> RTC with a gpbr to store the time
> > > >>
> > > >> you need 2 binding on for the RTT one the RTT-rtc
> > > > 
> > > > As in adding some virtual hardware-node which uses the rtt and gpbr as
> > > > resources?
> > > 
> > > So, why not simply having a compatibility string that collects the uses
> > > of this RTT node:
> > > 
> > > compatible = "atmel,at91sam9260-rtt-as-rtc", "atmel,at91sam9260-rtt";
> > > 
> > > And then "decide which device driver to bind to [the RTT] device"...
> > > If the rtt-as-rtc driver is not selected, the device can still be used
> > > as a simple "rtt". The board .dts can overload a compatibility string
> > > according to the use, etc.
> > > 
> > > Then the way do describe which GPBR to use has still to be discussed.
> > > But for the RTT itself, I would keep it simple like that.
> > 
> > no as infact the rtc-at91sam9 should not even exist
> > as this is much more generic
> > 
> > we use a backped register and a timer to emulate a RTC this can be unsed by
> > any one
> > 
> > and I can use any backuped timer
> > 
> > we need to have frameworks
> > where the gpbr are tracked and the rtt
> > 
> > 	for you describe the resources
> > 
> > 	rtt0: rtt at fffffd20 {
> > 		compatible = "atmel,at91sam9260-rtt";
> > 		reg = <0xfffffd20 0x10>;
> > 		interrupts = <1 4 7>;
> > 	};
> > 
> > 	rtc-timer {
> > 		compatible = "linux,rtc-timer";
> > 		timer = <&rtt0>;
> > 		backuped-register = <&gpbr 0>;
> > 	};
> > 
> > this need to SoC implemetation generic
> 
> This would indeed be a neat solution, albeit one that requires a lot
> work to be realised as both a backup-register and backed-up-timer
> framework would need to be implemented.

not that much

for backuped register or rtt a simple list with spinlock will be enougth
and after just handle the phandle

it's not that complex but if we want to describe the hardware correctly this
is needed

And this will not be AT91 specific but SoC generic

Ensure the GPBR are requested once is mandatory for any bug detection
a global ioremap is really dirty and need to be used when only NO other choice

Best Regards,
J.
> 
> Bye,
> -- 
> Nicolas Ferre
> 
> Thanks,
> Johan


From plagnioj at jcrosoft.com  Mon Apr  8 07:11:13 2013
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Mon, 8 Apr 2013 13:11:13 +0200
Subject: [RFC 4/5] RTC: rtc-at91sam9: add device-tree support
In-Reply-To: <20130408103847.GE25605@localhost>
References: <20130407150938.GA25605@localhost>
 <1365347572-14972-1-git-send-email-jhovold@gmail.com>
 <1365347572-14972-4-git-send-email-jhovold@gmail.com>
 <20130408073807.GQ20693@game.jcrosoft.org>
 <20130408090023.GC25605@localhost> <51629472.3070404@atmel.com>
 <20130408103847.GE25605@localhost>
Message-ID: <20130408111113.GX20693@game.jcrosoft.org>

On 12:38 Mon 08 Apr     , Johan Hovold wrote:
> On Mon, Apr 08, 2013 at 11:57:06AM +0200, Nicolas Ferre wrote:
> > On 04/08/2013 11:00 AM, Johan Hovold :
> > > On Mon, Apr 08, 2013 at 09:38:07AM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > >> On 17:12 Sun 07 Apr     , Johan Hovold wrote:
> > >>> Add device-tree support.
> > >>>
> > >>> The AT91 RTT can be used as an RTC if the atmel,at91-rtt-as-rtc-gpbr
> > >>> property is present and set to the general-purpose backup register to
> > >>> use to store the RTC time base.
> > >>>
> > >>> Signed-off-by: Johan Hovold <jhovold at gmail.com>
> > >>> ---
> > >>>  .../devicetree/bindings/rtc/rtc-at91sam9.txt       | 19 ++++++++++++
> > >>>  drivers/rtc/rtc-at91sam9.c                         | 36 +++++++++++++++++++++-
> > >>>  2 files changed, 54 insertions(+), 1 deletion(-)
> > >>>  create mode 100644 Documentation/devicetree/bindings/rtc/rtc-at91sam9.txt > >>>
> > >>> diff --git
> > >>> a/Documentation/devicetree/bindings/rtc/rtc-at91sam9.txt
> > >>> b/Documentation/devicetree/bindings/rtc/rtc-at91sam9.txt > >>> new
> > >>> file mode 100644
> > >>> index 0000000..0f54988
> > >>> --- /dev/null
> > >>> +++ b/Documentation/devicetree/bindings/rtc/rtc-at91sam9.txt
> > >>> @@ -0,0 +1,19 @@
> > >>> +Atmel AT91 RTT as RTC
> > >>> +=====================
> > >>> +
> > >>> +Required properties:
> > >>> +- compatible: Should be "atmel,at91sam9260-rtt"
> > >>> +- reg: Should contain register location and length
> > >>> +- interrupts: Should contain interrupt for the RTT which is the IRQ line
> > >>> +  shared across all System Controller members.
> > >>> +- atmel,rtt-as-rtc-gpbr: Should contain the backup-register to use to store
> > >>> +  the RTC time base
> > >>> +
> > >>> +Example:
> > >>> +
> > >>> +rtt at fffffd20 {
> > >>> +		compatible = "atmel,at91sam9g45-rtt", "atmel,at91sam9260-rtt";
> > 
> > No, there is no visible difference between the sam9g45 RTT and the
> > sam9260 one. So the most precise compatibility string is still sam9260.
> > If one day we feel the need for a advanced feature that exists on a more
> > recent SoC, we have the possibility to add it at that time...
> 
> Yes, this should be just "atmel,at91sam9260-rtt" to follow the current
> practise in AT91. However, as I mentioned in an earlier mail one could
> interpret
> 
> 	"The first string in the list specifies the exact device that
> 	the node represents in the form "<manufacturer>,<model>". The
> 	following strings represent other devices that the device is
> 	compatible with.
> 
> 	For example, the Freescale MPC8349 System on Chip (SoC) has a
> 	serial device which implements the National Semiconductor
> 	ns16550 register interface. The compatible property for the
> 	MPC8349 serial device should therefore be: compatible =
> 	"fsl,mpc8349-uart", "ns16550". In this case, fsl,mpc8349-uart
> 	specifies the exact device, and ns16550 states that it is
> 	register-level compatible with a National Semiconductor 16550
> 	UART."
> 
> 	http://www.devicetree.org/Device_Tree_Usage#Understanding_the_compatible_Property
> 
> to mean that the compatible property should always be exact SoC-IP
> followed by the first (most generic) compatible one.
here you describe compatible IP not drivers implementation

they are both usuart IP that are compatible at IP level.

Best Regards,
J.


From g.liakhovetski at gmx.de  Mon Apr  8 07:25:46 2013
From: g.liakhovetski at gmx.de (Guennadi Liakhovetski)
Date: Mon, 8 Apr 2013 13:25:46 +0200 (CEST)
Subject: [PATCH v3] irqchip: renesas-intc-irqpin: DT binding for sense
 bitfield width
In-Reply-To: <1694336.shM2ct4pzX@avalon>
References: <Pine.LNX.4.64.1304081002190.29945@axis700.grange>
 <1694336.shM2ct4pzX@avalon>
Message-ID: <Pine.LNX.4.64.1304081324370.29945@axis700.grange>

On Mon, 8 Apr 2013, Laurent Pinchart wrote:

> Hi Guennadi,
> 
> Thanks for the patch.
> 
> On Monday 08 April 2013 10:08:40 Guennadi Liakhovetski wrote:
> > Most Renesas irqpin controllers have 4-bit sense fields, however, some
> > have different widths. This patch adds a DT binding to optionally
> > specify such non-standard values.
> > 
> > Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas at gmail.com>
> > ---
> > 
> > v3: move the code to a common location, where device configuration
> > parameters are retrieved
> > 
> >  .../interrupt-controller/renesas,intc-irqpin.txt   |   13 +++++++++++++
> >  drivers/irqchip/irq-renesas-intc-irqpin.c          |    4 ++++
> >  2 files changed, 17 insertions(+), 0 deletions(-)
> >  create mode 100644
> > Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.
> > txt
> > 
> > diff --git
> > a/Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpi
> > n.txt
> > b/Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpi
> > n.txt new file mode 100644
> > index 0000000..c6f09b7
> > --- /dev/null
> > +++
> > b/Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpi
> > n.txt @@ -0,0 +1,13 @@
> > +DT bindings for the R-/SH-Mobile irqpin controller
> > +
> > +Required properties:
> > +
> > +- compatible: has to be "renesas,intc-irqpin"
> > +- #interrupt-cells: has to be <2>
> > +
> > +Optional properties:
> > +
> > +- any properties, listed in interrupts.txt in this directory, and any
> > standard
> > +  resource allocation properties
> > +- sense-bitfield-width: width of a single sense bitfield in the SENSE
> > register,
> > +  if different from the default 4 bits
> 
> Wouldn't it be better to define per-SoC compatible strings, and infer the 
> sense bitfield width from that ?

This is not a boolean, it is an integer, I don't think defining 
compatibility strings for 1, 2, 3, 4, 5,... bits is better than having one 
integer property.

Thanks
Guennadi

> 
> > diff --git a/drivers/irqchip/irq-renesas-intc-irqpin.c
> > b/drivers/irqchip/irq-renesas-intc-irqpin.c index 5a68e5a..4aca1b2 100644
> > --- a/drivers/irqchip/irq-renesas-intc-irqpin.c
> > +++ b/drivers/irqchip/irq-renesas-intc-irqpin.c
> > @@ -18,6 +18,7 @@
> >   */
> > 
> >  #include <linux/init.h>
> > +#include <linux/of.h>
> >  #include <linux/platform_device.h>
> >  #include <linux/spinlock.h>
> >  #include <linux/interrupt.h>
> > @@ -349,6 +350,9 @@ static int intc_irqpin_probe(struct platform_device
> > *pdev) /* deal with driver instance configuration */
> >  	if (pdata)
> >  		memcpy(&p->config, pdata, sizeof(*pdata));
> > +	else
> > +		of_property_read_u32(pdev->dev.of_node, "sense-bitfield-width",
> > +				     &p->config.sense_bitfield_width);
> >  	if (!p->config.sense_bitfield_width)
> >  		p->config.sense_bitfield_width = 4; /* default to 4 bits */
> -- 
> Regards,
> 
> Laurent Pinchart
> 

---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/


From dt.tangr at gmail.com  Mon Apr  8 07:33:43 2013
From: dt.tangr at gmail.com (Daniel Tang)
Date: Mon, 8 Apr 2013 21:33:43 +1000
Subject: [RFC PATCH arm: initial TI-Nspire support]
In-Reply-To: <201304072323.42173.arnd@arndb.de>
References: <6FE4B33E-A503-4A75-AEED-831CB2C06D83@gmail.com>
 <4B3FD561-84FC-40CD-B747-13851692D673@gmail.com>
 <521DFDFC-7E9E-47EA-ACDA-C91BBDC8454E@gmail.com>
 <201304072323.42173.arnd@arndb.de>
Message-ID: <896CB251-17FC-4327-BA4E-A8FD9ED1BEC7@gmail.com>

Changes:

 * Moved CLCD stuff to separate file until DT support for PL11x comes along
 * Whitespace cleanup in arch/arm/Makefile removed from patch
 * Rewrote code to find SP804 devices and use the first available one as a clockevent and the rest as clock sources until DT support comes to the SP804 driver.
 * Fix up platform selection in Kconfig. TI-NSPIRE based option was visible even when ARCH_MULTI_V4_V5 is not selected.
 * Added keypad driver and keymap
 * Support for 'make dtbs'

Signed-off-by: Daniel Tang <dt.tangr at gmail.com>
---
 arch/arm/Kconfig                            |   2 +
 arch/arm/Kconfig.debug                      |  16 ++
 arch/arm/Makefile                           |   1 +
 arch/arm/boot/dts/Makefile                  |   1 +
 arch/arm/boot/dts/nspire-cx.dts             | 110 ++++++++++
 arch/arm/boot/dts/nspire.dtsi               | 168 +++++++++++++++
 arch/arm/include/debug/nspire.S             |  28 +++
 arch/arm/mach-nspire/Kconfig                |  14 ++
 arch/arm/mach-nspire/Makefile               |   2 +
 arch/arm/mach-nspire/Makefile.boot          |   0
 arch/arm/mach-nspire/clcd.c                 | 123 +++++++++++
 arch/arm/mach-nspire/clcd.h                 |  14 ++
 arch/arm/mach-nspire/mmio.h                 |  15 ++
 arch/arm/mach-nspire/nspire.c               | 139 ++++++++++++
 drivers/input/keyboard/Kconfig              |  10 +
 drivers/input/keyboard/Makefile             |   1 +
 drivers/input/keyboard/nspire-keypad.c      | 318 ++++++++++++++++++++++++++++
 include/linux/platform_data/nspire-keypad.h |  28 +++
 18 files changed, 990 insertions(+)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 1cacda4..3f0cd8c 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1081,6 +1081,8 @@ source "arch/arm/mach-netx/Kconfig"
 
 source "arch/arm/mach-nomadik/Kconfig"
 
+source "arch/arm/mach-nspire/Kconfig"
+
 source "arch/arm/plat-omap/Kconfig"
 
 source "arch/arm/mach-omap1/Kconfig"
diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 9b31f43..5da3a50 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -298,6 +298,20 @@ choice
 		  Say Y here if you want kernel low-level debugging support
 		  on MVEBU based platforms.
 
+	config DEBUG_NSPIRE_CLASSIC_UART
+		bool "Kernel low-level debugging via TI-NSPIRE 8250 UART"
+		depends on ARCH_NSPIRE
+		help
+		  Say Y here if you want kernel low-level debugging support
+		  on TI-NSPIRE classic models.
+
+	config DEBUG_NSPIRE_CX_UART
+		bool "Kernel low-level debugging via TI-NSPIRE PL011 UART"
+		depends on ARCH_NSPIRE
+		help
+		  Say Y here if you want kernel low-level debugging support
+		  on TI-NSPIRE CX models.
+
 	config DEBUG_OMAP2PLUS_UART
 		bool "Kernel low-level debugging messages via OMAP2PLUS UART"
 		depends on ARCH_OMAP2PLUS
@@ -591,6 +605,8 @@ config DEBUG_LL_INCLUDE
 				 DEBUG_IMX6Q_UART
 	default "debug/highbank.S" if DEBUG_HIGHBANK_UART
 	default "debug/mvebu.S" if DEBUG_MVEBU_UART
+	default "debug/nspire.S" if 	DEBUG_NSPIRE_CX_UART || \
+					DEBUG_NSPIRE_CLASSIC_UART
 	default "debug/omap2plus.S" if DEBUG_OMAP2PLUS_UART
 	default "debug/picoxcell.S" if DEBUG_PICOXCELL_UART
 	default "debug/socfpga.S" if DEBUG_SOCFPGA_UART
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index ee4605f..2580d2b 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -165,6 +165,7 @@ machine-$(CONFIG_ARCH_MXS)		+= mxs
 machine-$(CONFIG_ARCH_MVEBU)		+= mvebu
 machine-$(CONFIG_ARCH_NETX)		+= netx
 machine-$(CONFIG_ARCH_NOMADIK)		+= nomadik
+machine-$(CONFIG_ARCH_NSPIRE)		+= nspire
 machine-$(CONFIG_ARCH_OMAP1)		+= omap1
 machine-$(CONFIG_ARCH_OMAP2PLUS)	+= omap2
 machine-$(CONFIG_ARCH_ORION5X)		+= orion5x
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 9c62558..adf8116 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -114,6 +114,7 @@ dtb-$(CONFIG_ARCH_MXS) += imx23-evk.dtb \
 	imx28-sps1.dtb \
 	imx28-tx28.dtb
 dtb-$(CONFIG_ARCH_NOMADIK) += ste-nomadik-s8815.dtb
+dtb-$(CONFIG_ARCH_NSPIRE) += nspire-cx.dtb
 dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
 	omap3-beagle.dtb \
 	omap3-beagle-xm.dtb \
diff --git a/arch/arm/boot/dts/nspire-cx.dts b/arch/arm/boot/dts/nspire-cx.dts
new file mode 100644
index 0000000..1da2e44
--- /dev/null
+++ b/arch/arm/boot/dts/nspire-cx.dts
@@ -0,0 +1,110 @@
+/*
+ *  linux/arch/arm/boot/nspire-cx.dts
+ *
+ *  Copyright (C) 2012 Daniel Tang <tangrs at tangrs.id.au>
+ *
+ * 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.
+ *
+ */
+/dts-v1/;
+
+/include/ "nspire.dtsi"
+
+/ {
+	model = "TI-NSPIRE CX";
+	compatible = "arm,nspire-cx";
+
+	memory {
+		device_type = "memory";
+		reg = <0x10000000 0x4000000>; /* 64 MB */
+	};
+
+	uart_clk: uart_clk {
+		#clock-cells = <0>;
+		compatible = "fixed-clock";
+		clock-frequency = <12000000>;
+	};
+
+	/* Not really a fixed clock but we'll fix this later */
+	apb_pclk: apb_pclk {
+		#clock-cells = <0>;
+		compatible = "fixed-clock";
+		clock-frequency = <33000000>;
+	};
+
+	ahb {
+		#address-cells = <1>;
+		#size-cells = <1>;
+
+		intc: interrupt-controller at DC000000 {
+			compatible = "arm,pl190-vic";
+			interrupt-controller;
+			reg = <0xDC000000 0x1000>;
+			#interrupt-cells = <1>;
+		};
+
+		lcd: lcd at C0000000 {
+			lcd-type = "cx";
+		};
+
+		apb at 90000000 {
+			#address-cells = <1>;
+			#size-cells = <1>;
+
+			i2c at 90050000 {
+				compatible = "snps,designware-i2c";
+				reg = <0x90050000 0x1000>;
+				interrupts = <20>;
+			};
+
+			/*
+			fast_timer: timer at 90010000 {
+				compatible = "arm,sp804", "arm,primecell";
+			};
+			*/
+
+			uart0: serial at 90020000 {
+				compatible = "arm,pl011", "arm,primecell";
+			};
+
+			timer0: timer at 900C0000 {
+				compatible = "arm,sp804", "arm,primecell";
+			};
+
+			timer1: timer at 900D0000 {
+				compatible = "arm,sp804", "arm,primecell";
+			};
+
+			keypad: input at 900E0000 {
+				keymap = <
+				0x0000001c 	0x0001001c 	0x00040039
+				0x0005002c 	0x00060015 	0x0007000b
+				0x0008000f 	0x0100002d 	0x01010011
+				0x0102002f 	0x01030004 	0x01040016
+				0x01050014 	0x0106001f 	0x01070002
+				0x010a006a 	0x02000013 	0x02010010
+				0x02020019 	0x02030007 	0x02040018
+				0x02050031 	0x02060032 	0x02070005
+				0x02080028 	0x0209006c 	0x03000026
+				0x03010025 	0x03020024 	0x0303000a
+				0x03040017 	0x03050023 	0x03060022
+				0x03070008 	0x03080035 	0x03090069
+				0x04000021 	0x04010012 	0x04020020
+				0x0404002e 	0x04050030 	0x0406001e
+				0x0407000d 	0x04080037 	0x04090067
+				0x05010038 	0x0502000c 	0x0503001b
+				0x05040034 	0x0505001a 	0x05060006
+				0x05080027 	0x0509000e 	0x050a006f
+				0x0600002b 	0x0602004e 	0x06030068
+				0x06040003 	0x0605006d 	0x06060009
+				0x06070001 	0x0609000f 	0x0708002a
+				0x0709001d 	0x070a0033 	>;
+			};
+		};
+	};
+	chosen {
+		bootargs = "debug earlyprintk console=tty0 console=ttyAMA0,115200n8 root=/dev/ram0";
+	};
+};
diff --git a/arch/arm/boot/dts/nspire.dtsi b/arch/arm/boot/dts/nspire.dtsi
new file mode 100644
index 0000000..d745e3d
--- /dev/null
+++ b/arch/arm/boot/dts/nspire.dtsi
@@ -0,0 +1,168 @@
+/*
+ *  linux/arch/arm/boot/nspire.dtsi
+ *
+ *  Copyright (C) 2012 Daniel Tang <tangrs at tangrs.id.au>
+ *
+ * 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/ "skeleton.dtsi"
+
+/ {
+	interrupt-parent = <&intc>;
+
+	cpus {
+		cpu at 0 {
+			compatible = "arm,arm926ejs";
+		};
+	};
+
+	bootrom: bootrom at 00000000 {
+		reg = <0x00000000 0x80000>;
+	};
+
+	sram: sram at A4000000 {
+		device = "memory";
+		reg = <0xA4000000 0x20000>;
+	};
+
+	timer_clk: timer_clk {
+		#clock-cells = <0>;
+		compatible = "fixed-clock";
+		clock-frequency = <32768>;
+	};
+
+	lcd_clk: lcd_clk {
+		#clock-cells = <0>;
+		compatible = "fixed-clock";
+		clock-frequency = <660000000>;
+	};
+
+	ahb {
+		compatible = "simple-bus";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges;
+
+		spi: spi at A9000000 {
+			reg = <0xA9000000 0x1000>;
+		};
+
+		usb0: usb at B0000000 {
+			reg = <0xB0000000 0x1000>;
+			interrupts = <8>;
+		};
+
+		usb1: usb at B4000000 {
+			reg = <0xB4000000 0x1000>;
+			interrupts = <9>;
+			status = "disabled";
+		};
+
+		lcd: lcd at C0000000 {
+			compatible = "arm,pl111", "arm,primecell";
+			reg = <0xC0000000 0x1000>;
+			interrupts = <21>;
+
+			clocks = <&lcd_clk>;
+			clock-names = "apb_pclk";
+		};
+
+		adc: adc at C4000000 {
+			reg = <0xC4000000 0x1000>;
+			interrupts = <11>;
+		};
+
+		tdes: crypto at C8010000 {
+			reg = <0xC8010000 0x1000>;
+		};
+
+		sha256: crypto at CC000000 {
+			reg = <0xCC000000 0x1000>;
+		};
+
+		apb at 90000000 {
+			compatible = "simple-bus";
+			#address-cells = <1>;
+			#size-cells = <1>;
+			clock-ranges;
+			ranges;
+
+			gpio: gpio at 90000000 {
+				reg = <0x90000000 0x1000>;
+				interrupts = <7>;
+			};
+
+			fast_timer: timer at 90010000 {
+				reg = <0x90010000 0x1000>;
+				interrupts = <17>;
+			};
+
+			uart: serial at 90020000 {
+				reg = <0x90020000 0x1000>;
+				interrupts = <1>;
+
+				clocks = <&uart_clk>, <&apb_pclk>;
+				clock-names = "uart_clk", "apb_pclk";
+			};
+
+			timer0: timer at 900C0000 {
+				reg = <0x900C0000 0x1000>;
+
+				clocks = <&timer_clk>;
+				clock-names = "timer_clk";
+			};
+
+			timer1: timer at 900D0000 {
+				reg = <0x900D0000 0x1000>;
+				interrupts = <19>;
+
+				clocks = <&timer_clk>;
+				clock-names = "timer_clk";
+			};
+
+			watchdog: watchdog at 90060000 {
+				compatible = "arm,amba-primecell";
+				reg = <0x90060000 0x1000>;
+				interrupts = <3>;
+			};
+
+			rtc: rtc at 90090000 {
+				reg = <0x90090000 0x1000>;
+				interrupts = <4>;
+			};
+
+			misc: misc at 900A0000 {
+				reg = <0x900A0000 0x1000>;
+			};
+
+			pwr: pwr at 900B0000 {
+				reg = <0x900B0000 0x1000>;
+				interrupts = <15>;
+			};
+
+			keypad: input at 900E0000 {
+				compatible = "nspire-keypad";
+				reg = <0x900E0000 0x1000>;
+				interrupts = <16>;
+
+				scan-interval = <1000>;
+				row-delay = <200>;
+
+				clocks = <&apb_pclk>;
+				clock-names = "apb_pclk";
+			};
+
+			contrast: contrast at 900F0000 {
+				reg = <0x900F0000 0x1000>;
+			};
+
+			led: led at 90110000 {
+				reg = <0x90110000 0x1000>;
+			};
+		};
+	};
+};
diff --git a/arch/arm/include/debug/nspire.S b/arch/arm/include/debug/nspire.S
new file mode 100644
index 0000000..3a9729c
--- /dev/null
+++ b/arch/arm/include/debug/nspire.S
@@ -0,0 +1,28 @@
+/*
+ *	linux/arch/arm/include/debug/nspire.S
+ *
+ *	Copyright (C) 2012 Daniel Tang <tangrs at tangrs.id.au>
+ *
+ * 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.
+ *
+ */
+
+#define NSPIRE_EARLY_UART_PHYS_BASE	   0x90020000
+#define NSPIRE_EARLY_UART_VIRT_BASE	   0xfee20000
+
+.macro	addruart, rp, rv, tmp
+	ldr \rp, =(NSPIRE_EARLY_UART_PHYS_BASE)		@ physical base address
+	ldr \rv, =(NSPIRE_EARLY_UART_VIRT_BASE)		@ virtual base address
+.endm
+
+
+#ifdef CONFIG_DEBUG_NSPIRE_CX_UART
+#include <asm/hardware/debug-pl01x.S>
+#endif
+
+#ifdef CONFIG_DEBUG_NSPIRE_CLASSIC_UART
+#define UART_SHIFT 2
+#include <asm/hardware/debug-8250.S>
+#endif
diff --git a/arch/arm/mach-nspire/Kconfig b/arch/arm/mach-nspire/Kconfig
new file mode 100644
index 0000000..d485280
--- /dev/null
+++ b/arch/arm/mach-nspire/Kconfig
@@ -0,0 +1,14 @@
+config ARCH_NSPIRE
+	bool "TI-NSPIRE based"
+	depends on ARCH_MULTI_V4_V5
+	depends on MMU
+	select CPU_ARM926T
+	select COMMON_CLK
+	select GENERIC_CLOCKEVENTS
+	select SPARSE_IRQ
+	select ARM_AMBA
+	select ARM_VIC
+	select ARM_TIMER_SP804
+	select USE_OF
+	help
+	  This enables support for systems using the TI-NSPIRE CPU
diff --git a/arch/arm/mach-nspire/Makefile b/arch/arm/mach-nspire/Makefile
new file mode 100644
index 0000000..1bec256
--- /dev/null
+++ b/arch/arm/mach-nspire/Makefile
@@ -0,0 +1,2 @@
+obj-y				+= nspire.o
+obj-y				+= clcd.o
diff --git a/arch/arm/mach-nspire/Makefile.boot b/arch/arm/mach-nspire/Makefile.boot
new file mode 100644
index 0000000..e69de29
diff --git a/arch/arm/mach-nspire/clcd.c b/arch/arm/mach-nspire/clcd.c
new file mode 100644
index 0000000..ee6ffcb
--- /dev/null
+++ b/arch/arm/mach-nspire/clcd.c
@@ -0,0 +1,123 @@
+/*
+ *	linux/arch/arm/mach-nspire/clcd.c
+ *
+ *	Copyright (C) 2012 Daniel Tang <tangrs at tangrs.id.au>
+ *
+ * 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/init.h>
+#include <linux/of.h>
+#include <linux/amba/bus.h>
+#include <linux/amba/clcd.h>
+#include <linux/dma-mapping.h>
+
+static struct clcd_panel nspire_cx_lcd_panel = {
+	.mode		= {
+		.name		= "Color LCD",
+		.refresh	= 60,
+		.xres		= 320,
+		.yres		= 240,
+		.sync		= 0,
+		.vmode		= FB_VMODE_NONINTERLACED,
+		.pixclock	= 1,
+		.hsync_len	= 6,
+		.vsync_len	= 1,
+		.right_margin	= 50,
+		.left_margin	= 38,
+		.lower_margin	= 3,
+		.upper_margin	= 17,
+	},
+	.width		= 65, /* ~6.50 cm */
+	.height		= 49, /* ~4.87 cm */
+	.tim2		= TIM2_IPC,
+	.cntl		= (CNTL_BGR | CNTL_LCDTFT | CNTL_LCDVCOMP(1) |
+				CNTL_LCDBPP16_565),
+	.bpp		= 16,
+};
+
+static struct clcd_panel nspire_classic_lcd_panel = {
+	.mode		= {
+		.name		= "Grayscale LCD",
+		.refresh	= 60,
+		.xres		= 320,
+		.yres		= 240,
+		.sync		= FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,
+		.vmode		= FB_VMODE_NONINTERLACED,
+		.pixclock	= 1,
+		.hsync_len	= 6,
+		.vsync_len	= 1,
+		.right_margin	= 6,
+		.left_margin	= 6,
+	},
+	.width		= 71, /* 7.11cm */
+	.height		= 53, /* 5.33cm */
+	.tim2		= 0x80007d0,
+	.cntl		= CNTL_LCDBPP8 | CNTL_LCDMONO8,
+	.bpp		= 8,
+	.grayscale	= 1
+};
+
+int nspire_clcd_setup(struct clcd_fb *fb)
+{
+	struct clcd_panel *panel;
+	size_t panel_size;
+	const char *type;
+	dma_addr_t dma;
+	int err;
+
+	BUG_ON(!fb->dev->dev.of_node);
+
+	err = of_property_read_string(fb->dev->dev.of_node, "lcd-type", &type);
+	if (err) {
+		pr_err("CLCD: Could not find lcd-type property\n");
+		return err;
+	}
+
+	if (!strcmp(type, "cx"))
+	{
+		panel = &nspire_cx_lcd_panel;
+	}
+	else if (!strcmp(type, "classic"))
+	{
+		panel = &nspire_classic_lcd_panel;
+	}
+	else
+	{
+		pr_err("CLCD: Unknown lcd-type %s\n", type);
+		return -EINVAL;
+	}
+
+	panel_size = ((panel->mode.xres * panel->mode.yres) * panel->bpp) / 8;
+	panel_size = ALIGN(panel_size, PAGE_SIZE);
+
+	fb->fb.screen_base = dma_alloc_writecombine(&fb->dev->dev,
+		panel_size, &dma, GFP_KERNEL);
+
+	if (!fb->fb.screen_base) {
+		pr_err("CLCD: unable to map framebuffer\n");
+		return -ENOMEM;
+	}
+
+	fb->fb.fix.smem_start = dma;
+	fb->fb.fix.smem_len = panel_size;
+	fb->panel = panel;
+
+	return 0;
+}
+
+int nspire_clcd_mmap(struct clcd_fb *fb, struct vm_area_struct *vma)
+{
+	return dma_mmap_writecombine(&fb->dev->dev, vma,
+		fb->fb.screen_base, fb->fb.fix.smem_start,
+		fb->fb.fix.smem_len);
+}
+
+void nspire_clcd_remove(struct clcd_fb *fb)
+{
+	dma_free_writecombine(&fb->dev->dev, fb->fb.fix.smem_len,
+		fb->fb.screen_base, fb->fb.fix.smem_start);
+}
diff --git a/arch/arm/mach-nspire/clcd.h b/arch/arm/mach-nspire/clcd.h
new file mode 100644
index 0000000..7144399
--- /dev/null
+++ b/arch/arm/mach-nspire/clcd.h
@@ -0,0 +1,14 @@
+/*
+ *	linux/arch/arm/mach-nspire/clcd.h
+ *
+ *	Copyright (C) 2012 Daniel Tang <tangrs at tangrs.id.au>
+ *
+ * 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.
+ *
+ */
+
+int nspire_clcd_setup(struct clcd_fb *fb);
+int nspire_clcd_mmap(struct clcd_fb *fb, struct vm_area_struct *vma);
+void nspire_clcd_remove(struct clcd_fb *fb);
diff --git a/arch/arm/mach-nspire/mmio.h b/arch/arm/mach-nspire/mmio.h
new file mode 100644
index 0000000..f0a1fa5
--- /dev/null
+++ b/arch/arm/mach-nspire/mmio.h
@@ -0,0 +1,15 @@
+/*
+ *	linux/arch/arm/mach-nspire/mmio.h
+ *
+ *	Copyright (C) 2012 Daniel Tang <tangrs at tangrs.id.au>
+ *
+ * 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.
+ *
+ */
+
+#define NSPIRE_EARLY_UART_PHYS_BASE	0x90020000
+#define NSPIRE_EARLY_UART_VIRT_BASE	0xfee20000
+
+#define NSPIRE_LCD_PHYS_BASE		0xC0000000
diff --git a/arch/arm/mach-nspire/nspire.c b/arch/arm/mach-nspire/nspire.c
new file mode 100644
index 0000000..7d972b8
--- /dev/null
+++ b/arch/arm/mach-nspire/nspire.c
@@ -0,0 +1,139 @@
+/*
+ *	linux/arch/arm/mach-nspire/nspire.c
+ *
+ *	Copyright (C) 2012 Daniel Tang <tangrs at tangrs.id.au>
+ *
+ * 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/init.h>
+#include <linux/of_irq.h>
+#include <linux/of_address.h>
+#include <linux/of_platform.h>
+#include <linux/irqchip.h>
+#include <linux/irqchip/arm-vic.h>
+#include <linux/clk-provider.h>
+#include <linux/clkdev.h>
+#include <linux/amba/bus.h>
+#include <linux/amba/clcd.h>
+
+#include <asm/mach/arch.h>
+#include <asm/mach-types.h>
+#include <asm/mach/map.h>
+
+#include <asm/hardware/timer-sp.h>
+
+#include "mmio.h"
+#include "clcd.h"
+
+static const char *nspire_dt_match[] __initconst = {
+	"arm,nspire",
+	"arm,nspire-cx",
+	"arm,nspire-tp",
+	"arm,nspire-clp",
+	NULL,
+};
+
+static struct map_desc nspire_io_desc[] __initdata = {
+	{
+		.virtual	=  NSPIRE_EARLY_UART_VIRT_BASE,
+		.pfn		= __phys_to_pfn(NSPIRE_EARLY_UART_PHYS_BASE),
+		.length		= SZ_4K,
+		.type		= MT_DEVICE
+	}
+};
+
+#define TIMER_NAME_MAXLEN 32
+static void __init nspire_add_sp804_timers(void)
+{
+	struct device_node *of_timer;
+	int clockevents_found = 0;
+
+	for_each_compatible_node(of_timer, NULL, "arm,sp804") {
+		struct resource res;
+		void __iomem *base;
+		char *timer_name;
+		struct clk *clk;
+		int irq;
+
+		clk = of_clk_get_by_name(of_timer, NULL);
+		if (WARN_ON(!clk))
+			continue;
+
+		timer_name = kzalloc(TIMER_NAME_MAXLEN, GFP_ATOMIC);
+		if (!timer_name)
+			break;
+
+		base = of_iomap(of_timer, 0);
+		if (WARN_ON(!base)) {
+			kfree(timer_name);
+			continue;
+		}
+
+		of_address_to_resource(of_timer, 0, &res);
+		scnprintf(timer_name, TIMER_NAME_MAXLEN, "%llx.%s",
+				(unsigned long long)res.start,
+				of_timer->name);
+
+		clk_register_clkdev(clk, timer_name, "sp804");
+		if (!clockevents_found) {
+			irq = irq_of_parse_and_map(of_timer, 0);
+			if (irq) {
+				sp804_clockevents_init(base, irq,timer_name);
+				clockevents_found = 1;
+				continue;
+			}
+		}
+
+		sp804_clocksource_init(base, timer_name);
+	}
+}
+
+
+static void __init nspire_init_timer(void)
+{
+	of_clk_init(NULL);
+	nspire_add_sp804_timers();
+}
+
+static void __init nspire_map_io(void)
+{
+	iotable_init(nspire_io_desc, ARRAY_SIZE(nspire_io_desc));
+}
+
+static struct clcd_board nspire_clcd_data = {
+	.name		= "LCD",
+	.check		= clcdfb_check,
+	.decode		= clcdfb_decode,
+	.setup		= nspire_clcd_setup,
+	.mmap		= nspire_clcd_mmap,
+	.remove		= nspire_clcd_remove,
+};
+
+
+static struct of_dev_auxdata nspire_auxdata[] __initdata = {
+	OF_DEV_AUXDATA("arm,pl111", NSPIRE_LCD_PHYS_BASE,
+			NULL, &nspire_clcd_data),
+	{ }
+};
+
+static void __init nspire_init(void)
+{
+	of_platform_populate(NULL, of_default_bus_match_table,
+			nspire_auxdata, NULL);
+}
+
+static void nspire_restart(char mode, const char *cmd)
+{
+}
+
+DT_MACHINE_START(NSPIRE, "TI-NSPIRE")
+	.map_io		= nspire_map_io,
+	.init_irq	= irqchip_init,
+	.init_time	= nspire_init_timer,
+	.init_machine	= nspire_init,
+	.dt_compat	= nspire_dt_match,
+	.restart	= nspire_restart,
+MACHINE_END
diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
index ac05006..677adba 100644
--- a/drivers/input/keyboard/Kconfig
+++ b/drivers/input/keyboard/Kconfig
@@ -418,6 +418,16 @@ config KEYBOARD_NOMADIK
 	  To compile this driver as a module, choose M here: the
 	  module will be called nmk-ske-keypad.
 
+config KEYBOARD_NSPIRE
+	tristate "TI-NSPIRE builtin keyboard"
+	depends on ARCH_NSPIRE
+	select INPUT_MATRIXKMAP
+	help
+	  Say Y here if you want to use the builtin keypad on the TI-NSPIRE.
+
+	  To compile this driver as a module, choose M here: the
+	  module will be called nspire-keypad.
+
 config KEYBOARD_TEGRA
 	tristate "NVIDIA Tegra internal matrix keyboard controller support"
 	depends on ARCH_TEGRA && OF
diff --git a/drivers/input/keyboard/Makefile b/drivers/input/keyboard/Makefile
index 49b1645..89d997b 100644
--- a/drivers/input/keyboard/Makefile
+++ b/drivers/input/keyboard/Makefile
@@ -35,6 +35,7 @@ obj-$(CONFIG_KEYBOARD_MCS)		+= mcs_touchkey.o
 obj-$(CONFIG_KEYBOARD_MPR121)		+= mpr121_touchkey.o
 obj-$(CONFIG_KEYBOARD_NEWTON)		+= newtonkbd.o
 obj-$(CONFIG_KEYBOARD_NOMADIK)		+= nomadik-ske-keypad.o
+obj-$(CONFIG_KEYBOARD_NSPIRE)		+= nspire-keypad.o
 obj-$(CONFIG_KEYBOARD_OMAP)		+= omap-keypad.o
 obj-$(CONFIG_KEYBOARD_OMAP4)		+= omap4-keypad.o
 obj-$(CONFIG_KEYBOARD_OPENCORES)	+= opencores-kbd.o
diff --git a/drivers/input/keyboard/nspire-keypad.c b/drivers/input/keyboard/nspire-keypad.c
new file mode 100644
index 0000000..5b2b3cc
--- /dev/null
+++ b/drivers/input/keyboard/nspire-keypad.c
@@ -0,0 +1,318 @@
+/*
+ *  linux/drivers/input/keyboard/nspire-keypad.c
+ *
+ *  Copyright (C) 2013 Daniel Tang <tangrs at tangrs.id.au>
+ *
+ * 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/input/matrix_keypad.h>
+#include <linux/platform_device.h>
+#include <linux/interrupt.h>
+#include <linux/spinlock.h>
+#include <linux/io.h>
+#include <linux/delay.h>
+#include <linux/input.h>
+#include <linux/slab.h>
+#include <linux/clk.h>
+#include <linux/module.h>
+#include <linux/of.h>
+
+#include <linux/platform_data/nspire-keypad.h>
+
+#define KEYPAD_SCAN_MODE	0x00
+#define KEYPAD_CNTL		0x04
+#define KEYPAD_INT		0x08
+#define KEYPAD_INTMSK		0x0C
+
+#define KEYPAD_DATA		0x10
+#define KEYPAD_GPIO		0x30
+
+#define KEYPAD_UNKNOWN_INT	0x40
+#define KEYPAD_UNKNOWN_INT_STS	0x44
+
+
+struct nspire_keypad {
+	spinlock_t lock;
+
+	void __iomem *reg_base;
+	int irq;
+	u32 int_mask;
+
+	struct input_dev *input;
+	struct clk *clk;
+
+	struct nspire_keypad_data options;
+	int row_shift;
+};
+
+static inline void nspire_report_state(struct nspire_keypad *keypad,
+		int row, int col, unsigned int state)
+{
+	int code = MATRIX_SCAN_CODE(row, col, keypad->row_shift);
+	unsigned short *keymap = keypad->input->keycode;
+
+	state = keypad->options.active_low ? !state : !!state;
+	input_report_key(keypad->input, keymap[code], state);
+}
+
+static irqreturn_t nspire_keypad_irq(int irq, void *dev_id)
+{
+	struct nspire_keypad *keypad = dev_id;
+	u32 int_sts;
+	u16 state[8];
+	int row, col;
+
+	int_sts = readl(keypad->reg_base + KEYPAD_INT) & keypad->int_mask;
+
+	if (!int_sts)
+		return IRQ_NONE;
+
+	spin_lock(&keypad->lock);
+
+	memcpy_fromio(state, keypad->reg_base + KEYPAD_DATA, sizeof(state));
+
+	for (row = 0; row < KEYPAD_BITMASK_ROWS; row++) {
+		u16 bits = state[row];
+		for (col = 0; col < KEYPAD_BITMASK_COLS; col++) {
+			nspire_report_state(keypad, row, col, bits & (1<<col));
+		}
+	}
+	input_sync(keypad->input);
+	writel(0x3, keypad->reg_base + KEYPAD_INT);
+
+	spin_unlock(&keypad->lock);
+
+	return IRQ_HANDLED;
+}
+
+static int nspire_keypad_chip_init(struct nspire_keypad *keypad)
+{
+	unsigned long val = 0, cycles_per_us, delay_cycles, row_delay_cycles;
+
+	cycles_per_us = (clk_get_rate(keypad->clk) / 1000000);
+	if (cycles_per_us == 0)
+		cycles_per_us = 1;
+
+	delay_cycles = cycles_per_us * keypad->options.scan_interval;
+	WARN_ON(delay_cycles >= (1<<16)); /* Overflow */
+	delay_cycles &= 0xffff;
+
+	row_delay_cycles = cycles_per_us * keypad->options.row_delay;
+	WARN_ON(row_delay_cycles >= (1<<14)); /* Overflow */
+	row_delay_cycles &= 0x3fff;
+
+
+	val |= (3<<0); /* Set scan mode to 3 (continuous scan) */
+	val |= (row_delay_cycles<<2); /* Delay between scanning each row */
+	val |= (delay_cycles<<16); /* Delay between scans */
+	writel(val, keypad->reg_base + KEYPAD_SCAN_MODE);
+
+	val = (KEYPAD_BITMASK_ROWS & 0xff) | (KEYPAD_BITMASK_COLS & 0xff)<<8;
+	writel(val, keypad->reg_base + KEYPAD_CNTL);
+
+	/* Enable interrupts */
+	keypad->int_mask = (1<<1);
+	writel(keypad->int_mask, keypad->reg_base + 0xc);
+
+	/* Disable GPIO interrupts to prevent hanging on touchpad */
+	/* Possibly used to detect touchpad events */
+	writel(0, keypad->reg_base + KEYPAD_UNKNOWN_INT);
+	/* Acknowledge existing interrupts */
+	writel(~0, keypad->reg_base + KEYPAD_UNKNOWN_INT_STS);
+
+	return 0;
+}
+
+static int nspire_keypad_probe(struct platform_device *pdev)
+{
+	const struct nspire_keypad_data *plat = pdev->dev.platform_data;
+	const struct device_node *of_node = pdev->dev.of_node;
+	struct nspire_keypad *keypad;
+	struct input_dev *input;
+	struct resource *res;
+	struct clk *clk;
+	int irq, error;
+
+	irq = platform_get_irq(pdev, 0);
+	if (irq < 0) {
+		dev_err(&pdev->dev, "failed to get keypad irq\n");
+		return -EINVAL;
+	}
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	if (!res) {
+		dev_err(&pdev->dev, "missing platform resources\n");
+		return -EINVAL;
+	}
+
+	clk = clk_get(&pdev->dev, NULL);
+	if (IS_ERR(clk)) {
+		dev_err(&pdev->dev, "unable to get clock\n");
+		return -EINVAL;
+	}
+
+	clk_prepare(clk);
+	error = clk_enable(clk);
+	if (error) {
+		goto err_put_clk;
+	}
+
+	keypad = kzalloc(sizeof(struct nspire_keypad), GFP_KERNEL);
+	input = input_allocate_device();
+	if (!keypad || !input) {
+		dev_err(&pdev->dev, "failed to allocate keypad memory\n");
+		error = -ENOMEM;
+		goto err_free_mem;
+	}
+
+	if (plat) {
+		memcpy(&keypad->options, plat, sizeof(*plat));
+	} else {
+		/* Load values from device tree */
+
+		error = of_property_read_u32(of_node, "scan-interval",
+				&keypad->options.scan_interval);
+		if (error) {
+			dev_err(&pdev->dev, "failed to get scan-interval\n");
+			goto err_free_mem;
+		}
+
+		error = of_property_read_u32(of_node, "row-delay",
+				&keypad->options.row_delay);
+		if (error) {
+			dev_err(&pdev->dev, "failed to get row-delay\n");
+			goto err_free_mem;
+		}
+
+		keypad->options.active_low = of_property_read_bool(of_node,
+				"active-low");
+
+		keypad->options.keymap = NULL;
+	}
+
+	keypad->row_shift = get_count_order(KEYPAD_BITMASK_COLS);
+	keypad->irq = irq;
+	keypad->clk = clk;
+	keypad->input = input;
+	spin_lock_init(&keypad->lock);
+
+	if (!request_mem_region(res->start, resource_size(res), pdev->name)) {
+		dev_err(&pdev->dev, "failed to request I/O memory\n");
+		error = -EBUSY;
+		goto err_free_mem;
+	}
+
+	keypad->reg_base = ioremap(res->start, resource_size(res));
+	if (!keypad->reg_base) {
+		dev_err(&pdev->dev, "failed to remap I/O memory\n");
+		error = -ENXIO;
+		goto err_free_mem_region;
+	}
+
+	input->id.bustype = BUS_HOST;
+	input->name = "nspire-keypad";
+	input->dev.parent = &pdev->dev;
+
+	set_bit(EV_KEY, input->evbit);
+	set_bit(EV_REP, input->evbit);
+
+	error = matrix_keypad_build_keymap(keypad->options.keymap, "keymap",
+			KEYPAD_BITMASK_ROWS, KEYPAD_BITMASK_COLS, NULL, input);
+	if (error) {
+		dev_err(&pdev->dev, "building keymap failed\n");
+		goto err_iounmap;
+	}
+
+	error = nspire_keypad_chip_init(keypad);
+	if (error) {
+		dev_err(&pdev->dev, "unable to init keypad hardware\n");
+		goto err_iounmap;
+	}
+
+	error = request_irq(keypad->irq, nspire_keypad_irq, 0,
+			"nspire_keypad", keypad);
+	if (error) {
+		dev_err(&pdev->dev, "allocate irq %d failed\n", keypad->irq);
+		goto err_iounmap;
+	}
+
+	error = input_register_device(input);
+	if (error) {
+		dev_err(&pdev->dev,
+				"unable to register input device: %d\n", error);
+		goto err_free_irq;
+	}
+
+	platform_set_drvdata(pdev, keypad);
+
+	dev_info(&pdev->dev, "TI-NSPIRE keypad at %#08x ("
+			"scan_interval=%uus,row_delay=%uus"
+			"%s)\n", res->start,
+			keypad->options.row_delay,
+			keypad->options.scan_interval,
+			keypad->options.active_low ? ",active_low" : "");
+
+	return 0;
+
+err_free_irq:
+	free_irq(keypad->irq, keypad);
+err_iounmap:
+	iounmap(keypad->reg_base);
+err_free_mem_region:
+	release_mem_region(res->start, resource_size(res));
+err_free_mem:
+	input_free_device(input);
+	kfree(keypad);
+
+	clk_disable(clk);
+err_put_clk:
+	clk_unprepare(clk);
+	clk_put(clk);
+	return error;
+}
+
+static int nspire_keypad_remove(struct platform_device *pdev)
+{
+	struct nspire_keypad *keypad = platform_get_drvdata(pdev);
+	struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+
+	free_irq(keypad->irq, keypad);
+
+	input_unregister_device(keypad->input);
+
+	iounmap(keypad->reg_base);
+	release_mem_region(res->start, resource_size(res));
+	kfree(keypad);
+
+	clk_disable(keypad->clk);
+	clk_unprepare(keypad->clk);
+	clk_put(keypad->clk);
+
+	return 0;
+}
+#ifdef CONFIG_OF
+static const struct of_device_id nspire_keypad_dt_match[] = {
+	{ .compatible = "nspire-keypad" },
+	{ },
+};
+MODULE_DEVICE_TABLE(of, nspire_keypad_dt_match);
+#endif
+
+static struct platform_driver nspire_keypad_driver = {
+	.driver = {
+		.name = "nspire-keypad",
+		.owner  = THIS_MODULE,
+		.of_match_table = of_match_ptr(nspire_keypad_dt_match),
+	},
+	.remove = nspire_keypad_remove,
+	.probe = nspire_keypad_probe
+};
+
+module_platform_driver(nspire_keypad_driver);
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("TI-NSPIRE Keypad Driver");
diff --git a/include/linux/platform_data/nspire-keypad.h b/include/linux/platform_data/nspire-keypad.h
new file mode 100644
index 0000000..03deb64
--- /dev/null
+++ b/include/linux/platform_data/nspire-keypad.h
@@ -0,0 +1,28 @@
+/*
+ *  linux/include/linux/platform_data/nspire-keypad.h
+ *
+ *  Copyright (C) 2012 Daniel Tang <tangrs at tangrs.id.au>
+ *
+ * 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.
+ *
+ */
+
+#ifndef _LINUX_NSPIRE_KEYPAD_H
+#define _LINUX_NSPIRE_KEYPAD_H
+
+#define KEYPAD_BITMASK_COLS	11
+#define KEYPAD_BITMASK_ROWS	8
+
+struct nspire_keypad_data {
+	struct matrix_keymap_data *keymap;
+
+	/* Maximum delay estimated assuming 33MHz APB */
+	u32 scan_interval;	/* In microseconds (~2000us max) */
+	u32 row_delay;		/* In microseconds (~500us max) */
+
+	bool active_low;
+};
+
+#endif



From laurent.pinchart at ideasonboard.com  Mon Apr  8 07:37:30 2013
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Mon, 08 Apr 2013 13:37:30 +0200
Subject: [PATCH v3] irqchip: renesas-intc-irqpin: DT binding for sense
 bitfield width
In-Reply-To: <Pine.LNX.4.64.1304081324370.29945@axis700.grange>
References: <Pine.LNX.4.64.1304081002190.29945@axis700.grange>
 <1694336.shM2ct4pzX@avalon>
 <Pine.LNX.4.64.1304081324370.29945@axis700.grange>
Message-ID: <15518520.KQOfZxAAdo@avalon>

Hi Guennadi,

On Monday 08 April 2013 13:25:46 Guennadi Liakhovetski wrote:
> On Mon, 8 Apr 2013, Laurent Pinchart wrote:
> > On Monday 08 April 2013 10:08:40 Guennadi Liakhovetski wrote:
> > > Most Renesas irqpin controllers have 4-bit sense fields, however, some
> > > have different widths. This patch adds a DT binding to optionally
> > > specify such non-standard values.
> > > 
> > > Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas at gmail.com>
> > > ---
> > > 
> > > v3: move the code to a common location, where device configuration
> > > parameters are retrieved
> > > 
> > >  .../interrupt-controller/renesas,intc-irqpin.txt   |   13 +++++++++++++
> > >  drivers/irqchip/irq-renesas-intc-irqpin.c          |    4 ++++
> > >  2 files changed, 17 insertions(+), 0 deletions(-)
> > >  create mode 100644
> > > 
> > > Documentation/devicetree/bindings/interrupt-controller/renesas,intc-
> > > irqpin.txt
> > > diff --git a/Documentation/devicetree/bindings/interrupt-
> > > controller/renesas,intc-irqpin.txt
> > > b/Documentation/devicetree/bindings/interrupt-controller/renesas,intc-
> > > irqpin.txt
> > > new file mode 100644
> > > index 0000000..c6f09b7
> > > --- /dev/null
> > > +++
> > > b/Documentation/devicetree/bindings/interrupt-controller/renesas,intc-
> > > irqpin.txt
> > > @@ -0,0 +1,13 @@
> > > +DT bindings for the R-/SH-Mobile irqpin controller
> > > +
> > > +Required properties:
> > > +
> > > +- compatible: has to be "renesas,intc-irqpin"
> > > +- #interrupt-cells: has to be <2>
> > > +
> > > +Optional properties:
> > > +
> > > +- any properties, listed in interrupts.txt in this directory, and any
> > > standard
> > > +  resource allocation properties
> > > +- sense-bitfield-width: width of a single sense bitfield in the SENSE
> > > register,
> > > +  if different from the default 4 bits
> > 
> > Wouldn't it be better to define per-SoC compatible strings, and infer the
> > sense bitfield width from that ?
> 
> This is not a boolean, it is an integer, I don't think defining
> compatibility strings for 1, 2, 3, 4, 5,... bits is better than having one
> integer property.

I'm not advocating for compatibility strings for a given number of bits, but 
for per-SoC compatibility strings from which to infer the width.

For instance, if the r8a7779 has a 6-bit sense field, you would use

compatible = "r8a7779,intc-irqpin";

and map that to 6 in the irqpin driver.

> > > diff --git a/drivers/irqchip/irq-renesas-intc-irqpin.c
> > > b/drivers/irqchip/irq-renesas-intc-irqpin.c index 5a68e5a..4aca1b2
> > > 100644
> > > --- a/drivers/irqchip/irq-renesas-intc-irqpin.c
> > > +++ b/drivers/irqchip/irq-renesas-intc-irqpin.c
> > > @@ -18,6 +18,7 @@
	> > >   */
> > >  
> > >  #include <linux/init.h>
> > > +#include <linux/of.h>
> > >  #include <linux/platform_device.h>
> > >  #include <linux/spinlock.h>
> > >  #include <linux/interrupt.h>
> > > 
> > > @@ -349,6 +350,9 @@ static int intc_irqpin_probe(struct platform_device
> > > *pdev) /* deal with driver instance configuration */
> > >  	if (pdata)
> > >  		memcpy(&p->config, pdata, sizeof(*pdata));
> > > +	else
> > > +		of_property_read_u32(pdev->dev.of_node, "sense-bitfield-width",
> > > +				     &p->config.sense_bitfield_width);
> > > 
> > >  	if (!p->config.sense_bitfield_width)
> > >  		p->config.sense_bitfield_width = 4; /* default to 4 bits */

-- 
Regards,

Laurent Pinchart



From prabhakar.csengg at gmail.com  Mon Apr  8 07:38:24 2013
From: prabhakar.csengg at gmail.com (Prabhakar Lad)
Date: Mon, 8 Apr 2013 17:08:24 +0530
Subject: [PATCH v2 1/3] media: davinci: vpss: enable vpss clocks
In-Reply-To: <51629B3D.4080905@ti.com>
References: <1364903044-13752-1-git-send-email-prabhakar.csengg@gmail.com>
 <1364903044-13752-2-git-send-email-prabhakar.csengg@gmail.com>
 <51629B3D.4080905@ti.com>
Message-ID: <CA+V-a8swx0LB0eK0bZwcuFhVCW2UB8Bvm3ebwMQifo=-TB6ASA@mail.gmail.com>

Sekhar,

On Mon, Apr 8, 2013 at 3:56 PM, Sekhar Nori <nsekhar at ti.com> wrote:
> On 4/2/2013 5:14 PM, Prabhakar lad wrote:
>> From: Lad, Prabhakar <prabhakar.csengg at gmail.com>
>>
>> By default the VPSS clocks were enabled in capture driver
>> for davinci family which creates duplicates for dm355/dm365/dm644x.
>> This patch adds support to enable the VPSS clocks in VPSS driver,
>> which avoids duplication of code and also adding clock aliases.
>>
>> This patch uses PM runtime API to enable/disable instead common clock
>> framework. con_ids for master and slave clocks of vpss is added in pm_domain
>
> Common clock framework in not (yet) used on DaVinci, so this is misleading.
>
OK, I'll make it 'This patch uses PM runtime API to enable/disable
clock, instead
of Davinci specific clock framework. con_ids for master and slave
clocks of vpss is added in pm_domain'

>> diff --git a/arch/arm/mach-davinci/pm_domain.c b/arch/arm/mach-davinci/pm_domain.c
>> index c90250e..445b10b 100644
>> --- a/arch/arm/mach-davinci/pm_domain.c
>> +++ b/arch/arm/mach-davinci/pm_domain.c
>> @@ -53,7 +53,7 @@ static struct dev_pm_domain davinci_pm_domain = {
>>
>>  static struct pm_clk_notifier_block platform_bus_notifier = {
>>       .pm_domain = &davinci_pm_domain,
>> -     .con_ids = { "fck", NULL, },
>> +     .con_ids = { "fck", "master", "slave", NULL, },
>
> NULL is sentinel so you can drop the ',' after that. Apart from that,
> for the mach-davinci parts:
>
OK

Regards,
--Prabhakar

> Acked-by: Sekhar Nori <nsekhar at ti.com>
>
> Thanks,
> Sekhar


From girishks2000 at gmail.com  Mon Apr  8 07:45:26 2013
From: girishks2000 at gmail.com (Girish KS)
Date: Mon, 8 Apr 2013 17:15:26 +0530
Subject: [PATCH V3 4/5] spi: s3c64xx: Added provision for dedicated cs pin
In-Reply-To: <20130408101530.GC9243@opensource.wolfsonmicro.com>
References: <1363157014-9615-1-git-send-email-ks.giri@samsung.com>
 <1363157014-9615-5-git-send-email-ks.giri@samsung.com>
 <20130401125744.GG18636@opensource.wolfsonmicro.com>
 <CAKrE-Kd+YAFmteDdh3odtV+YU1=OjoMuQV9usF4NmUse+TXhTg@mail.gmail.com>
 <20130408101530.GC9243@opensource.wolfsonmicro.com>
Message-ID: <CAKrE-KevVramLc1n_9kcfHVb=RKT_kexQ8iUP-5+BL3wxpMPbQ@mail.gmail.com>

On Mon, Apr 8, 2013 at 3:45 PM, Mark Brown
<broonie at opensource.wolfsonmicro.com> wrote:
> On Mon, Apr 08, 2013 at 03:21:03PM +0530, Girish KS wrote:
>> On Mon, Apr 1, 2013 at 6:27 PM, Mark Brown
>
>> > It's also a bit odd that we end up checking cs_gpio and then using line
>> > in the code, it'd be more idiomatic if cs_gpio were the GPIO number.
>
>> In the original driver it was assumed that the cs line is always a gpio pin.
>> But the current controller that i am working on has no gpio pin for cs
>> selection.
>> All the lines to the device are internally connected. There is no
>> option to select
>> the cs signal. So cs-gpio property parsing has to skipped for this
>> controller, that means
>> cs_gpio cannot be a GPIO number. If it has to be a number then it has
>> to be < 0 to say
>> it is not gpio. Any >= 0 number implies it is a valid gpio (in reality
>> for this controller it is not.)
>
> Two options here, one is to just assume nobody will use GPIO 0 and the
> other is to set the number appopriately during probe so that only probe
> needs to worry about the issue.

regarding the first option, may be others also should agree to it (in
case if somebody is
using the gpio 0).
In the second option if the gpio number is set in the probe, then we
are overwriting the
actual gpio number assigned in the platform data.
If I move the cs_gpio from the platform data to controller private
data then the dependency
on other platforms can be removed, but still the check (true or false)
before setting the gpio
line will remain. If agreed upon this i can go ahead and post the patch


From nsekhar at ti.com  Mon Apr  8 07:47:34 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Mon, 8 Apr 2013 17:17:34 +0530
Subject: [PATCH v8 0/2] ARM: davinci: dm355: add support for vpbe display
In-Reply-To: <20130408075606.5a59d32c@redhat.com>
References: <1365413215-3632-1-git-send-email-prabhakar.csengg@gmail.com>
 <51629DA8.3040806@ti.com> <20130408075606.5a59d32c@redhat.com>
Message-ID: <5162AE56.5090203@ti.com>

Hi Maruo,

On 4/8/2013 4:26 PM, Mauro Carvalho Chehab wrote:
> Hi Sekhar,
> 
> Em Mon, 8 Apr 2013 16:06:24 +0530
> Sekhar Nori <nsekhar at ti.com> escreveu:
> 
>> On 4/8/2013 2:56 PM, Prabhakar lad wrote:
>>> From: Lad, Prabhakar <prabhakar.csengg at gmail.com>
>>>
>>> This patch series enables VPBE display driver on DM355.
>>
>> These (this and the DM365 one) patches look good to me. I need to get an
>> immutable branch from Mauro where dependencies are queued and then I can
>> generate a pull request for these for ARM SoC.
> 
> Are you mean a branch at the media development tree for you to sent
> pull requests for me? If so, just use the "master" branch at the media

The pull request will be sent to my upstreams (ie the ARM SoC folks -
Arnd and Olof). Since the platform data patches need driver patches to
be applied first, I need a non-rebasing branch containing the driver
stuff which I can use a dependency and apply platform patches on top.

> tree:
> 	http://git.linuxtv.org/media_tree.git
> 
> The master branch there is never rebased. I'll likely start to have
> topic branches on the next Kernel cycle, also at the same tree.

Ideally I will use the immutable branch which you will also use to send
pull request to Linus so there are not unnecessary merge conflicts. When
will those branches be ready?

Thanks,
Sekhar


From nsekhar at ti.com  Mon Apr  8 07:48:46 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Mon, 8 Apr 2013 17:18:46 +0530
Subject: [PATCH v2 1/3] media: davinci: vpss: enable vpss clocks
In-Reply-To: <CA+V-a8swx0LB0eK0bZwcuFhVCW2UB8Bvm3ebwMQifo=-TB6ASA@mail.gmail.com>
References: <1364903044-13752-1-git-send-email-prabhakar.csengg@gmail.com>
 <1364903044-13752-2-git-send-email-prabhakar.csengg@gmail.com>
 <51629B3D.4080905@ti.com>
 <CA+V-a8swx0LB0eK0bZwcuFhVCW2UB8Bvm3ebwMQifo=-TB6ASA@mail.gmail.com>
Message-ID: <5162AE9E.9030404@ti.com>



On 4/8/2013 5:08 PM, Prabhakar Lad wrote:
> Sekhar,
> 
> On Mon, Apr 8, 2013 at 3:56 PM, Sekhar Nori <nsekhar at ti.com> wrote:
>> On 4/2/2013 5:14 PM, Prabhakar lad wrote:
>>> From: Lad, Prabhakar <prabhakar.csengg at gmail.com>
>>>
>>> By default the VPSS clocks were enabled in capture driver
>>> for davinci family which creates duplicates for dm355/dm365/dm644x.
>>> This patch adds support to enable the VPSS clocks in VPSS driver,
>>> which avoids duplication of code and also adding clock aliases.
>>>
>>> This patch uses PM runtime API to enable/disable instead common clock
>>> framework. con_ids for master and slave clocks of vpss is added in pm_domain
>>
>> Common clock framework in not (yet) used on DaVinci, so this is misleading.
>>
> OK, I'll make it 'This patch uses PM runtime API to enable/disable
> clock, instead
> of Davinci specific clock framework. con_ids for master and slave

may be just call it "DaVinci clock framework"

Thanks,
Sekhar


From girishks2000 at gmail.com  Mon Apr  8 07:52:29 2013
From: girishks2000 at gmail.com (Girish KS)
Date: Mon, 8 Apr 2013 17:22:29 +0530
Subject: [PATCH V3 4/5] spi: s3c64xx: Added provision for dedicated cs pin
In-Reply-To: <CAKrE-KevVramLc1n_9kcfHVb=RKT_kexQ8iUP-5+BL3wxpMPbQ@mail.gmail.com>
References: <1363157014-9615-1-git-send-email-ks.giri@samsung.com>
 <1363157014-9615-5-git-send-email-ks.giri@samsung.com>
 <20130401125744.GG18636@opensource.wolfsonmicro.com>
 <CAKrE-Kd+YAFmteDdh3odtV+YU1=OjoMuQV9usF4NmUse+TXhTg@mail.gmail.com>
 <20130408101530.GC9243@opensource.wolfsonmicro.com>
 <CAKrE-KevVramLc1n_9kcfHVb=RKT_kexQ8iUP-5+BL3wxpMPbQ@mail.gmail.com>
Message-ID: <CAKrE-Kd3ua3H7C03H67-8unCsW9R98mvmWWnuHCScngARvPkaQ@mail.gmail.com>

On Mon, Apr 8, 2013 at 5:15 PM, Girish KS <girishks2000 at gmail.com> wrote:
> On Mon, Apr 8, 2013 at 3:45 PM, Mark Brown
> <broonie at opensource.wolfsonmicro.com> wrote:
>> On Mon, Apr 08, 2013 at 03:21:03PM +0530, Girish KS wrote:
>>> On Mon, Apr 1, 2013 at 6:27 PM, Mark Brown
>>
>>> > It's also a bit odd that we end up checking cs_gpio and then using line
>>> > in the code, it'd be more idiomatic if cs_gpio were the GPIO number.
>>
>>> In the original driver it was assumed that the cs line is always a gpio pin.
>>> But the current controller that i am working on has no gpio pin for cs
>>> selection.
>>> All the lines to the device are internally connected. There is no
>>> option to select
>>> the cs signal. So cs-gpio property parsing has to skipped for this
>>> controller, that means
>>> cs_gpio cannot be a GPIO number. If it has to be a number then it has
>>> to be < 0 to say
>>> it is not gpio. Any >= 0 number implies it is a valid gpio (in reality
>>> for this controller it is not.)
>>
>> Two options here, one is to just assume nobody will use GPIO 0 and the
>> other is to set the number appopriately during probe so that only probe
>> needs to worry about the issue.
>
> regarding the first option, may be others also should agree to it (in
> case if somebody is
> using the gpio 0).
> In the second option if the gpio number is set in the probe, then we
> are overwriting the
> actual gpio number assigned in the platform data.
> If I move the cs_gpio from the platform data to controller private
> data then the dependency
> on other platforms can be removed, but still the check (true or false)
> before setting the gpio
> line will remain. If agreed upon this i can go ahead and post the patch

Sorry for the allignment. there is some issue with my interface


From kishon at ti.com  Mon Apr  8 07:55:05 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Mon, 8 Apr 2013 17:25:05 +0530
Subject: [PATCH] ARM: OMAP4: PM: fix PM regression introduced by recent
 clock cleanup
In-Reply-To: <alpine.DEB.2.00.1302122026530.29149@utopia.booyaka.com>
References: <alpine.DEB.2.00.1302122026530.29149@utopia.booyaka.com>
Message-ID: <5162B019.6050407@ti.com>

Hi,

On Wednesday 13 February 2013 01:58 AM, Paul Walmsley wrote:
>
> Commit 17b7e7d33530e2bbd3bdc90f4db09b91cfdde2bb ("ARM: OMAP4:
> clock/hwmod data: start to remove some IP block control "clocks"")
> introduced a regression preventing the L3INIT clockdomain of OMAP4
> systems from entering idle.  This in turn prevented these systems from
> entering full chip clock-stop.
>
> The regression was caused by the incorrect removal of a so-called
> "optional functional clock" from the OMAP4 clock data.  This wasn't
> caught for two reasons.  First, I missed the retention entry failure
> in the branch test logs:
>
> http://www.pwsan.com/omap/testlogs/cleanup_a_3.9/20130126014242/pm/4460pandaes/4460pandaes_log.txt
>
> Second, the integration data for the OCP2SCP PHY IP block, added by
> commit 0c6688753f9912c6a7013549ec31c8844020bbc1 ("ARM: OMAP4: hwmod
> data: add remaining USB-related IP blocks"), should have associated this
> clock with the IP block, but did not.
>
> Fix by adding back the so-called "optional" functional clock to the
> clock data, and by linking that clock to the OCP2SCP PHY IP block
> integration hwmod data.

This patch breaks MUSB in OMAP4 panda. The 48M clock is modeled as main 
clk [1] for ocp2scp so after doing get_sync, this optional clock gets 
enabled. But after this patch, the optional clock seems to be not 
enabled after get_sync.

http://lists.infradead.org/pipermail/linux-arm-kernel/2012-September/118285.html 
(this patch is not directly merged but I guess the discussion here is 
taken care of)

Thanks
Kishon


From plagnioj at jcrosoft.com  Mon Apr  8 07:52:38 2013
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Mon, 8 Apr 2013 13:52:38 +0200
Subject: [GIT PULL] at91: DT changes for 3.10 #2
In-Reply-To: <CAOesGMiDEER3++J80KtU3UDLWNADaJhGS7upArFm2RzM4Z_P=w@mail.gmail.com>
References: <1364569179-24773-1-git-send-email-nicolas.ferre@atmel.com>
 <20130402184947.GA8015@quad.lixom.net> <515BDE2C.9030904@atmel.com>
 <515D49D4.5020208@atmel.com>
 <CAOesGMiDEER3++J80KtU3UDLWNADaJhGS7upArFm2RzM4Z_P=w@mail.gmail.com>
Message-ID: <20130408115238.GY20693@game.jcrosoft.org>

On 10:19 Thu 04 Apr     , Olof Johansson wrote:
> On Thu, Apr 4, 2013 at 2:37 AM, Nicolas Ferre <nicolas.ferre at atmel.com> wrote:
> > On 04/03/2013 09:45 AM, Nicolas Ferre :
> >> On 04/02/2013 08:49 PM, Olof Johansson :
> >>> On Fri, Mar 29, 2013 at 03:59:39PM +0100, Nicolas Ferre wrote:
> >>>> Arnd, Olof,
> >>>>
> >>>> Here is a pull-request for AT91 that is dedicated to Device Tree
> >>>> modifications. It is stacked on the material that you already have
> >>>> for 3.10 in your arm-soc/at91/dt branch.
> >>>> Following our discussion with Arnd, I added the non-urgent patches that I
> >>>> already proposed too late for 3.9. I also included the moving of macb node
> >>>> and kept the original patch.
> >>>>
> >>>> Thanks, best regards,
> >>>>
> >>>> The following changes since commit 6901d947be5ba1245a0f63271355b95f9056a362:
> >>>>
> >>>>   ARM: at91/at91sam9x5cm: add 1-wire chip on CM board (2013-03-21 16:07:15 +0100)
> >>>>
> >>>> are available in the git repository at:
> >>>>
> >>>>   git://github.com/at91linux/linux-at91.git tags/at91-dt
> >>>>
> >>>> for you to fetch changes up to cc2e191b0ccc5a987fdb29261ab9c264c608924d:
> >>>>
> >>>>   ARM: at91/dt: fix macb node declaration (2013-03-29 10:02:04 +0100)
> >>>>
> >>>> ----------------------------------------------------------------
> >>>> One macb DT node move for 9x5 family: 9g15 doesn't
> >>>> have an Ethernet interface.
> >>>> Little fixes mainly related to at91sam9x5 DT and the
> >>>> RTC addition.
> >>>> Addition of the Acme Systems Aria G25 board.
> >>>>
> >>>> ----------------------------------------------------------------
> >>>> Douglas Gilbert (1):
> >>>>       ARM: at91: add Acme Systems Aria G25 board
> >>>
> >>> Hi,
> >>>
> >>> I just replied to the above patch -- please prefix the dts files with the
> >>> platform so it's easier to navigate the directory.
> >
> > I do not want to spark a debate here, but moving to directories per
> > "mach" earlier would have made things easier. If I recall well,
> > Jean-Christophe has proposed it a long time ago...
> 
> Yeah, we're at a size where it's starting to be warranted (powerpc
> does so already). It does cut down on the cross-exposure and review
> though and puts everyone in their own little sandbox, so there's some
> benefit in keeping it flat.
> 
> I think that benefit is losing its appeal though. But let's hold off
> for another couple of releases with the churn of moving things out in
> subdirectories.
> 
> >> Yes, I have to make sure that everybody agree on our side...
> >
> > The difficult point with this prefix... well it is difficult to tell...
> > our product will never be called "at91" again!
> 
> That's a marketing issue, not a technical kernel one. If we create
> subdirectory it makes sense to name it 'atmel' instead of 'at91'
> though, I'm sure.
> 
> > So, yes, our Linux identity is still "at91" and we are pretty attached
> > to it but our newer products are named "sam" + "core" + "product family"
> > which results in our newer family: "sama5d3" (note the at91 is missing)...
> > => anyway, we think that the at91 prefix is still vivid in Linux
> > community and we consider it as a good choice for now.
> > So, I may rename the newly introduced "sama5d3*.dts[i]" files with
> > "at91-sama5d3*.dts[i]" (while .c/.h files will remain the same).
> 
> Sounds reasonable, or stick to the same format as you already have
> with at91sam9 families. When we move to subdirectories it might make
> sense to stick them under 'atmel' instead of 'at91' though and drop
> the prefix.
I've a rfc for this as I do no lihe idea of prefix

and it make the grep search mo complex

I send a patch to clean the '\\' stuff in this Makefile

can you take

I send the dir split on the top of this
> 
> 
> 
> -Olof


From kgene.kim at samsung.com  Mon Apr  8 08:02:44 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Mon, 08 Apr 2013 21:02:44 +0900
Subject: [PATCH V5 0/4] cpufreq: exynos5440: support for cpufreq driver
In-Reply-To: <CADGdYn7ZRCSymU7k3Sn4mbS6B=dxy1N+vhQuyiFnhOQLLzrTbw@mail.gmail.com>
References: <1364457923-8499-1-git-send-email-amit.daniel@samsung.com>
 <2949363.nNl2A6XIoS@vostro.rjw.lan>
 <CADGdYn7ZRCSymU7k3Sn4mbS6B=dxy1N+vhQuyiFnhOQLLzrTbw@mail.gmail.com>
Message-ID: <2d0501ce3450$fac4e9c0$f04ebd40$%kim@samsung.com>

amit daniel kachhap wrote:
> 
> On Fri, Apr 5, 2013 at 6:08 PM, Rafael J. Wysocki <rjw at sisk.pl> wrote:
> > On Thursday, March 28, 2013 01:35:18 PM Amit Daniel Kachhap wrote:
> >> Submitting the V5 version of exynos5440 cpufreq driver. This patchset
> addresses
> >> all the coding and design concerns raised especially by Viresh.
> >>
> >> Changes in V5:
> >> * Removed the unnecessary DT look up entry from mach-exynos5-dt.c.
> >> * Fixed all coding and comments issue raised by Viresh.
> >>
> >> Changes in V4:
> >> * Added dev_err logs instead of pr_err.
> >> * Used the devm_ioremap_resource API.
> >> * Implemented several coding guidelines and minor error comments from
> Sylwester,
> >>   Russell and Viresh.
> >>
> >> Changes in V3:
> >> * Converted the driver to probe based as suggested by Viresh. This is
> also
> >>   beneficial for multiplatform kernel.
> >> * Other coding guidelines related changes.
> >> * Moved the DT node outside cpu0 node as the driver is now a platform
> >>   driver.
> >>
> >> Changes in V2:
> >> * Added OPP library support to parse DT parameters.
> >> * Removed a hack to handle interrupts in bootup.
> >> * Implemented other review comments from Viresh and Inder.
> >>
> >> All these patches are dependent on Thomas Abraham common clock patches.
> >> (http://www.mail-archive.com/linux-samsung-
> soc at vger.kernel.org/msg15860.html)
> >> This whole patch series is based on 3.9-rc4.
> >>
> >> Amit Daniel Kachhap (4):
> >>   cpufreq: exynos: Add cpufreq driver for exynos5440
> >>   cpufreq: exynos: Remove error return even if no soc is found
> >>   arm: exynos: Enable OPP library support for exynos5440
> >>   arm: dts: Add cpufreq controller node for Exynos5440 SoC
> >>
> >>  .../bindings/cpufreq/cpufreq-exynos5440.txt        |   28 ++
> >>  arch/arm/boot/dts/exynos5440.dtsi                  |   12 +
> >>  arch/arm/mach-exynos/Kconfig                       |    2 +
> >>  drivers/cpufreq/Kconfig.arm                        |    9 +
> >>  drivers/cpufreq/Makefile                           |    1 +
> >>  drivers/cpufreq/exynos-cpufreq.c                   |    2 +-
> >>  drivers/cpufreq/exynos5440-cpufreq.c               |  474
> ++++++++++++++++++++
> >>  7 files changed, 527 insertions(+), 1 deletions(-)
> >>  create mode 100644 Documentation/devicetree/bindings/cpufreq/cpufreq-
> exynos5440.txt
> >>  create mode 100644 drivers/cpufreq/exynos5440-cpufreq.c
> >
> > Is this for me or the Samsung tree?
> >
> > If it's for me, I need ACKs from the Samsung tree maintainers.  Also,
> please
> > address the Viresh's comments.
> >
> > Thanks,
> > Rafael
> >
> Hi Rafael,
> 
> I submitted the V6 version with all comments from Viresh addressed.
> 
> Hi Kukjin Kim,
> 
> Any suggestion on how this patch should be merged. In my opinion it
> should go via Rafael's tree as this patch uses some fixes present in
> Rafael's tree like modified cpufreq_notify_transition API.
> 
Yes, I agree. The v6 series including resending 1/4 patch looks good to me.
But the patch V6 4/4 would be sent to upstream via samsung tree to avoid
useless merge conflicts and I think, it's possible.

So Rafael, please take 1/4 ~ 3/4 patches in your tree with my ack.

Acked-by: Kukjin Kim <kgene.kim at samsung.com>

If any problems, please let me know.

Thanks.

- Kukjin



From b-cousson at ti.com  Mon Apr  8 08:06:43 2013
From: b-cousson at ti.com (Benoit Cousson)
Date: Mon, 8 Apr 2013 14:06:43 +0200
Subject: [PATCH v4 00/21] ARM: OMAP2+: Adapt to ehci-omap changes for 3.10
In-Reply-To: <20130405154259.GZ10155@atomide.com>
References: <1363794300-31526-1-git-send-email-rogerq@ti.com>
 <515E8B99.8080803@ti.com> <515E9FB1.2040803@ti.com>
 <20130405154259.GZ10155@atomide.com>
Message-ID: <5162B2D3.6070007@ti.com>

Hi Tony,

On 04/05/2013 05:43 PM, Tony Lindgren wrote:
> * Benoit Cousson <b-cousson at ti.com> [130405 03:00]:
>> On 04/05/2013 10:30 AM, Benoit Cousson wrote:
>>
>> ...
>>
>>>>   ARM: dts: OMAP4: Add HS USB Host IP nodes
>>>>   ARM: dts: OMAP3: Add HS USB Host IP nodes
>>>>   ARM: dts: omap3-beagle: Add USB Host support
>>>
>>> These 3 DTS patches are good to me, but I cannot applied them on top of
>>> the already existing patches I queued for 3.10.
>>>
>>> git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git
>>> for_3.10/dts
>>>
>>> Could you rebase these 3 ones only, and I will applied them.
>>
>> Mmm, in fact, I've just seen the pull request from Tony :-(
>>
>>
>> Tony,
>>
>> Don't you want to remove these DTS patches from the pull-request?
> 
> Oops sorry :( Looks like I applied them mistakenly as I saved all
> the patches into a mbox, then applied it. Anyways, too late to start
> messing with it now.
>  
>> Otherwise, I will have to rebase the whole DTS series on top of yours.
>> That being said, if the branch is not supposed to be rebased, it is doable.
> 
> I pulled in your for_3.10/dts for testing, and to me it looks like
> it's just overlapping additions. So that should be OK to resolve while
> pulling it in.
> 
> It seems there's no need to add omap-for-v3.10/usb as a dependency for
> your for_3.10/dts unless the conflict gets non-trivial with some
> additional patches.

The branch was not complete, with the latest additions, we do have
conflict due to the addition of several new nodes at the same place.

The resolution is not that hard since it is addition of node only, but
the rebase on to of omap-for-v3.10/usb will avoid the issue.

I have a new pre-merged branch available. for_3.10/dts_merged is based
on omap-for-v3.10/usb and Paul's omap-devel-b-for-3.10 branch to get the
AM33xx hwmod.
Paul's branch is just needed to avoid AM33xx regression introduced by
Santosh hwmod changes present in my branch.

Just let me know which one you will prefer to pull.

Regards,
Benoit



From shawn.guo at linaro.org  Mon Apr  8 08:11:58 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Mon, 8 Apr 2013 20:11:58 +0800
Subject: [PATCH 3/6] ARM: imx: add initial imx6dl support
In-Reply-To: <1365371979.4457.4.camel@smarty>
References: <1364913079-26039-1-git-send-email-shawn.guo@linaro.org>
 <1364913079-26039-4-git-send-email-shawn.guo@linaro.org>
 <1365371979.4457.4.camel@smarty>
Message-ID: <20130408121155.GA5044@S2101-09.ap.freescale.net>

On Sun, Apr 07, 2013 at 11:59:39PM +0200, Mathias Hasselmann wrote:
> Am Dienstag, den 02.04.2013, 22:31 +0800 schrieb Shawn Guo:
> > diff --git a/arch/arm/mach-imx/mxc.h b/arch/arm/mach-imx/mxc.h
> > index 7dce17a..8629e5b 100644
> > --- a/arch/arm/mach-imx/mxc.h
> > +++ b/arch/arm/mach-imx/mxc.h
> > @@ -34,6 +34,8 @@
> >  #define MXC_CPU_MX35		35
> >  #define MXC_CPU_MX51		51
> >  #define MXC_CPU_MX53		53
> > +#define MXC_CPU_IMX6DL		0x61
> > +#define MXC_CPU_IMX6Q		0x63
> >  
> >  #define IMX_CHIP_REVISION_1_0		0x10
> >  #define IMX_CHIP_REVISION_1_1		0x11
> 
> Hi Shawn,
> 
> Are the hexadecimal values for MXC_CPU_IMX6DL and MXC_CPU_IMX6Q correct?

The hexadecimal values are correct.  They are defined so to match Chip
Silicon Version (ANALOG_DIGPROG) register.

> I ask because Freescale's imx_3.0.35_1.1.0 kernel defines MXC_CPU_MX6DL
> and MXC_CPU_MX6Q with the decimal numbers 61 and 63.

In Freescale kernel, the value does not really matter, since the kernel
will use the macros in mxc_set_cpu_type() call.

Shawn



From b-cousson at ti.com  Mon Apr  8 08:12:44 2013
From: b-cousson at ti.com (Benoit Cousson)
Date: Mon, 8 Apr 2013 14:12:44 +0200
Subject: [PATCH 1/3] ARM: dts: Update OMAP3430 SDP NAND and ONENAND
 properties
In-Reply-To: <1365383828-25627-1-git-send-email-jon-hunter@ti.com>
References: <1365383828-25627-1-git-send-email-jon-hunter@ti.com>
Message-ID: <5162B43C.5000307@ti.com>

Hi Jon,

On 04/08/2013 03:17 AM, Jon Hunter wrote:
> The GPMC timing properties for device-tree have been updated by adding
> a "-ns" or "-ps" suffix to indicate the units of time the property
> represents (as suggested by Rob Herring). Therefore, update the timing
> property names for the OMAP3430 SDP NAND and ONENAND devices.
> 
> Signed-off-by: Jon Hunter <jon-hunter at ti.com>
> ---
> 
> Hi Benoit, this is a changed that is going to be introduced for v3.10.
> Feel free to squash this with the patch "ARM: dts: OMAP3: Add support
> for OMAP3430 SDP board" that you have queued for v3.10 if you prefer.

I applied them like that. I did not want to rebase again the whole series.


Regards,
Benoit


>  arch/arm/boot/dts/omap3430-sdp.dts |   56 ++++++++++++++++++------------------
>  1 file changed, 28 insertions(+), 28 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/omap3430-sdp.dts b/arch/arm/boot/dts/omap3430-sdp.dts
> index 05cd8ba..44d2191 100644
> --- a/arch/arm/boot/dts/omap3430-sdp.dts
> +++ b/arch/arm/boot/dts/omap3430-sdp.dts
> @@ -57,20 +57,20 @@
>  
>  		ti,nand-ecc-opt = "sw";
>  		gpmc,device-nand;
> -		gpmc,cs-on = <0>;
> -		gpmc,cs-rd-off = <36>;
> -		gpmc,cs-wr-off = <36>;
> -		gpmc,adv-on = <6>;
> -		gpmc,adv-rd-off = <24>;
> -		gpmc,adv-wr-off = <36>;
> -		gpmc,oe-on = <6>;
> -		gpmc,oe-off = <48>;
> -		gpmc,we-on = <6>;
> -		gpmc,we-off = <30>;
> -		gpmc,rd-cycle = <72>;
> -		gpmc,wr-cycle = <72>;
> -		gpmc,access = <54>;
> -		gpmc,wr-access = <30>;
> +		gpmc,cs-on-ns = <0>;
> +		gpmc,cs-rd-off-ns = <36>;
> +		gpmc,cs-wr-off-ns = <36>;
> +		gpmc,adv-on-ns = <6>;
> +		gpmc,adv-rd-off-ns = <24>;
> +		gpmc,adv-wr-off-ns = <36>;
> +		gpmc,oe-on-ns = <6>;
> +		gpmc,oe-off-ns = <48>;
> +		gpmc,we-on-ns = <6>;
> +		gpmc,we-off-ns = <30>;
> +		gpmc,rd-cycle-ns = <72>;
> +		gpmc,wr-cycle-ns = <72>;
> +		gpmc,access-ns = <54>;
> +		gpmc,wr-access-ns = <30>;
>  
>  		partition at 0 {
>  			label = "xloader-nand";
> @@ -102,20 +102,20 @@
>  
>  		gpmc,device-width = <2>;
>  		gpmc,mux-add-data = <2>;
> -		gpmc,cs-on = <0>;
> -		gpmc,cs-rd-off = <84>;
> -		gpmc,cs-wr-off = <72>;
> -		gpmc,adv-on = <0>;
> -		gpmc,adv-rd-off = <18>;
> -		gpmc,adv-wr-off = <18>;
> -		gpmc,oe-on = <30>;
> -		gpmc,oe-off = <84>;
> -		gpmc,we-on = <0>;
> -		gpmc,we-off = <42>;
> -		gpmc,rd-cycle = <108>;
> -		gpmc,wr-cycle = <96>;
> -		gpmc,access = <78>;
> -		gpmc,wr-data-mux-bus = <30>;
> +		gpmc,cs-on-ns = <0>;
> +		gpmc,cs-rd-off-ns = <84>;
> +		gpmc,cs-wr-off-ns = <72>;
> +		gpmc,adv-on-ns = <0>;
> +		gpmc,adv-rd-off-ns = <18>;
> +		gpmc,adv-wr-off-ns = <18>;
> +		gpmc,oe-on-ns = <30>;
> +		gpmc,oe-off-ns = <84>;
> +		gpmc,we-on-ns = <0>;
> +		gpmc,we-off-ns = <42>;
> +		gpmc,rd-cycle-ns = <108>;
> +		gpmc,wr-cycle-ns = <96>;
> +		gpmc,access-ns = <78>;
> +		gpmc,wr-data-mux-bus-ns = <30>;
>  
>  		partition at 0 {
>  			label = "xloader-onenand";
> 



From g.liakhovetski at gmx.de  Mon Apr  8 08:15:39 2013
From: g.liakhovetski at gmx.de (Guennadi Liakhovetski)
Date: Mon, 8 Apr 2013 14:15:39 +0200 (CEST)
Subject: [PATCH v3] irqchip: renesas-intc-irqpin: DT binding for sense
 bitfield width
In-Reply-To: <15518520.KQOfZxAAdo@avalon>
References: <Pine.LNX.4.64.1304081002190.29945@axis700.grange>
 <1694336.shM2ct4pzX@avalon> <Pine.LNX.4.64.1304081324370.29945@axis700.grange>
 <15518520.KQOfZxAAdo@avalon>
Message-ID: <Pine.LNX.4.64.1304081412550.29945@axis700.grange>

On Mon, 8 Apr 2013, Laurent Pinchart wrote:

> Hi Guennadi,
> 
> On Monday 08 April 2013 13:25:46 Guennadi Liakhovetski wrote:
> > On Mon, 8 Apr 2013, Laurent Pinchart wrote:
> > > On Monday 08 April 2013 10:08:40 Guennadi Liakhovetski wrote:
> > > > Most Renesas irqpin controllers have 4-bit sense fields, however, some
> > > > have different widths. This patch adds a DT binding to optionally
> > > > specify such non-standard values.
> > > > 
> > > > Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas at gmail.com>
> > > > ---
> > > > 
> > > > v3: move the code to a common location, where device configuration
> > > > parameters are retrieved
> > > > 
> > > >  .../interrupt-controller/renesas,intc-irqpin.txt   |   13 +++++++++++++
> > > >  drivers/irqchip/irq-renesas-intc-irqpin.c          |    4 ++++
> > > >  2 files changed, 17 insertions(+), 0 deletions(-)
> > > >  create mode 100644
> > > > 
> > > > Documentation/devicetree/bindings/interrupt-controller/renesas,intc-
> > > > irqpin.txt
> > > > diff --git a/Documentation/devicetree/bindings/interrupt-
> > > > controller/renesas,intc-irqpin.txt
> > > > b/Documentation/devicetree/bindings/interrupt-controller/renesas,intc-
> > > > irqpin.txt
> > > > new file mode 100644
> > > > index 0000000..c6f09b7
> > > > --- /dev/null
> > > > +++
> > > > b/Documentation/devicetree/bindings/interrupt-controller/renesas,intc-
> > > > irqpin.txt
> > > > @@ -0,0 +1,13 @@
> > > > +DT bindings for the R-/SH-Mobile irqpin controller
> > > > +
> > > > +Required properties:
> > > > +
> > > > +- compatible: has to be "renesas,intc-irqpin"
> > > > +- #interrupt-cells: has to be <2>
> > > > +
> > > > +Optional properties:
> > > > +
> > > > +- any properties, listed in interrupts.txt in this directory, and any
> > > > standard
> > > > +  resource allocation properties
> > > > +- sense-bitfield-width: width of a single sense bitfield in the SENSE
> > > > register,
> > > > +  if different from the default 4 bits
> > > 
> > > Wouldn't it be better to define per-SoC compatible strings, and infer the
> > > sense bitfield width from that ?
> > 
> > This is not a boolean, it is an integer, I don't think defining
> > compatibility strings for 1, 2, 3, 4, 5,... bits is better than having one
> > integer property.
> 
> I'm not advocating for compatibility strings for a given number of bits, but 
> for per-SoC compatibility strings from which to infer the width.
> 
> For instance, if the r8a7779 has a 6-bit sense field, you would use
> 
> compatible = "r8a7779,intc-irqpin";
> 
> and map that to 6 in the irqpin driver.

I understand what you mean, still I don't think mapping N 
SoC-compatibility strings to various values of a single integer is better 
than having a single property.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/


From ludovic.desroches at atmel.com  Mon Apr  8 08:19:30 2013
From: ludovic.desroches at atmel.com (Ludovic Desroches)
Date: Mon, 8 Apr 2013 14:19:30 +0200
Subject: [RFC v2 PATCH] at_hdmac: move to generic DMA binding
In-Reply-To: <20130408105515.GU20693@game.jcrosoft.org>
References: <1365403409-18381-1-git-send-email-ludovic.desroches@atmel.com>
 <20130408105515.GU20693@game.jcrosoft.org>
Message-ID: <20130408121930.GB6398@ludovic.desroches@atmel.com>

On Mon, Apr 08, 2013 at 12:55:15PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 08:43 Mon 08 Apr     , ludovic.desroches at atmel.com wrote:
> > From: Ludovic Desroches <ludovic.desroches at atmel.com>
> > 
> > Signed-off-by: Ludovic Desroches <ludovic.desroches at atmel.com>
> > ---
> > 
> > Hi,
> > 
> > Here is a second try to move at_hdmac to generic DMA binding. I have updated
> > bindings according to Arnd comments ie I have removed chunk transfer size.
> > 
> > I have added the implementation but I am not very happy with the translation
> > function. I have tried to not break old stuff: slave ask for a channel giving
> > an atslave structure (passed through pdata) as a parameter for the filter
> > function which saves this structure into chan->private. Then chan->private
> > contains the configuration for the channel CFG register which is done when
> > calling device_alloc_chan_resources.
> > 
> > If I allocate the atslave structure in the xlate function, where should be the
> > right place to deallocate it? For the moment, I choose to add the atslave
> > structure to the at_dma_chan structure but I am not happy with writing the
> > channel configuration register into the xlate function. I would like to keep
> > the same path as before.
> so allow with devm_

To my mind it's channel related and not controller related. If the channel is
released, will the deallocation be done automatically?

> > 
> > Regards
> > 
> > Ludovic
> > 
> > 
> >  .../devicetree/bindings/dma/atmel-dma.txt          | 27 +++++++-
> >  arch/arm/boot/dts/sama5d3.dtsi                     |  2 +
> >  drivers/dma/at_hdmac.c                             | 71 ++++++++++++++++++++--
> >  drivers/dma/at_hdmac_regs.h                        |  7 +++
> >  4 files changed, 99 insertions(+), 8 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/dma/atmel-dma.txt b/Documentation/devicetree/bindings/dma/atmel-dma.txt
> > index 3c046ee..2d6f0f3 100644
> > --- a/Documentation/devicetree/bindings/dma/atmel-dma.txt
> > +++ b/Documentation/devicetree/bindings/dma/atmel-dma.txt
> > @@ -4,11 +4,34 @@ Required properties:
> >  - compatible: Should be "atmel,<chip>-dma"
> >  - reg: Should contain DMA registers location and length
> >  - interrupts: Should contain DMA interrupt
> > +- #dma-cells: Must be <2>
> >  
> > -Examples:
> > +Example:
> >  
> > -dma at ffffec00 {
> > +dma0: dma at ffffec00 {
> >  	compatible = "atmel,at91sam9g45-dma";
> >  	reg = <0xffffec00 0x200>;
> >  	interrupts = <21>;
> > +	#dma-cells = <2>;
> > +};
> > +
> > +DMA clients connected to the Atmel DMA controller must use the format
> > +described in the dma.txt file, using a three-cell specifier for each channel.
> > +The three cells in order are:
> > +
> > +1. A phandle pointing to the DMA controller
> > +2. The memory interface (16 most significant bits), the peripheral interface
> > +(16 less significant bits)
> > +3. The peripheral identifier (can be different for tx and rx)
> > +
> > +Example:
> > +
> > +i2c0 at i2c@f8010000 {
> > +	compatible = "atmel,at91sam9x5-i2c";
> > +	reg = <0xf8010000 0x100>;
> > +	interrupts = <9 4 6>;
> > +	dmas = <&dma0 1 7>,
> > +	       <&dma0 1 8>;
> > +	dma-names = "tx", "rx"
> >  };
> > diff --git a/arch/arm/boot/dts/sama5d3.dtsi b/arch/arm/boot/dts/sama5d3.dtsi
> > index 39b0458..9232143 100644
> > --- a/arch/arm/boot/dts/sama5d3.dtsi
> > +++ b/arch/arm/boot/dts/sama5d3.dtsi
> > @@ -349,6 +349,7 @@
> >  				reg = <0xffffe600 0x200>;
> >  				interrupts = <30 4 0>;
> >  				#dma-cells = <1>;
> > +				#dma-cells = <2>;
> ??
> 
> 2 dma-cells?

Yes 2 dma-cells, mistake in the patch, the work is still in progress.

> >  			};
> >  
> >  			dma1: dma-controller at ffffe800 {
> > @@ -356,6 +357,7 @@
> >  				reg = <0xffffe800 0x200>;
> >  				interrupts = <31 4 0>;
> >  				#dma-cells = <1>;
> > +				#dma-cells = <2>;
> ditto
> >  			};
> >  
> >  			ramc0: ramc at ffffea00 {
> > diff --git a/drivers/dma/at_hdmac.c b/drivers/dma/at_hdmac.c
> > index 8415467..ec7f561 100644
> > --- a/drivers/dma/at_hdmac.c
> > +++ b/drivers/dma/at_hdmac.c
> > @@ -24,6 +24,7 @@
> >  #include <linux/slab.h>
> >  #include <linux/of.h>
> >  #include <linux/of_device.h>
> > +#include <linux/of_dma.h>
> >  
> >  #include "at_hdmac_regs.h"
> >  #include "dmaengine.h"
> > @@ -676,7 +677,7 @@ atc_prep_slave_sg(struct dma_chan *chan, struct scatterlist *sgl,
> >  		ctrlb |=  ATC_DST_ADDR_MODE_FIXED
> >  			| ATC_SRC_ADDR_MODE_INCR
> >  			| ATC_FC_MEM2PER
> > -			| ATC_SIF(AT_DMA_MEM_IF) | ATC_DIF(AT_DMA_PER_IF);
> > +			| ATC_SIF(atchan->mem_if) | ATC_DIF(atchan->per_if);
> >  		reg = sconfig->dst_addr;
> >  		for_each_sg(sgl, sg, sg_len, i) {
> >  			struct at_desc	*desc;
> > @@ -715,7 +716,7 @@ atc_prep_slave_sg(struct dma_chan *chan, struct scatterlist *sgl,
> >  		ctrlb |=  ATC_DST_ADDR_MODE_INCR
> >  			| ATC_SRC_ADDR_MODE_FIXED
> >  			| ATC_FC_PER2MEM
> > -			| ATC_SIF(AT_DMA_PER_IF) | ATC_DIF(AT_DMA_MEM_IF);
> > +			| ATC_SIF(atchan->per_if) | ATC_DIF(atchan->mem_if);
> >  
> >  		reg = sconfig->src_addr;
> >  		for_each_sg(sgl, sg, sg_len, i) {
> > @@ -821,8 +822,8 @@ atc_dma_cyclic_fill_desc(struct dma_chan *chan, struct at_desc *desc,
> >  		desc->lli.ctrlb = ATC_DST_ADDR_MODE_FIXED
> >  				| ATC_SRC_ADDR_MODE_INCR
> >  				| ATC_FC_MEM2PER
> > -				| ATC_SIF(AT_DMA_MEM_IF)
> > -				| ATC_DIF(AT_DMA_PER_IF);
> > +				| ATC_SIF(atchan->mem_if)
> > +				| ATC_DIF(atchan->per_if);
> >  		break;
> >  
> >  	case DMA_DEV_TO_MEM:
> > @@ -832,8 +833,8 @@ atc_dma_cyclic_fill_desc(struct dma_chan *chan, struct at_desc *desc,
> >  		desc->lli.ctrlb = ATC_DST_ADDR_MODE_INCR
> >  				| ATC_SRC_ADDR_MODE_FIXED
> >  				| ATC_FC_PER2MEM
> > -				| ATC_SIF(AT_DMA_PER_IF)
> > -				| ATC_DIF(AT_DMA_MEM_IF);
> > +				| ATC_SIF(atchan->per_if)
> > +				| ATC_DIF(atchan->mem_if);
> >  		break;
> >  
> >  	default:
> > @@ -1189,6 +1190,55 @@ static void atc_free_chan_resources(struct dma_chan *chan)
> >  	dev_vdbg(chan2dev(chan), "free_chan_resources: done\n");
> >  }
> >  
> > +static bool at_dma_filter(struct dma_chan *chan, void *dma_dev)
> > +{
> > +	if (dma_dev == chan->device->dev)
> > +		return true;
> > +	else
> > +		return false;
> > +}
> > +
> > +static struct dma_chan *at_dma_xlate(struct of_phandle_args *dma_spec,
> > +				     struct of_dma *of_dma)
> > +{
> > +	struct dma_chan *chan;
> > +	struct at_dma_chan *atchan;
> > +	struct at_dma_slave *atslave;
> > +	dma_cap_mask_t mask;
> > +	unsigned int per_id;
> > +	struct platform_device *dmac_pdev;
> > +
> > +	if (dma_spec->args_count != 2)
> > +		return NULL;
> > +
> > +	dmac_pdev = of_find_device_by_node(dma_spec->np);
> > +
> > +	dma_cap_zero(mask);
> > +	dma_cap_set(DMA_SLAVE, mask);
> > +
> > +	chan = dma_request_channel(mask, at_dma_filter, &dmac_pdev->dev);
> > +	if (!chan)
> > +		return NULL;
> > +
> > +	atchan = to_at_dma_chan(chan);
> > +	atchan->per_if = dma_spec->args[0] & 0xff;
> > +	atchan->mem_if = (dma_spec->args[0] >> 16) & 0xff;
> > +
> > +	atslave = &atchan->atslave;
> > +	/*
> > +	 * We can fill both SRC_PER and DST_PER, one of these fields will be
> > +	 * ignored depending on DMA transfer direction.
> > +	 */
> > +	per_id = dma_spec->args[1];
> > +	atslave->cfg = ATC_FIFOCFG_HALFFIFO | ATC_DST_H2SEL_HW
> > +		      | ATC_SRC_H2SEL_HW | ATC_DST_PER(per_id)
> > +		      | ATC_SRC_PER(per_id);
> > +	atslave->dma_dev = &dmac_pdev->dev;
> > +	chan->private = atslave;
> > +	channel_writel(atchan, CFG, atslave->cfg);
> > +
> > +	return chan;
> > +}
> >  
> >  /*--  Module Management  -----------------------------------------------*/
> >  
> > @@ -1389,6 +1439,15 @@ static int __init at_dma_probe(struct platform_device *pdev)
> >  
> >  	dma_async_device_register(&atdma->dma_common);
> >  
> > +	if (pdev->dev.of_node) {
> more simple return if NULL
> > +		printk("=== of_dma_controller_register ===\n");
> drop this

of course, I'll drop it for the submission

> > +		err = of_dma_controller_register(pdev->dev.of_node,
> > +						 at_dma_xlate, atdma);
> > +		if (err && err != -ENODEV)
> > +			dev_err(&pdev->dev,
> > +				"could not register of_dma_controller\n");
> 		if err you need to return err

ok

> > +	}
> > +
> >  	return 0;
> >  
> >  err_pool_create:
> > diff --git a/drivers/dma/at_hdmac_regs.h b/drivers/dma/at_hdmac_regs.h
> > index 0eb3c13..e3d2f12 100644
> > --- a/drivers/dma/at_hdmac_regs.h
> > +++ b/drivers/dma/at_hdmac_regs.h
> > @@ -220,6 +220,8 @@ enum atc_status {
> >   * @device: parent device
> >   * @ch_regs: memory mapped register base
> >   * @mask: channel index in a mask
> > + * @per_if: peripheral interface
> > + * @mem_if: memory interface
> >   * @status: transmit status information from irq/prep* functions
> >   *                to tasklet (use atomic operations)
> >   * @tasklet: bottom half to finish transaction work
> > @@ -227,6 +229,8 @@ enum atc_status {
> >   * @save_dscr: for cyclic operations, preserve next descriptor address in
> >   *             the cyclic list on suspend/resume cycle
> >   * @dma_sconfig: configuration for slave transfers, passed via DMA_SLAVE_CONFIG
> > + * @atslave: hardware configuration for slave transfers which is not passed via
> > + * DMA_SLAVE_CONFIG
> >   * @lock: serializes enqueue/dequeue operations to descriptors lists
> >   * @active_list: list of descriptors dmaengine is being running on
> >   * @queue: list of descriptors ready to be submitted to engine
> > @@ -238,11 +242,14 @@ struct at_dma_chan {
> >  	struct at_dma		*device;
> >  	void __iomem		*ch_regs;
> >  	u8			mask;
> > +	u8			per_if;
> > +	u8			mem_if;
> >  	unsigned long		status;
> >  	struct tasklet_struct	tasklet;
> >  	u32			save_cfg;
> >  	u32			save_dscr;
> >  	struct dma_slave_config dma_sconfig;
> > +	struct at_dma_slave	atslave;
> >  
> >  	spinlock_t		lock;
> >  
> > -- 
> > 1.7.11.3
> > 


From tgih.jun at samsung.com  Mon Apr  8 08:19:27 2013
From: tgih.jun at samsung.com (Seungwon Jeon)
Date: Mon, 08 Apr 2013 21:19:27 +0900
Subject: [PATCH v3] mmc: dw_mmc: let device core setup the default pin
 configuration
In-Reply-To: <1365170015-3009-1-git-send-email-thomas.abraham@linaro.org>
References: <1365170015-3009-1-git-send-email-thomas.abraham@linaro.org>
Message-ID: <003501ce3453$502adf80$f0809e80$%jun@samsung.com>

On Friday, April 05, 2013, Thomas Abraham wrote:
> With device core now able to setup the default pin configuration,
> the pin configuration code based on the deprecated Samsung specific
> gpio bindings is removed.
> 
> Signed-off-by: Thomas Abraham <thomas.abraham at linaro.org>
Acked-by: Seungwon Jeon <tgih.jun at samsung.com>

I hope that your another patch is merged.
 ARM: dts: add pinctrl nodes for Exynos5250 SoC
I didn't check whether it is applied.

Thanks,
Seungwon Jeon



From prabhakar.csengg at gmail.com  Mon Apr  8 08:19:10 2013
From: prabhakar.csengg at gmail.com (Prabhakar lad)
Date: Mon,  8 Apr 2013 17:49:10 +0530
Subject: [PATCH v3 0/3] davinci: vpss: clock cleanup
Message-ID: <1365423553-12619-1-git-send-email-prabhakar.csengg@gmail.com>

From: Lad, Prabhakar <prabhakar.csengg at gmail.com>

This patch series cleanup's the VPSS clock enabling.
The first patch removes vpss clock enabling from the capture
drivers and moves it to the VPSS driver itself.
The second patch moves the venc_enable_vpss_clock() to the driver
which was being done in platform code.

Changes for v3:
1: Changed the commit message for first patch as pointed by Sekhar.
2: Removed a semicolon after NULL in con_ids as pointed by Sekhar.
3: Included the Ack from Sekhar for first patch.

Changes for v2:
1: Used PM runtime API for clock handling and nit's pointed by Sekhar.

Lad, Prabhakar (3):
  media: davinci: vpss: enable vpss clocks
  media: davinci: vpbe: venc: move the enabling of vpss clocks to
    driver
  davinic: vpss: trivial cleanup

 arch/arm/mach-davinci/dm355.c                |    7 +---
 arch/arm/mach-davinci/dm365.c                |   11 +++++--
 arch/arm/mach-davinci/dm644x.c               |    9 +----
 arch/arm/mach-davinci/pm_domain.c            |    2 +-
 drivers/media/platform/davinci/dm355_ccdc.c  |   39 +----------------------
 drivers/media/platform/davinci/dm644x_ccdc.c |   44 --------------------------
 drivers/media/platform/davinci/isif.c        |   28 ++--------------
 drivers/media/platform/davinci/vpbe_venc.c   |   25 ++++++++++++++
 drivers/media/platform/davinci/vpss.c        |   36 ++++++++++++++++-----
 9 files changed, 71 insertions(+), 130 deletions(-)

-- 
1.7.4.1



From prabhakar.csengg at gmail.com  Mon Apr  8 08:19:11 2013
From: prabhakar.csengg at gmail.com (Prabhakar lad)
Date: Mon,  8 Apr 2013 17:49:11 +0530
Subject: [PATCH v3 1/3] media: davinci: vpss: enable vpss clocks
In-Reply-To: <1365423553-12619-1-git-send-email-prabhakar.csengg@gmail.com>
References: <1365423553-12619-1-git-send-email-prabhakar.csengg@gmail.com>
Message-ID: <1365423553-12619-2-git-send-email-prabhakar.csengg@gmail.com>

From: Lad, Prabhakar <prabhakar.csengg at gmail.com>

By default the VPSS clocks were enabled in capture driver
for davinci family which creates duplicates for dm355/dm365/dm644x.
This patch adds support to enable the VPSS clocks in VPSS driver,
which avoids duplication of code and also adding clock aliases.

This patch uses PM runtime API to enable/disable clock, instead
of DaVinci clock framework. con_ids for master and slave clocks of
vpss is added in pm_domain.

This patch cleanups the VPSS clock enabling in the capture driver,
and also removes the clock alias in machine file. Along side adds
a vpss slave clock for DM365 as mentioned by Sekhar
(https://patchwork.kernel.org/patch/1221261/).

The Suspend/Resume in dm644x_ccdc.c which enabled/disabled the VPSS clock
is now implemented as part of the VPSS driver.

Signed-off-by: Lad, Prabhakar <prabhakar.csengg at gmail.com>
Acked-by: Sekhar Nori <nsekhar at ti.com>
---
 arch/arm/mach-davinci/dm355.c                |    7 +---
 arch/arm/mach-davinci/dm365.c                |   11 +++++--
 arch/arm/mach-davinci/dm644x.c               |    9 +----
 arch/arm/mach-davinci/pm_domain.c            |    2 +-
 drivers/media/platform/davinci/dm355_ccdc.c  |   39 +----------------------
 drivers/media/platform/davinci/dm644x_ccdc.c |   44 --------------------------
 drivers/media/platform/davinci/isif.c        |   28 ++--------------
 drivers/media/platform/davinci/vpss.c        |   25 ++++++++++++++
 8 files changed, 43 insertions(+), 122 deletions(-)

diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index b49c3b7..8e98bb0 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -345,8 +345,8 @@ static struct clk_lookup dm355_clks[] = {
 	CLK(NULL, "pll1_aux", &pll1_aux_clk),
 	CLK(NULL, "pll1_sysclkbp", &pll1_sysclkbp),
 	CLK(NULL, "vpss_dac", &vpss_dac_clk),
-	CLK(NULL, "vpss_master", &vpss_master_clk),
-	CLK(NULL, "vpss_slave", &vpss_slave_clk),
+	CLK("vpss", "master", &vpss_master_clk),
+	CLK("vpss", "slave", &vpss_slave_clk),
 	CLK(NULL, "clkout1", &clkout1_clk),
 	CLK(NULL, "clkout2", &clkout2_clk),
 	CLK(NULL, "pll2", &pll2_clk),
@@ -873,9 +873,6 @@ static int __init dm355_init_devices(void)
 	if (!cpu_is_davinci_dm355())
 		return 0;
 
-	/* Add ccdc clock aliases */
-	clk_add_alias("master", dm355_ccdc_dev.name, "vpss_master", NULL);
-	clk_add_alias("slave", dm355_ccdc_dev.name, "vpss_master", NULL);
 	davinci_cfg_reg(DM355_INT_EDMA_CC);
 	platform_device_register(&dm355_edma_device);
 	platform_device_register(&dm355_vpss_device);
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index 6c39805..c61dd94 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -257,6 +257,12 @@ static struct clk vpss_master_clk = {
 	.flags		= CLK_PSC,
 };
 
+static struct clk vpss_slave_clk = {
+	.name		= "vpss_slave",
+	.parent		= &pll1_sysclk5,
+	.lpsc		= DAVINCI_LPSC_VPSSSLV,
+};
+
 static struct clk arm_clk = {
 	.name		= "arm_clk",
 	.parent		= &pll2_sysclk2,
@@ -449,7 +455,8 @@ static struct clk_lookup dm365_clks[] = {
 	CLK(NULL, "pll2_sysclk8", &pll2_sysclk8),
 	CLK(NULL, "pll2_sysclk9", &pll2_sysclk9),
 	CLK(NULL, "vpss_dac", &vpss_dac_clk),
-	CLK(NULL, "vpss_master", &vpss_master_clk),
+	CLK("vpss", "master", &vpss_master_clk),
+	CLK("vpss", "slave", &vpss_slave_clk),
 	CLK(NULL, "arm", &arm_clk),
 	CLK(NULL, "uart0", &uart0_clk),
 	CLK(NULL, "uart1", &uart1_clk),
@@ -1239,8 +1246,6 @@ static int __init dm365_init_devices(void)
 	clk_add_alias(NULL, dev_name(&dm365_mdio_device.dev),
 		      NULL, &dm365_emac_device.dev);
 
-	/* Add isif clock alias */
-	clk_add_alias("master", dm365_isif_dev.name, "vpss_master", NULL);
 	platform_device_register(&dm365_vpss_device);
 	platform_device_register(&dm365_isif_dev);
 	platform_device_register(&vpfe_capture_dev);
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index ee0e994..c2a9273 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -300,8 +300,8 @@ static struct clk_lookup dm644x_clks[] = {
 	CLK(NULL, "dsp", &dsp_clk),
 	CLK(NULL, "arm", &arm_clk),
 	CLK(NULL, "vicp", &vicp_clk),
-	CLK(NULL, "vpss_master", &vpss_master_clk),
-	CLK(NULL, "vpss_slave", &vpss_slave_clk),
+	CLK("vpss", "master", &vpss_master_clk),
+	CLK("vpss", "slave", &vpss_slave_clk),
 	CLK(NULL, "arm", &arm_clk),
 	CLK(NULL, "uart0", &uart0_clk),
 	CLK(NULL, "uart1", &uart1_clk),
@@ -901,11 +901,6 @@ int __init dm644x_init_video(struct vpfe_config *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) {
diff --git a/arch/arm/mach-davinci/pm_domain.c b/arch/arm/mach-davinci/pm_domain.c
index c90250e..6b98413 100644
--- a/arch/arm/mach-davinci/pm_domain.c
+++ b/arch/arm/mach-davinci/pm_domain.c
@@ -53,7 +53,7 @@ static struct dev_pm_domain davinci_pm_domain = {
 
 static struct pm_clk_notifier_block platform_bus_notifier = {
 	.pm_domain = &davinci_pm_domain,
-	.con_ids = { "fck", NULL, },
+	.con_ids = { "fck", "master", "slave", NULL },
 };
 
 static int __init davinci_pm_runtime_init(void)
diff --git a/drivers/media/platform/davinci/dm355_ccdc.c b/drivers/media/platform/davinci/dm355_ccdc.c
index 2364dba..05f8fb7 100644
--- a/drivers/media/platform/davinci/dm355_ccdc.c
+++ b/drivers/media/platform/davinci/dm355_ccdc.c
@@ -37,7 +37,6 @@
 #include <linux/platform_device.h>
 #include <linux/uaccess.h>
 #include <linux/videodev2.h>
-#include <linux/clk.h>
 #include <linux/err.h>
 #include <linux/module.h>
 
@@ -59,10 +58,6 @@ static struct ccdc_oper_config {
 	struct ccdc_params_raw bayer;
 	/* YCbCr configuration */
 	struct ccdc_params_ycbcr ycbcr;
-	/* Master clock */
-	struct clk *mclk;
-	/* slave clock */
-	struct clk *sclk;
 	/* ccdc base address */
 	void __iomem *base_addr;
 } ccdc_cfg = {
@@ -997,32 +992,10 @@ static int dm355_ccdc_probe(struct platform_device *pdev)
 		goto fail_nomem;
 	}
 
-	/* Get and enable Master clock */
-	ccdc_cfg.mclk = clk_get(&pdev->dev, "master");
-	if (IS_ERR(ccdc_cfg.mclk)) {
-		status = PTR_ERR(ccdc_cfg.mclk);
-		goto fail_nomap;
-	}
-	if (clk_prepare_enable(ccdc_cfg.mclk)) {
-		status = -ENODEV;
-		goto fail_mclk;
-	}
-
-	/* Get and enable Slave clock */
-	ccdc_cfg.sclk = clk_get(&pdev->dev, "slave");
-	if (IS_ERR(ccdc_cfg.sclk)) {
-		status = PTR_ERR(ccdc_cfg.sclk);
-		goto fail_mclk;
-	}
-	if (clk_prepare_enable(ccdc_cfg.sclk)) {
-		status = -ENODEV;
-		goto fail_sclk;
-	}
-
 	/* Platform data holds setup_pinmux function ptr */
 	if (NULL == pdev->dev.platform_data) {
 		status = -ENODEV;
-		goto fail_sclk;
+		goto fail_nomap;
 	}
 	setup_pinmux = pdev->dev.platform_data;
 	/*
@@ -1033,12 +1006,6 @@ static int dm355_ccdc_probe(struct platform_device *pdev)
 	ccdc_cfg.dev = &pdev->dev;
 	printk(KERN_NOTICE "%s is registered with vpfe.\n", ccdc_hw_dev.name);
 	return 0;
-fail_sclk:
-	clk_disable_unprepare(ccdc_cfg.sclk);
-	clk_put(ccdc_cfg.sclk);
-fail_mclk:
-	clk_disable_unprepare(ccdc_cfg.mclk);
-	clk_put(ccdc_cfg.mclk);
 fail_nomap:
 	iounmap(ccdc_cfg.base_addr);
 fail_nomem:
@@ -1052,10 +1019,6 @@ static int dm355_ccdc_remove(struct platform_device *pdev)
 {
 	struct resource	*res;
 
-	clk_disable_unprepare(ccdc_cfg.sclk);
-	clk_disable_unprepare(ccdc_cfg.mclk);
-	clk_put(ccdc_cfg.mclk);
-	clk_put(ccdc_cfg.sclk);
 	iounmap(ccdc_cfg.base_addr);
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 	if (res)
diff --git a/drivers/media/platform/davinci/dm644x_ccdc.c b/drivers/media/platform/davinci/dm644x_ccdc.c
index 971d639..30fa084 100644
--- a/drivers/media/platform/davinci/dm644x_ccdc.c
+++ b/drivers/media/platform/davinci/dm644x_ccdc.c
@@ -38,7 +38,6 @@
 #include <linux/uaccess.h>
 #include <linux/videodev2.h>
 #include <linux/gfp.h>
-#include <linux/clk.h>
 #include <linux/err.h>
 #include <linux/module.h>
 
@@ -60,10 +59,6 @@ static struct ccdc_oper_config {
 	struct ccdc_params_raw bayer;
 	/* YCbCr configuration */
 	struct ccdc_params_ycbcr ycbcr;
-	/* Master clock */
-	struct clk *mclk;
-	/* slave clock */
-	struct clk *sclk;
 	/* ccdc base address */
 	void __iomem *base_addr;
 } ccdc_cfg = {
@@ -991,38 +986,9 @@ static int dm644x_ccdc_probe(struct platform_device *pdev)
 		goto fail_nomem;
 	}
 
-	/* Get and enable Master clock */
-	ccdc_cfg.mclk = clk_get(&pdev->dev, "master");
-	if (IS_ERR(ccdc_cfg.mclk)) {
-		status = PTR_ERR(ccdc_cfg.mclk);
-		goto fail_nomap;
-	}
-	if (clk_prepare_enable(ccdc_cfg.mclk)) {
-		status = -ENODEV;
-		goto fail_mclk;
-	}
-
-	/* Get and enable Slave clock */
-	ccdc_cfg.sclk = clk_get(&pdev->dev, "slave");
-	if (IS_ERR(ccdc_cfg.sclk)) {
-		status = PTR_ERR(ccdc_cfg.sclk);
-		goto fail_mclk;
-	}
-	if (clk_prepare_enable(ccdc_cfg.sclk)) {
-		status = -ENODEV;
-		goto fail_sclk;
-	}
 	ccdc_cfg.dev = &pdev->dev;
 	printk(KERN_NOTICE "%s is registered with vpfe.\n", ccdc_hw_dev.name);
 	return 0;
-fail_sclk:
-	clk_disable_unprepare(ccdc_cfg.sclk);
-	clk_put(ccdc_cfg.sclk);
-fail_mclk:
-	clk_disable_unprepare(ccdc_cfg.mclk);
-	clk_put(ccdc_cfg.mclk);
-fail_nomap:
-	iounmap(ccdc_cfg.base_addr);
 fail_nomem:
 	release_mem_region(res->start, resource_size(res));
 fail_nores:
@@ -1034,10 +1000,6 @@ static int dm644x_ccdc_remove(struct platform_device *pdev)
 {
 	struct resource	*res;
 
-	clk_disable_unprepare(ccdc_cfg.mclk);
-	clk_disable_unprepare(ccdc_cfg.sclk);
-	clk_put(ccdc_cfg.mclk);
-	clk_put(ccdc_cfg.sclk);
 	iounmap(ccdc_cfg.base_addr);
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 	if (res)
@@ -1052,18 +1014,12 @@ static int dm644x_ccdc_suspend(struct device *dev)
 	ccdc_save_context();
 	/* Disable CCDC */
 	ccdc_enable(0);
-	/* Disable both master and slave clock */
-	clk_disable_unprepare(ccdc_cfg.mclk);
-	clk_disable_unprepare(ccdc_cfg.sclk);
 
 	return 0;
 }
 
 static int dm644x_ccdc_resume(struct device *dev)
 {
-	/* Enable both master and slave clock */
-	clk_prepare_enable(ccdc_cfg.mclk);
-	clk_prepare_enable(ccdc_cfg.sclk);
 	/* Restore CCDC context */
 	ccdc_restore_context();
 
diff --git a/drivers/media/platform/davinci/isif.c b/drivers/media/platform/davinci/isif.c
index abc3ae3..3332cca 100644
--- a/drivers/media/platform/davinci/isif.c
+++ b/drivers/media/platform/davinci/isif.c
@@ -32,7 +32,6 @@
 #include <linux/uaccess.h>
 #include <linux/io.h>
 #include <linux/videodev2.h>
-#include <linux/clk.h>
 #include <linux/err.h>
 #include <linux/module.h>
 
@@ -88,8 +87,6 @@ static struct isif_oper_config {
 	struct isif_ycbcr_config ycbcr;
 	struct isif_params_raw bayer;
 	enum isif_data_pack data_pack;
-	/* Master clock */
-	struct clk *mclk;
 	/* ISIF base address */
 	void __iomem *base_addr;
 	/* ISIF Linear Table 0 */
@@ -1039,6 +1036,10 @@ static int isif_probe(struct platform_device *pdev)
 	void *__iomem addr;
 	int status = 0, i;
 
+	/* Platform data holds setup_pinmux function ptr */
+	if (!pdev->dev.platform_data)
+		return -ENODEV;
+
 	/*
 	 * first try to register with vpfe. If not correct platform, then we
 	 * don't have to iomap
@@ -1047,22 +1048,6 @@ static int isif_probe(struct platform_device *pdev)
 	if (status < 0)
 		return status;
 
-	/* Get and enable Master clock */
-	isif_cfg.mclk = clk_get(&pdev->dev, "master");
-	if (IS_ERR(isif_cfg.mclk)) {
-		status = PTR_ERR(isif_cfg.mclk);
-		goto fail_mclk;
-	}
-	if (clk_prepare_enable(isif_cfg.mclk)) {
-		status = -ENODEV;
-		goto fail_mclk;
-	}
-
-	/* Platform data holds setup_pinmux function ptr */
-	if (NULL == pdev->dev.platform_data) {
-		status = -ENODEV;
-		goto fail_mclk;
-	}
 	setup_pinmux = pdev->dev.platform_data;
 	/*
 	 * setup Mux configuration for ccdc which may be different for
@@ -1124,9 +1109,6 @@ fail_nobase_res:
 		release_mem_region(res->start, resource_size(res));
 		i--;
 	}
-fail_mclk:
-	clk_disable_unprepare(isif_cfg.mclk);
-	clk_put(isif_cfg.mclk);
 	vpfe_unregister_ccdc_device(&isif_hw_dev);
 	return status;
 }
@@ -1146,8 +1128,6 @@ static int isif_remove(struct platform_device *pdev)
 		i++;
 	}
 	vpfe_unregister_ccdc_device(&isif_hw_dev);
-	clk_disable_unprepare(isif_cfg.mclk);
-	clk_put(isif_cfg.mclk);
 	return 0;
 }
 
diff --git a/drivers/media/platform/davinci/vpss.c b/drivers/media/platform/davinci/vpss.c
index a19c552..d36429d 100644
--- a/drivers/media/platform/davinci/vpss.c
+++ b/drivers/media/platform/davinci/vpss.c
@@ -25,6 +25,8 @@
 #include <linux/spinlock.h>
 #include <linux/compiler.h>
 #include <linux/io.h>
+#include <linux/pm_runtime.h>
+
 #include <media/davinci/vpss.h>
 
 MODULE_LICENSE("GPL");
@@ -490,6 +492,10 @@ static int vpss_probe(struct platform_device *pdev)
 	} else
 		oper_cfg.hw_ops.clear_wbl_overflow = dm644x_clear_wbl_overflow;
 
+	pm_runtime_enable(&pdev->dev);
+
+	pm_runtime_get(&pdev->dev);
+
 	spin_lock_init(&oper_cfg.vpss_lock);
 	dev_info(&pdev->dev, "%s vpss probe success\n", platform_name);
 	return 0;
@@ -507,6 +513,7 @@ static int vpss_remove(struct platform_device *pdev)
 {
 	struct resource		*res;
 
+	pm_runtime_disable(&pdev->dev);
 	iounmap(oper_cfg.vpss_regs_base0);
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 	release_mem_region(res->start, resource_size(res));
@@ -518,10 +525,28 @@ static int vpss_remove(struct platform_device *pdev)
 	return 0;
 }
 
+static int vpss_suspend(struct device *dev)
+{
+	pm_runtime_put(dev);
+	return 0;
+}
+
+static int vpss_resume(struct device *dev)
+{
+	pm_runtime_get(dev);
+	return 0;
+}
+
+static const struct dev_pm_ops vpss_pm_ops = {
+	.suspend = vpss_suspend,
+	.resume = vpss_resume,
+};
+
 static struct platform_driver vpss_driver = {
 	.driver = {
 		.name	= "vpss",
 		.owner = THIS_MODULE,
+		.pm = &vpss_pm_ops,
 	},
 	.remove = vpss_remove,
 	.probe = vpss_probe,
-- 
1.7.4.1



From broonie at opensource.wolfsonmicro.com  Mon Apr  8 08:20:57 2013
From: broonie at opensource.wolfsonmicro.com (Mark Brown)
Date: Mon, 8 Apr 2013 13:20:57 +0100
Subject: [PATCH V3 4/5] spi: s3c64xx: Added provision for dedicated cs pin
In-Reply-To: <CAKrE-KevVramLc1n_9kcfHVb=RKT_kexQ8iUP-5+BL3wxpMPbQ@mail.gmail.com>
References: <1363157014-9615-1-git-send-email-ks.giri@samsung.com>
 <1363157014-9615-5-git-send-email-ks.giri@samsung.com>
 <20130401125744.GG18636@opensource.wolfsonmicro.com>
 <CAKrE-Kd+YAFmteDdh3odtV+YU1=OjoMuQV9usF4NmUse+TXhTg@mail.gmail.com>
 <20130408101530.GC9243@opensource.wolfsonmicro.com>
 <CAKrE-KevVramLc1n_9kcfHVb=RKT_kexQ8iUP-5+BL3wxpMPbQ@mail.gmail.com>
Message-ID: <20130408122056.GG9243@opensource.wolfsonmicro.com>

On Mon, Apr 08, 2013 at 05:15:26PM +0530, Girish KS wrote:
> On Mon, Apr 8, 2013 at 3:45 PM, Mark Brown

> > Two options here, one is to just assume nobody will use GPIO 0 and the
> > other is to set the number appopriately during probe so that only probe
> > needs to worry about the issue.
> 
> In the second option if the gpio number is set in the probe, then we
> are overwriting the
> actual gpio number assigned in the platform data.
> If I move the cs_gpio from the platform data to controller private
> data then the dependency
> on other platforms can be removed, but still the check (true or false)
> before setting the gpio
> line will remain. If agreed upon this i can go ahead and post the patch

I think logic in probe should be fine, it just felt really cumbersome
having this on every single use but doing it once on probe ought to be
OK.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130408/16a9e989/attachment.sig>

From prabhakar.csengg at gmail.com  Mon Apr  8 08:19:12 2013
From: prabhakar.csengg at gmail.com (Prabhakar lad)
Date: Mon,  8 Apr 2013 17:49:12 +0530
Subject: [PATCH v3 2/3] media: davinci: vpbe: venc: move the enabling of vpss
 clocks to driver
In-Reply-To: <1365423553-12619-1-git-send-email-prabhakar.csengg@gmail.com>
References: <1365423553-12619-1-git-send-email-prabhakar.csengg@gmail.com>
Message-ID: <1365423553-12619-3-git-send-email-prabhakar.csengg@gmail.com>

From: Lad, Prabhakar <prabhakar.csengg at gmail.com>

The vpss clocks were enabled by calling a exported function from a driver
in a machine code. calling driver code from platform code is incorrect way.

This patch fixes this issue and calls the function from driver code itself.

Signed-off-by: Lad, Prabhakar <prabhakar.csengg at gmail.com>
---
 drivers/media/platform/davinci/vpbe_venc.c |   25 +++++++++++++++++++++++++
 1 files changed, 25 insertions(+), 0 deletions(-)

diff --git a/drivers/media/platform/davinci/vpbe_venc.c b/drivers/media/platform/davinci/vpbe_venc.c
index f15f211..91d0272 100644
--- a/drivers/media/platform/davinci/vpbe_venc.c
+++ b/drivers/media/platform/davinci/vpbe_venc.c
@@ -202,6 +202,25 @@ static void venc_enabledigitaloutput(struct v4l2_subdev *sd, int benable)
 	}
 }
 
+static void
+venc_enable_vpss_clock(int venc_type,
+		       enum vpbe_enc_timings_type type,
+		       unsigned int pclock)
+{
+	if (venc_type == VPBE_VERSION_1)
+		return;
+
+	if (venc_type == VPBE_VERSION_2 && (type == VPBE_ENC_STD ||
+	    (type == VPBE_ENC_DV_TIMINGS && pclock <= 27000000))) {
+		vpss_enable_clock(VPSS_VENC_CLOCK_SEL, 1);
+		vpss_enable_clock(VPSS_VPBE_CLOCK, 1);
+		return;
+	}
+
+	if (venc_type == VPBE_VERSION_3 && type == VPBE_ENC_STD)
+		vpss_enable_clock(VPSS_VENC_CLOCK_SEL, 0);
+}
+
 #define VDAC_CONFIG_SD_V3	0x0E21A6B6
 #define VDAC_CONFIG_SD_V2	0x081141CF
 /*
@@ -220,6 +239,7 @@ static int venc_set_ntsc(struct v4l2_subdev *sd)
 	if (pdata->setup_clock(VPBE_ENC_STD, V4L2_STD_525_60) < 0)
 		return -EINVAL;
 
+	venc_enable_vpss_clock(venc->venc_type, VPBE_ENC_STD, V4L2_STD_525_60);
 	venc_enabledigitaloutput(sd, 0);
 
 	if (venc->venc_type == VPBE_VERSION_3) {
@@ -265,6 +285,7 @@ static int venc_set_pal(struct v4l2_subdev *sd)
 	if (venc->pdata->setup_clock(VPBE_ENC_STD, V4L2_STD_625_50) < 0)
 		return -EINVAL;
 
+	venc_enable_vpss_clock(venc->venc_type, VPBE_ENC_STD, V4L2_STD_625_50);
 	venc_enabledigitaloutput(sd, 0);
 
 	if (venc->venc_type == VPBE_VERSION_3) {
@@ -319,6 +340,7 @@ static int venc_set_480p59_94(struct v4l2_subdev *sd)
 	if (pdata->setup_clock(VPBE_ENC_DV_TIMINGS, 27000000) < 0)
 		return -EINVAL;
 
+	venc_enable_vpss_clock(venc->venc_type, VPBE_ENC_DV_TIMINGS, 27000000);
 	venc_enabledigitaloutput(sd, 0);
 
 	if (venc->venc_type == VPBE_VERSION_2)
@@ -366,6 +388,7 @@ static int venc_set_576p50(struct v4l2_subdev *sd)
 	if (pdata->setup_clock(VPBE_ENC_DV_TIMINGS, 27000000) < 0)
 		return -EINVAL;
 
+	venc_enable_vpss_clock(venc->venc_type, VPBE_ENC_DV_TIMINGS, 27000000);
 	venc_enabledigitaloutput(sd, 0);
 
 	if (venc->venc_type == VPBE_VERSION_2)
@@ -406,6 +429,7 @@ static int venc_set_720p60_internal(struct v4l2_subdev *sd)
 	if (pdata->setup_clock(VPBE_ENC_DV_TIMINGS, 74250000) < 0)
 		return -EINVAL;
 
+	venc_enable_vpss_clock(venc->venc_type, VPBE_ENC_DV_TIMINGS, 74250000);
 	venc_enabledigitaloutput(sd, 0);
 
 	venc_write(sd, VENC_OSDCLK0, 0);
@@ -434,6 +458,7 @@ static int venc_set_1080i30_internal(struct v4l2_subdev *sd)
 	if (pdata->setup_clock(VPBE_ENC_DV_TIMINGS, 74250000) < 0)
 		return -EINVAL;
 
+	venc_enable_vpss_clock(venc->venc_type, VPBE_ENC_DV_TIMINGS, 74250000);
 	venc_enabledigitaloutput(sd, 0);
 
 	venc_write(sd, VENC_OSDCLK0, 0);
-- 
1.7.4.1



From prabhakar.csengg at gmail.com  Mon Apr  8 08:19:13 2013
From: prabhakar.csengg at gmail.com (Prabhakar lad)
Date: Mon,  8 Apr 2013 17:49:13 +0530
Subject: [PATCH v3 3/3] davinic: vpss: trivial cleanup
In-Reply-To: <1365423553-12619-1-git-send-email-prabhakar.csengg@gmail.com>
References: <1365423553-12619-1-git-send-email-prabhakar.csengg@gmail.com>
Message-ID: <1365423553-12619-4-git-send-email-prabhakar.csengg@gmail.com>

From: Lad, Prabhakar <prabhakar.csengg at gmail.com>

this patch removes unnecessary header file inclusions and
fixes the typo's.

Signed-off-by: Lad, Prabhakar <prabhakar.csengg at gmail.com>
---
 drivers/media/platform/davinci/vpss.c |   11 +++--------
 1 files changed, 3 insertions(+), 8 deletions(-)

diff --git a/drivers/media/platform/davinci/vpss.c b/drivers/media/platform/davinci/vpss.c
index d36429d..8a2f01e 100644
--- a/drivers/media/platform/davinci/vpss.c
+++ b/drivers/media/platform/davinci/vpss.c
@@ -17,13 +17,8 @@
  *
  * common vpss system module platform driver for all video drivers.
  */
-#include <linux/kernel.h>
-#include <linux/sched.h>
-#include <linux/init.h>
 #include <linux/module.h>
 #include <linux/platform_device.h>
-#include <linux/spinlock.h>
-#include <linux/compiler.h>
 #include <linux/io.h>
 #include <linux/pm_runtime.h>
 
@@ -101,7 +96,7 @@ enum vpss_platform_type {
 
 /*
  * vpss operations. Depends on platform. Not all functions are available
- * on all platforms. The api, first check if a functio is available before
+ * on all platforms. The api, first check if a function is available before
  * invoking it. In the probe, the function ptrs are initialized based on
  * vpss name. vpss name can be "dm355_vpss", "dm644x_vpss" etc.
  */
@@ -116,7 +111,7 @@ struct vpss_hw_ops {
 	void (*set_sync_pol)(struct vpss_sync_pol);
 	/* set the PG_FRAME_SIZE register*/
 	void (*set_pg_frame_size)(struct vpss_pg_frame_size);
-	/* check and clear interrupt if occured */
+	/* check and clear interrupt if occurred */
 	int (*dma_complete_interrupt)(void);
 };
 
@@ -235,7 +230,7 @@ EXPORT_SYMBOL(vpss_clear_wbl_overflow);
 
 /*
  *  dm355_enable_clock - Enable VPSS Clock
- *  @clock_sel: CLock to be enabled/disabled
+ *  @clock_sel: Clock to be enabled/disabled
  *  @en: enable/disable flag
  *
  *  This is called to enable or disable a vpss clock
-- 
1.7.4.1



From vladimir.danushevsky at oracle.com  Mon Apr  8 08:34:28 2013
From: vladimir.danushevsky at oracle.com (Vladimir Danushevsky)
Date: Mon, 8 Apr 2013 08:34:28 -0400
Subject: [PATCH] Report double word access atomicity on LPAE enabled targets
 through AUXV
Message-ID: <C3FF039D-7DE3-4A99-8317-789094095D8B@oracle.com>

From: Vladimir Danushevsky <vladidan at oracle.com>

Hi All,

One of the indirect LPAE features in a single-copy atomicity of LDRD/STRD instructions. This information is useful for some dynamic code generating applications (e.g. JIT compilers) to produce a more efficient access mechanism to atomic/volatile operands. 

The feature is part of the design scheme therefore it's not related to the platform configuration i.e. whether CONFIG_ARM_LPAE is enabled or not.

The patch exposes that information through hwcap entry of an Auxiliary Vector.



Signed-off-by: Vladimir Danushevsky <vladidan at oracle.com>

---

--- linux-3.8.4_vanilla/arch/arm/include/uapi/asm/hwcap.h       2013-03-20 16:11:19.000000000 -0400

+++ linux-3.8.4/arch/arm/include/uapi/asm/hwcap.h       2013-03-26 16:32:18.266043699 -0400

@@ -25,6 +25,7 @@

 #define HWCAP_IDIVT    (1 << 18)

 #define HWCAP_VFPD32   (1 << 19)       /* set if VFP has 32 regs (not 16) */

 #define HWCAP_IDIV     (HWCAP_IDIVA | HWCAP_IDIVT)

+#define HWCAP_ATOMICD   (1 << 20)       /* ldrd/strd single-copy atomicity */



 #endif /* _UAPI__ASMARM_HWCAP_H */


--- linux-3.8.4_vanilla/arch/arm/kernel/setup.c 2013-03-20 16:11:19.000000000 -0400

+++ linux-3.8.4/arch/arm/kernel/setup.c 2013-04-03 15:42:31.580525201 -0400

@@ -487,6 +487,10 @@ static void __init setup_processor(void)

        elf_hwcap &= ~HWCAP_THUMB;

 #endif


+        /* check LPAE presence */ 

+        if (((read_cpuid_ext(CPUID_EXT_MMFR3) >> 28) & 0xf) > 0)

+          elf_hwcap |= HWCAP_ATOMICD;

+

        feat_v6_fixup();


        cacheid_init();

---

From sergei.shtylyov at cogentembedded.com  Mon Apr  8 08:35:50 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Mon, 08 Apr 2013 16:35:50 +0400
Subject: [PATCH 0/8] Reorganize R8A7779/Marzen USB code
In-Reply-To: <20130408023344.GK13103@verge.net.au>
References: <201304050251.44464.sergei.shtylyov@cogentembedded.com>
 <87vc81ka6k.wl%kuninori.morimoto.gx@renesas.com>
 <515EFE6D.4020006@cogentembedded.com> <515F51B6.5000302@cogentembedded.com>
 <20130408023344.GK13103@verge.net.au>
Message-ID: <5162B9A6.1030202@cogentembedded.com>

Hello.

On 08-04-2013 6:33, Simon Horman wrote:

>>>>>     Here's the set of 4 patches against the Simon Horman's
>>>>> 'renesas.git' repo,
>>>>> 'renesas-next-20130404v2' tag and the 2 Ether patches I've
>>>>> reposted yesterday.
>>>>> It was created to fix the shortcomings in the R8A7779/Marzen
>>>>> USB platform code
>>>>> and R8A7779 USB common PHY driver, and so spans both
>>>>> arch/arm/mach-shmobile/
>>>>> and drivers/usb/ subtrees (some patches have to touch both subtrees).
>>>>> The patches were conceived with the complete bisectability
>>>>> goal in mind.

>>>>> [1/8] ARM: shmobile:Marzen: move USB EHCI, OHCI, and PHY
>>>>> devices to R8A7779 code
>>>>> [2/8] ehci-platform: add init() method to platform data
>>>>> [3/8] ARM: shmobile: R8A7779: setup EHCI internal buffer
>>>>> [4/8] rcar-phy: remove EHCI internal buffer setup
>>>>> [5/8] rcar-phy: correct base address
>>>>> [6/8] rcar-phy: add platform data
>>>>> [7/8] ARM: shmobile: Marzen: pass platform data to USB PHY device
>>>>> [8/8] rcar-phy: handle platform data

>>>>>     I'm not sure thru which tree this patchset should be
>>>>> merged, however it turns
>>>>> out that it's too late now to push it thru Felipe Balbi's USB
>>>>> tree for 3.10, so
>>>>> maybe the patchset can be merged thru Simon's tree with
>>>>> Felipe's and Alan
>>>>> Stern's ACKs.

>>>> I guess you already got request about patch style from Simon.

>>>    It's not about style. I tried to keep the series copmpletely
>>> bisectable, and granting almost all requests about splitting the
>>> patches would have broken the bisection.

>>>> When you send v2 patch, could you please add "this patch is
>>>> tested on xxxx bard"
>>>> on each patch's comment area ?

>>>    I'm not sure it's worth doing v2, although in one place I can
>>> indeed readily split the patch. All patches were tested on the
>>> Marzen board, I forgot to mention that in the cover letter.
>>
>>     Well, there's gonna be version 2 now, mainly because Alan Stern
>> wasn't content with the patch #2.

> When you spin v2 could you note in the change log of each patch that
> includes both SoC and board of SoC and river code that the reason for this
> is to avoid breaking bisection?

    OK, but I wonder if you have read my cover letter before looking at the 
patches... I clearly stated that keeping the series bisectable was one of my 
main goals.

> Thanks.

WBR, Sergei



From linus.walleij at linaro.org  Mon Apr  8 08:52:42 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Mon, 8 Apr 2013 14:52:42 +0200
Subject: [GIT PULL] ux500 multiplatform tags
Message-ID: <CACRpkdbPZ5Nvv9+Bz9UE-U6-9QpqAr6UKGyYrTAxj78SJaknvg@mail.gmail.com>

Hi ARM SoC folks and Sam,

These are the two multiplatform tags for MFD and ARM SoC.

As agreed there is one tag for a number of MFD patches that
remove the <mach/*> dependencies from the DB8500 PRCMU
driver, then another tag dependent on the former that from that
point switches to multiplatform.

Below are two tags on git request-pull formar: the first one
is for *both* trees, MFD and ARM SoC, the second is only
for ARM SoC.

I have moved a few hunks and introduced a new patch in the
MFD series to make things compile and bisect properly.
Notably the patch "mfd: db8500-prcmu: drop unused includes"
is a new one, but the end result is textually equivalent to what
has already been posted so I consider this a reviewed patch
set and the split as plain mechanics.

Please pull your applicable branches!

Yours,
Linus Walleij


MFD tag:


The following changes since commit a937536b868b8369b98967929045f1df54234323:

  Linux 3.9-rc3 (2013-03-17 15:59:32 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-stericsson.git
tags/ux500-multiplatform-mfd

for you to fetch changes up to 55b175d7e6327939df82592ef279c534da323354:

  ARM: ux500: split out prcmu initialization (2013-04-08 13:58:15 +0200)

----------------------------------------------------------------
MFD portions of the ux500 multiplatform branch.
A second tag for the ARM SoC tree will build upon
this one. This mainly removes the header file
dependencies from the PRCMU driver in the MFD
subsystem, and moves the PM functions to the
machine.

----------------------------------------------------------------
Arnd Bergmann (1):
      ARM: ux500: split out prcmu initialization

Linus Walleij (4):
      mfd: prcmu: pass a base and size with the early initcall
      mfd: db8500-prcmu: get base address from resource
      ARM: ux500: move PM-related PRCMU functions to machine
      mfd: db8500-prcmu: drop unused includes

 arch/arm/mach-ux500/Makefile                   |   2 +-
 arch/arm/mach-ux500/board-mop500.c             |  58 -----
 arch/arm/mach-ux500/cpu-db8500.c               |   2 -
 arch/arm/mach-ux500/cpu.c                      |  21 +-
 arch/arm/mach-ux500/cpuidle.c                  |   3 +-
 arch/arm/mach-ux500/devices-db8500.c           |   2 +
 arch/arm/mach-ux500/include/mach/hardware.h    |   2 -
 arch/arm/mach-ux500/include/mach/irqs-db8500.h |  25 --
 arch/arm/mach-ux500/pm.c                       | 167 +++++++++++++
 drivers/mfd/db8500-prcmu.c                     | 316 ++++++++++++-------------
 drivers/mfd/dbx500-prcmu-regs.h                | 204 +++++++---------
 include/linux/mfd/db8500-prcmu.h               |  10 +-
 include/linux/mfd/dbx500-prcmu.h               |  38 +--
 include/linux/platform_data/arm-ux500-pm.h     |  21 ++
 14 files changed, 454 insertions(+), 417 deletions(-)
 create mode 100644 arch/arm/mach-ux500/pm.c
 create mode 100644 include/linux/platform_data/arm-ux500-pm.h


ARM SoC tag:

The following changes since commit a937536b868b8369b98967929045f1df54234323:

  Linux 3.9-rc3 (2013-03-17 15:59:32 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-stericsson.git
tags/ux500-multiplatform-asoc

for you to fetch changes up to f6f1bdac9d3006e246e82672322dcd7e7e0863fd:

  ARM: ux500: build hotplug.o for ARMv7-a (2013-04-08 13:59:54 +0200)

----------------------------------------------------------------
Ux500 multiplatform support.
This tag builds upon the MFD-specific base
tag "ux500-multiplatform-mfd". This removes
all <mach/*> dependencies and makes the ux500
fully multi-platform.

----------------------------------------------------------------
Arnd Bergmann (7):
      ARM: ux500: split out prcmu initialization
      ARM: ux500: move mach/msp.h to <linux/platform_data/*>
      staging: ste_rmi4: kill platform_data hack
      ARM: ux500: make irqs.h local to platform
      ARM: ux500: make remaining headers local
      ARM: ux500: move to multiplatform
      ARM: ux500: build hotplug.o for ARMv7-a

Linus Walleij (8):
      mfd: prcmu: pass a base and size with the early initcall
      mfd: db8500-prcmu: get base address from resource
      ARM: ux500: move PM-related PRCMU functions to machine
      mfd: db8500-prcmu: drop unused includes
      ARM: ux500: move debugmacro to debug includes
      ARM: ux500: make debug macro stand-alone
      clk: ux500: pass clock base adresses in init call
      ARM: ux500: get rid of <mach/[hardware|db8500-regs].h>

 arch/arm/Kconfig                                   |  15 -
 arch/arm/Kconfig.debug                             |   8 +
 arch/arm/include/debug/ux500.S                     |  48 ++++
 arch/arm/mach-ux500/Kconfig                        |  14 +
 arch/arm/mach-ux500/Makefile                       |   4 +-
 arch/arm/mach-ux500/board-mop500-audio.c           |   7 +-
 arch/arm/mach-ux500/board-mop500-pins.c            |   2 -
 arch/arm/mach-ux500/board-mop500-sdi.c             |   4 +-
 arch/arm/mach-ux500/board-mop500-u8500uib.c        |   9 +-
 arch/arm/mach-ux500/board-mop500-uib.c             |   1 -
 arch/arm/mach-ux500/board-mop500.c                 |  66 +----
 arch/arm/mach-ux500/board-mop500.h                 |   4 +-
 arch/arm/mach-ux500/cache-l2x0.c                   |   2 +-
 arch/arm/mach-ux500/cpu-db8500.c                   |  12 +-
 arch/arm/mach-ux500/cpu.c                          |  33 ++-
 arch/arm/mach-ux500/cpuidle.c                      |   5 +-
 .../mach-ux500/{include/mach => }/db8500-regs.h    |  28 ++
 arch/arm/mach-ux500/devices-common.c               |   3 +-
 arch/arm/mach-ux500/devices-db8500.c               |   8 +-
 arch/arm/mach-ux500/devices-db8500.h               |   3 +-
 arch/arm/mach-ux500/devices.c                      |   5 +-
 arch/arm/mach-ux500/{include/mach => }/devices.h   |   0
 arch/arm/mach-ux500/hotplug.c                      |   2 +-
 arch/arm/mach-ux500/id.c                           |   4 +-
 arch/arm/mach-ux500/include/mach/debug-macro.S     |  39 ---
 arch/arm/mach-ux500/include/mach/hardware.h        |  47 ---
 arch/arm/mach-ux500/include/mach/timex.h           |   6 -
 arch/arm/mach-ux500/include/mach/uncompress.h      |  57 ----
 .../{include/mach => }/irqs-board-mop500.h         |   0
 .../mach-ux500/{include/mach => }/irqs-db8500.h    |  25 --
 arch/arm/mach-ux500/{include/mach => }/irqs.h      |   6 +-
 arch/arm/mach-ux500/platsmp.c                      |   4 +-
 arch/arm/mach-ux500/pm.c                           | 167 +++++++++++
 arch/arm/mach-ux500/{include/mach => }/setup.h     |   0
 arch/arm/mach-ux500/timer.c                        |   6 +-
 arch/arm/mach-ux500/usb.c                          |   2 +-
 drivers/clk/ux500/clk-prcc.c                       |   1 -
 drivers/clk/ux500/u8500_clk.c                      | 142 ++++-----
 drivers/clocksource/clksrc-dbx500-prcmu.c          |   3 -
 drivers/crypto/ux500/cryp/cryp.c                   |   2 -
 drivers/crypto/ux500/cryp/cryp_core.c              |   1 -
 drivers/crypto/ux500/hash/hash_core.c              |   1 -
 drivers/mfd/db8500-prcmu.c                         | 316 ++++++++++-----------
 drivers/mfd/dbx500-prcmu-regs.h                    | 204 ++++++-------
 drivers/staging/ste_rmi4/Makefile                  |   1 -
 .../staging/ste_rmi4/board-mop500-u8500uib-rmi4.c  |  31 --
 drivers/staging/ste_rmi4/synaptics_i2c_rmi4.c      |  31 +-
 drivers/staging/ste_rmi4/synaptics_i2c_rmi4.h      |   1 -
 include/linux/mfd/db8500-prcmu.h                   |  10 +-
 include/linux/mfd/dbx500-prcmu.h                   |  38 +--
 include/linux/platform_data/arm-ux500-pm.h         |  21 ++
 .../linux/platform_data/asoc-ux500-msp.h           |   0
 include/linux/platform_data/clk-ux500.h            |   3 +-
 sound/soc/ux500/mop500_ab8500.c                    |   2 -
 sound/soc/ux500/ux500_msp_dai.c                    |   4 +-
 sound/soc/ux500/ux500_msp_i2s.c                    |   4 +-
 sound/soc/ux500/ux500_msp_i2s.h                    |   2 -
 57 files changed, 699 insertions(+), 765 deletions(-)
 create mode 100644 arch/arm/include/debug/ux500.S
 rename arch/arm/mach-ux500/{include/mach => }/db8500-regs.h (88%)
 rename arch/arm/mach-ux500/{include/mach => }/devices.h (100%)
 delete mode 100644 arch/arm/mach-ux500/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-ux500/include/mach/hardware.h
 delete mode 100644 arch/arm/mach-ux500/include/mach/timex.h
 delete mode 100644 arch/arm/mach-ux500/include/mach/uncompress.h
 rename arch/arm/mach-ux500/{include/mach => }/irqs-board-mop500.h (100%)
 rename arch/arm/mach-ux500/{include/mach => }/irqs-db8500.h (83%)
 rename arch/arm/mach-ux500/{include/mach => }/irqs.h (93%)
 create mode 100644 arch/arm/mach-ux500/pm.c
 rename arch/arm/mach-ux500/{include/mach => }/setup.h (100%)
 delete mode 100644 drivers/staging/ste_rmi4/board-mop500-u8500uib-rmi4.c
 create mode 100644 include/linux/platform_data/arm-ux500-pm.h
 rename arch/arm/mach-ux500/include/mach/msp.h =>
include/linux/platform_data/asoc-ux500-msp.h (100%)


From mchehab at redhat.com  Mon Apr  8 08:56:52 2013
From: mchehab at redhat.com (Mauro Carvalho Chehab)
Date: Mon, 8 Apr 2013 09:56:52 -0300
Subject: [PATCH v8 0/2] ARM: davinci: dm355: add support for vpbe display
In-Reply-To: <5162AE56.5090203@ti.com>
References: <1365413215-3632-1-git-send-email-prabhakar.csengg@gmail.com>
 <51629DA8.3040806@ti.com> <20130408075606.5a59d32c@redhat.com>
 <5162AE56.5090203@ti.com>
Message-ID: <20130408095652.33dcb0be@redhat.com>

Em Mon, 8 Apr 2013 17:17:34 +0530
Sekhar Nori <nsekhar at ti.com> escreveu:

> Hi Maruo,
> 
> On 4/8/2013 4:26 PM, Mauro Carvalho Chehab wrote:
> > Hi Sekhar,
> > 
> > Em Mon, 8 Apr 2013 16:06:24 +0530
> > Sekhar Nori <nsekhar at ti.com> escreveu:
> > 
> >> On 4/8/2013 2:56 PM, Prabhakar lad wrote:
> >>> From: Lad, Prabhakar <prabhakar.csengg at gmail.com>
> >>>
> >>> This patch series enables VPBE display driver on DM355.
> >>
> >> These (this and the DM365 one) patches look good to me. I need to get an
> >> immutable branch from Mauro where dependencies are queued and then I can
> >> generate a pull request for these for ARM SoC.
> > 
> > Are you mean a branch at the media development tree for you to sent
> > pull requests for me? If so, just use the "master" branch at the media
> 
> The pull request will be sent to my upstreams (ie the ARM SoC folks -
> Arnd and Olof). Since the platform data patches need driver patches to
> be applied first, I need a non-rebasing branch containing the driver
> stuff which I can use a dependency and apply platform patches on top.

Hmm... I generally wait for arch patches to be applied first, before
sending driver patches. If you're willing to do that, I suggest that
Arnd/Olof should put those patches on a separate topic branch, and
sending an upstream pull request for them after mine.

If the patches are trivial, maybe the better would be to put both
media and arm patches at the same tree, with the other maintainers'
ack.

> 
> > tree:
> > 	http://git.linuxtv.org/media_tree.git
> > 
> > The master branch there is never rebased. I'll likely start to have
> > topic branches on the next Kernel cycle, also at the same tree.
> 
> Ideally I will use the immutable branch which you will also use to send
> pull request to Linus so there are not unnecessary merge conflicts. When
> will those branches be ready?

I use a tree at Kernel.org for Linus submission. I only pull the patches
there when I'm about to ask him to pull, and after being sure that those
patches were already successfully merged at -next tree for some time.
So, you should not base your tree there, as it will have there only the 
patches that I already submitted.


Regards,
Mauro


From eric at eukrea.com  Mon Apr  8 08:57:33 2013
From: eric at eukrea.com (=?UTF-8?q?Eric=20B=C3=A9nard?=)
Date: Mon,  8 Apr 2013 14:57:33 +0200
Subject: [PATCH 3/3] ARM: mx28: add auart4 2 pins pinmux to imx28.dtsi
In-Reply-To: <1365425853-12457-1-git-send-email-eric@eukrea.com>
References: <1365425853-12457-1-git-send-email-eric@eukrea.com>
Message-ID: <1365425853-12457-3-git-send-email-eric@eukrea.com>

Add auart4 2 pins configuration on SSP3 pads

Signed-off-by: Eric B?nard <eric at eukrea.com>
---
 arch/arm/boot/dts/imx28.dtsi | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
index 5c45f29..25f2243 100644
--- a/arch/arm/boot/dts/imx28.dtsi
+++ b/arch/arm/boot/dts/imx28.dtsi
@@ -354,6 +354,17 @@
 					fsl,pull-up = <0>;
 				};
 
+				auart4_2pins_a: auart4 at 0 {
+					reg = <0>;
+					fsl,pinmux-ids = <
+						0x2181 /* MX28_PAD_SSP3_SCK__AUART4_TX */
+						0x2191 /* MX28_PAD_SSP3_MOSI__AUART4_RX */
+					>;
+					fsl,drive-strength = <0>;
+					fsl,voltage = <1>;
+					fsl,pull-up = <0>;
+				};
+
 				mac0_pins_a: mac0 at 0 {
 					reg = <0>;
 					fsl,pinmux-ids = <
-- 
1.7.11.7



From eric at eukrea.com  Mon Apr  8 08:57:31 2013
From: eric at eukrea.com (=?UTF-8?q?Eric=20B=C3=A9nard?=)
Date: Mon,  8 Apr 2013 14:57:31 +0200
Subject: [PATCH 1/3] ARM: mx28: add auart2 2 pins pinmux to imx28.dtsi
Message-ID: <1365425853-12457-1-git-send-email-eric@eukrea.com>

Add auart2 2 pins configuration on its main pads

Signed-off-by: Eric B?nard <eric at eukrea.com>
---
 arch/arm/boot/dts/imx28.dtsi | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
index 7ba4966..13799cf 100644
--- a/arch/arm/boot/dts/imx28.dtsi
+++ b/arch/arm/boot/dts/imx28.dtsi
@@ -308,6 +308,17 @@
 					fsl,pull-up = <0>;
 				};
 
+				auart2_2pins_b: auart2-2pins at 1 {
+					reg = <1>;
+					fsl,pinmux-ids = <
+						0x3080 /* MX28_PAD_AUART2_RX__AUART2_RX */
+						0x3090 /* MX28_PAD_AUART2_TX__AUART2_TX */
+					>;
+					fsl,drive-strength = <0>;
+					fsl,voltage = <1>;
+					fsl,pull-up = <0>;
+				};
+
 				auart3_pins_a: auart3 at 0 {
 					reg = <0>;
 					fsl,pinmux-ids = <
-- 
1.7.11.7



From eric at eukrea.com  Mon Apr  8 08:57:32 2013
From: eric at eukrea.com (=?UTF-8?q?Eric=20B=C3=A9nard?=)
Date: Mon,  8 Apr 2013 14:57:32 +0200
Subject: [PATCH 2/3] ARM: mx28: add auart3 2 pins pinmux to imx28.dtsi
In-Reply-To: <1365425853-12457-1-git-send-email-eric@eukrea.com>
References: <1365425853-12457-1-git-send-email-eric@eukrea.com>
Message-ID: <1365425853-12457-2-git-send-email-eric@eukrea.com>

Add auart3 2 pins configuration on its main pads

Signed-off-by: Eric B?nard <eric at eukrea.com>
---
 arch/arm/boot/dts/imx28.dtsi | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
index 13799cf..5c45f29 100644
--- a/arch/arm/boot/dts/imx28.dtsi
+++ b/arch/arm/boot/dts/imx28.dtsi
@@ -343,6 +343,17 @@
 					fsl,pull-up = <0>;
 				};
 
+				auart3_2pins_b: auart3-2pins at 1 {
+					reg = <1>;
+					fsl,pinmux-ids = <
+						0x30c0 /* MX28_PAD_AUART3_RX__AUART3_RX */
+						0x30d0 /* MX28_PAD_AUART3_TX__AUART3_TX */
+					>;
+					fsl,drive-strength = <0>;
+					fsl,voltage = <1>;
+					fsl,pull-up = <0>;
+				};
+
 				mac0_pins_a: mac0 at 0 {
 					reg = <0>;
 					fsl,pinmux-ids = <
-- 
1.7.11.7



From nsekhar at ti.com  Mon Apr  8 09:09:57 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Mon, 8 Apr 2013 18:39:57 +0530
Subject: [PATCH v3 3/3] ARM: davinci: da850: add EHRPWM & ECAP DT node
In-Reply-To: <518397C60809E147AF5323E0420B992E3EAA91B6@DBDE01.ent.ti.com>
References: <1364197789-16783-1-git-send-email-avinashphilip@ti.com>
 <1364197789-16783-4-git-send-email-avinashphilip@ti.com>
 <515A97DE.1080403@ti.com>
 <518397C60809E147AF5323E0420B992E3EAA91B6@DBDE01.ent.ti.com>
Message-ID: <5162C1A5.5060808@ti.com>


On 4/8/2013 2:39 PM, Philip, Avinash wrote:
> On Tue, Apr 02, 2013 at 14:03:34, Nori, Sekhar wrote:
>> On 3/25/2013 1:19 PM, Philip Avinash wrote:
>>> Add da850 EHRPWM & ECAP DT node.
>>> Also adds OF_DEV_AUXDATA for EHRPWM & ECAP driver to use EHRPWM & ECAP
>>> clock.
>>
>> This looks fine to me but I will wait for the bindings to get accepted
>> before taking this one.
> 
> Sekhar,
> 
> Binding document got accepted in PWM tree [1].
> Can you accept this patch?

Can you also add the pinmux definitions and resend just this patch?
Sorry I did not notice those were missing earlier.

Thanks,
Sekhar


From prabhakar.csengg at gmail.com  Mon Apr  8 09:12:39 2013
From: prabhakar.csengg at gmail.com (Prabhakar Lad)
Date: Mon, 8 Apr 2013 18:42:39 +0530
Subject: Query on pinctrl usage for DT nodes
In-Reply-To: <515C5C76.3080009@wwwdotorg.org>
References: <CA+V-a8uiPwsAD--OHFAE=i2ed+-wbXm4p2deZXr92+Zv6GDS1w@mail.gmail.com>
 <515C5C76.3080009@wwwdotorg.org>
Message-ID: <CA+V-a8t3wtP77DdeUoQHKMjAuWmV+ude+1J3UjJmMTqobgStjA@mail.gmail.com>

Hi Stephen,

Sorry for the delayed response, I was a holiday.

On Wed, Apr 3, 2013 at 10:14 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
> On 04/03/2013 03:16 AM, Prabhakar Lad wrote:
>> Hi Linus/Stephen,
>>
>> I am working adding  DT nodes for DA850.
>>
>> Following is the pin control snippet of da850.dtsi:-
>>
>>               pmx_core: pinmux at 1c14120 {
> ...
>>                         i2c0_pins: pinmux_i2c0_pins {
>>                                 pinctrl-single,bits = <
>>                                         /* I2C0_SDA,I2C0_SCL */
>>                                         0x10 0x00002200 0x0000ff00
>>                                 >;
>>                         };
>>                         mdio_pins: pinmux_mdio_pins {
>>                                 pinctrl-single,bits = <
>>                                         /* MDIO_CLK, MDIO_D */
>>                                         0x10 0x00000088 0x000000ff
>>                                 >;
>>                         };
>>                 }
>>
>> And following is the code snippet for dts:-
>>
>>               i2c0: i2c at 1c22000 {
>>                       status = "okay";
>>                       clock-frequency = <100000>;
>>                       pinctrl-names = "default";
>>                       pinctrl-0 = <&i2c0_pins>;
>>               };
>>               mdio: mdio at 1e24000 {
>>                       status = "okay";
>>                       bus_freq = <2200000>;
>>                       pinctrl-names = "default";
>
> I assume there's also the following there:
>
>                         pinctrl-0 = <&mdio_pins>;
>
Yes missed it :)

>>               };
>>
>> But while booting I see the following boot log:-
>> ...
>> cpuidle: using governor menu
>> TCP: cubic registered
>> NET: Registered protocol family 17
>> pinctrl-single 1c14120.pinmux: pin 1c14130 already requested by
>> davinci_mdio.0; cannot claim for i2c_davinci.1
>> pinctrl-single 1c14120.pinmux: pin-4 (i2c_davinci.1) status -22
>> pinctrl-single 1c14120.pinmux: could not request pin 4 on device pinctrl-single
>> console [netcon0] enabled
>> ....
>>
>> This is because the mdio and i2c are using same pin 0x10,
>
> How can two devices use the same pin? I mean physically, in hardware?
>
> Is this because pinctrl-single uses the register address as the pin
> number, whereas you have registers which configure multiple pins at

Yes you are correct, we have registers  which configure multiple pins at once.
For example for above Pin Multiplexing Control 4 Register (Pinmux4)
[1] page(250) : -

PINMUX4_31_28 --> SP1_SCS[2]/UART1_TXD/SATA_CP_POD/GP1[0] Control
PINMUX4_27_24 --> SPI1_SCS[3]/UART1_RXD/SATA_LED/GP1[1] Control
PINMUX4_23_20 --> SPI1_SCS[4]/UART2_TXD/I2C1_SDA/GP1[2] Control
PINMUX4_19_16 --> SPI1_SCS[5]/UART2_RXD/I2C1_SCL/GP1[3] Control
PINMUX4_15_12 --> SPI1_SCS[6]/I2C0_SDA/TM64P3_OUT12/GP1[4] Control
PINMUX4_11_8 --> SPI1_SCS[7]/I2C0_SCL/TM64P2_OUT12/GP1[5] Control
PINMUX4_7_4 --> SPI0_SCS[0]/TM64P1_OUT12/GP1[6]/MDIO_D/TM64P1_IN12 Control
PINMUX4_3_0 --> SPI0_SCS[1]/TM64P0_OUT12/GP1[7]/MDIO_CLK/TM64P0_IN12 Control

> once? If so, your hardware isn't something that can be represented by
> pinctrl-single.
>
What is the alternative for such case ? any pointer would be helpful.

[1] http://www.ti.com/general/docs/lit/getliterature.tsp?literatureNumber=spruh77a&fileType=pdf

Regards,
--Prabhakar


From s.nawrocki at samsung.com  Mon Apr  8 09:16:01 2013
From: s.nawrocki at samsung.com (Sylwester Nawrocki)
Date: Mon, 08 Apr 2013 15:16:01 +0200
Subject: [PATCH 1/3] clk: exynos: register audio subsystem clocks using
 common clock framework
In-Reply-To: <CAAgF-Bcpaef_uTWjw6or_uonFN9HU=xSEhxFFTyiA+mu+7iYpw@mail.gmail.com>
References: <1365143029-16936-1-git-send-email-padma.v@samsung.com>
 <515ED757.9070708@samsung.com>
 <CAAgF-Bcpaef_uTWjw6or_uonFN9HU=xSEhxFFTyiA+mu+7iYpw@mail.gmail.com>
Message-ID: <5162C311.4050706@samsung.com>

Hi,

On 04/06/2013 12:13 PM, Padma Venkat wrote:
> On Fri, Apr 5, 2013 at 7:23 PM, Sylwester Nawrocki
> <s.nawrocki at samsung.com> wrote:
>> On 04/05/2013 08:23 AM, Padmavathi Venna wrote:
>>> Audio subsystem is introduced in exynos platforms. This has seperate
>>> clock controller which can control i2s0 and pcm0 clocks. This patch
>>> registers the audio subsystem clocks with the common clock framework.
>>>
>>> Signed-off-by: Padmavathi Venna <padma.v at samsung.com>
>>> ---
>>>  drivers/clk/samsung/Makefile           |    1 +
>>>  drivers/clk/samsung/clk-exynos-audss.c |  139 ++++++++++++++++++++++++++++++++
>>>  2 files changed, 140 insertions(+), 0 deletions(-)
>>>  create mode 100644 drivers/clk/samsung/clk-exynos-audss.c
[...]
>>> diff --git a/drivers/clk/samsung/clk-exynos-audss.c b/drivers/clk/samsung/clk-exynos-audss.c
>>> new file mode 100644
>>> index 0000000..d7f9aa8
>>> --- /dev/null
>>> +++ b/drivers/clk/samsung/clk-exynos-audss.c
[...]
>>> +/* register exynos_audss clocks */
>>> +void __init exynos_audss_clk_init(struct device_node *np)
>>> +{
>>
>> Isn't it better to just do
>>
>>         if (np == NULL)
>>                 return;
>>
>> i.e. just skip the initialization altogether ? panic() seems
>> unreasonable here.
> 
> Ok. I will change this.
> 
>>
>>> +     if (np) {
>>> +             reg_base = of_iomap(np, 0);
>>> +             if (!reg_base)
>>> +                     panic("%s: failed to map registers\n", __func__);
>>> +     } else
>>> +             panic("%s: unable to determine soc\n", __func__);
>>> +
>>> +     clk_table = kzalloc(sizeof(struct clk *) * nr_clks, GFP_KERNEL);
>>> +     if (!clk_table)
>>> +             panic("could not allocate clock lookup table\n");
>>> +
>>> +     clk_data.clks = clk_table;
>>> +     clk_data.clk_num = nr_clks;
>>> +     of_clk_add_provider(np, of_clk_src_onecell_get, &clk_data);
>>> +
>>> +     clk_table[mout_audss] = clk_register_mux(NULL, "mout_audss",
>>> +                             mout_audss_p, ARRAY_SIZE(mout_audss_p), 0,
>>> +                             reg_base + ASS_CLK_SRC, 0, 1, 0, &lock);
>>> +     clk_register_clkdev(clk_table[mout_audss], "mout_audss", NULL);
>>> +
>>> +     clk_table[mout_i2s] = clk_register_mux(NULL, "mout_i2s", mout_i2s_p,
>>> +                             ARRAY_SIZE(mout_i2s_p), 0,
>>> +                             reg_base + ASS_CLK_SRC, 2, 2, 0, &lock);
>>> +     clk_register_clkdev(clk_table[mout_i2s], "mout_i2s", NULL);
>>> +
>>> +     clk_table[dout_srp] = clk_register_divider(NULL, "dout_srp",
>>> +                             "mout_audss", 0, reg_base + ASS_CLK_DIV, 0, 4,
>>> +                             0, &lock);
>>> +
>>> +     clk_table[dout_bus] = clk_register_divider(NULL, "dout_bus",
>>> +                             "dout_srp", 0, reg_base + ASS_CLK_DIV, 4, 4, 0,
>>> +                             &lock);
>>> +
>>> +     clk_table[dout_i2s] = clk_register_divider(NULL, "dout_i2s",
>>> +                             "mout_i2s", 0, reg_base + ASS_CLK_DIV, 8, 4, 0,
>>> +                             &lock);
>>> +
>>> +     clk_table[srp_clk] = clk_register_gate(NULL, "srp_clk", "dout_srp",
>>> +                             CLK_SET_RATE_PARENT, reg_base + ASS_CLK_GATE, 0,
>>> +                             0, &lock);
>>> +
>>> +     clk_table[i2s_bus] = clk_register_gate(NULL, "i2s_bus", "dout_bus",
>>> +                             CLK_SET_RATE_PARENT, reg_base + ASS_CLK_GATE, 2,
>>
>> Don't we need to handle also bit 3 of the ASS_CLK_GATE register ?
> 
> Bit 3 is handled below as sclk_i2s0.

Oops, sorry, my fault.

>> In some kernels I saw PCM special/PCM Bus and I2S special/I2S Bus bits
>> associated with same clocks. So there were 2-bit wide masks for each clock.
>>
>> Tomasz had an idea to add a flag to the clock framework that would be passed
>> to clk_register_gate() and would indicate that the sixth argument is a bitmask,
>> rather than a bit index.
> 
> For I2S there are separate clock instances and bits in the clock
> controller named as busclk[bit:2] and i2s_clk[bit:3].

Indeed.

> But PCM case there are two bits available[bit 4 and 5] but I think
> only one clock instance available(need to check
> clk controller diagram). But anyway having the bitmask in the
> clk_register_gate may be useful.

Yes, from the diagram there seems to be only one clock (SCLK_PCM0) but there 
are 2 in the clock gate register (PCM Special, PCM bus). I guess it's best to
describe those as 2 clocks, and handle them in the driver this way. Instead 
of merging presumably two separate physical clocks in a single clock object.

I suppose "PCM Special" (SCLK_PCMx) is only shown on the Audio Subsystem
diagrams, since it's mostly related to the sound data flow. And the PCM bus
is the PCM IP block bus clock, which is important for inter-working of the
PCM bus with rest of the system.

One option would be to provide a dummy clock for the second PCM clock, for 
systems where it is not available. So the driver always handles two clocks.

>> Perhaps we could just specify each bit of ASS_CLK_GATE as a separate clock.
>> Then the drivers would need to be modified. I'm not sure what's best approach.
>> And if it is really necessary to be enabling/disabling both special/bus clock
>> gate bits simultaneously. I'm adding Mike to Cc, so perhaps he could provide
>> us with some pointers.
>>
>>> +                             0, &lock);
>>> +
>>> +     clk_table[sclk_i2s0] = clk_register_gate(NULL, "sclk_i2s0", "dout_i2s",
>>> +                             CLK_SET_RATE_PARENT, reg_base + ASS_CLK_GATE, 3,
>>> +                             0, &lock);
>>> +#ifdef CONFIG_PM_SLEEP
>>> +     register_syscore_ops(&exynos_audss_clk_syscore_ops);
>>> +#endif
>>> +     pr_info("Exynos: Audss: clock setup completed\n");
>>> +}
>>> +CLK_OF_DECLARE(exynos_audss_clk, "samsung,exynos-audss-clock", exynos_audss_clk_init);
>>
>>
>> [1] http://www.spinics.net/lists/linux-kbuild/msg07616.html

Regards,
Sylwester


From linus.walleij at linaro.org  Mon Apr  8 09:19:44 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Mon, 8 Apr 2013 15:19:44 +0200
Subject: [GIT PULL] ux500 pinctrl patches
Message-ID: <CACRpkdbJ=T_-P0+gCuajMNCM9XGWQsa1EfzfOpV4Dwdf-wYRXA@mail.gmail.com>

Hi ARM SoC guys,

here are some ux500 pinctrl patches for the next merge cycle.
Please pull it in to some apropriate ux500 branch.

Yours,
Linus Walleij

The following changes since commit f6161aa153581da4a3867a2d1a7caf4be19b6ec9:

  Linux 3.9-rc2 (2013-03-10 16:54:19 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-stericsson.git
tags/ux500-pinctrl

for you to fetch changes up to 44df39f28a1a163b179f0374ff915b556bc56105:

  ARM: ux500: 8500: add ab8500-musb pinctrl support (2013-04-03 22:51:39 +0200)

----------------------------------------------------------------
ux500 pinctrl updates for the ARM SoC tree.

----------------------------------------------------------------
Fabio Baltieri (1):
      ARM: ux500: remove redundant DB8500_PIN_SLEEP definition

Julien Delacou (1):
      ARM: ux500: u8500: fix pinctrl IDLE state definition for SPI2

Lee Jones (1):
      ARM: ux500: Add Snowball pin configuration for user LED

Patrice Chotard (1):
      ARM: ux500: 8500: add ab8500-musb pinctrl support

 arch/arm/mach-ux500/board-mop500-pins.c | 34 +++++++++++++++++++++++++--------
 1 file changed, 26 insertions(+), 8 deletions(-)


From will.deacon at arm.com  Mon Apr  8 09:21:07 2013
From: will.deacon at arm.com (Will Deacon)
Date: Mon, 8 Apr 2013 14:21:07 +0100
Subject: [PATCH] Report double word access atomicity on LPAE enabled
 targets through AUXV
In-Reply-To: <C3FF039D-7DE3-4A99-8317-789094095D8B@oracle.com>
References: <C3FF039D-7DE3-4A99-8317-789094095D8B@oracle.com>
Message-ID: <20130408132107.GF17476@mudshark.cambridge.arm.com>

On Mon, Apr 08, 2013 at 01:34:28PM +0100, Vladimir Danushevsky wrote:
> From: Vladimir Danushevsky <vladidan at oracle.com>
> 
> Hi All,

Hello,

> One of the indirect LPAE features in a single-copy atomicity of LDRD/STRD instructions. This information is useful for some dynamic code generating applications (e.g. JIT compilers) to produce a more efficient access mechanism to atomic/volatile operands. 
> 
> The feature is part of the design scheme therefore it's not related to the platform configuration i.e. whether CONFIG_ARM_LPAE is enabled or not.
> 
> The patch exposes that information through hwcap entry of an Auxiliary Vector.

Hmm, your commit text and patch format are both completely mangled.
Furthermore, you've taken your patch against a -stable kernel, rather than
the latest mainline release, so it doesn't apply anymore anyway.

However, I see what you're trying to do, and I've recently made use of this
in our atomic64 implementation so that we avoid the exclusive instructions
for atomic64_{read,set}.

> --- linux-3.8.4_vanilla/arch/arm/kernel/setup.c 2013-03-20 16:11:19.000000000 -0400
> 
> +++ linux-3.8.4/arch/arm/kernel/setup.c 2013-04-03 15:42:31.580525201 -0400
> 
> @@ -487,6 +487,10 @@ static void __init setup_processor(void)
> 
>         elf_hwcap &= ~HWCAP_THUMB;
> 
>  #endif
> 
> 
> +        /* check LPAE presence */ 
> 
> +        if (((read_cpuid_ext(CPUID_EXT_MMFR3) >> 28) & 0xf) > 0)
> 
> +          elf_hwcap |= HWCAP_ATOMICD;

This is broken -- you're checking for supersection support (why?) rather
than checking the vmsa field in MMFR0.

How about something like the patch below instead?

Will

--->8

diff --git a/arch/arm/include/uapi/asm/hwcap.h b/arch/arm/include/uapi/asm/hwcap.h
index 3688fd1..ecf0c6f 100644
--- a/arch/arm/include/uapi/asm/hwcap.h
+++ b/arch/arm/include/uapi/asm/hwcap.h
@@ -25,6 +25,7 @@
 #define HWCAP_IDIVT    (1 << 18)
 #define HWCAP_VFPD32   (1 << 19)       /* set if VFP has 32 regs (not 16) */
 #define HWCAP_IDIV     (HWCAP_IDIVA | HWCAP_IDIVT)
+#define HWCAP_ATOMICD  (1 << 20)
 
 
 #endif /* _UAPI__ASMARM_HWCAP_H */
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index d343a6c..cae7b9e 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -355,7 +355,7 @@ void __init early_print(const char *str, ...)
 
 static void __init cpuid_init_hwcaps(void)
 {
-       unsigned int divide_instrs;
+       unsigned int divide_instrs, vmsa;
 
        if (cpu_architecture() < CPU_ARCH_ARMv7)
                return;
@@ -368,6 +368,11 @@ static void __init cpuid_init_hwcaps(void)
        case 1:
                elf_hwcap |= HWCAP_IDIVT;
        }
+
+       /* LPAE implies atomic ldrd/strd instructions */
+       vmsa = (read_cpuid_ext(CPUID_EXT_MMFR0) & 0xf) >> 0;
+       if (vmsa >= 5)
+               elf_hwcap |= HWCAP_ATOMICD;
 }
 
 static void __init feat_v6_fixup(void)
@@ -864,6 +869,7 @@ static const char *hwcap_str[] = {
        "vfpv4",
        "idiva",
        "idivt",
+       "atomicd",
        NULL
 };
 


From kishon at ti.com  Mon Apr  8 09:21:15 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Mon, 8 Apr 2013 18:51:15 +0530
Subject: [PATCH v5 1/6] drivers: phy: add generic PHY framework
In-Reply-To: <515CC123.4060402@wwwdotorg.org>
References: <1364993634-6378-1-git-send-email-kishon@ti.com>
 <1364993634-6378-2-git-send-email-kishon@ti.com>
 <515CC123.4060402@wwwdotorg.org>
Message-ID: <5162C44B.90501@ti.com>

Hi,

On Thursday 04 April 2013 05:24 AM, Stephen Warren wrote:
> On 04/03/2013 06:53 AM, Kishon Vijay Abraham I wrote:
>> The PHY framework provides a set of APIs for the PHY drivers to
>> create/destroy a PHY and APIs for the PHY users to obtain a reference to the
>> PHY with or without using phandle. To obtain a reference to the PHY without
>> using phandle, the platform specfic intialization code (say from board file)
>> should have already called phy_bind with the binding information. The binding
>> information consists of phy's device name, phy user device name and an index.
>> The index is used when the same phy user binds to mulitple phys.
>>
>> PHY drivers should create the PHY by passing phy_descriptor that has
>> describes the PHY (label, type etc..) and ops like init, exit, suspend, resume,
>> power_on, power_off.
>>
>> The documentation for the generic PHY framework is added in
>> Documentation/phy.txt and the documentation for the sysfs entry is added
>> in Documentation/ABI/testing/sysfs-class-phy and the documentation for
>> dt binding is can be found at
>> Documentation/devicetree/bindings/phy/phy-bindings.txt
>
>> diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
>
>> +extern struct phy *devm_phy_create(struct device *dev, const char *label,
>> +	struct device_node *of_node, int type, struct phy_ops *ops,
>> +	void *priv);
>
> Can't the function get of_node from dev->of_node?
>
> I wonder if we shouldn't split up the registration a bit though:
>
> A function which registers a PHY object itself. That's the function above.
>
> A function which registers a DT-based PHY provider.
>
> Then, the of_xlate op would be part of the PHY provider, not part of
> some random PHY that happens to exist on that node. So:

Yeah. Makes sense to me. By this we can avoid struct phy * to represent 
two different things (phy provider and phy instance).

Thanks
Kishon


From ohad at wizery.com  Mon Apr  8 09:46:23 2013
From: ohad at wizery.com (Ohad Ben-Cohen)
Date: Mon, 8 Apr 2013 16:46:23 +0300
Subject: [GIT PULL] remoteproc fixes for 3.9
Message-ID: <CAK=WgbY-M-ZrhAO5rhZazNNK4X706PCYPOS6Ag5pXSsNeM2OGA@mail.gmail.com>

The following changes since commit f6161aa153581da4a3867a2d1a7caf4be19b6ec9:

  Linux 3.9-rc2 (2013-03-10 16:54:19 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/ohad/remoteproc.git
tags/remoteproc-3.9-fixes

for you to fetch changes up to c7426bce5933d16b492a34e42ae77e26fceddff6:

  remoteproc: fix FW_CONFIG typo (2013-04-07 15:11:27 +0300)

----------------------------------------------------------------
4 small remoteproc fixes:
- Suman fixed an issue that crawled in with the move to the new
  idr_alloc interface in 3.9
- Dmitry fixed an STE specific memory leak
- Sjur fixed an error path in the core
- Rob fixed a Kconfig typo

----------------------------------------------------------------
Dmitry Tarnyagin (1):
      remoteproc/ste: fix memory leak on shutdown

Robert Tivy (1):
      remoteproc: fix FW_CONFIG typo

Sjur Br?ndeland (1):
      remoteproc: fix error path of handle_vdev

Suman Anna (1):
      remoteproc: fix the error check for idr_alloc

 drivers/remoteproc/Kconfig           | 2 +-
 drivers/remoteproc/remoteproc_core.c | 6 ++++--
 drivers/remoteproc/ste_modem_rproc.c | 7 ++++++-
 3 files changed, 11 insertions(+), 4 deletions(-)


From girishks2000 at gmail.com  Mon Apr  8 09:49:05 2013
From: girishks2000 at gmail.com (Girish KS)
Date: Mon, 8 Apr 2013 19:19:05 +0530
Subject: [PATCH V3 4/5] spi: s3c64xx: Added provision for dedicated cs pin
In-Reply-To: <20130408122056.GG9243@opensource.wolfsonmicro.com>
References: <1363157014-9615-1-git-send-email-ks.giri@samsung.com>
 <1363157014-9615-5-git-send-email-ks.giri@samsung.com>
 <20130401125744.GG18636@opensource.wolfsonmicro.com>
 <CAKrE-Kd+YAFmteDdh3odtV+YU1=OjoMuQV9usF4NmUse+TXhTg@mail.gmail.com>
 <20130408101530.GC9243@opensource.wolfsonmicro.com>
 <CAKrE-KevVramLc1n_9kcfHVb=RKT_kexQ8iUP-5+BL3wxpMPbQ@mail.gmail.com>
 <20130408122056.GG9243@opensource.wolfsonmicro.com>
Message-ID: <CAKrE-KcMy1qzzg1JXqBOvAJTdQM3rLU6dHoQRnyryLz4p0rpaA@mail.gmail.com>

On Mon, Apr 8, 2013 at 5:50 PM, Mark Brown
<broonie at opensource.wolfsonmicro.com> wrote:
> On Mon, Apr 08, 2013 at 05:15:26PM +0530, Girish KS wrote:
>> On Mon, Apr 8, 2013 at 3:45 PM, Mark Brown
>
>> > Two options here, one is to just assume nobody will use GPIO 0 and the
>> > other is to set the number appopriately during probe so that only probe
>> > needs to worry about the issue.
>>
>> In the second option if the gpio number is set in the probe, then we
>> are overwriting the
>> actual gpio number assigned in the platform data.
>> If I move the cs_gpio from the platform data to controller private
>> data then the dependency
>> on other platforms can be removed, but still the check (true or false)
>> before setting the gpio
>> line will remain. If agreed upon this i can go ahead and post the patch
>
> I think logic in probe should be fine, it just felt really cumbersome
> having this on every single use but doing it once on probe ought to be
> OK.

I will move the populating cs_gpio logic to probe. But the enable_cs
and disable_cs will have the
check before calling the gpio_set_value api (because it takes cs-line
as a parameter),


From plagnioj at jcrosoft.com  Mon Apr  8 10:07:55 2013
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Mon, 8 Apr 2013 16:07:55 +0200
Subject: [RFC v2 PATCH] at_hdmac: move to generic DMA binding
In-Reply-To: <20130408121930.GB6398@ludovic.desroches@atmel.com>
References: <1365403409-18381-1-git-send-email-ludovic.desroches@atmel.com>
 <20130408105515.GU20693@game.jcrosoft.org>
 <20130408121930.GB6398@ludovic.desroches@atmel.com>
Message-ID: <20130408140755.GZ20693@game.jcrosoft.org>

On 14:19 Mon 08 Apr     , Ludovic Desroches wrote:
> On Mon, Apr 08, 2013 at 12:55:15PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > On 08:43 Mon 08 Apr     , ludovic.desroches at atmel.com wrote:
> > > From: Ludovic Desroches <ludovic.desroches at atmel.com>
> > > 
> > > Signed-off-by: Ludovic Desroches <ludovic.desroches at atmel.com>
> > > ---
> > > 
> > > Hi,
> > > 
> > > Here is a second try to move at_hdmac to generic DMA binding. I have updated
> > > bindings according to Arnd comments ie I have removed chunk transfer size.
> > > 
> > > I have added the implementation but I am not very happy with the translation
> > > function. I have tried to not break old stuff: slave ask for a channel giving
> > > an atslave structure (passed through pdata) as a parameter for the filter
> > > function which saves this structure into chan->private. Then chan->private
> > > contains the configuration for the channel CFG register which is done when
> > > calling device_alloc_chan_resources.
> > > 
> > > If I allocate the atslave structure in the xlate function, where should be the
> > > right place to deallocate it? For the moment, I choose to add the atslave
> > > structure to the at_dma_chan structure but I am not happy with writing the
> > > channel configuration register into the xlate function. I would like to keep
> > > the same path as before.
> > so allow with devm_
> 
> To my mind it's channel related and not controller related. If the channel is
> released, will the deallocation be done automatically?
when the device is free yes

so free on slave device it's ok

Best Regards,
J.
> 
> > > 
> > > Regards
> > > 
> > > Ludovic
> > > 
> > > 
> > >  .../devicetree/bindings/dma/atmel-dma.txt          | 27 +++++++-
> > >  arch/arm/boot/dts/sama5d3.dtsi                     |  2 +
> > >  drivers/dma/at_hdmac.c                             | 71 ++++++++++++++++++++--
> > >  drivers/dma/at_hdmac_regs.h                        |  7 +++
> > >  4 files changed, 99 insertions(+), 8 deletions(-)
> > > 
> > > diff --git a/Documentation/devicetree/bindings/dma/atmel-dma.txt b/Documentation/devicetree/bindings/dma/atmel-dma.txt
> > > index 3c046ee..2d6f0f3 100644
> > > --- a/Documentation/devicetree/bindings/dma/atmel-dma.txt
> > > +++ b/Documentation/devicetree/bindings/dma/atmel-dma.txt
> > > @@ -4,11 +4,34 @@ Required properties:
> > >  - compatible: Should be "atmel,<chip>-dma"
> > >  - reg: Should contain DMA registers location and length
> > >  - interrupts: Should contain DMA interrupt
> > > +- #dma-cells: Must be <2>
> > >  
> > > -Examples:
> > > +Example:
> > >  
> > > -dma at ffffec00 {
> > > +dma0: dma at ffffec00 {
> > >  	compatible = "atmel,at91sam9g45-dma";
> > >  	reg = <0xffffec00 0x200>;
> > >  	interrupts = <21>;
> > > +	#dma-cells = <2>;
> > > +};
> > > +
> > > +DMA clients connected to the Atmel DMA controller must use the format
> > > +described in the dma.txt file, using a three-cell specifier for each channel.
> > > +The three cells in order are:
> > > +
> > > +1. A phandle pointing to the DMA controller
> > > +2. The memory interface (16 most significant bits), the peripheral interface
> > > +(16 less significant bits)
> > > +3. The peripheral identifier (can be different for tx and rx)
> > > +
> > > +Example:
> > > +
> > > +i2c0 at i2c@f8010000 {
> > > +	compatible = "atmel,at91sam9x5-i2c";
> > > +	reg = <0xf8010000 0x100>;
> > > +	interrupts = <9 4 6>;
> > > +	dmas = <&dma0 1 7>,
> > > +	       <&dma0 1 8>;
> > > +	dma-names = "tx", "rx"
> > >  };
> > > diff --git a/arch/arm/boot/dts/sama5d3.dtsi b/arch/arm/boot/dts/sama5d3.dtsi
> > > index 39b0458..9232143 100644
> > > --- a/arch/arm/boot/dts/sama5d3.dtsi
> > > +++ b/arch/arm/boot/dts/sama5d3.dtsi
> > > @@ -349,6 +349,7 @@
> > >  				reg = <0xffffe600 0x200>;
> > >  				interrupts = <30 4 0>;
> > >  				#dma-cells = <1>;
> > > +				#dma-cells = <2>;
> > ??
> > 
> > 2 dma-cells?
> 
> Yes 2 dma-cells, mistake in the patch, the work is still in progress.
> 
> > >  			};
> > >  
> > >  			dma1: dma-controller at ffffe800 {
> > > @@ -356,6 +357,7 @@
> > >  				reg = <0xffffe800 0x200>;
> > >  				interrupts = <31 4 0>;
> > >  				#dma-cells = <1>;
> > > +				#dma-cells = <2>;
> > ditto
> > >  			};
> > >  
> > >  			ramc0: ramc at ffffea00 {
> > > diff --git a/drivers/dma/at_hdmac.c b/drivers/dma/at_hdmac.c
> > > index 8415467..ec7f561 100644
> > > --- a/drivers/dma/at_hdmac.c
> > > +++ b/drivers/dma/at_hdmac.c
> > > @@ -24,6 +24,7 @@
> > >  #include <linux/slab.h>
> > >  #include <linux/of.h>
> > >  #include <linux/of_device.h>
> > > +#include <linux/of_dma.h>
> > >  
> > >  #include "at_hdmac_regs.h"
> > >  #include "dmaengine.h"
> > > @@ -676,7 +677,7 @@ atc_prep_slave_sg(struct dma_chan *chan, struct scatterlist *sgl,
> > >  		ctrlb |=  ATC_DST_ADDR_MODE_FIXED
> > >  			| ATC_SRC_ADDR_MODE_INCR
> > >  			| ATC_FC_MEM2PER
> > > -			| ATC_SIF(AT_DMA_MEM_IF) | ATC_DIF(AT_DMA_PER_IF);
> > > +			| ATC_SIF(atchan->mem_if) | ATC_DIF(atchan->per_if);
> > >  		reg = sconfig->dst_addr;
> > >  		for_each_sg(sgl, sg, sg_len, i) {
> > >  			struct at_desc	*desc;
> > > @@ -715,7 +716,7 @@ atc_prep_slave_sg(struct dma_chan *chan, struct scatterlist *sgl,
> > >  		ctrlb |=  ATC_DST_ADDR_MODE_INCR
> > >  			| ATC_SRC_ADDR_MODE_FIXED
> > >  			| ATC_FC_PER2MEM
> > > -			| ATC_SIF(AT_DMA_PER_IF) | ATC_DIF(AT_DMA_MEM_IF);
> > > +			| ATC_SIF(atchan->per_if) | ATC_DIF(atchan->mem_if);
> > >  
> > >  		reg = sconfig->src_addr;
> > >  		for_each_sg(sgl, sg, sg_len, i) {
> > > @@ -821,8 +822,8 @@ atc_dma_cyclic_fill_desc(struct dma_chan *chan, struct at_desc *desc,
> > >  		desc->lli.ctrlb = ATC_DST_ADDR_MODE_FIXED
> > >  				| ATC_SRC_ADDR_MODE_INCR
> > >  				| ATC_FC_MEM2PER
> > > -				| ATC_SIF(AT_DMA_MEM_IF)
> > > -				| ATC_DIF(AT_DMA_PER_IF);
> > > +				| ATC_SIF(atchan->mem_if)
> > > +				| ATC_DIF(atchan->per_if);
> > >  		break;
> > >  
> > >  	case DMA_DEV_TO_MEM:
> > > @@ -832,8 +833,8 @@ atc_dma_cyclic_fill_desc(struct dma_chan *chan, struct at_desc *desc,
> > >  		desc->lli.ctrlb = ATC_DST_ADDR_MODE_INCR
> > >  				| ATC_SRC_ADDR_MODE_FIXED
> > >  				| ATC_FC_PER2MEM
> > > -				| ATC_SIF(AT_DMA_PER_IF)
> > > -				| ATC_DIF(AT_DMA_MEM_IF);
> > > +				| ATC_SIF(atchan->per_if)
> > > +				| ATC_DIF(atchan->mem_if);
> > >  		break;
> > >  
> > >  	default:
> > > @@ -1189,6 +1190,55 @@ static void atc_free_chan_resources(struct dma_chan *chan)
> > >  	dev_vdbg(chan2dev(chan), "free_chan_resources: done\n");
> > >  }
> > >  
> > > +static bool at_dma_filter(struct dma_chan *chan, void *dma_dev)
> > > +{
> > > +	if (dma_dev == chan->device->dev)
> > > +		return true;
> > > +	else
> > > +		return false;
> > > +}
> > > +
> > > +static struct dma_chan *at_dma_xlate(struct of_phandle_args *dma_spec,
> > > +				     struct of_dma *of_dma)
> > > +{
> > > +	struct dma_chan *chan;
> > > +	struct at_dma_chan *atchan;
> > > +	struct at_dma_slave *atslave;
> > > +	dma_cap_mask_t mask;
> > > +	unsigned int per_id;
> > > +	struct platform_device *dmac_pdev;
> > > +
> > > +	if (dma_spec->args_count != 2)
> > > +		return NULL;
> > > +
> > > +	dmac_pdev = of_find_device_by_node(dma_spec->np);
> > > +
> > > +	dma_cap_zero(mask);
> > > +	dma_cap_set(DMA_SLAVE, mask);
> > > +
> > > +	chan = dma_request_channel(mask, at_dma_filter, &dmac_pdev->dev);
> > > +	if (!chan)
> > > +		return NULL;
> > > +
> > > +	atchan = to_at_dma_chan(chan);
> > > +	atchan->per_if = dma_spec->args[0] & 0xff;
> > > +	atchan->mem_if = (dma_spec->args[0] >> 16) & 0xff;
> > > +
> > > +	atslave = &atchan->atslave;
> > > +	/*
> > > +	 * We can fill both SRC_PER and DST_PER, one of these fields will be
> > > +	 * ignored depending on DMA transfer direction.
> > > +	 */
> > > +	per_id = dma_spec->args[1];
> > > +	atslave->cfg = ATC_FIFOCFG_HALFFIFO | ATC_DST_H2SEL_HW
> > > +		      | ATC_SRC_H2SEL_HW | ATC_DST_PER(per_id)
> > > +		      | ATC_SRC_PER(per_id);
> > > +	atslave->dma_dev = &dmac_pdev->dev;
> > > +	chan->private = atslave;
> > > +	channel_writel(atchan, CFG, atslave->cfg);
> > > +
> > > +	return chan;
> > > +}
> > >  
> > >  /*--  Module Management  -----------------------------------------------*/
> > >  
> > > @@ -1389,6 +1439,15 @@ static int __init at_dma_probe(struct platform_device *pdev)
> > >  
> > >  	dma_async_device_register(&atdma->dma_common);
> > >  
> > > +	if (pdev->dev.of_node) {
> > more simple return if NULL
> > > +		printk("=== of_dma_controller_register ===\n");
> > drop this
> 
> of course, I'll drop it for the submission
> 
> > > +		err = of_dma_controller_register(pdev->dev.of_node,
> > > +						 at_dma_xlate, atdma);
> > > +		if (err && err != -ENODEV)
> > > +			dev_err(&pdev->dev,
> > > +				"could not register of_dma_controller\n");
> > 		if err you need to return err
> 
> ok
> 
> > > +	}
> > > +
> > >  	return 0;
> > >  
> > >  err_pool_create:
> > > diff --git a/drivers/dma/at_hdmac_regs.h b/drivers/dma/at_hdmac_regs.h
> > > index 0eb3c13..e3d2f12 100644
> > > --- a/drivers/dma/at_hdmac_regs.h
> > > +++ b/drivers/dma/at_hdmac_regs.h
> > > @@ -220,6 +220,8 @@ enum atc_status {
> > >   * @device: parent device
> > >   * @ch_regs: memory mapped register base
> > >   * @mask: channel index in a mask
> > > + * @per_if: peripheral interface
> > > + * @mem_if: memory interface
> > >   * @status: transmit status information from irq/prep* functions
> > >   *                to tasklet (use atomic operations)
> > >   * @tasklet: bottom half to finish transaction work
> > > @@ -227,6 +229,8 @@ enum atc_status {
> > >   * @save_dscr: for cyclic operations, preserve next descriptor address in
> > >   *             the cyclic list on suspend/resume cycle
> > >   * @dma_sconfig: configuration for slave transfers, passed via DMA_SLAVE_CONFIG
> > > + * @atslave: hardware configuration for slave transfers which is not passed via
> > > + * DMA_SLAVE_CONFIG
> > >   * @lock: serializes enqueue/dequeue operations to descriptors lists
> > >   * @active_list: list of descriptors dmaengine is being running on
> > >   * @queue: list of descriptors ready to be submitted to engine
> > > @@ -238,11 +242,14 @@ struct at_dma_chan {
> > >  	struct at_dma		*device;
> > >  	void __iomem		*ch_regs;
> > >  	u8			mask;
> > > +	u8			per_if;
> > > +	u8			mem_if;
> > >  	unsigned long		status;
> > >  	struct tasklet_struct	tasklet;
> > >  	u32			save_cfg;
> > >  	u32			save_dscr;
> > >  	struct dma_slave_config dma_sconfig;
> > > +	struct at_dma_slave	atslave;
> > >  
> > >  	spinlock_t		lock;
> > >  
> > > -- 
> > > 1.7.11.3
> > > 


From arnd at arndb.de  Mon Apr  8 10:17:31 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 8 Apr 2013 16:17:31 +0200
Subject: [PATCH v4 0/5] Device Bus support for Marvell EBU SoC
In-Reply-To: <1365419194-20871-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1365419194-20871-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <201304081617.31644.arnd@arndb.de>

On Monday 08 April 2013, Ezequiel Garcia wrote:
>   * Rename devbus,dev-width to devbus,bus-width and changed the
>     parameter value from bytes to bits: <8>, <16>, ...
>     Suggested by Arnd Bergmann.
> 
>   * As suggested by Jason Gunthorpe and agreed by Arnd Bergmann.
>     Reworked the whole devbus child chip-select device tree design.
>     Now there's a separate devbus at addr DT node for each controller
>     chip select. The impact of this is:
>       1. Timing parameters now go into the parent node.
>       2. There can only be one child per devbus node.
> 
>   * Remove unneeded bank-width parameter read.
> 

Whole series:

Acked-by: Arnd Bergmann <arnd at arndb.de>

It may be nicer to use #address-cells=<2> for devbus device nodes now that
each of them has only a 32 bit address space, but the current code is correct
as well using a 64 bit notation.

	Arnd


From pebolle at tiscali.nl  Mon Apr  8 10:23:59 2013
From: pebolle at tiscali.nl (Paul Bolle)
Date: Mon, 08 Apr 2013 16:23:59 +0200
Subject: [PATCH] ARM: imx: remove configs ARCH_MX5 and ARCH_MX51
Message-ID: <1365431039.1830.102.camel@x61.thuisdomein>

The Kconfig symbols ARCH_MX5 and ARCH_MX51 are unused since v3.3. They
can safely be removed.

Signed-off-by: Paul Bolle <pebolle at tiscali.nl>
---
Tested with "git grep" only.

 arch/arm/mach-imx/Kconfig | 10 ----------
 1 file changed, 10 deletions(-)

diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index 6d9ae09..cbd6942 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -92,12 +92,6 @@ config ARCH_MX25
 config MACH_MX27
 	bool
 
-config ARCH_MX5
-	bool
-
-config ARCH_MX51
-	bool
-
 config ARCH_MX53
 	bool
 
@@ -155,7 +149,6 @@ config SOC_IMX35
 config SOC_IMX5
 	bool
 	select ARCH_HAS_CPUFREQ
-	select ARCH_MX5
 	select ARCH_MXC_IOMUX_V3
 	select COMMON_CLK
 	select CPU_V7
@@ -163,8 +156,6 @@ config SOC_IMX5
 
 config	SOC_IMX51
 	bool
-	select ARCH_MX5
-	select ARCH_MX51
 	select PINCTRL
 	select PINCTRL_IMX51
 	select SOC_IMX5
@@ -787,7 +778,6 @@ comment "Device tree only"
 
 config	SOC_IMX53
 	bool "i.MX53 support"
-	select ARCH_MX5
 	select ARCH_MX53
 	select HAVE_CAN_FLEXCAN if CAN
 	select IMX_HAVE_PLATFORM_IMX2_WDT
-- 
1.7.11.7



From linux at arm.linux.org.uk  Mon Apr  8 10:24:06 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Mon, 8 Apr 2013 15:24:06 +0100
Subject: [PATCH] Report double word access atomicity on LPAE enabled
 targets through AUXV
In-Reply-To: <C3FF039D-7DE3-4A99-8317-789094095D8B@oracle.com>
References: <C3FF039D-7DE3-4A99-8317-789094095D8B@oracle.com>
Message-ID: <20130408142406.GL17995@n2100.arm.linux.org.uk>

On Mon, Apr 08, 2013 at 08:34:28AM -0400, Vladimir Danushevsky wrote:
> From: Vladimir Danushevsky <vladidan at oracle.com>

Please don't obfuscate your email address like that - git won't parse it.

> Hi All,

We don't include such salutations in the commit message.

> One of the indirect LPAE features in a single-copy atomicity of LDRD/STRD
> instructions. This information is useful for some dynamic code generating
> applications (e.g. JIT compilers) to produce a more efficient access
> mechanism to atomic/volatile operands.
> 
> The feature is part of the design scheme therefore it's not related to the
> platform configuration i.e. whether CONFIG_ARM_LPAE is enabled or not.
> 
> The patch exposes that information through hwcap entry of an Auxiliary
> Vector.

I think we're heading towards running out of hwcap bits to represent all
these different features.  Not there yet, but after this we only have 11
spare bits.

Maybe we need to switch to a more x86-centric method where we report this
stuff in /proc/cpuinfo, and userspace parses this information out.  If
glibc already has code in there for x86, maybe we can reuse that?

> Signed-off-by: Vladimir Danushevsky <vladidan at oracle.com>

Again, don't obfuscate.

> ---

diffstat?

> 
> --- linux-3.8.4_vanilla/arch/arm/include/uapi/asm/hwcap.h       2013-03-20 16:11:19.000000000 -0400
> 
> +++ linux-3.8.4/arch/arm/include/uapi/asm/hwcap.h       2013-03-26 16:32:18.266043699 -0400

This double-line spacing makes this patch impossible to apply.

> +        /* check LPAE presence */ 

If it's worth a comment, it's worth making it a good comment.
> 
> +        if (((read_cpuid_ext(CPUID_EXT_MMFR3) >> 28) & 0xf) > 0)
> 
> +          elf_hwcap |= HWCAP_ATOMICD;

We use tabs for indentation, not two spaces.  Also, on the face of it
ATOMICD isn't obvious what it means.  Maybe HWCAP_LDRDSTRD would be
better - it's only one character longer and truely reflects what you're
trying to report - the presence of these two instructions.


From Andrew.Murray at arm.com  Mon Apr  8 10:33:20 2013
From: Andrew.Murray at arm.com (Andrew Murray)
Date: Mon, 8 Apr 2013 15:33:20 +0100
Subject: [PATCH v3] of/pci: Provide support for parsing PCI DT ranges property
Message-ID: <20130408143320.GA24277@arm.com>

This patch factors out common implementation patterns to reduce overall kernel
code and provide a means for host bridge drivers to directly obtain struct
resources from the DT's ranges property without relying on architecture specific
DT handling. This will make it easier to write archiecture independent host bridge
drivers and mitigate against further duplication of DT parsing code.

This patch can be used in the following way:

	struct of_pci_range_parser parser;
	struct of_pci_range range;

	if (of_pci_range_parser(&parser, np))
		; //no ranges property

	for_each_of_pci_range(&parser, &range) {

		/*
			directly access properties of the address range, e.g.:
			range.pci_space, range.pci_addr, range.cpu_addr,
			range.size, range.flags

			alternatively obtain a struct resource, e.g.:
			struct resource res;
			of_pci_range_to_resource(&range, np, &res);
		*/
	}

Additionally the implementation takes care of adjacent ranges and merges them
into a single range (as was the case with powerpc and microblaze).

The modifications to microblaze, mips and powerpc have not been tested.

Signed-off-by: Andrew Murray <Andrew.Murray at arm.com>
Signed-off-by: Liviu Dudau <Liviu.Dudau at arm.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
Compared to the v3 sent by Andrew Murray, the following changes have
been made:

 * Unify and move duplicate pci_process_bridge_OF_ranges functions to
   drivers/of/of_pci.c as suggested by Rob Herring

 * Fix potential build errors with Microblaze/MIPS

Compared to "[PATCH v5 01/17] of/pci: Provide support for parsing PCI DT
ranges property", the following changes have been made:

 * Correct use of IORESOURCE_* as suggested by Russell King

 * Improved interface and naming as suggested by Thierry Reding

Compared to the v2 sent by Andrew Murray, Thomas Petazzoni did:

 * Add a memset() on the struct of_pci_range_iter when starting the
   for loop in for_each_pci_range(). Otherwise, with an uninitialized
   of_pci_range_iter, of_pci_process_ranges() may crash.

 * Add parenthesis around 'res', 'np' and 'iter' in the
   for_each_of_pci_range macro definitions. Otherwise, passing
   something like &foobar as 'res' didn't work.

 * Rebased on top of 3.9-rc2, which required fixing a few conflicts in
   the Microblaze code.

v2:
  This follows on from suggestions made by Grant Likely
  (marc.info/?l=linux-kernel&m=136079602806328)
---
 arch/microblaze/include/asm/pci-bridge.h |    5 +-
 arch/microblaze/pci/pci-common.c         |  192 ------------------------------
 arch/mips/pci/pci.c                      |   50 +++------
 arch/powerpc/include/asm/pci-bridge.h    |    5 +-
 arch/powerpc/kernel/pci-common.c         |  192 ------------------------------
 drivers/of/address.c                     |   63 ++++++++++
 drivers/of/of_pci.c                      |  168 ++++++++++++++++++++++++++
 include/linux/of_address.h               |   42 +++++++
 include/linux/of_pci.h                   |    3 +
 9 files changed, 294 insertions(+), 426 deletions(-)

diff --git a/arch/microblaze/include/asm/pci-bridge.h b/arch/microblaze/include/asm/pci-bridge.h
index cb5d397..5783cd6 100644
--- a/arch/microblaze/include/asm/pci-bridge.h
+++ b/arch/microblaze/include/asm/pci-bridge.h
@@ -10,6 +10,7 @@
 #include <linux/pci.h>
 #include <linux/list.h>
 #include <linux/ioport.h>
+#include <linux/of_pci.h>
 
 struct device_node;
 
@@ -132,10 +133,6 @@ extern void setup_indirect_pci(struct pci_controller *hose,
 extern struct pci_controller *pci_find_hose_for_OF_device(
 			struct device_node *node);
 
-/* Fill up host controller resources from the OF node */
-extern void pci_process_bridge_OF_ranges(struct pci_controller *hose,
-			struct device_node *dev, int primary);
-
 /* Allocate & free a PCI host bridge structure */
 extern struct pci_controller *pcibios_alloc_controller(struct device_node *dev);
 extern void pcibios_free_controller(struct pci_controller *phb);
diff --git a/arch/microblaze/pci/pci-common.c b/arch/microblaze/pci/pci-common.c
index 9ea521e..2735ad9 100644
--- a/arch/microblaze/pci/pci-common.c
+++ b/arch/microblaze/pci/pci-common.c
@@ -622,198 +622,6 @@ void pci_resource_to_user(const struct pci_dev *dev, int bar,
 	*end = rsrc->end - offset;
 }
 
-/**
- * pci_process_bridge_OF_ranges - Parse PCI bridge resources from device tree
- * @hose: newly allocated pci_controller to be setup
- * @dev: device node of the host bridge
- * @primary: set if primary bus (32 bits only, soon to be deprecated)
- *
- * This function will parse the "ranges" property of a PCI host bridge device
- * node and setup the resource mapping of a pci controller based on its
- * content.
- *
- * Life would be boring if it wasn't for a few issues that we have to deal
- * with here:
- *
- *   - We can only cope with one IO space range and up to 3 Memory space
- *     ranges. However, some machines (thanks Apple !) tend to split their
- *     space into lots of small contiguous ranges. So we have to coalesce.
- *
- *   - We can only cope with all memory ranges having the same offset
- *     between CPU addresses and PCI addresses. Unfortunately, some bridges
- *     are setup for a large 1:1 mapping along with a small "window" which
- *     maps PCI address 0 to some arbitrary high address of the CPU space in
- *     order to give access to the ISA memory hole.
- *     The way out of here that I've chosen for now is to always set the
- *     offset based on the first resource found, then override it if we
- *     have a different offset and the previous was set by an ISA hole.
- *
- *   - Some busses have IO space not starting at 0, which causes trouble with
- *     the way we do our IO resource renumbering. The code somewhat deals with
- *     it for 64 bits but I would expect problems on 32 bits.
- *
- *   - Some 32 bits platforms such as 4xx can have physical space larger than
- *     32 bits so we need to use 64 bits values for the parsing
- */
-void pci_process_bridge_OF_ranges(struct pci_controller *hose,
-				  struct device_node *dev, int primary)
-{
-	const u32 *ranges;
-	int rlen;
-	int pna = of_n_addr_cells(dev);
-	int np = pna + 5;
-	int memno = 0, isa_hole = -1;
-	u32 pci_space;
-	unsigned long long pci_addr, cpu_addr, pci_next, cpu_next, size;
-	unsigned long long isa_mb = 0;
-	struct resource *res;
-
-	pr_info("PCI host bridge %s %s ranges:\n",
-	       dev->full_name, primary ? "(primary)" : "");
-
-	/* Get ranges property */
-	ranges = of_get_property(dev, "ranges", &rlen);
-	if (ranges == NULL)
-		return;
-
-	/* Parse it */
-	pr_debug("Parsing ranges property...\n");
-	while ((rlen -= np * 4) >= 0) {
-		/* Read next ranges element */
-		pci_space = ranges[0];
-		pci_addr = of_read_number(ranges + 1, 2);
-		cpu_addr = of_translate_address(dev, ranges + 3);
-		size = of_read_number(ranges + pna + 3, 2);
-
-		pr_debug("pci_space: 0x%08x pci_addr:0x%016llx ",
-				pci_space, pci_addr);
-		pr_debug("cpu_addr:0x%016llx size:0x%016llx\n",
-					cpu_addr, size);
-
-		ranges += np;
-
-		/* If we failed translation or got a zero-sized region
-		 * (some FW try to feed us with non sensical zero sized regions
-		 * such as power3 which look like some kind of attempt
-		 * at exposing the VGA memory hole)
-		 */
-		if (cpu_addr == OF_BAD_ADDR || size == 0)
-			continue;
-
-		/* Now consume following elements while they are contiguous */
-		for (; rlen >= np * sizeof(u32);
-		     ranges += np, rlen -= np * 4) {
-			if (ranges[0] != pci_space)
-				break;
-			pci_next = of_read_number(ranges + 1, 2);
-			cpu_next = of_translate_address(dev, ranges + 3);
-			if (pci_next != pci_addr + size ||
-			    cpu_next != cpu_addr + size)
-				break;
-			size += of_read_number(ranges + pna + 3, 2);
-		}
-
-		/* Act based on address space type */
-		res = NULL;
-		switch ((pci_space >> 24) & 0x3) {
-		case 1:		/* PCI IO space */
-			pr_info("  IO 0x%016llx..0x%016llx -> 0x%016llx\n",
-			       cpu_addr, cpu_addr + size - 1, pci_addr);
-
-			/* We support only one IO range */
-			if (hose->pci_io_size) {
-				pr_info(" \\--> Skipped (too many) !\n");
-				continue;
-			}
-			/* On 32 bits, limit I/O space to 16MB */
-			if (size > 0x01000000)
-				size = 0x01000000;
-
-			/* 32 bits needs to map IOs here */
-			hose->io_base_virt = ioremap(cpu_addr, size);
-
-			/* Expect trouble if pci_addr is not 0 */
-			if (primary)
-				isa_io_base =
-					(unsigned long)hose->io_base_virt;
-			/* pci_io_size and io_base_phys always represent IO
-			 * space starting at 0 so we factor in pci_addr
-			 */
-			hose->pci_io_size = pci_addr + size;
-			hose->io_base_phys = cpu_addr - pci_addr;
-
-			/* Build resource */
-			res = &hose->io_resource;
-			res->flags = IORESOURCE_IO;
-			res->start = pci_addr;
-			break;
-		case 2:		/* PCI Memory space */
-		case 3:		/* PCI 64 bits Memory space */
-			pr_info(" MEM 0x%016llx..0x%016llx -> 0x%016llx %s\n",
-			       cpu_addr, cpu_addr + size - 1, pci_addr,
-			       (pci_space & 0x40000000) ? "Prefetch" : "");
-
-			/* We support only 3 memory ranges */
-			if (memno >= 3) {
-				pr_info(" \\--> Skipped (too many) !\n");
-				continue;
-			}
-			/* Handles ISA memory hole space here */
-			if (pci_addr == 0) {
-				isa_mb = cpu_addr;
-				isa_hole = memno;
-				if (primary || isa_mem_base == 0)
-					isa_mem_base = cpu_addr;
-				hose->isa_mem_phys = cpu_addr;
-				hose->isa_mem_size = size;
-			}
-
-			/* We get the PCI/Mem offset from the first range or
-			 * the, current one if the offset came from an ISA
-			 * hole. If they don't match, bugger.
-			 */
-			if (memno == 0 ||
-			    (isa_hole >= 0 && pci_addr != 0 &&
-			     hose->pci_mem_offset == isa_mb))
-				hose->pci_mem_offset = cpu_addr - pci_addr;
-			else if (pci_addr != 0 &&
-				 hose->pci_mem_offset != cpu_addr - pci_addr) {
-				pr_info(" \\--> Skipped (offset mismatch) !\n");
-				continue;
-			}
-
-			/* Build resource */
-			res = &hose->mem_resources[memno++];
-			res->flags = IORESOURCE_MEM;
-			if (pci_space & 0x40000000)
-				res->flags |= IORESOURCE_PREFETCH;
-			res->start = cpu_addr;
-			break;
-		}
-		if (res != NULL) {
-			res->name = dev->full_name;
-			res->end = res->start + size - 1;
-			res->parent = NULL;
-			res->sibling = NULL;
-			res->child = NULL;
-		}
-	}
-
-	/* If there's an ISA hole and the pci_mem_offset is -not- matching
-	 * the ISA hole offset, then we need to remove the ISA hole from
-	 * the resource list for that brige
-	 */
-	if (isa_hole >= 0 && hose->pci_mem_offset != isa_mb) {
-		unsigned int next = isa_hole + 1;
-		pr_info(" Removing ISA hole at 0x%016llx\n", isa_mb);
-		if (next < memno)
-			memmove(&hose->mem_resources[isa_hole],
-				&hose->mem_resources[next],
-				sizeof(struct resource) * (memno - next));
-		hose->mem_resources[--memno].flags = 0;
-	}
-}
-
 /* Decide whether to display the domain number in /proc */
 int pci_proc_domain(struct pci_bus *bus)
 {
diff --git a/arch/mips/pci/pci.c b/arch/mips/pci/pci.c
index 0872f12..bee49a4 100644
--- a/arch/mips/pci/pci.c
+++ b/arch/mips/pci/pci.c
@@ -122,51 +122,33 @@ static void pcibios_scanbus(struct pci_controller *hose)
 #ifdef CONFIG_OF
 void pci_load_of_ranges(struct pci_controller *hose, struct device_node *node)
 {
-	const __be32 *ranges;
-	int rlen;
-	int pna = of_n_addr_cells(node);
-	int np = pna + 5;
+	struct of_pci_range_range range;
+	struct of_pci_range_parser parser;
+	u32 res_type;
 
 	pr_info("PCI host bridge %s ranges:\n", node->full_name);
-	ranges = of_get_property(node, "ranges", &rlen);
-	if (ranges == NULL)
-		return;
 	hose->of_node = node;
 
-	while ((rlen -= np * 4) >= 0) {
-		u32 pci_space;
+	if (of_pci_range_parser(&parser, node))
+		return;
+
+	for_each_of_pci_range(&parser, &range) {
 		struct resource *res = NULL;
-		u64 addr, size;
-
-		pci_space = be32_to_cpup(&ranges[0]);
-		addr = of_translate_address(node, ranges + 3);
-		size = of_read_number(ranges + pna + 3, 2);
-		ranges += np;
-		switch ((pci_space >> 24) & 0x3) {
-		case 1:		/* PCI IO space */
+
+		res_type = range.flags & IORESOURCE_TYPE_BITS;
+		if (res_type == IORESOURCE_IO) {
 			pr_info("  IO 0x%016llx..0x%016llx\n",
-					addr, addr + size - 1);
+				range.addr, range.addr + range.size - 1);
 			hose->io_map_base =
-				(unsigned long)ioremap(addr, size);
+				(unsigned long)ioremap(range.addr, range.size);
 			res = hose->io_resource;
-			res->flags = IORESOURCE_IO;
-			break;
-		case 2:		/* PCI Memory space */
-		case 3:		/* PCI 64 bits Memory space */
+		} else if (res_type == IORESOURCE_MEM) {
 			pr_info(" MEM 0x%016llx..0x%016llx\n",
-					addr, addr + size - 1);
+				range.addr, range.addr + range.size - 1);
 			res = hose->mem_resource;
-			res->flags = IORESOURCE_MEM;
-			break;
-		}
-		if (res != NULL) {
-			res->start = addr;
-			res->name = node->full_name;
-			res->end = res->start + size - 1;
-			res->parent = NULL;
-			res->sibling = NULL;
-			res->child = NULL;
 		}
+		if (res != NULL)
+			of_pci_range_to_resource(&range, node, res);
 	}
 }
 #endif
diff --git a/arch/powerpc/include/asm/pci-bridge.h b/arch/powerpc/include/asm/pci-bridge.h
index 025a130..205bfba 100644
--- a/arch/powerpc/include/asm/pci-bridge.h
+++ b/arch/powerpc/include/asm/pci-bridge.h
@@ -10,6 +10,7 @@
 #include <linux/pci.h>
 #include <linux/list.h>
 #include <linux/ioport.h>
+#include <linux/of_pci.h>
 #include <asm-generic/pci-bridge.h>
 
 struct device_node;
@@ -231,10 +232,6 @@ extern int pcibios_map_io_space(struct pci_bus *bus);
 extern struct pci_controller *pci_find_hose_for_OF_device(
 			struct device_node* node);
 
-/* Fill up host controller resources from the OF node */
-extern void pci_process_bridge_OF_ranges(struct pci_controller *hose,
-			struct device_node *dev, int primary);
-
 /* Allocate & free a PCI host bridge structure */
 extern struct pci_controller *pcibios_alloc_controller(struct device_node *dev);
 extern void pcibios_free_controller(struct pci_controller *phb);
diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index fa12ae4..6edf396 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -640,198 +640,6 @@ void pci_resource_to_user(const struct pci_dev *dev, int bar,
 	*end = rsrc->end - offset;
 }
 
-/**
- * pci_process_bridge_OF_ranges - Parse PCI bridge resources from device tree
- * @hose: newly allocated pci_controller to be setup
- * @dev: device node of the host bridge
- * @primary: set if primary bus (32 bits only, soon to be deprecated)
- *
- * This function will parse the "ranges" property of a PCI host bridge device
- * node and setup the resource mapping of a pci controller based on its
- * content.
- *
- * Life would be boring if it wasn't for a few issues that we have to deal
- * with here:
- *
- *   - We can only cope with one IO space range and up to 3 Memory space
- *     ranges. However, some machines (thanks Apple !) tend to split their
- *     space into lots of small contiguous ranges. So we have to coalesce.
- *
- *   - We can only cope with all memory ranges having the same offset
- *     between CPU addresses and PCI addresses. Unfortunately, some bridges
- *     are setup for a large 1:1 mapping along with a small "window" which
- *     maps PCI address 0 to some arbitrary high address of the CPU space in
- *     order to give access to the ISA memory hole.
- *     The way out of here that I've chosen for now is to always set the
- *     offset based on the first resource found, then override it if we
- *     have a different offset and the previous was set by an ISA hole.
- *
- *   - Some busses have IO space not starting at 0, which causes trouble with
- *     the way we do our IO resource renumbering. The code somewhat deals with
- *     it for 64 bits but I would expect problems on 32 bits.
- *
- *   - Some 32 bits platforms such as 4xx can have physical space larger than
- *     32 bits so we need to use 64 bits values for the parsing
- */
-void pci_process_bridge_OF_ranges(struct pci_controller *hose,
-				  struct device_node *dev, int primary)
-{
-	const u32 *ranges;
-	int rlen;
-	int pna = of_n_addr_cells(dev);
-	int np = pna + 5;
-	int memno = 0, isa_hole = -1;
-	u32 pci_space;
-	unsigned long long pci_addr, cpu_addr, pci_next, cpu_next, size;
-	unsigned long long isa_mb = 0;
-	struct resource *res;
-
-	printk(KERN_INFO "PCI host bridge %s %s ranges:\n",
-	       dev->full_name, primary ? "(primary)" : "");
-
-	/* Get ranges property */
-	ranges = of_get_property(dev, "ranges", &rlen);
-	if (ranges == NULL)
-		return;
-
-	/* Parse it */
-	while ((rlen -= np * 4) >= 0) {
-		/* Read next ranges element */
-		pci_space = ranges[0];
-		pci_addr = of_read_number(ranges + 1, 2);
-		cpu_addr = of_translate_address(dev, ranges + 3);
-		size = of_read_number(ranges + pna + 3, 2);
-		ranges += np;
-
-		/* If we failed translation or got a zero-sized region
-		 * (some FW try to feed us with non sensical zero sized regions
-		 * such as power3 which look like some kind of attempt at exposing
-		 * the VGA memory hole)
-		 */
-		if (cpu_addr == OF_BAD_ADDR || size == 0)
-			continue;
-
-		/* Now consume following elements while they are contiguous */
-		for (; rlen >= np * sizeof(u32);
-		     ranges += np, rlen -= np * 4) {
-			if (ranges[0] != pci_space)
-				break;
-			pci_next = of_read_number(ranges + 1, 2);
-			cpu_next = of_translate_address(dev, ranges + 3);
-			if (pci_next != pci_addr + size ||
-			    cpu_next != cpu_addr + size)
-				break;
-			size += of_read_number(ranges + pna + 3, 2);
-		}
-
-		/* Act based on address space type */
-		res = NULL;
-		switch ((pci_space >> 24) & 0x3) {
-		case 1:		/* PCI IO space */
-			printk(KERN_INFO
-			       "  IO 0x%016llx..0x%016llx -> 0x%016llx\n",
-			       cpu_addr, cpu_addr + size - 1, pci_addr);
-
-			/* We support only one IO range */
-			if (hose->pci_io_size) {
-				printk(KERN_INFO
-				       " \\--> Skipped (too many) !\n");
-				continue;
-			}
-#ifdef CONFIG_PPC32
-			/* On 32 bits, limit I/O space to 16MB */
-			if (size > 0x01000000)
-				size = 0x01000000;
-
-			/* 32 bits needs to map IOs here */
-			hose->io_base_virt = ioremap(cpu_addr, size);
-
-			/* Expect trouble if pci_addr is not 0 */
-			if (primary)
-				isa_io_base =
-					(unsigned long)hose->io_base_virt;
-#endif /* CONFIG_PPC32 */
-			/* pci_io_size and io_base_phys always represent IO
-			 * space starting at 0 so we factor in pci_addr
-			 */
-			hose->pci_io_size = pci_addr + size;
-			hose->io_base_phys = cpu_addr - pci_addr;
-
-			/* Build resource */
-			res = &hose->io_resource;
-			res->flags = IORESOURCE_IO;
-			res->start = pci_addr;
-			break;
-		case 2:		/* PCI Memory space */
-		case 3:		/* PCI 64 bits Memory space */
-			printk(KERN_INFO
-			       " MEM 0x%016llx..0x%016llx -> 0x%016llx %s\n",
-			       cpu_addr, cpu_addr + size - 1, pci_addr,
-			       (pci_space & 0x40000000) ? "Prefetch" : "");
-
-			/* We support only 3 memory ranges */
-			if (memno >= 3) {
-				printk(KERN_INFO
-				       " \\--> Skipped (too many) !\n");
-				continue;
-			}
-			/* Handles ISA memory hole space here */
-			if (pci_addr == 0) {
-				isa_mb = cpu_addr;
-				isa_hole = memno;
-				if (primary || isa_mem_base == 0)
-					isa_mem_base = cpu_addr;
-				hose->isa_mem_phys = cpu_addr;
-				hose->isa_mem_size = size;
-			}
-
-			/* We get the PCI/Mem offset from the first range or
-			 * the, current one if the offset came from an ISA
-			 * hole. If they don't match, bugger.
-			 */
-			if (memno == 0 ||
-			    (isa_hole >= 0 && pci_addr != 0 &&
-			     hose->pci_mem_offset == isa_mb))
-				hose->pci_mem_offset = cpu_addr - pci_addr;
-			else if (pci_addr != 0 &&
-				 hose->pci_mem_offset != cpu_addr - pci_addr) {
-				printk(KERN_INFO
-				       " \\--> Skipped (offset mismatch) !\n");
-				continue;
-			}
-
-			/* Build resource */
-			res = &hose->mem_resources[memno++];
-			res->flags = IORESOURCE_MEM;
-			if (pci_space & 0x40000000)
-				res->flags |= IORESOURCE_PREFETCH;
-			res->start = cpu_addr;
-			break;
-		}
-		if (res != NULL) {
-			res->name = dev->full_name;
-			res->end = res->start + size - 1;
-			res->parent = NULL;
-			res->sibling = NULL;
-			res->child = NULL;
-		}
-	}
-
-	/* If there's an ISA hole and the pci_mem_offset is -not- matching
-	 * the ISA hole offset, then we need to remove the ISA hole from
-	 * the resource list for that brige
-	 */
-	if (isa_hole >= 0 && hose->pci_mem_offset != isa_mb) {
-		unsigned int next = isa_hole + 1;
-		printk(KERN_INFO " Removing ISA hole at 0x%016llx\n", isa_mb);
-		if (next < memno)
-			memmove(&hose->mem_resources[isa_hole],
-				&hose->mem_resources[next],
-				sizeof(struct resource) * (memno - next));
-		hose->mem_resources[--memno].flags = 0;
-	}
-}
-
 /* Decide whether to display the domain number in /proc */
 int pci_proc_domain(struct pci_bus *bus)
 {
diff --git a/drivers/of/address.c b/drivers/of/address.c
index 04da786..e87f45e 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -227,6 +227,69 @@ int of_pci_address_to_resource(struct device_node *dev, int bar,
 	return __of_address_to_resource(dev, addrp, size, flags, NULL, r);
 }
 EXPORT_SYMBOL_GPL(of_pci_address_to_resource);
+
+int of_pci_range_parser(struct of_pci_range_parser *parser,
+			struct device_node *node)
+{
+	const int na = 3, ns = 2;
+	int rlen;
+
+	parser->node = node;
+	parser->pna = of_n_addr_cells(node);
+	parser->np = parser->pna + na + ns;
+
+	parser->range = of_get_property(node, "ranges", &rlen);
+	if (parser->range == NULL)
+		return -ENOENT;
+
+	parser->end = parser->range + rlen / sizeof(__be32);
+
+	return 0;
+}
+
+struct of_pci_range *of_pci_process_ranges(struct of_pci_range_parser *parser,
+						struct of_pci_range *range)
+{
+	const int na = 3, ns = 2;
+
+	if (!parser->range || parser->range + parser->np > parser->end)
+		return NULL;
+
+	range->pci_space = be32_to_cpup(parser->range);
+	range->flags = of_bus_pci_get_flags(parser->range);
+	range->pci_addr = of_read_number(parser->range + 1, ns);
+	range->cpu_addr = of_translate_address(parser->node,
+				parser->range + na);
+	range->size = of_read_number(parser->range + parser->pna + na, ns);
+
+	parser->range += parser->np;
+
+	/* Now consume following elements while they are contiguous */
+	while (parser->range + parser->np <= parser->end) {
+		u32 flags, pci_space;
+		u64 pci_addr, cpu_addr, size;
+
+		pci_space = be32_to_cpup(parser->range);
+		flags = of_bus_pci_get_flags(parser->range);
+		pci_addr = of_read_number(parser->range + 1, ns);
+		cpu_addr = of_translate_address(parser->node,
+				parser->range + na);
+		size = of_read_number(parser->range + parser->pna + na, ns);
+
+		if (flags != range->flags)
+			break;
+		if (pci_addr != range->pci_addr + range->size ||
+		    cpu_addr != range->cpu_addr + range->size)
+			break;
+
+		range->size += size;
+		parser->range += parser->np;
+	}
+
+	return range;
+}
+EXPORT_SYMBOL_GPL(of_pci_process_ranges);
+
 #endif /* CONFIG_PCI */
 
 /*
diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
index 13e37e2..f88bd18 100644
--- a/drivers/of/of_pci.c
+++ b/drivers/of/of_pci.c
@@ -4,6 +4,10 @@
 #include <linux/of_pci.h>
 #include <asm/prom.h>
 
+#if defined(CONFIG_PPC32) || defined(CONFIG_PPC64) || defined(CONFIG_MICROBLAZE)
+#include <asm/pci-bridge.h>
+#endif
+
 static inline int __of_pci_pci_compare(struct device_node *node,
 				       unsigned int devfn)
 {
@@ -40,3 +44,167 @@ struct device_node *of_pci_find_child_device(struct device_node *parent,
 	return NULL;
 }
 EXPORT_SYMBOL_GPL(of_pci_find_child_device);
+
+/**
+ * pci_process_bridge_OF_ranges - Parse PCI bridge resources from device tree
+ * @hose: newly allocated pci_controller to be setup
+ * @dev: device node of the host bridge
+ * @primary: set if primary bus (32 bits only, soon to be deprecated)
+ *
+ * This function will parse the "ranges" property of a PCI host bridge device
+ * node and setup the resource mapping of a pci controller based on its
+ * content.
+ *
+ * Life would be boring if it wasn't for a few issues that we have to deal
+ * with here:
+ *
+ *   - We can only cope with one IO space range and up to 3 Memory space
+ *     ranges. However, some machines (thanks Apple !) tend to split their
+ *     space into lots of small contiguous ranges. So we have to coalesce.
+ *
+ *   - We can only cope with all memory ranges having the same offset
+ *     between CPU addresses and PCI addresses. Unfortunately, some bridges
+ *     are setup for a large 1:1 mapping along with a small "window" which
+ *     maps PCI address 0 to some arbitrary high address of the CPU space in
+ *     order to give access to the ISA memory hole.
+ *     The way out of here that I've chosen for now is to always set the
+ *     offset based on the first resource found, then override it if we
+ *     have a different offset and the previous was set by an ISA hole.
+ *
+ *   - Some busses have IO space not starting at 0, which causes trouble with
+ *     the way we do our IO resource renumbering. The code somewhat deals with
+ *     it for 64 bits but I would expect problems on 32 bits.
+ *
+ *   - Some 32 bits platforms such as 4xx can have physical space larger than
+ *     32 bits so we need to use 64 bits values for the parsing
+ */
+#if defined(CONFIG_PPC32) || defined(CONFIG_PPC64) || defined(CONFIG_MICROBLAZE)
+void pci_process_bridge_OF_ranges(struct pci_controller *hose,
+				  struct device_node *dev, int primary)
+{
+	int memno = 0, isa_hole = -1;
+	unsigned long long isa_mb = 0;
+	struct resource *res;
+	struct of_pci_range range;
+	struct of_pci_range_parser parser;
+	u32 res_type;
+
+	pr_info("PCI host bridge %s %s ranges:\n",
+	       dev->full_name, primary ? "(primary)" : "");
+
+	/* Check for ranges property */
+	if (of_pci_range_parser(&parser, dev))
+		return;
+
+	pr_debug("Parsing ranges property...\n");
+	for_each_of_pci_range(&parser, &range) {
+		/* Read next ranges element */
+		pr_debug("pci_space: 0x%08x pci_addr: 0x%016llx ",
+				range.pci_space, range.pci_addr);
+		pr_debug("cpu_addr: 0x%016llx size: 0x%016llx\n",
+				range.cpu_addr, range.size);
+
+		/* If we failed translation or got a zero-sized region
+		 * (some FW try to feed us with non sensical zero sized regions
+		 * such as power3 which look like some kind of attempt at
+		 * exposing the VGA memory hole)
+		 */
+		if (range.cpu_addr == OF_BAD_ADDR || range.size == 0)
+			continue;
+
+		/* Act based on address space type */
+		res = NULL;
+		res_type = range.flags & IORESOURCE_TYPE_BITS;
+		if (res_type == IORESOURCE_IO) {
+			pr_info("  IO 0x%016llx..0x%016llx -> 0x%016llx\n",
+				range.cpu_addr, range.cpu_addr + range.size - 1,
+				range.pci_addr);
+
+			/* We support only one IO range */
+			if (hose->pci_io_size) {
+				pr_info(" \\--> Skipped (too many) !\n");
+				continue;
+			}
+#if defined(CONFIG_PPC32) || defined(CONFIG_MICROBLAZE)
+			/* On 32 bits, limit I/O space to 16MB */
+			if (range.size > 0x01000000)
+				range.size = 0x01000000;
+
+			/* 32 bits needs to map IOs here */
+			hose->io_base_virt = ioremap(range.cpu_addr,
+						range.size);
+
+			/* Expect trouble if pci_addr is not 0 */
+			if (primary)
+				isa_io_base =
+					(unsigned long)hose->io_base_virt;
+#endif /* CONFIG_PPC32 || CONFIG_MICROBLAZE */
+			/* pci_io_size and io_base_phys always represent IO
+			 * space starting at 0 so we factor in pci_addr
+			 */
+			hose->pci_io_size = range.pci_addr + range.size;
+			hose->io_base_phys = range.cpu_addr - range.pci_addr;
+
+			/* Build resource */
+			res = &hose->io_resource;
+			range.cpu_addr = range.pci_addr;
+		} else if (res_type == IORESOURCE_MEM) {
+			pr_info(" MEM 0x%016llx..0x%016llx -> 0x%016llx %s\n",
+				range.cpu_addr, range.cpu_addr + range.size - 1,
+				range.pci_addr,
+				(range.pci_space & 0x40000000) ?
+				"Prefetch" : "");
+
+			/* We support only 3 memory ranges */
+			if (memno >= 3) {
+				pr_info(" \\--> Skipped (too many) !\n");
+				continue;
+			}
+			/* Handles ISA memory hole space here */
+			if (range.pci_addr == 0) {
+				isa_mb = range.cpu_addr;
+				isa_hole = memno;
+				if (primary || isa_mem_base == 0)
+					isa_mem_base = range.cpu_addr;
+				hose->isa_mem_phys = range.cpu_addr;
+				hose->isa_mem_size = range.size;
+			}
+
+			/* We get the PCI/Mem offset from the first range or
+			 * the, current one if the offset came from an ISA
+			 * hole. If they don't match, bugger.
+			 */
+			if (memno == 0 ||
+			(isa_hole >= 0 && range.pci_addr != 0 &&
+			     hose->pci_mem_offset == isa_mb))
+				hose->pci_mem_offset = range.cpu_addr -
+							range.pci_addr;
+			else if (range.pci_addr != 0 &&
+				hose->pci_mem_offset != range.cpu_addr -
+							range.pci_addr) {
+				pr_info(" \\--> Skipped (offset mismatch) !\n");
+				continue;
+			}
+
+			/* Build resource */
+			res = &hose->mem_resources[memno++];
+		}
+		if (res != NULL)
+			of_pci_range_to_resource(&range, dev, res);
+	}
+
+	/* If there's an ISA hole and the pci_mem_offset is -not- matching
+	 * the ISA hole offset, then we need to remove the ISA hole from
+	 * the resource list for that brige
+	 */
+	if (isa_hole >= 0 && hose->pci_mem_offset != isa_mb) {
+		unsigned int next = isa_hole + 1;
+		pr_info(" Removing ISA hole at 0x%016llx\n", isa_mb);
+		if (next < memno)
+			memmove(&hose->mem_resources[isa_hole],
+				&hose->mem_resources[next],
+				sizeof(struct resource) * (memno - next));
+		hose->mem_resources[--memno].flags = 0;
+	}
+}
+#endif
diff --git a/include/linux/of_address.h b/include/linux/of_address.h
index 0506eb5..c7003a3 100644
--- a/include/linux/of_address.h
+++ b/include/linux/of_address.h
@@ -4,6 +4,32 @@
 #include <linux/errno.h>
 #include <linux/of.h>
 
+struct of_pci_range_parser {
+	struct device_node *node;
+	const __be32 *range, *end;
+	int np, pna;
+};
+
+struct of_pci_range {
+	u32 pci_space;
+	u64 pci_addr;
+	u64 cpu_addr;
+	u64 size;
+	u32 flags;
+};
+
+#define for_each_of_pci_range(parser, range) \
+	for (; of_pci_process_ranges(parser, range);)
+
+#define of_pci_range_to_resource(range, np, res) \
+	do { \
+		(res)->flags = (range)->flags; \
+		(res)->start = (range)->cpu_addr; \
+		(res)->end = (range)->cpu_addr + (range)->size - 1; \
+		(res)->parent = (res)->child = (res)->sibling = NULL; \
+		(res)->name = (np)->full_name; \
+	} while (0)
+
 #ifdef CONFIG_OF_ADDRESS
 extern u64 of_translate_address(struct device_node *np, const __be32 *addr);
 extern bool of_can_translate_address(struct device_node *dev);
@@ -27,6 +53,10 @@ static inline unsigned long pci_address_to_pio(phys_addr_t addr) { return -1; }
 #define pci_address_to_pio pci_address_to_pio
 #endif
 
+int of_pci_range_parser(struct of_pci_range_parser *parser,
+			struct device_node *node);
+struct of_pci_range *of_pci_process_ranges(struct of_pci_range_parser *parser,
+						struct of_pci_range *range);
 #else /* CONFIG_OF_ADDRESS */
 #ifndef of_address_to_resource
 static inline int of_address_to_resource(struct device_node *dev, int index,
@@ -53,6 +83,18 @@ static inline const __be32 *of_get_address(struct device_node *dev, int index,
 {
 	return NULL;
 }
+
+int of_pci_range_parser(struct of_pci_range_parser *parser,
+			struct device_noed *node)
+{
+	return -1;
+}
+
+struct of_pci_range *of_pci_process_ranges(struct of_pci_range_parser *parser,
+						struct of_pci_range *range)
+{
+	return NULL;
+}
 #endif /* CONFIG_OF_ADDRESS */
 
 
diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
index bb115de..6852481 100644
--- a/include/linux/of_pci.h
+++ b/include/linux/of_pci.h
@@ -11,4 +11,7 @@ struct device_node;
 struct device_node *of_pci_find_child_device(struct device_node *parent,
 					     unsigned int devfn);
 
+void pci_process_bridge_OF_ranges(struct pci_controller *hose,
+			struct device_node *dev, int primary);
+
 #endif
-- 
1.7.0.4



From sameo at linux.intel.com  Mon Apr  8 10:38:02 2013
From: sameo at linux.intel.com (Samuel Ortiz)
Date: Mon, 8 Apr 2013 16:38:02 +0200
Subject: [GIT PULL] ux500 multiplatform tags
In-Reply-To: <CACRpkdbPZ5Nvv9+Bz9UE-U6-9QpqAr6UKGyYrTAxj78SJaknvg@mail.gmail.com>
References: <CACRpkdbPZ5Nvv9+Bz9UE-U6-9QpqAr6UKGyYrTAxj78SJaknvg@mail.gmail.com>
Message-ID: <20130408143802.GD21256@zurbaran>

Hi Linus,

On Mon, Apr 08, 2013 at 02:52:42PM +0200, Linus Walleij wrote:
> Hi ARM SoC folks and Sam,
> 
> These are the two multiplatform tags for MFD and ARM SoC.
> 
> As agreed there is one tag for a number of MFD patches that
> remove the <mach/*> dependencies from the DB8500 PRCMU
> driver, then another tag dependent on the former that from that
> point switches to multiplatform.
> 
> Below are two tags on git request-pull formar: the first one
> is for *both* trees, MFD and ARM SoC, the second is only
> for ARM SoC.
> 
> I have moved a few hunks and introduced a new patch in the
> MFD series to make things compile and bisect properly.
> Notably the patch "mfd: db8500-prcmu: drop unused includes"
> is a new one, but the end result is textually equivalent to what
> has already been posted so I consider this a reviewed patch
> set and the split as plain mechanics.
> 
> Please pull your applicable branches!
> 
> Yours,
> Linus Walleij
> 
> 
> MFD tag:
> 
> 
> The following changes since commit a937536b868b8369b98967929045f1df54234323:
> 
>   Linux 3.9-rc3 (2013-03-17 15:59:32 -0700)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-stericsson.git
> tags/ux500-multiplatform-mfd
Pulled to my mfd-next tree. This is much appreciated, thanks a lot.

Cheers,
Samuel.

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


From cov at codeaurora.org  Mon Apr  8 10:42:24 2013
From: cov at codeaurora.org (Christopher Covington)
Date: Mon, 08 Apr 2013 10:42:24 -0400
Subject: [PATCH] arm64: Fix task tracing
In-Reply-To: <20130403180443.GB21167@mudshark.cambridge.arm.com>
References: <1365012061-31660-1-git-send-email-cov@codeaurora.org>
 <20130403180443.GB21167@mudshark.cambridge.arm.com>
Message-ID: <5162D750.9050706@codeaurora.org>

Hi Will,

On 04/03/2013 02:04 PM, Will Deacon wrote:
> Hi Christopher,
> 
> On Wed, Apr 03, 2013 at 07:01:01PM +0100, Christopher Covington wrote:
>> For accurate accounting call contextidr_thread_switch before a
>> task is scheduled, rather than after.
>>
>> Signed-off-by: Christopher Covington <cov at codeaurora.org>
>> ---
>>  arch/arm64/kernel/process.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
>> index 0337cdb..c2cc249 100644
>> --- a/arch/arm64/kernel/process.c
>> +++ b/arch/arm64/kernel/process.c
>> @@ -311,11 +311,11 @@ struct task_struct *__switch_to(struct task_struct *prev,
>>  	fpsimd_thread_switch(next);
>>  	tls_thread_switch(next);
>>  	hw_breakpoint_thread_switch(next);
>> +	contextidr_thread_switch(next);
>>  
>>  	/* the actual thread switch */
>>  	last = cpu_switch_to(prev, next);
>>  
>> -	contextidr_thread_switch(next);
>>  	return last;
>>  }
> 
> Catalin and I wondered about this and decided to go with the current
> approach in case a debugger, in response to the contextidr write, decided to
> go off and mine information about the *new* task using the sp.

The problem with the existing implementation is that it doesn't seem to
compensate for how cpu_switch_to changes the stack pointer. Consider the
following sequence.

cpu_switch_to(prev=A, next=B)
cpu_switch_to(prev=B, next=C)
cpu_switch_to(prev=C, next=A)

After the third call, using A's stack, next will be B, and its thread ID will
be written to CONTEXTIDR. An easy way to see this in a simulator is to just
instrument the code with some printk's.

Thanks,
Christopher

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by the Linux Foundation.


From ohad at wizery.com  Mon Apr  8 10:43:12 2013
From: ohad at wizery.com (Ohad Ben-Cohen)
Date: Mon, 8 Apr 2013 17:43:12 +0300
Subject: [GIT PULL] an hwspinlock fix for 3.9
Message-ID: <CAK=WgbZu8u=5pEq_W2FpYr_fP+zBhHc94pg4xWZ_0h75_1JE0w@mail.gmail.com>

The following changes since commit f6161aa153581da4a3867a2d1a7caf4be19b6ec9:

  Linux 3.9-rc2 (2013-03-10 16:54:19 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/ohad/hwspinlock.git
tags/hwspinlock-3.9-fix

for you to fetch changes up to c10b90d85a5126d25c89cbaa50dc9fdd1c4d001a:

  hwspinlock: fix __hwspin_lock_request error path (2013-04-05 17:45:11 +0300)

----------------------------------------------------------------
An hwspinlock fix from Li Fei, taking care of a faulty error path.

----------------------------------------------------------------
Li Fei (1):
      hwspinlock: fix __hwspin_lock_request error path

 drivers/hwspinlock/hwspinlock_core.c | 2 ++
 1 file changed, 2 insertions(+)


From p.zabel at pengutronix.de  Mon Apr  8 10:46:23 2013
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Mon,  8 Apr 2013 16:46:23 +0200
Subject: [PATCH 5/5] ARM i.MX53: set CLK_SET_RATE_PARENT flag on the
 tve_ext_sel clock
In-Reply-To: <1365432383-7787-1-git-send-email-p.zabel@pengutronix.de>
References: <1365432383-7787-1-git-send-email-p.zabel@pengutronix.de>
Message-ID: <1365432383-7787-6-git-send-email-p.zabel@pengutronix.de>

Use imx_clk_mux_flags to set the appropriate flags for the TVE
selector clock. This is needed so tve_clk rate changes can propagate
up to pll4_sw.

Signed-off-by: Philipp Zabel <p.zabel at pengutronix.de>
---
 arch/arm/mach-imx/clk-imx51-imx53.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-imx/clk-imx51-imx53.c b/arch/arm/mach-imx/clk-imx51-imx53.c
index 189d654..6fc486b 100644
--- a/arch/arm/mach-imx/clk-imx51-imx53.c
+++ b/arch/arm/mach-imx/clk-imx51-imx53.c
@@ -362,8 +362,8 @@ int __init mx51_clocks_init(unsigned long rate_ckil, unsigned long rate_osc,
 				mx51_ipu_di0_sel, ARRAY_SIZE(mx51_ipu_di0_sel));
 	clk[ipu_di1_sel] = imx_clk_mux("ipu_di1_sel", MXC_CCM_CSCMR2, 29, 3,
 				mx51_ipu_di1_sel, ARRAY_SIZE(mx51_ipu_di1_sel));
-	clk[tve_ext_sel] = imx_clk_mux("tve_ext_sel", MXC_CCM_CSCMR1, 6, 1,
-				mx51_tve_ext_sel, ARRAY_SIZE(mx51_tve_ext_sel));
+	clk[tve_ext_sel] = imx_clk_mux_flags("tve_ext_sel", MXC_CCM_CSCMR1, 6, 1,
+				mx51_tve_ext_sel, ARRAY_SIZE(mx51_tve_ext_sel), CLK_SET_RATE_PARENT);
 	clk[tve_s] = imx_clk_mux("tve_sel", MXC_CCM_CSCMR1, 7, 1,
 				mx51_tve_sel, ARRAY_SIZE(mx51_tve_sel));
 	clk[tve_gate] = imx_clk_gate2("tve_gate", "tve_sel", MXC_CCM_CCGR2, 30);
-- 
1.8.2.rc2



From p.zabel at pengutronix.de  Mon Apr  8 10:46:18 2013
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Mon,  8 Apr 2013 16:46:18 +0200
Subject: [PATCH 0/5] i.MX53 TVE clock patches
Message-ID: <1365432383-7787-1-git-send-email-p.zabel@pengutronix.de>

Hi,

the first two are just cleanups, the following three patches are changes
to the i.MX53 clock tree that are necessary to use the TVEv2 module as
VGA output on the Freescale i.MX53-QSB or TQ MBa53 boards.

regards
Philipp

---
 Documentation/devicetree/bindings/clock/imx5-clock.txt |  1 -
 arch/arm/mach-imx/clk-imx51-imx53.c                    | 17 ++++++++---------
 2 files changed, 8 insertions(+), 10 deletions(-)



From p.zabel at pengutronix.de  Mon Apr  8 10:46:22 2013
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Mon,  8 Apr 2013 16:46:22 +0200
Subject: [PATCH 4/5] ARM i.MX53: tve_di clock is not part of the CCM,
 but of TVE
In-Reply-To: <1365432383-7787-1-git-send-email-p.zabel@pengutronix.de>
References: <1365432383-7787-1-git-send-email-p.zabel@pengutronix.de>
Message-ID: <1365432383-7787-5-git-send-email-p.zabel@pengutronix.de>

Remove the tve_di clock from the CCM clock tree. It will be provided
by the Television Encoder driver, as this clock is an output signal
of the TVE module.

Signed-off-by: Philipp Zabel <p.zabel at pengutronix.de>
---
 Documentation/devicetree/bindings/clock/imx5-clock.txt | 1 -
 arch/arm/mach-imx/clk-imx51-imx53.c                    | 3 +--
 2 files changed, 1 insertion(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/clock/imx5-clock.txt b/Documentation/devicetree/bindings/clock/imx5-clock.txt
index 84cae1f..d71b4b2 100644
--- a/Documentation/devicetree/bindings/clock/imx5-clock.txt
+++ b/Documentation/devicetree/bindings/clock/imx5-clock.txt
@@ -38,7 +38,6 @@ clocks and IDs.
 	usb_phy_podf		23
 	cpu_podf		24
 	di_pred			25
-	tve_di			26
 	tve_s			27
 	uart1_ipg_gate		28
 	uart1_per_gate		29
diff --git a/arch/arm/mach-imx/clk-imx51-imx53.c b/arch/arm/mach-imx/clk-imx51-imx53.c
index 9226940..189d654 100644
--- a/arch/arm/mach-imx/clk-imx51-imx53.c
+++ b/arch/arm/mach-imx/clk-imx51-imx53.c
@@ -78,7 +78,7 @@ enum imx5_clks {
 	dummy, ckil, osc, ckih1, ckih2, ahb, ipg, axi_a, axi_b, uart_pred,
 	uart_root, esdhc_a_pred, esdhc_b_pred, esdhc_c_s, esdhc_d_s,
 	emi_sel, emi_slow_podf, nfc_podf, ecspi_pred, ecspi_podf, usboh3_pred,
-	usboh3_podf, usb_phy_pred, usb_phy_podf, cpu_podf, di_pred, tve_di,
+	usboh3_podf, usb_phy_pred, usb_phy_podf, cpu_podf, di_pred, tve_di_unused,
 	tve_s, uart1_ipg_gate, uart1_per_gate, uart2_ipg_gate,
 	uart2_per_gate, uart3_ipg_gate, uart3_per_gate, i2c1_gate, i2c2_gate,
 	gpt_ipg_gate, pwm1_ipg_gate, pwm1_hf_gate, pwm2_ipg_gate, pwm2_hf_gate,
@@ -187,7 +187,6 @@ static void __init mx5_clocks_common_init(unsigned long rate_ckil,
 				usb_phy_sel_str, ARRAY_SIZE(usb_phy_sel_str));
 	clk[cpu_podf] = imx_clk_divider("cpu_podf", "pll1_sw", MXC_CCM_CACRR, 0, 3);
 	clk[di_pred] = imx_clk_divider("di_pred", "pll3_sw", MXC_CCM_CDCDR, 6, 3);
-	clk[tve_di] = imx_clk_fixed("tve_di", 65000000); /* FIXME */
 	clk[iim_gate] = imx_clk_gate2("iim_gate", "ipg", MXC_CCM_CCGR0, 30);
 	clk[uart1_ipg_gate] = imx_clk_gate2("uart1_ipg_gate", "ipg", MXC_CCM_CCGR1, 6);
 	clk[uart1_per_gate] = imx_clk_gate2("uart1_per_gate", "uart_root", MXC_CCM_CCGR1, 8);
-- 
1.8.2.rc2



From p.zabel at pengutronix.de  Mon Apr  8 10:46:19 2013
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Mon,  8 Apr 2013 16:46:19 +0200
Subject: [PATCH 1/5] ARM i.MX5: Remove tve_sel clock from i.MX53 clock tree
In-Reply-To: <1365432383-7787-1-git-send-email-p.zabel@pengutronix.de>
References: <1365432383-7787-1-git-send-email-p.zabel@pengutronix.de>
Message-ID: <1365432383-7787-2-git-send-email-p.zabel@pengutronix.de>

On i.MX53, there is only tve_ext_sel.

Signed-off-by: Philipp Zabel <p.zabel at pengutronix.de>
---
 arch/arm/mach-imx/clk-imx51-imx53.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-imx/clk-imx51-imx53.c b/arch/arm/mach-imx/clk-imx51-imx53.c
index 1be5078..9daef9d 100644
--- a/arch/arm/mach-imx/clk-imx51-imx53.c
+++ b/arch/arm/mach-imx/clk-imx51-imx53.c
@@ -45,7 +45,7 @@ static const char *mx53_ipu_di1_sel[] = { "di_pred", "osc", "ckih1", "tve_di", "
 static const char *mx53_ldb_di1_sel[] = { "pll3_sw", "pll4_sw", };
 static const char *mx51_tve_ext_sel[] = { "osc", "ckih1", };
 static const char *mx53_tve_ext_sel[] = { "pll4_sw", "ckih1", };
-static const char *tve_sel[] = { "tve_pred", "tve_ext_sel", };
+static const char *mx51_tve_sel[] = { "tve_pred", "tve_ext_sel", };
 static const char *ipu_sel[] = { "axi_a", "axi_b", "emi_slow_gate", "ahb", };
 static const char *gpu3d_sel[] = { "axi_a", "axi_b", "emi_slow_gate", "ahb" };
 static const char *gpu2d_sel[] = { "axi_a", "axi_b", "emi_slow_gate", "ahb" };
@@ -188,7 +188,6 @@ static void __init mx5_clocks_common_init(unsigned long rate_ckil,
 	clk[cpu_podf] = imx_clk_divider("cpu_podf", "pll1_sw", MXC_CCM_CACRR, 0, 3);
 	clk[di_pred] = imx_clk_divider("di_pred", "pll3_sw", MXC_CCM_CDCDR, 6, 3);
 	clk[tve_di] = imx_clk_fixed("tve_di", 65000000); /* FIXME */
-	clk[tve_s] = imx_clk_mux("tve_sel", MXC_CCM_CSCMR1, 7, 1, tve_sel, ARRAY_SIZE(tve_sel));
 	clk[iim_gate] = imx_clk_gate2("iim_gate", "ipg", MXC_CCM_CCGR0, 30);
 	clk[uart1_ipg_gate] = imx_clk_gate2("uart1_ipg_gate", "ipg", MXC_CCM_CCGR1, 6);
 	clk[uart1_per_gate] = imx_clk_gate2("uart1_per_gate", "uart_root", MXC_CCM_CCGR1, 8);
@@ -367,6 +366,8 @@ int __init mx51_clocks_init(unsigned long rate_ckil, unsigned long rate_osc,
 				mx51_ipu_di1_sel, ARRAY_SIZE(mx51_ipu_di1_sel));
 	clk[tve_ext_sel] = imx_clk_mux("tve_ext_sel", MXC_CCM_CSCMR1, 6, 1,
 				mx51_tve_ext_sel, ARRAY_SIZE(mx51_tve_ext_sel));
+	clk[tve_s] = imx_clk_mux("tve_sel", MXC_CCM_CSCMR1, 7, 1,
+				mx51_tve_sel, ARRAY_SIZE(mx51_tve_sel));
 	clk[tve_gate] = imx_clk_gate2("tve_gate", "tve_sel", MXC_CCM_CCGR2, 30);
 	clk[tve_pred] = imx_clk_divider("tve_pred", "pll3_sw", MXC_CCM_CDCDR, 28, 3);
 	clk[esdhc1_per_gate] = imx_clk_gate2("esdhc1_per_gate", "esdhc_a_podf", MXC_CCM_CCGR3, 2);
-- 
1.8.2.rc2



From p.zabel at pengutronix.de  Mon Apr  8 10:46:20 2013
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Mon,  8 Apr 2013 16:46:20 +0200
Subject: [PATCH 2/5] ARM i.MX53: Remove unused tve_gate clkdev entry
In-Reply-To: <1365432383-7787-1-git-send-email-p.zabel@pengutronix.de>
References: <1365432383-7787-1-git-send-email-p.zabel@pengutronix.de>
Message-ID: <1365432383-7787-3-git-send-email-p.zabel@pengutronix.de>

Signed-off-by: Philipp Zabel <p.zabel at pengutronix.de>
---
 arch/arm/mach-imx/clk-imx51-imx53.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/mach-imx/clk-imx51-imx53.c b/arch/arm/mach-imx/clk-imx51-imx53.c
index 9daef9d..890012e 100644
--- a/arch/arm/mach-imx/clk-imx51-imx53.c
+++ b/arch/arm/mach-imx/clk-imx51-imx53.c
@@ -319,7 +319,6 @@ static void __init mx5_clocks_common_init(unsigned long rate_ckil,
 	clk_register_clkdev(clk[dummy], NULL, "imx2-wdt.0");
 	clk_register_clkdev(clk[dummy], NULL, "imx2-wdt.1");
 	clk_register_clkdev(clk[dummy], NULL, "imx-keypad");
-	clk_register_clkdev(clk[tve_gate], NULL, "imx-tve.0");
 	clk_register_clkdev(clk[ipu_di1_gate], "di1", "imx-tve.0");
 	clk_register_clkdev(clk[gpc_dvfs], "gpc_dvfs", NULL);
 	clk_register_clkdev(clk[epit1_ipg_gate], "ipg", "imx-epit.0");
-- 
1.8.2.rc2



From p.zabel at pengutronix.de  Mon Apr  8 10:46:21 2013
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Mon,  8 Apr 2013 16:46:21 +0200
Subject: [PATCH 3/5] ARM i.MX53: make tve_ext_sel propagate rate change to PLL
In-Reply-To: <1365432383-7787-1-git-send-email-p.zabel@pengutronix.de>
References: <1365432383-7787-1-git-send-email-p.zabel@pengutronix.de>
Message-ID: <1365432383-7787-4-git-send-email-p.zabel@pengutronix.de>

This is needed so the Television Encoder driver can set the rate
on tve_clk and have it propagated up to pll4_sw.

Signed-off-by: Philipp Zabel <p.zabel at pengutronix.de>
---
 arch/arm/mach-imx/clk-imx51-imx53.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-imx/clk-imx51-imx53.c b/arch/arm/mach-imx/clk-imx51-imx53.c
index 890012e..9226940 100644
--- a/arch/arm/mach-imx/clk-imx51-imx53.c
+++ b/arch/arm/mach-imx/clk-imx51-imx53.c
@@ -469,8 +469,8 @@ int __init mx53_clocks_init(unsigned long rate_ckil, unsigned long rate_osc,
 				mx53_ipu_di0_sel, ARRAY_SIZE(mx53_ipu_di0_sel));
 	clk[ipu_di1_sel] = imx_clk_mux("ipu_di1_sel", MXC_CCM_CSCMR2, 29, 3,
 				mx53_ipu_di1_sel, ARRAY_SIZE(mx53_ipu_di1_sel));
-	clk[tve_ext_sel] = imx_clk_mux("tve_ext_sel", MXC_CCM_CSCMR1, 6, 1,
-				mx53_tve_ext_sel, ARRAY_SIZE(mx53_tve_ext_sel));
+	clk[tve_ext_sel] = imx_clk_mux_flags("tve_ext_sel", MXC_CCM_CSCMR1, 6, 1,
+				mx53_tve_ext_sel, ARRAY_SIZE(mx53_tve_ext_sel), CLK_SET_RATE_PARENT);
 	clk[tve_gate] = imx_clk_gate2("tve_gate", "tve_pred", MXC_CCM_CCGR2, 30);
 	clk[tve_pred] = imx_clk_divider("tve_pred", "tve_ext_sel", MXC_CCM_CDCDR, 28, 3);
 	clk[esdhc1_per_gate] = imx_clk_gate2("esdhc1_per_gate", "esdhc_a_podf", MXC_CCM_CCGR3, 2);
-- 
1.8.2.rc2



From linux at roeck-us.net  Mon Apr  8 10:54:07 2013
From: linux at roeck-us.net (Guenter Roeck)
Date: Mon, 8 Apr 2013 07:54:07 -0700
Subject: [v5] clk: add si5351 i2c common clock driver
In-Reply-To: <51625F9A.1050308@gmail.com>
References: <1365139415-17815-1-git-send-email-sebastian.hesselbarth@gmail.com>
 <20130407225046.GA16326@roeck-us.net> <51620604.4070204@gmail.com>
 <20130408001725.GA16648@roeck-us.net> <51625F9A.1050308@gmail.com>
Message-ID: <20130408145407.GA12243@roeck-us.net>

On Mon, Apr 08, 2013 at 08:11:38AM +0200, Sebastian Hesselbarth wrote:
> On 04/08/2013 02:17 AM, Guenter Roeck wrote:
> >On Mon, Apr 08, 2013 at 01:49:24AM +0200, Sebastian Hesselbarth wrote:
> >>On 04/08/2013 12:50 AM, Guenter Roeck wrote:
> >>>On Fri, Apr 05, 2013 at 05:23:35AM -0000, Sebastian Hesselbarth wrote:
> >>>>This patch adds a common clock driver for Silicon Labs Si5351a/b/c
> >>>>i2c programmable clock generators. Currently, the driver supports
> >>>>DT kernels only and VXCO feature of si5351b is not implemented. DT
> >>>>bindings selectively allow to overwrite stored Si5351 configuration
> >>>>which is very helpful for clock generators with empty eeprom
> >>>>configuration. Corresponding device tree binding documentation is
> >>>>also added.
> >>>>
> >>>>Signed-off-by: Sebastian Hesselbarth<sebastian.hesselbarth at gmail.com>
> >>>>Tested-by: Daniel Mack<zonque at gmail.com>
> >>>>
> >>>[ ... ]
> >>>
> >>>>+static inline void _si5351_msynth_set_pll_master(
> >>>>+	struct si5351_driver_data *drvdata, unsigned char num, int is_master)
> >>>>+{
> >>>>+	unsigned long flags;
> >>>>+
> >>>>+	if (num>   8 ||
> >>>>+	    (drvdata->variant == SI5351_VARIANT_A3&&   num>   3))
> >>>>+		return;
> >>>>+
> >>>>+	flags = __clk_get_flags(drvdata->msynth[num].hw.clk);
> >>>>+	if (is_master)
> >>>>+		flags |= CLK_SET_RATE_PARENT;
> >>>>+	else
> >>>>+		flags&= ~CLK_SET_RATE_PARENT;
> >>>>+	__clk_set_flags(drvdata->msynth[num].hw.clk, flags);
> >>>>+}
> >>>>+
> >>>Unless I am missing something, neither __clk_get_flags() nor the new
> >>>__clk_set_flags is exported.
> >>>
> >>>Did you try to build and load the driver as module ?
> >>
> >>Well, good catch. I didn't try to build v5 as a module, but I guess it
> >>will fail. But I consider this as something that has to be addressed in
> >>clk framework itself, not in this patch. There will be other
> >>clk-providers built as module in the future for sure.
> >>
> >Sure, but you provided the patch to make __clk_set_flags global. To avoid
> >build failures, I would suggest to either submit a patch to export the
> >missing functions, or to remove the ability to build the driver as module.
> 
> Actually, I knew that __clk_set_flags patch will not be accepted
> before posting it ;)
> 
Ah, but part of that is to get you to think about it again, and to defend it if
it is really needed. After all, "it can be abused" applies to pretty much every
API.

Key question is if you _really_ need run-time flag modifications, or if you can
live with initialization-time settings. If you really need it, you'll have to
explain the reasons.

> >On a side note, do you happen to know anyone working on drivers for Si5319 or
> >Si5368 ?
> 
> No.

Too bad ... I may have to write that code myself then.

Thanks,
Guenter


From pebolle at tiscali.nl  Mon Apr  8 10:55:10 2013
From: pebolle at tiscali.nl (Paul Bolle)
Date: Mon, 08 Apr 2013 16:55:10 +0200
Subject: [PATCH] ARM: EXYNOS: remove "config EXYNOS_DEV_DRM"
Message-ID: <1365432910.1830.105.camel@x61.thuisdomein>

The only user of Kconfig symbol EXYNOS_DEV_DRM was removed in commit
0a9d5ac307aefbb2c772537d3fe7f75046d563ac ("ARM: EXYNOS: removing
exynos-drm device registration from non-dt platforms"). It is safe to
remove this symbol too.

Signed-off-by: Paul Bolle <pebolle at tiscali.nl>
---
Only "git grep" tested.

 arch/arm/mach-exynos/Kconfig | 10 ----------
 1 file changed, 10 deletions(-)

diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index 70f94c8..99e7142 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -95,11 +95,6 @@ config EXYNOS4_DEV_AHCI
 	help
 	  Compile in platform device definitions for AHCI
 
-config EXYNOS_DEV_DRM
-	bool
-	help
-	  Compile in platform device definitions for core DRM device
-
 config EXYNOS4_SETUP_FIMD0
 	bool
 	help
@@ -199,7 +194,6 @@ config MACH_SMDKV310
 	select EXYNOS4_SETUP_SDHCI
 	select EXYNOS4_SETUP_USB_PHY
 	select EXYNOS_DEV_DMA
-	select EXYNOS_DEV_DRM
 	select EXYNOS_DEV_SYSMMU
 	select S3C24XX_PWM
 	select S3C_DEV_HSMMC
@@ -253,7 +247,6 @@ config MACH_UNIVERSAL_C210
 	select EXYNOS4_SETUP_SDHCI
 	select EXYNOS4_SETUP_USB_PHY
 	select EXYNOS_DEV_DMA
-	select EXYNOS_DEV_DRM
 	select EXYNOS_DEV_SYSMMU
 	select HAVE_SCHED_CLOCK
 	select S3C_DEV_HSMMC
@@ -294,7 +287,6 @@ config MACH_NURI
 	select EXYNOS4_SETUP_SDHCI
 	select EXYNOS4_SETUP_USB_PHY
 	select EXYNOS_DEV_DMA
-	select EXYNOS_DEV_DRM
 	select S3C_DEV_HSMMC
 	select S3C_DEV_HSMMC2
 	select S3C_DEV_HSMMC3
@@ -330,7 +322,6 @@ config MACH_ORIGEN
 	select EXYNOS4_SETUP_SDHCI
 	select EXYNOS4_SETUP_USB_PHY
 	select EXYNOS_DEV_DMA
-	select EXYNOS_DEV_DRM
 	select EXYNOS_DEV_SYSMMU
 	select S3C24XX_PWM
 	select S3C_DEV_HSMMC
@@ -366,7 +357,6 @@ config MACH_SMDK4212
 	select EXYNOS4_SETUP_SDHCI
 	select EXYNOS4_SETUP_USB_PHY
 	select EXYNOS_DEV_DMA
-	select EXYNOS_DEV_DRM
 	select EXYNOS_DEV_SYSMMU
 	select S3C24XX_PWM
 	select S3C_DEV_HSMMC2
-- 
1.7.11.7



From s.nawrocki at samsung.com  Mon Apr  8 11:05:50 2013
From: s.nawrocki at samsung.com (Sylwester Nawrocki)
Date: Mon, 08 Apr 2013 17:05:50 +0200
Subject: [PATCH] ARM: Samsung: Select ARM_CPU_SUSPEND when required
In-Reply-To: <20130408110032.GK17995@n2100.arm.linux.org.uk>
References: <1365366442-16025-1-git-send-email-s.nawrocki@samsung.com>
 <2cd601ce343f$7d6aac50$784004f0$%kim@samsung.com>
 <51629B96.9050504@samsung.com> <20130408110032.GK17995@n2100.arm.linux.org.uk>
Message-ID: <5162DCCE.8090909@samsung.com>

On 04/08/2013 01:00 PM, Russell King - ARM Linux wrote:
> On Mon, Apr 08, 2013 at 12:27:34PM +0200, Sylwester Nawrocki wrote:
>> On 04/08/2013 11:57 AM, Kukjin Kim wrote:
[...]
> 
> Sigh.  This stuff looks rather screwed up now:
> 
> $ grep -B1 'ENTRY.*do_suspend' arch/arm/mm/proc*.S
> arch/arm/mm/proc-arm920.S-#ifdef CONFIG_PM_SLEEP
> arch/arm/mm/proc-arm920.S:ENTRY(cpu_arm920_do_suspend)
> --
> arch/arm/mm/proc-arm926.S-#ifdef CONFIG_PM_SLEEP
> arch/arm/mm/proc-arm926.S:ENTRY(cpu_arm926_do_suspend)
> --
> arch/arm/mm/proc-mohawk.S-#ifdef CONFIG_PM_SLEEP
> arch/arm/mm/proc-mohawk.S:ENTRY(cpu_mohawk_do_suspend)
> --
> arch/arm/mm/proc-sa1100.S-#ifdef CONFIG_PM_SLEEP
> arch/arm/mm/proc-sa1100.S:ENTRY(cpu_sa1100_do_suspend)
> --
> arch/arm/mm/proc-v6.S-#ifdef CONFIG_PM_SLEEP
> arch/arm/mm/proc-v6.S:ENTRY(cpu_v6_do_suspend)
> --
> arch/arm/mm/proc-v7.S-#ifdef CONFIG_ARM_CPU_SUSPEND
> arch/arm/mm/proc-v7.S:ENTRY(cpu_v7_do_suspend)
> --
> arch/arm/mm/proc-xsc3.S-#ifdef CONFIG_PM_SLEEP
> arch/arm/mm/proc-xsc3.S:ENTRY(cpu_xsc3_do_suspend)
> --
> arch/arm/mm/proc-xscale.S-#ifdef CONFIG_PM_SLEEP
> arch/arm/mm/proc-xscale.S:ENTRY(cpu_xscale_do_suspend)
> 
> Now, CONFIG_PM_SLEEP is fine if this stuff only ever gets used when PM_SLEEP
> is enabled - that's what it was designed for in the first place.  However,
> as we can see from the earlier patches in this thread, the cpu_suspend
> stuff is being selected when PM is enabled (which is arguably wrong), and

Yes, presumably this needs to be cleaned up. I was considering replacing
CONFIG_PM with CONFIG_PM_SLEEP, but that might involve some not trivial
changes. I'm going to have a look at it eventually.

> also in some cases when CPU_IDLE is enabled.
> 
> Therefore, making this code depend on ARM_CPU_SUSPEND seems sensible.
> However, So, how did proc-v7.S and only that file end up doing something
> different?
> 
> commit 15e0d9e37c7fe9711b60f47221c394d45553ad8c
> Author: Arnd Bergmann <arnd at arndb.de>
> Date:   Sat Oct 1 21:09:39 2011 +0200
> 
>     ARM: pm: let platforms select cpu_suspend support
> 
>     Support for the cpu_suspend functions is only built-in
>     when CONFIG_PM_SLEEP is enabled, but omap3/4, exynos4
>     and pxa always call cpu_suspend when CONFIG_PM is enabled.
> 
>     Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> 
> ...
> diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
> index a30e785..591accd 100644
> --- a/arch/arm/mm/proc-v7.S
> +++ b/arch/arm/mm/proc-v7.S
> @@ -217,7 +217,7 @@ ENDPROC(cpu_v7_set_pte_ext)
>  /* Suspend/resume support: derived from arch/arm/mach-s5pv210/sleep.S */
>  .globl cpu_v7_suspend_size
>  .equ   cpu_v7_suspend_size, 4 * 9
> -#ifdef CONFIG_PM_SLEEP
> +#ifdef CONFIG_ARM_CPU_SUSPEND
>  ENTRY(cpu_v7_do_suspend)
> ...
> 
> As far as this commit goes, it looks sane at the time that it was written,
> but as soon as we have *any* other selections of ARM_CPU_SUSPEND, the
> whole idea becomes extremely fragile - hence the reason for your build
> errors.
> 
> Moreover, with the above commit, there is _no_ sense what so ever in not
> applying the same change to all proc-*.S files, thereby entirely avoiding
> this fragility.  I would argue that the original commit should have made
> the same change to _all_ proc-*.S files.
> 
> Let's do the job properly - hence this is now queued for -rc:

Thanks, that seems a most reasonable fix. I was considering something like
that, just was afraid a bit to do this wide change and that it might cause
some other issues. Anyway that looks fine.

> 8<===
> From: Russell King <rmk+kernel at arm.linux.org.uk>
> Subject: [PATCH] ARM: Do 15e0d9e37c (ARM: pm: let platforms select cpu_suspend support) properly
> 
> Let's do the changes properly and fix the same problem everywhere, not
> just for one case.
> 
> Cc: <stable at vger.kernel.org> # kernels containing 15e0d9e37c7fe or equivalent
> Signed-off-by: Russell King <rmk+kernel at arm.linux.org.uk>
> ---
>  arch/arm/mm/proc-arm920.S |    2 +-
>  arch/arm/mm/proc-arm926.S |    2 +-
>  arch/arm/mm/proc-mohawk.S |    2 +-
>  arch/arm/mm/proc-sa1100.S |    2 +-
>  arch/arm/mm/proc-v6.S     |    2 +-
>  arch/arm/mm/proc-xsc3.S   |    2 +-
>  arch/arm/mm/proc-xscale.S |    2 +-
>  7 files changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/arch/arm/mm/proc-arm920.S b/arch/arm/mm/proc-arm920.S
> index 2c3b942..2556cf1 100644
> --- a/arch/arm/mm/proc-arm920.S
> +++ b/arch/arm/mm/proc-arm920.S
> @@ -387,7 +387,7 @@ ENTRY(cpu_arm920_set_pte_ext)
>  /* Suspend/resume support: taken from arch/arm/plat-s3c24xx/sleep.S */
>  .globl	cpu_arm920_suspend_size
>  .equ	cpu_arm920_suspend_size, 4 * 3
> -#ifdef CONFIG_PM_SLEEP
> +#ifdef CONFIG_ARM_CPU_SUSPEND
>  ENTRY(cpu_arm920_do_suspend)
>  	stmfd	sp!, {r4 - r6, lr}
>  	mrc	p15, 0, r4, c13, c0, 0	@ PID
[...]


From vladimir.danushevsky at oracle.com  Mon Apr  8 11:11:33 2013
From: vladimir.danushevsky at oracle.com (Vladimir Danushevsky)
Date: Mon, 8 Apr 2013 11:11:33 -0400
Subject: [PATCH] Report double word access atomicity on LPAE enabled
 targets through AUXV
In-Reply-To: <20130408132107.GF17476@mudshark.cambridge.arm.com>
References: <C3FF039D-7DE3-4A99-8317-789094095D8B@oracle.com>
 <20130408132107.GF17476@mudshark.cambridge.arm.com>
Message-ID: <86662A8F-1B9A-477E-8D2B-BEA30C1A4F18@oracle.com>


On Apr 8, 2013, at 9:21 AM, Will Deacon wrote:

> On Mon, Apr 08, 2013 at 01:34:28PM +0100, Vladimir Danushevsky wrote:
>> From: Vladimir Danushevsky <vladidan at oracle.com>
>> 
>> Hi All,
> 
> Hello,
> 
>> One of the indirect LPAE features in a single-copy atomicity of LDRD/STRD instructions. This information is useful for some dynamic code generating applications (e.g. JIT compilers) to produce a more efficient access mechanism to atomic/volatile operands. 
>> 
>> The feature is part of the design scheme therefore it's not related to the platform configuration i.e. whether CONFIG_ARM_LPAE is enabled or not.
>> 
>> The patch exposes that information through hwcap entry of an Auxiliary Vector.
> 
> Hmm, your commit text and patch format are both completely mangled.
> Furthermore, you've taken your patch against a -stable kernel, rather than
> the latest mainline release, so it doesn't apply anymore anyway.

Apologize for mutilating the patch text/body. My first post.

> 
> However, I see what you're trying to do, and I've recently made use of this
> in our atomic64 implementation so that we avoid the exclusive instructions
> for atomic64_{read,set}.
> 
>> --- linux-3.8.4_vanilla/arch/arm/kernel/setup.c 2013-03-20 16:11:19.000000000 -0400
>> 
>> +++ linux-3.8.4/arch/arm/kernel/setup.c 2013-04-03 15:42:31.580525201 -0400
>> 
>> @@ -487,6 +487,10 @@ static void __init setup_processor(void)
>> 
>>        elf_hwcap &= ~HWCAP_THUMB;
>> 
>> #endif
>> 
>> 
>> +        /* check LPAE presence */ 
>> 
>> +        if (((read_cpuid_ext(CPUID_EXT_MMFR3) >> 28) & 0xf) > 0)
>> 
>> +          elf_hwcap |= HWCAP_ATOMICD;
> 
> This is broken -- you're checking for supersection support (why?) rather
> than checking the vmsa field in MMFR0.
> 
> How about something like the patch below instead?

The below patch is indeed more correct than the one originally suggested as long as MMFR0.VMSA values continue to represent an accumulating list of features (i.e. new supported values also imply long page format) which is probably true.

Thanks,
Vlad 

> 
> Will
> 
> --->8
> 
> diff --git a/arch/arm/include/uapi/asm/hwcap.h b/arch/arm/include/uapi/asm/hwcap.h
> index 3688fd1..ecf0c6f 100644
> --- a/arch/arm/include/uapi/asm/hwcap.h
> +++ b/arch/arm/include/uapi/asm/hwcap.h
> @@ -25,6 +25,7 @@
> #define HWCAP_IDIVT    (1 << 18)
> #define HWCAP_VFPD32   (1 << 19)       /* set if VFP has 32 regs (not 16) */
> #define HWCAP_IDIV     (HWCAP_IDIVA | HWCAP_IDIVT)
> +#define HWCAP_ATOMICD  (1 << 20)
> 
> 
> #endif /* _UAPI__ASMARM_HWCAP_H */
> diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> index d343a6c..cae7b9e 100644
> --- a/arch/arm/kernel/setup.c
> +++ b/arch/arm/kernel/setup.c
> @@ -355,7 +355,7 @@ void __init early_print(const char *str, ...)
> 
> static void __init cpuid_init_hwcaps(void)
> {
> -       unsigned int divide_instrs;
> +       unsigned int divide_instrs, vmsa;
> 
>        if (cpu_architecture() < CPU_ARCH_ARMv7)
>                return;
> @@ -368,6 +368,11 @@ static void __init cpuid_init_hwcaps(void)
>        case 1:
>                elf_hwcap |= HWCAP_IDIVT;
>        }
> +
> +       /* LPAE implies atomic ldrd/strd instructions */
> +       vmsa = (read_cpuid_ext(CPUID_EXT_MMFR0) & 0xf) >> 0;
> +       if (vmsa >= 5)
> +               elf_hwcap |= HWCAP_ATOMICD;
> }
> 
> static void __init feat_v6_fixup(void)
> @@ -864,6 +869,7 @@ static const char *hwcap_str[] = {
>        "vfpv4",
>        "idiva",
>        "idivt",
> +       "atomicd",
>        NULL
> };
> 



From linux at arm.linux.org.uk  Mon Apr  8 11:20:42 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Mon, 8 Apr 2013 16:20:42 +0100
Subject: [PATCH] ARM: makefile: add tuning options for Armada 370/XP
In-Reply-To: <20130406192957.GQ11459@1wt.eu>
References: <20130406192957.GQ11459@1wt.eu>
Message-ID: <20130408152042.GM17995@n2100.arm.linux.org.uk>

On Sat, Apr 06, 2013 at 09:29:57PM +0200, Willy Tarreau wrote:
> diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> index 15747d9..7dd5418 100644
> --- a/arch/arm/Makefile
> +++ b/arch/arm/Makefile
> @@ -93,6 +93,7 @@ tune-$(CONFIG_CPU_XSC3)		:=$(call cc-option,-mtune=xscale,-mtune=strongarm110) -
>  tune-$(CONFIG_CPU_FEROCEON)	:=$(call cc-option,-mtune=marvell-f,-mtune=xscale)
>  tune-$(CONFIG_CPU_V6)		:=$(call cc-option,-mtune=arm1136j-s,-mtune=strongarm)
>  tune-$(CONFIG_CPU_V6K)		:=$(call cc-option,-mtune=arm1136j-s,-mtune=strongarm)
> +tune-$(CONFIG_MACH_ARMADA_370_XP)	:=$(call cc-option,-mcpu=marvell-pj4,-mtune=xscale)

Do not do this.  This is not how these options work.  Look at all the
above - they all use -mtune=.

The reason for this is that we want to control which instructions are
used (-march=) independently of how the instructions are scheduled
(-mtune=).

Using -mcpu= influences both of those in an adverse way - it can enable
instructions which are not present on other CPUs in the same kernel.

So, the use of -mcpu= is not permitted in the kernel.  Instead, use
-march= and -mtune= in an appropriate manner to achieve your goal.


From lee.jones at linaro.org  Mon Apr  8 11:23:07 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Mon,  8 Apr 2013 16:23:07 +0100
Subject: [PATCH 1/5] ARM: ux500: Move DMA40 platform data includes file out to
 include/
Message-ID: <1365434591-21569-1-git-send-email-lee.jones@linaro.org>

The pin names for DB8500 based platforms need to be moved out of
ux500 platform data and into the new proper location in include/
linux/platform_data/. This way we an reference them from other
external locations, such as the main DMA50 driver(s).

Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/mach-ux500/board-mop500-audio.c                            |    2 +-
 arch/arm/mach-ux500/board-mop500-sdi.c                              |    2 +-
 arch/arm/mach-ux500/board-mop500.c                                  |    2 +-
 arch/arm/mach-ux500/cpu-db8500.c                                    |    2 +-
 arch/arm/mach-ux500/devices-db8500.c                                |    2 +-
 drivers/dma/ste_dma40.c                                             |    1 +
 .../linux/platform_data/dma-ste-dma40-db8500.h                      |    3 +--
 7 files changed, 7 insertions(+), 7 deletions(-)
 rename arch/arm/mach-ux500/ste-dma40-db8500.h => include/linux/platform_data/dma-ste-dma40-db8500.h (98%)

diff --git a/arch/arm/mach-ux500/board-mop500-audio.c b/arch/arm/mach-ux500/board-mop500-audio.c
index 7209db7..1f8c6e4 100644
--- a/arch/arm/mach-ux500/board-mop500-audio.c
+++ b/arch/arm/mach-ux500/board-mop500-audio.c
@@ -9,13 +9,13 @@
 #include <linux/gpio.h>
 #include <linux/platform_data/pinctrl-nomadik.h>
 #include <linux/platform_data/dma-ste-dma40.h>
+#include <linux/platform_data/dma-ste-dma40-db8500.h>
 
 #include <mach/devices.h>
 #include <mach/hardware.h>
 #include <mach/irqs.h>
 #include <mach/msp.h>
 
-#include "ste-dma40-db8500.h"
 #include "board-mop500.h"
 #include "devices-db8500.h"
 #include "pins-db8500.h"
diff --git a/arch/arm/mach-ux500/board-mop500-sdi.c b/arch/arm/mach-ux500/board-mop500-sdi.c
index 7f2cb6c..e4c0a74 100644
--- a/arch/arm/mach-ux500/board-mop500-sdi.c
+++ b/arch/arm/mach-ux500/board-mop500-sdi.c
@@ -12,6 +12,7 @@
 #include <linux/mmc/host.h>
 #include <linux/platform_device.h>
 #include <linux/platform_data/dma-ste-dma40.h>
+#include <linux/platform_data/dma-ste-dma40-db8500.h>
 
 #include <asm/mach-types.h>
 #include <mach/devices.h>
@@ -19,7 +20,6 @@
 
 #include "devices-db8500.h"
 #include "board-mop500.h"
-#include "ste-dma40-db8500.h"
 
 /*
  * v2 has a new version of this block that need to be forced, the number found
diff --git a/arch/arm/mach-ux500/board-mop500.c b/arch/arm/mach-ux500/board-mop500.c
index 87d2d7b..dd95399 100644
--- a/arch/arm/mach-ux500/board-mop500.c
+++ b/arch/arm/mach-ux500/board-mop500.c
@@ -38,6 +38,7 @@
 #include <linux/pinctrl/consumer.h>
 #include <linux/platform_data/pinctrl-nomadik.h>
 #include <linux/platform_data/dma-ste-dma40.h>
+#include <linux/platform_data/dma-ste-dma40-db8500.h>
 
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
@@ -48,7 +49,6 @@
 #include <mach/irqs.h>
 #include <linux/platform_data/crypto-ux500.h>
 
-#include "ste-dma40-db8500.h"
 #include "devices-db8500.h"
 #include "board-mop500.h"
 #include "board-mop500-regulators.h"
diff --git a/arch/arm/mach-ux500/cpu-db8500.c b/arch/arm/mach-ux500/cpu-db8500.c
index e027865..8553e14 100644
--- a/arch/arm/mach-ux500/cpu-db8500.c
+++ b/arch/arm/mach-ux500/cpu-db8500.c
@@ -22,6 +22,7 @@
 #include <linux/of_platform.h>
 #include <linux/regulator/machine.h>
 #include <linux/platform_data/pinctrl-nomadik.h>
+#include <linux/platform_data/dma-ste-dma40-db8500.h>
 #include <linux/random.h>
 
 #include <asm/pmu.h>
@@ -35,7 +36,6 @@
 #include <mach/irqs.h>
 
 #include "devices-db8500.h"
-#include "ste-dma40-db8500.h"
 
 #include "board-mop500.h"
 #include "id.h"
diff --git a/arch/arm/mach-ux500/devices-db8500.c b/arch/arm/mach-ux500/devices-db8500.c
index afa5b04..a7c0e521 100644
--- a/arch/arm/mach-ux500/devices-db8500.c
+++ b/arch/arm/mach-ux500/devices-db8500.c
@@ -13,6 +13,7 @@
 #include <linux/amba/bus.h>
 #include <linux/amba/pl022.h>
 #include <linux/platform_data/dma-ste-dma40.h>
+#include <linux/platform_data/dma-ste-dma40-db8500.h>
 #include <linux/mfd/dbx500-prcmu.h>
 
 #include <mach/hardware.h>
@@ -20,7 +21,6 @@
 #include <mach/irqs.h>
 
 #include "devices-db8500.h"
-#include "ste-dma40-db8500.h"
 
 static struct resource dma40_resources[] = {
 	[0] = {
diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index 1734fee..35f97d2 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -20,6 +20,7 @@
 #include <linux/amba/bus.h>
 #include <linux/regulator/consumer.h>
 #include <linux/platform_data/dma-ste-dma40.h>
+#include <linux/platform_data/dma-ste-dma40-db8500.h>
 
 #include "dmaengine.h"
 #include "ste_dma40_ll.h"
diff --git a/arch/arm/mach-ux500/ste-dma40-db8500.h b/include/linux/platform_data/dma-ste-dma40-db8500.h
similarity index 98%
rename from arch/arm/mach-ux500/ste-dma40-db8500.h
rename to include/linux/platform_data/dma-ste-dma40-db8500.h
index a616419..f538917 100644
--- a/arch/arm/mach-ux500/ste-dma40-db8500.h
+++ b/include/linux/platform_data/dma-ste-dma40-db8500.h
@@ -1,8 +1,7 @@
 /*
- * arch/arm/mach-ux500/ste_dma40_db8500.h
  * DB8500-SoC-specific configuration for DMA40
  *
- * Copyright (C) ST-Ericsson 2007-2010
+ * Copyright (C) ST-Ericsson 2007-2013
  * License terms: GNU General Public License (GPL) version 2
  * Author: Per Friden <per.friden at stericsson.com>
  * Author: Jonas Aaberg <jonas.aberg at stericsson.com>
-- 
1.7.10.4



From lee.jones at linaro.org  Mon Apr  8 11:23:08 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Mon,  8 Apr 2013 16:23:08 +0100
Subject: [PATCH 2/5] dmaengine: ste_dma40: Assign memcpy channels in the driver
In-Reply-To: <1365434591-21569-1-git-send-email-lee.jones@linaro.org>
References: <1365434591-21569-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1365434591-21569-2-git-send-email-lee.jones@linaro.org>

The channels reserved for memcpy are the same for all currently
supported platforms. With this in mind, we can ease the platform
data passing requirement by moving these assignments out from
platform code and place them directly into the driver.

Cc: Vinod Koul <vinod.koul at intel.com>
Cc: Dan Williams <djbw at fb.com>
Cc: Per Forlin <per.forlin at stericsson.com>
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/mach-ux500/devices-db8500.c        |   12 ------------
 drivers/dma/ste_dma40.c                     |   19 ++++++++++++++-----
 include/linux/platform_data/dma-ste-dma40.h |    4 ----
 3 files changed, 14 insertions(+), 21 deletions(-)

diff --git a/arch/arm/mach-ux500/devices-db8500.c b/arch/arm/mach-ux500/devices-db8500.c
index a7c0e521..2a63c19 100644
--- a/arch/arm/mach-ux500/devices-db8500.c
+++ b/arch/arm/mach-ux500/devices-db8500.c
@@ -146,22 +146,10 @@ static const dma_addr_t dma40_rx_map[DB8500_DMA_NR_DEV] = {
 	[DB8500_DMA_DEV48_CAC1_RX] = U8500_CRYP1_BASE + CRYP1_RX_REG_OFFSET,
 };
 
-/* Reserved event lines for memcpy only */
-static int dma40_memcpy_event[] = {
-	DB8500_DMA_MEMCPY_TX_0,
-	DB8500_DMA_MEMCPY_TX_1,
-	DB8500_DMA_MEMCPY_TX_2,
-	DB8500_DMA_MEMCPY_TX_3,
-	DB8500_DMA_MEMCPY_TX_4,
-	DB8500_DMA_MEMCPY_TX_5,
-};
-
 static struct stedma40_platform_data dma40_plat_data = {
 	.dev_len = DB8500_DMA_NR_DEV,
 	.dev_rx = dma40_rx_map,
 	.dev_tx = dma40_tx_map,
-	.memcpy = dma40_memcpy_event,
-	.memcpy_len = ARRAY_SIZE(dma40_memcpy_event),
 	.memcpy_conf_phy = &dma40_memcpy_conf_phy,
 	.memcpy_conf_log = &dma40_memcpy_conf_log,
 	.disabled_channels = {-1},
diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index 35f97d2..3ae5f99 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -56,6 +56,16 @@
 
 #define MAX(a, b) (((a) < (b)) ? (b) : (a))
 
+/* Reserved event lines for memcpy only. */
+static int dma40_memcpy_channels[] = {
+	DB8500_DMA_MEMCPY_TX_0,
+	DB8500_DMA_MEMCPY_TX_1,
+	DB8500_DMA_MEMCPY_TX_2,
+	DB8500_DMA_MEMCPY_TX_3,
+	DB8500_DMA_MEMCPY_TX_4,
+	DB8500_DMA_MEMCPY_TX_5,
+};
+
 /**
  * enum 40_command - The different commands and/or statuses.
  *
@@ -2015,8 +2025,7 @@ static int d40_config_memcpy(struct d40_chan *d40c)
 	if (dma_has_cap(DMA_MEMCPY, cap) && !dma_has_cap(DMA_SLAVE, cap)) {
 		d40c->dma_cfg = *d40c->base->plat_data->memcpy_conf_log;
 		d40c->dma_cfg.src_dev_type = STEDMA40_DEV_SRC_MEMORY;
-		d40c->dma_cfg.dst_dev_type = d40c->base->plat_data->
-			memcpy[d40c->chan.chan_id];
+		d40c->dma_cfg.dst_dev_type = dma40_memcpy_channels[d40c->chan.chan_id];
 
 	} else if (dma_has_cap(DMA_MEMCPY, cap) &&
 		   dma_has_cap(DMA_SLAVE, cap)) {
@@ -2928,7 +2937,7 @@ static int __init d40_dmaengine_init(struct d40_base *base,
 	}
 
 	d40_chan_init(base, &base->dma_memcpy, base->log_chans,
-		      base->num_log_chans, base->plat_data->memcpy_len);
+		      base->num_log_chans, ARRAY_SIZE(dma40_memcpy_channels));
 
 	dma_cap_zero(base->dma_memcpy.cap_mask);
 	dma_cap_set(DMA_MEMCPY, base->dma_memcpy.cap_mask);
@@ -3216,7 +3225,7 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
 			num_log_chans++;
 
 	base = kzalloc(ALIGN(sizeof(struct d40_base), 4) +
-		       (num_phy_chans + num_log_chans + plat_data->memcpy_len) *
+		       (num_phy_chans + num_log_chans + ARRAY_SIZE(dma40_memcpy_channels)) *
 		       sizeof(struct d40_chan), GFP_KERNEL);
 
 	if (base == NULL) {
@@ -3277,7 +3286,7 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
 	if (!base->lookup_phy_chans)
 		goto failure;
 
-	if (num_log_chans + plat_data->memcpy_len) {
+	if (num_log_chans + ARRAY_SIZE(dma40_memcpy_channels)) {
 		/*
 		 * The max number of logical channels are event lines for all
 		 * src devices and dst devices
diff --git a/include/linux/platform_data/dma-ste-dma40.h b/include/linux/platform_data/dma-ste-dma40.h
index 4b78101..a808784 100644
--- a/include/linux/platform_data/dma-ste-dma40.h
+++ b/include/linux/platform_data/dma-ste-dma40.h
@@ -141,8 +141,6 @@ struct stedma40_chan_cfg {
  * @dev_len: length of dev_tx and dev_rx
  * @dev_tx: mapping between destination event line and io address
  * @dev_rx: mapping between source event line and io address
- * @memcpy: list of memcpy event lines
- * @memcpy_len: length of memcpy
  * @memcpy_conf_phy: default configuration of physical channel memcpy
  * @memcpy_conf_log: default configuration of logical channel memcpy
  * @disabled_channels: A vector, ending with -1, that marks physical channels
@@ -162,8 +160,6 @@ struct stedma40_platform_data {
 	u32				 dev_len;
 	const dma_addr_t		*dev_tx;
 	const dma_addr_t		*dev_rx;
-	int				*memcpy;
-	u32				 memcpy_len;
 	struct stedma40_chan_cfg	*memcpy_conf_phy;
 	struct stedma40_chan_cfg	*memcpy_conf_log;
 	int				 disabled_channels[STEDMA40_MAX_PHYS];
-- 
1.7.10.4



From lee.jones at linaro.org  Mon Apr  8 11:23:09 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Mon,  8 Apr 2013 16:23:09 +0100
Subject: [PATCH 3/5] dmaengine: ste_dma40: Move default memcpy configs into
 the driver
In-Reply-To: <1365434591-21569-1-git-send-email-lee.jones@linaro.org>
References: <1365434591-21569-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1365434591-21569-3-git-send-email-lee.jones@linaro.org>

There are only two default memcpy configurations used for the DMA40
driver; one for physical memcpy and one for logical memcpy. Instead
of invariably passing the same configurations though platform data,
we're moving them into the driver instead.

Cc: Vinod Koul <vinod.koul at intel.com>
Cc: Dan Williams <djbw at fb.com>
Cc: Per Forlin <per.forlin at stericsson.com>
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/mach-ux500/devices-db8500.c        |   28 -----------------------
 drivers/dma/ste_dma40.c                     |   32 +++++++++++++++++++++++++--
 include/linux/platform_data/dma-ste-dma40.h |    4 ----
 3 files changed, 30 insertions(+), 34 deletions(-)

diff --git a/arch/arm/mach-ux500/devices-db8500.c b/arch/arm/mach-ux500/devices-db8500.c
index 2a63c19..c7da6e1 100644
--- a/arch/arm/mach-ux500/devices-db8500.c
+++ b/arch/arm/mach-ux500/devices-db8500.c
@@ -42,32 +42,6 @@ static struct resource dma40_resources[] = {
 	}
 };
 
-/* Default configuration for physcial memcpy */
-struct stedma40_chan_cfg dma40_memcpy_conf_phy = {
-	.mode = STEDMA40_MODE_PHYSICAL,
-	.dir = STEDMA40_MEM_TO_MEM,
-
-	.src_info.data_width = STEDMA40_BYTE_WIDTH,
-	.src_info.psize = STEDMA40_PSIZE_PHY_1,
-	.src_info.flow_ctrl = STEDMA40_NO_FLOW_CTRL,
-
-	.dst_info.data_width = STEDMA40_BYTE_WIDTH,
-	.dst_info.psize = STEDMA40_PSIZE_PHY_1,
-	.dst_info.flow_ctrl = STEDMA40_NO_FLOW_CTRL,
-};
-/* Default configuration for logical memcpy */
-struct stedma40_chan_cfg dma40_memcpy_conf_log = {
-	.dir = STEDMA40_MEM_TO_MEM,
-
-	.src_info.data_width = STEDMA40_BYTE_WIDTH,
-	.src_info.psize = STEDMA40_PSIZE_LOG_1,
-	.src_info.flow_ctrl = STEDMA40_NO_FLOW_CTRL,
-
-	.dst_info.data_width = STEDMA40_BYTE_WIDTH,
-	.dst_info.psize = STEDMA40_PSIZE_LOG_1,
-	.dst_info.flow_ctrl = STEDMA40_NO_FLOW_CTRL,
-};
-
 /*
  * Mapping between destination event lines and physical device address.
  * The event line is tied to a device and therefore the address is constant.
@@ -150,8 +124,6 @@ static struct stedma40_platform_data dma40_plat_data = {
 	.dev_len = DB8500_DMA_NR_DEV,
 	.dev_rx = dma40_rx_map,
 	.dev_tx = dma40_tx_map,
-	.memcpy_conf_phy = &dma40_memcpy_conf_phy,
-	.memcpy_conf_log = &dma40_memcpy_conf_log,
 	.disabled_channels = {-1},
 };
 
diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index 3ae5f99..ecca492 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -66,6 +66,34 @@ static int dma40_memcpy_channels[] = {
 	DB8500_DMA_MEMCPY_TX_5,
 };
 
+/* Default configuration for physcial memcpy */
+struct stedma40_chan_cfg dma40_memcpy_conf_phy = {
+	.mode = STEDMA40_MODE_PHYSICAL,
+	.dir = STEDMA40_MEM_TO_MEM,
+
+	.src_info.data_width = STEDMA40_BYTE_WIDTH,
+	.src_info.psize = STEDMA40_PSIZE_PHY_1,
+	.src_info.flow_ctrl = STEDMA40_NO_FLOW_CTRL,
+
+	.dst_info.data_width = STEDMA40_BYTE_WIDTH,
+	.dst_info.psize = STEDMA40_PSIZE_PHY_1,
+	.dst_info.flow_ctrl = STEDMA40_NO_FLOW_CTRL,
+};
+
+/* Default configuration for logical memcpy */
+struct stedma40_chan_cfg dma40_memcpy_conf_log = {
+	.mode = STEDMA40_MODE_LOGICAL,
+	.dir = STEDMA40_MEM_TO_MEM,
+
+	.src_info.data_width = STEDMA40_BYTE_WIDTH,
+	.src_info.psize = STEDMA40_PSIZE_LOG_1,
+	.src_info.flow_ctrl = STEDMA40_NO_FLOW_CTRL,
+
+	.dst_info.data_width = STEDMA40_BYTE_WIDTH,
+	.dst_info.psize = STEDMA40_PSIZE_LOG_1,
+	.dst_info.flow_ctrl = STEDMA40_NO_FLOW_CTRL,
+};
+
 /**
  * enum 40_command - The different commands and/or statuses.
  *
@@ -2023,13 +2051,13 @@ static int d40_config_memcpy(struct d40_chan *d40c)
 	dma_cap_mask_t cap = d40c->chan.device->cap_mask;
 
 	if (dma_has_cap(DMA_MEMCPY, cap) && !dma_has_cap(DMA_SLAVE, cap)) {
-		d40c->dma_cfg = *d40c->base->plat_data->memcpy_conf_log;
+		d40c->dma_cfg = dma40_memcpy_conf_log;
 		d40c->dma_cfg.src_dev_type = STEDMA40_DEV_SRC_MEMORY;
 		d40c->dma_cfg.dst_dev_type = dma40_memcpy_channels[d40c->chan.chan_id];
 
 	} else if (dma_has_cap(DMA_MEMCPY, cap) &&
 		   dma_has_cap(DMA_SLAVE, cap)) {
-		d40c->dma_cfg = *d40c->base->plat_data->memcpy_conf_phy;
+		d40c->dma_cfg = dma40_memcpy_conf_phy;
 	} else {
 		chan_err(d40c, "No memcpy\n");
 		return -EINVAL;
diff --git a/include/linux/platform_data/dma-ste-dma40.h b/include/linux/platform_data/dma-ste-dma40.h
index a808784..869c571 100644
--- a/include/linux/platform_data/dma-ste-dma40.h
+++ b/include/linux/platform_data/dma-ste-dma40.h
@@ -141,8 +141,6 @@ struct stedma40_chan_cfg {
  * @dev_len: length of dev_tx and dev_rx
  * @dev_tx: mapping between destination event line and io address
  * @dev_rx: mapping between source event line and io address
- * @memcpy_conf_phy: default configuration of physical channel memcpy
- * @memcpy_conf_log: default configuration of logical channel memcpy
  * @disabled_channels: A vector, ending with -1, that marks physical channels
  * that are for different reasons not available for the driver.
  * @soft_lli_chans: A vector, that marks physical channels will use LLI by SW
@@ -160,8 +158,6 @@ struct stedma40_platform_data {
 	u32				 dev_len;
 	const dma_addr_t		*dev_tx;
 	const dma_addr_t		*dev_rx;
-	struct stedma40_chan_cfg	*memcpy_conf_phy;
-	struct stedma40_chan_cfg	*memcpy_conf_log;
 	int				 disabled_channels[STEDMA40_MAX_PHYS];
 	int				*soft_lli_chans;
 	int				 num_of_soft_lli_chans;
-- 
1.7.10.4



From lee.jones at linaro.org  Mon Apr  8 11:23:10 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Mon,  8 Apr 2013 16:23:10 +0100
Subject: [PATCH 4/5] dmaengine: ste_dma40: Only configure a channel during a
 configure request
In-Reply-To: <1365434591-21569-1-git-send-email-lee.jones@linaro.org>
References: <1365434591-21569-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1365434591-21569-4-git-send-email-lee.jones@linaro.org>

According to the DMA documentation allocating a channel and configuring
it are two separate actions. By moving the configuration code into the
correct code path we lighten the burden on the information required to
successfully allocate a channel.

Cc: Vinod Koul <vinod.koul at intel.com>
Cc: Dan Williams <djbw at fb.com>
Cc: Per Forlin <per.forlin at stericsson.com>
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 drivers/dma/ste_dma40.c |    6 ------
 1 file changed, 6 deletions(-)

diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index ecca492..3543ea4 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -2471,16 +2471,10 @@ static int d40_alloc_chan_resources(struct dma_chan *chan)
 	}
 
 	pm_runtime_get_sync(d40c->base->dev);
-	/* Fill in basic CFG register values */
-	d40_phy_cfg(&d40c->dma_cfg, &d40c->src_def_cfg,
-		    &d40c->dst_def_cfg, chan_is_logical(d40c));
 
 	d40_set_prio_realtime(d40c);
 
 	if (chan_is_logical(d40c)) {
-		d40_log_cfg(&d40c->dma_cfg,
-			    &d40c->log_def.lcsp1, &d40c->log_def.lcsp3);
-
 		if (d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_MEM)
 			d40c->lcpa = d40c->base->lcpa_base +
 				d40c->dma_cfg.src_dev_type * D40_LCPA_CHAN_SIZE;
-- 
1.7.10.4



From lee.jones at linaro.org  Mon Apr  8 11:23:11 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Mon,  8 Apr 2013 16:23:11 +0100
Subject: [PATCH 5/5] dmaengine: ste_dma40: Move LCPA allocation and real-time
 config
In-Reply-To: <1365434591-21569-1-git-send-email-lee.jones@linaro.org>
References: <1365434591-21569-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1365434591-21569-5-git-send-email-lee.jones@linaro.org>

There are various pieces of configuration which do not need to happen
until after a channel is allocated. Here we move some of these so they're
dealt with when it's time to configure the channel, rather than allocate
it.

Cc: Vinod Koul <vinod.koul at intel.com>
Cc: Dan Williams <djbw at fb.com>
Cc: Per Forlin <per.forlin at stericsson.com>
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 drivers/dma/ste_dma40.c |   24 ++++++++++++------------
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index 3543ea4..8a71bf6 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -2472,18 +2472,6 @@ static int d40_alloc_chan_resources(struct dma_chan *chan)
 
 	pm_runtime_get_sync(d40c->base->dev);
 
-	d40_set_prio_realtime(d40c);
-
-	if (chan_is_logical(d40c)) {
-		if (d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_MEM)
-			d40c->lcpa = d40c->base->lcpa_base +
-				d40c->dma_cfg.src_dev_type * D40_LCPA_CHAN_SIZE;
-		else
-			d40c->lcpa = d40c->base->lcpa_base +
-				d40c->dma_cfg.dst_dev_type *
-				D40_LCPA_CHAN_SIZE + D40_LCPA_CHAN_DST_DELTA;
-	}
-
 	dev_dbg(chan2dev(d40c), "allocated %s channel (phy %d%s)\n",
 		 chan_is_logical(d40c) ? "logical" : "physical",
 		 d40c->phy_chan->num,
@@ -2830,6 +2818,18 @@ static int d40_set_runtime_config(struct dma_chan *chan,
 		d40_phy_cfg(cfg, &d40c->src_def_cfg,
 			    &d40c->dst_def_cfg, false);
 
+	d40_set_prio_realtime(d40c);
+
+	if (chan_is_logical(d40c)) {
+		if (cfg->dir == STEDMA40_PERIPH_TO_MEM)
+			d40c->lcpa = d40c->base->lcpa_base +
+				cfg->src_dev_type * D40_LCPA_CHAN_SIZE;
+		else
+			d40c->lcpa = d40c->base->lcpa_base +
+				cfg->dst_dev_type *
+				D40_LCPA_CHAN_SIZE + D40_LCPA_CHAN_DST_DELTA;
+	}
+
 	/* These settings will take precedence later */
 	d40c->runtime_addr = config_addr;
 	d40c->runtime_direction = config->direction;
-- 
1.7.10.4



From festevam at gmail.com  Mon Apr  8 11:26:04 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Mon, 8 Apr 2013 12:26:04 -0300
Subject: [PATCH 0/5] i.MX53 TVE clock patches
In-Reply-To: <1365432383-7787-1-git-send-email-p.zabel@pengutronix.de>
References: <1365432383-7787-1-git-send-email-p.zabel@pengutronix.de>
Message-ID: <CAOMZO5CjC4HEvZo7rqdN1inAz_=xif=5aANLPhB9oF_mygJeGg@mail.gmail.com>

Hi Phiipp,

On Mon, Apr 8, 2013 at 11:46 AM, Philipp Zabel <p.zabel at pengutronix.de> wrote:
> Hi,
>
> the first two are just cleanups, the following three patches are changes
> to the i.MX53 clock tree that are necessary to use the TVEv2 module as
> VGA output on the Freescale i.MX53-QSB or TQ MBa53 boards.

I would like to test this series on a mx53qsb.

Is the TVE driver available in some git tree?

Thanks,

Fabio Estevam


From ezequiel.garcia at free-electrons.com  Mon Apr  8 11:29:34 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Mon, 8 Apr 2013 12:29:34 -0300
Subject: [PATCH v4 0/5] Device Bus support for Marvell EBU SoC
In-Reply-To: <201304081617.31644.arnd@arndb.de>
References: <1365419194-20871-1-git-send-email-ezequiel.garcia@free-electrons.com>
 <201304081617.31644.arnd@arndb.de>
Message-ID: <20130408152933.GB877@localhost>

On Mon, Apr 08, 2013 at 04:17:31PM +0200, Arnd Bergmann wrote:
> On Monday 08 April 2013, Ezequiel Garcia wrote:
> >   * Rename devbus,dev-width to devbus,bus-width and changed the
> >     parameter value from bytes to bits: <8>, <16>, ...
> >     Suggested by Arnd Bergmann.
> > 
> >   * As suggested by Jason Gunthorpe and agreed by Arnd Bergmann.
> >     Reworked the whole devbus child chip-select device tree design.
> >     Now there's a separate devbus at addr DT node for each controller
> >     chip select. The impact of this is:
> >       1. Timing parameters now go into the parent node.
> >       2. There can only be one child per devbus node.
> > 
> >   * Remove unneeded bank-width parameter read.
> > 
> 
> Whole series:
> 
> Acked-by: Arnd Bergmann <arnd at arndb.de>
> 
> It may be nicer to use #address-cells=<2> for devbus device nodes now that
> each of them has only a 32 bit address space, but the current code is correct
> as well using a 64 bit notation.
> 

I'll probably be sending a v5 fixing this later.

@Jason Cooper:
How would you like to handle this, regarding the LPAE series?
Do you want me to rebase this devbus on top of that?

-- 
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com


From vladimir.danushevsky at oracle.com  Mon Apr  8 11:31:37 2013
From: vladimir.danushevsky at oracle.com (Vladimir Danushevsky)
Date: Mon, 8 Apr 2013 11:31:37 -0400
Subject: [PATCH] Report double word access atomicity on LPAE enabled
 targets through AUXV
In-Reply-To: <20130408142406.GL17995@n2100.arm.linux.org.uk>
References: <C3FF039D-7DE3-4A99-8317-789094095D8B@oracle.com>
 <20130408142406.GL17995@n2100.arm.linux.org.uk>
Message-ID: <225BED2C-F598-4EB8-8B32-D751E8D5EA04@oracle.com>


On Apr 8, 2013, at 10:24 AM, Russell King - ARM Linux wrote:

> On Mon, Apr 08, 2013 at 08:34:28AM -0400, Vladimir Danushevsky wrote:
>> From: Vladimir Danushevsky <vladidan at oracle.com>
> 
> Please don't obfuscate your email address like that - git won't parse it.
> 
>> Hi All,
> 
> We don't include such salutations in the commit message.
> 
I stand corrected for the comments above. Thanks.

>> One of the indirect LPAE features in a single-copy atomicity of LDRD/STRD
>> instructions. This information is useful for some dynamic code generating
>> applications (e.g. JIT compilers) to produce a more efficient access
>> mechanism to atomic/volatile operands.
>> 
>> The feature is part of the design scheme therefore it's not related to the
>> platform configuration i.e. whether CONFIG_ARM_LPAE is enabled or not.
>> 
>> The patch exposes that information through hwcap entry of an Auxiliary
>> Vector.
> 
> I think we're heading towards running out of hwcap bits to represent all
> these different features.  Not there yet, but after this we only have 11
> spare bits.

yes we will eventually run out of the bits, but until that time only user level features need to be exposed through AUXV i.e. LPAE or HYP should not interest an user application. 

> 
> Maybe we need to switch to a more x86-centric method where we report this
> stuff in /proc/cpuinfo, and userspace parses this information out.  If
> glibc already has code in there for x86, maybe we can reuse that?

Doesn't x86 still report first 32 bits of HWCAP in the AUXV?

> 
>> Signed-off-by: Vladimir Danushevsky <vladidan at oracle.com>
> 
> Again, don't obfuscate.

Noted. 

Thanks,
Vlad
> 
>> ---
> 
> diffstat?
> 
>> 
>> --- linux-3.8.4_vanilla/arch/arm/include/uapi/asm/hwcap.h       2013-03-20 16:11:19.000000000 -0400
>> 
>> +++ linux-3.8.4/arch/arm/include/uapi/asm/hwcap.h       2013-03-26 16:32:18.266043699 -0400
> 
> This double-line spacing makes this patch impossible to apply.
> 
>> +        /* check LPAE presence */ 
> 
> If it's worth a comment, it's worth making it a good comment.
>> 
>> +        if (((read_cpuid_ext(CPUID_EXT_MMFR3) >> 28) & 0xf) > 0)
>> 
>> +          elf_hwcap |= HWCAP_ATOMICD;
> 
> We use tabs for indentation, not two spaces.  Also, on the face of it
> ATOMICD isn't obvious what it means.  Maybe HWCAP_LDRDSTRD would be
> better - it's only one character longer and truely reflects what you're
> trying to report - the presence of these two instructions.



From will.deacon at arm.com  Mon Apr  8 11:31:32 2013
From: will.deacon at arm.com (Will Deacon)
Date: Mon, 8 Apr 2013 16:31:32 +0100
Subject: [PATCH] arm64: Fix task tracing
In-Reply-To: <5162D750.9050706@codeaurora.org>
References: <1365012061-31660-1-git-send-email-cov@codeaurora.org>
 <20130403180443.GB21167@mudshark.cambridge.arm.com>
 <5162D750.9050706@codeaurora.org>
Message-ID: <20130408153132.GQ17476@mudshark.cambridge.arm.com>

On Mon, Apr 08, 2013 at 03:42:24PM +0100, Christopher Covington wrote:
> On 04/03/2013 02:04 PM, Will Deacon wrote:
> > Hi Christopher,
> > 
> > On Wed, Apr 03, 2013 at 07:01:01PM +0100, Christopher Covington wrote:
> >> For accurate accounting call contextidr_thread_switch before a
> >> task is scheduled, rather than after.
> >>
> >> Signed-off-by: Christopher Covington <cov at codeaurora.org>
> >> ---
> >>  arch/arm64/kernel/process.c | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
> >> index 0337cdb..c2cc249 100644
> >> --- a/arch/arm64/kernel/process.c
> >> +++ b/arch/arm64/kernel/process.c
> >> @@ -311,11 +311,11 @@ struct task_struct *__switch_to(struct task_struct *prev,
> >>  	fpsimd_thread_switch(next);
> >>  	tls_thread_switch(next);
> >>  	hw_breakpoint_thread_switch(next);
> >> +	contextidr_thread_switch(next);
> >>  
> >>  	/* the actual thread switch */
> >>  	last = cpu_switch_to(prev, next);
> >>  
> >> -	contextidr_thread_switch(next);
> >>  	return last;
> >>  }
> > 
> > Catalin and I wondered about this and decided to go with the current
> > approach in case a debugger, in response to the contextidr write, decided to
> > go off and mine information about the *new* task using the sp.
> 
> The problem with the existing implementation is that it doesn't seem to
> compensate for how cpu_switch_to changes the stack pointer. Consider the
> following sequence.
> 
> cpu_switch_to(prev=A, next=B)
> cpu_switch_to(prev=B, next=C)
> cpu_switch_to(prev=C, next=A)
> 
> After the third call, using A's stack, next will be B, and its thread ID will
> be written to CONTEXTIDR. An easy way to see this in a simulator is to just
> instrument the code with some printk's.

Yes, but moving the call still isn't the right thing to do if we can avoid
it. How about making that contextidr_thread_switch take prev instead of
next?

Will


From marc.zyngier at arm.com  Mon Apr  8 11:36:38 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon,  8 Apr 2013 16:36:38 +0100
Subject: [PATCH v2 2/7] ARM: KVM: fix HYP mapping limitations around zero
In-Reply-To: <1365435403-29265-1-git-send-email-marc.zyngier@arm.com>
References: <1365435403-29265-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1365435403-29265-3-git-send-email-marc.zyngier@arm.com>

The current code for creating HYP mapping doesn't like to wrap
around zero, which prevents from mapping anything into the last
page of the virtual address space.

It doesn't take much effort to remove this limitation, making
the code more consistent with the rest of the kernel in the process.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm/kvm/mmu.c | 21 ++++++++++-----------
 1 file changed, 10 insertions(+), 11 deletions(-)

diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
index 3003321..96d61da 100644
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@ -131,11 +131,12 @@ static void create_hyp_pte_mappings(pmd_t *pmd, unsigned long start,
 	pte_t *pte;
 	unsigned long addr;
 
-	for (addr = start; addr < end; addr += PAGE_SIZE) {
+	addr = start;
+	do {
 		pte = pte_offset_kernel(pmd, addr);
 		kvm_set_pte(pte, pfn_pte(pfn, prot));
 		pfn++;
-	}
+	} while (addr += PAGE_SIZE, addr != end);
 }
 
 static int create_hyp_pmd_mappings(pud_t *pud, unsigned long start,
@@ -146,7 +147,8 @@ static int create_hyp_pmd_mappings(pud_t *pud, unsigned long start,
 	pte_t *pte;
 	unsigned long addr, next;
 
-	for (addr = start; addr < end; addr = next) {
+	addr = start;
+	do {
 		pmd = pmd_offset(pud, addr);
 
 		BUG_ON(pmd_sect(*pmd));
@@ -164,7 +166,7 @@ static int create_hyp_pmd_mappings(pud_t *pud, unsigned long start,
 
 		create_hyp_pte_mappings(pmd, addr, next, pfn, prot);
 		pfn += (next - addr) >> PAGE_SHIFT;
-	}
+	} while (addr = next, addr != end);
 
 	return 0;
 }
@@ -179,11 +181,10 @@ static int __create_hyp_mappings(pgd_t *pgdp,
 	unsigned long addr, next;
 	int err = 0;
 
-	if (start >= end)
-		return -EINVAL;
-
 	mutex_lock(&kvm_hyp_pgd_mutex);
-	for (addr = start & PAGE_MASK; addr < end; addr = next) {
+	addr = start & PAGE_MASK;
+	end = PAGE_ALIGN(end);
+	do {
 		pgd = pgdp + pgd_index(addr);
 		pud = pud_offset(pgd, addr);
 
@@ -202,7 +203,7 @@ static int __create_hyp_mappings(pgd_t *pgdp,
 		if (err)
 			goto out;
 		pfn += (next - addr) >> PAGE_SHIFT;
-	}
+	} while (addr = next, addr != end);
 out:
 	mutex_unlock(&kvm_hyp_pgd_mutex);
 	return err;
@@ -216,8 +217,6 @@ out:
  * The same virtual address as the kernel virtual address is also used
  * in Hyp-mode mapping (modulo HYP_PAGE_OFFSET) to the same underlying
  * physical pages.
- *
- * Note: Wrapping around zero in the "to" address is not supported.
  */
 int create_hyp_mappings(void *from, void *to)
 {
-- 
1.8.1.4




From marc.zyngier at arm.com  Mon Apr  8 11:36:37 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon,  8 Apr 2013 16:36:37 +0100
Subject: [PATCH v2 1/7] ARM: KVM: simplify HYP mapping population
In-Reply-To: <1365435403-29265-1-git-send-email-marc.zyngier@arm.com>
References: <1365435403-29265-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1365435403-29265-2-git-send-email-marc.zyngier@arm.com>

The way we populate HYP mappings is a bit convoluted, to say the least.
Passing a pointer around to keep track of the current PFN is quite
odd, and we end-up having two different PTE accessors for no good
reason.

Simplify the whole thing by unifying the two PTE accessors, passing
a pgprot_t around, and moving the various validity checks to the
upper layers.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm/kvm/mmu.c | 102 ++++++++++++++++++++++-------------------------------
 1 file changed, 42 insertions(+), 60 deletions(-)

diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
index 2f12e40..3003321 100644
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@ -125,54 +125,34 @@ void free_hyp_pmds(void)
 }
 
 static void create_hyp_pte_mappings(pmd_t *pmd, unsigned long start,
-				    unsigned long end)
+				    unsigned long end, unsigned long pfn,
+				    pgprot_t prot)
 {
 	pte_t *pte;
 	unsigned long addr;
-	struct page *page;
 
-	for (addr = start & PAGE_MASK; addr < end; addr += PAGE_SIZE) {
-		unsigned long hyp_addr = KERN_TO_HYP(addr);
-
-		pte = pte_offset_kernel(pmd, hyp_addr);
-		BUG_ON(!virt_addr_valid(addr));
-		page = virt_to_page(addr);
-		kvm_set_pte(pte, mk_pte(page, PAGE_HYP));
-	}
-}
-
-static void create_hyp_io_pte_mappings(pmd_t *pmd, unsigned long start,
-				       unsigned long end,
-				       unsigned long *pfn_base)
-{
-	pte_t *pte;
-	unsigned long addr;
-
-	for (addr = start & PAGE_MASK; addr < end; addr += PAGE_SIZE) {
-		unsigned long hyp_addr = KERN_TO_HYP(addr);
-
-		pte = pte_offset_kernel(pmd, hyp_addr);
-		BUG_ON(pfn_valid(*pfn_base));
-		kvm_set_pte(pte, pfn_pte(*pfn_base, PAGE_HYP_DEVICE));
-		(*pfn_base)++;
+	for (addr = start; addr < end; addr += PAGE_SIZE) {
+		pte = pte_offset_kernel(pmd, addr);
+		kvm_set_pte(pte, pfn_pte(pfn, prot));
+		pfn++;
 	}
 }
 
 static int create_hyp_pmd_mappings(pud_t *pud, unsigned long start,
-				   unsigned long end, unsigned long *pfn_base)
+				   unsigned long end, unsigned long pfn,
+				   pgprot_t prot)
 {
 	pmd_t *pmd;
 	pte_t *pte;
 	unsigned long addr, next;
 
 	for (addr = start; addr < end; addr = next) {
-		unsigned long hyp_addr = KERN_TO_HYP(addr);
-		pmd = pmd_offset(pud, hyp_addr);
+		pmd = pmd_offset(pud, addr);
 
 		BUG_ON(pmd_sect(*pmd));
 
 		if (pmd_none(*pmd)) {
-			pte = pte_alloc_one_kernel(NULL, hyp_addr);
+			pte = pte_alloc_one_kernel(NULL, addr);
 			if (!pte) {
 				kvm_err("Cannot allocate Hyp pte\n");
 				return -ENOMEM;
@@ -182,25 +162,17 @@ static int create_hyp_pmd_mappings(pud_t *pud, unsigned long start,
 
 		next = pmd_addr_end(addr, end);
 
-		/*
-		 * If pfn_base is NULL, we map kernel pages into HYP with the
-		 * virtual address. Otherwise, this is considered an I/O
-		 * mapping and we map the physical region starting at
-		 * *pfn_base to [start, end[.
-		 */
-		if (!pfn_base)
-			create_hyp_pte_mappings(pmd, addr, next);
-		else
-			create_hyp_io_pte_mappings(pmd, addr, next, pfn_base);
+		create_hyp_pte_mappings(pmd, addr, next, pfn, prot);
+		pfn += (next - addr) >> PAGE_SHIFT;
 	}
 
 	return 0;
 }
 
-static int __create_hyp_mappings(void *from, void *to, unsigned long *pfn_base)
+static int __create_hyp_mappings(pgd_t *pgdp,
+				 unsigned long start, unsigned long end,
+				 unsigned long pfn, pgprot_t prot)
 {
-	unsigned long start = (unsigned long)from;
-	unsigned long end = (unsigned long)to;
 	pgd_t *pgd;
 	pud_t *pud;
 	pmd_t *pmd;
@@ -209,21 +181,14 @@ static int __create_hyp_mappings(void *from, void *to, unsigned long *pfn_base)
 
 	if (start >= end)
 		return -EINVAL;
-	/* Check for a valid kernel memory mapping */
-	if (!pfn_base && (!virt_addr_valid(from) || !virt_addr_valid(to - 1)))
-		return -EINVAL;
-	/* Check for a valid kernel IO mapping */
-	if (pfn_base && (!is_vmalloc_addr(from) || !is_vmalloc_addr(to - 1)))
-		return -EINVAL;
 
 	mutex_lock(&kvm_hyp_pgd_mutex);
-	for (addr = start; addr < end; addr = next) {
-		unsigned long hyp_addr = KERN_TO_HYP(addr);
-		pgd = hyp_pgd + pgd_index(hyp_addr);
-		pud = pud_offset(pgd, hyp_addr);
+	for (addr = start & PAGE_MASK; addr < end; addr = next) {
+		pgd = pgdp + pgd_index(addr);
+		pud = pud_offset(pgd, addr);
 
 		if (pud_none_or_clear_bad(pud)) {
-			pmd = pmd_alloc_one(NULL, hyp_addr);
+			pmd = pmd_alloc_one(NULL, addr);
 			if (!pmd) {
 				kvm_err("Cannot allocate Hyp pmd\n");
 				err = -ENOMEM;
@@ -233,9 +198,10 @@ static int __create_hyp_mappings(void *from, void *to, unsigned long *pfn_base)
 		}
 
 		next = pgd_addr_end(addr, end);
-		err = create_hyp_pmd_mappings(pud, addr, next, pfn_base);
+		err = create_hyp_pmd_mappings(pud, addr, next, pfn, prot);
 		if (err)
 			goto out;
+		pfn += (next - addr) >> PAGE_SHIFT;
 	}
 out:
 	mutex_unlock(&kvm_hyp_pgd_mutex);
@@ -255,22 +221,38 @@ out:
  */
 int create_hyp_mappings(void *from, void *to)
 {
-	return __create_hyp_mappings(from, to, NULL);
+	unsigned long phys_addr = virt_to_phys(from);
+	unsigned long start = KERN_TO_HYP((unsigned long)from);
+	unsigned long end = KERN_TO_HYP((unsigned long)to);
+
+	/* Check for a valid kernel memory mapping */
+	if (!virt_addr_valid(from) || !virt_addr_valid(to - 1))
+		return -EINVAL;
+
+	return __create_hyp_mappings(hyp_pgd, start, end,
+				     __phys_to_pfn(phys_addr), PAGE_HYP);
 }
 
 /**
  * create_hyp_io_mappings - duplicate a kernel IO mapping into Hyp mode
  * @from:	The kernel start VA of the range
  * @to:		The kernel end VA of the range (exclusive)
- * @addr:	The physical start address which gets mapped
+ * @phys_addr:	The physical start address which gets mapped
  *
  * The resulting HYP VA is the same as the kernel VA, modulo
  * HYP_PAGE_OFFSET.
  */
-int create_hyp_io_mappings(void *from, void *to, phys_addr_t addr)
+int create_hyp_io_mappings(void *from, void *to, phys_addr_t phys_addr)
 {
-	unsigned long pfn = __phys_to_pfn(addr);
-	return __create_hyp_mappings(from, to, &pfn);
+	unsigned long start = KERN_TO_HYP((unsigned long)from);
+	unsigned long end = KERN_TO_HYP((unsigned long)to);
+
+	/* Check for a valid kernel IO mapping */
+	if (!is_vmalloc_addr(from) || !is_vmalloc_addr(to - 1))
+		return -EINVAL;
+
+	return __create_hyp_mappings(hyp_pgd, start, end,
+				     __phys_to_pfn(phys_addr), PAGE_HYP_DEVICE);
 }
 
 /**
-- 
1.8.1.4




From marc.zyngier at arm.com  Mon Apr  8 11:36:36 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon,  8 Apr 2013 16:36:36 +0100
Subject: [PATCH v2 0/7] ARM: KVM: Revamping the HYP init code for fun and
 profit
Message-ID: <1365435403-29265-1-git-send-email-marc.zyngier@arm.com>

Over the past few weeks, I've gradually realized how broken our HYP
idmap code is. Badly broken.

The main problem is about supporting CPU hotplug. Imagine a CPU being
initialized normally, running VMs, and then being powered down. So
far, so good. Now mentally bring it back online. The CPU will come
back via the secondary CPU boot path, and then what? We cannot use it
anymore, because we need an idmap which is long gone, and because our
page tables are now live, containing the world-switch code, VM
structures, and other bits and pieces.

Another fun issue is that we don't have any TLB invalidation in the
HYP init code. And guess what? we cannot do it! HYP TLB invalidation
has to occur in HYP, and once we've installed the runtime page tables,
it is already too late. It is actually fairly easy to construct a
scenario where idmap and runtime pages have colliding translations.

The nail on the coffin was provided by Catalin Marinas who told me how
much he disliked the arm64 HYP idmap code, and made me realize that we
already have all the necessary code in arch/arm/kvm/mmu.c. It just
needs a tiny bit of care and affection. With a chainsaw.

The solution to the first two issues is a bit tricky, but doesn't
involve a lot of code. The hotplug problem mandates that we keep two
sets of page tables (boot and runtime). The TLB problem mandates that
we're able to transition from one PGD to another while in HYP,
invalidating the TLBs in the process.

To be able to do this, we need to share a page between the two page
tables. A page that will have the same VA in both configurations. All
we need is a VA that has the following properties:
- This VA can't be used to represent a kernel mapping.
- This VA will not conflict with the physical address of the kernel
  text

The vectors page VA seems to satisfy this requirement:
- The kernel never maps anything else there
- The kernel text being copied at the beginning of the physical
  memory, it is unlikely to use the last 64kB (I doubt we'll ever
  support KVM on a system with something like 4MB of RAM, but patches
  are very welcome).

Let's call this VA the trampoline VA.

Now, we map our init page at 3 locations:
- idmap in the boot pgd
- trampoline VA in the boot pgd
- trampoline VA in the runtime pgd

The init scenario is now the following:
- We jump in HYP with four parameters: boot HYP pgd, runtime HYP pgd,
  runtime stack, runtime vectors
- Enable the MMU with the boot pgd
- Jump to a target into the trampoline page (remember, this is the
  same physical page!)
- Now switch to the runtime pgd (same VA, and still the same physical
  page!)
- Invalidate TLBs
- Set stack and vectors
- Profit! (or eret, if you only care about the code).

Once we have this infrastructure in place, supporting CPU hot-plug is
a piece of cake. Just wire a cpu-notifier in the existing code.

This has been tested on both arm (VE TC2) and arm64 (Foundation Model).

>From v1:
- Reduce the mandatory alignement of the init code page, and use a
  bounce page if the code is crossing a page boundary.
- Add some more comments to the code (as requested by Christoffer)
- Fixed compilation issue with older toolchains (spotted by Geoff)

Marc Zyngier (7):
  ARM: KVM: simplify HYP mapping population
  ARM: KVM: fix HYP mapping limitations around zero
  ARM: KVM: move to a KVM provided HYP idmap
  ARM: KVM: enforce maximum size for identity mapped code
  ARM: KVM: parametrize HYP page table freeing
  ARM: KVM: switch to a dual-step HYP init code
  ARM: KVM: perform HYP initilization for hotplugged CPUs

 arch/arm/include/asm/idmap.h    |   1 -
 arch/arm/include/asm/kvm_host.h |  18 ++-
 arch/arm/include/asm/kvm_mmu.h  |  27 +++-
 arch/arm/kernel/vmlinux.lds.S   |   7 +-
 arch/arm/kvm/arm.c              |  58 ++++----
 arch/arm/kvm/init.S             |  44 ++++++-
 arch/arm/kvm/mmu.c              | 286 ++++++++++++++++++++++++----------------
 arch/arm/mm/idmap.c             |  32 +----
 8 files changed, 294 insertions(+), 179 deletions(-)

-- 
1.8.1.4




From marc.zyngier at arm.com  Mon Apr  8 11:36:39 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon,  8 Apr 2013 16:36:39 +0100
Subject: [PATCH v2 3/7] ARM: KVM: move to a KVM provided HYP idmap
In-Reply-To: <1365435403-29265-1-git-send-email-marc.zyngier@arm.com>
References: <1365435403-29265-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1365435403-29265-4-git-send-email-marc.zyngier@arm.com>

After the HYP page table rework, it is pretty easy to let the KVM
code provide its own idmap, rather than expecting the kernel to
provide it. It takes actually less code to do so.

Acked-by: Will Deacon <will.deacon at arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm/include/asm/idmap.h   |  1 -
 arch/arm/include/asm/kvm_mmu.h |  1 -
 arch/arm/kvm/mmu.c             | 24 +++++++++++++++++++++++-
 arch/arm/mm/idmap.c            | 32 +-------------------------------
 4 files changed, 24 insertions(+), 34 deletions(-)

diff --git a/arch/arm/include/asm/idmap.h b/arch/arm/include/asm/idmap.h
index 1a66f907..bf863ed 100644
--- a/arch/arm/include/asm/idmap.h
+++ b/arch/arm/include/asm/idmap.h
@@ -8,7 +8,6 @@
 #define __idmap __section(.idmap.text) noinline notrace
 
 extern pgd_t *idmap_pgd;
-extern pgd_t *hyp_pgd;
 
 void setup_mm_for_reboot(void);
 
diff --git a/arch/arm/include/asm/kvm_mmu.h b/arch/arm/include/asm/kvm_mmu.h
index 970f3b5..3c71a1d 100644
--- a/arch/arm/include/asm/kvm_mmu.h
+++ b/arch/arm/include/asm/kvm_mmu.h
@@ -21,7 +21,6 @@
 
 #include <asm/cacheflush.h>
 #include <asm/pgalloc.h>
-#include <asm/idmap.h>
 
 /*
  * We directly use the kernel VA for the HYP, as we can directly share
diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
index 96d61da..bfc5927 100644
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@ -32,6 +32,7 @@
 
 extern char  __hyp_idmap_text_start[], __hyp_idmap_text_end[];
 
+static pgd_t *hyp_pgd;
 static DEFINE_MUTEX(kvm_hyp_pgd_mutex);
 
 static void kvm_tlb_flush_vmid_ipa(struct kvm *kvm, phys_addr_t ipa)
@@ -715,12 +716,33 @@ phys_addr_t kvm_mmu_get_httbr(void)
 
 int kvm_mmu_init(void)
 {
+	unsigned long hyp_idmap_start = virt_to_phys(__hyp_idmap_text_start);
+	unsigned long hyp_idmap_end = virt_to_phys(__hyp_idmap_text_end);
+	int err;
+
+	hyp_pgd = kzalloc(PTRS_PER_PGD * sizeof(pgd_t), GFP_KERNEL);
 	if (!hyp_pgd) {
 		kvm_err("Hyp mode PGD not allocated\n");
-		return -ENOMEM;
+		err = -ENOMEM;
+		goto out;
+	}
+
+	/* Create the idmap in the boot page tables */
+	err = 	__create_hyp_mappings(boot_hyp_pgd,
+				      hyp_idmap_start, hyp_idmap_end,
+				      __phys_to_pfn(hyp_idmap_start),
+				      PAGE_HYP);
+
+	if (err) {
+		kvm_err("Failed to idmap %lx-%lx\n",
+			hyp_idmap_start, hyp_idmap_end);
+		goto out;
 	}
 
 	return 0;
+out:
+	kfree(hyp_pgd);
+	return err;
 }
 
 /**
diff --git a/arch/arm/mm/idmap.c b/arch/arm/mm/idmap.c
index 5ee505c..83cb3ac 100644
--- a/arch/arm/mm/idmap.c
+++ b/arch/arm/mm/idmap.c
@@ -8,7 +8,6 @@
 #include <asm/pgtable.h>
 #include <asm/sections.h>
 #include <asm/system_info.h>
-#include <asm/virt.h>
 
 pgd_t *idmap_pgd;
 
@@ -83,37 +82,10 @@ static void identity_mapping_add(pgd_t *pgd, const char *text_start,
 	} while (pgd++, addr = next, addr != end);
 }
 
-#if defined(CONFIG_ARM_VIRT_EXT) && defined(CONFIG_ARM_LPAE)
-pgd_t *hyp_pgd;
-
-extern char  __hyp_idmap_text_start[], __hyp_idmap_text_end[];
-
-static int __init init_static_idmap_hyp(void)
-{
-	hyp_pgd = kzalloc(PTRS_PER_PGD * sizeof(pgd_t), GFP_KERNEL);
-	if (!hyp_pgd)
-		return -ENOMEM;
-
-	pr_info("Setting up static HYP identity map for 0x%p - 0x%p\n",
-		__hyp_idmap_text_start, __hyp_idmap_text_end);
-	identity_mapping_add(hyp_pgd, __hyp_idmap_text_start,
-			     __hyp_idmap_text_end, PMD_SECT_AP1);
-
-	return 0;
-}
-#else
-static int __init init_static_idmap_hyp(void)
-{
-	return 0;
-}
-#endif
-
 extern char  __idmap_text_start[], __idmap_text_end[];
 
 static int __init init_static_idmap(void)
 {
-	int ret;
-
 	idmap_pgd = pgd_alloc(&init_mm);
 	if (!idmap_pgd)
 		return -ENOMEM;
@@ -123,12 +95,10 @@ static int __init init_static_idmap(void)
 	identity_mapping_add(idmap_pgd, __idmap_text_start,
 			     __idmap_text_end, 0);
 
-	ret = init_static_idmap_hyp();
-
 	/* Flush L1 for the hardware to see this page table content */
 	flush_cache_louis();
 
-	return ret;
+	return 0;
 }
 early_initcall(init_static_idmap);
 
-- 
1.8.1.4




From marc.zyngier at arm.com  Mon Apr  8 11:36:40 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon,  8 Apr 2013 16:36:40 +0100
Subject: [PATCH v2 4/7] ARM: KVM: enforce maximum size for identity mapped code
In-Reply-To: <1365435403-29265-1-git-send-email-marc.zyngier@arm.com>
References: <1365435403-29265-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1365435403-29265-5-git-send-email-marc.zyngier@arm.com>

We're about to move to an init procedure where we rely on the
fact that the init code fits in a single page. Make sure we
align the idmap text on a vector alignment, and that the code is
not bigger than a single page.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm/kernel/vmlinux.lds.S | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
index b571484..a871b8e 100644
--- a/arch/arm/kernel/vmlinux.lds.S
+++ b/arch/arm/kernel/vmlinux.lds.S
@@ -20,7 +20,7 @@
 	VMLINUX_SYMBOL(__idmap_text_start) = .;				\
 	*(.idmap.text)							\
 	VMLINUX_SYMBOL(__idmap_text_end) = .;				\
-	ALIGN_FUNCTION();						\
+	. = ALIGN(32);							\
 	VMLINUX_SYMBOL(__hyp_idmap_text_start) = .;			\
 	*(.hyp.idmap.text)						\
 	VMLINUX_SYMBOL(__hyp_idmap_text_end) = .;
@@ -315,3 +315,8 @@ SECTIONS
  */
 ASSERT((__proc_info_end - __proc_info_begin), "missing CPU support")
 ASSERT((__arch_info_end - __arch_info_begin), "no machine record defined")
+/*
+ * The HYP init code can't be more than a page long.
+ * The above comment applies as well.
+ */
+ASSERT(((__hyp_idmap_text_end - __hyp_idmap_text_start) <= PAGE_SIZE), "HYP init code too big")
-- 
1.8.1.4




From marc.zyngier at arm.com  Mon Apr  8 11:36:43 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon,  8 Apr 2013 16:36:43 +0100
Subject: [PATCH v2 7/7] ARM: KVM: perform HYP initilization for hotplugged CPUs
In-Reply-To: <1365435403-29265-1-git-send-email-marc.zyngier@arm.com>
References: <1365435403-29265-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1365435403-29265-8-git-send-email-marc.zyngier@arm.com>

Now that we have the necessary infrastructure to boot a hotplugged CPU
at any point in time, wire a CPU notifier that will perform the HYP
init for the incoming CPU.

Note that this depends on the platform code and/or firmware to boot the
incoming CPU with HYP mode enabled and return to the kernel by following
the normal boot path (HYP stub installed).

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm/kvm/arm.c | 45 ++++++++++++++++++++++++++++++---------------
 1 file changed, 30 insertions(+), 15 deletions(-)

diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index 9010a12..8bee0bb 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -16,6 +16,7 @@
  * Foundation, 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.
  */
 
+#include <linux/cpu.h>
 #include <linux/errno.h>
 #include <linux/err.h>
 #include <linux/kvm_host.h>
@@ -794,7 +795,7 @@ long kvm_arch_vm_ioctl(struct file *filp,
 	}
 }
 
-static void cpu_init_hyp_mode(void *vector)
+static void cpu_init_hyp_mode(void *dummy)
 {
 	unsigned long long boot_pgd_ptr;
 	unsigned long long pgd_ptr;
@@ -814,12 +815,28 @@ static void cpu_init_hyp_mode(void *vector)
 	__cpu_init_hyp_mode(boot_pgd_ptr, pgd_ptr, hyp_stack_ptr, vector_ptr);
 }
 
+static int hyp_init_cpu_notify(struct notifier_block *self,
+			       unsigned long action, void *cpu)
+{
+	switch (action) {
+	case CPU_STARTING:
+	case CPU_STARTING_FROZEN:
+		cpu_init_hyp_mode(NULL);
+		break;
+	}
+
+	return NOTIFY_OK;
+}
+
+static struct notifier_block hyp_init_cpu_nb = {
+	.notifier_call = hyp_init_cpu_notify,
+};
+
 /**
  * Inits Hyp-mode on all online CPUs
  */
 static int init_hyp_mode(void)
 {
-	phys_addr_t init_phys_addr;
 	int cpu;
 	int err = 0;
 
@@ -852,19 +869,6 @@ static int init_hyp_mode(void)
 	}
 
 	/*
-	 * Execute the init code on each CPU.
-	 *
-	 * Note: The stack is not mapped yet, so don't do anything else than
-	 * initializing the hypervisor mode on each CPU using a local stack
-	 * space for temporary storage.
-	 */
-	init_phys_addr = virt_to_phys(__kvm_hyp_init);
-	for_each_online_cpu(cpu) {
-		smp_call_function_single(cpu, cpu_init_hyp_mode,
-					 (void *)(long)init_phys_addr, 1);
-	}
-
-	/*
 	 * Map the Hyp-code called directly from the host
 	 */
 	err = create_hyp_mappings(__kvm_hyp_code_start, __kvm_hyp_code_end);
@@ -909,6 +913,11 @@ static int init_hyp_mode(void)
 	}
 
 	/*
+	 * Execute the init code on each CPU.
+	 */
+	on_each_cpu(cpu_init_hyp_mode, NULL, 1);
+
+	/*
 	 * Init HYP view of VGIC
 	 */
 	err = kvm_vgic_hyp_init();
@@ -964,6 +973,12 @@ int kvm_arch_init(void *opaque)
 	if (err)
 		goto out_err;
 
+	err = register_cpu_notifier(&hyp_init_cpu_nb);
+	if (err) {
+		kvm_err("Cannot register HYP init CPU notifier (%d)\n", err);
+		goto out_err;
+	}
+
 	kvm_coproc_table_init();
 	return 0;
 out_err:
-- 
1.8.1.4




From marc.zyngier at arm.com  Mon Apr  8 11:36:41 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon,  8 Apr 2013 16:36:41 +0100
Subject: [PATCH v2 5/7] ARM: KVM: parametrize HYP page table freeing
In-Reply-To: <1365435403-29265-1-git-send-email-marc.zyngier@arm.com>
References: <1365435403-29265-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1365435403-29265-6-git-send-email-marc.zyngier@arm.com>

In order to prepare for having to deal with multiple HYP page tables,
pass the PGD parameter to the function performing the freeing of the
page tables.

Also move the freeing of the PGD itself there, and rename the
free_hyp_pmds to free_hyp_pgds.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm/include/asm/kvm_mmu.h |  2 +-
 arch/arm/kvm/arm.c             |  2 +-
 arch/arm/kvm/mmu.c             | 30 +++++++++++++++++-------------
 3 files changed, 19 insertions(+), 15 deletions(-)

diff --git a/arch/arm/include/asm/kvm_mmu.h b/arch/arm/include/asm/kvm_mmu.h
index 3c71a1d..92eb20d 100644
--- a/arch/arm/include/asm/kvm_mmu.h
+++ b/arch/arm/include/asm/kvm_mmu.h
@@ -32,7 +32,7 @@
 
 int create_hyp_mappings(void *from, void *to);
 int create_hyp_io_mappings(void *from, void *to, phys_addr_t);
-void free_hyp_pmds(void);
+void free_hyp_pgds(void);
 
 int kvm_alloc_stage2_pgd(struct kvm *kvm);
 void kvm_free_stage2_pgd(struct kvm *kvm);
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index 47cfcc3..8d44ef4 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -937,7 +937,7 @@ static int init_hyp_mode(void)
 out_free_context:
 	free_percpu(kvm_host_cpu_state);
 out_free_mappings:
-	free_hyp_pmds();
+	free_hyp_pgds();
 out_free_stack_pages:
 	for_each_possible_cpu(cpu)
 		free_page(per_cpu(kvm_arm_hyp_stack_page, cpu));
diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
index bfc5927..c4236e4 100644
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@ -86,42 +86,46 @@ static void free_ptes(pmd_t *pmd, unsigned long addr)
 	}
 }
 
-static void free_hyp_pgd_entry(unsigned long addr)
+static void free_hyp_pgd_entry(pgd_t *pgdp, unsigned long addr)
 {
 	pgd_t *pgd;
 	pud_t *pud;
 	pmd_t *pmd;
-	unsigned long hyp_addr = KERN_TO_HYP(addr);
 
-	pgd = hyp_pgd + pgd_index(hyp_addr);
-	pud = pud_offset(pgd, hyp_addr);
+	pgd = pgdp + pgd_index(addr);
+	pud = pud_offset(pgd, addr);
 
 	if (pud_none(*pud))
 		return;
 	BUG_ON(pud_bad(*pud));
 
-	pmd = pmd_offset(pud, hyp_addr);
+	pmd = pmd_offset(pud, addr);
 	free_ptes(pmd, addr);
 	pmd_free(NULL, pmd);
 	pud_clear(pud);
 }
 
 /**
- * free_hyp_pmds - free a Hyp-mode level-2 tables and child level-3 tables
+ * free_hyp_pgds - free Hyp-mode page tables
  *
- * Assumes this is a page table used strictly in Hyp-mode and therefore contains
+ * Assumes hyp_pgd is a page table used strictly in Hyp-mode and therefore contains
  * either mappings in the kernel memory area (above PAGE_OFFSET), or
  * device mappings in the vmalloc range (from VMALLOC_START to VMALLOC_END).
  */
-void free_hyp_pmds(void)
+void free_hyp_pgds(void)
 {
 	unsigned long addr;
 
 	mutex_lock(&kvm_hyp_pgd_mutex);
-	for (addr = PAGE_OFFSET; virt_addr_valid(addr); addr += PGDIR_SIZE)
-		free_hyp_pgd_entry(addr);
-	for (addr = VMALLOC_START; is_vmalloc_addr((void*)addr); addr += PGDIR_SIZE)
-		free_hyp_pgd_entry(addr);
+
+	if (hyp_pgd) {
+		for (addr = PAGE_OFFSET; virt_addr_valid(addr); addr += PGDIR_SIZE)
+			free_hyp_pgd_entry(hyp_pgd, KERN_TO_HYP(addr));
+		for (addr = VMALLOC_START; is_vmalloc_addr((void*)addr); addr += PGDIR_SIZE)
+			free_hyp_pgd_entry(hyp_pgd, KERN_TO_HYP(addr));
+		kfree(hyp_pgd);
+	}
+
 	mutex_unlock(&kvm_hyp_pgd_mutex);
 }
 
@@ -741,7 +745,7 @@ int kvm_mmu_init(void)
 
 	return 0;
 out:
-	kfree(hyp_pgd);
+	free_hyp_pgds();
 	return err;
 }
 
-- 
1.8.1.4




From marc.zyngier at arm.com  Mon Apr  8 11:36:42 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon,  8 Apr 2013 16:36:42 +0100
Subject: [PATCH v2 6/7] ARM: KVM: switch to a dual-step HYP init code
In-Reply-To: <1365435403-29265-1-git-send-email-marc.zyngier@arm.com>
References: <1365435403-29265-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1365435403-29265-7-git-send-email-marc.zyngier@arm.com>

Our HYP init code suffers from two major design issues:
- it cannot support CPU hotplug, as we tear down the idmap very early
- it cannot perform a TLB invalidation when switching from init to
  runtime mappings, as pages are manipulated from PL1 exclusively

The hotplug problem mandates that we keep two sets of page tables
(boot and runtime). The TLB problem mandates that we're able to
transition from one PGD to another while in HYP, invalidating the TLBs
in the process.

To be able to do this, we need to share a page between the two page
tables. A page that will have the same VA in both configurations. All we
need is a VA that has the following properties:
- This VA can't be used to represent a kernel mapping.
- This VA will not conflict with the physical address of the kernel text

The vectors page seems to satisfy this requirement:
- The kernel never maps anything else there
- The kernel text being copied at the beginning of the physical memory,
  it is unlikely to use the last 64kB (I doubt we'll ever support KVM
  on a system with something like 4MB of RAM, but patches are very
  welcome).

Let's call this VA the trampoline VA.

Now, we map our init page at 3 locations:
- idmap in the boot pgd
- trampoline VA in the boot pgd
- trampoline VA in the runtime pgd

The init scenario is now the following:
- We jump in HYP with four parameters: boot HYP pgd, runtime HYP pgd,
  runtime stack, runtime vectors
- Enable the MMU with the boot pgd
- Jump to a target into the trampoline page (remember, this is the same
  physical page!)
- Now switch to the runtime pgd (same VA, and still the same physical
  page!)
- Invalidate TLBs
- Set stack and vectors
- Profit! (or eret, if you only care about the code).

Note that we keep the boot mapping permanently (it is not strictly an
idmap anymore) to allow for CPU hotplug in later patches.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm/include/asm/kvm_host.h |  18 ++++--
 arch/arm/include/asm/kvm_mmu.h  |  24 +++++++-
 arch/arm/kvm/arm.c              |  11 ++--
 arch/arm/kvm/init.S             |  44 +++++++++++++-
 arch/arm/kvm/mmu.c              | 129 ++++++++++++++++++++++++++++------------
 5 files changed, 173 insertions(+), 53 deletions(-)

diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
index a856cc2..9fe22ee 100644
--- a/arch/arm/include/asm/kvm_host.h
+++ b/arch/arm/include/asm/kvm_host.h
@@ -190,22 +190,32 @@ int kvm_arm_coproc_set_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *);
 int handle_exit(struct kvm_vcpu *vcpu, struct kvm_run *run,
 		int exception_index);
 
-static inline void __cpu_init_hyp_mode(unsigned long long pgd_ptr,
+static inline void __cpu_init_hyp_mode(unsigned long long boot_pgd_ptr,
+				       unsigned long long pgd_ptr,
 				       unsigned long hyp_stack_ptr,
 				       unsigned long vector_ptr)
 {
 	unsigned long pgd_low, pgd_high;
 
-	pgd_low = (pgd_ptr & ((1ULL << 32) - 1));
-	pgd_high = (pgd_ptr >> 32ULL);
+	pgd_low = (boot_pgd_ptr & ((1ULL << 32) - 1));
+	pgd_high = (boot_pgd_ptr >> 32ULL);
 
 	/*
 	 * Call initialization code, and switch to the full blown
 	 * HYP code. The init code doesn't need to preserve these registers as
-	 * r1-r3 and r12 are already callee save according to the AAPCS.
+	 * r1-r3 and r12 are already callee saved according to the AAPCS.
 	 * Note that we slightly misuse the prototype by casing the pgd_low to
 	 * a void *.
+	 *
+	 * We don't have enough registers to perform the full init in one go.
+	 * Install the boot PGD first, and then install the runtime PGD,
+	 * stack pointer and vectors.
 	 */
+	kvm_call_hyp((void *)pgd_low, pgd_high, 0, 0);
+
+	pgd_low = (pgd_ptr & ((1ULL << 32) - 1));
+	pgd_high = (pgd_ptr >> 32ULL);
+
 	kvm_call_hyp((void *)pgd_low, pgd_high, hyp_stack_ptr, vector_ptr);
 }
 
diff --git a/arch/arm/include/asm/kvm_mmu.h b/arch/arm/include/asm/kvm_mmu.h
index 92eb20d..24b767a 100644
--- a/arch/arm/include/asm/kvm_mmu.h
+++ b/arch/arm/include/asm/kvm_mmu.h
@@ -19,17 +19,29 @@
 #ifndef __ARM_KVM_MMU_H__
 #define __ARM_KVM_MMU_H__
 
-#include <asm/cacheflush.h>
-#include <asm/pgalloc.h>
+#include <asm/memory.h>
+#include <asm/page.h>
 
 /*
  * We directly use the kernel VA for the HYP, as we can directly share
  * the mapping (HTTBR "covers" TTBR1).
  */
-#define HYP_PAGE_OFFSET_MASK	(~0UL)
+#define HYP_PAGE_OFFSET_MASK	UL(~0)
 #define HYP_PAGE_OFFSET		PAGE_OFFSET
 #define KERN_TO_HYP(kva)	(kva)
 
+/*
+ * Our virtual mapping for the boot-time MMU-enable code. Must be
+ * shared across all the page-tables. Conveniently, we use the vectors
+ * page, where no kernel data will ever be shared with HYP.
+ */
+#define TRAMPOLINE_VA		UL(CONFIG_VECTORS_BASE)
+
+#ifndef __ASSEMBLY__
+
+#include <asm/cacheflush.h>
+#include <asm/pgalloc.h>
+
 int create_hyp_mappings(void *from, void *to);
 int create_hyp_io_mappings(void *from, void *to, phys_addr_t);
 void free_hyp_pgds(void);
@@ -44,6 +56,8 @@ int kvm_handle_guest_abort(struct kvm_vcpu *vcpu, struct kvm_run *run);
 void kvm_mmu_free_memory_caches(struct kvm_vcpu *vcpu);
 
 phys_addr_t kvm_mmu_get_httbr(void);
+phys_addr_t kvm_mmu_get_boot_httbr(void);
+phys_addr_t kvm_get_idmap_vector(void);
 int kvm_mmu_init(void);
 void kvm_clear_hyp_idmap(void);
 
@@ -113,4 +127,8 @@ static inline void coherent_icache_guest_page(struct kvm *kvm, gfn_t gfn)
 	}
 }
 
+#define kvm_flush_dcache_to_poc(a,l)	__cpuc_flush_dcache_area((a), (l))
+
+#endif	/* !__ASSEMBLY__ */
+
 #endif /* __ARM_KVM_MMU_H__ */
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index 8d44ef4..9010a12 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -796,20 +796,22 @@ long kvm_arch_vm_ioctl(struct file *filp,
 
 static void cpu_init_hyp_mode(void *vector)
 {
+	unsigned long long boot_pgd_ptr;
 	unsigned long long pgd_ptr;
 	unsigned long hyp_stack_ptr;
 	unsigned long stack_page;
 	unsigned long vector_ptr;
 
 	/* Switch from the HYP stub to our own HYP init vector */
-	__hyp_set_vectors((unsigned long)vector);
+	__hyp_set_vectors(kvm_get_idmap_vector());
 
+	boot_pgd_ptr = (unsigned long long)kvm_mmu_get_boot_httbr();
 	pgd_ptr = (unsigned long long)kvm_mmu_get_httbr();
 	stack_page = __get_cpu_var(kvm_arm_hyp_stack_page);
 	hyp_stack_ptr = stack_page + PAGE_SIZE;
 	vector_ptr = (unsigned long)__kvm_hyp_vector;
 
-	__cpu_init_hyp_mode(pgd_ptr, hyp_stack_ptr, vector_ptr);
+	__cpu_init_hyp_mode(boot_pgd_ptr, pgd_ptr, hyp_stack_ptr, vector_ptr);
 }
 
 /**
@@ -863,11 +865,6 @@ static int init_hyp_mode(void)
 	}
 
 	/*
-	 * Unmap the identity mapping
-	 */
-	kvm_clear_hyp_idmap();
-
-	/*
 	 * Map the Hyp-code called directly from the host
 	 */
 	err = create_hyp_mappings(__kvm_hyp_code_start, __kvm_hyp_code_end);
diff --git a/arch/arm/kvm/init.S b/arch/arm/kvm/init.S
index 9f37a79..0ca054f 100644
--- a/arch/arm/kvm/init.S
+++ b/arch/arm/kvm/init.S
@@ -21,6 +21,7 @@
 #include <asm/asm-offsets.h>
 #include <asm/kvm_asm.h>
 #include <asm/kvm_arm.h>
+#include <asm/kvm_mmu.h>
 
 /********************************************************************
  * Hypervisor initialization
@@ -28,6 +29,25 @@
  *       r0,r1 = Hypervisor pgd pointer
  *       r2 = top of Hyp stack (kernel VA)
  *       r3 = pointer to hyp vectors
+ *
+ * The init scenario is:
+ * - We jump in HYP with four parameters: boot HYP pgd, runtime HYP pgd,
+ *   runtime stack, runtime vectors
+ * - Enable the MMU with the boot pgd
+ * - Jump to a target into the trampoline page (remember, this is the same
+ *   physical page!)
+ * - Now switch to the runtime pgd (same VA, and still the same physical
+ *   page!)
+ * - Invalidate TLBs
+ * - Set stack and vectors
+ * - Profit! (or eret, if you only care about the code).
+ *
+ * As we only have four registers available to pass parameters (and we
+ * need six), we split the init in two phases:
+ * - Phase 1: r0,r1 contain the boot PGD, r2 = 0, r3 = 0.
+ *   Provides the basic HYP init, and enable the MMU.
+ * - Phase 2: r0,r1 contain the runtime PGD, r2 = ToS, r3 = vectors
+ *   Switches to the runtime PGD, set stack and vectors.
  */
 
 	.text
@@ -47,6 +67,9 @@ __kvm_hyp_init:
 	W(b)	.
 
 __do_hyp_init:
+	cmp	r2, #0			@ We have a SP?
+	bne	phase2			@ Yes, second stage init
+
 	@ Set the HTTBR to point to the hypervisor PGD pointer passed
 	mcrr	p15, 4, r0, r1, c2
 
@@ -96,14 +119,31 @@ __do_hyp_init:
 	orr	r0, r0, r1
 	isb
 	mcr	p15, 4, r0, c1, c0, 0	@ HSCR
-	isb
 
-	@ Set stack pointer and return to the kernel
+	@ End of init phase-1
+	eret
+
+phase2:
+	@ Set stack pointer
 	mov	sp, r2
 
 	@ Set HVBAR to point to the HYP vectors
 	mcr	p15, 4, r3, c12, c0, 0	@ HVBAR
 
+	@ Jump to the trampoline page
+	ldr	r2, =TRAMPOLINE_VA
+	adr	r3, target
+	bfi	r2, r3, #0, #PAGE_SHIFT
+	mov	pc, r2
+
+target:	@ We're now in the trampoline code, switch page tables
+	mcrr	p15, 4, r0, r1, c2
+	isb
+
+	@ Invalidate the old TLBs
+	mcr	p15, 4, r0, c8, c7, 0	@ TLBIALLH
+	dsb
+
 	eret
 
 	.ltorg
diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
index c4236e4..b20eff2 100644
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@ -32,9 +32,15 @@
 
 extern char  __hyp_idmap_text_start[], __hyp_idmap_text_end[];
 
+static pgd_t *boot_hyp_pgd;
 static pgd_t *hyp_pgd;
 static DEFINE_MUTEX(kvm_hyp_pgd_mutex);
 
+static void *init_bounce_page;
+static unsigned long hyp_idmap_start;
+static unsigned long hyp_idmap_end;
+static phys_addr_t hyp_idmap_vector;
+
 static void kvm_tlb_flush_vmid_ipa(struct kvm *kvm, phys_addr_t ipa)
 {
 	kvm_call_hyp(__kvm_tlb_flush_vmid_ipa, kvm, ipa);
@@ -108,9 +114,12 @@ static void free_hyp_pgd_entry(pgd_t *pgdp, unsigned long addr)
 /**
  * free_hyp_pgds - free Hyp-mode page tables
  *
- * Assumes hyp_pgd is a page table used strictly in Hyp-mode and therefore contains
- * either mappings in the kernel memory area (above PAGE_OFFSET), or
- * device mappings in the vmalloc range (from VMALLOC_START to VMALLOC_END).
+ * Assumes hyp_pgd is a page table used strictly in Hyp-mode and
+ * therefore contains either mappings in the kernel memory area (above
+ * PAGE_OFFSET), or device mappings in the vmalloc range (from
+ * VMALLOC_START to VMALLOC_END).
+ *
+ * boot_hyp_pgd should only map two pages for the init code.
  */
 void free_hyp_pgds(void)
 {
@@ -118,6 +127,12 @@ void free_hyp_pgds(void)
 
 	mutex_lock(&kvm_hyp_pgd_mutex);
 
+	if (boot_hyp_pgd) {
+		free_hyp_pgd_entry(boot_hyp_pgd, hyp_idmap_start);
+		free_hyp_pgd_entry(boot_hyp_pgd, TRAMPOLINE_VA);
+		kfree(boot_hyp_pgd);
+	}
+
 	if (hyp_pgd) {
 		for (addr = PAGE_OFFSET; virt_addr_valid(addr); addr += PGDIR_SIZE)
 			free_hyp_pgd_entry(hyp_pgd, KERN_TO_HYP(addr));
@@ -126,6 +141,7 @@ void free_hyp_pgds(void)
 		kfree(hyp_pgd);
 	}
 
+	kfree(init_bounce_page);
 	mutex_unlock(&kvm_hyp_pgd_mutex);
 }
 
@@ -718,14 +734,62 @@ phys_addr_t kvm_mmu_get_httbr(void)
 	return virt_to_phys(hyp_pgd);
 }
 
+phys_addr_t kvm_mmu_get_boot_httbr(void)
+{
+	VM_BUG_ON(!virt_addr_valid(boot_hyp_pgd));
+	return virt_to_phys(boot_hyp_pgd);
+}
+
+phys_addr_t kvm_get_idmap_vector(void)
+{
+	return hyp_idmap_vector;
+}
+
 int kvm_mmu_init(void)
 {
-	unsigned long hyp_idmap_start = virt_to_phys(__hyp_idmap_text_start);
-	unsigned long hyp_idmap_end = virt_to_phys(__hyp_idmap_text_end);
 	int err;
 
+	hyp_idmap_start = virt_to_phys(__hyp_idmap_text_start);
+	hyp_idmap_end = virt_to_phys(__hyp_idmap_text_end);
+	hyp_idmap_vector = virt_to_phys(__kvm_hyp_init);
+
+	if ((hyp_idmap_start ^ hyp_idmap_end) & PAGE_MASK) {
+		/*
+		 * Our init code is crossing a page boundary. Allocate
+		 * a bounce page, copy the code over and use that.
+		 */
+		size_t len = __hyp_idmap_text_end - __hyp_idmap_text_start;
+		phys_addr_t phys_base;
+
+		init_bounce_page = kzalloc(PAGE_SIZE, GFP_KERNEL);
+		if (!init_bounce_page) {
+			kvm_err("Couldn't allocate HYP init bounce page\n");
+			err = -ENOMEM;
+			goto out;
+		}
+
+		memcpy(init_bounce_page, __hyp_idmap_text_start, len);
+		/*
+		 * Warning: the code we just copied to the bounce page
+		 * must be flushed to the point of coherency.
+		 * Otherwise, the data may be sitting in L2, and HYP
+		 * mode won't be able to observe it as it runs with
+		 * caches off at that point.
+		 */
+		kvm_flush_dcache_to_poc(init_bounce_page, len);
+
+		phys_base = virt_to_phys(init_bounce_page);
+		hyp_idmap_vector += phys_base - hyp_idmap_start;
+		hyp_idmap_start = phys_base;
+		hyp_idmap_end = phys_base + len;
+
+		kvm_info("Using HYP init bounce page @%lx\n",
+			 (unsigned long)phys_base);
+	}
+
 	hyp_pgd = kzalloc(PTRS_PER_PGD * sizeof(pgd_t), GFP_KERNEL);
-	if (!hyp_pgd) {
+	boot_hyp_pgd = kzalloc(PTRS_PER_PGD * sizeof(pgd_t), GFP_KERNEL);
+	if (!hyp_pgd || !boot_hyp_pgd) {
 		kvm_err("Hyp mode PGD not allocated\n");
 		err = -ENOMEM;
 		goto out;
@@ -743,39 +807,30 @@ int kvm_mmu_init(void)
 		goto out;
 	}
 
+	/* Map the very same page at the trampoline VA */
+	err = 	__create_hyp_mappings(boot_hyp_pgd,
+				      TRAMPOLINE_VA, TRAMPOLINE_VA + PAGE_SIZE,
+				      __phys_to_pfn(hyp_idmap_start),
+				      PAGE_HYP);
+	if (err) {
+		kvm_err("Failed to map trampoline @%lx into boot HYP pgd\n",
+			TRAMPOLINE_VA);
+		goto out;
+	}
+
+	/* Map the same page again into the runtime page tables */
+	err = 	__create_hyp_mappings(hyp_pgd,
+				      TRAMPOLINE_VA, TRAMPOLINE_VA + PAGE_SIZE,
+				      __phys_to_pfn(hyp_idmap_start),
+				      PAGE_HYP);
+	if (err) {
+		kvm_err("Failed to map trampoline @%lx into runtime HYP pgd\n",
+			TRAMPOLINE_VA);
+		goto out;
+	}
+
 	return 0;
 out:
 	free_hyp_pgds();
 	return err;
 }
-
-/**
- * kvm_clear_idmap - remove all idmaps from the hyp pgd
- *
- * Free the underlying pmds for all pgds in range and clear the pgds (but
- * don't free them) afterwards.
- */
-void kvm_clear_hyp_idmap(void)
-{
-	unsigned long addr, end;
-	unsigned long next;
-	pgd_t *pgd = hyp_pgd;
-	pud_t *pud;
-	pmd_t *pmd;
-
-	addr = virt_to_phys(__hyp_idmap_text_start);
-	end = virt_to_phys(__hyp_idmap_text_end);
-
-	pgd += pgd_index(addr);
-	do {
-		next = pgd_addr_end(addr, end);
-		if (pgd_none_or_clear_bad(pgd))
-			continue;
-		pud = pud_offset(pgd, addr);
-		pmd = pmd_offset(pud, addr);
-
-		pud_clear(pud);
-		kvm_clean_pmd_entry(pmd);
-		pmd_free(NULL, (pmd_t *)((unsigned long)pmd & PAGE_MASK));
-	} while (pgd++, addr = next, addr < end);
-}
-- 
1.8.1.4




From sebastian.hesselbarth at gmail.com  Mon Apr  8 11:38:44 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Mon, 8 Apr 2013 17:38:44 +0200
Subject: [v5] clk: add si5351 i2c common clock driver
In-Reply-To: <20130408145407.GA12243@roeck-us.net>
References: <1365139415-17815-1-git-send-email-sebastian.hesselbarth@gmail.com>
 <20130407225046.GA16326@roeck-us.net> <51620604.4070204@gmail.com>
 <20130408001725.GA16648@roeck-us.net> <51625F9A.1050308@gmail.com>
 <20130408145407.GA12243@roeck-us.net>
Message-ID: <CABJ1b_T30trVjXps-rSbYTNo1DcPeT8WsZ+M18B9wTJPBnL-gA@mail.gmail.com>

On Mon, Apr 8, 2013 at 4:54 PM, Guenter Roeck <linux at roeck-us.net> wrote:
> On Mon, Apr 08, 2013 at 08:11:38AM +0200, Sebastian Hesselbarth wrote:
>> On 04/08/2013 02:17 AM, Guenter Roeck wrote:
>> >On Mon, Apr 08, 2013 at 01:49:24AM +0200, Sebastian Hesselbarth wrote:
>> >>On 04/08/2013 12:50 AM, Guenter Roeck wrote:
>> >>>On Fri, Apr 05, 2013 at 05:23:35AM -0000, Sebastian Hesselbarth wrote:
>> >>>>This patch adds a common clock driver for Silicon Labs Si5351a/b/c
>> >>>>i2c programmable clock generators. Currently, the driver supports
>> >>>>DT kernels only and VXCO feature of si5351b is not implemented. DT
>> >>>>bindings selectively allow to overwrite stored Si5351 configuration
>> >>>>which is very helpful for clock generators with empty eeprom
>> >>>>configuration. Corresponding device tree binding documentation is
>> >>>>also added.
>> >>>>
>> >>>>Signed-off-by: Sebastian Hesselbarth<sebastian.hesselbarth at gmail.com>
>> >>>>Tested-by: Daniel Mack<zonque at gmail.com>
>> >>>>
>> >>>[ ... ]
>> >>>
>> >>>>+static inline void _si5351_msynth_set_pll_master(
>> >>>>+ struct si5351_driver_data *drvdata, unsigned char num, int is_master)
>> >>>>+{
>> >>>>+ unsigned long flags;
>> >>>>+
>> >>>>+ if (num>   8 ||
>> >>>>+     (drvdata->variant == SI5351_VARIANT_A3&&   num>   3))
>> >>>>+         return;
>> >>>>+
>> >>>>+ flags = __clk_get_flags(drvdata->msynth[num].hw.clk);
>> >>>>+ if (is_master)
>> >>>>+         flags |= CLK_SET_RATE_PARENT;
>> >>>>+ else
>> >>>>+         flags&= ~CLK_SET_RATE_PARENT;
>> >>>>+ __clk_set_flags(drvdata->msynth[num].hw.clk, flags);
>> >>>>+}
>> >>>>+
>> >>>Unless I am missing something, neither __clk_get_flags() nor the new
>> >>>__clk_set_flags is exported.
>> >>>
>> >>>Did you try to build and load the driver as module ?
>> >>
>> >>Well, good catch. I didn't try to build v5 as a module, but I guess it
>> >>will fail. But I consider this as something that has to be addressed in
>> >>clk framework itself, not in this patch. There will be other
>> >>clk-providers built as module in the future for sure.
>> >>
>> >Sure, but you provided the patch to make __clk_set_flags global. To avoid
>> >build failures, I would suggest to either submit a patch to export the
>> >missing functions, or to remove the ability to build the driver as module.
>>
>> Actually, I knew that __clk_set_flags patch will not be accepted
>> before posting it ;)
>>
> Ah, but part of that is to get you to think about it again, and to defend it if
> it is really needed. After all, "it can be abused" applies to pretty much every
> API.

Guenter,

I already thought about it a lot and I consider clk api broken in a way here.

> Key question is if you _really_ need run-time flag modifications, or if you can
> live with initialization-time settings. If you really need it, you'll have to
> explain the reasons.

The question is not if _I_ really need run-time flags but why the api allows to
perform run-time modifications of the clock hierarchy without allowing different
flags? There is clk_set_parent() so I guess clk api knows about run-time changes
already, but you cannot have different flags per parent. And with
__clk_set_flags()
rejected, you are not allowed to change the flags.

I understand that some flags are permanent and required at registration, but
CLK_SET_PARENT_RATE is not. It is not limited by hardware but limited by api.
One way would be a more generic clk-mux with per parent flags, but for
the current
implementation, I cannot see how clk-mux can be exploited here.

I can live with it, because then dynamic muxing of clock hierarchy
within clk-si5351
is just not supported or will break function. Currently, there is no
support for dynamic
muxing, so everything is fine.

>> >On a side note, do you happen to know anyone working on drivers for Si5319 or
>> >Si5368 ?
>>
>> No.
>
> Too bad ... I may have to write that code myself then.

Well, if clk-si5351 will ever get in mainline kernel, feel free to use
it as a template ;)

Sebastian


From jagarwal at nvidia.com  Mon Apr  8 11:41:26 2013
From: jagarwal at nvidia.com (Jay Agarwal)
Date: Mon, 8 Apr 2013 21:11:26 +0530
Subject: [PATCH 1/3] ARM: tegra: pcie: Add tegra3 support
Message-ID: <1365435688-4179-1-git-send-email-jagarwal@nvidia.com>

Signed-off-by: Jay Agarwal <jagarwal at nvidia.com>

- Enable pcie root port 2 for cardhu
- Make private data structure for each SOC
- Add required tegra3 clocks and regulators
- Add tegra3 specific code in enable controller
- Modify clock tree to get clocks based on device
- Based on git://gitorious.org/thierryreding/linux.git

 drivers/clk/tegra/clk-tegra30.c |   12 ++--
 drivers/pci/host/pci-tegra.c    |  146 ++++++++++++++++++++++++++++++++++-----
 2 files changed, 133 insertions(+), 25 deletions(-)

diff --git a/drivers/clk/tegra/clk-tegra30.c b/drivers/clk/tegra/clk-tegra30.c
index ba6f51b..6a80b40 100644
--- a/drivers/clk/tegra/clk-tegra30.c
+++ b/drivers/clk/tegra/clk-tegra30.c
@@ -1592,6 +1592,12 @@ static void __init tegra30_periph_clk_init(void)
 	clk_register_clkdev(clk, "afi", "tegra-pcie");
 	clks[afi] = clk;
 
+	/* pciex */
+	clk = tegra_clk_register_periph_gate("pciex", "pll_e", 0, clk_base, 0,
+				    74, &periph_u_regs, periph_clk_enb_refcnt);
+	clk_register_clkdev(clk, "pciex", NULL);
+	clks[pciex] = clk;
+
 	/* kfuse */
 	clk = tegra_clk_register_periph_gate("kfuse", "clk_m",
 				    TEGRA_PERIPH_ON_APB,
@@ -1710,11 +1716,6 @@ static void __init tegra30_fixed_clk_init(void)
 				1, 0, &cml_lock);
 	clk_register_clkdev(clk, "cml1", NULL);
 	clks[cml1] = clk;
-
-	/* pciex */
-	clk = clk_register_fixed_rate(NULL, "pciex", "pll_e", 0, 100000000);
-	clk_register_clkdev(clk, "pciex", NULL);
-	clks[pciex] = clk;
 }
 
 static void __init tegra30_osc_clk_init(void)
@@ -1930,7 +1931,6 @@ static struct tegra_clk_duplicate tegra_clk_duplicates[] = {
 	TEGRA_CLK_DUPLICATE(bsea, "nvavp", "bsea"),
 	TEGRA_CLK_DUPLICATE(cml1, "tegra_sata_cml", NULL),
 	TEGRA_CLK_DUPLICATE(cml0, "tegra_pcie", "cml"),
-	TEGRA_CLK_DUPLICATE(pciex, "tegra_pcie", "pciex"),
 	TEGRA_CLK_DUPLICATE(vcp, "nvavp", "vcp"),
 	TEGRA_CLK_DUPLICATE(clk_max, NULL, NULL), /* MUST be the last entry */
 };
diff --git a/drivers/pci/host/pci-tegra.c b/drivers/pci/host/pci-tegra.c
index 24085ed..79c0996 100644
--- a/drivers/pci/host/pci-tegra.c
+++ b/drivers/pci/host/pci-tegra.c
@@ -51,7 +51,6 @@
 #include <mach/powergate.h>
 
 #define INT_PCI_MSI_NR (8 * 32)
-#define TEGRA_MAX_PORTS 2
 
 /* register definitions */
 
@@ -143,14 +142,15 @@
 #define  AFI_INTR_EN_DFPCI_DECERR	(1 << 5)
 #define  AFI_INTR_EN_AXI_DECERR		(1 << 6)
 #define  AFI_INTR_EN_FPCI_TIMEOUT	(1 << 7)
+#define AFI_INTR_EN_PRSNT_SENSE		(1 << 8)
 
 #define AFI_PCIE_CONFIG					0x0f8
 #define  AFI_PCIE_CONFIG_PCIE_DISABLE(x)		(1 << ((x) + 1))
 #define  AFI_PCIE_CONFIG_PCIE_DISABLE_ALL		0xe
 #define  AFI_PCIE_CONFIG_SM2TMS0_XBAR_CONFIG_MASK	(0xf << 20)
 #define  AFI_PCIE_CONFIG_SM2TMS0_XBAR_CONFIG_SINGLE	(0x0 << 20)
-#define  AFI_PCIE_CONFIG_SM2TMS0_XBAR_CONFIG_420	(0x0 << 20)
 #define  AFI_PCIE_CONFIG_SM2TMS0_XBAR_CONFIG_DUAL	(0x1 << 20)
+#define  AFI_PCIE_CONFIG_SM2TMS0_XBAR_CONFIG_420	(0x0 << 20)
 #define  AFI_PCIE_CONFIG_SM2TMS0_XBAR_CONFIG_222	(0x1 << 20)
 #define  AFI_PCIE_CONFIG_SM2TMS0_XBAR_CONFIG_411	(0x2 << 20)
 
@@ -161,8 +161,11 @@
 #define AFI_PEX1_CTRL			0x118
 #define AFI_PEX2_CTRL			0x128
 #define  AFI_PEX_CTRL_RST		(1 << 0)
+#define  AFI_PEX_CTRL_CLKREQ_EN		(1 << 1)
 #define  AFI_PEX_CTRL_REFCLK_EN		(1 << 3)
 
+#define  AFI_PEXBIAS_CTRL_0		0x168
+
 #define RP_VEND_XP	0x00000F00
 #define  RP_VEND_XP_DL_UP	(1 << 30)
 
@@ -176,7 +179,8 @@
 #define  PADS_CTL_TX_DATA_EN_1L	(1 << 6)
 #define  PADS_CTL_RX_DATA_EN_1L	(1 << 10)
 
-#define PADS_PLL_CTL				0x000000B8
+#define  PADS_PLL_CTL_T20			0x000000B8
+#define  PADS_PLL_CTL_T30			0x000000B4
 #define  PADS_PLL_CTL_RST_B4SM			(1 << 1)
 #define  PADS_PLL_CTL_LOCKDET			(1 << 8)
 #define  PADS_PLL_CTL_REFCLK_MASK		(0x3 << 16)
@@ -184,8 +188,11 @@
 #define  PADS_PLL_CTL_REFCLK_INTERNAL_CMOS	(1 << 16)
 #define  PADS_PLL_CTL_REFCLK_EXTERNAL		(2 << 16)
 #define  PADS_PLL_CTL_TXCLKREF_MASK		(0x1 << 20)
+#define  PADS_PLL_CTL_TXCLKREF_BUF_EN		(1 << 22)
 #define  PADS_PLL_CTL_TXCLKREF_DIV10		(0 << 20)
 #define  PADS_PLL_CTL_TXCLKREF_DIV5		(1 << 20)
+#define  PADS_REFCLK_CFG0			0x000000C8
+#define  PADS_REFCLK_CFG1			0x000000CC
 
 struct tegra_msi {
 	DECLARE_BITMAP(used, INT_PCI_MSI_NR);
@@ -196,6 +203,19 @@ struct tegra_msi {
 	int irq;
 };
 
+/* used to differente tegra chips code */
+struct tegra_pcie_soc_data {
+	unsigned int num_max_ports;
+	unsigned int pads_pll_ctl;
+	unsigned int tx_ref_sel;
+	unsigned int msi_base_shift;
+	bool pex_clkreq_en;
+	bool pex_bias_ctrl;
+	bool intr_prsnt_sense;
+	bool need_avdd_supply;
+	bool need_cml0_clk;
+};
+
 static inline struct tegra_msi *to_tegra_msi(struct msi_chip *chip)
 {
 	return container_of(chip, struct tegra_msi, chip);
@@ -220,6 +240,7 @@ struct tegra_pcie {
 	struct clk *afi_clk;
 	struct clk *pcie_xclk;
 	struct clk *pll_e;
+	struct clk *cml0_clk;
 
 	struct tegra_msi msi;
 
@@ -229,6 +250,9 @@ struct tegra_pcie {
 
 	struct regulator *pex_clk_supply;
 	struct regulator *vdd_supply;
+	struct regulator *avdd_supply;
+
+	struct tegra_pcie_soc_data *soc_data;
 };
 
 struct tegra_pcie_port {
@@ -511,12 +535,15 @@ static void tegra_pcie_port_reset(struct tegra_pcie_port *port)
 
 static void tegra_pcie_port_enable(struct tegra_pcie_port *port)
 {
+	struct tegra_pcie_soc_data *soc = port->pcie->soc_data;
 	unsigned long ctrl = tegra_pcie_port_get_pex_ctrl(port);
 	unsigned long value;
 
 	/* enable reference clock */
 	value = afi_readl(port->pcie, ctrl);
 	value |= AFI_PEX_CTRL_REFCLK_EN;
+	if (soc->pex_clkreq_en)
+		value |= AFI_PEX_CTRL_CLKREQ_EN;
 	afi_writel(port->pcie, value, ctrl);
 
 	tegra_pcie_port_reset(port);
@@ -569,6 +596,8 @@ static void tegra_pcie_fixup_class(struct pci_dev *dev)
 }
 DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_NVIDIA, 0x0bf0, tegra_pcie_fixup_class);
 DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_NVIDIA, 0x0bf1, tegra_pcie_fixup_class);
+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_NVIDIA, 0x0e1c, tegra_pcie_fixup_class);
+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_NVIDIA, 0x0e1d, tegra_pcie_fixup_class);
 
 /* Tegra PCIE requires relaxed ordering */
 static void tegra_pcie_relax_enable(struct pci_dev *dev)
@@ -749,6 +778,11 @@ static int tegra_pcie_enable_controller(struct tegra_pcie *pcie)
 	struct tegra_pcie_port *port;
 	unsigned int timeout;
 	unsigned long value;
+	struct tegra_pcie_soc_data *soc = pcie->soc_data;
+
+	/* power down to PCIe slot clock bias pad */
+	if (soc->pex_bias_ctrl)
+		afi_writel(pcie, 0, AFI_PEXBIAS_CTRL_0);
 
 	/* configure mode and disable all ports */
 	value = afi_readl(pcie, AFI_PCIE_CONFIG);
@@ -776,26 +810,26 @@ static int tegra_pcie_enable_controller(struct tegra_pcie *pcie)
 	 * Set up PHY PLL inputs select PLLE output as refclock,
 	 * set TX ref sel to div10 (not div5).
 	 */
-	value = pads_readl(pcie, PADS_PLL_CTL);
+	value = pads_readl(pcie, soc->pads_pll_ctl);
 	value &= ~(PADS_PLL_CTL_REFCLK_MASK | PADS_PLL_CTL_TXCLKREF_MASK);
-	value |= (PADS_PLL_CTL_REFCLK_INTERNAL_CML | PADS_PLL_CTL_TXCLKREF_DIV10);
-	pads_writel(pcie, value, PADS_PLL_CTL);
+	value |= PADS_PLL_CTL_REFCLK_INTERNAL_CML | soc->tx_ref_sel;
+	pads_writel(pcie, value, soc->pads_pll_ctl);
 
 	/* take PLL out of reset  */
-	value = pads_readl(pcie, PADS_PLL_CTL);
+	value = pads_readl(pcie, soc->pads_pll_ctl);
 	value |= PADS_PLL_CTL_RST_B4SM;
-	pads_writel(pcie, value, PADS_PLL_CTL);
+	pads_writel(pcie, value, soc->pads_pll_ctl);
 
 	/*
 	 * Hack, set the clock voltage to the DEFAULT provided by hw folks.
 	 * This doesn't exist in the documentation.
 	 */
-	pads_writel(pcie, 0xfa5cfa5c, 0xc8);
+	pads_writel(pcie, 0xfa5cfa5c, PADS_REFCLK_CFG0);
 
 	/* wait for the PLL to lock */
 	timeout = 300;
 	do {
-		value = pads_readl(pcie, PADS_PLL_CTL);
+		value = pads_readl(pcie, soc->pads_pll_ctl);
 		usleep_range(1000, 1000);
 		if (--timeout == 0) {
 			pr_err("Tegra PCIe error: timeout waiting for PLL\n");
@@ -824,6 +858,8 @@ static int tegra_pcie_enable_controller(struct tegra_pcie *pcie)
 	value = AFI_INTR_EN_INI_SLVERR | AFI_INTR_EN_INI_DECERR |
 		AFI_INTR_EN_TGT_SLVERR | AFI_INTR_EN_TGT_DECERR |
 		AFI_INTR_EN_TGT_WRERR | AFI_INTR_EN_DFPCI_DECERR;
+	if (soc->intr_prsnt_sense)
+		value |= AFI_INTR_EN_PRSNT_SENSE;
 	afi_writel(pcie, value, AFI_AFI_INTR_ENABLE);
 	afi_writel(pcie, 0xffffffff, AFI_SM_INTR_ENABLE);
 
@@ -838,6 +874,7 @@ static int tegra_pcie_enable_controller(struct tegra_pcie *pcie)
 
 static void tegra_pcie_power_off(struct tegra_pcie *pcie)
 {
+	struct tegra_pcie_soc_data *soc = pcie->soc_data;
 	int err;
 
 	/* TODO: disable and unprepare clocks? */
@@ -849,19 +886,26 @@ static void tegra_pcie_power_off(struct tegra_pcie *pcie)
 	tegra_powergate_power_off(TEGRA_POWERGATE_PCIE);
 	tegra_pmc_pcie_xclk_clamp(true);
 
+	if (soc->need_avdd_supply) {
+		err = regulator_disable(pcie->avdd_supply);
+		if (err < 0)
+			dev_warn(pcie->dev, "failed to disable AVDD regulator: %d\n",
+			err);
+	}
 	err = regulator_disable(pcie->pex_clk_supply);
 	if (err < 0)
-		dev_err(pcie->dev, "failed to disable pex-clk regulator: %d\n",
+		dev_warn(pcie->dev, "failed to disable pex-clk regulator: %d\n",
 			err);
 
 	err = regulator_disable(pcie->vdd_supply);
 	if (err < 0)
-		dev_err(pcie->dev, "failed to disable VDD regulator: %d\n",
+		dev_warn(pcie->dev, "failed to disable VDD regulator: %d\n",
 			err);
 }
 
 static int tegra_pcie_power_on(struct tegra_pcie *pcie)
 {
+	struct tegra_pcie_soc_data *soc = pcie->soc_data;
 	int err;
 
 	tegra_periph_reset_assert(pcie->pcie_xclk);
@@ -885,6 +929,15 @@ static int tegra_pcie_power_on(struct tegra_pcie *pcie)
 		return err;
 	}
 
+	if (soc->need_avdd_supply) {
+		err = regulator_enable(pcie->avdd_supply);
+		if (err < 0) {
+			dev_err(pcie->dev, "failed to enable AVDD regulator: %d\n",
+				err);
+			return err;
+		}
+	}
+
 	err = tegra_powergate_sequence_power_up(TEGRA_POWERGATE_PCIE,
 						pcie->pex_clk);
 	if (err) {
@@ -902,6 +955,15 @@ static int tegra_pcie_power_on(struct tegra_pcie *pcie)
 		return err;
 	}
 
+	if (soc->need_cml0_clk) {
+		err = clk_prepare_enable(pcie->cml0_clk);
+		if (err < 0) {
+			dev_err(pcie->dev, "failed to enable cml0 clock: %d\n",
+				err);
+			return err;
+		}
+	}
+
 	err = clk_prepare_enable(pcie->pll_e);
 	if (err < 0) {
 		dev_err(pcie->dev, "failed to enable PLLE clock: %d\n", err);
@@ -913,6 +975,8 @@ static int tegra_pcie_power_on(struct tegra_pcie *pcie)
 
 static int tegra_pcie_clocks_get(struct tegra_pcie *pcie)
 {
+	struct tegra_pcie_soc_data *soc = pcie->soc_data;
+
 	pcie->pex_clk = devm_clk_get(pcie->dev, "pex");
 	if (IS_ERR(pcie->pex_clk))
 		return PTR_ERR(pcie->pex_clk);
@@ -929,6 +993,11 @@ static int tegra_pcie_clocks_get(struct tegra_pcie *pcie)
 	if (IS_ERR(pcie->pll_e))
 		return PTR_ERR(pcie->pll_e);
 
+	if (soc->need_cml0_clk) {
+		pcie->cml0_clk = devm_clk_get(pcie->dev, "cml0");
+		if (IS_ERR(pcie->cml0_clk))
+			return PTR_ERR(pcie->cml0_clk);
+	}
 	return 0;
 }
 
@@ -1151,6 +1220,7 @@ static int tegra_pcie_enable_msi(struct tegra_pcie *pcie)
 {
 	struct platform_device *pdev = to_platform_device(pcie->dev);
 	struct tegra_msi *msi = &pcie->msi;
+	struct tegra_pcie_soc_data *soc = pcie->soc_data;
 	unsigned long base;
 	int err;
 	u32 reg;
@@ -1187,7 +1257,7 @@ static int tegra_pcie_enable_msi(struct tegra_pcie *pcie)
 	msi->pages = __get_free_pages(GFP_KERNEL, 3);
 	base = virt_to_phys((void *)msi->pages);
 
-	afi_writel(pcie, base, AFI_MSI_FPCI_BAR_ST);
+	afi_writel(pcie, base >> soc->msi_base_shift, AFI_MSI_FPCI_BAR_ST);
 	afi_writel(pcie, base, AFI_MSI_AXI_BAR_ST);
 	/* this register is in 4K increments */
 	afi_writel(pcie, 1, AFI_MSI_BAR_SZ);
@@ -1284,6 +1354,7 @@ static u32 tegra_pcie_get_xbar_config(struct tegra_pcie *pcie, u32 lanes)
 static int tegra_pcie_parse_dt(struct tegra_pcie *pcie)
 {
 	struct device_node *np = pcie->dev->of_node, *port;
+	struct tegra_pcie_soc_data *soc = pcie->soc_data;
 	const __be32 *range = NULL;
 	struct resource res;
 	u32 lanes = 0;
@@ -1297,6 +1368,12 @@ static int tegra_pcie_parse_dt(struct tegra_pcie *pcie)
 	if (IS_ERR(pcie->pex_clk_supply))
 		return PTR_ERR(pcie->pex_clk_supply);
 
+	if (soc->need_avdd_supply) {
+		pcie->avdd_supply = devm_regulator_get(pcie->dev, "avdd");
+		if (IS_ERR(pcie->avdd_supply))
+			return PTR_ERR(pcie->avdd_supply);
+	}
+
 	while ((range = of_pci_process_ranges(np, &res, range)) != NULL) {
 		switch (res.flags & IORESOURCE_TYPE_BITS) {
 		case IORESOURCE_IO:
@@ -1341,7 +1418,7 @@ static int tegra_pcie_parse_dt(struct tegra_pcie *pcie)
 
 		index = PCI_SLOT(err);
 
-		if (index < 1 || index > TEGRA_MAX_PORTS) {
+		if (index < 1 || index > pcie->soc_data->num_max_ports) {
 			dev_err(pcie->dev, "invalid port number: %d\n", index);
 			return -EINVAL;
 		}
@@ -1477,8 +1554,39 @@ static int tegra_pcie_enable(struct tegra_pcie *pcie)
 	return 0;
 }
 
+static const struct tegra_pcie_soc_data tegra20_pcie_data = {
+	.num_max_ports = 2,
+	.pads_pll_ctl = PADS_PLL_CTL_T20,
+	.tx_ref_sel = PADS_PLL_CTL_TXCLKREF_DIV10,
+	.msi_base_shift = 0,
+	.pex_clkreq_en = false,
+	.pex_bias_ctrl = false,
+	.intr_prsnt_sense = false,
+	.need_avdd_supply = false,
+	.need_cml0_clk = false,
+};
+
+static const struct tegra_pcie_soc_data tegra30_pcie_data = {
+	.num_max_ports = 3,
+	.pads_pll_ctl = PADS_PLL_CTL_T30,
+	.tx_ref_sel = PADS_PLL_CTL_TXCLKREF_BUF_EN,
+	.msi_base_shift = 8,
+	.pex_clkreq_en = true,
+	.pex_bias_ctrl = true,
+	.intr_prsnt_sense = true,
+	.need_avdd_supply = true,
+	.need_cml0_clk = true,
+};
+
+static const struct of_device_id tegra_pcie_of_match[] = {
+	{ .compatible = "nvidia,tegra30-pcie", .data = &tegra30_pcie_data},
+	{ .compatible = "nvidia,tegra20-pcie", .data = &tegra20_pcie_data},
+	{ },
+};
+
 static int tegra_pcie_probe(struct platform_device *pdev)
 {
+	const struct of_device_id *match;
 	struct tegra_pcie *pcie;
 	int err;
 
@@ -1489,6 +1597,11 @@ static int tegra_pcie_probe(struct platform_device *pdev)
 	INIT_LIST_HEAD(&pcie->busses);
 	INIT_LIST_HEAD(&pcie->ports);
 	pcie->dev = &pdev->dev;
+	match = of_match_device(tegra_pcie_of_match, &pdev->dev);
+	if (match)
+		pcie->soc_data = (struct tegra_pcie_soc_data *)match->data;
+	else
+		return -ENODEV;
 
 	err = tegra_pcie_parse_dt(pcie);
 	if (err < 0)
@@ -1560,11 +1673,6 @@ static int tegra_pcie_remove(struct platform_device *pdev)
 	return 0;
 }
 
-static const struct of_device_id tegra_pcie_of_match[] = {
-	{ .compatible = "nvidia,tegra20-pcie", },
-	{ },
-};
-
 static struct platform_driver tegra_pcie_driver = {
 	.driver = {
 		.name = "tegra-pcie",
-- 
1.7.0.4



From jagarwal at nvidia.com  Mon Apr  8 11:41:27 2013
From: jagarwal at nvidia.com (Jay Agarwal)
Date: Mon, 8 Apr 2013 21:11:27 +0530
Subject: [PATCH 2/3] ARM: dts: tegra: Correct PCIe entry
In-Reply-To: <1365435688-4179-1-git-send-email-jagarwal@nvidia.com>
References: <1365435688-4179-1-git-send-email-jagarwal@nvidia.com>
Message-ID: <1365435688-4179-2-git-send-email-jagarwal@nvidia.com>

Signed-off-by: Jay Agarwal <jagarwal at nvidia.com>

- Add interrupt-names property
- Correct downstream I/O size
- Correct cml clock name for tegra30
- Based on git://gitorious.org/thierryreding/linux.git

 arch/arm/boot/dts/tegra30.dtsi |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/tegra30.dtsi b/arch/arm/boot/dts/tegra30.dtsi
index 5a270ff..289ef93 100644
--- a/arch/arm/boot/dts/tegra30.dtsi
+++ b/arch/arm/boot/dts/tegra30.dtsi
@@ -124,7 +124,7 @@
 		reg-names = "pads", "afi", "cs";
 		interrupts = <0 98 0x04   /* controller interrupt */
 		              0 99 0x04>; /* MSI interrupt */
-
+		interrupt-names = "intr", "msi";
 		bus-range = <0x00 0xff>;
 		#address-cells = <3>;
 		#size-cells = <2>;
@@ -132,13 +132,13 @@
 		ranges = <0x82000000 0 0x00000000 0x00000000 0 0x00001000   /* port 0 configuration space */
 			  0x82000000 0 0x00001000 0x00001000 0 0x00001000   /* port 1 configuration space */
 			  0x82000000 0 0x00004000 0x00004000 0 0x00001000   /* port 2 configuration space */
-			  0x81000000 0 0          0x02000000 0 0x00010000   /* downstream I/O */
+			  0x81000000 0 0          0x02000000 0 0x00100000   /* downstream I/O */
 			  0x82000000 0 0x20000000 0x20000000 0 0x10000000   /* non-prefetchable memory */
 			  0xc2000000 0 0x30000000 0x30000000 0 0x10000000>; /* prefetchable memory */
 
 		clocks = <&tegra_car 70>, <&tegra_car 72>, <&tegra_car 74>,
 			 <&tegra_car 118>, <&tegra_car 215>;
-		clock-names = "pex", "afi", "pcie_xclk", "pll_e", "cml";
+		clock-names = "pex", "afi", "pcie_xclk", "pll_e", "cml0";
 		status = "disabled";
 
 		pci at 1,0 {
-- 
1.7.0.4



From jagarwal at nvidia.com  Mon Apr  8 11:41:28 2013
From: jagarwal at nvidia.com (Jay Agarwal)
Date: Mon, 8 Apr 2013 21:11:28 +0530
Subject: [PATCH 3/3] ARM: dts: tegra: Add PCIe entry for cardhu
In-Reply-To: <1365435688-4179-1-git-send-email-jagarwal@nvidia.com>
References: <1365435688-4179-1-git-send-email-jagarwal@nvidia.com>
Message-ID: <1365435688-4179-3-git-send-email-jagarwal@nvidia.com>

Signed-off-by: Jay Agarwal <jagarwal at nvidia.com>

- Add PCIe node entry for cardhu
- Enable only root port 2
- Initialize regulators required for tegra30
- Based on git://gitorious.org/thierryreding/linux.git

 arch/arm/boot/dts/tegra30-cardhu.dtsi |   11 +++++++++++
 1 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/tegra30-cardhu.dtsi b/arch/arm/boot/dts/tegra30-cardhu.dtsi
index d2fdf95..b64113e 100644
--- a/arch/arm/boot/dts/tegra30-cardhu.dtsi
+++ b/arch/arm/boot/dts/tegra30-cardhu.dtsi
@@ -137,6 +137,17 @@
 		};
 	};
 
+	pcie-controller {
+		status = "okay";
+		pex-clk-supply = <&pex_hvdd_3v3_reg>;
+		vdd-supply = <&ldo1_reg>;
+		avdd-supply = <&ldo2_reg>;
+
+		pci at 3,0 {
+			status = "okay";
+		};
+	};
+
 	serial at 70006000 {
 		status = "okay";
 	};
-- 
1.7.0.4



From nicolas.ferre at atmel.com  Mon Apr  8 11:44:58 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Mon, 8 Apr 2013 17:44:58 +0200
Subject: [PATCH] ARM: at91: remove unused dbgu_readl() macro
In-Reply-To: <1364981103-22980-1-git-send-email-nicolas.ferre@atmel.com>
References: <1364981103-22980-1-git-send-email-nicolas.ferre@atmel.com>
Message-ID: <5162E5FA.8080807@atmel.com>

On 04/03/2013 11:25 AM, Nicolas Ferre :
> Signed-off-by: Nicolas Ferre <nicolas.ferre at atmel.com>

I stack this up on at91-3.10-cleanup right now.

> ---
>  arch/arm/mach-at91/include/mach/at91_dbgu.h | 3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/arch/arm/mach-at91/include/mach/at91_dbgu.h b/arch/arm/mach-at91/include/mach/at91_dbgu.h
> index 2aa0c5e..3b59485 100644
> --- a/arch/arm/mach-at91/include/mach/at91_dbgu.h
> +++ b/arch/arm/mach-at91/include/mach/at91_dbgu.h
> @@ -16,9 +16,6 @@
>  #ifndef AT91_DBGU_H
>  #define AT91_DBGU_H
>  
> -#define dbgu_readl(dbgu, field) \
> -	__raw_readl(AT91_VA_BASE_SYS + dbgu + AT91_DBGU_ ## field)
> -
>  #if !defined(CONFIG_ARCH_AT91X40)
>  #define AT91_DBGU_CR		(0x00)	/* Control Register */
>  #define AT91_DBGU_MR		(0x04)	/* Mode Register */
> 


-- 
Nicolas Ferre


From nicolas.ferre at atmel.com  Mon Apr  8 11:47:25 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Mon, 8 Apr 2013 17:47:25 +0200
Subject: [PATCH 1/2] ARM: at91/setup: fix trivial typos
In-Reply-To: <1365346199-29525-1-git-send-email-jhovold@gmail.com>
References: <1365346199-29525-1-git-send-email-jhovold@gmail.com>
Message-ID: <5162E68D.5070909@atmel.com>

On 04/07/2013 04:49 PM, Johan Hovold :
> Fix a few trivial typos in panic, warning and debug messages.
> 
> Signed-off-by: Johan Hovold <jhovold at gmail.com>

Acked-by: Nicolas Ferre <nicolas.ferre at atmel.com>

> ---
>  arch/arm/mach-at91/setup.c | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm/mach-at91/setup.c b/arch/arm/mach-at91/setup.c
> index 4b67847..9e7c1e1 100644
> --- a/arch/arm/mach-at91/setup.c
> +++ b/arch/arm/mach-at91/setup.c
> @@ -333,7 +333,7 @@ static void at91_dt_rstc(void)
>  
>  	of_id = of_match_node(rstc_ids, np);
>  	if (!of_id)
> -		panic("AT91: rtsc no restart function availlable\n");
> +		panic("AT91: rtsc no restart function available\n");

This one is stacked up.

>  
>  	arm_pm_restart = of_id->data;
>  
> @@ -353,7 +353,7 @@ static void at91_dt_ramc(void)
>  
>  	np = of_find_matching_node(NULL, ramc_ids);
>  	if (!np)
> -		panic("unable to find compatible ram conroller node in dtb\n");
> +		panic("unable to find compatible ram controller node in dtb\n");
>  
>  	at91_ramc_base[0] = of_iomap(np, 0);
>  	if (!at91_ramc_base[0])
> @@ -403,7 +403,7 @@ static void at91_dt_shdwc(void)
>  
>  	np = of_find_matching_node(NULL, shdwc_ids);
>  	if (!np) {
> -		pr_debug("AT91: unable to find compatible shutdown (shdwc) conroller node in dtb\n");
> +		pr_debug("AT91: unable to find compatible shutdown (shdwc) controller node in dtb\n");
>  		return;
>  	}
>  
> @@ -419,7 +419,7 @@ static void at91_dt_shdwc(void)
>  
>  	if (!of_property_read_u32(np, "atmel,wakeup-counter", &reg)) {
>  		if (reg > AT91_SHDW_CPTWK0_MAX) {
> -			pr_warn("AT91: shdwc wakeup conter 0x%x > 0x%x reduce it to 0x%x\n",
> +			pr_warn("AT91: shdwc wakeup counter 0x%x > 0x%x reduce it to 0x%x\n",
>  				reg, AT91_SHDW_CPTWK0_MAX, AT91_SHDW_CPTWK0_MAX);
>  			reg = AT91_SHDW_CPTWK0_MAX;
>  		}

The remaining bytes are now included in at91-3.10-cleanup branch.

Thanks,
-- 
Nicolas Ferre


From marc.zyngier at arm.com  Mon Apr  8 11:47:18 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon,  8 Apr 2013 16:47:18 +0100
Subject: [PATCH 1/2] ARM: KVM: add architecture specific hook for capabilities
In-Reply-To: <1365436039-29564-1-git-send-email-marc.zyngier@arm.com>
References: <1365436039-29564-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1365436039-29564-2-git-send-email-marc.zyngier@arm.com>

Most of the capabilities are common to both arm and arm64, but
we still need to handle the exceptions.

Introduce kvm_arch_dev_ioctl_check_extention, which both architectures
implement (in the 32bit case, it just returns 0).

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm/include/asm/kvm_host.h | 5 +++++
 arch/arm/kvm/arm.c              | 2 +-
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
index 78813b8..a81480c 100644
--- a/arch/arm/include/asm/kvm_host.h
+++ b/arch/arm/include/asm/kvm_host.h
@@ -207,6 +207,11 @@ static inline void __cpu_init_hyp_mode(unsigned long long pgd_ptr,
 	kvm_call_hyp((void *)pgd_low, pgd_high, hyp_stack_ptr, vector_ptr);
 }
 
+static inline int kvm_arch_dev_ioctl_check_extention(long ext)
+{
+	return 0;
+}
+
 int kvm_perf_init(void);
 int kvm_perf_teardown(void);
 
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index 61f7394..ed7b1e3 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -206,7 +206,7 @@ int kvm_dev_ioctl_check_extension(long ext)
 		r = KVM_MAX_VCPUS;
 		break;
 	default:
-		r = 0;
+		r = kvm_arch_dev_ioctl_check_extention(ext);
 		break;
 	}
 	return r;
-- 
1.8.1.4




From marc.zyngier at arm.com  Mon Apr  8 11:47:19 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon,  8 Apr 2013 16:47:19 +0100
Subject: [PATCH 2/2] ARM: KVM: promote vfp_host pointer to generic host cpu
 context
In-Reply-To: <1365436039-29564-1-git-send-email-marc.zyngier@arm.com>
References: <1365436039-29564-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1365436039-29564-3-git-send-email-marc.zyngier@arm.com>

We use the vfp_host pointer to store the host VFP context, should
the guest start using VFP itself.

Actually, we can use this pointer in a more generic way to store
CPU speficic data, and arm64 is using it to dump the whole host
state before switching to the guest.

Simply rename the vfp_host field to host_cpu_context, and the
corresponding type to kvm_cpu_context_t. No change in functionnality.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm/include/asm/kvm_host.h |  8 +++++---
 arch/arm/kernel/asm-offsets.c   |  2 +-
 arch/arm/kvm/arm.c              | 28 ++++++++++++++--------------
 3 files changed, 20 insertions(+), 18 deletions(-)

diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
index a81480c..a856cc2 100644
--- a/arch/arm/include/asm/kvm_host.h
+++ b/arch/arm/include/asm/kvm_host.h
@@ -87,7 +87,7 @@ struct kvm_vcpu_fault_info {
 	u32 hyp_pc;		/* PC when exception was taken from Hyp mode */
 };
 
-typedef struct vfp_hard_struct kvm_kernel_vfp_t;
+typedef struct vfp_hard_struct kvm_cpu_context_t;
 
 struct kvm_vcpu_arch {
 	struct kvm_regs regs;
@@ -105,8 +105,10 @@ struct kvm_vcpu_arch {
 	struct kvm_vcpu_fault_info fault;
 
 	/* Floating point registers (VFP and Advanced SIMD/NEON) */
-	kvm_kernel_vfp_t vfp_guest;
-	kvm_kernel_vfp_t *vfp_host;
+	struct vfp_hard_struct vfp_guest;
+
+	/* Host FP context */
+	kvm_cpu_context_t *host_cpu_context;
 
 	/* VGIC state */
 	struct vgic_cpu vgic_cpu;
diff --git a/arch/arm/kernel/asm-offsets.c b/arch/arm/kernel/asm-offsets.c
index ee1ac39..92562a2 100644
--- a/arch/arm/kernel/asm-offsets.c
+++ b/arch/arm/kernel/asm-offsets.c
@@ -154,7 +154,7 @@ int main(void)
   DEFINE(VCPU_MIDR,		offsetof(struct kvm_vcpu, arch.midr));
   DEFINE(VCPU_CP15,		offsetof(struct kvm_vcpu, arch.cp15));
   DEFINE(VCPU_VFP_GUEST,	offsetof(struct kvm_vcpu, arch.vfp_guest));
-  DEFINE(VCPU_VFP_HOST,		offsetof(struct kvm_vcpu, arch.vfp_host));
+  DEFINE(VCPU_VFP_HOST,		offsetof(struct kvm_vcpu, arch.host_cpu_context));
   DEFINE(VCPU_REGS,		offsetof(struct kvm_vcpu, arch.regs));
   DEFINE(VCPU_USR_REGS,		offsetof(struct kvm_vcpu, arch.regs.usr_regs));
   DEFINE(VCPU_SVC_REGS,		offsetof(struct kvm_vcpu, arch.regs.svc_regs));
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index ed7b1e3..47cfcc3 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -48,7 +48,7 @@ __asm__(".arch_extension	virt");
 #endif
 
 static DEFINE_PER_CPU(unsigned long, kvm_arm_hyp_stack_page);
-static kvm_kernel_vfp_t __percpu *kvm_host_vfp_state;
+static kvm_cpu_context_t __percpu *kvm_host_cpu_state;
 static unsigned long hyp_default_vectors;
 
 /* Per-CPU variable containing the currently running vcpu. */
@@ -326,7 +326,7 @@ void kvm_arch_vcpu_uninit(struct kvm_vcpu *vcpu)
 void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
 {
 	vcpu->cpu = cpu;
-	vcpu->arch.vfp_host = this_cpu_ptr(kvm_host_vfp_state);
+	vcpu->arch.host_cpu_context = this_cpu_ptr(kvm_host_cpu_state);
 
 	/*
 	 * Check whether this vcpu requires the cache to be flushed on
@@ -890,24 +890,24 @@ static int init_hyp_mode(void)
 	}
 
 	/*
-	 * Map the host VFP structures
+	 * Map the host CPU structures
 	 */
-	kvm_host_vfp_state = alloc_percpu(kvm_kernel_vfp_t);
-	if (!kvm_host_vfp_state) {
+	kvm_host_cpu_state = alloc_percpu(kvm_cpu_context_t);
+	if (!kvm_host_cpu_state) {
 		err = -ENOMEM;
-		kvm_err("Cannot allocate host VFP state\n");
+		kvm_err("Cannot allocate host CPU state\n");
 		goto out_free_mappings;
 	}
 
 	for_each_possible_cpu(cpu) {
-		kvm_kernel_vfp_t *vfp;
+		kvm_cpu_context_t *cpu_ctxt;
 
-		vfp = per_cpu_ptr(kvm_host_vfp_state, cpu);
-		err = create_hyp_mappings(vfp, vfp + 1);
+		cpu_ctxt = per_cpu_ptr(kvm_host_cpu_state, cpu);
+		err = create_hyp_mappings(cpu_ctxt, cpu_ctxt + 1);
 
 		if (err) {
-			kvm_err("Cannot map host VFP state: %d\n", err);
-			goto out_free_vfp;
+			kvm_err("Cannot map host CPU state: %d\n", err);
+			goto out_free_context;
 		}
 	}
 
@@ -916,7 +916,7 @@ static int init_hyp_mode(void)
 	 */
 	err = kvm_vgic_hyp_init();
 	if (err)
-		goto out_free_vfp;
+		goto out_free_context;
 
 #ifdef CONFIG_KVM_ARM_VGIC
 		vgic_present = true;
@@ -934,8 +934,8 @@ static int init_hyp_mode(void)
 	kvm_info("Hyp mode initialized successfully\n");
 
 	return 0;
-out_free_vfp:
-	free_percpu(kvm_host_vfp_state);
+out_free_context:
+	free_percpu(kvm_host_cpu_state);
 out_free_mappings:
 	free_hyp_pmds();
 out_free_stack_pages:
-- 
1.8.1.4




From marc.zyngier at arm.com  Mon Apr  8 11:47:17 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon,  8 Apr 2013 16:47:17 +0100
Subject: [PATCH 0/2] ARM: KVM: pre-KVM/arm64 patches
Message-ID: <1365436039-29564-1-git-send-email-marc.zyngier@arm.com>

This series contains two small changes to KVM/ARM, in preparation for
the arm64 patches. None of these changes actually affect the 32bit
implementation.

This has been tested on both arm (VE TC2) and arm64 (Foundation Model).

Marc Zyngier (2):
  ARM: KVM: add architecture specific hook for capabilities
  ARM: KVM: promote vfp_host pointer to generic host cpu context

 arch/arm/include/asm/kvm_host.h | 13 ++++++++++---
 arch/arm/kernel/asm-offsets.c   |  2 +-
 arch/arm/kvm/arm.c              | 30 +++++++++++++++---------------
 3 files changed, 26 insertions(+), 19 deletions(-)

-- 
1.8.1.4




From nicolas.ferre at atmel.com  Mon Apr  8 11:49:24 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Mon, 8 Apr 2013 17:49:24 +0200
Subject: [PATCH 2/2] ARM: at91: remove trailing semicolon from macros
In-Reply-To: <1365346199-29525-2-git-send-email-jhovold@gmail.com>
References: <1365346199-29525-1-git-send-email-jhovold@gmail.com>
 <1365346199-29525-2-git-send-email-jhovold@gmail.com>
Message-ID: <5162E704.4020805@atmel.com>

On 04/07/2013 04:49 PM, Johan Hovold :
> Remove trailing semicolon from register-access macros.
> 
> Signed-off-by: Johan Hovold <jhovold at gmail.com>

Acked-by: Nicolas Ferre <nicolas.ferre at atmel.com>

Now in at91-3.10-cleanup. Thanks,

> ---
>  arch/arm/mach-at91/at91_rstc.h                | 2 +-
>  arch/arm/mach-at91/at91_shdwc.h               | 2 +-
>  arch/arm/mach-at91/at91x40_time.c             | 2 +-
>  arch/arm/mach-at91/include/mach/at91_matrix.h | 2 +-
>  arch/arm/mach-at91/include/mach/at91_st.h     | 2 +-
>  5 files changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/arm/mach-at91/at91_rstc.h b/arch/arm/mach-at91/at91_rstc.h
> index 875fa33..a600e69 100644
> --- a/arch/arm/mach-at91/at91_rstc.h
> +++ b/arch/arm/mach-at91/at91_rstc.h
> @@ -23,7 +23,7 @@ extern void __iomem *at91_rstc_base;
>  	__raw_readl(at91_rstc_base + field)
>  
>  #define at91_rstc_write(field, value) \
> -	__raw_writel(value, at91_rstc_base + field);
> +	__raw_writel(value, at91_rstc_base + field)
>  #else
>  .extern at91_rstc_base
>  #endif
> diff --git a/arch/arm/mach-at91/at91_shdwc.h b/arch/arm/mach-at91/at91_shdwc.h
> index 60478ea..9e29f31 100644
> --- a/arch/arm/mach-at91/at91_shdwc.h
> +++ b/arch/arm/mach-at91/at91_shdwc.h
> @@ -23,7 +23,7 @@ extern void __iomem *at91_shdwc_base;
>  	__raw_readl(at91_shdwc_base + field)
>  
>  #define at91_shdwc_write(field, value) \
> -	__raw_writel(value, at91_shdwc_base + field);
> +	__raw_writel(value, at91_shdwc_base + field)
>  #endif
>  
>  #define AT91_SHDW_CR		0x00			/* Shut Down Control Register */
> diff --git a/arch/arm/mach-at91/at91x40_time.c b/arch/arm/mach-at91/at91x40_time.c
> index 0e57e44..f4c81c2 100644
> --- a/arch/arm/mach-at91/at91x40_time.c
> +++ b/arch/arm/mach-at91/at91x40_time.c
> @@ -33,7 +33,7 @@
>  	__raw_readl(AT91_IO_P2V(AT91_TC) + field)
>  
>  #define at91_tc_write(field, value) \
> -	__raw_writel(value, AT91_IO_P2V(AT91_TC) + field);
> +	__raw_writel(value, AT91_IO_P2V(AT91_TC) + field)
>  
>  /*
>   *	3 counter/timer units present.
> diff --git a/arch/arm/mach-at91/include/mach/at91_matrix.h b/arch/arm/mach-at91/include/mach/at91_matrix.h
> index 02fae9d..f8996c9 100644
> --- a/arch/arm/mach-at91/include/mach/at91_matrix.h
> +++ b/arch/arm/mach-at91/include/mach/at91_matrix.h
> @@ -14,7 +14,7 @@ extern void __iomem *at91_matrix_base;
>  	__raw_readl(at91_matrix_base + field)
>  
>  #define at91_matrix_write(field, value) \
> -	__raw_writel(value, at91_matrix_base + field);
> +	__raw_writel(value, at91_matrix_base + field)
>  
>  #else
>  .extern at91_matrix_base
> diff --git a/arch/arm/mach-at91/include/mach/at91_st.h b/arch/arm/mach-at91/include/mach/at91_st.h
> index 969aac2..67fdbd1 100644
> --- a/arch/arm/mach-at91/include/mach/at91_st.h
> +++ b/arch/arm/mach-at91/include/mach/at91_st.h
> @@ -23,7 +23,7 @@ extern void __iomem *at91_st_base;
>  	__raw_readl(at91_st_base + field)
>  
>  #define at91_st_write(field, value) \
> -	__raw_writel(value, at91_st_base + field);
> +	__raw_writel(value, at91_st_base + field)
>  #else
>  .extern at91_st_base
>  #endif
> 


-- 
Nicolas Ferre


From arnd at arndb.de  Mon Apr  8 11:49:27 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 8 Apr 2013 17:49:27 +0200
Subject: [GIT PULL] mxs fixes for 3.9, take 4
In-Reply-To: <20130403125620.GA21790@S2101-09.ap.freescale.net>
References: <20130403125620.GA21790@S2101-09.ap.freescale.net>
Message-ID: <201304081749.27633.arnd@arndb.de>

On Wednesday 03 April 2013, Shawn Guo wrote:
> The following changes since commit 07961ac7c0ee8b546658717034fe692fd12eefa9:
> 
>   Linux 3.9-rc5 (2013-03-31 15:12:43 -0700)
> 
> are available in the git repository at:
> 
>   git://git.linaro.org/people/shawnguo/linux-2.6.git tags/mxs-fixes-3.9-4
> 
> for you to fetch changes up to 55985e15b80beb339d3e332f00a26003deff14e6:
> 
>   ARM: mxs: Slow down the I2C clock speed (2013-04-03 09:34:01 +0800)

Pulled into fixes branch. I'll send it out in the next few days, waiting
for more to come in right now, as there are only two patches in the branch
at the moment.

	Arnd


From sameo at linux.intel.com  Mon Apr  8 11:51:37 2013
From: sameo at linux.intel.com (Samuel Ortiz)
Date: Mon, 8 Apr 2013 17:51:37 +0200
Subject: [PATCH v10 02/12] mfd: palmas: is_palmas_charger needed by
 multiple drivers
In-Reply-To: <1363964122-19201-3-git-send-email-ian@slimlogic.co.uk>
References: <1363964122-19201-1-git-send-email-ian@slimlogic.co.uk>
 <1363964122-19201-3-git-send-email-ian@slimlogic.co.uk>
Message-ID: <20130408155137.GY24058@zurbaran>

Hi Ian,

On Fri, Mar 22, 2013 at 02:55:12PM +0000, Ian Lartey wrote:
> is_palmas_charger checks for the presence of charging
> functionality in the device
> 
> Signed-off-by: Graeme Gregory <gg at slimlogic.co.uk>
> Signed-off-by: Ian Lartey <ian at slimlogic.co.uk>
> Acked-by: Laxman Dewangani <ldewangan at nvidia.com>
> ---
>  include/linux/mfd/palmas.h |   12 +++++++++++-
>  1 files changed, 11 insertions(+), 1 deletions(-)
I applied this one now, thanks.

Cheers,
Samuel.

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


From peter.maydell at linaro.org  Mon Apr  8 11:53:33 2013
From: peter.maydell at linaro.org (Peter Maydell)
Date: Mon, 8 Apr 2013 16:53:33 +0100
Subject: [PATCH 1/2] ARM: KVM: add architecture specific hook for
 capabilities
In-Reply-To: <1365436039-29564-2-git-send-email-marc.zyngier@arm.com>
References: <1365436039-29564-1-git-send-email-marc.zyngier@arm.com>
 <1365436039-29564-2-git-send-email-marc.zyngier@arm.com>
Message-ID: <CAFEAcA-WQO7cdi25-Bu5Yj3yN0PgUmEezHpdhR7dfQ_2y+Z0vg@mail.gmail.com>

On 8 April 2013 16:47, Marc Zyngier <marc.zyngier at arm.com> wrote:
> Most of the capabilities are common to both arm and arm64, but
> we still need to handle the exceptions.
>
> Introduce kvm_arch_dev_ioctl_check_extention, which both architectures

"extension" (here and in the code itself).

-- PMM


From arnd at arndb.de  Mon Apr  8 11:54:55 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 8 Apr 2013 17:54:55 +0200
Subject: [GIT PULL] Update for Renesas INTC External IRQ pin driver for
 v3.10
In-Reply-To: <1364540207-7699-1-git-send-email-horms+renesas@verge.net.au>
References: <1364540207-7699-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <201304081754.55689.arnd@arndb.de>

On Friday 29 March 2013, Simon Horman wrote:
> Hi Arnd, Hi Olof,
> 
> The following changes since commit 3b8dfa7c2f8af7613dae28ac0f3419bf75ead5d0:
> 
>   irqchip: irqc: Add DT support (2013-03-18 21:26:07 +0900)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-intc-external-irq2-for-v3.10
> 

Pulled into next/drivers, thanks!

Sorry for the slight delay in processing this.

	Arnd


From gg at slimlogic.co.uk  Mon Apr  8 11:55:58 2013
From: gg at slimlogic.co.uk (Graeme Gregory)
Date: Mon, 08 Apr 2013 16:55:58 +0100
Subject: [PATCH v10 0/12] Palmas updates
In-Reply-To: <20130405163056.GN17363@zurbaran>
References: <1363964122-19201-1-git-send-email-ian@slimlogic.co.uk>
 <20130405163056.GN17363@zurbaran>
Message-ID: <5162E88E.9010204@slimlogic.co.uk>

On 05/04/13 17:30, Samuel Ortiz wrote:
> Hi Ian,
>
> On Fri, Mar 22, 2013 at 02:55:10PM +0000, Ian Lartey wrote:
>> This patchset adds to the support for the Palmas series of PMIC chips.
>>
>> Some of the patches have previously been submitted individually.
>> The DT bindings doc has been added first due to comments that it was missing.
>>
>> Patches based on linux-next-20130319
> Are you expecting all those patches to go through the MFD tree ?
> Also, you stil have a few comments from Milo and Stephen to adress. Are you
> planning to send a v11 ?
>
>
Hi Samuel,

The device is an MFD so I suspect the best path is through MFD tree
although I notice you have applied the patch that was required by all
other patches so maybe this is not so much the case now!

Real life has got in the way of the next updated series of patches but
they will be issued just as soon as we can.

Thanks

Graeme



From will.deacon at arm.com  Mon Apr  8 11:57:49 2013
From: will.deacon at arm.com (Will Deacon)
Date: Mon, 8 Apr 2013 16:57:49 +0100
Subject: [PATCH] Report double word access atomicity on LPAE enabled
 targets through AUXV
In-Reply-To: <20130408142406.GL17995@n2100.arm.linux.org.uk>
References: <C3FF039D-7DE3-4A99-8317-789094095D8B@oracle.com>
 <20130408142406.GL17995@n2100.arm.linux.org.uk>
Message-ID: <20130408155749.GS17476@mudshark.cambridge.arm.com>

Hi Russell,

On Mon, Apr 08, 2013 at 03:24:06PM +0100, Russell King - ARM Linux wrote:
> I think we're heading towards running out of hwcap bits to represent all
> these different features.  Not there yet, but after this we only have 11
> spare bits.
> 
> Maybe we need to switch to a more x86-centric method where we report this
> stuff in /proc/cpuinfo, and userspace parses this information out.  If
> glibc already has code in there for x86, maybe we can reuse that?

Why can't we just pass multiple AT_HWCAP entries in the auxv? It would
require a small change to the ELF loader to allow an architecture to provide
more than just ELF_HWCAP, but it's fairly straightforward and easy to
propogate without breaking backwards compatibility.

> > +        if (((read_cpuid_ext(CPUID_EXT_MMFR3) >> 28) & 0xf) > 0)
> > 
> > +          elf_hwcap |= HWCAP_ATOMICD;
> 
> We use tabs for indentation, not two spaces.  Also, on the face of it
> ATOMICD isn't obvious what it means.  Maybe HWCAP_LDRDSTRD would be
> better - it's only one character longer and truely reflects what you're
> trying to report - the presence of these two instructions.

Actually, it's not just the presence of those instructions -- it's their
behaviour wrt atomicity. They are only guaranteed to be atomic if the CPU in
question supports LPAE. We could call it "lpae" but it might be set even
when the kernel is using the short-descriptor format.

Will


From arnd at arndb.de  Mon Apr  8 11:59:07 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 8 Apr 2013 17:59:07 +0200
Subject: [GIT PULL] Update for Renesas INTC External IRQ pin driver for
 v3.10
In-Reply-To: <201304081754.55689.arnd@arndb.de>
References: <1364540207-7699-1-git-send-email-horms+renesas@verge.net.au>
 <201304081754.55689.arnd@arndb.de>
Message-ID: <201304081759.07358.arnd@arndb.de>

On Monday 08 April 2013, Arnd Bergmann wrote:
> On Friday 29 March 2013, Simon Horman wrote:
> > Hi Arnd, Hi Olof,
> > 
> > The following changes since commit 3b8dfa7c2f8af7613dae28ac0f3419bf75ead5d0:
> > 
> >   irqchip: irqc: Add DT support (2013-03-18 21:26:07 +0900)
> > 
> > are available in the git repository at:
> > 
> >   git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-intc-external-irq2-for-v3.10
> > 
> 
> Pulled into next/drivers, thanks!
> 
> Sorry for the slight delay in processing this.
> 

Ah, I found now that we already had other branches based on this patch merged
into renesas/pinmux2 and renesas/soc2. Anyway, now we have it as a separate
branch tag.

	Arnd


From ludovic.desroches at atmel.com  Mon Apr  8 12:02:24 2013
From: ludovic.desroches at atmel.com (Ludovic Desroches)
Date: Mon, 8 Apr 2013 18:02:24 +0200
Subject: [PATCH] mmc: atmel-mci: pio hang on block errors
In-Reply-To: <1363771946-8931-1-git-send-email-ludovic.desroches@atmel.com>
References: <1363771946-8931-1-git-send-email-ludovic.desroches@atmel.com>
Message-ID: <20130408160224.GC6398@ludovic.desroches@atmel.com>

Hi Chris,

Could you take this fix? If there are no objections of course.

Regards

Ludovic

On Wed, Mar 20, 2013 at 10:32:26AM +0100, ludovic.desroches at atmel.com wrote:
> From: Terry Barnaby <terry at beam.ltd.uk>
> 
> The driver is doing, by default, multi-block reads. When a block error occurs
> card/block.c instigates a single block read: "mmcblk0: retrying using single
> block read".
> It leaves the sg chain intact and just changes the length attribute for the
> first sg entry and the overall sg_len parameter. When atmci_read_data_pio is
> called to read the single block of data it ignores the sg_len and expects to
> read more than 512 bytes as it sees there are multiple items in the sg list. No
> more data comes as the controller has only been commanded to get one block.
> 
> Signed-off-by: Terry Barnaby <terry at beam.ltd.uk>
> Acked-by: Ludovic Desroches <ludovic.desroches at atmel.com>
> Cc: stable <stable at vger.kernel.org> # 3.2+
> ---
>  drivers/mmc/host/atmel-mci.c | 14 ++++++++++----
>  1 file changed, 10 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/mmc/host/atmel-mci.c b/drivers/mmc/host/atmel-mci.c
> index 0932024..d98e68e 100644
> --- a/drivers/mmc/host/atmel-mci.c
> +++ b/drivers/mmc/host/atmel-mci.c
> @@ -163,6 +163,7 @@ struct atmel_mci {
>  	void __iomem		*regs;
>  
>  	struct scatterlist	*sg;
> +	unsigned int		sg_len;
>  	unsigned int		pio_offset;
>  
>  	struct atmel_mci_slot	*cur_slot;
> @@ -751,6 +752,7 @@ static u32 atmci_prepare_data(struct atmel_mci *host, struct mmc_data *data)
>  	data->error = -EINPROGRESS;
>  
>  	host->sg = data->sg;
> +	host->sg_len = data->sg_len;
>  	host->data = data;
>  	host->data_chan = NULL;
>  
> @@ -1573,7 +1575,8 @@ static void atmci_read_data_pio(struct atmel_mci *host)
>  			if (offset == sg->length) {
>  				flush_dcache_page(sg_page(sg));
>  				host->sg = sg = sg_next(sg);
> -				if (!sg)
> +				host->sg_len--;
> +				if (!sg || !host->sg_len)
>  					goto done;
>  
>  				offset = 0;
> @@ -1586,7 +1589,8 @@ static void atmci_read_data_pio(struct atmel_mci *host)
>  
>  			flush_dcache_page(sg_page(sg));
>  			host->sg = sg = sg_next(sg);
> -			if (!sg)
> +			host->sg_len--;
> +			if (!sg || !host->sg_len)
>  				goto done;
>  
>  			offset = 4 - remaining;
> @@ -1640,7 +1644,8 @@ static void atmci_write_data_pio(struct atmel_mci *host)
>  			nbytes += 4;
>  			if (offset == sg->length) {
>  				host->sg = sg = sg_next(sg);
> -				if (!sg)
> +				host->sg_len--;
> +				if (!sg || !host->sg_len)
>  					goto done;
>  
>  				offset = 0;
> @@ -1654,7 +1659,8 @@ static void atmci_write_data_pio(struct atmel_mci *host)
>  			nbytes += remaining;
>  
>  			host->sg = sg = sg_next(sg);
> -			if (!sg) {
> +			host->sg_len--;
> +			if (!sg || !host->sg_len) {
>  				atmci_writel(host, ATMCI_TDR, value);
>  				goto done;
>  			}
> -- 
> 1.7.11.3
> 


From p.zabel at pengutronix.de  Mon Apr  8 12:04:31 2013
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Mon,  8 Apr 2013 18:04:31 +0200
Subject: [PATCH 0/7] i.MX53 IPU + TVE patches
Message-ID: <1365437078-22579-1-git-send-email-p.zabel@pengutronix.de>

Hi,

the following patches allow to use the integrated Television Encoder
(TVEv2) on the i.MX53 SoC as VGA output encoder for the IPU. This is
useful for the Freescale i.MX53-QSB and TQ MBa53 boards, which have
VGA and DVI-I connectors, respectively.

regards
Philipp

---
 drivers/staging/imx-drm/Kconfig             |   7 +
 drivers/staging/imx-drm/Makefile            |   1 +
 drivers/staging/imx-drm/imx-drm-core.c      |  15 +-
 drivers/staging/imx-drm/imx-drm.h           |  14 +-
 drivers/staging/imx-drm/imx-tve.c           | 755 ++++++++++++++++++++++++++++
 drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h |   3 +
 drivers/staging/imx-drm/ipu-v3/ipu-dc.c     |  55 +-
 drivers/staging/imx-drm/ipu-v3/ipu-di.c     | 100 +++-
 drivers/staging/imx-drm/ipuv3-crtc.c        |  11 +-
 9 files changed, 932 insertions(+), 29 deletions(-)



From p.zabel at pengutronix.de  Mon Apr  8 12:04:37 2013
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Mon,  8 Apr 2013 18:04:37 +0200
Subject: [PATCH 6/7] staging: drm/imx: ipu-dc: force black output during
 blanking
In-Reply-To: <1365437078-22579-1-git-send-email-p.zabel@pengutronix.de>
References: <1365437078-22579-1-git-send-email-p.zabel@pengutronix.de>
Message-ID: <1365437078-22579-7-git-send-email-p.zabel@pengutronix.de>

Signed-off-by: Philipp Zabel <p.zabel at pengutronix.de>
---
 drivers/staging/imx-drm/ipu-v3/ipu-dc.c | 14 ++++++++------
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/imx-drm/ipu-v3/ipu-dc.c b/drivers/staging/imx-drm/ipu-v3/ipu-dc.c
index 355b8a2..1cb0631 100644
--- a/drivers/staging/imx-drm/ipu-v3/ipu-dc.c
+++ b/drivers/staging/imx-drm/ipu-v3/ipu-dc.c
@@ -179,19 +179,21 @@ int ipu_dc_init_sync(struct ipu_dc *dc, struct ipu_di *di, bool interlaced,
 		if (dc->di) {
 			dc_link_event(dc, DC_EVT_NL, 2, 3);
 			dc_link_event(dc, DC_EVT_EOL, 3, 2);
-			dc_link_event(dc, DC_EVT_NEW_DATA, 4, 1);
+			dc_link_event(dc, DC_EVT_NEW_DATA, 1, 1);
 			/* Init template microcode */
 			dc_write_tmpl(dc, 2, WROD(0), 0, map, SYNC_WAVE, 8, 5, 1);
-			dc_write_tmpl(dc, 3, WROD(0), 0, map, SYNC_WAVE, 4, 5, 1);
-			dc_write_tmpl(dc, 4, WROD(0), 0, map, SYNC_WAVE, 0, 5, 1);
+			dc_write_tmpl(dc, 3, WROD(0), 0, map, SYNC_WAVE, 4, 5, 0);
+			dc_write_tmpl(dc, 4, WRG, 0, map, NULL_WAVE, 0, 0, 1);
+			dc_write_tmpl(dc, 1, WROD(0), 0, map, SYNC_WAVE, 0, 5, 1);
 		} else {
 			dc_link_event(dc, DC_EVT_NL, 5, 3);
 			dc_link_event(dc, DC_EVT_EOL, 6, 2);
-			dc_link_event(dc, DC_EVT_NEW_DATA, 7, 1);
+			dc_link_event(dc, DC_EVT_NEW_DATA, 8, 1);
 			/* Init template microcode */
 			dc_write_tmpl(dc, 5, WROD(0), 0, map, SYNC_WAVE, 8, 5, 1);
-			dc_write_tmpl(dc, 6, WROD(0), 0, map, SYNC_WAVE, 4, 5, 1);
-			dc_write_tmpl(dc, 7, WROD(0), 0, map, SYNC_WAVE, 0, 5, 1);
+			dc_write_tmpl(dc, 6, WROD(0), 0, map, SYNC_WAVE, 4, 5, 0);
+			dc_write_tmpl(dc, 7, WRG, 0, map, NULL_WAVE, 0, 0, 1);
+			dc_write_tmpl(dc, 8, WROD(0), 0, map, SYNC_WAVE, 0, 5, 1);
 		}
 	}
 	dc_link_event(dc, DC_EVT_NF, 0, 0);
-- 
1.8.2.rc2



From p.zabel at pengutronix.de  Mon Apr  8 12:04:36 2013
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Mon,  8 Apr 2013 18:04:36 +0200
Subject: [PATCH 5/7] staging: drm/imx: ipu-dc: add WCLK/WRG opcodes
In-Reply-To: <1365437078-22579-1-git-send-email-p.zabel@pengutronix.de>
References: <1365437078-22579-1-git-send-email-p.zabel@pengutronix.de>
Message-ID: <1365437078-22579-6-git-send-email-p.zabel@pengutronix.de>

Add WRG and WCLK opcodes to the display controller microcode,
and allow multi instruction codes.

Signed-off-by: Philipp Zabel <p.zabel at pengutronix.de>
---
 drivers/staging/imx-drm/ipu-v3/ipu-dc.c | 39 ++++++++++++++++++++-------------
 1 file changed, 24 insertions(+), 15 deletions(-)

diff --git a/drivers/staging/imx-drm/ipu-v3/ipu-dc.c b/drivers/staging/imx-drm/ipu-v3/ipu-dc.c
index fad5057..355b8a2 100644
--- a/drivers/staging/imx-drm/ipu-v3/ipu-dc.c
+++ b/drivers/staging/imx-drm/ipu-v3/ipu-dc.c
@@ -61,8 +61,10 @@
 
 #define WROD(lf)		(0x18 | ((lf) << 1))
 #define WRG			0x01
+#define WCLK			0xc9
 
 #define SYNC_WAVE 0
+#define NULL_WAVE (-1)
 
 #define DC_GEN_SYNC_1_6_SYNC	(2 << 1)
 #define DC_GEN_SYNC_PRIORITY_1	(1 << 7)
@@ -119,16 +121,23 @@ static void dc_link_event(struct ipu_dc *dc, int event, int addr, int priority)
 }
 
 static void dc_write_tmpl(struct ipu_dc *dc, int word, u32 opcode, u32 operand,
-		int map, int wave, int glue, int sync)
+		int map, int wave, int glue, int sync, int stop)
 {
 	struct ipu_dc_priv *priv = dc->priv;
-	u32 reg;
-	int stop = 1;
-
-	reg = sync | glue << 4 | ++wave << 11 | ++map << 15 | ((operand << 20) & 0xfff00000);
-	writel(reg, priv->dc_tmpl_reg + word * 8);
-	reg = operand >> 12 | opcode << 4 | stop << 9;
-	writel(reg, priv->dc_tmpl_reg + word * 8 + 4);
+	u32 reg1, reg2;
+
+	if (opcode == WCLK) {
+		reg1 = (operand << 20) & 0xfff00000;
+		reg2 = operand >> 12 | opcode << 1 | stop << 9;
+	} else if (opcode == WRG) {
+		reg1 = sync | glue << 4 | ++wave << 11 | ((operand << 15) & 0xffff8000);
+		reg2 = operand >> 17 | opcode << 7 | stop << 9;
+	} else {
+		reg1 = sync | glue << 4 | ++wave << 11 | ++map << 15 | ((operand << 20) & 0xfff00000);
+		reg2 = operand >> 12 | opcode << 4 | stop << 9;
+	}
+	writel(reg1, priv->dc_tmpl_reg + word * 8);
+	writel(reg2, priv->dc_tmpl_reg + word * 8 + 4);
 }
 
 static int ipu_pixfmt_to_map(u32 fmt)
@@ -165,24 +174,24 @@ int ipu_dc_init_sync(struct ipu_dc *dc, struct ipu_di *di, bool interlaced,
 		dc_link_event(dc, DC_EVT_NEW_DATA, 0, 1);
 
 		/* Init template microcode */
-		dc_write_tmpl(dc, 0, WROD(0), 0, map, SYNC_WAVE, 0, 8);
+		dc_write_tmpl(dc, 0, WROD(0), 0, map, SYNC_WAVE, 0, 8, 1);
 	} else {
 		if (dc->di) {
 			dc_link_event(dc, DC_EVT_NL, 2, 3);
 			dc_link_event(dc, DC_EVT_EOL, 3, 2);
 			dc_link_event(dc, DC_EVT_NEW_DATA, 4, 1);
 			/* Init template microcode */
-			dc_write_tmpl(dc, 2, WROD(0), 0, map, SYNC_WAVE, 8, 5);
-			dc_write_tmpl(dc, 3, WROD(0), 0, map, SYNC_WAVE, 4, 5);
-			dc_write_tmpl(dc, 4, WROD(0), 0, map, SYNC_WAVE, 0, 5);
+			dc_write_tmpl(dc, 2, WROD(0), 0, map, SYNC_WAVE, 8, 5, 1);
+			dc_write_tmpl(dc, 3, WROD(0), 0, map, SYNC_WAVE, 4, 5, 1);
+			dc_write_tmpl(dc, 4, WROD(0), 0, map, SYNC_WAVE, 0, 5, 1);
 		} else {
 			dc_link_event(dc, DC_EVT_NL, 5, 3);
 			dc_link_event(dc, DC_EVT_EOL, 6, 2);
 			dc_link_event(dc, DC_EVT_NEW_DATA, 7, 1);
 			/* Init template microcode */
-			dc_write_tmpl(dc, 5, WROD(0), 0, map, SYNC_WAVE, 8, 5);
-			dc_write_tmpl(dc, 6, WROD(0), 0, map, SYNC_WAVE, 4, 5);
-			dc_write_tmpl(dc, 7, WROD(0), 0, map, SYNC_WAVE, 0, 5);
+			dc_write_tmpl(dc, 5, WROD(0), 0, map, SYNC_WAVE, 8, 5, 1);
+			dc_write_tmpl(dc, 6, WROD(0), 0, map, SYNC_WAVE, 4, 5, 1);
+			dc_write_tmpl(dc, 7, WROD(0), 0, map, SYNC_WAVE, 0, 5, 1);
 		}
 	}
 	dc_link_event(dc, DC_EVT_NF, 0, 0);
-- 
1.8.2.rc2



From p.zabel at pengutronix.de  Mon Apr  8 12:04:35 2013
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Mon,  8 Apr 2013 18:04:35 +0200
Subject: [PATCH 4/7] staging: drm/imx: Add support for VGA via TVE on i.MX53
In-Reply-To: <1365437078-22579-1-git-send-email-p.zabel@pengutronix.de>
References: <1365437078-22579-1-git-send-email-p.zabel@pengutronix.de>
Message-ID: <1365437078-22579-5-git-send-email-p.zabel@pengutronix.de>

This adds display interface timings for the Television Encoder
connected to IPU DI1 on i.MX53 and adds some configuration
glue code to select which IPU signal generators / pins are to
be used for HSYNC/VSYNC signals.

The default configuration is pin2/pin3 for hsync/vsync. The
VGA connector on i.MX53-QSB uses pin7/pin8, and the analog
part of the DVI-I connector on MBa53 connects to pin4/pin6.

Signed-off-by: Philipp Zabel <p.zabel at pengutronix.de>
---
 drivers/staging/imx-drm/imx-drm-core.c      | 15 ++++-
 drivers/staging/imx-drm/imx-drm.h           |  4 +-
 drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h |  3 +
 drivers/staging/imx-drm/ipu-v3/ipu-di.c     | 93 ++++++++++++++++++++++++++---
 drivers/staging/imx-drm/ipuv3-crtc.c        |  9 ++-
 5 files changed, 112 insertions(+), 12 deletions(-)

diff --git a/drivers/staging/imx-drm/imx-drm-core.c b/drivers/staging/imx-drm/imx-drm-core.c
index cec19f1..6455305 100644
--- a/drivers/staging/imx-drm/imx-drm-core.c
+++ b/drivers/staging/imx-drm/imx-drm-core.c
@@ -112,8 +112,8 @@ static struct imx_drm_crtc *imx_drm_crtc_by_num(struct imx_drm_device *imxdrm,
 	return NULL;
 }
 
-int imx_drm_crtc_panel_format(struct drm_crtc *crtc, u32 encoder_type,
-		u32 interface_pix_fmt)
+int imx_drm_crtc_panel_format_pins(struct drm_crtc *crtc, u32 encoder_type,
+		u32 interface_pix_fmt, int hsync_pin, int vsync_pin)
 {
 	struct imx_drm_device *imxdrm = crtc->dev->dev_private;
 	struct imx_drm_crtc *imx_crtc;
@@ -134,9 +134,18 @@ found:
 	helper = &imx_crtc->imx_drm_helper_funcs;
 	if (helper->set_interface_pix_fmt)
 		return helper->set_interface_pix_fmt(crtc,
-				encoder_type, interface_pix_fmt);
+				encoder_type, interface_pix_fmt,
+				hsync_pin, vsync_pin);
 	return 0;
 }
+EXPORT_SYMBOL_GPL(imx_drm_crtc_panel_format_pins);
+
+int imx_drm_crtc_panel_format(struct drm_crtc *crtc, u32 encoder_type,
+		u32 interface_pix_fmt)
+{
+	return imx_drm_crtc_panel_format_pins(crtc, encoder_type,
+					      interface_pix_fmt, 0, 0);
+}
 EXPORT_SYMBOL_GPL(imx_drm_crtc_panel_format);
 
 int imx_drm_crtc_vblank_get(struct imx_drm_crtc *imx_drm_crtc)
diff --git a/drivers/staging/imx-drm/imx-drm.h b/drivers/staging/imx-drm/imx-drm.h
index a24508f..f2aac91 100644
--- a/drivers/staging/imx-drm/imx-drm.h
+++ b/drivers/staging/imx-drm/imx-drm.h
@@ -18,7 +18,7 @@ struct imx_drm_crtc_helper_funcs {
 	int (*enable_vblank)(struct drm_crtc *crtc);
 	void (*disable_vblank)(struct drm_crtc *crtc);
 	int (*set_interface_pix_fmt)(struct drm_crtc *crtc, u32 encoder_type,
-			u32 pix_fmt);
+			u32 pix_fmt, int hsync_pin, int vsync_pin);
 	const struct drm_crtc_helper_funcs *crtc_helper_funcs;
 	const struct drm_crtc_funcs *crtc_funcs;
 };
@@ -54,6 +54,8 @@ struct drm_gem_cma_object *imx_drm_fb_get_obj(struct drm_framebuffer *fb);
 
 struct drm_device *imx_drm_device_get(void);
 void imx_drm_device_put(void);
+int imx_drm_crtc_panel_format_pins(struct drm_crtc *crtc, u32 encoder_type,
+		u32 interface_pix_fmt, int hsync_pin, int vsync_pin);
 int imx_drm_crtc_panel_format(struct drm_crtc *crtc, u32 encoder_type,
 		u32 interface_pix_fmt);
 void imx_drm_fb_helper_set(struct drm_fbdev_cma *fbdev_helper);
diff --git a/drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h b/drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h
index 66572d5..74c022e 100644
--- a/drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h
+++ b/drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h
@@ -54,6 +54,9 @@ struct ipu_di_signal_cfg {
 #define IPU_DI_CLKMODE_SYNC	(1 << 0)
 #define IPU_DI_CLKMODE_EXT	(1 << 1)
 	unsigned long clkflags;
+
+	u8 hsync_pin;
+	u8 vsync_pin;
 };
 
 enum ipu_color_space {
diff --git a/drivers/staging/imx-drm/ipu-v3/ipu-di.c b/drivers/staging/imx-drm/ipu-v3/ipu-di.c
index 26534b7..19d777e 100644
--- a/drivers/staging/imx-drm/ipu-v3/ipu-di.c
+++ b/drivers/staging/imx-drm/ipu-v3/ipu-di.c
@@ -440,7 +440,7 @@ static void ipu_di_sync_config_noninterlaced(struct ipu_di *di,
 			.repeat_count = sig->height,
 			.cnt_clr_src = DI_SYNC_VSYNC,
 		} , {
-			/* 5: DE, referenced by DC */
+			/* 5: Pixel Active, referenced by DC */
 			.run_src = DI_SYNC_CLK,
 			.offset_count = sig->h_sync_width + sig->h_start_width,
 			.offset_src = DI_SYNC_CLK,
@@ -454,13 +454,78 @@ static void ipu_di_sync_config_noninterlaced(struct ipu_di *di,
 			/* unused */
 		} , {
 			/* unused */
+		},
+	};
+	/* can't use #7 and #8 for line active and pixel active counters */
+	struct di_sync_config cfg_vga[] = {
+		{
+			/* 1: INT_HSYNC */
+			.run_count = h_total - 1,
+			.run_src = DI_SYNC_CLK,
+		} , {
+			/* 2: VSYNC */
+			.run_count = v_total - 1,
+			.run_src = DI_SYNC_INT_HSYNC,
+		} , {
+			/* 3: Line Active */
+			.run_src = DI_SYNC_INT_HSYNC,
+			.offset_count = sig->v_sync_width + sig->v_start_width,
+			.offset_src = DI_SYNC_INT_HSYNC,
+			.repeat_count = sig->height,
+			.cnt_clr_src = 3 /* VSYNC */,
+		} , {
+			/* PIN4: HSYNC for VGA via TVEv2 on TQ MBa53 */
+			.run_count = h_total - 1,
+			.run_src = DI_SYNC_CLK,
+			.offset_count = div * sig->v_to_h_sync + 18, /* magic value from Freescale TVE driver */
+			.offset_src = DI_SYNC_CLK,
+			.cnt_polarity_gen_en = 1,
+			.cnt_polarity_trigger_src = DI_SYNC_CLK,
+			.cnt_down = sig->h_sync_width * 2,
+		} , {
+			/* 5: Pixel Active signal to DC */
+			.run_src = DI_SYNC_CLK,
+			.offset_count = sig->h_sync_width + sig->h_start_width,
+			.offset_src = DI_SYNC_CLK,
+			.repeat_count = sig->width,
+			.cnt_clr_src = 4, /* Line Active */
+		} , {
+			/* PIN6: VSYNC for VGA via TVEv2 on TQ MBa53 */
+			.run_count = v_total - 1,
+			.run_src = DI_SYNC_INT_HSYNC,
+			.offset_count = 1, /* magic value from Freescale TVE driver */
+			.offset_src = DI_SYNC_INT_HSYNC,
+			.cnt_polarity_gen_en = 1,
+			.cnt_polarity_trigger_src = DI_SYNC_INT_HSYNC,
+			.cnt_down = sig->v_sync_width * 2,
+		} , {
+			/* PIN4: HSYNC for VGA via TVEv2 on i.MX53-QSB */
+			.run_count = h_total - 1,
+			.run_src = DI_SYNC_CLK,
+			.offset_count = div * sig->v_to_h_sync + 18, /* magic value from Freescale TVE driver */
+			.offset_src = DI_SYNC_CLK,
+			.cnt_polarity_gen_en = 1,
+			.cnt_polarity_trigger_src = DI_SYNC_CLK,
+			.cnt_down = sig->h_sync_width * 2,
+		} , {
+			/* PIN6: VSYNC for VGA via TVEv2 on i.MX53-QSB */
+			.run_count = v_total - 1,
+			.run_src = DI_SYNC_INT_HSYNC,
+			.offset_count = 1, /* magic value from Freescale TVE driver */
+			.offset_src = DI_SYNC_INT_HSYNC,
+			.cnt_polarity_gen_en = 1,
+			.cnt_polarity_trigger_src = DI_SYNC_INT_HSYNC,
+			.cnt_down = sig->v_sync_width * 2,
 		} , {
 			/* unused */
 		},
 	};
 
 	ipu_di_write(di, v_total - 1, DI_SCR_CONF);
-	ipu_di_sync_config(di, cfg, 0, ARRAY_SIZE(cfg));
+	if (sig->hsync_pin == 2 && sig->vsync_pin == 3)
+		ipu_di_sync_config(di, cfg, 0, ARRAY_SIZE(cfg));
+	else
+		ipu_di_sync_config(di, cfg_vga, 0, ARRAY_SIZE(cfg_vga));
 }
 
 int ipu_di_init_sync_panel(struct ipu_di *di, struct ipu_di_signal_cfg *sig)
@@ -537,11 +602,25 @@ int ipu_di_init_sync_panel(struct ipu_di *di, struct ipu_di_signal_cfg *sig)
 		ipu_di_sync_config_noninterlaced(di, sig, div);
 
 		vsync_cnt = 3;
-
-		if (sig->Hsync_pol)
-			di_gen |= DI_GEN_POLARITY_2;
-		if (sig->Vsync_pol)
-			di_gen |= DI_GEN_POLARITY_3;
+		if (di->id == 1)
+			vsync_cnt = 6;
+
+		if (sig->Hsync_pol) {
+			if (sig->hsync_pin == 2)
+				di_gen |= DI_GEN_POLARITY_2;
+			else if (sig->hsync_pin == 4)
+				di_gen |= DI_GEN_POLARITY_4;
+			else if (sig->hsync_pin == 7)
+				di_gen |= DI_GEN_POLARITY_7;
+		}
+		if (sig->Vsync_pol) {
+			if (sig->hsync_pin == 3)
+				di_gen |= DI_GEN_POLARITY_3;
+			else if (sig->hsync_pin == 6)
+				di_gen |= DI_GEN_POLARITY_6;
+			else if (sig->hsync_pin == 8)
+				di_gen |= DI_GEN_POLARITY_8;
+		}
 	}
 
 	if (!sig->clk_pol)
diff --git a/drivers/staging/imx-drm/ipuv3-crtc.c b/drivers/staging/imx-drm/ipuv3-crtc.c
index 620e571..ea61c86 100644
--- a/drivers/staging/imx-drm/ipuv3-crtc.c
+++ b/drivers/staging/imx-drm/ipuv3-crtc.c
@@ -60,6 +60,8 @@ struct ipu_crtc {
 	int			irq;
 	u32			interface_pix_fmt;
 	unsigned long		di_clkflags;
+	int			di_hsync_pin;
+	int			di_vsync_pin;
 };
 
 #define to_ipu_crtc(x) container_of(x, struct ipu_crtc, base)
@@ -255,6 +257,9 @@ static int ipu_crtc_mode_set(struct drm_crtc *crtc,
 
 	sig_cfg.v_to_h_sync = 0;
 
+	sig_cfg.hsync_pin = ipu_crtc->di_hsync_pin;
+	sig_cfg.vsync_pin = ipu_crtc->di_vsync_pin;
+
 	if (ipu_crtc->dp) {
 		ret = ipu_dp_setup_channel(ipu_crtc->dp, IPUV3_COLORSPACE_RGB,
 				IPUV3_COLORSPACE_RGB);
@@ -406,11 +411,13 @@ static void ipu_disable_vblank(struct drm_crtc *crtc)
 }
 
 static int ipu_set_interface_pix_fmt(struct drm_crtc *crtc, u32 encoder_type,
-		u32 pixfmt)
+		u32 pixfmt, int hsync_pin, int vsync_pin)
 {
 	struct ipu_crtc *ipu_crtc = to_ipu_crtc(crtc);
 
 	ipu_crtc->interface_pix_fmt = pixfmt;
+	ipu_crtc->di_hsync_pin = hsync_pin;
+	ipu_crtc->di_vsync_pin = vsync_pin;
 
 	switch (encoder_type) {
 	case DRM_MODE_ENCODER_DAC:
-- 
1.8.2.rc2



From p.zabel at pengutronix.de  Mon Apr  8 12:04:38 2013
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Mon,  8 Apr 2013 18:04:38 +0200
Subject: [PATCH 7/7] staging: drm/imx: Add support for Television Encoder
 (TVEv2)
In-Reply-To: <1365437078-22579-1-git-send-email-p.zabel@pengutronix.de>
References: <1365437078-22579-1-git-send-email-p.zabel@pengutronix.de>
Message-ID: <1365437078-22579-8-git-send-email-p.zabel@pengutronix.de>

This driver adds support for the Television Encoder integrated
on i.MX53 SoCs (TVEv2).

Currently only the VGA output mode is supported, which only uses
the TVDAC to generate RGB levels. HSYNC and VSYNC signals are
routed directly from the IPU signal generator pins through IOMUXC.

Signed-off-by: Philipp Zabel <p.zabel at pengutronix.de>
---
 drivers/staging/imx-drm/Kconfig   |   7 +
 drivers/staging/imx-drm/Makefile  |   1 +
 drivers/staging/imx-drm/imx-tve.c | 755 ++++++++++++++++++++++++++++++++++++++
 3 files changed, 763 insertions(+)
 create mode 100644 drivers/staging/imx-drm/imx-tve.c

diff --git a/drivers/staging/imx-drm/Kconfig b/drivers/staging/imx-drm/Kconfig
index be7e2e3..8c9e403 100644
--- a/drivers/staging/imx-drm/Kconfig
+++ b/drivers/staging/imx-drm/Kconfig
@@ -20,6 +20,13 @@ config DRM_IMX_PARALLEL_DISPLAY
 	tristate "Support for parallel displays"
 	depends on DRM_IMX
 
+config DRM_IMX_TVE
+	tristate "Support for TV and VGA displays"
+	depends on DRM_IMX
+	help
+	  Choose this to enable the internal Television Encoder (TVe)
+	  found on i.MX53 processors.
+
 config DRM_IMX_IPUV3_CORE
 	tristate "IPUv3 core support"
 	depends on DRM_IMX
diff --git a/drivers/staging/imx-drm/Makefile b/drivers/staging/imx-drm/Makefile
index 83a9056..7e50184 100644
--- a/drivers/staging/imx-drm/Makefile
+++ b/drivers/staging/imx-drm/Makefile
@@ -4,6 +4,7 @@ imxdrm-objs := imx-drm-core.o imx-fb.o
 obj-$(CONFIG_DRM_IMX) += imxdrm.o
 
 obj-$(CONFIG_DRM_IMX_PARALLEL_DISPLAY) += parallel-display.o
+obj-$(CONFIG_DRM_IMX_TVE) += imx-tve.o
 obj-$(CONFIG_DRM_IMX_FB_HELPER) += imx-fbdev.o
 obj-$(CONFIG_DRM_IMX_IPUV3_CORE) += ipu-v3/
 obj-$(CONFIG_DRM_IMX_IPUV3)	+= ipuv3-crtc.o
diff --git a/drivers/staging/imx-drm/imx-tve.c b/drivers/staging/imx-drm/imx-tve.c
new file mode 100644
index 0000000..a14ed0e
--- /dev/null
+++ b/drivers/staging/imx-drm/imx-tve.c
@@ -0,0 +1,755 @@
+/*
+ * i.MX drm driver - Television Encoder (TVEv2)
+ *
+ * Copyright (C) 2013 Philipp Zabel, Pengutronix
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
+ * MA 02110-1301, USA.
+ */
+
+#include <linux/clk.h>
+#include <linux/clk-provider.h>
+#include <linux/module.h>
+#include <linux/of_i2c.h>
+#include <linux/pinctrl/consumer.h>
+#include <linux/regmap.h>
+#include <linux/regulator/consumer.h>
+#include <linux/spinlock.h>
+#include <linux/videodev2.h>
+#include <drm/drmP.h>
+#include <drm/drm_fb_helper.h>
+#include <drm/drm_crtc_helper.h>
+
+#include "imx-drm.h"
+
+#define TVE_COM_CONF_REG	0x00
+#define TVE_TVDAC0_CONT_REG	0x28
+#define TVE_TVDAC1_CONT_REG	0x2c
+#define TVE_TVDAC2_CONT_REG	0x30
+#define TVE_CD_CONT_REG		0x34
+#define TVE_INT_CONT_REG	0x64
+#define TVE_STAT_REG		0x68
+#define TVE_TST_MODE_REG	0x6c
+#define TVE_MV_CONT_REG		0xdc
+
+/* TVE_COM_CONF_REG */
+#define TVE_SYNC_CH_2_EN	BIT(22)
+#define TVE_SYNC_CH_1_EN	BIT(21)
+#define TVE_SYNC_CH_0_EN	BIT(20)
+#define TVE_TV_OUT_MODE_MASK	(0x7 << 12)
+#define TVE_TV_OUT_DISABLE	(0x0 << 12)
+#define TVE_TV_OUT_CVBS_0	(0x1 << 12)
+#define TVE_TV_OUT_CVBS_2	(0x2 << 12)
+#define TVE_TV_OUT_CVBS_0_2	(0x3 << 12)
+#define TVE_TV_OUT_SVIDEO_0_1	(0x4 << 12)
+#define TVE_TV_OUT_SVIDEO_0_1_CVBS2_2	(0x5 << 12)
+#define TVE_TV_OUT_YPBPR	(0x6 << 12)
+#define TVE_TV_OUT_RGB		(0x7 << 12)
+#define TVE_TV_STAND_MASK	(0xf << 8)
+#define TVE_TV_STAND_HD_1080P30	(0xc << 8)
+#define TVE_P2I_CONV_EN		BIT(7)
+#define TVE_INP_VIDEO_FORM	BIT(6)
+#define TVE_INP_YCBCR_422	(0x0 << 6)
+#define TVE_INP_YCBCR_444	(0x1 << 6)
+#define TVE_DATA_SOURCE_MASK	(0x3 << 4)
+#define TVE_DATA_SOURCE_BUS1	(0x0 << 4)
+#define TVE_DATA_SOURCE_BUS2	(0x1 << 4)
+#define TVE_DATA_SOURCE_EXT	(0x2 << 4)
+#define TVE_DATA_SOURCE_TESTGEN	(0x3 << 4)
+#define TVE_IPU_CLK_EN_OFS	3
+#define TVE_IPU_CLK_EN		BIT(3)
+#define TVE_DAC_SAMP_RATE_OFS	1
+#define TVE_DAC_SAMP_RATE_WIDTH	2
+#define TVE_DAC_SAMP_RATE_MASK	(0x3 << 1)
+#define TVE_DAC_FULL_RATE	(0x0 << 1)
+#define TVE_DAC_DIV2_RATE	(0x1 << 1)
+#define TVE_DAC_DIV4_RATE	(0x2 << 1)
+#define TVE_EN			BIT(0)
+
+/* TVE_TVDACx_CONT_REG */
+#define TVE_TVDAC_GAIN_MASK	(0x3f << 0)
+
+/* TVE_CD_CONT_REG */
+#define TVE_CD_CH_2_SM_EN	BIT(22)
+#define TVE_CD_CH_1_SM_EN	BIT(21)
+#define TVE_CD_CH_0_SM_EN	BIT(20)
+#define TVE_CD_CH_2_LM_EN	BIT(18)
+#define TVE_CD_CH_1_LM_EN	BIT(17)
+#define TVE_CD_CH_0_LM_EN	BIT(16)
+#define TVE_CD_CH_2_REF_LVL	BIT(10)
+#define TVE_CD_CH_1_REF_LVL	BIT(9)
+#define TVE_CD_CH_0_REF_LVL	BIT(8)
+#define TVE_CD_EN		BIT(0)
+
+/* TVE_INT_CONT_REG */
+#define TVE_FRAME_END_IEN	BIT(13)
+#define TVE_CD_MON_END_IEN	BIT(2)
+#define TVE_CD_SM_IEN		BIT(1)
+#define TVE_CD_LM_IEN		BIT(0)
+
+/* TVE_TST_MODE_REG */
+#define TVE_TVDAC_TEST_MODE_MASK	(0x7 << 0)
+
+#define con_to_tve(x) container_of(x, struct imx_tve, connector)
+#define enc_to_tve(x) container_of(x, struct imx_tve, encoder)
+
+enum {
+	TVE_MODE_TVOUT,
+	TVE_MODE_VGA,
+};
+
+struct imx_tve {
+	struct drm_connector connector;
+	struct imx_drm_connector *imx_drm_connector;
+	struct drm_encoder encoder;
+	struct imx_drm_encoder *imx_drm_encoder;
+	struct device *dev;
+	spinlock_t enable_lock;	/* serializes tve_enable/disable */
+	spinlock_t lock;	/* register lock */
+	bool enabled;
+	int mode;
+
+	struct regmap *regmap;
+	struct regulator *dac_reg;
+	struct i2c_adapter *ddc;
+	struct clk *clk;
+	struct clk *di_sel_clk;
+	struct clk_hw clk_hw_di;
+	struct clk *di_clk;
+	int vsync_pin;
+	int hsync_pin;
+};
+
+static void tve_lock(void *__tve)
+{
+	struct imx_tve *tve = __tve;
+	spin_lock(&tve->lock);
+}
+
+static void tve_unlock(void *__tve)
+{
+	struct imx_tve *tve = __tve;
+	spin_unlock(&tve->lock);
+}
+
+static void tve_enable(struct imx_tve *tve)
+{
+	unsigned long flags;
+	int ret;
+
+	spin_lock_irqsave(&tve->enable_lock, flags);
+	if (!tve->enabled) {
+		tve->enabled = 1;
+		clk_prepare_enable(tve->clk);
+		ret = regmap_update_bits(tve->regmap, TVE_COM_CONF_REG,
+					 TVE_IPU_CLK_EN | TVE_EN,
+					 TVE_IPU_CLK_EN | TVE_EN);
+	}
+
+	/* clear interrupt status register */
+	regmap_write(tve->regmap, TVE_STAT_REG, 0xffffffff);
+
+	/* cable detection irq disabled in VGA mode, enabled in TVOUT mode */
+	if (tve->mode == TVE_MODE_VGA)
+		regmap_write(tve->regmap, TVE_INT_CONT_REG, 0);
+	else
+		regmap_write(tve->regmap, TVE_INT_CONT_REG,
+			     TVE_CD_SM_IEN | TVE_CD_LM_IEN | TVE_CD_MON_END_IEN);
+	spin_unlock_irqrestore(&tve->enable_lock, flags);
+}
+
+static void tve_disable(struct imx_tve *tve)
+{
+	unsigned long flags;
+	int ret;
+
+	spin_lock_irqsave(&tve->enable_lock, flags);
+	if (tve->enabled) {
+		tve->enabled = 0;
+		ret = regmap_update_bits(tve->regmap, TVE_COM_CONF_REG,
+					 TVE_IPU_CLK_EN | TVE_EN, 0);
+		clk_disable_unprepare(tve->clk);
+	}
+	spin_unlock_irqrestore(&tve->enable_lock, flags);
+}
+
+static int tve_setup_tvout(struct imx_tve *tve)
+{
+	return -ENOTSUPP;
+}
+
+static int tve_setup_vga(struct imx_tve *tve)
+{
+	unsigned int mask;
+	unsigned int val;
+	int ret;
+
+	/* set gain to (1 + 10/128) to provide 0.7V peak-to-peak amplitude */
+	ret = regmap_update_bits(tve->regmap, TVE_TVDAC0_CONT_REG,
+				 TVE_TVDAC_GAIN_MASK, 0x0a);
+	ret = regmap_update_bits(tve->regmap, TVE_TVDAC1_CONT_REG,
+				 TVE_TVDAC_GAIN_MASK, 0x0a);
+	ret = regmap_update_bits(tve->regmap, TVE_TVDAC2_CONT_REG,
+				 TVE_TVDAC_GAIN_MASK, 0x0a);
+
+	/* set configuration register */
+	mask = TVE_DATA_SOURCE_MASK | TVE_INP_VIDEO_FORM;
+	val  = TVE_DATA_SOURCE_BUS2 | TVE_INP_YCBCR_444;
+	mask |= TVE_TV_STAND_MASK       | TVE_P2I_CONV_EN;
+	val  |= TVE_TV_STAND_HD_1080P30 | 0;
+	mask |= TVE_TV_OUT_MODE_MASK | TVE_SYNC_CH_0_EN;
+	val  |= TVE_TV_OUT_RGB       | TVE_SYNC_CH_0_EN;
+	ret = regmap_update_bits(tve->regmap, TVE_COM_CONF_REG, mask, val);
+	if (ret < 0) {
+		dev_err(tve->dev, "failed to set configuration: %d\n", ret);
+		return ret;
+	}
+
+	/* set test mode (as documented) */
+	ret = regmap_update_bits(tve->regmap, TVE_TST_MODE_REG,
+				 TVE_TVDAC_TEST_MODE_MASK, 1);
+
+	return 0;
+}
+
+static enum drm_connector_status imx_tve_connector_detect(
+				struct drm_connector *connector, bool force)
+{
+	return connector_status_connected;
+}
+
+static void imx_tve_connector_destroy(struct drm_connector *connector)
+{
+	/* do not free here */
+}
+
+static int imx_tve_connector_get_modes(struct drm_connector *connector)
+{
+	struct imx_tve *tve = con_to_tve(connector);
+	struct edid *edid;
+	int ret = 0;
+
+	if (!tve->ddc)
+		return 0;
+
+	edid = drm_get_edid(connector, tve->ddc);
+	if (edid) {
+		drm_mode_connector_update_edid_property(connector, edid);
+		ret = drm_add_edid_modes(connector, edid);
+		kfree(edid);
+	}
+
+	return ret;
+}
+
+static int imx_tve_connector_mode_valid(struct drm_connector *connector,
+					struct drm_display_mode *mode)
+{
+	struct imx_tve *tve = con_to_tve(connector);
+	unsigned long rate;
+
+	/* pixel clock with 2x oversampling */
+	rate = clk_round_rate(tve->clk, 2000UL * mode->clock) / 2000;
+	if (rate == mode->clock)
+		return MODE_OK;
+
+	/* pixel clock without oversampling */
+	rate = clk_round_rate(tve->clk, 1000UL * mode->clock) / 1000;
+	if (rate == mode->clock)
+		return MODE_OK;
+
+	dev_warn(tve->dev, "ignoring mode %dx%d\n",
+		 mode->hdisplay, mode->vdisplay);
+
+	return MODE_BAD;
+}
+
+static struct drm_encoder *imx_tve_connector_best_encoder(
+		struct drm_connector *connector)
+{
+	struct imx_tve *tve = con_to_tve(connector);
+
+	return &tve->encoder;
+}
+
+static void imx_tve_encoder_dpms(struct drm_encoder *encoder, int mode)
+{
+	struct imx_tve *tve = enc_to_tve(encoder);
+	int ret;
+
+	ret = regmap_update_bits(tve->regmap, TVE_COM_CONF_REG,
+				 TVE_TV_OUT_MODE_MASK, TVE_TV_OUT_DISABLE);
+	if (ret < 0)
+		dev_err(tve->dev, "failed to disable TVOUT: %d\n", ret);
+}
+
+static bool imx_tve_encoder_mode_fixup(struct drm_encoder *encoder,
+				       const struct drm_display_mode *mode,
+				       struct drm_display_mode *adjusted_mode)
+{
+	return true;
+}
+
+static void imx_tve_encoder_prepare(struct drm_encoder *encoder)
+{
+	struct imx_tve *tve = enc_to_tve(encoder);
+
+	tve_disable(tve);
+
+	switch (tve->mode) {
+	case TVE_MODE_VGA:
+		imx_drm_crtc_panel_format_pins(encoder->crtc,
+				DRM_MODE_ENCODER_DAC, IPU_PIX_FMT_GBR24,
+				tve->hsync_pin, tve->vsync_pin);
+		break;
+	case TVE_MODE_TVOUT:
+		imx_drm_crtc_panel_format(encoder->crtc, DRM_MODE_ENCODER_TVDAC,
+					  V4L2_PIX_FMT_YUV444);
+		break;
+	}
+}
+
+static void imx_tve_encoder_mode_set(struct drm_encoder *encoder,
+				     struct drm_display_mode *mode,
+				     struct drm_display_mode *adjusted_mode)
+{
+	struct imx_tve *tve = enc_to_tve(encoder);
+	unsigned long rounded_rate;
+	unsigned long rate;
+	int div = 1;
+	int ret;
+
+	/*
+	 * FIXME
+	 * we should try 4k * mode->clock first,
+	 * and enable 4x oversampling for lower resolutions
+	 */
+	rate = 2000UL * mode->clock;
+	clk_set_rate(tve->clk, rate);
+	rounded_rate = clk_get_rate(tve->clk);
+	if (rounded_rate >= rate)
+		div = 2;
+	clk_set_rate(tve->di_clk, rounded_rate / div);
+
+	ret = clk_set_parent(tve->di_sel_clk, tve->di_clk);
+	if (ret < 0) {
+		dev_err(tve->dev, "failed to set di_sel parent to tve_di: %d\n",
+			ret);
+	}
+
+	if (tve->mode == TVE_MODE_VGA)
+		tve_setup_vga(tve);
+	else
+		tve_setup_tvout(tve);
+}
+
+static void imx_tve_encoder_commit(struct drm_encoder *encoder)
+{
+	struct imx_tve *tve = enc_to_tve(encoder);
+
+	tve_enable(tve);
+}
+
+static void imx_tve_encoder_disable(struct drm_encoder *encoder)
+{
+	struct imx_tve *tve = enc_to_tve(encoder);
+
+	tve_disable(tve);
+}
+
+static void imx_tve_encoder_destroy(struct drm_encoder *encoder)
+{
+	/* do not free here */
+}
+
+static struct drm_connector_funcs imx_tve_connector_funcs = {
+	.dpms = drm_helper_connector_dpms,
+	.fill_modes = drm_helper_probe_single_connector_modes,
+	.detect = imx_tve_connector_detect,
+	.destroy = imx_tve_connector_destroy,
+};
+
+static struct drm_connector_helper_funcs imx_tve_connector_helper_funcs = {
+	.get_modes = imx_tve_connector_get_modes,
+	.best_encoder = imx_tve_connector_best_encoder,
+	.mode_valid = imx_tve_connector_mode_valid,
+};
+
+static struct drm_encoder_funcs imx_tve_encoder_funcs = {
+	.destroy = imx_tve_encoder_destroy,
+};
+
+static struct drm_encoder_helper_funcs imx_tve_encoder_helper_funcs = {
+	.dpms = imx_tve_encoder_dpms,
+	.mode_fixup = imx_tve_encoder_mode_fixup,
+	.prepare = imx_tve_encoder_prepare,
+	.mode_set = imx_tve_encoder_mode_set,
+	.commit = imx_tve_encoder_commit,
+	.disable = imx_tve_encoder_disable,
+};
+
+static irqreturn_t imx_tve_irq_handler(int irq, void *data)
+{
+	struct imx_tve *tve = data;
+	unsigned int val;
+
+	regmap_read(tve->regmap, TVE_STAT_REG, &val);
+
+	/* clear interrupt status register */
+	regmap_write(tve->regmap, TVE_STAT_REG, 0xffffffff);
+
+	return IRQ_HANDLED;
+}
+
+static unsigned long clk_tve_di_recalc_rate(struct clk_hw *hw,
+					    unsigned long parent_rate)
+{
+	struct imx_tve *tve = container_of(hw, struct imx_tve, clk_hw_di);
+	unsigned int val;
+	int ret;
+
+	ret = regmap_read(tve->regmap, TVE_COM_CONF_REG, &val);
+	if (ret < 0)
+		return 0;
+
+	switch (val & TVE_DAC_SAMP_RATE_MASK) {
+	case TVE_DAC_DIV4_RATE:
+		return parent_rate / 4;
+	case TVE_DAC_DIV2_RATE:
+		return parent_rate / 2;
+	case TVE_DAC_FULL_RATE:
+	default:
+		return parent_rate;
+	}
+
+	return 0;
+}
+
+static long clk_tve_di_round_rate(struct clk_hw *hw, unsigned long rate,
+				  unsigned long *prate)
+{
+	unsigned long div;
+
+	div = *prate / rate;
+	if (div >= 4)
+		return *prate / 4;
+	else if (div >= 2)
+		return *prate / 2;
+	else
+		return *prate;
+}
+
+static int clk_tve_di_set_rate(struct clk_hw *hw, unsigned long rate,
+			       unsigned long parent_rate)
+{
+	struct imx_tve *tve = container_of(hw, struct imx_tve, clk_hw_di);
+	unsigned long div;
+	u32 val;
+	int ret;
+
+	div = parent_rate / rate;
+	if (div >= 4)
+		val = TVE_DAC_DIV4_RATE;
+	else if (div >= 2)
+		val = TVE_DAC_DIV2_RATE;
+	else
+		val = TVE_DAC_FULL_RATE;
+
+	ret = regmap_update_bits(tve->regmap, TVE_COM_CONF_REG, TVE_DAC_SAMP_RATE_MASK, val);
+	if (ret < 0) {
+		dev_err(tve->dev, "failed to set divider: %d\n", ret);
+		return ret;
+	}
+
+	return 0;
+}
+
+static struct clk_ops clk_tve_di_ops = {
+	.round_rate = clk_tve_di_round_rate,
+	.set_rate = clk_tve_di_set_rate,
+	.recalc_rate = clk_tve_di_recalc_rate,
+};
+
+static int tve_clk_init(struct imx_tve *tve, void __iomem *base)
+{
+	const char *tve_di_parent[1];
+	struct clk_init_data init = {
+		.name = "tve_di",
+		.ops = &clk_tve_di_ops,
+		.num_parents = 1,
+		.flags = 0,
+	};
+
+	tve_di_parent[0] = __clk_get_name(tve->clk);
+	init.parent_names = (const char **)&tve_di_parent;
+
+	tve->clk_hw_di.init = &init;
+	tve->di_clk = clk_register(tve->dev, &tve->clk_hw_di);
+	if (IS_ERR(tve->di_clk)) {
+		dev_err(tve->dev, "failed to register TVE output clock: %ld\n",
+			PTR_ERR(tve->di_clk));
+		return PTR_ERR(tve->di_clk);
+	}
+
+	return 0;
+}
+
+static int imx_tve_register(struct imx_tve *tve)
+{
+	int ret;
+
+	tve->connector.funcs = &imx_tve_connector_funcs;
+	tve->encoder.funcs = &imx_tve_encoder_funcs;
+
+	tve->encoder.encoder_type = DRM_MODE_ENCODER_NONE;
+	tve->connector.connector_type = DRM_MODE_CONNECTOR_VGA;
+
+	drm_encoder_helper_add(&tve->encoder, &imx_tve_encoder_helper_funcs);
+	ret = imx_drm_add_encoder(&tve->encoder, &tve->imx_drm_encoder,
+			THIS_MODULE);
+	if (ret) {
+		dev_err(tve->dev, "adding encoder failed with %d\n", ret);
+		return ret;
+	}
+
+	drm_connector_helper_add(&tve->connector,
+			&imx_tve_connector_helper_funcs);
+
+	ret = imx_drm_add_connector(&tve->connector,
+			&tve->imx_drm_connector, THIS_MODULE);
+	if (ret) {
+		imx_drm_remove_encoder(tve->imx_drm_encoder);
+		dev_err(tve->dev, "adding connector failed with %d\n", ret);
+		return ret;
+	}
+
+	drm_mode_connector_attach_encoder(&tve->connector, &tve->encoder);
+
+	return 0;
+}
+
+static bool imx_tve_readable_reg(struct device *dev, unsigned int reg)
+{
+	return (reg % 4 == 0) && (reg <= 0xdc);
+}
+
+static struct regmap_config tve_regmap_config = {
+	.reg_bits = 32,
+	.val_bits = 32,
+	.reg_stride = 4,
+
+	.readable_reg = imx_tve_readable_reg,
+
+	.lock = tve_lock,
+	.unlock = tve_unlock,
+
+	.max_register = 0xdc,
+};
+
+static const char *imx_tve_modes[] = {
+	[TVE_MODE_TVOUT]  = "tvout",
+	[TVE_MODE_VGA] = "vga",
+};
+
+const int of_get_tve_mode(struct device_node *np)
+{
+	const char *bm;
+	int ret, i;
+
+	ret = of_property_read_string(np, "fsl,tve-mode", &bm);
+	if (ret < 0)
+		return ret;
+
+	for (i = 0; i < ARRAY_SIZE(imx_tve_modes); i++)
+		if (!strcasecmp(bm, imx_tve_modes[i]))
+			return i;
+
+	return -EINVAL;
+}
+
+static int imx_tve_probe(struct platform_device *pdev)
+{
+	struct device_node *np = pdev->dev.of_node;
+	struct device_node *ddc_node;
+	struct imx_tve *tve;
+	struct resource *res;
+	void __iomem *base;
+	unsigned int val;
+	int irq;
+	int ret;
+
+	tve = devm_kzalloc(&pdev->dev, sizeof(*tve), GFP_KERNEL);
+	if (!tve)
+		return -ENOMEM;
+
+	tve->dev = &pdev->dev;
+	spin_lock_init(&tve->lock);
+	spin_lock_init(&tve->enable_lock);
+
+	ddc_node = of_parse_phandle(np, "ddc", 0);
+	if (ddc_node) {
+		tve->ddc = of_find_i2c_adapter_by_node(ddc_node);
+		of_node_put(ddc_node);
+	}
+
+	tve->mode = of_get_tve_mode(np);
+	if (tve->mode != TVE_MODE_VGA) {
+		dev_err(&pdev->dev, "only VGA mode supported, currently\n");
+		return -EINVAL;
+	}
+
+	if (tve->mode == TVE_MODE_VGA) {
+		struct pinctrl *pinctrl;
+
+		pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
+		if (IS_ERR(pinctrl)) {
+			ret = PTR_ERR(pinctrl);
+			dev_warn(&pdev->dev, "failed to setup pinctrl: %d", ret);
+			return ret;
+		}
+
+		ret = of_property_read_u32(np, "fsl,hsync-pin", &tve->hsync_pin);
+		if (ret < 0) {
+			dev_err(&pdev->dev, "failed to get vsync pin\n");
+			return ret;
+		}
+
+		ret |= of_property_read_u32(np, "fsl,vsync-pin", &tve->vsync_pin);
+		if (ret < 0) {
+			dev_err(&pdev->dev, "failed to get vsync pin\n");
+			return ret;
+		}
+	}
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	if (!res) {
+		dev_err(&pdev->dev, "failed to get memory region\n");
+		return -ENOENT;
+	}
+
+	base = devm_request_and_ioremap(&pdev->dev, res);
+	if (!base) {
+		dev_err(&pdev->dev, "failed to remap memory region\n");
+		return -ENOENT;
+	}
+
+	tve_regmap_config.lock_arg = tve;
+	tve->regmap = devm_regmap_init_mmio_clk(&pdev->dev, "tve", base,
+						&tve_regmap_config);
+	if (IS_ERR(tve->regmap)) {
+		dev_err(&pdev->dev, "failed to init regmap: %ld\n",
+			PTR_ERR(tve->regmap));
+		return PTR_ERR(tve->regmap);
+	}
+
+	irq = platform_get_irq(pdev, 0);
+	if (irq < 0) {
+		dev_err(&pdev->dev, "failed to get irq\n");
+		return irq;
+	}
+
+	ret = devm_request_threaded_irq(&pdev->dev, irq, NULL,
+					imx_tve_irq_handler, IRQF_ONESHOT,
+					"imx-tve", tve);
+	if (ret < 0) {
+		dev_err(&pdev->dev, "failed to request irq: %d\n", ret);
+		return ret;
+	}
+
+	tve->dac_reg = devm_regulator_get(&pdev->dev, "dac");
+	if (!IS_ERR(tve->dac_reg)) {
+		regulator_set_voltage(tve->dac_reg, 2750000, 2750000);
+		regulator_enable(tve->dac_reg);
+	}
+
+	tve->clk = devm_clk_get(&pdev->dev, "tve");
+	if (IS_ERR(tve->clk)) {
+		dev_err(&pdev->dev, "failed to get high speed tve clock: %ld\n",
+			PTR_ERR(tve->clk));
+		return PTR_ERR(tve->clk);
+	}
+
+	/* this is the IPU DI clock input selector, can be parented to tve_di */
+	tve->di_sel_clk = devm_clk_get(&pdev->dev, "di_sel");
+	if (IS_ERR(tve->di_sel_clk)) {
+		dev_err(&pdev->dev, "failed to get ipu di mux clock: %ld\n",
+			PTR_ERR(tve->di_sel_clk));
+		return PTR_ERR(tve->di_sel_clk);
+	}
+
+	ret = tve_clk_init(tve, base);
+	if (ret < 0)
+		return ret;
+
+	ret = regmap_read(tve->regmap, TVE_COM_CONF_REG, &val);
+	if (ret < 0) {
+		dev_err(&pdev->dev, "failed to read configuration register: %d\n", ret);
+		return ret;
+	}
+	if (val != 0x00100000) {
+		dev_err(&pdev->dev, "configuration register default value indicates this is not a TVEv2\n");
+		return -ENODEV;
+	};
+
+	/* disable cable detection for VGA mode */
+	ret = regmap_write(tve->regmap, TVE_CD_CONT_REG, 0);
+
+	ret = imx_tve_register(tve);
+	if (ret)
+		return ret;
+
+	ret = imx_drm_encoder_add_possible_crtcs(tve->imx_drm_encoder, np);
+
+	platform_set_drvdata(pdev, tve);
+
+	return 0;
+}
+
+static int imx_tve_remove(struct platform_device *pdev)
+{
+	struct imx_tve *tve = platform_get_drvdata(pdev);
+	struct drm_connector *connector = &tve->connector;
+	struct drm_encoder *encoder = &tve->encoder;
+
+	drm_mode_connector_detach_encoder(connector, encoder);
+
+	imx_drm_remove_connector(tve->imx_drm_connector);
+	imx_drm_remove_encoder(tve->imx_drm_encoder);
+
+	if (!IS_ERR(tve->dac_reg))
+		regulator_disable(tve->dac_reg);
+
+	return 0;
+}
+
+static const struct of_device_id imx_tve_dt_ids[] = {
+	{ .compatible = "fsl,imx53-tve", },
+	{ /* sentinel */ }
+};
+
+static struct platform_driver imx_tve_driver = {
+	.probe		= imx_tve_probe,
+	.remove		= imx_tve_remove,
+	.driver		= {
+		.of_match_table = imx_tve_dt_ids,
+		.name	= "imx-tve",
+		.owner	= THIS_MODULE,
+	},
+};
+
+module_platform_driver(imx_tve_driver);
+
+MODULE_DESCRIPTION("i.MX Television Encoder driver");
+MODULE_AUTHOR("Philipp Zabel, Pengutronix");
+MODULE_LICENSE("GPL");
-- 
1.8.2.rc2



From p.zabel at pengutronix.de  Mon Apr  8 12:04:32 2013
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Mon,  8 Apr 2013 18:04:32 +0200
Subject: [PATCH 1/7] staging: drm/imx: ipu-dc: add 24-bit GBR support to DC
In-Reply-To: <1365437078-22579-1-git-send-email-p.zabel@pengutronix.de>
References: <1365437078-22579-1-git-send-email-p.zabel@pengutronix.de>
Message-ID: <1365437078-22579-2-git-send-email-p.zabel@pengutronix.de>

24-bit GBR order is needed on the display interface connected
to the Television Encoder (TVEv2) on i.MX53.

Signed-off-by: Philipp Zabel <p.zabel at pengutronix.de>
---
 drivers/staging/imx-drm/imx-drm.h       | 10 ++++++++++
 drivers/staging/imx-drm/ipu-v3/ipu-dc.c | 10 ++++++++++
 2 files changed, 20 insertions(+)

diff --git a/drivers/staging/imx-drm/imx-drm.h b/drivers/staging/imx-drm/imx-drm.h
index ae28a49..a24508f 100644
--- a/drivers/staging/imx-drm/imx-drm.h
+++ b/drivers/staging/imx-drm/imx-drm.h
@@ -1,8 +1,18 @@
 #ifndef _IMX_DRM_H_
 #define _IMX_DRM_H_
 
+#include <linux/videodev2.h>
+
+#define IPU_PIX_FMT_GBR24	v4l2_fourcc('G', 'B', 'R', '3')
+
+struct drm_crtc;
+struct drm_connector;
+struct drm_device;
+struct drm_encoder;
 struct imx_drm_crtc;
 struct drm_fbdev_cma;
+struct drm_framebuffer;
+struct platform_device;
 
 struct imx_drm_crtc_helper_funcs {
 	int (*enable_vblank)(struct drm_crtc *crtc);
diff --git a/drivers/staging/imx-drm/ipu-v3/ipu-dc.c b/drivers/staging/imx-drm/ipu-v3/ipu-dc.c
index 93c7579..fad5057 100644
--- a/drivers/staging/imx-drm/ipu-v3/ipu-dc.c
+++ b/drivers/staging/imx-drm/ipu-v3/ipu-dc.c
@@ -20,6 +20,7 @@
 #include <linux/delay.h>
 #include <linux/io.h>
 
+#include "../imx-drm.h"
 #include "imx-ipu-v3.h"
 #include "ipu-prv.h"
 
@@ -86,6 +87,7 @@ struct ipu_dc_priv;
 enum ipu_dc_map {
 	IPU_DC_MAP_RGB24,
 	IPU_DC_MAP_RGB565,
+	IPU_DC_MAP_GBR24, /* TVEv2 */
 };
 
 struct ipu_dc {
@@ -136,6 +138,8 @@ static int ipu_pixfmt_to_map(u32 fmt)
 		return IPU_DC_MAP_RGB24;
 	case V4L2_PIX_FMT_RGB565:
 		return IPU_DC_MAP_RGB565;
+	case IPU_PIX_FMT_GBR24:
+		return IPU_DC_MAP_GBR24;
 	default:
 		return -EINVAL;
 	}
@@ -364,6 +368,12 @@ int ipu_dc_init(struct ipu_soc *ipu, struct device *dev,
 	ipu_dc_map_config(priv, IPU_DC_MAP_RGB565, 1, 10, 0xfc); /* green */
 	ipu_dc_map_config(priv, IPU_DC_MAP_RGB565, 2, 15, 0xf8); /* red */
 
+	/* gbr24 */
+	ipu_dc_map_clear(priv, IPU_DC_MAP_GBR24);
+	ipu_dc_map_config(priv, IPU_DC_MAP_GBR24, 2, 15, 0xff); /* green */
+	ipu_dc_map_config(priv, IPU_DC_MAP_GBR24, 1, 7, 0xff); /* blue */
+	ipu_dc_map_config(priv, IPU_DC_MAP_GBR24, 0, 23, 0xff); /* red */
+
 	return 0;
 }
 
-- 
1.8.2.rc2



From p.zabel at pengutronix.de  Mon Apr  8 12:04:33 2013
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Mon,  8 Apr 2013 18:04:33 +0200
Subject: [PATCH 2/7] staging: drm/imx: ipuv3-crtc: use external clock for TV
 Encoder
In-Reply-To: <1365437078-22579-1-git-send-email-p.zabel@pengutronix.de>
References: <1365437078-22579-1-git-send-email-p.zabel@pengutronix.de>
Message-ID: <1365437078-22579-3-git-send-email-p.zabel@pengutronix.de>

Signed-off-by: Philipp Zabel <p.zabel at pengutronix.de>
---
 drivers/staging/imx-drm/ipuv3-crtc.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/staging/imx-drm/ipuv3-crtc.c b/drivers/staging/imx-drm/ipuv3-crtc.c
index b028b0d..620e571 100644
--- a/drivers/staging/imx-drm/ipuv3-crtc.c
+++ b/drivers/staging/imx-drm/ipuv3-crtc.c
@@ -413,6 +413,8 @@ static int ipu_set_interface_pix_fmt(struct drm_crtc *crtc, u32 encoder_type,
 	ipu_crtc->interface_pix_fmt = pixfmt;
 
 	switch (encoder_type) {
+	case DRM_MODE_ENCODER_DAC:
+	case DRM_MODE_ENCODER_TVDAC:
 	case DRM_MODE_ENCODER_LVDS:
 		ipu_crtc->di_clkflags = IPU_DI_CLKMODE_SYNC |
 			IPU_DI_CLKMODE_EXT;
-- 
1.8.2.rc2



From p.zabel at pengutronix.de  Mon Apr  8 12:04:34 2013
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Mon,  8 Apr 2013 18:04:34 +0200
Subject: [PATCH 3/7] staging: drm/imx: ipu-di: add comments explaining signal
 generator configuration
In-Reply-To: <1365437078-22579-1-git-send-email-p.zabel@pengutronix.de>
References: <1365437078-22579-1-git-send-email-p.zabel@pengutronix.de>
Message-ID: <1365437078-22579-4-git-send-email-p.zabel@pengutronix.de>

Signed-off-by: Philipp Zabel <p.zabel at pengutronix.de>
---
 drivers/staging/imx-drm/ipu-v3/ipu-di.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/imx-drm/ipu-v3/ipu-di.c b/drivers/staging/imx-drm/ipu-v3/ipu-di.c
index ec340da..26534b7 100644
--- a/drivers/staging/imx-drm/ipu-v3/ipu-di.c
+++ b/drivers/staging/imx-drm/ipu-v3/ipu-di.c
@@ -413,9 +413,11 @@ static void ipu_di_sync_config_noninterlaced(struct ipu_di *di,
 		sig->v_end_width;
 	struct di_sync_config cfg[] = {
 		{
+			/* 1: INT_HSYNC */
 			.run_count = h_total - 1,
 			.run_src = DI_SYNC_CLK,
 		} , {
+			/* PIN2: HSYNC */
 			.run_count = h_total - 1,
 			.run_src = DI_SYNC_CLK,
 			.offset_count = div * sig->v_to_h_sync,
@@ -424,23 +426,28 @@ static void ipu_di_sync_config_noninterlaced(struct ipu_di *di,
 			.cnt_polarity_trigger_src = DI_SYNC_CLK,
 			.cnt_down = sig->h_sync_width * 2,
 		} , {
+			/* PIN3: VSYNC */
 			.run_count = v_total - 1,
 			.run_src = DI_SYNC_INT_HSYNC,
 			.cnt_polarity_gen_en = 1,
 			.cnt_polarity_trigger_src = DI_SYNC_INT_HSYNC,
 			.cnt_down = sig->v_sync_width * 2,
 		} , {
+			/* 4: Line Active */
 			.run_src = DI_SYNC_HSYNC,
 			.offset_count = sig->v_sync_width + sig->v_start_width,
 			.offset_src = DI_SYNC_HSYNC,
 			.repeat_count = sig->height,
 			.cnt_clr_src = DI_SYNC_VSYNC,
 		} , {
+			/* 5: DE, referenced by DC */
 			.run_src = DI_SYNC_CLK,
 			.offset_count = sig->h_sync_width + sig->h_start_width,
 			.offset_src = DI_SYNC_CLK,
 			.repeat_count = sig->width,
-			.cnt_clr_src = 5,
+			.cnt_clr_src = 5, /* Line Active */
+		} , {
+			/* unused */
 		} , {
 			/* unused */
 		} , {
-- 
1.8.2.rc2



From cjb at laptop.org  Mon Apr  8 12:07:58 2013
From: cjb at laptop.org (Chris Ball)
Date: Mon, 08 Apr 2013 12:07:58 -0400
Subject: [PATCH] mmc: atmel-mci: pio hang on block errors
In-Reply-To: <20130408160224.GC6398@ludovic.desroches@atmel.com> (Ludovic
 Desroches's message of "Mon, 8 Apr 2013 18:02:24 +0200")
References: <1363771946-8931-1-git-send-email-ludovic.desroches@atmel.com>
 <20130408160224.GC6398@ludovic.desroches@atmel.com>
Message-ID: <87y5ctm2e9.fsf@octavius.laptop.org>

Hi,

On Mon, Apr 08 2013, Ludovic Desroches wrote:
> Could you take this fix? If there are no objections of course.

Thanks for the reminder; pushed to mmc-next now.

- Chris.
-- 
Chris Ball   <cjb at laptop.org>   <http://printf.net/>
One Laptop Per Child


From dianders at google.com  Mon Apr  8 12:08:30 2013
From: dianders at google.com (Doug Anderson)
Date: Mon, 8 Apr 2013 09:08:30 -0700
Subject: [PATCH v3] mmc: dw_mmc: let device core setup the default pin
 configuration
In-Reply-To: <1365170015-3009-1-git-send-email-thomas.abraham@linaro.org>
References: <1365170015-3009-1-git-send-email-thomas.abraham@linaro.org>
Message-ID: <CAD=FV=U7kf_b92w7rDFkZN8Wr4sDTq5_=pMHaP948dT5CZbHsg@mail.gmail.com>

Thomas,

Since I commented on previous versions of this patch, I would have
loved to have been CCed on this new version.  ;)

On Fri, Apr 5, 2013 at 6:53 AM, Thomas Abraham
<thomas.abraham at linaro.org> wrote:
> With device core now able to setup the default pin configuration,
> the pin configuration code based on the deprecated Samsung specific
> gpio bindings is removed.
>
> Signed-off-by: Thomas Abraham <thomas.abraham at linaro.org>
> ---
> Changes since v2:
> - Changed patch subject from "mmc: dwmmc: let..." to "mmc: dw_mmc: let..."
> - Rebased to Chris's latest mmc-next branch.
>
>  drivers/mmc/host/dw_mmc-exynos.c |   38 --------------------------------------
>  drivers/mmc/host/dw_mmc.c        |   12 ++----------
>  drivers/mmc/host/dw_mmc.h        |    3 ---
>  3 files changed, 2 insertions(+), 51 deletions(-)

This patch applies fine but fails to compile on linux-next
"next-20130408".  You lost the race with:
   f2f942c mmc: dw_mmc: Check return value of regulator_enable

...that patch adds a "goto err_setup_bus" and you've renamed that
label.  I guess you get another fun rebase.

NOTE: this patch is even more urgent than it was before.  It looks
like pincontrol stuff has now landed in linux-next which means that
Exynos5 devices that need eMMC/SD will no longer boot until this patch
goes in.

-Doug


From festevam at gmail.com  Mon Apr  8 12:11:30 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Mon, 8 Apr 2013 13:11:30 -0300
Subject: [PATCH 0/5] i.MX53 TVE clock patches
In-Reply-To: <CAOMZO5CjC4HEvZo7rqdN1inAz_=xif=5aANLPhB9oF_mygJeGg@mail.gmail.com>
References: <1365432383-7787-1-git-send-email-p.zabel@pengutronix.de>
 <CAOMZO5CjC4HEvZo7rqdN1inAz_=xif=5aANLPhB9oF_mygJeGg@mail.gmail.com>
Message-ID: <CAOMZO5DwpbWuRzGCkWxP_9ffRXfh-AzQhTVXE1nYXXJCFp1iEg@mail.gmail.com>

On Mon, Apr 8, 2013 at 12:26 PM, Fabio Estevam <festevam at gmail.com> wrote:
> Hi Phiipp,
>
> On Mon, Apr 8, 2013 at 11:46 AM, Philipp Zabel <p.zabel at pengutronix.de> wrote:
>> Hi,
>>
>> the first two are just cleanups, the following three patches are changes
>> to the i.MX53 clock tree that are necessary to use the TVEv2 module as
>> VGA output on the Freescale i.MX53-QSB or TQ MBa53 boards.
>
> I would like to test this series on a mx53qsb.
>
> Is the TVE driver available in some git tree?

Just found the driver in my Inbox now.

Thanks for your work,Philipp


From sameo at linux.intel.com  Mon Apr  8 12:11:24 2013
From: sameo at linux.intel.com (Samuel Ortiz)
Date: Mon, 8 Apr 2013 18:11:24 +0200
Subject: [PATCH v10 0/12] Palmas updates
In-Reply-To: <5162E88E.9010204@slimlogic.co.uk>
References: <1363964122-19201-1-git-send-email-ian@slimlogic.co.uk>
 <20130405163056.GN17363@zurbaran>
 <5162E88E.9010204@slimlogic.co.uk>
Message-ID: <20130408161124.GA7255@zurbaran>

Hi Graeme,

On Mon, Apr 08, 2013 at 04:55:58PM +0100, Graeme Gregory wrote:
> On 05/04/13 17:30, Samuel Ortiz wrote:
> > Hi Ian,
> >
> > On Fri, Mar 22, 2013 at 02:55:10PM +0000, Ian Lartey wrote:
> >> This patchset adds to the support for the Palmas series of PMIC chips.
> >>
> >> Some of the patches have previously been submitted individually.
> >> The DT bindings doc has been added first due to comments that it was missing.
> >>
> >> Patches based on linux-next-20130319
> > Are you expecting all those patches to go through the MFD tree ?
> > Also, you stil have a few comments from Milo and Stephen to adress. Are you
> > planning to send a v11 ?
> >
> >
> Hi Samuel,
> 
> The device is an MFD so I suspect the best path is through MFD tree
Yes, that's fine. I just need to make sure everyone is on sync.


> although I notice you have applied the patch that was required by all
> other patches so maybe this is not so much the case now!
> 
> Real life has got in the way of the next updated series of patches but
> they will be issued just as soon as we can.
I know about real life getting in the way, no worries ;)

Cheers,
Samuel.

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


From swarren at wwwdotorg.org  Mon Apr  8 12:11:30 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Mon, 08 Apr 2013 10:11:30 -0600
Subject: GENERIC_GPIO considered deprecated
In-Reply-To: <2c9501ce342b$1535d290$3fa177b0$%kim@samsung.com>
References: <CAAVeFu+QUw1WmzwaJDfjyw75PrStd3p3PHs1MU5BC7_WXMB7kw@mail.gmail.com>
 <51576214.8010307@openwide.fr>
 <CAAVeFu++8YOOSxPbAaTudxSGcBomkGrakBjiVyD+XSee54TrWw@mail.gmail.com>
 <26e401ce30cc$602e45f0$208ad1d0$%kim@samsung.com>
 <CAAVeFuJcAgFma6wxmyoUN4Kfp-+y-gj3QMWvVYsCK_D8q0gSXQ@mail.gmail.com>
 <2c9501ce342b$1535d290$3fa177b0$%kim@samsung.com>
Message-ID: <5162EC32.2030602@wwwdotorg.org>

On 04/08/2013 01:31 AM, Kukjin Kim wrote:
> Alexandre Courbot wrote:
>>
>> On Wed, Apr 3, 2013 at 5:35 PM, Kukjin Kim <kgene.kim at samsung.com> wrote:
>>>> could you amend the patches that adds them such as they get changed
>>>> into "select ARCH_REQUIRE_GPIOLIB" instead? You can grep for "select
>>>
>>> I can do it for my tree but the branch already included in arm-soc tree
>> so I think, it should be fixed with another patch. And
>>>
>>>> GENERIC_GPIO" in arch/arm to find the offending lines. We are removing
>>>> GENERIC_GPIO and this work cannot be merged until you do this since it
>>>> would break ARM builds. Thanks!
>>>>
>>> So how about following? If you are OK, let me take into samsung tree.
>>>
>>> --------8<----------------8<--------
>>> From: Kukjin Kim <kgene.kim at samsung.com>
>>> Subject: [PATCH] ARM: SAMSUNG: change GENERIC_GPIO to
>> ARCH_REQUIRE_GPIOLIB
>>>
>>> When I applied regarding samsung-time patches, the "select GENERIC_GPIO"
>>> has been added wrong, so this patch fixes that.
>>> And since the GENERIC_GPIO in arch/arm/ will be gone away, this adds
>>> ARCH_REQUIRE_GPIOLIB for S3C24XX and S5PC100 instead.
>>>
>>> Reported-by: Alexandre Courbot <gnurou at gmail.com>
>>> Cc: Romain Naour <romain.naour at openwide.fr>
>>> Signed-off-by: Kukjin Kim <kgene.kim at samsung.com>
>>> ---
>>>  arch/arm/Kconfig |    4 ++--
>>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>>> index 46fcfa8..a239c7e 100644
>>> --- a/arch/arm/Kconfig
>>> +++ b/arch/arm/Kconfig
>>> @@ -770,10 +770,10 @@ config ARCH_SA1100
>>>  config ARCH_S3C24XX
>>>         bool "Samsung S3C24XX SoCs"
>>>         select ARCH_HAS_CPUFREQ
>>> +       select ARCH_REQUIRE_GPIOLIB
>>>         select CLKDEV_LOOKUP
>>>         select CLKSRC_MMIO
>>>         select GENERIC_CLOCKEVENTS
>>> -       select GENERIC_GPIO
>>>         select HAVE_CLK
>>>         select HAVE_S3C2410_I2C if I2C
>>>         select HAVE_S3C2410_WATCHDOG if WATCHDOG
>>> @@ -828,11 +828,11 @@ config ARCH_S5P64X0
>>>
>>>  config ARCH_S5PC100
>>>         bool "Samsung S5PC100"
>>> +       select ARCH_REQUIRE_GPIOLIB
>>>         select CLKDEV_LOOKUP
>>>         select CLKSRC_MMIO
>>>         select CPU_V7
>>>         select GENERIC_CLOCKEVENTS
>>> -       select GENERIC_GPIO
>>>         select HAVE_CLK
>>>         select HAVE_S3C2410_I2C if I2C
>>>         select HAVE_S3C2410_WATCHDOG if WATCHDOG
>>> --
>>> 1.7.10.4
>>
>> Should do the trick, if we can make sure that your tree is merged
>> prior to my patches.
> 
> I'm not sure but I think, arm-soc tree should be merged into mainline before others...
> 
>> Can you put it into your tree for 3.10?
>>
> I did, so it should be fine.
> 
> Thanks.
> 
> - Kukjin

You may want to discuss how to handle this dependency with the arm-soc
maintainers (CC'd).


From arnd at arndb.de  Mon Apr  8 12:13:33 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 8 Apr 2013 18:13:33 +0200
Subject: [PATCH 2/5] dmaengine: ste_dma40: Assign memcpy channels in the
 driver
In-Reply-To: <1365434591-21569-2-git-send-email-lee.jones@linaro.org>
References: <1365434591-21569-1-git-send-email-lee.jones@linaro.org>
 <1365434591-21569-2-git-send-email-lee.jones@linaro.org>
Message-ID: <201304081813.33926.arnd@arndb.de>

On Monday 08 April 2013, Lee Jones wrote:
> The channels reserved for memcpy are the same for all currently
> supported platforms. With this in mind, we can ease the platform
> data passing requirement by moving these assignments out from
> platform code and place them directly into the driver.
> 
> Cc: Vinod Koul <vinod.koul at intel.com>
> Cc: Dan Williams <djbw at fb.com>
> Cc: Per Forlin <per.forlin at stericsson.com>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>

Acked-by: Arnd Bergmann <arnd at arndb.de>


From arnd at arndb.de  Mon Apr  8 12:14:00 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 8 Apr 2013 18:14:00 +0200
Subject: [PATCH 3/5] dmaengine: ste_dma40: Move default memcpy configs
 into the driver
In-Reply-To: <1365434591-21569-3-git-send-email-lee.jones@linaro.org>
References: <1365434591-21569-1-git-send-email-lee.jones@linaro.org>
 <1365434591-21569-3-git-send-email-lee.jones@linaro.org>
Message-ID: <201304081814.00868.arnd@arndb.de>

On Monday 08 April 2013, Lee Jones wrote:
> There are only two default memcpy configurations used for the DMA40
> driver; one for physical memcpy and one for logical memcpy. Instead
> of invariably passing the same configurations though platform data,
> we're moving them into the driver instead.
> 
> Cc: Vinod Koul <vinod.koul at intel.com>
> Cc: Dan Williams <djbw at fb.com>
> Cc: Per Forlin <per.forlin at stericsson.com>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>

Acked-by: Arnd Bergmann <arnd at arndb.de>


From dave.martin at linaro.org  Mon Apr  8 12:13:53 2013
From: dave.martin at linaro.org (Dave Martin)
Date: Mon, 8 Apr 2013 17:13:53 +0100
Subject: some question about monitor mode support in arm
In-Reply-To: <CANudz+tPrFxUEhzbpdVYnhnzKnJJ2wsJ7s_3YAWiOUJjJhQ3YA@mail.gmail.com>
References: <CANudz+tPrFxUEhzbpdVYnhnzKnJJ2wsJ7s_3YAWiOUJjJhQ3YA@mail.gmail.com>
Message-ID: <20130408161353.GA2176@linaro.org>

On Thu, Mar 14, 2013 at 05:43:30PM +0800, loody wrote:
> Hi all:
> Does linux kernel support monitor mode handling?

No.  In theory the kernel could make use of TrustZone if it is not
locked down by vendor firmware ... but it is hard to make effective
use of it in a large general-purpose software stack like the Linux
kernel.

In consumer devices, TrustZone is often locked down by vendor
firmware, and then Linux can't play with it anyway.


> I grep the keyword 'smc' but it only show how switch to, such as
> mach-highbank/smc.S,
> but not seem where to handle it.

What are you trying to achieve?

Cheers
---Dave


From p.zabel at pengutronix.de  Mon Apr  8 12:16:35 2013
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Mon,  8 Apr 2013 18:16:35 +0200
Subject: [PATCH 2/2] ARM i.MX53: dts: Add TVE to i.MX53-QSB device tree
In-Reply-To: <1365437795-30074-1-git-send-email-p.zabel@pengutronix.de>
References: <1365437795-30074-1-git-send-email-p.zabel@pengutronix.de>
Message-ID: <1365437795-30074-3-git-send-email-p.zabel@pengutronix.de>

Signed-off-by: Philipp Zabel <p.zabel at pengutronix.de>
---
 arch/arm/boot/dts/imx53-qsb.dts | 25 +++++++++++++++++++++++--
 1 file changed, 23 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/imx53-qsb.dts b/arch/arm/boot/dts/imx53-qsb.dts
index 8f0e9ae..9141d19 100644
--- a/arch/arm/boot/dts/imx53-qsb.dts
+++ b/arch/arm/boot/dts/imx53-qsb.dts
@@ -129,6 +129,15 @@
 		};
 	};
 
+	tve {
+		pinctrl_vga_sync_1: vgasync-grp1 {
+			fsl,pins = <
+				/* VGA_HSYNC, VSYNC with max drive strength */
+				614 0xe6	/* MX53_PAD_EIM_OE__IPU_DI1_PIN7 */
+				619 0xe6	/* MX53_PAD_EIM_RW__IPU_DI1_PIN8 */
+			>;
+		};
+	};
 };
 
 &uart1 {
@@ -235,8 +244,8 @@
 			};
 
 			ldo8_reg: ldo8 {
-				regulator-min-microvolt = <1200000>;
-				regulator-max-microvolt = <3600000>;
+				regulator-min-microvolt = <2750000>;
+				regulator-max-microvolt = <2750000>;
 				regulator-always-on;
 			};
 
@@ -268,3 +277,15 @@
 	phy-reset-gpios = <&gpio7 6 0>;
 	status = "okay";
 };
+
+&tve {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_vga_sync_1>;
+	ddc = <&i2c2>;
+	fsl,tve-mode = "vga";
+	status = "okay";
+	dac-supply = <&ldo7_reg>;
+
+	fsl,hsync-pin = <7>; /* IPU DI1 PIN7 via EIM_OE */
+	fsl,vsync-pin = <8>; /* IPU DI1 PIN8 via EIM_RW */
+};
-- 
1.8.2.rc2



From p.zabel at pengutronix.de  Mon Apr  8 12:16:34 2013
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Mon,  8 Apr 2013 18:16:34 +0200
Subject: [PATCH 1/2] ARM i.MX53: Add TVE entry to i.MX53 dtsi
In-Reply-To: <1365437795-30074-1-git-send-email-p.zabel@pengutronix.de>
References: <1365437795-30074-1-git-send-email-p.zabel@pengutronix.de>
Message-ID: <1365437795-30074-2-git-send-email-p.zabel@pengutronix.de>

This adds the Television Encoder (TVEv2) device tree node
to the i.MX53 dtsi.

Signed-off-by: Philipp Zabel <p.zabel at pengutronix.de>
---
 arch/arm/boot/dts/imx53.dtsi | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/imx53.dtsi b/arch/arm/boot/dts/imx53.dtsi
index 845982e..d847502 100644
--- a/arch/arm/boot/dts/imx53.dtsi
+++ b/arch/arm/boot/dts/imx53.dtsi
@@ -781,6 +781,16 @@
 				clock-names = "ipg", "ahb", "ptp";
 				status = "disabled";
 			};
+
+			tve: tve at 63ff0000 {
+				compatible = "fsl,imx53-tve";
+				reg = <0x63ff0000 0x1000>;
+				interrupts = <92>;
+				clocks = <&clks 69>, <&clks 116>;
+				clock-names = "tve", "di_sel";
+				crtcs = <&ipu 1>;
+				status = "disabled";
+			};
 		};
 	};
 };
-- 
1.8.2.rc2



From p.zabel at pengutronix.de  Mon Apr  8 12:16:33 2013
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Mon,  8 Apr 2013 18:16:33 +0200
Subject: [PATCH 0/2] Add TVE to i.MX53-QSB device tree
Message-ID: <1365437795-30074-1-git-send-email-p.zabel@pengutronix.de>

Hi,

these two patches add the necessary TVE device tree nodes to the
i.MX53 dtsi and to the i.MX53-QSB dts, including pin configuration
for HSYNC and VSYNC pins.

regards
Philipp

---
 arch/arm/boot/dts/imx53-qsb.dts |   25 +++++++++++++++++++++++--
 arch/arm/boot/dts/imx53.dtsi    |   10 ++++++++++
 2 files changed, 33 insertions(+), 2 deletions(-)



From marc.zyngier at arm.com  Mon Apr  8 12:17:06 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon,  8 Apr 2013 17:17:06 +0100
Subject: [PATCH v3 04/32] arm64: KVM: EL2 register definitions
In-Reply-To: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1365437854-30214-5-git-send-email-marc.zyngier@arm.com>

Define all the useful bitfields for EL2 registers.

Reviewed-by: Christopher Covington <cov at codeaurora.org>
Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/include/asm/kvm_arm.h | 243 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 243 insertions(+)
 create mode 100644 arch/arm64/include/asm/kvm_arm.h

diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h
new file mode 100644
index 0000000..8ced0ca
--- /dev/null
+++ b/arch/arm64/include/asm/kvm_arm.h
@@ -0,0 +1,243 @@
+/*
+ * Copyright (C) 2012,2013 - ARM Ltd
+ * Author: Marc Zyngier <marc.zyngier at arm.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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#ifndef __ARM64_KVM_ARM_H__
+#define __ARM64_KVM_ARM_H__
+
+#include <asm/types.h>
+
+/* Hyp Configuration Register (HCR) bits */
+#define HCR_ID		(1 << 33)
+#define HCR_CD		(1 << 32)
+#define HCR_RW_SHIFT	31
+#define HCR_RW		(1 << HCR_RW_SHIFT)
+#define HCR_TRVM	(1 << 30)
+#define HCR_HCD		(1 << 29)
+#define HCR_TDZ		(1 << 28)
+#define HCR_TGE		(1 << 27)
+#define HCR_TVM		(1 << 26)
+#define HCR_TTLB	(1 << 25)
+#define HCR_TPU		(1 << 24)
+#define HCR_TPC		(1 << 23)
+#define HCR_TSW		(1 << 22)
+#define HCR_TAC		(1 << 21)
+#define HCR_TIDCP	(1 << 20)
+#define HCR_TSC		(1 << 19)
+#define HCR_TID3	(1 << 18)
+#define HCR_TID2	(1 << 17)
+#define HCR_TID1	(1 << 16)
+#define HCR_TID0	(1 << 15)
+#define HCR_TWE		(1 << 14)
+#define HCR_TWI		(1 << 13)
+#define HCR_DC		(1 << 12)
+#define HCR_BSU		(3 << 10)
+#define HCR_BSU_IS	(1 << 10)
+#define HCR_FB		(1 << 9)
+#define HCR_VA		(1 << 8)
+#define HCR_VI		(1 << 7)
+#define HCR_VF		(1 << 6)
+#define HCR_AMO		(1 << 5)
+#define HCR_IMO		(1 << 4)
+#define HCR_FMO		(1 << 3)
+#define HCR_PTW		(1 << 2)
+#define HCR_SWIO	(1 << 1)
+#define HCR_VM		(1)
+
+/*
+ * The bits we set in HCR:
+ * RW:		64bit by default, can be overriden for 32bit VMs
+ * TAC:		Trap ACTLR
+ * TSC:		Trap SMC
+ * TSW:		Trap cache operations by set/way
+ * TWI:		Trap WFI
+ * TIDCP:	Trap L2CTLR/L2ECTLR
+ * BSU_IS:	Upgrade barriers to the inner shareable domain
+ * FB:		Force broadcast of all maintainance operations
+ * AMO:		Override CPSR.A and enable signaling with VA
+ * IMO:		Override CPSR.I and enable signaling with VI
+ * FMO:		Override CPSR.F and enable signaling with VF
+ * SWIO:	Turn set/way invalidates into set/way clean+invalidate
+ */
+#define HCR_GUEST_FLAGS (HCR_TSC | HCR_TSW | HCR_TWI | HCR_VM | HCR_BSU_IS | \
+			 HCR_FB | HCR_TAC | HCR_AMO | HCR_IMO | HCR_FMO | \
+			 HCR_SWIO | HCR_TIDCP | HCR_RW)
+#define HCR_VIRT_EXCP_MASK (HCR_VA | HCR_VI | HCR_VF)
+
+/* Hyp System Control Register (SCTLR_EL2) bits */
+#define SCTLR_EL2_EE	(1 << 25)
+#define SCTLR_EL2_WXN	(1 << 19)
+#define SCTLR_EL2_I	(1 << 12)
+#define SCTLR_EL2_SA	(1 << 3)
+#define SCTLR_EL2_C	(1 << 2)
+#define SCTLR_EL2_A	(1 << 1)
+#define SCTLR_EL2_M	1
+#define SCTLR_EL2_FLAGS	(SCTLR_EL2_M | SCTLR_EL2_A | SCTLR_EL2_C |	\
+			 SCTLR_EL2_SA | SCTLR_EL2_I)
+
+/* TCR_EL2 Registers bits */
+#define TCR_EL2_TBI	(1 << 20)
+#define TCR_EL2_PS	(7 << 16)
+#define TCR_EL2_PS_40B	(2 << 16)
+#define TCR_EL2_TG0	(1 << 14)
+#define TCR_EL2_SH0	(3 << 12)
+#define TCR_EL2_ORGN0	(3 << 10)
+#define TCR_EL2_IRGN0	(3 << 8)
+#define TCR_EL2_T0SZ	0x3f
+#define TCR_EL2_MASK	(TCR_EL2_TG0 | TCR_EL2_SH0 | \
+			 TCR_EL2_ORGN0 | TCR_EL2_IRGN0 | TCR_EL2_T0SZ)
+
+#define TCR_EL2_FLAGS	(TCR_EL2_PS_40B)
+
+/* VTCR_EL2 Registers bits */
+#define VTCR_EL2_PS_MASK	(7 << 16)
+#define VTCR_EL2_PS_40B		(2 << 16)
+#define VTCR_EL2_TG0_MASK	(1 << 14)
+#define VTCR_EL2_TG0_4K		(0 << 14)
+#define VTCR_EL2_TG0_64K	(1 << 14)
+#define VTCR_EL2_SH0_MASK	(3 << 12)
+#define VTCR_EL2_SH0_INNER	(3 << 12)
+#define VTCR_EL2_ORGN0_MASK	(3 << 10)
+#define VTCR_EL2_ORGN0_WBWA	(3 << 10)
+#define VTCR_EL2_IRGN0_MASK	(3 << 8)
+#define VTCR_EL2_IRGN0_WBWA	(3 << 8)
+#define VTCR_EL2_SL0_MASK	(3 << 6)
+#define VTCR_EL2_SL0_LVL1	(1 << 6)
+#define VTCR_EL2_T0SZ_MASK	0x3f
+#define VTCR_EL2_T0SZ_40B	24
+
+#ifdef CONFIG_ARM64_64K_PAGES
+/*
+ * Stage2 translation configuration:
+ * 40bits output (PS = 2)
+ * 40bits input  (T0SZ = 24)
+ * 64kB pages (TG0 = 1)
+ * 2 level page tables (SL = 1)
+ */
+#define VTCR_EL2_FLAGS		(VTCR_EL2_PS_40B | VTCR_EL2_TG0_64K | \
+				 VTCR_EL2_SH0_INNER | VTCR_EL2_ORGN0_WBWA | \
+				 VTCR_EL2_IRGN0_WBWA | VTCR_EL2_SL0_LVL1 | \
+				 VTCR_EL2_T0SZ_40B)
+#define VTTBR_X		(38 - VTCR_EL2_T0SZ_40B)
+#else
+/*
+ * Stage2 translation configuration:
+ * 40bits output (PS = 2)
+ * 40bits input  (T0SZ = 24)
+ * 4kB pages (TG0 = 0)
+ * 3 level page tables (SL = 1)
+ */
+#define VTCR_EL2_FLAGS		(VTCR_EL2_PS_40B | VTCR_EL2_TG0_4K | \
+				 VTCR_EL2_SH0_INNER | VTCR_EL2_ORGN0_WBWA | \
+				 VTCR_EL2_IRGN0_WBWA | VTCR_EL2_SL0_LVL1 | \
+				 VTCR_EL2_T0SZ_40B)
+#define VTTBR_X		(37 - VTCR_EL2_T0SZ_40B)
+#endif
+
+#define VTTBR_BADDR_SHIFT (VTTBR_X - 1)
+#define VTTBR_BADDR_MASK  (((1LLU << (40 - VTTBR_X)) - 1) << VTTBR_BADDR_SHIFT)
+#define VTTBR_VMID_SHIFT  (48LLU)
+#define VTTBR_VMID_MASK	  (0xffLLU << VTTBR_VMID_SHIFT)
+
+/* Hyp System Trap Register */
+#define HSTR_EL2_TTEE	(1 << 16)
+#define HSTR_EL2_T(x)	(1 << x)
+
+/* Hyp Coprocessor Trap Register */
+#define CPTR_EL2_TCPAC	(1 << 31)
+#define CPTR_EL2_TTA	(1 << 20)
+#define CPTR_EL2_TFP	(1 << 10)
+
+/* Hyp Debug Configuration Register bits */
+#define MDCR_EL2_TDRA		(1 << 11)
+#define MDCR_EL2_TDOSA		(1 << 10)
+#define MDCR_EL2_TDA		(1 << 9)
+#define MDCR_EL2_TDE		(1 << 8)
+#define MDCR_EL2_HPME		(1 << 7)
+#define MDCR_EL2_TPM		(1 << 6)
+#define MDCR_EL2_TPMCR		(1 << 5)
+#define MDCR_EL2_HPMN_MASK	(0x1F)
+
+/* Exception Syndrome Register (ESR) bits */
+#define ESR_EL2_EC_SHIFT	(26)
+#define ESR_EL2_EC		(0x3fU << ESR_EL2_EC_SHIFT)
+#define ESR_EL2_IL		(1U << 25)
+#define ESR_EL2_ISS		(ESR_EL2_IL - 1)
+#define ESR_EL2_ISV_SHIFT	(24)
+#define ESR_EL2_ISV		(1U << ESR_EL2_ISV_SHIFT)
+#define ESR_EL2_SAS_SHIFT	(22)
+#define ESR_EL2_SAS		(3U << ESR_EL2_SAS_SHIFT)
+#define ESR_EL2_SSE		(1 << 21)
+#define ESR_EL2_SRT_SHIFT	(16)
+#define ESR_EL2_SRT_MASK	(0x1f << ESR_EL2_SRT_SHIFT)
+#define ESR_EL2_SF 		(1 << 15)
+#define ESR_EL2_AR 		(1 << 14)
+#define ESR_EL2_EA 		(1 << 9)
+#define ESR_EL2_CM 		(1 << 8)
+#define ESR_EL2_S1PTW 		(1 << 7)
+#define ESR_EL2_WNR		(1 << 6)
+#define ESR_EL2_FSC		(0x3f)
+#define ESR_EL2_FSC_TYPE	(0x3c)
+
+#define ESR_EL2_CV_SHIFT	(24)
+#define ESR_EL2_CV		(1U << ESR_EL2_CV_SHIFT)
+#define ESR_EL2_COND_SHIFT	(20)
+#define ESR_EL2_COND		(0xfU << ESR_EL2_COND_SHIFT)
+
+
+#define FSC_FAULT	(0x04)
+#define FSC_PERM	(0x0c)
+
+/* Hyp Prefetch Fault Address Register (HPFAR/HDFAR) */
+#define HPFAR_MASK	(~0xFUL)
+
+#define ESR_EL2_EC_UNKNOWN	(0x00)
+#define ESR_EL2_EC_WFI		(0x01)
+#define ESR_EL2_EC_CP15_32	(0x03)
+#define ESR_EL2_EC_CP15_64	(0x04)
+#define ESR_EL2_EC_CP14_MR	(0x05)
+#define ESR_EL2_EC_CP14_LS	(0x06)
+#define ESR_EL2_EC_FP_ASIMD	(0x07)
+#define ESR_EL2_EC_CP10_ID	(0x08)
+#define ESR_EL2_EC_CP14_64	(0x0C)
+#define ESR_EL2_EC_ILL_ISS	(0x0E)
+#define ESR_EL2_EC_SVC32	(0x11)
+#define ESR_EL2_EC_HVC32	(0x12)
+#define ESR_EL2_EC_SMC32	(0x13)
+#define ESR_EL2_EC_SVC64	(0x15)
+#define ESR_EL2_EC_HVC64	(0x16)
+#define ESR_EL2_EC_SMC64	(0x17)
+#define ESR_EL2_EC_SYS64	(0x18)
+#define ESR_EL2_EC_IABT		(0x20)
+#define ESR_EL2_EC_IABT_HYP	(0x21)
+#define ESR_EL2_EC_PC_ALIGN	(0x22)
+#define ESR_EL2_EC_DABT		(0x24)
+#define ESR_EL2_EC_DABT_HYP	(0x25)
+#define ESR_EL2_EC_SP_ALIGN	(0x26)
+#define ESR_EL2_EC_FP_EXC32	(0x28)
+#define ESR_EL2_EC_FP_EXC64	(0x2C)
+#define ESR_EL2_EC_SERRROR	(0x2F)
+#define ESR_EL2_EC_BREAKPT	(0x30)
+#define ESR_EL2_EC_BREAKPT_HYP	(0x31)
+#define ESR_EL2_EC_SOFTSTP	(0x32)
+#define ESR_EL2_EC_SOFTSTP_HYP	(0x33)
+#define ESR_EL2_EC_WATCHPT	(0x34)
+#define ESR_EL2_EC_WATCHPT_HYP	(0x35)
+#define ESR_EL2_EC_BKPT32	(0x38)
+#define ESR_EL2_EC_VECTOR32	(0x3A)
+#define ESR_EL2_EC_BRK64	(0x3C)
+
+#endif /* __ARM64_KVM_ARM_H__ */
-- 
1.8.1.4




From marc.zyngier at arm.com  Mon Apr  8 12:17:02 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon,  8 Apr 2013 17:17:02 +0100
Subject: [PATCH v3 00/32] Port of KVM to arm64
Message-ID: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>

This series contains the third version of KVM for arm64.

It depends on the following branches/series:
- git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch64.git soc-armv8-model
  Catalin's platform support branch for v8 models
- git://github.com/columbia/linux-kvm-arm.git kvm-arm-fixes
  mostly reworking the 32bit port to accomodate for arm64
- git://github.com/columbia/linux-kvm-arm.git kvm-arm-next
  adding perf support
- http://lists.infradead.org/pipermail/linux-arm-kernel/2013-April/161381.html
  reworking the whole init procedure for KVM/ARM
- http://lists.infradead.org/pipermail/linux-arm-kernel/2013-April/161395.html
  more 32bit rework

The code is unsurprisingly extremely similar to the KVM/arm code, and
a lot of it is actually shared with the 32bit version. Some of the
include files are duplicated though (I'm definitely willing to fix
that).

In terms of features:
- Support for 4k and 64k pages
- Support for 32bit and 64bit guests
- PSCI support for SMP booting

Testing has been done on both AEMv8 and Foundation models, with
various 32 and 64bit guests running a variety of distributions (OE,
Ubuntu and openSUSE for 64bit, Debian and Ubuntu on 32bit).

The patches are also available on the following branch:
git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git kvm-arm64/kvm

As we do not have a 64bit QEMU port, it has been tested using
kvmtools. Note that some of the changes have broken the userspace ABI
in v2, and you must update and rebuild your kvmtools (the previous
version won't work anymore):

git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git kvm-arm64/kvmtool

>From v2:
- Dropped the idmap code and use the new KVM/ARM boot protocol
- New KVM_CAP_ARM_EL1_32BIT capability to let userspace detect if EL1
  is 32bit capable
- Fixed a bug in arch/arm/entry.S, where EL0/EL1 breakpoint handling was
  mixed up (spotted by Catalin Marinas)
- Some sparse fixes (courtesy of Geoff Levand)
- Dropped the "shared" attribute from device mappings (spotted by Catalin)
- Add API documentation
- Add MAINTAINERS entry

>From v1:
- Rework of the world-switch to use common structure between host and
  guests (suggested by Christopher Covington)
- Some additional constants to make the EL1 fault injection clearer
  (suggested by Christopher Covington)
- Use of __u64 instead of "unsigned long" in the userspace API
  (suggested by Michael S. Tsirkin)
- Move the FP/SIMD registers into the "core" registers, dropping the
  specific accessors.
- Generic MPIDR implementation (suggested by Christopher Covington)
- Cleaner handling of the various host implementations

Marc Zyngier (32):
  arm64: add explicit symbols to ESR_EL1 decoding
  arm64: KVM: define HYP and Stage-2 translation page flags
  arm64: KVM: HYP mode idmap support
  arm64: KVM: EL2 register definitions
  arm64: KVM: system register definitions for 64bit guests
  arm64: KVM: Basic ESR_EL2 helpers and vcpu register access
  arm64: KVM: fault injection into a guest
  arm64: KVM: architecture specific MMU backend
  arm64: KVM: user space interface
  arm64: KVM: system register handling
  arm64: KVM: CPU specific system registers handling
  arm64: KVM: virtual CPU reset
  arm64: KVM: kvm_arch and kvm_vcpu_arch definitions
  arm64: KVM: MMIO access backend
  arm64: KVM: guest one-reg interface
  arm64: KVM: hypervisor initialization code
  arm64: KVM: HYP mode world switch implementation
  arm64: KVM: Exit handling
  arm64: KVM: Plug the VGIC
  arm64: KVM: Plug the arch timer
  arm64: KVM: PSCI implementation
  arm64: KVM: Build system integration
  arm64: KVM: define 32bit specific registers
  arm64: KVM: 32bit GP register access
  arm64: KVM: 32bit conditional execution emulation
  arm64: KVM: 32bit handling of coprocessor traps
  arm64: KVM: CPU specific 32bit coprocessor access
  arm64: KVM: 32bit specific register world switch
  arm64: KVM: 32bit guest fault injection
  arm64: KVM: enable initialization of a 32bit vcpu
  arm64: KVM: userspace API documentation
  arm64: KVM: MAINTAINERS update

 Documentation/virtual/kvm/api.txt       |   55 +-
 MAINTAINERS                             |    9 +
 arch/arm/kvm/arch_timer.c               |    1 +
 arch/arm64/Kconfig                      |    2 +
 arch/arm64/Makefile                     |    2 +-
 arch/arm64/include/asm/esr.h            |   55 ++
 arch/arm64/include/asm/kvm_arch_timer.h |   58 ++
 arch/arm64/include/asm/kvm_arm.h        |  243 ++++++++
 arch/arm64/include/asm/kvm_asm.h        |  104 ++++
 arch/arm64/include/asm/kvm_coproc.h     |   56 ++
 arch/arm64/include/asm/kvm_emulate.h    |  185 ++++++
 arch/arm64/include/asm/kvm_host.h       |  202 ++++++
 arch/arm64/include/asm/kvm_mmio.h       |   59 ++
 arch/arm64/include/asm/kvm_mmu.h        |  136 ++++
 arch/arm64/include/asm/kvm_psci.h       |   23 +
 arch/arm64/include/asm/kvm_vgic.h       |  156 +++++
 arch/arm64/include/asm/pgtable-hwdef.h  |   13 +
 arch/arm64/include/asm/pgtable.h        |   12 +
 arch/arm64/include/uapi/asm/kvm.h       |  168 +++++
 arch/arm64/kernel/asm-offsets.c         |   34 +
 arch/arm64/kernel/entry.S               |   53 +-
 arch/arm64/kernel/vmlinux.lds.S         |   16 +
 arch/arm64/kvm/Kconfig                  |   59 ++
 arch/arm64/kvm/Makefile                 |   19 +
 arch/arm64/kvm/emulate.c                |  154 +++++
 arch/arm64/kvm/guest.c                  |  260 ++++++++
 arch/arm64/kvm/handle_exit.c            |  124 ++++
 arch/arm64/kvm/hyp-init.S               |  112 ++++
 arch/arm64/kvm/hyp.S                    |  816 ++++++++++++++++++++++++
 arch/arm64/kvm/inject_fault.c           |  195 ++++++
 arch/arm64/kvm/regmap.c                 |  168 +++++
 arch/arm64/kvm/reset.c                  |   99 +++
 arch/arm64/kvm/sys_regs.c               | 1035 +++++++++++++++++++++++++++++++
 arch/arm64/kvm/sys_regs.h               |  138 +++++
 arch/arm64/kvm/sys_regs_generic_v8.c    |   95 +++
 include/uapi/linux/kvm.h                |    2 +
 36 files changed, 4872 insertions(+), 46 deletions(-)
 create mode 100644 arch/arm64/include/asm/esr.h
 create mode 100644 arch/arm64/include/asm/kvm_arch_timer.h
 create mode 100644 arch/arm64/include/asm/kvm_arm.h
 create mode 100644 arch/arm64/include/asm/kvm_asm.h
 create mode 100644 arch/arm64/include/asm/kvm_coproc.h
 create mode 100644 arch/arm64/include/asm/kvm_emulate.h
 create mode 100644 arch/arm64/include/asm/kvm_host.h
 create mode 100644 arch/arm64/include/asm/kvm_mmio.h
 create mode 100644 arch/arm64/include/asm/kvm_mmu.h
 create mode 100644 arch/arm64/include/asm/kvm_psci.h
 create mode 100644 arch/arm64/include/asm/kvm_vgic.h
 create mode 100644 arch/arm64/include/uapi/asm/kvm.h
 create mode 100644 arch/arm64/kvm/Kconfig
 create mode 100644 arch/arm64/kvm/Makefile
 create mode 100644 arch/arm64/kvm/emulate.c
 create mode 100644 arch/arm64/kvm/guest.c
 create mode 100644 arch/arm64/kvm/handle_exit.c
 create mode 100644 arch/arm64/kvm/hyp-init.S
 create mode 100644 arch/arm64/kvm/hyp.S
 create mode 100644 arch/arm64/kvm/inject_fault.c
 create mode 100644 arch/arm64/kvm/regmap.c
 create mode 100644 arch/arm64/kvm/reset.c
 create mode 100644 arch/arm64/kvm/sys_regs.c
 create mode 100644 arch/arm64/kvm/sys_regs.h
 create mode 100644 arch/arm64/kvm/sys_regs_generic_v8.c

-- 
1.8.1.4




From p.zabel at pengutronix.de  Mon Apr  8 12:17:18 2013
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Mon, 08 Apr 2013 18:17:18 +0200
Subject: [PATCH 0/5] i.MX53 TVE clock patches
In-Reply-To: <CAOMZO5CjC4HEvZo7rqdN1inAz_=xif=5aANLPhB9oF_mygJeGg@mail.gmail.com>
References: <1365432383-7787-1-git-send-email-p.zabel@pengutronix.de>
 <CAOMZO5CjC4HEvZo7rqdN1inAz_=xif=5aANLPhB9oF_mygJeGg@mail.gmail.com>
Message-ID: <1365437838.6626.7.camel@pizza.hi.pengutronix.de>

Hi Fabio,

Am Montag, den 08.04.2013, 12:26 -0300 schrieb Fabio Estevam:
> Hi Phiipp,
> 
> On Mon, Apr 8, 2013 at 11:46 AM, Philipp Zabel <p.zabel at pengutronix.de> wrote:
> > Hi,
> >
> > the first two are just cleanups, the following three patches are changes
> > to the i.MX53 clock tree that are necessary to use the TVEv2 module as
> > VGA output on the Freescale i.MX53-QSB or TQ MBa53 boards.
> 
> I would like to test this series on a mx53qsb.
>
> Is the TVE driver available in some git tree?

I have pushed the series for you at:

    git://git.pengutronix.de/git/pza/linux.git imx-ipu-tve/wip

regards
Philipp



From marc.zyngier at arm.com  Mon Apr  8 12:17:05 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon,  8 Apr 2013 17:17:05 +0100
Subject: [PATCH v3 03/32] arm64: KVM: HYP mode idmap support
In-Reply-To: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1365437854-30214-4-git-send-email-marc.zyngier@arm.com>

Add the necessary infrastructure for identity-mapped HYP page
tables. Idmap-ed code must be in the ".hyp.idmap.text" linker
section.

The rest of the HYP ends up in ".hyp.text".

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/kernel/vmlinux.lds.S | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
index 3fae2be..855d43d 100644
--- a/arch/arm64/kernel/vmlinux.lds.S
+++ b/arch/arm64/kernel/vmlinux.lds.S
@@ -17,6 +17,15 @@ ENTRY(stext)
 
 jiffies = jiffies_64;
 
+#define HYPERVISOR_TEXT					\
+	. = ALIGN(2048);				\
+	VMLINUX_SYMBOL(__hyp_idmap_text_start) = .;	\
+	*(.hyp.idmap.text)				\
+	VMLINUX_SYMBOL(__hyp_idmap_text_end) = .;	\
+	VMLINUX_SYMBOL(__hyp_text_start) = .;		\
+	*(.hyp.text)					\
+	VMLINUX_SYMBOL(__hyp_text_end) = .;
+
 SECTIONS
 {
 	/*
@@ -49,6 +58,7 @@ SECTIONS
 			TEXT_TEXT
 			SCHED_TEXT
 			LOCK_TEXT
+			HYPERVISOR_TEXT
 			*(.fixup)
 			*(.gnu.warning)
 		. = ALIGN(16);
@@ -124,3 +134,9 @@ SECTIONS
 	STABS_DEBUG
 	.comment 0 : { *(.comment) }
 }
+
+/*
+ * The HYP init code can't be more than a page long.
+ */
+ASSERT(((__hyp_idmap_text_start + PAGE_SIZE) >= __hyp_idmap_text_end),
+       "HYP init code too big")
-- 
1.8.1.4




From marc.zyngier at arm.com  Mon Apr  8 12:17:07 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon,  8 Apr 2013 17:17:07 +0100
Subject: [PATCH v3 05/32] arm64: KVM: system register definitions for 64bit
 guests
In-Reply-To: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1365437854-30214-6-git-send-email-marc.zyngier@arm.com>

Define the saved/restored registers for 64bit guests.

Reviewed-by: Christopher Covington <cov at codeaurora.org>
Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/include/asm/kvm_asm.h | 68 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 68 insertions(+)
 create mode 100644 arch/arm64/include/asm/kvm_asm.h

diff --git a/arch/arm64/include/asm/kvm_asm.h b/arch/arm64/include/asm/kvm_asm.h
new file mode 100644
index 0000000..591ac21
--- /dev/null
+++ b/arch/arm64/include/asm/kvm_asm.h
@@ -0,0 +1,68 @@
+/*
+ * Copyright (C) 2012,2013 - ARM Ltd
+ * Author: Marc Zyngier <marc.zyngier at arm.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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#ifndef __ARM_KVM_ASM_H__
+#define __ARM_KVM_ASM_H__
+
+/*
+ * 0 is reserved as an invalid value.
+ * Order *must* be kept in sync with the hyp switch code.
+ */
+#define	MPIDR_EL1	1	/* MultiProcessor Affinity Register */
+#define	CSSELR_EL1	2	/* Cache Size Selection Register */
+#define	SCTLR_EL1	3	/* System Control Register */
+#define	ACTLR_EL1	4	/* Auxilliary Control Register */
+#define	CPACR_EL1	5	/* Coprocessor Access Control */
+#define	TTBR0_EL1	6	/* Translation Table Base Register 0 */
+#define	TTBR1_EL1	7	/* Translation Table Base Register 1 */
+#define	TCR_EL1		8	/* Translation Control Register */
+#define	ESR_EL1		9	/* Exception Syndrome Register */
+#define	AFSR0_EL1	10	/* Auxilary Fault Status Register 0 */
+#define	AFSR1_EL1	11	/* Auxilary Fault Status Register 1 */
+#define	FAR_EL1		12	/* Fault Address Register */
+#define	MAIR_EL1	13	/* Memory Attribute Indirection Register */
+#define	VBAR_EL1	14	/* Vector Base Address Register */
+#define	CONTEXTIDR_EL1	15	/* Context ID Register */
+#define	TPIDR_EL0	16	/* Thread ID, User R/W */
+#define	TPIDRRO_EL0	17	/* Thread ID, User R/O */
+#define	TPIDR_EL1	18	/* Thread ID, Privileged */
+#define	AMAIR_EL1	19	/* Aux Memory Attribute Indirection Register */
+#define	CNTKCTL_EL1	20	/* Timer Control Register (EL1) */
+#define	NR_SYS_REGS	21
+
+#define ARM_EXCEPTION_IRQ	  0
+#define ARM_EXCEPTION_TRAP	  1
+
+#ifndef __ASSEMBLY__
+struct kvm;
+struct kvm_vcpu;
+
+extern char __kvm_hyp_init[];
+extern char __kvm_hyp_init_end[];
+
+extern char __kvm_hyp_vector[];
+
+extern char __kvm_hyp_code_start[];
+extern char __kvm_hyp_code_end[];
+
+extern void __kvm_flush_vm_context(void);
+extern void __kvm_tlb_flush_vmid_ipa(struct kvm *kvm, phys_addr_t ipa);
+
+extern int __kvm_vcpu_run(struct kvm_vcpu *vcpu);
+#endif
+
+#endif /* __ARM_KVM_ASM_H__ */
-- 
1.8.1.4




From marc.zyngier at arm.com  Mon Apr  8 12:17:04 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon,  8 Apr 2013 17:17:04 +0100
Subject: [PATCH v3 02/32] arm64: KVM: define HYP and Stage-2 translation page
 flags
In-Reply-To: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1365437854-30214-3-git-send-email-marc.zyngier@arm.com>

Add HYP and S2 page flags, for both normal and device memory.

Reviewed-by: Christopher Covington <cov at codeaurora.org>
Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/include/asm/pgtable-hwdef.h | 13 +++++++++++++
 arch/arm64/include/asm/pgtable.h       | 12 ++++++++++++
 2 files changed, 25 insertions(+)

diff --git a/arch/arm64/include/asm/pgtable-hwdef.h b/arch/arm64/include/asm/pgtable-hwdef.h
index 75fd13d..acb4ee5 100644
--- a/arch/arm64/include/asm/pgtable-hwdef.h
+++ b/arch/arm64/include/asm/pgtable-hwdef.h
@@ -35,6 +35,7 @@
 /*
  * Section
  */
+#define PMD_SECT_USER		(_AT(pteval_t, 1) << 6)		/* AP[1] */
 #define PMD_SECT_S		(_AT(pmdval_t, 3) << 8)
 #define PMD_SECT_AF		(_AT(pmdval_t, 1) << 10)
 #define PMD_SECT_NG		(_AT(pmdval_t, 1) << 11)
@@ -68,6 +69,18 @@
 #define PTE_ATTRINDX_MASK	(_AT(pteval_t, 7) << 2)
 
 /*
+ * 2nd stage PTE definitions
+ */
+#define PTE_S2_RDONLY		 (_AT(pteval_t, 1) << 6)   /* HAP[1]   */
+#define PTE_S2_RDWR		 (_AT(pteval_t, 2) << 6)   /* HAP[2:1] */
+
+/*
+ * EL2/HYP PTE/PMD definitions
+ */
+#define PMD_HYP			PMD_SECT_USER
+#define PTE_HYP			PTE_USER
+
+/*
  * 40-bit physical address supported.
  */
 #define PHYS_MASK_SHIFT		(40)
diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index e333a24..7c84ab4 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -76,6 +76,12 @@ extern pgprot_t pgprot_default;
 #define PAGE_KERNEL		_MOD_PROT(pgprot_default, PTE_PXN | PTE_UXN | PTE_DIRTY)
 #define PAGE_KERNEL_EXEC	_MOD_PROT(pgprot_default, PTE_UXN | PTE_DIRTY)
 
+#define PAGE_HYP		_MOD_PROT(pgprot_default, PTE_HYP)
+#define PAGE_HYP_DEVICE		_MOD_PROT(__pgprot(PROT_DEVICE_nGnRE), PTE_HYP)
+
+#define PAGE_S2			_MOD_PROT(pgprot_default, PTE_USER | PTE_S2_RDONLY)
+#define PAGE_S2_DEVICE		_MOD_PROT(__pgprot(PROT_DEVICE_nGnRE), PTE_USER | PTE_S2_RDWR)
+
 #define __PAGE_NONE		__pgprot(((_PAGE_DEFAULT) & ~PTE_TYPE_MASK) | PTE_PROT_NONE)
 #define __PAGE_SHARED		__pgprot(_PAGE_DEFAULT | PTE_USER | PTE_NG | PTE_PXN | PTE_UXN)
 #define __PAGE_SHARED_EXEC	__pgprot(_PAGE_DEFAULT | PTE_USER | PTE_NG | PTE_PXN)
@@ -197,6 +203,12 @@ extern pgprot_t phys_mem_access_prot(struct file *file, unsigned long pfn,
 
 #define pmd_bad(pmd)		(!(pmd_val(pmd) & 2))
 
+#define pmd_table(pmd)		((pmd_val(pmd) & PMD_TYPE_MASK) == \
+				 PMD_TYPE_TABLE)
+#define pmd_sect(pmd)		((pmd_val(pmd) & PMD_TYPE_MASK) == \
+				 PMD_TYPE_SECT)
+
+
 static inline void set_pmd(pmd_t *pmdp, pmd_t pmd)
 {
 	*pmdp = pmd;
-- 
1.8.1.4




From marc.zyngier at arm.com  Mon Apr  8 12:17:08 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon,  8 Apr 2013 17:17:08 +0100
Subject: [PATCH v3 06/32] arm64: KVM: Basic ESR_EL2 helpers and vcpu register
 access
In-Reply-To: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1365437854-30214-7-git-send-email-marc.zyngier@arm.com>

Implements helpers for dealing with the EL2 syndrome register as
well as accessing the vcpu registers.

Reviewed-by: Christopher Covington <cov at codeaurora.org>
Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/include/asm/kvm_emulate.h | 163 +++++++++++++++++++++++++++++++++++
 1 file changed, 163 insertions(+)
 create mode 100644 arch/arm64/include/asm/kvm_emulate.h

diff --git a/arch/arm64/include/asm/kvm_emulate.h b/arch/arm64/include/asm/kvm_emulate.h
new file mode 100644
index 0000000..2dcfa74
--- /dev/null
+++ b/arch/arm64/include/asm/kvm_emulate.h
@@ -0,0 +1,163 @@
+/*
+ * Copyright (C) 2012,2013 - ARM Ltd
+ * Author: Marc Zyngier <marc.zyngier at arm.com>
+ *
+ * Derived from arch/arm/include/kvm_emulate.h
+ * Copyright (C) 2012 - Virtual Open Systems and Columbia University
+ * Author: Christoffer Dall <c.dall at virtualopensystems.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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#ifndef __ARM64_KVM_EMULATE_H__
+#define __ARM64_KVM_EMULATE_H__
+
+#include <linux/kvm_host.h>
+#include <asm/kvm_asm.h>
+#include <asm/kvm_arm.h>
+#include <asm/kvm_mmio.h>
+#include <asm/ptrace.h>
+
+void kvm_inject_undefined(struct kvm_vcpu *vcpu);
+void kvm_inject_dabt(struct kvm_vcpu *vcpu, unsigned long addr);
+void kvm_inject_pabt(struct kvm_vcpu *vcpu, unsigned long addr);
+
+static inline unsigned long *vcpu_pc(const struct kvm_vcpu *vcpu)
+{
+	return (unsigned long *)&vcpu_gp_regs(vcpu)->regs.pc;
+}
+
+static inline unsigned long *vcpu_elr_el1(const struct kvm_vcpu *vcpu)
+{
+	return (unsigned long *)&vcpu_gp_regs(vcpu)->elr_el1;
+}
+
+static inline unsigned long *vcpu_cpsr(const struct kvm_vcpu *vcpu)
+{
+	return (unsigned long *)&vcpu_gp_regs(vcpu)->regs.pstate;
+}
+
+static inline bool vcpu_mode_is_32bit(const struct kvm_vcpu *vcpu)
+{
+	return false;	/* 32bit? Bahhh... */
+}
+
+static inline bool kvm_condition_valid(const struct kvm_vcpu *vcpu)
+{
+	return true;	/* No conditionals on arm64 */
+}
+
+static inline void kvm_skip_instr(struct kvm_vcpu *vcpu, bool is_wide_instr)
+{
+	*vcpu_pc(vcpu) += 4;
+}
+
+static inline void vcpu_set_thumb(struct kvm_vcpu *vcpu)
+{
+}
+
+static inline unsigned long *vcpu_reg(const struct kvm_vcpu *vcpu, u8 reg_num)
+{
+	return (unsigned long *)&vcpu_gp_regs(vcpu)->regs.regs[reg_num];
+}
+
+/* Get vcpu SPSR for current mode */
+static inline unsigned long *vcpu_spsr(const struct kvm_vcpu *vcpu)
+{
+	return (unsigned long *)&vcpu_gp_regs(vcpu)->spsr[KVM_SPSR_EL1];
+}
+
+static inline bool kvm_vcpu_reg_is_pc(const struct kvm_vcpu *vcpu, int reg)
+{
+	return false;
+}
+
+static inline bool vcpu_mode_priv(const struct kvm_vcpu *vcpu)
+{
+	u32 mode = *vcpu_cpsr(vcpu) & PSR_MODE_MASK;
+
+	return mode != PSR_MODE_EL0t;
+}
+
+static inline u32 kvm_vcpu_get_hsr(const struct kvm_vcpu *vcpu)
+{
+	return vcpu->arch.fault.esr_el2;
+}
+
+static inline unsigned long kvm_vcpu_get_hfar(const struct kvm_vcpu *vcpu)
+{
+	return vcpu->arch.fault.far_el2;
+}
+
+static inline phys_addr_t kvm_vcpu_get_fault_ipa(const struct kvm_vcpu *vcpu)
+{
+	return ((phys_addr_t)vcpu->arch.fault.hpfar_el2 & HPFAR_MASK) << 8;
+}
+
+static inline bool kvm_vcpu_dabt_isvalid(const struct kvm_vcpu *vcpu)
+{
+	return !!(kvm_vcpu_get_hsr(vcpu) & ESR_EL2_ISV);
+}
+
+static inline bool kvm_vcpu_dabt_iswrite(const struct kvm_vcpu *vcpu)
+{
+	return !!(kvm_vcpu_get_hsr(vcpu) & ESR_EL2_WNR);
+}
+
+static inline bool kvm_vcpu_dabt_issext(const struct kvm_vcpu *vcpu)
+{
+	return !!(kvm_vcpu_get_hsr(vcpu) & ESR_EL2_SSE);
+}
+
+static inline int kvm_vcpu_dabt_get_rd(const struct kvm_vcpu *vcpu)
+{
+	return (kvm_vcpu_get_hsr(vcpu) & ESR_EL2_SRT_MASK) >> ESR_EL2_SRT_SHIFT;
+}
+
+static inline bool kvm_vcpu_dabt_isextabt(const struct kvm_vcpu *vcpu)
+{
+	return !!(kvm_vcpu_get_hsr(vcpu) & ESR_EL2_EA);
+}
+
+static inline bool kvm_vcpu_dabt_iss1tw(const struct kvm_vcpu *vcpu)
+{
+	return !!(kvm_vcpu_get_hsr(vcpu) & ESR_EL2_S1PTW);
+}
+
+static inline int kvm_vcpu_dabt_get_as(const struct kvm_vcpu *vcpu)
+{
+	return 1 << ((kvm_vcpu_get_hsr(vcpu) & ESR_EL2_SAS) >> ESR_EL2_SAS_SHIFT);
+}
+
+/* This one is not specific to Data Abort */
+static inline bool kvm_vcpu_trap_il_is32bit(const struct kvm_vcpu *vcpu)
+{
+	return !!(kvm_vcpu_get_hsr(vcpu) & ESR_EL2_IL);
+}
+
+static inline u8 kvm_vcpu_trap_get_class(const struct kvm_vcpu *vcpu)
+{
+	return kvm_vcpu_get_hsr(vcpu) >> ESR_EL2_EC_SHIFT;
+}
+
+static inline bool kvm_vcpu_trap_is_iabt(const struct kvm_vcpu *vcpu)
+{
+	return kvm_vcpu_trap_get_class(vcpu) == ESR_EL2_EC_IABT;
+}
+
+static inline u8 kvm_vcpu_trap_get_fault(const struct kvm_vcpu *vcpu)
+{
+	return kvm_vcpu_get_hsr(vcpu) & ESR_EL2_FSC_TYPE;
+}
+
+#endif /* __ARM64_KVM_EMULATE_H__ */
-- 
1.8.1.4




From marc.zyngier at arm.com  Mon Apr  8 12:17:03 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon,  8 Apr 2013 17:17:03 +0100
Subject: [PATCH v3 01/32] arm64: add explicit symbols to ESR_EL1 decoding
In-Reply-To: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1365437854-30214-2-git-send-email-marc.zyngier@arm.com>

The ESR_EL1 decoding process is a bit cryptic, and KVM has also
a need for the same constants.

Add a new esr.h file containing the appropriate exception classes
constants, and change entry.S to use it. Fix a small bug in the
EL1 breakpoint check while we're at it.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
Cc: Catalin Marinas <catalin.marinas at arm.com>
Cc: Will Deacon <will.deacon at arm.com>
---
 arch/arm64/include/asm/esr.h | 55 ++++++++++++++++++++++++++++++++++++++++++++
 arch/arm64/kernel/entry.S    | 53 +++++++++++++++++++++---------------------
 2 files changed, 82 insertions(+), 26 deletions(-)
 create mode 100644 arch/arm64/include/asm/esr.h

diff --git a/arch/arm64/include/asm/esr.h b/arch/arm64/include/asm/esr.h
new file mode 100644
index 0000000..7883412
--- /dev/null
+++ b/arch/arm64/include/asm/esr.h
@@ -0,0 +1,55 @@
+/*
+ * Copyright (C) 2013 - ARM Ltd
+ * Author: Marc Zyngier <marc.zyngier at arm.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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#ifndef __ASM_ESR_H
+#define __ASM_ESR_H
+
+#define ESR_EL1_EC_SHIFT	(26)
+#define ESR_EL1_IL		(1U << 25)
+
+#define ESR_EL1_EC_UNKNOWN	(0x00)
+#define ESR_EL1_EC_WFI		(0x01)
+#define ESR_EL1_EC_CP15_32	(0x03)
+#define ESR_EL1_EC_CP15_64	(0x04)
+#define ESR_EL1_EC_CP14_MR	(0x05)
+#define ESR_EL1_EC_CP14_LS	(0x06)
+#define ESR_EL1_EC_FP_ASIMD	(0x07)
+#define ESR_EL1_EC_CP10_ID	(0x08)
+#define ESR_EL1_EC_CP14_64	(0x0C)
+#define ESR_EL1_EC_ILL_ISS	(0x0E)
+#define ESR_EL1_EC_SVC32	(0x11)
+#define ESR_EL1_EC_SVC64	(0x15)
+#define ESR_EL1_EC_SYS64	(0x18)
+#define ESR_EL1_EC_IABT_EL0	(0x20)
+#define ESR_EL1_EC_IABT_EL1	(0x21)
+#define ESR_EL1_EC_PC_ALIGN	(0x22)
+#define ESR_EL1_EC_DABT_EL0	(0x24)
+#define ESR_EL1_EC_DABT_EL1	(0x25)
+#define ESR_EL1_EC_SP_ALIGN	(0x26)
+#define ESR_EL1_EC_FP_EXC32	(0x28)
+#define ESR_EL1_EC_FP_EXC64	(0x2C)
+#define ESR_EL1_EC_SERRROR	(0x2F)
+#define ESR_EL1_EC_BREAKPT_EL0	(0x30)
+#define ESR_EL1_EC_BREAKPT_EL1	(0x31)
+#define ESR_EL1_EC_SOFTSTP_EL0	(0x32)
+#define ESR_EL1_EC_SOFTSTP_EL1	(0x33)
+#define ESR_EL1_EC_WATCHPT_EL0	(0x34)
+#define ESR_EL1_EC_WATCHPT_EL1	(0x35)
+#define ESR_EL1_EC_BKPT32	(0x38)
+#define ESR_EL1_EC_BRK64	(0x3C)
+
+#endif /* __ASM_ESR_H */
diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
index 514d609..c7e0470 100644
--- a/arch/arm64/kernel/entry.S
+++ b/arch/arm64/kernel/entry.S
@@ -24,6 +24,7 @@
 #include <asm/assembler.h>
 #include <asm/asm-offsets.h>
 #include <asm/errno.h>
+#include <asm/esr.h>
 #include <asm/thread_info.h>
 #include <asm/unistd.h>
 #include <asm/unistd32.h>
@@ -239,18 +240,18 @@ ENDPROC(el1_error_invalid)
 el1_sync:
 	kernel_entry 1
 	mrs	x1, esr_el1			// read the syndrome register
-	lsr	x24, x1, #26			// exception class
-	cmp	x24, #0x25			// data abort in EL1
+	lsr	x24, x1, #ESR_EL1_EC_SHIFT	// exception class
+	cmp	x24, #ESR_EL1_EC_DABT_EL1	// data abort in EL1
 	b.eq	el1_da
-	cmp	x24, #0x18			// configurable trap
+	cmp	x24, #ESR_EL1_EC_SYS64		// configurable trap
 	b.eq	el1_undef
-	cmp	x24, #0x26			// stack alignment exception
+	cmp	x24, #ESR_EL1_EC_SP_ALIGN	// stack alignment exception
 	b.eq	el1_sp_pc
-	cmp	x24, #0x22			// pc alignment exception
+	cmp	x24, #ESR_EL1_EC_PC_ALIGN	// pc alignment exception
 	b.eq	el1_sp_pc
-	cmp	x24, #0x00			// unknown exception in EL1
+	cmp	x24, #ESR_EL1_EC_UNKNOWN	// unknown exception in EL1
 	b.eq	el1_undef
-	cmp	x24, #0x30			// debug exception in EL1
+	cmp	x24, #ESR_EL1_EC_BREAKPT_EL1	// debug exception in EL1
 	b.ge	el1_dbg
 	b	el1_inv
 el1_da:
@@ -346,27 +347,27 @@ el1_preempt:
 el0_sync:
 	kernel_entry 0
 	mrs	x25, esr_el1			// read the syndrome register
-	lsr	x24, x25, #26			// exception class
-	cmp	x24, #0x15			// SVC in 64-bit state
+	lsr	x24, x25, #ESR_EL1_EC_SHIFT	// exception class
+	cmp	x24, #ESR_EL1_EC_SVC64		// SVC in 64-bit state
 	b.eq	el0_svc
 	adr	lr, ret_from_exception
-	cmp	x24, #0x24			// data abort in EL0
+	cmp	x24, #ESR_EL1_EC_DABT_EL0	// data abort in EL0
 	b.eq	el0_da
-	cmp	x24, #0x20			// instruction abort in EL0
+	cmp	x24, #ESR_EL1_EC_IABT_EL0	// instruction abort in EL0
 	b.eq	el0_ia
-	cmp	x24, #0x07			// FP/ASIMD access
+	cmp	x24, #ESR_EL1_EC_FP_ASIMD	// FP/ASIMD access
 	b.eq	el0_fpsimd_acc
-	cmp	x24, #0x2c			// FP/ASIMD exception
+	cmp	x24, #ESR_EL1_EC_FP_EXC64	// FP/ASIMD exception
 	b.eq	el0_fpsimd_exc
-	cmp	x24, #0x18			// configurable trap
+	cmp	x24, #ESR_EL1_EC_SYS64		// configurable trap
 	b.eq	el0_undef
-	cmp	x24, #0x26			// stack alignment exception
+	cmp	x24, #ESR_EL1_EC_SP_ALIGN	// stack alignment exception
 	b.eq	el0_sp_pc
-	cmp	x24, #0x22			// pc alignment exception
+	cmp	x24, #ESR_EL1_EC_PC_ALIGN	// pc alignment exception
 	b.eq	el0_sp_pc
-	cmp	x24, #0x00			// unknown exception in EL0
+	cmp	x24, #ESR_EL1_EC_UNKNOWN	// unknown exception in EL0
 	b.eq	el0_undef
-	cmp	x24, #0x30			// debug exception in EL0
+	cmp	x24, #ESR_EL1_EC_BREAKPT_EL0	// debug exception in EL0
 	b.ge	el0_dbg
 	b	el0_inv
 
@@ -375,21 +376,21 @@ el0_sync:
 el0_sync_compat:
 	kernel_entry 0, 32
 	mrs	x25, esr_el1			// read the syndrome register
-	lsr	x24, x25, #26			// exception class
-	cmp	x24, #0x11			// SVC in 32-bit state
+	lsr	x24, x25, #ESR_EL1_EC_SHIFT	// exception class
+	cmp	x24, #ESR_EL1_EC_SVC32		// SVC in 32-bit state
 	b.eq	el0_svc_compat
 	adr	lr, ret_from_exception
-	cmp	x24, #0x24			// data abort in EL0
+	cmp	x24, #ESR_EL1_EC_DABT_EL0	// data abort in EL0
 	b.eq	el0_da
-	cmp	x24, #0x20			// instruction abort in EL0
+	cmp	x24, #ESR_EL1_EC_IABT_EL0	// instruction abort in EL0
 	b.eq	el0_ia
-	cmp	x24, #0x07			// FP/ASIMD access
+	cmp	x24, #ESR_EL1_EC_FP_ASIMD	// FP/ASIMD access
 	b.eq	el0_fpsimd_acc
-	cmp	x24, #0x28			// FP/ASIMD exception
+	cmp	x24, #ESR_EL1_EC_FP_EXC32	// FP/ASIMD exception
 	b.eq	el0_fpsimd_exc
-	cmp	x24, #0x00			// unknown exception in EL0
+	cmp	x24, #ESR_EL1_EC_UNKNOWN	// unknown exception in EL0
 	b.eq	el0_undef
-	cmp	x24, #0x30			// debug exception in EL0
+	cmp	x24, #ESR_EL1_EC_BREAKPT_EL0	// debug exception in EL0
 	b.ge	el0_dbg
 	b	el0_inv
 el0_svc_compat:
-- 
1.8.1.4




From arnd at arndb.de  Mon Apr  8 12:17:41 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 8 Apr 2013 18:17:41 +0200
Subject: [PATCH 1/5] ARM: ux500: Move DMA40 platform data includes file
 out to include/
In-Reply-To: <1365434591-21569-1-git-send-email-lee.jones@linaro.org>
References: <1365434591-21569-1-git-send-email-lee.jones@linaro.org>
Message-ID: <201304081817.42031.arnd@arndb.de>

On Monday 08 April 2013, Lee Jones wrote:
> The pin names for DB8500 based platforms need to be moved out of
> ux500 platform data and into the new proper location in include/
> linux/platform_data/. This way we an reference them from other
> external locations, such as the main DMA50 driver(s).
> 
> Signed-off-by: Lee Jones <lee.jones at linaro.org>

Hmm, not sure about this one. The slave numbers are not really platform_data
and I think they should not be exposed to drivers. It makes sense to
keep the numbers for the memcpy channels in the driver itself as they
are hardwired in the driver, but the slave channels should stay in the
platform I think.

	Arnd


From marc.zyngier at arm.com  Mon Apr  8 12:17:30 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon,  8 Apr 2013 17:17:30 +0100
Subject: [PATCH v3 28/32] arm64: KVM: 32bit specific register world switch
In-Reply-To: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1365437854-30214-29-git-send-email-marc.zyngier@arm.com>

Allow registers specific to 32bit guests to be saved/restored
during the world switch.

Reviewed-by: Christopher Covington <cov at codeaurora.org>
Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/kvm/hyp.S | 70 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 70 insertions(+)

diff --git a/arch/arm64/kvm/hyp.S b/arch/arm64/kvm/hyp.S
index 25da0b5..bf305c1 100644
--- a/arch/arm64/kvm/hyp.S
+++ b/arch/arm64/kvm/hyp.S
@@ -266,6 +266,74 @@ __kvm_hyp_code_start:
 	msr	cntkctl_el1,	x23
 .endm
 
+.macro skip_32bit_state tmp, target
+	// Skip 32bit state if not needed
+	mrs	\tmp, hcr_el2
+	tbnz	\tmp, #HCR_RW_SHIFT, \target
+.endm
+
+.macro skip_tee_state tmp, target
+	// Skip ThumbEE state if not needed
+	mrs	\tmp, id_pfr0_el1
+	tbz	\tmp, #12, \target
+.endm
+
+.macro save_guest_32bit_state
+	skip_32bit_state x3, 1f
+
+	add	x3, x2, #CPU_SPSR_OFFSET(KVM_SPSR_ABT)
+	mrs	x4, spsr_abt
+	mrs	x5, spsr_und
+	mrs	x6, spsr_irq
+	mrs	x7, spsr_fiq
+	stp	x4, x5, [x3]
+	stp	x6, x7, [x3, #16]
+
+	add	x3, x2, #CPU_SYSREG_OFFSET(DACR32_EL2)
+	mrs	x4, dacr32_el2
+	mrs	x5, ifsr32_el2
+	mrs	x6, fpexc32_el2
+	mrs	x7, dbgvcr32_el2
+	stp	x4, x5, [x3]
+	stp	x6, x7, [x3, #16]
+
+	skip_tee_state x8, 1f
+
+	add	x3, x2, #CPU_SYSREG_OFFSET(TEECR32_EL1)
+	mrs	x4, teecr32_el1
+	mrs	x5, teehbr32_el1
+	stp	x4, x5, [x3]
+1:
+.endm
+
+.macro restore_guest_32bit_state
+	skip_32bit_state x3, 1f
+
+	add	x3, x2, #CPU_SPSR_OFFSET(KVM_SPSR_ABT)
+	ldp	x4, x5, [x3]
+	ldp	x6, x7, [x3, #16]
+	msr	spsr_abt, x4
+	msr	spsr_und, x5
+	msr	spsr_irq, x6
+	msr	spsr_fiq, x7
+
+	add	x3, x2, #CPU_SYSREG_OFFSET(DACR32_EL2)
+	ldp	x4, x5, [x3]
+	ldp	x6, x7, [x3, #16]
+	msr	dacr32_el2, x4
+	msr	ifsr32_el2, x5
+	msr	fpexc32_el2, x6
+	msr	dbgvcr32_el2, x7
+
+	skip_tee_state x8, 1f
+
+	add	x3, x2, #CPU_SYSREG_OFFSET(TEECR32_EL1)
+	ldp	x4, x5, [x3]
+	msr	teecr32_el1, x4
+	msr	teehbr32_el1, x5
+1:
+.endm
+
 .macro activate_traps
 	ldr	x2, [x0, #VCPU_IRQ_LINES]
 	ldr	x1, [x0, #VCPU_HCR_EL2]
@@ -494,6 +562,7 @@ ENTRY(__kvm_vcpu_run)
 
 	bl __restore_sysregs
 	bl __restore_fpsimd
+	restore_guest_32bit_state
 	restore_guest_regs
 
 	// That's it, no more messing around.
@@ -510,6 +579,7 @@ __kvm_vcpu_return:
 	save_guest_regs
 	bl __save_fpsimd
 	bl __save_sysregs
+	save_guest_32bit_state
 
 	save_timer_state
 	save_vgic_state
-- 
1.8.1.4




From marc.zyngier at arm.com  Mon Apr  8 12:17:34 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon,  8 Apr 2013 17:17:34 +0100
Subject: [PATCH v3 32/32] arm64: KVM: MAINTAINERS update
In-Reply-To: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1365437854-30214-33-git-send-email-marc.zyngier@arm.com>

Elect myself as the KVM/arm64 maintainer.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 MAINTAINERS | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 836a618..c6e0170 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4628,6 +4628,15 @@ F:	arch/arm/include/uapi/asm/kvm*
 F:	arch/arm/include/asm/kvm*
 F:	arch/arm/kvm/
 
+KERNEL VIRTUAL MACHINE FOR ARM64 (KVM/arm64)
+M:	Marc Zyngier <marc.zyngier at arm.com>
+L:	linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
+L:	kvmarm at lists.cs.columbia.edu
+S:	Maintained
+F:	arch/arm64/include/uapi/asm/kvm*
+F:	arch/arm64/include/asm/kvm*
+F:	arch/arm64/kvm/
+
 KEXEC
 M:	Eric Biederman <ebiederm at xmission.com>
 W:	http://kernel.org/pub/linux/utils/kernel/kexec/
-- 
1.8.1.4




From marc.zyngier at arm.com  Mon Apr  8 12:17:32 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon,  8 Apr 2013 17:17:32 +0100
Subject: [PATCH v3 30/32] arm64: KVM: enable initialization of a 32bit vcpu
In-Reply-To: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1365437854-30214-31-git-send-email-marc.zyngier@arm.com>

Wire the init of a 32bit vcpu by allowing 32bit modes in pstate,
and providing sensible defaults out of reset state.

This feature is of course conditioned by the presence of 32bit
capability on the physical CPU, and is checked by the KVM_CAP_ARM_EL1_32BIT
capability.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/include/asm/kvm_host.h |  2 +-
 arch/arm64/include/uapi/asm/kvm.h |  1 +
 arch/arm64/kvm/guest.c            |  6 ++++++
 arch/arm64/kvm/reset.c            | 25 ++++++++++++++++++++++++-
 include/uapi/linux/kvm.h          |  1 +
 5 files changed, 33 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index d44064d..c3ec107 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -34,7 +34,7 @@
 #include <asm/kvm_vgic.h>
 #include <asm/kvm_arch_timer.h>
 
-#define KVM_VCPU_MAX_FEATURES 1
+#define KVM_VCPU_MAX_FEATURES 2
 
 /* We don't currently support large pages. */
 #define KVM_HPAGE_GFN_SHIFT(x)	0
diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
index 5b1110c..5031f42 100644
--- a/arch/arm64/include/uapi/asm/kvm.h
+++ b/arch/arm64/include/uapi/asm/kvm.h
@@ -75,6 +75,7 @@ struct kvm_regs {
 #define KVM_VGIC_V2_CPU_SIZE		0x2000
 
 #define KVM_ARM_VCPU_POWER_OFF		0 /* CPU is started in OFF state */
+#define KVM_ARM_VCPU_EL1_32BIT		1 /* CPU running a 32bit VM */
 
 struct kvm_vcpu_init {
 	__u32 target;
diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
index 47d3729..74ef7d5 100644
--- a/arch/arm64/kvm/guest.c
+++ b/arch/arm64/kvm/guest.c
@@ -93,6 +93,12 @@ static int set_core_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
 	if (off == KVM_REG_ARM_CORE_REG(regs.pstate)) {
 		unsigned long mode = (*(unsigned long *)valp) & COMPAT_PSR_MODE_MASK;
 		switch (mode) {
+		case COMPAT_PSR_MODE_USR:
+		case COMPAT_PSR_MODE_FIQ:
+		case COMPAT_PSR_MODE_IRQ:
+		case COMPAT_PSR_MODE_SVC:
+		case COMPAT_PSR_MODE_ABT:
+		case COMPAT_PSR_MODE_UND:
 		case PSR_MODE_EL0t:
 		case PSR_MODE_EL1t:
 		case PSR_MODE_EL1h:
diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
index bc33e76..a282d35 100644
--- a/arch/arm64/kvm/reset.c
+++ b/arch/arm64/kvm/reset.c
@@ -35,11 +35,27 @@ static struct kvm_regs default_regs_reset = {
 	.regs.pstate = PSR_MODE_EL1h | PSR_A_BIT | PSR_I_BIT | PSR_F_BIT,
 };
 
+static struct kvm_regs default_regs_reset32 = {
+	.regs.pstate = (COMPAT_PSR_MODE_SVC | COMPAT_PSR_A_BIT |
+			COMPAT_PSR_I_BIT | COMPAT_PSR_F_BIT),
+};
+
+static bool cpu_has_32bit_el1(void)
+{
+	u64 pfr0;
+
+	pfr0 = read_cpuid(ID_AA64PFR0_EL1);
+	return !!(pfr0 & 0x20);
+}
+
 int kvm_arch_dev_ioctl_check_extention(long ext)
 {
 	int r;
 
 	switch (ext) {
+	case KVM_CAP_ARM_EL1_32BIT:
+		r = cpu_has_32bit_el1();
+		break;
 	default:
 		r = 0;
 	}
@@ -62,7 +78,14 @@ int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
 
 	switch (vcpu->arch.target) {
 	default:
-		cpu_reset = &default_regs_reset;
+		if (test_bit(KVM_ARM_VCPU_EL1_32BIT, vcpu->arch.features)) {
+			if (!cpu_has_32bit_el1())
+				return -EINVAL;
+			cpu_reset = &default_regs_reset32;
+			vcpu->arch.hcr_el2 &= ~HCR_RW;
+		} else {
+			cpu_reset = &default_regs_reset;
+		}
 		break;
 	}
 
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 2bf42b0..ce05763 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -665,6 +665,7 @@ struct kvm_ppc_smmu_info {
 #define KVM_CAP_PPC_EPR 86
 #define KVM_CAP_ARM_PSCI 87
 #define KVM_CAP_ARM_SET_DEVICE_ADDR 88
+#define KVM_CAP_ARM_EL1_32BIT 89
 
 #ifdef KVM_CAP_IRQ_ROUTING
 
-- 
1.8.1.4




From marc.zyngier at arm.com  Mon Apr  8 12:17:31 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon,  8 Apr 2013 17:17:31 +0100
Subject: [PATCH v3 29/32] arm64: KVM: 32bit guest fault injection
In-Reply-To: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1365437854-30214-30-git-send-email-marc.zyngier@arm.com>

Add fault injection capability for 32bit guests.

Reviewed-by: Christopher Covington <cov at codeaurora.org>
Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/kvm/inject_fault.c | 79 ++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 78 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/kvm/inject_fault.c b/arch/arm64/kvm/inject_fault.c
index 2ff3b78..083cfd5 100644
--- a/arch/arm64/kvm/inject_fault.c
+++ b/arch/arm64/kvm/inject_fault.c
@@ -1,5 +1,5 @@
 /*
- * Fault injection for 64bit guests.
+ * Fault injection for both 32 and 64bit guests.
  *
  * Copyright (C) 2012,2013 - ARM Ltd
  * Author: Marc Zyngier <marc.zyngier at arm.com>
@@ -25,6 +25,74 @@
 #include <asm/kvm_emulate.h>
 #include <asm/esr.h>
 
+static void prepare_fault32(struct kvm_vcpu *vcpu, u32 mode, u32 vect_offset)
+{
+	unsigned long cpsr;
+	unsigned long new_spsr_value = *vcpu_cpsr(vcpu);
+	bool is_thumb = (new_spsr_value & COMPAT_PSR_T_BIT);
+	u32 return_offset = (is_thumb) ? 4 : 0;
+	u32 sctlr = vcpu_cp15(vcpu, c1_SCTLR);
+
+	cpsr = mode | COMPAT_PSR_I_BIT;
+
+	if (sctlr & (1 << 30))
+		cpsr |= COMPAT_PSR_T_BIT;
+	if (sctlr & (1 << 25))
+		cpsr |= COMPAT_PSR_E_BIT;
+
+	*vcpu_cpsr(vcpu) = cpsr;
+
+	/* Note: These now point to the banked copies */
+	*vcpu_spsr(vcpu) = new_spsr_value;
+	*vcpu_reg(vcpu, 14) = *vcpu_pc(vcpu) + return_offset;
+
+	/* Branch to exception vector */
+	if (sctlr & (1 << 13))
+		vect_offset += 0xffff0000;
+	else /* always have security exceptions */
+		vect_offset += vcpu_cp15(vcpu, c12_VBAR);
+
+	*vcpu_pc(vcpu) = vect_offset;
+}
+
+static void inject_undef32(struct kvm_vcpu *vcpu)
+{
+	prepare_fault32(vcpu, COMPAT_PSR_MODE_UND, 4);
+}
+
+/*
+ * Modelled after TakeDataAbortException() and TakePrefetchAbortException
+ * pseudocode.
+ */
+static void inject_abt32(struct kvm_vcpu *vcpu, bool is_pabt,
+			 unsigned long addr)
+{
+	u32 vect_offset;
+	u32 *far, *fsr;
+	bool is_lpae;
+
+	if (is_pabt) {
+		vect_offset = 12;
+		far = &vcpu_cp15(vcpu, c6_IFAR);
+		fsr = &vcpu_cp15(vcpu, c5_IFSR);
+	} else { /* !iabt */
+		vect_offset = 16;
+		far = &vcpu_cp15(vcpu, c6_DFAR);
+		fsr = &vcpu_cp15(vcpu, c5_DFSR);
+	}
+
+	prepare_fault32(vcpu, COMPAT_PSR_MODE_ABT | COMPAT_PSR_A_BIT, vect_offset);
+
+	*far = addr;
+
+	/* Give the guest an IMPLEMENTATION DEFINED exception */
+	is_lpae = (vcpu_cp15(vcpu, c2_TTBCR) >> 31);
+	if (is_lpae)
+		*fsr = 1 << 9 | 0x34;
+	else
+		*fsr = 0x14;
+}
+
 static void inject_abt64(struct kvm_vcpu *vcpu, bool is_iabt, unsigned long addr)
 {
 	unsigned long cpsr = *vcpu_cpsr(vcpu);
@@ -90,6 +158,9 @@ static void inject_undef64(struct kvm_vcpu *vcpu)
  */
 void kvm_inject_dabt(struct kvm_vcpu *vcpu, unsigned long addr)
 {
+	if (!(vcpu->arch.hcr_el2 & HCR_RW))
+		inject_abt32(vcpu, false, addr);
+
 	inject_abt64(vcpu, false, addr);
 }
 
@@ -103,6 +174,9 @@ void kvm_inject_dabt(struct kvm_vcpu *vcpu, unsigned long addr)
  */
 void kvm_inject_pabt(struct kvm_vcpu *vcpu, unsigned long addr)
 {
+	if (!(vcpu->arch.hcr_el2 & HCR_RW))
+		inject_abt32(vcpu, true, addr);
+
 	inject_abt64(vcpu, true, addr);
 }
 
@@ -114,5 +188,8 @@ void kvm_inject_pabt(struct kvm_vcpu *vcpu, unsigned long addr)
  */
 void kvm_inject_undefined(struct kvm_vcpu *vcpu)
 {
+	if (!(vcpu->arch.hcr_el2 & HCR_RW))
+		inject_undef32(vcpu);
+
 	inject_undef64(vcpu);
 }
-- 
1.8.1.4




From marc.zyngier at arm.com  Mon Apr  8 12:17:29 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon,  8 Apr 2013 17:17:29 +0100
Subject: [PATCH v3 27/32] arm64: KVM: CPU specific 32bit coprocessor access
In-Reply-To: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1365437854-30214-28-git-send-email-marc.zyngier@arm.com>

Enable handling of CPU specific 32bit coprocessor access. Not much
here either.

Reviewed-by: Christopher Covington <cov at codeaurora.org>
Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/kvm/sys_regs_generic_v8.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm64/kvm/sys_regs_generic_v8.c b/arch/arm64/kvm/sys_regs_generic_v8.c
index d4e8039..4268ab9 100644
--- a/arch/arm64/kvm/sys_regs_generic_v8.c
+++ b/arch/arm64/kvm/sys_regs_generic_v8.c
@@ -59,11 +59,21 @@ static const struct sys_reg_desc genericv8_sys_regs[] = {
 	  access_actlr, reset_actlr, ACTLR_EL1 },
 };
 
+static const struct sys_reg_desc genericv8_cp15_regs[] = {
+	/* ACTLR */
+	{ Op1(0b000), CRn(0b0001), CRm(0b0000), Op2(0b001),
+	  access_actlr },
+};
+
 static struct kvm_sys_reg_target_table genericv8_target_table = {
 	.table64 = {
 		.table = genericv8_sys_regs,
 		.num = ARRAY_SIZE(genericv8_sys_regs),
 	},
+	.table32 = {
+		.table = genericv8_cp15_regs,
+		.num = ARRAY_SIZE(genericv8_cp15_regs),
+	},
 };
 
 static int __init sys_reg_genericv8_init(void)
-- 
1.8.1.4




From marc.zyngier at arm.com  Mon Apr  8 12:17:10 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon,  8 Apr 2013 17:17:10 +0100
Subject: [PATCH v3 08/32] arm64: KVM: architecture specific MMU backend
In-Reply-To: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1365437854-30214-9-git-send-email-marc.zyngier@arm.com>

Define the arm64 specific MMU backend:
- HYP/kernel VA offset
- S2 4/64kB definitions
- S2 page table populating and flushing
- icache cleaning

Reviewed-by: Christopher Covington <cov at codeaurora.org>
Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/include/asm/kvm_mmu.h | 136 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 136 insertions(+)
 create mode 100644 arch/arm64/include/asm/kvm_mmu.h

diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h
new file mode 100644
index 0000000..2eb2230
--- /dev/null
+++ b/arch/arm64/include/asm/kvm_mmu.h
@@ -0,0 +1,136 @@
+/*
+ * Copyright (C) 2012,2013 - ARM Ltd
+ * Author: Marc Zyngier <marc.zyngier at arm.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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#ifndef __ARM64_KVM_MMU_H__
+#define __ARM64_KVM_MMU_H__
+
+#include <asm/page.h>
+#include <asm/memory.h>
+
+/*
+ * As we only have the TTBR0_EL2 register, we cannot express
+ * "negative" addresses. This makes it impossible to directly share
+ * mappings with the kernel.
+ *
+ * Instead, give the HYP mode its own VA region at a fixed offset from
+ * the kernel by just masking the top bits (which are all ones for a
+ * kernel address).
+ */
+#define HYP_PAGE_OFFSET_SHIFT	VA_BITS
+#define HYP_PAGE_OFFSET_MASK	((UL(1) << HYP_PAGE_OFFSET_SHIFT) - 1)
+#define HYP_PAGE_OFFSET		(PAGE_OFFSET & HYP_PAGE_OFFSET_MASK)
+
+/*
+ * Our virtual mapping for the idmap-ed MMU-enable code. Must be
+ * shared across all the page-tables. Conveniently, we use the last
+ * possible page, where no kernel mapping will ever exist.
+ */
+#define TRAMPOLINE_VA		(HYP_PAGE_OFFSET_MASK & PAGE_MASK)
+
+#ifdef __ASSEMBLY__
+
+/*
+ * Convert a kernel VA into a HYP VA.
+ * reg: VA to be converted.
+ */
+.macro kern_hyp_va	reg
+	and	\reg, \reg, #HYP_PAGE_OFFSET_MASK
+.endm
+
+#else
+
+#include <asm/cacheflush.h>
+
+#define KERN_TO_HYP(kva)	((unsigned long)kva - PAGE_OFFSET + HYP_PAGE_OFFSET)
+
+/*
+ * Align KVM with the kernel's view of physical memory. Should be
+ * 40bit IPA, with PGD being 8kB aligned.
+ */
+#define KVM_PHYS_SHIFT	PHYS_MASK_SHIFT
+#define KVM_PHYS_SIZE	(1UL << KVM_PHYS_SHIFT)
+#define KVM_PHYS_MASK	(KVM_PHYS_SIZE - 1UL)
+
+#ifdef CONFIG_ARM64_64K_PAGES
+#define PAGE_LEVELS	2
+#define BITS_PER_LEVEL	13
+#else  /* 4kB pages */
+#define PAGE_LEVELS	3
+#define BITS_PER_LEVEL	9
+#endif
+
+/* Make sure we get the right size, and thus the right alignment */
+#define BITS_PER_S2_PGD (KVM_PHYS_SHIFT - (PAGE_LEVELS - 1) * BITS_PER_LEVEL - PAGE_SHIFT)
+#define PTRS_PER_S2_PGD (1 << max(BITS_PER_LEVEL, BITS_PER_S2_PGD))
+#define S2_PGD_ORDER	get_order(PTRS_PER_S2_PGD * sizeof(pgd_t))
+#define S2_PGD_SIZE	(1 << S2_PGD_ORDER)
+
+int create_hyp_mappings(void *from, void *to);
+int create_hyp_io_mappings(void *from, void *to, phys_addr_t);
+void free_hyp_pgds(void);
+
+int kvm_alloc_stage2_pgd(struct kvm *kvm);
+void kvm_free_stage2_pgd(struct kvm *kvm);
+int kvm_phys_addr_ioremap(struct kvm *kvm, phys_addr_t guest_ipa,
+			  phys_addr_t pa, unsigned long size);
+
+int kvm_handle_guest_abort(struct kvm_vcpu *vcpu, struct kvm_run *run);
+
+void kvm_mmu_free_memory_caches(struct kvm_vcpu *vcpu);
+
+phys_addr_t kvm_mmu_get_httbr(void);
+phys_addr_t kvm_mmu_get_boot_httbr(void);
+phys_addr_t kvm_get_idmap_vector(void);
+int kvm_mmu_init(void);
+void kvm_clear_hyp_idmap(void);
+
+#define	kvm_set_pte(ptep, pte)		set_pte(ptep, pte)
+
+static inline bool kvm_is_write_fault(unsigned long esr)
+{
+	unsigned long esr_ec = esr >> ESR_EL2_EC_SHIFT;
+
+	if (esr_ec == ESR_EL2_EC_IABT)
+		return false;
+
+	if ((esr & ESR_EL2_ISV) && !(esr & ESR_EL2_WNR))
+		return false;
+
+	return true;
+}
+
+static inline void kvm_clean_pgd(pgd_t *pgd) {}
+static inline void kvm_clean_pmd_entry(pmd_t *pmd) {}
+static inline void kvm_clean_pte(pte_t *pte) {}
+
+static inline void kvm_set_s2pte_writable(pte_t *pte)
+{
+	pte_val(*pte) |= PTE_S2_RDWR;
+}
+
+struct kvm;
+
+static inline void coherent_icache_guest_page(struct kvm *kvm, gfn_t gfn)
+{
+	unsigned long hva = gfn_to_hva(kvm, gfn);
+	flush_icache_range(hva, hva + PAGE_SIZE);
+}
+
+#define kvm_flush_dcache_to_poc(a,l)	__flush_dcache_area((a), (l))
+
+#endif /* __ASSEMBLY__ */
+#endif /* __ARM64_KVM_MMU_H__ */
-- 
1.8.1.4




From marc.zyngier at arm.com  Mon Apr  8 12:17:33 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon,  8 Apr 2013 17:17:33 +0100
Subject: [PATCH v3 31/32] arm64: KVM: userspace API documentation
In-Reply-To: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1365437854-30214-32-git-send-email-marc.zyngier@arm.com>

Unsurprisingly, the arm64 userspace API is extremely similar to
the 32bit one, the only significant difference being the ONE_REG
register mapping.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 Documentation/virtual/kvm/api.txt | 55 +++++++++++++++++++++++++--------------
 1 file changed, 36 insertions(+), 19 deletions(-)

diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
index 119358d..7c3385e 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -280,7 +280,7 @@ kvm_run' (see below).
 4.11 KVM_GET_REGS
 
 Capability: basic
-Architectures: all except ARM
+Architectures: all except ARM, arm64
 Type: vcpu ioctl
 Parameters: struct kvm_regs (out)
 Returns: 0 on success, -1 on error
@@ -301,7 +301,7 @@ struct kvm_regs {
 4.12 KVM_SET_REGS
 
 Capability: basic
-Architectures: all except ARM
+Architectures: all except ARM, arm64
 Type: vcpu ioctl
 Parameters: struct kvm_regs (in)
 Returns: 0 on success, -1 on error
@@ -587,7 +587,7 @@ struct kvm_fpu {
 4.24 KVM_CREATE_IRQCHIP
 
 Capability: KVM_CAP_IRQCHIP
-Architectures: x86, ia64, ARM
+Architectures: x86, ia64, ARM, arm64
 Type: vm ioctl
 Parameters: none
 Returns: 0 on success, -1 on error
@@ -595,14 +595,14 @@ Returns: 0 on success, -1 on error
 Creates an interrupt controller model in the kernel.  On x86, creates a virtual
 ioapic, a virtual PIC (two PICs, nested), and sets up future vcpus to have a
 local APIC.  IRQ routing for GSIs 0-15 is set to both PIC and IOAPIC; GSI 16-23
-only go to the IOAPIC.  On ia64, a IOSAPIC is created. On ARM, a GIC is
+only go to the IOAPIC.  On ia64, a IOSAPIC is created. On ARM/arm64, a GIC is
 created.
 
 
 4.25 KVM_IRQ_LINE
 
 Capability: KVM_CAP_IRQCHIP
-Architectures: x86, ia64, arm
+Architectures: x86, ia64, arm, arm64
 Type: vm ioctl
 Parameters: struct kvm_irq_level
 Returns: 0 on success, -1 on error
@@ -612,9 +612,10 @@ On some architectures it is required that an interrupt controller model has
 been previously created with KVM_CREATE_IRQCHIP.  Note that edge-triggered
 interrupts require the level to be set to 1 and then back to 0.
 
-ARM can signal an interrupt either at the CPU level, or at the in-kernel irqchip
-(GIC), and for in-kernel irqchip can tell the GIC to use PPIs designated for
-specific cpus.  The irq field is interpreted like this:
+ARM/arm64 can signal an interrupt either at the CPU level, or at the
+in-kernel irqchip (GIC), and for in-kernel irqchip can tell the GIC to
+use PPIs designated for specific cpus.  The irq field is interpreted
+like this:
 
  ?bits:  | 31 ... 24 | 23  ... 16 | 15    ...    0 |
   field: | irq_type  | vcpu_index |     irq_id     |
@@ -1802,6 +1803,19 @@ ARM 32-bit VFP control registers have the following id bit patterns:
 ARM 64-bit FP registers have the following id bit patterns:
   0x4002 0000 0012 0 <regno:12>
 
+
+arm64 registers are mapped using the lower 32 bits. The upper 16 of
+that is the register group type, or coprocessor number:
+
+arm64 core/FP-SIMD registers have the following id bit patterns:
+  0x6002 0000 0010 <index into the kvm_regs struct:16>
+
+arm64 CCSIDR registers are demultiplexed by CSSELR value:
+  0x6002 0000 0011 00 <csselr:8>
+
+arm64 system registers have the following id bit patterns:
+  0x6002 0000 0013 <op0:2> <op1:3> <crn:4> <crm:4> <op2:3>
+
 4.69 KVM_GET_ONE_REG
 
 Capability: KVM_CAP_ONE_REG
@@ -2165,7 +2179,7 @@ valid entries found.
 4.77 KVM_ARM_VCPU_INIT
 
 Capability: basic
-Architectures: arm
+Architectures: arm, arm64
 Type: vcpu ioctl
 Parameters: struct struct kvm_vcpu_init (in)
 Returns: 0 on success; -1 on error
@@ -2184,12 +2198,14 @@ should be created before this ioctl is invoked.
 Possible features:
 	- KVM_ARM_VCPU_POWER_OFF: Starts the CPU in a power-off state.
 	  Depends on KVM_CAP_ARM_PSCI.
+	- KVM_ARM_VCPU_EL1_32BIT: Starts the CPU in a 32bit mode.
+	  Depends on KVM_CAP_ARM_EL1_32BIT (arm64 only).
 
 
 4.78 KVM_GET_REG_LIST
 
 Capability: basic
-Architectures: arm
+Architectures: arm, arm64
 Type: vcpu ioctl
 Parameters: struct kvm_reg_list (in/out)
 Returns: 0 on success; -1 on error
@@ -2209,7 +2225,7 @@ KVM_GET_ONE_REG/KVM_SET_ONE_REG calls.
 4.80 KVM_ARM_SET_DEVICE_ADDR
 
 Capability: KVM_CAP_ARM_SET_DEVICE_ADDR
-Architectures: arm
+Architectures: arm, arm64
 Type: vm ioctl
 Parameters: struct kvm_arm_device_address (in)
 Returns: 0 on success, -1 on error
@@ -2230,18 +2246,19 @@ can access emulated or directly exposed devices, which the host kernel needs
 to know about. The id field is an architecture specific identifier for a
 specific device.
 
-ARM divides the id field into two parts, a device id and an address type id
-specific to the individual device.
+ARM/arm64 divides the id field into two parts, a device id and an
+address type id specific to the individual device.
 
  ?bits:  | 63        ...       32 | 31    ...    16 | 15    ...    0 |
   field: |        0x00000000      |     device id   |  addr type id  |
 
-ARM currently only require this when using the in-kernel GIC support for the
-hardware VGIC features, using KVM_ARM_DEVICE_VGIC_V2 as the device id.  When
-setting the base address for the guest's mapping of the VGIC virtual CPU
-and distributor interface, the ioctl must be called after calling
-KVM_CREATE_IRQCHIP, but before calling KVM_RUN on any of the VCPUs.  Calling
-this ioctl twice for any of the base addresses will return -EEXIST.
+ARM/arm64 currently only require this when using the in-kernel GIC
+support for the hardware VGIC features, using KVM_ARM_DEVICE_VGIC_V2
+as the device id.  When setting the base address for the guest's
+mapping of the VGIC virtual CPU and distributor interface, the ioctl
+must be called after calling KVM_CREATE_IRQCHIP, but before calling
+KVM_RUN on any of the VCPUs.  Calling this ioctl twice for any of the
+base addresses will return -EEXIST.
 
 
 5. The kvm_run structure
-- 
1.8.1.4




From marc.zyngier at arm.com  Mon Apr  8 12:17:25 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon,  8 Apr 2013 17:17:25 +0100
Subject: [PATCH v3 23/32] arm64: KVM: define 32bit specific registers
In-Reply-To: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1365437854-30214-24-git-send-email-marc.zyngier@arm.com>

Define the 32bit specific registers (SPSRs, cp15...).

Most CPU registers are directly mapped to a 64bit register
(r0->x0...). Only the SPSRs have separate registers.

cp15 registers are also mapped into their 64bit counterpart in most
cases.

Reviewed-by: Christopher Covington <cov at codeaurora.org>
Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/include/asm/kvm_asm.h  | 38 +++++++++++++++++++++++++++++++++++++-
 arch/arm64/include/asm/kvm_host.h |  5 ++++-
 arch/arm64/include/uapi/asm/kvm.h |  7 ++++++-
 3 files changed, 47 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/include/asm/kvm_asm.h b/arch/arm64/include/asm/kvm_asm.h
index 591ac21..c92de41 100644
--- a/arch/arm64/include/asm/kvm_asm.h
+++ b/arch/arm64/include/asm/kvm_asm.h
@@ -42,7 +42,43 @@
 #define	TPIDR_EL1	18	/* Thread ID, Privileged */
 #define	AMAIR_EL1	19	/* Aux Memory Attribute Indirection Register */
 #define	CNTKCTL_EL1	20	/* Timer Control Register (EL1) */
-#define	NR_SYS_REGS	21
+/* 32bit specific registers. Keep them at the end of the range */
+#define	DACR32_EL2	21	/* Domain Access Control Register */
+#define	IFSR32_EL2	22	/* Instruction Fault Status Register */
+#define	FPEXC32_EL2	23	/* Floating-Point Exception Control Register */
+#define	DBGVCR32_EL2	24	/* Debug Vector Catch Register */
+#define	TEECR32_EL1	25	/* ThumbEE Configuration Register */
+#define	TEEHBR32_EL1	26	/* ThumbEE Handler Base Register */
+#define	NR_SYS_REGS	27
+
+/* 32bit mapping */
+#define c0_MPIDR	(MPIDR_EL1 * 2)	/* MultiProcessor ID Register */
+#define c0_CSSELR	(CSSELR_EL1 * 2)/* Cache Size Selection Register */
+#define c1_SCTLR	(SCTLR_EL1 * 2)	/* System Control Register */
+#define c1_ACTLR	(ACTLR_EL1 * 2)	/* Auxiliary Control Register */
+#define c1_CPACR	(CPACR_EL1 * 2)	/* Coprocessor Access Control */
+#define c2_TTBR0	(TTBR0_EL1 * 2)	/* Translation Table Base Register 0 */
+#define c2_TTBR0_high	(c2_TTBR0 + 1)	/* TTBR0 top 32 bits */
+#define c2_TTBR1	(TTBR1_EL1 * 2)	/* Translation Table Base Register 1 */
+#define c2_TTBR1_high	(c2_TTBR1 + 1)	/* TTBR1 top 32 bits */
+#define c2_TTBCR	(TCR_EL1 * 2)	/* Translation Table Base Control R. */
+#define c3_DACR		(DACR32_EL2 * 2)/* Domain Access Control Register */
+#define c5_DFSR		(ESR_EL1 * 2)	/* Data Fault Status Register */
+#define c5_IFSR		(IFSR32_EL2 * 2)/* Instruction Fault Status Register */
+#define c5_ADFSR	(AFSR0_EL1 * 2)	/* Auxiliary Data Fault Status R */
+#define c5_AIFSR	(AFSR1_EL1 * 2)	/* Auxiliary Instr Fault Status R */
+#define c6_DFAR		(FAR_EL1 * 2)	/* Data Fault Address Register */
+#define c6_IFAR		(c6_DFAR + 1)	/* Instruction Fault Address Register */
+#define c10_PRRR	(MAIR_EL1 * 2)	/* Primary Region Remap Register */
+#define c10_NMRR	(c10_PRRR + 1)	/* Normal Memory Remap Register */
+#define c12_VBAR	(VBAR_EL1 * 2)	/* Vector Base Address Register */
+#define c13_CID		(CONTEXTIDR_EL1 * 2)	/* Context ID Register */
+#define c13_TID_URW	(TPIDR_EL0 * 2)	/* Thread ID, User R/W */
+#define c13_TID_URO	(TPIDRRO_EL0 * 2)/* Thread ID, User R/O */
+#define c13_TID_PRIV	(TPIDR_EL1 * 2)	/* Thread ID, Privileged */
+#define c10_AMAIR	(AMAIR_EL1 * 2)	/* Aux Memory Attr Indirection Reg */
+#define c14_CNTKCTL	(CNTKCTL_EL1 * 2) /* Timer Control Register (PL1) */
+#define NR_CP15_REGS	(NR_SYS_REGS * 2)
 
 #define ARM_EXCEPTION_IRQ	  0
 #define ARM_EXCEPTION_TRAP	  1
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index fdcb324..d44064d 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -84,7 +84,10 @@ struct kvm_vcpu_fault_info {
 
 struct kvm_cpu_context {
 	struct kvm_regs	gp_regs;
-	u64 sys_regs[NR_SYS_REGS];
+	union {
+		u64 sys_regs[NR_SYS_REGS];
+		u32 cp15[NR_CP15_REGS];
+	};
 };
 
 typedef struct kvm_cpu_context kvm_cpu_context_t;
diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
index fb60f90..5b1110c 100644
--- a/arch/arm64/include/uapi/asm/kvm.h
+++ b/arch/arm64/include/uapi/asm/kvm.h
@@ -23,7 +23,12 @@
 #define __ARM_KVM_H__
 
 #define KVM_SPSR_EL1	0
-#define KVM_NR_SPSR	1
+#define KVM_SPSR_SVC	KVM_SPSR_EL1
+#define KVM_SPSR_ABT	1
+#define KVM_SPSR_UND	2
+#define KVM_SPSR_IRQ	3
+#define KVM_SPSR_FIQ	4
+#define KVM_NR_SPSR	5
 
 #ifndef __ASSEMBLY__
 #include <asm/types.h>
-- 
1.8.1.4




From marc.zyngier at arm.com  Mon Apr  8 12:17:14 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon,  8 Apr 2013 17:17:14 +0100
Subject: [PATCH v3 12/32] arm64: KVM: virtual CPU reset
In-Reply-To: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1365437854-30214-13-git-send-email-marc.zyngier@arm.com>

Provide the reset code for a virtual CPU booted in 64bit mode.

Reviewed-by: Christopher Covington <cov at codeaurora.org>
Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/kvm/reset.c | 76 ++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 76 insertions(+)
 create mode 100644 arch/arm64/kvm/reset.c

diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
new file mode 100644
index 0000000..bc33e76
--- /dev/null
+++ b/arch/arm64/kvm/reset.c
@@ -0,0 +1,76 @@
+/*
+ * Copyright (C) 2012,2013 - ARM Ltd
+ * Author: Marc Zyngier <marc.zyngier at arm.com>
+ *
+ * Derived from arch/arm/kvm/reset.c
+ * Copyright (C) 2012 - Virtual Open Systems and Columbia University
+ * Author: Christoffer Dall <c.dall at virtualopensystems.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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <linux/errno.h>
+#include <linux/kvm_host.h>
+#include <linux/kvm.h>
+
+#include <asm/cputype.h>
+#include <asm/ptrace.h>
+#include <asm/kvm_arm.h>
+#include <asm/kvm_coproc.h>
+
+/*
+ * ARMv8 Reset Values
+ */
+static struct kvm_regs default_regs_reset = {
+	.regs.pstate = PSR_MODE_EL1h | PSR_A_BIT | PSR_I_BIT | PSR_F_BIT,
+};
+
+int kvm_arch_dev_ioctl_check_extention(long ext)
+{
+	int r;
+
+	switch (ext) {
+	default:
+		r = 0;
+	}
+
+	return r;
+}
+
+
+/**
+ * kvm_reset_vcpu - sets core registers and sys_regs to reset value
+ * @vcpu: The VCPU pointer
+ *
+ * This function finds the right table above and sets the registers on
+ * the virtual CPU struct to their architectually defined reset
+ * values.
+ */
+int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
+{
+	struct kvm_regs *cpu_reset;
+
+	switch (vcpu->arch.target) {
+	default:
+		cpu_reset = &default_regs_reset;
+		break;
+	}
+
+	/* Reset core registers */
+	memcpy(vcpu_gp_regs(vcpu), cpu_reset, sizeof(*cpu_reset));
+
+	/* Reset system registers */
+	kvm_reset_sys_regs(vcpu);
+
+	return 0;
+}
-- 
1.8.1.4




From marc.zyngier at arm.com  Mon Apr  8 12:17:18 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon,  8 Apr 2013 17:17:18 +0100
Subject: [PATCH v3 16/32] arm64: KVM: hypervisor initialization code
In-Reply-To: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1365437854-30214-17-git-send-email-marc.zyngier@arm.com>

Provide EL2 with page tables and stack, and set the vectors
to point to the full blown world-switch code.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/include/asm/kvm_host.h |  13 +++++
 arch/arm64/kvm/hyp-init.S         | 112 ++++++++++++++++++++++++++++++++++++++
 2 files changed, 125 insertions(+)
 create mode 100644 arch/arm64/kvm/hyp-init.S

diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index a0279ff..8655de4 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -183,4 +183,17 @@ int handle_exit(struct kvm_vcpu *vcpu, struct kvm_run *run,
 int kvm_perf_init(void);
 int kvm_perf_teardown(void);
 
+static inline void __cpu_init_hyp_mode(unsigned long long boot_pgd_ptr,
+				       unsigned long long pgd_ptr,
+				       unsigned long hyp_stack_ptr,
+				       unsigned long vector_ptr)
+{
+	/*
+	 * Call initialization code, and switch to the full blown
+	 * HYP code.
+	 */
+	kvm_call_hyp((void *)boot_pgd_ptr, pgd_ptr,
+		     hyp_stack_ptr, vector_ptr);
+}
+
 #endif /* __ARM64_KVM_HOST_H__ */
diff --git a/arch/arm64/kvm/hyp-init.S b/arch/arm64/kvm/hyp-init.S
new file mode 100644
index 0000000..4a9cfd2
--- /dev/null
+++ b/arch/arm64/kvm/hyp-init.S
@@ -0,0 +1,112 @@
+/*
+ * Copyright (C) 2012,2013 - ARM Ltd
+ * Author: Marc Zyngier <marc.zyngier at arm.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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <linux/linkage.h>
+
+#include <asm/assembler.h>
+#include <asm/kvm_arm.h>
+#include <asm/kvm_mmu.h>
+
+	.text
+	.pushsection	.hyp.idmap.text, "ax"
+
+	.align	11
+
+__kvm_hyp_init:
+	.global	__kvm_hyp_init
+
+ENTRY(__kvm_hyp_init_vector)
+	ventry	__invalid		// Synchronous EL2t
+	ventry	__invalid		// IRQ EL2t
+	ventry	__invalid		// FIQ EL2t
+	ventry	__invalid		// Error EL2t
+
+	ventry	__invalid		// Synchronous EL2h
+	ventry	__invalid		// IRQ EL2h
+	ventry	__invalid		// FIQ EL2h
+	ventry	__invalid		// Error EL2h
+
+	ventry	__do_hyp_init		// Synchronous 64-bit EL1
+	ventry	__invalid		// IRQ 64-bit EL1
+	ventry	__invalid		// FIQ 64-bit EL1
+	ventry	__invalid		// Error 64-bit EL1
+
+	ventry	__invalid		// Synchronous 32-bit EL1
+	ventry	__invalid		// IRQ 32-bit EL1
+	ventry	__invalid		// FIQ 32-bit EL1
+	ventry	__invalid		// Error 32-bit EL1
+ENDPROC(__kvm_hyp_init_vector)
+
+__invalid:
+	b	.
+
+	/*
+	 * x0: HYP boot pgd
+	 * x1: HYP pgd
+	 * x2: HYP stack
+	 * x3: HYP vectors
+	 */
+__do_hyp_init:
+
+	msr	ttbr0_el2, x0
+
+	mrs	x4, tcr_el1
+	ldr	x5, =TCR_EL2_MASK
+	and	x4, x4, x5
+	ldr	x5, =TCR_EL2_FLAGS
+	orr	x4, x4, x5
+	msr	tcr_el2, x4
+
+	ldr	x4, =VTCR_EL2_FLAGS
+	msr	vtcr_el2, x4
+
+	mrs	x4, mair_el1
+	msr	mair_el2, x4
+	isb
+
+	mov	x4, #SCTLR_EL2_FLAGS
+	msr	sctlr_el2, x4
+	isb
+
+	/* MMU is now enabled. Get ready for the trampoline dance */
+	ldr	x4, =TRAMPOLINE_VA
+	adr	x5, target
+	bfi	x4, x5, #0, #PAGE_SHIFT
+	br	x4
+
+	nop
+
+target: /* We're now in the trampoline code, switch page tables */
+	msr	ttbr0_el2, x1
+	isb
+
+	/* Invalidate the old TLBs */
+	tlbi	alle2
+	dsb	sy
+
+	/* Set the stack and new vectors */
+	kern_hyp_va	x2
+	mov	sp, x2
+	kern_hyp_va	x3
+	msr	vbar_el2, x3
+
+	/* Hello, World! */
+	eret
+
+	.ltorg
+
+	.popsection
-- 
1.8.1.4




From marc.zyngier at arm.com  Mon Apr  8 12:17:22 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon,  8 Apr 2013 17:17:22 +0100
Subject: [PATCH v3 20/32] arm64: KVM: Plug the arch timer
In-Reply-To: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1365437854-30214-21-git-send-email-marc.zyngier@arm.com>

Add support for the in-kernel timer emulation. The include file
is a complete duplicate of the 32bit one - something to fix
at one point.

Reviewed-by: Christopher Covington <cov at codeaurora.org>
Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm/kvm/arch_timer.c               |  1 +
 arch/arm64/include/asm/kvm_arch_timer.h | 58 +++++++++++++++++++++++++++++++++
 arch/arm64/kvm/hyp.S                    | 56 +++++++++++++++++++++++++++++++
 3 files changed, 115 insertions(+)
 create mode 100644 arch/arm64/include/asm/kvm_arch_timer.h

diff --git a/arch/arm/kvm/arch_timer.c b/arch/arm/kvm/arch_timer.c
index c55b608..49a7516 100644
--- a/arch/arm/kvm/arch_timer.c
+++ b/arch/arm/kvm/arch_timer.c
@@ -195,6 +195,7 @@ static struct notifier_block kvm_timer_cpu_nb = {
 
 static const struct of_device_id arch_timer_of_match[] = {
 	{ .compatible	= "arm,armv7-timer",	},
+	{ .compatible	= "arm,armv8-timer",	},
 	{},
 };
 
diff --git a/arch/arm64/include/asm/kvm_arch_timer.h b/arch/arm64/include/asm/kvm_arch_timer.h
new file mode 100644
index 0000000..eb02273
--- /dev/null
+++ b/arch/arm64/include/asm/kvm_arch_timer.h
@@ -0,0 +1,58 @@
+/*
+ * Copyright (C) 2012 ARM Ltd.
+ * Author: Marc Zyngier <marc.zyngier at arm.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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#ifndef __ARM64_KVM_ARCH_TIMER_H
+#define __ARM64_KVM_ARCH_TIMER_H
+
+#include <linux/clocksource.h>
+#include <linux/hrtimer.h>
+#include <linux/workqueue.h>
+
+struct arch_timer_kvm {
+	/* Is the timer enabled */
+	bool			enabled;
+
+	/* Virtual offset, restored only */
+	cycle_t			cntvoff;
+};
+
+struct arch_timer_cpu {
+	/* Background timer used when the guest is not running */
+	struct hrtimer			timer;
+
+	/* Work queued with the above timer expires */
+	struct work_struct		expired;
+
+	/* Background timer active */
+	bool				armed;
+
+	/* Timer IRQ */
+	const struct kvm_irq_level	*irq;
+
+	/* Registers: control register, timer value */
+	u32				cntv_ctl;	/* Saved/restored */
+	cycle_t				cntv_cval;	/* Saved/restored */
+};
+
+int kvm_timer_hyp_init(void);
+int kvm_timer_init(struct kvm *kvm);
+void kvm_timer_vcpu_init(struct kvm_vcpu *vcpu);
+void kvm_timer_flush_hwstate(struct kvm_vcpu *vcpu);
+void kvm_timer_sync_hwstate(struct kvm_vcpu *vcpu);
+void kvm_timer_vcpu_terminate(struct kvm_vcpu *vcpu);
+
+#endif
diff --git a/arch/arm64/kvm/hyp.S b/arch/arm64/kvm/hyp.S
index cc3192e..25da0b5 100644
--- a/arch/arm64/kvm/hyp.S
+++ b/arch/arm64/kvm/hyp.S
@@ -390,6 +390,60 @@ __kvm_hyp_code_start:
 2:
 .endm
 
+.macro save_timer_state
+	// x0: vcpu pointer
+	ldr	x2, [x0, #VCPU_KVM]
+	kern_hyp_va x2
+	ldr	w3, [x2, #KVM_TIMER_ENABLED]
+	cbz	w3, 1f
+
+	mrs	x3, cntv_ctl_el0
+	and	x3, x3, #3
+	str	w3, [x0, #VCPU_TIMER_CNTV_CTL]
+	bic	x3, x3, #1		// Clear Enable
+	msr	cntv_ctl_el0, x3
+
+	isb
+
+	mrs	x3, cntv_cval_el0
+	str	x3, [x0, #VCPU_TIMER_CNTV_CVAL]
+
+1:
+	// Allow physical timer/counter access for the host
+	mrs	x2, cnthctl_el2
+	orr	x2, x2, #3
+	msr	cnthctl_el2, x2
+
+	// Clear cntvoff for the host
+	msr	cntvoff_el2, xzr
+.endm
+
+.macro restore_timer_state
+	// x0: vcpu pointer
+	// Disallow physical timer access for the guest
+	// Physical counter access is allowed
+	mrs	x2, cnthctl_el2
+	orr	x2, x2, #1
+	bic	x2, x2, #2
+	msr	cnthctl_el2, x2
+
+	ldr	x2, [x0, #VCPU_KVM]
+	kern_hyp_va x2
+	ldr	w3, [x2, #KVM_TIMER_ENABLED]
+	cbz	w3, 1f
+
+	ldr	x3, [x2, #KVM_TIMER_CNTVOFF]
+	msr	cntvoff_el2, x3
+	ldr	x2, [x0, #VCPU_TIMER_CNTV_CVAL]
+	msr	cntv_cval_el0, x2
+	isb
+
+	ldr	w2, [x0, #VCPU_TIMER_CNTV_CTL]
+	and	x2, x2, #3
+	msr	cntv_ctl_el0, x2
+1:
+.endm
+
 __save_sysregs:
 	save_sysregs
 	ret
@@ -433,6 +487,7 @@ ENTRY(__kvm_vcpu_run)
 	activate_vm
 
 	restore_vgic_state
+	restore_timer_state
 
 	// Guest context
 	add	x2, x0, #VCPU_CONTEXT
@@ -456,6 +511,7 @@ __kvm_vcpu_return:
 	bl __save_fpsimd
 	bl __save_sysregs
 
+	save_timer_state
 	save_vgic_state
 
 	deactivate_traps
-- 
1.8.1.4




From marc.zyngier at arm.com  Mon Apr  8 12:17:19 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon,  8 Apr 2013 17:17:19 +0100
Subject: [PATCH v3 17/32] arm64: KVM: HYP mode world switch implementation
In-Reply-To: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1365437854-30214-18-git-send-email-marc.zyngier@arm.com>

The HYP mode world switch in all its glory.

Implements save/restore of host/guest registers, EL2 trapping,
IPA resolution, and additional services (tlb invalidation).

Reviewed-by: Christopher Covington <cov at codeaurora.org>
Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/kernel/asm-offsets.c |  34 +++
 arch/arm64/kvm/hyp.S            | 602 ++++++++++++++++++++++++++++++++++++++++
 2 files changed, 636 insertions(+)
 create mode 100644 arch/arm64/kvm/hyp.S

diff --git a/arch/arm64/kernel/asm-offsets.c b/arch/arm64/kernel/asm-offsets.c
index a2a4d81..666e231 100644
--- a/arch/arm64/kernel/asm-offsets.c
+++ b/arch/arm64/kernel/asm-offsets.c
@@ -21,6 +21,7 @@
 #include <linux/sched.h>
 #include <linux/mm.h>
 #include <linux/dma-mapping.h>
+#include <linux/kvm_host.h>
 #include <asm/thread_info.h>
 #include <asm/memory.h>
 #include <asm/cputable.h>
@@ -104,5 +105,38 @@ int main(void)
   BLANK();
   DEFINE(TZ_MINWEST,		offsetof(struct timezone, tz_minuteswest));
   DEFINE(TZ_DSTTIME,		offsetof(struct timezone, tz_dsttime));
+  BLANK();
+#ifdef CONFIG_KVM_ARM_HOST
+  DEFINE(VCPU_CONTEXT,		offsetof(struct kvm_vcpu, arch.ctxt));
+  DEFINE(CPU_GP_REGS,		offsetof(struct kvm_cpu_context, gp_regs));
+  DEFINE(CPU_USER_PT_REGS,	offsetof(struct kvm_regs, regs));
+  DEFINE(CPU_FP_REGS,		offsetof(struct kvm_regs, fp_regs));
+  DEFINE(CPU_SP_EL1,		offsetof(struct kvm_regs, sp_el1));
+  DEFINE(CPU_ELR_EL1,		offsetof(struct kvm_regs, elr_el1));
+  DEFINE(CPU_SPSR,		offsetof(struct kvm_regs, spsr));
+  DEFINE(CPU_SYSREGS,		offsetof(struct kvm_cpu_context, sys_regs));
+  DEFINE(VCPU_ESR_EL2,		offsetof(struct kvm_vcpu, arch.fault.esr_el2));
+  DEFINE(VCPU_FAR_EL2,		offsetof(struct kvm_vcpu, arch.fault.far_el2));
+  DEFINE(VCPU_HPFAR_EL2,	offsetof(struct kvm_vcpu, arch.fault.hpfar_el2));
+  DEFINE(VCPU_HCR_EL2,		offsetof(struct kvm_vcpu, arch.hcr_el2));
+  DEFINE(VCPU_IRQ_LINES,	offsetof(struct kvm_vcpu, arch.irq_lines));
+  DEFINE(VCPU_HOST_CONTEXT,	offsetof(struct kvm_vcpu, arch.host_cpu_context));
+  DEFINE(VCPU_TIMER_CNTV_CTL,	offsetof(struct kvm_vcpu, arch.timer_cpu.cntv_ctl));
+  DEFINE(VCPU_TIMER_CNTV_CVAL,	offsetof(struct kvm_vcpu, arch.timer_cpu.cntv_cval));
+  DEFINE(KVM_TIMER_CNTVOFF,	offsetof(struct kvm, arch.timer.cntvoff));
+  DEFINE(KVM_TIMER_ENABLED,	offsetof(struct kvm, arch.timer.enabled));
+  DEFINE(VCPU_KVM,		offsetof(struct kvm_vcpu, kvm));
+  DEFINE(VCPU_VGIC_CPU,		offsetof(struct kvm_vcpu, arch.vgic_cpu));
+  DEFINE(VGIC_CPU_HCR,		offsetof(struct vgic_cpu, vgic_hcr));
+  DEFINE(VGIC_CPU_VMCR,		offsetof(struct vgic_cpu, vgic_vmcr));
+  DEFINE(VGIC_CPU_MISR,		offsetof(struct vgic_cpu, vgic_misr));
+  DEFINE(VGIC_CPU_EISR,		offsetof(struct vgic_cpu, vgic_eisr));
+  DEFINE(VGIC_CPU_ELRSR,	offsetof(struct vgic_cpu, vgic_elrsr));
+  DEFINE(VGIC_CPU_APR,		offsetof(struct vgic_cpu, vgic_apr));
+  DEFINE(VGIC_CPU_LR,		offsetof(struct vgic_cpu, vgic_lr));
+  DEFINE(VGIC_CPU_NR_LR,	offsetof(struct vgic_cpu, nr_lr));
+  DEFINE(KVM_VTTBR,		offsetof(struct kvm, arch.vttbr));
+  DEFINE(KVM_VGIC_VCTRL,	offsetof(struct kvm, arch.vgic.vctrl_base));
+#endif
   return 0;
 }
diff --git a/arch/arm64/kvm/hyp.S b/arch/arm64/kvm/hyp.S
new file mode 100644
index 0000000..c745d20
--- /dev/null
+++ b/arch/arm64/kvm/hyp.S
@@ -0,0 +1,602 @@
+/*
+ * Copyright (C) 2012,2013 - ARM Ltd
+ * Author: Marc Zyngier <marc.zyngier at arm.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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <linux/linkage.h>
+#include <linux/irqchip/arm-gic.h>
+
+#include <asm/assembler.h>
+#include <asm/memory.h>
+#include <asm/asm-offsets.h>
+#include <asm/fpsimdmacros.h>
+#include <asm/kvm.h>
+#include <asm/kvm_asm.h>
+#include <asm/kvm_arm.h>
+#include <asm/kvm_mmu.h>
+
+#define CPU_GP_REG_OFFSET(x)	(CPU_GP_REGS + x)
+#define CPU_XREG_OFFSET(x)	CPU_GP_REG_OFFSET(CPU_USER_PT_REGS + 8*x)
+#define CPU_SPSR_OFFSET(x)	CPU_GP_REG_OFFSET(CPU_SPSR + 8*x)
+#define CPU_SYSREG_OFFSET(x)	(CPU_SYSREGS + 8*x)
+
+	.text
+	.pushsection	.hyp.text, "ax"
+	.align	PAGE_SHIFT
+
+__kvm_hyp_code_start:
+	.globl __kvm_hyp_code_start
+
+.macro save_common_regs
+	// x2: base address for cpu context
+	// x3: tmp register
+
+	add	x3, x2, #CPU_XREG_OFFSET(19)
+	stp	x19, x20, [x3]
+	stp	x21, x22, [x3, #16]
+	stp	x23, x24, [x3, #32]
+	stp	x25, x26, [x3, #48]
+	stp	x27, x28, [x3, #64]
+	stp	x29, lr, [x3, #80]
+
+	mrs	x19, sp_el0
+	mrs	x20, elr_el2		// EL1 PC
+	mrs	x21, spsr_el2		// EL1 pstate
+
+	stp	x19, x20, [x3, #96]
+	str	x21, [x3, #112]
+
+	mrs	x22, sp_el1
+	mrs	x23, elr_el1
+	mrs	x24, spsr_el1
+
+	str	x22, [x2, #CPU_GP_REG_OFFSET(CPU_SP_EL1)]
+	str	x23, [x2, #CPU_GP_REG_OFFSET(CPU_ELR_EL1)]
+	str	x24, [x2, #CPU_SPSR_OFFSET(KVM_SPSR_EL1)]
+.endm
+
+.macro restore_common_regs
+	// x2: base address for cpu context
+	// x3: tmp register
+
+	ldr	x22, [x2, #CPU_GP_REG_OFFSET(CPU_SP_EL1)]
+	ldr	x23, [x2, #CPU_GP_REG_OFFSET(CPU_ELR_EL1)]
+	ldr	x24, [x2, #CPU_SPSR_OFFSET(KVM_SPSR_EL1)]
+
+	msr	sp_el1, x22
+	msr	elr_el1, x23
+	msr	spsr_el1, x24
+
+	add	x3, x2, #CPU_XREG_OFFSET(31)    // SP_EL0
+	ldp	x19, x20, [x3]
+	ldr	x21, [x3, #16]
+
+	msr	sp_el0, x19
+	msr	elr_el2, x20 				// EL1 PC
+	msr	spsr_el2, x21 				// EL1 pstate
+
+	add	x3, x2, #CPU_XREG_OFFSET(19)
+	ldp	x19, x20, [x3]
+	ldp	x21, x22, [x3, #16]
+	ldp	x23, x24, [x3, #32]
+	ldp	x25, x26, [x3, #48]
+	ldp	x27, x28, [x3, #64]
+	ldp	x29, lr, [x3, #80]
+.endm
+
+.macro save_host_regs
+	save_common_regs
+.endm
+
+.macro restore_host_regs
+	restore_common_regs
+.endm
+
+.macro save_fpsimd
+	// x2: cpu context address
+	// x3, x4: tmp regs
+	add	x3, x2, #CPU_GP_REG_OFFSET(CPU_FP_REGS)
+	fpsimd_save x3, 4
+.endm
+
+.macro restore_fpsimd
+	// x2: cpu context address
+	// x3, x4: tmp regs
+	add	x3, x2, #CPU_GP_REG_OFFSET(CPU_FP_REGS)
+	fpsimd_restore x3, 4
+.endm
+
+.macro save_guest_regs
+	// x0 is the vcpu address
+	// x1 is the return code, do not corrupt!
+	// x2 is the cpu context
+	// x3 is a tmp register
+	// Guest's x0-x3 are on the stack
+
+	// Compute base to save registers
+	add	x3, x2, #CPU_XREG_OFFSET(4)
+	stp	x4, x5, [x3]
+	stp	x6, x7, [x3, #16]
+	stp	x8, x9, [x3, #32]
+	stp	x10, x11, [x3, #48]
+	stp	x12, x13, [x3, #64]
+	stp	x14, x15, [x3, #80]
+	stp	x16, x17, [x3, #96]
+	str	x18, [x3, #112]
+
+	pop	x6, x7			// x2, x3
+	pop	x4, x5			// x0, x1
+
+	add	x3, x2, #CPU_XREG_OFFSET(0)
+	stp	x4, x5, [x3]
+	stp	x6, x7, [x3, #16]
+
+	save_common_regs
+.endm
+
+.macro restore_guest_regs
+	// x0 is the vcpu address.
+	// x2 is the cpu context
+	// x3 is a tmp register
+
+	// Prepare x0-x3 for later restore
+	add	x3, x2, #CPU_XREG_OFFSET(0)
+	ldp	x4, x5, [x3]
+	ldp	x6, x7, [x3, #16]
+	push	x4, x5		// Push x0-x3 on the stack
+	push	x6, x7
+
+	// x4-x18
+	ldp	x4, x5, [x3, #32]
+	ldp	x6, x7, [x3, #48]
+	ldp	x8, x9, [x3, #64]
+	ldp	x10, x11, [x3, #80]
+	ldp	x12, x13, [x3, #96]
+	ldp	x14, x15, [x3, #112]
+	ldp	x16, x17, [x3, #128]
+	ldr	x18, [x3, #144]
+
+	// x19-x29, lr, sp*, elr*, spsr*
+	restore_common_regs
+
+	// Last bits of the 64bit state
+	pop	x2, x3
+	pop	x0, x1
+
+	// Do not touch any register after this!
+.endm
+
+/*
+ * Macros to perform system register save/restore.
+ *
+ * Ordering here is absolutely critical, and must be kept consistent
+ * in {save,restore}_sysregs, {save,restore}_guest_32bit_state,
+ * and in kvm_asm.h.
+ *
+ * In other words, don't touch any of these unless you know what
+ * you are doing.
+ */
+.macro save_sysregs
+	// x2: base address for cpu context
+	// x3: tmp register
+
+	add	x3, x2, #CPU_SYSREG_OFFSET(MPIDR_EL1)
+
+	mrs	x4,	vmpidr_el2
+	mrs	x5,	csselr_el1
+	mrs	x6,	sctlr_el1
+	mrs	x7,	actlr_el1
+	mrs	x8,	cpacr_el1
+	mrs	x9,	ttbr0_el1
+	mrs	x10,	ttbr1_el1
+	mrs	x11,	tcr_el1
+	mrs	x12,	esr_el1
+	mrs	x13, 	afsr0_el1
+	mrs	x14,	afsr1_el1
+	mrs	x15,	far_el1
+	mrs	x16,	mair_el1
+	mrs	x17,	vbar_el1
+	mrs	x18,	contextidr_el1
+	mrs	x19,	tpidr_el0
+	mrs	x20,	tpidrro_el0
+	mrs	x21,	tpidr_el1
+	mrs	x22, 	amair_el1
+	mrs	x23, 	cntkctl_el1
+
+	stp	x4, x5, [x3]
+	stp	x6, x7, [x3, #16]
+	stp	x8, x9, [x3, #32]
+	stp	x10, x11, [x3, #48]
+	stp	x12, x13, [x3, #64]
+	stp	x14, x15, [x3, #80]
+	stp	x16, x17, [x3, #96]
+	stp	x18, x19, [x3, #112]
+	stp	x20, x21, [x3, #128]
+	stp	x22, x23, [x3, #144]
+.endm
+
+.macro restore_sysregs
+	// x2: base address for cpu context
+	// x3: tmp register
+
+	add	x3, x2, #CPU_SYSREG_OFFSET(MPIDR_EL1)
+
+	ldp	x4, x5, [x3]
+	ldp	x6, x7, [x3, #16]
+	ldp	x8, x9, [x3, #32]
+	ldp	x10, x11, [x3, #48]
+	ldp	x12, x13, [x3, #64]
+	ldp	x14, x15, [x3, #80]
+	ldp	x16, x17, [x3, #96]
+	ldp	x18, x19, [x3, #112]
+	ldp	x20, x21, [x3, #128]
+	ldp	x22, x23, [x3, #144]
+
+	msr	vmpidr_el2,	x4
+	msr	csselr_el1,	x5
+	msr	sctlr_el1,	x6
+	msr	actlr_el1,	x7
+	msr	cpacr_el1,	x8
+	msr	ttbr0_el1,	x9
+	msr	ttbr1_el1,	x10
+	msr	tcr_el1,	x11
+	msr	esr_el1,	x12
+	msr	afsr0_el1,	x13
+	msr	afsr1_el1,	x14
+	msr	far_el1,	x15
+	msr	mair_el1,	x16
+	msr	vbar_el1,	x17
+	msr	contextidr_el1,	x18
+	msr	tpidr_el0,	x19
+	msr	tpidrro_el0,	x20
+	msr	tpidr_el1,	x21
+	msr	amair_el1,	x22
+	msr	cntkctl_el1,	x23
+.endm
+
+.macro activate_traps
+	ldr	x2, [x0, #VCPU_IRQ_LINES]
+	ldr	x1, [x0, #VCPU_HCR_EL2]
+	orr	x2, x2, x1
+	msr	hcr_el2, x2
+
+	ldr	x2, =(CPTR_EL2_TTA)
+	msr	cptr_el2, x2
+
+	ldr	x2, =(1 << 15)	// Trap CP15 Cr=15
+	msr	hstr_el2, x2
+
+	mrs	x2, mdcr_el2
+	and	x2, x2, #MDCR_EL2_HPMN_MASK
+	orr	x2, x2, #(MDCR_EL2_TPM | MDCR_EL2_TPMCR)
+	msr	mdcr_el2, x2
+.endm
+
+.macro deactivate_traps
+	mov	x2, #HCR_RW
+	msr	hcr_el2, x2
+	msr	cptr_el2, xzr
+	msr	hstr_el2, xzr
+
+	mrs	x2, mdcr_el2
+	and	x2, x2, #MDCR_EL2_HPMN_MASK
+	msr	mdcr_el2, x2
+.endm
+
+.macro activate_vm
+	ldr	x1, [x0, #VCPU_KVM]
+	kern_hyp_va	x1
+	ldr	x2, [x1, #KVM_VTTBR]
+	msr	vttbr_el2, x2
+.endm
+
+.macro deactivate_vm
+	msr	vttbr_el2, xzr
+.endm
+
+__save_sysregs:
+	save_sysregs
+	ret
+
+__restore_sysregs:
+	restore_sysregs
+	ret
+
+__save_fpsimd:
+	save_fpsimd
+	ret
+
+__restore_fpsimd:
+	restore_fpsimd
+	ret
+
+/*
+ * u64 __kvm_vcpu_run(struct kvm_vcpu *vcpu);
+ *
+ * This is the world switch. The first half of the function
+ * deals with entering the guest, and anything from __kvm_vcpu_return
+ * to the end of the function deals with reentering the host.
+ * On the enter path, only x0 (vcpu pointer) must be preserved until
+ * the last moment. On the exit path, x0 (vcpu pointer) and x1 (exception
+ * code) must both be preserved until the epilogue.
+ * In both cases, x2 points to the CPU context we're saving/restoring from/to.
+ */
+ENTRY(__kvm_vcpu_run)
+	kern_hyp_va	x0
+	msr	tpidr_el2, x0	// Save the vcpu register
+
+	// Host context
+	ldr	x2, [x0, #VCPU_HOST_CONTEXT]
+	kern_hyp_va x2
+
+	save_host_regs
+	bl __save_fpsimd
+	bl __save_sysregs
+
+	activate_traps
+	activate_vm
+
+	// Guest context
+	add	x2, x0, #VCPU_CONTEXT
+
+	bl __restore_sysregs
+	bl __restore_fpsimd
+	restore_guest_regs
+
+	// That's it, no more messing around.
+	clrex
+	eret
+
+__kvm_vcpu_return:
+	// Assume x0 is the vcpu pointer, x1 the return code
+	// Guest's x0-x3 are on the stack
+
+	// Guest context
+	add	x2, x0, #VCPU_CONTEXT
+
+	save_guest_regs
+	bl __save_fpsimd
+	bl __save_sysregs
+
+	deactivate_traps
+	deactivate_vm
+
+	// Host context
+	ldr	x2, [x0, #VCPU_HOST_CONTEXT]
+	kern_hyp_va x2
+
+	bl __restore_sysregs
+	bl __restore_fpsimd
+	restore_host_regs
+	mov	x0, x1
+	clrex
+	ret
+END(__kvm_vcpu_run)
+
+// void __kvm_tlb_flush_vmid_ipa(struct kvm *kvm, phys_addr_t ipa);
+ENTRY(__kvm_tlb_flush_vmid_ipa)
+	kern_hyp_va	x0
+	ldr	x2, [x0, #KVM_VTTBR]
+	msr	vttbr_el2, x2
+	isb
+
+	/*
+	 * We could do so much better if we had the VA as well.
+	 * Instead, we invalidate Stage-2 for this IPA, and the
+	 * whole of Stage-1. Weep...
+	 */
+	tlbi	ipas2e1is, x1
+	dsb	sy
+	tlbi	vmalle1is
+	dsb	sy
+	isb
+
+	msr	vttbr_el2, xzr
+	isb
+	ret
+ENDPROC(__kvm_tlb_flush_vmid_ipa)
+
+ENTRY(__kvm_flush_vm_context)
+	tlbi	alle1is
+	ic	ialluis
+	dsb	sy
+	isb
+	ret
+ENDPROC(__kvm_flush_vm_context)
+
+__kvm_hyp_panic:
+	adr	x0, __hyp_panic_str
+	adr	x1, 1f
+	ldp	x2, x3, [x1]
+	sub	x0, x0, x2
+	add	x0, x0, x3
+	mrs	x1, spsr_el2
+	mrs	x2, elr_el2
+	mrs	x3, esr_el2
+	mrs	x4, far_el2
+	mrs	x5, hpfar_el2
+	mrs	x6, tpidr_el2
+
+	mov	lr, #(PSR_F_BIT | PSR_I_BIT | PSR_A_BIT | PSR_D_BIT |\
+		      PSR_MODE_EL1h)
+	msr	spsr_el2, lr
+	ldr	lr, =panic
+	msr	elr_el2, lr
+	eret
+
+	.align	3
+1:	.quad	HYP_PAGE_OFFSET
+	.quad	PAGE_OFFSET
+ENDPROC(__kvm_hyp_panic)
+
+__hyp_panic_str:
+	.ascii	"HYP panic:\nPS:%08x PC:%p ESR:%p\nFAR:%p HPFAR:%p VCPU:%p\n\0"
+
+	.align	2
+
+ENTRY(kvm_call_hyp)
+	hvc	#0
+	ret
+ENDPROC(kvm_call_hyp)
+
+.macro invalid_vector	label, target
+	.align	2
+\label:
+	b \target
+ENDPROC(\label)
+.endm
+
+	/* None of these should ever happen */
+	invalid_vector	el2t_sync_invalid, __kvm_hyp_panic
+	invalid_vector	el2t_irq_invalid, __kvm_hyp_panic
+	invalid_vector	el2t_fiq_invalid, __kvm_hyp_panic
+	invalid_vector	el2t_error_invalid, __kvm_hyp_panic
+	invalid_vector	el2h_sync_invalid, __kvm_hyp_panic
+	invalid_vector	el2h_irq_invalid, __kvm_hyp_panic
+	invalid_vector	el2h_fiq_invalid, __kvm_hyp_panic
+	invalid_vector	el2h_error_invalid, __kvm_hyp_panic
+	invalid_vector	el1_sync_invalid, __kvm_hyp_panic
+	invalid_vector	el1_irq_invalid, __kvm_hyp_panic
+	invalid_vector	el1_fiq_invalid, __kvm_hyp_panic
+	invalid_vector	el1_error_invalid, __kvm_hyp_panic
+
+el1_sync:					// Guest trapped into EL2
+	push	x0, x1
+	push	x2, x3
+
+	mrs	x1, esr_el2
+	lsr	x2, x1, #ESR_EL2_EC_SHIFT
+
+	cmp	x2, #ESR_EL2_EC_HVC64
+	b.ne	el1_trap
+
+	mrs	x3, vttbr_el2			// If vttbr is valid, the 64bit guest
+	cbnz	x3, el1_trap			// called HVC
+
+	/* Here, we're pretty sure the host called HVC. */
+	pop	x2, x3
+	pop	x0, x1
+
+	push	lr, xzr
+
+	/*
+	 * Compute the function address in EL2, and shuffle the parameters.
+	 */
+	kern_hyp_va	x0
+	mov	lr, x0
+	mov	x0, x1
+	mov	x1, x2
+	mov	x2, x3
+	blr	lr
+
+	pop	lr, xzr
+	eret
+
+el1_trap:
+	/*
+	 * x1: ESR
+	 * x2: ESR_EC
+	 */
+	cmp	x2, #ESR_EL2_EC_DABT
+	mov	x0, #ESR_EL2_EC_IABT
+	ccmp	x2, x0, #4, ne
+	b.ne	1f		// Not an abort we care about
+
+	/* This is an abort. Check for permission fault */
+	and	x2, x1, #ESR_EL2_FSC_TYPE
+	cmp	x2, #FSC_PERM
+	b.ne	1f		// Not a permission fault
+
+	/*
+	 * Check for Stage-1 page table walk, which is guaranteed
+	 * to give a valid HPFAR_EL2.
+	 */
+	tbnz	x1, #7, 1f	// S1PTW is set
+
+	/*
+	 * Permission fault, HPFAR_EL2 is invalid.
+	 * Resolve the IPA the hard way using the guest VA.
+	 * We always perform an EL1 lookup, as we already
+	 * went through Stage-1.
+	 */
+	mrs	x3, far_el2
+	at	s1e1r, x3
+	isb
+
+	/* Read result */
+	mrs	x3, par_el1
+	tbnz	x3, #1, 3f		// Bail out if we failed the translation
+	ubfx	x3, x3, #12, #36	// Extract IPA
+	lsl	x3, x3, #4		// and present it like HPFAR
+	b	2f
+
+1:	mrs	x3, hpfar_el2
+
+2:	mrs	x0, tpidr_el2
+	mrs	x2, far_el2
+	str	x1, [x0, #VCPU_ESR_EL2]
+	str	x2, [x0, #VCPU_FAR_EL2]
+	str	x3, [x0, #VCPU_HPFAR_EL2]
+
+	mov	x1, #ARM_EXCEPTION_TRAP
+	b	__kvm_vcpu_return
+
+	/*
+	 * Translation failed. Just return to the guest and
+	 * let it fault again. Another CPU is probably playing
+	 * behind our back.
+	 */
+3:	pop	x2, x3
+	pop	x0, x1
+
+	eret
+
+el1_irq:
+	push	x0, x1
+	push	x2, x3
+	mrs	x0, tpidr_el2
+	mov	x1, #ARM_EXCEPTION_IRQ
+	b	__kvm_vcpu_return
+
+	.ltorg
+
+	.align 11
+
+ENTRY(__kvm_hyp_vector)
+	ventry	el2t_sync_invalid		// Synchronous EL2t
+	ventry	el2t_irq_invalid		// IRQ EL2t
+	ventry	el2t_fiq_invalid		// FIQ EL2t
+	ventry	el2t_error_invalid		// Error EL2t
+
+	ventry	el2h_sync_invalid		// Synchronous EL2h
+	ventry	el2h_irq_invalid		// IRQ EL2h
+	ventry	el2h_fiq_invalid		// FIQ EL2h
+	ventry	el2h_error_invalid		// Error EL2h
+
+	ventry	el1_sync			// Synchronous 64-bit EL1
+	ventry	el1_irq				// IRQ 64-bit EL1
+	ventry	el1_fiq_invalid			// FIQ 64-bit EL1
+	ventry	el1_error_invalid		// Error 64-bit EL1
+
+	ventry	el1_sync			// Synchronous 32-bit EL1
+	ventry	el1_irq				// IRQ 32-bit EL1
+	ventry	el1_fiq_invalid			// FIQ 32-bit EL1
+	ventry	el1_error_invalid		// Error 32-bit EL1
+ENDPROC(__kvm_hyp_vector)
+
+__kvm_hyp_code_end:
+	.globl	__kvm_hyp_code_end
+
+	.popsection
-- 
1.8.1.4




From marc.zyngier at arm.com  Mon Apr  8 12:17:20 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon,  8 Apr 2013 17:17:20 +0100
Subject: [PATCH v3 18/32] arm64: KVM: Exit handling
In-Reply-To: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1365437854-30214-19-git-send-email-marc.zyngier@arm.com>

Handle the exit of a VM, decoding the exit reason from HYP mode
and calling the corresponding handler.

Reviewed-by: Christopher Covington <cov at codeaurora.org>
Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/kvm/handle_exit.c | 119 +++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 119 insertions(+)
 create mode 100644 arch/arm64/kvm/handle_exit.c

diff --git a/arch/arm64/kvm/handle_exit.c b/arch/arm64/kvm/handle_exit.c
new file mode 100644
index 0000000..c65d115
--- /dev/null
+++ b/arch/arm64/kvm/handle_exit.c
@@ -0,0 +1,119 @@
+/*
+ * Copyright (C) 2012,2013 - ARM Ltd
+ * Author: Marc Zyngier <marc.zyngier at arm.com>
+ *
+ * Derived from arch/arm/kvm/handle_exit.c:
+ * Copyright (C) 2012 - Virtual Open Systems and Columbia University
+ * Author: Christoffer Dall <c.dall at virtualopensystems.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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <linux/kvm.h>
+#include <linux/kvm_host.h>
+#include <asm/kvm_emulate.h>
+#include <asm/kvm_coproc.h>
+#include <asm/kvm_mmu.h>
+
+typedef int (*exit_handle_fn)(struct kvm_vcpu *, struct kvm_run *);
+
+static int handle_hvc(struct kvm_vcpu *vcpu, struct kvm_run *run)
+{
+	/*
+	 * Guest called HVC instruction:
+	 * Let it know we don't want that by injecting an undefined exception.
+	 */
+	kvm_debug("hvc: %x (at %08lx)", kvm_vcpu_get_hsr(vcpu) & ((1 << 16) - 1),
+		  *vcpu_pc(vcpu));
+	kvm_debug("         HSR: %8x", kvm_vcpu_get_hsr(vcpu));
+	kvm_inject_undefined(vcpu);
+	return 1;
+}
+
+static int handle_smc(struct kvm_vcpu *vcpu, struct kvm_run *run)
+{
+	/* We don't support SMC; don't do that. */
+	kvm_debug("smc: at %08lx", *vcpu_pc(vcpu));
+	kvm_inject_undefined(vcpu);
+	return 1;
+}
+
+/**
+ * kvm_handle_wfi - handle a wait-for-interrupts instruction executed by a guest
+ * @vcpu:	the vcpu pointer
+ *
+ * Simply call kvm_vcpu_block(), which will halt execution of
+ * world-switches and schedule other host processes until there is an
+ * incoming IRQ or FIQ to the VM.
+ */
+static int kvm_handle_wfi(struct kvm_vcpu *vcpu, struct kvm_run *run)
+{
+	kvm_vcpu_block(vcpu);
+	return 1;
+}
+
+static exit_handle_fn arm_exit_handlers[] = {
+	[ESR_EL2_EC_WFI]	= kvm_handle_wfi,
+	[ESR_EL2_EC_HVC64]	= handle_hvc,
+	[ESR_EL2_EC_SMC64]	= handle_smc,
+	[ESR_EL2_EC_SYS64]	= kvm_handle_sys_reg,
+	[ESR_EL2_EC_IABT]	= kvm_handle_guest_abort,
+	[ESR_EL2_EC_DABT]	= kvm_handle_guest_abort,
+};
+
+static exit_handle_fn kvm_get_exit_handler(struct kvm_vcpu *vcpu)
+{
+	u8 hsr_ec = kvm_vcpu_trap_get_class(vcpu);
+
+	if (hsr_ec >= ARRAY_SIZE(arm_exit_handlers) ||
+	    !arm_exit_handlers[hsr_ec]) {
+		kvm_err("Unkown exception class: hsr: %#08x\n",
+			(unsigned int)kvm_vcpu_get_hsr(vcpu));
+		BUG();
+	}
+
+	return arm_exit_handlers[hsr_ec];
+}
+
+/*
+ * Return > 0 to return to guest, < 0 on error, 0 (and set exit_reason) on
+ * proper exit to userspace.
+ */
+int handle_exit(struct kvm_vcpu *vcpu, struct kvm_run *run,
+		       int exception_index)
+{
+	exit_handle_fn exit_handler;
+
+	switch (exception_index) {
+	case ARM_EXCEPTION_IRQ:
+		return 1;
+	case ARM_EXCEPTION_TRAP:
+		/*
+		 * See ARM ARM B1.14.1: "Hyp traps on instructions
+		 * that fail their condition code check"
+		 */
+		if (!kvm_condition_valid(vcpu)) {
+			kvm_skip_instr(vcpu, kvm_vcpu_trap_il_is32bit(vcpu));
+			return 1;
+		}
+
+		exit_handler = kvm_get_exit_handler(vcpu);
+
+		return exit_handler(vcpu, run);
+	default:
+		kvm_pr_unimpl("Unsupported exception type: %d",
+			      exception_index);
+		run->exit_reason = KVM_EXIT_INTERNAL_ERROR;
+		return 0;
+	}
+}
-- 
1.8.1.4




From marc.zyngier at arm.com  Mon Apr  8 12:17:27 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon,  8 Apr 2013 17:17:27 +0100
Subject: [PATCH v3 25/32] arm64: KVM: 32bit conditional execution emulation
In-Reply-To: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1365437854-30214-26-git-send-email-marc.zyngier@arm.com>

As conditional instructions can trap on AArch32, add the thinest
possible emulation layer to keep 32bit guests happy.

Reviewed-by: Christopher Covington <cov at codeaurora.org>
Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/include/asm/kvm_emulate.h |  13 ++-
 arch/arm64/kvm/Makefile              |   2 +-
 arch/arm64/kvm/emulate.c             | 154 +++++++++++++++++++++++++++++++++++
 3 files changed, 166 insertions(+), 3 deletions(-)
 create mode 100644 arch/arm64/kvm/emulate.c

diff --git a/arch/arm64/include/asm/kvm_emulate.h b/arch/arm64/include/asm/kvm_emulate.h
index 37a6567..8d4ab33 100644
--- a/arch/arm64/include/asm/kvm_emulate.h
+++ b/arch/arm64/include/asm/kvm_emulate.h
@@ -31,6 +31,9 @@
 unsigned long *vcpu_reg32(const struct kvm_vcpu *vcpu, u8 reg_num);
 unsigned long *vcpu_spsr32(const struct kvm_vcpu *vcpu);
 
+bool kvm_condition_valid32(const struct kvm_vcpu *vcpu);
+void kvm_skip_instr32(struct kvm_vcpu *vcpu, bool is_wide_instr);
+
 void kvm_inject_undefined(struct kvm_vcpu *vcpu);
 void kvm_inject_dabt(struct kvm_vcpu *vcpu, unsigned long addr);
 void kvm_inject_pabt(struct kvm_vcpu *vcpu, unsigned long addr);
@@ -57,12 +60,18 @@ static inline bool vcpu_mode_is_32bit(const struct kvm_vcpu *vcpu)
 
 static inline bool kvm_condition_valid(const struct kvm_vcpu *vcpu)
 {
-	return true;	/* No conditionals on arm64 */
+	if (vcpu_mode_is_32bit(vcpu))
+		return kvm_condition_valid32(vcpu);
+
+	return true;
 }
 
 static inline void kvm_skip_instr(struct kvm_vcpu *vcpu, bool is_wide_instr)
 {
-	*vcpu_pc(vcpu) += 4;
+	if (vcpu_mode_is_32bit(vcpu))
+		kvm_skip_instr32(vcpu, is_wide_instr);
+	else
+		*vcpu_pc(vcpu) += 4;
 }
 
 static inline void vcpu_set_thumb(struct kvm_vcpu *vcpu)
diff --git a/arch/arm64/kvm/Makefile b/arch/arm64/kvm/Makefile
index 1668448..88c6639 100644
--- a/arch/arm64/kvm/Makefile
+++ b/arch/arm64/kvm/Makefile
@@ -11,7 +11,7 @@ obj-$(CONFIG_KVM_ARM_HOST) += kvm.o
 kvm-$(CONFIG_KVM_ARM_HOST) += $(addprefix ../../../virt/kvm/, kvm_main.o coalesced_mmio.o)
 kvm-$(CONFIG_KVM_ARM_HOST) += $(addprefix ../../../arch/arm/kvm/, arm.o mmu.o mmio.o psci.o perf.o)
 
-kvm-$(CONFIG_KVM_ARM_HOST) += inject_fault.o regmap.o
+kvm-$(CONFIG_KVM_ARM_HOST) += emulate.o inject_fault.o regmap.o
 kvm-$(CONFIG_KVM_ARM_HOST) += hyp.o hyp-init.o handle_exit.o
 kvm-$(CONFIG_KVM_ARM_HOST) += guest.o reset.o sys_regs.o sys_regs_generic_v8.o
 
diff --git a/arch/arm64/kvm/emulate.c b/arch/arm64/kvm/emulate.c
new file mode 100644
index 0000000..01d4713
--- /dev/null
+++ b/arch/arm64/kvm/emulate.c
@@ -0,0 +1,154 @@
+/*
+ * (not much of an) Emulation layer for 32bit guests.
+ *
+ * Copyright (C) 2012 - Virtual Open Systems and Columbia University
+ * Author: Christoffer Dall <c.dall at virtualopensystems.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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <linux/kvm_host.h>
+#include <asm/kvm_emulate.h>
+
+/*
+ * stolen from arch/arm/kernel/opcodes.c
+ *
+ * condition code lookup table
+ * index into the table is test code: EQ, NE, ... LT, GT, AL, NV
+ *
+ * bit position in short is condition code: NZCV
+ */
+static const unsigned short cc_map[16] = {
+	0xF0F0,			/* EQ == Z set            */
+	0x0F0F,			/* NE                     */
+	0xCCCC,			/* CS == C set            */
+	0x3333,			/* CC                     */
+	0xFF00,			/* MI == N set            */
+	0x00FF,			/* PL                     */
+	0xAAAA,			/* VS == V set            */
+	0x5555,			/* VC                     */
+	0x0C0C,			/* HI == C set && Z clear */
+	0xF3F3,			/* LS == C clear || Z set */
+	0xAA55,			/* GE == (N==V)           */
+	0x55AA,			/* LT == (N!=V)           */
+	0x0A05,			/* GT == (!Z && (N==V))   */
+	0xF5FA,			/* LE == (Z || (N!=V))    */
+	0xFFFF,			/* AL always              */
+	0			/* NV                     */
+};
+
+static int kvm_vcpu_get_condition(const struct kvm_vcpu *vcpu)
+{
+	u32 esr = kvm_vcpu_get_hsr(vcpu);
+
+	if (esr & ESR_EL2_CV)
+		return (esr & ESR_EL2_COND) >> ESR_EL2_COND_SHIFT;
+
+	return -1;
+}
+
+/*
+ * Check if a trapped instruction should have been executed or not.
+ */
+bool kvm_condition_valid32(const struct kvm_vcpu *vcpu)
+{
+	unsigned long cpsr;
+	u32 cpsr_cond;
+	int cond;
+
+	/* Top two bits non-zero?  Unconditional. */
+	if (kvm_vcpu_get_hsr(vcpu) >> 30)
+		return true;
+
+	/* Is condition field valid? */
+	cond = kvm_vcpu_get_condition(vcpu);
+	if (cond == 0xE)
+		return true;
+
+	cpsr = *vcpu_cpsr(vcpu);
+
+	if (cond < 0) {
+		/* This can happen in Thumb mode: examine IT state. */
+		unsigned long it;
+
+		it = ((cpsr >> 8) & 0xFC) | ((cpsr >> 25) & 0x3);
+
+		/* it == 0 => unconditional. */
+		if (it == 0)
+			return true;
+
+		/* The cond for this insn works out as the top 4 bits. */
+		cond = (it >> 4);
+	}
+
+	cpsr_cond = cpsr >> 28;
+
+	if (!((cc_map[cond] >> cpsr_cond) & 1))
+		return false;
+
+	return true;
+}
+
+/**
+ * adjust_itstate - adjust ITSTATE when emulating instructions in IT-block
+ * @vcpu:	The VCPU pointer
+ *
+ * When exceptions occur while instructions are executed in Thumb IF-THEN
+ * blocks, the ITSTATE field of the CPSR is not advanved (updated), so we have
+ * to do this little bit of work manually. The fields map like this:
+ *
+ * IT[7:0] -> CPSR[26:25],CPSR[15:10]
+ */
+static void kvm_adjust_itstate(struct kvm_vcpu *vcpu)
+{
+	unsigned long itbits, cond;
+	unsigned long cpsr = *vcpu_cpsr(vcpu);
+	bool is_arm = !(cpsr & COMPAT_PSR_T_BIT);
+
+	BUG_ON(is_arm && (cpsr & COMPAT_PSR_IT_MASK));
+
+	if (!(cpsr & COMPAT_PSR_IT_MASK))
+		return;
+
+	cond = (cpsr & 0xe000) >> 13;
+	itbits = (cpsr & 0x1c00) >> (10 - 2);
+	itbits |= (cpsr & (0x3 << 25)) >> 25;
+
+	/* Perform ITAdvance (see page A-52 in ARM DDI 0406C) */
+	if ((itbits & 0x7) == 0)
+		itbits = cond = 0;
+	else
+		itbits = (itbits << 1) & 0x1f;
+
+	cpsr &= ~COMPAT_PSR_IT_MASK;
+	cpsr |= cond << 13;
+	cpsr |= (itbits & 0x1c) << (10 - 2);
+	cpsr |= (itbits & 0x3) << 25;
+	*vcpu_cpsr(vcpu) = cpsr;
+}
+
+/**
+ * kvm_skip_instr - skip a trapped instruction and proceed to the next
+ * @vcpu: The vcpu pointer
+ */
+void kvm_skip_instr32(struct kvm_vcpu *vcpu, bool is_wide_instr)
+{
+	bool is_thumb;
+
+	is_thumb = !!(*vcpu_cpsr(vcpu) & COMPAT_PSR_T_BIT);
+	if (is_thumb && !is_wide_instr)
+		*vcpu_pc(vcpu) += 2;
+	else
+		*vcpu_pc(vcpu) += 4;
+	kvm_adjust_itstate(vcpu);
+}
-- 
1.8.1.4




From marc.zyngier at arm.com  Mon Apr  8 12:17:09 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon,  8 Apr 2013 17:17:09 +0100
Subject: [PATCH v3 07/32] arm64: KVM: fault injection into a guest
In-Reply-To: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1365437854-30214-8-git-send-email-marc.zyngier@arm.com>

Implement the injection of a fault (undefined, data abort or
prefetch abort) into a 64bit guest.

Reviewed-by: Christopher Covington <cov at codeaurora.org>
Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/kvm/inject_fault.c | 118 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 118 insertions(+)
 create mode 100644 arch/arm64/kvm/inject_fault.c

diff --git a/arch/arm64/kvm/inject_fault.c b/arch/arm64/kvm/inject_fault.c
new file mode 100644
index 0000000..2ff3b78
--- /dev/null
+++ b/arch/arm64/kvm/inject_fault.c
@@ -0,0 +1,118 @@
+/*
+ * Fault injection for 64bit guests.
+ *
+ * Copyright (C) 2012,2013 - ARM Ltd
+ * Author: Marc Zyngier <marc.zyngier at arm.com>
+ *
+ * Based on arch/arm/kvm/emulate.c
+ * Copyright (C) 2012 - Virtual Open Systems and Columbia University
+ * Author: Christoffer Dall <c.dall at virtualopensystems.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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <linux/kvm_host.h>
+#include <asm/kvm_emulate.h>
+#include <asm/esr.h>
+
+static void inject_abt64(struct kvm_vcpu *vcpu, bool is_iabt, unsigned long addr)
+{
+	unsigned long cpsr = *vcpu_cpsr(vcpu);
+	int is_aarch32;
+	u32 esr = 0;
+
+	is_aarch32 = vcpu_mode_is_32bit(vcpu);
+
+	*vcpu_spsr(vcpu) = cpsr;
+	*vcpu_elr_el1(vcpu) = *vcpu_pc(vcpu);
+
+	*vcpu_cpsr(vcpu) = PSR_MODE_EL1h | PSR_A_BIT | PSR_F_BIT | PSR_I_BIT;
+	*vcpu_pc(vcpu) = vcpu_sys_reg(vcpu, VBAR_EL1) + 0x200;
+
+	vcpu_sys_reg(vcpu, FAR_EL1) = addr;
+
+	/*
+	 * Build an {i,d}abort, depending on the level and the
+	 * instruction set. Report an external synchronous abort.
+	 */
+	if (kvm_vcpu_trap_il_is32bit(vcpu))
+		esr |= ESR_EL1_IL;
+
+	if (is_aarch32 || (cpsr & PSR_MODE_MASK) == PSR_MODE_EL0t)
+		esr |= (ESR_EL1_EC_IABT_EL0 << ESR_EL1_EC_SHIFT);
+	else
+		esr |= (ESR_EL1_EC_IABT_EL1 << ESR_EL1_EC_SHIFT);
+
+	if (!is_iabt)
+		esr |= ESR_EL1_EC_DABT_EL0;
+
+	vcpu_sys_reg(vcpu, ESR_EL1) = esr | 0x10; /* External abort */
+}
+
+static void inject_undef64(struct kvm_vcpu *vcpu)
+{
+	unsigned long cpsr = *vcpu_cpsr(vcpu);
+	u32 esr = (ESR_EL1_EC_UNKNOWN << ESR_EL1_EC_SHIFT);
+
+	*vcpu_spsr(vcpu) = cpsr;
+	*vcpu_elr_el1(vcpu) = *vcpu_pc(vcpu);
+
+	*vcpu_cpsr(vcpu) = PSR_MODE_EL1h | PSR_F_BIT | PSR_I_BIT;
+	*vcpu_pc(vcpu) = vcpu_sys_reg(vcpu, VBAR_EL1) + 0x200;
+
+	/*
+	 * Build an unknown exception, depending on the instruction
+	 * set.
+	 */
+	if (kvm_vcpu_trap_il_is32bit(vcpu))
+		esr |= ESR_EL1_IL;
+
+	vcpu_sys_reg(vcpu, ESR_EL1) = esr;
+}
+
+/**
+ * kvm_inject_dabt - inject a data abort into the guest
+ * @vcpu: The VCPU to receive the undefined exception
+ * @addr: The address to report in the DFAR
+ *
+ * It is assumed that this code is called from the VCPU thread and that the
+ * VCPU therefore is not currently executing guest code.
+ */
+void kvm_inject_dabt(struct kvm_vcpu *vcpu, unsigned long addr)
+{
+	inject_abt64(vcpu, false, addr);
+}
+
+/**
+ * kvm_inject_pabt - inject a prefetch abort into the guest
+ * @vcpu: The VCPU to receive the undefined exception
+ * @addr: The address to report in the DFAR
+ *
+ * It is assumed that this code is called from the VCPU thread and that the
+ * VCPU therefore is not currently executing guest code.
+ */
+void kvm_inject_pabt(struct kvm_vcpu *vcpu, unsigned long addr)
+{
+	inject_abt64(vcpu, true, addr);
+}
+
+/**
+ * kvm_inject_undefined - inject an undefined instruction into the guest
+ *
+ * It is assumed that this code is called from the VCPU thread and that the
+ * VCPU therefore is not currently executing guest code.
+ */
+void kvm_inject_undefined(struct kvm_vcpu *vcpu)
+{
+	inject_undef64(vcpu);
+}
-- 
1.8.1.4




From marc.zyngier at arm.com  Mon Apr  8 12:17:17 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon,  8 Apr 2013 17:17:17 +0100
Subject: [PATCH v3 15/32] arm64: KVM: guest one-reg interface
In-Reply-To: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1365437854-30214-16-git-send-email-marc.zyngier@arm.com>

Let userspace play with the guest registers.

Reviewed-by: Christopher Covington <cov at codeaurora.org>
Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/kvm/guest.c | 254 +++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 254 insertions(+)
 create mode 100644 arch/arm64/kvm/guest.c

diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
new file mode 100644
index 0000000..47d3729
--- /dev/null
+++ b/arch/arm64/kvm/guest.c
@@ -0,0 +1,254 @@
+/*
+ * Copyright (C) 2012,2013 - ARM Ltd
+ * Author: Marc Zyngier <marc.zyngier at arm.com>
+ *
+ * Derived from arch/arm/kvm/guest.c:
+ * Copyright (C) 2012 - Virtual Open Systems and Columbia University
+ * Author: Christoffer Dall <c.dall at virtualopensystems.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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <linux/errno.h>
+#include <linux/err.h>
+#include <linux/kvm_host.h>
+#include <linux/module.h>
+#include <linux/vmalloc.h>
+#include <linux/fs.h>
+#include <asm/cputype.h>
+#include <asm/uaccess.h>
+#include <asm/kvm.h>
+#include <asm/kvm_asm.h>
+#include <asm/kvm_emulate.h>
+#include <asm/kvm_coproc.h>
+
+struct kvm_stats_debugfs_item debugfs_entries[] = {
+	{ NULL }
+};
+
+int kvm_arch_vcpu_setup(struct kvm_vcpu *vcpu)
+{
+	vcpu->arch.hcr_el2 = HCR_GUEST_FLAGS;
+	return 0;
+}
+
+static u64 core_reg_offset_from_id(u64 id)
+{
+	return id & ~(KVM_REG_ARCH_MASK | KVM_REG_SIZE_MASK | KVM_REG_ARM_CORE);
+}
+
+static int get_core_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
+{
+	__u32 __user *uaddr = (__u32 __user *)(unsigned long)reg->addr;
+	struct kvm_regs *regs = vcpu_gp_regs(vcpu);
+	int nr_regs = sizeof(*regs) / sizeof(__u32);
+	u32 off;
+
+	/* Our ID is an index into the kvm_regs struct. */
+	off = core_reg_offset_from_id(reg->id);
+	if (off >= nr_regs ||
+	    (off + (KVM_REG_SIZE(reg->id) / sizeof(__u32))) >= nr_regs)
+		return -ENOENT;
+
+	if (copy_to_user(uaddr, ((u32 *)regs) + off, KVM_REG_SIZE(reg->id)))
+		return -EFAULT;
+
+	return 0;
+}
+
+static int set_core_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
+{
+	__u32 __user *uaddr = (__u32 __user *)(unsigned long)reg->addr;
+	struct kvm_regs *regs = vcpu_gp_regs(vcpu);
+	int nr_regs = sizeof(*regs) / sizeof(__u32);
+	void *valp;
+	u64 off;
+	int err = 0;
+
+	/* Our ID is an index into the kvm_regs struct. */
+	off = core_reg_offset_from_id(reg->id);
+	if (off >= nr_regs ||
+	    (off + (KVM_REG_SIZE(reg->id) / sizeof(__u32))) >= nr_regs)
+		return -ENOENT;
+
+	valp = kmalloc(KVM_REG_SIZE(reg->id), GFP_KERNEL);
+	if (!valp)
+		return -ENOMEM;
+
+	if (copy_from_user(valp, uaddr, KVM_REG_SIZE(reg->id))) {
+		err = -EFAULT;
+		goto out;
+	}
+
+	if (off == KVM_REG_ARM_CORE_REG(regs.pstate)) {
+		unsigned long mode = (*(unsigned long *)valp) & COMPAT_PSR_MODE_MASK;
+		switch (mode) {
+		case PSR_MODE_EL0t:
+		case PSR_MODE_EL1t:
+		case PSR_MODE_EL1h:
+			break;
+		default:
+			err = -EINVAL;
+			goto out;
+		}
+	}
+
+	memcpy((u32 *)regs + off, valp, KVM_REG_SIZE(reg->id));
+out:
+	kfree(valp);
+	return err;
+}
+
+int kvm_arch_vcpu_ioctl_get_regs(struct kvm_vcpu *vcpu, struct kvm_regs *regs)
+{
+	return -EINVAL;
+}
+
+int kvm_arch_vcpu_ioctl_set_regs(struct kvm_vcpu *vcpu, struct kvm_regs *regs)
+{
+	return -EINVAL;
+}
+
+static unsigned long num_core_regs(void)
+{
+	return sizeof(struct kvm_regs) / sizeof(unsigned long);
+}
+
+/**
+ * kvm_arm_num_regs - how many registers do we present via KVM_GET_ONE_REG
+ *
+ * This is for all registers.
+ */
+unsigned long kvm_arm_num_regs(struct kvm_vcpu *vcpu)
+{
+	return num_core_regs() + kvm_arm_num_sys_reg_descs(vcpu);
+}
+
+/**
+ * kvm_arm_copy_reg_indices - get indices of all registers.
+ *
+ * We do core registers right here, then we apppend system regs.
+ */
+int kvm_arm_copy_reg_indices(struct kvm_vcpu *vcpu, u64 __user *uindices)
+{
+	unsigned int i;
+	const u64 core_reg = KVM_REG_ARM64 | KVM_REG_SIZE_U64 | KVM_REG_ARM_CORE;
+
+	for (i = 0; i < sizeof(struct kvm_regs)/sizeof(unsigned long); i++) {
+		if (put_user(core_reg | i, uindices))
+			return -EFAULT;
+		uindices++;
+	}
+
+	return kvm_arm_copy_sys_reg_indices(vcpu, uindices);
+}
+
+int kvm_arm_get_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
+{
+	/* We currently use nothing arch-specific in upper 32 bits */
+	if ((reg->id & ~KVM_REG_SIZE_MASK) >> 32 != KVM_REG_ARM64 >> 32)
+		return -EINVAL;
+
+	/* Register group 16 means we want a core register. */
+	if ((reg->id & KVM_REG_ARM_COPROC_MASK) == KVM_REG_ARM_CORE)
+		return get_core_reg(vcpu, reg);
+
+	return kvm_arm_sys_reg_get_reg(vcpu, reg);
+}
+
+int kvm_arm_set_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
+{
+	/* We currently use nothing arch-specific in upper 32 bits */
+	if ((reg->id & ~KVM_REG_SIZE_MASK) >> 32 != KVM_REG_ARM64 >> 32)
+		return -EINVAL;
+
+	/* Register group 16 means we set a core register. */
+	if ((reg->id & KVM_REG_ARM_COPROC_MASK) == KVM_REG_ARM_CORE)
+		return set_core_reg(vcpu, reg);
+
+	return kvm_arm_sys_reg_set_reg(vcpu, reg);
+}
+
+int kvm_arch_vcpu_ioctl_get_sregs(struct kvm_vcpu *vcpu,
+				  struct kvm_sregs *sregs)
+{
+	return -EINVAL;
+}
+
+int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu,
+				  struct kvm_sregs *sregs)
+{
+	return -EINVAL;
+}
+
+int __attribute_const__ kvm_target_cpu(void)
+{
+	unsigned long implementor = read_cpuid_implementor();
+	unsigned long part_number = read_cpuid_part_number();
+
+	if (implementor != ARM_CPU_IMP_ARM)
+		return -EINVAL;
+
+	switch (part_number) {
+	case ARM_CPU_PART_AEM_V8:
+		return KVM_ARM_TARGET_AEM_V8;
+	case ARM_CPU_PART_FOUNDATION:
+		return KVM_ARM_TARGET_FOUNDATION_V8;
+	case ARM_CPU_PART_CORTEX_A57:
+		/* Currently handled by the generic backend */
+		return KVM_ARM_TARGET_CORTEX_A57;
+	default:
+		return -EINVAL;
+	}
+}
+
+int kvm_vcpu_set_target(struct kvm_vcpu *vcpu,
+			const struct kvm_vcpu_init *init)
+{
+	unsigned int i;
+	int phys_target = kvm_target_cpu();
+
+	if (init->target != phys_target)
+		return -EINVAL;
+
+	vcpu->arch.target = phys_target;
+	bitmap_zero(vcpu->arch.features, KVM_VCPU_MAX_FEATURES);
+
+	/* -ENOENT for unknown features, -EINVAL for invalid combinations. */
+	for (i = 0; i < sizeof(init->features)*8; i++) {
+		if (init->features[i / 32] & (1 << (i % 32))) {
+			if (i >= KVM_VCPU_MAX_FEATURES)
+				return -ENOENT;
+			set_bit(i, vcpu->arch.features);
+		}
+	}
+
+	/* Now we know what it is, we can reset it. */
+	return kvm_reset_vcpu(vcpu);
+}
+
+int kvm_arch_vcpu_ioctl_get_fpu(struct kvm_vcpu *vcpu, struct kvm_fpu *fpu)
+{
+	return -EINVAL;
+}
+
+int kvm_arch_vcpu_ioctl_set_fpu(struct kvm_vcpu *vcpu, struct kvm_fpu *fpu)
+{
+	return -EINVAL;
+}
+
+int kvm_arch_vcpu_ioctl_translate(struct kvm_vcpu *vcpu,
+				  struct kvm_translation *tr)
+{
+	return -EINVAL;
+}
-- 
1.8.1.4




From marc.zyngier at arm.com  Mon Apr  8 12:17:24 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon,  8 Apr 2013 17:17:24 +0100
Subject: [PATCH v3 22/32] arm64: KVM: Build system integration
In-Reply-To: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1365437854-30214-23-git-send-email-marc.zyngier@arm.com>

Reviewed-by: Christopher Covington <cov at codeaurora.org>
Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/Kconfig      |  2 ++
 arch/arm64/Makefile     |  2 +-
 arch/arm64/kvm/Kconfig  | 59 +++++++++++++++++++++++++++++++++++++++++++++++++
 arch/arm64/kvm/Makefile | 19 ++++++++++++++++
 4 files changed, 81 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm64/kvm/Kconfig
 create mode 100644 arch/arm64/kvm/Makefile

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 43b0e9f..d984a46 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -240,6 +240,8 @@ source "drivers/Kconfig"
 
 source "fs/Kconfig"
 
+source "arch/arm64/kvm/Kconfig"
+
 source "arch/arm64/Kconfig.debug"
 
 source "security/Kconfig"
diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
index c95c5cb..ae89e63 100644
--- a/arch/arm64/Makefile
+++ b/arch/arm64/Makefile
@@ -36,7 +36,7 @@ TEXT_OFFSET := 0x00080000
 
 export	TEXT_OFFSET GZFLAGS
 
-core-y		+= arch/arm64/kernel/ arch/arm64/mm/
+core-y		+= arch/arm64/kernel/ arch/arm64/mm/ arch/arm64/kvm/
 libs-y		:= arch/arm64/lib/ $(libs-y)
 libs-y		+= $(LIBGCC)
 
diff --git a/arch/arm64/kvm/Kconfig b/arch/arm64/kvm/Kconfig
new file mode 100644
index 0000000..a76be8b
--- /dev/null
+++ b/arch/arm64/kvm/Kconfig
@@ -0,0 +1,59 @@
+#
+# KVM configuration
+#
+
+source "virt/kvm/Kconfig"
+
+menuconfig VIRTUALIZATION
+	bool "Virtualization"
+	---help---
+	  Say Y here to get to see options for using your Linux host to run
+	  other operating systems inside virtual machines (guests).
+	  This option alone does not add any kernel code.
+
+	  If you say N, all options in this submenu will be skipped and
+	  disabled.
+
+if VIRTUALIZATION
+
+config KVM
+	bool "Kernel-based Virtual Machine (KVM) support"
+	select PREEMPT_NOTIFIERS
+	select ANON_INODES
+	select KVM_MMIO
+	select KVM_ARM_HOST
+	select KVM_ARM_VGIC
+	select KVM_ARM_TIMER
+	---help---
+	  Support hosting virtualized guest machines.
+
+	  This module provides access to the hardware capabilities through
+	  a character device node named /dev/kvm.
+
+	  If unsure, say N.
+
+config KVM_ARM_HOST
+	bool
+	depends on KVM
+	depends on MMU
+	select	MMU_NOTIFIER
+	---help---
+	  Provides host support for ARM processors.
+
+config KVM_ARM_VGIC
+        bool
+	depends on KVM_ARM_HOST && OF
+	select HAVE_KVM_IRQCHIP
+	---help---
+	  Adds support for a hardware assisted, in-kernel GIC emulation.
+
+config KVM_ARM_TIMER
+        bool
+	depends on KVM_ARM_VGIC
+	select HAVE_KVM_IRQCHIP
+	---help---
+	  Adds support for the Architected Timers in virtual machines
+
+source drivers/virtio/Kconfig
+
+endif # VIRTUALIZATION
diff --git a/arch/arm64/kvm/Makefile b/arch/arm64/kvm/Makefile
new file mode 100644
index 0000000..be9eb3833
--- /dev/null
+++ b/arch/arm64/kvm/Makefile
@@ -0,0 +1,19 @@
+#
+# Makefile for Kernel-based Virtual Machine module
+#
+
+ccflags-y += -Ivirt/kvm -Iarch/arm64/kvm
+CFLAGS_arm.o := -I.
+CFLAGS_mmu.o := -I.
+
+obj-$(CONFIG_KVM_ARM_HOST) += kvm.o
+
+kvm-$(CONFIG_KVM_ARM_HOST) += $(addprefix ../../../virt/kvm/, kvm_main.o coalesced_mmio.o)
+kvm-$(CONFIG_KVM_ARM_HOST) += $(addprefix ../../../arch/arm/kvm/, arm.o mmu.o mmio.o psci.o perf.o)
+
+kvm-$(CONFIG_KVM_ARM_HOST) += inject_fault.o
+kvm-$(CONFIG_KVM_ARM_HOST) += hyp.o hyp-init.o handle_exit.o
+kvm-$(CONFIG_KVM_ARM_HOST) += guest.o reset.o sys_regs.o sys_regs_generic_v8.o
+
+kvm-$(CONFIG_KVM_ARM_VGIC) += $(addprefix ../../../arch/arm/kvm/, vgic.o)
+kvm-$(CONFIG_KVM_ARM_TIMER) += $(addprefix ../../../arch/arm/kvm/, arch_timer.o)
-- 
1.8.1.4




From marc.zyngier at arm.com  Mon Apr  8 12:17:26 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon,  8 Apr 2013 17:17:26 +0100
Subject: [PATCH v3 24/32] arm64: KVM: 32bit GP register access
In-Reply-To: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1365437854-30214-25-git-send-email-marc.zyngier@arm.com>

Allow access to the 32bit register file through the usual API.

Reviewed-by: Christopher Covington <cov at codeaurora.org>
Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/include/asm/kvm_emulate.h |  17 +++-
 arch/arm64/kvm/Makefile              |   2 +-
 arch/arm64/kvm/regmap.c              | 168 +++++++++++++++++++++++++++++++++++
 3 files changed, 184 insertions(+), 3 deletions(-)
 create mode 100644 arch/arm64/kvm/regmap.c

diff --git a/arch/arm64/include/asm/kvm_emulate.h b/arch/arm64/include/asm/kvm_emulate.h
index 2dcfa74..37a6567 100644
--- a/arch/arm64/include/asm/kvm_emulate.h
+++ b/arch/arm64/include/asm/kvm_emulate.h
@@ -28,6 +28,9 @@
 #include <asm/kvm_mmio.h>
 #include <asm/ptrace.h>
 
+unsigned long *vcpu_reg32(const struct kvm_vcpu *vcpu, u8 reg_num);
+unsigned long *vcpu_spsr32(const struct kvm_vcpu *vcpu);
+
 void kvm_inject_undefined(struct kvm_vcpu *vcpu);
 void kvm_inject_dabt(struct kvm_vcpu *vcpu, unsigned long addr);
 void kvm_inject_pabt(struct kvm_vcpu *vcpu, unsigned long addr);
@@ -49,7 +52,7 @@ static inline unsigned long *vcpu_cpsr(const struct kvm_vcpu *vcpu)
 
 static inline bool vcpu_mode_is_32bit(const struct kvm_vcpu *vcpu)
 {
-	return false;	/* 32bit? Bahhh... */
+	return !!(*vcpu_cpsr(vcpu) & PSR_MODE32_BIT);
 }
 
 static inline bool kvm_condition_valid(const struct kvm_vcpu *vcpu)
@@ -64,28 +67,38 @@ static inline void kvm_skip_instr(struct kvm_vcpu *vcpu, bool is_wide_instr)
 
 static inline void vcpu_set_thumb(struct kvm_vcpu *vcpu)
 {
+	*vcpu_cpsr(vcpu) |= COMPAT_PSR_T_BIT;
 }
 
 static inline unsigned long *vcpu_reg(const struct kvm_vcpu *vcpu, u8 reg_num)
 {
+	if (vcpu_mode_is_32bit(vcpu))
+		return vcpu_reg32(vcpu, reg_num);
+
 	return (unsigned long *)&vcpu_gp_regs(vcpu)->regs.regs[reg_num];
 }
 
 /* Get vcpu SPSR for current mode */
 static inline unsigned long *vcpu_spsr(const struct kvm_vcpu *vcpu)
 {
+	if (vcpu_mode_is_32bit(vcpu))
+		return vcpu_spsr32(vcpu);
+
 	return (unsigned long *)&vcpu_gp_regs(vcpu)->spsr[KVM_SPSR_EL1];
 }
 
 static inline bool kvm_vcpu_reg_is_pc(const struct kvm_vcpu *vcpu, int reg)
 {
-	return false;
+	return (vcpu_mode_is_32bit(vcpu)) && reg == 15;
 }
 
 static inline bool vcpu_mode_priv(const struct kvm_vcpu *vcpu)
 {
 	u32 mode = *vcpu_cpsr(vcpu) & PSR_MODE_MASK;
 
+	if (vcpu_mode_is_32bit(vcpu))
+		return mode > COMPAT_PSR_MODE_USR;
+
 	return mode != PSR_MODE_EL0t;
 }
 
diff --git a/arch/arm64/kvm/Makefile b/arch/arm64/kvm/Makefile
index be9eb3833..1668448 100644
--- a/arch/arm64/kvm/Makefile
+++ b/arch/arm64/kvm/Makefile
@@ -11,7 +11,7 @@ obj-$(CONFIG_KVM_ARM_HOST) += kvm.o
 kvm-$(CONFIG_KVM_ARM_HOST) += $(addprefix ../../../virt/kvm/, kvm_main.o coalesced_mmio.o)
 kvm-$(CONFIG_KVM_ARM_HOST) += $(addprefix ../../../arch/arm/kvm/, arm.o mmu.o mmio.o psci.o perf.o)
 
-kvm-$(CONFIG_KVM_ARM_HOST) += inject_fault.o
+kvm-$(CONFIG_KVM_ARM_HOST) += inject_fault.o regmap.o
 kvm-$(CONFIG_KVM_ARM_HOST) += hyp.o hyp-init.o handle_exit.o
 kvm-$(CONFIG_KVM_ARM_HOST) += guest.o reset.o sys_regs.o sys_regs_generic_v8.o
 
diff --git a/arch/arm64/kvm/regmap.c b/arch/arm64/kvm/regmap.c
new file mode 100644
index 0000000..bbc6ae3
--- /dev/null
+++ b/arch/arm64/kvm/regmap.c
@@ -0,0 +1,168 @@
+/*
+ * Copyright (C) 2012,2013 - ARM Ltd
+ * Author: Marc Zyngier <marc.zyngier at arm.com>
+ *
+ * Derived from arch/arm/kvm/emulate.c:
+ * Copyright (C) 2012 - Virtual Open Systems and Columbia University
+ * Author: Christoffer Dall <c.dall at virtualopensystems.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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <linux/mm.h>
+#include <linux/kvm_host.h>
+#include <asm/kvm_emulate.h>
+#include <asm/ptrace.h>
+
+#define VCPU_NR_MODES 6
+#define REG_OFFSET(_reg) \
+	(offsetof(struct user_pt_regs, _reg) / sizeof(unsigned long))
+
+#define USR_REG_OFFSET(R) REG_OFFSET(compat_usr(R))
+
+static const unsigned long vcpu_reg_offsets[VCPU_NR_MODES][16] = {
+	/* USR Registers */
+	{
+		USR_REG_OFFSET(0), USR_REG_OFFSET(1), USR_REG_OFFSET(2),
+		USR_REG_OFFSET(3), USR_REG_OFFSET(4), USR_REG_OFFSET(5),
+		USR_REG_OFFSET(6), USR_REG_OFFSET(7), USR_REG_OFFSET(8),
+		USR_REG_OFFSET(9), USR_REG_OFFSET(10), USR_REG_OFFSET(11),
+		USR_REG_OFFSET(12), USR_REG_OFFSET(13),	USR_REG_OFFSET(14),
+		REG_OFFSET(pc)
+	},
+
+	/* FIQ Registers */
+	{
+		USR_REG_OFFSET(0), USR_REG_OFFSET(1), USR_REG_OFFSET(2),
+		USR_REG_OFFSET(3), USR_REG_OFFSET(4), USR_REG_OFFSET(5),
+		USR_REG_OFFSET(6), USR_REG_OFFSET(7),
+		REG_OFFSET(compat_r8_fiq),  /* r8 */
+		REG_OFFSET(compat_r9_fiq),  /* r9 */
+		REG_OFFSET(compat_r10_fiq), /* r10 */
+		REG_OFFSET(compat_r11_fiq), /* r11 */
+		REG_OFFSET(compat_r12_fiq), /* r12 */
+		REG_OFFSET(compat_sp_fiq),  /* r13 */
+		REG_OFFSET(compat_lr_fiq),  /* r14 */
+		REG_OFFSET(pc)
+	},
+
+	/* IRQ Registers */
+	{
+		USR_REG_OFFSET(0), USR_REG_OFFSET(1), USR_REG_OFFSET(2),
+		USR_REG_OFFSET(3), USR_REG_OFFSET(4), USR_REG_OFFSET(5),
+		USR_REG_OFFSET(6), USR_REG_OFFSET(7), USR_REG_OFFSET(8),
+		USR_REG_OFFSET(9), USR_REG_OFFSET(10), USR_REG_OFFSET(11),
+		USR_REG_OFFSET(12),
+		REG_OFFSET(compat_sp_irq), /* r13 */
+		REG_OFFSET(compat_lr_irq), /* r14 */
+		REG_OFFSET(pc)
+	},
+
+	/* SVC Registers */
+	{
+		USR_REG_OFFSET(0), USR_REG_OFFSET(1), USR_REG_OFFSET(2),
+		USR_REG_OFFSET(3), USR_REG_OFFSET(4), USR_REG_OFFSET(5),
+		USR_REG_OFFSET(6), USR_REG_OFFSET(7), USR_REG_OFFSET(8),
+		USR_REG_OFFSET(9), USR_REG_OFFSET(10), USR_REG_OFFSET(11),
+		USR_REG_OFFSET(12),
+		REG_OFFSET(compat_sp_svc), /* r13 */
+		REG_OFFSET(compat_lr_svc), /* r14 */
+		REG_OFFSET(pc)
+	},
+
+	/* ABT Registers */
+	{
+		USR_REG_OFFSET(0), USR_REG_OFFSET(1), USR_REG_OFFSET(2),
+		USR_REG_OFFSET(3), USR_REG_OFFSET(4), USR_REG_OFFSET(5),
+		USR_REG_OFFSET(6), USR_REG_OFFSET(7), USR_REG_OFFSET(8),
+		USR_REG_OFFSET(9), USR_REG_OFFSET(10), USR_REG_OFFSET(11),
+		USR_REG_OFFSET(12),
+		REG_OFFSET(compat_sp_abt), /* r13 */
+		REG_OFFSET(compat_lr_abt), /* r14 */
+		REG_OFFSET(pc)
+	},
+
+	/* UND Registers */
+	{
+		USR_REG_OFFSET(0), USR_REG_OFFSET(1), USR_REG_OFFSET(2),
+		USR_REG_OFFSET(3), USR_REG_OFFSET(4), USR_REG_OFFSET(5),
+		USR_REG_OFFSET(6), USR_REG_OFFSET(7), USR_REG_OFFSET(8),
+		USR_REG_OFFSET(9), USR_REG_OFFSET(10), USR_REG_OFFSET(11),
+		USR_REG_OFFSET(12),
+		REG_OFFSET(compat_sp_und), /* r13 */
+		REG_OFFSET(compat_lr_und), /* r14 */
+		REG_OFFSET(pc)
+	},
+};
+
+/*
+ * Return a pointer to the register number valid in the current mode of
+ * the virtual CPU.
+ */
+unsigned long *vcpu_reg32(const struct kvm_vcpu *vcpu, u8 reg_num)
+{
+	unsigned long *reg_array = (unsigned long *)&vcpu->arch.ctxt.gp_regs.regs;
+	unsigned long mode = *vcpu_cpsr(vcpu) & COMPAT_PSR_MODE_MASK;
+
+	switch (mode) {
+	case COMPAT_PSR_MODE_USR ... COMPAT_PSR_MODE_SVC:
+		mode &= ~PSR_MODE32_BIT; /* 0 ... 3 */
+		break;
+
+	case COMPAT_PSR_MODE_ABT:
+		mode = 4;
+		break;
+
+	case COMPAT_PSR_MODE_UND:
+		mode = 5;
+		break;
+
+	case COMPAT_PSR_MODE_SYS:
+		mode = 0;	/* SYS maps to USR */
+		break;
+
+	default:
+		BUG();
+	}
+
+	return reg_array + vcpu_reg_offsets[mode][reg_num];
+}
+
+/*
+ * Return the SPSR for the current mode of the virtual CPU.
+ */
+unsigned long *vcpu_spsr32(const struct kvm_vcpu *vcpu)
+{
+	unsigned long mode = *vcpu_cpsr(vcpu) & COMPAT_PSR_MODE_MASK;
+	switch (mode) {
+	case COMPAT_PSR_MODE_SVC:
+		mode = KVM_SPSR_SVC;
+		break;
+	case COMPAT_PSR_MODE_ABT:
+		mode = KVM_SPSR_ABT;
+		break;
+	case COMPAT_PSR_MODE_UND:
+		mode = KVM_SPSR_UND;
+		break;
+	case COMPAT_PSR_MODE_IRQ:
+		mode = KVM_SPSR_IRQ;
+		break;
+	case COMPAT_PSR_MODE_FIQ:
+		mode = KVM_SPSR_FIQ;
+		break;
+	default:
+		BUG();
+	}
+
+	return (unsigned long *)&vcpu_gp_regs(vcpu)->spsr[mode];
+}
-- 
1.8.1.4




From marc.zyngier at arm.com  Mon Apr  8 12:17:23 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon,  8 Apr 2013 17:17:23 +0100
Subject: [PATCH v3 21/32] arm64: KVM: PSCI implementation
In-Reply-To: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1365437854-30214-22-git-send-email-marc.zyngier@arm.com>

Wire the PSCI backend into the exit handling code.

Reviewed-by: Christopher Covington <cov at codeaurora.org>
Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/include/asm/kvm_host.h |  2 +-
 arch/arm64/include/asm/kvm_psci.h | 23 +++++++++++++++++++++++
 arch/arm64/include/uapi/asm/kvm.h | 16 ++++++++++++++++
 arch/arm64/kvm/handle_exit.c      | 16 +++++++---------
 4 files changed, 47 insertions(+), 10 deletions(-)
 create mode 100644 arch/arm64/include/asm/kvm_psci.h

diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 8655de4..fdcb324 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -34,7 +34,7 @@
 #include <asm/kvm_vgic.h>
 #include <asm/kvm_arch_timer.h>
 
-#define KVM_VCPU_MAX_FEATURES 0
+#define KVM_VCPU_MAX_FEATURES 1
 
 /* We don't currently support large pages. */
 #define KVM_HPAGE_GFN_SHIFT(x)	0
diff --git a/arch/arm64/include/asm/kvm_psci.h b/arch/arm64/include/asm/kvm_psci.h
new file mode 100644
index 0000000..e301a48
--- /dev/null
+++ b/arch/arm64/include/asm/kvm_psci.h
@@ -0,0 +1,23 @@
+/*
+ * Copyright (C) 2012,2013 - ARM Ltd
+ * Author: Marc Zyngier <marc.zyngier at arm.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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#ifndef __ARM64_KVM_PSCI_H__
+#define __ARM64_KVM_PSCI_H__
+
+bool kvm_psci_call(struct kvm_vcpu *vcpu);
+
+#endif /* __ARM64_KVM_PSCI_H__ */
diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
index ebac919..fb60f90 100644
--- a/arch/arm64/include/uapi/asm/kvm.h
+++ b/arch/arm64/include/uapi/asm/kvm.h
@@ -69,6 +69,8 @@ struct kvm_regs {
 #define KVM_VGIC_V2_DIST_SIZE		0x1000
 #define KVM_VGIC_V2_CPU_SIZE		0x2000
 
+#define KVM_ARM_VCPU_POWER_OFF		0 /* CPU is started in OFF state */
+
 struct kvm_vcpu_init {
 	__u32 target;
 	__u32 features[7];
@@ -141,6 +143,20 @@ struct kvm_arch_memory_slot {
 /* Highest supported SPI, from VGIC_NR_IRQS */
 #define KVM_ARM_IRQ_GIC_MAX		127
 
+/* PSCI interface */
+#define KVM_PSCI_FN_BASE		0x95c1ba5e
+#define KVM_PSCI_FN(n)			(KVM_PSCI_FN_BASE + (n))
+
+#define KVM_PSCI_FN_CPU_SUSPEND		KVM_PSCI_FN(0)
+#define KVM_PSCI_FN_CPU_OFF		KVM_PSCI_FN(1)
+#define KVM_PSCI_FN_CPU_ON		KVM_PSCI_FN(2)
+#define KVM_PSCI_FN_MIGRATE		KVM_PSCI_FN(3)
+
+#define KVM_PSCI_RET_SUCCESS		0
+#define KVM_PSCI_RET_NI			((unsigned long)-1)
+#define KVM_PSCI_RET_INVAL		((unsigned long)-2)
+#define KVM_PSCI_RET_DENIED		((unsigned long)-3)
+
 #endif
 
 #endif /* __ARM_KVM_H__ */
diff --git a/arch/arm64/kvm/handle_exit.c b/arch/arm64/kvm/handle_exit.c
index c65d115..4766b7f 100644
--- a/arch/arm64/kvm/handle_exit.c
+++ b/arch/arm64/kvm/handle_exit.c
@@ -24,26 +24,24 @@
 #include <asm/kvm_emulate.h>
 #include <asm/kvm_coproc.h>
 #include <asm/kvm_mmu.h>
+#include <asm/kvm_psci.h>
 
 typedef int (*exit_handle_fn)(struct kvm_vcpu *, struct kvm_run *);
 
 static int handle_hvc(struct kvm_vcpu *vcpu, struct kvm_run *run)
 {
-	/*
-	 * Guest called HVC instruction:
-	 * Let it know we don't want that by injecting an undefined exception.
-	 */
-	kvm_debug("hvc: %x (at %08lx)", kvm_vcpu_get_hsr(vcpu) & ((1 << 16) - 1),
-		  *vcpu_pc(vcpu));
-	kvm_debug("         HSR: %8x", kvm_vcpu_get_hsr(vcpu));
+	if (kvm_psci_call(vcpu))
+		return 1;
+
 	kvm_inject_undefined(vcpu);
 	return 1;
 }
 
 static int handle_smc(struct kvm_vcpu *vcpu, struct kvm_run *run)
 {
-	/* We don't support SMC; don't do that. */
-	kvm_debug("smc: at %08lx", *vcpu_pc(vcpu));
+	if (kvm_psci_call(vcpu))
+		return 1;
+
 	kvm_inject_undefined(vcpu);
 	return 1;
 }
-- 
1.8.1.4




From marc.zyngier at arm.com  Mon Apr  8 12:17:11 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon,  8 Apr 2013 17:17:11 +0100
Subject: [PATCH v3 09/32] arm64: KVM: user space interface
In-Reply-To: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1365437854-30214-10-git-send-email-marc.zyngier@arm.com>

Provide the kvm.h file that defines the user space visible
interface.

Reviewed-by: Christopher Covington <cov at codeaurora.org>
Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/include/uapi/asm/kvm.h | 117 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 117 insertions(+)
 create mode 100644 arch/arm64/include/uapi/asm/kvm.h

diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
new file mode 100644
index 0000000..4e64570
--- /dev/null
+++ b/arch/arm64/include/uapi/asm/kvm.h
@@ -0,0 +1,117 @@
+/*
+ * Copyright (C) 2012,2013 - ARM Ltd
+ * Author: Marc Zyngier <marc.zyngier at arm.com>
+ *
+ * Derived from arch/arm/include/uapi/asm/kvm.h:
+ * Copyright (C) 2012 - Virtual Open Systems and Columbia University
+ * Author: Christoffer Dall <c.dall at virtualopensystems.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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#ifndef __ARM_KVM_H__
+#define __ARM_KVM_H__
+
+#define KVM_SPSR_EL1	0
+#define KVM_NR_SPSR	1
+
+#ifndef __ASSEMBLY__
+#include <asm/types.h>
+#include <asm/ptrace.h>
+
+#define __KVM_HAVE_GUEST_DEBUG
+#define __KVM_HAVE_IRQ_LINE
+
+#define KVM_REG_SIZE(id)						\
+	(1U << (((id) & KVM_REG_SIZE_MASK) >> KVM_REG_SIZE_SHIFT))
+
+struct kvm_regs {
+	struct user_pt_regs regs;	/* sp = sp_el0 */
+
+	__u64	sp_el1;
+	__u64	elr_el1;
+
+	__u64	spsr[KVM_NR_SPSR];
+
+	struct user_fpsimd_state fp_regs;
+};
+
+/* Supported Processor Types */
+#define KVM_ARM_TARGET_AEM_V8		0
+#define KVM_ARM_TARGET_FOUNDATION_V8	1
+#define KVM_ARM_TARGET_CORTEX_A57	2
+
+#define KVM_ARM_NUM_TARGETS		3
+
+/* KVM_ARM_SET_DEVICE_ADDR ioctl id encoding */
+#define KVM_ARM_DEVICE_TYPE_SHIFT	0
+#define KVM_ARM_DEVICE_TYPE_MASK	(0xffff << KVM_ARM_DEVICE_TYPE_SHIFT)
+#define KVM_ARM_DEVICE_ID_SHIFT		16
+#define KVM_ARM_DEVICE_ID_MASK		(0xffff << KVM_ARM_DEVICE_ID_SHIFT)
+
+/* Supported device IDs */
+#define KVM_ARM_DEVICE_VGIC_V2		0
+
+/* Supported VGIC address types  */
+#define KVM_VGIC_V2_ADDR_TYPE_DIST	0
+#define KVM_VGIC_V2_ADDR_TYPE_CPU	1
+
+#define KVM_VGIC_V2_DIST_SIZE		0x1000
+#define KVM_VGIC_V2_CPU_SIZE		0x2000
+
+struct kvm_vcpu_init {
+	__u32 target;
+	__u32 features[7];
+};
+
+struct kvm_sregs {
+};
+
+struct kvm_fpu {
+};
+
+struct kvm_guest_debug_arch {
+};
+
+struct kvm_debug_exit_arch {
+};
+
+struct kvm_sync_regs {
+};
+
+struct kvm_arch_memory_slot {
+};
+
+/* KVM_IRQ_LINE irq field index values */
+#define KVM_ARM_IRQ_TYPE_SHIFT		24
+#define KVM_ARM_IRQ_TYPE_MASK		0xff
+#define KVM_ARM_IRQ_VCPU_SHIFT		16
+#define KVM_ARM_IRQ_VCPU_MASK		0xff
+#define KVM_ARM_IRQ_NUM_SHIFT		0
+#define KVM_ARM_IRQ_NUM_MASK		0xffff
+
+/* irq_type field */
+#define KVM_ARM_IRQ_TYPE_CPU		0
+#define KVM_ARM_IRQ_TYPE_SPI		1
+#define KVM_ARM_IRQ_TYPE_PPI		2
+
+/* out-of-kernel GIC cpu interrupt injection irq_number field */
+#define KVM_ARM_IRQ_CPU_IRQ		0
+#define KVM_ARM_IRQ_CPU_FIQ		1
+
+/* Highest supported SPI, from VGIC_NR_IRQS */
+#define KVM_ARM_IRQ_GIC_MAX		127
+
+#endif
+
+#endif /* __ARM_KVM_H__ */
-- 
1.8.1.4




From marc.zyngier at arm.com  Mon Apr  8 12:17:15 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon,  8 Apr 2013 17:17:15 +0100
Subject: [PATCH v3 13/32] arm64: KVM: kvm_arch and kvm_vcpu_arch definitions
In-Reply-To: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1365437854-30214-14-git-send-email-marc.zyngier@arm.com>

Provide the architecture dependent structures for VM and
vcpu abstractions.

Reviewed-by: Christopher Covington <cov at codeaurora.org>
Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/include/asm/kvm_host.h | 186 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 186 insertions(+)
 create mode 100644 arch/arm64/include/asm/kvm_host.h

diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
new file mode 100644
index 0000000..a0279ff
--- /dev/null
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -0,0 +1,186 @@
+/*
+ * Copyright (C) 2012,2013 - ARM Ltd
+ * Author: Marc Zyngier <marc.zyngier at arm.com>
+ *
+ * Derived from arch/arm/include/asm/kvm_host.h:
+ * Copyright (C) 2012 - Virtual Open Systems and Columbia University
+ * Author: Christoffer Dall <c.dall at virtualopensystems.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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#ifndef __ARM64_KVM_HOST_H__
+#define __ARM64_KVM_HOST_H__
+
+#include <asm/kvm.h>
+#include <asm/kvm_asm.h>
+#include <asm/kvm_mmio.h>
+
+#define KVM_MAX_VCPUS 4
+#define KVM_USER_MEM_SLOTS 32
+#define KVM_PRIVATE_MEM_SLOTS 4
+#define KVM_COALESCED_MMIO_PAGE_OFFSET 1
+
+#include <asm/kvm_vgic.h>
+#include <asm/kvm_arch_timer.h>
+
+#define KVM_VCPU_MAX_FEATURES 0
+
+/* We don't currently support large pages. */
+#define KVM_HPAGE_GFN_SHIFT(x)	0
+#define KVM_NR_PAGE_SIZES	1
+#define KVM_PAGES_PER_HPAGE(x)	(1UL<<31)
+
+struct kvm_vcpu;
+int kvm_target_cpu(void);
+int kvm_reset_vcpu(struct kvm_vcpu *vcpu);
+int kvm_arch_dev_ioctl_check_extention(long ext);
+
+struct kvm_arch {
+	/* The VMID generation used for the virt. memory system */
+	u64    vmid_gen;
+	u32    vmid;
+
+	/* 1-level 2nd stage table and lock */
+	spinlock_t pgd_lock;
+	pgd_t *pgd;
+
+	/* VTTBR value associated with above pgd and vmid */
+	u64    vttbr;
+
+	/* Interrupt controller */
+	struct vgic_dist	vgic;
+
+	/* Timer */
+	struct arch_timer_kvm	timer;
+};
+
+#define KVM_NR_MEM_OBJS     40
+
+/*
+ * We don't want allocation failures within the mmu code, so we preallocate
+ * enough memory for a single page fault in a cache.
+ */
+struct kvm_mmu_memory_cache {
+	int nobjs;
+	void *objects[KVM_NR_MEM_OBJS];
+};
+
+struct kvm_vcpu_fault_info {
+	u32 esr_el2;		/* Hyp Syndrom Register */
+	u64 far_el2;		/* Hyp Fault Address Register */
+	u64 hpfar_el2;		/* Hyp IPA Fault Address Register */
+};
+
+struct kvm_cpu_context {
+	struct kvm_regs	gp_regs;
+	u64 sys_regs[NR_SYS_REGS];
+};
+
+typedef struct kvm_cpu_context kvm_cpu_context_t;
+
+struct kvm_vcpu_arch {
+	struct kvm_cpu_context ctxt;
+
+	/* HYP configuration */
+	u64 hcr_el2;
+
+	/* Exception Information */
+	struct kvm_vcpu_fault_info fault;
+
+	/* Pointer to host CPU context */
+	kvm_cpu_context_t *host_cpu_context;
+
+	/* VGIC state */
+	struct vgic_cpu vgic_cpu;
+	struct arch_timer_cpu timer_cpu;
+
+	/*
+	 * Anything that is not used directly from assembly code goes
+	 * here.
+	 */
+	/* dcache set/way operation pending */
+	int last_pcpu;
+	cpumask_t require_dcache_flush;
+
+	/* Don't run the guest */
+	bool pause;
+
+	/* IO related fields */
+	struct kvm_decode mmio_decode;
+
+	/* Interrupt related fields */
+	u64 irq_lines;		/* IRQ and FIQ levels */
+
+	/* Cache some mmu pages needed inside spinlock regions */
+	struct kvm_mmu_memory_cache mmu_page_cache;
+
+	/* Target CPU and feature flags */
+	u32 target;
+	DECLARE_BITMAP(features, KVM_VCPU_MAX_FEATURES);
+
+	/* Detect first run of a vcpu */
+	bool has_run_once;
+};
+
+#define vcpu_gp_regs(v)		(&(v)->arch.ctxt.gp_regs)
+#define vcpu_sys_reg(v,r)	((v)->arch.ctxt.sys_regs[(r)])
+#define vcpu_cp15(v,r)		((v)->arch.ctxt.cp15[(r)])
+
+struct kvm_vm_stat {
+	u32 remote_tlb_flush;
+};
+
+struct kvm_vcpu_stat {
+	u32 halt_wakeup;
+};
+
+struct kvm_vcpu_init;
+int kvm_vcpu_set_target(struct kvm_vcpu *vcpu,
+			const struct kvm_vcpu_init *init);
+unsigned long kvm_arm_num_regs(struct kvm_vcpu *vcpu);
+int kvm_arm_copy_reg_indices(struct kvm_vcpu *vcpu, u64 __user *indices);
+struct kvm_one_reg;
+int kvm_arm_get_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
+int kvm_arm_set_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
+
+#define KVM_ARCH_WANT_MMU_NOTIFIER
+struct kvm;
+int kvm_unmap_hva(struct kvm *kvm, unsigned long hva);
+int kvm_unmap_hva_range(struct kvm *kvm,
+			unsigned long start, unsigned long end);
+void kvm_set_spte_hva(struct kvm *kvm, unsigned long hva, pte_t pte);
+
+/* We do not have shadow page tables, hence the empty hooks */
+static inline int kvm_age_hva(struct kvm *kvm, unsigned long hva)
+{
+	return 0;
+}
+
+static inline int kvm_test_age_hva(struct kvm *kvm, unsigned long hva)
+{
+	return 0;
+}
+
+struct kvm_vcpu *kvm_arm_get_running_vcpu(void);
+struct kvm_vcpu __percpu **kvm_get_running_vcpus(void);
+
+u64 kvm_call_hyp(void *hypfn, ...);
+
+int handle_exit(struct kvm_vcpu *vcpu, struct kvm_run *run,
+		int exception_index);
+
+int kvm_perf_init(void);
+int kvm_perf_teardown(void);
+
+#endif /* __ARM64_KVM_HOST_H__ */
-- 
1.8.1.4




From marc.zyngier at arm.com  Mon Apr  8 12:17:13 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon,  8 Apr 2013 17:17:13 +0100
Subject: [PATCH v3 11/32] arm64: KVM: CPU specific system registers handling
In-Reply-To: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1365437854-30214-12-git-send-email-marc.zyngier@arm.com>

Add the support code for CPU specific system registers. Not much
here yet.

Reviewed-by: Christopher Covington <cov at codeaurora.org>
Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/kvm/sys_regs_generic_v8.c | 85 ++++++++++++++++++++++++++++++++++++
 1 file changed, 85 insertions(+)
 create mode 100644 arch/arm64/kvm/sys_regs_generic_v8.c

diff --git a/arch/arm64/kvm/sys_regs_generic_v8.c b/arch/arm64/kvm/sys_regs_generic_v8.c
new file mode 100644
index 0000000..d4e8039
--- /dev/null
+++ b/arch/arm64/kvm/sys_regs_generic_v8.c
@@ -0,0 +1,85 @@
+/*
+ * Copyright (C) 2012,2013 - ARM Ltd
+ * Author: Marc Zyngier <marc.zyngier at arm.com>
+ *
+ * Based on arch/arm/kvm/coproc_a15.c:
+ * Copyright (C) 2012 - Virtual Open Systems and Columbia University
+ * Authors: Rusty Russell <rusty at rustcorp.au>
+ *          Christoffer Dall <c.dall at virtualopensystems.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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
+ */
+#include <linux/kvm_host.h>
+#include <asm/cputype.h>
+#include <asm/kvm_arm.h>
+#include <asm/kvm_asm.h>
+#include <asm/kvm_host.h>
+#include <asm/kvm_emulate.h>
+#include <asm/kvm_coproc.h>
+#include <linux/init.h>
+
+#include "sys_regs.h"
+
+static bool access_actlr(struct kvm_vcpu *vcpu,
+			 const struct sys_reg_params *p,
+			 const struct sys_reg_desc *r)
+{
+	if (p->is_write)
+		return ignore_write(vcpu, p);
+
+	*vcpu_reg(vcpu, p->Rt) = vcpu_sys_reg(vcpu, ACTLR_EL1);
+	return true;
+}
+
+static void reset_actlr(struct kvm_vcpu *vcpu, const struct sys_reg_desc *r)
+{
+	u64 actlr;
+
+	asm volatile("mrs %0, actlr_el1\n" : "=r" (actlr));
+	vcpu_sys_reg(vcpu, ACTLR_EL1) = actlr;
+}
+
+/*
+ * Implementation specific sys-reg registers.
+ * Important: Must be sorted ascending by Op0, Op1, CRn, CRm, Op2
+ */
+static const struct sys_reg_desc genericv8_sys_regs[] = {
+	/* ACTLR_EL1 */
+	{ Op0(0b11), Op1(0b000), CRn(0b0001), CRm(0b0000), Op2(0b001),
+	  access_actlr, reset_actlr, ACTLR_EL1 },
+};
+
+static struct kvm_sys_reg_target_table genericv8_target_table = {
+	.table64 = {
+		.table = genericv8_sys_regs,
+		.num = ARRAY_SIZE(genericv8_sys_regs),
+	},
+};
+
+static int __init sys_reg_genericv8_init(void)
+{
+	unsigned int i;
+
+	for (i = 1; i < ARRAY_SIZE(genericv8_sys_regs); i++)
+		BUG_ON(cmp_sys_reg(&genericv8_sys_regs[i-1],
+			       &genericv8_sys_regs[i]) >= 0);
+
+	kvm_register_target_sys_reg_table(KVM_ARM_TARGET_AEM_V8,
+					  &genericv8_target_table);
+	kvm_register_target_sys_reg_table(KVM_ARM_TARGET_FOUNDATION_V8,
+					  &genericv8_target_table);
+	kvm_register_target_sys_reg_table(KVM_ARM_TARGET_CORTEX_A57,
+					  &genericv8_target_table);
+	return 0;
+}
+late_initcall(sys_reg_genericv8_init);
-- 
1.8.1.4




From arnd at arndb.de  Mon Apr  8 12:19:46 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 8 Apr 2013 18:19:46 +0200
Subject: [PATCH 4/5] dmaengine: ste_dma40: Only configure a channel during
 a configure request
In-Reply-To: <1365434591-21569-4-git-send-email-lee.jones@linaro.org>
References: <1365434591-21569-1-git-send-email-lee.jones@linaro.org>
 <1365434591-21569-4-git-send-email-lee.jones@linaro.org>
Message-ID: <201304081819.46377.arnd@arndb.de>

On Monday 08 April 2013, Lee Jones wrote:
> According to the DMA documentation allocating a channel and configuring
> it are two separate actions. By moving the configuration code into the
> correct code path we lighten the burden on the information required to
> successfully allocate a channel.
> 
> Cc: Vinod Koul <vinod.koul at intel.com>
> Cc: Dan Williams <djbw at fb.com>
> Cc: Per Forlin <per.forlin at stericsson.com>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>

I think the patch doesn't match the description. You only remove
the calls to configure the channel but don't add it in a proper
place.

	Arnd


From marc.zyngier at arm.com  Mon Apr  8 12:17:12 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon,  8 Apr 2013 17:17:12 +0100
Subject: [PATCH v3 10/32] arm64: KVM: system register handling
In-Reply-To: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1365437854-30214-11-git-send-email-marc.zyngier@arm.com>

Provide 64bit system register handling, modeled after the cp15
handling for ARM.

Reviewed-by: Christopher Covington <cov at codeaurora.org>
Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/include/asm/kvm_coproc.h |  51 +++
 arch/arm64/include/uapi/asm/kvm.h   |  29 ++
 arch/arm64/kvm/sys_regs.c           | 871 ++++++++++++++++++++++++++++++++++++
 arch/arm64/kvm/sys_regs.h           | 138 ++++++
 include/uapi/linux/kvm.h            |   1 +
 5 files changed, 1090 insertions(+)
 create mode 100644 arch/arm64/include/asm/kvm_coproc.h
 create mode 100644 arch/arm64/kvm/sys_regs.c
 create mode 100644 arch/arm64/kvm/sys_regs.h

diff --git a/arch/arm64/include/asm/kvm_coproc.h b/arch/arm64/include/asm/kvm_coproc.h
new file mode 100644
index 0000000..9b4477a
--- /dev/null
+++ b/arch/arm64/include/asm/kvm_coproc.h
@@ -0,0 +1,51 @@
+/*
+ * Copyright (C) 2012,2013 - ARM Ltd
+ * Author: Marc Zyngier <marc.zyngier at arm.com>
+ *
+ * Derived from arch/arm/include/asm/kvm_coproc.h
+ * Copyright (C) 2012 Rusty Russell IBM Corporation
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#ifndef __ARM64_KVM_COPROC_H__
+#define __ARM64_KVM_COPROC_H__
+
+#include <linux/kvm_host.h>
+
+void kvm_reset_sys_regs(struct kvm_vcpu *vcpu);
+
+struct kvm_sys_reg_table {
+	const struct sys_reg_desc *table;
+	size_t num;
+};
+
+struct kvm_sys_reg_target_table {
+	struct kvm_sys_reg_table table64;
+};
+
+void kvm_register_target_sys_reg_table(unsigned int target,
+				       struct kvm_sys_reg_target_table *table);
+
+int kvm_handle_sys_reg(struct kvm_vcpu *vcpu, struct kvm_run *run);
+
+#define kvm_coproc_table_init kvm_sys_reg_table_init
+void kvm_sys_reg_table_init(void);
+
+struct kvm_one_reg;
+int kvm_arm_copy_sys_reg_indices(struct kvm_vcpu *vcpu, u64 __user *uindices);
+int kvm_arm_sys_reg_get_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *);
+int kvm_arm_sys_reg_set_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *);
+unsigned long kvm_arm_num_sys_reg_descs(struct kvm_vcpu *vcpu);
+
+#endif /* __ARM64_KVM_COPROC_H__ */
diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
index 4e64570..ebac919 100644
--- a/arch/arm64/include/uapi/asm/kvm.h
+++ b/arch/arm64/include/uapi/asm/kvm.h
@@ -92,6 +92,35 @@ struct kvm_sync_regs {
 struct kvm_arch_memory_slot {
 };
 
+/* If you need to interpret the index values, here is the key: */
+#define KVM_REG_ARM_COPROC_MASK		0x000000000FFF0000
+#define KVM_REG_ARM_COPROC_SHIFT	16
+
+/* Normal registers are mapped as coprocessor 16. */
+#define KVM_REG_ARM_CORE		(0x0010 << KVM_REG_ARM_COPROC_SHIFT)
+#define KVM_REG_ARM_CORE_REG(name)	(offsetof(struct kvm_regs, name) / sizeof(__u32))
+
+/* Some registers need more space to represent values. */
+#define KVM_REG_ARM_DEMUX		(0x0011 << KVM_REG_ARM_COPROC_SHIFT)
+#define KVM_REG_ARM_DEMUX_ID_MASK	0x000000000000FF00
+#define KVM_REG_ARM_DEMUX_ID_SHIFT	8
+#define KVM_REG_ARM_DEMUX_ID_CCSIDR	(0x00 << KVM_REG_ARM_DEMUX_ID_SHIFT)
+#define KVM_REG_ARM_DEMUX_VAL_MASK	0x00000000000000FF
+#define KVM_REG_ARM_DEMUX_VAL_SHIFT	0
+
+/* AArch64 system registers */
+#define KVM_REG_ARM64_SYSREG		(0x0013 << KVM_REG_ARM_COPROC_SHIFT)
+#define KVM_REG_ARM64_SYSREG_OP0_MASK	0x000000000000c000
+#define KVM_REG_ARM64_SYSREG_OP0_SHIFT	14
+#define KVM_REG_ARM64_SYSREG_OP1_MASK	0x0000000000003800
+#define KVM_REG_ARM64_SYSREG_OP1_SHIFT	11
+#define KVM_REG_ARM64_SYSREG_CRN_MASK	0x0000000000000780
+#define KVM_REG_ARM64_SYSREG_CRN_SHIFT	7
+#define KVM_REG_ARM64_SYSREG_CRM_MASK	0x0000000000000078
+#define KVM_REG_ARM64_SYSREG_CRM_SHIFT	3
+#define KVM_REG_ARM64_SYSREG_OP2_MASK	0x0000000000000007
+#define KVM_REG_ARM64_SYSREG_OP2_SHIFT	0
+
 /* KVM_IRQ_LINE irq field index values */
 #define KVM_ARM_IRQ_TYPE_SHIFT		24
 #define KVM_ARM_IRQ_TYPE_MASK		0xff
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
new file mode 100644
index 0000000..9df3b32
--- /dev/null
+++ b/arch/arm64/kvm/sys_regs.c
@@ -0,0 +1,871 @@
+/*
+ * Copyright (C) 2012,2013 - ARM Ltd
+ * Author: Marc Zyngier <marc.zyngier at arm.com>
+ *
+ * Derived from arch/arm/kvm/coproc.c:
+ * Copyright (C) 2012 - Virtual Open Systems and Columbia University
+ * Authors: Rusty Russell <rusty at rustcorp.com.au>
+ *          Christoffer Dall <c.dall at virtualopensystems.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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <linux/mm.h>
+#include <linux/kvm_host.h>
+#include <linux/uaccess.h>
+#include <asm/kvm_arm.h>
+#include <asm/kvm_host.h>
+#include <asm/kvm_emulate.h>
+#include <asm/kvm_coproc.h>
+#include <asm/cacheflush.h>
+#include <asm/cputype.h>
+#include <trace/events/kvm.h>
+
+#include "sys_regs.h"
+
+/*
+ * All of this file is extremly similar to the ARM coproc.c, but the
+ * types are different. My gut feeling is that it should be pretty
+ * easy to merge, but that would be an ABI breakage -- again. VFP
+ * would also need to be abstracted.
+ */
+
+/* 3 bits per cache level, as per CLIDR, but non-existent caches always 0 */
+static u32 cache_levels;
+
+/* CSSELR values; used to index KVM_REG_ARM_DEMUX_ID_CCSIDR */
+#define CSSELR_MAX 12
+
+/* Which cache CCSIDR represents depends on CSSELR value. */
+static u32 get_ccsidr(u32 csselr)
+{
+	u32 ccsidr;
+
+	/* Make sure noone else changes CSSELR during this! */
+	local_irq_disable();
+	/* Put value into CSSELR */
+	asm volatile("msr csselr_el1, %x0" : : "r" (csselr));
+	/* Read result out of CCSIDR */
+	asm volatile("mrs %0, ccsidr_el1" : "=r" (ccsidr));
+	local_irq_enable();
+
+	return ccsidr;
+}
+
+static void do_dc_cisw(u32 val)
+{
+	asm volatile("dc cisw, %x0" : : "r" (val));
+}
+
+static void do_dc_csw(u32 val)
+{
+	asm volatile("dc csw, %x0" : : "r" (val));
+}
+
+/* See note at ARM ARM B1.14.4 */
+static bool access_dcsw(struct kvm_vcpu *vcpu,
+			const struct sys_reg_params *p,
+			const struct sys_reg_desc *r)
+{
+	unsigned long val;
+	int cpu;
+
+	cpu = get_cpu();
+
+	if (!p->is_write)
+		return read_from_write_only(vcpu, p);
+
+	cpumask_setall(&vcpu->arch.require_dcache_flush);
+	cpumask_clear_cpu(cpu, &vcpu->arch.require_dcache_flush);
+
+	/* If we were already preempted, take the long way around */
+	if (cpu != vcpu->arch.last_pcpu) {
+		flush_cache_all();
+		goto done;
+	}
+
+	val = *vcpu_reg(vcpu, p->Rt);
+
+	switch (p->CRm) {
+	case 6:			/* Upgrade DCISW to DCCISW, as per HCR.SWIO */
+	case 14:		/* DCCISW */
+		do_dc_cisw(val);
+		break;
+
+	case 10:		/* DCCSW */
+		do_dc_csw(val);
+		break;
+	}
+
+done:
+	put_cpu();
+
+	return true;
+}
+
+/*
+ * We could trap ID_DFR0 and tell the guest we don't support performance
+ * monitoring.  Unfortunately the patch to make the kernel check ID_DFR0 was
+ * NAKed, so it will read the PMCR anyway.
+ *
+ * Therefore we tell the guest we have 0 counters.  Unfortunately, we
+ * must always support PMCCNTR (the cycle counter): we just RAZ/WI for
+ * all PM registers, which doesn't crash the guest kernel at least.
+ */
+static bool pm_fake(struct kvm_vcpu *vcpu,
+		    const struct sys_reg_params *p,
+		    const struct sys_reg_desc *r)
+{
+	if (p->is_write)
+		return ignore_write(vcpu, p);
+	else
+		return read_zero(vcpu, p);
+}
+
+static void reset_amair_el1(struct kvm_vcpu *vcpu, const struct sys_reg_desc *r)
+{
+	u64 amair;
+
+	asm volatile("mrs %0, amair_el1\n" : "=r" (amair));
+	vcpu_sys_reg(vcpu, AMAIR_EL1) = amair;
+}
+
+static void reset_mpidr(struct kvm_vcpu *vcpu, const struct sys_reg_desc *r)
+{
+	/*
+	 * Simply map the vcpu_id into the Aff0 field of the MPIDR.
+	 */
+	vcpu_sys_reg(vcpu, MPIDR_EL1) = (1 << 31) | (vcpu->vcpu_id & 0xff);
+}
+
+/*
+ * Architected system registers.
+ * Important: Must be sorted ascending by Op0, Op1, CRn, CRm, Op2
+ */
+static const struct sys_reg_desc sys_reg_descs[] = {
+	/* DC ISW */
+	{ Op0(0b01), Op1(0b000), CRn(0b0111), CRm(0b0110), Op2(0b010),
+	  access_dcsw },
+	/* DC CSW */
+	{ Op0(0b01), Op1(0b000), CRn(0b0111), CRm(0b1010), Op2(0b010),
+	  access_dcsw },
+	/* DC CISW */
+	{ Op0(0b01), Op1(0b000), CRn(0b0111), CRm(0b1110), Op2(0b010),
+	  access_dcsw },
+
+	/* MPIDR_EL1 */
+	{ Op0(0b11), Op1(0b000), CRn(0b0000), CRm(0b0000), Op2(0b101),
+	  NULL, reset_mpidr, MPIDR_EL1 },
+	/* SCTLR_EL1 */
+	{ Op0(0b11), Op1(0b000), CRn(0b0001), CRm(0b0000), Op2(0b000),
+	  NULL, reset_val, SCTLR_EL1, 0x00C50078 },
+	/* CPACR_EL1 */
+	{ Op0(0b11), Op1(0b000), CRn(0b0001), CRm(0b0000), Op2(0b010),
+	  NULL, reset_val, CPACR_EL1, 0 },
+	/* TTBR0_EL1 */
+	{ Op0(0b11), Op1(0b000), CRn(0b0010), CRm(0b0000), Op2(0b000),
+	  NULL, reset_unknown, TTBR0_EL1 },
+	/* TTBR1_EL1 */
+	{ Op0(0b11), Op1(0b000), CRn(0b0010), CRm(0b0000), Op2(0b001),
+	  NULL, reset_unknown, TTBR1_EL1 },
+	/* TCR_EL1 */
+	{ Op0(0b11), Op1(0b000), CRn(0b0010), CRm(0b0000), Op2(0b010),
+	  NULL, reset_val, TCR_EL1, 0 },
+
+	/* AFSR0_EL1 */
+	{ Op0(0b11), Op1(0b000), CRn(0b0101), CRm(0b0001), Op2(0b000),
+	  NULL, reset_unknown, AFSR0_EL1 },
+	/* AFSR1_EL1 */
+	{ Op0(0b11), Op1(0b000), CRn(0b0101), CRm(0b0001), Op2(0b001),
+	  NULL, reset_unknown, AFSR1_EL1 },
+	/* ESR_EL1 */
+	{ Op0(0b11), Op1(0b000), CRn(0b0101), CRm(0b0010), Op2(0b000),
+	  NULL, reset_unknown, ESR_EL1 },
+	/* FAR_EL1 */
+	{ Op0(0b11), Op1(0b000), CRn(0b0110), CRm(0b0000), Op2(0b000),
+	  NULL, reset_unknown, FAR_EL1 },
+
+	/* PMINTENSET_EL1 */
+	{ Op0(0b11), Op1(0b000), CRn(0b1001), CRm(0b1110), Op2(0b001),
+	  pm_fake },
+	/* PMINTENCLR_EL1 */
+	{ Op0(0b11), Op1(0b000), CRn(0b1001), CRm(0b1110), Op2(0b010),
+	  pm_fake },
+
+	/* MAIR_EL1 */
+	{ Op0(0b11), Op1(0b000), CRn(0b1010), CRm(0b0010), Op2(0b000),
+	  NULL, reset_unknown, MAIR_EL1 },
+	/* AMAIR_EL1 */
+	{ Op0(0b11), Op1(0b000), CRn(0b1010), CRm(0b0011), Op2(0b000),
+	  NULL, reset_amair_el1, AMAIR_EL1 },
+
+	/* VBAR_EL1 */
+	{ Op0(0b11), Op1(0b000), CRn(0b1100), CRm(0b0000), Op2(0b000),
+	  NULL, reset_val, VBAR_EL1, 0 },
+	/* CONTEXTIDR_EL1 */
+	{ Op0(0b11), Op1(0b000), CRn(0b1101), CRm(0b0000), Op2(0b001),
+	  NULL, reset_val, CONTEXTIDR_EL1, 0 },
+	/* TPIDR_EL1 */
+	{ Op0(0b11), Op1(0b000), CRn(0b1101), CRm(0b0000), Op2(0b100),
+	  NULL, reset_unknown, TPIDR_EL1 },
+
+	/* CNTKCTL_EL1 */
+	{ Op0(0b11), Op1(0b000), CRn(0b1110), CRm(0b0001), Op2(0b000),
+	  NULL, reset_val, CNTKCTL_EL1, 0},
+
+	/* CSSELR_EL1 */
+	{ Op0(0b11), Op1(0b010), CRn(0b0000), CRm(0b0000), Op2(0b000),
+	  NULL, reset_unknown, CSSELR_EL1 },
+
+	/* PMCR_EL0 */
+	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b000),
+	  pm_fake },
+	/* PMCNTENSET_EL0 */
+	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b001),
+	  pm_fake },
+	/* PMCNTENCLR_EL0 */
+	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b010),
+	  pm_fake },
+	/* PMOVSCLR_EL0 */
+	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b011),
+	  pm_fake },
+	/* PMSWINC_EL0 */
+	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b100),
+	  pm_fake },
+	/* PMSELR_EL0 */
+	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b101),
+	  pm_fake },
+	/* PMCEID0_EL0 */
+	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b110),
+	  pm_fake },
+	/* PMCEID1_EL0 */
+	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b111),
+	  pm_fake },
+	/* PMCCNTR_EL0 */
+	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1101), Op2(0b000),
+	  pm_fake },
+	/* PMXEVTYPER_EL0 */
+	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1101), Op2(0b001),
+	  pm_fake },
+	/* PMXEVCNTR_EL0 */
+	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1101), Op2(0b010),
+	  pm_fake },
+	/* PMUSERENR_EL0 */
+	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1110), Op2(0b000),
+	  pm_fake },
+	/* PMOVSSET_EL0 */
+	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1110), Op2(0b011),
+	  pm_fake },
+
+	/* TPIDR_EL0 */
+	{ Op0(0b11), Op1(0b011), CRn(0b1101), CRm(0b0000), Op2(0b010),
+	  NULL, reset_unknown, TPIDR_EL0 },
+	/* TPIDRRO_EL0 */
+	{ Op0(0b11), Op1(0b011), CRn(0b1101), CRm(0b0000), Op2(0b011),
+	  NULL, reset_unknown, TPIDRRO_EL0 },
+};
+
+/* Target specific emulation tables */
+static struct kvm_sys_reg_target_table *target_tables[KVM_ARM_NUM_TARGETS];
+
+void kvm_register_target_sys_reg_table(unsigned int target,
+				       struct kvm_sys_reg_target_table *table)
+{
+	target_tables[target] = table;
+}
+
+/* Get specific register table for this target. */
+static const struct sys_reg_desc *get_target_table(unsigned target, size_t *num)
+{
+	struct kvm_sys_reg_target_table *table;
+
+	table = target_tables[target];
+	*num = table->table64.num;
+	return table->table64.table;
+}
+
+static const struct sys_reg_desc *find_reg(const struct sys_reg_params *params,
+					 const struct sys_reg_desc table[],
+					 unsigned int num)
+{
+	unsigned int i;
+
+	for (i = 0; i < num; i++) {
+		const struct sys_reg_desc *r = &table[i];
+
+		if (params->Op0 != r->Op0)
+			continue;
+		if (params->Op1 != r->Op1)
+			continue;
+		if (params->CRn != r->CRn)
+			continue;
+		if (params->CRm != r->CRm)
+			continue;
+		if (params->Op2 != r->Op2)
+			continue;
+
+		return r;
+	}
+	return NULL;
+}
+
+static int emulate_sys_reg(struct kvm_vcpu *vcpu,
+			   const struct sys_reg_params *params)
+{
+	size_t num;
+	const struct sys_reg_desc *table, *r;
+
+	table = get_target_table(vcpu->arch.target, &num);
+
+	/* Search target-specific then generic table. */
+	r = find_reg(params, table, num);
+	if (!r)
+		r = find_reg(params, sys_reg_descs, ARRAY_SIZE(sys_reg_descs));
+
+	if (likely(r)) {
+		/* If we don't have an accessor, we should never get here! */
+		BUG_ON(!r->access);
+
+		if (likely(r->access(vcpu, params, r))) {
+			/* Skip instruction, since it was emulated */
+			kvm_skip_instr(vcpu, kvm_vcpu_trap_il_is32bit(vcpu));
+			return 1;
+		}
+		/* If access function fails, it should complain. */
+	} else {
+		kvm_err("Unsupported guest sys_reg access at: %lx\n",
+			*vcpu_pc(vcpu));
+		print_sys_reg_instr(params);
+	}
+	kvm_inject_undefined(vcpu);
+	return 1;
+}
+
+static void reset_sys_reg_descs(struct kvm_vcpu *vcpu,
+			      const struct sys_reg_desc *table, size_t num)
+{
+	unsigned long i;
+
+	for (i = 0; i < num; i++)
+		if (table[i].reset)
+			table[i].reset(vcpu, &table[i]);
+}
+
+/**
+ * kvm_handle_sys_reg -- handles a mrs/msr trap on a guest sys_reg access
+ * @vcpu: The VCPU pointer
+ * @run:  The kvm_run struct
+ */
+int kvm_handle_sys_reg(struct kvm_vcpu *vcpu, struct kvm_run *run)
+{
+	struct sys_reg_params params;
+	unsigned long esr = kvm_vcpu_get_hsr(vcpu);
+
+	params.Op0 = (esr >> 20) & 3;
+	params.Op1 = (esr >> 14) & 0x7;
+	params.CRn = (esr >> 10) & 0xf;
+	params.CRm = (esr >> 1) & 0xf;
+	params.Op2 = (esr >> 17) & 0x7;
+	params.Rt = (esr >> 5) & 0x1f;
+	params.is_write = !(esr & 1);
+
+	return emulate_sys_reg(vcpu, &params);
+}
+
+/******************************************************************************
+ * Userspace API
+ *****************************************************************************/
+
+static bool index_to_params(u64 id, struct sys_reg_params *params)
+{
+	switch (id & KVM_REG_SIZE_MASK) {
+	case KVM_REG_SIZE_U64:
+		/* Any unused index bits means it's not valid. */
+		if (id & ~(KVM_REG_ARCH_MASK | KVM_REG_SIZE_MASK
+			      | KVM_REG_ARM_COPROC_MASK
+			      | KVM_REG_ARM64_SYSREG_OP0_MASK
+			      | KVM_REG_ARM64_SYSREG_OP1_MASK
+			      | KVM_REG_ARM64_SYSREG_CRN_MASK
+			      | KVM_REG_ARM64_SYSREG_CRM_MASK
+			      | KVM_REG_ARM64_SYSREG_OP2_MASK))
+			return false;
+		params->Op0 = ((id & KVM_REG_ARM64_SYSREG_OP0_MASK)
+			       >> KVM_REG_ARM64_SYSREG_OP0_SHIFT);
+		params->Op1 = ((id & KVM_REG_ARM64_SYSREG_OP1_MASK)
+			       >> KVM_REG_ARM64_SYSREG_OP1_SHIFT);
+		params->CRn = ((id & KVM_REG_ARM64_SYSREG_CRN_MASK)
+			       >> KVM_REG_ARM64_SYSREG_CRN_SHIFT);
+		params->CRm = ((id & KVM_REG_ARM64_SYSREG_CRM_MASK)
+			       >> KVM_REG_ARM64_SYSREG_CRM_SHIFT);
+		params->Op2 = ((id & KVM_REG_ARM64_SYSREG_OP2_MASK)
+			       >> KVM_REG_ARM64_SYSREG_OP2_SHIFT);
+		return true;
+	default:
+		return false;
+	}
+}
+
+/* Decode an index value, and find the sys_reg_desc entry. */
+static const struct sys_reg_desc *index_to_sys_reg_desc(struct kvm_vcpu *vcpu,
+						    u64 id)
+{
+	size_t num;
+	const struct sys_reg_desc *table, *r;
+	struct sys_reg_params params;
+
+	/* We only do sys_reg for now. */
+	if ((id & KVM_REG_ARM_COPROC_MASK) != KVM_REG_ARM64_SYSREG)
+		return NULL;
+
+	if (!index_to_params(id, &params))
+		return NULL;
+
+	table = get_target_table(vcpu->arch.target, &num);
+	r = find_reg(&params, table, num);
+	if (!r)
+		r = find_reg(&params, sys_reg_descs, ARRAY_SIZE(sys_reg_descs));
+
+	/* Not saved in the sys_reg array? */
+	if (r && !r->reg)
+		r = NULL;
+
+	return r;
+}
+
+/*
+ * These are the invariant sys_reg registers: we let the guest see the
+ * host versions of these, so they're part of the guest state.
+ *
+ * A future CPU may provide a mechanism to present different values to
+ * the guest, or a future kvm may trap them.
+ */
+
+#define FUNCTION_INVARIANT(reg)						\
+	static void get_##reg(struct kvm_vcpu *v,			\
+			      const struct sys_reg_desc *r)		\
+	{								\
+		u64 val;						\
+									\
+		asm volatile("mrs %0, " __stringify(reg) "\n"		\
+			     : "=r" (val));				\
+		((struct sys_reg_desc *)r)->val = val;			\
+	}
+
+FUNCTION_INVARIANT(midr_el1)
+FUNCTION_INVARIANT(ctr_el0)
+FUNCTION_INVARIANT(revidr_el1)
+FUNCTION_INVARIANT(id_pfr0_el1)
+FUNCTION_INVARIANT(id_pfr1_el1)
+FUNCTION_INVARIANT(id_dfr0_el1)
+FUNCTION_INVARIANT(id_afr0_el1)
+FUNCTION_INVARIANT(id_mmfr0_el1)
+FUNCTION_INVARIANT(id_mmfr1_el1)
+FUNCTION_INVARIANT(id_mmfr2_el1)
+FUNCTION_INVARIANT(id_mmfr3_el1)
+FUNCTION_INVARIANT(id_isar0_el1)
+FUNCTION_INVARIANT(id_isar1_el1)
+FUNCTION_INVARIANT(id_isar2_el1)
+FUNCTION_INVARIANT(id_isar3_el1)
+FUNCTION_INVARIANT(id_isar4_el1)
+FUNCTION_INVARIANT(id_isar5_el1)
+FUNCTION_INVARIANT(clidr_el1)
+FUNCTION_INVARIANT(aidr_el1)
+
+/* ->val is filled in by kvm_invariant_sys_reg_table_init() */
+static struct sys_reg_desc invariant_sys_regs[] = {
+	{ Op0(0b11),	Op1(0b000),	CRn(0b0000),	CRm(0b0000),	Op2(0b000),
+	  NULL, get_midr_el1 },
+	{ Op0(0b11),	Op1(0b000),	CRn(0b0000),	CRm(0b0000),	Op2(0b110),
+	  NULL, get_revidr_el1 },
+	{ Op0(0b11),	Op1(0b000),	CRn(0b0000),	CRm(0b0001),	Op2(0b000),
+	  NULL, get_id_pfr0_el1 },
+	{ Op0(0b11),	Op1(0b000),	CRn(0b0000),	CRm(0b0001),	Op2(0b001),
+	  NULL, get_id_pfr1_el1 },
+	{ Op0(0b11),	Op1(0b000),	CRn(0b0000),	CRm(0b0001),	Op2(0b010),
+	  NULL, get_id_dfr0_el1 },
+	{ Op0(0b11),	Op1(0b000),	CRn(0b0000),	CRm(0b0001),	Op2(0b011),
+	  NULL, get_id_afr0_el1 },
+	{ Op0(0b11),	Op1(0b000),	CRn(0b0000),	CRm(0b0001),	Op2(0b100),
+	  NULL, get_id_mmfr0_el1 },
+	{ Op0(0b11),	Op1(0b000),	CRn(0b0000),	CRm(0b0001),	Op2(0b101),
+	  NULL, get_id_mmfr1_el1 },
+	{ Op0(0b11),	Op1(0b000),	CRn(0b0000),	CRm(0b0001),	Op2(0b110),
+	  NULL, get_id_mmfr2_el1 },
+	{ Op0(0b11),	Op1(0b000),	CRn(0b0000),	CRm(0b0001),	Op2(0b111),
+	  NULL, get_id_mmfr3_el1 },
+	{ Op0(0b11),	Op1(0b000),	CRn(0b0000),	CRm(0b0010),	Op2(0b000),
+	  NULL, get_id_isar0_el1 },
+	{ Op0(0b11),	Op1(0b000),	CRn(0b0000),	CRm(0b0010),	Op2(0b001),
+	  NULL, get_id_isar1_el1 },
+	{ Op0(0b11),	Op1(0b000),	CRn(0b0000),	CRm(0b0010),	Op2(0b010),
+	  NULL, get_id_isar2_el1 },
+	{ Op0(0b11),	Op1(0b000),	CRn(0b0000),	CRm(0b0010),	Op2(0b011),
+	  NULL, get_id_isar3_el1 },
+	{ Op0(0b11),	Op1(0b000),	CRn(0b0000),	CRm(0b0010),	Op2(0b100),
+	  NULL, get_id_isar4_el1 },
+	{ Op0(0b11),	Op1(0b000),	CRn(0b0000),	CRm(0b0010),	Op2(0b101),
+	  NULL, get_id_isar5_el1 },
+	{ Op0(0b11),	Op1(0b001),	CRn(0b0000),	CRm(0b0000),	Op2(0b001),
+	  NULL, get_clidr_el1 },
+	{ Op0(0b11),	Op1(0b001),	CRn(0b0000),	CRm(0b0000),	Op2(0b111),
+	  NULL, get_aidr_el1 },
+	{ Op0(0b11),	Op1(0b011),	CRn(0b0000),	CRm(0b0000),	Op2(0b001),
+	  NULL, get_ctr_el0 },
+};
+
+static int reg_from_user(void *val, const void __user *uaddr, u64 id)
+{
+	/* This Just Works because we are little endian. */
+	if (copy_from_user(val, uaddr, KVM_REG_SIZE(id)) != 0)
+		return -EFAULT;
+	return 0;
+}
+
+static int reg_to_user(void __user *uaddr, const void *val, u64 id)
+{
+	/* This Just Works because we are little endian. */
+	if (copy_to_user(uaddr, val, KVM_REG_SIZE(id)) != 0)
+		return -EFAULT;
+	return 0;
+}
+
+static int get_invariant_sys_reg(u64 id, void __user *uaddr)
+{
+	struct sys_reg_params params;
+	const struct sys_reg_desc *r;
+
+	if (!index_to_params(id, &params))
+		return -ENOENT;
+
+	r = find_reg(&params, invariant_sys_regs, ARRAY_SIZE(invariant_sys_regs));
+	if (!r)
+		return -ENOENT;
+
+	return reg_to_user(uaddr, &r->val, id);
+}
+
+static int set_invariant_sys_reg(u64 id, void __user *uaddr)
+{
+	struct sys_reg_params params;
+	const struct sys_reg_desc *r;
+	int err;
+	u64 val = 0; /* Make sure high bits are 0 for 32-bit regs */
+
+	if (!index_to_params(id, &params))
+		return -ENOENT;
+	r = find_reg(&params, invariant_sys_regs, ARRAY_SIZE(invariant_sys_regs));
+	if (!r)
+		return -ENOENT;
+
+	err = reg_from_user(&val, uaddr, id);
+	if (err)
+		return err;
+
+	/* This is what we mean by invariant: you can't change it. */
+	if (r->val != val)
+		return -EINVAL;
+
+	return 0;
+}
+
+static bool is_valid_cache(u32 val)
+{
+	u32 level, ctype;
+
+	if (val >= CSSELR_MAX)
+		return -ENOENT;
+
+	/* Bottom bit is Instruction or Data bit.  Next 3 bits are level. */
+        level = (val >> 1);
+        ctype = (cache_levels >> (level * 3)) & 7;
+
+	switch (ctype) {
+	case 0: /* No cache */
+		return false;
+	case 1: /* Instruction cache only */
+		return (val & 1);
+	case 2: /* Data cache only */
+	case 4: /* Unified cache */
+		return !(val & 1);
+	case 3: /* Separate instruction and data caches */
+		return true;
+	default: /* Reserved: we can't know instruction or data. */
+		return false;
+	}
+}
+
+static int demux_c15_get(u64 id, void __user *uaddr)
+{
+	u32 val;
+	u32 __user *uval = uaddr;
+
+	/* Fail if we have unknown bits set. */
+	if (id & ~(KVM_REG_ARCH_MASK|KVM_REG_SIZE_MASK|KVM_REG_ARM_COPROC_MASK
+		   | ((1 << KVM_REG_ARM_COPROC_SHIFT)-1)))
+		return -ENOENT;
+
+	switch (id & KVM_REG_ARM_DEMUX_ID_MASK) {
+	case KVM_REG_ARM_DEMUX_ID_CCSIDR:
+		if (KVM_REG_SIZE(id) != 4)
+			return -ENOENT;
+		val = (id & KVM_REG_ARM_DEMUX_VAL_MASK)
+			>> KVM_REG_ARM_DEMUX_VAL_SHIFT;
+		if (!is_valid_cache(val))
+			return -ENOENT;
+
+		return put_user(get_ccsidr(val), uval);
+	default:
+		return -ENOENT;
+	}
+}
+
+static int demux_c15_set(u64 id, void __user *uaddr)
+{
+	u32 val, newval;
+	u32 __user *uval = uaddr;
+
+	/* Fail if we have unknown bits set. */
+	if (id & ~(KVM_REG_ARCH_MASK|KVM_REG_SIZE_MASK|KVM_REG_ARM_COPROC_MASK
+		   | ((1 << KVM_REG_ARM_COPROC_SHIFT)-1)))
+		return -ENOENT;
+
+	switch (id & KVM_REG_ARM_DEMUX_ID_MASK) {
+	case KVM_REG_ARM_DEMUX_ID_CCSIDR:
+		if (KVM_REG_SIZE(id) != 4)
+			return -ENOENT;
+		val = (id & KVM_REG_ARM_DEMUX_VAL_MASK)
+			>> KVM_REG_ARM_DEMUX_VAL_SHIFT;
+		if (!is_valid_cache(val))
+			return -ENOENT;
+
+		if (get_user(newval, uval))
+			return -EFAULT;
+
+		/* This is also invariant: you can't change it. */
+		if (newval != get_ccsidr(val))
+			return -EINVAL;
+		return 0;
+	default:
+		return -ENOENT;
+	}
+}
+
+int kvm_arm_sys_reg_get_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
+{
+	const struct sys_reg_desc *r;
+	void __user *uaddr = (void __user *)(unsigned long)reg->addr;
+
+	if ((reg->id & KVM_REG_ARM_COPROC_MASK) == KVM_REG_ARM_DEMUX)
+		return demux_c15_get(reg->id, uaddr);
+
+	r = index_to_sys_reg_desc(vcpu, reg->id);
+	if (!r)
+		return get_invariant_sys_reg(reg->id, uaddr);
+
+	/* Note: copies two regs if size is 64 bit. */
+	return reg_to_user(uaddr, &vcpu_sys_reg(vcpu, r->reg), reg->id);
+}
+
+int kvm_arm_sys_reg_set_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
+{
+	const struct sys_reg_desc *r;
+	void __user *uaddr = (void __user *)(unsigned long)reg->addr;
+
+	if ((reg->id & KVM_REG_ARM_COPROC_MASK) == KVM_REG_ARM_DEMUX)
+		return demux_c15_set(reg->id, uaddr);
+
+	r = index_to_sys_reg_desc(vcpu, reg->id);
+	if (!r)
+		return set_invariant_sys_reg(reg->id, uaddr);
+
+	/* Note: copies two regs if size is 64 bit */
+	return reg_from_user(&vcpu_sys_reg(vcpu, r->reg), uaddr, reg->id);
+}
+
+static unsigned int num_demux_regs(void)
+{
+	unsigned int i, count = 0;
+
+	for (i = 0; i < CSSELR_MAX; i++)
+		if (is_valid_cache(i))
+			count++;
+
+	return count;
+}
+
+static int write_demux_regids(u64 __user *uindices)
+{
+	u64 val = KVM_REG_ARM | KVM_REG_SIZE_U32 | KVM_REG_ARM_DEMUX;
+	unsigned int i;
+
+	val |= KVM_REG_ARM_DEMUX_ID_CCSIDR;
+	for (i = 0; i < CSSELR_MAX; i++) {
+		if (!is_valid_cache(i))
+			continue;
+		if (put_user(val | i, uindices))
+			return -EFAULT;
+		uindices++;
+	}
+	return 0;
+}
+
+static u64 sys_reg_to_index(const struct sys_reg_desc *reg)
+{
+	return (KVM_REG_ARM64 | KVM_REG_SIZE_U64 |
+		KVM_REG_ARM64_SYSREG |
+		(reg->Op0 << KVM_REG_ARM64_SYSREG_OP0_SHIFT) |
+		(reg->Op1 << KVM_REG_ARM64_SYSREG_OP1_SHIFT) |
+		(reg->CRn << KVM_REG_ARM64_SYSREG_CRN_SHIFT) |
+		(reg->CRm << KVM_REG_ARM64_SYSREG_CRM_SHIFT) |
+		(reg->Op2 << KVM_REG_ARM64_SYSREG_OP2_SHIFT));
+}
+
+static bool copy_reg_to_user(const struct sys_reg_desc *reg, u64 __user **uind)
+{
+	if (!*uind)
+		return true;
+
+	if (put_user(sys_reg_to_index(reg), *uind))
+		return false;
+
+	(*uind)++;
+	return true;
+}
+
+/* Assumed ordered tables, see kvm_sys_reg_table_init. */
+static int walk_sys_regs(struct kvm_vcpu *vcpu, u64 __user *uind)
+{
+	const struct sys_reg_desc *i1, *i2, *end1, *end2;
+	unsigned int total = 0;
+	size_t num;
+
+	/* We check for duplicates here, to allow arch-specific overrides. */
+	i1 = get_target_table(vcpu->arch.target, &num);
+	end1 = i1 + num;
+	i2 = sys_reg_descs;
+	end2 = sys_reg_descs + ARRAY_SIZE(sys_reg_descs);
+
+	BUG_ON(i1 == end1 || i2 == end2);
+
+	/* Walk carefully, as both tables may refer to the same register. */
+	while (i1 || i2) {
+		int cmp = cmp_sys_reg(i1, i2);
+		/* target-specific overrides generic entry. */
+		if (cmp <= 0) {
+			/* Ignore registers we trap but don't save. */
+			if (i1->reg) {
+				if (!copy_reg_to_user(i1, &uind))
+					return -EFAULT;
+				total++;
+			}
+		} else {
+			/* Ignore registers we trap but don't save. */
+			if (i2->reg) {
+				if (!copy_reg_to_user(i2, &uind))
+					return -EFAULT;
+				total++;
+			}
+		}
+
+		if (cmp <= 0 && ++i1 == end1)
+			i1 = NULL;
+		if (cmp >= 0 && ++i2 == end2)
+			i2 = NULL;
+	}
+	return total;
+}
+
+unsigned long kvm_arm_num_sys_reg_descs(struct kvm_vcpu *vcpu)
+{
+	return ARRAY_SIZE(invariant_sys_regs)
+		+ num_demux_regs()
+		+ walk_sys_regs(vcpu, (u64 __user *)NULL);
+}
+
+int kvm_arm_copy_sys_reg_indices(struct kvm_vcpu *vcpu, u64 __user *uindices)
+{
+	unsigned int i;
+	int err;
+
+	/* Then give them all the invariant registers' indices. */
+	for (i = 0; i < ARRAY_SIZE(invariant_sys_regs); i++) {
+		if (put_user(sys_reg_to_index(&invariant_sys_regs[i]), uindices))
+			return -EFAULT;
+		uindices++;
+	}
+
+	err = walk_sys_regs(vcpu, uindices);
+	if (err < 0)
+		return err;
+	uindices += err;
+
+	return write_demux_regids(uindices);
+}
+
+void kvm_sys_reg_table_init(void)
+{
+	unsigned int i;
+	struct sys_reg_desc clidr;
+
+	/* Make sure tables are unique and in order. */
+	for (i = 1; i < ARRAY_SIZE(sys_reg_descs); i++)
+		BUG_ON(cmp_sys_reg(&sys_reg_descs[i-1], &sys_reg_descs[i]) >= 0);
+
+	/* We abuse the reset function to overwrite the table itself. */
+	for (i = 0; i < ARRAY_SIZE(invariant_sys_regs); i++)
+		invariant_sys_regs[i].reset(NULL, &invariant_sys_regs[i]);
+
+	/*
+	 * CLIDR format is awkward, so clean it up.  See ARM B4.1.20:
+	 *
+	 *   If software reads the Cache Type fields from Ctype1
+	 *   upwards, once it has seen a value of 0b000, no caches
+	 *   exist at further-out levels of the hierarchy. So, for
+	 *   example, if Ctype3 is the first Cache Type field with a
+	 *   value of 0b000, the values of Ctype4 to Ctype7 must be
+	 *   ignored.
+	 */
+	get_clidr_el1(NULL, &clidr); /* Ugly... */
+	cache_levels = clidr.val;
+	for (i = 0; i < 7; i++)
+		if (((cache_levels >> (i*3)) & 7) == 0)
+			break;
+	/* Clear all higher bits. */
+	cache_levels &= (1 << (i*3))-1;
+}
+
+/**
+ * kvm_reset_sys_regs - sets system registers to reset value
+ * @vcpu: The VCPU pointer
+ *
+ * This function finds the right table above and sets the registers on the
+ * virtual CPU struct to their architecturally defined reset values.
+ */
+void kvm_reset_sys_regs(struct kvm_vcpu *vcpu)
+{
+	size_t num;
+	const struct sys_reg_desc *table;
+
+	/* Catch someone adding a register without putting in reset entry. */
+	memset(&vcpu->arch.ctxt.sys_regs, 0x42, sizeof(vcpu->arch.ctxt.sys_regs));
+
+	/* Generic chip reset first (so target could override). */
+	reset_sys_reg_descs(vcpu, sys_reg_descs, ARRAY_SIZE(sys_reg_descs));
+
+	table = get_target_table(vcpu->arch.target, &num);
+	reset_sys_reg_descs(vcpu, table, num);
+
+	for (num = 1; num < NR_SYS_REGS; num++)
+		if (vcpu_sys_reg(vcpu, num) == 0x4242424242424242)
+			panic("Didn't reset vcpu_sys_reg(%zi)", num);
+}
diff --git a/arch/arm64/kvm/sys_regs.h b/arch/arm64/kvm/sys_regs.h
new file mode 100644
index 0000000..d50d372
--- /dev/null
+++ b/arch/arm64/kvm/sys_regs.h
@@ -0,0 +1,138 @@
+/*
+ * Copyright (C) 2012,2013 - ARM Ltd
+ * Author: Marc Zyngier <marc.zyngier at arm.com>
+ *
+ * Derived from arch/arm/kvm/coproc.h
+ * Copyright (C) 2012 - Virtual Open Systems and Columbia University
+ * Authors: Christoffer Dall <c.dall at virtualopensystems.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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#ifndef __ARM64_KVM_SYS_REGS_LOCAL_H__
+#define __ARM64_KVM_SYS_REGS_LOCAL_H__
+
+struct sys_reg_params {
+	u8	Op0;
+	u8	Op1;
+	u8	CRn;
+	u8	CRm;
+	u8	Op2;
+	u8	Rt;
+	bool	is_write;
+};
+
+struct sys_reg_desc {
+	/* MRS/MSR instruction which accesses it. */
+	u8	Op0;
+	u8	Op1;
+	u8	CRn;
+	u8	CRm;
+	u8	Op2;
+
+	/* Trapped access from guest, if non-NULL. */
+	bool (*access)(struct kvm_vcpu *,
+		       const struct sys_reg_params *,
+		       const struct sys_reg_desc *);
+
+	/* Initialization for vcpu. */
+	void (*reset)(struct kvm_vcpu *, const struct sys_reg_desc *);
+
+	/* Index into sys_reg[], or 0 if we don't need to save it. */
+	int reg;
+
+	/* Value (usually reset value) */
+	u64 val;
+};
+
+static inline void print_sys_reg_instr(const struct sys_reg_params *p)
+{
+	/* Look, we even formatted it for you to paste into the table! */
+	kvm_pr_unimpl(" { Op0(%2u), Op1(%2u), CRn(%2u), CRm(%2u), Op2(%2u), func_%s },\n",
+		      p->Op0, p->Op1, p->CRn, p->CRm, p->Op2, p->is_write ? "write" : "read");
+}
+
+static inline bool ignore_write(struct kvm_vcpu *vcpu,
+				const struct sys_reg_params *p)
+{
+	return true;
+}
+
+static inline bool read_zero(struct kvm_vcpu *vcpu,
+			     const struct sys_reg_params *p)
+{
+	*vcpu_reg(vcpu, p->Rt) = 0;
+	return true;
+}
+
+static inline bool write_to_read_only(struct kvm_vcpu *vcpu,
+				      const struct sys_reg_params *params)
+{
+	kvm_debug("sys_reg write to read-only register at: %lx\n",
+		  *vcpu_pc(vcpu));
+	print_sys_reg_instr(params);
+	return false;
+}
+
+static inline bool read_from_write_only(struct kvm_vcpu *vcpu,
+					const struct sys_reg_params *params)
+{
+	kvm_debug("sys_reg read to write-only register at: %lx\n",
+		  *vcpu_pc(vcpu));
+	print_sys_reg_instr(params);
+	return false;
+}
+
+/* Reset functions */
+static inline void reset_unknown(struct kvm_vcpu *vcpu,
+				 const struct sys_reg_desc *r)
+{
+	BUG_ON(!r->reg);
+	BUG_ON(r->reg >= NR_SYS_REGS);
+	vcpu_sys_reg(vcpu, r->reg) = 0x1de7ec7edbadc0deULL;
+}
+
+static inline void reset_val(struct kvm_vcpu *vcpu, const struct sys_reg_desc *r)
+{
+	BUG_ON(!r->reg);
+	BUG_ON(r->reg >= NR_SYS_REGS);
+	vcpu_sys_reg(vcpu, r->reg) = r->val;
+}
+
+static inline int cmp_sys_reg(const struct sys_reg_desc *i1,
+			      const struct sys_reg_desc *i2)
+{
+	BUG_ON(i1 == i2);
+	if (!i1)
+		return 1;
+	else if (!i2)
+		return -1;
+	if (i1->Op0 != i2->Op0)
+		return i1->Op0 - i2->Op0;
+	if (i1->Op1 != i2->Op1)
+		return i1->Op1 - i2->Op1;
+	if (i1->CRn != i2->CRn)
+		return i1->CRn - i2->CRn;
+	if (i1->CRm != i2->CRm)
+		return i1->CRm - i2->CRm;
+	return i1->Op2 - i2->Op2;
+}
+
+
+#define Op0(_x) 	.Op0 = _x
+#define Op1(_x) 	.Op1 = _x
+#define CRn(_x)		.CRn = _x
+#define CRm(_x) 	.CRm = _x
+#define Op2(_x) 	.Op2 = _x
+
+#endif /* __ARM64_KVM_SYS_REGS_LOCAL_H__ */
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 3c56ba3..2bf42b0 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -782,6 +782,7 @@ struct kvm_dirty_tlb {
 #define KVM_REG_IA64		0x3000000000000000ULL
 #define KVM_REG_ARM		0x4000000000000000ULL
 #define KVM_REG_S390		0x5000000000000000ULL
+#define KVM_REG_ARM64		0x6000000000000000ULL
 
 #define KVM_REG_SIZE_SHIFT	52
 #define KVM_REG_SIZE_MASK	0x00f0000000000000ULL
-- 
1.8.1.4




From marc.zyngier at arm.com  Mon Apr  8 12:17:16 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon,  8 Apr 2013 17:17:16 +0100
Subject: [PATCH v3 14/32] arm64: KVM: MMIO access backend
In-Reply-To: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1365437854-30214-15-git-send-email-marc.zyngier@arm.com>

Define the necessary structures to perform an MMIO access.

Reviewed-by: Christopher Covington <cov at codeaurora.org>
Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/include/asm/kvm_mmio.h | 59 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 59 insertions(+)
 create mode 100644 arch/arm64/include/asm/kvm_mmio.h

diff --git a/arch/arm64/include/asm/kvm_mmio.h b/arch/arm64/include/asm/kvm_mmio.h
new file mode 100644
index 0000000..fc2f689
--- /dev/null
+++ b/arch/arm64/include/asm/kvm_mmio.h
@@ -0,0 +1,59 @@
+/*
+ * Copyright (C) 2012 - Virtual Open Systems and Columbia University
+ * Author: Christoffer Dall <c.dall at virtualopensystems.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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#ifndef __ARM64_KVM_MMIO_H__
+#define __ARM64_KVM_MMIO_H__
+
+#include <linux/kvm_host.h>
+#include <asm/kvm_asm.h>
+#include <asm/kvm_arm.h>
+
+/*
+ * This is annoying. The mmio code requires this, even if we don't
+ * need any decoding. To be fixed.
+ */
+struct kvm_decode {
+	unsigned long rt;
+	bool sign_extend;
+};
+
+/*
+ * The in-kernel MMIO emulation code wants to use a copy of run->mmio,
+ * which is an anonymous type. Use our own type instead.
+ */
+struct kvm_exit_mmio {
+	phys_addr_t	phys_addr;
+	u8		data[8];
+	u32		len;
+	bool		is_write;
+};
+
+static inline void kvm_prepare_mmio(struct kvm_run *run,
+				    struct kvm_exit_mmio *mmio)
+{
+	run->mmio.phys_addr	= mmio->phys_addr;
+	run->mmio.len		= mmio->len;
+	run->mmio.is_write	= mmio->is_write;
+	memcpy(run->mmio.data, mmio->data, mmio->len);
+	run->exit_reason	= KVM_EXIT_MMIO;
+}
+
+int kvm_handle_mmio_return(struct kvm_vcpu *vcpu, struct kvm_run *run);
+int io_mem_abort(struct kvm_vcpu *vcpu, struct kvm_run *run,
+		 phys_addr_t fault_ipa);
+
+#endif	/* __ARM64_KVM_MMIO_H__ */
-- 
1.8.1.4




From marc.zyngier at arm.com  Mon Apr  8 12:17:28 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon,  8 Apr 2013 17:17:28 +0100
Subject: [PATCH v3 26/32] arm64: KVM: 32bit handling of coprocessor traps
In-Reply-To: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1365437854-30214-27-git-send-email-marc.zyngier@arm.com>

Provide the necessary infrastructure to trap coprocessor accesses that
occur when running 32bit guests.

Also wire SMC and HVC trapped in 32bit mode while were at it.

Reviewed-by: Christopher Covington <cov at codeaurora.org>
Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/include/asm/kvm_coproc.h |   5 +
 arch/arm64/kvm/handle_exit.c        |   7 ++
 arch/arm64/kvm/sys_regs.c           | 178 ++++++++++++++++++++++++++++++++++--
 3 files changed, 183 insertions(+), 7 deletions(-)

diff --git a/arch/arm64/include/asm/kvm_coproc.h b/arch/arm64/include/asm/kvm_coproc.h
index 9b4477a..9a59301 100644
--- a/arch/arm64/include/asm/kvm_coproc.h
+++ b/arch/arm64/include/asm/kvm_coproc.h
@@ -32,11 +32,16 @@ struct kvm_sys_reg_table {
 
 struct kvm_sys_reg_target_table {
 	struct kvm_sys_reg_table table64;
+	struct kvm_sys_reg_table table32;
 };
 
 void kvm_register_target_sys_reg_table(unsigned int target,
 				       struct kvm_sys_reg_target_table *table);
 
+int kvm_handle_cp14_load_store(struct kvm_vcpu *vcpu, struct kvm_run *run);
+int kvm_handle_cp14_access(struct kvm_vcpu *vcpu, struct kvm_run *run);
+int kvm_handle_cp15_32(struct kvm_vcpu *vcpu, struct kvm_run *run);
+int kvm_handle_cp15_64(struct kvm_vcpu *vcpu, struct kvm_run *run);
 int kvm_handle_sys_reg(struct kvm_vcpu *vcpu, struct kvm_run *run);
 
 #define kvm_coproc_table_init kvm_sys_reg_table_init
diff --git a/arch/arm64/kvm/handle_exit.c b/arch/arm64/kvm/handle_exit.c
index 4766b7f..9beaca03 100644
--- a/arch/arm64/kvm/handle_exit.c
+++ b/arch/arm64/kvm/handle_exit.c
@@ -62,6 +62,13 @@ static int kvm_handle_wfi(struct kvm_vcpu *vcpu, struct kvm_run *run)
 
 static exit_handle_fn arm_exit_handlers[] = {
 	[ESR_EL2_EC_WFI]	= kvm_handle_wfi,
+	[ESR_EL2_EC_CP15_32]	= kvm_handle_cp15_32,
+	[ESR_EL2_EC_CP15_64]	= kvm_handle_cp15_64,
+	[ESR_EL2_EC_CP14_MR]	= kvm_handle_cp14_access,
+	[ESR_EL2_EC_CP14_LS]	= kvm_handle_cp14_load_store,
+	[ESR_EL2_EC_CP14_64]	= kvm_handle_cp14_access,
+	[ESR_EL2_EC_HVC32]	= handle_hvc,
+	[ESR_EL2_EC_SMC32]	= handle_smc,
 	[ESR_EL2_EC_HVC64]	= handle_hvc,
 	[ESR_EL2_EC_SMC64]	= handle_smc,
 	[ESR_EL2_EC_SYS64]	= kvm_handle_sys_reg,
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index 9df3b32..0303218 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -38,6 +38,10 @@
  * types are different. My gut feeling is that it should be pretty
  * easy to merge, but that would be an ABI breakage -- again. VFP
  * would also need to be abstracted.
+ *
+ * For AArch32, we only take care of what is being trapped. Anything
+ * that has to do with init and userspace access has to go via the
+ * 64bit interface.
  */
 
 /* 3 bits per cache level, as per CLIDR, but non-existent caches always 0 */
@@ -163,6 +167,16 @@ static const struct sys_reg_desc sys_reg_descs[] = {
 	{ Op0(0b01), Op1(0b000), CRn(0b0111), CRm(0b1110), Op2(0b010),
 	  access_dcsw },
 
+	/* TEECR32_EL1 */
+	{ Op0(0b10), Op1(0b010), CRn(0b0000), CRm(0b0000), Op2(0b000),
+	  NULL, reset_val, TEECR32_EL1, 0 },
+	/* TEEHBR32_EL1 */
+	{ Op0(0b10), Op1(0b010), CRn(0b0001), CRm(0b0000), Op2(0b000),
+	  NULL, reset_val, TEEHBR32_EL1, 0 },
+	/* DBGVCR32_EL2 */
+	{ Op0(0b10), Op1(0b100), CRn(0b0000), CRm(0b0111), Op2(0b000),
+	  NULL, reset_val, DBGVCR32_EL2, 0 },
+
 	/* MPIDR_EL1 */
 	{ Op0(0b11), Op1(0b000), CRn(0b0000), CRm(0b0000), Op2(0b101),
 	  NULL, reset_mpidr, MPIDR_EL1 },
@@ -273,6 +287,39 @@ static const struct sys_reg_desc sys_reg_descs[] = {
 	/* TPIDRRO_EL0 */
 	{ Op0(0b11), Op1(0b011), CRn(0b1101), CRm(0b0000), Op2(0b011),
 	  NULL, reset_unknown, TPIDRRO_EL0 },
+
+	/* DACR32_EL2 */
+	{ Op0(0b11), Op1(0b100), CRn(0b0011), CRm(0b0000), Op2(0b000),
+	  NULL, reset_unknown, DACR32_EL2 },
+	/* IFSR32_EL2 */
+	{ Op0(0b11), Op1(0b100), CRn(0b0101), CRm(0b0000), Op2(0b001),
+	  NULL, reset_unknown, IFSR32_EL2 },
+	/* FPEXC32_EL2 */
+	{ Op0(0b11), Op1(0b100), CRn(0b0101), CRm(0b0011), Op2(0b000),
+	  NULL, reset_val, FPEXC32_EL2, 0x70 },
+};
+
+/* Trapped cp15 registers */
+static const struct sys_reg_desc cp15_regs[] = {
+	/*
+	 * DC{C,I,CI}SW operations:
+	 */
+	{ Op1( 0), CRn( 7), CRm( 6), Op2( 2), access_dcsw },
+	{ Op1( 0), CRn( 7), CRm(10), Op2( 2), access_dcsw },
+	{ Op1( 0), CRn( 7), CRm(14), Op2( 2), access_dcsw },
+	{ Op1( 0), CRn( 9), CRm(12), Op2( 0), pm_fake },
+	{ Op1( 0), CRn( 9), CRm(12), Op2( 1), pm_fake },
+	{ Op1( 0), CRn( 9), CRm(12), Op2( 2), pm_fake },
+	{ Op1( 0), CRn( 9), CRm(12), Op2( 3), pm_fake },
+	{ Op1( 0), CRn( 9), CRm(12), Op2( 5), pm_fake },
+	{ Op1( 0), CRn( 9), CRm(12), Op2( 6), pm_fake },
+	{ Op1( 0), CRn( 9), CRm(12), Op2( 7), pm_fake },
+	{ Op1( 0), CRn( 9), CRm(13), Op2( 0), pm_fake },
+	{ Op1( 0), CRn( 9), CRm(13), Op2( 1), pm_fake },
+	{ Op1( 0), CRn( 9), CRm(13), Op2( 2), pm_fake },
+	{ Op1( 0), CRn( 9), CRm(14), Op2( 0), pm_fake },
+	{ Op1( 0), CRn( 9), CRm(14), Op2( 1), pm_fake },
+	{ Op1( 0), CRn( 9), CRm(14), Op2( 2), pm_fake },
 };
 
 /* Target specific emulation tables */
@@ -285,13 +332,20 @@ void kvm_register_target_sys_reg_table(unsigned int target,
 }
 
 /* Get specific register table for this target. */
-static const struct sys_reg_desc *get_target_table(unsigned target, size_t *num)
+static const struct sys_reg_desc *get_target_table(unsigned target,
+						   bool mode_is_64,
+						   size_t *num)
 {
 	struct kvm_sys_reg_target_table *table;
 
 	table = target_tables[target];
-	*num = table->table64.num;
-	return table->table64.table;
+	if (mode_is_64) {
+		*num = table->table64.num;
+		return table->table64.table;
+	} else {
+		*num = table->table32.num;
+		return table->table32.table;
+	}
 }
 
 static const struct sys_reg_desc *find_reg(const struct sys_reg_params *params,
@@ -319,13 +373,123 @@ static const struct sys_reg_desc *find_reg(const struct sys_reg_params *params,
 	return NULL;
 }
 
+int kvm_handle_cp14_load_store(struct kvm_vcpu *vcpu, struct kvm_run *run)
+{
+	kvm_inject_undefined(vcpu);
+	return 1;
+}
+
+int kvm_handle_cp14_access(struct kvm_vcpu *vcpu, struct kvm_run *run)
+{
+	kvm_inject_undefined(vcpu);
+	return 1;
+}
+
+static int emulate_cp15(struct kvm_vcpu *vcpu,
+			const struct sys_reg_params *params)
+{
+	size_t num;
+	const struct sys_reg_desc *table, *r;
+
+	table = get_target_table(vcpu->arch.target, false, &num);
+
+	/* Search target-specific then generic table. */
+	r = find_reg(params, table, num);
+	if (!r)
+		r = find_reg(params, cp15_regs, ARRAY_SIZE(cp15_regs));
+
+	if (likely(r)) {
+		/* If we don't have an accessor, we should never get here! */
+		BUG_ON(!r->access);
+
+		if (likely(r->access(vcpu, params, r))) {
+			/* Skip instruction, since it was emulated */
+			kvm_skip_instr(vcpu, kvm_vcpu_trap_il_is32bit(vcpu));
+			return 1;
+		}
+		/* If access function fails, it should complain. */
+	} else {
+		kvm_err("Unsupported guest CP15 access at: %08lx\n",
+			*vcpu_pc(vcpu));
+		print_sys_reg_instr(params);
+	}
+	kvm_inject_undefined(vcpu);
+	return 1;
+}
+
+/**
+ * kvm_handle_cp15_64 -- handles a mrrc/mcrr trap on a guest CP15 access
+ * @vcpu: The VCPU pointer
+ * @run:  The kvm_run struct
+ */
+int kvm_handle_cp15_64(struct kvm_vcpu *vcpu, struct kvm_run *run)
+{
+	struct sys_reg_params params;
+	u32 hsr = kvm_vcpu_get_hsr(vcpu);
+	int Rt2 = (hsr >> 10) & 0xf;
+	int ret;
+
+	params.CRm = (hsr >> 1) & 0xf;
+	params.Rt = (hsr >> 5) & 0xf;
+	params.is_write = ((hsr & 1) == 0);
+
+	params.Op0 = 0;
+	params.Op1 = (hsr >> 16) & 0xf;
+	params.Op2 = 0;
+	params.CRn = 0;
+
+	/*
+	 * Massive hack here. Store Rt2 in the top 32bits so we only
+	 * have one register to deal with. As we use the same trap
+	 * backends between AArch32 and AArch64, we get away with it.
+	 */
+	if (params.is_write) {
+		u64 val = *vcpu_reg(vcpu, params.Rt);
+		val &= 0xffffffff;
+		val |= *vcpu_reg(vcpu, Rt2) << 32;
+		*vcpu_reg(vcpu, params.Rt) = val;
+	}
+
+	ret = emulate_cp15(vcpu, &params);
+
+	/* Reverse hack here */
+	if (ret && !params.is_write) {
+		u64 val = *vcpu_reg(vcpu, params.Rt);
+		val >>= 32;
+		*vcpu_reg(vcpu, Rt2) = val;
+	}
+
+	return ret;
+}
+
+/**
+ * kvm_handle_cp15_32 -- handles a mrc/mcr trap on a guest CP15 access
+ * @vcpu: The VCPU pointer
+ * @run:  The kvm_run struct
+ */
+int kvm_handle_cp15_32(struct kvm_vcpu *vcpu, struct kvm_run *run)
+{
+	struct sys_reg_params params;
+	u32 hsr = kvm_vcpu_get_hsr(vcpu);
+
+	params.CRm = (hsr >> 1) & 0xf;
+	params.Rt  = (hsr >> 5) & 0xf;
+	params.is_write = ((hsr & 1) == 0);
+	params.CRn = (hsr >> 10) & 0xf;
+	params.Op0 = 0;
+	params.Op1 = (hsr >> 14) & 0x7;
+	params.Op2 = (hsr >> 17) & 0x7;
+
+	return emulate_cp15(vcpu, &params);
+}
+
 static int emulate_sys_reg(struct kvm_vcpu *vcpu,
 			   const struct sys_reg_params *params)
 {
 	size_t num;
 	const struct sys_reg_desc *table, *r;
 
-	table = get_target_table(vcpu->arch.target, &num);
+	table = get_target_table(vcpu->arch.target, true, &num);
 
 	/* Search target-specific then generic table. */
 	r = find_reg(params, table, num);
@@ -430,7 +594,7 @@ static const struct sys_reg_desc *index_to_sys_reg_desc(struct kvm_vcpu *vcpu,
 	if (!index_to_params(id, &params))
 		return NULL;
 
-	table = get_target_table(vcpu->arch.target, &num);
+	table = get_target_table(vcpu->arch.target, true, &num);
 	r = find_reg(&params, table, num);
 	if (!r)
 		r = find_reg(&params, sys_reg_descs, ARRAY_SIZE(sys_reg_descs));
@@ -750,7 +914,7 @@ static int walk_sys_regs(struct kvm_vcpu *vcpu, u64 __user *uind)
 	size_t num;
 
 	/* We check for duplicates here, to allow arch-specific overrides. */
-	i1 = get_target_table(vcpu->arch.target, &num);
+	i1 = get_target_table(vcpu->arch.target, true, &num);
 	end1 = i1 + num;
 	i2 = sys_reg_descs;
 	end2 = sys_reg_descs + ARRAY_SIZE(sys_reg_descs);
@@ -862,7 +1026,7 @@ void kvm_reset_sys_regs(struct kvm_vcpu *vcpu)
 	/* Generic chip reset first (so target could override). */
 	reset_sys_reg_descs(vcpu, sys_reg_descs, ARRAY_SIZE(sys_reg_descs));
 
-	table = get_target_table(vcpu->arch.target, &num);
+	table = get_target_table(vcpu->arch.target, true, &num);
 	reset_sys_reg_descs(vcpu, table, num);
 
 	for (num = 1; num < NR_SYS_REGS; num++)
-- 
1.8.1.4




From marc.zyngier at arm.com  Mon Apr  8 12:17:21 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon,  8 Apr 2013 17:17:21 +0100
Subject: [PATCH v3 19/32] arm64: KVM: Plug the VGIC
In-Reply-To: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1365437854-30214-20-git-send-email-marc.zyngier@arm.com>

Add support for the in-kernel GIC emulation. The include file
is a complete duplicate of the 32bit one - something to fix
at one point.

Reviewed-by: Christopher Covington <cov at codeaurora.org>
Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/include/asm/kvm_vgic.h | 156 ++++++++++++++++++++++++++++++++++++++
 arch/arm64/kvm/hyp.S              |  88 +++++++++++++++++++++
 2 files changed, 244 insertions(+)
 create mode 100644 arch/arm64/include/asm/kvm_vgic.h

diff --git a/arch/arm64/include/asm/kvm_vgic.h b/arch/arm64/include/asm/kvm_vgic.h
new file mode 100644
index 0000000..f353f22
--- /dev/null
+++ b/arch/arm64/include/asm/kvm_vgic.h
@@ -0,0 +1,156 @@
+/*
+ * Copyright (C) 2012 ARM Ltd.
+ * Author: Marc Zyngier <marc.zyngier at arm.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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#ifndef __ARM64_KVM_VGIC_H
+#define __ARM64_KVM_VGIC_H
+
+#include <linux/kernel.h>
+#include <linux/kvm.h>
+#include <linux/irqreturn.h>
+#include <linux/spinlock.h>
+#include <linux/types.h>
+#include <linux/irqchip/arm-gic.h>
+
+#define VGIC_NR_IRQS		128
+#define VGIC_NR_SGIS		16
+#define VGIC_NR_PPIS		16
+#define VGIC_NR_PRIVATE_IRQS	(VGIC_NR_SGIS + VGIC_NR_PPIS)
+#define VGIC_NR_SHARED_IRQS	(VGIC_NR_IRQS - VGIC_NR_PRIVATE_IRQS)
+#define VGIC_MAX_CPUS		KVM_MAX_VCPUS
+
+/* Sanity checks... */
+#if (VGIC_MAX_CPUS > 8)
+#error	Invalid number of CPU interfaces
+#endif
+
+#if (VGIC_NR_IRQS & 31)
+#error "VGIC_NR_IRQS must be a multiple of 32"
+#endif
+
+#if (VGIC_NR_IRQS > 1024)
+#error "VGIC_NR_IRQS must be <= 1024"
+#endif
+
+/*
+ * The GIC distributor registers describing interrupts have two parts:
+ * - 32 per-CPU interrupts (SGI + PPI)
+ * - a bunch of shared interrupts (SPI)
+ */
+struct vgic_bitmap {
+	union {
+		u32 reg[VGIC_NR_PRIVATE_IRQS / 32];
+		DECLARE_BITMAP(reg_ul, VGIC_NR_PRIVATE_IRQS);
+	} percpu[VGIC_MAX_CPUS];
+	union {
+		u32 reg[VGIC_NR_SHARED_IRQS / 32];
+		DECLARE_BITMAP(reg_ul, VGIC_NR_SHARED_IRQS);
+	} shared;
+};
+
+struct vgic_bytemap {
+	u32 percpu[VGIC_MAX_CPUS][VGIC_NR_PRIVATE_IRQS / 4];
+	u32 shared[VGIC_NR_SHARED_IRQS  / 4];
+};
+
+struct vgic_dist {
+	spinlock_t		lock;
+	bool			ready;
+
+	/* Virtual control interface mapping */
+	void __iomem		*vctrl_base;
+
+	/* Distributor and vcpu interface mapping in the guest */
+	phys_addr_t		vgic_dist_base;
+	phys_addr_t		vgic_cpu_base;
+
+	/* Distributor enabled */
+	u32			enabled;
+
+	/* Interrupt enabled (one bit per IRQ) */
+	struct vgic_bitmap	irq_enabled;
+
+	/* Interrupt 'pin' level */
+	struct vgic_bitmap	irq_state;
+
+	/* Level-triggered interrupt in progress */
+	struct vgic_bitmap	irq_active;
+
+	/* Interrupt priority. Not used yet. */
+	struct vgic_bytemap	irq_priority;
+
+	/* Level/edge triggered */
+	struct vgic_bitmap	irq_cfg;
+
+	/* Source CPU per SGI and target CPU */
+	u8			irq_sgi_sources[VGIC_MAX_CPUS][16];
+
+	/* Target CPU for each IRQ */
+	u8			irq_spi_cpu[VGIC_NR_SHARED_IRQS];
+	struct vgic_bitmap	irq_spi_target[VGIC_MAX_CPUS];
+
+	/* Bitmap indicating which CPU has something pending */
+	unsigned long		irq_pending_on_cpu;
+};
+
+struct vgic_cpu {
+	/* per IRQ to LR mapping */
+	u8		vgic_irq_lr_map[VGIC_NR_IRQS];
+
+	/* Pending interrupts on this VCPU */
+	DECLARE_BITMAP(	pending_percpu, VGIC_NR_PRIVATE_IRQS);
+	DECLARE_BITMAP(	pending_shared, VGIC_NR_SHARED_IRQS);
+
+	/* Bitmap of used/free list registers */
+	DECLARE_BITMAP(	lr_used, 64);
+
+	/* Number of list registers on this CPU */
+	int		nr_lr;
+
+	/* CPU vif control registers for world switch */
+	u32		vgic_hcr;
+	u32		vgic_vmcr;
+	u32		vgic_misr;	/* Saved only */
+	u32		vgic_eisr[2];	/* Saved only */
+	u32		vgic_elrsr[2];	/* Saved only */
+	u32		vgic_apr;
+	u32		vgic_lr[64];	/* A15 has only 4... */
+};
+
+#define LR_EMPTY	0xff
+
+struct kvm;
+struct kvm_vcpu;
+struct kvm_run;
+struct kvm_exit_mmio;
+
+int kvm_vgic_set_addr(struct kvm *kvm, unsigned long type, u64 addr);
+int kvm_vgic_hyp_init(void);
+int kvm_vgic_init(struct kvm *kvm);
+int kvm_vgic_create(struct kvm *kvm);
+int kvm_vgic_vcpu_init(struct kvm_vcpu *vcpu);
+void kvm_vgic_flush_hwstate(struct kvm_vcpu *vcpu);
+void kvm_vgic_sync_hwstate(struct kvm_vcpu *vcpu);
+int kvm_vgic_inject_irq(struct kvm *kvm, int cpuid, unsigned int irq_num,
+			bool level);
+int kvm_vgic_vcpu_pending_irq(struct kvm_vcpu *vcpu);
+bool vgic_handle_mmio(struct kvm_vcpu *vcpu, struct kvm_run *run,
+		      struct kvm_exit_mmio *mmio);
+
+#define irqchip_in_kernel(k)	(!!((k)->arch.vgic.vctrl_base))
+#define vgic_initialized(k)	((k)->arch.vgic.ready)
+
+#endif
diff --git a/arch/arm64/kvm/hyp.S b/arch/arm64/kvm/hyp.S
index c745d20..cc3192e 100644
--- a/arch/arm64/kvm/hyp.S
+++ b/arch/arm64/kvm/hyp.S
@@ -306,6 +306,90 @@ __kvm_hyp_code_start:
 	msr	vttbr_el2, xzr
 .endm
 
+/*
+ * Save the VGIC CPU state into memory
+ * x0: Register pointing to VCPU struct
+ * Do not corrupt x1!!!
+ */
+.macro save_vgic_state
+	/* Get VGIC VCTRL base into x2 */
+	ldr	x2, [x0, #VCPU_KVM]
+	kern_hyp_va	x2
+	ldr	x2, [x2, #KVM_VGIC_VCTRL]
+	kern_hyp_va	x2
+	cbz	x2, 2f		// disabled
+
+	/* Compute the address of struct vgic_cpu */
+	add	x3, x0, #VCPU_VGIC_CPU
+
+	/* Save all interesting registers */
+	ldr	w4, [x2, #GICH_HCR]
+	ldr	w5, [x2, #GICH_VMCR]
+	ldr	w6, [x2, #GICH_MISR]
+	ldr	w7, [x2, #GICH_EISR0]
+	ldr	w8, [x2, #GICH_EISR1]
+	ldr	w9, [x2, #GICH_ELRSR0]
+	ldr	w10, [x2, #GICH_ELRSR1]
+	ldr	w11, [x2, #GICH_APR]
+
+	str	w4, [x3, #VGIC_CPU_HCR]
+	str	w5, [x3, #VGIC_CPU_VMCR]
+	str	w6, [x3, #VGIC_CPU_MISR]
+	str	w7, [x3, #VGIC_CPU_EISR]
+	str	w8, [x3, #(VGIC_CPU_EISR + 4)]
+	str	w9, [x3, #VGIC_CPU_ELRSR]
+	str	w10, [x3, #(VGIC_CPU_ELRSR + 4)]
+	str	w11, [x3, #VGIC_CPU_APR]
+
+	/* Clear GICH_HCR */
+	str	wzr, [x2, #GICH_HCR]
+
+	/* Save list registers */
+	add	x2, x2, #GICH_LR0
+	ldr	w4, [x3, #VGIC_CPU_NR_LR]
+	add	x3, x3, #VGIC_CPU_LR
+1:	ldr	w5, [x2], #4
+	str	w5, [x3], #4
+	sub	w4, w4, #1
+	cbnz	w4, 1b
+2:
+.endm
+
+/*
+ * Restore the VGIC CPU state from memory
+ * x0: Register pointing to VCPU struct
+ */
+.macro restore_vgic_state
+	/* Get VGIC VCTRL base into x2 */
+	ldr	x2, [x0, #VCPU_KVM]
+	kern_hyp_va	x2
+	ldr	x2, [x2, #KVM_VGIC_VCTRL]
+	kern_hyp_va	x2
+	cbz	x2, 2f		// disabled
+
+	/* Compute the address of struct vgic_cpu */
+	add	x3, x0, #VCPU_VGIC_CPU
+
+	/* We only restore a minimal set of registers */
+	ldr	w4, [x3, #VGIC_CPU_HCR]
+	ldr	w5, [x3, #VGIC_CPU_VMCR]
+	ldr	w6, [x3, #VGIC_CPU_APR]
+
+	str	w4, [x2, #GICH_HCR]
+	str	w5, [x2, #GICH_VMCR]
+	str	w6, [x2, #GICH_APR]
+
+	/* Restore list registers */
+	add	x2, x2, #GICH_LR0
+	ldr	w4, [x3, #VGIC_CPU_NR_LR]
+	add	x3, x3, #VGIC_CPU_LR
+1:	ldr	w5, [x3], #4
+	str	w5, [x2], #4
+	sub	w4, w4, #1
+	cbnz	w4, 1b
+2:
+.endm
+
 __save_sysregs:
 	save_sysregs
 	ret
@@ -348,6 +432,8 @@ ENTRY(__kvm_vcpu_run)
 	activate_traps
 	activate_vm
 
+	restore_vgic_state
+
 	// Guest context
 	add	x2, x0, #VCPU_CONTEXT
 
@@ -370,6 +456,8 @@ __kvm_vcpu_return:
 	bl __save_fpsimd
 	bl __save_sysregs
 
+	save_vgic_state
+
 	deactivate_traps
 	deactivate_vm
 
-- 
1.8.1.4




From paul at pwsan.com  Mon Apr  8 12:23:32 2013
From: paul at pwsan.com (Paul Walmsley)
Date: Mon, 8 Apr 2013 16:23:32 +0000 (UTC)
Subject: [PATCH] ARM: OMAP4: PM: fix PM regression introduced by recent
 clock cleanup
In-Reply-To: <5162B019.6050407@ti.com>
References: <alpine.DEB.2.00.1302122026530.29149@utopia.booyaka.com>
 <5162B019.6050407@ti.com>
Message-ID: <alpine.DEB.2.00.1304081617470.32105@utopia.booyaka.com>

Hi,

On Mon, 8 Apr 2013, Kishon Vijay Abraham I wrote:

> On Wednesday 13 February 2013 01:58 AM, Paul Walmsley wrote:
> > 
> > Commit 17b7e7d33530e2bbd3bdc90f4db09b91cfdde2bb ("ARM: OMAP4:
> > clock/hwmod data: start to remove some IP block control "clocks"")
> > introduced a regression preventing the L3INIT clockdomain of OMAP4
> > systems from entering idle.  This in turn prevented these systems from
> > entering full chip clock-stop.
> > 
> > The regression was caused by the incorrect removal of a so-called
> > "optional functional clock" from the OMAP4 clock data.  This wasn't
> > caught for two reasons.  First, I missed the retention entry failure
> > in the branch test logs:
> > 
> > http://www.pwsan.com/omap/testlogs/cleanup_a_3.9/20130126014242/pm/4460pandaes/4460pandaes_log.txt
> > 
> > Second, the integration data for the OCP2SCP PHY IP block, added by
> > commit 0c6688753f9912c6a7013549ec31c8844020bbc1 ("ARM: OMAP4: hwmod
> > data: add remaining USB-related IP blocks"), should have associated this
> > clock with the IP block, but did not.
> > 
> > Fix by adding back the so-called "optional" functional clock to the
> > clock data, and by linking that clock to the OCP2SCP PHY IP block
> > integration hwmod data.
> 
> This patch breaks MUSB in OMAP4 panda. The 48M clock is modeled as main clk
> [1] for ocp2scp so after doing get_sync, this optional clock gets enabled. But
> after this patch, the optional clock seems to be not enabled after get_sync.
> 
> http://lists.infradead.org/pipermail/linux-arm-kernel/2012-September/118285.html
> (this patch is not directly merged but I guess the discussion here is taken
> care of)

The OMAP integration for the MUSB driver needs to clk_enable() and 
clk_disable() its optional clock.  It's not correct to work around a 
driver problem by changing the hardware description data - that data is 
intended to be driver-neutral.


- Paul


From arnd at arndb.de  Mon Apr  8 12:24:35 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 8 Apr 2013 18:24:35 +0200
Subject: [GIT PULL 1/3] omap non critical fixes for v3.10 merge window
In-Reply-To: <pull-1364923751-842943>
References: <pull-1364923751-842943>
Message-ID: <201304081824.35663.arnd@arndb.de>

On Tuesday 02 April 2013, Tony Lindgren wrote:
> The following changes since commit 07961ac7c0ee8b546658717034fe692fd12eefa9:
> 
>   Linux 3.9-rc5 (2013-03-31 15:12:43 -0700)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.10/fixes-non-critical-signed
> 
> for you to fetch changes up to 105612489bf59386b46b3f9f034e03f70e57aee6:
> 
>   Merge branch 'for_3.10/omap5_generic_updates' of git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux into omap-for-v3.10/fixes-non-critical (2013-04-01 09:30:47 -0700)
> 

Pulled all three branches, thanks a lot!

The cleanup branch conflicted with a bug fix from Paul Walmsley that Linus
already merged, see below for the resolution that I used, adding a modified
line from the one Paul submitted.

	Arnd

commit dde86de7d54a47779b312919ebb9b8a4c48ce192
Merge: e11f1ec 6fa6183
Author: Arnd Bergmann <arnd at arndb.de>
Date:   Mon Apr 8 18:07:35 2013 +0200

    Merge branch 'next/cleanup' into for-next
    
    Conflicts:
    	arch/arm/mach-omap2/cclock44xx_data.c

index 0c6834a,b1e77ef..88e37a4
--- a/arch/arm/mach-omap2/cclock44xx_data.c
+++ b/arch/arm/mach-omap2/cclock44xx_data.c
@@@ -1424,255 -1413,265 +1424,266 @@@ DEFINE_CLK_MUX(auxclkreq5_ck, auxclkreq
  	       0x0, NULL);
  
  /*
-  * clkdev
+  * clocks specific to omap4460
   */
+ static struct omap_clk omap446x_clks[] = {
+ 	CLK(NULL,	"div_ts_ck",			&div_ts_ck),
+ 	CLK(NULL,	"bandgap_ts_fclk",		&bandgap_ts_fclk),
+ };
+ 
+ /*
+  * clocks specific to omap4430
+  */
+ static struct omap_clk omap443x_clks[] = {
+ 	CLK(NULL,	"bandgap_fclk",			&bandgap_fclk),
+ };
  
+ /*
+  * clocks common to omap44xx
+  */
  static struct omap_clk omap44xx_clks[] = {
- 	CLK(NULL,	"extalt_clkin_ck",		&extalt_clkin_ck,	CK_443X),
- 	CLK(NULL,	"pad_clks_src_ck",		&pad_clks_src_ck,	CK_443X),
- 	CLK(NULL,	"pad_clks_ck",			&pad_clks_ck,	CK_443X),
- 	CLK(NULL,	"pad_slimbus_core_clks_ck",	&pad_slimbus_core_clks_ck,	CK_443X),
- 	CLK(NULL,	"secure_32k_clk_src_ck",	&secure_32k_clk_src_ck,	CK_443X),
- 	CLK(NULL,	"slimbus_src_clk",		&slimbus_src_clk,	CK_443X),
- 	CLK(NULL,	"slimbus_clk",			&slimbus_clk,	CK_443X),
- 	CLK(NULL,	"sys_32k_ck",			&sys_32k_ck,	CK_443X),
- 	CLK(NULL,	"virt_12000000_ck",		&virt_12000000_ck,	CK_443X),
- 	CLK(NULL,	"virt_13000000_ck",		&virt_13000000_ck,	CK_443X),
- 	CLK(NULL,	"virt_16800000_ck",		&virt_16800000_ck,	CK_443X),
- 	CLK(NULL,	"virt_19200000_ck",		&virt_19200000_ck,	CK_443X),
- 	CLK(NULL,	"virt_26000000_ck",		&virt_26000000_ck,	CK_443X),
- 	CLK(NULL,	"virt_27000000_ck",		&virt_27000000_ck,	CK_443X),
- 	CLK(NULL,	"virt_38400000_ck",		&virt_38400000_ck,	CK_443X),
- 	CLK(NULL,	"sys_clkin_ck",			&sys_clkin_ck,	CK_443X),
- 	CLK(NULL,	"tie_low_clock_ck",		&tie_low_clock_ck,	CK_443X),
- 	CLK(NULL,	"utmi_phy_clkout_ck",		&utmi_phy_clkout_ck,	CK_443X),
- 	CLK(NULL,	"xclk60mhsp1_ck",		&xclk60mhsp1_ck,	CK_443X),
- 	CLK(NULL,	"xclk60mhsp2_ck",		&xclk60mhsp2_ck,	CK_443X),
- 	CLK(NULL,	"xclk60motg_ck",		&xclk60motg_ck,	CK_443X),
- 	CLK(NULL,	"abe_dpll_bypass_clk_mux_ck",	&abe_dpll_bypass_clk_mux_ck,	CK_443X),
- 	CLK(NULL,	"abe_dpll_refclk_mux_ck",	&abe_dpll_refclk_mux_ck,	CK_443X),
- 	CLK(NULL,	"dpll_abe_ck",			&dpll_abe_ck,	CK_443X),
- 	CLK(NULL,	"dpll_abe_x2_ck",		&dpll_abe_x2_ck,	CK_443X),
- 	CLK(NULL,	"dpll_abe_m2x2_ck",		&dpll_abe_m2x2_ck,	CK_443X),
- 	CLK(NULL,	"abe_24m_fclk",			&abe_24m_fclk,	CK_443X),
- 	CLK(NULL,	"abe_clk",			&abe_clk,	CK_443X),
- 	CLK(NULL,	"aess_fclk",			&aess_fclk,	CK_443X),
- 	CLK(NULL,	"dpll_abe_m3x2_ck",		&dpll_abe_m3x2_ck,	CK_443X),
- 	CLK(NULL,	"core_hsd_byp_clk_mux_ck",	&core_hsd_byp_clk_mux_ck,	CK_443X),
- 	CLK(NULL,	"dpll_core_ck",			&dpll_core_ck,	CK_443X),
- 	CLK(NULL,	"dpll_core_x2_ck",		&dpll_core_x2_ck,	CK_443X),
- 	CLK(NULL,	"dpll_core_m6x2_ck",		&dpll_core_m6x2_ck,	CK_443X),
- 	CLK(NULL,	"dbgclk_mux_ck",		&dbgclk_mux_ck,	CK_443X),
- 	CLK(NULL,	"dpll_core_m2_ck",		&dpll_core_m2_ck,	CK_443X),
- 	CLK(NULL,	"ddrphy_ck",			&ddrphy_ck,	CK_443X),
- 	CLK(NULL,	"dpll_core_m5x2_ck",		&dpll_core_m5x2_ck,	CK_443X),
- 	CLK(NULL,	"div_core_ck",			&div_core_ck,	CK_443X),
- 	CLK(NULL,	"div_iva_hs_clk",		&div_iva_hs_clk,	CK_443X),
- 	CLK(NULL,	"div_mpu_hs_clk",		&div_mpu_hs_clk,	CK_443X),
- 	CLK(NULL,	"dpll_core_m4x2_ck",		&dpll_core_m4x2_ck,	CK_443X),
- 	CLK(NULL,	"dll_clk_div_ck",		&dll_clk_div_ck,	CK_443X),
- 	CLK(NULL,	"dpll_abe_m2_ck",		&dpll_abe_m2_ck,	CK_443X),
- 	CLK(NULL,	"dpll_core_m3x2_ck",		&dpll_core_m3x2_ck,	CK_443X),
- 	CLK(NULL,	"dpll_core_m7x2_ck",		&dpll_core_m7x2_ck,	CK_443X),
- 	CLK(NULL,	"iva_hsd_byp_clk_mux_ck",	&iva_hsd_byp_clk_mux_ck,	CK_443X),
- 	CLK(NULL,	"dpll_iva_ck",			&dpll_iva_ck,	CK_443X),
- 	CLK(NULL,	"dpll_iva_x2_ck",		&dpll_iva_x2_ck,	CK_443X),
- 	CLK(NULL,	"dpll_iva_m4x2_ck",		&dpll_iva_m4x2_ck,	CK_443X),
- 	CLK(NULL,	"dpll_iva_m5x2_ck",		&dpll_iva_m5x2_ck,	CK_443X),
- 	CLK(NULL,	"dpll_mpu_ck",			&dpll_mpu_ck,	CK_443X),
- 	CLK(NULL,	"dpll_mpu_m2_ck",		&dpll_mpu_m2_ck,	CK_443X),
- 	CLK(NULL,	"per_hs_clk_div_ck",		&per_hs_clk_div_ck,	CK_443X),
- 	CLK(NULL,	"per_hsd_byp_clk_mux_ck",	&per_hsd_byp_clk_mux_ck,	CK_443X),
- 	CLK(NULL,	"dpll_per_ck",			&dpll_per_ck,	CK_443X),
- 	CLK(NULL,	"dpll_per_m2_ck",		&dpll_per_m2_ck,	CK_443X),
- 	CLK(NULL,	"dpll_per_x2_ck",		&dpll_per_x2_ck,	CK_443X),
- 	CLK(NULL,	"dpll_per_m2x2_ck",		&dpll_per_m2x2_ck,	CK_443X),
- 	CLK(NULL,	"dpll_per_m3x2_ck",		&dpll_per_m3x2_ck,	CK_443X),
- 	CLK(NULL,	"dpll_per_m4x2_ck",		&dpll_per_m4x2_ck,	CK_443X),
- 	CLK(NULL,	"dpll_per_m5x2_ck",		&dpll_per_m5x2_ck,	CK_443X),
- 	CLK(NULL,	"dpll_per_m6x2_ck",		&dpll_per_m6x2_ck,	CK_443X),
- 	CLK(NULL,	"dpll_per_m7x2_ck",		&dpll_per_m7x2_ck,	CK_443X),
- 	CLK(NULL,	"usb_hs_clk_div_ck",		&usb_hs_clk_div_ck,	CK_443X),
- 	CLK(NULL,	"dpll_usb_ck",			&dpll_usb_ck,	CK_443X),
- 	CLK(NULL,	"dpll_usb_clkdcoldo_ck",	&dpll_usb_clkdcoldo_ck,	CK_443X),
- 	CLK(NULL,	"dpll_usb_m2_ck",		&dpll_usb_m2_ck,	CK_443X),
- 	CLK(NULL,	"ducati_clk_mux_ck",		&ducati_clk_mux_ck,	CK_443X),
- 	CLK(NULL,	"func_12m_fclk",		&func_12m_fclk,	CK_443X),
- 	CLK(NULL,	"func_24m_clk",			&func_24m_clk,	CK_443X),
- 	CLK(NULL,	"func_24mc_fclk",		&func_24mc_fclk,	CK_443X),
- 	CLK(NULL,	"func_48m_fclk",		&func_48m_fclk,	CK_443X),
- 	CLK(NULL,	"func_48mc_fclk",		&func_48mc_fclk,	CK_443X),
- 	CLK(NULL,	"func_64m_fclk",		&func_64m_fclk,	CK_443X),
- 	CLK(NULL,	"func_96m_fclk",		&func_96m_fclk,	CK_443X),
- 	CLK(NULL,	"init_60m_fclk",		&init_60m_fclk,	CK_443X),
- 	CLK(NULL,	"l3_div_ck",			&l3_div_ck,	CK_443X),
- 	CLK(NULL,	"l4_div_ck",			&l4_div_ck,	CK_443X),
- 	CLK(NULL,	"lp_clk_div_ck",		&lp_clk_div_ck,	CK_443X),
- 	CLK(NULL,	"l4_wkup_clk_mux_ck",		&l4_wkup_clk_mux_ck,	CK_443X),
- 	CLK("smp_twd",	NULL,				&mpu_periphclk,	CK_443X),
- 	CLK(NULL,	"ocp_abe_iclk",			&ocp_abe_iclk,	CK_443X),
- 	CLK(NULL,	"per_abe_24m_fclk",		&per_abe_24m_fclk,	CK_443X),
- 	CLK(NULL,	"per_abe_nc_fclk",		&per_abe_nc_fclk,	CK_443X),
- 	CLK(NULL,	"syc_clk_div_ck",		&syc_clk_div_ck,	CK_443X),
- 	CLK(NULL,	"aes1_fck",			&aes1_fck,	CK_443X),
- 	CLK(NULL,	"aes2_fck",			&aes2_fck,	CK_443X),
- 	CLK(NULL,	"bandgap_fclk",			&bandgap_fclk,	CK_443X),
- 	CLK(NULL,	"div_ts_ck",			&div_ts_ck,	CK_446X),
- 	CLK(NULL,	"bandgap_ts_fclk",		&bandgap_ts_fclk,	CK_446X),
- 	CLK(NULL,	"dmic_sync_mux_ck",		&dmic_sync_mux_ck,	CK_443X),
- 	CLK(NULL,	"func_dmic_abe_gfclk",			&func_dmic_abe_gfclk,	CK_443X),
- 	CLK(NULL,	"dss_sys_clk",			&dss_sys_clk,	CK_443X),
- 	CLK(NULL,	"dss_tv_clk",			&dss_tv_clk,	CK_443X),
- 	CLK(NULL,	"dss_dss_clk",			&dss_dss_clk,	CK_443X),
- 	CLK(NULL,	"dss_48mhz_clk",		&dss_48mhz_clk,	CK_443X),
- 	CLK(NULL,	"dss_fck",			&dss_fck,	CK_443X),
- 	CLK("omapdss_dss",	"ick",			&dss_fck,	CK_443X),
- 	CLK(NULL,	"fdif_fck",			&fdif_fck,	CK_443X),
- 	CLK(NULL,	"gpio1_dbclk",			&gpio1_dbclk,	CK_443X),
- 	CLK(NULL,	"gpio2_dbclk",			&gpio2_dbclk,	CK_443X),
- 	CLK(NULL,	"gpio3_dbclk",			&gpio3_dbclk,	CK_443X),
- 	CLK(NULL,	"gpio4_dbclk",			&gpio4_dbclk,	CK_443X),
- 	CLK(NULL,	"gpio5_dbclk",			&gpio5_dbclk,	CK_443X),
- 	CLK(NULL,	"gpio6_dbclk",			&gpio6_dbclk,	CK_443X),
- 	CLK(NULL,	"sgx_clk_mux",			&sgx_clk_mux,	CK_443X),
- 	CLK(NULL,	"hsi_fck",			&hsi_fck,	CK_443X),
- 	CLK(NULL,	"iss_ctrlclk",			&iss_ctrlclk,	CK_443X),
- 	CLK(NULL,	"mcasp_sync_mux_ck",		&mcasp_sync_mux_ck,	CK_443X),
- 	CLK(NULL,	"func_mcasp_abe_gfclk",			&func_mcasp_abe_gfclk,	CK_443X),
- 	CLK(NULL,	"mcbsp1_sync_mux_ck",		&mcbsp1_sync_mux_ck,	CK_443X),
- 	CLK(NULL,	"func_mcbsp1_gfclk",			&func_mcbsp1_gfclk,	CK_443X),
- 	CLK(NULL,	"mcbsp2_sync_mux_ck",		&mcbsp2_sync_mux_ck,	CK_443X),
- 	CLK(NULL,	"func_mcbsp2_gfclk",			&func_mcbsp2_gfclk,	CK_443X),
- 	CLK(NULL,	"mcbsp3_sync_mux_ck",		&mcbsp3_sync_mux_ck,	CK_443X),
- 	CLK(NULL,	"func_mcbsp3_gfclk",			&func_mcbsp3_gfclk,	CK_443X),
- 	CLK(NULL,	"mcbsp4_sync_mux_ck",		&mcbsp4_sync_mux_ck,	CK_443X),
- 	CLK(NULL,	"per_mcbsp4_gfclk",			&per_mcbsp4_gfclk,	CK_443X),
- 	CLK(NULL,	"hsmmc1_fclk",			&hsmmc1_fclk,	CK_443X),
- 	CLK(NULL,	"hsmmc2_fclk",			&hsmmc2_fclk,	CK_443X),
- 	CLK(NULL,	"ocp2scp_usb_phy_phy_48m",	&ocp2scp_usb_phy_phy_48m,	CK_443X),
- 	CLK(NULL,	"sha2md5_fck",			&sha2md5_fck,	CK_443X),
- 	CLK(NULL,	"slimbus1_fclk_1",		&slimbus1_fclk_1,	CK_443X),
- 	CLK(NULL,	"slimbus1_fclk_0",		&slimbus1_fclk_0,	CK_443X),
- 	CLK(NULL,	"slimbus1_fclk_2",		&slimbus1_fclk_2,	CK_443X),
- 	CLK(NULL,	"slimbus1_slimbus_clk",		&slimbus1_slimbus_clk,	CK_443X),
- 	CLK(NULL,	"slimbus2_fclk_1",		&slimbus2_fclk_1,	CK_443X),
- 	CLK(NULL,	"slimbus2_fclk_0",		&slimbus2_fclk_0,	CK_443X),
- 	CLK(NULL,	"slimbus2_slimbus_clk",		&slimbus2_slimbus_clk,	CK_443X),
- 	CLK(NULL,	"smartreflex_core_fck",		&smartreflex_core_fck,	CK_443X),
- 	CLK(NULL,	"smartreflex_iva_fck",		&smartreflex_iva_fck,	CK_443X),
- 	CLK(NULL,	"smartreflex_mpu_fck",		&smartreflex_mpu_fck,	CK_443X),
- 	CLK(NULL,	"dmt1_clk_mux",			&dmt1_clk_mux,	CK_443X),
- 	CLK(NULL,	"cm2_dm10_mux",			&cm2_dm10_mux,	CK_443X),
- 	CLK(NULL,	"cm2_dm11_mux",			&cm2_dm11_mux,	CK_443X),
- 	CLK(NULL,	"cm2_dm2_mux",			&cm2_dm2_mux,	CK_443X),
- 	CLK(NULL,	"cm2_dm3_mux",			&cm2_dm3_mux,	CK_443X),
- 	CLK(NULL,	"cm2_dm4_mux",			&cm2_dm4_mux,	CK_443X),
- 	CLK(NULL,	"timer5_sync_mux",		&timer5_sync_mux,	CK_443X),
- 	CLK(NULL,	"timer6_sync_mux",			&timer6_sync_mux,	CK_443X),
- 	CLK(NULL,	"timer7_sync_mux",			&timer7_sync_mux,	CK_443X),
- 	CLK(NULL,	"timer8_sync_mux",			&timer8_sync_mux,	CK_443X),
- 	CLK(NULL,	"cm2_dm9_mux",			&cm2_dm9_mux,	CK_443X),
- 	CLK(NULL,	"usb_host_fs_fck",		&usb_host_fs_fck,	CK_443X),
- 	CLK("usbhs_omap",	"fs_fck",		&usb_host_fs_fck,	CK_443X),
- 	CLK(NULL,	"utmi_p1_gfclk",		&utmi_p1_gfclk,	CK_443X),
- 	CLK(NULL,	"usb_host_hs_utmi_p1_clk",	&usb_host_hs_utmi_p1_clk,	CK_443X),
- 	CLK(NULL,	"utmi_p2_gfclk",		&utmi_p2_gfclk,	CK_443X),
- 	CLK(NULL,	"usb_host_hs_utmi_p2_clk",	&usb_host_hs_utmi_p2_clk,	CK_443X),
- 	CLK(NULL,	"usb_host_hs_utmi_p3_clk",	&usb_host_hs_utmi_p3_clk,	CK_443X),
- 	CLK(NULL,	"usb_host_hs_hsic480m_p1_clk",	&usb_host_hs_hsic480m_p1_clk,	CK_443X),
- 	CLK(NULL,	"usb_host_hs_hsic60m_p1_clk",	&usb_host_hs_hsic60m_p1_clk,	CK_443X),
- 	CLK(NULL,	"usb_host_hs_hsic60m_p2_clk",	&usb_host_hs_hsic60m_p2_clk,	CK_443X),
- 	CLK(NULL,	"usb_host_hs_hsic480m_p2_clk",	&usb_host_hs_hsic480m_p2_clk,	CK_443X),
- 	CLK(NULL,	"usb_host_hs_func48mclk",	&usb_host_hs_func48mclk,	CK_443X),
- 	CLK(NULL,	"usb_host_hs_fck",		&usb_host_hs_fck,	CK_443X),
- 	CLK("usbhs_omap",	"hs_fck",		&usb_host_hs_fck,	CK_443X),
- 	CLK(NULL,	"otg_60m_gfclk",		&otg_60m_gfclk,	CK_443X),
- 	CLK(NULL,	"usb_otg_hs_xclk",		&usb_otg_hs_xclk,	CK_443X),
- 	CLK(NULL,	"usb_otg_hs_ick",		&usb_otg_hs_ick,	CK_443X),
- 	CLK("musb-omap2430",	"ick",			&usb_otg_hs_ick,	CK_443X),
- 	CLK(NULL,	"usb_phy_cm_clk32k",		&usb_phy_cm_clk32k,	CK_443X),
- 	CLK(NULL,	"usb_tll_hs_usb_ch2_clk",	&usb_tll_hs_usb_ch2_clk,	CK_443X),
- 	CLK(NULL,	"usb_tll_hs_usb_ch0_clk",	&usb_tll_hs_usb_ch0_clk,	CK_443X),
- 	CLK(NULL,	"usb_tll_hs_usb_ch1_clk",	&usb_tll_hs_usb_ch1_clk,	CK_443X),
- 	CLK(NULL,	"usb_tll_hs_ick",		&usb_tll_hs_ick,	CK_443X),
- 	CLK("usbhs_omap",	"usbtll_ick",		&usb_tll_hs_ick,	CK_443X),
- 	CLK("usbhs_tll",	"usbtll_ick",		&usb_tll_hs_ick,	CK_443X),
- 	CLK(NULL,	"usim_ck",			&usim_ck,	CK_443X),
- 	CLK(NULL,	"usim_fclk",			&usim_fclk,	CK_443X),
- 	CLK(NULL,	"pmd_stm_clock_mux_ck",		&pmd_stm_clock_mux_ck,	CK_443X),
- 	CLK(NULL,	"pmd_trace_clk_mux_ck",		&pmd_trace_clk_mux_ck,	CK_443X),
- 	CLK(NULL,	"stm_clk_div_ck",		&stm_clk_div_ck,	CK_443X),
- 	CLK(NULL,	"trace_clk_div_ck",		&trace_clk_div_ck,	CK_443X),
- 	CLK(NULL,	"auxclk0_src_ck",		&auxclk0_src_ck,	CK_443X),
- 	CLK(NULL,	"auxclk0_ck",			&auxclk0_ck,	CK_443X),
- 	CLK(NULL,	"auxclkreq0_ck",		&auxclkreq0_ck,	CK_443X),
- 	CLK(NULL,	"auxclk1_src_ck",		&auxclk1_src_ck,	CK_443X),
- 	CLK(NULL,	"auxclk1_ck",			&auxclk1_ck,	CK_443X),
- 	CLK(NULL,	"auxclkreq1_ck",		&auxclkreq1_ck,	CK_443X),
- 	CLK(NULL,	"auxclk2_src_ck",		&auxclk2_src_ck,	CK_443X),
- 	CLK(NULL,	"auxclk2_ck",			&auxclk2_ck,	CK_443X),
- 	CLK(NULL,	"auxclkreq2_ck",		&auxclkreq2_ck,	CK_443X),
- 	CLK(NULL,	"auxclk3_src_ck",		&auxclk3_src_ck,	CK_443X),
- 	CLK(NULL,	"auxclk3_ck",			&auxclk3_ck,	CK_443X),
- 	CLK(NULL,	"auxclkreq3_ck",		&auxclkreq3_ck,	CK_443X),
- 	CLK(NULL,	"auxclk4_src_ck",		&auxclk4_src_ck,	CK_443X),
- 	CLK(NULL,	"auxclk4_ck",			&auxclk4_ck,	CK_443X),
- 	CLK(NULL,	"auxclkreq4_ck",		&auxclkreq4_ck,	CK_443X),
- 	CLK(NULL,	"auxclk5_src_ck",		&auxclk5_src_ck,	CK_443X),
- 	CLK(NULL,	"auxclk5_ck",			&auxclk5_ck,	CK_443X),
- 	CLK(NULL,	"auxclkreq5_ck",		&auxclkreq5_ck,	CK_443X),
- 	CLK("omap-gpmc",	"fck",			&dummy_ck,	CK_443X),
- 	CLK("omap_i2c.1",	"ick",			&dummy_ck,	CK_443X),
- 	CLK("omap_i2c.2",	"ick",			&dummy_ck,	CK_443X),
- 	CLK("omap_i2c.3",	"ick",			&dummy_ck,	CK_443X),
- 	CLK("omap_i2c.4",	"ick",			&dummy_ck,	CK_443X),
- 	CLK(NULL,	"mailboxes_ick",		&dummy_ck,	CK_443X),
- 	CLK("omap_hsmmc.0",	"ick",			&dummy_ck,	CK_443X),
- 	CLK("omap_hsmmc.1",	"ick",			&dummy_ck,	CK_443X),
- 	CLK("omap_hsmmc.2",	"ick",			&dummy_ck,	CK_443X),
- 	CLK("omap_hsmmc.3",	"ick",			&dummy_ck,	CK_443X),
- 	CLK("omap_hsmmc.4",	"ick",			&dummy_ck,	CK_443X),
- 	CLK("omap-mcbsp.1",	"ick",			&dummy_ck,	CK_443X),
- 	CLK("omap-mcbsp.2",	"ick",			&dummy_ck,	CK_443X),
- 	CLK("omap-mcbsp.3",	"ick",			&dummy_ck,	CK_443X),
- 	CLK("omap-mcbsp.4",	"ick",			&dummy_ck,	CK_443X),
- 	CLK("omap2_mcspi.1",	"ick",			&dummy_ck,	CK_443X),
- 	CLK("omap2_mcspi.2",	"ick",			&dummy_ck,	CK_443X),
- 	CLK("omap2_mcspi.3",	"ick",			&dummy_ck,	CK_443X),
- 	CLK("omap2_mcspi.4",	"ick",			&dummy_ck,	CK_443X),
- 	CLK(NULL,	"uart1_ick",			&dummy_ck,	CK_443X),
- 	CLK(NULL,	"uart2_ick",			&dummy_ck,	CK_443X),
- 	CLK(NULL,	"uart3_ick",			&dummy_ck,	CK_443X),
- 	CLK(NULL,	"uart4_ick",			&dummy_ck,	CK_443X),
- 	CLK("usbhs_omap",	"usbhost_ick",		&dummy_ck,		CK_443X),
- 	CLK("usbhs_omap",	"usbtll_fck",		&dummy_ck,	CK_443X),
- 	CLK("usbhs_tll",	"usbtll_fck",		&dummy_ck,	CK_443X),
- 	CLK("omap_wdt",	"ick",				&dummy_ck,	CK_443X),
- 	CLK(NULL,	"timer_32k_ck",	&sys_32k_ck,	CK_443X),
+ 	CLK(NULL,	"extalt_clkin_ck",		&extalt_clkin_ck),
+ 	CLK(NULL,	"pad_clks_src_ck",		&pad_clks_src_ck),
+ 	CLK(NULL,	"pad_clks_ck",			&pad_clks_ck),
+ 	CLK(NULL,	"pad_slimbus_core_clks_ck",	&pad_slimbus_core_clks_ck),
+ 	CLK(NULL,	"secure_32k_clk_src_ck",	&secure_32k_clk_src_ck),
+ 	CLK(NULL,	"slimbus_src_clk",		&slimbus_src_clk),
+ 	CLK(NULL,	"slimbus_clk",			&slimbus_clk),
+ 	CLK(NULL,	"sys_32k_ck",			&sys_32k_ck),
+ 	CLK(NULL,	"virt_12000000_ck",		&virt_12000000_ck),
+ 	CLK(NULL,	"virt_13000000_ck",		&virt_13000000_ck),
+ 	CLK(NULL,	"virt_16800000_ck",		&virt_16800000_ck),
+ 	CLK(NULL,	"virt_19200000_ck",		&virt_19200000_ck),
+ 	CLK(NULL,	"virt_26000000_ck",		&virt_26000000_ck),
+ 	CLK(NULL,	"virt_27000000_ck",		&virt_27000000_ck),
+ 	CLK(NULL,	"virt_38400000_ck",		&virt_38400000_ck),
+ 	CLK(NULL,	"sys_clkin_ck",			&sys_clkin_ck),
+ 	CLK(NULL,	"tie_low_clock_ck",		&tie_low_clock_ck),
+ 	CLK(NULL,	"utmi_phy_clkout_ck",		&utmi_phy_clkout_ck),
+ 	CLK(NULL,	"xclk60mhsp1_ck",		&xclk60mhsp1_ck),
+ 	CLK(NULL,	"xclk60mhsp2_ck",		&xclk60mhsp2_ck),
+ 	CLK(NULL,	"xclk60motg_ck",		&xclk60motg_ck),
+ 	CLK(NULL,	"abe_dpll_bypass_clk_mux_ck",	&abe_dpll_bypass_clk_mux_ck),
+ 	CLK(NULL,	"abe_dpll_refclk_mux_ck",	&abe_dpll_refclk_mux_ck),
+ 	CLK(NULL,	"dpll_abe_ck",			&dpll_abe_ck),
+ 	CLK(NULL,	"dpll_abe_x2_ck",		&dpll_abe_x2_ck),
+ 	CLK(NULL,	"dpll_abe_m2x2_ck",		&dpll_abe_m2x2_ck),
+ 	CLK(NULL,	"abe_24m_fclk",			&abe_24m_fclk),
+ 	CLK(NULL,	"abe_clk",			&abe_clk),
+ 	CLK(NULL,	"aess_fclk",			&aess_fclk),
+ 	CLK(NULL,	"dpll_abe_m3x2_ck",		&dpll_abe_m3x2_ck),
+ 	CLK(NULL,	"core_hsd_byp_clk_mux_ck",	&core_hsd_byp_clk_mux_ck),
+ 	CLK(NULL,	"dpll_core_ck",			&dpll_core_ck),
+ 	CLK(NULL,	"dpll_core_x2_ck",		&dpll_core_x2_ck),
+ 	CLK(NULL,	"dpll_core_m6x2_ck",		&dpll_core_m6x2_ck),
+ 	CLK(NULL,	"dbgclk_mux_ck",		&dbgclk_mux_ck),
+ 	CLK(NULL,	"dpll_core_m2_ck",		&dpll_core_m2_ck),
+ 	CLK(NULL,	"ddrphy_ck",			&ddrphy_ck),
+ 	CLK(NULL,	"dpll_core_m5x2_ck",		&dpll_core_m5x2_ck),
+ 	CLK(NULL,	"div_core_ck",			&div_core_ck),
+ 	CLK(NULL,	"div_iva_hs_clk",		&div_iva_hs_clk),
+ 	CLK(NULL,	"div_mpu_hs_clk",		&div_mpu_hs_clk),
+ 	CLK(NULL,	"dpll_core_m4x2_ck",		&dpll_core_m4x2_ck),
+ 	CLK(NULL,	"dll_clk_div_ck",		&dll_clk_div_ck),
+ 	CLK(NULL,	"dpll_abe_m2_ck",		&dpll_abe_m2_ck),
+ 	CLK(NULL,	"dpll_core_m3x2_ck",		&dpll_core_m3x2_ck),
+ 	CLK(NULL,	"dpll_core_m7x2_ck",		&dpll_core_m7x2_ck),
+ 	CLK(NULL,	"iva_hsd_byp_clk_mux_ck",	&iva_hsd_byp_clk_mux_ck),
+ 	CLK(NULL,	"dpll_iva_ck",			&dpll_iva_ck),
+ 	CLK(NULL,	"dpll_iva_x2_ck",		&dpll_iva_x2_ck),
+ 	CLK(NULL,	"dpll_iva_m4x2_ck",		&dpll_iva_m4x2_ck),
+ 	CLK(NULL,	"dpll_iva_m5x2_ck",		&dpll_iva_m5x2_ck),
+ 	CLK(NULL,	"dpll_mpu_ck",			&dpll_mpu_ck),
+ 	CLK(NULL,	"dpll_mpu_m2_ck",		&dpll_mpu_m2_ck),
+ 	CLK(NULL,	"per_hs_clk_div_ck",		&per_hs_clk_div_ck),
+ 	CLK(NULL,	"per_hsd_byp_clk_mux_ck",	&per_hsd_byp_clk_mux_ck),
+ 	CLK(NULL,	"dpll_per_ck",			&dpll_per_ck),
+ 	CLK(NULL,	"dpll_per_m2_ck",		&dpll_per_m2_ck),
+ 	CLK(NULL,	"dpll_per_x2_ck",		&dpll_per_x2_ck),
+ 	CLK(NULL,	"dpll_per_m2x2_ck",		&dpll_per_m2x2_ck),
+ 	CLK(NULL,	"dpll_per_m3x2_ck",		&dpll_per_m3x2_ck),
+ 	CLK(NULL,	"dpll_per_m4x2_ck",		&dpll_per_m4x2_ck),
+ 	CLK(NULL,	"dpll_per_m5x2_ck",		&dpll_per_m5x2_ck),
+ 	CLK(NULL,	"dpll_per_m6x2_ck",		&dpll_per_m6x2_ck),
+ 	CLK(NULL,	"dpll_per_m7x2_ck",		&dpll_per_m7x2_ck),
+ 	CLK(NULL,	"usb_hs_clk_div_ck",		&usb_hs_clk_div_ck),
+ 	CLK(NULL,	"dpll_usb_ck",			&dpll_usb_ck),
+ 	CLK(NULL,	"dpll_usb_clkdcoldo_ck",	&dpll_usb_clkdcoldo_ck),
+ 	CLK(NULL,	"dpll_usb_m2_ck",		&dpll_usb_m2_ck),
+ 	CLK(NULL,	"ducati_clk_mux_ck",		&ducati_clk_mux_ck),
+ 	CLK(NULL,	"func_12m_fclk",		&func_12m_fclk),
+ 	CLK(NULL,	"func_24m_clk",			&func_24m_clk),
+ 	CLK(NULL,	"func_24mc_fclk",		&func_24mc_fclk),
+ 	CLK(NULL,	"func_48m_fclk",		&func_48m_fclk),
+ 	CLK(NULL,	"func_48mc_fclk",		&func_48mc_fclk),
+ 	CLK(NULL,	"func_64m_fclk",		&func_64m_fclk),
+ 	CLK(NULL,	"func_96m_fclk",		&func_96m_fclk),
+ 	CLK(NULL,	"init_60m_fclk",		&init_60m_fclk),
+ 	CLK(NULL,	"l3_div_ck",			&l3_div_ck),
+ 	CLK(NULL,	"l4_div_ck",			&l4_div_ck),
+ 	CLK(NULL,	"lp_clk_div_ck",		&lp_clk_div_ck),
+ 	CLK(NULL,	"l4_wkup_clk_mux_ck",		&l4_wkup_clk_mux_ck),
+ 	CLK("smp_twd",	NULL,				&mpu_periphclk),
+ 	CLK(NULL,	"ocp_abe_iclk",			&ocp_abe_iclk),
+ 	CLK(NULL,	"per_abe_24m_fclk",		&per_abe_24m_fclk),
+ 	CLK(NULL,	"per_abe_nc_fclk",		&per_abe_nc_fclk),
+ 	CLK(NULL,	"syc_clk_div_ck",		&syc_clk_div_ck),
+ 	CLK(NULL,	"aes1_fck",			&aes1_fck),
+ 	CLK(NULL,	"aes2_fck",			&aes2_fck),
+ 	CLK(NULL,	"dmic_sync_mux_ck",		&dmic_sync_mux_ck),
+ 	CLK(NULL,	"func_dmic_abe_gfclk",		&func_dmic_abe_gfclk),
+ 	CLK(NULL,	"dss_sys_clk",			&dss_sys_clk),
+ 	CLK(NULL,	"dss_tv_clk",			&dss_tv_clk),
+ 	CLK(NULL,	"dss_dss_clk",			&dss_dss_clk),
+ 	CLK(NULL,	"dss_48mhz_clk",		&dss_48mhz_clk),
+ 	CLK(NULL,	"dss_fck",			&dss_fck),
+ 	CLK("omapdss_dss",	"ick",			&dss_fck),
+ 	CLK(NULL,	"fdif_fck",			&fdif_fck),
+ 	CLK(NULL,	"gpio1_dbclk",			&gpio1_dbclk),
+ 	CLK(NULL,	"gpio2_dbclk",			&gpio2_dbclk),
+ 	CLK(NULL,	"gpio3_dbclk",			&gpio3_dbclk),
+ 	CLK(NULL,	"gpio4_dbclk",			&gpio4_dbclk),
+ 	CLK(NULL,	"gpio5_dbclk",			&gpio5_dbclk),
+ 	CLK(NULL,	"gpio6_dbclk",			&gpio6_dbclk),
+ 	CLK(NULL,	"sgx_clk_mux",			&sgx_clk_mux),
+ 	CLK(NULL,	"hsi_fck",			&hsi_fck),
+ 	CLK(NULL,	"iss_ctrlclk",			&iss_ctrlclk),
+ 	CLK(NULL,	"mcasp_sync_mux_ck",		&mcasp_sync_mux_ck),
+ 	CLK(NULL,	"func_mcasp_abe_gfclk",		&func_mcasp_abe_gfclk),
+ 	CLK(NULL,	"mcbsp1_sync_mux_ck",		&mcbsp1_sync_mux_ck),
+ 	CLK(NULL,	"func_mcbsp1_gfclk",		&func_mcbsp1_gfclk),
+ 	CLK(NULL,	"mcbsp2_sync_mux_ck",		&mcbsp2_sync_mux_ck),
+ 	CLK(NULL,	"func_mcbsp2_gfclk",		&func_mcbsp2_gfclk),
+ 	CLK(NULL,	"mcbsp3_sync_mux_ck",		&mcbsp3_sync_mux_ck),
+ 	CLK(NULL,	"func_mcbsp3_gfclk",		&func_mcbsp3_gfclk),
+ 	CLK(NULL,	"mcbsp4_sync_mux_ck",		&mcbsp4_sync_mux_ck),
+ 	CLK(NULL,	"per_mcbsp4_gfclk",		&per_mcbsp4_gfclk),
+ 	CLK(NULL,	"hsmmc1_fclk",			&hsmmc1_fclk),
+ 	CLK(NULL,	"hsmmc2_fclk",			&hsmmc2_fclk),
++	CLK(NULL,	"ocp2scp_usb_phy_phy_48m",	&ocp2scp_usb_phy_phy_48m),
+ 	CLK(NULL,	"sha2md5_fck",			&sha2md5_fck),
+ 	CLK(NULL,	"slimbus1_fclk_1",		&slimbus1_fclk_1),
+ 	CLK(NULL,	"slimbus1_fclk_0",		&slimbus1_fclk_0),
+ 	CLK(NULL,	"slimbus1_fclk_2",		&slimbus1_fclk_2),
+ 	CLK(NULL,	"slimbus1_slimbus_clk",		&slimbus1_slimbus_clk),
+ 	CLK(NULL,	"slimbus2_fclk_1",		&slimbus2_fclk_1),
+ 	CLK(NULL,	"slimbus2_fclk_0",		&slimbus2_fclk_0),
+ 	CLK(NULL,	"slimbus2_slimbus_clk",		&slimbus2_slimbus_clk),
+ 	CLK(NULL,	"smartreflex_core_fck",		&smartreflex_core_fck),
+ 	CLK(NULL,	"smartreflex_iva_fck",		&smartreflex_iva_fck),
+ 	CLK(NULL,	"smartreflex_mpu_fck",		&smartreflex_mpu_fck),
+ 	CLK(NULL,	"dmt1_clk_mux",			&dmt1_clk_mux),
+ 	CLK(NULL,	"cm2_dm10_mux",			&cm2_dm10_mux),
+ 	CLK(NULL,	"cm2_dm11_mux",			&cm2_dm11_mux),
+ 	CLK(NULL,	"cm2_dm2_mux",			&cm2_dm2_mux),
+ 	CLK(NULL,	"cm2_dm3_mux",			&cm2_dm3_mux),
+ 	CLK(NULL,	"cm2_dm4_mux",			&cm2_dm4_mux),
+ 	CLK(NULL,	"timer5_sync_mux",		&timer5_sync_mux),
+ 	CLK(NULL,	"timer6_sync_mux",		&timer6_sync_mux),
+ 	CLK(NULL,	"timer7_sync_mux",		&timer7_sync_mux),
+ 	CLK(NULL,	"timer8_sync_mux",		&timer8_sync_mux),
+ 	CLK(NULL,	"cm2_dm9_mux",			&cm2_dm9_mux),
+ 	CLK(NULL,	"usb_host_fs_fck",		&usb_host_fs_fck),
+ 	CLK("usbhs_omap",	"fs_fck",		&usb_host_fs_fck),
+ 	CLK(NULL,	"utmi_p1_gfclk",		&utmi_p1_gfclk),
+ 	CLK(NULL,	"usb_host_hs_utmi_p1_clk",	&usb_host_hs_utmi_p1_clk),
+ 	CLK(NULL,	"utmi_p2_gfclk",		&utmi_p2_gfclk),
+ 	CLK(NULL,	"usb_host_hs_utmi_p2_clk",	&usb_host_hs_utmi_p2_clk),
+ 	CLK(NULL,	"usb_host_hs_utmi_p3_clk",	&usb_host_hs_utmi_p3_clk),
+ 	CLK(NULL,	"usb_host_hs_hsic480m_p1_clk",	&usb_host_hs_hsic480m_p1_clk),
+ 	CLK(NULL,	"usb_host_hs_hsic60m_p1_clk",	&usb_host_hs_hsic60m_p1_clk),
+ 	CLK(NULL,	"usb_host_hs_hsic60m_p2_clk",	&usb_host_hs_hsic60m_p2_clk),
+ 	CLK(NULL,	"usb_host_hs_hsic480m_p2_clk",	&usb_host_hs_hsic480m_p2_clk),
+ 	CLK(NULL,	"usb_host_hs_func48mclk",	&usb_host_hs_func48mclk),
+ 	CLK(NULL,	"usb_host_hs_fck",		&usb_host_hs_fck),
+ 	CLK("usbhs_omap",	"hs_fck",		&usb_host_hs_fck),
+ 	CLK(NULL,	"otg_60m_gfclk",		&otg_60m_gfclk),
+ 	CLK(NULL,	"usb_otg_hs_xclk",		&usb_otg_hs_xclk),
+ 	CLK(NULL,	"usb_otg_hs_ick",		&usb_otg_hs_ick),
+ 	CLK("musb-omap2430",	"ick",			&usb_otg_hs_ick),
+ 	CLK(NULL,	"usb_phy_cm_clk32k",		&usb_phy_cm_clk32k),
+ 	CLK(NULL,	"usb_tll_hs_usb_ch2_clk",	&usb_tll_hs_usb_ch2_clk),
+ 	CLK(NULL,	"usb_tll_hs_usb_ch0_clk",	&usb_tll_hs_usb_ch0_clk),
+ 	CLK(NULL,	"usb_tll_hs_usb_ch1_clk",	&usb_tll_hs_usb_ch1_clk),
+ 	CLK(NULL,	"usb_tll_hs_ick",		&usb_tll_hs_ick),
+ 	CLK("usbhs_omap",	"usbtll_ick",		&usb_tll_hs_ick),
+ 	CLK("usbhs_tll",	"usbtll_ick",		&usb_tll_hs_ick),
+ 	CLK(NULL,	"usim_ck",			&usim_ck),
+ 	CLK(NULL,	"usim_fclk",			&usim_fclk),
+ 	CLK(NULL,	"pmd_stm_clock_mux_ck",		&pmd_stm_clock_mux_ck),
+ 	CLK(NULL,	"pmd_trace_clk_mux_ck",		&pmd_trace_clk_mux_ck),
+ 	CLK(NULL,	"stm_clk_div_ck",		&stm_clk_div_ck),
+ 	CLK(NULL,	"trace_clk_div_ck",		&trace_clk_div_ck),
+ 	CLK(NULL,	"auxclk0_src_ck",		&auxclk0_src_ck),
+ 	CLK(NULL,	"auxclk0_ck",			&auxclk0_ck),
+ 	CLK(NULL,	"auxclkreq0_ck",		&auxclkreq0_ck),
+ 	CLK(NULL,	"auxclk1_src_ck",		&auxclk1_src_ck),
+ 	CLK(NULL,	"auxclk1_ck",			&auxclk1_ck),
+ 	CLK(NULL,	"auxclkreq1_ck",		&auxclkreq1_ck),
+ 	CLK(NULL,	"auxclk2_src_ck",		&auxclk2_src_ck),
+ 	CLK(NULL,	"auxclk2_ck",			&auxclk2_ck),
+ 	CLK(NULL,	"auxclkreq2_ck",		&auxclkreq2_ck),
+ 	CLK(NULL,	"auxclk3_src_ck",		&auxclk3_src_ck),
+ 	CLK(NULL,	"auxclk3_ck",			&auxclk3_ck),
+ 	CLK(NULL,	"auxclkreq3_ck",		&auxclkreq3_ck),
+ 	CLK(NULL,	"auxclk4_src_ck",		&auxclk4_src_ck),
+ 	CLK(NULL,	"auxclk4_ck",			&auxclk4_ck),
+ 	CLK(NULL,	"auxclkreq4_ck",		&auxclkreq4_ck),
+ 	CLK(NULL,	"auxclk5_src_ck",		&auxclk5_src_ck),
+ 	CLK(NULL,	"auxclk5_ck",			&auxclk5_ck),
+ 	CLK(NULL,	"auxclkreq5_ck",		&auxclkreq5_ck),
+ 	CLK("omap-gpmc",	"fck",			&dummy_ck),
+ 	CLK("omap_i2c.1",	"ick",			&dummy_ck),
+ 	CLK("omap_i2c.2",	"ick",			&dummy_ck),
+ 	CLK("omap_i2c.3",	"ick",			&dummy_ck),
+ 	CLK("omap_i2c.4",	"ick",			&dummy_ck),
+ 	CLK(NULL,	"mailboxes_ick",		&dummy_ck),
+ 	CLK("omap_hsmmc.0",	"ick",			&dummy_ck),
+ 	CLK("omap_hsmmc.1",	"ick",			&dummy_ck),
+ 	CLK("omap_hsmmc.2",	"ick",			&dummy_ck),
+ 	CLK("omap_hsmmc.3",	"ick",			&dummy_ck),
+ 	CLK("omap_hsmmc.4",	"ick",			&dummy_ck),
+ 	CLK("omap-mcbsp.1",	"ick",			&dummy_ck),
+ 	CLK("omap-mcbsp.2",	"ick",			&dummy_ck),
+ 	CLK("omap-mcbsp.3",	"ick",			&dummy_ck),
+ 	CLK("omap-mcbsp.4",	"ick",			&dummy_ck),
+ 	CLK("omap2_mcspi.1",	"ick",			&dummy_ck),
+ 	CLK("omap2_mcspi.2",	"ick",			&dummy_ck),
+ 	CLK("omap2_mcspi.3",	"ick",			&dummy_ck),
+ 	CLK("omap2_mcspi.4",	"ick",			&dummy_ck),
+ 	CLK(NULL,	"uart1_ick",			&dummy_ck),
+ 	CLK(NULL,	"uart2_ick",			&dummy_ck),
+ 	CLK(NULL,	"uart3_ick",			&dummy_ck),
+ 	CLK(NULL,	"uart4_ick",			&dummy_ck),
+ 	CLK("usbhs_omap",	"usbhost_ick",		&dummy_ck),
+ 	CLK("usbhs_omap",	"usbtll_fck",		&dummy_ck),
+ 	CLK("usbhs_tll",	"usbtll_fck",		&dummy_ck),
+ 	CLK("omap_wdt",	"ick",				&dummy_ck),
+ 	CLK(NULL,	"timer_32k_ck",	&sys_32k_ck),
  	/* TODO: Remove "omap_timer.X" aliases once DT migration is complete */
- 	CLK("omap_timer.1",	"timer_sys_ck",	&sys_clkin_ck,	CK_443X),
- 	CLK("omap_timer.2",	"timer_sys_ck",	&sys_clkin_ck,	CK_443X),
- 	CLK("omap_timer.3",	"timer_sys_ck",	&sys_clkin_ck,	CK_443X),
- 	CLK("omap_timer.4",	"timer_sys_ck",	&sys_clkin_ck,	CK_443X),
- 	CLK("omap_timer.9",	"timer_sys_ck",	&sys_clkin_ck,	CK_443X),
- 	CLK("omap_timer.10",	"timer_sys_ck",	&sys_clkin_ck,	CK_443X),
- 	CLK("omap_timer.11",	"timer_sys_ck",	&sys_clkin_ck,	CK_443X),
- 	CLK("omap_timer.5",	"timer_sys_ck",	&syc_clk_div_ck,	CK_443X),
- 	CLK("omap_timer.6",	"timer_sys_ck",	&syc_clk_div_ck,	CK_443X),
- 	CLK("omap_timer.7",	"timer_sys_ck",	&syc_clk_div_ck,	CK_443X),
- 	CLK("omap_timer.8",	"timer_sys_ck",	&syc_clk_div_ck,	CK_443X),
- 	CLK("4a318000.timer",	"timer_sys_ck",	&sys_clkin_ck,	CK_443X),
- 	CLK("48032000.timer",	"timer_sys_ck",	&sys_clkin_ck,	CK_443X),
- 	CLK("48034000.timer",	"timer_sys_ck",	&sys_clkin_ck,	CK_443X),
- 	CLK("48036000.timer",	"timer_sys_ck",	&sys_clkin_ck,	CK_443X),
- 	CLK("4803e000.timer",	"timer_sys_ck",	&sys_clkin_ck,	CK_443X),
- 	CLK("48086000.timer",	"timer_sys_ck",	&sys_clkin_ck,	CK_443X),
- 	CLK("48088000.timer",	"timer_sys_ck",	&sys_clkin_ck,	CK_443X),
- 	CLK("40138000.timer",	"timer_sys_ck",	&syc_clk_div_ck,	CK_443X),
- 	CLK("4013a000.timer",	"timer_sys_ck",	&syc_clk_div_ck,	CK_443X),
- 	CLK("4013c000.timer",	"timer_sys_ck",	&syc_clk_div_ck,	CK_443X),
- 	CLK("4013e000.timer",	"timer_sys_ck",	&syc_clk_div_ck,	CK_443X),
- 	CLK(NULL,	"cpufreq_ck",	&dpll_mpu_ck,	CK_443X),
+ 	CLK("omap_timer.1",	"timer_sys_ck",	&sys_clkin_ck),
+ 	CLK("omap_timer.2",	"timer_sys_ck",	&sys_clkin_ck),
+ 	CLK("omap_timer.3",	"timer_sys_ck",	&sys_clkin_ck),
+ 	CLK("omap_timer.4",	"timer_sys_ck",	&sys_clkin_ck),
+ 	CLK("omap_timer.9",	"timer_sys_ck",	&sys_clkin_ck),
+ 	CLK("omap_timer.10",	"timer_sys_ck",	&sys_clkin_ck),
+ 	CLK("omap_timer.11",	"timer_sys_ck",	&sys_clkin_ck),
+ 	CLK("omap_timer.5",	"timer_sys_ck",	&syc_clk_div_ck),
+ 	CLK("omap_timer.6",	"timer_sys_ck",	&syc_clk_div_ck),
+ 	CLK("omap_timer.7",	"timer_sys_ck",	&syc_clk_div_ck),
+ 	CLK("omap_timer.8",	"timer_sys_ck",	&syc_clk_div_ck),
+ 	CLK("4a318000.timer",	"timer_sys_ck",	&sys_clkin_ck),
+ 	CLK("48032000.timer",	"timer_sys_ck",	&sys_clkin_ck),
+ 	CLK("48034000.timer",	"timer_sys_ck",	&sys_clkin_ck),
+ 	CLK("48036000.timer",	"timer_sys_ck",	&sys_clkin_ck),
+ 	CLK("4803e000.timer",	"timer_sys_ck",	&sys_clkin_ck),
+ 	CLK("48086000.timer",	"timer_sys_ck",	&sys_clkin_ck),
+ 	CLK("48088000.timer",	"timer_sys_ck",	&sys_clkin_ck),
+ 	CLK("40138000.timer",	"timer_sys_ck",	&syc_clk_div_ck),
+ 	CLK("4013a000.timer",	"timer_sys_ck",	&syc_clk_div_ck),
+ 	CLK("4013c000.timer",	"timer_sys_ck",	&syc_clk_div_ck),
+ 	CLK("4013e000.timer",	"timer_sys_ck",	&syc_clk_div_ck),
+ 	CLK(NULL,	"cpufreq_ck",	&dpll_mpu_ck),
  };
  
  int __init omap4xxx_clk_init(void)


From dave.martin at linaro.org  Mon Apr  8 12:28:44 2013
From: dave.martin at linaro.org (Dave Martin)
Date: Mon, 8 Apr 2013 17:28:44 +0100
Subject: Anyone implement Cortex A9 FIQ
In-Reply-To: <CAHrpEqT9SSbHYK62i0ZteEd4SfZaa_nw+T0SHunP2W+MUEqmrg@mail.gmail.com>
References: <CAHrpEqSQ1n_WUfxoraKZFS2A8NjdP_MCcWmJdCjcon_QwgX4Hw@mail.gmail.com>
 <5142FBF5.3010307@arm.com>
 <CAHrpEqSO89Lx=EGTJJ_XOFwkHqL=heoOUQCtJUzm6D7mEAbWiw@mail.gmail.com>
 <514764E2.6040101@arm.com>
 <CAHrpEqT9SSbHYK62i0ZteEd4SfZaa_nw+T0SHunP2W+MUEqmrg@mail.gmail.com>
Message-ID: <20130408162844.GB2176@linaro.org>

On Tue, Mar 19, 2013 at 03:49:50PM +0800, Frank Li wrote:
> >
> > Whether this is feasible will really depend on what platform you're on - if
> > there's a secure monitor then FIQs are out of the question anyway. Can you
> > tell us more about the system?
> 
> Freescale MX6Q.
> 
> >
> > If your average interrupt latency is low then you should just be able to do
> > this with normal IRQs (have you got threaded interrupt handlers?)
> 
> Not all drivers use threaded interrupt handler.
> 
> >
> > What is it about the situation that leads you to believe that you *need*
> > FIQ?
> 
> FIQ can be executed even in spin_lock_saveirq.
> We want do very small hardware set at related precision period (every 125us).

Why is the latency requirement so tight for this one interrupt?

Cheers
---Dave


From arnd at arndb.de  Mon Apr  8 12:32:58 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 8 Apr 2013 18:32:58 +0200
Subject: [GIT PULL] arm: vt8500: Add support for pinctrl/gpio module
In-Reply-To: <515D0D29.8030203@prisktech.co.nz>
References: <515D0D29.8030203@prisktech.co.nz>
Message-ID: <201304081832.58772.arnd@arndb.de>

On Thursday 04 April 2013, Tony Prisk wrote:
> The following changes since commit 8bb9660418e05bb1845ac1a2428444d78e322cc7:
> 
>    Linux 3.9-rc4 (2013-03-23 16:52:44 -0700)
> 
> are available in the git repository at:
> 
>    git://server.prisktech.co.nz/git/linuxwmt.git tags/vt8500/pinctrl
> 

Pulled into next/drivers, thanks a lot!

	Arnd


From arnd at arndb.de  Mon Apr  8 12:36:58 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 8 Apr 2013 18:36:58 +0200
Subject: [GIT PULL] arm-soc: Xilinx zynq timer changes for v3.10
In-Reply-To: <1e33aafc-ee95-42ab-b5d7-048c1d7d0664@CO9EHSMHS023.ehs.local>
References: <1e33aafc-ee95-42ab-b5d7-048c1d7d0664@CO9EHSMHS023.ehs.local>
Message-ID: <201304081836.58488.arnd@arndb.de>

On Thursday 04 April 2013, Michal Simek wrote:
> please pull these zynq timer changes to your arm-soc tree.
> 
> This tree is based on clksrc/cleanup branch because these changes related
> on Rob changes in clksrc-of.c.
> 
> Please let me know if you have any problem with it.
> 

Pulled into next/drivers branch, thanks!

	Arnd


From greg at kroah.com  Mon Apr  8 12:42:09 2013
From: greg at kroah.com (Greg KH)
Date: Mon, 8 Apr 2013 09:42:09 -0700
Subject: [PATCH V5 0/6] USB: EHCI multiplatform for 3.10
In-Reply-To: <1364919844-1726-1-git-send-email-arnd@arndb.de>
References: <1364919844-1726-1-git-send-email-arnd@arndb.de>
Message-ID: <20130408164209.GA13694@kroah.com>

On Tue, Apr 02, 2013 at 06:23:58PM +0200, Arnd Bergmann wrote:
> Hi Greg,
> 
> Here are the EHCI patches that I think are good for inclusion in 3.10,
> I hope you are willing to include them after the debacle over these
> patches in 3.9.
> 
> The patches are all logically independent but sorted by priority,
> so decide for yourself how many you want to take, starting at the
> first one. The first six patches all have an Ack from Alan Stern
> and from the respective ARM platform maintainers.

I don't see an ACK for the 6th patch from Alan, any reason for that?

I've applied the first 5 for now, if you want the 6th one applied,
please resend.

thanks,

greg k-h


From tony at atomide.com  Mon Apr  8 12:42:28 2013
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 8 Apr 2013 09:42:28 -0700
Subject: [PATCH v3 2/4] ARM: OMAP4+: PM: Consolidate OMAP4 PM code to
 re-use it for OMAP5
In-Reply-To: <5162A093.7090808@ti.com>
References: <1365166743-5940-1-git-send-email-santosh.shilimkar@ti.com>
 <1365166743-5940-3-git-send-email-santosh.shilimkar@ti.com>
 <20130405213433.GF10155@atomide.com> <5162A093.7090808@ti.com>
Message-ID: <20130408164228.GK10155@atomide.com>

* Santosh Shilimkar <santosh.shilimkar at ti.com> [130408 03:51]:
> On Saturday 06 April 2013 03:04 AM, Tony Lindgren wrote:
> > * Santosh Shilimkar <santosh.shilimkar at ti.com> [130405 06:01]:
> >> OMAP5 has backward compatible PRCM block and it's programming
> >> model is mostly similar to OMAP4. Same is going to be maintained
> >> for future OMAP4 based SOCs. Hence consolidate the OMAP4 power
> >> management code so that it can be re-used on OMAP5 and later devices.
> >>
> >> While at it, update the kernel-doc for omap4_pm_init().
> >>
> >> Acked-by: Nishanth Menon <nm at ti.com>
> >> Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
> >> ---
> >>  arch/arm/mach-omap2/Makefile                       |    9 +--
> >>  arch/arm/mach-omap2/{pm44xx.c => pm_omap4plus.c}   |   58 ++++++++++++++++----
> >>  .../mach-omap2/{sleep44xx.S => sleep_omap4plus.S}  |    0
> >>  3 files changed, 53 insertions(+), 14 deletions(-)
> >>  rename arch/arm/mach-omap2/{pm44xx.c => pm_omap4plus.c} (83%)
> >>  rename arch/arm/mach-omap2/{sleep44xx.S => sleep_omap4plus.S} (100%)
> > 
> > I suggest you leave out the rename. That just adds churn and has
> > flame potential.
> > 
> OK. I can leave that mow but have to do renames anyways when
> I add OMAP5 support. OMAP54XX support inside pm44xx.c and sleep44x.S
> will be really odd.

Well that should be just fine if the hardware is the same.
 
> Let me know if you have concern on renaming it while OMAP5 support
> gets added ?

If the rename is done, it should have a clear reason to do it in
a separate patch. IMHO it's just fine to have omap4 in some name and
then assume that at least some follow up SoCs also use that code.
In the worst case we may end up renaming things many times:

omap-xyz.c -> omap2-xyz.c -> omap2plus-xyz.c -> omap2-to-4-xyz.c ->
omap2-to-4-and-am35xx-xyz.c etc :)

If we rename something, the description should have a clear reason
for doing it like "To avoid confusing between PM code that does not
have support for bootrom assisted off-idle on SMP omaps with PM code
that's not bootrom assisted, let's rename foo to.."

For the naming, the only safe naming convention is to use something
actually describing the piece of hardware. Maybe some combination
of bootrom-assisted-off-idle + SMP in this case if there's no actual
name for this hwblock?

Regards,

Tony


From sebastian.hesselbarth at gmail.com  Mon Apr  8 12:46:01 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Mon,  8 Apr 2013 18:46:01 +0200
Subject: [PATCH] clk: export __clk_get_flags for modular clock providers
Message-ID: <1365439561-18783-1-git-send-email-sebastian.hesselbarth@gmail.com>

The common clock api provides some helpers for clk-providers but does
not export these helpers. This hinders clk-providers to be built as modules.
This patch adds __clk_get_flags() to the list of exported symbols.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
---
Cc: Mike Turquette <mturquette at linaro.org>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
---
 drivers/clk/clk.c |    1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index ed87b24..3e478b8 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -450,6 +450,7 @@ unsigned long __clk_get_flags(struct clk *clk)
 {
 	return !clk ? 0 : clk->flags;
 }
+EXPORT_SYMBOL_GPL(__clk_get_flags);
 
 bool __clk_is_enabled(struct clk *clk)
 {
-- 
1.7.10.4



From shc_work at mail.ru  Mon Apr  8 12:46:39 2013
From: shc_work at mail.ru (=?UTF-8?B?QWxleGFuZGVyIFNoaXlhbg==?=)
Date: Mon, 08 Apr 2013 20:46:39 +0400
Subject: =?UTF-8?B?UmVbMl06IFtQQVRDSF0gcmVndWxhdG9yOiBtYzEzNzgzOiBBZGQgZGV2aWNl?=
 =?UTF-8?B?IHRyZWUgcHJvYmUgc3VwcG9ydA==?=
In-Reply-To: <20130407192157.GQ6597@opensource.wolfsonmicro.com>
References: <1365354131-9770-1-git-send-email-shc_work@mail.ru>
 <20130407192157.GQ6597@opensource.wolfsonmicro.com>
Message-ID: <1365439599.786794300@f48.mail.ru>

Hello.

> On Sun, Apr 07, 2013 at 09:02:11PM +0400, Alexander Shiyan wrote:
> > Patch adds device tree probe support for mc13783-regulator driver.
> 
> I'd expect to see a document describing the binding for any new binding.
OK.
 
> > +	if (num_parsed != num_regulators) {
> > +		dev_warn(&pdev->dev,
> > +		"parsed %d != regulators %d - check your device tree!\n",
> > +			num_parsed, num_regulators);
> >  
> > -		init_data = &pdata->regulators[i];
> > -		desc = &mc13783_regulators[init_data->id].desc;
> > +		num_regulators = num_parsed;
> > +		priv->num_regulators = num_regulators;
> 
> Why is this something we warn about?  Users should be able to omit
> unused regulators, no point in adding nodes that don't have any real
> information.

Warning is appear on nonexistent regulators names only.
I will rewrite warning procedure in the v2 globally for mc13xx.
Thanks.

---

From sebastian.hesselbarth at gmail.com  Mon Apr  8 12:46:57 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Mon,  8 Apr 2013 18:46:57 +0200
Subject: [PATCH v6] clk: add si5351 i2c common clock driver
In-Reply-To: <1365139415-17815-1-git-send-email-sebastian.hesselbarth@gmail.com>
References: <1365139415-17815-1-git-send-email-sebastian.hesselbarth@gmail.com>
Message-ID: <1365439617-18816-1-git-send-email-sebastian.hesselbarth@gmail.com>

This patch adds a common clock driver for Silicon Labs Si5351a/b/c
i2c programmable clock generators. Currently, the driver does not
support VXCO feature of si5351b. Passing platform_data or DT bindings
selectively allow to overwrite stored Si5351 configuration which is
very helpful for clock generators with empty eeprom configuration.
Corresponding device tree binding documentation is also added.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
---
This v5 introduces a rather big change compared to v4, so I removed
the Daniel Mack's Tested-by. The driver now parses the device tree
prior clock registration to have all clk flags ready. The plus of this
approach is that, the driver now can be used on non-DT kernels as well.

Changes from v5:
- removed __clk_set_flags
- remove CONFIG_OF dependency
- introduce si5351_platform_data (non-DT untested)
- parse DT into si5351_platform_data (tested)
- minor cleanups

Changes from v4:
- move from clk-private.h to clk-provider.h (Reported by Mike Turquette)
- use __clk_set_flags() helper

Changes from v3:
- add silabs prefix to custom DT properties (Reported by Lars-Peter Clausen)
- use sizeof(*foo) instead of sizeof(struct bar) (Reported by Lars-Peter Clausen)
- check return value of of_clk_add_provider (Reported by Lars-Peter Clausen)
- clean up i2c client init (Reported by Lars-Peter Clausen)
- silence successful probe (Suggested by Lars-Peter Clausen)
- make CONFIG_CLK_SI5351 depend on CONFIG_OF

Changes from v2:
- add curly brackets to if-else-statements (Reported by Daniel Mack)
- fix div-by-zero for clk6/clk7 (Reported by Daniel Mack)
- fix parameter address calculation for clk6/clk7

Changes from v1:
- remove .is_enabled functions as they read from i2c
  (Reported by Daniel Mack)
- add CLK_SET_RATE_PARENT on clkout reparent if clkout uses
  its own multisync

Cc: Grant Likely <grant.likely at secretlab.ca>
Cc: Rob Herring <rob.herring at calxeda.com>
Cc: Rob Landley <rob at landley.net>
Cc: Mike Turquette <mturquette at linaro.org>
Cc: Stephen Warren <swarren at nvidia.com>
Cc: Thierry Reding <thierry.reding at avionic-design.de>
Cc: Dom Cobley <popcornmix at gmail.com>
Cc: Linus Walleij <linus.walleij at linaro.org>
Cc: Arnd Bergmann <arnd at arndb.de>
Cc: Andrew Morton <akpm at linux-foundation.org>
Cc: Pawel Moll <pawel.moll at arm.com>
Cc: Mark Brown <broonie at opensource.wolfsonmicro.com>
Cc: Russell King - ARM Linux <linux at arm.linux.org.uk>
Cc: Rabeeh Khoury <rabeeh at solid-run.com>
Cc: Daniel Mack <zonque at gmail.com>
Cc: Jean-Francois Moine <moinejf at free.fr>
Cc: Lars-Peter Clausen <lars at metafoo.de>
Cc: Guenter Roeck <linux at roeck-us.net>
Cc: devicetree-discuss at lists.ozlabs.org
Cc: linux-doc at vger.kernel.org
Cc: linux-kernel at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
---
 .../devicetree/bindings/clock/silabs,si5351.txt    |  114 ++
 .../devicetree/bindings/vendor-prefixes.txt        |    1 +
 drivers/clk/Kconfig                                |    9 +
 drivers/clk/Makefile                               |    1 +
 drivers/clk/clk-si5351.c                           | 1462 ++++++++++++++++++++
 drivers/clk/clk-si5351.h                           |  155 +++
 include/linux/platform_data/si5351.h               |  114 ++
 7 files changed, 1856 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/silabs,si5351.txt
 create mode 100644 drivers/clk/clk-si5351.c
 create mode 100644 drivers/clk/clk-si5351.h
 create mode 100644 include/linux/platform_data/si5351.h

diff --git a/Documentation/devicetree/bindings/clock/silabs,si5351.txt b/Documentation/devicetree/bindings/clock/silabs,si5351.txt
new file mode 100644
index 0000000..cc37465
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/silabs,si5351.txt
@@ -0,0 +1,114 @@
+Binding for Silicon Labs Si5351a/b/c programmable i2c clock generator.
+
+Reference
+[1] Si5351A/B/C Data Sheet
+    http://www.silabs.com/Support%20Documents/TechnicalDocs/Si5351.pdf
+
+The Si5351a/b/c are programmable i2c clock generators with upto 8 output
+clocks. Si5351a also has a reduced pin-count package (MSOP10) where only
+3 output clocks are accessible. The internal structure of the clock
+generators can be found in [1].
+
+==I2C device node==
+
+Required properties:
+- compatible: shall be one of "silabs,si5351{a,a-msop,b,c}".
+- reg: i2c device address, shall be 0x60 or 0x61.
+- #clock-cells: from common clock binding; shall be set to 1.
+- clocks: from common clock binding; list of parent clock
+  handles, shall be xtal reference clock or xtal and clkin for
+  si5351c only.
+- #address-cells: shall be set to 1.
+- #size-cells: shall be set to 0.
+
+Optional properties:
+- silabs,pll-source: pair of (number, source) for each pll. Allows
+  to overwrite clock source of pll A (number=0) or B (number=1).
+
+==Child nodes==
+
+Each of the clock outputs can be overwritten individually by
+using a child node to the I2C device node. If a child node for a clock
+output is not set, the eeprom configuration is not overwritten.
+
+Required child node properties:
+- reg: number of clock output.
+
+Optional child node properties:
+- silabs,clock-source: source clock of the output divider stage N, shall be
+  0 = multisynth N
+  1 = multisynth 0 for output clocks 0-3, else multisynth4
+  2 = xtal
+  3 = clkin (si5351c only)
+- silabs,drive-strength: output drive strength in mA, shall be one of {2,4,6,8}.
+- silabs,multisynth-source: source pll A(0) or B(1) of corresponding multisynth
+  divider.
+- silabs,pll-master: boolean, multisynth can change pll frequency.
+
+==Example==
+
+/* 25MHz reference crystal */
+ref25: ref25M {
+	compatible = "fixed-clock";
+	#clock-cells = <0>;
+	clock-frequency = <25000000>;
+};
+
+i2c-master-node {
+
+	/* Si5351a msop10 i2c clock generator */
+	si5351a: clock-generator at 60 {
+		compatible = "silabs,si5351a-msop";
+		reg = <0x60>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		#clock-cells = <1>;
+
+		/* connect xtal input to 25MHz reference */
+		clocks = <&ref25>;
+
+		/* connect xtal input as source of pll0 and pll1 */
+		silabs,pll-source = <0 0>, <1 0>;
+
+		/*
+		 * overwrite clkout0 configuration with:
+		 * - 8mA output drive strength
+		 * - pll0 as clock source of multisynth0
+		 * - multisynth0 as clock source of output divider
+		 * - multisynth0 can change pll0
+		 * - set initial clock frequency of 74.25MHz
+		 */
+		clkout0 {
+			reg = <0>;
+			silabs,drive-strength = <8>;
+			silabs,multisynth-source = <0>;
+			silabs,clock-source = <0>;
+			silabs,pll-master;
+			clock-frequency = <74250000>;
+		};
+
+		/*
+		 * overwrite clkout1 configuration with:
+		 * - 4mA output drive strength
+		 * - pll1 as clock source of multisynth1
+		 * - multisynth1 as clock source of output divider
+		 * - multisynth1 can change pll1
+		 */
+		clkout1 {
+			reg = <1>;
+			silabs,drive-strength = <4>;
+			silabs,multisynth-source = <1>;
+			silabs,clock-source = <0>;
+			pll-master;
+		};
+
+		/*
+		 * overwrite clkout2 configuration with:
+		 * - xtal as clock source of output divider
+		 */
+		clkout2 {
+			reg = <2>;
+			silabs,clock-source = <2>;
+		};
+	};
+};
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 19e1ef7..ca60849 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -48,6 +48,7 @@ samsung	Samsung Semiconductor
 sbs	Smart Battery System
 schindler	Schindler
 sil	Silicon Image
+silabs	Silicon Laboratories
 simtek
 sirf	SiRF Technology, Inc.
 snps 	Synopsys, Inc.
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index a47e6ee..5039e41 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -55,6 +55,15 @@ config COMMON_CLK_MAX77686
 	---help---
 	  This driver supports Maxim 77686 crystal oscillator clock. 
 
+config COMMON_CLK_SI5351
+	tristate "Clock driver for SiLabs 5351A/B/C"
+	depends on I2C
+	select REGMAP_I2C
+	select RATIONAL
+	---help---
+	  This driver supports Silicon Labs 5351A/B/C programmable clock
+	  generators.
+
 config CLK_TWL6040
 	tristate "External McPDM functional clock from twl6040"
 	depends on TWL6040_CORE
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 300d477..92ca698 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -33,4 +33,5 @@ obj-$(CONFIG_X86)		+= x86/
 # Chip specific
 obj-$(CONFIG_COMMON_CLK_WM831X) += clk-wm831x.o
 obj-$(CONFIG_COMMON_CLK_MAX77686) += clk-max77686.o
+obj-$(CONFIG_COMMON_CLK_SI5351) += clk-si5351.o
 obj-$(CONFIG_CLK_TWL6040)	+= clk-twl6040.o
diff --git a/drivers/clk/clk-si5351.c b/drivers/clk/clk-si5351.c
new file mode 100644
index 0000000..f849601
--- /dev/null
+++ b/drivers/clk/clk-si5351.c
@@ -0,0 +1,1462 @@
+/*
+ * clk-si5351.c: Silicon Laboratories Si5351A/B/C I2C Clock Generator
+ *
+ * Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
+ * Rabeeh Khoury <rabeeh at solid-run.com>
+ *
+ * References:
+ * [1] "Si5351A/B/C Data Sheet"
+ *     http://www.silabs.com/Support%20Documents/TechnicalDocs/Si5351.pdf
+ * [2] "Manually Generating an Si5351 Register Map"
+ *     http://www.silabs.com/Support%20Documents/TechnicalDocs/AN619.pdf
+ *
+ * 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.
+ */
+
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/clkdev.h>
+#include <linux/clk-provider.h>
+#include <linux/delay.h>
+#include <linux/err.h>
+#include <linux/errno.h>
+#include <linux/rational.h>
+#include <linux/i2c.h>
+#include <linux/of_platform.h>
+#include <linux/platform_data/si5351.h>
+#include <linux/regmap.h>
+#include <linux/slab.h>
+#include <linux/string.h>
+#include <asm/div64.h>
+
+#include "clk-si5351.h"
+
+struct si5351_driver_data;
+
+struct si5351_parameters {
+	unsigned long	p1;
+	unsigned long	p2;
+	unsigned long	p3;
+	int		valid;
+};
+
+struct si5351_hw_data {
+	struct clk_hw			hw;
+	struct si5351_driver_data	*drvdata;
+	struct si5351_parameters	params;
+	unsigned char			num;
+};
+
+struct si5351_driver_data {
+	enum si5351_variant	variant;
+	struct i2c_client	*client;
+	struct regmap		*regmap;
+	struct clk_onecell_data onecell;
+
+	struct clk		*pxtal;
+	const char		*pxtal_name;
+	struct clk_hw		xtal;
+	struct clk		*pclkin;
+	const char		*pclkin_name;
+	struct clk_hw		clkin;
+
+	struct si5351_hw_data	pll[2];
+	struct si5351_hw_data	*msynth;
+	struct si5351_hw_data	*clkout;
+};
+
+static const char const *si5351_input_names[] = {
+	"xtal", "clkin"
+};
+static const char const *si5351_pll_names[] = {
+	"plla", "pllb", "vxco"
+};
+static const char const *si5351_msynth_names[] = {
+	"ms0", "ms1", "ms2", "ms3", "ms4", "ms5", "ms6", "ms7"
+};
+static const char const *si5351_clkout_names[] = {
+	"clk0", "clk1", "clk2", "clk3", "clk4", "clk5", "clk6", "clk7"
+};
+
+/*
+ * Si5351 i2c regmap
+ */
+static inline u8 si5351_reg_read(struct si5351_driver_data *drvdata, u8 reg)
+{
+	u32 val;
+	int ret;
+
+	ret = regmap_read(drvdata->regmap, reg, &val);
+	if (ret) {
+		dev_err(&drvdata->client->dev,
+			"unable to read from reg%02x\n", reg);
+		return 0;
+	}
+
+	return (u8)val;
+}
+
+static inline int si5351_bulk_read(struct si5351_driver_data *drvdata,
+				   u8 reg, u8 count, u8 *buf)
+{
+	return regmap_bulk_read(drvdata->regmap, reg, buf, count);
+}
+
+static inline int si5351_reg_write(struct si5351_driver_data *drvdata,
+				   u8 reg, u8 val)
+{
+	return regmap_write(drvdata->regmap, reg, val);
+}
+
+static inline int si5351_bulk_write(struct si5351_driver_data *drvdata,
+				    u8 reg, u8 count, const u8 *buf)
+{
+	return regmap_raw_write(drvdata->regmap, reg, buf, count);
+}
+
+static inline int si5351_set_bits(struct si5351_driver_data *drvdata,
+				  u8 reg, u8 mask, u8 val)
+{
+	return regmap_update_bits(drvdata->regmap, reg, mask, val);
+}
+
+static inline u8 si5351_msynth_params_address(int num)
+{
+	if (num > 5)
+		return SI5351_CLK6_PARAMETERS + (num - 6);
+	return SI5351_CLK0_PARAMETERS + (SI5351_PARAMETERS_LENGTH * num);
+}
+
+static void si5351_read_parameters(struct si5351_driver_data *drvdata,
+				   u8 reg, struct si5351_parameters *params)
+{
+	u8 buf[SI5351_PARAMETERS_LENGTH];
+
+	switch (reg) {
+	case SI5351_CLK6_PARAMETERS:
+	case SI5351_CLK7_PARAMETERS:
+		buf[0] = si5351_reg_read(drvdata, reg);
+		params->p1 = buf[0];
+		params->p2 = 0;
+		params->p3 = 1;
+		break;
+	default:
+		si5351_bulk_read(drvdata, reg, SI5351_PARAMETERS_LENGTH, buf);
+		params->p1 = ((buf[2] & 0x03) << 16) | (buf[3] << 8) | buf[4];
+		params->p2 = ((buf[5] & 0x0f) << 16) | (buf[6] << 8) | buf[7];
+		params->p3 = ((buf[5] & 0xf0) << 12) | (buf[0] << 8) | buf[1];
+	}
+	params->valid = 1;
+}
+
+static void si5351_write_parameters(struct si5351_driver_data *drvdata,
+				    u8 reg, struct si5351_parameters *params)
+{
+	u8 buf[SI5351_PARAMETERS_LENGTH];
+
+	switch (reg) {
+	case SI5351_CLK6_PARAMETERS:
+	case SI5351_CLK7_PARAMETERS:
+		buf[0] = params->p1 & 0xff;
+		si5351_reg_write(drvdata, reg, buf[0]);
+		break;
+	default:
+		buf[0] = ((params->p3 & 0x0ff00) >> 8) & 0xff;
+		buf[1] = params->p3 & 0xff;
+		/* save rdiv and divby4 */
+		buf[2] = si5351_reg_read(drvdata, reg + 2) & ~0x03;
+		buf[2] |= ((params->p1 & 0x30000) >> 16) & 0x03;
+		buf[3] = ((params->p1 & 0x0ff00) >> 8) & 0xff;
+		buf[4] = params->p1 & 0xff;
+		buf[5] = ((params->p3 & 0xf0000) >> 12) |
+			((params->p2 & 0xf0000) >> 16);
+		buf[6] = ((params->p2 & 0x0ff00) >> 8) & 0xff;
+		buf[7] = params->p2 & 0xff;
+		si5351_bulk_write(drvdata, reg, SI5351_PARAMETERS_LENGTH, buf);
+	}
+}
+
+static bool si5351_regmap_is_volatile(struct device *dev, unsigned int reg)
+{
+	switch (reg) {
+	case SI5351_DEVICE_STATUS:
+	case SI5351_INTERRUPT_STATUS:
+	case SI5351_PLL_RESET:
+		return true;
+	}
+	return false;
+}
+
+static bool si5351_regmap_is_writeable(struct device *dev, unsigned int reg)
+{
+	/* reserved registers */
+	if (reg >= 4 && reg <= 8)
+		return false;
+	if (reg >= 10 && reg <= 14)
+		return false;
+	if (reg >= 173 && reg <= 176)
+		return false;
+	if (reg >= 178 && reg <= 182)
+		return false;
+	/* read-only */
+	if (reg == SI5351_DEVICE_STATUS)
+		return false;
+	return true;
+}
+
+static struct regmap_config si5351_regmap_config = {
+	.reg_bits = 8,
+	.val_bits = 8,
+	.cache_type = REGCACHE_RBTREE,
+	.max_register = 187,
+	.writeable_reg = si5351_regmap_is_writeable,
+	.volatile_reg = si5351_regmap_is_volatile,
+};
+
+/*
+ * Si5351 xtal clock input
+ */
+static int si5351_xtal_prepare(struct clk_hw *hw)
+{
+	struct si5351_driver_data *drvdata =
+		container_of(hw, struct si5351_driver_data, xtal);
+	si5351_set_bits(drvdata, SI5351_FANOUT_ENABLE,
+			SI5351_XTAL_ENABLE, SI5351_XTAL_ENABLE);
+	return 0;
+}
+
+static void si5351_xtal_unprepare(struct clk_hw *hw)
+{
+	struct si5351_driver_data *drvdata =
+		container_of(hw, struct si5351_driver_data, xtal);
+	si5351_set_bits(drvdata, SI5351_FANOUT_ENABLE,
+			SI5351_XTAL_ENABLE, 0);
+}
+
+static const struct clk_ops si5351_xtal_ops = {
+	.prepare = si5351_xtal_prepare,
+	.unprepare = si5351_xtal_unprepare,
+};
+
+/*
+ * Si5351 clkin clock input (Si5351C only)
+ */
+static int si5351_clkin_prepare(struct clk_hw *hw)
+{
+	struct si5351_driver_data *drvdata =
+		container_of(hw, struct si5351_driver_data, clkin);
+	si5351_set_bits(drvdata, SI5351_FANOUT_ENABLE,
+			SI5351_CLKIN_ENABLE, SI5351_CLKIN_ENABLE);
+	return 0;
+}
+
+static void si5351_clkin_unprepare(struct clk_hw *hw)
+{
+	struct si5351_driver_data *drvdata =
+		container_of(hw, struct si5351_driver_data, clkin);
+	si5351_set_bits(drvdata, SI5351_FANOUT_ENABLE,
+			SI5351_CLKIN_ENABLE, 0);
+}
+
+/*
+ * CMOS clock source constraints:
+ * The input frequency range of the PLL is 10Mhz to 40MHz.
+ * If CLKIN is >40MHz, the input divider must be used.
+ */
+static unsigned long si5351_clkin_recalc_rate(struct clk_hw *hw,
+					      unsigned long parent_rate)
+{
+	struct si5351_driver_data *drvdata =
+		container_of(hw, struct si5351_driver_data, clkin);
+	unsigned long rate;
+	unsigned char idiv;
+
+	rate = parent_rate;
+	if (parent_rate > 160000000) {
+		idiv = SI5351_CLKIN_DIV_8;
+		rate /= 8;
+	} else if (parent_rate > 80000000) {
+		idiv = SI5351_CLKIN_DIV_4;
+		rate /= 4;
+	} else if (parent_rate > 40000000) {
+		idiv = SI5351_CLKIN_DIV_2;
+		rate /= 2;
+	} else {
+		idiv = SI5351_CLKIN_DIV_1;
+	}
+
+	si5351_set_bits(drvdata, SI5351_PLL_INPUT_SOURCE,
+			SI5351_CLKIN_DIV_MASK, idiv);
+
+	dev_dbg(&drvdata->client->dev, "%s - clkin div = %d, rate = %lu\n",
+		__func__, (1 << (idiv >> 6)), rate);
+
+	return rate;
+}
+
+static const struct clk_ops si5351_clkin_ops = {
+	.prepare = si5351_clkin_prepare,
+	.unprepare = si5351_clkin_unprepare,
+	.recalc_rate = si5351_clkin_recalc_rate,
+};
+
+/*
+ * Si5351 vxco clock input (Si5351B only)
+ */
+
+static int si5351_vxco_prepare(struct clk_hw *hw)
+{
+	struct si5351_hw_data *hwdata =
+		container_of(hw, struct si5351_hw_data, hw);
+
+	dev_warn(&hwdata->drvdata->client->dev, "VXCO currently unsupported\n");
+
+	return 0;
+}
+
+static void si5351_vxco_unprepare(struct clk_hw *hw)
+{
+}
+
+static unsigned long si5351_vxco_recalc_rate(struct clk_hw *hw,
+					     unsigned long parent_rate)
+{
+	return 0;
+}
+
+static int si5351_vxco_set_rate(struct clk_hw *hw, unsigned long rate,
+				unsigned long parent)
+{
+	return 0;
+}
+
+static const struct clk_ops si5351_vxco_ops = {
+	.prepare = si5351_vxco_prepare,
+	.unprepare = si5351_vxco_unprepare,
+	.recalc_rate = si5351_vxco_recalc_rate,
+	.set_rate = si5351_vxco_set_rate,
+};
+
+/*
+ * Si5351 pll a/b
+ *
+ * Feedback Multisynth Divider Equations [2]
+ *
+ * fVCO = fIN * (a + b/c)
+ *
+ * with 15 + 0/1048575 <= (a + b/c) <= 90 + 0/1048575 and
+ * fIN = fXTAL or fIN = fCLKIN/CLKIN_DIV
+ *
+ * Feedback Multisynth Register Equations
+ *
+ * (1) MSNx_P1[17:0] = 128 * a + floor(128 * b/c) - 512
+ * (2) MSNx_P2[19:0] = 128 * b - c * floor(128 * b/c) = (128*b) mod c
+ * (3) MSNx_P3[19:0] = c
+ *
+ * Transposing (2) yields: (4) floor(128 * b/c) = (128 * b / MSNx_P2)/c
+ *
+ * Using (4) on (1) yields:
+ * MSNx_P1 = 128 * a + (128 * b/MSNx_P2)/c - 512
+ * MSNx_P1 + 512 + MSNx_P2/c = 128 * a + 128 * b/c
+ *
+ * a + b/c = (MSNx_P1 + MSNx_P2/MSNx_P3 + 512)/128
+ *         = (MSNx_P1*MSNx_P3 + MSNx_P2 + 512*MSNx_P3)/(128*MSNx_P3)
+ *
+ */
+static inline void _si5351_pll_reparent(struct si5351_driver_data *drvdata,
+					int num, enum si5351_pll_src parent)
+{
+	u8 mask = (num == 0) ? SI5351_PLLA_SOURCE : SI5351_PLLB_SOURCE;
+
+	if (parent == SI5351_PLL_SRC_DEFAULT)
+		return;
+
+	si5351_set_bits(drvdata, SI5351_PLL_INPUT_SOURCE, mask,
+			(parent == SI5351_PLL_SRC_XTAL) ? 0 : mask);
+}
+
+static unsigned char si5351_pll_get_parent(struct clk_hw *hw)
+{
+	struct si5351_hw_data *hwdata =
+		container_of(hw, struct si5351_hw_data, hw);
+	u8 mask = (hwdata->num == 0) ? SI5351_PLLA_SOURCE : SI5351_PLLB_SOURCE;
+	u8 val;
+
+	val = si5351_reg_read(hwdata->drvdata, SI5351_PLL_INPUT_SOURCE);
+
+	return (val & mask) ? 1 : 0;
+}
+
+static int si5351_pll_set_parent(struct clk_hw *hw, u8 index)
+{
+	struct si5351_hw_data *hwdata =
+		container_of(hw, struct si5351_hw_data, hw);
+
+	if (hwdata->drvdata->variant != SI5351_VARIANT_C &&
+	    index > 0)
+		return -EPERM;
+
+	if (index > 1)
+		return -EINVAL;
+
+	_si5351_pll_reparent(hwdata->drvdata, hwdata->num,
+			     (index == 0) ? SI5351_PLL_SRC_XTAL :
+			     SI5351_PLL_SRC_CLKIN);
+
+	return 0;
+}
+
+static unsigned long si5351_pll_recalc_rate(struct clk_hw *hw,
+					    unsigned long parent_rate)
+{
+	struct si5351_hw_data *hwdata =
+		container_of(hw, struct si5351_hw_data, hw);
+	u8 reg = (hwdata->num == 0) ? SI5351_PLLA_PARAMETERS :
+		SI5351_PLLB_PARAMETERS;
+	unsigned long long rate;
+
+	if (!hwdata->params.valid)
+		si5351_read_parameters(hwdata->drvdata, reg, &hwdata->params);
+
+	if (hwdata->params.p3 == 0)
+		return parent_rate;
+
+	/* fVCO = fIN * (P1*P3 + 512*P3 + P2)/(128*P3) */
+	rate  = hwdata->params.p1 * hwdata->params.p3;
+	rate += 512 * hwdata->params.p3;
+	rate += hwdata->params.p2;
+	rate *= parent_rate;
+	do_div(rate, 128 * hwdata->params.p3);
+
+	dev_dbg(&hwdata->drvdata->client->dev,
+		"%s - %s: p1 = %lu, p2 = %lu, p3 = %lu, parent_rate = %lu, rate = %lu\n",
+		__func__, __clk_get_name(hwdata->hw.clk),
+		hwdata->params.p1, hwdata->params.p2, hwdata->params.p3,
+		parent_rate, (unsigned long)rate);
+
+	return (unsigned long)rate;
+}
+
+static long si5351_pll_round_rate(struct clk_hw *hw, unsigned long rate,
+				  unsigned long *parent_rate)
+{
+	struct si5351_hw_data *hwdata =
+		container_of(hw, struct si5351_hw_data, hw);
+	unsigned long rfrac, denom, a, b, c;
+	unsigned long long lltmp;
+
+	if (rate < SI5351_PLL_VCO_MIN)
+		rate = SI5351_PLL_VCO_MIN;
+	if (rate > SI5351_PLL_VCO_MAX)
+		rate = SI5351_PLL_VCO_MAX;
+
+	/* determine integer part of feedback equation */
+	a = rate / *parent_rate;
+
+	if (a < SI5351_PLL_A_MIN)
+		rate = *parent_rate * SI5351_PLL_A_MIN;
+	if (a > SI5351_PLL_A_MAX)
+		rate = *parent_rate * SI5351_PLL_A_MAX;
+
+	/* find best approximation for b/c = fVCO mod fIN */
+	denom = 1000 * 1000;
+	lltmp = rate % (*parent_rate);
+	lltmp *= denom;
+	do_div(lltmp, *parent_rate);
+	rfrac = (unsigned long)lltmp;
+
+	b = 0;
+	c = 1;
+	if (rfrac)
+		rational_best_approximation(rfrac, denom,
+				    SI5351_PLL_B_MAX, SI5351_PLL_C_MAX, &b, &c);
+
+	/* calculate parameters */
+	hwdata->params.p3  = c;
+	hwdata->params.p2  = (128 * b) % c;
+	hwdata->params.p1  = 128 * a;
+	hwdata->params.p1 += (128 * b / c);
+	hwdata->params.p1 -= 512;
+
+	/* recalculate rate by fIN * (a + b/c) */
+	lltmp  = *parent_rate;
+	lltmp *= b;
+	do_div(lltmp, c);
+
+	rate  = (unsigned long)lltmp;
+	rate += *parent_rate * a;
+
+	dev_dbg(&hwdata->drvdata->client->dev,
+		"%s - %s: a = %lu, b = %lu, c = %lu, parent_rate = %lu, rate = %lu\n",
+		__func__, __clk_get_name(hwdata->hw.clk), a, b, c,
+		*parent_rate, rate);
+
+	return rate;
+}
+
+static int si5351_pll_set_rate(struct clk_hw *hw, unsigned long rate,
+			       unsigned long parent_rate)
+{
+	struct si5351_hw_data *hwdata =
+		container_of(hw, struct si5351_hw_data, hw);
+	u8 reg = (hwdata->num == 0) ? SI5351_PLLA_PARAMETERS :
+		SI5351_PLLB_PARAMETERS;
+	u8 val;
+
+	/* write multisynth parameters */
+	si5351_write_parameters(hwdata->drvdata, reg, &hwdata->params);
+
+	/* plla/pllb ctrl is in clk6/clk7 ctrl registers */
+	si5351_set_bits(hwdata->drvdata, SI5351_CLK6_CTRL + hwdata->num,
+		SI5351_CLK_INTEGER_MODE,
+		(hwdata->params.p2 == 0) ? SI5351_CLK_INTEGER_MODE : 0);
+
+	/* reset pll */
+	val = (hwdata->num == 0) ? SI5351_PLL_RESET_A : SI5351_PLL_RESET_B;
+	si5351_set_bits(hwdata->drvdata, SI5351_PLL_RESET, val, val);
+
+	dev_dbg(&hwdata->drvdata->client->dev,
+		"%s - %s: p1 = %lu, p2 = %lu, p3 = %lu, parent_rate = %lu, rate = %lu\n",
+		__func__, __clk_get_name(hwdata->hw.clk),
+		hwdata->params.p1, hwdata->params.p2, hwdata->params.p3,
+		parent_rate, rate);
+
+	return 0;
+}
+
+static const struct clk_ops si5351_pll_ops = {
+	.set_parent = si5351_pll_set_parent,
+	.get_parent = si5351_pll_get_parent,
+	.recalc_rate = si5351_pll_recalc_rate,
+	.round_rate = si5351_pll_round_rate,
+	.set_rate = si5351_pll_set_rate,
+};
+
+/*
+ * Si5351 multisync divider
+ *
+ * for fOUT <= 150 MHz:
+ *
+ * fOUT = (fIN * (a + b/c)) / CLKOUTDIV
+ *
+ * with 6 + 0/1048575 <= (a + b/c) <= 1800 + 0/1048575 and
+ * fIN = fVCO0, fVCO1
+ *
+ * Output Clock Multisynth Register Equations
+ *
+ * MSx_P1[17:0] = 128 * a + floor(128 * b/c) - 512
+ * MSx_P2[19:0] = 128 * b - c * floor(128 * b/c) = (128*b) mod c
+ * MSx_P3[19:0] = c
+ *
+ * MS[6,7] are integer (P1) divide only, P2 = 0, P3 = 0
+ *
+ * for 150MHz < fOUT <= 160MHz:
+ *
+ * MSx_P1 = 0, MSx_P2 = 0, MSx_P3 = 1, MSx_INT = 1, MSx_DIVBY4 = 11b
+ */
+static inline void _si5351_msynth_reparent(struct si5351_driver_data *drvdata,
+				   int num, enum si5351_multisynth_src parent)
+{
+	if (parent == SI5351_MULTISYNTH_SRC_DEFAULT)
+		return;
+
+	si5351_set_bits(drvdata, SI5351_CLK0_CTRL + num, SI5351_CLK_PLL_SELECT,
+			(parent == SI5351_MULTISYNTH_SRC_VCO0) ? 0 :
+			SI5351_CLK_PLL_SELECT);
+}
+
+static unsigned char si5351_msynth_get_parent(struct clk_hw *hw)
+{
+	struct si5351_hw_data *hwdata =
+		container_of(hw, struct si5351_hw_data, hw);
+	u8 val;
+
+	val = si5351_reg_read(hwdata->drvdata, SI5351_CLK0_CTRL + hwdata->num);
+
+	return (val & SI5351_CLK_PLL_SELECT) ? 1 : 0;
+}
+
+static int si5351_msynth_set_parent(struct clk_hw *hw, u8 index)
+{
+	struct si5351_hw_data *hwdata =
+		container_of(hw, struct si5351_hw_data, hw);
+
+	_si5351_msynth_reparent(hwdata->drvdata, hwdata->num,
+				(index == 0) ? SI5351_MULTISYNTH_SRC_VCO0 :
+				SI5351_MULTISYNTH_SRC_VCO1);
+	return 0;
+}
+
+static unsigned long si5351_msynth_recalc_rate(struct clk_hw *hw,
+					       unsigned long parent_rate)
+{
+	struct si5351_hw_data *hwdata =
+		container_of(hw, struct si5351_hw_data, hw);
+	u8 reg = si5351_msynth_params_address(hwdata->num);
+	unsigned long long rate;
+	unsigned long m;
+
+	if (!hwdata->params.valid)
+		si5351_read_parameters(hwdata->drvdata, reg, &hwdata->params);
+
+	if (hwdata->params.p3 == 0)
+		return parent_rate;
+
+	/*
+	 * multisync0-5: fOUT = (128 * P3 * fIN) / (P1*P3 + P2 + 512*P3)
+	 * multisync6-7: fOUT = fIN / P1
+	 */
+	rate = parent_rate;
+	if (hwdata->num > 5) {
+		m = hwdata->params.p1;
+	} else if ((si5351_reg_read(hwdata->drvdata, reg + 2) &
+		    SI5351_OUTPUT_CLK_DIVBY4) == SI5351_OUTPUT_CLK_DIVBY4) {
+		m = 4;
+	} else {
+		rate *= 128 * hwdata->params.p3;
+		m = hwdata->params.p1 * hwdata->params.p3;
+		m += hwdata->params.p2;
+		m += 512 * hwdata->params.p3;
+	}
+
+	if (m == 0)
+		return 0;
+	do_div(rate, m);
+
+	dev_dbg(&hwdata->drvdata->client->dev,
+		"%s - %s: p1 = %lu, p2 = %lu, p3 = %lu, m = %lu, parent_rate = %lu, rate = %lu\n",
+		__func__, __clk_get_name(hwdata->hw.clk),
+		hwdata->params.p1, hwdata->params.p2, hwdata->params.p3,
+		m, parent_rate, (unsigned long)rate);
+
+	return (unsigned long)rate;
+}
+
+static long si5351_msynth_round_rate(struct clk_hw *hw, unsigned long rate,
+				     unsigned long *parent_rate)
+{
+	struct si5351_hw_data *hwdata =
+		container_of(hw, struct si5351_hw_data, hw);
+	unsigned long long lltmp;
+	unsigned long a, b, c;
+	int divby4;
+
+	/* multisync6-7 can only handle freqencies < 150MHz */
+	if (hwdata->num >= 6 && rate > SI5351_MULTISYNTH67_MAX_FREQ)
+		rate = SI5351_MULTISYNTH67_MAX_FREQ;
+
+	/* multisync frequency is 1MHz .. 160MHz */
+	if (rate > SI5351_MULTISYNTH_MAX_FREQ)
+		rate = SI5351_MULTISYNTH_MAX_FREQ;
+	if (rate < SI5351_MULTISYNTH_MIN_FREQ)
+		rate = SI5351_MULTISYNTH_MIN_FREQ;
+
+	divby4 = 0;
+	if (rate > SI5351_MULTISYNTH_DIVBY4_FREQ)
+		divby4 = 1;
+
+	/* multisync can set pll */
+	if (__clk_get_flags(hwdata->hw.clk) & CLK_SET_RATE_PARENT) {
+		/*
+		 * find largest integer divider for max
+		 * vco frequency and given target rate
+		 */
+		if (divby4 == 0) {
+			lltmp = SI5351_PLL_VCO_MAX;
+			do_div(lltmp, rate);
+			a = (unsigned long)lltmp;
+		} else
+			a = 4;
+
+		b = 0;
+		c = 1;
+
+		*parent_rate = a * rate;
+	} else {
+		unsigned long rfrac, denom;
+
+		/* disable divby4 */
+		if (divby4) {
+			rate = SI5351_MULTISYNTH_DIVBY4_FREQ;
+			divby4 = 0;
+		}
+
+		/* determine integer part of divider equation */
+		a = *parent_rate / rate;
+		if (a < SI5351_MULTISYNTH_A_MIN)
+			a = SI5351_MULTISYNTH_A_MIN;
+		if (hwdata->num >= 6 && a > SI5351_MULTISYNTH67_A_MAX)
+			a = SI5351_MULTISYNTH67_A_MAX;
+		else if (a > SI5351_MULTISYNTH_A_MAX)
+			a = SI5351_MULTISYNTH_A_MAX;
+
+		/* find best approximation for b/c = fVCO mod fOUT */
+		denom = 1000 * 1000;
+		lltmp = (*parent_rate) % rate;
+		lltmp *= denom;
+		do_div(lltmp, rate);
+		rfrac = (unsigned long)lltmp;
+
+		b = 0;
+		c = 1;
+		if (rfrac)
+			rational_best_approximation(rfrac, denom,
+			    SI5351_MULTISYNTH_B_MAX, SI5351_MULTISYNTH_C_MAX,
+			    &b, &c);
+	}
+
+	/* recalculate rate by fOUT = fIN / (a + b/c) */
+	lltmp  = *parent_rate;
+	lltmp *= c;
+	do_div(lltmp, a * c + b);
+	rate  = (unsigned long)lltmp;
+
+	/* calculate parameters */
+	if (divby4) {
+		hwdata->params.p3 = 1;
+		hwdata->params.p2 = 0;
+		hwdata->params.p1 = 0;
+	} else {
+		hwdata->params.p3  = c;
+		hwdata->params.p2  = (128 * b) % c;
+		hwdata->params.p1  = 128 * a;
+		hwdata->params.p1 += (128 * b / c);
+		hwdata->params.p1 -= 512;
+	}
+
+	dev_dbg(&hwdata->drvdata->client->dev,
+		"%s - %s: a = %lu, b = %lu, c = %lu, divby4 = %d, parent_rate = %lu, rate = %lu\n",
+		__func__, __clk_get_name(hwdata->hw.clk), a, b, c, divby4,
+		*parent_rate, rate);
+
+	return rate;
+}
+
+static int si5351_msynth_set_rate(struct clk_hw *hw, unsigned long rate,
+				  unsigned long parent_rate)
+{
+	struct si5351_hw_data *hwdata =
+		container_of(hw, struct si5351_hw_data, hw);
+	u8 reg = si5351_msynth_params_address(hwdata->num);
+	int divby4 = 0;
+
+	/* write multisynth parameters */
+	si5351_write_parameters(hwdata->drvdata, reg, &hwdata->params);
+
+	if (rate > SI5351_MULTISYNTH_DIVBY4_FREQ)
+		divby4 = 1;
+
+	/* enable/disable integer mode and divby4 on multisynth0-5 */
+	if (hwdata->num < 6) {
+		si5351_set_bits(hwdata->drvdata, reg + 2,
+				SI5351_OUTPUT_CLK_DIVBY4,
+				(divby4) ? SI5351_OUTPUT_CLK_DIVBY4 : 0);
+		si5351_set_bits(hwdata->drvdata, SI5351_CLK0_CTRL + hwdata->num,
+			SI5351_CLK_INTEGER_MODE,
+			(hwdata->params.p2 == 0) ? SI5351_CLK_INTEGER_MODE : 0);
+	}
+
+	dev_dbg(&hwdata->drvdata->client->dev,
+		"%s - %s: p1 = %lu, p2 = %lu, p3 = %lu, divby4 = %d, parent_rate = %lu, rate = %lu\n",
+		__func__, __clk_get_name(hwdata->hw.clk),
+		hwdata->params.p1, hwdata->params.p2, hwdata->params.p3,
+		divby4, parent_rate, rate);
+
+	return 0;
+}
+
+static const struct clk_ops si5351_msynth_ops = {
+	.set_parent = si5351_msynth_set_parent,
+	.get_parent = si5351_msynth_get_parent,
+	.recalc_rate = si5351_msynth_recalc_rate,
+	.round_rate = si5351_msynth_round_rate,
+	.set_rate = si5351_msynth_set_rate,
+};
+
+/*
+ * Si5351 clkout divider
+ */
+static inline void _si5351_clkout_reparent(struct si5351_driver_data *drvdata,
+				  int num, enum si5351_clkout_src parent)
+{
+	u8 val;
+
+	if (num > 8)
+		return;
+
+	switch (parent) {
+	case SI5351_CLKOUT_SRC_MSYNTH_N:
+		val = SI5351_CLK_INPUT_MULTISYNTH_N;
+		break;
+	case SI5351_CLKOUT_SRC_MSYNTH_0_4:
+		/* clk0/clk4 can only connect to its own multisync */
+		if (num == 0 || num == 4)
+			val = SI5351_CLK_INPUT_MULTISYNTH_N;
+		else
+			val = SI5351_CLK_INPUT_MULTISYNTH_0_4;
+		break;
+	case SI5351_CLKOUT_SRC_XTAL:
+		val = SI5351_CLK_INPUT_XTAL;
+		break;
+	case SI5351_CLKOUT_SRC_CLKIN:
+		val = SI5351_CLK_INPUT_CLKIN;
+		break;
+	default:
+		return;
+	}
+
+	si5351_set_bits(drvdata, SI5351_CLK0_CTRL + num,
+			SI5351_CLK_INPUT_MASK, val);
+}
+
+static inline void _si5351_clkout_set_drive_strength(
+	struct si5351_driver_data *drvdata, int num,
+	enum si5351_drive_strength drive)
+{
+	u8 mask;
+
+	if (num > 8)
+		return;
+
+	switch (drive) {
+	case SI5351_DRIVE_2MA:
+		mask = SI5351_CLK_DRIVE_STRENGTH_2MA;
+		break;
+	case SI5351_DRIVE_4MA:
+		mask = SI5351_CLK_DRIVE_STRENGTH_4MA;
+		break;
+	case SI5351_DRIVE_6MA:
+		mask = SI5351_CLK_DRIVE_STRENGTH_6MA;
+		break;
+	case SI5351_DRIVE_8MA:
+		mask = SI5351_CLK_DRIVE_STRENGTH_8MA;
+		break;
+	default:
+		return;
+	}
+
+	si5351_set_bits(drvdata, SI5351_CLK0_CTRL + num,
+			SI5351_CLK_DRIVE_STRENGTH_MASK, mask);
+}
+
+static int si5351_clkout_prepare(struct clk_hw *hw)
+{
+	struct si5351_hw_data *hwdata =
+		container_of(hw, struct si5351_hw_data, hw);
+
+	si5351_set_bits(hwdata->drvdata, SI5351_CLK0_CTRL + hwdata->num,
+			SI5351_CLK_POWERDOWN, 0);
+	si5351_set_bits(hwdata->drvdata, SI5351_OUTPUT_ENABLE_CTRL,
+			(1 << hwdata->num), 0);
+	return 0;
+}
+
+static void si5351_clkout_unprepare(struct clk_hw *hw)
+{
+	struct si5351_hw_data *hwdata =
+		container_of(hw, struct si5351_hw_data, hw);
+
+	si5351_set_bits(hwdata->drvdata, SI5351_CLK0_CTRL + hwdata->num,
+			SI5351_CLK_POWERDOWN, SI5351_CLK_POWERDOWN);
+	si5351_set_bits(hwdata->drvdata, SI5351_OUTPUT_ENABLE_CTRL,
+			(1 << hwdata->num), (1 << hwdata->num));
+}
+
+static u8 si5351_clkout_get_parent(struct clk_hw *hw)
+{
+	struct si5351_hw_data *hwdata =
+		container_of(hw, struct si5351_hw_data, hw);
+	int index = 0;
+	unsigned char val;
+
+	val = si5351_reg_read(hwdata->drvdata, SI5351_CLK0_CTRL + hwdata->num);
+	switch (val & SI5351_CLK_INPUT_MASK) {
+	case SI5351_CLK_INPUT_MULTISYNTH_N:
+		index = 0;
+		break;
+	case SI5351_CLK_INPUT_MULTISYNTH_0_4:
+		index = 1;
+		break;
+	case SI5351_CLK_INPUT_XTAL:
+		index = 2;
+		break;
+	case SI5351_CLK_INPUT_CLKIN:
+		index = 3;
+		break;
+	}
+
+	return index;
+}
+
+static int si5351_clkout_set_parent(struct clk_hw *hw, u8 index)
+{
+	struct si5351_hw_data *hwdata =
+		container_of(hw, struct si5351_hw_data, hw);
+	enum si5351_clkout_src parent = SI5351_CLKOUT_SRC_DEFAULT;
+
+	switch (index) {
+	case 0:
+		parent = SI5351_CLKOUT_SRC_MSYNTH_N;
+		break;
+	case 1:
+		parent = SI5351_CLKOUT_SRC_MSYNTH_0_4;
+		break;
+	case 2:
+		parent = SI5351_CLKOUT_SRC_XTAL;
+		break;
+	case 3:
+		parent = SI5351_CLKOUT_SRC_CLKIN;
+		break;
+	}
+
+	_si5351_clkout_reparent(hwdata->drvdata, hwdata->num, parent);
+
+	return 0;
+}
+
+static unsigned long si5351_clkout_recalc_rate(struct clk_hw *hw,
+					       unsigned long parent_rate)
+{
+	struct si5351_hw_data *hwdata =
+		container_of(hw, struct si5351_hw_data, hw);
+	unsigned char reg;
+	unsigned char rdiv;
+
+	if (hwdata->num > 5)
+		reg = si5351_msynth_params_address(hwdata->num) + 2;
+	else
+		reg = SI5351_CLK6_7_OUTPUT_DIVIDER;
+
+	rdiv = si5351_reg_read(hwdata->drvdata, reg);
+	if (hwdata->num == 6) {
+		rdiv &= SI5351_OUTPUT_CLK6_DIV_MASK;
+	} else {
+		rdiv &= SI5351_OUTPUT_CLK_DIV_MASK;
+		rdiv >>= SI5351_OUTPUT_CLK_DIV_SHIFT;
+	}
+
+	return parent_rate >> rdiv;
+}
+
+static long si5351_clkout_round_rate(struct clk_hw *hw, unsigned long rate,
+				     unsigned long *parent_rate)
+{
+	struct si5351_hw_data *hwdata =
+		container_of(hw, struct si5351_hw_data, hw);
+	unsigned char rdiv;
+
+	/* clkout6/7 can only handle output freqencies < 150MHz */
+	if (hwdata->num >= 6 && rate > SI5351_CLKOUT67_MAX_FREQ)
+		rate = SI5351_CLKOUT67_MAX_FREQ;
+
+	/* clkout freqency is 8kHz - 160MHz */
+	if (rate > SI5351_CLKOUT_MAX_FREQ)
+		rate = SI5351_CLKOUT_MAX_FREQ;
+	if (rate < SI5351_CLKOUT_MIN_FREQ)
+		rate = SI5351_CLKOUT_MIN_FREQ;
+
+	/* request frequency if multisync master */
+	if (__clk_get_flags(hwdata->hw.clk) & CLK_SET_RATE_PARENT) {
+		/* use r divider for frequencies below 1MHz */
+		rdiv = SI5351_OUTPUT_CLK_DIV_1;
+		while (rate < SI5351_MULTISYNTH_MIN_FREQ &&
+		       rdiv < SI5351_OUTPUT_CLK_DIV_128) {
+			rdiv += 1;
+			rate *= 2;
+		}
+		*parent_rate = rate;
+	} else {
+		unsigned long new_rate, new_err, err;
+
+		/* round to closed rdiv */
+		rdiv = SI5351_OUTPUT_CLK_DIV_1;
+		new_rate = *parent_rate;
+		err = abs(new_rate - rate);
+		do {
+			new_rate >>= 1;
+			new_err = abs(new_rate - rate);
+			if (new_err > err || rdiv == SI5351_OUTPUT_CLK_DIV_128)
+				break;
+			rdiv++;
+			err = new_err;
+		} while (1);
+	}
+	rate = *parent_rate >> rdiv;
+
+	dev_dbg(&hwdata->drvdata->client->dev,
+		"%s - %s: rdiv = %u, parent_rate = %lu, rate = %lu\n",
+		__func__, __clk_get_name(hwdata->hw.clk), (1 << rdiv),
+		*parent_rate, rate);
+
+	return rate;
+}
+
+static int si5351_clkout_set_rate(struct clk_hw *hw, unsigned long rate,
+				  unsigned long parent_rate)
+{
+	struct si5351_hw_data *hwdata =
+		container_of(hw, struct si5351_hw_data, hw);
+	unsigned long new_rate, new_err, err;
+	unsigned char rdiv;
+
+	/* round to closed rdiv */
+	rdiv = SI5351_OUTPUT_CLK_DIV_1;
+	new_rate = parent_rate;
+	err = abs(new_rate - rate);
+	do {
+		new_rate >>= 1;
+		new_err = abs(new_rate - rate);
+		if (new_err > err || rdiv == SI5351_OUTPUT_CLK_DIV_128)
+			break;
+		rdiv++;
+		err = new_err;
+	} while (1);
+
+	/* powerdown clkout */
+	si5351_set_bits(hwdata->drvdata, SI5351_CLK0_CTRL + hwdata->num,
+			SI5351_CLK_POWERDOWN, SI5351_CLK_POWERDOWN);
+
+	/* write output divider */
+	switch (hwdata->num) {
+	case 6:
+		si5351_set_bits(hwdata->drvdata, SI5351_CLK6_7_OUTPUT_DIVIDER,
+				SI5351_OUTPUT_CLK6_DIV_MASK, rdiv);
+		break;
+	case 7:
+		si5351_set_bits(hwdata->drvdata, SI5351_CLK6_7_OUTPUT_DIVIDER,
+				SI5351_OUTPUT_CLK_DIV_MASK,
+				rdiv << SI5351_OUTPUT_CLK_DIV_SHIFT);
+		break;
+	default:
+		si5351_set_bits(hwdata->drvdata,
+				si5351_msynth_params_address(hwdata->num) + 2,
+				SI5351_OUTPUT_CLK_DIV_MASK,
+				rdiv << SI5351_OUTPUT_CLK_DIV_SHIFT);
+	}
+
+	/* powerup clkout */
+	si5351_set_bits(hwdata->drvdata, SI5351_CLK0_CTRL + hwdata->num,
+			SI5351_CLK_POWERDOWN, 0);
+
+	dev_dbg(&hwdata->drvdata->client->dev,
+		"%s - %s: rdiv = %u, parent_rate = %lu, rate = %lu\n",
+		__func__, __clk_get_name(hwdata->hw.clk), (1 << rdiv),
+		parent_rate, rate);
+
+	return 0;
+}
+
+static const struct clk_ops si5351_clkout_ops = {
+	.prepare = si5351_clkout_prepare,
+	.unprepare = si5351_clkout_unprepare,
+	.set_parent = si5351_clkout_set_parent,
+	.get_parent = si5351_clkout_get_parent,
+	.recalc_rate = si5351_clkout_recalc_rate,
+	.round_rate = si5351_clkout_round_rate,
+	.set_rate = si5351_clkout_set_rate,
+};
+
+/*
+ * Si5351 i2c probe and DT
+ */
+#ifdef CONFIG_OF
+static const struct of_device_id si5351_dt_ids[] = {
+	{ .compatible = "silabs,si5351a", .data = (void *)SI5351_VARIANT_A, },
+	{ .compatible = "silabs,si5351a-msop",
+					 .data = (void *)SI5351_VARIANT_A3, },
+	{ .compatible = "silabs,si5351b", .data = (void *)SI5351_VARIANT_B, },
+	{ .compatible = "silabs,si5351c", .data = (void *)SI5351_VARIANT_C, },
+	{ }
+};
+MODULE_DEVICE_TABLE(of, si5351_dt_ids);
+
+static int si5351_dt_parse(struct i2c_client *client)
+{
+	struct device_node *child, *np = client->dev.of_node;
+	struct si5351_platform_data *pdata;
+	const struct of_device_id *match;
+	struct property *prop;
+	const __be32 *p;
+	int num = 0;
+	u32 val;
+
+	if (np == NULL)
+		return 0;
+
+	match = of_match_node(si5351_dt_ids, np);
+	if (match == NULL)
+		return -EINVAL;
+
+	pdata = devm_kzalloc(&client->dev, sizeof(*pdata), GFP_KERNEL);
+	if (!pdata)
+		return -ENOMEM;
+
+	pdata->variant = (enum si5351_variant)match->data;
+	pdata->clk_xtal = of_clk_get(np, 0);
+	if (!IS_ERR(pdata->clk_xtal))
+		clk_put(pdata->clk_xtal);
+	pdata->clk_clkin = of_clk_get(np, 1);
+	if (!IS_ERR(pdata->clk_clkin))
+		clk_put(pdata->clk_clkin);
+
+	/*
+	 * property silabs,pll-source : <num src>, [<..>]
+	 * allow to selectively set pll source
+	 */
+	of_property_for_each_u32(np, "silabs,pll-source", prop, p, num) {
+		if (num >= 2) {
+			dev_err(&client->dev,
+				"invalid pll %d on pll-source prop\n", num);
+			break;
+		}
+
+		p = of_prop_next_u32(prop, p, &val);
+		if (!p)
+			break;
+
+		switch (val) {
+		case 0:
+			pdata->pll_src[num] = SI5351_PLL_SRC_XTAL;
+			break;
+		case 1:
+			pdata->pll_src[num] = SI5351_PLL_SRC_CLKIN;
+			break;
+		default:
+			dev_warn(&client->dev,
+				 "invalid parent %d for pll %d\n", val, num);
+			continue;
+		}
+	}
+
+	/* per clkout properties */
+	num = of_get_child_count(np);
+
+	if (num == 0)
+		return 0;
+
+	for_each_child_of_node(np, child) {
+		if (of_property_read_u32(child, "reg", &num)) {
+			dev_err(&client->dev, "missing reg property of %s\n",
+				child->name);
+			continue;
+		}
+
+		if (!of_property_read_u32(child, "silabs,multisynth-source",
+					  &val)) {
+			switch (val) {
+			case 0:
+				pdata->clkout[num].multisynth_src =
+					SI5351_MULTISYNTH_SRC_VCO0;
+				break;
+			case 1:
+				pdata->clkout[num].multisynth_src =
+					SI5351_MULTISYNTH_SRC_VCO1;
+				break;
+			default:
+				dev_warn(&client->dev,
+					 "invalid parent %d for multisynth %d\n",
+					 val, num);
+			}
+		}
+
+		if (!of_property_read_u32(child, "silabs,clock-source", &val)) {
+			switch (val) {
+			case 0:
+				pdata->clkout[num].clkout_src =
+					SI5351_CLKOUT_SRC_MSYNTH_N;
+				break;
+			case 1:
+				pdata->clkout[num].clkout_src =
+					SI5351_CLKOUT_SRC_MSYNTH_0_4;
+				break;
+			case 2:
+				pdata->clkout[num].clkout_src =
+					SI5351_CLKOUT_SRC_XTAL;
+				break;
+			case 3:
+				pdata->clkout[num].clkout_src =
+					SI5351_CLKOUT_SRC_CLKIN;
+				break;
+			default:
+				dev_warn(&client->dev,
+					 "invalid parent %d for clkout %d\n",
+					 val, num);
+			}
+		}
+
+		if (!of_property_read_u32(child, "silabs,drive-strength",
+					  &val)) {
+			switch (val) {
+			case SI5351_DRIVE_2MA:
+			case SI5351_DRIVE_4MA:
+			case SI5351_DRIVE_6MA:
+			case SI5351_DRIVE_8MA:
+				pdata->clkout[num].drive = val;
+				break;
+			default:
+				dev_warn(&client->dev,
+					 "invalid drive strength %d for clkout %d\n",
+					 val, num);
+			}
+		}
+
+		if (!of_property_read_u32(child, "clock-frequency", &val))
+			pdata->clkout[num].rate = val;
+
+		pdata->clkout[num].pll_master =
+			of_property_read_bool(child, "silabs,pll-master");
+	}
+
+	client->dev.platform_data = pdata;
+
+	return 0;
+}
+#else
+static int si5351_dt_parse(struct i2c_client *client)
+{
+	return 0;
+}
+#endif /* CONFIG_OF */
+
+static int si5351_i2c_probe(struct i2c_client *client,
+			    const struct i2c_device_id *id)
+{
+	struct si5351_platform_data *pdata;
+	struct si5351_driver_data *drvdata;
+	struct clk_init_data init;
+	struct clk *clk;
+	const char *parent_names[4];
+	u8 num_parents, num_clocks;
+	int ret, n;
+
+	ret = si5351_dt_parse(client);
+	if (ret)
+		return ret;
+
+	pdata = client->dev.platform_data;
+	if (!pdata)
+		return -EINVAL;
+
+	drvdata = devm_kzalloc(&client->dev, sizeof(*drvdata), GFP_KERNEL);
+	if (drvdata == NULL) {
+		dev_err(&client->dev, "unable to allocate driver data\n");
+		return -ENOMEM;
+	}
+
+	i2c_set_clientdata(client, drvdata);
+	drvdata->client = client;
+	drvdata->variant = pdata->variant;
+	drvdata->pxtal = pdata->clk_xtal;
+	drvdata->pclkin = pdata->clk_clkin;
+
+	drvdata->regmap = devm_regmap_init_i2c(client, &si5351_regmap_config);
+	if (IS_ERR(drvdata->regmap)) {
+		dev_err(&client->dev, "failed to allocate register map\n");
+		return PTR_ERR(drvdata->regmap);
+	}
+
+	/* Disable interrupts */
+	si5351_reg_write(drvdata, SI5351_INTERRUPT_MASK, 0xf0);
+	/* Set disabled output drivers to drive low */
+	si5351_reg_write(drvdata, SI5351_CLK3_0_DISABLE_STATE, 0x00);
+	si5351_reg_write(drvdata, SI5351_CLK7_4_DISABLE_STATE, 0x00);
+	/* Ensure pll select is on XTAL for Si5351A/B */
+	if (drvdata->variant != SI5351_VARIANT_C)
+		si5351_set_bits(drvdata, SI5351_PLL_INPUT_SOURCE,
+				SI5351_PLLA_SOURCE | SI5351_PLLB_SOURCE, 0);
+
+	/* setup clock configuration */
+	for (n = 0; n < 2; n++)
+		_si5351_pll_reparent(drvdata, n, pdata->pll_src[n]);
+
+	for (n = 0; n < 8; n++) {
+		_si5351_msynth_reparent(drvdata, n,
+					pdata->clkout[n].multisynth_src);
+		_si5351_clkout_reparent(drvdata, n,
+					pdata->clkout[n].clkout_src);
+		_si5351_clkout_set_drive_strength(drvdata, n,
+					pdata->clkout[n].drive);
+	}
+
+	/* register xtal input clock gate */
+	memset(&init, 0, sizeof(init));
+	init.name = si5351_input_names[0];
+	init.ops = &si5351_xtal_ops;
+	init.flags = 0;
+	if (!IS_ERR(drvdata->pxtal)) {
+		drvdata->pxtal_name = __clk_get_name(drvdata->pxtal);
+		init.parent_names = &drvdata->pxtal_name;
+		init.num_parents = 1;
+	}
+	drvdata->xtal.init = &init;
+	clk = devm_clk_register(&client->dev, &drvdata->xtal);
+	if (IS_ERR(clk)) {
+		dev_err(&client->dev, "unable to register %s\n", init.name);
+		return PTR_ERR(clk);
+	}
+
+	/* register clkin input clock gate */
+	if (drvdata->variant == SI5351_VARIANT_C) {
+		memset(&init, 0, sizeof(init));
+		init.name = si5351_input_names[1];
+		init.ops = &si5351_clkin_ops;
+		if (!IS_ERR(drvdata->pclkin)) {
+			drvdata->pclkin_name = __clk_get_name(drvdata->pclkin);
+			init.parent_names = &drvdata->pclkin_name;
+			init.num_parents = 1;
+		}
+		drvdata->clkin.init = &init;
+		clk = devm_clk_register(&client->dev, &drvdata->clkin);
+		if (IS_ERR(clk)) {
+			dev_err(&client->dev, "unable to register %s\n",
+				init.name);
+			return PTR_ERR(clk);
+		}
+	}
+
+	/* Si5351C allows to mux either xtal or clkin to PLL input */
+	num_parents = (drvdata->variant == SI5351_VARIANT_C) ? 2 : 1;
+	parent_names[0] = si5351_input_names[0];
+	parent_names[1] = si5351_input_names[1];
+
+	/* register PLLA */
+	drvdata->pll[0].num = 0;
+	drvdata->pll[0].drvdata = drvdata;
+	drvdata->pll[0].hw.init = &init;
+	memset(&init, 0, sizeof(init));
+	init.name = si5351_pll_names[0];
+	init.ops = &si5351_pll_ops;
+	init.flags = 0;
+	init.parent_names = parent_names;
+	init.num_parents = num_parents;
+	clk = devm_clk_register(&client->dev, &drvdata->pll[0].hw);
+	if (IS_ERR(clk)) {
+		dev_err(&client->dev, "unable to register %s\n", init.name);
+		return -EINVAL;
+	}
+
+	/* register PLLB or VXCO (Si5351B) */
+	drvdata->pll[1].num = 1;
+	drvdata->pll[1].drvdata = drvdata;
+	drvdata->pll[1].hw.init = &init;
+	memset(&init, 0, sizeof(init));
+	if (drvdata->variant == SI5351_VARIANT_B) {
+		init.name = si5351_pll_names[2];
+		init.ops = &si5351_vxco_ops;
+		init.flags = CLK_IS_ROOT;
+		init.parent_names = NULL;
+		init.num_parents = 0;
+	} else {
+		init.name = si5351_pll_names[1];
+		init.ops = &si5351_pll_ops;
+		init.flags = 0;
+		init.parent_names = parent_names;
+		init.num_parents = num_parents;
+	}
+	clk = devm_clk_register(&client->dev, &drvdata->pll[1].hw);
+	if (IS_ERR(clk)) {
+		dev_err(&client->dev, "unable to register %s\n", init.name);
+		return -EINVAL;
+	}
+
+	/* register clk multisync and clk out divider */
+	num_clocks = (drvdata->variant == SI5351_VARIANT_A3) ? 3 : 8;
+	parent_names[0] = si5351_pll_names[0];
+	if (drvdata->variant == SI5351_VARIANT_B)
+		parent_names[1] = si5351_pll_names[2];
+	else
+		parent_names[1] = si5351_pll_names[1];
+
+	drvdata->msynth = devm_kzalloc(&client->dev, num_clocks *
+				       sizeof(*drvdata->msynth), GFP_KERNEL);
+	drvdata->clkout = devm_kzalloc(&client->dev, num_clocks *
+				       sizeof(*drvdata->clkout), GFP_KERNEL);
+
+	drvdata->onecell.clk_num = num_clocks;
+	drvdata->onecell.clks = devm_kzalloc(&client->dev,
+		num_clocks * sizeof(*drvdata->onecell.clks), GFP_KERNEL);
+
+	if (WARN_ON(!drvdata->msynth || !drvdata->clkout ||
+		    !drvdata->onecell.clks))
+		return -ENOMEM;
+
+	for (n = 0; n < num_clocks; n++) {
+		drvdata->msynth[n].num = n;
+		drvdata->msynth[n].drvdata = drvdata;
+		drvdata->msynth[n].hw.init = &init;
+		memset(&init, 0, sizeof(init));
+		init.name = si5351_msynth_names[n];
+		init.ops = &si5351_msynth_ops;
+		init.flags = 0;
+		if (pdata->clkout[n].pll_master)
+			init.flags |= CLK_SET_RATE_PARENT;
+		init.parent_names = parent_names;
+		init.num_parents = 2;
+		clk = devm_clk_register(&client->dev, &drvdata->msynth[n].hw);
+		if (IS_ERR(clk)) {
+			dev_err(&client->dev, "unable to register %s\n",
+				init.name);
+			return -EINVAL;
+		}
+	}
+
+	num_parents = (drvdata->variant == SI5351_VARIANT_C) ? 4 : 3;
+	parent_names[2] = si5351_input_names[0];
+	parent_names[3] = si5351_input_names[1];
+	for (n = 0; n < num_clocks; n++) {
+		parent_names[0] = si5351_msynth_names[n];
+		parent_names[1] = (n < 4) ? si5351_msynth_names[0] :
+			si5351_msynth_names[4];
+
+		drvdata->clkout[n].num = n;
+		drvdata->clkout[n].drvdata = drvdata;
+		drvdata->clkout[n].hw.init = &init;
+		memset(&init, 0, sizeof(init));
+		init.name = si5351_clkout_names[n];
+		init.ops = &si5351_clkout_ops;
+		init.flags = 0;
+		if (pdata->clkout[n].clkout_src == SI5351_CLKOUT_SRC_MSYNTH_N)
+			init.flags |= CLK_SET_RATE_PARENT;
+		init.parent_names = parent_names;
+		init.num_parents = num_parents;
+		clk = devm_clk_register(&client->dev, &drvdata->clkout[n].hw);
+		if (IS_ERR(clk)) {
+			dev_err(&client->dev, "unable to register %s\n",
+				init.name);
+			return -EINVAL;
+		}
+		drvdata->onecell.clks[n] = clk;
+	}
+
+	ret = of_clk_add_provider(client->dev.of_node, of_clk_src_onecell_get,
+				  &drvdata->onecell);
+	if (ret) {
+		dev_err(&client->dev, "unable to add clk provider\n");
+		return ret;
+	}
+
+	return 0;
+}
+
+static const struct i2c_device_id si5351_i2c_ids[] = {
+	{ "silabs,si5351", 0 },
+	{ }
+};
+MODULE_DEVICE_TABLE(i2c, si5351_i2c_ids);
+
+static struct i2c_driver si5351_driver = {
+	.driver = {
+		.name = "si5351",
+		.of_match_table = of_match_ptr(si5351_dt_ids),
+	},
+	.probe = si5351_i2c_probe,
+	.id_table = si5351_i2c_ids,
+};
+module_i2c_driver(si5351_driver);
+
+MODULE_AUTHOR("Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com");
+MODULE_DESCRIPTION("Silicon Labs Si5351A/B/C clock generator driver");
+MODULE_LICENSE("GPL");
diff --git a/drivers/clk/clk-si5351.h b/drivers/clk/clk-si5351.h
new file mode 100644
index 0000000..af41b50
--- /dev/null
+++ b/drivers/clk/clk-si5351.h
@@ -0,0 +1,155 @@
+/*
+ * clk-si5351.h: Silicon Laboratories Si5351A/B/C I2C Clock Generator
+ *
+ * Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
+ * Rabeeh Khoury <rabeeh at solid-run.com>
+ *
+ * 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.
+ */
+
+#ifndef _CLK_SI5351_H_
+#define _CLK_SI5351_H_
+
+#define SI5351_BUS_BASE_ADDR			0x60
+
+#define SI5351_PLL_VCO_MIN			600000000
+#define SI5351_PLL_VCO_MAX			900000000
+#define SI5351_MULTISYNTH_MIN_FREQ		1000000
+#define SI5351_MULTISYNTH_DIVBY4_FREQ		150000000
+#define SI5351_MULTISYNTH_MAX_FREQ		160000000
+#define SI5351_MULTISYNTH67_MAX_FREQ		SI5351_MULTISYNTH_DIVBY4_FREQ
+#define SI5351_CLKOUT_MIN_FREQ			8000
+#define SI5351_CLKOUT_MAX_FREQ			SI5351_MULTISYNTH_MAX_FREQ
+#define SI5351_CLKOUT67_MAX_FREQ		SI5351_MULTISYNTH67_MAX_FREQ
+
+#define SI5351_PLL_A_MIN			15
+#define SI5351_PLL_A_MAX			90
+#define SI5351_PLL_B_MAX			(SI5351_PLL_C_MAX-1)
+#define SI5351_PLL_C_MAX			1048575
+#define SI5351_MULTISYNTH_A_MIN			6
+#define SI5351_MULTISYNTH_A_MAX			1800
+#define SI5351_MULTISYNTH67_A_MAX		254
+#define SI5351_MULTISYNTH_B_MAX			(SI5351_MULTISYNTH_C_MAX-1)
+#define SI5351_MULTISYNTH_C_MAX			1048575
+#define SI5351_MULTISYNTH_P1_MAX		((1<<18)-1)
+#define SI5351_MULTISYNTH_P2_MAX		((1<<20)-1)
+#define SI5351_MULTISYNTH_P3_MAX		((1<<20)-1)
+
+#define SI5351_DEVICE_STATUS			0
+#define SI5351_INTERRUPT_STATUS			1
+#define SI5351_INTERRUPT_MASK			2
+#define  SI5351_STATUS_SYS_INIT			(1<<7)
+#define  SI5351_STATUS_LOL_B			(1<<6)
+#define  SI5351_STATUS_LOL_A			(1<<5)
+#define  SI5351_STATUS_LOS			(1<<4)
+#define SI5351_OUTPUT_ENABLE_CTRL		3
+#define SI5351_OEB_PIN_ENABLE_CTRL		9
+#define SI5351_PLL_INPUT_SOURCE			15
+#define  SI5351_CLKIN_DIV_MASK			(3<<6)
+#define  SI5351_CLKIN_DIV_1			(0<<6)
+#define  SI5351_CLKIN_DIV_2			(1<<6)
+#define  SI5351_CLKIN_DIV_4			(2<<6)
+#define  SI5351_CLKIN_DIV_8			(3<<6)
+#define  SI5351_PLLB_SOURCE			(1<<3)
+#define  SI5351_PLLA_SOURCE			(1<<2)
+
+#define SI5351_CLK0_CTRL			16
+#define SI5351_CLK1_CTRL			17
+#define SI5351_CLK2_CTRL			18
+#define SI5351_CLK3_CTRL			19
+#define SI5351_CLK4_CTRL			20
+#define SI5351_CLK5_CTRL			21
+#define SI5351_CLK6_CTRL			22
+#define SI5351_CLK7_CTRL			23
+#define  SI5351_CLK_POWERDOWN			(1<<7)
+#define  SI5351_CLK_INTEGER_MODE		(1<<6)
+#define  SI5351_CLK_PLL_SELECT			(1<<5)
+#define  SI5351_CLK_INVERT			(1<<4)
+#define  SI5351_CLK_INPUT_MASK			(3<<2)
+#define  SI5351_CLK_INPUT_XTAL			(0<<2)
+#define  SI5351_CLK_INPUT_CLKIN			(1<<2)
+#define  SI5351_CLK_INPUT_MULTISYNTH_0_4	(2<<2)
+#define  SI5351_CLK_INPUT_MULTISYNTH_N		(3<<2)
+#define  SI5351_CLK_DRIVE_STRENGTH_MASK		(3<<0)
+#define  SI5351_CLK_DRIVE_STRENGTH_2MA		(0<<0)
+#define  SI5351_CLK_DRIVE_STRENGTH_4MA		(1<<0)
+#define  SI5351_CLK_DRIVE_STRENGTH_6MA		(2<<0)
+#define  SI5351_CLK_DRIVE_STRENGTH_8MA		(3<<0)
+
+#define SI5351_CLK3_0_DISABLE_STATE		24
+#define SI5351_CLK7_4_DISABLE_STATE		25
+#define  SI5351_CLK_DISABLE_STATE_LOW		0
+#define  SI5351_CLK_DISABLE_STATE_HIGH		1
+#define  SI5351_CLK_DISABLE_STATE_FLOAT		2
+#define  SI5351_CLK_DISABLE_STATE_NEVER		3
+
+#define SI5351_PARAMETERS_LENGTH		8
+#define SI5351_PLLA_PARAMETERS			26
+#define SI5351_PLLB_PARAMETERS			34
+#define SI5351_CLK0_PARAMETERS			42
+#define SI5351_CLK1_PARAMETERS			50
+#define SI5351_CLK2_PARAMETERS			58
+#define SI5351_CLK3_PARAMETERS			66
+#define SI5351_CLK4_PARAMETERS			74
+#define SI5351_CLK5_PARAMETERS			82
+#define SI5351_CLK6_PARAMETERS			90
+#define SI5351_CLK7_PARAMETERS			91
+#define SI5351_CLK6_7_OUTPUT_DIVIDER		92
+#define  SI5351_OUTPUT_CLK_DIV_MASK		(7 << 4)
+#define  SI5351_OUTPUT_CLK6_DIV_MASK		(7 << 0)
+#define  SI5351_OUTPUT_CLK_DIV_SHIFT		4
+#define  SI5351_OUTPUT_CLK_DIV6_SHIFT		0
+#define  SI5351_OUTPUT_CLK_DIV_1		0
+#define  SI5351_OUTPUT_CLK_DIV_2		1
+#define  SI5351_OUTPUT_CLK_DIV_4		2
+#define  SI5351_OUTPUT_CLK_DIV_8		3
+#define  SI5351_OUTPUT_CLK_DIV_16		4
+#define  SI5351_OUTPUT_CLK_DIV_32		5
+#define  SI5351_OUTPUT_CLK_DIV_64		6
+#define  SI5351_OUTPUT_CLK_DIV_128		7
+#define  SI5351_OUTPUT_CLK_DIVBY4		(3<<2)
+
+#define SI5351_SSC_PARAM0			149
+#define SI5351_SSC_PARAM1			150
+#define SI5351_SSC_PARAM2			151
+#define SI5351_SSC_PARAM3			152
+#define SI5351_SSC_PARAM4			153
+#define SI5351_SSC_PARAM5			154
+#define SI5351_SSC_PARAM6			155
+#define SI5351_SSC_PARAM7			156
+#define SI5351_SSC_PARAM8			157
+#define SI5351_SSC_PARAM9			158
+#define SI5351_SSC_PARAM10			159
+#define SI5351_SSC_PARAM11			160
+#define SI5351_SSC_PARAM12			161
+
+#define SI5351_VXCO_PARAMETERS_LOW		162
+#define SI5351_VXCO_PARAMETERS_MID		163
+#define SI5351_VXCO_PARAMETERS_HIGH		164
+
+#define SI5351_CLK0_PHASE_OFFSET		165
+#define SI5351_CLK1_PHASE_OFFSET		166
+#define SI5351_CLK2_PHASE_OFFSET		167
+#define SI5351_CLK3_PHASE_OFFSET		168
+#define SI5351_CLK4_PHASE_OFFSET		169
+#define SI5351_CLK5_PHASE_OFFSET		170
+
+#define SI5351_PLL_RESET			177
+#define  SI5351_PLL_RESET_B			(1<<7)
+#define  SI5351_PLL_RESET_A			(1<<5)
+
+#define SI5351_CRYSTAL_LOAD			183
+#define  SI5351_CRYSTAL_LOAD_MASK		(3<<6)
+#define  SI5351_CRYSTAL_LOAD_6PF		(1<<6)
+#define  SI5351_CRYSTAL_LOAD_8PF		(2<<6)
+#define  SI5351_CRYSTAL_LOAD_10PF		(3<<6)
+
+#define SI5351_FANOUT_ENABLE			187
+#define  SI5351_CLKIN_ENABLE			(1<<7)
+#define  SI5351_XTAL_ENABLE			(1<<6)
+#define  SI5351_MULTISYNTH_ENABLE		(1<<4)
+
+#endif
diff --git a/include/linux/platform_data/si5351.h b/include/linux/platform_data/si5351.h
new file mode 100644
index 0000000..f62218e
--- /dev/null
+++ b/include/linux/platform_data/si5351.h
@@ -0,0 +1,114 @@
+/*
+ * Si5351A/B/C programmable clock generator platform_data.
+ */
+
+#ifndef __LINUX_PLATFORM_DATA_SI5351_H__
+#define __LINUX_PLATFORM_DATA_SI5351_H__
+
+struct clk;
+
+/**
+ * enum si5351_variant - SiLabs Si5351 chip variant
+ * @SI5351_VARIANT_A: Si5351A (8 output clocks, XTAL input)
+ * @SI5351_VARIANT_A3: Si5351A MSOP10 (3 output clocks, XTAL input)
+ * @SI5351_VARIANT_B: Si5351B (8 output clocks, XTAL/VXCO input)
+ * @SI5351_VARIANT_C: Si5351C (8 output clocks, XTAL/CLKIN input)
+ */
+enum si5351_variant {
+	SI5351_VARIANT_A = 1,
+	SI5351_VARIANT_A3 = 2,
+	SI5351_VARIANT_B = 3,
+	SI5351_VARIANT_C = 4,
+};
+
+/**
+ * enum si5351_pll_src - Si5351 pll clock source
+ * @SI5351_PLL_SRC_DEFAULT: default, do not change eeprom config
+ * @SI5351_PLL_SRC_XTAL: pll source clock is XTAL input
+ * @SI5351_PLL_SRC_CLKIN: pll source clock is CLKIN input
+ */
+enum si5351_pll_src {
+	SI5351_PLL_SRC_DEFAULT = 0,
+	SI5351_PLL_SRC_XTAL = 1,
+	SI5351_PLL_SRC_CLKIN = 2,
+};
+
+/**
+ * enum si5351_multisynth_src - Si5351 multisynth clock source
+ * @SI5351_MULTISYNTH_SRC_DEFAULT: default, do not change eeprom config
+ * @SI5351_MULTISYNTH_SRC_VCO0: multisynth source clock is VCO0
+ * @SI5351_MULTISYNTH_SRC_VCO1: multisynth source clock is VCO1
+ */
+enum si5351_multisynth_src {
+	SI5351_MULTISYNTH_SRC_DEFAULT = 0,
+	SI5351_MULTISYNTH_SRC_VCO0 = 1,
+	SI5351_MULTISYNTH_SRC_VCO1 = 2,
+};
+
+/**
+ * enum si5351_clkout_src - Si5351 clock output clock source
+ * @SI5351_CLKOUT_SRC_DEFAULT: default, do not change eeprom config
+ * @SI5351_CLKOUT_SRC_MSYNTH_N: clkout N source clock is multisynth N
+ * @SI5351_CLKOUT_SRC_MSYNTH_0_4: clkout N source clock is multisynth 0 (N<4)
+ *                                or 4 (N>=4)
+ * @SI5351_CLKOUT_SRC_XTAL: clkout N source clock is XTAL
+ * @SI5351_CLKOUT_SRC_CLKIN: clkout N source clock is CLKIN
+ */
+enum si5351_clkout_src {
+	SI5351_CLKOUT_SRC_DEFAULT = 0,
+	SI5351_CLKOUT_SRC_MSYNTH_N = 1,
+	SI5351_CLKOUT_SRC_MSYNTH_0_4 = 2,
+	SI5351_CLKOUT_SRC_XTAL = 3,
+	SI5351_CLKOUT_SRC_CLKIN = 4,
+};
+
+/**
+ * enum si5351_drive_strength - Si5351 clock output drive strength
+ * @SI5351_DRIVE_DEFAULT: default, do not change eeprom config
+ * @SI5351_DRIVE_2MA: 2mA clock output drive strength
+ * @SI5351_DRIVE_4MA: 4mA clock output drive strength
+ * @SI5351_DRIVE_6MA: 6mA clock output drive strength
+ * @SI5351_DRIVE_8MA: 8mA clock output drive strength
+ */
+enum si5351_drive_strength {
+	SI5351_DRIVE_DEFAULT = 0,
+	SI5351_DRIVE_2MA = 2,
+	SI5351_DRIVE_4MA = 4,
+	SI5351_DRIVE_6MA = 6,
+	SI5351_DRIVE_8MA = 8,
+};
+
+/**
+ * struct si5351_clkout_config - Si5351 clock output configuration
+ * @clkout: clkout number
+ * @multisynth_src: multisynth source clock
+ * @clkout_src: clkout source clock
+ * @pll_master: if true, clkout can also change pll rate
+ * @drive: output drive strength
+ * @rate: initial clkout rate, or default if 0
+ */
+struct si5351_clkout_config {
+	enum si5351_multisynth_src multisynth_src;
+	enum si5351_clkout_src clkout_src;
+	enum si5351_drive_strength drive;
+	bool pll_master;
+	unsigned long rate;
+};
+
+/**
+ * struct si5351_platform_data - Platform data for the Si5351 clock driver
+ * @variant: Si5351 chip variant
+ * @clk_xtal: xtal input clock
+ * @clk_clkin: clkin input clock
+ * @pll_src: array of pll source clock setting
+ * @clkout: array of clkout configuration
+ */
+struct si5351_platform_data {
+	enum si5351_variant variant;
+	struct clk *clk_xtal;
+	struct clk *clk_clkin;
+	enum si5351_pll_src pll_src[2];
+	struct si5351_clkout_config clkout[8];
+};
+
+#endif
-- 
1.7.10.4



From stern at rowland.harvard.edu  Mon Apr  8 12:48:33 2013
From: stern at rowland.harvard.edu (Alan Stern)
Date: Mon, 8 Apr 2013 12:48:33 -0400 (EDT)
Subject: [PATCH V5 0/6] USB: EHCI multiplatform for 3.10
In-Reply-To: <20130408164209.GA13694@kroah.com>
Message-ID: <Pine.LNX.4.44L0.1304081247350.1529-100000@iolanthe.rowland.org>

On Mon, 8 Apr 2013, Greg KH wrote:

> On Tue, Apr 02, 2013 at 06:23:58PM +0200, Arnd Bergmann wrote:
> > Hi Greg,
> > 
> > Here are the EHCI patches that I think are good for inclusion in 3.10,
> > I hope you are willing to include them after the debacle over these
> > patches in 3.9.
> > 
> > The patches are all logically independent but sorted by priority,
> > so decide for yourself how many you want to take, starting at the
> > first one. The first six patches all have an Ack from Alan Stern
> > and from the respective ARM platform maintainers.
> 
> I don't see an ACK for the 6th patch from Alan, any reason for that?

The last patch was different from all the others.  It changed ohci-hcd, 
not ehci-hcd.  I haven't had time yet to go through it in detail; lots 
of other things on my plate.

Alan Stern



From dianders at chromium.org  Mon Apr  8 12:51:19 2013
From: dianders at chromium.org (Doug Anderson)
Date: Mon,  8 Apr 2013 09:51:19 -0700
Subject: [PATCH] ARM: dts: fix bad merge of display timing node to
 exynos5250-smdk5250.dts
Message-ID: <1365439879-3398-1-git-send-email-dianders@chromium.org>

The display timing node was added:
  7ed2077 ARM: dts: Add display timing node to exynos5250-smdk5250.dts
...and looks OK there.  ...but it looks like we lost a "};" in the
merge and it no longer compiles.  Fix it.

Signed-off-by: Doug Anderson <dianders at chromium.org>
---
 arch/arm/boot/dts/exynos5250-smdk5250.dts | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index 4be14df..26d856b 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -239,6 +239,7 @@
 			vback-porch = <4>;
 			vfront-porch = <4>;
 			vsync-len = <4>;
+		};
 	};
 
 	fixed-rate-clocks {
-- 
1.8.1.3



From tomasz.figa at gmail.com  Mon Apr  8 12:53:13 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Mon, 08 Apr 2013 18:53:13 +0200
Subject: [PATCH v4 04/14] mfd: Add Samsung PWM/timer master driver
In-Reply-To: <2359597.ofbj7Kvioz@flatron>
References: <1365093431-30621-1-git-send-email-t.figa@samsung.com>
 <201304052154.21361.arnd@arndb.de> <2359597.ofbj7Kvioz@flatron>
Message-ID: <5357756.gKmBOZlWcd@flatron>

On Saturday 06 of April 2013 00:24:18 Tomasz Figa wrote:
> On Friday 05 of April 2013 21:54:21 Arnd Bergmann wrote:
> > On Friday 05 April 2013, Tomasz Figa wrote:
> > > > I don't think anyone ever suggested using a private API though.
> > > 
> > > I must have gotten the last paragraph of
> > > http://article.gmane.org/gmane.linux.kernel.samsung-soc/16638
> > > wrong then. For me it seemed like the timer driver would expose a
> > > private API to the PWM driver.
> > 
> > Yes, sorry I wasn't clear enough. I meant a register-level interface
> > exposed from the base driver, not a high-level interface like you
> > did.
> 
> I'm not sure what you mean by a register-level interface. Something like
> samsung_pwm_update_reg(reg, mask, val), which modifies bitfields
> according to the mask and value with appropriate synchronization? If
> yes, this solves only the problem of access to shared registers.
> 
> The other problems that remain:
> 
> - negotiation of PWM channels to use for clock source and clock events,
>   because each board can use different channels for PWM outputs,
> 
> - code duplication caused by both of the drivers doing mostly the same
>   things and or having to parse the same data from device tree,
> 
> - both non-DT and DT platforms must be supported,
> 
> - how to keep the ability to load PWM driver as a module (or not load it
> at all when PWM is not used on particular board), while retaining
> everything that is needed for the clocksource driver in kernel,
> 
> - some platforms can't use PWM timers as system clocksources, while on
>   others this is the only timekeeping hardware available.
> 

Hmm. Does anybody have an idea of a better way of implementing this PWM 
timer support, which solves the above problems?

This series is a dependency for moving Universal C210 board to DT-based 
description and it's already almost out of time to get this included for 
3.10...

Best regards,
Tomasz

> > > > I think
> > > > it's ok if the driver lives in drivers/mfd when it doesn't fit
> > > > anywhere
> > > > else easily, but you should really register it to the pwm
> > > > subsystem
> > > > to
> > > > expose that functionality, not export functions that can be used
> > > > by
> > > > a pwm shim driver, which even seems to be missing from the series.
> > > 
> > > Anyway, using PWM API in a clocksource driver that needs to be
> > > running
> > > very early (before any initcalls get called) seems a bit weird for
> > > me, especially when PWM API doesn't provide such fine grained
> > > control
> > > over PWM timers that is required in the clocksource drivers.
> > 
> > Exactly, that's why you should have a regular PWM driver that gets
> > loaded at a convenient time and just uses an interface exported by the
> > base driver to access the common registers.
> 
> Well, this is basically what my patches do, except that the PWM driver
> isn't reworked to use the base driver yet.
> 
> The private API exported to the samsung-time and pwm-samsung drivers
> isn't maybe the most fortunate one, but it clearly has the advantage of
> solving all the problems I mentioned before.
> 
> Same goes for calling this an MFD driver. It doesn't even use the MFD
> core, but there seems to be no better place to put it. Maybe
> drivers/platform/arm would be better, if it existed, just as currently
> available drivers/platform/x86?
> 
> Best regards,
> Tomasz


From jgunthorpe at obsidianresearch.com  Mon Apr  8 12:56:26 2013
From: jgunthorpe at obsidianresearch.com (Jason Gunthorpe)
Date: Mon, 8 Apr 2013 10:56:26 -0600
Subject: [PATCH 6/6] ARM: dts: Add pcie controller node for Samsung
 EXYNOS5440 SoC
In-Reply-To: <000001ce3438$b136e1e0$13a4a5a0$%han@samsung.com>
References: <00c001ce277b$92b26ab0$b8174010$%han@samsung.com>
 <00c501ce277c$30e49dc0$92add940$%han@samsung.com>
 <000001ce3438$b136e1e0$13a4a5a0$%han@samsung.com>
Message-ID: <20130408165626.GA30824@obsidianresearch.com>

On Mon, Apr 08, 2013 at 06:08:53PM +0900, Jingoo Han wrote:

> I have a question.  Now, I am reviewing the Tegra PCIe, Marvell PCIe
> patchset.  However, in the case of Exynos PCIe, 'downstream I/O' and
> 'non-prefetchable memory' are different between PCIe0 and PCIe1.
> These regions are not shared.
> 
> PCIe0:
> 	ranges = <0x00000800 0 0x40000000 0x40000000 0 0x00200000   /* configuration space */
> 		  0x81000000 0 0	  0x40200000 0 0x00004000   /* downstream I/O */
> 		  0x82000000 0 0	  0x40204000 0 0x10000000>; /* non-prefetchable memory */
> 
> PCIe1:
> 	ranges = <0x00000800 0 0x40000000 0x40000000 0 0x00200000   /* configuration space */
> 		  0x81000000 0 0	  0x40200000 0 0x00004000   /* downstream I/O */
> 		  0x82000000 0 0	  0x40204000 0 0x10000000>; /* non-prefetchable memory */
> 
> PCIe0 uses 0x40000000~0x5fffffff, PCI1 uses 0x60000000~0x7fffffff.
> 
> How can I handle this? :)

You need to dig into where this range restriction comes from, and how
it interacts with the PCI-E root bridge's window registers. Is there
another set of registers that control this? Is it hardwired into the
silicon? Do the root port window registers control this? 

I'm looking at functions like exynos_pcie_prog_viewport_mem_outbound
and wondering if the driver already controls this window.. But it
looks like there may be some restrictions.

Marvell also has unshared regions, but the driver arranges for those
ranges to be setup dynamically based on writes to the bridge's window
registers from the Linux PCI core, so the region is always in sync
with what the Linux PCI core is trying to do.

The desired perfect outcome is to have a single logical 'shared'
region for memory and I/O - give that region to the PCI core via
struct resources, then the PCI core tells the driver and HW what
portion of that region belongs to each root port via a write to the
root port bridge's window registers. The net result is still
non-overlapping regions, but the allocation of space between port 0
and port 1 is performed at run time.

I don't really know enough about your hardware to give you better
advice, sorry. The general guidance to try and follow the PCI-E spec
for a root complex is good, but if the HW can't do it, or it would
make the driver too complex, then one PCI domain per port will always
work (this is similar to your original driver, but with domains).

The main advantage to following the PCI-E specs and allowing for
dynamic allocation of address space is that it lets you reserve less
address space for PCI-E, and this in turn gives you more low mem
address space to use for DRAM.

> The following is right?
 
> +       pcie-controller {
> 		.....
> +               ranges = <0x82000000 0 0x40000000 0x40000000 0 0x00200000   /* port 0 registers */
> +                         0x82000000 0 0x60000000 0x60000000 0 0x00200000   /* port 1 registers */
> +                         0x81000000 0 0          0x40200000 0 0x00004000   /* port 0 downstream I/O */
> +                         0x81000000 0 0          0x60200000 0 0x00004000   /* port 1 downstream I/O */
> +                         0x82000000 0 0x40204000 0x40204000 0 0x10000000>; /* port 0 non-prefetchable memory */
> +                         0x82000000 0 0x40204000 0x60204000 0 0x10000000>; /* port 1 non-prefetchable memory */


> +
> +               pci at 1,0 {
> +                       device_type = "pci";
> +                       assigned-addresses = <0x82000800 0 0x40000000 0 0x00200000
> +                                                 0x81000800 0 0x40200000 0 0x00004000
> +                                                 0x81000800 0 0x40204000 0 0x10000000>;

Would be:

                       ranges = <0x81000800 0 0x40200000  0x81000800 0 0x40200000  0 0x00004000
                                 0x81000800 0 0x40204000  0x81000800 0 0x40204000  0 0x10000000>;
                       assigned-addresses = <0x82000800 0 0x40000000  0 0x00200000>;

Jason


From dianders at chromium.org  Mon Apr  8 12:58:15 2013
From: dianders at chromium.org (Doug Anderson)
Date: Mon,  8 Apr 2013 09:58:15 -0700
Subject: [PATCH] ARM: dts: Disable the RTC by default on exynos5
Message-ID: <1365440295-4460-1-git-send-email-dianders@chromium.org>

This change makes the rtc on the exynos5250 and 5440 disabled by
default to match exynos4.

Ever since the common clock framework came in came in, exynos5250
boards have dumped lots of warnings in the boot log.  It turns out
that we don't see those on exynos4 since the rtc is disabled by
default.  While we need to get to the bottom of the problems with the
RTC, it still makes sense to have the default state of the RTC on
exynos boards match.

For the record, warnings look like this:
  ------------[ cut here ]------------
  WARNING: at /.../drivers/clk/clk.c:771 __clk_enable+0x34/0xb0()
  Modules linked in:
  [<80015bfc>] (unwind_backtrace+0x0/0xec) from [<804717f0>] (dump_stack+0x20/0x24)
  [<804717f0>] (dump_stack+0x20/0x24) from [<80023cd0>] (warn_slowpath_common+0x5c/0x7c)
  [<80023cd0>] (warn_slowpath_common+0x5c/0x7c) from [<80023d1c>] (warn_slowpath_null+0x2c/0x34)
  [<80023d1c>] (warn_slowpath_null+0x2c/0x34) from [<8035ddb0>] (__clk_enable+0x34/0xb0)
  [<8035ddb0>] (__clk_enable+0x34/0xb0) from [<8035de54>] (clk_enable+0x28/0x3c)
  [<8035de54>] (clk_enable+0x28/0x3c) from [<8031a160>] (s3c_rtc_probe+0xf4/0x434)
  [<8031a160>] (s3c_rtc_probe+0xf4/0x434) from [<8028e288>] (platform_drv_probe+0x24/0x28)
  [<8028e288>] (platform_drv_probe+0x24/0x28) from [<8028ce10>] (driver_probe_device+0xbc/0x22c)
  [<8028ce10>] (driver_probe_device+0xbc/0x22c) from [<8028cff8>] (__driver_attach+0x78/0x9c)
  [<8028cff8>] (__driver_attach+0x78/0x9c) from [<8028bdfc>] (bus_for_each_dev+0x64/0xac)
  [<8028bdfc>] (bus_for_each_dev+0x64/0xac) from [<8028c7e0>] (driver_attach+0x28/0x30)
  [<8028c7e0>] (driver_attach+0x28/0x30) from [<8028c43c>] (bus_add_driver+0xe0/0x234)
  [<8028c43c>] (bus_add_driver+0xe0/0x234) from [<8028d55c>] (driver_register+0xac/0x13c)
  [<8028d55c>] (driver_register+0xac/0x13c) from [<8028e4f4>] (platform_driver_register+0x54/0x68)
  [<8028e4f4>] (platform_driver_register+0x54/0x68) from [<8065c944>] (s3c_rtc_driver_init+0x14/0x1c)
  [<8065c944>] (s3c_rtc_driver_init+0x14/0x1c) from [<800086d8>] (do_one_initcall+0x60/0x138)
  [<800086d8>] (do_one_initcall+0x60/0x138) from [<80633a8c>] (kernel_init_freeable+0x108/0x1d0)
  [<80633a8c>] (kernel_init_freeable+0x108/0x1d0) from [<8046d2f8>] (kernel_init+0x1c/0xf4)
  [<8046d2f8>] (kernel_init+0x1c/0xf4) from [<8000e358>] (ret_from_fork+0x14/0x20)
  ---[ end trace 4bcdc801c868d73f ]---

Signed-off-by: Doug Anderson <dianders at chromium.org>
---
 arch/arm/boot/dts/exynos5250.dtsi | 1 +
 arch/arm/boot/dts/exynos5440.dtsi | 1 +
 2 files changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi
index dc55e33..892b724 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -183,6 +183,7 @@
 		interrupts = <0 43 0>, <0 44 0>;
 		clocks = <&clock 337>;
 		clock-names = "rtc";
+		status = "disabled";
 	};
 
 	tmu at 10060000 {
diff --git a/arch/arm/boot/dts/exynos5440.dtsi b/arch/arm/boot/dts/exynos5440.dtsi
index 25c6134..a8ceef4 100644
--- a/arch/arm/boot/dts/exynos5440.dtsi
+++ b/arch/arm/boot/dts/exynos5440.dtsi
@@ -181,5 +181,6 @@
 		interrupts = <0 17 0>, <0 16 0>;
 		clocks = <&clock 21>;
 		clock-names = "rtc";
+		status = "disabled";
 	};
 };
-- 
1.8.1.3



From robherring2 at gmail.com  Mon Apr  8 12:58:58 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Mon, 08 Apr 2013 11:58:58 -0500
Subject: [PATCH v3] of/pci: Provide support for parsing PCI DT ranges
 property
In-Reply-To: <20130408143320.GA24277@arm.com>
References: <20130408143320.GA24277@arm.com>
Message-ID: <5162F752.4000008@gmail.com>

Adding PPC and Microblaze maintainers.

On 04/08/2013 09:33 AM, Andrew Murray wrote:
> This patch factors out common implementation patterns to reduce overall kernel
> code and provide a means for host bridge drivers to directly obtain struct
> resources from the DT's ranges property without relying on architecture specific
> DT handling. This will make it easier to write archiecture independent host bridge
> drivers and mitigate against further duplication of DT parsing code.
> 
> This patch can be used in the following way:
> 
> 	struct of_pci_range_parser parser;
> 	struct of_pci_range range;
> 
> 	if (of_pci_range_parser(&parser, np))
> 		; //no ranges property
> 
> 	for_each_of_pci_range(&parser, &range) {
> 
> 		/*
> 			directly access properties of the address range, e.g.:
> 			range.pci_space, range.pci_addr, range.cpu_addr,
> 			range.size, range.flags
> 
> 			alternatively obtain a struct resource, e.g.:
> 			struct resource res;
> 			of_pci_range_to_resource(&range, np, &res);
> 		*/
> 	}
> 
> Additionally the implementation takes care of adjacent ranges and merges them
> into a single range (as was the case with powerpc and microblaze).
> 
> The modifications to microblaze, mips and powerpc have not been tested.
> 
> Signed-off-by: Andrew Murray <Andrew.Murray at arm.com>
> Signed-off-by: Liviu Dudau <Liviu.Dudau at arm.com>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> ---
> Compared to the v3 sent by Andrew Murray, the following changes have
> been made:
> 
>  * Unify and move duplicate pci_process_bridge_OF_ranges functions to
>    drivers/of/of_pci.c as suggested by Rob Herring

This part should really be a separate patch with just the move and
should have acks from PPC and Microblaze maintainers.

Otherwise it looks okay to me.

Rob

>  * Fix potential build errors with Microblaze/MIPS
> 
> Compared to "[PATCH v5 01/17] of/pci: Provide support for parsing PCI DT
> ranges property", the following changes have been made:
> 
>  * Correct use of IORESOURCE_* as suggested by Russell King
> 
>  * Improved interface and naming as suggested by Thierry Reding
> 
> Compared to the v2 sent by Andrew Murray, Thomas Petazzoni did:
> 
>  * Add a memset() on the struct of_pci_range_iter when starting the
>    for loop in for_each_pci_range(). Otherwise, with an uninitialized
>    of_pci_range_iter, of_pci_process_ranges() may crash.
> 
>  * Add parenthesis around 'res', 'np' and 'iter' in the
>    for_each_of_pci_range macro definitions. Otherwise, passing
>    something like &foobar as 'res' didn't work.
> 
>  * Rebased on top of 3.9-rc2, which required fixing a few conflicts in
>    the Microblaze code.
> 
> v2:
>   This follows on from suggestions made by Grant Likely
>   (marc.info/?l=linux-kernel&m=136079602806328)
> ---
>  arch/microblaze/include/asm/pci-bridge.h |    5 +-
>  arch/microblaze/pci/pci-common.c         |  192 ------------------------------
>  arch/mips/pci/pci.c                      |   50 +++------
>  arch/powerpc/include/asm/pci-bridge.h    |    5 +-
>  arch/powerpc/kernel/pci-common.c         |  192 ------------------------------
>  drivers/of/address.c                     |   63 ++++++++++
>  drivers/of/of_pci.c                      |  168 ++++++++++++++++++++++++++
>  include/linux/of_address.h               |   42 +++++++
>  include/linux/of_pci.h                   |    3 +
>  9 files changed, 294 insertions(+), 426 deletions(-)
> 
> diff --git a/arch/microblaze/include/asm/pci-bridge.h b/arch/microblaze/include/asm/pci-bridge.h
> index cb5d397..5783cd6 100644
> --- a/arch/microblaze/include/asm/pci-bridge.h
> +++ b/arch/microblaze/include/asm/pci-bridge.h
> @@ -10,6 +10,7 @@
>  #include <linux/pci.h>
>  #include <linux/list.h>
>  #include <linux/ioport.h>
> +#include <linux/of_pci.h>
>  
>  struct device_node;
>  
> @@ -132,10 +133,6 @@ extern void setup_indirect_pci(struct pci_controller *hose,
>  extern struct pci_controller *pci_find_hose_for_OF_device(
>  			struct device_node *node);
>  
> -/* Fill up host controller resources from the OF node */
> -extern void pci_process_bridge_OF_ranges(struct pci_controller *hose,
> -			struct device_node *dev, int primary);
> -
>  /* Allocate & free a PCI host bridge structure */
>  extern struct pci_controller *pcibios_alloc_controller(struct device_node *dev);
>  extern void pcibios_free_controller(struct pci_controller *phb);
> diff --git a/arch/microblaze/pci/pci-common.c b/arch/microblaze/pci/pci-common.c
> index 9ea521e..2735ad9 100644
> --- a/arch/microblaze/pci/pci-common.c
> +++ b/arch/microblaze/pci/pci-common.c
> @@ -622,198 +622,6 @@ void pci_resource_to_user(const struct pci_dev *dev, int bar,
>  	*end = rsrc->end - offset;
>  }
>  
> -/**
> - * pci_process_bridge_OF_ranges - Parse PCI bridge resources from device tree
> - * @hose: newly allocated pci_controller to be setup
> - * @dev: device node of the host bridge
> - * @primary: set if primary bus (32 bits only, soon to be deprecated)
> - *
> - * This function will parse the "ranges" property of a PCI host bridge device
> - * node and setup the resource mapping of a pci controller based on its
> - * content.
> - *
> - * Life would be boring if it wasn't for a few issues that we have to deal
> - * with here:
> - *
> - *   - We can only cope with one IO space range and up to 3 Memory space
> - *     ranges. However, some machines (thanks Apple !) tend to split their
> - *     space into lots of small contiguous ranges. So we have to coalesce.
> - *
> - *   - We can only cope with all memory ranges having the same offset
> - *     between CPU addresses and PCI addresses. Unfortunately, some bridges
> - *     are setup for a large 1:1 mapping along with a small "window" which
> - *     maps PCI address 0 to some arbitrary high address of the CPU space in
> - *     order to give access to the ISA memory hole.
> - *     The way out of here that I've chosen for now is to always set the
> - *     offset based on the first resource found, then override it if we
> - *     have a different offset and the previous was set by an ISA hole.
> - *
> - *   - Some busses have IO space not starting at 0, which causes trouble with
> - *     the way we do our IO resource renumbering. The code somewhat deals with
> - *     it for 64 bits but I would expect problems on 32 bits.
> - *
> - *   - Some 32 bits platforms such as 4xx can have physical space larger than
> - *     32 bits so we need to use 64 bits values for the parsing
> - */
> -void pci_process_bridge_OF_ranges(struct pci_controller *hose,
> -				  struct device_node *dev, int primary)
> -{
> -	const u32 *ranges;
> -	int rlen;
> -	int pna = of_n_addr_cells(dev);
> -	int np = pna + 5;
> -	int memno = 0, isa_hole = -1;
> -	u32 pci_space;
> -	unsigned long long pci_addr, cpu_addr, pci_next, cpu_next, size;
> -	unsigned long long isa_mb = 0;
> -	struct resource *res;
> -
> -	pr_info("PCI host bridge %s %s ranges:\n",
> -	       dev->full_name, primary ? "(primary)" : "");
> -
> -	/* Get ranges property */
> -	ranges = of_get_property(dev, "ranges", &rlen);
> -	if (ranges == NULL)
> -		return;
> -
> -	/* Parse it */
> -	pr_debug("Parsing ranges property...\n");
> -	while ((rlen -= np * 4) >= 0) {
> -		/* Read next ranges element */
> -		pci_space = ranges[0];
> -		pci_addr = of_read_number(ranges + 1, 2);
> -		cpu_addr = of_translate_address(dev, ranges + 3);
> -		size = of_read_number(ranges + pna + 3, 2);
> -
> -		pr_debug("pci_space: 0x%08x pci_addr:0x%016llx ",
> -				pci_space, pci_addr);
> -		pr_debug("cpu_addr:0x%016llx size:0x%016llx\n",
> -					cpu_addr, size);
> -
> -		ranges += np;
> -
> -		/* If we failed translation or got a zero-sized region
> -		 * (some FW try to feed us with non sensical zero sized regions
> -		 * such as power3 which look like some kind of attempt
> -		 * at exposing the VGA memory hole)
> -		 */
> -		if (cpu_addr == OF_BAD_ADDR || size == 0)
> -			continue;
> -
> -		/* Now consume following elements while they are contiguous */
> -		for (; rlen >= np * sizeof(u32);
> -		     ranges += np, rlen -= np * 4) {
> -			if (ranges[0] != pci_space)
> -				break;
> -			pci_next = of_read_number(ranges + 1, 2);
> -			cpu_next = of_translate_address(dev, ranges + 3);
> -			if (pci_next != pci_addr + size ||
> -			    cpu_next != cpu_addr + size)
> -				break;
> -			size += of_read_number(ranges + pna + 3, 2);
> -		}
> -
> -		/* Act based on address space type */
> -		res = NULL;
> -		switch ((pci_space >> 24) & 0x3) {
> -		case 1:		/* PCI IO space */
> -			pr_info("  IO 0x%016llx..0x%016llx -> 0x%016llx\n",
> -			       cpu_addr, cpu_addr + size - 1, pci_addr);
> -
> -			/* We support only one IO range */
> -			if (hose->pci_io_size) {
> -				pr_info(" \\--> Skipped (too many) !\n");
> -				continue;
> -			}
> -			/* On 32 bits, limit I/O space to 16MB */
> -			if (size > 0x01000000)
> -				size = 0x01000000;
> -
> -			/* 32 bits needs to map IOs here */
> -			hose->io_base_virt = ioremap(cpu_addr, size);
> -
> -			/* Expect trouble if pci_addr is not 0 */
> -			if (primary)
> -				isa_io_base =
> -					(unsigned long)hose->io_base_virt;
> -			/* pci_io_size and io_base_phys always represent IO
> -			 * space starting at 0 so we factor in pci_addr
> -			 */
> -			hose->pci_io_size = pci_addr + size;
> -			hose->io_base_phys = cpu_addr - pci_addr;
> -
> -			/* Build resource */
> -			res = &hose->io_resource;
> -			res->flags = IORESOURCE_IO;
> -			res->start = pci_addr;
> -			break;
> -		case 2:		/* PCI Memory space */
> -		case 3:		/* PCI 64 bits Memory space */
> -			pr_info(" MEM 0x%016llx..0x%016llx -> 0x%016llx %s\n",
> -			       cpu_addr, cpu_addr + size - 1, pci_addr,
> -			       (pci_space & 0x40000000) ? "Prefetch" : "");
> -
> -			/* We support only 3 memory ranges */
> -			if (memno >= 3) {
> -				pr_info(" \\--> Skipped (too many) !\n");
> -				continue;
> -			}
> -			/* Handles ISA memory hole space here */
> -			if (pci_addr == 0) {
> -				isa_mb = cpu_addr;
> -				isa_hole = memno;
> -				if (primary || isa_mem_base == 0)
> -					isa_mem_base = cpu_addr;
> -				hose->isa_mem_phys = cpu_addr;
> -				hose->isa_mem_size = size;
> -			}
> -
> -			/* We get the PCI/Mem offset from the first range or
> -			 * the, current one if the offset came from an ISA
> -			 * hole. If they don't match, bugger.
> -			 */
> -			if (memno == 0 ||
> -			    (isa_hole >= 0 && pci_addr != 0 &&
> -			     hose->pci_mem_offset == isa_mb))
> -				hose->pci_mem_offset = cpu_addr - pci_addr;
> -			else if (pci_addr != 0 &&
> -				 hose->pci_mem_offset != cpu_addr - pci_addr) {
> -				pr_info(" \\--> Skipped (offset mismatch) !\n");
> -				continue;
> -			}
> -
> -			/* Build resource */
> -			res = &hose->mem_resources[memno++];
> -			res->flags = IORESOURCE_MEM;
> -			if (pci_space & 0x40000000)
> -				res->flags |= IORESOURCE_PREFETCH;
> -			res->start = cpu_addr;
> -			break;
> -		}
> -		if (res != NULL) {
> -			res->name = dev->full_name;
> -			res->end = res->start + size - 1;
> -			res->parent = NULL;
> -			res->sibling = NULL;
> -			res->child = NULL;
> -		}
> -	}
> -
> -	/* If there's an ISA hole and the pci_mem_offset is -not- matching
> -	 * the ISA hole offset, then we need to remove the ISA hole from
> -	 * the resource list for that brige
> -	 */
> -	if (isa_hole >= 0 && hose->pci_mem_offset != isa_mb) {
> -		unsigned int next = isa_hole + 1;
> -		pr_info(" Removing ISA hole at 0x%016llx\n", isa_mb);
> -		if (next < memno)
> -			memmove(&hose->mem_resources[isa_hole],
> -				&hose->mem_resources[next],
> -				sizeof(struct resource) * (memno - next));
> -		hose->mem_resources[--memno].flags = 0;
> -	}
> -}
> -
>  /* Decide whether to display the domain number in /proc */
>  int pci_proc_domain(struct pci_bus *bus)
>  {
> diff --git a/arch/mips/pci/pci.c b/arch/mips/pci/pci.c
> index 0872f12..bee49a4 100644
> --- a/arch/mips/pci/pci.c
> +++ b/arch/mips/pci/pci.c
> @@ -122,51 +122,33 @@ static void pcibios_scanbus(struct pci_controller *hose)
>  #ifdef CONFIG_OF
>  void pci_load_of_ranges(struct pci_controller *hose, struct device_node *node)
>  {
> -	const __be32 *ranges;
> -	int rlen;
> -	int pna = of_n_addr_cells(node);
> -	int np = pna + 5;
> +	struct of_pci_range_range range;
> +	struct of_pci_range_parser parser;
> +	u32 res_type;
>  
>  	pr_info("PCI host bridge %s ranges:\n", node->full_name);
> -	ranges = of_get_property(node, "ranges", &rlen);
> -	if (ranges == NULL)
> -		return;
>  	hose->of_node = node;
>  
> -	while ((rlen -= np * 4) >= 0) {
> -		u32 pci_space;
> +	if (of_pci_range_parser(&parser, node))
> +		return;
> +
> +	for_each_of_pci_range(&parser, &range) {
>  		struct resource *res = NULL;
> -		u64 addr, size;
> -
> -		pci_space = be32_to_cpup(&ranges[0]);
> -		addr = of_translate_address(node, ranges + 3);
> -		size = of_read_number(ranges + pna + 3, 2);
> -		ranges += np;
> -		switch ((pci_space >> 24) & 0x3) {
> -		case 1:		/* PCI IO space */
> +
> +		res_type = range.flags & IORESOURCE_TYPE_BITS;
> +		if (res_type == IORESOURCE_IO) {
>  			pr_info("  IO 0x%016llx..0x%016llx\n",
> -					addr, addr + size - 1);
> +				range.addr, range.addr + range.size - 1);
>  			hose->io_map_base =
> -				(unsigned long)ioremap(addr, size);
> +				(unsigned long)ioremap(range.addr, range.size);
>  			res = hose->io_resource;
> -			res->flags = IORESOURCE_IO;
> -			break;
> -		case 2:		/* PCI Memory space */
> -		case 3:		/* PCI 64 bits Memory space */
> +		} else if (res_type == IORESOURCE_MEM) {
>  			pr_info(" MEM 0x%016llx..0x%016llx\n",
> -					addr, addr + size - 1);
> +				range.addr, range.addr + range.size - 1);
>  			res = hose->mem_resource;
> -			res->flags = IORESOURCE_MEM;
> -			break;
> -		}
> -		if (res != NULL) {
> -			res->start = addr;
> -			res->name = node->full_name;
> -			res->end = res->start + size - 1;
> -			res->parent = NULL;
> -			res->sibling = NULL;
> -			res->child = NULL;
>  		}
> +		if (res != NULL)
> +			of_pci_range_to_resource(&range, node, res);
>  	}
>  }
>  #endif
> diff --git a/arch/powerpc/include/asm/pci-bridge.h b/arch/powerpc/include/asm/pci-bridge.h
> index 025a130..205bfba 100644
> --- a/arch/powerpc/include/asm/pci-bridge.h
> +++ b/arch/powerpc/include/asm/pci-bridge.h
> @@ -10,6 +10,7 @@
>  #include <linux/pci.h>
>  #include <linux/list.h>
>  #include <linux/ioport.h>
> +#include <linux/of_pci.h>
>  #include <asm-generic/pci-bridge.h>
>  
>  struct device_node;
> @@ -231,10 +232,6 @@ extern int pcibios_map_io_space(struct pci_bus *bus);
>  extern struct pci_controller *pci_find_hose_for_OF_device(
>  			struct device_node* node);
>  
> -/* Fill up host controller resources from the OF node */
> -extern void pci_process_bridge_OF_ranges(struct pci_controller *hose,
> -			struct device_node *dev, int primary);
> -
>  /* Allocate & free a PCI host bridge structure */
>  extern struct pci_controller *pcibios_alloc_controller(struct device_node *dev);
>  extern void pcibios_free_controller(struct pci_controller *phb);
> diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
> index fa12ae4..6edf396 100644
> --- a/arch/powerpc/kernel/pci-common.c
> +++ b/arch/powerpc/kernel/pci-common.c
> @@ -640,198 +640,6 @@ void pci_resource_to_user(const struct pci_dev *dev, int bar,
>  	*end = rsrc->end - offset;
>  }
>  
> -/**
> - * pci_process_bridge_OF_ranges - Parse PCI bridge resources from device tree
> - * @hose: newly allocated pci_controller to be setup
> - * @dev: device node of the host bridge
> - * @primary: set if primary bus (32 bits only, soon to be deprecated)
> - *
> - * This function will parse the "ranges" property of a PCI host bridge device
> - * node and setup the resource mapping of a pci controller based on its
> - * content.
> - *
> - * Life would be boring if it wasn't for a few issues that we have to deal
> - * with here:
> - *
> - *   - We can only cope with one IO space range and up to 3 Memory space
> - *     ranges. However, some machines (thanks Apple !) tend to split their
> - *     space into lots of small contiguous ranges. So we have to coalesce.
> - *
> - *   - We can only cope with all memory ranges having the same offset
> - *     between CPU addresses and PCI addresses. Unfortunately, some bridges
> - *     are setup for a large 1:1 mapping along with a small "window" which
> - *     maps PCI address 0 to some arbitrary high address of the CPU space in
> - *     order to give access to the ISA memory hole.
> - *     The way out of here that I've chosen for now is to always set the
> - *     offset based on the first resource found, then override it if we
> - *     have a different offset and the previous was set by an ISA hole.
> - *
> - *   - Some busses have IO space not starting at 0, which causes trouble with
> - *     the way we do our IO resource renumbering. The code somewhat deals with
> - *     it for 64 bits but I would expect problems on 32 bits.
> - *
> - *   - Some 32 bits platforms such as 4xx can have physical space larger than
> - *     32 bits so we need to use 64 bits values for the parsing
> - */
> -void pci_process_bridge_OF_ranges(struct pci_controller *hose,
> -				  struct device_node *dev, int primary)
> -{
> -	const u32 *ranges;
> -	int rlen;
> -	int pna = of_n_addr_cells(dev);
> -	int np = pna + 5;
> -	int memno = 0, isa_hole = -1;
> -	u32 pci_space;
> -	unsigned long long pci_addr, cpu_addr, pci_next, cpu_next, size;
> -	unsigned long long isa_mb = 0;
> -	struct resource *res;
> -
> -	printk(KERN_INFO "PCI host bridge %s %s ranges:\n",
> -	       dev->full_name, primary ? "(primary)" : "");
> -
> -	/* Get ranges property */
> -	ranges = of_get_property(dev, "ranges", &rlen);
> -	if (ranges == NULL)
> -		return;
> -
> -	/* Parse it */
> -	while ((rlen -= np * 4) >= 0) {
> -		/* Read next ranges element */
> -		pci_space = ranges[0];
> -		pci_addr = of_read_number(ranges + 1, 2);
> -		cpu_addr = of_translate_address(dev, ranges + 3);
> -		size = of_read_number(ranges + pna + 3, 2);
> -		ranges += np;
> -
> -		/* If we failed translation or got a zero-sized region
> -		 * (some FW try to feed us with non sensical zero sized regions
> -		 * such as power3 which look like some kind of attempt at exposing
> -		 * the VGA memory hole)
> -		 */
> -		if (cpu_addr == OF_BAD_ADDR || size == 0)
> -			continue;
> -
> -		/* Now consume following elements while they are contiguous */
> -		for (; rlen >= np * sizeof(u32);
> -		     ranges += np, rlen -= np * 4) {
> -			if (ranges[0] != pci_space)
> -				break;
> -			pci_next = of_read_number(ranges + 1, 2);
> -			cpu_next = of_translate_address(dev, ranges + 3);
> -			if (pci_next != pci_addr + size ||
> -			    cpu_next != cpu_addr + size)
> -				break;
> -			size += of_read_number(ranges + pna + 3, 2);
> -		}
> -
> -		/* Act based on address space type */
> -		res = NULL;
> -		switch ((pci_space >> 24) & 0x3) {
> -		case 1:		/* PCI IO space */
> -			printk(KERN_INFO
> -			       "  IO 0x%016llx..0x%016llx -> 0x%016llx\n",
> -			       cpu_addr, cpu_addr + size - 1, pci_addr);
> -
> -			/* We support only one IO range */
> -			if (hose->pci_io_size) {
> -				printk(KERN_INFO
> -				       " \\--> Skipped (too many) !\n");
> -				continue;
> -			}
> -#ifdef CONFIG_PPC32
> -			/* On 32 bits, limit I/O space to 16MB */
> -			if (size > 0x01000000)
> -				size = 0x01000000;
> -
> -			/* 32 bits needs to map IOs here */
> -			hose->io_base_virt = ioremap(cpu_addr, size);
> -
> -			/* Expect trouble if pci_addr is not 0 */
> -			if (primary)
> -				isa_io_base =
> -					(unsigned long)hose->io_base_virt;
> -#endif /* CONFIG_PPC32 */
> -			/* pci_io_size and io_base_phys always represent IO
> -			 * space starting at 0 so we factor in pci_addr
> -			 */
> -			hose->pci_io_size = pci_addr + size;
> -			hose->io_base_phys = cpu_addr - pci_addr;
> -
> -			/* Build resource */
> -			res = &hose->io_resource;
> -			res->flags = IORESOURCE_IO;
> -			res->start = pci_addr;
> -			break;
> -		case 2:		/* PCI Memory space */
> -		case 3:		/* PCI 64 bits Memory space */
> -			printk(KERN_INFO
> -			       " MEM 0x%016llx..0x%016llx -> 0x%016llx %s\n",
> -			       cpu_addr, cpu_addr + size - 1, pci_addr,
> -			       (pci_space & 0x40000000) ? "Prefetch" : "");
> -
> -			/* We support only 3 memory ranges */
> -			if (memno >= 3) {
> -				printk(KERN_INFO
> -				       " \\--> Skipped (too many) !\n");
> -				continue;
> -			}
> -			/* Handles ISA memory hole space here */
> -			if (pci_addr == 0) {
> -				isa_mb = cpu_addr;
> -				isa_hole = memno;
> -				if (primary || isa_mem_base == 0)
> -					isa_mem_base = cpu_addr;
> -				hose->isa_mem_phys = cpu_addr;
> -				hose->isa_mem_size = size;
> -			}
> -
> -			/* We get the PCI/Mem offset from the first range or
> -			 * the, current one if the offset came from an ISA
> -			 * hole. If they don't match, bugger.
> -			 */
> -			if (memno == 0 ||
> -			    (isa_hole >= 0 && pci_addr != 0 &&
> -			     hose->pci_mem_offset == isa_mb))
> -				hose->pci_mem_offset = cpu_addr - pci_addr;
> -			else if (pci_addr != 0 &&
> -				 hose->pci_mem_offset != cpu_addr - pci_addr) {
> -				printk(KERN_INFO
> -				       " \\--> Skipped (offset mismatch) !\n");
> -				continue;
> -			}
> -
> -			/* Build resource */
> -			res = &hose->mem_resources[memno++];
> -			res->flags = IORESOURCE_MEM;
> -			if (pci_space & 0x40000000)
> -				res->flags |= IORESOURCE_PREFETCH;
> -			res->start = cpu_addr;
> -			break;
> -		}
> -		if (res != NULL) {
> -			res->name = dev->full_name;
> -			res->end = res->start + size - 1;
> -			res->parent = NULL;
> -			res->sibling = NULL;
> -			res->child = NULL;
> -		}
> -	}
> -
> -	/* If there's an ISA hole and the pci_mem_offset is -not- matching
> -	 * the ISA hole offset, then we need to remove the ISA hole from
> -	 * the resource list for that brige
> -	 */
> -	if (isa_hole >= 0 && hose->pci_mem_offset != isa_mb) {
> -		unsigned int next = isa_hole + 1;
> -		printk(KERN_INFO " Removing ISA hole at 0x%016llx\n", isa_mb);
> -		if (next < memno)
> -			memmove(&hose->mem_resources[isa_hole],
> -				&hose->mem_resources[next],
> -				sizeof(struct resource) * (memno - next));
> -		hose->mem_resources[--memno].flags = 0;
> -	}
> -}
> -
>  /* Decide whether to display the domain number in /proc */
>  int pci_proc_domain(struct pci_bus *bus)
>  {
> diff --git a/drivers/of/address.c b/drivers/of/address.c
> index 04da786..e87f45e 100644
> --- a/drivers/of/address.c
> +++ b/drivers/of/address.c
> @@ -227,6 +227,69 @@ int of_pci_address_to_resource(struct device_node *dev, int bar,
>  	return __of_address_to_resource(dev, addrp, size, flags, NULL, r);
>  }
>  EXPORT_SYMBOL_GPL(of_pci_address_to_resource);
> +
> +int of_pci_range_parser(struct of_pci_range_parser *parser,
> +			struct device_node *node)
> +{
> +	const int na = 3, ns = 2;
> +	int rlen;
> +
> +	parser->node = node;
> +	parser->pna = of_n_addr_cells(node);
> +	parser->np = parser->pna + na + ns;
> +
> +	parser->range = of_get_property(node, "ranges", &rlen);
> +	if (parser->range == NULL)
> +		return -ENOENT;
> +
> +	parser->end = parser->range + rlen / sizeof(__be32);
> +
> +	return 0;
> +}
> +
> +struct of_pci_range *of_pci_process_ranges(struct of_pci_range_parser *parser,
> +						struct of_pci_range *range)
> +{
> +	const int na = 3, ns = 2;
> +
> +	if (!parser->range || parser->range + parser->np > parser->end)
> +		return NULL;
> +
> +	range->pci_space = be32_to_cpup(parser->range);
> +	range->flags = of_bus_pci_get_flags(parser->range);
> +	range->pci_addr = of_read_number(parser->range + 1, ns);
> +	range->cpu_addr = of_translate_address(parser->node,
> +				parser->range + na);
> +	range->size = of_read_number(parser->range + parser->pna + na, ns);
> +
> +	parser->range += parser->np;
> +
> +	/* Now consume following elements while they are contiguous */
> +	while (parser->range + parser->np <= parser->end) {
> +		u32 flags, pci_space;
> +		u64 pci_addr, cpu_addr, size;
> +
> +		pci_space = be32_to_cpup(parser->range);
> +		flags = of_bus_pci_get_flags(parser->range);
> +		pci_addr = of_read_number(parser->range + 1, ns);
> +		cpu_addr = of_translate_address(parser->node,
> +				parser->range + na);
> +		size = of_read_number(parser->range + parser->pna + na, ns);
> +
> +		if (flags != range->flags)
> +			break;
> +		if (pci_addr != range->pci_addr + range->size ||
> +		    cpu_addr != range->cpu_addr + range->size)
> +			break;
> +
> +		range->size += size;
> +		parser->range += parser->np;
> +	}
> +
> +	return range;
> +}
> +EXPORT_SYMBOL_GPL(of_pci_process_ranges);
> +
>  #endif /* CONFIG_PCI */
>  
>  /*
> diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
> index 13e37e2..f88bd18 100644
> --- a/drivers/of/of_pci.c
> +++ b/drivers/of/of_pci.c
> @@ -4,6 +4,10 @@
>  #include <linux/of_pci.h>
>  #include <asm/prom.h>
>  
> +#if defined(CONFIG_PPC32) || defined(CONFIG_PPC64) || defined(CONFIG_MICROBLAZE)
> +#include <asm/pci-bridge.h>
> +#endif
> +
>  static inline int __of_pci_pci_compare(struct device_node *node,
>  				       unsigned int devfn)
>  {
> @@ -40,3 +44,167 @@ struct device_node *of_pci_find_child_device(struct device_node *parent,
>  	return NULL;
>  }
>  EXPORT_SYMBOL_GPL(of_pci_find_child_device);
> +
> +/**
> + * pci_process_bridge_OF_ranges - Parse PCI bridge resources from device tree
> + * @hose: newly allocated pci_controller to be setup
> + * @dev: device node of the host bridge
> + * @primary: set if primary bus (32 bits only, soon to be deprecated)
> + *
> + * This function will parse the "ranges" property of a PCI host bridge device
> + * node and setup the resource mapping of a pci controller based on its
> + * content.
> + *
> + * Life would be boring if it wasn't for a few issues that we have to deal
> + * with here:
> + *
> + *   - We can only cope with one IO space range and up to 3 Memory space
> + *     ranges. However, some machines (thanks Apple !) tend to split their
> + *     space into lots of small contiguous ranges. So we have to coalesce.
> + *
> + *   - We can only cope with all memory ranges having the same offset
> + *     between CPU addresses and PCI addresses. Unfortunately, some bridges
> + *     are setup for a large 1:1 mapping along with a small "window" which
> + *     maps PCI address 0 to some arbitrary high address of the CPU space in
> + *     order to give access to the ISA memory hole.
> + *     The way out of here that I've chosen for now is to always set the
> + *     offset based on the first resource found, then override it if we
> + *     have a different offset and the previous was set by an ISA hole.
> + *
> + *   - Some busses have IO space not starting at 0, which causes trouble with
> + *     the way we do our IO resource renumbering. The code somewhat deals with
> + *     it for 64 bits but I would expect problems on 32 bits.
> + *
> + *   - Some 32 bits platforms such as 4xx can have physical space larger than
> + *     32 bits so we need to use 64 bits values for the parsing
> + */
> +#if defined(CONFIG_PPC32) || defined(CONFIG_PPC64) || defined(CONFIG_MICROBLAZE)
> +void pci_process_bridge_OF_ranges(struct pci_controller *hose,
> +				  struct device_node *dev, int primary)
> +{
> +	int memno = 0, isa_hole = -1;
> +	unsigned long long isa_mb = 0;
> +	struct resource *res;
> +	struct of_pci_range range;
> +	struct of_pci_range_parser parser;
> +	u32 res_type;
> +
> +	pr_info("PCI host bridge %s %s ranges:\n",
> +	       dev->full_name, primary ? "(primary)" : "");
> +
> +	/* Check for ranges property */
> +	if (of_pci_range_parser(&parser, dev))
> +		return;
> +
> +	pr_debug("Parsing ranges property...\n");
> +	for_each_of_pci_range(&parser, &range) {
> +		/* Read next ranges element */
> +		pr_debug("pci_space: 0x%08x pci_addr: 0x%016llx ",
> +				range.pci_space, range.pci_addr);
> +		pr_debug("cpu_addr: 0x%016llx size: 0x%016llx\n",
> +				range.cpu_addr, range.size);
> +
> +		/* If we failed translation or got a zero-sized region
> +		 * (some FW try to feed us with non sensical zero sized regions
> +		 * such as power3 which look like some kind of attempt at
> +		 * exposing the VGA memory hole)
> +		 */
> +		if (range.cpu_addr == OF_BAD_ADDR || range.size == 0)
> +			continue;
> +
> +		/* Act based on address space type */
> +		res = NULL;
> +		res_type = range.flags & IORESOURCE_TYPE_BITS;
> +		if (res_type == IORESOURCE_IO) {
> +			pr_info("  IO 0x%016llx..0x%016llx -> 0x%016llx\n",
> +				range.cpu_addr, range.cpu_addr + range.size - 1,
> +				range.pci_addr);
> +
> +			/* We support only one IO range */
> +			if (hose->pci_io_size) {
> +				pr_info(" \\--> Skipped (too many) !\n");
> +				continue;
> +			}
> +#if defined(CONFIG_PPC32) || defined(CONFIG_MICROBLAZE)
> +			/* On 32 bits, limit I/O space to 16MB */
> +			if (range.size > 0x01000000)
> +				range.size = 0x01000000;
> +
> +			/* 32 bits needs to map IOs here */
> +			hose->io_base_virt = ioremap(range.cpu_addr,
> +						range.size);
> +
> +			/* Expect trouble if pci_addr is not 0 */
> +			if (primary)
> +				isa_io_base =
> +					(unsigned long)hose->io_base_virt;
> +#endif /* CONFIG_PPC32 || CONFIG_MICROBLAZE */
> +			/* pci_io_size and io_base_phys always represent IO
> +			 * space starting at 0 so we factor in pci_addr
> +			 */
> +			hose->pci_io_size = range.pci_addr + range.size;
> +			hose->io_base_phys = range.cpu_addr - range.pci_addr;
> +
> +			/* Build resource */
> +			res = &hose->io_resource;
> +			range.cpu_addr = range.pci_addr;
> +		} else if (res_type == IORESOURCE_MEM) {
> +			pr_info(" MEM 0x%016llx..0x%016llx -> 0x%016llx %s\n",
> +				range.cpu_addr, range.cpu_addr + range.size - 1,
> +				range.pci_addr,
> +				(range.pci_space & 0x40000000) ?
> +				"Prefetch" : "");
> +
> +			/* We support only 3 memory ranges */
> +			if (memno >= 3) {
> +				pr_info(" \\--> Skipped (too many) !\n");
> +				continue;
> +			}
> +			/* Handles ISA memory hole space here */
> +			if (range.pci_addr == 0) {
> +				isa_mb = range.cpu_addr;
> +				isa_hole = memno;
> +				if (primary || isa_mem_base == 0)
> +					isa_mem_base = range.cpu_addr;
> +				hose->isa_mem_phys = range.cpu_addr;
> +				hose->isa_mem_size = range.size;
> +			}
> +
> +			/* We get the PCI/Mem offset from the first range or
> +			 * the, current one if the offset came from an ISA
> +			 * hole. If they don't match, bugger.
> +			 */
> +			if (memno == 0 ||
> +			(isa_hole >= 0 && range.pci_addr != 0 &&
> +			     hose->pci_mem_offset == isa_mb))
> +				hose->pci_mem_offset = range.cpu_addr -
> +							range.pci_addr;
> +			else if (range.pci_addr != 0 &&
> +				hose->pci_mem_offset != range.cpu_addr -
> +							range.pci_addr) {
> +				pr_info(" \\--> Skipped (offset mismatch) !\n");
> +				continue;
> +			}
> +
> +			/* Build resource */
> +			res = &hose->mem_resources[memno++];
> +		}
> +		if (res != NULL)
> +			of_pci_range_to_resource(&range, dev, res);
> +	}
> +
> +	/* If there's an ISA hole and the pci_mem_offset is -not- matching
> +	 * the ISA hole offset, then we need to remove the ISA hole from
> +	 * the resource list for that brige
> +	 */
> +	if (isa_hole >= 0 && hose->pci_mem_offset != isa_mb) {
> +		unsigned int next = isa_hole + 1;
> +		pr_info(" Removing ISA hole at 0x%016llx\n", isa_mb);
> +		if (next < memno)
> +			memmove(&hose->mem_resources[isa_hole],
> +				&hose->mem_resources[next],
> +				sizeof(struct resource) * (memno - next));
> +		hose->mem_resources[--memno].flags = 0;
> +	}
> +}
> +#endif
> diff --git a/include/linux/of_address.h b/include/linux/of_address.h
> index 0506eb5..c7003a3 100644
> --- a/include/linux/of_address.h
> +++ b/include/linux/of_address.h
> @@ -4,6 +4,32 @@
>  #include <linux/errno.h>
>  #include <linux/of.h>
>  
> +struct of_pci_range_parser {
> +	struct device_node *node;
> +	const __be32 *range, *end;
> +	int np, pna;
> +};
> +
> +struct of_pci_range {
> +	u32 pci_space;
> +	u64 pci_addr;
> +	u64 cpu_addr;
> +	u64 size;
> +	u32 flags;
> +};
> +
> +#define for_each_of_pci_range(parser, range) \
> +	for (; of_pci_process_ranges(parser, range);)
> +
> +#define of_pci_range_to_resource(range, np, res) \
> +	do { \
> +		(res)->flags = (range)->flags; \
> +		(res)->start = (range)->cpu_addr; \
> +		(res)->end = (range)->cpu_addr + (range)->size - 1; \
> +		(res)->parent = (res)->child = (res)->sibling = NULL; \
> +		(res)->name = (np)->full_name; \
> +	} while (0)
> +
>  #ifdef CONFIG_OF_ADDRESS
>  extern u64 of_translate_address(struct device_node *np, const __be32 *addr);
>  extern bool of_can_translate_address(struct device_node *dev);
> @@ -27,6 +53,10 @@ static inline unsigned long pci_address_to_pio(phys_addr_t addr) { return -1; }
>  #define pci_address_to_pio pci_address_to_pio
>  #endif
>  
> +int of_pci_range_parser(struct of_pci_range_parser *parser,
> +			struct device_node *node);
> +struct of_pci_range *of_pci_process_ranges(struct of_pci_range_parser *parser,
> +						struct of_pci_range *range);
>  #else /* CONFIG_OF_ADDRESS */
>  #ifndef of_address_to_resource
>  static inline int of_address_to_resource(struct device_node *dev, int index,
> @@ -53,6 +83,18 @@ static inline const __be32 *of_get_address(struct device_node *dev, int index,
>  {
>  	return NULL;
>  }
> +
> +int of_pci_range_parser(struct of_pci_range_parser *parser,
> +			struct device_noed *node)
> +{
> +	return -1;
> +}
> +
> +struct of_pci_range *of_pci_process_ranges(struct of_pci_range_parser *parser,
> +						struct of_pci_range *range)
> +{
> +	return NULL;
> +}
>  #endif /* CONFIG_OF_ADDRESS */
>  
>  
> diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
> index bb115de..6852481 100644
> --- a/include/linux/of_pci.h
> +++ b/include/linux/of_pci.h
> @@ -11,4 +11,7 @@ struct device_node;
>  struct device_node *of_pci_find_child_device(struct device_node *parent,
>  					     unsigned int devfn);
>  
> +void pci_process_bridge_OF_ranges(struct pci_controller *hose,
> +			struct device_node *dev, int primary);
> +
>  #endif
> 



From jason at lakedaemon.net  Mon Apr  8 13:00:49 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Mon, 8 Apr 2013 13:00:49 -0400
Subject: [PATCH] ARM: kirkwood: DT board setup for CloudBox
In-Reply-To: <515E5DA9.1000605@free.fr>
References: <20130401163316.GC16404@kw.sim.vm.gnt> <515A5BC6.5000007@free.fr>
 <20130402114535.GR13280@titan.lakedaemon.net>
 <20130402125408.GH16404@kw.sim.vm.gnt>
 <20130402172454.GT13280@titan.lakedaemon.net>
 <515D0776.7050208@free.fr> <20130404080058.GJ16404@kw.sim.vm.gnt>
 <20130404093435.GK16404@kw.sim.vm.gnt>
 <20130405011143.GX13280@titan.lakedaemon.net>
 <515E5DA9.1000605@free.fr>
Message-ID: <20130408170049.GY13280@titan.lakedaemon.net>

On Fri, Apr 05, 2013 at 07:14:17AM +0200, Chris Moore wrote:
> Le 05/04/2013 03:11, Jason Cooper a ?crit :
> >On Thu, Apr 04, 2013 at 11:34:35AM +0200, Simon Guinot wrote:
> >>
> ...
> 
> >>Then we are back to the initial problem...
> >>
> >>Maybe we could append some suffixes based on the version:
> >>
> >>1: cloudbox-v1
> >>2: cloudbox-v2
> >>
> >>Or better, suffix based on the other code names:
> >>
> >>1: cloudbox-ns2mini
> >>2: cloudbox-familybox
> >>
> >>Or even let the things as they are:
> >>
> >>1: netspace_v2_mini
> >>2: cloudbox
> >In light of the above info, let's got with the third option.  If we
> >discover a different LaCie Cloudbox board down the road, we can add an
> >appropriately more specific compatible string to differentiate.  As you
> >can tell, I'd prefer to have something more specific in the original
> >commit, but we can only work with what we're given. :(
> >
> 
> This is now OK with me.
> However I would like to have a more precise description somewhere;
> probably either in the Kconfig or, if this is obsolescent, in
> whatever replaces it.
> I think that someone grepping the kernel sources for the commercial
> name "CloudBox" should find both versions and be able to decide
> which one he has.

A one line comment in netspace_v2_mini dts file should suffice.

thx,

Jason.


From arnd at arndb.de  Mon Apr  8 13:02:24 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 8 Apr 2013 19:02:24 +0200
Subject: [GIT PULL] arm-soc: Xilinx zynq core - pmu enable for v3.10
In-Reply-To: <8fadfba0-8f3d-4008-983b-259ed9e4f302@TX2EHSMHS012.ehs.local>
References: <8fadfba0-8f3d-4008-983b-259ed9e4f302@TX2EHSMHS012.ehs.local>
Message-ID: <201304081902.24451.arnd@arndb.de>

On Thursday 04 April 2013, Michal Simek wrote:
> Hi Arnd and Olof,
> 
> please pull this dts change to your tree.
> It enables pmu support for zynq.
> 
> Not sure if core branch is the correct one but feel free to rename it.
> 

Pulled into next/dt

	Arnd


From tony at atomide.com  Mon Apr  8 13:02:54 2013
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 8 Apr 2013 10:02:54 -0700
Subject: [GIT PULL] OMAP: PM: fixes for v3.10
In-Reply-To: <87hajkjz89.fsf@linaro.org>
References: <87hajkjz89.fsf@linaro.org>
Message-ID: <20130408170253.GL10155@atomide.com>

* Kevin Hilman <khilman at linaro.org> [130405 17:14]:
> Tony,
> 
> This OMAP PM fixes tag is based on your cleanup-v2 branch due to some
> dependencies in the series from Santosh you already merged.
> 
> Kevin
> 
> 
> The following changes since commit c309f7f46167e85d1aae2fd31f23e7d2b5cdfbe0:
> 
>   Merge branch 'for_3.10/omap_generic_cleanup_v2' of git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux into omap-for-v3.10/cleanup-v2 (2013-03-28 14:45:31 -0700)
> 
> are available in the git repository at:
> 
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git tags/omap-pm-v3.10/fixes/pm
> 
> for you to fetch changes up to b7806dc7cba840ea538706621486475d93a53c55:
> 
>   ARM: OMAP4+: PM: Restore CPU power state to ON with clockdomain force wakeup method (2013-04-05 14:19:25 -0700)
> 
> ----------------------------------------------------------------
> OMAP PM fixes for v3.10

Thanks pulling into omap-for-v3.10/fixes-pm.

Regards,

Tony
 
> ----------------------------------------------------------------
> Santosh Shilimkar (1):
>       ARM: OMAP4+: PM: Restore CPU power state to ON with clockdomain force wakeup method
> 
>  arch/arm/mach-omap2/cpuidle44xx.c |  1 +
>  arch/arm/mach-omap2/omap-smp.c    | 12 ++++++++++--
>  2 files changed, 11 insertions(+), 2 deletions(-)


From tony at atomide.com  Mon Apr  8 13:03:12 2013
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 8 Apr 2013 10:03:12 -0700
Subject: [GIT PULL] OMAP: PM: cpuidle cleanups for v3.10
In-Reply-To: <874nfkjz3l.fsf@linaro.org>
References: <874nfkjz3l.fsf@linaro.org>
Message-ID: <20130408170312.GM10155@atomide.com>

* Kevin Hilman <khilman at linaro.org> [130405 17:17]:
> Tony,
> 
> Please pull the following changes for OMAP CPUidle for v3.10.
> 
> Kevin
> 
> 
> The following changes since commit 07961ac7c0ee8b546658717034fe692fd12eefa9:
> 
>   Linux 3.9-rc5 (2013-03-31 15:12:43 -0700)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git tags/omap-pm-v3.10/cleanup/cpuidle
> 
> for you to fetch changes up to 2507386b7c01e3b0f6967d12c72467bf3f66c77e:
> 
>   ARM: OMAP4+: CPUidle: Consolidate idle driver for OMAP5 support (2013-04-05 13:37:33 -0700)
> 
> ----------------------------------------------------------------
> OMAP3/4 CPUidle cleanups for v3.10

Thanks pulling into omap-for-v3.10/cleanup-pm.

Regards,

Tony
 
> ----------------------------------------------------------------
> Daniel Lezcano (1):
>       ARM: omap3: cpuidle: enable time keeping
> 
> Santosh Shilimkar (5):
>       ARM: OMAP4: CPUidle: Avoid double idle driver registration
>       ARM: OMAP: CPUidle: Unregister drivere on device registration failure
>       ARM: OMAP4: CPUidle: Make C-state description field more precise
>       ARM: OMAP4+: CPUidle: Deprecate use of omap4_mpuss_read_prev_context_state()
>       ARM: OMAP4+: CPUidle: Consolidate idle driver for OMAP5 support
> 
>  arch/arm/mach-omap2/common.h              |  5 ----
>  arch/arm/mach-omap2/cpuidle34xx.c         | 11 +++++--
>  arch/arm/mach-omap2/cpuidle44xx.c         | 48 +++++++++++++++++--------------
>  arch/arm/mach-omap2/omap-mpuss-lowpower.c | 14 ---------
>  4 files changed, 35 insertions(+), 43 deletions(-)


From jgunthorpe at obsidianresearch.com  Mon Apr  8 13:03:10 2013
From: jgunthorpe at obsidianresearch.com (Jason Gunthorpe)
Date: Mon, 8 Apr 2013 11:03:10 -0600
Subject: mvebu-mbus: defining a DT binding
In-Reply-To: <201304061039.56241.arnd@arndb.de>
References: <20130405150200.7b6dee63@skate> <201304052301.27231.arnd@arndb.de>
 <20130405212143.GA16221@obsidianresearch.com>
 <201304061039.56241.arnd@arndb.de>
Message-ID: <20130408170310.GB30824@obsidianresearch.com>

On Sat, Apr 06, 2013 at 10:39:56AM +0200, Arnd Bergmann wrote:

> > Realistically this size should never be used so it doesn't matter if
> > it is 4G or 4G-1 - though obviously 4G is preferred in cases where
> > size cells is 2. :)
> 
> But the PCI bus already is required to have #size-cells=<2>, and
> we would only use this in the ranges property of the PCI node, right?

Yes, my bad, you are correct.

> > So.. I don't think it matters today for mvebu, but something to think
> > about - shuffling the firmware's address map could be dangerous.
> 
> I would at least expect a secure-mode firmware to prevent the OS
> from changing any mappings that the firmware relies on, but I see
> what you mean.

Right.

Jason


From mturquette at linaro.org  Mon Apr  8 13:03:31 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Mon, 08 Apr 2013 10:03:31 -0700
Subject: [PATCHv2 00/10] ARM: sunxi: Architecture cleanups and rework
In-Reply-To: <515F0743.4010509@free-electrons.com>
References: <1364289198-11589-1-git-send-email-maxime.ripard@free-electrons.com>
 <51555CCF.2090005@free-electrons.com> <20130402183100.GM25867@quad.lixom.net>
 <515F0743.4010509@free-electrons.com>
Message-ID: <20130408170331.14359.52789@quantum>

Quoting Maxime Ripard (2013-04-05 10:17:55)
> Le 02/04/2013 20:31, Olof Johansson a ?crit :
> > On Fri, Mar 29, 2013 at 10:20:15AM +0100, Maxime Ripard wrote:
> >> Hi Mike,
> >>
> >> Le 26/03/2013 10:13, Maxime Ripard a ?crit :
> >>> Hi,
> >>>
> >>> This patchset is a serie of various cleanups and reworks in the sunxi
> >>> architecture to prepare a clean landing for the next Allwinner SoC, the
> >>> A31 (sun6i).
> >>>
> >>> The A31 is significantly different from the previous Allwinner SoC we
> >>> supported, the A10 and A13, to no longer make the generic sunxi prefix
> >>> we used in most compatible string relevant, while it should really have
> >>> been sun4i in the first place.
> >>>
> >>> This set is also the occasion to cleanup the timer and irq code by
> >>> switching to the recently introduced clocksource and irqchip
> >>> infrastructures.
> >>>
> >>> This set depends on the UART patches I sent previously.
> >>
> >> I was meaning to take this branch, but some of the drivers changes in it
> >> depends on the clock patches that Emilio sent and that are in clk-next.
> >> Is it ok to merge clk-next into my branch?
> > 
> > All of of a <subsystem>-next branch is usually asking for trouble, since it'll
> > cause all sorts of pain if the other maintianer is rebasing his for-next
> > branch.
> > 
> > Best is to get those patches on just a minimal topic branch (that is still
> > bisectable) that is shared between the trees.
> > 
> > Mike?
> 
> Mike, could you comment on that? I'd very much like to see this patches
> come into 3.10.
> 

Sorry for not seeing this earlier.  This thread ended up in my mail
killfile somehow.

I have already merged the patches that this series depends on into my
immutable clk-for-3.10 branch.  Unfortunately that means that they
cannot be separated out into a shared topic branch.  However
clk-for-3.10 is immutable and will never be rebased, so it is safe to
pull in as a dependency.

Does that solve the issue adequately?

Just for reference, the clk-for-3.x branch is always a subset of
clk-next.  Once some patches from clk-next have had some cycles in
linux-next and enough time has passed since being merged without any
regressions or other issues I migrate them over into clk-for-3.x.
clk-next itself is typically just clk-for-3.x with between 3 and 10
patches on top that may be dropped or rebased or merged into
clk-for-3.x.

Regards,
Mike

> Maxime
> 
> 
> -- 
> Maxime Ripard, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com


From gnurou at gmail.com  Mon Apr  8 13:03:30 2013
From: gnurou at gmail.com (Alexandre Courbot)
Date: Mon, 8 Apr 2013 10:03:30 -0700
Subject: [PATCH] gpio: update gpio Chinese documentation
In-Reply-To: <20130408012253.GA2545@cbz-workstation>
References: <20130408012253.GA2545@cbz-workstation>
Message-ID: <CAAVeFuLrgTGoSU+OG2RWEVorcCSREG10hTMSAafNMZdFdG7APw@mail.gmail.com>

2013/4/7 Chen Baozi <baozich at gmail.com>:
> Since the GENERIC_GPIO has been removed and the documentation of it
> has been modified, this patch updates the corresponding documentation of
> gpio in Chinese.
>
> Signed-off-by: Chen Baozi <baozich at gmail.com>
> ---
>  Documentation/zh_CN/gpio.txt | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)

Acked-by: Alexandre Courbot <acourbot at nvidia.com>

Integrated into my series, thanks. With this I guess I can send the
whole series again to Grant for him to integrate in his branch. It's
time if we want it to make it for 3.10.

Alex.


>
> diff --git a/Documentation/zh_CN/gpio.txt b/Documentation/zh_CN/gpio.txt
> index 4fa7b4e..d5b8f01 100644
> --- a/Documentation/zh_CN/gpio.txt
> +++ b/Documentation/zh_CN/gpio.txt
> @@ -84,10 +84,10 @@ GPIO ??
>  ?????????????(??????????????????,???
>  ????????? GPIO ????????????????????)
>
> -????,?????????????????????????????
> -??? Kconfig ???? GENERIC_GPIO??? (??? true)????
> -?? <asm/gpio.h> ????????? GPIO ???????? Kconfig
> -???????GENERIC_GPIO????????:
> +????,????????????????????????????????
> +??? Kconfig ??? ARCH_REQUIRE_GPIOLIB ?? ARCH_WANT_OPTIONAL_GPIOLIB
> +????????? GPIO ???????? Kconfig ???????GENERIC_GPIO?
> +???????:
>
>         #include <linux/gpio.h>
>
> --
> 1.8.1.4
>

From ohaugan at codeaurora.org  Mon Apr  8 13:03:54 2013
From: ohaugan at codeaurora.org (Olav Haugan)
Date: Mon, 08 Apr 2013 10:03:54 -0700
Subject: [PATCH] documentation: iommu: add description of ARM System MMU
 binding
In-Reply-To: <20130408092535.GA17476@mudshark.cambridge.arm.com>
References: <1365094259-24847-1-git-send-email-will.deacon@arm.com>
 <515F37C1.4000109@codeaurora.org>
 <20130408092535.GA17476@mudshark.cambridge.arm.com>
Message-ID: <5162F87A.7070409@codeaurora.org>

Hi Will,

On 4/8/2013 2:25 AM, Will Deacon wrote:
> Hi Olav,
> 
> On Fri, Apr 05, 2013 at 09:44:49PM +0100, Olav Haugan wrote:
>> On 4/4/2013 9:50 AM, Will Deacon wrote:
>>> diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
>>> new file mode 100644
>>> index 0000000..938325f
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
>>> @@ -0,0 +1,61 @@
>>> +* ARM System MMU Architecture Implementation
>>> +
>>> +ARM SoCs may contain an implementation of the ARM System Memory
>>> +Management Unit Architecture, which can be used to provide 1 or 2 stages
>>> +of address translation to bus masters external to the CPU.
>>> +
>>> +The SMMU may also raise interrupts in response to various fault
>>> +conditions.
>>> +
>>> +** System MMU required properties:
>>> +
>>> +- compatible    : Should be one of "arm,smmu-v1" or "arm,smmu-v2"
>>> +                  depending on the version of the architecture
>>> +                  implemented.
>>> +
>>> +- reg           : Base address and size of the SMMU.
>>> +
>>> +- #global-interrupts : The number of global interrupts exposed by the
>>> +                       device.
>>> +
>>> +- interrupts    : Interrupt list, with the first #global-irqs entries
>>> +                  corresponding to the global interrupts and any
>>> +                  following entries corresponding to context interrupts,
>>> +                  specified in order of their indexing by the SMMU.
>>> +
>>> +- mmu-masters   : A list of phandles to device nodes representing bus
>>> +                  masters for which the SMMU can provide a translation.
>>
>> I am not sure I understand the use of mmu-masters. I would imagine that
>> the bus masters themselves would have phandles to their respective SMMUs
>> that provides the translation.
> 
> The problem with that is when you have chained SMMUs. E.g., a separate SMMU
> for stage 1 and stage 2, where the StreamIDs are not the same going into the
> second SMMU on the chain. The set of masters and StreamIDs coming into a
> system MMU is really a property of that system MMU, and is determined at
> integration time.
> 
>>> +
>>> +- stream-ids    : A list of 16-bit values corresponding to the StreamIDs
>>> +                  for the devices listed in the mmu-masters property.
>>> +                  This list must be same length as mmu-masters, so
>>> +                  masters with multiple stream-ids will have multiple
>>> +                  entries in mmu-masters.
>>> +
>>
>> Why are the stream IDs (SIDs) coupled with the bus masters in this way?
>> You are probably following a different pattern than we do. Our SMMU
>> driver programs the SMMU SIDs and does not really know or care which
>> mmu-master it belongs to.
> 
> Generally, the StreamIDs are fixed in hardware (as a function of various AXI
> bits -- see the SMMU integration guide) and cannot be set by software.
> Furthermore, when the StreamIDs have an implicit effect on IOMMU domain
> configuration, since stream-matching may not be always be able to identify a
> master uniquely.

Let me clarify what I mean by "our SMMU driver programs the SMMU SIDs".
What I meant to say is that our SMMU driver programs the SID into the
Stream Match Register (SMR) to route the transactions to the correct
context bank based on the SID.

>> Please see my comments above. I would like to work with you on defining
>> the bindings for System MMU. We have had System MMU DT bindings for some
>> time and I'd like to share what we are doing in hope that we can merge
>> something that works for all of us.
>>
>> We use some of the same properties but we have a lot more. We also model
>> the context banks as children of each SMMU in an object-oriented way.
> 
> Hmm, what you have looks really... complicated. Why do you need so much stuff?

Yes, some of the stuff is implementation specific.

>> Here is our current binding for SMMUv1:
>>
>> * Qualcomm MSM IOMMU v1
>>
>> Required properties:
>> - compatible : one of:
>> 	- "qcom,msm-smmu-v1"
>> - reg : offset and length of the register set for the device. Optional
>> 	offset and length for clock register for additional clock that
>> 	needs to be turned on for access to this IOMMU.
>> - reg-names: "iommu_base", "clk_base" (optional)
> 
> Since I'm just working on a software model, I've not gone near clocks.
> However, clocks are fairly well understood so we could easily add those
> later if they're needed.
> 
>> - label: name of this IOMMU instance.
> 
> What?

This is mostly used for debugging allowing us to log a name that is more
user friendly instead of something like "fda64000.qcom,iommu" as the
device name. We also use this to create debugfs directory with a user
friendly name.

> 
>> Optional properties:
>> - qcom,iommu-secure-id : Secure identifier for the IOMMU block
>> - vdd-supply : vdd-supply: phandle to GDSC regulator controlling this IOMMU.
>> - qcom,alt-vdd-supply : Alternative regulator needed to access IOMMU
>>   configuration registers.
>> - interrupts : should contain the performance monitor overflow interrupt
>> number.
>> - qcom,iommu-enable-halt : Enable halt of the IOMMU before programming
>> certain	registers
>> - qcom,iommu-pmu-ngroups: Number of Performance Monitor Unit (PMU) groups.
>> - qcom,iommu-pmu-ncounters: Number of PMU counters per group.
>> - qcom,iommu-pmu-event-classes: List of event classes supported.
>> - qcom,needs-alt-core-clk : boolean to enable the secondary core clock
>> for access to the IOMMU configuration registers
>> - qcom,iommu-bfb-regs : An array of unsigned 32-bit integers
>> corresponding to BFB register addresses that need to be configured for
>> performance tuning purposes. If this property is present, the
>> qcom,iommu-bfb-data must also be present. Register addresses are
>> specified as an offset from the base of the IOMMU hardware block. This
>> property may be omitted if no BFB register configuration needs to be
>> done for a particular IOMMU hardware instance. The registers specified
>> by this property shall fall within the IOMMU implementation-defined
>> register region.
>> - qcom,iommu-bfb-data : An array of unsigned 32-bit integers
>> representing the values to be programmed into the corresponding
>> registers given by the qcom,iommu-bfb-regs property. If this property is
>> present, the qcom,iommu-bfb-regs property shall also be present, and the
>> lengths of both properties shall be the same.
> 
> This really looks specific to your implementation/integration and I can't
> see that we'd want this in the binding to be honest. It would be good to
> have PMU support in the future, but I've not thought about that part yet.

Yes, some of this is specific to our implementation. However, the
properties related to regulators and PMU are not specific I believe. How
do you do handle regulators?

>> - List of sub nodes, one for each of the translation context banks
>> supported.
>>   Each sub node has the following required properties:
>>
>>   - reg : offset and length of the register set for the context bank.
> 
> Why do you need this? The structure of the context banks is well defined by
> the SMMU architecture.

Since we specify the context banks as children of the IOMMU we specify
the address of each node. I believe you should be specifying the "reg"
property for the nodes when you do this.

>>   - interrupts : should contain the context bank interrupt.
>>   - qcom,iommu-ctx-sids : List of stream identifiers associated with
>> this translation context.
> 
> StreamIDs aren't statically associated with a translation context. Why do
> you put them here? Also, how do this interact with stream matching?

We put the StreamIDs in the context bank to tell our driver that these
StreamIDs should be programmed into the Stream Match Register (SMR) to
route the transactions bearing these StreamIDs to this context bank. We
don't really change the SID2CB mapping during run-time. It is set during
compile time.

>>   - label : Name of the context bank
> 
> Again: what?

Same idea as the label in the IOMMU parent node. We also use this to
allow clients to find context bank devices to attach to based on the name.

>> Optional sub-node properties:
>>    - qcom,secure-context : boolean indicating that a context is secure
>>  and programmed by the secure environment.
> 
> Why does Linux care about this?

Linux cares about this because if we are doing content protection using
one of the context banks then the context bank is programmed by the
secure environment and not accessible/programmable by the HLOS.

> 
>> Please let me know your thoughts on this.
> 
> I'd really rather start off small, and describe precisely what we need to
> get architecturally-compliant SMMUs off the ground. Then, as the code grows
> to use more features (PM, PMU, ...) then we can extend the binding.
> Otherwise, we paint ourselves into a corner with the binding before we've
> developed any driver code.

Sure, I did not mean to add implementation specific stuff to upstream
bindings. Does it makes sense to you thought the way we modeled context
banks as child nodes?

Thanks,

Olav Haugan

-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation


From arnd at arndb.de  Mon Apr  8 13:05:46 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 8 Apr 2013 19:05:46 +0200
Subject: [GIT PULL] arm-soc: Xilinx zynq core - smp for v3.10
In-Reply-To: <890ef3b8-f536-4b00-9bd8-5ea50de3bf51@DB8EHSMHS032.ehs.local>
References: <890ef3b8-f536-4b00-9bd8-5ea50de3bf51@DB8EHSMHS032.ehs.local>
Message-ID: <201304081905.46201.arnd@arndb.de>

On Thursday 04 April 2013, Michal Simek wrote:
> Hi Arnd and Olof,
> 
> please pull the following smp support to your arm-soc tree.
> 
> This branch is based on zynq/clksrc/cleanup parts because
> there are some dependencies on moving timer to generic location.
> 
> I could based it on standard Linux tagged version but you will get
> several conflicts you will have to resolve.
> If you are OK to resolving these problems, please let me know
> I will create another branch with core-smp changes which are not based
> on zynq/clksrc/cleanup branch.
> 

This one gave me a little trouble because of conflicts with Catalin's
gic/cleanup branch. Could both of you (Michal and Catalin) have a look
at my resolution? I basically just removed the zynq_secondary_init()
function added in this branch.

I've merged it all into next/soc2 and added a merge with gic/cleanup
to resolve the conflict.

Also, please use signed tags for sending pull requests and include
a description of the branch contents that will end up in the merge
commit.

	Arnd


From tony at atomide.com  Mon Apr  8 13:06:19 2013
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 8 Apr 2013 10:06:19 -0700
Subject: [GIT PULL 1/3] omap non critical fixes for v3.10 merge window
In-Reply-To: <201304081824.35663.arnd@arndb.de>
References: <pull-1364923751-842943>
 <201304081824.35663.arnd@arndb.de>
Message-ID: <20130408170619.GN10155@atomide.com>

* Arnd Bergmann <arnd at arndb.de> [130408 09:29]:
> On Tuesday 02 April 2013, Tony Lindgren wrote:
> > The following changes since commit 07961ac7c0ee8b546658717034fe692fd12eefa9:
> > 
> >   Linux 3.9-rc5 (2013-03-31 15:12:43 -0700)
> > 
> > are available in the git repository at:
> > 
> >   git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.10/fixes-non-critical-signed
> > 
> > for you to fetch changes up to 105612489bf59386b46b3f9f034e03f70e57aee6:
> > 
> >   Merge branch 'for_3.10/omap5_generic_updates' of git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux into omap-for-v3.10/fixes-non-critical (2013-04-01 09:30:47 -0700)
> > 
> 
> Pulled all three branches, thanks a lot!
> 
> The cleanup branch conflicted with a bug fix from Paul Walmsley that Linus
> already merged, see below for the resolution that I used, adding a modified
> line from the one Paul submitted.

Yes looks good thanks. I think I had the same resolve in one
of the other branches, but that should not cause issues with
your branches I presume.

Regards,

Tony


From tony at atomide.com  Mon Apr  8 13:09:14 2013
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 8 Apr 2013 10:09:14 -0700
Subject: [PATCH v4 00/21] ARM: OMAP2+: Adapt to ehci-omap changes for 3.10
In-Reply-To: <5162B2D3.6070007@ti.com>
References: <1363794300-31526-1-git-send-email-rogerq@ti.com>
 <515E8B99.8080803@ti.com> <515E9FB1.2040803@ti.com>
 <20130405154259.GZ10155@atomide.com> <5162B2D3.6070007@ti.com>
Message-ID: <20130408170914.GO10155@atomide.com>

* Benoit Cousson <b-cousson at ti.com> [130408 05:11]:
> Hi Tony,
> 
> On 04/05/2013 05:43 PM, Tony Lindgren wrote:
> > * Benoit Cousson <b-cousson at ti.com> [130405 03:00]:
> >> On 04/05/2013 10:30 AM, Benoit Cousson wrote:
> >>
> >> ...
> >>
> >>>>   ARM: dts: OMAP4: Add HS USB Host IP nodes
> >>>>   ARM: dts: OMAP3: Add HS USB Host IP nodes
> >>>>   ARM: dts: omap3-beagle: Add USB Host support
> >>>
> >>> These 3 DTS patches are good to me, but I cannot applied them on top of
> >>> the already existing patches I queued for 3.10.
> >>>
> >>> git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git
> >>> for_3.10/dts
> >>>
> >>> Could you rebase these 3 ones only, and I will applied them.
> >>
> >> Mmm, in fact, I've just seen the pull request from Tony :-(
> >>
> >>
> >> Tony,
> >>
> >> Don't you want to remove these DTS patches from the pull-request?
> > 
> > Oops sorry :( Looks like I applied them mistakenly as I saved all
> > the patches into a mbox, then applied it. Anyways, too late to start
> > messing with it now.
> >  
> >> Otherwise, I will have to rebase the whole DTS series on top of yours.
> >> That being said, if the branch is not supposed to be rebased, it is doable.
> > 
> > I pulled in your for_3.10/dts for testing, and to me it looks like
> > it's just overlapping additions. So that should be OK to resolve while
> > pulling it in.
> > 
> > It seems there's no need to add omap-for-v3.10/usb as a dependency for
> > your for_3.10/dts unless the conflict gets non-trivial with some
> > additional patches.
> 
> The branch was not complete, with the latest additions, we do have
> conflict due to the addition of several new nodes at the same place.

OK
 
> The resolution is not that hard since it is addition of node only, but
> the rebase on to of omap-for-v3.10/usb will avoid the issue.
> 
> I have a new pre-merged branch available. for_3.10/dts_merged is based
> on omap-for-v3.10/usb and Paul's omap-devel-b-for-3.10 branch to get the
> AM33xx hwmod.
> Paul's branch is just needed to avoid AM33xx regression introduced by
> Santosh hwmod changes present in my branch.
> 
> Just let me know which one you will prefer to pull.

If the merge conflicts are non-trivial, then let's do the pre-merged
branch. That will be easier to test also in this case for am33xx.

Regards,

Tony


From paul at pwsan.com  Mon Apr  8 13:09:41 2013
From: paul at pwsan.com (Paul Walmsley)
Date: Mon, 8 Apr 2013 17:09:41 +0000 (UTC)
Subject: [PATCH] ARM: OMAP4: PM: fix PM regression introduced by recent
 clock cleanup
In-Reply-To: <alpine.DEB.2.00.1304081617470.32105@utopia.booyaka.com>
References: <alpine.DEB.2.00.1302122026530.29149@utopia.booyaka.com>
 <5162B019.6050407@ti.com>
 <alpine.DEB.2.00.1304081617470.32105@utopia.booyaka.com>
Message-ID: <alpine.DEB.2.00.1304081704380.32105@utopia.booyaka.com>

On Mon, 8 Apr 2013, Paul Walmsley wrote:

> On Mon, 8 Apr 2013, Kishon Vijay Abraham I wrote:
> 
> > On Wednesday 13 February 2013 01:58 AM, Paul Walmsley wrote:
> > > 
> > > Commit 17b7e7d33530e2bbd3bdc90f4db09b91cfdde2bb ("ARM: OMAP4:
> > > clock/hwmod data: start to remove some IP block control "clocks"")
> > > introduced a regression preventing the L3INIT clockdomain of OMAP4
> > > systems from entering idle.  This in turn prevented these systems from
> > > entering full chip clock-stop.
> > > integration hwmod data.
> > 
> > This patch breaks MUSB in OMAP4 panda. The 48M clock is modeled as main clk
> > [1] for ocp2scp so after doing get_sync, this optional clock gets enabled. But
> > after this patch, the optional clock seems to be not enabled after get_sync.
> > 
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2012-September/118285.html
> > (this patch is not directly merged but I guess the discussion here is taken
> > care of)
> 
> The OMAP integration for the MUSB driver needs to clk_enable() and 
> clk_disable() its optional clock.  It's not correct to work around a 
> driver problem by changing the hardware description data - that data is 
> intended to be driver-neutral.

Ugh, took a closer look at this one.  Now I recall what's going on here.  
This is a case where a bit that's clearly marked as an "optional clock" in 
the hardware is really the main functional clock for the IP block.

So I'm open to solving this problem in the integration data as we did 
before, by making ocp2scp_usb_phy_phy_48m the main clock of the 
ocp2scp_usb_phy.  But we need to have a big comment in the hwmod data to 
indicate what's going on here so it doesn't get missed again, since it's 
an inconsistency.  


- Paul


From linux at arm.linux.org.uk  Mon Apr  8 13:09:56 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Mon, 8 Apr 2013 18:09:56 +0100
Subject: [RFC v2] dmaengine: omap-dma: Start DMA without delay for
 cyclic channels
In-Reply-To: <51626D88.8020809@ti.com>
References: <1364987862-14597-1-git-send-email-peter.ujfalusi@ti.com>
 <51626D88.8020809@ti.com>
Message-ID: <20130408170956.GX30923@n2100.arm.linux.org.uk>

On Mon, Apr 08, 2013 at 09:11:04AM +0200, Peter Ujfalusi wrote:
> Russell,
> 
> On 04/03/2013 01:17 PM, Peter Ujfalusi wrote:
> > cyclic DMA is only used by audio which needs DMA to be started without a
> > delay.
> > If the DMA for audio is started using the tasklet we experience random
> > channel switch (to be more precise: channel shift).
> > 
> > Reported-by: Peter Meerwald <pmeerw at pmeerw.net>
> > Signed-off-by: Peter Ujfalusi <peter.ujfalusi at ti.com>
> > ---
> > Hi Russell,
> > 
> > Instead of removing the tasklet we can identify the DMA channel used by audio
> > based on the cyclic flag of the channel.
> > I think this can be used as a short term solution to fix the audio channel shift
> > issue and later when we have the dynamic DMA channel allocation we can adjust
> > the code.
> 
> Could you, please look at this patch?

Now that I'm back from a short 4 day break, then yes, and the answer is
that it's fine.  Who's handling the patch?


From arnd at arndb.de  Mon Apr  8 13:14:30 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 8 Apr 2013 19:14:30 +0200
Subject: [PATCH V5 0/6] USB: EHCI multiplatform for 3.10
In-Reply-To: <20130408164209.GA13694@kroah.com>
References: <1364919844-1726-1-git-send-email-arnd@arndb.de>
 <20130408164209.GA13694@kroah.com>
Message-ID: <201304081914.30266.arnd@arndb.de>

On Monday 08 April 2013, Greg KH wrote:
> On Tue, Apr 02, 2013 at 06:23:58PM +0200, Arnd Bergmann wrote:
> > Hi Greg,
> > 
> > Here are the EHCI patches that I think are good for inclusion in 3.10,
> > I hope you are willing to include them after the debacle over these
> > patches in 3.9.
> > 
> > The patches are all logically independent but sorted by priority,
> > so decide for yourself how many you want to take, starting at the
> > first one. The first six patches all have an Ack from Alan Stern
> > and from the respective ARM platform maintainers.
> 
> I don't see an ACK for the 6th patch from Alan, any reason for that?
> 
> I've applied the first 5 for now, if you want the 6th one applied,
> please resend.

Thanks a lot!

I had mentioned the fact that the last one is missing the ack in my
email, maybe not prominently enough when I wrote:

> > * The final patch is from me and still waiting for an Ack from Alan
> >   Stern, so please wait for his feedback before applying that one.

It would be nice to get that in, but it's not as important for 3.10 since
the only conflict between backends I expect is between Exynos and SPEAr.
SPEAr is not widely used for all I can tell, and whether Exynos actually
makes the multiplatform conversion is still an open question, since there
are a number of missing patches and we are about to close the window for
arm-soc patches as well. In 3.11, things will look quite different.

	Arnd


From tony at atomide.com  Mon Apr  8 13:15:19 2013
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 8 Apr 2013 10:15:19 -0700
Subject: [RFC v2] dmaengine: omap-dma: Start DMA without delay for
 cyclic channels
In-Reply-To: <20130408170956.GX30923@n2100.arm.linux.org.uk>
References: <1364987862-14597-1-git-send-email-peter.ujfalusi@ti.com>
 <51626D88.8020809@ti.com>
 <20130408170956.GX30923@n2100.arm.linux.org.uk>
Message-ID: <20130408171519.GP10155@atomide.com>

* Russell King - ARM Linux <linux at arm.linux.org.uk> [130408 10:15]:
> On Mon, Apr 08, 2013 at 09:11:04AM +0200, Peter Ujfalusi wrote:
> > Russell,
> > 
> > On 04/03/2013 01:17 PM, Peter Ujfalusi wrote:
> > > cyclic DMA is only used by audio which needs DMA to be started without a
> > > delay.
> > > If the DMA for audio is started using the tasklet we experience random
> > > channel switch (to be more precise: channel shift).
> > > 
> > > Reported-by: Peter Meerwald <pmeerw at pmeerw.net>
> > > Signed-off-by: Peter Ujfalusi <peter.ujfalusi at ti.com>
> > > ---
> > > Hi Russell,
> > > 
> > > Instead of removing the tasklet we can identify the DMA channel used by audio
> > > based on the cyclic flag of the channel.
> > > I think this can be used as a short term solution to fix the audio channel shift
> > > issue and later when we have the dynamic DMA channel allocation we can adjust
> > > the code.
> > 
> > Could you, please look at this patch?
> 
> Now that I'm back from a short 4 day break, then yes, and the answer is
> that it's fine.  Who's handling the patch?

I suggest Peter resend the patch with also Grant + Linus W cc:d so
they can queue it unless there are other related patches pending
somewhere else.

Regards,

Tony


From jgunthorpe at obsidianresearch.com  Mon Apr  8 13:19:40 2013
From: jgunthorpe at obsidianresearch.com (Jason Gunthorpe)
Date: Mon, 8 Apr 2013 11:19:40 -0600
Subject: [PATCH v4 1/5] drivers: memory: Introduce Marvell EBU Device Bus
 driver
In-Reply-To: <1365419194-20871-2-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1365419194-20871-1-git-send-email-ezequiel.garcia@free-electrons.com>
 <1365419194-20871-2-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <20130408171940.GA8815@obsidianresearch.com>

Looks OK to me, though with mbus dt bindings we'd see some more
changes.

Just to note on them for future:

> +	child = of_get_next_child(node, NULL);
> +	if (!child) {
> +		dev_err(dev, "%s has no childs\n", node->full_name);
> +		return -EINVAL;
> +	}

This isn't really necessary anymore, the ranges of the node itself
should be parsed to get the window start/end. The driver should never
need to look at the children directly..

> +	/* Get the CS to choose the window string */
> +	err = of_property_read_u32(node, "ranges", &cs);
> +	if (err < 0)
> +		return err;

.. and this is why you've kept the 2 cells address - the top cell is
still encoding the target id. This would go away eventually too..

Maybe it would be better in the interm to compute the CS offset from
the control register offset?

(reg.start % 0x400)/8 should do the trick?

> +	devbus->child = of_platform_device_create(child, NULL, &pdev->dev);
> +	if (!devbus->child) {
> +		dev_warn(dev, "cannot create child device %s\n", child->name);
> +		/* Remove the allocated window */
> +		mvebu_mbus_del_window(devbus->child_mem.start,
> +				      resource_size(&devbus->child_mem));
> +	}

This can probably just be of_platform_populate or similar to do all
children? For instance, I often use many DT nodes to represent a FPGA,
since the my FPGA's tend to have many functionally orthogonal units
inside.

Regards,
Jason


From swarren at wwwdotorg.org  Mon Apr  8 13:24:26 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Mon, 08 Apr 2013 11:24:26 -0600
Subject: Query on pinctrl usage for DT nodes
In-Reply-To: <CA+V-a8t3wtP77DdeUoQHKMjAuWmV+ude+1J3UjJmMTqobgStjA@mail.gmail.com>
References: <CA+V-a8uiPwsAD--OHFAE=i2ed+-wbXm4p2deZXr92+Zv6GDS1w@mail.gmail.com>
 <515C5C76.3080009@wwwdotorg.org>
 <CA+V-a8t3wtP77DdeUoQHKMjAuWmV+ude+1J3UjJmMTqobgStjA@mail.gmail.com>
Message-ID: <5162FD4A.1030909@wwwdotorg.org>

On 04/08/2013 07:12 AM, Prabhakar Lad wrote:
> On Wed, Apr 3, 2013 at 10:14 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
>> On 04/03/2013 03:16 AM, Prabhakar Lad wrote:
>>> Hi Linus/Stephen,
>>>
>>> I am working adding  DT nodes for DA850.
...
>>> But while booting I see the following boot log:-
>>> ...
>>> cpuidle: using governor menu
>>> TCP: cubic registered
>>> NET: Registered protocol family 17
>>> pinctrl-single 1c14120.pinmux: pin 1c14130 already requested by
>>> davinci_mdio.0; cannot claim for i2c_davinci.1
>>> pinctrl-single 1c14120.pinmux: pin-4 (i2c_davinci.1) status -22
>>> pinctrl-single 1c14120.pinmux: could not request pin 4 on device pinctrl-single
>>> console [netcon0] enabled
>>> ....
>>>
>>> This is because the mdio and i2c are using same pin 0x10,
>>
>> How can two devices use the same pin? I mean physically, in hardware?
>>
>> Is this because pinctrl-single uses the register address as the pin
>> number, whereas you have registers which configure multiple pins at
> 
> Yes you are correct, we have registers  which configure multiple pins at once.
> For example for above Pin Multiplexing Control 4 Register (Pinmux4)
> [1] page(250) : -
> 
> PINMUX4_31_28 --> SP1_SCS[2]/UART1_TXD/SATA_CP_POD/GP1[0] Control
> PINMUX4_27_24 --> SPI1_SCS[3]/UART1_RXD/SATA_LED/GP1[1] Control
> PINMUX4_23_20 --> SPI1_SCS[4]/UART2_TXD/I2C1_SDA/GP1[2] Control
> PINMUX4_19_16 --> SPI1_SCS[5]/UART2_RXD/I2C1_SCL/GP1[3] Control
> PINMUX4_15_12 --> SPI1_SCS[6]/I2C0_SDA/TM64P3_OUT12/GP1[4] Control
> PINMUX4_11_8 --> SPI1_SCS[7]/I2C0_SCL/TM64P2_OUT12/GP1[5] Control
> PINMUX4_7_4 --> SPI0_SCS[0]/TM64P1_OUT12/GP1[6]/MDIO_D/TM64P1_IN12 Control
> PINMUX4_3_0 --> SPI0_SCS[1]/TM64P0_OUT12/GP1[7]/MDIO_CLK/TM64P0_IN12 Control
> 
>> once? If so, your hardware isn't something that can be represented by
>> pinctrl-single.
>
> What is the alternative for such case ? any pointer would be helpful.
> 
> [1] http://www.ti.com/general/docs/lit/getliterature.tsp?literatureNumber=spruh77a&fileType=pdf

Tony previously replied:

Tony wrote:
> Tony wrote:
>> ??? wrote:
>>> Prabhakar wrote:
>>>> Is there any
>>>> alternative way to handle if the two node's are using same pins any
>>>> pointers could be very much helpful ?
>>
>> It could also that the mux register(s) follow the one-mux-per-bit
>> mapping.
>>
>> In that case pinctrl-single,bits option as documented in the
>> Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt.
> 
> Oh it's already using pinctrl-single,bits option. Maybe there's a
> bug, adding Peter to cc.

So I guess you need to debug the code to see why that option isn't
working for you.

Going back to your original question above though, if the pinctrl-single
driver doesn't work out for you, then you'd need to create a custom
pinctrl driver for your chip, just like the many examples already in
drivers/pinctrl.


From arnd at arndb.de  Mon Apr  8 13:29:21 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 8 Apr 2013 19:29:21 +0200
Subject: [GIT PULL 1/3] omap usb platform init changes for v3.10 merge
 window
In-Reply-To: <pull-1365104396-577667>
References: <pull-1365104396-577667>
Message-ID: <201304081929.21834.arnd@arndb.de>

On Thursday 04 April 2013, Tony Lindgren wrote:
> b05a674d73e4eb314fa1b6c78e37aef1:
> 
>   usb: phy: nop: Add some parameters to platform data (2013-03-18 11:13:54 +0200)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.10/usb-signed
> 
> for you to fetch changes up to 2e5f78aeceb6f203b514ca03a48e3fd056025524:
> 
>   ARM: dts: omap3-beagle: Add USB Host support (2013-04-02 10:00:04 -0700)
> 
> ----------------------------------------------------------------
> EHCI platform data related changes for v3.10 merge window.
> These are needed for the USB PHY support, and are based on
> commit 1f0972f5 from Felipe Balbi's tree as agreed on the
> mailing lists.

Pulled into next/drivers branch.

	Arnd


From tony at atomide.com  Mon Apr  8 13:29:37 2013
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 8 Apr 2013 10:29:37 -0700
Subject: [RFC PATCH 3/3] ARM: OMAP2+: Add command line parameter for
 debugSS module control
In-Reply-To: <1362396957-30113-4-git-send-email-hvaibhav@ti.com>
References: <hvaibhav@ti.com>
 <1362396957-30113-4-git-send-email-hvaibhav@ti.com>
Message-ID: <20130408172936.GQ10155@atomide.com>

Hi,

* hvaibhav at ti.com <hvaibhav at ti.com> [130304 03:40]:
> From: Vaibhav Hiremath <hvaibhav at ti.com>
> 
> Currently there is no clean mechanism to control debugSS module and
> you have to always keep clocks enabled, either,
> 
>     - By enabling it during boot as part of clk_init function.
>     Or
>     - By having HWMOD_INIT_NO_IDLE flag in hwmod data.
> 
> Based on the discussion,
> http://www.mail-archive.com/linux-omap at vger.kernel.org/msg81771.html
> 
> This patch introduces new kernel parameter "omap_debugss_en",
> which will allow user to control debugSS module enable/disable
> part during boot-time.

I suggest you just make this part into a standard DT only
device driver. That way the command line parsing and clock
enabling can happen the normal way.

Is there any reason why this could not be a loadable module?

Regards,

Tony
 
> Signed-off-by: Vaibhav Hiremath <hvaibhav at ti.com>
> Cc: Kevin Hilman <khilman at linaro.org>
> Cc: Paul Walmsley <paul at pwsan.com>
> Cc: Tony Lindgren <tony at atomide.com>
> ---
> Tested on
> 	- AM335x based EVM and BeagleBone platforms
> 
>  Documentation/kernel-parameters.txt |    3 +
>  arch/arm/mach-omap2/Makefile        |    2 +-
>  arch/arm/mach-omap2/debugss.c       |   80 +++++++++++++++++++++++++++++++++++
>  3 files changed, 84 insertions(+), 1 deletions(-)
>  create mode 100644 arch/arm/mach-omap2/debugss.c
> 
> diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
> index 6c72381..bf1c822 100644
> --- a/Documentation/kernel-parameters.txt
> +++ b/Documentation/kernel-parameters.txt
> @@ -2051,6 +2051,9 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
>  			For example, to override I2C bus2:
>  			omap_mux=i2c2_scl.i2c2_scl=0x100,i2c2_sda.i2c2_sda=0x100
> 
> +	omap_debugss_en	[OMAP] Enable Debug Sub-System module required
> +			for JTAG debugging.
> +
>  	oprofile.timer=	[HW]
>  			Use timer interrupt instead of performance counters
> 
> diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
> index d1156cf..aaf5cc2 100644
> --- a/arch/arm/mach-omap2/Makefile
> +++ b/arch/arm/mach-omap2/Makefile
> @@ -5,7 +5,7 @@
>  # Common support
>  obj-y := id.o io.o control.o mux.o devices.o fb.o serial.o gpmc.o timer.o pm.o \
>  	 common.o gpio.o dma.o wd_timer.o display.o i2c.o hdq1w.o omap_hwmod.o \
> -	 omap_device.o sram.o
> +	 omap_device.o sram.o debugss.o
> 
>  omap-2-3-common				= irq.o
>  hwmod-common				= omap_hwmod.o \
> diff --git a/arch/arm/mach-omap2/debugss.c b/arch/arm/mach-omap2/debugss.c
> new file mode 100644
> index 0000000..b45bf2c
> --- /dev/null
> +++ b/arch/arm/mach-omap2/debugss.c
> @@ -0,0 +1,80 @@
> +/*
> + * debugss.c: Debug Sus-System related code goes in here
> + *
> + * Copyright (C) {2013} Texas Instruments Incorporated - http://www.ti.com/
> + *
> + * This file is automatically generated from the AM33XX hardware databases.
> + * 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 version 2.
> + *
> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
> + * kind, whether express or implied; without even the implied warranty
> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include <linux/init.h>
> +#include <linux/err.h>
> +#include <linux/clk.h>
> +
> +#include "omap_hwmod.h"
> +
> +static bool is_debugss_en;
> +
> +/**
> + * omap_debugss_en - Enable debugss clock/module based on user config
> + *
> + * During kernel bootup, omap2 hwmod framework will disable all the
> + * unused/unclaimed modules, which in turn also disables debugss module.
> + * This breaks any further debugging capability provided by HW.
> + *
> + *
> + * Introduce early param which allows user to enable clock/module -
> + *
> + *   omap_debugss_en	(For all OMAP2 architectures)
> + *
> + * Please note that, with this command-line param, module always remain
> + * enabled.
> + */
> +static int __init omap_debugss_en(char *str)
> +{
> +	is_debugss_en = true;
> +	return 0;
> +}
> +early_param("omap_debugss_en", omap_debugss_en);
> +
> +static int __init _omap2_debugss_enable(void)
> +{
> +	const char oh_name[10] = "debugss";
> +	struct omap_hwmod *oh;
> +	int ret;
> +
> +	if (is_debugss_en) {
> +		struct omap_hwmod_opt_clk *oc;
> +		int i;
> +
> +		oh = omap_hwmod_lookup(oh_name);
> +		if (!oh) {
> +			pr_err("debugss device not found\n");
> +			return 0;
> +		}
> +
> +		/* Make sure that hwmod internal data structures are setup */
> +		ret = omap_hwmod_setup_one(oh_name);
> +		if (ret) {
> +			pr_err("failed to setup hwmod for %s\n", oh_name);
> +			return 0;
> +		}
> +		/* Enable optional clocks */
> +		for (i = oh->opt_clks_cnt, oc = oh->opt_clks; i > 0; i--, oc++)	{
> +			if (oc->_clk)
> +				clk_prepare_enable(oc->_clk);
> +		}
> +		/* Enable debugss clock/module  */
> +		omap_hwmod_enable(oh);
> +	}
> +
> +	return 0;
> +}
> +device_initcall(_omap2_debugss_enable);
> --
> 1.7.0.4
> 


From tony at atomide.com  Mon Apr  8 13:30:53 2013
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 8 Apr 2013 10:30:53 -0700
Subject: [RFC PATCH 0/3] ARM: OMAP2+: Add command line parameter for
 debugSS module control
In-Reply-To: <79CD15C6BA57404B839C016229A409A83EC281C1@DBDE01.ent.ti.com>
References: <hvaibhav@ti.com>
 <1362396957-30113-1-git-send-email-hvaibhav@ti.com>
 <79CD15C6BA57404B839C016229A409A83EC281C1@DBDE01.ent.ti.com>
Message-ID: <20130408173052.GR10155@atomide.com>

* Hiremath, Vaibhav <hvaibhav at ti.com> [130314 04:33]:
> > From: Hiremath, Vaibhav
> > This patch introduces new kernel parameter "omap_debugss_en",
> > which will allow user to control debugSS module enable/disable
> > part during boot-time.
> > 
> > In case of OMAP3, the debugSS is part of EMU domain and
> > is currently controlled by clock tree alone.
> > 
> > In case of OMAP4, the debugSS is part of EMU domain and
> > is currently controlled by clock tree, as MODULEMODE_SWCTRL
> > is not defined for hwmod.
> > 
> > In case of AM335x, the debugSS is in wakeup domain and is currently
> > controlled through hwmod alone. Currently we keep it always enabled.
> 
> Any comments or input on this patch series?

No comments on adding the clocks, but the enabling of
them should be just a regular device driver.

Regards,

Tony


From arnd at arndb.de  Mon Apr  8 13:36:56 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 8 Apr 2013 19:36:56 +0200
Subject: [GIT PULL 2/3] omap timer changes for v3.10 merge window
In-Reply-To: <0LdWUM-1V6HSB0nzO-00i0Xm@mx.kundenserver.de>
References: <0LdWUM-1V6HSB0nzO-00i0Xm@mx.kundenserver.de>
Message-ID: <201304081936.56288.arnd@arndb.de>

On Thursday 04 April 2013, Tony Lindgren wrote:
> Clean-up for omap2+ timers from Jon Hunter <jon-hunter at ti.com>:
> 
> This series consists mainly of clean-ups for clockevents and
> clocksource timers on OMAP2+ devices. The most significant change
> in functionality comes from the 5th patch which is changing the
> selection of the clocksource timer for OMAP3 and AM335x devices
> when gptimers are used for clocksource.
> 
> Note that this series depends on 7185684 (ARM: OMAP: use
> consistent error checking) in RMK's tree and 960cba6 (ARM:
> OMAP5: timer: Update the clocksource name as per clock data)
> in omap-for-v3.10/fixes-non-critical. So this branch is based
> on a merge of 7185684 and omap-for-v3.10/fixes-non-critical
> to avoid non-trivial merge conflicts.
> 

Pulled into next/drivers, thanks!

Do you have a URL for a stable branch containing 7185684
that we can list in our branch description file?

	Arnd


From mturquette at linaro.org  Mon Apr  8 13:36:28 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Mon, 08 Apr 2013 10:36:28 -0700
Subject: [v5] clk: add si5351 i2c common clock driver
In-Reply-To: <CABJ1b_T30trVjXps-rSbYTNo1DcPeT8WsZ+M18B9wTJPBnL-gA@mail.gmail.com>
References: <1365139415-17815-1-git-send-email-sebastian.hesselbarth@gmail.com>
 <20130407225046.GA16326@roeck-us.net> <51620604.4070204@gmail.com>
 <20130408001725.GA16648@roeck-us.net> <51625F9A.1050308@gmail.com>
 <20130408145407.GA12243@roeck-us.net>
 <CABJ1b_T30trVjXps-rSbYTNo1DcPeT8WsZ+M18B9wTJPBnL-gA@mail.gmail.com>
Message-ID: <20130408173628.14359.70620@quantum>

Quoting Sebastian Hesselbarth (2013-04-08 08:38:44)
> On Mon, Apr 8, 2013 at 4:54 PM, Guenter Roeck <linux at roeck-us.net> wrote:
> > On Mon, Apr 08, 2013 at 08:11:38AM +0200, Sebastian Hesselbarth wrote:
> >> On 04/08/2013 02:17 AM, Guenter Roeck wrote:
> >> >On Mon, Apr 08, 2013 at 01:49:24AM +0200, Sebastian Hesselbarth wrote:
> >> >>On 04/08/2013 12:50 AM, Guenter Roeck wrote:
> >> >>>On Fri, Apr 05, 2013 at 05:23:35AM -0000, Sebastian Hesselbarth wrote:
> >> >>>>This patch adds a common clock driver for Silicon Labs Si5351a/b/c
> >> >>>>i2c programmable clock generators. Currently, the driver supports
> >> >>>>DT kernels only and VXCO feature of si5351b is not implemented. DT
> >> >>>>bindings selectively allow to overwrite stored Si5351 configuration
> >> >>>>which is very helpful for clock generators with empty eeprom
> >> >>>>configuration. Corresponding device tree binding documentation is
> >> >>>>also added.
> >> >>>>
> >> >>>>Signed-off-by: Sebastian Hesselbarth<sebastian.hesselbarth at gmail.com>
> >> >>>>Tested-by: Daniel Mack<zonque at gmail.com>
> >> >>>>
> >> >>>[ ... ]
> >> >>>
> >> >>>>+static inline void _si5351_msynth_set_pll_master(
> >> >>>>+ struct si5351_driver_data *drvdata, unsigned char num, int is_master)
> >> >>>>+{
> >> >>>>+ unsigned long flags;
> >> >>>>+
> >> >>>>+ if (num>   8 ||
> >> >>>>+     (drvdata->variant == SI5351_VARIANT_A3&&   num>   3))
> >> >>>>+         return;
> >> >>>>+
> >> >>>>+ flags = __clk_get_flags(drvdata->msynth[num].hw.clk);
> >> >>>>+ if (is_master)
> >> >>>>+         flags |= CLK_SET_RATE_PARENT;
> >> >>>>+ else
> >> >>>>+         flags&= ~CLK_SET_RATE_PARENT;
> >> >>>>+ __clk_set_flags(drvdata->msynth[num].hw.clk, flags);
> >> >>>>+}
> >> >>>>+
> >> >>>Unless I am missing something, neither __clk_get_flags() nor the new
> >> >>>__clk_set_flags is exported.
> >> >>>
> >> >>>Did you try to build and load the driver as module ?
> >> >>
> >> >>Well, good catch. I didn't try to build v5 as a module, but I guess it
> >> >>will fail. But I consider this as something that has to be addressed in
> >> >>clk framework itself, not in this patch. There will be other
> >> >>clk-providers built as module in the future for sure.
> >> >>
> >> >Sure, but you provided the patch to make __clk_set_flags global. To avoid
> >> >build failures, I would suggest to either submit a patch to export the
> >> >missing functions, or to remove the ability to build the driver as module.
> >>
> >> Actually, I knew that __clk_set_flags patch will not be accepted
> >> before posting it ;)
> >>
> > Ah, but part of that is to get you to think about it again, and to defend it if
> > it is really needed. After all, "it can be abused" applies to pretty much every
> > API.
> 
> Guenter,
> 
> I already thought about it a lot and I consider clk api broken in a way here.
> 
> > Key question is if you _really_ need run-time flag modifications, or if you can
> > live with initialization-time settings. If you really need it, you'll have to
> > explain the reasons.
> 
> The question is not if _I_ really need run-time flags but why the api allows to
> perform run-time modifications of the clock hierarchy without allowing different
> flags? There is clk_set_parent() so I guess clk api knows about run-time changes
> already, but you cannot have different flags per parent. And with
> __clk_set_flags()
> rejected, you are not allowed to change the flags.
> 
> I understand that some flags are permanent and required at registration, but
> CLK_SET_PARENT_RATE is not. It is not limited by hardware but limited by api.
> One way would be a more generic clk-mux with per parent flags, but for
> the current
> implementation, I cannot see how clk-mux can be exploited here.
> 

There are a couple of ways to get past this issue.  One is removal of
some of the flags.  I have never liked CLK_SET_RATE_PARENT, since I
think the ability to propagate a rate-change request up to the parent
should be enabled for all clocks.  This is in the interest of the driver
author who does not care to know intimate details of the clock
hierarchy.

When I developed the rate-change propagation code I was likely too hasty
in defining a per-clock flag for that behavior.  It might have been
enough to simply compare the &best_parent_rate value from .round_rate
and compare it against clk->parent->rate.  This means that no flag is
necessary.

This assumes that the .round_rate implementation has enough knowledge to
know whether or not to propagate the rate-change request up to the
parent.  This may not not true for the common divider type.

I'll make some tests on removing this flag (and potentially other flags)
to see how painful it is.

Regards,
Mike

> I can live with it, because then dynamic muxing of clock hierarchy
> within clk-si5351
> is just not supported or will break function. Currently, there is no
> support for dynamic
> muxing, so everything is fine.
> 
> >> >On a side note, do you happen to know anyone working on drivers for Si5319 or
> >> >Si5368 ?
> >>
> >> No.
> >
> > Too bad ... I may have to write that code myself then.
> 
> Well, if clk-si5351 will ever get in mainline kernel, feel free to use
> it as a template ;)
> 
> Sebastian


From arnd at arndb.de  Mon Apr  8 13:40:12 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 8 Apr 2013 19:40:12 +0200
Subject: [GIT PULL 2/3] omap timer changes for v3.10 merge window
In-Reply-To: <0LdWUM-1V6HSB0nzO-00i0Xm@mx.kundenserver.de>
References: <0LdWUM-1V6HSB0nzO-00i0Xm@mx.kundenserver.de>
Message-ID: <201304081940.12773.arnd@arndb.de>

On Thursday 04 April 2013, Tony Lindgren wrote:
>  arch/arm/mach-omap2/board-cm-t3517.c |   2 +-
>  arch/arm/mach-omap2/board-generic.c  |   2 +-
>  arch/arm/mach-omap2/common.h         |   3 +-
>  arch/arm/mach-omap2/timer.c          | 124 ++++++++++++++++++-----------------
>  4 files changed, 66 insertions(+), 65 deletions(-)

BTW, do you have any plans to move the timer.c file to drivers/clocksource?

I think that's where most of them are heading now.

	Arnd


From gregkh at linuxfoundation.org  Mon Apr  8 13:40:16 2013
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Mon, 8 Apr 2013 10:40:16 -0700
Subject: [PATCH 0/7] i.MX53 IPU + TVE patches
In-Reply-To: <1365437078-22579-1-git-send-email-p.zabel@pengutronix.de>
References: <1365437078-22579-1-git-send-email-p.zabel@pengutronix.de>
Message-ID: <20130408174016.GB30036@kroah.com>

On Mon, Apr 08, 2013 at 06:04:31PM +0200, Philipp Zabel wrote:
> Hi,
> 
> the following patches allow to use the integrated Television Encoder
> (TVEv2) on the i.MX53 SoC as VGA output encoder for the IPU. This is
> useful for the Freescale i.MX53-QSB and TQ MBa53 boards, which have
> VGA and DVI-I connectors, respectively.
> 
> regards
> Philipp
> 
> ---
>  drivers/staging/imx-drm/Kconfig             |   7 +
>  drivers/staging/imx-drm/Makefile            |   1 +
>  drivers/staging/imx-drm/imx-drm-core.c      |  15 +-
>  drivers/staging/imx-drm/imx-drm.h           |  14 +-
>  drivers/staging/imx-drm/imx-tve.c           | 755 ++++++++++++++++++++++++++++
>  drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h |   3 +
>  drivers/staging/imx-drm/ipu-v3/ipu-dc.c     |  55 +-
>  drivers/staging/imx-drm/ipu-v3/ipu-di.c     | 100 +++-
>  drivers/staging/imx-drm/ipuv3-crtc.c        |  11 +-
>  9 files changed, 932 insertions(+), 29 deletions(-)

That's a lot of new features being added here, yet no work seems to be
happening to move this out of the staging tree.  What is left to do
here, and why isn't that being worked on first, before stuff like this?

thanks,

greg k-h


From daniel.lezcano at linaro.org  Mon Apr  8 13:40:37 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Mon, 08 Apr 2013 19:40:37 +0200
Subject: [PATCH 7/9] intel: cpuidle: remove stop/start critical timings
In-Reply-To: <5161DC9C.3020703@linaro.org>
References: <1364991322-20585-1-git-send-email-daniel.lezcano@linaro.org>
 <1364991322-20585-7-git-send-email-daniel.lezcano@linaro.org>
 <3375360.P4DAA9Jd5Y@vostro.rjw.lan> <5161DC9C.3020703@linaro.org>
Message-ID: <51630115.6040205@linaro.org>

On 04/07/2013 10:52 PM, Daniel Lezcano wrote:
> On 04/05/2013 12:31 AM, Rafael J. Wysocki wrote:
>> On Wednesday, April 03, 2013 02:15:20 PM Daniel Lezcano wrote:
>>> The start/stop_critical_timings are called from arch/x86/kernel/process.c
>>> in the cpu_idle loop function.
>>>
>>> Remove the ones in the cpuidle driver.
>>>
>>> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
>> For this one I need an ACK from Len.
>>
>> Len, any objections?
>
> Len ? ping ...

Rafael,

this patch is not dependent from any patch in the series, is it possible
you apply the patchset except this patch ?

May be you can apply it later when Len acks it, or I can resend it, no ?

I have a lot of code consolidation patches awaiting for this patchset to
be merged.

Thanks
  -- Daniel

> ---
>  drivers/idle/intel_idle.c |    3 ---
>  1 file changed, 3 deletions(-)
>
> diff --git a/drivers/idle/intel_idle.c b/drivers/idle/intel_idle.c
> index 5d66750..c99c31e 100644
> --- a/drivers/idle/intel_idle.c
> +++ b/drivers/idle/intel_idle.c
> @@ -339,7 +339,6 @@ static int intel_idle(struct cpuidle_device *dev,
>  	if (!(lapic_timer_reliable_states & (1 << (cstate))))
>  		clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &cpu);
>  
> -	stop_critical_timings();
>  	if (!need_resched()) {
>  
>  		__monitor((void *)&current_thread_info()->flags, 0, 0);
> @@ -348,8 +347,6 @@ static int intel_idle(struct cpuidle_device *dev,
>  			__mwait(eax, ecx);
>  	}
>  
> -	start_critical_timings();
> -
>  	if (!(lapic_timer_reliable_states & (1 << (cstate))))
>  		clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &cpu);
>  
>
>


-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From linux at roeck-us.net  Mon Apr  8 13:46:36 2013
From: linux at roeck-us.net (Guenter Roeck)
Date: Mon, 8 Apr 2013 10:46:36 -0700
Subject: [PATCH v6] clk: add si5351 i2c common clock driver
In-Reply-To: <1365439617-18816-1-git-send-email-sebastian.hesselbarth@gmail.com>
References: <1365139415-17815-1-git-send-email-sebastian.hesselbarth@gmail.com>
 <1365439617-18816-1-git-send-email-sebastian.hesselbarth@gmail.com>
Message-ID: <20130408174636.GA1885@roeck-us.net>

On Mon, Apr 08, 2013 at 06:46:57PM +0200, Sebastian Hesselbarth wrote:
> This patch adds a common clock driver for Silicon Labs Si5351a/b/c
> i2c programmable clock generators. Currently, the driver does not
> support VXCO feature of si5351b. Passing platform_data or DT bindings
> selectively allow to overwrite stored Si5351 configuration which is
> very helpful for clock generators with empty eeprom configuration.
> Corresponding device tree binding documentation is also added.
> 
> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>

[ ... ]

> +
> +/*
> + * Si5351 i2c probe and DT
> + */
> +#ifdef CONFIG_OF
> +static const struct of_device_id si5351_dt_ids[] = {
> +	{ .compatible = "silabs,si5351a", .data = (void *)SI5351_VARIANT_A, },
> +	{ .compatible = "silabs,si5351a-msop",
> +					 .data = (void *)SI5351_VARIANT_A3, },
> +	{ .compatible = "silabs,si5351b", .data = (void *)SI5351_VARIANT_B, },
> +	{ .compatible = "silabs,si5351c", .data = (void *)SI5351_VARIANT_C, },
> +	{ }
> +};
> +MODULE_DEVICE_TABLE(of, si5351_dt_ids);
> +
> +static int si5351_dt_parse(struct i2c_client *client)
> +{
> +	struct device_node *child, *np = client->dev.of_node;
> +	struct si5351_platform_data *pdata;
> +	const struct of_device_id *match;
> +	struct property *prop;
> +	const __be32 *p;
> +	int num = 0;
> +	u32 val;
> +
> +	if (np == NULL)
> +		return 0;
> +
> +	match = of_match_node(si5351_dt_ids, np);
> +	if (match == NULL)
> +		return -EINVAL;
> +
> +	pdata = devm_kzalloc(&client->dev, sizeof(*pdata), GFP_KERNEL);
> +	if (!pdata)
> +		return -ENOMEM;
> +
> +	pdata->variant = (enum si5351_variant)match->data;
> +	pdata->clk_xtal = of_clk_get(np, 0);
> +	if (!IS_ERR(pdata->clk_xtal))
> +		clk_put(pdata->clk_xtal);
> +	pdata->clk_clkin = of_clk_get(np, 1);
> +	if (!IS_ERR(pdata->clk_clkin))
> +		clk_put(pdata->clk_clkin);
> +
> +	/*
> +	 * property silabs,pll-source : <num src>, [<..>]
> +	 * allow to selectively set pll source
> +	 */
> +	of_property_for_each_u32(np, "silabs,pll-source", prop, p, num) {
> +		if (num >= 2) {
> +			dev_err(&client->dev,
> +				"invalid pll %d on pll-source prop\n", num);
> +			break;

You report dev_err here, but you don't return an error to the caller.
Is this on purpose ? If it is not a fatal error, maybe it should be dev_info ?

> +		}
> +
> +		p = of_prop_next_u32(prop, p, &val);
> +		if (!p)
> +			break;
> +
> +		switch (val) {
> +		case 0:
> +			pdata->pll_src[num] = SI5351_PLL_SRC_XTAL;
> +			break;
> +		case 1:
> +			pdata->pll_src[num] = SI5351_PLL_SRC_CLKIN;
> +			break;
> +		default:
> +			dev_warn(&client->dev,
> +				 "invalid parent %d for pll %d\n", val, num);
> +			continue;

Same here, and a couple of times below. Given the context, I think it would
be better if the error cases would return an error. After all, the condition
suggests that the device tree data is wrong, meaning one has to assume it
won't work anyway and should be fixed in the device tree and not be ignored
by the driver.

> +		}
> +	}
> +
> +	/* per clkout properties */
> +	num = of_get_child_count(np);
> +
> +	if (num == 0)
> +		return 0;
> +

This doesn't set client->dev.platform_data yet returns no error, meaning the
calling code will either use provided platform data or fail after all if it is
NULL. That seems to be inconsistent, given that a dt entry was already detected.
The user might end up wondering why the provided device tree data is not used,
not realizing that it is incomplete.

If children are not mandatory, you could just drop the code above and go through
for_each_child_of_node() anyway; it won't do anything and set
client->dev.platform_data at the end. If children are mandatory, it might make
sense to return an eror here (if there is dt information, it should be complete
and consistent).

> +	for_each_child_of_node(np, child) {
> +		if (of_property_read_u32(child, "reg", &num)) {
> +			dev_err(&client->dev, "missing reg property of %s\n",
> +				child->name);
> +			continue;
> +		}
> +
What if "num" returns 100 ? Or 1000 ?

> +		if (!of_property_read_u32(child, "silabs,multisynth-source",
> +					  &val)) {
> +			switch (val) {
> +			case 0:
> +				pdata->clkout[num].multisynth_src =
> +					SI5351_MULTISYNTH_SRC_VCO0;
> +				break;
> +			case 1:
> +				pdata->clkout[num].multisynth_src =
> +					SI5351_MULTISYNTH_SRC_VCO1;
> +				break;
> +			default:
> +				dev_warn(&client->dev,
> +					 "invalid parent %d for multisynth %d\n",
> +					 val, num);
> +			}
> +		}
> +
> +		if (!of_property_read_u32(child, "silabs,clock-source", &val)) {
> +			switch (val) {
> +			case 0:
> +				pdata->clkout[num].clkout_src =
> +					SI5351_CLKOUT_SRC_MSYNTH_N;
> +				break;
> +			case 1:
> +				pdata->clkout[num].clkout_src =
> +					SI5351_CLKOUT_SRC_MSYNTH_0_4;
> +				break;
> +			case 2:
> +				pdata->clkout[num].clkout_src =
> +					SI5351_CLKOUT_SRC_XTAL;
> +				break;
> +			case 3:
> +				pdata->clkout[num].clkout_src =
> +					SI5351_CLKOUT_SRC_CLKIN;
> +				break;
> +			default:
> +				dev_warn(&client->dev,
> +					 "invalid parent %d for clkout %d\n",
> +					 val, num);
> +			}
> +		}
> +
> +		if (!of_property_read_u32(child, "silabs,drive-strength",
> +					  &val)) {
> +			switch (val) {
> +			case SI5351_DRIVE_2MA:
> +			case SI5351_DRIVE_4MA:
> +			case SI5351_DRIVE_6MA:
> +			case SI5351_DRIVE_8MA:
> +				pdata->clkout[num].drive = val;
> +				break;
> +			default:
> +				dev_warn(&client->dev,
> +					 "invalid drive strength %d for clkout %d\n",
> +					 val, num);
> +			}
> +		}
> +
> +		if (!of_property_read_u32(child, "clock-frequency", &val))
> +			pdata->clkout[num].rate = val;
> +
> +		pdata->clkout[num].pll_master =
> +			of_property_read_bool(child, "silabs,pll-master");
> +	}
> +
> +	client->dev.platform_data = pdata;
> +
> +	return 0;
> +}
> +#else
> +static int si5351_dt_parse(struct i2c_client *client)
> +{
> +	return 0;
> +}
> +#endif /* CONFIG_OF */
> +
> +static int si5351_i2c_probe(struct i2c_client *client,
> +			    const struct i2c_device_id *id)
> +{
> +	struct si5351_platform_data *pdata;
> +	struct si5351_driver_data *drvdata;
> +	struct clk_init_data init;
> +	struct clk *clk;
> +	const char *parent_names[4];
> +	u8 num_parents, num_clocks;
> +	int ret, n;
> +
> +	ret = si5351_dt_parse(client);
> +	if (ret)
> +		return ret;
> +
> +	pdata = client->dev.platform_data;
> +	if (!pdata)
> +		return -EINVAL;
> +
> +	drvdata = devm_kzalloc(&client->dev, sizeof(*drvdata), GFP_KERNEL);
> +	if (drvdata == NULL) {
> +		dev_err(&client->dev, "unable to allocate driver data\n");
> +		return -ENOMEM;
> +	}
> +
> +	i2c_set_clientdata(client, drvdata);
> +	drvdata->client = client;
> +	drvdata->variant = pdata->variant;
> +	drvdata->pxtal = pdata->clk_xtal;
> +	drvdata->pclkin = pdata->clk_clkin;
> +
> +	drvdata->regmap = devm_regmap_init_i2c(client, &si5351_regmap_config);
> +	if (IS_ERR(drvdata->regmap)) {
> +		dev_err(&client->dev, "failed to allocate register map\n");
> +		return PTR_ERR(drvdata->regmap);
> +	}
> +
> +	/* Disable interrupts */
> +	si5351_reg_write(drvdata, SI5351_INTERRUPT_MASK, 0xf0);
> +	/* Set disabled output drivers to drive low */
> +	si5351_reg_write(drvdata, SI5351_CLK3_0_DISABLE_STATE, 0x00);
> +	si5351_reg_write(drvdata, SI5351_CLK7_4_DISABLE_STATE, 0x00);
> +	/* Ensure pll select is on XTAL for Si5351A/B */
> +	if (drvdata->variant != SI5351_VARIANT_C)
> +		si5351_set_bits(drvdata, SI5351_PLL_INPUT_SOURCE,
> +				SI5351_PLLA_SOURCE | SI5351_PLLB_SOURCE, 0);
> +
> +	/* setup clock configuration */
> +	for (n = 0; n < 2; n++)
> +		_si5351_pll_reparent(drvdata, n, pdata->pll_src[n]);
> +
> +	for (n = 0; n < 8; n++) {
> +		_si5351_msynth_reparent(drvdata, n,
> +					pdata->clkout[n].multisynth_src);
> +		_si5351_clkout_reparent(drvdata, n,
> +					pdata->clkout[n].clkout_src);
> +		_si5351_clkout_set_drive_strength(drvdata, n,
> +					pdata->clkout[n].drive);
> +	}
> +
> +	/* register xtal input clock gate */
> +	memset(&init, 0, sizeof(init));
> +	init.name = si5351_input_names[0];
> +	init.ops = &si5351_xtal_ops;
> +	init.flags = 0;
> +	if (!IS_ERR(drvdata->pxtal)) {
> +		drvdata->pxtal_name = __clk_get_name(drvdata->pxtal);
> +		init.parent_names = &drvdata->pxtal_name;
> +		init.num_parents = 1;
> +	}
> +	drvdata->xtal.init = &init;
> +	clk = devm_clk_register(&client->dev, &drvdata->xtal);
> +	if (IS_ERR(clk)) {
> +		dev_err(&client->dev, "unable to register %s\n", init.name);
> +		return PTR_ERR(clk);
> +	}
> +
> +	/* register clkin input clock gate */
> +	if (drvdata->variant == SI5351_VARIANT_C) {
> +		memset(&init, 0, sizeof(init));
> +		init.name = si5351_input_names[1];
> +		init.ops = &si5351_clkin_ops;
> +		if (!IS_ERR(drvdata->pclkin)) {
> +			drvdata->pclkin_name = __clk_get_name(drvdata->pclkin);
> +			init.parent_names = &drvdata->pclkin_name;
> +			init.num_parents = 1;
> +		}
> +		drvdata->clkin.init = &init;
> +		clk = devm_clk_register(&client->dev, &drvdata->clkin);
> +		if (IS_ERR(clk)) {
> +			dev_err(&client->dev, "unable to register %s\n",
> +				init.name);
> +			return PTR_ERR(clk);
> +		}
> +	}
> +
> +	/* Si5351C allows to mux either xtal or clkin to PLL input */
> +	num_parents = (drvdata->variant == SI5351_VARIANT_C) ? 2 : 1;
> +	parent_names[0] = si5351_input_names[0];
> +	parent_names[1] = si5351_input_names[1];
> +
> +	/* register PLLA */
> +	drvdata->pll[0].num = 0;
> +	drvdata->pll[0].drvdata = drvdata;
> +	drvdata->pll[0].hw.init = &init;
> +	memset(&init, 0, sizeof(init));
> +	init.name = si5351_pll_names[0];
> +	init.ops = &si5351_pll_ops;
> +	init.flags = 0;
> +	init.parent_names = parent_names;
> +	init.num_parents = num_parents;
> +	clk = devm_clk_register(&client->dev, &drvdata->pll[0].hw);
> +	if (IS_ERR(clk)) {
> +		dev_err(&client->dev, "unable to register %s\n", init.name);
> +		return -EINVAL;
> +	}
> +
> +	/* register PLLB or VXCO (Si5351B) */
> +	drvdata->pll[1].num = 1;
> +	drvdata->pll[1].drvdata = drvdata;
> +	drvdata->pll[1].hw.init = &init;
> +	memset(&init, 0, sizeof(init));
> +	if (drvdata->variant == SI5351_VARIANT_B) {
> +		init.name = si5351_pll_names[2];
> +		init.ops = &si5351_vxco_ops;
> +		init.flags = CLK_IS_ROOT;
> +		init.parent_names = NULL;
> +		init.num_parents = 0;
> +	} else {
> +		init.name = si5351_pll_names[1];
> +		init.ops = &si5351_pll_ops;
> +		init.flags = 0;
> +		init.parent_names = parent_names;
> +		init.num_parents = num_parents;
> +	}
> +	clk = devm_clk_register(&client->dev, &drvdata->pll[1].hw);
> +	if (IS_ERR(clk)) {
> +		dev_err(&client->dev, "unable to register %s\n", init.name);
> +		return -EINVAL;
> +	}
> +
> +	/* register clk multisync and clk out divider */
> +	num_clocks = (drvdata->variant == SI5351_VARIANT_A3) ? 3 : 8;
> +	parent_names[0] = si5351_pll_names[0];
> +	if (drvdata->variant == SI5351_VARIANT_B)
> +		parent_names[1] = si5351_pll_names[2];
> +	else
> +		parent_names[1] = si5351_pll_names[1];
> +
> +	drvdata->msynth = devm_kzalloc(&client->dev, num_clocks *
> +				       sizeof(*drvdata->msynth), GFP_KERNEL);
> +	drvdata->clkout = devm_kzalloc(&client->dev, num_clocks *
> +				       sizeof(*drvdata->clkout), GFP_KERNEL);
> +
> +	drvdata->onecell.clk_num = num_clocks;
> +	drvdata->onecell.clks = devm_kzalloc(&client->dev,
> +		num_clocks * sizeof(*drvdata->onecell.clks), GFP_KERNEL);
> +
> +	if (WARN_ON(!drvdata->msynth || !drvdata->clkout ||
> +		    !drvdata->onecell.clks))
> +		return -ENOMEM;
> +
> +	for (n = 0; n < num_clocks; n++) {
> +		drvdata->msynth[n].num = n;
> +		drvdata->msynth[n].drvdata = drvdata;
> +		drvdata->msynth[n].hw.init = &init;
> +		memset(&init, 0, sizeof(init));
> +		init.name = si5351_msynth_names[n];
> +		init.ops = &si5351_msynth_ops;
> +		init.flags = 0;
> +		if (pdata->clkout[n].pll_master)
> +			init.flags |= CLK_SET_RATE_PARENT;
> +		init.parent_names = parent_names;
> +		init.num_parents = 2;
> +		clk = devm_clk_register(&client->dev, &drvdata->msynth[n].hw);
> +		if (IS_ERR(clk)) {
> +			dev_err(&client->dev, "unable to register %s\n",
> +				init.name);
> +			return -EINVAL;
> +		}
> +	}
> +
> +	num_parents = (drvdata->variant == SI5351_VARIANT_C) ? 4 : 3;
> +	parent_names[2] = si5351_input_names[0];
> +	parent_names[3] = si5351_input_names[1];
> +	for (n = 0; n < num_clocks; n++) {
> +		parent_names[0] = si5351_msynth_names[n];
> +		parent_names[1] = (n < 4) ? si5351_msynth_names[0] :
> +			si5351_msynth_names[4];
> +
> +		drvdata->clkout[n].num = n;
> +		drvdata->clkout[n].drvdata = drvdata;
> +		drvdata->clkout[n].hw.init = &init;
> +		memset(&init, 0, sizeof(init));
> +		init.name = si5351_clkout_names[n];
> +		init.ops = &si5351_clkout_ops;
> +		init.flags = 0;
> +		if (pdata->clkout[n].clkout_src == SI5351_CLKOUT_SRC_MSYNTH_N)
> +			init.flags |= CLK_SET_RATE_PARENT;
> +		init.parent_names = parent_names;
> +		init.num_parents = num_parents;
> +		clk = devm_clk_register(&client->dev, &drvdata->clkout[n].hw);
> +		if (IS_ERR(clk)) {
> +			dev_err(&client->dev, "unable to register %s\n",
> +				init.name);
> +			return -EINVAL;
> +		}
> +		drvdata->onecell.clks[n] = clk;
> +	}
> +
> +	ret = of_clk_add_provider(client->dev.of_node, of_clk_src_onecell_get,
> +				  &drvdata->onecell);
> +	if (ret) {
> +		dev_err(&client->dev, "unable to add clk provider\n");
> +		return ret;
> +	}
> +
> +	return 0;
> +}
> +
> +static const struct i2c_device_id si5351_i2c_ids[] = {
> +	{ "silabs,si5351", 0 },
> +	{ }
> +};
> +MODULE_DEVICE_TABLE(i2c, si5351_i2c_ids);
> +
> +static struct i2c_driver si5351_driver = {
> +	.driver = {
> +		.name = "si5351",
> +		.of_match_table = of_match_ptr(si5351_dt_ids),
> +	},
> +	.probe = si5351_i2c_probe,
> +	.id_table = si5351_i2c_ids,
> +};
> +module_i2c_driver(si5351_driver);
> +
> +MODULE_AUTHOR("Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com");
> +MODULE_DESCRIPTION("Silicon Labs Si5351A/B/C clock generator driver");
> +MODULE_LICENSE("GPL");
> diff --git a/drivers/clk/clk-si5351.h b/drivers/clk/clk-si5351.h
> new file mode 100644
> index 0000000..af41b50
> --- /dev/null
> +++ b/drivers/clk/clk-si5351.h
> @@ -0,0 +1,155 @@
> +/*
> + * clk-si5351.h: Silicon Laboratories Si5351A/B/C I2C Clock Generator
> + *
> + * Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
> + * Rabeeh Khoury <rabeeh at solid-run.com>
> + *
> + * 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.
> + */
> +
> +#ifndef _CLK_SI5351_H_
> +#define _CLK_SI5351_H_
> +
> +#define SI5351_BUS_BASE_ADDR			0x60
> +
> +#define SI5351_PLL_VCO_MIN			600000000
> +#define SI5351_PLL_VCO_MAX			900000000
> +#define SI5351_MULTISYNTH_MIN_FREQ		1000000
> +#define SI5351_MULTISYNTH_DIVBY4_FREQ		150000000
> +#define SI5351_MULTISYNTH_MAX_FREQ		160000000
> +#define SI5351_MULTISYNTH67_MAX_FREQ		SI5351_MULTISYNTH_DIVBY4_FREQ
> +#define SI5351_CLKOUT_MIN_FREQ			8000
> +#define SI5351_CLKOUT_MAX_FREQ			SI5351_MULTISYNTH_MAX_FREQ
> +#define SI5351_CLKOUT67_MAX_FREQ		SI5351_MULTISYNTH67_MAX_FREQ
> +
> +#define SI5351_PLL_A_MIN			15
> +#define SI5351_PLL_A_MAX			90
> +#define SI5351_PLL_B_MAX			(SI5351_PLL_C_MAX-1)
> +#define SI5351_PLL_C_MAX			1048575
> +#define SI5351_MULTISYNTH_A_MIN			6
> +#define SI5351_MULTISYNTH_A_MAX			1800
> +#define SI5351_MULTISYNTH67_A_MAX		254
> +#define SI5351_MULTISYNTH_B_MAX			(SI5351_MULTISYNTH_C_MAX-1)
> +#define SI5351_MULTISYNTH_C_MAX			1048575
> +#define SI5351_MULTISYNTH_P1_MAX		((1<<18)-1)
> +#define SI5351_MULTISYNTH_P2_MAX		((1<<20)-1)
> +#define SI5351_MULTISYNTH_P3_MAX		((1<<20)-1)
> +
> +#define SI5351_DEVICE_STATUS			0
> +#define SI5351_INTERRUPT_STATUS			1
> +#define SI5351_INTERRUPT_MASK			2
> +#define  SI5351_STATUS_SYS_INIT			(1<<7)
> +#define  SI5351_STATUS_LOL_B			(1<<6)
> +#define  SI5351_STATUS_LOL_A			(1<<5)
> +#define  SI5351_STATUS_LOS			(1<<4)
> +#define SI5351_OUTPUT_ENABLE_CTRL		3
> +#define SI5351_OEB_PIN_ENABLE_CTRL		9
> +#define SI5351_PLL_INPUT_SOURCE			15
> +#define  SI5351_CLKIN_DIV_MASK			(3<<6)
> +#define  SI5351_CLKIN_DIV_1			(0<<6)
> +#define  SI5351_CLKIN_DIV_2			(1<<6)
> +#define  SI5351_CLKIN_DIV_4			(2<<6)
> +#define  SI5351_CLKIN_DIV_8			(3<<6)
> +#define  SI5351_PLLB_SOURCE			(1<<3)
> +#define  SI5351_PLLA_SOURCE			(1<<2)
> +
> +#define SI5351_CLK0_CTRL			16
> +#define SI5351_CLK1_CTRL			17
> +#define SI5351_CLK2_CTRL			18
> +#define SI5351_CLK3_CTRL			19
> +#define SI5351_CLK4_CTRL			20
> +#define SI5351_CLK5_CTRL			21
> +#define SI5351_CLK6_CTRL			22
> +#define SI5351_CLK7_CTRL			23
> +#define  SI5351_CLK_POWERDOWN			(1<<7)
> +#define  SI5351_CLK_INTEGER_MODE		(1<<6)
> +#define  SI5351_CLK_PLL_SELECT			(1<<5)
> +#define  SI5351_CLK_INVERT			(1<<4)
> +#define  SI5351_CLK_INPUT_MASK			(3<<2)
> +#define  SI5351_CLK_INPUT_XTAL			(0<<2)
> +#define  SI5351_CLK_INPUT_CLKIN			(1<<2)
> +#define  SI5351_CLK_INPUT_MULTISYNTH_0_4	(2<<2)
> +#define  SI5351_CLK_INPUT_MULTISYNTH_N		(3<<2)
> +#define  SI5351_CLK_DRIVE_STRENGTH_MASK		(3<<0)
> +#define  SI5351_CLK_DRIVE_STRENGTH_2MA		(0<<0)
> +#define  SI5351_CLK_DRIVE_STRENGTH_4MA		(1<<0)
> +#define  SI5351_CLK_DRIVE_STRENGTH_6MA		(2<<0)
> +#define  SI5351_CLK_DRIVE_STRENGTH_8MA		(3<<0)
> +
> +#define SI5351_CLK3_0_DISABLE_STATE		24
> +#define SI5351_CLK7_4_DISABLE_STATE		25
> +#define  SI5351_CLK_DISABLE_STATE_LOW		0
> +#define  SI5351_CLK_DISABLE_STATE_HIGH		1
> +#define  SI5351_CLK_DISABLE_STATE_FLOAT		2
> +#define  SI5351_CLK_DISABLE_STATE_NEVER		3
> +
> +#define SI5351_PARAMETERS_LENGTH		8
> +#define SI5351_PLLA_PARAMETERS			26
> +#define SI5351_PLLB_PARAMETERS			34
> +#define SI5351_CLK0_PARAMETERS			42
> +#define SI5351_CLK1_PARAMETERS			50
> +#define SI5351_CLK2_PARAMETERS			58
> +#define SI5351_CLK3_PARAMETERS			66
> +#define SI5351_CLK4_PARAMETERS			74
> +#define SI5351_CLK5_PARAMETERS			82
> +#define SI5351_CLK6_PARAMETERS			90
> +#define SI5351_CLK7_PARAMETERS			91
> +#define SI5351_CLK6_7_OUTPUT_DIVIDER		92
> +#define  SI5351_OUTPUT_CLK_DIV_MASK		(7 << 4)
> +#define  SI5351_OUTPUT_CLK6_DIV_MASK		(7 << 0)
> +#define  SI5351_OUTPUT_CLK_DIV_SHIFT		4
> +#define  SI5351_OUTPUT_CLK_DIV6_SHIFT		0
> +#define  SI5351_OUTPUT_CLK_DIV_1		0
> +#define  SI5351_OUTPUT_CLK_DIV_2		1
> +#define  SI5351_OUTPUT_CLK_DIV_4		2
> +#define  SI5351_OUTPUT_CLK_DIV_8		3
> +#define  SI5351_OUTPUT_CLK_DIV_16		4
> +#define  SI5351_OUTPUT_CLK_DIV_32		5
> +#define  SI5351_OUTPUT_CLK_DIV_64		6
> +#define  SI5351_OUTPUT_CLK_DIV_128		7
> +#define  SI5351_OUTPUT_CLK_DIVBY4		(3<<2)
> +
> +#define SI5351_SSC_PARAM0			149
> +#define SI5351_SSC_PARAM1			150
> +#define SI5351_SSC_PARAM2			151
> +#define SI5351_SSC_PARAM3			152
> +#define SI5351_SSC_PARAM4			153
> +#define SI5351_SSC_PARAM5			154
> +#define SI5351_SSC_PARAM6			155
> +#define SI5351_SSC_PARAM7			156
> +#define SI5351_SSC_PARAM8			157
> +#define SI5351_SSC_PARAM9			158
> +#define SI5351_SSC_PARAM10			159
> +#define SI5351_SSC_PARAM11			160
> +#define SI5351_SSC_PARAM12			161
> +
> +#define SI5351_VXCO_PARAMETERS_LOW		162
> +#define SI5351_VXCO_PARAMETERS_MID		163
> +#define SI5351_VXCO_PARAMETERS_HIGH		164
> +
> +#define SI5351_CLK0_PHASE_OFFSET		165
> +#define SI5351_CLK1_PHASE_OFFSET		166
> +#define SI5351_CLK2_PHASE_OFFSET		167
> +#define SI5351_CLK3_PHASE_OFFSET		168
> +#define SI5351_CLK4_PHASE_OFFSET		169
> +#define SI5351_CLK5_PHASE_OFFSET		170
> +
> +#define SI5351_PLL_RESET			177
> +#define  SI5351_PLL_RESET_B			(1<<7)
> +#define  SI5351_PLL_RESET_A			(1<<5)
> +
> +#define SI5351_CRYSTAL_LOAD			183
> +#define  SI5351_CRYSTAL_LOAD_MASK		(3<<6)
> +#define  SI5351_CRYSTAL_LOAD_6PF		(1<<6)
> +#define  SI5351_CRYSTAL_LOAD_8PF		(2<<6)
> +#define  SI5351_CRYSTAL_LOAD_10PF		(3<<6)
> +
> +#define SI5351_FANOUT_ENABLE			187
> +#define  SI5351_CLKIN_ENABLE			(1<<7)
> +#define  SI5351_XTAL_ENABLE			(1<<6)
> +#define  SI5351_MULTISYNTH_ENABLE		(1<<4)
> +
> +#endif
> diff --git a/include/linux/platform_data/si5351.h b/include/linux/platform_data/si5351.h
> new file mode 100644
> index 0000000..f62218e
> --- /dev/null
> +++ b/include/linux/platform_data/si5351.h
> @@ -0,0 +1,114 @@
> +/*
> + * Si5351A/B/C programmable clock generator platform_data.
> + */
> +
> +#ifndef __LINUX_PLATFORM_DATA_SI5351_H__
> +#define __LINUX_PLATFORM_DATA_SI5351_H__
> +
> +struct clk;
> +
> +/**
> + * enum si5351_variant - SiLabs Si5351 chip variant
> + * @SI5351_VARIANT_A: Si5351A (8 output clocks, XTAL input)
> + * @SI5351_VARIANT_A3: Si5351A MSOP10 (3 output clocks, XTAL input)
> + * @SI5351_VARIANT_B: Si5351B (8 output clocks, XTAL/VXCO input)
> + * @SI5351_VARIANT_C: Si5351C (8 output clocks, XTAL/CLKIN input)
> + */
> +enum si5351_variant {
> +	SI5351_VARIANT_A = 1,
> +	SI5351_VARIANT_A3 = 2,
> +	SI5351_VARIANT_B = 3,
> +	SI5351_VARIANT_C = 4,
> +};
> +
> +/**
> + * enum si5351_pll_src - Si5351 pll clock source
> + * @SI5351_PLL_SRC_DEFAULT: default, do not change eeprom config
> + * @SI5351_PLL_SRC_XTAL: pll source clock is XTAL input
> + * @SI5351_PLL_SRC_CLKIN: pll source clock is CLKIN input
> + */
> +enum si5351_pll_src {
> +	SI5351_PLL_SRC_DEFAULT = 0,
> +	SI5351_PLL_SRC_XTAL = 1,
> +	SI5351_PLL_SRC_CLKIN = 2,
> +};
> +
> +/**
> + * enum si5351_multisynth_src - Si5351 multisynth clock source
> + * @SI5351_MULTISYNTH_SRC_DEFAULT: default, do not change eeprom config
> + * @SI5351_MULTISYNTH_SRC_VCO0: multisynth source clock is VCO0
> + * @SI5351_MULTISYNTH_SRC_VCO1: multisynth source clock is VCO1
> + */
> +enum si5351_multisynth_src {
> +	SI5351_MULTISYNTH_SRC_DEFAULT = 0,
> +	SI5351_MULTISYNTH_SRC_VCO0 = 1,
> +	SI5351_MULTISYNTH_SRC_VCO1 = 2,
> +};
> +
> +/**
> + * enum si5351_clkout_src - Si5351 clock output clock source
> + * @SI5351_CLKOUT_SRC_DEFAULT: default, do not change eeprom config
> + * @SI5351_CLKOUT_SRC_MSYNTH_N: clkout N source clock is multisynth N
> + * @SI5351_CLKOUT_SRC_MSYNTH_0_4: clkout N source clock is multisynth 0 (N<4)
> + *                                or 4 (N>=4)
> + * @SI5351_CLKOUT_SRC_XTAL: clkout N source clock is XTAL
> + * @SI5351_CLKOUT_SRC_CLKIN: clkout N source clock is CLKIN
> + */
> +enum si5351_clkout_src {
> +	SI5351_CLKOUT_SRC_DEFAULT = 0,
> +	SI5351_CLKOUT_SRC_MSYNTH_N = 1,
> +	SI5351_CLKOUT_SRC_MSYNTH_0_4 = 2,
> +	SI5351_CLKOUT_SRC_XTAL = 3,
> +	SI5351_CLKOUT_SRC_CLKIN = 4,
> +};
> +
> +/**
> + * enum si5351_drive_strength - Si5351 clock output drive strength
> + * @SI5351_DRIVE_DEFAULT: default, do not change eeprom config
> + * @SI5351_DRIVE_2MA: 2mA clock output drive strength
> + * @SI5351_DRIVE_4MA: 4mA clock output drive strength
> + * @SI5351_DRIVE_6MA: 6mA clock output drive strength
> + * @SI5351_DRIVE_8MA: 8mA clock output drive strength
> + */
> +enum si5351_drive_strength {
> +	SI5351_DRIVE_DEFAULT = 0,
> +	SI5351_DRIVE_2MA = 2,
> +	SI5351_DRIVE_4MA = 4,
> +	SI5351_DRIVE_6MA = 6,
> +	SI5351_DRIVE_8MA = 8,
> +};
> +
> +/**
> + * struct si5351_clkout_config - Si5351 clock output configuration
> + * @clkout: clkout number
> + * @multisynth_src: multisynth source clock
> + * @clkout_src: clkout source clock
> + * @pll_master: if true, clkout can also change pll rate
> + * @drive: output drive strength
> + * @rate: initial clkout rate, or default if 0
> + */
> +struct si5351_clkout_config {
> +	enum si5351_multisynth_src multisynth_src;
> +	enum si5351_clkout_src clkout_src;
> +	enum si5351_drive_strength drive;
> +	bool pll_master;
> +	unsigned long rate;
> +};
> +
> +/**
> + * struct si5351_platform_data - Platform data for the Si5351 clock driver
> + * @variant: Si5351 chip variant
> + * @clk_xtal: xtal input clock
> + * @clk_clkin: clkin input clock
> + * @pll_src: array of pll source clock setting
> + * @clkout: array of clkout configuration
> + */
> +struct si5351_platform_data {
> +	enum si5351_variant variant;
> +	struct clk *clk_xtal;
> +	struct clk *clk_clkin;
> +	enum si5351_pll_src pll_src[2];
> +	struct si5351_clkout_config clkout[8];
> +};
> +
> +#endif
> -- 
> 1.7.10.4
> 
> 


From tony at atomide.com  Mon Apr  8 13:46:49 2013
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 8 Apr 2013 10:46:49 -0700
Subject: [GIT PULL 2/3] omap timer changes for v3.10 merge window
In-Reply-To: <201304081940.12773.arnd@arndb.de>
References: <0LdWUM-1V6HSB0nzO-00i0Xm@mx.kundenserver.de>
 <201304081940.12773.arnd@arndb.de>
Message-ID: <20130408174648.GS10155@atomide.com>

* Arnd Bergmann <arnd at arndb.de> [130408 10:45]:
> On Thursday 04 April 2013, Tony Lindgren wrote:
> >  arch/arm/mach-omap2/board-cm-t3517.c |   2 +-
> >  arch/arm/mach-omap2/board-generic.c  |   2 +-
> >  arch/arm/mach-omap2/common.h         |   3 +-
> >  arch/arm/mach-omap2/timer.c          | 124 ++++++++++++++++++-----------------
> >  4 files changed, 66 insertions(+), 65 deletions(-)
> 
> BTW, do you have any plans to move the timer.c file to drivers/clocksource?
> 
> I think that's where most of them are heading now.

Yes that's the plan.

With the various patches posted at least the timer code
GPMC code should be very close to being movable. And the
mailbox code is getting moved to drivers based on the pull
request I saw for that few days ago.

Regards,

Tony


From tony at atomide.com  Mon Apr  8 13:52:58 2013
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 8 Apr 2013 10:52:58 -0700
Subject: [GIT PULL 2/3] omap timer changes for v3.10 merge window
In-Reply-To: <201304081936.56288.arnd@arndb.de>
References: <0LdWUM-1V6HSB0nzO-00i0Xm@mx.kundenserver.de>
 <201304081936.56288.arnd@arndb.de>
Message-ID: <20130408175257.GT10155@atomide.com>

* Arnd Bergmann <arnd at arndb.de> [130408 10:41]:
> On Thursday 04 April 2013, Tony Lindgren wrote:
> > Clean-up for omap2+ timers from Jon Hunter <jon-hunter at ti.com>:
> > 
> > This series consists mainly of clean-ups for clockevents and
> > clocksource timers on OMAP2+ devices. The most significant change
> > in functionality comes from the 5th patch which is changing the
> > selection of the clocksource timer for OMAP3 and AM335x devices
> > when gptimers are used for clocksource.
> > 
> > Note that this series depends on 7185684 (ARM: OMAP: use
> > consistent error checking) in RMK's tree and 960cba6 (ARM:
> > OMAP5: timer: Update the clocksource name as per clock data)
> > in omap-for-v3.10/fixes-non-critical. So this branch is based
> > on a merge of 7185684 and omap-for-v3.10/fixes-non-critical
> > to avoid non-trivial merge conflicts.
> > 
> 
> Pulled into next/drivers, thanks!
> 
> Do you have a URL for a stable branch containing 7185684
> that we can list in our branch description file?

That's in RMK's for-next, but I have not seen any discussion
for that branch being immutable except up to commit 7185684.

Unless Russell has better ideas, you may want to set up
branch with 7185684 as the head for your dependencies.

Regards,

Tony


From arnd at arndb.de  Mon Apr  8 13:54:54 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 8 Apr 2013 19:54:54 +0200
Subject: [GIT PULL 3/3] omap gpmc changes for v3.10 merge window
In-Reply-To: <0MLQ4w-1UONym4BnO-000gHb@mx.kundenserver.de>
References: <0MLQ4w-1UONym4BnO-000gHb@mx.kundenserver.de>
Message-ID: <201304081954.54959.arnd@arndb.de>

On Thursday 04 April 2013, Tony Lindgren wrote:
> GPMC updates from Jon Hunter <jon-hunter at ti.com>:
> 
> Adds GPMC (General Purpose Memory Controller) DT support for
> NOR flash and Ethernet and includes various GPMC cleans-up
> and fixes.
> 
> This series is dependent on commit 7185684 (ARM: OMAP: use
> consistent error checking) from RMK's clean-up branch and commit
> 31d9adc (ARM: OMAP2+: Fix broken gpmc support).

Pulled into the next/drivers branch, thanks!

	Arnd


From dave.martin at linaro.org  Mon Apr  8 14:10:06 2013
From: dave.martin at linaro.org (Dave Martin)
Date: Mon, 8 Apr 2013 19:10:06 +0100
Subject: RFC: right way to conditional-ize some macros for LTO
In-Reply-To: <1364907037.3650.54.camel@linaro1.home>
References: <5155E28A.30509@am.sony.com>
 <1364907037.3650.54.camel@linaro1.home>
Message-ID: <20130408181006.GC2176@linaro.org>

On Tue, Apr 02, 2013 at 01:50:37PM +0100, Jon Medhurst (Tixy) wrote:
> On Fri, 2013-03-29 at 11:50 -0700, Tim Bird wrote:
> > Hi all,
> > 
> > A while ago I was working on supporting link-time optimization
> > for ARM, and I'm just now getting around to submitting some of
> > the patches from my work.  I'll explain more below, but the
> > executive summary is this: Andi Kleen's LTO patches for Linux
> > almost work on ARM.  I ran into one issue in
> > arch/arm/include/asm/unified.h where various 'it'-related
> > macros are expanding multiple times, in C context, and causing
> > build errors.
> > 
> > As near as I can tell, these macros are not used except by
> > arch/arm/kernel/kprobes-test-thumb.c (and most are not used
> > at all).
> > 
> > When compiling with CONFIG_LTO=y, in Andi's 3.7.0 tree with LTO
> > patches, I got the messages below:
> > -----------------------------------------------
> > ...
> >   LD      drivers/tty/built-in.o
> >   LD      drivers/built-in.o
> >   LINK    vmlinux
> >   GEN     .version
> >   CHK     include/generated/compile.h
> >   UPD     include/generated/compile.h
> >   CC      init/version.o
> >   LD      init/built-in.o
> >   LDFINAL vmlinux.o
> > [Leaving LTRANS /tmp/ccsIMbQT.args]
> > [Leaving LTRANS vmlinux.o.ltrans.out]
> > In file included from /a/home/tbird/work/auto-reduce/lto-work/linux-misc-andi-kleen/include/uapi/linux/swab.h:269:0,
> >                  from :872:
> > /a/home/tbird/work/auto-reduce/lto-work/linux-misc-andi-kleen/crypto/wp512.c: In function 'wp512_process_buffer':
> > /a/home/tbird/work/auto-reduce/lto-work/linux-misc-andi-kleen/crypto/wp512.c:987:1: warning: the frame size of 1160 bytes is larger than 1024 bytes [-Wframe-larger-than=]
> > vmlinux.o.ltrans0.s: Assembler messages:
> > vmlinux.o.ltrans0.s:408: Error: Macro `it' was already defined
> > vmlinux.o.ltrans0.s:410: Error: Macro `itt' was already defined
> > vmlinux.o.ltrans0.s:412: Error: Macro `ite' was already defined
> > vmlinux.o.ltrans0.s:414: Error: Macro `ittt' was already defined
> > vmlinux.o.ltrans0.s:416: Error: Macro `itte' was already defined
> > vmlinux.o.ltrans0.s:418: Error: Macro `itet' was already defined
> > vmlinux.o.ltrans0.s:420: Error: Macro `itee' was already defined
> > vmlinux.o.ltrans0.s:422: Error: Macro `itttt' was already defined
> > vmlinux.o.ltrans0.s:424: Error: Macro `ittte' was already defined
> > vmlinux.o.ltrans0.s:426: Error: Macro `ittet' was already defined
> > vmlinux.o.ltrans0.s:428: Error: Macro `ittee' was already defined
> > vmlinux.o.ltrans0.s:430: Error: Macro `itett' was already defined
> > vmlinux.o.ltrans0.s:432: Error: Macro `itete' was already defined
> > vmlinux.o.ltrans0.s:434: Error: Macro `iteet' was already defined
> > vmlinux.o.ltrans0.s:436: Error: Macro `iteee' was already defined
> > vmlinux.o.ltrans0.s:968: Error: Macro `it' was already defined
> > vmlinux.o.ltrans0.s:970: Error: Macro `itt' was already defined
> > vmlinux.o.ltrans0.s:972: Error: Macro `ite' was already defined
> > vmlinux.o.ltrans0.s:974: Error: Macro `ittt' was already defined
> > vmlinux.o.ltrans0.s:976: Error: Macro `itte' was already defined
> > ...
> > [Leaving LTRANS vmlinux.o.ltrans30.ltrans.o]
> > [Leaving LTRANS vmlinux.o.ltrans31.o]
> > [Leaving LTRANS vmlinux.o.ltrans31.ltrans.o]
> > /a/home/tbird/work/auto-reduce/sony-yocto/lto-build2/tmp/sysroots/x86_64-linux/usr/libexec/armv5te-sony-linux-gnueabi/gcc/arm-sony-linux-gnueabi/4.7.3/arm-sony-linux-gnueabi-ld: lto-wrapper failed
> > collect2: error: ld returned 1 exit status
> > make[1]: *** [vmlinux] Error 1
> > make: *** [sub-make] Error 2
> > 
> > Error: Bad result 512, running "make -j 8 KALLSYMS_EXTRA_PASS=1 bzImage": (output follows)
> > Error:
> > ---------------------------------------------
> > 
> > The messages are repeated thousands of times (I'm guessing for every object
> > file after the first that included arch/arm/include/asm/unified.h)
> > 
> > Recognizing that LTO is currently incompatible with kprobes, and (so far)
> > finding that only kprobes appeared to use these macros, I did the following hack:
> > 
> > diff --git a/arch/arm/include/asm/unified.h b/arch/arm/include/asm/unified.h
> > index f5989f4..5179c13 100644
> > --- a/arch/arm/include/asm/unified.h
> > +++ b/arch/arm/include/asm/unified.h
> > @@ -92,6 +92,7 @@
> >  	.macro	iteee, cond
> >  	.endm
> >  #else	/* !__ASSEMBLY__ */
> > +#ifndef CONFIG_LTO
> >  __asm__(
> >  "	.macro	it, cond\n"
> >  "	.endm\n"
> > @@ -123,6 +124,7 @@ __asm__(
> >  "	.endm\n"
> >  "	.macro	iteee, cond\n"
> >  "	.endm\n");
> > +#endif  /* ! CONFIG_LTO */
> >  #endif	/* __ASSEMBLY__ */
> > 
> >  #endif	/* CONFIG_ARM_ASM_UNIFIED */
> > 
> > This the macros thus removed, I had no problems building the kernel
> > and running it on target.
> > 
> > While this works to remove the build error, it doesn't seem robust and I'd
> > like to either 1) find a better way to make these macro definitions conditional,
> > or 2) eliminate them completely.

This is one instance of a more general problem: anything in an asm()
which alters the state of the assembler is potentially unsafe when we
start attempting to merge compilation units together before passing them
through the assembler, because GCC does not take these side effects
into account at all.

This feels like a potential problem for every arch if my understanding
is correct.  But how much it hurts will depend to some extent on how
asm() is used in arch-specific headers.


LTO may completely reorder / remove stuff at external scope, so every
toplevel asm needs careful scrutiny, as does any code anywhere using
directives which permanently change the assembler state (like .arch etc.)
... otherwise we could end up with half the kernel assembled using
the wrong CPU or arch settings, because a random C file somewhere
happened to override them using asm directives.

An nasty hack which might work would be to add primitive multi-definition
prevention like

	.ifndef .L__UNIFIED_H_INCLUDED
	.equ .L__UNIFIED_H_INCLUDED
	
	.macro it cond
	.endm

	@ ...

	.endif

This only works because we know the macro definitions are supposed to
be the same everywhere.

(.L__UNIFIED_H_INCLUDED is anything sufficiently verbose to avoid
clashes with any custom or compiler-generated local symbol.  This symbol
will leak between compilation units too, but providing it doesn't clash
with anything emitted by the compiler, that shouldn't matter.  Because
of the .L prefix, gas will not emit the symbol in its output by default)


If LTO inlines some affected code before the first top-level asm
arising from unified.h then you still lose :(  AFAIK there's no
guarantee it won't, unless you pass -fno-toplevel-reorder, but I
believe that has undesirable side-effects, and somewhat defeats the
idea of LTO.) 


Two slightly more correct fixes I can think of:


1) Get of the "it" .macros for C files, as you suggested.  We can
provide C macros which provide equivalent functionality at the expense
of ugliness and non-standard syntax.  Since the use of these is so rare,
that could be acceptable.

For example:

#ifdef CONFIG_ARM_ASM_UNIFIED
#define U(x...) x
#else
#define U(x...)
#endif

	asm (
	 U(	"itee	eq\n\t"		)
		"moveq	%0, %2\n\t"
		"movne	%0, %3\n\t"
		"movne	%1, #1"
	);

(Silly example, but you get the idea)


.S files won't be LTO'd, so we can keep the macros there, conditional
on #ifdef __ASSEMBLY__, at least allowing the illusion of compliant
assembler syntax to be preserved.


2) Eliminate the toplevel asms for any compilation unit which will be
subjected to LTO, and re-inject them when assembling the LTO output, or
to inject them only when running the assembler.  Since the assembler has
no mechanism like the gcc -include option, that might require wrapping
the assembler in a script, which might slow down compilation noticeably,
depending on how many times the assembler is invoked.  I guess LTO
reduces the number of actual assembler invocations rather significantly,
though -- perhaps we would only do this when LTO is enabled.

This all feels complex and impractical, though.

> > 
> > The macros themselves seem empty.  Can someone tell me what they do?
> > What is the status of these macros?  Are they even needed?
> 
> The names of the macros are for Thumb2 instructions which are redundant
> when building for the ARM instruction set. Newer toolchains which
> support the unified assembler syntax will effectively ignore them and I
> guess these empty macros are there so people can write assembler which
> will compile with older toolchains.
> 
> > Could they be
> > made conditional on something like NEED_IT_MACROS, and then have that set only

This wouldn't solve the problem unless there is only ever one C file in
the entire kernel built with that define.  Even it it were true today,
it might not be true tomorrow.

> > in the arch/arm/kernel/kprobes-test-thumb.c, before the unified.h is included?
> 
> That file needs the real Thumb2 instructions, not empty macros, and
> indeed it doesn't use them, because it is only compiled when
> CONFIG_THUMB2_KERNEL=y and that selects CONFIG_ARM_ASM_UNIFIED and those
> 'it' macro's are guarded by #ifndef CONFIG_ARM_ASM_UNIFIED.
> 
> Note, there are other files which use the 'it' instructions, e.g.
> arch/arm/include/asm/futex.h.

For code which might be built using either the ARM or Thumb instruction set
(which is most of the kernel) the "it" directives are required in certain
situations as part of the assembler syntax.  Just because a particular one
is not needed right now does not mean some assembler that gets written
tomorrow won't need it.  gas can guess correctly which IT instructions to
insert most of the time, but there are some situations where it's
necessary to override the default guess, such as when a location in the
middle of a conditional sequence is a branch target.

Unfortunately, gas chokes on those directives in non-unified syntax, so
we have to make them disappear using macros... hence the problem.

> 
> > I would like get this minor issue resolved in mainline, to make it easier for Andi
> > to get his LTO work upstream and have it work with ARM.
> > 
> > Any suggestions are welcome.
> 
> If your toolchain supports the unified assembler syntax, you could try
> enabling CONFIG_ARM_ASM_UNIFIED in ARM builds.

This is the easiest fix for the immediate issue would be OK if older
toolchains are not LTO-capable anyway, providing there are no old boards
which this would break etc.

It doesn't solve any of the other problems with LTO and toplevel asm(),
so we'd still need to be vigilant about those.

Cheers
---Dave


From swarren at wwwdotorg.org  Mon Apr  8 14:11:30 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Mon, 08 Apr 2013 12:11:30 -0600
Subject: [PATCH 1/3] ARM: tegra: pcie: Add tegra3 support
In-Reply-To: <1365435688-4179-1-git-send-email-jagarwal@nvidia.com>
References: <1365435688-4179-1-git-send-email-jagarwal@nvidia.com>
Message-ID: <51630852.1000107@wwwdotorg.org>

On 04/08/2013 09:41 AM, Jay Agarwal wrote:
> Signed-off-by: Jay Agarwal <jagarwal at nvidia.com>
> 
> - Enable pcie root port 2 for cardhu
> - Make private data structure for each SOC
> - Add required tegra3 clocks and regulators
> - Add tegra3 specific code in enable controller
> - Modify clock tree to get clocks based on device
> - Based on git://gitorious.org/thierryreding/linux.git

There are quite a few capitalization errors above. The correct versions
are: PCIe, Cardhu, SoC, Tegra.

Upstream uses engineering names not marketing names, so Tegra30 not Tegra3.

>  drivers/clk/tegra/clk-tegra30.c |   12 ++--
>  drivers/pci/host/pci-tegra.c    |  146 ++++++++++++++++++++++++++++++++++-----

This patch touches two unrelated drivers. There is no dependency between
the changes, since PCIe doesn't work yet on Tegra30, so there's no need
for those unrelated changes to be part of the same patch. Please split
them into separate patches. The clk patch can likely be applied very
soon, without waiting for any of the other PCIe patches.

> - Modify clock tree to get clocks based on device

That description doesn't seem to describe the change made to
clk-tegra30.c. Can you please include more details re: what the patch is
doing and why.

> diff --git a/drivers/pci/host/pci-tegra.c b/drivers/pci/host/pci-tegra.c

> +/* used to differente tegra chips code */

differentiate

> +struct tegra_pcie_soc_data {
...
> +	bool need_avdd_supply;
> +	bool need_cml0_clk;

s/need/has/ would be better.

> @@ -749,6 +778,11 @@ static int tegra_pcie_enable_controller(struct tegra_pcie *pcie)
>  	struct tegra_pcie_port *port;
>  	unsigned int timeout;
>  	unsigned long value;
> +	struct tegra_pcie_soc_data *soc = pcie->soc_data;
> +
> +	/* power down to PCIe slot clock bias pad */
> +	if (soc->pex_bias_ctrl)
> +		afi_writel(pcie, 0, AFI_PEXBIAS_CTRL_0);

Power down when /enabling/ a controller?

>  	err = regulator_disable(pcie->pex_clk_supply);
>  	if (err < 0)
> -		dev_err(pcie->dev, "failed to disable pex-clk regulator: %d\n",
> +		dev_warn(pcie->dev, "failed to disable pex-clk regulator: %d\n",
>  			err);
>  
>  	err = regulator_disable(pcie->vdd_supply);
>  	if (err < 0)
> -		dev_err(pcie->dev, "failed to disable VDD regulator: %d\n",
> +		dev_warn(pcie->dev, "failed to disable VDD regulator: %d\n",
>  			err);

Please explain why that change is correct. If the regulators only exist
on Tegra20, please represent that fact in the SoC data. Regulators must
always exist, so enable/disable should never fail due to missing
regulators. Actual run-time failures seem like something that really is
an error.

> @@ -1489,6 +1597,11 @@ static int tegra_pcie_probe(struct platform_device *pdev)
>  	INIT_LIST_HEAD(&pcie->busses);
>  	INIT_LIST_HEAD(&pcie->ports);
>  	pcie->dev = &pdev->dev;
> +	match = of_match_device(tegra_pcie_of_match, &pdev->dev);
> +	if (match)
> +		pcie->soc_data = (struct tegra_pcie_soc_data *)match->data;
> +	else
> +		return -ENODEV;

that would be more idiomatic as:

if (!match)
	return -ENODEV;
pcie->soc_data = ...;



From kgene.kim at samsung.com  Mon Apr  8 14:17:40 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Tue, 09 Apr 2013 03:17:40 +0900
Subject: [GIT PULL 0/10] Samsung stuff for v3.10
Message-ID: <516309C4.3000008@samsung.com>

Hi Arnd, Olof

This is 2nd pull-request for Samsung stuff for v3.10.

If any problems, please kindly let me know.


-- 
Thanks.

Best regards,
Kgene.
--
Kukjin Kim <kgene.kim at samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.



The following changes since commit 347394370cbd68ab440564357eaf3d0a5b8bddeb:

   Merge branch 'next/pinctrl-exynos-1' into for-next-next (2013-04-09 
01:07:43 +0900)

are available in the git repository at:

   git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git 
for-next

Abhilash Kesavan (1):
       ARM: dts: Add max77686 device tree support for CROS5250

Alexander Graf (2):
       ARM: dts: Declare the gic as a15 compatible for exynos5250
       ARM: dts: Add architected timer nodes for exynos5250

Alexander Shiyan (3):
       ARM: S3C24XX: Removed unneeded dependency on ARCH_S3C24XX for boards
       ARM: S3C24XX: Removed unneeded dependency on CPU_S3C2410
       ARM: S3C24XX: Removed unneeded dependency on CPU_S3C2412

Amit Daniel Kachhap (2):
       ARM: dts: Add PMIC node entry for Arndale board
       ARM: dts: Add cpufreq controller node for Exynos5440 SoC

Andrzej Hajda (1):
       clk: exynos4: Add missing CMU_TOP and ISP clocks

Axel Lin (1):
       clocksource: mct: Add terminating entry for exynos_mct_ids table

Byungho An (1):
       ARM: dts: Add node for GMAC for exynos5440

Chanho Park (5):
       irqchip: exynos-combiner: Add set_irq_affinity function for 
combiner_irq
       irqchip: exynos-combiner: Correct combined IRQs for exynos4
       ARM: EXYNOS: Enable PMUs for exynos4
       ARM: EXYNOS: Add arm-pmu DT binding for exynos5250
       ARM: EXYNOS: Add arm-pmu DT binding for exynos421x

Charles Keepax (2):
       ARM: S3C64XX: Clear DMA flags on channel request
       ARM: S3C64XX: Slow down mic detection rate for wm5102

Daniel Lezcano (3):
       ARM: EXYNOS: factor out the idle states
       ARM: EXYNOS: handle properly the return values
       ARM: EXYNOS: replace cpumask by the corresponding macro

Dongjin Kim (3):
       ARM: dts: Add board dts file for ODROID-X
       ARM: dts: Fix the timing property of MSHC controller for 
exynos4412-odroidx
       ARM: dts: enable RTC device node for exynos4412-odroidx

Doug Anderson (3):
       clocksource: mct: Add missing semicolons in exynos_mct.c
       ARM: dts: add usb 2.0 clock references to exynos5250 device tree
       ARM: dts: Document usb clocks in samsung,exynos4210-ehci/ohci 
bindings

Giridhar Maruthy (4):
       ARM: dts: remove disabled status from watchdog node for 
exynos5440-ssdk5440
       ARM: dts: remove disabled status from RTC node for 
exynos5440-ssdk5440
       ARM: dts: change compatible value for exynos5440 i2c
       ARM: dts: Add virtual GIC DT bindings for exynos5440

Girish K S (2):
       ARM: dts: Add initial board support file for exynos5250-arndale
       ARM: EXYNOS: force MAC ip to 32bit DMA

Heiko Stueber (1):
       clk: samsung: fix pm init on non-dt platforms

Heiko Stuebner (15):
       ARM: S3C24XX: fix redundant checks in the irq mapping function
       ARM: S3C24XX: fix irq parent check
       ARM: S3C24XX: move s3c24xx_init_irq to s3c2410_init_irq
       ARM: S3C24XX: make s3c24xx_init_intc static
       ARM: S3C24XX: add handle_irq function
       clk: samsung: register clk_div_tables for divider clocks
       clk: samsung: always allocate the clk_table
       clk: samsung: add infrastructure to add separate aliases
       ARM: S3C24XX: move irq driver to drivers/irqchip
       irqchip: s3c24xx: fix comments on some camera interrupts
       irqchip: s3c24xx: fix irqlist of second s3c2416 controller
       irqchip: s3c24xx: add irq_set_type callback for basic interrupt types
       irqchip: s3c24xx: globally keep track of the created intc instances
       irqchip: s3c24xx: make interrupt handling independent of 
irq_domain structure
       irqchip: s3c24xx: add devicetree support

Inderpal Singh (2):
       ARM: EXYNOS: Add support for rtc wakeup
       ARM: SAMSUNG: check processor type before cache restoration in resume

Jingoo Han (3):
       ARM: EXYNOS: Add AUXDATA for DP controller
       ARM: dts: Add device tree node for DP controller for exynos5250
       ARM: EXYNOS: change the name of USB ohci header

Jonathan Kliegman (2):
       ARM: EXYNOS: Remove hardcode wakeup unmask for EINT_0
       ARM: EXYNOS: Clear ENABLE_WAKEUP_SW bit when entering suspend

Kukjin Kim (17):
       ARM: dts: cleanup exynos5440.dtsi
       ARM: dts: re-organized cpu node for exynos5440
       Merge branch 'next/timer-samsung' into next/clk-exynos
       Merge branch 'next/mct-exynos' into next/clk-exynos
       ARM: SAMSUNG: change GENERIC_GPIO to ARCH_REQUIRE_GPIOLIB
       Merge branch 'next/cleanup-samsung' into for-next-next
       Merge branch 'next/irq-s3c24xx' into for-next-next
       Merge branch 'next/mct-exynos' into for-next-next
       Merge commit 'v3.9-rc5' into next/clk-exynos
       Merge branch 'next/clk-exynos' into for-next-next
       ARM: dts: add device tree file for SD5v1 board
       Merge branch 'next/dt-exynos' into for-next-next
       Merge branch 'next/pinctrl-exynos' into for-next-next
       Merge branch 'next/pmu-exynos' into for-next-next
       Merge branch 'next/secure-exynos' into for-next-next
       Merge branch 'next/timer-samsung' into for-next-next
       Merge branch 'next/devel-samsung' into for-next-next

Leela Krishna Amudala (3):
       clk: exynos5250: register display block gate clocks to common 
clock framework
       ARM: dts: Add FIMD node to exynos5
       ARM: dts: Add display timing node to exynos5250-smdk5250.dts

Lukasz Majewski (1):
       clk: exynos4: Export clocks used by exynos cpufreq drivers

Padmavathi Venna (1):
       ARM: SAMSUNG: Remove unnecessary code for dma

Paul Bolle (11):
       ARM: S3C24XX: drop "select MACH_N35"
       ARM: S3C24XX: drop "select MACH_NEO1973"
       ARM: EXYNOS: drop "select HAVE_SCHED_CLOCK"
       ARM: EXYNOS: change HAVE_SAMSUNG_KEYPAD to KEYBOARD_SAMSUNG
       ARM: SAMSUNG: remove "config S3C_BOOT_WATCHDOG"
       ARM: SAMSUNG: Remove useless Samsung GPIO related CONFIG
       ARM: S3C24XX: remove unneeded "config SMDK2440_CPU2442"
       ARM: S3C64XX: remove obsolete Makefile line
       ARM: S5P64X0: Fix typo "CONFIG_S5P64X0_SETUP_SDHCI"
       ARM: SAMSUNG: Fix typo "CONFIG_SAMSUNG_DEV_RTC"
       ARM: EXYNOS: remove "config EXYNOS_DEV_DRM"

Prasanna Kumar (1):
       ARM: dts: Set up power domain for MFC and G-scaler for exynos5250

Sachin Kamat (23):
       ARM: dts: Add vmmc regulator node in exynos4412-origen.dts
       ARM: dts: Add sdhci node for exynos4412-origen
       ARM: dts: Update MFC DT binding documentation
       ARM: dts: Add MFC codec support for EXYNOS4 DT machines
       ARM: dts: Add MFC codec support to SMDKV310 DT
       ARM: dts: Add MFC codec support to Origen DT
       ARM: dts: Add MFC codec entry to exynos4412-origen DT
       ARM: dts: Add MFC codec entry to exynos4412-smdk4412 DT
       ARM: dts: Add MSHC node for exynos4412-origen DT
       ARM: dts: Add s5m8767 PMIC node to exynos4412-origen DT
       ARM: dts: Add sdhci node for exynos4412-smdk4412
       clk: samsung: Fix compilation error
       ARM: dts: Add G2D node to exynos4210.dtsi
       ARM: dts: Add G2D node to SMDKV310
       ARM: dts: Add G2D node to exynos4210-origen
       ARM: dts: Add G2D node to exynos4x12.dtsi
       ARM: dts: Add G2D node to SMDK4412
       ARM: dts: Add G2D node to exynos4412-origen
       ARM: dts: Add Samsung G2D DT bindings documentation
       ARM: dts: Add disable-wp for card slot on exynos5250-arndale
       ARM: dts: Add vmmc regulator support for Arndale board
       ARM: dts: Add MFC codec support for Arndale board
       ARM: dts: Add HDMI HPD and regulator node for Arndale board

Subash Patel (3):
       ARM: dts: add PMU support in exynos5440
       ARM: dts: update bootargs to boot from sda2 for exynos5440-ssdk5440
       ARM: dts: add PDMA0 changes for exynos5440

Sylwester Nawrocki (7):
       ARM: SAMSUNG: Export MIPI CSIS/DSIM PHY control functions
       clk: exynos4: Correct sclk_mfc clock definition
       clk: exynos4: Add camera related clock definitions
       ARM: S3C24XX: Remove unused GPIO drive strength register definitions
       clk: exynos4: export clocks required for fimc-is
       ARM: S3C24XX: Correct NR_IRQS definition for s3c2440
       ARM: dts: Add SYSREG block node for S5P/Exynos4 SoC series

Thomas Abraham (32):
       ARM: dts: add board dts file for EXYNOS4412 based Origen board
       ARM: EXYNOS: add a register base address variable in mct 
controller driver
       ARM: EXYNOS: prepare an array of MCT interrupt numbers and use it
       ARM: EXYNOS: add device tree support for MCT controller driver
       ARM: EXYNOS: allow dt based discovery of mct controller using 
clocksource_of_init
       ARM: dts: add mct device tree node for all supported Exynos SoC's
       ARM: EXYNOS: remove static io-remapping of mct registers for Exynos5
       ARM: EXYNOS: move mct driver to drivers/clocksource
       clk: samsung: add common clock framework helper functions for 
Samsung platforms
       clk: samsung: add pll clock registration helper functions
       clk: exynos4: register clocks using common clock framework
       clk: exynos5250: register clocks using common clock framework
       clk: exynos5440: register clocks using common clock framework
       ARM: EXYNOS: Migrate clock support to common clock framework
       ARM: EXYNOS: Initialize the clocks prior to timer initialization
       ARM: EXYNOS: allow legacy board support to specify xxti and 
xusbxti clock speed
       ARM: EXYNOS: remove auxdata table from exynos4/5 dt machine file
       clocksource: mct: use fin_pll clock as the tick clock source for mct
       clocksource: mct: add support for mct clock setup
       ARM: dts: add Exynos4 and Exynos5 clock controller nodes
       ARM: dts: add clock provider information for all controllers in 
Exynos4 SoCs
       ARM: dts: add clock provider information for all controllers in 
Exynos5250 SoC
       ARM: dts: add clock provider information for all controllers in 
Exynos5440 SoC
       ARM: dts: add board specific fixed rate clock nodes for Exynos 
based platforms
       ARM: EXYNOS: fix compilation error introduced due to common clock 
migration
       pinctrl: exynos5440: fix probe failure due to missing pin-list in 
config nodes
       pinctrl: exynos5440: add gpio interrupt support
       ARM: dts: add pin state information in client nodes for Exynos4 
platforms
       ARM: dts: add pin state information in client nodes for Exynos5 
platforms
       ARM: dts: list the interrupts generated by pin-controller on 
Exynos5440
       ARM: dts: Fix gmac clock ids due to changes in Exynos5440
       ARM: EXYNOS: Add a platform bus notifier to set dma masks for 
Exynos5440

Tomasz Figa (22):
       clk: exynos4: Use mout_mpll_user_* on Exynos4x12
       clk: exynos4: Add missing mout_mipihsi clock
       clk: exynos4: Add missing sclk_audio0 clock
       clk: exynos4: Export sclk_pcm0
       clk: exynos4: Move dac and mixer to Exynos4210-specific clocks
       clk: samsung: Remove unimplemented ops for pll
       clk: exynos4: Export mout_core clock of Exynos4210
       clk: exynos4: Add G3D clocks
       clk: exynos4: Add missing mout_sata on Exynos4210
       clk: exynos4: Define {E,V}PLL registers
       clk: exynos4: Use SRC_MASK_PERIL{0,1} definitions
       clk: exynos4: Remove SoC-specific registers from save list
       clk: exynos4: Add E4210 prefix to LCD1 clock registers
       clk: exynos4: Add E4210 prefix to GATE_IP_PERIR register
       clk: exynos4: Remove E4X12 prefix from SRC_DMC register
       clk: exynos4: Add missing registers to suspend save list
       clk: exynos4: Add support for SoC-specific register save list
       ARM: Add interface for registering and calling firmware-specific 
operations
       ARM: EXYNOS: Add support for secure monitor calls
       ARM: EXYNOS: Add support for Exynos secure firmware
       ARM: EXYNOS: Add IO mapping for non-secure SYSRAM.
       ARM: EXYNOS: Add secure firmware support to secondary CPU bring-up

Tushar Behera (3):
       clk: exynos5250: Fix divider values for sclk_mmc{0,1,2,3}
       ARM: dts: Add pin-control related changes for Arndale board
       ARM: dts: Add gpio-button entries for Arndale board

Vikas Sajjan (3):
       ARM: dts: Add FIMD node to exynos4
       ARM: dts: Add FIMD node and display timing node to 
exynos4412-origen.dts
       ARM: dts: Add FIMD DT binding Documentation

Viresh Kumar (1):
       cpufreq: s3c24xx: move cpufreq driver to drivers/cpufreq

Vivek Gautam (2):
       ARM: dts: Enabling ehci-s5p driver for EXYNOS5250
       ARM: dts: Enabling ohci-exynos driver for EXYNOS5250

Wei Yongjun (1):
       ARM: EXYNOS: remove duplicated include from common.c

  Documentation/arm/firmware.txt                     |   88 ++
  .../devicetree/bindings/arm/samsung-boards.txt     |   10 +
  .../devicetree/bindings/arm/samsung/sysreg.txt     |    7 +
  .../devicetree/bindings/clock/exynos4-clock.txt    |  288 ++++
  .../devicetree/bindings/clock/exynos5250-clock.txt |  177 +++
  .../devicetree/bindings/clock/exynos5440-clock.txt |   61 +
  .../devicetree/bindings/gpu/samsung-g2d.txt        |   20 +
  .../interrupt-controller/samsung,s3c24xx-irq.txt   |   53 +
  .../devicetree/bindings/media/s5p-mfc.txt          |   21 +
  .../bindings/timer/samsung,exynos4210-mct.txt      |   68 +
  .../devicetree/bindings/usb/exynos-usb.txt         |   50 +
  .../devicetree/bindings/video/samsung-fimd.txt     |   65 +
  arch/arm/Kconfig                                   |   56 +-
  arch/arm/boot/dts/Makefile                         |    4 +
  arch/arm/boot/dts/cros5250-common.dtsi             |  189 ++-
  arch/arm/boot/dts/exynos4.dtsi                     |   85 +
  arch/arm/boot/dts/exynos4210-origen.dts            |   22 +
  arch/arm/boot/dts/exynos4210-smdkv310.dts          |   75 +-
  arch/arm/boot/dts/exynos4210-trats.dts             |   12 +
  arch/arm/boot/dts/exynos4210.dtsi                  |   43 +
  arch/arm/boot/dts/exynos4212.dtsi                  |   22 +
  arch/arm/boot/dts/exynos4412-odroidx.dts           |  109 ++
  arch/arm/boot/dts/exynos4412-origen.dts            |  451 ++++++
  arch/arm/boot/dts/exynos4412-smdk4412.dts          |   33 +
  arch/arm/boot/dts/exynos4412.dtsi                  |   26 +
  arch/arm/boot/dts/exynos4x12.dtsi                  |   13 +
  arch/arm/boot/dts/exynos5250-arndale.dts           |  452 ++++++
  arch/arm/boot/dts/exynos5250-pinctrl.dtsi          |  783 ++++++++++
  arch/arm/boot/dts/exynos5250-smdk5250.dts          |   69 +-
  arch/arm/boot/dts/exynos5250-snow.dts              |   33 +-
  arch/arm/boot/dts/exynos5250.dtsi                  |  489 +++---
  arch/arm/boot/dts/exynos5440-sd5v1.dts             |   39 +
  arch/arm/boot/dts/exynos5440-ssdk5440.dts          |   25 +-
  arch/arm/boot/dts/exynos5440.dtsi                  |  115 +-
  arch/arm/common/Makefile                           |    2 +
  arch/arm/common/firmware.c                         |   18 +
  arch/arm/include/asm/firmware.h                    |   66 +
  arch/arm/mach-exynos/Kconfig                       |   23 +-
  arch/arm/mach-exynos/Makefile                      |   12 +-
  arch/arm/mach-exynos/clock-exynos4.c               | 1601 
-------------------
  arch/arm/mach-exynos/clock-exynos4.h               |   35 -
  arch/arm/mach-exynos/clock-exynos4210.c            |  187 ---
  arch/arm/mach-exynos/clock-exynos4212.c            |  201 ---
  arch/arm/mach-exynos/clock-exynos5.c               | 1645 
--------------------
  arch/arm/mach-exynos/common.c                      |  123 +-
  arch/arm/mach-exynos/common.h                      |   12 +-
  arch/arm/mach-exynos/cpuidle.c                     |   58 +-
  arch/arm/mach-exynos/dev-ohci.c                    |    2 +-
  arch/arm/mach-exynos/exynos-smc.S                  |   22 +
  arch/arm/mach-exynos/firmware.c                    |   70 +
  arch/arm/mach-exynos/include/mach/irqs.h           |   19 +-
  arch/arm/mach-exynos/include/mach/map.h            |    4 +-
  arch/arm/mach-exynos/include/mach/pm-core.h        |    9 +-
  arch/arm/mach-exynos/include/mach/regs-clock.h     |  107 --
  arch/arm/mach-exynos/include/mach/regs-mct.h       |   53 -
  arch/arm/mach-exynos/mach-armlex4210.c             |    3 +-
  arch/arm/mach-exynos/mach-exynos4-dt.c             |  123 +--
  arch/arm/mach-exynos/mach-exynos5-dt.c             |  165 +--
  arch/arm/mach-exynos/mach-nuri.c                   |    5 +-
  arch/arm/mach-exynos/mach-origen.c                 |    7 +-
  arch/arm/mach-exynos/mach-smdk4x12.c               |    5 +-
  arch/arm/mach-exynos/mach-smdkv310.c               |    9 +-
  arch/arm/mach-exynos/mach-universal_c210.c         |    3 +-
  arch/arm/mach-exynos/platsmp.c                     |   32 +-
  arch/arm/mach-exynos/smc.h                         |   31 +
  arch/arm/mach-s3c24xx/Kconfig                      |   84 +-
  arch/arm/mach-s3c24xx/Makefile                     |    8 +-
  arch/arm/mach-s3c24xx/common.h                     |    1 +
  arch/arm/mach-s3c24xx/include/mach/dma.h           |    1 -
  arch/arm/mach-s3c24xx/include/mach/entry-macro.S   |   70 -
  arch/arm/mach-s3c24xx/include/mach/irqs.h          |    4 +-
  arch/arm/mach-s3c24xx/{ => include/mach}/s3c2412.h |    0
  arch/arm/mach-s3c24xx/iotiming-s3c2412.c           |    2 +-
  arch/arm/mach-s3c24xx/mach-amlm5900.c              |    2 +-
  arch/arm/mach-s3c24xx/mach-bast.c                  |    2 +-
  arch/arm/mach-s3c24xx/mach-h1940.c                 |    7 +-
  arch/arm/mach-s3c24xx/mach-n30.c                   |    4 +-
  arch/arm/mach-s3c24xx/mach-otom.c                  |    2 +-
  arch/arm/mach-s3c24xx/mach-qt2410.c                |    2 +-
  arch/arm/mach-s3c24xx/mach-smdk2410.c              |    2 +-
  arch/arm/mach-s3c24xx/mach-tct_hammer.c            |    2 +-
  arch/arm/mach-s3c24xx/mach-vr1000.c                |    2 +-
  arch/arm/mach-s3c24xx/regs-dsc.h                   |  203 +---
  arch/arm/mach-s3c64xx/Makefile                     |    1 -
  arch/arm/mach-s3c64xx/dma.c                        |    1 +
  arch/arm/mach-s3c64xx/include/mach/dma.h           |    1 -
  arch/arm/mach-s3c64xx/mach-crag6410-module.c       |    1 +
  arch/arm/plat-samsung/Kconfig                      |   18 +-
  arch/arm/plat-samsung/devs.c                       |    2 +-
  arch/arm/plat-samsung/dma-ops.c                    |   10 +-
  arch/arm/plat-samsung/include/plat/cpu-freq-core.h |   10 +-
  arch/arm/plat-samsung/include/plat/cpu-freq.h      |    6 +-
  arch/arm/plat-samsung/include/plat/cpu.h           |    1 -
  arch/arm/plat-samsung/include/plat/dma-ops.h       |    1 -
  arch/arm/plat-samsung/include/plat/dma-pl330.h     |    1 -
  arch/arm/plat-samsung/include/plat/map-s5p.h       |    1 +
  arch/arm/plat-samsung/include/plat/rtc-core.h      |    2 +-
  arch/arm/plat-samsung/include/plat/sdhci.h         |    4 +-
  arch/arm/plat-samsung/s5p-sleep.S                  |    9 +
  arch/arm/plat-samsung/setup-mipiphy.c              |    3 +
  drivers/clk/Makefile                               |    1 +
  drivers/clk/samsung/Makefile                       |    8 +
  drivers/clk/samsung/clk-exynos4.c                  | 1091 +++++++++++++
  drivers/clk/samsung/clk-exynos5250.c               |  523 +++++++
  drivers/clk/samsung/clk-exynos5440.c               |  139 ++
  drivers/clk/samsung/clk-pll.c                      |  419 +++++
  drivers/clk/samsung/clk-pll.h                      |   41 +
  drivers/clk/samsung/clk.c                          |  320 ++++
  drivers/clk/samsung/clk.h                          |  289 ++++
  drivers/clocksource/Kconfig                        |    5 +
  drivers/clocksource/Makefile                       |    1 +
  .../mct.c => drivers/clocksource/exynos_mct.c      |  210 ++-
  drivers/cpufreq/Kconfig.arm                        |   58 +
  drivers/cpufreq/Makefile                           |    9 +-
  .../cpufreq/s3c2410-cpufreq.c                      |    0
  .../cpufreq/s3c2412-cpufreq.c                      |    3 +-
  .../cpufreq/s3c2440-cpufreq.c                      |    0
  .../cpufreq/s3c24xx-cpufreq-debugfs.c              |    0
  .../cpufreq.c => drivers/cpufreq/s3c24xx-cpufreq.c |    0
  drivers/irqchip/Makefile                           |    1 +
  drivers/irqchip/exynos-combiner.c                  |   80 +-
  .../irq.c => drivers/irqchip/irq-s3c24xx.c         |  523 +++++--
  drivers/pinctrl/pinctrl-exynos5440.c               |  151 ++-
  drivers/usb/host/ohci-exynos.c                     |    3 +-
  .../{usb-exynos.h => usb-ohci-exynos.h}            |    0
  125 files changed, 7801 insertions(+), 5249 deletions(-)
  create mode 100644 Documentation/arm/firmware.txt
  create mode 100644 
Documentation/devicetree/bindings/arm/samsung/sysreg.txt
  create mode 100644 
Documentation/devicetree/bindings/clock/exynos4-clock.txt
  create mode 100644 
Documentation/devicetree/bindings/clock/exynos5250-clock.txt
  create mode 100644 
Documentation/devicetree/bindings/clock/exynos5440-clock.txt
  create mode 100644 Documentation/devicetree/bindings/gpu/samsung-g2d.txt
  create mode 100644 
Documentation/devicetree/bindings/interrupt-controller/samsung,s3c24xx-irq.txt
  create mode 100644 
Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.txt
  create mode 100644 Documentation/devicetree/bindings/usb/exynos-usb.txt
  create mode 100644 
Documentation/devicetree/bindings/video/samsung-fimd.txt
  create mode 100644 arch/arm/boot/dts/exynos4412-odroidx.dts
  create mode 100644 arch/arm/boot/dts/exynos4412-origen.dts
  create mode 100644 arch/arm/boot/dts/exynos5250-arndale.dts
  create mode 100644 arch/arm/boot/dts/exynos5250-pinctrl.dtsi
  create mode 100644 arch/arm/boot/dts/exynos5440-sd5v1.dts
  create mode 100644 arch/arm/common/firmware.c
  create mode 100644 arch/arm/include/asm/firmware.h
  delete mode 100644 arch/arm/mach-exynos/clock-exynos4.c
  delete mode 100644 arch/arm/mach-exynos/clock-exynos4.h
  delete mode 100644 arch/arm/mach-exynos/clock-exynos4210.c
  delete mode 100644 arch/arm/mach-exynos/clock-exynos4212.c
  delete mode 100644 arch/arm/mach-exynos/clock-exynos5.c
  create mode 100644 arch/arm/mach-exynos/exynos-smc.S
  create mode 100644 arch/arm/mach-exynos/firmware.c
  delete mode 100644 arch/arm/mach-exynos/include/mach/regs-mct.h
  create mode 100644 arch/arm/mach-exynos/smc.h
  delete mode 100644 arch/arm/mach-s3c24xx/include/mach/entry-macro.S
  rename arch/arm/mach-s3c24xx/{ => include/mach}/s3c2412.h (100%)
  create mode 100644 drivers/clk/samsung/Makefile
  create mode 100644 drivers/clk/samsung/clk-exynos4.c
  create mode 100644 drivers/clk/samsung/clk-exynos5250.c
  create mode 100644 drivers/clk/samsung/clk-exynos5440.c
  create mode 100644 drivers/clk/samsung/clk-pll.c
  create mode 100644 drivers/clk/samsung/clk-pll.h
  create mode 100644 drivers/clk/samsung/clk.c
  create mode 100644 drivers/clk/samsung/clk.h
  rename arch/arm/mach-exynos/mct.c => drivers/clocksource/exynos_mct.c 
(64%)
  rename arch/arm/mach-s3c24xx/cpufreq-s3c2410.c => 
drivers/cpufreq/s3c2410-cpufreq.c (100%)
  rename arch/arm/mach-s3c24xx/cpufreq-s3c2412.c => 
drivers/cpufreq/s3c2412-cpufreq.c (99%)
  rename arch/arm/mach-s3c24xx/cpufreq-s3c2440.c => 
drivers/cpufreq/s3c2440-cpufreq.c (100%)
  rename arch/arm/mach-s3c24xx/cpufreq-debugfs.c => 
drivers/cpufreq/s3c24xx-cpufreq-debugfs.c (100%)
  rename arch/arm/mach-s3c24xx/cpufreq.c => 
drivers/cpufreq/s3c24xx-cpufreq.c (100%)
  rename arch/arm/mach-s3c24xx/irq.c => drivers/irqchip/irq-s3c24xx.c (75%)
  rename include/linux/platform_data/{usb-exynos.h => usb-ohci-exynos.h} 
(100%)


From kgene.kim at samsung.com  Mon Apr  8 14:17:51 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Tue, 09 Apr 2013 03:17:51 +0900
Subject: [GIT PULL 01/10] cleanup-samsung for v3.10
Message-ID: <516309CF.6030202@samsung.com>

The following changes since commit a937538b868b8369b98967929045f1df54234323:

   Linux 3.9-rc3 (2013-03-17 15:59:32 -0700)

are available in the git repository at:

   git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git 
tags/cleanup-samsung-for-v3.10

for you to fetch changes up to fe72e27368265a99f6a0a189a5d593aac320a59d:

   ARM: EXYNOS: remove "config EXYNOS_DEV_DRM" (2013-04-09 00:32:38 +0900)

----------------------------------------------------------------
cleanup unused codes for samsung

----------------------------------------------------------------
Alexander Shiyan (3):
       ARM: S3C24XX: Removed unneeded dependency on ARCH_S3C24XX for boards
       ARM: S3C24XX: Removed unneeded dependency on CPU_S3C2410
       ARM: S3C24XX: Removed unneeded dependency on CPU_S3C2412

Jingoo Han (1):
       ARM: EXYNOS: change the name of USB ohci header

Padmavathi Venna (1):
       ARM: SAMSUNG: Remove unnecessary code for dma

Paul Bolle (11):
       ARM: S3C24XX: drop "select MACH_N35"
       ARM: S3C24XX: drop "select MACH_NEO1973"
       ARM: EXYNOS: drop "select HAVE_SCHED_CLOCK"
       ARM: EXYNOS: change HAVE_SAMSUNG_KEYPAD to KEYBOARD_SAMSUNG
       ARM: SAMSUNG: remove "config S3C_BOOT_WATCHDOG"
       ARM: SAMSUNG: Remove useless Samsung GPIO related CONFIG
       ARM: S3C24XX: remove unneeded "config SMDK2440_CPU2442"
       ARM: S3C64XX: remove obsolete Makefile line
       ARM: S5P64X0: Fix typo "CONFIG_S5P64X0_SETUP_SDHCI"
       ARM: SAMSUNG: Fix typo "CONFIG_SAMSUNG_DEV_RTC"
       ARM: EXYNOS: remove "config EXYNOS_DEV_DRM"

Sylwester Nawrocki (1):
       ARM: S3C24XX: Remove unused GPIO drive strength register definitions

Wei Yongjun (1):
       ARM: EXYNOS: remove duplicated include from common.c

  arch/arm/Kconfig                                   |   1 -
  arch/arm/mach-exynos/Kconfig                       |  13 +-
  arch/arm/mach-exynos/common.c                      |   1 -
  arch/arm/mach-exynos/dev-ohci.c                    |   2 +-
  arch/arm/mach-exynos/mach-origen.c                 |   2 +-
  arch/arm/mach-exynos/mach-smdkv310.c               |   2 +-
  arch/arm/mach-s3c24xx/Kconfig                      |  22 +--
  arch/arm/mach-s3c24xx/include/mach/dma.h           |   1 -
  arch/arm/mach-s3c24xx/regs-dsc.h                   | 203 
+--------------------
  arch/arm/mach-s3c64xx/Makefile                     |   1 -
  arch/arm/mach-s3c64xx/include/mach/dma.h           |   1 -
  arch/arm/plat-samsung/Kconfig                      |  14 --
  arch/arm/plat-samsung/dma-ops.c                    |  10 +-
  arch/arm/plat-samsung/include/plat/dma-ops.h       |   1 -
  arch/arm/plat-samsung/include/plat/dma-pl330.h     |   1 -
  arch/arm/plat-samsung/include/plat/rtc-core.h      |   2 +-
  arch/arm/plat-samsung/include/plat/sdhci.h         |   4 +-
  drivers/usb/host/ohci-exynos.c                     |   3 +-
  .../{usb-exynos.h => usb-ohci-exynos.h}            |   0
  19 files changed, 20 insertions(+), 264 deletions(-)
  rename include/linux/platform_data/{usb-exynos.h => usb-ohci-exynos.h} 
(100%)
-- 
Thanks.

Best regards,
Kgene.
--
Kukjin Kim <kgene.kim at samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.


From kgene.kim at samsung.com  Mon Apr  8 14:18:01 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Tue, 09 Apr 2013 03:18:01 +0900
Subject: [GIT PULL 02/10] 2nd irq-s3c24xx for v3.10
Message-ID: <516309D9.7000609@samsung.com>

The following changes since commit d98fedef912832611b668fa7ece8e8ff54a6a590:

   gpio: samsung: fixes build warning with s3c2410_defconfig (2013-03-05 
20:21:36 +0900)

are available in the git repository at:

   git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git 
tags/irq-s3c24xx-for-v3.10

for you to fetch changes up to f0774d41da0e607b70e54ecc50aeb6684f54c2b1:

   irqchip: s3c24xx: add devicetree support (2013-04-04 14:56:30 +0900)

----------------------------------------------------------------
s3c24xx irq cleanup and move into drivers/irqchip

----------------------------------------------------------------
Heiko Stuebner (12):
       ARM: S3C24XX: fix redundant checks in the irq mapping function
       ARM: S3C24XX: fix irq parent check
       ARM: S3C24XX: move s3c24xx_init_irq to s3c2410_init_irq
       ARM: S3C24XX: make s3c24xx_init_intc static
       ARM: S3C24XX: add handle_irq function
       ARM: S3C24XX: move irq driver to drivers/irqchip
       irqchip: s3c24xx: fix comments on some camera interrupts
       irqchip: s3c24xx: fix irqlist of second s3c2416 controller
       irqchip: s3c24xx: add irq_set_type callback for basic interrupt types
       irqchip: s3c24xx: globally keep track of the created intc instances
       irqchip: s3c24xx: make interrupt handling independent of 
irq_domain structure
       irqchip: s3c24xx: add devicetree support

  .../interrupt-controller/samsung,s3c24xx-irq.txt   |  53 +++
  arch/arm/Kconfig                                   |   1 +
  arch/arm/mach-s3c24xx/Makefile                     |   2 +-
  arch/arm/mach-s3c24xx/common.h                     |   1 +
  arch/arm/mach-s3c24xx/include/mach/entry-macro.S   |  70 ---
  arch/arm/mach-s3c24xx/mach-amlm5900.c              |   2 +-
  arch/arm/mach-s3c24xx/mach-bast.c                  |   2 +-
  arch/arm/mach-s3c24xx/mach-h1940.c                 |   7 +-
  arch/arm/mach-s3c24xx/mach-n30.c                   |   4 +-
  arch/arm/mach-s3c24xx/mach-otom.c                  |   2 +-
  arch/arm/mach-s3c24xx/mach-qt2410.c                |   2 +-
  arch/arm/mach-s3c24xx/mach-smdk2410.c              |   2 +-
  arch/arm/mach-s3c24xx/mach-tct_hammer.c            |   2 +-
  arch/arm/mach-s3c24xx/mach-vr1000.c                |   2 +-
  arch/arm/plat-samsung/include/plat/cpu.h           |   1 -
  drivers/irqchip/Makefile                           |   1 +
  .../irq.c => drivers/irqchip/irq-s3c24xx.c         | 523 
++++++++++++++++-----
  17 files changed, 472 insertions(+), 205 deletions(-)
  create mode 100644 
Documentation/devicetree/bindings/interrupt-controller/samsung,s3c24xx-irq.txt
  delete mode 100644 arch/arm/mach-s3c24xx/include/mach/entry-macro.S
  rename arch/arm/mach-s3c24xx/irq.c => drivers/irqchip/irq-s3c24xx.c (75%)

-- 
Thanks.

Best regards,
Kgene.
--
Kukjin Kim <kgene.kim at samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.


From kgene.kim at samsung.com  Mon Apr  8 14:18:22 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Tue, 09 Apr 2013 03:18:22 +0900
Subject: [GIT PULL 03/10] mct-exynos for v3.10
Message-ID: <516309EE.30000@samsung.com>

The following changes since commit 6dbe51c251a327e012439c4772097a13df43c5b8:

   Linux 3.9-rc1 (2013-03-03 15:11:05 -0800)

are available in the git repository at:

   git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git 
tags/mct-exynos-for-v3.10

for you to fetch changes up to 354599f460ba79c9fb00f220e42de5a7509ceeb4:

   clocksource: mct: Add terminating entry for exynos_mct_ids table 
(2013-04-04 15:35:42 +0900)

----------------------------------------------------------------
add support exynos mct device tree and move into drivers/clocksource

----------------------------------------------------------------
Axel Lin (1):
       clocksource: mct: Add terminating entry for exynos_mct_ids table

Doug Anderson (1):
       clocksource: mct: Add missing semicolons in exynos_mct.c

Thomas Abraham (7):
       ARM: EXYNOS: add a register base address variable in mct 
controller driver
       ARM: EXYNOS: prepare an array of MCT interrupt numbers and use it
       ARM: EXYNOS: add device tree support for MCT controller driver
       ARM: EXYNOS: allow dt based discovery of mct controller using 
clocksource_of_init
       ARM: dts: add mct device tree node for all supported Exynos SoC's
       ARM: EXYNOS: remove static io-remapping of mct registers for Exynos5
       ARM: EXYNOS: move mct driver to drivers/clocksource

  .../bindings/timer/samsung,exynos4210-mct.txt      |  68 +++++++
  arch/arm/Kconfig                                   |   2 +-
  arch/arm/boot/dts/exynos4210.dtsi                  |  22 +++
  arch/arm/boot/dts/exynos4212.dtsi                  |  22 +++
  arch/arm/boot/dts/exynos4412.dtsi                  |  24 +++
  arch/arm/boot/dts/exynos5250.dtsi                  |  22 +++
  arch/arm/mach-exynos/Kconfig                       |   8 +-
  arch/arm/mach-exynos/Makefile                      |   2 -
  arch/arm/mach-exynos/common.c                      |   5 -
  arch/arm/mach-exynos/common.h                      |   2 +-
  arch/arm/mach-exynos/include/mach/irqs.h           |   6 -
  arch/arm/mach-exynos/include/mach/map.h            |   1 -
  arch/arm/mach-exynos/include/mach/regs-mct.h       |  53 ------
  arch/arm/mach-exynos/mach-armlex4210.c             |   2 +-
  arch/arm/mach-exynos/mach-exynos4-dt.c             |   3 +-
  arch/arm/mach-exynos/mach-exynos5-dt.c             |   3 +-
  arch/arm/mach-exynos/mach-nuri.c                   |   2 +-
  arch/arm/mach-exynos/mach-origen.c                 |   2 +-
  arch/arm/mach-exynos/mach-smdk4x12.c               |   4 +-
  arch/arm/mach-exynos/mach-smdkv310.c               |   4 +-
  drivers/clocksource/Kconfig                        |   5 +
  drivers/clocksource/Makefile                       |   1 +
  .../mct.c => drivers/clocksource/exynos_mct.c      | 196 
++++++++++++++-------
  23 files changed, 310 insertions(+), 149 deletions(-)
  create mode 100644 
Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.txt
  delete mode 100644 arch/arm/mach-exynos/include/mach/regs-mct.h
  rename arch/arm/mach-exynos/mct.c => drivers/clocksource/exynos_mct.c 
(67%)

-- 
Thanks.

Best regards,
Kgene.
--
Kukjin Kim <kgene.kim at samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.


From lauraa at codeaurora.org  Mon Apr  8 14:18:46 2013
From: lauraa at codeaurora.org (Laura Abbott)
Date: Mon, 08 Apr 2013 11:18:46 -0700
Subject: [RFC][PATCH] arm: highmem: Add support for flushing kmap_atomic
 mappings
In-Reply-To: <alpine.LFD.2.03.1304061006530.1171@syhkavp.arg>
References: <1365198171-8469-1-git-send-email-lauraa@codeaurora.org>
 <alpine.LFD.2.03.1304061006530.1171@syhkavp.arg>
Message-ID: <51630A06.90702@codeaurora.org>

On 4/6/2013 7:22 AM, Nicolas Pitre wrote:
> On Fri, 5 Apr 2013, Laura Abbott wrote:
>
>> The highmem code provides kmap_flush_unused to ensure all kmap
>> mappings are really removed if they are used. This code does not
>
> You meant "if they are *not* used", right?
>

Yes, missed a word there

>> handle kmap_atomic mappings since they are managed separately.
>> This prevents an issue for any code which relies on having absolutely
>> no mappings for a particular page. Rather than pay the penalty of
>> having CONFIG_DEBUG_HIGHMEM on all the time, add functionality
>> to remove the kmap_atomic mappings in a similar way to kmap_flush_unused.
>
> Could you elaborate on that code that relies on having absolutely no
> mappings for a particular page please?
>

We have a use case where we pass memory to trustzone to have it 
protected such that the non-secure environment may not read or write 
that memory. The protecting/unprotecting can happen at runtime. If there 
are any valid mappings in the page tables, the CPU is free to 
speculatively access that memory. If the CPU speculates into a protected 
region while in the non-secure world, we get a fault violation. 
Essentially this means that even if we reserve the memory at bootup time 
with memblock_reserve, if  the memory was ever previously mapped with 
kmap_atomic (to flush caches for example) we could still end up with 
stray mappings which can lead to faults.

In general, it seems like this is missing functionality from the 
intended behavior of kmap_flush_unused which is to get rid of all stray 
mappings.


>> This is intended to be an RFC to make sure this approach is
>> reasonable. The goal is to have kmap_atomic_flush_unused be a public
>> API.
>
> The clearing code is going to be costly since you do a
> set_top_pte(vaddr, __pte(0)) unconditionally on the whole range,
> regardless if the PTE is already set to 0.
>

Good point. I'll add a check for that.

> Using it via an hotplug callback is rather strange, but I'm assuming
> that this was only for testing?
>

The hotplug callback is needed because we clear the mappings per-CPU. If 
a CPU is hotplugged out with stray mappings they will not be cleared 
since on_each_cpu only works on online CPUs.

>
> Nicolas
>

Thanks,
Laura

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation


From kgene.kim at samsung.com  Mon Apr  8 14:18:42 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Tue, 09 Apr 2013 03:18:42 +0900
Subject: [GIT PULL 04/10] clk-exynos for v3.10
Message-ID: <51630A02.4080905@samsung.com>

The following changes since commit 07961ac7c0ee8b546658717034fe692fd12eefa9:

   Linux 3.9-rc5 (2013-03-31 15:12:43 -0700)

are available in the git repository at:

   git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git 
tags/clk-exynos-for-v3.10

for you to fetch changes up to da821eb7d42935b0f7056d98c75fd1150f6636f4:

   Merge commit 'v3.9-rc5' into next/clk-exynos (2013-04-09 01:10:13 +0900)

----------------------------------------------------------------

add suppport common clock framework for exynos

----------------------------------------------------------------
Abhilash Kesavan (1):
       ARM: dts: Add max77686 device tree support for CROS5250

Andrzej Hajda (1):
       clk: exynos4: Add missing CMU_TOP and ISP clocks

Dongjin Kim (3):
       ARM: dts: Add board dts file for ODROID-X
       ARM: dts: Fix the timing property of MSHC controller for 
exynos4412-odroidx
       ARM: dts: enable RTC device node for exynos4412-odroidx

Giridhar Maruthy (3):
       ARM: dts: remove disabled status from watchdog node for 
exynos5440-ssdk5440
       ARM: dts: remove disabled status from RTC node for 
exynos5440-ssdk5440
       ARM: dts: change compatible value for exynos5440 i2c

Girish K S (1):
       ARM: dts: Add initial board support file for exynos5250-arndale

Heiko Stueber (1):
       clk: samsung: fix pm init on non-dt platforms

Heiko Stuebner (6):
       ARM: S3C24XX: remove plat/irq.h in plat-samsung
       ARM: S3C24XX: move plat-samsung/s3c24XX headers to local common.h
       ARM: S3C24XX: cleanup the included soc init functions in common.h
       clk: samsung: register clk_div_tables for divider clocks
       clk: samsung: always allocate the clk_table
       clk: samsung: add infrastructure to add separate aliases

Jingoo Han (2):
       ARM: EXYNOS: Add AUXDATA for DP controller
       ARM: dts: Add device tree node for DP controller for exynos5250

Kukjin Kim (7):
       mmc: s3cmci: moved mach/regs-sdi.h into s3cmci device driver
       ARM: S3C24XX: plat/common-smdk.h local
       ARM: dts: cleanup exynos5440.dtsi
       ARM: dts: re-organized cpu node for exynos5440
       Merge branch 'next/timer-samsung' into next/clk-exynos
       Merge branch 'next/mct-exynos' into next/clk-exynos
       Merge commit 'v3.9-rc5' into next/clk-exynos

Leela Krishna Amudala (1):
       clk: exynos5250: register display block gate clocks to common 
clock framework

Lukasz Majewski (1):
       clk: exynos4: Export clocks used by exynos cpufreq drivers

Prasanna Kumar (1):
       ARM: dts: Set up power domain for MFC and G-scaler for exynos5250

Romain Naour (5):
       ARM: SAMSUNG: Rename s5p-time to samsung-time
       ARM: S3C24XX: Add samsung-time support for s3c24xx
       ARM: S3C64XX: Add samsung-time support for s3c64xx
       ARM: S5PC100: Add samsung-time support for s5pc100
       ARM: SAMSUNG: Remove unused plat-samsung/time.c

Sachin Kamat (12):
       ARM: dts: Add vmmc regulator node in exynos4412-origen.dts
       ARM: dts: Add sdhci node for exynos4412-origen
       ARM: dts: Update MFC DT binding documentation
       ARM: dts: Add MFC codec support for EXYNOS4 DT machines
       ARM: dts: Add MFC codec support to SMDKV310 DT
       ARM: dts: Add MFC codec support to Origen DT
       ARM: dts: Add MFC codec entry to exynos4412-origen DT
       ARM: dts: Add MFC codec entry to exynos4412-smdk4412 DT
       ARM: dts: Add MSHC node for exynos4412-origen DT
       ARM: dts: Add s5m8767 PMIC node to exynos4412-origen DT
       ARM: dts: Add sdhci node for exynos4412-smdk4412
       clk: samsung: Fix compilation error

Sylwester Nawrocki (3):
       clk: exynos4: Correct sclk_mfc clock definition
       clk: exynos4: Add camera related clock definitions
       clk: exynos4: export clocks required for fimc-is

Thomas Abraham (25):
       ARM: dts: add board dts file for EXYNOS4412 based Origen board
       ARM: EXYNOS: add a register base address variable in mct 
controller driver
       ARM: EXYNOS: prepare an array of MCT interrupt numbers and use it
       ARM: EXYNOS: add device tree support for MCT controller driver
       ARM: EXYNOS: allow dt based discovery of mct controller using 
clocksource_of_init
       ARM: dts: add mct device tree node for all supported Exynos SoC's
       ARM: EXYNOS: remove static io-remapping of mct registers for Exynos5
       ARM: EXYNOS: move mct driver to drivers/clocksource
       clk: samsung: add common clock framework helper functions for 
Samsung platforms
       clk: samsung: add pll clock registration helper functions
       clk: exynos4: register clocks using common clock framework
       clk: exynos5250: register clocks using common clock framework
       clk: exynos5440: register clocks using common clock framework
       ARM: EXYNOS: Migrate clock support to common clock framework
       ARM: EXYNOS: Initialize the clocks prior to timer initialization
       ARM: EXYNOS: allow legacy board support to specify xxti and 
xusbxti clock speed
       ARM: EXYNOS: remove auxdata table from exynos4/5 dt machine file
       clocksource: mct: use fin_pll clock as the tick clock source for mct
       clocksource: mct: add support for mct clock setup
       ARM: dts: add Exynos4 and Exynos5 clock controller nodes
       ARM: dts: add clock provider information for all controllers in 
Exynos4 SoCs
       ARM: dts: add clock provider information for all controllers in 
Exynos5250 SoC
       ARM: dts: add clock provider information for all controllers in 
Exynos5440 SoC
       ARM: dts: add board specific fixed rate clock nodes for Exynos 
based platforms
       ARM: EXYNOS: fix compilation error introduced due to common clock 
migration

Tomasz Figa (17):
       clk: exynos4: Use mout_mpll_user_* on Exynos4x12
       clk: exynos4: Add missing mout_mipihsi clock
       clk: exynos4: Add missing sclk_audio0 clock
       clk: exynos4: Export sclk_pcm0
       clk: exynos4: Move dac and mixer to Exynos4210-specific clocks
       clk: samsung: Remove unimplemented ops for pll
       clk: exynos4: Export mout_core clock of Exynos4210
       clk: exynos4: Add G3D clocks
       clk: exynos4: Add missing mout_sata on Exynos4210
       clk: exynos4: Define {E,V}PLL registers
       clk: exynos4: Use SRC_MASK_PERIL{0,1} definitions
       clk: exynos4: Remove SoC-specific registers from save list
       clk: exynos4: Add E4210 prefix to LCD1 clock registers
       clk: exynos4: Add E4210 prefix to GATE_IP_PERIR register
       clk: exynos4: Remove E4X12 prefix from SRC_DMC register
       clk: exynos4: Add missing registers to suspend save list
       clk: exynos4: Add support for SoC-specific register save list

Tushar Behera (1):
       clk: exynos5250: Fix divider values for sclk_mmc{0,1,2,3}

Vivek Gautam (2):
       ARM: dts: Enabling ehci-s5p driver for EXYNOS5250
       ARM: dts: Enabling ohci-exynos driver for EXYNOS5250

  .../devicetree/bindings/clock/exynos4-clock.txt    |  288 ++++
  .../devicetree/bindings/clock/exynos5250-clock.txt |  177 +++
  .../devicetree/bindings/clock/exynos5440-clock.txt |   61 +
  .../devicetree/bindings/media/s5p-mfc.txt          |   21 +
  .../bindings/timer/samsung,exynos4210-mct.txt      |   68 +
  .../devicetree/bindings/usb/exynos-usb.txt         |   40 +
  arch/arm/Kconfig                                   |   14 +-
  arch/arm/boot/dts/Makefile                         |    3 +
  arch/arm/boot/dts/cros5250-common.dtsi             |  138 ++
  arch/arm/boot/dts/exynos4.dtsi                     |   58 +
  arch/arm/boot/dts/exynos4210-origen.dts            |   18 +
  arch/arm/boot/dts/exynos4210-smdkv310.dts          |   18 +
  arch/arm/boot/dts/exynos4210-trats.dts             |   12 +
  arch/arm/boot/dts/exynos4210.dtsi                  |   30 +
  arch/arm/boot/dts/exynos4212.dtsi                  |   22 +
  arch/arm/boot/dts/exynos4412-odroidx.dts           |  109 ++
  arch/arm/boot/dts/exynos4412-origen.dts            |  430 +++++
  arch/arm/boot/dts/exynos4412-smdk4412.dts          |   25 +
  arch/arm/boot/dts/exynos4412.dtsi                  |   26 +
  arch/arm/boot/dts/exynos4x12.dtsi                  |    6 +
  arch/arm/boot/dts/exynos5250-arndale.dts           |  129 ++
  arch/arm/boot/dts/exynos5250-smdk5250.dts          |   20 +
  arch/arm/boot/dts/exynos5250-snow.dts              |   11 +
  arch/arm/boot/dts/exynos5250.dtsi                  |  142 ++
  arch/arm/boot/dts/exynos5440-ssdk5440.dts          |   19 +-
  arch/arm/boot/dts/exynos5440.dtsi                  |   66 +-
  arch/arm/mach-exynos/Kconfig                       |   12 +-
  arch/arm/mach-exynos/Makefile                      |    6 -
  arch/arm/mach-exynos/clock-exynos4.c               | 1601 
-------------------
  arch/arm/mach-exynos/clock-exynos4.h               |   35 -
  arch/arm/mach-exynos/clock-exynos4210.c            |  187 ---
  arch/arm/mach-exynos/clock-exynos4212.c            |  201 ---
  arch/arm/mach-exynos/clock-exynos5.c               | 1645 
--------------------
  arch/arm/mach-exynos/common.c                      |   59 +-
  arch/arm/mach-exynos/common.h                      |   10 +-
  arch/arm/mach-exynos/include/mach/irqs.h           |    6 -
  arch/arm/mach-exynos/include/mach/map.h            |    1 -
  arch/arm/mach-exynos/include/mach/regs-clock.h     |  107 --
  arch/arm/mach-exynos/include/mach/regs-mct.h       |   53 -
  arch/arm/mach-exynos/mach-armlex4210.c             |    3 +-
  arch/arm/mach-exynos/mach-exynos4-dt.c             |  122 +-
  arch/arm/mach-exynos/mach-exynos5-dt.c             |  141 +-
  arch/arm/mach-exynos/mach-nuri.c                   |    5 +-
  arch/arm/mach-exynos/mach-origen.c                 |    5 +-
  arch/arm/mach-exynos/mach-smdk4x12.c               |    5 +-
  arch/arm/mach-exynos/mach-smdkv310.c               |    7 +-
  arch/arm/mach-exynos/mach-universal_c210.c         |    9 +-
  arch/arm/mach-s3c24xx/Kconfig                      |    6 +
  arch/arm/mach-s3c24xx/bast-irq.c                   |    2 -
  arch/arm/mach-s3c24xx/clock-s3c2410.c              |    1 -
  arch/arm/mach-s3c24xx/clock-s3c2412.c              |    1 -
  arch/arm/mach-s3c24xx/clock-s3c2416.c              |    1 -
  arch/arm/mach-s3c24xx/clock-s3c2443.c              |    1 -
  arch/arm/mach-s3c24xx/common-smdk.c                |    3 +-
  .../include/plat => mach-s3c24xx}/common-smdk.h    |    3 +-
  arch/arm/mach-s3c24xx/common.c                     |    7 +-
  arch/arm/mach-s3c24xx/common.h                     |   90 +-
  arch/arm/mach-s3c24xx/dma-s3c2410.c                |    1 -
  arch/arm/mach-s3c24xx/dma-s3c2412.c                |    1 -
  arch/arm/mach-s3c24xx/dma-s3c2440.c                |    1 -
  arch/arm/mach-s3c24xx/dma-s3c2443.c                |    1 -
  arch/arm/mach-s3c24xx/include/mach/regs-sdi.h      |  127 --
  arch/arm/mach-s3c24xx/irq-pm.c                     |    7 +-
  arch/arm/mach-s3c24xx/irq.c                        |    8 +-
  arch/arm/mach-s3c24xx/mach-amlm5900.c              |    5 +-
  arch/arm/mach-s3c24xx/mach-anubis.c                |    4 +-
  arch/arm/mach-s3c24xx/mach-at2440evb.c             |    4 +-
  arch/arm/mach-s3c24xx/mach-bast.c                  |    4 +-
  arch/arm/mach-s3c24xx/mach-gta02.c                 |    4 +-
  arch/arm/mach-s3c24xx/mach-h1940.c                 |    5 +-
  arch/arm/mach-s3c24xx/mach-jive.c                  |    6 +-
  arch/arm/mach-s3c24xx/mach-mini2440.c              |    4 +-
  arch/arm/mach-s3c24xx/mach-n30.c                   |    7 +-
  arch/arm/mach-s3c24xx/mach-nexcoder.c              |    6 +-
  arch/arm/mach-s3c24xx/mach-osiris.c                |    4 +-
  arch/arm/mach-s3c24xx/mach-otom.c                  |    5 +-
  arch/arm/mach-s3c24xx/mach-qt2410.c                |    6 +-
  arch/arm/mach-s3c24xx/mach-rx1950.c                |    4 +-
  arch/arm/mach-s3c24xx/mach-rx3715.c                |    4 +-
  arch/arm/mach-s3c24xx/mach-smdk2410.c              |    7 +-
  arch/arm/mach-s3c24xx/mach-smdk2413.c              |   13 +-
  arch/arm/mach-s3c24xx/mach-smdk2416.c              |    8 +-
  arch/arm/mach-s3c24xx/mach-smdk2440.c              |    9 +-
  arch/arm/mach-s3c24xx/mach-smdk2443.c              |    9 +-
  arch/arm/mach-s3c24xx/mach-tct_hammer.c            |    4 +-
  arch/arm/mach-s3c24xx/mach-vr1000.c                |    4 +-
  arch/arm/mach-s3c24xx/mach-vstms.c                 |    7 +-
  arch/arm/mach-s3c24xx/pm-s3c2412.c                 |    1 -
  arch/arm/mach-s3c24xx/s3c2410.c                    |    1 -
  arch/arm/mach-s3c24xx/s3c2412.c                    |    1 -
  arch/arm/mach-s3c24xx/s3c2416.c                    |    1 -
  arch/arm/mach-s3c24xx/s3c2440.c                    |    1 -
  arch/arm/mach-s3c24xx/s3c2442.c                    |    1 -
  arch/arm/mach-s3c24xx/s3c2443.c                    |    1 -
  arch/arm/mach-s3c24xx/s3c244x.c                    |    2 -
  arch/arm/mach-s3c64xx/Kconfig                      |    2 +
  arch/arm/mach-s3c64xx/mach-anw6410.c               |    4 +-
  arch/arm/mach-s3c64xx/mach-crag6410.c              |    4 +-
  arch/arm/mach-s3c64xx/mach-hmt.c                   |    4 +-
  arch/arm/mach-s3c64xx/mach-mini6410.c              |    4 +-
  arch/arm/mach-s3c64xx/mach-ncp.c                   |    4 +-
  arch/arm/mach-s3c64xx/mach-real6410.c              |    4 +-
  arch/arm/mach-s3c64xx/mach-smartq.c                |    2 +
  arch/arm/mach-s3c64xx/mach-smartq5.c               |    3 +-
  arch/arm/mach-s3c64xx/mach-smartq7.c               |    3 +-
  arch/arm/mach-s3c64xx/mach-smdk6400.c              |    4 +-
  arch/arm/mach-s3c64xx/mach-smdk6410.c              |    4 +-
  arch/arm/mach-s5p64x0/Kconfig                      |    4 +-
  arch/arm/mach-s5p64x0/mach-smdk6440.c              |    6 +-
  arch/arm/mach-s5p64x0/mach-smdk6450.c              |    6 +-
  arch/arm/mach-s5pc100/Kconfig                      |    1 +
  arch/arm/mach-s5pc100/mach-smdkc100.c              |    4 +-
  arch/arm/mach-s5pv210/Kconfig                      |    2 +-
  arch/arm/mach-s5pv210/mach-aquila.c                |    6 +-
  arch/arm/mach-s5pv210/mach-goni.c                  |    6 +-
  arch/arm/mach-s5pv210/mach-smdkc110.c              |    6 +-
  arch/arm/mach-s5pv210/mach-smdkv210.c              |    6 +-
  arch/arm/mach-s5pv210/mach-torbreck.c              |    6 +-
  arch/arm/plat-samsung/Kconfig                      |    6 +-
  arch/arm/plat-samsung/Makefile                     |    3 +-
  arch/arm/plat-samsung/include/plat/cpu.h           |    4 -
  arch/arm/plat-samsung/include/plat/irq.h           |  116 --
  arch/arm/plat-samsung/include/plat/s3c2410.h       |   31 -
  arch/arm/plat-samsung/include/plat/s3c2412.h       |   32 -
  arch/arm/plat-samsung/include/plat/s3c2416.h       |   37 -
  arch/arm/plat-samsung/include/plat/s3c2443.h       |   36 -
  arch/arm/plat-samsung/include/plat/s3c244x.h       |   42 -
  arch/arm/plat-samsung/include/plat/s5p-time.h      |   40 -
  arch/arm/plat-samsung/include/plat/samsung-time.h  |   53 +
  .../plat-samsung/{s5p-time.c => samsung-time.c}    |  138 +-
  arch/arm/plat-samsung/time.c                       |  287 ----
  drivers/clk/Makefile                               |    1 +
  drivers/clk/samsung/Makefile                       |    8 +
  drivers/clk/samsung/clk-exynos4.c                  | 1091 +++++++++++++
  drivers/clk/samsung/clk-exynos5250.c               |  523 +++++++
  drivers/clk/samsung/clk-exynos5440.c               |  139 ++
  drivers/clk/samsung/clk-pll.c                      |  419 +++++
  drivers/clk/samsung/clk-pll.h                      |   41 +
  drivers/clk/samsung/clk.c                          |  320 ++++
  drivers/clk/samsung/clk.h                          |  289 ++++
  drivers/clocksource/Kconfig                        |    5 +
  drivers/clocksource/Makefile                       |    1 +
  .../mct.c => drivers/clocksource/exynos_mct.c      |  209 ++-
  drivers/mmc/host/s3cmci.c                          |   83 +-
  144 files changed, 5417 insertions(+), 5206 deletions(-)
  create mode 100644 
Documentation/devicetree/bindings/clock/exynos4-clock.txt
  create mode 100644 
Documentation/devicetree/bindings/clock/exynos5250-clock.txt
  create mode 100644 
Documentation/devicetree/bindings/clock/exynos5440-clock.txt
  create mode 100644 
Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.txt
  create mode 100644 Documentation/devicetree/bindings/usb/exynos-usb.txt
  create mode 100644 arch/arm/boot/dts/exynos4412-odroidx.dts
  create mode 100644 arch/arm/boot/dts/exynos4412-origen.dts
  create mode 100644 arch/arm/boot/dts/exynos5250-arndale.dts
  delete mode 100644 arch/arm/mach-exynos/clock-exynos4.c
  delete mode 100644 arch/arm/mach-exynos/clock-exynos4.h
  delete mode 100644 arch/arm/mach-exynos/clock-exynos4210.c
  delete mode 100644 arch/arm/mach-exynos/clock-exynos4212.c
  delete mode 100644 arch/arm/mach-exynos/clock-exynos5.c
  delete mode 100644 arch/arm/mach-exynos/include/mach/regs-mct.h
  rename arch/arm/{plat-samsung/include/plat => 
mach-s3c24xx}/common-smdk.h (86%)
  delete mode 100644 arch/arm/mach-s3c24xx/include/mach/regs-sdi.h
  delete mode 100644 arch/arm/plat-samsung/include/plat/irq.h
  delete mode 100644 arch/arm/plat-samsung/include/plat/s3c2410.h
  delete mode 100644 arch/arm/plat-samsung/include/plat/s3c2412.h
  delete mode 100644 arch/arm/plat-samsung/include/plat/s3c2416.h
  delete mode 100644 arch/arm/plat-samsung/include/plat/s3c2443.h
  delete mode 100644 arch/arm/plat-samsung/include/plat/s3c244x.h
  delete mode 100644 arch/arm/plat-samsung/include/plat/s5p-time.h
  create mode 100644 arch/arm/plat-samsung/include/plat/samsung-time.h
  rename arch/arm/plat-samsung/{s5p-time.c => samsung-time.c} (68%)
  delete mode 100644 arch/arm/plat-samsung/time.c
  create mode 100644 drivers/clk/samsung/Makefile
  create mode 100644 drivers/clk/samsung/clk-exynos4.c
  create mode 100644 drivers/clk/samsung/clk-exynos5250.c
  create mode 100644 drivers/clk/samsung/clk-exynos5440.c
  create mode 100644 drivers/clk/samsung/clk-pll.c
  create mode 100644 drivers/clk/samsung/clk-pll.h
  create mode 100644 drivers/clk/samsung/clk.c
  create mode 100644 drivers/clk/samsung/clk.h
  rename arch/arm/mach-exynos/mct.c => drivers/clocksource/exynos_mct.c 
(65%)

-- 
Thanks.

Best regards,
Kgene.
--
Kukjin Kim <kgene.kim at samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.


From kgene.kim at samsung.com  Mon Apr  8 14:18:54 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Tue, 09 Apr 2013 03:18:54 +0900
Subject: [GIT PULL 05/10] dt-exynos for v3.10
Message-ID: <51630A0E.4000600@samsung.com>

The following changes since commit da821eb7d42935b0f7056d98c75fd1150f6636f4:

   Merge commit 'v3.9-rc5' into next/clk-exynos (2013-04-09 01:10:13 +0900)

are available in the git repository at:


   git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git 
tags/dt-exynos-for-v3.10

for you to fetch changes up to 58a7bbf75442ea439a4d3b7993ad87023e406063:

   ARM: dts: add PDMA0 changes for exynos5440 (2013-04-09 01:39:27 +0900)

----------------------------------------------------------------
update device tree for exynos4 and exynos5

----------------------------------------------------------------
Alexander Graf (2):
       ARM: dts: Declare the gic as a15 compatible for exynos5250
       ARM: dts: Add architected timer nodes for exynos5250

Amit Daniel Kachhap (2):
       ARM: dts: Add PMIC node entry for Arndale board
       ARM: dts: Add cpufreq controller node for Exynos5440 SoC

Byungho An (1):
       ARM: dts: Add node for GMAC for exynos5440

Doug Anderson (2):
       ARM: dts: add usb 2.0 clock references to exynos5250 device tree
       ARM: dts: Document usb clocks in samsung,exynos4210-ehci/ohci 
bindings

Giridhar Maruthy (1):
       ARM: dts: Add virtual GIC DT bindings for exynos5440

Kukjin Kim (1):
       ARM: dts: add device tree file for SD5v1 board

Leela Krishna Amudala (2):
       ARM: dts: Add FIMD node to exynos5
       ARM: dts: Add display timing node to exynos5250-smdk5250.dts

Sachin Kamat (11):
       ARM: dts: Add G2D node to exynos4210.dtsi
       ARM: dts: Add G2D node to SMDKV310
       ARM: dts: Add G2D node to exynos4210-origen
       ARM: dts: Add G2D node to exynos4x12.dtsi
       ARM: dts: Add G2D node to SMDK4412
       ARM: dts: Add G2D node to exynos4412-origen
       ARM: dts: Add Samsung G2D DT bindings documentation
       ARM: dts: Add disable-wp for card slot on exynos5250-arndale
       ARM: dts: Add vmmc regulator support for Arndale board
       ARM: dts: Add MFC codec support for Arndale board
       ARM: dts: Add HDMI HPD and regulator node for Arndale board

Subash Patel (3):
       ARM: dts: add PMU support in exynos5440
       ARM: dts: update bootargs to boot from sda2 for exynos5440-ssdk5440
       ARM: dts: add PDMA0 changes for exynos5440

Sylwester Nawrocki (1):
       ARM: dts: Add SYSREG block node for S5P/Exynos4 SoC series

Thomas Abraham (4):
       ARM: dts: add pin state information in client nodes for Exynos4 
platforms
       ARM: dts: add pin state information in client nodes for Exynos5 
platforms
       ARM: dts: list the interrupts generated by pin-controller on 
Exynos5440
       ARM: dts: Fix gmac clock ids due to changes in Exynos5440

Tushar Behera (2):
       ARM: dts: Add pin-control related changes for Arndale board
       ARM: dts: Add gpio-button entries for Arndale board

Vikas Sajjan (3):
       ARM: dts: Add FIMD node to exynos4
       ARM: dts: Add FIMD node and display timing node to 
exynos4412-origen.dts
       ARM: dts: Add FIMD DT binding Documentation

  .../devicetree/bindings/arm/samsung/sysreg.txt     |   7 +
  .../devicetree/bindings/gpu/samsung-g2d.txt        |  20 +
  .../devicetree/bindings/usb/exynos-usb.txt         |  10 +
  .../devicetree/bindings/video/samsung-fimd.txt     |  65 ++
  arch/arm/boot/dts/Makefile                         |   1 +
  arch/arm/boot/dts/cros5250-common.dtsi             |  51 +-
  arch/arm/boot/dts/exynos4.dtsi                     |  27 +
  arch/arm/boot/dts/exynos4210-origen.dts            |   4 +
  arch/arm/boot/dts/exynos4210-smdkv310.dts          |  57 +-
  arch/arm/boot/dts/exynos4210.dtsi                  |   7 +
  arch/arm/boot/dts/exynos4412-origen.dts            |  21 +
  arch/arm/boot/dts/exynos4412-smdk4412.dts          |   8 +
  arch/arm/boot/dts/exynos4x12.dtsi                  |   7 +
  arch/arm/boot/dts/exynos5250-arndale.dts           | 343 ++++++++-
  arch/arm/boot/dts/exynos5250-pinctrl.dtsi          | 783 
+++++++++++++++++++++
  arch/arm/boot/dts/exynos5250-smdk5250.dts          |  49 +-
  arch/arm/boot/dts/exynos5250-snow.dts              |  22 +-
  arch/arm/boot/dts/exynos5250.dtsi                  | 343 +++------
  arch/arm/boot/dts/exynos5440-sd5v1.dts             |  39 +
  arch/arm/boot/dts/exynos5440-ssdk5440.dts          |   6 +-
  arch/arm/boot/dts/exynos5440.dtsi                  |  55 +-
  21 files changed, 1559 insertions(+), 366 deletions(-)
  create mode 100644 
Documentation/devicetree/bindings/arm/samsung/sysreg.txt
  create mode 100644 Documentation/devicetree/bindings/gpu/samsung-g2d.txt
  create mode 100644 
Documentation/devicetree/bindings/video/samsung-fimd.txt
  create mode 100644 arch/arm/boot/dts/exynos5250-pinctrl.dtsi
  create mode 100644 arch/arm/boot/dts/exynos5440-sd5v1.dts

-- 
Thanks.

Best regards,
Kgene.
--
Kukjin Kim <kgene.kim at samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.


From kgene.kim at samsung.com  Mon Apr  8 14:19:04 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Tue, 09 Apr 2013 03:19:04 +0900
Subject: [GIT PULL 06/10] 2nd pinctrl-exynos for v3.10
Message-ID: <51630A18.6010801@samsung.com>

The following changes since commit 97916777d6904e24b86eac77da58ef7cb09d539d:

   ARM: EXYNOS: skip wakeup interrupt registration for exynos5250 if 
pinctrl is enabled (2013-03-05 20:59:12 +0900)

are available in the git repository at:

   git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git 
tags/pinctrl-exynos-for-v3.10

for you to fetch changes up to 790af0a51bdcbf504814be2673f96facfdd74981:

   pinctrl: exynos5440: add gpio interrupt support (2013-04-08 23:55:41 
+0900)

----------------------------------------------------------------
add support gpio interrupt for exynos5440

----------------------------------------------------------------
Thomas Abraham (2):
       pinctrl: exynos5440: fix probe failure due to missing pin-list in 
config nodes
       pinctrl: exynos5440: add gpio interrupt support

  drivers/pinctrl/pinctrl-exynos5440.c | 151 
++++++++++++++++++++++++++++++++++-
  1 file changed, 148 insertions(+), 3 deletions(-)

-- 
Thanks.

Best regards,
Kgene.
--
Kukjin Kim <kgene.kim at samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.


From kgene.kim at samsung.com  Mon Apr  8 14:19:24 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Tue, 09 Apr 2013 03:19:24 +0900
Subject: [GIT PULL 07/10] pmu-exynos for v3.10
Message-ID: <51630A2C.7060409@samsung.com>

The following changes since commit da821eb7d42935b0f7056d98c75fd1150f6636f4:

   Merge commit 'v3.9-rc5' into next/clk-exynos (2013-04-09 01:10:13 +0900)

are available in the git repository at:


   git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git 
tags/pmu-exynos-for-v3.10

for you to fetch changes up to db35234ec7a7a10145cf472f68e1c73fbd48f79c:

   ARM: EXYNOS: Add arm-pmu DT binding for exynos421x (2013-04-09 
01:49:16 +0900)

----------------------------------------------------------------
add support arm-pmu for exynos4 and exynos5250

----------------------------------------------------------------
Chanho Park (5):
       irqchip: exynos-combiner: Add set_irq_affinity function for 
combiner_irq
       irqchip: exynos-combiner: Correct combined IRQs for exynos4
       ARM: EXYNOS: Enable PMUs for exynos4
       ARM: EXYNOS: Add arm-pmu DT binding for exynos5250
       ARM: EXYNOS: Add arm-pmu DT binding for exynos421x

  arch/arm/boot/dts/exynos4210.dtsi        |  6 +++
  arch/arm/boot/dts/exynos5250.dtsi        |  6 +++
  arch/arm/mach-exynos/common.c            | 28 +++++++++++
  arch/arm/mach-exynos/include/mach/irqs.h | 13 ++++--
  arch/arm/plat-samsung/devs.c             |  2 +-
  drivers/irqchip/exynos-combiner.c        | 80 
+++++++++++++++++++++++++-------
  6 files changed, 113 insertions(+), 22 deletions(-)

-- 
Thanks.

Best regards,
Kgene.
--
Kukjin Kim <kgene.kim at samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.


From kgene.kim at samsung.com  Mon Apr  8 14:19:34 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Tue, 09 Apr 2013 03:19:34 +0900
Subject: [GIT PULL 08/10] secure-exynos for v3.10
Message-ID: <51630A36.6030505@samsung.com>

The following changes since commit da821eb7d42935b0f7056d98c75fd1150f6636f4:

   Merge commit 'v3.9-rc5' into next/clk-exynos (2013-04-09 01:10:13 +0900)

are available in the git repository at:


   git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git 
tags/secure-exynos-for-v3.10

for you to fetch changes up to beddf63fc8e01f06799bd6d7a2dd879885bbc9c6:

   ARM: EXYNOS: Add secure firmware support to secondary CPU bring-up 
(2013-04-09 01:52:30 +0900)

----------------------------------------------------------------
add support secure firmware for exynos

----------------------------------------------------------------
Tomasz Figa (5):
       ARM: Add interface for registering and calling firmware-specific 
operations
       ARM: EXYNOS: Add support for secure monitor calls
       ARM: EXYNOS: Add support for Exynos secure firmware
       ARM: EXYNOS: Add IO mapping for non-secure SYSRAM.
       ARM: EXYNOS: Add secure firmware support to secondary CPU bring-up

  Documentation/arm/firmware.txt                     | 88 
++++++++++++++++++++++
  .../devicetree/bindings/arm/samsung-boards.txt     | 10 +++
  arch/arm/common/Makefile                           |  2 +
  arch/arm/common/firmware.c                         | 18 +++++
  arch/arm/include/asm/firmware.h                    | 66 ++++++++++++++++
  arch/arm/mach-exynos/Makefile                      |  6 ++
  arch/arm/mach-exynos/common.c                      | 35 +++++++++
  arch/arm/mach-exynos/common.h                      |  2 +
  arch/arm/mach-exynos/exynos-smc.S                  | 22 ++++++
  arch/arm/mach-exynos/firmware.c                    | 70 +++++++++++++++++
  arch/arm/mach-exynos/include/mach/map.h            |  3 +
  arch/arm/mach-exynos/mach-exynos4-dt.c             |  1 +
  arch/arm/mach-exynos/platsmp.c                     | 32 ++++++--
  arch/arm/mach-exynos/smc.h                         | 31 ++++++++
  arch/arm/plat-samsung/include/plat/map-s5p.h       |  1 +
  15 files changed, 382 insertions(+), 5 deletions(-)
  create mode 100644 Documentation/arm/firmware.txt
  create mode 100644 arch/arm/common/firmware.c
  create mode 100644 arch/arm/include/asm/firmware.h
  create mode 100644 arch/arm/mach-exynos/exynos-smc.S
  create mode 100644 arch/arm/mach-exynos/firmware.c
  create mode 100644 arch/arm/mach-exynos/smc.h

-- 
Thanks.

Best regards,
Kgene.
--
Kukjin Kim <kgene.kim at samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.


From kgene.kim at samsung.com  Mon Apr  8 14:19:52 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Tue, 09 Apr 2013 03:19:52 +0900
Subject: [GIT PULL 09/10] 2nd timer-samsung for v3.10
Message-ID: <51630A48.1060401@samsung.com>

The following changes since commit ad38bdd15d5b97dcb1ffc46ea77c237e30312fbb:

   ARM: SAMSUNG: Remove unused plat-samsung/time.c (2013-03-05 20:19:54 
+0900)

are available in the git repository at:

   git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git 
tags/timer-samsung-for-v3.10

for you to fetch changes up to 536504309c3c2da5a755263c7179ffe1b2e5b3dd:

   ARM: SAMSUNG: change GENERIC_GPIO to ARCH_REQUIRE_GPIOLIB (2013-04-04 
09:36:24 +0900)

----------------------------------------------------------------
including fix for GENERIC_GPIO based on previous pull-request for 
timer-samsung

----------------------------------------------------------------
Kukjin Kim (1):
       ARM: SAMSUNG: change GENERIC_GPIO to ARCH_REQUIRE_GPIOLIB

  arch/arm/Kconfig | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

-- 
Thanks.

Best regards,
Kgene.
--
Kukjin Kim <kgene.kim at samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.


From kgene.kim at samsung.com  Mon Apr  8 14:20:05 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Tue, 09 Apr 2013 03:20:05 +0900
Subject: [GIT PULL 10/10] devel-samsung for v3.10
Message-ID: <51630A55.6030703@samsung.com>

The following changes since commit 6dbe51c251a327e012439c4772097a13df43c5b8:

   Linux 3.9-rc1 (2013-03-03 15:11:05 -0800)

are available in the git repository at:

   git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git 
tags/devel-samsung-for-v3.10

for you to fetch changes up to 298591f89fd0f3f779a77e589ce2f1c28e9788ed:

   ARM: EXYNOS: replace cpumask by the corresponding macro (2013-04-09 
00:44:35 +0900)

----------------------------------------------------------------
including various development for samsung for v3.10

----------------------------------------------------------------
Charles Keepax (2):
       ARM: S3C64XX: Clear DMA flags on channel request
       ARM: S3C64XX: Slow down mic detection rate for wm5102

Daniel Lezcano (3):
       ARM: EXYNOS: factor out the idle states
       ARM: EXYNOS: handle properly the return values
       ARM: EXYNOS: replace cpumask by the corresponding macro

Inderpal Singh (2):
       ARM: EXYNOS: Add support for rtc wakeup
       ARM: SAMSUNG: check processor type before cache restoration in resume

Jonathan Kliegman (2):
       ARM: EXYNOS: Remove hardcode wakeup unmask for EINT_0
       ARM: EXYNOS: Clear ENABLE_WAKEUP_SW bit when entering suspend

Sylwester Nawrocki (2):
       ARM: SAMSUNG: Export MIPI CSIS/DSIM PHY control functions
       ARM: S3C24XX: Correct NR_IRQS definition for s3c2440

  arch/arm/mach-exynos/common.c                |  2 +
  arch/arm/mach-exynos/cpuidle.c               | 58 
+++++++++++++---------------
  arch/arm/mach-exynos/include/mach/pm-core.h  |  9 +----
  arch/arm/mach-s3c24xx/include/mach/irqs.h    |  4 +-
  arch/arm/mach-s3c64xx/dma.c                  |  1 +
  arch/arm/mach-s3c64xx/mach-crag6410-module.c |  1 +
  arch/arm/plat-samsung/s5p-sleep.S            |  9 +++++
  arch/arm/plat-samsung/setup-mipiphy.c        |  3 ++
  8 files changed, 45 insertions(+), 42 deletions(-)

-- 
Thanks.

Best regards,
Kgene.
--
Kukjin Kim <kgene.kim at samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.


From kgene.kim at samsung.com  Mon Apr  8 14:21:21 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Tue, 09 Apr 2013 03:21:21 +0900
Subject: [PATCH] ARM: EXYNOS: remove "config EXYNOS_DEV_DRM"
In-Reply-To: <1365432910.1830.105.camel@x61.thuisdomein>
References: <1365432910.1830.105.camel@x61.thuisdomein>
Message-ID: <51630AA1.8060207@samsung.com>

On 04/08/13 23:55, Paul Bolle wrote:
> The only user of Kconfig symbol EXYNOS_DEV_DRM was removed in commit
> 0a9d5ac307aefbb2c772537d3fe7f75046d563ac ("ARM: EXYNOS: removing
> exynos-drm device registration from non-dt platforms"). It is safe to
> remove this symbol too.
>
> Signed-off-by: Paul Bolle<pebolle at tiscali.nl>
> ---
> Only "git grep" tested.
>
>   arch/arm/mach-exynos/Kconfig | 10 ----------
>   1 file changed, 10 deletions(-)
>
> diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
> index 70f94c8..99e7142 100644
> --- a/arch/arm/mach-exynos/Kconfig
> +++ b/arch/arm/mach-exynos/Kconfig
> @@ -95,11 +95,6 @@ config EXYNOS4_DEV_AHCI
>   	help
>   	  Compile in platform device definitions for AHCI
>
> -config EXYNOS_DEV_DRM
> -	bool
> -	help
> -	  Compile in platform device definitions for core DRM device
> -
>   config EXYNOS4_SETUP_FIMD0
>   	bool
>   	help
> @@ -199,7 +194,6 @@ config MACH_SMDKV310
>   	select EXYNOS4_SETUP_SDHCI
>   	select EXYNOS4_SETUP_USB_PHY
>   	select EXYNOS_DEV_DMA
> -	select EXYNOS_DEV_DRM
>   	select EXYNOS_DEV_SYSMMU
>   	select S3C24XX_PWM
>   	select S3C_DEV_HSMMC
> @@ -253,7 +247,6 @@ config MACH_UNIVERSAL_C210
>   	select EXYNOS4_SETUP_SDHCI
>   	select EXYNOS4_SETUP_USB_PHY
>   	select EXYNOS_DEV_DMA
> -	select EXYNOS_DEV_DRM
>   	select EXYNOS_DEV_SYSMMU
>   	select HAVE_SCHED_CLOCK
>   	select S3C_DEV_HSMMC
> @@ -294,7 +287,6 @@ config MACH_NURI
>   	select EXYNOS4_SETUP_SDHCI
>   	select EXYNOS4_SETUP_USB_PHY
>   	select EXYNOS_DEV_DMA
> -	select EXYNOS_DEV_DRM
>   	select S3C_DEV_HSMMC
>   	select S3C_DEV_HSMMC2
>   	select S3C_DEV_HSMMC3
> @@ -330,7 +322,6 @@ config MACH_ORIGEN
>   	select EXYNOS4_SETUP_SDHCI
>   	select EXYNOS4_SETUP_USB_PHY
>   	select EXYNOS_DEV_DMA
> -	select EXYNOS_DEV_DRM
>   	select EXYNOS_DEV_SYSMMU
>   	select S3C24XX_PWM
>   	select S3C_DEV_HSMMC
> @@ -366,7 +357,6 @@ config MACH_SMDK4212
>   	select EXYNOS4_SETUP_SDHCI
>   	select EXYNOS4_SETUP_USB_PHY
>   	select EXYNOS_DEV_DMA
> -	select EXYNOS_DEV_DRM
>   	select EXYNOS_DEV_SYSMMU
>   	select S3C24XX_PWM
>   	select S3C_DEV_HSMMC2

Applied, thanks.

- Kukjin


From swarren at wwwdotorg.org  Mon Apr  8 14:21:47 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Mon, 08 Apr 2013 12:21:47 -0600
Subject: [PATCH 1/3] ARM: tegra: pcie: Add tegra3 support
In-Reply-To: <1365435688-4179-1-git-send-email-jagarwal@nvidia.com>
References: <1365435688-4179-1-git-send-email-jagarwal@nvidia.com>
Message-ID: <51630ABB.1020200@wwwdotorg.org>

On 04/08/2013 09:41 AM, Jay Agarwal wrote:
> Signed-off-by: Jay Agarwal <jagarwal at nvidia.com>
> 
> - Enable pcie root port 2 for cardhu
> - Make private data structure for each SOC
> - Add required tegra3 clocks and regulators
> - Add tegra3 specific code in enable controller
> - Modify clock tree to get clocks based on device
> - Based on git://gitorious.org/thierryreding/linux.git

A couple more points on this patch:

* You didn't mention that this series is based on Thierry's
work-in-progress tree, and not something immediately destined for
upstream. As such, only Thierry is expected to actually apply any of
these patches.

* Your changes to the Tegra PCIe driver require that device tree include
extra clocks and regulators. You need to update
Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt to
describe these new requirements.


From kgene.kim at samsung.com  Mon Apr  8 14:23:34 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Tue, 09 Apr 2013 03:23:34 +0900
Subject: [PATCH] ARM: dts: fix bad merge of display timing node to
 exynos5250-smdk5250.dts
In-Reply-To: <1365439879-3398-1-git-send-email-dianders@chromium.org>
References: <1365439879-3398-1-git-send-email-dianders@chromium.org>
Message-ID: <51630B26.1000102@samsung.com>

On 04/09/13 01:51, Doug Anderson wrote:
> The display timing node was added:
>    7ed2077 ARM: dts: Add display timing node to exynos5250-smdk5250.dts
> ...and looks OK there.  ...but it looks like we lost a "};" in the
> merge and it no longer compiles.  Fix it.
>
> Signed-off-by: Doug Anderson<dianders at chromium.org>
> ---
>   arch/arm/boot/dts/exynos5250-smdk5250.dts | 1 +
>   1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts b/arch/arm/boot/dts/exynos5250-smdk5250.dts
> index 4be14df..26d856b 100644
> --- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
> +++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
> @@ -239,6 +239,7 @@
>   			vback-porch =<4>;
>   			vfront-porch =<4>;
>   			vsync-len =<4>;
> +		};
>   	};
>
>   	fixed-rate-clocks {

Thanks for your pointing out. But it should be fixed with re-sorting out 
the branch.

If any problems, please let me know.

- Kukjin


From sebastian.hesselbarth at gmail.com  Mon Apr  8 14:24:08 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Mon, 08 Apr 2013 20:24:08 +0200
Subject: [PATCH v6] clk: add si5351 i2c common clock driver
In-Reply-To: <20130408174636.GA1885@roeck-us.net>
References: <1365139415-17815-1-git-send-email-sebastian.hesselbarth@gmail.com>
 <1365439617-18816-1-git-send-email-sebastian.hesselbarth@gmail.com>
 <20130408174636.GA1885@roeck-us.net>
Message-ID: <51630B48.9050005@gmail.com>

On 04/08/2013 07:46 PM, Guenter Roeck wrote:
> On Mon, Apr 08, 2013 at 06:46:57PM +0200, Sebastian Hesselbarth wrote:
>> This patch adds a common clock driver for Silicon Labs Si5351a/b/c
>> i2c programmable clock generators. Currently, the driver does not
>> support VXCO feature of si5351b. Passing platform_data or DT bindings
>> selectively allow to overwrite stored Si5351 configuration which is
>> very helpful for clock generators with empty eeprom configuration.
>> Corresponding device tree binding documentation is also added.
>>
>> Signed-off-by: Sebastian Hesselbarth<sebastian.hesselbarth at gmail.com>
>
> [ ... ]
>
>> +
>> +/*
>> + * Si5351 i2c probe and DT
>> + */
>> +#ifdef CONFIG_OF
>> +static const struct of_device_id si5351_dt_ids[] = {
>> +	{ .compatible = "silabs,si5351a", .data = (void *)SI5351_VARIANT_A, },
>> +	{ .compatible = "silabs,si5351a-msop",
>> +					 .data = (void *)SI5351_VARIANT_A3, },
>> +	{ .compatible = "silabs,si5351b", .data = (void *)SI5351_VARIANT_B, },
>> +	{ .compatible = "silabs,si5351c", .data = (void *)SI5351_VARIANT_C, },
>> +	{ }
>> +};
>> +MODULE_DEVICE_TABLE(of, si5351_dt_ids);
>> +
>> +static int si5351_dt_parse(struct i2c_client *client)
>> +{
>> +	struct device_node *child, *np = client->dev.of_node;
>> +	struct si5351_platform_data *pdata;
>> +	const struct of_device_id *match;
>> +	struct property *prop;
>> +	const __be32 *p;
>> +	int num = 0;
>> +	u32 val;
>> +
>> +	if (np == NULL)
>> +		return 0;
>> +
>> +	match = of_match_node(si5351_dt_ids, np);
>> +	if (match == NULL)
>> +		return -EINVAL;
>> +
>> +	pdata = devm_kzalloc(&client->dev, sizeof(*pdata), GFP_KERNEL);
>> +	if (!pdata)
>> +		return -ENOMEM;
>> +
>> +	pdata->variant = (enum si5351_variant)match->data;
>> +	pdata->clk_xtal = of_clk_get(np, 0);
>> +	if (!IS_ERR(pdata->clk_xtal))
>> +		clk_put(pdata->clk_xtal);
>> +	pdata->clk_clkin = of_clk_get(np, 1);
>> +	if (!IS_ERR(pdata->clk_clkin))
>> +		clk_put(pdata->clk_clkin);
>> +
>> +	/*
>> +	 * property silabs,pll-source :<num src>, [<..>]
>> +	 * allow to selectively set pll source
>> +	 */
>> +	of_property_for_each_u32(np, "silabs,pll-source", prop, p, num) {
>> +		if (num>= 2) {
>> +			dev_err(&client->dev,
>> +				"invalid pll %d on pll-source prop\n", num);
>> +			break;
>
> You report dev_err here, but you don't return an error to the caller.
> Is this on purpose ? If it is not a fatal error, maybe it should be dev_info ?

This shouldn't break but continue with one u32 skipped. Actually, it is
a warning because somebody passed an invalid value and should be 
dev_warn(). But see my note below, I will make them all fatal.

>> +		}
>> +
>> +		p = of_prop_next_u32(prop, p,&val);
>> +		if (!p)
>> +			break;
>> +
>> +		switch (val) {
>> +		case 0:
>> +			pdata->pll_src[num] = SI5351_PLL_SRC_XTAL;
>> +			break;
>> +		case 1:
>> +			pdata->pll_src[num] = SI5351_PLL_SRC_CLKIN;
>> +			break;
>> +		default:
>> +			dev_warn(&client->dev,
>> +				 "invalid parent %d for pll %d\n", val, num);
>> +			continue;
>
> Same here, and a couple of times below. Given the context, I think it would
> be better if the error cases would return an error. After all, the condition
> suggests that the device tree data is wrong, meaning one has to assume it
> won't work anyway and should be fixed in the device tree and not be ignored
> by the driver.

I am skipping invalid DT data enties here, but I can make them all
fatal. I will also add more variant checks in the corresponding
_si5351_* functions.

>> +		}
>> +	}
>> +
>> +	/* per clkout properties */
>> +	num = of_get_child_count(np);
>> +
>> +	if (num == 0)
>> +		return 0;
>> +
>
> This doesn't set client->dev.platform_data yet returns no error, meaning the
> calling code will either use provided platform data or fail after all if it is
> NULL. That seems to be inconsistent, given that a dt entry was already detected.
> The user might end up wondering why the provided device tree data is not used,
> not realizing that it is incomplete.
>
> If children are not mandatory, you could just drop the code above and go through
> for_each_child_of_node() anyway; it won't do anything and set
> client->dev.platform_data at the end. If children are mandatory, it might make
> sense to return an eror here (if there is dt information, it should be complete
> and consistent).

Not having children is valid as you only provide them if you want to
overwrite the current config stored in the eeprom. But yes, skipping
for_each_child_of_node below is a left-over from an implementation where
I used dynamically allocated ->pll/->clkout.

>> +	for_each_child_of_node(np, child) {
>> +		if (of_property_read_u32(child, "reg",&num)) {
>> +			dev_err(&client->dev, "missing reg property of %s\n",
>> +				child->name);
>> +			continue;
>> +		}
>> +
> What if "num" returns 100 ? Or 1000 ?

Segmentation fault? ;) I will add a check for 0 <= num < 8.

Thanks for the review,
   Sebastian


From kgene.kim at gmail.com  Mon Apr  8 14:25:23 2013
From: kgene.kim at gmail.com (Kukjin Kim)
Date: Tue, 09 Apr 2013 03:25:23 +0900
Subject: [PATCH] ARM: dts: Disable the RTC by default on exynos5
In-Reply-To: <1365440295-4460-1-git-send-email-dianders@chromium.org>
References: <1365440295-4460-1-git-send-email-dianders@chromium.org>
Message-ID: <51630B93.3020702@gmail.com>

On 04/09/13 01:58, Doug Anderson wrote:
> This change makes the rtc on the exynos5250 and 5440 disabled by
> default to match exynos4.
>
> Ever since the common clock framework came in came in, exynos5250
> boards have dumped lots of warnings in the boot log.  It turns out
> that we don't see those on exynos4 since the rtc is disabled by
> default.  While we need to get to the bottom of the problems with the
> RTC, it still makes sense to have the default state of the RTC on
> exynos boards match.
>
> For the record, warnings look like this:
>    ------------[ cut here ]------------
>    WARNING: at /.../drivers/clk/clk.c:771 __clk_enable+0x34/0xb0()
>    Modules linked in:
>    [<80015bfc>] (unwind_backtrace+0x0/0xec) from [<804717f0>] (dump_stack+0x20/0x24)
>    [<804717f0>] (dump_stack+0x20/0x24) from [<80023cd0>] (warn_slowpath_common+0x5c/0x7c)
>    [<80023cd0>] (warn_slowpath_common+0x5c/0x7c) from [<80023d1c>] (warn_slowpath_null+0x2c/0x34)
>    [<80023d1c>] (warn_slowpath_null+0x2c/0x34) from [<8035ddb0>] (__clk_enable+0x34/0xb0)
>    [<8035ddb0>] (__clk_enable+0x34/0xb0) from [<8035de54>] (clk_enable+0x28/0x3c)
>    [<8035de54>] (clk_enable+0x28/0x3c) from [<8031a160>] (s3c_rtc_probe+0xf4/0x434)
>    [<8031a160>] (s3c_rtc_probe+0xf4/0x434) from [<8028e288>] (platform_drv_probe+0x24/0x28)
>    [<8028e288>] (platform_drv_probe+0x24/0x28) from [<8028ce10>] (driver_probe_device+0xbc/0x22c)
>    [<8028ce10>] (driver_probe_device+0xbc/0x22c) from [<8028cff8>] (__driver_attach+0x78/0x9c)
>    [<8028cff8>] (__driver_attach+0x78/0x9c) from [<8028bdfc>] (bus_for_each_dev+0x64/0xac)
>    [<8028bdfc>] (bus_for_each_dev+0x64/0xac) from [<8028c7e0>] (driver_attach+0x28/0x30)
>    [<8028c7e0>] (driver_attach+0x28/0x30) from [<8028c43c>] (bus_add_driver+0xe0/0x234)
>    [<8028c43c>] (bus_add_driver+0xe0/0x234) from [<8028d55c>] (driver_register+0xac/0x13c)
>    [<8028d55c>] (driver_register+0xac/0x13c) from [<8028e4f4>] (platform_driver_register+0x54/0x68)
>    [<8028e4f4>] (platform_driver_register+0x54/0x68) from [<8065c944>] (s3c_rtc_driver_init+0x14/0x1c)
>    [<8065c944>] (s3c_rtc_driver_init+0x14/0x1c) from [<800086d8>] (do_one_initcall+0x60/0x138)
>    [<800086d8>] (do_one_initcall+0x60/0x138) from [<80633a8c>] (kernel_init_freeable+0x108/0x1d0)
>    [<80633a8c>] (kernel_init_freeable+0x108/0x1d0) from [<8046d2f8>] (kernel_init+0x1c/0xf4)
>    [<8046d2f8>] (kernel_init+0x1c/0xf4) from [<8000e358>] (ret_from_fork+0x14/0x20)
>    ---[ end trace 4bcdc801c868d73f ]---
>
> Signed-off-by: Doug Anderson<dianders at chromium.org>
> ---
>   arch/arm/boot/dts/exynos5250.dtsi | 1 +
>   arch/arm/boot/dts/exynos5440.dtsi | 1 +
>   2 files changed, 2 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi
> index dc55e33..892b724 100644
> --- a/arch/arm/boot/dts/exynos5250.dtsi
> +++ b/arch/arm/boot/dts/exynos5250.dtsi
> @@ -183,6 +183,7 @@
>   		interrupts =<0 43 0>,<0 44 0>;
>   		clocks =<&clock 337>;
>   		clock-names = "rtc";
> +		status = "disabled";
>   	};
>
>   	tmu at 10060000 {
> diff --git a/arch/arm/boot/dts/exynos5440.dtsi b/arch/arm/boot/dts/exynos5440.dtsi
> index 25c6134..a8ceef4 100644
> --- a/arch/arm/boot/dts/exynos5440.dtsi
> +++ b/arch/arm/boot/dts/exynos5440.dtsi
> @@ -181,5 +181,6 @@
>   		interrupts =<0 17 0>,<0 16 0>;
>   		clocks =<&clock 21>;
>   		clock-names = "rtc";
> +		status = "disabled";
>   	};
>   };

Ooops, OK.

Applied, thanks.

- Kukjin


From dianders at chromium.org  Mon Apr  8 14:25:28 2013
From: dianders at chromium.org (Doug Anderson)
Date: Mon, 8 Apr 2013 11:25:28 -0700
Subject: [PATCH] ARM: dts: fix bad merge of display timing node to
 exynos5250-smdk5250.dts
In-Reply-To: <51630B26.1000102@samsung.com>
References: <1365439879-3398-1-git-send-email-dianders@chromium.org>
 <51630B26.1000102@samsung.com>
Message-ID: <CAD=FV=Ui2C49Z=39qboo9CdETrea2z+_+Wc77pjfDWX26XtxJg@mail.gmail.com>

Kukjin,

On Mon, Apr 8, 2013 at 11:23 AM, Kukjin Kim <kgene.kim at samsung.com> wrote:
> Thanks for your pointing out. But it should be fixed with re-sorting out the
> branch.

No problem with however you want to solve it.  ;)  Seemed that the
patch was the easiest way to report the problem in any case...

-Doug


From swarren at wwwdotorg.org  Mon Apr  8 14:27:00 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Mon, 08 Apr 2013 12:27:00 -0600
Subject: [PATCH 2/3] ARM: dts: tegra: Correct PCIe entry
In-Reply-To: <1365435688-4179-2-git-send-email-jagarwal@nvidia.com>
References: <1365435688-4179-1-git-send-email-jagarwal@nvidia.com>
 <1365435688-4179-2-git-send-email-jagarwal@nvidia.com>
Message-ID: <51630BF4.6000605@wwwdotorg.org>

On 04/08/2013 09:41 AM, Jay Agarwal wrote:
> Signed-off-by: Jay Agarwal <jagarwal at nvidia.com>

Your s-o-b line should be below the patch description, not above it.
Please see Documentation/SubmittingPatches.

I also don't see a --- line between the patch description and diffstat.
How are you generating these patch emails? Please see our internal wiki,
or other git documentation.

> diff --git a/arch/arm/boot/dts/tegra30.dtsi b/arch/arm/boot/dts/tegra30.dtsi

> -		clock-names = "pex", "afi", "pcie_xclk", "pll_e", "cml";
> +		clock-names = "pex", "afi", "pcie_xclk", "pll_e", "cml0";

Can you please explain more about this change?

I see the Tegra clock driver provides both a "cml0" and a "cml1" clock.
Are both of those used for PCIe?

If so, then why doesn't the driver and this DT change include both cml0
and cml1?

If not, then please note that the clock-names property doesn't have to
match the name of the clock at the clock provider. This property names
the clock inputs to the HW module. Hence, if the PCIe module only uses a
single CML clock, it can quite legitimately name its clock input just
"cml" rather than "cml0". In this case, you wouldn't need to make this
change to the DT.


From kgene.kim at gmail.com  Mon Apr  8 14:29:16 2013
From: kgene.kim at gmail.com (Kukjin Kim)
Date: Tue, 09 Apr 2013 03:29:16 +0900
Subject: [PATCH] ARM: dts: fix bad merge of display timing node to
 exynos5250-smdk5250.dts
In-Reply-To: <CAD=FV=Ui2C49Z=39qboo9CdETrea2z+_+Wc77pjfDWX26XtxJg@mail.gmail.com>
References: <1365439879-3398-1-git-send-email-dianders@chromium.org>	<51630B26.1000102@samsung.com>
 <CAD=FV=Ui2C49Z=39qboo9CdETrea2z+_+Wc77pjfDWX26XtxJg@mail.gmail.com>
Message-ID: <51630C7C.9040003@gmail.com>

On 04/09/13 03:25, Doug Anderson wrote:
> Kukjin,
>
> On Mon, Apr 8, 2013 at 11:23 AM, Kukjin Kim<kgene.kim at samsung.com>  wrote:
>> Thanks for your pointing out. But it should be fixed with re-sorting out the
>> branch.
>
> No problem with however you want to solve it.  ;)  Seemed that the
> patch was the easiest way to report the problem in any case...
>
Makes sense :-)

BTW, if any problems on current for-next, please kindly let me know.

Thanks.

- Kukjin


From arnd at arndb.de  Mon Apr  8 14:29:31 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 8 Apr 2013 20:29:31 +0200
Subject: [GIT PULL 1/3] ARM: bcm2835: device tree updates
In-Reply-To: <1365125338-6668-1-git-send-email-swarren@wwwdotorg.org>
References: <1365125338-6668-1-git-send-email-swarren@wwwdotorg.org>
Message-ID: <201304082029.32051.arnd@arndb.de>

On Friday 05 April 2013, Stephen Warren wrote:
> This branch adds two devices to the BCM2835 SoC device tree: the SPI
> controller and the HW random number generator.
> 
> The SPI controller isn't actually instantiated in the Raspberry Pi
> device tree, since there are no on-board SPI devices; it's up to the
> end-user to modify their own device-tree to describe whatever they
> have attached.
> 

Pulled all three branches, thanks!

	Arnd


From jason at lakedaemon.net  Mon Apr  8 14:30:55 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Mon, 8 Apr 2013 14:30:55 -0400
Subject: [PATCH v4 0/5] Device Bus support for Marvell EBU SoC
In-Reply-To: <20130408152933.GB877@localhost>
References: <1365419194-20871-1-git-send-email-ezequiel.garcia@free-electrons.com>
 <201304081617.31644.arnd@arndb.de> <20130408152933.GB877@localhost>
Message-ID: <20130408183055.GA13280@titan.lakedaemon.net>

On Mon, Apr 08, 2013 at 12:29:34PM -0300, Ezequiel Garcia wrote:
> On Mon, Apr 08, 2013 at 04:17:31PM +0200, Arnd Bergmann wrote:
> > On Monday 08 April 2013, Ezequiel Garcia wrote:
> > >   * Rename devbus,dev-width to devbus,bus-width and changed the
> > >     parameter value from bytes to bits: <8>, <16>, ...
> > >     Suggested by Arnd Bergmann.
> > > 
> > >   * As suggested by Jason Gunthorpe and agreed by Arnd Bergmann.
> > >     Reworked the whole devbus child chip-select device tree design.
> > >     Now there's a separate devbus at addr DT node for each controller
> > >     chip select. The impact of this is:
> > >       1. Timing parameters now go into the parent node.
> > >       2. There can only be one child per devbus node.
> > > 
> > >   * Remove unneeded bank-width parameter read.
> > > 
> > 
> > Whole series:
> > 
> > Acked-by: Arnd Bergmann <arnd at arndb.de>
> > 
> > It may be nicer to use #address-cells=<2> for devbus device nodes now that
> > each of them has only a 32 bit address space, but the current code is correct
> > as well using a 64 bit notation.
> > 
> 
> I'll probably be sending a v5 fixing this later.
> 
> @Jason Cooper:
> How would you like to handle this, regarding the LPAE series?
> Do you want me to rebase this devbus on top of that?

Let's avoid the dependency and merge them both as is.  Once v3.10 drops,
you can send a fixup patch to move it to 64bit.

thx,

Jason.


From swarren at wwwdotorg.org  Mon Apr  8 14:32:29 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Mon, 08 Apr 2013 12:32:29 -0600
Subject: [PATCH 3/3] ARM: dts: tegra: Add PCIe entry for cardhu
In-Reply-To: <1365435688-4179-3-git-send-email-jagarwal@nvidia.com>
References: <1365435688-4179-1-git-send-email-jagarwal@nvidia.com>
 <1365435688-4179-3-git-send-email-jagarwal@nvidia.com>
Message-ID: <51630D3D.2040709@wwwdotorg.org>

On 04/08/2013 09:41 AM, Jay Agarwal wrote:
> Signed-off-by: Jay Agarwal <jagarwal at nvidia.com>
> 
> - Add PCIe node entry for cardhu
> - Enable only root port 2
> - Initialize regulators required for tegra30

Initialize isn't correct; this change makes no changes to any regulator;
it simply includes the required regulator properties in the new node.

I think you'd want to re-write this patch description as:

Enable the PCIe controller on Cardhu. Only port 2 is connected on this
board. It is connected to the Ethernet controller in the dock.

> diff --git a/arch/arm/boot/dts/tegra30-cardhu.dtsi b/arch/arm/boot/dts/tegra30-cardhu.dtsi

> +	pcie-controller {
...
>  	serial at 70006000 {

It lookos like this node is added in the wrong place. Nodes should be
sorted based on reg property, and judging by the reg property for this
node in tegra30.dtsi in Thierry's branch, this should be the first node
in the Cardhu file.


From sebastian.hesselbarth at gmail.com  Mon Apr  8 14:32:30 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Mon, 08 Apr 2013 20:32:30 +0200
Subject: [v5] clk: add si5351 i2c common clock driver
In-Reply-To: <20130408173628.14359.70620@quantum>
References: <1365139415-17815-1-git-send-email-sebastian.hesselbarth@gmail.com>
 <20130407225046.GA16326@roeck-us.net> <51620604.4070204@gmail.com>
 <20130408001725.GA16648@roeck-us.net> <51625F9A.1050308@gmail.com>
 <20130408145407.GA12243@roeck-us.net>
 <CABJ1b_T30trVjXps-rSbYTNo1DcPeT8WsZ+M18B9wTJPBnL-gA@mail.gmail.com>
 <20130408173628.14359.70620@quantum>
Message-ID: <51630D3E.30706@gmail.com>

On 04/08/2013 07:36 PM, Mike Turquette wrote:
> Quoting Sebastian Hesselbarth (2013-04-08 08:38:44)
>> On Mon, Apr 8, 2013 at 4:54 PM, Guenter Roeck<linux at roeck-us.net>  wrote:
>>> On Mon, Apr 08, 2013 at 08:11:38AM +0200, Sebastian Hesselbarth wrote:
>>>> On 04/08/2013 02:17 AM, Guenter Roeck wrote:
>>>>> On Mon, Apr 08, 2013 at 01:49:24AM +0200, Sebastian Hesselbarth wrote:
>>>>>> On 04/08/2013 12:50 AM, Guenter Roeck wrote:
>>>>>>> On Fri, Apr 05, 2013 at 05:23:35AM -0000, Sebastian Hesselbarth wrote:
>>>>>>>> This patch adds a common clock driver for Silicon Labs Si5351a/b/c
>>>>>>>> i2c programmable clock generators. Currently, the driver supports
>>>>>>>> DT kernels only and VXCO feature of si5351b is not implemented. DT
>>>>>>>> bindings selectively allow to overwrite stored Si5351 configuration
>>>>>>>> which is very helpful for clock generators with empty eeprom
>>>>>>>> configuration. Corresponding device tree binding documentation is
>>>>>>>> also added.
>>>>>>>>
>>>>>>>> Signed-off-by: Sebastian Hesselbarth<sebastian.hesselbarth at gmail.com>
>>>>>>>> Tested-by: Daniel Mack<zonque at gmail.com>
>>>>>>>>
>>>>>>> [ ... ]
>>>>>>>
>>>>>>>> +static inline void _si5351_msynth_set_pll_master(
>>>>>>>> + struct si5351_driver_data *drvdata, unsigned char num, int is_master)
>>>>>>>> +{
>>>>>>>> + unsigned long flags;
>>>>>>>> +
>>>>>>>> + if (num>    8 ||
>>>>>>>> +     (drvdata->variant == SI5351_VARIANT_A3&&    num>    3))
>>>>>>>> +         return;
>>>>>>>> +
>>>>>>>> + flags = __clk_get_flags(drvdata->msynth[num].hw.clk);
>>>>>>>> + if (is_master)
>>>>>>>> +         flags |= CLK_SET_RATE_PARENT;
>>>>>>>> + else
>>>>>>>> +         flags&= ~CLK_SET_RATE_PARENT;
>>>>>>>> + __clk_set_flags(drvdata->msynth[num].hw.clk, flags);
>>>>>>>> +}
>>>>>>>> +
>>>>>>> Unless I am missing something, neither __clk_get_flags() nor the new
>>>>>>> __clk_set_flags is exported.
>>>>>>>
>>>>>>> Did you try to build and load the driver as module ?
>>>>>>
>>>>>> Well, good catch. I didn't try to build v5 as a module, but I guess it
>>>>>> will fail. But I consider this as something that has to be addressed in
>>>>>> clk framework itself, not in this patch. There will be other
>>>>>> clk-providers built as module in the future for sure.
>>>>>>
>>>>> Sure, but you provided the patch to make __clk_set_flags global. To avoid
>>>>> build failures, I would suggest to either submit a patch to export the
>>>>> missing functions, or to remove the ability to build the driver as module.
>>>>
>>>> Actually, I knew that __clk_set_flags patch will not be accepted
>>>> before posting it ;)
>>>>
>>> Ah, but part of that is to get you to think about it again, and to defend it if
>>> it is really needed. After all, "it can be abused" applies to pretty much every
>>> API.
>>
>> Guenter,
>>
>> I already thought about it a lot and I consider clk api broken in a way here.
>>
>>> Key question is if you _really_ need run-time flag modifications, or if you can
>>> live with initialization-time settings. If you really need it, you'll have to
>>> explain the reasons.
>>
>> The question is not if _I_ really need run-time flags but why the api allows to
>> perform run-time modifications of the clock hierarchy without allowing different
>> flags? There is clk_set_parent() so I guess clk api knows about run-time changes
>> already, but you cannot have different flags per parent. And with
>> __clk_set_flags()
>> rejected, you are not allowed to change the flags.
>>
>> I understand that some flags are permanent and required at registration, but
>> CLK_SET_PARENT_RATE is not. It is not limited by hardware but limited by api.
>> One way would be a more generic clk-mux with per parent flags, but for
>> the current
>> implementation, I cannot see how clk-mux can be exploited here.
>>
>
> There are a couple of ways to get past this issue.  One is removal of
> some of the flags.  I have never liked CLK_SET_RATE_PARENT, since I
> think the ability to propagate a rate-change request up to the parent
> should be enabled for all clocks.  This is in the interest of the driver
> author who does not care to know intimate details of the clock
> hierarchy.
>
> When I developed the rate-change propagation code I was likely too hasty
> in defining a per-clock flag for that behavior.  It might have been
> enough to simply compare the&best_parent_rate value from .round_rate
> and compare it against clk->parent->rate.  This means that no flag is
> necessary.
>
> This assumes that the .round_rate implementation has enough knowledge to
> know whether or not to propagate the rate-change request up to the
> parent.  This may not not true for the common divider type.
>
> I'll make some tests on removing this flag (and potentially other flags)
> to see how painful it is.

Mike,

another good thing would be to have implementation independent building 
blocks for clk drivers. I think clk-fixed-rate, clk-gate, clk-mux and
some clk-synth should be enough. The current core clk templates in the
api are almost all special implementations.

Sebastian


From arnd at arndb.de  Mon Apr  8 14:33:03 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 8 Apr 2013 20:33:03 +0200
Subject: [GIT PULL] Renesas ARM based SoC bockw defconfig updates for v3.10
In-Reply-To: <1365130583-11257-1-git-send-email-horms+renesas@verge.net.au>
References: <1365130583-11257-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <201304082033.04091.arnd@arndb.de>

On Friday 05 April 2013, Simon Horman wrote:
> An update to the defconfig for the bockw board to enable SMSC ethernet.
> 
> This is based on:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas renesas-boards3-for-v3.10
> 
> The reason for using that base is that the bockw defconfig was added
> in the boards branch instead of the defconfig branch, which was not ideal.

Pulled into the same next/boards2 branch that had the original addition.

	Arnd


From yinghai at kernel.org  Mon Apr  8 14:40:11 2013
From: yinghai at kernel.org (Yinghai Lu)
Date: Mon, 8 Apr 2013 11:40:11 -0700
Subject: [PATCH 0/2] mm: vmemmap: add vmemmap_verify check for hot-add
 node/memory case
In-Reply-To: <1365415000-10389-1-git-send-email-linfeng@cn.fujitsu.com>
References: <1365415000-10389-1-git-send-email-linfeng@cn.fujitsu.com>
Message-ID: <CAE9FiQVaByGOTjLVthRkEze_ekXm5LAKgKdHzrD+q1iYmjgZFQ@mail.gmail.com>

On Mon, Apr 8, 2013 at 2:56 AM, Lin Feng <linfeng at cn.fujitsu.com> wrote:
> In hot add node(memory) case, vmemmap pages are always allocated from other
> node,

that is broken, and should be fixed.
vmemmap should be on local node even for hot add node.

Thanks

Yinghai


From jason at lakedaemon.net  Mon Apr  8 15:10:47 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Mon, 8 Apr 2013 15:10:47 -0400
Subject: [PATCH v4 0/5] Device Bus support for Marvell EBU SoC
In-Reply-To: <20130408183055.GA13280@titan.lakedaemon.net>
References: <1365419194-20871-1-git-send-email-ezequiel.garcia@free-electrons.com>
 <201304081617.31644.arnd@arndb.de> <20130408152933.GB877@localhost>
 <20130408183055.GA13280@titan.lakedaemon.net>
Message-ID: <20130408191047.GC13280@titan.lakedaemon.net>

On Mon, Apr 08, 2013 at 02:30:55PM -0400, Jason Cooper wrote:
> On Mon, Apr 08, 2013 at 12:29:34PM -0300, Ezequiel Garcia wrote:
> > On Mon, Apr 08, 2013 at 04:17:31PM +0200, Arnd Bergmann wrote:
> > > On Monday 08 April 2013, Ezequiel Garcia wrote:
> > > >   * Rename devbus,dev-width to devbus,bus-width and changed the
> > > >     parameter value from bytes to bits: <8>, <16>, ...
> > > >     Suggested by Arnd Bergmann.
> > > > 
> > > >   * As suggested by Jason Gunthorpe and agreed by Arnd Bergmann.
> > > >     Reworked the whole devbus child chip-select device tree design.
> > > >     Now there's a separate devbus at addr DT node for each controller
> > > >     chip select. The impact of this is:
> > > >       1. Timing parameters now go into the parent node.
> > > >       2. There can only be one child per devbus node.
> > > > 
> > > >   * Remove unneeded bank-width parameter read.
> > > > 
> > > 
> > > Whole series:
> > > 
> > > Acked-by: Arnd Bergmann <arnd at arndb.de>
> > > 
> > > It may be nicer to use #address-cells=<2> for devbus device nodes now that
> > > each of them has only a 32 bit address space, but the current code is correct
> > > as well using a 64 bit notation.
> > > 
> > 
> > I'll probably be sending a v5 fixing this later.
> > 
> > @Jason Cooper:
> > How would you like to handle this, regarding the LPAE series?
> > Do you want me to rebase this devbus on top of that?
> 
> Let's avoid the dependency and merge them both as is.  Once v3.10 drops,
> you can send a fixup patch to move it to 64bit.

After talking with gregory, I'll merge everything as-is, then have him
rebase the LPAE changes on top of mvebu/dt.

thx,

Jason.


From fabian at ritter-vogt.de  Mon Apr  8 15:16:27 2013
From: fabian at ritter-vogt.de (Fabian Vogt)
Date: Mon, 08 Apr 2013 21:16:27 +0200
Subject: [RFC PATCH arm: initial TI-Nspire support]
In-Reply-To: <896CB251-17FC-4327-BA4E-A8FD9ED1BEC7@gmail.com>
References: <6FE4B33E-A503-4A75-AEED-831CB2C06D83@gmail.com>
 <4B3FD561-84FC-40CD-B747-13851692D673@gmail.com>
 <521DFDFC-7E9E-47EA-ACDA-C91BBDC8454E@gmail.com>
 <201304072323.42173.arnd@arndb.de>
 <896CB251-17FC-4327-BA4E-A8FD9ED1BEC7@gmail.com>
Message-ID: <op.wu8k5pwqu7prd4@fabians-laptop.fritz.box>

The latest kernel it seems to get stuck at
console_lock() in register_framebuffer (drivers/video/fbmem.c:1655)
if the LCD-controller is enabled. (Early printk and serial console works  
fine)
CONFIG_NO_HZ is not activated, it works completely.
Could this be a kernel bug or is this an issue with our timer  
configuration?


From arnd at arndb.de  Mon Apr  8 15:15:33 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 8 Apr 2013 21:15:33 +0200
Subject: [PATCH v4 1/5] drivers: memory: Introduce Marvell EBU Device Bus
 driver
In-Reply-To: <20130408171940.GA8815@obsidianresearch.com>
References: <1365419194-20871-1-git-send-email-ezequiel.garcia@free-electrons.com>
 <1365419194-20871-2-git-send-email-ezequiel.garcia@free-electrons.com>
 <20130408171940.GA8815@obsidianresearch.com>
Message-ID: <201304082115.33882.arnd@arndb.de>

On Monday 08 April 2013, Jason Gunthorpe wrote:
> > +     /* Get the CS to choose the window string */
> > +     err = of_property_read_u32(node, "ranges", &cs);
> > +     if (err < 0)
> > +             return err;
> 
> .. and this is why you've kept the 2 cells address - the top cell is
> still encoding the target id. This would go away eventually too..
> 
> Maybe it would be better in the interm to compute the CS offset from
> the control register offset?
> 
> (reg.start % 0x400)/8 should do the trick?

Yes, we came to the axact same conclusion on IRC.

> > +     devbus->child = of_platform_device_create(child, NULL, &pdev->dev);
> > +     if (!devbus->child) {
> > +             dev_warn(dev, "cannot create child device %s\n", child->name);
> > +             /* Remove the allocated window */
> > +             mvebu_mbus_del_window(devbus->child_mem.start,
> > +                                   resource_size(&devbus->child_mem));
> > +     }
> 
> This can probably just be of_platform_populate or similar to do all
> children? For instance, I often use many DT nodes to represent a FPGA,
> since the my FPGA's tend to have many functionally orthogonal units
> inside.

Good idea, yes.

	Arnd


From rjw at sisk.pl  Mon Apr  8 15:27:40 2013
From: rjw at sisk.pl (Rafael J. Wysocki)
Date: Mon, 08 Apr 2013 21:27:40 +0200
Subject: [PATCH 7/9] intel: cpuidle: remove stop/start critical timings
In-Reply-To: <51630115.6040205@linaro.org>
References: <1364991322-20585-1-git-send-email-daniel.lezcano@linaro.org>
 <5161DC9C.3020703@linaro.org> <51630115.6040205@linaro.org>
Message-ID: <6514915.cyFSTtqpte@vostro.rjw.lan>

On Monday, April 08, 2013 07:40:37 PM Daniel Lezcano wrote:
> On 04/07/2013 10:52 PM, Daniel Lezcano wrote:
> > On 04/05/2013 12:31 AM, Rafael J. Wysocki wrote:
> >> On Wednesday, April 03, 2013 02:15:20 PM Daniel Lezcano wrote:
> >>> The start/stop_critical_timings are called from arch/x86/kernel/process.c
> >>> in the cpu_idle loop function.
> >>>
> >>> Remove the ones in the cpuidle driver.
> >>>
> >>> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
> >> For this one I need an ACK from Len.
> >>
> >> Len, any objections?
> >
> > Len ? ping ...
> 
> Rafael,
> 
> this patch is not dependent from any patch in the series, is it possible
> you apply the patchset except this patch ?
> 
> May be you can apply it later when Len acks it, or I can resend it, no ?
> 
> I have a lot of code consolidation patches awaiting for this patchset to
> be merged.

OK, I'll take the rest of your patches in this series (except for [1/9]
which also is not depended on by anything AFAICS).

Thanks,
Rafael


> > ---
> >  drivers/idle/intel_idle.c |    3 ---
> >  1 file changed, 3 deletions(-)
> >
> > diff --git a/drivers/idle/intel_idle.c b/drivers/idle/intel_idle.c
> > index 5d66750..c99c31e 100644
> > --- a/drivers/idle/intel_idle.c
> > +++ b/drivers/idle/intel_idle.c
> > @@ -339,7 +339,6 @@ static int intel_idle(struct cpuidle_device *dev,
> >  	if (!(lapic_timer_reliable_states & (1 << (cstate))))
> >  		clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &cpu);
> >  
> > -	stop_critical_timings();
> >  	if (!need_resched()) {
> >  
> >  		__monitor((void *)&current_thread_info()->flags, 0, 0);
> > @@ -348,8 +347,6 @@ static int intel_idle(struct cpuidle_device *dev,
> >  			__mwait(eax, ecx);
> >  	}
> >  
> > -	start_critical_timings();
> > -
> >  	if (!(lapic_timer_reliable_states & (1 << (cstate))))
> >  		clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &cpu);
> >  
> >
> >
> 
> 
> 
-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.


From dianders at chromium.org  Mon Apr  8 15:21:32 2013
From: dianders at chromium.org (Doug Anderson)
Date: Mon, 8 Apr 2013 12:21:32 -0700
Subject: [PATCH] ARM: dts: fix bad merge of display timing node to
 exynos5250-smdk5250.dts
In-Reply-To: <51630C7C.9040003@gmail.com>
References: <1365439879-3398-1-git-send-email-dianders@chromium.org>
 <51630B26.1000102@samsung.com>
 <CAD=FV=Ui2C49Z=39qboo9CdETrea2z+_+Wc77pjfDWX26XtxJg@mail.gmail.com>
 <51630C7C.9040003@gmail.com>
Message-ID: <CAD=FV=UcKTBjKtyQFY4odTpBDKbNQEAHjyahqgNCsD570zq=pw@mail.gmail.com>

Kukjin,

On Mon, Apr 8, 2013 at 11:29 AM, Kukjin Kim <kgene.kim at gmail.com> wrote:
> BTW, if any problems on current for-next, please kindly let me know.

I usually try to check linux-next at least once a week, but sometimes
it's more or less often.  At the moment I'm trying to track something
weird down but it seems like it has some userspace component to it.
I'll post a separate thread if I find a kernel problem there.

Aside from the RTC, my biggest problem right now is that reboot
stopped working at the same time as the common clock.  The
exynos5_restart() function is essentially behaving as a no-op since
the clock to the IP block that handles reset has been gated.  :(  The
bit "CLK_PMU_APBIF" is gated in "CLK_GATE_IP_PERIS". This used to be
ungated in exynos5_clk_ip_peris_ctrl().

I'm happy to test a patch that fixes this but I haven't yet had time
to try to fix it cleanly myself.


-Doug


From tomasz.figa at gmail.com  Mon Apr  8 15:27:14 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Mon, 08 Apr 2013 21:27:14 +0200
Subject: [PATCH] ARM: dts: fix bad merge of display timing node to
 exynos5250-smdk5250.dts
In-Reply-To: <CAD=FV=UcKTBjKtyQFY4odTpBDKbNQEAHjyahqgNCsD570zq=pw@mail.gmail.com>
References: <1365439879-3398-1-git-send-email-dianders@chromium.org>
 <51630C7C.9040003@gmail.com>
 <CAD=FV=UcKTBjKtyQFY4odTpBDKbNQEAHjyahqgNCsD570zq=pw@mail.gmail.com>
Message-ID: <2824266.emLkgITIHc@flatron>

Hi Doug,

On Monday 08 of April 2013 12:21:32 Doug Anderson wrote:
> Kukjin,
> 
> On Mon, Apr 8, 2013 at 11:29 AM, Kukjin Kim <kgene.kim at gmail.com> wrote:
> > BTW, if any problems on current for-next, please kindly let me know.
> 
> I usually try to check linux-next at least once a week, but sometimes
> it's more or less often.  At the moment I'm trying to track something
> weird down but it seems like it has some userspace component to it.
> I'll post a separate thread if I find a kernel problem there.
> 
> Aside from the RTC, my biggest problem right now is that reboot
> stopped working at the same time as the common clock.  The
> exynos5_restart() function is essentially behaving as a no-op since
> the clock to the IP block that handles reset has been gated.  :(  The
> bit "CLK_PMU_APBIF" is gated in "CLK_GATE_IP_PERIS". This used to be
> ungated in exynos5_clk_ip_peris_ctrl().
> 
> I'm happy to test a patch that fixes this but I haven't yet had time
> to try to fix it cleanly myself.

Common Clock Framework by default automatically gates unused clocks, just 
like regulator core does with unused regulators. Maybe this is the cause?

There is a CLK_IGNORE_UNUSED flag which disables this behavior for all 
clocks which have it set. Maybe it should be set for the problematic 
clock?

Best regards,
Tomasz



From daniel.lezcano at linaro.org  Mon Apr  8 15:27:25 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Mon, 08 Apr 2013 21:27:25 +0200
Subject: [PATCH 7/9] intel: cpuidle: remove stop/start critical timings
In-Reply-To: <6514915.cyFSTtqpte@vostro.rjw.lan>
References: <1364991322-20585-1-git-send-email-daniel.lezcano@linaro.org>
 <5161DC9C.3020703@linaro.org> <51630115.6040205@linaro.org>
 <6514915.cyFSTtqpte@vostro.rjw.lan>
Message-ID: <51631A1D.3090705@linaro.org>

On 04/08/2013 09:27 PM, Rafael J. Wysocki wrote:
> On Monday, April 08, 2013 07:40:37 PM Daniel Lezcano wrote:
>> On 04/07/2013 10:52 PM, Daniel Lezcano wrote:
>>> On 04/05/2013 12:31 AM, Rafael J. Wysocki wrote:
>>>> On Wednesday, April 03, 2013 02:15:20 PM Daniel Lezcano wrote:
>>>>> The start/stop_critical_timings are called from arch/x86/kernel/process.c
>>>>> in the cpu_idle loop function.
>>>>>
>>>>> Remove the ones in the cpuidle driver.
>>>>>
>>>>> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
>>>> For this one I need an ACK from Len.
>>>>
>>>> Len, any objections?
>>>
>>> Len ? ping ...
>>
>> Rafael,
>>
>> this patch is not dependent from any patch in the series, is it possible
>> you apply the patchset except this patch ?
>>
>> May be you can apply it later when Len acks it, or I can resend it, no ?
>>
>> I have a lot of code consolidation patches awaiting for this patchset to
>> be merged.
> 
> OK, I'll take the rest of your patches in this series (except for [1/9]
> which also is not depended on by anything AFAICS).

Thanks Rafael.

  -- Daniel

-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From illia.ragozin at grapecom.com  Mon Apr  8 15:31:30 2013
From: illia.ragozin at grapecom.com (Elijah Ragozin)
Date: Mon, 08 Apr 2013 22:31:30 +0300
Subject: Fwd: [PATCH RESEND v2 1/1] ARM Feroceon: fix kexec by setting
 outer_cache.inv_all
In-Reply-To: <5150A8FF.7010301@grapecom.com>
References: <5150A8FF.7010301@grapecom.com>
Message-ID: <51631B12.2010908@grapecom.com>

On Feroceon the L2 cache becomes non-coherent with the CPU
when the L1 caches are disabled. Thus the L2 needs to be invalidated
after both L1 caches are disabled.

On kexec before the starting the code for relocation the kernel,
the L1 caches are disabled in cpu_froc_fin (cpu_v7_proc_fin for Feroceon),
but after L2 cache is never invalidated, because inv_all is not set
in cache-feroceon-l2.c.
So kernel relocation and decompression may has (and usually has) errors.
Setting the function enables L2 invalidation and fixes the issue.

Signed-off-by: Illia Ragozin <illia.ragozin at grapecom.com>
---
  arch/arm/mm/cache-feroceon-l2.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/arch/arm/mm/cache-feroceon-l2.c
b/arch/arm/mm/cache-feroceon-l2.c
index e0b0e7a..09f8851 100644
--- a/arch/arm/mm/cache-feroceon-l2.c
+++ b/arch/arm/mm/cache-feroceon-l2.c
@@ -342,6 +342,7 @@ void __init feroceon_l2_init(int __l2_wt_override)
  	outer_cache.inv_range = feroceon_l2_inv_range;
  	outer_cache.clean_range = feroceon_l2_clean_range;
  	outer_cache.flush_range = feroceon_l2_flush_range;
+	outer_cache.inv_all = l2_inv_all;
  
  	enable_l2();
  
-- 
1.8.1.4



From illia.ragozin at grapecom.com  Mon Apr  8 15:34:07 2013
From: illia.ragozin at grapecom.com (Elijah Ragozin)
Date: Mon, 08 Apr 2013 22:34:07 +0300
Subject: [PATCH RESEND v2 1/1] ARM Feroceon: fix kexec by setting
 outer_cache.inv_all
In-Reply-To: <51631B12.2010908@grapecom.com>
References: <51631B12.2010908@grapecom.com>
Message-ID: <51631BAF.40408@grapecom.com>

On Feroceon the L2 cache becomes non-coherent with the CPU
when the L1 caches are disabled. Thus the L2 needs to be invalidated
after both L1 caches are disabled.

On kexec before the starting the code for relocation the kernel,
the L1 caches are disabled in cpu_froc_fin (cpu_v7_proc_fin for Feroceon),
but after L2 cache is never invalidated, because inv_all is not set
in cache-feroceon-l2.c.
So kernel relocation and decompression may has (and usually has) errors.
Setting the function enables L2 invalidation and fixes the issue.

Signed-off-by: Illia Ragozin <illia.ragozin at grapecom.com>
---
  arch/arm/mm/cache-feroceon-l2.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/arch/arm/mm/cache-feroceon-l2.c
b/arch/arm/mm/cache-feroceon-l2.c
index e0b0e7a..09f8851 100644
--- a/arch/arm/mm/cache-feroceon-l2.c
+++ b/arch/arm/mm/cache-feroceon-l2.c
@@ -342,6 +342,7 @@ void __init feroceon_l2_init(int __l2_wt_override)
  	outer_cache.inv_range = feroceon_l2_inv_range;
  	outer_cache.clean_range = feroceon_l2_clean_range;
  	outer_cache.flush_range = feroceon_l2_flush_range;
+	outer_cache.inv_all = l2_inv_all;
  
  	enable_l2();
  
-- 
1.8.1.4



From arnd at arndb.de  Mon Apr  8 15:36:44 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 8 Apr 2013 21:36:44 +0200
Subject: GENERIC_GPIO considered deprecated
In-Reply-To: <5162EC32.2030602@wwwdotorg.org>
References: <CAAVeFu+QUw1WmzwaJDfjyw75PrStd3p3PHs1MU5BC7_WXMB7kw@mail.gmail.com>
 <2c9501ce342b$1535d290$3fa177b0$%kim@samsung.com>
 <5162EC32.2030602@wwwdotorg.org>
Message-ID: <201304082136.44905.arnd@arndb.de>

On Monday 08 April 2013, Stephen Warren wrote:
> >>
> >> Should do the trick, if we can make sure that your tree is merged
> >> prior to my patches.
> > 
> > I'm not sure but I think, arm-soc tree should be merged into mainline before others...
> > 
> >> Can you put it into your tree for 3.10?
> >>
> > I did, so it should be fine.
> > 
> 
> You may want to discuss how to handle this dependency with the arm-soc
> maintainers (CC'd).

I'm fine with putting the same branch into arm-soc as well as the gpio tree
and anything else that might need it, that tends to be the least invasive
way.

	Arnd


From arnd at arndb.de  Mon Apr  8 15:38:15 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 8 Apr 2013 21:38:15 +0200
Subject: [RFC PATCH arm: initial TI-Nspire support]
In-Reply-To: <op.wu8k5pwqu7prd4@fabians-laptop.fritz.box>
References: <6FE4B33E-A503-4A75-AEED-831CB2C06D83@gmail.com>
 <896CB251-17FC-4327-BA4E-A8FD9ED1BEC7@gmail.com>
 <op.wu8k5pwqu7prd4@fabians-laptop.fritz.box>
Message-ID: <201304082138.15875.arnd@arndb.de>

On Monday 08 April 2013, Fabian Vogt wrote:
> The latest kernel it seems to get stuck at
> console_lock() in register_framebuffer (drivers/video/fbmem.c:1655)
> if the LCD-controller is enabled. (Early printk and serial console works  
> fine)
> CONFIG_NO_HZ is not activated, it works completely.
> Could this be a kernel bug or is this an issue with our timer  
> configuration?

This usually happens when the console driver or anything it uses
calls a function that does a printk(), which means you get a recursive
call into the console code and try to get the same lock again.

	Arnd


From dianders at chromium.org  Mon Apr  8 15:41:28 2013
From: dianders at chromium.org (Doug Anderson)
Date: Mon, 8 Apr 2013 12:41:28 -0700
Subject: [PATCH] ARM: dts: fix bad merge of display timing node to
 exynos5250-smdk5250.dts
In-Reply-To: <2824266.emLkgITIHc@flatron>
References: <1365439879-3398-1-git-send-email-dianders@chromium.org>
 <51630C7C.9040003@gmail.com>
 <CAD=FV=UcKTBjKtyQFY4odTpBDKbNQEAHjyahqgNCsD570zq=pw@mail.gmail.com>
 <2824266.emLkgITIHc@flatron>
Message-ID: <CAD=FV=X7-DvuCpPeJwKDZeacbRzR+oB+upzzg=PK3_PmSnxbig@mail.gmail.com>

Tomasz,

On Mon, Apr 8, 2013 at 12:27 PM, Tomasz Figa <tomasz.figa at gmail.com> wrote:
> Common Clock Framework by default automatically gates unused clocks, just
> like regulator core does with unused regulators. Maybe this is the cause?

Yes, I'm nearly certain that's the case here.  The reset code doesn't
belong to any driver (it's in mach-exynos/common.c) it certainly
doesn't grab any clock.

I tried quickly to see if there was an easy clock to grab but got a
bit stuck.  In the old way of doing things clocks could be global and
grabbed without a dev node.  That may still be possible now, but in
the 15 minutes I spent I couldn't figure it out and so it went to the
back burner.  ...or we could make a real reset device, but that might
be overkill?

> There is a CLK_IGNORE_UNUSED flag which disables this behavior for all
> clocks which have it set. Maybe it should be set for the problematic
> clock?

Didn't know about that one, thanks!  It seems like a bit annoying that
we'd have to keep this clock all the time just to get reset working,
though.  I guess in 3.4 that's what we did, though I don't know if it
was intentional...

-Doug


From rjw at sisk.pl  Mon Apr  8 15:49:33 2013
From: rjw at sisk.pl (Rafael J. Wysocki)
Date: Mon, 08 Apr 2013 21:49:33 +0200
Subject: [PATCH V5 0/4] cpufreq: exynos5440: support for cpufreq driver
In-Reply-To: <2d0501ce3450$fac4e9c0$f04ebd40$%kim@samsung.com>
References: <1364457923-8499-1-git-send-email-amit.daniel@samsung.com>
 <CADGdYn7ZRCSymU7k3Sn4mbS6B=dxy1N+vhQuyiFnhOQLLzrTbw@mail.gmail.com>
 <2d0501ce3450$fac4e9c0$f04ebd40$%kim@samsung.com>
Message-ID: <1403255.89Vcuzrghk@vostro.rjw.lan>

On Monday, April 08, 2013 09:02:44 PM Kukjin Kim wrote:
> amit daniel kachhap wrote:
> > 
> > On Fri, Apr 5, 2013 at 6:08 PM, Rafael J. Wysocki <rjw at sisk.pl> wrote:
> > > On Thursday, March 28, 2013 01:35:18 PM Amit Daniel Kachhap wrote:
> > >> Submitting the V5 version of exynos5440 cpufreq driver. This patchset
> > addresses
> > >> all the coding and design concerns raised especially by Viresh.
> > >>
> > >> Changes in V5:
> > >> * Removed the unnecessary DT look up entry from mach-exynos5-dt.c.
> > >> * Fixed all coding and comments issue raised by Viresh.
> > >>
> > >> Changes in V4:
> > >> * Added dev_err logs instead of pr_err.
> > >> * Used the devm_ioremap_resource API.
> > >> * Implemented several coding guidelines and minor error comments from
> > Sylwester,
> > >>   Russell and Viresh.
> > >>
> > >> Changes in V3:
> > >> * Converted the driver to probe based as suggested by Viresh. This is
> > also
> > >>   beneficial for multiplatform kernel.
> > >> * Other coding guidelines related changes.
> > >> * Moved the DT node outside cpu0 node as the driver is now a platform
> > >>   driver.
> > >>
> > >> Changes in V2:
> > >> * Added OPP library support to parse DT parameters.
> > >> * Removed a hack to handle interrupts in bootup.
> > >> * Implemented other review comments from Viresh and Inder.
> > >>
> > >> All these patches are dependent on Thomas Abraham common clock patches.
> > >> (http://www.mail-archive.com/linux-samsung-
> > soc at vger.kernel.org/msg15860.html)
> > >> This whole patch series is based on 3.9-rc4.
> > >>
> > >> Amit Daniel Kachhap (4):
> > >>   cpufreq: exynos: Add cpufreq driver for exynos5440
> > >>   cpufreq: exynos: Remove error return even if no soc is found
> > >>   arm: exynos: Enable OPP library support for exynos5440
> > >>   arm: dts: Add cpufreq controller node for Exynos5440 SoC
> > >>
> > >>  .../bindings/cpufreq/cpufreq-exynos5440.txt        |   28 ++
> > >>  arch/arm/boot/dts/exynos5440.dtsi                  |   12 +
> > >>  arch/arm/mach-exynos/Kconfig                       |    2 +
> > >>  drivers/cpufreq/Kconfig.arm                        |    9 +
> > >>  drivers/cpufreq/Makefile                           |    1 +
> > >>  drivers/cpufreq/exynos-cpufreq.c                   |    2 +-
> > >>  drivers/cpufreq/exynos5440-cpufreq.c               |  474
> > ++++++++++++++++++++
> > >>  7 files changed, 527 insertions(+), 1 deletions(-)
> > >>  create mode 100644 Documentation/devicetree/bindings/cpufreq/cpufreq-
> > exynos5440.txt
> > >>  create mode 100644 drivers/cpufreq/exynos5440-cpufreq.c
> > >
> > > Is this for me or the Samsung tree?
> > >
> > > If it's for me, I need ACKs from the Samsung tree maintainers.  Also,
> > please
> > > address the Viresh's comments.
> > >
> > > Thanks,
> > > Rafael
> > >
> > Hi Rafael,
> > 
> > I submitted the V6 version with all comments from Viresh addressed.
> > 
> > Hi Kukjin Kim,
> > 
> > Any suggestion on how this patch should be merged. In my opinion it
> > should go via Rafael's tree as this patch uses some fixes present in
> > Rafael's tree like modified cpufreq_notify_transition API.
> > 
> Yes, I agree. The v6 series including resending 1/4 patch looks good to me.
> But the patch V6 4/4 would be sent to upstream via samsung tree to avoid
> useless merge conflicts and I think, it's possible.
> 
> So Rafael, please take 1/4 ~ 3/4 patches in your tree with my ack.
> 
> Acked-by: Kukjin Kim <kgene.kim at samsung.com>
> 
> If any problems, please let me know.

I will, thank you!

Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.


From s.hauer at pengutronix.de  Mon Apr  8 15:46:03 2013
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Mon,  8 Apr 2013 21:46:03 +0200
Subject: [PATCH] ARM i.MX53: remove platform ahci support
In-Reply-To: <1365431039.1830.102.camel@x61.thuisdomein>
References: <1365431039.1830.102.camel@x61.thuisdomein>
Message-ID: <1365450363-6582-1-git-send-email-s.hauer@pengutronix.de>

The i.MX53 ahci platform support is unused in mainline. To demotivate
people using it just remove it from the tree.

Signed-off-by: Sascha Hauer <s.hauer at pengutronix.de>
---

Paul, with this one applied you could also remove config ARCH_MX53.

 arch/arm/plat-mxc/devices/Kconfig               |   4 -
 arch/arm/plat-mxc/devices/Makefile              |   1 -
 arch/arm/plat-mxc/devices/platform-ahci-imx.c   | 156 ------------------------
 arch/arm/plat-mxc/include/mach/devices-common.h |  10 --
 4 files changed, 171 deletions(-)
 delete mode 100644 arch/arm/plat-mxc/devices/platform-ahci-imx.c

diff --git a/arch/arm/plat-mxc/devices/Kconfig b/arch/arm/plat-mxc/devices/Kconfig
index a35d984..02404d0 100644
--- a/arch/arm/plat-mxc/devices/Kconfig
+++ b/arch/arm/plat-mxc/devices/Kconfig
@@ -83,7 +83,3 @@ config IMX_HAVE_PLATFORM_SDHCI_ESDHC_IMX
 
 config IMX_HAVE_PLATFORM_SPI_IMX
 	bool
-
-config IMX_HAVE_PLATFORM_AHCI
-	bool
-	default y if ARCH_MX53
diff --git a/arch/arm/plat-mxc/devices/Makefile b/arch/arm/plat-mxc/devices/Makefile
index 76f3195..cd8d572 100644
--- a/arch/arm/plat-mxc/devices/Makefile
+++ b/arch/arm/plat-mxc/devices/Makefile
@@ -27,4 +27,3 @@ obj-$(CONFIG_IMX_HAVE_PLATFORM_MXC_RTC) += platform-mxc_rtc.o
 obj-$(CONFIG_IMX_HAVE_PLATFORM_MXC_W1) += platform-mxc_w1.o
 obj-$(CONFIG_IMX_HAVE_PLATFORM_SDHCI_ESDHC_IMX) += platform-sdhci-esdhc-imx.o
 obj-$(CONFIG_IMX_HAVE_PLATFORM_SPI_IMX) +=  platform-spi_imx.o
-obj-$(CONFIG_IMX_HAVE_PLATFORM_AHCI) +=  platform-ahci-imx.o
diff --git a/arch/arm/plat-mxc/devices/platform-ahci-imx.c b/arch/arm/plat-mxc/devices/platform-ahci-imx.c
deleted file mode 100644
index ade4a1c..0000000
--- a/arch/arm/plat-mxc/devices/platform-ahci-imx.c
+++ /dev/null
@@ -1,156 +0,0 @@
-/*
- * Copyright (C) 2011 Freescale Semiconductor, Inc. All Rights Reserved.
- */
-
-/*
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
-
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
-
- * You should have received a copy of the GNU General Public License along
- * with this program; if not, write to the Free Software Foundation, Inc.,
- * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
- */
-
-#include <linux/io.h>
-#include <linux/clk.h>
-#include <linux/err.h>
-#include <linux/device.h>
-#include <linux/dma-mapping.h>
-#include <asm/sizes.h>
-#include <mach/hardware.h>
-#include <mach/devices-common.h>
-
-#define imx_ahci_imx_data_entry_single(soc, _devid)		\
-	{								\
-		.devid = _devid,					\
-		.iobase = soc ## _SATA_BASE_ADDR,			\
-		.irq = soc ## _INT_SATA,				\
-	}
-
-#ifdef CONFIG_SOC_IMX53
-const struct imx_ahci_imx_data imx53_ahci_imx_data __initconst =
-	imx_ahci_imx_data_entry_single(MX53, "imx53-ahci");
-#endif
-
-enum {
-	HOST_CAP = 0x00,
-	HOST_CAP_SSS = (1 << 27), /* Staggered Spin-up */
-	HOST_PORTS_IMPL	= 0x0c,
-	HOST_TIMER1MS = 0xe0, /* Timer 1-ms */
-};
-
-static struct clk *sata_clk, *sata_ref_clk;
-
-/* AHCI module Initialization, if return 0, initialization is successful. */
-static int imx_sata_init(struct device *dev, void __iomem *addr)
-{
-	u32 tmpdata;
-	int ret = 0;
-	struct clk *clk;
-
-	sata_clk = clk_get(dev, "ahci");
-	if (IS_ERR(sata_clk)) {
-		dev_err(dev, "no sata clock.\n");
-		return PTR_ERR(sata_clk);
-	}
-	ret = clk_prepare_enable(sata_clk);
-	if (ret) {
-		dev_err(dev, "can't prepare/enable sata clock.\n");
-		goto put_sata_clk;
-	}
-
-	/* Get the AHCI SATA PHY CLK */
-	sata_ref_clk = clk_get(dev, "ahci_phy");
-	if (IS_ERR(sata_ref_clk)) {
-		dev_err(dev, "no sata ref clock.\n");
-		ret = PTR_ERR(sata_ref_clk);
-		goto release_sata_clk;
-	}
-	ret = clk_prepare_enable(sata_ref_clk);
-	if (ret) {
-		dev_err(dev, "can't prepare/enable sata ref clock.\n");
-		goto put_sata_ref_clk;
-	}
-
-	/* Get the AHB clock rate, and configure the TIMER1MS reg later */
-	clk = clk_get(dev, "ahci_dma");
-	if (IS_ERR(clk)) {
-		dev_err(dev, "no dma clock.\n");
-		ret = PTR_ERR(clk);
-		goto release_sata_ref_clk;
-	}
-	tmpdata = clk_get_rate(clk) / 1000;
-	clk_put(clk);
-
-	writel(tmpdata, addr + HOST_TIMER1MS);
-
-	tmpdata = readl(addr + HOST_CAP);
-	if (!(tmpdata & HOST_CAP_SSS)) {
-		tmpdata |= HOST_CAP_SSS;
-		writel(tmpdata, addr + HOST_CAP);
-	}
-
-	if (!(readl(addr + HOST_PORTS_IMPL) & 0x1))
-		writel((readl(addr + HOST_PORTS_IMPL) | 0x1),
-			addr + HOST_PORTS_IMPL);
-
-	return 0;
-
-release_sata_ref_clk:
-	clk_disable_unprepare(sata_ref_clk);
-put_sata_ref_clk:
-	clk_put(sata_ref_clk);
-release_sata_clk:
-	clk_disable_unprepare(sata_clk);
-put_sata_clk:
-	clk_put(sata_clk);
-
-	return ret;
-}
-
-static void imx_sata_exit(struct device *dev)
-{
-	clk_disable_unprepare(sata_ref_clk);
-	clk_put(sata_ref_clk);
-
-	clk_disable_unprepare(sata_clk);
-	clk_put(sata_clk);
-
-}
-struct platform_device *__init imx_add_ahci_imx(
-		const struct imx_ahci_imx_data *data,
-		const struct ahci_platform_data *pdata)
-{
-	struct resource res[] = {
-		{
-			.start = data->iobase,
-			.end = data->iobase + SZ_4K - 1,
-			.flags = IORESOURCE_MEM,
-		}, {
-			.start = data->irq,
-			.end = data->irq,
-			.flags = IORESOURCE_IRQ,
-		},
-	};
-
-	return imx_add_platform_device_dmamask(data->devid, 0,
-			res, ARRAY_SIZE(res),
-			pdata, sizeof(*pdata),  DMA_BIT_MASK(32));
-}
-
-struct platform_device *__init imx53_add_ahci_imx(void)
-{
-	struct ahci_platform_data pdata = {
-		.init = imx_sata_init,
-		.exit = imx_sata_exit,
-	};
-
-	return imx_add_ahci_imx(&imx53_ahci_imx_data, &pdata);
-}
diff --git a/arch/arm/plat-mxc/include/mach/devices-common.h b/arch/arm/plat-mxc/include/mach/devices-common.h
index eaf79d2..ab5f88c 100644
--- a/arch/arm/plat-mxc/include/mach/devices-common.h
+++ b/arch/arm/plat-mxc/include/mach/devices-common.h
@@ -329,13 +329,3 @@ struct platform_device *__init imx_add_spi_imx(
 struct platform_device *imx_add_imx_dma(void);
 struct platform_device *imx_add_imx_sdma(char *name,
 	resource_size_t iobase, int irq, struct sdma_platform_data *pdata);
-
-#include <linux/ahci_platform.h>
-struct imx_ahci_imx_data {
-	const char *devid;
-	resource_size_t iobase;
-	resource_size_t irq;
-};
-struct platform_device *__init imx_add_ahci_imx(
-		const struct imx_ahci_imx_data *data,
-		const struct ahci_platform_data *pdata);
-- 
1.8.2.rc2



From sylvester.nawrocki at gmail.com  Mon Apr  8 15:53:07 2013
From: sylvester.nawrocki at gmail.com (Sylwester Nawrocki)
Date: Mon,  8 Apr 2013 21:53:07 +0200
Subject: [PATCH] ARM: S3C24XX: Fix interrupt pending register offset of the
 EINT controller
Message-ID: <1365450787-14473-1-git-send-email-s.nawrocki@samsung.com>

The external pending interrupt register address (EINTPEND) offset is
0xa8, not 0x08. Without this patch the external interrupts are not
properly acknowledged, which may lead to an interrupt storm and the
system hang as soon as any external interrupt is requested.

Signed-off-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
---

This patch is for _3.9_. I'm going to send a similar patch for 3.10-rc2
for drivers/irqchip/irq-s3c24xx.c.
---
 arch/arm/mach-s3c24xx/irq.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-s3c24xx/irq.c b/arch/arm/mach-s3c24xx/irq.c
index cb9f5e0..d8ba9be 100644
--- a/arch/arm/mach-s3c24xx/irq.c
+++ b/arch/arm/mach-s3c24xx/irq.c
@@ -500,7 +500,7 @@ struct s3c_irq_intc *s3c24xx_init_intc(struct device_node *np,
 		base = (void *)0xfd000000;

 		intc->reg_mask = base + 0xa4;
-		intc->reg_pending = base + 0x08;
+		intc->reg_pending = base + 0xa8;
 		irq_num = 20;
 		irq_start = S3C2410_IRQ(32);
 		irq_offset = 4;
--
1.7.4.1



From s.hauer at pengutronix.de  Mon Apr  8 16:00:38 2013
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Mon, 8 Apr 2013 22:00:38 +0200
Subject: [RFC PATCH] CLK: Allow parent clock and rate to be configured in
 DT.
In-Reply-To: <51628F61.9000300@parkeon.com>
References: <20130319170933.28337.50448.stgit@localhost>
 <CAOMZO5ASkvquyzPCEGObvB5Xh9bDPTJ2zx26eOUJT_Vb36Bn3Q@mail.gmail.com>
 <CAKGA1bkWLrOs15ni=8D__BvuG6kvqkeeLZGOLrVZY9g0q0z4Bg@mail.gmail.com>
 <6581638.FPkNsv6peb@flatron> <20130407132623.GP1906@pengutronix.de>
 <51628F61.9000300@parkeon.com>
Message-ID: <20130408200038.GU1906@pengutronix.de>

On Mon, Apr 08, 2013 at 11:35:29AM +0200, Martin Fuzzey wrote:
> On 07/04/13 15:26, Sascha Hauer wrote:
> >
> >Honestly I'm annoyed by this aswell. The devicetree contains a nice and
> >complete hardware description and it seems convenient to put hardware
> >related configuration data there aswell.
> Yes
> >The problem is that hardware description and configuration data are two
> >completely different sets of data. The hardware description is static
> >for a given board and should (ideally) never change. The configuration
> >data instead is often usecase specific and changes over the lifetime of
> >a board. The configuration data can only handle a single (or maybe a
> >table of) static setup(s). It's a good way to specify a sane default or
> >a very special setup, but doesn't handle the case when some OS (or
> >version thereof) wants to have a static setup and another wants to
> >figure out the same data dynamically.
> Agreed
> >For these reasons I am against throwing the two data sets into a single
> >pot. Still I also want to have the devicetree way to configure some
> >static setup items.
> Sure but why does using the DT for both mean "throwing them into a
> single pot?"

Because most likely without further intervention they would end up in
the dts files in the kernel tree. This for example happened to the
mtd partitions for several boards. This means the kernel dts files now
enforce a certain partitioning which is not very nice.

> 
> I think we need to seperate the ideas of "DT as a container format"
> and "semantics of DT nodes".
> 
> The format is the same everywhere but the semantics could change in
> different parts of the tree.
> 
> Since the DT is a tree structure surely all we need to do is agree
> on a designated configuration root node
> "linux-config" for example under which we put all configuration
> related stuff specific to linux whilst
> retaining the "hardware description only" rule for the rest of the DT.

Fine with me, but I was also referring to the dts source files. Ideally
even the bootloader has a devicetree dtb and a configuration overlay dtb
so that both could be changed independently.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From pebolle at tiscali.nl  Mon Apr  8 16:03:03 2013
From: pebolle at tiscali.nl (Paul Bolle)
Date: Mon, 08 Apr 2013 22:03:03 +0200
Subject: [PATCH] ARM i.MX53: remove platform ahci support
In-Reply-To: <1365450363-6582-1-git-send-email-s.hauer@pengutronix.de>
References: <1365431039.1830.102.camel@x61.thuisdomein>
 <1365450363-6582-1-git-send-email-s.hauer@pengutronix.de>
Message-ID: <1365451383.1830.135.camel@x61.thuisdomein>

On Mon, 2013-04-08 at 21:46 +0200, Sascha Hauer wrote:
> Paul, with this one applied you could also remove config ARCH_MX53.

Unless I'm doing something wrong, this doesn't apply onto v3.9-rc6. I
guess it requires some other branch. But, assuming I don't get fed up
with cleaning up Kconfig cruft, I will notice ARCH_MX53 getting unused
when your patch hits mainline anyway.

But is there a reason you can't just remove ARCH_MX53 yourself?


Paul Bolle



From fabian at ritter-vogt.de  Mon Apr  8 16:06:29 2013
From: fabian at ritter-vogt.de (Fabian Vogt)
Date: Mon, 08 Apr 2013 22:06:29 +0200
Subject: [RFC PATCH arm: initial TI-Nspire support]
In-Reply-To: <201304082138.15875.arnd@arndb.de>
References: <6FE4B33E-A503-4A75-AEED-831CB2C06D83@gmail.com>
 <896CB251-17FC-4327-BA4E-A8FD9ED1BEC7@gmail.com>
 <op.wu8k5pwqu7prd4@fabians-laptop.fritz.box>
 <201304082138.15875.arnd@arndb.de>
Message-ID: <op.wu8ng3wyu7prd4@fabians-laptop.fritz.box>

> On Monday 08 April 2013, Fabian Vogt wrote:
>> The latest kernel it seems to get stuck at
>> console_lock() in do_register_framebuffer (drivers/video/fbmem.c:1655)
>> if the LCD-controller is enabled. (Early printk and serial console works
>> fine)
>> CONFIG_NO_HZ is not activated, it works completely.
>> Could this be a kernel bug or is this an issue with our timer
>> configuration?
>
> This usually happens when the console driver or anything it uses
> calls a function that does a printk(), which means you get a recursive
> call into the console code and try to get the same lock again.
Yes, I've heard that before, but than it would work/not work independently
of NO_HZ. Can printk's be executet within console_lock() ..  
console_unlock() blocks?
If not, it could be fb_notifier_call_chain, too, but that wouldn't be  
likely at all.
I also tried spinlock/mutex debugging and soft lockup detection,
but neither of them outputs anything.


From sylvester.nawrocki at gmail.com  Mon Apr  8 16:10:57 2013
From: sylvester.nawrocki at gmail.com (Sylwester Nawrocki)
Date: Mon, 08 Apr 2013 22:10:57 +0200
Subject: [GIT PULL 10/10] devel-samsung for v3.10
In-Reply-To: <51630A55.6030703@samsung.com>
References: <51630A55.6030703@samsung.com>
Message-ID: <51632451.3050801@gmail.com>

On 04/08/2013 08:20 PM, Kukjin Kim wrote:
> The following changes since commit
> 6dbe51c251a327e012439c4772097a13df43c5b8:
>
> Linux 3.9-rc1 (2013-03-03 15:11:05 -0800)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
> tags/devel-samsung-for-v3.10
>
> for you to fetch changes up to 298591f89fd0f3f779a77e589ce2f1c28e9788ed:
>
> ARM: EXYNOS: replace cpumask by the corresponding macro (2013-04-09
> 00:44:35 +0900)
>
> ----------------------------------------------------------------
> including various development for samsung for v3.10
>
> ----------------------------------------------------------------
> Charles Keepax (2):
> ARM: S3C64XX: Clear DMA flags on channel request
> ARM: S3C64XX: Slow down mic detection rate for wm5102
>
> Daniel Lezcano (3):
> ARM: EXYNOS: factor out the idle states
> ARM: EXYNOS: handle properly the return values
> ARM: EXYNOS: replace cpumask by the corresponding macro
>
> Inderpal Singh (2):
> ARM: EXYNOS: Add support for rtc wakeup
> ARM: SAMSUNG: check processor type before cache restoration in resume
>
> Jonathan Kliegman (2):
> ARM: EXYNOS: Remove hardcode wakeup unmask for EINT_0
> ARM: EXYNOS: Clear ENABLE_WAKEUP_SW bit when entering suspend
>
> Sylwester Nawrocki (2):
> ARM: SAMSUNG: Export MIPI CSIS/DSIM PHY control functions

This one was supposed to be a fix for 3.8-rc IIRC. But anyway the whole
file this patch touches is going to be removed in 3.11.

> ARM: S3C24XX: Correct NR_IRQS definition for s3c2440

And this one is needed for 3.9, sorry for not mentioning it in the patch's
description. Together with [1] it makes my s3c2440 SoC based test board
booting again with 3.9-rc6.

[1] http://www.spinics.net/lists/arm-kernel/msg236643.html

Thanks,
Sylwester


From heiko at sntech.de  Mon Apr  8 16:25:43 2013
From: heiko at sntech.de (Heiko =?iso-8859-15?q?St=FCbner?=)
Date: Mon, 8 Apr 2013 22:25:43 +0200
Subject: [PATCH] ARM: S3C24XX: Fix interrupt pending register offset of
 the EINT controller
In-Reply-To: <1365450787-14473-1-git-send-email-s.nawrocki@samsung.com>
References: <1365450787-14473-1-git-send-email-s.nawrocki@samsung.com>
Message-ID: <201304082225.43967.heiko@sntech.de>

Am Montag, 8. April 2013, 21:53:07 schrieb Sylwester Nawrocki:
> The external pending interrupt register address (EINTPEND) offset is
> 0xa8, not 0x08. Without this patch the external interrupts are not
> properly acknowledged, which may lead to an interrupt storm and the
> system hang as soon as any external interrupt is requested.
> 
> Signed-off-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
yep, I unintentionally introduced a typo there and the register really is 
0xa8, so thanks (again) for the fix

Reviewed-by: Heiko Stuebner <heiko at sntech.de>
 

> ---
> 
> This patch is for _3.9_. I'm going to send a similar patch for 3.10-rc2
> for drivers/irqchip/irq-s3c24xx.c.
> ---
>  arch/arm/mach-s3c24xx/irq.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/arm/mach-s3c24xx/irq.c b/arch/arm/mach-s3c24xx/irq.c
> index cb9f5e0..d8ba9be 100644
> --- a/arch/arm/mach-s3c24xx/irq.c
> +++ b/arch/arm/mach-s3c24xx/irq.c
> @@ -500,7 +500,7 @@ struct s3c_irq_intc *s3c24xx_init_intc(struct
> device_node *np, base = (void *)0xfd000000;
> 
>  		intc->reg_mask = base + 0xa4;
> -		intc->reg_pending = base + 0x08;
> +		intc->reg_pending = base + 0xa8;
>  		irq_num = 20;
>  		irq_start = S3C2410_IRQ(32);
>  		irq_offset = 4;
> --
> 1.7.4.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-samsung-soc" in the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



From bhelgaas at google.com  Mon Apr  8 16:29:59 2013
From: bhelgaas at google.com (Bjorn Helgaas)
Date: Mon, 8 Apr 2013 14:29:59 -0600
Subject: [PATCHv7 08/17] pci: PCIe driver for Marvell Armada 370/XP systems
In-Reply-To: <1364395234-11195-9-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1364395234-11195-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1364395234-11195-9-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <CAErSpo7fGPe3wFha36kNMxeRP4gBpBWgfw85aTLey-DSz2ZYew@mail.gmail.com>

On Wed, Mar 27, 2013 at 8:40 AM, Thomas Petazzoni
<thomas.petazzoni at free-electrons.com> wrote:
> This driver implements the support for the PCIe interfaces on the
> Marvell Armada 370/XP ARM SoCs. In the future, it might be extended to
> cover earlier families of Marvell SoCs, such as Dove, Orion and
> Kirkwood.
>
> The driver implements the hw_pci operations needed by the core ARM PCI
> code to setup PCI devices and get their corresponding IRQs, and the
> pci_ops operations that are used by the PCI core to read/write the
> configuration space of PCI devices.
>
> Since the PCIe interfaces of Marvell SoCs are completely separate and
> not linked together in a bus, this driver sets up an emulated PCI host
> bridge, with one PCI-to-PCI bridge as child for each hardware PCIe
> interface.
>
> In addition, this driver enumerates the different PCIe slots, and for
> those having a device plugged in, it sets up the necessary address
> decoding windows, using the new armada_370_xp_alloc_pcie_window()
> function from mach-mvebu/addr-map.c.
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>

Acked-by: Bjorn Helgaas <bhelgaas at google.com>

A few trivial comments below; it's up to you whether you do anything
with them or not.  It's OK with me if you ignore them :)

The only thing I saw that might be a bug is the resource_size()
question in mvebu_pcie_probe().

Bjorn

> diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
> new file mode 100644
> index 0000000..3ad563f
> --- /dev/null
> +++ b/drivers/pci/host/Makefile
> @@ -0,0 +1,4 @@
> +obj-$(CONFIG_PCI_MVEBU) += pci-mvebu.o
> +CFLAGS_pci-mvebu.o += \
> +       -I$(srctree)/arch/arm/plat-orion/include \
> +       -I$(srctree)/arch/arm/mach-mvebu/include

Too bad to have to adjust CFLAGS here.  Seems like I remember earlier
discussion, but I didn't pay much attention, and if this is the best
we can do, I guess it's OK.

> diff --git a/drivers/pci/host/pci-mvebu.c b/drivers/pci/host/pci-mvebu.c
> new file mode 100644
> index 0000000..289babd
> --- /dev/null
> +++ b/drivers/pci/host/pci-mvebu.c
> @@ -0,0 +1,927 @@
> +/*
> + * PCIe driver for Marvell Armada 370 and Armada XP SoCs
> + *
> + * 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/kernel.h>
> +#include <linux/pci.h>
> +#include <linux/clk.h>
> +#include <linux/module.h>
> +#include <linux/mbus.h>
> +#include <linux/slab.h>
> +#include <linux/platform_device.h>
> +#include <linux/of_address.h>
> +#include <linux/of_pci.h>
> +#include <linux/of_irq.h>
> +#include <linux/of_platform.h>
> +
> +/*
> + * PCIe unit register offsets.
> + */
> +#define PCIE_DEV_ID_OFF                0x0000
> +#define PCIE_CMD_OFF           0x0004
> +#define PCIE_DEV_REV_OFF       0x0008
> +#define PCIE_BAR_LO_OFF(n)     (0x0010 + ((n) << 3))
> +#define PCIE_BAR_HI_OFF(n)     (0x0014 + ((n) << 3))
> +#define PCIE_HEADER_LOG_4_OFF  0x0128
> +#define PCIE_BAR_CTRL_OFF(n)   (0x1804 + ((n - 1) * 4))

Strictly speaking, I suppose you should have "(((n) - 1) ..." here.

> +#define PCIE_WIN04_CTRL_OFF(n) (0x1820 + ((n) << 4))
> +#define PCIE_WIN04_BASE_OFF(n) (0x1824 + ((n) << 4))
> +#define PCIE_WIN04_REMAP_OFF(n)        (0x182c + ((n) << 4))
> +#define PCIE_WIN5_CTRL_OFF     0x1880
> +#define PCIE_WIN5_BASE_OFF     0x1884
> +#define PCIE_WIN5_REMAP_OFF    0x188c
> +#define PCIE_CONF_ADDR_OFF     0x18f8
> +#define  PCIE_CONF_ADDR_EN             0x80000000
> +#define  PCIE_CONF_REG(r)              ((((r) & 0xf00) << 16) | ((r) & 0xfc))
> +#define  PCIE_CONF_BUS(b)              (((b) & 0xff) << 16)
> +#define  PCIE_CONF_DEV(d)              (((d) & 0x1f) << 11)
> +#define  PCIE_CONF_FUNC(f)             (((f) & 0x7) << 8)
> +#define PCIE_CONF_DATA_OFF     0x18fc
> +#define PCIE_MASK_OFF          0x1910
> +#define PCIE_CTRL_OFF          0x1a00
> +#define  PCIE_CTRL_X1_MODE             0x0001
> +#define PCIE_STAT_OFF          0x1a04
> +#define  PCIE_STAT_DEV_OFFS            20
> +#define  PCIE_STAT_DEV_MASK            0x1f
> +#define  PCIE_STAT_BUS_OFFS            8
> +#define  PCIE_STAT_BUS_MASK            0xff
> +#define  PCIE_STAT_LINK_DOWN           1

Whoever wrote pci_regs.h came up with a style I kind of like: the bit
masks are already shifted so you can see where they are in the value,
and there are no #defines for the shifts, e.g.,

#define PCI_EXP_FLAGS_TYPE      0x00f0  /* Device/Port type */

The users of PCI_EXP_FLAGS_TYPE just have a bare ">> 4" where
necessary.  It seems like a good compromise that uses only one symbol
(good for grepping), gives good visual indication in the header file
of how the value is laid out, allows clearing bits without shifts, and
clearly shows what's happening at the uses.

But what you have is OK, too :)

> +#define PCIE_DEBUG_CTRL         0x1a60
> +#define  PCIE_DEBUG_SOFT_RESET         (1<<20)
> +
> +/*
> + * This product ID is registered by Marvell, and used when the Marvell
> + * SoC is not the root complex, but an endpoint on the PCIe bus. It is
> + * therefore safe to re-use this PCI ID for our emulated PCI-to-PCI
> + * bridge.
> + */
> +#define MARVELL_EMULATED_PCI_PCI_BRIDGE_ID 0x7846
> +
> +/* PCI configuration space of a PCI-to-PCI bridge */
> +struct mvebu_sw_pci_bridge {
> +       u16 vendor;
> +       u16 device;
> +       u16 command;
> +       u16 status;
> +       u16 class;
> +       u8 interface;
> +       u8 revision;
> +       u8 bist;
> +       u8 header_type;
> +       u8 latency_timer;
> +       u8 cache_line_size;
> +       u32 bar[2];
> +       u8 primary_bus;
> +       u8 secondary_bus;
> +       u8 subordinate_bus;
> +       u8 secondary_latency_timer;
> +       u8 iobase;
> +       u8 iolimit;
> +       u16 secondary_status;
> +       u16 membase;
> +       u16 memlimit;
> +       u16 prefmembase;
> +       u16 prefmemlimit;
> +       u32 prefbaseupper;
> +       u32 preflimitupper;
> +       u16 iobaseupper;
> +       u16 iolimitupper;
> +       u8 cappointer;
> +       u8 reserved1;
> +       u16 reserved2;
> +       u32 romaddr;
> +       u8 intline;
> +       u8 intpin;
> +       u16 bridgectrl;
> +};
> +
> +struct mvebu_pcie_port;
> +
> +/* Structure representing all PCIe interfaces */
> +struct mvebu_pcie {
> +       struct platform_device *pdev;
> +       struct mvebu_pcie_port *ports;
> +       struct resource io;
> +       struct resource realio;
> +       struct resource mem;
> +       struct resource busn;
> +       int nports;
> +};
> +
> +/* Structure representing one PCIe interface */
> +struct mvebu_pcie_port {
> +       char *name;
> +       void __iomem *base;
> +       spinlock_t conf_lock;
> +       int haslink;
> +       u32 port;
> +       u32 lane;
> +       int devfn;
> +       struct clk *clk;
> +       struct mvebu_sw_pci_bridge bridge;
> +       struct device_node *dn;
> +       struct mvebu_pcie *pcie;
> +       phys_addr_t memwin_base;
> +       size_t memwin_size;
> +       phys_addr_t iowin_base;
> +       size_t iowin_size;
> +};
> +
> +static int mvebu_pcie_link_up(void __iomem *base)

This could return bool, I guess.

I think I would make

  mvebu_pcie_link_up()
  mvebu_pcie_set_local_bus_nr()
  mvebu_pcie_setup_wins()
  mvebu_pcie_setup_hw()
  mvebu_pcie_hw_rd_conf()
  mvebu_pcie_hw_wr_conf()

all take a "struct mvebu_pcie_port *port" directly rather than having
the caller pass in "port->base", but maybe you have a reason for doing
otherwise.

> +{
> +       return !(readl(base + PCIE_STAT_OFF) & PCIE_STAT_LINK_DOWN);
> +}
> +
> +static void mvebu_pcie_set_local_bus_nr(void __iomem *base, int nr)
> +{
> +       u32 stat;
> +
> +       stat = readl(base + PCIE_STAT_OFF);
> +       stat &= ~(PCIE_STAT_BUS_MASK << PCIE_STAT_BUS_OFFS);
> +       stat |= nr << PCIE_STAT_BUS_OFFS;
> +       writel(stat, base + PCIE_STAT_OFF);
> +}
> +
> +/*
> + * Setup PCIE BARs and Address Decode Wins:
> + * BAR[0,2] -> disabled, BAR[1] -> covers all DRAM banks
> + * WIN[0-3] -> DRAM bank[0-3]
> + */
> +static void __init mvebu_pcie_setup_wins(void __iomem *base)
> +{
> +       const struct mbus_dram_target_info *dram;
> +       u32 size;
> +       int i;
> +
> +       dram = mv_mbus_dram_info();
> +
> +       /*
> +        * First, disable and clear BARs and windows.
> +        */

Typically single-line comments would be "/* ... */" all on one line.

> +       for (i = 1; i <= 2; i++) {

Interesting use of "i <= 2" rather than the typical "i < 3".

> +               writel(0, base + PCIE_BAR_CTRL_OFF(i));
> +               writel(0, base + PCIE_BAR_LO_OFF(i));
> +               writel(0, base + PCIE_BAR_HI_OFF(i));
> +       }
> +
> +       for (i = 0; i < 5; i++) {
> +               writel(0, base + PCIE_WIN04_CTRL_OFF(i));
> +               writel(0, base + PCIE_WIN04_BASE_OFF(i));
> +               writel(0, base + PCIE_WIN04_REMAP_OFF(i));
> +       }
> +
> +       writel(0, base + PCIE_WIN5_CTRL_OFF);
> +       writel(0, base + PCIE_WIN5_BASE_OFF);
> +       writel(0, base + PCIE_WIN5_REMAP_OFF);
> +
> +       /*
> +        * Setup windows for DDR banks.  Count total DDR size on the fly.
> +        */
> +       size = 0;
> +       for (i = 0; i < dram->num_cs; i++) {
> +               const struct mbus_dram_window *cs = dram->cs + i;
> +
> +               writel(cs->base & 0xffff0000, base + PCIE_WIN04_BASE_OFF(i));
> +               writel(0, base + PCIE_WIN04_REMAP_OFF(i));
> +               writel(((cs->size - 1) & 0xffff0000) |
> +                       (cs->mbus_attr << 8) |
> +                       (dram->mbus_dram_target_id << 4) | 1,
> +                               base + PCIE_WIN04_CTRL_OFF(i));
> +
> +               size += cs->size;
> +       }
> +
> +       /*
> +        * Round up 'size' to the nearest power of two.
> +        */
> +       if ((size & (size - 1)) != 0)
> +               size = 1 << fls(size);
> +
> +       /*
> +        * Setup BAR[1] to all DRAM banks.
> +        */
> +       writel(dram->cs[0].base, base + PCIE_BAR_LO_OFF(1));
> +       writel(0, base + PCIE_BAR_HI_OFF(1));
> +       writel(((size - 1) & 0xffff0000) | 1, base + PCIE_BAR_CTRL_OFF(1));
> +}
> +
> +static void __init mvebu_pcie_setup_hw(void __iomem *base)
> +{
> +       u16 cmd;
> +       u32 mask;
> +
> +       /*
> +        * Point PCIe unit MBUS decode windows to DRAM space.
> +        */
> +       mvebu_pcie_setup_wins(base);
> +
> +       /*
> +        * Master + slave enable.
> +        */
> +       cmd = readw(base + PCIE_CMD_OFF);
> +       cmd |= PCI_COMMAND_IO;
> +       cmd |= PCI_COMMAND_MEMORY;
> +       cmd |= PCI_COMMAND_MASTER;
> +       writew(cmd, base + PCIE_CMD_OFF);
> +
> +       /*
> +        * Enable interrupt lines A-D.
> +        */
> +       mask = readl(base + PCIE_MASK_OFF);
> +       mask |= 0x0f000000;

No #defines for these bits?

> +       writel(mask, base + PCIE_MASK_OFF);
> +}
> +
> +static int mvebu_pcie_hw_rd_conf(void __iomem *base, struct pci_bus *bus,
> +                                u32 devfn, int where, int size, u32 *val)
> +{
> +       writel(PCIE_CONF_BUS(bus->number) |
> +               PCIE_CONF_DEV(PCI_SLOT(devfn)) |
> +               PCIE_CONF_FUNC(PCI_FUNC(devfn)) |
> +               PCIE_CONF_REG(where) | PCIE_CONF_ADDR_EN,

A "PCIE_CONF_ADDR(busnr, devfn, where)" macro would be nice here.

> +                       base + PCIE_CONF_ADDR_OFF);
> +
> +       *val = readl(base + PCIE_CONF_DATA_OFF);
> +
> +       if (size == 1)
> +               *val = (*val >> (8 * (where & 3))) & 0xff;
> +       else if (size == 2)
> +               *val = (*val >> (8 * (where & 3))) & 0xffff;
> +
> +       return PCIBIOS_SUCCESSFUL;
> +}
> +
> +static int mvebu_pcie_hw_wr_conf(void __iomem *base, struct pci_bus *bus,
> +                             u32 devfn, int where, int size, u32 val)
> +{
> +       int ret = PCIBIOS_SUCCESSFUL;
> +
> +       writel(PCIE_CONF_BUS(bus->number) |
> +               PCIE_CONF_DEV(PCI_SLOT(devfn)) |
> +               PCIE_CONF_FUNC(PCI_FUNC(devfn)) |
> +               PCIE_CONF_REG(where) | PCIE_CONF_ADDR_EN,
> +                       base + PCIE_CONF_ADDR_OFF);
> +
> +       if (size == 4)
> +               writel(val, base + PCIE_CONF_DATA_OFF);
> +       else if (size == 2)
> +               writew(val, base + PCIE_CONF_DATA_OFF + (where & 3));
> +       else if (size == 1)
> +               writeb(val, base + PCIE_CONF_DATA_OFF + (where & 3));
> +       else
> +               ret = PCIBIOS_BAD_REGISTER_NUMBER;
> +
> +       return ret;
> +}
> +
> +static void mvebu_pcie_handle_iobase_change(struct mvebu_pcie_port *port)
> +{
> +       phys_addr_t iobase;
> +
> +       /* Are the current iobase/iolimit values invalid? */

I first thought "current ... values" meant "the values before the
change."  If you used "new values" it might be clearer that this is
used to handle *writes* to the window base/size registers, and that
we're looking at the values being written.

> +       if (port->bridge.iolimit < port->bridge.iobase ||
> +           port->bridge.iolimitupper < port->bridge.iobaseupper) {
> +
> +               /* If a window was configured, remove it */
> +               if (port->iowin_base) {
> +                       mvebu_mbus_del_window(port->iowin_base,
> +                                             port->iowin_size);
> +                       port->iowin_base = 0;
> +                       port->iowin_size = 0;
> +               }
> +
> +               return;
> +       }
> +
> +       /*
> +        * We read the PCI-to-PCI bridge emulated registers, and
> +        * calculate the base address and size of the address decoding
> +        * window to setup, according to the PCI-to-PCI bridge
> +        * specifications. iobase is the bus address, port->iowin_base
> +        * is the CPU address.
> +        */
> +       iobase = ((port->bridge.iobase & 0xF0) << 8) |
> +               (port->bridge.iobaseupper << 16);
> +       port->iowin_base = port->pcie->io.start + iobase;
> +       port->iowin_size = ((0xFFF | ((port->bridge.iolimit & 0xF0) << 8) |
> +                           (port->bridge.iolimitupper << 16)) -
> +                           iobase);
> +
> +       mvebu_mbus_add_window_remap_flags(port->name, port->iowin_base,
> +                                         port->iowin_size,
> +                                         iobase,
> +                                         MVEBU_MBUS_PCI_IO);
> +
> +       pci_ioremap_io(iobase, port->iowin_base);
> +}
> +
> +static void mvebu_pcie_handle_membase_change(struct mvebu_pcie_port *port)
> +{
> +       /* Are the current membase/memlimit values invalid? */
> +       if (port->bridge.memlimit < port->bridge.membase) {
> +
> +               /* If a window was configured, remove it */
> +               if (port->memwin_base) {
> +                       mvebu_mbus_del_window(port->memwin_base,
> +                                             port->memwin_size);
> +                       port->memwin_base = 0;
> +                       port->memwin_size = 0;
> +               }
> +
> +               return;
> +       }
> +
> +       /*
> +        * We read the PCI-to-PCI bridge emulated registers, and
> +        * calculate the base address and size of the address decoding
> +        * window to setup, according to the PCI-to-PCI bridge
> +        * specifications.
> +        */
> +       port->memwin_base  = ((port->bridge.membase & 0xFFF0) << 16);
> +       port->memwin_size  =
> +               (((port->bridge.memlimit & 0xFFF0) << 16) | 0xFFFFF) -
> +               port->memwin_base;
> +
> +       mvebu_mbus_add_window_remap_flags(port->name, port->memwin_base,
> +                                         port->memwin_size,
> +                                         MVEBU_MBUS_NO_REMAP,
> +                                         MVEBU_MBUS_PCI_MEM);
> +}
> +
> +/*
> + * Initialize the configuration space of the PCI-to-PCI bridge
> + * associated with the given PCIe interface.
> + */
> +static void mvebu_sw_pci_bridge_init(struct mvebu_pcie_port *port)
> +{
> +       struct mvebu_sw_pci_bridge *bridge = &port->bridge;
> +
> +       memset(bridge, 0, sizeof(struct mvebu_sw_pci_bridge));
> +
> +       bridge->status = PCI_STATUS_CAP_LIST;
> +       bridge->class = PCI_CLASS_BRIDGE_PCI;
> +       bridge->vendor = PCI_VENDOR_ID_MARVELL;
> +       bridge->device = MARVELL_EMULATED_PCI_PCI_BRIDGE_ID;
> +       bridge->header_type = PCI_HEADER_TYPE_BRIDGE;
> +       bridge->cache_line_size = 0x10;
> +
> +       /* We support 32 bits I/O addressing */
> +       bridge->iobase = PCI_IO_RANGE_TYPE_32;
> +       bridge->iolimit = PCI_IO_RANGE_TYPE_32;
> +}
> +
> +/*
> + * Read the configuration space of the PCI-to-PCI bridge associated to
> + * the given PCIe interface.
> + */
> +static int mvebu_sw_pci_bridge_read(struct mvebu_pcie_port *port,
> +                                 unsigned int where, int size, u32 *value)
> +{
> +       struct mvebu_sw_pci_bridge *bridge = &port->bridge;
> +
> +       switch (where & ~3) {
> +       case PCI_VENDOR_ID:
> +               *value = bridge->device << 16 | bridge->vendor;
> +               break;
> +
> +       case PCI_COMMAND:
> +               *value = bridge->status << 16 | bridge->command;
> +               break;
> +
> +       case PCI_CLASS_REVISION:
> +               *value = bridge->class << 16 | bridge->interface << 8 |
> +                        bridge->revision;
> +               break;
> +
> +       case PCI_CACHE_LINE_SIZE:
> +               *value = bridge->bist << 24 | bridge->header_type << 16 |
> +                        bridge->latency_timer << 8 | bridge->cache_line_size;
> +               break;
> +
> +       case PCI_BASE_ADDRESS_0 ... PCI_BASE_ADDRESS_1:
> +               *value = bridge->bar[((where & ~3) - PCI_BASE_ADDRESS_0) / 4];
> +               break;
> +
> +       case PCI_PRIMARY_BUS:
> +               *value = (bridge->secondary_latency_timer << 24 |
> +                         bridge->subordinate_bus         << 16 |
> +                         bridge->secondary_bus           <<  8 |
> +                         bridge->primary_bus);
> +               break;
> +
> +       case PCI_IO_BASE:
> +               *value = (bridge->secondary_status << 16 |
> +                         bridge->iolimit          <<  8 |
> +                         bridge->iobase);
> +               break;
> +
> +       case PCI_MEMORY_BASE:
> +               *value = (bridge->memlimit << 16 | bridge->membase);
> +               break;
> +
> +       case PCI_PREF_MEMORY_BASE:
> +               *value = (bridge->prefmemlimit << 16 | bridge->prefmembase);
> +               break;
> +
> +       case PCI_PREF_BASE_UPPER32:
> +               *value = bridge->prefbaseupper;
> +               break;
> +
> +       case PCI_PREF_LIMIT_UPPER32:
> +               *value = bridge->preflimitupper;
> +               break;
> +
> +       case PCI_IO_BASE_UPPER16:
> +               *value = (bridge->iolimitupper << 16 | bridge->iobaseupper);
> +               break;
> +
> +       case PCI_ROM_ADDRESS1:
> +               *value = 0;
> +               break;
> +
> +       default:
> +               *value = 0xffffffff;
> +               return PCIBIOS_BAD_REGISTER_NUMBER;
> +       }
> +
> +       if (size == 2)
> +               *value = (*value >> (8 * (where & 3))) & 0xffff;
> +       else if (size == 1)
> +               *value = (*value >> (8 * (where & 3))) & 0xff;
> +
> +       return PCIBIOS_SUCCESSFUL;
> +}
> +
> +/* Write to the PCI-to-PCI bridge configuration space */
> +static int mvebu_sw_pci_bridge_write(struct mvebu_pcie_port *port,
> +                                    unsigned int where, int size, u32 value)
> +{
> +       struct mvebu_sw_pci_bridge *bridge = &port->bridge;
> +       u32 mask, reg;
> +       int err;
> +
> +       if (size == 4)
> +               mask = 0x0;
> +       else if (size == 2)
> +               mask = ~(0xffff << ((where & 3) * 8));
> +       else if (size == 1)
> +               mask = ~(0xff << ((where & 3) * 8));
> +       else
> +               return PCIBIOS_BAD_REGISTER_NUMBER;
> +
> +       err = mvebu_sw_pci_bridge_read(port, where & ~3, 4, &reg);
> +       if (err)
> +               return err;
> +
> +       value = (reg & mask) | value << ((where & 3) * 8);
> +
> +       switch (where & ~3) {
> +       case PCI_COMMAND:
> +               bridge->command = value & 0xffff;
> +               bridge->status = value >> 16;
> +               break;
> +
> +       case PCI_BASE_ADDRESS_0 ... PCI_BASE_ADDRESS_1:
> +               bridge->bar[((where & ~3) - PCI_BASE_ADDRESS_0) / 4] = value;
> +               break;
> +
> +       case PCI_IO_BASE:
> +               /*
> +                * We also keep bit 1 set, it is a read-only bit that
> +                * indicates we support 32 bits addressing for the
> +                * I/O
> +                */
> +               bridge->iobase = (value & 0xff) | PCI_IO_RANGE_TYPE_32;
> +               bridge->iolimit = ((value >> 8) & 0xff) | PCI_IO_RANGE_TYPE_32;
> +               bridge->secondary_status = value >> 16;
> +               mvebu_pcie_handle_iobase_change(port);
> +               break;
> +
> +       case PCI_MEMORY_BASE:
> +               bridge->membase = value & 0xffff;
> +               bridge->memlimit = value >> 16;
> +               mvebu_pcie_handle_membase_change(port);
> +               break;
> +
> +       case PCI_PREF_MEMORY_BASE:
> +               bridge->prefmembase = value & 0xffff;
> +               bridge->prefmemlimit = value >> 16;
> +               break;
> +
> +       case PCI_PREF_BASE_UPPER32:
> +               bridge->prefbaseupper = value;
> +               break;
> +
> +       case PCI_PREF_LIMIT_UPPER32:
> +               bridge->preflimitupper = value;
> +               break;
> +
> +       case PCI_IO_BASE_UPPER16:
> +               bridge->iobaseupper = value & 0xffff;
> +               bridge->iolimitupper = value >> 16;
> +               mvebu_pcie_handle_iobase_change(port);
> +               break;
> +
> +       case PCI_PRIMARY_BUS:
> +               bridge->primary_bus             = value & 0xff;
> +               bridge->secondary_bus           = (value >> 8) & 0xff;
> +               bridge->subordinate_bus         = (value >> 16) & 0xff;
> +               bridge->secondary_latency_timer = (value >> 24) & 0xff;
> +               mvebu_pcie_set_local_bus_nr(port->base, bridge->secondary_bus);
> +               break;
> +
> +       default:
> +               break;
> +       }
> +
> +       return PCIBIOS_SUCCESSFUL;
> +}
> +
> +static inline struct mvebu_pcie *sys_to_pcie(struct pci_sys_data *sys)
> +{
> +       return sys->private_data;
> +}
> +
> +/* Find the PCIe interface that corresponds to the given bus */
> +static struct mvebu_pcie_port *mvebu_find_port_from_bus(struct mvebu_pcie *pcie,
> +                                                       int bus)
> +{
> +       int porti;
> +
> +       for (porti = 0; porti < pcie->nports; porti++)
> +               if (pcie->ports[porti].bridge.secondary_bus == bus)
> +                       return &pcie->ports[porti];
> +
> +       return NULL;
> +}
> +
> +/* Find the PCIe interface that corresponds to the given devfn */
> +static struct mvebu_pcie_port *
> +mvebu_find_port_from_devfn(struct mvebu_pcie *pcie, int devfn)
> +{
> +       int porti;
> +
> +       for (porti = 0; porti < pcie->nports; porti++)
> +               if (pcie->ports[porti].devfn == devfn)
> +                       return &pcie->ports[porti];
> +
> +       return NULL;
> +}
> +
> +/* PCI configuration space write function */
> +static int mvebu_pcie_wr_conf(struct pci_bus *bus, u32 devfn,
> +                             int where, int size, u32 val)
> +{
> +       struct mvebu_pcie *pcie = sys_to_pcie(bus->sysdata);
> +
> +       if (bus->number != 0) {
> +               /*
> +                * Accessing a real PCIe interface.
> +                */
> +               struct mvebu_pcie_port *port;
> +               unsigned long flags;
> +               int ret;
> +
> +               port = mvebu_find_port_from_bus(pcie, bus->number);
> +               if (!port)
> +                       return PCIBIOS_DEVICE_NOT_FOUND;
> +
> +               if (!port->haslink)
> +                       return PCIBIOS_DEVICE_NOT_FOUND;
> +
> +               if (PCI_SLOT(devfn) != 0)
> +                       return PCIBIOS_DEVICE_NOT_FOUND;
> +
> +               spin_lock_irqsave(&port->conf_lock, flags);
> +               ret = mvebu_pcie_hw_wr_conf(port->base, bus,
> +                                           PCI_DEVFN(1, PCI_FUNC(devfn)),
> +                                           where, size, val);
> +               spin_unlock_irqrestore(&port->conf_lock, flags);
> +
> +               return ret;
> +       } else {
> +               /*
> +                * Access the emulated PCI-to-PCI bridges.
> +                */
> +               struct mvebu_pcie_port *port;
> +               port = mvebu_find_port_from_devfn(pcie, devfn);
> +               if (!port)
> +                       return PCIBIOS_DEVICE_NOT_FOUND;
> +
> +               return mvebu_sw_pci_bridge_write(port, where, size, val);
> +       }
> +
> +       return PCIBIOS_SUCCESSFUL;

This last "return" is unreachable (I see you omitted it from the
rd_conf() path already :)).  This would be slightly simpler as:

  static struct mvebu_pcie_port *mvebu_find_port(struct mvebu_pcie *pcie,
      struct pci_bus *bus, int devfn)
  {
    int i;

    for (i = 0; i < pcie->nports; i++) {
      if ((bus->number == 0 && pcie->ports[i].devfn == devfn) ||
          (pcie->ports[porti].bridge.secondary_bus == bus->number))
        return &pcie->ports[i];
    }
    return NULL;
  }

  static int mvebu_pcie_wr_conf(struct pci_bus *bus, ...)
  {
    port = mvebu_find_port(pcie, bus, devfn);
    if (!port)
      return PCIBIOS_DEVICE_NOT_FOUND;

    if (bus->number == 0)
      return mvebu_sw_pci_bridge_write(port, where, size, val);

    if (!port->haslink || PCI_SLOT(devfn) != 0)
      return PCIBIOS_DEVICE_NOT_FOUND;

    ...
    return ret;
  }


> +}
> +
> +/* PCI configuration space read function */
> +static int mvebu_pcie_rd_conf(struct pci_bus *bus, u32 devfn, int where,
> +                             int size, u32 *val)
> +{
> +       struct mvebu_pcie *pcie = sys_to_pcie(bus->sysdata);
> +
> +       if (bus->number != 0) {
> +               /*
> +                * Accessing a real PCIe interface.
> +                */
> +               struct mvebu_pcie_port *port;
> +               unsigned long flags;
> +               int ret;
> +
> +               port = mvebu_find_port_from_bus(pcie, bus->number);
> +               if (!port) {
> +                       *val = 0xffffffff;
> +                       return PCIBIOS_DEVICE_NOT_FOUND;
> +               }
> +
> +               if (!port->haslink || PCI_SLOT(devfn) != 0) {
> +                       *val = 0xffffffff;
> +                       return PCIBIOS_DEVICE_NOT_FOUND;
> +               }
> +
> +               spin_lock_irqsave(&port->conf_lock, flags);
> +               ret = mvebu_pcie_hw_rd_conf(port->base, bus,
> +                                           PCI_DEVFN(1, PCI_FUNC(devfn)),
> +                                           where, size, val);
> +               spin_unlock_irqrestore(&port->conf_lock, flags);
> +
> +               return ret;
> +       } else {
> +               /*
> +                * Access the emulated PCI-to-PCI bridges.
> +                */
> +               struct mvebu_pcie_port *port;
> +               port = mvebu_find_port_from_devfn(pcie, devfn);
> +               if (!port) {
> +                       *val = 0xffffffff;
> +                       return PCIBIOS_DEVICE_NOT_FOUND;
> +               }
> +
> +               return mvebu_sw_pci_bridge_read(port, where, size, val);
> +       }
> +}
> +
> +static struct pci_ops mvebu_pcie_ops = {
> +       .read = mvebu_pcie_rd_conf,
> +       .write = mvebu_pcie_wr_conf,
> +};
> +
> +static int __init mvebu_pcie_setup(int nr, struct pci_sys_data *sys)
> +{
> +       struct mvebu_pcie *pcie = sys_to_pcie(sys);
> +       int i;
> +
> +       pci_add_resource_offset(&sys->resources, &pcie->realio, sys->io_offset);
> +       pci_add_resource_offset(&sys->resources, &pcie->mem, sys->mem_offset);
> +       pci_add_resource(&sys->resources, &pcie->busn);
> +
> +       for (i = 0; i < pcie->nports; i++) {
> +               struct mvebu_pcie_port *port = &pcie->ports[i];
> +               mvebu_pcie_setup_hw(port->base);
> +       }
> +
> +       return 1;
> +}
> +
> +static int __init mvebu_pcie_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
> +{
> +       struct of_irq oirq;
> +       int ret;
> +
> +       ret = of_irq_map_pci(dev, &oirq);
> +       if (ret)
> +               return ret;
> +
> +       return irq_create_of_mapping(oirq.controller, oirq.specifier,
> +                                    oirq.size);
> +}
> +
> +static struct pci_bus *mvebu_pcie_scan_bus(int nr, struct pci_sys_data *sys)
> +{
> +       struct mvebu_pcie *pcie = sys_to_pcie(sys);
> +       struct pci_bus *bus;
> +
> +       bus = pci_create_root_bus(&pcie->pdev->dev, sys->busnr,
> +                                 &mvebu_pcie_ops, sys, &sys->resources);
> +       if (!bus)
> +               return NULL;
> +
> +       pci_scan_child_bus(bus);
> +
> +       return bus;
> +}
> +
> +resource_size_t mvebu_pcie_align_resource(struct pci_dev *dev,
> +                                         const struct resource *res,
> +                                         resource_size_t start,
> +                                         resource_size_t size,
> +                                         resource_size_t align)
> +{
> +       if (dev->bus->number != 0)
> +               return start;
> +
> +       /*
> +        * On the PCI-to-PCI bridge side, the I/O windows must have at
> +        * least a 64 KB size and be aligned on their size, and the
> +        * memory windows must have at least a 1 MB size and be
> +        * aligned on their size
> +        */
> +       if (res->flags & IORESOURCE_IO)
> +               return round_up(start, max((resource_size_t)SZ_64K, size));
> +       else if (res->flags & IORESOURCE_MEM)
> +               return round_up(start, max((resource_size_t)SZ_1M, size));
> +       else
> +               return start;
> +}
> +
> +static void mvebu_pcie_enable(struct mvebu_pcie *pcie)
> +{
> +       struct hw_pci hw;
> +
> +       memset(&hw, 0, sizeof(hw));
> +
> +       hw.nr_controllers = 1;
> +       hw.private_data   = (void **)&pcie;
> +       hw.setup          = mvebu_pcie_setup;
> +       hw.scan           = mvebu_pcie_scan_bus;
> +       hw.map_irq        = mvebu_pcie_map_irq;
> +       hw.ops            = &mvebu_pcie_ops;
> +       hw.align_resource = mvebu_pcie_align_resource;
> +
> +       pci_common_init(&hw);
> +}
> +
> +/*
> + * Looks up the list of register addresses encoded into the reg =
> + * <...> property for one that matches the given port/lane. Once
> + * found, maps it.
> + */
> +static void __iomem *mvebu_pcie_map_registers(struct platform_device *pdev,
> +                                             struct device_node *np,
> +                                             struct mvebu_pcie_port *port)
> +{
> +       struct resource regs;
> +       int ret = 0;
> +
> +       ret = of_address_to_resource(np, 0, &regs);
> +       if (ret)
> +               return NULL;
> +
> +       return devm_request_and_ioremap(&pdev->dev, &regs);
> +}
> +
> +static int __init mvebu_pcie_probe(struct platform_device *pdev)
> +{
> +       struct mvebu_pcie *pcie;
> +       struct device_node *np = pdev->dev.of_node;
> +       struct of_pci_range range;
> +       struct of_pci_range_parser parser;
> +       struct device_node *child;
> +       int i, ret;
> +
> +       pcie = devm_kzalloc(&pdev->dev, sizeof(struct mvebu_pcie),
> +                           GFP_KERNEL);
> +       if (!pcie)
> +               return -ENOMEM;
> +
> +       pcie->pdev = pdev;
> +
> +       if (of_pci_range_parser(&parser, np))
> +               return -EINVAL;
> +
> +       /* Get the I/O and memory ranges from DT */
> +       for_each_of_pci_range(&parser, &range) {
> +               unsigned long restype = range.flags & IORESOURCE_TYPE_BITS;
> +               if (restype == IORESOURCE_IO) {
> +                       of_pci_range_to_resource(&range, np, &pcie->io);
> +                       of_pci_range_to_resource(&range, np, &pcie->realio);
> +                       pcie->io.name = "I/O";
> +                       pcie->realio.start = PCIBIOS_MIN_IO;
> +                       pcie->realio.end = min(resource_size(&pcie->io),
> +                                              IO_SPACE_LIMIT);

Using "resource_size(&pcie->io)" here seems strange -- are you
assuming that pcie->io starts at address zero?

> +               }
> +               if (restype == IORESOURCE_MEM) {
> +                       of_pci_range_to_resource(&range, np, &pcie->mem);
> +                       pcie->mem.name = "MEM";
> +               }
> +       }
> +
> +       /* Get the bus range */
> +       ret = of_pci_parse_bus_range(np, &pcie->busn);
> +       if (ret) {
> +               dev_err(&pdev->dev, "failed to parse bus-range property: %d\n",
> +                       ret);
> +               return ret;
> +       }
> +
> +       for_each_child_of_node(pdev->dev.of_node, child) {
> +               if (!of_device_is_available(child))
> +                       continue;
> +               pcie->nports++;
> +       }
> +
> +       pcie->ports = devm_kzalloc(&pdev->dev, pcie->nports *
> +                                  sizeof(struct mvebu_pcie_port),
> +                                  GFP_KERNEL);
> +       if (!pcie->ports)
> +               return -ENOMEM;
> +
> +       i = 0;
> +       for_each_child_of_node(pdev->dev.of_node, child) {
> +               struct mvebu_pcie_port *port = &pcie->ports[i];
> +
> +               if (!of_device_is_available(child))
> +                       continue;
> +
> +               port->pcie = pcie;
> +
> +               if (of_property_read_u32(child, "marvell,pcie-port",
> +                                        &port->port)) {
> +                       dev_warn(&pdev->dev,
> +                                "ignoring PCIe DT node, missing pcie-port property\n");
> +                       continue;
> +               }
> +
> +               if (of_property_read_u32(child, "marvell,pcie-lane",
> +                                        &port->lane))
> +                       port->lane = 0;
> +
> +               port->name = kasprintf(GFP_KERNEL, "pcie%d.%d",
> +                                      port->port, port->lane);
> +
> +               port->devfn = of_pci_get_devfn(child);
> +               if (port->devfn < 0)
> +                       continue;
> +
> +               port->base = mvebu_pcie_map_registers(pdev, child, port);
> +               if (!port->base) {
> +                       dev_err(&pdev->dev, "PCIe%d.%d: cannot map registers\n",
> +                               port->port, port->lane);
> +                       continue;
> +               }
> +
> +               if (mvebu_pcie_link_up(port->base)) {
> +                       port->haslink = 1;
> +                       dev_info(&pdev->dev, "PCIe%d.%d: link up\n",
> +                                port->port, port->lane);
> +               } else {
> +                       port->haslink = 0;
> +                       dev_info(&pdev->dev, "PCIe%d.%d: link down\n",
> +                                port->port, port->lane);
> +               }
> +
> +               port->clk = of_clk_get_by_name(child, NULL);
> +               if (!port->clk) {
> +                       dev_err(&pdev->dev, "PCIe%d.%d: cannot get clock\n",
> +                              port->port, port->lane);
> +                       iounmap(port->base);
> +                       port->haslink = 0;
> +                       continue;
> +               }
> +
> +               port->dn = child;
> +
> +               clk_prepare_enable(port->clk);
> +               spin_lock_init(&port->conf_lock);
> +
> +               mvebu_sw_pci_bridge_init(port);
> +
> +               i++;
> +       }
> +
> +       mvebu_pcie_enable(pcie);
> +
> +       return 0;
> +}
> +
> +static const struct of_device_id mvebu_pcie_of_match_table[] = {
> +       { .compatible = "marvell,armada-xp-pcie", },
> +       { .compatible = "marvell,armada-370-pcie", },
> +       {},
> +};
> +MODULE_DEVICE_TABLE(of, mvebu_pcie_of_match_table);
> +
> +static struct platform_driver mvebu_pcie_driver = {
> +       .driver = {
> +               .owner = THIS_MODULE,
> +               .name = "mvebu-pcie",
> +               .of_match_table =
> +                  of_match_ptr(mvebu_pcie_of_match_table),
> +       },
> +};
> +
> +static int mvebu_pcie_init(void)
> +{
> +       return platform_driver_probe(&mvebu_pcie_driver,
> +                                    mvebu_pcie_probe);
> +}
> +
> +subsys_initcall(mvebu_pcie_init);
> +
> +MODULE_AUTHOR("Thomas Petazzoni <thomas.petazzoni at free-electrons.com>");
> +MODULE_DESCRIPTION("Marvell EBU PCIe driver");
> +MODULE_LICENSE("GPLv2");
> --
> 1.7.9.5
>


From bhelgaas at google.com  Mon Apr  8 16:32:09 2013
From: bhelgaas at google.com (Bjorn Helgaas)
Date: Mon, 8 Apr 2013 14:32:09 -0600
Subject: [PATCHv7 04/17] pci: infrastructure to add drivers in
 drivers/pci/host
In-Reply-To: <20130328082436.317d698a@skate>
References: <1364395234-11195-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1364395234-11195-5-git-send-email-thomas.petazzoni@free-electrons.com>
 <CAAfodu2t4j4ZASzdaKV0QarffXRwMgkMESGy=dDq1oMfTANEeg@mail.gmail.com>
 <20130328082436.317d698a@skate>
Message-ID: <CAErSpo61=gqnNkUYhsu88UUBRQN0SBynG07mby1f3HJUm=oZKA@mail.gmail.com>

On Thu, Mar 28, 2013 at 1:24 AM, Thomas Petazzoni
<thomas.petazzoni at free-electrons.com> wrote:
> Dear Neil Greatorex,
>
> On Thu, 28 Mar 2013 00:28:02 +0000, Neil Greatorex wrote:
>
>> Surely this patch should include the drivers/pci/host/Makefile or it will
>> not build?
>
> Ah, correct. I'll fix that up in the v8. Thank you for noticing!

With the fix, looks OK to me.

Bjorn


From rjw at sisk.pl  Mon Apr  8 16:50:21 2013
From: rjw at sisk.pl (Rafael J. Wysocki)
Date: Mon, 08 Apr 2013 22:50:21 +0200
Subject: [PATCH 1/9] ARM: cpuidle: remove useless declaration
In-Reply-To: <515C1F3B.5040008@linaro.org>
References: <1364991322-20585-1-git-send-email-daniel.lezcano@linaro.org>
 <515C1F3B.5040008@linaro.org>
Message-ID: <3144551.suxBcA9vOB@vostro.rjw.lan>

On Wednesday, April 03, 2013 02:23:23 PM Daniel Lezcano wrote:
> On 04/03/2013 02:15 PM, Daniel Lezcano wrote:
> > The noop functions code is not necessary because the header file is
> > included in files which are compiled when CONFIG_CPU_IDLE is on.
> >
> > Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
> 
> I have been involved in the development of this file. I know Rob is no
> longer working on this neither monitoring the code.
> 
> Russell are you ok with this patch ? Rafael needs your ack to take this
> patch into its tree.

Well, since nothing in the cpuidle directory seems to really depend on this
patch, my suggestion is to merge it through the ARM tree when suitable.

Thanks,
Rafael


> > ---
> >  arch/arm/include/asm/cpuidle.h |    7 +------
> >  1 file changed, 1 insertion(+), 6 deletions(-)
> >
> > diff --git a/arch/arm/include/asm/cpuidle.h b/arch/arm/include/asm/cpuidle.h
> > index 2fca60a..7367787 100644
> > --- a/arch/arm/include/asm/cpuidle.h
> > +++ b/arch/arm/include/asm/cpuidle.h
> > @@ -1,13 +1,8 @@
> >  #ifndef __ASM_ARM_CPUIDLE_H
> >  #define __ASM_ARM_CPUIDLE_H
> >  
> > -#ifdef CONFIG_CPU_IDLE
> >  extern int arm_cpuidle_simple_enter(struct cpuidle_device *dev,
> > -		struct cpuidle_driver *drv, int index);
> > -#else
> > -static inline int arm_cpuidle_simple_enter(struct cpuidle_device *dev,
> > -		struct cpuidle_driver *drv, int index) { return -ENODEV; }
> > -#endif
> > +				    struct cpuidle_driver *drv, int index);
> >  
> >  /* Common ARM WFI state */
> >  #define ARM_CPUIDLE_WFI_STATE_PWR(p) {\
> 
> 
> 
-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.


From maxime.ripard at free-electrons.com  Mon Apr  8 16:47:09 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Mon, 08 Apr 2013 22:47:09 +0200
Subject: [PATCH] pinctrl: sunxi: Rename wemac functions to emac
In-Reply-To: <1364389953-20688-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1364389953-20688-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <51632CCD.6080900@free-electrons.com>

Hi Linus,

Le 27/03/2013 14:12, Maxime Ripard a ?crit :
> The pin functions associated to the ethernet controller were introduced
> with the label "wemac", which was the name of the ethernet driver in the
> allwinner source tree, while the real name of the IP is actually "emac",
> as advertised in several documents including the datasheet.
> 
> Since this is part of the device tree bindings, and that these part of
> the bindings have not yet be released in a kernel version, it seems like
> the good timing to change it and assure consistency.

This patch depends on patches you applied earlier, could you merge it if
you agree with it?

Thanks,
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


From daniel.lezcano at linaro.org  Mon Apr  8 16:53:54 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Mon, 08 Apr 2013 22:53:54 +0200
Subject: [PATCH 1/9] ARM: cpuidle: remove useless declaration
In-Reply-To: <3144551.suxBcA9vOB@vostro.rjw.lan>
References: <1364991322-20585-1-git-send-email-daniel.lezcano@linaro.org>
 <515C1F3B.5040008@linaro.org> <3144551.suxBcA9vOB@vostro.rjw.lan>
Message-ID: <51632E62.2060300@linaro.org>

On 04/08/2013 10:50 PM, Rafael J. Wysocki wrote:
> On Wednesday, April 03, 2013 02:23:23 PM Daniel Lezcano wrote:
>> On 04/03/2013 02:15 PM, Daniel Lezcano wrote:
>>> The noop functions code is not necessary because the header file is
>>> included in files which are compiled when CONFIG_CPU_IDLE is on.
>>>
>>> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
>>
>> I have been involved in the development of this file. I know Rob is no
>> longer working on this neither monitoring the code.
>>
>> Russell are you ok with this patch ? Rafael needs your ack to take this
>> patch into its tree.
> 
> Well, since nothing in the cpuidle directory seems to really depend on this
> patch, my suggestion is to merge it through the ARM tree when suitable.

Ok.


>>> ---
>>>  arch/arm/include/asm/cpuidle.h |    7 +------
>>>  1 file changed, 1 insertion(+), 6 deletions(-)
>>>
>>> diff --git a/arch/arm/include/asm/cpuidle.h b/arch/arm/include/asm/cpuidle.h
>>> index 2fca60a..7367787 100644
>>> --- a/arch/arm/include/asm/cpuidle.h
>>> +++ b/arch/arm/include/asm/cpuidle.h
>>> @@ -1,13 +1,8 @@
>>>  #ifndef __ASM_ARM_CPUIDLE_H
>>>  #define __ASM_ARM_CPUIDLE_H
>>>  
>>> -#ifdef CONFIG_CPU_IDLE
>>>  extern int arm_cpuidle_simple_enter(struct cpuidle_device *dev,
>>> -		struct cpuidle_driver *drv, int index);
>>> -#else
>>> -static inline int arm_cpuidle_simple_enter(struct cpuidle_device *dev,
>>> -		struct cpuidle_driver *drv, int index) { return -ENODEV; }
>>> -#endif
>>> +				    struct cpuidle_driver *drv, int index);
>>>  
>>>  /* Common ARM WFI state */
>>>  #define ARM_CPUIDLE_WFI_STATE_PWR(p) {\
>>
>>
>>


-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From akpm at linux-foundation.org  Mon Apr  8 16:55:53 2013
From: akpm at linux-foundation.org (Andrew Morton)
Date: Mon, 8 Apr 2013 13:55:53 -0700
Subject: [PATCH 0/2] mm: vmemmap: add vmemmap_verify check for hot-add
 node/memory case
In-Reply-To: <CAE9FiQVaByGOTjLVthRkEze_ekXm5LAKgKdHzrD+q1iYmjgZFQ@mail.gmail.com>
References: <1365415000-10389-1-git-send-email-linfeng@cn.fujitsu.com>
 <CAE9FiQVaByGOTjLVthRkEze_ekXm5LAKgKdHzrD+q1iYmjgZFQ@mail.gmail.com>
Message-ID: <20130408135553.2f60518d923b6920bdf1931f@linux-foundation.org>

On Mon, 8 Apr 2013 11:40:11 -0700 Yinghai Lu <yinghai at kernel.org> wrote:

> On Mon, Apr 8, 2013 at 2:56 AM, Lin Feng <linfeng at cn.fujitsu.com> wrote:
> > In hot add node(memory) case, vmemmap pages are always allocated from other
> > node,
> 
> that is broken, and should be fixed.
> vmemmap should be on local node even for hot add node.
> 

That would be nice.

I don't see much value in the added warnings, really.  Because there's
nothing the user can *do* about them, apart from a) stop using NUMA, b)
stop using memory hotplug, c) become a kernel MM developer or d) switch
to Windows.



From tony at atomide.com  Mon Apr  8 16:56:33 2013
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 8 Apr 2013 13:56:33 -0700
Subject: [PATCH RESEND 1/1] omap4: control: Add the
 CONTROL_SMART2IO_PADCONF_2 register definition
In-Reply-To: <1363219908-32007-2-git-send-email-ruslan.bilovol@ti.com>
References: <1363219908-32007-1-git-send-email-ruslan.bilovol@ti.com>
 <1363219908-32007-2-git-send-email-ruslan.bilovol@ti.com>
Message-ID: <20130408205633.GV10155@atomide.com>

* Ruslan Bilovol <ruslan.bilovol at ti.com> [130313 17:16]:
> This patch adds missing CONTROL_SMART2IO_PADCONF_2 register
> definition

Sorry for the delay on this one. After looking at these registers,
there's no need to define them here.

These all relate to pinconf, and these all can now be handled by
generic pinconf using pinctrl-single.c. There's generic pinconf
support added to pinctrl-single.c in linux next by Haojian Zhuang.

This means that you can just define these in the .dts file for
the board, and you can select the board specific values for things
like output buffer.

In Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
you should see what all is already supported, and if it's not,
we can patch it in. That's in current linux next queued for
v3.10.

Regards,

Tony
 
> Signed-off-by: Ruslan Bilovol <ruslan.bilovol at ti.com>
> ---
>  arch/arm/mach-omap2/ctrl_module_pad_core_44xx.h |   45 +++++++++++++++++++++++
>  1 file changed, 45 insertions(+)
> 
> diff --git a/arch/arm/mach-omap2/ctrl_module_pad_core_44xx.h b/arch/arm/mach-omap2/ctrl_module_pad_core_44xx.h
> index c88420d..d512ade 100644
> --- a/arch/arm/mach-omap2/ctrl_module_pad_core_44xx.h
> +++ b/arch/arm/mach-omap2/ctrl_module_pad_core_44xx.h
> @@ -46,6 +46,7 @@
>  #define OMAP4_CTRL_MODULE_PAD_CORE_CONTROL_SMART3IO_PADCONF_2	0x05c0
>  #define OMAP4_CTRL_MODULE_PAD_CORE_CONTROL_USBB_HSIC		0x05c4
>  #define OMAP4_CTRL_MODULE_PAD_CORE_CONTROL_SLIMBUS		0x05c8
> +#define OMAP4_CTRL_MODULE_PAD_CORE_CONTROL_SMART2IO_PADCONF_2	0x05cc
>  #define OMAP4_CTRL_MODULE_PAD_CORE_CONTROL_PBIASLITE		0x0600
>  #define OMAP4_CTRL_MODULE_PAD_CORE_CONTROL_I2C_0		0x0604
>  #define OMAP4_CTRL_MODULE_PAD_CORE_CONTROL_CAMERA_RX		0x0608
> @@ -764,6 +765,50 @@
>  #define OMAP4_HSI_DR0_LB_SHIFT					10
>  #define OMAP4_HSI_DR0_LB_MASK					(1 << 10)
>  
> +/* CONTROL_SMART2IO_PADCONF_2 */
> +#define OMAP4_DPM_DR1_DS_SHIFT					31
> +#define OMAP4_DPM_DR1_DS_MASK					(1 << 31)
> +#define OMAP4_DPM_DR2_DS_SHIFT					30
> +#define OMAP4_DPM_DR2_DS_MASK					(1 << 30)
> +#define OMAP4_DPM_DR3_DS_SHIFT					29
> +#define OMAP4_DPM_DR3_DS_MASK					(1 << 29)
> +#define OMAP4_GPIO_DR10_DS_SHIFT				28
> +#define OMAP4_GPIO_DR10_DS_MASK					(1 << 28)
> +#define OMAP4_HSI2_DR0_DS_SHIFT					27
> +#define OMAP4_HSI2_DR0_DS_MASK					(1 << 27)
> +#define OMAP4_HSI2_DR1_DS_SHIFT					26
> +#define OMAP4_HSI2_DR1_DS_MASK					(1 << 26)
> +#define OMAP4_HSI2_DR2_DS_SHIFT					25
> +#define OMAP4_HSI2_DR2_DS_MASK					(1 << 25)
> +#define OMAP4_SDMMC3_DR0_DS_SHIFT				24
> +#define OMAP4_SDMMC3_DR0_DS_MASK				(1 << 24)
> +#define OMAP4_SDMMC4_DR0_DS_SHIFT				23
> +#define OMAP4_SDMMC4_DR0_DS_MASK				(1 << 23)
> +#define OMAP4_SDMMC4_DR1_DS_SHIFT				22
> +#define OMAP4_SDMMC4_DR1_DS_MASK				(1 << 22)
> +#define OMAP4_SPI3_DR0_DS_SHIFT					21
> +#define OMAP4_SPI3_DR0_DS_MASK					(1 << 21)
> +#define OMAP4_SPI3_DR1_DS_SHIFT					20
> +#define OMAP4_SPI3_DR1_DS_MASK					(1 << 20)
> +#define OMAP4_UART3_DR2_DS_SHIFT				19
> +#define OMAP4_UART3_DR2_DS_MASK					(1 << 19)
> +#define OMAP4_UART3_DR3_DS_SHIFT				18
> +#define OMAP4_UART3_DR3_DS_MASK					(1 << 18)
> +#define OMAP4_UART3_DR4_DS_SHIFT				17
> +#define OMAP4_UART3_DR4_DS_MASK					(1 << 17)
> +#define OMAP4_UART3_DR5_DS_SHIFT				16
> +#define OMAP4_UART3_DR5_DS_MASK					(1 << 16)
> +#define OMAP4_USBA0_DR0_DS_SHIFT				15
> +#define OMAP4_USBA0_DR0_DS_MASK					(1 << 15)
> +#define OMAP4_USBA0_DR1_DS_SHIFT				14
> +#define OMAP4_USBA0_DR1_DS_MASK					(1 << 14)
> +#define OMAP4_USBA_DR2_DS_SHIFT					13
> +#define OMAP4_USBA_DR2_DS_MASK					(1 << 13)
> +#define OMAP4_USBB2_DR0_DS_SHIFT				12
> +#define OMAP4_USBB2_DR0_DS_MASK					(1 << 12)
> +#define OMAP4_USBB1_DR0_DS_SHIFT				11
> +#define OMAP4_USBB1_DR0_DS_MASK					(1 << 11)
> +
>  /* CONTROL_USBB_HSIC */
>  #define OMAP4_USBB2_DR1_SR_SHIFT				30
>  #define OMAP4_USBB2_DR1_SR_MASK					(0x3 << 30)
> -- 
> 1.7.9.5
> 


From thomas.petazzoni at free-electrons.com  Mon Apr  8 16:57:41 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Mon, 8 Apr 2013 22:57:41 +0200
Subject: [PATCHv7 08/17] pci: PCIe driver for Marvell Armada 370/XP systems
In-Reply-To: <CAErSpo7fGPe3wFha36kNMxeRP4gBpBWgfw85aTLey-DSz2ZYew@mail.gmail.com>
References: <1364395234-11195-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1364395234-11195-9-git-send-email-thomas.petazzoni@free-electrons.com>
 <CAErSpo7fGPe3wFha36kNMxeRP4gBpBWgfw85aTLey-DSz2ZYew@mail.gmail.com>
Message-ID: <20130408225741.74fc383c@skate>

Dear Bjorn Helgaas,

On Mon, 8 Apr 2013 14:29:59 -0600, Bjorn Helgaas wrote:

> > Signed-off-by: Thomas Petazzoni
> > <thomas.petazzoni at free-electrons.com>
> 
> Acked-by: Bjorn Helgaas <bhelgaas at google.com>
> 
> A few trivial comments below; it's up to you whether you do anything
> with them or not.  It's OK with me if you ignore them :)
> 
> The only thing I saw that might be a bug is the resource_size()
> question in mvebu_pcie_probe().

Thanks for the review!

> > diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
> > new file mode 100644
> > index 0000000..3ad563f
> > --- /dev/null
> > +++ b/drivers/pci/host/Makefile
> > @@ -0,0 +1,4 @@
> > +obj-$(CONFIG_PCI_MVEBU) += pci-mvebu.o
> > +CFLAGS_pci-mvebu.o += \
> > +       -I$(srctree)/arch/arm/plat-orion/include \
> > +       -I$(srctree)/arch/arm/mach-mvebu/include
> 
> Too bad to have to adjust CFLAGS here.  Seems like I remember earlier
> discussion, but I didn't pay much attention, and if this is the best
> we can do, I guess it's OK.

Ah, indeed! This is now longer needed. The plat-orion include was
needed to get access to some PCIe functions, which are now part of the
driver, and the mach-mvebu header was needed to access some address
decoding window related functions, that are now part of the mvebu-mbus
driver.

> > +#define PCIE_BAR_CTRL_OFF(n)   (0x1804 + ((n - 1) * 4))
> 
> Strictly speaking, I suppose you should have "(((n) - 1) ..." here.

Correct, thanks.

> > +#define PCIE_STAT_OFF          0x1a04
> > +#define  PCIE_STAT_DEV_OFFS            20
> > +#define  PCIE_STAT_DEV_MASK            0x1f
> > +#define  PCIE_STAT_BUS_OFFS            8
> > +#define  PCIE_STAT_BUS_MASK            0xff
> > +#define  PCIE_STAT_LINK_DOWN           1
> 
> Whoever wrote pci_regs.h came up with a style I kind of like: the bit
> masks are already shifted so you can see where they are in the value,
> and there are no #defines for the shifts, e.g.,
> 
> #define PCI_EXP_FLAGS_TYPE      0x00f0  /* Device/Port type */
> 
> The users of PCI_EXP_FLAGS_TYPE just have a bare ">> 4" where
> necessary.  It seems like a good compromise that uses only one symbol
> (good for grepping), gives good visual indication in the header file
> of how the value is laid out, allows clearing bits without shifts, and
> clearly shows what's happening at the uses.
> 
> But what you have is OK, too :)

Hum, ok, I'll try to think of it. Maybe too much of a 'big' change at
this point, but I'll see.

> > +static int mvebu_pcie_link_up(void __iomem *base)
> 
> This could return bool, I guess.

Indeed.

> I think I would make
> 
>   mvebu_pcie_link_up()
>   mvebu_pcie_set_local_bus_nr()
>   mvebu_pcie_setup_wins()
>   mvebu_pcie_setup_hw()
>   mvebu_pcie_hw_rd_conf()
>   mvebu_pcie_hw_wr_conf()
> 
> all take a "struct mvebu_pcie_port *port" directly rather than having
> the caller pass in "port->base", but maybe you have a reason for doing
> otherwise.

I'll review this, I think your suggestion makes sense.

> > +       /*
> > +        * First, disable and clear BARs and windows.
> > +        */
> 
> Typically single-line comments would be "/* ... */" all on one line.

Correct.

> > +       for (i = 1; i <= 2; i++) {
> 
> Interesting use of "i <= 2" rather than the typical "i < 3".

I must confess this code comes from plat-orion/pcie.c, and I just
copy/pasted it (note: we intentionally don't use plat-orion/pcie.c to
avoid having to have to include a header in plat-orion/include, and
this plat-orion/pcie.c should ultimately go away once all Marvell EBU
platforms are migrated to use the new PCIe driver).

> > +       /*
> > +        * Enable interrupt lines A-D.
> > +        */
> > +       mask = readl(base + PCIE_MASK_OFF);
> > +       mask |= 0x0f000000;
> 
> No #defines for these bits?

Good point.

> > +       writel(mask, base + PCIE_MASK_OFF);
> > +}
> > +
> > +static int mvebu_pcie_hw_rd_conf(void __iomem *base, struct
> > pci_bus *bus,
> > +                                u32 devfn, int where, int size,
> > u32 *val) +{
> > +       writel(PCIE_CONF_BUS(bus->number) |
> > +               PCIE_CONF_DEV(PCI_SLOT(devfn)) |
> > +               PCIE_CONF_FUNC(PCI_FUNC(devfn)) |
> > +               PCIE_CONF_REG(where) | PCIE_CONF_ADDR_EN,
> 
> A "PCIE_CONF_ADDR(busnr, devfn, where)" macro would be nice here.

Right.

> > +static void mvebu_pcie_handle_iobase_change(struct mvebu_pcie_port
> > *port) +{
> > +       phys_addr_t iobase;
> > +
> > +       /* Are the current iobase/iolimit values invalid? */
> 
> I first thought "current ... values" meant "the values before the
> change."  If you used "new values" it might be clearer that this is
> used to handle *writes* to the window base/size registers, and that
> we're looking at the values being written.

Ok, makes sense indeed.

> > +               return mvebu_sw_pci_bridge_write(port, where, size,
> > val);
> > +       }
> > +
> > +       return PCIBIOS_SUCCESSFUL;
> 
> This last "return" is unreachable (I see you omitted it from the
> rd_conf() path already :)).  This would be slightly simpler as:
> 
>   static struct mvebu_pcie_port *mvebu_find_port(struct mvebu_pcie
> *pcie, struct pci_bus *bus, int devfn)
>   {
>     int i;
> 
>     for (i = 0; i < pcie->nports; i++) {
>       if ((bus->number == 0 && pcie->ports[i].devfn == devfn) ||
>           (pcie->ports[porti].bridge.secondary_bus == bus->number))
>         return &pcie->ports[i];
>     }
>     return NULL;
>   }
> 
>   static int mvebu_pcie_wr_conf(struct pci_bus *bus, ...)
>   {
>     port = mvebu_find_port(pcie, bus, devfn);
>     if (!port)
>       return PCIBIOS_DEVICE_NOT_FOUND;
> 
>     if (bus->number == 0)
>       return mvebu_sw_pci_bridge_write(port, where, size, val);
> 
>     if (!port->haslink || PCI_SLOT(devfn) != 0)
>       return PCIBIOS_DEVICE_NOT_FOUND;
> 
>     ...
>     return ret;
>   }

Ok, I'll have a look at this.

> > IORESOURCE_TYPE_BITS;
> > +               if (restype == IORESOURCE_IO) {
> > +                       of_pci_range_to_resource(&range, np,
> > &pcie->io);
> > +                       of_pci_range_to_resource(&range, np,
> > &pcie->realio);
> > +                       pcie->io.name = "I/O";
> > +                       pcie->realio.start = PCIBIOS_MIN_IO;
> > +                       pcie->realio.end =
> > min(resource_size(&pcie->io),
> > +                                              IO_SPACE_LIMIT);
> 
> Using "resource_size(&pcie->io)" here seems strange -- are you
> assuming that pcie->io starts at address zero?

No, I'm assuming PCIBIOS_MIN_IO is always 0. So presumarly, this should
be something like:

	pcie->realio.end = min(PCIBIOS_MIN_IO +
				resource_size(&pcie->io),
				IO_SPACE_LIMIT);


Thanks for all your valuable comments!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From mcgrof at do-not-panic.com  Mon Apr  8 17:04:26 2013
From: mcgrof at do-not-panic.com (Luis R. Rodriguez)
Date: Mon, 8 Apr 2013 14:04:26 -0700
Subject: Central Linux ARM wiki
Message-ID: <CAB=NE6VEmnVGtdU=kbWnDwq0TXSs-UcFgcxCKE1QptZWteBqiA@mail.gmail.com>

Do we have a central place to centrally document ARM development
upstream? I'd like to start using a central place to start documenting
things for some stuff I'd like to work on and I don't want to use any
vendor specific stuff. Are we go happy with using elinux.org ? If so
can we add a reference to that as the place for ARM development from
wiki.kernel.org ?

  Luis


From sergei.shtylyov at cogentembedded.com  Mon Apr  8 17:10:49 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Tue, 9 Apr 2013 01:10:49 +0400
Subject: [PATCH v2 0/9] Reorganize R8A7779/Marzen USB code
Message-ID: <201304090110.50154.sergei.shtylyov@cogentembedded.com>

Hello.

   Here's the set of 9 patches against the Simon Horman's 'renesas.git' repo,
'renesas-next-20130405v2' tag.  It was created to fix the shortcomings in the
R8A7779/Marzen USB platform code and R8A7779 USB common PHY driver, and so
spans both arch/arm/mach-shmobile/ and drivers/usb/ subtrees (some patches have
to touch both subtrees). The patches were conceived with the complete
bisectability goal in mind. The patches have been tested on the Marzen board.

[1/9] ARM: shmobile: Marzen: move USB EHCI, OHCI, and PHY devices to R8A7779 code
[2/9] ehci-platform: add pre_setup() method to platform data
[3/9] ARM: shmobile: R8A7779: setup EHCI internal buffer
[4/9] rcar-phy: remove EHCI internal buffer setup
[5/9] ARM: shmobile: R8A7779: remove USB PHY 2nd memory resource
[6/9] rcar-phy: correct base address
[7/9] rcar-phy: add platform data
[8/9] ARM: shmobile: Marzen: pass platform data to USB PHY device
[9/9] rcar-phy: handle platform data

   I'm not sure thru which tree this patchset should be merged, however it turns
out that it's too late now to push it thru Felipe Balbi's USB tree for 3.10 which
would have been most convenient probably, so maybe the patchset can be merged
thru Simon's tree with Felipe's and Alan Stern's ACKs. Or perhaps it now should
be postponed for 3.11...

WBR, Sergei


From sergei.shtylyov at cogentembedded.com  Mon Apr  8 17:18:51 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Tue, 9 Apr 2013 01:18:51 +0400
Subject: [PATCH v2 1/9] ARM: shmobile: Marzen: move USB EHCI, OHCI,
 and PHY devices to R8A7779 code
Message-ID: <201304090118.52339.sergei.shtylyov@cogentembedded.com>

USB EHCI, OHCI, and common PHY are the SoC devices but are wrongly defined and
registered in the Marzen board file.  Move the data and code to their proper
place in setup-r8a7779.c; while at it, we have to rename 8a7779_late_devices[]
to 8a7779_standard_devices[] -- this seems legitimate since they are registered
from r8a7779_add_standard_devices() anyway.

Note that I'm deliberately changing the USB PHY platform device's 'id' field
from (previously just omitted) 0 to -1 as the device is a single of its kind.

Note also that the board and SoC code have to be in one patch to keep the code
bisectable...

Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

---
Changes since the original posting:
- added a note about bisectability to the changelog.

 arch/arm/mach-shmobile/board-marzen.c         |  178 -------------------------
 arch/arm/mach-shmobile/include/mach/r8a7779.h |    1 
 arch/arm/mach-shmobile/setup-r8a7779.c        |  185 +++++++++++++++++++++++++-
 3 files changed, 184 insertions(+), 180 deletions(-)

Index: renesas/arch/arm/mach-shmobile/board-marzen.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/board-marzen.c
+++ renesas/arch/arm/mach-shmobile/board-marzen.c
@@ -36,10 +36,6 @@
 #include <linux/mmc/host.h>
 #include <linux/mmc/sh_mobile_sdhi.h>
 #include <linux/mfd/tmio.h>
-#include <linux/usb/otg.h>
-#include <linux/usb/ehci_pdriver.h>
-#include <linux/usb/ohci_pdriver.h>
-#include <linux/pm_runtime.h>
 #include <mach/hardware.h>
 #include <mach/r8a7779.h>
 #include <mach/common.h>
@@ -149,26 +145,6 @@ static struct platform_device hspi_devic
 	.num_resources	= ARRAY_SIZE(hspi_resources),
 };
 
-/* USB PHY */
-static struct resource usb_phy_resources[] = {
-	[0] = {
-		.start		= 0xffe70000,
-		.end		= 0xffe70900 - 1,
-		.flags		= IORESOURCE_MEM,
-	},
-	[1] = {
-		.start		= 0xfff70000,
-		.end		= 0xfff70900 - 1,
-		.flags		= IORESOURCE_MEM,
-	},
-};
-
-static struct platform_device usb_phy_device = {
-	.name		= "rcar_usb_phy",
-	.resource	= usb_phy_resources,
-	.num_resources	= ARRAY_SIZE(usb_phy_resources),
-};
-
 /* LEDS */
 static struct gpio_led marzen_leds[] = {
 	{
@@ -204,161 +180,9 @@ static struct platform_device *marzen_de
 	&sdhi0_device,
 	&thermal_device,
 	&hspi_device,
-	&usb_phy_device,
 	&leds_device,
 };
 
-/* USB */
-static struct usb_phy *phy;
-static int usb_power_on(struct platform_device *pdev)
-{
-	if (!phy)
-		return -EIO;
-
-	pm_runtime_enable(&pdev->dev);
-	pm_runtime_get_sync(&pdev->dev);
-
-	usb_phy_init(phy);
-
-	return 0;
-}
-
-static void usb_power_off(struct platform_device *pdev)
-{
-	if (!phy)
-		return;
-
-	usb_phy_shutdown(phy);
-
-	pm_runtime_put_sync(&pdev->dev);
-	pm_runtime_disable(&pdev->dev);
-}
-
-static struct usb_ehci_pdata ehcix_pdata = {
-	.power_on	= usb_power_on,
-	.power_off	= usb_power_off,
-	.power_suspend	= usb_power_off,
-};
-
-static struct resource ehci0_resources[] = {
-	[0] = {
-		.start	= 0xffe70000,
-		.end	= 0xffe70400 - 1,
-		.flags	= IORESOURCE_MEM,
-	},
-	[1] = {
-		.start	= gic_iid(0x4c),
-		.flags	= IORESOURCE_IRQ,
-	},
-};
-
-static struct platform_device ehci0_device = {
-	.name	= "ehci-platform",
-	.id	= 0,
-	.dev	= {
-		.dma_mask		= &ehci0_device.dev.coherent_dma_mask,
-		.coherent_dma_mask	= 0xffffffff,
-		.platform_data		= &ehcix_pdata,
-	},
-	.num_resources	= ARRAY_SIZE(ehci0_resources),
-	.resource	= ehci0_resources,
-};
-
-static struct resource ehci1_resources[] = {
-	[0] = {
-		.start	= 0xfff70000,
-		.end	= 0xfff70400 - 1,
-		.flags	= IORESOURCE_MEM,
-	},
-	[1] = {
-		.start	= gic_iid(0x4d),
-		.flags	= IORESOURCE_IRQ,
-	},
-};
-
-static struct platform_device ehci1_device = {
-	.name	= "ehci-platform",
-	.id	= 1,
-	.dev	= {
-		.dma_mask		= &ehci1_device.dev.coherent_dma_mask,
-		.coherent_dma_mask	= 0xffffffff,
-		.platform_data		= &ehcix_pdata,
-	},
-	.num_resources	= ARRAY_SIZE(ehci1_resources),
-	.resource	= ehci1_resources,
-};
-
-static struct usb_ohci_pdata ohcix_pdata = {
-	.power_on	= usb_power_on,
-	.power_off	= usb_power_off,
-	.power_suspend	= usb_power_off,
-};
-
-static struct resource ohci0_resources[] = {
-	[0] = {
-		.start	= 0xffe70400,
-		.end	= 0xffe70800 - 1,
-		.flags	= IORESOURCE_MEM,
-	},
-	[1] = {
-		.start	= gic_iid(0x4c),
-		.flags	= IORESOURCE_IRQ,
-	},
-};
-
-static struct platform_device ohci0_device = {
-	.name	= "ohci-platform",
-	.id	= 0,
-	.dev	= {
-		.dma_mask		= &ohci0_device.dev.coherent_dma_mask,
-		.coherent_dma_mask	= 0xffffffff,
-		.platform_data		= &ohcix_pdata,
-	},
-	.num_resources	= ARRAY_SIZE(ohci0_resources),
-	.resource	= ohci0_resources,
-};
-
-static struct resource ohci1_resources[] = {
-	[0] = {
-		.start	= 0xfff70400,
-		.end	= 0xfff70800 - 1,
-		.flags	= IORESOURCE_MEM,
-	},
-	[1] = {
-		.start	= gic_iid(0x4d),
-		.flags	= IORESOURCE_IRQ,
-	},
-};
-
-static struct platform_device ohci1_device = {
-	.name	= "ohci-platform",
-	.id	= 1,
-	.dev	= {
-		.dma_mask		= &ohci1_device.dev.coherent_dma_mask,
-		.coherent_dma_mask	= 0xffffffff,
-		.platform_data		= &ohcix_pdata,
-	},
-	.num_resources	= ARRAY_SIZE(ohci1_resources),
-	.resource	= ohci1_resources,
-};
-
-static struct platform_device *marzen_late_devices[] __initdata = {
-	&ehci0_device,
-	&ehci1_device,
-	&ohci0_device,
-	&ohci1_device,
-};
-
-void __init marzen_init_late(void)
-{
-	/* get usb phy */
-	phy = usb_get_phy(USB_PHY_TYPE_USB2);
-
-	shmobile_init_late();
-	platform_add_devices(marzen_late_devices,
-			     ARRAY_SIZE(marzen_late_devices));
-}
-
 static const struct pinctrl_map marzen_pinctrl_map[] = {
 	/* HSPI0 */
 	PIN_MAP_MUX_GROUP_DEFAULT("sh-hspi.0", "pfc-r8a7779",
@@ -416,6 +240,6 @@ MACHINE_START(MARZEN, "marzen")
 	.nr_irqs	= NR_IRQS_LEGACY,
 	.init_irq	= r8a7779_init_irq,
 	.init_machine	= marzen_init,
-	.init_late	= marzen_init_late,
+	.init_late	= r8a7779_init_late,
 	.init_time	= r8a7779_earlytimer_init,
 MACHINE_END
Index: renesas/arch/arm/mach-shmobile/include/mach/r8a7779.h
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/include/mach/r8a7779.h
+++ renesas/arch/arm/mach-shmobile/include/mach/r8a7779.h
@@ -33,6 +33,7 @@ extern void r8a7779_add_early_devices(vo
 extern void r8a7779_add_standard_devices(void);
 extern void r8a7779_add_standard_devices_dt(void);
 extern void r8a7779_add_ether_device(struct sh_eth_plat_data *pdata);
+extern void r8a7779_init_late(void);
 extern void r8a7779_clock_init(void);
 extern void r8a7779_pinmux_init(void);
 extern void r8a7779_pm_init(void);
Index: renesas/arch/arm/mach-shmobile/setup-r8a7779.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/setup-r8a7779.c
+++ renesas/arch/arm/mach-shmobile/setup-r8a7779.c
@@ -32,6 +32,10 @@
 #include <linux/sh_intc.h>
 #include <linux/sh_timer.h>
 #include <linux/dma-mapping.h>
+#include <linux/usb/otg.h>
+#include <linux/usb/ehci_pdriver.h>
+#include <linux/usb/ohci_pdriver.h>
+#include <linux/pm_runtime.h>
 #include <mach/hardware.h>
 #include <mach/irqs.h>
 #include <mach/r8a7779.h>
@@ -394,6 +398,162 @@ static struct platform_device sata_devic
 	},
 };
 
+/* USB PHY */
+static struct resource usb_phy_resources[] = {
+	[0] = {
+		.start		= 0xffe70000,
+		.end		= 0xffe70900 - 1,
+		.flags		= IORESOURCE_MEM,
+	},
+	[1] = {
+		.start		= 0xfff70000,
+		.end		= 0xfff70900 - 1,
+		.flags		= IORESOURCE_MEM,
+	},
+};
+
+static struct platform_device usb_phy_device = {
+	.name		= "rcar_usb_phy",
+	.id		= -1,
+	.resource	= usb_phy_resources,
+	.num_resources	= ARRAY_SIZE(usb_phy_resources),
+};
+
+/* USB */
+static struct usb_phy *phy;
+
+static int usb_power_on(struct platform_device *pdev)
+{
+	if (!phy)
+		return -EIO;
+
+	pm_runtime_enable(&pdev->dev);
+	pm_runtime_get_sync(&pdev->dev);
+
+	usb_phy_init(phy);
+
+	return 0;
+}
+
+static void usb_power_off(struct platform_device *pdev)
+{
+	if (!phy)
+		return;
+
+	usb_phy_shutdown(phy);
+
+	pm_runtime_put_sync(&pdev->dev);
+	pm_runtime_disable(&pdev->dev);
+}
+
+static struct usb_ehci_pdata ehcix_pdata = {
+	.power_on	= usb_power_on,
+	.power_off	= usb_power_off,
+	.power_suspend	= usb_power_off,
+};
+
+static struct resource ehci0_resources[] = {
+	[0] = {
+		.start	= 0xffe70000,
+		.end	= 0xffe70400 - 1,
+		.flags	= IORESOURCE_MEM,
+	},
+	[1] = {
+		.start	= gic_iid(0x4c),
+		.flags	= IORESOURCE_IRQ,
+	},
+};
+
+static struct platform_device ehci0_device = {
+	.name	= "ehci-platform",
+	.id	= 0,
+	.dev	= {
+		.dma_mask		= &ehci0_device.dev.coherent_dma_mask,
+		.coherent_dma_mask	= 0xffffffff,
+		.platform_data		= &ehcix_pdata,
+	},
+	.num_resources	= ARRAY_SIZE(ehci0_resources),
+	.resource	= ehci0_resources,
+};
+
+static struct resource ehci1_resources[] = {
+	[0] = {
+		.start	= 0xfff70000,
+		.end	= 0xfff70400 - 1,
+		.flags	= IORESOURCE_MEM,
+	},
+	[1] = {
+		.start	= gic_iid(0x4d),
+		.flags	= IORESOURCE_IRQ,
+	},
+};
+
+static struct platform_device ehci1_device = {
+	.name	= "ehci-platform",
+	.id	= 1,
+	.dev	= {
+		.dma_mask		= &ehci1_device.dev.coherent_dma_mask,
+		.coherent_dma_mask	= 0xffffffff,
+		.platform_data		= &ehcix_pdata,
+	},
+	.num_resources	= ARRAY_SIZE(ehci1_resources),
+	.resource	= ehci1_resources,
+};
+
+static struct usb_ohci_pdata ohcix_pdata = {
+	.power_on	= usb_power_on,
+	.power_off	= usb_power_off,
+	.power_suspend	= usb_power_off,
+};
+
+static struct resource ohci0_resources[] = {
+	[0] = {
+		.start	= 0xffe70400,
+		.end	= 0xffe70800 - 1,
+		.flags	= IORESOURCE_MEM,
+	},
+	[1] = {
+		.start	= gic_iid(0x4c),
+		.flags	= IORESOURCE_IRQ,
+	},
+};
+
+static struct platform_device ohci0_device = {
+	.name	= "ohci-platform",
+	.id	= 0,
+	.dev	= {
+		.dma_mask		= &ohci0_device.dev.coherent_dma_mask,
+		.coherent_dma_mask	= 0xffffffff,
+		.platform_data		= &ohcix_pdata,
+	},
+	.num_resources	= ARRAY_SIZE(ohci0_resources),
+	.resource	= ohci0_resources,
+};
+
+static struct resource ohci1_resources[] = {
+	[0] = {
+		.start	= 0xfff70400,
+		.end	= 0xfff70800 - 1,
+		.flags	= IORESOURCE_MEM,
+	},
+	[1] = {
+		.start	= gic_iid(0x4d),
+		.flags	= IORESOURCE_IRQ,
+	},
+};
+
+static struct platform_device ohci1_device = {
+	.name	= "ohci-platform",
+	.id	= 1,
+	.dev	= {
+		.dma_mask		= &ohci1_device.dev.coherent_dma_mask,
+		.coherent_dma_mask	= 0xffffffff,
+		.platform_data		= &ohcix_pdata,
+	},
+	.num_resources	= ARRAY_SIZE(ohci1_resources),
+	.resource	= ohci1_resources,
+};
+
 /* Ether */
 static struct resource ether_resources[] = {
 	{
@@ -415,9 +575,10 @@ static struct platform_device *r8a7779_d
 	&scif5_device,
 	&tmu00_device,
 	&tmu01_device,
+	&usb_phy_device,
 };
 
-static struct platform_device *r8a7779_late_devices[] __initdata = {
+static struct platform_device *r8a7779_standard_devices[] __initdata = {
 	&i2c0_device,
 	&i2c1_device,
 	&i2c2_device,
@@ -437,8 +598,8 @@ void __init r8a7779_add_standard_devices
 
 	platform_add_devices(r8a7779_devices_dt,
 			    ARRAY_SIZE(r8a7779_devices_dt));
-	platform_add_devices(r8a7779_late_devices,
-			    ARRAY_SIZE(r8a7779_late_devices));
+	platform_add_devices(r8a7779_standard_devices,
+			    ARRAY_SIZE(r8a7779_standard_devices));
 }
 
 void __init r8a7779_add_ether_device(struct sh_eth_plat_data *pdata)
@@ -481,6 +642,23 @@ void __init r8a7779_add_early_devices(vo
 	 */
 }
 
+static struct platform_device *r8a7779_late_devices[] __initdata = {
+	&ehci0_device,
+	&ehci1_device,
+	&ohci0_device,
+	&ohci1_device,
+};
+
+void __init r8a7779_init_late(void)
+{
+	/* get USB PHY */
+	phy = usb_get_phy(USB_PHY_TYPE_USB2);
+
+	shmobile_init_late();
+	platform_add_devices(r8a7779_late_devices,
+			     ARRAY_SIZE(r8a7779_late_devices));
+}
+
 #ifdef CONFIG_USE_OF
 void __init r8a7779_init_delay(void)
 {
@@ -514,6 +692,7 @@ DT_MACHINE_START(R8A7779_DT, "Generic R8
 	.init_irq	= r8a7779_init_irq_dt,
 	.init_machine	= r8a7779_add_standard_devices_dt,
 	.init_time	= shmobile_timer_init,
+	.init_late	= r8a7779_init_late,
 	.dt_compat	= r8a7779_compat_dt,
 MACHINE_END
 #endif /* CONFIG_USE_OF */


From sergei.shtylyov at cogentembedded.com  Mon Apr  8 17:21:22 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Tue, 9 Apr 2013 01:21:22 +0400
Subject: [PATCH v2 3/9] ARM: shmobile: R8A7779: setup EHCI internal buffer
Message-ID: <201304090121.23296.sergei.shtylyov@cogentembedded.com>

Setup the EHCI internal buffer (before EHCI driver has a chance to touch the
registers) using the pre_setup() method in 'struct usb_ehci_pdata'.

Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

---
Changes since the original posting:
- changed from init() platform device method to pre_setup() as per the previous
  patch.

 arch/arm/mach-shmobile/setup-r8a7779.c |   15 +++++++++++++++
 1 file changed, 15 insertions(+)

Index: renesas/arch/arm/mach-shmobile/setup-r8a7779.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/setup-r8a7779.c
+++ renesas/arch/arm/mach-shmobile/setup-r8a7779.c
@@ -446,10 +446,25 @@ static void usb_power_off(struct platfor
 	pm_runtime_disable(&pdev->dev);
 }
 
+static int ehci_init_internal_buffer(struct usb_hcd *hcd)
+{
+	/*
+	 * Below are recommended values from the datasheet;
+	 * see [USB :: Setting of EHCI Internal Buffer].
+	 */
+	/* EHCI IP internal buffer setting */
+	iowrite32(0x00ff0040, hcd->regs + 0x0094);
+	/* EHCI IP internal buffer enable */
+	iowrite32(0x00000001, hcd->regs + 0x009C);
+
+	return 0;
+}
+
 static struct usb_ehci_pdata ehcix_pdata = {
 	.power_on	= usb_power_on,
 	.power_off	= usb_power_off,
 	.power_suspend	= usb_power_off,
+	.pre_setup	= ehci_init_internal_buffer,
 };
 
 static struct resource ehci0_resources[] = {


From sergei.shtylyov at cogentembedded.com  Mon Apr  8 17:22:49 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Tue, 9 Apr 2013 01:22:49 +0400
Subject: [PATCH v2 4/9] rcar-phy: remove EHCI internal buffer setup
Message-ID: <201304090122.49969.sergei.shtylyov@cogentembedded.com>

Now that the EHCI internal  buffer setup is done by the platform code, we  can
remove  such code from this driver as it  never  really belonged here.  We also
no longer need the 2nd memory region now (2nd EHCI controller is simply missing
in e.g. R8A7778 SoC).

Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

---
Changes since the original posting:
- split R8A7779 SoC file change to a separate patch.

 drivers/usb/phy/rcar-phy.c |   28 ++++------------------------
 1 file changed, 4 insertions(+), 24 deletions(-)

Index: renesas/drivers/usb/phy/rcar-phy.c
===================================================================
--- renesas.orig/drivers/usb/phy/rcar-phy.c
+++ renesas/drivers/usb/phy/rcar-phy.c
@@ -23,8 +23,6 @@
 #define USBEH0		0x080C
 #define USBOH0		0x081C
 #define USBCTL0		0x0858
-#define EIIBC1		0x0094
-#define EIIBC2		0x009C
 
 /* USBPCTRL1 */
 #define PHY_RST		(1 << 2)
@@ -40,7 +38,6 @@ struct rcar_usb_phy_priv {
 	spinlock_t lock;
 
 	void __iomem *reg0;
-	void __iomem *reg1;
 	int counter;
 };
 
@@ -59,7 +56,6 @@ static int rcar_usb_phy_init(struct usb_
 	struct rcar_usb_phy_priv *priv = usb_phy_to_priv(phy);
 	struct device *dev = phy->dev;
 	void __iomem *reg0 = priv->reg0;
-	void __iomem *reg1 = priv->reg1;
 	int i;
 	u32 val;
 	unsigned long flags;
@@ -97,19 +93,6 @@ static int rcar_usb_phy_init(struct usb_
 		iowrite32(0x00000000, (reg0 + USBPCTRL0));
 
 		/*
-		 * EHCI IP internal buffer setting
-		 * EHCI IP internal buffer enable
-		 *
-		 * These are recommended value of a datasheet
-		 * see [USB :: EHCI internal buffer setting]
-		 */
-		iowrite32(0x00ff0040, (reg0 + EIIBC1));
-		iowrite32(0x00ff0040, (reg1 + EIIBC1));
-
-		iowrite32(0x00000001, (reg0 + EIIBC2));
-		iowrite32(0x00000001, (reg1 + EIIBC2));
-
-		/*
 		 * Bus alignment settings
 		 */
 
@@ -145,14 +128,13 @@ static void rcar_usb_phy_shutdown(struct
 static int rcar_usb_phy_probe(struct platform_device *pdev)
 {
 	struct rcar_usb_phy_priv *priv;
-	struct resource *res0, *res1;
+	struct resource *res0;
 	struct device *dev = &pdev->dev;
-	void __iomem *reg0, *reg1;
+	void __iomem *reg0;
 	int ret;
 
 	res0 = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-	res1 = platform_get_resource(pdev, IORESOURCE_MEM, 1);
-	if (!res0 || !res1) {
+	if (!res0) {
 		dev_err(dev, "Not enough platform resources\n");
 		return -EINVAL;
 	}
@@ -164,8 +146,7 @@ static int rcar_usb_phy_probe(struct pla
 	 * this driver can't use devm_request_and_ioremap(dev, res) here
 	 */
 	reg0 = devm_ioremap_nocache(dev, res0->start, resource_size(res0));
-	reg1 = devm_ioremap_nocache(dev, res1->start, resource_size(res1));
-	if (!reg0 || !reg1) {
+	if (!reg0) {
 		dev_err(dev, "ioremap error\n");
 		return -ENOMEM;
 	}
@@ -177,7 +158,6 @@ static int rcar_usb_phy_probe(struct pla
 	}
 
 	priv->reg0		= reg0;
-	priv->reg1		= reg1;
 	priv->counter		= 0;
 	priv->phy.dev		= dev;
 	priv->phy.label		= dev_name(dev);


From sergei.shtylyov at cogentembedded.com  Mon Apr  8 17:26:27 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Tue, 9 Apr 2013 01:26:27 +0400
Subject: [PATCH v2 5/9] ARM: shmobile: R8A7779: remove USB PHY 2nd memory
 resource
Message-ID: <201304090126.27827.sergei.shtylyov@cogentembedded.com>

Now that 'drivers/usb/phy/rcar-phy.c' doesn't require the second memory resource
anymore, we can remove it from the R8A7779's USB PHY platform device.

Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

---
Changes since the original posting:
- new patch in this version, split from the previous one.

 arch/arm/mach-shmobile/setup-r8a7779.c |    5 -----
 1 file changed, 5 deletions(-)

Index: renesas/arch/arm/mach-shmobile/setup-r8a7779.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/setup-r8a7779.c
+++ renesas/arch/arm/mach-shmobile/setup-r8a7779.c
@@ -405,11 +405,6 @@ static struct resource usb_phy_resources
 		.end		= 0xffe70900 - 1,
 		.flags		= IORESOURCE_MEM,
 	},
-	[1] = {
-		.start		= 0xfff70000,
-		.end		= 0xfff70900 - 1,
-		.flags		= IORESOURCE_MEM,
-	},
 };
 
 static struct platform_device usb_phy_device = {


From sboyd at codeaurora.org  Mon Apr  8 17:27:23 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Mon,  8 Apr 2013 14:27:23 -0700
Subject: [PATCHv4 01/11] clockevents: Prefer CPU local devices over global
 devices
In-Reply-To: <1365456453-16297-1-git-send-email-sboyd@codeaurora.org>
References: <1365456453-16297-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1365456453-16297-2-git-send-email-sboyd@codeaurora.org>

On an SMP system with only one global clockevent and a dummy
clockevent per CPU we run into problems. We want the dummy
clockevents to be registered as the per CPU tick devices, but
we can only achieve that if we register the dummy clockevents
before the global clockevent or if we artificially inflate the
rating of the dummy clockevents to be higher than the rating
of the global clockevent. Failure to do so leads to boot
hangs when the dummy timers are registered on all other CPUs
besides the CPU that accepted the global clockevent as its tick
device and there is no broadcast timer to poke the dummy
devices.

If we're registering multiple clockevents and one clockevent is
global and the other is local to a particular CPU we should
choose to use the local clockevent regardless of the rating of
the device. This way, if the clockevent is a dummy it will take
the tick device duty as long as there isn't a higher rated tick
device and any global clockevent will be bumped out into
broadcast mode, fixing the problem described above.

Reported-by: Mark Rutland <mark.rutland at arm.com>
Cc: John Stultz <john.stultz at linaro.org>
Cc: Thomas Gleixner <tglx at linutronix.de>
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 kernel/time/tick-common.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/kernel/time/tick-common.c b/kernel/time/tick-common.c
index b1600a6..9ea59b9 100644
--- a/kernel/time/tick-common.c
+++ b/kernel/time/tick-common.c
@@ -251,9 +251,10 @@ static int tick_check_new_device(struct clock_event_device *newdev)
 		    !(newdev->features & CLOCK_EVT_FEAT_ONESHOT))
 			goto out_bc;
 		/*
-		 * Check the rating
+		 * Check the rating, but prefer CPU local devices
 		 */
-		if (curdev->rating >= newdev->rating)
+		if (curdev->rating >= newdev->rating &&
+		    cpumask_equal(curdev->cpumask, newdev->cpumask))
 			goto out_bc;
 	}
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Mon Apr  8 17:27:26 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Mon,  8 Apr 2013 14:27:26 -0700
Subject: [PATCHv4 04/11] ARM: smp_twd: Divorce smp_twd from local timer API
In-Reply-To: <1365456453-16297-1-git-send-email-sboyd@codeaurora.org>
References: <1365456453-16297-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1365456453-16297-5-git-send-email-sboyd@codeaurora.org>

Separate the smp_twd timers from the local timer API. This will
allow us to remove ARM local timer support in the near future and
gets us closer to moving this driver to drivers/clocksource.

Cc: Russell King <linux at arm.linux.org.uk>
Cc: Tony Lindgren <tony at atomide.com>
Tested-by: Mark Rutland <mark.rutland at arm.com>
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 arch/arm/Kconfig          |  2 +-
 arch/arm/kernel/smp_twd.c | 64 +++++++++++++++++++++++++++++++----------------
 2 files changed, 44 insertions(+), 22 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 13b7394..ee6bb9d 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1523,6 +1523,7 @@ config SMP
 	depends on HAVE_SMP
 	depends on MMU
 	select HAVE_ARM_SCU if !ARCH_MSM_SCORPIONMP
+	select HAVE_ARM_TWD if (!ARCH_MSM_SCORPIONMP && !EXYNOS4_MCT)
 	select USE_GENERIC_SMP_HELPERS
 	help
 	  This enables support for systems with more than one CPU. If you have
@@ -1646,7 +1647,6 @@ config LOCAL_TIMERS
 	bool "Use local timer interrupts"
 	depends on SMP
 	default y
-	select HAVE_ARM_TWD if (!ARCH_MSM_SCORPIONMP && !EXYNOS4_MCT)
 	help
 	  Enable support for local timers on SMP platforms, rather then the
 	  legacy IPI broadcast method.  Local timers allows the system
diff --git a/arch/arm/kernel/smp_twd.c b/arch/arm/kernel/smp_twd.c
index 3f25650..a79476d 100644
--- a/arch/arm/kernel/smp_twd.c
+++ b/arch/arm/kernel/smp_twd.c
@@ -11,6 +11,7 @@
 #include <linux/init.h>
 #include <linux/kernel.h>
 #include <linux/clk.h>
+#include <linux/cpu.h>
 #include <linux/delay.h>
 #include <linux/device.h>
 #include <linux/err.h>
@@ -24,7 +25,6 @@
 
 #include <asm/smp_plat.h>
 #include <asm/smp_twd.h>
-#include <asm/localtimer.h>
 
 /* set up by the platform code */
 static void __iomem *twd_base;
@@ -33,7 +33,7 @@ static struct clk *twd_clk;
 static unsigned long twd_timer_rate;
 static DEFINE_PER_CPU(bool, percpu_setup_called);
 
-static struct clock_event_device __percpu **twd_evt;
+static struct clock_event_device __percpu *twd_evt;
 static int twd_ppi;
 
 static void twd_set_mode(enum clock_event_mode mode,
@@ -90,8 +90,10 @@ static int twd_timer_ack(void)
 	return 0;
 }
 
-static void twd_timer_stop(struct clock_event_device *clk)
+static void twd_timer_stop(void)
 {
+	struct clock_event_device *clk = __this_cpu_ptr(twd_evt);
+
 	twd_set_mode(CLOCK_EVT_MODE_UNUSED, clk);
 	disable_percpu_irq(clk->irq);
 }
@@ -106,7 +108,7 @@ static void twd_update_frequency(void *new_rate)
 {
 	twd_timer_rate = *((unsigned long *) new_rate);
 
-	clockevents_update_freq(*__this_cpu_ptr(twd_evt), twd_timer_rate);
+	clockevents_update_freq(__this_cpu_ptr(twd_evt), twd_timer_rate);
 }
 
 static int twd_rate_change(struct notifier_block *nb,
@@ -132,7 +134,7 @@ static struct notifier_block twd_clk_nb = {
 
 static int twd_clk_init(void)
 {
-	if (twd_evt && *__this_cpu_ptr(twd_evt) && !IS_ERR(twd_clk))
+	if (twd_evt && __this_cpu_ptr(twd_evt) && !IS_ERR(twd_clk))
 		return clk_notifier_register(twd_clk, &twd_clk_nb);
 
 	return 0;
@@ -151,7 +153,7 @@ static void twd_update_frequency(void *data)
 {
 	twd_timer_rate = clk_get_rate(twd_clk);
 
-	clockevents_update_freq(*__this_cpu_ptr(twd_evt), twd_timer_rate);
+	clockevents_update_freq(__this_cpu_ptr(twd_evt), twd_timer_rate);
 }
 
 static int twd_cpufreq_transition(struct notifier_block *nb,
@@ -177,7 +179,7 @@ static struct notifier_block twd_cpufreq_nb = {
 
 static int twd_cpufreq_init(void)
 {
-	if (twd_evt && *__this_cpu_ptr(twd_evt) && !IS_ERR(twd_clk))
+	if (twd_evt && __this_cpu_ptr(twd_evt) && !IS_ERR(twd_clk))
 		return cpufreq_register_notifier(&twd_cpufreq_nb,
 			CPUFREQ_TRANSITION_NOTIFIER);
 
@@ -228,7 +230,7 @@ static void __cpuinit twd_calibrate_rate(void)
 
 static irqreturn_t twd_handler(int irq, void *dev_id)
 {
-	struct clock_event_device *evt = *(struct clock_event_device **)dev_id;
+	struct clock_event_device *evt = dev_id;
 
 	if (twd_timer_ack()) {
 		evt->event_handler(evt);
@@ -265,9 +267,9 @@ static void twd_get_clock(struct device_node *np)
 /*
  * Setup the local clock events for a CPU.
  */
-static int __cpuinit twd_timer_setup(struct clock_event_device *clk)
+static void __cpuinit twd_timer_setup(void)
 {
-	struct clock_event_device **this_cpu_clk;
+	struct clock_event_device *clk = __this_cpu_ptr(twd_evt);
 	int cpu = smp_processor_id();
 
 	/*
@@ -276,9 +278,9 @@ static int __cpuinit twd_timer_setup(struct clock_event_device *clk)
 	 */
 	if (per_cpu(percpu_setup_called, cpu)) {
 		__raw_writel(0, twd_base + TWD_TIMER_CONTROL);
-		clockevents_register_device(*__this_cpu_ptr(twd_evt));
+		clockevents_register_device(clk);
 		enable_percpu_irq(clk->irq, 0);
-		return 0;
+		return;
 	}
 	per_cpu(percpu_setup_called, cpu) = true;
 
@@ -297,27 +299,37 @@ static int __cpuinit twd_timer_setup(struct clock_event_device *clk)
 	clk->set_mode = twd_set_mode;
 	clk->set_next_event = twd_set_next_event;
 	clk->irq = twd_ppi;
-
-	this_cpu_clk = __this_cpu_ptr(twd_evt);
-	*this_cpu_clk = clk;
+	clk->cpumask = cpumask_of(cpu);
 
 	clockevents_config_and_register(clk, twd_timer_rate,
 					0xf, 0xffffffff);
 	enable_percpu_irq(clk->irq, 0);
+}
 
-	return 0;
+static int __cpuinit twd_timer_cpu_notify(struct notifier_block *self,
+					   unsigned long action, void *hcpu)
+{
+	switch (action & ~CPU_TASKS_FROZEN) {
+	case CPU_STARTING:
+		twd_timer_setup();
+		break;
+	case CPU_DYING:
+		twd_timer_stop();
+		break;
+	}
+
+	return NOTIFY_OK;
 }
 
-static struct local_timer_ops twd_lt_ops __cpuinitdata = {
-	.setup	= twd_timer_setup,
-	.stop	= twd_timer_stop,
+static struct notifier_block twd_timer_cpu_nb __cpuinitdata = {
+	.notifier_call = twd_timer_cpu_notify,
 };
 
 static int __init twd_local_timer_common_register(struct device_node *np)
 {
 	int err;
 
-	twd_evt = alloc_percpu(struct clock_event_device *);
+	twd_evt = alloc_percpu(struct clock_event_device);
 	if (!twd_evt) {
 		err = -ENOMEM;
 		goto out_free;
@@ -329,12 +341,22 @@ static int __init twd_local_timer_common_register(struct device_node *np)
 		goto out_free;
 	}
 
-	err = local_timer_register(&twd_lt_ops);
+	err = register_cpu_notifier(&twd_timer_cpu_nb);
 	if (err)
 		goto out_irq;
 
 	twd_get_clock(np);
 
+	/*
+	 * Immediately configure the timer on the boot CPU, unless we need
+	 * jiffies to be incrementing to calibrate the rate in which case
+	 * setup the timer in late_time_init.
+	 */
+	if (twd_timer_rate)
+		twd_timer_setup();
+	else
+		late_time_init = twd_timer_setup;
+
 	return 0;
 
 out_irq:
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Mon Apr  8 17:27:31 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Mon,  8 Apr 2013 14:27:31 -0700
Subject: [PATCHv4 09/11] clocksource: time-armada-370-xp: Fix sparse warning
In-Reply-To: <1365456453-16297-1-git-send-email-sboyd@codeaurora.org>
References: <1365456453-16297-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1365456453-16297-10-git-send-email-sboyd@codeaurora.org>

drivers/clocksource/time-armada-370-xp.c:217:13: warning: symbol
'armada_370_xp_timer_init' was not declared. Should it be static?

Also remove the __init marking in the prototype as it's
unnecessary along with the init.h include.

Acked-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 drivers/clocksource/time-armada-370-xp.c | 3 ++-
 include/linux/time-armada-370-xp.h       | 4 +---
 2 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/clocksource/time-armada-370-xp.c b/drivers/clocksource/time-armada-370-xp.c
index 47a6730..efe4aef 100644
--- a/drivers/clocksource/time-armada-370-xp.c
+++ b/drivers/clocksource/time-armada-370-xp.c
@@ -27,10 +27,11 @@
 #include <linux/of_address.h>
 #include <linux/irq.h>
 #include <linux/module.h>
+#include <linux/percpu.h>
+#include <linux/time-armada-370-xp.h>
 
 #include <asm/sched_clock.h>
 #include <asm/localtimer.h>
-#include <linux/percpu.h>
 /*
  * Timer block registers.
  */
diff --git a/include/linux/time-armada-370-xp.h b/include/linux/time-armada-370-xp.h
index dfdfdc0..6fb0856 100644
--- a/include/linux/time-armada-370-xp.h
+++ b/include/linux/time-armada-370-xp.h
@@ -11,8 +11,6 @@
 #ifndef __TIME_ARMADA_370_XPPRCMU_H
 #define __TIME_ARMADA_370_XPPRCMU_H
 
-#include <linux/init.h>
-
-void __init armada_370_xp_timer_init(void);
+void armada_370_xp_timer_init(void);
 
 #endif
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Mon Apr  8 17:27:24 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Mon,  8 Apr 2013 14:27:24 -0700
Subject: [PATCHv4 02/11] clocksource: add generic dummy timer driver
In-Reply-To: <1365456453-16297-1-git-send-email-sboyd@codeaurora.org>
References: <1365456453-16297-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1365456453-16297-3-git-send-email-sboyd@codeaurora.org>

From: Mark Rutland <mark.rutland at arm.com>

Several architectures have a dummy timer driver tightly coupled with
their broadcast code to support machines without cpu-local timers (or
where there is a lack of driver support).

Since 12ad100046: "clockevents: Add generic timer broadcast function"
it's been possible to write broadcast-capable timer drivers decoupled
from the broadcast mechanism. We can use this functionality to implement
a generic dummy timer driver that can be shared by all architectures
with generic tick broadcast (ARCH_HAS_TICK_BROADCAST).

This patch implements a generic dummy timer using this facility.

Signed-off-by: Mark Rutland <mark.rutland at arm.com>
Cc: John Stultz <john.stultz at linaro.org>
Cc: Thomas Gleixner <tglx at linutronix.de>
[sboyd: Make percpu data static, use __this_cpu_ptr(), move to
        early_initcall to properly register on each CPU, only
	register if more than one CPU possible]
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 drivers/clocksource/Makefile      |  1 +
 drivers/clocksource/dummy_timer.c | 69 +++++++++++++++++++++++++++++++++++++++
 2 files changed, 70 insertions(+)
 create mode 100644 drivers/clocksource/dummy_timer.c

diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index 4d8283a..655d718 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -22,3 +22,4 @@ obj-$(CONFIG_VT8500_TIMER)	+= vt8500_timer.o
 
 obj-$(CONFIG_ARM_ARCH_TIMER)		+= arm_arch_timer.o
 obj-$(CONFIG_CLKSRC_METAG_GENERIC)	+= metag_generic.o
+obj-$(CONFIG_ARCH_HAS_TICK_BROADCAST)	+= dummy_timer.o
diff --git a/drivers/clocksource/dummy_timer.c b/drivers/clocksource/dummy_timer.c
new file mode 100644
index 0000000..1f55f96
--- /dev/null
+++ b/drivers/clocksource/dummy_timer.c
@@ -0,0 +1,69 @@
+/*
+ *  linux/drivers/clocksource/dummy_timer.c
+ *
+ *  Copyright (C) 2013 ARM Ltd.
+ *  All Rights Reserved
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include <linux/clockchips.h>
+#include <linux/cpu.h>
+#include <linux/init.h>
+#include <linux/percpu.h>
+#include <linux/cpumask.h>
+
+static DEFINE_PER_CPU(struct clock_event_device, dummy_timer_evt);
+
+static void dummy_timer_set_mode(enum clock_event_mode mode,
+			   struct clock_event_device *evt)
+{
+	/*
+	 * Core clockevents code will call this when exchanging timer devices.
+	 * We don't need to do anything here.
+	 */
+}
+
+static void __cpuinit dummy_timer_setup(void)
+{
+	int cpu = smp_processor_id();
+	struct clock_event_device *evt = __this_cpu_ptr(&dummy_timer_evt);
+
+	evt->name	= "dummy_timer";
+	evt->features	= CLOCK_EVT_FEAT_PERIODIC |
+			  CLOCK_EVT_FEAT_ONESHOT |
+			  CLOCK_EVT_FEAT_DUMMY;
+	evt->rating	= 100;
+	evt->set_mode	= dummy_timer_set_mode;
+	evt->cpumask	= cpumask_of(cpu);
+
+	clockevents_register_device(evt);
+}
+
+static int __cpuinit dummy_timer_cpu_notify(struct notifier_block *self,
+				      unsigned long action, void *hcpu)
+{
+	if ((action & ~CPU_TASKS_FROZEN) == CPU_STARTING)
+		dummy_timer_setup();
+
+	return NOTIFY_OK;
+}
+
+static struct notifier_block dummy_timer_cpu_nb __cpuinitdata = {
+	.notifier_call = dummy_timer_cpu_notify,
+};
+
+static int __init dummy_timer_register(void)
+{
+	int err = register_cpu_notifier(&dummy_timer_cpu_nb);
+	if (err)
+		return err;
+
+	/* We won't get a call on the boot CPU, so register immediately */
+	if (num_possible_cpus() > 1)
+		dummy_timer_setup();
+
+	return 0;
+}
+early_initcall(dummy_timer_register);
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Mon Apr  8 17:27:28 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Mon,  8 Apr 2013 14:27:28 -0700
Subject: [PATCHv4 06/11] ARM: EXYNOS4: Divorce mct from local timer API
In-Reply-To: <1365456453-16297-1-git-send-email-sboyd@codeaurora.org>
References: <1365456453-16297-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1365456453-16297-7-git-send-email-sboyd@codeaurora.org>

Separate the mct local timers from the local timer API. This will
allow us to remove ARM local timer support in the near future and
gets us closer to moving this driver to drivers/clocksource.

Cc: Kukjin Kim <kgene.kim at samsung.com>
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 arch/arm/mach-exynos/mct.c | 60 +++++++++++++++++++++++++++++++++-------------
 1 file changed, 43 insertions(+), 17 deletions(-)

diff --git a/arch/arm/mach-exynos/mct.c b/arch/arm/mach-exynos/mct.c
index c9d6650..a3ec5b6 100644
--- a/arch/arm/mach-exynos/mct.c
+++ b/arch/arm/mach-exynos/mct.c
@@ -16,13 +16,13 @@
 #include <linux/err.h>
 #include <linux/clk.h>
 #include <linux/clockchips.h>
+#include <linux/cpu.h>
 #include <linux/platform_device.h>
 #include <linux/delay.h>
 #include <linux/percpu.h>
 #include <linux/of.h>
 
 #include <asm/arch_timer.h>
-#include <asm/localtimer.h>
 
 #include <plat/cpu.h>
 
@@ -42,7 +42,7 @@ static unsigned long clk_rate;
 static unsigned int mct_int_type;
 
 struct mct_clock_event_device {
-	struct clock_event_device *evt;
+	struct clock_event_device evt;
 	void __iomem *base;
 	char name[10];
 };
@@ -264,8 +264,6 @@ static void exynos4_clockevent_init(void)
 		setup_irq(EXYNOS4_IRQ_MCT_G0, &mct_comp_event_irq);
 }
 
-#ifdef CONFIG_LOCAL_TIMERS
-
 static DEFINE_PER_CPU(struct mct_clock_event_device, percpu_mct_tick);
 
 /* Clock event handling */
@@ -338,7 +336,7 @@ static inline void exynos4_tick_set_mode(enum clock_event_mode mode,
 
 static int exynos4_mct_tick_clear(struct mct_clock_event_device *mevt)
 {
-	struct clock_event_device *evt = mevt->evt;
+	struct clock_event_device *evt = &mevt->evt;
 
 	/*
 	 * This is for supporting oneshot mode.
@@ -360,7 +358,7 @@ static int exynos4_mct_tick_clear(struct mct_clock_event_device *mevt)
 static irqreturn_t exynos4_mct_tick_isr(int irq, void *dev_id)
 {
 	struct mct_clock_event_device *mevt = dev_id;
-	struct clock_event_device *evt = mevt->evt;
+	struct clock_event_device *evt = &mevt->evt;
 
 	exynos4_mct_tick_clear(mevt);
 
@@ -387,8 +385,7 @@ static int __cpuinit exynos4_local_timer_setup(struct clock_event_device *evt)
 	unsigned int cpu = smp_processor_id();
 	int mct_lx_irq;
 
-	mevt = this_cpu_ptr(&percpu_mct_tick);
-	mevt->evt = evt;
+	mevt = container_of(evt, struct mct_clock_event_device, evt);
 
 	mevt->base = EXYNOS4_MCT_L_BASE(cpu);
 	sprintf(mevt->name, "mct_tick%d", cpu);
@@ -426,7 +423,7 @@ static int __cpuinit exynos4_local_timer_setup(struct clock_event_device *evt)
 	return 0;
 }
 
-static void exynos4_local_timer_stop(struct clock_event_device *evt)
+static void __cpuinit exynos4_local_timer_stop(struct clock_event_device *evt)
 {
 	unsigned int cpu = smp_processor_id();
 	evt->set_mode(CLOCK_EVT_MODE_UNUSED, evt);
@@ -439,22 +436,43 @@ static void exynos4_local_timer_stop(struct clock_event_device *evt)
 		disable_percpu_irq(EXYNOS_IRQ_MCT_LOCALTIMER);
 }
 
-static struct local_timer_ops exynos4_mct_tick_ops __cpuinitdata = {
-	.setup	= exynos4_local_timer_setup,
-	.stop	= exynos4_local_timer_stop,
+static int __cpuinit exynos4_mct_cpu_notify(struct notifier_block *self,
+					   unsigned long action, void *hcpu)
+{
+	struct mct_clock_event_device *mevt;
+
+	/*
+	 * Dereference cpu pointer in each case to avoid spurious
+	 * preemptible warnings
+	 */
+	switch (action & ~CPU_TASKS_FROZEN) {
+	case CPU_STARTING:
+		mevt = this_cpu_ptr(&percpu_mct_tick);
+		exynos4_local_timer_setup(&mevt->evt);
+		break;
+	case CPU_DYING:
+		mevt = this_cpu_ptr(&percpu_mct_tick);
+		exynos4_local_timer_stop(&mevt->evt);
+		break;
+	}
+
+	return NOTIFY_OK;
+}
+
+static struct notifier_block exynos4_mct_cpu_nb __cpuinitdata = {
+	.notifier_call = exynos4_mct_cpu_notify,
 };
-#endif /* CONFIG_LOCAL_TIMERS */
 
 static void __init exynos4_timer_resources(void)
 {
+	int err;
+	struct mct_clock_event_device *mevt = this_cpu_ptr(&percpu_mct_tick);
 	struct clk *mct_clk;
 	mct_clk = clk_get(NULL, "xtal");
 
 	clk_rate = clk_get_rate(mct_clk);
 
-#ifdef CONFIG_LOCAL_TIMERS
 	if (mct_int_type == MCT_INT_PPI) {
-		int err;
 
 		err = request_percpu_irq(EXYNOS_IRQ_MCT_LOCALTIMER,
 					 exynos4_mct_tick_isr, "MCT",
@@ -463,8 +481,16 @@ static void __init exynos4_timer_resources(void)
 		     EXYNOS_IRQ_MCT_LOCALTIMER, err);
 	}
 
-	local_timer_register(&exynos4_mct_tick_ops);
-#endif /* CONFIG_LOCAL_TIMERS */
+	err = register_cpu_notifier(&exynos4_mct_cpu_nb);
+	if (err)
+		goto out_irq;
+
+	/* Immediately configure the timer on the boot CPU */
+	exynos4_local_timer_setup(&mevt->evt);
+	return;
+
+out_irq:
+	free_percpu_irq(EXYNOS_IRQ_MCT_LOCALTIMER, &percpu_mct_tick);
 }
 
 void __init exynos4_timer_init(void)
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Mon Apr  8 17:27:22 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Mon,  8 Apr 2013 14:27:22 -0700
Subject: [PATCHv4 00/11] Remove ARM local timer API
Message-ID: <1365456453-16297-1-git-send-email-sboyd@codeaurora.org>

In light of Mark Rutland's recent work on divorcing the ARM architected
timers from the ARM local timer API and introducing a generic arch hook for
broadcast it seems that we should remove the local timer API entirely.
Doing so will reduce the architecture dependencies of our timer drivers,
reduce code in ARM core, and simplify timer drivers because they no longer
go through an architecture layer that is essentially a hotplug notifier.

Previous attempts have been made[1] unsuccessfully. I'm hoping this can
be accepted now so that we can clean up the timer drivers that are
used in both UP and SMP situations. Right now these drivers have to ignore
the timer setup callback on the boot CPU to avoid registering clockevents
twice. This is not very symmetric and causes convuluted code that does
the same thing in two places.

Patches based on v3.9-rc5. I'm still looking for Acks/Tested-by
on EXYNOS and PRIMA2.

[1] http://article.gmane.org/gmane.linux.ports.arm.kernel/145705

Note: A hotplug notifier is used by both x86 for the apb_timer (see 
apbt_cpuhp_notify) and by metag (see arch_timer_cpu_notify in
metag_generic.c) so this is not new.

Changes since v3:
 * New patch to fix SMP with dummy timers registered after a global timer
 * Push this_cpu_ptr lower to avoid preemptible false positive warnings
 * Collected acks/tested-bys

Changes since v2:
 * Bug fixes in smp_twd from Tony Lindgren's testing
 * Move smp_twd to use late_time_init hook
 * Collected Acks

Changes since v1:
 * Picked up Mark's generic dummy timer driver
 * Split out omap changes into new patch

Mark Rutland (1):
  clocksource: add generic dummy timer driver

Stephen Boyd (10):
  clockevents: Prefer CPU local devices over global devices
  ARM: smp: Remove duplicate dummy timer implementation
  ARM: smp_twd: Divorce smp_twd from local timer API
  ARM: OMAP2+: Divorce from local timer API
  ARM: EXYNOS4: Divorce mct from local timer API
  ARM: PRIMA2: Divorce timer-marco from local timer API
  ARM: msm: Divorce msm_timer from local timer API
  clocksource: time-armada-370-xp: Fix sparse warning
  clocksource: time-armada-370-xp: Divorce from local timer API
  ARM: smp: Remove local timer API

 arch/arm/Kconfig                         |  12 +--
 arch/arm/include/asm/localtimer.h        |  34 ---------
 arch/arm/kernel/smp.c                    |  87 ---------------------
 arch/arm/kernel/smp_twd.c                |  64 +++++++++++-----
 arch/arm/mach-exynos/mct.c               |  60 ++++++++++-----
 arch/arm/mach-msm/timer.c                | 127 +++++++++++++++++--------------
 arch/arm/mach-omap2/Kconfig              |   1 -
 arch/arm/mach-omap2/timer.c              |   7 --
 arch/arm/mach-prima2/timer-marco.c       | 100 +++++++++++++-----------
 drivers/clocksource/Makefile             |   1 +
 drivers/clocksource/dummy_timer.c        |  69 +++++++++++++++++
 drivers/clocksource/time-armada-370-xp.c |  92 +++++++++++-----------
 include/linux/time-armada-370-xp.h       |   4 +-
 kernel/time/tick-common.c                |   5 +-
 14 files changed, 327 insertions(+), 336 deletions(-)
 delete mode 100644 arch/arm/include/asm/localtimer.h
 create mode 100644 drivers/clocksource/dummy_timer.c

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Mon Apr  8 17:27:27 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Mon,  8 Apr 2013 14:27:27 -0700
Subject: [PATCHv4 05/11] ARM: OMAP2+: Divorce from local timer API
In-Reply-To: <1365456453-16297-1-git-send-email-sboyd@codeaurora.org>
References: <1365456453-16297-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1365456453-16297-6-git-send-email-sboyd@codeaurora.org>

Now that the TWD doesn't rely on the local timer API, OMAP can
stop selecting it in Kconfig and relying on the config option to
decide if it should call smp_twd functions.

Acked-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
Acked-by: Tony Lindgren <tony at atomide.com>
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 arch/arm/mach-omap2/Kconfig | 1 -
 arch/arm/mach-omap2/timer.c | 7 -------
 2 files changed, 8 deletions(-)

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 8111cd9..1b731e3 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -88,7 +88,6 @@ config ARCH_OMAP4
 	select CACHE_L2X0
 	select CPU_V7
 	select HAVE_SMP
-	select LOCAL_TIMERS if SMP
 	select OMAP_INTERCONNECT
 	select PL310_ERRATA_588369
 	select PL310_ERRATA_727915
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 2bdd4cf..c00a8f8 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -587,7 +587,6 @@ OMAP_SYS_GP_TIMER_INIT(3_am33xx, 1, OMAP4_MPU_SOURCE, "ti,timer-alwon",
 #ifdef CONFIG_ARCH_OMAP4
 OMAP_SYS_32K_TIMER_INIT(4, 1, OMAP4_32K_SOURCE, "ti,timer-alwon",
 			2, OMAP4_MPU_SOURCE);
-#ifdef CONFIG_LOCAL_TIMERS
 static DEFINE_TWD_LOCAL_TIMER(twd_local_timer, OMAP44XX_LOCAL_TWD_BASE, 29);
 void __init omap4_local_timer_init(void)
 {
@@ -606,12 +605,6 @@ void __init omap4_local_timer_init(void)
 			pr_err("twd_local_timer_register failed %d\n", err);
 	}
 }
-#else /* CONFIG_LOCAL_TIMERS */
-void __init omap4_local_timer_init(void)
-{
-	omap4_sync32k_timer_init();
-}
-#endif /* CONFIG_LOCAL_TIMERS */
 #endif /* CONFIG_ARCH_OMAP4 */
 
 #ifdef CONFIG_SOC_OMAP5
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Mon Apr  8 17:27:29 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Mon,  8 Apr 2013 14:27:29 -0700
Subject: [PATCHv4 07/11] ARM: PRIMA2: Divorce timer-marco from local timer API
In-Reply-To: <1365456453-16297-1-git-send-email-sboyd@codeaurora.org>
References: <1365456453-16297-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1365456453-16297-8-git-send-email-sboyd@codeaurora.org>

Separate the marco local timers from the local timer API. This
will allow us to remove ARM local timer support in the near future
and gets us closer to moving this driver to drivers/clocksource.

Cc: Barry Song <baohua.song at csr.com>
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 arch/arm/mach-prima2/timer-marco.c | 100 ++++++++++++++++++++-----------------
 1 file changed, 54 insertions(+), 46 deletions(-)

diff --git a/arch/arm/mach-prima2/timer-marco.c b/arch/arm/mach-prima2/timer-marco.c
index f4eea2e..123c89a 100644
--- a/arch/arm/mach-prima2/timer-marco.c
+++ b/arch/arm/mach-prima2/timer-marco.c
@@ -10,6 +10,7 @@
 #include <linux/interrupt.h>
 #include <linux/clockchips.h>
 #include <linux/clocksource.h>
+#include <linux/cpu.h>
 #include <linux/bitops.h>
 #include <linux/irq.h>
 #include <linux/clk.h>
@@ -18,7 +19,6 @@
 #include <linux/of_irq.h>
 #include <linux/of_address.h>
 #include <asm/sched_clock.h>
-#include <asm/localtimer.h>
 #include <asm/mach/time.h>
 
 #include "common.h"
@@ -154,13 +154,7 @@ static void sirfsoc_clocksource_resume(struct clocksource *cs)
 		BIT(1) | BIT(0), sirfsoc_timer_base + SIRFSOC_TIMER_64COUNTER_CTRL);
 }
 
-static struct clock_event_device sirfsoc_clockevent = {
-	.name = "sirfsoc_clockevent",
-	.rating = 200,
-	.features = CLOCK_EVT_FEAT_ONESHOT,
-	.set_mode = sirfsoc_timer_set_mode,
-	.set_next_event = sirfsoc_timer_set_next_event,
-};
+static struct clock_event_device __percpu *sirfsoc_clockevent;
 
 static struct clocksource sirfsoc_clocksource = {
 	.name = "sirfsoc_clocksource",
@@ -176,11 +170,8 @@ static struct irqaction sirfsoc_timer_irq = {
 	.name = "sirfsoc_timer0",
 	.flags = IRQF_TIMER | IRQF_NOBALANCING,
 	.handler = sirfsoc_timer_interrupt,
-	.dev_id = &sirfsoc_clockevent,
 };
 
-#ifdef CONFIG_LOCAL_TIMERS
-
 static struct irqaction sirfsoc_timer1_irq = {
 	.name = "sirfsoc_timer1",
 	.flags = IRQF_TIMER | IRQF_NOBALANCING,
@@ -189,56 +180,77 @@ static struct irqaction sirfsoc_timer1_irq = {
 
 static int __cpuinit sirfsoc_local_timer_setup(struct clock_event_device *ce)
 {
-	/* Use existing clock_event for cpu 0 */
-	if (!smp_processor_id())
-		return 0;
+	int cpu = smp_processor_id();
+	struct irqaction *action;
+
+	if (cpu == 0)
+		action = &sirfsoc_timer_irq;
+	else
+		action = &sirfsoc_timer1_irq;
 
-	ce->irq = sirfsoc_timer1_irq.irq;
+	ce->irq = action->irq;
 	ce->name = "local_timer";
-	ce->features = sirfsoc_clockevent.features;
-	ce->rating = sirfsoc_clockevent.rating;
+	ce->features = CLOCK_EVT_FEAT_ONESHOT;
+	ce->rating = 200;
 	ce->set_mode = sirfsoc_timer_set_mode;
 	ce->set_next_event = sirfsoc_timer_set_next_event;
-	ce->shift = sirfsoc_clockevent.shift;
-	ce->mult = sirfsoc_clockevent.mult;
-	ce->max_delta_ns = sirfsoc_clockevent.max_delta_ns;
-	ce->min_delta_ns = sirfsoc_clockevent.min_delta_ns;
+	clockevents_calc_mult_shift(ce, CLOCK_TICK_RATE, 60);
+	ce->max_delta_ns = clockevent_delta2ns(-2, ce);
+	ce->min_delta_ns = clockevent_delta2ns(2, ce);
+	ce->cpumask = cpumask_of(cpu);
 
-	sirfsoc_timer1_irq.dev_id = ce;
-	BUG_ON(setup_irq(ce->irq, &sirfsoc_timer1_irq));
-	irq_set_affinity(sirfsoc_timer1_irq.irq, cpumask_of(1));
+	action->dev_id = ce;
+	BUG_ON(setup_irq(ce->irq, action));
+	irq_set_affinity(action->irq, cpumask_of(cpu));
 
 	clockevents_register_device(ce);
 	return 0;
 }
 
-static void sirfsoc_local_timer_stop(struct clock_event_device *ce)
+static void __cpuinit sirfsoc_local_timer_stop(struct clock_event_device *ce)
 {
+	int cpu = smp_processor_id();
+
 	sirfsoc_timer_count_disable(1);
 
-	remove_irq(sirfsoc_timer1_irq.irq, &sirfsoc_timer1_irq);
+	if (cpu == 0)
+		remove_irq(sirfsoc_timer_irq.irq, &sirfsoc_timer_irq);
+	else
+		remove_irq(sirfsoc_timer1_irq.irq, &sirfsoc_timer1_irq);
 }
 
-static struct local_timer_ops sirfsoc_local_timer_ops __cpuinitdata = {
-	.setup	= sirfsoc_local_timer_setup,
-	.stop	= sirfsoc_local_timer_stop,
+static int __cpuinit sirfsoc_cpu_notify(struct notifier_block *self,
+					   unsigned long action, void *hcpu)
+{
+	/*
+	 * Dereference cpu pointer in each case to avoid spurious
+	 * preemptible warnings
+	 */
+	switch (action & ~CPU_TASKS_FROZEN) {
+	case CPU_STARTING:
+		sirfsoc_local_timer_setup(this_cpu_ptr(sirfsoc_clockevent));
+		break;
+	case CPU_DYING:
+		sirfsoc_local_timer_stop(this_cpu_ptr(sirfsoc_clockevent));
+		break;
+	}
+
+	return NOTIFY_OK;
+}
+
+static struct notifier_block sirfsoc_cpu_nb __cpuinitdata = {
+	.notifier_call = sirfsoc_cpu_notify,
 };
-#endif /* CONFIG_LOCAL_TIMERS */
 
 static void __init sirfsoc_clockevent_init(void)
 {
-	clockevents_calc_mult_shift(&sirfsoc_clockevent, CLOCK_TICK_RATE, 60);
-
-	sirfsoc_clockevent.max_delta_ns =
-		clockevent_delta2ns(-2, &sirfsoc_clockevent);
-	sirfsoc_clockevent.min_delta_ns =
-		clockevent_delta2ns(2, &sirfsoc_clockevent);
-
-	sirfsoc_clockevent.cpumask = cpumask_of(0);
-	clockevents_register_device(&sirfsoc_clockevent);
-#ifdef CONFIG_LOCAL_TIMERS
-	local_timer_register(&sirfsoc_local_timer_ops);
-#endif
+	sirfsoc_clockevent = alloc_percpu(struct clock_event_device);
+	BUG_ON(!sirfsoc_clockevent);
+
+	BUG_ON(register_cpu_notifier(&sirfsoc_cpu_nb));
+
+	/* Immediately configure the timer on the boot CPU */
+	sirfsoc_local_timer_setup(this_cpu_ptr(sirfsoc_clockevent));
 }
 
 /* initialize the kernel jiffy timer source */
@@ -281,8 +293,6 @@ void __init sirfsoc_marco_timer_init(void)
 
 	BUG_ON(clocksource_register_hz(&sirfsoc_clocksource, CLOCK_TICK_RATE));
 
-	BUG_ON(setup_irq(sirfsoc_timer_irq.irq, &sirfsoc_timer_irq));
-
 	sirfsoc_clockevent_init();
 }
 
@@ -306,11 +316,9 @@ static void __init sirfsoc_of_timer_map(void)
 	if (!sirfsoc_timer_irq.irq)
 		panic("No irq passed for timer0 via DT\n");
 
-#ifdef CONFIG_LOCAL_TIMERS
 	sirfsoc_timer1_irq.irq = irq_of_parse_and_map(np, 1);
 	if (!sirfsoc_timer1_irq.irq)
 		panic("No irq passed for timer1 via DT\n");
-#endif
 
 	of_node_put(np);
 }
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Mon Apr  8 17:27:25 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Mon,  8 Apr 2013 14:27:25 -0700
Subject: [PATCHv4 03/11] ARM: smp: Remove duplicate dummy timer implementation
In-Reply-To: <1365456453-16297-1-git-send-email-sboyd@codeaurora.org>
References: <1365456453-16297-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1365456453-16297-4-git-send-email-sboyd@codeaurora.org>

Drop ARM's version of the dummy timer now that we have a generic
implementation in drivers/clocksource.

Cc: Russell King <linux at arm.linux.org.uk>
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 arch/arm/kernel/smp.c | 22 ++--------------------
 1 file changed, 2 insertions(+), 20 deletions(-)

diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
index 79078ed..4de4d14 100644
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -469,24 +469,6 @@ void tick_broadcast(const struct cpumask *mask)
 }
 #endif
 
-static void broadcast_timer_set_mode(enum clock_event_mode mode,
-	struct clock_event_device *evt)
-{
-}
-
-static void __cpuinit broadcast_timer_setup(struct clock_event_device *evt)
-{
-	evt->name	= "dummy_timer";
-	evt->features	= CLOCK_EVT_FEAT_ONESHOT |
-			  CLOCK_EVT_FEAT_PERIODIC |
-			  CLOCK_EVT_FEAT_DUMMY;
-	evt->rating	= 100;
-	evt->mult	= 1;
-	evt->set_mode	= broadcast_timer_set_mode;
-
-	clockevents_register_device(evt);
-}
-
 static struct local_timer_ops *lt_ops;
 
 #ifdef CONFIG_LOCAL_TIMERS
@@ -510,8 +492,8 @@ static void __cpuinit percpu_timer_setup(void)
 
 	evt->cpumask = cpumask_of(cpu);
 
-	if (!lt_ops || lt_ops->setup(evt))
-		broadcast_timer_setup(evt);
+	if (lt_ops)
+		lt_ops->setup(evt);
 }
 
 #ifdef CONFIG_HOTPLUG_CPU
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Mon Apr  8 17:27:33 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Mon,  8 Apr 2013 14:27:33 -0700
Subject: [PATCHv4 11/11] ARM: smp: Remove local timer API
In-Reply-To: <1365456453-16297-1-git-send-email-sboyd@codeaurora.org>
References: <1365456453-16297-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1365456453-16297-12-git-send-email-sboyd@codeaurora.org>

There are no more users of this API, remove it.

Cc: Russell King <linux at arm.linux.org.uk>
Acked-by: Tony Lindgren <tony at atomide.com>
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 arch/arm/Kconfig                  | 10 ------
 arch/arm/include/asm/localtimer.h | 34 -------------------
 arch/arm/kernel/smp.c             | 69 ---------------------------------------
 3 files changed, 113 deletions(-)
 delete mode 100644 arch/arm/include/asm/localtimer.h

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index ee6bb9d..f97a980 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1643,16 +1643,6 @@ config ARM_PSCI
 	  0022A ("Power State Coordination Interface System Software on
 	  ARM processors").
 
-config LOCAL_TIMERS
-	bool "Use local timer interrupts"
-	depends on SMP
-	default y
-	help
-	  Enable support for local timers on SMP platforms, rather then the
-	  legacy IPI broadcast method.  Local timers allows the system
-	  accounting to be spread across the timer interval, preventing a
-	  "thundering herd" at every timer tick.
-
 # The GPIO number here must be sorted by descending number. In case of
 # a multiplatform kernel, we just want the highest value required by the
 # selected platforms.
diff --git a/arch/arm/include/asm/localtimer.h b/arch/arm/include/asm/localtimer.h
deleted file mode 100644
index f77ffc1..0000000
--- a/arch/arm/include/asm/localtimer.h
+++ /dev/null
@@ -1,34 +0,0 @@
-/*
- *  arch/arm/include/asm/localtimer.h
- *
- *  Copyright (C) 2004-2005 ARM Ltd.
- *
- * 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.
- */
-#ifndef __ASM_ARM_LOCALTIMER_H
-#define __ASM_ARM_LOCALTIMER_H
-
-#include <linux/errno.h>
-
-struct clock_event_device;
-
-struct local_timer_ops {
-	int  (*setup)(struct clock_event_device *);
-	void (*stop)(struct clock_event_device *);
-};
-
-#ifdef CONFIG_LOCAL_TIMERS
-/*
- * Register a local timer driver
- */
-int local_timer_register(struct local_timer_ops *);
-#else
-static inline int local_timer_register(struct local_timer_ops *ops)
-{
-	return -ENXIO;
-}
-#endif
-
-#endif
diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
index 4de4d14..4c49138 100644
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -41,7 +41,6 @@
 #include <asm/sections.h>
 #include <asm/tlbflush.h>
 #include <asm/ptrace.h>
-#include <asm/localtimer.h>
 #include <asm/smp_plat.h>
 #include <asm/virt.h>
 #include <asm/mach/arch.h>
@@ -133,8 +132,6 @@ int __cpuinit boot_secondary(unsigned int cpu, struct task_struct *idle)
 }
 
 #ifdef CONFIG_HOTPLUG_CPU
-static void percpu_timer_stop(void);
-
 static int platform_cpu_kill(unsigned int cpu)
 {
 	if (smp_ops.cpu_kill)
@@ -178,11 +175,6 @@ int __cpuinit __cpu_disable(void)
 	migrate_irqs();
 
 	/*
-	 * Stop the local timer for this CPU.
-	 */
-	percpu_timer_stop();
-
-	/*
 	 * Flush user cache and TLB mappings, and then remove this CPU
 	 * from the vm mask set of all processes.
 	 *
@@ -269,8 +261,6 @@ static void __cpuinit smp_store_cpu_info(unsigned int cpuid)
 	store_cpu_topology(cpuid);
 }
 
-static void percpu_timer_setup(void);
-
 /*
  * This is the secondary CPU boot entry.  We're using this CPUs
  * idle thread stack, but a set of temporary page tables.
@@ -325,11 +315,6 @@ asmlinkage void __cpuinit secondary_start_kernel(void)
 	set_cpu_online(cpu, true);
 	complete(&cpu_running);
 
-	/*
-	 * Setup the percpu timer for this CPU.
-	 */
-	percpu_timer_setup();
-
 	local_irq_enable();
 	local_fiq_enable();
 
@@ -376,12 +361,6 @@ void __init smp_prepare_cpus(unsigned int max_cpus)
 		max_cpus = ncores;
 	if (ncores > 1 && max_cpus) {
 		/*
-		 * Enable the local timer or broadcast device for the
-		 * boot CPU, but only if we have more than one CPU.
-		 */
-		percpu_timer_setup();
-
-		/*
 		 * Initialise the present map, which describes the set of CPUs
 		 * actually populated at the present time. A platform should
 		 * re-initialize the map in the platforms smp_prepare_cpus()
@@ -457,11 +436,6 @@ u64 smp_irq_stat_cpu(unsigned int cpu)
 	return sum;
 }
 
-/*
- * Timer (local or broadcast) support
- */
-static DEFINE_PER_CPU(struct clock_event_device, percpu_clockevent);
-
 #ifdef CONFIG_GENERIC_CLOCKEVENTS_BROADCAST
 void tick_broadcast(const struct cpumask *mask)
 {
@@ -469,49 +443,6 @@ void tick_broadcast(const struct cpumask *mask)
 }
 #endif
 
-static struct local_timer_ops *lt_ops;
-
-#ifdef CONFIG_LOCAL_TIMERS
-int local_timer_register(struct local_timer_ops *ops)
-{
-	if (!is_smp() || !setup_max_cpus)
-		return -ENXIO;
-
-	if (lt_ops)
-		return -EBUSY;
-
-	lt_ops = ops;
-	return 0;
-}
-#endif
-
-static void __cpuinit percpu_timer_setup(void)
-{
-	unsigned int cpu = smp_processor_id();
-	struct clock_event_device *evt = &per_cpu(percpu_clockevent, cpu);
-
-	evt->cpumask = cpumask_of(cpu);
-
-	if (lt_ops)
-		lt_ops->setup(evt);
-}
-
-#ifdef CONFIG_HOTPLUG_CPU
-/*
- * The generic clock events code purposely does not stop the local timer
- * on CPU_DEAD/CPU_DEAD_FROZEN hotplug events, so we have to do it
- * manually here.
- */
-static void percpu_timer_stop(void)
-{
-	unsigned int cpu = smp_processor_id();
-	struct clock_event_device *evt = &per_cpu(percpu_clockevent, cpu);
-
-	if (lt_ops)
-		lt_ops->stop(evt);
-}
-#endif
-
 static DEFINE_RAW_SPINLOCK(stop_lock);
 
 /*
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Mon Apr  8 17:27:30 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Mon,  8 Apr 2013 14:27:30 -0700
Subject: [PATCHv4 08/11] ARM: msm: Divorce msm_timer from local timer API
In-Reply-To: <1365456453-16297-1-git-send-email-sboyd@codeaurora.org>
References: <1365456453-16297-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1365456453-16297-9-git-send-email-sboyd@codeaurora.org>

Separate the msm_timer from the local timer API. This will allow
us to remove ARM local timer support in the near future and gets
us closer to moving this driver to drivers/clocksource.

Acked-by: David Brown <davidb at codeaurora.org>
Cc: Daniel Walker <dwalker at fifo99.com>
Cc: Bryan Huntsman <bryanh at codeaurora.org>
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 arch/arm/mach-msm/timer.c | 127 +++++++++++++++++++++++++---------------------
 1 file changed, 69 insertions(+), 58 deletions(-)

diff --git a/arch/arm/mach-msm/timer.c b/arch/arm/mach-msm/timer.c
index 2969027..f4bc4a6 100644
--- a/arch/arm/mach-msm/timer.c
+++ b/arch/arm/mach-msm/timer.c
@@ -16,6 +16,7 @@
 
 #include <linux/clocksource.h>
 #include <linux/clockchips.h>
+#include <linux/cpu.h>
 #include <linux/init.h>
 #include <linux/interrupt.h>
 #include <linux/irq.h>
@@ -25,7 +26,6 @@
 #include <linux/of_irq.h>
 
 #include <asm/mach/time.h>
-#include <asm/localtimer.h>
 #include <asm/sched_clock.h>
 
 #include "common.h"
@@ -46,7 +46,7 @@ static void __iomem *event_base;
 
 static irqreturn_t msm_timer_interrupt(int irq, void *dev_id)
 {
-	struct clock_event_device *evt = *(struct clock_event_device **)dev_id;
+	struct clock_event_device *evt = dev_id;
 	/* Stop the timer tick */
 	if (evt->mode == CLOCK_EVT_MODE_ONESHOT) {
 		u32 ctrl = readl_relaxed(event_base + TIMER_ENABLE);
@@ -90,18 +90,7 @@ static void msm_timer_set_mode(enum clock_event_mode mode,
 	writel_relaxed(ctrl, event_base + TIMER_ENABLE);
 }
 
-static struct clock_event_device msm_clockevent = {
-	.name		= "gp_timer",
-	.features	= CLOCK_EVT_FEAT_ONESHOT,
-	.rating		= 200,
-	.set_next_event	= msm_timer_set_next_event,
-	.set_mode	= msm_timer_set_mode,
-};
-
-static union {
-	struct clock_event_device *evt;
-	struct clock_event_device * __percpu *percpu_evt;
-} msm_evt;
+static struct clock_event_device __percpu *msm_evt;
 
 static void __iomem *source_base;
 
@@ -127,40 +116,68 @@ static struct clocksource msm_clocksource = {
 	.flags	= CLOCK_SOURCE_IS_CONTINUOUS,
 };
 
-#ifdef CONFIG_LOCAL_TIMERS
+static int msm_timer_irq;
+static int msm_timer_has_ppi;
+
 static int __cpuinit msm_local_timer_setup(struct clock_event_device *evt)
 {
-	/* Use existing clock_event for cpu 0 */
-	if (!smp_processor_id())
-		return 0;
+	int cpu = smp_processor_id();
+	int err;
 
 	writel_relaxed(0, event_base + TIMER_ENABLE);
 	writel_relaxed(0, event_base + TIMER_CLEAR);
 	writel_relaxed(~0, event_base + TIMER_MATCH_VAL);
-	evt->irq = msm_clockevent.irq;
+	evt->irq = msm_timer_irq;
 	evt->name = "local_timer";
-	evt->features = msm_clockevent.features;
-	evt->rating = msm_clockevent.rating;
+	evt->features = CLOCK_EVT_FEAT_ONESHOT;
+	evt->rating = 200;
 	evt->set_mode = msm_timer_set_mode;
 	evt->set_next_event = msm_timer_set_next_event;
+	evt->cpumask = cpumask_of(cpu);
+
+	clockevents_config_and_register(evt, GPT_HZ, 4, 0xffffffff);
+
+	if (msm_timer_has_ppi) {
+		enable_percpu_irq(evt->irq, IRQ_TYPE_EDGE_RISING);
+	} else {
+		err = request_irq(evt->irq, msm_timer_interrupt,
+				IRQF_TIMER | IRQF_NOBALANCING |
+				IRQF_TRIGGER_RISING, "gp_timer", evt);
+		if (err)
+			pr_err("request_irq failed\n");
+	}
 
-	*__this_cpu_ptr(msm_evt.percpu_evt) = evt;
-	clockevents_config_and_register(evt, GPT_HZ, 4, 0xf0000000);
-	enable_percpu_irq(evt->irq, IRQ_TYPE_EDGE_RISING);
 	return 0;
 }
 
-static void msm_local_timer_stop(struct clock_event_device *evt)
+static void __cpuinit msm_local_timer_stop(struct clock_event_device *evt)
 {
 	evt->set_mode(CLOCK_EVT_MODE_UNUSED, evt);
 	disable_percpu_irq(evt->irq);
 }
 
-static struct local_timer_ops msm_local_timer_ops __cpuinitdata = {
-	.setup	= msm_local_timer_setup,
-	.stop	= msm_local_timer_stop,
+static int __cpuinit msm_timer_cpu_notify(struct notifier_block *self,
+					   unsigned long action, void *hcpu)
+{
+	/*
+	 * Dereference cpu pointer in each case to avoid spurious
+	 * preemptible warnings
+	 */
+	switch (action & ~CPU_TASKS_FROZEN) {
+	case CPU_STARTING:
+		msm_local_timer_setup(this_cpu_ptr(msm_evt));
+		break;
+	case CPU_DYING:
+		msm_local_timer_stop(this_cpu_ptr(msm_evt));
+		break;
+	}
+
+	return NOTIFY_OK;
+}
+
+static struct notifier_block msm_timer_cpu_nb __cpuinitdata = {
+	.notifier_call = msm_timer_cpu_notify,
 };
-#endif /* CONFIG_LOCAL_TIMERS */
 
 static notrace u32 msm_sched_clock_read(void)
 {
@@ -170,41 +187,35 @@ static notrace u32 msm_sched_clock_read(void)
 static void __init msm_timer_init(u32 dgt_hz, int sched_bits, int irq,
 				  bool percpu)
 {
-	struct clock_event_device *ce = &msm_clockevent;
 	struct clocksource *cs = &msm_clocksource;
-	int res;
+	int res = 0;
 
-	writel_relaxed(0, event_base + TIMER_ENABLE);
-	writel_relaxed(0, event_base + TIMER_CLEAR);
-	writel_relaxed(~0, event_base + TIMER_MATCH_VAL);
-	ce->cpumask = cpumask_of(0);
-	ce->irq = irq;
-
-	clockevents_config_and_register(ce, GPT_HZ, 4, 0xffffffff);
-	if (percpu) {
-		msm_evt.percpu_evt = alloc_percpu(struct clock_event_device *);
-		if (!msm_evt.percpu_evt) {
-			pr_err("memory allocation failed for %s\n", ce->name);
+	msm_timer_irq = irq;
+	msm_timer_has_ppi = percpu;
+
+	msm_evt = alloc_percpu(struct clock_event_device);
+	if (!msm_evt) {
+		pr_err("memory allocation failed for clockevents\n");
+		goto err;
+	}
+
+	if (percpu)
+		res = request_percpu_irq(irq, msm_timer_interrupt,
+					 "gp_timer", msm_evt);
+
+	if (res) {
+		pr_err("request_percpu_irq failed\n");
+	} else {
+		res = register_cpu_notifier(&msm_timer_cpu_nb);
+		if (res) {
+			free_percpu_irq(irq, msm_evt);
 			goto err;
 		}
-		*__this_cpu_ptr(msm_evt.percpu_evt) = ce;
-		res = request_percpu_irq(ce->irq, msm_timer_interrupt,
-					 ce->name, msm_evt.percpu_evt);
-		if (!res) {
-			enable_percpu_irq(ce->irq, IRQ_TYPE_EDGE_RISING);
-#ifdef CONFIG_LOCAL_TIMERS
-			local_timer_register(&msm_local_timer_ops);
-#endif
-		}
-	} else {
-		msm_evt.evt = ce;
-		res = request_irq(ce->irq, msm_timer_interrupt,
-				  IRQF_TIMER | IRQF_NOBALANCING |
-				  IRQF_TRIGGER_RISING, ce->name, &msm_evt.evt);
+
+		/* Immediately configure the timer on the boot CPU */
+		msm_local_timer_setup(__this_cpu_ptr(msm_evt));
 	}
 
-	if (res)
-		pr_err("request_irq failed for %s\n", ce->name);
 err:
 	writel_relaxed(TIMER_ENABLE_EN, source_base + TIMER_ENABLE);
 	res = clocksource_register_hz(cs, dgt_hz);
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Mon Apr  8 17:27:32 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Mon,  8 Apr 2013 14:27:32 -0700
Subject: [PATCHv4 10/11] clocksource: time-armada-370-xp: Divorce from local
 timer API
In-Reply-To: <1365456453-16297-1-git-send-email-sboyd@codeaurora.org>
References: <1365456453-16297-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1365456453-16297-11-git-send-email-sboyd@codeaurora.org>

Separate the armada 370xp local timers from the local timer API.
This will allow us to remove ARM local timer support in the near
future and makes this driver multi-architecture friendly.

Acked-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
Tested-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 drivers/clocksource/time-armada-370-xp.c | 89 +++++++++++++++-----------------
 1 file changed, 41 insertions(+), 48 deletions(-)

diff --git a/drivers/clocksource/time-armada-370-xp.c b/drivers/clocksource/time-armada-370-xp.c
index efe4aef..8e6296d 100644
--- a/drivers/clocksource/time-armada-370-xp.c
+++ b/drivers/clocksource/time-armada-370-xp.c
@@ -19,6 +19,7 @@
 #include <linux/platform_device.h>
 #include <linux/kernel.h>
 #include <linux/clk.h>
+#include <linux/cpu.h>
 #include <linux/timer.h>
 #include <linux/clockchips.h>
 #include <linux/interrupt.h>
@@ -31,7 +32,6 @@
 #include <linux/time-armada-370-xp.h>
 
 #include <asm/sched_clock.h>
-#include <asm/localtimer.h>
 /*
  * Timer block registers.
  */
@@ -70,7 +70,7 @@ static bool timer25Mhz = true;
  */
 static u32 ticks_per_jiffy;
 
-static struct clock_event_device __percpu **percpu_armada_370_xp_evt;
+static struct clock_event_device __percpu *armada_370_xp_evt;
 
 static u32 notrace armada_370_xp_read_sched_clock(void)
 {
@@ -143,21 +143,14 @@ armada_370_xp_clkevt_mode(enum clock_event_mode mode,
 	}
 }
 
-static struct clock_event_device armada_370_xp_clkevt = {
-	.name		= "armada_370_xp_per_cpu_tick",
-	.features	= CLOCK_EVT_FEAT_ONESHOT | CLOCK_EVT_FEAT_PERIODIC,
-	.shift		= 32,
-	.rating		= 300,
-	.set_next_event	= armada_370_xp_clkevt_next_event,
-	.set_mode	= armada_370_xp_clkevt_mode,
-};
+static int armada_370_xp_clkevt_irq;
 
 static irqreturn_t armada_370_xp_timer_interrupt(int irq, void *dev_id)
 {
 	/*
 	 * ACK timer interrupt and call event handler.
 	 */
-	struct clock_event_device *evt = *(struct clock_event_device **)dev_id;
+	struct clock_event_device *evt = dev_id;
 
 	writel(TIMER0_CLR_MASK, local_base + LCL_TIMER_EVENTS_STATUS);
 	evt->event_handler(evt);
@@ -173,42 +166,55 @@ static int __cpuinit armada_370_xp_timer_setup(struct clock_event_device *evt)
 	u32 u;
 	int cpu = smp_processor_id();
 
-	/* Use existing clock_event for cpu 0 */
-	if (!smp_processor_id())
-		return 0;
-
 	u = readl(local_base + TIMER_CTRL_OFF);
 	if (timer25Mhz)
 		writel(u | TIMER0_25MHZ, local_base + TIMER_CTRL_OFF);
 	else
 		writel(u & ~TIMER0_25MHZ, local_base + TIMER_CTRL_OFF);
 
-	evt->name		= armada_370_xp_clkevt.name;
-	evt->irq		= armada_370_xp_clkevt.irq;
-	evt->features		= armada_370_xp_clkevt.features;
-	evt->shift		= armada_370_xp_clkevt.shift;
-	evt->rating		= armada_370_xp_clkevt.rating,
+	evt->name		= "armada_370_xp_per_cpu_tick",
+	evt->features		= CLOCK_EVT_FEAT_ONESHOT |
+				  CLOCK_EVT_FEAT_PERIODIC;
+	evt->shift		= 32,
+	evt->rating		= 300,
 	evt->set_next_event	= armada_370_xp_clkevt_next_event,
 	evt->set_mode		= armada_370_xp_clkevt_mode,
+	evt->irq		= armada_370_xp_clkevt_irq;
 	evt->cpumask		= cpumask_of(cpu);
 
-	*__this_cpu_ptr(percpu_armada_370_xp_evt) = evt;
-
 	clockevents_config_and_register(evt, timer_clk, 1, 0xfffffffe);
 	enable_percpu_irq(evt->irq, 0);
 
 	return 0;
 }
 
-static void  armada_370_xp_timer_stop(struct clock_event_device *evt)
+static void __cpuinit armada_370_xp_timer_stop(struct clock_event_device *evt)
 {
 	evt->set_mode(CLOCK_EVT_MODE_UNUSED, evt);
 	disable_percpu_irq(evt->irq);
 }
 
-static struct local_timer_ops armada_370_xp_local_timer_ops __cpuinitdata = {
-	.setup	= armada_370_xp_timer_setup,
-	.stop	=  armada_370_xp_timer_stop,
+static int __cpuinit armada_370_xp_timer_cpu_notify(struct notifier_block *self,
+					   unsigned long action, void *hcpu)
+{
+	/*
+	 * Dereference cpu pointer in each case to avoid spurious
+	 * preemptible warnings
+	 */
+	switch (action & ~CPU_TASKS_FROZEN) {
+	case CPU_STARTING:
+		armada_370_xp_timer_setup(this_cpu_ptr(armada_370_xp_evt));
+		break;
+	case CPU_DYING:
+		armada_370_xp_timer_stop(this_cpu_ptr(armada_370_xp_evt));
+		break;
+	}
+
+	return NOTIFY_OK;
+}
+
+static struct notifier_block armada_370_xp_timer_cpu_nb __cpuinitdata = {
+	.notifier_call = armada_370_xp_timer_cpu_notify,
 };
 
 void __init armada_370_xp_timer_init(void)
@@ -224,9 +230,6 @@ void __init armada_370_xp_timer_init(void)
 
 	if (of_find_property(np, "marvell,timer-25Mhz", NULL)) {
 		/* The fixed 25MHz timer is available so let's use it */
-		u = readl(local_base + TIMER_CTRL_OFF);
-		writel(u | TIMER0_25MHZ,
-		       local_base + TIMER_CTRL_OFF);
 		u = readl(timer_base + TIMER_CTRL_OFF);
 		writel(u | TIMER0_25MHZ,
 		       timer_base + TIMER_CTRL_OFF);
@@ -236,9 +239,6 @@ void __init armada_370_xp_timer_init(void)
 		struct clk *clk = of_clk_get(np, 0);
 		WARN_ON(IS_ERR(clk));
 		rate =  clk_get_rate(clk);
-		u = readl(local_base + TIMER_CTRL_OFF);
-		writel(u & ~(TIMER0_25MHZ),
-		       local_base + TIMER_CTRL_OFF);
 
 		u = readl(timer_base + TIMER_CTRL_OFF);
 		writel(u & ~(TIMER0_25MHZ),
@@ -252,7 +252,7 @@ void __init armada_370_xp_timer_init(void)
 	 * We use timer 0 as clocksource, and private(local) timer 0
 	 * for clockevents
 	 */
-	armada_370_xp_clkevt.irq = irq_of_parse_and_map(np, 4);
+	armada_370_xp_clkevt_irq = irq_of_parse_and_map(np, 4);
 
 	ticks_per_jiffy = (timer_clk + HZ / 2) / HZ;
 
@@ -277,26 +277,19 @@ void __init armada_370_xp_timer_init(void)
 			      "armada_370_xp_clocksource",
 			      timer_clk, 300, 32, clocksource_mmio_readl_down);
 
-	/* Register the clockevent on the private timer of CPU 0 */
-	armada_370_xp_clkevt.cpumask = cpumask_of(0);
-	clockevents_config_and_register(&armada_370_xp_clkevt,
-					timer_clk, 1, 0xfffffffe);
+	register_cpu_notifier(&armada_370_xp_timer_cpu_nb);
 
-	percpu_armada_370_xp_evt = alloc_percpu(struct clock_event_device *);
+	armada_370_xp_evt = alloc_percpu(struct clock_event_device);
 
 
 	/*
 	 * Setup clockevent timer (interrupt-driven).
 	 */
-	*__this_cpu_ptr(percpu_armada_370_xp_evt) = &armada_370_xp_clkevt;
-	res = request_percpu_irq(armada_370_xp_clkevt.irq,
+	res = request_percpu_irq(armada_370_xp_clkevt_irq,
 				armada_370_xp_timer_interrupt,
-				armada_370_xp_clkevt.name,
-				percpu_armada_370_xp_evt);
-	if (!res) {
-		enable_percpu_irq(armada_370_xp_clkevt.irq, 0);
-#ifdef CONFIG_LOCAL_TIMERS
-		local_timer_register(&armada_370_xp_local_timer_ops);
-#endif
-	}
+				"armada_370_xp_per_cpu_tick",
+				armada_370_xp_evt);
+	/* Immediately configure the timer on the boot CPU */
+	if (!res)
+		armada_370_xp_timer_setup(this_cpu_ptr(armada_370_xp_evt));
 }
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From arnd at arndb.de  Mon Apr  8 17:29:07 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 8 Apr 2013 23:29:07 +0200
Subject: [RFC PATCH arm: initial TI-Nspire support]
In-Reply-To: <op.wu8ng3wyu7prd4@fabians-laptop.fritz.box>
References: <6FE4B33E-A503-4A75-AEED-831CB2C06D83@gmail.com>
 <201304082138.15875.arnd@arndb.de>
 <op.wu8ng3wyu7prd4@fabians-laptop.fritz.box>
Message-ID: <201304082329.08105.arnd@arndb.de>

On Monday 08 April 2013, Fabian Vogt wrote:
> Yes, I've heard that before, but than it would work/not work independently
> of NO_HZ. Can printk's be executet within console_lock() ..  
> console_unlock() blocks?

I think it's legal to call printk in that case, but the message will
not be printed until you reach the console_unlock()

> If not, it could be fb_notifier_call_chain, too, but that wouldn't be  
> likely at all.
> I also tried spinlock/mutex debugging and soft lockup detection,
> but neither of them outputs anything.

Unfortunately, lockdep does not help with console_lock, since that
is a weird semaphore variant, not a standard mutex or spinlock.

	Arnd


From arnd at arndb.de  Mon Apr  8 17:31:30 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 8 Apr 2013 23:31:30 +0200
Subject: [PATCHv7 08/17] pci: PCIe driver for Marvell Armada 370/XP systems
In-Reply-To: <CAErSpo7fGPe3wFha36kNMxeRP4gBpBWgfw85aTLey-DSz2ZYew@mail.gmail.com>
References: <1364395234-11195-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1364395234-11195-9-git-send-email-thomas.petazzoni@free-electrons.com>
 <CAErSpo7fGPe3wFha36kNMxeRP4gBpBWgfw85aTLey-DSz2ZYew@mail.gmail.com>
Message-ID: <201304082331.30809.arnd@arndb.de>

On Monday 08 April 2013, Bjorn Helgaas wrote:
> On Wed, Mar 27, 2013 at 8:40 AM, Thomas Petazzoni
> 
> > diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
> > new file mode 100644
> > index 0000000..3ad563f
> > --- /dev/null
> > +++ b/drivers/pci/host/Makefile
> > @@ -0,0 +1,4 @@
> > +obj-$(CONFIG_PCI_MVEBU) += pci-mvebu.o
> > +CFLAGS_pci-mvebu.o += \
> > +       -I$(srctree)/arch/arm/plat-orion/include \
> > +       -I$(srctree)/arch/arm/mach-mvebu/include
> 
> Too bad to have to adjust CFLAGS here.  Seems like I remember earlier
> discussion, but I didn't pay much attention, and if this is the best
> we can do, I guess it's OK.

I'm pretty sure I NAK'ed this part. I'm surprised it's still there.


	Arnd


From sergei.shtylyov at cogentembedded.com  Mon Apr  8 17:31:10 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Tue, 9 Apr 2013 01:31:10 +0400
Subject: [PATCH v2 6/9] rcar-phy: correct base address
Message-ID: <201304090131.11208.sergei.shtylyov@cogentembedded.com>

The memory region that is used by the driver overlaps EHCI and OHCI  register
regions for absolutely no reason now  -- fix it  by adding offset of 0x800 to
the base address, changing the register #define's accordingly. This has extra
positive effect that we now can use devm_ioremap_resource()...

Note that the driver and the SoC code have to be in one patch to keep the code
bisectable...

Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

---
Changes since the original posting:
- added a note about bisectability to the changelog.

 arch/arm/mach-shmobile/setup-r8a7779.c |    2 +-
 drivers/usb/phy/rcar-phy.c             |   28 ++++++++++------------------
 2 files changed, 11 insertions(+), 19 deletions(-)

Index: renesas/arch/arm/mach-shmobile/setup-r8a7779.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/setup-r8a7779.c
+++ renesas/arch/arm/mach-shmobile/setup-r8a7779.c
@@ -401,7 +401,7 @@ static struct platform_device sata_devic
 /* USB PHY */
 static struct resource usb_phy_resources[] = {
 	[0] = {
-		.start		= 0xffe70000,
+		.start		= 0xffe70800,
 		.end		= 0xffe70900 - 1,
 		.flags		= IORESOURCE_MEM,
 	},
Index: renesas/drivers/usb/phy/rcar-phy.c
===================================================================
--- renesas.orig/drivers/usb/phy/rcar-phy.c
+++ renesas/drivers/usb/phy/rcar-phy.c
@@ -16,13 +16,13 @@
 #include <linux/spinlock.h>
 #include <linux/module.h>
 
-/* USBH common register */
-#define USBPCTRL0	0x0800
-#define USBPCTRL1	0x0804
-#define USBST		0x0808
-#define USBEH0		0x080C
-#define USBOH0		0x081C
-#define USBCTL0		0x0858
+/* REGS block */
+#define USBPCTRL0	0x00
+#define USBPCTRL1	0x04
+#define USBST		0x08
+#define USBEH0		0x0C
+#define USBOH0		0x1C
+#define USBCTL0		0x58
 
 /* USBPCTRL1 */
 #define PHY_RST		(1 << 2)
@@ -139,17 +139,9 @@ static int rcar_usb_phy_probe(struct pla
 		return -EINVAL;
 	}
 
-	/*
-	 * CAUTION
-	 *
-	 * Because this phy address is also mapped under OHCI/EHCI address area,
-	 * this driver can't use devm_request_and_ioremap(dev, res) here
-	 */
-	reg0 = devm_ioremap_nocache(dev, res0->start, resource_size(res0));
-	if (!reg0) {
-		dev_err(dev, "ioremap error\n");
-		return -ENOMEM;
-	}
+	reg0 = devm_ioremap_resource(dev, res0);
+	if (IS_ERR(reg0))
+		return PTR_ERR(reg0);
 
 	priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
 	if (!priv) {


From sergei.shtylyov at cogentembedded.com  Mon Apr  8 17:33:44 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Tue, 9 Apr 2013 01:33:44 +0400
Subject: [PATCH v2 8/9] ARM: shmobile: Marzen: pass platform data to USB PHY
 device
Message-ID: <201304090133.45312.sergei.shtylyov@cogentembedded.com>

Since we're now going to setup the USBPCTRL0 register using the USB PHY device's
platform data, we now need a way to pass those platform data from the board file
to the device which is situated in setup-r8a7779.c -- and what I'm suggesting is
r8a7779_add_usb_phy_device() that will register USB PHY platform device with the
passed platform data using platform_device_register_resndata() call; creating
this function envolves deletion of 'usb_phy_device' from r8a7779_devices_dt[],
so that it will no longer be registered for the generic R8A7779 machine (where
we can't provide the platform data anyway), hence EHCI/OHCI drivers will fail
to load as well.

For the Marzen board, this new function will be called from marzen_init() to
register the USB PHY device early enough.

Note that the board and the SoC code have to be in one patch to keep the code
bisectable...

Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

---
Changes since the original posting:
- added a note about bisectability to the changelog.

 arch/arm/mach-shmobile/board-marzen.c         |    5 +++++
 arch/arm/mach-shmobile/include/mach/r8a7779.h |    2 ++
 arch/arm/mach-shmobile/setup-r8a7779.c        |   16 ++++++++--------
 3 files changed, 15 insertions(+), 8 deletions(-)

Index: renesas/arch/arm/mach-shmobile/board-marzen.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/board-marzen.c
+++ renesas/arch/arm/mach-shmobile/board-marzen.c
@@ -56,6 +56,10 @@ static struct regulator_consumer_supply 
 	REGULATOR_SUPPLY("vdd33a", "smsc911x"),
 };
 
+static struct rcar_phy_platform_data usb_phy_platform_data = {
+	.usbpctrl0	= 0,
+};
+
 /* SMSC LAN89218 */
 static struct resource smsc911x_resources[] = {
 	[0] = {
@@ -230,6 +234,7 @@ static void __init marzen_init(void)
 	r8a7779_pinmux_init();
 
 	r8a7779_add_standard_devices();
+	r8a7779_add_usb_phy_device(&usb_phy_platform_data);
 	platform_add_devices(marzen_devices, ARRAY_SIZE(marzen_devices));
 }
 
Index: renesas/arch/arm/mach-shmobile/include/mach/r8a7779.h
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/include/mach/r8a7779.h
+++ renesas/arch/arm/mach-shmobile/include/mach/r8a7779.h
@@ -4,6 +4,7 @@
 #include <linux/sh_clk.h>
 #include <linux/pm_domain.h>
 #include <linux/sh_eth.h>
+#include <linux/usb/rcar-phy.h>
 
 struct platform_device;
 
@@ -33,6 +34,7 @@ extern void r8a7779_add_early_devices(vo
 extern void r8a7779_add_standard_devices(void);
 extern void r8a7779_add_standard_devices_dt(void);
 extern void r8a7779_add_ether_device(struct sh_eth_plat_data *pdata);
+extern void r8a7779_add_usb_phy_device(struct rcar_phy_platform_data *pdata);
 extern void r8a7779_init_late(void);
 extern void r8a7779_clock_init(void);
 extern void r8a7779_pinmux_init(void);
Index: renesas/arch/arm/mach-shmobile/setup-r8a7779.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/setup-r8a7779.c
+++ renesas/arch/arm/mach-shmobile/setup-r8a7779.c
@@ -407,13 +407,6 @@ static struct resource usb_phy_resources
 	},
 };
 
-static struct platform_device usb_phy_device = {
-	.name		= "rcar_usb_phy",
-	.id		= -1,
-	.resource	= usb_phy_resources,
-	.num_resources	= ARRAY_SIZE(usb_phy_resources),
-};
-
 /* USB */
 static struct usb_phy *phy;
 
@@ -585,7 +578,6 @@ static struct platform_device *r8a7779_d
 	&scif5_device,
 	&tmu00_device,
 	&tmu01_device,
-	&usb_phy_device,
 };
 
 static struct platform_device *r8a7779_standard_devices[] __initdata = {
@@ -620,6 +612,14 @@ void __init r8a7779_add_ether_device(str
 					  pdata, sizeof(*pdata));
 }
 
+void __init r8a7779_add_usb_phy_device(struct rcar_phy_platform_data *pdata)
+{
+	platform_device_register_resndata(&platform_bus, "rcar_usb_phy", -1,
+					  usb_phy_resources,
+					  ARRAY_SIZE(usb_phy_resources),
+					  pdata, sizeof(*pdata));
+}
+
 /* do nothing for !CONFIG_SMP or !CONFIG_HAVE_TWD */
 void __init __weak r8a7779_register_twd(void) { }
 


From thomas.petazzoni at free-electrons.com  Mon Apr  8 17:34:57 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Mon, 8 Apr 2013 23:34:57 +0200
Subject: [PATCHv7 08/17] pci: PCIe driver for Marvell Armada 370/XP systems
In-Reply-To: <201304082331.30809.arnd@arndb.de>
References: <1364395234-11195-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1364395234-11195-9-git-send-email-thomas.petazzoni@free-electrons.com>
 <CAErSpo7fGPe3wFha36kNMxeRP4gBpBWgfw85aTLey-DSz2ZYew@mail.gmail.com>
 <201304082331.30809.arnd@arndb.de>
Message-ID: <20130408233457.7127eab2@skate>

Dear Arnd Bergmann,

On Mon, 8 Apr 2013 23:31:30 +0200, Arnd Bergmann wrote:

> > Too bad to have to adjust CFLAGS here.  Seems like I remember earlier
> > discussion, but I didn't pay much attention, and if this is the best
> > we can do, I guess it's OK.
> 
> I'm pretty sure I NAK'ed this part. I'm surprised it's still there.

As I said in my reply to Bjorn, it's a mistake. I did so much efforts
to get rid of the mach-mvebu and plat-orion dependencies, that in the
end, I forgot that the original reason was to get rid of those special
cflags.

For sure, I'll send a v8 that has those cflags removed, they are
unneeded.

Sorry for this.

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From arnd at arndb.de  Mon Apr  8 17:34:12 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 8 Apr 2013 23:34:12 +0200
Subject: [PATCHv7 08/17] pci: PCIe driver for Marvell Armada 370/XP systems
In-Reply-To: <20130408225741.74fc383c@skate>
References: <1364395234-11195-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <CAErSpo7fGPe3wFha36kNMxeRP4gBpBWgfw85aTLey-DSz2ZYew@mail.gmail.com>
 <20130408225741.74fc383c@skate>
Message-ID: <201304082334.13186.arnd@arndb.de>

On Monday 08 April 2013, Thomas Petazzoni wrote:
> > > +                       pcie->io.name = "I/O";
> > > +                       pcie->realio.start = PCIBIOS_MIN_IO;
> > > +                       pcie->realio.end =
> > > min(resource_size(&pcie->io),
> > > +                                              IO_SPACE_LIMIT);
> > 
> > Using "resource_size(&pcie->io)" here seems strange -- are you
> > assuming that pcie->io starts at address zero?
> 
> No, I'm assuming PCIBIOS_MIN_IO is always 0. So presumarly, this should
> be something like:
> 
>         pcie->realio.end = min(PCIBIOS_MIN_IO +
>                                 resource_size(&pcie->io),
>                                 IO_SPACE_LIMIT);
> 

Normally PCIBIOS_MIN_IO is 0x1000, since the first 4096 ports are reserved
for ISA and PCMCIA compatible drivers and should not be assigned to
PCI devices. So the first port should get ports 0x1000 to 0xffff, later
ones can used the entire 65536 ports e.g. 0x10000 to 0x1ffff.

	Arnd


From tony at atomide.com  Mon Apr  8 17:46:03 2013
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 8 Apr 2013 14:46:03 -0700
Subject: [PATCH v2 RESEND] ARM: OMAP1: fix omap_udc registration
In-Reply-To: <1364846580-5256-1-git-send-email-aaro.koskinen@iki.fi>
References: <1364846580-5256-1-git-send-email-aaro.koskinen@iki.fi>
Message-ID: <20130408214603.GW10155@atomide.com>

* Aaro Koskinen <aaro.koskinen at iki.fi> [130401 13:07]:
> omap_udc platform device is not registered properly anymore:
> CONFIG_USB_GADGET_OMAP was deleted by 193ab2a6 (usb: gadget: allow
> multiple gadgets to be built) already in v3.1.
> 
> Fix by using CONFIG_USB_OMAP instead. Tested on Nokia 770 by checking
> that omap_udc is probed & working properly when built as a module.

Thanks, applying into omap-for-v3.10/board.

Tony
 
> Acked-by: Felipe Balbi <balbi at ti.com>
> Signed-off-by: Aaro Koskinen <aaro.koskinen at iki.fi>
> ---
> 
> 	Patch history:
> 
> 	v2: http://marc.info/?t=136266319800006&r=1&w=2
>             - use IS_ENABLED()
> 
> 	v1: http://marc.info/?t=136260886600006&r=1&w=2
> 
>  arch/arm/mach-omap1/include/mach/usb.h |    2 +-
>  arch/arm/mach-omap1/usb.c              |    6 +++---
>  2 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm/mach-omap1/include/mach/usb.h b/arch/arm/mach-omap1/include/mach/usb.h
> index 753cd5c..45e5ac7 100644
> --- a/arch/arm/mach-omap1/include/mach/usb.h
> +++ b/arch/arm/mach-omap1/include/mach/usb.h
> @@ -2,7 +2,7 @@
>   * FIXME correct answer depends on hmc_mode,
>   * as does (on omap1) any nonzero value for config->otg port number
>   */
> -#ifdef	CONFIG_USB_GADGET_OMAP
> +#if IS_ENABLED(CONFIG_USB_OMAP)
>  #define	is_usb0_device(config)	1
>  #else
>  #define	is_usb0_device(config)	0
> diff --git a/arch/arm/mach-omap1/usb.c b/arch/arm/mach-omap1/usb.c
> index 1a1db59..4118db5 100644
> --- a/arch/arm/mach-omap1/usb.c
> +++ b/arch/arm/mach-omap1/usb.c
> @@ -123,7 +123,7 @@ omap_otg_init(struct omap_usb_config *config)
>  	syscon = omap_readl(OTG_SYSCON_1);
>  	syscon |= HST_IDLE_EN|DEV_IDLE_EN|OTG_IDLE_EN;
>  
> -#ifdef	CONFIG_USB_GADGET_OMAP
> +#if IS_ENABLED(CONFIG_USB_OMAP)
>  	if (config->otg || config->register_dev) {
>  		struct platform_device *udc_device = config->udc_device;
>  		int status;
> @@ -169,7 +169,7 @@ omap_otg_init(struct omap_usb_config *config)
>  void omap_otg_init(struct omap_usb_config *config) {}
>  #endif
>  
> -#ifdef	CONFIG_USB_GADGET_OMAP
> +#if IS_ENABLED(CONFIG_USB_OMAP)
>  
>  static struct resource udc_resources[] = {
>  	/* order is significant! */
> @@ -600,7 +600,7 @@ static void __init omap_1510_usb_init(struct omap_usb_config *config)
>  	while (!(omap_readw(ULPD_DPLL_CTRL) & DPLL_LOCK))
>  		cpu_relax();
>  
> -#ifdef	CONFIG_USB_GADGET_OMAP
> +#if IS_ENABLED(CONFIG_USB_OMAP)
>  	if (config->register_dev) {
>  		int status;
>  
> -- 
> 1.7.10.4
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


From tony at atomide.com  Mon Apr  8 17:46:13 2013
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 8 Apr 2013 14:46:13 -0700
Subject: [PATCH] ARM: OMAP2+: omap2plus_defconfig: Add support for
 BMP085 pressure sensor
In-Reply-To: <1361193652-25313-1-git-send-email-ruslan.bilovol@ti.com>
References: <1361193652-25313-1-git-send-email-ruslan.bilovol@ti.com>
Message-ID: <20130408214613.GX10155@atomide.com>

* Ruslan Bilovol <ruslan.bilovol at ti.com> [130218 05:24]:
> This patch enables BMP085 pressure sensor that can be
> found on OMAP4 Blaze Tablet development platform
> 
> Signed-off-by: Ruslan Bilovol <ruslan.bilovol at ti.com>

Thanks adding to omap-for-v3.10/board.

Regards,

Tony

> ---
>  arch/arm/configs/omap2plus_defconfig |    1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig
> index b16bae2..6a4e9a2 100644
> --- a/arch/arm/configs/omap2plus_defconfig
> +++ b/arch/arm/configs/omap2plus_defconfig
> @@ -93,6 +93,7 @@ CONFIG_BLK_DEV_RAM_SIZE=16384
>  CONFIG_SENSORS_LIS3LV02D=m
>  CONFIG_SENSORS_TSL2550=m
>  CONFIG_SENSORS_LIS3_I2C=m
> +CONFIG_BMP085_I2C=m
>  CONFIG_SCSI=y
>  CONFIG_BLK_DEV_SD=y
>  CONFIG_SCSI_MULTI_LUN=y
> -- 
> 1.7.9.5
> 


From tony at atomide.com  Mon Apr  8 17:46:19 2013
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 8 Apr 2013 14:46:19 -0700
Subject: [PATCH] ARM: OMAP: zoom: Use pwm stack for lcd and keyboard
 backlight
In-Reply-To: <513DCA13.40705@ti.com>
References: <1363003076-17360-1-git-send-email-peter.ujfalusi@ti.com>
 <513DCA13.40705@ti.com>
Message-ID: <20130408214618.GY10155@atomide.com>

* Tomi Valkeinen <tomi.valkeinen at ti.com> [130311 05:16]:
> On 2013-03-11 13:57, Peter Ujfalusi wrote:
> > Use pwm_leds driver for the keyboard light and pwm-backlight for the lcd
> > backlight control (instead of implementing the PWM driver part in the board
> > file).
> > 
> > Signed-off-by: Peter Ujfalusi <peter.ujfalusi at ti.com>
> > ---
> >  arch/arm/mach-omap2/board-zoom-display.c     | 56 ----------------------------
> >  arch/arm/mach-omap2/board-zoom-peripherals.c | 53 +++++++++++++++++++++++++-
> >  2 files changed, 52 insertions(+), 57 deletions(-)
> 
> I can't test this, but looks fine to me. Good to get rid of the hacky
> backlight code in board-zoom-display.c.

Thanks applying into omap-for-v3.10/board.

Tony


From tony at atomide.com  Mon Apr  8 17:46:32 2013
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 8 Apr 2013 14:46:32 -0700
Subject: [PATCH] ARM: OMAP: RX-51: add missing regulator supply
 definitions for lis3lv02d
In-Reply-To: <1364846644-5302-1-git-send-email-aaro.koskinen@iki.fi>
References: <1364846644-5302-1-git-send-email-aaro.koskinen@iki.fi>
Message-ID: <20130408214632.GA10155@atomide.com>

* Aaro Koskinen <aaro.koskinen at iki.fi> [130401 13:08]:
> Add missing regulator definitions for lis3lv02d accelerometer. Fixes
> the following probe issue:
> 
> [   57.737518] lis3lv02d_i2c 3-001d: Failed to get supply 'Vdd': -517
> [   57.747100] i2c 3-001d: Driver lis3lv02d_i2c requests probe deferral
> 
> Reported-by: Pali Roh?r <pali.rohar at gmail.com>
> Reviewed-by: Mark Brown <broonie at opensource.wolfsonmicro.com>
> Signed-off-by: Aaro Koskinen <aaro.koskinen at iki.fi>
> ---
> 
> 	The patch was discussed in this thread...
> 
> 		http://marc.info/?t=136105842400001&r=1&w=2
> 
> 	...and now sending it to relevant mailing lists.
> 
>  arch/arm/mach-omap2/board-rx51-peripherals.c |    4 ++++
>  1 file changed, 4 insertions(+)

Thanks applying into omap-for-v3.10/board.

Tony
 
> diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c b/arch/arm/mach-omap2/board-rx51-peripherals.c
> index 3a077df..1a88467 100644
> --- a/arch/arm/mach-omap2/board-rx51-peripherals.c
> +++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
> @@ -547,12 +547,16 @@ static struct regulator_consumer_supply rx51_vio_supplies[] = {
>  	REGULATOR_SUPPLY("DVDD", "2-0019"),
>  	/* Si4713 IO supply */
>  	REGULATOR_SUPPLY("vio", "2-0063"),
> +	/* lis3lv02d */
> +	REGULATOR_SUPPLY("Vdd_IO", "3-001d"),
>  };
>  
>  static struct regulator_consumer_supply rx51_vaux1_consumers[] = {
>  	REGULATOR_SUPPLY("vdds_sdi", "omapdss"),
>  	/* Si4713 supply */
>  	REGULATOR_SUPPLY("vdd", "2-0063"),
> +	/* lis3lv02d */
> +	REGULATOR_SUPPLY("Vdd", "3-001d"),
>  };
>  
>  static struct regulator_init_data rx51_vaux1 = {
> -- 
> 1.7.10.4
> 


From tony at atomide.com  Mon Apr  8 17:46:42 2013
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 8 Apr 2013 14:46:42 -0700
Subject: [PATCH] omap2+: Remove useless Makefile line
In-Reply-To: <1365156992.1830.63.camel@x61.thuisdomein>
References: <1365156992.1830.63.camel@x61.thuisdomein>
Message-ID: <20130408214640.GB10155@atomide.com>

* Paul Bolle <pebolle at tiscali.nl> [130405 03:21]:
> Merge commit 952414505f55afe5cd6dc004765076aa22b3ed7e ("Merge branch
> 'next/cleanup' of git://git.linaro.org/people/arnd/arm-soc") added
> references to CONFIG_MACH_PCM049 and board-omap4pcm049.o to this
> Makefile. But there's no Kconfig symbol MACH_PCM049 and there's no file
> board-omap4pcm049.c. This line can safely be removed.
> 
> Signed-off-by: Paul Bolle <pebolle at tiscali.nl>
> ---
> Note that MACH_PCM049 was removed from mach-types in v3.5.
> 
>  arch/arm/mach-omap2/Makefile | 2 --
>  1 file changed, 2 deletions(-)

Thanks applying into omap-for-v3.10/board.

Tony
 
> diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
> index 3d0697c..62bb352 100644
> --- a/arch/arm/mach-omap2/Makefile
> +++ b/arch/arm/mach-omap2/Makefile
> @@ -254,8 +254,6 @@ obj-$(CONFIG_MACH_TOUCHBOOK)		+= board-omap3touchbook.o
>  obj-$(CONFIG_MACH_OMAP_4430SDP)		+= board-4430sdp.o
>  obj-$(CONFIG_MACH_OMAP4_PANDA)		+= board-omap4panda.o
>  
> -obj-$(CONFIG_MACH_PCM049)		+= board-omap4pcm049.o
> -
>  obj-$(CONFIG_MACH_OMAP3517EVM)		+= board-am3517evm.o
>  
>  obj-$(CONFIG_MACH_CRANEBOARD)		+= board-am3517crane.o
> -- 
> 1.7.11.7
> 


From thomas.petazzoni at free-electrons.com  Mon Apr  8 17:53:41 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Mon, 8 Apr 2013 23:53:41 +0200
Subject: [PATCHv7 08/17] pci: PCIe driver for Marvell Armada 370/XP systems
In-Reply-To: <201304082334.13186.arnd@arndb.de>
References: <1364395234-11195-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <CAErSpo7fGPe3wFha36kNMxeRP4gBpBWgfw85aTLey-DSz2ZYew@mail.gmail.com>
 <20130408225741.74fc383c@skate> <201304082334.13186.arnd@arndb.de>
Message-ID: <20130408235341.7012b791@skate>

Dear Arnd Bergmann,

On Mon, 8 Apr 2013 23:34:12 +0200, Arnd Bergmann wrote:

> > No, I'm assuming PCIBIOS_MIN_IO is always 0. So presumarly, this should
> > be something like:
> > 
> >         pcie->realio.end = min(PCIBIOS_MIN_IO +
> >                                 resource_size(&pcie->io),
> >                                 IO_SPACE_LIMIT);
> > 
> 
> Normally PCIBIOS_MIN_IO is 0x1000, since the first 4096 ports are reserved
> for ISA and PCMCIA compatible drivers and should not be assigned to
> PCI devices. So the first port should get ports 0x1000 to 0xffff, later
> ones can used the entire 65536 ports e.g. 0x10000 to 0x1ffff.

Then I guess it should work with the code I'm proposing here, no?

Note: this pcie->realio region is global: it will be shared by all PCIe
interfaces.

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From rtivy at ti.com  Mon Apr  8 18:02:40 2013
From: rtivy at ti.com (Tivy, Robert)
Date: Mon, 8 Apr 2013 22:02:40 +0000
Subject: [PATCH v9 4/6] ARM: davinci: Add a remoteproc driver
 implementation for OMAP-L13x DSP
In-Reply-To: <CAK=WgbZme2UkMeP-JB2h3xnmcpzAaYeOcy7gxh60muJ8KZbr_A@mail.gmail.com>
References: <1364521307-1219-1-git-send-email-rtivy@ti.com>
 <1364521307-1219-5-git-send-email-rtivy@ti.com>
 <CAK=WgbZme2UkMeP-JB2h3xnmcpzAaYeOcy7gxh60muJ8KZbr_A@mail.gmail.com>
Message-ID: <13514BD7FAEBA745BBD7D8A672905C14312302EA@DFLE12.ent.ti.com>

Hi Ohad,

> -----Original Message-----
> From: Ohad Ben-Cohen [mailto:ohad at wizery.com]
> Sent: Sunday, April 07, 2013 6:03 AM
> To: Tivy, Robert
> Cc: davinci-linux-open-source; linux-arm; Nori, Sekhar; Rob Landley;
> linux-doc at vger.kernel.org; Grosen, Mark; Ring, Chris
> Subject: Re: [PATCH v9 4/6] ARM: davinci: Add a remoteproc driver
> implementation for OMAP-L13x DSP
> 
> Hi Rob,
> 
> On Fri, Mar 29, 2013 at 4:41 AM, Robert Tivy <rtivy at ti.com> wrote:> +
> > +static int da8xx_rproc_probe(struct platform_device *pdev)
> > +{
> > +       struct device *dev = &pdev->dev;
> > +       struct da8xx_rproc *drproc;
> > +       struct rproc *rproc;
> > +       struct irq_data *irq_data;
> > +       struct resource *bootreg_res;
> > +       struct resource *chipsig_res;
> > +       struct clk *dsp_clk;
> > +       void __iomem *chipsig;
> > +       void __iomem *bootreg;
> > +       int irq;
> > +       int ret;
> > +
> > +       irq = platform_get_irq(pdev, 0);
> > +       if (irq < 0) {
> > +               dev_err(dev, "platform_get_irq(pdev, 0) error: %d\n",
> irq);
> > +               return irq;
> > +       }
> > +
> > +       irq_data = irq_get_irq_data(irq);
> > +       if (!irq_data) {
> > +               dev_err(dev, "irq_get_irq_data(%d): NULL\n", irq);
> > +               return -EINVAL;
> > +       }
> > +
> > +       bootreg_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > +       if (!bootreg_res) {
> > +               dev_err(dev,
> > +                       "platform_get_resource(IORESOURCE_MEM, 0):
> NULL\n");
> > +               return -EADDRNOTAVAIL;
> > +       }
> > +
> > +       chipsig_res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> > +       if (!chipsig_res) {
> > +               dev_err(dev,
> > +                       "platform_get_resource(IORESOURCE_MEM, 1):
> NULL\n");
> > +               return -EADDRNOTAVAIL;
> > +       }
> > +
> > +       bootreg = devm_request_and_ioremap(dev, bootreg_res);
> > +       if (!bootreg) {
> > +               dev_err(dev, "unable to map boot register\n");
> > +               return -EADDRNOTAVAIL;
> > +       }
> > +
> > +       chipsig = devm_request_and_ioremap(dev, chipsig_res);
> > +       if (!chipsig) {
> > +               dev_err(dev, "unable to map CHIPSIG register\n");
> > +               return -EADDRNOTAVAIL;
> > +       }
> > +
> > +       dsp_clk = devm_clk_get(dev, NULL);
> > +       if (IS_ERR(dsp_clk)) {
> > +               dev_err(dev, "clk_get error: %ld\n",
> PTR_ERR(dsp_clk));
> > +
> > +               return PTR_RET(dsp_clk);
> > +       }
> > +
> > +       rproc = rproc_alloc(dev, "dsp", &da8xx_rproc_ops,
> da8xx_fw_name,
> > +               sizeof(*drproc));
> > +       if (!rproc)
> > +               return -ENOMEM;
> > +
> > +       drproc = rproc->priv;
> > +       drproc->rproc = rproc;
> > +
> > +       platform_set_drvdata(pdev, rproc);
> > +
> > +       /* everything the ISR needs is now setup, so hook it up */
> > +       ret = devm_request_threaded_irq(dev, irq,
> da8xx_rproc_callback,
> > +               handle_event, 0, "da8xx-remoteproc", rproc);
> > +       if (ret) {
> > +               dev_err(dev, "devm_request_threaded_irq error: %d\n",
> ret);
> > +               goto free_rproc;
> > +       }
> > +
> > +       /*
> > +        * rproc_add() can end up enabling the DSP's clk with the DSP
> > +        * *not* in reset, but da8xx_rproc_start() needs the DSP to
> be
> > +        * held in reset at the time it is called.
> > +        */
> > +       ret = reset_assert(dev);
> > +       if (ret)
> > +               goto free_rproc;
> > +
> > +       ret = rproc_add(rproc);
> > +       if (ret) {
> > +               dev_err(dev, "rproc_add failed: %d\n", ret);
> > +               goto free_rproc;
> > +       }
> > +
> > +       drproc->chipsig = chipsig;
> > +       drproc->bootreg = bootreg;
> > +       drproc->ack_fxn = irq_data->chip->irq_ack;
> > +       drproc->irq_data = irq_data;
> > +       drproc->irq = irq;
> > +       drproc->dsp_clk = dsp_clk;
> > +
> > +       return 0;
> > +
> > +free_rproc:
> > +       rproc_put(rproc);
> > +
> > +       return ret;
> > +}
> 
> Two small changes please:
> 
> - could you please fix the error path of probe? it seems that some
> resources are taken but not freed in case a failure shows up
> subsequently

I'm not sure what resources you mean?

The platform_get_irq()/irq_get_irq_data()/platform_get_resource() calls don't have "put" counterparts.  The "devm_*" calls get automatically cleaned up (and I wasn't able to find any existing example of some code that actually does the cleanup explicitly).

> - seems like it's safer to set drproc before calling rproc_add
> otherwise you have a small race there

Agreed, will change.

> 
> If you could respin this one quickly it'd be great, thanks!
> 
> Ohad.

Sergei had a comment to change devm_request_and_ioremap() to devm_ioremap_resource(), so I will submit a new patch with your and Sergei's comments applied.

Regards,

- Rob



From robherring2 at gmail.com  Mon Apr  8 18:05:26 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Mon, 08 Apr 2013 17:05:26 -0500
Subject: [PATCH 1/1] of/irq: store IRQ trigger/level in struct resource
 flags
In-Reply-To: <1365148088-11175-1-git-send-email-javier.martinez@collabora.co.uk>
References: <1365148088-11175-1-git-send-email-javier.martinez@collabora.co.uk>
Message-ID: <51633F26.7000400@gmail.com>

On 04/05/2013 02:48 AM, Javier Martinez Canillas wrote:
> According to Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
> the "#interrupt-cells" property of an "interrupt-controller" is used
> to define the number of cells needed to specify a single interrupt.
> 
> A commonly used variant is two cell on which #interrupt-cells = <2>
> and the first cell defines the index of the interrupt in the controller
> and the second cell is used to specify any of the following flags:
> 
>     - bits[3:0] trigger type and level flags
>         1 = low-to-high edge triggered
>         2 = high-to-low edge triggered
>         4 = active high level-sensitive
>         8 = active low level-sensitive
> 
> An example of an interrupt controller which use the two cell format is
> the OMAP GPIO controller that allows GPIO lines to be used as IRQ
> (Documentation/devicetree/bindings/gpio/gpio-omap.txt)
> 
> But setting #interrupt-cells = <2> on the OMAP GPIO device node and
> specifying the GPIO-IRQ type and level flags on the second cell does not
> store this value on the populated IORESOURCE_IRQ struct resource.
> 
> This is because when using an IRQ from an interrupt controller and
> setting both cells (e.g:)
> 
> 	interrupt-parent = <&gpio6>;
> 	interrupts = <16 8>;
> 
> A call to of_irq_to_resource() is made and this function calls to
> irq_of_parse_and_map_type() to get the virtual IRQ mapped to the real
> index for this interrupt controller. This IRQ number is populated on
> the struct resource:
> 
> int of_irq_to_resource(struct device_node *dev, int index, struct resource *r)
> {
> 	int irq = irq_of_parse_and_map(dev, index);
> 	..
> 	r->start = r->end = irq;
> }
> 
> irq_of_parse_and_map() calls to irq_create_of_mapping() which calls to
> the correct xlate function handler according to "#interrupt-cells"
> (irq_domain_xlate_onecell or irq_domain_xlate_twocell) and to
> irq_set_irq_type() to set the IRQ type.
> 
> But the type is never returned so it can't be saved on the IRQ struct
> resource flags member.
> 
> This means that drivers that need the IRQ type/level flags defined in
> the DT won't be able to get it.

But the interrupt controllers that need the information should be able
to get to it via irqd_get_trigger_type. What problem exactly are you
trying to fix? What driver would use this?

My understanding of the IORESOURCE_IRQ_xxx (and DMA) bits are they are
ISA specific and therefore should not be used on non-ISA buses.

Rob




From arnd at arndb.de  Mon Apr  8 18:14:06 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 9 Apr 2013 00:14:06 +0200
Subject: [PATCHv7 08/17] pci: PCIe driver for Marvell Armada 370/XP systems
In-Reply-To: <20130408235341.7012b791@skate>
References: <1364395234-11195-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <201304082334.13186.arnd@arndb.de> <20130408235341.7012b791@skate>
Message-ID: <201304090014.06959.arnd@arndb.de>

On Monday 08 April 2013, Thomas Petazzoni wrote:
> Dear Arnd Bergmann,
> 
> On Mon, 8 Apr 2013 23:34:12 +0200, Arnd Bergmann wrote:
> 
> > > No, I'm assuming PCIBIOS_MIN_IO is always 0. So presumarly, this should
> > > be something like:
> > > 
> > >         pcie->realio.end = min(PCIBIOS_MIN_IO +
> > >                                 resource_size(&pcie->io),
> > >                                 IO_SPACE_LIMIT);
> > > 
> > 
> > Normally PCIBIOS_MIN_IO is 0x1000, since the first 4096 ports are reserved
> > for ISA and PCMCIA compatible drivers and should not be assigned to
> > PCI devices. So the first port should get ports 0x1000 to 0xffff, later
> > ones can used the entire 65536 ports e.g. 0x10000 to 0x1ffff.
> 
> Then I guess it should work with the code I'm proposing here, no?
> 
> Note: this pcie->realio region is global: it will be shared by all PCIe
> interfaces.

I think it's still wrong, unless you guarantee that
resource_start(&pcie->io) is the same as PCIBIOS_MIN_IO.

Why don't you just read the start and end values from the ranges
property? I assume you want to run with io_offset=0, so you really
need

	pcie->realio.type = IORESOURCE_IO;
	pcie->realio.start = max(PCIBIOS_MIN_IO, range->pci_addr);
	pcie->realio.end = max(IO_SPACE_LIMIT, range->pci_addr + range->size);

	Arnd


From swarren at wwwdotorg.org  Mon Apr  8 18:16:15 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Mon, 08 Apr 2013 16:16:15 -0600
Subject: [PATCH 1/1] of/irq: store IRQ trigger/level in struct resource
 flags
In-Reply-To: <51633F26.7000400@gmail.com>
References: <1365148088-11175-1-git-send-email-javier.martinez@collabora.co.uk>
 <51633F26.7000400@gmail.com>
Message-ID: <516341AF.7030207@wwwdotorg.org>

On 04/08/2013 04:05 PM, Rob Herring wrote:
> On 04/05/2013 02:48 AM, Javier Martinez Canillas wrote:
>> According to Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
>> the "#interrupt-cells" property of an "interrupt-controller" is used
>> to define the number of cells needed to specify a single interrupt.
...
>> But the type is never returned so it can't be saved on the IRQ struct
>> resource flags member.
>>
>> This means that drivers that need the IRQ type/level flags defined in
>> the DT won't be able to get it.
> 
> But the interrupt controllers that need the information should be able
> to get to it via irqd_get_trigger_type. What problem exactly are you
> trying to fix? What driver would use this?

FYI, that is indeed what I did in sound/soc/codecs/wm8903.c. Thinking
back, I'm not sure if that was the right thing or whether I should have
sent this same patch:-)


From tony at atomide.com  Mon Apr  8 18:17:32 2013
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 8 Apr 2013 15:17:32 -0700
Subject: [PATCH] omap2+: Remove useless Makefile line
In-Reply-To: <1365156749.1830.60.camel@x61.thuisdomein>
References: <1365156749.1830.60.camel@x61.thuisdomein>
Message-ID: <20130408221732.GD10155@atomide.com>

* Paul Bolle <pebolle at tiscali.nl> [130405 03:17]:
> Commit f41caddbe73f52a42f529d668ce47b4d693fd2c0 ("omap2+: Use Kconfig
> symbol in Makefile instead of obj-y") reorganized this Makefile. But,
> for some reason, it also added references to CONFIG_MACH_ENCORE and
> board-omap3encore.o. But there's no Kconfig symbol MACH_ENCORE and
> there's no file board-omap3encore.c. This line can safely be removed.

Thanks applying into omap-for-v3.10/board.

Tony
 
> Signed-off-by: Paul Bolle <pebolle at tiscali.nl>
> ---
>  arch/arm/mach-omap2/Makefile | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
> index b068b7f..3d0697c 100644
> --- a/arch/arm/mach-omap2/Makefile
> +++ b/arch/arm/mach-omap2/Makefile
> @@ -229,7 +229,6 @@ obj-$(CONFIG_MACH_DEVKIT8000)     	+= board-devkit8000.o
>  obj-$(CONFIG_MACH_OMAP_LDP)		+= board-ldp.o
>  obj-$(CONFIG_MACH_OMAP3530_LV_SOM)      += board-omap3logic.o
>  obj-$(CONFIG_MACH_OMAP3_TORPEDO)        += board-omap3logic.o
> -obj-$(CONFIG_MACH_ENCORE)		+= board-omap3encore.o
>  obj-$(CONFIG_MACH_OVERO)		+= board-overo.o
>  obj-$(CONFIG_MACH_OMAP3EVM)		+= board-omap3evm.o
>  obj-$(CONFIG_MACH_OMAP3_PANDORA)	+= board-omap3pandora.o
> -- 
> 1.7.11.7
> 
> 
> 


From bhelgaas at google.com  Mon Apr  8 18:28:58 2013
From: bhelgaas at google.com (Bjorn Helgaas)
Date: Mon, 8 Apr 2013 16:28:58 -0600
Subject: [RFCv1 08/11] PCI: Introduce new MSI chip infrastructure
In-Reply-To: <1364316746-8702-9-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1364316746-8702-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1364316746-8702-9-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <CAErSpo42AFdKH2RKTxOaeJgCPrYD5KYkOs3UEBez8x8Bjmun5w@mail.gmail.com>

On Tue, Mar 26, 2013 at 10:52 AM, Thomas Petazzoni
<thomas.petazzoni at free-electrons.com> wrote:
> From: Thierry Reding <thierry.reding at avionic-design.de>
>
> The new struct msi_chip is used to associated an MSI controller with a
> PCI bus. It is automatically handed down from the root to its children
> during bus enumeration.
>
> This patch provides default (weak) implementations for the architecture-
> specific MSI functions (arch_setup_msi_irq(), arch_teardown_msi_irq()
> and arch_msi_check_device()) which check if a PCI device's bus has an
> attached MSI chip and forward the call appropriately.
>
> Signed-off-by: Thierry Reding <thierry.reding at avionic-design.de>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> ---
>  drivers/pci/msi.c   |   35 +++++++++++++++++++++++++++++++----
>  drivers/pci/probe.c |    1 +
>  include/linux/msi.h |   10 ++++++++++
>  include/linux/pci.h |    1 +
>  4 files changed, 43 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
> index 00cc78c..fce3549 100644
> --- a/drivers/pci/msi.c
> +++ b/drivers/pci/msi.c
> @@ -26,14 +26,41 @@
>
>  static int pci_msi_enable = 1;
>
> -/* Arch hooks */
> +int __weak arch_setup_msi_irq(struct pci_dev *dev, struct msi_desc *desc)
> +{
> +       struct msi_chip *chip = dev->bus->msi;
> +
> +       if (chip && chip->setup_irq) {
> +               int err;
> +
> +               err = chip->setup_irq(chip, dev, desc);
> +               if (err < 0)
> +                       return err;
> +
> +               irq_set_chip_data(desc->irq, chip);
> +               return err;
> +       }
> +
> +       return -EINVAL;
> +}
>
> -#ifndef arch_msi_check_device
> -int arch_msi_check_device(struct pci_dev *dev, int nvec, int type)
> +void __weak arch_teardown_msi_irq(unsigned int irq)
>  {
> +       struct msi_chip *chip = irq_get_chip_data(irq);
> +
> +       if (chip && chip->teardown_irq)
> +               chip->teardown_irq(chip, irq);
> +}
> +
> +int __weak arch_msi_check_device(struct pci_dev *dev, int nvec, int type)

I like the replacement of "#ifndef arch_msi_check_device()" with a
weak implementation here, but this only does half the job -- shouldn't
we remove the powerpc "#define arch_msi_check_device
arch_msi_check_device" at the same time?

And since we're touching all the check_device() implementations, maybe
we could come up with a better name.  "check_device()" conveys
absolutely no information about what we're checking or what the sense
of the result is.  arch_msi_supported()?  pcibios_msi_supported()?  I
guess it should be consistent with the other arch interfaces, so
arch_*() is probably better.

Maybe the ugly #ifdef-ery around arch_setup_msi_irqs,
arch_teardown_msi_irqs, and arch_restore_msi_irqs could be cleaned up
similarly?  Somebody worked pretty hard to obfuscate all that,
probably before weak functions were available.

> +{
> +       struct msi_chip *chip = dev->bus->msi;
> +
> +       if (chip && chip->check_device)
> +               return chip->check_device(chip, dev, nvec, type);
> +
>         return 0;
>  }
> -#endif
>
>  #ifndef arch_setup_msi_irqs
>  # define arch_setup_msi_irqs default_setup_msi_irqs
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index b494066..9307550 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -634,6 +634,7 @@ static struct pci_bus *pci_alloc_child_bus(struct pci_bus *parent,
>
>         child->parent = parent;
>         child->ops = parent->ops;
> +       child->msi = parent->msi;
>         child->sysdata = parent->sysdata;
>         child->bus_flags = parent->bus_flags;
>
> diff --git a/include/linux/msi.h b/include/linux/msi.h
> index ce93a34..ea4a5be 100644
> --- a/include/linux/msi.h
> +++ b/include/linux/msi.h
> @@ -58,5 +58,15 @@ extern int arch_setup_msi_irqs(struct pci_dev *dev, int nvec, int type);
>  extern void arch_teardown_msi_irqs(struct pci_dev *dev);
>  extern int arch_msi_check_device(struct pci_dev* dev, int nvec, int type);
>
> +struct msi_chip {
> +       struct module *owner;
> +       struct device *dev;
> +
> +       int (*setup_irq)(struct msi_chip *chip, struct pci_dev *dev,
> +                        struct msi_desc *desc);
> +       void (*teardown_irq)(struct msi_chip *chip, unsigned int irq);
> +       int (*check_device)(struct msi_chip *chip, struct pci_dev *dev,
> +                           int nvec, int type);

If we do end up adding interfaces like this (I'm not sure it will work
-- see below), I think it would be better to pass just the pci_dev,
not the "msi_chip, pci_dev" pair.  Passing both pointers avoids a
cheap lookup in the caller, but it adds a way that two inseparable
things can get out of sync.

> +};
>
>  #endif /* LINUX_MSI_H */
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index 2461033a..6aca43ea 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -416,6 +416,7 @@ struct pci_bus {
>         struct resource busn_res;       /* bus numbers routed to this bus */
>
>         struct pci_ops  *ops;           /* configuration access functions */
> +       struct msi_chip *msi;           /* MSI controller */

"msi" seems like a too-generic name here; it suggests an interrupt or
IRQ, not a controller.

I'm not sure this is the correct place for it.  Having it in the
struct pci_bus means you need arch code to fill it in, e.g., you added
it in mvebu_pcie_scan_bus() in patch 09/11.  There's no good way to do
that for arches that use pci_scan_root_bus(), which is the direction
I'd like to go.

I think it probably should go in sysdata instead.  That would mean you
can't really do generic weak setup/tear-down functions, because they
wouldn't know how to pull the MSI controller info out of the
arch-specific sysdata.  But there are so many levels of weak-ness
going on there, maybe it would be a good thing to get rid of one :)

Bjorn

>         void            *sysdata;       /* hook for sys-specific extension */
>         struct proc_dir_entry *procdir; /* directory entry in /proc/bus/pci */
>
> --
> 1.7.9.5
>


From bhelgaas at google.com  Mon Apr  8 18:29:07 2013
From: bhelgaas at google.com (Bjorn Helgaas)
Date: Mon, 8 Apr 2013 16:29:07 -0600
Subject: [RFCv1 09/11] pci: mvebu: add MSI support
In-Reply-To: <1364316746-8702-10-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1364316746-8702-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1364316746-8702-10-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <CAErSpo7yC_97Vg-zuype-jyfqiY+77OE97cxYoEO9ZZnXjQ95A@mail.gmail.com>

On Tue, Mar 26, 2013 at 10:52 AM, Thomas Petazzoni
<thomas.petazzoni at free-electrons.com> wrote:
> This commit adds the MSI support for the Marvell EBU PCIe driver. The
> driver now looks at the 'msi-parent' property of the PCIe controller
> DT node, and if it exists, it gets the associated IRQ domain, which
> should be the MSI interrupt controller registered by the IRQ
> controller driver.
>
> Using this, the PCIe driver registers the ->setup_irq() and
> ->teardown_irq() callbacks using the newly introduced msi_chip
> infrastructure, which allows the kernel PCI core to use the MSI
> functionality.
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> ---
>  .../devicetree/bindings/pci/mvebu-pci.txt          |    5 +
>  drivers/pci/host/pci-mvebu.c                       |  128 ++++++++++++++++++++
>  2 files changed, 133 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/pci/mvebu-pci.txt b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
> index 192bdfb..53cc437 100644
> --- a/Documentation/devicetree/bindings/pci/mvebu-pci.txt
> +++ b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
> @@ -14,6 +14,10 @@ Mandatory properties:
>    corresponding registers
>  - ranges: ranges for the PCI memory and I/O regions
>
> +Optional properties:
> +- msi-parent: a phandle pointing to the interrupt controller that
> +  handles the MSI interrupts.
> +
>  In addition, the Device Tree node must have sub-nodes describing each
>  PCIe interface, having the following mandatory properties:
>  - reg: used only for interrupt mapping, so only the first four bytes
> @@ -43,6 +47,7 @@ pcie-controller {
>         #address-cells = <3>;
>         #size-cells = <2>;
>
> +       msi-parent = <&msi>;
>         bus-range = <0x00 0xff>;
>
>         reg = <0xd0040000 0x2000>, <0xd0042000 0x2000>,
> diff --git a/drivers/pci/host/pci-mvebu.c b/drivers/pci/host/pci-mvebu.c
> index 9e6b137..b46fab8 100644
> --- a/drivers/pci/host/pci-mvebu.c
> +++ b/drivers/pci/host/pci-mvebu.c
> @@ -7,17 +7,23 @@
>   */
>
>  #include <linux/kernel.h>
> +#include <linux/irq.h>
> +#include <linux/irqdomain.h>
>  #include <linux/pci.h>
> +#include <linux/msi.h>
>  #include <linux/clk.h>
>  #include <linux/module.h>
>  #include <linux/mbus.h>
>  #include <linux/slab.h>
>  #include <linux/platform_device.h>
> +#include <linux/interrupt.h>
>  #include <linux/of_address.h>
>  #include <linux/of_pci.h>
>  #include <linux/of_irq.h>
>  #include <linux/of_platform.h>
>
> +#define INT_PCI_MSI_NR (16)
> +
>  /*
>   * PCIe unit register offsets.
>   */
> @@ -101,10 +107,19 @@ struct mvebu_sw_pci_bridge {
>
>  struct mvebu_pcie_port;
>
> +struct mvebu_pcie_msi {
> +       DECLARE_BITMAP(used, INT_PCI_MSI_NR);
> +       struct irq_domain *domain;
> +       struct mutex lock;
> +       struct msi_chip chip;
> +       phys_addr_t doorbell;
> +};
> +
>  /* Structure representing all PCIe interfaces */
>  struct mvebu_pcie {
>         struct platform_device *pdev;
>         struct mvebu_pcie_port *ports;
> +       struct mvebu_pcie_msi msi;
>         struct resource io;
>         struct resource realio;
>         struct resource mem;
> @@ -546,6 +561,11 @@ static inline struct mvebu_pcie *sys_to_pcie(struct pci_sys_data *sys)
>         return sys->private_data;
>  }
>
> +static inline struct mvebu_pcie_msi *to_mvebu_msi(struct msi_chip *chip)
> +{
> +       return container_of(chip, struct mvebu_pcie_msi, chip);
> +}
> +
>  /* Find the PCIe interface that corresponds to the given bus */
>  static struct mvebu_pcie_port *mvebu_find_port_from_bus(struct mvebu_pcie *pcie,
>                                                         int bus)
> @@ -710,6 +730,8 @@ static struct pci_bus *mvebu_pcie_scan_bus(int nr, struct pci_sys_data *sys)
>         if (!bus)
>                 return NULL;
>
> +       bus->msi = &pcie->msi.chip;

As I mentioned in the 08/11 patch, I'd like to keep arch-specific
stuff out of the PCI scanning path to preserve the ability to move
toward pci_scan_root_bus() eventually.

>         pci_scan_child_bus(bus);
>
>         return bus;
> @@ -786,6 +808,105 @@ static void __iomem *mvebu_pcie_map_registers(struct platform_device *pdev,
>         return devm_request_and_ioremap(&pdev->dev, &regs);
>  }
>
> +#if defined(CONFIG_PCI_MSI)
> +static int mvebu_pcie_msi_alloc(struct mvebu_pcie_msi *chip)
> +{
> +       int msi;
> +
> +       mutex_lock(&chip->lock);
> +
> +       msi = find_first_zero_bit(chip->used, INT_PCI_MSI_NR);
> +
> +       if (msi < INT_PCI_MSI_NR)
> +               set_bit(msi, chip->used);
> +       else
> +               msi = -ENOSPC;
> +
> +       mutex_unlock(&chip->lock);
> +
> +       return msi;
> +}
> +
> +static void mvebu_pcie_msi_free(struct mvebu_pcie_msi *chip, unsigned long irq)
> +{
> +       struct device *dev = chip->chip.dev;
> +
> +       mutex_lock(&chip->lock);
> +
> +       if (!test_bit(irq, chip->used))
> +               dev_err(dev, "trying to free unused MSI#%lu\n", irq);
> +       else
> +               clear_bit(irq, chip->used);
> +
> +       mutex_unlock(&chip->lock);
> +}
> +
> +static int mvebu_pcie_setup_msi_irq(struct msi_chip *chip,
> +                                   struct pci_dev *pdev,
> +                                   struct msi_desc *desc)
> +{
> +       struct mvebu_pcie_msi *msi = to_mvebu_msi(chip);

If this took only the pci_dev (not the msi_chip), I think you could do this:

  struct mvebu_pcie_msi *msi = &pdev->bus->sysdata->msi;

> +       struct msi_msg msg;
> +       unsigned int irq;
> +       int hwirq;
> +
> +       hwirq = mvebu_pcie_msi_alloc(msi);
> +       if (hwirq < 0)
> +               return hwirq;
> +
> +       irq = irq_create_mapping(msi->domain, hwirq);
> +       if (!irq)
> +               return -EINVAL;
> +
> +       irq_set_msi_desc(irq, desc);
> +
> +       msg.address_lo = msi->doorbell;
> +       msg.address_hi = 0;
> +       msg.data = 0xf00 | (hwirq + 16);
> +
> +       write_msi_msg(irq, &msg);
> +
> +       return 0;
> +}
> +
> +static void mvebu_pcie_teardown_msi_irq(struct msi_chip *chip,
> +                                       unsigned int irq)
> +{
> +       struct mvebu_pcie_msi *msi = to_mvebu_msi(chip);
> +       struct irq_data *d = irq_get_irq_data(irq);
> +
> +       mvebu_pcie_msi_free(msi, d->hwirq);
> +}
> +
> +static int mvebu_pcie_enable_msi(struct mvebu_pcie *pcie)
> +{
> +       struct device_node *msi_node;
> +       struct mvebu_pcie_msi *msi;
> +
> +       msi = &pcie->msi;
> +
> +       mutex_init(&msi->lock);
> +
> +       msi_node = of_parse_phandle(pcie->pdev->dev.of_node,
> +                                   "msi-parent", 0);
> +       if (!msi_node)
> +               return -EINVAL;
> +
> +       msi->domain = irq_find_host(msi_node);
> +       if (!msi->domain)
> +               return -EINVAL;
> +
> +       if (of_property_read_u32(msi_node, "marvell,doorbell", &msi->doorbell))
> +               return -EINVAL;
> +
> +       msi->chip.dev = &pcie->pdev->dev;
> +       msi->chip.setup_irq = mvebu_pcie_setup_msi_irq;
> +       msi->chip.teardown_irq = mvebu_pcie_teardown_msi_irq;
> +
> +       return 0;
> +}
> +#endif /* CONFIG_PCI_MSI */
> +
>  static int __init mvebu_pcie_probe(struct platform_device *pdev)
>  {
>         struct mvebu_pcie *pcie;
> @@ -903,6 +1024,13 @@ static int __init mvebu_pcie_probe(struct platform_device *pdev)
>
>         mvebu_pcie_enable(pcie);
>
> +#ifdef CONFIG_PCI_MSI
> +       ret = mvebu_pcie_enable_msi(pcie);
> +       if (ret)
> +               dev_warn(&pdev->dev, "could not enable MSI support: %d\n",
> +                        ret);
> +#endif
> +
>         return 0;
>  }
>
> --
> 1.7.9.5
>


From simon.guinot at sequanux.org  Mon Apr  8 18:41:26 2013
From: simon.guinot at sequanux.org (Simon Guinot)
Date: Tue,  9 Apr 2013 00:41:26 +0200
Subject: [PATCH v2 0/3] Add DT board setup for LaCie CloudBox
Message-ID: <1365460889-22965-1-git-send-email-simon.guinot@sequanux.org>

This patch series adds DT board setup for the LaCie CloudBox machine.
Note that two patches have been added for this v2. The first,
"ARM: Kirkwood: sort board entries by ASCII-code order" helps to respect
alphabetical order while adding a new board entry. The last,
"ARM: Kirkwood: update Network Space Mini v2 description" could be
useful to differentiate the cloudbox and netspace_v2_mini machines
(both embedded in products named LaCie CloudBox).

Regards,

Simon

Changes for v2:
 - Add patch "ARM: Kirkwood: sort board entries by ASCII-code order".
 - Add patch "ARM: Kirkwood: update Network Space Mini v2 description".
 - Rebase against Jason's branch marvell/mvebu/boards.
 - Remove i2c pinctrl declaration (not used).
 - For all modified files, respect alphabetical order while inserting cloudbox
   entries.
 - Enhance patch description to avoid confusion between the two LaCie
   products named CloudBox.

Simon Guinot (3):
  ARM: Kirkwood: sort board entries by ASCII-code order
  ARM: Kirkwood: DT board setup for CloudBox
  ARM: Kirkwood: update Network Space Mini v2 description

 arch/arm/boot/dts/Makefile              |    3 +-
 arch/arm/boot/dts/kirkwood-cloudbox.dts |   89 +++++++++
 arch/arm/boot/dts/kirkwood-ns2mini.dts  |    1 +
 arch/arm/configs/kirkwood_defconfig     |   51 ++---
 arch/arm/mach-kirkwood/Kconfig          |  325 ++++++++++++++++---------------
 arch/arm/mach-kirkwood/Makefile         |   41 ++--
 arch/arm/mach-kirkwood/board-dt.c       |   14 +-
 arch/arm/mach-kirkwood/board-ns2.c      |    3 +-
 arch/arm/mach-kirkwood/common.h         |    6 +
 9 files changed, 324 insertions(+), 209 deletions(-)
 create mode 100644 arch/arm/boot/dts/kirkwood-cloudbox.dts

-- 
1.7.10.4



From simon.guinot at sequanux.org  Mon Apr  8 18:41:27 2013
From: simon.guinot at sequanux.org (Simon Guinot)
Date: Tue,  9 Apr 2013 00:41:27 +0200
Subject: [PATCH v2 1/3] ARM: Kirkwood: sort board entries by ASCII-code order
In-Reply-To: <1365460889-22965-1-git-send-email-simon.guinot@sequanux.org>
References: <1365460889-22965-1-git-send-email-simon.guinot@sequanux.org>
Message-ID: <1365460889-22965-2-git-send-email-simon.guinot@sequanux.org>

This patch sorts board entries in files Kconfig, Makefile and
kirkwood_defconfig by ASCII-code order.

Signed-off-by: Simon Guinot <simon.guinot at sequanux.org>
---
 arch/arm/configs/kirkwood_defconfig |   50 +++---
 arch/arm/mach-kirkwood/Kconfig      |  314 ++++++++++++++++++-----------------
 arch/arm/mach-kirkwood/Makefile     |   40 ++---
 3 files changed, 203 insertions(+), 201 deletions(-)

diff --git a/arch/arm/configs/kirkwood_defconfig b/arch/arm/configs/kirkwood_defconfig
index 46d704a..0421d0f 100644
--- a/arch/arm/configs/kirkwood_defconfig
+++ b/arch/arm/configs/kirkwood_defconfig
@@ -10,47 +10,47 @@ CONFIG_MODULES=y
 CONFIG_MODULE_UNLOAD=y
 # CONFIG_BLK_DEV_BSG is not set
 CONFIG_ARCH_KIRKWOOD=y
+CONFIG_MACH_D2NET_V2=y
 CONFIG_MACH_DB88F6281_BP=y
+CONFIG_MACH_DOCKSTAR=y
+CONFIG_MACH_ESATA_SHEEVAPLUG=y
+CONFIG_MACH_GURUPLUG=y
+CONFIG_MACH_INETSPACE_V2=y
+CONFIG_MACH_MV88F6281GTW_GE=y
+CONFIG_MACH_NET2BIG_V2=y
+CONFIG_MACH_NET5BIG_V2=y
+CONFIG_MACH_NETSPACE_MAX_V2=y
+CONFIG_MACH_NETSPACE_V2=y
+CONFIG_MACH_OPENRD_BASE=y
+CONFIG_MACH_OPENRD_CLIENT=y
+CONFIG_MACH_OPENRD_ULTIMATE=y
 CONFIG_MACH_RD88F6192_NAS=y
 CONFIG_MACH_RD88F6281=y
-CONFIG_MACH_MV88F6281GTW_GE=y
 CONFIG_MACH_SHEEVAPLUG=y
-CONFIG_MACH_ESATA_SHEEVAPLUG=y
-CONFIG_MACH_GURUPLUG=y
-CONFIG_MACH_DREAMPLUG_DT=y
-CONFIG_MACH_ICONNECT_DT=y
+CONFIG_MACH_T5325=y
+CONFIG_MACH_TS219=y
+CONFIG_MACH_TS41X=y
 CONFIG_MACH_DLINK_KIRKWOOD_DT=y
-CONFIG_MACH_IB62X0_DT=y
-CONFIG_MACH_TS219_DT=y
 CONFIG_MACH_DOCKSTAR_DT=y
+CONFIG_MACH_DREAMPLUG_DT=y
 CONFIG_MACH_GOFLEXNET_DT=y
 CONFIG_MACH_GURUPLUG_DT=y
-CONFIG_MACH_LSXL_DT=y
+CONFIG_MACH_IB62X0_DT=y
+CONFIG_MACH_ICONNECT_DT=y
+CONFIG_MACH_INETSPACE_V2_DT=y
 CONFIG_MACH_IOMEGA_IX2_200_DT=y
 CONFIG_MACH_KM_KIRKWOOD_DT=y
-CONFIG_MACH_INETSPACE_V2_DT=y
+CONFIG_MACH_LSXL_DT=y
 CONFIG_MACH_MPLCEC4_DT=y
-CONFIG_MACH_NETSPACE_V2_DT=y
-CONFIG_MACH_NETSPACE_MAX_V2_DT=y
 CONFIG_MACH_NETSPACE_LITE_V2_DT=y
+CONFIG_MACH_NETSPACE_MAX_V2_DT=y
 CONFIG_MACH_NETSPACE_MINI_V2_DT=y
+CONFIG_MACH_NETSPACE_V2_DT=y
+CONFIG_MACH_NSA310_DT=y
 CONFIG_MACH_OPENBLOCKS_A6_DT=y
 CONFIG_MACH_READYNAS_DT=y
 CONFIG_MACH_TOPKICK_DT=y
-CONFIG_MACH_TS219=y
-CONFIG_MACH_TS41X=y
-CONFIG_MACH_DOCKSTAR=y
-CONFIG_MACH_OPENRD_BASE=y
-CONFIG_MACH_OPENRD_CLIENT=y
-CONFIG_MACH_OPENRD_ULTIMATE=y
-CONFIG_MACH_NETSPACE_V2=y
-CONFIG_MACH_INETSPACE_V2=y
-CONFIG_MACH_NETSPACE_MAX_V2=y
-CONFIG_MACH_D2NET_V2=y
-CONFIG_MACH_NET2BIG_V2=y
-CONFIG_MACH_NET5BIG_V2=y
-CONFIG_MACH_T5325=y
-CONFIG_MACH_NSA310_DT=y
+CONFIG_MACH_TS219_DT=y
 # CONFIG_CPU_FEROCEON_OLD_ID is not set
 CONFIG_PREEMPT=y
 CONFIG_AEABI=y
diff --git a/arch/arm/mach-kirkwood/Kconfig b/arch/arm/mach-kirkwood/Kconfig
index 3fd07eb..938395a 100644
--- a/arch/arm/mach-kirkwood/Kconfig
+++ b/arch/arm/mach-kirkwood/Kconfig
@@ -2,23 +2,41 @@ if ARCH_KIRKWOOD
 
 menu "Marvell Kirkwood Implementations"
 
+config MACH_D2NET_V2
+	bool "LaCie d2 Network v2 NAS Board"
+	help
+	  Say 'Y' here if you want your kernel to support the
+	  LaCie d2 Network v2 NAS.
+
 config MACH_DB88F6281_BP
 	bool "Marvell DB-88F6281-BP Development Board"
 	help
 	  Say 'Y' here if you want your kernel to support the
 	  Marvell DB-88F6281-BP Development Board.
 
-config MACH_RD88F6192_NAS
-	bool "Marvell RD-88F6192-NAS Reference Board"
+config MACH_DOCKSTAR
+	bool "Seagate FreeAgent DockStar"
 	help
 	  Say 'Y' here if you want your kernel to support the
-	  Marvell RD-88F6192-NAS Reference Board.
+	  Seagate FreeAgent DockStar.
 
-config MACH_RD88F6281
-	bool "Marvell RD-88F6281 Reference Board"
+config MACH_ESATA_SHEEVAPLUG
+	bool "Marvell eSATA SheevaPlug Reference Board"
 	help
 	  Say 'Y' here if you want your kernel to support the
-	  Marvell RD-88F6281 Reference Board.
+	  Marvell eSATA SheevaPlug Reference Board.
+
+config MACH_GURUPLUG
+	bool "Marvell GuruPlug Reference Board"
+	help
+	  Say 'Y' here if you want your kernel to support the
+	  Marvell GuruPlug Reference Board.
+
+config MACH_INETSPACE_V2
+	bool "LaCie Internet Space v2 NAS Board"
+	help
+	  Say 'Y' here if you want your kernel to support the
+	  LaCie Internet Space v2 NAS.
 
 config MACH_MV88F6281GTW_GE
 	bool "Marvell 88F6281 GTW GE Board"
@@ -26,23 +44,93 @@ config MACH_MV88F6281GTW_GE
 	  Say 'Y' here if you want your kernel to support the
 	  Marvell 88F6281 GTW GE Board.
 
+config MACH_NET2BIG_V2
+	bool "LaCie 2Big Network v2 NAS Board"
+	help
+	  Say 'Y' here if you want your kernel to support the
+	  LaCie 2Big Network v2 NAS.
+
+config MACH_NET5BIG_V2
+	bool "LaCie 5Big Network v2 NAS Board"
+	help
+	  Say 'Y' here if you want your kernel to support the
+	  LaCie 5Big Network v2 NAS.
+
+config MACH_NETSPACE_MAX_V2
+	bool "LaCie Network Space Max v2 NAS Board"
+	help
+	  Say 'Y' here if you want your kernel to support the
+	  LaCie Network Space Max v2 NAS.
+
+config MACH_NETSPACE_V2
+	bool "LaCie Network Space v2 NAS Board"
+	help
+	  Say 'Y' here if you want your kernel to support the
+	  LaCie Network Space v2 NAS.
+
+config MACH_OPENRD
+        bool
+
+config MACH_OPENRD_BASE
+	bool "Marvell OpenRD Base Board"
+	select MACH_OPENRD
+	help
+	  Say 'Y' here if you want your kernel to support the
+	  Marvell OpenRD Base Board.
+
+config MACH_OPENRD_CLIENT
+	bool "Marvell OpenRD Client Board"
+	select MACH_OPENRD
+	help
+	  Say 'Y' here if you want your kernel to support the
+	  Marvell OpenRD Client Board.
+
+config MACH_OPENRD_ULTIMATE
+	bool "Marvell OpenRD Ultimate Board"
+	select MACH_OPENRD
+	help
+	  Say 'Y' here if you want your kernel to support the
+	  Marvell OpenRD Ultimate Board.
+
+config MACH_RD88F6192_NAS
+	bool "Marvell RD-88F6192-NAS Reference Board"
+	help
+	  Say 'Y' here if you want your kernel to support the
+	  Marvell RD-88F6192-NAS Reference Board.
+
+config MACH_RD88F6281
+	bool "Marvell RD-88F6281 Reference Board"
+	help
+	  Say 'Y' here if you want your kernel to support the
+	  Marvell RD-88F6281 Reference Board.
+
 config MACH_SHEEVAPLUG
 	bool "Marvell SheevaPlug Reference Board"
 	help
 	  Say 'Y' here if you want your kernel to support the
 	  Marvell SheevaPlug Reference Board.
 
-config MACH_ESATA_SHEEVAPLUG
-	bool "Marvell eSATA SheevaPlug Reference Board"
+config MACH_T5325
+	bool "HP t5325 Thin Client"
 	help
 	  Say 'Y' here if you want your kernel to support the
-	  Marvell eSATA SheevaPlug Reference Board.
+	  HP t5325 Thin Client.
 
-config MACH_GURUPLUG
-	bool "Marvell GuruPlug Reference Board"
+config MACH_TS219
+	bool "QNAP TS-110, TS-119, TS-119P+, TS-210, TS-219, TS-219P and TS-219P+ Turbo NAS"
 	help
 	  Say 'Y' here if you want your kernel to support the
-	  Marvell GuruPlug Reference Board.
+	  QNAP TS-110, TS-119, TS-119P+, TS-210, TS-219, TS-219P and
+	  TS-219P+ Turbo NAS devices.
+
+config MACH_TS41X
+	bool "QNAP TS-410, TS-410U, TS-419P, TS-419P+ and TS-419U Turbo NAS"
+	help
+	  Say 'Y' here if you want your kernel to support the
+	  QNAP TS-410, TS-410U, TS-419P, TS-419P+ and TS-419U Turbo
+	  NAS devices.
+
+comment "Device tree entries"
 
 config ARCH_KIRKWOOD_DT
 	bool "Marvell Kirkwood Flattened Device Tree"
@@ -58,12 +146,20 @@ config ARCH_KIRKWOOD_DT
 	  Say 'Y' here if you want your kernel to support the
 	  Marvell Kirkwood using flattened device tree.
 
-config MACH_GURUPLUG_DT
-	bool "Marvell GuruPlug Reference Board (Flattened Device Tree)"
+config MACH_DLINK_KIRKWOOD_DT
+	bool "D-Link Kirkwood-based NAS (Flattened Device Tree)"
 	select ARCH_KIRKWOOD_DT
 	help
 	  Say 'Y' here if you want your kernel to support the
-	  Marvell GuruPlug Reference Board (Flattened Device Tree).
+	  Kirkwood-based D-Link NASes such as DNS-320 & DNS-325,
+	  using Flattened Device Tree.
+
+config MACH_DOCKSTAR_DT
+	bool "Seagate FreeAgent Dockstar (Flattened Device Tree)"
+	select ARCH_KIRKWOOD_DT
+	help
+	  Say 'Y' here if you want your kernel to support the
+	  Seagate FreeAgent Dockstar (Flattened Device Tree).
 
 config MACH_DREAMPLUG_DT
 	bool "Marvell DreamPlug (Flattened Device Tree)"
@@ -72,19 +168,19 @@ config MACH_DREAMPLUG_DT
 	  Say 'Y' here if you want your kernel to support the
 	  Marvell DreamPlug (Flattened Device Tree).
 
-config MACH_ICONNECT_DT
-	bool "Iomega Iconnect (Flattened Device Tree)"
+config MACH_GOFLEXNET_DT
+	bool "Seagate GoFlex Net (Flattened Device Tree)"
 	select ARCH_KIRKWOOD_DT
 	help
-	  Say 'Y' here to enable Iomega Iconnect support.
+	  Say 'Y' here if you want your kernel to support the
+	  Seagate GoFlex Net (Flattened Device Tree).
 
-config MACH_DLINK_KIRKWOOD_DT
-	bool "D-Link Kirkwood-based NAS (Flattened Device Tree)"
+config MACH_GURUPLUG_DT
+	bool "Marvell GuruPlug Reference Board (Flattened Device Tree)"
 	select ARCH_KIRKWOOD_DT
 	help
 	  Say 'Y' here if you want your kernel to support the
-	  Kirkwood-based D-Link NASes such as DNS-320 & DNS-325,
-	  using Flattened Device Tree.
+	  Marvell GuruPlug Reference Board (Flattened Device Tree).
 
 config MACH_IB62X0_DT
 	bool "RaidSonic IB-NAS6210, IB-NAS6220 (Flattened Device Tree)"
@@ -94,41 +190,18 @@ config MACH_IB62X0_DT
 	  RaidSonic IB-NAS6210 & IB-NAS6220 devices, using
 	  Flattened Device Tree.
 
-config MACH_TS219_DT
-	bool "Device Tree for QNAP TS-11X, TS-21X NAS"
-	select ARCH_KIRKWOOD_DT
-	select ARM_APPENDED_DTB
-	select ARM_ATAG_DTB_COMPAT
-	help
-	  Say 'Y' here if you want your kernel to support the QNAP
-	  TS-110, TS-119, TS-119P+, TS-210, TS-219, TS-219P and
-	  TS-219P+ Turbo NAS devices using Fattened Device Tree.
-	  There are two different Device Tree descriptions, depending
-	  on if the device is based on an if the board uses the MV6281
-	  or MV6282. If you have the wrong one, the buttons will not
-	  work.
-
-config MACH_DOCKSTAR_DT
-	bool "Seagate FreeAgent Dockstar (Flattened Device Tree)"
-	select ARCH_KIRKWOOD_DT
-	help
-	  Say 'Y' here if you want your kernel to support the
-	  Seagate FreeAgent Dockstar (Flattened Device Tree).
-
-config MACH_GOFLEXNET_DT
-	bool "Seagate GoFlex Net (Flattened Device Tree)"
+config MACH_ICONNECT_DT
+	bool "Iomega Iconnect (Flattened Device Tree)"
 	select ARCH_KIRKWOOD_DT
 	help
-	  Say 'Y' here if you want your kernel to support the
-	  Seagate GoFlex Net (Flattened Device Tree).
+	  Say 'Y' here to enable Iomega Iconnect support.
 
-config MACH_LSXL_DT
-	bool "Buffalo Linkstation LS-XHL, LS-CHLv2 (Flattened Device Tree)"
+config MACH_INETSPACE_V2_DT
+	bool "LaCie Internet Space v2 NAS (Flattened Device Tree)"
 	select ARCH_KIRKWOOD_DT
 	help
-	  Say 'Y' here if you want your kernel to support the
-	  Buffalo Linkstation LS-XHL & LS-CHLv2 devices, using
-	  Flattened Device Tree.
+	  Say 'Y' here if you want your kernel to support the LaCie
+	  Internet Space v2 NAS, using Flattened Device Tree.
 
 config MACH_IOMEGA_IX2_200_DT
 	bool "Iomega StorCenter ix2-200 (Flattened Device Tree)"
@@ -144,12 +217,13 @@ config MACH_KM_KIRKWOOD_DT
 	  Say 'Y' here if you want your kernel to support the
 	  Keymile Kirkwood Reference Desgin, using Flattened Device Tree.
 
-config MACH_INETSPACE_V2_DT
-	bool "LaCie Internet Space v2 NAS (Flattened Device Tree)"
+config MACH_LSXL_DT
+	bool "Buffalo Linkstation LS-XHL, LS-CHLv2 (Flattened Device Tree)"
 	select ARCH_KIRKWOOD_DT
 	help
-	  Say 'Y' here if you want your kernel to support the LaCie
-	  Internet Space v2 NAS, using Flattened Device Tree.
+	  Say 'Y' here if you want your kernel to support the
+	  Buffalo Linkstation LS-XHL & LS-CHLv2 devices, using
+	  Flattened Device Tree.
 
 config MACH_MPLCEC4_DT
 	bool "MPL CEC4 (Flattened Device Tree)"
@@ -158,12 +232,12 @@ config MACH_MPLCEC4_DT
 	  Say 'Y' here if you want your kernel to support the
 	  MPL CEC4 (Flattened Device Tree).
 
-config MACH_NETSPACE_V2_DT
-	bool "LaCie Network Space v2 NAS (Flattened Device Tree)"
+config MACH_NETSPACE_LITE_V2_DT
+	bool "LaCie Network Space Lite v2 NAS (Flattened Device Tree)"
 	select ARCH_KIRKWOOD_DT
 	help
 	  Say 'Y' here if you want your kernel to support the LaCie
-	  Network Space v2 NAS, using Flattened Device Tree.
+	  Network Space Lite v2 NAS, using Flattened Device Tree.
 
 config MACH_NETSPACE_MAX_V2_DT
 	bool "LaCie Network Space Max v2 NAS (Flattened Device Tree)"
@@ -172,13 +246,6 @@ config MACH_NETSPACE_MAX_V2_DT
 	  Say 'Y' here if you want your kernel to support the LaCie
 	  Network Space Max v2 NAS, using Flattened Device Tree.
 
-config MACH_NETSPACE_LITE_V2_DT
-	bool "LaCie Network Space Lite v2 NAS (Flattened Device Tree)"
-	select ARCH_KIRKWOOD_DT
-	help
-	  Say 'Y' here if you want your kernel to support the LaCie
-	  Network Space Lite v2 NAS, using Flattened Device Tree.
-
 config MACH_NETSPACE_MINI_V2_DT
 	bool "LaCie Network Space Mini v2 NAS (Flattened Device Tree)"
 	select ARCH_KIRKWOOD_DT
@@ -187,6 +254,21 @@ config MACH_NETSPACE_MINI_V2_DT
 	  Network Space Mini v2 NAS (aka SafeBox), using Flattened
 	  Device Tree.
 
+config MACH_NETSPACE_V2_DT
+	bool "LaCie Network Space v2 NAS (Flattened Device Tree)"
+	select ARCH_KIRKWOOD_DT
+	help
+	  Say 'Y' here if you want your kernel to support the LaCie
+	  Network Space v2 NAS, using Flattened Device Tree.
+
+config MACH_NSA310_DT
+	bool "ZyXEL NSA-310 (Flattened Device Tree)"
+	select ARCH_KIRKWOOD_DT
+	select ARM_ATAG_DTB_COMPAT
+	help
+	  Say 'Y' here if you want your kernel to support the
+	  ZyXEL NSA-310 board (Flattened Device Tree).
+
 config MACH_OPENBLOCKS_A6_DT
 	bool "Plat'Home OpenBlocks A6 (Flattened Device Tree)"
 	select ARCH_KIRKWOOD_DT
@@ -210,99 +292,19 @@ config MACH_TOPKICK_DT
 	  Say 'Y' here if you want your kernel to support the
 	  USI Topkick, using Flattened Device Tree
 
-config MACH_TS219
-	bool "QNAP TS-110, TS-119, TS-119P+, TS-210, TS-219, TS-219P and TS-219P+ Turbo NAS"
-	help
-	  Say 'Y' here if you want your kernel to support the
-	  QNAP TS-110, TS-119, TS-119P+, TS-210, TS-219, TS-219P and
-	  TS-219P+ Turbo NAS devices.
-
-config MACH_TS41X
-	bool "QNAP TS-410, TS-410U, TS-419P, TS-419P+ and TS-419U Turbo NAS"
-	help
-	  Say 'Y' here if you want your kernel to support the
-	  QNAP TS-410, TS-410U, TS-419P, TS-419P+ and TS-419U Turbo
-	  NAS devices.
-
-config MACH_DOCKSTAR
-	bool "Seagate FreeAgent DockStar"
-	help
-	  Say 'Y' here if you want your kernel to support the
-	  Seagate FreeAgent DockStar.
-
-config MACH_OPENRD
-        bool
-
-config MACH_OPENRD_BASE
-	bool "Marvell OpenRD Base Board"
-	select MACH_OPENRD
-	help
-	  Say 'Y' here if you want your kernel to support the
-	  Marvell OpenRD Base Board.
-
-config MACH_OPENRD_CLIENT
-	bool "Marvell OpenRD Client Board"
-	select MACH_OPENRD
-	help
-	  Say 'Y' here if you want your kernel to support the
-	  Marvell OpenRD Client Board.
-
-config MACH_OPENRD_ULTIMATE
-	bool "Marvell OpenRD Ultimate Board"
-	select MACH_OPENRD
-	help
-	  Say 'Y' here if you want your kernel to support the
-	  Marvell OpenRD Ultimate Board.
-
-config MACH_NETSPACE_V2
-	bool "LaCie Network Space v2 NAS Board"
-	help
-	  Say 'Y' here if you want your kernel to support the
-	  LaCie Network Space v2 NAS.
-
-config MACH_INETSPACE_V2
-	bool "LaCie Internet Space v2 NAS Board"
-	help
-	  Say 'Y' here if you want your kernel to support the
-	  LaCie Internet Space v2 NAS.
-
-config MACH_NETSPACE_MAX_V2
-	bool "LaCie Network Space Max v2 NAS Board"
-	help
-	  Say 'Y' here if you want your kernel to support the
-	  LaCie Network Space Max v2 NAS.
-
-config MACH_D2NET_V2
-	bool "LaCie d2 Network v2 NAS Board"
-	help
-	  Say 'Y' here if you want your kernel to support the
-	  LaCie d2 Network v2 NAS.
-
-config MACH_NET2BIG_V2
-	bool "LaCie 2Big Network v2 NAS Board"
-	help
-	  Say 'Y' here if you want your kernel to support the
-	  LaCie 2Big Network v2 NAS.
-
-config MACH_NET5BIG_V2
-	bool "LaCie 5Big Network v2 NAS Board"
-	help
-	  Say 'Y' here if you want your kernel to support the
-	  LaCie 5Big Network v2 NAS.
-
-config MACH_T5325
-	bool "HP t5325 Thin Client"
-	help
-	  Say 'Y' here if you want your kernel to support the
-	  HP t5325 Thin Client.
-
-config MACH_NSA310_DT
-	bool "ZyXEL NSA-310 (Flattened Device Tree)"
+config MACH_TS219_DT
+	bool "Device Tree for QNAP TS-11X, TS-21X NAS"
 	select ARCH_KIRKWOOD_DT
+	select ARM_APPENDED_DTB
 	select ARM_ATAG_DTB_COMPAT
 	help
-	  Say 'Y' here if you want your kernel to support the
-	  ZyXEL NSA-310 board (Flattened Device Tree).
+	  Say 'Y' here if you want your kernel to support the QNAP
+	  TS-110, TS-119, TS-119P+, TS-210, TS-219, TS-219P and
+	  TS-219P+ Turbo NAS devices using Fattened Device Tree.
+	  There are two different Device Tree descriptions, depending
+	  on if the device is based on an if the board uses the MV6281
+	  or MV6282. If you have the wrong one, the buttons will not
+	  work.
 
 endmenu
 
diff --git a/arch/arm/mach-kirkwood/Makefile b/arch/arm/mach-kirkwood/Makefile
index ff0f3cb..5f1285d 100644
--- a/arch/arm/mach-kirkwood/Makefile
+++ b/arch/arm/mach-kirkwood/Makefile
@@ -1,43 +1,43 @@
 obj-y				+= common.o addr-map.o irq.o pcie.o mpp.o
 
+obj-$(CONFIG_MACH_D2NET_V2)		+= d2net_v2-setup.o lacie_v2-common.o
 obj-$(CONFIG_MACH_DB88F6281_BP)		+= db88f6281-bp-setup.o
-obj-$(CONFIG_MACH_RD88F6192_NAS)	+= rd88f6192-nas-setup.o
-obj-$(CONFIG_MACH_RD88F6281)		+= rd88f6281-setup.o
-obj-$(CONFIG_MACH_MV88F6281GTW_GE)	+= mv88f6281gtw_ge-setup.o
-obj-$(CONFIG_MACH_SHEEVAPLUG)		+= sheevaplug-setup.o
+obj-$(CONFIG_MACH_DOCKSTAR)		+= dockstar-setup.o
 obj-$(CONFIG_MACH_ESATA_SHEEVAPLUG)	+= sheevaplug-setup.o
 obj-$(CONFIG_MACH_GURUPLUG)		+= guruplug-setup.o
-obj-$(CONFIG_MACH_DOCKSTAR)		+= dockstar-setup.o
-obj-$(CONFIG_MACH_TS219)		+= ts219-setup.o tsx1x-common.o
-obj-$(CONFIG_MACH_TS41X)		+= ts41x-setup.o tsx1x-common.o
-obj-$(CONFIG_MACH_OPENRD)		+= openrd-setup.o
-obj-$(CONFIG_MACH_NETSPACE_V2)		+= netspace_v2-setup.o lacie_v2-common.o
 obj-$(CONFIG_MACH_INETSPACE_V2)		+= netspace_v2-setup.o lacie_v2-common.o
-obj-$(CONFIG_MACH_NETSPACE_MAX_V2)	+= netspace_v2-setup.o lacie_v2-common.o
-obj-$(CONFIG_MACH_D2NET_V2)		+= d2net_v2-setup.o lacie_v2-common.o
+obj-$(CONFIG_MACH_MV88F6281GTW_GE)	+= mv88f6281gtw_ge-setup.o
 obj-$(CONFIG_MACH_NET2BIG_V2)		+= netxbig_v2-setup.o lacie_v2-common.o
 obj-$(CONFIG_MACH_NET5BIG_V2)		+= netxbig_v2-setup.o lacie_v2-common.o
+obj-$(CONFIG_MACH_NETSPACE_MAX_V2)	+= netspace_v2-setup.o lacie_v2-common.o
+obj-$(CONFIG_MACH_NETSPACE_V2)		+= netspace_v2-setup.o lacie_v2-common.o
+obj-$(CONFIG_MACH_OPENRD)		+= openrd-setup.o
+obj-$(CONFIG_MACH_RD88F6192_NAS)	+= rd88f6192-nas-setup.o
+obj-$(CONFIG_MACH_RD88F6281)		+= rd88f6281-setup.o
+obj-$(CONFIG_MACH_SHEEVAPLUG)		+= sheevaplug-setup.o
 obj-$(CONFIG_MACH_T5325)		+= t5325-setup.o
+obj-$(CONFIG_MACH_TS219)		+= ts219-setup.o tsx1x-common.o
+obj-$(CONFIG_MACH_TS41X)		+= ts41x-setup.o tsx1x-common.o
 
 obj-$(CONFIG_ARCH_KIRKWOOD_DT)		+= board-dt.o
-obj-$(CONFIG_MACH_DREAMPLUG_DT)		+= board-dreamplug.o
-obj-$(CONFIG_MACH_GURUPLUG_DT)		+= board-guruplug.o
-obj-$(CONFIG_MACH_ICONNECT_DT)		+= board-iconnect.o
 obj-$(CONFIG_MACH_DLINK_KIRKWOOD_DT)	+= board-dnskw.o
-obj-$(CONFIG_MACH_IB62X0_DT)		+= board-ib62x0.o
-obj-$(CONFIG_MACH_TS219_DT)		+= board-ts219.o tsx1x-common.o
 obj-$(CONFIG_MACH_DOCKSTAR_DT)		+= board-dockstar.o
+obj-$(CONFIG_MACH_DREAMPLUG_DT)		+= board-dreamplug.o
 obj-$(CONFIG_MACH_GOFLEXNET_DT)		+= board-goflexnet.o
-obj-$(CONFIG_MACH_LSXL_DT)		+= board-lsxl.o
+obj-$(CONFIG_MACH_GURUPLUG_DT)		+= board-guruplug.o
+obj-$(CONFIG_MACH_IB62X0_DT)		+= board-ib62x0.o
+obj-$(CONFIG_MACH_ICONNECT_DT)		+= board-iconnect.o
+obj-$(CONFIG_MACH_INETSPACE_V2_DT)	+= board-ns2.o
 obj-$(CONFIG_MACH_IOMEGA_IX2_200_DT)	+= board-iomega_ix2_200.o
 obj-$(CONFIG_MACH_KM_KIRKWOOD_DT)	+= board-km_kirkwood.o
-obj-$(CONFIG_MACH_INETSPACE_V2_DT)	+= board-ns2.o
+obj-$(CONFIG_MACH_LSXL_DT)		+= board-lsxl.o
 obj-$(CONFIG_MACH_MPLCEC4_DT)		+= board-mplcec4.o
-obj-$(CONFIG_MACH_NETSPACE_V2_DT)	+= board-ns2.o
-obj-$(CONFIG_MACH_NETSPACE_MAX_V2_DT)	+= board-ns2.o
 obj-$(CONFIG_MACH_NETSPACE_LITE_V2_DT)	+= board-ns2.o
+obj-$(CONFIG_MACH_NETSPACE_MAX_V2_DT)	+= board-ns2.o
 obj-$(CONFIG_MACH_NETSPACE_MINI_V2_DT)	+= board-ns2.o
+obj-$(CONFIG_MACH_NETSPACE_V2_DT)	+= board-ns2.o
 obj-$(CONFIG_MACH_NSA310_DT)		+= board-nsa310.o
 obj-$(CONFIG_MACH_OPENBLOCKS_A6_DT)	+= board-openblocks_a6.o
 obj-$(CONFIG_MACH_READYNAS_DT)		+= board-readynas.o
 obj-$(CONFIG_MACH_TOPKICK_DT)		+= board-usi_topkick.o
+obj-$(CONFIG_MACH_TS219_DT)		+= board-ts219.o tsx1x-common.o
-- 
1.7.10.4



From simon.guinot at sequanux.org  Mon Apr  8 18:41:28 2013
From: simon.guinot at sequanux.org (Simon Guinot)
Date: Tue,  9 Apr 2013 00:41:28 +0200
Subject: [PATCH v2 2/3] ARM: Kirkwood: DT board setup for CloudBox
In-Reply-To: <1365460889-22965-1-git-send-email-simon.guinot@sequanux.org>
References: <1365460889-22965-1-git-send-email-simon.guinot@sequanux.org>
Message-ID: <1365460889-22965-3-git-send-email-simon.guinot@sequanux.org>

This patch adds DT board setup for the LaCie NAS CloudBox. The CloudBox
is a low cost NAS based on the Network Space v2.

Chipset list:
- CPU MARVELL 88F6702 1Ghz
- SDRAM memory: 256MB DDR2-800 (2x128MB x8) 400Mhz
- 1 Ethernet Gigabit port (PHY MARVELL 88E1318)
- SPI flash, NOR 512KB
- 1 push button
- 2 LEDs (red and blue)

There is no EEPROM and no USB ports embedded.

Note that this board must not be confused with the Network Space Mini v2
which is embedded in a previous LaCie product also named CloudBox.

Signed-off-by: Simon Guinot <simon.guinot at sequanux.org>
---
Changes for v2:
 - Rebase against Jason's branch marvell/mvebu/boards.
 - Remove i2c pinctrl declaration (not used).
 - For all modified files, respect alphabetical order while inserting cloudbox
   entries.
 - Enhance patch description to avoid confusion between the two LaCie
   products named CloudBox.

 arch/arm/boot/dts/Makefile              |    3 +-
 arch/arm/boot/dts/kirkwood-cloudbox.dts |   89 +++++++++++++++++++++++++++++++
 arch/arm/configs/kirkwood_defconfig     |    1 +
 arch/arm/mach-kirkwood/Kconfig          |    7 +++
 arch/arm/mach-kirkwood/Makefile         |    1 +
 arch/arm/mach-kirkwood/board-dt.c       |   14 ++---
 arch/arm/mach-kirkwood/board-ns2.c      |    3 +-
 arch/arm/mach-kirkwood/common.h         |    6 +++
 8 files changed, 116 insertions(+), 8 deletions(-)
 create mode 100644 arch/arm/boot/dts/kirkwood-cloudbox.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 125211d..c56f20f 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -51,7 +51,8 @@ dtb-$(CONFIG_ARCH_HIGHBANK) += highbank.dtb \
 dtb-$(CONFIG_ARCH_INTEGRATOR) += integratorap.dtb \
 	integratorcp.dtb
 dtb-$(CONFIG_ARCH_LPC32XX) += ea3250.dtb phy3250.dtb
-dtb-$(CONFIG_ARCH_KIRKWOOD) += kirkwood-dns320.dtb \
+dtb-$(CONFIG_ARCH_KIRKWOOD) += kirkwood-cloudbox.dtb \
+	kirkwood-dns320.dtb \
 	kirkwood-dns325.dtb \
 	kirkwood-dockstar.dtb \
 	kirkwood-dreamplug.dtb \
diff --git a/arch/arm/boot/dts/kirkwood-cloudbox.dts b/arch/arm/boot/dts/kirkwood-cloudbox.dts
new file mode 100644
index 0000000..5f21d4e
--- /dev/null
+++ b/arch/arm/boot/dts/kirkwood-cloudbox.dts
@@ -0,0 +1,89 @@
+/dts-v1/;
+
+/include/ "kirkwood.dtsi"
+/include/ "kirkwood-6281.dtsi"
+
+/ {
+	model = "LaCie CloudBox";
+	compatible = "lacie,cloudbox", "marvell,kirkwood-88f6702", "marvell,kirkwood";
+
+	memory {
+		device_type = "memory";
+		reg = <0x00000000 0x10000000>;
+	};
+
+	chosen {
+		bootargs = "console=ttyS0,115200n8";
+	};
+
+	ocp at f1000000 {
+		pinctrl: pinctrl at 10000 {
+			pinctrl-0 = < &pmx_spi &pmx_uart0
+					&pmx_cloudbox_sata0 >;
+			pinctrl-names = "default";
+
+			pmx_cloudbox_sata0: pmx-cloudbox-sata0 {
+				marvell,pins = "mpp15";
+				marvell,function = "sata0";
+			};
+		};
+
+		serial at 12000 {
+			clock-frequency = <166666667>;
+			status = "okay";
+		};
+
+		sata at 80000 {
+			status = "okay";
+			nr-ports = <1>;
+		};
+
+		spi at 10600 {
+			status = "okay";
+
+			flash at 0 {
+				#address-cells = <1>;
+				#size-cells = <1>;
+				compatible = "mx25l4005a";
+				reg = <0>;
+				spi-max-frequency = <20000000>;
+				mode = <0>;
+
+				partition at 0 {
+					reg = <0x0 0x80000>;
+					label = "u-boot";
+				};
+			};
+		};
+	};
+
+	gpio_keys {
+		compatible = "gpio-keys";
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		button at 1 {
+			label = "Power push button";
+			linux,code = <116>;
+			gpios = <&gpio0 16 1>;
+		};
+	};
+
+	gpio-leds {
+		compatible = "gpio-leds";
+
+		red-fail {
+			label = "cloudbox:red:fail";
+			gpios = <&gpio0 14 0>;
+		};
+		blue-sata {
+			label = "cloudbox:blue:sata";
+			gpios = <&gpio0 15 0>;
+		};
+	};
+
+	gpio_poweroff {
+		compatible = "gpio-poweroff";
+		gpios = <&gpio0 17 0>;
+	};
+};
diff --git a/arch/arm/configs/kirkwood_defconfig b/arch/arm/configs/kirkwood_defconfig
index 0421d0f..7205a7a 100644
--- a/arch/arm/configs/kirkwood_defconfig
+++ b/arch/arm/configs/kirkwood_defconfig
@@ -30,6 +30,7 @@ CONFIG_MACH_SHEEVAPLUG=y
 CONFIG_MACH_T5325=y
 CONFIG_MACH_TS219=y
 CONFIG_MACH_TS41X=y
+CONFIG_MACH_CLOUDBOX_DT=y
 CONFIG_MACH_DLINK_KIRKWOOD_DT=y
 CONFIG_MACH_DOCKSTAR_DT=y
 CONFIG_MACH_DREAMPLUG_DT=y
diff --git a/arch/arm/mach-kirkwood/Kconfig b/arch/arm/mach-kirkwood/Kconfig
index 938395a..45ab2f5 100644
--- a/arch/arm/mach-kirkwood/Kconfig
+++ b/arch/arm/mach-kirkwood/Kconfig
@@ -146,6 +146,13 @@ config ARCH_KIRKWOOD_DT
 	  Say 'Y' here if you want your kernel to support the
 	  Marvell Kirkwood using flattened device tree.
 
+config MACH_CLOUDBOX_DT
+	bool "LaCie CloudBox NAS (Flattened Device Tree)"
+	select ARCH_KIRKWOOD_DT
+	help
+	  Say 'Y' here if you want your kernel to support the LaCie
+	  CloudBox NAS, using Flattened Device Tree.
+
 config MACH_DLINK_KIRKWOOD_DT
 	bool "D-Link Kirkwood-based NAS (Flattened Device Tree)"
 	select ARCH_KIRKWOOD_DT
diff --git a/arch/arm/mach-kirkwood/Makefile b/arch/arm/mach-kirkwood/Makefile
index 5f1285d..cdbca32 100644
--- a/arch/arm/mach-kirkwood/Makefile
+++ b/arch/arm/mach-kirkwood/Makefile
@@ -20,6 +20,7 @@ obj-$(CONFIG_MACH_TS219)		+= ts219-setup.o tsx1x-common.o
 obj-$(CONFIG_MACH_TS41X)		+= ts41x-setup.o tsx1x-common.o
 
 obj-$(CONFIG_ARCH_KIRKWOOD_DT)		+= board-dt.o
+obj-$(CONFIG_MACH_CLOUDBOX_DT)		+= board-ns2.o
 obj-$(CONFIG_MACH_DLINK_KIRKWOOD_DT)	+= board-dnskw.o
 obj-$(CONFIG_MACH_DOCKSTAR_DT)		+= board-dockstar.o
 obj-$(CONFIG_MACH_DREAMPLUG_DT)		+= board-dreamplug.o
diff --git a/arch/arm/mach-kirkwood/board-dt.c b/arch/arm/mach-kirkwood/board-dt.c
index e5a3cfe..7904758 100644
--- a/arch/arm/mach-kirkwood/board-dt.c
+++ b/arch/arm/mach-kirkwood/board-dt.c
@@ -139,11 +139,12 @@ static void __init kirkwood_dt_init(void)
 	if (of_machine_is_compatible("keymile,km_kirkwood"))
 		km_kirkwood_init();
 
-	if (of_machine_is_compatible("lacie,inetspace_v2") ||
-	    of_machine_is_compatible("lacie,netspace_v2") ||
-	    of_machine_is_compatible("lacie,netspace_max_v2") ||
+	if (of_machine_is_compatible("lacie,cloudbox") ||
+	    of_machine_is_compatible("lacie,inetspace_v2") ||
 	    of_machine_is_compatible("lacie,netspace_lite_v2") ||
-	    of_machine_is_compatible("lacie,netspace_mini_v2"))
+	    of_machine_is_compatible("lacie,netspace_max_v2") ||
+	    of_machine_is_compatible("lacie,netspace_mini_v2") ||
+	    of_machine_is_compatible("lacie,netspace_v2"))
 		ns2_init();
 
 	if (of_machine_is_compatible("mpl,cec4"))
@@ -174,11 +175,12 @@ static const char * const kirkwood_dt_board_compat[] = {
 	"buffalo,lsxl",
 	"iom,ix2-200",
 	"keymile,km_kirkwood",
+	"lacie,cloudbox",
 	"lacie,inetspace_v2",
-	"lacie,netspace_max_v2",
-	"lacie,netspace_v2",
 	"lacie,netspace_lite_v2",
+	"lacie,netspace_max_v2",
 	"lacie,netspace_mini_v2",
+	"lacie,netspace_v2",
 	"mpl,cec4",
 	"netgear,readynas-duo-v2",
 	"plathome,openblocks-a6",
diff --git a/arch/arm/mach-kirkwood/board-ns2.c b/arch/arm/mach-kirkwood/board-ns2.c
index f2ea3b7..f8f6605 100644
--- a/arch/arm/mach-kirkwood/board-ns2.c
+++ b/arch/arm/mach-kirkwood/board-ns2.c
@@ -27,7 +27,8 @@ void __init ns2_init(void)
 	/*
 	 * Basic setup. Needs to be called early.
 	 */
-	if (of_machine_is_compatible("lacie,netspace_lite_v2") ||
+	if (of_machine_is_compatible("lacie,cloudbox") ||
+	    of_machine_is_compatible("lacie,netspace_lite_v2") ||
 	    of_machine_is_compatible("lacie,netspace_mini_v2"))
 		ns2_ge00_data.phy_addr = MV643XX_ETH_PHY_ADDR(0);
 	kirkwood_ge00_init(&ns2_ge00_data);
diff --git a/arch/arm/mach-kirkwood/common.h b/arch/arm/mach-kirkwood/common.h
index 7ee8670..3147be2 100644
--- a/arch/arm/mach-kirkwood/common.h
+++ b/arch/arm/mach-kirkwood/common.h
@@ -153,6 +153,12 @@ void usi_topkick_init(void);
 static inline void usi_topkick_init(void) {};
 #endif
 
+#ifdef CONFIG_MACH_CLOUDBOX_DT
+void cloudbox_init(void);
+#else
+static inline void cloudbox_init(void) {};
+#endif
+
 /* early init functions not converted to fdt yet */
 char *kirkwood_id(void);
 void kirkwood_l2_init(void);
-- 
1.7.10.4



From simon.guinot at sequanux.org  Mon Apr  8 18:41:29 2013
From: simon.guinot at sequanux.org (Simon Guinot)
Date: Tue,  9 Apr 2013 00:41:29 +0200
Subject: [PATCH v2 3/3] ARM: Kirkwood: update Network Space Mini v2 description
In-Reply-To: <1365460889-22965-1-git-send-email-simon.guinot@sequanux.org>
References: <1365460889-22965-1-git-send-email-simon.guinot@sequanux.org>
Message-ID: <1365460889-22965-4-git-send-email-simon.guinot@sequanux.org>

LaCie has released two products under the CloudBox name. The
netspace_mini_v2 machine is embedded in the oldest product. The cloudbox
machine is embedded in the newest one. In order to allow a CloudBox user
to select the right machine support, this patch adds some informations
to the netspace_mini_v2 Kconfig description. A comment is also added to
the dts file.

Signed-off-by: Simon Guinot <simon.guinot at sequanux.org>
---
 arch/arm/boot/dts/kirkwood-ns2mini.dts |    1 +
 arch/arm/mach-kirkwood/Kconfig         |    8 ++++++--
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/kirkwood-ns2mini.dts b/arch/arm/boot/dts/kirkwood-ns2mini.dts
index b79f5eb..adab1ab 100644
--- a/arch/arm/boot/dts/kirkwood-ns2mini.dts
+++ b/arch/arm/boot/dts/kirkwood-ns2mini.dts
@@ -3,6 +3,7 @@
 /include/ "kirkwood-ns2-common.dtsi"
 
 / {
+	/* This machine is embedded in the first LaCie CloudBox product. */
 	model = "LaCie Network Space Mini v2";
 	compatible = "lacie,netspace_mini_v2", "marvell,kirkwood-88f6192", "marvell,kirkwood";
 
diff --git a/arch/arm/mach-kirkwood/Kconfig b/arch/arm/mach-kirkwood/Kconfig
index 45ab2f5..7509a89 100644
--- a/arch/arm/mach-kirkwood/Kconfig
+++ b/arch/arm/mach-kirkwood/Kconfig
@@ -258,8 +258,12 @@ config MACH_NETSPACE_MINI_V2_DT
 	select ARCH_KIRKWOOD_DT
 	help
 	  Say 'Y' here if you want your kernel to support the LaCie
-	  Network Space Mini v2 NAS (aka SafeBox), using Flattened
-	  Device Tree.
+	  Network Space Mini v2 NAS using Flattened Device Tree.
+
+	  This board is embedded in a product named CloudBox, which
+	  provides automatic backup on a 100GB cloud storage. This
+	  should not confused with a more recent LaCie NAS also named
+	  CloudBox. For this last, the disk capacity is 1TB or above.
 
 config MACH_NETSPACE_V2_DT
 	bool "LaCie Network Space v2 NAS (Flattened Device Tree)"
-- 
1.7.10.4



From javier.martinez at collabora.co.uk  Mon Apr  8 18:44:05 2013
From: javier.martinez at collabora.co.uk (Javier Martinez Canillas)
Date: Tue, 09 Apr 2013 00:44:05 +0200
Subject: [PATCH 1/1] of/irq: store IRQ trigger/level in struct resource
 flags
In-Reply-To: <51633F26.7000400@gmail.com>
References: <1365148088-11175-1-git-send-email-javier.martinez@collabora.co.uk>
 <51633F26.7000400@gmail.com>
Message-ID: <51634835.5010302@collabora.co.uk>

On 04/09/2013 12:05 AM, Rob Herring wrote:
> On 04/05/2013 02:48 AM, Javier Martinez Canillas wrote:
>> According to Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
>> the "#interrupt-cells" property of an "interrupt-controller" is used
>> to define the number of cells needed to specify a single interrupt.
>> 
>> A commonly used variant is two cell on which #interrupt-cells = <2>
>> and the first cell defines the index of the interrupt in the controller
>> and the second cell is used to specify any of the following flags:
>> 
>>     - bits[3:0] trigger type and level flags
>>         1 = low-to-high edge triggered
>>         2 = high-to-low edge triggered
>>         4 = active high level-sensitive
>>         8 = active low level-sensitive
>> 
>> An example of an interrupt controller which use the two cell format is
>> the OMAP GPIO controller that allows GPIO lines to be used as IRQ
>> (Documentation/devicetree/bindings/gpio/gpio-omap.txt)
>> 
>> But setting #interrupt-cells = <2> on the OMAP GPIO device node and
>> specifying the GPIO-IRQ type and level flags on the second cell does not
>> store this value on the populated IORESOURCE_IRQ struct resource.
>> 
>> This is because when using an IRQ from an interrupt controller and
>> setting both cells (e.g:)
>> 
>> 	interrupt-parent = <&gpio6>;
>> 	interrupts = <16 8>;
>> 
>> A call to of_irq_to_resource() is made and this function calls to
>> irq_of_parse_and_map_type() to get the virtual IRQ mapped to the real
>> index for this interrupt controller. This IRQ number is populated on
>> the struct resource:
>> 
>> int of_irq_to_resource(struct device_node *dev, int index, struct resource *r)
>> {
>> 	int irq = irq_of_parse_and_map(dev, index);
>> 	..
>> 	r->start = r->end = irq;
>> }
>> 
>> irq_of_parse_and_map() calls to irq_create_of_mapping() which calls to
>> the correct xlate function handler according to "#interrupt-cells"
>> (irq_domain_xlate_onecell or irq_domain_xlate_twocell) and to
>> irq_set_irq_type() to set the IRQ type.
>> 
>> But the type is never returned so it can't be saved on the IRQ struct
>> resource flags member.
>> 
>> This means that drivers that need the IRQ type/level flags defined in
>> the DT won't be able to get it.
> 
> But the interrupt controllers that need the information should be able
> to get to it via irqd_get_trigger_type. What problem exactly are you
> trying to fix? What driver would use this?
>

Yes but this is not about the interrupt controller wanting this information but
a device driver that is using the IORESOURCE_IRQ struct resource that has the
information about the virtual IRQ associated with a GPIO-IRQ.

The driver doesn't know neither care if its IRQ line is connected to a line of
an real IRQ controller or to a GPIO controller that allows a GPIO line to be
used as an IRQ.

> My understanding of the IORESOURCE_IRQ_xxx (and DMA) bits are they are
> ISA specific and therefore should not be used on non-ISA buses.
> 

Many TI OMAP2+ SoC based boards have an SMSC LAN911x/912x controller
(drivers/net/ethernet/smsc/smsc911x.c) that is connected to the OMAP processor
through its General-Purpose Memory Controller (GPMC) and this LAN driver obtain
its IRQ and I/O address space from a struct resource IORESOURCE_IRQ and
IORESOURCE_MEM respectively, that is filled by the DeviceTree core.

It does this:

irq_res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
irq_flags = irq_res->flags & IRQF_TRIGGER_MASK;

Since of_irq_to_resource() doesn't fill the trigger/level flags on the
IORESOURCE_IRQ struct resource, irq_flags will always be 0 regarding the value
specified on the second cell of the "interrupts" DT property.

A previous discussion about this can be found here [1].

> Rob
> 
> 

Thanks a lot and best regards,
Javier

[1]: https://patchwork.kernel.org/patch/2194911/


From b-cousson at ti.com  Mon Apr  8 18:46:13 2013
From: b-cousson at ti.com (Benoit Cousson)
Date: Tue, 9 Apr 2013 00:46:13 +0200
Subject: [GIT PULL] ARM: OMAP: Device Tree for 3.10
Message-ID: <516348B5.3060400@ti.com>

Hi Tony,

Please pull the following commits for OMAP Device Tree for v3.10.

Note that the branch is based on two other branches:

- omap-devel-b-for-3.10 from Paul to get the AM33xx missing hwmod and thus avoid a regression with Santosh's hwmod cleanup including in this DT series [1]. It avoids breaking bisect if this series is merged before Paul's fixes.

- omap-for-v3.10/usb branch to avoid nasty merge conflict in omap3.dtsi and omap4.dtsi due to the DTS patches contains in the USB branch.

Regards,
Benoit

[1] https://patchwork.kernel.org/patch/2366291/

---

The following changes since commit 5852264f9d6139751796853fdfca9d5230cbfb97:
  Benoit Cousson (1):
        Merge tag 'omap-devel-b-for-3.10' of git://git.kernel.org/.../pjw/omap-pending into for_3.10/dts_merged

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.10/dts

Anil Kumar (3):
      ARM: dts: Add minimal DT support for DevKit8000
      ARM: dts: omap3-devkit8000: Enable audio support
      ARM: dts: omap3-devkit8000: Add NAND DT node

AnilKumar Ch (3):
      ARM: dts: AM33XX: Rename I2C and GPIO nodes
      ARM: dts: AM33XX: Add d_can instances to aliases
      ARM: dts: AM33XX: Add memory resource to d_can node

Felipe Balbi (1):
      ARM: dts: OMAP5: Add SPI nodes

Florian Vaussard (3):
      ARM: dts: omap3-overo: Add support for pwm-leds
      ARM: dts: omap3-overo: Add audio support
      ARM: dts: OMAP3: Add GPMC controller

Javier Martinez Canillas (5):
      ARM: dts: omap3: Add generic DT support for IGEP devices
      ARM: dts: omap3: Add support for IGEPv2 board
      ARM: dts: omap3: Add support for IGEP COM Module
      ARM: dts: OMAP3: reduce GPMC mapped registers address space
      Documentation: dt: gpio-omap: Move interrupt-controller from #interrupt-cells description

Jon Hunter (16):
      ARM: OMAP2+: Prepare for device-tree PMU support
      ARM: dts: OMAP2+: Add PMU nodes
      ARM: dts: OMAP2+: Add SDMA controller bindings and nodes
      ARM: dts: Add GPMC node for OMAP2, OMAP4 and OMAP5
      ARM: dts: Add OMAP2 gpio bindings
      ARM: dts: OMAP3+: Correct gpio #interrupts-cells property
      ARM: dts: OMAP3: Add reg and interrupt properties for gpio
      ARM: dts: OMAP3: Add support for OMAP3430 SDP board
      ARM: OMAP: Force dmtimer restore if context loss is not detectable
      ARM: OMAP: Add function to request timer by node
      ARM: dts: OMAP2+: Update DMTIMER compatibility property
      ARM: OMAP2+: Populate DMTIMER errata when using device-tree
      ARM: dts: OMAP2+: Identify GPIO banks that are always powered
      ARM: dts: Update OMAP3430 SDP NAND and ONENAND properties
      ARM: dts: Add NOR flash bindings for OMAP2420 H4
      ARM: dts: Add OMAP3430 SDP NOR flash memory binding

Kishon Vijay Abraham I (7):
      ARM: dts: OMAP4: Add omap control usb data
      ARM: dts: OMAP4: Add omap-usb2 data
      ARM: dts: OMAP: Add usb_otg and glue data to OMAP3+ boards
      ARM: dts: OMAP5: Add OMAP control usb data
      ARM: dts: OMAP5: Add ocp2scp data
      ARM: dts: OMAP5: Add omap-usb3 and omap-usb2 data
      ARM: dts: OMAP5: add dwc3 omap and dwc3 core data

Lokesh Vutla (1):
      ARM: dts: OMAP5: Add watchdog timer node

Matthias Brugger (1):
      ARM: dts: omap3-igep: Add uart1 and uart2 to igep boards

NeilBrown (1):
      ARM: OMAP: Simplify dmtimer context-loss handling

Nishanth Menon (6):
      ARM: dts: OMAP34xx/35xx: Add CPU OPP table
      ARM: dts: OMAP36xx: Add CPU OPP table
      ARM: dts: OMAP3: use twl4030 vdd1 regulator for CPU
      ARM: dts: OMAP443x: Add CPU OPP table
      ARM: dts: omap4-panda: move generic sections to panda-common
      ARM: dts: OMAP4460: Add CPU OPP table

Peter Ujfalusi (5):
      ARM: dts: twl4030: Add PWM support
      ARM: dts: twl6030: Add PWM support
      ARM: dts: omap3-beagle-xm: Use pwm-leds for pmu_stat LED
      ARM: dts: omap4-sdp: Add support for pwm-leds (keypad and charging LED)
      ARM: dts: omap4-sdp: Add support for pwm-backlight

Philip Avinash (1):
      ARM: dts: AM33XX: Corrects typo in interrupt field in SPI node

Rajendra Nayak (1):
      ARM: dts: OMAP5: Specify nonsecure PPI IRQ for arch timer

Santosh Shilimkar (9):
      ARM: dts: omap5-evm: Update available memory to 2032 MB
      ARM: dts: OMAP5: Align the local timer dt node as per the current binding code
      ARM: dts: OMAP5: Move the gic node out of ocp space
      ARM: dts: OMAP5: Update the timer and GIC nodes for HYP kernel support
      ARM: dts: OMAP5: Update keypad reg property
      Documentation: dt: OMAP: l3-noc: Add *reg* in required properties
      ARM: dts: OMAP4/5: Update l3-noc DT nodes
      ARM: OMAP2+: hwmod: extract module address space from DT blob
      ARM: OMAP2+: hwmod: Don't call _init_mpu_rt_base if no sysc

Sebastien Guiriec (1):
      ARM: dts: OMAP2+: Add SDMA Audio IPs bindings

Sourav Poddar (4):
      ARM: dts: omap4-sdp: Add I2c pinctrl data
      ARM: dts: omap5-evm: Add I2c pinctrl data
      ARM: dts: omap4-panda: Add I2c pinctrl data
      ARM: dts: omap5-evm: Add mcspi data

 .../devicetree/bindings/arm/omap/l3-noc.txt        |    1 +
 .../devicetree/bindings/arm/omap/timer.txt         |   17 ++-
 .../devicetree/bindings/gpio/gpio-omap.txt         |    8 +-
 Documentation/devicetree/bindings/usb/omap-usb.txt |    1 +
 arch/arm/boot/dts/Makefile                         |    4 +
 arch/arm/boot/dts/am335x-bone.dts                  |   10 +-
 arch/arm/boot/dts/am335x-evm.dts                   |   18 +-
 arch/arm/boot/dts/am335x-evmsk.dts                 |   18 +-
 arch/arm/boot/dts/am33xx.dtsi                      |   40 ++--
 arch/arm/boot/dts/am3517-evm.dts                   |    2 +-
 arch/arm/boot/dts/am3517_mt_ventoux.dts            |    2 +-
 arch/arm/boot/dts/omap2.dtsi                       |   39 +++-
 arch/arm/boot/dts/omap2420-h4.dts                  |   46 ++++
 arch/arm/boot/dts/omap2420.dtsi                    |   67 +++++-
 arch/arm/boot/dts/omap2430.dtsi                    |   87 +++++++-
 arch/arm/boot/dts/omap3-beagle-xm.dts              |   26 ++-
 arch/arm/boot/dts/omap3-beagle.dts                 |    8 +-
 arch/arm/boot/dts/omap3-devkit8000.dts             |  169 +++++++++++++
 arch/arm/boot/dts/omap3-evm.dts                    |   14 +-
 arch/arm/boot/dts/omap3-igep.dtsi                  |  122 ++++++++++
 arch/arm/boot/dts/omap3-igep0020.dts               |   56 +++++
 arch/arm/boot/dts/omap3-igep0030.dts               |   44 ++++
 arch/arm/boot/dts/omap3-overo.dtsi                 |   31 ++-
 arch/arm/boot/dts/omap3.dtsi                       |  132 +++++++++--
 arch/arm/boot/dts/omap3430-sdp.dts                 |  190 +++++++++++++++
 arch/arm/boot/dts/omap34xx.dtsi                    |   28 +++
 arch/arm/boot/dts/omap36xx.dtsi                    |   13 +
 arch/arm/boot/dts/omap4-panda-a4.dts               |    5 +-
 arch/arm/boot/dts/omap4-panda-common.dtsi          |  251 ++++++++++++++++++++
 arch/arm/boot/dts/omap4-panda-es.dts               |    5 +-
 arch/arm/boot/dts/omap4-panda.dts                  |  201 +----------------
 arch/arm/boot/dts/omap4-sdp.dts                    |   74 ++++++-
 arch/arm/boot/dts/omap4-var-som.dts                |    2 +-
 arch/arm/boot/dts/omap4.dtsi                       |  135 +++++++++--
 arch/arm/boot/dts/omap443x.dtsi                    |   27 ++
 arch/arm/boot/dts/omap4460.dtsi                    |   32 +++
 arch/arm/boot/dts/omap5-evm.dts                    |  110 +++++++++-
 arch/arm/boot/dts/omap5.dtsi                       |  245 ++++++++++++++++---
 arch/arm/boot/dts/twl4030.dtsi                     |   18 ++-
 arch/arm/boot/dts/twl6030.dtsi                     |   12 +
 arch/arm/mach-omap2/board-generic.c                |    1 +
 arch/arm/mach-omap2/omap_hwmod.c                   |   48 ++++-
 arch/arm/mach-omap2/pmu.c                          |   14 +-
 arch/arm/mach-omap2/timer.c                        |    7 +-
 arch/arm/plat-omap/dmtimer.c                       |  241 +++++++++++--------
 arch/arm/plat-omap/include/plat/dmtimer.h          |    1 +
 46 files changed, 2167 insertions(+), 455 deletions(-)
 create mode 100644 arch/arm/boot/dts/omap3-devkit8000.dts
 create mode 100644 arch/arm/boot/dts/omap3-igep.dtsi
 create mode 100644 arch/arm/boot/dts/omap3-igep0020.dts
 create mode 100644 arch/arm/boot/dts/omap3-igep0030.dts
 create mode 100644 arch/arm/boot/dts/omap3430-sdp.dts
 create mode 100644 arch/arm/boot/dts/omap34xx.dtsi
 create mode 100644 arch/arm/boot/dts/omap4-panda-common.dtsi
 create mode 100644 arch/arm/boot/dts/omap443x.dtsi
 create mode 100644 arch/arm/boot/dts/omap4460.dtsi


From gregory.clement at free-electrons.com  Mon Apr  8 18:52:08 2013
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Tue,  9 Apr 2013 00:52:08 +0200
Subject: [PATCH v3 0/9] ARM: mvebu: Enable LPAE support for Armada XP SoCs
Message-ID: <1365461538-30702-1-git-send-email-gregory.clement@free-electrons.com>

Hello,

The Armada XP SoCs have LPAE support. This is the third patch set
which allows to run kernel on this SoCs with LPAE support.

The biggest changes are the conversion of the device tree file to 64
bits in order to be able to use more than 4GB of memory (without this
the LPAE is pointless).

They are two kinds of change:
- most of the change are on the commit log, according to Arnd
comments.

- the other change was made on the patch "ARM: dts: mvebu: Convert
  mvebu device tree files to 64 bits". I managed to not have to use
  the 64 bits format for the Armada 370 device tree files.

This patch set won't be the last one, as to ease the merge work of
Jason, I will rebase this series onto his dts branch once he will have
pull the pending commits. Beside this rebase nothing will be changed,
that why I would like to start to get the acked-by from Rob Herring
and Arnd Bergmann for this series(both of them made comments so they
must have an opinion on this last version). I am also submitting the
patch "ARM: mvebu: Enable pj4b on LPAE compilations" to Russell King's
patch system as I didn't receive any complaint about it, and it is a
pretty trivial patch.

This new patch set have been tested on a Armada XP GP board with 8GB
of DRAM with LPAE selected. It have been tested on Armada XP DB board
with 3GB of DRAM with and without LPAE. And also on the Armada 370 DB
board (without LPAE) to check that no regression appeared.

This patch set is based on 3.9-rc6 and is still 3.10 material. The git
branch called lpae-v3 is available at:

https://github.com/MISL-EBU-System-SW/mainline-public.git.

Thanks,

Changelog:
v2 -> v3:

* Pass all the arm architecture word in uppercase in the commit titles.

* Add a commit message to "ARM: dts: mvebu: move all peripherals
  inside soc" and move it at first patch of the series.

* Add a commit message to " ARM: dts: mvebu: move all peripherals
  inside soc"

* Add a commit message to "ARM: dts: mvebu: introduce internal-regs
   node"

* Add more explanation to "ARM: mvebu: Align the internal registers
  virtual base to support LPAE"

* In patch "ARM: dts: mvebu: Convert all the mvebu files to use the
  range property" thanks to the use of the overload capability of the
  device tree format, armada-370 now includes the 32 bit skeleton and
  all the armada 370 based dts can remain the same.

v1 -> v2:

* The patch to convert the mvebu device tree files to 64 bits was
  split in 3 parts:

    - "arm: dts: move all peripherals inside soc" from Thomas

	- then "arm: dts: Convert all the mvebu files to use the range
    property" which will allow to keep 32 bits addresses for the
    internal registers whereas the memory of the system will be 64
    bits

	- and finally "arm: dts: Convert mvebu device tree files to 64
      bits" which was the move to 64 bits itself.

* A new patch was added "arm: dts: introduce internal-regs node" based
  on the work of Thomas for the mvebu-mbus driver. It introduce a
  'internal-regs' subnode, under which all devices are moved. This is
  not really needed for now, but will be for the mvebu-mbus
  driver. This generates a lot of code movement since it's indenting
  by one more tab all the devices. So it was a good opportunity to fix
  all the bad indentation.

* New patch from Thomas "fix cpus section indentation" to finalize the
  fixing of the bad indentation

* For DMA transfer, DMA_ZONE was selected instead of DMABOUNCE: all
  the DMA transfer are restricted to the low 32 bits address space.

Gregory CLEMENT (4):
  ARM: mvebu: Limit the DMA zone when LPAE is selected
  ARM: dts: mvebu: Convert all the mvebu files to use the range
    property
  ARM: dts: mvebu: introduce internal-regs node
  ARM: dts: mvebu: Convert mvebu device tree files to 64 bits

Lior Amsalem (3):
  ARM: mvebu: Align the internal registers virtual base to support LPAE
  ARM: mvebu: Enable pj4b on LPAE compilations
  ARM: dts: Add a 64 bits version of the skeleton device tree

Thomas Petazzoni (2):
  ARM: dts: mvebu: fix cpus section indentation
  ARM: dts: mvebu: move all peripherals inside soc

 arch/arm/boot/dts/armada-370-db.dts              |  108 ++++-----
 arch/arm/boot/dts/armada-370-mirabox.dts         |   78 +++----
 arch/arm/boot/dts/armada-370-rd.dts              |   16 +-
 arch/arm/boot/dts/armada-370-xp.dtsi             |  253 +++++++++++-----------
 arch/arm/boot/dts/armada-370.dtsi                |  223 +++++++++----------
 arch/arm/boot/dts/armada-xp-db.dts               |  156 ++++++-------
 arch/arm/boot/dts/armada-xp-gp.dts               |  138 ++++++------
 arch/arm/boot/dts/armada-xp-mv78230.dtsi         |   84 +++----
 arch/arm/boot/dts/armada-xp-mv78260.dtsi         |  110 +++++-----
 arch/arm/boot/dts/armada-xp-mv78460.dtsi         |  136 ++++++------
 arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts |  198 ++++++++---------
 arch/arm/boot/dts/armada-xp.dtsi                 |  191 ++++++++--------
 arch/arm/boot/dts/skeleton64.dtsi                |   13 ++
 arch/arm/include/debug/mvebu.S                   |    2 +-
 arch/arm/mach-mvebu/Kconfig                      |    1 +
 arch/arm/mach-mvebu/armada-370-xp.h              |    2 +-
 arch/arm/mm/proc-v7.S                            |    3 +-
 17 files changed, 877 insertions(+), 835 deletions(-)
 create mode 100644 arch/arm/boot/dts/skeleton64.dtsi

-- 
1.7.9.5



From gregory.clement at free-electrons.com  Mon Apr  8 18:52:09 2013
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Tue,  9 Apr 2013 00:52:09 +0200
Subject: [PATCH v3 1/9] ARM: dts: mvebu: fix cpus section indentation
In-Reply-To: <1365461538-30702-1-git-send-email-gregory.clement@free-electrons.com>
References: <1365461538-30702-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1365461538-30702-2-git-send-email-gregory.clement@free-electrons.com>

From: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>

Align the cpu node indentation with the rest of the file

[gc]: added a commit description
Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 arch/arm/boot/dts/armada-xp-mv78230.dtsi |   28 ++++++++--------
 arch/arm/boot/dts/armada-xp-mv78260.dtsi |   28 ++++++++--------
 arch/arm/boot/dts/armada-xp-mv78460.dtsi |   54 +++++++++++++++---------------
 3 files changed, 55 insertions(+), 55 deletions(-)

diff --git a/arch/arm/boot/dts/armada-xp-mv78230.dtsi b/arch/arm/boot/dts/armada-xp-mv78230.dtsi
index f56c405..50180eb 100644
--- a/arch/arm/boot/dts/armada-xp-mv78230.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78230.dtsi
@@ -25,22 +25,22 @@
 	};
 
 	cpus {
-	    #address-cells = <1>;
-	    #size-cells = <0>;
+		#address-cells = <1>;
+		#size-cells = <0>;
 
-	    cpu at 0 {
-		device_type = "cpu";
-		compatible = "marvell,sheeva-v7";
-		reg = <0>;
-		clocks = <&cpuclk 0>;
-	    };
+		cpu at 0 {
+			device_type = "cpu";
+			compatible = "marvell,sheeva-v7";
+			reg = <0>;
+			clocks = <&cpuclk 0>;
+		};
 
-	    cpu at 1 {
-		device_type = "cpu";
-		compatible = "marvell,sheeva-v7";
-		reg = <1>;
-		clocks = <&cpuclk 1>;
-	    };
+		cpu at 1 {
+			device_type = "cpu";
+			compatible = "marvell,sheeva-v7";
+			reg = <1>;
+			clocks = <&cpuclk 1>;
+		};
 	};
 
 	soc {
diff --git a/arch/arm/boot/dts/armada-xp-mv78260.dtsi b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
index f8f2b78..3c433d5 100644
--- a/arch/arm/boot/dts/armada-xp-mv78260.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
@@ -26,22 +26,22 @@
 	};
 
 	cpus {
-	    #address-cells = <1>;
-	    #size-cells = <0>;
+		#address-cells = <1>;
+		#size-cells = <0>;
 
-	    cpu at 0 {
-		device_type = "cpu";
-		compatible = "marvell,sheeva-v7";
-		reg = <0>;
-		clocks = <&cpuclk 0>;
-	    };
+		cpu at 0 {
+			device_type = "cpu";
+			compatible = "marvell,sheeva-v7";
+			reg = <0>;
+			clocks = <&cpuclk 0>;
+		};
 
-	    cpu at 1 {
-		device_type = "cpu";
-		compatible = "marvell,sheeva-v7";
-		reg = <1>;
-		clocks = <&cpuclk 1>;
-	    };
+		cpu at 1 {
+			device_type = "cpu";
+			compatible = "marvell,sheeva-v7";
+			reg = <1>;
+			clocks = <&cpuclk 1>;
+		};
 	};
 
 	soc {
diff --git a/arch/arm/boot/dts/armada-xp-mv78460.dtsi b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
index 936c25d..4c38e942 100644
--- a/arch/arm/boot/dts/armada-xp-mv78460.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
@@ -27,36 +27,36 @@
 
 
 	cpus {
-	    #address-cells = <1>;
-	    #size-cells = <0>;
+		#address-cells = <1>;
+		#size-cells = <0>;
 
-	    cpu at 0 {
-		device_type = "cpu";
-		compatible = "marvell,sheeva-v7";
-		reg = <0>;
-		clocks = <&cpuclk 0>;
-	    };
+		cpu at 0 {
+			device_type = "cpu";
+			compatible = "marvell,sheeva-v7";
+			reg = <0>;
+			clocks = <&cpuclk 0>;
+		};
 
-	    cpu at 1 {
-		device_type = "cpu";
-		compatible = "marvell,sheeva-v7";
-		reg = <1>;
-		clocks = <&cpuclk 1>;
-	    };
+		cpu at 1 {
+			device_type = "cpu";
+			compatible = "marvell,sheeva-v7";
+			reg = <1>;
+			clocks = <&cpuclk 1>;
+		};
 
-	    cpu at 2 {
-		device_type = "cpu";
-		compatible = "marvell,sheeva-v7";
-		reg = <2>;
-		clocks = <&cpuclk 2>;
-	    };
+		cpu at 2 {
+			device_type = "cpu";
+			compatible = "marvell,sheeva-v7";
+			reg = <2>;
+			clocks = <&cpuclk 2>;
+		};
 
-	    cpu at 3 {
-		device_type = "cpu";
-		compatible = "marvell,sheeva-v7";
-		reg = <3>;
-		clocks = <&cpuclk 3>;
-	    };
+		cpu at 3 {
+			device_type = "cpu";
+			compatible = "marvell,sheeva-v7";
+			reg = <3>;
+			clocks = <&cpuclk 3>;
+		};
 	};
 
 	soc {
@@ -112,4 +112,4 @@
 				status = "disabled";
 		};
 	};
- };
+};
-- 
1.7.9.5



From gregory.clement at free-electrons.com  Mon Apr  8 18:52:10 2013
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Tue,  9 Apr 2013 00:52:10 +0200
Subject: [PATCH v3 2/9] ARM: mvebu: Limit the DMA zone when LPAE is selected
In-Reply-To: <1365461538-30702-1-git-send-email-gregory.clement@free-electrons.com>
References: <1365461538-30702-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1365461538-30702-3-git-send-email-gregory.clement@free-electrons.com>

When LPAE is activated on Armada XP, all registers and IOs are still
32bit, the 40bit extension is on the CPU to DRAM path (windows) only.
That means that all the DMA transfer are restricted to the low 32 bits
address space. This is limitation is achieved by selecting ZONE_DMA.

Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
---
 arch/arm/mach-mvebu/Kconfig |    1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index 440b13e..db1bbc8 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -13,6 +13,7 @@ config ARCH_MVEBU
 	select MVEBU_CLK_CORE
 	select MVEBU_CLK_CPU
 	select MVEBU_CLK_GATING
+	select ZONE_DMA if ARM_LPAE
 
 if ARCH_MVEBU
 
-- 
1.7.9.5



From gregory.clement at free-electrons.com  Mon Apr  8 18:52:11 2013
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Tue,  9 Apr 2013 00:52:11 +0200
Subject: [PATCH v3 3/9] ARM: mvebu: Align the internal registers virtual base
 to support LPAE
In-Reply-To: <1365461538-30702-1-git-send-email-gregory.clement@free-electrons.com>
References: <1365461538-30702-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1365461538-30702-4-git-send-email-gregory.clement@free-electrons.com>

From: Lior Amsalem <alior at marvell.com>

In order to be able to support the LPAE, the internal registers
virtual base must be aligned to 2MB. In LPAE section size is 2MB, in
earlyprintk we map the internal registers and it must be section
aligned.

Signed-off-by: Lior Amsalem <alior at marvell.com>
Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
---
 arch/arm/include/debug/mvebu.S      |    2 +-
 arch/arm/mach-mvebu/armada-370-xp.h |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/include/debug/mvebu.S b/arch/arm/include/debug/mvebu.S
index 865c6d0..df191af 100644
--- a/arch/arm/include/debug/mvebu.S
+++ b/arch/arm/include/debug/mvebu.S
@@ -12,7 +12,7 @@
 */
 
 #define ARMADA_370_XP_REGS_PHYS_BASE	0xd0000000
-#define ARMADA_370_XP_REGS_VIRT_BASE	0xfeb00000
+#define ARMADA_370_XP_REGS_VIRT_BASE	0xfec00000
 
 	.macro	addruart, rp, rv, tmp
 	ldr	\rp, =ARMADA_370_XP_REGS_PHYS_BASE
diff --git a/arch/arm/mach-mvebu/armada-370-xp.h b/arch/arm/mach-mvebu/armada-370-xp.h
index c6a7d74..c49c08e 100644
--- a/arch/arm/mach-mvebu/armada-370-xp.h
+++ b/arch/arm/mach-mvebu/armada-370-xp.h
@@ -16,7 +16,7 @@
 #define __MACH_ARMADA_370_XP_H
 
 #define ARMADA_370_XP_REGS_PHYS_BASE	0xd0000000
-#define ARMADA_370_XP_REGS_VIRT_BASE	IOMEM(0xfeb00000)
+#define ARMADA_370_XP_REGS_VIRT_BASE	IOMEM(0xfec00000)
 #define ARMADA_370_XP_REGS_SIZE		SZ_1M
 
 #ifdef CONFIG_SMP
-- 
1.7.9.5



From gregory.clement at free-electrons.com  Mon Apr  8 18:52:12 2013
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Tue,  9 Apr 2013 00:52:12 +0200
Subject: [PATCH v3 4/9] ARM: mvebu: Enable pj4b on LPAE compilations
In-Reply-To: <1365461538-30702-1-git-send-email-gregory.clement@free-electrons.com>
References: <1365461538-30702-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1365461538-30702-5-git-send-email-gregory.clement@free-electrons.com>

From: Lior Amsalem <alior at marvell.com>

pj4b cpus are LPAE capable so enable them on LPAE compilations

Signed-off-by: Lior Amsalem <alior at marvell.com>
Tested-by: Franklin <flin at marvell.com>
Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
---
 arch/arm/mm/proc-v7.S |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
index f584d3f..d75dc67 100644
--- a/arch/arm/mm/proc-v7.S
+++ b/arch/arm/mm/proc-v7.S
@@ -402,6 +402,8 @@ __v7_ca9mp_proc_info:
 	__v7_proc __v7_ca9mp_setup
 	.size	__v7_ca9mp_proc_info, . - __v7_ca9mp_proc_info
 
+#endif	/* CONFIG_ARM_LPAE */
+
 	/*
 	 * Marvell PJ4B processor.
 	 */
@@ -411,7 +413,6 @@ __v7_pj4b_proc_info:
 	.long	0xfffffff0
 	__v7_proc __v7_pj4b_setup
 	.size	__v7_pj4b_proc_info, . - __v7_pj4b_proc_info
-#endif	/* CONFIG_ARM_LPAE */
 
 	/*
 	 * ARM Ltd. Cortex A7 processor.
-- 
1.7.9.5



From gregory.clement at free-electrons.com  Mon Apr  8 18:52:13 2013
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Tue,  9 Apr 2013 00:52:13 +0200
Subject: [PATCH v3 5/9] ARM: dts: Add a 64 bits version of the skeleton device
 tree
In-Reply-To: <1365461538-30702-1-git-send-email-gregory.clement@free-electrons.com>
References: <1365461538-30702-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1365461538-30702-6-git-send-email-gregory.clement@free-electrons.com>

From: Lior Amsalem <alior at marvell.com>

In order to be able to use more than 4GB address-cells and size-cells
have to be set to 2

Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
Signed-off-by: Lior Amsalem <alior at marvell.com>
---
 arch/arm/boot/dts/skeleton64.dtsi |   13 +++++++++++++
 1 file changed, 13 insertions(+)
 create mode 100644 arch/arm/boot/dts/skeleton64.dtsi

diff --git a/arch/arm/boot/dts/skeleton64.dtsi b/arch/arm/boot/dts/skeleton64.dtsi
new file mode 100644
index 0000000..1599415
--- /dev/null
+++ b/arch/arm/boot/dts/skeleton64.dtsi
@@ -0,0 +1,13 @@
+/*
+ * Skeleton device tree in the 64 bits version; the bare minimum
+ * needed to boot; just include and add a compatible value.  The
+ * bootloader will typically populate the memory node.
+ */
+
+/ {
+	#address-cells = <2>;
+	#size-cells = <2>;
+	chosen { };
+	aliases { };
+	memory { device_type = "memory"; reg = <0 0>; };
+};
-- 
1.7.9.5



From gregory.clement at free-electrons.com  Mon Apr  8 18:52:14 2013
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Tue,  9 Apr 2013 00:52:14 +0200
Subject: [PATCH v3 6/9] ARM: dts: mvebu: move all peripherals inside soc
In-Reply-To: <1365461538-30702-1-git-send-email-gregory.clement@free-electrons.com>
References: <1365461538-30702-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1365461538-30702-7-git-send-email-gregory.clement@free-electrons.com>

From: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>

reorganize the .dts and .dtsi files so that all devices are under the
soc { } node (currently some devices such as the interrupt controller,
the L2 cache and a few others are outside).

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 arch/arm/boot/dts/armada-370-xp.dtsi |   26 +++++++++++++-------------
 arch/arm/boot/dts/armada-370.dtsi    |   23 ++++++++++++-----------
 arch/arm/boot/dts/armada-xp.dtsi     |   32 ++++++++++++++++----------------
 3 files changed, 41 insertions(+), 40 deletions(-)

diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi b/arch/arm/boot/dts/armada-370-xp.dtsi
index 5b70820..bd26c48 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -28,19 +28,6 @@
 		};
 	};
 
-	mpic: interrupt-controller at d0020000 {
-	      compatible = "marvell,mpic";
-	      #interrupt-cells = <1>;
-	      #size-cells = <1>;
-	      interrupt-controller;
-	};
-
-	coherency-fabric at d0020200 {
-		compatible = "marvell,coherency-fabric";
-		reg = <0xd0020200 0xb0>,
-		      <0xd0021810 0x1c>;
-	};
-
 	soc {
 		#address-cells = <1>;
 		#size-cells = <1>;
@@ -48,6 +35,19 @@
 		interrupt-parent = <&mpic>;
 		ranges;
 
+		mpic: interrupt-controller at d0020000 {
+			compatible = "marvell,mpic";
+			#interrupt-cells = <1>;
+			#size-cells = <1>;
+			interrupt-controller;
+		};
+
+		coherency-fabric at d0020200 {
+			compatible = "marvell,coherency-fabric";
+			reg = <0xd0020200 0xb0>,
+			      <0xd0021810 0x1c>;
+		};
+
 		serial at d0012000 {
 				compatible = "snps,dw-apb-uart";
 				reg = <0xd0012000 0x100>;
diff --git a/arch/arm/boot/dts/armada-370.dtsi b/arch/arm/boot/dts/armada-370.dtsi
index a195deb..9bc092b 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -20,12 +20,6 @@
 / {
 	model = "Marvell Armada 370 family SoC";
 	compatible = "marvell,armada370", "marvell,armada-370-xp";
-	L2: l2-cache {
-		compatible = "marvell,aurora-outer-cache";
-		reg = <0xd0008000 0x1000>;
-		cache-id-part = <0x100>;
-		wt-override;
-	};
 
 	aliases {
 		gpio0 = &gpio0;
@@ -33,17 +27,24 @@
 		gpio2 = &gpio2;
 	};
 
-	mpic: interrupt-controller at d0020000 {
-	      reg = <0xd0020a00 0x1d0>,
-		    <0xd0021870 0x58>;
-	};
-
 	soc {
+		mpic: interrupt-controller at d0020000 {
+			reg = <0xd0020a00 0x1d0>,
+			      <0xd0021870 0x58>;
+		};
+
 		system-controller at d0018200 {
 				compatible = "marvell,armada-370-xp-system-controller";
 				reg = <0xd0018200 0x100>;
 		};
 
+		L2: l2-cache {
+			compatible = "marvell,aurora-outer-cache";
+			reg = <0xd0008000 0x1000>;
+			cache-id-part = <0x100>;
+			wt-override;
+		};
+
 		pinctrl {
 			compatible = "marvell,mv88f6710-pinctrl";
 			reg = <0xd0018000 0x38>;
diff --git a/arch/arm/boot/dts/armada-xp.dtsi b/arch/arm/boot/dts/armada-xp.dtsi
index ca00d83..e644cc5 100644
--- a/arch/arm/boot/dts/armada-xp.dtsi
+++ b/arch/arm/boot/dts/armada-xp.dtsi
@@ -22,25 +22,25 @@
 	model = "Marvell Armada XP family SoC";
 	compatible = "marvell,armadaxp", "marvell,armada-370-xp";
 
-	L2: l2-cache {
-		compatible = "marvell,aurora-system-cache";
-		reg = <0xd0008000 0x1000>;
-		cache-id-part = <0x100>;
-		wt-override;
-	};
+	soc {
+		L2: l2-cache {
+			compatible = "marvell,aurora-system-cache";
+			reg = <0xd0008000 0x1000>;
+			cache-id-part = <0x100>;
+			wt-override;
+		};
 
-	mpic: interrupt-controller at d0020000 {
-	      reg = <0xd0020a00 0x2d0>,
-		    <0xd0021070 0x58>;
-	};
+		mpic: interrupt-controller at d0020000 {
+		      reg = <0xd0020a00 0x2d0>,
+			    <0xd0021070 0x58>;
+		};
 
-	armada-370-xp-pmsu at d0022000 {
-		compatible = "marvell,armada-370-xp-pmsu";
-		reg = <0xd0022100 0x430>,
-		      <0xd0020800 0x20>;
-	};
+		armada-370-xp-pmsu at d0022000 {
+			compatible = "marvell,armada-370-xp-pmsu";
+			reg = <0xd0022100 0x430>,
+			      <0xd0020800 0x20>;
+		};
 
-	soc {
 		serial at d0012200 {
 				compatible = "snps,dw-apb-uart";
 				reg = <0xd0012200 0x100>;
-- 
1.7.9.5



From gregory.clement at free-electrons.com  Mon Apr  8 18:52:15 2013
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Tue,  9 Apr 2013 00:52:15 +0200
Subject: [PATCH v3 7/9] ARM: dts: mvebu: Convert all the mvebu files to use
 the range property
In-Reply-To: <1365461538-30702-1-git-send-email-gregory.clement@free-electrons.com>
References: <1365461538-30702-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1365461538-30702-8-git-send-email-gregory.clement@free-electrons.com>

This conversion will allow to keep 32 bits addresses for the internal
registers whereas the memory of the system will be 64 bits.
Later it will also ease the move of the mvebu-mbus driver to the
device tree support.

Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
---
 arch/arm/boot/dts/armada-370-db.dts              |   16 ++---
 arch/arm/boot/dts/armada-370-mirabox.dts         |   14 ++--
 arch/arm/boot/dts/armada-370-rd.dts              |   14 ++--
 arch/arm/boot/dts/armada-370-xp.dtsi             |   83 +++++++++++-----------
 arch/arm/boot/dts/armada-370.dtsi                |   49 ++++++-------
 arch/arm/boot/dts/armada-xp-db.dts               |   28 ++++----
 arch/arm/boot/dts/armada-xp-gp.dts               |   20 +++---
 arch/arm/boot/dts/armada-xp-mv78230.dtsi         |   10 +--
 arch/arm/boot/dts/armada-xp-mv78260.dtsi         |   18 ++---
 arch/arm/boot/dts/armada-xp-mv78460.dtsi         |   18 ++---
 arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts |   22 +++---
 arch/arm/boot/dts/armada-xp.dtsi                 |   65 ++++++++---------
 12 files changed, 180 insertions(+), 177 deletions(-)

diff --git a/arch/arm/boot/dts/armada-370-db.dts b/arch/arm/boot/dts/armada-370-db.dts
index e34b280..183901c 100644
--- a/arch/arm/boot/dts/armada-370-db.dts
+++ b/arch/arm/boot/dts/armada-370-db.dts
@@ -30,11 +30,11 @@
 	};
 
 	soc {
-		serial at d0012000 {
+		serial at 12000 {
 			clock-frequency = <200000000>;
 			status = "okay";
 		};
-		sata at d00a0000 {
+		sata at a0000 {
 			nr-ports = <2>;
 			status = "okay";
 		};
@@ -49,18 +49,18 @@
 			};
 		};
 
-		ethernet at d0070000 {
+		ethernet at 70000 {
 			status = "okay";
 			phy = <&phy0>;
 			phy-mode = "rgmii-id";
 		};
-		ethernet at d0074000 {
+		ethernet at 74000 {
 			status = "okay";
 			phy = <&phy1>;
 			phy-mode = "rgmii-id";
 		};
 
-		mvsdio at d00d4000 {
+		mvsdio at d4000 {
 			pinctrl-0 = <&sdio_pins1>;
 			pinctrl-names = "default";
 			/*
@@ -75,15 +75,15 @@
 			/* No CD or WP GPIOs */
 		};
 
-		usb at d0050000 {
+		usb at 50000 {
 			status = "okay";
 		};
 
-		usb at d0051000 {
+		usb at 51000 {
 			status = "okay";
 		};
 
-		spi0: spi at d0010600 {
+		spi0: spi at 10600 {
 			status = "okay";
 
 			spi-flash at 0 {
diff --git a/arch/arm/boot/dts/armada-370-mirabox.dts b/arch/arm/boot/dts/armada-370-mirabox.dts
index 3234875..77dfec7 100644
--- a/arch/arm/boot/dts/armada-370-mirabox.dts
+++ b/arch/arm/boot/dts/armada-370-mirabox.dts
@@ -25,11 +25,11 @@
 	};
 
 	soc {
-		serial at d0012000 {
+		serial at 12000 {
 			clock-frequency = <200000000>;
 			status = "okay";
 		};
-		timer at d0020300 {
+		timer at 20300 {
 			clock-frequency = <600000000>;
 			status = "okay";
 		};
@@ -42,18 +42,18 @@
 				reg = <1>;
 			};
 		};
-		ethernet at d0070000 {
+		ethernet at 70000 {
 			status = "okay";
 			phy = <&phy0>;
 			phy-mode = "rgmii-id";
 		};
-		ethernet at d0074000 {
+		ethernet at 74000 {
 			status = "okay";
 			phy = <&phy1>;
 			phy-mode = "rgmii-id";
 		};
 
-		mvsdio at d00d4000 {
+		mvsdio at d4000 {
 			pinctrl-0 = <&sdio_pins3>;
 			pinctrl-names = "default";
 			status = "okay";
@@ -63,11 +63,11 @@
 			 */
 		};
 
-		usb at d0050000 {
+		usb at 50000 {
 			status = "okay";
 		};
 
-		usb at d0051000 {
+		usb at 51000 {
 			status = "okay";
 		};
 	};
diff --git a/arch/arm/boot/dts/armada-370-rd.dts b/arch/arm/boot/dts/armada-370-rd.dts
index 070bba4..be209020 100644
--- a/arch/arm/boot/dts/armada-370-rd.dts
+++ b/arch/arm/boot/dts/armada-370-rd.dts
@@ -28,11 +28,11 @@
 	};
 
 	soc {
-		serial at d0012000 {
+		serial at 12000 {
 			clock-frequency = <200000000>;
 			status = "okay";
 		};
-		sata at d00a0000 {
+		sata at a0000 {
 			nr-ports = <2>;
 			status = "okay";
 		};
@@ -47,29 +47,29 @@
 			};
 		};
 
-		ethernet at d0070000 {
+		ethernet at 70000 {
 			status = "okay";
 			phy = <&phy0>;
 			phy-mode = "sgmii";
 		};
-		ethernet at d0074000 {
+		ethernet at 74000 {
 			status = "okay";
 			phy = <&phy1>;
 			phy-mode = "rgmii-id";
 		};
 
-		mvsdio at d00d4000 {
+		mvsdio at d4000 {
 			pinctrl-0 = <&sdio_pins1>;
 			pinctrl-names = "default";
 			status = "okay";
 			/* No CD or WP GPIOs */
 		};
 
-		usb at d0050000 {
+		usb at 50000 {
 			status = "okay";
 		};
 
-		usb at d0051000 {
+		usb at 51000 {
 			status = "okay";
 		};
 	};
diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi b/arch/arm/boot/dts/armada-370-xp.dtsi
index bd26c48..1874655 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -28,59 +28,60 @@
 		};
 	};
 
+
 	soc {
 		#address-cells = <1>;
 		#size-cells = <1>;
 		compatible = "simple-bus";
 		interrupt-parent = <&mpic>;
-		ranges;
+		ranges = <0 0xd0000000 0x100000>;
 
-		mpic: interrupt-controller at d0020000 {
-			compatible = "marvell,mpic";
-			#interrupt-cells = <1>;
-			#size-cells = <1>;
-			interrupt-controller;
+		mpic: interrupt-controller at 20000 {
+				compatible = "marvell,mpic";
+				#interrupt-cells = <1>;
+				#size-cells = <1>;
+				interrupt-controller;
 		};
 
-		coherency-fabric at d0020200 {
-			compatible = "marvell,coherency-fabric";
-			reg = <0xd0020200 0xb0>,
-			      <0xd0021810 0x1c>;
+		coherency-fabric at 20200 {
+				compatible = "marvell,coherency-fabric";
+				reg = <0x20200 0xb0>,
+				      <0x21810 0x1c>;
 		};
 
-		serial at d0012000 {
+		serial at 12000 {
 				compatible = "snps,dw-apb-uart";
-				reg = <0xd0012000 0x100>;
+				reg = <0x12000 0x100>;
 				reg-shift = <2>;
 				interrupts = <41>;
 				reg-io-width = <1>;
 				status = "disabled";
 		};
-		serial at d0012100 {
+		serial at 12100 {
 				compatible = "snps,dw-apb-uart";
-				reg = <0xd0012100 0x100>;
+				reg = <0x12100 0x100>;
 				reg-shift = <2>;
 				interrupts = <42>;
 				reg-io-width = <1>;
 				status = "disabled";
 		};
 
-		timer at d0020300 {
+		timer at 20300 {
 			       compatible = "marvell,armada-370-xp-timer";
-			       reg = <0xd0020300 0x30>,
-			       <0xd0021040 0x30>;
+			       reg = <0x20300 0x30>,
+			       <0x21040 0x30>;
 			       interrupts = <37>, <38>, <39>, <40>, <5>, <6>;
 			       clocks = <&coreclk 2>;
 		};
 
-		addr-decoding at d0020000 {
+		addr-decoding at 20000 {
 			compatible = "marvell,armada-addr-decoding-controller";
-			reg = <0xd0020000 0x258>;
+			reg = <0x20000 0x258>;
 		};
 
-		sata at d00a0000 {
+		sata at a0000 {
 			compatible = "marvell,orion-sata";
-			reg = <0xd00a0000 0x2400>;
+			reg = <0xa0000 0x2400>;
 			interrupts = <55>;
 			clocks = <&gateclk 15>, <&gateclk 30>;
 			clock-names = "0", "1";
@@ -91,28 +92,28 @@
 			#address-cells = <1>;
 			#size-cells = <0>;
 			compatible = "marvell,orion-mdio";
-			reg = <0xd0072004 0x4>;
+			reg = <0x72004 0x4>;
 		};
 
-		ethernet at d0070000 {
+		ethernet at 70000 {
 				compatible = "marvell,armada-370-neta";
-				reg = <0xd0070000 0x2500>;
+				reg = <0x70000 0x2500>;
 				interrupts = <8>;
 				clocks = <&gateclk 4>;
 				status = "disabled";
 		};
 
-		ethernet at d0074000 {
+		ethernet at 74000 {
 				compatible = "marvell,armada-370-neta";
-				reg = <0xd0074000 0x2500>;
+				reg = <0x74000 0x2500>;
 				interrupts = <10>;
 				clocks = <&gateclk 3>;
 				status = "disabled";
 		};
 
-		i2c0: i2c at d0011000 {
+		i2c0: i2c at 11000 {
 			compatible = "marvell,mv64xxx-i2c";
-			reg = <0xd0011000 0x20>;
+			reg = <0x11000 0x20>;
 			#address-cells = <1>;
 			#size-cells = <0>;
 			interrupts = <31>;
@@ -121,9 +122,9 @@
 			status = "disabled";
 		};
 
-		i2c1: i2c at d0011100 {
+		i2c1: i2c at 11100 {
 			compatible = "marvell,mv64xxx-i2c";
-			reg = <0xd0011100 0x20>;
+			reg = <0x11100 0x20>;
 			#address-cells = <1>;
 			#size-cells = <0>;
 			interrupts = <32>;
@@ -134,35 +135,35 @@
 
 		rtc at 10300 {
 			compatible = "marvell,orion-rtc";
-			reg = <0xd0010300 0x20>;
+			reg = <0x10300 0x20>;
 			interrupts = <50>;
 		};
 
-		mvsdio at d00d4000 {
+		mvsdio at d4000 {
 			compatible = "marvell,orion-sdio";
-			reg = <0xd00d4000 0x200>;
+			reg = <0xd4000 0x200>;
 			interrupts = <54>;
 			clocks = <&gateclk 17>;
 			status = "disabled";
 		};
 
-		usb at d0050000 {
+		usb at 50000 {
 			compatible = "marvell,orion-ehci";
-			reg = <0xd0050000 0x500>;
+			reg = <0x50000 0x500>;
 			interrupts = <45>;
 			status = "disabled";
 		};
 
-		usb at d0051000 {
+		usb at 51000 {
 			compatible = "marvell,orion-ehci";
-			reg = <0xd0051000 0x500>;
+			reg = <0x51000 0x500>;
 			interrupts = <46>;
 			status = "disabled";
 		};
 
-		spi0: spi at d0010600 {
+		spi0: spi at 10600 {
 			compatible = "marvell,orion-spi";
-			reg = <0xd0010600 0x28>;
+			reg = <0x10600 0x28>;
 			#address-cells = <1>;
 			#size-cells = <0>;
 			cell-index = <0>;
@@ -171,9 +172,9 @@
 			status = "disabled";
 		};
 
-		spi1: spi at d0010680 {
+		spi1: spi at 10680 {
 			compatible = "marvell,orion-spi";
-			reg = <0xd0010680 0x28>;
+			reg = <0x10680 0x28>;
 			#address-cells = <1>;
 			#size-cells = <0>;
 			cell-index = <1>;
diff --git a/arch/arm/boot/dts/armada-370.dtsi b/arch/arm/boot/dts/armada-370.dtsi
index 9bc092b..04a8004 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -28,14 +28,15 @@
 	};
 
 	soc {
-		mpic: interrupt-controller at d0020000 {
-			reg = <0xd0020a00 0x1d0>,
-			      <0xd0021870 0x58>;
+
+		mpic: interrupt-controller at 20000 {
+			reg = <0x20a00 0x1d0>,
+			      <0x21870 0x58>;
 		};
 
-		system-controller at d0018200 {
+		system-controller at 18200 {
 				compatible = "marvell,armada-370-xp-system-controller";
-				reg = <0xd0018200 0x100>;
+				reg = <0x18200 0x100>;
 		};
 
 		L2: l2-cache {
@@ -47,7 +48,7 @@
 
 		pinctrl {
 			compatible = "marvell,mv88f6710-pinctrl";
-			reg = <0xd0018000 0x38>;
+			reg = <0x18000 0x38>;
 
 			sdio_pins1: sdio-pins1 {
 			      marvell,pins = "mpp9",  "mpp11", "mpp12",
@@ -68,9 +69,9 @@
 			};
 	        };
 
-		gpio0: gpio at d0018100 {
+		gpio0: gpio at 18100 {
 			compatible = "marvell,orion-gpio";
-			reg = <0xd0018100 0x40>;
+			reg = <0x18100 0x40>;
 			ngpios = <32>;
 			gpio-controller;
 			#gpio-cells = <2>;
@@ -79,9 +80,9 @@
 			interrupts = <82>, <83>, <84>, <85>;
 		};
 
-		gpio1: gpio at d0018140 {
+		gpio1: gpio at 18140 {
 			compatible = "marvell,orion-gpio";
-			reg = <0xd0018140 0x40>;
+			reg = <0x18140 0x40>;
 			ngpios = <32>;
 			gpio-controller;
 			#gpio-cells = <2>;
@@ -90,9 +91,9 @@
 			interrupts = <87>, <88>, <89>, <90>;
 		};
 
-		gpio2: gpio at d0018180 {
+		gpio2: gpio at 18180 {
 			compatible = "marvell,orion-gpio";
-			reg = <0xd0018180 0x40>;
+			reg = <0x18180 0x40>;
 			ngpios = <2>;
 			gpio-controller;
 			#gpio-cells = <2>;
@@ -101,23 +102,23 @@
 			interrupts = <91>;
 		};
 
-		coreclk: mvebu-sar at d0018230 {
+		coreclk: mvebu-sar at 18230 {
 			compatible = "marvell,armada-370-core-clock";
-			reg = <0xd0018230 0x08>;
+			reg = <0x18230 0x08>;
 			#clock-cells = <1>;
 		};
 
-		gateclk: clock-gating-control at d0018220 {
+		gateclk: clock-gating-control at 18220 {
 			compatible = "marvell,armada-370-gating-clock";
-			reg = <0xd0018220 0x4>;
+			reg = <0x18220 0x4>;
 			clocks = <&coreclk 0>;
 			#clock-cells = <1>;
 		};
 
-		xor at d0060800 {
+		xor at 60800 {
 			compatible = "marvell,orion-xor";
-			reg = <0xd0060800 0x100
-			       0xd0060A00 0x100>;
+			reg = <0x60800 0x100
+			       0x60A00 0x100>;
 			status = "okay";
 
 			xor00 {
@@ -133,10 +134,10 @@
 			};
 		};
 
-		xor at d0060900 {
+		xor at 60900 {
 			compatible = "marvell,orion-xor";
-			reg = <0xd0060900 0x100
-			       0xd0060b00 0x100>;
+			reg = <0x60900 0x100
+			       0x60b00 0x100>;
 			status = "okay";
 
 			xor10 {
@@ -152,11 +153,11 @@
 			};
 		};
 
-		usb at d0050000 {
+		usb at 50000 {
 			clocks = <&coreclk 0>;
 		};
 
-		usb at d0051000 {
+		usb at 51000 {
 			clocks = <&coreclk 0>;
 		};
 
diff --git a/arch/arm/boot/dts/armada-xp-db.dts b/arch/arm/boot/dts/armada-xp-db.dts
index e83505e..5e2b595 100644
--- a/arch/arm/boot/dts/armada-xp-db.dts
+++ b/arch/arm/boot/dts/armada-xp-db.dts
@@ -30,24 +30,24 @@
 	};
 
 	soc {
-		serial at d0012000 {
+		serial at 12000 {
 			clock-frequency = <250000000>;
 			status = "okay";
 		};
-		serial at d0012100 {
+		serial at 12100 {
 			clock-frequency = <250000000>;
 			status = "okay";
 		};
-		serial at d0012200 {
+		serial at 12200 {
 			clock-frequency = <250000000>;
 			status = "okay";
 		};
-		serial at d0012300 {
+		serial at 12300 {
 			clock-frequency = <250000000>;
 			status = "okay";
 		};
 
-		sata at d00a0000 {
+		sata at a0000 {
 			nr-ports = <2>;
 			status = "okay";
 		};
@@ -70,47 +70,47 @@
 			};
 		};
 
-		ethernet at d0070000 {
+		ethernet at 70000 {
 			status = "okay";
 			phy = <&phy0>;
 			phy-mode = "rgmii-id";
 		};
-		ethernet at d0074000 {
+		ethernet at 74000 {
 			status = "okay";
 			phy = <&phy1>;
 			phy-mode = "rgmii-id";
 		};
-		ethernet at d0030000 {
+		ethernet at 30000 {
 			status = "okay";
 			phy = <&phy2>;
 			phy-mode = "sgmii";
 		};
-		ethernet at d0034000 {
+		ethernet at 34000 {
 			status = "okay";
 			phy = <&phy3>;
 			phy-mode = "sgmii";
 		};
 
-		mvsdio at d00d4000 {
+		mvsdio at d4000 {
 			pinctrl-0 = <&sdio_pins>;
 			pinctrl-names = "default";
 			status = "okay";
 			/* No CD or WP GPIOs */
 		};
 
-		usb at d0050000 {
+		usb at 50000 {
 			status = "okay";
 		};
 
-		usb at d0051000 {
+		usb at 51000 {
 			status = "okay";
 		};
 
-		usb at d0052000 {
+		usb at 52000 {
 			status = "okay";
 		};
 
-		spi0: spi at d0010600 {
+		spi0: spi at 10600 {
 			status = "okay";
 
 			spi-flash at 0 {
diff --git a/arch/arm/boot/dts/armada-xp-gp.dts b/arch/arm/boot/dts/armada-xp-gp.dts
index 1c8afe2..12b98d3 100644
--- a/arch/arm/boot/dts/armada-xp-gp.dts
+++ b/arch/arm/boot/dts/armada-xp-gp.dts
@@ -37,24 +37,24 @@
 	};
 
 	soc {
-		serial at d0012000 {
+		serial at 12000 {
 			clock-frequency = <250000000>;
 			status = "okay";
 		};
-		serial at d0012100 {
+		serial at 12100 {
 			clock-frequency = <250000000>;
 			status = "okay";
 		};
-		serial at d0012200 {
+		serial at 12200 {
 			clock-frequency = <250000000>;
 			status = "okay";
 		};
-		serial at d0012300 {
+		serial at 12300 {
 			clock-frequency = <250000000>;
 			status = "okay";
 		};
 
-		sata at d00a0000 {
+		sata at a0000 {
 			nr-ports = <2>;
 			status = "okay";
 		};
@@ -77,28 +77,28 @@
 			};
 		};
 
-		ethernet at d0070000 {
+		ethernet at 70000 {
 			status = "okay";
 			phy = <&phy0>;
 			phy-mode = "rgmii-id";
 		};
-		ethernet at d0074000 {
+		ethernet at 74000 {
 			status = "okay";
 			phy = <&phy1>;
 			phy-mode = "rgmii-id";
 		};
-		ethernet at d0030000 {
+		ethernet at 30000 {
 			status = "okay";
 			phy = <&phy2>;
 			phy-mode = "rgmii-id";
 		};
-		ethernet at d0034000 {
+		ethernet at 34000 {
 			status = "okay";
 			phy = <&phy3>;
 			phy-mode = "rgmii-id";
 		};
 
-		spi0: spi at d0010600 {
+		spi0: spi at 10600 {
 			status = "okay";
 
 			spi-flash at 0 {
diff --git a/arch/arm/boot/dts/armada-xp-mv78230.dtsi b/arch/arm/boot/dts/armada-xp-mv78230.dtsi
index 50180eb..757fd42 100644
--- a/arch/arm/boot/dts/armada-xp-mv78230.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78230.dtsi
@@ -46,7 +46,7 @@
 	soc {
 		pinctrl {
 			compatible = "marvell,mv78230-pinctrl";
-			reg = <0xd0018000 0x38>;
+			reg = <0x18000 0x38>;
 
 			sdio_pins: sdio-pins {
 				marvell,pins = "mpp30", "mpp31", "mpp32",
@@ -55,9 +55,9 @@
 			};
 		};
 
-		gpio0: gpio at d0018100 {
+		gpio0: gpio at 18100 {
 			compatible = "marvell,orion-gpio";
-			reg = <0xd0018100 0x40>;
+			reg = <0x18100 0x40>;
 			ngpios = <32>;
 			gpio-controller;
 			#gpio-cells = <2>;
@@ -66,9 +66,9 @@
 			interrupts = <82>, <83>, <84>, <85>;
 		};
 
-		gpio1: gpio at d0018140 {
+		gpio1: gpio at 18140 {
 			compatible = "marvell,orion-gpio";
-			reg = <0xd0018140 0x40>;
+			reg = <0x18140 0x40>;
 			ngpios = <17>;
 			gpio-controller;
 			#gpio-cells = <2>;
diff --git a/arch/arm/boot/dts/armada-xp-mv78260.dtsi b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
index 3c433d5..2b572ab 100644
--- a/arch/arm/boot/dts/armada-xp-mv78260.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
@@ -47,7 +47,7 @@
 	soc {
 		pinctrl {
 			compatible = "marvell,mv78260-pinctrl";
-			reg = <0xd0018000 0x38>;
+			reg = <0x18000 0x38>;
 
 			sdio_pins: sdio-pins {
 				marvell,pins = "mpp30", "mpp31", "mpp32",
@@ -56,9 +56,9 @@
 			};
 		};
 
-		gpio0: gpio at d0018100 {
+		gpio0: gpio at 18100 {
 			compatible = "marvell,orion-gpio";
-			reg = <0xd0018100 0x40>;
+			reg = <0x18100 0x40>;
 			ngpios = <32>;
 			gpio-controller;
 			#gpio-cells = <2>;
@@ -67,9 +67,9 @@
 			interrupts = <82>, <83>, <84>, <85>;
 		};
 
-		gpio1: gpio at d0018140 {
+		gpio1: gpio at 18140 {
 			compatible = "marvell,orion-gpio";
-			reg = <0xd0018140 0x40>;
+			reg = <0x18140 0x40>;
 			ngpios = <32>;
 			gpio-controller;
 			#gpio-cells = <2>;
@@ -78,9 +78,9 @@
 			interrupts = <87>, <88>, <89>, <90>;
 		};
 
-		gpio2: gpio at d0018180 {
+		gpio2: gpio at 18180 {
 			compatible = "marvell,orion-gpio";
-			reg = <0xd0018180 0x40>;
+			reg = <0x18180 0x40>;
 			ngpios = <3>;
 			gpio-controller;
 			#gpio-cells = <2>;
@@ -89,9 +89,9 @@
 			interrupts = <91>;
 		};
 
-		ethernet at d0034000 {
+		ethernet at 34000 {
 				compatible = "marvell,armada-370-neta";
-				reg = <0xd0034000 0x2500>;
+				reg = <0x34000 0x2500>;
 				interrupts = <14>;
 				clocks = <&gateclk 1>;
 				status = "disabled";
diff --git a/arch/arm/boot/dts/armada-xp-mv78460.dtsi b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
index 4c38e942..79a121f 100644
--- a/arch/arm/boot/dts/armada-xp-mv78460.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
@@ -62,7 +62,7 @@
 	soc {
 		pinctrl {
 			compatible = "marvell,mv78460-pinctrl";
-			reg = <0xd0018000 0x38>;
+			reg = <0x18000 0x38>;
 
 			sdio_pins: sdio-pins {
 				marvell,pins = "mpp30", "mpp31", "mpp32",
@@ -71,9 +71,9 @@
 			};
 		};
 
-		gpio0: gpio at d0018100 {
+		gpio0: gpio at 18100 {
 			compatible = "marvell,orion-gpio";
-			reg = <0xd0018100 0x40>;
+			reg = <0x18100 0x40>;
 			ngpios = <32>;
 			gpio-controller;
 			#gpio-cells = <2>;
@@ -82,9 +82,9 @@
 			interrupts = <82>, <83>, <84>, <85>;
 		};
 
-		gpio1: gpio at d0018140 {
+		gpio1: gpio at 18140 {
 			compatible = "marvell,orion-gpio";
-			reg = <0xd0018140 0x40>;
+			reg = <0x18140 0x40>;
 			ngpios = <32>;
 			gpio-controller;
 			#gpio-cells = <2>;
@@ -93,9 +93,9 @@
 			interrupts = <87>, <88>, <89>, <90>;
 		};
 
-		gpio2: gpio at d0018180 {
+		gpio2: gpio at 18180 {
 			compatible = "marvell,orion-gpio";
-			reg = <0xd0018180 0x40>;
+			reg = <0x18180 0x40>;
 			ngpios = <3>;
 			gpio-controller;
 			#gpio-cells = <2>;
@@ -104,9 +104,9 @@
 			interrupts = <91>;
 		};
 
-		ethernet at d0034000 {
+		ethernet at 34000 {
 				compatible = "marvell,armada-370-neta";
-				reg = <0xd0034000 0x2500>;
+				reg = <0x34000 0x2500>;
 				interrupts = <14>;
 				clocks = <&gateclk 1>;
 				status = "disabled";
diff --git a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
index 3818a82..a7bade4 100644
--- a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
+++ b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
@@ -27,11 +27,11 @@
 	};
 
 	soc {
-		serial at d0012000 {
+		serial at 12000 {
 			clock-frequency = <250000000>;
 			status = "okay";
 		};
-		serial at d0012100 {
+		serial at 12100 {
 			clock-frequency = <250000000>;
 			status = "okay";
 		};
@@ -96,31 +96,31 @@
 			};
 		};
 
-		ethernet at d0070000 {
+		ethernet at 70000 {
 			status = "okay";
 			phy = <&phy0>;
 			phy-mode = "sgmii";
 		};
-		ethernet at d0074000 {
+		ethernet at 74000 {
 			status = "okay";
 			phy = <&phy1>;
 			phy-mode = "sgmii";
 		};
-		ethernet at d0030000 {
+		ethernet at 30000 {
 			status = "okay";
 			phy = <&phy2>;
 			phy-mode = "sgmii";
 		};
-		ethernet at d0034000 {
+		ethernet at 34000 {
 			status = "okay";
 			phy = <&phy3>;
 			phy-mode = "sgmii";
 		};
-		i2c at d0011000 {
+		i2c at 11000 {
 			status = "okay";
 			clock-frequency = <400000>;
 		};
-		i2c at d0011100 {
+		i2c at 11100 {
 			status = "okay";
 			clock-frequency = <400000>;
 
@@ -129,14 +129,14 @@
 				reg = <0x30>;
 			};
 		};
-		sata at d00a0000 {
+		sata at a0000 {
 			nr-ports = <2>;
 			status = "okay";
 		};
-		usb at d0050000 {
+		usb at 50000 {
 			status = "okay";
 		};
-		usb at d0051000 {
+		usb at 51000 {
 			status = "okay";
 		};
 	};
diff --git a/arch/arm/boot/dts/armada-xp.dtsi b/arch/arm/boot/dts/armada-xp.dtsi
index e644cc5..6ca6b7a 100644
--- a/arch/arm/boot/dts/armada-xp.dtsi
+++ b/arch/arm/boot/dts/armada-xp.dtsi
@@ -22,83 +22,84 @@
 	model = "Marvell Armada XP family SoC";
 	compatible = "marvell,armadaxp", "marvell,armada-370-xp";
 
+
 	soc {
 		L2: l2-cache {
 			compatible = "marvell,aurora-system-cache";
-			reg = <0xd0008000 0x1000>;
+			reg = <0x08000 0x1000>;
 			cache-id-part = <0x100>;
 			wt-override;
 		};
 
-		mpic: interrupt-controller at d0020000 {
-		      reg = <0xd0020a00 0x2d0>,
-			    <0xd0021070 0x58>;
+		mpic: interrupt-controller at 20000 {
+		      reg = <0x20a00 0x2d0>,
+			    <0x21070 0x58>;
 		};
 
-		armada-370-xp-pmsu at d0022000 {
+		armada-370-xp-pmsu at 22000 {
 			compatible = "marvell,armada-370-xp-pmsu";
-			reg = <0xd0022100 0x430>,
-			      <0xd0020800 0x20>;
+			reg = <0x22100 0x430>,
+			      <0x20800 0x20>;
 		};
 
-		serial at d0012200 {
+		serial at 12200 {
 				compatible = "snps,dw-apb-uart";
-				reg = <0xd0012200 0x100>;
+				reg = <0x12200 0x100>;
 				reg-shift = <2>;
 				interrupts = <43>;
 				reg-io-width = <1>;
 				status = "disabled";
 		};
-		serial at d0012300 {
+		serial at 12300 {
 				compatible = "snps,dw-apb-uart";
-				reg = <0xd0012300 0x100>;
+				reg = <0x12300 0x100>;
 				reg-shift = <2>;
 				interrupts = <44>;
 				reg-io-width = <1>;
 				status = "disabled";
 		};
 
-		timer at d0020300 {
+		timer at 20300 {
 				marvell,timer-25Mhz;
 		};
 
-		coreclk: mvebu-sar at d0018230 {
+		coreclk: mvebu-sar at 18230 {
 			compatible = "marvell,armada-xp-core-clock";
-			reg = <0xd0018230 0x08>;
+			reg = <0x18230 0x08>;
 			#clock-cells = <1>;
 		};
 
-		cpuclk: clock-complex at d0018700 {
+		cpuclk: clock-complex at 18700 {
 			#clock-cells = <1>;
 			compatible = "marvell,armada-xp-cpu-clock";
-			reg = <0xd0018700 0xA0>;
+			reg = <0x18700 0xA0>;
 			clocks = <&coreclk 1>;
 		};
 
-		gateclk: clock-gating-control at d0018220 {
+		gateclk: clock-gating-control at 18220 {
 			compatible = "marvell,armada-xp-gating-clock";
-			reg = <0xd0018220 0x4>;
+			reg = <0x18220 0x4>;
 			clocks = <&coreclk 0>;
 			#clock-cells = <1>;
 		};
 
-		system-controller at d0018200 {
+		system-controller at 18200 {
 				compatible = "marvell,armada-370-xp-system-controller";
-				reg = <0xd0018200 0x500>;
+				reg = <0x18200 0x500>;
 		};
 
-		ethernet at d0030000 {
+		ethernet at 30000 {
 				compatible = "marvell,armada-370-neta";
-				reg = <0xd0030000 0x2500>;
+				reg = <0x30000 0x2500>;
 				interrupts = <12>;
 				clocks = <&gateclk 2>;
 				status = "disabled";
 		};
 
-		xor at d0060900 {
+		xor at 60900 {
 			compatible = "marvell,orion-xor";
-			reg = <0xd0060900 0x100
-			       0xd0060b00 0x100>;
+			reg = <0x60900 0x100
+			       0x60b00 0x100>;
 			clocks = <&gateclk 22>;
 			status = "okay";
 
@@ -115,10 +116,10 @@
 			};
 		};
 
-		xor at d00f0900 {
+		xor at f0900 {
 			compatible = "marvell,orion-xor";
-			reg = <0xd00F0900 0x100
-			       0xd00F0B00 0x100>;
+			reg = <0xF0900 0x100
+			       0xF0B00 0x100>;
 			clocks = <&gateclk 28>;
 			status = "okay";
 
@@ -135,17 +136,17 @@
 			};
 		};
 
-		usb at d0050000 {
+		usb at 50000 {
 			clocks = <&gateclk 18>;
 		};
 
-		usb at d0051000 {
+		usb at 51000 {
 			clocks = <&gateclk 19>;
 		};
 
-		usb at d0052000 {
+		usb at 52000 {
 			compatible = "marvell,orion-ehci";
-			reg = <0xd0052000 0x500>;
+			reg = <0x52000 0x500>;
 			interrupts = <47>;
 			clocks = <&gateclk 20>;
 			status = "disabled";
-- 
1.7.9.5



From gregory.clement at free-electrons.com  Mon Apr  8 18:52:17 2013
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Tue,  9 Apr 2013 00:52:17 +0200
Subject: [PATCH v3 9/9] ARM: dts: mvebu: Convert mvebu device tree files to 64
 bits
In-Reply-To: <1365461538-30702-1-git-send-email-gregory.clement@free-electrons.com>
References: <1365461538-30702-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1365461538-30702-10-git-send-email-gregory.clement@free-electrons.com>

In order to be able to use more than 4GB of RAM when the LPAE is
activated, the dts must be converted in 64 bits.

Only Armada XP is LPAE capable, but as it shares a common dtsi file
with Armada 370, then the common file include the skeleton64. Thanks
to the use of the overload capability of the device tree format,
armada-370 include the 32 bit skeleton and all the armada 370 based
dts can remain the same.

This was heavily based on the work of Lior Amsalem.

Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
---
 arch/arm/boot/dts/armada-370-xp.dtsi             |    4 ++--
 arch/arm/boot/dts/armada-370.dtsi                |    2 ++
 arch/arm/boot/dts/armada-xp-db.dts               |    2 +-
 arch/arm/boot/dts/armada-xp-gp.dts               |   14 ++++++++------
 arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts |    2 +-
 5 files changed, 14 insertions(+), 10 deletions(-)

diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi b/arch/arm/boot/dts/armada-370-xp.dtsi
index 8b9adc6..6a3b418 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -16,7 +16,7 @@
  * 370 and Armada XP SoC.
  */
 
-/include/ "skeleton.dtsi"
+/include/ "skeleton64.dtsi"
 
 / {
 	model = "Marvell Armada 370 and XP SoC";
@@ -33,7 +33,7 @@
 		#size-cells = <1>;
 		compatible = "simple-bus";
 		interrupt-parent = <&mpic>;
-		ranges = <0 0xd0000000 0x100000>;
+		ranges = <0 0 0xd0000000 0x100000>;
 
 		internal-regs {
 			compatible = "simple-bus";
diff --git a/arch/arm/boot/dts/armada-370.dtsi b/arch/arm/boot/dts/armada-370.dtsi
index 9ae6053..7fc18e7 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -16,6 +16,7 @@
  */
 
 /include/ "armada-370-xp.dtsi"
+/include/ "skeleton.dtsi"
 
 / {
 	model = "Marvell Armada 370 family SoC";
@@ -28,6 +29,7 @@
 	};
 
 	soc {
+		ranges = <0 0xd0000000 0x100000>;
 		internal-regs {
 			system-controller at 18200 {
 				compatible = "marvell,armada-370-xp-system-controller";
diff --git a/arch/arm/boot/dts/armada-xp-db.dts b/arch/arm/boot/dts/armada-xp-db.dts
index fbd0f04..a2dd24e 100644
--- a/arch/arm/boot/dts/armada-xp-db.dts
+++ b/arch/arm/boot/dts/armada-xp-db.dts
@@ -26,7 +26,7 @@
 
 	memory {
 		device_type = "memory";
-		reg = <0x00000000 0x80000000>; /* 2 GB */
+		reg = <0 0x00000000 0 0x80000000>; /* 2 GB */
 	};
 
 	soc {
diff --git a/arch/arm/boot/dts/armada-xp-gp.dts b/arch/arm/boot/dts/armada-xp-gp.dts
index b0298d7..b022906 100644
--- a/arch/arm/boot/dts/armada-xp-gp.dts
+++ b/arch/arm/boot/dts/armada-xp-gp.dts
@@ -26,14 +26,16 @@
 
 	memory {
 		device_type = "memory";
-
 		/*
-		 * 4 GB of plug-in RAM modules by default but only 3GB
-		 * are visible, the amount of memory available can be
-		 * changed by the bootloader according the size of the
-		 * module actually plugged
+                 * 8 GB of plug-in RAM modules by default.The amount
+                 * of memory available can be changed by the
+                 * bootloader according the size of the module
+                 * actually plugged. Only 7GB are usable because
+                 * addresses from 0xC0000000 to 0xffffffff are used by
+                 * the internal registers of the SoC.
 		 */
-		reg = <0x00000000 0xC0000000>;
+		reg = <0x00000000 0x00000000 0x00000000 0xC0000000>,
+		      <0x00000001 0x00000000 0x00000001 0x00000000>;
 	};
 
 	soc {
diff --git a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
index e2eaf4f..1f274e7 100644
--- a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
+++ b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
@@ -23,7 +23,7 @@
 
 	memory {
 		device_type = "memory";
-		reg = <0x00000000 0xC0000000>; /* 3 GB */
+		reg = <0 0x00000000 0 0xC0000000>; /* 3 GB */
 	};
 
 	soc {
-- 
1.7.9.5



From gregory.clement at free-electrons.com  Mon Apr  8 18:52:16 2013
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Tue,  9 Apr 2013 00:52:16 +0200
Subject: [PATCH v3 8/9] ARM: dts: mvebu: introduce internal-regs node
In-Reply-To: <1365461538-30702-1-git-send-email-gregory.clement@free-electrons.com>
References: <1365461538-30702-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1365461538-30702-9-git-send-email-gregory.clement@free-electrons.com>

Introduce a 'internal-regs' subnode, under which all devices are
moved. This is not really needed for now, but will be for the
mvebu-mbus driver. This generates a lot of code movement since it's
indenting by one more tab all the devices.  So it was a good
opportunity to fix all the bad indentation.

Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
---
 arch/arm/boot/dts/armada-370-db.dts              |  108 +++++-----
 arch/arm/boot/dts/armada-370-mirabox.dts         |   78 ++++----
 arch/arm/boot/dts/armada-370-rd.dts              |    2 +
 arch/arm/boot/dts/armada-370-xp.dtsi             |  228 +++++++++++-----------
 arch/arm/boot/dts/armada-370.dtsi                |  219 +++++++++++----------
 arch/arm/boot/dts/armada-xp-db.dts               |  154 +++++++--------
 arch/arm/boot/dts/armada-xp-gp.dts               |  124 ++++++------
 arch/arm/boot/dts/armada-xp-mv78230.dtsi         |   56 +++---
 arch/arm/boot/dts/armada-xp-mv78260.dtsi         |   80 ++++----
 arch/arm/boot/dts/armada-xp-mv78460.dtsi         |   80 ++++----
 arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts |  196 ++++++++++---------
 arch/arm/boot/dts/armada-xp.dtsi                 |  182 +++++++++--------
 12 files changed, 763 insertions(+), 744 deletions(-)

diff --git a/arch/arm/boot/dts/armada-370-db.dts b/arch/arm/boot/dts/armada-370-db.dts
index 183901c..6c30a9f 100644
--- a/arch/arm/boot/dts/armada-370-db.dts
+++ b/arch/arm/boot/dts/armada-370-db.dts
@@ -30,68 +30,70 @@
 	};
 
 	soc {
-		serial at 12000 {
-			clock-frequency = <200000000>;
-			status = "okay";
-		};
-		sata at a0000 {
-			nr-ports = <2>;
-			status = "okay";
-		};
-
-		mdio {
-			phy0: ethernet-phy at 0 {
-				reg = <0>;
+		internal-regs {
+			serial at 12000 {
+				clock-frequency = <200000000>;
+				status = "okay";
+			};
+			sata at a0000 {
+				nr-ports = <2>;
+				status = "okay";
 			};
 
-			phy1: ethernet-phy at 1 {
-				reg = <1>;
+			mdio {
+				phy0: ethernet-phy at 0 {
+					reg = <0>;
+				};
+
+				phy1: ethernet-phy at 1 {
+					reg = <1>;
+				};
 			};
-		};
 
-		ethernet at 70000 {
-			status = "okay";
-			phy = <&phy0>;
-			phy-mode = "rgmii-id";
-		};
-		ethernet at 74000 {
-			status = "okay";
-			phy = <&phy1>;
-			phy-mode = "rgmii-id";
-		};
+			ethernet at 70000 {
+				status = "okay";
+				phy = <&phy0>;
+				phy-mode = "rgmii-id";
+			};
+			ethernet at 74000 {
+				status = "okay";
+				phy = <&phy1>;
+				phy-mode = "rgmii-id";
+			};
 
-		mvsdio at d4000 {
-			pinctrl-0 = <&sdio_pins1>;
-			pinctrl-names = "default";
-			/*
-			 * This device is disabled by default, because
-			 * using the SD card connector requires
-			 * changing the default CON40 connector
-			 * "DB-88F6710_MPP_2xRGMII_DEVICE_Jumper" to a
-			 * different connector
-			 * "DB-88F6710_MPP_RGMII_SD_Jumper".
-			 */
-			status = "disabled";
-			/* No CD or WP GPIOs */
-		};
+			mvsdio at d4000 {
+				pinctrl-0 = <&sdio_pins1>;
+				pinctrl-names = "default";
+				/*
+				 * This device is disabled by default, because
+				 * using the SD card connector requires
+				 * changing the default CON40 connector
+				 * "DB-88F6710_MPP_2xRGMII_DEVICE_Jumper" to a
+				 * different connector
+				 * "DB-88F6710_MPP_RGMII_SD_Jumper".
+				 */
+				status = "disabled";
+				/* No CD or WP GPIOs */
+			};
 
-		usb at 50000 {
-			status = "okay";
-		};
+			usb at 50000 {
+				status = "okay";
+			};
 
-		usb at 51000 {
-			status = "okay";
-		};
+			usb at 51000 {
+				status = "okay";
+			};
 
-		spi0: spi at 10600 {
-			status = "okay";
+			spi0: spi at 10600 {
+				status = "okay";
 
-			spi-flash at 0 {
-				#address-cells = <1>;
-				#size-cells = <1>;
-				compatible = "mx25l25635e";
-				reg = <0>; /* Chip select 0 */
-				spi-max-frequency = <50000000>;
+				spi-flash at 0 {
+					#address-cells = <1>;
+					#size-cells = <1>;
+					compatible = "mx25l25635e";
+					reg = <0>; /* Chip select 0 */
+					spi-max-frequency = <50000000>;
+				};
 			};
 		};
 	};
diff --git a/arch/arm/boot/dts/armada-370-mirabox.dts b/arch/arm/boot/dts/armada-370-mirabox.dts
index 77dfec7..d4cefc0 100644
--- a/arch/arm/boot/dts/armada-370-mirabox.dts
+++ b/arch/arm/boot/dts/armada-370-mirabox.dts
@@ -25,50 +25,52 @@
 	};
 
 	soc {
-		serial at 12000 {
-			clock-frequency = <200000000>;
-			status = "okay";
-		};
-		timer at 20300 {
-			clock-frequency = <600000000>;
-			status = "okay";
-		};
-		mdio {
-			phy0: ethernet-phy at 0 {
-				reg = <0>;
+		internal-regs {
+			serial at 12000 {
+				clock-frequency = <200000000>;
+				status = "okay";
 			};
+			timer at 20300 {
+				clock-frequency = <600000000>;
+				status = "okay";
+			};
+			mdio {
+				phy0: ethernet-phy at 0 {
+					reg = <0>;
+				};
 
-			phy1: ethernet-phy at 1 {
-				reg = <1>;
+				phy1: ethernet-phy at 1 {
+					reg = <1>;
+				};
+			};
+			ethernet at 70000 {
+				status = "okay";
+				phy = <&phy0>;
+				phy-mode = "rgmii-id";
+			};
+			ethernet at 74000 {
+				status = "okay";
+				phy = <&phy1>;
+				phy-mode = "rgmii-id";
 			};
-		};
-		ethernet at 70000 {
-			status = "okay";
-			phy = <&phy0>;
-			phy-mode = "rgmii-id";
-		};
-		ethernet at 74000 {
-			status = "okay";
-			phy = <&phy1>;
-			phy-mode = "rgmii-id";
-		};
 
-		mvsdio at d4000 {
-			pinctrl-0 = <&sdio_pins3>;
-			pinctrl-names = "default";
-			status = "okay";
-			/*
-			 * No CD or WP GPIOs: SDIO interface used for
-			 * Wifi/Bluetooth chip
-			 */
-		};
+			mvsdio at d4000 {
+				pinctrl-0 = <&sdio_pins3>;
+				pinctrl-names = "default";
+				status = "okay";
+				/*
+				 * No CD or WP GPIOs: SDIO interface used for
+				 * Wifi/Bluetooth chip
+				 */
+			};
 
-		usb at 50000 {
-			status = "okay";
-		};
+			usb at 50000 {
+				status = "okay";
+			};
 
-		usb at 51000 {
-			status = "okay";
+			usb at 51000 {
+				status = "okay";
+			};
 		};
 	};
 };
diff --git a/arch/arm/boot/dts/armada-370-rd.dts b/arch/arm/boot/dts/armada-370-rd.dts
index be209020..437dcd2 100644
--- a/arch/arm/boot/dts/armada-370-rd.dts
+++ b/arch/arm/boot/dts/armada-370-rd.dts
@@ -28,6 +28,7 @@
 	};
 
 	soc {
+		internal-regs {
 		serial at 12000 {
 			clock-frequency = <200000000>;
 			status = "okay";
@@ -72,5 +73,6 @@
 		usb at 51000 {
 			status = "okay";
 		};
+		};
 	};
 };
diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi b/arch/arm/boot/dts/armada-370-xp.dtsi
index 1874655..8b9adc6 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -28,7 +28,6 @@
 		};
 	};
 
-
 	soc {
 		#address-cells = <1>;
 		#size-cells = <1>;
@@ -36,151 +35,156 @@
 		interrupt-parent = <&mpic>;
 		ranges = <0 0xd0000000 0x100000>;
 
-		mpic: interrupt-controller at 20000 {
+		internal-regs {
+			compatible = "simple-bus";
+			#address-cells = <1>;
+			#size-cells = <1>;
+			ranges;
+
+			mpic: interrupt-controller at 20000 {
 				compatible = "marvell,mpic";
 				#interrupt-cells = <1>;
 				#size-cells = <1>;
 				interrupt-controller;
-		};
+			};
 
-		coherency-fabric at 20200 {
+			coherency-fabric at 20200 {
 				compatible = "marvell,coherency-fabric";
-				reg = <0x20200 0xb0>,
-				      <0x21810 0x1c>;
-		};
+				reg = <0x20200 0xb0>, <0x21810 0x1c>;
+			};
 
-		serial at 12000 {
+			serial at 12000 {
 				compatible = "snps,dw-apb-uart";
 				reg = <0x12000 0x100>;
 				reg-shift = <2>;
 				interrupts = <41>;
 				reg-io-width = <1>;
 				status = "disabled";
-		};
-		serial at 12100 {
+			};
+			serial at 12100 {
 				compatible = "snps,dw-apb-uart";
 				reg = <0x12100 0x100>;
 				reg-shift = <2>;
 				interrupts = <42>;
 				reg-io-width = <1>;
 				status = "disabled";
-		};
-
-		timer at 20300 {
-			       compatible = "marvell,armada-370-xp-timer";
-			       reg = <0x20300 0x30>,
-			       <0x21040 0x30>;
-			       interrupts = <37>, <38>, <39>, <40>, <5>, <6>;
-			       clocks = <&coreclk 2>;
-		};
-
-		addr-decoding at 20000 {
-			compatible = "marvell,armada-addr-decoding-controller";
-			reg = <0x20000 0x258>;
-		};
-
-		sata at a0000 {
-			compatible = "marvell,orion-sata";
-			reg = <0xa0000 0x2400>;
-			interrupts = <55>;
-			clocks = <&gateclk 15>, <&gateclk 30>;
-			clock-names = "0", "1";
-			status = "disabled";
-		};
+			};
+
+			timer at 20300 {
+				compatible = "marvell,armada-370-xp-timer";
+				reg = <0x20300 0x30>, <0x21040 0x30>;
+				interrupts = <37>, <38>, <39>, <40>, <5>, <6>;
+				clocks = <&coreclk 2>;
+			};
+
+			addr-decoding at 20000 {
+				compatible = "marvell,armada-addr-decoding-controller";
+				reg = <0x20000 0x258>;
+			};
+
+			sata at a0000 {
+				compatible = "marvell,orion-sata";
+				reg = <0xa0000 0x2400>;
+				interrupts = <55>;
+				clocks = <&gateclk 15>, <&gateclk 30>;
+				clock-names = "0", "1";
+				status = "disabled";
+			};
 
-		mdio {
-			#address-cells = <1>;
-			#size-cells = <0>;
-			compatible = "marvell,orion-mdio";
-			reg = <0x72004 0x4>;
-		};
+			mdio {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "marvell,orion-mdio";
+				reg = <0x72004 0x4>;
+			};
 
-		ethernet at 70000 {
+			ethernet at 70000 {
 				compatible = "marvell,armada-370-neta";
 				reg = <0x70000 0x2500>;
 				interrupts = <8>;
 				clocks = <&gateclk 4>;
 				status = "disabled";
-		};
+			};
 
-		ethernet at 74000 {
+			ethernet at 74000 {
 				compatible = "marvell,armada-370-neta";
 				reg = <0x74000 0x2500>;
 				interrupts = <10>;
 				clocks = <&gateclk 3>;
 				status = "disabled";
-		};
-
-		i2c0: i2c at 11000 {
-			compatible = "marvell,mv64xxx-i2c";
-			reg = <0x11000 0x20>;
-			#address-cells = <1>;
-			#size-cells = <0>;
-			interrupts = <31>;
-			timeout-ms = <1000>;
-			clocks = <&coreclk 0>;
-			status = "disabled";
-		};
-
-		i2c1: i2c at 11100 {
-			compatible = "marvell,mv64xxx-i2c";
-			reg = <0x11100 0x20>;
-			#address-cells = <1>;
-			#size-cells = <0>;
-			interrupts = <32>;
-			timeout-ms = <1000>;
-			clocks = <&coreclk 0>;
-			status = "disabled";
-		};
-
-		rtc at 10300 {
-			compatible = "marvell,orion-rtc";
-			reg = <0x10300 0x20>;
-			interrupts = <50>;
-		};
-
-		mvsdio at d4000 {
-			compatible = "marvell,orion-sdio";
-			reg = <0xd4000 0x200>;
-			interrupts = <54>;
-			clocks = <&gateclk 17>;
-			status = "disabled";
-		};
-
-		usb at 50000 {
-			compatible = "marvell,orion-ehci";
-			reg = <0x50000 0x500>;
-			interrupts = <45>;
-			status = "disabled";
-		};
-
-		usb at 51000 {
-			compatible = "marvell,orion-ehci";
-			reg = <0x51000 0x500>;
-			interrupts = <46>;
-			status = "disabled";
-		};
+			};
+
+			i2c0: i2c at 11000 {
+				compatible = "marvell,mv64xxx-i2c";
+				reg = <0x11000 0x20>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+				interrupts = <31>;
+				timeout-ms = <1000>;
+				clocks = <&coreclk 0>;
+				status = "disabled";
+			};
+
+			i2c1: i2c at 11100 {
+				compatible = "marvell,mv64xxx-i2c";
+				reg = <0x11100 0x20>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+				interrupts = <32>;
+				timeout-ms = <1000>;
+				clocks = <&coreclk 0>;
+				status = "disabled";
+			};
+
+			rtc at 10300 {
+				compatible = "marvell,orion-rtc";
+				reg = <0x10300 0x20>;
+				interrupts = <50>;
+			};
+
+			mvsdio at d4000 {
+				compatible = "marvell,orion-sdio";
+				reg = <0xd4000 0x200>;
+				interrupts = <54>;
+				clocks = <&gateclk 17>;
+				status = "disabled";
+			};
 
-		spi0: spi at 10600 {
-			compatible = "marvell,orion-spi";
-			reg = <0x10600 0x28>;
-			#address-cells = <1>;
-			#size-cells = <0>;
-			cell-index = <0>;
-			interrupts = <30>;
-			clocks = <&coreclk 0>;
-			status = "disabled";
-		};
+			usb at 50000 {
+				compatible = "marvell,orion-ehci";
+				reg = <0x50000 0x500>;
+				interrupts = <45>;
+				status = "disabled";
+			};
 
-		spi1: spi at 10680 {
-			compatible = "marvell,orion-spi";
-			reg = <0x10680 0x28>;
-			#address-cells = <1>;
-			#size-cells = <0>;
-			cell-index = <1>;
-			interrupts = <92>;
-			clocks = <&coreclk 0>;
-			status = "disabled";
+			usb at 51000 {
+				compatible = "marvell,orion-ehci";
+				reg = <0x51000 0x500>;
+				interrupts = <46>;
+				status = "disabled";
+			};
+
+			spi0: spi at 10600 {
+				compatible = "marvell,orion-spi";
+				reg = <0x10600 0x28>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+				cell-index = <0>;
+				interrupts = <30>;
+				clocks = <&coreclk 0>;
+				status = "disabled";
+			};
+
+			spi1: spi at 10680 {
+				compatible = "marvell,orion-spi";
+				reg = <0x10680 0x28>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+				cell-index = <1>;
+				interrupts = <92>;
+				clocks = <&coreclk 0>;
+				status = "disabled";
+			};
 		};
 	};
 };
diff --git a/arch/arm/boot/dts/armada-370.dtsi b/arch/arm/boot/dts/armada-370.dtsi
index 04a8004..9ae6053 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -28,138 +28,137 @@
 	};
 
 	soc {
-
-		mpic: interrupt-controller at 20000 {
-			reg = <0x20a00 0x1d0>,
-			      <0x21870 0x58>;
-		};
-
-		system-controller at 18200 {
+		internal-regs {
+			system-controller at 18200 {
 				compatible = "marvell,armada-370-xp-system-controller";
 				reg = <0x18200 0x100>;
-		};
+			};
 
-		L2: l2-cache {
-			compatible = "marvell,aurora-outer-cache";
-			reg = <0xd0008000 0x1000>;
-			cache-id-part = <0x100>;
-			wt-override;
-		};
+			L2: l2-cache {
+				compatible = "marvell,aurora-outer-cache";
+				reg = <0xd0008000 0x1000>;
+				cache-id-part = <0x100>;
+				wt-override;
+			};
 
-		pinctrl {
-			compatible = "marvell,mv88f6710-pinctrl";
-			reg = <0x18000 0x38>;
+			mpic: interrupt-controller at 20000 {
+				reg = <0x20a00 0x1d0>, <0x21870 0x58>;
+			};
+
+			pinctrl {
+				compatible = "marvell,mv88f6710-pinctrl";
+				reg = <0x18000 0x38>;
 
 			sdio_pins1: sdio-pins1 {
-			      marvell,pins = "mpp9",  "mpp11", "mpp12",
-					     "mpp13", "mpp14", "mpp15";
-			      marvell,function = "sd0";
-			};
+					marvell,pins = "mpp9",  "mpp11", "mpp12",
+						"mpp13", "mpp14", "mpp15";
+					marvell,function = "sd0";
+				};
 
 			sdio_pins2: sdio-pins2 {
-			      marvell,pins = "mpp47", "mpp48", "mpp49",
-					     "mpp50", "mpp51", "mpp52";
-			      marvell,function = "sd0";
-			};
+					marvell,pins = "mpp47", "mpp48", "mpp49",
+						"mpp50", "mpp51", "mpp52";
+					marvell,function = "sd0";
+				};
 
 			sdio_pins3: sdio-pins3 {
-			      marvell,pins = "mpp48", "mpp49", "mpp50",
-					     "mpp51", "mpp52", "mpp53";
-			      marvell,function = "sd0";
+					marvell,pins = "mpp48", "mpp49", "mpp50",
+						"mpp51", "mpp52", "mpp53";
+					marvell,function = "sd0";
+				};
 			};
-	        };
-
-		gpio0: gpio at 18100 {
-			compatible = "marvell,orion-gpio";
-			reg = <0x18100 0x40>;
-			ngpios = <32>;
-			gpio-controller;
-			#gpio-cells = <2>;
-			interrupt-controller;
-			#interrupts-cells = <2>;
-			interrupts = <82>, <83>, <84>, <85>;
-		};
-
-		gpio1: gpio at 18140 {
-			compatible = "marvell,orion-gpio";
-			reg = <0x18140 0x40>;
-			ngpios = <32>;
-			gpio-controller;
-			#gpio-cells = <2>;
-			interrupt-controller;
-			#interrupts-cells = <2>;
-			interrupts = <87>, <88>, <89>, <90>;
-		};
-
-		gpio2: gpio at 18180 {
-			compatible = "marvell,orion-gpio";
-			reg = <0x18180 0x40>;
-			ngpios = <2>;
-			gpio-controller;
-			#gpio-cells = <2>;
-			interrupt-controller;
-			#interrupts-cells = <2>;
-			interrupts = <91>;
-		};
-
-		coreclk: mvebu-sar at 18230 {
-			compatible = "marvell,armada-370-core-clock";
-			reg = <0x18230 0x08>;
-			#clock-cells = <1>;
-		};
 
-		gateclk: clock-gating-control at 18220 {
-			compatible = "marvell,armada-370-gating-clock";
-			reg = <0x18220 0x4>;
-			clocks = <&coreclk 0>;
-			#clock-cells = <1>;
-		};
+			gpio0: gpio at 18100 {
+				compatible = "marvell,orion-gpio";
+				reg = <0x18100 0x40>;
+				ngpios = <32>;
+				gpio-controller;
+				#gpio-cells = <2>;
+				interrupt-controller;
+				#interrupts-cells = <2>;
+				interrupts = <82>, <83>, <84>, <85>;
+			};
 
-		xor at 60800 {
-			compatible = "marvell,orion-xor";
-			reg = <0x60800 0x100
-			       0x60A00 0x100>;
-			status = "okay";
+			gpio1: gpio at 18140 {
+				compatible = "marvell,orion-gpio";
+				reg = <0x18140 0x40>;
+				ngpios = <32>;
+				gpio-controller;
+				#gpio-cells = <2>;
+				interrupt-controller;
+				#interrupts-cells = <2>;
+				interrupts = <87>, <88>, <89>, <90>;
+			};
 
-			xor00 {
-				interrupts = <51>;
-				dmacap,memcpy;
-				dmacap,xor;
+			gpio2: gpio at 18180 {
+				compatible = "marvell,orion-gpio";
+				reg = <0x18180 0x40>;
+				ngpios = <2>;
+				gpio-controller;
+				#gpio-cells = <2>;
+				interrupt-controller;
+				#interrupts-cells = <2>;
+				interrupts = <91>;
 			};
-			xor01 {
-				interrupts = <52>;
-				dmacap,memcpy;
-				dmacap,xor;
-				dmacap,memset;
+
+			coreclk: mvebu-sar at 18230 {
+				compatible = "marvell,armada-370-core-clock";
+				reg = <0x18230 0x08>;
+				#clock-cells = <1>;
 			};
-		};
 
-		xor at 60900 {
-			compatible = "marvell,orion-xor";
-			reg = <0x60900 0x100
-			       0x60b00 0x100>;
-			status = "okay";
+			gateclk: clock-gating-control at 18220 {
+				compatible = "marvell,armada-370-gating-clock";
+				reg = <0x18220 0x4>;
+				clocks = <&coreclk 0>;
+				#clock-cells = <1>;
+			};
 
-			xor10 {
-				interrupts = <94>;
-				dmacap,memcpy;
-				dmacap,xor;
+			xor at 60800 {
+				compatible = "marvell,orion-xor";
+				reg = <0x60800 0x100
+				       0x60A00 0x100>;
+				status = "okay";
+
+				xor00 {
+					interrupts = <51>;
+					dmacap,memcpy;
+					dmacap,xor;
+				};
+				xor01 {
+					interrupts = <52>;
+					dmacap,memcpy;
+					dmacap,xor;
+					dmacap,memset;
+				};
 			};
-			xor11 {
-				interrupts = <95>;
-				dmacap,memcpy;
-				dmacap,xor;
-				dmacap,memset;
+
+			xor at 60900 {
+				compatible = "marvell,orion-xor";
+				reg = <0x60900 0x100
+				       0x60b00 0x100>;
+				status = "okay";
+
+				xor10 {
+					interrupts = <94>;
+					dmacap,memcpy;
+					dmacap,xor;
+				};
+				xor11 {
+					interrupts = <95>;
+					dmacap,memcpy;
+					dmacap,xor;
+					dmacap,memset;
+				};
 			};
-		};
 
-		usb at 50000 {
-			clocks = <&coreclk 0>;
-		};
+			usb at 50000 {
+				clocks = <&coreclk 0>;
+			};
 
-		usb at 51000 {
-			clocks = <&coreclk 0>;
+			usb at 51000 {
+				clocks = <&coreclk 0>;
+			};
 		};
-
 	};
 };
diff --git a/arch/arm/boot/dts/armada-xp-db.dts b/arch/arm/boot/dts/armada-xp-db.dts
index 5e2b595..fbd0f04 100644
--- a/arch/arm/boot/dts/armada-xp-db.dts
+++ b/arch/arm/boot/dts/armada-xp-db.dts
@@ -30,95 +30,97 @@
 	};
 
 	soc {
-		serial at 12000 {
-			clock-frequency = <250000000>;
-			status = "okay";
-		};
-		serial at 12100 {
-			clock-frequency = <250000000>;
-			status = "okay";
-		};
-		serial at 12200 {
-			clock-frequency = <250000000>;
-			status = "okay";
-		};
-		serial at 12300 {
-			clock-frequency = <250000000>;
-			status = "okay";
-		};
-
-		sata at a0000 {
-			nr-ports = <2>;
-			status = "okay";
-		};
-
-		mdio {
-			phy0: ethernet-phy at 0 {
-				reg = <0>;
+		internal-regs {
+			serial at 12000 {
+				clock-frequency = <250000000>;
+				status = "okay";
 			};
-
-			phy1: ethernet-phy at 1 {
-				reg = <1>;
+			serial at 12100 {
+				clock-frequency = <250000000>;
+				status = "okay";
+			};
+			serial at 12200 {
+				clock-frequency = <250000000>;
+				status = "okay";
+			};
+			serial at 12300 {
+				clock-frequency = <250000000>;
+				status = "okay";
 			};
 
-			phy2: ethernet-phy at 2 {
-				reg = <25>;
+			sata at a0000 {
+				nr-ports = <2>;
+				status = "okay";
 			};
 
-			phy3: ethernet-phy at 3 {
-				reg = <27>;
+			mdio {
+				phy0: ethernet-phy at 0 {
+					reg = <0>;
+				};
+
+				phy1: ethernet-phy at 1 {
+					reg = <1>;
+				};
+
+				phy2: ethernet-phy at 2 {
+					reg = <25>;
+				};
+
+				phy3: ethernet-phy at 3 {
+					reg = <27>;
+				};
 			};
-		};
 
-		ethernet at 70000 {
-			status = "okay";
-			phy = <&phy0>;
-			phy-mode = "rgmii-id";
-		};
-		ethernet at 74000 {
-			status = "okay";
-			phy = <&phy1>;
-			phy-mode = "rgmii-id";
-		};
-		ethernet at 30000 {
-			status = "okay";
-			phy = <&phy2>;
-			phy-mode = "sgmii";
-		};
-		ethernet at 34000 {
-			status = "okay";
-			phy = <&phy3>;
-			phy-mode = "sgmii";
-		};
+			ethernet at 70000 {
+				status = "okay";
+				phy = <&phy0>;
+				phy-mode = "rgmii-id";
+			};
+			ethernet at 74000 {
+				status = "okay";
+				phy = <&phy1>;
+				phy-mode = "rgmii-id";
+			};
+			ethernet at 30000 {
+				status = "okay";
+				phy = <&phy2>;
+				phy-mode = "sgmii";
+			};
+			ethernet at 34000 {
+				status = "okay";
+				phy = <&phy3>;
+				phy-mode = "sgmii";
+			};
 
-		mvsdio at d4000 {
-			pinctrl-0 = <&sdio_pins>;
-			pinctrl-names = "default";
-			status = "okay";
-			/* No CD or WP GPIOs */
-		};
+			mvsdio at d4000 {
+				pinctrl-0 = <&sdio_pins>;
+				pinctrl-names = "default";
+				status = "okay";
+				/* No CD or WP GPIOs */
+			};
 
-		usb at 50000 {
-			status = "okay";
-		};
+			usb at 50000 {
+				status = "okay";
+			};
 
-		usb at 51000 {
-			status = "okay";
-		};
+			usb at 51000 {
+				status = "okay";
+			};
 
-		usb at 52000 {
-			status = "okay";
-		};
+			usb at 52000 {
+				status = "okay";
+			};
 
-		spi0: spi at 10600 {
-			status = "okay";
+			spi0: spi at 10600 {
+				status = "okay";
 
-			spi-flash at 0 {
-				#address-cells = <1>;
-				#size-cells = <1>;
-				compatible = "m25p64";
-				reg = <0>; /* Chip select 0 */
-				spi-max-frequency = <20000000>;
+				spi-flash at 0 {
+					#address-cells = <1>;
+					#size-cells = <1>;
+					compatible = "m25p64";
+					reg = <0>; /* Chip select 0 */
+					spi-max-frequency = <20000000>;
+				};
 			};
 		};
 	};
diff --git a/arch/arm/boot/dts/armada-xp-gp.dts b/arch/arm/boot/dts/armada-xp-gp.dts
index 12b98d3..b0298d7 100644
--- a/arch/arm/boot/dts/armada-xp-gp.dts
+++ b/arch/arm/boot/dts/armada-xp-gp.dts
@@ -37,76 +37,78 @@
 	};
 
 	soc {
-		serial at 12000 {
-			clock-frequency = <250000000>;
-			status = "okay";
-		};
-		serial at 12100 {
-			clock-frequency = <250000000>;
-			status = "okay";
-		};
-		serial at 12200 {
-			clock-frequency = <250000000>;
-			status = "okay";
-		};
-		serial at 12300 {
-			clock-frequency = <250000000>;
-			status = "okay";
-		};
-
-		sata at a0000 {
-			nr-ports = <2>;
-			status = "okay";
-		};
-
-		mdio {
-			phy0: ethernet-phy at 0 {
-				reg = <16>;
+		internal-regs {
+			serial at 12000 {
+				clock-frequency = <250000000>;
+				status = "okay";
 			};
-
-			phy1: ethernet-phy at 1 {
-				reg = <17>;
+			serial at 12100 {
+				clock-frequency = <250000000>;
+				status = "okay";
+			};
+			serial at 12200 {
+				clock-frequency = <250000000>;
+				status = "okay";
+			};
+			serial at 12300 {
+				clock-frequency = <250000000>;
+				status = "okay";
 			};
 
-			phy2: ethernet-phy at 2 {
-				reg = <18>;
+			sata at a0000 {
+				nr-ports = <2>;
+				status = "okay";
 			};
 
-			phy3: ethernet-phy at 3 {
-				reg = <19>;
+			mdio {
+				phy0: ethernet-phy at 0 {
+					reg = <16>;
+				};
+
+				phy1: ethernet-phy at 1 {
+					reg = <17>;
+				};
+
+				phy2: ethernet-phy at 2 {
+					reg = <18>;
+				};
+
+				phy3: ethernet-phy at 3 {
+					reg = <19>;
+				};
 			};
-		};
 
-		ethernet at 70000 {
-			status = "okay";
-			phy = <&phy0>;
-			phy-mode = "rgmii-id";
-		};
-		ethernet at 74000 {
-			status = "okay";
-			phy = <&phy1>;
-			phy-mode = "rgmii-id";
-		};
-		ethernet at 30000 {
-			status = "okay";
-			phy = <&phy2>;
-			phy-mode = "rgmii-id";
-		};
-		ethernet at 34000 {
-			status = "okay";
-			phy = <&phy3>;
-			phy-mode = "rgmii-id";
-		};
+			ethernet at 70000 {
+				status = "okay";
+				phy = <&phy0>;
+				phy-mode = "rgmii-id";
+			};
+			ethernet at 74000 {
+				status = "okay";
+				phy = <&phy1>;
+				phy-mode = "rgmii-id";
+			};
+			ethernet at 30000 {
+				status = "okay";
+				phy = <&phy2>;
+				phy-mode = "rgmii-id";
+			};
+			ethernet at 34000 {
+				status = "okay";
+				phy = <&phy3>;
+				phy-mode = "rgmii-id";
+			};
 
-		spi0: spi at 10600 {
-			status = "okay";
+			spi0: spi at 10600 {
+				status = "okay";
 
-			spi-flash at 0 {
-				#address-cells = <1>;
-				#size-cells = <1>;
-				compatible = "n25q128a13";
-				reg = <0>; /* Chip select 0 */
-				spi-max-frequency = <108000000>;
+				spi-flash at 0 {
+					#address-cells = <1>;
+					#size-cells = <1>;
+					compatible = "n25q128a13";
+					reg = <0>; /* Chip select 0 */
+					spi-max-frequency = <108000000>;
+				};
 			};
 		};
 	};
diff --git a/arch/arm/boot/dts/armada-xp-mv78230.dtsi b/arch/arm/boot/dts/armada-xp-mv78230.dtsi
index 757fd42..392f118 100644
--- a/arch/arm/boot/dts/armada-xp-mv78230.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78230.dtsi
@@ -44,37 +44,39 @@
 	};
 
 	soc {
-		pinctrl {
-			compatible = "marvell,mv78230-pinctrl";
-			reg = <0x18000 0x38>;
+		internal-regs {
+			pinctrl {
+				compatible = "marvell,mv78230-pinctrl";
+				reg = <0x18000 0x38>;
 
-			sdio_pins: sdio-pins {
-				marvell,pins = "mpp30", "mpp31", "mpp32",
-					       "mpp33", "mpp34", "mpp35";
-				marvell,function = "sd0";
+				sdio_pins: sdio-pins {
+					marvell,pins = "mpp30", "mpp31", "mpp32",
+						       "mpp33", "mpp34", "mpp35";
+					marvell,function = "sd0";
+				};
 			};
-		};
 
-		gpio0: gpio at 18100 {
-			compatible = "marvell,orion-gpio";
-			reg = <0x18100 0x40>;
-			ngpios = <32>;
-			gpio-controller;
-			#gpio-cells = <2>;
-			interrupt-controller;
-			#interrupts-cells = <2>;
-			interrupts = <82>, <83>, <84>, <85>;
-		};
+			gpio0: gpio at 18100 {
+				compatible = "marvell,orion-gpio";
+				reg = <0x18100 0x40>;
+				ngpios = <32>;
+				gpio-controller;
+				#gpio-cells = <2>;
+				interrupt-controller;
+				#interrupts-cells = <2>;
+				interrupts = <82>, <83>, <84>, <85>;
+			};
 
-		gpio1: gpio at 18140 {
-			compatible = "marvell,orion-gpio";
-			reg = <0x18140 0x40>;
-			ngpios = <17>;
-			gpio-controller;
-			#gpio-cells = <2>;
-			interrupt-controller;
-			#interrupts-cells = <2>;
-			interrupts = <87>, <88>, <89>;
+			gpio1: gpio at 18140 {
+				compatible = "marvell,orion-gpio";
+				reg = <0x18140 0x40>;
+				ngpios = <17>;
+				gpio-controller;
+				#gpio-cells = <2>;
+				interrupt-controller;
+				#interrupts-cells = <2>;
+				interrupts = <87>, <88>, <89>;
+			};
 		};
 	};
 };
diff --git a/arch/arm/boot/dts/armada-xp-mv78260.dtsi b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
index 2b572ab..8fb7fea 100644
--- a/arch/arm/boot/dts/armada-xp-mv78260.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
@@ -45,56 +45,58 @@
 	};
 
 	soc {
-		pinctrl {
-			compatible = "marvell,mv78260-pinctrl";
-			reg = <0x18000 0x38>;
+		internal-regs {
+			pinctrl {
+				compatible = "marvell,mv78260-pinctrl";
+				reg = <0x18000 0x38>;
 
-			sdio_pins: sdio-pins {
-				marvell,pins = "mpp30", "mpp31", "mpp32",
-					       "mpp33", "mpp34", "mpp35";
-				marvell,function = "sd0";
+				sdio_pins: sdio-pins {
+					marvell,pins = "mpp30", "mpp31", "mpp32",
+						       "mpp33", "mpp34", "mpp35";
+					marvell,function = "sd0";
+				};
 			};
-		};
 
-		gpio0: gpio at 18100 {
-			compatible = "marvell,orion-gpio";
-			reg = <0x18100 0x40>;
-			ngpios = <32>;
-			gpio-controller;
-			#gpio-cells = <2>;
-			interrupt-controller;
-			#interrupts-cells = <2>;
-			interrupts = <82>, <83>, <84>, <85>;
-		};
+			gpio0: gpio at 18100 {
+				compatible = "marvell,orion-gpio";
+				reg = <0x18100 0x40>;
+				ngpios = <32>;
+				gpio-controller;
+				#gpio-cells = <2>;
+				interrupt-controller;
+				#interrupts-cells = <2>;
+				interrupts = <82>, <83>, <84>, <85>;
+			};
 
-		gpio1: gpio at 18140 {
-			compatible = "marvell,orion-gpio";
-			reg = <0x18140 0x40>;
-			ngpios = <32>;
-			gpio-controller;
-			#gpio-cells = <2>;
-			interrupt-controller;
-			#interrupts-cells = <2>;
-			interrupts = <87>, <88>, <89>, <90>;
-		};
+			gpio1: gpio at 18140 {
+				compatible = "marvell,orion-gpio";
+				reg = <0x18140 0x40>;
+				ngpios = <32>;
+				gpio-controller;
+				#gpio-cells = <2>;
+				interrupt-controller;
+				#interrupts-cells = <2>;
+				interrupts = <87>, <88>, <89>, <90>;
+			};
 
-		gpio2: gpio at 18180 {
-			compatible = "marvell,orion-gpio";
-			reg = <0x18180 0x40>;
-			ngpios = <3>;
-			gpio-controller;
-			#gpio-cells = <2>;
-			interrupt-controller;
-			#interrupts-cells = <2>;
-			interrupts = <91>;
-		};
+			gpio2: gpio at 18180 {
+				compatible = "marvell,orion-gpio";
+				reg = <0x18180 0x40>;
+				ngpios = <3>;
+				gpio-controller;
+				#gpio-cells = <2>;
+				interrupt-controller;
+				#interrupts-cells = <2>;
+				interrupts = <91>;
+			};
 
-		ethernet at 34000 {
+			ethernet at 34000 {
 				compatible = "marvell,armada-370-neta";
 				reg = <0x34000 0x2500>;
 				interrupts = <14>;
 				clocks = <&gateclk 1>;
 				status = "disabled";
+			};
 		};
 	};
 };
diff --git a/arch/arm/boot/dts/armada-xp-mv78460.dtsi b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
index 79a121f..fa665cb 100644
--- a/arch/arm/boot/dts/armada-xp-mv78460.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
@@ -60,56 +60,58 @@
 	};
 
 	soc {
-		pinctrl {
-			compatible = "marvell,mv78460-pinctrl";
-			reg = <0x18000 0x38>;
+		internal-regs {
+			pinctrl {
+				compatible = "marvell,mv78460-pinctrl";
+				reg = <0x18000 0x38>;
 
-			sdio_pins: sdio-pins {
-				marvell,pins = "mpp30", "mpp31", "mpp32",
-					       "mpp33", "mpp34", "mpp35";
-				marvell,function = "sd0";
+				sdio_pins: sdio-pins {
+					marvell,pins = "mpp30", "mpp31", "mpp32",
+						       "mpp33", "mpp34", "mpp35";
+					marvell,function = "sd0";
+				};
 			};
-		};
 
-		gpio0: gpio at 18100 {
-			compatible = "marvell,orion-gpio";
-			reg = <0x18100 0x40>;
-			ngpios = <32>;
-			gpio-controller;
-			#gpio-cells = <2>;
-			interrupt-controller;
-			#interrupts-cells = <2>;
-			interrupts = <82>, <83>, <84>, <85>;
-		};
+			gpio0: gpio at 18100 {
+				compatible = "marvell,orion-gpio";
+				reg = <0x18100 0x40>;
+				ngpios = <32>;
+				gpio-controller;
+				#gpio-cells = <2>;
+				interrupt-controller;
+				#interrupts-cells = <2>;
+				interrupts = <82>, <83>, <84>, <85>;
+			};
 
-		gpio1: gpio at 18140 {
-			compatible = "marvell,orion-gpio";
-			reg = <0x18140 0x40>;
-			ngpios = <32>;
-			gpio-controller;
-			#gpio-cells = <2>;
-			interrupt-controller;
-			#interrupts-cells = <2>;
-			interrupts = <87>, <88>, <89>, <90>;
-		};
+			gpio1: gpio at 18140 {
+				compatible = "marvell,orion-gpio";
+				reg = <0x18140 0x40>;
+				ngpios = <32>;
+				gpio-controller;
+				#gpio-cells = <2>;
+				interrupt-controller;
+				#interrupts-cells = <2>;
+				interrupts = <87>, <88>, <89>, <90>;
+			};
 
-		gpio2: gpio at 18180 {
-			compatible = "marvell,orion-gpio";
-			reg = <0x18180 0x40>;
-			ngpios = <3>;
-			gpio-controller;
-			#gpio-cells = <2>;
-			interrupt-controller;
-			#interrupts-cells = <2>;
-			interrupts = <91>;
-		};
+			gpio2: gpio at 18180 {
+				compatible = "marvell,orion-gpio";
+				reg = <0x18180 0x40>;
+				ngpios = <3>;
+				gpio-controller;
+				#gpio-cells = <2>;
+				interrupt-controller;
+				#interrupts-cells = <2>;
+				interrupts = <91>;
+			};
 
-		ethernet at 34000 {
+			ethernet at 34000 {
 				compatible = "marvell,armada-370-neta";
 				reg = <0x34000 0x2500>;
 				interrupts = <14>;
 				clocks = <&gateclk 1>;
 				status = "disabled";
+			};
 		};
 	};
 };
diff --git a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
index a7bade4..e2eaf4f 100644
--- a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
+++ b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
@@ -27,117 +27,119 @@
 	};
 
 	soc {
-		serial at 12000 {
-			clock-frequency = <250000000>;
-			status = "okay";
-		};
-		serial at 12100 {
-			clock-frequency = <250000000>;
-			status = "okay";
-		};
-		pinctrl {
-			led_pins: led-pins-0 {
-				marvell,pins = "mpp49", "mpp51", "mpp53";
-				marvell,function = "gpio";
+		internal-regs {
+			serial at 12000 {
+				clock-frequency = <250000000>;
+				status = "okay";
 			};
-		};
-		leds {
-			compatible = "gpio-leds";
-			pinctrl-names = "default";
-			pinctrl-0 = <&led_pins>;
-
-			red_led {
-				label = "red_led";
-				gpios = <&gpio1 17 1>;
-				default-state = "off";
+			serial at 12100 {
+				clock-frequency = <250000000>;
+				status = "okay";
 			};
-
-			yellow_led {
-				label = "yellow_led";
-				gpios = <&gpio1 19 1>;
-				default-state = "off";
+			pinctrl {
+				led_pins: led-pins-0 {
+					marvell,pins = "mpp49", "mpp51", "mpp53";
+					marvell,function = "gpio";
+				};
 			};
-
-			green_led {
-				label = "green_led";
-				gpios = <&gpio1 21 1>;
-				default-state = "off";
-				linux,default-trigger = "heartbeat";
+			leds {
+				compatible = "gpio-leds";
+				pinctrl-names = "default";
+				pinctrl-0 = <&led_pins>;
+
+				red_led {
+					label = "red_led";
+					gpios = <&gpio1 17 1>;
+					default-state = "off";
+				};
+
+				yellow_led {
+					label = "yellow_led";
+					gpios = <&gpio1 19 1>;
+					default-state = "off";
+				};
+
+				green_led {
+					label = "green_led";
+					gpios = <&gpio1 21 1>;
+					default-state = "off";
+					linux,default-trigger = "heartbeat";
+				};
 			};
-		};
 
-		gpio_keys {
-			compatible = "gpio-keys";
-			#address-cells = <1>;
-			#size-cells = <0>;
+			gpio_keys {
+				compatible = "gpio-keys";
+				#address-cells = <1>;
+				#size-cells = <0>;
 
-			button at 1 {
-				label = "Init Button";
-				linux,code = <116>;
-				gpios = <&gpio1 28 0>;
+				button at 1 {
+					label = "Init Button";
+					linux,code = <116>;
+					gpios = <&gpio1 28 0>;
+				};
 			};
-		};
 
-		mdio {
-			phy0: ethernet-phy at 0 {
-				reg = <0>;
-			};
+			mdio {
+				phy0: ethernet-phy at 0 {
+					reg = <0>;
+				};
 
-			phy1: ethernet-phy at 1 {
-				reg = <1>;
-			};
+				phy1: ethernet-phy at 1 {
+					reg = <1>;
+				};
 
-			phy2: ethernet-phy at 2 {
-				reg = <2>;
-			};
+				phy2: ethernet-phy at 2 {
+					reg = <2>;
+				};
 
-			phy3: ethernet-phy at 3 {
-				reg = <3>;
+				phy3: ethernet-phy at 3 {
+					reg = <3>;
+				};
 			};
-		};
-
-		ethernet at 70000 {
-			status = "okay";
-			phy = <&phy0>;
-			phy-mode = "sgmii";
-		};
-		ethernet at 74000 {
-			status = "okay";
-			phy = <&phy1>;
-			phy-mode = "sgmii";
-		};
-		ethernet at 30000 {
-			status = "okay";
-			phy = <&phy2>;
-			phy-mode = "sgmii";
-		};
-		ethernet at 34000 {
-			status = "okay";
-			phy = <&phy3>;
-			phy-mode = "sgmii";
-		};
-		i2c at 11000 {
-			status = "okay";
-			clock-frequency = <400000>;
-		};
-		i2c at 11100 {
-			status = "okay";
-			clock-frequency = <400000>;
 
-			s35390a: s35390a at 30 {
-				compatible = "s35390a";
-				reg = <0x30>;
+			ethernet at 70000 {
+				status = "okay";
+				phy = <&phy0>;
+				phy-mode = "sgmii";
+			};
+			ethernet at 74000 {
+				status = "okay";
+				phy = <&phy1>;
+				phy-mode = "sgmii";
+			};
+			ethernet at 30000 {
+				status = "okay";
+				phy = <&phy2>;
+				phy-mode = "sgmii";
+			};
+			ethernet at 34000 {
+				status = "okay";
+				phy = <&phy3>;
+				phy-mode = "sgmii";
+			};
+			i2c at 11000 {
+				status = "okay";
+				clock-frequency = <400000>;
+			};
+			i2c at 11100 {
+				status = "okay";
+				clock-frequency = <400000>;
+
+				s35390a: s35390a at 30 {
+					compatible = "s35390a";
+					reg = <0x30>;
+				};
+			};
+			sata at a0000 {
+				nr-ports = <2>;
+				status = "okay";
+			};
+			usb at 50000 {
+				status = "okay";
+			};
+			usb at 51000 {
+				status = "okay";
 			};
-		};
-		sata at a0000 {
-			nr-ports = <2>;
-			status = "okay";
-		};
-		usb at 50000 {
-			status = "okay";
-		};
-		usb at 51000 {
-			status = "okay";
 		};
 	};
 };
diff --git a/arch/arm/boot/dts/armada-xp.dtsi b/arch/arm/boot/dts/armada-xp.dtsi
index 6ca6b7a..2b39dde 100644
--- a/arch/arm/boot/dts/armada-xp.dtsi
+++ b/arch/arm/boot/dts/armada-xp.dtsi
@@ -22,135 +22,133 @@
 	model = "Marvell Armada XP family SoC";
 	compatible = "marvell,armadaxp", "marvell,armada-370-xp";
 
-
 	soc {
-		L2: l2-cache {
-			compatible = "marvell,aurora-system-cache";
-			reg = <0x08000 0x1000>;
-			cache-id-part = <0x100>;
-			wt-override;
-		};
+		internal-regs {
+			L2: l2-cache {
+				compatible = "marvell,aurora-system-cache";
+				reg = <0x08000 0x1000>;
+				cache-id-part = <0x100>;
+				wt-override;
+			};
 
-		mpic: interrupt-controller at 20000 {
-		      reg = <0x20a00 0x2d0>,
-			    <0x21070 0x58>;
-		};
+			mpic: interrupt-controller at 20000 {
+			      reg = <0x20a00 0x2d0>, <0x21070 0x58>;
+			};
 
-		armada-370-xp-pmsu at 22000 {
-			compatible = "marvell,armada-370-xp-pmsu";
-			reg = <0x22100 0x430>,
-			      <0x20800 0x20>;
-		};
+			armada-370-xp-pmsu at 22000 {
+				compatible = "marvell,armada-370-xp-pmsu";
+				reg = <0x22100 0x430>, <0x20800 0x20>;
+			};
 
-		serial at 12200 {
+			serial at 12200 {
 				compatible = "snps,dw-apb-uart";
 				reg = <0x12200 0x100>;
 				reg-shift = <2>;
 				interrupts = <43>;
 				reg-io-width = <1>;
 				status = "disabled";
-		};
-		serial at 12300 {
+			};
+			serial at 12300 {
 				compatible = "snps,dw-apb-uart";
 				reg = <0x12300 0x100>;
 				reg-shift = <2>;
 				interrupts = <44>;
 				reg-io-width = <1>;
 				status = "disabled";
-		};
+			};
 
-		timer at 20300 {
+			timer at 20300 {
 				marvell,timer-25Mhz;
-		};
+			};
 
-		coreclk: mvebu-sar at 18230 {
-			compatible = "marvell,armada-xp-core-clock";
-			reg = <0x18230 0x08>;
-			#clock-cells = <1>;
-		};
+			coreclk: mvebu-sar at 18230 {
+				compatible = "marvell,armada-xp-core-clock";
+				reg = <0x18230 0x08>;
+				#clock-cells = <1>;
+			};
 
-		cpuclk: clock-complex at 18700 {
-			#clock-cells = <1>;
-			compatible = "marvell,armada-xp-cpu-clock";
-			reg = <0x18700 0xA0>;
-			clocks = <&coreclk 1>;
-		};
+			cpuclk: clock-complex at 18700 {
+				#clock-cells = <1>;
+				compatible = "marvell,armada-xp-cpu-clock";
+				reg = <0x18700 0xA0>;
+				clocks = <&coreclk 1>;
+			};
 
-		gateclk: clock-gating-control at 18220 {
-			compatible = "marvell,armada-xp-gating-clock";
-			reg = <0x18220 0x4>;
-			clocks = <&coreclk 0>;
-			#clock-cells = <1>;
-		};
+			gateclk: clock-gating-control at 18220 {
+				compatible = "marvell,armada-xp-gating-clock";
+				reg = <0x18220 0x4>;
+				clocks = <&coreclk 0>;
+				#clock-cells = <1>;
+			};
 
-		system-controller at 18200 {
+			system-controller at 18200 {
 				compatible = "marvell,armada-370-xp-system-controller";
 				reg = <0x18200 0x500>;
-		};
+			};
 
-		ethernet at 30000 {
+			ethernet at 30000 {
 				compatible = "marvell,armada-370-neta";
 				reg = <0x30000 0x2500>;
 				interrupts = <12>;
 				clocks = <&gateclk 2>;
 				status = "disabled";
-		};
-
-		xor at 60900 {
-			compatible = "marvell,orion-xor";
-			reg = <0x60900 0x100
-			       0x60b00 0x100>;
-			clocks = <&gateclk 22>;
-			status = "okay";
-
-			xor10 {
-				interrupts = <51>;
-				dmacap,memcpy;
-				dmacap,xor;
-			};
-			xor11 {
-				interrupts = <52>;
-				dmacap,memcpy;
-				dmacap,xor;
-				dmacap,memset;
 			};
-		};
-
-		xor at f0900 {
-			compatible = "marvell,orion-xor";
-			reg = <0xF0900 0x100
-			       0xF0B00 0x100>;
-			clocks = <&gateclk 28>;
-			status = "okay";
 
-			xor00 {
-				interrupts = <94>;
-				dmacap,memcpy;
-				dmacap,xor;
+			xor at 60900 {
+				compatible = "marvell,orion-xor";
+				reg = <0x60900 0x100
+				       0x60b00 0x100>;
+				clocks = <&gateclk 22>;
+				status = "okay";
+
+				xor10 {
+					interrupts = <51>;
+					dmacap,memcpy;
+					dmacap,xor;
+				};
+				xor11 {
+					interrupts = <52>;
+					dmacap,memcpy;
+					dmacap,xor;
+					dmacap,memset;
+				};
 			};
-			xor01 {
-				interrupts = <95>;
-				dmacap,memcpy;
-				dmacap,xor;
-				dmacap,memset;
+
+			xor at f0900 {
+				compatible = "marvell,orion-xor";
+				reg = <0xF0900 0x100
+				       0xF0B00 0x100>;
+				clocks = <&gateclk 28>;
+				status = "okay";
+
+				xor00 {
+					interrupts = <94>;
+					dmacap,memcpy;
+					dmacap,xor;
+				};
+				xor01 {
+					interrupts = <95>;
+					dmacap,memcpy;
+					dmacap,xor;
+					dmacap,memset;
+				};
 			};
-		};
 
-		usb at 50000 {
-			clocks = <&gateclk 18>;
-		};
+			usb at 50000 {
+				clocks = <&gateclk 18>;
+			};
 
-		usb at 51000 {
-			clocks = <&gateclk 19>;
-		};
+			usb at 51000 {
+				clocks = <&gateclk 19>;
+			};
 
-		usb at 52000 {
-			compatible = "marvell,orion-ehci";
-			reg = <0x52000 0x500>;
-			interrupts = <47>;
-			clocks = <&gateclk 20>;
-			status = "disabled";
+			usb at 52000 {
+				compatible = "marvell,orion-ehci";
+				reg = <0x52000 0x500>;
+				interrupts = <47>;
+				clocks = <&gateclk 20>;
+				status = "disabled";
+			};
 		};
-
 	};
 };
-- 
1.7.9.5



From javier.martinez at collabora.co.uk  Mon Apr  8 18:56:31 2013
From: javier.martinez at collabora.co.uk (Javier Martinez Canillas)
Date: Tue, 09 Apr 2013 00:56:31 +0200
Subject: [PATCH 1/1] of/irq: store IRQ trigger/level in struct resource
 flags
In-Reply-To: <516341AF.7030207@wwwdotorg.org>
References: <1365148088-11175-1-git-send-email-javier.martinez@collabora.co.uk>
 <51633F26.7000400@gmail.com> <516341AF.7030207@wwwdotorg.org>
Message-ID: <51634B1F.4030408@collabora.co.uk>

On 04/09/2013 12:16 AM, Stephen Warren wrote:
> On 04/08/2013 04:05 PM, Rob Herring wrote:
>> On 04/05/2013 02:48 AM, Javier Martinez Canillas wrote:
>>> According to Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
>>> the "#interrupt-cells" property of an "interrupt-controller" is used
>>> to define the number of cells needed to specify a single interrupt.
> ...
>>> But the type is never returned so it can't be saved on the IRQ struct
>>> resource flags member.
>>>
>>> This means that drivers that need the IRQ type/level flags defined in
>>> the DT won't be able to get it.
>> 
>> But the interrupt controllers that need the information should be able
>> to get to it via irqd_get_trigger_type. What problem exactly are you
>> trying to fix? What driver would use this?
> 
> FYI, that is indeed what I did in sound/soc/codecs/wm8903.c. Thinking
> back, I'm not sure if that was the right thing or whether I should have
> sent this same patch:-)
> 

Hi Stephen,

I'm glad you agree :-)

I could change drivers/net/ethernet/smsc/smsc911x.c to get the type flags for
the IRQ with irqd_get_trigger_type() but I prefer $subject because:

a) This works in the non-DT case with board files and filling the resources from
platform data in arch/arm/mach-omap2/gpmc-smsc911x.c. So this is definitely a
bug on the DT core.

b) I don't see why of_irq_to_resource() should discard the type/level flags when
filling the IORESOURCE_IRQ if it was specified on the DT.

c) We will have to change all drivers that expect to get the IRQ type flags from
a IORESOURCE_IRQ struct resource.

Thanks a lot and best regards,
Javier


From rtivy at ti.com  Mon Apr  8 18:56:38 2013
From: rtivy at ti.com (Tivy, Robert)
Date: Mon, 8 Apr 2013 22:56:38 +0000
Subject: [PATCH v9 1/6] rpmsg: Process all available messages in
 virtqueue callback
In-Reply-To: <CAK=WgbaCtACsvt9cqQmGqXsADFb_3bfnNKeWq9iijR2vkYVuQQ@mail.gmail.com>
References: <1364521307-1219-1-git-send-email-rtivy@ti.com>
 <1364521307-1219-2-git-send-email-rtivy@ti.com>
 <CAK=WgbaCtACsvt9cqQmGqXsADFb_3bfnNKeWq9iijR2vkYVuQQ@mail.gmail.com>
Message-ID: <13514BD7FAEBA745BBD7D8A672905C1431230345@DFLE12.ent.ti.com>

> -----Original Message-----
> From: Ohad Ben-Cohen [mailto:ohad at wizery.com]
> Sent: Sunday, April 07, 2013 5:51 AM
> 
> On Fri, Mar 29, 2013 at 4:41 AM, Robert Tivy <rtivy at ti.com> wrote:
> > Change virtqueue callback function rpmsg_recv_done() to process all
> > available messages instead of just one message.
> >
> > Signed-off-by: Robert Tivy <rtivy at ti.com>
> 
> I'm thinking instead of adding an indentation level, let's split the
> _recv function.
> 
> This is what I have in mind - let me know if it works for you - thanks:
> 
> diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c
> b/drivers/rpmsg/virtio_rpmsg_bus.c
> index a59684b..42b9872 100644
> --- a/drivers/rpmsg/virtio_rpmsg_bus.c
> +++ b/drivers/rpmsg/virtio_rpmsg_bus.c
> @@ -776,22 +776,11 @@ out:
>  }
>  EXPORT_SYMBOL(rpmsg_send_offchannel_raw);
> 
> -/* called when an rx buffer is used, and it's time to digest a message
> */
> -static void rpmsg_recv_done(struct virtqueue *rvq)
> +static int rpmsg_recv_single(struct virtproc_info *vrp, struct device
> *dev,
> +                            struct rpmsg_hdr *msg, unsigned int len)
>  {
> -       struct rpmsg_hdr *msg;
> -       unsigned int len;
>         struct rpmsg_endpoint *ept;
>         struct scatterlist sg;
> -       struct virtproc_info *vrp = rvq->vdev->priv;
> -       struct device *dev = &rvq->vdev->dev;
> -       int err;
> -
> -       msg = virtqueue_get_buf(rvq, &len);
> -       if (!msg) {
> -               dev_err(dev, "uhm, incoming signal, but no used buffer
> ?\n");
> -               return;
> -       }
> 
>         dev_dbg(dev, "From: 0x%x, To: 0x%x, Len: %d, Flags: %d,
> Reserved: %d\n",
>                                         msg->src, msg->dst, msg->len,
> @@ -806,7 +795,7 @@ static void rpmsg_recv_done(struct virtqueue *rvq)
>         if (len > RPMSG_BUF_SIZE ||
>                 msg->len > (len - sizeof(struct rpmsg_hdr))) {
>                 dev_warn(dev, "inbound msg too big: (%d, %d)\n", len,
> msg->len);
> -               return;
> +               return -EINVAL;
>         }
> 
>         /* use the dst addr to fetch the callback of the appropriate
> user */
> @@ -842,9 +831,39 @@ static void rpmsg_recv_done(struct virtqueue *rvq)
>         err = virtqueue_add_buf(vrp->rvq, &sg, 0, 1, msg, GFP_KERNEL);
>         if (err < 0) {
>                 dev_err(dev, "failed to add a virtqueue buffer: %d\n",
> err);
> +               return err;
> +       }
> +
> +       return 0;
> +}
> +
> +/* called when an rx buffer is used, and it's time to digest a message
> */
> +static void rpmsg_recv_done(struct virtqueue *rvq)
> +{
> +       struct virtproc_info *vrp = rvq->vdev->priv;
> +       struct device *dev = &rvq->vdev->dev;
> +       struct rpmsg_hdr *msg;
> +       unsigned int len, msgs_received = 0;
> +       int err;
> +
> +       msg = virtqueue_get_buf(rvq, &len);
> +       if (!msg) {
> +               dev_err(dev, "uhm, incoming signal, but no used buffer
> ?\n");
>                 return;
>         }
> 
> +       while (msg) {
> +               err = rpmsg_recv_single(vrp, dev, msg, len);
> +               if (err)
> +                       break;
> +
> +               msgs_received++;
> +
> +               msg = virtqueue_get_buf(rvq, &len);
> +       };
> +
> +       dev_dbg(dev, "Received %u messages\n", msgs_received);
> +
>         /* tell the remote processor we added another available rx
> buffer */
>         virtqueue_kick(vrp->rvq);
>  }

Shouldn't the virtqueue_kick() be called only when we successfully added a buffer with virtqueue_add_buf()?

If so, we should make it:
	if (msgs_received)
		/* tell the remote processor we added another available rx buffer */
		virtqueue_kick(vrp->rvp);
}

Thanks for the rewrite, looks better.  I'll give it a try and let you know how it goes.

Regards,

- Rob



From laurent.pinchart at ideasonboard.com  Mon Apr  8 19:22:29 2013
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Tue, 09 Apr 2013 01:22:29 +0200
Subject: [PATCH v3] irqchip: renesas-intc-irqpin: DT binding for sense
 bitfield width
In-Reply-To: <Pine.LNX.4.64.1304081412550.29945@axis700.grange>
References: <Pine.LNX.4.64.1304081002190.29945@axis700.grange>
 <15518520.KQOfZxAAdo@avalon>
 <Pine.LNX.4.64.1304081412550.29945@axis700.grange>
Message-ID: <2492042.P3NGiSlrcg@avalon>

Hi Guennadi,

On Monday 08 April 2013 14:15:39 Guennadi Liakhovetski wrote:
> On Mon, 8 Apr 2013, Laurent Pinchart wrote:
> > On Monday 08 April 2013 13:25:46 Guennadi Liakhovetski wrote:
> > > On Mon, 8 Apr 2013, Laurent Pinchart wrote:
> > > > On Monday 08 April 2013 10:08:40 Guennadi Liakhovetski wrote:
> > > > > Most Renesas irqpin controllers have 4-bit sense fields, however,
> > > > > some have different widths. This patch adds a DT binding to
> > > > > optionally specify such non-standard values.
> > > > > 
> > > > > Signed-off-by: Guennadi Liakhovetski
> > > > > <g.liakhovetski+renesas at gmail.com>
> > > > > ---
> > > > > 
> > > > > v3: move the code to a common location, where device configuration
> > > > > parameters are retrieved
> > > > > 
> > > > >  .../interrupt-controller/renesas,intc-irqpin.txt   |   13 +++++++++
> > > > >  drivers/irqchip/irq-renesas-intc-irqpin.c          |    4 ++++
> > > > >  2 files changed, 17 insertions(+), 0 deletions(-)
> > > > >  create mode 100644
> > > > > 
> > > > > Documentation/devicetree/bindings/interrupt-controller/renesas,intc-
> > > > > irqpin.txt
> > > > > diff --git a/Documentation/devicetree/bindings/interrupt-
> > > > > controller/renesas,intc-irqpin.txt
> > > > > b/Documentation/devicetree/bindings/interrupt-controller/
> > > > > renesas,intc-irqpin.txt
> > > > > new file mode 100644
> > > > > index 0000000..c6f09b7
> > > > > --- /dev/null
> > > > > +++
> > > > > b/Documentation/devicetree/bindings/interrupt-controller/renesas,int
> > > > > c-
> > > > > irqpin.txt
> > > > > @@ -0,0 +1,13 @@
> > > > > +DT bindings for the R-/SH-Mobile irqpin controller
> > > > > +
> > > > > +Required properties:
> > > > > +
> > > > > +- compatible: has to be "renesas,intc-irqpin"
> > > > > +- #interrupt-cells: has to be <2>
> > > > > +
> > > > > +Optional properties:
> > > > > +
> > > > > +- any properties, listed in interrupts.txt in this directory, and
> > > > > any standard
> > > > > +  resource allocation properties
> > > > > +- sense-bitfield-width: width of a single sense bitfield in the
> > > > > SENSE register,
> > > > > +  if different from the default 4 bits
> > > > 
> > > > Wouldn't it be better to define per-SoC compatible strings, and infer
> > > > the sense bitfield width from that ?
> > > 
> > > This is not a boolean, it is an integer, I don't think defining
> > > compatibility strings for 1, 2, 3, 4, 5,... bits is better than having
> > > one integer property.
> > 
> > I'm not advocating for compatibility strings for a given number of bits,
> > but for per-SoC compatibility strings from which to infer the width.
> > 
> > For instance, if the r8a7779 has a 6-bit sense field, you would use
> > 
> > compatible = "r8a7779,intc-irqpin";
> > 
> > and map that to 6 in the irqpin driver.
> 
> I understand what you mean, still I don't think mapping N SoC-compatibility
> strings to various values of a single integer is better than having a single
> property.

The way I understand (or maybe rather feel) the DT bindings philosophy is that 
hardware information for on-SoC IP cores that depend on the IP core version 
should be conveyed through the compatible property. I might be wrong though.

-- 
Regards,

Laurent Pinchart



From tony at atomide.com  Mon Apr  8 19:27:19 2013
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 8 Apr 2013 16:27:19 -0700
Subject: [PATCH v4 0/3] ARM: OMAP2+: Export SoC information to
 userspace using SoC infrastructure
In-Reply-To: <1360842924-32429-1-git-send-email-ruslan.bilovol@ti.com>
References: <1360842924-32429-1-git-send-email-ruslan.bilovol@ti.com>
Message-ID: <20130408232718.GE10155@atomide.com>

* Ruslan Bilovol <ruslan.bilovol at ti.com> [130214 03:59]:
> Hi,
> 
> This patch series is an attempt to export some OMAP SoC
> information (like name, revision etc.) to userspace.
> The first patch does some unification of OMAP SoC
> information representation in current sources.
> Second patch adds exactly needed changes using
> exists in Linux kernel SoC infrastructure.

Thanks for your patience with these patches,
applying into omap-for-v3.10/soc.

Tony
 
> -----------------------------------------
> v4:
> - Moved common part of late init into common function  in additional
>   separate patch
> - rebased on top of 'omap-for-v3.9/soc' branch of tmlind/linux-omap tree
> 
> -----------------------------------------
> v3:
> - reduced number of lines changed in the first patch (reusing
>   existent code)
> 
> -----------------------------------------
> v2:
> - changed cpu_* -> soc_* variable names
> - rebased on top of 'omap-for-v3.9/soc' branch of tmlind/linux-omap tree
> 
> 
> Ruslan Bilovol (3):
>   ARM: OMAP2+: Move common part of late init into common function
>   ARM: OMAP2+: SoC name and revision unification
>   ARM: OMAP2+: Export SoC information to userspace
> 
>  arch/arm/mach-omap2/common.h |    8 ++++
>  arch/arm/mach-omap2/id.c     |   95 ++++++++++++++++++++++++++++++++++++++----
>  arch/arm/mach-omap2/io.c     |   34 +++++++--------
>  arch/arm/plat-omap/Kconfig   |    1 +
>  4 files changed, 112 insertions(+), 26 deletions(-)
> 
> -- 
> 1.7.9.5
> 


From tony at atomide.com  Mon Apr  8 19:27:25 2013
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 8 Apr 2013 16:27:25 -0700
Subject: [PATCH] ARM: OMAP4: Enable fix for Cortex-A9 erratas
In-Reply-To: <1363876938-31724-1-git-send-email-r.sricharan@ti.com>
References: <1363876938-31724-1-git-send-email-r.sricharan@ti.com>
Message-ID: <20130408232725.GF10155@atomide.com>

* Sricharan R <r.sricharan at ti.com> [130321 07:46]:
> This enables the fixes for the below erratas
> applicable for OMAP4 Socs.
> 
> 754322: Faulty MMU translations following ASID switch
> 
> 775420: A data cache maintenance operation which aborts,
>         followed by an ISB, without any DSB in-between,
>         might lead to deadlock
> 
> Signed-off-by: Sricharan R <r.sricharan at ti.com>
> Acked-by: Santosh Shilimkar <santosh.shilimkar at ti.com>

Thanks applying into omap-for-v3.10/soc.

Tony

> ---
>  arch/arm/mach-omap2/Kconfig |    2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
> index c3477e7..c4a3f3f 100644
> --- a/arch/arm/mach-omap2/Kconfig
> +++ b/arch/arm/mach-omap2/Kconfig
> @@ -73,6 +73,8 @@ config ARCH_OMAP4
>  	select PM_RUNTIME if CPU_IDLE
>  	select USB_ARCH_HAS_EHCI if USB_SUPPORT
>  	select COMMON_CLK
> +	select ARM_ERRATA_754322
> +	select ARM_ERRATA_775420
>  
>  config SOC_OMAP5
>  	bool "TI OMAP5"
> -- 
> 1.7.9.5
> 


From sfr at canb.auug.org.au  Mon Apr  8 19:38:42 2013
From: sfr at canb.auug.org.au (Stephen Rothwell)
Date: Tue, 9 Apr 2013 09:38:42 +1000
Subject: GENERIC_GPIO considered deprecated
In-Reply-To: <201304082136.44905.arnd@arndb.de>
References: <CAAVeFu+QUw1WmzwaJDfjyw75PrStd3p3PHs1MU5BC7_WXMB7kw@mail.gmail.com>
 <2c9501ce342b$1535d290$3fa177b0$%kim@samsung.com>
 <5162EC32.2030602@wwwdotorg.org> <201304082136.44905.arnd@arndb.de>
Message-ID: <20130409093842.656ae3fff92d5368db5c0646@canb.auug.org.au>

Hi all,

On Mon, 8 Apr 2013 21:36:44 +0200 Arnd Bergmann <arnd at arndb.de> wrote:
>
> On Monday 08 April 2013, Stephen Warren wrote:
> > >>
> > >> Should do the trick, if we can make sure that your tree is merged
> > >> prior to my patches.
> > > 
> > > I'm not sure but I think, arm-soc tree should be merged into mainline before others...
> > > 
> > >> Can you put it into your tree for 3.10?
> > >>
> > > I did, so it should be fine.
> > > 
> > 
> > You may want to discuss how to handle this dependency with the arm-soc
> > maintainers (CC'd).
> 
> I'm fine with putting the same branch into arm-soc as well as the gpio tree
> and anything else that might need it, that tends to be the least invasive
> way.

Just a reminder: that had better be the exact same branch and that branch
had better never be rebased/rewritten ...

-- 
Cheers,
Stephen Rothwell                    sfr at canb.auug.org.au
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130409/1f974ace/attachment-0001.sig>

From rtivy at ti.com  Mon Apr  8 19:55:58 2013
From: rtivy at ti.com (Tivy, Robert)
Date: Mon, 8 Apr 2013 23:55:58 +0000
Subject: [PATCH v9 4/6] ARM: davinci: Add a remoteproc driver
 implementation for OMAP-L13x DSP
In-Reply-To: <5161B2FC.2090605@cogentembedded.com>
References: <1364521307-1219-1-git-send-email-rtivy@ti.com>
 <1364521307-1219-5-git-send-email-rtivy@ti.com>
 <CAK=WgbZme2UkMeP-JB2h3xnmcpzAaYeOcy7gxh60muJ8KZbr_A@mail.gmail.com>
 <5161B2FC.2090605@cogentembedded.com>
Message-ID: <13514BD7FAEBA745BBD7D8A672905C1431230384@DFLE12.ent.ti.com>

Hi Sergei,

> -----Original Message-----
> From: Sergei Shtylyov [mailto:sergei.shtylyov at cogentembedded.com]
> Sent: Sunday, April 07, 2013 10:55 AM
> 
> Hello.
> 
> On 04/07/2013 05:02 PM, Ohad Ben-Cohen wrote:
> 
> >
> >> +static int da8xx_rproc_probe(struct platform_device *pdev)
> >> +{
> >> +       struct device *dev = &pdev->dev;
> >> +       struct da8xx_rproc *drproc;
> >> +       struct rproc *rproc;
> >> +       struct irq_data *irq_data;
> >> +       struct resource *bootreg_res;
> >> +       struct resource *chipsig_res;
> >> +       struct clk *dsp_clk;
> >> +       void __iomem *chipsig;
> >> +       void __iomem *bootreg;
> >> +       int irq;
> >> +       int ret;
> >> +
> [...]
> >> +       bootreg = devm_request_and_ioremap(dev, bootreg_res);
> >> +       if (!bootreg) {
> >> +               dev_err(dev, "unable to map boot register\n");
> >> +               return -EADDRNOTAVAIL;
> >> +       }
> >> +
> >> +       chipsig = devm_request_and_ioremap(dev, chipsig_res);
> 
>     I suggest that you use more modern (yes, already a newer interface
> :-)
> devm_ioremap_resource() instead -- it returns the error code (as a
> pointer)
> in case of error, and it certainly doesn't require you to print error
> messages.

Thanks, will do.

I appreciate the notice of a more modern function, it's really tough to keep up with the flurry of activity to the kernel.

Regarding this change, should the code use
	return PTR_ERR(bootreg);
or
	return PTR_RET(bootreg);
I ask because PTR_ERR() returns 'long' whereas PTR_RET() returns 'int' (and probe returns 'int'), but I see that the majority of existing code uses "return PTR_ERR()" in probe functions.

> 
> >> +       if (!chipsig) {
> >> +               dev_err(dev, "unable to map CHIPSIG register\n");
> >> +               return -EADDRNOTAVAIL;
> >> +       }
> >>
> 
> WBR, Sergei

Regards,

- Rob



From gnurou at gmail.com  Mon Apr  8 20:07:54 2013
From: gnurou at gmail.com (Alexandre Courbot)
Date: Mon, 8 Apr 2013 17:07:54 -0700
Subject: GENERIC_GPIO considered deprecated
In-Reply-To: <20130409093842.656ae3fff92d5368db5c0646@canb.auug.org.au>
References: <CAAVeFu+QUw1WmzwaJDfjyw75PrStd3p3PHs1MU5BC7_WXMB7kw@mail.gmail.com>
 <2c9501ce342b$1535d290$3fa177b0$%kim@samsung.com>
 <5162EC32.2030602@wwwdotorg.org> <201304082136.44905.arnd@arndb.de>
 <20130409093842.656ae3fff92d5368db5c0646@canb.auug.org.au>
Message-ID: <CAAVeFuJCxYiOXRkjJZXpSFUaGoiAtWwBWBJmxXUyQMkmrSEsew@mail.gmail.com>

On Mon, Apr 8, 2013 at 4:38 PM, Stephen Rothwell <sfr at canb.auug.org.au> wrote:
> Hi all,
>
> On Mon, 8 Apr 2013 21:36:44 +0200 Arnd Bergmann <arnd at arndb.de> wrote:
>>
>> On Monday 08 April 2013, Stephen Warren wrote:
>> > >>
>> > >> Should do the trick, if we can make sure that your tree is merged
>> > >> prior to my patches.
>> > >
>> > > I'm not sure but I think, arm-soc tree should be merged into mainline before others...
>> > >
>> > >> Can you put it into your tree for 3.10?
>> > >>
>> > > I did, so it should be fine.
>> > >
>> >
>> > You may want to discuss how to handle this dependency with the arm-soc
>> > maintainers (CC'd).
>>
>> I'm fine with putting the same branch into arm-soc as well as the gpio tree
>> and anything else that might need it, that tends to be the least invasive
>> way.
>
> Just a reminder: that had better be the exact same branch and that branch
> had better never be rebased/rewritten ...

Sorry, which branch are we talking about - is it the one I published
for -next initially? If so wouldn't it be simpler to withdraw it and
have Grant integrate the patches in his branch? Since no one depends
on them for now anyway...

I remember rebasing it once some time ago to add Acked-bys, but it
hasn't changed since then.

Alex.


From sfr at canb.auug.org.au  Mon Apr  8 20:10:35 2013
From: sfr at canb.auug.org.au (Stephen Rothwell)
Date: Tue, 9 Apr 2013 10:10:35 +1000
Subject: GENERIC_GPIO considered deprecated
In-Reply-To: <CAAVeFuJCxYiOXRkjJZXpSFUaGoiAtWwBWBJmxXUyQMkmrSEsew@mail.gmail.com>
References: <CAAVeFu+QUw1WmzwaJDfjyw75PrStd3p3PHs1MU5BC7_WXMB7kw@mail.gmail.com>
 <2c9501ce342b$1535d290$3fa177b0$%kim@samsung.com>
 <5162EC32.2030602@wwwdotorg.org> <201304082136.44905.arnd@arndb.de>
 <20130409093842.656ae3fff92d5368db5c0646@canb.auug.org.au>
 <CAAVeFuJCxYiOXRkjJZXpSFUaGoiAtWwBWBJmxXUyQMkmrSEsew@mail.gmail.com>
Message-ID: <20130409101035.c59edcf9fa6e40a064f7fe41@canb.auug.org.au>

Hi,

On Mon, 8 Apr 2013 17:07:54 -0700 Alexandre Courbot <gnurou at gmail.com> wrote:
>
> On Mon, Apr 8, 2013 at 4:38 PM, Stephen Rothwell <sfr at canb.auug.org.au> wrote:
> >
> > On Mon, 8 Apr 2013 21:36:44 +0200 Arnd Bergmann <arnd at arndb.de> wrote:
> >>
> >> On Monday 08 April 2013, Stephen Warren wrote:
> >> > >>
> >> > >> Should do the trick, if we can make sure that your tree is merged
> >> > >> prior to my patches.
> >> > >
> >> > > I'm not sure but I think, arm-soc tree should be merged into mainline before others...
> >> > >
> >> > >> Can you put it into your tree for 3.10?
> >> > >>
> >> > > I did, so it should be fine.
> >> > >
> >> >
> >> > You may want to discuss how to handle this dependency with the arm-soc
> >> > maintainers (CC'd).
> >>
> >> I'm fine with putting the same branch into arm-soc as well as the gpio tree
> >> and anything else that might need it, that tends to be the least invasive
> >> way.
> >
> > Just a reminder: that had better be the exact same branch and that branch
> > had better never be rebased/rewritten ...
> 
> Sorry, which branch are we talking about - is it the one I published
> for -next initially? If so wouldn't it be simpler to withdraw it and
> have Grant integrate the patches in his branch? Since no one depends
> on them for now anyway...
> 
> I remember rebasing it once some time ago to add Acked-bys, but it
> hasn't changed since then.

I am talking about the branch that Arnd says should be merged into both
the arm-soc and gpio trees.

-- 
Cheers,
Stephen Rothwell                    sfr at canb.auug.org.au
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130409/dcce9b66/attachment.sig>

From tony at atomide.com  Mon Apr  8 20:15:01 2013
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 8 Apr 2013 17:15:01 -0700
Subject: [GIT PULL] ARM: OMAP: Device Tree for 3.10
In-Reply-To: <516348B5.3060400@ti.com>
References: <516348B5.3060400@ti.com>
Message-ID: <20130409001501.GH10155@atomide.com>

* Benoit Cousson <b-cousson at ti.com> [130408 15:50]:
> Hi Tony,
> 
> Please pull the following commits for OMAP Device Tree for v3.10.
> 
> Note that the branch is based on two other branches:
> 
> - omap-devel-b-for-3.10 from Paul to get the AM33xx missing hwmod and thus avoid a regression with Santosh's hwmod cleanup including in this DT series [1]. It avoids breaking bisect if this series is merged before Paul's fixes.
> 
> - omap-for-v3.10/usb branch to avoid nasty merge conflict in omap3.dtsi and omap4.dtsi due to the DTS patches contains in the USB branch.

Thanks pulling into omap-for-v3.10/dt.

Tony
 
> [1] https://patchwork.kernel.org/patch/2366291/


From tony at atomide.com  Mon Apr  8 20:15:30 2013
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 8 Apr 2013 17:15:30 -0700
Subject: [PATCH v2] arm/dts: OMAP3: fix pinctrl-single configuration
In-Reply-To: <1364574725.4634.51.camel@mars>
References: <1364458106.3757.11.camel@mars>
 <20130328163854.GV10155@atomide.com>
 <1364549848.4634.13.camel@mars>
 <20130329151759.GB10155@atomide.com>
 <1364574725.4634.51.camel@mars>
Message-ID: <20130409001530.GI10155@atomide.com>

* Christoph Fritz <chf.fritz at googlemail.com> [130329 09:36]:
>  - Fix 'function-mask' referring to TRM (Omap 36xx) Section 13.4.4:
>    "Pad Functional Multiplexing and Configuration".
>  - Fix 'omap3_pmx_wkup' referring to TRM Table 13-6:
>    "Wkup Control Module Pad Configuration Register Fields".

Thanks applying into omap-for-v3.10/dt on top of the patches
queued by Benoit.

Tony
 
> Signed-off-by: Christoph Fritz <chf.fritz at googlemail.com>
> ---
>  arch/arm/boot/dts/omap3.dtsi |   10 +++++-----
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
> index 1acc261..1997b41 100644
> --- a/arch/arm/boot/dts/omap3.dtsi
> +++ b/arch/arm/boot/dts/omap3.dtsi
> @@ -27,7 +27,7 @@
>  	};
>  
>  	/*
> -	 * The soc node represents the soc top level view. It is uses for IPs
> +	 * The soc node represents the soc top level view. It is used for IPs
>  	 * that are not memory mapped in the MPU view or for the MPU itself.
>  	 */
>  	soc {
> @@ -81,16 +81,16 @@
>  			#address-cells = <1>;
>  			#size-cells = <0>;
>  			pinctrl-single,register-width = <16>;
> -			pinctrl-single,function-mask = <0x7fff>;
> +			pinctrl-single,function-mask = <0x7f1f>;
>  		};
>  
> -		omap3_pmx_wkup: pinmux at 0x48002a58 {
> +		omap3_pmx_wkup: pinmux at 0x48002a00 {
>  			compatible = "ti,omap3-padconf", "pinctrl-single";
> -			reg = <0x48002a58 0x5c>;
> +			reg = <0x48002a00 0x5c>;
>  			#address-cells = <1>;
>  			#size-cells = <0>;
>  			pinctrl-single,register-width = <16>;
> -			pinctrl-single,function-mask = <0x7fff>;
> +			pinctrl-single,function-mask = <0x7f1f>;
>  		};
>  
>  		gpio1: gpio at 48310000 {
> -- 
> 1.7.10.4
> 
> 
> 


From akpm at linux-foundation.org  Mon Apr  8 20:16:37 2013
From: akpm at linux-foundation.org (Andrew Morton)
Date: Mon, 8 Apr 2013 17:16:37 -0700
Subject: [PATCH V2] video: implement a simple framebuffer driver
In-Reply-To: <1365043183-28905-1-git-send-email-swarren@wwwdotorg.org>
References: <1365043183-28905-1-git-send-email-swarren@wwwdotorg.org>
Message-ID: <20130408171637.98b5ad1f867bcbda883af68b@linux-foundation.org>

On Wed,  3 Apr 2013 20:39:43 -0600 Stephen Warren <swarren at wwwdotorg.org> wrote:

> A simple frame-buffer describes a raw memory region that may be rendered
> to, with the assumption that the display hardware has already been set
> up to scan out from that buffer.
> 
> This is useful in cases where a bootloader exists and has set up the
> display hardware, but a Linux driver doesn't yet exist for the display
> hardware.
> 
> ...
>
> +config FB_SIMPLE
> +	bool "Simple framebuffer support"
> +	depends on (FB = y) && OF

It's sad that this simple little thing requires Open Firmware.  Could
it be generalised in some way so that the small amount of setup info
could be provided by other means (eg, module_param) or does the
dependency go deeper than that?

> +struct simplefb_format simplefb_formats[] = {
> +	{ "r5g6b5", 16, {11, 5}, {5, 6}, {0, 5}, {0, 0} },
> +};

I'll make this static.



From ezequiel.garcia at free-electrons.com  Mon Apr  8 20:42:54 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Mon, 8 Apr 2013 21:42:54 -0300
Subject: [PATCH v4 1/5] drivers: memory: Introduce Marvell EBU Device Bus
 driver
In-Reply-To: <20130408171940.GA8815@obsidianresearch.com>
References: <1365419194-20871-1-git-send-email-ezequiel.garcia@free-electrons.com>
 <1365419194-20871-2-git-send-email-ezequiel.garcia@free-electrons.com>
 <20130408171940.GA8815@obsidianresearch.com>
Message-ID: <20130409004253.GA2258@localhost>

Hi Jason

On Mon, Apr 08, 2013 at 11:19:40AM -0600, Jason Gunthorpe wrote:
> Looks OK to me, though with mbus dt bindings we'd see some more
> changes.
> 

Thanks for the review!

> Just to note on them for future:
> 
> > +	child = of_get_next_child(node, NULL);
> > +	if (!child) {
> > +		dev_err(dev, "%s has no childs\n", node->full_name);
> > +		return -EINVAL;
> > +	}
> 
> This isn't really necessary anymore, the ranges of the node itself
> should be parsed to get the window start/end. The driver should never
> need to look at the children directly..
> 

You mean the above will not be necessary in the *future*,
once we add mbus DT bindings, right?

AFAICT, it's needed for the current workaround to work.
FWIW, the whole code below the *FIXME* is part of the temporary
to-be-removed thing.

Maybe I'll add a special comment on each chunk that's meant
to be removed to avoid confusions.

> > +	/* Get the CS to choose the window string */
> > +	err = of_property_read_u32(node, "ranges", &cs);
> > +	if (err < 0)
> > +		return err;
> 
> .. and this is why you've kept the 2 cells address - the top cell is
> still encoding the target id. This would go away eventually too..
> 
> Maybe it would be better in the interm to compute the CS offset from
> the control register offset?
> 
> (reg.start % 0x400)/8 should do the trick?
> 

Yes, I'll do this and drop the 2-cell address.

> > +	devbus->child = of_platform_device_create(child, NULL, &pdev->dev);
> > +	if (!devbus->child) {
> > +		dev_warn(dev, "cannot create child device %s\n", child->name);
> > +		/* Remove the allocated window */
> > +		mvebu_mbus_del_window(devbus->child_mem.start,
> > +				      resource_size(&devbus->child_mem));
> > +	}
> 
> This can probably just be of_platform_populate or similar to do all
> children? For instance, I often use many DT nodes to represent a FPGA,
> since the my FPGA's tend to have many functionally orthogonal units
> inside.
> 

In the past I've found it's not possible to use of_platform_populate,
altough I can be wrong.

The problem seems to be that through of_platform_populate() it's
possible that the child device (cfi-flash, for instance) gets probed
before the devbus controller. In other words, the actual parent-child
relationship gets lost and it's necesarry to use some child probe deferal
mechanism.

This has been recently discussed [1] when implementing GPMC where for simplicity
the of_platform_device_create() solution was chosen.
Anyway, I'll try of_platform_populate early tomorrow.

Thanks,

[1]  http://www.mail-archive.com/linux-omap at vger.kernel.org/msg85897.html
-- 
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com


From mturquette at linaro.org  Mon Apr  8 21:14:33 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Mon, 08 Apr 2013 18:14:33 -0700
Subject: [PATCH V3 1/3] clk: ux500: Add support for sysctrl clocks
In-Reply-To: <1364992017-12683-1-git-send-email-ulf.hansson@stericsson.com>
References: <1364992017-12683-1-git-send-email-ulf.hansson@stericsson.com>
Message-ID: <20130409011433.14359.14140@quantum>

Quoting Ulf Hansson (2013-04-03 05:26:57)
> From: Ulf Hansson <ulf.hansson at linaro.org>
> 
> The abx500 sysctrl clocks are using the ab8500 sysctrl driver to
> modify the clock hardware. Sysctrl clocks are represented by a
> ab8500 sysctrl register and with a corresponding bitmask.
> 
> The sysctrl clocks are slow path clocks, which means clk_prepare
> and clk_unprepare will be used to gate|ungate these clocks.
> 
> Signed-off-by: Ulf Hansson <ulf.hansson at linaro.org>

Hi Ulf,

Is there a V3 update for patches #2 & #3?  I can't seem to find them.

Regards,
Mike

> ---
> 
> Changes in v3:
>         - Fixed error check at clk registration.
> Changes in v2:
>         - Removed wrong header file.
> ---
>  drivers/clk/ux500/Makefile      |    1 +
>  drivers/clk/ux500/clk-sysctrl.c |  221 +++++++++++++++++++++++++++++++++++++++
>  drivers/clk/ux500/clk.h         |   29 +++++
>  3 files changed, 251 insertions(+)
>  create mode 100644 drivers/clk/ux500/clk-sysctrl.c
> 
> diff --git a/drivers/clk/ux500/Makefile b/drivers/clk/ux500/Makefile
> index bcc0c11..c6a806e 100644
> --- a/drivers/clk/ux500/Makefile
> +++ b/drivers/clk/ux500/Makefile
> @@ -5,6 +5,7 @@
>  # Clock types
>  obj-y += clk-prcc.o
>  obj-y += clk-prcmu.o
> +obj-y += clk-sysctrl.o
>  
>  # Clock definitions
>  obj-y += u8500_clk.o
> diff --git a/drivers/clk/ux500/clk-sysctrl.c b/drivers/clk/ux500/clk-sysctrl.c
> new file mode 100644
> index 0000000..bc7e9bd
> --- /dev/null
> +++ b/drivers/clk/ux500/clk-sysctrl.c
> @@ -0,0 +1,221 @@
> +/*
> + * Sysctrl clock implementation for ux500 platform.
> + *
> + * Copyright (C) 2013 ST-Ericsson SA
> + * Author: Ulf Hansson <ulf.hansson at linaro.org>
> + *
> + * License terms: GNU General Public License (GPL) version 2
> + */
> +
> +#include <linux/clk-provider.h>
> +#include <linux/mfd/abx500/ab8500-sysctrl.h>
> +#include <linux/device.h>
> +#include <linux/slab.h>
> +#include <linux/delay.h>
> +#include <linux/io.h>
> +#include <linux/err.h>
> +#include "clk.h"
> +
> +#define SYSCTRL_MAX_NUM_PARENTS 4
> +
> +#define to_clk_sysctrl(_hw) container_of(_hw, struct clk_sysctrl, hw)
> +
> +struct clk_sysctrl {
> +       struct clk_hw hw;
> +       struct device *dev;
> +       u8 parent_index;
> +       u16 reg_sel[SYSCTRL_MAX_NUM_PARENTS];
> +       u8 reg_mask[SYSCTRL_MAX_NUM_PARENTS];
> +       u8 reg_bits[SYSCTRL_MAX_NUM_PARENTS];
> +       unsigned long rate;
> +       unsigned long enable_delay_us;
> +};
> +
> +/* Sysctrl clock operations. */
> +
> +static int clk_sysctrl_prepare(struct clk_hw *hw)
> +{
> +       int ret;
> +       struct clk_sysctrl *clk = to_clk_sysctrl(hw);
> +
> +       ret = ab8500_sysctrl_write(clk->reg_sel[0], clk->reg_mask[0],
> +                               clk->reg_bits[0]);
> +
> +       if (!ret && clk->enable_delay_us)
> +               usleep_range(clk->enable_delay_us, clk->enable_delay_us);
> +
> +       return ret;
> +}
> +
> +static void clk_sysctrl_unprepare(struct clk_hw *hw)
> +{
> +       struct clk_sysctrl *clk = to_clk_sysctrl(hw);
> +       if (ab8500_sysctrl_clear(clk->reg_sel[0], clk->reg_mask[0]))
> +               dev_err(clk->dev, "clk_sysctrl: %s fail to clear %s.\n",
> +                       __func__, __clk_get_name(hw->clk));
> +}
> +
> +static unsigned long clk_sysctrl_recalc_rate(struct clk_hw *hw,
> +                                       unsigned long parent_rate)
> +{
> +       struct clk_sysctrl *clk = to_clk_sysctrl(hw);
> +       return clk->rate;
> +}
> +
> +static int clk_sysctrl_set_parent(struct clk_hw *hw, u8 index)
> +{
> +       struct clk_sysctrl *clk = to_clk_sysctrl(hw);
> +       u8 old_index = clk->parent_index;
> +       int ret = 0;
> +
> +       if (clk->reg_sel[old_index]) {
> +               ret = ab8500_sysctrl_clear(clk->reg_sel[old_index],
> +                                       clk->reg_mask[old_index]);
> +               if (ret)
> +                       return ret;
> +       }
> +
> +       if (clk->reg_sel[index]) {
> +               ret = ab8500_sysctrl_write(clk->reg_sel[index],
> +                                       clk->reg_mask[index],
> +                                       clk->reg_bits[index]);
> +               if (ret) {
> +                       if (clk->reg_sel[old_index])
> +                               ab8500_sysctrl_write(clk->reg_sel[old_index],
> +                                               clk->reg_mask[old_index],
> +                                               clk->reg_bits[old_index]);
> +                       return ret;
> +               }
> +       }
> +       clk->parent_index = index;
> +
> +       return ret;
> +}
> +
> +static u8 clk_sysctrl_get_parent(struct clk_hw *hw)
> +{
> +       struct clk_sysctrl *clk = to_clk_sysctrl(hw);
> +       return clk->parent_index;
> +}
> +
> +static struct clk_ops clk_sysctrl_gate_ops = {
> +       .prepare = clk_sysctrl_prepare,
> +       .unprepare = clk_sysctrl_unprepare,
> +};
> +
> +static struct clk_ops clk_sysctrl_gate_fixed_rate_ops = {
> +       .prepare = clk_sysctrl_prepare,
> +       .unprepare = clk_sysctrl_unprepare,
> +       .recalc_rate = clk_sysctrl_recalc_rate,
> +};
> +
> +static struct clk_ops clk_sysctrl_set_parent_ops = {
> +       .set_parent = clk_sysctrl_set_parent,
> +       .get_parent = clk_sysctrl_get_parent,
> +};
> +
> +static struct clk *clk_reg_sysctrl(struct device *dev,
> +                               const char *name,
> +                               const char **parent_names,
> +                               u8 num_parents,
> +                               u16 *reg_sel,
> +                               u8 *reg_mask,
> +                               u8 *reg_bits,
> +                               unsigned long rate,
> +                               unsigned long enable_delay_us,
> +                               unsigned long flags,
> +                               struct clk_ops *clk_sysctrl_ops)
> +{
> +       struct clk_sysctrl *clk;
> +       struct clk_init_data clk_sysctrl_init;
> +       struct clk *clk_reg;
> +       int i;
> +
> +       if (!dev)
> +               return ERR_PTR(-EINVAL);
> +
> +       if (!name || (num_parents > SYSCTRL_MAX_NUM_PARENTS)) {
> +               dev_err(dev, "clk_sysctrl: invalid arguments passed\n");
> +               return ERR_PTR(-EINVAL);
> +       }
> +
> +       clk = devm_kzalloc(dev, sizeof(struct clk_sysctrl), GFP_KERNEL);
> +       if (!clk) {
> +               dev_err(dev, "clk_sysctrl: could not allocate clk\n");
> +               return ERR_PTR(-ENOMEM);
> +       }
> +
> +       for (i = 0; i < num_parents; i++) {
> +               clk->reg_sel[i] = reg_sel[i];
> +               clk->reg_bits[i] = reg_bits[i];
> +               clk->reg_mask[i] = reg_mask[i];
> +       }
> +
> +       clk->parent_index = 0;
> +       clk->rate = rate;
> +       clk->enable_delay_us = enable_delay_us;
> +       clk->dev = dev;
> +
> +       clk_sysctrl_init.name = name;
> +       clk_sysctrl_init.ops = clk_sysctrl_ops;
> +       clk_sysctrl_init.flags = flags;
> +       clk_sysctrl_init.parent_names = parent_names;
> +       clk_sysctrl_init.num_parents = num_parents;
> +       clk->hw.init = &clk_sysctrl_init;
> +
> +       clk_reg = devm_clk_register(clk->dev, &clk->hw);
> +       if (IS_ERR(clk_reg))
> +               dev_err(dev, "clk_sysctrl: clk_register failed\n");
> +
> +       return clk_reg;
> +}
> +
> +struct clk *clk_reg_sysctrl_gate(struct device *dev,
> +                               const char *name,
> +                               const char *parent_name,
> +                               u16 reg_sel,
> +                               u8 reg_mask,
> +                               u8 reg_bits,
> +                               unsigned long enable_delay_us,
> +                               unsigned long flags)
> +{
> +       const char **parent_names = (parent_name ? &parent_name : NULL);
> +       u8 num_parents = (parent_name ? 1 : 0);
> +
> +       return clk_reg_sysctrl(dev, name, parent_names, num_parents,
> +                       &reg_sel, &reg_mask, &reg_bits, 0, enable_delay_us,
> +                       flags, &clk_sysctrl_gate_ops);
> +}
> +
> +struct clk *clk_reg_sysctrl_gate_fixed_rate(struct device *dev,
> +                                       const char *name,
> +                                       const char *parent_name,
> +                                       u16 reg_sel,
> +                                       u8 reg_mask,
> +                                       u8 reg_bits,
> +                                       unsigned long rate,
> +                                       unsigned long enable_delay_us,
> +                                       unsigned long flags)
> +{
> +       const char **parent_names = (parent_name ? &parent_name : NULL);
> +       u8 num_parents = (parent_name ? 1 : 0);
> +
> +       return clk_reg_sysctrl(dev, name, parent_names, num_parents,
> +                       &reg_sel, &reg_mask, &reg_bits,
> +                       rate, enable_delay_us, flags,
> +                       &clk_sysctrl_gate_fixed_rate_ops);
> +}
> +
> +struct clk *clk_reg_sysctrl_set_parent(struct device *dev,
> +                               const char *name,
> +                               const char **parent_names,
> +                               u8 num_parents,
> +                               u16 *reg_sel,
> +                               u8 *reg_mask,
> +                               u8 *reg_bits,
> +                               unsigned long flags)
> +{
> +       return clk_reg_sysctrl(dev, name, parent_names, num_parents,
> +                       reg_sel, reg_mask, reg_bits, 0, 0, flags,
> +                       &clk_sysctrl_set_parent_ops);
> +}
> diff --git a/drivers/clk/ux500/clk.h b/drivers/clk/ux500/clk.h
> index c3e4491..3d2dfdc 100644
> --- a/drivers/clk/ux500/clk.h
> +++ b/drivers/clk/ux500/clk.h
> @@ -11,6 +11,7 @@
>  #define __UX500_CLK_H
>  
>  #include <linux/clk.h>
> +#include <linux/device.h>
>  
>  struct clk *clk_reg_prcc_pclk(const char *name,
>                               const char *parent_name,
> @@ -57,4 +58,32 @@ struct clk *clk_reg_prcmu_opp_volt_scalable(const char *name,
>                                             unsigned long rate,
>                                             unsigned long flags);
>  
> +struct clk *clk_reg_sysctrl_gate(struct device *dev,
> +                                const char *name,
> +                                const char *parent_name,
> +                                u16 reg_sel,
> +                                u8 reg_mask,
> +                                u8 reg_bits,
> +                                unsigned long enable_delay_us,
> +                                unsigned long flags);
> +
> +struct clk *clk_reg_sysctrl_gate_fixed_rate(struct device *dev,
> +                                           const char *name,
> +                                           const char *parent_name,
> +                                           u16 reg_sel,
> +                                           u8 reg_mask,
> +                                           u8 reg_bits,
> +                                           unsigned long rate,
> +                                           unsigned long enable_delay_us,
> +                                           unsigned long flags);
> +
> +struct clk *clk_reg_sysctrl_set_parent(struct device *dev,
> +                                      const char *name,
> +                                      const char **parent_names,
> +                                      u8 num_parents,
> +                                      u16 *reg_sel,
> +                                      u8 *reg_mask,
> +                                      u8 *reg_bits,
> +                                      unsigned long flags);
> +
>  #endif /* __UX500_CLK_H */
> -- 
> 1.7.10


From mturquette at linaro.org  Mon Apr  8 21:21:36 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Mon, 08 Apr 2013 18:21:36 -0700
Subject: [PATCH V4 0/3] clk: Fixup issues for clk_set_parent
In-Reply-To: <1364936979-20805-1-git-send-email-ulf.hansson@stericsson.com>
References: <1364936979-20805-1-git-send-email-ulf.hansson@stericsson.com>
Message-ID: <20130409012136.14359.33264@quantum>

Quoting Ulf Hansson (2013-04-02 14:09:36)
> From: Ulf Hansson <ulf.hansson at linaro.org>
> 
> These issues exist in the clk_set_parent API:
> 
> * Race issue for spinlocks when updating the clock tree toplogy.
> * The feature of reparent to the orphan list is broken.
> 

Taken into clk-next.

Thanks,
Mike

> This patchset fixes both problems. Patch 1 prepares for patch 2 and
> patch 3, which are where the real issues are resolved.
> 
> Changes in v4:
>         - Rebased on top Mike's clk reentrancy patches.
> 
> Changes in v3:
>         - Fix review comments from Mike.
>         - Include fixup for allow reparent to the orphan list.
> 
> Changes in v2:
>         - Do not remove the existing __clk_reparent API.
>         - Rebase patches.
> 
> Ulf Hansson (3):
>   clk: Restructure code for __clk_reparent
>   clk: Fixup errorhandling for clk_set_parent
>   clk: Fixup locking issues for clk_set_parent
> 
>  drivers/clk/clk.c |  193 ++++++++++++++++++++++++++++++++++++-----------------
>  1 file changed, 130 insertions(+), 63 deletions(-)
> 
> -- 
> 1.7.10


From kgene.kim at samsung.com  Mon Apr  8 21:45:49 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Tue, 09 Apr 2013 10:45:49 +0900
Subject: GENERIC_GPIO considered deprecated
In-Reply-To: <20130409101035.c59edcf9fa6e40a064f7fe41@canb.auug.org.au>
References: <CAAVeFu+QUw1WmzwaJDfjyw75PrStd3p3PHs1MU5BC7_WXMB7kw@mail.gmail.com>
 <2c9501ce342b$1535d290$3fa177b0$%kim@samsung.com>
 <5162EC32.2030602@wwwdotorg.org> <201304082136.44905.arnd@arndb.de>
 <20130409093842.656ae3fff92d5368db5c0646@canb.auug.org.au>
 <CAAVeFuJCxYiOXRkjJZXpSFUaGoiAtWwBWBJmxXUyQMkmrSEsew@mail.gmail.com>
 <20130409101035.c59edcf9fa6e40a064f7fe41@canb.auug.org.au>
Message-ID: <2e6101ce34c3$f6449580$e2cdc080$%kim@samsung.com>

Stephen Rothwell wrote:
> 
> Hi,
> 
> On Mon, 8 Apr 2013 17:07:54 -0700 Alexandre Courbot <gnurou at gmail.com>
> wrote:
> >
> > On Mon, Apr 8, 2013 at 4:38 PM, Stephen Rothwell <sfr at canb.auug.org.au>
> wrote:
> > >
> > > On Mon, 8 Apr 2013 21:36:44 +0200 Arnd Bergmann <arnd at arndb.de> wrote:
> > >>
> > >> On Monday 08 April 2013, Stephen Warren wrote:
> > >> > >>
> > >> > >> Should do the trick, if we can make sure that your tree is
> merged
> > >> > >> prior to my patches.
> > >> > >
> > >> > > I'm not sure but I think, arm-soc tree should be merged into
> mainline before others...
> > >> > >
> > >> > >> Can you put it into your tree for 3.10?
> > >> > >>
> > >> > > I did, so it should be fine.
> > >> > >
> > >> >
> > >> > You may want to discuss how to handle this dependency with the arm-
> soc
> > >> > maintainers (CC'd).
> > >>
> > >> I'm fine with putting the same branch into arm-soc as well as the
> gpio tree
> > >> and anything else that might need it, that tends to be the least
> invasive
> > >> way.
> > >
> > > Just a reminder: that had better be the exact same branch and that
> branch
> > > had better never be rebased/rewritten ...
> >
> > Sorry, which branch are we talking about - is it the one I published
> > for -next initially? If so wouldn't it be simpler to withdraw it and
> > have Grant integrate the patches in his branch? Since no one depends
> > on them for now anyway...
> >
> > I remember rebasing it once some time ago to add Acked-bys, but it
> > hasn't changed since then.
> 
> I am talking about the branch that Arnd says should be merged into both
> the arm-soc and gpio trees.
> 
Well, AFAIK, the problem including "select GENERIC_GPIO" happened only in
samsung tree so arm-soc tree is enough. If any problems, please let me know.

Arnd, just note, the fix is included in my pull-request [09/10].

Thanks.

- Kukjin



From linfeng at cn.fujitsu.com  Mon Apr  8 21:58:55 2013
From: linfeng at cn.fujitsu.com (Lin Feng)
Date: Tue, 09 Apr 2013 09:58:55 +0800
Subject: [PATCH 0/2] mm: vmemmap: add vmemmap_verify check for hot-add
 node/memory case
In-Reply-To: <20130408135553.2f60518d923b6920bdf1931f@linux-foundation.org>
References: <1365415000-10389-1-git-send-email-linfeng@cn.fujitsu.com>
 <CAE9FiQVaByGOTjLVthRkEze_ekXm5LAKgKdHzrD+q1iYmjgZFQ@mail.gmail.com>
 <20130408135553.2f60518d923b6920bdf1931f@linux-foundation.org>
Message-ID: <516375DF.3080602@cn.fujitsu.com>

Hi Andrew,

On 04/09/2013 04:55 AM, Andrew Morton wrote:
> On Mon, 8 Apr 2013 11:40:11 -0700 Yinghai Lu <yinghai at kernel.org> wrote:
> 
>> On Mon, Apr 8, 2013 at 2:56 AM, Lin Feng <linfeng at cn.fujitsu.com> wrote:
>>> In hot add node(memory) case, vmemmap pages are always allocated from other
>>> node,
>>
>> that is broken, and should be fixed.
>> vmemmap should be on local node even for hot add node.
>>
> 
> That would be nice.
> 
> I don't see much value in the added warnings, really.  Because there's
> nothing the user can *do* about them, apart from a) stop using NUMA, b)
> stop using memory hotplug, c) become a kernel MM developer or d) switch
> to Windows.
> 
> 

I agree that we can't do anything helpful to response to such warnings for
the moment, but maybe someone can at least take your c) measure if it's 
what he really cares. ;-)

This patch sent because we found that on a old kernel we get such warnings
but we don't on latest kernel, it appears that it has been fixed by someone
but in fact it is due to sizeof(struct page) is 64bytes aligned now but not
on the old kernel. Now the struct pages for a section is always 2MB in size, 
every time we populate vmemmap for a section we get a new pmd, so the 
vmemmap_verify() check is just ignored. Such phenomenon is misleading.

struct page {
	...
}
#ifdef CONFIG_HAVE_ALIGNED_STRUCT_PAGE
      __aligned(2 * sizeof(unsigned long))
#endif
; 

Anyway the current logic for vmemmap_verify() is broken :(

thanks,
linfeng


From linfeng at cn.fujitsu.com  Mon Apr  8 22:02:27 2013
From: linfeng at cn.fujitsu.com (Lin Feng)
Date: Tue, 09 Apr 2013 10:02:27 +0800
Subject: [PATCH 0/2] mm: vmemmap: add vmemmap_verify check for hot-add
 node/memory case
In-Reply-To: <CAE9FiQVaByGOTjLVthRkEze_ekXm5LAKgKdHzrD+q1iYmjgZFQ@mail.gmail.com>
References: <1365415000-10389-1-git-send-email-linfeng@cn.fujitsu.com>
 <CAE9FiQVaByGOTjLVthRkEze_ekXm5LAKgKdHzrD+q1iYmjgZFQ@mail.gmail.com>
Message-ID: <516376B3.90207@cn.fujitsu.com>

Hi Yinghai,

On 04/09/2013 02:40 AM, Yinghai Lu wrote:
> On Mon, Apr 8, 2013 at 2:56 AM, Lin Feng <linfeng at cn.fujitsu.com> wrote:
>> In hot add node(memory) case, vmemmap pages are always allocated from other
>> node,
> 
> that is broken, and should be fixed.
> vmemmap should be on local node even for hot add node.
> 

Have you ever sent any relative patchset on this, maybe we can run some test
on it ;-)

thanks,
linfeng


From linfeng at cn.fujitsu.com  Mon Apr  8 22:07:11 2013
From: linfeng at cn.fujitsu.com (Lin Feng)
Date: Tue, 09 Apr 2013 10:07:11 +0800
Subject: [PATCH 2/2] mm: vmemmap: arm64: add vmemmap_verify check for
 hot-add node case
In-Reply-To: <20130408105556.GB17476@mudshark.cambridge.arm.com>
References: <1365415000-10389-1-git-send-email-linfeng@cn.fujitsu.com>
 <1365415000-10389-3-git-send-email-linfeng@cn.fujitsu.com>
 <20130408105556.GB17476@mudshark.cambridge.arm.com>
Message-ID: <516377CF.2080004@cn.fujitsu.com>

Hi will,

On 04/08/2013 06:55 PM, Will Deacon wrote:
> Given that we don't have NUMA support or memory-hotplug on arm64 yet, I'm
> not sure that this change makes much sense at the moment. early_pfn_to_nid
> will always return 0 and we only ever have one node.
> 
> To be honest, I'm not sure what that vmemmap_verify check is trying to
> achieve anyway. ia64 does some funky node affinity initialisation early on
> but, for the rest of us, it looks like we always just check the distance
> from node 0.

Sorry for my noise to arm people.

Yes, not everyone cares about vmemmap_verify(), as you described it's not
necessary to arm64 at all. 

thanks,
linfeng


From sboyd at codeaurora.org  Mon Apr  8 22:30:19 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Mon,  8 Apr 2013 19:30:19 -0700
Subject: [PATCH 0/4] Memory mapped architected timers
Message-ID: <1365474623-29181-1-git-send-email-sboyd@codeaurora.org>

This patchset adds support for memory mapped architected timers. We
don't have any other global broadcast timer in our system, so we use the
mmio timer during low power modes. The first patch is the binding.
The next two patches lay some groundwork so that the last patch is simpler.
The final patch adds support for mmio timers.

Patches are based on a recent patch from Mark that removes the
physical count reading (clocksource: arch_timer: use virtual counter,
message id <1364404312-4427-4-git-send-email-mark.rutland at arm.com>).

Stephen Boyd (4):
  Documentation: Add memory mapped ARM architected timer binding
  ARM: arch_timers: Pass clock event to set_mode callback
  clocksource: arch_timer: Push the read/write wrappers deeper
  clocksource: arch_timer: Add support for memory mapped timers

 .../devicetree/bindings/arm/arch_timer.txt         |  62 ++-
 arch/arm/include/asm/arch_timer.h                  |   5 +-
 arch/arm64/include/asm/arch_timer.h                |   4 +-
 drivers/clocksource/arm_arch_timer.c               | 451 +++++++++++++++++----
 include/clocksource/arm_arch_timer.h               |   4 +-
 5 files changed, 448 insertions(+), 78 deletions(-)

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Mon Apr  8 22:30:20 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Mon,  8 Apr 2013 19:30:20 -0700
Subject: [PATCH 1/4] Documentation: Add memory mapped ARM architected timer
 binding
In-Reply-To: <1365474623-29181-1-git-send-email-sboyd@codeaurora.org>
References: <1365474623-29181-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1365474623-29181-2-git-send-email-sboyd@codeaurora.org>

Add a binding for the arm architected timer hardware's memory
mapped interface. The mmio timer hardware is made up of one base
frame and a collection of up to 8 timer frames, where each of the
8 timer frames can have either one or two views. A frame
typically maps to a privilege level (user/kernel, hypervisor,
secure). The first view has full access to the registers within a
frame, while the second view can be restricted to particular
registers within a frame. Each frame must support a physical
timer. It's optional for a frame to support a virtual timer.

Cc: devicetree-discuss at lists.ozlabs.org
Cc: Mark Rutland <mark.rutland at arm.com>
Cc: Marc Zyngier <Marc.Zyngier at arm.com>
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 .../devicetree/bindings/arm/arch_timer.txt         | 62 ++++++++++++++++++++--
 1 file changed, 59 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/arch_timer.txt b/Documentation/devicetree/bindings/arm/arch_timer.txt
index 20746e5..69ef711 100644
--- a/Documentation/devicetree/bindings/arm/arch_timer.txt
+++ b/Documentation/devicetree/bindings/arm/arch_timer.txt
@@ -1,10 +1,14 @@
 * ARM architected timer
 
-ARM cores may have a per-core architected timer, which provides per-cpu timers.
+ARM cores may have a per-core architected timer, which provides per-cpu timers,
+or a memory mapped architected timer, which provides up to 8 frames with a
+physical and optional virtual timer per frame.
 
-The timer is attached to a GIC to deliver its per-processor interrupts.
+The per-core architected timer is attached to a GIC to deliver its
+per-processor interrupts via PPIs. The memory mapped timer is attached to a GIC
+to deliver its interrupts via SPIs.
 
-** Timer node properties:
+** CP15 Timer node properties:
 
 - compatible : Should at least contain one of
 	"arm,armv7-timer"
@@ -26,3 +30,55 @@ Example:
 			     <1 10 0xf08>;
 		clock-frequency = <100000000>;
 	};
+
+** Memory mapped timer node properties
+
+- compatible : Should at least contain "arm,armv7-timer-mem".
+
+- #address-cells : Must be 1.
+
+- #size-cells : Must be 1.
+
+- ranges : Indicates parent and child bus address space are the same.
+
+- clock-frequency : The frequency of the main counter, in Hz. Optional.
+
+- reg : The control frame base address.
+
+Frame:
+
+- frame-id: Encoded as follows:
+		bits[3:0]  frame number: 0 to 7.
+		bits[10:8] frame usage:
+			0 - user/kernel
+			1 - hyp
+			2 - secure
+
+- interrupts : Interrupt list for physical and virtual timers in that order.
+  The virtual timer interrupt is optional.
+
+- reg : The first and second view base addresses in that order. The second view
+  base address is optional.
+
+Example:
+
+	timer at f0000000 {
+		compatible = "arm,armv7-timer-mem";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges;
+		reg = <0xf0000000 0x1000>;
+		clock-frequency = <50000000>;
+		frame0 at f0001000 {
+			frame-id = <0x0>
+			interrupts = <0 13 0x8>,
+				     <0 14 0x8>;
+			reg = <0xf0001000 0x1000>,
+			      <0xf0002000 0x1000>;
+		};
+		frame1 at f0003000 {
+			frame-id = <0x11>
+			interrupts = <0 15 0x8>;
+			reg = <0xf0003000 0x1000>;
+		};
+	};
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Mon Apr  8 22:30:21 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Mon,  8 Apr 2013 19:30:21 -0700
Subject: [PATCH 2/4] ARM: arch_timers: Pass clock event to set_mode callback
In-Reply-To: <1365474623-29181-1-git-send-email-sboyd@codeaurora.org>
References: <1365474623-29181-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1365474623-29181-3-git-send-email-sboyd@codeaurora.org>

There isn't any reason why we don't pass the event here and we'll
need it in the near future for memory mapped arch timers anyway.

Cc: Mark Rutland <mark.rutland at arm.com>
Cc: Marc Zyngier <Marc.Zyngier at arm.com>
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 drivers/clocksource/arm_arch_timer.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
index 2abb861..545891b 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -140,7 +140,7 @@ static int __cpuinit arch_timer_setup(struct clock_event_device *clk)
 
 	clk->cpumask = cpumask_of(smp_processor_id());
 
-	clk->set_mode(CLOCK_EVT_MODE_SHUTDOWN, NULL);
+	clk->set_mode(CLOCK_EVT_MODE_SHUTDOWN, clk);
 
 	clockevents_config_and_register(clk, arch_timer_rate,
 					0xf, 0x7fffffff);
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Mon Apr  8 22:30:22 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Mon,  8 Apr 2013 19:30:22 -0700
Subject: [PATCH 3/4] clocksource: arch_timer: Push the read/write wrappers
 deeper
In-Reply-To: <1365474623-29181-1-git-send-email-sboyd@codeaurora.org>
References: <1365474623-29181-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1365474623-29181-4-git-send-email-sboyd@codeaurora.org>

We're going to introduce support to read and write the memory
mapped timer registers in the next patch, so push the cp15
read/write functions one level deeper. This simplifies the next
patch and makes it clearer what's going on.

Cc: Mark Rutland <mark.rutland at arm.com>
Cc: Marc Zyngier <Marc.Zyngier at arm.com>
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 arch/arm/include/asm/arch_timer.h    |  5 ++--
 arch/arm64/include/asm/arch_timer.h  |  4 ++--
 drivers/clocksource/arm_arch_timer.c | 44 ++++++++++++++++++++++++------------
 3 files changed, 34 insertions(+), 19 deletions(-)

diff --git a/arch/arm/include/asm/arch_timer.h b/arch/arm/include/asm/arch_timer.h
index 35fea17..560f8a0 100644
--- a/arch/arm/include/asm/arch_timer.h
+++ b/arch/arm/include/asm/arch_timer.h
@@ -18,7 +18,8 @@ int arch_timer_sched_clock_init(void);
  * nicely work out which register we want, and chuck away the rest of
  * the code. At least it does so with a recent GCC (4.6.3).
  */
-static inline void arch_timer_reg_write(const int access, const int reg, u32 val)
+static inline void __arch_timer_reg_write(const int access, const int reg,
+					  u32 val)
 {
 	if (access == ARCH_TIMER_PHYS_ACCESS) {
 		switch (reg) {
@@ -45,7 +46,7 @@ static inline void arch_timer_reg_write(const int access, const int reg, u32 val
 	isb();
 }
 
-static inline u32 arch_timer_reg_read(const int access, const int reg)
+static inline u32 __arch_timer_reg_read(const int access, const int reg)
 {
 	u32 val = 0;
 
diff --git a/arch/arm64/include/asm/arch_timer.h b/arch/arm64/include/asm/arch_timer.h
index 5307737..78b0379 100644
--- a/arch/arm64/include/asm/arch_timer.h
+++ b/arch/arm64/include/asm/arch_timer.h
@@ -26,7 +26,7 @@
 
 #include <clocksource/arm_arch_timer.h>
 
-static inline void arch_timer_reg_write(int access, int reg, u32 val)
+static inline void __arch_timer_reg_write(int access, int reg, u32 val)
 {
 	if (access == ARCH_TIMER_PHYS_ACCESS) {
 		switch (reg) {
@@ -57,7 +57,7 @@ static inline void arch_timer_reg_write(int access, int reg, u32 val)
 	isb();
 }
 
-static inline u32 arch_timer_reg_read(int access, int reg)
+static inline u32 __arch_timer_reg_read(int access, int reg)
 {
 	u32 val;
 
diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
index 545891b..38e0efc 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -43,14 +43,26 @@ static bool arch_timer_use_virtual = true;
  * Architected system timer support.
  */
 
+static inline void arch_timer_reg_write(int access, int reg, u32 val,
+					struct clock_event_device *clk)
+{
+	__arch_timer_reg_write(access, reg, val);
+}
+
+static inline u32 arch_timer_reg_read(int access, int reg,
+				      struct clock_event_device *clk)
+{
+	return __arch_timer_reg_read(access, reg);
+}
+
 static inline irqreturn_t timer_handler(const int access,
 					struct clock_event_device *evt)
 {
 	unsigned long ctrl;
-	ctrl = arch_timer_reg_read(access, ARCH_TIMER_REG_CTRL);
+	ctrl = arch_timer_reg_read(access, ARCH_TIMER_REG_CTRL, evt);
 	if (ctrl & ARCH_TIMER_CTRL_IT_STAT) {
 		ctrl |= ARCH_TIMER_CTRL_IT_MASK;
-		arch_timer_reg_write(access, ARCH_TIMER_REG_CTRL, ctrl);
+		arch_timer_reg_write(access, ARCH_TIMER_REG_CTRL, ctrl, evt);
 		evt->event_handler(evt);
 		return IRQ_HANDLED;
 	}
@@ -72,15 +84,16 @@ static irqreturn_t arch_timer_handler_phys(int irq, void *dev_id)
 	return timer_handler(ARCH_TIMER_PHYS_ACCESS, evt);
 }
 
-static inline void timer_set_mode(const int access, int mode)
+static inline void timer_set_mode(const int access, int mode,
+				  struct clock_event_device *clk)
 {
 	unsigned long ctrl;
 	switch (mode) {
 	case CLOCK_EVT_MODE_UNUSED:
 	case CLOCK_EVT_MODE_SHUTDOWN:
-		ctrl = arch_timer_reg_read(access, ARCH_TIMER_REG_CTRL);
+		ctrl = arch_timer_reg_read(access, ARCH_TIMER_REG_CTRL, clk);
 		ctrl &= ~ARCH_TIMER_CTRL_ENABLE;
-		arch_timer_reg_write(access, ARCH_TIMER_REG_CTRL, ctrl);
+		arch_timer_reg_write(access, ARCH_TIMER_REG_CTRL, ctrl, clk);
 		break;
 	default:
 		break;
@@ -90,36 +103,37 @@ static inline void timer_set_mode(const int access, int mode)
 static void arch_timer_set_mode_virt(enum clock_event_mode mode,
 				     struct clock_event_device *clk)
 {
-	timer_set_mode(ARCH_TIMER_VIRT_ACCESS, mode);
+	timer_set_mode(ARCH_TIMER_VIRT_ACCESS, mode, clk);
 }
 
 static void arch_timer_set_mode_phys(enum clock_event_mode mode,
 				     struct clock_event_device *clk)
 {
-	timer_set_mode(ARCH_TIMER_PHYS_ACCESS, mode);
+	timer_set_mode(ARCH_TIMER_PHYS_ACCESS, mode, clk);
 }
 
-static inline void set_next_event(const int access, unsigned long evt)
+static inline void set_next_event(const int access, unsigned long evt,
+				  struct clock_event_device *clk)
 {
 	unsigned long ctrl;
-	ctrl = arch_timer_reg_read(access, ARCH_TIMER_REG_CTRL);
+	ctrl = arch_timer_reg_read(access, ARCH_TIMER_REG_CTRL, clk);
 	ctrl |= ARCH_TIMER_CTRL_ENABLE;
 	ctrl &= ~ARCH_TIMER_CTRL_IT_MASK;
-	arch_timer_reg_write(access, ARCH_TIMER_REG_TVAL, evt);
-	arch_timer_reg_write(access, ARCH_TIMER_REG_CTRL, ctrl);
+	arch_timer_reg_write(access, ARCH_TIMER_REG_TVAL, evt, clk);
+	arch_timer_reg_write(access, ARCH_TIMER_REG_CTRL, ctrl, clk);
 }
 
 static int arch_timer_set_next_event_virt(unsigned long evt,
-					  struct clock_event_device *unused)
+					  struct clock_event_device *clk)
 {
-	set_next_event(ARCH_TIMER_VIRT_ACCESS, evt);
+	set_next_event(ARCH_TIMER_VIRT_ACCESS, evt, clk);
 	return 0;
 }
 
 static int arch_timer_set_next_event_phys(unsigned long evt,
-					  struct clock_event_device *unused)
+					  struct clock_event_device *clk)
 {
-	set_next_event(ARCH_TIMER_PHYS_ACCESS, evt);
+	set_next_event(ARCH_TIMER_PHYS_ACCESS, evt, clk);
 	return 0;
 }
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Mon Apr  8 22:30:23 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Mon,  8 Apr 2013 19:30:23 -0700
Subject: [PATCH 4/4] clocksource: arch_timer: Add support for memory mapped
 timers
In-Reply-To: <1365474623-29181-1-git-send-email-sboyd@codeaurora.org>
References: <1365474623-29181-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1365474623-29181-5-git-send-email-sboyd@codeaurora.org>

Add support for the memory mapped timers by filling in the
read/write functions and adding some parsing code. Note that we
only register one clocksource, preferring the cp15 based
clocksource over the mmio one.

To keep things simple we register one global clockevent. This
covers the case of UP and SMP systems with only mmio hardware and
systems where the memory mapped timers are used as the broadcast
timer in low power modes. The DT binding allows for per-CPU
memory mapped timers in case we want to support that in the
future, but the code isn't added here.

We also punt on hypervisor support, although it should be
possible to support it by searching for the hyp frame instead of
the kernel frame and updating KVM timers to support it.

Cc: Mark Rutland <mark.rutland at arm.com>
Cc: Marc Zyngier <Marc.Zyngier at arm.com>
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 drivers/clocksource/arm_arch_timer.c | 411 ++++++++++++++++++++++++++++++-----
 include/clocksource/arm_arch_timer.h |   4 +-
 2 files changed, 357 insertions(+), 58 deletions(-)

diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
index 38e0efc..6158422 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -16,13 +16,43 @@
 #include <linux/clockchips.h>
 #include <linux/interrupt.h>
 #include <linux/of_irq.h>
+#include <linux/of_address.h>
 #include <linux/io.h>
+#include <linux/slab.h>
 
 #include <asm/arch_timer.h>
 #include <asm/virt.h>
 
 #include <clocksource/arm_arch_timer.h>
 
+#define FRAME_NUM_MASK		0x7
+#define FRAME_TYPE_MASK		(0x3 << 8)
+#define FRAME_TYPE_KERNEL_USER	(0 << 8)
+
+#define CNTTIDR		0x08
+#define CNTTIDR_VIRT(n)	(BIT(1) << ((n) * 4))
+
+#define CNTVCT_LO	0x08
+#define CNTVCT_HI	0x0c
+#define CNTFRQ		0x10
+#define CNTP_TVAL	0x28
+#define CNTP_CTL	0x2c
+#define CNTV_TVAL	0x38
+#define CNTV_CTL	0x3c
+
+#define ARCH_CP15_TIMER	BIT(0)
+#define ARCH_MEM_TIMER	BIT(1)
+static unsigned arch_timers_present;
+
+static void __iomem *arch_counter_base;
+
+struct arch_timer {
+	void __iomem *base;
+	struct clock_event_device evt;
+};
+
+#define to_arch_timer(e) container_of(e, struct arch_timer, evt)
+
 static u32 arch_timer_rate;
 
 enum ppi_nr {
@@ -38,6 +68,7 @@ static int arch_timer_ppi[MAX_TIMER_PPI];
 static struct clock_event_device __percpu *arch_timer_evt;
 
 static bool arch_timer_use_virtual = true;
+static bool arch_timer_mem_use_virtual = true;
 
 /*
  * Architected system timer support.
@@ -46,13 +77,69 @@ static bool arch_timer_use_virtual = true;
 static inline void arch_timer_reg_write(int access, int reg, u32 val,
 					struct clock_event_device *clk)
 {
-	__arch_timer_reg_write(access, reg, val);
+	if (access == ARCH_TIMER_MEM_PHYS_ACCESS) {
+		struct arch_timer *timer = to_arch_timer(clk);
+		switch (reg) {
+		case ARCH_TIMER_REG_CTRL:
+			writel_relaxed(val, timer->base + CNTP_CTL);
+			break;
+		case ARCH_TIMER_REG_TVAL:
+			writel_relaxed(val, timer->base + CNTP_TVAL);
+			break;
+		default:
+			BUILD_BUG();
+		}
+	} else if (access == ARCH_TIMER_MEM_VIRT_ACCESS) {
+		struct arch_timer *timer = to_arch_timer(clk);
+		switch (reg) {
+		case ARCH_TIMER_REG_CTRL:
+			writel_relaxed(val, timer->base + CNTV_CTL);
+			break;
+		case ARCH_TIMER_REG_TVAL:
+			writel_relaxed(val, timer->base + CNTV_TVAL);
+			break;
+		default:
+			BUILD_BUG();
+		}
+	} else {
+		__arch_timer_reg_write(access, reg, val);
+	}
 }
 
 static inline u32 arch_timer_reg_read(int access, int reg,
 				      struct clock_event_device *clk)
 {
-	return __arch_timer_reg_read(access, reg);
+	u32 val;
+
+	if (access == ARCH_TIMER_MEM_PHYS_ACCESS) {
+		struct arch_timer *timer = to_arch_timer(clk);
+		switch (reg) {
+		case ARCH_TIMER_REG_CTRL:
+			val = readl_relaxed(timer->base + CNTP_CTL);
+			break;
+		case ARCH_TIMER_REG_TVAL:
+			val = readl_relaxed(timer->base + CNTP_TVAL);
+			break;
+		default:
+			BUILD_BUG();
+		}
+	} else if (access == ARCH_TIMER_MEM_VIRT_ACCESS) {
+		struct arch_timer *timer = to_arch_timer(clk);
+		switch (reg) {
+		case ARCH_TIMER_REG_CTRL:
+			val = readl_relaxed(timer->base + CNTV_CTL);
+			break;
+		case ARCH_TIMER_REG_TVAL:
+			val = readl_relaxed(timer->base + CNTV_TVAL);
+			break;
+		default:
+			BUILD_BUG();
+		}
+	} else {
+		val = __arch_timer_reg_read(access, reg);
+	}
+
+	return val;
 }
 
 static inline irqreturn_t timer_handler(const int access,
@@ -84,6 +171,20 @@ static irqreturn_t arch_timer_handler_phys(int irq, void *dev_id)
 	return timer_handler(ARCH_TIMER_PHYS_ACCESS, evt);
 }
 
+static irqreturn_t arch_timer_handler_phys_mem(int irq, void *dev_id)
+{
+	struct clock_event_device *evt = dev_id;
+
+	return timer_handler(ARCH_TIMER_MEM_PHYS_ACCESS, evt);
+}
+
+static irqreturn_t arch_timer_handler_virt_mem(int irq, void *dev_id)
+{
+	struct clock_event_device *evt = dev_id;
+
+	return timer_handler(ARCH_TIMER_MEM_VIRT_ACCESS, evt);
+}
+
 static inline void timer_set_mode(const int access, int mode,
 				  struct clock_event_device *clk)
 {
@@ -112,6 +213,18 @@ static void arch_timer_set_mode_phys(enum clock_event_mode mode,
 	timer_set_mode(ARCH_TIMER_PHYS_ACCESS, mode, clk);
 }
 
+static void arch_timer_set_mode_virt_mem(enum clock_event_mode mode,
+					 struct clock_event_device *clk)
+{
+	timer_set_mode(ARCH_TIMER_MEM_VIRT_ACCESS, mode, clk);
+}
+
+static void arch_timer_set_mode_phys_mem(enum clock_event_mode mode,
+					 struct clock_event_device *clk)
+{
+	timer_set_mode(ARCH_TIMER_MEM_PHYS_ACCESS, mode, clk);
+}
+
 static inline void set_next_event(const int access, unsigned long evt,
 				  struct clock_event_device *clk)
 {
@@ -137,27 +250,62 @@ static int arch_timer_set_next_event_phys(unsigned long evt,
 	return 0;
 }
 
-static int __cpuinit arch_timer_setup(struct clock_event_device *clk)
+static int arch_timer_set_next_event_virt_mem(unsigned long evt,
+					      struct clock_event_device *clk)
 {
-	clk->features = CLOCK_EVT_FEAT_ONESHOT | CLOCK_EVT_FEAT_C3STOP;
-	clk->name = "arch_sys_timer";
-	clk->rating = 450;
-	if (arch_timer_use_virtual) {
-		clk->irq = arch_timer_ppi[VIRT_PPI];
-		clk->set_mode = arch_timer_set_mode_virt;
-		clk->set_next_event = arch_timer_set_next_event_virt;
+	set_next_event(ARCH_TIMER_MEM_VIRT_ACCESS, evt, clk);
+	return 0;
+}
+
+static int arch_timer_set_next_event_phys_mem(unsigned long evt,
+					      struct clock_event_device *clk)
+{
+	set_next_event(ARCH_TIMER_MEM_PHYS_ACCESS, evt, clk);
+	return 0;
+}
+
+static void __cpuinit __arch_timer_setup(unsigned type,
+				       struct clock_event_device *clk)
+{
+	clk->features = CLOCK_EVT_FEAT_ONESHOT;
+
+	if (type == ARCH_CP15_TIMER) {
+		clk->features |= CLOCK_EVT_FEAT_C3STOP;
+		clk->name = "arch_sys_timer";
+		clk->rating = 450;
+		clk->cpumask = cpumask_of(smp_processor_id());
+		if (arch_timer_use_virtual) {
+			clk->irq = arch_timer_ppi[VIRT_PPI];
+			clk->set_mode = arch_timer_set_mode_virt;
+			clk->set_next_event = arch_timer_set_next_event_virt;
+		} else {
+			clk->irq = arch_timer_ppi[PHYS_SECURE_PPI];
+			clk->set_mode = arch_timer_set_mode_phys;
+			clk->set_next_event = arch_timer_set_next_event_phys;
+		}
 	} else {
-		clk->irq = arch_timer_ppi[PHYS_SECURE_PPI];
-		clk->set_mode = arch_timer_set_mode_phys;
-		clk->set_next_event = arch_timer_set_next_event_phys;
+		clk->name = "arch_mem_timer";
+		clk->rating = 400;
+		clk->cpumask = cpu_all_mask;
+		if (arch_timer_mem_use_virtual) {
+			clk->set_mode = arch_timer_set_mode_virt_mem;
+			clk->set_next_event =
+				arch_timer_set_next_event_virt_mem;
+		} else {
+			clk->set_mode = arch_timer_set_mode_phys_mem;
+			clk->set_next_event =
+				arch_timer_set_next_event_phys_mem;
+		}
 	}
 
-	clk->cpumask = cpumask_of(smp_processor_id());
-
 	clk->set_mode(CLOCK_EVT_MODE_SHUTDOWN, clk);
 
-	clockevents_config_and_register(clk, arch_timer_rate,
-					0xf, 0x7fffffff);
+	clockevents_config_and_register(clk, arch_timer_rate, 0xf, 0x7fffffff);
+}
+
+static int __cpuinit arch_timer_setup(struct clock_event_device *clk)
+{
+	__arch_timer_setup(ARCH_CP15_TIMER, clk);
 
 	if (arch_timer_use_virtual)
 		enable_percpu_irq(arch_timer_ppi[VIRT_PPI], 0);
@@ -172,27 +320,41 @@ static int __cpuinit arch_timer_setup(struct clock_event_device *clk)
 	return 0;
 }
 
-static int arch_timer_available(void)
+static void
+arch_timer_detect_rate(void __iomem *cntbase, struct device_node *np)
 {
-	u32 freq;
-
-	if (arch_timer_rate == 0) {
-		freq = arch_timer_get_cntfrq();
-
-		/* Check the timer frequency. */
-		if (freq == 0) {
-			pr_warn("Architected timer frequency not available\n");
-			return -EINVAL;
-		}
+	/* Who has more than one independent system counters? */
+	if (arch_timer_rate)
+		return;
 
-		arch_timer_rate = freq;
+	/* Try to determine the frequency from the device tree or CNTFRQ */
+	if (of_property_read_u32(np, "clock-frequency", &arch_timer_rate)) {
+		if (cntbase)
+			arch_timer_rate = readl_relaxed(cntbase + CNTFRQ);
+		else
+			arch_timer_rate = arch_timer_get_cntfrq();
 	}
 
-	pr_info_once("Architected local timer running at %lu.%02luMHz (%s).\n",
+	/* Check the timer frequency. */
+	if (arch_timer_rate == 0)
+		pr_warn("Architected timer frequency not available\n");
+}
+
+static void arch_timer_banner(unsigned type)
+{
+	pr_info("Architected %s%s%s timer(s) running at %lu.%02luMHz (%s%s%s).\n",
+		     type & ARCH_CP15_TIMER ? "cp15" : "",
+		     type == (ARCH_CP15_TIMER | ARCH_MEM_TIMER) ?  " and " : "",
+		     type & ARCH_MEM_TIMER ? "mmio" : "",
 		     (unsigned long)arch_timer_rate / 1000000,
 		     (unsigned long)(arch_timer_rate / 10000) % 100,
-		     arch_timer_use_virtual ? "virt" : "phys");
-	return 0;
+		     type & ARCH_CP15_TIMER ?
+			arch_timer_use_virtual ? "virt" : "phys" :
+			"",
+		     type == (ARCH_CP15_TIMER | ARCH_MEM_TIMER) ?  "/" : "",
+		     type & ARCH_MEM_TIMER ?
+			arch_timer_mem_use_virtual ? "virt" : "phys" :
+			"");
 }
 
 u32 arch_timer_get_rate(void)
@@ -200,19 +362,29 @@ u32 arch_timer_get_rate(void)
 	return arch_timer_rate;
 }
 
-u64 arch_timer_read_counter(void)
+static u64 arch_counter_get_mem_cntvct(void)
 {
-	return arch_counter_get_cntvct();
+	u32 vct_lo, vct_hi, tmp_hi;
+
+	do {
+		vct_hi = readl_relaxed(arch_counter_base + CNTVCT_HI);
+		vct_lo = readl_relaxed(arch_counter_base + CNTVCT_LO);
+		tmp_hi = readl_relaxed(arch_counter_base + CNTVCT_HI);
+	} while (vct_hi != tmp_hi);
+
+	return ((u64) vct_hi << 32) | vct_lo;
 }
 
+u64 (*arch_timer_read_counter)(void);
+
 static cycle_t arch_counter_read(struct clocksource *cs)
 {
-	return arch_counter_get_cntvct();
+	return arch_timer_read_counter();
 }
 
 static cycle_t arch_counter_read_cc(const struct cyclecounter *cc)
 {
-	return arch_counter_get_cntvct();
+	return arch_timer_read_counter();
 }
 
 static struct clocksource clocksource_counter = {
@@ -235,6 +407,23 @@ struct timecounter *arch_timer_get_timecounter(void)
 	return &timecounter;
 }
 
+static void __init arch_counter_register(unsigned type)
+{
+	u64 start_count;
+
+	/* Register the CP15 based counter if we have one */
+	if (type & ARCH_CP15_TIMER)
+		arch_timer_read_counter = arch_counter_get_cntvct;
+	else
+		arch_timer_read_counter = arch_counter_get_mem_cntvct;
+
+	start_count = arch_timer_read_counter();
+	clocksource_register_hz(&clocksource_counter, arch_timer_rate);
+	cyclecounter.mult = clocksource_counter.mult;
+	cyclecounter.shift = clocksource_counter.shift;
+	timecounter_init(&timecounter, &cyclecounter, start_count);
+}
+
 static void __cpuinit arch_timer_stop(struct clock_event_device *clk)
 {
 	pr_debug("arch_timer_teardown disable IRQ%d cpu #%d\n",
@@ -277,22 +466,12 @@ static int __init arch_timer_register(void)
 	int err;
 	int ppi;
 
-	err = arch_timer_available();
-	if (err)
-		goto out;
-
 	arch_timer_evt = alloc_percpu(struct clock_event_device);
 	if (!arch_timer_evt) {
 		err = -ENOMEM;
 		goto out;
 	}
 
-	clocksource_register_hz(&clocksource_counter, arch_timer_rate);
-	cyclecounter.mult = clocksource_counter.mult;
-	cyclecounter.shift = clocksource_counter.shift;
-	timecounter_init(&timecounter, &cyclecounter,
-			 arch_counter_get_cntvct());
-
 	if (arch_timer_use_virtual) {
 		ppi = arch_timer_ppi[VIRT_PPI];
 		err = request_percpu_irq(ppi, arch_timer_handler_virt,
@@ -343,31 +522,50 @@ out:
 	return err;
 }
 
+static int __init arch_timer_mem_register(void __iomem *base, unsigned irq)
+{
+	int ret;
+	irq_handler_t func;
+	struct arch_timer *t;
+
+	t = kzalloc(sizeof(*t), GFP_KERNEL);
+	if (!t)
+		return -ENOMEM;
+
+	t->base = base;
+	t->evt.irq = irq;
+	__arch_timer_setup(ARCH_MEM_TIMER, &t->evt);
+
+	if (arch_timer_mem_use_virtual)
+		func = arch_timer_handler_virt_mem;
+	else
+		func = arch_timer_handler_phys_mem;
+
+	ret = request_irq(irq, func, IRQF_TIMER, "arch_mem_timer", &t->evt);
+	if (ret)
+		kfree(t);
+	return ret;
+}
+
 static const struct of_device_id arch_timer_of_match[] __initconst = {
 	{ .compatible	= "arm,armv7-timer",	},
 	{ .compatible	= "arm,armv8-timer",	},
 	{},
 };
 
-int __init arch_timer_init(void)
+static int __init arch_timer_parse(void)
 {
 	struct device_node *np;
-	u32 freq;
 	int i;
 
 	np = of_find_matching_node(NULL, arch_timer_of_match);
-	if (!np) {
-		pr_err("arch_timer: can't find DT node\n");
-		return -ENODEV;
-	}
-
-	/* Try to determine the frequency from the device tree or CNTFRQ */
-	if (!of_property_read_u32(np, "clock-frequency", &freq))
-		arch_timer_rate = freq;
+	if (!np)
+		return 0;
 
+	arch_timers_present |= ARCH_CP15_TIMER;
 	for (i = PHYS_SECURE_PPI; i < MAX_TIMER_PPI; i++)
 		arch_timer_ppi[i] = irq_of_parse_and_map(np, i);
-
+	arch_timer_detect_rate(NULL, np);
 	of_node_put(np);
 
 	/*
@@ -390,3 +588,102 @@ int __init arch_timer_init(void)
 
 	return arch_timer_register();
 }
+
+static const struct of_device_id arch_timer_mem_of_match[] __initconst = {
+	{ .compatible	= "arm,armv7-timer-mem", },
+	{},
+};
+
+static int __init arch_timer_mem_parse(void)
+{
+	struct device_node *np, *frame, *best_frame = NULL;
+	void __iomem *cntctlbase, *base;
+	unsigned irq;
+	u32 cnttidr;
+
+	np = of_find_matching_node(NULL, arch_timer_mem_of_match);
+	if (!np)
+		return 0;
+
+	arch_timers_present |= ARCH_MEM_TIMER;
+	cntctlbase = of_iomap(np, 0);
+	if (!cntctlbase) {
+		pr_err("arch_timer: Can't find CNTCTLBase\n");
+		of_node_put(np);
+		return -ENOMEM;
+	}
+
+	cnttidr = readl_relaxed(cntctlbase + CNTTIDR);
+	/*
+	 * Try to find a virtual capable kernel/user frame. Otherwise fall back
+	 * to a physical kernel/user frame.
+	 */
+	for_each_child_of_node(np, frame) {
+		u32 id;
+		int n;
+
+		if (of_property_read_u32(frame, "frame-id", &id)) {
+			pr_warn("arch_timer: Missing frame-id\n");
+			of_node_put(frame);
+			of_node_put(np);
+			return -EINVAL;
+		}
+
+		n = id & FRAME_NUM_MASK;
+		if ((id & FRAME_TYPE_MASK) == FRAME_TYPE_KERNEL_USER) {
+			if (cnttidr & CNTTIDR_VIRT(n)) {
+				of_node_put(best_frame);
+				best_frame = frame;
+				break;
+			}
+			of_node_put(best_frame);
+			best_frame = of_node_get(frame);
+		}
+	}
+	of_node_put(np);
+
+	base = arch_counter_base = of_iomap(best_frame, 0);
+	if (!base) {
+		pr_warn("arch_timer: Can't map frame's registers\n");
+		of_node_put(best_frame);
+		return -ENOMEM;
+	}
+
+	irq = irq_of_parse_and_map(best_frame, 1);
+	if (!irq) {
+		arch_timer_mem_use_virtual = false;
+		irq = irq_of_parse_and_map(best_frame, 0);
+	}
+	if (!irq) {
+		pr_warn("arch_timer: Missing timer irq\n");
+		of_node_put(best_frame);
+		return -EINVAL;
+	}
+
+	arch_timer_detect_rate(base, best_frame);
+	of_node_put(best_frame);
+
+	return arch_timer_mem_register(base, irq);
+}
+
+int __init arch_timer_init(void)
+{
+	int err;
+
+	err = arch_timer_parse();
+	if (err)
+		return err;
+
+	err = arch_timer_mem_parse();
+	if (err)
+		return err;
+
+	if (!(arch_timers_present & (ARCH_CP15_TIMER | ARCH_MEM_TIMER))) {
+		pr_err("arch_timer: can't find DT node\n");
+		return -ENODEV;
+	}
+
+	arch_timer_banner(arch_timers_present);
+	arch_counter_register(arch_timers_present);
+	return 0;
+}
diff --git a/include/clocksource/arm_arch_timer.h b/include/clocksource/arm_arch_timer.h
index 3883812..c3ff7fe 100644
--- a/include/clocksource/arm_arch_timer.h
+++ b/include/clocksource/arm_arch_timer.h
@@ -28,12 +28,14 @@
 
 #define ARCH_TIMER_PHYS_ACCESS		0
 #define ARCH_TIMER_VIRT_ACCESS		1
+#define ARCH_TIMER_MEM_PHYS_ACCESS	2
+#define ARCH_TIMER_MEM_VIRT_ACCESS	3
 
 #ifdef CONFIG_ARM_ARCH_TIMER
 
 extern int arch_timer_init(void);
 extern u32 arch_timer_get_rate(void);
-extern u64 arch_timer_read_counter(void);
+extern u64 (*arch_timer_read_counter)(void);
 extern struct timecounter *arch_timer_get_timecounter(void);
 
 #else
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From robherring2 at gmail.com  Mon Apr  8 22:45:43 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Mon, 08 Apr 2013 21:45:43 -0500
Subject: [PATCH 1/1] of/irq: store IRQ trigger/level in struct resource
 flags
In-Reply-To: <51634B1F.4030408@collabora.co.uk>
References: <1365148088-11175-1-git-send-email-javier.martinez@collabora.co.uk>
 <51633F26.7000400@gmail.com> <516341AF.7030207@wwwdotorg.org>
 <51634B1F.4030408@collabora.co.uk>
Message-ID: <516380D7.3060000@gmail.com>

On 04/08/2013 05:56 PM, Javier Martinez Canillas wrote:
> On 04/09/2013 12:16 AM, Stephen Warren wrote:
>> On 04/08/2013 04:05 PM, Rob Herring wrote:
>>> On 04/05/2013 02:48 AM, Javier Martinez Canillas wrote:
>>>> According to Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
>>>> the "#interrupt-cells" property of an "interrupt-controller" is used
>>>> to define the number of cells needed to specify a single interrupt.
>> ...
>>>> But the type is never returned so it can't be saved on the IRQ struct
>>>> resource flags member.
>>>>
>>>> This means that drivers that need the IRQ type/level flags defined in
>>>> the DT won't be able to get it.
>>>
>>> But the interrupt controllers that need the information should be able
>>> to get to it via irqd_get_trigger_type. What problem exactly are you
>>> trying to fix? What driver would use this?
>>
>> FYI, that is indeed what I did in sound/soc/codecs/wm8903.c. Thinking
>> back, I'm not sure if that was the right thing or whether I should have
>> sent this same patch:-)
>>
> 
> Hi Stephen,
> 
> I'm glad you agree :-)
> 
> I could change drivers/net/ethernet/smsc/smsc911x.c to get the type flags for
> the IRQ with irqd_get_trigger_type() but I prefer $subject because:

irqd_get_trigger_type probably is not meant for outside of irqchips.
Creating an irq_get_irq_type function which takes an irq number would be
the right function as that does not expose struct irq_data.

> a) This works in the non-DT case with board files and filling the resources from
> platform data in arch/arm/mach-omap2/gpmc-smsc911x.c. So this is definitely a
> bug on the DT core.

And hackery/abuse like this:

arch/arm/mach-omap2/board-3630sdp.c:32:    .flags          =
GPMC_MUX_ADD_DATA | IORESOURCE_IRQ_LOWLEVEL,

> b) I don't see why of_irq_to_resource() should discard the type/level flags when
> filling the IORESOURCE_IRQ if it was specified on the DT.
> 
> c) We will have to change all drivers that expect to get the IRQ type flags from
> a IORESOURCE_IRQ struct resource.

I'm not convinced that is a high number of drivers. Nearly all the
occurrences of IORESOURCE_IRQ_ in drivers/ are for ISA (acpi/pnp) and
drivers for ISA devices.

Rob


From swarren at wwwdotorg.org  Mon Apr  8 23:16:00 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Mon, 08 Apr 2013 21:16:00 -0600
Subject: [PATCH V2] video: implement a simple framebuffer driver
In-Reply-To: <20130408171637.98b5ad1f867bcbda883af68b@linux-foundation.org>
References: <1365043183-28905-1-git-send-email-swarren@wwwdotorg.org>
 <20130408171637.98b5ad1f867bcbda883af68b@linux-foundation.org>
Message-ID: <516387F0.7080602@wwwdotorg.org>

On 04/08/2013 06:16 PM, Andrew Morton wrote:
> On Wed,  3 Apr 2013 20:39:43 -0600 Stephen Warren <swarren at wwwdotorg.org> wrote:
> 
>> A simple frame-buffer describes a raw memory region that may be rendered
>> to, with the assumption that the display hardware has already been set
>> up to scan out from that buffer.
>>
>> This is useful in cases where a bootloader exists and has set up the
>> display hardware, but a Linux driver doesn't yet exist for the display
>> hardware.
>>
>> ...
>>
>> +config FB_SIMPLE
>> +	bool "Simple framebuffer support"
>> +	depends on (FB = y) && OF
> 
> It's sad that this simple little thing requires Open Firmware.  Could
> it be generalised in some way so that the small amount of setup info
> could be provided by other means (eg, module_param) or does the
> dependency go deeper than that?

I wouldn't be at all surprised if others want to feed it platform data
rather than parameterizing it through device tree. All my platforms use
DT though, so I didn't want to add that support without any user; it'd
just be dead code for now. But, if someone wants that, I can certainly
code it up or test/review after the change etc.


From mturquette at linaro.org  Mon Apr  8 23:42:36 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Mon, 08 Apr 2013 20:42:36 -0700
Subject: [PATCH v2] clk: add LP8788 clock driver
In-Reply-To: <A874F61F95741C4A9BA573A70FE3998F82E4AB29@DQHE02.ent.ti.com>
References: <A874F61F95741C4A9BA573A70FE3998F82E4AB29@DQHE02.ent.ti.com>
Message-ID: <20130409034236.14359.17841@quantum>

Quoting Kim, Milo (2013-04-03 18:34:37)
> Patch v2.
>   (a) Remove unnecessary 'is_enabled()' operation code.
>   (b) Add CLK_IGNORE_UNUSED flag.
>   (c) Add clock device detection code : lp8788_is_clk_device_ready()
>       If the device is not ready, return as -ENODEV on loading the driver.
> 
> Patch v1.
>   Initial patch
> 

It's better to put the above changelog stuff below in the scratchpad
area ...

> Signed-off-by: Milo(Woogyom) Kim <milo.kim at ti.com>
> ---

... here.

>  drivers/clk/Kconfig        |    7 ++
>  drivers/clk/Makefile       |    1 +
>  drivers/clk/clk-lp8788.c   |  160 ++++++++++++++++++++++++++++++++++++++++++++
>  drivers/mfd/lp8788.c       |    2 +
>  include/linux/mfd/lp8788.h |    1 +
>  5 files changed, 171 insertions(+)
>  create mode 100644 drivers/clk/clk-lp8788.c
> 
> +static int lp8788_clk_probe(struct platform_device *pdev)
> +{
> +       struct lp8788 *lp = dev_get_drvdata(pdev->dev.parent);
> +       struct lp8788_clk *pclk;
> +
> +       pclk = devm_kzalloc(&pdev->dev, sizeof(struct lp8788_clk), GFP_KERNEL);
> +       if (!pclk)
> +               return -ENOMEM;
> +
> +       pclk->lp = lp;
> +       platform_set_drvdata(pdev, pclk);
> +
> +       if (!lp8788_is_clk_device_ready(pclk))
> +               return -ENODEV;

Would EPROBE_DEFER be better?

> +
> +       return lp8788_clk_register(&pdev->dev, pclk);
> +}
> +
> +static int lp8788_clk_remove(struct platform_device *pdev)
> +{
> +       struct lp8788_clk *pclk = platform_get_drvdata(pdev);
> +
> +       lp8788_clk_unregister(pclk);
> +       return 0;
> +}
> +
> +static struct platform_driver lp8788_clk_driver = {
> +       .probe = lp8788_clk_probe,
> +       .remove = lp8788_clk_remove,
> +       .driver         = {
> +               .name   = LP8788_DEV_CLK,
> +               .owner  = THIS_MODULE,
> +       },
> +};
> +
> +static int __init lp8788_clk_init(void)
> +{
> +       return platform_driver_register(&lp8788_clk_driver);
> +}
> +subsys_initcall(lp8788_clk_init);
> +
> +static void __exit lp8788_clk_exit(void)
> +{
> +       platform_driver_unregister(&lp8788_clk_driver);
> +}
> +module_exit(lp8788_clk_exit);
> +
> +MODULE_DESCRIPTION("TI LP8788 Clock Driver");
> +MODULE_AUTHOR("Milo Kim");
> +MODULE_LICENSE("GPL");
> +MODULE_ALIAS("platform:lp8788-clk");
> diff --git a/drivers/mfd/lp8788.c b/drivers/mfd/lp8788.c
> index c3d3c9b..9f5596e 100644
> --- a/drivers/mfd/lp8788.c
> +++ b/drivers/mfd/lp8788.c
> @@ -72,6 +72,8 @@ static struct resource rtc_irqs[] = {
>  };
>  
>  static struct mfd_cell lp8788_devs[] = {
> +       MFD_DEV_SIMPLE(CLK),
> +
>         /* 4 bucks */
>         MFD_DEV_WITH_ID(BUCK, 1),
>         MFD_DEV_WITH_ID(BUCK, 2),
> diff --git a/include/linux/mfd/lp8788.h b/include/linux/mfd/lp8788.h
> index 786bf66..5f33be8 100644
> --- a/include/linux/mfd/lp8788.h
> +++ b/include/linux/mfd/lp8788.h
> @@ -28,6 +28,7 @@
>  #define LP8788_DEV_VIBRATOR    "lp8788-vibrator"
>  #define LP8788_DEV_KEYLED      "lp8788-keyled"
>  #define LP8788_DEV_ADC         "lp8788-adc"
> +#define LP8788_DEV_CLK         "lp8788-clk"
>  
>  #define LP8788_NUM_BUCKS       4
>  #define LP8788_NUM_DLDOS       12

I guess the above two hunks need Samuel's ACK.

Regards,
Mike

> -- 
> 1.7.9.5
> 
> 
> Best Regards,
> Milo


From tony at atomide.com  Tue Apr  9 00:51:00 2013
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 8 Apr 2013 21:51:00 -0700
Subject: [GIT PULL 1/5] omap pm fixes for v3.10 merge window
Message-ID: <pull-1365483063-475562>

The following changes since commit c309f7f46167e85d1aae2fd31f23e7d2b5cdfbe0:

  Merge branch 'for_3.10/omap_generic_cleanup_v2' of git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux into omap-for-v3.10/cleanup-v2 (2013-03-28 14:45:31 -0700)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.10/fixes-pm-signed

for you to fetch changes up to 5e7deed71290136cf70944e158f40401d0eed784:

  Merge tag 'omap-pm-v3.10/fixes/pm' of git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm into omap-for-v3.10/fixes-pm (2013-04-08 09:58:00 -0700)

----------------------------------------------------------------

Non-critical PM fix via Kevin Hilman <khilman at linaro.org>:

OMAP PM fixes for v3.10

Note that this has a dependency to omap-for-v3.10/cleanup-v2-signed.

----------------------------------------------------------------
Santosh Shilimkar (1):
      ARM: OMAP4+: PM: Restore CPU power state to ON with clockdomain force wakeup method

Tony Lindgren (1):
      Merge tag 'omap-pm-v3.10/fixes/pm' of git://git.kernel.org/.../khilman/linux-omap-pm into omap-for-v3.10/fixes-pm

 arch/arm/mach-omap2/cpuidle44xx.c |  1 +
 arch/arm/mach-omap2/omap-smp.c    | 12 ++++++++++--
 2 files changed, 11 insertions(+), 2 deletions(-)


From tony at atomide.com  Tue Apr  9 00:51:02 2013
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 8 Apr 2013 21:51:02 -0700
Subject: [GIT PULL 3/5] omap board changes for v3.10 merge window
In-Reply-To: <pull-1365483063-475562>
Message-ID: <mailman.8.1365483081.1198.linux-arm-kernel@lists.infradead.org>

The following changes since commit 31880c37c11e28cb81c70757e38392b42e695dc6:

  Linux 3.9-rc6 (2013-04-07 20:49:54 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.10/board-signed

for you to fetch changes up to 06993d6a8a51b90fc78c8c3cb7a81c9b4b88c683:

  ARM: OMAP: board-4430sdp: Provide regulator to pwm-backlight (2013-04-08 14:01:05 -0700)

----------------------------------------------------------------
Board related changes for v3.10 merge window. These are pretty
much all non-critical fixes for platform device initialization
that will be needed until we can drop the board-*.c files and
move to DT based boot.

----------------------------------------------------------------
Aaro Koskinen (2):
      ARM: OMAP1: fix omap_udc registration
      ARM: OMAP: RX-51: add missing regulator supply definitions for lis3lv02d

Andrew Chew (1):
      ARM: OMAP: board-4430sdp: Provide regulator to pwm-backlight

Paul Bolle (2):
      omap2+: Remove useless Makefile line
      omap2+: Remove useless Makefile line

Peter Ujfalusi (1):
      ARM: OMAP: zoom: Use pwm stack for lcd and keyboard backlight

Ruslan Bilovol (1):
      ARM: OMAP2+: omap2plus_defconfig: Add support for BMP085 pressure sensor

 arch/arm/configs/omap2plus_defconfig         |  1 +
 arch/arm/mach-omap1/include/mach/usb.h       |  2 +-
 arch/arm/mach-omap1/usb.c                    |  6 +--
 arch/arm/mach-omap2/Makefile                 |  3 --
 arch/arm/mach-omap2/board-4430sdp.c          |  6 +++
 arch/arm/mach-omap2/board-rx51-peripherals.c |  4 ++
 arch/arm/mach-omap2/board-zoom-display.c     | 56 ----------------------------
 arch/arm/mach-omap2/board-zoom-peripherals.c | 53 +++++++++++++++++++++++++-
 8 files changed, 67 insertions(+), 64 deletions(-)


From tony at atomide.com  Tue Apr  9 00:51:02 2013
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 8 Apr 2013 21:51:02 -0700
Subject: [GIT PULL 4/5] omap soc changes for v3.10 merge window
In-Reply-To: <pull-1365483063-475562>
Message-ID: <mailman.9.1365483088.1198.linux-arm-kernel@lists.infradead.org>

The following changes since commit 31880c37c11e28cb81c70757e38392b42e695dc6:

  Linux 3.9-rc6 (2013-04-07 20:49:54 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.10/soc-signed

for you to fetch changes up to 7a9819950f47dbf319895ee78220f2761f3687a3:

  ARM: OMAP4: Enable fix for Cortex-A9 erratas (2013-04-08 16:14:51 -0700)

----------------------------------------------------------------
Changes needed for enabling SOC_BUS for the SoC revision
information. Also enable few HW errata workarounds for omap4.

----------------------------------------------------------------
Ruslan Bilovol (3):
      ARM: OMAP2+: Move common part of late init into common function
      ARM: OMAP2+: SoC name and revision unification
      ARM: OMAP2+: Export SoC information to userspace

Sricharan R (1):
      ARM: OMAP4: Enable fix for Cortex-A9 erratas

 arch/arm/mach-omap2/Kconfig  |  3 ++
 arch/arm/mach-omap2/common.h |  8 ++++
 arch/arm/mach-omap2/id.c     | 95 ++++++++++++++++++++++++++++++++++++++++----
 arch/arm/mach-omap2/io.c     | 34 ++++++++--------
 4 files changed, 114 insertions(+), 26 deletions(-)


From tony at atomide.com  Tue Apr  9 00:51:01 2013
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 8 Apr 2013 21:51:01 -0700
Subject: [GIT PULL 2/5] omap pm clean-up for v3.10 merge window
In-Reply-To: <pull-1365483063-475562>
Message-ID: <mailman.10.1365483096.1198.linux-arm-kernel@lists.infradead.org>

The following changes since commit 07961ac7c0ee8b546658717034fe692fd12eefa9:

  Linux 3.9-rc5 (2013-03-31 15:12:43 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.10/cleanup-pm-signed

for you to fetch changes up to ca8cdff548da76da01f3783548ceb917139a5ddc:

  Merge tag 'omap-pm-v3.10/cleanup/cpuidle' of git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm into omap-for-v3.10/cleanup-pm (2013-04-08 09:51:00 -0700)

----------------------------------------------------------------

PM cleanup to prepare for omap5 PM via Kevin Hilman <khilman at linaro.org>:

OMAP3/4 CPUidle cleanups for v3.10

----------------------------------------------------------------
Daniel Lezcano (1):
      ARM: omap3: cpuidle: enable time keeping

Santosh Shilimkar (5):
      ARM: OMAP4: CPUidle: Avoid double idle driver registration
      ARM: OMAP: CPUidle: Unregister drivere on device registration failure
      ARM: OMAP4: CPUidle: Make C-state description field more precise
      ARM: OMAP4+: CPUidle: Deprecate use of omap4_mpuss_read_prev_context_state()
      ARM: OMAP4+: CPUidle: Consolidate idle driver for OMAP5 support

Tony Lindgren (1):
      Merge tag 'omap-pm-v3.10/cleanup/cpuidle' of git://git.kernel.org/.../khilman/linux-omap-pm into omap-for-v3.10/cleanup-pm

 arch/arm/mach-omap2/common.h              |  5 ----
 arch/arm/mach-omap2/cpuidle34xx.c         | 11 +++++--
 arch/arm/mach-omap2/cpuidle44xx.c         | 48 +++++++++++++++++--------------
 arch/arm/mach-omap2/omap-mpuss-lowpower.c | 14 ---------
 4 files changed, 35 insertions(+), 43 deletions(-)


From tony at atomide.com  Tue Apr  9 00:51:03 2013
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 8 Apr 2013 21:51:03 -0700
Subject: [GIT PULL 5/5] omap dt changes for v3.10 merge window
In-Reply-To: <pull-1365483063-475562>
Message-ID: <mailman.11.1365483104.1198.linux-arm-kernel@lists.infradead.org>

The following changes since commit 5852264f9d6139751796853fdfca9d5230cbfb97:

  Merge tag 'omap-devel-b-for-3.10' of git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending into for_3.10/dts_merged (2013-04-09 00:11:05 +0200)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.10/dt-signed-v2

for you to fetch changes up to 161e89a689bb88004b757986eefda2402448eef7:

  ARM/dts: OMAP3: fix pinctrl-single configuration (2013-04-08 17:00:22 -0700)

----------------------------------------------------------------
Device tree updates for omaps via Benoit Cousson <b-cousson at ti.com>.

Note that the branch has dependencies to two other branches:

- omap-devel-b-for-3.10 from Paul to get the AM33xx missing
  hwmod and thus avoid a regression with Santosh's hwmod
  cleanup including in this DT series [1]. It avoids breaking
  bisect if this series is merged before Paul's fixes.

- omap-for-v3.10/usb branch to avoid nasty merge conflict in
  omap3.dtsi and omap4.dtsi due to the DTS patches contained
  in the USB branch because of a screw up by the unnamed person
  typing this signed tag based on Benoit's comments.

[1] https://patchwork.kernel.org/patch/2366291/

----------------------------------------------------------------
Anil Kumar (3):
      ARM: dts: Add minimal DT support for DevKit8000
      ARM: dts: omap3-devkit8000: Enable audio support
      ARM: dts: omap3-devkit8000: Add NAND DT node

AnilKumar Ch (3):
      ARM: dts: AM33XX: Rename I2C and GPIO nodes
      ARM: dts: AM33XX: Add d_can instances to aliases
      ARM: dts: AM33XX: Add memory resource to d_can node

Christoph Fritz (1):
      ARM/dts: OMAP3: fix pinctrl-single configuration

Felipe Balbi (1):
      ARM: dts: OMAP5: Add SPI nodes

Florian Vaussard (3):
      ARM: dts: omap3-overo: Add support for pwm-leds
      ARM: dts: omap3-overo: Add audio support
      ARM: dts: OMAP3: Add GPMC controller

Javier Martinez Canillas (5):
      ARM: dts: omap3: Add generic DT support for IGEP devices
      ARM: dts: omap3: Add support for IGEPv2 board
      ARM: dts: omap3: Add support for IGEP COM Module
      ARM: dts: OMAP3: reduce GPMC mapped registers address space
      Documentation: dt: gpio-omap: Move interrupt-controller from #interrupt-cells description

Jon Hunter (16):
      ARM: OMAP2+: Prepare for device-tree PMU support
      ARM: dts: OMAP2+: Add PMU nodes
      ARM: dts: OMAP2+: Add SDMA controller bindings and nodes
      ARM: dts: Add GPMC node for OMAP2, OMAP4 and OMAP5
      ARM: dts: Add OMAP2 gpio bindings
      ARM: dts: OMAP3+: Correct gpio #interrupts-cells property
      ARM: dts: OMAP3: Add reg and interrupt properties for gpio
      ARM: dts: OMAP3: Add support for OMAP3430 SDP board
      ARM: OMAP: Force dmtimer restore if context loss is not detectable
      ARM: OMAP: Add function to request timer by node
      ARM: dts: OMAP2+: Update DMTIMER compatibility property
      ARM: OMAP2+: Populate DMTIMER errata when using device-tree
      ARM: dts: OMAP2+: Identify GPIO banks that are always powered
      ARM: dts: Update OMAP3430 SDP NAND and ONENAND properties
      ARM: dts: Add NOR flash bindings for OMAP2420 H4
      ARM: dts: Add OMAP3430 SDP NOR flash memory binding

Kishon Vijay Abraham I (7):
      ARM: dts: OMAP4: Add omap control usb data
      ARM: dts: OMAP4: Add omap-usb2 data
      ARM: dts: OMAP: Add usb_otg and glue data to OMAP3+ boards
      ARM: dts: OMAP5: Add OMAP control usb data
      ARM: dts: OMAP5: Add ocp2scp data
      ARM: dts: OMAP5: Add omap-usb3 and omap-usb2 data
      ARM: dts: OMAP5: add dwc3 omap and dwc3 core data

Lokesh Vutla (1):
      ARM: dts: OMAP5: Add watchdog timer node

Matthias Brugger (1):
      ARM: dts: omap3-igep: Add uart1 and uart2 to igep boards

NeilBrown (1):
      ARM: OMAP: Simplify dmtimer context-loss handling

Nishanth Menon (6):
      ARM: dts: OMAP34xx/35xx: Add CPU OPP table
      ARM: dts: OMAP36xx: Add CPU OPP table
      ARM: dts: OMAP3: use twl4030 vdd1 regulator for CPU
      ARM: dts: OMAP443x: Add CPU OPP table
      ARM: dts: omap4-panda: move generic sections to panda-common
      ARM: dts: OMAP4460: Add CPU OPP table

Peter Ujfalusi (5):
      ARM: dts: twl4030: Add PWM support
      ARM: dts: twl6030: Add PWM support
      ARM: dts: omap3-beagle-xm: Use pwm-leds for pmu_stat LED
      ARM: dts: omap4-sdp: Add support for pwm-leds (keypad and charging LED)
      ARM: dts: omap4-sdp: Add support for pwm-backlight

Philip Avinash (1):
      ARM: dts: AM33XX: Corrects typo in interrupt field in SPI node

Rajendra Nayak (1):
      ARM: dts: OMAP5: Specify nonsecure PPI IRQ for arch timer

Santosh Shilimkar (9):
      ARM: dts: omap5-evm: Update available memory to 2032 MB
      ARM: dts: OMAP5: Align the local timer dt node as per the current binding code
      ARM: dts: OMAP5: Move the gic node out of ocp space
      ARM: dts: OMAP5: Update the timer and GIC nodes for HYP kernel support
      ARM: dts: OMAP5: Update keypad reg property
      Documentation: dt: OMAP: l3-noc: Add *reg* in required properties
      ARM: dts: OMAP4/5: Update l3-noc DT nodes
      ARM: OMAP2+: hwmod: extract module address space from DT blob
      ARM: OMAP2+: hwmod: Don't call _init_mpu_rt_base if no sysc

Sebastien Guiriec (1):
      ARM: dts: OMAP2+: Add SDMA Audio IPs bindings

Sourav Poddar (4):
      ARM: dts: omap4-sdp: Add I2c pinctrl data
      ARM: dts: omap5-evm: Add I2c pinctrl data
      ARM: dts: omap4-panda: Add I2c pinctrl data
      ARM: dts: omap5-evm: Add mcspi data

Tony Lindgren (1):
      Merge branch 'for_3.10/dts' of git://git.kernel.org/.../bcousson/linux-omap-dt into omap-for-v3.10/dt

 .../devicetree/bindings/arm/omap/l3-noc.txt        |   1 +
 .../devicetree/bindings/arm/omap/timer.txt         |  17 +-
 .../devicetree/bindings/gpio/gpio-omap.txt         |   8 +-
 Documentation/devicetree/bindings/usb/omap-usb.txt |   1 +
 arch/arm/boot/dts/Makefile                         |   4 +
 arch/arm/boot/dts/am335x-bone.dts                  |  10 +-
 arch/arm/boot/dts/am335x-evm.dts                   |  18 +-
 arch/arm/boot/dts/am335x-evmsk.dts                 |  18 +-
 arch/arm/boot/dts/am33xx.dtsi                      |  40 ++--
 arch/arm/boot/dts/am3517-evm.dts                   |   2 +-
 arch/arm/boot/dts/am3517_mt_ventoux.dts            |   2 +-
 arch/arm/boot/dts/omap2.dtsi                       |  39 +++-
 arch/arm/boot/dts/omap2420-h4.dts                  |  46 ++++
 arch/arm/boot/dts/omap2420.dtsi                    |  67 +++++-
 arch/arm/boot/dts/omap2430.dtsi                    |  87 ++++++-
 arch/arm/boot/dts/omap3-beagle-xm.dts              |  26 ++-
 arch/arm/boot/dts/omap3-beagle.dts                 |   8 +-
 arch/arm/boot/dts/omap3-devkit8000.dts             | 169 ++++++++++++++
 arch/arm/boot/dts/omap3-evm.dts                    |  14 +-
 arch/arm/boot/dts/omap3-igep.dtsi                  | 122 ++++++++++
 arch/arm/boot/dts/omap3-igep0020.dts               |  56 +++++
 arch/arm/boot/dts/omap3-igep0030.dts               |  44 ++++
 arch/arm/boot/dts/omap3-overo.dtsi                 |  31 ++-
 arch/arm/boot/dts/omap3.dtsi                       | 142 ++++++++++--
 arch/arm/boot/dts/omap3430-sdp.dts                 | 190 ++++++++++++++++
 arch/arm/boot/dts/omap34xx.dtsi                    |  28 +++
 arch/arm/boot/dts/omap36xx.dtsi                    |  13 ++
 arch/arm/boot/dts/omap4-panda-a4.dts               |   5 +-
 arch/arm/boot/dts/omap4-panda-common.dtsi          | 251 +++++++++++++++++++++
 arch/arm/boot/dts/omap4-panda-es.dts               |   5 +-
 arch/arm/boot/dts/omap4-panda.dts                  | 201 +----------------
 arch/arm/boot/dts/omap4-sdp.dts                    |  74 +++++-
 arch/arm/boot/dts/omap4-var-som.dts                |   2 +-
 arch/arm/boot/dts/omap4.dtsi                       | 135 +++++++++--
 arch/arm/boot/dts/omap443x.dtsi                    |  27 +++
 arch/arm/boot/dts/omap4460.dtsi                    |  32 +++
 arch/arm/boot/dts/omap5-evm.dts                    | 110 ++++++++-
 arch/arm/boot/dts/omap5.dtsi                       | 245 +++++++++++++++++---
 arch/arm/boot/dts/twl4030.dtsi                     |  18 +-
 arch/arm/boot/dts/twl6030.dtsi                     |  12 +
 arch/arm/mach-omap2/board-generic.c                |   1 +
 arch/arm/mach-omap2/omap_hwmod.c                   |  48 +++-
 arch/arm/mach-omap2/pmu.c                          |  14 +-
 arch/arm/mach-omap2/timer.c                        |   7 +-
 arch/arm/plat-omap/dmtimer.c                       | 241 ++++++++++++--------
 arch/arm/plat-omap/include/plat/dmtimer.h          |   1 +
 46 files changed, 2172 insertions(+), 460 deletions(-)
 create mode 100644 arch/arm/boot/dts/omap3-devkit8000.dts
 create mode 100644 arch/arm/boot/dts/omap3-igep.dtsi
 create mode 100644 arch/arm/boot/dts/omap3-igep0020.dts
 create mode 100644 arch/arm/boot/dts/omap3-igep0030.dts
 create mode 100644 arch/arm/boot/dts/omap3430-sdp.dts
 create mode 100644 arch/arm/boot/dts/omap34xx.dtsi
 create mode 100644 arch/arm/boot/dts/omap4-panda-common.dtsi
 create mode 100644 arch/arm/boot/dts/omap443x.dtsi
 create mode 100644 arch/arm/boot/dts/omap4460.dtsi


From prasanna.ps at samsung.com  Tue Apr  9 00:59:18 2013
From: prasanna.ps at samsung.com (Prasanna Kumar)
Date: Tue, 09 Apr 2013 10:29:18 +0530
Subject: [PATCH RESEND] i2c: s3c2410: Add SMBus emulation for block read
Message-ID: <1365483558-4054-1-git-send-email-prasanna.ps@samsung.com>

From: Jaemin Yoo <jmin.yoo at samsung.com>

SMBus read and write are supported by the emulation layer of i2c
framework if the controller doesn't have SMBus features.

I2C_M_RECV_LEN flag is used to let i2c drivers know rx length is not
yet determined but will be read to the first byte in rx buffer.

s3c2410 doesn't handle this flag. So only one byte is read from slave.
There fore following two features are added to the driver code.

1. skip rx length check if I2C_M_RECV_LEN is set and the length is 1.
2. add actual bytes to the rx length after reading first bytes if
   I2C_M_RECV_LEN.

I2C_M_RECV_LEN is only set for SMBus command. So this code does not
affect legacy codes which only use i2c command for s3c2410.

Signed-off-by: Jaemin Yoo <jmin.yoo at samsung.com>
Signed-off-by: Prasanna Kumar <prasanna.ps at samsung.com>
---
 drivers/i2c/busses/i2c-s3c2410.c |    9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/drivers/i2c/busses/i2c-s3c2410.c b/drivers/i2c/busses/i2c-s3c2410.c
index 17c5c37..e4ab9ea 100644
--- a/drivers/i2c/busses/i2c-s3c2410.c
+++ b/drivers/i2c/busses/i2c-s3c2410.c
@@ -309,6 +309,12 @@ static inline int is_lastmsg(struct s3c24xx_i2c *i2c)
 
 static inline int is_msglast(struct s3c24xx_i2c *i2c)
 {
+	/* msg->len is always 1 for the first byte of smbus block read.
+	 * Actual length will be read from slave. More bytes will be
+	 * read according to the length then. */
+	if (i2c->msg->flags & I2C_M_RECV_LEN && i2c->msg->len == 1)
+		return 0;
+
 	return i2c->msg_ptr == i2c->msg->len-1;
 }
 
@@ -448,6 +454,9 @@ static int i2c_s3c_irq_nextbyte(struct s3c24xx_i2c *i2c, unsigned long iicstat)
 		byte = readb(i2c->regs + S3C2410_IICDS);
 		i2c->msg->buf[i2c->msg_ptr++] = byte;
 
+		/* Add actual length to read for smbus block read */
+		if (i2c->msg->flags & I2C_M_RECV_LEN && i2c->msg->len == 1)
+			i2c->msg->len += byte;
  prepare_read:
 		if (is_msglast(i2c)) {
 			/* last byte of buffer */
-- 
1.7.10.4



From andrew at lunn.ch  Tue Apr  9 01:19:31 2013
From: andrew at lunn.ch (Andrew Lunn)
Date: Tue, 9 Apr 2013 07:19:31 +0200
Subject: [PATCH v2 0/3] Add DT board setup for LaCie CloudBox
In-Reply-To: <1365460889-22965-1-git-send-email-simon.guinot@sequanux.org>
References: <1365460889-22965-1-git-send-email-simon.guinot@sequanux.org>
Message-ID: <20130409051931.GH13524@lunn.ch>

On Tue, Apr 09, 2013 at 12:41:26AM +0200, Simon Guinot wrote:
> This patch series adds DT board setup for the LaCie CloudBox machine.
> Note that two patches have been added for this v2. The first,
> "ARM: Kirkwood: sort board entries by ASCII-code order" helps to respect
> alphabetical order while adding a new board entry. The last,
> "ARM: Kirkwood: update Network Space Mini v2 description" could be
> useful to differentiate the cloudbox and netspace_v2_mini machines
> (both embedded in products named LaCie CloudBox).
> 
> Regards,

Hi Simon,

Looks good.

Acked-by: Andrew Lunn <andrew at lunn.ch>

> 
> Simon
> 
> Changes for v2:
>  - Add patch "ARM: Kirkwood: sort board entries by ASCII-code order".
>  - Add patch "ARM: Kirkwood: update Network Space Mini v2 description".
>  - Rebase against Jason's branch marvell/mvebu/boards.
>  - Remove i2c pinctrl declaration (not used).
>  - For all modified files, respect alphabetical order while inserting cloudbox
>    entries.
>  - Enhance patch description to avoid confusion between the two LaCie
>    products named CloudBox.
> 
> Simon Guinot (3):
>   ARM: Kirkwood: sort board entries by ASCII-code order
>   ARM: Kirkwood: DT board setup for CloudBox
>   ARM: Kirkwood: update Network Space Mini v2 description
> 
>  arch/arm/boot/dts/Makefile              |    3 +-
>  arch/arm/boot/dts/kirkwood-cloudbox.dts |   89 +++++++++
>  arch/arm/boot/dts/kirkwood-ns2mini.dts  |    1 +
>  arch/arm/configs/kirkwood_defconfig     |   51 ++---
>  arch/arm/mach-kirkwood/Kconfig          |  325 ++++++++++++++++---------------
>  arch/arm/mach-kirkwood/Makefile         |   41 ++--
>  arch/arm/mach-kirkwood/board-dt.c       |   14 +-
>  arch/arm/mach-kirkwood/board-ns2.c      |    3 +-
>  arch/arm/mach-kirkwood/common.h         |    6 +
>  9 files changed, 324 insertions(+), 209 deletions(-)
>  create mode 100644 arch/arm/boot/dts/kirkwood-cloudbox.dts
> 
> -- 
> 1.7.10.4
> 


From nicolas.pitre at linaro.org  Tue Apr  9 01:20:11 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Tue, 9 Apr 2013 01:20:11 -0400 (EDT)
Subject: [GIT PULL] Multi Cluster Power Management infrastructure
In-Reply-To: <20130407000237.GI17995@n2100.arm.linux.org.uk>
References: <alpine.LFD.2.03.1303251219530.1372@syhkavp.arg>
 <alpine.LFD.2.03.1304042138160.1171@syhkavp.arg>
 <20130405094159.GH17995@n2100.arm.linux.org.uk>
 <201304052233.25630.arnd@arndb.de>
 <20130407000237.GI17995@n2100.arm.linux.org.uk>
Message-ID: <alpine.LFD.2.03.1304090006140.1171@syhkavp.arg>

On Sun, 7 Apr 2013, Russell King - ARM Linux wrote:

> On Fri, Apr 05, 2013 at 10:33:25PM +0200, Arnd Bergmann wrote:
> > On Friday 05 April 2013, Russell King - ARM Linux wrote:
> > > 
> > > Now, I'm currently on holiday.  I'm going to be on holday until after
> > > mid-April.  I'm not pulling anything until then.  I'm not applying anything
> > > until then.  I'm not even reading this mailbox - and given current mail
> > > rates at 300-400 messages per day, I will *not* be reading back over a
> > > fortnights worth of email.
> > 
> > I haven't reviewed the patches before, and only heard of the controversy
> > from Nico's email yesterday. Independent of your personal situation and
> > who implemented the code, I think it's clear that a lot of people (not
> > just Linaro) want to see it get merged and not having it upstream is
> > blocking platform specific code from getting put into arm-soc.
> 
> Nicolas is doing what he always does when he doesn't get his own way - he
> tries to force his way.  This is exactly what's going on here...

Since you're willfully blocking my way, I have no choice but to force 
it.  Are you expecting me to stand still?

> > Since you are currently on holiday, I think it's best if we at least put
> > it into asm-soc as a for-rmk/mcpm branch in order to give it coverage
> > in linux-next and let us merge the dependent platform code into "late"
> > branches for 3.10. I still hope the nontechnical issues can be resolved
> > in time to let you pull it into your tree before the merge window.
> 
> I doubt it will.  The way I now feel, I feel betrayed by Linaro, and
> I feel that they have done me a great disservice.  I don't see that
> there's anything Linaro has to offer me in way of work (if they could,
> then they would be able to tell me what areas they have available -
> but they can't even do that.)

Oh come on, please cut that crap.  We gave you complete freedom to 
suggest what _you_ want to work on.  But apparently you can't even do 
that either.

> How can this be resolved?  I've no idea, that's entirely up to Linaro
> and its management to work out whether they actually have any work
> available.

What does it have to do with the pull request I sent to you, given that 
it has been made clear now that Linaro won't pay you for this?  Are you 
expecting money from Linaro before sending those patches upstream?

> So no, _I_ can't resolve it until Linaro gets a handle on what the hell
> that organization wants to do.

That organization wants you, the prime ARM Linux kernel expert above 
all, to determine by yourself a list of things where your work could 
benefit ARM Linux the most.  Then we'll select in your list some items 
we want you to work on our behalf in exchange for money.  How can I make 
it more clear?

If patch review is part of the deal, that would be for work in progress, 
and _not_ for completed patches.  The patches presented here used to be 
work in progress during Q4 of last year but they are _not_ work in 
progress anymore.  So please get a grip and look towards the future not 
in the past.

> But the whole message here is: if you fuck me around commercially, you
> can't *not* expect it to have an impact on what I volunteer to do, and
> you'd better *not* put work-items on the table and then take them away
> again, and then end up demanding that they be done for gratis just
> because of my position.  *That* is grossly unfair.

Well, as a community maintainer, you have to follow the established 
community process.  As a community contributor, I have to follow the 
process too.  And the community doesn't give a damn about the success of 
your commercial arrangements nor Linaro's.  As far as the community is 
concerned, I did my part, so I'm politely asking you that you do yours.

Of course, your community maintainer work is done on a volunteer basis 
and I fully appreciate that.  That means I cannot impose on you to merge 
my patches.

However, this patch set has gone through all the normal community review 
process.  No one objects to its merge into mainline.  No one but you, 
and your arguments at this point are completely non technical.

In that case you have to accept that I might seek another maintainer to 
judge the technical merit of those patches and merge them upstream.  
Linus has made it clear many times that maintainers can be bypassed if 
need be.

Any commercial arrangement between you and Linaro remains an orthogonal 
issue, and the discussion about that may continue separately and in 
private if you are still interested.


Nicolas


From prakash.pm at ti.com  Tue Apr  9 01:31:22 2013
From: prakash.pm at ti.com (Manjunathappa, Prakash)
Date: Tue, 9 Apr 2013 05:31:22 +0000
Subject: [PATCH] ARM: davinci: da850 evm: update clock rate for UART 1/2
 DT nodes
In-Reply-To: <51433233.9070303@ti.com>
References: <1361262734-8540-1-git-send-email-prakash.pm@ti.com>
 <512F33F3.9070203@ti.com>
 <A73F36158E33644199EB82C5EC81C7BC3EA49090@DBDE01.ent.ti.com>
 <51433233.9070303@ti.com>
Message-ID: <A73F36158E33644199EB82C5EC81C7BC3EA4C535@DBDE01.ent.ti.com>

On Fri, Mar 15, 2013 at 20:07:39, Nori, Sekhar wrote:
> 
> 
> On 3/15/2013 6:56 PM, Manjunathappa, Prakash wrote:
> > Hi Sekhar,
> > 
> > On Thu, Feb 28, 2013 at 16:09:47, Nori, Sekhar wrote:
> >> Prakash,
> >>
> >> On 2/19/2013 2:02 PM, Manjunathappa, Prakash wrote:
> >>> DT kernel with latest of denx SPL U-boot boots with garbled UART
> >>> logs. This is because in U-boot UART2 gets sourced by PLL0_SYSCLK2
> >>> configured for 150MHz. But later in kernel UART2 gets mapped to
> >>> PLL1_SYSCLK2 and is configured for 132MHz not for 150MHz.
> >>>
> >>> PLL1 is configured for 264MHz to support mDDR on the EVM. That is
> >>> memory controller driving mDDR can be configured for 150MHz and
> >>> mDDR it self can operate at 132MHz.
> >>>
> >>> So override UART1 and UART2 DT node clock-frequency property with
> >>> rate available on da850 EVM.
> >>>
> >>> Signed-off-by: Manjunathappa, Prakash <prakash.pm at ti.com>
> >>
> >> How about dropping the clock-frequency attribute altogether? of_serial.c
> >> seems to be falling back on clk apis if frequency is not passed and that
> >> should make the kernel work with all versions of U-Boot.
> >>
> > 
> > Yes it can be dropped by having duplicate clock node for UART having only
> 
> You meant an additional clk_lookup entry? That's different from a new
> 'struct clk' node.
> 

Yes I meant adding to clk_lookup, not new 'struct clk'.

> > dev_id. This is required because DT kernel does the clk_get with only dev_id
> > and non-DT kernel only with con_id. In DT kernel clk_get is done from generic
> > code of_platform_serial_setup:of_serial.c and in non-DT kernel is done from
> > platform code, davinci_serial_setup_clk:arch/arm/mach-davinci/serial.c
> > 
> > Please let me know your opinion on this.
> 
> When only one clock is present, con_id of NULL is more appropriate. How
> about fixing arch/arm/mach-davinci/serial.c and existing clk_lookup
> entries to use this?
> 

Ok I will share patch which fixes this.

Thanks,
Prakash



From nicolas.pitre at linaro.org  Tue Apr  9 01:41:13 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Tue, 9 Apr 2013 01:41:13 -0400 (EDT)
Subject: [PATCH v4 15/15] ARM: vexpress: Select multi-cluster SMP operation
 if required
In-Reply-To: <1365412211.3384.16.camel@linaro1.home>
References: <1360041732-17936-1-git-send-email-nicolas.pitre@linaro.org>
 <1360041732-17936-16-git-send-email-nicolas.pitre@linaro.org>
 <20130405224819.GB14308@quad.lixom.net>
 <alpine.LFD.2.03.1304060943370.1171@syhkavp.arg>
 <1365412211.3384.16.camel@linaro1.home>
Message-ID: <alpine.LFD.2.03.1304090135590.1171@syhkavp.arg>

On Mon, 8 Apr 2013, Jon Medhurst (Tixy) wrote:

> On Sat, 2013-04-06 at 10:02 -0400, Nicolas Pitre wrote:
> > I've amended this patch slightly so to:
> > 
> > 1) Keep the default .smp = &vexpress_smp_ops and only perform an 
> >    override in vexpress_smp_init_ops() when appropriate.  This should
> >    remove one potential issue with Xen support that was highlighted 
> >    recently.
> > 
> > 2) Add a mcpm_smp_set_ops() instead of installing mcpm_smp_ops directly
> >    for better abstraction.
> >
> > 3) Added a comment about and checked for the CCI node being enabled.
> > 
> > That results in the patch below.  Given those are minor changes, I kept 
> > the existing review tags.
> >
> > From: Jon Medhurst <tixy at linaro.org>
> > Date: Wed, 30 Jan 2013 09:12:55 +0000
> > Subject: [PATCH] ARM: vexpress: Select multi-cluster SMP operation if required
> > 
> > Signed-off-by: Jon Medhurst <tixy at linaro.org>
> > Signed-off-by: Nicolas Pitre <nicolas.pitre at linaro.org>
> > Reviewed-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
> > Acked-by: Pawel Moll <pawel.moll at arm.com>
> >
> > diff --git a/arch/arm/common/mcpm_platsmp.c b/arch/arm/common/mcpm_platsmp.c
> > index 34f236af09..cc82040877 100644
> > --- a/arch/arm/common/mcpm_platsmp.c
> > +++ b/arch/arm/common/mcpm_platsmp.c
> > @@ -85,3 +85,8 @@ struct smp_operations __initdata mcpm_smp_ops = {
> >  	.cpu_die		= mcpm_cpu_die,
> >  #endif
> >  };
> > +
> > +void __init mcpm_smp_set_ops(void)
> > +{
> > +	smp_set_ops(&mcpm_smp_ops);
> > +}
> > diff --git a/arch/arm/include/asm/mcpm_entry.h b/arch/arm/include/asm/mcpm_entry.h
> > index 814623e6a1..34dfb86ff5 100644
> > --- a/arch/arm/include/asm/mcpm_entry.h
> > +++ b/arch/arm/include/asm/mcpm_entry.h
> > @@ -190,5 +190,7 @@ int __mcpm_cluster_state(unsigned int cluster);
> >  int __init mcpm_sync_init(
> >  	void (*power_up_setup)(unsigned int affinity_level));
> >  
> > +void __init mcpm_smp_set_ops(void);
> > +
> >  #endif /* ! __ASSEMBLY__ */
> >  #endif
> 
> 
> Do the changes to the above mcpm files want to be in a separate patch as
> it's generic ARM code, not vexpress specific?

Well, since it was so trivial I didn't do it, but the split might be a 
good idea nevertheless.  So I inserted the following patch in the 
series, and corresponding changes are now removed from the patch above.  
What do you think?

Author: Nicolas Pitre <nicolas.pitre at linaro.org>
Date:   Tue Apr 9 01:29:17 2013 -0400

    ARM: mcpm: provide an interface to set the SMP ops at run time
    
    This is cleaner than exporting the mcpm_smp_ops structure.
    
    Signed-off-by: Nicolas Pitre <nico at linaro.org>

diff --git a/arch/arm/common/mcpm_platsmp.c b/arch/arm/common/mcpm_platsmp.c
index 34f236af09..79ed70d846 100644
--- a/arch/arm/common/mcpm_platsmp.c
+++ b/arch/arm/common/mcpm_platsmp.c
@@ -76,7 +76,7 @@ static void mcpm_cpu_die(unsigned int cpu)
 
 #endif
 
-struct smp_operations __initdata mcpm_smp_ops = {
+static struct smp_operations __initdata mcpm_smp_ops = {
 	.smp_init_cpus		= simple_smp_init_cpus,
 	.smp_boot_secondary	= mcpm_boot_secondary,
 	.smp_secondary_init	= mcpm_secondary_init,
@@ -85,3 +85,8 @@ struct smp_operations __initdata mcpm_smp_ops = {
 	.cpu_die		= mcpm_cpu_die,
 #endif
 };
+
+void __init mcpm_smp_set_ops(void)
+{
+	smp_set_ops(&mcpm_smp_ops);
+}
diff --git a/arch/arm/include/asm/mcpm_entry.h b/arch/arm/include/asm/mcpm_entry.h
index 814623e6a1..34dfb86ff5 100644
--- a/arch/arm/include/asm/mcpm_entry.h
+++ b/arch/arm/include/asm/mcpm_entry.h
@@ -190,5 +190,7 @@ int __mcpm_cluster_state(unsigned int cluster);
 int __init mcpm_sync_init(
 	void (*power_up_setup)(unsigned int affinity_level));
 
+void __init mcpm_smp_set_ops(void);
+
 #endif /* ! __ASSEMBLY__ */
 #endif


From thomas.abraham at linaro.org  Tue Apr  9 01:59:46 2013
From: thomas.abraham at linaro.org (Thomas Abraham)
Date: Tue, 09 Apr 2013 11:29:46 +0530
Subject: [PATCH v4] mmc: dw_mmc: let device core setup the default pin
 configuration
Message-ID: <1365487186-4587-1-git-send-email-thomas.abraham@linaro.org>

With device core now able to setup the default pin configuration,
the pin configuration code based on the deprecated Samsung specific
gpio bindings is removed.

Signed-off-by: Thomas Abraham <thomas.abraham at linaro.org>
Acked-by: Linus Walleij <linus.walleij at linaro.org>
Reviewed-by: Doug Anderson <dianders at chromium.org>
Tested-by: Doug Anderson <dianders at chromium.org>
Acked-by: Seungwon Jeon <tgih.jun at samsung.com>
---
Changes since v3:
- Rebased to the latest mmc-next branch, resolving the compilation
  error with this patch due to changes in commit f2f942ce
  "mmc: dw_mmc: Check return value of regulator_enable".
  Thanks to Doug for pointing out this issue with the v3 patch.

 drivers/mmc/host/dw_mmc-exynos.c |   38 --------------------------------------
 drivers/mmc/host/dw_mmc.c        |   14 +++-----------
 drivers/mmc/host/dw_mmc.h        |    3 ---
 3 files changed, 3 insertions(+), 52 deletions(-)

diff --git a/drivers/mmc/host/dw_mmc-exynos.c b/drivers/mmc/host/dw_mmc-exynos.c
index c7f0976..f013e7e 100644
--- a/drivers/mmc/host/dw_mmc-exynos.c
+++ b/drivers/mmc/host/dw_mmc-exynos.c
@@ -152,43 +152,6 @@ static int dw_mci_exynos_parse_dt(struct dw_mci *host)
 	return 0;
 }
 
-static int dw_mci_exynos_setup_bus(struct dw_mci *host,
-				struct device_node *slot_np, u8 bus_width)
-{
-	int idx, gpio, ret;
-
-	if (!slot_np)
-		return -EINVAL;
-
-	/* cmd + clock + bus-width pins */
-	for (idx = 0; idx < NUM_PINS(bus_width); idx++) {
-		gpio = of_get_gpio(slot_np, idx);
-		if (!gpio_is_valid(gpio)) {
-			dev_err(host->dev, "invalid gpio: %d\n", gpio);
-			return -EINVAL;
-		}
-
-		ret = devm_gpio_request(host->dev, gpio, "dw-mci-bus");
-		if (ret) {
-			dev_err(host->dev, "gpio [%d] request failed\n", gpio);
-			return -EBUSY;
-		}
-	}
-
-	if (host->pdata->quirks & DW_MCI_QUIRK_BROKEN_CARD_DETECTION)
-		return 0;
-
-	gpio = of_get_named_gpio(slot_np, "samsung,cd-pinmux-gpio", 0);
-	if (gpio_is_valid(gpio)) {
-		if (devm_gpio_request(host->dev, gpio, "dw-mci-cd"))
-			dev_err(host->dev, "gpio [%d] request failed\n", gpio);
-	} else {
-		dev_info(host->dev, "cd gpio not available");
-	}
-
-	return 0;
-}
-
 /* Common capabilities of Exynos4/Exynos5 SoC */
 static unsigned long exynos_dwmmc_caps[4] = {
 	MMC_CAP_UHS_DDR50 | MMC_CAP_1_8V_DDR |
@@ -205,7 +168,6 @@ static const struct dw_mci_drv_data exynos_drv_data = {
 	.prepare_command	= dw_mci_exynos_prepare_command,
 	.set_ios		= dw_mci_exynos_set_ios,
 	.parse_dt		= dw_mci_exynos_parse_dt,
-	.setup_bus		= dw_mci_exynos_setup_bus,
 };
 
 static const struct of_device_id dw_mci_exynos_match[] = {
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 45d9216..5dcef43 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -1952,14 +1952,6 @@ static int dw_mci_init_slot(struct dw_mci *host, unsigned int id)
 	else
 		bus_width = 1;
 
-	if (drv_data && drv_data->setup_bus) {
-		struct device_node *slot_np;
-		slot_np = dw_mci_of_find_slot_node(host->dev, slot->id);
-		ret = drv_data->setup_bus(host, slot_np, bus_width);
-		if (ret)
-			goto err_setup_bus;
-	}
-
 	switch (bus_width) {
 	case 8:
 		mmc->caps |= MMC_CAP_8_BIT_DATA;
@@ -2002,7 +1994,7 @@ static int dw_mci_init_slot(struct dw_mci *host, unsigned int id)
 		if (ret) {
 			dev_err(host->dev,
 				"failed to enable regulator: %d\n", ret);
-			goto err_setup_bus;
+			return ret;
 		}
 	}
 
@@ -2015,7 +2007,7 @@ static int dw_mci_init_slot(struct dw_mci *host, unsigned int id)
 
 	ret = mmc_add_host(mmc);
 	if (ret)
-		goto err_setup_bus;
+		goto err_add_host;
 
 #if defined(CONFIG_DEBUG_FS)
 	dw_mci_init_debugfs(slot);
@@ -2032,7 +2024,7 @@ static int dw_mci_init_slot(struct dw_mci *host, unsigned int id)
 
 	return 0;
 
-err_setup_bus:
+err_add_host:
 	mmc_free_host(mmc);
 	return -EINVAL;
 }
diff --git a/drivers/mmc/host/dw_mmc.h b/drivers/mmc/host/dw_mmc.h
index 53b8fd9..0b74189 100644
--- a/drivers/mmc/host/dw_mmc.h
+++ b/drivers/mmc/host/dw_mmc.h
@@ -190,7 +190,6 @@ extern int dw_mci_resume(struct dw_mci *host);
  * @prepare_command: handle CMD register extensions.
  * @set_ios: handle bus specific extensions.
  * @parse_dt: parse implementation specific device tree properties.
- * @setup_bus: initialize io-interface
  *
  * Provide controller implementation specific extensions. The usage of this
  * data structure is fully optional and usage of each member in this structure
@@ -203,7 +202,5 @@ struct dw_mci_drv_data {
 	void		(*prepare_command)(struct dw_mci *host, u32 *cmdr);
 	void		(*set_ios)(struct dw_mci *host, struct mmc_ios *ios);
 	int		(*parse_dt)(struct dw_mci *host);
-	int		(*setup_bus)(struct dw_mci *host,
-				struct device_node *slot_np, u8 bus_width);
 };
 #endif /* _DW_MMC_H_ */
-- 
1.6.6.rc2



From cdall at cs.columbia.edu  Tue Apr  9 01:42:10 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Mon, 8 Apr 2013 22:42:10 -0700
Subject: [PATCH v2 0/7] ARM: KVM: Revamping the HYP init code for fun and
 profit
In-Reply-To: <1365435403-29265-1-git-send-email-marc.zyngier@arm.com>
References: <1365435403-29265-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <CAEDV+gLNc=tTuV=Qgbu4OMTx5STd_RLP7OPODsyq3TkLh586GA@mail.gmail.com>

On Mon, Apr 8, 2013 at 8:36 AM, Marc Zyngier <marc.zyngier at arm.com> wrote:
> Over the past few weeks, I've gradually realized how broken our HYP
> idmap code is. Badly broken.
>
> The main problem is about supporting CPU hotplug. Imagine a CPU being
> initialized normally, running VMs, and then being powered down. So
> far, so good. Now mentally bring it back online. The CPU will come
> back via the secondary CPU boot path, and then what? We cannot use it
> anymore, because we need an idmap which is long gone, and because our
> page tables are now live, containing the world-switch code, VM
> structures, and other bits and pieces.
>
> Another fun issue is that we don't have any TLB invalidation in the
> HYP init code. And guess what? we cannot do it! HYP TLB invalidation
> has to occur in HYP, and once we've installed the runtime page tables,
> it is already too late. It is actually fairly easy to construct a
> scenario where idmap and runtime pages have colliding translations.
>
> The nail on the coffin was provided by Catalin Marinas who told me how
> much he disliked the arm64 HYP idmap code, and made me realize that we
> already have all the necessary code in arch/arm/kvm/mmu.c. It just
> needs a tiny bit of care and affection. With a chainsaw.
>
> The solution to the first two issues is a bit tricky, but doesn't
> involve a lot of code. The hotplug problem mandates that we keep two
> sets of page tables (boot and runtime). The TLB problem mandates that
> we're able to transition from one PGD to another while in HYP,
> invalidating the TLBs in the process.
>
> To be able to do this, we need to share a page between the two page
> tables. A page that will have the same VA in both configurations. All
> we need is a VA that has the following properties:
> - This VA can't be used to represent a kernel mapping.
> - This VA will not conflict with the physical address of the kernel
>   text
>
> The vectors page VA seems to satisfy this requirement:
> - The kernel never maps anything else there
> - The kernel text being copied at the beginning of the physical
>   memory, it is unlikely to use the last 64kB (I doubt we'll ever
>   support KVM on a system with something like 4MB of RAM, but patches
>   are very welcome).
>
> Let's call this VA the trampoline VA.
>
> Now, we map our init page at 3 locations:
> - idmap in the boot pgd
> - trampoline VA in the boot pgd
> - trampoline VA in the runtime pgd
>
> The init scenario is now the following:
> - We jump in HYP with four parameters: boot HYP pgd, runtime HYP pgd,
>   runtime stack, runtime vectors
> - Enable the MMU with the boot pgd
> - Jump to a target into the trampoline page (remember, this is the
>   same physical page!)
> - Now switch to the runtime pgd (same VA, and still the same physical
>   page!)
> - Invalidate TLBs
> - Set stack and vectors
> - Profit! (or eret, if you only care about the code).
>
> Once we have this infrastructure in place, supporting CPU hot-plug is
> a piece of cake. Just wire a cpu-notifier in the existing code.
>
> This has been tested on both arm (VE TC2) and arm64 (Foundation Model).
>
> From v1:
> - Reduce the mandatory alignement of the init code page, and use a
>   bounce page if the code is crossing a page boundary.
> - Add some more comments to the code (as requested by Christoffer)
> - Fixed compilation issue with older toolchains (spotted by Geoff)
>

The whole thing looks good to me,
-Christoffer


From prakash.pm at ti.com  Tue Apr  9 01:44:10 2013
From: prakash.pm at ti.com (Manjunathappa, Prakash)
Date: Tue, 9 Apr 2013 05:44:10 +0000
Subject: [PATCH v5 0/5] Patch enables support for m25p64 SPI flash
 support on da850-EVM.
In-Reply-To: <1364998150-5980-1-git-send-email-prakash.pm@ti.com>
References: <1364998150-5980-1-git-send-email-prakash.pm@ti.com>
Message-ID: <A73F36158E33644199EB82C5EC81C7BC3EA4C560@DBDE01.ent.ti.com>

Hi Grant,

On Wed, Apr 03, 2013 at 19:39:05, Manjunathappa, Prakash wrote:
> Testing information:
> da850-evm comes with partitions specified in DT blob.
> Able to mount/umount and create/delete files on filesystem partition.
> 

Could you please ack the driver(1/5) and documentation(2/5) changes so
that Sekhar can merge the platform changes, he doesn't have any
objection on this series.
http://marc.info/?l=linux-doc&m=136489750130615&w=1

Thanks,
Prakash

> Applies on top of linux_davinci/master tree:
> git://gitorious.org/linux-davinci/linux-davinci.git
> 
> Since v4:
> Separate out chip_select pinmuxing so as to allow boards choose
> accordingly.
> 
> Since v3:
> Minor nit, fix tabs and commit message of 2/5.
> 
> Since v2:
> Fix compatible property DT naming convention.
> 
> Since v1:
> Look for m25p64 instead of m25p80 flash chip and correct partition information.
> Dropped below accepted patch:
> "spi/davinci: fix module build error"
> Considered below missed out patch:
> spi/davinci: add DT binding documentation
> 
> Manjunathappa, Prakash (4):
>   spi/davinci: no wildcards in DT compatible property
>   ARM: davinci: da850: add SPI1 DT node
>   ARM: davinci: da850: override SPI DT node device name
>   ARM: davinci: da850-evm: add SPI flash support
> 
> Murali Karicheri (1):
>   spi/davinci: add DT binding documentation
> 
>  .../devicetree/bindings/spi/spi-davinci.txt        |   51 ++++++++++++++++++++
>  arch/arm/boot/dts/da850-evm.dts                    |   40 +++++++++++++++
>  arch/arm/boot/dts/da850.dtsi                       |   22 ++++++++
>  arch/arm/mach-davinci/da8xx-dt.c                   |    1 +
>  drivers/spi/spi-davinci.c                          |    4 +-
>  5 files changed, 116 insertions(+), 2 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/spi/spi-davinci.txt
> 
> -- 
> 1.7.4.1
> 
> 



From kuninori.morimoto.gx at renesas.com  Tue Apr  9 01:58:04 2013
From: kuninori.morimoto.gx at renesas.com (Kuninori Morimoto)
Date: Mon, 08 Apr 2013 22:58:04 -0700 (PDT)
Subject: [PATCH v2 0/9] Reorganize R8A7779/Marzen USB code
In-Reply-To: <201304090110.50154.sergei.shtylyov@cogentembedded.com>
References: <201304090110.50154.sergei.shtylyov@cogentembedded.com>
Message-ID: <87zjx89rfb.wl%kuninori.morimoto.gx@renesas.com>


Hi

>    Here's the set of 9 patches against the Simon Horman's 'renesas.git' repo,
> 'renesas-next-20130405v2' tag.  It was created to fix the shortcomings in the
> R8A7779/Marzen USB platform code and R8A7779 USB common PHY driver, and so
> spans both arch/arm/mach-shmobile/ and drivers/usb/ subtrees (some patches have
> to touch both subtrees). The patches were conceived with the complete
> bisectability goal in mind. The patches have been tested on the Marzen board.

Please add this "tested on xxx" comment on each patch's log area, not only on [0/x].
We need it on "git log"

> [1/9] ARM: shmobile: Marzen: move USB EHCI, OHCI, and PHY devices to R8A7779 code
> [2/9] ehci-platform: add pre_setup() method to platform data
> [3/9] ARM: shmobile: R8A7779: setup EHCI internal buffer
> [4/9] rcar-phy: remove EHCI internal buffer setup
> [5/9] ARM: shmobile: R8A7779: remove USB PHY 2nd memory resource
> [6/9] rcar-phy: correct base address
> [7/9] rcar-phy: add platform data
> [8/9] ARM: shmobile: Marzen: pass platform data to USB PHY device
> [9/9] rcar-phy: handle platform data

I didn't get [7/9][9/9] patch somehow

Best regards
---
Kuninori Morimoto


From dt.tangr at gmail.com  Tue Apr  9 01:59:52 2013
From: dt.tangr at gmail.com (Daniel Tang)
Date: Tue, 9 Apr 2013 15:59:52 +1000
Subject: [RFC PATCH arm: initial TI-Nspire support]
In-Reply-To: <op.wu8k5pwqu7prd4@fabians-laptop.fritz.box>
References: <6FE4B33E-A503-4A75-AEED-831CB2C06D83@gmail.com>
 <4B3FD561-84FC-40CD-B747-13851692D673@gmail.com>
 <521DFDFC-7E9E-47EA-ACDA-C91BBDC8454E@gmail.com>
 <201304072323.42173.arnd@arndb.de>
 <896CB251-17FC-4327-BA4E-A8FD9ED1BEC7@gmail.com>
 <op.wu8k5pwqu7prd4@fabians-laptop.fritz.box>
Message-ID: <29D8E742-C870-45AE-B102-13A477AE6419@gmail.com>


On 09/04/2013, at 5:16 AM, Fabian Vogt <fabian at ritter-vogt.de> wrote:

> The latest kernel it seems to get stuck at
> console_lock() in register_framebuffer (drivers/video/fbmem.c:1655)
> if the LCD-controller is enabled. (Early printk and serial console works fine)
> CONFIG_NO_HZ is not activated, it works completely.
> Could this be a kernel bug or is this an issue with our timer configuration?

Even with the CONFIG_NO_HZ option disabled, I've found that probing of our LCD hardware sometimes still fail with an error of -2.

Depending on how I arrange the device tree or the contents of the boot arguments or, as said, the CONFIG_NO_HZ option, I get different behaviours ranging from: 
 * Getting a -2 error during device probe (possibly due to a clock not being found).
 * LCD hardware is found but boot hangs right after the driver is initialised.
 * LCD hardware is apparently initialised correctly and text appears onscreen but user mode init hangs and I never get to a shell prompt.

This smells of a race condition that occurs before the clcd driver even gets to initialise. Some bug in our timer code? A OF or console bug perhaps? Though, I'm a bit hesitant to blame it on a kernel subsystem bug until it's clear that our code isn't at fault.

Any suggestions?

From tixy at linaro.org  Tue Apr  9 02:00:46 2013
From: tixy at linaro.org (Jon Medhurst (Tixy))
Date: Tue, 09 Apr 2013 07:00:46 +0100
Subject: [PATCH v4 15/15] ARM: vexpress: Select multi-cluster SMP
 operation if required
In-Reply-To: <alpine.LFD.2.03.1304090135590.1171@syhkavp.arg>
References: <1360041732-17936-1-git-send-email-nicolas.pitre@linaro.org>
 <1360041732-17936-16-git-send-email-nicolas.pitre@linaro.org>
 <20130405224819.GB14308@quad.lixom.net>
 <alpine.LFD.2.03.1304060943370.1171@syhkavp.arg>
 <1365412211.3384.16.camel@linaro1.home>
 <alpine.LFD.2.03.1304090135590.1171@syhkavp.arg>
Message-ID: <1365487246.3292.3.camel@computer5.home>

On Tue, 2013-04-09 at 01:41 -0400, Nicolas Pitre wrote:
> > Do the changes to the above mcpm files want to be in a separate patch as
> > it's generic ARM code, not vexpress specific?
> 
> Well, since it was so trivial I didn't do it, but the split might be a 
> good idea nevertheless.  So I inserted the following patch in the 
> series, and corresponding changes are now removed from the patch above.  
> What do you think?

Looks fine. Did you miss my other comment about smp_ops not looking like
they were getting set in the case of mcpm_smp_set_ops not getting
called?


> Author: Nicolas Pitre <nicolas.pitre at linaro.org>
> Date:   Tue Apr 9 01:29:17 2013 -0400
> 
>     ARM: mcpm: provide an interface to set the SMP ops at run time
>     
>     This is cleaner than exporting the mcpm_smp_ops structure.
>     
>     Signed-off-by: Nicolas Pitre <nico at linaro.org>
> 
> diff --git a/arch/arm/common/mcpm_platsmp.c b/arch/arm/common/mcpm_platsmp.c
> index 34f236af09..79ed70d846 100644
> --- a/arch/arm/common/mcpm_platsmp.c
> +++ b/arch/arm/common/mcpm_platsmp.c
> @@ -76,7 +76,7 @@ static void mcpm_cpu_die(unsigned int cpu)
>  
>  #endif
>  
> -struct smp_operations __initdata mcpm_smp_ops = {
> +static struct smp_operations __initdata mcpm_smp_ops = {
>  	.smp_init_cpus		= simple_smp_init_cpus,
>  	.smp_boot_secondary	= mcpm_boot_secondary,
>  	.smp_secondary_init	= mcpm_secondary_init,
> @@ -85,3 +85,8 @@ struct smp_operations __initdata mcpm_smp_ops = {
>  	.cpu_die		= mcpm_cpu_die,
>  #endif
>  };
> +
> +void __init mcpm_smp_set_ops(void)
> +{
> +	smp_set_ops(&mcpm_smp_ops);
> +}
> diff --git a/arch/arm/include/asm/mcpm_entry.h b/arch/arm/include/asm/mcpm_entry.h
> index 814623e6a1..34dfb86ff5 100644
> --- a/arch/arm/include/asm/mcpm_entry.h
> +++ b/arch/arm/include/asm/mcpm_entry.h
> @@ -190,5 +190,7 @@ int __mcpm_cluster_state(unsigned int cluster);
>  int __init mcpm_sync_init(
>  	void (*power_up_setup)(unsigned int affinity_level));
>  
> +void __init mcpm_smp_set_ops(void);
> +
>  #endif /* ! __ASSEMBLY__ */
>  #endif
> 

-- 
Tixy



From thomas.abraham at linaro.org  Tue Apr  9 02:07:01 2013
From: thomas.abraham at linaro.org (Thomas Abraham)
Date: Tue, 9 Apr 2013 11:37:01 +0530
Subject: [PATCH v3] mmc: dw_mmc: let device core setup the default pin
 configuration
In-Reply-To: <003501ce3453$502adf80$f0809e80$%jun@samsung.com>
References: <1365170015-3009-1-git-send-email-thomas.abraham@linaro.org>
 <003501ce3453$502adf80$f0809e80$%jun@samsung.com>
Message-ID: <CAJuYYwQmK=Lxw_+3GDHw=_c=3UJJNi0rcNjxNKPtDMPMw29YoQ@mail.gmail.com>

On 8 April 2013 17:49, Seungwon Jeon <tgih.jun at samsung.com> wrote:
> On Friday, April 05, 2013, Thomas Abraham wrote:
>> With device core now able to setup the default pin configuration,
>> the pin configuration code based on the deprecated Samsung specific
>> gpio bindings is removed.
>>
>> Signed-off-by: Thomas Abraham <thomas.abraham at linaro.org>
> Acked-by: Seungwon Jeon <tgih.jun at samsung.com>
>
> I hope that your another patch is merged.
>  ARM: dts: add pinctrl nodes for Exynos5250 SoC
> I didn't check whether it is applied.

Hi Seungwon,

Thanks for your Ack. Yes, the pinctrl nodes for Exynos5250 have been
merged through kgene's tree.

Regards,
Thomas.

>
> Thanks,
> Seungwon Jeon
>


From thomas.abraham at linaro.org  Tue Apr  9 02:08:27 2013
From: thomas.abraham at linaro.org (Thomas Abraham)
Date: Tue, 9 Apr 2013 11:38:27 +0530
Subject: [PATCH v3] mmc: dw_mmc: let device core setup the default pin
 configuration
In-Reply-To: <CAD=FV=U7kf_b92w7rDFkZN8Wr4sDTq5_=pMHaP948dT5CZbHsg@mail.gmail.com>
References: <1365170015-3009-1-git-send-email-thomas.abraham@linaro.org>
 <CAD=FV=U7kf_b92w7rDFkZN8Wr4sDTq5_=pMHaP948dT5CZbHsg@mail.gmail.com>
Message-ID: <CAJuYYwTAUnjwGsxfHho2jQXvkQfV2Kcvx-QfqCDqq7D7Fu0x7g@mail.gmail.com>

On 8 April 2013 21:38, Doug Anderson <dianders at google.com> wrote:
> Thomas,
>
> Since I commented on previous versions of this patch, I would have
> loved to have been CCed on this new version.  ;)

Hi Doug,

Sorry for missing out on CC'ing you in the v3 patch. It just slipped my mind.

>
> On Fri, Apr 5, 2013 at 6:53 AM, Thomas Abraham
> <thomas.abraham at linaro.org> wrote:
>> With device core now able to setup the default pin configuration,
>> the pin configuration code based on the deprecated Samsung specific
>> gpio bindings is removed.
>>
>> Signed-off-by: Thomas Abraham <thomas.abraham at linaro.org>
>> ---
>> Changes since v2:
>> - Changed patch subject from "mmc: dwmmc: let..." to "mmc: dw_mmc: let..."
>> - Rebased to Chris's latest mmc-next branch.
>>
>>  drivers/mmc/host/dw_mmc-exynos.c |   38 --------------------------------------
>>  drivers/mmc/host/dw_mmc.c        |   12 ++----------
>>  drivers/mmc/host/dw_mmc.h        |    3 ---
>>  3 files changed, 2 insertions(+), 51 deletions(-)
>
> This patch applies fine but fails to compile on linux-next
> "next-20130408".  You lost the race with:
>    f2f942c mmc: dw_mmc: Check return value of regulator_enable
>
> ...that patch adds a "goto err_setup_bus" and you've renamed that
> label.  I guess you get another fun rebase.
>
> NOTE: this patch is even more urgent than it was before.  It looks
> like pincontrol stuff has now landed in linux-next which means that
> Exynos5 devices that need eMMC/SD will no longer boot until this patch
> goes in.

Ok. I have posted the v4 version of this patch taking care of this.
Thanks for pointing this out.

Regards,
Thomas.

>
> -Doug


From santosh.shilimkar at ti.com  Tue Apr  9 02:13:50 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Tue, 9 Apr 2013 11:43:50 +0530
Subject: [PATCH v3 2/4] ARM: OMAP4+: PM: Consolidate OMAP4 PM code to
 re-use it for OMAP5
In-Reply-To: <20130408164228.GK10155@atomide.com>
References: <1365166743-5940-1-git-send-email-santosh.shilimkar@ti.com>
 <1365166743-5940-3-git-send-email-santosh.shilimkar@ti.com>
 <20130405213433.GF10155@atomide.com> <5162A093.7090808@ti.com>
 <20130408164228.GK10155@atomide.com>
Message-ID: <5163B19E.30105@ti.com>

On Monday 08 April 2013 10:12 PM, Tony Lindgren wrote:
> * Santosh Shilimkar <santosh.shilimkar at ti.com> [130408 03:51]:
>> On Saturday 06 April 2013 03:04 AM, Tony Lindgren wrote:
>>> * Santosh Shilimkar <santosh.shilimkar at ti.com> [130405 06:01]:
>>>> OMAP5 has backward compatible PRCM block and it's programming
>>>> model is mostly similar to OMAP4. Same is going to be maintained
>>>> for future OMAP4 based SOCs. Hence consolidate the OMAP4 power
>>>> management code so that it can be re-used on OMAP5 and later devices.
>>>>
>>>> While at it, update the kernel-doc for omap4_pm_init().
>>>>
>>>> Acked-by: Nishanth Menon <nm at ti.com>
>>>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
>>>> ---
>>>>  arch/arm/mach-omap2/Makefile                       |    9 +--
>>>>  arch/arm/mach-omap2/{pm44xx.c => pm_omap4plus.c}   |   58 ++++++++++++++++----
>>>>  .../mach-omap2/{sleep44xx.S => sleep_omap4plus.S}  |    0
>>>>  3 files changed, 53 insertions(+), 14 deletions(-)
>>>>  rename arch/arm/mach-omap2/{pm44xx.c => pm_omap4plus.c} (83%)
>>>>  rename arch/arm/mach-omap2/{sleep44xx.S => sleep_omap4plus.S} (100%)
>>>
>>> I suggest you leave out the rename. That just adds churn and has
>>> flame potential.
>>>
>> OK. I can leave that mow but have to do renames anyways when
>> I add OMAP5 support. OMAP54XX support inside pm44xx.c and sleep44x.S
>> will be really odd.
> 
> Well that should be just fine if the hardware is the same.
>  
>> Let me know if you have concern on renaming it while OMAP5 support
>> gets added ?
> 
> If the rename is done, it should have a clear reason to do it in
> a separate patch. IMHO it's just fine to have omap4 in some name and
> then assume that at least some follow up SoCs also use that code.
> In the worst case we may end up renaming things many times:
>
Agree. omap4_* is just fine and thats why many omap4_* are not renamed.
Here the files were calling specific family of OMAP4 i.e OMAP44XX and
hence the rename was appropriate.
 
> omap-xyz.c -> omap2-xyz.c -> omap2plus-xyz.c -> omap2-to-4-xyz.c ->
> omap2-to-4-and-am35xx-xyz.c etc :)
> 
pm_omap4plus.c and sleep_omap4plus.S was chosen specifically considering
the OMAP4+ devices share the PRCM IP. But PRCM_IP itself isn't new so
calling by IP wasn't an option.

> If we rename something, the description should have a clear reason
> for doing it like "To avoid confusing between PM code that does not
> have support for bootrom assisted off-idle on SMP omaps with PM code
> that's not bootrom assisted, let's rename foo to.."
> 
> For the naming, the only safe naming convention is to use something
> actually describing the piece of hardware. Maybe some combination
> of bootrom-assisted-off-idle + SMP in this case if there's no actual
> name for this hwblock?
> 
As I said, the IP has been there from OMAP2XX days. Here the case that
IP version is very similar between OMAP4, OMAP5. DRA(next SOC) and its
derivatives. Hence can share most of the code. I thought this was good
enough reason considering at least 4 family of SOC's can make use
of the code.

It has nothing to do with SMP etc specifically and rather the similarity
between the PM infrastructure on the mentioned SOCs. 

Let me know if you can suggested better name than what I chose ?

Regards,
Santosh


From santosh.shilimkar at ti.com  Tue Apr  9 02:52:24 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Tue, 9 Apr 2013 12:22:24 +0530
Subject: [RFC v2] dmaengine: omap-dma: Start DMA without delay for cyclic
 channels
In-Reply-To: <20130408171519.GP10155@atomide.com>
References: <1364987862-14597-1-git-send-email-peter.ujfalusi@ti.com>
 <51626D88.8020809@ti.com> <20130408170956.GX30923@n2100.arm.linux.org.uk>
 <20130408171519.GP10155@atomide.com>
Message-ID: <5163BAA8.7040502@ti.com>

On Monday 08 April 2013 10:45 PM, Tony Lindgren wrote:
> * Russell King - ARM Linux <linux at arm.linux.org.uk> [130408 10:15]:
>> On Mon, Apr 08, 2013 at 09:11:04AM +0200, Peter Ujfalusi wrote:
>>> Russell,
>>>
>>> On 04/03/2013 01:17 PM, Peter Ujfalusi wrote:
>>>> cyclic DMA is only used by audio which needs DMA to be started without a
>>>> delay.
>>>> If the DMA for audio is started using the tasklet we experience random
>>>> channel switch (to be more precise: channel shift).
>>>>
>>>> Reported-by: Peter Meerwald <pmeerw at pmeerw.net>
>>>> Signed-off-by: Peter Ujfalusi <peter.ujfalusi at ti.com>
>>>> ---
>>>> Hi Russell,
>>>>
>>>> Instead of removing the tasklet we can identify the DMA channel used by audio
>>>> based on the cyclic flag of the channel.
>>>> I think this can be used as a short term solution to fix the audio channel shift
>>>> issue and later when we have the dynamic DMA channel allocation we can adjust
>>>> the code.
>>>
>>> Could you, please look at this patch?
>>
>> Now that I'm back from a short 4 day break, then yes, and the answer is
>> that it's fine.  Who's handling the patch?
> 
> I suggest Peter resend the patch with also Grant + Linus W cc:d so
> they can queue it unless there are other related patches pending
> somewhere else.
> 
Am curious on your suggestion. DMA engine patches are going via Vinod
Koul's tree so I think the $subject patch should follow the same
tree, No ?

Peter, if you plan to re-send, feel free to add my ack.


Regards,
Santosh



From s.hauer at pengutronix.de  Tue Apr  9 02:58:22 2013
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Tue,  9 Apr 2013 08:58:22 +0200
Subject: [PATCH 1/2] ARM i.MX53: remove platform ahci support
Message-ID: <1365490703-1852-1-git-send-email-s.hauer@pengutronix.de>

The i.MX53 ahci platform support is unused in mainline. To demotivate
people using it just remove it from the tree.

Signed-off-by: Sascha Hauer <s.hauer at pengutronix.de>
---
 arch/arm/mach-imx/devices/Kconfig             |   4 -
 arch/arm/mach-imx/devices/Makefile            |   1 -
 arch/arm/mach-imx/devices/devices-common.h    |  10 --
 arch/arm/mach-imx/devices/platform-ahci-imx.c | 157 --------------------------
 4 files changed, 172 deletions(-)
 delete mode 100644 arch/arm/mach-imx/devices/platform-ahci-imx.c

diff --git a/arch/arm/mach-imx/devices/Kconfig b/arch/arm/mach-imx/devices/Kconfig
index 9b9ba1f..3dd2b1b 100644
--- a/arch/arm/mach-imx/devices/Kconfig
+++ b/arch/arm/mach-imx/devices/Kconfig
@@ -86,7 +86,3 @@ config IMX_HAVE_PLATFORM_SDHCI_ESDHC_IMX
 
 config IMX_HAVE_PLATFORM_SPI_IMX
 	bool
-
-config IMX_HAVE_PLATFORM_AHCI
-	bool
-	default y if ARCH_MX53
diff --git a/arch/arm/mach-imx/devices/Makefile b/arch/arm/mach-imx/devices/Makefile
index 6acf37e..67416fb 100644
--- a/arch/arm/mach-imx/devices/Makefile
+++ b/arch/arm/mach-imx/devices/Makefile
@@ -29,5 +29,4 @@ obj-$(CONFIG_IMX_HAVE_PLATFORM_MXC_RTC) += platform-mxc_rtc.o
 obj-$(CONFIG_IMX_HAVE_PLATFORM_MXC_W1) += platform-mxc_w1.o
 obj-$(CONFIG_IMX_HAVE_PLATFORM_SDHCI_ESDHC_IMX) += platform-sdhci-esdhc-imx.o
 obj-$(CONFIG_IMX_HAVE_PLATFORM_SPI_IMX) +=  platform-spi_imx.o
-obj-$(CONFIG_IMX_HAVE_PLATFORM_AHCI) +=  platform-ahci-imx.o
 obj-$(CONFIG_IMX_HAVE_PLATFORM_MX2_EMMA) += platform-mx2-emma.o
diff --git a/arch/arm/mach-imx/devices/devices-common.h b/arch/arm/mach-imx/devices/devices-common.h
index 9bd5777..453e20b 100644
--- a/arch/arm/mach-imx/devices/devices-common.h
+++ b/arch/arm/mach-imx/devices/devices-common.h
@@ -344,13 +344,3 @@ struct platform_device *imx_add_imx_dma(char *name, resource_size_t iobase,
 					int irq, int irq_err);
 struct platform_device *imx_add_imx_sdma(char *name,
 	resource_size_t iobase, int irq, struct sdma_platform_data *pdata);
-
-#include <linux/ahci_platform.h>
-struct imx_ahci_imx_data {
-	const char *devid;
-	resource_size_t iobase;
-	resource_size_t irq;
-};
-struct platform_device *__init imx_add_ahci_imx(
-		const struct imx_ahci_imx_data *data,
-		const struct ahci_platform_data *pdata);
diff --git a/arch/arm/mach-imx/devices/platform-ahci-imx.c b/arch/arm/mach-imx/devices/platform-ahci-imx.c
deleted file mode 100644
index 3d87dd9..0000000
--- a/arch/arm/mach-imx/devices/platform-ahci-imx.c
+++ /dev/null
@@ -1,157 +0,0 @@
-/*
- * Copyright (C) 2011 Freescale Semiconductor, Inc. All Rights Reserved.
- */
-
-/*
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
-
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
-
- * You should have received a copy of the GNU General Public License along
- * with this program; if not, write to the Free Software Foundation, Inc.,
- * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
- */
-
-#include <linux/io.h>
-#include <linux/clk.h>
-#include <linux/err.h>
-#include <linux/device.h>
-#include <linux/dma-mapping.h>
-#include <asm/sizes.h>
-
-#include "../hardware.h"
-#include "devices-common.h"
-
-#define imx_ahci_imx_data_entry_single(soc, _devid)		\
-	{								\
-		.devid = _devid,					\
-		.iobase = soc ## _SATA_BASE_ADDR,			\
-		.irq = soc ## _INT_SATA,				\
-	}
-
-#ifdef CONFIG_SOC_IMX53
-const struct imx_ahci_imx_data imx53_ahci_imx_data __initconst =
-	imx_ahci_imx_data_entry_single(MX53, "imx53-ahci");
-#endif
-
-enum {
-	HOST_CAP = 0x00,
-	HOST_CAP_SSS = (1 << 27), /* Staggered Spin-up */
-	HOST_PORTS_IMPL	= 0x0c,
-	HOST_TIMER1MS = 0xe0, /* Timer 1-ms */
-};
-
-static struct clk *sata_clk, *sata_ref_clk;
-
-/* AHCI module Initialization, if return 0, initialization is successful. */
-static int imx_sata_init(struct device *dev, void __iomem *addr)
-{
-	u32 tmpdata;
-	int ret = 0;
-	struct clk *clk;
-
-	sata_clk = clk_get(dev, "ahci");
-	if (IS_ERR(sata_clk)) {
-		dev_err(dev, "no sata clock.\n");
-		return PTR_ERR(sata_clk);
-	}
-	ret = clk_prepare_enable(sata_clk);
-	if (ret) {
-		dev_err(dev, "can't prepare/enable sata clock.\n");
-		goto put_sata_clk;
-	}
-
-	/* Get the AHCI SATA PHY CLK */
-	sata_ref_clk = clk_get(dev, "ahci_phy");
-	if (IS_ERR(sata_ref_clk)) {
-		dev_err(dev, "no sata ref clock.\n");
-		ret = PTR_ERR(sata_ref_clk);
-		goto release_sata_clk;
-	}
-	ret = clk_prepare_enable(sata_ref_clk);
-	if (ret) {
-		dev_err(dev, "can't prepare/enable sata ref clock.\n");
-		goto put_sata_ref_clk;
-	}
-
-	/* Get the AHB clock rate, and configure the TIMER1MS reg later */
-	clk = clk_get(dev, "ahci_dma");
-	if (IS_ERR(clk)) {
-		dev_err(dev, "no dma clock.\n");
-		ret = PTR_ERR(clk);
-		goto release_sata_ref_clk;
-	}
-	tmpdata = clk_get_rate(clk) / 1000;
-	clk_put(clk);
-
-	writel(tmpdata, addr + HOST_TIMER1MS);
-
-	tmpdata = readl(addr + HOST_CAP);
-	if (!(tmpdata & HOST_CAP_SSS)) {
-		tmpdata |= HOST_CAP_SSS;
-		writel(tmpdata, addr + HOST_CAP);
-	}
-
-	if (!(readl(addr + HOST_PORTS_IMPL) & 0x1))
-		writel((readl(addr + HOST_PORTS_IMPL) | 0x1),
-			addr + HOST_PORTS_IMPL);
-
-	return 0;
-
-release_sata_ref_clk:
-	clk_disable_unprepare(sata_ref_clk);
-put_sata_ref_clk:
-	clk_put(sata_ref_clk);
-release_sata_clk:
-	clk_disable_unprepare(sata_clk);
-put_sata_clk:
-	clk_put(sata_clk);
-
-	return ret;
-}
-
-static void imx_sata_exit(struct device *dev)
-{
-	clk_disable_unprepare(sata_ref_clk);
-	clk_put(sata_ref_clk);
-
-	clk_disable_unprepare(sata_clk);
-	clk_put(sata_clk);
-
-}
-struct platform_device *__init imx_add_ahci_imx(
-		const struct imx_ahci_imx_data *data,
-		const struct ahci_platform_data *pdata)
-{
-	struct resource res[] = {
-		{
-			.start = data->iobase,
-			.end = data->iobase + SZ_4K - 1,
-			.flags = IORESOURCE_MEM,
-		}, {
-			.start = data->irq,
-			.end = data->irq,
-			.flags = IORESOURCE_IRQ,
-		},
-	};
-
-	return imx_add_platform_device_dmamask(data->devid, 0,
-			res, ARRAY_SIZE(res),
-			pdata, sizeof(*pdata),  DMA_BIT_MASK(32));
-}
-
-struct platform_device *__init imx53_add_ahci_imx(void)
-{
-	struct ahci_platform_data pdata = {
-		.init = imx_sata_init,
-		.exit = imx_sata_exit,
-	};
-
-	return imx_add_ahci_imx(&imx53_ahci_imx_data, &pdata);
-}
-- 
1.8.2.rc2



From s.hauer at pengutronix.de  Tue Apr  9 02:58:23 2013
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Tue,  9 Apr 2013 08:58:23 +0200
Subject: [PATCH 2/2] ARM: i.MX: remove unused ARCH_* configs
In-Reply-To: <1365490703-1852-1-git-send-email-s.hauer@pengutronix.de>
References: <1365490703-1852-1-git-send-email-s.hauer@pengutronix.de>
Message-ID: <1365490703-1852-2-git-send-email-s.hauer@pengutronix.de>

From: Paul Bolle <pebolle at tiscali.nl>

This removes the unused Kconfig options ARCH_MX5, ARCH_MX51,
ARCH_MX53 and MACH_MX21.

Signed-off-by: Paul Bolle <pebolle at tiscali.nl>
Signed-off-by: Sascha Hauer <s.hauer at pengutronix.de>
---
 arch/arm/mach-imx/Kconfig | 18 ------------------
 1 file changed, 18 deletions(-)

diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index 4c9c6f9..6575e4e 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -83,24 +83,12 @@ config ARCH_MXC_IOMUX_V3
 config ARCH_MX1
 	bool
 
-config MACH_MX21
-	bool
-
 config ARCH_MX25
 	bool
 
 config MACH_MX27
 	bool
 
-config ARCH_MX5
-	bool
-
-config ARCH_MX51
-	bool
-
-config ARCH_MX53
-	bool
-
 config SOC_IMX1
 	bool
 	select ARCH_MX1
@@ -114,7 +102,6 @@ config SOC_IMX21
 	select COMMON_CLK
 	select CPU_ARM926T
 	select IMX_HAVE_IOMUX_V1
-	select MACH_MX21
 	select MXC_AVIC
 
 config SOC_IMX25
@@ -155,7 +142,6 @@ config SOC_IMX35
 config SOC_IMX5
 	bool
 	select ARCH_HAS_CPUFREQ
-	select ARCH_MX5
 	select ARCH_MXC_IOMUX_V3
 	select COMMON_CLK
 	select CPU_V7
@@ -163,8 +149,6 @@ config SOC_IMX5
 
 config	SOC_IMX51
 	bool
-	select ARCH_MX5
-	select ARCH_MX51
 	select PINCTRL
 	select PINCTRL_IMX51
 	select SOC_IMX5
@@ -789,8 +773,6 @@ comment "Device tree only"
 
 config	SOC_IMX53
 	bool "i.MX53 support"
-	select ARCH_MX5
-	select ARCH_MX53
 	select HAVE_CAN_FLEXCAN if CAN
 	select IMX_HAVE_PLATFORM_IMX2_WDT
 	select PINCTRL
-- 
1.8.2.rc2



From s.hauer at pengutronix.de  Tue Apr  9 02:59:16 2013
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Tue, 9 Apr 2013 08:59:16 +0200
Subject: [PATCH] ARM i.MX53: remove platform ahci support
In-Reply-To: <1365451383.1830.135.camel@x61.thuisdomein>
References: <1365431039.1830.102.camel@x61.thuisdomein>
 <1365450363-6582-1-git-send-email-s.hauer@pengutronix.de>
 <1365451383.1830.135.camel@x61.thuisdomein>
Message-ID: <20130409065916.GY1906@pengutronix.de>

On Mon, Apr 08, 2013 at 10:03:03PM +0200, Paul Bolle wrote:
> On Mon, 2013-04-08 at 21:46 +0200, Sascha Hauer wrote:
> > Paul, with this one applied you could also remove config ARCH_MX53.
> 
> Unless I'm doing something wrong, this doesn't apply onto v3.9-rc6. I
> guess it requires some other branch. But, assuming I don't get fed up
> with cleaning up Kconfig cruft, I will notice ARCH_MX53 getting unused
> when your patch hits mainline anyway.

I wanted to say that the patch could be extended with more cleanup.

> 
> But is there a reason you can't just remove ARCH_MX53 yourself?

Just did that.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From lee.jones at linaro.org  Tue Apr  9 03:05:58 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Tue, 9 Apr 2013 08:05:58 +0100
Subject: [PATCH 1/5] ARM: ux500: Move DMA40 platform data includes file
 out to include/
In-Reply-To: <201304081817.42031.arnd@arndb.de>
References: <1365434591-21569-1-git-send-email-lee.jones@linaro.org>
 <201304081817.42031.arnd@arndb.de>
Message-ID: <20130409070558.GG3084@gmail.com>

On Mon, 08 Apr 2013, Arnd Bergmann wrote:

> On Monday 08 April 2013, Lee Jones wrote:
> > The pin names for DB8500 based platforms need to be moved out of
> > ux500 platform data and into the new proper location in include/
> > linux/platform_data/. This way we an reference them from other
> > external locations, such as the main DMA50 driver(s).
> > 
> > Signed-off-by: Lee Jones <lee.jones at linaro.org>
> 
> Hmm, not sure about this one. The slave numbers are not really platform_data
> and I think they should not be exposed to drivers. It makes sense to
> keep the numbers for the memcpy channels in the driver itself as they
> are hardwired in the driver, but the slave channels should stay in the
> platform I think.

Just looking at this again now. So you're right in that the main
reason for moving these out of platform code and into the system-wide
platform data area is for the memcpy channels. However, I'd prefer to
keep the channel allocation enum fully contiguous rather than
splitting them out.

The channels are only exposed to the one external driver which
includes them, and that's the D40 driver.

How against this move are you?

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From lee.jones at linaro.org  Tue Apr  9 03:11:54 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Tue, 9 Apr 2013 08:11:54 +0100
Subject: [PATCH 4/5] dmaengine: ste_dma40: Do not configure channels during
 an channel allocation
In-Reply-To: <1365434591-21569-4-git-send-email-lee.jones@linaro.org>
References: <1365434591-21569-1-git-send-email-lee.jones@linaro.org>
 <1365434591-21569-4-git-send-email-lee.jones@linaro.org>
Message-ID: <20130409071154.GH3084@gmail.com>

According to the DMA documentation allocating a channel and configuring
it are two separate actions. By removing the configuration code from the
channel allocation path we lighten the burden on the information required to
successfully allocate a channel.

Cc: Vinod Koul <vinod.koul at intel.com>
Cc: Dan Williams <djbw at fb.com>
Cc: Per Forlin <per.forlin at stericsson.com>
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 drivers/dma/ste_dma40.c |    6 ------
 1 file changed, 6 deletions(-)

diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index ecca492..3543ea4 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -2471,16 +2471,10 @@ static int d40_alloc_chan_resources(struct dma_chan *chan)
 	}
 
 	pm_runtime_get_sync(d40c->base->dev);
-	/* Fill in basic CFG register values */
-	d40_phy_cfg(&d40c->dma_cfg, &d40c->src_def_cfg,
-		    &d40c->dst_def_cfg, chan_is_logical(d40c));
 
 	d40_set_prio_realtime(d40c);
 
 	if (chan_is_logical(d40c)) {
-		d40_log_cfg(&d40c->dma_cfg,
-			    &d40c->log_def.lcsp1, &d40c->log_def.lcsp3);
-
 		if (d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_MEM)
 			d40c->lcpa = d40c->base->lcpa_base +
 				d40c->dma_cfg.src_dev_type * D40_LCPA_CHAN_SIZE;
-- 
1.7.10.4


From peter.ujfalusi at ti.com  Tue Apr  9 03:19:31 2013
From: peter.ujfalusi at ti.com (Peter Ujfalusi)
Date: Tue, 9 Apr 2013 09:19:31 +0200
Subject: [RFC v2] dmaengine: omap-dma: Start DMA without delay for cyclic
 channels
In-Reply-To: <5163BAA8.7040502@ti.com>
References: <1364987862-14597-1-git-send-email-peter.ujfalusi@ti.com>
 <51626D88.8020809@ti.com> <20130408170956.GX30923@n2100.arm.linux.org.uk>
 <20130408171519.GP10155@atomide.com> <5163BAA8.7040502@ti.com>
Message-ID: <5163C103.8020101@ti.com>

On 04/09/2013 08:52 AM, Santosh Shilimkar wrote:
>> I suggest Peter resend the patch with also Grant + Linus W cc:d so
>> they can queue it unless there are other related patches pending
>> somewhere else.
>>
> Am curious on your suggestion. DMA engine patches are going via Vinod
> Koul's tree so I think the $subject patch should follow the same
> tree, No ?

AFAIK Vinod should be the correct person to pick it up, but I can CC Grant and
Linus W as well.

> Peter, if you plan to re-send, feel free to add my ack.

I'll figure out which stable release should have this applied and will resend.

-- 
P?ter


From peter.ujfalusi at ti.com  Tue Apr  9 03:19:52 2013
From: peter.ujfalusi at ti.com (Peter Ujfalusi)
Date: Tue, 9 Apr 2013 09:19:52 +0200
Subject: [RFC v2] dmaengine: omap-dma: Start DMA without delay for cyclic
 channels
In-Reply-To: <20130408170956.GX30923@n2100.arm.linux.org.uk>
References: <1364987862-14597-1-git-send-email-peter.ujfalusi@ti.com>
 <51626D88.8020809@ti.com> <20130408170956.GX30923@n2100.arm.linux.org.uk>
Message-ID: <5163C118.5000207@ti.com>

On 04/08/2013 07:09 PM, Russell King - ARM Linux wrote:
> Now that I'm back from a short 4 day break, then yes, and the answer is
> that it's fine.  Who's handling the patch?

Thank you,
P?ter


From peter.ujfalusi at ti.com  Tue Apr  9 03:21:40 2013
From: peter.ujfalusi at ti.com (Peter Ujfalusi)
Date: Tue, 9 Apr 2013 09:21:40 +0200
Subject: [RFC v2] dmaengine: omap-dma: Start DMA without delay for cyclic
 channels
In-Reply-To: <5163C118.5000207@ti.com>
References: <1364987862-14597-1-git-send-email-peter.ujfalusi@ti.com>
 <51626D88.8020809@ti.com> <20130408170956.GX30923@n2100.arm.linux.org.uk>
 <5163C118.5000207@ti.com>
Message-ID: <5163C184.1010200@ti.com>

Russell,

On 04/09/2013 09:19 AM, Peter Ujfalusi wrote:
> On 04/08/2013 07:09 PM, Russell King - ARM Linux wrote:
>> Now that I'm back from a short 4 day break, then yes, and the answer is
>> that it's fine.  Who's handling the patch?
> 
> Thank you,
> P?ter

Can I add you acked-by to the patch?

-- 
P?ter


From s.hauer at pengutronix.de  Tue Apr  9 03:33:18 2013
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Tue, 9 Apr 2013 09:33:18 +0200
Subject: [PATCH] mmc: mxcmmc: Fix bug when card is present during boot
In-Reply-To: <1365228811-10928-1-git-send-email-shc_work@mail.ru>
References: <1365228811-10928-1-git-send-email-shc_work@mail.ru>
Message-ID: <20130409073318.GF1906@pengutronix.de>

On Sat, Apr 06, 2013 at 10:13:31AM +0400, Alexander Shiyan wrote:
> This patch fixes bug when card is present during boot.
> Bug was introduced due commit "mmc: mxcmmc: fix bug that may block a
> data transfer forever". When a card is present "mxcmci_setup_data"
> function is executed, but the timer is not initialized.

Acked-by: Sascha Hauer <s.hauer at pengutronix.de>

Sascha

> 
> ...
> i.MX SDHC driver
> mmc0: SD Status: Invalid Allocation Unit size.
> mmc0: new SD card at address b368
> mmcblk0: mmc0:b368 SDC   1.91 GiB
> ------------[ cut here ]------------
> kernel BUG at kernel/timer.c:729!
> Internal error: Oops - BUG: 0 [#1] PREEMPT ARM
> CPU: 0    Not tainted  (3.9.0-rc5-next-20130404 #2)
> PC is at mod_timer+0x168/0x198
> LR is at mxcmci_request+0x21c/0x328
> pc : [<c0026d28>]    lr : [<c0261928>]    psr: 60000013
> sp : c7933df0  ip : 00001000  fp : 00000001
> r10: c0012edc  r9 : c7920400  r8 : c014f92c
> r7 : c7920600  r6 : ffff8f8f  r5 : ffff8f8f  r4 : c79206a4
> r3 : 00000000  r2 : 00000000  r1 : ffff8f8f  r0 : c79206a4
> Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
> Control: 0005317f  Table: a0004000  DAC: 00000017
> Process mmcqd/0 (pid: 450, stack limit = 0xc79321b8)
> Stack: (0xc7933df0 to 0xc7934000)
> 3de0:                                     c78260f8 00000000 00000001 c78dcce0
> 3e00: c78dcc2c 00000200 c7920600 c014f92c c0012edc c0261928 00000003 00000000
> 3e20: 00000000 c7874210 c78dc800 00000002 c790f720 c78dcc2c c7920400 00000001
> 3e40: c78dcd20 00000001 c7933ee4 00000000 c78dcc2c c02504f0 00000000 c7920400
> 3e60: 00000000 c0251588 c7a60138 c7920000 c78dcc2c c78dcc04 c78dcc00 00000000
> 3e80: 00000000 c025de34 c78dcc04 c7a60138 c78dcc28 c78dcc04 c7920000 c7a60138
> 3ea0: c7920400 c78dcc00 c78dcc2c c025ed3c c7933f44 00000000 c78dcc00 00000000
> 3ec0: 00000000 c0037af0 00000000 c7932000 40000013 c0250d50 c7933f6c 00000000
> 3ee0: c78cb6c0 c003f6b8 00100100 c7920000 c7a60138 c78dcc04 c78dcc00 120d0000
> 3f00: c7920400 c78dcc00 c78dcc0c c025f918 c7847d34 00000001 c7847d40 00000000
> 3f20: c7933f54 c78dcc04 c7a60138 c7932000 00000000 120d0000 c7996b80 00000001
> 3f40: c78dcc0c c0260410 00000000 c7847d2c 00000000 c78dcc04 c0260358 00000000
> 3f60: 00000000 00000000 00000000 c0037094 00000000 00000000 2d656761 c78dcc04
> 3f80: 00000000 c7933f84 c7933f84 00000000 c7933f90 c7933f90 c7933fac c7847d2c
> 3fa0: c0036ff0 00000000 00000000 c000e210 00000000 00000000 00000000 00000000
> 3fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> 3fe0: 00000000 00000000 00000000 00000000 00000013 00000000 7ffff1e5 ef7b8ff9
> [<c0026d28>] (mod_timer+0x168/0x198) from [<c0261928>] (mxcmci_request+0x21c/0x328)
> [<c0261928>] (mxcmci_request+0x21c/0x328) from [<c02504f0>] (mmc_start_request+0xc4/0xe8)
> [<c02504f0>] (mmc_start_request+0xc4/0xe8) from [<c0251588>] (mmc_start_req+0x2d0/0x380)
> [<c0251588>] (mmc_start_req+0x2d0/0x380) from [<c025ed3c>] (mmc_blk_issue_rw_rq+0xb4/0xaf0)
> [<c025ed3c>] (mmc_blk_issue_rw_rq+0xb4/0xaf0) from [<c025f918>] (mmc_blk_issue_rq+0x1a0/0x4ec)
> [<c025f918>] (mmc_blk_issue_rq+0x1a0/0x4ec) from [<c0260410>] (mmc_queue_thread+0xb8/0x150)
> [<c0260410>] (mmc_queue_thread+0xb8/0x150) from [<c0037094>] (kthread+0xa4/0xb0)
> [<c0037094>] (kthread+0xa4/0xb0) from [<c000e210>] (ret_from_fork+0x14/0x24)
> Code: e0065015 eaffffb3 e3a0a001 eaffffea (e7f001f2)
> ---[ end trace 29f2f8ea54d9d99e ]---
> 
> Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
> ---
>  drivers/mmc/host/mxcmmc.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/mmc/host/mxcmmc.c b/drivers/mmc/host/mxcmmc.c
> index a72936e..28e527e 100644
> --- a/drivers/mmc/host/mxcmmc.c
> +++ b/drivers/mmc/host/mxcmmc.c
> @@ -1052,12 +1052,12 @@ static int mxcmci_probe(struct platform_device *pdev)
>  			goto out_free_irq;
>  	}
>  
> -	mmc_add_host(mmc);
> -
>  	init_timer(&host->watchdog);
>  	host->watchdog.function = &mxcmci_watchdog;
>  	host->watchdog.data = (unsigned long)mmc;
>  
> +	mmc_add_host(mmc);
> +
>  	return 0;
>  
>  out_free_irq:
> -- 
> 1.8.1.5
> 
> 

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From linus.walleij at linaro.org  Tue Apr  9 03:37:40 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Tue, 9 Apr 2013 09:37:40 +0200
Subject: [PATCH 1/6] pinctrl: samsung: Protect bank registers with a
 spinlock
In-Reply-To: <1363642315-10331-2-git-send-email-tomasz.figa@gmail.com>
References: <1363642315-10331-1-git-send-email-tomasz.figa@gmail.com>
 <1363642315-10331-2-git-send-email-tomasz.figa@gmail.com>
Message-ID: <CACRpkdb9JUzTtxQa++jVJHCPM_ZaWUnO1pfi9=7oNpMuGnc+LQ@mail.gmail.com>

On Mon, Mar 18, 2013 at 10:31 PM, Tomasz Figa <tomasz.figa at gmail.com> wrote:

> Certain pin control registers can be accessed from different contexts,
> i.e. pinctrl, gpio and irq functions. This makes the locking provided by
> pin control core insufficient.
>
> This patch adds necessary locking using a per bank spinlock as it was
> done in the old Samsung GPIO driver.
>
> Signed-off-by: Tomasz Figa <tomasz.figa at gmail.com>

OK no reaction from the other Samsung maintainers so now I start
applying these...

Patch applied!

Yours,
Linus Walleij


From linus.walleij at linaro.org  Tue Apr  9 03:40:15 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Tue, 9 Apr 2013 09:40:15 +0200
Subject: [PATCH 2/6] pinctrl: samsung: Include pinctrl-exynos driver data
 conditionally
In-Reply-To: <1733680.zsxXgkCci5@flatron>
References: <1363642315-10331-1-git-send-email-tomasz.figa@gmail.com>
 <1363642315-10331-3-git-send-email-tomasz.figa@gmail.com>
 <1733680.zsxXgkCci5@flatron>
Message-ID: <CACRpkdb63vNQ_63NLPrK0mx=W4ecBeksY=GNMpJRLsAyzfb65A@mail.gmail.com>

On Mon, Mar 18, 2013 at 10:38 PM, Tomasz Figa <tomasz.figa at gmail.com> wrote:
> On Monday 18 of March 2013 22:31:51 Tomasz Figa wrote:
>> Since pinctrl-samsung is a common part of the pin control support for
>> several Samsung SoCs, it can be compiled without Exynos support enabled.
>>
>> This patch surrounds Exynos-specific driver data with ifdefs to include
>> them only when support for Exynos is enabled.
>>
>> Signed-off-by: Tomasz Figa <tomasz.figa at gmail.com>
>> ---
>>  drivers/pinctrl/pinctrl-samsung.c | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/pinctrl/pinctrl-samsung.c
>> b/drivers/pinctrl/pinctrl-samsung.c index b1d4ac8..f1fb562 100644
>> --- a/drivers/pinctrl/pinctrl-samsung.c
>> +++ b/drivers/pinctrl/pinctrl-samsung.c
>> @@ -968,10 +968,12 @@ static int samsung_pinctrl_probe(struct
>> platform_device *pdev) }
>>
>>  static const struct of_device_id samsung_pinctrl_dt_match[] = {
>> +#ifdef CONFIG_PINCTRL_EXYNOS4
>
> Oops... This should be CONFIG_PINCTRL_EXYNOS. It used to be EXYNOS4 in
> Kgene's tree (on which I usually base my patches) for some time, but it no
> longer is, but I forgot to change this during rebae.
>
> Linus, if remaining patches turned out to be OK, would you fix this when
> applying?

Fixed and applied.

Thanks!
Linus Walleij


From sfr at canb.auug.org.au  Tue Apr  9 03:40:47 2013
From: sfr at canb.auug.org.au (Stephen Rothwell)
Date: Tue, 9 Apr 2013 17:40:47 +1000
Subject: linux-next: manual merge of the arm-soc tree with the omap_dss2 tree
Message-ID: <20130409174047.c506479e08e9688c0a4ced9a@canb.auug.org.au>

Hi all,

Today's linux-next merge of the arm-soc tree got a conflict in
arch/arm/mach-omap2/board-2430sdp.c between commit 3b4ece75b9e9 ("arm:
omap: board-2430: use generic dpi panel's gpio handling") from the
omap_dss2 tree and commit 5b6513d27775 ("ARM: OMAP: fix typo
"CONFIG_SMC91x_MODULE"") from the arm-soc tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr at canb.auug.org.au

diff --cc arch/arm/mach-omap2/board-2430sdp.c
index e551aae,cb0596b..0000000
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@@ -135,7 -146,27 +135,7 @@@ static struct omap_dss_board_info sdp24
  	.default_device	= &sdp2430_lcd_device,
  };
  
- #if defined(CONFIG_SMC91X) || defined(CONFIG_SMC91x_MODULE)
 -static void __init sdp2430_display_init(void)
 -{
 -	int r;
 -
 -	static struct gpio gpios[] __initdata = {
 -		{ SDP2430_LCD_PANEL_ENABLE_GPIO, GPIOF_OUT_INIT_LOW,
 -			"LCD reset" },
 -		{ SDP2430_LCD_PANEL_BACKLIGHT_GPIO, GPIOF_OUT_INIT_LOW,
 -			"LCD Backlight" },
 -	};
 -
 -	r = gpio_request_array(gpios, ARRAY_SIZE(gpios));
 -	if (r) {
 -		pr_err("Cannot request LCD GPIOs, error %d\n", r);
 -		return;
 -	}
 -
 -	omap_display_init(&sdp2430_dss_data);
 -}
 -
+ #if IS_ENABLED(CONFIG_SMC91X)
  
  static struct omap_smc91x_platform_data board_smc91x_data = {
  	.cs		= 5,
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130409/fc3b5762/attachment-0001.sig>

From s.hauer at pengutronix.de  Tue Apr  9 03:41:35 2013
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Tue, 9 Apr 2013 09:41:35 +0200
Subject: [PATCH] i.MX PATA cleanup and i.MX51 support
In-Reply-To: <1365067509-10186-1-git-send-email-s.hauer@pengutronix.de>
References: <1365067509-10186-1-git-send-email-s.hauer@pengutronix.de>
Message-ID: <20130409074135.GB10373@pengutronix.de>

Hi Jeff,

Any comments to this series? Can you queue 1-4 for the next merge
window?

Sascha

On Thu, Apr 04, 2013 at 11:25:03AM +0200, Sascha Hauer wrote:
> The following contains some cleanup and devicetree support for the
> i.MX PATA driver. Also i.MX51 PATA support is added.
> 
> The first four patches should go via the ata tree, the others through
> arm-soc, they do not depend on each other.
> 
> Sascha
> 
> ----------------------------------------------------------------
> Sascha Hauer (6):
>       ata: i.MX PATA: Use devm_clk_get
>       ata: i.MX PATA: cleanup error path
>       ata: i.MX PATA: use void __iomem * for regs
>       ata: i.MX PATA: add devicetree support
>       ARM: i.MX5: Add PATA and SRTC clocks
>       ARM: i.MX51: Add PATA support
> 
>  Documentation/devicetree/bindings/ata/imx-pata.txt | 17 +++++++++
>  .../devicetree/bindings/clock/imx5-clock.txt       |  2 +
>  arch/arm/boot/dts/imx51.dtsi                       | 44 ++++++++++++++++++++++
>  arch/arm/mach-imx/clk-imx51-imx53.c                |  4 +-
>  drivers/ata/pata_imx.c                             | 36 +++++++++++++-----
>  5 files changed, 92 insertions(+), 11 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/ata/imx-pata.txt
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From linus.walleij at linaro.org  Tue Apr  9 03:41:52 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Tue, 9 Apr 2013 09:41:52 +0200
Subject: [PATCH 3/6] pinctrl: samsung: Split pin bank description into two
 structures
In-Reply-To: <1363642315-10331-4-git-send-email-tomasz.figa@gmail.com>
References: <1363642315-10331-1-git-send-email-tomasz.figa@gmail.com>
 <1363642315-10331-4-git-send-email-tomasz.figa@gmail.com>
Message-ID: <CACRpkdZewWoTT=EMd=pC_ESdRBU-O2q+syGvFX65WP9qEV9X_w@mail.gmail.com>

On Mon, Mar 18, 2013 at 10:31 PM, Tomasz Figa <tomasz.figa at gmail.com> wrote:

> This patch splits pin bank description into two structures, one
> describing bank type (currently only bitfield widths), which can be
> shared across multiple banks and second containing bank-specific
> parameters including a pointer to a bank type struct.
>
> It is a prerequisite for further patch removing the statically hardcoded
> register offsets, making it impossible to support SoCs with different
> set and order of pin control registers.
>
> Signed-off-by: Tomasz Figa <tomasz.figa at gmail.com>

Patch applied.

Yours,
Linus Walleij


From linus.walleij at linaro.org  Tue Apr  9 03:43:07 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Tue, 9 Apr 2013 09:43:07 +0200
Subject: [PATCH 4/6] pinctrl: samsung: Remove hardcoded register offsets
In-Reply-To: <1363642315-10331-5-git-send-email-tomasz.figa@gmail.com>
References: <1363642315-10331-1-git-send-email-tomasz.figa@gmail.com>
 <1363642315-10331-5-git-send-email-tomasz.figa@gmail.com>
Message-ID: <CACRpkdaAjhkg_Q+q9Jg+f9F_abbeYKs-sZcuTEZiDjd+rqCtpA@mail.gmail.com>

On Mon, Mar 18, 2013 at 10:31 PM, Tomasz Figa <tomasz.figa at gmail.com> wrote:

> This patch replaces statically hardcoded register offsets of Exynos SoCs
> with an array of register offsets in samsung_pin_bank_type struct.
>
> Thanks to this change, support for SoCs with other set and order of
> registers can be added (e.g. S3C24xx and S3C64xx).
>
> Signed-off-by: Tomasz Figa <tomasz.figa at gmail.com>

Patch applied.

Yours,
Linus Walleij


From linus.walleij at linaro.org  Tue Apr  9 03:44:43 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Tue, 9 Apr 2013 09:44:43 +0200
Subject: [PATCH 5/6] pinctrl: samsung: Handle banks with two configuration
 registers
In-Reply-To: <1363642315-10331-6-git-send-email-tomasz.figa@gmail.com>
References: <1363642315-10331-1-git-send-email-tomasz.figa@gmail.com>
 <1363642315-10331-6-git-send-email-tomasz.figa@gmail.com>
Message-ID: <CACRpkdYf3mAP-5MHj7n0Ug4nK1QrX3xbV3XVcUJs8w+8AtPVOw@mail.gmail.com>

On Mon, Mar 18, 2013 at 10:31 PM, Tomasz Figa <tomasz.figa at gmail.com> wrote:

> This patch adds support for banks that have more than one function
> configuration registers, e.g. some of the banks of S3C64xx SoCs.
>
> Signed-off-by: Tomasz Figa <tomasz.figa at gmail.com>

Patch applied.

Yours,
Linus Walleij


From p.zabel at pengutronix.de  Tue Apr  9 03:44:46 2013
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Tue, 09 Apr 2013 09:44:46 +0200
Subject: [PATCH 0/7] i.MX53 IPU + TVE patches
In-Reply-To: <20130408174016.GB30036@kroah.com>
References: <1365437078-22579-1-git-send-email-p.zabel@pengutronix.de>
 <20130408174016.GB30036@kroah.com>
Message-ID: <1365493486.4023.13.camel@pizza.hi.pengutronix.de>

Hi Greg,

Am Montag, den 08.04.2013, 10:40 -0700 schrieb Greg Kroah-Hartman:
> On Mon, Apr 08, 2013 at 06:04:31PM +0200, Philipp Zabel wrote:
> > Hi,
> > 
> > the following patches allow to use the integrated Television Encoder
> > (TVEv2) on the i.MX53 SoC as VGA output encoder for the IPU. This is
> > useful for the Freescale i.MX53-QSB and TQ MBa53 boards, which have
> > VGA and DVI-I connectors, respectively.
> > 
> > regards
> > Philipp
> > 
> > ---
> >  drivers/staging/imx-drm/Kconfig             |   7 +
> >  drivers/staging/imx-drm/Makefile            |   1 +
> >  drivers/staging/imx-drm/imx-drm-core.c      |  15 +-
> >  drivers/staging/imx-drm/imx-drm.h           |  14 +-
> >  drivers/staging/imx-drm/imx-tve.c           | 755 ++++++++++++++++++++++++++++
> >  drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h |   3 +
> >  drivers/staging/imx-drm/ipu-v3/ipu-dc.c     |  55 +-
> >  drivers/staging/imx-drm/ipu-v3/ipu-di.c     | 100 +++-
> >  drivers/staging/imx-drm/ipuv3-crtc.c        |  11 +-
> >  9 files changed, 932 insertions(+), 29 deletions(-)
> 
> That's a lot of new features being added here, yet no work seems to be
> happening to move this out of the staging tree.  What is left to do
> here, and why isn't that being worked on first, before stuff like this?

the IPU code could still use a bit of testing, and I hope adding
features like VGA output on common development boards will increase the
amount of scrutiny this code will get.
I expect the structure of the IPU drivers to change when the common
display framework gets introduced at last, also requiring changes to the
device tree bindings, and I'm a bit reluctant to push for mainline
proper while the bindings are still not clear.

regards
Philipp



From linus.walleij at linaro.org  Tue Apr  9 03:47:05 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Tue, 9 Apr 2013 09:47:05 +0200
Subject: [PATCH 6/6] pinctrl: Add pinctrl-s3c64xx driver
In-Reply-To: <1363642315-10331-7-git-send-email-tomasz.figa@gmail.com>
References: <1363642315-10331-1-git-send-email-tomasz.figa@gmail.com>
 <1363642315-10331-7-git-send-email-tomasz.figa@gmail.com>
Message-ID: <CACRpkdayk9fYJEyi8o0k96h9a4q_F6HOVE6SxnBx-pm2a95JYQ@mail.gmail.com>

On Mon, Mar 18, 2013 at 10:31 PM, Tomasz Figa <tomasz.figa at gmail.com> wrote:

> This patch adds pinctrl-s3c64xx driver which implements pin control
> interface for Samsung S3C64xx SoCs.
>
> Signed-off-by: Tomasz Figa <tomasz.figa at gmail.com>

Yes it's long over due that we fix up the S3C family, thanks a lot
for doing this Tomasz, and sorry for taking so long to review the
patches.

Patch applied!

Yours,
Linus Walleij


From sfr at canb.auug.org.au  Tue Apr  9 03:47:47 2013
From: sfr at canb.auug.org.au (Stephen Rothwell)
Date: Tue, 9 Apr 2013 17:47:47 +1000
Subject: linux-next: manual merge of the arm-soc tree with the gpio-lw tree
Message-ID: <20130409174747.873a9c9cad1cd6a4dbe4014f@canb.auug.org.au>

Hi all,

Today's linux-next merge of the arm-soc tree got a conflict in
drivers/gpio/gpio-vt8500.c between commit 808c513ee64b ("gpio/vt8500:
Convert to devm_ioremap_resource()") from the gpio-lw tree and commit
dc1010860b03 ("gpio: vt8500: Remove arch-vt8500 gpio driver") from the
arm-soc tree.

The latter removed the file, so I did that and can carry the fix as
necessary (no action is required).

-- 
Cheers,
Stephen Rothwell                    sfr at canb.auug.org.au
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130409/21456e74/attachment.sig>

From pebolle at tiscali.nl  Tue Apr  9 03:53:58 2013
From: pebolle at tiscali.nl (Paul Bolle)
Date: Tue, 09 Apr 2013 09:53:58 +0200
Subject: [PATCH] ARM i.MX53: remove platform ahci support
In-Reply-To: <20130409065916.GY1906@pengutronix.de>
References: <1365431039.1830.102.camel@x61.thuisdomein>
 <1365450363-6582-1-git-send-email-s.hauer@pengutronix.de>
 <1365451383.1830.135.camel@x61.thuisdomein>
 <20130409065916.GY1906@pengutronix.de>
Message-ID: <1365494038.1830.145.camel@x61.thuisdomein>

On Tue, 2013-04-09 at 08:59 +0200, Sascha Hauer wrote:
> I wanted to say that the patch could be extended with more cleanup.

I see. But as long as long as I can't convince myself that, say, some
Kconfig symbol really is unused, it's hard for me to actually suggest
the related cleaning up. Especially when I'm touching code that I know
nothing about (as I do in most of the cleanups I suggest).


Paul Bolle



From vinod.koul at intel.com  Tue Apr  9 03:26:00 2013
From: vinod.koul at intel.com (Vinod Koul)
Date: Tue, 9 Apr 2013 12:56:00 +0530
Subject: [RFC v2] dmaengine: omap-dma: Start DMA without delay for
 cyclic channels
In-Reply-To: <5163C103.8020101@ti.com>
References: <1364987862-14597-1-git-send-email-peter.ujfalusi@ti.com>
 <51626D88.8020809@ti.com>
 <20130408170956.GX30923@n2100.arm.linux.org.uk>
 <20130408171519.GP10155@atomide.com> <5163BAA8.7040502@ti.com>
 <5163C103.8020101@ti.com>
Message-ID: <20130409072600.GA31193@intel.com>

On Tue, Apr 09, 2013 at 09:19:31AM +0200, Peter Ujfalusi wrote:
> On 04/09/2013 08:52 AM, Santosh Shilimkar wrote:
> >> I suggest Peter resend the patch with also Grant + Linus W cc:d so
> >> they can queue it unless there are other related patches pending
> >> somewhere else.
> >>
> > Am curious on your suggestion. DMA engine patches are going via Vinod
> > Koul's tree so I think the $subject patch should follow the same
> > tree, No ?
> 
> AFAIK Vinod should be the correct person to pick it up, but I can CC Grant and
> Linus W as well.
Yes it should go thru dmaengine tree, sorry was travelling hence the delay, pls
resend the patch and I will do the needful
> 
> > Peter, if you plan to re-send, feel free to add my ack.
> 
> I'll figure out which stable release should have this applied and will resend.
> 
> -- 
> P?ter


From pebolle at tiscali.nl  Tue Apr  9 03:58:19 2013
From: pebolle at tiscali.nl (Paul Bolle)
Date: Tue, 09 Apr 2013 09:58:19 +0200
Subject: [PATCH 2/2] ARM: i.MX: remove unused ARCH_* configs
In-Reply-To: <1365490703-1852-2-git-send-email-s.hauer@pengutronix.de>
References: <1365490703-1852-1-git-send-email-s.hauer@pengutronix.de>
 <1365490703-1852-2-git-send-email-s.hauer@pengutronix.de>
Message-ID: <1365494299.1830.149.camel@x61.thuisdomein>

On Tue, 2013-04-09 at 08:58 +0200, Sascha Hauer wrote:
> This removes the unused Kconfig options ARCH_MX5, ARCH_MX51,
> ARCH_MX53 and MACH_MX21.

I see you added MACH_MX21 too. It recently popped in my treewide
searches and is indeed unused. Thanks!


Paul Bolle



From linus.walleij at linaro.org  Tue Apr  9 04:06:45 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Tue, 9 Apr 2013 10:06:45 +0200
Subject: [PATCH/RFC] ARM: shmobile: Disallow PINCTRL without GPIOLIB
In-Reply-To: <21658140.49USZQOU99@avalon>
References: <20130318135818.23765.51686.sendpatchset@w520>
 <7840344.mRAPGty7WD@avalon>
 <CANqRtoR+xVFx6ytvjcHxNcQ3X=avXs49-pR-XCr7ApqOq_WFRQ@mail.gmail.com>
 <21658140.49USZQOU99@avalon>
Message-ID: <CACRpkdZ9fSoQnF-MgRKi4PUhv56+CuraXhuVgUhLyHcoEnBPZg@mail.gmail.com>

On Tue, Mar 26, 2013 at 4:23 PM, Laurent Pinchart
<laurent.pinchart at ideasonboard.com> wrote:

>> About this issue, the fact that selecting PINCTRL without GPIO results
>> in compile error makes me think that something needs slight adjustment
>> in the PFC code.
>
> The above errors come from the pinctrl core (although the PFC driver might not
> compile either in this case). Linus, what's your opinion on this ? Do we want
> to support systems with pinctrl but without gpiolib ?

Yes. It is perfectly legal to have pin controllers that do not correlate
GPIO ranges.

Does commit 2afe8229687ec24cbc07e78449a588bb8b68f858
"pinctrl: core: add dependence of GPIOLIB"
by Haojian fix this issue?

Yours,
Linus Walleij


From sameo at linux.intel.com  Tue Apr  9 04:06:53 2013
From: sameo at linux.intel.com (Samuel Ortiz)
Date: Tue, 9 Apr 2013 10:06:53 +0200
Subject: [PATCH 08/10] drivers: mfd: use module_platform_driver_probe()
In-Reply-To: <1363266691-15757-10-git-send-email-fabio.porcedda@gmail.com>
References: <1363266691-15757-1-git-send-email-fabio.porcedda@gmail.com>
 <1363266691-15757-10-git-send-email-fabio.porcedda@gmail.com>
Message-ID: <20130409080653.GG24058@zurbaran>

Hi Fabio,

On Thu, Mar 14, 2013 at 02:11:29PM +0100, Fabio Porcedda wrote:
> This patch converts the drivers to use the
> module_platform_driver_probe() macro which makes the code smaller and
> a bit simpler.
> 
> Signed-off-by: Fabio Porcedda <fabio.porcedda at gmail.com>
> Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
> Cc: Linus Walleij <linus.walleij at linaro.org>
> Cc: Samuel Ortiz <sameo at linux.intel.com>
> Cc: linux-arm-kernel at lists.infradead.org
> ---
>  drivers/mfd/davinci_voicecodec.c | 12 +-----------
>  drivers/mfd/htc-pasic3.c         | 13 +------------
>  2 files changed, 2 insertions(+), 23 deletions(-)
Jingoo Han sent a larger patchset to convert many MFD drivers to
module_platform_driver_probe(), including htc-pasic3 and davinci_voicecodec.

See my mfd-next tree for more details.

Cheers,
Samuel.

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


From hvaibhav at ti.com  Tue Apr  9 04:07:37 2013
From: hvaibhav at ti.com (Hiremath, Vaibhav)
Date: Tue, 9 Apr 2013 08:07:37 +0000
Subject: [RFC PATCH 3/3] ARM: OMAP2+: Add command line parameter for
 debugSS module control
In-Reply-To: <20130408172936.GQ10155@atomide.com>
References: <hvaibhav@ti.com>
 <1362396957-30113-4-git-send-email-hvaibhav@ti.com>
 <20130408172936.GQ10155@atomide.com>
Message-ID: <79CD15C6BA57404B839C016229A409A83EC47BB2@DBDE01.ent.ti.com>


> -----Original Message-----
> From: Tony Lindgren [mailto:tony at atomide.com]
> Sent: Monday, April 08, 2013 11:00 PM
> To: Hiremath, Vaibhav
> Cc: linux-omap at vger.kernel.org; khilman at linaro.org; paul at pwsan.com;
> Nayak, Rajendra; linux-arm-kernel at lists.infradead.org
> Subject: Re: [RFC PATCH 3/3] ARM: OMAP2+: Add command line parameter
> for debugSS module control
> 
> Hi,
> 
> * hvaibhav at ti.com <hvaibhav at ti.com> [130304 03:40]:
> > From: Vaibhav Hiremath <hvaibhav at ti.com>
> >
> > Currently there is no clean mechanism to control debugSS module and
> > you have to always keep clocks enabled, either,
> >
> >     - By enabling it during boot as part of clk_init function.
> >     Or
> >     - By having HWMOD_INIT_NO_IDLE flag in hwmod data.
> >
> > Based on the discussion,
> > http://www.mail-archive.com/linux-omap at vger.kernel.org/msg81771.html
> >
> > This patch introduces new kernel parameter "omap_debugss_en",
> > which will allow user to control debugSS module enable/disable
> > part during boot-time.
> 
> I suggest you just make this part into a standard DT only
> device driver. That way the command line parsing and clock
> enabling can happen the normal way.
> 

That?s good idea, as we are moving towards DT only boot support.
Also, are you suggesting to have both command-line param and DT
Property for this?


> Is there any reason why this could not be a loadable module?
> 

Because we want to keep it enabled before late_initcall. As part of late_initcall
Clock/hwmod framework will start disabling unused modules, which will impact the
Debugs as well. Consider the case where this debugss is loaded as a module, the user
Will loose the JTAG connection until the module is loaded; and once module is
Loaded, he has to again re-connect to the debugss.


With only DT option the code will look like below, is this what you also have in your mind -

arch/arm/boot/dts/am33xx.dtsi:

	debugss: debugss at 4b000000 {
		compatible = "ti,debugss";
		ti,hwmods = "debugss";
		reg = <0x4b000000 1000000>;
		status = "disabled";	/* User need to enable it if he need JTAG connectivity*/
	};


arch/arm/mach-omap2/debugss.c:

	static int __init _omap2_debugss_enable(void)
	{
		struct device_node *np;
	
		np = of_find_matching_node(oh_name);
		if (!node || ! of_device_is_available()) {
			pr_err("debugss device is not found\n");
			return -ENODEV;
		}
		...
		hwmod lookup./setup/enable along with optional clock enable.
		...

	}
	device_initcall(_omap2_debugss_enable);

Thanks,
Vaibhav


From geert at linux-m68k.org  Tue Apr  9 04:08:12 2013
From: geert at linux-m68k.org (Geert Uytterhoeven)
Date: Tue, 9 Apr 2013 10:08:12 +0200
Subject: [PATCH V2] video: implement a simple framebuffer driver
In-Reply-To: <20130408171637.98b5ad1f867bcbda883af68b@linux-foundation.org>
References: <1365043183-28905-1-git-send-email-swarren@wwwdotorg.org>
 <20130408171637.98b5ad1f867bcbda883af68b@linux-foundation.org>
Message-ID: <CAMuHMdXm94FtmS-qMN6FGjtRs08xkZhmSmCU8Nfr1UgyTK5QEw@mail.gmail.com>

On Tue, Apr 9, 2013 at 2:16 AM, Andrew Morton <akpm at linux-foundation.org> wrote:
> On Wed,  3 Apr 2013 20:39:43 -0600 Stephen Warren <swarren at wwwdotorg.org> wrote:
>> A simple frame-buffer describes a raw memory region that may be rendered
>> to, with the assumption that the display hardware has already been set
>> up to scan out from that buffer.
>>
>> This is useful in cases where a bootloader exists and has set up the
>> display hardware, but a Linux driver doesn't yet exist for the display
>> hardware.
>>
>> ...
>>
>> +config FB_SIMPLE
>> +     bool "Simple framebuffer support"
>> +     depends on (FB = y) && OF
>
> It's sad that this simple little thing requires Open Firmware.  Could
> it be generalised in some way so that the small amount of setup info
> could be provided by other means (eg, module_param) or does the
> dependency go deeper than that?

Indeed. Instead of consolidating, we seem to get more of them: offb, vesafb,
efifb, ...

cfr. near the tail of drivers/video/Makefile (don't know about all of them):
 # Platform or fallback drivers go here
obj-$(CONFIG_FB_UVESA)            += uvesafb.o
obj-$(CONFIG_FB_VESA)             += vesafb.o
obj-$(CONFIG_FB_EFI)              += efifb.o
obj-$(CONFIG_FB_VGA16)            += vga16fb.o
obj-$(CONFIG_FB_OF)               += offb.o
obj-$(CONFIG_FB_BF537_LQ035)      += bf537-lq035.o
obj-$(CONFIG_FB_BF54X_LQ043)      += bf54x-lq043fb.o
obj-$(CONFIG_FB_BFIN_LQ035Q1)     += bfin-lq035q1-fb.o
obj-$(CONFIG_FB_BFIN_T350MCQB)    += bfin-t350mcqb-fb.o
obj-$(CONFIG_FB_BFIN_7393)        += bfin_adv7393fb.o
obj-$(CONFIG_FB_MX3)              += mx3fb.o
obj-$(CONFIG_FB_DA8XX)            += da8xx-fb.o
obj-$(CONFIG_FB_MXS)              += mxsfb.o
obj-$(CONFIG_FB_SSD1307)          += ssd1307fb.o

# the test framebuffer is last
obj-$(CONFIG_FB_VIRTUAL)          += vfb.o

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds


From hvaibhav at ti.com  Tue Apr  9 04:11:22 2013
From: hvaibhav at ti.com (Hiremath, Vaibhav)
Date: Tue, 9 Apr 2013 08:11:22 +0000
Subject: [RFC PATCH 0/3] ARM: OMAP2+: Add command line parameter for
 debugSS module control
In-Reply-To: <20130408173052.GR10155@atomide.com>
References: <hvaibhav@ti.com>
 <1362396957-30113-1-git-send-email-hvaibhav@ti.com>
 <79CD15C6BA57404B839C016229A409A83EC281C1@DBDE01.ent.ti.com>
 <20130408173052.GR10155@atomide.com>
Message-ID: <79CD15C6BA57404B839C016229A409A83EC47BD9@DBDE01.ent.ti.com>


> -----Original Message-----
> From: Tony Lindgren [mailto:tony at atomide.com]
> Sent: Monday, April 08, 2013 11:01 PM
> To: Hiremath, Vaibhav
> Cc: linux-omap at vger.kernel.org; khilman at linaro.org; paul at pwsan.com;
> Nayak, Rajendra; linux-arm-kernel at lists.infradead.org
> Subject: Re: [RFC PATCH 0/3] ARM: OMAP2+: Add command line parameter
> for debugSS module control
> 
> * Hiremath, Vaibhav <hvaibhav at ti.com> [130314 04:33]:
> > > From: Hiremath, Vaibhav
> > > This patch introduces new kernel parameter "omap_debugss_en",
> > > which will allow user to control debugSS module enable/disable
> > > part during boot-time.
> > >
> > > In case of OMAP3, the debugSS is part of EMU domain and
> > > is currently controlled by clock tree alone.
> > >
> > > In case of OMAP4, the debugSS is part of EMU domain and
> > > is currently controlled by clock tree, as MODULEMODE_SWCTRL
> > > is not defined for hwmod.
> > >
> > > In case of AM335x, the debugSS is in wakeup domain and is currently
> > > controlled through hwmod alone. Currently we keep it always
> enabled.
> >
> > Any comments or input on this patch series?
> 
> No comments on adding the clocks, but the enabling of
> them should be just a regular device driver.
> 

Thanks for review, on this patch I will add your Reviewed-by line on next version
Of the patch-series.

I have just responded my comment to the other mail on this, and based on
Your response we can conclude. 

Thanks,
Vaibhav
.



From andrew.murray at arm.com  Tue Apr  9 04:11:19 2013
From: andrew.murray at arm.com (Andrew Murray)
Date: Tue, 9 Apr 2013 09:11:19 +0100
Subject: [RFCv1 08/11] PCI: Introduce new MSI chip infrastructure
In-Reply-To: <CAErSpo42AFdKH2RKTxOaeJgCPrYD5KYkOs3UEBez8x8Bjmun5w@mail.gmail.com>
References: <1364316746-8702-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1364316746-8702-9-git-send-email-thomas.petazzoni@free-electrons.com>
 <CAErSpo42AFdKH2RKTxOaeJgCPrYD5KYkOs3UEBez8x8Bjmun5w@mail.gmail.com>
Message-ID: <20130409081119.GA30736@arm.com>

On Mon, Apr 08, 2013 at 11:28:58PM +0100, Bjorn Helgaas wrote:
> On Tue, Mar 26, 2013 at 10:52 AM, Thomas Petazzoni
> <thomas.petazzoni at free-electrons.com> wrote:
> > From: Thierry Reding <thierry.reding at avionic-design.de>
> >
> >  #endif /* LINUX_MSI_H */
> > diff --git a/include/linux/pci.h b/include/linux/pci.h
> > index 2461033a..6aca43ea 100644
> > --- a/include/linux/pci.h
> > +++ b/include/linux/pci.h
> > @@ -416,6 +416,7 @@ struct pci_bus {
> >         struct resource busn_res;       /* bus numbers routed to this bus */
> >
> >         struct pci_ops  *ops;           /* configuration access functions */
> > +       struct msi_chip *msi;           /* MSI controller */
> 
> "msi" seems like a too-generic name here; it suggests an interrupt or
> IRQ, not a controller.
> 
> I'm not sure this is the correct place for it.  Having it in the
> struct pci_bus means you need arch code to fill it in, e.g., you added
> it in mvebu_pcie_scan_bus() in patch 09/11.  There's no good way to do
> that for arches that use pci_scan_root_bus(), which is the direction
> I'd like to go.
> 
> I think it probably should go in sysdata instead.  That would mean you
> can't really do generic weak setup/tear-down functions, because they
> wouldn't know how to pull the MSI controller info out of the
> arch-specific sysdata.  But there are so many levels of weak-ness
> going on there, maybe it would be a good thing to get rid of one :)

But generic setup/tear-down functions would allow for architecture
independent MSI controllers. This would be useful for MSI controllers that
are unrelated to PCI host controllers or a specific architecture. It would
make drivers sit more comfortably in drivers/irqchip or drivers/pci/host. Also
having the msi_chip in struct pci_bus could allow there to exist multiple
MSI controllers on a PCI fabric and is consistent with pci_ops.

Assuming the MSI controller is represented in the device tree and there is a
relationship between the controller and the host bridge
(phandle/interrupt-parent) then as Thierry suggested[1] previously you could call
something like of_find_msi_chip_by_node(node) to locate an msi_chip from a
device node. Could this look up exist in pci_scan_root_bus via its struct
device.of_node? Perhaps pci_create_root_bus can be changed to take a parameter
for msi_chip alongside the ops parameter? The of_find_msi_chip_by_node could
walk up the device tree until it finds an MSI controller.

In the case where device tree isn't used - then I guess the weakly defined
arch_ callbacks would be replaced with the architectures existing
implementation. Or perhaps if MSI controllers are registered (msi_chip_add)
then pci_scan_root_bus could use the first controller it finds.

Also I believe pci_alloc_child_bus function would need to be changed to add
"b->msi = msi" to inherit msi_chip for child buses in the above patch?

Andrew Murray

[1] http://lkml.org/lkml/2013/3/25/67


From linus.walleij at linaro.org  Tue Apr  9 04:14:30 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Tue, 9 Apr 2013 10:14:30 +0200
Subject: [PATCH 1/3] pinctrl: exynos5440: fix probe failure due to missing
 pin-list in config nodes
In-Reply-To: <1364310754-3692-2-git-send-email-kgene.kim@samsung.com>
References: <1364310754-3692-1-git-send-email-kgene.kim@samsung.com>
 <1364310754-3692-2-git-send-email-kgene.kim@samsung.com>
Message-ID: <CACRpkdb6NDXqVicnRyQW8SPVHHo1hZ8OM57Ah3wmVwWWWp3+cg@mail.gmail.com>

On Tue, Mar 26, 2013 at 4:12 PM, Kukjin Kim <kgene.kim at samsung.com> wrote:

> From: Thomas Abraham <thomas.ab at samsung.com>
>
> The property 'samsung,exynos5440-pins' is optional in configuration nodes
> which are included in the Exynos5440 pin-controller device node. Fix the
> incorrect failure in driver probe if 'samsung,exynos5440-pins' property
> is not found in the configuration nodes.
>
> Signed-off-by: Thomas Abraham <thomas.ab at samsung.com>
> Cc: Linus Walleij <linus.walleij at linaro.org>
> Signed-off-by: Kukjin Kim <kgene.kim at samsung.com>

Patch applied!

Thanks,
Linus Walleij


From sameo at linux.intel.com  Tue Apr  9 04:14:40 2013
From: sameo at linux.intel.com (Samuel Ortiz)
Date: Tue, 9 Apr 2013 10:14:40 +0200
Subject: [PATCH v2] mfd: remove twelve unused Kconfig symbols
In-Reply-To: <1363770579.1390.82.camel@x61.thuisdomein>
References: <1363732701.1390.45.camel@x61.thuisdomein>
 <20130320082427.GB28775@opensource.wolfsonmicro.com>
 <1363770579.1390.82.camel@x61.thuisdomein>
Message-ID: <20130409081440.GI24058@zurbaran>

Hi Paul,

On Wed, Mar 20, 2013 at 10:09:39AM +0100, Paul Bolle wrote:
> Twelve Kconfig symbols, all related to WM8350, WM8351, and WM8352, are
> unused. Commit 19d57ed5a308472a02e773f33c03ad4cb2ec6a9 ("mfd: Remove
> custom wm8350 cache implementation") removed all their (actual) users.
> Remove these symbols too.
> 
> Signed-off-by: Paul Bolle <pebolle at tiscali.nl>
> Acked-by: Mark Brown <broonie at opensource.wolfsonmicro.com>
> ---
> 0) This version adds Mark's ACK. It is now also sent to the ARM
> maintainers, as Mark suggested.
> 
> 1) Still only eyeball tested.
> 
>  arch/arm/mach-imx/Kconfig     |  2 --
>  arch/arm/mach-s3c64xx/Kconfig |  3 ---
>  drivers/mfd/Kconfig           | 48 -------------------------------------------
>  3 files changed, 53 deletions(-)
Applied to my mfd-next tree, thanks.

Cheers,
Samuel.

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


From p.zabel at pengutronix.de  Tue Apr  9 04:16:08 2013
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Tue, 09 Apr 2013 10:16:08 +0200
Subject: [PATCH v6 1/8] dt: describe base reset signal binding
In-Reply-To: <515D84D6.8090107@gmail.com>
References: <1364488523-20310-1-git-send-email-p.zabel@pengutronix.de>
 <1364488523-20310-2-git-send-email-p.zabel@pengutronix.de>
 <515D84D6.8090107@gmail.com>
Message-ID: <1365495368.4023.29.camel@pizza.hi.pengutronix.de>

Hi Rob,

Am Donnerstag, den 04.04.2013, 08:49 -0500 schrieb Rob Herring:
> On 03/28/2013 11:35 AM, Philipp Zabel wrote:
> > From: Stephen Warren <swarren at nvidia.com>
> > 
> > This binding is intended to represent the hardware reset signals present
> > internally in most IC (SoC, FPGA, ...) designs.
> > It consists of a binding for a reset controller device (provider), and a
> > pair of properties, "resets" and "reset-names", to link a device node
> > (consumer) to its reset controller via phandle, similarly to the clock
> > and interrupt bindings.
> > 
> > The reset controller has all information necessary to reset the consumer
> > device. That could be provided via device tree, or it could be implemented
> > in hardware.
> > The aim is to enable device drivers to request a framework API to issue a
> > reset simply by providing their struct device pointer as the most common
> > case.
> > 
> > Signed-off-by: Stephen Warren <swarren at nvidia.com>
> > Signed-off-by: Philipp Zabel <p.zabel at pengutronix.de>
> > Reviewed-by: Shawn Guo <shawn.guo at linaro.org>
> > Reviewed-by: Marek Vasut <marex at denx.de>
> 
> Looks good.
> 
> Acked-by: Rob Herring <rob.herring at calxeda.com>

Thank you. I'll not add the Acked-by: line to the patch itself, if
that's ok, since Shawn already pulled it into his imx/soc branch.

regards
Philipp




From sameo at linux.intel.com  Tue Apr  9 04:16:48 2013
From: sameo at linux.intel.com (Samuel Ortiz)
Date: Tue, 9 Apr 2013 10:16:48 +0200
Subject: [PATCH v2] clk: add LP8788 clock driver
In-Reply-To: <A874F61F95741C4A9BA573A70FE3998F82E4AB29@DQHE02.ent.ti.com>
References: <A874F61F95741C4A9BA573A70FE3998F82E4AB29@DQHE02.ent.ti.com>
Message-ID: <20130409081648.GJ24058@zurbaran>

Hi Milo,

On Thu, Apr 04, 2013 at 01:34:37AM +0000, Kim, Milo wrote:
> Patch v2.
>   (a) Remove unnecessary 'is_enabled()' operation code.
>   (b) Add CLK_IGNORE_UNUSED flag.
>   (c) Add clock device detection code : lp8788_is_clk_device_ready()
>       If the device is not ready, return as -ENODEV on loading the driver.
> 
> Patch v1.
>   Initial patch
> 
> Signed-off-by: Milo(Woogyom) Kim <milo.kim at ti.com>
> ---
>  drivers/clk/Kconfig        |    7 ++
>  drivers/clk/Makefile       |    1 +
>  drivers/clk/clk-lp8788.c   |  160 ++++++++++++++++++++++++++++++++++++++++++++
>  drivers/mfd/lp8788.c       |    2 +
>  include/linux/mfd/lp8788.h |    1 +
>  5 files changed, 171 insertions(+)
>  create mode 100644 drivers/clk/clk-lp8788.c
For the MFD part:
Acked-by: Samuel Ortiz <sameo at linux.intel.com>

Cheers,
Samuel.

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


From nicolas.ferre at atmel.com  Tue Apr  9 04:17:59 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Tue, 9 Apr 2013 10:17:59 +0200
Subject: [GIT PULL] at91: DT changes for 3.10 #3
In-Reply-To: <1365094799-16940-1-git-send-email-nicolas.ferre@atmel.com>
References: <20130402184947.GA8015@quad.lixom.net>
 <1365094799-16940-1-git-send-email-nicolas.ferre@atmel.com>
Message-ID: <5163CEB7.5030806@atmel.com>

On 04/04/2013 06:59 PM, Nicolas Ferre :
> Arnd, Olof,
> 
> Here is the refreshed pull-request for AT91 that is dedicated to Device Tree
> modifications. It is stacked on the material that you already have
> for 3.10 in your arm-soc/at91/dt branch.
> Following our discussion with Arnd, I added the non-urgent patches that I
> already proposed too late for 3.9. I also included the moving of macb node
> and kept the original patch.
> 
> As Olof asked, I renamed the Aria board dts file: at91-ariag25.dts and placed
> it in the Makefile. I also took the advantage of this delay to stack two more
> DT related patches.

Ping?

I saw that you made an update to arm-soc yesterday, and maybe you have
forgotten this pull-request?

Thanks, bye,


> Thanks, best regards,
> 
> The following changes since commit 6901d947be5ba1245a0f63271355b95f9056a362:
> 
>   ARM: at91/at91sam9x5cm: add 1-wire chip on CM board (2013-03-21 16:07:15 +0100)
> 
> are available in the git repository at:
> 
>   git://github.com/at91linux/linux-at91.git tags/at91-dt
> 
> for you to fetch changes up to f10491fff07dcced77f8ab1b3bc1f8e18715bfb9:
> 
>   ARM: at91/at91sam9260.dtsi: fix u(s)art pinctrl encoding (2013-04-04 18:31:17 +0200)
> 
> ----------------------------------------------------------------
> One macb DT node move for 9x5 family: 9g15 doesn't
> have an Ethernet interface.
> Little fixes mainly related to at91sam9x5 DT, IIO ADC bindings,
> pinctrl for at91sam9260/g20 DT and the RTC addition.
> Addition of the Acme Systems Aria G25 board.
> 
> ----------------------------------------------------------------
> Douglas Gilbert (2):
>       ARM: at91: add Acme Systems Aria G25 board
>       ARM: at91/at91sam9260.dtsi: fix u(s)art pinctrl encoding
> 
> Ludovic Desroches (1):
>       ARM: at91: dts: add adc resolution stuff
> 
> Nicolas Ferre (5):
>       ARM: at91/at91sam9x5: add RTC node
>       ARM: at91/trivial: typos in compatible property
>       ARM: at91/trivial: fix model name for SAM9G15-EK
>       ARM: at91: remove partial parameter in bootargs for at91sam9x5ek.dtsi
>       ARM: at91/dt: fix macb node declaration
> 
>  arch/arm/boot/dts/Makefile          |   1 +
>  arch/arm/boot/dts/at91-ariag25.dts  | 171 +++++++++++++++++++++++++++++++++++
>  arch/arm/boot/dts/at91sam9260.dtsi  |  19 ++--
>  arch/arm/boot/dts/at91sam9g15.dtsi  |   2 +-
>  arch/arm/boot/dts/at91sam9g15ek.dts |   2 +-
>  arch/arm/boot/dts/at91sam9g25.dtsi  |   2 +-
>  arch/arm/boot/dts/at91sam9g25ek.dts |   9 ++
>  arch/arm/boot/dts/at91sam9g35.dtsi  |   2 +-
>  arch/arm/boot/dts/at91sam9g35ek.dts |   9 ++
>  arch/arm/boot/dts/at91sam9g45.dtsi  |   3 +
>  arch/arm/boot/dts/at91sam9x25.dtsi  |   2 +-
>  arch/arm/boot/dts/at91sam9x25ek.dts |  14 +++
>  arch/arm/boot/dts/at91sam9x35.dtsi  |   2 +-
>  arch/arm/boot/dts/at91sam9x35ek.dts |   9 ++
>  arch/arm/boot/dts/at91sam9x5.dtsi   |  10 ++
>  arch/arm/boot/dts/at91sam9x5ek.dtsi |   7 +-
>  16 files changed, 244 insertions(+), 20 deletions(-)
>  create mode 100644 arch/arm/boot/dts/at91-ariag25.dts
> 


-- 
Nicolas Ferre


From thierry.reding at avionic-design.de  Tue Apr  9 04:18:50 2013
From: thierry.reding at avionic-design.de (Thierry Reding)
Date: Tue, 9 Apr 2013 10:18:50 +0200
Subject: [RFCv1 08/11] PCI: Introduce new MSI chip infrastructure
In-Reply-To: <CAErSpo42AFdKH2RKTxOaeJgCPrYD5KYkOs3UEBez8x8Bjmun5w@mail.gmail.com>
References: <1364316746-8702-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1364316746-8702-9-git-send-email-thomas.petazzoni@free-electrons.com>
 <CAErSpo42AFdKH2RKTxOaeJgCPrYD5KYkOs3UEBez8x8Bjmun5w@mail.gmail.com>
Message-ID: <20130409081850.GB27255@avionic-0098.mockup.avionic-design.de>

On Mon, Apr 08, 2013 at 04:28:58PM -0600, Bjorn Helgaas wrote:
> On Tue, Mar 26, 2013 at 10:52 AM, Thomas Petazzoni
> <thomas.petazzoni at free-electrons.com> wrote:
> > From: Thierry Reding <thierry.reding at avionic-design.de>
> >
> > The new struct msi_chip is used to associated an MSI controller with a
> > PCI bus. It is automatically handed down from the root to its children
> > during bus enumeration.
> >
> > This patch provides default (weak) implementations for the architecture-
> > specific MSI functions (arch_setup_msi_irq(), arch_teardown_msi_irq()
> > and arch_msi_check_device()) which check if a PCI device's bus has an
> > attached MSI chip and forward the call appropriately.
> >
> > Signed-off-by: Thierry Reding <thierry.reding at avionic-design.de>
> > Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> > ---
> >  drivers/pci/msi.c   |   35 +++++++++++++++++++++++++++++++----
> >  drivers/pci/probe.c |    1 +
> >  include/linux/msi.h |   10 ++++++++++
> >  include/linux/pci.h |    1 +
> >  4 files changed, 43 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
> > index 00cc78c..fce3549 100644
> > --- a/drivers/pci/msi.c
> > +++ b/drivers/pci/msi.c
> > @@ -26,14 +26,41 @@
> >
> >  static int pci_msi_enable = 1;
> >
> > -/* Arch hooks */
> > +int __weak arch_setup_msi_irq(struct pci_dev *dev, struct msi_desc *desc)
> > +{
> > +       struct msi_chip *chip = dev->bus->msi;
> > +
> > +       if (chip && chip->setup_irq) {
> > +               int err;
> > +
> > +               err = chip->setup_irq(chip, dev, desc);
> > +               if (err < 0)
> > +                       return err;
> > +
> > +               irq_set_chip_data(desc->irq, chip);
> > +               return err;
> > +       }
> > +
> > +       return -EINVAL;
> > +}
> >
> > -#ifndef arch_msi_check_device
> > -int arch_msi_check_device(struct pci_dev *dev, int nvec, int type)
> > +void __weak arch_teardown_msi_irq(unsigned int irq)
> >  {
> > +       struct msi_chip *chip = irq_get_chip_data(irq);
> > +
> > +       if (chip && chip->teardown_irq)
> > +               chip->teardown_irq(chip, irq);
> > +}
> > +
> > +int __weak arch_msi_check_device(struct pci_dev *dev, int nvec, int type)
> 
> I like the replacement of "#ifndef arch_msi_check_device()" with a
> weak implementation here, but this only does half the job -- shouldn't
> we remove the powerpc "#define arch_msi_check_device
> arch_msi_check_device" at the same time?

Yes, there are a few things that can be done to cleanup the "mess"
around this subsequently. For instance I have a local patch which
completely removes the ARCH_SUPPORTS_MSI symbol because it isn't
useful after making the symbols weak. One other obvious item is to
convert more architectures to implement an MSI chip.

> And since we're touching all the check_device() implementations, maybe
> we could come up with a better name.  "check_device()" conveys
> absolutely no information about what we're checking or what the sense
> of the result is.  arch_msi_supported()?  pcibios_msi_supported()?  I
> guess it should be consistent with the other arch interfaces, so
> arch_*() is probably better.

At least on PowerPC the arch_msi_check_device() hook also refuses to
setup multiple MSI per device because it isn't supported. I can't think
of a better alternative than arch_msi_supported(), though so that's fine
with me.

Perhaps pcibios_msi_supported() wouldn't be so bad either. Other
architecture-specific functions already use that prefix (see the OF
support functions) and it might be good to settle on one convention for
consistency.

That said, the goal is to eventually get rid of all the arch_msi_*()
functions. The only reason they are still there is because I didn't want
to convert everything in one go. So I wanted to put the infrastructure
in place that we need to support multi-platform on ARM (which is given
by this generic MSI chip infrastructure). Later the remaining PCI
architectures can be converted to provide an msi_chip as well, at which
point the now weak implementations can become non-weak and be renamed to
something like pci_{setup,teardown,check}_msi() to make it more obvious
that they are generic.

> Maybe the ugly #ifdef-ery around arch_setup_msi_irqs,
> arch_teardown_msi_irqs, and arch_restore_msi_irqs could be cleaned up
> similarly?  Somebody worked pretty hard to obfuscate all that,
> probably before weak functions were available.

I think Andrew or Jason at one point commented whether they should be
allowed to be implemented by an MSI chip. If so we could use the same
approach as for the other functions.

> > diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> > index b494066..9307550 100644
> > --- a/drivers/pci/probe.c
> > +++ b/drivers/pci/probe.c
> > @@ -634,6 +634,7 @@ static struct pci_bus *pci_alloc_child_bus(struct pci_bus *parent,
> >
> >         child->parent = parent;
> >         child->ops = parent->ops;
> > +       child->msi = parent->msi;
> >         child->sysdata = parent->sysdata;
> >         child->bus_flags = parent->bus_flags;
> >
> > diff --git a/include/linux/msi.h b/include/linux/msi.h
> > index ce93a34..ea4a5be 100644
> > --- a/include/linux/msi.h
> > +++ b/include/linux/msi.h
> > @@ -58,5 +58,15 @@ extern int arch_setup_msi_irqs(struct pci_dev *dev, int nvec, int type);
> >  extern void arch_teardown_msi_irqs(struct pci_dev *dev);
> >  extern int arch_msi_check_device(struct pci_dev* dev, int nvec, int type);
> >
> > +struct msi_chip {
> > +       struct module *owner;
> > +       struct device *dev;
> > +
> > +       int (*setup_irq)(struct msi_chip *chip, struct pci_dev *dev,
> > +                        struct msi_desc *desc);
> > +       void (*teardown_irq)(struct msi_chip *chip, unsigned int irq);
> > +       int (*check_device)(struct msi_chip *chip, struct pci_dev *dev,
> > +                           int nvec, int type);
> 
> If we do end up adding interfaces like this (I'm not sure it will work
> -- see below), I think it would be better to pass just the pci_dev,
> not the "msi_chip, pci_dev" pair.  Passing both pointers avoids a
> cheap lookup in the caller, but it adds a way that two inseparable
> things can get out of sync.

Yes, that's a good idea and we can easily do that.

> > +};
> >
> >  #endif /* LINUX_MSI_H */
> > diff --git a/include/linux/pci.h b/include/linux/pci.h
> > index 2461033a..6aca43ea 100644
> > --- a/include/linux/pci.h
> > +++ b/include/linux/pci.h
> > @@ -416,6 +416,7 @@ struct pci_bus {
> >         struct resource busn_res;       /* bus numbers routed to this bus */
> >
> >         struct pci_ops  *ops;           /* configuration access functions */
> > +       struct msi_chip *msi;           /* MSI controller */
> 
> "msi" seems like a too-generic name here; it suggests an interrupt or
> IRQ, not a controller.

It's short and to the point. The bus abstraction doesn't really have any
interrupt functionality, has it? Even for PCI devices the MSI interrupt
number is actually stored in the .irq field, so I don't think it's too
generic. But if you insist I'll think of another name.

> I'm not sure this is the correct place for it.  Having it in the
> struct pci_bus means you need arch code to fill it in, e.g., you added
> it in mvebu_pcie_scan_bus() in patch 09/11.  There's no good way to do
> that for arches that use pci_scan_root_bus(), which is the direction
> I'd like to go.

We could add an argument to pci_scan_root_bus() to pass this information
in. It's a bit ugly but see below...

> I think it probably should go in sysdata instead.  That would mean you
> can't really do generic weak setup/tear-down functions, because they
> wouldn't know how to pull the MSI controller info out of the
> arch-specific sysdata.  But there are so many levels of weak-ness
> going on there, maybe it would be a good thing to get rid of one :)

Isn't putting more data into sysdata a step in the opposite direction of
where we want to go? I seem to remember some discussion about wanting to
consolidate the various architecture-specific implementations and move
more common code into the PCI core. If we handle the whole MSI business
in architecture-specific code we gain little to nothing compared to the
current situation.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130409/e25780af/attachment-0001.sig>

From p.zabel at pengutronix.de  Tue Apr  9 04:19:34 2013
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Tue, 09 Apr 2013 10:19:34 +0200
Subject: [GIT PULL v2] Reset controller API
Message-ID: <1365495574.4023.32.camel@pizza.hi.pengutronix.de>

Hi Olof,

I have added two fixes on top of the reset series at
git://git.pengutronix.de/git/pza/linux.git reset/for_v3.10.
Could you pull them in together with the rest?

The following changes since commit 8bb9660418e05bb1845ac1a2428444d78e322cc7:

  Linux 3.9-rc4 (2013-03-23 16:52:44 -0700)

are available in the git repository at:

  git://git.pengutronix.de/git/pza/linux.git reset/for_v3.10

for you to fetch changes up to fbdb93ecb869f02a5f8f145fa06a0984c415a7d4:

  Documentation: gpio-reset.txt: Fix 'initially-in-reset' example (2013-04-09 09:55:00 +0200)

They add a simple API for devices to request being reset by separate
reset controller hardware and implement the reset signal device tree
bindings proposed by Stephen Warren.
The patches have been discussed on the linux-arm-kernel list under the topic
"Reset controller API to reset IP modules on i.MX5 and i.MX6".

----------------------------------------------------------------
Dan Carpenter (1):
      reset: NULL deref on allocation failure

Fabio Estevam (1):
      Documentation: gpio-reset.txt: Fix 'initially-in-reset' example

Philipp Zabel (2):
      reset: Add reset controller API
      reset: Add driver for gpio-controlled reset pins

Stephen Warren (1):
      dt: describe base reset signal binding

 .../devicetree/bindings/reset/gpio-reset.txt       |  37 +++
 Documentation/devicetree/bindings/reset/reset.txt  |  75 ++++++
 drivers/Kconfig                                    |   2 +
 drivers/Makefile                                   |   3 +
 drivers/reset/Kconfig                              |  26 ++
 drivers/reset/Makefile                             |   2 +
 drivers/reset/core.c                               | 297
+++++++++++++++++++++
 drivers/reset/gpio-reset.c                         | 208
+++++++++++++++
 include/linux/reset-controller.h                   |  51 ++++
 include/linux/reset.h                              |  17 ++
 10 files changed, 718 insertions(+)
 create mode 100644
Documentation/devicetree/bindings/reset/gpio-reset.txt
 create mode 100644 Documentation/devicetree/bindings/reset/reset.txt
 create mode 100644 drivers/reset/Kconfig
 create mode 100644 drivers/reset/Makefile
 create mode 100644 drivers/reset/core.c
 create mode 100644 drivers/reset/gpio-reset.c
 create mode 100644 include/linux/reset-controller.h
 create mode 100644 include/linux/reset.h




From nicolas.ferre at atmel.com  Tue Apr  9 04:20:07 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Tue, 9 Apr 2013 10:20:07 +0200
Subject: [GIT PULL] at91: little cleanup for 3.10 #3
Message-ID: <1365495607-30320-1-git-send-email-nicolas.ferre@atmel.com>

Arnd, Olof,

Again more trivial cleanup for AT91. It is based on material already sent and
present in arm-soc/at91/cleanup2.

Thanks, best regards,

The following changes since commit e7619459d47a673af3433208a42f583af920e9db:

  ARM: at91: Fix typo in restart code panic message (2013-03-26 12:21:25 +0100)

are available in the git repository at:

  git://github.com/at91linux/linux-at91.git tags/at91-cleanup

for you to fetch changes up to 3aa630b3e6be83c4e91a68537fe6edf80f8d295e:

  ARM: at91: remove trailing semicolon from macros (2013-04-08 17:47:44 +0200)

----------------------------------------------------------------
Trivial typos and some macros removal & modification

----------------------------------------------------------------
Johan Hovold (2):
      ARM: at91/setup: fix trivial typos
      ARM: at91: remove trailing semicolon from macros

Nicolas Ferre (1):
      ARM: at91: remove unused dbgu_readl() macro

 arch/arm/mach-at91/at91_rstc.h                | 2 +-
 arch/arm/mach-at91/at91_shdwc.h               | 2 +-
 arch/arm/mach-at91/at91x40_time.c             | 2 +-
 arch/arm/mach-at91/include/mach/at91_dbgu.h   | 3 ---
 arch/arm/mach-at91/include/mach/at91_matrix.h | 2 +-
 arch/arm/mach-at91/include/mach/at91_st.h     | 2 +-
 arch/arm/mach-at91/setup.c                    | 6 +++---
 7 files changed, 8 insertions(+), 11 deletions(-)

-- 
Nicolas Ferre


From sameo at linux.intel.com  Tue Apr  9 04:20:46 2013
From: sameo at linux.intel.com (Samuel Ortiz)
Date: Tue, 9 Apr 2013 10:20:46 +0200
Subject: [PATCH] mfd: ab8500-core: Ignore masked out interrupts
In-Reply-To: <1363873784-27378-1-git-send-email-fabio.baltieri@linaro.org>
References: <1363873784-27378-1-git-send-email-fabio.baltieri@linaro.org>
Message-ID: <20130409082046.GK24058@zurbaran>

Hi Fabio,

On Thu, Mar 21, 2013 at 02:49:44PM +0100, Fabio Baltieri wrote:
> AB8500 asserts LATCH bits for masked out interrupts.  This patch
> explicitly masks those out using the cached mask value to prevent
> handle_nested_irq() being called for masked IRQ on the same register as
> unmasked ones.
> 
> Acked-by: Linus Walleij <linus.walleij at linaro.org>
> Signed-off-by: Fabio Baltieri <fabio.baltieri at linaro.org>
> ---
> 
> Hello Samuel, Anton,
> 
> this is a small fix for the AB8500 irq generation code.  As this depends
> on Lee's patches already merged in the battery tree, this patch is based
> on Anton's repository, and should apply cleanly on it and on next.
As Lee prepared a branch for Anton and me to pull from, this patch applied
cleanly on top of mfd-next. So I took it and pushed it now.

Cheers,
Samuel.

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


From thierry.reding at avionic-design.de  Tue Apr  9 04:22:33 2013
From: thierry.reding at avionic-design.de (Thierry Reding)
Date: Tue, 9 Apr 2013 10:22:33 +0200
Subject: [RFCv1 08/11] PCI: Introduce new MSI chip infrastructure
In-Reply-To: <20130409081119.GA30736@arm.com>
References: <1364316746-8702-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1364316746-8702-9-git-send-email-thomas.petazzoni@free-electrons.com>
 <CAErSpo42AFdKH2RKTxOaeJgCPrYD5KYkOs3UEBez8x8Bjmun5w@mail.gmail.com>
 <20130409081119.GA30736@arm.com>
Message-ID: <20130409082232.GC27255@avionic-0098.mockup.avionic-design.de>

On Tue, Apr 09, 2013 at 09:11:19AM +0100, Andrew Murray wrote:
[...]
> Also I believe pci_alloc_child_bus function would need to be changed to add
> "b->msi = msi" to inherit msi_chip for child buses in the above patch?

The patch already does:

	child->msi = parent->msi;

in pci_alloc_child_bus(), the same way that ops is inherited. I have
admittedly only tested this code on Tegra, but I don't see why that
wouldn't be enough. Or maybe I haven't understood your question?

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130409/99b8cee1/attachment.sig>

From linus.walleij at linaro.org  Tue Apr  9 04:23:03 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Tue, 9 Apr 2013 10:23:03 +0200
Subject: [PATCH 2/3] pinctrl: exynos5440: add gpio interrupt support
In-Reply-To: <1364310754-3692-3-git-send-email-kgene.kim@samsung.com>
References: <1364310754-3692-1-git-send-email-kgene.kim@samsung.com>
 <1364310754-3692-3-git-send-email-kgene.kim@samsung.com>
Message-ID: <CACRpkdbEUe1NkOY7wR2FU+0Y=D5Qd=Lu2Zvv=TPBBCbWja0HMQ@mail.gmail.com>

On Tue, Mar 26, 2013 at 4:12 PM, Kukjin Kim <kgene.kim at samsung.com> wrote:

> From: Thomas Abraham <thomas.ab at samsung.com>
>
> Exynos5440 supports gpio interrupts on gpios 16 to 23. The eight interrupt lines
> originating from the pin-controller are connected to the gic. Add irq-chip support
> for these interrupts.
>
> Signed-off-by: Thomas Abraham <thomas.ab at samsung.com>
> Cc: Linus Walleij <linus.walleij at linaro.org>
> Signed-off-by: Kukjin Kim <kgene.kim at samsung.com>

Basically really nice. Patch has been applied, but some comments
for future reference:

> +/* gpiolib gpio_to_irq callback function */
> +static int exynos5440_gpio_to_irq(struct gpio_chip *gc, unsigned offset)
> +{
> +       struct exynos5440_pinctrl_priv_data *priv = dev_get_drvdata(gc->dev);
> +       unsigned int virq;

I'm a bit annoyed by use of the abbreviation "virq" as if the IRQs were
"virtual", they are not - this implies that the Linux IRQ numbers are not
"real" or something.

I use the nomenclature:

irq = Linux IRQ
hwirq = whatever offset that IRQ has in the hardware IRQ controller.

virq I think is confusing...

> +static irqreturn_t exynos5440_gpio_irq(int irq, void *data)
> +{
> +       struct exynos5440_gpio_intr_data *intd = data;
> +       struct exynos5440_pinctrl_priv_data *d = intd->priv;
> +       int virq;
> +
> +       virq = irq_linear_revmap(d->irq_domain, intd->gpio_int);
> +       if (!virq)
> +               return IRQ_NONE;
> +       generic_handle_irq(virq);
> +       return IRQ_HANDLED;
> +}

Same here. Actually, I guess irq_linear_revmap works here,
but irq_find_mapping(domain, hwirq) is more archaic, could
you test if that works as well and make a follow-up patch to
change it?

Yours,
Linus Walleij


From linus.walleij at linaro.org  Tue Apr  9 04:24:23 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Tue, 9 Apr 2013 10:24:23 +0200
Subject: [PATCH 3/3] ARM: dts: list the interrupts generated by
 pin-controller on Exynos5440
In-Reply-To: <1364310754-3692-4-git-send-email-kgene.kim@samsung.com>
References: <1364310754-3692-1-git-send-email-kgene.kim@samsung.com>
 <1364310754-3692-4-git-send-email-kgene.kim@samsung.com>
Message-ID: <CACRpkdZ8kftvKP2-a4A5q+x545urjmhevtHjtL+SXnnN=0H83Q@mail.gmail.com>

On Tue, Mar 26, 2013 at 4:12 PM, Kukjin Kim <kgene.kim at samsung.com> wrote:

> From: Thomas Abraham <thomas.ab at samsung.com>
>
> Exynos5440 pin-controller generates eight interrupts to support gpio
> interrupts. List those interrupt numbers in the pin-controller node.
>
> Signed-off-by: Thomas Abraham <thomas.ab at samsung.com>
> Cc: Linus Walleij <linus.walleij at linaro.org>
> Signed-off-by: Kukjin Kim <kgene.kim at samsung.com>

Acked-by: Linus Walleij <linus.walleij at linaro.org>

I guess this will go into the Exynos tree?

Tell me if you want me to apply it to the pinctrl tree.

Yours,
Linus Walleij


From andrew.murray at arm.com  Tue Apr  9 04:25:32 2013
From: andrew.murray at arm.com (Andrew Murray)
Date: Tue, 9 Apr 2013 09:25:32 +0100
Subject: [RFCv1 08/11] PCI: Introduce new MSI chip infrastructure
In-Reply-To: <20130409082232.GC27255@avionic-0098.mockup.avionic-design.de>
References: <1364316746-8702-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1364316746-8702-9-git-send-email-thomas.petazzoni@free-electrons.com>
 <CAErSpo42AFdKH2RKTxOaeJgCPrYD5KYkOs3UEBez8x8Bjmun5w@mail.gmail.com>
 <20130409081119.GA30736@arm.com>
 <20130409082232.GC27255@avionic-0098.mockup.avionic-design.de>
Message-ID: <20130409082532.GA31140@arm.com>

On Tue, Apr 09, 2013 at 09:22:33AM +0100, Thierry Reding wrote:
> On Tue, Apr 09, 2013 at 09:11:19AM +0100, Andrew Murray wrote:
> [...]
> > Also I believe pci_alloc_child_bus function would need to be changed to add
> > "b->msi = msi" to inherit msi_chip for child buses in the above patch?
> 
> The patch already does:
> 
> 	child->msi = parent->msi;
> 
> in pci_alloc_child_bus(), the same way that ops is inherited. I have
> admittedly only tested this code on Tegra, but I don't see why that
> wouldn't be enough. Or maybe I haven't understood your question?

Sorry I missed that part of your patch - that was exacatly what I was
hoping to see.

Andrew Murray


From ohad at wizery.com  Tue Apr  9 04:25:46 2013
From: ohad at wizery.com (Ohad Ben-Cohen)
Date: Tue, 9 Apr 2013 11:25:46 +0300
Subject: [PATCH v9 1/6] rpmsg: Process all available messages in virtqueue
 callback
In-Reply-To: <13514BD7FAEBA745BBD7D8A672905C1431230345@DFLE12.ent.ti.com>
References: <1364521307-1219-1-git-send-email-rtivy@ti.com>
 <1364521307-1219-2-git-send-email-rtivy@ti.com>
 <CAK=WgbaCtACsvt9cqQmGqXsADFb_3bfnNKeWq9iijR2vkYVuQQ@mail.gmail.com>
 <13514BD7FAEBA745BBD7D8A672905C1431230345@DFLE12.ent.ti.com>
Message-ID: <CAK=WgbbpJuh8M4FLEgQKzbOPadJFHO=gvpA2jVOrN5N1g=1f2w@mail.gmail.com>

On Tue, Apr 9, 2013 at 1:56 AM, Tivy, Robert <rtivy at ti.com> wrote:
> Shouldn't the virtqueue_kick() be called only when we successfully added a buffer with virtqueue_add_buf()?

Definitely, thanks for noticing!

Take 2:

diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c b/drivers/rpmsg/virtio_rpmsg_bus.c
index a59684b..4ade672 100644
--- a/drivers/rpmsg/virtio_rpmsg_bus.c
+++ b/drivers/rpmsg/virtio_rpmsg_bus.c
@@ -776,22 +776,11 @@ out:
 }
 EXPORT_SYMBOL(rpmsg_send_offchannel_raw);

-/* called when an rx buffer is used, and it's time to digest a message */
-static void rpmsg_recv_done(struct virtqueue *rvq)
+static int rpmsg_recv_single(struct virtproc_info *vrp, struct device *dev,
+                            struct rpmsg_hdr *msg, unsigned int len)
 {
-       struct rpmsg_hdr *msg;
-       unsigned int len;
        struct rpmsg_endpoint *ept;
        struct scatterlist sg;
-       struct virtproc_info *vrp = rvq->vdev->priv;
-       struct device *dev = &rvq->vdev->dev;
-       int err;
-
-       msg = virtqueue_get_buf(rvq, &len);
-       if (!msg) {
-               dev_err(dev, "uhm, incoming signal, but no used buffer ?\n");
-               return;
-       }

        dev_dbg(dev, "From: 0x%x, To: 0x%x, Len: %d, Flags: %d, Reserved: %d\n",
                                        msg->src, msg->dst, msg->len,
@@ -806,7 +795,7 @@ static void rpmsg_recv_done(struct virtqueue *rvq)
        if (len > RPMSG_BUF_SIZE ||
                msg->len > (len - sizeof(struct rpmsg_hdr))) {
                dev_warn(dev, "inbound msg too big: (%d, %d)\n", len, msg->len);
-               return;
+               return -EINVAL;
        }

        /* use the dst addr to fetch the callback of the appropriate user */
@@ -842,11 +831,42 @@ static void rpmsg_recv_done(struct virtqueue *rvq)
        err = virtqueue_add_buf(vrp->rvq, &sg, 0, 1, msg, GFP_KERNEL);
        if (err < 0) {
                dev_err(dev, "failed to add a virtqueue buffer: %d\n", err);
+               return err;
+       }
+
+       return 0;
+}
+
+/* called when an rx buffer is used, and it's time to digest a message */
+static void rpmsg_recv_done(struct virtqueue *rvq)
+{
+       struct virtproc_info *vrp = rvq->vdev->priv;
+       struct device *dev = &rvq->vdev->dev;
+       struct rpmsg_hdr *msg;
+       unsigned int len, msgs_received = 0;
+       int err;
+
+       msg = virtqueue_get_buf(rvq, &len);
+       if (!msg) {
+               dev_err(dev, "uhm, incoming signal, but no used buffer ?\n");
                return;
        }

+       while (msg) {
+               err = rpmsg_recv_single(vrp, dev, msg, len);
+               if (err)
+                       break;
+
+               msgs_received++;
+
+               msg = virtqueue_get_buf(rvq, &len);
+       };
+
+       dev_dbg(dev, "Received %u messages\n", msgs_received);
+
        /* tell the remote processor we added another available rx buffer */
-       virtqueue_kick(vrp->rvq);
+       if (msgs_received)
+               virtqueue_kick(vrp->rvq);
 }

 /*

> Thanks for the rewrite, looks better.  I'll give it a try and let you know how it goes.

Thanks!
Ohad.


From javier at dowhile0.org  Tue Apr  9 04:26:38 2013
From: javier at dowhile0.org (Javier Martinez Canillas)
Date: Tue, 9 Apr 2013 10:26:38 +0200
Subject: [PATCH 1/1] of/irq: store IRQ trigger/level in struct resource
 flags
In-Reply-To: <516380D7.3060000@gmail.com>
References: <1365148088-11175-1-git-send-email-javier.martinez@collabora.co.uk>
 <51633F26.7000400@gmail.com> <516341AF.7030207@wwwdotorg.org>
 <51634B1F.4030408@collabora.co.uk> <516380D7.3060000@gmail.com>
Message-ID: <CABxcv==GPmsC+-1-arFrA4xF5RbOtK1h-UMUDyft0PcbJCuF7A@mail.gmail.com>

On Tue, Apr 9, 2013 at 4:45 AM, Rob Herring <robherring2 at gmail.com> wrote:
> On 04/08/2013 05:56 PM, Javier Martinez Canillas wrote:
>> On 04/09/2013 12:16 AM, Stephen Warren wrote:
>>> On 04/08/2013 04:05 PM, Rob Herring wrote:
>>>> On 04/05/2013 02:48 AM, Javier Martinez Canillas wrote:
>>>>> According to Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
>>>>> the "#interrupt-cells" property of an "interrupt-controller" is used
>>>>> to define the number of cells needed to specify a single interrupt.
>>> ...
>>>>> But the type is never returned so it can't be saved on the IRQ struct
>>>>> resource flags member.
>>>>>
>>>>> This means that drivers that need the IRQ type/level flags defined in
>>>>> the DT won't be able to get it.
>>>>
>>>> But the interrupt controllers that need the information should be able
>>>> to get to it via irqd_get_trigger_type. What problem exactly are you
>>>> trying to fix? What driver would use this?
>>>
>>> FYI, that is indeed what I did in sound/soc/codecs/wm8903.c. Thinking
>>> back, I'm not sure if that was the right thing or whether I should have
>>> sent this same patch:-)
>>>
>>
>> Hi Stephen,
>>
>> I'm glad you agree :-)
>>
>> I could change drivers/net/ethernet/smsc/smsc911x.c to get the type flags for
>> the IRQ with irqd_get_trigger_type() but I prefer $subject because:
>
> irqd_get_trigger_type probably is not meant for outside of irqchips.
> Creating an irq_get_irq_type function which takes an irq number would be
> the right function as that does not expose struct irq_data.
>

Ok, I can add an irqd_get_trigger_type() that just return the flags to
the caller without exposing the struct irq_data and using it on the
SMSC 911x driver instead using struct resource *irq_res->flags

I hope networking folks understand why this change is needed in this
driver to get the type/level flags for an IRQ defined on a DT...

>> a) This works in the non-DT case with board files and filling the resources from
>> platform data in arch/arm/mach-omap2/gpmc-smsc911x.c. So this is definitely a
>> bug on the DT core.
>
> And hackery/abuse like this:
>
> arch/arm/mach-omap2/board-3630sdp.c:32:    .flags          =
> GPMC_MUX_ADD_DATA | IORESOURCE_IRQ_LOWLEVEL,
>
>> b) I don't see why of_irq_to_resource() should discard the type/level flags when
>> filling the IORESOURCE_IRQ if it was specified on the DT.
>>
>> c) We will have to change all drivers that expect to get the IRQ type flags from
>> a IORESOURCE_IRQ struct resource.
>
> I'm not convinced that is a high number of drivers. Nearly all the
> occurrences of IORESOURCE_IRQ_ in drivers/ are for ISA (acpi/pnp) and
> drivers for ISA devices.
>

If IORESOURCE_IRQ is just supposed to be used for ISA devices drivers
that use ACPI/PnP instead DT, then of_irq_to_resource() callers should
just use irq_of_parse_and_map() that returns the virtual IRQ number
for an index within a controller instead of a struct resource.

In fact I wonder what's the point to have an of_irq_to_resource()
function at all if  IORESOURCE_IRQ is not supposed to be used for
devices connected through dumb buses that need a DT and the struct
resource will only hold the mapped virtual IRQ number and no the IRQ
flags.

> Rob
>

Best regards,
Javier


From michal.bachraty at streamunlimited.com  Tue Apr  9 04:26:15 2013
From: michal.bachraty at streamunlimited.com (Michal Bachraty)
Date: Tue,  9 Apr 2013 10:26:15 +0200
Subject: [PATCH] clk: si5351: Add gapless tuning for SI5351 PLL
Message-ID: <1365495975-792-1-git-send-email-michal.bachraty@streamunlimited.com>

For gapless tuning, there is no need for PLL reset and clkout power-down
when tuning output. "silabs,gapless-tuning" parameter enables gapless tuning
for specific clock output.

Signed-off-by: Michal Bachraty <michal.bachraty at streamunlimited.com>
---
 .../devicetree/bindings/clock/silabs,si5351.txt    |    2 ++
 drivers/clk/clk-si5351.c                           |   27 +++++++++++++++++---
 2 files changed, 25 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/clock/silabs,si5351.txt b/Documentation/devicetree/bindings/clock/silabs,si5351.txt
index cc37465..e16ab2b 100644
--- a/Documentation/devicetree/bindings/clock/silabs,si5351.txt
+++ b/Documentation/devicetree/bindings/clock/silabs,si5351.txt
@@ -44,6 +44,8 @@ Optional child node properties:
 - silabs,multisynth-source: source pll A(0) or B(1) of corresponding multisynth
   divider.
 - silabs,pll-master: boolean, multisynth can change pll frequency.
+- silabs,gapless-tuning: boolean, enable gapless (glitch-free) tuning. Depends on
+  "silabs,multisynth-source" parameter.
 
 ==Example==
 
diff --git a/drivers/clk/clk-si5351.c b/drivers/clk/clk-si5351.c
index e259cec..d3933a9 100644
--- a/drivers/clk/clk-si5351.c
+++ b/drivers/clk/clk-si5351.c
@@ -54,6 +54,7 @@ struct si5351_hw_data {
 	struct si5351_driver_data	*drvdata;
 	struct si5351_parameters	params;
 	unsigned char			num;
+	unsigned char			gapless_tuning;
 };
 
 struct si5351_driver_data {
@@ -526,8 +527,10 @@ static int si5351_pll_set_rate(struct clk_hw *hw, unsigned long rate,
 		(hwdata->params.p2 == 0) ? SI5351_CLK_INTEGER_MODE : 0);
 
 	/* reset pll */
-	val = (hwdata->num == 0) ? SI5351_PLL_RESET_A : SI5351_PLL_RESET_B;
-	si5351_set_bits(hwdata->drvdata, SI5351_PLL_RESET, val, val);
+	if (!hwdata->gapless_tuning) {
+		val = (hwdata->num == 0) ? SI5351_PLL_RESET_A : SI5351_PLL_RESET_B;
+		si5351_set_bits(hwdata->drvdata, SI5351_PLL_RESET, val, val);
+	}
 
 	dev_dbg(&hwdata->drvdata->client->dev,
 		"%s - %s: p1 = %lu, p2 = %lu, p3 = %lu, parent_rate = %lu, rate = %lu\n",
@@ -1064,8 +1067,9 @@ static int si5351_clkout_set_rate(struct clk_hw *hw, unsigned long rate,
 	} while (1);
 
 	/* powerdown clkout */
-	si5351_set_bits(hwdata->drvdata, SI5351_CLK0_CTRL + hwdata->num,
-			SI5351_CLK_POWERDOWN, SI5351_CLK_POWERDOWN);
+	if (!hwdata->gapless_tuning)
+		si5351_set_bits(hwdata->drvdata, SI5351_CLK0_CTRL + hwdata->num,
+				SI5351_CLK_POWERDOWN, SI5351_CLK_POWERDOWN);
 
 	/* write output divider */
 	switch (hwdata->num) {
@@ -1117,6 +1121,7 @@ static void si5351_dt_setup(
 	struct property *prop;
 	const __be32 *p;
 	unsigned int num, val;
+	int pll = -1;
 
 	if (np == NULL)
 		return;
@@ -1167,6 +1172,8 @@ static void si5351_dt_setup(
 				dev_warn(&client->dev,
 					 "unable to reparent multisynth %d to %d\n",
 					 num, val);
+			else
+				pll = val;
 		}
 
 		if (!of_property_read_u32(np, "silabs,clock-source", &val)) {
@@ -1178,6 +1185,15 @@ static void si5351_dt_setup(
 
 		if (!of_property_read_u32(np, "clock-frequency", &val))
 			clk_set_rate(drvdata->onecell.clks[num], val);
+
+		if (of_property_read_bool(np, "silabs,gapless-tuning")) {
+			if (pll >= 0) {
+				drvdata->clkout[num].gapless_tuning = 1;
+				drvdata->pll[pll].gapless_tuning = 1;
+			} else
+				dev_warn(&client->dev,
+					"unable to set gapless tuning");
+		}
 	}
 }
 
@@ -1294,6 +1310,7 @@ static int si5351_i2c_probe(struct i2c_client *client,
 	drvdata->pll[0].num = 0;
 	drvdata->pll[0].drvdata = drvdata;
 	drvdata->pll[0].hw.init = &init;
+	drvdata->pll[0].gapless_tuning = 0;
 	memset(&init, 0, sizeof(init));
 	init.name = si5351_pll_names[0];
 	init.ops = &si5351_pll_ops;
@@ -1310,6 +1327,7 @@ static int si5351_i2c_probe(struct i2c_client *client,
 	drvdata->pll[1].num = 1;
 	drvdata->pll[1].drvdata = drvdata;
 	drvdata->pll[1].hw.init = &init;
+	drvdata->pll[1].gapless_tuning = 0;
 	memset(&init, 0, sizeof(init));
 	if (drvdata->variant == SI5351_VARIANT_B) {
 		init.name = si5351_pll_names[2];
@@ -1380,6 +1398,7 @@ static int si5351_i2c_probe(struct i2c_client *client,
 		drvdata->clkout[n].num = n;
 		drvdata->clkout[n].drvdata = drvdata;
 		drvdata->clkout[n].hw.init = &init;
+		drvdata->clkout[n].gapless_tuning = 0;
 		memset(&init, 0, sizeof(init));
 		init.name = si5351_clkout_names[n];
 		init.ops = &si5351_clkout_ops;
-- 
1.7.9.5



From javier at dowhile0.org  Tue Apr  9 04:28:43 2013
From: javier at dowhile0.org (Javier Martinez Canillas)
Date: Tue, 9 Apr 2013 10:28:43 +0200
Subject: [PATCH 1/1] of/irq: store IRQ trigger/level in struct resource
 flags
In-Reply-To: <CABxcv==GPmsC+-1-arFrA4xF5RbOtK1h-UMUDyft0PcbJCuF7A@mail.gmail.com>
References: <1365148088-11175-1-git-send-email-javier.martinez@collabora.co.uk>
 <51633F26.7000400@gmail.com> <516341AF.7030207@wwwdotorg.org>
 <51634B1F.4030408@collabora.co.uk> <516380D7.3060000@gmail.com>
 <CABxcv==GPmsC+-1-arFrA4xF5RbOtK1h-UMUDyft0PcbJCuF7A@mail.gmail.com>
Message-ID: <CABxcv==ok8jWE_Wzb597dzjV=6-4NCpAOrsMZKW_ooKAzf18mQ@mail.gmail.com>

On Tue, Apr 9, 2013 at 10:26 AM, Javier Martinez Canillas
<javier at dowhile0.org> wrote:
> On Tue, Apr 9, 2013 at 4:45 AM, Rob Herring <robherring2 at gmail.com> wrote:
>> On 04/08/2013 05:56 PM, Javier Martinez Canillas wrote:
>>> On 04/09/2013 12:16 AM, Stephen Warren wrote:
>>>> On 04/08/2013 04:05 PM, Rob Herring wrote:
>>>>> On 04/05/2013 02:48 AM, Javier Martinez Canillas wrote:
>>>>>> According to Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
>>>>>> the "#interrupt-cells" property of an "interrupt-controller" is used
>>>>>> to define the number of cells needed to specify a single interrupt.
>>>> ...
>>>>>> But the type is never returned so it can't be saved on the IRQ struct
>>>>>> resource flags member.
>>>>>>
>>>>>> This means that drivers that need the IRQ type/level flags defined in
>>>>>> the DT won't be able to get it.
>>>>>
>>>>> But the interrupt controllers that need the information should be able
>>>>> to get to it via irqd_get_trigger_type. What problem exactly are you
>>>>> trying to fix? What driver would use this?
>>>>
>>>> FYI, that is indeed what I did in sound/soc/codecs/wm8903.c. Thinking
>>>> back, I'm not sure if that was the right thing or whether I should have
>>>> sent this same patch:-)
>>>>
>>>
>>> Hi Stephen,
>>>
>>> I'm glad you agree :-)
>>>
>>> I could change drivers/net/ethernet/smsc/smsc911x.c to get the type flags for
>>> the IRQ with irqd_get_trigger_type() but I prefer $subject because:
>>
>> irqd_get_trigger_type probably is not meant for outside of irqchips.
>> Creating an irq_get_irq_type function which takes an irq number would be
>> the right function as that does not expose struct irq_data.
>>
>
> Ok, I can add an irqd_get_trigger_type() that just return the flags to

I meant irq_get_irq_type() of course.

Best regards,
Javier


From kishon at ti.com  Tue Apr  9 04:28:21 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Tue, 9 Apr 2013 13:58:21 +0530
Subject: =?UTF-8?q?=5BPATCH=5D=20ARM=3A=20OMAP4=3A=20HWMOD=3A=20make=20=27ocp2scp=5Fusb=5Fphy=5Fphy=5F48m=22=20as=20the=20main=20clock?=
Message-ID: <1365496101-7829-1-git-send-email-kishon@ti.com>

commit 92702d (ARM: OMAP4: PM: fix PM regression introduced by recent
clock cleanup) makes the 'ocp2scp_usb_phy_phy_48m' as optional
functional clock causing regression in MUSB. But this 48MHz clock is a
mandatory clock for usb phy attached to ocp2scp and hence made as the main
clock for ocp2scp.

Cc: Keerthy <j-keerthy at ti.com>
Cc: Beno?t Cousson <b-cousson at ti.com>
Cc: Paul Walmsley <paul at pwsan.com>
Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
---
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |    8 +-------
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 9e05765..c1fb090 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -2714,16 +2714,12 @@ static struct omap_ocp2scp_dev ocp2scp_dev_attr[] = {
 	{ }
 };
 
-static struct omap_hwmod_opt_clk ocp2scp_usb_phy_opt_clks[] = {
-	{ .role = "48mhz", .clk = "ocp2scp_usb_phy_phy_48m" },
-};
-
 /* ocp2scp_usb_phy */
 static struct omap_hwmod omap44xx_ocp2scp_usb_phy_hwmod = {
 	.name		= "ocp2scp_usb_phy",
 	.class		= &omap44xx_ocp2scp_hwmod_class,
 	.clkdm_name	= "l3_init_clkdm",
-	.main_clk	= "func_48m_fclk",
+	.main_clk	= "ocp2scp_usb_phy_phy_48m",
 	.prcm = {
 		.omap4 = {
 			.clkctrl_offs = OMAP4_CM_L3INIT_USBPHYOCP2SCP_CLKCTRL_OFFSET,
@@ -2732,8 +2728,6 @@ static struct omap_hwmod omap44xx_ocp2scp_usb_phy_hwmod = {
 		},
 	},
 	.dev_attr	= ocp2scp_dev_attr,
-	.opt_clks	= ocp2scp_usb_phy_opt_clks,
-	.opt_clks_cnt	= ARRAY_SIZE(ocp2scp_usb_phy_opt_clks),
 };
 
 /*
-- 
1.7.10.4



From pdeschrijver at nvidia.com  Tue Apr  9 04:30:50 2013
From: pdeschrijver at nvidia.com (Peter De Schrijver)
Date: Tue, 9 Apr 2013 11:30:50 +0300
Subject: [PATCH 2/3] ARM: dts: tegra: Correct PCIe entry
In-Reply-To: <51630BF4.6000605@wwwdotorg.org>
References: <1365435688-4179-1-git-send-email-jagarwal@nvidia.com>
 <1365435688-4179-2-git-send-email-jagarwal@nvidia.com>
 <51630BF4.6000605@wwwdotorg.org>
Message-ID: <20130409083050.GQ3572@tbergstrom-lnx.Nvidia.com>

On Mon, Apr 08, 2013 at 08:27:00PM +0200, Stephen Warren wrote:
> On 04/08/2013 09:41 AM, Jay Agarwal wrote:
> > Signed-off-by: Jay Agarwal <jagarwal at nvidia.com>
> 
> Your s-o-b line should be below the patch description, not above it.
> Please see Documentation/SubmittingPatches.
> 
> I also don't see a --- line between the patch description and diffstat.
> How are you generating these patch emails? Please see our internal wiki,
> or other git documentation.
> 
> > diff --git a/arch/arm/boot/dts/tegra30.dtsi b/arch/arm/boot/dts/tegra30.dtsi
> 
> > -		clock-names = "pex", "afi", "pcie_xclk", "pll_e", "cml";
> > +		clock-names = "pex", "afi", "pcie_xclk", "pll_e", "cml0";
> 
> Can you please explain more about this change?
> 
> I see the Tegra clock driver provides both a "cml0" and a "cml1" clock.
> Are both of those used for PCIe?
> 

cml0 is used for pcie and cml1 is used for sata.

Cheers,

Peter.


From horms at verge.net.au  Tue Apr  9 04:32:43 2013
From: horms at verge.net.au (Simon Horman)
Date: Tue, 9 Apr 2013 17:32:43 +0900
Subject: [PATCH v2 0/9] Reorganize R8A7779/Marzen USB code
In-Reply-To: <201304090110.50154.sergei.shtylyov@cogentembedded.com>
References: <201304090110.50154.sergei.shtylyov@cogentembedded.com>
Message-ID: <20130409083243.GF18478@verge.net.au>

On Tue, Apr 09, 2013 at 01:10:49AM +0400, Sergei Shtylyov wrote:
> Hello.
> 
>    Here's the set of 9 patches against the Simon Horman's 'renesas.git' repo,
> 'renesas-next-20130405v2' tag.  It was created to fix the shortcomings in the
> R8A7779/Marzen USB platform code and R8A7779 USB common PHY driver, and so
> spans both arch/arm/mach-shmobile/ and drivers/usb/ subtrees (some patches have
> to touch both subtrees). The patches were conceived with the complete
> bisectability goal in mind. The patches have been tested on the Marzen board.
> 
> [1/9] ARM: shmobile: Marzen: move USB EHCI, OHCI, and PHY devices to R8A7779 code
> [2/9] ehci-platform: add pre_setup() method to platform data
> [3/9] ARM: shmobile: R8A7779: setup EHCI internal buffer
> [4/9] rcar-phy: remove EHCI internal buffer setup
> [5/9] ARM: shmobile: R8A7779: remove USB PHY 2nd memory resource
> [6/9] rcar-phy: correct base address
> [7/9] rcar-phy: add platform data
> [8/9] ARM: shmobile: Marzen: pass platform data to USB PHY device
> [9/9] rcar-phy: handle platform data
> 
>    I'm not sure thru which tree this patchset should be merged, however it turns
> out that it's too late now to push it thru Felipe Balbi's USB tree for 3.10 which
> would have been most convenient probably, so maybe the patchset can be merged
> thru Simon's tree with Felipe's and Alan Stern's ACKs. Or perhaps it now should
> be postponed for 3.11...

I feel that it is also too late for v3.10 for my tree.

I am happy to take them through my tree with appropriate acks.
Or, follow acks from Morimoto-san to allow the shmobile portions
to go through a different tree.



From linus.walleij at linaro.org  Tue Apr  9 04:35:33 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Tue, 9 Apr 2013 10:35:33 +0200
Subject: [PATCH] pinctrl:sirf:re-arch and add support for new SiRFatlas6
 SoC
In-Reply-To: <CAGsJ_4xSk_fXjhM2kxy0Hd36e9BsGshfmM97KgcU3cC5avmxtQ@mail.gmail.com>
References: <1363597988-7409-1-git-send-email-Barry.Song@csr.com>
 <CACRpkdYUTQ_7V1CbKbx05zgBONj6iUi=ekzSwmZz8dqeRx7ZJw@mail.gmail.com>
 <CAGsJ_4wmn-LxxX-JeSJzdkVFSUeJ=vQrKHJr9yUtsoxG2BFHtw@mail.gmail.com>
 <CACRpkdaMYTXpnfg8MhRP5Fs_Qn2gwv=Xuk3YSYejxt+vK9D6+w@mail.gmail.com>
 <CAGsJ_4xSk_fXjhM2kxy0Hd36e9BsGshfmM97KgcU3cC5avmxtQ@mail.gmail.com>
Message-ID: <CACRpkda+ghKMkXFQzkJ7uauwGWGNrn4aqyYajt9U9RYkmvT-6g@mail.gmail.com>

On Sun, Apr 7, 2013 at 5:03 AM, Barry Song <21cnbao at gmail.com> wrote:
> 2013/4/3 Linus Walleij <linus.walleij at linaro.org>:
>> On Thu, Mar 28, 2013 at 7:27 AM, Barry Song <21cnbao at gmail.com> wrote:
>>> 2013/3/28, Linus Walleij <linus.walleij at linaro.org>:
>>
>>>>> Signed-off-by: Barry Song <Baohua.Song at csr.com>
>>>>
>>>> This is OK but can you please:
>>>
>>> ok. one issue is recently Arnd has given another changes in
>>> pinctrl-sirf in arm-soc multiple platform branch:
>>> https://git.kernel.org/cgit/linux/kernel/git/arm/arm-soc.git/commit/?h=prima2/multiplatform&id=67d71344fd09223820eb9de39b597ec29f035e89
>>>
>>> it makes us easily to get merging conflict. what is your suggestion
>>> about taking all these changes in 3.10?
>>
>> Please send this to where the rest of the patches are with my ACK
>> (I guess the ARM SoC tree?)
>
> unfortunately, this is not in arm soc:
> Wei Yongjun <yongjun_wei at trendmicro.com.cn>
> pinctrl: sirf: using for_each_set_bit to simplify the code
>
> https://git.kernel.org/cgit/linux/kernel/git/linusw/linux-pinctrl.git/commit/?h=for-next&id=3dcbd6f5789839c7fea8841088ed3a28688f81ed
>
> i think there will still be some merge conflict. so to make people
> easy, i might wait for 3.11 and resend the patch with your ack, then
> you apply it on pinctrl tree.

OK let's do it like that.

Yours,
Linus Walleij


From linus.walleij at linaro.org  Tue Apr  9 04:36:59 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Tue, 9 Apr 2013 10:36:59 +0200
Subject: [PATCH v2 0/3] Get rid of big array from imx pinctrl driver
In-Reply-To: <20130408060857.GA5047@S2101-09.ap.freescale.net>
References: <1361533888-18073-1-git-send-email-shawn.guo@linaro.org>
 <CAOMZO5D1+baoM0vMdPW9bAd4DX8C82BF9H87igFNo78+8D_N3Q@mail.gmail.com>
 <20130407071028.GD11898@S2101-09.ap.freescale.net>
 <CAOMZO5Bxfj9ZGrVOcNirsVHFLWaHWBdkFpKSiVQ9iS4paT0Y6g@mail.gmail.com>
 <20130407142610.GE11898@S2101-09.ap.freescale.net>
 <CAOMZO5A-nwmb=6G-D_2LBNsPYH4C8Z686BjS3vd3WhzvnDFfqw@mail.gmail.com>
 <20130408060857.GA5047@S2101-09.ap.freescale.net>
Message-ID: <CACRpkdZL084APsYD_g44Yxx5fWC-8e6bvS6xKpr_2YrXDMhwZQ@mail.gmail.com>

On Mon, Apr 8, 2013 at 8:09 AM, Shawn Guo <shawn.guo at linaro.org> wrote:

> --8<-----
>
> diff --git a/drivers/pinctrl/pinctrl-imx6q.c b/drivers/pinctrl/pinctrl-imx6q.c
> index f00f532..76dd9c4 100644
> --- a/drivers/pinctrl/pinctrl-imx6q.c
> +++ b/drivers/pinctrl/pinctrl-imx6q.c

Acked-by. I trust you to fix up and merge the outcome of this Shawn...

Yours,
Linus Walleij


From marc.zyngier at arm.com  Tue Apr  9 04:37:30 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Tue, 09 Apr 2013 09:37:30 +0100
Subject: [PATCH 1/2] ARM: KVM: add architecture specific hook for
 capabilities
In-Reply-To: <CAFEAcA-WQO7cdi25-Bu5Yj3yN0PgUmEezHpdhR7dfQ_2y+Z0vg@mail.gmail.com>
References: <1365436039-29564-1-git-send-email-marc.zyngier@arm.com>
 <1365436039-29564-2-git-send-email-marc.zyngier@arm.com>
 <CAFEAcA-WQO7cdi25-Bu5Yj3yN0PgUmEezHpdhR7dfQ_2y+Z0vg@mail.gmail.com>
Message-ID: <5163D34A.8010906@arm.com>

On 08/04/13 16:53, Peter Maydell wrote:
> On 8 April 2013 16:47, Marc Zyngier <marc.zyngier at arm.com> wrote:
>> Most of the capabilities are common to both arm and arm64, but
>> we still need to handle the exceptions.
>>
>> Introduce kvm_arch_dev_ioctl_check_extention, which both architectures
> 
> "extension" (here and in the code itself).

Damn. My native language has crept back. Thanks for pointing it out.

	M.
-- 
Jazz is not dead. It just smells funny...



From avinashphilip at ti.com  Tue Apr  9 04:42:27 2013
From: avinashphilip at ti.com (Philip, Avinash)
Date: Tue, 9 Apr 2013 08:42:27 +0000
Subject: [PATCH v3 3/3] ARM: davinci: da850: add EHRPWM & ECAP DT node
In-Reply-To: <5162C1A5.5060808@ti.com>
References: <1364197789-16783-1-git-send-email-avinashphilip@ti.com>
 <1364197789-16783-4-git-send-email-avinashphilip@ti.com>
 <515A97DE.1080403@ti.com>
 <518397C60809E147AF5323E0420B992E3EAA91B6@DBDE01.ent.ti.com>
 <5162C1A5.5060808@ti.com>
Message-ID: <518397C60809E147AF5323E0420B992E3EAA9DA3@DBDE01.ent.ti.com>

On Mon, Apr 08, 2013 at 18:39:57, Nori, Sekhar wrote:
> 
> On 4/8/2013 2:39 PM, Philip, Avinash wrote:
> > On Tue, Apr 02, 2013 at 14:03:34, Nori, Sekhar wrote:
> >> On 3/25/2013 1:19 PM, Philip Avinash wrote:
> >>> Add da850 EHRPWM & ECAP DT node.
> >>> Also adds OF_DEV_AUXDATA for EHRPWM & ECAP driver to use EHRPWM & ECAP
> >>> clock.
> >>
> >> This looks fine to me but I will wait for the bindings to get accepted
> >> before taking this one.
> > 
> > Sekhar,
> > 
> > Binding document got accepted in PWM tree [1].
> > Can you accept this patch?
> 
> Can you also add the pinmux definitions and resend just this patch?
> Sorry I did not notice those were missing earlier.

According to latest schematics, ECAP instance 2 being used for PWM backlight
control. Should I add pin-mux only for ECAP2 or for all PWM instances?

Thanks
Avinash

> 
> Thanks,
> Sekhar
> 


From horms at verge.net.au  Tue Apr  9 04:44:23 2013
From: horms at verge.net.au (Simon Horman)
Date: Tue, 9 Apr 2013 17:44:23 +0900
Subject: [PATCH v3] irqchip: renesas-intc-irqpin: DT binding for sense
 bitfield width
In-Reply-To: <2492042.P3NGiSlrcg@avalon>
References: <Pine.LNX.4.64.1304081002190.29945@axis700.grange>
 <15518520.KQOfZxAAdo@avalon>
 <Pine.LNX.4.64.1304081412550.29945@axis700.grange>
 <2492042.P3NGiSlrcg@avalon>
Message-ID: <20130409084423.GH18478@verge.net.au>

On Tue, Apr 09, 2013 at 01:22:29AM +0200, Laurent Pinchart wrote:
> Hi Guennadi,
> 
> On Monday 08 April 2013 14:15:39 Guennadi Liakhovetski wrote:
> > On Mon, 8 Apr 2013, Laurent Pinchart wrote:
> > > On Monday 08 April 2013 13:25:46 Guennadi Liakhovetski wrote:
> > > > On Mon, 8 Apr 2013, Laurent Pinchart wrote:
> > > > > On Monday 08 April 2013 10:08:40 Guennadi Liakhovetski wrote:
> > > > > > Most Renesas irqpin controllers have 4-bit sense fields, however,
> > > > > > some have different widths. This patch adds a DT binding to
> > > > > > optionally specify such non-standard values.
> > > > > > 
> > > > > > Signed-off-by: Guennadi Liakhovetski
> > > > > > <g.liakhovetski+renesas at gmail.com>
> > > > > > ---
> > > > > > 
> > > > > > v3: move the code to a common location, where device configuration
> > > > > > parameters are retrieved
> > > > > > 
> > > > > >  .../interrupt-controller/renesas,intc-irqpin.txt   |   13 +++++++++
> > > > > >  drivers/irqchip/irq-renesas-intc-irqpin.c          |    4 ++++
> > > > > >  2 files changed, 17 insertions(+), 0 deletions(-)
> > > > > >  create mode 100644
> > > > > > 
> > > > > > Documentation/devicetree/bindings/interrupt-controller/renesas,intc-
> > > > > > irqpin.txt
> > > > > > diff --git a/Documentation/devicetree/bindings/interrupt-
> > > > > > controller/renesas,intc-irqpin.txt
> > > > > > b/Documentation/devicetree/bindings/interrupt-controller/
> > > > > > renesas,intc-irqpin.txt
> > > > > > new file mode 100644
> > > > > > index 0000000..c6f09b7
> > > > > > --- /dev/null
> > > > > > +++
> > > > > > b/Documentation/devicetree/bindings/interrupt-controller/renesas,int
> > > > > > c-
> > > > > > irqpin.txt
> > > > > > @@ -0,0 +1,13 @@
> > > > > > +DT bindings for the R-/SH-Mobile irqpin controller
> > > > > > +
> > > > > > +Required properties:
> > > > > > +
> > > > > > +- compatible: has to be "renesas,intc-irqpin"
> > > > > > +- #interrupt-cells: has to be <2>
> > > > > > +
> > > > > > +Optional properties:
> > > > > > +
> > > > > > +- any properties, listed in interrupts.txt in this directory, and
> > > > > > any standard
> > > > > > +  resource allocation properties
> > > > > > +- sense-bitfield-width: width of a single sense bitfield in the
> > > > > > SENSE register,
> > > > > > +  if different from the default 4 bits
> > > > > 
> > > > > Wouldn't it be better to define per-SoC compatible strings, and infer
> > > > > the sense bitfield width from that ?
> > > > 
> > > > This is not a boolean, it is an integer, I don't think defining
> > > > compatibility strings for 1, 2, 3, 4, 5,... bits is better than having
> > > > one integer property.
> > > 
> > > I'm not advocating for compatibility strings for a given number of bits,
> > > but for per-SoC compatibility strings from which to infer the width.
> > > 
> > > For instance, if the r8a7779 has a 6-bit sense field, you would use
> > > 
> > > compatible = "r8a7779,intc-irqpin";
> > > 
> > > and map that to 6 in the irqpin driver.
> > 
> > I understand what you mean, still I don't think mapping N SoC-compatibility
> > strings to various values of a single integer is better than having a single
> > property.
> 
> The way I understand (or maybe rather feel) the DT bindings philosophy is that 
> hardware information for on-SoC IP cores that depend on the IP core version 
> should be conveyed through the compatible property. I might be wrong though.

That is also my understanding.


From linus.walleij at linaro.org  Tue Apr  9 04:48:29 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Tue, 9 Apr 2013 10:48:29 +0200
Subject: [PATCH] pinctrl: sunxi: Rename wemac functions to emac
In-Reply-To: <1364389953-20688-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1364389953-20688-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <CACRpkdbESJaYTAONN5UdDEUEVHjh3iJcfrXs2-g61MHi4FouVA@mail.gmail.com>

On Wed, Mar 27, 2013 at 2:12 PM, Maxime Ripard
<maxime.ripard at free-electrons.com> wrote:

> The pin functions associated to the ethernet controller were introduced
> with the label "wemac", which was the name of the ethernet driver in the
> allwinner source tree, while the real name of the IP is actually "emac",
> as advertised in several documents including the datasheet.
>
> Since this is part of the device tree bindings, and that these part of
> the bindings have not yet be released in a kernel version, it seems like
> the good timing to change it and assure consistency.
>
> Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>

Patch applied, thanks!

Yours,
Linus Walleij


From b-cousson at ti.com  Tue Apr  9 04:54:03 2013
From: b-cousson at ti.com (Benoit Cousson)
Date: Tue, 9 Apr 2013 10:54:03 +0200
Subject: [PATCH] ARM: OMAP4: HWMOD: make 'ocp2scp_usb_phy_phy_48m" as
 the main clock
In-Reply-To: <1365496101-7829-1-git-send-email-kishon@ti.com>
References: <1365496101-7829-1-git-send-email-kishon@ti.com>
Message-ID: <5163D72B.5040205@ti.com>

Hi Kishon,

On 04/09/2013 10:28 AM, Kishon Vijay Abraham I wrote:
> commit 92702d (ARM: OMAP4: PM: fix PM regression introduced by recent
> clock cleanup) makes the 'ocp2scp_usb_phy_phy_48m' as optional
> functional clock causing regression in MUSB. But this 48MHz clock is a
> mandatory clock for usb phy attached to ocp2scp and hence made as the main
> clock for ocp2scp.

It is a fix for 3.9-rcX?

Regards,
Benoit

> 
> Cc: Keerthy <j-keerthy at ti.com>
> Cc: Beno?t Cousson <b-cousson at ti.com>
> Cc: Paul Walmsley <paul at pwsan.com>
> Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
> ---
>  arch/arm/mach-omap2/omap_hwmod_44xx_data.c |    8 +-------
>  1 file changed, 1 insertion(+), 7 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> index 9e05765..c1fb090 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> @@ -2714,16 +2714,12 @@ static struct omap_ocp2scp_dev ocp2scp_dev_attr[] = {
>  	{ }
>  };
>  
> -static struct omap_hwmod_opt_clk ocp2scp_usb_phy_opt_clks[] = {
> -	{ .role = "48mhz", .clk = "ocp2scp_usb_phy_phy_48m" },
> -};
> -
>  /* ocp2scp_usb_phy */
>  static struct omap_hwmod omap44xx_ocp2scp_usb_phy_hwmod = {
>  	.name		= "ocp2scp_usb_phy",
>  	.class		= &omap44xx_ocp2scp_hwmod_class,
>  	.clkdm_name	= "l3_init_clkdm",
> -	.main_clk	= "func_48m_fclk",
> +	.main_clk	= "ocp2scp_usb_phy_phy_48m",
>  	.prcm = {
>  		.omap4 = {
>  			.clkctrl_offs = OMAP4_CM_L3INIT_USBPHYOCP2SCP_CLKCTRL_OFFSET,
> @@ -2732,8 +2728,6 @@ static struct omap_hwmod omap44xx_ocp2scp_usb_phy_hwmod = {
>  		},
>  	},
>  	.dev_attr	= ocp2scp_dev_attr,
> -	.opt_clks	= ocp2scp_usb_phy_opt_clks,
> -	.opt_clks_cnt	= ARRAY_SIZE(ocp2scp_usb_phy_opt_clks),
>  };
>  
>  /*
> 



From kishon at ti.com  Tue Apr  9 04:55:05 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Tue, 9 Apr 2013 14:25:05 +0530
Subject: [PATCH] ARM: OMAP4: HWMOD: make 'ocp2scp_usb_phy_phy_48m" as
 the main clock
In-Reply-To: <5163D72B.5040205@ti.com>
References: <1365496101-7829-1-git-send-email-kishon@ti.com>
 <5163D72B.5040205@ti.com>
Message-ID: <5163D769.1040401@ti.com>

Hi,

On Tuesday 09 April 2013 02:24 PM, Benoit Cousson wrote:
> Hi Kishon,
>
> On 04/09/2013 10:28 AM, Kishon Vijay Abraham I wrote:
>> commit 92702d (ARM: OMAP4: PM: fix PM regression introduced by recent
>> clock cleanup) makes the 'ocp2scp_usb_phy_phy_48m' as optional
>> functional clock causing regression in MUSB. But this 48MHz clock is a
>> mandatory clock for usb phy attached to ocp2scp and hence made as the main
>> clock for ocp2scp.
>
> It is a fix for 3.9-rcX?

Yeah.

Thanks
Kishon


From fabio.baltieri at linaro.org  Tue Apr  9 04:57:21 2013
From: fabio.baltieri at linaro.org (Fabio Baltieri)
Date: Tue,  9 Apr 2013 10:57:21 +0200
Subject: [PATCH] mfd: ab8500-core: Add of_compatilbe property for ab8500-usb
Message-ID: <1365497841-4640-1-git-send-email-fabio.baltieri@linaro.org>

Add of_comptabile string to the ab8500-usb cell to allow the driver to
grab properties from device-tree when available.

Signed-off-by: Fabio Baltieri <fabio.baltieri at linaro.org>
---

Hi Samuel,

this oneline allows the driver to grab regulators and other attributes
from device tree.

This is actually generated on top of -next, so it should apply cleanly on
your current mfd-next tree.  If it doesn't, I'll rebase on your updated
tree when available.

Thanks,
Fabio

 drivers/mfd/ab8500-core.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mfd/ab8500-core.c b/drivers/mfd/ab8500-core.c
index f276352..4be1d0c 100644
--- a/drivers/mfd/ab8500-core.c
+++ b/drivers/mfd/ab8500-core.c
@@ -1107,6 +1107,7 @@ static struct mfd_cell ab8500_devs[] = {
 	},
 	{
 		.name = "ab8500-usb",
+		.of_compatible = "stericsson,ab8500-usb",
 		.num_resources = ARRAY_SIZE(ab8500_usb_resources),
 		.resources = ab8500_usb_resources,
 	},
-- 
1.8.1.3



From ohad at wizery.com  Tue Apr  9 05:03:37 2013
From: ohad at wizery.com (Ohad Ben-Cohen)
Date: Tue, 9 Apr 2013 12:03:37 +0300
Subject: [PATCH v9 4/6] ARM: davinci: Add a remoteproc driver
 implementation for OMAP-L13x DSP
In-Reply-To: <13514BD7FAEBA745BBD7D8A672905C14312302EA@DFLE12.ent.ti.com>
References: <1364521307-1219-1-git-send-email-rtivy@ti.com>
 <1364521307-1219-5-git-send-email-rtivy@ti.com>
 <CAK=WgbZme2UkMeP-JB2h3xnmcpzAaYeOcy7gxh60muJ8KZbr_A@mail.gmail.com>
 <13514BD7FAEBA745BBD7D8A672905C14312302EA@DFLE12.ent.ti.com>
Message-ID: <CAK=Wgba6_4T0Y1=xBpqw8fbxYhSDfWsj5XoLSAJAhq-MkxV9pw@mail.gmail.com>

On Tue, Apr 9, 2013 at 1:02 AM, Tivy, Robert <rtivy at ti.com> wrote:
> The platform_get_irq()/irq_get_irq_data()/platform_get_resource() calls don't have "put" counterparts.  The "devm_*" calls get automatically cleaned up (and I wasn't able to find any existing example of some code that actually does the cleanup explicitly).

Fair enough, thanks for looking.

> Sergei had a comment to change devm_request_and_ioremap() to devm_ioremap_resource(), so I will submit a new patch with your and Sergei's comments applied.

Thanks!


From linux at prisktech.co.nz  Tue Apr  9 05:04:50 2013
From: linux at prisktech.co.nz (Tony Prisk)
Date: Tue, 09 Apr 2013 21:04:50 +1200
Subject: linux-next: manual merge of the arm-soc tree with the gpio-lw tree
In-Reply-To: <20130409174747.873a9c9cad1cd6a4dbe4014f@canb.auug.org.au>
References: <20130409174747.873a9c9cad1cd6a4dbe4014f@canb.auug.org.au>
Message-ID: <5163D9B2.9060603@prisktech.co.nz>

On 09/04/13 19:47, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the arm-soc tree got a conflict in
> drivers/gpio/gpio-vt8500.c between commit 808c513ee64b ("gpio/vt8500:
> Convert to devm_ioremap_resource()") from the gpio-lw tree and commit
> dc1010860b03 ("gpio: vt8500: Remove arch-vt8500 gpio driver") from the
> arm-soc tree.
>
> The latter removed the file, so I did that and can carry the fix as
> necessary (no action is required).
>
That's the correct solution

Regards
Tony P



From sameo at linux.intel.com  Tue Apr  9 05:05:01 2013
From: sameo at linux.intel.com (Samuel Ortiz)
Date: Tue, 9 Apr 2013 11:05:01 +0200
Subject: [PATCH] mfd: ab8500-core: Add of_compatilbe property for
 ab8500-usb
In-Reply-To: <1365497841-4640-1-git-send-email-fabio.baltieri@linaro.org>
References: <1365497841-4640-1-git-send-email-fabio.baltieri@linaro.org>
Message-ID: <20130409090501.GF23447@zurbaran>

Hi Fabio,

On Tue, Apr 09, 2013 at 10:57:21AM +0200, Fabio Baltieri wrote:
> Add of_comptabile string to the ab8500-usb cell to allow the driver to
> grab properties from device-tree when available.
> 
> Signed-off-by: Fabio Baltieri <fabio.baltieri at linaro.org>
> ---
> 
> Hi Samuel,
> 
> this oneline allows the driver to grab regulators and other attributes
> from device tree.
> 
> This is actually generated on top of -next, so it should apply cleanly on
> your current mfd-next tree.  If it doesn't, I'll rebase on your updated
> tree when available.
It applies cleanly, I just pushed it now.

Cheers,
Samuel.

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


From mark.rutland at arm.com  Tue Apr  9 05:08:43 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Tue, 9 Apr 2013 10:08:43 +0100
Subject: [PATCH 1/4] Documentation: Add memory mapped ARM architected
 timer binding
In-Reply-To: <1365474623-29181-2-git-send-email-sboyd@codeaurora.org>
References: <1365474623-29181-1-git-send-email-sboyd@codeaurora.org>
 <1365474623-29181-2-git-send-email-sboyd@codeaurora.org>
Message-ID: <20130409090843.GS23725@e106331-lin.cambridge.arm.com>

Hi Stephen,

On Tue, Apr 09, 2013 at 03:30:20AM +0100, Stephen Boyd wrote:
> Add a binding for the arm architected timer hardware's memory
> mapped interface. The mmio timer hardware is made up of one base
> frame and a collection of up to 8 timer frames, where each of the
> 8 timer frames can have either one or two views. A frame
> typically maps to a privilege level (user/kernel, hypervisor,
> secure). The first view has full access to the registers within a
> frame, while the second view can be restricted to particular
> registers within a frame. Each frame must support a physical
> timer. It's optional for a frame to support a virtual timer.
> 
> Cc: devicetree-discuss at lists.ozlabs.org
> Cc: Mark Rutland <mark.rutland at arm.com>
> Cc: Marc Zyngier <Marc.Zyngier at arm.com>
> Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
> ---
>  .../devicetree/bindings/arm/arch_timer.txt         | 62 ++++++++++++++++++++--
>  1 file changed, 59 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/arm/arch_timer.txt b/Documentation/devicetree/bindings/arm/arch_timer.txt
> index 20746e5..69ef711 100644
> --- a/Documentation/devicetree/bindings/arm/arch_timer.txt
> +++ b/Documentation/devicetree/bindings/arm/arch_timer.txt
> @@ -1,10 +1,14 @@
>  * ARM architected timer
>  
> -ARM cores may have a per-core architected timer, which provides per-cpu timers.
> +ARM cores may have a per-core architected timer, which provides per-cpu timers,
> +or a memory mapped architected timer, which provides up to 8 frames with a
> +physical and optional virtual timer per frame.
>  
> -The timer is attached to a GIC to deliver its per-processor interrupts.
> +The per-core architected timer is attached to a GIC to deliver its
> +per-processor interrupts via PPIs. The memory mapped timer is attached to a GIC
> +to deliver its interrupts via SPIs.
>  
> -** Timer node properties:
> +** CP15 Timer node properties:
>  
>  - compatible : Should at least contain one of
>  	"arm,armv7-timer"
> @@ -26,3 +30,55 @@ Example:
>  			     <1 10 0xf08>;
>  		clock-frequency = <100000000>;
>  	};
> +
> +** Memory mapped timer node properties
> +
> +- compatible : Should at least contain "arm,armv7-timer-mem".
> +
> +- #address-cells : Must be 1.

What about LPAE systems?

How about something like the following:

#address-cells : If the ranges property is empty, the same value as the
                 parent node's #address-cells property. Otherwise, a
		 value such that the ranges property specifies a
		 mapping to the parent node's address space.            

> +
> +- #size-cells : Must be 1.
> +
> +- ranges : Indicates parent and child bus address space are the same.
> +

Similarly, what if someone wants to write a more complex mapping for some
reason?

We should be able to handle it if we use the standard accessors.

> +- clock-frequency : The frequency of the main counter, in Hz. Optional.
> +
> +- reg : The control frame base address.
> +
> +Frame:
> +
> +- frame-id: Encoded as follows:
> +		bits[3:0]  frame number: 0 to 7.
> +		bits[10:8] frame usage:
> +			0 - user/kernel
> +			1 - hyp
> +			2 - secure
> +

Could we not just have a disabled status property for those frames claimed by a
higher level (either secure firmware or hypervisor)? Or have I missed something
here?

Then we'd just have a frame-number property, which is easier for humans to read
and understand.

> +- interrupts : Interrupt list for physical and virtual timers in that order.
> +  The virtual timer interrupt is optional.
> +
> +- reg : The first and second view base addresses in that order. The second view
> +  base address is optional.
> +
> +Example:
> +
> +	timer at f0000000 {
> +		compatible = "arm,armv7-timer-mem";
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +		ranges;
> +		reg = <0xf0000000 0x1000>;
> +		clock-frequency = <50000000>;
> +		frame0 at f0001000 {
> +			frame-id = <0x0>
> +			interrupts = <0 13 0x8>,
> +				     <0 14 0x8>;
> +			reg = <0xf0001000 0x1000>,
> +			      <0xf0002000 0x1000>;
> +		};
> +		frame1 at f0003000 {
> +			frame-id = <0x11>
> +			interrupts = <0 15 0x8>;
> +			reg = <0xf0003000 0x1000>;
> +		};
> +	};
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> hosted by The Linux Foundation
> 
> 

Mark.


From sfr at canb.auug.org.au  Tue Apr  9 05:09:00 2013
From: sfr at canb.auug.org.au (Stephen Rothwell)
Date: Tue, 9 Apr 2013 19:09:00 +1000
Subject: linux-next: build warning after merge of the final tree (probably
 arm-soc tree related)
Message-ID: <20130409190900.97dcf3a70a9c0ad727b8bc4b@canb.auug.org.au>

Hi all,

After merging the final tree, today's linux-next build (arm defconfig)
produced these warnings:

arch/arm/mach-cns3xxx/Kconfig:2:warning: choice value used outside its choice group
arch/arm/mach-bcm2835/Kconfig:2:warning: choice value used outside its choice group
arch/arm/Kconfig:287:error: recursive dependency detected!
arch/arm/Kconfig:287:	choice <choice> contains symbol ARCH_CNS3XXX
arch/arm/Kconfig:366:	symbol ARCH_CNS3XXX depends on ARCH_MULTI_V6
arch/arm/Kconfig:933:	symbol ARCH_MULTI_V6 depends on ARCH_MULTIPLATFORM
arch/arm/Kconfig:292:	symbol ARCH_MULTIPLATFORM is part of choice <choice>

-- 
Cheers,
Stephen Rothwell                    sfr at canb.auug.org.au
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130409/ec45e218/attachment.sig>

From will.deacon at arm.com  Tue Apr  9 05:18:13 2013
From: will.deacon at arm.com (Will Deacon)
Date: Tue, 9 Apr 2013 10:18:13 +0100
Subject: [PATCH v2 6/7] ARM: KVM: switch to a dual-step HYP init code
In-Reply-To: <1365435403-29265-7-git-send-email-marc.zyngier@arm.com>
References: <1365435403-29265-1-git-send-email-marc.zyngier@arm.com>
 <1365435403-29265-7-git-send-email-marc.zyngier@arm.com>
Message-ID: <20130409091813.GC24090@mudshark.cambridge.arm.com>

On Mon, Apr 08, 2013 at 04:36:42PM +0100, Marc Zyngier wrote:
> Our HYP init code suffers from two major design issues:
> - it cannot support CPU hotplug, as we tear down the idmap very early
> - it cannot perform a TLB invalidation when switching from init to
>   runtime mappings, as pages are manipulated from PL1 exclusively
> 
> The hotplug problem mandates that we keep two sets of page tables
> (boot and runtime). The TLB problem mandates that we're able to
> transition from one PGD to another while in HYP, invalidating the TLBs
> in the process.
> 
> To be able to do this, we need to share a page between the two page
> tables. A page that will have the same VA in both configurations. All we
> need is a VA that has the following properties:
> - This VA can't be used to represent a kernel mapping.
> - This VA will not conflict with the physical address of the kernel text
> 
> The vectors page seems to satisfy this requirement:
> - The kernel never maps anything else there
> - The kernel text being copied at the beginning of the physical memory,
>   it is unlikely to use the last 64kB (I doubt we'll ever support KVM
>   on a system with something like 4MB of RAM, but patches are very
>   welcome).
> 
> Let's call this VA the trampoline VA.
> 
> Now, we map our init page at 3 locations:
> - idmap in the boot pgd
> - trampoline VA in the boot pgd
> - trampoline VA in the runtime pgd
> 
> The init scenario is now the following:
> - We jump in HYP with four parameters: boot HYP pgd, runtime HYP pgd,
>   runtime stack, runtime vectors
> - Enable the MMU with the boot pgd
> - Jump to a target into the trampoline page (remember, this is the same
>   physical page!)
> - Now switch to the runtime pgd (same VA, and still the same physical
>   page!)
> - Invalidate TLBs
> - Set stack and vectors
> - Profit! (or eret, if you only care about the code).
> 
> Note that we keep the boot mapping permanently (it is not strictly an
> idmap anymore) to allow for CPU hotplug in later patches.
> 
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> ---
>  arch/arm/include/asm/kvm_host.h |  18 ++++--
>  arch/arm/include/asm/kvm_mmu.h  |  24 +++++++-
>  arch/arm/kvm/arm.c              |  11 ++--
>  arch/arm/kvm/init.S             |  44 +++++++++++++-
>  arch/arm/kvm/mmu.c              | 129 ++++++++++++++++++++++++++++------------
>  5 files changed, 173 insertions(+), 53 deletions(-)
> 
> diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
> index a856cc2..9fe22ee 100644
> --- a/arch/arm/include/asm/kvm_host.h
> +++ b/arch/arm/include/asm/kvm_host.h
> @@ -190,22 +190,32 @@ int kvm_arm_coproc_set_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *);
>  int handle_exit(struct kvm_vcpu *vcpu, struct kvm_run *run,
>                 int exception_index);
> 
> -static inline void __cpu_init_hyp_mode(unsigned long long pgd_ptr,
> +static inline void __cpu_init_hyp_mode(unsigned long long boot_pgd_ptr,
> +                                      unsigned long long pgd_ptr,
>                                        unsigned long hyp_stack_ptr,
>                                        unsigned long vector_ptr)
>  {
>         unsigned long pgd_low, pgd_high;
> 
> -       pgd_low = (pgd_ptr & ((1ULL << 32) - 1));
> -       pgd_high = (pgd_ptr >> 32ULL);
> +       pgd_low = (boot_pgd_ptr & ((1ULL << 32) - 1));
> +       pgd_high = (boot_pgd_ptr >> 32ULL);
> 
>         /*
>          * Call initialization code, and switch to the full blown
>          * HYP code. The init code doesn't need to preserve these registers as
> -        * r1-r3 and r12 are already callee save according to the AAPCS.
> +        * r1-r3 and r12 are already callee saved according to the AAPCS.
>          * Note that we slightly misuse the prototype by casing the pgd_low to
>          * a void *.
> +        *
> +        * We don't have enough registers to perform the full init in one go.
> +        * Install the boot PGD first, and then install the runtime PGD,
> +        * stack pointer and vectors.
>          */
> +       kvm_call_hyp((void *)pgd_low, pgd_high, 0, 0);
> +
> +       pgd_low = (pgd_ptr & ((1ULL << 32) - 1));
> +       pgd_high = (pgd_ptr >> 32ULL);

It might be worth macro-ising the low/high extraction operations now that
you're using them twice. Hell, you could even make them big-endian clean!

>         kvm_call_hyp((void *)pgd_low, pgd_high, hyp_stack_ptr, vector_ptr);
>  }
> 
> diff --git a/arch/arm/include/asm/kvm_mmu.h b/arch/arm/include/asm/kvm_mmu.h
> index 92eb20d..24b767a 100644
> --- a/arch/arm/include/asm/kvm_mmu.h
> +++ b/arch/arm/include/asm/kvm_mmu.h
> @@ -19,17 +19,29 @@
>  #ifndef __ARM_KVM_MMU_H__
>  #define __ARM_KVM_MMU_H__
> 
> -#include <asm/cacheflush.h>
> -#include <asm/pgalloc.h>
> +#include <asm/memory.h>
> +#include <asm/page.h>
> 
>  /*
>   * We directly use the kernel VA for the HYP, as we can directly share
>   * the mapping (HTTBR "covers" TTBR1).
>   */
> -#define HYP_PAGE_OFFSET_MASK   (~0UL)
> +#define HYP_PAGE_OFFSET_MASK   UL(~0)
>  #define HYP_PAGE_OFFSET                PAGE_OFFSET
>  #define KERN_TO_HYP(kva)       (kva)
> 
> +/*
> + * Our virtual mapping for the boot-time MMU-enable code. Must be
> + * shared across all the page-tables. Conveniently, we use the vectors
> + * page, where no kernel data will ever be shared with HYP.
> + */
> +#define TRAMPOLINE_VA          UL(CONFIG_VECTORS_BASE)
> +
> +#ifndef __ASSEMBLY__
> +
> +#include <asm/cacheflush.h>
> +#include <asm/pgalloc.h>
> +
>  int create_hyp_mappings(void *from, void *to);
>  int create_hyp_io_mappings(void *from, void *to, phys_addr_t);
>  void free_hyp_pgds(void);
> @@ -44,6 +56,8 @@ int kvm_handle_guest_abort(struct kvm_vcpu *vcpu, struct kvm_run *run);
>  void kvm_mmu_free_memory_caches(struct kvm_vcpu *vcpu);
> 
>  phys_addr_t kvm_mmu_get_httbr(void);
> +phys_addr_t kvm_mmu_get_boot_httbr(void);
> +phys_addr_t kvm_get_idmap_vector(void);
>  int kvm_mmu_init(void);
>  void kvm_clear_hyp_idmap(void);
> 
> @@ -113,4 +127,8 @@ static inline void coherent_icache_guest_page(struct kvm *kvm, gfn_t gfn)
>         }
>  }
> 
> +#define kvm_flush_dcache_to_poc(a,l)   __cpuc_flush_dcache_area((a), (l))
> +
> +#endif /* !__ASSEMBLY__ */
> +
>  #endif /* __ARM_KVM_MMU_H__ */
> diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
> index 8d44ef4..9010a12 100644
> --- a/arch/arm/kvm/arm.c
> +++ b/arch/arm/kvm/arm.c
> @@ -796,20 +796,22 @@ long kvm_arch_vm_ioctl(struct file *filp,
> 
>  static void cpu_init_hyp_mode(void *vector)
>  {
> +       unsigned long long boot_pgd_ptr;
>         unsigned long long pgd_ptr;
>         unsigned long hyp_stack_ptr;
>         unsigned long stack_page;
>         unsigned long vector_ptr;
> 
>         /* Switch from the HYP stub to our own HYP init vector */
> -       __hyp_set_vectors((unsigned long)vector);
> +       __hyp_set_vectors(kvm_get_idmap_vector());
> 
> +       boot_pgd_ptr = (unsigned long long)kvm_mmu_get_boot_httbr();
>         pgd_ptr = (unsigned long long)kvm_mmu_get_httbr();

Strictly speaking, could you avoid using two sets of tables for this? That
is, have code in the trampoline page which remaps the rest of the address
space using the current tables? Not saying it's feasible, just interested.

>         stack_page = __get_cpu_var(kvm_arm_hyp_stack_page);
>         hyp_stack_ptr = stack_page + PAGE_SIZE;
>         vector_ptr = (unsigned long)__kvm_hyp_vector;
> 
> -       __cpu_init_hyp_mode(pgd_ptr, hyp_stack_ptr, vector_ptr);
> +       __cpu_init_hyp_mode(boot_pgd_ptr, pgd_ptr, hyp_stack_ptr, vector_ptr);
>  }
> 
>  /**
> @@ -863,11 +865,6 @@ static int init_hyp_mode(void)
>         }
> 
>         /*
> -        * Unmap the identity mapping
> -        */
> -       kvm_clear_hyp_idmap();
> -
> -       /*
>          * Map the Hyp-code called directly from the host
>          */
>         err = create_hyp_mappings(__kvm_hyp_code_start, __kvm_hyp_code_end);
> diff --git a/arch/arm/kvm/init.S b/arch/arm/kvm/init.S
> index 9f37a79..0ca054f 100644
> --- a/arch/arm/kvm/init.S
> +++ b/arch/arm/kvm/init.S
> @@ -21,6 +21,7 @@
>  #include <asm/asm-offsets.h>
>  #include <asm/kvm_asm.h>
>  #include <asm/kvm_arm.h>
> +#include <asm/kvm_mmu.h>
> 
>  /********************************************************************
>   * Hypervisor initialization
> @@ -28,6 +29,25 @@
>   *       r0,r1 = Hypervisor pgd pointer
>   *       r2 = top of Hyp stack (kernel VA)
>   *       r3 = pointer to hyp vectors
> + *
> + * The init scenario is:
> + * - We jump in HYP with four parameters: boot HYP pgd, runtime HYP pgd,
> + *   runtime stack, runtime vectors
> + * - Enable the MMU with the boot pgd
> + * - Jump to a target into the trampoline page (remember, this is the same
> + *   physical page!)
> + * - Now switch to the runtime pgd (same VA, and still the same physical
> + *   page!)
> + * - Invalidate TLBs
> + * - Set stack and vectors
> + * - Profit! (or eret, if you only care about the code).
> + *
> + * As we only have four registers available to pass parameters (and we
> + * need six), we split the init in two phases:
> + * - Phase 1: r0,r1 contain the boot PGD, r2 = 0, r3 = 0.
> + *   Provides the basic HYP init, and enable the MMU.
> + * - Phase 2: r0,r1 contain the runtime PGD, r2 = ToS, r3 = vectors
> + *   Switches to the runtime PGD, set stack and vectors.
>   */
> 
>         .text
> @@ -47,6 +67,9 @@ __kvm_hyp_init:
>         W(b)    .
> 
>  __do_hyp_init:
> +       cmp     r2, #0                  @ We have a SP?
> +       bne     phase2                  @ Yes, second stage init
> +
>         @ Set the HTTBR to point to the hypervisor PGD pointer passed
>         mcrr    p15, 4, r0, r1, c2
> 
> @@ -96,14 +119,31 @@ __do_hyp_init:
>         orr     r0, r0, r1
>         isb
>         mcr     p15, 4, r0, c1, c0, 0   @ HSCR
> -       isb
> 
> -       @ Set stack pointer and return to the kernel
> +       @ End of init phase-1
> +       eret
> +
> +phase2:
> +       @ Set stack pointer
>         mov     sp, r2
> 
>         @ Set HVBAR to point to the HYP vectors
>         mcr     p15, 4, r3, c12, c0, 0  @ HVBAR
> 
> +       @ Jump to the trampoline page
> +       ldr     r2, =TRAMPOLINE_VA
> +       adr     r3, target
> +       bfi     r2, r3, #0, #PAGE_SHIFT
> +       mov     pc, r2
> +
> +target:        @ We're now in the trampoline code, switch page tables
> +       mcrr    p15, 4, r0, r1, c2
> +       isb
> +
> +       @ Invalidate the old TLBs
> +       mcr     p15, 4, r0, c8, c7, 0   @ TLBIALLH
> +       dsb
> +
>         eret
> 
>         .ltorg
> diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
> index c4236e4..b20eff2 100644
> --- a/arch/arm/kvm/mmu.c
> +++ b/arch/arm/kvm/mmu.c
> @@ -32,9 +32,15 @@
> 
>  extern char  __hyp_idmap_text_start[], __hyp_idmap_text_end[];
> 
> +static pgd_t *boot_hyp_pgd;
>  static pgd_t *hyp_pgd;
>  static DEFINE_MUTEX(kvm_hyp_pgd_mutex);
> 
> +static void *init_bounce_page;
> +static unsigned long hyp_idmap_start;
> +static unsigned long hyp_idmap_end;
> +static phys_addr_t hyp_idmap_vector;
> +
>  static void kvm_tlb_flush_vmid_ipa(struct kvm *kvm, phys_addr_t ipa)
>  {
>         kvm_call_hyp(__kvm_tlb_flush_vmid_ipa, kvm, ipa);
> @@ -108,9 +114,12 @@ static void free_hyp_pgd_entry(pgd_t *pgdp, unsigned long addr)
>  /**
>   * free_hyp_pgds - free Hyp-mode page tables
>   *
> - * Assumes hyp_pgd is a page table used strictly in Hyp-mode and therefore contains
> - * either mappings in the kernel memory area (above PAGE_OFFSET), or
> - * device mappings in the vmalloc range (from VMALLOC_START to VMALLOC_END).
> + * Assumes hyp_pgd is a page table used strictly in Hyp-mode and
> + * therefore contains either mappings in the kernel memory area (above
> + * PAGE_OFFSET), or device mappings in the vmalloc range (from
> + * VMALLOC_START to VMALLOC_END).
> + *
> + * boot_hyp_pgd should only map two pages for the init code.
>   */
>  void free_hyp_pgds(void)
>  {
> @@ -118,6 +127,12 @@ void free_hyp_pgds(void)
> 
>         mutex_lock(&kvm_hyp_pgd_mutex);
> 
> +       if (boot_hyp_pgd) {
> +               free_hyp_pgd_entry(boot_hyp_pgd, hyp_idmap_start);
> +               free_hyp_pgd_entry(boot_hyp_pgd, TRAMPOLINE_VA);
> +               kfree(boot_hyp_pgd);
> +       }
> +
>         if (hyp_pgd) {
>                 for (addr = PAGE_OFFSET; virt_addr_valid(addr); addr += PGDIR_SIZE)
>                         free_hyp_pgd_entry(hyp_pgd, KERN_TO_HYP(addr));
> @@ -126,6 +141,7 @@ void free_hyp_pgds(void)
>                 kfree(hyp_pgd);
>         }
> 
> +       kfree(init_bounce_page);
>         mutex_unlock(&kvm_hyp_pgd_mutex);
>  }
> 
> @@ -718,14 +734,62 @@ phys_addr_t kvm_mmu_get_httbr(void)
>         return virt_to_phys(hyp_pgd);
>  }
> 
> +phys_addr_t kvm_mmu_get_boot_httbr(void)
> +{
> +       VM_BUG_ON(!virt_addr_valid(boot_hyp_pgd));

Seems a bit OTT -- it's always going to be in lowmem.

> +       return virt_to_phys(boot_hyp_pgd);
> +}
> +
> +phys_addr_t kvm_get_idmap_vector(void)
> +{
> +       return hyp_idmap_vector;
> +}
> +
>  int kvm_mmu_init(void)
>  {
> -       unsigned long hyp_idmap_start = virt_to_phys(__hyp_idmap_text_start);
> -       unsigned long hyp_idmap_end = virt_to_phys(__hyp_idmap_text_end);
>         int err;
> 
> +       hyp_idmap_start = virt_to_phys(__hyp_idmap_text_start);
> +       hyp_idmap_end = virt_to_phys(__hyp_idmap_text_end);
> +       hyp_idmap_vector = virt_to_phys(__kvm_hyp_init);
> +
> +       if ((hyp_idmap_start ^ hyp_idmap_end) & PAGE_MASK) {
> +               /*
> +                * Our init code is crossing a page boundary. Allocate
> +                * a bounce page, copy the code over and use that.
> +                */
> +               size_t len = __hyp_idmap_text_end - __hyp_idmap_text_start;
> +               phys_addr_t phys_base;
> +
> +               init_bounce_page = kzalloc(PAGE_SIZE, GFP_KERNEL);
> +               if (!init_bounce_page) {
> +                       kvm_err("Couldn't allocate HYP init bounce page\n");
> +                       err = -ENOMEM;
> +                       goto out;
> +               }

Given that you don't really need a lowmem page for the bounce page, this
might be better expressed using alloc_page and kmap for the memcpy.

I also wonder whether or not you can eventually free the page and
corresponding mappings if !CONFIG_HOTPLUG_CPU?

> +               memcpy(init_bounce_page, __hyp_idmap_text_start, len);
> +               /*
> +                * Warning: the code we just copied to the bounce page
> +                * must be flushed to the point of coherency.
> +                * Otherwise, the data may be sitting in L2, and HYP
> +                * mode won't be able to observe it as it runs with
> +                * caches off at that point.
> +                */
> +               kvm_flush_dcache_to_poc(init_bounce_page, len);
> +
> +               phys_base = virt_to_phys(init_bounce_page);
> +               hyp_idmap_vector += phys_base - hyp_idmap_start;
> +               hyp_idmap_start = phys_base;
> +               hyp_idmap_end = phys_base + len;
> +
> +               kvm_info("Using HYP init bounce page @%lx\n",
> +                        (unsigned long)phys_base);
> +       }
> +
>         hyp_pgd = kzalloc(PTRS_PER_PGD * sizeof(pgd_t), GFP_KERNEL);
> -       if (!hyp_pgd) {
> +       boot_hyp_pgd = kzalloc(PTRS_PER_PGD * sizeof(pgd_t), GFP_KERNEL);
> +       if (!hyp_pgd || !boot_hyp_pgd) {
>                 kvm_err("Hyp mode PGD not allocated\n");
>                 err = -ENOMEM;
>                 goto out;
> @@ -743,39 +807,30 @@ int kvm_mmu_init(void)
>                 goto out;
>         }
> 
> +       /* Map the very same page at the trampoline VA */
> +       err =   __create_hyp_mappings(boot_hyp_pgd,
> +                                     TRAMPOLINE_VA, TRAMPOLINE_VA + PAGE_SIZE,
> +                                     __phys_to_pfn(hyp_idmap_start),
> +                                     PAGE_HYP);
> +       if (err) {
> +               kvm_err("Failed to map trampoline @%lx into boot HYP pgd\n",
> +                       TRAMPOLINE_VA);
> +               goto out;
> +       }
> +
> +       /* Map the same page again into the runtime page tables */
> +       err =   __create_hyp_mappings(hyp_pgd,
> +                                     TRAMPOLINE_VA, TRAMPOLINE_VA + PAGE_SIZE,
> +                                     __phys_to_pfn(hyp_idmap_start),
> +                                     PAGE_HYP);
> +       if (err) {
> +               kvm_err("Failed to map trampoline @%lx into runtime HYP pgd\n",
> +                       TRAMPOLINE_VA);
> +               goto out;
> +       }

I'm probably just missing it, but where are the updated page tables flushed
to memory?

Will


From arnd at arndb.de  Tue Apr  9 05:21:24 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 9 Apr 2013 11:21:24 +0200
Subject: linux-next: build warning after merge of the final tree (probably
 arm-soc tree related)
In-Reply-To: <20130409190900.97dcf3a70a9c0ad727b8bc4b@canb.auug.org.au>
References: <20130409190900.97dcf3a70a9c0ad727b8bc4b@canb.auug.org.au>
Message-ID: <201304091121.24372.arnd@arndb.de>

On Tuesday 09 April 2013, Stephen Rothwell wrote:
> After merging the final tree, today's linux-next build (arm defconfig)
> produced these warnings:
> 
> arch/arm/mach-cns3xxx/Kconfig:2:warning: choice value used outside its choice group
> arch/arm/mach-bcm2835/Kconfig:2:warning: choice value used outside its choice group
> arch/arm/Kconfig:287:error: recursive dependency detected!
> arch/arm/Kconfig:287:   choice <choice> contains symbol ARCH_CNS3XXX
> arch/arm/Kconfig:366:   symbol ARCH_CNS3XXX depends on ARCH_MULTI_V6
> arch/arm/Kconfig:933:   symbol ARCH_MULTI_V6 depends on ARCH_MULTIPLATFORM
> arch/arm/Kconfig:292:   symbol ARCH_MULTIPLATFORM is part of choice <choice>

Thanks for the notification, I think git rerere picked up a wrong conflict resolution
again that I did earlier. I'll fix it when I do the next pulls today.

	Arnd


From fabio.porcedda at gmail.com  Tue Apr  9 05:23:21 2013
From: fabio.porcedda at gmail.com (Fabio Porcedda)
Date: Tue, 9 Apr 2013 11:23:21 +0200
Subject: [PATCH 08/10] drivers: mfd: use module_platform_driver_probe()
In-Reply-To: <20130409080653.GG24058@zurbaran>
References: <1363266691-15757-1-git-send-email-fabio.porcedda@gmail.com>
 <1363266691-15757-10-git-send-email-fabio.porcedda@gmail.com>
 <20130409080653.GG24058@zurbaran>
Message-ID: <CAHkwnC_Mq4YtY1SVFRAFPVBVajbK2dTnDOwNBQKeTdY_jDT5nA@mail.gmail.com>

On Tue, Apr 9, 2013 at 10:06 AM, Samuel Ortiz <sameo at linux.intel.com> wrote:
> Hi Fabio,
>
> On Thu, Mar 14, 2013 at 02:11:29PM +0100, Fabio Porcedda wrote:
>> This patch converts the drivers to use the
>> module_platform_driver_probe() macro which makes the code smaller and
>> a bit simpler.
>>
>> Signed-off-by: Fabio Porcedda <fabio.porcedda at gmail.com>
>> Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
>> Cc: Linus Walleij <linus.walleij at linaro.org>
>> Cc: Samuel Ortiz <sameo at linux.intel.com>
>> Cc: linux-arm-kernel at lists.infradead.org
>> ---
>>  drivers/mfd/davinci_voicecodec.c | 12 +-----------
>>  drivers/mfd/htc-pasic3.c         | 13 +------------
>>  2 files changed, 2 insertions(+), 23 deletions(-)
> Jingoo Han sent a larger patchset to convert many MFD drivers to
> module_platform_driver_probe(), including htc-pasic3 and davinci_voicecodec.
>
> See my mfd-next tree for more details.

I understand, thanks for letting me know.

It's my fault for having waited too long to send this patch set.

Best regards
--
Fabio Porcedda

> Cheers,
> Samuel.
>
> --
> Intel Open Source Technology Centre
> http://oss.intel.com/


From fabio.baltieri at linaro.org  Tue Apr  9 05:16:56 2013
From: fabio.baltieri at linaro.org (Fabio Baltieri)
Date: Tue,  9 Apr 2013 11:16:56 +0200
Subject: [PATCH] ARM: ux500: Fix intcore regulator name
Message-ID: <1365499016-8348-1-git-send-email-fabio.baltieri@linaro.org>

Ux500 regulator name for V-INTCORE is misspelled as vinitcore instead of
vintcore in some .dts file, causing the AB8500 regulator driver to not
bind properly.  Fix this by replacing all occurrences with the right
name.

Acked-by: Lee Jones <lee.jones at linaro.org>
Signed-off-by: Fabio Baltieri <fabio.baltieri at linaro.org>
---
 Documentation/devicetree/bindings/mfd/ab8500.txt | 2 +-
 arch/arm/boot/dts/dbx5x0.dtsi                    | 6 +++---
 arch/arm/boot/dts/href.dtsi                      | 2 +-
 arch/arm/boot/dts/hrefv60plus.dts                | 2 +-
 arch/arm/boot/dts/snowball.dts                   | 2 +-
 5 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/Documentation/devicetree/bindings/mfd/ab8500.txt b/Documentation/devicetree/bindings/mfd/ab8500.txt
index c3a14e0..cd9e90c 100644
--- a/Documentation/devicetree/bindings/mfd/ab8500.txt
+++ b/Documentation/devicetree/bindings/mfd/ab8500.txt
@@ -120,7 +120,7 @@ ab8500 {
                                   "USB_LINK_STATUS",
                                   "USB_ADP_PROBE_PLUG",
                                   "USB_ADP_PROBE_UNPLUG";
-                vddulpivio18-supply = <&ab8500_ldo_initcore_reg>;
+                vddulpivio18-supply = <&ab8500_ldo_intcore_reg>;
                 v-ape-supply = <&db8500_vape_reg>;
                 musb_1v8-supply = <&db8500_vsmps2_reg>;
         };
diff --git a/arch/arm/boot/dts/dbx5x0.dtsi b/arch/arm/boot/dts/dbx5x0.dtsi
index 9de9309..70e5d5a 100644
--- a/arch/arm/boot/dts/dbx5x0.dtsi
+++ b/arch/arm/boot/dts/dbx5x0.dtsi
@@ -383,7 +383,7 @@
 							  "USB_LINK_STATUS",
 							  "USB_ADP_PROBE_PLUG",
 							  "USB_ADP_PROBE_UNPLUG";
-					vddulpivio18-supply = <&ab8500_ldo_initcore_reg>;
+					vddulpivio18-supply = <&ab8500_ldo_intcore_reg>;
 					v-ape-supply = <&db8500_vape_reg>;
 					musb_1v8-supply = <&db8500_vsmps2_reg>;
 				};
@@ -441,8 +441,8 @@
 					};
 
 					// supply for v-intcore12; VINTCORE12 LDO
-					ab8500_ldo_initcore_reg: ab8500_ldo_initcore {
-						regulator-compatible = "ab8500_ldo_initcore";
+					ab8500_ldo_intcore_reg: ab8500_ldo_intcore {
+						regulator-compatible = "ab8500_ldo_intcore";
 					};
 
 					// supply for tvout; gpadc; TVOUT LDO
diff --git a/arch/arm/boot/dts/href.dtsi b/arch/arm/boot/dts/href.dtsi
index 379128e..2e0978a 100644
--- a/arch/arm/boot/dts/href.dtsi
+++ b/arch/arm/boot/dts/href.dtsi
@@ -235,7 +235,7 @@
 						regulator-name = "V-MMC-SD";
 					};
 
-					ab8500_ldo_initcore_reg: ab8500_ldo_initcore {
+					ab8500_ldo_intcore_reg: ab8500_ldo_intcore {
 						regulator-name = "V-INTCORE";
 					};
 
diff --git a/arch/arm/boot/dts/hrefv60plus.dts b/arch/arm/boot/dts/hrefv60plus.dts
index 2b587a7..27fabc8 100644
--- a/arch/arm/boot/dts/hrefv60plus.dts
+++ b/arch/arm/boot/dts/hrefv60plus.dts
@@ -172,7 +172,7 @@
 						regulator-name = "V-MMC-SD";
 					};
 
-					ab8500_ldo_initcore_reg: ab8500_ldo_initcore {
+					ab8500_ldo_intcore_reg: ab8500_ldo_intcore {
 						regulator-name = "V-INTCORE";
 					};
 
diff --git a/arch/arm/boot/dts/snowball.dts b/arch/arm/boot/dts/snowball.dts
index d3ec32f..5e3438b 100644
--- a/arch/arm/boot/dts/snowball.dts
+++ b/arch/arm/boot/dts/snowball.dts
@@ -312,7 +312,7 @@
 						regulator-name = "V-MMC-SD";
 					};
 
-					ab8500_ldo_initcore_reg: ab8500_ldo_initcore {
+					ab8500_ldo_intcore_reg: ab8500_ldo_intcore {
 						regulator-name = "V-INTCORE";
 					};
 
-- 
1.8.1.3



From sebastian.hesselbarth at gmail.com  Tue Apr  9 05:25:41 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Tue, 9 Apr 2013 11:25:41 +0200
Subject: [PATCH] clk: si5351: Add gapless tuning for SI5351 PLL
In-Reply-To: <1365495975-792-1-git-send-email-michal.bachraty@streamunlimited.com>
References: <1365495975-792-1-git-send-email-michal.bachraty@streamunlimited.com>
Message-ID: <CABJ1b_RW=UUxmTrYOsx2wsDm1egs9DL3dWtat0--5kqec9-rQA@mail.gmail.com>

On Tue, Apr 9, 2013 at 10:26 AM, Michal Bachraty
<michal.bachraty at streamunlimited.com> wrote:
> For gapless tuning, there is no need for PLL reset and clkout power-down
> when tuning output. "silabs,gapless-tuning" parameter enables gapless tuning
> for specific clock output.

Michal,

does gapless tuning have any constraints? Can we use it for all rate
changes or determine the
need for pll reset by rate offset?

Sebastian


From mark.rutland at arm.com  Tue Apr  9 05:27:11 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Tue, 9 Apr 2013 10:27:11 +0100
Subject: [PATCH 01/02] ARM: shmobile: force enable of r8a7790 arch timer
In-Reply-To: <20130408012328.13555.44487.sendpatchset@w520>
References: <20130408012318.13555.58237.sendpatchset@w520>
 <20130408012328.13555.44487.sendpatchset@w520>
Message-ID: <20130409092711.GT23725@e106331-lin.cambridge.arm.com>

Adding Stephen Boyd and Marc Zyngier to Cc as they're both familiar with the
architected timer.

On Mon, Apr 08, 2013 at 02:23:28AM +0100, Magnus Damm wrote:
> From: Magnus Damm <damm at opensource.se>
> 
> Implement a SoC-specific timer init function for
> r8a7790 that makes sure the architected timer
> is started regardless of boot loader setting.
> 
> Signed-off-by: Magnus Damm <damm at opensource.se>
> ---
> 
>  arch/arm/mach-shmobile/include/mach/r8a7790.h |    1 +
>  arch/arm/mach-shmobile/setup-r8a7790.c        |   14 +++++++++++++-
>  2 files changed, 14 insertions(+), 1 deletion(-)
> 
> --- 0001/arch/arm/mach-shmobile/include/mach/r8a7790.h
> +++ work/arch/arm/mach-shmobile/include/mach/r8a7790.h	2013-04-08 10:13:38.000000000 +0900
> @@ -4,5 +4,6 @@
>  void r8a7790_add_standard_devices(void);
>  void r8a7790_clock_init(void);
>  void r8a7790_pinmux_init(void);
> +void r8a7790_timer_init(void);
>  
>  #endif /* __ASM_R8A7790_H__ */
> --- 0001/arch/arm/mach-shmobile/setup-r8a7790.c
> +++ work/arch/arm/mach-shmobile/setup-r8a7790.c	2013-04-08 10:13:38.000000000 +0900
> @@ -117,6 +117,18 @@ void __init r8a7790_add_standard_devices
>  	r8a7790_register_irqc(0);
>  }
>  
> +void __init r8a7790_timer_init(void)
> +{
> +	void __iomem *cntcr;
> +
> +	/* make sure arch timer is started by setting bit 0 of CNTCT */

Typo: CNTCT should be CNTCR above.

> +	cntcr = ioremap(0xe6080000, PAGE_SIZE);
> +	iowrite32(1, cntcr);
> +	iounmap(cntcr);
> +
> +	shmobile_timer_init();
> +}

Does this mean you have memory-mapped timers and CP15 timers linked together?

Why do your firmware and bootloader not set this up?

Mark.


From arnd at arndb.de  Tue Apr  9 05:32:01 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 9 Apr 2013 11:32:01 +0200
Subject: linux-next: manual merge of the arm-soc tree with the omap_dss2
 tree
In-Reply-To: <20130409174047.c506479e08e9688c0a4ced9a@canb.auug.org.au>
References: <20130409174047.c506479e08e9688c0a4ced9a@canb.auug.org.au>
Message-ID: <201304091132.01771.arnd@arndb.de>

On Tuesday 09 April 2013, Stephen Rothwell wrote:
> 
> - #if defined(CONFIG_SMC91X) || defined(CONFIG_SMC91x_MODULE)
>  -static void __init sdp2430_display_init(void)
>  -{
>  -      int r;
>  -
>  -      static struct gpio gpios[] __initdata = {
>  -              { SDP2430_LCD_PANEL_ENABLE_GPIO, GPIOF_OUT_INIT_LOW,
>  -                      "LCD reset" },
>  -              { SDP2430_LCD_PANEL_BACKLIGHT_GPIO, GPIOF_OUT_INIT_LOW,
>  -                      "LCD Backlight" },
>  -      };
>  -
>  -      r = gpio_request_array(gpios, ARRAY_SIZE(gpios));
>  -      if (r) {
>  -              pr_err("Cannot request LCD GPIOs, error %d\n", r);
>  -              return;
>  -      }
>  -
>  -      omap_display_init(&sdp2430_dss_data);
>  -}
>  -
> + #if IS_ENABLED(CONFIG_SMC91X)

Looks good, thanks!

	Arnd


From arnd at arndb.de  Tue Apr  9 05:35:11 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 9 Apr 2013 11:35:11 +0200
Subject: [PATCH 1/5] ARM: ux500: Move DMA40 platform data includes file
 out to include/
In-Reply-To: <20130409070558.GG3084@gmail.com>
References: <1365434591-21569-1-git-send-email-lee.jones@linaro.org>
 <201304081817.42031.arnd@arndb.de> <20130409070558.GG3084@gmail.com>
Message-ID: <201304091135.11427.arnd@arndb.de>

On Tuesday 09 April 2013, Lee Jones wrote:
> On Mon, 08 Apr 2013, Arnd Bergmann wrote:
> 
> > On Monday 08 April 2013, Lee Jones wrote:
> > > The pin names for DB8500 based platforms need to be moved out of
> > > ux500 platform data and into the new proper location in include/
> > > linux/platform_data/. This way we an reference them from other
> > > external locations, such as the main DMA50 driver(s).
> > > 
> > > Signed-off-by: Lee Jones <lee.jones at linaro.org>
> > 
> > Hmm, not sure about this one. The slave numbers are not really platform_data
> > and I think they should not be exposed to drivers. It makes sense to
> > keep the numbers for the memcpy channels in the driver itself as they
> > are hardwired in the driver, but the slave channels should stay in the
> > platform I think.
> 
> Just looking at this again now. So you're right in that the main
> reason for moving these out of platform code and into the system-wide
> platform data area is for the memcpy channels. However, I'd prefer to
> keep the channel allocation enum fully contiguous rather than
> splitting them out.
> 
> The channels are only exposed to the one external driver which
> includes them, and that's the D40 driver.
> 
> How against this move are you?

I think it's a move in the wrong direction. If you think we should keep the
knowledge of which channels are used for memcpy outside of the driver,
I would prefer you to drop the the first two patches, which implies that
we will eventually pass that information using DT properties in order get
rid of the auxdata.

	Arnd


From arnd at arndb.de  Tue Apr  9 05:36:09 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 9 Apr 2013 11:36:09 +0200
Subject: [PATCH 4/5] dmaengine: ste_dma40: Do not configure channels
 during an channel allocation
In-Reply-To: <20130409071154.GH3084@gmail.com>
References: <1365434591-21569-1-git-send-email-lee.jones@linaro.org>
 <1365434591-21569-4-git-send-email-lee.jones@linaro.org>
 <20130409071154.GH3084@gmail.com>
Message-ID: <201304091136.09629.arnd@arndb.de>

On Tuesday 09 April 2013, Lee Jones wrote:
> According to the DMA documentation allocating a channel and configuring
> it are two separate actions. By removing the configuration code from the
> channel allocation path we lighten the burden on the information required to
> successfully allocate a channel.

Did you send out the first version again? The text is the same as before.

	Arnd


From wsa at the-dreams.de  Tue Apr  9 05:37:39 2013
From: wsa at the-dreams.de (Wolfram Sang)
Date: Tue, 9 Apr 2013 11:37:39 +0200
Subject: [PATCH] i2c: s3c2410: Add SMBus emulation for block read
In-Reply-To: <1364308196-10101-1-git-send-email-prasanna.ps@samsung.com>
References: <1364308196-10101-1-git-send-email-prasanna.ps@samsung.com>
Message-ID: <20130409093739.GH3624@the-dreams.de>

On Tue, Mar 26, 2013 at 07:59:56PM +0530, Prasanna Kumar wrote:
> From: Jaemin Yoo <jmin.yoo at samsung.com>
> 
> SMBus read and write are supported by the emulation layer of i2c
> framework if the controller doesn't have SMBus features.
> 
> I2C_M_RECV_LEN flag is used to let i2c drivers know rx length is not
> yet determined but will be read to the first byte in rx buffer.
> 
> s3c2410 doesn't handle this flag. So only one byte is read from slave.
> There fore following two features are added to the driver code.
> 
> 1. skip rx length check if I2C_M_RECV_LEN is set and the length is 1.
> 2. add actual bytes to the rx length after reading first bytes if
>    I2C_M_RECV_LEN.
> 
> I2C_M_RECV_LEN is only set for SMBus command. So this code does not
> affect legacy codes which only use i2c command for s3c2410.
> 
> Signed-off-by: Jaemin Yoo <jmin.yoo at samsung.com>
> Tested-by: Prasanna Kumar <prasanna.ps at samsung.com>

Applied to for-next, thanks!



From mark.rutland at arm.com  Tue Apr  9 05:38:56 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Tue, 9 Apr 2013 10:38:56 +0100
Subject: [PATCH 3/4] clocksource: arch_timer: Push the read/write
 wrappers deeper
In-Reply-To: <1365474623-29181-4-git-send-email-sboyd@codeaurora.org>
References: <1365474623-29181-1-git-send-email-sboyd@codeaurora.org>
 <1365474623-29181-4-git-send-email-sboyd@codeaurora.org>
Message-ID: <20130409093855.GU23725@e106331-lin.cambridge.arm.com>

Hi,

On Tue, Apr 09, 2013 at 03:30:22AM +0100, Stephen Boyd wrote:
> We're going to introduce support to read and write the memory
> mapped timer registers in the next patch, so push the cp15
> read/write functions one level deeper. This simplifies the next
> patch and makes it clearer what's going on.
> 
> Cc: Mark Rutland <mark.rutland at arm.com>
> Cc: Marc Zyngier <Marc.Zyngier at arm.com>
> Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
> ---
>  arch/arm/include/asm/arch_timer.h    |  5 ++--
>  arch/arm64/include/asm/arch_timer.h  |  4 ++--
>  drivers/clocksource/arm_arch_timer.c | 44 ++++++++++++++++++++++++------------
>  3 files changed, 34 insertions(+), 19 deletions(-)
> 
> diff --git a/arch/arm/include/asm/arch_timer.h b/arch/arm/include/asm/arch_timer.h
> index 35fea17..560f8a0 100644
> --- a/arch/arm/include/asm/arch_timer.h
> +++ b/arch/arm/include/asm/arch_timer.h
> @@ -18,7 +18,8 @@ int arch_timer_sched_clock_init(void);
>   * nicely work out which register we want, and chuck away the rest of
>   * the code. At least it does so with a recent GCC (4.6.3).
>   */
> -static inline void arch_timer_reg_write(const int access, const int reg, u32 val)
> +static inline void __arch_timer_reg_write(const int access, const int reg,
> +					  u32 val)
>  {
>  	if (access == ARCH_TIMER_PHYS_ACCESS) {
>  		switch (reg) {
> @@ -45,7 +46,7 @@ static inline void arch_timer_reg_write(const int access, const int reg, u32 val
>  	isb();
>  }
>  
> -static inline u32 arch_timer_reg_read(const int access, const int reg)
> +static inline u32 __arch_timer_reg_read(const int access, const int reg)

Rather than prefixing all of these with "__", why not add "cp15" to the names?

I think that'd make the end result more consistent and clearer, as we'd have a
_mem version and a _cp15 version of each function.

Mark.


From arnd at arndb.de  Tue Apr  9 05:40:51 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 9 Apr 2013 11:40:51 +0200
Subject: [PATCH v4 1/5] drivers: memory: Introduce Marvell EBU Device Bus
 driver
In-Reply-To: <20130409004253.GA2258@localhost>
References: <1365419194-20871-1-git-send-email-ezequiel.garcia@free-electrons.com>
 <20130408171940.GA8815@obsidianresearch.com>
 <20130409004253.GA2258@localhost>
Message-ID: <201304091140.51839.arnd@arndb.de>

On Tuesday 09 April 2013, Ezequiel Garcia wrote:
> > This can probably just be of_platform_populate or similar to do all
> > children? For instance, I often use many DT nodes to represent a FPGA,
> > since the my FPGA's tend to have many functionally orthogonal units
> > inside.
> > 
> 
> In the past I've found it's not possible to use of_platform_populate,
> altough I can be wrong.
> 
> The problem seems to be that through of_platform_populate() it's
> possible that the child device (cfi-flash, for instance) gets probed
> before the devbus controller. In other words, the actual parent-child
> relationship gets lost and it's necesarry to use some child probe deferal
> mechanism.
> 
> This has been recently discussed [1] when implementing GPMC where for simplicity
> the of_platform_device_create() solution was chosen.
> Anyway, I'll try of_platform_populate early tomorrow.

I think the problem mentioned in that thread was that the device would
automatically get probed by the top-level of_platform_populate() when
you mark the devbus as compatible="simple-bus", which is not what Jason
was referring to. Instead you should call of_platform_populate in the
probe() function of the devbus device to probe its children after
the bus is set up.

	Arnd


From arnd at arndb.de  Tue Apr  9 05:47:11 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 9 Apr 2013 11:47:11 +0200
Subject: [GIT PULL] at91: DT changes for 3.10 #3
In-Reply-To: <5163CEB7.5030806@atmel.com>
References: <20130402184947.GA8015@quad.lixom.net>
 <1365094799-16940-1-git-send-email-nicolas.ferre@atmel.com>
 <5163CEB7.5030806@atmel.com>
Message-ID: <201304091147.11669.arnd@arndb.de>

On Tuesday 09 April 2013, Nicolas Ferre wrote:
> Ping?
> 
> I saw that you made an update to arm-soc yesterday, and maybe you have
> forgotten this pull-request?
> 

I got about halfway through, but it's still in the queue, planning to merge
it today. My default sort order in the email client is "thread with latest
reply first", so when I went through my pull request folder from the bottom,
I ended up addressing newer mails first ;-)

Thanks for the reminder.

	Arnd


From rogerq at ti.com  Tue Apr  9 05:55:21 2013
From: rogerq at ti.com (Roger Quadros)
Date: Tue, 9 Apr 2013 12:55:21 +0300
Subject: [RFC][PATCH 1/2] ARM: OMAP4: clock: Add device tree support for
 AUXCLKs
In-Reply-To: <20130405155851.GA10155@atomide.com>
References: <1363703220-4777-1-git-send-email-rogerq@ti.com>
 <1363703220-4777-2-git-send-email-rogerq@ti.com>
 <20130403234242.GE10155@atomide.com> <515D2D30.3000306@ti.com>
 <20130404164137.GH10155@atomide.com> <515EA9E3.1010409@ti.com>
 <20130405155851.GA10155@atomide.com>
Message-ID: <5163E589.1040809@ti.com>

On 04/05/2013 06:58 PM, Tony Lindgren wrote:
> * Roger Quadros <rogerq at ti.com> [130405 03:44]:
>> On 04/04/2013 07:41 PM, Tony Lindgren wrote:
>>> * Roger Quadros <rogerq at ti.com> [130404 00:39]:
>>>> On 04/04/2013 02:42 AM, Tony Lindgren wrote:
>>> For v3.10, let's just make sure that USB works with DT as then
>>> after v3.10 we can make omap4 DT only and get rid of estimated
>>> 7K lines of code and data. I guess this is the last piece missing
>>> for that, or are we also missing something else?
>>
>> For panda we just need a way to map the auxclk to the USB PHY device
>> and the relevant dts data to get USB host working with DT.
>> Beagle USB host should work already with DT without any changes.
>>
>>>
>>> Can't you set up a clock alias for your device so it can find the
>>> auxclk when requesting it with the dev entry?
>>>
>>
>> which clock is mapped to which PHY device depends on board design
>> and that cannot be per-determined at one place. This information
>> needs to come from the board.dts file.
> 
> OK that makes sense.
>  
>> There was an earlier attempt to provide a way of building clock aliases
>> at runtime from device tree [1], but the current approach is way better
>>
>> [1]
>> https://lkml.org/lkml/2013/3/12/241
>>
>>> For the DT clock driver if needed for v3.10, how about just do a
>>> minimal drivers/clock/omap/ that uses the standard binding?
>>> Then that driver can just do clk_get() from cclock44xx_data.c
>>
>> I don't understand how to do it and why it is better than the current
>> approach.
> 
> Well your approach is fine as a first step moving all the clock
> code, but it needs to be a real driver under drivers/clock/omap.
> And the DT binding needs to stay the same for the driver(s) in the
> long term as we start moving clocks to DT + /lib/firmware.

The code needs to be there were the clock structs are defined.
Currently they are in arch/arm/mach-omap2/cclock44xx_data.c for OMAP4.

> 
> If this all is too late for v3.10, I suggest you just set up the
> right clock alias for panda with machine_is_compatible flag in
> board-generic.c so we get EHCI working with DT for v3.10. Then
> it's easy to to deal with it properly for v3.11.

OK, let's do it this way for Panda for 3.10.

> 
>> How can that driver do clk_get() from cclock44xx_data.c?
>> from where does it get the clk_id to pass into clk_get()?
> 
> Can't you just use the clock name there to get it?

In device tree we don't pass around clock names. You can either get
a phandle or an index to the clock.

e.g. Documentation/devicetree/bindings/clock/imx31-clock.txt

>  
>>> for now? And then later on we'll just move all the clocks to a
>>> combination of DT + /lib/firmware.
>>
>> What is the benefit of moving clock data to /lib/firmware? We could
>> as well just move it to DT only, no?
> 
> DT only clocks option is naturally available with this too. It
> just gets easily inefficient with such a huge number of clocks.
>  

OK.
>>>> e.g. auxclk are required to be specified in DT nodes for USB PHY.
>>>> Without this we can't get USB host working on Panda.
>>>
>>> OK. So if the USB PHY has a dev entry, can't you just set up a
>>> clock alias in struct omap_clk omap44xx_clks[] for it?
>>
>> I've explained why this can't be done above.
> 
> Yes I understand now, the clock is board specific. 
>   
>>>> As Rajendra points out, it seems moving entire clock data to DT is not
>>>> going to happen soon. So this is the simplistic way things can work.
>>>
>>> Right but seems like we can get started there without moving
>>> them all at once.
>>>
>> What if we provide a complete clock list instead of only auxclks in
>> dt_clks[]?
>>
>> This approach is similar to arch/arm/mach-imx/clk-imx35.c
>>
>> Device drivers can then use them as they migrate to DT. Then later
>> we could migrate clock data to DT, without impacting device drivers.
> 
> As long as the binding stays the same in the long run too, this
> clock remapping approach is just fine as a starting point. And
> the driver needs to go to drivers/clock/omap. But in the long run
> we just want to get the huge amounts static data out of the kernel
> for clocks and hwmod data to fix things for good.

In that case we need to identify what clocks need to be supported.
If it is all (~200) of them, is this method good enough?

cheers,
-roger


From nsekhar at ti.com  Tue Apr  9 05:57:23 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Tue, 9 Apr 2013 15:27:23 +0530
Subject: [PATCH v3 2/3] media: davinci: vpbe: venc: move the enabling
 of vpss clocks to driver
In-Reply-To: <1365423553-12619-3-git-send-email-prabhakar.csengg@gmail.com>
References: <1365423553-12619-1-git-send-email-prabhakar.csengg@gmail.com>
 <1365423553-12619-3-git-send-email-prabhakar.csengg@gmail.com>
Message-ID: <5163E603.3030103@ti.com>



On 4/8/2013 5:49 PM, Prabhakar lad wrote:
> From: Lad, Prabhakar <prabhakar.csengg at gmail.com>
> 
> The vpss clocks were enabled by calling a exported function from a driver
> in a machine code. calling driver code from platform code is incorrect way.
> 
> This patch fixes this issue and calls the function from driver code itself.
> 
> Signed-off-by: Lad, Prabhakar <prabhakar.csengg at gmail.com>
> ---
>  drivers/media/platform/davinci/vpbe_venc.c |   25 +++++++++++++++++++++++++
>  1 files changed, 25 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/media/platform/davinci/vpbe_venc.c b/drivers/media/platform/davinci/vpbe_venc.c
> index f15f211..91d0272 100644
> --- a/drivers/media/platform/davinci/vpbe_venc.c
> +++ b/drivers/media/platform/davinci/vpbe_venc.c
> @@ -202,6 +202,25 @@ static void venc_enabledigitaloutput(struct v4l2_subdev *sd, int benable)
>  	}
>  }
>  
> +static void
> +venc_enable_vpss_clock(int venc_type,
> +		       enum vpbe_enc_timings_type type,
> +		       unsigned int pclock)
> +{
> +	if (venc_type == VPBE_VERSION_1)
> +		return;
> +
> +	if (venc_type == VPBE_VERSION_2 && (type == VPBE_ENC_STD ||
> +	    (type == VPBE_ENC_DV_TIMINGS && pclock <= 27000000))) {

checkpatch --strict will throw a "Alignment should match open
parenthesis" check here. You may want to fix before you send the pull
request. No need to resend the patch just for this.

Thanks,
Sekhar


From prabhakar.csengg at gmail.com  Tue Apr  9 06:03:44 2013
From: prabhakar.csengg at gmail.com (Prabhakar Lad)
Date: Tue, 9 Apr 2013 15:33:44 +0530
Subject: [PATCH v3 2/3] media: davinci: vpbe: venc: move the enabling of
 vpss clocks to driver
In-Reply-To: <5163E603.3030103@ti.com>
References: <1365423553-12619-1-git-send-email-prabhakar.csengg@gmail.com>
 <1365423553-12619-3-git-send-email-prabhakar.csengg@gmail.com>
 <5163E603.3030103@ti.com>
Message-ID: <CA+V-a8vFOh3m1jCBCZmHJyU0+fQFTrj1+cfFAOP4LSCCbY8cBA@mail.gmail.com>

On Tue, Apr 9, 2013 at 3:27 PM, Sekhar Nori <nsekhar at ti.com> wrote:
>
>
> On 4/8/2013 5:49 PM, Prabhakar lad wrote:
>> From: Lad, Prabhakar <prabhakar.csengg at gmail.com>
>>
>> The vpss clocks were enabled by calling a exported function from a driver
>> in a machine code. calling driver code from platform code is incorrect way.
>>
>> This patch fixes this issue and calls the function from driver code itself.
>>
>> Signed-off-by: Lad, Prabhakar <prabhakar.csengg at gmail.com>
>> ---
>>  drivers/media/platform/davinci/vpbe_venc.c |   25 +++++++++++++++++++++++++
>>  1 files changed, 25 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/media/platform/davinci/vpbe_venc.c b/drivers/media/platform/davinci/vpbe_venc.c
>> index f15f211..91d0272 100644
>> --- a/drivers/media/platform/davinci/vpbe_venc.c
>> +++ b/drivers/media/platform/davinci/vpbe_venc.c
>> @@ -202,6 +202,25 @@ static void venc_enabledigitaloutput(struct v4l2_subdev *sd, int benable)
>>       }
>>  }
>>
>> +static void
>> +venc_enable_vpss_clock(int venc_type,
>> +                    enum vpbe_enc_timings_type type,
>> +                    unsigned int pclock)
>> +{
>> +     if (venc_type == VPBE_VERSION_1)
>> +             return;
>> +
>> +     if (venc_type == VPBE_VERSION_2 && (type == VPBE_ENC_STD ||
>> +         (type == VPBE_ENC_DV_TIMINGS && pclock <= 27000000))) {
>
> checkpatch --strict will throw a "Alignment should match open
> parenthesis" check here. You may want to fix before you send the pull
> request. No need to resend the patch just for this.
>
OK, thanks will fix it while issuing the pull.

Regards,
--Prabhakar

> Thanks,
> Sekhar


From lee.jones at linaro.org  Tue Apr  9 06:04:35 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Tue, 9 Apr 2013 11:04:35 +0100
Subject: [PATCH 4/5] dmaengine: ste_dma40: Do not configure channels
 during an channel allocation
In-Reply-To: <201304091136.09629.arnd@arndb.de>
References: <1365434591-21569-1-git-send-email-lee.jones@linaro.org>
 <1365434591-21569-4-git-send-email-lee.jones@linaro.org>
 <20130409071154.GH3084@gmail.com>
 <201304091136.09629.arnd@arndb.de>
Message-ID: <20130409100435.GB25316@gmail.com>

On Tue, 09 Apr 2013, Arnd Bergmann wrote:

> On Tuesday 09 April 2013, Lee Jones wrote:
> > According to the DMA documentation allocating a channel and configuring
> > it are two separate actions. By removing the configuration code from the
> > channel allocation path we lighten the burden on the information required to
> > successfully allocate a channel.
> 
> Did you send out the first version again? The text is the same as before.

No, the first commit message implied I'd moved the config code from
'allocate' to 'configure', whereas in reality I just removed it from
'allocate', as it's already in 'configure'.

This changelog is different (and more accurate) than the first.

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From sameo at linux.intel.com  Tue Apr  9 06:05:10 2013
From: sameo at linux.intel.com (Samuel Ortiz)
Date: Tue, 9 Apr 2013 12:05:10 +0200
Subject: [PATCH 1/2] mfd: db8500-prcmu: Return early if the TCPM cannot
 be located
In-Reply-To: <1365071941-23475-1-git-send-email-lee.jones@linaro.org>
References: <1365071941-23475-1-git-send-email-lee.jones@linaro.org>
Message-ID: <20130409100510.GP24058@zurbaran>

Hi Lee,

On Thu, Apr 04, 2013 at 11:39:00AM +0100, Lee Jones wrote:
> Currently we check to see if we obtained the Tightly Coupled Program
> Memory (TCPM) base and only execute the code within the check if we
> have it. It's more traditional to return early if we don't have it.
> This way we can flatten most of the function's code down to a single
> tab spacing.
> 
> Cc: Samuel Ortiz <sameo at linux.intel.com>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>
> ---
>  drivers/mfd/db8500-prcmu.c |   40 +++++++++++++++++++++-------------------
>  1 file changed, 21 insertions(+), 19 deletions(-)
I had to apply this one manually, please check if it was done correctly from
my mfd-next tree.

Cheers,
Samuel.

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


From sameo at linux.intel.com  Tue Apr  9 06:06:09 2013
From: sameo at linux.intel.com (Samuel Ortiz)
Date: Tue, 9 Apr 2013 12:06:09 +0200
Subject: [PATCH 2/2] mfd: db8500-prcmu: Support platform dependant device
 selection
In-Reply-To: <1365071941-23475-2-git-send-email-lee.jones@linaro.org>
References: <1365071941-23475-1-git-send-email-lee.jones@linaro.org>
 <1365071941-23475-2-git-send-email-lee.jones@linaro.org>
Message-ID: <20130409100609.GQ24058@zurbaran>

Hi Lee,

On Thu, Apr 04, 2013 at 11:39:01AM +0100, Lee Jones wrote:
> The main aim for this cycle is to have the u8540 booting to a
> console. However, the u8540 doesn't support all of the u8500
> platform devices yet. After this stage is complete we can then
> fill in the inadequacies, such as specific clock support at a
> later date. To achieve this we're placing devices supported by
> all platforms into a common device structure and the remaining
> ones into a platform specific one.
> 
> Cc: Samuel Ortiz <sameo at linux.intel.com>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>
> ---
>  drivers/mfd/db8500-prcmu.c |   52 ++++++++++++++++++++++++++++----------------
>  1 file changed, 33 insertions(+), 19 deletions(-)
This one does not apply (not even manually) on top of mfd-next. Would you mind
rebasing it (And adding Linus' ACK) ?

Cheers,
Samuel.

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


From sameo at linux.intel.com  Tue Apr  9 06:07:51 2013
From: sameo at linux.intel.com (Samuel Ortiz)
Date: Tue, 9 Apr 2013 12:07:51 +0200
Subject: [PATCH 3/3] mfd: ab8500: sysctrl: Initialize driver at
 arch_initcall
In-Reply-To: <1364943987-1338-4-git-send-email-ulf.hansson@stericsson.com>
References: <1364943987-1338-1-git-send-email-ulf.hansson@stericsson.com>
 <1364943987-1338-4-git-send-email-ulf.hansson@stericsson.com>
Message-ID: <20130409100751.GR24058@zurbaran>

Hi Ulf,

On Wed, Apr 03, 2013 at 01:06:27AM +0200, Ulf Hansson wrote:
> From: Ulf Hansson <ulf.hansson at linaro.org>
> 
> The abx500-clk driver is initiated at arch_initcall level. Moreover it
> is relying on the ab8500-sysctrl API to be available. Therefore move
> ab8500-sysctrl to arch_initcall level as well. The device is already
> added before the abx500 clk device, thus it will be probed before as
> well, which is exactly what we want.
> 
> Signed-off-by: Ulf Hansson <ulf.hansson at linaro.org>
> Cc: Samuel Ortiz <sameo at linux.intel.com>
> ---
>  drivers/mfd/ab8500-sysctrl.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
Applied, thanks.

Cheers,
Samuel.

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


From sameo at linux.intel.com  Tue Apr  9 06:09:35 2013
From: sameo at linux.intel.com (Samuel Ortiz)
Date: Tue, 9 Apr 2013 12:09:35 +0200
Subject: [PATCH] mfd: vexpress: Give the "leds-gpio" device a real parent
In-Reply-To: <1364991987-6598-1-git-send-email-pawel.moll@arm.com>
References: <1364991987-6598-1-git-send-email-pawel.moll@arm.com>
Message-ID: <20130409100935.GS24058@zurbaran>

Hi Pawel,

On Wed, Apr 03, 2013 at 01:26:27PM +0100, Pawel Moll wrote:
> The registration of the "leds-gpio" device was using
> "vexpress_sysreg_dev" as a parent before it was actually
> set to something different than NULL.
> 
> Trivial fix by reordering the code.
> 
> Reported-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
> Signed-off-by: Pawel Moll <pawel.moll at arm.com>
> ---
>  drivers/mfd/vexpress-sysreg.c |    4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
Applied, thanks.

Cheers,
Samuel.

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


From rogerq at ti.com  Tue Apr  9 06:16:27 2013
From: rogerq at ti.com (Roger Quadros)
Date: Tue, 9 Apr 2013 13:16:27 +0300
Subject: [RFC][PATCH 1/2] ARM: OMAP4: clock: Add device tree support for
 AUXCLKs
In-Reply-To: <515F1035.8090500@ti.com>
References: <1363703220-4777-1-git-send-email-rogerq@ti.com>
 <1363703220-4777-2-git-send-email-rogerq@ti.com>
 <20130403234242.GE10155@atomide.com> <515D2D30.3000306@ti.com>
 <20130404164137.GH10155@atomide.com> <515F1035.8090500@ti.com>
Message-ID: <5163EA7B.6090109@ti.com>

On 04/05/2013 08:56 PM, Grygorii Strashko wrote:
> On 04/04/2013 07:41 PM, Tony Lindgren wrote:
>> * Roger Quadros <rogerq at ti.com> [130404 00:39]:
>>> On 04/04/2013 02:42 AM, Tony Lindgren wrote:
>>>>> --- a/arch/arm/mach-omap2/cclock44xx_data.c
>>>>> +++ b/arch/arm/mach-omap2/cclock44xx_data.c
>>>>> @@ -27,6 +27,7 @@
>>>>>   #include <linux/clk-private.h>
>>>>>   #include <linux/clkdev.h>
>>>>>   #include <linux/io.h>
>>>>> +#include <linux/of.h>
>>>>>     #include "soc.h"
>>>>>   #include "iomap.h"
>>>>> @@ -1663,6 +1664,40 @@ static struct omap_clk omap44xx_clks[] = {
>>>>>       CLK(NULL,    "cpufreq_ck",    &dpll_mpu_ck,    CK_443X),
>>>>>   };
>>>>>   +static struct clk *scrm_clks[] = {
>>>>> +    &auxclk0_ck,
>>>>> +    &auxclk1_ck,
>>>>> +    &auxclk2_ck,
>>>>> +    &auxclk3_ck,
>>>>> +    &auxclk4_ck,
>>>>> +    &auxclk5_ck,
>>>>> +};
>>>> Hmm I don't like the idea of specifying the auxclk both in the
>>>> cclock44xx_data.c and in DT..
>>> Right, but till we have all clocks moved to DT we only need this
>>> approach for general purpose clocks that are not mapped to devices
>>> by hwmod.
>> For v3.10, let's just make sure that USB works with DT as then
>> after v3.10 we can make omap4 DT only and get rid of estimated
>> 7K lines of code and data. I guess this is the last piece missing
>> for that, or are we also missing something else?
>>
>> Can't you set up a clock alias for your device so it can find the
>> auxclk when requesting it with the dev entry?
>>
>> For the DT clock driver if needed for v3.10, how about just do a
>> minimal drivers/clock/omap/ that uses the standard binding?
>> Then that driver can just do clk_get() from cclock44xx_data.c
>> for now? And then later on we'll just move all the clocks to a
>> combination of DT + /lib/firmware.
>>
> Hi Roger, Rajendra, All
> 
> Sorry that disturbing you.

Hi Grygorri,

Nothing to disturb at all ;).

> 
> I'm supporting Android OMAP4 kernels (K3.0/K3.4) and like to clarify few
> points regarding this approach (having into account possible future migrations
> on newer Kernels and OMAP5).
> If I understand everything right, this patch series allows to create clock binding
> in DT using following syntax: clocks = <&aux_clks 3>

Actually in v2 of the patch this would be clocks = <&clks 3>

>  - does it means that in worst case there will be ~200 clock IDs defined?

I'm afraid so yes. But when I wrote this I was only thinking of generic clocks, i.e. AUXCLKS.
So when we start talking of all clocks we might need to reconsider the approach.

>  - does it means that clock nodes binding using phandles (human-friendly notation)
> isn't going to be supported?
> for example:
>     clocks = <&sys_clkin_ck>
>     clocks = <&dss_sys_clk &dss_tv_clk &dss_dss_clk>)

This would depend if we define the clock nodes within DT or not. From what Tony
mentioned (i.e. inefficiency) it seems that the clock nodes won't be defined
in the device tree. Then we are left with using an index.
> 
> I was horrified to think about the problems of this approach support
> (in case if there would be more then ~30 IDs) - just miss with on digit
> and weeks of debugging would be guaranteed.
> 
> Please, say me that i'm wrong.

It is still not written in stone so if you have a better idea we could
go that route.

cheers,
-roger

> And why clock DT data can't be auto-generated like all other OMAP data
> to close this questions?
> 
> Thanks.
> 
>>> e.g. auxclk are required to be specified in DT nodes for USB PHY.
>>> Without this we can't get USB host working on Panda.
>> OK. So if the USB PHY has a dev entry, can't you just set up a
>> clock alias in struct omap_clk omap44xx_clks[] for it?
>>  
>>> As Rajendra points out, it seems moving entire clock data to DT is not
>>> going to happen soon. So this is the simplistic way things can work.
>> Right but seems like we can get started there without moving
>> them all at once.
>>
>> Regards,
>>
>> Tony
>> -- 
>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 



From peter.ujfalusi at ti.com  Tue Apr  9 06:20:17 2013
From: peter.ujfalusi at ti.com (Peter Ujfalusi)
Date: Tue, 9 Apr 2013 12:20:17 +0200
Subject: [RFC v2] dmaengine: omap-dma: Start DMA without delay for cyclic
 channels
In-Reply-To: <20130409072600.GA31193@intel.com>
References: <1364987862-14597-1-git-send-email-peter.ujfalusi@ti.com>
 <51626D88.8020809@ti.com> <20130408170956.GX30923@n2100.arm.linux.org.uk>
 <20130408171519.GP10155@atomide.com> <5163BAA8.7040502@ti.com>
 <5163C103.8020101@ti.com> <20130409072600.GA31193@intel.com>
Message-ID: <5163EB61.3000507@ti.com>

On 04/09/2013 09:26 AM, Vinod Koul wrote:
> Yes it should go thru dmaengine tree, sorry was travelling hence the delay, pls
> resend the patch and I will do the needful

I already have the patch rebased on today's linux-next, just waiting for
Russell to confirm that I can add his Acked-by to the patch.
I take this from Russell as ACK: "Now that I'm back from a short 4 day break,
then yes, and the answer is that it's fine.  Who's handling the patch?"

But I want to be sure I can add that line...

-- 
P?ter


From arnd at arndb.de  Tue Apr  9 06:28:01 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 9 Apr 2013 12:28:01 +0200
Subject: [PATCH 4/5] dmaengine: ste_dma40: Do not configure channels
 during an channel allocation
In-Reply-To: <20130409071154.GH3084@gmail.com>
References: <1365434591-21569-1-git-send-email-lee.jones@linaro.org>
 <1365434591-21569-4-git-send-email-lee.jones@linaro.org>
 <20130409071154.GH3084@gmail.com>
Message-ID: <201304091228.01896.arnd@arndb.de>

On Tuesday 09 April 2013, Lee Jones wrote:
> According to the DMA documentation allocating a channel and configuring
> it are two separate actions. By removing the configuration code from the
> channel allocation path we lighten the burden on the information required to
> successfully allocate a channel.
> 
> Cc: Vinod Koul <vinod.koul at intel.com>
> Cc: Dan Williams <djbw at fb.com>
> Cc: Per Forlin <per.forlin at stericsson.com>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>

Acked-by: Arnd Bergmann <arnd at arndb.de>


From lee.jones at linaro.org  Tue Apr  9 06:29:49 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Tue, 9 Apr 2013 11:29:49 +0100
Subject: [PATCH 1/2] mfd: db8500-prcmu: Return early if the TCPM cannot
 be located
In-Reply-To: <20130409100510.GP24058@zurbaran>
References: <1365071941-23475-1-git-send-email-lee.jones@linaro.org>
 <20130409100510.GP24058@zurbaran>
Message-ID: <20130409102949.GC25316@gmail.com>

On Tue, 09 Apr 2013, Samuel Ortiz wrote:

> Hi Lee,
> 
> On Thu, Apr 04, 2013 at 11:39:00AM +0100, Lee Jones wrote:
> > Currently we check to see if we obtained the Tightly Coupled Program
> > Memory (TCPM) base and only execute the code within the check if we
> > have it. It's more traditional to return early if we don't have it.
> > This way we can flatten most of the function's code down to a single
> > tab spacing.
> > 
> > Cc: Samuel Ortiz <sameo at linux.intel.com>
> > Signed-off-by: Lee Jones <lee.jones at linaro.org>
> > ---
> >  drivers/mfd/db8500-prcmu.c |   40 +++++++++++++++++++++-------------------
> >  1 file changed, 21 insertions(+), 19 deletions(-)
> I had to apply this one manually, please check if it was done correctly from
> my mfd-next tree.

Yes, looks good.

I think it was only 'db8500_prcmu_early_init()' and the line numbers
which confused it.

Kind regards,
Lee

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From mark.rutland at arm.com  Tue Apr  9 06:33:03 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Tue, 9 Apr 2013 11:33:03 +0100
Subject: [PATCHv4 01/11] clockevents: Prefer CPU local devices over
 global devices
In-Reply-To: <1365456453-16297-2-git-send-email-sboyd@codeaurora.org>
References: <1365456453-16297-1-git-send-email-sboyd@codeaurora.org>
 <1365456453-16297-2-git-send-email-sboyd@codeaurora.org>
Message-ID: <20130409103303.GV23725@e106331-lin.cambridge.arm.com>

Hi Stephen,

Apologies for my lack of response on the last version of this.

On Mon, Apr 08, 2013 at 10:27:23PM +0100, Stephen Boyd wrote:
> On an SMP system with only one global clockevent and a dummy
> clockevent per CPU we run into problems. We want the dummy
> clockevents to be registered as the per CPU tick devices, but
> we can only achieve that if we register the dummy clockevents
> before the global clockevent or if we artificially inflate the
> rating of the dummy clockevents to be higher than the rating
> of the global clockevent. Failure to do so leads to boot
> hangs when the dummy timers are registered on all other CPUs
> besides the CPU that accepted the global clockevent as its tick
> device and there is no broadcast timer to poke the dummy
> devices.
> 
> If we're registering multiple clockevents and one clockevent is
> global and the other is local to a particular CPU we should
> choose to use the local clockevent regardless of the rating of
> the device. This way, if the clockevent is a dummy it will take
> the tick device duty as long as there isn't a higher rated tick
> device and any global clockevent will be bumped out into
> broadcast mode, fixing the problem described above.

It might be worth pointing out that if dummy timers are only registered
when there's more than one CPU, UP behaviour won't degrade from the
current state of affairs.

> 
> Reported-by: Mark Rutland <mark.rutland at arm.com>
> Cc: John Stultz <john.stultz at linaro.org>
> Cc: Thomas Gleixner <tglx at linutronix.de>
> Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
> ---
>  kernel/time/tick-common.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/kernel/time/tick-common.c b/kernel/time/tick-common.c
> index b1600a6..9ea59b9 100644
> --- a/kernel/time/tick-common.c
> +++ b/kernel/time/tick-common.c
> @@ -251,9 +251,10 @@ static int tick_check_new_device(struct clock_event_device *newdev)
>  		    !(newdev->features & CLOCK_EVT_FEAT_ONESHOT))
>  			goto out_bc;
>  		/*
> -		 * Check the rating
> +		 * Check the rating, but prefer CPU local devices
>  		 */
> -		if (curdev->rating >= newdev->rating)
> +		if (curdev->rating >= newdev->rating &&
> +		    cpumask_equal(curdev->cpumask, newdev->cpumask))
>  			goto out_bc;
>  	}

This looks good to me. I tested this on a TC2 with a v3.9-rc6 kernel
without architected timer support. The patch restores the ability to use
the sp804 as a broadcast source.

Tested-by: Mark Rutland <mark.rutland at arm.com>

If possible I think this should sit in -next for a bit to make sure it
doesn't have any unexpected side effects.

Otherwise, results of testing below.

Without this patch (where boot hangs), magic sysrq show-all-timers give
me the following:

Tick Device: mode:     1
Broadcast device
Clock Event Device: <NULL>
tick_broadcast_mask: 0000000e
tick_broadcast_oneshot_mask: 00000000


Tick Device: mode:     1
Per CPU device: 0
Clock Event Device: v2m-timer0
 max_delta_ns:   4294966591000
 min_delta_ns:   14999
 mult:           2147484
 shift:          31
 mode:           3
 next_event:     18340000000 nsecs
 set_next_event: sp804_set_next_event
 set_mode:       sp804_set_mode
 event_handler:  hrtimer_interrupt
 retries:        0

Tick Device: mode:     0
Per CPU device: 1
Clock Event Device: dummy_timer
 max_delta_ns:   0
 min_delta_ns:   0
 mult:           1
 shift:          0
 mode:           1
 next_event:     9223372036854775807 nsecs
 set_next_event: <00000000>
 set_mode:       broadcast_timer_set_mode
 event_handler:  tick_handle_periodic
 retries:        0

[...]

With this patch (where boot succeeds), show-all-timers gives me the following:

Tick Device: mode:     0
Broadcast device
Clock Event Device: v2m-timer0
 max_delta_ns:   4294966591000
 min_delta_ns:   14999
 mult:           2147484
 shift:          31
 mode:           2
 next_event:     9223372036854775807 nsecs
 set_next_event: sp804_set_next_event
 set_mode:       sp804_set_mode
 event_handler:  tick_handle_periodic_broadcast
 retries:        0
tick_broadcast_mask: 0000000f
tick_broadcast_oneshot_mask: 00000000


Tick Device: mode:     0
Per CPU device: 0
Clock Event Device: dummy_timer
 max_delta_ns:   0
 min_delta_ns:   0
 mult:           1
 shift:          0
 mode:           1
 next_event:     9223372036854775807 nsecs
 set_next_event: <pK-error>
 set_mode:       broadcast_timer_set_mode
 event_handler:  tick_handle_periodic
 retries:        0

Tick Device: mode:     0
Per CPU device: 1
Clock Event Device: dummy_timer
 max_delta_ns:   0
 min_delta_ns:   0
 mult:           1
 shift:          0
 mode:           1
 next_event:     9223372036854775807 nsecs
 set_next_event: <pK-error>
 set_mode:       broadcast_timer_set_mode
 event_handler:  tick_handle_periodic
 retries:        0

[...]

Cheers,
Mark.


From broonie at opensource.wolfsonmicro.com  Tue Apr  9 06:34:04 2013
From: broonie at opensource.wolfsonmicro.com (Mark Brown)
Date: Tue, 9 Apr 2013 11:34:04 +0100
Subject: [PATCH V3 4/5] spi: s3c64xx: Added provision for dedicated cs pin
In-Reply-To: <CAKrE-KcMy1qzzg1JXqBOvAJTdQM3rLU6dHoQRnyryLz4p0rpaA@mail.gmail.com>
References: <1363157014-9615-1-git-send-email-ks.giri@samsung.com>
 <1363157014-9615-5-git-send-email-ks.giri@samsung.com>
 <20130401125744.GG18636@opensource.wolfsonmicro.com>
 <CAKrE-Kd+YAFmteDdh3odtV+YU1=OjoMuQV9usF4NmUse+TXhTg@mail.gmail.com>
 <20130408101530.GC9243@opensource.wolfsonmicro.com>
 <CAKrE-KevVramLc1n_9kcfHVb=RKT_kexQ8iUP-5+BL3wxpMPbQ@mail.gmail.com>
 <20130408122056.GG9243@opensource.wolfsonmicro.com>
 <CAKrE-KcMy1qzzg1JXqBOvAJTdQM3rLU6dHoQRnyryLz4p0rpaA@mail.gmail.com>
Message-ID: <20130409103404.GO9243@opensource.wolfsonmicro.com>

On Mon, Apr 08, 2013 at 07:19:05PM +0530, Girish KS wrote:

> I will move the populating cs_gpio logic to probe. But the enable_cs
> and disable_cs will have the
> check before calling the gpio_set_value api (because it takes cs-line
> as a parameter),

Yes, you'll still need to have a check.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130409/f3c91002/attachment.sig>

From ezequiel.garcia at free-electrons.com  Tue Apr  9 06:34:46 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Tue, 9 Apr 2013 07:34:46 -0300
Subject: [PATCH v4 1/5] drivers: memory: Introduce Marvell EBU Device Bus
 driver
In-Reply-To: <201304091140.51839.arnd@arndb.de>
References: <1365419194-20871-1-git-send-email-ezequiel.garcia@free-electrons.com>
 <20130408171940.GA8815@obsidianresearch.com>
 <20130409004253.GA2258@localhost>
 <201304091140.51839.arnd@arndb.de>
Message-ID: <20130409103445.GA2268@localhost>

Hi Arnd,

On Tue, Apr 09, 2013 at 11:40:51AM +0200, Arnd Bergmann wrote:
> On Tuesday 09 April 2013, Ezequiel Garcia wrote:
> > > This can probably just be of_platform_populate or similar to do all
> > > children? For instance, I often use many DT nodes to represent a FPGA,
> > > since the my FPGA's tend to have many functionally orthogonal units
> > > inside.
> > > 
> > 
> > In the past I've found it's not possible to use of_platform_populate,
> > altough I can be wrong.
> > 
> > The problem seems to be that through of_platform_populate() it's
> > possible that the child device (cfi-flash, for instance) gets probed
> > before the devbus controller. In other words, the actual parent-child
> > relationship gets lost and it's necesarry to use some child probe deferal
> > mechanism.
> > 
> > This has been recently discussed [1] when implementing GPMC where for simplicity
> > the of_platform_device_create() solution was chosen.
> > Anyway, I'll try of_platform_populate early tomorrow.
> 
> I think the problem mentioned in that thread was that the device would
> automatically get probed by the top-level of_platform_populate() when
> you mark the devbus as compatible="simple-bus", which is not what Jason
> was referring to. Instead you should call of_platform_populate in the
> probe() function of the devbus device to probe its children after
> the bus is set up.
> 

Ah! yes, you're right...

Well, in that case the only issue I can foresee is that if we decide
to use of_platform_populate we won't be able to unregister child
devices from the remove() callback.

Indeed, the benefits of using of_platform_populate are interesting,
but I don't know how much of an issue this represents.

If we can't unregister child devices, we can't remove address windows.
Now, this is not a big deal, since we plan to define them statically in
the DT anyway.
In that case, it seems we shouldn't allow this driver to be a module, uh?

(actually we currently can't have mvebu-devbus as a module, because
mbus API is not exported, but we can fix that if we want).

What do you think?
-- 
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com


From marc.zyngier at arm.com  Tue Apr  9 06:42:56 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Tue, 09 Apr 2013 11:42:56 +0100
Subject: [PATCH v2 6/7] ARM: KVM: switch to a dual-step HYP init code
In-Reply-To: <20130409091813.GC24090@mudshark.cambridge.arm.com>
References: <1365435403-29265-1-git-send-email-marc.zyngier@arm.com>
 <1365435403-29265-7-git-send-email-marc.zyngier@arm.com>
 <20130409091813.GC24090@mudshark.cambridge.arm.com>
Message-ID: <5163F0B0.2000400@arm.com>

On 09/04/13 10:18, Will Deacon wrote:
> On Mon, Apr 08, 2013 at 04:36:42PM +0100, Marc Zyngier wrote:
>> Our HYP init code suffers from two major design issues:
>> - it cannot support CPU hotplug, as we tear down the idmap very early
>> - it cannot perform a TLB invalidation when switching from init to
>>   runtime mappings, as pages are manipulated from PL1 exclusively
>>
>> The hotplug problem mandates that we keep two sets of page tables
>> (boot and runtime). The TLB problem mandates that we're able to
>> transition from one PGD to another while in HYP, invalidating the TLBs
>> in the process.
>>
>> To be able to do this, we need to share a page between the two page
>> tables. A page that will have the same VA in both configurations. All we
>> need is a VA that has the following properties:
>> - This VA can't be used to represent a kernel mapping.
>> - This VA will not conflict with the physical address of the kernel text
>>
>> The vectors page seems to satisfy this requirement:
>> - The kernel never maps anything else there
>> - The kernel text being copied at the beginning of the physical memory,
>>   it is unlikely to use the last 64kB (I doubt we'll ever support KVM
>>   on a system with something like 4MB of RAM, but patches are very
>>   welcome).
>>
>> Let's call this VA the trampoline VA.
>>
>> Now, we map our init page at 3 locations:
>> - idmap in the boot pgd
>> - trampoline VA in the boot pgd
>> - trampoline VA in the runtime pgd
>>
>> The init scenario is now the following:
>> - We jump in HYP with four parameters: boot HYP pgd, runtime HYP pgd,
>>   runtime stack, runtime vectors
>> - Enable the MMU with the boot pgd
>> - Jump to a target into the trampoline page (remember, this is the same
>>   physical page!)
>> - Now switch to the runtime pgd (same VA, and still the same physical
>>   page!)
>> - Invalidate TLBs
>> - Set stack and vectors
>> - Profit! (or eret, if you only care about the code).
>>
>> Note that we keep the boot mapping permanently (it is not strictly an
>> idmap anymore) to allow for CPU hotplug in later patches.
>>
>> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
>> ---
>>  arch/arm/include/asm/kvm_host.h |  18 ++++--
>>  arch/arm/include/asm/kvm_mmu.h  |  24 +++++++-
>>  arch/arm/kvm/arm.c              |  11 ++--
>>  arch/arm/kvm/init.S             |  44 +++++++++++++-
>>  arch/arm/kvm/mmu.c              | 129 ++++++++++++++++++++++++++++------------
>>  5 files changed, 173 insertions(+), 53 deletions(-)
>>
>> diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
>> index a856cc2..9fe22ee 100644
>> --- a/arch/arm/include/asm/kvm_host.h
>> +++ b/arch/arm/include/asm/kvm_host.h
>> @@ -190,22 +190,32 @@ int kvm_arm_coproc_set_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *);
>>  int handle_exit(struct kvm_vcpu *vcpu, struct kvm_run *run,
>>                 int exception_index);
>>
>> -static inline void __cpu_init_hyp_mode(unsigned long long pgd_ptr,
>> +static inline void __cpu_init_hyp_mode(unsigned long long boot_pgd_ptr,
>> +                                      unsigned long long pgd_ptr,
>>                                        unsigned long hyp_stack_ptr,
>>                                        unsigned long vector_ptr)
>>  {
>>         unsigned long pgd_low, pgd_high;
>>
>> -       pgd_low = (pgd_ptr & ((1ULL << 32) - 1));
>> -       pgd_high = (pgd_ptr >> 32ULL);
>> +       pgd_low = (boot_pgd_ptr & ((1ULL << 32) - 1));
>> +       pgd_high = (boot_pgd_ptr >> 32ULL);
>>
>>         /*
>>          * Call initialization code, and switch to the full blown
>>          * HYP code. The init code doesn't need to preserve these registers as
>> -        * r1-r3 and r12 are already callee save according to the AAPCS.
>> +        * r1-r3 and r12 are already callee saved according to the AAPCS.
>>          * Note that we slightly misuse the prototype by casing the pgd_low to
>>          * a void *.
>> +        *
>> +        * We don't have enough registers to perform the full init in one go.
>> +        * Install the boot PGD first, and then install the runtime PGD,
>> +        * stack pointer and vectors.
>>          */
>> +       kvm_call_hyp((void *)pgd_low, pgd_high, 0, 0);
>> +
>> +       pgd_low = (pgd_ptr & ((1ULL << 32) - 1));
>> +       pgd_high = (pgd_ptr >> 32ULL);
> 
> It might be worth macro-ising the low/high extraction operations now that
> you're using them twice. Hell, you could even make them big-endian clean!

Now you're talking! ;-)

I actually wonder if we could rearrange the code to let the compiler do
the low/high split... Quickly looking through the PCS, it looks like
this would actually work.

>>         kvm_call_hyp((void *)pgd_low, pgd_high, hyp_stack_ptr, vector_ptr);
>>  }
>>
>> diff --git a/arch/arm/include/asm/kvm_mmu.h b/arch/arm/include/asm/kvm_mmu.h
>> index 92eb20d..24b767a 100644
>> --- a/arch/arm/include/asm/kvm_mmu.h
>> +++ b/arch/arm/include/asm/kvm_mmu.h
>> @@ -19,17 +19,29 @@
>>  #ifndef __ARM_KVM_MMU_H__
>>  #define __ARM_KVM_MMU_H__
>>
>> -#include <asm/cacheflush.h>
>> -#include <asm/pgalloc.h>
>> +#include <asm/memory.h>
>> +#include <asm/page.h>
>>
>>  /*
>>   * We directly use the kernel VA for the HYP, as we can directly share
>>   * the mapping (HTTBR "covers" TTBR1).
>>   */
>> -#define HYP_PAGE_OFFSET_MASK   (~0UL)
>> +#define HYP_PAGE_OFFSET_MASK   UL(~0)
>>  #define HYP_PAGE_OFFSET                PAGE_OFFSET
>>  #define KERN_TO_HYP(kva)       (kva)
>>
>> +/*
>> + * Our virtual mapping for the boot-time MMU-enable code. Must be
>> + * shared across all the page-tables. Conveniently, we use the vectors
>> + * page, where no kernel data will ever be shared with HYP.
>> + */
>> +#define TRAMPOLINE_VA          UL(CONFIG_VECTORS_BASE)
>> +
>> +#ifndef __ASSEMBLY__
>> +
>> +#include <asm/cacheflush.h>
>> +#include <asm/pgalloc.h>
>> +
>>  int create_hyp_mappings(void *from, void *to);
>>  int create_hyp_io_mappings(void *from, void *to, phys_addr_t);
>>  void free_hyp_pgds(void);
>> @@ -44,6 +56,8 @@ int kvm_handle_guest_abort(struct kvm_vcpu *vcpu, struct kvm_run *run);
>>  void kvm_mmu_free_memory_caches(struct kvm_vcpu *vcpu);
>>
>>  phys_addr_t kvm_mmu_get_httbr(void);
>> +phys_addr_t kvm_mmu_get_boot_httbr(void);
>> +phys_addr_t kvm_get_idmap_vector(void);
>>  int kvm_mmu_init(void);
>>  void kvm_clear_hyp_idmap(void);
>>
>> @@ -113,4 +127,8 @@ static inline void coherent_icache_guest_page(struct kvm *kvm, gfn_t gfn)
>>         }
>>  }
>>
>> +#define kvm_flush_dcache_to_poc(a,l)   __cpuc_flush_dcache_area((a), (l))
>> +
>> +#endif /* !__ASSEMBLY__ */
>> +
>>  #endif /* __ARM_KVM_MMU_H__ */
>> diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
>> index 8d44ef4..9010a12 100644
>> --- a/arch/arm/kvm/arm.c
>> +++ b/arch/arm/kvm/arm.c
>> @@ -796,20 +796,22 @@ long kvm_arch_vm_ioctl(struct file *filp,
>>
>>  static void cpu_init_hyp_mode(void *vector)
>>  {
>> +       unsigned long long boot_pgd_ptr;
>>         unsigned long long pgd_ptr;
>>         unsigned long hyp_stack_ptr;
>>         unsigned long stack_page;
>>         unsigned long vector_ptr;
>>
>>         /* Switch from the HYP stub to our own HYP init vector */
>> -       __hyp_set_vectors((unsigned long)vector);
>> +       __hyp_set_vectors(kvm_get_idmap_vector());
>>
>> +       boot_pgd_ptr = (unsigned long long)kvm_mmu_get_boot_httbr();
>>         pgd_ptr = (unsigned long long)kvm_mmu_get_httbr();
> 
> Strictly speaking, could you avoid using two sets of tables for this? That
> is, have code in the trampoline page which remaps the rest of the address
> space using the current tables? Not saying it's feasible, just interested.

If you do that, you loose the ability to bring in a hotplugged CPU, as
your idmap and your runtime page tables may have conflicting
translations. Or am I missing something obvious?

>>         stack_page = __get_cpu_var(kvm_arm_hyp_stack_page);
>>         hyp_stack_ptr = stack_page + PAGE_SIZE;
>>         vector_ptr = (unsigned long)__kvm_hyp_vector;
>>
>> -       __cpu_init_hyp_mode(pgd_ptr, hyp_stack_ptr, vector_ptr);
>> +       __cpu_init_hyp_mode(boot_pgd_ptr, pgd_ptr, hyp_stack_ptr, vector_ptr);
>>  }
>>
>>  /**
>> @@ -863,11 +865,6 @@ static int init_hyp_mode(void)
>>         }
>>
>>         /*
>> -        * Unmap the identity mapping
>> -        */
>> -       kvm_clear_hyp_idmap();
>> -
>> -       /*
>>          * Map the Hyp-code called directly from the host
>>          */
>>         err = create_hyp_mappings(__kvm_hyp_code_start, __kvm_hyp_code_end);
>> diff --git a/arch/arm/kvm/init.S b/arch/arm/kvm/init.S
>> index 9f37a79..0ca054f 100644
>> --- a/arch/arm/kvm/init.S
>> +++ b/arch/arm/kvm/init.S
>> @@ -21,6 +21,7 @@
>>  #include <asm/asm-offsets.h>
>>  #include <asm/kvm_asm.h>
>>  #include <asm/kvm_arm.h>
>> +#include <asm/kvm_mmu.h>
>>
>>  /********************************************************************
>>   * Hypervisor initialization
>> @@ -28,6 +29,25 @@
>>   *       r0,r1 = Hypervisor pgd pointer
>>   *       r2 = top of Hyp stack (kernel VA)
>>   *       r3 = pointer to hyp vectors
>> + *
>> + * The init scenario is:
>> + * - We jump in HYP with four parameters: boot HYP pgd, runtime HYP pgd,
>> + *   runtime stack, runtime vectors
>> + * - Enable the MMU with the boot pgd
>> + * - Jump to a target into the trampoline page (remember, this is the same
>> + *   physical page!)
>> + * - Now switch to the runtime pgd (same VA, and still the same physical
>> + *   page!)
>> + * - Invalidate TLBs
>> + * - Set stack and vectors
>> + * - Profit! (or eret, if you only care about the code).
>> + *
>> + * As we only have four registers available to pass parameters (and we
>> + * need six), we split the init in two phases:
>> + * - Phase 1: r0,r1 contain the boot PGD, r2 = 0, r3 = 0.
>> + *   Provides the basic HYP init, and enable the MMU.
>> + * - Phase 2: r0,r1 contain the runtime PGD, r2 = ToS, r3 = vectors
>> + *   Switches to the runtime PGD, set stack and vectors.
>>   */
>>
>>         .text
>> @@ -47,6 +67,9 @@ __kvm_hyp_init:
>>         W(b)    .
>>
>>  __do_hyp_init:
>> +       cmp     r2, #0                  @ We have a SP?
>> +       bne     phase2                  @ Yes, second stage init
>> +
>>         @ Set the HTTBR to point to the hypervisor PGD pointer passed
>>         mcrr    p15, 4, r0, r1, c2
>>
>> @@ -96,14 +119,31 @@ __do_hyp_init:
>>         orr     r0, r0, r1
>>         isb
>>         mcr     p15, 4, r0, c1, c0, 0   @ HSCR
>> -       isb
>>
>> -       @ Set stack pointer and return to the kernel
>> +       @ End of init phase-1
>> +       eret
>> +
>> +phase2:
>> +       @ Set stack pointer
>>         mov     sp, r2
>>
>>         @ Set HVBAR to point to the HYP vectors
>>         mcr     p15, 4, r3, c12, c0, 0  @ HVBAR
>>
>> +       @ Jump to the trampoline page
>> +       ldr     r2, =TRAMPOLINE_VA
>> +       adr     r3, target
>> +       bfi     r2, r3, #0, #PAGE_SHIFT
>> +       mov     pc, r2
>> +
>> +target:        @ We're now in the trampoline code, switch page tables
>> +       mcrr    p15, 4, r0, r1, c2
>> +       isb
>> +
>> +       @ Invalidate the old TLBs
>> +       mcr     p15, 4, r0, c8, c7, 0   @ TLBIALLH
>> +       dsb
>> +
>>         eret
>>
>>         .ltorg
>> diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
>> index c4236e4..b20eff2 100644
>> --- a/arch/arm/kvm/mmu.c
>> +++ b/arch/arm/kvm/mmu.c
>> @@ -32,9 +32,15 @@
>>
>>  extern char  __hyp_idmap_text_start[], __hyp_idmap_text_end[];
>>
>> +static pgd_t *boot_hyp_pgd;
>>  static pgd_t *hyp_pgd;
>>  static DEFINE_MUTEX(kvm_hyp_pgd_mutex);
>>
>> +static void *init_bounce_page;
>> +static unsigned long hyp_idmap_start;
>> +static unsigned long hyp_idmap_end;
>> +static phys_addr_t hyp_idmap_vector;
>> +
>>  static void kvm_tlb_flush_vmid_ipa(struct kvm *kvm, phys_addr_t ipa)
>>  {
>>         kvm_call_hyp(__kvm_tlb_flush_vmid_ipa, kvm, ipa);
>> @@ -108,9 +114,12 @@ static void free_hyp_pgd_entry(pgd_t *pgdp, unsigned long addr)
>>  /**
>>   * free_hyp_pgds - free Hyp-mode page tables
>>   *
>> - * Assumes hyp_pgd is a page table used strictly in Hyp-mode and therefore contains
>> - * either mappings in the kernel memory area (above PAGE_OFFSET), or
>> - * device mappings in the vmalloc range (from VMALLOC_START to VMALLOC_END).
>> + * Assumes hyp_pgd is a page table used strictly in Hyp-mode and
>> + * therefore contains either mappings in the kernel memory area (above
>> + * PAGE_OFFSET), or device mappings in the vmalloc range (from
>> + * VMALLOC_START to VMALLOC_END).
>> + *
>> + * boot_hyp_pgd should only map two pages for the init code.
>>   */
>>  void free_hyp_pgds(void)
>>  {
>> @@ -118,6 +127,12 @@ void free_hyp_pgds(void)
>>
>>         mutex_lock(&kvm_hyp_pgd_mutex);
>>
>> +       if (boot_hyp_pgd) {
>> +               free_hyp_pgd_entry(boot_hyp_pgd, hyp_idmap_start);
>> +               free_hyp_pgd_entry(boot_hyp_pgd, TRAMPOLINE_VA);
>> +               kfree(boot_hyp_pgd);
>> +       }
>> +
>>         if (hyp_pgd) {
>>                 for (addr = PAGE_OFFSET; virt_addr_valid(addr); addr += PGDIR_SIZE)
>>                         free_hyp_pgd_entry(hyp_pgd, KERN_TO_HYP(addr));
>> @@ -126,6 +141,7 @@ void free_hyp_pgds(void)
>>                 kfree(hyp_pgd);
>>         }
>>
>> +       kfree(init_bounce_page);
>>         mutex_unlock(&kvm_hyp_pgd_mutex);
>>  }
>>
>> @@ -718,14 +734,62 @@ phys_addr_t kvm_mmu_get_httbr(void)
>>         return virt_to_phys(hyp_pgd);
>>  }
>>
>> +phys_addr_t kvm_mmu_get_boot_httbr(void)
>> +{
>> +       VM_BUG_ON(!virt_addr_valid(boot_hyp_pgd));
> 
> Seems a bit OTT -- it's always going to be in lowmem.

Indeed.

>> +       return virt_to_phys(boot_hyp_pgd);
>> +}
>> +
>> +phys_addr_t kvm_get_idmap_vector(void)
>> +{
>> +       return hyp_idmap_vector;
>> +}
>> +
>>  int kvm_mmu_init(void)
>>  {
>> -       unsigned long hyp_idmap_start = virt_to_phys(__hyp_idmap_text_start);
>> -       unsigned long hyp_idmap_end = virt_to_phys(__hyp_idmap_text_end);
>>         int err;
>>
>> +       hyp_idmap_start = virt_to_phys(__hyp_idmap_text_start);
>> +       hyp_idmap_end = virt_to_phys(__hyp_idmap_text_end);
>> +       hyp_idmap_vector = virt_to_phys(__kvm_hyp_init);
>> +
>> +       if ((hyp_idmap_start ^ hyp_idmap_end) & PAGE_MASK) {
>> +               /*
>> +                * Our init code is crossing a page boundary. Allocate
>> +                * a bounce page, copy the code over and use that.
>> +                */
>> +               size_t len = __hyp_idmap_text_end - __hyp_idmap_text_start;
>> +               phys_addr_t phys_base;
>> +
>> +               init_bounce_page = kzalloc(PAGE_SIZE, GFP_KERNEL);
>> +               if (!init_bounce_page) {
>> +                       kvm_err("Couldn't allocate HYP init bounce page\n");
>> +                       err = -ENOMEM;
>> +                       goto out;
>> +               }
> 
> Given that you don't really need a lowmem page for the bounce page, this
> might be better expressed using alloc_page and kmap for the memcpy.

I'm a bit dubious about that. We have to make sure that the memory is
within the 4GB range, and the only flag I can spot for alloc_page is
GFP_DMA32, which is not exactly what we want, even if it may work.

And yes, we have a problem with platforms having *all* their memory
above 4GB.

> I also wonder whether or not you can eventually free the page and
> corresponding mappings if !CONFIG_HOTPLUG_CPU?

This is indeed possible, as we're sure nothing will use the boot tage
tables once all CPUs have switched to the runtime page tables.

>> +               memcpy(init_bounce_page, __hyp_idmap_text_start, len);
>> +               /*
>> +                * Warning: the code we just copied to the bounce page
>> +                * must be flushed to the point of coherency.
>> +                * Otherwise, the data may be sitting in L2, and HYP
>> +                * mode won't be able to observe it as it runs with
>> +                * caches off at that point.
>> +                */
>> +               kvm_flush_dcache_to_poc(init_bounce_page, len);
>> +
>> +               phys_base = virt_to_phys(init_bounce_page);
>> +               hyp_idmap_vector += phys_base - hyp_idmap_start;
>> +               hyp_idmap_start = phys_base;
>> +               hyp_idmap_end = phys_base + len;
>> +
>> +               kvm_info("Using HYP init bounce page @%lx\n",
>> +                        (unsigned long)phys_base);
>> +       }
>> +
>>         hyp_pgd = kzalloc(PTRS_PER_PGD * sizeof(pgd_t), GFP_KERNEL);
>> -       if (!hyp_pgd) {
>> +       boot_hyp_pgd = kzalloc(PTRS_PER_PGD * sizeof(pgd_t), GFP_KERNEL);
>> +       if (!hyp_pgd || !boot_hyp_pgd) {
>>                 kvm_err("Hyp mode PGD not allocated\n");
>>                 err = -ENOMEM;
>>                 goto out;
>> @@ -743,39 +807,30 @@ int kvm_mmu_init(void)
>>                 goto out;
>>         }
>>
>> +       /* Map the very same page at the trampoline VA */
>> +       err =   __create_hyp_mappings(boot_hyp_pgd,
>> +                                     TRAMPOLINE_VA, TRAMPOLINE_VA + PAGE_SIZE,
>> +                                     __phys_to_pfn(hyp_idmap_start),
>> +                                     PAGE_HYP);
>> +       if (err) {
>> +               kvm_err("Failed to map trampoline @%lx into boot HYP pgd\n",
>> +                       TRAMPOLINE_VA);
>> +               goto out;
>> +       }
>> +
>> +       /* Map the same page again into the runtime page tables */
>> +       err =   __create_hyp_mappings(hyp_pgd,
>> +                                     TRAMPOLINE_VA, TRAMPOLINE_VA + PAGE_SIZE,
>> +                                     __phys_to_pfn(hyp_idmap_start),
>> +                                     PAGE_HYP);
>> +       if (err) {
>> +               kvm_err("Failed to map trampoline @%lx into runtime HYP pgd\n",
>> +                       TRAMPOLINE_VA);
>> +               goto out;
>> +       }
> 
> I'm probably just missing it, but where are the updated page tables flushed
> to memory?

Mumble mumble... We have some partial flush, but clearly not enough of
it to be completely safe. Good spotting.

I'll update the series and send out a v3.

Thanks for reviewing.

	M.
-- 
Jazz is not dead. It just smells funny...



From arnd at arndb.de  Tue Apr  9 06:44:07 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 9 Apr 2013 12:44:07 +0200
Subject: [PATCH v4 1/5] drivers: memory: Introduce Marvell EBU Device Bus
 driver
In-Reply-To: <20130409103445.GA2268@localhost>
References: <1365419194-20871-1-git-send-email-ezequiel.garcia@free-electrons.com>
 <201304091140.51839.arnd@arndb.de> <20130409103445.GA2268@localhost>
Message-ID: <201304091244.07662.arnd@arndb.de>

On Tuesday 09 April 2013, Ezequiel Garcia wrote:
> Ah! yes, you're right...
> 
> Well, in that case the only issue I can foresee is that if we decide
> to use of_platform_populate we won't be able to unregister child
> devices from the remove() callback.
> 
> Indeed, the benefits of using of_platform_populate are interesting,
> but I don't know how much of an issue this represents.
> 
> If we can't unregister child devices, we can't remove address windows.
> Now, this is not a big deal, since we plan to define them statically in
> the DT anyway.
> In that case, it seems we shouldn't allow this driver to be a module, uh?
> 
> (actually we currently can't have mvebu-devbus as a module, because
> mbus API is not exported, but we can fix that if we want).

I think it's still reasonable to make it a module, but it might need to
be one without a module_exit() call to prevent unloading.

We could also try to add the opposite of of_platform_populate to remove
an entire subtree.

	Arnd


From arnd at arndb.de  Tue Apr  9 06:49:38 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 9 Apr 2013 12:49:38 +0200
Subject: [GIT PULL] at91: DT changes for 3.10 #3
In-Reply-To: <1365094799-16940-1-git-send-email-nicolas.ferre@atmel.com>
References: <20130402184947.GA8015@quad.lixom.net>
 <1365094799-16940-1-git-send-email-nicolas.ferre@atmel.com>
Message-ID: <201304091249.38903.arnd@arndb.de>

On Thursday 04 April 2013, Nicolas Ferre wrote:
> Here is the refreshed pull-request for AT91 that is dedicated to Device Tree
> modifications. It is stacked on the material that you already have
> for 3.10 in your arm-soc/at91/dt branch.
> Following our discussion with Arnd, I added the non-urgent patches that I
> already proposed too late for 3.9. I also included the moving of macb node
> and kept the original patch.
> 
> As Olof asked, I renamed the Aria board dts file: at91-ariag25.dts and placed
> it in the Makefile. I also took the advantage of this delay to stack two more
> DT related patches.
> 

Pulled into next/dt, thanks!

	Arnd


From arnd at arndb.de  Tue Apr  9 06:55:02 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 9 Apr 2013 12:55:02 +0200
Subject: [GIT PULL] mailbox driver framework for v3.10 merge window
In-Reply-To: <37C860A02101E749A747FA2D3C1E3C504A1971@DLEE11.ent.ti.com>
References: <37C860A02101E749A747FA2D3C1E3C504A1971@DLEE11.ent.ti.com>
Message-ID: <201304091255.03020.arnd@arndb.de>

On Thursday 04 April 2013, Anna, Suman wrote:
> OMAP and ST-Ericsson platforms are both using mailbox to communicate with some coprocessors. This series creates a consolidated framework, living under drivers/mailbox.
> The changes mainly contain:
> - create a mailbox framework independent from OMAP h/w
> - creates dbx500 mailbox driver for ST-Ericsson platforms
> - move the omap mailbox out of plat-omap/mach-omapX  adapting to the new framework.
> - minor bug fixes in mailbox code

Pulled into a new next/mailbox branch, to keep it separate from the
existing subsystems.

As a note for you: when you send a pull request, please make sure that you
use a tag that includes the changeset text (your description above), so I
don't have to copy it from the email. I noticed that you do have a tag
"mailbox-for-v3.10" in your tree, but the pull request was for the branch
with the same contents.

	Arnd


From arnd at arndb.de  Tue Apr  9 06:59:45 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 9 Apr 2013 12:59:45 +0200
Subject: [GIT PULL] ARM: sunxi: dt for 3.10, take 2
In-Reply-To: <515F0176.6060601@free-electrons.com>
References: <515F0176.6060601@free-electrons.com>
Message-ID: <201304091259.46064.arnd@arndb.de>

On Friday 05 April 2013, Maxime Ripard wrote:
> ARM: sunxi: dt additions for 3.10, take 2
> 
>   - Rename the clock compatible introduced in the first pull request for 3.10
>   - Complete the UART support for A13 and A10
>   - Adds clock gates support

Applied to next/dt branch, thanks!

	Arnd


From ezequiel.garcia at free-electrons.com  Tue Apr  9 07:00:32 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Tue, 9 Apr 2013 08:00:32 -0300
Subject: [PATCH v4 1/5] drivers: memory: Introduce Marvell EBU Device Bus
 driver
In-Reply-To: <201304091244.07662.arnd@arndb.de>
References: <1365419194-20871-1-git-send-email-ezequiel.garcia@free-electrons.com>
 <201304091140.51839.arnd@arndb.de>
 <20130409103445.GA2268@localhost>
 <201304091244.07662.arnd@arndb.de>
Message-ID: <20130409110031.GB2268@localhost>

On Tue, Apr 09, 2013 at 12:44:07PM +0200, Arnd Bergmann wrote:
> On Tuesday 09 April 2013, Ezequiel Garcia wrote:
> > Ah! yes, you're right...
> > 
> > Well, in that case the only issue I can foresee is that if we decide
> > to use of_platform_populate we won't be able to unregister child
> > devices from the remove() callback.
> > 
> > Indeed, the benefits of using of_platform_populate are interesting,
> > but I don't know how much of an issue this represents.
> > 
> > If we can't unregister child devices, we can't remove address windows.
> > Now, this is not a big deal, since we plan to define them statically in
> > the DT anyway.
> > In that case, it seems we shouldn't allow this driver to be a module, uh?
> > 
> > (actually we currently can't have mvebu-devbus as a module, because
> > mbus API is not exported, but we can fix that if we want).
> 
> I think it's still reasonable to make it a module, but it might need to
> be one without a module_exit() call to prevent unloading.
> 
> We could also try to add the opposite of of_platform_populate to remove
> an entire subtree.
> 

Yes, good idea.

I'll send a v5 in a minute, with your acked-by,
maintaining the of_platform_device_create for now.

I think at this point it's reasonable to add of_platform_populate
as a follow-up patch, together with the mbus-related fixes.

Thanks,
-- 
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com


From arnd at arndb.de  Tue Apr  9 07:01:04 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 9 Apr 2013 13:01:04 +0200
Subject: [GIT PULL 1/8] ARM: tegra: DT-related fixes needed by the MMC tree
In-Reply-To: <1365181426-11547-1-git-send-email-swarren@wwwdotorg.org>
References: <1365181426-11547-1-git-send-email-swarren@wwwdotorg.org>
Message-ID: <201304091301.04472.arnd@arndb.de>

On Friday 05 April 2013, Stephen Warren wrote:
> In order to convert the Tegra MMC driver to using mmc_of_parse(), some
> bugs in the Tegra device-tree content need to be fixed first; it's
> currently wrong but unused, and mmc_of_parse() causes that data to be
> used for the first time.
> 
> (This branch has also been merged into the MMC tree. I'm sending it as a
> separate pull request as an FYI, but you can feel free to skip it and just
> pull in 2/8 which is the main Tegra fixes branch and includes this)
> 

Pulled into next/dt for completeness, thanks!

	Arnd


From arnd at arndb.de  Tue Apr  9 07:13:19 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 9 Apr 2013 13:13:19 +0200
Subject: [GIT PULL 2/3] DaVinci DT updates for v3.10
In-Reply-To: <1365156017-12149-2-git-send-email-nsekhar@ti.com>
References: <1365156017-12149-1-git-send-email-nsekhar@ti.com>
 <1365156017-12149-2-git-send-email-nsekhar@ti.com>
Message-ID: <201304091313.19512.arnd@arndb.de>

On Friday 05 April 2013, Sekhar Nori wrote:
> Here are the DT updates for v3.10. This depends on the
> SoC updates from previous pull request.
> 

I've pulled both into the next/soc branch now, which is slightly wrong, but
your two branches belong conceptually together, and the order is fixed
now for 3.10 so the first dt branch comes before the soc branch. I did
not want to start a next/dt2 just for this.

	Arnd


From linus.walleij at linaro.org  Tue Apr  9 07:14:28 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Tue, 9 Apr 2013 13:14:28 +0200
Subject: [RFC PATCH arm: initial TI-Nspire support]
In-Reply-To: <6FE4B33E-A503-4A75-AEED-831CB2C06D83@gmail.com>
References: <6FE4B33E-A503-4A75-AEED-831CB2C06D83@gmail.com>
Message-ID: <CACRpkdbuAvRzVdzKL51k5d7vVpGNUHh_f_ZAxP4m3zFdBOV=xw@mail.gmail.com>

On Thu, Apr 4, 2013 at 11:01 AM, Daniel Tang <dt.tangr at gmail.com> wrote:

(I suspect I duplicate a lot of Arnd's comments, I haven't really checked.
If we contradict each other, point it out so we can discuss.)

> +config ARCH_NSPIRE
> +       bool "TI-NSPIRE based"
> +       depends on MMU
> +       select CPU_ARM926T
> +       select HAVE_MACH_CLKDEV
> +       select CLKDEV_LOOKUP

For a new platform you should be selecting COMMON_CLK
and implement your clock drivers under drivers/clk/*.

> +       select ARM_AMBA
> +       select USB_ARCH_HAS_EHCI
> +       select ARCH_WANT_OPTIONAL_GPIOLIB
> +       select GENERIC_ALLOCATOR

I wonder what that is used for ... will be fun to see :-)

> +       select ARCH_HAS_CPUFREQ
> +       select CPU_FREQ_TABLE
> +       help
> +         This enables support for systems using the TI-NSPIRE CPU

This does not select GENERIC_CLOCKEVENTS and SPARSE_IRQ
which is not a good sign.

> +choice
> +       prompt "Early printk and boot message serial interface"
> +       help
> +         Early printk output interface
> +       depends on EARLY_PRINTK
> +       default NSPIRE_EARLYPRINTK_CX
> +
> +config NSPIRE_EARLYPRINTK_CLASSIC
> +       bool "Classic"
> +
> +config NSPIRE_EARLYPRINTK_CX
> +       bool "CX model"
> +endchoice

This kind of stuf should go into
arch/arm/Kconfig.debug these days, along with implementation
of debug macro in arch/arm/debug/foo.S

> diff --git a/arch/arm/mach-nspire/classic.c b/arch/arm/mach-nspire/classic.c
(...)

> +union reg_clk_speed {
> +       unsigned long raw;
> +       struct {
> +               unsigned long __padding0:1;
> +               unsigned long base_cpu_ratio:7;
> +               unsigned long is_base_27mhz:1;
> +               unsigned long __padding1:3;
> +               unsigned long cpu_ahb_ratio:3;
> +               unsigned long __padding2:1;
> +               unsigned long base_val:5;
> +       } val;
> +};

Usually to try to fit a struct over a register range is not such a good
idea in Linux.

Instead define abstract representations of what you want to do
(remove everything named "padding" above, use proper data types instead
of these unsigned longs and that complex union) then use offsets to
registers and remap the base offset in memory.

It makes for simpler debugging and ability to properly use read|write[lwb]
macros.

> +static unsigned long classic_clocks_to_io(struct nspire_clk_speeds *clks)
> +{
> +       union reg_clk_speed reg;
> +
> +       BUG_ON(clks->div.base_cpu < 2);
> +       BUG_ON(clks->div.cpu_ahb < 1);
> +
> +       reg.raw = 0;
> +       reg.val.base_cpu_ratio = clks->div.base_cpu / 2;
> +       reg.val.cpu_ahb_ratio = clks->div.cpu_ahb - 1;
> +       reg.val.is_base_27mhz = (clks->base <= 27000000);
> +       reg.val.base_val = (300 - (clks->base / 1000000)) / 6;
> +
> +       return reg.raw;
> +}

And that avoid having to create special helper functions like this.

In integer divisions consider using DIV_ROUND_CLOSEST()
from <linux/kernel.h> where applicable.

> +/* Interrupt handling */

The interrupt controller driver shall be placed in drivers/irqchips
these days.

> +static inline int check_interrupt(void __iomem *base, struct pt_regs *regs)
> +{
> +       if (readl(base + 0x0)) {

Arrow antipattern, turn it around.

if (!readl(base))
   return 0;

Then de-indent the rest of the code.

> +               int irqnr = readl(base + 0x24);
> +               unsigned prev_priority;
> +               handle_IRQ(irqnr, regs);
> +
> +               /* Reset priorities */
> +               prev_priority = readl(IOMEM(NSPIRE_INTERRUPT_VIRT_BASE + 0x28));
> +               writel(prev_priority, IOMEM(NSPIRE_INTERRUPT_VIRT_BASE + 0x2c));
> +               return 1;
> +       }
> +       return 0;
> +}

I don't understand this, put in  some explanation of what this function
does please.

> +asmlinkage void __exception_irq_entry
> +       nspire_classic_handle_irq(struct pt_regs *regs)
> +{
> +       int serviced;
> +
> +       do {
> +               void __iomem *reg_base = IOMEM(NSPIRE_INTERRUPT_VIRT_BASE);

Instead of casting this in every IRQ entry define a static local
in the irq driver file to point to the base.

Avoids time in the IRQ handler, so it obviously the right thing to do.

Please also use a dynamic remapping ioremap* insteaf of
this static IOMEM() thing.

> +               serviced = 0;
> +
> +               /* IRQ */
> +               serviced += check_interrupt(reg_base, regs);
> +               /* FIQ */
> +               serviced += check_interrupt(reg_base + 0x100, regs);

Should you now handle FIQs first at all times?

> +       } while (serviced > 0);
> +}
> +
> +static void classic_irq_ack(struct irq_data *d)
> +{
> +       readl(IOMEM(NSPIRE_INTERRUPT_VIRT_BASE + 0x28));
> +}

As stated use an ioremap:ed base static local.

(...)
> +void __init nspire_classic_init_irq(void)
> +{
> +       /* No stickies */
> +       writel(0, IOMEM(NSPIRE_INTERRUPT_VIRT_BASE + 0x204));

0x204???

Use

#define FOO_REGISTER 0x204

to define understandable names for all of this so we can read the code.

Usually this means the comments are no longer needed because the
code becomes self-evident.

> +
> +       /* Disable all interrupts */
> +       writel(~0, IOMEM(NSPIRE_INTERRUPT_VIRT_BASE + 0xc));
> +       writel(~0, IOMEM(NSPIRE_INTERRUPT_VIRT_BASE + 0x10c));
> +
> +       /* Set all priorities to 0 */
> +       memset_io(IOMEM(NSPIRE_INTERRUPT_VIRT_BASE + 0x300), 0, 0x7f);
> +
> +       /* Accept interrupts of all priorities */
> +       writel(0xf, IOMEM(NSPIRE_INTERRUPT_VIRT_BASE + 0x2c));
> +       writel(0xf, IOMEM(NSPIRE_INTERRUPT_VIRT_BASE + 0x12c));
> +
> +       /* Clear existing interrupts */
> +       readl(IOMEM(NSPIRE_INTERRUPT_VIRT_BASE + 0x28));
> +       readl(IOMEM(NSPIRE_INTERRUPT_VIRT_BASE + 0x128));

Dito, everywhere.

In the end looking like this:

readl(base + NSPIRE_IRQ_FOO); or something.

No IOMEM, etc.

(...)
> +/* Timer */

Hm, looks like you just forgot to select GENERIC_CLOCKEVENTS?

Strange if it works anyway :-/

We are comtemplating putting these things into drivers/timer,
nothing decided yet.

> +static int classic_timer_set_event(unsigned long delta,
> +                               struct clock_event_device *dev)
> +{
> +       unsigned long flags;
> +
> +       local_irq_save(flags);
> +       writel(delta, NSPIRE_APB_VIRTIO(NSPIRE_APB_TIMER2));
> +       writel(1, NSPIRE_APB_VIRTIO(NSPIRE_APB_TIMER2 + 0x8));
> +       writel(0, NSPIRE_APB_VIRTIO(NSPIRE_APB_TIMER2 + 0x18));

Remove magic numbers, define register names.

Remap a base, get rid of NSPIRE_APB_VIRTIO().

> +       local_irq_restore(flags);
> +
> +       return 0;
> +}
> +static void classic_timer_set_mode(enum clock_event_mode mode,
> +                                struct clock_event_device *evt)
> +{
> +       evt->mode = mode;
> +}
> +
> +static struct clock_event_device nspire_clkevt = {
> +       .name           = "clockevent",
> +       .features       = CLOCK_EVT_FEAT_ONESHOT,
> +       .shift          = 32,
> +       .rating         = 400,
> +       .set_next_event = classic_timer_set_event,
> +       .set_mode       = classic_timer_set_mode,
> +       .cpumask                = cpu_all_mask,
> +};
> +
> +static irqreturn_t classic_timer_interrupt(int irq, void *dev_id)
> +{
> +       struct clock_event_device *c = dev_id;
> +
> +       /* Acknowledge */
> +       writel((1<<0), NSPIRE_APB_VIRTIO(NSPIRE_APB_MISC + 0x20));

writel((1<<0) isn't very helpful.

#include <linux/bitops.h>

#define NSPIRE_TIMER_ACK_REG 0x20
#define NSPIRE_TIMER_ACK BIT(0)

writel(NSPIRE_TIMER_ACK, base +  NSPIRE_TIMER_ACK_REG);

Then follow a lot of platform data and devices. These have to be moved
over to the device tree instead and deleted.

(...)
> +++ b/arch/arm/mach-nspire/touchpad.c
> @@ -0,0 +1,30 @@
> +/*
> + *     linux/arch/arm/mach-nspire/touchpad.c
> + *
> + *     Copyright (C) 2012 Fabian Vogt <fabian at ritter-vogt.de>
> + *
> + * 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/i2c.h>
> +
> +#include "touchpad.h"
> +
> +#if defined(CONFIG_MOUSE_SYNAPTICS_I2C) || \
> +       defined(CONFIG_MOUSE_SYNAPTICS_I2C_MODULE)
> +static struct i2c_board_info synaptics_i2c = {
> +       I2C_BOARD_INFO("synaptics_i2c", 0x20),
> +       .irq    = 0,
> +};
> +
> +void __init nspire_touchpad_init()
> +{
> +       i2c_register_board_info(0, &synaptics_i2c, 1);
> +}


Not only should this be done from devicetree, but exactly which
synaptics driver are you using with this?

I don't think there is one in the kernel tree yet.

> diff --git a/arch/arm/tools/mach-types b/arch/arm/tools/mach-types
> index 831e1fd..e76c16b 100644
> --- a/arch/arm/tools/mach-types
> +++ b/arch/arm/tools/mach-types
> @@ -1204,3 +1204,6 @@ baileys                   MACH_BAILEYS            BAILEYS                 4169
>  familybox              MACH_FAMILYBOX          FAMILYBOX               4170
>  ensemble_mx35          MACH_ENSEMBLE_MX35      ENSEMBLE_MX35           4171
>  sc_sps_1               MACH_SC_SPS_1           SC_SPS_1                4172
> +nspireclp              MACH_NSPIRECLP          NSPIRECLP               4441
> +nspiretp               MACH_NSPIRETP           NSPIRETP                4442
> +nspirecx               MACH_NSPIRECX           NSPIRECX                4443

We don't patch this file, Russell updates it from the machine registry on
his webpage.

And with device tree it goes irrelevant.

Yours,
Linus Walleij


From nsekhar at ti.com  Tue Apr  9 07:18:33 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Tue, 9 Apr 2013 16:48:33 +0530
Subject: [PATCH v8 0/2] ARM: davinci: dm355: add support for vpbe display
In-Reply-To: <20130408095652.33dcb0be@redhat.com>
References: <1365413215-3632-1-git-send-email-prabhakar.csengg@gmail.com>
 <51629DA8.3040806@ti.com> <20130408075606.5a59d32c@redhat.com>
 <5162AE56.5090203@ti.com> <20130408095652.33dcb0be@redhat.com>
Message-ID: <5163F909.4030109@ti.com>

On 4/8/2013 6:26 PM, Mauro Carvalho Chehab wrote:
> Em Mon, 8 Apr 2013 17:17:34 +0530
> Sekhar Nori <nsekhar at ti.com> escreveu:
> 
>> Hi Maruo,
>>
>> On 4/8/2013 4:26 PM, Mauro Carvalho Chehab wrote:
>>> Hi Sekhar,
>>>
>>> Em Mon, 8 Apr 2013 16:06:24 +0530
>>> Sekhar Nori <nsekhar at ti.com> escreveu:
>>>
>>>> On 4/8/2013 2:56 PM, Prabhakar lad wrote:
>>>>> From: Lad, Prabhakar <prabhakar.csengg at gmail.com>
>>>>>
>>>>> This patch series enables VPBE display driver on DM355.
>>>>
>>>> These (this and the DM365 one) patches look good to me. I need to get an
>>>> immutable branch from Mauro where dependencies are queued and then I can
>>>> generate a pull request for these for ARM SoC.
>>>
>>> Are you mean a branch at the media development tree for you to sent
>>> pull requests for me? If so, just use the "master" branch at the media
>>
>> The pull request will be sent to my upstreams (ie the ARM SoC folks -
>> Arnd and Olof). Since the platform data patches need driver patches to
>> be applied first, I need a non-rebasing branch containing the driver
>> stuff which I can use a dependency and apply platform patches on top.
> 
> Hmm... I generally wait for arch patches to be applied first, before
> sending driver patches. If you're willing to do that, I suggest that
> Arnd/Olof should put those patches on a separate topic branch, and
> sending an upstream pull request for them after mine.

The patches can be put on a separate branch, but the branch wont build
without the driver changes (eg need defintion of VPBE_ENC_DV_TIMINGS
from include/media/davinci/vpbe_types.h).

So this will need a immutable branch from you to depend on so Linus's
tree won't have duplicate commits when Arnd/Olof send their pull request.

> 
> If the patches are trivial, maybe the better would be to put both
> media and arm patches at the same tree, with the other maintainers'
> ack.

This seems to be the easiest path at the moment. I will ack the platform
parts and Prabhakar can issue a pull request for you. I have just
checked that these patches won't cause a merge conflict with anything
already queued through my tree.

Thanks,
Sekhar


From kgene.kim at samsung.com  Tue Apr  9 07:20:12 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Tue, 09 Apr 2013 20:20:12 +0900
Subject: [GIT PULL 10/10] devel-samsung for v3.10
In-Reply-To: <51632451.3050801@gmail.com>
References: <51630A55.6030703@samsung.com> <51632451.3050801@gmail.com>
Message-ID: <2f2f01ce3514$33d10f00$9b732d00$%kim@samsung.com>

Sylwester Nawrocki wrote:

[...]

> > Sylwester Nawrocki (2):
> > ARM: SAMSUNG: Export MIPI CSIS/DSIM PHY control functions
> 
> This one was supposed to be a fix for 3.8-rc IIRC. But anyway the whole

If so, this should be sent to stable 3.8 tree, but I'm not sure this is
really bug fix.

> file this patch touches is going to be removed in 3.11.
> 
It means it is still needed for v3.10 :-)

> > ARM: S3C24XX: Correct NR_IRQS definition for s3c2440
> 
> And this one is needed for 3.9, sorry for not mentioning it in the patch's
> description. Together with [1] it makes my s3c2440 SoC based test board
> booting again with 3.9-rc6.
> 
> [1] http://www.spinics.net/lists/arm-kernel/msg236643.html
> 
OK, let me drop it in this branch.

Arnd and Olof, please hold on pulling for this branch. I will sort out soon.

Thanks.

- Kukjin



From linus.walleij at linaro.org  Tue Apr  9 07:23:27 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Tue, 9 Apr 2013 13:23:27 +0200
Subject: [RFC PATCH arm: initial TI-Nspire support]
In-Reply-To: <201304072323.42173.arnd@arndb.de>
References: <6FE4B33E-A503-4A75-AEED-831CB2C06D83@gmail.com>
 <4B3FD561-84FC-40CD-B747-13851692D673@gmail.com>
 <521DFDFC-7E9E-47EA-ACDA-C91BBDC8454E@gmail.com>
 <201304072323.42173.arnd@arndb.de>
Message-ID: <CACRpkda9Nue-8Esp3cJ6u2-MJ2ZL8hH-2BnrhHwWv4GZP2VR5w@mail.gmail.com>

On Sun, Apr 7, 2013 at 11:23 PM, Arnd Bergmann <arnd at arndb.de> wrote:
> On Sunday 07 April 2013, Daniel Tang wrote:
>> Here's an updated patch that enables support for the LCD.
>>
>> I looked into drivers/video/of_display_timing.c but it doesn't have the fields to describe the
>> PL11x specific options needed in struct clcd_panel. At the moment, it is implemented by
>> hardcoding the values in the kernel and using the device tree to select the correct
>> configuration.
>>
>> Signed-off-by: Daniel Tang <dt.tangr at gmail.com>
>
> I think you should for now keep the clcd stuff in a separate file,
> since it will be replaced with DT logic eventually. For now, the
> auxdata method is ok, but Linus Walleij might already have thought
> about how pl111 should get all its data from the device tree.

So last thing I heard there was *someone* at ARM working on
device tree support for the PL110/PL111, so I just don't know who
this was.

But I bet Pawel knows, because it will be needed for all
ARM reference designs.

Yours,
Linus Walleij


From linux at arm.linux.org.uk  Tue Apr  9 07:30:07 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Tue, 9 Apr 2013 12:30:07 +0100
Subject: linux-next: build warning after merge of the final tree
 (probably arm-soc tree related)
In-Reply-To: <201304091121.24372.arnd@arndb.de>
References: <20130409190900.97dcf3a70a9c0ad727b8bc4b@canb.auug.org.au>
 <201304091121.24372.arnd@arndb.de>
Message-ID: <20130409113007.GB14496@n2100.arm.linux.org.uk>

On Tue, Apr 09, 2013 at 11:21:24AM +0200, Arnd Bergmann wrote:
> On Tuesday 09 April 2013, Stephen Rothwell wrote:
> > After merging the final tree, today's linux-next build (arm defconfig)
> > produced these warnings:
> > 
> > arch/arm/mach-cns3xxx/Kconfig:2:warning: choice value used outside its choice group
> > arch/arm/mach-bcm2835/Kconfig:2:warning: choice value used outside its choice group
> > arch/arm/Kconfig:287:error: recursive dependency detected!
> > arch/arm/Kconfig:287:   choice <choice> contains symbol ARCH_CNS3XXX
> > arch/arm/Kconfig:366:   symbol ARCH_CNS3XXX depends on ARCH_MULTI_V6
> > arch/arm/Kconfig:933:   symbol ARCH_MULTI_V6 depends on ARCH_MULTIPLATFORM
> > arch/arm/Kconfig:292:   symbol ARCH_MULTIPLATFORM is part of choice <choice>
> 
> Thanks for the notification, I think git rerere picked up a wrong conflict resolution
> again that I did earlier. I'll fix it when I do the next pulls today.

The problem commit is: d4b63675f7202d2d7865aa19d83537e615ad3c50 which is
your next/multiplatform branch.  It re-introduces the ARCH_CNS3XXX
in arch/arm/Kconfig, which should've remained deleted.


From nsekhar at ti.com  Tue Apr  9 07:35:25 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Tue, 9 Apr 2013 17:05:25 +0530
Subject: [PATCH v3 3/3] ARM: davinci: da850: add EHRPWM & ECAP DT node
In-Reply-To: <518397C60809E147AF5323E0420B992E3EAA9DA3@DBDE01.ent.ti.com>
References: <1364197789-16783-1-git-send-email-avinashphilip@ti.com>
 <1364197789-16783-4-git-send-email-avinashphilip@ti.com>
 <515A97DE.1080403@ti.com>
 <518397C60809E147AF5323E0420B992E3EAA91B6@DBDE01.ent.ti.com>
 <5162C1A5.5060808@ti.com>
 <518397C60809E147AF5323E0420B992E3EAA9DA3@DBDE01.ent.ti.com>
Message-ID: <5163FCFD.6070606@ti.com>

On 4/9/2013 2:12 PM, Philip, Avinash wrote:
> On Mon, Apr 08, 2013 at 18:39:57, Nori, Sekhar wrote:
>>
>> On 4/8/2013 2:39 PM, Philip, Avinash wrote:
>>> On Tue, Apr 02, 2013 at 14:03:34, Nori, Sekhar wrote:
>>>> On 3/25/2013 1:19 PM, Philip Avinash wrote:
>>>>> Add da850 EHRPWM & ECAP DT node.
>>>>> Also adds OF_DEV_AUXDATA for EHRPWM & ECAP driver to use EHRPWM & ECAP
>>>>> clock.
>>>>
>>>> This looks fine to me but I will wait for the bindings to get accepted
>>>> before taking this one.
>>>
>>> Sekhar,
>>>
>>> Binding document got accepted in PWM tree [1].
>>> Can you accept this patch?
>>
>> Can you also add the pinmux definitions and resend just this patch?
>> Sorry I did not notice those were missing earlier.
> 
> According to latest schematics, ECAP instance 2 being used for PWM backlight
> control. Should I add pin-mux only for ECAP2 or for all PWM instances?

I meant add definitions in .dtsi. Since there is only one pin a given
functionality can be present on in DaVinci, it can be done in a board
independent manner. See examples for other peripherals in existing
da850.dtsi file.

Thanks,
Sekhar


From kgene.kim at samsung.com  Tue Apr  9 07:38:30 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Tue, 09 Apr 2013 20:38:30 +0900
Subject: [PATCH] ARM: EXYNOS: no more support non-DT for EXYNOS SoCs
In-Reply-To: <2f3001ce3515$9a9ae1b0$cfd0a510$%kim@samsung.com>
References: <2f3001ce3515$9a9ae1b0$cfd0a510$%kim@samsung.com>
Message-ID: <2f3701ce3516$c29aca80$47d05f80$%kim@samsung.com>

Kukjin Kim wrote:
> 
> 
> As we discussed in mailing list, non-DT for EXYNOS SoCs will not be
> supported from v3.10. This patch removes regarding files for non-DT
> including board files.
> 
> Signed-off-by: Kukjin Kim <kgene.kim at samsung.com>
> ---
>  arch/arm/configs/exynos4_defconfig         |   68 --
>  arch/arm/mach-exynos/Kconfig               |  303 +-----
>  arch/arm/mach-exynos/Makefile              |   26 -
>  arch/arm/mach-exynos/common.c              |    9 +-
>  arch/arm/mach-exynos/dev-ahci.c            |  255 -----
>  arch/arm/mach-exynos/dev-ohci.c            |   52 --
>  arch/arm/mach-exynos/dma.c                 |  322 -------
>  arch/arm/mach-exynos/mach-armlex4210.c     |  206 -----
>  arch/arm/mach-exynos/mach-nuri.c           | 1387
> ----------------------------
>  arch/arm/mach-exynos/mach-origen.c         |  822 -----------------
>  arch/arm/mach-exynos/mach-smdk4x12.c       |  395 --------
>  arch/arm/mach-exynos/mach-smdkv310.c       |  443 ---------
>  arch/arm/mach-exynos/mach-universal_c210.c | 1159 -----------------------
>  arch/arm/mach-exynos/pm_domains.c          |    7 -
>  arch/arm/mach-exynos/setup-fimc.c          |   44 -
>  arch/arm/mach-exynos/setup-fimd0.c         |   43 -
>  arch/arm/mach-exynos/setup-i2c1.c          |   23 -
>  arch/arm/mach-exynos/setup-i2c2.c          |   23 -
>  arch/arm/mach-exynos/setup-i2c3.c          |   23 -
>  arch/arm/mach-exynos/setup-i2c4.c          |   23 -
>  arch/arm/mach-exynos/setup-i2c5.c          |   23 -
>  arch/arm/mach-exynos/setup-i2c6.c          |   23 -
>  arch/arm/mach-exynos/setup-i2c7.c          |   23 -
>  arch/arm/mach-exynos/setup-keypad.c        |   36 -
>  arch/arm/mach-exynos/setup-sdhci-gpio.c    |  152 ---
>  arch/arm/mach-exynos/setup-spi.c           |   45 -
>  arch/arm/mach-exynos/setup-usb-phy.c       |  223 -----
>  27 files changed, 3 insertions(+), 6155 deletions(-)
>  delete mode 100644 arch/arm/configs/exynos4_defconfig
>  delete mode 100644 arch/arm/mach-exynos/dev-ahci.c
>  delete mode 100644 arch/arm/mach-exynos/dev-ohci.c
>  delete mode 100644 arch/arm/mach-exynos/dma.c
>  delete mode 100644 arch/arm/mach-exynos/mach-armlex4210.c
>  delete mode 100644 arch/arm/mach-exynos/mach-nuri.c
>  delete mode 100644 arch/arm/mach-exynos/mach-origen.c
>  delete mode 100644 arch/arm/mach-exynos/mach-smdk4x12.c
>  delete mode 100644 arch/arm/mach-exynos/mach-smdkv310.c
>  delete mode 100644 arch/arm/mach-exynos/mach-universal_c210.c
>  delete mode 100644 arch/arm/mach-exynos/setup-fimc.c
>  delete mode 100644 arch/arm/mach-exynos/setup-fimd0.c
>  delete mode 100644 arch/arm/mach-exynos/setup-i2c1.c
>  delete mode 100644 arch/arm/mach-exynos/setup-i2c2.c
>  delete mode 100644 arch/arm/mach-exynos/setup-i2c3.c
>  delete mode 100644 arch/arm/mach-exynos/setup-i2c4.c
>  delete mode 100644 arch/arm/mach-exynos/setup-i2c5.c
>  delete mode 100644 arch/arm/mach-exynos/setup-i2c6.c
>  delete mode 100644 arch/arm/mach-exynos/setup-i2c7.c
>  delete mode 100644 arch/arm/mach-exynos/setup-keypad.c
>  delete mode 100644 arch/arm/mach-exynos/setup-sdhci-gpio.c
>  delete mode 100644 arch/arm/mach-exynos/setup-spi.c
>  delete mode 100644 arch/arm/mach-exynos/setup-usb-phy.c
> 
One more, as you know, we cannot support all features non-DT did only with
DT exynos. But I think, if required, some of them can be kept in samsung
tree temporarily.

Note, original patch couldn't submitted to linux arm kernel ml due to size.
And please ignore useless line wrapped due to e-mail client problem :-(

Thanks.

- Kukjin

[...]



From dt.tangr at gmail.com  Tue Apr  9 07:39:39 2013
From: dt.tangr at gmail.com (Daniel Tang)
Date: Tue, 9 Apr 2013 21:39:39 +1000
Subject: [RFC PATCH arm: initial TI-Nspire support]
In-Reply-To: <CACRpkdbuAvRzVdzKL51k5d7vVpGNUHh_f_ZAxP4m3zFdBOV=xw@mail.gmail.com>
References: <6FE4B33E-A503-4A75-AEED-831CB2C06D83@gmail.com>
 <CACRpkdbuAvRzVdzKL51k5d7vVpGNUHh_f_ZAxP4m3zFdBOV=xw@mail.gmail.com>
Message-ID: <EE94A8F2-2BC2-446E-B0B2-1E1803E240F2@gmail.com>

Hi,

Thanks for your comments! They're much appreciated. 

Just to bring you up to speed, we decided to begin reimplementing the machine from scratch and slowly pull things in from the original patch. Arnd pointed out a lot of fundamental issues with our patch so we thought it'd be better to just start over instead of patch things up.

The latest copy of our patch is somewhere in this thread (http://archive.arm.linux.org.uk/lurker/message/20130408.113343.585af217.en.html) which will have already addressed some of the problems you've pointed out (using the device tree being a major one). We would also appreciate it if you could take a look at that one too.

On 09/04/2013, at 9:14 PM, Linus Walleij <linus.walleij at linaro.org> wrote:

>> 
>> +union reg_clk_speed {
>> +       unsigned long raw;
>> +       struct {
>> +               unsigned long __padding0:1;
>> +               unsigned long base_cpu_ratio:7;
>> +               unsigned long is_base_27mhz:1;
>> +               unsigned long __padding1:3;
>> +               unsigned long cpu_ahb_ratio:3;
>> +               unsigned long __padding2:1;
>> +               unsigned long base_val:5;
>> +       } val;
>> +};
> Usually to try to fit a struct over a register range is not such a good
> idea in Linux.
> 
> Instead define abstract representations of what you want to do
> (remove everything named "padding" above, use proper data types instead
> of these unsigned longs and that complex union) then use offsets to
> registers and remap the base offset in memory.
> 
> It makes for simpler debugging and ability to properly use read|write[lwb]
> macros.

The structure is actually a bitfield. We'd readl() the raw unsigned long into the 'raw' field and then access the data via the 'val' structure. 

Should we be using bitmasks and bitshifting to get at those values instead?

> 
>> +static unsigned long classic_clocks_to_io(struct nspire_clk_speeds *clks)
>> +{
>> +       union reg_clk_speed reg;
>> +
>> +       BUG_ON(clks->div.base_cpu < 2);
>> +       BUG_ON(clks->div.cpu_ahb < 1);
>> +
>> +       reg.raw = 0;
>> +       reg.val.base_cpu_ratio = clks->div.base_cpu / 2;
>> +       reg.val.cpu_ahb_ratio = clks->div.cpu_ahb - 1;
>> +       reg.val.is_base_27mhz = (clks->base <= 27000000);
>> +       reg.val.base_val = (300 - (clks->base / 1000000)) / 6;
>> +
>> +       return reg.raw;
>> +}
> 
> And that avoid having to create special helper functions like this.
> 

Fair enough.

> 
>> +               int irqnr = readl(base + 0x24);
>> +               unsigned prev_priority;
>> +               handle_IRQ(irqnr, regs);
>> +
>> +               /* Reset priorities */
>> +               prev_priority = readl(IOMEM(NSPIRE_INTERRUPT_VIRT_BASE + 0x28));
>> +               writel(prev_priority, IOMEM(NSPIRE_INTERRUPT_VIRT_BASE + 0x2c));
>> +               return 1;
>> +       }
>> +       return 0;
>> +}
> 
> I don't understand this, put in  some explanation of what this function
> does please.

Yep gotcha. In future patches, we'll also put the magic numbers into proper defines.

> 
>> +asmlinkage void __exception_irq_entry
>> +       nspire_classic_handle_irq(struct pt_regs *regs)
>> +{
>> +       int serviced;
>> +
>> +       do {
>> +               void __iomem *reg_base = IOMEM(NSPIRE_INTERRUPT_VIRT_BASE);
> 
> Instead of casting this in every IRQ entry define a static local
> in the irq driver file to point to the base.
> 
> Avoids time in the IRQ handler, so it obviously the right thing to do.
> 
> Please also use a dynamic remapping ioremap* insteaf of
> this static IOMEM() thing.
> 
>> +               serviced = 0;
>> +
>> +               /* IRQ */
>> +               serviced += check_interrupt(reg_base, regs);
>> +               /* FIQ */
>> +               serviced += check_interrupt(reg_base + 0x100, regs);
> 
> Should you now handle FIQs first at all times?

Ah yes, that would make sense.

> 
> Hm, looks like you just forgot to select GENERIC_CLOCKEVENTS?
> 
> Strange if it works anyway :-/
> 
> We are comtemplating putting these things into drivers/timer,
> nothing decided yet.

That's fine, we'll deal with it when we pull this file into the 'good' patch.

> 
> Not only should this be done from devicetree, but exactly which
> synaptics driver are you using with this?
> 
> I don't think there is one in the kernel tree yet.
> 

It's this one here http://lxr.free-electrons.com/source/drivers/input/mouse/synaptics_i2c.c
> 
> 
> And with device tree it goes irrelevant.

Yep, this has been addressed in our updated patch.

> 
> Yours,
> Linus Walleij


Also, how would you like us to submit updates? Should we continue posting updated patches as replies to this thread?

Cheers,
tangrs

From ezequiel.garcia at free-electrons.com  Tue Apr  9 07:40:18 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Tue,  9 Apr 2013 08:40:18 -0300
Subject: [PATCH v5 0/5] Device Bus support for Marvell EBU SoC
Message-ID: <1365507623-18043-1-git-send-email-ezequiel.garcia@free-electrons.com>

This patchset continues the effort to add Device Bus support
on Marvell EBU SoC.

If you're reading this for the first time you can grab the full details here:

  http://www.spinics.net/lists/arm-kernel/msg236151.html

This new version changes the way each chip select is described in the DT.
Now there's a separate node for each Device Bus chip select, like this:

	devbus-bootcs at d0010400 {
		compatible = "marvell,mvebu-devbus";
		reg = <0xd0010400 0x8>;
		ranges = <0 0xf0000000 0x8000000>; /* @addr 0xf000000, size 0x8000000 */

		device at 0 {
			reg = <0 0x8000000>;
		}
	};

	// ...

	devbus-cs1 at d0010410 {
		compatible = "marvell,mvebu-devbus";
		reg = <0xd0010410 0x8>;
	};

In particular, please note that once the window handling is properly added
to the DT, and we remove the mbus usage from this driver, in the above DT nodes
the ranges property value will have to be changed, but the ABI will be the same.

This applies on top of v3.9-rc5 with mbus patches applied, which can 
be found in Jason Cooper's mvebus/soc branch.
If anyone wants to try this, there's a public branch available at:

  https://github.com/MISL-EBU-System-SW/mainline-public/tree/mvebu-devbus-v5

Changes from v4:

  * Calculate the chip select from the base address
    and drop the 2-cell address size.
    Suggested by Arnd Bergmann and Jason Gunthorpe.

  * The mvebu driver can't be compiled as a module, since the mbus
    API is not exported yet, so remove that option.

  * Bunch of comments here and there...

Changes from v3:

  * Rename devbus,dev-width to devbus,bus-width and changed the
    parameter value from bytes to bits: <8>, <16>, ...
    Suggested by Arnd Bergmann.

  * As suggested by Jason Gunthorpe and agreed by Arnd Bergmann.
    Reworked the whole devbus child chip-select device tree design.
    Now there's a separate devbus at addr DT node for each controller
    chip select. The impact of this is:
      1. Timing parameters now go into the parent node.
      2. There can only be one child per devbus node.

  * Remove unneeded bank-width parameter read.

Changes from v2:

  * Replace the 'NOR' specific probe by a generic probe.
    Currently, we don't see anything specific to NOR in this driver.
    Suggested by Jason Gunthorpe.

  * Add a check to detect that every timing parameter is specified
    in the device tree node.
    Suggested by Jason Gunthorpe.

Changes from v1:

  * Added a remove() function to unregister childs and remove address windows,
    as suggested by Thomas Petazzoni.

  * Remove unneeded 'inline' prefix on functions as suggested by Thomas Petazzoni.

  * Timings parameters are now mandatory and expressed in picoseconds,
    as requested by Jason Gunthorpe.
    This is consistent with OMAP's GPMC dts binding.

  * Fix documentation as suggested by Jason Gunthorpe.

Thanks!

Ezequiel Garcia (5):
  drivers: memory: Introduce Marvell EBU Device Bus driver
  ARM: mvebu: Add Device Bus support for Armada 370/XP SoC
  ARM: mvebu: Add support for NOR flash device on Armada XP-GP board
  ARM: mvebu: Add support for NOR flash device on Openblocks AX3 board
  ARM: mvebu: Add Device Bus and CFI flash memory support to defconfig

 .../bindings/memory-controllers/mvebu-devbus.txt   | 156 +++++++++
 arch/arm/boot/dts/armada-370-xp.dtsi               |  45 +++
 arch/arm/boot/dts/armada-xp-gp.dts                 |  29 ++
 arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts   |  29 ++
 arch/arm/configs/mvebu_defconfig                   |   7 +
 drivers/memory/Kconfig                             |  10 +
 drivers/memory/Makefile                            |   1 +
 drivers/memory/mvebu-devbus.c                      | 366 +++++++++++++++++++++
 8 files changed, 643 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/memory-controllers/mvebu-devbus.txt
 create mode 100644 drivers/memory/mvebu-devbus.c

-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Tue Apr  9 07:40:19 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Tue,  9 Apr 2013 08:40:19 -0300
Subject: [PATCH v5 1/5] drivers: memory: Introduce Marvell EBU Device Bus
 driver
In-Reply-To: <1365507623-18043-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1365507623-18043-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1365507623-18043-2-git-send-email-ezequiel.garcia@free-electrons.com>

Marvell EBU SoCs such as Armada 370/XP, Orion5x (88f5xxx) and
Discovery (mv78xx0) supports a Device Bus controller to access several
kinds of memories and I/O devices (NOR, NAND, SRAM, FPGA).

This commit adds a driver to handle this controller. So far only
Armada 370, Armada XP and Discovery SoCs are supported.

The driver must be registered through a device tree node;
as explained in the binding document.

For each child node in the device tree, this driver will:
  * set timing parameters
  * register a child device
  * setup an address decoding window, using the mbus driver

Keep in mind the address decoding window setup is only a temporary hack.
This code will be removed from this devbus driver as soon as a proper device
tree binding for the mbus driver is added.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
Acked-by: Arnd Bergmann <arnd at arndb.de>
---
 .../bindings/memory-controllers/mvebu-devbus.txt   | 156 +++++++++
 drivers/memory/Kconfig                             |  10 +
 drivers/memory/Makefile                            |   1 +
 drivers/memory/mvebu-devbus.c                      | 366 +++++++++++++++++++++
 4 files changed, 533 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/memory-controllers/mvebu-devbus.txt
 create mode 100644 drivers/memory/mvebu-devbus.c

diff --git a/Documentation/devicetree/bindings/memory-controllers/mvebu-devbus.txt b/Documentation/devicetree/bindings/memory-controllers/mvebu-devbus.txt
new file mode 100644
index 0000000..653c90c
--- /dev/null
+++ b/Documentation/devicetree/bindings/memory-controllers/mvebu-devbus.txt
@@ -0,0 +1,156 @@
+Device tree bindings for MVEBU Device Bus controllers
+
+The Device Bus controller available in some Marvell's SoC allows to control
+different types of standard memory and I/O devices such as NOR, NAND, and FPGA.
+The actual devices are instantiated from the child nodes of a Device Bus node.
+
+Required properties:
+
+ - compatible:          Currently only Armada 370/XP SoC are supported,
+                        with this compatible string:
+
+                        marvell,mvebu-devbus
+
+ - reg:                 A resource specifier for the register space.
+                        This is the base address of a chip select within
+			the controller's register space.
+                        (see the example below)
+
+ - #address-cells:      Must be set to 1
+ - #size-cells:         Must be set to 1
+ - ranges:              Must be set up to reflect the memory layout with four
+                        integer values for each chip-select line in use:
+                        0 <physical address of mapping> <size>
+
+Mandatory timing properties for child nodes:
+
+Read parameters:
+
+ - devbus,turn-off-ps:  Defines the time during which the controller does not
+                        drive the AD bus after the completion of a device read.
+                        This prevents contentions on the Device Bus after a read
+                        cycle from a slow device.
+
+ - devbus,bus-width:    Defines the bus width (e.g. <16>)
+
+ - devbus,badr-skew-ps: Defines the time delay from from A[2:0] toggle,
+                        to read data sample. This parameter is useful for
+                        synchronous pipelined devices, where the address
+                        precedes the read data by one or two cycles.
+
+ - devbus,acc-first-ps: Defines the time delay from the negation of
+                        ALE[0] to the cycle that the first read data is sampled
+                        by the controller.
+
+ - devbus,acc-next-ps:  Defines the time delay between the cycle that
+                        samples data N and the cycle that samples data N+1
+                        (in burst accesses).
+
+ - devbus,rd-setup-ps:  Defines the time delay between DEV_CSn assertion to
+			DEV_OEn assertion. If set to 0 (default),
+                        DEV_OEn and DEV_CSn are asserted at the same cycle.
+                        This parameter has no affect on <acc-first-ps> parameter
+                        (no affect on first data sample). Set <rd-setup-ps>
+                        to a value smaller than <acc-first-ps>.
+
+ - devbus,rd-hold-ps:   Defines the time between the last data sample to the
+			de-assertion of DEV_CSn. If set to 0 (default),
+			DEV_OEn and DEV_CSn are de-asserted at the same cycle
+			(the cycle of the last data sample).
+                        This parameter has no affect on DEV_OEn de-assertion.
+                        DEV_OEn is always de-asserted the next cycle after
+                        last data sampled. Also this parameter has no
+                        affect on <turn-off-ps> parameter.
+                        Set <rd-hold-ps> to a value smaller than <turn-off-ps>.
+
+Write parameters:
+
+ - devbus,ale-wr-ps:    Defines the time delay from the ALE[0] negation cycle
+			to the DEV_WEn assertion.
+
+ - devbus,wr-low-ps:    Defines the time during which DEV_WEn is active.
+                        A[2:0] and Data are kept valid as long as DEV_WEn
+                        is active. This parameter defines the setup time of
+                        address and data to DEV_WEn rise.
+
+ - devbus,wr-high-ps:   Defines the time during which DEV_WEn is kept
+                        inactive (high) between data beats of a burst write.
+                        DEV_A[2:0] and Data are kept valid (do not toggle) for
+                        <wr-high-ps> - <tick> ps.
+			This parameter defines the hold time of address and
+			data after DEV_WEn rise.
+
+ - devbus,sync-enable: Synchronous device enable.
+                       1: True
+                       0: False
+
+An example for an Armada XP GP board, with a 16 MiB NOR device as child
+is showed below. Note that the Device Bus driver is in charge of allocating
+the mbus address decoding window for each of its child devices.
+The window is created using the chip select specified in the child
+device node together with the base address and size specified in the ranges
+property. For instance, in the example below the allocated decoding window
+will start at base address 0xf0000000, with a size 0x1000000 (16 MiB)
+for chip select 0 (a.k.a DEV_BOOTCS).
+
+This address window handling is done in this mvebu-devbus only as a temporary
+solution. It will be removed when the support for mbus device tree binding is
+added.
+
+The reg property implicitly specifies the chip select as this:
+
+  0x10400: DEV_BOOTCS
+  0x10408: DEV_CS0
+  0x10410: DEV_CS1
+  0x10418: DEV_CS2
+  0x10420: DEV_CS3
+
+Example:
+
+	devbus-bootcs at d0010400 {
+		status = "okay";
+		ranges = <0 0xf0000000 0x1000000>; /* @addr 0xf0000000, size 0x1000000 */
+		#address-cells = <1>;
+		#size-cells = <1>;
+
+		/* Device Bus parameters are required */
+
+		/* Read parameters */
+		devbus,bus-width    = <8>;
+		devbus,turn-off-ps  = <60000>;
+		devbus,badr-skew-ps = <0>;
+		devbus,acc-first-ps = <124000>;
+		devbus,acc-next-ps  = <248000>;
+		devbus,rd-setup-ps  = <0>;
+		devbus,rd-hold-ps   = <0>;
+
+		/* Write parameters */
+		devbus,sync-enable = <0>;
+		devbus,wr-high-ps  = <60000>;
+		devbus,wr-low-ps   = <60000>;
+		devbus,ale-wr-ps   = <60000>;
+
+		flash at 0 {
+			compatible = "cfi-flash";
+
+			/* 16 MiB */
+			reg = <0 0x1000000>;
+			bank-width = <2>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+
+			/*
+			 * We split the 16 MiB in two partitions,
+			 * just as an example.
+			 */
+			partition at 0 {
+				label = "First";
+				reg = <0 0x800000>;
+			};
+
+			partition at 800000 {
+				label = "Second";
+				reg = <0x800000 0x800000>;
+			};
+		};
+	};
diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig
index 067f311..29a11db 100644
--- a/drivers/memory/Kconfig
+++ b/drivers/memory/Kconfig
@@ -20,6 +20,16 @@ config TI_EMIF
 	  parameters and other settings during frequency, voltage and
 	  temperature changes
 
+config MVEBU_DEVBUS
+	bool "Marvell EBU Device Bus Controller"
+	default y
+	depends on PLAT_ORION && OF
+	help
+	  This driver is for the Device Bus controller available in some
+	  Marvell EBU SoCs such as Discovery (mv78xx0), Orion (88f5xxx) and
+	  Armada 370 and Armada XP. This controller allows to handle flash
+	  devices such as NOR, NAND, SRAM, and FPGA.
+
 config TEGRA20_MC
 	bool "Tegra20 Memory Controller(MC) driver"
 	default y
diff --git a/drivers/memory/Makefile b/drivers/memory/Makefile
index 9cce5d7..969d923 100644
--- a/drivers/memory/Makefile
+++ b/drivers/memory/Makefile
@@ -6,5 +6,6 @@ ifeq ($(CONFIG_DDR),y)
 obj-$(CONFIG_OF)		+= of_memory.o
 endif
 obj-$(CONFIG_TI_EMIF)		+= emif.o
+obj-$(CONFIG_MVEBU_DEVBUS)	+= mvebu-devbus.o
 obj-$(CONFIG_TEGRA20_MC)	+= tegra20-mc.o
 obj-$(CONFIG_TEGRA30_MC)	+= tegra30-mc.o
diff --git a/drivers/memory/mvebu-devbus.c b/drivers/memory/mvebu-devbus.c
new file mode 100644
index 0000000..313eae1
--- /dev/null
+++ b/drivers/memory/mvebu-devbus.c
@@ -0,0 +1,366 @@
+/*
+ * Marvell EBU SoC Device Bus Controller
+ * (memory controller for NOR/NAND/SRAM/FPGA devices)
+ *
+ * Copyright (C) 2013 Marvell
+ *
+ * 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 version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
+ *
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/slab.h>
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/clk.h>
+#include <linux/mbus.h>
+#include <linux/of_platform.h>
+#include <linux/of_address.h>
+#include <linux/platform_device.h>
+
+/* Register definitions */
+#define DEV_WIDTH_BIT		30
+#define BADR_SKEW_BIT		28
+#define RD_HOLD_BIT		23
+#define ACC_NEXT_BIT		17
+#define RD_SETUP_BIT		12
+#define ACC_FIRST_BIT		6
+
+#define SYNC_ENABLE_BIT		24
+#define WR_HIGH_BIT		16
+#define WR_LOW_BIT		8
+
+#define READ_PARAM_OFFSET	0x0
+#define WRITE_PARAM_OFFSET	0x4
+
+static const char * const devbus_wins[] = {
+	"devbus-boot",
+	"devbus-cs0",
+	"devbus-cs1",
+	"devbus-cs2",
+	"devbus-cs3",
+};
+
+struct devbus_read_params {
+	u32 bus_width;
+	u32 badr_skew;
+	u32 turn_off;
+	u32 acc_first;
+	u32 acc_next;
+	u32 rd_setup;
+	u32 rd_hold;
+};
+
+struct devbus_write_params {
+	u32 sync_enable;
+	u32 wr_high;
+	u32 wr_low;
+	u32 ale_wr;
+};
+
+struct devbus {
+	struct device *dev;
+	void __iomem *base;
+	unsigned long tick_ps;
+
+	/*
+	 * Remove this once the allocation window handling
+	 * is moved out of here, to be described in the DT.
+	 */
+	struct resource child_mem;
+
+	/* For now, only one child is created per chip select */
+	struct platform_device *child;
+};
+
+static int get_timing_param_ps(struct devbus *devbus,
+			       struct device_node *node,
+			       const char *name,
+			       u32 *ticks)
+{
+	u32 time_ps;
+	int err;
+
+	err = of_property_read_u32(node, name, &time_ps);
+	if (err < 0) {
+		dev_err(devbus->dev, "%s has no '%s' property\n",
+			name, node->full_name);
+		return err;
+	}
+
+	*ticks = (time_ps + devbus->tick_ps - 1) / devbus->tick_ps;
+
+	dev_dbg(devbus->dev, "%s: %u ps -> 0x%x\n",
+		name, time_ps, *ticks);
+	return 0;
+}
+
+static int devbus_set_timing_params(struct devbus *devbus,
+				    struct device_node *node)
+{
+	struct devbus_read_params r;
+	struct devbus_write_params w;
+	u32 value;
+	int err;
+
+	dev_dbg(devbus->dev, "Setting timing parameter, tick is %lu ps\n",
+		devbus->tick_ps);
+
+	/* Get read timings */
+	err = of_property_read_u32(node, "devbus,bus-width", &r.bus_width);
+	if (err < 0) {
+		dev_err(devbus->dev,
+			"%s has no 'devbus,bus-width' property\n",
+			node->full_name);
+		return err;
+	}
+	/* Convert bit width to byte width */
+	r.bus_width /= 8;
+
+	err = get_timing_param_ps(devbus, node, "devbus,badr-skew-ps",
+				 &r.badr_skew);
+	if (err < 0)
+		return err;
+
+	err = get_timing_param_ps(devbus, node, "devbus,turn-off-ps",
+				 &r.turn_off);
+	if (err < 0)
+		return err;
+
+	err = get_timing_param_ps(devbus, node, "devbus,acc-first-ps",
+				 &r.acc_first);
+	if (err < 0)
+		return err;
+
+	err = get_timing_param_ps(devbus, node, "devbus,acc-next-ps",
+				 &r.acc_next);
+	if (err < 0)
+		return err;
+
+	err = get_timing_param_ps(devbus, node, "devbus,rd-setup-ps",
+				 &r.rd_setup);
+	if (err < 0)
+		return err;
+
+	err = get_timing_param_ps(devbus, node, "devbus,rd-hold-ps",
+				 &r.rd_hold);
+	if (err < 0)
+		return err;
+
+	/* Get write timings */
+	err = of_property_read_u32(node, "devbus,sync-enable",
+				  &w.sync_enable);
+	if (err < 0) {
+		dev_err(devbus->dev,
+			"%s has no 'devbus,sync-enable' property\n",
+			node->full_name);
+		return err;
+	}
+
+	err = get_timing_param_ps(devbus, node, "devbus,ale-wr-ps",
+				 &w.ale_wr);
+	if (err < 0)
+		return err;
+
+	err = get_timing_param_ps(devbus, node, "devbus,wr-low-ps",
+				 &w.wr_low);
+	if (err < 0)
+		return err;
+
+	err = get_timing_param_ps(devbus, node, "devbus,wr-high-ps",
+				 &w.wr_high);
+	if (err < 0)
+		return err;
+
+	/* Set read timings */
+	value = r.bus_width << DEV_WIDTH_BIT |
+		r.badr_skew << BADR_SKEW_BIT |
+		r.rd_hold   << RD_HOLD_BIT   |
+		r.acc_next  << ACC_NEXT_BIT  |
+		r.rd_setup  << RD_SETUP_BIT  |
+		r.acc_first << ACC_FIRST_BIT |
+		r.turn_off;
+
+	dev_dbg(devbus->dev, "read parameters register 0x%p = 0x%x\n",
+		devbus->base + READ_PARAM_OFFSET,
+		value);
+
+	writel(value, devbus->base + READ_PARAM_OFFSET);
+
+	/* Set write timings */
+	value = w.sync_enable  << SYNC_ENABLE_BIT |
+		w.wr_low       << WR_LOW_BIT      |
+		w.wr_high      << WR_HIGH_BIT     |
+		w.ale_wr;
+
+	dev_dbg(devbus->dev, "write parameters register: 0x%p = 0x%x\n",
+		devbus->base + WRITE_PARAM_OFFSET,
+		value);
+
+	writel(value, devbus->base + WRITE_PARAM_OFFSET);
+
+	return 0;
+}
+
+static int mvebu_devbus_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct device_node *node = pdev->dev.of_node;
+	struct device_node *child;
+	struct devbus *devbus;
+	struct resource *res;
+	struct clk *clk;
+	unsigned long rate;
+	int err, cs;
+
+	devbus = devm_kzalloc(&pdev->dev, sizeof(struct devbus), GFP_KERNEL);
+	if (!devbus)
+		return -ENOMEM;
+
+	devbus->dev = dev;
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	devbus->base = devm_ioremap_resource(&pdev->dev, res);
+	if (IS_ERR(devbus->base))
+		return PTR_ERR(devbus->base);
+
+	clk = devm_clk_get(&pdev->dev, NULL);
+	if (IS_ERR(clk))
+		return PTR_ERR(clk);
+	clk_prepare_enable(clk);
+
+	/*
+	 * Obtain clock period in picoseconds,
+	 * we need this in order to convert timing
+	 * parameters from cycles to picoseconds.
+	 */
+	rate = clk_get_rate(clk) / 1000;
+	devbus->tick_ps = 1000000000 / rate;
+
+	child = of_get_next_child(node, NULL);
+	if (!child) {
+		dev_err(dev, "%s has no childs\n", node->full_name);
+		return -EINVAL;
+	}
+
+	/* Read the device tree node and set the new timing parameters */
+	err = devbus_set_timing_params(devbus, node);
+	if (err < 0)
+		return err;
+
+	/*
+	 * Allocate an address window for this device.
+	 * If the device probing fails, then we won't be able to
+	 * remove the allocated address decoding window.
+	 *
+	 * FIXME: This is only a temporary hack! We need to do this here
+	 * because we still don't have device tree bindings for mbus.
+	 * Once that support is added, we will declare these address windows
+	 * statically in the device tree, and remove the window configuration
+	 * from here.
+	 */
+
+	/*
+	 * Get the CS to choose the window string.
+	 * This is a bit hacky, but it will be removed once the
+	 * address windows are declared in the device tree.
+	 */
+	cs = (((unsigned long)devbus->base) % 0x400) / 8;
+
+	/*
+	 * Translate the child's memory region to create the address window.
+	 * This too, will be removed once the address windows are declared
+	 * in the device tree.
+	 */
+	if (of_address_to_resource(child, 0, &devbus->child_mem)) {
+		dev_err(dev, "%s has malformed 'reg' property\n",
+			child->full_name);
+		return -EINVAL;
+	}
+
+	/*
+	 * Create an mbus address windows.
+	 * FIXME: Remove this, together with the above code, once the
+	 * address windows are declared in the device tree.
+	 */
+	err = mvebu_mbus_add_window(devbus_wins[cs], devbus->child_mem.start,
+				    resource_size(&devbus->child_mem));
+	if (err < 0)
+		return err;
+
+	/*
+	 * We need to create a child device explicitly from here to
+	 * guarantee that the child will be probed after the timing
+	 * parameters for the bus are written.
+	 *
+	 * For simplicity, only one child is created per chip select,
+	 * but it's trivial to extend this.
+	 *
+	 * TODO:
+	 * The next step would be to use of_platform_populate() here to
+	 * create a bunch of child nodes and remove the one-child constraint.
+	 *
+	 * Before that and in order to properly unregister the child nodes
+	 * we need to implement a new function of_platform_remove/unregister,
+	 * the opposite of of_platform_populate.
+	 */
+	devbus->child = of_platform_device_create(child, NULL, &pdev->dev);
+	if (!devbus->child) {
+		dev_warn(dev, "cannot create child device %s\n", child->name);
+		/* Remove the allocated window */
+		mvebu_mbus_del_window(devbus->child_mem.start,
+				      resource_size(&devbus->child_mem));
+	}
+
+	platform_set_drvdata(pdev, devbus);
+
+	return 0;
+}
+
+static int mvebu_devbus_remove(struct platform_device *pdev)
+{
+	struct devbus *devbus = platform_get_drvdata(pdev);
+
+	/* Release device */
+	of_device_unregister(devbus->child);
+
+	/* Release window */
+	mvebu_mbus_del_window(devbus->child_mem.start,
+			      resource_size(&devbus->child_mem));
+
+	devbus->child = NULL;
+	platform_set_drvdata(pdev, NULL);
+
+	return 0;
+}
+
+static const struct of_device_id mvebu_devbus_of_match[] = {
+	{ .compatible = "marvell,mvebu-devbus" },
+	{},
+};
+MODULE_DEVICE_TABLE(of, mvebu_devbus_of_match);
+
+static struct platform_driver mvebu_devbus_driver = {
+	.probe		= mvebu_devbus_probe,
+	.remove		= mvebu_devbus_remove,
+	.driver		= {
+		.name	= "mvebu-devbus",
+		.owner	= THIS_MODULE,
+		.of_match_table = mvebu_devbus_of_match,
+	},
+};
+module_platform_driver(mvebu_devbus_driver);
+
+MODULE_LICENSE("GPL v2");
+MODULE_AUTHOR("Ezequiel Garcia <ezequiel.garcia at free-electrons.com>");
+MODULE_DESCRIPTION("Marvell EBU SoC Device Bus controller");
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Tue Apr  9 07:40:20 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Tue,  9 Apr 2013 08:40:20 -0300
Subject: [PATCH v5 2/5] ARM: mvebu: Add Device Bus support for Armada 370/XP
 SoC
In-Reply-To: <1365507623-18043-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1365507623-18043-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1365507623-18043-3-git-send-email-ezequiel.garcia@free-electrons.com>

Armada 370 and Armada XP SoC have a Device Bus controller to
handle NOR, NAND, SRAM and FPGA devices.
This patch adds the device tree node to enable the controller.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
Acked-by: Arnd Bergmann <arnd at arndb.de>
---
 arch/arm/boot/dts/armada-370-xp.dtsi | 45 ++++++++++++++++++++++++++++++++++++
 1 file changed, 45 insertions(+)

diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi b/arch/arm/boot/dts/armada-370-xp.dtsi
index 7704829..9693f79 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -176,6 +176,51 @@
 			clocks = <&coreclk 0>;
 			status = "disabled";
 		};
+
+		devbus-bootcs at d0010400 {
+			compatible = "marvell,mvebu-devbus";
+			reg = <0xd0010400 0x8>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			clocks = <&coreclk 0>;
+			status = "disabled";
+		};
+
+		devbus-cs0 at d0010408 {
+			compatible = "marvell,mvebu-devbus";
+			reg = <0xd0010408 0x8>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			clocks = <&coreclk 0>;
+			status = "disabled";
+		};
+
+		devbus-cs1 at d0010410 {
+			compatible = "marvell,mvebu-devbus";
+			reg = <0xd0010410 0x8>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			clocks = <&coreclk 0>;
+			status = "disabled";
+		};
+
+		devbus-cs2 at d0010418 {
+			compatible = "marvell,mvebu-devbus";
+			reg = <0xd0010418 0x8>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			clocks = <&coreclk 0>;
+			status = "disabled";
+		};
+
+		devbus-cs3 at d0010420 {
+			compatible = "marvell,mvebu-devbus";
+			reg = <0xd0010420 0x8>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			clocks = <&coreclk 0>;
+			status = "disabled";
+		};
 	};
 };
 
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Tue Apr  9 07:40:21 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Tue,  9 Apr 2013 08:40:21 -0300
Subject: [PATCH v5 3/5] ARM: mvebu: Add support for NOR flash device on Armada
 XP-GP board
In-Reply-To: <1365507623-18043-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1365507623-18043-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1365507623-18043-4-git-send-email-ezequiel.garcia@free-electrons.com>

The Armada XP Development Board DB-MV784MP-GP has a NOR flash device
connected to the Device Bus. This commit adds the device tree node
to support this device.

This SoC supports a flexible and dynamic decoding window allocation
scheme; but since this feature is still not implemented we need
to specify the window base address in the device tree node itself.

This base address has been selected in a completely arbitrary fashion.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
Acked-by: Arnd Bergmann <arnd at arndb.de>
---
 arch/arm/boot/dts/armada-xp-gp.dts | 29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)

diff --git a/arch/arm/boot/dts/armada-xp-gp.dts b/arch/arm/boot/dts/armada-xp-gp.dts
index 1c8afe2..e57e9c7 100644
--- a/arch/arm/boot/dts/armada-xp-gp.dts
+++ b/arch/arm/boot/dts/armada-xp-gp.dts
@@ -109,5 +109,34 @@
 				spi-max-frequency = <108000000>;
 			};
 		};
+
+		devbus-bootcs at d0010400 {
+			status = "okay";
+			ranges = <0 0xf0000000 0x1000000>; /* @addr 0xf000000, size 0x1000000 */
+
+			/* Device Bus parameters are required */
+
+			/* Read parameters */
+			devbus,bus-width    = <8>;
+			devbus,turn-off-ps  = <60000>;
+			devbus,badr-skew-ps = <0>;
+			devbus,acc-first-ps = <124000>;
+			devbus,acc-next-ps  = <248000>;
+			devbus,rd-setup-ps  = <0>;
+			devbus,rd-hold-ps   = <0>;
+
+			/* Write parameters */
+			devbus,sync-enable = <0>;
+			devbus,wr-high-ps  = <60000>;
+			devbus,wr-low-ps   = <60000>;
+			devbus,ale-wr-ps   = <60000>;
+
+			/* NOR 16 MiB */
+			nor at 0 {
+				compatible = "cfi-flash";
+				reg = <0 0x1000000>;
+				bank-width = <2>;
+			};
+		};
 	};
 };
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Tue Apr  9 07:40:22 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Tue,  9 Apr 2013 08:40:22 -0300
Subject: [PATCH v5 4/5] ARM: mvebu: Add support for NOR flash device on
 Openblocks AX3 board
In-Reply-To: <1365507623-18043-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1365507623-18043-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1365507623-18043-5-git-send-email-ezequiel.garcia@free-electrons.com>

The Plat'home Openblocks AX3 has a 128 MiB NOR flash device connected
to the Device Bus. This commit adds the device tree node to support this device.

The SoC supports a flexible and dynamic decoding window allocation scheme;
but since this feature is still not implemented we need to specify the window
base address in the device tree node itself.
This base address has been selected in a completely arbitrary fashion.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
Acked-by: Arnd Bergmann <arnd at arndb.de>
---
 arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 29 ++++++++++++++++++++++++
 1 file changed, 29 insertions(+)

diff --git a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
index 3818a82..b5c5f4d 100644
--- a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
+++ b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
@@ -139,5 +139,34 @@
 		usb at d0051000 {
 			status = "okay";
 		};
+
+		devbus-bootcs at d0010400 {
+			status = "okay";
+			ranges = <0 0xf0000000 0x8000000>; /* @addr 0xf000000, size 0x8000000 */
+
+			/* Device Bus parameters are required */
+
+			/* Read parameters */
+			devbus,bus-width    = <8>;
+			devbus,turn-off-ps  = <60000>;
+			devbus,badr-skew-ps = <0>;
+			devbus,acc-first-ps = <124000>;
+			devbus,acc-next-ps  = <248000>;
+			devbus,rd-setup-ps  = <0>;
+			devbus,rd-hold-ps   = <0>;
+
+			/* Write parameters */
+			devbus,sync-enable = <0>;
+			devbus,wr-high-ps  = <60000>;
+			devbus,wr-low-ps   = <60000>;
+			devbus,ale-wr-ps   = <60000>;
+
+			/* NOR 128 MiB */
+			nor at 0 {
+				compatible = "cfi-flash";
+				reg = <0 0x8000000>;
+				bank-width = <2>;
+			};
+		};
 	};
 };
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Tue Apr  9 07:40:23 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Tue,  9 Apr 2013 08:40:23 -0300
Subject: [PATCH v5 5/5] ARM: mvebu: Add Device Bus and CFI flash memory
 support to defconfig
In-Reply-To: <1365507623-18043-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1365507623-18043-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1365507623-18043-6-git-send-email-ezequiel.garcia@free-electrons.com>

This patch selects the devbus driver as part of the mvebu default
config, along with the required options to detect and support
CFI flash memories.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
Acked-by: Arnd Bergmann <arnd at arndb.de>
---
 arch/arm/configs/mvebu_defconfig | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/configs/mvebu_defconfig b/arch/arm/configs/mvebu_defconfig
index 2ec8119..fe8ba26 100644
--- a/arch/arm/configs/mvebu_defconfig
+++ b/arch/arm/configs/mvebu_defconfig
@@ -46,6 +46,11 @@ CONFIG_I2C_MV64XXX=y
 CONFIG_MTD=y
 CONFIG_MTD_CHAR=y
 CONFIG_MTD_M25P80=y
+CONFIG_MTD_CFI=y
+CONFIG_MTD_CFI_INTELEXT=y
+CONFIG_MTD_CFI_AMDSTD=y
+CONFIG_MTD_CFI_STAA=y
+CONFIG_MTD_PHYSMAP_OF=y
 CONFIG_SERIAL_8250_DW=y
 CONFIG_GPIOLIB=y
 CONFIG_GPIO_SYSFS=y
@@ -65,6 +70,8 @@ CONFIG_RTC_DRV_S35390A=y
 CONFIG_RTC_DRV_MV=y
 CONFIG_DMADEVICES=y
 CONFIG_MV_XOR=y
+CONFIG_MEMORY=y
+CONFIG_MVEBU_DEVBUS=y
 # CONFIG_IOMMU_SUPPORT is not set
 CONFIG_EXT2_FS=y
 CONFIG_EXT3_FS=y
-- 
1.8.1.5



From arnd at arndb.de  Tue Apr  9 07:48:14 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 9 Apr 2013 13:48:14 +0200
Subject: [PATCH] ARM: EXYNOS: no more support non-DT for EXYNOS SoCs
In-Reply-To: <2f3701ce3516$c29aca80$47d05f80$%kim@samsung.com>
References: <2f3001ce3515$9a9ae1b0$cfd0a510$%kim@samsung.com>
 <2f3701ce3516$c29aca80$47d05f80$%kim@samsung.com>
Message-ID: <201304091348.14887.arnd@arndb.de>

On Tuesday 09 April 2013, Kukjin Kim wrote:
> One more, as you know, we cannot support all features non-DT did only with
> DT exynos. But I think, if required, some of them can be kept in samsung
> tree temporarily.

Which are the features that are going to be missing? Is it possible to
add the ones that people are likely to miss using auxdata?
 
> Note, original patch couldn't submitted to linux arm kernel ml due to size.
> And please ignore useless line wrapped due to e-mail client problem :-(

You might be able to send it when you create the patch using 'git format-patch 
-M -D', which will leave out deleted files.

	Arnd


From nsekhar at ti.com  Tue Apr  9 07:48:20 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Tue, 9 Apr 2013 17:18:20 +0530
Subject: [PATCH v9 1/2] ARM: davinci: dm365: add support for v4l2 video
 display
In-Reply-To: <1365412636-3468-2-git-send-email-prabhakar.csengg@gmail.com>
References: <1365412636-3468-1-git-send-email-prabhakar.csengg@gmail.com>
 <1365412636-3468-2-git-send-email-prabhakar.csengg@gmail.com>
Message-ID: <51640004.6020604@ti.com>

On 4/8/2013 2:47 PM, Prabhakar lad wrote:
> From: Lad, Prabhakar <prabhakar.csengg at gmail.com>
> 
> Create platform devices for various video modules like venc,osd,
> vpbe and v4l2 driver for dm365.
> 
> Signed-off-by: Lad, Prabhakar <prabhakar.csengg at gmail.com>
> Acked-by: Sekhar Nori <nsekhar at ti.com>
> ---

> diff --git a/arch/arm/mach-davinci/davinci.h b/arch/arm/mach-davinci/davinci.h
> index 12d544b..a9de512 100644
> --- a/arch/arm/mach-davinci/davinci.h
> +++ b/arch/arm/mach-davinci/davinci.h
> @@ -36,8 +36,13 @@
>  #include <media/davinci/vpbe_osd.h>
>  
>  #define DAVINCI_SYSTEM_MODULE_BASE	0x01c40000
> +#define SYSMOD_VDAC_CONFIG		0x2c
>  #define SYSMOD_VIDCLKCTL		0x38
>  #define SYSMOD_VPSS_CLKCTL		0x44
> +#define VPSS_VENCCLKEN_ENABLE		BIT(3)
> +#define VPSS_DACCLKEN_ENABLE		BIT(4)
> +#define VPSS_PLLC2SYSCLK5_ENABLE	BIT(5)
> +

Prabhakar, I noticed it only after I applied these patches, but these
bit definitions in between list of register offsets is distracting. Can
you please move them down after the register offsets when you send the
pull request? You can add a comment /* VPSS CLKCTL bit definitions */
before you start the bit definitions.

>  #define SYSMOD_VDD3P3VPWDN		0x48
>  #define SYSMOD_VSCLKDIS			0x6c
>  #define SYSMOD_PUPDCTL1			0x7c

Thanks,
Sekhar


From shawn.guo at linaro.org  Tue Apr  9 07:50:20 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 9 Apr 2013 19:50:20 +0800
Subject: [PATCH] ARM i.MX6: Fix ldb_di clock selection
In-Reply-To: <20130405092948.GF2667@S2101-09.ap.freescale.net>
References: <1365084209-27240-1-git-send-email-dirk.behme@de.bosch.com>
 <20130405092948.GF2667@S2101-09.ap.freescale.net>
Message-ID: <20130409115018.GH5047@S2101-09.ap.freescale.net>

On Fri, Apr 05, 2013 at 05:29:50PM +0800, Shawn Guo wrote:
> Arnd, Olof,
> 
> Please help apply this as a fix for 3.9.
> 
I will send a new pull request which includes this fix.

Shawn

> On Thu, Apr 04, 2013 at 04:03:29PM +0200, Dirk Behme wrote:
> > According to the recent i.MX6 Quad technical reference manual, mode 0x4 (100b)
> > of the CCM_CS2DCR register (address 0x020C402C) bits [11-9] and [14-12] select
> > the PLL3 clock, and not the PLL3 PFD1 540M clock. In our code, the PLL3 root
> > clock is named 'pll3_usb_otg', select this instead of the 540M clock.
> > 
> > Signed-off-by: Dirk Behme <dirk.behme at de.bosch.com>
> 
> Cc: <stable at vger.kernel.org>
> 
> Acked-by: Shawn Guo <shawn.guo at linaro.org>
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel



From arnd at arndb.de  Tue Apr  9 07:51:13 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 9 Apr 2013 13:51:13 +0200
Subject: [GIT PULL 3/3] DaVinci board updates for v3.10
In-Reply-To: <1365156017-12149-3-git-send-email-nsekhar@ti.com>
References: <1365156017-12149-1-git-send-email-nsekhar@ti.com>
 <1365156017-12149-3-git-send-email-nsekhar@ti.com>
Message-ID: <201304091351.13773.arnd@arndb.de>

On Friday 05 April 2013, Sekhar Nori wrote:
> The following changes since commit a937536b868b8369b98967929045f1df54234323:
> 
>   Linux 3.9-rc3 (2013-03-17 15:59:32 -0700)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-for-v3.10/board
> 
> for you to fetch changes up to a0a56db9771f57667daff41cfa2546dad1abe6d9:
> 
>   ARM: davinci: use is IS_ENABLED macro (2013-04-02 15:31:15 +0530)
> 
> ----------------------------------------------------------------
> v3.10 board updates for DaVinci
> 
> This pull request enables CGROUPS in defconfig and also
> cleans up mach-davinci to use IS_ENABLED() macro.

Pulled into next/boards branch, thanks!

	Arnd


From prabhakar.csengg at gmail.com  Tue Apr  9 07:51:07 2013
From: prabhakar.csengg at gmail.com (Prabhakar Lad)
Date: Tue, 9 Apr 2013 17:21:07 +0530
Subject: [PATCH v9 1/2] ARM: davinci: dm365: add support for v4l2 video
 display
In-Reply-To: <51640004.6020604@ti.com>
References: <1365412636-3468-1-git-send-email-prabhakar.csengg@gmail.com>
 <1365412636-3468-2-git-send-email-prabhakar.csengg@gmail.com>
 <51640004.6020604@ti.com>
Message-ID: <CA+V-a8tRuMdauvpjj0ekUsGZgvJhgJbnA-tjgOYgR1Eg09zRLg@mail.gmail.com>

Sekhar,

On Tue, Apr 9, 2013 at 5:18 PM, Sekhar Nori <nsekhar at ti.com> wrote:
> On 4/8/2013 2:47 PM, Prabhakar lad wrote:
>> From: Lad, Prabhakar <prabhakar.csengg at gmail.com>
>>
>> Create platform devices for various video modules like venc,osd,
>> vpbe and v4l2 driver for dm365.
>>
>> Signed-off-by: Lad, Prabhakar <prabhakar.csengg at gmail.com>
>> Acked-by: Sekhar Nori <nsekhar at ti.com>
>> ---
>
>> diff --git a/arch/arm/mach-davinci/davinci.h b/arch/arm/mach-davinci/davinci.h
>> index 12d544b..a9de512 100644
>> --- a/arch/arm/mach-davinci/davinci.h
>> +++ b/arch/arm/mach-davinci/davinci.h
>> @@ -36,8 +36,13 @@
>>  #include <media/davinci/vpbe_osd.h>
>>
>>  #define DAVINCI_SYSTEM_MODULE_BASE   0x01c40000
>> +#define SYSMOD_VDAC_CONFIG           0x2c
>>  #define SYSMOD_VIDCLKCTL             0x38
>>  #define SYSMOD_VPSS_CLKCTL           0x44
>> +#define VPSS_VENCCLKEN_ENABLE                BIT(3)
>> +#define VPSS_DACCLKEN_ENABLE         BIT(4)
>> +#define VPSS_PLLC2SYSCLK5_ENABLE     BIT(5)
>> +
>
> Prabhakar, I noticed it only after I applied these patches, but these
> bit definitions in between list of register offsets is distracting. Can
> you please move them down after the register offsets when you send the
> pull request? You can add a comment /* VPSS CLKCTL bit definitions */
> before you start the bit definitions.
>
OK, I'll fix it while issuing the pull request.

Regards,
--Prabhakar

>>  #define SYSMOD_VDD3P3VPWDN           0x48
>>  #define SYSMOD_VSCLKDIS                      0x6c
>>  #define SYSMOD_PUPDCTL1                      0x7c
>
> Thanks,
> Sekhar


From shawn.guo at linaro.org  Tue Apr  9 07:51:57 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 9 Apr 2013 19:51:57 +0800
Subject: [GIT PULL] imx fixes for 3.9, take 5
In-Reply-To: <20130403034023.GN24039@S2101-09.ap.freescale.net>
References: <20130402134627.GF24039@S2101-09.ap.freescale.net>
 <20130403031511.GB27874@quad.lixom.net>
 <20130403034023.GN24039@S2101-09.ap.freescale.net>
Message-ID: <20130409115154.GI5047@S2101-09.ap.freescale.net>

On Wed, Apr 03, 2013 at 11:40:26AM +0800, Shawn Guo wrote:
> > So, please resend with just the two clock fixes, as long as they are indeed
> > regressions for something that used to work. Or I can just cherry-pick them
> > over if you prefer.
> 
> Please just cherry-pick them, thanks.
> 
I will resend the pull request which includes these 2 clock fixes.

Shawn



From shawn.guo at linaro.org  Tue Apr  9 07:53:26 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 9 Apr 2013 19:53:26 +0800
Subject: [PATCH] ARM: imx: provide twd clock lookup from device tree
In-Reply-To: <1365004963-27957-1-git-send-email-shawn.guo@linaro.org>
References: <1365004963-27957-1-git-send-email-shawn.guo@linaro.org>
Message-ID: <20130409115324.GJ5047@S2101-09.ap.freescale.net>

On Thu, Apr 04, 2013 at 12:02:43AM +0800, Shawn Guo wrote:
> While booting from device tree, imx6q used to provide twd clock lookup
> by calling clk_register_clkdev() in clock driver.  However, the commit
> bd60345 (ARM: use device tree to get smp_twd clock) forces DT boot to
> look up the clock from device tree.  It causes the failure below when
> twd driver tries to get the clock, and hence kernel has to calibrate the
> local timer frequency.
> 
>  smp_twd: clock not found -2
>  ...
>  Calibrating local timer... 396.13MHz.
> 
> Fix the regression by providing twd clock lookup from device tree, and
> remove the unused twd clk_register_clkdev() call from clock driver.
> 
> Signed-off-by: Shawn Guo <shawn.guo at linaro.org>
> ---
> Arnd, Olof,
> 
> This is a fix for 3.9.

I will have this included in the pull request that is to be sent.

Shawn



From shawn.guo at linaro.org  Tue Apr  9 07:56:16 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 9 Apr 2013 19:56:16 +0800
Subject: [GIT PULL] mxs fixes for 3.9, take 4
In-Reply-To: <201304081749.27633.arnd@arndb.de>
References: <20130403125620.GA21790@S2101-09.ap.freescale.net>
 <201304081749.27633.arnd@arndb.de>
Message-ID: <20130409115614.GE5044@S2101-09.ap.freescale.net>

On Mon, Apr 08, 2013 at 05:49:27PM +0200, Arnd Bergmann wrote:
> On Wednesday 03 April 2013, Shawn Guo wrote:
> > The following changes since commit 07961ac7c0ee8b546658717034fe692fd12eefa9:
> > 
> >   Linux 3.9-rc5 (2013-03-31 15:12:43 -0700)
> > 
> > are available in the git repository at:
> > 
> >   git://git.linaro.org/people/shawnguo/linux-2.6.git tags/mxs-fixes-3.9-4
> > 
> > for you to fetch changes up to 55985e15b80beb339d3e332f00a26003deff14e6:
> > 
> >   ARM: mxs: Slow down the I2C clock speed (2013-04-03 09:34:01 +0800)
> 
> Pulled into fixes branch. I'll send it out in the next few days, waiting
> for more to come in right now, as there are only two patches in the branch
> at the moment.

I had a few IMX fixes patches waiting for you and Olof to apply since
last week.  To ease you guys a little bit, I will include all these
patches in a pull request that is to be sent in a few minutes.

Shawn



From shawn.guo at linaro.org  Tue Apr  9 07:57:46 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 9 Apr 2013 19:57:46 +0800
Subject: [PATCH v2 0/3] Get rid of big array from imx pinctrl driver
In-Reply-To: <CACRpkdZL084APsYD_g44Yxx5fWC-8e6bvS6xKpr_2YrXDMhwZQ@mail.gmail.com>
References: <1361533888-18073-1-git-send-email-shawn.guo@linaro.org>
 <CAOMZO5D1+baoM0vMdPW9bAd4DX8C82BF9H87igFNo78+8D_N3Q@mail.gmail.com>
 <20130407071028.GD11898@S2101-09.ap.freescale.net>
 <CAOMZO5Bxfj9ZGrVOcNirsVHFLWaHWBdkFpKSiVQ9iS4paT0Y6g@mail.gmail.com>
 <20130407142610.GE11898@S2101-09.ap.freescale.net>
 <CAOMZO5A-nwmb=6G-D_2LBNsPYH4C8Z686BjS3vd3WhzvnDFfqw@mail.gmail.com>
 <20130408060857.GA5047@S2101-09.ap.freescale.net>
 <CACRpkdZL084APsYD_g44Yxx5fWC-8e6bvS6xKpr_2YrXDMhwZQ@mail.gmail.com>
Message-ID: <20130409115744.GF5044@S2101-09.ap.freescale.net>

On Tue, Apr 09, 2013 at 10:36:59AM +0200, Linus Walleij wrote:
> On Mon, Apr 8, 2013 at 8:09 AM, Shawn Guo <shawn.guo at linaro.org> wrote:
> 
> > --8<-----
> >
> > diff --git a/drivers/pinctrl/pinctrl-imx6q.c b/drivers/pinctrl/pinctrl-imx6q.c
> > index f00f532..76dd9c4 100644
> > --- a/drivers/pinctrl/pinctrl-imx6q.c
> > +++ b/drivers/pinctrl/pinctrl-imx6q.c
> 
> Acked-by. I trust you to fix up and merge the outcome of this Shawn...

Thanks, Linus.  Thanks to Fabio too for noticing the bugs.

Shawn



From lee.jones at linaro.org  Tue Apr  9 07:58:23 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Tue, 9 Apr 2013 12:58:23 +0100
Subject: [PATCH 2/2] mfd: db8500-prcmu: Support platform dependant device
 selection
In-Reply-To: <1365071941-23475-2-git-send-email-lee.jones@linaro.org>
References: <1365071941-23475-1-git-send-email-lee.jones@linaro.org>
 <1365071941-23475-2-git-send-email-lee.jones@linaro.org>
Message-ID: <20130409115823.GD25316@gmail.com>

On Thu, 04 Apr 2013, Lee Jones wrote:

> The main aim for this cycle is to have the u8540 booting to a
> console. However, the u8540 doesn't support all of the u8500
> platform devices yet. After this stage is complete we can then
> fill in the inadequacies, such as specific clock support at a
> later date. To achieve this we're placing devices supported by
> all platforms into a common device structure and the remaining
> ones into a platform specific one.
> 
> Cc: Samuel Ortiz <sameo at linux.intel.com>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>
> ---
>  drivers/mfd/db8500-prcmu.c |   52 ++++++++++++++++++++++++++++----------------
>  1 file changed, 33 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/mfd/db8500-prcmu.c b/drivers/mfd/db8500-prcmu.c
> index 1c4edbf8..dec94d0 100644
> --- a/drivers/mfd/db8500-prcmu.c
> +++ b/drivers/mfd/db8500-prcmu.c
> @@ -24,6 +24,7 @@
>  #include <linux/jiffies.h>
>  #include <linux/bitops.h>
>  #include <linux/fs.h>
> +#include <linux/of.h>
>  #include <linux/platform_device.h>
>  #include <linux/uaccess.h>
>  #include <linux/irqchip/arm-gic.h>
> @@ -3107,19 +3108,7 @@ static struct ux500_wdt_data db8500_wdt_pdata = {
>  	.has_28_bits_resolution = true,
>  };
>  
> -static struct mfd_cell db8500_prcmu_devs[] = {
> -	{
> -		.name = "db8500-prcmu-regulators",
> -		.of_compatible = "stericsson,db8500-prcmu-regulator",
> -		.platform_data = &db8500_regulators,
> -		.pdata_size = sizeof(db8500_regulators),
> -	},
> -	{
> -		.name = "cpufreq-ux500",
> -		.of_compatible = "stericsson,cpufreq-ux500",
> -		.platform_data = &db8500_cpufreq_table,
> -		.pdata_size = sizeof(db8500_cpufreq_table),
> -	},
> +static struct mfd_cell common_prcmu_devs[] = {
>  	{
>  		.name = "ux500_wdt",
>  		.platform_data = &db8500_wdt_pdata,
> @@ -3135,6 +3124,21 @@ static struct mfd_cell db8500_prcmu_devs[] = {
>  	},
>  };
>  
> +static struct mfd_cell db8500_prcmu_devs[] = {
> +	{
> +		.name = "db8500-prcmu-regulators",
> +		.of_compatible = "stericsson,db8500-prcmu-regulator",
> +		.platform_data = &db8500_regulators,
> +		.pdata_size = sizeof(db8500_regulators),
> +	},
> +	{
> +		.name = "cpufreq-ux500",
> +		.of_compatible = "stericsson,cpufreq-ux500",
> +		.platform_data = &db8500_cpufreq_table,
> +		.pdata_size = sizeof(db8500_cpufreq_table),
> +	},
> +};
> +
>  static void db8500_prcmu_update_cpufreq(void)
>  {
>  	if (prcmu_has_arm_maxopp()) {
> @@ -3184,10 +3188,10 @@ static int db8500_prcmu_probe(struct platform_device *pdev)
>  
>  	db8500_irq_init(np);
>  
> -	for (i = 0; i < ARRAY_SIZE(db8500_prcmu_devs); i++) {
> -		if (!strcmp(db8500_prcmu_devs[i].name, "ab8500-core")) {
> -			db8500_prcmu_devs[i].platform_data = pdata->ab_platdata;
> -			db8500_prcmu_devs[i].pdata_size = sizeof(struct ab8500_platform_data);
> +	for (i = 0; i < ARRAY_SIZE(common_prcmu_devs); i++) {
> +		if (!strcmp(common_prcmu_devs[i].name, "ab8500-core")) {
> +			common_prcmu_devs[i].platform_data = pdata->ab_platdata;
> +			common_prcmu_devs[i].pdata_size = sizeof(struct ab8500_platform_data);
>  		}
>  	}
>  
> @@ -3195,13 +3199,23 @@ static int db8500_prcmu_probe(struct platform_device *pdev)
>  
>  	db8500_prcmu_update_cpufreq();
>  
> -	err = mfd_add_devices(&pdev->dev, 0, db8500_prcmu_devs,
> -			      ARRAY_SIZE(db8500_prcmu_devs), NULL, 0, NULL);
> +	err = mfd_add_devices(&pdev->dev, 0, common_prcmu_devs,
> +			      ARRAY_SIZE(common_prcmu_devs), NULL, 0, NULL);
>  	if (err) {
>  		pr_err("prcmu: Failed to add subdevices\n");
>  		return err;
>  	}
>  
> +	/* TODO: Remove restriction when clk definitions are available. */
> +	if (!of_machine_is_compatible("st-ericsson,u8540")) {
> +		err = mfd_add_devices(&pdev->dev, 0, db8500_prcmu_devs,
> +				      ARRAY_SIZE(db8500_prcmu_devs), NULL, 0, NULL);
> +		if (err) {
> +			pr_err("prcmu: Failed to add subdevices\n");
> +			return err;
> +		}
> +	}
> +
>  	pr_info("DB8500 PRCMU initialized\n");
>  
>  no_irq_return:

Did you see this one Sam?

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From linus.walleij at linaro.org  Tue Apr  9 07:58:45 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Tue, 9 Apr 2013 13:58:45 +0200
Subject: [RFC PATCH arm: initial TI-Nspire support]
In-Reply-To: <EE94A8F2-2BC2-446E-B0B2-1E1803E240F2@gmail.com>
References: <6FE4B33E-A503-4A75-AEED-831CB2C06D83@gmail.com>
 <CACRpkdbuAvRzVdzKL51k5d7vVpGNUHh_f_ZAxP4m3zFdBOV=xw@mail.gmail.com>
 <EE94A8F2-2BC2-446E-B0B2-1E1803E240F2@gmail.com>
Message-ID: <CACRpkdaFS=ZM6dTtD3ziBTfVJzwOU2x8gfyYutogkYL8LEo8qQ@mail.gmail.com>

On Tue, Apr 9, 2013 at 1:39 PM, Daniel Tang <dt.tangr at gmail.com> wrote:

>>> +union reg_clk_speed {
>>> +       unsigned long raw;
>>> +       struct {
>>> +               unsigned long __padding0:1;
>>> +               unsigned long base_cpu_ratio:7;
>>> +               unsigned long is_base_27mhz:1;
>>> +               unsigned long __padding1:3;
>>> +               unsigned long cpu_ahb_ratio:3;
>>> +               unsigned long __padding2:1;
>>> +               unsigned long base_val:5;
>>> +       } val;
>>> +};
>>
>> Usually to try to fit a struct over a register range is not such a good
>> idea in Linux.
>>
>> Instead define abstract representations of what you want to do
>> (remove everything named "padding" above, use proper data types instead
>> of these unsigned longs and that complex union) then use offsets to
>> registers and remap the base offset in memory.
>>
>> It makes for simpler debugging and ability to properly use read|write[lwb]
>> macros.
>
> The structure is actually a bitfield. We'd readl() the raw unsigned long into the 'raw' field and then access the data via the 'val' structure.
>
> Should we be using bitmasks and bitshifting to get at those values instead?

I personally think that is better because it avoids complex structures
and strange helper functions.

When it really shows it's ugly face is when you get a second generation
of the hardware that have some other bits in slightly different places,
and you have to create another struct to map a small difference instead
of being able to just tweak the code slightly.

>> Not only should this be done from devicetree, but exactly which
>> synaptics driver are you using with this?
>>
>> I don't think there is one in the kernel tree yet.
>>
>
> It's this one here http://lxr.free-electrons.com/source/drivers/input/mouse/synaptics_i2c.c

Aha I thought it was one of those modern RMI4 things.
OK then...

> Also, how would you like us to submit updates? Should we continue posting updated patches as replies to this thread?

Just repost it somehow, include relevant people on To/Cc. No need
to use the same thread I think?

Yours,
Linus Walleij


From sergei.shtylyov at cogentembedded.com  Tue Apr  9 08:00:15 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Tue, 09 Apr 2013 16:00:15 +0400
Subject: [PATCH 0/8] Reorganize R8A7779/Marzen USB code
In-Reply-To: <87vc81ka6k.wl%kuninori.morimoto.gx@renesas.com>
References: <201304050251.44464.sergei.shtylyov@cogentembedded.com>
 <87vc81ka6k.wl%kuninori.morimoto.gx@renesas.com>
Message-ID: <516402CF.3060503@cogentembedded.com>

Hello.

On 05-04-2013 6:01, Kuninori Morimoto wrote:

>>     Here's the set of 4 patches against the Simon Horman's 'renesas.git' repo,
>> 'renesas-next-20130404v2' tag and the 2 Ether patches I've reposted yesterday.
>> It was created to fix the shortcomings in the R8A7779/Marzen USB platform code
>> and R8A7779 USB common PHY driver, and so spans both arch/arm/mach-shmobile/
>> and drivers/usb/ subtrees (some patches have to touch both subtrees).
>> The patches were conceived with the complete bisectability goal in mind.

>> [1/8] ARM: shmobile:Marzen: move USB EHCI, OHCI, and PHY devices to R8A7779 code
>> [2/8] ehci-platform: add init() method to platform data
>> [3/8] ARM: shmobile: R8A7779: setup EHCI internal buffer
>> [4/8] rcar-phy: remove EHCI internal buffer setup
>> [5/8] rcar-phy: correct base address
>> [6/8] rcar-phy: add platform data
>> [7/8] ARM: shmobile: Marzen: pass platform data to USB PHY device
>> [8/8] rcar-phy: handle platform data

>>     I'm not sure thru which tree this patchset should be merged, however it turns
>> out that it's too late now to push it thru Felipe Balbi's USB tree for 3.10, so
>> maybe the patchset can be merged thru Simon's tree with Felipe's and Alan
>> Stern's ACKs.

> I guess you already got request about patch style from Simon.
> When you send v2 patch, could you please add "this patch is tested on xxxx bard"
> on each patch's comment area ?

    I thought adding it to each patch (BTW, I didn't get what you meant: 
changelog or the area below ---) was a bit too much and just mentioned it in 
the cover letter.

> Then,
> for all patches

> Acked-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>

    Sorry, I forgot to add this. If you still want it, I'll add it to version 
3 that will be posted today.

> Best regards
> ---
> Kuninori Morimoto

WBR, Sergei



From pawel.moll at arm.com  Tue Apr  9 08:01:56 2013
From: pawel.moll at arm.com (Pawel Moll)
Date: Tue, 09 Apr 2013 13:01:56 +0100
Subject: [RFC PATCH arm: initial TI-Nspire support]
In-Reply-To: <CACRpkda9Nue-8Esp3cJ6u2-MJ2ZL8hH-2BnrhHwWv4GZP2VR5w@mail.gmail.com>
References: <6FE4B33E-A503-4A75-AEED-831CB2C06D83@gmail.com>
 <4B3FD561-84FC-40CD-B747-13851692D673@gmail.com>
 <521DFDFC-7E9E-47EA-ACDA-C91BBDC8454E@gmail.com>
 <201304072323.42173.arnd@arndb.de>
 <CACRpkda9Nue-8Esp3cJ6u2-MJ2ZL8hH-2BnrhHwWv4GZP2VR5w@mail.gmail.com>
Message-ID: <1365508916.24306.17.camel@hornet>

On Tue, 2013-04-09 at 12:23 +0100, Linus Walleij wrote:
> On Sun, Apr 7, 2013 at 11:23 PM, Arnd Bergmann <arnd at arndb.de> wrote:
> > On Sunday 07 April 2013, Daniel Tang wrote:
> >> Here's an updated patch that enables support for the LCD.
> >>
> >> I looked into drivers/video/of_display_timing.c but it doesn't have the fields to describe the
> >> PL11x specific options needed in struct clcd_panel. At the moment, it is implemented by
> >> hardcoding the values in the kernel and using the device tree to select the correct
> >> configuration.
> >>
> >> Signed-off-by: Daniel Tang <dt.tangr at gmail.com>
> >
> > I think you should for now keep the clcd stuff in a separate file,
> > since it will be replaced with DT logic eventually. For now, the
> > auxdata method is ok, but Linus Walleij might already have thought
> > about how pl111 should get all its data from the device tree.
> 
> So last thing I heard there was *someone* at ARM working on
> device tree support for the PL110/PL111, so I just don't know who
> this was.
> 
> But I bet Pawel knows, because it will be needed for all
> ARM reference designs.

So I have PL111 code almost working here, however today it depends on
not-yet-upstream (to my knowledge) generic/common panel/display
framework. If I'm not disturbed again I may get something done this
week, hopefully removing the dependency.

There's also some work going on on a DRM driver for PL111, but I can't
promise any dates.

As to PL110 I have no idea how different is it from the PL111, but
nothing is happening about it anyway.

Pawe?




From linus.walleij at linaro.org  Tue Apr  9 08:05:28 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Tue, 9 Apr 2013 14:05:28 +0200
Subject: [RFC PATCH arm: initial TI-Nspire support]
In-Reply-To: <1365508916.24306.17.camel@hornet>
References: <6FE4B33E-A503-4A75-AEED-831CB2C06D83@gmail.com>
 <4B3FD561-84FC-40CD-B747-13851692D673@gmail.com>
 <521DFDFC-7E9E-47EA-ACDA-C91BBDC8454E@gmail.com>
 <201304072323.42173.arnd@arndb.de>
 <CACRpkda9Nue-8Esp3cJ6u2-MJ2ZL8hH-2BnrhHwWv4GZP2VR5w@mail.gmail.com>
 <1365508916.24306.17.camel@hornet>
Message-ID: <CACRpkdZhtoe+CATjsHFxWgcZTEfGZr01kSObXpAp8WRFjMxiOg@mail.gmail.com>

On Tue, Apr 9, 2013 at 2:01 PM, Pawel Moll <pawel.moll at arm.com> wrote:

> As to PL110 I have no idea how different is it from the PL111, but
> nothing is happening about it anyway.

I have that on my Integrator/CP (in working condition!) so I will
be able to test it as it arrives, but basically I think the panel
model will be the same.

Yours,
Linus Walleij


From s.nawrocki at samsung.com  Tue Apr  9 08:09:34 2013
From: s.nawrocki at samsung.com (Sylwester Nawrocki)
Date: Tue, 09 Apr 2013 14:09:34 +0200
Subject: [GIT PULL 10/10] devel-samsung for v3.10
In-Reply-To: <2f2f01ce3514$33d10f00$9b732d00$%kim@samsung.com>
References: <51630A55.6030703@samsung.com> <51632451.3050801@gmail.com>
 <2f2f01ce3514$33d10f00$9b732d00$%kim@samsung.com>
Message-ID: <516404FE.4000907@samsung.com>

On 04/09/2013 01:20 PM, Kukjin Kim wrote:
> Sylwester Nawrocki wrote:
> 
> [...]
> 
>>> Sylwester Nawrocki (2):
>>> ARM: SAMSUNG: Export MIPI CSIS/DSIM PHY control functions
>>
>> This one was supposed to be a fix for 3.8-rc IIRC. But anyway the whole
> 
> If so, this should be sent to stable 3.8 tree, but I'm not sure this is
> really bug fix.

It prevents build error when MIPI-CSIS driver is build as a loadable module.
That means with some valid kernel configuration the kernel cannot be build.
Hence IMHO it is a bug fix, and sending it to 3.8+ stable indeed seems a
good idea.

>> file this patch touches is going to be removed in 3.11.
>>
> It means it is still needed for v3.10 :-)

Yeah, true. :) Just wanted to note that I have already some RFC patches
for the MIPI CSI-2/DSI DPHY driver using the generic PHY framework.
However this framework is not settled yet, I assume it would be completed
for 3.11.

>>> ARM: S3C24XX: Correct NR_IRQS definition for s3c2440
>>
>> And this one is needed for 3.9, sorry for not mentioning it in the patch's
>> description. Together with [1] it makes my s3c2440 SoC based test board
>> booting again with 3.9-rc6.
>>
>> [1] http://www.spinics.net/lists/arm-kernel/msg236643.html
>>
> OK, let me drop it in this branch.

Thanks!

> Arnd and Olof, please hold on pulling for this branch. I will sort out soon.
> 
> Thanks.
> 
> - Kukjin

Regards,
Sylwester


From prabhakar.csengg at gmail.com  Tue Apr  9 08:14:47 2013
From: prabhakar.csengg at gmail.com (Prabhakar Lad)
Date: Tue, 9 Apr 2013 17:44:47 +0530
Subject: [BUG] mod/file2alias: build error in devicetable-offsets.c [was:
 asm/types.h Header file wont get generated while building uImage ?]
In-Reply-To: <m2ip48d62f.fsf@igel.home>
References: <CA+V-a8vYsBLVH-3Bm35Sv9K9ZMTcMB4_P_V3kBjyuEKDozPi5w@mail.gmail.com>
 <1363949290.3528.37.camel@linaro1.home> <m2ip48d62f.fsf@igel.home>
Message-ID: <CA+V-a8srtwdf1H2JQwbkyMFhXopPEA90RM8Hy+UunM6Mm7-d1w@mail.gmail.com>

Hi Andreas

On Sun, Mar 31, 2013 at 1:16 AM, Andreas Schwab <schwab at linux-m68k.org> wrote:
> "Jon Medhurst (Tixy)" <tixy at linaro.org> writes:
>
>> For builds which succeed I see this order:
>>
>>   WRAP    arch/arm/include/generated/asm/types.h
>>   [...]
>>   GEN     include/generated/asm-offsets.h
>>
>> and for those which fail:
>>
>>   CC      scripts/mod/devicetable-offsets.s
>>   In file included from include/linux/types.h:5:0,
>>                    from include/linux/mod_devicetable.h:11,
>>                    from scripts/mod/devicetable-offsets.c:2:
>>   include/uapi/linux/types.h:4:23: fatal error: asm/types.h: No such file or directory
>>   [...]
>>   WRAP    arch/arm/include/generated/asm/types.h
>
> Does that help?
>
> diff --git a/Makefile b/Makefile
> index a5f3203..2a484db 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -512,7 +512,8 @@ ifeq ($(KBUILD_EXTMOD),)
>  # Carefully list dependencies so we do not try to build scripts twice
>  # in parallel
>  PHONY += scripts
> -scripts: scripts_basic include/config/auto.conf include/config/tristate.conf
> +scripts: scripts_basic include/config/auto.conf include/config/tristate.conf \
> +        asm-generic
>         $(Q)$(MAKE) $(build)=$(@)
>
>  # Objects we will link into vmlinux / subdirs we need to visit
>
Whats the status of it ?

Regards,
--Prabhakar

> Andreas.
>
> --
> Andreas Schwab, schwab at linux-m68k.org
> GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
> "And now for something completely different."


From dave.martin at linaro.org  Tue Apr  9 08:21:45 2013
From: dave.martin at linaro.org (Dave Martin)
Date: Tue, 9 Apr 2013 13:21:45 +0100
Subject: [PATCH v4 2/2] arm: prefer PSCI for SMP bringup
In-Reply-To: <alpine.LFD.2.03.1304021202520.1171@syhkavp.arg>
References: <1364575371-8926-2-git-send-email-stefano.stabellini@eu.citrix.com>
 <alpine.LFD.2.03.1303291320580.1372@syhkavp.arg>
 <alpine.DEB.2.02.1303291735080.4430@kaball.uk.xensource.com>
 <alpine.LFD.2.03.1303291349150.1372@syhkavp.arg>
 <5155EC28.8050608@gmail.com>
 <alpine.DEB.2.02.1304011541010.5078@kaball.uk.xensource.com>
 <alpine.LFD.2.03.1304011412030.1171@syhkavp.arg>
 <alpine.DEB.2.02.1304021522230.5078@kaball.uk.xensource.com>
 <alpine.LFD.2.03.1304021202520.1171@syhkavp.arg>
Message-ID: <20130409122133.GA2233@linaro.org>

On Tue, Apr 02, 2013 at 12:11:25PM -0400, Nicolas Pitre wrote:
> On Tue, 2 Apr 2013, Stefano Stabellini wrote:
> 
> > On Mon, 1 Apr 2013, Nicolas Pitre wrote:
> > > On Mon, 1 Apr 2013, Stefano Stabellini wrote:
> > > > What are the platforms that are going to use smp_init? Do we know how do
> > > > they intend to use it?
> > > 
> > > VExpress for one.  When booting on a big.LITTLE system such as TC2 on 
> > > VExpress, the MCPM layer needs to arbitrate power management operations 
> > > on a per cluster basis.  In that case there is a MCPM specific set of 
> > > SMP ops to be used, even if it may end up calling into PSCI.
> > > 
> > > But the important point is that we don't know beforehand what to use, 
> > > especially with a kernel that can boot on multiple different VExpress 
> > > configurations.  The decision has to be made at run time, and therefore 
> > > a static default or mdesc->smp ops doesn't cut it.
> > 
> > I certainly like the principle and I am in favor of anything that moves
> > the decisions at runtime. I have pulled the patch in the series, it's
> > going to be in the next version.
> > 
> > However I am concerned that these platform specific operations won't
> > work with Xen at all.
> > I am getting increasingly certain that we need a Xen specific check in
> > setup_arch to bump up of the priority of PSCI over anything else if Xen
> > is running. 
> 
> I'm concerned about mixing big.LITTLE and Xen as well.  I don't think 
> this is going to make an easy match.  KVM might have an easier fit here.
> 
> But, in any case, even if the MCPM layer gets involved, if Xen is there 
> then PSCI will end up being the ultimate interface anyway.

Note that big.LITTLE != MCPM.  Virtualisation hosts might be large multi-
cluster systems, but the CPUs might be all of the same type.  MCPM or
similar would me needed for the multi-cluster power management even
though there is no big.LITTLE mix of CPUs.

> But let's cross that bridge when we get to it.  For now this is still a 
> non existing problem.

That's a big open question.  Either the host or hypervisor needs to be
very clever about scheduling guests, or you need to bind each guest virtual
CPU to a specific class of physical CPUs -- so, for example you provide
a guest with an explicit mix of bigs and littles.

All we can say about that for now is that it's a potential research area...

Cheers
---Dave


From u.kleine-koenig at pengutronix.de  Tue Apr  9 08:23:13 2013
From: u.kleine-koenig at pengutronix.de (Uwe =?iso-8859-1?Q?Kleine-K=F6nig?=)
Date: Tue, 9 Apr 2013 14:23:13 +0200
Subject: [PATCH] i2c: s3c2410: Add SMBus emulation for block read
In-Reply-To: <1364308196-10101-1-git-send-email-prasanna.ps@samsung.com>
References: <1364308196-10101-1-git-send-email-prasanna.ps@samsung.com>
Message-ID: <20130409122313.GD4913@pengutronix.de>

Hello,

On Tue, Mar 26, 2013 at 07:59:56PM +0530, Prasanna Kumar wrote:
> diff --git a/drivers/i2c/busses/i2c-s3c2410.c b/drivers/i2c/busses/i2c-s3c2410.c
> index 17c5c37..e4ab9ea 100644
> --- a/drivers/i2c/busses/i2c-s3c2410.c
> +++ b/drivers/i2c/busses/i2c-s3c2410.c
> @@ -309,6 +309,12 @@ static inline int is_lastmsg(struct s3c24xx_i2c *i2c)
>  
>  static inline int is_msglast(struct s3c24xx_i2c *i2c)
>  {
> +	/* msg->len is always 1 for the first byte of smbus block read.
> +	 * Actual length will be read from slave. More bytes will be
> +	 * read according to the length then. */
> +	if (i2c->msg->flags & I2C_M_RECV_LEN && i2c->msg->len == 1)
> +		return 0;
> +
>  	return i2c->msg_ptr == i2c->msg->len-1;
>  }
>  
> @@ -448,6 +454,9 @@ static int i2c_s3c_irq_nextbyte(struct s3c24xx_i2c *i2c, unsigned long iicstat)
>  		byte = readb(i2c->regs + S3C2410_IICDS);
>  		i2c->msg->buf[i2c->msg_ptr++] = byte;
>  
> +		/* Add actual length to read for smbus block read */
> +		if (i2c->msg->flags & I2C_M_RECV_LEN && i2c->msg->len == 1)
> +			i2c->msg->len += byte;
>   prepare_read:
>  		if (is_msglast(i2c)) {
I don't know if that can happen, but if the block has length 0 (that is,
only consists of a single byte that is read as 0) the is_msglast() test
returns 0 which might be wrong. Maybe even if it cannot regularily
happen handle it in a sane way?

Also I wonder if error checking for byte > I2C_SMBUS_BLOCK_MAX would be
needed to prevent a buffer overrun?

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |


From shawn.guo at linaro.org  Tue Apr  9 08:24:37 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 9 Apr 2013 20:24:37 +0800
Subject: [GIT PULL v2] imx fixes for 3.9, take 5
Message-ID: <20130409122435.GK5047@S2101-09.ap.freescale.net>

Changes since v1:
 * Drop patch "cpuimx27 and mbimx27: prepend CONFIG_ to Kconfig macro"
   which is queued for 3.10 now.
 * Add patches "ARM i.MX6: Fix ldb_di clock selection" and "ARM: imx:
   provide twd clock lookup from device tree"

The following changes since commit 31880c37c11e28cb81c70757e38392b42e695dc6:

  Linux 3.9-rc6 (2013-04-07 20:49:54 -0700)

are available in the git repository at:

  git://git.linaro.org/people/shawnguo/linux-2.6.git tags/imx-fixes-3.9-5

for you to fetch changes up to e8094b2c17126c7dfdeafa296f206a4a3b122d23:

  ARM i.MX6: Fix ldb_di clock selection (2013-04-09 19:48:09 +0800)

----------------------------------------------------------------
The imx fixes for 3.9, take 5:

* A couple imx35 clock fixes for regressions caused by common clock
  framework conversion.  The admux and iomux get disabled by common
  clock framework late initcall, and hence causes problems.
* Add missing twd clock lookup in device tree.  This becomes required
  since commit bd60345 (ARM: use device tree to get smp_twd clock)
  forces all DT boot to find lookup from device tree.
* Fix imx6q ldb_di clock parents mismatch per reference manual.

----------------------------------------------------------------
Dirk Behme (1):
      ARM i.MX6: Fix ldb_di clock selection

Markus Pargmann (2):
      ARM: clk-imx35: Bugfix iomux clock
      ARM: imx35 Bugfix admux clock

Shawn Guo (1):
      ARM: imx: provide twd clock lookup from device tree

 arch/arm/boot/dts/imx6qdl.dtsi |    1 +
 arch/arm/mach-imx/clk-imx35.c  |    2 ++
 arch/arm/mach-imx/clk-imx6q.c  |    3 +--
 3 files changed, 4 insertions(+), 2 deletions(-)



From prakash.pm at ti.com  Tue Apr  9 08:27:57 2013
From: prakash.pm at ti.com (Manjunathappa, Prakash)
Date: Tue, 9 Apr 2013 17:57:57 +0530
Subject: [PATCH 0/4] ARM: davinci: fix UART clock enabling
Message-ID: <1365510481-32129-1-git-send-email-prakash.pm@ti.com>

Patch series addresses below issues:
1) Do clk_get on dev_id when there is single clock for a module
2) Fix garbled UART log with DT kernel on da850-evm.

Applies on top of v3.9-rc9 of Linus's.
Tested on da850-evm. Able to see proper bootup log and console on UART2.

Manjunathappa, Prakash (4):
  ARM: davinci: uart: move to devid based clk_get
  ARM: davinci: da850: override device name of UART in DT kernel
  ARM: davinci: da850: do not specify clock_frequency for UART DT node
  ARM: davinci: da8xx: remove da8xx_uart_clk_enable

 arch/arm/boot/dts/da850.dtsi                   |    3 -
 arch/arm/mach-davinci/da830.c                  |    8 ++--
 arch/arm/mach-davinci/da850.c                  |    8 ++--
 arch/arm/mach-davinci/da8xx-dt.c               |   11 +----
 arch/arm/mach-davinci/devices-da8xx.c          |   40 ++++++++++++++++---
 arch/arm/mach-davinci/devices-tnetv107x.c      |   35 ++++++++++++++---
 arch/arm/mach-davinci/dm355.c                  |   48 ++++++++++++++++++-----
 arch/arm/mach-davinci/dm365.c                  |   35 ++++++++++++----
 arch/arm/mach-davinci/dm644x.c                 |   48 ++++++++++++++++++-----
 arch/arm/mach-davinci/dm646x.c                 |   49 +++++++++++++++++++-----
 arch/arm/mach-davinci/include/mach/da8xx.h     |    2 +-
 arch/arm/mach-davinci/include/mach/tnetv107x.h |    2 +-
 arch/arm/mach-davinci/serial.c                 |   19 ++++++---
 arch/arm/mach-davinci/tnetv107x.c              |    8 ++--
 14 files changed, 233 insertions(+), 83 deletions(-)

-- 
1.7.4.1



From prakash.pm at ti.com  Tue Apr  9 08:31:01 2013
From: prakash.pm at ti.com (Manjunathappa, Prakash)
Date: Tue, 9 Apr 2013 18:01:01 +0530
Subject: [PATCH 1/4] ARM: davinci: uart: move to dev_id based clk_get
In-Reply-To: <1365510481-32129-1-git-send-email-prakash.pm@ti.com>
References: <1365510481-32129-1-git-send-email-prakash.pm@ti.com>
Message-ID: <1365510664-1394-2-git-send-email-prakash.pm@ti.com>

For modules having single clock, clk_get should be done with dev_id.
But current davinci implementation handles multiple instances
of the UART devices with single platform_device_register. Hence clk_get
is based on con_id rather than dev_id, this is not correct. Do
platform_device_register for each instance and clk_get on dev_id.

Signed-off-by: Manjunathappa, Prakash <prakash.pm at ti.com>
---
 arch/arm/mach-davinci/da830.c                  |    8 ++--
 arch/arm/mach-davinci/da850.c                  |    8 ++--
 arch/arm/mach-davinci/devices-da8xx.c          |   40 ++++++++++++++++---
 arch/arm/mach-davinci/devices-tnetv107x.c      |   35 ++++++++++++++---
 arch/arm/mach-davinci/dm355.c                  |   48 ++++++++++++++++++-----
 arch/arm/mach-davinci/dm365.c                  |   35 ++++++++++++----
 arch/arm/mach-davinci/dm644x.c                 |   48 ++++++++++++++++++-----
 arch/arm/mach-davinci/dm646x.c                 |   49 +++++++++++++++++++-----
 arch/arm/mach-davinci/include/mach/da8xx.h     |    2 +-
 arch/arm/mach-davinci/include/mach/tnetv107x.h |    2 +-
 arch/arm/mach-davinci/serial.c                 |   19 ++++++---
 arch/arm/mach-davinci/tnetv107x.c              |    8 ++--
 12 files changed, 230 insertions(+), 72 deletions(-)

diff --git a/arch/arm/mach-davinci/da830.c b/arch/arm/mach-davinci/da830.c
index 678a54a..4a13ac9d 100644
--- a/arch/arm/mach-davinci/da830.c
+++ b/arch/arm/mach-davinci/da830.c
@@ -395,9 +395,9 @@ static struct clk_lookup da830_clks[] = {
 	CLK(NULL,		"tptc0",	&tptc0_clk),
 	CLK(NULL,		"tptc1",	&tptc1_clk),
 	CLK("davinci_mmc.0",	NULL,		&mmcsd_clk),
-	CLK(NULL,		"uart0",	&uart0_clk),
-	CLK(NULL,		"uart1",	&uart1_clk),
-	CLK(NULL,		"uart2",	&uart2_clk),
+	CLK("serial8250.0",	NULL,		&uart0_clk),
+	CLK("serial8250.1",	NULL,		&uart1_clk),
+	CLK("serial8250.2",	NULL,		&uart2_clk),
 	CLK("spi_davinci.0",	NULL,		&spi0_clk),
 	CLK("spi_davinci.1",	NULL,		&spi1_clk),
 	CLK(NULL,		"ecap0",	&ecap0_clk),
@@ -1199,7 +1199,7 @@ static struct davinci_soc_info davinci_soc_info_da830 = {
 	.gpio_base		= DA8XX_GPIO_BASE,
 	.gpio_num		= 128,
 	.gpio_irq		= IRQ_DA8XX_GPIO0,
-	.serial_dev		= &da8xx_serial_device,
+	.serial_dev		= da8xx_serial_device,
 	.emac_pdata		= &da8xx_emac_pdata,
 };
 
diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index 0c4a26d..8c041e4 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -408,9 +408,9 @@ static struct clk_lookup da850_clks[] = {
 	CLK(NULL,		"tpcc1",	&tpcc1_clk),
 	CLK(NULL,		"tptc2",	&tptc2_clk),
 	CLK("pruss_uio",	"pruss",	&pruss_clk),
-	CLK(NULL,		"uart0",	&uart0_clk),
-	CLK(NULL,		"uart1",	&uart1_clk),
-	CLK(NULL,		"uart2",	&uart2_clk),
+	CLK("serial8250.0",	NULL,		&uart0_clk),
+	CLK("serial8250.1",	NULL,		&uart1_clk),
+	CLK("serial8250.2",	NULL,		&uart2_clk),
 	CLK(NULL,		"aintc",	&aintc_clk),
 	CLK(NULL,		"gpio",		&gpio_clk),
 	CLK("i2c_davinci.2",	NULL,		&i2c1_clk),
@@ -1255,7 +1255,7 @@ static struct davinci_soc_info davinci_soc_info_da850 = {
 	.gpio_base		= DA8XX_GPIO_BASE,
 	.gpio_num		= 144,
 	.gpio_irq		= IRQ_DA8XX_GPIO0,
-	.serial_dev		= &da8xx_serial_device,
+	.serial_dev		= da8xx_serial_device,
 	.emac_pdata		= &da8xx_emac_pdata,
 	.sram_dma		= DA8XX_SHARED_RAM_BASE,
 	.sram_len		= SZ_128K,
diff --git a/arch/arm/mach-davinci/devices-da8xx.c b/arch/arm/mach-davinci/devices-da8xx.c
index fc50243..eec7132 100644
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -67,7 +67,7 @@
 void __iomem *da8xx_syscfg0_base;
 void __iomem *da8xx_syscfg1_base;
 
-static struct plat_serial8250_port da8xx_serial_pdata[] = {
+static struct plat_serial8250_port da8xx_serial_pdata0[] = {
 	{
 		.mapbase	= DA8XX_UART0_BASE,
 		.irq		= IRQ_DA8XX_UARTINT0,
@@ -77,6 +77,11 @@ static struct plat_serial8250_port da8xx_serial_pdata[] = {
 		.regshift	= 2,
 	},
 	{
+		.flags	= 0,
+	},
+};
+static struct plat_serial8250_port da8xx_serial_pdata1[] = {
+	{
 		.mapbase	= DA8XX_UART1_BASE,
 		.irq		= IRQ_DA8XX_UARTINT1,
 		.flags		= UPF_BOOT_AUTOCONF | UPF_SKIP_TEST |
@@ -85,6 +90,11 @@ static struct plat_serial8250_port da8xx_serial_pdata[] = {
 		.regshift	= 2,
 	},
 	{
+		.flags	= 0,
+	},
+};
+static struct plat_serial8250_port da8xx_serial_pdata2[] = {
+	{
 		.mapbase	= DA8XX_UART2_BASE,
 		.irq		= IRQ_DA8XX_UARTINT2,
 		.flags		= UPF_BOOT_AUTOCONF | UPF_SKIP_TEST |
@@ -97,11 +107,29 @@ static struct plat_serial8250_port da8xx_serial_pdata[] = {
 	},
 };
 
-struct platform_device da8xx_serial_device = {
-	.name	= "serial8250",
-	.id	= PLAT8250_DEV_PLATFORM,
-	.dev	= {
-		.platform_data	= da8xx_serial_pdata,
+struct platform_device da8xx_serial_device[] = {
+	{
+		.name	= "serial8250",
+		.id	= PLAT8250_DEV_PLATFORM,
+		.dev	= {
+			.platform_data	= da8xx_serial_pdata0,
+		},
+	},
+	{
+		.name	= "serial8250",
+		.id	= PLAT8250_DEV_PLATFORM1,
+		.dev	= {
+			.platform_data	= da8xx_serial_pdata1,
+		},
+	},
+	{
+		.name	= "serial8250",
+		.id	= PLAT8250_DEV_PLATFORM2,
+		.dev	= {
+			.platform_data	= da8xx_serial_pdata2,
+		},
+	},
+	{
 	},
 };
 
diff --git a/arch/arm/mach-davinci/devices-tnetv107x.c b/arch/arm/mach-davinci/devices-tnetv107x.c
index 773ab07..665748f 100644
--- a/arch/arm/mach-davinci/devices-tnetv107x.c
+++ b/arch/arm/mach-davinci/devices-tnetv107x.c
@@ -126,7 +126,7 @@ static struct platform_device edma_device = {
 	.dev.platform_data = tnetv107x_edma_info,
 };
 
-static struct plat_serial8250_port serial_data[] = {
+static struct plat_serial8250_port serial_platform_data0[] = {
 	{
 		.mapbase	= TNETV107X_UART0_BASE,
 		.irq		= IRQ_TNETV107X_UART0,
@@ -137,6 +137,11 @@ static struct plat_serial8250_port serial_data[] = {
 		.regshift	= 2,
 	},
 	{
+		.flags		= 0
+	},
+};
+static struct plat_serial8250_port serial_platform_data1[] = {
+	{
 		.mapbase	= TNETV107X_UART1_BASE,
 		.irq		= IRQ_TNETV107X_UART1,
 		.flags		= UPF_BOOT_AUTOCONF | UPF_SKIP_TEST |
@@ -146,6 +151,11 @@ static struct plat_serial8250_port serial_data[] = {
 		.regshift	= 2,
 	},
 	{
+		.flags		= 0
+	},
+};
+static struct plat_serial8250_port serial_platform_data2[] = {
+	{
 		.mapbase	= TNETV107X_UART2_BASE,
 		.irq		= IRQ_TNETV107X_UART2,
 		.flags		= UPF_BOOT_AUTOCONF | UPF_SKIP_TEST |
@@ -155,14 +165,27 @@ static struct plat_serial8250_port serial_data[] = {
 		.regshift	= 2,
 	},
 	{
-		.flags	= 0,
+		.flags		= 0
 	},
 };
 
-struct platform_device tnetv107x_serial_device = {
-	.name			= "serial8250",
-	.id			= PLAT8250_DEV_PLATFORM,
-	.dev.platform_data	= serial_data,
+
+struct platform_device tnetv107x_serial_device[] = {
+	{
+		.name			= "serial8250",
+		.id			= PLAT8250_DEV_PLATFORM,
+		.dev.platform_data	= serial_platform_data0,
+	},
+	{
+		.name			= "serial8250",
+		.id			= PLAT8250_DEV_PLATFORM1,
+		.dev.platform_data	= serial_platform_data1,
+	},
+	{
+		.name			= "serial8250",
+		.id			= PLAT8250_DEV_PLATFORM2,
+		.dev.platform_data	= serial_platform_data2,
+	},
 };
 
 static struct resource mmc0_resources[] = {
diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index b49c3b7..844541e 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -355,9 +355,9 @@ static struct clk_lookup dm355_clks[] = {
 	CLK(NULL, "clkout3", &clkout3_clk),
 	CLK(NULL, "arm", &arm_clk),
 	CLK(NULL, "mjcp", &mjcp_clk),
-	CLK(NULL, "uart0", &uart0_clk),
-	CLK(NULL, "uart1", &uart1_clk),
-	CLK(NULL, "uart2", &uart2_clk),
+	CLK("serial8250.0", NULL, &uart0_clk),
+	CLK("serial8250.1", NULL, &uart1_clk),
+	CLK("serial8250.2", NULL, &uart2_clk),
 	CLK("i2c_davinci.1", NULL, &i2c_clk),
 	CLK("davinci-mcbsp.0", NULL, &asp0_clk),
 	CLK("davinci-mcbsp.1", NULL, &asp1_clk),
@@ -785,7 +785,7 @@ static struct davinci_timer_info dm355_timer_info = {
 	.clocksource_id	= T0_TOP,
 };
 
-static struct plat_serial8250_port dm355_serial_platform_data[] = {
+static struct plat_serial8250_port dm355_serial_platform_data0[] = {
 	{
 		.mapbase	= DAVINCI_UART0_BASE,
 		.irq		= IRQ_UARTINT0,
@@ -795,6 +795,11 @@ static struct plat_serial8250_port dm355_serial_platform_data[] = {
 		.regshift	= 2,
 	},
 	{
+		.flags		= 0
+	},
+};
+static struct plat_serial8250_port dm355_serial_platform_data1[] = {
+	{
 		.mapbase	= DAVINCI_UART1_BASE,
 		.irq		= IRQ_UARTINT1,
 		.flags		= UPF_BOOT_AUTOCONF | UPF_SKIP_TEST |
@@ -803,6 +808,11 @@ static struct plat_serial8250_port dm355_serial_platform_data[] = {
 		.regshift	= 2,
 	},
 	{
+		.flags		= 0
+	},
+};
+static struct plat_serial8250_port dm355_serial_platform_data2[] = {
+	{
 		.mapbase	= DM355_UART2_BASE,
 		.irq		= IRQ_DM355_UARTINT2,
 		.flags		= UPF_BOOT_AUTOCONF | UPF_SKIP_TEST |
@@ -815,11 +825,29 @@ static struct plat_serial8250_port dm355_serial_platform_data[] = {
 	},
 };
 
-static struct platform_device dm355_serial_device = {
-	.name			= "serial8250",
-	.id			= PLAT8250_DEV_PLATFORM,
-	.dev			= {
-		.platform_data	= dm355_serial_platform_data,
+static struct platform_device dm355_serial_device[] = {
+	{
+		.name			= "serial8250",
+		.id			= PLAT8250_DEV_PLATFORM,
+		.dev			= {
+			.platform_data	= dm355_serial_platform_data0,
+		},
+	},
+	{
+		.name			= "serial8250",
+		.id			= PLAT8250_DEV_PLATFORM1,
+		.dev			= {
+			.platform_data	= dm355_serial_platform_data1,
+		},
+	},
+	{
+		.name			= "serial8250",
+		.id			= PLAT8250_DEV_PLATFORM2,
+		.dev			= {
+			.platform_data	= dm355_serial_platform_data2,
+		},
+	},
+	{
 	},
 };
 
@@ -844,7 +872,7 @@ static struct davinci_soc_info davinci_soc_info_dm355 = {
 	.gpio_base		= DAVINCI_GPIO_BASE,
 	.gpio_num		= 104,
 	.gpio_irq		= IRQ_DM355_GPIOBNK0,
-	.serial_dev		= &dm355_serial_device,
+	.serial_dev		= dm355_serial_device,
 	.sram_dma		= 0x00010000,
 	.sram_len		= SZ_32K,
 };
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index 6c39805..5492cbc 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -451,8 +451,8 @@ static struct clk_lookup dm365_clks[] = {
 	CLK(NULL, "vpss_dac", &vpss_dac_clk),
 	CLK(NULL, "vpss_master", &vpss_master_clk),
 	CLK(NULL, "arm", &arm_clk),
-	CLK(NULL, "uart0", &uart0_clk),
-	CLK(NULL, "uart1", &uart1_clk),
+	CLK("serial8250.0", NULL, &uart0_clk),
+	CLK("serial8250.1", NULL, &uart1_clk),
 	CLK("i2c_davinci.1", NULL, &i2c_clk),
 	CLK("davinci_mmc.0", NULL, &mmcsd0_clk),
 	CLK("davinci_mmc.1", NULL, &mmcsd1_clk),
@@ -1037,7 +1037,7 @@ static struct davinci_timer_info dm365_timer_info = {
 
 #define DM365_UART1_BASE	(IO_PHYS + 0x106000)
 
-static struct plat_serial8250_port dm365_serial_platform_data[] = {
+static struct plat_serial8250_port dm365_serial_platform_data0[] = {
 	{
 		.mapbase	= DAVINCI_UART0_BASE,
 		.irq		= IRQ_UARTINT0,
@@ -1047,6 +1047,11 @@ static struct plat_serial8250_port dm365_serial_platform_data[] = {
 		.regshift	= 2,
 	},
 	{
+		.flags		= 0
+	},
+};
+static struct plat_serial8250_port dm365_serial_platform_data1[] = {
+	{
 		.mapbase	= DM365_UART1_BASE,
 		.irq		= IRQ_UARTINT1,
 		.flags		= UPF_BOOT_AUTOCONF | UPF_SKIP_TEST |
@@ -1059,14 +1064,26 @@ static struct plat_serial8250_port dm365_serial_platform_data[] = {
 	},
 };
 
-static struct platform_device dm365_serial_device = {
-	.name			= "serial8250",
-	.id			= PLAT8250_DEV_PLATFORM,
-	.dev			= {
-		.platform_data	= dm365_serial_platform_data,
+static struct platform_device dm365_serial_device[] = {
+	{
+		.name			= "serial8250",
+		.id			= PLAT8250_DEV_PLATFORM,
+		.dev			= {
+			.platform_data	= dm365_serial_platform_data0,
+		},
+	},
+	{
+		.name			= "serial8250",
+		.id			= PLAT8250_DEV_PLATFORM1,
+		.dev			= {
+			.platform_data	= dm365_serial_platform_data1,
+		},
+	},
+	{
 	},
 };
 
+
 static struct davinci_soc_info davinci_soc_info_dm365 = {
 	.io_desc		= dm365_io_desc,
 	.io_desc_num		= ARRAY_SIZE(dm365_io_desc),
@@ -1089,7 +1106,7 @@ static struct davinci_soc_info davinci_soc_info_dm365 = {
 	.gpio_num		= 104,
 	.gpio_irq		= IRQ_DM365_GPIO0,
 	.gpio_unbanked		= 8,	/* really 16 ... skip muxed GPIOs */
-	.serial_dev		= &dm365_serial_device,
+	.serial_dev		= dm365_serial_device,
 	.emac_pdata		= &dm365_emac_pdata,
 	.sram_dma		= 0x00010000,
 	.sram_len		= SZ_32K,
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index db1dd92..8134c47 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -303,9 +303,9 @@ static struct clk_lookup dm644x_clks[] = {
 	CLK(NULL, "vpss_master", &vpss_master_clk),
 	CLK(NULL, "vpss_slave", &vpss_slave_clk),
 	CLK(NULL, "arm", &arm_clk),
-	CLK(NULL, "uart0", &uart0_clk),
-	CLK(NULL, "uart1", &uart1_clk),
-	CLK(NULL, "uart2", &uart2_clk),
+	CLK("serial8250.0", NULL, &uart0_clk),
+	CLK("serial8250.1", NULL, &uart1_clk),
+	CLK("serial8250.2", NULL, &uart2_clk),
 	CLK("davinci_emac.1", NULL, &emac_clk),
 	CLK("i2c_davinci.1", NULL, &i2c_clk),
 	CLK("palm_bk3710", NULL, &ide_clk),
@@ -813,7 +813,7 @@ static struct davinci_timer_info dm644x_timer_info = {
 	.clocksource_id	= T0_TOP,
 };
 
-static struct plat_serial8250_port dm644x_serial_platform_data[] = {
+static struct plat_serial8250_port dm644x_serial_platform_data0[] = {
 	{
 		.mapbase	= DAVINCI_UART0_BASE,
 		.irq		= IRQ_UARTINT0,
@@ -823,6 +823,11 @@ static struct plat_serial8250_port dm644x_serial_platform_data[] = {
 		.regshift	= 2,
 	},
 	{
+		.flags		= 0
+	},
+};
+static struct plat_serial8250_port dm644x_serial_platform_data1[] = {
+	{
 		.mapbase	= DAVINCI_UART1_BASE,
 		.irq		= IRQ_UARTINT1,
 		.flags		= UPF_BOOT_AUTOCONF | UPF_SKIP_TEST |
@@ -831,6 +836,11 @@ static struct plat_serial8250_port dm644x_serial_platform_data[] = {
 		.regshift	= 2,
 	},
 	{
+		.flags		= 0
+	},
+};
+static struct plat_serial8250_port dm644x_serial_platform_data2[] = {
+	{
 		.mapbase	= DAVINCI_UART2_BASE,
 		.irq		= IRQ_UARTINT2,
 		.flags		= UPF_BOOT_AUTOCONF | UPF_SKIP_TEST |
@@ -843,11 +853,29 @@ static struct plat_serial8250_port dm644x_serial_platform_data[] = {
 	},
 };
 
-static struct platform_device dm644x_serial_device = {
-	.name			= "serial8250",
-	.id			= PLAT8250_DEV_PLATFORM,
-	.dev			= {
-		.platform_data	= dm644x_serial_platform_data,
+static struct platform_device dm644x_serial_device[] = {
+	{
+		.name			= "serial8250",
+		.id			= PLAT8250_DEV_PLATFORM,
+		.dev			= {
+			.platform_data	= dm644x_serial_platform_data0,
+		},
+	},
+	{
+		.name			= "serial8250",
+		.id			= PLAT8250_DEV_PLATFORM1,
+		.dev			= {
+			.platform_data	= dm644x_serial_platform_data1,
+		},
+	},
+	{
+		.name			= "serial8250",
+		.id			= PLAT8250_DEV_PLATFORM2,
+		.dev			= {
+			.platform_data	= dm644x_serial_platform_data2,
+		},
+	},
+	{
 	},
 };
 
@@ -872,7 +900,7 @@ static struct davinci_soc_info davinci_soc_info_dm644x = {
 	.gpio_base		= DAVINCI_GPIO_BASE,
 	.gpio_num		= 71,
 	.gpio_irq		= IRQ_GPIOBNK0,
-	.serial_dev		= &dm644x_serial_device,
+	.serial_dev		= dm644x_serial_device,
 	.emac_pdata		= &dm644x_emac_pdata,
 	.sram_dma		= 0x00008000,
 	.sram_len		= SZ_16K,
diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c
index ac7b431..0f0cac6 100644
--- a/arch/arm/mach-davinci/dm646x.c
+++ b/arch/arm/mach-davinci/dm646x.c
@@ -342,9 +342,9 @@ static struct clk_lookup dm646x_clks[] = {
 	CLK(NULL, "edma_tc1", &edma_tc1_clk),
 	CLK(NULL, "edma_tc2", &edma_tc2_clk),
 	CLK(NULL, "edma_tc3", &edma_tc3_clk),
-	CLK(NULL, "uart0", &uart0_clk),
-	CLK(NULL, "uart1", &uart1_clk),
-	CLK(NULL, "uart2", &uart2_clk),
+	CLK("serial8250.0", NULL, &uart0_clk),
+	CLK("serial8250.1", NULL, &uart1_clk),
+	CLK("serial8250.2", NULL, &uart2_clk),
 	CLK("i2c_davinci.1", NULL, &i2c_clk),
 	CLK(NULL, "gpio", &gpio_clk),
 	CLK("davinci-mcasp.0", NULL, &mcasp0_clk),
@@ -790,7 +790,7 @@ static struct davinci_timer_info dm646x_timer_info = {
 	.clocksource_id	= T0_TOP,
 };
 
-static struct plat_serial8250_port dm646x_serial_platform_data[] = {
+static struct plat_serial8250_port dm646x_serial_platform_data0[] = {
 	{
 		.mapbase	= DAVINCI_UART0_BASE,
 		.irq		= IRQ_UARTINT0,
@@ -800,6 +800,11 @@ static struct plat_serial8250_port dm646x_serial_platform_data[] = {
 		.regshift	= 2,
 	},
 	{
+		.flags		= 0
+	},
+};
+static struct plat_serial8250_port dm646x_serial_platform_data1[] = {
+	{
 		.mapbase	= DAVINCI_UART1_BASE,
 		.irq		= IRQ_UARTINT1,
 		.flags		= UPF_BOOT_AUTOCONF | UPF_SKIP_TEST |
@@ -808,6 +813,11 @@ static struct plat_serial8250_port dm646x_serial_platform_data[] = {
 		.regshift	= 2,
 	},
 	{
+		.flags		= 0
+	},
+};
+static struct plat_serial8250_port dm646x_serial_platform_data2[] = {
+	{
 		.mapbase	= DAVINCI_UART2_BASE,
 		.irq		= IRQ_DM646X_UARTINT2,
 		.flags		= UPF_BOOT_AUTOCONF | UPF_SKIP_TEST |
@@ -820,14 +830,33 @@ static struct plat_serial8250_port dm646x_serial_platform_data[] = {
 	},
 };
 
-static struct platform_device dm646x_serial_device = {
-	.name			= "serial8250",
-	.id			= PLAT8250_DEV_PLATFORM,
-	.dev			= {
-		.platform_data	= dm646x_serial_platform_data,
+static struct platform_device dm646x_serial_device[] = {
+	{
+		.name			= "serial8250",
+		.id			= PLAT8250_DEV_PLATFORM,
+		.dev			= {
+			.platform_data	= dm646x_serial_platform_data0,
+		},
+	},
+	{
+		.name			= "serial8250",
+		.id			= PLAT8250_DEV_PLATFORM1,
+		.dev			= {
+			.platform_data	= dm646x_serial_platform_data1,
+		},
+	},
+	{
+		.name			= "serial8250",
+		.id			= PLAT8250_DEV_PLATFORM2,
+		.dev			= {
+			.platform_data	= dm646x_serial_platform_data2,
+		},
+	},
+	{
 	},
 };
 
+
 static struct davinci_soc_info davinci_soc_info_dm646x = {
 	.io_desc		= dm646x_io_desc,
 	.io_desc_num		= ARRAY_SIZE(dm646x_io_desc),
@@ -849,7 +878,7 @@ static struct davinci_soc_info davinci_soc_info_dm646x = {
 	.gpio_base		= DAVINCI_GPIO_BASE,
 	.gpio_num		= 43, /* Only 33 usable */
 	.gpio_irq		= IRQ_DM646X_GPIOBNK0,
-	.serial_dev		= &dm646x_serial_device,
+	.serial_dev		= dm646x_serial_device,
 	.emac_pdata		= &dm646x_emac_pdata,
 	.sram_dma		= 0x10010000,
 	.sram_len		= SZ_32K,
diff --git a/arch/arm/mach-davinci/include/mach/da8xx.h b/arch/arm/mach-davinci/include/mach/da8xx.h
index de439b7..9453fd2 100644
--- a/arch/arm/mach-davinci/include/mach/da8xx.h
+++ b/arch/arm/mach-davinci/include/mach/da8xx.h
@@ -105,7 +105,7 @@ int __init da850_register_vpif_capture
 			(struct vpif_capture_config *capture_config);
 void da8xx_restart(char mode, const char *cmd);
 
-extern struct platform_device da8xx_serial_device;
+extern struct platform_device da8xx_serial_device[];
 extern struct emac_platform_data da8xx_emac_pdata;
 extern struct da8xx_lcdc_platform_data sharp_lcd035q3dg01_pdata;
 extern struct da8xx_lcdc_platform_data sharp_lk043t1dg01_pdata;
diff --git a/arch/arm/mach-davinci/include/mach/tnetv107x.h b/arch/arm/mach-davinci/include/mach/tnetv107x.h
index 1656a02..07948a5 100644
--- a/arch/arm/mach-davinci/include/mach/tnetv107x.h
+++ b/arch/arm/mach-davinci/include/mach/tnetv107x.h
@@ -49,7 +49,7 @@ struct tnetv107x_device_info {
 };
 
 extern struct platform_device tnetv107x_wdt_device;
-extern struct platform_device tnetv107x_serial_device;
+extern struct platform_device tnetv107x_serial_device[];
 
 extern void __init tnetv107x_init(void);
 extern void __init tnetv107x_devices_init(struct tnetv107x_device_info *);
diff --git a/arch/arm/mach-davinci/serial.c b/arch/arm/mach-davinci/serial.c
index f262581..57e6150 100644
--- a/arch/arm/mach-davinci/serial.c
+++ b/arch/arm/mach-davinci/serial.c
@@ -76,7 +76,7 @@ int __init davinci_serial_setup_clk(unsigned instance, unsigned int *rate)
 	char name[16];
 	struct clk *clk;
 	struct davinci_soc_info *soc_info = &davinci_soc_info;
-	struct device *dev = &soc_info->serial_dev->dev;
+	struct device *dev = &soc_info->serial_dev[instance].dev;
 
 	sprintf(name, "uart%d", instance);
 	clk = clk_get(dev, name);
@@ -96,19 +96,25 @@ int __init davinci_serial_setup_clk(unsigned instance, unsigned int *rate)
 
 int __init davinci_serial_init(struct davinci_uart_config *info)
 {
-	int i, ret;
+	int i, ret = 0;
 	struct davinci_soc_info *soc_info = &davinci_soc_info;
-	struct device *dev = &soc_info->serial_dev->dev;
-	struct plat_serial8250_port *p = dev->platform_data;
+	struct device *dev;
+	struct plat_serial8250_port *p;
 
 	/*
 	 * Make sure the serial ports are muxed on at this point.
 	 * You have to mux them off in device drivers later on if not needed.
 	 */
-	for (i = 0; p->flags; i++, p++) {
+	for (i = 0; soc_info->serial_dev[i].dev.platform_data != NULL; i++) {
+		dev = &soc_info->serial_dev[i].dev;
+		p = dev->platform_data;
 		if (!(info->enabled_uarts & (1 << i)))
 			continue;
 
+		ret = platform_device_register(&soc_info->serial_dev[i]);
+		if (ret)
+			continue;
+
 		ret = davinci_serial_setup_clk(i, &p->uartclk);
 		if (ret)
 			continue;
@@ -125,6 +131,5 @@ int __init davinci_serial_init(struct davinci_uart_config *info)
 		if (p->membase && p->type != PORT_AR7)
 			davinci_serial_reset(p);
 	}
-
-	return platform_device_register(soc_info->serial_dev);
+	return ret;
 }
diff --git a/arch/arm/mach-davinci/tnetv107x.c b/arch/arm/mach-davinci/tnetv107x.c
index dc1a209..0a3601a 100644
--- a/arch/arm/mach-davinci/tnetv107x.c
+++ b/arch/arm/mach-davinci/tnetv107x.c
@@ -263,7 +263,7 @@ static struct clk_lookup clks[] = {
 	CLK(NULL,		"clk_chipcfg",		&clk_chipcfg),
 	CLK("tnetv107x-ts.0",	NULL,			&clk_tsc),
 	CLK(NULL,		"clk_rom",		&clk_rom),
-	CLK(NULL,		"uart2",		&clk_uart2),
+	CLK("serial8250.2",     NULL,			&clk_uart2),
 	CLK(NULL,		"clk_pktsec",		&clk_pktsec),
 	CLK("tnetv107x-rng.0",	NULL,			&clk_rng),
 	CLK("tnetv107x-pka.0",	NULL,			&clk_pka),
@@ -273,8 +273,8 @@ static struct clk_lookup clks[] = {
 	CLK(NULL,		"clk_gpio",		&clk_gpio),
 	CLK(NULL,		"clk_mdio",		&clk_mdio),
 	CLK("davinci_mmc.0",	NULL,			&clk_sdio0),
-	CLK(NULL,		"uart0",		&clk_uart0),
-	CLK(NULL,		"uart1",		&clk_uart1),
+	CLK("serial8250.0",	NULL,			&clk_uart0),
+	CLK("serial8250.1",	NULL,			&clk_uart1),
 	CLK(NULL,		"timer0",		&clk_timer0),
 	CLK(NULL,		"timer1",		&clk_timer1),
 	CLK("tnetv107x_wdt.0",	NULL,			&clk_wdt_arm),
@@ -756,7 +756,7 @@ static struct davinci_soc_info tnetv107x_soc_info = {
 	.gpio_type		= GPIO_TYPE_TNETV107X,
 	.gpio_num		= TNETV107X_N_GPIO,
 	.timer_info		= &timer_info,
-	.serial_dev		= &tnetv107x_serial_device,
+	.serial_dev		= tnetv107x_serial_device,
 };
 
 void __init tnetv107x_init(void)
-- 
1.7.4.1



From prakash.pm at ti.com  Tue Apr  9 08:31:02 2013
From: prakash.pm at ti.com (Manjunathappa, Prakash)
Date: Tue, 9 Apr 2013 18:01:02 +0530
Subject: [PATCH 2/4] ARM: davinci: da850: override device name of UART in DT
 kernel
In-Reply-To: <1365510481-32129-1-git-send-email-prakash.pm@ti.com>
References: <1365510481-32129-1-git-send-email-prakash.pm@ti.com>
Message-ID: <1365510664-1394-3-git-send-email-prakash.pm@ti.com>

Populate OF_DEV_AUXDATA with desired device name so as to prevent
clk_get failures.

Signed-off-by: Manjunathappa, Prakash <prakash.pm at ti.com>
---
 arch/arm/mach-davinci/da8xx-dt.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-davinci/da8xx-dt.c b/arch/arm/mach-davinci/da8xx-dt.c
index 6b7a0a2..fff78a1 100644
--- a/arch/arm/mach-davinci/da8xx-dt.c
+++ b/arch/arm/mach-davinci/da8xx-dt.c
@@ -40,6 +40,9 @@ static void __init da8xx_init_irq(void)
 struct of_dev_auxdata da850_auxdata_lookup[] __initdata = {
 	OF_DEV_AUXDATA("ti,davinci-i2c", 0x01c22000, "i2c_davinci.1", NULL),
 	OF_DEV_AUXDATA("ti,davinci-wdt", 0x01c21000, "watchdog", NULL),
+	OF_DEV_AUXDATA("ns16550a", 0x01c42000, "serial8250.0", NULL),
+	OF_DEV_AUXDATA("ns16550a", 0x01d0c000, "serial8250.1", NULL),
+	OF_DEV_AUXDATA("ns16550a", 0x01d0d000, "serial8250.2", NULL),
 	{}
 };
 
-- 
1.7.4.1



From prakash.pm at ti.com  Tue Apr  9 08:31:03 2013
From: prakash.pm at ti.com (Manjunathappa, Prakash)
Date: Tue, 9 Apr 2013 18:01:03 +0530
Subject: [PATCH 3/4] ARM: davinci: da850: do not specify clock_frequency for
 UART DT node
In-Reply-To: <1365510481-32129-1-git-send-email-prakash.pm@ti.com>
References: <1365510481-32129-1-git-send-email-prakash.pm@ti.com>
Message-ID: <1365510664-1394-4-git-send-email-prakash.pm@ti.com>

DT kernel on da850-evm comes up with garbled UART logs. This is because
of mismatch in actual module clock rate and rate specified(clock-frequency)
in DT blob. kernel should not assume or depend on bootloaders clock
configuration, instead let it find the clock rate at runtime.

Issue discussed here before arriving on this implementation:
"ARM: davinci: da850 evm: update clock rate for UART 1/2 DT nodes"
https://patchwork.kernel.org/patch/2162271/

Signed-off-by: Manjunathappa, Prakash <prakash.pm at ti.com>
---
 arch/arm/boot/dts/da850.dtsi |    3 ---
 1 files changed, 0 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 3ec1bda..4498375 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -66,7 +66,6 @@
 		serial0: serial at 1c42000 {
 			compatible = "ns16550a";
 			reg = <0x42000 0x100>;
-			clock-frequency = <150000000>;
 			reg-shift = <2>;
 			interrupts = <25>;
 			status = "disabled";
@@ -74,7 +73,6 @@
 		serial1: serial at 1d0c000 {
 			compatible = "ns16550a";
 			reg = <0x10c000 0x100>;
-			clock-frequency = <150000000>;
 			reg-shift = <2>;
 			interrupts = <53>;
 			status = "disabled";
@@ -82,7 +80,6 @@
 		serial2: serial at 1d0d000 {
 			compatible = "ns16550a";
 			reg = <0x10d000 0x100>;
-			clock-frequency = <150000000>;
 			reg-shift = <2>;
 			interrupts = <61>;
 			status = "disabled";
-- 
1.7.4.1



From prakash.pm at ti.com  Tue Apr  9 08:31:04 2013
From: prakash.pm at ti.com (Manjunathappa, Prakash)
Date: Tue, 9 Apr 2013 18:01:04 +0530
Subject: [PATCH 4/4] ARM: davinci: da8xx: remove da8xx_uart_clk_enable
In-Reply-To: <1365510481-32129-1-git-send-email-prakash.pm@ti.com>
References: <1365510481-32129-1-git-send-email-prakash.pm@ti.com>
Message-ID: <1365510664-1394-5-git-send-email-prakash.pm@ti.com>

Serial clocks are enabled from of_platform_serial_setup:of_serial.c,
so remove davinci_serial_setup_clk from here.

Signed-off-by: Manjunathappa, Prakash <prakash.pm at ti.com>
---
 arch/arm/mach-davinci/da8xx-dt.c |    8 --------
 1 files changed, 0 insertions(+), 8 deletions(-)

diff --git a/arch/arm/mach-davinci/da8xx-dt.c b/arch/arm/mach-davinci/da8xx-dt.c
index fff78a1..219126b 100644
--- a/arch/arm/mach-davinci/da8xx-dt.c
+++ b/arch/arm/mach-davinci/da8xx-dt.c
@@ -20,13 +20,6 @@
 
 #define DA8XX_NUM_UARTS	3
 
-void __init da8xx_uart_clk_enable(void)
-{
-	int i;
-	for (i = 0; i < DA8XX_NUM_UARTS; i++)
-		davinci_serial_setup_clk(i, NULL);
-}
-
 static struct of_device_id da8xx_irq_match[] __initdata = {
 	{ .compatible = "ti,cp-intc", .data = cp_intc_of_init, },
 	{ }
@@ -53,7 +46,6 @@ static void __init da850_init_machine(void)
 	of_platform_populate(NULL, of_default_bus_match_table,
 			     da850_auxdata_lookup, NULL);
 
-	da8xx_uart_clk_enable();
 }
 
 static const char *da850_boards_compat[] __initdata = {
-- 
1.7.4.1



From cov at codeaurora.org  Tue Apr  9 08:33:34 2013
From: cov at codeaurora.org (Christopher Covington)
Date: Tue,  9 Apr 2013 08:33:34 -0400
Subject: [PATCH v2] arm64: Fix task tracing
In-Reply-To: <20130408153132.GQ17476@mudshark.cambridge.arm.com>
References: <20130408153132.GQ17476@mudshark.cambridge.arm.com>
Message-ID: <1365510814-21343-1-git-send-email-cov@codeaurora.org>

For accurate accounting pass contextidr_thread_switch the prev
task pointer, since cpu_switch_to has at that point changed the
the stack pointer.

Signed-off-by: Christopher Covington <cov at codeaurora.org>
---
 arch/arm64/kernel/process.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
index 0337cdb..a49b25a 100644
--- a/arch/arm64/kernel/process.c
+++ b/arch/arm64/kernel/process.c
@@ -315,7 +315,7 @@ struct task_struct *__switch_to(struct task_struct *prev,
 	/* the actual thread switch */
 	last = cpu_switch_to(prev, next);
 
-	contextidr_thread_switch(next);
+	contextidr_thread_switch(prev);
 	return last;
 }
 
-- 
Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by the Linux Foundation.



From shawn.guo at linaro.org  Tue Apr  9 08:35:44 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 9 Apr 2013 20:35:44 +0800
Subject: [PATCH 1/3] ARM: mx28: add auart2 2 pins pinmux to imx28.dtsi
In-Reply-To: <1365425853-12457-1-git-send-email-eric@eukrea.com>
References: <1365425853-12457-1-git-send-email-eric@eukrea.com>
Message-ID: <20130409123542.GG5044@S2101-09.ap.freescale.net>

On Mon, Apr 08, 2013 at 02:57:31PM +0200, Eric B?nard wrote:
> Add auart2 2 pins configuration on its main pads
> 
> Signed-off-by: Eric B?nard <eric at eukrea.com>

All 3 patches applied, thanks.

> ---
>  arch/arm/boot/dts/imx28.dtsi | 11 +++++++++++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
> index 7ba4966..13799cf 100644
> --- a/arch/arm/boot/dts/imx28.dtsi
> +++ b/arch/arm/boot/dts/imx28.dtsi
> @@ -308,6 +308,17 @@
>  					fsl,pull-up = <0>;
>  				};
>  
> +				auart2_2pins_b: auart2-2pins at 1 {
> +					reg = <1>;
> +					fsl,pinmux-ids = <
> +						0x3080 /* MX28_PAD_AUART2_RX__AUART2_RX */
> +						0x3090 /* MX28_PAD_AUART2_TX__AUART2_TX */
> +					>;
> +					fsl,drive-strength = <0>;
> +					fsl,voltage = <1>;
> +					fsl,pull-up = <0>;
> +				};
> +
>  				auart3_pins_a: auart3 at 0 {
>  					reg = <0>;
>  					fsl,pinmux-ids = <
> -- 
> 1.7.11.7
> 



From arnd at arndb.de  Tue Apr  9 08:36:41 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 9 Apr 2013 14:36:41 +0200
Subject: [GIT PULL 3/5] omap board changes for v3.10 merge window
In-Reply-To: <0Lgo4c-1UueHv2nOo-00naI8@mx.kundenserver.de>
References: <0Lgo4c-1UueHv2nOo-00naI8@mx.kundenserver.de>
Message-ID: <201304091436.42046.arnd@arndb.de>

On Tuesday 09 April 2013, Tony Lindgren wrote:
> The following changes since commit 31880c37c11e28cb81c70757e38392b42e695dc6:
> 
>   Linux 3.9-rc6 (2013-04-07 20:49:54 -0700)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.10/board-signed
> 
> for you to fetch changes up to 06993d6a8a51b90fc78c8c3cb7a81c9b4b88c683:
> 
>   ARM: OMAP: board-4430sdp: Provide regulator to pwm-backlight (2013-04-08 14:01:05 -0700)
> 
> ----------------------------------------------------------------
> Board related changes for v3.10 merge window. These are pretty
> much all non-critical fixes for platform device initialization
> that will be needed until we can drop the board-*.c files and
> move to DT based boot.
> 

Pulled into next/boards branch

	Arnd


From horms at verge.net.au  Tue Apr  9 08:42:46 2013
From: horms at verge.net.au (Simon Horman)
Date: Tue, 9 Apr 2013 21:42:46 +0900
Subject: [PATCH 00/02] ARM: shmobile: r8a7790 Lager arch timer fixes
In-Reply-To: <87r4ilolmh.wl%kuninori.morimoto.gx@renesas.com>
References: <20130408012318.13555.58237.sendpatchset@w520>
 <87r4ilolmh.wl%kuninori.morimoto.gx@renesas.com>
Message-ID: <20130409124245.GE15412@verge.net.au>

On Sun, Apr 07, 2013 at 06:29:46PM -0700, Kuninori Morimoto wrote:
> 
> Hi
> 
> > ARM: shmobile: r8a7790 Lager arch timer fixes
> > 
> > [PATCH 01/02] ARM: shmobile: force enable of r8a7790 arch timer 
> > [PATCH 02/02] ARM: shmobile: use r8a7790 timer setup code on Lager
> > 
> > This mini-series contains fixes to start the arch timer on
> > r8a7790 and the Lager board regardless of boot loader setting.
> > 
> > Signed-off-by: Magnus Damm <damm at opensource.se>
> > ---
> 
> I guess shmobile_timer_init() will be conflict (or compile error)
> on next (?) merge window thought...
> but, for current code/branch

[ discussed in another sub-thread ]

> Tested-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>

Thanks.

01/02 queued up in the soc-r8a7790 branch
02/02 queue up in the boards-lager branch,
      which is a merge of renesas-boards3-for-v3.10 and soc-r8a7790


From horms at verge.net.au  Tue Apr  9 08:34:34 2013
From: horms at verge.net.au (Simon Horman)
Date: Tue, 9 Apr 2013 21:34:34 +0900
Subject: [PATCH] ARM: shmobile: Include all 2 GiB of memory on APE6EVM
In-Reply-To: <20130408014444.18767.64441.sendpatchset@w520>
References: <20130408014444.18767.64441.sendpatchset@w520>
Message-ID: <20130409123433.GD15412@verge.net.au>

On Mon, Apr 08, 2013 at 10:44:44AM +0900, Magnus Damm wrote:
> From: Takashi Yoshii <takashi.yoshii.zj at renesas.com>
> 
> Add 1GiB of DRAM at 0x2_0000_0000
> 
> Signed-off-by: Takashi Yoshii <takashi.yoshii.zj at renesas.com>
> Signed-off-by: Magnus Damm <damm at opensource.se>

Thanks, queued up in the boards-ape6evm branch.

> ---
> 
>  This patch simply updates the DTS to describe the actual board
>  hardware. If we want to make use of the memory we also need to
>  enable LPAE in the kernel configuration, but that is seen as a
>  separate step.
> 
>  arch/arm/boot/dts/r8a73a4-ape6evm.dts |    5 +++++
>  1 file changed, 5 insertions(+)
> 
> --- 0001/arch/arm/boot/dts/r8a73a4-ape6evm.dts
> +++ work/arch/arm/boot/dts/r8a73a4-ape6evm.dts	2013-04-08 10:27:20.000000000 +0900
> @@ -24,6 +24,11 @@
>  		reg = <0 0x40000000 0 0x40000000>;
>  	};
>  
> +	memory at 200000000 {
> +		device_type = "memory";
> +		reg = <2 0x00000000 0 0x40000000>;
> +	};
> +
>  	ape6evm_fixed_3v3: fixedregulator at 0 {
>  		compatible = "regulator-fixed";
>  		regulator-name = "3V3";
> 


From nicolas.ferre at atmel.com  Tue Apr  9 08:45:00 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Tue, 9 Apr 2013 14:45:00 +0200
Subject: [PATCH] mmc: atmel-mci: remove include <mach/cpu.h>
Message-ID: <1365511500-13778-1-git-send-email-nicolas.ferre@atmel.com>

Header file not needed anymore as we have removed
the calls to cpu_is_xxx() macro.

Signed-off-by: Nicolas Ferre <nicolas.ferre at atmel.com>
---
 drivers/mmc/host/atmel-mci.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/mmc/host/atmel-mci.c b/drivers/mmc/host/atmel-mci.c
index e75774f..08e2b92 100644
--- a/drivers/mmc/host/atmel-mci.c
+++ b/drivers/mmc/host/atmel-mci.c
@@ -40,8 +40,6 @@
 #include <asm/io.h>
 #include <asm/unaligned.h>
 
-#include <mach/cpu.h>
-
 #include "atmel-mci-regs.h"
 
 #define ATMCI_DATA_ERROR_FLAGS	(ATMCI_DCRCE | ATMCI_DTOE | ATMCI_OVRE | ATMCI_UNRE)
-- 
1.8.0



From sergei.shtylyov at cogentembedded.com  Tue Apr  9 08:44:17 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Tue, 09 Apr 2013 16:44:17 +0400
Subject: [PATCH v2 0/9] Reorganize R8A7779/Marzen USB code
In-Reply-To: <87zjx89rfb.wl%kuninori.morimoto.gx@renesas.com>
References: <201304090110.50154.sergei.shtylyov@cogentembedded.com>
 <87zjx89rfb.wl%kuninori.morimoto.gx@renesas.com>
Message-ID: <51640D21.3090800@cogentembedded.com>

Hello.

On 09-04-2013 9:58, Kuninori Morimoto wrote:

>>     Here's the set of 9 patches against the Simon Horman's 'renesas.git' repo,
>> 'renesas-next-20130405v2' tag.  It was created to fix the shortcomings in the
>> R8A7779/Marzen USB platform code and R8A7779 USB common PHY driver, and so
>> spans both arch/arm/mach-shmobile/ and drivers/usb/ subtrees (some patches have
>> to touch both subtrees). The patches were conceived with the complete
>> bisectability goal in mind. The patches have been tested on the Marzen board.

> Please add this "tested on xxx" comment on each patch's log area, not only on [0/x].
> We need it on "git log"

    I'm going to post R8A7778/BOCK-W series following this one, and all the 
patches in 1st series should additionally be tested on BOCK-W. Well, I 
probably can hold up posting version 3 until I have the second series verified.
    BTW, about R8A7778/BOCK-W, R-Car M1A user manual talks about a ferrite 
bead in 49.4.1 (3) Setting USB-PHY. Do you know for sure if it's used or not
on BOCK-W board? PHY initialization seems to work with either settings...

>> [1/9] ARM: shmobile: Marzen: move USB EHCI, OHCI, and PHY devices to R8A7779 code
>> [2/9] ehci-platform: add pre_setup() method to platform data
>> [3/9] ARM: shmobile: R8A7779: setup EHCI internal buffer
>> [4/9] rcar-phy: remove EHCI internal buffer setup
>> [5/9] ARM: shmobile: R8A7779: remove USB PHY 2nd memory resource
>> [6/9] rcar-phy: correct base address
>> [7/9] rcar-phy: add platform data
>> [8/9] ARM: shmobile: Marzen: pass platform data to USB PHY device
>> [9/9] rcar-phy: handle platform data

> I didn't get [7/9][9/9] patch somehow

    Here they are in the archive:

http://marc.info/?l=linux-usb&m=136545680506170
http://marc.info/?l=linux-usb&m=136545698906257

WBR, Sergei



From shawn.guo at linaro.org  Tue Apr  9 08:49:16 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 9 Apr 2013 20:49:16 +0800
Subject: [PATCH 0/5] i.MX53 TVE clock patches
In-Reply-To: <1365432383-7787-1-git-send-email-p.zabel@pengutronix.de>
References: <1365432383-7787-1-git-send-email-p.zabel@pengutronix.de>
Message-ID: <20130409124914.GH5044@S2101-09.ap.freescale.net>

On Mon, Apr 08, 2013 at 04:46:18PM +0200, Philipp Zabel wrote:
> Hi,
> 
> the first two are just cleanups, the following three patches are changes
> to the i.MX53 clock tree that are necessary to use the TVEv2 module as
> VGA output on the Freescale i.MX53-QSB or TQ MBa53 boards.
> 
> regards
> Philipp
> 
> ---
>  Documentation/devicetree/bindings/clock/imx5-clock.txt |  1 -
>  arch/arm/mach-imx/clk-imx51-imx53.c                    | 17 ++++++++---------
>  2 files changed, 8 insertions(+), 10 deletions(-)

All 5 patches applied, thanks.



From horms at verge.net.au  Tue Apr  9 08:52:56 2013
From: horms at verge.net.au (Simon Horman)
Date: Tue, 9 Apr 2013 21:52:56 +0900
Subject: [PATCH] ARM: shmobile: marzen-reference: use irqpin for lan
In-Reply-To: <1365125960-25753-1-git-send-email-horms+renesas@verge.net.au>
References: <1365125960-25753-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <20130409125256.GG15412@verge.net.au>

On Fri, Apr 05, 2013 at 10:39:20AM +0900, Simon Horman wrote:
> This corrects the configuration of the SMSC lan controller
> to use the newly added irqpin as its IRQ source.
> 
> Previously the lan controller did not work. Now it does.
> 
> Cc: Guennadi Liakhovetski <g.liakhovetski+renesas at gmail.com>
> Signed-off-by: Simon Horman <horms+renesas at verge.net.au>

Queued up in the boards-marzen branch.


From arnd at arndb.de  Tue Apr  9 08:53:24 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 9 Apr 2013 14:53:24 +0200
Subject: [GIT PULL] Renesas ARM r8a7778 SoC update for v3.10
In-Reply-To: <1365142324-7286-1-git-send-email-horms+renesas@verge.net.au>
References: <1365142324-7286-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <201304091453.24229.arnd@arndb.de>

On Friday 05 April 2013, Simon Horman wrote:
> Hi Olof, Hi Arnd,
> 
> The following changes since commit 8585deb18580d04209a2986430aa0959ef38fce2:
> 
>   ARM: shmobile: r8a7790 SoC 64-bit DT support (2013-04-02 11:02:21 +0900)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas tags/renesas-soc-r8a7778-for-v3.10
> 
> for you to fetch changes up to 524219146a89aee5366326c225ccd71231419d89:
> 
>   ARM: shmobile: R8A7778: add Ether support (2013-04-05 10:57:05 +0900)

Pulled into next/soc2, thanks!


	Arnd


From arnd at arndb.de  Tue Apr  9 08:53:49 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 9 Apr 2013 14:53:49 +0200
Subject: [GIT PULL] Renesas ARM-based SoC bockw board updates for v3.10
In-Reply-To: <1365131070-13142-1-git-send-email-horms+renesas@verge.net.au>
References: <1365131070-13142-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <201304091453.49770.arnd@arndb.de>

On Friday 05 April 2013, Simon Horman wrote:
> Hi Olof, Hi Arnd,
> 
> The following changes since commit 5e3780ba6dded2636c939549e3bea16d736859fb:
> 
>   Merge branch 'soc-r8a7778' into boards-bockw-base (2013-04-05 11:32:38 +0900)
> 
> are available in the git repository at:
> 
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas tags/renesas-boards-bockw-for-v3.10
> 
> for you to fetch changes up to 446ee9b2d813a9378e304008fc433ce543ca68a1:
> 
>   ARM: shmobile: bockw: enable network settings on bootargs (2013-04-05 11:32:53 +0900)
> 
> ----------------------------------------------------------------
> Renesas ARM-based SoC bockw board updates for v3.10
> 
> Add SMSC ethernet support to the bockw board.
> 
> This pull request is based on a merge of:
> git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git renesas-soc-r8a7778-for-v3.10
> git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git renesas-boards3-for-v3.10
> 


Pulled into next/boards2, thanks!

	Arnd


From arnd at arndb.de  Tue Apr  9 08:54:10 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 9 Apr 2013 14:54:10 +0200
Subject: [GIT PULL] Renesas ARM r8a7779 SoC update for v3.10
In-Reply-To: <1365130669-11662-1-git-send-email-horms+renesas@verge.net.au>
References: <1365130669-11662-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <201304091454.10325.arnd@arndb.de>

On Friday 05 April 2013, Simon Horman wrote:
> The following changes since commit 8585deb18580d04209a2986430aa0959ef38fce2:
> 
>   ARM: shmobile: r8a7790 SoC 64-bit DT support (2013-04-02 11:02:21 +0900)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas tags/renesas-soc-r8a7779-for-v3.10
> 
> for you to fetch changes up to dace48d04dee46a3409d5e13cd98031522e46377:
> 
>   ARM: shmobile: R8A7779: add Ether support (2013-04-05 10:47:03 +0900)
> 
> ----------------------------------------------------------------
> Renesas ARM r8a7779 SoC update for v3.10
> 
> Update to the r8a7779 SoC:
> * Add SH Ethernet support
> * Add comment describing clock ratios
> 
> This pull request is based on:
> git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas renesas-soc2-for-v3.10
> 

Pulled into next/soc2, thanks!

	Arnd


From shawn.guo at linaro.org  Tue Apr  9 08:55:06 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 9 Apr 2013 20:55:06 +0800
Subject: [PATCH 7/7] staging: drm/imx: Add support for Television Encoder
 (TVEv2)
In-Reply-To: <1365437078-22579-8-git-send-email-p.zabel@pengutronix.de>
References: <1365437078-22579-1-git-send-email-p.zabel@pengutronix.de>
 <1365437078-22579-8-git-send-email-p.zabel@pengutronix.de>
Message-ID: <20130409125505.GI5044@S2101-09.ap.freescale.net>

On Mon, Apr 08, 2013 at 06:04:38PM +0200, Philipp Zabel wrote:
> This driver adds support for the Television Encoder integrated
> on i.MX53 SoCs (TVEv2).
> 
> Currently only the VGA output mode is supported, which only uses
> the TVDAC to generate RGB levels. HSYNC and VSYNC signals are
> routed directly from the IPU signal generator pins through IOMUXC.
> 
> Signed-off-by: Philipp Zabel <p.zabel at pengutronix.de>
> ---
>  drivers/staging/imx-drm/Kconfig   |   7 +
>  drivers/staging/imx-drm/Makefile  |   1 +
>  drivers/staging/imx-drm/imx-tve.c | 755 ++++++++++++++++++++++++++++++++++++++
>  3 files changed, 763 insertions(+)
>  create mode 100644 drivers/staging/imx-drm/imx-tve.c

Bindings doc is missing.

Shawn



From arnd at arndb.de  Tue Apr  9 08:58:03 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 9 Apr 2013 14:58:03 +0200
Subject: [GIT PULL v2] imx fixes for 3.9, take 5
In-Reply-To: <20130409122435.GK5047@S2101-09.ap.freescale.net>
References: <20130409122435.GK5047@S2101-09.ap.freescale.net>
Message-ID: <201304091458.03811.arnd@arndb.de>

On Tuesday 09 April 2013, Shawn Guo wrote:
> The imx fixes for 3.9, take 5:
> 
> * A couple imx35 clock fixes for regressions caused by common clock
>   framework conversion.  The admux and iomux get disabled by common
>   clock framework late initcall, and hence causes problems.
> * Add missing twd clock lookup in device tree.  This becomes required
>   since commit bd60345 (ARM: use device tree to get smp_twd clock)
>   forces all DT boot to find lookup from device tree.
> * Fix imx6q ldb_di clock parents mismatch per reference manual.

Pulled into the fixes branch now, thanks for following up on this,
I didn't have any of them on my radar.

	Arnd


From sameo at linux.intel.com  Tue Apr  9 09:00:52 2013
From: sameo at linux.intel.com (Samuel Ortiz)
Date: Tue, 9 Apr 2013 15:00:52 +0200
Subject: [PATCH 2/2] mfd: db8500-prcmu: Support platform dependant device
 selection
In-Reply-To: <20130409100609.GQ24058@zurbaran>
References: <1365071941-23475-1-git-send-email-lee.jones@linaro.org>
 <1365071941-23475-2-git-send-email-lee.jones@linaro.org>
 <20130409100609.GQ24058@zurbaran>
Message-ID: <20130409130052.GA9172@zurbaran>

In case you did not get this one...

On Tue, Apr 09, 2013 at 12:06:09PM +0200, Samuel Ortiz wrote:
> Hi Lee,
> 
> On Thu, Apr 04, 2013 at 11:39:01AM +0100, Lee Jones wrote:
> > The main aim for this cycle is to have the u8540 booting to a
> > console. However, the u8540 doesn't support all of the u8500
> > platform devices yet. After this stage is complete we can then
> > fill in the inadequacies, such as specific clock support at a
> > later date. To achieve this we're placing devices supported by
> > all platforms into a common device structure and the remaining
> > ones into a platform specific one.
> > 
> > Cc: Samuel Ortiz <sameo at linux.intel.com>
> > Signed-off-by: Lee Jones <lee.jones at linaro.org>
> > ---
> >  drivers/mfd/db8500-prcmu.c |   52 ++++++++++++++++++++++++++++----------------
> >  1 file changed, 33 insertions(+), 19 deletions(-)
> This one does not apply (not even manually) on top of mfd-next. Would you mind
> rebasing it (And adding Linus' ACK) ?
> 
> Cheers,
> Samuel.
> 
> -- 
> Intel Open Source Technology Centre
> http://oss.intel.com/

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


From shawn.guo at linaro.org  Tue Apr  9 09:08:26 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 9 Apr 2013 21:08:26 +0800
Subject: [PATCH 1/2] ARM i.MX53: remove platform ahci support
In-Reply-To: <1365490703-1852-1-git-send-email-s.hauer@pengutronix.de>
References: <1365490703-1852-1-git-send-email-s.hauer@pengutronix.de>
Message-ID: <20130409130824.GJ5044@S2101-09.ap.freescale.net>

On Tue, Apr 09, 2013 at 08:58:22AM +0200, Sascha Hauer wrote:
> The i.MX53 ahci platform support is unused in mainline. To demotivate
> people using it just remove it from the tree.
> 
> Signed-off-by: Sascha Hauer <s.hauer at pengutronix.de>

Both applied, thanks.



From robherring2 at gmail.com  Tue Apr  9 09:09:54 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Tue, 09 Apr 2013 08:09:54 -0500
Subject: multi-platform broken in -next
Message-ID: <51641322.6000508@gmail.com>

Arnd,

Looks like cns3xxx changes broke multi-platform builds in todays
linux-next tree:

+ make -j4 ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- zImage dtbs
scripts/kconfig/conf --silentoldconfig Kconfig
arch/arm/mach-cns3xxx/Kconfig:2:warning: choice value used outside its
choice group
arch/arm/mach-bcm2835/Kconfig:2:warning: choice value used outside its
choice group
arch/arm/Kconfig:287:error: recursive dependency detected!
arch/arm/Kconfig:287:	choice <choice> contains symbol ARCH_CNS3XXX
arch/arm/Kconfig:366:	symbol ARCH_CNS3XXX depends on ARCH_MULTI_V6
arch/arm/Kconfig:933:	symbol ARCH_MULTI_V6 depends on ARCH_MULTIPLATFORM
arch/arm/Kconfig:292:	symbol ARCH_MULTIPLATFORM is part of choice <choice>
  WRAP    arch/arm/include/generated/asm/auxvec.h
  WRAP    arch/arm/include/generated/asm/bitsperlong.h

Rob


From arnd at arndb.de  Tue Apr  9 09:13:58 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 9 Apr 2013 15:13:58 +0200
Subject: [GIT PULL 2/8] ARM: tegra: minor fixes
In-Reply-To: <1365181426-11547-2-git-send-email-swarren@wwwdotorg.org>
References: <1365181426-11547-1-git-send-email-swarren@wwwdotorg.org>
 <1365181426-11547-2-git-send-email-swarren@wwwdotorg.org>
Message-ID: <201304091513.58302.arnd@arndb.de>

On Friday 05 April 2013, Stephen Warren wrote:
> This branch contains a variety of small build and run-time fixes that
> weren't important enough for 3.9.
> 
> * Enable CPU errata WARs in secondary reset handler as a preparation
>   for multi-platform support, and a related fix.
> * Don't touch DBLGAR in reset/resume handlers, so enable the code to
>   run on A15 cores.
> * Minor build fixes.
> * A fix to the Tegra clock driver.
> * Some error-handling fixes.
> 
> This branch is based on the previous fixes-for-mmc pull request.
> 

Pulled into next/fixes-non-critical, thanks!

	Arnd


From pawel.moll at arm.com  Tue Apr  9 09:17:50 2013
From: pawel.moll at arm.com (Pawel Moll)
Date: Tue,  9 Apr 2013 14:17:50 +0100
Subject: [PATCH] ARM: vexpress: Remove A9 PMU compatible values for non-A9
 platforms
Message-ID: <1365513470-2680-1-git-send-email-pawel.moll@arm.com>

The ARM perf core code used to rely on the pmu node being
compatible with "arm,cortex-a9-pmu", even when the PMUs
of the different Cortex-A processors are not really
compatible... This is no longer required and actually
became harmful, so remove all the offending values
from Versatile Express DTS files.

Signed-off-by: Pawel Moll <pawel.moll at arm.com>
---
Hello Arnd, Olof,

Could you please add this patch to your fixes branch for 3.10 or
to pull from the tag below?

Thanks,

Pawel

The following changes since commit f011a08c804d50eeff4abf2d308cdce492f015aa:

  Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/sfr/next-fixes (2013-04-08 16:10:43 -0700)

are available in the git repository at:


  git://git.linaro.org/people/pawelmoll/linux.git tags/vexpress/fixes-for-3.10

for you to fetch changes up to a8baa6ab9cfe01f16f08fdae22796a21ee2ab21d:

  ARM: vexpress: Remove A9 PMU compatible values for non-A9 platforms (2013-04-09 14:03:51 +0100)

----------------------------------------------------------------
Versatile Express fixes for 3.10:
* Fix PMU compatible values in non-A9 DTSes

----------------------------------------------------------------

 arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts |    2 +-
 arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts  |    2 +-
 arch/arm/boot/dts/vexpress-v2p-ca5s.dts     |    2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts b/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
index 7318717..9420053 100644
--- a/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
+++ b/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
@@ -117,7 +117,7 @@
 	};
 
 	pmu {
-		compatible = "arm,cortex-a15-pmu", "arm,cortex-a9-pmu";
+		compatible = "arm,cortex-a15-pmu";
 		interrupts = <0 68 4>,
 			     <0 69 4>;
 	};
diff --git a/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts b/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
index dfe371e..d2803be 100644
--- a/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
+++ b/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
@@ -134,7 +134,7 @@
 	};
 
 	pmu {
-		compatible = "arm,cortex-a15-pmu", "arm,cortex-a9-pmu";
+		compatible = "arm,cortex-a15-pmu";
 		interrupts = <0 68 4>,
 			     <0 69 4>;
 	};
diff --git a/arch/arm/boot/dts/vexpress-v2p-ca5s.dts b/arch/arm/boot/dts/vexpress-v2p-ca5s.dts
index 6328cbc..c544a55 100644
--- a/arch/arm/boot/dts/vexpress-v2p-ca5s.dts
+++ b/arch/arm/boot/dts/vexpress-v2p-ca5s.dts
@@ -111,7 +111,7 @@
 	};
 
 	pmu {
-		compatible = "arm,cortex-a5-pmu", "arm,cortex-a9-pmu";
+		compatible = "arm,cortex-a5-pmu";
 		interrupts = <0 68 4>,
 			     <0 69 4>;
 	};
-- 
1.7.10.4




From horms at verge.net.au  Tue Apr  9 09:25:35 2013
From: horms at verge.net.au (Simon Horman)
Date: Tue, 9 Apr 2013 22:25:35 +0900
Subject: [PATCH 2/2] ARM: shmobile: sh73a0: Suspend-to-RAM Power Off mode
In-Reply-To: <1363872697-11267-3-git-send-email-hechtb+renesas@gmail.com>
References: <1363872697-11267-1-git-send-email-hechtb+renesas@gmail.com>
 <1363872697-11267-3-git-send-email-hechtb+renesas@gmail.com>
Message-ID: <20130409132534.GB21045@verge.net.au>

On ?,  3? 21, 2013 at 02:31:37?? +0100, Bastian Hecht wrote:
> We add Power Off mode defined by the ARM architecture as our
> Suspend-to-RAM mechanism. Here the L2 cache keeps its power and we only
> take care to flush the L1. Different startup paths are added for the two
> CPUs, one leading to cpu_resume() and the other to secondary_startup().
> 
> Signed-off-by: Bastian Hecht <hechtb+renesas at gmail.com>

Bastian, could you please let me know about the status of this patch?
Is it awaiting review?

> ---
>  arch/arm/mach-shmobile/Makefile              |    2 +-
>  arch/arm/mach-shmobile/headsmp-sh73a0.S      |   72 ++++++++++++++++++++++++++
>  arch/arm/mach-shmobile/include/mach/common.h |    1 +
>  arch/arm/mach-shmobile/pm-sh73a0.c           |   32 ++++++++++--
>  arch/arm/mach-shmobile/smp-sh73a0.c          |    9 +++-
>  5 files changed, 109 insertions(+), 7 deletions(-)
>  create mode 100644 arch/arm/mach-shmobile/headsmp-sh73a0.S
> 
> diff --git a/arch/arm/mach-shmobile/Makefile b/arch/arm/mach-shmobile/Makefile
> index c621edf..1d33d89 100644
> --- a/arch/arm/mach-shmobile/Makefile
> +++ b/arch/arm/mach-shmobile/Makefile
> @@ -14,7 +14,7 @@ obj-$(CONFIG_ARCH_EMEV2)	+= setup-emev2.o clock-emev2.o
>  
>  # SMP objects
>  smp-y				:= platsmp.o headsmp.o
> -smp-$(CONFIG_ARCH_SH73A0)	+= smp-sh73a0.o headsmp-scu.o
> +smp-$(CONFIG_ARCH_SH73A0)	+= smp-sh73a0.o headsmp-sh73a0.o headsmp-scu.o
>  smp-$(CONFIG_ARCH_R8A7779)	+= smp-r8a7779.o headsmp-scu.o
>  smp-$(CONFIG_ARCH_EMEV2)	+= smp-emev2.o headsmp-scu.o
>  
> diff --git a/arch/arm/mach-shmobile/headsmp-sh73a0.S b/arch/arm/mach-shmobile/headsmp-sh73a0.S
> new file mode 100644
> index 0000000..6ffed46
> --- /dev/null
> +++ b/arch/arm/mach-shmobile/headsmp-sh73a0.S
> @@ -0,0 +1,72 @@
> +/*
> + * SMP support for SoC sh73a0
> + *
> + * Copyright (C) 2013 Bastian Hecht
> + *
> + * 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/linkage.h>
> +#include <linux/init.h>
> +#include <asm/memory.h>
> +
> +        __CPUINIT
> +
> +ENTRY(sh73a0_primary_resume)
> +        bl      v7_invalidate_l1
> +        b       cpu_resume
> +ENDPROC(sh73a0_primary_resume)
> +
> +ENTRY(sh73a0_secondary_startup)
> +        bl      v7_invalidate_l1
> +        b       secondary_startup
> +ENDPROC(sh73a0_primary_resume)
> +
> +/*
> + * Reset vector for both CPUs.
> + *
> + * This function will be mapped to address 0 by the SBAR register and is the
> + * general wakeup vector.
> + * For both CPUs we need to set the SCU power flag to Run Mode and invalidate
> + * the L1 cache so no random data get flushed out later.
> + * We can't use v7_invalidate_l1() directly as a normal branch is out of range
> + * here and so we need a long jump. We jump to the physical address as the
> + * MMU is still turned off.
> + *
> + * We do not need to worry about CPU1 running ahead of CPU0 as the secondary
> + * CPU of the sh73a0 needs to be woken using the WUPCR register. This is done
> + * in sh73a0_boot_secondary().
> + */
> +        .align  12
> +ENTRY(sh73a0_reset_vector)
> +        /* Retrieve the CPU ID and keep it in r4 */
> +        mrc     p15, 0, r4, c0, c0, 5   @ read MIPDR
> +        and     r4, r4, #3              @ mask out cpu ID
> +
> +        /*
> +         * We clear the SCU Power status flag to prepare for the
> +         * L1 coherency mode
> +         */
> +        mov     r0, r4                  @ copy CPU ID
> +        lsl     r0, r0, #3              @ we will shift by cpu_id * 8 bits
> +	ldr	r1, 3f
> +	ldr	r1, [r1]		@ SCU base address
> +        ldr     r2, [r1, #8]            @ SCU Power Status Register
> +        mov     r3, #3
> +        bic     r2, r2, r3, lsl r0      @ Clear bits of our CPU (Run Mode)
> +        str     r2, [r1, #8]            @ write back
> +
> +        /*
> +         * Depending on the CPU ID we either resume our primary core from
> +         * sleeping or bring up the secondary CPU
> +         */
> +        cmp     r4, #0                  @ if CPU0
> +        ldreq   pc, 1f                  @ jump to sh73a0_primary_resume
> +        ldr     pc, 2f                  @ jump to sh73a0_secondary_startup
> +
> +1:      .long   sh73a0_primary_resume - PAGE_OFFSET + PLAT_PHYS_OFFSET
> +2:      .long   sh73a0_secondary_startup - PAGE_OFFSET + PLAT_PHYS_OFFSET
> +3:      .long	shmobile_scu_base - PAGE_OFFSET + PLAT_PHYS_OFFSET
> +ENDPROC(sh73a0_reset_vector)
> diff --git a/arch/arm/mach-shmobile/include/mach/common.h b/arch/arm/mach-shmobile/include/mach/common.h
> index 03f73de..842bb35 100644
> --- a/arch/arm/mach-shmobile/include/mach/common.h
> +++ b/arch/arm/mach-shmobile/include/mach/common.h
> @@ -45,6 +45,7 @@ extern void sh73a0_add_standard_devices_dt(void);
>  extern void sh73a0_clock_init(void);
>  extern void sh73a0_pinmux_init(void);
>  extern void sh73a0_pm_init(void);
> +extern void sh73a0_reset_vector(void);
>  extern struct clk sh73a0_extal1_clk;
>  extern struct clk sh73a0_extal2_clk;
>  extern struct clk sh73a0_extcki_clk;
> diff --git a/arch/arm/mach-shmobile/pm-sh73a0.c b/arch/arm/mach-shmobile/pm-sh73a0.c
> index 99086e9..7e8e0a1 100644
> --- a/arch/arm/mach-shmobile/pm-sh73a0.c
> +++ b/arch/arm/mach-shmobile/pm-sh73a0.c
> @@ -1,30 +1,54 @@
>  /*
>   * sh73a0 Power management support
>   *
> - *  Copyright (C) 2012 Bastian Hecht <hechtb+renesas at gmail.com>
> + *  Copyright (C) 2013 Bastian Hecht <hechtb+renesas at gmail.com>
>   *
>   * This file is subject to the terms and conditions of the GNU General Public
>   * License.  See the file "COPYING" in the main directory of this archive
>   * for more details.
>   */
>  
> +#include <linux/cpuidle.h>
> +#include <linux/module.h>
>  #include <linux/suspend.h>
> +#include <linux/io.h>
> +#include <asm/cacheflush.h>
> +#include <asm/smp_scu.h>
> +#include <asm/suspend.h>
>  #include <mach/common.h>
>  
>  #ifdef CONFIG_SUSPEND
> -static int sh73a0_enter_suspend(suspend_state_t suspend_state)
> +/*
> + * sh73a0_do_poweroff: Power off the main CPU
> + *
> + * The L2 cache doesn't loose power in Power Off mode - ignore it.
> + * After flushing the L1 cache we don't take care to disable it as we
> + * only work on temporary values in a UP environment and it gets invalidated
> + * on startup. Just straight take down the ARM core.
> + */
> +static int sh73a0_do_poweroff(unsigned long unused)
>  {
> +	flush_cache_all();
> +	scu_power_mode(shmobile_scu_base, SCU_PM_POWEROFF);
>  	cpu_do_idle();
> +
> +	return 0;
> +}
> +
> +static int sh73a0_enter_poweroff_suspend(suspend_state_t suspend_state)
> +{
> +	cpu_suspend(0, sh73a0_do_poweroff);
> +
>  	return 0;
>  }
>  
>  static void sh73a0_suspend_init(void)
>  {
> -	shmobile_suspend_ops.enter = sh73a0_enter_suspend;
> +	shmobile_suspend_ops.enter = sh73a0_enter_poweroff_suspend;
>  }
>  #else
>  static void sh73a0_suspend_init(void) {}
> -#endif
> +#endif	/* CONFIG_SUSPEND */
>  
>  void __init sh73a0_pm_init(void)
>  {
> diff --git a/arch/arm/mach-shmobile/smp-sh73a0.c b/arch/arm/mach-shmobile/smp-sh73a0.c
> index 5ae502b..348714e 100644
> --- a/arch/arm/mach-shmobile/smp-sh73a0.c
> +++ b/arch/arm/mach-shmobile/smp-sh73a0.c
> @@ -70,9 +70,14 @@ static void __init sh73a0_smp_prepare_cpus(unsigned int max_cpus)
>  {
>  	scu_enable(shmobile_scu_base);
>  
> -	/* Map the reset vector (in headsmp-scu.S) */
> +	/*
> +	 * Map the general reset vector that is hit from multiple paths:
> +	 * - Primary CPU resume at wakeup time
> +	 * - Secondary startup at boot time
> +	 * - Secondary startup at wakeup time
> +	 */
>  	__raw_writel(0, APARMBAREA);      /* 4k */
> -	__raw_writel(__pa(shmobile_secondary_vector_scu), SBAR);
> +	__raw_writel(__pa(sh73a0_reset_vector), SBAR);
>  
>  	/* enable cache coherency on booting CPU */
>  	scu_power_mode(shmobile_scu_base, SCU_PM_NORMAL);
> -- 
> 1.7.9.5
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


From nicolas.ferre at atmel.com  Tue Apr  9 09:31:24 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Tue, 9 Apr 2013 15:31:24 +0200
Subject: [PATCH] ARM: at91: change "Unknown" qualifier SoC subtype handling
Message-ID: <1365514284-21624-1-git-send-email-nicolas.ferre@atmel.com>

An AT91 SoC that doesn't have a subtype is shown as "Unknown"
in the Linux log message which is not correct.
This was leading to confusion so, add a "none" qualifier to
the subtype property and set this one in the appropriate cases.

Signed-off-by: Nicolas Ferre <nicolas.ferre at atmel.com>
---
 arch/arm/mach-at91/include/mach/cpu.h |  9 ++++++---
 arch/arm/mach-at91/setup.c            | 22 +++++++++++++++-------
 2 files changed, 21 insertions(+), 10 deletions(-)

diff --git a/arch/arm/mach-at91/include/mach/cpu.h b/arch/arm/mach-at91/include/mach/cpu.h
index 0f3379f..d3d7b99 100644
--- a/arch/arm/mach-at91/include/mach/cpu.h
+++ b/arch/arm/mach-at91/include/mach/cpu.h
@@ -86,7 +86,7 @@ enum at91_soc_type {
 	AT91_SOC_SAMA5D3,
 
 	/* Unknown type */
-	AT91_SOC_NONE
+	AT91_SOC_UNKNOWN,
 };
 
 enum at91_soc_subtype {
@@ -107,8 +107,11 @@ enum at91_soc_subtype {
 	AT91_SOC_SAMA5D31, AT91_SOC_SAMA5D33, AT91_SOC_SAMA5D34,
 	AT91_SOC_SAMA5D35,
 
+	/* No subtype for this SoC */
+	AT91_SOC_SUBTYPE_NONE,
+
 	/* Unknown subtype */
-	AT91_SOC_SUBTYPE_NONE
+	AT91_SOC_SUBTYPE_UNKNOWN,
 };
 
 struct at91_socinfo {
@@ -122,7 +125,7 @@ const char *at91_get_soc_subtype(struct at91_socinfo *c);
 
 static inline int at91_soc_is_detected(void)
 {
-	return at91_soc_initdata.type != AT91_SOC_NONE;
+	return at91_soc_initdata.type != AT91_SOC_UNKNOWN;
 }
 
 #ifdef CONFIG_SOC_AT91RM9200
diff --git a/arch/arm/mach-at91/setup.c b/arch/arm/mach-at91/setup.c
index 2ecd169..fd00a09 100644
--- a/arch/arm/mach-at91/setup.c
+++ b/arch/arm/mach-at91/setup.c
@@ -105,28 +105,32 @@ static void __init soc_detect(u32 dbgu_base)
 	switch (socid) {
 	case ARCH_ID_AT91RM9200:
 		at91_soc_initdata.type = AT91_SOC_RM9200;
-		if (at91_soc_initdata.subtype == AT91_SOC_SUBTYPE_NONE)
+		if (at91_soc_initdata.subtype == AT91_SOC_SUBTYPE_UNKNOWN)
 			at91_soc_initdata.subtype = AT91_SOC_RM9200_BGA;
 		at91_boot_soc = at91rm9200_soc;
 		break;
 
 	case ARCH_ID_AT91SAM9260:
 		at91_soc_initdata.type = AT91_SOC_SAM9260;
+		at91_soc_initdata.subtype = AT91_SOC_SUBTYPE_NONE;
 		at91_boot_soc = at91sam9260_soc;
 		break;
 
 	case ARCH_ID_AT91SAM9261:
 		at91_soc_initdata.type = AT91_SOC_SAM9261;
+		at91_soc_initdata.subtype = AT91_SOC_SUBTYPE_NONE;
 		at91_boot_soc = at91sam9261_soc;
 		break;
 
 	case ARCH_ID_AT91SAM9263:
 		at91_soc_initdata.type = AT91_SOC_SAM9263;
+		at91_soc_initdata.subtype = AT91_SOC_SUBTYPE_NONE;
 		at91_boot_soc = at91sam9263_soc;
 		break;
 
 	case ARCH_ID_AT91SAM9G20:
 		at91_soc_initdata.type = AT91_SOC_SAM9G20;
+		at91_soc_initdata.subtype = AT91_SOC_SUBTYPE_NONE;
 		at91_boot_soc = at91sam9260_soc;
 		break;
 
@@ -139,6 +143,7 @@ static void __init soc_detect(u32 dbgu_base)
 
 	case ARCH_ID_AT91SAM9RL64:
 		at91_soc_initdata.type = AT91_SOC_SAM9RL;
+		at91_soc_initdata.subtype = AT91_SOC_SUBTYPE_NONE;
 		at91_boot_soc = at91sam9rl_soc;
 		break;
 
@@ -161,6 +166,7 @@ static void __init soc_detect(u32 dbgu_base)
 	/* at91sam9g10 */
 	if ((socid & ~AT91_CIDR_EXT) == ARCH_ID_AT91SAM9G10) {
 		at91_soc_initdata.type = AT91_SOC_SAM9G10;
+		at91_soc_initdata.subtype = AT91_SOC_SUBTYPE_NONE;
 		at91_boot_soc = at91sam9261_soc;
 	}
 	/* at91sam9xe */
@@ -242,7 +248,7 @@ static const char *soc_name[] = {
 	[AT91_SOC_SAM9X5]	= "at91sam9x5",
 	[AT91_SOC_SAM9N12]	= "at91sam9n12",
 	[AT91_SOC_SAMA5D3]	= "sama5d3",
-	[AT91_SOC_NONE]		= "Unknown"
+	[AT91_SOC_UNKNOWN]	= "Unknown",
 };
 
 const char *at91_get_soc_type(struct at91_socinfo *c)
@@ -268,7 +274,8 @@ static const char *soc_subtype_name[] = {
 	[AT91_SOC_SAMA5D33]	= "sama5d33",
 	[AT91_SOC_SAMA5D34]	= "sama5d34",
 	[AT91_SOC_SAMA5D35]	= "sama5d35",
-	[AT91_SOC_SUBTYPE_NONE]	= "Unknown"
+	[AT91_SOC_SUBTYPE_NONE]	= "None",
+	[AT91_SOC_SUBTYPE_UNKNOWN] = "Unknown",
 };
 
 const char *at91_get_soc_subtype(struct at91_socinfo *c)
@@ -282,8 +289,8 @@ void __init at91_map_io(void)
 	/* Map peripherals */
 	iotable_init(&at91_io_desc, 1);
 
-	at91_soc_initdata.type = AT91_SOC_NONE;
-	at91_soc_initdata.subtype = AT91_SOC_SUBTYPE_NONE;
+	at91_soc_initdata.type = AT91_SOC_UNKNOWN;
+	at91_soc_initdata.subtype = AT91_SOC_SUBTYPE_UNKNOWN;
 
 	soc_detect(AT91_BASE_DBGU0);
 	if (!at91_soc_is_detected())
@@ -294,8 +301,9 @@ void __init at91_map_io(void)
 
 	pr_info("AT91: Detected soc type: %s\n",
 		at91_get_soc_type(&at91_soc_initdata));
-	pr_info("AT91: Detected soc subtype: %s\n",
-		at91_get_soc_subtype(&at91_soc_initdata));
+	if (at91_soc_initdata.subtype != AT91_SOC_SUBTYPE_NONE)
+		pr_info("AT91: Detected soc subtype: %s\n",
+			at91_get_soc_subtype(&at91_soc_initdata));
 
 	if (!at91_soc_is_enabled())
 		panic("AT91: Soc not enabled");
-- 
1.8.0



From horms at verge.net.au  Tue Apr  9 09:38:06 2013
From: horms at verge.net.au (Simon Horman)
Date: Tue, 9 Apr 2013 22:38:06 +0900
Subject: [PATCH v3 2/7] clocksource: sh_cmt: Add OF support
In-Reply-To: <20130321130714.GE24470@verge.net.au>
References: <1363535031-21402-1-git-send-email-hechtb+renesas@gmail.com>
 <1363535031-21402-2-git-send-email-hechtb+renesas@gmail.com>
 <20130321130714.GE24470@verge.net.au>
Message-ID: <20130409133805.GA21875@verge.net.au>

On ?,  3? 21, 2013 at 10:07:15?? +0900, Simon Horman wrote:
> On Sun, Mar 17, 2013 at 04:43:46PM +0100, Bastian Hecht wrote:
> > We add the capabilty to probe SH CMT timer devices using Device Tree
> > setup.
> > 
> > Signed-off-by: Bastian Hecht <hechtb+renesas at gmail.com>
> > ---
> > v3: same (only patch 0003 changed)
> > 
> >  drivers/clocksource/sh_cmt.c |  109 +++++++++++++++++++++++++++++++++++++-----
> 
> 
> This change appears to break booting of kzm9g-reference
> with MMC enabled. I assume because it somehow causes CMT to
> (once again) be initialised after SDHI and/or MMC.
> 
> Tested using next with the defconfig + CONFIG_MACH_KZM9G_REFERENCE=y +
> initrd root fs.

Ping.

> >  1 file changed, 96 insertions(+), 13 deletions(-)
> > 
> > diff --git a/drivers/clocksource/sh_cmt.c b/drivers/clocksource/sh_cmt.c
> > index 08d0c41..79bc526 100644
> > --- a/drivers/clocksource/sh_cmt.c
> > +++ b/drivers/clocksource/sh_cmt.c
> > @@ -34,10 +34,13 @@
> >  #include <linux/module.h>
> >  #include <linux/pm_domain.h>
> >  #include <linux/pm_runtime.h>
> > +#include <linux/of.h>
> >  
> >  struct sh_cmt_priv {
> >  	void __iomem *mapbase;
> >  	struct clk *clk;
> > +	long channel_offset;
> > +	int timer_bit;
> >  	unsigned long width; /* 16 or 32 bit version of hardware block */
> >  	unsigned long overflow_bit;
> >  	unsigned long clear_bits;
> > @@ -109,9 +112,7 @@ static void sh_cmt_write32(void __iomem *base, unsigned long offs,
> >  
> >  static inline unsigned long sh_cmt_read_cmstr(struct sh_cmt_priv *p)
> >  {
> > -	struct sh_timer_config *cfg = p->pdev->dev.platform_data;
> > -
> > -	return p->read_control(p->mapbase - cfg->channel_offset, 0);
> > +	return p->read_control(p->mapbase - p->channel_offset, 0);
> >  }
> >  
> >  static inline unsigned long sh_cmt_read_cmcsr(struct sh_cmt_priv *p)
> > @@ -127,9 +128,7 @@ static inline unsigned long sh_cmt_read_cmcnt(struct sh_cmt_priv *p)
> >  static inline void sh_cmt_write_cmstr(struct sh_cmt_priv *p,
> >  				      unsigned long value)
> >  {
> > -	struct sh_timer_config *cfg = p->pdev->dev.platform_data;
> > -
> > -	p->write_control(p->mapbase - cfg->channel_offset, 0, value);
> > +	p->write_control(p->mapbase - p->channel_offset, 0, value);
> >  }
> >  
> >  static inline void sh_cmt_write_cmcsr(struct sh_cmt_priv *p,
> > @@ -176,7 +175,6 @@ static DEFINE_RAW_SPINLOCK(sh_cmt_lock);
> >  
> >  static void sh_cmt_start_stop_ch(struct sh_cmt_priv *p, int start)
> >  {
> > -	struct sh_timer_config *cfg = p->pdev->dev.platform_data;
> >  	unsigned long flags, value;
> >  
> >  	/* start stop register shared by multiple timer channels */
> > @@ -184,9 +182,9 @@ static void sh_cmt_start_stop_ch(struct sh_cmt_priv *p, int start)
> >  	value = sh_cmt_read_cmstr(p);
> >  
> >  	if (start)
> > -		value |= 1 << cfg->timer_bit;
> > +		value |= 1 << p->timer_bit;
> >  	else
> > -		value &= ~(1 << cfg->timer_bit);
> > +		value &= ~(1 << p->timer_bit);
> >  
> >  	sh_cmt_write_cmstr(p, value);
> >  	raw_spin_unlock_irqrestore(&sh_cmt_lock, flags);
> > @@ -673,9 +671,85 @@ static int sh_cmt_register(struct sh_cmt_priv *p, char *name,
> >  	return 0;
> >  }
> >  
> > -static int sh_cmt_setup(struct sh_cmt_priv *p, struct platform_device *pdev)
> > +static const struct of_device_id of_sh_cmt_match[] = {
> > +	{ .compatible = "renesas,cmt-timer" },
> > +	{},
> > +};
> > +MODULE_DEVICE_TABLE(of, of_sh_cmt_match);
> > +
> > +static const int sh_cmt_offset_multiplier[] = { 0x60, 0x10, 0x40, 0x40, 0x40 };
> > +#define CMT_MAX_CHANNELS	6
> > +
> > +static struct sh_timer_config *sh_cmt_parse_dt(struct device *dev)
> > +{
> > +	struct sh_timer_config *cfg;
> > +	struct device_node *np = dev->of_node;
> > +	u32 timer_id, channel_id, rating;
> > +
> > +	if (!IS_ENABLED(CONFIG_OF) || !np)
> > +		return NULL;
> > +
> > +	cfg = devm_kzalloc(dev, sizeof(struct sh_timer_config), GFP_KERNEL);
> > +	if (!cfg) {
> > +		dev_err(dev, "failed to allocate DT config data\n");
> > +		return NULL;
> > +	}
> > +
> > +	if (of_property_read_u32(np, "renesas,device-id", &timer_id)) {
> > +		dev_err(dev, "device id missing\n");
> > +		return NULL;
> > +	}
> > +	if (timer_id >= ARRAY_SIZE(sh_cmt_offset_multiplier)) {
> > +		dev_err(dev, "invalid device id\n");
> > +		return NULL;
> > +	}
> > +
> > +	if (of_property_read_u32(np, "renesas,channel-id", &channel_id)) {
> > +		dev_err(dev, "channel id missing\n");
> > +		return NULL;
> > +	}
> > +	if (channel_id >= CMT_MAX_CHANNELS) {
> > +		dev_err(dev, "invalid channel id\n");
> > +		return NULL;
> > +	}
> > +
> > +	cfg->channel_offset = sh_cmt_offset_multiplier[timer_id] *
> > +							(channel_id + 1);
> > +	cfg->timer_bit = channel_id;
> > +
> > +	/*
> > +	 * We convert the {source,event}-quality DT properties to linux specific
> > +	 * clock{source,event}_ratings.
> > +	 */
> > +	if (!of_property_read_u32(np, "renesas,source-quality", &rating)) {
> > +		if (rating > 10) {
> > +			dev_err(dev, "invalid source-quality\n");
> > +			return NULL;
> > +		}
> > +		if (rating)
> > +			cfg->clocksource_rating = rating * 50 - 1;
> > +	}
> > +
> > +	if (!of_property_read_u32(np, "renesas,event-quality", &rating)) {
> > +		if (rating > 10) {
> > +			dev_err(dev, "invalid event-quality\n");
> > +			return NULL;
> > +		}
> > +		if (rating)
> > +			cfg->clockevent_rating = rating * 50 - 1;
> > +	}
> > +
> > +	if (!cfg->clocksource_rating && !cfg->clockevent_rating) {
> > +		dev_err(dev, "source- and event-quality 0, timer is unused\n");
> > +		return NULL;
> > +	}
> > +
> > +	return cfg;
> > +}
> > +
> > +static int sh_cmt_setup(struct sh_cmt_priv *p, struct platform_device *pdev,
> > +						struct sh_timer_config *cfg)
> >  {
> > -	struct sh_timer_config *cfg = pdev->dev.platform_data;
> >  	struct resource *res;
> >  	int irq, ret;
> >  	ret = -ENXIO;
> > @@ -762,6 +836,9 @@ static int sh_cmt_setup(struct sh_cmt_priv *p, struct platform_device *pdev)
> >  		goto err2;
> >  	}
> >  
> > +	p->channel_offset = cfg->channel_offset;
> > +	p->timer_bit = cfg->timer_bit;
> > +
> >  	platform_set_drvdata(pdev, p);
> >  
> >  	return 0;
> > @@ -777,7 +854,7 @@ err0:
> >  static int sh_cmt_probe(struct platform_device *pdev)
> >  {
> >  	struct sh_cmt_priv *p = platform_get_drvdata(pdev);
> > -	struct sh_timer_config *cfg = pdev->dev.platform_data;
> > +	struct sh_timer_config *cfg;
> >  	int ret;
> >  
> >  	if (!is_early_platform_device(pdev)) {
> > @@ -785,6 +862,11 @@ static int sh_cmt_probe(struct platform_device *pdev)
> >  		pm_runtime_enable(&pdev->dev);
> >  	}
> >  
> > +	if (pdev->dev.of_node)
> > +		cfg = sh_cmt_parse_dt(&pdev->dev);
> > +	else
> > +		cfg = pdev->dev.platform_data;
> > +
> >  	if (p) {
> >  		dev_info(&pdev->dev, "kept as earlytimer\n");
> >  		goto out;
> > @@ -796,7 +878,7 @@ static int sh_cmt_probe(struct platform_device *pdev)
> >  		return -ENOMEM;
> >  	}
> >  
> > -	ret = sh_cmt_setup(p, pdev);
> > +	ret = sh_cmt_setup(p, pdev, cfg);
> >  	if (ret) {
> >  		kfree(p);
> >  		pm_runtime_idle(&pdev->dev);
> > @@ -824,6 +906,7 @@ static struct platform_driver sh_cmt_device_driver = {
> >  	.remove		= sh_cmt_remove,
> >  	.driver		= {
> >  		.name	= "sh_cmt",
> > +		.of_match_table = of_match_ptr(of_sh_cmt_match),
> >  	}
> >  };
> >  
> > -- 
> > 1.7.9.5
> > 
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> > the body of a message to majordomo at vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


From arnd at arndb.de  Tue Apr  9 09:43:26 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 9 Apr 2013 15:43:26 +0200
Subject: [GIT PULL 1/5] omap pm fixes for v3.10 merge window
In-Reply-To: <pull-1365483063-475562>
References: <pull-1365483063-475562>
Message-ID: <201304091543.26551.arnd@arndb.de>

On Tuesday 09 April 2013, Tony Lindgren wrote:
> The following changes since commit c309f7f46167e85d1aae2fd31f23e7d2b5cdfbe0:
> 
>   Merge branch 'for_3.10/omap_generic_cleanup_v2' of git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux into omap-for-v3.10/cleanup-v2 (2013-03-28 14:45:31 -0700)
> 

Pulled into next/cleanup branch because of the dependency. Thanks,

	Arnd


From arnd at arndb.de  Tue Apr  9 09:44:32 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 9 Apr 2013 15:44:32 +0200
Subject: [GIT PULL 3/8] ARM: tegra: cleanup
In-Reply-To: <1365181426-11547-3-git-send-email-swarren@wwwdotorg.org>
References: <1365181426-11547-1-git-send-email-swarren@wwwdotorg.org>
 <1365181426-11547-3-git-send-email-swarren@wwwdotorg.org>
Message-ID: <201304091544.32377.arnd@arndb.de>

On Friday 05 April 2013, Stephen Warren wrote:
> This branch includes various cleanup of the core Tegra support.
> 
> * Unification of the separate board-dt-tegra*.c files into a single
>   tegra.c, now that everything is DT-driven and basically identical.
> * Use of_clk_get() in the Tegra clocksource driver so that clocks are
>   described in DT rather than hard-coding clock names.
> * Some cleanup of the PMC-related code, with the aim that the PMC
>   "driver" contains more of the code that touches PMC registers, rather
>   than spreading PMC register accesses through other files.
> * Conversion of the "PMC" driver to acquire resources describe in device
>   tree rather than hard-coding them.
> * Use of common code for the CPU sleep TLB invalidation.
> 

Pulled into next/cleanup branch and resolved the conflict against
an earlier cleanup that was already present there, fixup below.

	Arnd

--- a/drivers/clocksource/tegra20_timer.c
+++ b/drivers/clocksource/tegra20_timer.c
@@@ -218,34 -259,12 +218,34 @@@ static void __init tegra20_init_timer(s
        tegra_clockevent.irq = tegra_timer_irq.irq;
        clockevents_config_and_register(&tegra_clockevent, 1000000,
                                        0x1, 0x1fffffff);
 -#ifdef CONFIG_HAVE_ARM_TWD
 -      twd_local_timer_of_register();
 -#endif
 +}
 +CLOCKSOURCE_OF_DECLARE(tegra20_timer, "nvidia,tegra20-timer", tegra20_init_timer);
 +
 +static void __init tegra20_init_rtc(struct device_node *np)
 +{
 +      struct clk *clk;
 +
 +      rtc_base = of_iomap(np, 0);
 +      if (!rtc_base) {
 +              pr_err("Can't map RTC registers");
 +              BUG();
 +      }
 +
 +      /*
 +       * rtc registers are used by read_persistent_clock, keep the rtc clock
 +       * enabled
 +       */
-       clk = clk_get_sys("rtc-tegra", NULL);
++      clk = of_clk_get(np, 0);
 +      if (IS_ERR(clk))
 +              pr_warn("Unable to get rtc-tegra clock\n");
 +      else
 +              clk_prepare_enable(clk);
 +
 +      of_node_put(np);
 +
        register_persistent_clock(NULL, tegra_read_persistent_clock);
  }
 -CLOCKSOURCE_OF_DECLARE(tegra20, "nvidia,tegra20-timer", tegra20_init_timer);
 +CLOCKSOURCE_OF_DECLARE(tegra20_rtc, "nvidia,tegra20-rtc", tegra20_init_rtc);
  
  #ifdef CONFIG_PM
  static u32 usec_config;


From arnd at arndb.de  Tue Apr  9 09:44:53 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 9 Apr 2013 15:44:53 +0200
Subject: [GIT PULL 1/4] ARM: mxs: cleanup for 3.10
In-Reply-To: <1365411621-18422-1-git-send-email-shawn.guo@linaro.org>
References: <1365411621-18422-1-git-send-email-shawn.guo@linaro.org>
Message-ID: <201304091544.53671.arnd@arndb.de>

On Monday 08 April 2013, Shawn Guo wrote:
> Hi Arnd, Olof,
> 
> This is the mxs cleanup material for 3.10.  It's based on clksrc/cleanup
> branch in arm-soc tree.  Please pull, thanks.

Pulled into next/cleanup, thanks!

	Arnd


From arnd at arndb.de  Tue Apr  9 09:45:10 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 9 Apr 2013 15:45:10 +0200
Subject: [GIT PULL 01/10] cleanup-samsung for v3.10
In-Reply-To: <516309CF.6030202@samsung.com>
References: <516309CF.6030202@samsung.com>
Message-ID: <201304091545.10894.arnd@arndb.de>

On Monday 08 April 2013, Kukjin Kim wrote:
> The following changes since commit a937538b868b8369b98967929045f1df54234323:
> 
>    Linux 3.9-rc3 (2013-03-17 15:59:32 -0700)
> 
> are available in the git repository at:
> 
>    git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git 
> tags/cleanup-samsung-for-v3.10
> 
> for you to fetch changes up to fe72e27368265a99f6a0a189a5d593aac320a59d:
> 
>    ARM: EXYNOS: remove "config EXYNOS_DEV_DRM" (2013-04-09 00:32:38 +0900)

Pulled into next/cleanup, thanks!

	Arnd


From arnd at arndb.de  Tue Apr  9 09:45:25 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 9 Apr 2013 15:45:25 +0200
Subject: [GIT PULL] at91: little cleanup for 3.10 #3
In-Reply-To: <1365495607-30320-1-git-send-email-nicolas.ferre@atmel.com>
References: <1365495607-30320-1-git-send-email-nicolas.ferre@atmel.com>
Message-ID: <201304091545.25487.arnd@arndb.de>

On Tuesday 09 April 2013, Nicolas Ferre wrote:
> Arnd, Olof,
> 
> Again more trivial cleanup for AT91. It is based on material already sent and
> present in arm-soc/at91/cleanup2.

Pulled into next/cleanup, thanks!

	Arnd


From michal.bachraty at streamunlimited.com  Tue Apr  9 09:49:37 2013
From: michal.bachraty at streamunlimited.com (Michal Bachraty)
Date: Tue, 09 Apr 2013 15:49:37 +0200
Subject: [PATCH] clk: si5351: Add gapless tuning for SI5351 PLL
In-Reply-To: <CABJ1b_RW=UUxmTrYOsx2wsDm1egs9DL3dWtat0--5kqec9-rQA@mail.gmail.com>
References: <1365495975-792-1-git-send-email-michal.bachraty@streamunlimited.com>
 <CABJ1b_RW=UUxmTrYOsx2wsDm1egs9DL3dWtat0--5kqec9-rQA@mail.gmail.com>
Message-ID: <2031033.gNGydvIeAk@ganymedes>

Hi Sebastian,

> does gapless tuning have any constraints? Can we use it for all rate
> changes or determine the
> need for pll reset by rate offset?

Today I made some test measurements ( switching from 22.5MHz to 32kHz, then to 
50MHz, then to 1MHz) with good results: without any gaps and any side 
frequences.  So there are no constrains, and we can use it for any frequences. 

Best,
Michal



From emilio at elopez.com.ar  Tue Apr  9 09:48:01 2013
From: emilio at elopez.com.ar (=?UTF-8?q?Emilio=20L=C3=B3pez?=)
Date: Tue,  9 Apr 2013 10:48:01 -0300
Subject: [PATCH 0/3] sunxi: unify main oscillator and its gate
Message-ID: <1365515284-32061-1-git-send-email-emilio@elopez.com.ar>

Hi Mike,

As discussed previously when introducing the sunxi driver, this patchset
unifies the main oscillator ("osc24M_fixed") and its gate ("osc24M")
into a single clock ("osc24M"). It does so by adding fixed-rate support
into the composite clock and then using it to implement the new clock.

The changes shouldn't require any modifications on current/future users 
of the composite clock, although I haven't tested any to make sure of 
it. @Prashant, can I get a tested-by from you if necessary?

Thanks,

Emilio

Emilio L?pez (3):
  clk: composite: Add fixed-rate support
  clk: sunxi: Unify oscillator clock
  ARM: sunxi: unify osc24M_fixed and osc24M

 arch/arm/boot/dts/sunxi.dtsi  |  8 +-----
 drivers/clk/clk-composite.c   | 57 ++++++++++++++++++++++++++++++++++++++++---
 drivers/clk/sunxi/clk-sunxi.c | 30 +++++++++++++++++------
 include/linux/clk-provider.h  |  6 +++++
 4 files changed, 83 insertions(+), 18 deletions(-)

-- 
1.8.2.1



From emilio at elopez.com.ar  Tue Apr  9 09:48:02 2013
From: emilio at elopez.com.ar (=?UTF-8?q?Emilio=20L=C3=B3pez?=)
Date: Tue,  9 Apr 2013 10:48:02 -0300
Subject: [PATCH 1/3] clk: composite: Add fixed-rate support
In-Reply-To: <1365515284-32061-1-git-send-email-emilio@elopez.com.ar>
References: <1365515284-32061-1-git-send-email-emilio@elopez.com.ar>
Message-ID: <1365515284-32061-2-git-send-email-emilio@elopez.com.ar>

This patchset adds fixed-rate support to the composite clock, allowing
us to register gatable oscillators.

Signed-off-by: Emilio L?pez <emilio at elopez.com.ar>
---
 drivers/clk/clk-composite.c  | 57 ++++++++++++++++++++++++++++++++++++++++----
 include/linux/clk-provider.h |  6 +++++
 2 files changed, 59 insertions(+), 4 deletions(-)

diff --git a/drivers/clk/clk-composite.c b/drivers/clk/clk-composite.c
index 097dee4..5416e1d 100644
--- a/drivers/clk/clk-composite.c
+++ b/drivers/clk/clk-composite.c
@@ -43,8 +43,8 @@ static int clk_composite_set_parent(struct clk_hw *hw, u8 index)
 	return mux_ops->set_parent(mux_hw, index);
 }
 
-static unsigned long clk_composite_recalc_rate(struct clk_hw *hw,
-					    unsigned long parent_rate)
+static unsigned long clk_composite_recalc_rate_div(struct clk_hw *hw,
+						   unsigned long parent_rate)
 {
 	struct clk_composite *composite = to_clk_composite(hw);
 	const struct clk_ops *div_ops = composite->div_ops;
@@ -55,6 +55,18 @@ static unsigned long clk_composite_recalc_rate(struct clk_hw *hw,
 	return div_ops->recalc_rate(div_hw, parent_rate);
 }
 
+static unsigned long clk_composite_recalc_rate_fixed(struct clk_hw *hw,
+						     unsigned long parent_rate)
+{
+	struct clk_composite *composite = to_clk_composite(hw);
+	const struct clk_ops *fixed_ops = composite->fixed_ops;
+	struct clk_hw *fixed_hw = composite->fixed_hw;
+
+	fixed_hw->clk = hw->clk;
+
+	return fixed_ops->recalc_rate(fixed_hw, parent_rate);
+}
+
 static long clk_composite_round_rate(struct clk_hw *hw, unsigned long rate,
 				  unsigned long *prate)
 {
@@ -112,11 +124,12 @@ static void clk_composite_disable(struct clk_hw *hw)
 	gate_ops->disable(gate_hw);
 }
 
-struct clk *clk_register_composite(struct device *dev, const char *name,
+static struct clk *_clk_register_composite(struct device *dev, const char *name,
 			const char **parent_names, int num_parents,
 			struct clk_hw *mux_hw, const struct clk_ops *mux_ops,
 			struct clk_hw *div_hw, const struct clk_ops *div_ops,
 			struct clk_hw *gate_hw, const struct clk_ops *gate_ops,
+			struct clk_hw *fixed_hw, const struct clk_ops *fixed_ops,
 			unsigned long flags)
 {
 	struct clk *clk;
@@ -158,7 +171,7 @@ struct clk *clk_register_composite(struct device *dev, const char *name,
 
 		composite->div_hw = div_hw;
 		composite->div_ops = div_ops;
-		clk_composite_ops->recalc_rate = clk_composite_recalc_rate;
+		clk_composite_ops->recalc_rate = clk_composite_recalc_rate_div;
 		clk_composite_ops->round_rate = clk_composite_round_rate;
 		clk_composite_ops->set_rate = clk_composite_set_rate;
 	}
@@ -177,6 +190,17 @@ struct clk *clk_register_composite(struct device *dev, const char *name,
 		clk_composite_ops->disable = clk_composite_disable;
 	}
 
+	if (fixed_hw && fixed_ops) {
+		if (!fixed_ops->recalc_rate) {
+			clk = ERR_PTR(-EINVAL);
+			goto err;
+		}
+
+		composite->fixed_hw = fixed_hw;
+		composite->fixed_ops = fixed_ops;
+		clk_composite_ops->recalc_rate = clk_composite_recalc_rate_fixed;
+	}
+
 	init.ops = clk_composite_ops;
 	composite->hw.init = &init;
 
@@ -193,9 +217,34 @@ struct clk *clk_register_composite(struct device *dev, const char *name,
 	if (composite->gate_hw)
 		composite->gate_hw->clk = clk;
 
+	if (composite->fixed_hw)
+		composite->fixed_hw->clk = clk;
+
 	return clk;
 
 err:
 	kfree(composite);
 	return clk;
 }
+
+struct clk *clk_register_composite(struct device *dev, const char *name,
+			const char **parent_names, int num_parents,
+			struct clk_hw *mux_hw, const struct clk_ops *mux_ops,
+			struct clk_hw *div_hw, const struct clk_ops *div_ops,
+			struct clk_hw *gate_hw, const struct clk_ops *gate_ops,
+			unsigned long flags)
+{
+	return _clk_register_composite(dev, name, parent_names, num_parents,
+				       mux_hw, mux_ops, div_hw, div_ops,
+				       gate_hw, gate_ops, NULL, NULL, flags);
+}
+
+struct clk *clk_register_gatable_osc(struct device *dev, const char *name,
+			struct clk_hw *fixed_hw, const struct clk_ops *fixed_ops,
+			struct clk_hw *gate_hw, const struct clk_ops *gate_ops,
+			unsigned long flags)
+{
+	return _clk_register_composite(dev, name, NULL, 0, NULL, NULL,
+				       NULL, NULL, gate_hw, gate_ops,
+				       fixed_hw, fixed_ops, flags);
+}
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 33e7e64..82dd006 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -343,10 +343,12 @@ struct clk_composite {
 	struct clk_hw	*mux_hw;
 	struct clk_hw	*div_hw;
 	struct clk_hw	*gate_hw;
+	struct clk_hw	*fixed_hw;
 
 	const struct clk_ops	*mux_ops;
 	const struct clk_ops	*div_ops;
 	const struct clk_ops	*gate_ops;
+	const struct clk_ops	*fixed_ops;
 };
 
 struct clk *clk_register_composite(struct device *dev, const char *name,
@@ -356,6 +358,10 @@ struct clk *clk_register_composite(struct device *dev, const char *name,
 		struct clk_hw *gate_hw, const struct clk_ops *gate_ops,
 		unsigned long flags);
 
+struct clk *clk_register_gatable_osc(struct device *dev, const char *name,
+		struct clk_hw *fixed_hw, const struct clk_ops *fixed_ops,
+		struct clk_hw *gate_hw, const struct clk_ops *gate_ops,
+		unsigned long flags);
 /**
  * clk_register - allocate a new clock, register it and return an opaque cookie
  * @dev: device that is registering this clock
-- 
1.8.2.1



From emilio at elopez.com.ar  Tue Apr  9 09:48:03 2013
From: emilio at elopez.com.ar (=?UTF-8?q?Emilio=20L=C3=B3pez?=)
Date: Tue,  9 Apr 2013 10:48:03 -0300
Subject: [PATCH 2/3] clk: sunxi: Unify oscillator clock
In-Reply-To: <1365515284-32061-1-git-send-email-emilio@elopez.com.ar>
References: <1365515284-32061-1-git-send-email-emilio@elopez.com.ar>
Message-ID: <1365515284-32061-3-git-send-email-emilio@elopez.com.ar>

This commit uses the new fixed-rate support on the composite clock to
unify osc24M_fixed and osc24M clocks, so it matches the actual hardware.

Signed-off-by: Emilio L?pez <emilio at elopez.com.ar>
---
 drivers/clk/sunxi/clk-sunxi.c | 30 +++++++++++++++++++++++-------
 1 file changed, 23 insertions(+), 7 deletions(-)

diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
index 0bb0eb4..e072bd8 100644
--- a/drivers/clk/sunxi/clk-sunxi.c
+++ b/drivers/clk/sunxi/clk-sunxi.c
@@ -33,16 +33,33 @@ static DEFINE_SPINLOCK(clk_lock);
 static void __init sunxi_osc_clk_setup(struct device_node *node)
 {
 	struct clk *clk;
+	struct clk_fixed_rate *fixed;
+	struct clk_gate *gate;
 	const char *clk_name = node->name;
-	const char *parent;
-	void *reg;
+	u32 rate;
 
-	reg = of_iomap(node, 0);
+	/* allocate fixed-rate and gate clock structs */
+	fixed = kzalloc(sizeof(struct clk_fixed_rate), GFP_KERNEL);
+	if (!fixed)
+		return;
+	gate = kzalloc(sizeof(struct clk_gate), GFP_KERNEL);
+	if (!gate) {
+		kfree(fixed);
+		return;
+	}
 
-	parent = of_clk_get_parent_name(node, 0);
+	if (of_property_read_u32(node, "clock-frequency", &rate))
+		return;
+
+	/* set up gate and fixed rate properties */
+	gate->reg = of_iomap(node, 0);
+	gate->bit_idx = SUNXI_OSC24M_GATE;
+	gate->lock = &clk_lock;
+	fixed->fixed_rate = rate;
 
-	clk = clk_register_gate(NULL, clk_name, parent, 0, reg,
-				SUNXI_OSC24M_GATE, 0, &clk_lock);
+	clk = clk_register_gatable_osc(NULL, clk_name, &fixed->hw,
+				       &clk_fixed_rate_ops, &gate->hw,
+				       &clk_gate_ops, CLK_IS_ROOT);
 
 	if (clk) {
 		of_clk_add_provider(node, of_clk_src_simple_get, clk);
@@ -380,7 +397,6 @@ static void __init sunxi_gates_clk_setup(struct device_node *node,
 
 /* Matches for of_clk_init */
 static const __initconst struct of_device_id clk_match[] = {
-	{.compatible = "fixed-clock", .data = of_fixed_clk_setup,},
 	{.compatible = "allwinner,sun4i-osc-clk", .data = sunxi_osc_clk_setup,},
 	{}
 };
-- 
1.8.2.1



From sergei.shtylyov at cogentembedded.com  Tue Apr  9 09:49:02 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Tue, 09 Apr 2013 17:49:02 +0400
Subject: [PATCH v9 4/6] ARM: davinci: Add a remoteproc driver
 implementation for OMAP-L13x DSP
In-Reply-To: <13514BD7FAEBA745BBD7D8A672905C1431230384@DFLE12.ent.ti.com>
References: <1364521307-1219-1-git-send-email-rtivy@ti.com>
 <1364521307-1219-5-git-send-email-rtivy@ti.com>
 <CAK=WgbZme2UkMeP-JB2h3xnmcpzAaYeOcy7gxh60muJ8KZbr_A@mail.gmail.com>
 <5161B2FC.2090605@cogentembedded.com>
 <13514BD7FAEBA745BBD7D8A672905C1431230384@DFLE12.ent.ti.com>
Message-ID: <51641C4E.5010800@cogentembedded.com>

Hello.

On 09-04-2013 3:55, Tivy, Robert wrote:

>>>> +static int da8xx_rproc_probe(struct platform_device *pdev)
>>>> +{
>>>> +       struct device *dev = &pdev->dev;
>>>> +       struct da8xx_rproc *drproc;
>>>> +       struct rproc *rproc;
>>>> +       struct irq_data *irq_data;
>>>> +       struct resource *bootreg_res;
>>>> +       struct resource *chipsig_res;
>>>> +       struct clk *dsp_clk;
>>>> +       void __iomem *chipsig;
>>>> +       void __iomem *bootreg;
>>>> +       int irq;
>>>> +       int ret;
>>>> +
>> [...]
>>>> +       bootreg = devm_request_and_ioremap(dev, bootreg_res);
>>>> +       if (!bootreg) {
>>>> +               dev_err(dev, "unable to map boot register\n");
>>>> +               return -EADDRNOTAVAIL;
>>>> +       }
>>>> +
>>>> +       chipsig = devm_request_and_ioremap(dev, chipsig_res);

>>      I suggest that you use more modern (yes, already a newer interface
>> :-)
>> devm_ioremap_resource() instead -- it returns the error code (as a
>> pointer)
>> in case of error, and it certainly doesn't require you to print error
>> messages.

> Thanks, will do.

> I appreciate the notice of a more modern function, it's really tough to keep up with the flurry of activity to the kernel.

> Regarding this change, should the code use
> 	return PTR_ERR(bootreg);
> or
> 	return PTR_RET(bootreg);

    The former, to avoid duplicate IS_ERR() check.

> I ask because PTR_ERR() returns 'long' whereas PTR_RET() returns 'int' (and probe returns 'int'), but I see that the majority of existing code uses "return PTR_ERR()" in probe functions.

    But PTR_RET() uses PTR_ERR() internally anyway.

>>>> +       if (!chipsig) {
>>>> +               dev_err(dev, "unable to map CHIPSIG register\n");
>>>> +               return -EADDRNOTAVAIL;
>>>> +       }

WBR, Sergei



From emilio at elopez.com.ar  Tue Apr  9 09:48:04 2013
From: emilio at elopez.com.ar (=?UTF-8?q?Emilio=20L=C3=B3pez?=)
Date: Tue,  9 Apr 2013 10:48:04 -0300
Subject: [PATCH 3/3] ARM: sunxi: unify osc24M_fixed and osc24M
In-Reply-To: <1365515284-32061-1-git-send-email-emilio@elopez.com.ar>
References: <1365515284-32061-1-git-send-email-emilio@elopez.com.ar>
Message-ID: <1365515284-32061-4-git-send-email-emilio@elopez.com.ar>

Now that the clock driver supports the gatable oscillator as one single
clock, drop osc24M_fixed and move the relevant properties to osc24M

Signed-off-by: Emilio L?pez <emilio at elopez.com.ar>
---
 arch/arm/boot/dts/sunxi.dtsi | 8 +-------
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/arch/arm/boot/dts/sunxi.dtsi b/arch/arm/boot/dts/sunxi.dtsi
index a8d47e2..2309272 100644
--- a/arch/arm/boot/dts/sunxi.dtsi
+++ b/arch/arm/boot/dts/sunxi.dtsi
@@ -39,17 +39,11 @@
 			clock-frequency = <0>;
 		};
 
-		osc24M_fixed: osc24M_fixed {
-			#clock-cells = <0>;
-			compatible = "fixed-clock";
-			clock-frequency = <24000000>;
-		};
-
 		osc24M: osc24M at 01c20050 {
 			#clock-cells = <0>;
 			compatible = "allwinner,sun4i-osc-clk";
+			clock-frequency = <24000000>;
 			reg = <0x01c20050 0x4>;
-			clocks = <&osc24M_fixed>;
 		};
 
 		osc32k: osc32k {
-- 
1.8.2.1



From linux at arm.linux.org.uk  Tue Apr  9 09:51:20 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Tue, 9 Apr 2013 14:51:20 +0100
Subject: [RFC PATCH arm: initial TI-Nspire support]
In-Reply-To: <1365508916.24306.17.camel@hornet>
References: <6FE4B33E-A503-4A75-AEED-831CB2C06D83@gmail.com>
 <4B3FD561-84FC-40CD-B747-13851692D673@gmail.com>
 <521DFDFC-7E9E-47EA-ACDA-C91BBDC8454E@gmail.com>
 <201304072323.42173.arnd@arndb.de>
 <CACRpkda9Nue-8Esp3cJ6u2-MJ2ZL8hH-2BnrhHwWv4GZP2VR5w@mail.gmail.com>
 <1365508916.24306.17.camel@hornet>
Message-ID: <20130409135120.GC14496@n2100.arm.linux.org.uk>

On Tue, Apr 09, 2013 at 01:01:56PM +0100, Pawel Moll wrote:
> So I have PL111 code almost working here, however today it depends on
> not-yet-upstream (to my knowledge) generic/common panel/display
> framework. If I'm not disturbed again I may get something done this
> week, hopefully removing the dependency.
> 
> There's also some work going on on a DRM driver for PL111, but I can't
> promise any dates.
> 
> As to PL110 I have no idea how different is it from the PL111, but
> nothing is happening about it anyway.

If you're doing PL111, then you might as well do PL110, because the two
are basically the same.  But note that all PL111's aren't equal.  Some
are closer to PL110 than the current PL111, so if you want to support
all PL111s, you also need to have the support in place for PL110.

Also note that the way the bits are assigned in the frame buffer varies
between platforms, and most certainly the TRMs documentation of colour
bitfield layouts can _not_ be relied upon.

I have considerable knowledge in this area, but as seems to be the norm
now, no one cares about that.  I'll go back to twiddling my thumbs now,
waiting for the next email to arrive.  Or maybe I'll go down to the
shops and wander around down there.  Or something.


From linux at arm.linux.org.uk  Tue Apr  9 09:54:06 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Tue, 9 Apr 2013 14:54:06 +0100
Subject: [RFC v2] dmaengine: omap-dma: Start DMA without delay for
 cyclic channels
In-Reply-To: <5163C184.1010200@ti.com>
References: <1364987862-14597-1-git-send-email-peter.ujfalusi@ti.com>
 <51626D88.8020809@ti.com> <20130408170956.GX30923@n2100.arm.linux.org.uk>
 <5163C118.5000207@ti.com> <5163C184.1010200@ti.com>
Message-ID: <20130409135406.GA14500@n2100.arm.linux.org.uk>

On Tue, Apr 09, 2013 at 09:21:40AM +0200, Peter Ujfalusi wrote:
> Russell,
> 
> On 04/09/2013 09:19 AM, Peter Ujfalusi wrote:
> > On 04/08/2013 07:09 PM, Russell King - ARM Linux wrote:
> >> Now that I'm back from a short 4 day break, then yes, and the answer is
> >> that it's fine.  Who's handling the patch?
> > 
> > Thank you,
> > P?ter
> 
> Can I add you acked-by to the patch?

You may, using the rmk+kernel address, not this one.  Thanks.


From arnd at arndb.de  Tue Apr  9 10:05:59 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 9 Apr 2013 16:05:59 +0200
Subject: [GIT PULL] ux500 multiplatform tags
In-Reply-To: <CACRpkdbPZ5Nvv9+Bz9UE-U6-9QpqAr6UKGyYrTAxj78SJaknvg@mail.gmail.com>
References: <CACRpkdbPZ5Nvv9+Bz9UE-U6-9QpqAr6UKGyYrTAxj78SJaknvg@mail.gmail.com>
Message-ID: <201304091605.59598.arnd@arndb.de>

On Monday 08 April 2013, Linus Walleij wrote:
> Hi ARM SoC folks and Sam,
> 
> These are the two multiplatform tags for MFD and ARM SoC.
> 
> As agreed there is one tag for a number of MFD patches that
> remove the <mach/*> dependencies from the DB8500 PRCMU
> driver, then another tag dependent on the former that from that
> point switches to multiplatform.
> 
> Below are two tags on git request-pull formar: the first one
> is for *both* trees, MFD and ARM SoC, the second is only
> for ARM SoC.
> 
> I have moved a few hunks and introduced a new patch in the
> MFD series to make things compile and bisect properly.
> Notably the patch "mfd: db8500-prcmu: drop unused includes"
> is a new one, but the end result is textually equivalent to what
> has already been posted so I consider this a reviewed patch
> set and the split as plain mechanics.
> 
> Please pull your applicable branches!

Pulled into next/multiplatform, thanks a lot!

	Arnd


From arnd at arndb.de  Tue Apr  9 10:06:42 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 9 Apr 2013 16:06:42 +0200
Subject: [GIT PULL 2/4] ARM: mxs: multiplatform for 3.10
In-Reply-To: <1365411621-18422-2-git-send-email-shawn.guo@linaro.org>
References: <1365411621-18422-1-git-send-email-shawn.guo@linaro.org>
 <1365411621-18422-2-git-send-email-shawn.guo@linaro.org>
Message-ID: <201304091606.42908.arnd@arndb.de>

On Monday 08 April 2013, Shawn Guo wrote:
> Hi Arnd, Olof,
> 
> It's based on mxs-cleanup-3.10 to enable multiplatform build for
> mach-mxs. Please pull, thanks.

Great work, I did not see this one coming for 3.10.

Pulled into next/multiplatform, thanks!

	Arnd


From laurent.pinchart at ideasonboard.com  Tue Apr  9 10:07:58 2013
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Tue, 09 Apr 2013 16:07:58 +0200
Subject: [PATCH/RFC] ARM: shmobile: Disallow PINCTRL without GPIOLIB
In-Reply-To: <CACRpkdZ9fSoQnF-MgRKi4PUhv56+CuraXhuVgUhLyHcoEnBPZg@mail.gmail.com>
References: <20130318135818.23765.51686.sendpatchset@w520>
 <21658140.49USZQOU99@avalon>
 <CACRpkdZ9fSoQnF-MgRKi4PUhv56+CuraXhuVgUhLyHcoEnBPZg@mail.gmail.com>
Message-ID: <2575027.16EVpHnJzT@avalon>

Hi Linus,

On Tuesday 09 April 2013 10:06:45 Linus Walleij wrote:
> On Tue, Mar 26, 2013 at 4:23 PM, Laurent Pinchart wrote:
> >> About this issue, the fact that selecting PINCTRL without GPIO results
> >> in compile error makes me think that something needs slight adjustment
> >> in the PFC code.
> > 
> > The above errors come from the pinctrl core (although the PFC driver might
> > not compile either in this case). Linus, what's your opinion on this ? Do
> > we want to support systems with pinctrl but without gpiolib ?
> 
> Yes. It is perfectly legal to have pin controllers that do not correlate
> GPIO ranges.
> 
> Does commit 2afe8229687ec24cbc07e78449a588bb8b68f858
> "pinctrl: core: add dependence of GPIOLIB"
> by Haojian fix this issue?

Yes it does.

I've just sent a patch that makes GPIOLIB support optional in the PFC driver. 
Magnus, with these two, should we revert 
6722f6cb763203cab775297b6e9d00834af0d6d7 ?

-- 
Regards,

Laurent Pinchart



From arnd at arndb.de  Tue Apr  9 10:09:15 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 9 Apr 2013 16:09:15 +0200
Subject: multi-platform broken in -next
In-Reply-To: <51641322.6000508@gmail.com>
References: <51641322.6000508@gmail.com>
Message-ID: <201304091609.16027.arnd@arndb.de>

On Tuesday 09 April 2013, Rob Herring wrote:
> Looks like cns3xxx changes broke multi-platform builds in todays
> linux-next tree:
> 
> + make -j4 ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- zImage dtbs
> scripts/kconfig/conf --silentoldconfig Kconfig
> arch/arm/mach-cns3xxx/Kconfig:2:warning: choice value used outside its
> choice group
> arch/arm/mach-bcm2835/Kconfig:2:warning: choice value used outside its
> choice group
> arch/arm/Kconfig:287:error: recursive dependency detected!
> arch/arm/Kconfig:287:   choice <choice> contains symbol ARCH_CNS3XXX
> arch/arm/Kconfig:366:   symbol ARCH_CNS3XXX depends on ARCH_MULTI_V6
> arch/arm/Kconfig:933:   symbol ARCH_MULTI_V6 depends on ARCH_MULTIPLATFORM
> arch/arm/Kconfig:292:   symbol ARCH_MULTIPLATFORM is part of choice <choice>
>   WRAP    arch/arm/include/generated/asm/auxvec.h
>   WRAP    arch/arm/include/generated/asm/bitsperlong.h

Yes, you are the third person to report this today, sorry for causing all the
trouble. I've fixed it up earlier today.

	Arnd


From rogerio.pimentel at freescale.com  Tue Apr  9 10:07:29 2013
From: rogerio.pimentel at freescale.com (Rogerio Pimentel)
Date: Tue, 9 Apr 2013 11:07:29 -0300
Subject: [PATCH v2 1/4] imx-drm: parallel-display: Fix valid_mode checking
Message-ID: <1365516452-1287-1-git-send-email-rogerio.pimentel@freescale.com>

It fixes the logic of valid_mode checking, it's now
in accordance with drm_mode_status enumeration.

Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
Signed-off-by: Rogerio Pimentel <rogerio.pimentel at freescale.com>
---
Changes since v1:
Removed the "if(np)" block and now using the existent functions to get
the modes by fixing the mode_valid logic test 
 drivers/staging/imx-drm/parallel-display.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/imx-drm/parallel-display.c b/drivers/staging/imx-drm/parallel-display.c
index a8064fc..49c90c3 100644
--- a/drivers/staging/imx-drm/parallel-display.c
+++ b/drivers/staging/imx-drm/parallel-display.c
@@ -64,7 +64,7 @@ static int imx_pd_connector_get_modes(struct drm_connector *connector)
 		num_modes = drm_add_edid_modes(connector, imxpd->edid);
 	}
 
-	if (imxpd->mode_valid) {
+	if (imxpd->mode_valid == MODE_OK) {
 		struct drm_display_mode *mode = drm_mode_create(connector->dev);
 		drm_mode_copy(mode, &imxpd->mode);
 		mode->type |= DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED,
@@ -78,7 +78,7 @@ static int imx_pd_connector_get_modes(struct drm_connector *connector)
 static int imx_pd_connector_mode_valid(struct drm_connector *connector,
 			  struct drm_display_mode *mode)
 {
-	return 0;
+	return MODE_OK;
 }
 
 static struct drm_encoder *imx_pd_connector_best_encoder(
-- 
1.7.10.4




From rogerio.pimentel at freescale.com  Tue Apr  9 10:07:30 2013
From: rogerio.pimentel at freescale.com (Rogerio Pimentel)
Date: Tue, 9 Apr 2013 11:07:30 -0300
Subject: [PATCH v2 2/4] imx-drm: parallel-display: Make IPU KMS parse
 display-timings
In-Reply-To: <1365516452-1287-1-git-send-email-rogerio.pimentel@freescale.com>
References: <1365516452-1287-1-git-send-email-rogerio.pimentel@freescale.com>
Message-ID: <1365516452-1287-2-git-send-email-rogerio.pimentel@freescale.com>

This patch adds support for parsing of the DT display-timings prop
to IPU KMS driver.

Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
Signed-off-by: Marek Vasut <marex at denx.de>
Signed-off-by: Rogerio Pimentel <rogerio.pimentel at freescale.com>
---
Changes since v1:
Moved the function of_get_drm_display_mode from 
imx_pd_connector_get_modes function to probe function
 drivers/staging/imx-drm/parallel-display.c |    2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/staging/imx-drm/parallel-display.c b/drivers/staging/imx-drm/parallel-display.c
index 49c90c3..adc011d 100644
--- a/drivers/staging/imx-drm/parallel-display.c
+++ b/drivers/staging/imx-drm/parallel-display.c
@@ -232,6 +232,8 @@ static int imx_pd_probe(struct platform_device *pdev)
 
 	platform_set_drvdata(pdev, imxpd);
 
+	of_get_drm_display_mode(np, &imxpd->mode, 0);
+
 	return 0;
 }
 
-- 
1.7.10.4




From rogerio.pimentel at freescale.com  Tue Apr  9 10:07:31 2013
From: rogerio.pimentel at freescale.com (Rogerio Pimentel)
Date: Tue, 9 Apr 2013 11:07:31 -0300
Subject: [PATCH v2 3/4] ARM: dts: mx53qsb: Add support for parallel display
In-Reply-To: <1365516452-1287-1-git-send-email-rogerio.pimentel@freescale.com>
References: <1365516452-1287-1-git-send-email-rogerio.pimentel@freescale.com>
Message-ID: <1365516452-1287-3-git-send-email-rogerio.pimentel@freescale.com>

Add support for CLAA WVGA display for i.MX53 QSB.

Signed-off-by: Rogerio Pimentel <rogerio.pimentel at freescale.com>
---
Changes since v1:
Changed the label disp1 to disp0 to correctly match the display pins
 arch/arm/boot/dts/imx53-qsb.dtsp |   26 ++++++++++++++++++++++++++
 arch/arm/boot/dts/imx53.dtsip    |   35 +++++++++++++++++++++++++++++++++++
 2 files changed, 61 insertions(+)

diff --git a/arch/arm/boot/dts/imx53-qsb.dtsp b/arch/arm/boot/dts/imx53-qsb.dtsp
index dae8d9f..6086a3c 100644
--- a/arch/arm/boot/dts/imx53-qsb.dtsp
+++ b/arch/arm/boot/dts/imx53-qsb.dtsp
@@ -21,6 +21,32 @@
 		reg = <0x70000000 0x40000000>;
 	};
 
+	display at di0 {
+		compatible = "fsl,imx-parallel-display";
+		crtcs = <&ipu 0>;
+		interface-pix-fmt = "rgb565";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_ipu_disp0_1>;
+		display-timings {
+			claawvga {
+				native-mode;
+				clock-frequency = <27000000>;
+				hactive = <800>;
+				vactive = <480>;
+				hback-porch = <40>;
+				hfront-porch = <60>;
+				vback-porch = <10>;
+				vfront-porch = <10>;
+				hsync-len = <20>;
+				vsync-len = <10>;
+				hsync-active = <0>;
+				vsync-active = <0>;
+				de-active = <1>;
+				pixelclk-active = <0>;
+			};
+		};
+	};
+
 	gpio-keys {
 		compatible = "gpio-keys";
 
diff --git a/arch/arm/boot/dts/imx53.dtsip b/arch/arm/boot/dts/imx53.dtsip
index 845982e..a5f9d68 100644
--- a/arch/arm/boot/dts/imx53.dtsip
+++ b/arch/arm/boot/dts/imx53.dtsip
@@ -444,6 +444,41 @@
 					};
 				};
 
+				ipu_disp0 {
+					pinctrl_ipu_disp0_1: ipudisp0grp-1 {
+						fsl,pins = <
+						MX53_PAD_DI0_DISP_CLK__IPU_DI0_DISP_CLK 0x5
+						MX53_PAD_DI0_PIN15__IPU_DI0_PIN15 0x5
+						MX53_PAD_DI0_PIN2__IPU_DI0_PIN2 0x5
+						MX53_PAD_DI0_PIN3__IPU_DI0_PIN3  0x5
+						MX53_PAD_DISP0_DAT0__IPU_DISP0_DAT_0 0x5
+						MX53_PAD_DISP0_DAT1__IPU_DISP0_DAT_1 0x5
+						MX53_PAD_DISP0_DAT2__IPU_DISP0_DAT_2 0x5
+						MX53_PAD_DISP0_DAT3__IPU_DISP0_DAT_3 0x5
+						MX53_PAD_DISP0_DAT4__IPU_DISP0_DAT_4 0x5
+						MX53_PAD_DISP0_DAT5__IPU_DISP0_DAT_5 0x5
+						MX53_PAD_DISP0_DAT6__IPU_DISP0_DAT_6 0x5
+						MX53_PAD_DISP0_DAT7__IPU_DISP0_DAT_7 0x5
+						MX53_PAD_DISP0_DAT8__IPU_DISP0_DAT_8 0x5
+						MX53_PAD_DISP0_DAT9__IPU_DISP0_DAT_9 0x5
+						MX53_PAD_DISP0_DAT10__IPU_DISP0_DAT_10 0x5
+						MX53_PAD_DISP0_DAT11__IPU_DISP0_DAT_11 0x5
+						MX53_PAD_DISP0_DAT12__IPU_DISP0_DAT_12 0x5
+						MX53_PAD_DISP0_DAT13__IPU_DISP0_DAT_13 0x5
+						MX53_PAD_DISP0_DAT14__IPU_DISP0_DAT_14 0x5
+						MX53_PAD_DISP0_DAT15__IPU_DISP0_DAT_15 0x5
+						MX53_PAD_DISP0_DAT16__IPU_DISP0_DAT_16 0x5
+						MX53_PAD_DISP0_DAT17__IPU_DISP0_DAT_17 0x5
+						MX53_PAD_DISP0_DAT18__IPU_DISP0_DAT_18 0x5
+						MX53_PAD_DISP0_DAT19__IPU_DISP0_DAT_19 0x5
+						MX53_PAD_DISP0_DAT20__IPU_DISP0_DAT_20 0x5
+						MX53_PAD_DISP0_DAT21__IPU_DISP0_DAT_21 0x5
+						MX53_PAD_DISP0_DAT22__IPU_DISP0_DAT_22 0x5
+						MX53_PAD_DISP0_DAT23__IPU_DISP0_DAT_23 0x5
+						>;
+					};
+				};
+
 				owire {
 					pinctrl_owire_1: owiregrp-1 {
 						fsl,pins = <
-- 
1.7.10.4




From rogerio.pimentel at freescale.com  Tue Apr  9 10:07:32 2013
From: rogerio.pimentel at freescale.com (Rogerio Pimentel)
Date: Tue, 9 Apr 2013 11:07:32 -0300
Subject: [PATCH v2 4/4] ARM: imx_v6_v7_defconfig: enable parallel display
In-Reply-To: <1365516452-1287-1-git-send-email-rogerio.pimentel@freescale.com>
References: <1365516452-1287-1-git-send-email-rogerio.pimentel@freescale.com>
Message-ID: <1365516452-1287-4-git-send-email-rogerio.pimentel@freescale.com>

Allow parallel display to work by default

Signed-off-by: Rogerio Pimentel <rogerio.pimentel at freescale.com>
---
Changes since v1:
No changes
 arch/arm/configs/imx_v6_v7_defconfig |    3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/configs/imx_v6_v7_defconfig b/arch/arm/configs/imx_v6_v7_defconfig
index e36b010..4942479 100644
--- a/arch/arm/configs/imx_v6_v7_defconfig
+++ b/arch/arm/configs/imx_v6_v7_defconfig
@@ -162,6 +162,7 @@ CONFIG_MEDIA_CAMERA_SUPPORT=y
 CONFIG_SOC_CAMERA=y
 CONFIG_SOC_CAMERA_OV2640=y
 CONFIG_DRM=y
+CONFIG_OF_VIDEOMODE=y
 CONFIG_VIDEO_MX3=y
 CONFIG_FB=y
 CONFIG_LCD_PLATFORM=y
@@ -206,6 +207,8 @@ CONFIG_IMX_SDMA=y
 CONFIG_MXS_DMA=y
 CONFIG_STAGING=y
 CONFIG_DRM_IMX=y
+CONFIG_DRM_IMX_FB_HELPER=y
+CONFIG_DRM_IMX_PARALLEL_DISPLAY=y
 CONFIG_DRM_IMX_IPUV3_CORE=y
 CONFIG_DRM_IMX_IPUV3=y
 CONFIG_COMMON_CLK_DEBUG=y
-- 
1.7.10.4




From fabio.estevam at freescale.com  Tue Apr  9 10:16:18 2013
From: fabio.estevam at freescale.com (Fabio Estevam)
Date: Tue, 9 Apr 2013 11:16:18 -0300
Subject: [PATCH] video: mxsfb: Adapt to new videomode API
Message-ID: <1365516978-29888-1-git-send-email-fabio.estevam@freescale.com>

commit 6cd2c7db4 (videomode: videomode_from_timing work) changed the name of 
the function from videomode_from_timing() to videomode_from_timings().

commit 32ed6ef1 (videomode: create enum for videomode's display flags) changed
the 'data_flags' field in videomode structure to 'flags'

Adapt to these changes in order to fix the following errors:

drivers/video/mxsfb.c:761:3: error: too many arguments to function 'videomode_from_timing'
drivers/video/mxsfb.c:761:7: error: void value not ignored as it ought to be
drivers/video/mxsfb.c:768:9: error: 'struct videomode' has no member named 'data_flags'
drivers/video/mxsfb.c:770:9: error: 'struct videomode' has no member named 'data_flags'

Also select VIDEOMODE_HELPER in Kconfig to avoid linker errors.

Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
---
 drivers/video/Kconfig |    1 +
 drivers/video/mxsfb.c |    7 ++++---
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index d90e3f5..240f863 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -2428,6 +2428,7 @@ config FB_MXS
 	select FB_CFB_IMAGEBLIT
 	select FB_MODE_HELPERS
 	select OF_VIDEOMODE
+	select VIDEOMODE_HELPERS
 	help
 	  Framebuffer support for the MXS SoC.
 
diff --git a/drivers/video/mxsfb.c b/drivers/video/mxsfb.c
index eac7c1a..fb559f3 100644
--- a/drivers/video/mxsfb.c
+++ b/drivers/video/mxsfb.c
@@ -43,6 +43,7 @@
 #include <linux/kernel.h>
 #include <linux/of_device.h>
 #include <linux/of_gpio.h>
+#include <video/display_timing.h>
 #include <video/of_display_timing.h>
 #include <linux/platform_device.h>
 #include <linux/clk.h>
@@ -758,16 +759,16 @@ static int mxsfb_init_fbinfo_dt(struct mxsfb_info *host)
 		struct videomode vm;
 		struct fb_videomode fb_vm;
 
-		ret = videomode_from_timing(timings, &vm, i);
+		ret = videomode_from_timings(timings, &vm, i);
 		if (ret < 0)
 			goto put_timings_node;
 		ret = fb_videomode_from_videomode(&vm, &fb_vm);
 		if (ret < 0)
 			goto put_timings_node;
 
-		if (vm.data_flags & DISPLAY_FLAGS_DE_HIGH)
+		if (vm.flags & DISPLAY_FLAGS_DE_HIGH)
 			host->sync |= MXSFB_SYNC_DATA_ENABLE_HIGH_ACT;
-		if (vm.data_flags & DISPLAY_FLAGS_PIXDATA_NEGEDGE)
+		if (vm.flags & DISPLAY_FLAGS_PIXDATA_NEGEDGE)
 			host->sync |= MXSFB_SYNC_DOTCLK_FALLING_ACT;
 		fb_add_videomode(&fb_vm, &fb_info->modelist);
 	}
-- 
1.7.9.5




From arnd at arndb.de  Tue Apr  9 10:37:53 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 9 Apr 2013 16:37:53 +0200
Subject: [GIT PULL 4/8] ARM: tegra: core SoC support development
In-Reply-To: <1365181426-11547-4-git-send-email-swarren@wwwdotorg.org>
References: <1365181426-11547-1-git-send-email-swarren@wwwdotorg.org>
 <1365181426-11547-4-git-send-email-swarren@wwwdotorg.org>
Message-ID: <201304091637.53857.arnd@arndb.de>

On Friday 05 April 2013, Stephen Warren wrote:
> This branch includes major development on the core Tegra SoC support code
> in the mach-tegra directory:
> 
> * SMP support for Tegra114.
> * Exposes SoC chip ID and revision through standard sysfs files.
> * System-level suspend/resume for Tegra20/30. At present, this only
>   supports "LP2" mode (CPU power-down), but provides the basis to
>   implement "LP0"/"LP1" (various levels of core/chip power-down) in the
>   hopefully near future.
> * A minor cleanup of a duplicate include, which was introduced in this
>   branch.
> 
> This branch is based on the previous cleanup pull request.

Pulled into next/soc, thanks!

	Arnd


From arnd at arndb.de  Tue Apr  9 10:46:01 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 9 Apr 2013 16:46:01 +0200
Subject: [GIT PULL 3/4] ARM: mxs: soc changes for 3.10
In-Reply-To: <1365411621-18422-3-git-send-email-shawn.guo@linaro.org>
References: <1365411621-18422-1-git-send-email-shawn.guo@linaro.org>
 <1365411621-18422-3-git-send-email-shawn.guo@linaro.org>
Message-ID: <201304091646.02133.arnd@arndb.de>

On Monday 08 April 2013, Shawn Guo wrote:
> The following changes since commit 07961ac7c0ee8b546658717034fe692fd12eefa9:
> 
>   Linux 3.9-rc5 (2013-03-31 15:12:43 -0700)
> 
> are available in the git repository at:
> 
>   git://git.linaro.org/people/shawnguo/linux-2.6.git tags/mxs-soc-3.10
> 
> for you to fetch changes up to 656c284c5c517460245db159e122b0207f06f998:
> 
>   ARM: mxs_defconfig: Select watchdog driver (2013-04-01 16:31:04 +0800)
> 

Pulled into next/soc, thanks!

	Arnd


From arnd at arndb.de  Tue Apr  9 10:46:06 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 9 Apr 2013 16:46:06 +0200
Subject: [GIT PULL 4/5] omap soc changes for v3.10 merge window
In-Reply-To: <0MeglY-1UETDn0lho-00OeKU@mx.kundenserver.de>
References: <0MeglY-1UETDn0lho-00OeKU@mx.kundenserver.de>
Message-ID: <201304091646.06384.arnd@arndb.de>

On Tuesday 09 April 2013, Tony Lindgren wrote:
> The following changes since commit 31880c37c11e28cb81c70757e38392b42e695dc6:
> 
>   Linux 3.9-rc6 (2013-04-07 20:49:54 -0700)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.10/soc-signed
> 
> for you to fetch changes up to 7a9819950f47dbf319895ee78220f2761f3687a3:
> 
>   ARM: OMAP4: Enable fix for Cortex-A9 erratas (2013-04-08 16:14:51 -0700)
> 
> ----------------------------------------------------------------
> Changes needed for enabling SOC_BUS for the SoC revision
> information. Also enable few HW errata workarounds for omap4.

Pulled into next/soc, thanks!

	Arnd


From sboyd at codeaurora.org  Tue Apr  9 10:49:20 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Tue, 09 Apr 2013 07:49:20 -0700
Subject: [PATCH 3/4] clocksource: arch_timer: Push the read/write wrappers
 deeper
In-Reply-To: <20130409093855.GU23725@e106331-lin.cambridge.arm.com>
References: <1365474623-29181-1-git-send-email-sboyd@codeaurora.org>
 <1365474623-29181-4-git-send-email-sboyd@codeaurora.org>
 <20130409093855.GU23725@e106331-lin.cambridge.arm.com>
Message-ID: <51642A70.9060302@codeaurora.org>

On 04/09/13 02:38, Mark Rutland wrote:
> On Tue, Apr 09, 2013 at 03:30:22AM +0100, Stephen Boyd wrote:
>> -static inline u32 arch_timer_reg_read(const int access, const int reg)
>> +static inline u32 __arch_timer_reg_read(const int access, const int reg)
> Rather than prefixing all of these with "__", why not add "cp15" to the names?
>
> I think that'd make the end result more consistent and clearer, as we'd have a
> _mem version and a _cp15 version of each function.

Sounds fair. I'll make the change.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation



From arnd at arndb.de  Tue Apr  9 10:52:28 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 9 Apr 2013 16:52:28 +0200
Subject: [GIT PULL 2/5] omap pm clean-up for v3.10 merge window
In-Reply-To: <0MarPy-1U9XGk2D8s-00Ks1o@mx.kundenserver.de>
References: <0MarPy-1U9XGk2D8s-00Ks1o@mx.kundenserver.de>
Message-ID: <201304091652.28385.arnd@arndb.de>

On Tuesday 09 April 2013, Tony Lindgren wrote:
> The following changes since commit 07961ac7c0ee8b546658717034fe692fd12eefa9:
> 
>   Linux 3.9-rc5 (2013-03-31 15:12:43 -0700)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.10/cleanup-pm-signed
> 
> for you to fetch changes up to ca8cdff548da76da01f3783548ceb917139a5ddc:
> 
>   Merge tag 'omap-pm-v3.10/cleanup/cpuidle' of git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm into omap-for-v3.10/cleanup-pm (2013-04-08 09:51:00 -0700)
> 
> ----------------------------------------------------------------
> 
> PM cleanup to prepare for omap5 PM via Kevin Hilman <khilman at linaro.org>:
> 
> OMAP3/4 CPUidle cleanups for v3.10

Adding Daniel and Rafael to Cc.

Is this series coordinated with the other cpuidle changes? Please tell me if this
is good to go into arm-soc.

	Arnd

> ----------------------------------------------------------------
> Daniel Lezcano (1):
>       ARM: omap3: cpuidle: enable time keeping
> 
> Santosh Shilimkar (5):
>       ARM: OMAP4: CPUidle: Avoid double idle driver registration
>       ARM: OMAP: CPUidle: Unregister drivere on device registration failure
>       ARM: OMAP4: CPUidle: Make C-state description field more precise
>       ARM: OMAP4+: CPUidle: Deprecate use of omap4_mpuss_read_prev_context_state()
>       ARM: OMAP4+: CPUidle: Consolidate idle driver for OMAP5 support
> 
> Tony Lindgren (1):
>       Merge tag 'omap-pm-v3.10/cleanup/cpuidle' of git://git.kernel.org/.../khilman/linux-omap-pm into omap-for-v3.10/cleanup-pm
> 
>  arch/arm/mach-omap2/common.h              |  5 ----
>  arch/arm/mach-omap2/cpuidle34xx.c         | 11 +++++--
>  arch/arm/mach-omap2/cpuidle44xx.c         | 48 +++++++++++++++++--------------
>  arch/arm/mach-omap2/omap-mpuss-lowpower.c | 14 ---------
>  4 files changed, 35 insertions(+), 43 deletions(-)
> 



From kgene.kim at gmail.com  Tue Apr  9 10:55:08 2013
From: kgene.kim at gmail.com (Kukjin Kim)
Date: Tue, 09 Apr 2013 23:55:08 +0900
Subject: [GIT PULL 06/10] 2nd pinctrl-exynos for v3.10
In-Reply-To: <51630A18.6010801@samsung.com>
References: <51630A18.6010801@samsung.com>
Message-ID: <51642BCC.6000200@gmail.com>

On 04/09/13 03:19, Kukjin Kim wrote:
> The following changes since commit
> 97916777d6904e24b86eac77da58ef7cb09d539d:
>
> ARM: EXYNOS: skip wakeup interrupt registration for exynos5250 if
> pinctrl is enabled (2013-03-05 20:59:12 +0900)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
> tags/pinctrl-exynos-for-v3.10
>
> for you to fetch changes up to 790af0a51bdcbf504814be2673f96facfdd74981:
>
> pinctrl: exynos5440: add gpio interrupt support (2013-04-08 23:55:41 +0900)
>
> ----------------------------------------------------------------
> add support gpio interrupt for exynos5440
>
> ----------------------------------------------------------------
> Thomas Abraham (2):
> pinctrl: exynos5440: fix probe failure due to missing pin-list in config
> nodes
> pinctrl: exynos5440: add gpio interrupt support
>
> drivers/pinctrl/pinctrl-exynos5440.c | 151
> ++++++++++++++++++++++++++++++++++-
> 1 file changed, 148 insertions(+), 3 deletions(-)
>

Hi Arnd, Olof

Please hold on this pulling because this already merged into pinctrl tree.

Thanks.

- Kukjin


From gregory.clement at free-electrons.com  Tue Apr  9 10:56:08 2013
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Tue, 09 Apr 2013 16:56:08 +0200
Subject: [PATCH 0/3] sunxi: unify main oscillator and its gate
In-Reply-To: <1365515284-32061-1-git-send-email-emilio@elopez.com.ar>
References: <1365515284-32061-1-git-send-email-emilio@elopez.com.ar>
Message-ID: <51642C08.6070600@free-electrons.com>

Hi Emilio,

On 04/09/2013 03:48 PM, Emilio L?pez wrote:
> Hi Mike,
> 
> As discussed previously when introducing the sunxi driver, this patchset
> unifies the main oscillator ("osc24M_fixed") and its gate ("osc24M")
> into a single clock ("osc24M"). It does so by adding fixed-rate support
> into the composite clock and then using it to implement the new clock.
> 
> The changes shouldn't require any modifications on current/future users 
> of the composite clock, although I haven't tested any to make sure of 
> it. @Prashant, can I get a tested-by from you if necessary?

This patch set is a nice improvement, now we will have the best of the
two worlds: a 1-to-1 between the clock device in the device tree and the
real hardware clock on one side, and the reuse of existing driver clock
on the other side.

Could you indicate on which branch this patch set can be applied ? In
3.9-rc6 there is no file drivers/clk/clk-composite.c. I guess it should
be the something like clk-next or clk-for-3.10 from Mike's git tree.

Adding the branch where to apply the patch set is a good information to
add to the cover letter of a patch set.

Thanks,

> 
> Thanks,
> 
> Emilio
> 
> Emilio L??pez (3):
>   clk: composite: Add fixed-rate support
>   clk: sunxi: Unify oscillator clock
>   ARM: sunxi: unify osc24M_fixed and osc24M
> 
>  arch/arm/boot/dts/sunxi.dtsi  |  8 +-----
>  drivers/clk/clk-composite.c   | 57 ++++++++++++++++++++++++++++++++++++++++---
>  drivers/clk/sunxi/clk-sunxi.c | 30 +++++++++++++++++------
>  include/linux/clk-provider.h  |  6 +++++
>  4 files changed, 83 insertions(+), 18 deletions(-)
> 


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From kgene.kim at samsung.com  Tue Apr  9 10:56:52 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Tue, 09 Apr 2013 23:56:52 +0900
Subject: [PATCH 3/3] ARM: dts: list the interrupts generated by
 pin-controller on Exynos5440
In-Reply-To: <CACRpkdZ8kftvKP2-a4A5q+x545urjmhevtHjtL+SXnnN=0H83Q@mail.gmail.com>
References: <1364310754-3692-1-git-send-email-kgene.kim@samsung.com>
 <1364310754-3692-4-git-send-email-kgene.kim@samsung.com>
 <CACRpkdZ8kftvKP2-a4A5q+x545urjmhevtHjtL+SXnnN=0H83Q@mail.gmail.com>
Message-ID: <51642C34.4020607@samsung.com>

On 04/09/13 17:24, Linus Walleij wrote:
> On Tue, Mar 26, 2013 at 4:12 PM, Kukjin Kim<kgene.kim at samsung.com>  wrote:
>
>> From: Thomas Abraham<thomas.ab at samsung.com>
>>
>> Exynos5440 pin-controller generates eight interrupts to support gpio
>> interrupts. List those interrupt numbers in the pin-controller node.
>>
>> Signed-off-by: Thomas Abraham<thomas.ab at samsung.com>
>> Cc: Linus Walleij<linus.walleij at linaro.org>
>> Signed-off-by: Kukjin Kim<kgene.kim at samsung.com>
>
> Acked-by: Linus Walleij<linus.walleij at linaro.org>
>
> I guess this will go into the Exynos tree?
>
Yeah, it would be nice to us.

> Tell me if you want me to apply it to the pinctrl tree.
>
Thanks but let me take this into samsung tree.

- Kukjin


From kgene.kim at samsung.com  Tue Apr  9 10:59:09 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Tue, 09 Apr 2013 23:59:09 +0900
Subject: [PATCH] ARM: S3C24XX: Fix interrupt pending register offset of
 the EINT controller
In-Reply-To: <201304082225.43967.heiko@sntech.de>
References: <1365450787-14473-1-git-send-email-s.nawrocki@samsung.com>
 <201304082225.43967.heiko@sntech.de>
Message-ID: <51642CBD.6060803@samsung.com>

On 04/09/13 05:25, Heiko St?bner wrote:
> Am Montag, 8. April 2013, 21:53:07 schrieb Sylwester Nawrocki:
>> The external pending interrupt register address (EINTPEND) offset is
>> 0xa8, not 0x08. Without this patch the external interrupts are not
>> properly acknowledged, which may lead to an interrupt storm and the
>> system hang as soon as any external interrupt is requested.
>>
>> Signed-off-by: Sylwester Nawrocki<s.nawrocki at samsung.com>
> yep, I unintentionally introduced a typo there and the register really is
> 0xa8, so thanks (again) for the fix
>
> Reviewed-by: Heiko Stuebner<heiko at sntech.de>
>
Applied into fixes for v3.9.

Thanks.

- Kukjin


From arnd at arndb.de  Tue Apr  9 10:59:08 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 9 Apr 2013 16:59:08 +0200
Subject: [GIT PULL 7/8] ARM: tegra: multi-platform conversion
In-Reply-To: <1365181426-11547-7-git-send-email-swarren@wwwdotorg.org>
References: <1365181426-11547-1-git-send-email-swarren@wwwdotorg.org>
 <1365181426-11547-7-git-send-email-swarren@wwwdotorg.org>
Message-ID: <201304091659.08376.arnd@arndb.de>

On Friday 05 April 2013, Stephen Warren wrote:
> This branch converts Tegra to support multi-platform/single-zImage.
> 
> One header is made accessible to drivers. The earlyprintk implementation
> is moved to the multi-platform location. Some Kconfig changes are made
> to enable multi-platform. Some dead files are deleted.
> 
> The APIs exposed in the now-global tegra-powergate.h should be replaced
> with standard reset and power domain APIs in the future.
> 
> This branch is based on (part of) the previous soc pull request.
> 

Pulled into next/multiplatform, thanks a lot!

We now have a total of eight new platforms lined up for supporting a
multiplatform kernel in 3.10, and I still have some (limited) hope
for exynos.

I had to reorder the branches in arm-soc to avoid starting a
next/multiplatform2 branch, but I saw nothing that prevents us from
having multiplatform after soc.

	Arnd


From hechtb at gmail.com  Tue Apr  9 11:02:33 2013
From: hechtb at gmail.com (Bastian Hecht)
Date: Tue, 9 Apr 2013 17:02:33 +0200
Subject: [PATCH 2/2] ARM: shmobile: sh73a0: Suspend-to-RAM Power Off mode
In-Reply-To: <20130409132534.GB21045@verge.net.au>
References: <1363872697-11267-1-git-send-email-hechtb+renesas@gmail.com>
 <1363872697-11267-3-git-send-email-hechtb+renesas@gmail.com>
 <20130409132534.GB21045@verge.net.au>
Message-ID: <CABYn4sztgV_-Agp6GtdqTSzqNCNeSK27XEdAA7zZ7cs-DEpLgA@mail.gmail.com>

Hi Simon,

2013/4/9 Simon Horman <horms at verge.net.au>:
> On ?,  3? 21, 2013 at 02:31:37?? +0100, Bastian Hecht wrote:
>> We add Power Off mode defined by the ARM architecture as our
>> Suspend-to-RAM mechanism. Here the L2 cache keeps its power and we only
>> take care to flush the L1. Different startup paths are added for the two
>> CPUs, one leading to cpu_resume() and the other to secondary_startup().
>>
>> Signed-off-by: Bastian Hecht <hechtb+renesas at gmail.com>
>
> Bastian, could you please let me know about the status of this patch?
> Is it awaiting review?

I want to have a look again at the part with the L1 take down, my code
might be incorrect there although I experienced no adverse effects.
Before that I want to get the r8a7740 PM code merged.

I've posted a patch "ARM: shmobile: r8a7740: Add power down modes and
CPUIdle". I will post a fresh patch tomorrow I think with a stripped
down version. I will remove Core Standby Mode for which it is unclear
why we need to flush the L2 cache.

Thanks,

 Bastian

>> ---
>>  arch/arm/mach-shmobile/Makefile              |    2 +-
>>  arch/arm/mach-shmobile/headsmp-sh73a0.S      |   72 ++++++++++++++++++++++++++
>>  arch/arm/mach-shmobile/include/mach/common.h |    1 +
>>  arch/arm/mach-shmobile/pm-sh73a0.c           |   32 ++++++++++--
>>  arch/arm/mach-shmobile/smp-sh73a0.c          |    9 +++-
>>  5 files changed, 109 insertions(+), 7 deletions(-)
>>  create mode 100644 arch/arm/mach-shmobile/headsmp-sh73a0.S
>>
>> diff --git a/arch/arm/mach-shmobile/Makefile b/arch/arm/mach-shmobile/Makefile
>> index c621edf..1d33d89 100644
>> --- a/arch/arm/mach-shmobile/Makefile
>> +++ b/arch/arm/mach-shmobile/Makefile
>> @@ -14,7 +14,7 @@ obj-$(CONFIG_ARCH_EMEV2)    += setup-emev2.o clock-emev2.o
>>
>>  # SMP objects
>>  smp-y                                := platsmp.o headsmp.o
>> -smp-$(CONFIG_ARCH_SH73A0)    += smp-sh73a0.o headsmp-scu.o
>> +smp-$(CONFIG_ARCH_SH73A0)    += smp-sh73a0.o headsmp-sh73a0.o headsmp-scu.o
>>  smp-$(CONFIG_ARCH_R8A7779)   += smp-r8a7779.o headsmp-scu.o
>>  smp-$(CONFIG_ARCH_EMEV2)     += smp-emev2.o headsmp-scu.o
>>
>> diff --git a/arch/arm/mach-shmobile/headsmp-sh73a0.S b/arch/arm/mach-shmobile/headsmp-sh73a0.S
>> new file mode 100644
>> index 0000000..6ffed46
>> --- /dev/null
>> +++ b/arch/arm/mach-shmobile/headsmp-sh73a0.S
>> @@ -0,0 +1,72 @@
>> +/*
>> + * SMP support for SoC sh73a0
>> + *
>> + * Copyright (C) 2013 Bastian Hecht
>> + *
>> + * 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/linkage.h>
>> +#include <linux/init.h>
>> +#include <asm/memory.h>
>> +
>> +        __CPUINIT
>> +
>> +ENTRY(sh73a0_primary_resume)
>> +        bl      v7_invalidate_l1
>> +        b       cpu_resume
>> +ENDPROC(sh73a0_primary_resume)
>> +
>> +ENTRY(sh73a0_secondary_startup)
>> +        bl      v7_invalidate_l1
>> +        b       secondary_startup
>> +ENDPROC(sh73a0_primary_resume)
>> +
>> +/*
>> + * Reset vector for both CPUs.
>> + *
>> + * This function will be mapped to address 0 by the SBAR register and is the
>> + * general wakeup vector.
>> + * For both CPUs we need to set the SCU power flag to Run Mode and invalidate
>> + * the L1 cache so no random data get flushed out later.
>> + * We can't use v7_invalidate_l1() directly as a normal branch is out of range
>> + * here and so we need a long jump. We jump to the physical address as the
>> + * MMU is still turned off.
>> + *
>> + * We do not need to worry about CPU1 running ahead of CPU0 as the secondary
>> + * CPU of the sh73a0 needs to be woken using the WUPCR register. This is done
>> + * in sh73a0_boot_secondary().
>> + */
>> +        .align  12
>> +ENTRY(sh73a0_reset_vector)
>> +        /* Retrieve the CPU ID and keep it in r4 */
>> +        mrc     p15, 0, r4, c0, c0, 5   @ read MIPDR
>> +        and     r4, r4, #3              @ mask out cpu ID
>> +
>> +        /*
>> +         * We clear the SCU Power status flag to prepare for the
>> +         * L1 coherency mode
>> +         */
>> +        mov     r0, r4                  @ copy CPU ID
>> +        lsl     r0, r0, #3              @ we will shift by cpu_id * 8 bits
>> +     ldr     r1, 3f
>> +     ldr     r1, [r1]                @ SCU base address
>> +        ldr     r2, [r1, #8]            @ SCU Power Status Register
>> +        mov     r3, #3
>> +        bic     r2, r2, r3, lsl r0      @ Clear bits of our CPU (Run Mode)
>> +        str     r2, [r1, #8]            @ write back
>> +
>> +        /*
>> +         * Depending on the CPU ID we either resume our primary core from
>> +         * sleeping or bring up the secondary CPU
>> +         */
>> +        cmp     r4, #0                  @ if CPU0
>> +        ldreq   pc, 1f                  @ jump to sh73a0_primary_resume
>> +        ldr     pc, 2f                  @ jump to sh73a0_secondary_startup
>> +
>> +1:      .long   sh73a0_primary_resume - PAGE_OFFSET + PLAT_PHYS_OFFSET
>> +2:      .long   sh73a0_secondary_startup - PAGE_OFFSET + PLAT_PHYS_OFFSET
>> +3:      .long        shmobile_scu_base - PAGE_OFFSET + PLAT_PHYS_OFFSET
>> +ENDPROC(sh73a0_reset_vector)
>> diff --git a/arch/arm/mach-shmobile/include/mach/common.h b/arch/arm/mach-shmobile/include/mach/common.h
>> index 03f73de..842bb35 100644
>> --- a/arch/arm/mach-shmobile/include/mach/common.h
>> +++ b/arch/arm/mach-shmobile/include/mach/common.h
>> @@ -45,6 +45,7 @@ extern void sh73a0_add_standard_devices_dt(void);
>>  extern void sh73a0_clock_init(void);
>>  extern void sh73a0_pinmux_init(void);
>>  extern void sh73a0_pm_init(void);
>> +extern void sh73a0_reset_vector(void);
>>  extern struct clk sh73a0_extal1_clk;
>>  extern struct clk sh73a0_extal2_clk;
>>  extern struct clk sh73a0_extcki_clk;
>> diff --git a/arch/arm/mach-shmobile/pm-sh73a0.c b/arch/arm/mach-shmobile/pm-sh73a0.c
>> index 99086e9..7e8e0a1 100644
>> --- a/arch/arm/mach-shmobile/pm-sh73a0.c
>> +++ b/arch/arm/mach-shmobile/pm-sh73a0.c
>> @@ -1,30 +1,54 @@
>>  /*
>>   * sh73a0 Power management support
>>   *
>> - *  Copyright (C) 2012 Bastian Hecht <hechtb+renesas at gmail.com>
>> + *  Copyright (C) 2013 Bastian Hecht <hechtb+renesas at gmail.com>
>>   *
>>   * This file is subject to the terms and conditions of the GNU General Public
>>   * License.  See the file "COPYING" in the main directory of this archive
>>   * for more details.
>>   */
>>
>> +#include <linux/cpuidle.h>
>> +#include <linux/module.h>
>>  #include <linux/suspend.h>
>> +#include <linux/io.h>
>> +#include <asm/cacheflush.h>
>> +#include <asm/smp_scu.h>
>> +#include <asm/suspend.h>
>>  #include <mach/common.h>
>>
>>  #ifdef CONFIG_SUSPEND
>> -static int sh73a0_enter_suspend(suspend_state_t suspend_state)
>> +/*
>> + * sh73a0_do_poweroff: Power off the main CPU
>> + *
>> + * The L2 cache doesn't loose power in Power Off mode - ignore it.
>> + * After flushing the L1 cache we don't take care to disable it as we
>> + * only work on temporary values in a UP environment and it gets invalidated
>> + * on startup. Just straight take down the ARM core.
>> + */
>> +static int sh73a0_do_poweroff(unsigned long unused)
>>  {
>> +     flush_cache_all();
>> +     scu_power_mode(shmobile_scu_base, SCU_PM_POWEROFF);
>>       cpu_do_idle();
>> +
>> +     return 0;
>> +}
>> +
>> +static int sh73a0_enter_poweroff_suspend(suspend_state_t suspend_state)
>> +{
>> +     cpu_suspend(0, sh73a0_do_poweroff);
>> +
>>       return 0;
>>  }
>>
>>  static void sh73a0_suspend_init(void)
>>  {
>> -     shmobile_suspend_ops.enter = sh73a0_enter_suspend;
>> +     shmobile_suspend_ops.enter = sh73a0_enter_poweroff_suspend;
>>  }
>>  #else
>>  static void sh73a0_suspend_init(void) {}
>> -#endif
>> +#endif       /* CONFIG_SUSPEND */
>>
>>  void __init sh73a0_pm_init(void)
>>  {
>> diff --git a/arch/arm/mach-shmobile/smp-sh73a0.c b/arch/arm/mach-shmobile/smp-sh73a0.c
>> index 5ae502b..348714e 100644
>> --- a/arch/arm/mach-shmobile/smp-sh73a0.c
>> +++ b/arch/arm/mach-shmobile/smp-sh73a0.c
>> @@ -70,9 +70,14 @@ static void __init sh73a0_smp_prepare_cpus(unsigned int max_cpus)
>>  {
>>       scu_enable(shmobile_scu_base);
>>
>> -     /* Map the reset vector (in headsmp-scu.S) */
>> +     /*
>> +      * Map the general reset vector that is hit from multiple paths:
>> +      * - Primary CPU resume at wakeup time
>> +      * - Secondary startup at boot time
>> +      * - Secondary startup at wakeup time
>> +      */
>>       __raw_writel(0, APARMBAREA);      /* 4k */
>> -     __raw_writel(__pa(shmobile_secondary_vector_scu), SBAR);
>> +     __raw_writel(__pa(sh73a0_reset_vector), SBAR);
>>
>>       /* enable cache coherency on booting CPU */
>>       scu_power_mode(shmobile_scu_base, SCU_PM_NORMAL);
>> --
>> 1.7.9.5
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>


From kgene.kim at gmail.com  Tue Apr  9 11:02:49 2013
From: kgene.kim at gmail.com (kgene.kim at gmail.com)
Date: Wed, 10 Apr 2013 00:02:49 +0900
Subject: [PATCH RESEND] ARM: EXYNOS: no more support non-DT for EXYNOS SoCs
Message-ID: <51642dab.e844440a.0ad1.ffffc13f@mx.google.com>

From: Kukjin Kim <kgene.kim at samsung.com>

As we discussed in mailing list, non-DT for EXYNOS SoCs will not be
supported from v3.10. This patch removes regarding files for non-DT
including board files.

Signed-off-by: Kukjin Kim <kgene.kim at samsung.com>
---
Recreated as per Arnd's suggestion with using -D option :-)

Thanks, Arnd.

 arch/arm/configs/exynos4_defconfig         |   68 --
 arch/arm/mach-exynos/Kconfig               |  303 +-----
 arch/arm/mach-exynos/Makefile              |   26 -
 arch/arm/mach-exynos/common.c              |    9 +-
 arch/arm/mach-exynos/dev-ahci.c            |  255 -----
 arch/arm/mach-exynos/dev-ohci.c            |   52 --
 arch/arm/mach-exynos/dma.c                 |  322 -------
 arch/arm/mach-exynos/mach-armlex4210.c     |  206 -----
 arch/arm/mach-exynos/mach-nuri.c           | 1387 ----------------------------
 arch/arm/mach-exynos/mach-origen.c         |  822 -----------------
 arch/arm/mach-exynos/mach-smdk4x12.c       |  395 --------
 arch/arm/mach-exynos/mach-smdkv310.c       |  443 ---------
 arch/arm/mach-exynos/mach-universal_c210.c | 1159 -----------------------
 arch/arm/mach-exynos/pm_domains.c          |    7 -
 arch/arm/mach-exynos/setup-fimc.c          |   44 -
 arch/arm/mach-exynos/setup-fimd0.c         |   43 -
 arch/arm/mach-exynos/setup-i2c1.c          |   23 -
 arch/arm/mach-exynos/setup-i2c2.c          |   23 -
 arch/arm/mach-exynos/setup-i2c3.c          |   23 -
 arch/arm/mach-exynos/setup-i2c4.c          |   23 -
 arch/arm/mach-exynos/setup-i2c5.c          |   23 -
 arch/arm/mach-exynos/setup-i2c6.c          |   23 -
 arch/arm/mach-exynos/setup-i2c7.c          |   23 -
 arch/arm/mach-exynos/setup-keypad.c        |   36 -
 arch/arm/mach-exynos/setup-sdhci-gpio.c    |  152 ---
 arch/arm/mach-exynos/setup-spi.c           |   45 -
 arch/arm/mach-exynos/setup-usb-phy.c       |  223 -----
 27 files changed, 3 insertions(+), 6155 deletions(-)
 delete mode 100644 arch/arm/configs/exynos4_defconfig
 delete mode 100644 arch/arm/mach-exynos/dev-ahci.c
 delete mode 100644 arch/arm/mach-exynos/dev-ohci.c
 delete mode 100644 arch/arm/mach-exynos/dma.c
 delete mode 100644 arch/arm/mach-exynos/mach-armlex4210.c
 delete mode 100644 arch/arm/mach-exynos/mach-nuri.c
 delete mode 100644 arch/arm/mach-exynos/mach-origen.c
 delete mode 100644 arch/arm/mach-exynos/mach-smdk4x12.c
 delete mode 100644 arch/arm/mach-exynos/mach-smdkv310.c
 delete mode 100644 arch/arm/mach-exynos/mach-universal_c210.c
 delete mode 100644 arch/arm/mach-exynos/setup-fimc.c
 delete mode 100644 arch/arm/mach-exynos/setup-fimd0.c
 delete mode 100644 arch/arm/mach-exynos/setup-i2c1.c
 delete mode 100644 arch/arm/mach-exynos/setup-i2c2.c
 delete mode 100644 arch/arm/mach-exynos/setup-i2c3.c
 delete mode 100644 arch/arm/mach-exynos/setup-i2c4.c
 delete mode 100644 arch/arm/mach-exynos/setup-i2c5.c
 delete mode 100644 arch/arm/mach-exynos/setup-i2c6.c
 delete mode 100644 arch/arm/mach-exynos/setup-i2c7.c
 delete mode 100644 arch/arm/mach-exynos/setup-keypad.c
 delete mode 100644 arch/arm/mach-exynos/setup-sdhci-gpio.c
 delete mode 100644 arch/arm/mach-exynos/setup-spi.c
 delete mode 100644 arch/arm/mach-exynos/setup-usb-phy.c

diff --git a/arch/arm/configs/exynos4_defconfig b/arch/arm/configs/exynos4_defconfig
deleted file mode 100644
index bffe68e..0000000
diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index a62d979..b93d221 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -80,314 +80,13 @@ config SOC_EXYNOS5440
 	help
 	  Enable EXYNOS5440 SoC support
 
-config EXYNOS_DEV_DMA
-	bool
-	help
-	  Compile in amba device definitions for DMA controller
-
-config EXYNOS4_DEV_AHCI
-	bool
-	help
-	  Compile in platform device definitions for AHCI
-
-config EXYNOS4_SETUP_FIMD0
-	bool
-	help
-	  Common setup code for FIMD0.
-
-config EXYNOS4_DEV_USB_OHCI
-	bool
-	help
-	  Compile in platform device definition for USB OHCI
-
-config EXYNOS4_SETUP_I2C1
-	bool
-	help
-	  Common setup code for i2c bus 1.
-
-config EXYNOS4_SETUP_I2C2
-	bool
-	help
-	  Common setup code for i2c bus 2.
-
-config EXYNOS4_SETUP_I2C3
-	bool
-	help
-	  Common setup code for i2c bus 3.
-
-config EXYNOS4_SETUP_I2C4
-	bool
-	help
-	  Common setup code for i2c bus 4.
-
-config EXYNOS4_SETUP_I2C5
-	bool
-	help
-	  Common setup code for i2c bus 5.
-
-config EXYNOS4_SETUP_I2C6
-	bool
-	help
-	  Common setup code for i2c bus 6.
-
-config EXYNOS4_SETUP_I2C7
-	bool
-	help
-	  Common setup code for i2c bus 7.
-
-config EXYNOS4_SETUP_KEYPAD
-	bool
-	help
-	  Common setup code for keypad.
-
-config EXYNOS4_SETUP_SDHCI
-	bool
-	select EXYNOS4_SETUP_SDHCI_GPIO
-	help
-	  Internal helper functions for EXYNOS4 based SDHCI systems.
-
-config EXYNOS4_SETUP_SDHCI_GPIO
-	bool
-	help
-	  Common setup code for SDHCI gpio.
-
-config EXYNOS4_SETUP_FIMC
-	bool
-	help
-	  Common setup code for the camera interfaces.
-
-config EXYNOS4_SETUP_USB_PHY
-	bool
-	help
-	  Common setup code for USB PHY controller
-
-config EXYNOS_SETUP_SPI
-	bool
-	help
-	  Common setup code for SPI GPIO configurations.
-
 # machine support
 
-if ARCH_EXYNOS4
-
-comment "EXYNOS4210 Boards"
-
-config MACH_SMDKC210
-	bool "SMDKC210"
-	select MACH_SMDKV310
-	help
-	  Machine support for Samsung SMDKC210
-
-config MACH_SMDKV310
-	bool "SMDKV310"
-	select CPU_EXYNOS4210
-	select EXYNOS4_DEV_AHCI
-	select EXYNOS4_DEV_USB_OHCI
-	select EXYNOS4_SETUP_FIMD0
-	select EXYNOS4_SETUP_I2C1
-	select EXYNOS4_SETUP_KEYPAD
-	select EXYNOS4_SETUP_SDHCI
-	select EXYNOS4_SETUP_USB_PHY
-	select EXYNOS_DEV_DMA
-	select EXYNOS_DEV_SYSMMU
-	select S3C24XX_PWM
-	select S3C_DEV_HSMMC
-	select S3C_DEV_HSMMC1
-	select S3C_DEV_HSMMC2
-	select S3C_DEV_HSMMC3
-	select S3C_DEV_I2C1
-	select S3C_DEV_RTC
-	select S3C_DEV_USB_HSOTG
-	select S3C_DEV_WDT
-	select S5P_DEV_FIMC0
-	select S5P_DEV_FIMC1
-	select S5P_DEV_FIMC2
-	select S5P_DEV_FIMC3
-	select S5P_DEV_FIMD0
-	select S5P_DEV_G2D
-	select S5P_DEV_I2C_HDMIPHY
-	select S5P_DEV_JPEG
-	select S5P_DEV_MFC
-	select S5P_DEV_TV
-	select S5P_DEV_USB_EHCI
-	select SAMSUNG_DEV_BACKLIGHT
-	select SAMSUNG_DEV_KEYPAD
-	select SAMSUNG_DEV_PWM
-	help
-	  Machine support for Samsung SMDKV310
-
-config MACH_ARMLEX4210
-	bool "ARMLEX4210"
-	select CPU_EXYNOS4210
-	select EXYNOS4_DEV_AHCI
-	select EXYNOS4_SETUP_SDHCI
-	select EXYNOS_DEV_DMA
-	select S3C_DEV_HSMMC
-	select S3C_DEV_HSMMC2
-	select S3C_DEV_HSMMC3
-	select S3C_DEV_RTC
-	select S3C_DEV_WDT
-	help
-	  Machine support for Samsung ARMLEX4210 based on EXYNOS4210
-
-config MACH_UNIVERSAL_C210
-	bool "Mobile UNIVERSAL_C210 Board"
-	select CLKSRC_MMIO
-	select CPU_EXYNOS4210
-	select EXYNOS4_SETUP_FIMC
-	select EXYNOS4_SETUP_FIMD0
-	select EXYNOS4_SETUP_I2C1
-	select EXYNOS4_SETUP_I2C3
-	select EXYNOS4_SETUP_I2C5
-	select EXYNOS4_SETUP_SDHCI
-	select EXYNOS4_SETUP_USB_PHY
-	select EXYNOS_DEV_DMA
-	select EXYNOS_DEV_SYSMMU
-	select S3C_DEV_HSMMC
-	select S3C_DEV_HSMMC2
-	select S3C_DEV_HSMMC3
-	select S3C_DEV_I2C1
-	select S3C_DEV_I2C3
-	select S3C_DEV_I2C5
-	select S3C_DEV_USB_HSOTG
-	select S5P_DEV_CSIS0
-	select S5P_DEV_FIMC0
-	select S5P_DEV_FIMC1
-	select S5P_DEV_FIMC2
-	select S5P_DEV_FIMC3
-	select S5P_DEV_FIMD0
-	select S5P_DEV_G2D
-	select S5P_DEV_I2C_HDMIPHY
-	select S5P_DEV_JPEG
-	select S5P_DEV_MFC
-	select S5P_DEV_ONENAND
-	select S5P_DEV_TV
-	select S5P_GPIO_INT
-	select S5P_SETUP_MIPIPHY
-	select SAMSUNG_HRT
-	help
-	  Machine support for Samsung Mobile Universal S5PC210 Reference
-	  Board.
-
-config MACH_NURI
-	bool "Mobile NURI Board"
-	select CPU_EXYNOS4210
-	select EXYNOS4_SETUP_FIMC
-	select EXYNOS4_SETUP_FIMD0
-	select EXYNOS4_SETUP_I2C1
-	select EXYNOS4_SETUP_I2C3
-	select EXYNOS4_SETUP_I2C5
-	select EXYNOS4_SETUP_I2C6
-	select EXYNOS4_SETUP_SDHCI
-	select EXYNOS4_SETUP_USB_PHY
-	select EXYNOS_DEV_DMA
-	select S3C_DEV_HSMMC
-	select S3C_DEV_HSMMC2
-	select S3C_DEV_HSMMC3
-	select S3C_DEV_I2C1
-	select S3C_DEV_I2C3
-	select S3C_DEV_I2C5
-	select S3C_DEV_I2C6
-	select S3C_DEV_RTC
-	select S3C_DEV_USB_HSOTG
-	select S3C_DEV_WDT
-	select S5P_DEV_CSIS0
-	select S5P_DEV_FIMC0
-	select S5P_DEV_FIMC1
-	select S5P_DEV_FIMC2
-	select S5P_DEV_FIMC3
-	select S5P_DEV_FIMD0
-	select S5P_DEV_G2D
-	select S5P_DEV_JPEG
-	select S5P_DEV_MFC
-	select S5P_DEV_USB_EHCI
-	select S5P_GPIO_INT
-	select S5P_SETUP_MIPIPHY
-	select SAMSUNG_DEV_ADC
-	select SAMSUNG_DEV_PWM
-	help
-	  Machine support for Samsung Mobile NURI Board.
-
-config MACH_ORIGEN
-	bool "ORIGEN"
-	select CPU_EXYNOS4210
-	select EXYNOS4_DEV_USB_OHCI
-	select EXYNOS4_SETUP_FIMD0
-	select EXYNOS4_SETUP_SDHCI
-	select EXYNOS4_SETUP_USB_PHY
-	select EXYNOS_DEV_DMA
-	select EXYNOS_DEV_SYSMMU
-	select S3C24XX_PWM
-	select S3C_DEV_HSMMC
-	select S3C_DEV_HSMMC2
-	select S3C_DEV_RTC
-	select S3C_DEV_USB_HSOTG
-	select S3C_DEV_WDT
-	select S5P_DEV_FIMC0
-	select S5P_DEV_FIMC1
-	select S5P_DEV_FIMC2
-	select S5P_DEV_FIMC3
-	select S5P_DEV_FIMD0
-	select S5P_DEV_G2D
-	select S5P_DEV_I2C_HDMIPHY
-	select S5P_DEV_JPEG
-	select S5P_DEV_MFC
-	select S5P_DEV_TV
-	select S5P_DEV_USB_EHCI
-	select SAMSUNG_DEV_BACKLIGHT
-	select SAMSUNG_DEV_PWM
-	help
-	  Machine support for ORIGEN based on Samsung EXYNOS4210
-
-comment "EXYNOS4212 Boards"
-
-config MACH_SMDK4212
-	bool "SMDK4212"
-	select EXYNOS4_SETUP_FIMD0
-	select EXYNOS4_SETUP_I2C1
-	select EXYNOS4_SETUP_I2C3
-	select EXYNOS4_SETUP_I2C7
-	select EXYNOS4_SETUP_KEYPAD
-	select EXYNOS4_SETUP_SDHCI
-	select EXYNOS4_SETUP_USB_PHY
-	select EXYNOS_DEV_DMA
-	select EXYNOS_DEV_SYSMMU
-	select S3C24XX_PWM
-	select S3C_DEV_HSMMC2
-	select S3C_DEV_HSMMC3
-	select S3C_DEV_I2C1
-	select S3C_DEV_I2C3
-	select S3C_DEV_I2C7
-	select S3C_DEV_RTC
-	select S3C_DEV_USB_HSOTG
-	select S3C_DEV_WDT
-	select S5P_DEV_FIMC0
-	select S5P_DEV_FIMC1
-	select S5P_DEV_FIMC2
-	select S5P_DEV_FIMC3
-	select S5P_DEV_FIMD0
-	select S5P_DEV_MFC
-	select SAMSUNG_DEV_BACKLIGHT
-	select SAMSUNG_DEV_KEYPAD
-	select SAMSUNG_DEV_PWM
-	select SOC_EXYNOS4212
-	help
-	  Machine support for Samsung SMDK4212
-
-comment "EXYNOS4412 Boards"
-
-config MACH_SMDK4412
-	bool "SMDK4412"
-	select MACH_SMDK4212
-	select SOC_EXYNOS4412
-	help
-	  Machine support for Samsung SMDK4412
-endif
-
 comment "Flattened Device Tree based board for EXYNOS SoCs"
 
 config MACH_EXYNOS4_DT
 	bool "Samsung Exynos4 Machine using device tree"
+	default y
 	depends on ARCH_EXYNOS4
 	select ARM_AMBA
 	select CLKSRC_OF
diff --git a/arch/arm/mach-exynos/Makefile b/arch/arm/mach-exynos/Makefile
index b09b027..9811f87 100644
--- a/arch/arm/mach-exynos/Makefile
+++ b/arch/arm/mach-exynos/Makefile
@@ -32,16 +32,6 @@ AFLAGS_exynos-smc.o		:=-Wa,-march=armv7-a$(plus_sec)
 
 # machine support
 
-obj-$(CONFIG_MACH_SMDKC210)		+= mach-smdkv310.o
-obj-$(CONFIG_MACH_SMDKV310)		+= mach-smdkv310.o
-obj-$(CONFIG_MACH_ARMLEX4210)		+= mach-armlex4210.o
-obj-$(CONFIG_MACH_UNIVERSAL_C210)	+= mach-universal_c210.o
-obj-$(CONFIG_MACH_NURI)			+= mach-nuri.o
-obj-$(CONFIG_MACH_ORIGEN)		+= mach-origen.o
-
-obj-$(CONFIG_MACH_SMDK4212)		+= mach-smdk4x12.o
-obj-$(CONFIG_MACH_SMDK4412)		+= mach-smdk4x12.o
-
 obj-$(CONFIG_MACH_EXYNOS4_DT)		+= mach-exynos4-dt.o
 obj-$(CONFIG_MACH_EXYNOS5_DT)		+= mach-exynos5-dt.o
 
@@ -49,21 +39,5 @@ obj-$(CONFIG_MACH_EXYNOS5_DT)		+= mach-exynos5-dt.o
 
 obj-y					+= dev-uart.o
 obj-$(CONFIG_ARCH_EXYNOS4)		+= dev-audio.o
-obj-$(CONFIG_EXYNOS4_DEV_AHCI)		+= dev-ahci.o
-obj-$(CONFIG_EXYNOS_DEV_DMA)		+= dma.o
-obj-$(CONFIG_EXYNOS4_DEV_USB_OHCI)	+= dev-ohci.o
 
 obj-$(CONFIG_ARCH_EXYNOS)		+= setup-i2c0.o
-obj-$(CONFIG_EXYNOS4_SETUP_FIMC)	+= setup-fimc.o
-obj-$(CONFIG_EXYNOS4_SETUP_FIMD0)	+= setup-fimd0.o
-obj-$(CONFIG_EXYNOS4_SETUP_I2C1)	+= setup-i2c1.o
-obj-$(CONFIG_EXYNOS4_SETUP_I2C2)	+= setup-i2c2.o
-obj-$(CONFIG_EXYNOS4_SETUP_I2C3)	+= setup-i2c3.o
-obj-$(CONFIG_EXYNOS4_SETUP_I2C4)	+= setup-i2c4.o
-obj-$(CONFIG_EXYNOS4_SETUP_I2C5)	+= setup-i2c5.o
-obj-$(CONFIG_EXYNOS4_SETUP_I2C6)	+= setup-i2c6.o
-obj-$(CONFIG_EXYNOS4_SETUP_I2C7)	+= setup-i2c7.o
-obj-$(CONFIG_EXYNOS4_SETUP_KEYPAD)	+= setup-keypad.o
-obj-$(CONFIG_EXYNOS4_SETUP_SDHCI_GPIO)	+= setup-sdhci-gpio.o
-obj-$(CONFIG_EXYNOS4_SETUP_USB_PHY)	+= setup-usb-phy.o
-obj-$(CONFIG_EXYNOS_SETUP_SPI)		+= setup-spi.o
diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
index a8570bf..d5c36fd 100644
--- a/arch/arm/mach-exynos/common.c
+++ b/arch/arm/mach-exynos/common.c
@@ -357,7 +357,7 @@ void __init exynos_init_io(struct map_desc *mach_desc, int size)
 {
 	struct map_desc *iodesc = exynos_iodesc;
 	int iodesc_sz = ARRAY_SIZE(exynos_iodesc);
-#if defined(CONFIG_OF) && defined(CONFIG_ARCH_EXYNOS5)
+#if defined(CONFIG_ARCH_EXYNOS5)
 	unsigned long root = of_get_flat_dt_root();
 
 	/* initialize the io descriptors we need for initialization */
@@ -437,10 +437,8 @@ static void __init exynos5440_map_io(void)
 void __init exynos_init_time(void)
 {
 	if (of_have_populated_dt()) {
-#ifdef CONFIG_OF
 		of_clk_init(NULL);
 		clocksource_of_init();
-#endif
 	} else {
 		/* todo: remove after migrating legacy E4 platforms to dt */
 #ifdef CONFIG_ARCH_EXYNOS4
@@ -459,10 +457,8 @@ void __init exynos4_init_irq(void)
 
 	if (!of_have_populated_dt())
 		gic_init_bases(0, IRQ_PPI(0), S5P_VA_GIC_DIST, S5P_VA_GIC_CPU, gic_bank_offset, NULL);
-#ifdef CONFIG_OF
 	else
 		irqchip_init();
-#endif
 
 	if (!of_have_populated_dt())
 		combiner_init(S5P_VA_COMBINER_BASE, NULL);
@@ -479,9 +475,8 @@ void __init exynos4_init_irq(void)
 
 void __init exynos5_init_irq(void)
 {
-#ifdef CONFIG_OF
 	irqchip_init();
-#endif
+
 	/*
 	 * The parameters of s5p_init_irq() are for VIC init.
 	 * Theses parameters should be NULL and 0 because EXYNOS4
diff --git a/arch/arm/mach-exynos/dev-ahci.c b/arch/arm/mach-exynos/dev-ahci.c
deleted file mode 100644
index ce1aad3..0000000
diff --git a/arch/arm/mach-exynos/dev-ohci.c b/arch/arm/mach-exynos/dev-ohci.c
deleted file mode 100644
index d5bc129..0000000
diff --git a/arch/arm/mach-exynos/dma.c b/arch/arm/mach-exynos/dma.c
deleted file mode 100644
index 87e07d6..0000000
diff --git a/arch/arm/mach-exynos/mach-armlex4210.c b/arch/arm/mach-exynos/mach-armlex4210.c
deleted file mode 100644
index 2c23b65..0000000
diff --git a/arch/arm/mach-exynos/mach-nuri.c b/arch/arm/mach-exynos/mach-nuri.c
deleted file mode 100644
index 0c10852..0000000
diff --git a/arch/arm/mach-exynos/mach-origen.c b/arch/arm/mach-exynos/mach-origen.c
deleted file mode 100644
index f662345..0000000
diff --git a/arch/arm/mach-exynos/mach-smdk4x12.c b/arch/arm/mach-exynos/mach-smdk4x12.c
deleted file mode 100644
index 184faa3..0000000
diff --git a/arch/arm/mach-exynos/mach-smdkv310.c b/arch/arm/mach-exynos/mach-smdkv310.c
deleted file mode 100644
index ee815a7..0000000
diff --git a/arch/arm/mach-exynos/mach-universal_c210.c b/arch/arm/mach-exynos/mach-universal_c210.c
deleted file mode 100644
index 72f08fd..0000000
diff --git a/arch/arm/mach-exynos/pm_domains.c b/arch/arm/mach-exynos/pm_domains.c
index 9f1351d..beb946d 100644
--- a/arch/arm/mach-exynos/pm_domains.c
+++ b/arch/arm/mach-exynos/pm_domains.c
@@ -84,7 +84,6 @@ static struct exynos_pm_domain PD = {			\
 	},						\
 }
 
-#ifdef CONFIG_OF
 static void exynos_add_device_to_domain(struct exynos_pm_domain *pd,
 					 struct device *dev)
 {
@@ -193,12 +192,6 @@ static __init int exynos_pm_dt_parse_domains(void)
 
 	return 0;
 }
-#else
-static __init int exynos_pm_dt_parse_domains(void)
-{
-	return 0;
-}
-#endif /* CONFIG_OF */
 
 static __init __maybe_unused void exynos_pm_add_dev_to_genpd(struct platform_device *pdev,
 						struct exynos_pm_domain *pd)
diff --git a/arch/arm/mach-exynos/setup-fimc.c b/arch/arm/mach-exynos/setup-fimc.c
deleted file mode 100644
index 6a45078..0000000
diff --git a/arch/arm/mach-exynos/setup-fimd0.c b/arch/arm/mach-exynos/setup-fimd0.c
deleted file mode 100644
index 5665bb4..0000000
diff --git a/arch/arm/mach-exynos/setup-i2c1.c b/arch/arm/mach-exynos/setup-i2c1.c
deleted file mode 100644
index 8d2279c..0000000
diff --git a/arch/arm/mach-exynos/setup-i2c2.c b/arch/arm/mach-exynos/setup-i2c2.c
deleted file mode 100644
index 0ed62fc..0000000
diff --git a/arch/arm/mach-exynos/setup-i2c3.c b/arch/arm/mach-exynos/setup-i2c3.c
deleted file mode 100644
index 7787fd2..0000000
diff --git a/arch/arm/mach-exynos/setup-i2c4.c b/arch/arm/mach-exynos/setup-i2c4.c
deleted file mode 100644
index edc847f..0000000
diff --git a/arch/arm/mach-exynos/setup-i2c5.c b/arch/arm/mach-exynos/setup-i2c5.c
deleted file mode 100644
index d88af7f..0000000
diff --git a/arch/arm/mach-exynos/setup-i2c6.c b/arch/arm/mach-exynos/setup-i2c6.c
deleted file mode 100644
index c590286..0000000
diff --git a/arch/arm/mach-exynos/setup-i2c7.c b/arch/arm/mach-exynos/setup-i2c7.c
deleted file mode 100644
index 1bba755..0000000
diff --git a/arch/arm/mach-exynos/setup-keypad.c b/arch/arm/mach-exynos/setup-keypad.c
deleted file mode 100644
index 7862bfb..0000000
diff --git a/arch/arm/mach-exynos/setup-sdhci-gpio.c b/arch/arm/mach-exynos/setup-sdhci-gpio.c
deleted file mode 100644
index e8d08bf..0000000
diff --git a/arch/arm/mach-exynos/setup-spi.c b/arch/arm/mach-exynos/setup-spi.c
deleted file mode 100644
index 4999829..0000000
diff --git a/arch/arm/mach-exynos/setup-usb-phy.c b/arch/arm/mach-exynos/setup-usb-phy.c
deleted file mode 100644
index b81cc56..0000000
-- 
1.8.2.1.339.g52a3e01



From emilio at elopez.com.ar  Tue Apr  9 11:04:07 2013
From: emilio at elopez.com.ar (=?ISO-8859-1?Q?Emilio_L=F3pez?=)
Date: Tue, 09 Apr 2013 12:04:07 -0300
Subject: [PATCH 0/3] sunxi: unify main oscillator and its gate
In-Reply-To: <51642C08.6070600@free-electrons.com>
References: <1365515284-32061-1-git-send-email-emilio@elopez.com.ar>
 <51642C08.6070600@free-electrons.com>
Message-ID: <51642DE7.9060602@elopez.com.ar>

Hi Gregory,

El 09/04/13 11:56, Gregory CLEMENT escribi?:
> Hi Emilio,
> 
> On 04/09/2013 03:48 PM, Emilio L?pez wrote:
>> Hi Mike,
>>
>> As discussed previously when introducing the sunxi driver, this patchset
>> unifies the main oscillator ("osc24M_fixed") and its gate ("osc24M")
>> into a single clock ("osc24M"). It does so by adding fixed-rate support
>> into the composite clock and then using it to implement the new clock.
>>
>> The changes shouldn't require any modifications on current/future users 
>> of the composite clock, although I haven't tested any to make sure of 
>> it. @Prashant, can I get a tested-by from you if necessary?
> 
> This patch set is a nice improvement, now we will have the best of the
> two worlds: a 1-to-1 between the clock device in the device tree and the
> real hardware clock on one side, and the reuse of existing driver clock
> on the other side.
> 
> Could you indicate on which branch this patch set can be applied ? In
> 3.9-rc6 there is no file drivers/clk/clk-composite.c. I guess it should
> be the something like clk-next or clk-for-3.10 from Mike's git tree.

Yes, this should be applied on Mike's clk-next / clk-for-3.10, and
Maxime's tree for the DT part. Mike's branches contain both the sunxi
driver and clk-composite.c.

> Adding the branch where to apply the patch set is a good information to
> add to the cover letter of a patch set.

Indeed, I always forget to do so :/

Thanks,

Emilio


From arnd at arndb.de  Tue Apr  9 11:04:08 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 9 Apr 2013 17:04:08 +0200
Subject: [GIT PULL 6/8] ARM: tegra: device tree changes
In-Reply-To: <1365181426-11547-6-git-send-email-swarren@wwwdotorg.org>
References: <1365181426-11547-1-git-send-email-swarren@wwwdotorg.org>
 <1365181426-11547-6-git-send-email-swarren@wwwdotorg.org>
Message-ID: <201304091704.08446.arnd@arndb.de>

On Friday 05 April 2013, Stephen Warren wrote:
> Spam Status: Spamassassin 0% probability of being spam.
> 
> Full report:
> No, score=-4.2 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1  
> This branch contains the majority of the device tree changes for Tegra.
> Highlights include:
> 
> * Many changes for Tegra114, and the Dalmore board, to enable pinctrl,
>   SDHCI/MMC, PWM, DMA, I2C, KBC, SPI, battery, regulators.
> * Adding or enabling suspend wakeup sources on many boards, and adding
>   suspend timing parameters, to support the system suspend patches.
> * Adding clocks to the audio-related nodes, so that in 3.11, the audio
>   driver can pull these clocks from device tree rather than hard-coding
>   clock names.
> * Some small DT fixes/cleanup.
> 
> This branch is based on the previous clk pull request.

Hmm, I can't put this into the normal next/dt branch, since I really don't
want to add a dependency on the next/drivers branch there.

Can you send a replacement pull request that only contains the commits
that don't depend on that, and a separate request that can go on top
of next/drivers?

Alternatively, I could start a next/dt2 branch, but I'd like to avoid
that.

	Arnd


From p.zabel at pengutronix.de  Tue Apr  9 11:04:26 2013
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Tue, 09 Apr 2013 17:04:26 +0200
Subject: [PATCH v2 1/4] imx-drm: parallel-display: Fix valid_mode checking
In-Reply-To: <1365516452-1287-1-git-send-email-rogerio.pimentel@freescale.com>
References: <1365516452-1287-1-git-send-email-rogerio.pimentel@freescale.com>
Message-ID: <1365519866.4023.47.camel@pizza.hi.pengutronix.de>

Hi Rogerio,

Am Dienstag, den 09.04.2013, 11:07 -0300 schrieb Rogerio Pimentel:
> It fixes the logic of valid_mode checking, it's now
> in accordance with drm_mode_status enumeration.
> 
> Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
> Signed-off-by: Rogerio Pimentel <rogerio.pimentel at freescale.com>
> ---
> Changes since v1:
> Removed the "if(np)" block and now using the existent functions to get
> the modes by fixing the mode_valid logic test 
>  drivers/staging/imx-drm/parallel-display.c |    4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/staging/imx-drm/parallel-display.c b/drivers/staging/imx-drm/parallel-display.c
> index a8064fc..49c90c3 100644
> --- a/drivers/staging/imx-drm/parallel-display.c
> +++ b/drivers/staging/imx-drm/parallel-display.c
> @@ -64,7 +64,7 @@ static int imx_pd_connector_get_modes(struct drm_connector *connector)
>  		num_modes = drm_add_edid_modes(connector, imxpd->edid);
>  	}
>  
> -	if (imxpd->mode_valid) {
> +	if (imxpd->mode_valid == MODE_OK) {

It's a bit unfortunate that the imxpd->mode_valid variable is named the
same as the imx_pd_connector_helper_funcs.mode_valid callback, but it is
not the same. imxpd->mode_valid seems to be used as a bool here, and I
don't think that should stay the same.

>  		struct drm_display_mode *mode = drm_mode_create(connector->dev);
>  		drm_mode_copy(mode, &imxpd->mode);
>  		mode->type |= DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED,
> @@ -78,7 +78,7 @@ static int imx_pd_connector_get_modes(struct drm_connector *connector)
>  static int imx_pd_connector_mode_valid(struct drm_connector *connector,
>  			  struct drm_display_mode *mode)
>  {
> -	return 0;
> +	return MODE_OK;

This hunk is correct.

Eventually, we should check available display interface clock
frequencies here.

regards
Philipp



From p.zabel at pengutronix.de  Tue Apr  9 11:05:48 2013
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Tue, 09 Apr 2013 17:05:48 +0200
Subject: [PATCH v2 2/4] imx-drm: parallel-display: Make IPU KMS parse
 display-timings
In-Reply-To: <1365516452-1287-2-git-send-email-rogerio.pimentel@freescale.com>
References: <1365516452-1287-1-git-send-email-rogerio.pimentel@freescale.com>
 <1365516452-1287-2-git-send-email-rogerio.pimentel@freescale.com>
Message-ID: <1365519948.4023.49.camel@pizza.hi.pengutronix.de>

Am Dienstag, den 09.04.2013, 11:07 -0300 schrieb Rogerio Pimentel:
> This patch adds support for parsing of the DT display-timings prop
> to IPU KMS driver.
> 
> Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
> Signed-off-by: Marek Vasut <marex at denx.de>
> Signed-off-by: Rogerio Pimentel <rogerio.pimentel at freescale.com>
> ---
> Changes since v1:
> Moved the function of_get_drm_display_mode from 
> imx_pd_connector_get_modes function to probe function
>  drivers/staging/imx-drm/parallel-display.c |    2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/staging/imx-drm/parallel-display.c b/drivers/staging/imx-drm/parallel-display.c
> index 49c90c3..adc011d 100644
> --- a/drivers/staging/imx-drm/parallel-display.c
> +++ b/drivers/staging/imx-drm/parallel-display.c
> @@ -232,6 +232,8 @@ static int imx_pd_probe(struct platform_device *pdev)
>  
>  	platform_set_drvdata(pdev, imxpd);
>  
> +	of_get_drm_display_mode(np, &imxpd->mode, 0);
> +

I'd prefer something like

	ret = of_get_drm_display_mode(np, &imxpd->mode, 0);
	if (!ret)
		imxpd->mode_valid = 1;

here.

regards
Philipp



From hechtb at gmail.com  Tue Apr  9 11:06:36 2013
From: hechtb at gmail.com (Bastian Hecht)
Date: Tue, 9 Apr 2013 17:06:36 +0200
Subject: [PATCH v3 2/7] clocksource: sh_cmt: Add OF support
In-Reply-To: <20130409133805.GA21875@verge.net.au>
References: <1363535031-21402-1-git-send-email-hechtb+renesas@gmail.com>
 <1363535031-21402-2-git-send-email-hechtb+renesas@gmail.com>
 <20130321130714.GE24470@verge.net.au>
 <20130409133805.GA21875@verge.net.au>
Message-ID: <CABYn4sw20M=KB9kJN8HOD4ofdknSSKrUNzpss2e9aG-ELRMNrg@mail.gmail.com>

Hi Simon,

2013/4/9 Simon Horman <horms at verge.net.au>:
> On ?,  3? 21, 2013 at 10:07:15?? +0900, Simon Horman wrote:
>> On Sun, Mar 17, 2013 at 04:43:46PM +0100, Bastian Hecht wrote:
>> > We add the capabilty to probe SH CMT timer devices using Device Tree
>> > setup.
>> >
>> > Signed-off-by: Bastian Hecht <hechtb+renesas at gmail.com>
>> > ---
>> > v3: same (only patch 0003 changed)
>> >
>> >  drivers/clocksource/sh_cmt.c |  109 +++++++++++++++++++++++++++++++++++++-----
>>
>>
>> This change appears to break booting of kzm9g-reference
>> with MMC enabled. I assume because it somehow causes CMT to
>> (once again) be initialised after SDHI and/or MMC.
>>
>> Tested using next with the defconfig + CONFIG_MACH_KZM9G_REFERENCE=y +
>> initrd root fs.
>

Thanks for finding this flaw. I've got it on my agenda.

Bastian

>> >  1 file changed, 96 insertions(+), 13 deletions(-)
>> >
>> > diff --git a/drivers/clocksource/sh_cmt.c b/drivers/clocksource/sh_cmt.c
>> > index 08d0c41..79bc526 100644
>> > --- a/drivers/clocksource/sh_cmt.c
>> > +++ b/drivers/clocksource/sh_cmt.c
>> > @@ -34,10 +34,13 @@
>> >  #include <linux/module.h>
>> >  #include <linux/pm_domain.h>
>> >  #include <linux/pm_runtime.h>
>> > +#include <linux/of.h>
>> >
>> >  struct sh_cmt_priv {
>> >     void __iomem *mapbase;
>> >     struct clk *clk;
>> > +   long channel_offset;
>> > +   int timer_bit;
>> >     unsigned long width; /* 16 or 32 bit version of hardware block */
>> >     unsigned long overflow_bit;
>> >     unsigned long clear_bits;
>> > @@ -109,9 +112,7 @@ static void sh_cmt_write32(void __iomem *base, unsigned long offs,
>> >
>> >  static inline unsigned long sh_cmt_read_cmstr(struct sh_cmt_priv *p)
>> >  {
>> > -   struct sh_timer_config *cfg = p->pdev->dev.platform_data;
>> > -
>> > -   return p->read_control(p->mapbase - cfg->channel_offset, 0);
>> > +   return p->read_control(p->mapbase - p->channel_offset, 0);
>> >  }
>> >
>> >  static inline unsigned long sh_cmt_read_cmcsr(struct sh_cmt_priv *p)
>> > @@ -127,9 +128,7 @@ static inline unsigned long sh_cmt_read_cmcnt(struct sh_cmt_priv *p)
>> >  static inline void sh_cmt_write_cmstr(struct sh_cmt_priv *p,
>> >                                   unsigned long value)
>> >  {
>> > -   struct sh_timer_config *cfg = p->pdev->dev.platform_data;
>> > -
>> > -   p->write_control(p->mapbase - cfg->channel_offset, 0, value);
>> > +   p->write_control(p->mapbase - p->channel_offset, 0, value);
>> >  }
>> >
>> >  static inline void sh_cmt_write_cmcsr(struct sh_cmt_priv *p,
>> > @@ -176,7 +175,6 @@ static DEFINE_RAW_SPINLOCK(sh_cmt_lock);
>> >
>> >  static void sh_cmt_start_stop_ch(struct sh_cmt_priv *p, int start)
>> >  {
>> > -   struct sh_timer_config *cfg = p->pdev->dev.platform_data;
>> >     unsigned long flags, value;
>> >
>> >     /* start stop register shared by multiple timer channels */
>> > @@ -184,9 +182,9 @@ static void sh_cmt_start_stop_ch(struct sh_cmt_priv *p, int start)
>> >     value = sh_cmt_read_cmstr(p);
>> >
>> >     if (start)
>> > -           value |= 1 << cfg->timer_bit;
>> > +           value |= 1 << p->timer_bit;
>> >     else
>> > -           value &= ~(1 << cfg->timer_bit);
>> > +           value &= ~(1 << p->timer_bit);
>> >
>> >     sh_cmt_write_cmstr(p, value);
>> >     raw_spin_unlock_irqrestore(&sh_cmt_lock, flags);
>> > @@ -673,9 +671,85 @@ static int sh_cmt_register(struct sh_cmt_priv *p, char *name,
>> >     return 0;
>> >  }
>> >
>> > -static int sh_cmt_setup(struct sh_cmt_priv *p, struct platform_device *pdev)
>> > +static const struct of_device_id of_sh_cmt_match[] = {
>> > +   { .compatible = "renesas,cmt-timer" },
>> > +   {},
>> > +};
>> > +MODULE_DEVICE_TABLE(of, of_sh_cmt_match);
>> > +
>> > +static const int sh_cmt_offset_multiplier[] = { 0x60, 0x10, 0x40, 0x40, 0x40 };
>> > +#define CMT_MAX_CHANNELS   6
>> > +
>> > +static struct sh_timer_config *sh_cmt_parse_dt(struct device *dev)
>> > +{
>> > +   struct sh_timer_config *cfg;
>> > +   struct device_node *np = dev->of_node;
>> > +   u32 timer_id, channel_id, rating;
>> > +
>> > +   if (!IS_ENABLED(CONFIG_OF) || !np)
>> > +           return NULL;
>> > +
>> > +   cfg = devm_kzalloc(dev, sizeof(struct sh_timer_config), GFP_KERNEL);
>> > +   if (!cfg) {
>> > +           dev_err(dev, "failed to allocate DT config data\n");
>> > +           return NULL;
>> > +   }
>> > +
>> > +   if (of_property_read_u32(np, "renesas,device-id", &timer_id)) {
>> > +           dev_err(dev, "device id missing\n");
>> > +           return NULL;
>> > +   }
>> > +   if (timer_id >= ARRAY_SIZE(sh_cmt_offset_multiplier)) {
>> > +           dev_err(dev, "invalid device id\n");
>> > +           return NULL;
>> > +   }
>> > +
>> > +   if (of_property_read_u32(np, "renesas,channel-id", &channel_id)) {
>> > +           dev_err(dev, "channel id missing\n");
>> > +           return NULL;
>> > +   }
>> > +   if (channel_id >= CMT_MAX_CHANNELS) {
>> > +           dev_err(dev, "invalid channel id\n");
>> > +           return NULL;
>> > +   }
>> > +
>> > +   cfg->channel_offset = sh_cmt_offset_multiplier[timer_id] *
>> > +                                                   (channel_id + 1);
>> > +   cfg->timer_bit = channel_id;
>> > +
>> > +   /*
>> > +    * We convert the {source,event}-quality DT properties to linux specific
>> > +    * clock{source,event}_ratings.
>> > +    */
>> > +   if (!of_property_read_u32(np, "renesas,source-quality", &rating)) {
>> > +           if (rating > 10) {
>> > +                   dev_err(dev, "invalid source-quality\n");
>> > +                   return NULL;
>> > +           }
>> > +           if (rating)
>> > +                   cfg->clocksource_rating = rating * 50 - 1;
>> > +   }
>> > +
>> > +   if (!of_property_read_u32(np, "renesas,event-quality", &rating)) {
>> > +           if (rating > 10) {
>> > +                   dev_err(dev, "invalid event-quality\n");
>> > +                   return NULL;
>> > +           }
>> > +           if (rating)
>> > +                   cfg->clockevent_rating = rating * 50 - 1;
>> > +   }
>> > +
>> > +   if (!cfg->clocksource_rating && !cfg->clockevent_rating) {
>> > +           dev_err(dev, "source- and event-quality 0, timer is unused\n");
>> > +           return NULL;
>> > +   }
>> > +
>> > +   return cfg;
>> > +}
>> > +
>> > +static int sh_cmt_setup(struct sh_cmt_priv *p, struct platform_device *pdev,
>> > +                                           struct sh_timer_config *cfg)
>> >  {
>> > -   struct sh_timer_config *cfg = pdev->dev.platform_data;
>> >     struct resource *res;
>> >     int irq, ret;
>> >     ret = -ENXIO;
>> > @@ -762,6 +836,9 @@ static int sh_cmt_setup(struct sh_cmt_priv *p, struct platform_device *pdev)
>> >             goto err2;
>> >     }
>> >
>> > +   p->channel_offset = cfg->channel_offset;
>> > +   p->timer_bit = cfg->timer_bit;
>> > +
>> >     platform_set_drvdata(pdev, p);
>> >
>> >     return 0;
>> > @@ -777,7 +854,7 @@ err0:
>> >  static int sh_cmt_probe(struct platform_device *pdev)
>> >  {
>> >     struct sh_cmt_priv *p = platform_get_drvdata(pdev);
>> > -   struct sh_timer_config *cfg = pdev->dev.platform_data;
>> > +   struct sh_timer_config *cfg;
>> >     int ret;
>> >
>> >     if (!is_early_platform_device(pdev)) {
>> > @@ -785,6 +862,11 @@ static int sh_cmt_probe(struct platform_device *pdev)
>> >             pm_runtime_enable(&pdev->dev);
>> >     }
>> >
>> > +   if (pdev->dev.of_node)
>> > +           cfg = sh_cmt_parse_dt(&pdev->dev);
>> > +   else
>> > +           cfg = pdev->dev.platform_data;
>> > +
>> >     if (p) {
>> >             dev_info(&pdev->dev, "kept as earlytimer\n");
>> >             goto out;
>> > @@ -796,7 +878,7 @@ static int sh_cmt_probe(struct platform_device *pdev)
>> >             return -ENOMEM;
>> >     }
>> >
>> > -   ret = sh_cmt_setup(p, pdev);
>> > +   ret = sh_cmt_setup(p, pdev, cfg);
>> >     if (ret) {
>> >             kfree(p);
>> >             pm_runtime_idle(&pdev->dev);
>> > @@ -824,6 +906,7 @@ static struct platform_driver sh_cmt_device_driver = {
>> >     .remove         = sh_cmt_remove,
>> >     .driver         = {
>> >             .name   = "sh_cmt",
>> > +           .of_match_table = of_match_ptr(of_sh_cmt_match),
>> >     }
>> >  };
>> >
>> > --
>> > 1.7.9.5
>> >
>> > --
>> > To unsubscribe from this list: send the line "unsubscribe linux-sh" in
>> > the body of a message to majordomo at vger.kernel.org
>> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> >
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>


From kgene.kim at samsung.com  Tue Apr  9 11:07:36 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Wed, 10 Apr 2013 00:07:36 +0900
Subject: [PATCH] ARM: EXYNOS: no more support non-DT for EXYNOS SoCs
In-Reply-To: <201304091348.14887.arnd@arndb.de>
References: <2f3001ce3515$9a9ae1b0$cfd0a510$%kim@samsung.com>
 <2f3701ce3516$c29aca80$47d05f80$%kim@samsung.com>
 <201304091348.14887.arnd@arndb.de>
Message-ID: <51642EB8.8050107@samsung.com>

On 04/09/13 20:48, Arnd Bergmann wrote:
> On Tuesday 09 April 2013, Kukjin Kim wrote:
>> One more, as you know, we cannot support all features non-DT did only with
>> DT exynos. But I think, if required, some of them can be kept in samsung
>> tree temporarily.
>
> Which are the features that are going to be missing? Is it possible to
> add the ones that people are likely to miss using auxdata?
>
AFAIK, some of them such as sata, usb phy is on-going and...

>> Note, original patch couldn't submitted to linux arm kernel ml due to size.
>> And please ignore useless line wrapped due to e-mail client problem :-(
>
> You might be able to send it when you create the patch using 'git format-patch
> -M -D', which will leave out deleted files.
>
Thanks, I did as per your suggestion.

- Kukjin


From horms at verge.net.au  Tue Apr  9 11:11:47 2013
From: horms at verge.net.au (Simon Horman)
Date: Wed, 10 Apr 2013 00:11:47 +0900
Subject: [PATCH 0/8] Reorganize R8A7779/Marzen USB code
In-Reply-To: <516402CF.3060503@cogentembedded.com>
References: <201304050251.44464.sergei.shtylyov@cogentembedded.com>
 <87vc81ka6k.wl%kuninori.morimoto.gx@renesas.com>
 <516402CF.3060503@cogentembedded.com>
Message-ID: <20130409151147.GC27787@verge.net.au>

On Tue, Apr 09, 2013 at 04:00:15PM +0400, Sergei Shtylyov wrote:
> Hello.
> 
> On 05-04-2013 6:01, Kuninori Morimoto wrote:
> 
> >>    Here's the set of 4 patches against the Simon Horman's 'renesas.git' repo,
> >>'renesas-next-20130404v2' tag and the 2 Ether patches I've reposted yesterday.
> >>It was created to fix the shortcomings in the R8A7779/Marzen USB platform code
> >>and R8A7779 USB common PHY driver, and so spans both arch/arm/mach-shmobile/
> >>and drivers/usb/ subtrees (some patches have to touch both subtrees).
> >>The patches were conceived with the complete bisectability goal in mind.
> 
> >>[1/8] ARM: shmobile:Marzen: move USB EHCI, OHCI, and PHY devices to R8A7779 code
> >>[2/8] ehci-platform: add init() method to platform data
> >>[3/8] ARM: shmobile: R8A7779: setup EHCI internal buffer
> >>[4/8] rcar-phy: remove EHCI internal buffer setup
> >>[5/8] rcar-phy: correct base address
> >>[6/8] rcar-phy: add platform data
> >>[7/8] ARM: shmobile: Marzen: pass platform data to USB PHY device
> >>[8/8] rcar-phy: handle platform data
> 
> >>    I'm not sure thru which tree this patchset should be merged, however it turns
> >>out that it's too late now to push it thru Felipe Balbi's USB tree for 3.10, so
> >>maybe the patchset can be merged thru Simon's tree with Felipe's and Alan
> >>Stern's ACKs.
> 
> >I guess you already got request about patch style from Simon.
> >When you send v2 patch, could you please add "this patch is tested on xxxx bard"
> >on each patch's comment area ?
> 
>    I thought adding it to each patch (BTW, I didn't get what you
> meant: changelog or the area below ---) was a bit too much and just
> mentioned it in the cover letter.
> 
> >Then,
> >for all patches
> 
> >Acked-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
> 
>    Sorry, I forgot to add this. If you still want it, I'll add it to
> version 3 that will be posted today.

You can also add

Acked-by: Simon Horman <horms+renesas at verge.net.au>

I'll replace it with a Sob line if the patches
end up going through my tree.

> 
> >Best regards
> >---
> >Kuninori Morimoto
> 
> WBR, Sergei
> 


From arnd at arndb.de  Tue Apr  9 11:14:53 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 9 Apr 2013 17:14:53 +0200
Subject: [GIT PULL 5/8] ARM: tegra: clock driver development
In-Reply-To: <1365181426-11547-5-git-send-email-swarren@wwwdotorg.org>
References: <1365181426-11547-1-git-send-email-swarren@wwwdotorg.org>
 <1365181426-11547-5-git-send-email-swarren@wwwdotorg.org>
Message-ID: <201304091714.53220.arnd@arndb.de>

On Friday 05 April 2013, Stephen Warren wrote:
> This branch contains most fixes and enhancements to the Tegra common
> clock driver. The main new feature is a driver for Tegra114, which
> coupled with later device tree changes enables many devices on that
> chip, such as MMC, I2C, etc.
> 
> This branch depends on a patch in:
> 
> git://git.linaro.org/people/mturquette/linux.git clk-for-3.10

Pulled into next/drivers branch, and noted down the dependency.

As a general recommendation, it is nicer if you can prepare a
separate branch with the dependency, even if it's just one patch,
and have that pulled into both maintainer trees, rather than
having us add the entire set of clk changes as a dependency.

	Arnd


From arnd at arndb.de  Tue Apr  9 11:16:35 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 9 Apr 2013 17:16:35 +0200
Subject: [GIT PULL 8/8] ARM: tegra: defconfig changes
In-Reply-To: <1365181426-11547-8-git-send-email-swarren@wwwdotorg.org>
References: <1365181426-11547-1-git-send-email-swarren@wwwdotorg.org>
 <1365181426-11547-8-git-send-email-swarren@wwwdotorg.org>
Message-ID: <201304091716.36058.arnd@arndb.de>

On Friday 05 April 2013, Stephen Warren wrote:
> Various new features are enabled:
> 
> * Tegra114 support.
> * Various PMICs and related options for Tegra114 platforms.
> * KEYBOARD_GPIO, mainly as a suspend wakeup source.
> * tegra_defconfig is rebuilt based on v3.9-rc1, which causes various
>   layout changes.
> 
> This branch is based on v3.9-rc1.

Pulled into next/soc.

I'm currently thinking about creating a next/defconfig branch after all,
since we have a couple of pull requests in next/soc that only do
defconfig changes. Olof, any opinion?

	Arnd


From p.zabel at pengutronix.de  Tue Apr  9 11:17:23 2013
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Tue, 09 Apr 2013 17:17:23 +0200
Subject: [PATCH v2 3/4] ARM: dts: mx53qsb: Add support for parallel display
In-Reply-To: <1365516452-1287-3-git-send-email-rogerio.pimentel@freescale.com>
References: <1365516452-1287-1-git-send-email-rogerio.pimentel@freescale.com>
 <1365516452-1287-3-git-send-email-rogerio.pimentel@freescale.com>
Message-ID: <1365520643.4023.52.camel@pizza.hi.pengutronix.de>

Am Dienstag, den 09.04.2013, 11:07 -0300 schrieb Rogerio Pimentel:
> Add support for CLAA WVGA display for i.MX53 QSB.
> 
> Signed-off-by: Rogerio Pimentel <rogerio.pimentel at freescale.com>
> ---
> Changes since v1:
> Changed the label disp1 to disp0 to correctly match the display pins
>  arch/arm/boot/dts/imx53-qsb.dtsp |   26 ++++++++++++++++++++++++++
>  arch/arm/boot/dts/imx53.dtsip    |   35 +++++++++++++++++++++++++++++++++++
>  2 files changed, 61 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/imx53-qsb.dtsp b/arch/arm/boot/dts/imx53-qsb.dtsp
> index dae8d9f..6086a3c 100644
> --- a/arch/arm/boot/dts/imx53-qsb.dtsp
> +++ b/arch/arm/boot/dts/imx53-qsb.dtsp
> @@ -21,6 +21,32 @@
>  		reg = <0x70000000 0x40000000>;
>  	};
>  
> +	display at di0 {
> +		compatible = "fsl,imx-parallel-display";
> +		crtcs = <&ipu 0>;
> +		interface-pix-fmt = "rgb565";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&pinctrl_ipu_disp0_1>;
> +		display-timings {
> +			claawvga {
> +				native-mode;
> +				clock-frequency = <27000000>;
> +				hactive = <800>;
> +				vactive = <480>;
> +				hback-porch = <40>;
> +				hfront-porch = <60>;
> +				vback-porch = <10>;
> +				vfront-porch = <10>;
> +				hsync-len = <20>;
> +				vsync-len = <10>;
> +				hsync-active = <0>;
> +				vsync-active = <0>;
> +				de-active = <1>;
> +				pixelclk-active = <0>;
> +			};
> +		};
> +	};
> +

This clashes with the MCIMXHDMICARD daughter module, which has a sii902x
HDMI encoder connected to DISP0 for i.MX53-QSB. Would it make sense to
add all possible options to the device tree but mark them with
status = "disabled" by default?

regards
Philipp

>  	gpio-keys {
>  		compatible = "gpio-keys";
>  
> diff --git a/arch/arm/boot/dts/imx53.dtsip b/arch/arm/boot/dts/imx53.dtsip
> index 845982e..a5f9d68 100644
> --- a/arch/arm/boot/dts/imx53.dtsip
> +++ b/arch/arm/boot/dts/imx53.dtsip
> @@ -444,6 +444,41 @@
>  					};
>  				};
>  
> +				ipu_disp0 {
> +					pinctrl_ipu_disp0_1: ipudisp0grp-1 {
> +						fsl,pins = <
> +						MX53_PAD_DI0_DISP_CLK__IPU_DI0_DISP_CLK 0x5
> +						MX53_PAD_DI0_PIN15__IPU_DI0_PIN15 0x5
> +						MX53_PAD_DI0_PIN2__IPU_DI0_PIN2 0x5
> +						MX53_PAD_DI0_PIN3__IPU_DI0_PIN3  0x5
> +						MX53_PAD_DISP0_DAT0__IPU_DISP0_DAT_0 0x5
> +						MX53_PAD_DISP0_DAT1__IPU_DISP0_DAT_1 0x5
> +						MX53_PAD_DISP0_DAT2__IPU_DISP0_DAT_2 0x5
> +						MX53_PAD_DISP0_DAT3__IPU_DISP0_DAT_3 0x5
> +						MX53_PAD_DISP0_DAT4__IPU_DISP0_DAT_4 0x5
> +						MX53_PAD_DISP0_DAT5__IPU_DISP0_DAT_5 0x5
> +						MX53_PAD_DISP0_DAT6__IPU_DISP0_DAT_6 0x5
> +						MX53_PAD_DISP0_DAT7__IPU_DISP0_DAT_7 0x5
> +						MX53_PAD_DISP0_DAT8__IPU_DISP0_DAT_8 0x5
> +						MX53_PAD_DISP0_DAT9__IPU_DISP0_DAT_9 0x5
> +						MX53_PAD_DISP0_DAT10__IPU_DISP0_DAT_10 0x5
> +						MX53_PAD_DISP0_DAT11__IPU_DISP0_DAT_11 0x5
> +						MX53_PAD_DISP0_DAT12__IPU_DISP0_DAT_12 0x5
> +						MX53_PAD_DISP0_DAT13__IPU_DISP0_DAT_13 0x5
> +						MX53_PAD_DISP0_DAT14__IPU_DISP0_DAT_14 0x5
> +						MX53_PAD_DISP0_DAT15__IPU_DISP0_DAT_15 0x5
> +						MX53_PAD_DISP0_DAT16__IPU_DISP0_DAT_16 0x5
> +						MX53_PAD_DISP0_DAT17__IPU_DISP0_DAT_17 0x5
> +						MX53_PAD_DISP0_DAT18__IPU_DISP0_DAT_18 0x5
> +						MX53_PAD_DISP0_DAT19__IPU_DISP0_DAT_19 0x5
> +						MX53_PAD_DISP0_DAT20__IPU_DISP0_DAT_20 0x5
> +						MX53_PAD_DISP0_DAT21__IPU_DISP0_DAT_21 0x5
> +						MX53_PAD_DISP0_DAT22__IPU_DISP0_DAT_22 0x5
> +						MX53_PAD_DISP0_DAT23__IPU_DISP0_DAT_23 0x5
> +						>;
> +					};
> +				};
> +
>  				owire {
>  					pinctrl_owire_1: owiregrp-1 {
>  						fsl,pins = <




From shawn.guo at linaro.org  Tue Apr  9 11:19:32 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 9 Apr 2013 23:19:32 +0800
Subject: [GIT PULL 1/4] ARM: imx: noncritical fixes for 3.10
Message-ID: <1365520775-28478-1-git-send-email-shawn.guo@linaro.org>

The following changes since commit 07961ac7c0ee8b546658717034fe692fd12eefa9:

  Linux 3.9-rc5 (2013-03-31 15:12:43 -0700)

are available in the git repository at:

  git://git.linaro.org/people/shawnguo/linux-2.6.git tags/imx-noncritical-fixes-3.10

for you to fetch changes up to 4f5ef62ced8e7e01179de734856e03bddb06389c:

  ARM: cpuimx27 and mbimx27: prepend CONFIG_ to Kconfig macro (2013-04-03 16:50:54 +0800)

----------------------------------------------------------------
The imx noncritical fixes for 3.10:

* A bunch of fixes for sparse warings
* One fix for the typo in use of Kconfig symbol
  MACH_EUKREA_CPUIMX27_USEUART4

----------------------------------------------------------------
Fabio Estevam (15):
      ARM: mach-imx: cpu: Include "common.h"
      ARM: mach-imx: mm-imx3: Staticize imx3_init_l2x0()
      ARM: mach-imx: iomux-imx31: Staticize mxc_pin_alloc_map
      ARM: mach-imx: cpu-imx5: Include "common.h"
      ARM: mach-imx: clk-pllv1: Staticize clk_pllv1_ops
      ARM: mach-imx: clk-pllv2: Staticize clk_pllv2_ops
      ARM: mach-imx: clk-gate2: Include "clk.h"
      ARM: mach-imx: irq-common: Remove imx_irq_set_priority()
      ARM: mach-imx: clk-busy: Staticize clk_busy_mux_ops
      ARM: mach-imx: clk: Include "clk.h"
      ARM: mach-imx: tzic: Staticize *tzic_base
      ARM: mach-imx: avic: Staticize *avic_base
      ARM: mach-imx: gpc: Include "common.h"
      ARM: mach-imx: src: Include "common.h
      ARM: mach-imx: mach-imx6q: Fix sparse warnings

Paul Bolle (1):
      ARM: cpuimx27 and mbimx27: prepend CONFIG_ to Kconfig macro

 arch/arm/mach-imx/avic.c                     |    2 +-
 arch/arm/mach-imx/clk-busy.c                 |    2 +-
 arch/arm/mach-imx/clk-gate2.c                |    1 +
 arch/arm/mach-imx/clk-pllv1.c                |    2 +-
 arch/arm/mach-imx/clk-pllv2.c                |    2 +-
 arch/arm/mach-imx/clk.c                      |    1 +
 arch/arm/mach-imx/cpu-imx5.c                 |    1 +
 arch/arm/mach-imx/cpu.c                      |    1 +
 arch/arm/mach-imx/eukrea_mbimx27-baseboard.c |    4 ++--
 arch/arm/mach-imx/gpc.c                      |    1 +
 arch/arm/mach-imx/iomux-imx31.c              |    2 +-
 arch/arm/mach-imx/irq-common.c               |   19 -------------------
 arch/arm/mach-imx/mach-cpuimx27.c            |    4 ++--
 arch/arm/mach-imx/mach-imx6q.c               |    4 ++--
 arch/arm/mach-imx/mm-imx3.c                  |    2 +-
 arch/arm/mach-imx/src.c                      |    1 +
 arch/arm/mach-imx/tzic.c                     |    2 +-
 17 files changed, 19 insertions(+), 32 deletions(-)



From shawn.guo at linaro.org  Tue Apr  9 11:19:33 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 9 Apr 2013 23:19:33 +0800
Subject: [GIT PULL 2/4] ARM: imx: cleanup for 3.10
In-Reply-To: <1365520775-28478-1-git-send-email-shawn.guo@linaro.org>
References: <1365520775-28478-1-git-send-email-shawn.guo@linaro.org>
Message-ID: <1365520775-28478-2-git-send-email-shawn.guo@linaro.org>

The following changes since commit 07961ac7c0ee8b546658717034fe692fd12eefa9:

  Linux 3.9-rc5 (2013-03-31 15:12:43 -0700)

are available in the git repository at:

  git://git.linaro.org/people/shawnguo/linux-2.6.git tags/imx-cleanup-3.10

for you to fetch changes up to 3442a7b51d1cfae144f3289ab0be44e27c236f53:

  ARM: i.MX: remove unused ARCH_* configs (2013-04-09 21:07:36 +0800)

----------------------------------------------------------------
The imx cleanup for 3.10:

* Clean up a couple of unneeded function declarations
* Remove imx specific cpufreq driver as generic cpufreq-cpu0 works well
  as the replacement
* Remove platform ahci support
* Clean up unused ARCH/MACH Kconfig symbols
* Remove a couple of unused files

----------------------------------------------------------------
Fabio Estevam (2):
      ARM: imx: avic: Move avic_saved_mask_reg under CONFIG_PM
      ARM: imx: clk-imx27: Do not register peripheral clock for SSI

Markus Pargmann (1):
      ARM: imx: Remove cpufreq driver

Paul Bolle (1):
      ARM: i.MX: remove unused ARCH_* configs

Sascha Hauer (1):
      ARM i.MX53: remove platform ahci support

Shawn Guo (4):
      ARM: imx: remove duplicated function declaration
      ARM: imx: remove pl310_get_save_ptr() declaration
      ARM: imx: remove Makefile.boot
      ARM: imx: remove mx6q.h

 arch/arm/Kconfig                              |    7 -
 arch/arm/mach-imx/Kconfig                     |   18 ---
 arch/arm/mach-imx/Makefile                    |    3 +-
 arch/arm/mach-imx/Makefile.boot               |   35 -----
 arch/arm/mach-imx/avic.c                      |    4 +-
 arch/arm/mach-imx/clk-imx27.c                 |    2 -
 arch/arm/mach-imx/common.h                    |    3 -
 arch/arm/mach-imx/cpu_op-mx51.c               |   31 ----
 arch/arm/mach-imx/cpu_op-mx51.h               |   14 --
 arch/arm/mach-imx/cpufreq.c                   |  206 -------------------------
 arch/arm/mach-imx/devices/Kconfig             |    4 -
 arch/arm/mach-imx/devices/Makefile            |    1 -
 arch/arm/mach-imx/devices/devices-common.h    |   10 --
 arch/arm/mach-imx/devices/platform-ahci-imx.c |  157 -------------------
 arch/arm/mach-imx/hardware.h                  |    1 -
 arch/arm/mach-imx/mach-cpuimx51sd.c           |    5 -
 arch/arm/mach-imx/mach-mx51_babbage.c         |    4 -
 arch/arm/mach-imx/mx6q.h                      |   31 ----
 18 files changed, 3 insertions(+), 533 deletions(-)
 delete mode 100644 arch/arm/mach-imx/Makefile.boot
 delete mode 100644 arch/arm/mach-imx/cpu_op-mx51.c
 delete mode 100644 arch/arm/mach-imx/cpu_op-mx51.h
 delete mode 100644 arch/arm/mach-imx/cpufreq.c
 delete mode 100644 arch/arm/mach-imx/devices/platform-ahci-imx.c
 delete mode 100644 arch/arm/mach-imx/mx6q.h



From shawn.guo at linaro.org  Tue Apr  9 11:19:34 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 9 Apr 2013 23:19:34 +0800
Subject: [GIT PULL 3/4] ARM: imx: soc changes for 3.10
In-Reply-To: <1365520775-28478-1-git-send-email-shawn.guo@linaro.org>
References: <1365520775-28478-1-git-send-email-shawn.guo@linaro.org>
Message-ID: <1365520775-28478-3-git-send-email-shawn.guo@linaro.org>

Hi Arnd, Olof,

It's based on imx-cleanup-3.10 and Philipp Zabel's "Reset controller
API" pull request to resolve dependency and conflicts.

There will still be one trivial conflict with your clksrc/cleanup
branch.  My for-next branch contains the resolution.

Shawn

The following changes since commit a86a36ef05484eea7144bbf06e2194c831c325de:

  Merge remote-tracking branch 'pza/reset/for_v3.10' into imx/soc (2013-04-09 21:50:50 +0800)

are available in the git repository at:


  git://git.linaro.org/people/shawnguo/linux-2.6.git tags/imx-soc-3.10

for you to fetch changes up to 723bf2b0844f1d2435b8ffa4e706962a6a852179:

  ARM i.MX53: set CLK_SET_RATE_PARENT flag on the tve_ext_sel clock (2013-04-09 21:52:14 +0800)

----------------------------------------------------------------
The imx soc changes for 3.10:

* Enable anatop, well bisa and RBC for suspend to optimize the power
  consumption a little bit
* Clock changes for TVE, LDB, PATA, SRTC support
* Add System Reset Controller (SRC) support for imx5 and imx6
* Add initial imx6dl support based on imx6q code
* Kconfig for cpufreq-cpu0, defconfig updates and few other changes

----------------------------------------------------------------
Anson Huang (3):
      ARM: imx: enable anatop suspend/resume
      ARM: imx: enable periphery well bias for suspend
      ARM: imx: enable RBC to support anatop LPM mode

Fabio Estevam (3):
      ARM: mach-imx: anatop: Include "common.h"
      ARM: imx_v6_v7_defconfig: Select CONFIG_PERF_EVENTS
      ARM: imx_v4_v5_defconfig: Add CONFIG_GPIO_SYSFS

Gwenhael Goavec-Merou (1):
      ARM: imx1: mm: add call to mxc_device_init

Markus Pargmann (1):
      ARM: imx27, imx5: Add kconfig selects for cpufreq-cpu0

Martin Fuzzey (1):
      ARM: i.MX53 Add the cko1, cko2 clock outputs.

Philipp Zabel (14):
      ARM i.MX53: Add GPU clocks to clock tree
      ARM i.MX6q: export imx6q_revision
      ARM i.MX: Add imx_clk_divider_flags and imx_clk_mux_flags
      ARM i.MX53: fix ldb di divider and selector clocks
      ARM i.MX6q: fix ldb di divider and selector clocks
      ARM i.MX6q: Add audio/video PLL post dividers for i.MX6q rev 1.1
      ARM i.MX6q: set the LDB serial clock parent to the video PLL
      ARM i.MX6q: Add GPU, VPU, IPU, and OpenVG resets to System Reset Controller (SRC)
      staging: drm/imx: Use SRC to reset IPU
      ARM i.MX5: Remove tve_sel clock from i.MX53 clock tree
      ARM i.MX53: Remove unused tve_gate clkdev entry
      ARM i.MX53: make tve_ext_sel propagate rate change to PLL
      ARM i.MX53: tve_di clock is not part of the CCM, but of TVE
      ARM i.MX53: set CLK_SET_RATE_PARENT flag on the tve_ext_sel clock

Sascha Hauer (1):
      ARM: i.MX5: Add PATA and SRTC clocks

Shawn Guo (3):
      ARM: imx: do not use regmap_read for ANADIG_DIGPROG
      ARM: imx: add initial imx6dl support
      ARM: imx: do not bring up unavailable cores

 .../devicetree/bindings/clock/imx5-clock.txt       |   14 ++-
 .../devicetree/bindings/clock/imx6q-clock.txt      |    3 +
 .../devicetree/bindings/reset/fsl,imx-src.txt      |   49 ++++++++
 .../bindings/staging/imx-drm/fsl-imx-drm.txt       |    3 +
 arch/arm/Kconfig.debug                             |    4 +-
 arch/arm/configs/imx_v4_v5_defconfig               |    1 +
 arch/arm/configs/imx_v6_v7_defconfig               |    1 +
 arch/arm/mach-imx/Kconfig                          |   10 +-
 arch/arm/mach-imx/Makefile                         |    1 +
 arch/arm/mach-imx/anatop.c                         |  103 ++++++++++++++++
 arch/arm/mach-imx/clk-imx51-imx53.c                |   75 +++++++++---
 arch/arm/mach-imx/clk-imx6q.c                      |  128 ++++++++++++++++++--
 arch/arm/mach-imx/clk.h                            |   17 +++
 arch/arm/mach-imx/common.h                         |   10 +-
 arch/arm/mach-imx/gpc.c                            |   23 +++-
 arch/arm/mach-imx/mach-imx6q.c                     |   74 ++++-------
 arch/arm/mach-imx/mm-imx1.c                        |    2 +
 arch/arm/mach-imx/mxc.h                            |   11 ++
 arch/arm/mach-imx/platsmp.c                        |    4 +-
 arch/arm/mach-imx/pm-imx6q.c                       |    4 +-
 arch/arm/mach-imx/src.c                            |   65 ++++++++++
 drivers/staging/imx-drm/ipu-v3/ipu-common.c        |   12 +-
 22 files changed, 525 insertions(+), 89 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/reset/fsl,imx-src.txt
 create mode 100644 arch/arm/mach-imx/anatop.c



From shawn.guo at linaro.org  Tue Apr  9 11:19:35 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 9 Apr 2013 23:19:35 +0800
Subject: [GIT PULL 4/4] ARM: imx: device tree changes for 3.10
In-Reply-To: <1365520775-28478-1-git-send-email-shawn.guo@linaro.org>
References: <1365520775-28478-1-git-send-email-shawn.guo@linaro.org>
Message-ID: <1365520775-28478-4-git-send-email-shawn.guo@linaro.org>

Hi Arnd, Olof,

It's based on imx-cleanup-3.10 and Stephen Warren's "[GIT PULL] dt:
run C pre-processor on *.dts, create some standard headers" to resolve
dependency and conflicts.

Shawn

The following changes since commit 8b9ad9f67d094efd2c2765d82cc1866bee9052c2:

  Merge remote-tracking branch 'swarren/for-3.10/dtc-cpp-chroot-std-headers' into imx/dt (2013-04-09 22:52:42 +0800)

are available in the git repository at:


  git://git.linaro.org/people/shawnguo/linux-2.6.git tags/imx-dt-3.10

for you to fetch changes up to 4b23185ff5e1c2ada2845002a034e8840ab98b63:

  ARM: dts: imx6dl-wandboard: Add USB Host support (2013-04-09 22:53:40 +0800)

----------------------------------------------------------------
The imx device tree changes for 3.10:

* The huge diff stat is introduced by the pinctrl changes.  With DTC
  macro support ready, we're moving those huge mount of data about pins
  out of pinctrl driver.
* Device tree source updates for GPI, LDB, SRC, cpufreq-cpu0.
* Initial imx6dl device tree support
* Board level DTS changes for some imx27 and imx51 platforms.

----------------------------------------------------------------
Alexander Shiyan (2):
      ARM: dts: Add NFC support for i.MX27 Phytec PCM038 module
      ARM: dts: Add missing imx27-phytec-phycore dtb target

Dirk Behme (1):
      ARM: dts: imx6q: add PMU

Fabio Estevam (3):
      ARM: mx27: Replace clk_register_clkdev with clock DT lookup
      ARM: dts: Add initial support for Wandboard Dual-Lite
      ARM: dts: imx6dl-wandboard: Add USB Host support

Gwenhael Goavec-Merou (5):
      ARM: imx: Add support for the Armadeus Systems APF51Dev docking board
      ARM: imx51: Add pinctrl for ecspi2
      ARM: imx51: Add a second pinctrl group for i2c2
      ARM: imx: apf51dev: add ecspi1, ecspi2 and i2c2 support
      ARM: imx: Add support for the Armadeus Systems APF27Dev docking board

Marek Vasut (1):
      ARM: dts: imx53: fix SD2_DATA1 pad AUDMUX_AUD4 configuration

Markus Pargmann (3):
      ARM: imx27 DT init cpufreq-cpu0 device
      ARM: imx5 DT init cpufreq-cpu0 device
      ARM: dts: imx51 cpu node

Pavel Machek (1):
      ARM: dts: MicroSys sbc6x support (i.MX6)

Peter Chen (1):
      ARM: dts: imx6q-sabresd: Add USB support

Philipp Zabel (6):
      ARM i.MX5: Move IPU clock lookups into device tree
      ARM i.MX53: Add IOMUXC GPR to device tree
      ARM i.MX53: Add LDB device to device tree
      ARM i.MX6q: Link system reset controller (SRC) to IPU in DT
      ARM i.MX5: Add system reset controller (SRC) to i.MX51 and i.MX53 device tree
      ARM i.MX5: Add System Reset Controller (SRC) support for i.MX51 and i.MX53

Sascha Hauer (8):
      ARM: i.MX: Add GPT devicetree Documentation
      ARM: i.MX27: Add GPT devicetree nodes
      ARM: i.MX31: Add GPT devicetree node
      ARM: i.MX51: Add GPT devicetree node
      ARM: i.MX53: Add GPT devicetree node
      ARM: i.MX6: Add clocks to GPT devicetree node
      ARM: i.MX27: Add clocks to GPT devicetree nodes
      ARM: i.MX51: Add PATA support

Sean Cross (3):
      ARM: dts: imx6q: Add pinctrl for ecspi3
      ARM: dts: imx6q: Add pinctrl for i2c2 and i2c3
      ARM: dts: imx6q: Add pinctrl for audmix on AUD3

Shawn Guo (7):
      ARM: imx: use #include for all device trees
      pinctrl: imx: move hard-coding data into device tree
      pinctrl: add pinctrl driver for imx6dl
      pinctrl: add pinctrl driver for imx6sl
      ARM: dts: imx: make sabreauto and sabresd common
      ARM: dts: imx: add initial imx6dl-sabresd support
      ARM: dts: imx: add initial imx6dl-sabreauto support

Steffen Trumtrar (1):
      ARM i.MX6q: Add LDB device to device tree

 .../devicetree/bindings/clock/imx27-clock.txt      |  117 +
 .../bindings/pinctrl/fsl,imx-pinctrl.txt           |    6 +-
 .../bindings/pinctrl/fsl,imx35-pinctrl.txt         |  955 +-------
 .../bindings/pinctrl/fsl,imx51-pinctrl.txt         |  759 +------
 .../bindings/pinctrl/fsl,imx53-pinctrl.txt         | 1174 +---------
 .../bindings/pinctrl/fsl,imx6dl-pinctrl.txt        |   38 +
 .../bindings/pinctrl/fsl,imx6q-pinctrl.txt         | 1596 +-------------
 .../bindings/pinctrl/fsl,imx6sl-pinctrl.txt        |   39 +
 .../devicetree/bindings/timer/fsl,imxgpt.txt       |   18 +
 arch/arm/boot/dts/Makefile                         |    9 +-
 arch/arm/boot/dts/imx25-karo-tx25.dts              |    2 +-
 arch/arm/boot/dts/imx25-pdk.dts                    |    2 +-
 arch/arm/boot/dts/imx25.dtsi                       |    2 +-
 arch/arm/boot/dts/imx27-apf27.dts                  |    2 +-
 arch/arm/boot/dts/imx27-apf27dev.dts               |   60 +
 arch/arm/boot/dts/imx27-pdk.dts                    |    2 +-
 arch/arm/boot/dts/imx27-phytec-phycore.dts         |    8 +-
 arch/arm/boot/dts/imx27.dtsi                       |   82 +-
 arch/arm/boot/dts/imx31-bug.dts                    |    2 +-
 arch/arm/boot/dts/imx31.dtsi                       |   18 +-
 arch/arm/boot/dts/imx35-pinfunc.h                  |  970 +++++++++
 arch/arm/boot/dts/imx51-apf51.dts                  |    2 +-
 arch/arm/boot/dts/imx51-apf51dev.dts               |   97 +
 arch/arm/boot/dts/imx51-babbage.dts                |   16 +-
 arch/arm/boot/dts/imx51-pinfunc.h                  |  773 +++++++
 arch/arm/boot/dts/imx51.dtsi                       |  343 +--
 arch/arm/boot/dts/imx53-ard.dts                    |   70 +-
 arch/arm/boot/dts/imx53-evk.dts                    |   18 +-
 arch/arm/boot/dts/imx53-mba53.dts                  |   82 +-
 arch/arm/boot/dts/imx53-pinfunc.h                  | 1189 ++++++++++
 arch/arm/boot/dts/imx53-qsb.dts                    |   22 +-
 arch/arm/boot/dts/imx53-smd.dts                    |   16 +-
 arch/arm/boot/dts/imx53-tqma53.dtsi                |   32 +-
 arch/arm/boot/dts/imx53.dtsi                       |  256 ++-
 arch/arm/boot/dts/imx6dl-pinfunc.h                 | 1085 +++++++++
 arch/arm/boot/dts/imx6dl-sabreauto.dts             |   31 +
 arch/arm/boot/dts/imx6dl-sabresd.dts               |   35 +
 arch/arm/boot/dts/imx6dl-wandboard.dts             |   44 +
 arch/arm/boot/dts/imx6dl.dtsi                      |  125 +-
 arch/arm/boot/dts/imx6q-arm2.dts                   |    8 +-
 arch/arm/boot/dts/imx6q-pinfunc.h                  | 1041 +++++++++
 arch/arm/boot/dts/imx6q-sabreauto.dts              |   33 +-
 arch/arm/boot/dts/imx6q-sabrelite.dts              |   18 +-
 arch/arm/boot/dts/imx6q-sabresd.dts                |   67 +-
 arch/arm/boot/dts/imx6q-sbc6x.dts                  |   44 +
 arch/arm/boot/dts/imx6q.dtsi                       |  280 ++-
 arch/arm/boot/dts/imx6qdl-sabreauto.dtsi           |   38 +
 arch/arm/boot/dts/imx6qdl-sabresd.dtsi             |   87 +
 arch/arm/boot/dts/imx6qdl.dtsi                     |   33 +-
 arch/arm/boot/dts/imx6sl-pinfunc.h                 | 1077 +++++++++
 arch/arm/mach-imx/Kconfig                          |    2 +
 arch/arm/mach-imx/clk-imx27.c                      |   11 +-
 arch/arm/mach-imx/clk-imx51-imx53.c                |    9 +-
 arch/arm/mach-imx/imx27-dt.c                       |   22 +-
 arch/arm/mach-imx/imx51-dt.c                       |    3 +
 arch/arm/mach-imx/mm-imx5.c                        |    2 +
 arch/arm/mach-imx/src.c                            |    4 +-
 drivers/pinctrl/Kconfig                            |   12 +-
 drivers/pinctrl/Makefile                           |    1 +
 drivers/pinctrl/pinctrl-imx.c                      |  126 +-
 drivers/pinctrl/pinctrl-imx.h                      |   29 +-
 drivers/pinctrl/pinctrl-imx35.c                    | 2088 +++++++-----------
 drivers/pinctrl/pinctrl-imx51.c                    | 1532 +++++--------
 drivers/pinctrl/pinctrl-imx53.c                    | 1597 ++------------
 drivers/pinctrl/pinctrl-imx6dl.c                   |  497 +++++
 drivers/pinctrl/pinctrl-imx6q.c                    | 2301 ++------------------
 drivers/pinctrl/pinctrl-imx6sl.c                   |  403 ++++
 67 files changed, 10490 insertions(+), 10972 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/clock/imx27-clock.txt
 create mode 100644 Documentation/devicetree/bindings/pinctrl/fsl,imx6dl-pinctrl.txt
 create mode 100644 Documentation/devicetree/bindings/pinctrl/fsl,imx6sl-pinctrl.txt
 create mode 100644 Documentation/devicetree/bindings/timer/fsl,imxgpt.txt
 create mode 100644 arch/arm/boot/dts/imx27-apf27dev.dts
 create mode 100644 arch/arm/boot/dts/imx35-pinfunc.h
 create mode 100644 arch/arm/boot/dts/imx51-apf51dev.dts
 create mode 100644 arch/arm/boot/dts/imx51-pinfunc.h
 create mode 100644 arch/arm/boot/dts/imx53-pinfunc.h
 create mode 100644 arch/arm/boot/dts/imx6dl-pinfunc.h
 create mode 100644 arch/arm/boot/dts/imx6dl-sabreauto.dts
 create mode 100644 arch/arm/boot/dts/imx6dl-sabresd.dts
 create mode 100644 arch/arm/boot/dts/imx6dl-wandboard.dts
 create mode 100644 arch/arm/boot/dts/imx6q-pinfunc.h
 create mode 100644 arch/arm/boot/dts/imx6q-sbc6x.dts
 create mode 100644 arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
 create mode 100644 arch/arm/boot/dts/imx6qdl-sabresd.dtsi
 create mode 100644 arch/arm/boot/dts/imx6sl-pinfunc.h
 create mode 100644 drivers/pinctrl/pinctrl-imx6dl.c
 create mode 100644 drivers/pinctrl/pinctrl-imx6sl.c



From p.zabel at pengutronix.de  Tue Apr  9 11:19:51 2013
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Tue, 09 Apr 2013 17:19:51 +0200
Subject: [PATCH v2 2/4] imx-drm: parallel-display: Make IPU KMS parse
 display-timings
In-Reply-To: <1365519948.4023.49.camel@pizza.hi.pengutronix.de>
References: <1365516452-1287-1-git-send-email-rogerio.pimentel@freescale.com>
 <1365516452-1287-2-git-send-email-rogerio.pimentel@freescale.com>
 <1365519948.4023.49.camel@pizza.hi.pengutronix.de>
Message-ID: <1365520791.4023.55.camel@pizza.hi.pengutronix.de>

Am Dienstag, den 09.04.2013, 17:05 +0200 schrieb Philipp Zabel:
> Am Dienstag, den 09.04.2013, 11:07 -0300 schrieb Rogerio Pimentel:
> > This patch adds support for parsing of the DT display-timings prop
> > to IPU KMS driver.
> > 
> > Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
> > Signed-off-by: Marek Vasut <marex at denx.de>
> > Signed-off-by: Rogerio Pimentel <rogerio.pimentel at freescale.com>
> > ---
> > Changes since v1:
> > Moved the function of_get_drm_display_mode from 
> > imx_pd_connector_get_modes function to probe function
> >  drivers/staging/imx-drm/parallel-display.c |    2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/drivers/staging/imx-drm/parallel-display.c b/drivers/staging/imx-drm/parallel-display.c
> > index 49c90c3..adc011d 100644
> > --- a/drivers/staging/imx-drm/parallel-display.c
> > +++ b/drivers/staging/imx-drm/parallel-display.c
> > @@ -232,6 +232,8 @@ static int imx_pd_probe(struct platform_device *pdev)
> >  
> >  	platform_set_drvdata(pdev, imxpd);
> >  
> > +	of_get_drm_display_mode(np, &imxpd->mode, 0);
> > +
> 
> I'd prefer something like
> 
> 	ret = of_get_drm_display_mode(np, &imxpd->mode, 0);

Also, DRM_IMX_PARALLEL_DISPLAY needs to select OF_VIDEOMODE in 
drivers/staging/imx-drm/Kconfig to use of_get_drm_display_mode.

> 	if (!ret)
> 		imxpd->mode_valid = 1;
> 
> here.

regards
Philipp



From kgene.kim at samsung.com  Tue Apr  9 11:23:37 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Wed, 10 Apr 2013 00:23:37 +0900
Subject: [GIT PULL] Samsung fixes-2 for v3.9
Message-ID: <51643279.7050200@samsung.com>

The following changes since commit 31880c37c11e28cb81c70757e38392b42e695dc6:

   Linux 3.9-rc6 (2013-04-07 20:49:54 -0700)

are available in the git repository at:

   git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git 
tags/samsung-fixes-for-v3.9

for you to fetch changes up to 646dd2f0a980949b05042792fbadd72b735c3eda:

   ARM: S3C24XX: Fix interrupt pending register offset of the EINT 
controller (2013-04-10 00:09:30 +0900)

----------------------------------------------------------------
samsung fixes can support s3c24xx for v3.9

----------------------------------------------------------------
Sylwester Nawrocki (2):
       ARM: S3C24XX: Correct NR_IRQS definition for s3c2440
       ARM: S3C24XX: Fix interrupt pending register offset of the EINT 
controller

  arch/arm/mach-s3c24xx/include/mach/irqs.h | 4 +---
  arch/arm/mach-s3c24xx/irq.c               | 2 +-
  2 files changed, 2 insertions(+), 4 deletions(-)



From arnd at arndb.de  Tue Apr  9 11:27:46 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 9 Apr 2013 17:27:46 +0200
Subject: [GIT PULL] Samsung fixes-2 for v3.9
In-Reply-To: <51643279.7050200@samsung.com>
References: <51643279.7050200@samsung.com>
Message-ID: <201304091727.47154.arnd@arndb.de>

On Tuesday 09 April 2013, Kukjin Kim wrote:
> The following changes since commit 31880c37c11e28cb81c70757e38392b42e695dc6:
> 
>    Linux 3.9-rc6 (2013-04-07 20:49:54 -0700)
> 
> are available in the git repository at:
> 
>    git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git 
> tags/samsung-fixes-for-v3.9
> 
> for you to fetch changes up to 646dd2f0a980949b05042792fbadd72b735c3eda:
> 
>    ARM: S3C24XX: Fix interrupt pending register offset of the EINT 
> controller (2013-04-10 00:09:30 +0900)
> 
> ----------------------------------------------------------------
> samsung fixes can support s3c24xx for v3.9

Pulled into fixes branch, thanks!

	Arnd


From horms at verge.net.au  Tue Apr  9 11:30:03 2013
From: horms at verge.net.au (Simon Horman)
Date: Wed, 10 Apr 2013 00:30:03 +0900
Subject: [PATCH] ARM: shmobile: marzen-reference: use irqpin for lan
In-Reply-To: <20130409125256.GG15412@verge.net.au>
References: <1365125960-25753-1-git-send-email-horms+renesas@verge.net.au>
 <20130409125256.GG15412@verge.net.au>
Message-ID: <20130409153003.GA13831@verge.net.au>

On Tue, Apr 09, 2013 at 09:52:56PM +0900, Simon Horman wrote:
> On Fri, Apr 05, 2013 at 10:39:20AM +0900, Simon Horman wrote:
> > This corrects the configuration of the SMSC lan controller
> > to use the newly added irqpin as its IRQ source.
> > 
> > Previously the lan controller did not work. Now it does.
> > 
> > Cc: Guennadi Liakhovetski <g.liakhovetski+renesas at gmail.com>
> > Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
> 
> Queued up in the boards-marzen branch.

Dropped as the pre-requisite irqpin dt code isn't queued-up yet.


From kgene.kim at samsung.com  Tue Apr  9 11:30:45 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Wed, 10 Apr 2013 00:30:45 +0900
Subject: [GIT PULL v2 10/10] devel-samsung for v3.10
Message-ID: <51643425.3070108@samsung.com>

Hi Arnd, Olof

Note, this is re-sending because of missed including fixes in previous 
pull-request [10/10]. Thanks.

- Kukjin

The following changes since commit 6dbe51c251a327e012439c4772097a13df43c5b8:

   Linux 3.9-rc1 (2013-03-03 15:11:05 -0800)

are available in the git repository at:

   git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git 
tags/devel-samsung-for-v3.10

for you to fetch changes up to 329afd264592f8d0e40fa063c089b35fba0014cc:

   ARM: EXYNOS: replace cpumask by the corresponding macro (2013-04-10 
00:12:27 +0900)

----------------------------------------------------------------
including various development for samsung for v3.10

----------------------------------------------------------------
Charles Keepax (2):
       ARM: S3C64XX: Clear DMA flags on channel request
       ARM: S3C64XX: Slow down mic detection rate for wm5102

Daniel Lezcano (3):
       ARM: EXYNOS: factor out the idle states
       ARM: EXYNOS: handle properly the return values
       ARM: EXYNOS: replace cpumask by the corresponding macro

Inderpal Singh (2):
       ARM: EXYNOS: Add support for rtc wakeup
       ARM: SAMSUNG: check processor type before cache restoration in resume

Jonathan Kliegman (2):
       ARM: EXYNOS: Remove hardcode wakeup unmask for EINT_0
       ARM: EXYNOS: Clear ENABLE_WAKEUP_SW bit when entering suspend

Sylwester Nawrocki (1):
       ARM: SAMSUNG: Export MIPI CSIS/DSIM PHY control functions

  arch/arm/mach-exynos/common.c                |  2 +
  arch/arm/mach-exynos/cpuidle.c               | 58 
+++++++++++++---------------
  arch/arm/mach-exynos/include/mach/pm-core.h  |  9 +----
  arch/arm/mach-s3c64xx/dma.c                  |  1 +
  arch/arm/mach-s3c64xx/mach-crag6410-module.c |  1 +
  arch/arm/plat-samsung/s5p-sleep.S            |  9 +++++
  arch/arm/plat-samsung/setup-mipiphy.c        |  3 ++
  7 files changed, 44 insertions(+), 39 deletions(-)


From kgene.kim at gmail.com  Tue Apr  9 11:32:23 2013
From: kgene.kim at gmail.com (Kukjin Kim)
Date: Wed, 10 Apr 2013 00:32:23 +0900
Subject: [GIT PULL 10/10] devel-samsung for v3.10
In-Reply-To: <516404FE.4000907@samsung.com>
References: <51630A55.6030703@samsung.com> <51632451.3050801@gmail.com>
 <2f2f01ce3514$33d10f00$9b732d00$%kim@samsung.com>
 <516404FE.4000907@samsung.com>
Message-ID: <51643487.9020402@gmail.com>

On 04/09/13 21:09, Sylwester Nawrocki wrote:
> On 04/09/2013 01:20 PM, Kukjin Kim wrote:
>> Sylwester Nawrocki wrote:
>>
>> [...]
>>
>>>> Sylwester Nawrocki (2):
>>>> ARM: SAMSUNG: Export MIPI CSIS/DSIM PHY control functions
>>>
>>> This one was supposed to be a fix for 3.8-rc IIRC. But anyway the whole
>>
>> If so, this should be sent to stable 3.8 tree, but I'm not sure this is
>> really bug fix.
>
> It prevents build error when MIPI-CSIS driver is build as a loadable module.
> That means with some valid kernel configuration the kernel cannot be build.
> Hence IMHO it is a bug fix, and sending it to 3.8+ stable indeed seems a
> good idea.
>
OK.

>>> file this patch touches is going to be removed in 3.11.
>>>
>> It means it is still needed for v3.10 :-)
>
> Yeah, true. :) Just wanted to note that I have already some RFC patches
> for the MIPI CSI-2/DSI DPHY driver using the generic PHY framework.
> However this framework is not settled yet, I assume it would be completed
> for 3.11.
>
I see.

>>>> ARM: S3C24XX: Correct NR_IRQS definition for s3c2440
>>>
>>> And this one is needed for 3.9, sorry for not mentioning it in the patch's
>>> description. Together with [1] it makes my s3c2440 SoC based test board
>>> booting again with 3.9-rc6.
>>>
>>> [1] http://www.spinics.net/lists/arm-kernel/msg236643.html
>>>
>> OK, let me drop it in this branch.
>
> Thanks!
>
You're welcome :-)

>> Arnd and Olof, please hold on pulling for this branch. I will sort out soon.
>>
I re-sent pull-request instead of this.

Thanks.

- Kukjin


From s-anna at ti.com  Tue Apr  9 11:33:27 2013
From: s-anna at ti.com (Anna, Suman)
Date: Tue, 9 Apr 2013 15:33:27 +0000
Subject: [GIT PULL] mailbox driver framework for v3.10 merge window
In-Reply-To: <201304091255.03020.arnd@arndb.de>
References: <37C860A02101E749A747FA2D3C1E3C504A1971@DLEE11.ent.ti.com>
 <201304091255.03020.arnd@arndb.de>
Message-ID: <37C860A02101E749A747FA2D3C1E3C504A2AD0@DLEE11.ent.ti.com>

 On Thursday 04 April 2013, Anna, Suman wrote:
> > OMAP and ST-Ericsson platforms are both using mailbox to communicate with
> some coprocessors. This series creates a consolidated framework, living under
> drivers/mailbox.
> > The changes mainly contain:
> > - create a mailbox framework independent from OMAP h/w
> > - creates dbx500 mailbox driver for ST-Ericsson platforms
> > - move the omap mailbox out of plat-omap/mach-omapX  adapting to the new
> framework.
> > - minor bug fixes in mailbox code
> 
> Pulled into a new next/mailbox branch, to keep it separate from the existing
> subsystems.
> 
> As a note for you: when you send a pull request, please make sure that you use a
> tag that includes the changeset text (your description above), so I don't have to
> copy it from the email. I noticed that you do have a tag "mailbox-for-v3.10" in
> your tree, but the pull request was for the branch with the same contents.
> 

Thanks Arnd. Yes, the tag is for the same SHA, and has the same comments as above. I understood the process only a bit later.

Regards
Suman


From arnd at arndb.de  Tue Apr  9 11:34:30 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 9 Apr 2013 17:34:30 +0200
Subject: [GIT PULL] Samsung fixes-2 for v3.9
In-Reply-To: <51643279.7050200@samsung.com>
References: <51643279.7050200@samsung.com>
Message-ID: <201304091734.30298.arnd@arndb.de>

On Tuesday 09 April 2013, Kukjin Kim wrote:
> The following changes since commit 31880c37c11e28cb81c70757e38392b42e695dc6:

> ----------------------------------------------------------------
> Sylwester Nawrocki (2):
>        ARM: S3C24XX: Correct NR_IRQS definition for s3c2440
>        ARM: S3C24XX: Fix interrupt pending register offset of the EINT 
> controller


I got a conflict merging this into the for-next branch, which has earlier
patches. Please confirm that the resolution below is correct.

	Arnd

diff --cc arch/arm/mach-s3c24xx/irq.c
index 8296d94,d8ba9be..7f56a93
--- a/arch/arm/mach-s3c24xx/irq.c
+++ b/arch/arm/mach-s3c24xx/irq.c
@@@ -498,9 -500,10 +498,9 @@@ struct s3c_irq_intc *s3c24xx_init_intc(
                base = (void *)0xfd000000;
  
                intc->reg_mask = base + 0xa4;
-               intc->reg_pending = base + 0x08;
+               intc->reg_pending = base + 0xa8;
 -              irq_num = 20;
 +              irq_num = 24;
                irq_start = S3C2410_IRQ(32);
 -              irq_offset = 4;
                break;
        default:
                pr_err("irq: unsupported controller address\n");



From swarren at wwwdotorg.org  Tue Apr  9 11:36:45 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Tue, 09 Apr 2013 09:36:45 -0600
Subject: [GIT PULL 3/8] ARM: tegra: cleanup
In-Reply-To: <201304091544.32377.arnd@arndb.de>
References: <1365181426-11547-1-git-send-email-swarren@wwwdotorg.org>
 <1365181426-11547-3-git-send-email-swarren@wwwdotorg.org>
 <201304091544.32377.arnd@arndb.de>
Message-ID: <5164358D.1050204@wwwdotorg.org>

On 04/09/2013 07:44 AM, Arnd Bergmann wrote:
> On Friday 05 April 2013, Stephen Warren wrote:
>> This branch includes various cleanup of the core Tegra support.
>>
>> * Unification of the separate board-dt-tegra*.c files into a single
>>   tegra.c, now that everything is DT-driven and basically identical.
>> * Use of_clk_get() in the Tegra clocksource driver so that clocks are
>>   described in DT rather than hard-coding clock names.
>> * Some cleanup of the PMC-related code, with the aim that the PMC
>>   "driver" contains more of the code that touches PMC registers, rather
>>   than spreading PMC register accesses through other files.
>> * Conversion of the "PMC" driver to acquire resources describe in device
>>   tree rather than hard-coding them.
>> * Use of common code for the CPU sleep TLB invalidation.
>>
> 
> Pulled into next/cleanup branch and resolved the conflict against
> an earlier cleanup that was already present there, fixup below.

Oh yes, sorry I forgot to mention that; of course this conflict doesn't
show up when I build my own for-next, but rather only in
arm-soc/linux-next so I forgot about it:-(

Anyway, the resolution you posted looks good. Thanks.


From swarren at wwwdotorg.org  Tue Apr  9 11:38:05 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Tue, 09 Apr 2013 09:38:05 -0600
Subject: [GIT PULL 5/8] ARM: tegra: clock driver development
In-Reply-To: <201304091714.53220.arnd@arndb.de>
References: <1365181426-11547-1-git-send-email-swarren@wwwdotorg.org>
 <1365181426-11547-5-git-send-email-swarren@wwwdotorg.org>
 <201304091714.53220.arnd@arndb.de>
Message-ID: <516435DD.6060006@wwwdotorg.org>

On 04/09/2013 09:14 AM, Arnd Bergmann wrote:
> On Friday 05 April 2013, Stephen Warren wrote:
>> This branch contains most fixes and enhancements to the Tegra common
>> clock driver. The main new feature is a driver for Tegra114, which
>> coupled with later device tree changes enables many devices on that
>> chip, such as MMC, I2C, etc.
>>
>> This branch depends on a patch in:
>>
>> git://git.linaro.org/people/mturquette/linux.git clk-for-3.10
> 
> Pulled into next/drivers branch, and noted down the dependency.
> 
> As a general recommendation, it is nicer if you can prepare a
> separate branch with the dependency, even if it's just one patch,
> and have that pulled into both maintainer trees, rather than
> having us add the entire set of clk changes as a dependency.

Yes, I did ask for that to happen repeatedly, but Mike forgot when
applying the patch to his tree.


From gregory.clement at free-electrons.com  Tue Apr  9 11:41:20 2013
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Tue, 09 Apr 2013 17:41:20 +0200
Subject: [PATCH 1/3] clk: composite: Add fixed-rate support
In-Reply-To: <1365515284-32061-2-git-send-email-emilio@elopez.com.ar>
References: <1365515284-32061-1-git-send-email-emilio@elopez.com.ar>
 <1365515284-32061-2-git-send-email-emilio@elopez.com.ar>
Message-ID: <516436A0.9080609@free-electrons.com>

On 04/09/2013 03:48 PM, Emilio L?pez wrote:
> This patchset adds fixed-rate support to the composite clock, allowing
> us to register gatable oscillators.
> 
> Signed-off-by: Emilio L??pez <emilio at elopez.com.ar>
> ---
>  drivers/clk/clk-composite.c  | 57 ++++++++++++++++++++++++++++++++++++++++----
>  include/linux/clk-provider.h |  6 +++++
>  2 files changed, 59 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/clk/clk-composite.c b/drivers/clk/clk-composite.c
> index 097dee4..5416e1d 100644
> --- a/drivers/clk/clk-composite.c
> +++ b/drivers/clk/clk-composite.c
> @@ -43,8 +43,8 @@ static int clk_composite_set_parent(struct clk_hw *hw, u8 index)
>  	return mux_ops->set_parent(mux_hw, index);
>  }
>  
> -static unsigned long clk_composite_recalc_rate(struct clk_hw *hw,
> -					    unsigned long parent_rate)
> +static unsigned long clk_composite_recalc_rate_div(struct clk_hw *hw,
> +						   unsigned long parent_rate)
>  {
>  	struct clk_composite *composite = to_clk_composite(hw);
>  	const struct clk_ops *div_ops = composite->div_ops;
> @@ -55,6 +55,18 @@ static unsigned long clk_composite_recalc_rate(struct clk_hw *hw,
>  	return div_ops->recalc_rate(div_hw, parent_rate);
>  }
>  
> +static unsigned long clk_composite_recalc_rate_fixed(struct clk_hw *hw,
> +						     unsigned long parent_rate)
> +{
> +	struct clk_composite *composite = to_clk_composite(hw);
> +	const struct clk_ops *fixed_ops = composite->fixed_ops;
> +	struct clk_hw *fixed_hw = composite->fixed_hw;
> +
> +	fixed_hw->clk = hw->clk;
> +
> +	return fixed_ops->recalc_rate(fixed_hw, parent_rate);
> +}
> +
>  static long clk_composite_round_rate(struct clk_hw *hw, unsigned long rate,
>  				  unsigned long *prate)
>  {
> @@ -112,11 +124,12 @@ static void clk_composite_disable(struct clk_hw *hw)
>  	gate_ops->disable(gate_hw);
>  }
>  
> -struct clk *clk_register_composite(struct device *dev, const char *name,
> +static struct clk *_clk_register_composite(struct device *dev, const char *name,
>  			const char **parent_names, int num_parents,
>  			struct clk_hw *mux_hw, const struct clk_ops *mux_ops,
>  			struct clk_hw *div_hw, const struct clk_ops *div_ops,
>  			struct clk_hw *gate_hw, const struct clk_ops *gate_ops,
> +			struct clk_hw *fixed_hw, const struct clk_ops *fixed_ops,
>  			unsigned long flags)
>  {
>  	struct clk *clk;
> @@ -158,7 +171,7 @@ struct clk *clk_register_composite(struct device *dev, const char *name,
>  
>  		composite->div_hw = div_hw;
>  		composite->div_ops = div_ops;
> -		clk_composite_ops->recalc_rate = clk_composite_recalc_rate;
> +		clk_composite_ops->recalc_rate = clk_composite_recalc_rate_div;
>  		clk_composite_ops->round_rate = clk_composite_round_rate;
>  		clk_composite_ops->set_rate = clk_composite_set_rate;
>  	}
> @@ -177,6 +190,17 @@ struct clk *clk_register_composite(struct device *dev, const char *name,
>  		clk_composite_ops->disable = clk_composite_disable;
>  	}
>  
> +	if (fixed_hw && fixed_ops) {
> +		if (!fixed_ops->recalc_rate) {
> +			clk = ERR_PTR(-EINVAL);
> +			goto err;
> +		}
> +
> +		composite->fixed_hw = fixed_hw;
> +		composite->fixed_ops = fixed_ops;
> +		clk_composite_ops->recalc_rate = clk_composite_recalc_rate_fixed;
> +	}
> +
>  	init.ops = clk_composite_ops;
>  	composite->hw.init = &init;
>  
> @@ -193,9 +217,34 @@ struct clk *clk_register_composite(struct device *dev, const char *name,
>  	if (composite->gate_hw)
>  		composite->gate_hw->clk = clk;
>  
> +	if (composite->fixed_hw)
> +		composite->fixed_hw->clk = clk;
> +
>  	return clk;
>  
>  err:
>  	kfree(composite);
>  	return clk;
>  }
> +
> +struct clk *clk_register_composite(struct device *dev, const char *name,
> +			const char **parent_names, int num_parents,
> +			struct clk_hw *mux_hw, const struct clk_ops *mux_ops,
> +			struct clk_hw *div_hw, const struct clk_ops *div_ops,
> +			struct clk_hw *gate_hw, const struct clk_ops *gate_ops,
> +			unsigned long flags)
> +{
> +	return _clk_register_composite(dev, name, parent_names, num_parents,
> +				       mux_hw, mux_ops, div_hw, div_ops,
> +				       gate_hw, gate_ops, NULL, NULL, flags);
> +}
> +
> +struct clk *clk_register_gatable_osc(struct device *dev, const char *name,
> +			struct clk_hw *fixed_hw, const struct clk_ops *fixed_ops,
> +			struct clk_hw *gate_hw, const struct clk_ops *gate_ops,
> +			unsigned long flags)
> +{
> +	return _clk_register_composite(dev, name, NULL, 0, NULL, NULL,
> +				       NULL, NULL, gate_hw, gate_ops,
> +				       fixed_hw, fixed_ops, flags);
> +}

I think you should remove all this chunk, and made your change in
clk_register_composite() instead of using _clk_register_composite(). I don't
think it is a good thing that each kind of composition was declared here.

The way you composed your clock should be done by each driver.

I understand that you didn't want to break the existing driver, but in this case
it is better to do the modification in the driver to follow the new API.
The change is pretty trivial and can be automated by using spatch aka semantic patch
aka coccinelle. But as this API is very new you could also do it by hand, however I
didn't find any occurrences of this function in the branches clk-next or clk-for-3.10.
I only found one occurrence in  the  in patch "clk: tegra30: Convert clk out to
composite clk" from Prashant Gaikwad. Unfortunately I didn't find a tree with this
commit applied.


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From kgene.kim at samsung.com  Tue Apr  9 11:43:11 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Wed, 10 Apr 2013 00:43:11 +0900
Subject: [GIT PULL] Samsung fixes-2 for v3.9
In-Reply-To: <201304091734.30298.arnd@arndb.de>
References: <51643279.7050200@samsung.com> <201304091734.30298.arnd@arndb.de>
Message-ID: <5164370F.6020503@samsung.com>

On 04/10/13 00:34, Arnd Bergmann wrote:
> On Tuesday 09 April 2013, Kukjin Kim wrote:
>> The following changes since commit 31880c37c11e28cb81c70757e38392b42e695dc6:
>
>> ----------------------------------------------------------------
>> Sylwester Nawrocki (2):
>>         ARM: S3C24XX: Correct NR_IRQS definition for s3c2440
>>         ARM: S3C24XX: Fix interrupt pending register offset of the EINT
>> controller
>
>
> I got a conflict merging this into the for-next branch, which has earlier
> patches. Please confirm that the resolution below is correct.
>
Yes, your resolution is correct.

Thanks.

- Kukjin

>
> diff --cc arch/arm/mach-s3c24xx/irq.c
> index 8296d94,d8ba9be..7f56a93
> --- a/arch/arm/mach-s3c24xx/irq.c
> +++ b/arch/arm/mach-s3c24xx/irq.c
> @@@ -498,9 -500,10 +498,9 @@@ struct s3c_irq_intc *s3c24xx_init_intc(
>                  base = (void *)0xfd000000;
>
>                  intc->reg_mask = base + 0xa4;
> -               intc->reg_pending = base + 0x08;
> +               intc->reg_pending = base + 0xa8;
>   -              irq_num = 20;
>   +              irq_num = 24;
>                  irq_start = S3C2410_IRQ(32);
>   -              irq_offset = 4;
>                  break;
>          default:
>                  pr_err("irq: unsupported controller address\n");
>
> --


From swarren at wwwdotorg.org  Tue Apr  9 11:46:04 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Tue, 09 Apr 2013 09:46:04 -0600
Subject: [PATCH 2/3] ARM: dts: tegra: Correct PCIe entry
In-Reply-To: <20130409083050.GQ3572@tbergstrom-lnx.Nvidia.com>
References: <1365435688-4179-1-git-send-email-jagarwal@nvidia.com>
 <1365435688-4179-2-git-send-email-jagarwal@nvidia.com>
 <51630BF4.6000605@wwwdotorg.org>
 <20130409083050.GQ3572@tbergstrom-lnx.Nvidia.com>
Message-ID: <516437BC.8060707@wwwdotorg.org>

On 04/09/2013 02:30 AM, Peter De Schrijver wrote:
> On Mon, Apr 08, 2013 at 08:27:00PM +0200, Stephen Warren wrote:
>> On 04/08/2013 09:41 AM, Jay Agarwal wrote:
>>> Signed-off-by: Jay Agarwal <jagarwal at nvidia.com>
>>
>> Your s-o-b line should be below the patch description, not above it.
>> Please see Documentation/SubmittingPatches.
>>
>> I also don't see a --- line between the patch description and diffstat.
>> How are you generating these patch emails? Please see our internal wiki,
>> or other git documentation.
>>
>>> diff --git a/arch/arm/boot/dts/tegra30.dtsi b/arch/arm/boot/dts/tegra30.dtsi
>>
>>> -		clock-names = "pex", "afi", "pcie_xclk", "pll_e", "cml";
>>> +		clock-names = "pex", "afi", "pcie_xclk", "pll_e", "cml0";
>>
>> Can you please explain more about this change?
>>
>> I see the Tegra clock driver provides both a "cml0" and a "cml1" clock.
>> Are both of those used for PCIe?
>>
> 
> cml0 is used for pcie and cml1 is used for sata.

OK, so the PCIe drivers' clock-names property may as well contain just
cml then. Same for SATA. The clock name at the provider isn't relevant.


From maxime.ripard at free-electrons.com  Tue Apr  9 11:48:52 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue, 09 Apr 2013 17:48:52 +0200
Subject: [GIT PULL] Sunxi Cleanups for 3.10
Message-ID: <51643864.4050906@free-electrons.com>

Hi Arnd, Olof,

Here is a pull request for the various cleanups for the sunXi platform
for 3.10.

It is based both on Mike Turquette's clk-for-3.10 branch and on the
branch clksrc/cleanup found in arm-soc

The following changes since commit 7c91d302ffe2ffac813c47d6ba2e7489a2ccb35f:

  Merge remote-tracking branch 'clk/clk-for-3.10' into sunxi/core-for-3.10 (2013-04-08 21:39:22 +0200)

are available in the git repository at:


  git://github.com/mripard/linux.git tags/sunxi-cleanup-for-3.10

for you to fetch changes up to bc34b5f27cd33f4213bc5c8df0099dd11408d29d:

  ARM: sunxi: Rework the restart code (2013-04-08 21:43:08 +0200)

----------------------------------------------------------------
Cleanups for Allwinner sunXi architecture:
  - Remove sunxi.dtsi
  - Switch to clocksource/irqchip device tree handlers
  - Cleanup the watchdog code

----------------------------------------------------------------
Maxime Ripard (6):
      clocksource: sunxi: Cleanup the timer code
      clocksource: sunxi: make use of CLKSRC_OF
      clocksource: sunxi: Rename sunxi to sun4i
      irqchip: sunxi: Make use of the IRQCHIP_DECLARE macro
      irqchip: sunxi: Rename sunxi to sun4i
      ARM: sunxi: Rework the restart code

 ...lwinner,sunxi-ic.txt => allwinner,sun4i-ic.txt} |    4 +-
 ...r,sunxi-timer.txt => allwinner,sun4i-timer.txt} |    4 +-
 .../watchdog/{sunxi-wdt.txt => sun4i-wdt.txt}      |    6 +-
 arch/arm/mach-sunxi/Kconfig                        |    5 +-
 arch/arm/mach-sunxi/sunxi.c                        |   74 ++++++----
 drivers/clocksource/Kconfig                        |    2 +-
 drivers/clocksource/Makefile                       |    2 +-
 .../clocksource/{sunxi_timer.c => sun4i_timer.c}   |   94 ++++++------
 drivers/irqchip/Makefile                           |    2 +-
 drivers/irqchip/irq-sun4i.c                        |  149 +++++++++++++++++++
 drivers/irqchip/irq-sunxi.c                        |  151 --------------------
 include/linux/irqchip/sunxi.h                      |   27 ----
 include/linux/sunxi_timer.h                        |   24 ----
 13 files changed, 249 insertions(+), 295 deletions(-)
 rename Documentation/devicetree/bindings/interrupt-controller/{allwinner,sunxi-ic.txt => allwinner,sun4i-ic.txt} (94%)
 rename Documentation/devicetree/bindings/timer/{allwinner,sunxi-timer.txt => allwinner,sun4i-timer.txt} (78%)
 rename Documentation/devicetree/bindings/watchdog/{sunxi-wdt.txt => sun4i-wdt.txt} (57%)
 rename drivers/clocksource/{sunxi_timer.c => sun4i_timer.c} (50%)
 create mode 100644 drivers/irqchip/irq-sun4i.c
 delete mode 100644 drivers/irqchip/irq-sunxi.c
 delete mode 100644 include/linux/irqchip/sunxi.h
 delete mode 100644 include/linux/sunxi_timer.h

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


From arnd at arndb.de  Tue Apr  9 11:55:04 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 9 Apr 2013 17:55:04 +0200
Subject: [GIT PULL 6/8] ARM: tegra: device tree changes
In-Reply-To: <1365181426-11547-6-git-send-email-swarren@wwwdotorg.org>
References: <1365181426-11547-1-git-send-email-swarren@wwwdotorg.org>
 <1365181426-11547-6-git-send-email-swarren@wwwdotorg.org>
Message-ID: <201304091755.04661.arnd@arndb.de>

On Friday 05 April 2013, Stephen Warren wrote:
> This branch contains the majority of the device tree changes for Tegra.
> Highlights include:
> 
> * Many changes for Tegra114, and the Dalmore board, to enable pinctrl,
>   SDHCI/MMC, PWM, DMA, I2C, KBC, SPI, battery, regulators.
> * Adding or enabling suspend wakeup sources on many boards, and adding
>   suspend timing parameters, to support the system suspend patches.
> * Adding clocks to the audio-related nodes, so that in 3.11, the audio
>   driver can pull these clocks from device tree rather than hard-coding
>   clock names.
> * Some small DT fixes/cleanup.
> 
> This branch is based on the previous clk pull request.

I ended up doing a next/dt2 branch for this, since the mxs tree has the
same kind of dependency.

	Arnd


From maxime.ripard at free-electrons.com  Tue Apr  9 11:55:08 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue, 09 Apr 2013 17:55:08 +0200
Subject: [GIT PULL] sunXi DT additions for 3.10, take 3
Message-ID: <516439DC.5010009@free-electrons.com>

Hi Arnd, Olof,

Please consider pulling the following pull request.

It should be our last for the 3.10 merge window.

Thanks,
Maxime

The following changes since commit 36386d6e54d0ebcd5b2e0869f837800293d94c3c:

  arm: sunxi: Add clock to pinctrl node (2013-04-04 23:45:30 +0200)

are available in the git repository at:

  git://github.com/mripard/linux.git tags/sunxi-dt-for-3.10-3

for you to fetch changes up to 0b19b7c2c6e169efccb4b1632fe628969d001618:

  ARM: sunxi: dt: Update watchdog compatible string (2013-04-08 21:56:34 +0200)

----------------------------------------------------------------
SunXi dt additions for 3.10, take 3
  - Remove sunxi.dtsi and only use one dtsi for each SoC
  - Various compatible renamings to be consistent with the other platforms

----------------------------------------------------------------
Maxime Ripard (4):
      ARM: sunxi: dt: Reorganize the dtsi
      ARM: sunxi: dt: Update timer compatible string
      ARM: sunxi: dt: Update interrupt controller compatible string
      ARM: sunxi: dt: Update watchdog compatible string

 arch/arm/boot/dts/sun4i-a10-cubieboard.dts |    2 +-
 arch/arm/boot/dts/sun4i-a10-hackberry.dts  |    2 +-
 arch/arm/boot/dts/sun4i-a10.dtsi           |  194 +++++++++++++++++++++++++-
 arch/arm/boot/dts/sun5i-a13-olinuxino.dts  |    2 +-
 arch/arm/boot/dts/sun5i-a13.dtsi           |  194 +++++++++++++++++++++++++-
 arch/arm/boot/dts/sunxi.dtsi               |  208 ----------------------------
 6 files changed, 387 insertions(+), 215 deletions(-)
 delete mode 100644 arch/arm/boot/dts/sunxi.dtsi

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


From arnd at arndb.de  Tue Apr  9 11:57:08 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 9 Apr 2013 17:57:08 +0200
Subject: [GIT PULL 4/4] ARM: mxs: device tree changes for 3.10
In-Reply-To: <1365411621-18422-4-git-send-email-shawn.guo@linaro.org>
References: <1365411621-18422-1-git-send-email-shawn.guo@linaro.org>
 <1365411621-18422-4-git-send-email-shawn.guo@linaro.org>
Message-ID: <201304091757.08475.arnd@arndb.de>

On Monday 08 April 2013, Shawn Guo wrote:
> Hi Arnd, Olof,
> 
> This is the mxs device tree changes for 3.10.  It's based on
> mxs-cleanup-3.10 to avoid some nasty conflicts.  Please pull, thanks.
> 
> Shawn
> 
> The following changes since commit e933a1a12a02f42e0013cda87bba37ccb59efc47:
> 
>   clocksource: mxs_timer: Add semicolon at end of line (2013-04-03 10:30:08 +0800)
> 
> are available in the git repository at:
> 
>   git://git.linaro.org/people/shawnguo/linux-2.6.git tags/mxs-dt-3.10
> 
> for you to fetch changes up to 4344429d3d926d219671f607125cff51223a140a:
> 
>   video: mxsfb: Introduce regulator support (2013-04-08 15:44:55 +0800)
> 
> ----------------------------------------------------------------
> The mxs device tree changes for 3.10:
> 
> * Move enet_out clk into device tree and have fec driver handle it.
> * Convert mxsfb driver to generic display timings bindings, and remove
>   the mxsfb auxdata from platform code.
> * Add generic DMA device tree binding for mxs-dma, and convert the most
>   of client device drivers to it.
> * Change mxsfb driver to use regulator for controlling power of panel.
> * A few device tree source updates

Pulled into next/dt2, thanks!

	Arnd


From arnd at arndb.de  Tue Apr  9 11:59:13 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 9 Apr 2013 17:59:13 +0200
Subject: [GIT PULL] ux500 pinctrl patches
In-Reply-To: <CACRpkdbJ=T_-P0+gCuajMNCM9XGWQsa1EfzfOpV4Dwdf-wYRXA@mail.gmail.com>
References: <CACRpkdbJ=T_-P0+gCuajMNCM9XGWQsa1EfzfOpV4Dwdf-wYRXA@mail.gmail.com>
Message-ID: <201304091759.13537.arnd@arndb.de>

On Monday 08 April 2013, Linus Walleij wrote:
> Hi ARM SoC guys,
> 
> here are some ux500 pinctrl patches for the next merge cycle.
> Please pull it in to some apropriate ux500 branch.
> 

Pulled into next/drivers, thanks!

	Arnd


From jgunthorpe at obsidianresearch.com  Tue Apr  9 12:00:45 2013
From: jgunthorpe at obsidianresearch.com (Jason Gunthorpe)
Date: Tue, 9 Apr 2013 10:00:45 -0600
Subject: [PATCH v4 1/5] drivers: memory: Introduce Marvell EBU Device Bus
 driver
In-Reply-To: <201304091244.07662.arnd@arndb.de>
References: <1365419194-20871-1-git-send-email-ezequiel.garcia@free-electrons.com>
 <201304091140.51839.arnd@arndb.de>
 <20130409103445.GA2268@localhost>
 <201304091244.07662.arnd@arndb.de>
Message-ID: <20130409160045.GA9663@obsidianresearch.com>

On Tue, Apr 09, 2013 at 12:44:07PM +0200, Arnd Bergmann wrote:

> I think it's still reasonable to make it a module, but it might need
> to be one without a module_exit() call to prevent unloading.

Agree, I think it is better to properly handle a broader set of
possible DT's than to have module unloading. The DT is supposed to be
stable..

Jason


From jgunthorpe at obsidianresearch.com  Tue Apr  9 12:03:16 2013
From: jgunthorpe at obsidianresearch.com (Jason Gunthorpe)
Date: Tue, 9 Apr 2013 10:03:16 -0600
Subject: [PATCH v4 1/5] drivers: memory: Introduce Marvell EBU Device Bus
 driver
In-Reply-To: <20130409004253.GA2258@localhost>
References: <1365419194-20871-1-git-send-email-ezequiel.garcia@free-electrons.com>
 <1365419194-20871-2-git-send-email-ezequiel.garcia@free-electrons.com>
 <20130408171940.GA8815@obsidianresearch.com>
 <20130409004253.GA2258@localhost>
Message-ID: <20130409160316.GB9663@obsidianresearch.com>

On Mon, Apr 08, 2013 at 09:42:54PM -0300, Ezequiel Garcia wrote:
> > Just to note on them for future:
> > 
> > > +	child = of_get_next_child(node, NULL);
> > > +	if (!child) {
> > > +		dev_err(dev, "%s has no childs\n", node->full_name);
> > > +		return -EINVAL;
> > > +	}
> > 
> > This isn't really necessary anymore, the ranges of the node itself
> > should be parsed to get the window start/end. The driver should never
> > need to look at the children directly..
> > 
> 
> You mean the above will not be necessary in the *future*,
> once we add mbus DT bindings, right?

No, you could do this now.

Look at your binding:

+               devbus-bootcs at d0010400 {
+                       status = "okay";
+                       ranges = <0 0xf0000000 0x1000000>; /* @addr 0xf000000, size 0x1000000 */

Parse that ranges and you get the base and size of the window.

Then 'ranges' is mandatory and 'ranges' must have a single entry.

No need to look at children at all. You can remove all the child
parsing code, and then the driver is able to handle a wider range of
possible DT uses.

Jason


From emilio at elopez.com.ar  Tue Apr  9 12:04:20 2013
From: emilio at elopez.com.ar (=?ISO-8859-1?Q?Emilio_L=F3pez?=)
Date: Tue, 09 Apr 2013 13:04:20 -0300
Subject: [PATCH 1/3] clk: composite: Add fixed-rate support
In-Reply-To: <516436A0.9080609@free-electrons.com>
References: <1365515284-32061-1-git-send-email-emilio@elopez.com.ar>
 <1365515284-32061-2-git-send-email-emilio@elopez.com.ar>
 <516436A0.9080609@free-electrons.com>
Message-ID: <51643C04.3030002@elopez.com.ar>

Hi Gregory,

El 09/04/13 12:41, Gregory CLEMENT escribi?:
> On 04/09/2013 03:48 PM, Emilio L?pez wrote:
>> This patchset adds fixed-rate support to the composite clock, allowing
>> us to register gatable oscillators.
>>
>> Signed-off-by: Emilio L??pez <emilio at elopez.com.ar>
>> ---
>>  drivers/clk/clk-composite.c  | 57 ++++++++++++++++++++++++++++++++++++++++----
>>  include/linux/clk-provider.h |  6 +++++
>>  2 files changed, 59 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/clk/clk-composite.c b/drivers/clk/clk-composite.c
>> index 097dee4..5416e1d 100644
>> --- a/drivers/clk/clk-composite.c
>> +++ b/drivers/clk/clk-composite.c
>> @@ -43,8 +43,8 @@ static int clk_composite_set_parent(struct clk_hw *hw, u8 index)
>>  	return mux_ops->set_parent(mux_hw, index);
>>  }
>>  
>> -static unsigned long clk_composite_recalc_rate(struct clk_hw *hw,
>> -					    unsigned long parent_rate)
>> +static unsigned long clk_composite_recalc_rate_div(struct clk_hw *hw,
>> +						   unsigned long parent_rate)
>>  {
>>  	struct clk_composite *composite = to_clk_composite(hw);
>>  	const struct clk_ops *div_ops = composite->div_ops;
>> @@ -55,6 +55,18 @@ static unsigned long clk_composite_recalc_rate(struct clk_hw *hw,
>>  	return div_ops->recalc_rate(div_hw, parent_rate);
>>  }
>>  
>> +static unsigned long clk_composite_recalc_rate_fixed(struct clk_hw *hw,
>> +						     unsigned long parent_rate)
>> +{
>> +	struct clk_composite *composite = to_clk_composite(hw);
>> +	const struct clk_ops *fixed_ops = composite->fixed_ops;
>> +	struct clk_hw *fixed_hw = composite->fixed_hw;
>> +
>> +	fixed_hw->clk = hw->clk;
>> +
>> +	return fixed_ops->recalc_rate(fixed_hw, parent_rate);
>> +}
>> +
>>  static long clk_composite_round_rate(struct clk_hw *hw, unsigned long rate,
>>  				  unsigned long *prate)
>>  {
>> @@ -112,11 +124,12 @@ static void clk_composite_disable(struct clk_hw *hw)
>>  	gate_ops->disable(gate_hw);
>>  }
>>  
>> -struct clk *clk_register_composite(struct device *dev, const char *name,
>> +static struct clk *_clk_register_composite(struct device *dev, const char *name,
>>  			const char **parent_names, int num_parents,
>>  			struct clk_hw *mux_hw, const struct clk_ops *mux_ops,
>>  			struct clk_hw *div_hw, const struct clk_ops *div_ops,
>>  			struct clk_hw *gate_hw, const struct clk_ops *gate_ops,
>> +			struct clk_hw *fixed_hw, const struct clk_ops *fixed_ops,
>>  			unsigned long flags)
>>  {
>>  	struct clk *clk;
>> @@ -158,7 +171,7 @@ struct clk *clk_register_composite(struct device *dev, const char *name,
>>  
>>  		composite->div_hw = div_hw;
>>  		composite->div_ops = div_ops;
>> -		clk_composite_ops->recalc_rate = clk_composite_recalc_rate;
>> +		clk_composite_ops->recalc_rate = clk_composite_recalc_rate_div;
>>  		clk_composite_ops->round_rate = clk_composite_round_rate;
>>  		clk_composite_ops->set_rate = clk_composite_set_rate;
>>  	}
>> @@ -177,6 +190,17 @@ struct clk *clk_register_composite(struct device *dev, const char *name,
>>  		clk_composite_ops->disable = clk_composite_disable;
>>  	}
>>  
>> +	if (fixed_hw && fixed_ops) {
>> +		if (!fixed_ops->recalc_rate) {
>> +			clk = ERR_PTR(-EINVAL);
>> +			goto err;
>> +		}
>> +
>> +		composite->fixed_hw = fixed_hw;
>> +		composite->fixed_ops = fixed_ops;
>> +		clk_composite_ops->recalc_rate = clk_composite_recalc_rate_fixed;
>> +	}
>> +
>>  	init.ops = clk_composite_ops;
>>  	composite->hw.init = &init;
>>  
>> @@ -193,9 +217,34 @@ struct clk *clk_register_composite(struct device *dev, const char *name,
>>  	if (composite->gate_hw)
>>  		composite->gate_hw->clk = clk;
>>  
>> +	if (composite->fixed_hw)
>> +		composite->fixed_hw->clk = clk;
>> +
>>  	return clk;
>>  
>>  err:
>>  	kfree(composite);
>>  	return clk;
>>  }
>> +
>> +struct clk *clk_register_composite(struct device *dev, const char *name,
>> +			const char **parent_names, int num_parents,
>> +			struct clk_hw *mux_hw, const struct clk_ops *mux_ops,
>> +			struct clk_hw *div_hw, const struct clk_ops *div_ops,
>> +			struct clk_hw *gate_hw, const struct clk_ops *gate_ops,
>> +			unsigned long flags)
>> +{
>> +	return _clk_register_composite(dev, name, parent_names, num_parents,
>> +				       mux_hw, mux_ops, div_hw, div_ops,
>> +				       gate_hw, gate_ops, NULL, NULL, flags);
>> +}
>> +
>> +struct clk *clk_register_gatable_osc(struct device *dev, const char *name,
>> +			struct clk_hw *fixed_hw, const struct clk_ops *fixed_ops,
>> +			struct clk_hw *gate_hw, const struct clk_ops *gate_ops,
>> +			unsigned long flags)
>> +{
>> +	return _clk_register_composite(dev, name, NULL, 0, NULL, NULL,
>> +				       NULL, NULL, gate_hw, gate_ops,
>> +				       fixed_hw, fixed_ops, flags);
>> +}
> 
> I think you should remove all this chunk, and made your change in
> clk_register_composite() instead of using _clk_register_composite(). I don't
> think it is a good thing that each kind of composition was declared here.
> 
> The way you composed your clock should be done by each driver.
> 
> I understand that you didn't want to break the existing driver, but in this case
> it is better to do the modification in the driver to follow the new API.
> The change is pretty trivial and can be automated by using spatch aka semantic patch
> aka coccinelle. But as this API is very new you could also do it by hand, however I
> didn't find any occurrences of this function in the branches clk-next or clk-for-3.10.
> I only found one occurrence in  the  in patch "clk: tegra30: Convert clk out to
> composite clk" from Prashant Gaikwad. Unfortunately I didn't find a tree with this
> commit applied.

Originally I thought of doing it that way, but I couldn't find any
actual usage of clk-composite, so I played it safe and avoided breaking
the API. If there are no patches queued for 3.10 using it and Prashant
agrees, I will rename _clk_register_composite -> clk_register_composite
and drop the wrappers.

@Prashant: are there any patches queued for 3.10 using this API?


From horms at verge.net.au  Tue Apr  9 12:14:13 2013
From: horms at verge.net.au (Simon Horman)
Date: Wed, 10 Apr 2013 01:14:13 +0900
Subject: [PATCH] ARM: shmobile: Include all 2 GiB of memory on APE6EVM
In-Reply-To: <20130409123433.GD15412@verge.net.au>
References: <20130408014444.18767.64441.sendpatchset@w520>
 <20130409123433.GD15412@verge.net.au>
Message-ID: <20130409161410.GA16003@verge.net.au>

On Tue, Apr 09, 2013 at 09:34:34PM +0900, Simon Horman wrote:
> On Mon, Apr 08, 2013 at 10:44:44AM +0900, Magnus Damm wrote:
> > From: Takashi Yoshii <takashi.yoshii.zj at renesas.com>
> > 
> > Add 1GiB of DRAM at 0x2_0000_0000
> > 
> > Signed-off-by: Takashi Yoshii <takashi.yoshii.zj at renesas.com>
> > Signed-off-by: Magnus Damm <damm at opensource.se>
> 
> Thanks, queued up in the boards-ape6evm branch.

I have dropped this patch as it appears to prevent
the board from booting.

> 
> > ---
> > 
> >  This patch simply updates the DTS to describe the actual board
> >  hardware. If we want to make use of the memory we also need to
> >  enable LPAE in the kernel configuration, but that is seen as a
> >  separate step.
> > 
> >  arch/arm/boot/dts/r8a73a4-ape6evm.dts |    5 +++++
> >  1 file changed, 5 insertions(+)
> > 
> > --- 0001/arch/arm/boot/dts/r8a73a4-ape6evm.dts
> > +++ work/arch/arm/boot/dts/r8a73a4-ape6evm.dts	2013-04-08 10:27:20.000000000 +0900
> > @@ -24,6 +24,11 @@
> >  		reg = <0 0x40000000 0 0x40000000>;
> >  	};
> >  
> > +	memory at 200000000 {
> > +		device_type = "memory";
> > +		reg = <2 0x00000000 0 0x40000000>;
> > +	};
> > +
> >  	ape6evm_fixed_3v3: fixedregulator at 0 {
> >  		compatible = "regulator-fixed";
> >  		regulator-name = "3V3";
> > 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


From nicolas.pitre at linaro.org  Tue Apr  9 12:30:37 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Tue, 9 Apr 2013 12:30:37 -0400 (EDT)
Subject: [PATCH v4 14/15] ARM: Enable selection of SMP operations at boot
 time
In-Reply-To: <1360041732-17936-15-git-send-email-nicolas.pitre@linaro.org>
References: <1360041732-17936-1-git-send-email-nicolas.pitre@linaro.org>
 <1360041732-17936-15-git-send-email-nicolas.pitre@linaro.org>
Message-ID: <alpine.LFD.2.03.1304091223200.1171@syhkavp.arg>

On Tue, 5 Feb 2013, Nicolas Pitre wrote:

> From: Jon Medhurst <tixy at linaro.org>
> 
> Add a new 'smp_init' hook to machine_desc so platforms can specify a
> function to be used to setup smp ops instead of having a statically
> defined value.
> 
> Signed-off-by: Jon Medhurst <tixy at linaro.org>
> Signed-off-by: Nicolas Pitre <nicolas.pitre at linaro.org>
> Reviewed-by: Santosh Shilimkar <santosh.shilimkar at ti.com>

I've slightly amended this patch to make its usage more flexible, please 
see below.

> diff --git a/arch/arm/include/asm/mach/arch.h b/arch/arm/include/asm/mach/arch.h
> index 917d4fcfd9..3d01c6d6c3 100644
> --- a/arch/arm/include/asm/mach/arch.h
> +++ b/arch/arm/include/asm/mach/arch.h
> @@ -17,8 +17,10 @@ struct pt_regs;
>  struct smp_operations;
>  #ifdef CONFIG_SMP
>  #define smp_ops(ops) (&(ops))
> +#define smp_init_ops(ops) (&(ops))
>  #else
>  #define smp_ops(ops) (struct smp_operations *)NULL
> +#define smp_init_ops(ops) (void (*)(void))NULL
>  #endif
>  
>  struct machine_desc {
> @@ -42,6 +44,7 @@ struct machine_desc {
>  	unsigned char		reserve_lp2 :1;	/* never has lp2	*/
>  	char			restart_mode;	/* default restart mode	*/
>  	struct smp_operations	*smp;		/* SMP operations	*/
> +	void			(*smp_init)(void);
>  	void			(*fixup)(struct tag *, char **,
>  					 struct meminfo *);
>  	void			(*reserve)(void);/* reserve mem blocks	*/
> diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> index 3f6cbb2e3e..41edca8582 100644
> --- a/arch/arm/kernel/setup.c
> +++ b/arch/arm/kernel/setup.c
> @@ -768,7 +768,10 @@ void __init setup_arch(char **cmdline_p)
>  	arm_dt_init_cpu_maps();
>  #ifdef CONFIG_SMP
>  	if (is_smp()) {
> -		smp_set_ops(mdesc->smp);
> +		if(mdesc->smp_init)
> +			(*mdesc->smp_init)();
> +		else
> +			smp_set_ops(mdesc->smp);
>  		smp_init_cpus();
>  	}
>  #endif

I've amended it with the following changes to deal with an issue 
highlighted by Tixy.  If the runtime hook does not initialize the smp 
ops, the core may continue with a default.  That should let MCPM, PSCI 
and Xen play well together.

diff --git a/arch/arm/include/asm/mach/arch.h b/arch/arm/include/asm/mach/arch.h
index c01bf53b85..af8c54c6c6 100644
--- a/arch/arm/include/asm/mach/arch.h
+++ b/arch/arm/include/asm/mach/arch.h
@@ -19,7 +19,7 @@ struct smp_operations;
 #define smp_init_ops(ops) (&(ops))
 #else
 #define smp_ops(ops) (struct smp_operations *)NULL
-#define smp_init_ops(ops) (void (*)(void))NULL
+#define smp_init_ops(ops) (bool (*)(void))NULL
 #endif
 
 struct machine_desc {
@@ -43,7 +43,7 @@ struct machine_desc {
 	unsigned char		reserve_lp2 :1;	/* never has lp2	*/
 	char			restart_mode;	/* default restart mode	*/
 	struct smp_operations	*smp;		/* SMP operations	*/
-	void			(*smp_init)(void);
+	bool			(*smp_init)(void);
 	void			(*fixup)(struct tag *, char **,
 					 struct meminfo *);
 	void			(*reserve)(void);/* reserve mem blocks	*/
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index e69c580c6f..cf4b08c0f9 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -768,9 +768,7 @@ void __init setup_arch(char **cmdline_p)
 	arm_dt_init_cpu_maps();
 #ifdef CONFIG_SMP
 	if (is_smp()) {
-		if (mdesc->smp_init)
-			mdesc->smp_init();
-		else
+		if (!mdesc->smp_init || !mdesc->smp_init())
 			smp_set_ops(mdesc->smp);
 		smp_init_cpus();
 	}


Nicolas


From nicolas.pitre at linaro.org  Tue Apr  9 12:34:25 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Tue, 9 Apr 2013 12:34:25 -0400 (EDT)
Subject: [PATCH v4 15/15] ARM: vexpress: Select multi-cluster SMP operation
 if required
In-Reply-To: <1365487246.3292.3.camel@computer5.home>
References: <1360041732-17936-1-git-send-email-nicolas.pitre@linaro.org>
 <1360041732-17936-16-git-send-email-nicolas.pitre@linaro.org>
 <20130405224819.GB14308@quad.lixom.net>
 <alpine.LFD.2.03.1304060943370.1171@syhkavp.arg>
 <1365412211.3384.16.camel@linaro1.home>
 <alpine.LFD.2.03.1304090135590.1171@syhkavp.arg>
 <1365487246.3292.3.camel@computer5.home>
Message-ID: <alpine.LFD.2.03.1304090829590.1171@syhkavp.arg>

On Tue, 9 Apr 2013, Jon Medhurst (Tixy) wrote:

> On Tue, 2013-04-09 at 01:41 -0400, Nicolas Pitre wrote:
> > > Do the changes to the above mcpm files want to be in a separate patch as
> > > it's generic ARM code, not vexpress specific?
> > 
> > Well, since it was so trivial I didn't do it, but the split might be a 
> > good idea nevertheless.  So I inserted the following patch in the 
> > series, and corresponding changes are now removed from the patch above.  
> > What do you think?
> 
> Looks fine. 

May I add your ACK?

> Did you miss my other comment about smp_ops not looking like they were 
> getting set in the case of mcpm_smp_set_ops not getting called?

You are right.  See my change to #14/15 to fix that.

The VExpress patch now becomes this (only change is the return value):

Author: Jon Medhurst <tixy at linaro.org>
Date:   Wed Jan 30 09:12:55 2013 +0000

    ARM: vexpress: Select multi-cluster SMP operation if required
    
    Signed-off-by: Jon Medhurst <tixy at linaro.org>
    Signed-off-by: Nicolas Pitre <nicolas.pitre at linaro.org>
    Reviewed-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
    Acked-by: Pawel Moll <pawel.moll at arm.com>

diff --git a/arch/arm/mach-vexpress/core.h b/arch/arm/mach-vexpress/core.h
index f134cd4a85..bde4374ab6 100644
--- a/arch/arm/mach-vexpress/core.h
+++ b/arch/arm/mach-vexpress/core.h
@@ -6,6 +6,8 @@
 
 void vexpress_dt_smp_map_io(void);
 
+bool vexpress_smp_init_ops(void);
+
 extern struct smp_operations	vexpress_smp_ops;
 
 extern void vexpress_cpu_die(unsigned int cpu);
diff --git a/arch/arm/mach-vexpress/platsmp.c b/arch/arm/mach-vexpress/platsmp.c
index dc1ace55d5..f31a7af712 100644
--- a/arch/arm/mach-vexpress/platsmp.c
+++ b/arch/arm/mach-vexpress/platsmp.c
@@ -12,9 +12,11 @@
 #include <linux/errno.h>
 #include <linux/smp.h>
 #include <linux/io.h>
+#include <linux/of.h>
 #include <linux/of_fdt.h>
 #include <linux/vexpress.h>
 
+#include <asm/mcpm_entry.h>
 #include <asm/smp_scu.h>
 #include <asm/mach/map.h>
 
@@ -203,3 +205,21 @@ struct smp_operations __initdata vexpress_smp_ops = {
 	.cpu_die		= vexpress_cpu_die,
 #endif
 };
+
+bool __init vexpress_smp_init_ops(void)
+{
+#ifdef CONFIG_MCPM
+	/*
+	 * The best way to detect a multi-cluster configuration at the moment
+	 * is to look for the presence of a CCI in the system.
+	 * Override the default vexpress_smp_ops if so.
+	 */
+	struct device_node *node;
+	node = of_find_compatible_node(NULL, NULL, "arm,cci");
+	if (node && of_device_is_available(node)) {
+		mcpm_smp_set_ops();
+		return true;
+	}
+#endif
+	return false;
+}
diff --git a/arch/arm/mach-vexpress/v2m.c b/arch/arm/mach-vexpress/v2m.c
index 915683cb67..16b42c10e0 100644
--- a/arch/arm/mach-vexpress/v2m.c
+++ b/arch/arm/mach-vexpress/v2m.c
@@ -476,6 +476,7 @@ static const char * const v2m_dt_match[] __initconst = {
 DT_MACHINE_START(VEXPRESS_DT, "ARM-Versatile Express")
 	.dt_compat	= v2m_dt_match,
 	.smp		= smp_ops(vexpress_smp_ops),
+	.smp_init	= smp_init_ops(vexpress_smp_init_ops),
 	.map_io		= v2m_dt_map_io,
 	.init_early	= v2m_dt_init_early,
 	.init_irq	= irqchip_init,


From tony at atomide.com  Tue Apr  9 12:34:59 2013
From: tony at atomide.com (Tony Lindgren)
Date: Tue, 9 Apr 2013 09:34:59 -0700
Subject: [RFC PATCH 3/3] ARM: OMAP2+: Add command line parameter for
 debugSS module control
In-Reply-To: <79CD15C6BA57404B839C016229A409A83EC47BB2@DBDE01.ent.ti.com>
References: <hvaibhav@ti.com>
 <1362396957-30113-4-git-send-email-hvaibhav@ti.com>
 <20130408172936.GQ10155@atomide.com>
 <79CD15C6BA57404B839C016229A409A83EC47BB2@DBDE01.ent.ti.com>
Message-ID: <20130409163459.GJ10155@atomide.com>

* Hiremath, Vaibhav <hvaibhav at ti.com> [130409 01:12]:
> > From: Tony Lindgren [mailto:tony at atomide.com]
> > 
> > I suggest you just make this part into a standard DT only
> > device driver. That way the command line parsing and clock
> > enabling can happen the normal way.
> > 
> 
> That?s good idea, as we are moving towards DT only boot support.
> Also, are you suggesting to have both command-line param and DT
> Property for this?
> 
> 
> > Is there any reason why this could not be a loadable module?
> > 
> 
> Because we want to keep it enabled before late_initcall. As part of late_initcall
> Clock/hwmod framework will start disabling unused modules, which will impact the
> Debugs as well. Consider the case where this debugss is loaded as a module, the user
> Will loose the JTAG connection until the module is loaded; and once module is
> Loaded, he has to again re-connect to the debugss.

It will get run before late_initcall if compiled in. Sounds
like there are no issues also make it work as a loadable module
as needed.
 
> With only DT option the code will look like below, is this what you also have in your mind -
> 
> arch/arm/boot/dts/am33xx.dtsi:
> 
> 	debugss: debugss at 4b000000 {
> 		compatible = "ti,debugss";
> 		ti,hwmods = "debugss";
> 		reg = <0x4b000000 1000000>;
> 		status = "disabled";	/* User need to enable it if he need JTAG connectivity*/
> 	};
>
>
> arch/arm/mach-omap2/debugss.c:
> 
> 	static int __init _omap2_debugss_enable(void)
> 	{
> 		struct device_node *np;
> 	
> 		np = of_find_matching_node(oh_name);
> 		if (!node || ! of_device_is_available()) {
> 			pr_err("debugss device is not found\n");
> 			return -ENODEV;
> 		}
> 		...
> 		hwmod lookup./setup/enable along with optional clock enable.
> 		...
> 
> 	}
> 	device_initcall(_omap2_debugss_enable);

It should be all standard device driver stuff. I'd make it just
regular module_platform_driver and only initialize it earlier if
compiled in.

Regards,

Tony




From khilman at linaro.org  Tue Apr  9 12:38:28 2013
From: khilman at linaro.org (Kevin Hilman)
Date: Tue, 09 Apr 2013 09:38:28 -0700
Subject: [GIT PULL 2/5] omap pm clean-up for v3.10 merge window
In-Reply-To: <201304091652.28385.arnd@arndb.de> (Arnd Bergmann's message of
 "Tue, 9 Apr 2013 16:52:28 +0200")
References: <0MarPy-1U9XGk2D8s-00Ks1o@mx.kundenserver.de>
 <201304091652.28385.arnd@arndb.de>
Message-ID: <87vc7virqz.fsf@linaro.org>

Arnd Bergmann <arnd at arndb.de> writes:

> On Tuesday 09 April 2013, Tony Lindgren wrote:
>> The following changes since commit 07961ac7c0ee8b546658717034fe692fd12eefa9:
>> 
>>   Linux 3.9-rc5 (2013-03-31 15:12:43 -0700)
>> 
>> are available in the git repository at:
>> 
>>   git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.10/cleanup-pm-signed
>> 
>> for you to fetch changes up to ca8cdff548da76da01f3783548ceb917139a5ddc:
>> 
>>   Merge tag 'omap-pm-v3.10/cleanup/cpuidle' of
>> git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm
>> into omap-for-v3.10/cleanup-pm (2013-04-08 09:51:00 -0700)
>> 
>> ----------------------------------------------------------------
>> 
>> PM cleanup to prepare for omap5 PM via Kevin Hilman <khilman at linaro.org>:
>> 
>> OMAP3/4 CPUidle cleanups for v3.10
>
> Adding Daniel and Rafael to Cc.
>
> Is this series coordinated with the other cpuidle changes? Please tell me if this
> is good to go into arm-soc.

Hmm, looks like it's not ready.  There are some minor conflicts with
what Rafael has queued up from Daniel.

I will work this out with Daniel to figure out how we should proceed.

Kevin


From sboyd at codeaurora.org  Tue Apr  9 12:42:38 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Tue, 09 Apr 2013 09:42:38 -0700
Subject: [PATCH 1/4] Documentation: Add memory mapped ARM architected
 timer binding
In-Reply-To: <20130409090843.GS23725@e106331-lin.cambridge.arm.com>
References: <1365474623-29181-1-git-send-email-sboyd@codeaurora.org>
 <1365474623-29181-2-git-send-email-sboyd@codeaurora.org>
 <20130409090843.GS23725@e106331-lin.cambridge.arm.com>
Message-ID: <516444FE.2080200@codeaurora.org>

On 04/09/13 02:08, Mark Rutland wrote:
> On Tue, Apr 09, 2013 at 03:30:20AM +0100, Stephen Boyd wrote:
>>  
>> -** Timer node properties:
>> +** CP15 Timer node properties:
>>  
>>  - compatible : Should at least contain one of
>>  	"arm,armv7-timer"
>> @@ -26,3 +30,55 @@ Example:
>>  			     <1 10 0xf08>;
>>  		clock-frequency = <100000000>;
>>  	};
>> +
>> +** Memory mapped timer node properties
>> +
>> +- compatible : Should at least contain "arm,armv7-timer-mem".
>> +
>> +- #address-cells : Must be 1.
> What about LPAE systems?
>
> How about something like the following:
>
> #address-cells : If the ranges property is empty, the same value as the
>                  parent node's #address-cells property. Otherwise, a
> 		 value such that the ranges property specifies a
> 		 mapping to the parent node's address space.            

Yes that is much better. I wasn't trying to preclude LPAE or 64 bit systems.

>> +
>> +- #size-cells : Must be 1.
>> +
>> +- ranges : Indicates parent and child bus address space are the same.
>> +
> Similarly, what if someone wants to write a more complex mapping for some
> reason?
>
> We should be able to handle it if we use the standard accessors.

Maybe I should just leave this part out? They are standard DT properties
so I could assume DT writers know what to do.

>> +- clock-frequency : The frequency of the main counter, in Hz. Optional.
>> +
>> +- reg : The control frame base address.
>> +
>> +Frame:
>> +
>> +- frame-id: Encoded as follows:
>> +		bits[3:0]  frame number: 0 to 7.
>> +		bits[10:8] frame usage:
>> +			0 - user/kernel
>> +			1 - hyp
>> +			2 - secure
>> +
> Could we not just have a disabled status property for those frames claimed by a
> higher level (either secure firmware or hypervisor)? Or have I missed something
> here?

Using disabled status would work. I was also thinking maybe we should
use a compatible string in each frame's node. Then we could match
against compatible children like "frame-user", "frame-kernel",
"frame-hyp", "frame-secure", "frame-user-kernel", etc. It allows us
flexibility if we should need to add something else in the future.

Also to get the frame number, I was thinking maybe we should expand the
reg property to have two address cells. Then we could have reg = <0
0xf0001000 0x1000>.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Tue Apr  9 12:47:42 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Tue, 09 Apr 2013 09:47:42 -0700
Subject: [PATCHv2] ARM: Push selects for TWD/SCU into machine entries
In-Reply-To: <5151DC41.7090307@codeaurora.org>
References: <1362007694-3419-1-git-send-email-sboyd@codeaurora.org>
 <512E9A39.3070207@wwwdotorg.org> <51354E35.1080804@codeaurora.org>
 <201303052234.32723.arnd@arndb.de> <5144C8DC.9010104@codeaurora.org>
 <5151DC41.7090307@codeaurora.org>
Message-ID: <5164462E.4010706@codeaurora.org>

On 03/26/13 10:34, Stephen Boyd wrote:
> On 03/16/13 12:32, Stephen Boyd wrote:
>> On 3/5/2013 2:34 PM, Arnd Bergmann wrote:
>>> On Tuesday 05 March 2013, Stephen Boyd wrote:
>>>> On 02/27/13 15:43, Stephen Warren wrote:
>>>>> Seems simple enough it doesn't really need many, but for Tegra,
>>>>> Acked-by: Stephen Warren <swarren at nvidia.com>
>>>>>
>>>>> Which kernel is this going into? It's possible Tegra will get converted
>>>>> to multi-platform in 3.10, which might move that main ARCH_TEGRA block
>>>>> from arch/arm/Kconfig into arch/arm/mach-tegra/Kconfig, although I
>>>>> suppose it doesn't have to move it. I think some/all(?) other
>>>>> multi-platform conversions have moved their main Kconfig option like
>>>>> that though.
>>>> Thanks. I'm hoping that Arnd/Olof can pick this up. I'm not sure which
>>>> version it will go into.
>>>>
>>> Hmm, it certainly looks useful to me. I think it should go into the next
>>> cleanup branch as a base, so others can build on top of it. We will
>>> also need it for the Exynos multiplatform patches that I hope can land
>>> in 3.10 as well.
>>>
>>> Sneaking it in through the fixes branch would make life easier for us,
>>> but it doesn't feel right.
>> Arnd, can you pick this up into the arm-soc tree now? It would be good
>> to get this into next so that conflicts are avoided later on.
>>
> Arnd?
>

Ping?

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Tue Apr  9 12:49:27 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Tue, 09 Apr 2013 09:49:27 -0700
Subject: [PATCHv4 01/11] clockevents: Prefer CPU local devices over global
 devices
In-Reply-To: <20130409103303.GV23725@e106331-lin.cambridge.arm.com>
References: <1365456453-16297-1-git-send-email-sboyd@codeaurora.org>
 <1365456453-16297-2-git-send-email-sboyd@codeaurora.org>
 <20130409103303.GV23725@e106331-lin.cambridge.arm.com>
Message-ID: <51644697.2010707@codeaurora.org>

On 04/09/13 03:33, Mark Rutland wrote:
> On Mon, Apr 08, 2013 at 10:27:23PM +0100, Stephen Boyd wrote:
>> On an SMP system with only one global clockevent and a dummy
>> clockevent per CPU we run into problems. We want the dummy
>> clockevents to be registered as the per CPU tick devices, but
>> we can only achieve that if we register the dummy clockevents
>> before the global clockevent or if we artificially inflate the
>> rating of the dummy clockevents to be higher than the rating
>> of the global clockevent. Failure to do so leads to boot
>> hangs when the dummy timers are registered on all other CPUs
>> besides the CPU that accepted the global clockevent as its tick
>> device and there is no broadcast timer to poke the dummy
>> devices.
>>
>> If we're registering multiple clockevents and one clockevent is
>> global and the other is local to a particular CPU we should
>> choose to use the local clockevent regardless of the rating of
>> the device. This way, if the clockevent is a dummy it will take
>> the tick device duty as long as there isn't a higher rated tick
>> device and any global clockevent will be bumped out into
>> broadcast mode, fixing the problem described above.
> It might be worth pointing out that if dummy timers are only registered
> when there's more than one CPU, UP behaviour won't degrade from the
> current state of affairs.

Sure, I'll try to come up with something if I have to repost (looks like
I might have to rework the mct change).

>
>> Reported-by: Mark Rutland <mark.rutland at arm.com>
>> Cc: John Stultz <john.stultz at linaro.org>
>> Cc: Thomas Gleixner <tglx at linutronix.de>
>> Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
>> ---
>>  kernel/time/tick-common.c | 5 +++--
>>  1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/kernel/time/tick-common.c b/kernel/time/tick-common.c
>> index b1600a6..9ea59b9 100644
>> --- a/kernel/time/tick-common.c
>> +++ b/kernel/time/tick-common.c
>> @@ -251,9 +251,10 @@ static int tick_check_new_device(struct clock_event_device *newdev)
>>  		    !(newdev->features & CLOCK_EVT_FEAT_ONESHOT))
>>  			goto out_bc;
>>  		/*
>> -		 * Check the rating
>> +		 * Check the rating, but prefer CPU local devices
>>  		 */
>> -		if (curdev->rating >= newdev->rating)
>> +		if (curdev->rating >= newdev->rating &&
>> +		    cpumask_equal(curdev->cpumask, newdev->cpumask))
>>  			goto out_bc;
>>  	}
> This looks good to me. I tested this on a TC2 with a v3.9-rc6 kernel
> without architected timer support. The patch restores the ability to use
> the sp804 as a broadcast source.
>
> Tested-by: Mark Rutland <mark.rutland at arm.com>
>
> If possible I think this should sit in -next for a bit to make sure it
> doesn't have any unexpected side effects.

Thanks for testing.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation



From tony at atomide.com  Tue Apr  9 12:49:29 2013
From: tony at atomide.com (Tony Lindgren)
Date: Tue, 9 Apr 2013 09:49:29 -0700
Subject: [RFC][PATCH 1/2] ARM: OMAP4: clock: Add device tree support
 for AUXCLKs
In-Reply-To: <5163E589.1040809@ti.com>
References: <1363703220-4777-1-git-send-email-rogerq@ti.com>
 <1363703220-4777-2-git-send-email-rogerq@ti.com>
 <20130403234242.GE10155@atomide.com> <515D2D30.3000306@ti.com>
 <20130404164137.GH10155@atomide.com> <515EA9E3.1010409@ti.com>
 <20130405155851.GA10155@atomide.com> <5163E589.1040809@ti.com>
Message-ID: <20130409164928.GL10155@atomide.com>

* Roger Quadros <rogerq at ti.com> [130409 03:00]:
> On 04/05/2013 06:58 PM, Tony Lindgren wrote:
> > 
> > Well your approach is fine as a first step moving all the clock
> > code, but it needs to be a real driver under drivers/clock/omap.
> > And the DT binding needs to stay the same for the driver(s) in the
> > long term as we start moving clocks to DT + /lib/firmware.
> 
> The code needs to be there were the clock structs are defined.
> Currently they are in arch/arm/mach-omap2/cclock44xx_data.c for OMAP4.

But if you do just a passthrough driver then that should not
be needed. 
 
> > If this all is too late for v3.10, I suggest you just set up the
> > right clock alias for panda with machine_is_compatible flag in
> > board-generic.c so we get EHCI working with DT for v3.10. Then
> > it's easy to to deal with it properly for v3.11.
> 
> OK, let's do it this way for Panda for 3.10.

Yes otherwise we'll be delaying omap4 DT conversion again. 
 
> >> How can that driver do clk_get() from cclock44xx_data.c?
> >> from where does it get the clk_id to pass into clk_get()?
> > 
> > Can't you just use the clock name there to get it?
> 
> In device tree we don't pass around clock names. You can either get
> a phandle or an index to the clock.
> 
> e.g. Documentation/devicetree/bindings/clock/imx31-clock.txt

Yes I understand that. But the driver/clock/omap driver can just
remap the DT device initially so the board specific clock is
found from the clock alias table. Basically initially a passthrough
driver that can be enhanced to parse DT clock bindings and load
data from /lib/firmware.

> > As long as the binding stays the same in the long run too, this
> > clock remapping approach is just fine as a starting point. And
> > the driver needs to go to drivers/clock/omap. But in the long run
> > we just want to get the huge amounts static data out of the kernel
> > for clocks and hwmod data to fix things for good.
> 
> In that case we need to identify what clocks need to be supported.
> If it is all (~200) of them, is this method good enough?

We should support any clock we need for booting the device with
just DT bindings to get timers, console and rootfs working. Then
we just need to load the complete set from /lib/firmware.

It seems that the binding can be the same for all the clocks.
For now, we can just use the standard clock binding and do the
remapping in the clock driver.

Regards,

Tony


From tixy at linaro.org  Tue Apr  9 12:55:02 2013
From: tixy at linaro.org (Jon Medhurst (Tixy))
Date: Tue, 09 Apr 2013 17:55:02 +0100
Subject: [PATCH v4 14/15] ARM: Enable selection of SMP operations at
 boot time
In-Reply-To: <alpine.LFD.2.03.1304091223200.1171@syhkavp.arg>
References: <1360041732-17936-1-git-send-email-nicolas.pitre@linaro.org>
 <1360041732-17936-15-git-send-email-nicolas.pitre@linaro.org>
 <alpine.LFD.2.03.1304091223200.1171@syhkavp.arg>
Message-ID: <1365526502.3434.90.camel@linaro1.home>

On Tue, 2013-04-09 at 12:30 -0400, Nicolas Pitre wrote:
> On Tue, 5 Feb 2013, Nicolas Pitre wrote:
> 
> > From: Jon Medhurst <tixy at linaro.org>
> > 
> > Add a new 'smp_init' hook to machine_desc so platforms can specify a
> > function to be used to setup smp ops instead of having a statically
> > defined value.
> > 
> > Signed-off-by: Jon Medhurst <tixy at linaro.org>
> > Signed-off-by: Nicolas Pitre <nicolas.pitre at linaro.org>
> > Reviewed-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
> 
> I've slightly amended this patch to make its usage more flexible, please 
> see below.

Looks good to me.

Reviewed-by: Jon Medhurst <tixy at linaro.org>

> > diff --git a/arch/arm/include/asm/mach/arch.h b/arch/arm/include/asm/mach/arch.h
> > index 917d4fcfd9..3d01c6d6c3 100644
> > --- a/arch/arm/include/asm/mach/arch.h
> > +++ b/arch/arm/include/asm/mach/arch.h
> > @@ -17,8 +17,10 @@ struct pt_regs;
> >  struct smp_operations;
> >  #ifdef CONFIG_SMP
> >  #define smp_ops(ops) (&(ops))
> > +#define smp_init_ops(ops) (&(ops))
> >  #else
> >  #define smp_ops(ops) (struct smp_operations *)NULL
> > +#define smp_init_ops(ops) (void (*)(void))NULL
> >  #endif
> >  
> >  struct machine_desc {
> > @@ -42,6 +44,7 @@ struct machine_desc {
> >  	unsigned char		reserve_lp2 :1;	/* never has lp2	*/
> >  	char			restart_mode;	/* default restart mode	*/
> >  	struct smp_operations	*smp;		/* SMP operations	*/
> > +	void			(*smp_init)(void);
> >  	void			(*fixup)(struct tag *, char **,
> >  					 struct meminfo *);
> >  	void			(*reserve)(void);/* reserve mem blocks	*/
> > diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> > index 3f6cbb2e3e..41edca8582 100644
> > --- a/arch/arm/kernel/setup.c
> > +++ b/arch/arm/kernel/setup.c
> > @@ -768,7 +768,10 @@ void __init setup_arch(char **cmdline_p)
> >  	arm_dt_init_cpu_maps();
> >  #ifdef CONFIG_SMP
> >  	if (is_smp()) {
> > -		smp_set_ops(mdesc->smp);
> > +		if(mdesc->smp_init)
> > +			(*mdesc->smp_init)();
> > +		else
> > +			smp_set_ops(mdesc->smp);
> >  		smp_init_cpus();
> >  	}
> >  #endif
> 
> I've amended it with the following changes to deal with an issue 
> highlighted by Tixy.  If the runtime hook does not initialize the smp 
> ops, the core may continue with a default.  That should let MCPM, PSCI 
> and Xen play well together.
> 
> diff --git a/arch/arm/include/asm/mach/arch.h b/arch/arm/include/asm/mach/arch.h
> index c01bf53b85..af8c54c6c6 100644
> --- a/arch/arm/include/asm/mach/arch.h
> +++ b/arch/arm/include/asm/mach/arch.h
> @@ -19,7 +19,7 @@ struct smp_operations;
>  #define smp_init_ops(ops) (&(ops))
>  #else
>  #define smp_ops(ops) (struct smp_operations *)NULL
> -#define smp_init_ops(ops) (void (*)(void))NULL
> +#define smp_init_ops(ops) (bool (*)(void))NULL
>  #endif
>  
>  struct machine_desc {
> @@ -43,7 +43,7 @@ struct machine_desc {
>  	unsigned char		reserve_lp2 :1;	/* never has lp2	*/
>  	char			restart_mode;	/* default restart mode	*/
>  	struct smp_operations	*smp;		/* SMP operations	*/
> -	void			(*smp_init)(void);
> +	bool			(*smp_init)(void);
>  	void			(*fixup)(struct tag *, char **,
>  					 struct meminfo *);
>  	void			(*reserve)(void);/* reserve mem blocks	*/
> diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> index e69c580c6f..cf4b08c0f9 100644
> --- a/arch/arm/kernel/setup.c
> +++ b/arch/arm/kernel/setup.c
> @@ -768,9 +768,7 @@ void __init setup_arch(char **cmdline_p)
>  	arm_dt_init_cpu_maps();
>  #ifdef CONFIG_SMP
>  	if (is_smp()) {
> -		if (mdesc->smp_init)
> -			mdesc->smp_init();
> -		else
> +		if (!mdesc->smp_init || !mdesc->smp_init())
>  			smp_set_ops(mdesc->smp);
>  		smp_init_cpus();
>  	}
> 
> 
> Nicolas




From tony at atomide.com  Tue Apr  9 12:55:03 2013
From: tony at atomide.com (Tony Lindgren)
Date: Tue, 9 Apr 2013 09:55:03 -0700
Subject: [PATCH v3 2/4] ARM: OMAP4+: PM: Consolidate OMAP4 PM code to
 re-use it for OMAP5
In-Reply-To: <5163B19E.30105@ti.com>
References: <1365166743-5940-1-git-send-email-santosh.shilimkar@ti.com>
 <1365166743-5940-3-git-send-email-santosh.shilimkar@ti.com>
 <20130405213433.GF10155@atomide.com> <5162A093.7090808@ti.com>
 <20130408164228.GK10155@atomide.com> <5163B19E.30105@ti.com>
Message-ID: <20130409165503.GM10155@atomide.com>

* Santosh Shilimkar <santosh.shilimkar at ti.com> [130408 23:16]:
> > 
> As I said, the IP has been there from OMAP2XX days. Here the case that
> IP version is very similar between OMAP4, OMAP5. DRA(next SOC) and its
> derivatives. Hence can share most of the code. I thought this was good
> enough reason considering at least 4 family of SOC's can make use
> of the code.

Well at least that might be enough of a reasoning to rename it as
it is somewhat futureproof.
 
> It has nothing to do with SMP etc specifically and rather the similarity
> between the PM infrastructure on the mentioned SOCs. 
>
> Let me know if you can suggested better name than what I chose ?

Not really except something like pm-iprevXXX.[chS] where the rev is
the first revision that it works with?

But then again if it's touching registers all over the place directly,
that naming does not make much sense either :)

Regards,

Tony


From tony at atomide.com  Tue Apr  9 12:56:33 2013
From: tony at atomide.com (Tony Lindgren)
Date: Tue, 9 Apr 2013 09:56:33 -0700
Subject: [GIT PULL 2/5] omap pm clean-up for v3.10 merge window
In-Reply-To: <87vc7virqz.fsf@linaro.org>
References: <0MarPy-1U9XGk2D8s-00Ks1o@mx.kundenserver.de>
 <201304091652.28385.arnd@arndb.de> <87vc7virqz.fsf@linaro.org>
Message-ID: <20130409165633.GN10155@atomide.com>

* Kevin Hilman <khilman at linaro.org> [130409 09:43]:
> Arnd Bergmann <arnd at arndb.de> writes:
> 
> > On Tuesday 09 April 2013, Tony Lindgren wrote:
> >> The following changes since commit 07961ac7c0ee8b546658717034fe692fd12eefa9:
> >> 
> >>   Linux 3.9-rc5 (2013-03-31 15:12:43 -0700)
> >> 
> >> are available in the git repository at:
> >> 
> >>   git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.10/cleanup-pm-signed
> >> 
> >> for you to fetch changes up to ca8cdff548da76da01f3783548ceb917139a5ddc:
> >> 
> >>   Merge tag 'omap-pm-v3.10/cleanup/cpuidle' of
> >> git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm
> >> into omap-for-v3.10/cleanup-pm (2013-04-08 09:51:00 -0700)
> >> 
> >> ----------------------------------------------------------------
> >> 
> >> PM cleanup to prepare for omap5 PM via Kevin Hilman <khilman at linaro.org>:
> >> 
> >> OMAP3/4 CPUidle cleanups for v3.10
> >
> > Adding Daniel and Rafael to Cc.
> >
> > Is this series coordinated with the other cpuidle changes? Please tell me if this
> > is good to go into arm-soc.
> 
> Hmm, looks like it's not ready.  There are some minor conflicts with
> what Rafael has queued up from Daniel.
> 
> I will work this out with Daniel to figure out how we should proceed.

OK it seems that this branch can also be queued by Rafael after
updating it if there's a dependency. So far it's not conflicting
with anything else we have queued up for arm soc tree.

Regards,

Tony


From p.zabel at pengutronix.de  Tue Apr  9 13:18:47 2013
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Tue,  9 Apr 2013 19:18:47 +0200
Subject: [PATCH] ARM i.MX53: dts: add i2c aliases
Message-ID: <1365527927-20618-1-git-send-email-p.zabel@pengutronix.de>

This allows to order the i2c character devices correctly,
so that /dev/i2c-0 corresponds to i2c1, /dev/i2c-1 corresponds
to i2c2, and so on. Currently they are ordered by register
address.

Signed-off-by: Philipp Zabel <p.zabel at pengutronix.de>
---
 arch/arm/boot/dts/imx53.dtsi | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/boot/dts/imx53.dtsi b/arch/arm/boot/dts/imx53.dtsi
index 845982e..7b9a391 100644
--- a/arch/arm/boot/dts/imx53.dtsi
+++ b/arch/arm/boot/dts/imx53.dtsi
@@ -27,6 +27,9 @@
 		gpio4 = &gpio5;
 		gpio5 = &gpio6;
 		gpio6 = &gpio7;
+		i2c0 = &i2c1;
+		i2c1 = &i2c2;
+		i2c2 = &i2c3;
 	};
 
 	tzic: tz-interrupt-controller at 0fffc000 {
-- 
1.8.2.rc2



From jon-hunter at ti.com  Tue Apr  9 13:23:35 2013
From: jon-hunter at ti.com (Jon Hunter)
Date: Tue, 9 Apr 2013 12:23:35 -0500
Subject: [PATCH] Documentation: dt: update properties in TI GPMC NAND example
Message-ID: <1365528215-5030-1-git-send-email-jon-hunter@ti.com>

The GPMC timing properties for device-tree have been updated
by adding a "-ns" or "-ps" suffix to indicate the units of
time the property represents. Therefore, update the timing
property names for TI GPMC NAND example.

Signed-off-by: Jon Hunter <jon-hunter at ti.com>
---
 .../devicetree/bindings/mtd/gpmc-nand.txt          |   28 ++++++++++----------
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
index e7f8d7e..6a983c1 100644
--- a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
@@ -56,20 +56,20 @@ Example for an AM33xx board:
 			nand-bus-width = <16>;
 			ti,nand-ecc-opt = "bch8";
 
-			gpmc,sync-clk = <0>;
-			gpmc,cs-on = <0>;
-			gpmc,cs-rd-off = <44>;
-			gpmc,cs-wr-off = <44>;
-			gpmc,adv-on = <6>;
-			gpmc,adv-rd-off = <34>;
-			gpmc,adv-wr-off = <44>;
-			gpmc,we-off = <40>;
-			gpmc,oe-off = <54>;
-			gpmc,access = <64>;
-			gpmc,rd-cycle = <82>;
-			gpmc,wr-cycle = <82>;
-			gpmc,wr-access = <40>;
-			gpmc,wr-data-mux-bus = <0>;
+			gpmc,sync-clk-ps = <0>;
+			gpmc,cs-on-ns = <0>;
+			gpmc,cs-rd-off-ns = <44>;
+			gpmc,cs-wr-off-ns = <44>;
+			gpmc,adv-on-ns = <6>;
+			gpmc,adv-rd-off-ns = <34>;
+			gpmc,adv-wr-off-ns = <44>;
+			gpmc,we-off-ns = <40>;
+			gpmc,oe-off-ns = <54>;
+			gpmc,access-ns = <64>;
+			gpmc,rd-cycle-ns = <82>;
+			gpmc,wr-cycle-ns = <82>;
+			gpmc,wr-access-ns = <40>;
+			gpmc,wr-data-mux-bus-ns = <0>;
 
 			#address-cells = <1>;
 			#size-cells = <1>;
-- 
1.7.10.4



From tixy at linaro.org  Tue Apr  9 13:28:43 2013
From: tixy at linaro.org (Jon Medhurst (Tixy))
Date: Tue, 09 Apr 2013 18:28:43 +0100
Subject: [PATCH v4 15/15] ARM: vexpress: Select multi-cluster SMP
 operation if required
In-Reply-To: <alpine.LFD.2.03.1304090829590.1171@syhkavp.arg>
References: <1360041732-17936-1-git-send-email-nicolas.pitre@linaro.org>
 <1360041732-17936-16-git-send-email-nicolas.pitre@linaro.org>
 <20130405224819.GB14308@quad.lixom.net>
 <alpine.LFD.2.03.1304060943370.1171@syhkavp.arg>
 <1365412211.3384.16.camel@linaro1.home>
 <alpine.LFD.2.03.1304090135590.1171@syhkavp.arg>
 <1365487246.3292.3.camel@computer5.home>
 <alpine.LFD.2.03.1304090829590.1171@syhkavp.arg>
Message-ID: <1365528523.3434.105.camel@linaro1.home>

On Tue, 2013-04-09 at 12:34 -0400, Nicolas Pitre wrote:
> On Tue, 9 Apr 2013, Jon Medhurst (Tixy) wrote:
> 
> > On Tue, 2013-04-09 at 01:41 -0400, Nicolas Pitre wrote:
> > > > Do the changes to the above mcpm files want to be in a separate patch as
> > > > it's generic ARM code, not vexpress specific?
> > > 
> > > Well, since it was so trivial I didn't do it, but the split might be a 
> > > good idea nevertheless.  So I inserted the following patch in the 
> > > series, and corresponding changes are now removed from the patch above.  
> > > What do you think?
> > 
> > Looks fine. 
> 
> May I add your ACK?

Yes,
Acked-by: Jon Medhurst <tixy at linaro.org>

> > Did you miss my other comment about smp_ops not looking like they were 
> > getting set in the case of mcpm_smp_set_ops not getting called?
> 
> You are right.  See my change to #14/15 to fix that.
> 
> The VExpress patch now becomes this (only change is the return value):
> 
> Author: Jon Medhurst <tixy at linaro.org>
> Date:   Wed Jan 30 09:12:55 2013 +0000
> 
>     ARM: vexpress: Select multi-cluster SMP operation if required
>     
>     Signed-off-by: Jon Medhurst <tixy at linaro.org>
>     Signed-off-by: Nicolas Pitre <nicolas.pitre at linaro.org>
>     Reviewed-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
>     Acked-by: Pawel Moll <pawel.moll at arm.com>
> 
> diff --git a/arch/arm/mach-vexpress/core.h b/arch/arm/mach-vexpress/core.h
> index f134cd4a85..bde4374ab6 100644
> --- a/arch/arm/mach-vexpress/core.h
> +++ b/arch/arm/mach-vexpress/core.h
> @@ -6,6 +6,8 @@
>  
>  void vexpress_dt_smp_map_io(void);
>  
> +bool vexpress_smp_init_ops(void);
> +
>  extern struct smp_operations	vexpress_smp_ops;
>  
>  extern void vexpress_cpu_die(unsigned int cpu);
> diff --git a/arch/arm/mach-vexpress/platsmp.c b/arch/arm/mach-vexpress/platsmp.c
> index dc1ace55d5..f31a7af712 100644
> --- a/arch/arm/mach-vexpress/platsmp.c
> +++ b/arch/arm/mach-vexpress/platsmp.c
> @@ -12,9 +12,11 @@
>  #include <linux/errno.h>
>  #include <linux/smp.h>
>  #include <linux/io.h>
> +#include <linux/of.h>
>  #include <linux/of_fdt.h>
>  #include <linux/vexpress.h>
>  
> +#include <asm/mcpm_entry.h>
>  #include <asm/smp_scu.h>
>  #include <asm/mach/map.h>
>  
> @@ -203,3 +205,21 @@ struct smp_operations __initdata vexpress_smp_ops = {
>  	.cpu_die		= vexpress_cpu_die,
>  #endif
>  };
> +
> +bool __init vexpress_smp_init_ops(void)
> +{
> +#ifdef CONFIG_MCPM
> +	/*
> +	 * The best way to detect a multi-cluster configuration at the moment
> +	 * is to look for the presence of a CCI in the system.
> +	 * Override the default vexpress_smp_ops if so.
> +	 */
> +	struct device_node *node;
> +	node = of_find_compatible_node(NULL, NULL, "arm,cci");
> +	if (node && of_device_is_available(node)) {
> +		mcpm_smp_set_ops();
> +		return true;
> +	}
> +#endif
> +	return false;
> +}
> diff --git a/arch/arm/mach-vexpress/v2m.c b/arch/arm/mach-vexpress/v2m.c
> index 915683cb67..16b42c10e0 100644
> --- a/arch/arm/mach-vexpress/v2m.c
> +++ b/arch/arm/mach-vexpress/v2m.c
> @@ -476,6 +476,7 @@ static const char * const v2m_dt_match[] __initconst = {
>  DT_MACHINE_START(VEXPRESS_DT, "ARM-Versatile Express")
>  	.dt_compat	= v2m_dt_match,
>  	.smp		= smp_ops(vexpress_smp_ops),
> +	.smp_init	= smp_init_ops(vexpress_smp_init_ops),
>  	.map_io		= v2m_dt_map_io,
>  	.init_early	= v2m_dt_init_early,
>  	.init_irq	= irqchip_init,
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel




From khilman at linaro.org  Tue Apr  9 13:36:26 2013
From: khilman at linaro.org (Kevin Hilman)
Date: Tue, 09 Apr 2013 10:36:26 -0700
Subject: [GIT PULL 2/5] omap pm clean-up for v3.10 merge window
In-Reply-To: <20130409165633.GN10155@atomide.com> (Tony Lindgren's message of
 "Tue, 9 Apr 2013 09:56:33 -0700")
References: <0MarPy-1U9XGk2D8s-00Ks1o@mx.kundenserver.de>
 <201304091652.28385.arnd@arndb.de> <87vc7virqz.fsf@linaro.org>
 <20130409165633.GN10155@atomide.com>
Message-ID: <874nffip2d.fsf@linaro.org>

Tony Lindgren <tony at atomide.com> writes:

> * Kevin Hilman <khilman at linaro.org> [130409 09:43]:
>> Arnd Bergmann <arnd at arndb.de> writes:
>> 
>> > On Tuesday 09 April 2013, Tony Lindgren wrote:
>> >> The following changes since commit 07961ac7c0ee8b546658717034fe692fd12eefa9:
>> >> 
>> >>   Linux 3.9-rc5 (2013-03-31 15:12:43 -0700)
>> >> 
>> >> are available in the git repository at:
>> >> 
>> >>   git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.10/cleanup-pm-signed
>> >> 
>> >> for you to fetch changes up to ca8cdff548da76da01f3783548ceb917139a5ddc:
>> >> 
>> >>   Merge tag 'omap-pm-v3.10/cleanup/cpuidle' of
>> >> git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm
>> >> into omap-for-v3.10/cleanup-pm (2013-04-08 09:51:00 -0700)
>> >> 
>> >> ----------------------------------------------------------------
>> >> 
>> >> PM cleanup to prepare for omap5 PM via Kevin Hilman <khilman at linaro.org>:
>> >> 
>> >> OMAP3/4 CPUidle cleanups for v3.10
>> >
>> > Adding Daniel and Rafael to Cc.
>> >
>> > Is this series coordinated with the other cpuidle changes? Please tell me if this
>> > is good to go into arm-soc.
>> 
>> Hmm, looks like it's not ready.  There are some minor conflicts with
>> what Rafael has queued up from Daniel.
>> 
>> I will work this out with Daniel to figure out how we should proceed.
>
> OK it seems that this branch can also be queued by Rafael after
> updating it if there's a dependency. So far it's not conflicting
> with anything else we have queued up for arm soc tree.

Right, I just did a test rebase onto the relevant commit in Rafael
linux-next branch, and fixed up all the conflicts[1].

If Rafael agrees, it's fine with me if it goes via him.

Rafael, the signed tag for the updated branch is below[1], based on the
commit in your linux-next branch where you merged the rest of the
CPUidle changes.  Let me know if you want a different base commit, or an
official pull request.

Kevin

[1] git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git tags/omap-pm-v3.10/cleanup/cpuidle-v2


From tony at atomide.com  Tue Apr  9 13:43:20 2013
From: tony at atomide.com (Tony Lindgren)
Date: Tue, 9 Apr 2013 10:43:20 -0700
Subject: [RFC][PATCH 1/2] ARM: OMAP4: clock: Add device tree support
 for AUXCLKs
In-Reply-To: <20130409164928.GL10155@atomide.com>
References: <1363703220-4777-1-git-send-email-rogerq@ti.com>
 <1363703220-4777-2-git-send-email-rogerq@ti.com>
 <20130403234242.GE10155@atomide.com> <515D2D30.3000306@ti.com>
 <20130404164137.GH10155@atomide.com> <515EA9E3.1010409@ti.com>
 <20130405155851.GA10155@atomide.com> <5163E589.1040809@ti.com>
 <20130409164928.GL10155@atomide.com>
Message-ID: <20130409174319.GP10155@atomide.com>

* Tony Lindgren <tony at atomide.com> [130409 09:54]:
> * Roger Quadros <rogerq at ti.com> [130409 03:00]:
> > On 04/05/2013 06:58 PM, Tony Lindgren wrote:
> > > 
> > > Can't you just use the clock name there to get it?
> > 
> > In device tree we don't pass around clock names. You can either get
> > a phandle or an index to the clock.
> > 
> > e.g. Documentation/devicetree/bindings/clock/imx31-clock.txt
> 
> Yes I understand that. But the driver/clock/omap driver can just
> remap the DT device initially so the board specific clock is
> found from the clock alias table. Basically initially a passthrough
> driver that can be enhanced to parse DT clock bindings and load
> data from /lib/firmware.

Actually probably the driver/clock/omap can even do even less
initially. There probably even no need to remap clocks there.

As long as the DT clock driver understands that a board specific
auxclk is specified in the DT it can just call clk_add_alias() so
the driver will get the right auxclk from cclock44xx_data.c.

Then other features can be added later on like to allocate a
clock entirely based on the binding etc.

Regards,

Tony 


From sergei.shtylyov at cogentembedded.com  Tue Apr  9 13:47:51 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Tue, 9 Apr 2013 21:47:51 +0400
Subject: [PATCH 1/2] ARM: shmobile: R8A7778: fix Ether device name
Message-ID: <201304092147.51621.sergei.shtylyov@cogentembedded.com>

While recasting the commit "ARM: shmobile: R8A7778: add Ether support", I made a
typo in the platform device's name: used underscore instead of hyphen. 

Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

---
The patch is atop of the 'renesas-next-20130410' tag of the 'renesas.git' tree.

 arch/arm/mach-shmobile/setup-r8a7778.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: renesas/arch/arm/mach-shmobile/setup-r8a7778.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/setup-r8a7778.c
+++ renesas/arch/arm/mach-shmobile/setup-r8a7778.c
@@ -96,7 +96,7 @@ static struct resource ether_resources[]
 
 void __init r8a7778_add_ether_device(struct sh_eth_plat_data *pdata)
 {
-	platform_device_register_resndata(&platform_bus, "sh_eth", -1,
+	platform_device_register_resndata(&platform_bus, "sh-eth", -1,
 					  ether_resources,
 					  ARRAY_SIZE(ether_resources),
 					  pdata, sizeof(*pdata));


From sergei.shtylyov at cogentembedded.com  Tue Apr  9 13:48:59 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Tue, 9 Apr 2013 21:48:59 +0400
Subject: [PATCH 2/2] ARM: shmobile: R8A7779: fix Ether device name
Message-ID: <201304092149.00465.sergei.shtylyov@cogentembedded.com>

While recasting the commit "ARM: shmobile: R8A7779: add Ether support", I made a
typo in the platform device's name: used underscore instead of hyphen. 

Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

---
The patch is atop of the 'renesas-next-20130410' tag of the 'renesas.git' tree.

 arch/arm/mach-shmobile/setup-r8a7779.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: renesas/arch/arm/mach-shmobile/setup-r8a7779.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/setup-r8a7779.c
+++ renesas/arch/arm/mach-shmobile/setup-r8a7779.c
@@ -443,7 +443,7 @@ void __init r8a7779_add_standard_devices
 
 void __init r8a7779_add_ether_device(struct sh_eth_plat_data *pdata)
 {
-	platform_device_register_resndata(&platform_bus, "sh_eth", -1,
+	platform_device_register_resndata(&platform_bus, "sh-eth", -1,
 					  ether_resources,
 					  ARRAY_SIZE(ether_resources),
 					  pdata, sizeof(*pdata));


From schwab at linux-m68k.org  Tue Apr  9 13:57:00 2013
From: schwab at linux-m68k.org (Andreas Schwab)
Date: Tue, 09 Apr 2013 19:57:00 +0200
Subject: [PATCH] kbuild: generate generic headers before recursing into scripts
In-Reply-To: <CA+V-a8srtwdf1H2JQwbkyMFhXopPEA90RM8Hy+UunM6Mm7-d1w@mail.gmail.com>
 (Prabhakar Lad's message of "Tue, 9 Apr 2013 17:44:47 +0530")
References: <CA+V-a8vYsBLVH-3Bm35Sv9K9ZMTcMB4_P_V3kBjyuEKDozPi5w@mail.gmail.com>
 <1363949290.3528.37.camel@linaro1.home> <m2ip48d62f.fsf@igel.home>
 <CA+V-a8srtwdf1H2JQwbkyMFhXopPEA90RM8Hy+UunM6Mm7-d1w@mail.gmail.com>
Message-ID: <m2k3ob1tar.fsf_-_@igel.home>

The headers are now needed inside scripts/mod since 6543bec
("mod/file2alias: make modalias generation safe for cross compiling").

Signed-off-by: Andreas Schwab <schwab at linux-m68k.org>
---
Prabhakar Lad <prabhakar.csengg at gmail.com> writes:

> Whats the status of it ?

I think it has sufficiently been tested by now.

Andreas.
---
 Makefile | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index 6db672b..11157bd 100644
--- a/Makefile
+++ b/Makefile
@@ -513,7 +513,8 @@ ifeq ($(KBUILD_EXTMOD),)
 # Carefully list dependencies so we do not try to build scripts twice
 # in parallel
 PHONY += scripts
-scripts: scripts_basic include/config/auto.conf include/config/tristate.conf
+scripts: scripts_basic include/config/auto.conf include/config/tristate.conf \
+	 asm-generic
 	$(Q)$(MAKE) $(build)=$(@)
 
 # Objects we will link into vmlinux / subdirs we need to visit
-- 
1.8.2.1


-- 
Andreas Schwab, schwab at linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."


From hvaibhav at ti.com  Tue Apr  9 14:03:51 2013
From: hvaibhav at ti.com (Hiremath, Vaibhav)
Date: Tue, 9 Apr 2013 18:03:51 +0000
Subject: [GIT PULL] ARM: OMAP5: hwmod, prm/cm data files and updates for
 3.10
In-Reply-To: <20130405171052.GD10155@atomide.com>
References: <1363768852-18125-1-git-send-email-santosh.shilimkar@ti.com>
 <20130401170539.GK10155@atomide.com> <515BA76D.3000302@ti.com>
 <alpine.DEB.2.00.1304031146230.2616@utopia.booyaka.com>
 <515D6020.2030103@ti.com> <20130404165208.GI10155@atomide.com>
 <515DB110.9000503@ti.com> <515F00B8.3000501@ti.com>
 <20130405171052.GD10155@atomide.com>
Message-ID: <79CD15C6BA57404B839C016229A409A83EC49D42@DBDE01.ent.ti.com>


> -----Original Message-----
> From: linux-omap-owner at vger.kernel.org [mailto:linux-omap-
> owner at vger.kernel.org] On Behalf Of Tony Lindgren
> Sent: Friday, April 05, 2013 10:41 PM
> To: Shilimkar, Santosh
> Cc: Paul Walmsley; linux-omap at vger.kernel.org; linux-arm-
> kernel at lists.infradead.org; Kristo, Tero; Menon, Nishanth; Nayak,
> Rajendra; Valentin, Eduardo; Anna, Suman; Bedia, Vaibhav; Hiremath,
> Vaibhav
> Subject: Re: [GIT PULL] ARM: OMAP5: hwmod, prm/cm data files and
> updates for 3.10
> 
> * Santosh Shilimkar <santosh.shilimkar at ti.com> [130405 09:52]:
> > On Thursday 04 April 2013 10:27 PM, Santosh Shilimkar wrote:
> > > On Thursday 04 April 2013 10:22 PM, Tony Lindgren wrote:
> > >> * Santosh Shilimkar <santosh.shilimkar at ti.com> [130404 04:15]:
> > [..]
> >
> > >> Can't we already trim the am33xx hwmod data after your patches for
> > >> v3.10 as am33xx is already DT only? Unfortunately we cannot create
> > >> negative diffstat in other ways for v3.10 merge window as we
> cannot
> > >> make omap4 DT only just quite yet.
> > >>
> > > Yes we can and I can take a stab it tomorrow. The only thing is I
> > > might need some support for testing but thats manageable. Will
> > > take a stab at it tomorrow and if everything goes well, post a
> > > patch for smae.
> > >
> > Patch for the AM33XX to trim is end of the email. Thanks to
> > Sricharan and Pekon for patch and testing. Looping both
> > Vaibhav's if they have any objection on the patch.
> >
> > Regards,
> > Santosh
> >
> > From b95dd33fe59b8e77727eb3b1717d763bbf9a2893 Mon Sep 17 00:00:00
> 2001
> > From: Sricharan R <r.sricharan at ti.com>
> > Date: Fri, 5 Apr 2013 20:39:12 +0530
> > Subject: [PATCH] ARM: AM33XX: hwmod data: Clean up the data file
> >
> > - The IO resource information like dma request lines, irq number and
> > ocp address space can be populated via dt blob. So such data can be
> stripped
> > from SOC hwmod data file.
> >
> > - The devices like adc, mailbox, gpmc which are missing the device
> > tree bindings, hwmod data is not added since AM33XX is DT only build.
> > When such devices add the dt bindings, respective hwmod data can be
> > added along with it.
> >
> > - The hwmod like firewall etc which are not useful are also dropped.
> >
> > This gets us around ~2000 loc of negative diff. Patch is boot tested
> on
> > AM335X EVM.
> 
> Great, that's a nice reduction :) Considering am33xx is DT only, it
> should be safe.. But can the am33xx guys please test and ack it?
> 
I am reviewing the patch-diff and will give my comment as soon as possible.

Thanks,
Vaibhav


From darrick.wong at oracle.com  Tue Apr  9 14:03:52 2013
From: darrick.wong at oracle.com (Darrick J. Wong)
Date: Tue, 9 Apr 2013 11:03:52 -0700
Subject: [PATCH v3] mm: Make snapshotting pages for stable writes a
 per-bio operation
In-Reply-To: <20130403144244.GC14667@quack.suse.cz>
References: <20130313194429.GE5313@blackbox.djwong.org>
 <20130313210216.GA7754@quack.suse.cz>
 <20130314224243.GI5313@blackbox.djwong.org>
 <20130315100105.GA4889@quack.suse.cz>
 <20130315232816.GN5313@blackbox.djwong.org>
 <20130318174134.GB7852@quack.suse.cz>
 <20130318230259.GP5313@blackbox.djwong.org>
 <20130402170143.GA8910@blackbox.djwong.org>
 <20130403142019.GC5811@suse.de>
 <20130403144244.GC14667@quack.suse.cz>
Message-ID: <20130409180352.GA8907@blackbox.djwong.org>

On Wed, Apr 03, 2013 at 04:42:44PM +0200, Jan Kara wrote:
> On Wed 03-04-13 15:20:19, Mel Gorman wrote:
> > On Tue, Apr 02, 2013 at 10:01:43AM -0700, Darrick J. Wong wrote:
> > > Hi,
> > > 
> > > A couple of weeks have gone by without further comments about this patch.
> > > 
> > > Are you interested in the minor cleanups and added comments, or is the v2 patch
> > > in -next good enough?
> > > 
> > > Apparently Mel Gorman's interested in this patchset too.  Mel: Most of stable
> > > pages part 2 are already in upstream for 3.9... except this piece.  Are you
> > > interested in having this piece in 3.9 also?  Or is 3.10 good enough for
> > > everyone?
> > > 
> > 
> > My understanding is that it only affects ARM and DEBUG_VM so there is a
> > relatively small chance of this generating spurious bug reports.  However,
> > 3.9 is still far enough away that I see no good reason to delay this patch
> > until 3.10 either.
>   No, actually with direct IO, anything that needs stable pages is going to
> blow up quickly because pages attached to bio needn't be from page cache. So
> I think it should better make it into 3.9.

Hmm.  The previous version of this patch has been hanging around in -next for a
few weeks without problems (afaik).  With just a raw 3.9-rc[56] I haven't been
able to produce a failed checksum or kernel crash when running with O_DIRECT,
either with the write-after-checksum reproducer or even a simple dd
oflag=direct.  But maybe I've gotten lucky on x86?

So... Andrew: Would you like to pick up the patch with more descriptive
comments?  And, is it too late to push it for 3.9?  Jan seems to think we might
have a bug (though I haven't encountered it).

I'll resend the patch just in case it got eaten.

--D
> 
> 									Honza
> -- 
> Jan Kara <jack at suse.cz>
> SUSE Labs, CR


From darrick.wong at oracle.com  Tue Apr  9 14:06:17 2013
From: darrick.wong at oracle.com (Darrick J. Wong)
Date: Tue, 9 Apr 2013 11:06:17 -0700
Subject: [PATCH v3] [RESEND] mm: Make snapshotting pages for stable writes a
 per-bio operation
Message-ID: <20130409180617.GB8907@blackbox.djwong.org>

Walking a bio's page mappings has proved problematic, so create a new bio flag
to indicate that a bio's data needs to be snapshotted in order to guarantee
stable pages during writeback.  Next, for the one user (ext3/jbd) of
snapshotting, hook all the places where writes can be initiated without
PG_writeback set, and set BIO_SNAP_STABLE there.  We must also flag journal
"metadata" bios for stable writeout, since file data can be written through the
journal.  Finally, the MS_SNAP_STABLE mount flag (only used by ext3) is now
superfluous, so get rid of it.

v3: Improve the documentation in jbd for why we're doing this, and clean up
some code.

Signed-off-by: Darrick J. Wong <darrick.wong at oracle.com>

[darrick.wong at oracle.com: Fold in a couple of small cleanups from akpm]
Signed-off-by: Andrew Morton <akpm at linux-foundation.org>
---
 fs/buffer.c                 |    9 ++++++++-
 fs/ext3/super.c             |    1 -
 fs/jbd/commit.c             |   25 ++++++++++++++++++++++---
 include/linux/blk_types.h   |    3 ++-
 include/linux/buffer_head.h |    1 +
 include/uapi/linux/fs.h     |    1 -
 mm/bounce.c                 |   21 +--------------------
 mm/page-writeback.c         |    4 ----
 8 files changed, 34 insertions(+), 31 deletions(-)

diff --git a/fs/buffer.c b/fs/buffer.c
index b4dcb34..71578d6 100644
--- a/fs/buffer.c
+++ b/fs/buffer.c
@@ -2949,7 +2949,7 @@ static void guard_bh_eod(int rw, struct bio *bio, struct buffer_head *bh)
 	}
 }
 
-int submit_bh(int rw, struct buffer_head * bh)
+int _submit_bh(int rw, struct buffer_head *bh, unsigned long bio_flags)
 {
 	struct bio *bio;
 	int ret = 0;
@@ -2984,6 +2984,7 @@ int submit_bh(int rw, struct buffer_head * bh)
 
 	bio->bi_end_io = end_bio_bh_io_sync;
 	bio->bi_private = bh;
+	bio->bi_flags |= bio_flags;
 
 	/* Take care of bh's that straddle the end of the device */
 	guard_bh_eod(rw, bio, bh);
@@ -2997,6 +2998,12 @@ int submit_bh(int rw, struct buffer_head * bh)
 	bio_put(bio);
 	return ret;
 }
+EXPORT_SYMBOL_GPL(_submit_bh);
+
+int submit_bh(int rw, struct buffer_head *bh)
+{
+	return _submit_bh(rw, bh, 0);
+}
 EXPORT_SYMBOL(submit_bh);
 
 /**
diff --git a/fs/ext3/super.c b/fs/ext3/super.c
index fb5120a..3dc48cc 100644
--- a/fs/ext3/super.c
+++ b/fs/ext3/super.c
@@ -2067,7 +2067,6 @@ static int ext3_fill_super (struct super_block *sb, void *data, int silent)
 		test_opt(sb,DATA_FLAGS) == EXT3_MOUNT_JOURNAL_DATA ? "journal":
 		test_opt(sb,DATA_FLAGS) == EXT3_MOUNT_ORDERED_DATA ? "ordered":
 		"writeback");
-	sb->s_flags |= MS_SNAP_STABLE;
 
 	return 0;
 
diff --git a/fs/jbd/commit.c b/fs/jbd/commit.c
index 86b39b1..11bb11f 100644
--- a/fs/jbd/commit.c
+++ b/fs/jbd/commit.c
@@ -162,8 +162,17 @@ static void journal_do_submit_data(struct buffer_head **wbuf, int bufs,
 
 	for (i = 0; i < bufs; i++) {
 		wbuf[i]->b_end_io = end_buffer_write_sync;
-		/* We use-up our safety reference in submit_bh() */
-		submit_bh(write_op, wbuf[i]);
+		/*
+		 * Here we write back pagecache data that may be mmaped. Since
+		 * we cannot afford to clean the page and set PageWriteback
+		 * here due to lock ordering (page lock ranks above transaction
+		 * start), the data can change while IO is in flight. Tell the
+		 * block layer it should bounce the bio pages if stable data
+		 * during write is required.
+		 *
+		 * We use up our safety reference in submit_bh().
+		 */
+		_submit_bh(write_op, wbuf[i], 1 << BIO_SNAP_STABLE);
 	}
 }
 
@@ -667,7 +676,17 @@ start_journal_io:
 				clear_buffer_dirty(bh);
 				set_buffer_uptodate(bh);
 				bh->b_end_io = journal_end_buffer_io_sync;
-				submit_bh(write_op, bh);
+				/*
+				 * In data=journal mode, here we can end up
+				 * writing pagecache data that might be
+				 * mmapped. Since we can't afford to clean the
+				 * page and set PageWriteback (see the comment
+				 * near the other use of _submit_bh()), the
+				 * data can change while the write is in
+				 * flight.  Tell the block layer to bounce the
+				 * bio pages if stable pages are required.
+				 */
+				_submit_bh(write_op, bh, 1 << BIO_SNAP_STABLE);
 			}
 			cond_resched();
 
diff --git a/include/linux/blk_types.h b/include/linux/blk_types.h
index cdf1119..22990cf 100644
--- a/include/linux/blk_types.h
+++ b/include/linux/blk_types.h
@@ -111,12 +111,13 @@ struct bio {
 #define BIO_FS_INTEGRITY 9	/* fs owns integrity data, not block layer */
 #define BIO_QUIET	10	/* Make BIO Quiet */
 #define BIO_MAPPED_INTEGRITY 11/* integrity metadata has been remapped */
+#define BIO_SNAP_STABLE	12	/* bio data must be snapshotted during write */
 
 /*
  * Flags starting here get preserved by bio_reset() - this includes
  * BIO_POOL_IDX()
  */
-#define BIO_RESET_BITS	12
+#define BIO_RESET_BITS	13
 
 #define bio_flagged(bio, flag)	((bio)->bi_flags & (1 << (flag)))
 
diff --git a/include/linux/buffer_head.h b/include/linux/buffer_head.h
index 5afc4f9..4c16c4a 100644
--- a/include/linux/buffer_head.h
+++ b/include/linux/buffer_head.h
@@ -181,6 +181,7 @@ void ll_rw_block(int, int, struct buffer_head * bh[]);
 int sync_dirty_buffer(struct buffer_head *bh);
 int __sync_dirty_buffer(struct buffer_head *bh, int rw);
 void write_dirty_buffer(struct buffer_head *bh, int rw);
+int _submit_bh(int rw, struct buffer_head *bh, unsigned long bio_flags);
 int submit_bh(int, struct buffer_head *);
 void write_boundary_block(struct block_device *bdev,
 			sector_t bblock, unsigned blocksize);
diff --git a/include/uapi/linux/fs.h b/include/uapi/linux/fs.h
index c7fc1e6..a4ed56c 100644
--- a/include/uapi/linux/fs.h
+++ b/include/uapi/linux/fs.h
@@ -88,7 +88,6 @@ struct inodes_stat_t {
 #define MS_STRICTATIME	(1<<24) /* Always perform atime updates */
 
 /* These sb flags are internal to the kernel */
-#define MS_SNAP_STABLE	(1<<27) /* Snapshot pages during writeback, if needed */
 #define MS_NOSEC	(1<<28)
 #define MS_BORN		(1<<29)
 #define MS_ACTIVE	(1<<30)
diff --git a/mm/bounce.c b/mm/bounce.c
index 5f89017..a5c2ec3 100644
--- a/mm/bounce.c
+++ b/mm/bounce.c
@@ -181,32 +181,13 @@ static void bounce_end_io_read_isa(struct bio *bio, int err)
 #ifdef CONFIG_NEED_BOUNCE_POOL
 static int must_snapshot_stable_pages(struct request_queue *q, struct bio *bio)
 {
-	struct page *page;
-	struct backing_dev_info *bdi;
-	struct address_space *mapping;
-	struct bio_vec *from;
-	int i;
-
 	if (bio_data_dir(bio) != WRITE)
 		return 0;
 
 	if (!bdi_cap_stable_pages_required(&q->backing_dev_info))
 		return 0;
 
-	/*
-	 * Based on the first page that has a valid mapping, decide whether or
-	 * not we have to employ bounce buffering to guarantee stable pages.
-	 */
-	bio_for_each_segment(from, bio, i) {
-		page = from->bv_page;
-		mapping = page_mapping(page);
-		if (!mapping)
-			continue;
-		bdi = mapping->backing_dev_info;
-		return mapping->host->i_sb->s_flags & MS_SNAP_STABLE;
-	}
-
-	return 0;
+	return test_bit(BIO_SNAP_STABLE, &bio->bi_flags);
 }
 #else
 static int must_snapshot_stable_pages(struct request_queue *q, struct bio *bio)
diff --git a/mm/page-writeback.c b/mm/page-writeback.c
index efe6814..4514ad7 100644
--- a/mm/page-writeback.c
+++ b/mm/page-writeback.c
@@ -2311,10 +2311,6 @@ void wait_for_stable_page(struct page *page)
 
 	if (!bdi_cap_stable_pages_required(bdi))
 		return;
-#ifdef CONFIG_NEED_BOUNCE_POOL
-	if (mapping->host->i_sb->s_flags & MS_SNAP_STABLE)
-		return;
-#endif /* CONFIG_NEED_BOUNCE_POOL */
 
 	wait_on_page_writeback(page);
 }


From cdall at cs.columbia.edu  Tue Apr  9 14:28:07 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Tue, 9 Apr 2013 11:28:07 -0700
Subject: [PATCH v2 6/7] ARM: KVM: switch to a dual-step HYP init code
In-Reply-To: <5163F0B0.2000400@arm.com>
References: <1365435403-29265-1-git-send-email-marc.zyngier@arm.com>
 <1365435403-29265-7-git-send-email-marc.zyngier@arm.com>
 <20130409091813.GC24090@mudshark.cambridge.arm.com>
 <5163F0B0.2000400@arm.com>
Message-ID: <CAEDV+gK5P+8TEaQoqLoR6a2JWV+kP2tHwShK25tf+xD4k26OdA@mail.gmail.com>

On Tue, Apr 9, 2013 at 3:42 AM, Marc Zyngier <marc.zyngier at arm.com> wrote:
> On 09/04/13 10:18, Will Deacon wrote:
>> On Mon, Apr 08, 2013 at 04:36:42PM +0100, Marc Zyngier wrote:
>>> Our HYP init code suffers from two major design issues:
>>> - it cannot support CPU hotplug, as we tear down the idmap very early
>>> - it cannot perform a TLB invalidation when switching from init to
>>>   runtime mappings, as pages are manipulated from PL1 exclusively
>>>
>>> The hotplug problem mandates that we keep two sets of page tables
>>> (boot and runtime). The TLB problem mandates that we're able to
>>> transition from one PGD to another while in HYP, invalidating the TLBs
>>> in the process.
>>>
>>> To be able to do this, we need to share a page between the two page
>>> tables. A page that will have the same VA in both configurations. All we
>>> need is a VA that has the following properties:
>>> - This VA can't be used to represent a kernel mapping.
>>> - This VA will not conflict with the physical address of the kernel text
>>>
>>> The vectors page seems to satisfy this requirement:
>>> - The kernel never maps anything else there
>>> - The kernel text being copied at the beginning of the physical memory,
>>>   it is unlikely to use the last 64kB (I doubt we'll ever support KVM
>>>   on a system with something like 4MB of RAM, but patches are very
>>>   welcome).
>>>
>>> Let's call this VA the trampoline VA.
>>>
>>> Now, we map our init page at 3 locations:
>>> - idmap in the boot pgd
>>> - trampoline VA in the boot pgd
>>> - trampoline VA in the runtime pgd
>>>
>>> The init scenario is now the following:
>>> - We jump in HYP with four parameters: boot HYP pgd, runtime HYP pgd,
>>>   runtime stack, runtime vectors
>>> - Enable the MMU with the boot pgd
>>> - Jump to a target into the trampoline page (remember, this is the same
>>>   physical page!)
>>> - Now switch to the runtime pgd (same VA, and still the same physical
>>>   page!)
>>> - Invalidate TLBs
>>> - Set stack and vectors
>>> - Profit! (or eret, if you only care about the code).
>>>
>>> Note that we keep the boot mapping permanently (it is not strictly an
>>> idmap anymore) to allow for CPU hotplug in later patches.
>>>
>>> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
>>> ---
>>>  arch/arm/include/asm/kvm_host.h |  18 ++++--
>>>  arch/arm/include/asm/kvm_mmu.h  |  24 +++++++-
>>>  arch/arm/kvm/arm.c              |  11 ++--
>>>  arch/arm/kvm/init.S             |  44 +++++++++++++-
>>>  arch/arm/kvm/mmu.c              | 129 ++++++++++++++++++++++++++++------------
>>>  5 files changed, 173 insertions(+), 53 deletions(-)
>>>
>>> diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
>>> index a856cc2..9fe22ee 100644
>>> --- a/arch/arm/include/asm/kvm_host.h
>>> +++ b/arch/arm/include/asm/kvm_host.h
>>> @@ -190,22 +190,32 @@ int kvm_arm_coproc_set_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *);
>>>  int handle_exit(struct kvm_vcpu *vcpu, struct kvm_run *run,
>>>                 int exception_index);
>>>
>>> -static inline void __cpu_init_hyp_mode(unsigned long long pgd_ptr,
>>> +static inline void __cpu_init_hyp_mode(unsigned long long boot_pgd_ptr,
>>> +                                      unsigned long long pgd_ptr,
>>>                                        unsigned long hyp_stack_ptr,
>>>                                        unsigned long vector_ptr)
>>>  {
>>>         unsigned long pgd_low, pgd_high;
>>>
>>> -       pgd_low = (pgd_ptr & ((1ULL << 32) - 1));
>>> -       pgd_high = (pgd_ptr >> 32ULL);
>>> +       pgd_low = (boot_pgd_ptr & ((1ULL << 32) - 1));
>>> +       pgd_high = (boot_pgd_ptr >> 32ULL);
>>>
>>>         /*
>>>          * Call initialization code, and switch to the full blown
>>>          * HYP code. The init code doesn't need to preserve these registers as
>>> -        * r1-r3 and r12 are already callee save according to the AAPCS.
>>> +        * r1-r3 and r12 are already callee saved according to the AAPCS.
>>>          * Note that we slightly misuse the prototype by casing the pgd_low to
>>>          * a void *.
>>> +        *
>>> +        * We don't have enough registers to perform the full init in one go.
>>> +        * Install the boot PGD first, and then install the runtime PGD,
>>> +        * stack pointer and vectors.
>>>          */
>>> +       kvm_call_hyp((void *)pgd_low, pgd_high, 0, 0);
>>> +
>>> +       pgd_low = (pgd_ptr & ((1ULL << 32) - 1));
>>> +       pgd_high = (pgd_ptr >> 32ULL);
>>
>> It might be worth macro-ising the low/high extraction operations now that
>> you're using them twice. Hell, you could even make them big-endian clean!
>
> Now you're talking! ;-)
>
> I actually wonder if we could rearrange the code to let the compiler do
> the low/high split... Quickly looking through the PCS, it looks like
> this would actually work.
>
>>>         kvm_call_hyp((void *)pgd_low, pgd_high, hyp_stack_ptr, vector_ptr);
>>>  }
>>>
>>> diff --git a/arch/arm/include/asm/kvm_mmu.h b/arch/arm/include/asm/kvm_mmu.h
>>> index 92eb20d..24b767a 100644
>>> --- a/arch/arm/include/asm/kvm_mmu.h
>>> +++ b/arch/arm/include/asm/kvm_mmu.h
>>> @@ -19,17 +19,29 @@
>>>  #ifndef __ARM_KVM_MMU_H__
>>>  #define __ARM_KVM_MMU_H__
>>>
>>> -#include <asm/cacheflush.h>
>>> -#include <asm/pgalloc.h>
>>> +#include <asm/memory.h>
>>> +#include <asm/page.h>
>>>
>>>  /*
>>>   * We directly use the kernel VA for the HYP, as we can directly share
>>>   * the mapping (HTTBR "covers" TTBR1).
>>>   */
>>> -#define HYP_PAGE_OFFSET_MASK   (~0UL)
>>> +#define HYP_PAGE_OFFSET_MASK   UL(~0)
>>>  #define HYP_PAGE_OFFSET                PAGE_OFFSET
>>>  #define KERN_TO_HYP(kva)       (kva)
>>>
>>> +/*
>>> + * Our virtual mapping for the boot-time MMU-enable code. Must be
>>> + * shared across all the page-tables. Conveniently, we use the vectors
>>> + * page, where no kernel data will ever be shared with HYP.
>>> + */
>>> +#define TRAMPOLINE_VA          UL(CONFIG_VECTORS_BASE)
>>> +
>>> +#ifndef __ASSEMBLY__
>>> +
>>> +#include <asm/cacheflush.h>
>>> +#include <asm/pgalloc.h>
>>> +
>>>  int create_hyp_mappings(void *from, void *to);
>>>  int create_hyp_io_mappings(void *from, void *to, phys_addr_t);
>>>  void free_hyp_pgds(void);
>>> @@ -44,6 +56,8 @@ int kvm_handle_guest_abort(struct kvm_vcpu *vcpu, struct kvm_run *run);
>>>  void kvm_mmu_free_memory_caches(struct kvm_vcpu *vcpu);
>>>
>>>  phys_addr_t kvm_mmu_get_httbr(void);
>>> +phys_addr_t kvm_mmu_get_boot_httbr(void);
>>> +phys_addr_t kvm_get_idmap_vector(void);
>>>  int kvm_mmu_init(void);
>>>  void kvm_clear_hyp_idmap(void);
>>>
>>> @@ -113,4 +127,8 @@ static inline void coherent_icache_guest_page(struct kvm *kvm, gfn_t gfn)
>>>         }
>>>  }
>>>
>>> +#define kvm_flush_dcache_to_poc(a,l)   __cpuc_flush_dcache_area((a), (l))
>>> +
>>> +#endif /* !__ASSEMBLY__ */
>>> +
>>>  #endif /* __ARM_KVM_MMU_H__ */
>>> diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
>>> index 8d44ef4..9010a12 100644
>>> --- a/arch/arm/kvm/arm.c
>>> +++ b/arch/arm/kvm/arm.c
>>> @@ -796,20 +796,22 @@ long kvm_arch_vm_ioctl(struct file *filp,
>>>
>>>  static void cpu_init_hyp_mode(void *vector)
>>>  {
>>> +       unsigned long long boot_pgd_ptr;
>>>         unsigned long long pgd_ptr;
>>>         unsigned long hyp_stack_ptr;
>>>         unsigned long stack_page;
>>>         unsigned long vector_ptr;
>>>
>>>         /* Switch from the HYP stub to our own HYP init vector */
>>> -       __hyp_set_vectors((unsigned long)vector);
>>> +       __hyp_set_vectors(kvm_get_idmap_vector());
>>>
>>> +       boot_pgd_ptr = (unsigned long long)kvm_mmu_get_boot_httbr();
>>>         pgd_ptr = (unsigned long long)kvm_mmu_get_httbr();
>>
>> Strictly speaking, could you avoid using two sets of tables for this? That
>> is, have code in the trampoline page which remaps the rest of the address
>> space using the current tables? Not saying it's feasible, just interested.
>
> If you do that, you loose the ability to bring in a hotplugged CPU, as
> your idmap and your runtime page tables may have conflicting
> translations. Or am I missing something obvious?
>

I don't think you're missing anything, there are two requirements:
idmap, and context switch, and as long as we keep the same VA in Hyp
as in kernel mode (modulo offset for arm64) I don't think there's any
way around having those two tables.

>>>         stack_page = __get_cpu_var(kvm_arm_hyp_stack_page);
>>>         hyp_stack_ptr = stack_page + PAGE_SIZE;
>>>         vector_ptr = (unsigned long)__kvm_hyp_vector;
>>>
>>> -       __cpu_init_hyp_mode(pgd_ptr, hyp_stack_ptr, vector_ptr);
>>> +       __cpu_init_hyp_mode(boot_pgd_ptr, pgd_ptr, hyp_stack_ptr, vector_ptr);
>>>  }
>>>
>>>  /**
>>> @@ -863,11 +865,6 @@ static int init_hyp_mode(void)
>>>         }
>>>
>>>         /*
>>> -        * Unmap the identity mapping
>>> -        */
>>> -       kvm_clear_hyp_idmap();
>>> -
>>> -       /*
>>>          * Map the Hyp-code called directly from the host
>>>          */
>>>         err = create_hyp_mappings(__kvm_hyp_code_start, __kvm_hyp_code_end);
>>> diff --git a/arch/arm/kvm/init.S b/arch/arm/kvm/init.S
>>> index 9f37a79..0ca054f 100644
>>> --- a/arch/arm/kvm/init.S
>>> +++ b/arch/arm/kvm/init.S
>>> @@ -21,6 +21,7 @@
>>>  #include <asm/asm-offsets.h>
>>>  #include <asm/kvm_asm.h>
>>>  #include <asm/kvm_arm.h>
>>> +#include <asm/kvm_mmu.h>
>>>
>>>  /********************************************************************
>>>   * Hypervisor initialization
>>> @@ -28,6 +29,25 @@
>>>   *       r0,r1 = Hypervisor pgd pointer
>>>   *       r2 = top of Hyp stack (kernel VA)
>>>   *       r3 = pointer to hyp vectors
>>> + *
>>> + * The init scenario is:
>>> + * - We jump in HYP with four parameters: boot HYP pgd, runtime HYP pgd,
>>> + *   runtime stack, runtime vectors
>>> + * - Enable the MMU with the boot pgd
>>> + * - Jump to a target into the trampoline page (remember, this is the same
>>> + *   physical page!)
>>> + * - Now switch to the runtime pgd (same VA, and still the same physical
>>> + *   page!)
>>> + * - Invalidate TLBs
>>> + * - Set stack and vectors
>>> + * - Profit! (or eret, if you only care about the code).
>>> + *
>>> + * As we only have four registers available to pass parameters (and we
>>> + * need six), we split the init in two phases:
>>> + * - Phase 1: r0,r1 contain the boot PGD, r2 = 0, r3 = 0.
>>> + *   Provides the basic HYP init, and enable the MMU.
>>> + * - Phase 2: r0,r1 contain the runtime PGD, r2 = ToS, r3 = vectors
>>> + *   Switches to the runtime PGD, set stack and vectors.
>>>   */
>>>
>>>         .text
>>> @@ -47,6 +67,9 @@ __kvm_hyp_init:
>>>         W(b)    .
>>>
>>>  __do_hyp_init:
>>> +       cmp     r2, #0                  @ We have a SP?
>>> +       bne     phase2                  @ Yes, second stage init
>>> +
>>>         @ Set the HTTBR to point to the hypervisor PGD pointer passed
>>>         mcrr    p15, 4, r0, r1, c2
>>>
>>> @@ -96,14 +119,31 @@ __do_hyp_init:
>>>         orr     r0, r0, r1
>>>         isb
>>>         mcr     p15, 4, r0, c1, c0, 0   @ HSCR
>>> -       isb
>>>
>>> -       @ Set stack pointer and return to the kernel
>>> +       @ End of init phase-1
>>> +       eret
>>> +
>>> +phase2:
>>> +       @ Set stack pointer
>>>         mov     sp, r2
>>>
>>>         @ Set HVBAR to point to the HYP vectors
>>>         mcr     p15, 4, r3, c12, c0, 0  @ HVBAR
>>>
>>> +       @ Jump to the trampoline page
>>> +       ldr     r2, =TRAMPOLINE_VA
>>> +       adr     r3, target
>>> +       bfi     r2, r3, #0, #PAGE_SHIFT
>>> +       mov     pc, r2
>>> +
>>> +target:        @ We're now in the trampoline code, switch page tables
>>> +       mcrr    p15, 4, r0, r1, c2
>>> +       isb
>>> +
>>> +       @ Invalidate the old TLBs
>>> +       mcr     p15, 4, r0, c8, c7, 0   @ TLBIALLH
>>> +       dsb
>>> +
>>>         eret
>>>
>>>         .ltorg
>>> diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
>>> index c4236e4..b20eff2 100644
>>> --- a/arch/arm/kvm/mmu.c
>>> +++ b/arch/arm/kvm/mmu.c
>>> @@ -32,9 +32,15 @@
>>>
>>>  extern char  __hyp_idmap_text_start[], __hyp_idmap_text_end[];
>>>
>>> +static pgd_t *boot_hyp_pgd;
>>>  static pgd_t *hyp_pgd;
>>>  static DEFINE_MUTEX(kvm_hyp_pgd_mutex);
>>>
>>> +static void *init_bounce_page;
>>> +static unsigned long hyp_idmap_start;
>>> +static unsigned long hyp_idmap_end;
>>> +static phys_addr_t hyp_idmap_vector;
>>> +
>>>  static void kvm_tlb_flush_vmid_ipa(struct kvm *kvm, phys_addr_t ipa)
>>>  {
>>>         kvm_call_hyp(__kvm_tlb_flush_vmid_ipa, kvm, ipa);
>>> @@ -108,9 +114,12 @@ static void free_hyp_pgd_entry(pgd_t *pgdp, unsigned long addr)
>>>  /**
>>>   * free_hyp_pgds - free Hyp-mode page tables
>>>   *
>>> - * Assumes hyp_pgd is a page table used strictly in Hyp-mode and therefore contains
>>> - * either mappings in the kernel memory area (above PAGE_OFFSET), or
>>> - * device mappings in the vmalloc range (from VMALLOC_START to VMALLOC_END).
>>> + * Assumes hyp_pgd is a page table used strictly in Hyp-mode and
>>> + * therefore contains either mappings in the kernel memory area (above
>>> + * PAGE_OFFSET), or device mappings in the vmalloc range (from
>>> + * VMALLOC_START to VMALLOC_END).
>>> + *
>>> + * boot_hyp_pgd should only map two pages for the init code.
>>>   */
>>>  void free_hyp_pgds(void)
>>>  {
>>> @@ -118,6 +127,12 @@ void free_hyp_pgds(void)
>>>
>>>         mutex_lock(&kvm_hyp_pgd_mutex);
>>>
>>> +       if (boot_hyp_pgd) {
>>> +               free_hyp_pgd_entry(boot_hyp_pgd, hyp_idmap_start);
>>> +               free_hyp_pgd_entry(boot_hyp_pgd, TRAMPOLINE_VA);
>>> +               kfree(boot_hyp_pgd);
>>> +       }
>>> +
>>>         if (hyp_pgd) {
>>>                 for (addr = PAGE_OFFSET; virt_addr_valid(addr); addr += PGDIR_SIZE)
>>>                         free_hyp_pgd_entry(hyp_pgd, KERN_TO_HYP(addr));
>>> @@ -126,6 +141,7 @@ void free_hyp_pgds(void)
>>>                 kfree(hyp_pgd);
>>>         }
>>>
>>> +       kfree(init_bounce_page);
>>>         mutex_unlock(&kvm_hyp_pgd_mutex);
>>>  }
>>>
>>> @@ -718,14 +734,62 @@ phys_addr_t kvm_mmu_get_httbr(void)
>>>         return virt_to_phys(hyp_pgd);
>>>  }
>>>
>>> +phys_addr_t kvm_mmu_get_boot_httbr(void)
>>> +{
>>> +       VM_BUG_ON(!virt_addr_valid(boot_hyp_pgd));
>>
>> Seems a bit OTT -- it's always going to be in lowmem.
>
> Indeed.
>
>>> +       return virt_to_phys(boot_hyp_pgd);
>>> +}
>>> +
>>> +phys_addr_t kvm_get_idmap_vector(void)
>>> +{
>>> +       return hyp_idmap_vector;
>>> +}
>>> +
>>>  int kvm_mmu_init(void)
>>>  {
>>> -       unsigned long hyp_idmap_start = virt_to_phys(__hyp_idmap_text_start);
>>> -       unsigned long hyp_idmap_end = virt_to_phys(__hyp_idmap_text_end);
>>>         int err;
>>>
>>> +       hyp_idmap_start = virt_to_phys(__hyp_idmap_text_start);
>>> +       hyp_idmap_end = virt_to_phys(__hyp_idmap_text_end);
>>> +       hyp_idmap_vector = virt_to_phys(__kvm_hyp_init);
>>> +
>>> +       if ((hyp_idmap_start ^ hyp_idmap_end) & PAGE_MASK) {
>>> +               /*
>>> +                * Our init code is crossing a page boundary. Allocate
>>> +                * a bounce page, copy the code over and use that.
>>> +                */
>>> +               size_t len = __hyp_idmap_text_end - __hyp_idmap_text_start;
>>> +               phys_addr_t phys_base;
>>> +
>>> +               init_bounce_page = kzalloc(PAGE_SIZE, GFP_KERNEL);
>>> +               if (!init_bounce_page) {
>>> +                       kvm_err("Couldn't allocate HYP init bounce page\n");
>>> +                       err = -ENOMEM;
>>> +                       goto out;
>>> +               }
>>
>> Given that you don't really need a lowmem page for the bounce page, this
>> might be better expressed using alloc_page and kmap for the memcpy.
>
> I'm a bit dubious about that. We have to make sure that the memory is
> within the 4GB range, and the only flag I can spot for alloc_page is
> GFP_DMA32, which is not exactly what we want, even if it may work.
>
> And yes, we have a problem with platforms having *all* their memory
> above 4GB.
>

now when we're picking at this, do we really need to memset an entire
page to zero? I know it's nice for debugging, but it is really
unnecessary and would slow down boot so slightly, no?

>> I also wonder whether or not you can eventually free the page and
>> corresponding mappings if !CONFIG_HOTPLUG_CPU?
>
> This is indeed possible, as we're sure nothing will use the boot tage
> tables once all CPUs have switched to the runtime page tables.
>
>>> +               memcpy(init_bounce_page, __hyp_idmap_text_start, len);
>>> +               /*
>>> +                * Warning: the code we just copied to the bounce page
>>> +                * must be flushed to the point of coherency.
>>> +                * Otherwise, the data may be sitting in L2, and HYP
>>> +                * mode won't be able to observe it as it runs with
>>> +                * caches off at that point.
>>> +                */
>>> +               kvm_flush_dcache_to_poc(init_bounce_page, len);
>>> +
>>> +               phys_base = virt_to_phys(init_bounce_page);
>>> +               hyp_idmap_vector += phys_base - hyp_idmap_start;
>>> +               hyp_idmap_start = phys_base;
>>> +               hyp_idmap_end = phys_base + len;
>>> +
>>> +               kvm_info("Using HYP init bounce page @%lx\n",
>>> +                        (unsigned long)phys_base);
>>> +       }
>>> +
>>>         hyp_pgd = kzalloc(PTRS_PER_PGD * sizeof(pgd_t), GFP_KERNEL);
>>> -       if (!hyp_pgd) {
>>> +       boot_hyp_pgd = kzalloc(PTRS_PER_PGD * sizeof(pgd_t), GFP_KERNEL);
>>> +       if (!hyp_pgd || !boot_hyp_pgd) {
>>>                 kvm_err("Hyp mode PGD not allocated\n");
>>>                 err = -ENOMEM;
>>>                 goto out;
>>> @@ -743,39 +807,30 @@ int kvm_mmu_init(void)
>>>                 goto out;
>>>         }
>>>
>>> +       /* Map the very same page at the trampoline VA */
>>> +       err =   __create_hyp_mappings(boot_hyp_pgd,
>>> +                                     TRAMPOLINE_VA, TRAMPOLINE_VA + PAGE_SIZE,
>>> +                                     __phys_to_pfn(hyp_idmap_start),
>>> +                                     PAGE_HYP);
>>> +       if (err) {
>>> +               kvm_err("Failed to map trampoline @%lx into boot HYP pgd\n",
>>> +                       TRAMPOLINE_VA);
>>> +               goto out;
>>> +       }
>>> +
>>> +       /* Map the same page again into the runtime page tables */
>>> +       err =   __create_hyp_mappings(hyp_pgd,
>>> +                                     TRAMPOLINE_VA, TRAMPOLINE_VA + PAGE_SIZE,
>>> +                                     __phys_to_pfn(hyp_idmap_start),
>>> +                                     PAGE_HYP);
>>> +       if (err) {
>>> +               kvm_err("Failed to map trampoline @%lx into runtime HYP pgd\n",
>>> +                       TRAMPOLINE_VA);
>>> +               goto out;
>>> +       }
>>
>> I'm probably just missing it, but where are the updated page tables flushed
>> to memory?
>
> Mumble mumble... We have some partial flush, but clearly not enough of
> it to be completely safe. Good spotting.
>
> I'll update the series and send out a v3.
>
> Thanks for reviewing.
>
>         M.
> --
> Jazz is not dead. It just smells funny...
>


From cdall at cs.columbia.edu  Tue Apr  9 14:31:24 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Tue, 9 Apr 2013 11:31:24 -0700
Subject: [PATCH 0/2] ARM: KVM: pre-KVM/arm64 patches
In-Reply-To: <1365436039-29564-1-git-send-email-marc.zyngier@arm.com>
References: <1365436039-29564-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <CAEDV+gL+ur+hC1EvKUcEkQ5_YkqvrZ3VYbFRJ=c7xyu2hOYMVw@mail.gmail.com>

On Mon, Apr 8, 2013 at 8:47 AM, Marc Zyngier <marc.zyngier at arm.com> wrote:
> This series contains two small changes to KVM/ARM, in preparation for
> the arm64 patches. None of these changes actually affect the 32bit
> implementation.
>
> This has been tested on both arm (VE TC2) and arm64 (Foundation Model).
>
> Marc Zyngier (2):
>   ARM: KVM: add architecture specific hook for capabilities
>   ARM: KVM: promote vfp_host pointer to generic host cpu context

they look good to me, I can just do that rename Peter pointed out when
applying them, thanks.


>
>  arch/arm/include/asm/kvm_host.h | 13 ++++++++++---
>  arch/arm/kernel/asm-offsets.c   |  2 +-
>  arch/arm/kvm/arm.c              | 30 +++++++++++++++---------------
>  3 files changed, 26 insertions(+), 19 deletions(-)
>
> --
> 1.8.1.4
>
>


From arnd at arndb.de  Tue Apr  9 14:32:18 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 9 Apr 2013 20:32:18 +0200
Subject: [PATCHv2] ARM: Push selects for TWD/SCU into machine entries
In-Reply-To: <5164462E.4010706@codeaurora.org>
References: <1362007694-3419-1-git-send-email-sboyd@codeaurora.org>
 <5151DC41.7090307@codeaurora.org> <5164462E.4010706@codeaurora.org>
Message-ID: <201304092032.18885.arnd@arndb.de>

On Tuesday 09 April 2013, Stephen Boyd wrote:
> >>>
> >>> Sneaking it in through the fixes branch would make life easier for us,
> >>> but it doesn't feel right.
> >> Arnd, can you pick this up into the arm-soc tree now? It would be good
> >> to get this into next so that conflicts are avoided later on.
> >>
> > Arnd?
> >
> 
> Ping?


Sorry for the long delay, you scrolled down from my unread emails twice.

Three tips for you to make it more likely to get a fast reaction time:

* Send the original patch to Olof and me, not just the reply to the
  on-list patch.
* Use the arm at kernel.org alias to reach us, since that will make the
  email go into the right folder
* Use the [GIT PULL] keyword in the subject line, ideally sending a
  pull request as well, instead of a separate email. While we do apply
  emails, It's often batch processing to apply everything and then
  we scan for emails that have PULL in the subject, while others
  can get lost.

I've applied it to the next/soc branch now.

	Arnd


From nicolas.pitre at linaro.org  Tue Apr  9 14:34:25 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Tue, 9 Apr 2013 14:34:25 -0400 (EDT)
Subject: [PATCH v4 2/2] arm: prefer PSCI for SMP bringup
In-Reply-To: <20130409122133.GA2233@linaro.org>
References: <1364575371-8926-2-git-send-email-stefano.stabellini@eu.citrix.com>
 <alpine.LFD.2.03.1303291320580.1372@syhkavp.arg>
 <alpine.DEB.2.02.1303291735080.4430@kaball.uk.xensource.com>
 <alpine.LFD.2.03.1303291349150.1372@syhkavp.arg> <5155EC28.8050608@gmail.com>
 <alpine.DEB.2.02.1304011541010.5078@kaball.uk.xensource.com>
 <alpine.LFD.2.03.1304011412030.1171@syhkavp.arg>
 <alpine.DEB.2.02.1304021522230.5078@kaball.uk.xensource.com>
 <alpine.LFD.2.03.1304021202520.1171@syhkavp.arg>
 <20130409122133.GA2233@linaro.org>
Message-ID: <alpine.LFD.2.03.1304091421370.1171@syhkavp.arg>

On Tue, 9 Apr 2013, Dave Martin wrote:

> On Tue, Apr 02, 2013 at 12:11:25PM -0400, Nicolas Pitre wrote:
> > I'm concerned about mixing big.LITTLE and Xen as well.  I don't think 
> > this is going to make an easy match.  KVM might have an easier fit here.
> > 
> > But, in any case, even if the MCPM layer gets involved, if Xen is there 
> > then PSCI will end up being the ultimate interface anyway.
> 
> Note that big.LITTLE != MCPM.  Virtualisation hosts might be large multi-
> cluster systems, but the CPUs might be all of the same type.  MCPM or
> similar would me needed for the multi-cluster power management even
> though there is no big.LITTLE mix of CPUs.

Absolutely!  But in this case, there is no need for Xen to learn about 
the computing capacity differences between different CPU sets.

What I wanted to emphasize is the fact that, if Xen decides to expose a 
b.L topology to guests, then those guests must be b.L aware to make good 
scheduling decisions, etc.  Initially I suspect that guests will be 
confined to the same sets of CPUs to simplify things.  Or it could even 
migrate a guest between little and big CPUs like the switcher does.  
But a single guest probably won't span different CPU classes 
simultaneously initially.  And therefore it is unlikely that MCPM will 
be active inside a Xen guest for quite a while.

> > But let's cross that bridge when we get to it.  For now this is still a 
> > non existing problem.
> 
> That's a big open question.  Either the host or hypervisor needs to be
> very clever about scheduling guests, or you need to bind each guest virtual
> CPU to a specific class of physical CPUs -- so, for example you provide
> a guest with an explicit mix of bigs and littles.
> 
> All we can say about that for now is that it's a potential research area...

Absolutely.


Nicolas


From lee.jones at linaro.org  Tue Apr  9 14:39:36 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Tue,  9 Apr 2013 19:39:36 +0100
Subject: [PATCH 1/8] dmaengine: ste_dma40: Assign memcpy channels in the driver
Message-ID: <1365532783-27425-1-git-send-email-lee.jones@linaro.org>

The channels reserved for memcpy are the same for all currently
supported platforms. With this in mind, we can ease the platform
data passing requirement by moving these assignments out from
platform code and place them directly into the driver.

Cc: Vinod Koul <vinod.koul at intel.com>
Cc: Dan Williams <djbw at fb.com>
Cc: Per Forlin <per.forlin at stericsson.com>
Acked-by: Arnd Bergmann <arnd at arndb.de>
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/mach-ux500/devices-db8500.c        |   12 ------------
 drivers/dma/ste_dma40.c                     |   12 +++++++-----
 include/linux/platform_data/dma-ste-dma40.h |    4 ----
 3 files changed, 7 insertions(+), 21 deletions(-)

diff --git a/arch/arm/mach-ux500/devices-db8500.c b/arch/arm/mach-ux500/devices-db8500.c
index afa5b04..9b09683 100644
--- a/arch/arm/mach-ux500/devices-db8500.c
+++ b/arch/arm/mach-ux500/devices-db8500.c
@@ -146,22 +146,10 @@ static const dma_addr_t dma40_rx_map[DB8500_DMA_NR_DEV] = {
 	[DB8500_DMA_DEV48_CAC1_RX] = U8500_CRYP1_BASE + CRYP1_RX_REG_OFFSET,
 };
 
-/* Reserved event lines for memcpy only */
-static int dma40_memcpy_event[] = {
-	DB8500_DMA_MEMCPY_TX_0,
-	DB8500_DMA_MEMCPY_TX_1,
-	DB8500_DMA_MEMCPY_TX_2,
-	DB8500_DMA_MEMCPY_TX_3,
-	DB8500_DMA_MEMCPY_TX_4,
-	DB8500_DMA_MEMCPY_TX_5,
-};
-
 static struct stedma40_platform_data dma40_plat_data = {
 	.dev_len = DB8500_DMA_NR_DEV,
 	.dev_rx = dma40_rx_map,
 	.dev_tx = dma40_tx_map,
-	.memcpy = dma40_memcpy_event,
-	.memcpy_len = ARRAY_SIZE(dma40_memcpy_event),
 	.memcpy_conf_phy = &dma40_memcpy_conf_phy,
 	.memcpy_conf_log = &dma40_memcpy_conf_log,
 	.disabled_channels = {-1},
diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index 1734fee..12de79e 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -55,6 +55,9 @@
 
 #define MAX(a, b) (((a) < (b)) ? (b) : (a))
 
+/* Reserved event lines for memcpy only. */
+static int dma40_memcpy_channels[] = { 56, 57, 58, 59, 60 };
+
 /**
  * enum 40_command - The different commands and/or statuses.
  *
@@ -2014,8 +2017,7 @@ static int d40_config_memcpy(struct d40_chan *d40c)
 	if (dma_has_cap(DMA_MEMCPY, cap) && !dma_has_cap(DMA_SLAVE, cap)) {
 		d40c->dma_cfg = *d40c->base->plat_data->memcpy_conf_log;
 		d40c->dma_cfg.src_dev_type = STEDMA40_DEV_SRC_MEMORY;
-		d40c->dma_cfg.dst_dev_type = d40c->base->plat_data->
-			memcpy[d40c->chan.chan_id];
+		d40c->dma_cfg.dst_dev_type = dma40_memcpy_channels[d40c->chan.chan_id];
 
 	} else if (dma_has_cap(DMA_MEMCPY, cap) &&
 		   dma_has_cap(DMA_SLAVE, cap)) {
@@ -2927,7 +2929,7 @@ static int __init d40_dmaengine_init(struct d40_base *base,
 	}
 
 	d40_chan_init(base, &base->dma_memcpy, base->log_chans,
-		      base->num_log_chans, base->plat_data->memcpy_len);
+		      base->num_log_chans, ARRAY_SIZE(dma40_memcpy_channels));
 
 	dma_cap_zero(base->dma_memcpy.cap_mask);
 	dma_cap_set(DMA_MEMCPY, base->dma_memcpy.cap_mask);
@@ -3215,7 +3217,7 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
 			num_log_chans++;
 
 	base = kzalloc(ALIGN(sizeof(struct d40_base), 4) +
-		       (num_phy_chans + num_log_chans + plat_data->memcpy_len) *
+		       (num_phy_chans + num_log_chans + ARRAY_SIZE(dma40_memcpy_channels)) *
 		       sizeof(struct d40_chan), GFP_KERNEL);
 
 	if (base == NULL) {
@@ -3276,7 +3278,7 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
 	if (!base->lookup_phy_chans)
 		goto failure;
 
-	if (num_log_chans + plat_data->memcpy_len) {
+	if (num_log_chans + ARRAY_SIZE(dma40_memcpy_channels)) {
 		/*
 		 * The max number of logical channels are event lines for all
 		 * src devices and dst devices
diff --git a/include/linux/platform_data/dma-ste-dma40.h b/include/linux/platform_data/dma-ste-dma40.h
index 4b78101..a808784 100644
--- a/include/linux/platform_data/dma-ste-dma40.h
+++ b/include/linux/platform_data/dma-ste-dma40.h
@@ -141,8 +141,6 @@ struct stedma40_chan_cfg {
  * @dev_len: length of dev_tx and dev_rx
  * @dev_tx: mapping between destination event line and io address
  * @dev_rx: mapping between source event line and io address
- * @memcpy: list of memcpy event lines
- * @memcpy_len: length of memcpy
  * @memcpy_conf_phy: default configuration of physical channel memcpy
  * @memcpy_conf_log: default configuration of logical channel memcpy
  * @disabled_channels: A vector, ending with -1, that marks physical channels
@@ -162,8 +160,6 @@ struct stedma40_platform_data {
 	u32				 dev_len;
 	const dma_addr_t		*dev_tx;
 	const dma_addr_t		*dev_rx;
-	int				*memcpy;
-	u32				 memcpy_len;
 	struct stedma40_chan_cfg	*memcpy_conf_phy;
 	struct stedma40_chan_cfg	*memcpy_conf_log;
 	int				 disabled_channels[STEDMA40_MAX_PHYS];
-- 
1.7.10.4



From lee.jones at linaro.org  Tue Apr  9 14:39:37 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Tue,  9 Apr 2013 19:39:37 +0100
Subject: [PATCH 2/8] dmaengine: ste_dma40: Move default memcpy configs into
 the driver
In-Reply-To: <1365532783-27425-1-git-send-email-lee.jones@linaro.org>
References: <1365532783-27425-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1365532783-27425-2-git-send-email-lee.jones@linaro.org>

There are only two default memcpy configurations used for the DMA40
driver; one for physical memcpy and one for logical memcpy. Instead
of invariably passing the same configurations though platform data,
we're moving them into the driver instead.

Cc: Vinod Koul <vinod.koul at intel.com>
Cc: Dan Williams <djbw at fb.com>
Cc: Per Forlin <per.forlin at stericsson.com>
Acked-by: Arnd Bergmann <arnd at arndb.de>
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/mach-ux500/devices-db8500.c        |   28 -----------------------
 drivers/dma/ste_dma40.c                     |   32 +++++++++++++++++++++++++--
 include/linux/platform_data/dma-ste-dma40.h |    4 ----
 3 files changed, 30 insertions(+), 34 deletions(-)

diff --git a/arch/arm/mach-ux500/devices-db8500.c b/arch/arm/mach-ux500/devices-db8500.c
index 9b09683..5b1f1f7 100644
--- a/arch/arm/mach-ux500/devices-db8500.c
+++ b/arch/arm/mach-ux500/devices-db8500.c
@@ -42,32 +42,6 @@ static struct resource dma40_resources[] = {
 	}
 };
 
-/* Default configuration for physcial memcpy */
-struct stedma40_chan_cfg dma40_memcpy_conf_phy = {
-	.mode = STEDMA40_MODE_PHYSICAL,
-	.dir = STEDMA40_MEM_TO_MEM,
-
-	.src_info.data_width = STEDMA40_BYTE_WIDTH,
-	.src_info.psize = STEDMA40_PSIZE_PHY_1,
-	.src_info.flow_ctrl = STEDMA40_NO_FLOW_CTRL,
-
-	.dst_info.data_width = STEDMA40_BYTE_WIDTH,
-	.dst_info.psize = STEDMA40_PSIZE_PHY_1,
-	.dst_info.flow_ctrl = STEDMA40_NO_FLOW_CTRL,
-};
-/* Default configuration for logical memcpy */
-struct stedma40_chan_cfg dma40_memcpy_conf_log = {
-	.dir = STEDMA40_MEM_TO_MEM,
-
-	.src_info.data_width = STEDMA40_BYTE_WIDTH,
-	.src_info.psize = STEDMA40_PSIZE_LOG_1,
-	.src_info.flow_ctrl = STEDMA40_NO_FLOW_CTRL,
-
-	.dst_info.data_width = STEDMA40_BYTE_WIDTH,
-	.dst_info.psize = STEDMA40_PSIZE_LOG_1,
-	.dst_info.flow_ctrl = STEDMA40_NO_FLOW_CTRL,
-};
-
 /*
  * Mapping between destination event lines and physical device address.
  * The event line is tied to a device and therefore the address is constant.
@@ -150,8 +124,6 @@ static struct stedma40_platform_data dma40_plat_data = {
 	.dev_len = DB8500_DMA_NR_DEV,
 	.dev_rx = dma40_rx_map,
 	.dev_tx = dma40_tx_map,
-	.memcpy_conf_phy = &dma40_memcpy_conf_phy,
-	.memcpy_conf_log = &dma40_memcpy_conf_log,
 	.disabled_channels = {-1},
 };
 
diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index 12de79e..3b83dee 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -58,6 +58,34 @@
 /* Reserved event lines for memcpy only. */
 static int dma40_memcpy_channels[] = { 56, 57, 58, 59, 60 };
 
+/* Default configuration for physcial memcpy */
+struct stedma40_chan_cfg dma40_memcpy_conf_phy = {
+	.mode = STEDMA40_MODE_PHYSICAL,
+	.dir = STEDMA40_MEM_TO_MEM,
+
+	.src_info.data_width = STEDMA40_BYTE_WIDTH,
+	.src_info.psize = STEDMA40_PSIZE_PHY_1,
+	.src_info.flow_ctrl = STEDMA40_NO_FLOW_CTRL,
+
+	.dst_info.data_width = STEDMA40_BYTE_WIDTH,
+	.dst_info.psize = STEDMA40_PSIZE_PHY_1,
+	.dst_info.flow_ctrl = STEDMA40_NO_FLOW_CTRL,
+};
+
+/* Default configuration for logical memcpy */
+struct stedma40_chan_cfg dma40_memcpy_conf_log = {
+	.mode = STEDMA40_MODE_LOGICAL,
+	.dir = STEDMA40_MEM_TO_MEM,
+
+	.src_info.data_width = STEDMA40_BYTE_WIDTH,
+	.src_info.psize = STEDMA40_PSIZE_LOG_1,
+	.src_info.flow_ctrl = STEDMA40_NO_FLOW_CTRL,
+
+	.dst_info.data_width = STEDMA40_BYTE_WIDTH,
+	.dst_info.psize = STEDMA40_PSIZE_LOG_1,
+	.dst_info.flow_ctrl = STEDMA40_NO_FLOW_CTRL,
+};
+
 /**
  * enum 40_command - The different commands and/or statuses.
  *
@@ -2015,13 +2043,13 @@ static int d40_config_memcpy(struct d40_chan *d40c)
 	dma_cap_mask_t cap = d40c->chan.device->cap_mask;
 
 	if (dma_has_cap(DMA_MEMCPY, cap) && !dma_has_cap(DMA_SLAVE, cap)) {
-		d40c->dma_cfg = *d40c->base->plat_data->memcpy_conf_log;
+		d40c->dma_cfg = dma40_memcpy_conf_log;
 		d40c->dma_cfg.src_dev_type = STEDMA40_DEV_SRC_MEMORY;
 		d40c->dma_cfg.dst_dev_type = dma40_memcpy_channels[d40c->chan.chan_id];
 
 	} else if (dma_has_cap(DMA_MEMCPY, cap) &&
 		   dma_has_cap(DMA_SLAVE, cap)) {
-		d40c->dma_cfg = *d40c->base->plat_data->memcpy_conf_phy;
+		d40c->dma_cfg = dma40_memcpy_conf_phy;
 	} else {
 		chan_err(d40c, "No memcpy\n");
 		return -EINVAL;
diff --git a/include/linux/platform_data/dma-ste-dma40.h b/include/linux/platform_data/dma-ste-dma40.h
index a808784..869c571 100644
--- a/include/linux/platform_data/dma-ste-dma40.h
+++ b/include/linux/platform_data/dma-ste-dma40.h
@@ -141,8 +141,6 @@ struct stedma40_chan_cfg {
  * @dev_len: length of dev_tx and dev_rx
  * @dev_tx: mapping between destination event line and io address
  * @dev_rx: mapping between source event line and io address
- * @memcpy_conf_phy: default configuration of physical channel memcpy
- * @memcpy_conf_log: default configuration of logical channel memcpy
  * @disabled_channels: A vector, ending with -1, that marks physical channels
  * that are for different reasons not available for the driver.
  * @soft_lli_chans: A vector, that marks physical channels will use LLI by SW
@@ -160,8 +158,6 @@ struct stedma40_platform_data {
 	u32				 dev_len;
 	const dma_addr_t		*dev_tx;
 	const dma_addr_t		*dev_rx;
-	struct stedma40_chan_cfg	*memcpy_conf_phy;
-	struct stedma40_chan_cfg	*memcpy_conf_log;
 	int				 disabled_channels[STEDMA40_MAX_PHYS];
 	int				*soft_lli_chans;
 	int				 num_of_soft_lli_chans;
-- 
1.7.10.4



From lee.jones at linaro.org  Tue Apr  9 14:39:38 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Tue,  9 Apr 2013 19:39:38 +0100
Subject: [PATCH 3/8] dmaengine: ste_dma40: Actually write the runtime
 configuration to registers
In-Reply-To: <1365532783-27425-1-git-send-email-lee.jones@linaro.org>
References: <1365532783-27425-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1365532783-27425-3-git-send-email-lee.jones@linaro.org>

Someone has spent a fair amount of effort writing a runtime configuration
changing algorithm for DMA clients. However, the config appears to never
actually make it to hardware. In order for the configuration to take hold
we need to issue a d40_config_write(), as this is the routine which writes
it into the hardware's registers.

Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 drivers/dma/ste_dma40.c |    3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index 3b83dee..2a0a9d4 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -2831,6 +2831,9 @@ static int d40_set_runtime_config(struct dma_chan *chan,
 	/* These settings will take precedence later */
 	d40c->runtime_addr = config_addr;
 	d40c->runtime_direction = config->direction;
+
+	d40_config_write(d40c);
+
 	dev_dbg(d40c->base->dev,
 		"configured channel %s for %s, data width %d/%d, "
 		"maxburst %d/%d elements, LE, no flow control\n",
-- 
1.7.10.4



From lee.jones at linaro.org  Tue Apr  9 14:39:39 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Tue,  9 Apr 2013 19:39:39 +0100
Subject: [PATCH 4/8] dmaengine: ste_dma40: Do not configure channels during an
 channel allocation
In-Reply-To: <1365532783-27425-1-git-send-email-lee.jones@linaro.org>
References: <1365532783-27425-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1365532783-27425-4-git-send-email-lee.jones@linaro.org>

According to the DMA documentation allocating a channel and configuring
it are two separate actions. By removing the configuration code from the
channel allocation path we lighten the burden on the information required to
successfully allocate a channel.

Cc: Vinod Koul <vinod.koul at intel.com>
Cc: Dan Williams <djbw at fb.com>
Cc: Per Forlin <per.forlin at stericsson.com>
Acked-by: Arnd Bergmann <arnd at arndb.de>
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 drivers/dma/ste_dma40.c |   14 --------------
 1 file changed, 14 deletions(-)

diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index 2a0a9d4..9e423ad 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -2463,16 +2463,10 @@ static int d40_alloc_chan_resources(struct dma_chan *chan)
 	}
 
 	pm_runtime_get_sync(d40c->base->dev);
-	/* Fill in basic CFG register values */
-	d40_phy_cfg(&d40c->dma_cfg, &d40c->src_def_cfg,
-		    &d40c->dst_def_cfg, chan_is_logical(d40c));
 
 	d40_set_prio_realtime(d40c);
 
 	if (chan_is_logical(d40c)) {
-		d40_log_cfg(&d40c->dma_cfg,
-			    &d40c->log_def.lcsp1, &d40c->log_def.lcsp3);
-
 		if (d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_MEM)
 			d40c->lcpa = d40c->base->lcpa_base +
 				d40c->dma_cfg.src_dev_type * D40_LCPA_CHAN_SIZE;
@@ -2487,14 +2481,6 @@ static int d40_alloc_chan_resources(struct dma_chan *chan)
 		 d40c->phy_chan->num,
 		 d40c->dma_cfg.use_fixed_channel ? ", fixed" : "");
 
-
-	/*
-	 * Only write channel configuration to the DMA if the physical
-	 * resource is free. In case of multiple logical channels
-	 * on the same physical resource, only the first write is necessary.
-	 */
-	if (is_free_phy)
-		d40_config_write(d40c);
 fail:
 	pm_runtime_mark_last_busy(d40c->base->dev);
 	pm_runtime_put_autosuspend(d40c->base->dev);
-- 
1.7.10.4



From lee.jones at linaro.org  Tue Apr  9 14:39:40 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Tue,  9 Apr 2013 19:39:40 +0100
Subject: [PATCH 5/8] dmaengine: ste_dma40: Ensure src and dst registers are
 configured correctly
In-Reply-To: <1365532783-27425-1-git-send-email-lee.jones@linaro.org>
References: <1365532783-27425-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1365532783-27425-5-git-send-email-lee.jones@linaro.org>

Confusingly d40_log_cfg() is used to set up the logical channel
configuration registers, but d40_phy_cfg() is used to configure
physical _and_ logical registers, so it should be called in both
cases. It is the function call's final attribute which determines
whether it's a physical or logical channel, not whether the
function is called or not.

Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 drivers/dma/ste_dma40.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index 9e423ad..49d8c9d 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -2810,9 +2810,9 @@ static int d40_set_runtime_config(struct dma_chan *chan,
 	/* Fill in register values */
 	if (chan_is_logical(d40c))
 		d40_log_cfg(cfg, &d40c->log_def.lcsp1, &d40c->log_def.lcsp3);
-	else
-		d40_phy_cfg(cfg, &d40c->src_def_cfg,
-			    &d40c->dst_def_cfg, false);
+
+	d40_phy_cfg(cfg, &d40c->src_def_cfg, &d40c->dst_def_cfg,
+		    chan_is_logical(d40c));
 
 	/* These settings will take precedence later */
 	d40c->runtime_addr = config_addr;
-- 
1.7.10.4



From lee.jones at linaro.org  Tue Apr  9 14:39:41 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Tue,  9 Apr 2013 19:39:41 +0100
Subject: [PATCH 6/8] dmaengine: ste_dma40: Move LCPA allocation and real-time
 config
In-Reply-To: <1365532783-27425-1-git-send-email-lee.jones@linaro.org>
References: <1365532783-27425-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1365532783-27425-6-git-send-email-lee.jones@linaro.org>

There are various pieces of configuration which do not need to happen
until after a channel is allocated. Here we move some of these so they're
dealt with when it's time to configure the channel, rather than allocate
it.

Cc: Vinod Koul <vinod.koul at intel.com>
Cc: Dan Williams <djbw at fb.com>
Cc: Per Forlin <per.forlin at stericsson.com>
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 drivers/dma/ste_dma40.c |   24 ++++++++++++------------
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index 49d8c9d..c14db3e 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -2464,18 +2464,6 @@ static int d40_alloc_chan_resources(struct dma_chan *chan)
 
 	pm_runtime_get_sync(d40c->base->dev);
 
-	d40_set_prio_realtime(d40c);
-
-	if (chan_is_logical(d40c)) {
-		if (d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_MEM)
-			d40c->lcpa = d40c->base->lcpa_base +
-				d40c->dma_cfg.src_dev_type * D40_LCPA_CHAN_SIZE;
-		else
-			d40c->lcpa = d40c->base->lcpa_base +
-				d40c->dma_cfg.dst_dev_type *
-				D40_LCPA_CHAN_SIZE + D40_LCPA_CHAN_DST_DELTA;
-	}
-
 	dev_dbg(chan2dev(d40c), "allocated %s channel (phy %d%s)\n",
 		 chan_is_logical(d40c) ? "logical" : "physical",
 		 d40c->phy_chan->num,
@@ -2814,6 +2802,18 @@ static int d40_set_runtime_config(struct dma_chan *chan,
 	d40_phy_cfg(cfg, &d40c->src_def_cfg, &d40c->dst_def_cfg,
 		    chan_is_logical(d40c));
 
+	d40_set_prio_realtime(d40c);
+
+	if (chan_is_logical(d40c)) {
+		if (cfg->dir == STEDMA40_PERIPH_TO_MEM)
+			d40c->lcpa = d40c->base->lcpa_base +
+				cfg->src_dev_type * D40_LCPA_CHAN_SIZE;
+		else
+			d40c->lcpa = d40c->base->lcpa_base +
+				cfg->dst_dev_type *
+				D40_LCPA_CHAN_SIZE + D40_LCPA_CHAN_DST_DELTA;
+	}
+
 	/* These settings will take precedence later */
 	d40c->runtime_addr = config_addr;
 	d40c->runtime_direction = config->direction;
-- 
1.7.10.4



From lee.jones at linaro.org  Tue Apr  9 14:39:42 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Tue,  9 Apr 2013 19:39:42 +0100
Subject: [PATCH 7/8] dmaengine: ste_dma40: Use the BIT macro to replace ugly
 '(1 << x)'s
In-Reply-To: <1365532783-27425-1-git-send-email-lee.jones@linaro.org>
References: <1365532783-27425-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1365532783-27425-7-git-send-email-lee.jones@linaro.org>

The aim is to make the code that little more readable.

Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 drivers/dma/ste_dma40.c |   34 +++++++++++++++++-----------------
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index c14db3e..7b96e75 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -49,9 +49,9 @@
 #define MAX_LCLA_ALLOC_ATTEMPTS 256
 
 /* Bit markings for allocation map */
-#define D40_ALLOC_FREE		(1 << 31)
-#define D40_ALLOC_PHY		(1 << 30)
-#define D40_ALLOC_LOG_FREE	0
+#define D40_ALLOC_FREE		BIT(31)
+#define D40_ALLOC_PHY		BIT(30)
+#define D40_ALLOC_LOG_FREE	BIT(0)
 
 #define MAX(a, b) (((a) < (b)) ? (b) : (a))
 
@@ -993,12 +993,12 @@ static int d40_size_2_dmalen(int size, u32 data_width1, u32 data_width2)
 	int dmalen;
 	u32 max_w = max(data_width1, data_width2);
 	u32 min_w = min(data_width1, data_width2);
-	u32 seg_max = ALIGN(STEDMA40_MAX_SEG_SIZE << min_w, 1 << max_w);
+	u32 seg_max = ALIGN(STEDMA40_MAX_SEG_SIZE << min_w, BIT(max_w));
 
 	if (seg_max > STEDMA40_MAX_SEG_SIZE)
-		seg_max -= (1 << max_w);
+		seg_max -= BIT(max_w);
 
-	if (!IS_ALIGNED(size, 1 << max_w))
+	if (!IS_ALIGNED(size, BIT(max_w)))
 		return -EINVAL;
 
 	if (size <= seg_max)
@@ -1448,7 +1448,7 @@ static u32 d40_residue(struct d40_chan *d40c)
 			  >> D40_SREG_ELEM_PHY_ECNT_POS;
 	}
 
-	return num_elt * (1 << d40c->dma_cfg.dst_info.data_width);
+	return num_elt * BIT(d40c->dma_cfg.dst_info.data_width);
 }
 
 static bool d40_tx_is_linked(struct d40_chan *d40c)
@@ -1722,7 +1722,7 @@ static irqreturn_t d40_handle_interrupt(int irq, void *data)
 		}
 
 		/* ACK interrupt */
-		writel(1 << idx, base->virtbase + il[row].clr);
+		writel(BIT(idx), base->virtbase + il[row].clr);
 
 		spin_lock(&d40c->lock);
 
@@ -1804,9 +1804,9 @@ static int d40_validate_conf(struct d40_chan *d40c,
 	}
 
 	if (d40_psize_2_burst_size(is_log, conf->src_info.psize) *
-	    (1 << conf->src_info.data_width) !=
+	    BIT(conf->src_info.data_width) !=
 	    d40_psize_2_burst_size(is_log, conf->dst_info.psize) *
-	    (1 << conf->dst_info.data_width)) {
+	    BIT(conf->dst_info.data_width)) {
 		/*
 		 * The DMAC hardware only supports
 		 * src (burst x width) == dst (burst x width)
@@ -1848,8 +1848,8 @@ static bool d40_alloc_mask_set(struct d40_phy_res *phy,
 		if (phy->allocated_src == D40_ALLOC_FREE)
 			phy->allocated_src = D40_ALLOC_LOG_FREE;
 
-		if (!(phy->allocated_src & (1 << log_event_line))) {
-			phy->allocated_src |= 1 << log_event_line;
+		if (!(phy->allocated_src & BIT(log_event_line))) {
+			phy->allocated_src |= BIT(log_event_line);
 			goto found;
 		} else
 			goto not_found;
@@ -1860,8 +1860,8 @@ static bool d40_alloc_mask_set(struct d40_phy_res *phy,
 		if (phy->allocated_dst == D40_ALLOC_FREE)
 			phy->allocated_dst = D40_ALLOC_LOG_FREE;
 
-		if (!(phy->allocated_dst & (1 << log_event_line))) {
-			phy->allocated_dst |= 1 << log_event_line;
+		if (!(phy->allocated_dst & BIT(log_event_line))) {
+			phy->allocated_dst |= BIT(log_event_line);
 			goto found;
 		} else
 			goto not_found;
@@ -1891,11 +1891,11 @@ static bool d40_alloc_mask_free(struct d40_phy_res *phy, bool is_src,
 
 	/* Logical channel */
 	if (is_src) {
-		phy->allocated_src &= ~(1 << log_event_line);
+		phy->allocated_src &= ~BIT(log_event_line);
 		if (phy->allocated_src == D40_ALLOC_LOG_FREE)
 			phy->allocated_src = D40_ALLOC_FREE;
 	} else {
-		phy->allocated_dst &= ~(1 << log_event_line);
+		phy->allocated_dst &= ~BIT(log_event_line);
 		if (phy->allocated_dst == D40_ALLOC_LOG_FREE)
 			phy->allocated_dst = D40_ALLOC_FREE;
 	}
@@ -2394,7 +2394,7 @@ static void __d40_set_prio_rt(struct d40_chan *d40c, int dev_type, bool src)
 	u32 rtreg;
 	u32 event = D40_TYPE_TO_EVENT(dev_type);
 	u32 group = D40_TYPE_TO_GROUP(dev_type);
-	u32 bit = 1 << event;
+	u32 bit = BIT(event);
 	u32 prioreg;
 	struct d40_gen_dmac *dmac = &d40c->base->gen_dmac;
 
-- 
1.7.10.4



From lee.jones at linaro.org  Tue Apr  9 14:39:43 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Tue,  9 Apr 2013 19:39:43 +0100
Subject: [PATCH 8/8] ARM: ux500: Amalgamate DMA source and destination channel
 numbers
In-Reply-To: <1365532783-27425-1-git-send-email-lee.jones@linaro.org>
References: <1365532783-27425-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1365532783-27425-8-git-send-email-lee.jones@linaro.org>

Devices which utilise DMA tend to use the same channel numbers for
transmitting and receiving. For this reason and the fact that it'll
decrease the burden of platform data passed to each device, we're
amalgamating source and destination device types.

Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/mach-ux500/board-mop500-audio.c    |   18 +--
 arch/arm/mach-ux500/board-mop500-sdi.c      |   24 ++--
 arch/arm/mach-ux500/board-mop500.c          |   33 ++---
 arch/arm/mach-ux500/cpu-db8500.c            |   32 ++---
 arch/arm/mach-ux500/devices-db8500.c        |  120 ++++++++---------
 arch/arm/mach-ux500/ste-dma40-db8500.h      |  193 ++++++++++-----------------
 arch/arm/mach-ux500/usb.c                   |   10 +-
 drivers/dma/ste_dma40.c                     |   99 +++++---------
 drivers/dma/ste_dma40_ll.c                  |    4 +-
 include/linux/platform_data/dma-ste-dma40.h |    6 +-
 10 files changed, 209 insertions(+), 330 deletions(-)

diff --git a/arch/arm/mach-ux500/board-mop500-audio.c b/arch/arm/mach-ux500/board-mop500-audio.c
index 7209db7..f012cfa 100644
--- a/arch/arm/mach-ux500/board-mop500-audio.c
+++ b/arch/arm/mach-ux500/board-mop500-audio.c
@@ -24,8 +24,7 @@ static struct stedma40_chan_cfg msp0_dma_rx = {
 	.high_priority = true,
 	.dir = STEDMA40_PERIPH_TO_MEM,
 
-	.src_dev_type = DB8500_DMA_DEV31_MSP0_RX_SLIM0_CH0_RX,
-	.dst_dev_type = STEDMA40_DEV_DST_MEMORY,
+	.dev_type = DB8500_DMA_DEV31_MSP0_SLIM0_CH0,
 
 	.src_info.psize = STEDMA40_PSIZE_LOG_4,
 	.dst_info.psize = STEDMA40_PSIZE_LOG_4,
@@ -37,8 +36,7 @@ static struct stedma40_chan_cfg msp0_dma_tx = {
 	.high_priority = true,
 	.dir = STEDMA40_MEM_TO_PERIPH,
 
-	.src_dev_type = STEDMA40_DEV_DST_MEMORY,
-	.dst_dev_type = DB8500_DMA_DEV31_MSP0_TX_SLIM0_CH0_TX,
+	.dev_type = DB8500_DMA_DEV31_MSP0_SLIM0_CH0,
 
 	.src_info.psize = STEDMA40_PSIZE_LOG_4,
 	.dst_info.psize = STEDMA40_PSIZE_LOG_4,
@@ -56,8 +54,7 @@ static struct stedma40_chan_cfg msp1_dma_rx = {
 	.high_priority = true,
 	.dir = STEDMA40_PERIPH_TO_MEM,
 
-	.src_dev_type = DB8500_DMA_DEV30_MSP3_RX,
-	.dst_dev_type = STEDMA40_DEV_DST_MEMORY,
+	.dev_type = DB8500_DMA_DEV30_MSP3,
 
 	.src_info.psize = STEDMA40_PSIZE_LOG_4,
 	.dst_info.psize = STEDMA40_PSIZE_LOG_4,
@@ -69,8 +66,7 @@ static struct stedma40_chan_cfg msp1_dma_tx = {
 	.high_priority = true,
 	.dir = STEDMA40_MEM_TO_PERIPH,
 
-	.src_dev_type = STEDMA40_DEV_DST_MEMORY,
-	.dst_dev_type = DB8500_DMA_DEV30_MSP1_TX,
+	.dev_type = DB8500_DMA_DEV30_MSP1,
 
 	.src_info.psize = STEDMA40_PSIZE_LOG_4,
 	.dst_info.psize = STEDMA40_PSIZE_LOG_4,
@@ -88,8 +84,7 @@ static struct stedma40_chan_cfg msp2_dma_rx = {
 	.high_priority = true,
 	.dir = STEDMA40_PERIPH_TO_MEM,
 
-	.src_dev_type = DB8500_DMA_DEV14_MSP2_RX,
-	.dst_dev_type = STEDMA40_DEV_DST_MEMORY,
+	.dev_type = DB8500_DMA_DEV14_MSP2,
 
 	/* MSP2 DMA doesn't work with PSIZE == 4 on DB8500v2 */
 	.src_info.psize = STEDMA40_PSIZE_LOG_1,
@@ -102,8 +97,7 @@ static struct stedma40_chan_cfg msp2_dma_tx = {
 	.high_priority = true,
 	.dir = STEDMA40_MEM_TO_PERIPH,
 
-	.src_dev_type = STEDMA40_DEV_DST_MEMORY,
-	.dst_dev_type = DB8500_DMA_DEV14_MSP2_TX,
+	.dev_type = DB8500_DMA_DEV14_MSP2,
 
 	.src_info.psize = STEDMA40_PSIZE_LOG_4,
 	.dst_info.psize = STEDMA40_PSIZE_LOG_4,
diff --git a/arch/arm/mach-ux500/board-mop500-sdi.c b/arch/arm/mach-ux500/board-mop500-sdi.c
index 7f2cb6c..5c28216 100644
--- a/arch/arm/mach-ux500/board-mop500-sdi.c
+++ b/arch/arm/mach-ux500/board-mop500-sdi.c
@@ -64,8 +64,7 @@ static int mop500_sdi0_ios_handler(struct device *dev, struct mmc_ios *ios)
 struct stedma40_chan_cfg mop500_sdi0_dma_cfg_rx = {
 	.mode = STEDMA40_MODE_LOGICAL,
 	.dir = STEDMA40_PERIPH_TO_MEM,
-	.src_dev_type = DB8500_DMA_DEV29_SD_MM0_RX,
-	.dst_dev_type = STEDMA40_DEV_DST_MEMORY,
+	.dev_type = DB8500_DMA_DEV29_SD_MM0,
 	.src_info.data_width = STEDMA40_WORD_WIDTH,
 	.dst_info.data_width = STEDMA40_WORD_WIDTH,
 };
@@ -73,8 +72,7 @@ struct stedma40_chan_cfg mop500_sdi0_dma_cfg_rx = {
 static struct stedma40_chan_cfg mop500_sdi0_dma_cfg_tx = {
 	.mode = STEDMA40_MODE_LOGICAL,
 	.dir = STEDMA40_MEM_TO_PERIPH,
-	.src_dev_type = STEDMA40_DEV_SRC_MEMORY,
-	.dst_dev_type = DB8500_DMA_DEV29_SD_MM0_TX,
+	.dev_type = DB8500_DMA_DEV29_SD_MM0,
 	.src_info.data_width = STEDMA40_WORD_WIDTH,
 	.dst_info.data_width = STEDMA40_WORD_WIDTH,
 };
@@ -135,8 +133,7 @@ void mop500_sdi_tc35892_init(struct device *parent)
 static struct stedma40_chan_cfg sdi1_dma_cfg_rx = {
 	.mode = STEDMA40_MODE_LOGICAL,
 	.dir = STEDMA40_PERIPH_TO_MEM,
-	.src_dev_type = DB8500_DMA_DEV32_SD_MM1_RX,
-	.dst_dev_type = STEDMA40_DEV_DST_MEMORY,
+	.dev_type = DB8500_DMA_DEV32_SD_MM1,
 	.src_info.data_width = STEDMA40_WORD_WIDTH,
 	.dst_info.data_width = STEDMA40_WORD_WIDTH,
 };
@@ -144,8 +141,7 @@ static struct stedma40_chan_cfg sdi1_dma_cfg_rx = {
 static struct stedma40_chan_cfg sdi1_dma_cfg_tx = {
 	.mode = STEDMA40_MODE_LOGICAL,
 	.dir = STEDMA40_MEM_TO_PERIPH,
-	.src_dev_type = STEDMA40_DEV_SRC_MEMORY,
-	.dst_dev_type = DB8500_DMA_DEV32_SD_MM1_TX,
+	.dev_type = DB8500_DMA_DEV32_SD_MM1,
 	.src_info.data_width = STEDMA40_WORD_WIDTH,
 	.dst_info.data_width = STEDMA40_WORD_WIDTH,
 };
@@ -172,8 +168,7 @@ struct mmci_platform_data mop500_sdi1_data = {
 struct stedma40_chan_cfg mop500_sdi2_dma_cfg_rx = {
 	.mode = STEDMA40_MODE_LOGICAL,
 	.dir = STEDMA40_PERIPH_TO_MEM,
-	.src_dev_type =  DB8500_DMA_DEV28_SD_MM2_RX,
-	.dst_dev_type = STEDMA40_DEV_DST_MEMORY,
+	.dev_type =  DB8500_DMA_DEV28_SD_MM2,
 	.src_info.data_width = STEDMA40_WORD_WIDTH,
 	.dst_info.data_width = STEDMA40_WORD_WIDTH,
 };
@@ -181,8 +176,7 @@ struct stedma40_chan_cfg mop500_sdi2_dma_cfg_rx = {
 static struct stedma40_chan_cfg mop500_sdi2_dma_cfg_tx = {
 	.mode = STEDMA40_MODE_LOGICAL,
 	.dir = STEDMA40_MEM_TO_PERIPH,
-	.src_dev_type = STEDMA40_DEV_SRC_MEMORY,
-	.dst_dev_type = DB8500_DMA_DEV28_SD_MM2_TX,
+	.dev_type = DB8500_DMA_DEV28_SD_MM2,
 	.src_info.data_width = STEDMA40_WORD_WIDTH,
 	.dst_info.data_width = STEDMA40_WORD_WIDTH,
 };
@@ -210,8 +204,7 @@ struct mmci_platform_data mop500_sdi2_data = {
 struct stedma40_chan_cfg mop500_sdi4_dma_cfg_rx = {
 	.mode = STEDMA40_MODE_LOGICAL,
 	.dir = STEDMA40_PERIPH_TO_MEM,
-	.src_dev_type =  DB8500_DMA_DEV42_SD_MM4_RX,
-	.dst_dev_type = STEDMA40_DEV_DST_MEMORY,
+	.dev_type =  DB8500_DMA_DEV42_SD_MM4,
 	.src_info.data_width = STEDMA40_WORD_WIDTH,
 	.dst_info.data_width = STEDMA40_WORD_WIDTH,
 };
@@ -219,8 +212,7 @@ struct stedma40_chan_cfg mop500_sdi4_dma_cfg_rx = {
 static struct stedma40_chan_cfg mop500_sdi4_dma_cfg_tx = {
 	.mode = STEDMA40_MODE_LOGICAL,
 	.dir = STEDMA40_MEM_TO_PERIPH,
-	.src_dev_type = STEDMA40_DEV_SRC_MEMORY,
-	.dst_dev_type = DB8500_DMA_DEV42_SD_MM4_TX,
+	.dev_type = DB8500_DMA_DEV42_SD_MM4,
 	.src_info.data_width = STEDMA40_WORD_WIDTH,
 	.dst_info.data_width = STEDMA40_WORD_WIDTH,
 };
diff --git a/arch/arm/mach-ux500/board-mop500.c b/arch/arm/mach-ux500/board-mop500.c
index 87d2d7b..a8b3ad9 100644
--- a/arch/arm/mach-ux500/board-mop500.c
+++ b/arch/arm/mach-ux500/board-mop500.c
@@ -452,8 +452,7 @@ void mop500_snowball_ethernet_clock_enable(void)
 static struct cryp_platform_data u8500_cryp1_platform_data = {
 		.mem_to_engine = {
 				.dir = STEDMA40_MEM_TO_PERIPH,
-				.src_dev_type = STEDMA40_DEV_SRC_MEMORY,
-				.dst_dev_type = DB8500_DMA_DEV48_CAC1_TX,
+				.dev_type = DB8500_DMA_DEV48_CAC1,
 				.src_info.data_width = STEDMA40_WORD_WIDTH,
 				.dst_info.data_width = STEDMA40_WORD_WIDTH,
 				.mode = STEDMA40_MODE_LOGICAL,
@@ -462,8 +461,7 @@ static struct cryp_platform_data u8500_cryp1_platform_data = {
 		},
 		.engine_to_mem = {
 				.dir = STEDMA40_PERIPH_TO_MEM,
-				.src_dev_type = DB8500_DMA_DEV48_CAC1_RX,
-				.dst_dev_type = STEDMA40_DEV_DST_MEMORY,
+				.dev_type = DB8500_DMA_DEV48_CAC1,
 				.src_info.data_width = STEDMA40_WORD_WIDTH,
 				.dst_info.data_width = STEDMA40_WORD_WIDTH,
 				.mode = STEDMA40_MODE_LOGICAL,
@@ -474,8 +472,7 @@ static struct cryp_platform_data u8500_cryp1_platform_data = {
 
 static struct stedma40_chan_cfg u8500_hash_dma_cfg_tx = {
 		.dir = STEDMA40_MEM_TO_PERIPH,
-		.src_dev_type = STEDMA40_DEV_SRC_MEMORY,
-		.dst_dev_type = DB8500_DMA_DEV50_HAC1_TX,
+		.dev_type = DB8500_DMA_DEV50_HAC1_TX,
 		.src_info.data_width = STEDMA40_WORD_WIDTH,
 		.dst_info.data_width = STEDMA40_WORD_WIDTH,
 		.mode = STEDMA40_MODE_LOGICAL,
@@ -497,8 +494,7 @@ static struct platform_device *mop500_platform_devs[] __initdata = {
 static struct stedma40_chan_cfg ssp0_dma_cfg_rx = {
 	.mode = STEDMA40_MODE_LOGICAL,
 	.dir = STEDMA40_PERIPH_TO_MEM,
-	.src_dev_type =  DB8500_DMA_DEV8_SSP0_RX,
-	.dst_dev_type = STEDMA40_DEV_DST_MEMORY,
+	.dev_type = DB8500_DMA_DEV8_SSP0,
 	.src_info.data_width = STEDMA40_BYTE_WIDTH,
 	.dst_info.data_width = STEDMA40_BYTE_WIDTH,
 };
@@ -506,8 +502,7 @@ static struct stedma40_chan_cfg ssp0_dma_cfg_rx = {
 static struct stedma40_chan_cfg ssp0_dma_cfg_tx = {
 	.mode = STEDMA40_MODE_LOGICAL,
 	.dir = STEDMA40_MEM_TO_PERIPH,
-	.src_dev_type = STEDMA40_DEV_SRC_MEMORY,
-	.dst_dev_type = DB8500_DMA_DEV8_SSP0_TX,
+	.dev_type = DB8500_DMA_DEV8_SSP0,
 	.src_info.data_width = STEDMA40_BYTE_WIDTH,
 	.dst_info.data_width = STEDMA40_BYTE_WIDTH,
 };
@@ -538,8 +533,7 @@ static void __init mop500_spi_init(struct device *parent)
 static struct stedma40_chan_cfg uart0_dma_cfg_rx = {
 	.mode = STEDMA40_MODE_LOGICAL,
 	.dir = STEDMA40_PERIPH_TO_MEM,
-	.src_dev_type =  DB8500_DMA_DEV13_UART0_RX,
-	.dst_dev_type = STEDMA40_DEV_DST_MEMORY,
+	.dev_type = DB8500_DMA_DEV13_UART0,
 	.src_info.data_width = STEDMA40_BYTE_WIDTH,
 	.dst_info.data_width = STEDMA40_BYTE_WIDTH,
 };
@@ -547,8 +541,7 @@ static struct stedma40_chan_cfg uart0_dma_cfg_rx = {
 static struct stedma40_chan_cfg uart0_dma_cfg_tx = {
 	.mode = STEDMA40_MODE_LOGICAL,
 	.dir = STEDMA40_MEM_TO_PERIPH,
-	.src_dev_type = STEDMA40_DEV_SRC_MEMORY,
-	.dst_dev_type = DB8500_DMA_DEV13_UART0_TX,
+	.dev_type = DB8500_DMA_DEV13_UART0,
 	.src_info.data_width = STEDMA40_BYTE_WIDTH,
 	.dst_info.data_width = STEDMA40_BYTE_WIDTH,
 };
@@ -556,8 +549,7 @@ static struct stedma40_chan_cfg uart0_dma_cfg_tx = {
 static struct stedma40_chan_cfg uart1_dma_cfg_rx = {
 	.mode = STEDMA40_MODE_LOGICAL,
 	.dir = STEDMA40_PERIPH_TO_MEM,
-	.src_dev_type =  DB8500_DMA_DEV12_UART1_RX,
-	.dst_dev_type = STEDMA40_DEV_DST_MEMORY,
+	.dev_type = DB8500_DMA_DEV12_UART1,
 	.src_info.data_width = STEDMA40_BYTE_WIDTH,
 	.dst_info.data_width = STEDMA40_BYTE_WIDTH,
 };
@@ -565,8 +557,7 @@ static struct stedma40_chan_cfg uart1_dma_cfg_rx = {
 static struct stedma40_chan_cfg uart1_dma_cfg_tx = {
 	.mode = STEDMA40_MODE_LOGICAL,
 	.dir = STEDMA40_MEM_TO_PERIPH,
-	.src_dev_type = STEDMA40_DEV_SRC_MEMORY,
-	.dst_dev_type = DB8500_DMA_DEV12_UART1_TX,
+	.dev_type = DB8500_DMA_DEV12_UART1,
 	.src_info.data_width = STEDMA40_BYTE_WIDTH,
 	.dst_info.data_width = STEDMA40_BYTE_WIDTH,
 };
@@ -574,8 +565,7 @@ static struct stedma40_chan_cfg uart1_dma_cfg_tx = {
 static struct stedma40_chan_cfg uart2_dma_cfg_rx = {
 	.mode = STEDMA40_MODE_LOGICAL,
 	.dir = STEDMA40_PERIPH_TO_MEM,
-	.src_dev_type =  DB8500_DMA_DEV11_UART2_RX,
-	.dst_dev_type = STEDMA40_DEV_DST_MEMORY,
+	.dev_type = DB8500_DMA_DEV11_UART2,
 	.src_info.data_width = STEDMA40_BYTE_WIDTH,
 	.dst_info.data_width = STEDMA40_BYTE_WIDTH,
 };
@@ -583,8 +573,7 @@ static struct stedma40_chan_cfg uart2_dma_cfg_rx = {
 static struct stedma40_chan_cfg uart2_dma_cfg_tx = {
 	.mode = STEDMA40_MODE_LOGICAL,
 	.dir = STEDMA40_MEM_TO_PERIPH,
-	.src_dev_type = STEDMA40_DEV_SRC_MEMORY,
-	.dst_dev_type = DB8500_DMA_DEV11_UART2_TX,
+	.dev_type = DB8500_DMA_DEV11_UART2,
 	.src_info.data_width = STEDMA40_BYTE_WIDTH,
 	.dst_info.data_width = STEDMA40_BYTE_WIDTH,
 };
diff --git a/arch/arm/mach-ux500/cpu-db8500.c b/arch/arm/mach-ux500/cpu-db8500.c
index e027865..f72cc9b 100644
--- a/arch/arm/mach-ux500/cpu-db8500.c
+++ b/arch/arm/mach-ux500/cpu-db8500.c
@@ -167,25 +167,25 @@ static void __init db8500_add_gpios(struct device *parent)
 }
 
 static int usb_db8500_rx_dma_cfg[] = {
-	DB8500_DMA_DEV38_USB_OTG_IEP_1_9,
-	DB8500_DMA_DEV37_USB_OTG_IEP_2_10,
-	DB8500_DMA_DEV36_USB_OTG_IEP_3_11,
-	DB8500_DMA_DEV19_USB_OTG_IEP_4_12,
-	DB8500_DMA_DEV18_USB_OTG_IEP_5_13,
-	DB8500_DMA_DEV17_USB_OTG_IEP_6_14,
-	DB8500_DMA_DEV16_USB_OTG_IEP_7_15,
-	DB8500_DMA_DEV39_USB_OTG_IEP_8
+	DB8500_DMA_DEV38_USB_OTG_IEP_AND_OEP_1_9,
+	DB8500_DMA_DEV37_USB_OTG_IEP_AND_OEP_2_10,
+	DB8500_DMA_DEV36_USB_OTG_IEP_AND_OEP_3_11,
+	DB8500_DMA_DEV19_USB_OTG_IEP_AND_OEP_4_12,
+	DB8500_DMA_DEV18_USB_OTG_IEP_AND_OEP_5_13,
+	DB8500_DMA_DEV17_USB_OTG_IEP_AND_OEP_6_14,
+	DB8500_DMA_DEV16_USB_OTG_IEP_AND_OEP_7_15,
+	DB8500_DMA_DEV39_USB_OTG_IEP_AND_OEP_8
 };
 
 static int usb_db8500_tx_dma_cfg[] = {
-	DB8500_DMA_DEV38_USB_OTG_OEP_1_9,
-	DB8500_DMA_DEV37_USB_OTG_OEP_2_10,
-	DB8500_DMA_DEV36_USB_OTG_OEP_3_11,
-	DB8500_DMA_DEV19_USB_OTG_OEP_4_12,
-	DB8500_DMA_DEV18_USB_OTG_OEP_5_13,
-	DB8500_DMA_DEV17_USB_OTG_OEP_6_14,
-	DB8500_DMA_DEV16_USB_OTG_OEP_7_15,
-	DB8500_DMA_DEV39_USB_OTG_OEP_8
+	DB8500_DMA_DEV38_USB_OTG_IEP_AND_OEP_1_9,
+	DB8500_DMA_DEV37_USB_OTG_IEP_AND_OEP_2_10,
+	DB8500_DMA_DEV36_USB_OTG_IEP_AND_OEP_3_11,
+	DB8500_DMA_DEV19_USB_OTG_IEP_AND_OEP_4_12,
+	DB8500_DMA_DEV18_USB_OTG_IEP_AND_OEP_5_13,
+	DB8500_DMA_DEV17_USB_OTG_IEP_AND_OEP_6_14,
+	DB8500_DMA_DEV16_USB_OTG_IEP_AND_OEP_7_15,
+	DB8500_DMA_DEV39_USB_OTG_IEP_AND_OEP_8
 };
 
 static const char *db8500_read_soc_id(void)
diff --git a/arch/arm/mach-ux500/devices-db8500.c b/arch/arm/mach-ux500/devices-db8500.c
index 5b1f1f7..03efd4c1 100644
--- a/arch/arm/mach-ux500/devices-db8500.c
+++ b/arch/arm/mach-ux500/devices-db8500.c
@@ -50,74 +50,74 @@ static struct resource dma40_resources[] = {
  */
 static const dma_addr_t dma40_tx_map[DB8500_DMA_NR_DEV] = {
 	/* MUSB - these will be runtime-reconfigured */
-	[DB8500_DMA_DEV39_USB_OTG_OEP_8] = -1,
-	[DB8500_DMA_DEV16_USB_OTG_OEP_7_15] = -1,
-	[DB8500_DMA_DEV17_USB_OTG_OEP_6_14] = -1,
-	[DB8500_DMA_DEV18_USB_OTG_OEP_5_13] = -1,
-	[DB8500_DMA_DEV19_USB_OTG_OEP_4_12] = -1,
-	[DB8500_DMA_DEV36_USB_OTG_OEP_3_11] = -1,
-	[DB8500_DMA_DEV37_USB_OTG_OEP_2_10] = -1,
-	[DB8500_DMA_DEV38_USB_OTG_OEP_1_9] = -1,
+	[DB8500_DMA_DEV39_USB_OTG_IEP_AND_OEP_8] = -1,
+	[DB8500_DMA_DEV16_USB_OTG_IEP_AND_OEP_7_15] = -1,
+	[DB8500_DMA_DEV17_USB_OTG_IEP_AND_OEP_6_14] = -1,
+	[DB8500_DMA_DEV18_USB_OTG_IEP_AND_OEP_5_13] = -1,
+	[DB8500_DMA_DEV19_USB_OTG_IEP_AND_OEP_4_12] = -1,
+	[DB8500_DMA_DEV36_USB_OTG_IEP_AND_OEP_3_11] = -1,
+	[DB8500_DMA_DEV37_USB_OTG_IEP_AND_OEP_2_10] = -1,
+	[DB8500_DMA_DEV38_USB_OTG_IEP_AND_OEP_1_9] = -1,
 	/* PrimeCells - run-time configured */
-	[DB8500_DMA_DEV0_SPI0_TX] = -1,
-	[DB8500_DMA_DEV1_SD_MMC0_TX] = -1,
-	[DB8500_DMA_DEV2_SD_MMC1_TX] = -1,
-	[DB8500_DMA_DEV3_SD_MMC2_TX] = -1,
-	[DB8500_DMA_DEV8_SSP0_TX] = -1,
-	[DB8500_DMA_DEV9_SSP1_TX] = -1,
-	[DB8500_DMA_DEV11_UART2_TX] = -1,
-	[DB8500_DMA_DEV12_UART1_TX] = -1,
-	[DB8500_DMA_DEV13_UART0_TX] = -1,
-	[DB8500_DMA_DEV28_SD_MM2_TX] = -1,
-	[DB8500_DMA_DEV29_SD_MM0_TX] = -1,
-	[DB8500_DMA_DEV32_SD_MM1_TX] = -1,
-	[DB8500_DMA_DEV33_SPI2_TX] = -1,
-	[DB8500_DMA_DEV35_SPI1_TX] = -1,
-	[DB8500_DMA_DEV40_SPI3_TX] = -1,
-	[DB8500_DMA_DEV41_SD_MM3_TX] = -1,
-	[DB8500_DMA_DEV42_SD_MM4_TX] = -1,
-	[DB8500_DMA_DEV43_SD_MM5_TX] = -1,
-	[DB8500_DMA_DEV14_MSP2_TX] = U8500_MSP2_BASE + MSP_TX_RX_REG_OFFSET,
-	[DB8500_DMA_DEV30_MSP1_TX] = U8500_MSP1_BASE + MSP_TX_RX_REG_OFFSET,
-	[DB8500_DMA_DEV31_MSP0_TX_SLIM0_CH0_TX] = U8500_MSP0_BASE + MSP_TX_RX_REG_OFFSET,
-	[DB8500_DMA_DEV48_CAC1_TX] = U8500_CRYP1_BASE + CRYP1_TX_REG_OFFSET,
+	[DB8500_DMA_DEV0_SPI0] = -1,
+	[DB8500_DMA_DEV1_SD_MMC0] = -1,
+	[DB8500_DMA_DEV2_SD_MMC1] = -1,
+	[DB8500_DMA_DEV3_SD_MMC2] = -1,
+	[DB8500_DMA_DEV8_SSP0] = -1,
+	[DB8500_DMA_DEV9_SSP1] = -1,
+	[DB8500_DMA_DEV11_UART2] = -1,
+	[DB8500_DMA_DEV12_UART1] = -1,
+	[DB8500_DMA_DEV13_UART0] = -1,
+	[DB8500_DMA_DEV28_SD_MM2] = -1,
+	[DB8500_DMA_DEV29_SD_MM0] = -1,
+	[DB8500_DMA_DEV32_SD_MM1] = -1,
+	[DB8500_DMA_DEV33_SPI2] = -1,
+	[DB8500_DMA_DEV35_SPI1] = -1,
+	[DB8500_DMA_DEV40_SPI3] = -1,
+	[DB8500_DMA_DEV41_SD_MM3] = -1,
+	[DB8500_DMA_DEV42_SD_MM4] = -1,
+	[DB8500_DMA_DEV43_SD_MM5] = -1,
+	[DB8500_DMA_DEV14_MSP2] = U8500_MSP2_BASE + MSP_TX_RX_REG_OFFSET,
+	[DB8500_DMA_DEV30_MSP1] = U8500_MSP1_BASE + MSP_TX_RX_REG_OFFSET,
+	[DB8500_DMA_DEV31_MSP0_SLIM0_CH0] = U8500_MSP0_BASE + MSP_TX_RX_REG_OFFSET,
+	[DB8500_DMA_DEV48_CAC1] = U8500_CRYP1_BASE + CRYP1_TX_REG_OFFSET,
 	[DB8500_DMA_DEV50_HAC1_TX] = U8500_HASH1_BASE + HASH1_TX_REG_OFFSET,
 };
 
 /* Mapping between source event lines and physical device address */
 static const dma_addr_t dma40_rx_map[DB8500_DMA_NR_DEV] = {
 	/* MUSB - these will be runtime-reconfigured */
-	[DB8500_DMA_DEV39_USB_OTG_IEP_8] = -1,
-	[DB8500_DMA_DEV16_USB_OTG_IEP_7_15] = -1,
-	[DB8500_DMA_DEV17_USB_OTG_IEP_6_14] = -1,
-	[DB8500_DMA_DEV18_USB_OTG_IEP_5_13] = -1,
-	[DB8500_DMA_DEV19_USB_OTG_IEP_4_12] = -1,
-	[DB8500_DMA_DEV36_USB_OTG_IEP_3_11] = -1,
-	[DB8500_DMA_DEV37_USB_OTG_IEP_2_10] = -1,
-	[DB8500_DMA_DEV38_USB_OTG_IEP_1_9] = -1,
+	[DB8500_DMA_DEV39_USB_OTG_IEP_AND_OEP_8] = -1,
+	[DB8500_DMA_DEV16_USB_OTG_IEP_AND_OEP_7_15] = -1,
+	[DB8500_DMA_DEV17_USB_OTG_IEP_AND_OEP_6_14] = -1,
+	[DB8500_DMA_DEV18_USB_OTG_IEP_AND_OEP_5_13] = -1,
+	[DB8500_DMA_DEV19_USB_OTG_IEP_AND_OEP_4_12] = -1,
+	[DB8500_DMA_DEV36_USB_OTG_IEP_AND_OEP_3_11] = -1,
+	[DB8500_DMA_DEV37_USB_OTG_IEP_AND_OEP_2_10] = -1,
+	[DB8500_DMA_DEV38_USB_OTG_IEP_AND_OEP_1_9] = -1,
 	/* PrimeCells */
-	[DB8500_DMA_DEV0_SPI0_RX] = -1,
-	[DB8500_DMA_DEV1_SD_MMC0_RX] = -1,
-	[DB8500_DMA_DEV2_SD_MMC1_RX] = -1,
-	[DB8500_DMA_DEV3_SD_MMC2_RX] = -1,
-	[DB8500_DMA_DEV8_SSP0_RX] = -1,
-	[DB8500_DMA_DEV9_SSP1_RX] = -1,
-	[DB8500_DMA_DEV11_UART2_RX] = -1,
-	[DB8500_DMA_DEV12_UART1_RX] = -1,
-	[DB8500_DMA_DEV13_UART0_RX] = -1,
-	[DB8500_DMA_DEV28_SD_MM2_RX] = -1,
-	[DB8500_DMA_DEV29_SD_MM0_RX] = -1,
-	[DB8500_DMA_DEV32_SD_MM1_RX] = -1,
-	[DB8500_DMA_DEV33_SPI2_RX] = -1,
-	[DB8500_DMA_DEV35_SPI1_RX] = -1,
-	[DB8500_DMA_DEV40_SPI3_RX] = -1,
-	[DB8500_DMA_DEV41_SD_MM3_RX] = -1,
-	[DB8500_DMA_DEV42_SD_MM4_RX] = -1,
-	[DB8500_DMA_DEV43_SD_MM5_RX] = -1,
-	[DB8500_DMA_DEV14_MSP2_RX] = U8500_MSP2_BASE + MSP_TX_RX_REG_OFFSET,
-	[DB8500_DMA_DEV30_MSP3_RX] = U8500_MSP3_BASE + MSP_TX_RX_REG_OFFSET,
-	[DB8500_DMA_DEV31_MSP0_RX_SLIM0_CH0_RX] = U8500_MSP0_BASE + MSP_TX_RX_REG_OFFSET,
-	[DB8500_DMA_DEV48_CAC1_RX] = U8500_CRYP1_BASE + CRYP1_RX_REG_OFFSET,
+	[DB8500_DMA_DEV0_SPI0] = -1,
+	[DB8500_DMA_DEV1_SD_MMC0] = -1,
+	[DB8500_DMA_DEV2_SD_MMC1] = -1,
+	[DB8500_DMA_DEV3_SD_MMC2] = -1,
+	[DB8500_DMA_DEV8_SSP0] = -1,
+	[DB8500_DMA_DEV9_SSP1] = -1,
+	[DB8500_DMA_DEV11_UART2] = -1,
+	[DB8500_DMA_DEV12_UART1] = -1,
+	[DB8500_DMA_DEV13_UART0] = -1,
+	[DB8500_DMA_DEV28_SD_MM2] = -1,
+	[DB8500_DMA_DEV29_SD_MM0] = -1,
+	[DB8500_DMA_DEV32_SD_MM1] = -1,
+	[DB8500_DMA_DEV33_SPI2] = -1,
+	[DB8500_DMA_DEV35_SPI1] = -1,
+	[DB8500_DMA_DEV40_SPI3] = -1,
+	[DB8500_DMA_DEV41_SD_MM3] = -1,
+	[DB8500_DMA_DEV42_SD_MM4] = -1,
+	[DB8500_DMA_DEV43_SD_MM5] = -1,
+	[DB8500_DMA_DEV14_MSP2] = U8500_MSP2_BASE + MSP_TX_RX_REG_OFFSET,
+	[DB8500_DMA_DEV30_MSP3] = U8500_MSP3_BASE + MSP_TX_RX_REG_OFFSET,
+	[DB8500_DMA_DEV31_MSP0_SLIM0_CH0] = U8500_MSP0_BASE + MSP_TX_RX_REG_OFFSET,
+	[DB8500_DMA_DEV48_CAC1] = U8500_CRYP1_BASE + CRYP1_RX_REG_OFFSET,
 };
 
 static struct stedma40_platform_data dma40_plat_data = {
diff --git a/arch/arm/mach-ux500/ste-dma40-db8500.h b/arch/arm/mach-ux500/ste-dma40-db8500.h
index a616419..0296ae5 100644
--- a/arch/arm/mach-ux500/ste-dma40-db8500.h
+++ b/arch/arm/mach-ux500/ste-dma40-db8500.h
@@ -12,133 +12,74 @@
 
 #define DB8500_DMA_NR_DEV 64
 
-enum dma_src_dev_type {
-	DB8500_DMA_DEV0_SPI0_RX = 0,
-	DB8500_DMA_DEV1_SD_MMC0_RX = 1,
-	DB8500_DMA_DEV2_SD_MMC1_RX = 2,
-	DB8500_DMA_DEV3_SD_MMC2_RX = 3,
-	DB8500_DMA_DEV4_I2C1_RX = 4,
-	DB8500_DMA_DEV5_I2C3_RX = 5,
-	DB8500_DMA_DEV6_I2C2_RX = 6,
-	DB8500_DMA_DEV7_I2C4_RX = 7, /* Only on V1 and later */
-	DB8500_DMA_DEV8_SSP0_RX = 8,
-	DB8500_DMA_DEV9_SSP1_RX = 9,
-	DB8500_DMA_DEV10_MCDE_RX = 10,
-	DB8500_DMA_DEV11_UART2_RX = 11,
-	DB8500_DMA_DEV12_UART1_RX = 12,
-	DB8500_DMA_DEV13_UART0_RX = 13,
-	DB8500_DMA_DEV14_MSP2_RX = 14,
-	DB8500_DMA_DEV15_I2C0_RX = 15,
-	DB8500_DMA_DEV16_USB_OTG_IEP_7_15 = 16,
-	DB8500_DMA_DEV17_USB_OTG_IEP_6_14 = 17,
-	DB8500_DMA_DEV18_USB_OTG_IEP_5_13 = 18,
-	DB8500_DMA_DEV19_USB_OTG_IEP_4_12 = 19,
-	DB8500_DMA_DEV20_SLIM0_CH0_RX_HSI_RX_CH0 = 20,
-	DB8500_DMA_DEV21_SLIM0_CH1_RX_HSI_RX_CH1 = 21,
-	DB8500_DMA_DEV22_SLIM0_CH2_RX_HSI_RX_CH2 = 22,
-	DB8500_DMA_DEV23_SLIM0_CH3_RX_HSI_RX_CH3 = 23,
-	DB8500_DMA_DEV24_SRC_SXA0_RX_TX = 24,
-	DB8500_DMA_DEV25_SRC_SXA1_RX_TX = 25,
-	DB8500_DMA_DEV26_SRC_SXA2_RX_TX = 26,
-	DB8500_DMA_DEV27_SRC_SXA3_RX_TX = 27,
-	DB8500_DMA_DEV28_SD_MM2_RX = 28,
-	DB8500_DMA_DEV29_SD_MM0_RX = 29,
-	DB8500_DMA_DEV30_MSP1_RX = 30,
+/*
+ * Unless otherwise specified, all channels numbers are used for
+ * TX & RX, and can be used for either source or destination
+ * channels.
+ */
+enum dma_dev_type {
+	DB8500_DMA_DEV0_SPI0 = 0,
+	DB8500_DMA_DEV1_SD_MMC0 = 1,
+	DB8500_DMA_DEV2_SD_MMC1 = 2,
+	DB8500_DMA_DEV3_SD_MMC2 = 3,
+	DB8500_DMA_DEV4_I2C1 = 4,
+	DB8500_DMA_DEV5_I2C3 = 5,
+	DB8500_DMA_DEV6_I2C2 = 6,
+	DB8500_DMA_DEV7_I2C4 = 7,			/* Only on V1 and later */
+	DB8500_DMA_DEV8_SSP0 = 8,
+	DB8500_DMA_DEV9_SSP1 = 9,
+	DB8500_DMA_DEV10_MCDE_RX = 10,			/* RX only */
+	DB8500_DMA_DEV11_UART2 = 11,
+	DB8500_DMA_DEV12_UART1 = 12,
+	DB8500_DMA_DEV13_UART0 = 13,
+	DB8500_DMA_DEV14_MSP2 = 14,
+	DB8500_DMA_DEV15_I2C0 = 15,
+	DB8500_DMA_DEV16_USB_OTG_IEP_AND_OEP_7_15 = 16,
+	DB8500_DMA_DEV17_USB_OTG_IEP_AND_OEP_6_14 = 17,
+	DB8500_DMA_DEV18_USB_OTG_IEP_AND_OEP_5_13 = 18,
+	DB8500_DMA_DEV19_USB_OTG_IEP_AND_OEP_4_12 = 19,
+	DB8500_DMA_DEV20_SLIM0_CH0_HSI_CH0 = 20,
+	DB8500_DMA_DEV21_SLIM0_CH1_HSI_CH1 = 21,
+	DB8500_DMA_DEV22_SLIM0_CH2_HSI_CH2 = 22,
+	DB8500_DMA_DEV23_SLIM0_CH3_HSI_CH3 = 23,
+	DB8500_DMA_DEV24_SXA0 = 24,
+	DB8500_DMA_DEV25_SXA1 = 25,
+	DB8500_DMA_DEV26_SXA2 = 26,
+	DB8500_DMA_DEV27_SXA3 = 27,
+	DB8500_DMA_DEV28_SD_MM2 = 28,
+	DB8500_DMA_DEV29_SD_MM0 = 29,
+	DB8500_DMA_DEV30_MSP1 = 30,
 	/* On DB8500v2, MSP3 RX replaces MSP1 RX */
-	DB8500_DMA_DEV30_MSP3_RX = 30,
-	DB8500_DMA_DEV31_MSP0_RX_SLIM0_CH0_RX = 31,
-	DB8500_DMA_DEV32_SD_MM1_RX = 32,
-	DB8500_DMA_DEV33_SPI2_RX = 33,
-	DB8500_DMA_DEV34_I2C3_RX2 = 34,
-	DB8500_DMA_DEV35_SPI1_RX = 35,
-	DB8500_DMA_DEV36_USB_OTG_IEP_3_11 = 36,
-	DB8500_DMA_DEV37_USB_OTG_IEP_2_10 = 37,
-	DB8500_DMA_DEV38_USB_OTG_IEP_1_9 = 38,
-	DB8500_DMA_DEV39_USB_OTG_IEP_8 = 39,
-	DB8500_DMA_DEV40_SPI3_RX = 40,
-	DB8500_DMA_DEV41_SD_MM3_RX = 41,
-	DB8500_DMA_DEV42_SD_MM4_RX = 42,
-	DB8500_DMA_DEV43_SD_MM5_RX = 43,
-	DB8500_DMA_DEV44_SRC_SXA4_RX_TX = 44,
-	DB8500_DMA_DEV45_SRC_SXA5_RX_TX = 45,
-	DB8500_DMA_DEV46_SLIM0_CH8_RX_SRC_SXA6_RX_TX = 46,
-	DB8500_DMA_DEV47_SLIM0_CH9_RX_SRC_SXA7_RX_TX = 47,
-	DB8500_DMA_DEV48_CAC1_RX = 48,
-	/* 49, 50 and 51 are not used */
-	DB8500_DMA_DEV52_SLIM0_CH4_RX_HSI_RX_CH4 = 52,
-	DB8500_DMA_DEV53_SLIM0_CH5_RX_HSI_RX_CH5 = 53,
-	DB8500_DMA_DEV54_SLIM0_CH6_RX_HSI_RX_CH6 = 54,
-	DB8500_DMA_DEV55_SLIM0_CH7_RX_HSI_RX_CH7 = 55,
-	/* 56, 57, 58, 59 and 60 are not used */
-	DB8500_DMA_DEV61_CAC0_RX = 61,
-	/* 62 and 63 are not used */
-};
-
-enum dma_dest_dev_type {
-	DB8500_DMA_DEV0_SPI0_TX = 0,
-	DB8500_DMA_DEV1_SD_MMC0_TX = 1,
-	DB8500_DMA_DEV2_SD_MMC1_TX = 2,
-	DB8500_DMA_DEV3_SD_MMC2_TX = 3,
-	DB8500_DMA_DEV4_I2C1_TX = 4,
-	DB8500_DMA_DEV5_I2C3_TX = 5,
-	DB8500_DMA_DEV6_I2C2_TX = 6,
-	DB8500_DMA_DEV7_I2C4_TX = 7, /* Only on V1 and later */
-	DB8500_DMA_DEV8_SSP0_TX = 8,
-	DB8500_DMA_DEV9_SSP1_TX = 9,
-	/* 10 is not used*/
-	DB8500_DMA_DEV11_UART2_TX = 11,
-	DB8500_DMA_DEV12_UART1_TX = 12,
-	DB8500_DMA_DEV13_UART0_TX = 13,
-	DB8500_DMA_DEV14_MSP2_TX = 14,
-	DB8500_DMA_DEV15_I2C0_TX = 15,
-	DB8500_DMA_DEV16_USB_OTG_OEP_7_15 = 16,
-	DB8500_DMA_DEV17_USB_OTG_OEP_6_14 = 17,
-	DB8500_DMA_DEV18_USB_OTG_OEP_5_13 = 18,
-	DB8500_DMA_DEV19_USB_OTG_OEP_4_12 = 19,
-	DB8500_DMA_DEV20_SLIM0_CH0_TX_HSI_TX_CH0 = 20,
-	DB8500_DMA_DEV21_SLIM0_CH1_TX_HSI_TX_CH1 = 21,
-	DB8500_DMA_DEV22_SLIM0_CH2_TX_HSI_TX_CH2 = 22,
-	DB8500_DMA_DEV23_SLIM0_CH3_TX_HSI_TX_CH3 = 23,
-	DB8500_DMA_DEV24_DST_SXA0_RX_TX = 24,
-	DB8500_DMA_DEV25_DST_SXA1_RX_TX = 25,
-	DB8500_DMA_DEV26_DST_SXA2_RX_TX = 26,
-	DB8500_DMA_DEV27_DST_SXA3_RX_TX = 27,
-	DB8500_DMA_DEV28_SD_MM2_TX = 28,
-	DB8500_DMA_DEV29_SD_MM0_TX = 29,
-	DB8500_DMA_DEV30_MSP1_TX = 30,
-	DB8500_DMA_DEV31_MSP0_TX_SLIM0_CH0_TX = 31,
-	DB8500_DMA_DEV32_SD_MM1_TX = 32,
-	DB8500_DMA_DEV33_SPI2_TX = 33,
-	DB8500_DMA_DEV34_I2C3_TX2 = 34,
-	DB8500_DMA_DEV35_SPI1_TX = 35,
-	DB8500_DMA_DEV36_USB_OTG_OEP_3_11 = 36,
-	DB8500_DMA_DEV37_USB_OTG_OEP_2_10 = 37,
-	DB8500_DMA_DEV38_USB_OTG_OEP_1_9 = 38,
-	DB8500_DMA_DEV39_USB_OTG_OEP_8 = 39,
-	DB8500_DMA_DEV40_SPI3_TX = 40,
-	DB8500_DMA_DEV41_SD_MM3_TX = 41,
-	DB8500_DMA_DEV42_SD_MM4_TX = 42,
-	DB8500_DMA_DEV43_SD_MM5_TX = 43,
-	DB8500_DMA_DEV44_DST_SXA4_RX_TX = 44,
-	DB8500_DMA_DEV45_DST_SXA5_RX_TX = 45,
-	DB8500_DMA_DEV46_SLIM0_CH8_TX_DST_SXA6_RX_TX = 46,
-	DB8500_DMA_DEV47_SLIM0_CH9_TX_DST_SXA7_RX_TX = 47,
-	DB8500_DMA_DEV48_CAC1_TX  = 48,
-	DB8500_DMA_DEV49_CAC1_TX_HAC1_TX = 49,
-	DB8500_DMA_DEV50_HAC1_TX = 50,
-	DB8500_DMA_MEMCPY_TX_0 = 51,
-	DB8500_DMA_DEV52_SLIM1_CH4_TX_HSI_TX_CH4 = 52,
-	DB8500_DMA_DEV53_SLIM1_CH5_TX_HSI_TX_CH5 = 53,
-	DB8500_DMA_DEV54_SLIM1_CH6_TX_HSI_TX_CH6 = 54,
-	DB8500_DMA_DEV55_SLIM1_CH7_TX_HSI_TX_CH7 = 55,
-	DB8500_DMA_MEMCPY_TX_1 = 56,
-	DB8500_DMA_MEMCPY_TX_2 = 57,
-	DB8500_DMA_MEMCPY_TX_3 = 58,
-	DB8500_DMA_MEMCPY_TX_4 = 59,
-	DB8500_DMA_MEMCPY_TX_5 = 60,
-	DB8500_DMA_DEV61_CAC0_TX = 61,
-	DB8500_DMA_DEV62_CAC0_TX_HAC0_TX = 62,
-	DB8500_DMA_DEV63_HAC0_TX = 63,
+	DB8500_DMA_DEV30_MSP3 = 30,
+	DB8500_DMA_DEV31_MSP0_SLIM0_CH0 = 31,
+	DB8500_DMA_DEV32_SD_MM1 = 32,
+	DB8500_DMA_DEV33_SPI2 = 33,
+	DB8500_DMA_DEV34_I2C3_RX2_TX2 = 34,
+	DB8500_DMA_DEV35_SPI1 = 35,
+	DB8500_DMA_DEV36_USB_OTG_IEP_AND_OEP_3_11 = 36,
+	DB8500_DMA_DEV37_USB_OTG_IEP_AND_OEP_2_10 = 37,
+	DB8500_DMA_DEV38_USB_OTG_IEP_AND_OEP_1_9 = 38,
+	DB8500_DMA_DEV39_USB_OTG_IEP_AND_OEP_8 = 39,
+	DB8500_DMA_DEV40_SPI3 = 40,
+	DB8500_DMA_DEV41_SD_MM3 = 41,
+	DB8500_DMA_DEV42_SD_MM4 = 42,
+	DB8500_DMA_DEV43_SD_MM5 = 43,
+	DB8500_DMA_DEV44_SXA4 = 44,
+	DB8500_DMA_DEV45_SXA5 = 45,
+	DB8500_DMA_DEV46_SLIM0_CH8_SRC_SXA6 = 46,
+	DB8500_DMA_DEV47_SLIM0_CH9_SRC_SXA7 = 47,
+	DB8500_DMA_DEV48_CAC1 = 48,
+	DB8500_DMA_DEV49_CAC1_TX_HAC1_TX = 49,		/* TX only */
+	DB8500_DMA_DEV50_HAC1_TX = 50,			/* TX only */
+	DB8500_DMA_MEMCPY_TX_0 = 51,			/* TX only */
+	DB8500_DMA_DEV52_SLIM0_CH4_HSI_CH4 = 52,
+	DB8500_DMA_DEV53_SLIM0_CH5_HSI_CH5 = 53,
+	DB8500_DMA_DEV54_SLIM0_CH6_HSI_CH6 = 54,
+	DB8500_DMA_DEV55_SLIM0_CH7_HSI_CH7 = 55,
+	/* 56 -> 60 are channels reserved for memcpy only */
+	DB8500_DMA_DEV61_CAC0 = 61,
+	DB8500_DMA_DEV62_CAC0_TX_HAC0_TX = 62,		/* TX only */
+	DB8500_DMA_DEV63_HAC0_TX = 63,			/* TX only */
 };
 
 #endif
diff --git a/arch/arm/mach-ux500/usb.c b/arch/arm/mach-ux500/usb.c
index 78ac65f..e0ea490 100644
--- a/arch/arm/mach-ux500/usb.c
+++ b/arch/arm/mach-ux500/usb.c
@@ -15,7 +15,6 @@
 #define MUSB_DMA40_RX_CH { \
 		.mode = STEDMA40_MODE_LOGICAL, \
 		.dir = STEDMA40_PERIPH_TO_MEM, \
-		.dst_dev_type = STEDMA40_DEV_DST_MEMORY, \
 		.src_info.data_width = STEDMA40_WORD_WIDTH, \
 		.dst_info.data_width = STEDMA40_WORD_WIDTH, \
 		.src_info.psize = STEDMA40_PSIZE_LOG_16, \
@@ -25,7 +24,6 @@
 #define MUSB_DMA40_TX_CH { \
 		.mode = STEDMA40_MODE_LOGICAL, \
 		.dir = STEDMA40_MEM_TO_PERIPH, \
-		.src_dev_type = STEDMA40_DEV_SRC_MEMORY, \
 		.src_info.data_width = STEDMA40_WORD_WIDTH, \
 		.dst_info.data_width = STEDMA40_WORD_WIDTH, \
 		.src_info.psize = STEDMA40_PSIZE_LOG_16, \
@@ -125,20 +123,20 @@ struct platform_device ux500_musb_device = {
 	.resource = usb_resources,
 };
 
-static inline void ux500_usb_dma_update_rx_ch_config(int *src_dev_type)
+static inline void ux500_usb_dma_update_rx_ch_config(int *dev_type)
 {
 	u32 idx;
 
 	for (idx = 0; idx < UX500_MUSB_DMA_NUM_RX_CHANNELS; idx++)
-		musb_dma_rx_ch[idx].src_dev_type = src_dev_type[idx];
+		musb_dma_rx_ch[idx].dev_type = dev_type[idx];
 }
 
-static inline void ux500_usb_dma_update_tx_ch_config(int *dst_dev_type)
+static inline void ux500_usb_dma_update_tx_ch_config(int *dev_type)
 {
 	u32 idx;
 
 	for (idx = 0; idx < UX500_MUSB_DMA_NUM_TX_CHANNELS; idx++)
-		musb_dma_tx_ch[idx].dst_dev_type = dst_dev_type[idx];
+		musb_dma_tx_ch[idx].dev_type = dev_type[idx];
 }
 
 void ux500_add_usb(struct device *parent, resource_size_t base, int irq,
diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index 7b96e75..67b9d57 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -28,10 +28,6 @@
 
 #define D40_PHY_CHAN -1
 
-/* For masking out/in 2 bit channel positions */
-#define D40_CHAN_POS(chan)  (2 * (chan / 2))
-#define D40_CHAN_POS_MASK(chan) (0x3 << D40_CHAN_POS(chan))
-
 /* Maximum iterations taken before giving up suspending a channel */
 #define D40_SUSPEND_MAX_IT 500
 
@@ -55,6 +51,10 @@
 
 #define MAX(a, b) (((a) < (b)) ? (b) : (a))
 
+#define D40_IS_SRC(dir) (dir == STEDMA40_PERIPH_TO_MEM) : true : false;
+#define D40_IS_DST(dir) ((dir == STEDMA40_MEM_TO_PERIPH) || \
+			 (dir == STEDMA40_MEM_TO_MEM)) : true : false;
+
 /* Reserved event lines for memcpy only. */
 static int dma40_memcpy_channels[] = { 56, 57, 58, 59, 60 };
 
@@ -1288,21 +1288,17 @@ static void __d40_config_set_event(struct d40_chan *d40c,
 static void d40_config_set_event(struct d40_chan *d40c,
 				 enum d40_events event_type)
 {
+	u32 event = D40_TYPE_TO_EVENT(d40c->dma_cfg.dev_type);
+
 	/* Enable event line connected to device (or memcpy) */
 	if ((d40c->dma_cfg.dir ==  STEDMA40_PERIPH_TO_MEM) ||
-	    (d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_PERIPH)) {
-		u32 event = D40_TYPE_TO_EVENT(d40c->dma_cfg.src_dev_type);
-
+	    (d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_PERIPH))
 		__d40_config_set_event(d40c, event_type, event,
 				       D40_CHAN_REG_SSLNK);
-	}
-
-	if (d40c->dma_cfg.dir !=  STEDMA40_PERIPH_TO_MEM) {
-		u32 event = D40_TYPE_TO_EVENT(d40c->dma_cfg.dst_dev_type);
 
+	if (d40c->dma_cfg.dir !=  STEDMA40_PERIPH_TO_MEM)
 		__d40_config_set_event(d40c, event_type, event,
 				       D40_CHAN_REG_SDLNK);
-	}
 }
 
 static u32 d40_chan_has_events(struct d40_chan *d40c)
@@ -1744,8 +1740,6 @@ static int d40_validate_conf(struct d40_chan *d40c,
 			     struct stedma40_chan_cfg *conf)
 {
 	int res = 0;
-	u32 dst_event_group = D40_TYPE_TO_GROUP(conf->dst_dev_type);
-	u32 src_event_group = D40_TYPE_TO_GROUP(conf->src_dev_type);
 	bool is_log = conf->mode == STEDMA40_MODE_LOGICAL;
 
 	if (!conf->dir) {
@@ -1753,44 +1747,24 @@ static int d40_validate_conf(struct d40_chan *d40c,
 		res = -EINVAL;
 	}
 
-	if (conf->dst_dev_type != STEDMA40_DEV_DST_MEMORY &&
-	    d40c->base->plat_data->dev_tx[conf->dst_dev_type] == 0 &&
-	    d40c->runtime_addr == 0) {
-
-		chan_err(d40c, "Invalid TX channel address (%d)\n",
-			 conf->dst_dev_type);
-		res = -EINVAL;
-	}
-
-	if (conf->src_dev_type != STEDMA40_DEV_SRC_MEMORY &&
-	    d40c->base->plat_data->dev_rx[conf->src_dev_type] == 0 &&
-	    d40c->runtime_addr == 0) {
-		chan_err(d40c, "Invalid RX channel address (%d)\n",
-			conf->src_dev_type);
+	if ((conf->dev_type < 0) && is_log) {
+		chan_err(d40c, "Invalid device type\n");
 		res = -EINVAL;
 	}
 
 	if (conf->dir == STEDMA40_MEM_TO_PERIPH &&
-	    dst_event_group == STEDMA40_DEV_DST_MEMORY) {
-		chan_err(d40c, "Invalid dst\n");
+	    d40c->base->plat_data->dev_tx[conf->dev_type] == 0 &&
+	    d40c->runtime_addr == 0) {
+		chan_err(d40c, "Invalid TX channel address (%d)\n",
+			 conf->dev_type);
 		res = -EINVAL;
 	}
 
 	if (conf->dir == STEDMA40_PERIPH_TO_MEM &&
-	    src_event_group == STEDMA40_DEV_SRC_MEMORY) {
-		chan_err(d40c, "Invalid src\n");
-		res = -EINVAL;
-	}
-
-	if (src_event_group == STEDMA40_DEV_SRC_MEMORY &&
-	    dst_event_group == STEDMA40_DEV_DST_MEMORY && is_log) {
-		chan_err(d40c, "No event line\n");
-		res = -EINVAL;
-	}
-
-	if (conf->dir == STEDMA40_PERIPH_TO_PERIPH &&
-	    (src_event_group != dst_event_group)) {
-		chan_err(d40c, "Invalid event group\n");
+	    d40c->base->plat_data->dev_rx[conf->dev_type] == 0 &&
+	    d40c->runtime_addr == 0) {
+		chan_err(d40c, "Invalid RX channel address (%d)\n",
+			 conf->dev_type);
 		res = -EINVAL;
 	}
 
@@ -1911,7 +1885,7 @@ out:
 
 static int d40_allocate_channel(struct d40_chan *d40c, bool *first_phy_user)
 {
-	int dev_type;
+	int dev_type = d40c->dma_cfg.dev_type;
 	int event_group;
 	int event_line;
 	struct d40_phy_res *phys;
@@ -1926,13 +1900,11 @@ static int d40_allocate_channel(struct d40_chan *d40c, bool *first_phy_user)
 	num_phy_chans = d40c->base->num_phy_chans;
 
 	if (d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_MEM) {
-		dev_type = d40c->dma_cfg.src_dev_type;
 		log_num = 2 * dev_type;
 		is_src = true;
 	} else if (d40c->dma_cfg.dir == STEDMA40_MEM_TO_PERIPH ||
 		   d40c->dma_cfg.dir == STEDMA40_MEM_TO_MEM) {
 		/* dst event lines are used for logical memcpy */
-		dev_type = d40c->dma_cfg.dst_dev_type;
 		log_num = 2 * dev_type + 1;
 		is_src = false;
 	} else
@@ -2044,8 +2016,7 @@ static int d40_config_memcpy(struct d40_chan *d40c)
 
 	if (dma_has_cap(DMA_MEMCPY, cap) && !dma_has_cap(DMA_SLAVE, cap)) {
 		d40c->dma_cfg = dma40_memcpy_conf_log;
-		d40c->dma_cfg.src_dev_type = STEDMA40_DEV_SRC_MEMORY;
-		d40c->dma_cfg.dst_dev_type = dma40_memcpy_channels[d40c->chan.chan_id];
+		d40c->dma_cfg.dev_type = dma40_memcpy_channels[d40c->chan.chan_id];
 
 	} else if (dma_has_cap(DMA_MEMCPY, cap) &&
 		   dma_has_cap(DMA_SLAVE, cap)) {
@@ -2062,7 +2033,7 @@ static int d40_free_dma(struct d40_chan *d40c)
 {
 
 	int res = 0;
-	u32 event;
+	u32 event = D40_TYPE_TO_EVENT(d40c->dma_cfg.dev_type);
 	struct d40_phy_res *phy = d40c->phy_chan;
 	bool is_src;
 
@@ -2081,13 +2052,11 @@ static int d40_free_dma(struct d40_chan *d40c)
 	}
 
 	if (d40c->dma_cfg.dir == STEDMA40_MEM_TO_PERIPH ||
-	    d40c->dma_cfg.dir == STEDMA40_MEM_TO_MEM) {
-		event = D40_TYPE_TO_EVENT(d40c->dma_cfg.dst_dev_type);
+	    d40c->dma_cfg.dir == STEDMA40_MEM_TO_MEM)
 		is_src = false;
-	} else if (d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_MEM) {
-		event = D40_TYPE_TO_EVENT(d40c->dma_cfg.src_dev_type);
+	else if (d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_MEM)
 		is_src = true;
-	} else {
+	else {
 		chan_err(d40c, "Unknown direction\n");
 		return -EINVAL;
 	}
@@ -2128,7 +2097,7 @@ static bool d40_is_paused(struct d40_chan *d40c)
 	unsigned long flags;
 	void __iomem *active_reg;
 	u32 status;
-	u32 event;
+	u32 event = D40_TYPE_TO_EVENT(d40c->dma_cfg.dev_type);
 
 	spin_lock_irqsave(&d40c->lock, flags);
 
@@ -2149,10 +2118,8 @@ static bool d40_is_paused(struct d40_chan *d40c)
 
 	if (d40c->dma_cfg.dir == STEDMA40_MEM_TO_PERIPH ||
 	    d40c->dma_cfg.dir == STEDMA40_MEM_TO_MEM) {
-		event = D40_TYPE_TO_EVENT(d40c->dma_cfg.dst_dev_type);
 		status = readl(chanbase + D40_CHAN_REG_SDLNK);
 	} else if (d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_MEM) {
-		event = D40_TYPE_TO_EVENT(d40c->dma_cfg.src_dev_type);
 		status = readl(chanbase + D40_CHAN_REG_SSLNK);
 	} else {
 		chan_err(d40c, "Unknown direction\n");
@@ -2294,9 +2261,9 @@ d40_get_dev_addr(struct d40_chan *chan, enum dma_transfer_direction direction)
 		return chan->runtime_addr;
 
 	if (direction == DMA_DEV_TO_MEM)
-		addr = plat->dev_rx[cfg->src_dev_type];
+		addr = plat->dev_rx[cfg->dev_type];
 	else if (direction == DMA_MEM_TO_DEV)
-		addr = plat->dev_tx[cfg->dst_dev_type];
+		addr = plat->dev_tx[cfg->dev_type];
 
 	return addr;
 }
@@ -2427,11 +2394,11 @@ static void d40_set_prio_realtime(struct d40_chan *d40c)
 
 	if ((d40c->dma_cfg.dir ==  STEDMA40_PERIPH_TO_MEM) ||
 	    (d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_PERIPH))
-		__d40_set_prio_rt(d40c, d40c->dma_cfg.src_dev_type, true);
+		__d40_set_prio_rt(d40c, d40c->dma_cfg.dev_type, true);
 
 	if ((d40c->dma_cfg.dir ==  STEDMA40_MEM_TO_PERIPH) ||
 	    (d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_PERIPH))
-		__d40_set_prio_rt(d40c, d40c->dma_cfg.dst_dev_type, false);
+		__d40_set_prio_rt(d40c, d40c->dma_cfg.dev_type, false);
 }
 
 /* DMA ENGINE functions */
@@ -2715,7 +2682,7 @@ static int d40_set_runtime_config(struct dma_chan *chan,
 
 	if (config->direction == DMA_DEV_TO_MEM) {
 		dma_addr_t dev_addr_rx =
-			d40c->base->plat_data->dev_rx[cfg->src_dev_type];
+			d40c->base->plat_data->dev_rx[cfg->dev_type];
 
 		config_addr = config->src_addr;
 		if (dev_addr_rx)
@@ -2738,7 +2705,7 @@ static int d40_set_runtime_config(struct dma_chan *chan,
 
 	} else if (config->direction == DMA_MEM_TO_DEV) {
 		dma_addr_t dev_addr_tx =
-			d40c->base->plat_data->dev_tx[cfg->dst_dev_type];
+			d40c->base->plat_data->dev_tx[cfg->dev_type];
 
 		config_addr = config->dst_addr;
 		if (dev_addr_tx)
@@ -2807,10 +2774,10 @@ static int d40_set_runtime_config(struct dma_chan *chan,
 	if (chan_is_logical(d40c)) {
 		if (cfg->dir == STEDMA40_PERIPH_TO_MEM)
 			d40c->lcpa = d40c->base->lcpa_base +
-				cfg->src_dev_type * D40_LCPA_CHAN_SIZE;
+				cfg->dev_type * D40_LCPA_CHAN_SIZE;
 		else
 			d40c->lcpa = d40c->base->lcpa_base +
-				cfg->dst_dev_type *
+				cfg->dev_type *
 				D40_LCPA_CHAN_SIZE + D40_LCPA_CHAN_DST_DELTA;
 	}
 
diff --git a/drivers/dma/ste_dma40_ll.c b/drivers/dma/ste_dma40_ll.c
index 7180e0d..5eb6c10 100644
--- a/drivers/dma/ste_dma40_ll.c
+++ b/drivers/dma/ste_dma40_ll.c
@@ -63,7 +63,7 @@ void d40_phy_cfg(struct stedma40_chan_cfg *cfg,
 		    (cfg->dir == STEDMA40_PERIPH_TO_PERIPH)) {
 			/* Set master port to 1 */
 			src |= 1 << D40_SREG_CFG_MST_POS;
-			src |= D40_TYPE_TO_EVENT(cfg->src_dev_type);
+			src |= D40_TYPE_TO_EVENT(cfg->dev_type);
 
 			if (cfg->src_info.flow_ctrl == STEDMA40_NO_FLOW_CTRL)
 				src |= 1 << D40_SREG_CFG_PHY_TM_POS;
@@ -74,7 +74,7 @@ void d40_phy_cfg(struct stedma40_chan_cfg *cfg,
 		    (cfg->dir == STEDMA40_PERIPH_TO_PERIPH)) {
 			/* Set master port to 1 */
 			dst |= 1 << D40_SREG_CFG_MST_POS;
-			dst |= D40_TYPE_TO_EVENT(cfg->dst_dev_type);
+			dst |= D40_TYPE_TO_EVENT(cfg->dev_type);
 
 			if (cfg->dst_info.flow_ctrl == STEDMA40_NO_FLOW_CTRL)
 				dst |= 1 << D40_SREG_CFG_PHY_TM_POS;
diff --git a/include/linux/platform_data/dma-ste-dma40.h b/include/linux/platform_data/dma-ste-dma40.h
index 869c571..9e42a67 100644
--- a/include/linux/platform_data/dma-ste-dma40.h
+++ b/include/linux/platform_data/dma-ste-dma40.h
@@ -109,8 +109,7 @@ struct stedma40_half_channel_info {
  * version 3+, i.e DB8500v2+
  * @mode: channel mode: physical, logical, or operation
  * @mode_opt: options for the chosen channel mode
- * @src_dev_type: Src device type
- * @dst_dev_type: Dst device type
+ * @dev_type: src/dst device type (driver uses dir to figure out which)
  * @src_info: Parameters for dst half channel
  * @dst_info: Parameters for dst half channel
  * @use_fixed_channel: if true, use physical channel specified by phy_channel
@@ -126,8 +125,7 @@ struct stedma40_chan_cfg {
 	bool					 realtime;
 	enum stedma40_mode			 mode;
 	enum stedma40_mode_opt			 mode_opt;
-	int					 src_dev_type;
-	int					 dst_dev_type;
+	int					 dev_type;
 	struct stedma40_half_channel_info	 src_info;
 	struct stedma40_half_channel_info	 dst_info;
 
-- 
1.7.10.4



From jack at suse.cz  Tue Apr  9 14:47:41 2013
From: jack at suse.cz (Jan Kara)
Date: Tue, 9 Apr 2013 20:47:41 +0200
Subject: [PATCH v3] [RESEND] mm: Make snapshotting pages for stable
 writes a per-bio operation
In-Reply-To: <20130409180617.GB8907@blackbox.djwong.org>
References: <20130409180617.GB8907@blackbox.djwong.org>
Message-ID: <20130409184741.GB15214@quack.suse.cz>

On Tue 09-04-13 11:06:17, Darrick J. Wong wrote:
> Walking a bio's page mappings has proved problematic, so create a new bio flag
> to indicate that a bio's data needs to be snapshotted in order to guarantee
> stable pages during writeback.  Next, for the one user (ext3/jbd) of
> snapshotting, hook all the places where writes can be initiated without
> PG_writeback set, and set BIO_SNAP_STABLE there.  We must also flag journal
> "metadata" bios for stable writeout, since file data can be written through the
> journal.  Finally, the MS_SNAP_STABLE mount flag (only used by ext3) is now
> superfluous, so get rid of it.
> 
> v3: Improve the documentation in jbd for why we're doing this, and clean up
> some code.
> 
> Signed-off-by: Darrick J. Wong <darrick.wong at oracle.com>
> 
> [darrick.wong at oracle.com: Fold in a couple of small cleanups from akpm]
> Signed-off-by: Andrew Morton <akpm at linux-foundation.org>
  You can add:
Reviewed-by: Jan Kara <jack at suse.cz>

								Honza
> ---
>  fs/buffer.c                 |    9 ++++++++-
>  fs/ext3/super.c             |    1 -
>  fs/jbd/commit.c             |   25 ++++++++++++++++++++++---
>  include/linux/blk_types.h   |    3 ++-
>  include/linux/buffer_head.h |    1 +
>  include/uapi/linux/fs.h     |    1 -
>  mm/bounce.c                 |   21 +--------------------
>  mm/page-writeback.c         |    4 ----
>  8 files changed, 34 insertions(+), 31 deletions(-)
> 
> diff --git a/fs/buffer.c b/fs/buffer.c
> index b4dcb34..71578d6 100644
> --- a/fs/buffer.c
> +++ b/fs/buffer.c
> @@ -2949,7 +2949,7 @@ static void guard_bh_eod(int rw, struct bio *bio, struct buffer_head *bh)
>  	}
>  }
>  
> -int submit_bh(int rw, struct buffer_head * bh)
> +int _submit_bh(int rw, struct buffer_head *bh, unsigned long bio_flags)
>  {
>  	struct bio *bio;
>  	int ret = 0;
> @@ -2984,6 +2984,7 @@ int submit_bh(int rw, struct buffer_head * bh)
>  
>  	bio->bi_end_io = end_bio_bh_io_sync;
>  	bio->bi_private = bh;
> +	bio->bi_flags |= bio_flags;
>  
>  	/* Take care of bh's that straddle the end of the device */
>  	guard_bh_eod(rw, bio, bh);
> @@ -2997,6 +2998,12 @@ int submit_bh(int rw, struct buffer_head * bh)
>  	bio_put(bio);
>  	return ret;
>  }
> +EXPORT_SYMBOL_GPL(_submit_bh);
> +
> +int submit_bh(int rw, struct buffer_head *bh)
> +{
> +	return _submit_bh(rw, bh, 0);
> +}
>  EXPORT_SYMBOL(submit_bh);
>  
>  /**
> diff --git a/fs/ext3/super.c b/fs/ext3/super.c
> index fb5120a..3dc48cc 100644
> --- a/fs/ext3/super.c
> +++ b/fs/ext3/super.c
> @@ -2067,7 +2067,6 @@ static int ext3_fill_super (struct super_block *sb, void *data, int silent)
>  		test_opt(sb,DATA_FLAGS) == EXT3_MOUNT_JOURNAL_DATA ? "journal":
>  		test_opt(sb,DATA_FLAGS) == EXT3_MOUNT_ORDERED_DATA ? "ordered":
>  		"writeback");
> -	sb->s_flags |= MS_SNAP_STABLE;
>  
>  	return 0;
>  
> diff --git a/fs/jbd/commit.c b/fs/jbd/commit.c
> index 86b39b1..11bb11f 100644
> --- a/fs/jbd/commit.c
> +++ b/fs/jbd/commit.c
> @@ -162,8 +162,17 @@ static void journal_do_submit_data(struct buffer_head **wbuf, int bufs,
>  
>  	for (i = 0; i < bufs; i++) {
>  		wbuf[i]->b_end_io = end_buffer_write_sync;
> -		/* We use-up our safety reference in submit_bh() */
> -		submit_bh(write_op, wbuf[i]);
> +		/*
> +		 * Here we write back pagecache data that may be mmaped. Since
> +		 * we cannot afford to clean the page and set PageWriteback
> +		 * here due to lock ordering (page lock ranks above transaction
> +		 * start), the data can change while IO is in flight. Tell the
> +		 * block layer it should bounce the bio pages if stable data
> +		 * during write is required.
> +		 *
> +		 * We use up our safety reference in submit_bh().
> +		 */
> +		_submit_bh(write_op, wbuf[i], 1 << BIO_SNAP_STABLE);
>  	}
>  }
>  
> @@ -667,7 +676,17 @@ start_journal_io:
>  				clear_buffer_dirty(bh);
>  				set_buffer_uptodate(bh);
>  				bh->b_end_io = journal_end_buffer_io_sync;
> -				submit_bh(write_op, bh);
> +				/*
> +				 * In data=journal mode, here we can end up
> +				 * writing pagecache data that might be
> +				 * mmapped. Since we can't afford to clean the
> +				 * page and set PageWriteback (see the comment
> +				 * near the other use of _submit_bh()), the
> +				 * data can change while the write is in
> +				 * flight.  Tell the block layer to bounce the
> +				 * bio pages if stable pages are required.
> +				 */
> +				_submit_bh(write_op, bh, 1 << BIO_SNAP_STABLE);
>  			}
>  			cond_resched();
>  
> diff --git a/include/linux/blk_types.h b/include/linux/blk_types.h
> index cdf1119..22990cf 100644
> --- a/include/linux/blk_types.h
> +++ b/include/linux/blk_types.h
> @@ -111,12 +111,13 @@ struct bio {
>  #define BIO_FS_INTEGRITY 9	/* fs owns integrity data, not block layer */
>  #define BIO_QUIET	10	/* Make BIO Quiet */
>  #define BIO_MAPPED_INTEGRITY 11/* integrity metadata has been remapped */
> +#define BIO_SNAP_STABLE	12	/* bio data must be snapshotted during write */
>  
>  /*
>   * Flags starting here get preserved by bio_reset() - this includes
>   * BIO_POOL_IDX()
>   */
> -#define BIO_RESET_BITS	12
> +#define BIO_RESET_BITS	13
>  
>  #define bio_flagged(bio, flag)	((bio)->bi_flags & (1 << (flag)))
>  
> diff --git a/include/linux/buffer_head.h b/include/linux/buffer_head.h
> index 5afc4f9..4c16c4a 100644
> --- a/include/linux/buffer_head.h
> +++ b/include/linux/buffer_head.h
> @@ -181,6 +181,7 @@ void ll_rw_block(int, int, struct buffer_head * bh[]);
>  int sync_dirty_buffer(struct buffer_head *bh);
>  int __sync_dirty_buffer(struct buffer_head *bh, int rw);
>  void write_dirty_buffer(struct buffer_head *bh, int rw);
> +int _submit_bh(int rw, struct buffer_head *bh, unsigned long bio_flags);
>  int submit_bh(int, struct buffer_head *);
>  void write_boundary_block(struct block_device *bdev,
>  			sector_t bblock, unsigned blocksize);
> diff --git a/include/uapi/linux/fs.h b/include/uapi/linux/fs.h
> index c7fc1e6..a4ed56c 100644
> --- a/include/uapi/linux/fs.h
> +++ b/include/uapi/linux/fs.h
> @@ -88,7 +88,6 @@ struct inodes_stat_t {
>  #define MS_STRICTATIME	(1<<24) /* Always perform atime updates */
>  
>  /* These sb flags are internal to the kernel */
> -#define MS_SNAP_STABLE	(1<<27) /* Snapshot pages during writeback, if needed */
>  #define MS_NOSEC	(1<<28)
>  #define MS_BORN		(1<<29)
>  #define MS_ACTIVE	(1<<30)
> diff --git a/mm/bounce.c b/mm/bounce.c
> index 5f89017..a5c2ec3 100644
> --- a/mm/bounce.c
> +++ b/mm/bounce.c
> @@ -181,32 +181,13 @@ static void bounce_end_io_read_isa(struct bio *bio, int err)
>  #ifdef CONFIG_NEED_BOUNCE_POOL
>  static int must_snapshot_stable_pages(struct request_queue *q, struct bio *bio)
>  {
> -	struct page *page;
> -	struct backing_dev_info *bdi;
> -	struct address_space *mapping;
> -	struct bio_vec *from;
> -	int i;
> -
>  	if (bio_data_dir(bio) != WRITE)
>  		return 0;
>  
>  	if (!bdi_cap_stable_pages_required(&q->backing_dev_info))
>  		return 0;
>  
> -	/*
> -	 * Based on the first page that has a valid mapping, decide whether or
> -	 * not we have to employ bounce buffering to guarantee stable pages.
> -	 */
> -	bio_for_each_segment(from, bio, i) {
> -		page = from->bv_page;
> -		mapping = page_mapping(page);
> -		if (!mapping)
> -			continue;
> -		bdi = mapping->backing_dev_info;
> -		return mapping->host->i_sb->s_flags & MS_SNAP_STABLE;
> -	}
> -
> -	return 0;
> +	return test_bit(BIO_SNAP_STABLE, &bio->bi_flags);
>  }
>  #else
>  static int must_snapshot_stable_pages(struct request_queue *q, struct bio *bio)
> diff --git a/mm/page-writeback.c b/mm/page-writeback.c
> index efe6814..4514ad7 100644
> --- a/mm/page-writeback.c
> +++ b/mm/page-writeback.c
> @@ -2311,10 +2311,6 @@ void wait_for_stable_page(struct page *page)
>  
>  	if (!bdi_cap_stable_pages_required(bdi))
>  		return;
> -#ifdef CONFIG_NEED_BOUNCE_POOL
> -	if (mapping->host->i_sb->s_flags & MS_SNAP_STABLE)
> -		return;
> -#endif /* CONFIG_NEED_BOUNCE_POOL */
>  
>  	wait_on_page_writeback(page);
>  }
-- 
Jan Kara <jack at suse.cz>
SUSE Labs, CR


From arnd at arndb.de  Tue Apr  9 14:51:12 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 9 Apr 2013 20:51:12 +0200
Subject: [PATCH 8/8] ARM: ux500: Amalgamate DMA source and destination
 channel numbers
In-Reply-To: <1365532783-27425-8-git-send-email-lee.jones@linaro.org>
References: <1365532783-27425-1-git-send-email-lee.jones@linaro.org>
 <1365532783-27425-8-git-send-email-lee.jones@linaro.org>
Message-ID: <201304092051.13138.arnd@arndb.de>

On Tuesday 09 April 2013, Lee Jones wrote:
> Devices which utilise DMA tend to use the same channel numbers for
> transmitting and receiving. For this reason and the fact that it'll
> decrease the burden of platform data passed to each device, we're
> amalgamating source and destination device types.
> 
> Signed-off-by: Lee Jones <lee.jones at linaro.org>

Very nice cleanup!

Acked-by: Arnd Bergmann <arnd at arndb.de>


From arnd at arndb.de  Tue Apr  9 14:55:55 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 9 Apr 2013 20:55:55 +0200
Subject: [PATCH 7/8] dmaengine: ste_dma40: Use the BIT macro to replace
 ugly '(1 << x)'s
In-Reply-To: <1365532783-27425-7-git-send-email-lee.jones@linaro.org>
References: <1365532783-27425-1-git-send-email-lee.jones@linaro.org>
 <1365532783-27425-7-git-send-email-lee.jones@linaro.org>
Message-ID: <201304092055.55661.arnd@arndb.de>

On Tuesday 09 April 2013, Lee Jones wrote:
> The aim is to make the code that little more readable.
> 
> Signed-off-by: Lee Jones <lee.jones at linaro.org>

I don't find the new version any more or less readable than the old one,
but I have no objections if other people think it's a good idea.

Acked-by: Arnd Bergmann <arnd at arndb.de>


From arnd at arndb.de  Tue Apr  9 14:56:30 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 9 Apr 2013 20:56:30 +0200
Subject: [PATCH 6/8] dmaengine: ste_dma40: Move LCPA allocation and
 real-time config
In-Reply-To: <1365532783-27425-6-git-send-email-lee.jones@linaro.org>
References: <1365532783-27425-1-git-send-email-lee.jones@linaro.org>
 <1365532783-27425-6-git-send-email-lee.jones@linaro.org>
Message-ID: <201304092056.31101.arnd@arndb.de>

On Tuesday 09 April 2013, Lee Jones wrote:
> There are various pieces of configuration which do not need to happen
> until after a channel is allocated. Here we move some of these so they're
> dealt with when it's time to configure the channel, rather than allocate
> it.
> 
> Cc: Vinod Koul <vinod.koul at intel.com>
> Cc: Dan Williams <djbw at fb.com>
> Cc: Per Forlin <per.forlin at stericsson.com>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>

Acked-by: Arnd Bergmann <arnd at arndb.de>


From arnd at arndb.de  Tue Apr  9 14:57:29 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 9 Apr 2013 20:57:29 +0200
Subject: [PATCH 5/8] dmaengine: ste_dma40: Ensure src and dst registers
 are configured correctly
In-Reply-To: <1365532783-27425-5-git-send-email-lee.jones@linaro.org>
References: <1365532783-27425-1-git-send-email-lee.jones@linaro.org>
 <1365532783-27425-5-git-send-email-lee.jones@linaro.org>
Message-ID: <201304092057.29684.arnd@arndb.de>

On Tuesday 09 April 2013, Lee Jones wrote:
> Confusingly d40_log_cfg() is used to set up the logical channel
> configuration registers, but d40_phy_cfg() is used to configure
> physical and logical registers, so it should be called in both
> cases. It is the function call's final attribute which determines
> whether it's a physical or logical channel, not whether the
> function is called or not.

So how did it ever work? Your description sounds like it was
broken all along, but I would assume that someone tested the code.

	Arnd


From arnd at arndb.de  Tue Apr  9 14:59:37 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 9 Apr 2013 20:59:37 +0200
Subject: [PATCH 3/8] dmaengine: ste_dma40: Actually write the runtime
 configuration to registers
In-Reply-To: <1365532783-27425-3-git-send-email-lee.jones@linaro.org>
References: <1365532783-27425-1-git-send-email-lee.jones@linaro.org>
 <1365532783-27425-3-git-send-email-lee.jones@linaro.org>
Message-ID: <201304092059.37739.arnd@arndb.de>

On Tuesday 09 April 2013, Lee Jones wrote:
> Someone has spent a fair amount of effort writing a runtime configuration
> changing algorithm for DMA clients. However, the config appears to never
> actually make it to hardware. In order for the configuration to take hold
> we need to issue a d40_config_write(), as this is the routine which writes
> it into the hardware's registers.
> 
> Signed-off-by: Lee Jones <lee.jones at linaro.org>

So this makes the runtime_addr selection work I suppose, but the
runtime_direction still isn't used anywhere, correct?

	Arnd


From harvey.harrison at gmail.com  Tue Apr  9 15:04:45 2013
From: harvey.harrison at gmail.com (Harvey Harrison)
Date: Tue, 9 Apr 2013 12:04:45 -0700
Subject: [PATCH 7/8] dmaengine: ste_dma40: Use the BIT macro to replace
 ugly '(1 << x)'s
In-Reply-To: <1365532783-27425-7-git-send-email-lee.jones@linaro.org>
References: <1365532783-27425-1-git-send-email-lee.jones@linaro.org>
 <1365532783-27425-7-git-send-email-lee.jones@linaro.org>
Message-ID: <CAHLZz133b6kydVwh0_Cn2yg-Q_MeUF+Z-7+CMY7TkB7KK2ssAQ@mail.gmail.com>

On Tue, Apr 9, 2013 at 11:39 AM, Lee Jones <lee.jones at linaro.org> wrote:
>
> The aim is to make the code that little more readable.
>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>
> ---

>
>  #define MAX(a, b) (((a) < (b)) ? (b) : (a))

Not part of your patch, but probably a good idea to switch to the
generic MAX macro, this
one is evaluating its args twice.

Cheers,

Harvey


From thomas.petazzoni at free-electrons.com  Tue Apr  9 15:06:52 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Tue, 9 Apr 2013 21:06:52 +0200
Subject: [PATCHv7 08/17] pci: PCIe driver for Marvell Armada 370/XP systems
In-Reply-To: <201304090014.06959.arnd@arndb.de>
References: <1364395234-11195-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <201304082334.13186.arnd@arndb.de> <20130408235341.7012b791@skate>
 <201304090014.06959.arnd@arndb.de>
Message-ID: <20130409210652.3bc1958b@skate>

Dear Arnd Bergmann,

On Tue, 9 Apr 2013 00:14:06 +0200, Arnd Bergmann wrote:

> 	pcie->realio.type = IORESOURCE_IO;
> 	pcie->realio.start = max(PCIBIOS_MIN_IO, range->pci_addr);
> 	pcie->realio.end = max(IO_SPACE_LIMIT, range->pci_addr + range->size);

Shouldn't this last line be using "min()" so that we guarantee we don't
have an I/O region that goes beyond IO_SPACE_LIMIT?

Thanks,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From lee.jones at linaro.org  Tue Apr  9 15:07:16 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Tue, 9 Apr 2013 20:07:16 +0100
Subject: [PATCH 3/8] dmaengine: ste_dma40: Actually write the runtime
 configuration to registers
In-Reply-To: <201304092059.37739.arnd@arndb.de>
References: <1365532783-27425-1-git-send-email-lee.jones@linaro.org>
 <1365532783-27425-3-git-send-email-lee.jones@linaro.org>
 <201304092059.37739.arnd@arndb.de>
Message-ID: <20130409190716.GE25316@gmail.com>

On Tue, 09 Apr 2013, Arnd Bergmann wrote:

> On Tuesday 09 April 2013, Lee Jones wrote:
> > Someone has spent a fair amount of effort writing a runtime configuration
> > changing algorithm for DMA clients. However, the config appears to never
> > actually make it to hardware. In order for the configuration to take hold
> > we need to issue a d40_config_write(), as this is the routine which writes
> > it into the hardware's registers.
> > 
> > Signed-off-by: Lee Jones <lee.jones at linaro.org>
> 
> So this makes the runtime_addr selection work I suppose, but the
> runtime_direction still isn't used anywhere, correct?

Yes, I have this on my TODO to speak with Linus, as he was the one who
mainlined it.

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From lee.jones at linaro.org  Tue Apr  9 15:09:16 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Tue, 9 Apr 2013 20:09:16 +0100
Subject: [PATCH 5/8] dmaengine: ste_dma40: Ensure src and dst registers
 are configured correctly
In-Reply-To: <201304092057.29684.arnd@arndb.de>
References: <1365532783-27425-1-git-send-email-lee.jones@linaro.org>
 <1365532783-27425-5-git-send-email-lee.jones@linaro.org>
 <201304092057.29684.arnd@arndb.de>
Message-ID: <20130409190916.GF25316@gmail.com>

On Tue, 09 Apr 2013, Arnd Bergmann wrote:

> On Tuesday 09 April 2013, Lee Jones wrote:
> > Confusingly d40_log_cfg() is used to set up the logical channel
> > configuration registers, but d40_phy_cfg() is used to configure
> > physical and logical registers, so it should be called in both
> > cases. It is the function call's final attribute which determines
> > whether it's a physical or logical channel, not whether the
> > function is called or not.
> 
> So how did it ever work? Your description sounds like it was
> broken all along, but I would assume that someone tested the code.

>From what I can see, not.

My best guess is that the 'test' was to see if the configuration
changed using the debug print at the end of the function. I don't see
how else the configuration can be written to hardware.

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From arnd at arndb.de  Tue Apr  9 15:09:43 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 9 Apr 2013 21:09:43 +0200
Subject: [PATCHv7 08/17] pci: PCIe driver for Marvell Armada 370/XP systems
In-Reply-To: <20130409210652.3bc1958b@skate>
References: <1364395234-11195-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <201304090014.06959.arnd@arndb.de> <20130409210652.3bc1958b@skate>
Message-ID: <201304092109.43404.arnd@arndb.de>

On Tuesday 09 April 2013, Thomas Petazzoni wrote:
> Dear Arnd Bergmann,
> 
> On Tue, 9 Apr 2013 00:14:06 +0200, Arnd Bergmann wrote:
> 
> >       pcie->realio.type = IORESOURCE_IO;
> >       pcie->realio.start = max(PCIBIOS_MIN_IO, range->pci_addr);
> >       pcie->realio.end = max(IO_SPACE_LIMIT, range->pci_addr + range->size);
> 
> Shouldn't this last line be using "min()" so that we guarantee we don't
> have an I/O region that goes beyond IO_SPACE_LIMIT?
> 

Yes, of course. Sorry for not typing what I was thinking ;-)

	Arnd


From arnd at arndb.de  Tue Apr  9 15:12:55 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 9 Apr 2013 21:12:55 +0200
Subject: [PATCH 7/8] dmaengine: ste_dma40: Use the BIT macro to replace
 ugly '(1 << x)'s
In-Reply-To: <CAHLZz133b6kydVwh0_Cn2yg-Q_MeUF+Z-7+CMY7TkB7KK2ssAQ@mail.gmail.com>
References: <1365532783-27425-1-git-send-email-lee.jones@linaro.org>
 <1365532783-27425-7-git-send-email-lee.jones@linaro.org>
 <CAHLZz133b6kydVwh0_Cn2yg-Q_MeUF+Z-7+CMY7TkB7KK2ssAQ@mail.gmail.com>
Message-ID: <201304092112.56039.arnd@arndb.de>

On Tuesday 09 April 2013, Harvey Harrison wrote:
> 
> On Tue, Apr 9, 2013 at 11:39 AM, Lee Jones <lee.jones at linaro.org> wrote:
> >
> > The aim is to make the code that little more readable.
> >
> > Signed-off-by: Lee Jones <lee.jones at linaro.org>
> > ---
> 
> >
> >  #define MAX(a, b) (((a) < (b)) ? (b) : (a))
> 
> Not part of your patch, but probably a good idea to switch to the
> generic MAX macro, this
> one is evaluating its args twice.

Yes, good point. The macro is only used in one place, to compare
two compile-time constant values, but we should define macros in
drivers that are already provided by the kernel.

	Arnd


From lee.jones at linaro.org  Tue Apr  9 15:12:56 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Tue, 9 Apr 2013 20:12:56 +0100
Subject: [PATCH 7/8] dmaengine: ste_dma40: Use the BIT macro to replace
 ugly '(1 << x)'s
In-Reply-To: <CAHLZz133b6kydVwh0_Cn2yg-Q_MeUF+Z-7+CMY7TkB7KK2ssAQ@mail.gmail.com>
References: <1365532783-27425-1-git-send-email-lee.jones@linaro.org>
 <1365532783-27425-7-git-send-email-lee.jones@linaro.org>
 <CAHLZz133b6kydVwh0_Cn2yg-Q_MeUF+Z-7+CMY7TkB7KK2ssAQ@mail.gmail.com>
Message-ID: <20130409191256.GG25316@gmail.com>

On Tue, 09 Apr 2013, Harvey Harrison wrote:

> On Tue, Apr 9, 2013 at 11:39 AM, Lee Jones <lee.jones at linaro.org> wrote:
> >
> > The aim is to make the code that little more readable.
> >
> > Signed-off-by: Lee Jones <lee.jones at linaro.org>
> > ---
> 
> >
> >  #define MAX(a, b) (((a) < (b)) ? (b) : (a))
> 
> Not part of your patch, but probably a good idea to switch to the
> generic MAX macro, this
> one is evaluating its args twice.

Sure, thanks for the heads-up.

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From arnd at arndb.de  Tue Apr  9 15:35:36 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 9 Apr 2013 21:35:36 +0200
Subject: [PATCHv2] ARM: Push selects for TWD/SCU into machine entries
In-Reply-To: <201304092032.18885.arnd@arndb.de>
References: <1362007694-3419-1-git-send-email-sboyd@codeaurora.org>
 <5164462E.4010706@codeaurora.org> <201304092032.18885.arnd@arndb.de>
Message-ID: <201304092135.36616.arnd@arndb.de>

On Tuesday 09 April 2013, Arnd Bergmann wrote:
> I've applied it to the next/soc branch now.
> 

I just made up my mind again after I got a few merge conflicts. I have
added it to the next/multiplatform branch now instead of next/soc, since
a few of the Kconfig entries changed in this patch are moved to other
files in that branch.

I've also added an entry for mach-zynq, which has gained SMP support
in the meantime. I assume it uses TWD/SCU as it is otherwise rather close
to the ARM reference platforms.

	Arnd


From mturquette at linaro.org  Tue Apr  9 15:40:21 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Tue, 09 Apr 2013 12:40:21 -0700
Subject: [PATCH 2/3] clk: ux500: abx500: Define clock tree for ab850x
In-Reply-To: <1364943987-1338-3-git-send-email-ulf.hansson@stericsson.com>
References: <1364943987-1338-1-git-send-email-ulf.hansson@stericsson.com>
 <1364943987-1338-3-git-send-email-ulf.hansson@stericsson.com>
Message-ID: <20130409194021.14359.1439@quantum>

Quoting Ulf Hansson (2013-04-02 16:06:26)
> From: Ulf Hansson <ulf.hansson at linaro.org>
> 
> The patch setups the first version of the clock tree for ab850x, which
> is used by u8500 platforms. Mainly sysctrl clocks are used.
> 
> Signed-off-by: Ulf Hansson <ulf.hansson at linaro.org>

Ulf,

Does the V1 version of this patch #2 go along with the recently posted
v3 version of patch #1 titled, "[PATCH V3 1/3] clk: ux500: Add support
for sysctrl clocks"?

Regards,
Mike

> ---
>  drivers/clk/ux500/abx500-clk.c |   71 ++++++++++++++++++++++++++++++++++++++--
>  1 file changed, 68 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/clk/ux500/abx500-clk.c b/drivers/clk/ux500/abx500-clk.c
> index 9f7400d..a0fca00 100644
> --- a/drivers/clk/ux500/abx500-clk.c
> +++ b/drivers/clk/ux500/abx500-clk.c
> @@ -12,13 +12,78 @@
>  #include <linux/device.h>
>  #include <linux/platform_device.h>
>  #include <linux/mfd/abx500/ab8500.h>
> -
> -/* TODO: Add clock implementations here */
> -
> +#include <linux/mfd/abx500/ab8500-sysctrl.h>
> +#include <linux/clk.h>
> +#include <linux/clkdev.h>
> +#include <linux/clk-provider.h>
> +#include <linux/mfd/dbx500-prcmu.h>
> +#include "clk.h"
>  
>  /* Clock definitions for ab8500 */
>  static int ab8500_reg_clks(struct device *dev)
>  {
> +       int ret;
> +       struct clk *clk;
> +
> +       const char *intclk_parents[] = {"ab8500_sysclk", "ulpclk"};
> +       u16 intclk_reg_sel[] = {0 , AB8500_SYSULPCLKCTRL1};
> +       u8 intclk_reg_mask[] = {0 , AB8500_SYSULPCLKCTRL1_SYSULPCLKINTSEL_MASK};
> +       u8 intclk_reg_bits[] = {
> +               0 ,
> +               (1 << AB8500_SYSULPCLKCTRL1_SYSULPCLKINTSEL_SHIFT)
> +       };
> +
> +       dev_info(dev, "register clocks for ab850x\n");
> +
> +       /* Enable SWAT */
> +       ret = ab8500_sysctrl_set(AB8500_SWATCTRL, AB8500_SWATCTRL_SWATENABLE);
> +       if (ret)
> +               return ret;
> +
> +       /* ab8500_sysclk */
> +       clk = clk_reg_prcmu_gate("ab8500_sysclk", NULL, PRCMU_SYSCLK,
> +                               CLK_IS_ROOT);
> +       clk_register_clkdev(clk, "sysclk", "ab8500-usb.0");
> +       clk_register_clkdev(clk, "sysclk", "ab-iddet.0");
> +       clk_register_clkdev(clk, "sysclk", "ab85xx-codec.0");
> +       clk_register_clkdev(clk, "sysclk", "shrm_bus");
> +
> +       /* ab8500_sysclk2 */
> +       clk = clk_reg_sysctrl_gate(dev , "ab8500_sysclk2", "ab8500_sysclk",
> +               AB8500_SYSULPCLKCTRL1, AB8500_SYSULPCLKCTRL1_SYSCLKBUF2REQ,
> +               AB8500_SYSULPCLKCTRL1_SYSCLKBUF2REQ, 0, 0);
> +       clk_register_clkdev(clk, "sysclk", "0-0070");
> +
> +       /* ab8500_sysclk3 */
> +       clk = clk_reg_sysctrl_gate(dev , "ab8500_sysclk3", "ab8500_sysclk",
> +               AB8500_SYSULPCLKCTRL1, AB8500_SYSULPCLKCTRL1_SYSCLKBUF3REQ,
> +               AB8500_SYSULPCLKCTRL1_SYSCLKBUF3REQ, 0, 0);
> +       clk_register_clkdev(clk, "sysclk", "cg1960_core.0");
> +
> +       /* ab8500_sysclk4 */
> +       clk = clk_reg_sysctrl_gate(dev , "ab8500_sysclk4", "ab8500_sysclk",
> +               AB8500_SYSULPCLKCTRL1, AB8500_SYSULPCLKCTRL1_SYSCLKBUF4REQ,
> +               AB8500_SYSULPCLKCTRL1_SYSCLKBUF4REQ, 0, 0);
> +
> +       /* ab_ulpclk */
> +       clk = clk_reg_sysctrl_gate_fixed_rate(dev, "ulpclk", NULL,
> +               AB8500_SYSULPCLKCTRL1, AB8500_SYSULPCLKCTRL1_ULPCLKREQ,
> +               AB8500_SYSULPCLKCTRL1_ULPCLKREQ,
> +               38400000, 9000, CLK_IS_ROOT);
> +       clk_register_clkdev(clk, "ulpclk", "ab85xx-codec.0");
> +
> +       /* ab8500_intclk */
> +       clk = clk_reg_sysctrl_set_parent(dev , "intclk", intclk_parents, 2,
> +               intclk_reg_sel, intclk_reg_mask, intclk_reg_bits, 0);
> +       clk_register_clkdev(clk, "intclk", "ab85xx-codec.0");
> +       clk_register_clkdev(clk, NULL, "ab8500-pwm.1");
> +
> +       /* ab8500_audioclk */
> +       clk = clk_reg_sysctrl_gate(dev , "audioclk", "intclk",
> +               AB8500_SYSULPCLKCTRL1, AB8500_SYSULPCLKCTRL1_AUDIOCLKENA,
> +               AB8500_SYSULPCLKCTRL1_AUDIOCLKENA, 0, 0);
> +       clk_register_clkdev(clk, "audioclk", "ab85xx-codec.0");
> +
>         return 0;
>  }
>  
> -- 
> 1.7.10


From lee.jones at linaro.org  Tue Apr  9 15:52:58 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Tue, 9 Apr 2013 20:52:58 +0100
Subject: [PATCH 2/2 v2] mfd: db8500-prcmu: Support platform dependant device
 selection
In-Reply-To: <1365071941-23475-2-git-send-email-lee.jones@linaro.org>
References: <1365071941-23475-1-git-send-email-lee.jones@linaro.org>
 <1365071941-23475-2-git-send-email-lee.jones@linaro.org>
Message-ID: <20130409195258.GH25316@gmail.com>

The main aim for this cycle is to have the u8540 booting to a
console. However, the u8540 doesn't support all of the u8500
platform devices yet. After this stage is complete we can then
fill in the inadequacies, such as specific clock support at a
later date. To achieve this we're placing devices supported by
all platforms into a common device structure and the remaining
ones into a platform specific one.

Cc: Samuel Ortiz <sameo at linux.intel.com>
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 drivers/mfd/db8500-prcmu.c |   32 ++++++++++++++++++++++++--------
 1 file changed, 24 insertions(+), 8 deletions(-)

diff --git a/drivers/mfd/db8500-prcmu.c b/drivers/mfd/db8500-prcmu.c
index 25dda8d..319b8ab 100644
--- a/drivers/mfd/db8500-prcmu.c
+++ b/drivers/mfd/db8500-prcmu.c
@@ -24,6 +24,7 @@
 #include <linux/jiffies.h>
 #include <linux/bitops.h>
 #include <linux/fs.h>
+#include <linux/of.h>
 #include <linux/platform_device.h>
 #include <linux/uaccess.h>
 #include <linux/mfd/core.h>
@@ -3067,6 +3068,15 @@ static struct db8500_thsens_platform_data db8500_thsens_data = {
 	.num_trips = 4,
 };
 
+static struct mfd_cell common_prcmu_devs[] = {
+	{
+		.name = "ux500_wdt",
+		.platform_data = &db8500_wdt_pdata,
+		.pdata_size = sizeof(db8500_wdt_pdata),
+		.id = -1,
+	},
+};
+
 static struct mfd_cell db8500_prcmu_devs[] = {
 	{
 		.name = "db8500-prcmu-regulators",
@@ -3081,12 +3091,6 @@ static struct mfd_cell db8500_prcmu_devs[] = {
 		.pdata_size = sizeof(db8500_cpufreq_table),
 	},
 	{
-		.name = "ux500_wdt",
-		.platform_data = &db8500_wdt_pdata,
-		.pdata_size = sizeof(db8500_wdt_pdata),
-		.id = -1,
-	},
-	{
 		.name = "db8500-thermal",
 		.num_resources = ARRAY_SIZE(db8500_thsens_resources),
 		.resources = db8500_thsens_resources,
@@ -3175,13 +3179,25 @@ static int db8500_prcmu_probe(struct platform_device *pdev)
 
 	db8500_prcmu_update_cpufreq();
 
-	err = mfd_add_devices(&pdev->dev, 0, db8500_prcmu_devs,
-			      ARRAY_SIZE(db8500_prcmu_devs), NULL, 0, db8500_irq_domain);
+	err = mfd_add_devices(&pdev->dev, 0, common_prcmu_devs,
+			      ARRAY_SIZE(common_prcmu_devs), NULL, 0, db8500_irq_domain);
 	if (err) {
 		pr_err("prcmu: Failed to add subdevices\n");
 		return err;
 	}
 
+	/* TODO: Remove restriction when clk definitions are available. */
+	if (!of_machine_is_compatible("st-ericsson,u8540")) {
+		err = mfd_add_devices(&pdev->dev, 0, db8500_prcmu_devs,
+				      ARRAY_SIZE(db8500_prcmu_devs), NULL, 0,
+				      db8500_irq_domain);
+		if (err) {
+			mfd_remove_devices(&pdev->dev);
+			pr_err("prcmu: Failed to add subdevices\n");
+			goto no_irq_return;
+		}
+	}
+
 	err = db8500_prcmu_register_ab8500(&pdev->dev, pdata->ab_platdata,
 					   pdata->ab_irq);
 	if (err) {
-- 
1.7.10.4


From arnd at arndb.de  Tue Apr  9 16:01:18 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 9 Apr 2013 22:01:18 +0200
Subject: [GIT PULL 7/8] ARM: tegra: multi-platform conversion
In-Reply-To: <201304091659.08376.arnd@arndb.de>
References: <1365181426-11547-1-git-send-email-swarren@wwwdotorg.org>
 <1365181426-11547-7-git-send-email-swarren@wwwdotorg.org>
 <201304091659.08376.arnd@arndb.de>
Message-ID: <201304092201.18950.arnd@arndb.de>

On Tuesday 09 April 2013, Arnd Bergmann wrote:
> On Friday 05 April 2013, Stephen Warren wrote:
> > This branch converts Tegra to support multi-platform/single-zImage.

> I had to reorder the branches in arm-soc to avoid starting a
> next/multiplatform2 branch, but I saw nothing that prevents us from
> having multiplatform after soc.

I've applied this patch on top.

From 1939e142b04d91b97a8643dd68c4b3fae48a136b Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd at arndb.de>
Date: Tue, 9 Apr 2013 21:58:38 +0200
Subject: [PATCH] ARM: tegra: build assembly files with -march=armv7-a

The tegra assembly files are written for ARMv7 and are not compatible
with ARMv6, which leads to build warnings when compiling a dual
ARMv6/v7 kernel. Since this code is only ever run on Tegra ARMv7
hardware, we can tell the assembler which architecture level to
use.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>

diff --git a/arch/arm/mach-tegra/Makefile b/arch/arm/mach-tegra/Makefile
index e40326d..bfc5b07 100644
--- a/arch/arm/mach-tegra/Makefile
+++ b/arch/arm/mach-tegra/Makefile
@@ -1,3 +1,5 @@
+asflags-y				+= -march=armv7-a
+
 obj-y                                   += common.o
 obj-y                                   += io.o
 obj-y                                   += irq.o


From nicolas.pitre at linaro.org  Tue Apr  9 16:03:45 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Tue, 9 Apr 2013 16:03:45 -0400 (EDT)
Subject: [PATCH v6 3/4] ARM: Enable selection of SMP operations at boot
 time
In-Reply-To: <1365167495-18508-3-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1304031239550.5078@kaball.uk.xensource.com>
 <1365167495-18508-3-git-send-email-stefano.stabellini@eu.citrix.com>
Message-ID: <alpine.LFD.2.03.1304091600330.17375@syhkavp.arg>

On Fri, 5 Apr 2013, Stefano Stabellini wrote:

> From: Jon Medhurst <tixy at linaro.org>
> 
> Add a new 'smp_init' hook to machine_desc so platforms can specify a
> function to be used to setup smp ops instead of having a statically
> defined value.
> 
> If smp_init is set, use it instead of psci_smp_ops or mdesc->smp.
> 
> Signed-off-by: Jon Medhurst <tixy at linaro.org>
> Signed-off-by: Nicolas Pitre <nicolas.pitre at linaro.org>
> Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
> Reviewed-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
> ---
>  arch/arm/include/asm/mach/arch.h |    3 +++
>  arch/arm/kernel/setup.c          |    4 +++-
>  2 files changed, 6 insertions(+), 1 deletions(-)

Please use this version instead.  The runtime hook may now indicate if 
it did initialize smp_ops or not.

----- >8
From: Jon Medhurst <tixy at linaro.org>
Date: Thu, 13 Dec 2012 13:23:13 +0000
Subject: [PATCH] ARM: Enable selection of SMP operations at boot time

Add a new 'smp_init' hook to machine_desc so platforms can specify a
function to be used to setup smp ops instead of having a statically
defined value.  The hook must return true when smp_ops are initialized.
If false the static mdesc->smp_ops will be used by default.

Signed-off-by: Jon Medhurst <tixy at linaro.org>
Signed-off-by: Nicolas Pitre <nicolas.pitre at linaro.org>
Reviewed-by: Santosh Shilimkar <santosh.shilimkar at ti.com>

diff --git a/arch/arm/include/asm/mach/arch.h b/arch/arm/include/asm/mach/arch.h
index 308ad7d6f9..af8c54c6c6 100644
--- a/arch/arm/include/asm/mach/arch.h
+++ b/arch/arm/include/asm/mach/arch.h
@@ -16,8 +16,10 @@ struct pt_regs;
 struct smp_operations;
 #ifdef CONFIG_SMP
 #define smp_ops(ops) (&(ops))
+#define smp_init_ops(ops) (&(ops))
 #else
 #define smp_ops(ops) (struct smp_operations *)NULL
+#define smp_init_ops(ops) (bool (*)(void))NULL
 #endif
 
 struct machine_desc {
@@ -41,6 +43,7 @@ struct machine_desc {
 	unsigned char		reserve_lp2 :1;	/* never has lp2	*/
 	char			restart_mode;	/* default restart mode	*/
 	struct smp_operations	*smp;		/* SMP operations	*/
+	bool			(*smp_init)(void);
 	void			(*fixup)(struct tag *, char **,
 					 struct meminfo *);
 	void			(*reserve)(void);/* reserve mem blocks	*/
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 3f6cbb2e3e..cf4b08c0f9 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -768,7 +768,8 @@ void __init setup_arch(char **cmdline_p)
 	arm_dt_init_cpu_maps();
 #ifdef CONFIG_SMP
 	if (is_smp()) {
-		smp_set_ops(mdesc->smp);
+		if (!mdesc->smp_init || !mdesc->smp_init())
+			smp_set_ops(mdesc->smp);
 		smp_init_cpus();
 	}
 #endif


From robherring2 at gmail.com  Tue Apr  9 16:15:32 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Tue, 09 Apr 2013 15:15:32 -0500
Subject: [GIT PULL] dt: run C pre-processor on *.dts, create some standard
 headers
In-Reply-To: <1365187610-29422-1-git-send-email-swarren@wwwdotorg.org>
References: <1365187610-29422-1-git-send-email-swarren@wwwdotorg.org>
Message-ID: <516476E4.3050206@gmail.com>

On 04/05/2013 01:46 PM, Stephen Warren wrote:
> Rob, it might be worth keeping this in a separate branch in linux-next
> so you can pull it out if it causes any issues. I've been using these
> patches for quite a while now, but there's always opportunity for
> surprises on architectures I don't use. I did just fix a bug when
> building with O= a few days back, hence the V2 that I posted as patches.
> 

Pulled into my for-next branch.

Rob

> ----------------------------------------------------------------
> 
> This branch enhances the support for running dtc on device tree files.
> 
> A dedicated directory is created for header files that provide constants
> for device-tree bindings.
> 
> The kbuild dependency script processor is enhanced to support processing
> the dependency outputs from multiple separate commands at once.
> 
> The kbuild dtc rule is modified so that the C pre-processor is always
> applied when compiling any device tree.
> 
> Some standard headers are created which define common constants for GPIO,
> IRQ, and ARM GIC device tree bindings.
> 
> ----------------------------------------------------------------
> 
> The following changes since commit 6dbe51c251a327e012439c4772097a13df43c5b8:
> 
>   Linux 3.9-rc1
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra.git tegra-for-3.10-dtc-cpp-chroot-std-headers
> 
> for you to fetch changes up to 4be505d4fc7a07371a2b658469ca1dda99993ca3:
> 
>   ARM: dt: create a DT header for the GIC
> 
> ----------------------------------------------------------------
> 
> Stephen Warren (7):
>       kbuild: create an "include chroot" for DT bindings
>       kbuild: fixdep: support concatenated dep files
>       kbuild: cmd_dtc_cpp: extract deps from both gcc -E and dtc
>       kbuild: always run gcc -E on *.dts, remove cmd_dtc_cpp
>       ARM: dt: add header to define GPIO flags
>       ARM: dt: add header to define IRQ flags
>       ARM: dt: create a DT header for the GIC
> 
>  arch/arm/boot/dts/include/dt-bindings           |    1 +
>  include/dt-bindings/gpio/gpio.h                 |   15 +++
>  .../dt-bindings/interrupt-controller/arm-gic.h  |   22 +++++
>  include/dt-bindings/interrupt-controller/irq.h  |   19 ++++
>  scripts/Makefile.lib                            |   17 ++--
>  scripts/basic/fixdep.c                          |   93 ++++++++++++------
>  6 files changed, 125 insertions(+), 42 deletions(-)
>  create mode 120000 arch/arm/boot/dts/include/dt-bindings
>  create mode 100644 include/dt-bindings/gpio/gpio.h
>  create mode 100644 include/dt-bindings/interrupt-controller/arm-gic.h
>  create mode 100644 include/dt-bindings/interrupt-controller/irq.h
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
> 
> 



From arnd at arndb.de  Tue Apr  9 16:19:53 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 9 Apr 2013 22:19:53 +0200
Subject: [GIT PULL 02/10] 2nd irq-s3c24xx for v3.10
In-Reply-To: <516309D9.7000609@samsung.com>
References: <516309D9.7000609@samsung.com>
Message-ID: <201304092219.54078.arnd@arndb.de>

On Monday 08 April 2013, Kukjin Kim wrote:
> s3c24xx irq cleanup and move into drivers/irqchip

I had a little trouble applying this because of the interface change to
CLOCKSOURCE_OF_DECLARE. This is the rather complex merge I did. Please
check that it still works.

	Arnd

commit 682f619ef995c6bc7e07b356451b8d762caefc5e
Merge: 894b738 354599f
Author: Arnd Bergmann <arnd at arndb.de>
Date:   Tue Apr 9 22:07:37 2013 +0200

    Merge tag 'mct-exynos-for-v3.10' of git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung into next/drivers
    
    From Kukjin Kim <kgene.kim at samsung.com>:
    
    add support exynos mct device tree and move into drivers/clocksource
    
    * tag 'mct-exynos-for-v3.10' of git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung:
      clocksource: mct: Add terminating entry for exynos_mct_ids table
      clocksource: mct: Add missing semicolons in exynos_mct.c
      ARM: EXYNOS: move mct driver to drivers/clocksource
      ARM: EXYNOS: remove static io-remapping of mct registers for Exynos5
      ARM: dts: add mct device tree node for all supported Exynos SoC's
      ARM: EXYNOS: allow dt based discovery of mct controller using clocksource_of_init
      ARM: EXYNOS: add device tree support for MCT controller driver
      ARM: EXYNOS: prepare an array of MCT interrupt numbers and use it
      ARM: EXYNOS: add a register base address variable in mct controller driver
    
    Conflicts:
    	drivers/clocksource/Makefile
    	drivers/clocksource/exynos_mct.c
    
    Signed-off-by: Arnd Bergmann <arnd at arndb.de>

diff --cc drivers/clocksource/Makefile
index e74c8ce,1c1b15d..cd1f09c
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@@ -19,7 -19,7 +19,8 @@@ obj-$(CONFIG_ARCH_BCM2835)	+= bcm2835_t
  obj-$(CONFIG_SUNXI_TIMER)	+= sunxi_timer.o
  obj-$(CONFIG_ARCH_TEGRA)	+= tegra20_timer.o
  obj-$(CONFIG_VT8500_TIMER)	+= vt8500_timer.o
- obj-$(CONFIG_CADENCE_TTC_TIMER)		+= cadence_ttc_timer.o
++obj-$(CONFIG_CADENCE_TTC_TIMER)	+= cadence_ttc_timer.o
+ obj-$(CONFIG_CLKSRC_EXYNOS_MCT)	+= exynos_mct.o
  
  obj-$(CONFIG_ARM_ARCH_TIMER)		+= arm_arch_timer.o
  obj-$(CONFIG_CLKSRC_METAG_GENERIC)	+= metag_generic.o
diff --cc drivers/clocksource/exynos_mct.c
index c9d6650,d3f1327..957af86
--- a/drivers/clocksource/exynos_mct.c
+++ b/drivers/clocksource/exynos_mct.c
@@@ -445,13 -477,17 +477,17 @@@ static struct local_timer_ops exynos4_m
  };
  #endif /* CONFIG_LOCAL_TIMERS */
  
- static void __init exynos4_timer_resources(void)
 -static void __init exynos4_timer_resources(struct device_node *np)
++static void __init exynos4_timer_resources(void __iomem *base)
  {
  	struct clk *mct_clk;
  	mct_clk = clk_get(NULL, "xtal");
  
  	clk_rate = clk_get_rate(mct_clk);
  
 -	reg_base = np ? of_iomap(np, 0) : S5P_VA_SYSTIMER;
++	reg_base = base;
+ 	if (!reg_base)
+ 		panic("%s: unable to ioremap mct address space\n", __func__);
+ 
  #ifdef CONFIG_LOCAL_TIMERS
  	if (mct_int_type == MCT_INT_PPI) {
  		int err;
@@@ -467,19 -503,49 +503,54 @@@
  #endif /* CONFIG_LOCAL_TIMERS */
  }
  
- void __init exynos4_timer_init(void)
 -static const struct of_device_id exynos_mct_ids[] = {
 -	{ .compatible = "samsung,exynos4210-mct", .data = (void *)MCT_INT_SPI },
 -	{ .compatible = "samsung,exynos4412-mct", .data = (void *)MCT_INT_PPI },
 -	{ }
 -};
 -
+ void __init mct_init(void)
  {
- 	if (soc_is_exynos5440()) {
- 		arch_timer_of_register();
- 		return;
 -	struct device_node *np = NULL;
 -	const struct of_device_id *match;
 -	u32 nr_irqs, i;
 -
 -#ifdef CONFIG_OF
 -	np = of_find_matching_node_and_match(NULL, exynos_mct_ids, &match);
 -#endif
 -	if (np) {
 -		mct_int_type = (u32)(match->data);
 -
 -		/* This driver uses only one global timer interrupt */
 -		mct_irqs[MCT_G0_IRQ] = irq_of_parse_and_map(np, MCT_G0_IRQ);
 -
 -		/*
 -		 * Find out the number of local irqs specified. The local
 -		 * timer irqs are specified after the four global timer
 -		 * irqs are specified.
 -		 */
 -#ifdef CONFIG_OF
 -		nr_irqs = of_irq_count(np);
 -#endif
 -		for (i = MCT_L0_IRQ; i < nr_irqs; i++)
 -			mct_irqs[i] = irq_of_parse_and_map(np, i);
 -	} else if (soc_is_exynos4210()) {
++	if (soc_is_exynos4210()) {
+ 		mct_irqs[MCT_G0_IRQ] = EXYNOS4_IRQ_MCT_G0;
+ 		mct_irqs[MCT_L0_IRQ] = EXYNOS4_IRQ_MCT_L0;
+ 		mct_irqs[MCT_L1_IRQ] = EXYNOS4_IRQ_MCT_L1;
+ 		mct_int_type = MCT_INT_SPI;
+ 	} else {
+ 		panic("unable to determine mct controller type\n");
  	}
  
- 	if ((soc_is_exynos4210()) || (soc_is_exynos5250()))
- 		mct_int_type = MCT_INT_SPI;
- 	else
- 		mct_int_type = MCT_INT_PPI;
 -	exynos4_timer_resources(np);
++	exynos4_timer_resources(S5P_VA_SYSTIMER);
+ 	exynos4_clocksource_init();
+ 	exynos4_clockevent_init();
+ }
 -CLOCKSOURCE_OF_DECLARE(exynos4210, "samsung,exynos4210-mct", mct_init);
 -CLOCKSOURCE_OF_DECLARE(exynos4412, "samsung,exynos4412-mct", mct_init);
 +
- 	exynos4_timer_resources();
++static void __init mct_init_dt(struct device_node *np, unsigned int int_type)
++{
++	u32 nr_irqs, i;
++
++	mct_int_type = int_type;
++
++	/* This driver uses only one global timer interrupt */
++	mct_irqs[MCT_G0_IRQ] = irq_of_parse_and_map(np, MCT_G0_IRQ);
++
++	/*
++	 * Find out the number of local irqs specified. The local
++	 * timer irqs are specified after the four global timer
++	 * irqs are specified.
++	 */
++	nr_irqs = of_irq_count(np);
++	for (i = MCT_L0_IRQ; i < nr_irqs; i++)
++		mct_irqs[i] = irq_of_parse_and_map(np, i);
++
++	exynos4_timer_resources(of_iomap(np, 0));
 +	exynos4_clocksource_init();
 +	exynos4_clockevent_init();
 +}
++
++
++static void __init mct_init_spi(struct device_node *np)
++{
++	return mct_init_dt(np, MCT_INT_SPI);
++}
++
++static void __init mct_init_ppi(struct device_node *np)
++{
++	return mct_init_dt(np, MCT_INT_PPI);
++}
++CLOCKSOURCE_OF_DECLARE(exynos4210, "samsung,exynos4210-mct", mct_init_spi);
++CLOCKSOURCE_OF_DECLARE(exynos4412, "samsung,exynos4412-mct", mct_init_ppi);



From arnd at arndb.de  Tue Apr  9 16:21:10 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 9 Apr 2013 22:21:10 +0200
Subject: [GIT PULL 02/10] 2nd irq-s3c24xx for v3.10
In-Reply-To: <201304092219.54078.arnd@arndb.de>
References: <516309D9.7000609@samsung.com> <201304092219.54078.arnd@arndb.de>
Message-ID: <201304092221.10650.arnd@arndb.de>

On Tuesday 09 April 2013, Arnd Bergmann wrote:
> On Monday 08 April 2013, Kukjin Kim wrote:
> > s3c24xx irq cleanup and move into drivers/irqchip
> 
> I had a little trouble applying this because of the interface change to
> CLOCKSOURCE_OF_DECLARE. This is the rather complex merge I did. Please
> check that it still works.

The reply should have been for patch 3/10. I've merged both into the
next/drivers branch.

	Arnd


From ezequiel.garcia at free-electrons.com  Tue Apr  9 16:26:16 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Tue,  9 Apr 2013 17:26:16 -0300
Subject: [PATCH v6 0/5] Device Bus support for Marvell EBU SoC
Message-ID: <1365539181-29242-1-git-send-email-ezequiel.garcia@free-electrons.com>

This patchset continues the effort to add Device Bus support
on Marvell EBU SoC.

If you're reading this for the first time you can grab the full details here:

  http://www.spinics.net/lists/arm-kernel/msg236151.html

This new version changes the way each chip select is described in the DT.
Now there's a separate node for each Device Bus chip select, like this:

	devbus-bootcs at d0010400 {
		compatible = "marvell,mvebu-devbus";
		reg = <0xd0010400 0x8>;
		ranges = <0 0xf0000000 0x8000000>; /* @addr 0xf000000, size 0x8000000 */

		device at 0 {
			reg = <0 0x8000000>;
		}
	};

	// ...

	devbus-cs1 at d0010410 {
		compatible = "marvell,mvebu-devbus";
		reg = <0xd0010410 0x8>;
	};

In particular, please note that once the window handling is properly added
to the DT, and we remove the mbus usage from this driver, in the above DT nodes
the ranges property value will have to be changed, but the ABI will be the same.

This applies on top of v3.9-rc5 with mbus patches applied, which can 
be found in Jason Cooper's mvebus/soc branch.

This v6 fixes some issues pointed out by both Arnd Bergmann and Jason Gunthorpe.
Thanks to both for reviewing the driver and for the feedback!

Changes from v5:

  * Instead of translating the child address, parse the 'ranges'
    property. This is possible because the 'ranges' is mandatory
    and will a single entry to describing the address window.
    This allows to remove every reference to child nodes, and will
    be removed later, once the mbus binding is added.

  * Use of_platform_populate to register all child nodes.
    This way we solve the one-child only constraint present
    in the previous v5 of this series.

  * Rework the driver registration. Now there's a module_init()
    to register the platform driver, but there's no module_exit()
    to unregister it. This is done because currently there's no
    function opposite to of_platform_populate() to unregister all
    devices from a DT tree.

Changes from v4:

  * Calculate the chip select from the base address
    and drop the 2-cell address size.
    Suggested by Arnd Bergmann and Jason Gunthorpe.

  * The mvebu driver can't be compiled as a module, since the mbus
    API is not exported yet, so remove that option.

  * Bunch of comments here and there...

Changes from v3:

  * Rename devbus,dev-width to devbus,bus-width and changed the
    parameter value from bytes to bits: <8>, <16>, ...
    Suggested by Arnd Bergmann.

  * As suggested by Jason Gunthorpe and agreed by Arnd Bergmann.
    Reworked the whole devbus child chip-select device tree design.
    Now there's a separate devbus at addr DT node for each controller
    chip select. The impact of this is:
      1. Timing parameters now go into the parent node.
      2. There can only be one child per devbus node.

  * Remove unneeded bank-width parameter read.

Changes from v2:

  * Replace the 'NOR' specific probe by a generic probe.
    Currently, we don't see anything specific to NOR in this driver.
    Suggested by Jason Gunthorpe.

  * Add a check to detect that every timing parameter is specified
    in the device tree node.
    Suggested by Jason Gunthorpe.

Changes from v1:

  * Added a remove() function to unregister childs and remove address windows,
    as suggested by Thomas Petazzoni.

  * Remove unneeded 'inline' prefix on functions as suggested by Thomas Petazzoni.

  * Timings parameters are now mandatory and expressed in picoseconds,
    as requested by Jason Gunthorpe.
    This is consistent with OMAP's GPMC dts binding.

  * Fix documentation as suggested by Jason Gunthorpe.

Thanks!

Ezequiel Garcia (5):
  drivers: memory: Introduce Marvell EBU Device Bus driver
  ARM: mvebu: Add Device Bus support for Armada 370/XP SoC
  ARM: mvebu: Add support for NOR flash device on Armada XP-GP board
  ARM: mvebu: Add support for NOR flash device on Openblocks AX3 board
  ARM: mvebu: Add Device Bus and CFI flash memory support to defconfig

 .../bindings/memory-controllers/mvebu-devbus.txt   | 156 ++++++++++
 arch/arm/boot/dts/armada-370-xp.dtsi               |  45 +++
 arch/arm/boot/dts/armada-xp-gp.dts                 |  29 ++
 arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts   |  29 ++
 arch/arm/configs/mvebu_defconfig                   |   7 +
 drivers/memory/Kconfig                             |  10 +
 drivers/memory/Makefile                            |   1 +
 drivers/memory/mvebu-devbus.c                      | 326 +++++++++++++++++++++
 8 files changed, 603 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/memory-controllers/mvebu-devbus.txt
 create mode 100644 drivers/memory/mvebu-devbus.c

-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Tue Apr  9 16:26:17 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Tue,  9 Apr 2013 17:26:17 -0300
Subject: [PATCH v6 1/5] drivers: memory: Introduce Marvell EBU Device Bus
 driver
In-Reply-To: <1365539181-29242-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1365539181-29242-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1365539181-29242-2-git-send-email-ezequiel.garcia@free-electrons.com>

Marvell EBU SoCs such as Armada 370/XP, Orion5x (88f5xxx) and
Discovery (mv78xx0) supports a Device Bus controller to access several
kinds of memories and I/O devices (NOR, NAND, SRAM, FPGA).

This commit adds a driver to handle this controller. So far only
Armada 370, Armada XP and Discovery SoCs are supported.

The driver must be registered through a device tree node;
as explained in the binding document.

For each child node in the device tree, this driver will:
  * set timing parameters
  * register a child device
  * setup an address decoding window, using the mbus driver

Keep in mind the address decoding window setup is only a temporary hack.
This code will be removed from this devbus driver as soon as a proper device
tree binding for the mbus driver is added.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
Acked-by: Arnd Bergmann <arnd at arndb.de>
---
 .../bindings/memory-controllers/mvebu-devbus.txt   | 156 ++++++++++
 drivers/memory/Kconfig                             |  10 +
 drivers/memory/Makefile                            |   1 +
 drivers/memory/mvebu-devbus.c                      | 326 +++++++++++++++++++++
 4 files changed, 493 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/memory-controllers/mvebu-devbus.txt
 create mode 100644 drivers/memory/mvebu-devbus.c

diff --git a/Documentation/devicetree/bindings/memory-controllers/mvebu-devbus.txt b/Documentation/devicetree/bindings/memory-controllers/mvebu-devbus.txt
new file mode 100644
index 0000000..653c90c
--- /dev/null
+++ b/Documentation/devicetree/bindings/memory-controllers/mvebu-devbus.txt
@@ -0,0 +1,156 @@
+Device tree bindings for MVEBU Device Bus controllers
+
+The Device Bus controller available in some Marvell's SoC allows to control
+different types of standard memory and I/O devices such as NOR, NAND, and FPGA.
+The actual devices are instantiated from the child nodes of a Device Bus node.
+
+Required properties:
+
+ - compatible:          Currently only Armada 370/XP SoC are supported,
+                        with this compatible string:
+
+                        marvell,mvebu-devbus
+
+ - reg:                 A resource specifier for the register space.
+                        This is the base address of a chip select within
+			the controller's register space.
+                        (see the example below)
+
+ - #address-cells:      Must be set to 1
+ - #size-cells:         Must be set to 1
+ - ranges:              Must be set up to reflect the memory layout with four
+                        integer values for each chip-select line in use:
+                        0 <physical address of mapping> <size>
+
+Mandatory timing properties for child nodes:
+
+Read parameters:
+
+ - devbus,turn-off-ps:  Defines the time during which the controller does not
+                        drive the AD bus after the completion of a device read.
+                        This prevents contentions on the Device Bus after a read
+                        cycle from a slow device.
+
+ - devbus,bus-width:    Defines the bus width (e.g. <16>)
+
+ - devbus,badr-skew-ps: Defines the time delay from from A[2:0] toggle,
+                        to read data sample. This parameter is useful for
+                        synchronous pipelined devices, where the address
+                        precedes the read data by one or two cycles.
+
+ - devbus,acc-first-ps: Defines the time delay from the negation of
+                        ALE[0] to the cycle that the first read data is sampled
+                        by the controller.
+
+ - devbus,acc-next-ps:  Defines the time delay between the cycle that
+                        samples data N and the cycle that samples data N+1
+                        (in burst accesses).
+
+ - devbus,rd-setup-ps:  Defines the time delay between DEV_CSn assertion to
+			DEV_OEn assertion. If set to 0 (default),
+                        DEV_OEn and DEV_CSn are asserted at the same cycle.
+                        This parameter has no affect on <acc-first-ps> parameter
+                        (no affect on first data sample). Set <rd-setup-ps>
+                        to a value smaller than <acc-first-ps>.
+
+ - devbus,rd-hold-ps:   Defines the time between the last data sample to the
+			de-assertion of DEV_CSn. If set to 0 (default),
+			DEV_OEn and DEV_CSn are de-asserted at the same cycle
+			(the cycle of the last data sample).
+                        This parameter has no affect on DEV_OEn de-assertion.
+                        DEV_OEn is always de-asserted the next cycle after
+                        last data sampled. Also this parameter has no
+                        affect on <turn-off-ps> parameter.
+                        Set <rd-hold-ps> to a value smaller than <turn-off-ps>.
+
+Write parameters:
+
+ - devbus,ale-wr-ps:    Defines the time delay from the ALE[0] negation cycle
+			to the DEV_WEn assertion.
+
+ - devbus,wr-low-ps:    Defines the time during which DEV_WEn is active.
+                        A[2:0] and Data are kept valid as long as DEV_WEn
+                        is active. This parameter defines the setup time of
+                        address and data to DEV_WEn rise.
+
+ - devbus,wr-high-ps:   Defines the time during which DEV_WEn is kept
+                        inactive (high) between data beats of a burst write.
+                        DEV_A[2:0] and Data are kept valid (do not toggle) for
+                        <wr-high-ps> - <tick> ps.
+			This parameter defines the hold time of address and
+			data after DEV_WEn rise.
+
+ - devbus,sync-enable: Synchronous device enable.
+                       1: True
+                       0: False
+
+An example for an Armada XP GP board, with a 16 MiB NOR device as child
+is showed below. Note that the Device Bus driver is in charge of allocating
+the mbus address decoding window for each of its child devices.
+The window is created using the chip select specified in the child
+device node together with the base address and size specified in the ranges
+property. For instance, in the example below the allocated decoding window
+will start at base address 0xf0000000, with a size 0x1000000 (16 MiB)
+for chip select 0 (a.k.a DEV_BOOTCS).
+
+This address window handling is done in this mvebu-devbus only as a temporary
+solution. It will be removed when the support for mbus device tree binding is
+added.
+
+The reg property implicitly specifies the chip select as this:
+
+  0x10400: DEV_BOOTCS
+  0x10408: DEV_CS0
+  0x10410: DEV_CS1
+  0x10418: DEV_CS2
+  0x10420: DEV_CS3
+
+Example:
+
+	devbus-bootcs at d0010400 {
+		status = "okay";
+		ranges = <0 0xf0000000 0x1000000>; /* @addr 0xf0000000, size 0x1000000 */
+		#address-cells = <1>;
+		#size-cells = <1>;
+
+		/* Device Bus parameters are required */
+
+		/* Read parameters */
+		devbus,bus-width    = <8>;
+		devbus,turn-off-ps  = <60000>;
+		devbus,badr-skew-ps = <0>;
+		devbus,acc-first-ps = <124000>;
+		devbus,acc-next-ps  = <248000>;
+		devbus,rd-setup-ps  = <0>;
+		devbus,rd-hold-ps   = <0>;
+
+		/* Write parameters */
+		devbus,sync-enable = <0>;
+		devbus,wr-high-ps  = <60000>;
+		devbus,wr-low-ps   = <60000>;
+		devbus,ale-wr-ps   = <60000>;
+
+		flash at 0 {
+			compatible = "cfi-flash";
+
+			/* 16 MiB */
+			reg = <0 0x1000000>;
+			bank-width = <2>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+
+			/*
+			 * We split the 16 MiB in two partitions,
+			 * just as an example.
+			 */
+			partition at 0 {
+				label = "First";
+				reg = <0 0x800000>;
+			};
+
+			partition at 800000 {
+				label = "Second";
+				reg = <0x800000 0x800000>;
+			};
+		};
+	};
diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig
index 067f311..29a11db 100644
--- a/drivers/memory/Kconfig
+++ b/drivers/memory/Kconfig
@@ -20,6 +20,16 @@ config TI_EMIF
 	  parameters and other settings during frequency, voltage and
 	  temperature changes
 
+config MVEBU_DEVBUS
+	bool "Marvell EBU Device Bus Controller"
+	default y
+	depends on PLAT_ORION && OF
+	help
+	  This driver is for the Device Bus controller available in some
+	  Marvell EBU SoCs such as Discovery (mv78xx0), Orion (88f5xxx) and
+	  Armada 370 and Armada XP. This controller allows to handle flash
+	  devices such as NOR, NAND, SRAM, and FPGA.
+
 config TEGRA20_MC
 	bool "Tegra20 Memory Controller(MC) driver"
 	default y
diff --git a/drivers/memory/Makefile b/drivers/memory/Makefile
index 9cce5d7..969d923 100644
--- a/drivers/memory/Makefile
+++ b/drivers/memory/Makefile
@@ -6,5 +6,6 @@ ifeq ($(CONFIG_DDR),y)
 obj-$(CONFIG_OF)		+= of_memory.o
 endif
 obj-$(CONFIG_TI_EMIF)		+= emif.o
+obj-$(CONFIG_MVEBU_DEVBUS)	+= mvebu-devbus.o
 obj-$(CONFIG_TEGRA20_MC)	+= tegra20-mc.o
 obj-$(CONFIG_TEGRA30_MC)	+= tegra30-mc.o
diff --git a/drivers/memory/mvebu-devbus.c b/drivers/memory/mvebu-devbus.c
new file mode 100644
index 0000000..d4284d4
--- /dev/null
+++ b/drivers/memory/mvebu-devbus.c
@@ -0,0 +1,326 @@
+/*
+ * Marvell EBU SoC Device Bus Controller
+ * (memory controller for NOR/NAND/SRAM/FPGA devices)
+ *
+ * Copyright (C) 2013 Marvell
+ *
+ * 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 version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
+ *
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/slab.h>
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/clk.h>
+#include <linux/mbus.h>
+#include <linux/of_platform.h>
+#include <linux/of_address.h>
+#include <linux/platform_device.h>
+
+/* Register definitions */
+#define DEV_WIDTH_BIT		30
+#define BADR_SKEW_BIT		28
+#define RD_HOLD_BIT		23
+#define ACC_NEXT_BIT		17
+#define RD_SETUP_BIT		12
+#define ACC_FIRST_BIT		6
+
+#define SYNC_ENABLE_BIT		24
+#define WR_HIGH_BIT		16
+#define WR_LOW_BIT		8
+
+#define READ_PARAM_OFFSET	0x0
+#define WRITE_PARAM_OFFSET	0x4
+
+static const char * const devbus_wins[] = {
+	"devbus-boot",
+	"devbus-cs0",
+	"devbus-cs1",
+	"devbus-cs2",
+	"devbus-cs3",
+};
+
+struct devbus_read_params {
+	u32 bus_width;
+	u32 badr_skew;
+	u32 turn_off;
+	u32 acc_first;
+	u32 acc_next;
+	u32 rd_setup;
+	u32 rd_hold;
+};
+
+struct devbus_write_params {
+	u32 sync_enable;
+	u32 wr_high;
+	u32 wr_low;
+	u32 ale_wr;
+};
+
+struct devbus {
+	struct device *dev;
+	void __iomem *base;
+	unsigned long tick_ps;
+};
+
+static int get_timing_param_ps(struct devbus *devbus,
+			       struct device_node *node,
+			       const char *name,
+			       u32 *ticks)
+{
+	u32 time_ps;
+	int err;
+
+	err = of_property_read_u32(node, name, &time_ps);
+	if (err < 0) {
+		dev_err(devbus->dev, "%s has no '%s' property\n",
+			name, node->full_name);
+		return err;
+	}
+
+	*ticks = (time_ps + devbus->tick_ps - 1) / devbus->tick_ps;
+
+	dev_dbg(devbus->dev, "%s: %u ps -> 0x%x\n",
+		name, time_ps, *ticks);
+	return 0;
+}
+
+static int devbus_set_timing_params(struct devbus *devbus,
+				    struct device_node *node)
+{
+	struct devbus_read_params r;
+	struct devbus_write_params w;
+	u32 value;
+	int err;
+
+	dev_dbg(devbus->dev, "Setting timing parameter, tick is %lu ps\n",
+		devbus->tick_ps);
+
+	/* Get read timings */
+	err = of_property_read_u32(node, "devbus,bus-width", &r.bus_width);
+	if (err < 0) {
+		dev_err(devbus->dev,
+			"%s has no 'devbus,bus-width' property\n",
+			node->full_name);
+		return err;
+	}
+	/* Convert bit width to byte width */
+	r.bus_width /= 8;
+
+	err = get_timing_param_ps(devbus, node, "devbus,badr-skew-ps",
+				 &r.badr_skew);
+	if (err < 0)
+		return err;
+
+	err = get_timing_param_ps(devbus, node, "devbus,turn-off-ps",
+				 &r.turn_off);
+	if (err < 0)
+		return err;
+
+	err = get_timing_param_ps(devbus, node, "devbus,acc-first-ps",
+				 &r.acc_first);
+	if (err < 0)
+		return err;
+
+	err = get_timing_param_ps(devbus, node, "devbus,acc-next-ps",
+				 &r.acc_next);
+	if (err < 0)
+		return err;
+
+	err = get_timing_param_ps(devbus, node, "devbus,rd-setup-ps",
+				 &r.rd_setup);
+	if (err < 0)
+		return err;
+
+	err = get_timing_param_ps(devbus, node, "devbus,rd-hold-ps",
+				 &r.rd_hold);
+	if (err < 0)
+		return err;
+
+	/* Get write timings */
+	err = of_property_read_u32(node, "devbus,sync-enable",
+				  &w.sync_enable);
+	if (err < 0) {
+		dev_err(devbus->dev,
+			"%s has no 'devbus,sync-enable' property\n",
+			node->full_name);
+		return err;
+	}
+
+	err = get_timing_param_ps(devbus, node, "devbus,ale-wr-ps",
+				 &w.ale_wr);
+	if (err < 0)
+		return err;
+
+	err = get_timing_param_ps(devbus, node, "devbus,wr-low-ps",
+				 &w.wr_low);
+	if (err < 0)
+		return err;
+
+	err = get_timing_param_ps(devbus, node, "devbus,wr-high-ps",
+				 &w.wr_high);
+	if (err < 0)
+		return err;
+
+	/* Set read timings */
+	value = r.bus_width << DEV_WIDTH_BIT |
+		r.badr_skew << BADR_SKEW_BIT |
+		r.rd_hold   << RD_HOLD_BIT   |
+		r.acc_next  << ACC_NEXT_BIT  |
+		r.rd_setup  << RD_SETUP_BIT  |
+		r.acc_first << ACC_FIRST_BIT |
+		r.turn_off;
+
+	dev_dbg(devbus->dev, "read parameters register 0x%p = 0x%x\n",
+		devbus->base + READ_PARAM_OFFSET,
+		value);
+
+	writel(value, devbus->base + READ_PARAM_OFFSET);
+
+	/* Set write timings */
+	value = w.sync_enable  << SYNC_ENABLE_BIT |
+		w.wr_low       << WR_LOW_BIT      |
+		w.wr_high      << WR_HIGH_BIT     |
+		w.ale_wr;
+
+	dev_dbg(devbus->dev, "write parameters register: 0x%p = 0x%x\n",
+		devbus->base + WRITE_PARAM_OFFSET,
+		value);
+
+	writel(value, devbus->base + WRITE_PARAM_OFFSET);
+
+	return 0;
+}
+
+static int mvebu_devbus_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct device_node *node = pdev->dev.of_node;
+	struct devbus *devbus;
+	struct resource *res;
+	struct clk *clk;
+	unsigned long rate;
+	int err, cs;
+	u32 addr_region[3];
+
+	devbus = devm_kzalloc(&pdev->dev, sizeof(struct devbus), GFP_KERNEL);
+	if (!devbus)
+		return -ENOMEM;
+
+	devbus->dev = dev;
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	devbus->base = devm_ioremap_resource(&pdev->dev, res);
+	if (IS_ERR(devbus->base))
+		return PTR_ERR(devbus->base);
+
+	clk = devm_clk_get(&pdev->dev, NULL);
+	if (IS_ERR(clk))
+		return PTR_ERR(clk);
+	clk_prepare_enable(clk);
+
+	/*
+	 * Obtain clock period in picoseconds,
+	 * we need this in order to convert timing
+	 * parameters from cycles to picoseconds.
+	 */
+	rate = clk_get_rate(clk) / 1000;
+	devbus->tick_ps = 1000000000 / rate;
+
+	/* Read the device tree node and set the new timing parameters */
+	err = devbus_set_timing_params(devbus, node);
+	if (err < 0)
+		return err;
+
+	/*
+	 * Allocate an address window for this device.
+	 * If the device probing fails, then we won't be able to
+	 * remove the allocated address decoding window.
+	 *
+	 * FIXME: This is only a temporary hack! We need to do this here
+	 * because we still don't have device tree bindings for mbus.
+	 * Once that support is added, we will declare these address windows
+	 * statically in the device tree, and remove the window configuration
+	 * from here.
+	 */
+
+	/*
+	 * Get the CS to choose the window string.
+	 * This is a bit hacky, but it will be removed once the
+	 * address windows are declared in the device tree.
+	 */
+	cs = (((unsigned long)devbus->base) % 0x400) / 8;
+
+	/*
+	 * Since this is only part of the workaround,
+	 * we can do this dirty 'ranges' property parsing.
+	 * Of course, this will be removed once the address windows
+	 * are declared in the device tree.
+	 */
+	err = of_property_read_u32_array(node, "ranges", addr_region,
+					 ARRAY_SIZE(addr_region));
+	if (err < 0) {
+		dev_err(dev, "%s has a malformed 'range' property\n",
+			node->full_name);
+		return err;
+	}
+
+	/*
+	 * Create an mbus address windows.
+	 * FIXME: Remove this, together with the above code, once the
+	 * address windows are declared in the device tree.
+	 */
+	err = mvebu_mbus_add_window(devbus_wins[cs],
+				    addr_region[1], addr_region[2]);
+	if (err < 0)
+		return err;
+
+	/*
+	 * We need to create a child device explicitly from here to
+	 * guarantee that the child will be probed after the timing
+	 * parameters for the bus are written.
+	 */
+	err = of_platform_populate(node, NULL, NULL, dev);
+	if (err < 0) {
+		mvebu_mbus_del_window(addr_region[1], addr_region[2]);
+		return err;
+	}
+
+	return 0;
+}
+
+static const struct of_device_id mvebu_devbus_of_match[] = {
+	{ .compatible = "marvell,mvebu-devbus" },
+	{},
+};
+MODULE_DEVICE_TABLE(of, mvebu_devbus_of_match);
+
+static struct platform_driver mvebu_devbus_driver = {
+	.probe		= mvebu_devbus_probe,
+	.driver		= {
+		.name	= "mvebu-devbus",
+		.owner	= THIS_MODULE,
+		.of_match_table = mvebu_devbus_of_match,
+	},
+};
+
+static int __init mvebu_devbus_init(void)
+{
+	return platform_driver_register(&mvebu_devbus_driver);
+}
+module_init(mvebu_devbus_init);
+
+MODULE_LICENSE("GPL v2");
+MODULE_AUTHOR("Ezequiel Garcia <ezequiel.garcia at free-electrons.com>");
+MODULE_DESCRIPTION("Marvell EBU SoC Device Bus controller");
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Tue Apr  9 16:26:18 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Tue,  9 Apr 2013 17:26:18 -0300
Subject: [PATCH v6 2/5] ARM: mvebu: Add Device Bus support for Armada 370/XP
 SoC
In-Reply-To: <1365539181-29242-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1365539181-29242-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1365539181-29242-3-git-send-email-ezequiel.garcia@free-electrons.com>

Armada 370 and Armada XP SoC have a Device Bus controller to
handle NOR, NAND, SRAM and FPGA devices.
This patch adds the device tree node to enable the controller.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
Acked-by: Arnd Bergmann <arnd at arndb.de>
---
 arch/arm/boot/dts/armada-370-xp.dtsi | 45 ++++++++++++++++++++++++++++++++++++
 1 file changed, 45 insertions(+)

diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi b/arch/arm/boot/dts/armada-370-xp.dtsi
index 7704829..9693f79 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -176,6 +176,51 @@
 			clocks = <&coreclk 0>;
 			status = "disabled";
 		};
+
+		devbus-bootcs at d0010400 {
+			compatible = "marvell,mvebu-devbus";
+			reg = <0xd0010400 0x8>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			clocks = <&coreclk 0>;
+			status = "disabled";
+		};
+
+		devbus-cs0 at d0010408 {
+			compatible = "marvell,mvebu-devbus";
+			reg = <0xd0010408 0x8>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			clocks = <&coreclk 0>;
+			status = "disabled";
+		};
+
+		devbus-cs1 at d0010410 {
+			compatible = "marvell,mvebu-devbus";
+			reg = <0xd0010410 0x8>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			clocks = <&coreclk 0>;
+			status = "disabled";
+		};
+
+		devbus-cs2 at d0010418 {
+			compatible = "marvell,mvebu-devbus";
+			reg = <0xd0010418 0x8>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			clocks = <&coreclk 0>;
+			status = "disabled";
+		};
+
+		devbus-cs3 at d0010420 {
+			compatible = "marvell,mvebu-devbus";
+			reg = <0xd0010420 0x8>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			clocks = <&coreclk 0>;
+			status = "disabled";
+		};
 	};
 };
 
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Tue Apr  9 16:26:19 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Tue,  9 Apr 2013 17:26:19 -0300
Subject: [PATCH v6 3/5] ARM: mvebu: Add support for NOR flash device on Armada
 XP-GP board
In-Reply-To: <1365539181-29242-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1365539181-29242-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1365539181-29242-4-git-send-email-ezequiel.garcia@free-electrons.com>

The Armada XP Development Board DB-MV784MP-GP has a NOR flash device
connected to the Device Bus. This commit adds the device tree node
to support this device.

This SoC supports a flexible and dynamic decoding window allocation
scheme; but since this feature is still not implemented we need
to specify the window base address in the device tree node itself.

This base address has been selected in a completely arbitrary fashion.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
Acked-by: Arnd Bergmann <arnd at arndb.de>
---
 arch/arm/boot/dts/armada-xp-gp.dts | 29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)

diff --git a/arch/arm/boot/dts/armada-xp-gp.dts b/arch/arm/boot/dts/armada-xp-gp.dts
index 1c8afe2..e57e9c7 100644
--- a/arch/arm/boot/dts/armada-xp-gp.dts
+++ b/arch/arm/boot/dts/armada-xp-gp.dts
@@ -109,5 +109,34 @@
 				spi-max-frequency = <108000000>;
 			};
 		};
+
+		devbus-bootcs at d0010400 {
+			status = "okay";
+			ranges = <0 0xf0000000 0x1000000>; /* @addr 0xf000000, size 0x1000000 */
+
+			/* Device Bus parameters are required */
+
+			/* Read parameters */
+			devbus,bus-width    = <8>;
+			devbus,turn-off-ps  = <60000>;
+			devbus,badr-skew-ps = <0>;
+			devbus,acc-first-ps = <124000>;
+			devbus,acc-next-ps  = <248000>;
+			devbus,rd-setup-ps  = <0>;
+			devbus,rd-hold-ps   = <0>;
+
+			/* Write parameters */
+			devbus,sync-enable = <0>;
+			devbus,wr-high-ps  = <60000>;
+			devbus,wr-low-ps   = <60000>;
+			devbus,ale-wr-ps   = <60000>;
+
+			/* NOR 16 MiB */
+			nor at 0 {
+				compatible = "cfi-flash";
+				reg = <0 0x1000000>;
+				bank-width = <2>;
+			};
+		};
 	};
 };
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Tue Apr  9 16:26:20 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Tue,  9 Apr 2013 17:26:20 -0300
Subject: [PATCH v6 4/5] ARM: mvebu: Add support for NOR flash device on
 Openblocks AX3 board
In-Reply-To: <1365539181-29242-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1365539181-29242-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1365539181-29242-5-git-send-email-ezequiel.garcia@free-electrons.com>

The Plat'home Openblocks AX3 has a 128 MiB NOR flash device connected
to the Device Bus. This commit adds the device tree node to support this device.

The SoC supports a flexible and dynamic decoding window allocation scheme;
but since this feature is still not implemented we need to specify the window
base address in the device tree node itself.
This base address has been selected in a completely arbitrary fashion.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
Acked-by: Arnd Bergmann <arnd at arndb.de>
---
 arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 29 ++++++++++++++++++++++++
 1 file changed, 29 insertions(+)

diff --git a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
index 3818a82..b5c5f4d 100644
--- a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
+++ b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
@@ -139,5 +139,34 @@
 		usb at d0051000 {
 			status = "okay";
 		};
+
+		devbus-bootcs at d0010400 {
+			status = "okay";
+			ranges = <0 0xf0000000 0x8000000>; /* @addr 0xf000000, size 0x8000000 */
+
+			/* Device Bus parameters are required */
+
+			/* Read parameters */
+			devbus,bus-width    = <8>;
+			devbus,turn-off-ps  = <60000>;
+			devbus,badr-skew-ps = <0>;
+			devbus,acc-first-ps = <124000>;
+			devbus,acc-next-ps  = <248000>;
+			devbus,rd-setup-ps  = <0>;
+			devbus,rd-hold-ps   = <0>;
+
+			/* Write parameters */
+			devbus,sync-enable = <0>;
+			devbus,wr-high-ps  = <60000>;
+			devbus,wr-low-ps   = <60000>;
+			devbus,ale-wr-ps   = <60000>;
+
+			/* NOR 128 MiB */
+			nor at 0 {
+				compatible = "cfi-flash";
+				reg = <0 0x8000000>;
+				bank-width = <2>;
+			};
+		};
 	};
 };
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Tue Apr  9 16:26:21 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Tue,  9 Apr 2013 17:26:21 -0300
Subject: [PATCH v6 5/5] ARM: mvebu: Add Device Bus and CFI flash memory
 support to defconfig
In-Reply-To: <1365539181-29242-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1365539181-29242-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1365539181-29242-6-git-send-email-ezequiel.garcia@free-electrons.com>

This patch selects the devbus driver as part of the mvebu default
config, along with the required options to detect and support
CFI flash memories.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
Acked-by: Arnd Bergmann <arnd at arndb.de>
---
 arch/arm/configs/mvebu_defconfig | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/configs/mvebu_defconfig b/arch/arm/configs/mvebu_defconfig
index 2ec8119..fe8ba26 100644
--- a/arch/arm/configs/mvebu_defconfig
+++ b/arch/arm/configs/mvebu_defconfig
@@ -46,6 +46,11 @@ CONFIG_I2C_MV64XXX=y
 CONFIG_MTD=y
 CONFIG_MTD_CHAR=y
 CONFIG_MTD_M25P80=y
+CONFIG_MTD_CFI=y
+CONFIG_MTD_CFI_INTELEXT=y
+CONFIG_MTD_CFI_AMDSTD=y
+CONFIG_MTD_CFI_STAA=y
+CONFIG_MTD_PHYSMAP_OF=y
 CONFIG_SERIAL_8250_DW=y
 CONFIG_GPIOLIB=y
 CONFIG_GPIO_SYSFS=y
@@ -65,6 +70,8 @@ CONFIG_RTC_DRV_S35390A=y
 CONFIG_RTC_DRV_MV=y
 CONFIG_DMADEVICES=y
 CONFIG_MV_XOR=y
+CONFIG_MEMORY=y
+CONFIG_MVEBU_DEVBUS=y
 # CONFIG_IOMMU_SUPPORT is not set
 CONFIG_EXT2_FS=y
 CONFIG_EXT3_FS=y
-- 
1.8.1.5



From dianders at chromium.org  Tue Apr  9 16:12:41 2013
From: dianders at chromium.org (Doug Anderson)
Date: Tue,  9 Apr 2013 13:12:41 -0700
Subject: [PATCH v5 3/3] ARM: dts: Add sbs-battery for exynos5250-snow
In-Reply-To: <1365538361-2763-1-git-send-email-dianders@chromium.org>
References: <1363192583-26363-1-git-send-email-dianders@chromium.org>
 <1365538361-2763-1-git-send-email-dianders@chromium.org>
Message-ID: <1365538361-2763-3-git-send-email-dianders@chromium.org>

Now that we have i2c-arbitrator in place on bus 4 we can add the
sbs-battery driver.  Future devices will be added onto bus 4 once
drivers are in good shape.

Signed-off-by: Doug Anderson <dianders at chromium.org>
---
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 arch/arm/boot/dts/exynos5250-snow.dts | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5250-snow.dts b/arch/arm/boot/dts/exynos5250-snow.dts
index fa85f58..c115143 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -66,6 +66,12 @@
 			reg = <0>;
 			#address-cells = <1>;
 			#size-cells = <0>;
+
+			battery: sbs-battery at b {
+				compatible = "sbs,sbs-battery";
+				reg = <0xb>;
+				sbs,poll-retry-count = <1>;
+			};
 		};
 	};
 
-- 
1.8.1.3



From dianders at chromium.org  Tue Apr  9 16:12:40 2013
From: dianders at chromium.org (Doug Anderson)
Date: Tue,  9 Apr 2013 13:12:40 -0700
Subject: [PATCH v5 2/3] ARM: dts: Add i2c-arbitrator bus for exynos5250-snow
In-Reply-To: <1365538361-2763-1-git-send-email-dianders@chromium.org>
References: <1363192583-26363-1-git-send-email-dianders@chromium.org>
 <1365538361-2763-1-git-send-email-dianders@chromium.org>
Message-ID: <1365538361-2763-2-git-send-email-dianders@chromium.org>

We need to use the i2c-arbitrator to talk to any of the devices on i2c
bus 4 on exynos5250-snow so that we don't confuse the embedded
controller (EC).  Add the i2c-arbitrator to the device tree.  As we
add future devices (keyboard, sbs, tps65090) we'll add them on top of
this.

The arbitrated bus is numbered 104 simply as a convenience to make it
easier for people poking around to guess that it might have something
to do with the physical bus 4.

The addition is split between the cros5250-common and the snow device
tree file since not all cros5250-class devices use arbitration.

Signed-off-by: Doug Anderson <dianders at chromium.org>
---
Changes in v5:
- Adjust bindings as per Wolfram Sang.

Changes in v4:
- Changed mux gpio syntax to work atop Thomas's "ARM: dts: add pin
  state information in client nodes for Exynos5 platforms"; avoid
  adding gpios property to i2c at 12CA0000 for the same reason.

Changes in v3: None
Changes in v2:
- Use new device tree property names / compatible string.
- Include that the GPIOs for arbitration are active low.

 arch/arm/boot/dts/cros5250-common.dtsi |  3 ++-
 arch/arm/boot/dts/exynos5250-snow.dts  | 25 +++++++++++++++++++++++++
 2 files changed, 27 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/cros5250-common.dtsi b/arch/arm/boot/dts/cros5250-common.dtsi
index 8a5b3a6..0a61bbb 100644
--- a/arch/arm/boot/dts/cros5250-common.dtsi
+++ b/arch/arm/boot/dts/cros5250-common.dtsi
@@ -193,7 +193,8 @@
 	};
 
 	i2c at 12CA0000 {
-		status = "disabled";
+		samsung,i2c-sda-delay = <100>;
+		samsung,i2c-max-bus-freq = <66000>;
 	};
 
 	i2c at 12CB0000 {
diff --git a/arch/arm/boot/dts/exynos5250-snow.dts b/arch/arm/boot/dts/exynos5250-snow.dts
index 581ffae..fa85f58 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -16,6 +16,10 @@
 	model = "Google Snow";
 	compatible = "google,snow", "samsung,exynos5250";
 
+	aliases {
+		i2c104 = &i2c_104;
+	};
+
 	pinctrl at 11400000 {
 		sd3_clk: sd3-clk {
 			samsung,pin-drv = <0>;
@@ -44,6 +48,27 @@
 		};
 	};
 
+	i2c-arbitrator {
+		compatible = "i2c-arb-gpio-challenge";
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		i2c-parent = <&{/i2c at 12CA0000}>;
+
+		our-claim-gpio = <&gpf0 3 1>;
+		their-claim-gpios = <&gpe0 4 1>;
+		slew-delay-us = <10>;
+		wait-retry-us = <3000>;
+		wait-free-us = <50000>;
+
+		/* Use ID 104 as a hint that we're on physical bus 4 */
+		i2c_104: i2c at 0 {
+			reg = <0>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+	};
+
 	/*
 	 * On Snow we've got SIP WiFi and so can keep drive strengths low to
 	 * reduce EMI.
-- 
1.8.1.3



From ezequiel.garcia at free-electrons.com  Tue Apr  9 16:28:47 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Tue, 9 Apr 2013 17:28:47 -0300
Subject: [PATCH v4 1/5] drivers: memory: Introduce Marvell EBU Device Bus
 driver
In-Reply-To: <20130409160316.GB9663@obsidianresearch.com>
References: <1365419194-20871-1-git-send-email-ezequiel.garcia@free-electrons.com>
 <1365419194-20871-2-git-send-email-ezequiel.garcia@free-electrons.com>
 <20130408171940.GA8815@obsidianresearch.com>
 <20130409004253.GA2258@localhost>
 <20130409160316.GB9663@obsidianresearch.com>
Message-ID: <20130409202845.GA2251@localhost>

Hi Jason,

On Tue, Apr 09, 2013 at 10:03:16AM -0600, Jason Gunthorpe wrote:
> 
> No need to look at children at all. You can remove all the child
> parsing code, and then the driver is able to handle a wider range of
> possible DT uses.
> 

Agreed. I just sent a v6 fixing this and using of_platform_populate()
to create every child available.

How does it look?

Thanks for the feedback!
-- 
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com


From arnd at arndb.de  Tue Apr  9 16:31:18 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 9 Apr 2013 22:31:18 +0200
Subject: [GIT PULL 04/10] clk-exynos for v3.10
In-Reply-To: <51630A02.4080905@samsung.com>
References: <51630A02.4080905@samsung.com>
Message-ID: <201304092231.18314.arnd@arndb.de>

On Monday 08 April 2013, Kukjin Kim wrote:
> The following changes since commit 07961ac7c0ee8b546658717034fe692fd12eefa9:
> 
>    Linux 3.9-rc5 (2013-03-31 15:12:43 -0700)
> 
> are available in the git repository at:
> 
>    git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git 
> tags/clk-exynos-for-v3.10
> 
> for you to fetch changes up to da821eb7d42935b0f7056d98c75fd1150f6636f4:
> 
>    Merge commit 'v3.9-rc5' into next/clk-exynos (2013-04-09 01:10:13 +0900)
> 
> ----------------------------------------------------------------
> 
> add suppport common clock framework for exynos

I got a build warning, probably because of this patch:

>       ARM: dts: Add MSHC node for exynos4412-origen DT

Fixed up as below, please check.

Pulled into the next/drivers tree.

	Arnd

diff --git a/arch/arm/boot/dts/exynos4412-odroidx.dts b/arch/arm/boot/dts/exynos4412-odroidx.dts
index 15dc0a3..53bc8bf 100644
--- a/arch/arm/boot/dts/exynos4412-odroidx.dts
+++ b/arch/arm/boot/dts/exynos4412-odroidx.dts
@@ -39,6 +39,8 @@
        };
 
        mshc at 12550000 {
+               #address-cells = <1>;
+               #size-cells = <0>;
                pinctrl-0 = <&sd4_clk &sd4_cmd &sd4_bus4 &sd4_bus8>;
                pinctrl-names = "default";
                status = "okay";
diff --git a/arch/arm/boot/dts/exynos4412-origen.dts b/arch/arm/boot/dts/exynos4412-origen.dts
index a5478bd..1fecf76 100644
--- a/arch/arm/boot/dts/exynos4412-origen.dts
+++ b/arch/arm/boot/dts/exynos4412-origen.dts
@@ -45,6 +45,8 @@
        };
 
        mshc at 12550000 {
+               #address-cells = <1>;
+               #size-cells = <0>;
                pinctrl-0 = <&sd4_clk &sd4_cmd &sd4_bus4 &sd4_bus8>;
                pinctrl-names = "default";
                status = "okay";



From arnd at arndb.de  Tue Apr  9 16:37:49 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 9 Apr 2013 22:37:49 +0200
Subject: [PATCH 3/8] dmaengine: ste_dma40: Actually write the runtime
 configuration to registers
In-Reply-To: <1365532783-27425-3-git-send-email-lee.jones@linaro.org>
References: <1365532783-27425-1-git-send-email-lee.jones@linaro.org>
 <1365532783-27425-3-git-send-email-lee.jones@linaro.org>
Message-ID: <201304092237.50057.arnd@arndb.de>

On Tuesday 09 April 2013, Lee Jones wrote:
> Someone has spent a fair amount of effort writing a runtime configuration
> changing algorithm for DMA clients. However, the config appears to never
> actually make it to hardware. In order for the configuration to take hold
> we need to issue a d40_config_write(), as this is the routine which writes
> it into the hardware's registers.
> 
> Signed-off-by: Lee Jones <lee.jones at linaro.org>

Acked-by: Arnd Bergmann <arnd at arndb.de>


From arnd at arndb.de  Tue Apr  9 16:38:07 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 9 Apr 2013 22:38:07 +0200
Subject: [PATCH 5/8] dmaengine: ste_dma40: Ensure src and dst registers
 are configured correctly
In-Reply-To: <20130409190916.GF25316@gmail.com>
References: <1365532783-27425-1-git-send-email-lee.jones@linaro.org>
 <201304092057.29684.arnd@arndb.de> <20130409190916.GF25316@gmail.com>
Message-ID: <201304092238.07286.arnd@arndb.de>

On Tuesday 09 April 2013, Lee Jones wrote:
> On Tue, 09 Apr 2013, Arnd Bergmann wrote:
> 
> > On Tuesday 09 April 2013, Lee Jones wrote:
> > > Confusingly d40_log_cfg() is used to set up the logical channel
> > > configuration registers, but d40_phy_cfg() is used to configure
> > > physical and logical registers, so it should be called in both
> > > cases. It is the function call's final attribute which determines
> > > whether it's a physical or logical channel, not whether the
> > > function is called or not.
> > 
> > So how did it ever work? Your description sounds like it was
> > broken all along, but I would assume that someone tested the code.
> 
> From what I can see, not.
> 
> My best guess is that the 'test' was to see if the configuration
> changed using the debug print at the end of the function. I don't see
> how else the configuration can be written to hardware.

Acked-by: Arnd Bergmann <arnd at arndb.de>


From jgunthorpe at obsidianresearch.com  Tue Apr  9 16:38:55 2013
From: jgunthorpe at obsidianresearch.com (Jason Gunthorpe)
Date: Tue, 9 Apr 2013 14:38:55 -0600
Subject: [PATCH v6 1/5] drivers: memory: Introduce Marvell EBU Device Bus
 driver
In-Reply-To: <1365539181-29242-2-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1365539181-29242-1-git-send-email-ezequiel.garcia@free-electrons.com>
 <1365539181-29242-2-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <20130409203855.GA27797@obsidianresearch.com>

On Tue, Apr 09, 2013 at 05:26:17PM -0300, Ezequiel Garcia wrote:
> +	/*
> +	 * Since this is only part of the workaround,
> +	 * we can do this dirty 'ranges' property parsing.
> +	 * Of course, this will be removed once the address windows
> +	 * are declared in the device tree.
> +	 */
> +	err = of_property_read_u32_array(node, "ranges", addr_region,
> +					 ARRAY_SIZE(addr_region));
> +	if (err < 0) {
> +		dev_err(dev, "%s has a malformed 'range' property\n",
> +			node->full_name);
> +		return err;
> +	}

> +	/*
> +	 * Create an mbus address windows.
> +	 * FIXME: Remove this, together with the above code, once the
> +	 * address windows are declared in the device tree.
> +	 */
> +	err = mvebu_mbus_add_window(devbus_wins[cs],
> +				    addr_region[1], addr_region[2]);

Oh, this is a dangerous way to parse ranges.. 

Try something like:

const __be32 *prop;
u64 base;
u64 size;

prop = of_get_property("ranges",&psize);
if (prop == NULL || psize != of_n_addr_cells(node) + of_n_size_cells(node))
   err;
base = of_translate_address(node,prop);
if (base == OF_BAD_ADDR)
   err;
size = of_read_number(prop + of_n_addr_cells(node),of_n_size_cells(node));

err = mvebu_mbus_add_window(devbus_wins[cs],base,size);

I omitted some error checking.

Jason


From arnd at arndb.de  Tue Apr  9 16:45:19 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 9 Apr 2013 22:45:19 +0200
Subject: [GIT PULL 05/10] dt-exynos for v3.10
In-Reply-To: <51630A0E.4000600@samsung.com>
References: <51630A0E.4000600@samsung.com>
Message-ID: <201304092245.19933.arnd@arndb.de>

On Monday 08 April 2013, Kukjin Kim wrote:
> The following changes since commit da821eb7d42935b0f7056d98c75fd1150f6636f4:
> 
>    Merge commit 'v3.9-rc5' into next/clk-exynos (2013-04-09 01:10:13 +0900)
> 
> are available in the git repository at:
> 
> 
>    git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git 
> tags/dt-exynos-for-v3.10
> 
> for you to fetch changes up to 58a7bbf75442ea439a4d3b7993ad87023e406063:
> 
>    ARM: dts: add PDMA0 changes for exynos5440 (2013-04-09 01:39:27 +0900)

Pulled into next/dt2 because of the dependency. This will likely get
sent out in the second batch of pull requests to Linus.

	Arnd


From arnd at arndb.de  Tue Apr  9 16:48:53 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 9 Apr 2013 22:48:53 +0200
Subject: [GIT PULL 09/10] 2nd timer-samsung for v3.10
In-Reply-To: <51630A48.1060401@samsung.com>
References: <51630A48.1060401@samsung.com>
Message-ID: <201304092248.53883.arnd@arndb.de>

On Monday 08 April 2013, Kukjin Kim wrote:
>    git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git 
> tags/timer-samsung-for-v3.10
> 
> for you to fetch changes up to 536504309c3c2da5a755263c7179ffe1b2e5b3dd:
> 
>    ARM: SAMSUNG: change GENERIC_GPIO to ARCH_REQUIRE_GPIOLIB (2013-04-04 
> 09:36:24 +0900)

Pulled into next/drivers, thanks!

	Arnd


From nm at ti.com  Tue Apr  9 16:49:00 2013
From: nm at ti.com (Nishanth Menon)
Date: Tue, 9 Apr 2013 15:49:00 -0500
Subject: [RFC][PATCH 1/2] ARM: OMAP4: clock: Add device tree support for
 AUXCLKs
In-Reply-To: <20130409174319.GP10155@atomide.com>
References: <1363703220-4777-1-git-send-email-rogerq@ti.com>
 <1363703220-4777-2-git-send-email-rogerq@ti.com>
 <20130403234242.GE10155@atomide.com> <515D2D30.3000306@ti.com>
 <20130404164137.GH10155@atomide.com> <515EA9E3.1010409@ti.com>
 <20130405155851.GA10155@atomide.com> <5163E589.1040809@ti.com>
 <20130409164928.GL10155@atomide.com>
 <20130409174319.GP10155@atomide.com>
Message-ID: <20130409204900.GA8815@kahuna>

On 10:43-20130409, Tony Lindgren wrote:
> * Tony Lindgren <tony at atomide.com> [130409 09:54]:
> > * Roger Quadros <rogerq at ti.com> [130409 03:00]:
> > > On 04/05/2013 06:58 PM, Tony Lindgren wrote:
> > > > 
> > > > Can't you just use the clock name there to get it?
> > > 
> > > In device tree we don't pass around clock names. You can either get
> > > a phandle or an index to the clock.
> > > 
> > > e.g. Documentation/devicetree/bindings/clock/imx31-clock.txt
> > 
> > Yes I understand that. But the driver/clock/omap driver can just
> > remap the DT device initially so the board specific clock is
> > found from the clock alias table. Basically initially a passthrough
> > driver that can be enhanced to parse DT clock bindings and load
> > data from /lib/firmware.
> 
> Actually probably the driver/clock/omap can even do even less
> initially. There probably even no need to remap clocks there.
> 
> As long as the DT clock driver understands that a board specific
> auxclk is specified in the DT it can just call clk_add_alias() so
> the driver will get the right auxclk from cclock44xx_data.c.
> 
> Then other features can be added later on like to allocate a
> clock entirely based on the binding etc.
I did try to have an implementation for cpufreq using clock nodes.
unfortunately, device tree wont let me have arguments of strings :(
So, I am unable to do clock = <&clk mpu_dpll>;
instead, I am forced to do clock = <&clk 249>;

Here is an attempt on beagleXM - adds every clock node to the list.
Tons of un-necessary prints added to give an idea - see log:
http://pastebin.com/F9A2zSTr

Would an cleaned up version be good enough as a step #1 of transition?

>From 7d373bdb9e9549c1b6ba1775a8dfd96ebe78abfb Mon Sep 17 00:00:00 2001
From: Nishanth Menon <nm at ti.com>
Date: Tue, 26 Mar 2013 10:23:27 +0000
Subject: [PATCH] OMAP: add devicetree support for clock nodes.

Dummy patch based on Roger's original idea

Nyet-Signed-off-by: Nishanth Menon <nm at ti.com>
---
 arch/arm/boot/dts/omap3.dtsi          |    5 ++
 arch/arm/boot/dts/omap34xx.dtsi       |    2 +
 arch/arm/mach-omap2/cclock3xxx_data.c |    3 +-
 arch/arm/mach-omap2/cclock44xx_data.c |    3 +-
 arch/arm/mach-omap2/pm.c              |   11 +++-
 drivers/clk/Kconfig                   |    6 ++
 drivers/clk/Makefile                  |    2 +
 drivers/clk/ti.c                      |  100 +++++++++++++++++++++++++++++++++
 include/linux/clk/ti.h                |   30 ++++++++++
 9 files changed, 157 insertions(+), 5 deletions(-)
 create mode 100644 drivers/clk/ti.c
 create mode 100644 include/linux/clk/ti.h

diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 3344f05..a08990d 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -73,6 +73,11 @@
 			ti,hwmods = "counter_32k";
 		};
 
+		clks: clocks {
+			compatible = "ti,clock";
+			#clock-cells = <1>;
+		};
+
 		intc: interrupt-controller at 48200000 {
 			compatible = "ti,omap2-intc";
 			interrupt-controller;
diff --git a/arch/arm/boot/dts/omap34xx.dtsi b/arch/arm/boot/dts/omap34xx.dtsi
index 75ed4ae..93c2621 100644
--- a/arch/arm/boot/dts/omap34xx.dtsi
+++ b/arch/arm/boot/dts/omap34xx.dtsi
@@ -23,6 +23,8 @@
 				600000  1350000
 			>;
 			clock-latency = <300000>; /* From legacy driver */
+			clocks = <&clks 249>; /* index to cpufreq_ck */
+			clock-names = "cpu";
 		};
 	};
 };
diff --git a/arch/arm/mach-omap2/cclock3xxx_data.c b/arch/arm/mach-omap2/cclock3xxx_data.c
index 4579c3c..d5d5ef5 100644
--- a/arch/arm/mach-omap2/cclock3xxx_data.c
+++ b/arch/arm/mach-omap2/cclock3xxx_data.c
@@ -22,6 +22,7 @@
 #include <linux/clk-private.h>
 #include <linux/list.h>
 #include <linux/io.h>
+#include <linux/clk/ti.h>
 
 #include "soc.h"
 #include "iomap.h"
@@ -3574,7 +3575,7 @@ int __init omap3xxx_clk_init(void)
 	for (c = omap3xxx_clks; c < omap3xxx_clks + ARRAY_SIZE(omap3xxx_clks);
 	     c++)
 		if (c->cpu & cpu_clkflg) {
-			clkdev_add(&c->lk);
+			ti_clk_node_add(&c->lk);
 			if (!__clk_init(NULL, c->lk.clk))
 				omap2_init_clk_hw_omap_clocks(c->lk.clk);
 		}
diff --git a/arch/arm/mach-omap2/cclock44xx_data.c b/arch/arm/mach-omap2/cclock44xx_data.c
index 0c6834a..338ef64 100644
--- a/arch/arm/mach-omap2/cclock44xx_data.c
+++ b/arch/arm/mach-omap2/cclock44xx_data.c
@@ -27,6 +27,7 @@
 #include <linux/clk-private.h>
 #include <linux/clkdev.h>
 #include <linux/io.h>
+#include <linux/clk/ti.h>
 
 #include "soc.h"
 #include "iomap.h"
@@ -1697,7 +1698,7 @@ int __init omap4xxx_clk_init(void)
 	for (c = omap44xx_clks; c < omap44xx_clks + ARRAY_SIZE(omap44xx_clks);
 									c++) {
 		if (c->cpu & cpu_clkflg) {
-			clkdev_add(&c->lk);
+			ti_clk_node_add(&c->lk);
 			if (!__clk_init(NULL, c->lk.clk))
 				omap2_init_clk_hw_omap_clocks(c->lk.clk);
 		}
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index 8d15f9a..6cf95160 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -267,7 +267,12 @@ static void __init omap4_init_voltages(void)
 
 static inline void omap_init_cpufreq(void)
 {
-	struct platform_device_info devinfo = { .name = "omap-cpufreq", };
+	struct platform_device_info devinfo = { };
+
+	if (!of_have_populated_dt())
+		devinfo.name = "omap-cpufreq";
+	else
+		devinfo.name = "cpufreq-cpu0";
 	platform_device_register_full(&devinfo);
 }
 
@@ -301,9 +306,9 @@ int __init omap2_common_pm_late_init(void)
 		/* Smartreflex device init */
 		omap_devinit_smartreflex();
 
-		/* cpufreq dummy device instantiation */
-		omap_init_cpufreq();
 	}
+	/* cpufreq dummy device instantiation */
+	omap_init_cpufreq();
 
 #ifdef CONFIG_SUSPEND
 	suspend_set_ops(&omap_pm_ops);
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index a47e6ee..03c6e48 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -55,6 +55,12 @@ config COMMON_CLK_MAX77686
 	---help---
 	  This driver supports Maxim 77686 crystal oscillator clock. 
 
+config COMMON_CLK_TI
+	tristate "Clock driver for TI SoCs"
+	depends on ARCH_OMAP && OF
+	---help---
+	  Fill me up.. some generic statement ofcourse (lets start with OMAP)
+
 config CLK_TWL6040
 	tristate "External McPDM functional clock from twl6040"
 	depends on TWL6040_CORE
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 300d477..9621815 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -30,6 +30,8 @@ obj-$(CONFIG_ARCH_TEGRA)	+= tegra/
 
 obj-$(CONFIG_X86)		+= x86/
 
+obj-$(CONFIG_COMMON_CLK_TI)	+= ti.o
+
 # Chip specific
 obj-$(CONFIG_COMMON_CLK_WM831X) += clk-wm831x.o
 obj-$(CONFIG_COMMON_CLK_MAX77686) += clk-max77686.o
diff --git a/drivers/clk/ti.c b/drivers/clk/ti.c
new file mode 100644
index 0000000..c747381
--- /dev/null
+++ b/drivers/clk/ti.c
@@ -0,0 +1,100 @@
+/*
+ * TI Clock node provider
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ *	Nishanth Menon
+ *
+ * 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.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+#include <linux/kernel.h>
+#include <linux/list.h>
+#include <linux/clk-private.h>
+#include <linux/clkdev.h>
+#include <linux/io.h>
+#include <linux/of.h>
+#include <linux/clk/ti.h>
+
+struct ti_clk {
+	struct clk_lookup *lk;
+	struct list_head node;
+};
+
+static LIST_HEAD(ti_clk_list);
+
+static struct clk *ti_bypass_clk_get_by_name(struct of_phandle_args *clkspec,
+					     void *data)
+{
+	struct ti_clk *c;
+#if 0
+	/* Eww.. IF ONLY phandle arguments could be string */
+	char clk_name[32]; /* 32 is max size of property name */
+
+	char *name = clkspec->args[0];
+
+	snprintf(clk_name, 32, "%s_ck", name);
+	list_for_each_entry(c, &ti_clk_list, node) {
+		int r = strncmp(c->lk->conn_id, clk_name, 32);
+		pr_err("%s: searching %s in %s - %d\n",
+			__func__, clk_name, c->lk->con_id, r);
+		if (!r) {
+			pr_err("%s: found it!\n", __func__);
+			return c->lk.clk;
+		}
+	}
+#else
+	/* Use integer indexing into clkdev list! Sigh.. */
+	int idx = clkspec->args[0];
+	int cindex = 1;
+
+	list_for_each_entry(c, &ti_clk_list, node) {
+		int r = (idx == cindex) ? 0 :  1;
+		pr_err("%s: searching index search = %d in %d in %s - %d\n",
+			__func__, idx, cindex, c->lk->con_id, r);
+		if (!r) {
+			pr_err("%s: found it!\n", __func__);
+			return c->lk->clk;
+		}
+		cindex++;
+	}
+#endif
+
+	pr_err("%s: ran out of options\n", __func__);
+	return ERR_PTR(-ENODEV);
+}
+
+static void __init ti_clock_init(struct device_node *node)
+{
+
+	pr_err("%s: START\n", __func__);
+	of_clk_add_provider(node, ti_bypass_clk_get_by_name, NULL);
+	pr_err("%s: END\n", __func__);
+}
+CLK_OF_DECLARE(ti_clk, "ti,clock", ti_clock_init);
+
+void __init ti_clk_node_add(struct clk_lookup *lk)
+{
+	struct ti_clk *c;
+	static bool of_added;
+
+	c = kzalloc(sizeof(struct ti_clk), GFP_KERNEL);
+	if (!c) {
+		pr_err("%s: No memory!! cannot add clk node!\n", __func__);
+		return;
+	}
+	clkdev_add(lk);
+	c->lk = lk;
+	list_add_tail(&c->node, &ti_clk_list);
+	pr_err("%s: Added clock node %s\n", __func__, lk->con_id);
+	if (!of_added) {
+		of_clk_init(NULL);
+		of_added =  true;
+	}
+};
+
diff --git a/include/linux/clk/ti.h b/include/linux/clk/ti.h
new file mode 100644
index 0000000..eb502a8
--- /dev/null
+++ b/include/linux/clk/ti.h
@@ -0,0 +1,30 @@
+/*
+ * TI Clock node provider header
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ *	Nishanth Menon
+ *
+ * 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.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+#ifndef __TI_CLK_H
+#define __TI_CLK_H
+
+#include <linux/clkdev.h>
+
+#ifdef CONFIG_OF
+extern void ti_clk_node_add(struct clk_lookup *lk);
+#else
+static inline void ti_clk_node_add(struct clk_lookup *lk)
+{
+	clkdev_add(lk);
+}
+#endif /* CONFIG_OF */
+
+#endif	/* __TI_CLK_H */
-- 
1.7.9.5


-- 
Regards,
Nishanth Menon


From arnd at arndb.de  Tue Apr  9 16:49:13 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 9 Apr 2013 22:49:13 +0200
Subject: [GIT PULL 07/10] pmu-exynos for v3.10
In-Reply-To: <51630A2C.7060409@samsung.com>
References: <51630A2C.7060409@samsung.com>
Message-ID: <201304092249.14136.arnd@arndb.de>

On Monday 08 April 2013, Kukjin Kim wrote:
> The following changes since commit da821eb7d42935b0f7056d98c75fd1150f6636f4:
> 
>    Merge commit 'v3.9-rc5' into next/clk-exynos (2013-04-09 01:10:13 +0900)
> 
> are available in the git repository at:
> 
> 
>    git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git 
> tags/pmu-exynos-for-v3.10
> 
> for you to fetch changes up to db35234ec7a7a10145cf472f68e1c73fbd48f79c:
> 
>    ARM: EXYNOS: Add arm-pmu DT binding for exynos421x (2013-04-09 
> 01:49:16 +0900)
> 
> ----------------------------------------------------------------
> add support arm-pmu for exynos4 and exynos5250

Pulled into next/drivers, thanks!

	Arnd


From ezequiel.garcia at free-electrons.com  Tue Apr  9 16:49:47 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Tue, 9 Apr 2013 17:49:47 -0300
Subject: [PATCH v6 1/5] drivers: memory: Introduce Marvell EBU Device Bus
 driver
In-Reply-To: <20130409203855.GA27797@obsidianresearch.com>
References: <1365539181-29242-1-git-send-email-ezequiel.garcia@free-electrons.com>
 <1365539181-29242-2-git-send-email-ezequiel.garcia@free-electrons.com>
 <20130409203855.GA27797@obsidianresearch.com>
Message-ID: <20130409204946.GA2294@localhost>

On Tue, Apr 09, 2013 at 02:38:55PM -0600, Jason Gunthorpe wrote:
> On Tue, Apr 09, 2013 at 05:26:17PM -0300, Ezequiel Garcia wrote:
> > +	/*
> > +	 * Since this is only part of the workaround,
> > +	 * we can do this dirty 'ranges' property parsing.
> > +	 * Of course, this will be removed once the address windows
> > +	 * are declared in the device tree.
> > +	 */
> > +	err = of_property_read_u32_array(node, "ranges", addr_region,
> > +					 ARRAY_SIZE(addr_region));
> > +	if (err < 0) {
> > +		dev_err(dev, "%s has a malformed 'range' property\n",
> > +			node->full_name);
> > +		return err;
> > +	}
> 
> > +	/*
> > +	 * Create an mbus address windows.
> > +	 * FIXME: Remove this, together with the above code, once the
> > +	 * address windows are declared in the device tree.
> > +	 */
> > +	err = mvebu_mbus_add_window(devbus_wins[cs],
> > +				    addr_region[1], addr_region[2]);
> 
> Oh, this is a dangerous way to parse ranges.. 
> 
> Try something like:
> 
> const __be32 *prop;
> u64 base;
> u64 size;
> 
> prop = of_get_property("ranges",&psize);
> if (prop == NULL || psize != of_n_addr_cells(node) + of_n_size_cells(node))
>    err;
> base = of_translate_address(node,prop);
> if (base == OF_BAD_ADDR)
>    err;
> size = of_read_number(prop + of_n_addr_cells(node),of_n_size_cells(node));
> 
> err = mvebu_mbus_add_window(devbus_wins[cs],base,size);
>

No problem, I'll try something like the above.

Mind explaining me why do you think it's dangerous
or in what cases do you expect the other (dirty) solution to break?
-- 
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com


From arnd at arndb.de  Tue Apr  9 16:52:50 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 9 Apr 2013 22:52:50 +0200
Subject: [GIT PULL 08/10] secure-exynos for v3.10
In-Reply-To: <51630A36.6030505@samsung.com>
References: <51630A36.6030505@samsung.com>
Message-ID: <201304092252.50718.arnd@arndb.de>

On Monday 08 April 2013, Kukjin Kim wrote:
> 
> The following changes since commit da821eb7d42935b0f7056d98c75fd1150f6636f4:
> 
>    Merge commit 'v3.9-rc5' into next/clk-exynos (2013-04-09 01:10:13 +0900)
> 
> are available in the git repository at:
> 
> 
>    git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git 
> tags/secure-exynos-for-v3.10
> 
> for you to fetch changes up to beddf63fc8e01f06799bd6d7a2dd879885bbc9c6:
> 
>    ARM: EXYNOS: Add secure firmware support to secondary CPU bring-up 
> (2013-04-09 01:52:30 +0900)

I've created a separate top-level branch next/firmware for this, since
we are waiting for a similar pull request from Broadcom.

	Arnd


From sameo at linux.intel.com  Tue Apr  9 16:55:04 2013
From: sameo at linux.intel.com (Samuel Ortiz)
Date: Tue, 9 Apr 2013 22:55:04 +0200
Subject: [PATCH 2/2 v2] mfd: db8500-prcmu: Support platform dependant
 device selection
In-Reply-To: <20130409195258.GH25316@gmail.com>
References: <1365071941-23475-1-git-send-email-lee.jones@linaro.org>
 <1365071941-23475-2-git-send-email-lee.jones@linaro.org>
 <20130409195258.GH25316@gmail.com>
Message-ID: <20130409205504.GC24058@zurbaran>

Hi Lee,

On Tue, Apr 09, 2013 at 08:52:58PM +0100, Lee Jones wrote:
> The main aim for this cycle is to have the u8540 booting to a
> console. However, the u8540 doesn't support all of the u8500
> platform devices yet. After this stage is complete we can then
> fill in the inadequacies, such as specific clock support at a
> later date. To achieve this we're placing devices supported by
> all platforms into a common device structure and the remaining
> ones into a platform specific one.
> 
> Cc: Samuel Ortiz <sameo at linux.intel.com>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>
> ---
>  drivers/mfd/db8500-prcmu.c |   32 ++++++++++++++++++++++++--------
>  1 file changed, 24 insertions(+), 8 deletions(-)
Applied and pushed now, thanks.

Cheers,
Samuel.

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


From rtivy at ti.com  Tue Apr  9 16:56:54 2013
From: rtivy at ti.com (Tivy, Robert)
Date: Tue, 9 Apr 2013 20:56:54 +0000
Subject: [PATCH v9 1/6] rpmsg: Process all available messages in
 virtqueue callback
In-Reply-To: <CAK=WgbbpJuh8M4FLEgQKzbOPadJFHO=gvpA2jVOrN5N1g=1f2w@mail.gmail.com>
References: <1364521307-1219-1-git-send-email-rtivy@ti.com>
 <1364521307-1219-2-git-send-email-rtivy@ti.com>
 <CAK=WgbaCtACsvt9cqQmGqXsADFb_3bfnNKeWq9iijR2vkYVuQQ@mail.gmail.com>
 <13514BD7FAEBA745BBD7D8A672905C1431230345@DFLE12.ent.ti.com>
 <CAK=WgbbpJuh8M4FLEgQKzbOPadJFHO=gvpA2jVOrN5N1g=1f2w@mail.gmail.com>
Message-ID: <13514BD7FAEBA745BBD7D8A672905C1431230582@DFLE12.ent.ti.com>

Just one small fix needed (see below) and it's good-to-go.

> -----Original Message-----
> From: Ohad Ben-Cohen [mailto:ohad at wizery.com]
> Sent: Tuesday, April 09, 2013 1:26 AM
> 
> On Tue, Apr 9, 2013 at 1:56 AM, Tivy, Robert <rtivy at ti.com> wrote:
> > Shouldn't the virtqueue_kick() be called only when we successfully
> added a buffer with virtqueue_add_buf()?
> 
> Definitely, thanks for noticing!
> 
> Take 2:
> 
> diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c
> b/drivers/rpmsg/virtio_rpmsg_bus.c
> index a59684b..4ade672 100644
> --- a/drivers/rpmsg/virtio_rpmsg_bus.c
> +++ b/drivers/rpmsg/virtio_rpmsg_bus.c
> @@ -776,22 +776,11 @@ out:
>  }
>  EXPORT_SYMBOL(rpmsg_send_offchannel_raw);
> 
> -/* called when an rx buffer is used, and it's time to digest a message
> */
> -static void rpmsg_recv_done(struct virtqueue *rvq)
> +static int rpmsg_recv_single(struct virtproc_info *vrp, struct device
> *dev,
> +                            struct rpmsg_hdr *msg, unsigned int len)
>  {
> -       struct rpmsg_hdr *msg;
> -       unsigned int len;
>         struct rpmsg_endpoint *ept;
>         struct scatterlist sg;
> -       struct virtproc_info *vrp = rvq->vdev->priv;
> -       struct device *dev = &rvq->vdev->dev;
> -       int err;

This new function also uses an 'int err;', so the above line should not be removed.

> -
> -       msg = virtqueue_get_buf(rvq, &len);
> -       if (!msg) {
> -               dev_err(dev, "uhm, incoming signal, but no used buffer
> ?\n");
> -               return;
> -       }
> 
>         dev_dbg(dev, "From: 0x%x, To: 0x%x, Len: %d, Flags: %d,
> Reserved: %d\n",
>                                         msg->src, msg->dst, msg->len,
> @@ -806,7 +795,7 @@ static void rpmsg_recv_done(struct virtqueue *rvq)
>         if (len > RPMSG_BUF_SIZE ||
>                 msg->len > (len - sizeof(struct rpmsg_hdr))) {
>                 dev_warn(dev, "inbound msg too big: (%d, %d)\n", len,
> msg->len);
> -               return;
> +               return -EINVAL;
>         }
> 
>         /* use the dst addr to fetch the callback of the appropriate
> user */
> @@ -842,11 +831,42 @@ static void rpmsg_recv_done(struct virtqueue
> *rvq)
>         err = virtqueue_add_buf(vrp->rvq, &sg, 0, 1, msg, GFP_KERNEL);
>         if (err < 0) {
>                 dev_err(dev, "failed to add a virtqueue buffer: %d\n",
> err);
> +               return err;
> +       }
> +
> +       return 0;
> +}
> +
> +/* called when an rx buffer is used, and it's time to digest a message
> */
> +static void rpmsg_recv_done(struct virtqueue *rvq)
> +{
> +       struct virtproc_info *vrp = rvq->vdev->priv;
> +       struct device *dev = &rvq->vdev->dev;
> +       struct rpmsg_hdr *msg;
> +       unsigned int len, msgs_received = 0;
> +       int err;
> +
> +       msg = virtqueue_get_buf(rvq, &len);
> +       if (!msg) {
> +               dev_err(dev, "uhm, incoming signal, but no used buffer
> ?\n");
>                 return;
>         }
> 
> +       while (msg) {
> +               err = rpmsg_recv_single(vrp, dev, msg, len);
> +               if (err)
> +                       break;
> +
> +               msgs_received++;
> +
> +               msg = virtqueue_get_buf(rvq, &len);
> +       };
> +
> +       dev_dbg(dev, "Received %u messages\n", msgs_received);
> +
>         /* tell the remote processor we added another available rx
> buffer */
> -       virtqueue_kick(vrp->rvq);
> +       if (msgs_received)
> +               virtqueue_kick(vrp->rvq);
>  }
> 
>  /*
> 
> > Thanks for the rewrite, looks better.  I'll give it a try and let you
> know how it goes.
> 
> Thanks!
> Ohad.

I added the above-mentioned 'int err;' to my tree's rpmsg_recv_single() and tested it out, it worked well.  So once that is corrected, you can add:
Acked-by: Robert Tivy <rtivy at ti.com>

Regards,

- Rob



From paul at pwsan.com  Tue Apr  9 16:59:27 2013
From: paul at pwsan.com (Paul Walmsley)
Date: Tue, 9 Apr 2013 20:59:27 +0000 (UTC)
Subject: [PATCH] ARM: OMAP4: HWMOD: make 'ocp2scp_usb_phy_phy_48m" as
 the main clock
In-Reply-To: <1365496101-7829-1-git-send-email-kishon@ti.com>
References: <1365496101-7829-1-git-send-email-kishon@ti.com>
Message-ID: <alpine.DEB.2.00.1304092058450.26840@utopia.booyaka.com>

Hi

On Tue, 9 Apr 2013, Kishon Vijay Abraham I wrote:

> commit 92702d (ARM: OMAP4: PM: fix PM regression introduced by recent
> clock cleanup) makes the 'ocp2scp_usb_phy_phy_48m' as optional
> functional clock causing regression in MUSB. But this 48MHz clock is a
> mandatory clock for usb phy attached to ocp2scp and hence made as the main
> clock for ocp2scp.
> 
> Cc: Keerthy <j-keerthy at ti.com>
> Cc: Beno?t Cousson <b-cousson at ti.com>
> Cc: Paul Walmsley <paul at pwsan.com>
> Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>

This patch is missing the "big comment" that I requested in the hwmod 
data:

http://marc.info/?l=linux-omap&m=136544098331552&w=2

Once that's added, it should be good to go.


- Paul

From daniel.lezcano at linaro.org  Tue Apr  9 17:03:55 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Tue, 09 Apr 2013 23:03:55 +0200
Subject: [GIT PULL 2/5] omap pm clean-up for v3.10 merge window
In-Reply-To: <874nffip2d.fsf@linaro.org>
References: <0MarPy-1U9XGk2D8s-00Ks1o@mx.kundenserver.de>
 <201304091652.28385.arnd@arndb.de> <87vc7virqz.fsf@linaro.org>
 <20130409165633.GN10155@atomide.com> <874nffip2d.fsf@linaro.org>
Message-ID: <5164823B.8070301@linaro.org>

On 04/09/2013 07:36 PM, Kevin Hilman wrote:
> Tony Lindgren <tony at atomide.com> writes:
> 
>> * Kevin Hilman <khilman at linaro.org> [130409 09:43]:
>>> Arnd Bergmann <arnd at arndb.de> writes:
>>>
>>>> On Tuesday 09 April 2013, Tony Lindgren wrote:
>>>>> The following changes since commit 07961ac7c0ee8b546658717034fe692fd12eefa9:
>>>>>
>>>>>   Linux 3.9-rc5 (2013-03-31 15:12:43 -0700)
>>>>>
>>>>> are available in the git repository at:
>>>>>
>>>>>   git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.10/cleanup-pm-signed
>>>>>
>>>>> for you to fetch changes up to ca8cdff548da76da01f3783548ceb917139a5ddc:
>>>>>
>>>>>   Merge tag 'omap-pm-v3.10/cleanup/cpuidle' of
>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm
>>>>> into omap-for-v3.10/cleanup-pm (2013-04-08 09:51:00 -0700)
>>>>>
>>>>> ----------------------------------------------------------------
>>>>>
>>>>> PM cleanup to prepare for omap5 PM via Kevin Hilman <khilman at linaro.org>:
>>>>>
>>>>> OMAP3/4 CPUidle cleanups for v3.10
>>>>
>>>> Adding Daniel and Rafael to Cc.

Kevin,

I just want to point you this patch:

https://git.linaro.org/gitweb?p=people/dlezcano/cpuidle-next.git;a=commit;h=e03a37fdf942a25154ccb5539524afd336f130bb

I did not yet send it to Rafael.


>>>> Is this series coordinated with the other cpuidle changes? Please tell me if this
>>>> is good to go into arm-soc.
>>>
>>> Hmm, looks like it's not ready.  There are some minor conflicts with
>>> what Rafael has queued up from Daniel.
>>>
>>> I will work this out with Daniel to figure out how we should proceed.
>>
>> OK it seems that this branch can also be queued by Rafael after
>> updating it if there's a dependency. So far it's not conflicting
>> with anything else we have queued up for arm soc tree.
> 
> Right, I just did a test rebase onto the relevant commit in Rafael
> linux-next branch, and fixed up all the conflicts[1].
> 
> If Rafael agrees, it's fine with me if it goes via him.
> 
> Rafael, the signed tag for the updated branch is below[1], based on the
> commit in your linux-next branch where you merged the rest of the
> CPUidle changes.  Let me know if you want a different base commit, or an
> official pull request.
> 
> Kevin
> 
> [1] git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git tags/omap-pm-v3.10/cleanup/cpuidle-v2



-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From akpm at linux-foundation.org  Tue Apr  9 17:04:32 2013
From: akpm at linux-foundation.org (Andrew Morton)
Date: Tue, 9 Apr 2013 14:04:32 -0700
Subject: [PATCH v3] [RESEND] mm: Make snapshotting pages for stable
 writes a per-bio operation
In-Reply-To: <20130409180617.GB8907@blackbox.djwong.org>
References: <20130409180617.GB8907@blackbox.djwong.org>
Message-ID: <20130409140432.cd69f999302a02caf73788fc@linux-foundation.org>

On Tue, 9 Apr 2013 11:06:17 -0700 "Darrick J. Wong" <darrick.wong at oracle.com> wrote:

> +		 * Here we write back pagecache data that may be mmaped. Since
> +		 * we cannot afford to clean the page and set PageWriteback
> +		 * here due to lock ordering (page lock ranks above transaction
> +		 * start), the data can change while IO is in flight. Tell the
> +		 * block layer it should bounce the bio pages if stable data
> +		 * during write is required.

I think there are already ab/ba deadlocks between lock_page() and
journal_start().  iirc one path was write(), I forget which was the
other path.  This was 10+ years ago and nobody else noticed and I
didn't know how to fix it so I didn't tell anyone ;)

It would be neat to be able to hook things like journal_start() into
lockdep but I don't think that lockdep has easy provision for wiring
oddball things into its mechanisms.



From thomas.petazzoni at free-electrons.com  Tue Apr  9 17:06:21 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Tue,  9 Apr 2013 23:06:21 +0200
Subject: [PATCHv8 00/19] PCIe support for the Armada 370 and Armada XP SoCs
Message-ID: <1365541601-14095-1-git-send-email-thomas.petazzoni@free-electrons.com>

Hello,

This series of patches introduces PCIe support for the Marvell Armada
370 and Armada XP. In the future, we plan to extend the driver to
cover Kirkwood platforms, and possibly other Marvell EBU platforms as
well.

Here is the current status of the different patches:

 * Patches 1-5 are awaiting a formal Acked-by from the Device Tree
   maintainers. Patches 1-3 are the new version of the OF PCI range
   parsing functions from Andrew Murray, which he worked on after the
   comments from Rob Herring. Patches 4 and 5 are much more trivial
   and have been around since many versions of this series.

 * Patch 6 and 10, that are touching drivers/pci/ have been formally
   Acked-by Bjorn Helgaas, the PCI maintainer.

 * Patch 7, which is touching arch/arm/kernel, has been merged by
   Russell King already, see
   http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=7683/1.

 * Patches 8 and 9 are touching drivers/clk, and are awaiting an
   Acked-by from Mike Turquette. However, they are fairly trivial
   patches, so they shouldn't cause too much problem.

 * All the other patches touch mvebu-specific things, either
   mach-mvebu or the related Device Tree files or defconfig, so it's
   up to the Marvell maintainers to pick them up.

This patch set depends on:

 * The arm-soc/mvebu/cleanup branch in Arnd and Olof arm-soc tree

 * [PATCH v3 for 3.10] Introduce a Marvell EBU MBus driver
   http://lists.infradead.org/pipermail/linux-arm-kernel/2013-March/156883.html

For easier testing, the code has been pushed to:

  git://github.com/MISL-EBU-System-SW/mainline-public.git marvell-pcie-v8

This PATCHv8 follows:
 * PATCHv7, sent on March, 27th 2013
 * PATCHv6, sent on March, 26st 2013
 * PATCHv5, sent on March, 21st 2013
 * PATCHv4, sent on March, 8th 2013
 * PATCHv3, sent on February, 12th 2013
 * PATCHv2, sent on January, 28th 2013
 * RFCv1, sent on December, 7th 2012

Changes between v7 and v8:

 * In the patch introducing the drivers/pci/host directory, add an
   empty drivers/pci/host/Makefile to ensure that the kernel still
   build. This Makefile will actually gets its first useful line when
   the Marvell PCIe driver gets added. Noted by Neil Greatorex.

 * Remove bogus (and useless) CFLAGS in drivers/pci/host/Makefile for
   the compilation of the Marvell PCIe driver. Noticed by Bjorn
   Helgaas.

 * Added missing parenthesis in the definition of the
   PCIE_BAR_CTRL_OFF macro. Noticed by Bjorn Helgaas.

 * Make mvebu_pcie_link_up() return 'bool' instead of 'int'. Suggested
   by Bjorn Helgaas.

 * Change mvebu_pcie_link_up(), mvebu_pcie_set_local_bus_nr(),
   mvebu_pcie_setup_wins(), mvebu_pcie_setup_hw(),
   mvebu_pcie_hw_rd_conf(), mvebu_pcie_hw_wr_conf() so that they take
   a 'struct mvebu_pcie_port *' instead of a 'void __iomem *' as first
   argument. The base address of the PCIe interface register are
   available using the 'base' field of 'struct
   mvebu_pcie_port'. Suggested by Bjorn Helgaas.

 * Fixed multi-line comments that should have been one line
   comments. Noticed by Bjorn Helgaas.

 * Fixed a for() loop in mvebu_pcie_setup_wins() to use the more
   conventional 'ii < 3' ending condition instead of 'i <=
   2'. Suggested by Bjorn Helgaas.

 * Add a #define instead of an hardcoded magic value when enabling
   interrupts A-D in mvebu_pcie_setup_hw(). Suggested by Bjorn
   Helgaas.

 * Add a PCIE_CONF_ADDR() to simplify the code in
   mvebu_pcie_hw_rd_conf() and mvebu_pcie_hw_wr_conf(). Suggested by
   Bjorn Helgaas.

 * Clarify the comments in mvebu_pcie_handle_iobase_change() and
   mvebu_pcie_handle_membase_change() so that it is clear we look at
   the new iobase/iolimit (respectively membase/memlimit)
   values. Suggested by Bjorn Helgaas.

 * Replace mvebu_pcie_find_port_by_bus() and
   mvebu_pcie_find_port_by_devfn() by a single mvebu_pcie_find_port()
   function, and simplify the mvebu_pcie_rd_conf() and
   mvebu_pcie_wr_conf() functions. Suggested by Bjorn Helgaas.

 * Fix the computation of the real I/O resource start and end
   addresses, according to the suggestions of Arnd Bergmann and Jason
   Gunthorpe.

 * Remove the MASK/OFFS definition, and use definitions more in the
   style of pci_regs.h. Suggested by Bjorn Helgaas.

 * Integrate the latest version of 'of/pci: Provide support for
   parsing PCI DT ranges property' from Andrew Murray, fixed according
   to the review of Rob Herring.

 * Added the Acked-by tags from Bjorn Helgaas on the PCI patches.

Changes between v6 and v7:

 * Use assigned-addresses in the DT subnodes for the MMIO PCIe
   registers, in order to align with what Thierry is doing on the
   Tegra PCIe driver.

 * Added empty 'ranges;' properties in the subnodes, as requested by
   Arnd. Note that due to this, it is not possible to remove the
   #address-cells and #size-cells properties from the subnodes, as
   Jason Gunthorpe requested, otherwise the DT compiler complains with:

     Warning (ranges_format): /soc/pcie-controller/pcie at 1,0 has empty
     "ranges" property but its #address-cells (2) differs from
     /soc/pcie-controller (3)

     Warning (ranges_format): /soc/pcie-controller/pcie at 1,0 has empty
     "ranges" property but its #size-cells (1) differs from
     /soc/pcie-controller (2)

 * Use the new RFCv3 patch from Andrew Murray for 'of/pci: Provide
   support for parsing PCI DT ranges property'.

 * Updated the DT binding documentation accordingly.

Changes between v5 and v6:

 * Use pci_create_root_bus() + pci_scan_child_bus() instead of
   pci_scan_root_bus(). This is needed to be able to add MSI support
   later on. Moreover Thierry Reding suggested that
   pci_scan_root_bus() "does a pci_bus_add_devices(), which is called
   again in pci_common_init() in the ARM code". Thanks Thierry for
   pointing out this issue.

Changes between v4 and v5:

 * Rebased on top of 3.9-rc2 + the new mvebu-mbus driver (v3).

 * Changed the names of the PCI DT sub-nodes to match the OF
   specifications: they should be named pcie at DD,FF where DD is the
   device number and FF the function number. Requested by Mitch
   Bradley.

 * Add the device_type = "pci" property at the pcie-controller
   level. Requested by Mitch Bradley.

 * Drop patch 'of/pci: Add of_pci_get_bus() function' because it
   wasn't actually used in the rest of the patch series.

 * Updated the patch 'of/pci: Provide support for parsing PCI DT
   ranges property' to use the latest version proposed by Andrew
   Murray on the devicetree-discuss@ mailing list.

Changes between v3 and v4:

 * Rebased on top of 3.9-rc1.

 * Drop patch "ARM: pci: Allow passing per-controller private data"
   because it was merged in 3.9.

 * Drop patch "lib: devres: don't enclose pcim_*() functions in
   CONFIG_HAS_IOPORT", because it was merged in 3.9.

 * Added CONFIG_PCI_MVEBU=y in mvebu_defconfig, so that the right PCI
   host controller driver is automatically enabled.

 * Instead of using the DT 'ranges' property to encode the PCIe
   register ranges, use a 'reg' property on the main PCIe controller
   DT node together with a 'reg-names' property. Suggested by Jason
   Gunthorpe.

 * Don't select PCI_SW_HOST_BRIDGE and PCI_SW_PCI_PCI_BRIDGE, they
   don't exist anymore. Reported by Bjorn Helgaas.

 * Added support for the Armada XP GP board.

 * Fix the 'ranges' property so that the memory range is an identity
   map between CPU addresses and bus addresses. Suggested by Arnd
   Bergmann.

 * Changed the 'ranges' property to have the I/O region after the
   memory region.

 * Use the new mvebu-mbus driver API to create/remove address decoding
   windows when needed. This remove the need to include
   <mach/addr-map.h>. Requested by Arnd Bergmann.

 * Include directly into the driver the few common PCIe functions we
   were using from arch/arm/plat-orion/pcie.c. This allows to remove
   the inclusion of <plat/pcie.h>. Requested by Arnd Bergmann.

 * Directly set up the address decoding windows when the memory
   base/limit and I/O base/limit are configured in the PCI-to-PCI
   bridge instead of relying on the memory and I/O accesses being
   enabled in the PCI_COMMAND register. Suggested by Bjorn Helgaas.

 * Added some comments on top of the calculations of the I/O
   base/limit and memory base/limit. Suggested by Arnd Bergmann.

 * Changed a bit the way the "realio" resource is created, from
   suggestions given by Arnd Bergmann.

 * Updated the Device Tree binding documentation. Reported by Jason
   Gunthorpe.

 * Instead of using "marvell,armada-370-xp-pcie" as the DT compatible
   string, use two separate compatible strings:
   "marvell,armada-370-pcie" and "marvell,armada-xp-pcie". For now,
   the driver does the same thing for both.

Changes between v2 and v3:

 * Use of_irq_map_pci() instead of of_irq_map_raw(), as suggested by
   Andrew Murray. In order to do this, we moved the interrupt-map and
   interrupt-map-mask DT properties from the main PCIe controller node
   to the DT subnodes representing each PCIe interface.

 * Remove the usage of the emulated host bridge.

 * Move the emulated PCI-to-PCI bridge code into the Marvell PCI
   driver itself, in order to allow a tighter integration. Suggested
   by Bjorn Helgaas and Jason Gunthorpe.

 * Make the allocation of address decoding windows dynamic: it's when
   memory accesses or I/O accesses are enabled at the PCI-to-PCI
   bridge level that we allocate and setup the corresponding address
   decoding window. Requested by Bjorn Helgaas.

 * Fixed the implementation of I/O accesses to use I/O addresses that
   fall within the normal IO_SPACE_LIMIT. This required using the
   "remap" functionality of address decoding windows, and therefore
   some changes in the address decoding window allocator. Follows a
   long discussion about I/O accesses.

 * Set up a correct bus number in the configuration of the PCIe
   interfaces so that we don't have to fake bus numbers
   anymore. Requested by Jason Gunthorpe.

 * Fix the of_pci_get_devfn() implementation according to Stephen
   Warren's comment.

 * Use CFLAGS_ instead of ccflags to add the mach-mvebu and plat-orion
   include paths when building the pci-mvebu driver. This ensures that
   the include paths are only added when building this specific
   driver. Requested by Stephen Warren.

 * Fix the ->resource_align() to only apply on bus 0 (the one on which
   the emulated PCI-to-PCI bridges sit), and to request an alignment
   on the size of the window (and not only 64 KB for I/O windows and 1
   MB for memory windows).

 * Clarified the commit log of "clk: mvebu: create parent-child
   relation for PCIe clocks on Armada 370"

Thanks,

Thomas

Andrew Murray (3):
  of/pci: Unify pci_process_bridge_OF_ranges from Microblaze and
    PowerPC
  of/pci: Provide support for parsing PCI DT ranges property
  of/pci: mips: convert to common of_pci_range_parser

Thierry Reding (2):
  of/pci: Add of_pci_get_devfn() function
  of/pci: Add of_pci_parse_bus_range() function

Thomas Petazzoni (14):
  pci: infrastructure to add drivers in drivers/pci/host
  arm: pci: add a align_resource hook
  clk: mvebu: create parent-child relation for PCIe clocks on Armada
    370
  clk: mvebu: add more PCIe clocks for Armada XP
  pci: PCIe driver for Marvell Armada 370/XP systems
  arm: mvebu: PCIe support is now available on mvebu
  arm: mvebu: add PCIe Device Tree informations for Armada 370
  arm: mvebu: add PCIe Device Tree informations for Armada XP
  arm: mvebu: PCIe Device Tree informations for OpenBlocks AX3-4
  arm: mvebu: PCIe Device Tree informations for Armada XP DB
  arm: mvebu: PCIe Device Tree informations for Armada 370 Mirabox
  arm: mvebu: PCIe Device Tree informations for Armada 370 DB
  arm: mvebu: PCIe Device Tree informations for Armada XP GP
  arm: mvebu: update defconfig with PCI and USB support

 .../devicetree/bindings/pci/mvebu-pci.txt          |  220 +++++
 arch/arm/boot/dts/armada-370-db.dts                |   17 +
 arch/arm/boot/dts/armada-370-mirabox.dts           |   16 +
 arch/arm/boot/dts/armada-370.dtsi                  |   51 ++
 arch/arm/boot/dts/armada-xp-db.dts                 |   33 +
 arch/arm/boot/dts/armada-xp-gp.dts                 |   21 +
 arch/arm/boot/dts/armada-xp-mv78230.dtsi           |  104 +++
 arch/arm/boot/dts/armada-xp-mv78260.dtsi           |  122 +++
 arch/arm/boot/dts/armada-xp-mv78460.dtsi           |  188 +++++
 arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts   |    9 +
 arch/arm/configs/mvebu_defconfig                   |    3 +
 arch/arm/include/asm/mach/pci.h                    |   11 +
 arch/arm/kernel/bios32.c                           |    6 +
 arch/arm/mach-mvebu/Kconfig                        |    2 +
 arch/microblaze/include/asm/pci-bridge.h           |    5 +-
 arch/microblaze/pci/pci-common.c                   |  192 -----
 arch/mips/pci/pci.c                                |   50 +-
 arch/powerpc/include/asm/pci-bridge.h              |    5 +-
 arch/powerpc/kernel/pci-common.c                   |  192 -----
 drivers/clk/mvebu/clk-gating-ctrl.c                |   18 +-
 drivers/of/address.c                               |   63 ++
 drivers/of/of_pci.c                                |  227 ++++-
 drivers/pci/Kconfig                                |    2 +
 drivers/pci/Makefile                               |    3 +
 drivers/pci/host/Kconfig                           |    8 +
 drivers/pci/host/Makefile                          |    1 +
 drivers/pci/host/pci-mvebu.c                       |  879 ++++++++++++++++++++
 include/linux/of_address.h                         |   42 +
 include/linux/of_pci.h                             |    6 +
 29 files changed, 2059 insertions(+), 437 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/pci/mvebu-pci.txt
 create mode 100644 drivers/pci/host/Kconfig
 create mode 100644 drivers/pci/host/Makefile
 create mode 100644 drivers/pci/host/pci-mvebu.c

-- 
1.7.9.5



From thomas.petazzoni at free-electrons.com  Tue Apr  9 17:06:23 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Tue,  9 Apr 2013 23:06:23 +0200
Subject: [PATCHv8 02/19] of/pci: Provide support for parsing PCI DT ranges
 property
In-Reply-To: <1365541601-14095-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1365541601-14095-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1365541601-14095-3-git-send-email-thomas.petazzoni@free-electrons.com>

From: Andrew Murray <Andrew.Murray at arm.com>

This patch factors out common implementation patterns to reduce
overall kernel code and provide a means for host bridge drivers to
directly obtain struct resources from the DT's ranges property without
relying on architecture specific DT handling. This will make it easier
to write archiecture independent host bridge drivers and mitigate
against further duplication of DT parsing code.

This patch can be used in the following way:

        struct of_pci_range_parser parser;
        struct of_pci_range range;

        if (of_pci_range_parser(&parser, np))
                ; //no ranges property

        for_each_of_pci_range(&parser, &range) {

                /*
                        directly access properties of the address range, e.g.:
                        range.pci_space, range.pci_addr, range.cpu_addr,
                        range.size, range.flags

                        alternatively obtain a struct resource, e.g.:
                        struct resource res;
                        of_pci_range_to_resource(&range, np, &res);
                */
        }

Additionally the implementation takes care of adjacent ranges and
merges them into a single range (as was the case with powerpc and
microblaze).

Signed-off-by: Andrew Murray <Andrew.Murray at arm.com>
Signed-off-by: Liviu Dudau <Liviu.Dudau at arm.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Cc: monstr at monstr.eu
Cc: benh at kernel.crashing.org
Cc: paulus at samba.org
Cc: Ralf Baechle <ralf at linux-mips.org>
---
 drivers/of/address.c       |   63 +++++++++++++++++++++++++
 drivers/of/of_pci.c        |  112 ++++++++++++++++----------------------------
 include/linux/of_address.h |   42 +++++++++++++++++
 3 files changed, 145 insertions(+), 72 deletions(-)

diff --git a/drivers/of/address.c b/drivers/of/address.c
index 04da786..e87f45e 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -227,6 +227,69 @@ int of_pci_address_to_resource(struct device_node *dev, int bar,
 	return __of_address_to_resource(dev, addrp, size, flags, NULL, r);
 }
 EXPORT_SYMBOL_GPL(of_pci_address_to_resource);
+
+int of_pci_range_parser(struct of_pci_range_parser *parser,
+			struct device_node *node)
+{
+	const int na = 3, ns = 2;
+	int rlen;
+
+	parser->node = node;
+	parser->pna = of_n_addr_cells(node);
+	parser->np = parser->pna + na + ns;
+
+	parser->range = of_get_property(node, "ranges", &rlen);
+	if (parser->range == NULL)
+		return -ENOENT;
+
+	parser->end = parser->range + rlen / sizeof(__be32);
+
+	return 0;
+}
+
+struct of_pci_range *of_pci_process_ranges(struct of_pci_range_parser *parser,
+						struct of_pci_range *range)
+{
+	const int na = 3, ns = 2;
+
+	if (!parser->range || parser->range + parser->np > parser->end)
+		return NULL;
+
+	range->pci_space = be32_to_cpup(parser->range);
+	range->flags = of_bus_pci_get_flags(parser->range);
+	range->pci_addr = of_read_number(parser->range + 1, ns);
+	range->cpu_addr = of_translate_address(parser->node,
+				parser->range + na);
+	range->size = of_read_number(parser->range + parser->pna + na, ns);
+
+	parser->range += parser->np;
+
+	/* Now consume following elements while they are contiguous */
+	while (parser->range + parser->np <= parser->end) {
+		u32 flags, pci_space;
+		u64 pci_addr, cpu_addr, size;
+
+		pci_space = be32_to_cpup(parser->range);
+		flags = of_bus_pci_get_flags(parser->range);
+		pci_addr = of_read_number(parser->range + 1, ns);
+		cpu_addr = of_translate_address(parser->node,
+				parser->range + na);
+		size = of_read_number(parser->range + parser->pna + na, ns);
+
+		if (flags != range->flags)
+			break;
+		if (pci_addr != range->pci_addr + range->size ||
+		    cpu_addr != range->cpu_addr + range->size)
+			break;
+
+		range->size += size;
+		parser->range += parser->np;
+	}
+
+	return range;
+}
+EXPORT_SYMBOL_GPL(of_pci_process_ranges);
+
 #endif /* CONFIG_PCI */
 
 /*
diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
index 9dd8a10..ebb408b 100644
--- a/drivers/of/of_pci.c
+++ b/drivers/of/of_pci.c
@@ -82,67 +82,43 @@ EXPORT_SYMBOL_GPL(of_pci_find_child_device);
 void pci_process_bridge_OF_ranges(struct pci_controller *hose,
 				  struct device_node *dev, int primary)
 {
-	const u32 *ranges;
-	int rlen;
-	int pna = of_n_addr_cells(dev);
-	int np = pna + 5;
 	int memno = 0, isa_hole = -1;
-	u32 pci_space;
-	unsigned long long pci_addr, cpu_addr, pci_next, cpu_next, size;
 	unsigned long long isa_mb = 0;
 	struct resource *res;
+	struct of_pci_range range;
+	struct of_pci_range_parser parser;
+	u32 res_type;
 
 	pr_info("PCI host bridge %s %s ranges:\n",
 	       dev->full_name, primary ? "(primary)" : "");
 
-	/* Get ranges property */
-	ranges = of_get_property(dev, "ranges", &rlen);
-	if (ranges == NULL)
+	/* Check for ranges property */
+	if (of_pci_range_parser(&parser, dev))
 		return;
 
-	/* Parse it */
 	pr_debug("Parsing ranges property...\n");
-	while ((rlen -= np * 4) >= 0) {
+	for_each_of_pci_range(&parser, &range) {
 		/* Read next ranges element */
-		pci_space = ranges[0];
-		pci_addr = of_read_number(ranges + 1, 2);
-		cpu_addr = of_translate_address(dev, ranges + 3);
-		size = of_read_number(ranges + pna + 3, 2);
-
-		pr_debug("pci_space: 0x%08x pci_addr:0x%016llx ",
-				pci_space, pci_addr);
-		pr_debug("cpu_addr:0x%016llx size:0x%016llx\n",
-					cpu_addr, size);
-
-		ranges += np;
+		pr_debug("pci_space: 0x%08x pci_addr: 0x%016llx ",
+				range.pci_space, range.pci_addr);
+		pr_debug("cpu_addr: 0x%016llx size: 0x%016llx\n",
+				range.cpu_addr, range.size);
 
 		/* If we failed translation or got a zero-sized region
 		 * (some FW try to feed us with non sensical zero sized regions
 		 * such as power3 which look like some kind of attempt
 		 * at exposing the VGA memory hole)
 		 */
-		if (cpu_addr == OF_BAD_ADDR || size == 0)
+		if (range.cpu_addr == OF_BAD_ADDR || range.size == 0)
 			continue;
 
-		/* Now consume following elements while they are contiguous */
-		for (; rlen >= np * sizeof(u32);
-		     ranges += np, rlen -= np * 4) {
-			if (ranges[0] != pci_space)
-				break;
-			pci_next = of_read_number(ranges + 1, 2);
-			cpu_next = of_translate_address(dev, ranges + 3);
-			if (pci_next != pci_addr + size ||
-			    cpu_next != cpu_addr + size)
-				break;
-			size += of_read_number(ranges + pna + 3, 2);
-		}
-
 		/* Act based on address space type */
 		res = NULL;
-		switch ((pci_space >> 24) & 0x3) {
-		case 1:		/* PCI IO space */
+		res_type = range.flags & IORESOURCE_TYPE_BITS;
+		if (res_type == IORESOURCE_IO) {
 			pr_info("  IO 0x%016llx..0x%016llx -> 0x%016llx\n",
-			       cpu_addr, cpu_addr + size - 1, pci_addr);
+				range.cpu_addr, range.cpu_addr + range.size - 1,
+				range.pci_addr);
 
 			/* We support only one IO range */
 			if (hose->pci_io_size) {
@@ -151,11 +127,12 @@ void pci_process_bridge_OF_ranges(struct pci_controller *hose,
 			}
 #if defined(CONFIG_PPC32) || defined(CONFIG_MICROBLAZE)
 			/* On 32 bits, limit I/O space to 16MB */
-			if (size > 0x01000000)
-				size = 0x01000000;
+			if (range.size > 0x01000000)
+				range.size = 0x01000000;
 
 			/* 32 bits needs to map IOs here */
-			hose->io_base_virt = ioremap(cpu_addr, size);
+			hose->io_base_virt = ioremap(range.cpu_addr,
+						range.size);
 
 			/* Expect trouble if pci_addr is not 0 */
 			if (primary)
@@ -165,19 +142,18 @@ void pci_process_bridge_OF_ranges(struct pci_controller *hose,
 			/* pci_io_size and io_base_phys always represent IO
 			 * space starting at 0 so we factor in pci_addr
 			 */
-			hose->pci_io_size = pci_addr + size;
-			hose->io_base_phys = cpu_addr - pci_addr;
+			hose->pci_io_size = range.pci_addr + range.size;
+			hose->io_base_phys = range.cpu_addr - range.pci_addr;
 
 			/* Build resource */
 			res = &hose->io_resource;
-			res->flags = IORESOURCE_IO;
-			res->start = pci_addr;
-			break;
-		case 2:		/* PCI Memory space */
-		case 3:		/* PCI 64 bits Memory space */
+			range.cpu_addr = range.pci_addr;
+		} else if (res_type == IORESOURCE_MEM) {
 			pr_info(" MEM 0x%016llx..0x%016llx -> 0x%016llx %s\n",
-			       cpu_addr, cpu_addr + size - 1, pci_addr,
-			       (pci_space & 0x40000000) ? "Prefetch" : "");
+				range.cpu_addr, range.cpu_addr + range.size - 1,
+				range.pci_addr,
+				(range.pci_space & 0x40000000) ?
+				"Prefetch" : "");
 
 			/* We support only 3 memory ranges */
 			if (memno >= 3) {
@@ -185,13 +161,13 @@ void pci_process_bridge_OF_ranges(struct pci_controller *hose,
 				continue;
 			}
 			/* Handles ISA memory hole space here */
-			if (pci_addr == 0) {
-				isa_mb = cpu_addr;
+			if (range.pci_addr == 0) {
+				isa_mb = range.cpu_addr;
 				isa_hole = memno;
 				if (primary || isa_mem_base == 0)
-					isa_mem_base = cpu_addr;
-				hose->isa_mem_phys = cpu_addr;
-				hose->isa_mem_size = size;
+					isa_mem_base = range.cpu_addr;
+				hose->isa_mem_phys = range.cpu_addr;
+				hose->isa_mem_size = range.size;
 			}
 
 			/* We get the PCI/Mem offset from the first range or
@@ -199,30 +175,22 @@ void pci_process_bridge_OF_ranges(struct pci_controller *hose,
 			 * hole. If they don't match, bugger.
 			 */
 			if (memno == 0 ||
-			    (isa_hole >= 0 && pci_addr != 0 &&
+			(isa_hole >= 0 && range.pci_addr != 0 &&
 			     hose->pci_mem_offset == isa_mb))
-				hose->pci_mem_offset = cpu_addr - pci_addr;
-			else if (pci_addr != 0 &&
-				 hose->pci_mem_offset != cpu_addr - pci_addr) {
+				hose->pci_mem_offset = range.cpu_addr -
+							range.pci_addr;
+			else if (range.pci_addr != 0 &&
+				hose->pci_mem_offset != range.cpu_addr -
+							range.pci_addr) {
 				pr_info(" \\--> Skipped (offset mismatch) !\n");
 				continue;
 			}
 
 			/* Build resource */
 			res = &hose->mem_resources[memno++];
-			res->flags = IORESOURCE_MEM;
-			if (pci_space & 0x40000000)
-				res->flags |= IORESOURCE_PREFETCH;
-			res->start = cpu_addr;
-			break;
-		}
-		if (res != NULL) {
-			res->name = dev->full_name;
-			res->end = res->start + size - 1;
-			res->parent = NULL;
-			res->sibling = NULL;
-			res->child = NULL;
 		}
+		if (res != NULL)
+			of_pci_range_to_resource(&range, dev, res);
 	}
 
 	/* If there's an ISA hole and the pci_mem_offset is -not- matching
diff --git a/include/linux/of_address.h b/include/linux/of_address.h
index 0506eb5..c7003a3 100644
--- a/include/linux/of_address.h
+++ b/include/linux/of_address.h
@@ -4,6 +4,32 @@
 #include <linux/errno.h>
 #include <linux/of.h>
 
+struct of_pci_range_parser {
+	struct device_node *node;
+	const __be32 *range, *end;
+	int np, pna;
+};
+
+struct of_pci_range {
+	u32 pci_space;
+	u64 pci_addr;
+	u64 cpu_addr;
+	u64 size;
+	u32 flags;
+};
+
+#define for_each_of_pci_range(parser, range) \
+	for (; of_pci_process_ranges(parser, range);)
+
+#define of_pci_range_to_resource(range, np, res) \
+	do { \
+		(res)->flags = (range)->flags; \
+		(res)->start = (range)->cpu_addr; \
+		(res)->end = (range)->cpu_addr + (range)->size - 1; \
+		(res)->parent = (res)->child = (res)->sibling = NULL; \
+		(res)->name = (np)->full_name; \
+	} while (0)
+
 #ifdef CONFIG_OF_ADDRESS
 extern u64 of_translate_address(struct device_node *np, const __be32 *addr);
 extern bool of_can_translate_address(struct device_node *dev);
@@ -27,6 +53,10 @@ static inline unsigned long pci_address_to_pio(phys_addr_t addr) { return -1; }
 #define pci_address_to_pio pci_address_to_pio
 #endif
 
+int of_pci_range_parser(struct of_pci_range_parser *parser,
+			struct device_node *node);
+struct of_pci_range *of_pci_process_ranges(struct of_pci_range_parser *parser,
+						struct of_pci_range *range);
 #else /* CONFIG_OF_ADDRESS */
 #ifndef of_address_to_resource
 static inline int of_address_to_resource(struct device_node *dev, int index,
@@ -53,6 +83,18 @@ static inline const __be32 *of_get_address(struct device_node *dev, int index,
 {
 	return NULL;
 }
+
+int of_pci_range_parser(struct of_pci_range_parser *parser,
+			struct device_noed *node)
+{
+	return -1;
+}
+
+struct of_pci_range *of_pci_process_ranges(struct of_pci_range_parser *parser,
+						struct of_pci_range *range)
+{
+	return NULL;
+}
 #endif /* CONFIG_OF_ADDRESS */
 
 
-- 
1.7.9.5



From thomas.petazzoni at free-electrons.com  Tue Apr  9 17:06:22 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Tue,  9 Apr 2013 23:06:22 +0200
Subject: [PATCHv8 01/19] of/pci: Unify pci_process_bridge_OF_ranges from
 Microblaze and PowerPC
In-Reply-To: <1365541601-14095-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1365541601-14095-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1365541601-14095-2-git-send-email-thomas.petazzoni@free-electrons.com>

From: Andrew Murray <Andrew.Murray at arm.com>

The pci_process_bridge_OF_ranges function, used to parse the "ranges"
property of a PCI host device, is found in both Microblaze and PowerPC
architectures. These implementations are nearly identical. This patch
moves this common code to a common place.

Signed-off-by: Andrew Murray <Andrew.Murray at arm.com>
Signed-off-by: Liviu Dudau <Liviu.Dudau at arm.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Cc: monstr at monstr.eu
Cc: benh at kernel.crashing.org
Cc: paulus at samba.org
Cc: Ralf Baechle <ralf at linux-mips.org>
---
 arch/microblaze/include/asm/pci-bridge.h |    5 +-
 arch/microblaze/pci/pci-common.c         |  192 ----------------------------
 arch/powerpc/include/asm/pci-bridge.h    |    5 +-
 arch/powerpc/kernel/pci-common.c         |  192 ----------------------------
 drivers/of/of_pci.c                      |  200 ++++++++++++++++++++++++++++++
 include/linux/of_pci.h                   |    4 +
 6 files changed, 206 insertions(+), 392 deletions(-)

diff --git a/arch/microblaze/include/asm/pci-bridge.h b/arch/microblaze/include/asm/pci-bridge.h
index cb5d397..5783cd6 100644
--- a/arch/microblaze/include/asm/pci-bridge.h
+++ b/arch/microblaze/include/asm/pci-bridge.h
@@ -10,6 +10,7 @@
 #include <linux/pci.h>
 #include <linux/list.h>
 #include <linux/ioport.h>
+#include <linux/of_pci.h>
 
 struct device_node;
 
@@ -132,10 +133,6 @@ extern void setup_indirect_pci(struct pci_controller *hose,
 extern struct pci_controller *pci_find_hose_for_OF_device(
 			struct device_node *node);
 
-/* Fill up host controller resources from the OF node */
-extern void pci_process_bridge_OF_ranges(struct pci_controller *hose,
-			struct device_node *dev, int primary);
-
 /* Allocate & free a PCI host bridge structure */
 extern struct pci_controller *pcibios_alloc_controller(struct device_node *dev);
 extern void pcibios_free_controller(struct pci_controller *phb);
diff --git a/arch/microblaze/pci/pci-common.c b/arch/microblaze/pci/pci-common.c
index 9ea521e..2735ad9 100644
--- a/arch/microblaze/pci/pci-common.c
+++ b/arch/microblaze/pci/pci-common.c
@@ -622,198 +622,6 @@ void pci_resource_to_user(const struct pci_dev *dev, int bar,
 	*end = rsrc->end - offset;
 }
 
-/**
- * pci_process_bridge_OF_ranges - Parse PCI bridge resources from device tree
- * @hose: newly allocated pci_controller to be setup
- * @dev: device node of the host bridge
- * @primary: set if primary bus (32 bits only, soon to be deprecated)
- *
- * This function will parse the "ranges" property of a PCI host bridge device
- * node and setup the resource mapping of a pci controller based on its
- * content.
- *
- * Life would be boring if it wasn't for a few issues that we have to deal
- * with here:
- *
- *   - We can only cope with one IO space range and up to 3 Memory space
- *     ranges. However, some machines (thanks Apple !) tend to split their
- *     space into lots of small contiguous ranges. So we have to coalesce.
- *
- *   - We can only cope with all memory ranges having the same offset
- *     between CPU addresses and PCI addresses. Unfortunately, some bridges
- *     are setup for a large 1:1 mapping along with a small "window" which
- *     maps PCI address 0 to some arbitrary high address of the CPU space in
- *     order to give access to the ISA memory hole.
- *     The way out of here that I've chosen for now is to always set the
- *     offset based on the first resource found, then override it if we
- *     have a different offset and the previous was set by an ISA hole.
- *
- *   - Some busses have IO space not starting at 0, which causes trouble with
- *     the way we do our IO resource renumbering. The code somewhat deals with
- *     it for 64 bits but I would expect problems on 32 bits.
- *
- *   - Some 32 bits platforms such as 4xx can have physical space larger than
- *     32 bits so we need to use 64 bits values for the parsing
- */
-void pci_process_bridge_OF_ranges(struct pci_controller *hose,
-				  struct device_node *dev, int primary)
-{
-	const u32 *ranges;
-	int rlen;
-	int pna = of_n_addr_cells(dev);
-	int np = pna + 5;
-	int memno = 0, isa_hole = -1;
-	u32 pci_space;
-	unsigned long long pci_addr, cpu_addr, pci_next, cpu_next, size;
-	unsigned long long isa_mb = 0;
-	struct resource *res;
-
-	pr_info("PCI host bridge %s %s ranges:\n",
-	       dev->full_name, primary ? "(primary)" : "");
-
-	/* Get ranges property */
-	ranges = of_get_property(dev, "ranges", &rlen);
-	if (ranges == NULL)
-		return;
-
-	/* Parse it */
-	pr_debug("Parsing ranges property...\n");
-	while ((rlen -= np * 4) >= 0) {
-		/* Read next ranges element */
-		pci_space = ranges[0];
-		pci_addr = of_read_number(ranges + 1, 2);
-		cpu_addr = of_translate_address(dev, ranges + 3);
-		size = of_read_number(ranges + pna + 3, 2);
-
-		pr_debug("pci_space: 0x%08x pci_addr:0x%016llx ",
-				pci_space, pci_addr);
-		pr_debug("cpu_addr:0x%016llx size:0x%016llx\n",
-					cpu_addr, size);
-
-		ranges += np;
-
-		/* If we failed translation or got a zero-sized region
-		 * (some FW try to feed us with non sensical zero sized regions
-		 * such as power3 which look like some kind of attempt
-		 * at exposing the VGA memory hole)
-		 */
-		if (cpu_addr == OF_BAD_ADDR || size == 0)
-			continue;
-
-		/* Now consume following elements while they are contiguous */
-		for (; rlen >= np * sizeof(u32);
-		     ranges += np, rlen -= np * 4) {
-			if (ranges[0] != pci_space)
-				break;
-			pci_next = of_read_number(ranges + 1, 2);
-			cpu_next = of_translate_address(dev, ranges + 3);
-			if (pci_next != pci_addr + size ||
-			    cpu_next != cpu_addr + size)
-				break;
-			size += of_read_number(ranges + pna + 3, 2);
-		}
-
-		/* Act based on address space type */
-		res = NULL;
-		switch ((pci_space >> 24) & 0x3) {
-		case 1:		/* PCI IO space */
-			pr_info("  IO 0x%016llx..0x%016llx -> 0x%016llx\n",
-			       cpu_addr, cpu_addr + size - 1, pci_addr);
-
-			/* We support only one IO range */
-			if (hose->pci_io_size) {
-				pr_info(" \\--> Skipped (too many) !\n");
-				continue;
-			}
-			/* On 32 bits, limit I/O space to 16MB */
-			if (size > 0x01000000)
-				size = 0x01000000;
-
-			/* 32 bits needs to map IOs here */
-			hose->io_base_virt = ioremap(cpu_addr, size);
-
-			/* Expect trouble if pci_addr is not 0 */
-			if (primary)
-				isa_io_base =
-					(unsigned long)hose->io_base_virt;
-			/* pci_io_size and io_base_phys always represent IO
-			 * space starting at 0 so we factor in pci_addr
-			 */
-			hose->pci_io_size = pci_addr + size;
-			hose->io_base_phys = cpu_addr - pci_addr;
-
-			/* Build resource */
-			res = &hose->io_resource;
-			res->flags = IORESOURCE_IO;
-			res->start = pci_addr;
-			break;
-		case 2:		/* PCI Memory space */
-		case 3:		/* PCI 64 bits Memory space */
-			pr_info(" MEM 0x%016llx..0x%016llx -> 0x%016llx %s\n",
-			       cpu_addr, cpu_addr + size - 1, pci_addr,
-			       (pci_space & 0x40000000) ? "Prefetch" : "");
-
-			/* We support only 3 memory ranges */
-			if (memno >= 3) {
-				pr_info(" \\--> Skipped (too many) !\n");
-				continue;
-			}
-			/* Handles ISA memory hole space here */
-			if (pci_addr == 0) {
-				isa_mb = cpu_addr;
-				isa_hole = memno;
-				if (primary || isa_mem_base == 0)
-					isa_mem_base = cpu_addr;
-				hose->isa_mem_phys = cpu_addr;
-				hose->isa_mem_size = size;
-			}
-
-			/* We get the PCI/Mem offset from the first range or
-			 * the, current one if the offset came from an ISA
-			 * hole. If they don't match, bugger.
-			 */
-			if (memno == 0 ||
-			    (isa_hole >= 0 && pci_addr != 0 &&
-			     hose->pci_mem_offset == isa_mb))
-				hose->pci_mem_offset = cpu_addr - pci_addr;
-			else if (pci_addr != 0 &&
-				 hose->pci_mem_offset != cpu_addr - pci_addr) {
-				pr_info(" \\--> Skipped (offset mismatch) !\n");
-				continue;
-			}
-
-			/* Build resource */
-			res = &hose->mem_resources[memno++];
-			res->flags = IORESOURCE_MEM;
-			if (pci_space & 0x40000000)
-				res->flags |= IORESOURCE_PREFETCH;
-			res->start = cpu_addr;
-			break;
-		}
-		if (res != NULL) {
-			res->name = dev->full_name;
-			res->end = res->start + size - 1;
-			res->parent = NULL;
-			res->sibling = NULL;
-			res->child = NULL;
-		}
-	}
-
-	/* If there's an ISA hole and the pci_mem_offset is -not- matching
-	 * the ISA hole offset, then we need to remove the ISA hole from
-	 * the resource list for that brige
-	 */
-	if (isa_hole >= 0 && hose->pci_mem_offset != isa_mb) {
-		unsigned int next = isa_hole + 1;
-		pr_info(" Removing ISA hole at 0x%016llx\n", isa_mb);
-		if (next < memno)
-			memmove(&hose->mem_resources[isa_hole],
-				&hose->mem_resources[next],
-				sizeof(struct resource) * (memno - next));
-		hose->mem_resources[--memno].flags = 0;
-	}
-}
-
 /* Decide whether to display the domain number in /proc */
 int pci_proc_domain(struct pci_bus *bus)
 {
diff --git a/arch/powerpc/include/asm/pci-bridge.h b/arch/powerpc/include/asm/pci-bridge.h
index 025a130..205bfba 100644
--- a/arch/powerpc/include/asm/pci-bridge.h
+++ b/arch/powerpc/include/asm/pci-bridge.h
@@ -10,6 +10,7 @@
 #include <linux/pci.h>
 #include <linux/list.h>
 #include <linux/ioport.h>
+#include <linux/of_pci.h>
 #include <asm-generic/pci-bridge.h>
 
 struct device_node;
@@ -231,10 +232,6 @@ extern int pcibios_map_io_space(struct pci_bus *bus);
 extern struct pci_controller *pci_find_hose_for_OF_device(
 			struct device_node* node);
 
-/* Fill up host controller resources from the OF node */
-extern void pci_process_bridge_OF_ranges(struct pci_controller *hose,
-			struct device_node *dev, int primary);
-
 /* Allocate & free a PCI host bridge structure */
 extern struct pci_controller *pcibios_alloc_controller(struct device_node *dev);
 extern void pcibios_free_controller(struct pci_controller *phb);
diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index fa12ae4..6edf396 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -640,198 +640,6 @@ void pci_resource_to_user(const struct pci_dev *dev, int bar,
 	*end = rsrc->end - offset;
 }
 
-/**
- * pci_process_bridge_OF_ranges - Parse PCI bridge resources from device tree
- * @hose: newly allocated pci_controller to be setup
- * @dev: device node of the host bridge
- * @primary: set if primary bus (32 bits only, soon to be deprecated)
- *
- * This function will parse the "ranges" property of a PCI host bridge device
- * node and setup the resource mapping of a pci controller based on its
- * content.
- *
- * Life would be boring if it wasn't for a few issues that we have to deal
- * with here:
- *
- *   - We can only cope with one IO space range and up to 3 Memory space
- *     ranges. However, some machines (thanks Apple !) tend to split their
- *     space into lots of small contiguous ranges. So we have to coalesce.
- *
- *   - We can only cope with all memory ranges having the same offset
- *     between CPU addresses and PCI addresses. Unfortunately, some bridges
- *     are setup for a large 1:1 mapping along with a small "window" which
- *     maps PCI address 0 to some arbitrary high address of the CPU space in
- *     order to give access to the ISA memory hole.
- *     The way out of here that I've chosen for now is to always set the
- *     offset based on the first resource found, then override it if we
- *     have a different offset and the previous was set by an ISA hole.
- *
- *   - Some busses have IO space not starting at 0, which causes trouble with
- *     the way we do our IO resource renumbering. The code somewhat deals with
- *     it for 64 bits but I would expect problems on 32 bits.
- *
- *   - Some 32 bits platforms such as 4xx can have physical space larger than
- *     32 bits so we need to use 64 bits values for the parsing
- */
-void pci_process_bridge_OF_ranges(struct pci_controller *hose,
-				  struct device_node *dev, int primary)
-{
-	const u32 *ranges;
-	int rlen;
-	int pna = of_n_addr_cells(dev);
-	int np = pna + 5;
-	int memno = 0, isa_hole = -1;
-	u32 pci_space;
-	unsigned long long pci_addr, cpu_addr, pci_next, cpu_next, size;
-	unsigned long long isa_mb = 0;
-	struct resource *res;
-
-	printk(KERN_INFO "PCI host bridge %s %s ranges:\n",
-	       dev->full_name, primary ? "(primary)" : "");
-
-	/* Get ranges property */
-	ranges = of_get_property(dev, "ranges", &rlen);
-	if (ranges == NULL)
-		return;
-
-	/* Parse it */
-	while ((rlen -= np * 4) >= 0) {
-		/* Read next ranges element */
-		pci_space = ranges[0];
-		pci_addr = of_read_number(ranges + 1, 2);
-		cpu_addr = of_translate_address(dev, ranges + 3);
-		size = of_read_number(ranges + pna + 3, 2);
-		ranges += np;
-
-		/* If we failed translation or got a zero-sized region
-		 * (some FW try to feed us with non sensical zero sized regions
-		 * such as power3 which look like some kind of attempt at exposing
-		 * the VGA memory hole)
-		 */
-		if (cpu_addr == OF_BAD_ADDR || size == 0)
-			continue;
-
-		/* Now consume following elements while they are contiguous */
-		for (; rlen >= np * sizeof(u32);
-		     ranges += np, rlen -= np * 4) {
-			if (ranges[0] != pci_space)
-				break;
-			pci_next = of_read_number(ranges + 1, 2);
-			cpu_next = of_translate_address(dev, ranges + 3);
-			if (pci_next != pci_addr + size ||
-			    cpu_next != cpu_addr + size)
-				break;
-			size += of_read_number(ranges + pna + 3, 2);
-		}
-
-		/* Act based on address space type */
-		res = NULL;
-		switch ((pci_space >> 24) & 0x3) {
-		case 1:		/* PCI IO space */
-			printk(KERN_INFO
-			       "  IO 0x%016llx..0x%016llx -> 0x%016llx\n",
-			       cpu_addr, cpu_addr + size - 1, pci_addr);
-
-			/* We support only one IO range */
-			if (hose->pci_io_size) {
-				printk(KERN_INFO
-				       " \\--> Skipped (too many) !\n");
-				continue;
-			}
-#ifdef CONFIG_PPC32
-			/* On 32 bits, limit I/O space to 16MB */
-			if (size > 0x01000000)
-				size = 0x01000000;
-
-			/* 32 bits needs to map IOs here */
-			hose->io_base_virt = ioremap(cpu_addr, size);
-
-			/* Expect trouble if pci_addr is not 0 */
-			if (primary)
-				isa_io_base =
-					(unsigned long)hose->io_base_virt;
-#endif /* CONFIG_PPC32 */
-			/* pci_io_size and io_base_phys always represent IO
-			 * space starting at 0 so we factor in pci_addr
-			 */
-			hose->pci_io_size = pci_addr + size;
-			hose->io_base_phys = cpu_addr - pci_addr;
-
-			/* Build resource */
-			res = &hose->io_resource;
-			res->flags = IORESOURCE_IO;
-			res->start = pci_addr;
-			break;
-		case 2:		/* PCI Memory space */
-		case 3:		/* PCI 64 bits Memory space */
-			printk(KERN_INFO
-			       " MEM 0x%016llx..0x%016llx -> 0x%016llx %s\n",
-			       cpu_addr, cpu_addr + size - 1, pci_addr,
-			       (pci_space & 0x40000000) ? "Prefetch" : "");
-
-			/* We support only 3 memory ranges */
-			if (memno >= 3) {
-				printk(KERN_INFO
-				       " \\--> Skipped (too many) !\n");
-				continue;
-			}
-			/* Handles ISA memory hole space here */
-			if (pci_addr == 0) {
-				isa_mb = cpu_addr;
-				isa_hole = memno;
-				if (primary || isa_mem_base == 0)
-					isa_mem_base = cpu_addr;
-				hose->isa_mem_phys = cpu_addr;
-				hose->isa_mem_size = size;
-			}
-
-			/* We get the PCI/Mem offset from the first range or
-			 * the, current one if the offset came from an ISA
-			 * hole. If they don't match, bugger.
-			 */
-			if (memno == 0 ||
-			    (isa_hole >= 0 && pci_addr != 0 &&
-			     hose->pci_mem_offset == isa_mb))
-				hose->pci_mem_offset = cpu_addr - pci_addr;
-			else if (pci_addr != 0 &&
-				 hose->pci_mem_offset != cpu_addr - pci_addr) {
-				printk(KERN_INFO
-				       " \\--> Skipped (offset mismatch) !\n");
-				continue;
-			}
-
-			/* Build resource */
-			res = &hose->mem_resources[memno++];
-			res->flags = IORESOURCE_MEM;
-			if (pci_space & 0x40000000)
-				res->flags |= IORESOURCE_PREFETCH;
-			res->start = cpu_addr;
-			break;
-		}
-		if (res != NULL) {
-			res->name = dev->full_name;
-			res->end = res->start + size - 1;
-			res->parent = NULL;
-			res->sibling = NULL;
-			res->child = NULL;
-		}
-	}
-
-	/* If there's an ISA hole and the pci_mem_offset is -not- matching
-	 * the ISA hole offset, then we need to remove the ISA hole from
-	 * the resource list for that brige
-	 */
-	if (isa_hole >= 0 && hose->pci_mem_offset != isa_mb) {
-		unsigned int next = isa_hole + 1;
-		printk(KERN_INFO " Removing ISA hole at 0x%016llx\n", isa_mb);
-		if (next < memno)
-			memmove(&hose->mem_resources[isa_hole],
-				&hose->mem_resources[next],
-				sizeof(struct resource) * (memno - next));
-		hose->mem_resources[--memno].flags = 0;
-	}
-}
-
 /* Decide whether to display the domain number in /proc */
 int pci_proc_domain(struct pci_bus *bus)
 {
diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
index 13e37e2..9dd8a10 100644
--- a/drivers/of/of_pci.c
+++ b/drivers/of/of_pci.c
@@ -4,6 +4,10 @@
 #include <linux/of_pci.h>
 #include <asm/prom.h>
 
+#if defined(CONFIG_PPC32) || defined(CONFIG_PPC64) || defined(CONFIG_MICROBLAZE)
+#include <asm/pci-bridge.h>
+#endif
+
 static inline int __of_pci_pci_compare(struct device_node *node,
 				       unsigned int devfn)
 {
@@ -40,3 +44,199 @@ struct device_node *of_pci_find_child_device(struct device_node *parent,
 	return NULL;
 }
 EXPORT_SYMBOL_GPL(of_pci_find_child_device);
+
+/**
+ * pci_process_bridge_OF_ranges - Parse PCI bridge resources from device tree
+ * @hose: newly allocated pci_controller to be setup
+ * @dev: device node of the host bridge
+ * @primary: set if primary bus (32 bits only, soon to be deprecated)
+ *
+ * This function will parse the "ranges" property of a PCI host bridge device
+ * node and setup the resource mapping of a pci controller based on its
+ * content.
+ *
+ * Life would be boring if it wasn't for a few issues that we have to deal
+ * with here:
+ *
+ *   - We can only cope with one IO space range and up to 3 Memory space
+ *	ranges. However, some machines (thanks Apple !) tend to split their
+ *	space into lots of small contiguous ranges. So we have to coalesce.
+ *
+ *   - We can only cope with all memory ranges having the same offset
+ *	between CPU addresses and PCI addresses. Unfortunately, some bridges
+ *	are setup for a large 1:1 mapping along with a small "window" which
+ *	maps PCI address 0 to some arbitrary high address of the CPU space in
+ *	order to give access to the ISA memory hole.
+ *	The way out of here that I've chosen for now is to always set the
+ *	offset based on the first resource found, then override it if we
+ *	have a different offset and the previous was set by an ISA hole.
+ *
+ *   - Some busses have IO space not starting at 0, which causes trouble with
+ *	the way we do our IO resource renumbering. The code somewhat deals with
+ *	it for 64 bits but I would expect problems on 32 bits.
+ *
+ *   - Some 32 bits platforms such as 4xx can have physical space larger than
+ *	32 bits so we need to use 64 bits values for the parsing
+ */
+#if defined(CONFIG_PPC32) || defined(CONFIG_PPC64) || defined(CONFIG_MICROBLAZE)
+void pci_process_bridge_OF_ranges(struct pci_controller *hose,
+				  struct device_node *dev, int primary)
+{
+	const u32 *ranges;
+	int rlen;
+	int pna = of_n_addr_cells(dev);
+	int np = pna + 5;
+	int memno = 0, isa_hole = -1;
+	u32 pci_space;
+	unsigned long long pci_addr, cpu_addr, pci_next, cpu_next, size;
+	unsigned long long isa_mb = 0;
+	struct resource *res;
+
+	pr_info("PCI host bridge %s %s ranges:\n",
+	       dev->full_name, primary ? "(primary)" : "");
+
+	/* Get ranges property */
+	ranges = of_get_property(dev, "ranges", &rlen);
+	if (ranges == NULL)
+		return;
+
+	/* Parse it */
+	pr_debug("Parsing ranges property...\n");
+	while ((rlen -= np * 4) >= 0) {
+		/* Read next ranges element */
+		pci_space = ranges[0];
+		pci_addr = of_read_number(ranges + 1, 2);
+		cpu_addr = of_translate_address(dev, ranges + 3);
+		size = of_read_number(ranges + pna + 3, 2);
+
+		pr_debug("pci_space: 0x%08x pci_addr:0x%016llx ",
+				pci_space, pci_addr);
+		pr_debug("cpu_addr:0x%016llx size:0x%016llx\n",
+					cpu_addr, size);
+
+		ranges += np;
+
+		/* If we failed translation or got a zero-sized region
+		 * (some FW try to feed us with non sensical zero sized regions
+		 * such as power3 which look like some kind of attempt
+		 * at exposing the VGA memory hole)
+		 */
+		if (cpu_addr == OF_BAD_ADDR || size == 0)
+			continue;
+
+		/* Now consume following elements while they are contiguous */
+		for (; rlen >= np * sizeof(u32);
+		     ranges += np, rlen -= np * 4) {
+			if (ranges[0] != pci_space)
+				break;
+			pci_next = of_read_number(ranges + 1, 2);
+			cpu_next = of_translate_address(dev, ranges + 3);
+			if (pci_next != pci_addr + size ||
+			    cpu_next != cpu_addr + size)
+				break;
+			size += of_read_number(ranges + pna + 3, 2);
+		}
+
+		/* Act based on address space type */
+		res = NULL;
+		switch ((pci_space >> 24) & 0x3) {
+		case 1:		/* PCI IO space */
+			pr_info("  IO 0x%016llx..0x%016llx -> 0x%016llx\n",
+			       cpu_addr, cpu_addr + size - 1, pci_addr);
+
+			/* We support only one IO range */
+			if (hose->pci_io_size) {
+				pr_info(" \\--> Skipped (too many) !\n");
+				continue;
+			}
+#if defined(CONFIG_PPC32) || defined(CONFIG_MICROBLAZE)
+			/* On 32 bits, limit I/O space to 16MB */
+			if (size > 0x01000000)
+				size = 0x01000000;
+
+			/* 32 bits needs to map IOs here */
+			hose->io_base_virt = ioremap(cpu_addr, size);
+
+			/* Expect trouble if pci_addr is not 0 */
+			if (primary)
+				isa_io_base =
+					(unsigned long)hose->io_base_virt;
+#endif /* CONFIG_PPC32 || CONFIG_MICROBLAZE */
+			/* pci_io_size and io_base_phys always represent IO
+			 * space starting at 0 so we factor in pci_addr
+			 */
+			hose->pci_io_size = pci_addr + size;
+			hose->io_base_phys = cpu_addr - pci_addr;
+
+			/* Build resource */
+			res = &hose->io_resource;
+			res->flags = IORESOURCE_IO;
+			res->start = pci_addr;
+			break;
+		case 2:		/* PCI Memory space */
+		case 3:		/* PCI 64 bits Memory space */
+			pr_info(" MEM 0x%016llx..0x%016llx -> 0x%016llx %s\n",
+			       cpu_addr, cpu_addr + size - 1, pci_addr,
+			       (pci_space & 0x40000000) ? "Prefetch" : "");
+
+			/* We support only 3 memory ranges */
+			if (memno >= 3) {
+				pr_info(" \\--> Skipped (too many) !\n");
+				continue;
+			}
+			/* Handles ISA memory hole space here */
+			if (pci_addr == 0) {
+				isa_mb = cpu_addr;
+				isa_hole = memno;
+				if (primary || isa_mem_base == 0)
+					isa_mem_base = cpu_addr;
+				hose->isa_mem_phys = cpu_addr;
+				hose->isa_mem_size = size;
+			}
+
+			/* We get the PCI/Mem offset from the first range or
+			 * the, current one if the offset came from an ISA
+			 * hole. If they don't match, bugger.
+			 */
+			if (memno == 0 ||
+			    (isa_hole >= 0 && pci_addr != 0 &&
+			     hose->pci_mem_offset == isa_mb))
+				hose->pci_mem_offset = cpu_addr - pci_addr;
+			else if (pci_addr != 0 &&
+				 hose->pci_mem_offset != cpu_addr - pci_addr) {
+				pr_info(" \\--> Skipped (offset mismatch) !\n");
+				continue;
+			}
+
+			/* Build resource */
+			res = &hose->mem_resources[memno++];
+			res->flags = IORESOURCE_MEM;
+			if (pci_space & 0x40000000)
+				res->flags |= IORESOURCE_PREFETCH;
+			res->start = cpu_addr;
+			break;
+		}
+		if (res != NULL) {
+			res->name = dev->full_name;
+			res->end = res->start + size - 1;
+			res->parent = NULL;
+			res->sibling = NULL;
+			res->child = NULL;
+		}
+	}
+
+	/* If there's an ISA hole and the pci_mem_offset is -not- matching
+	 * the ISA hole offset, then we need to remove the ISA hole from
+	 * the resource list for that brige
+	 */
+	if (isa_hole >= 0 && hose->pci_mem_offset != isa_mb) {
+		unsigned int next = isa_hole + 1;
+		pr_info(" Removing ISA hole at 0x%016llx\n", isa_mb);
+		if (next < memno)
+			memmove(&hose->mem_resources[isa_hole],
+				&hose->mem_resources[next],
+				sizeof(struct resource) * (memno - next));
+		hose->mem_resources[--memno].flags = 0;
+	}
+}
+#endif
diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
index bb115de..e56182f 100644
--- a/include/linux/of_pci.h
+++ b/include/linux/of_pci.h
@@ -4,6 +4,7 @@
 #include <linux/pci.h>
 
 struct pci_dev;
+struct pci_controller;
 struct of_irq;
 int of_irq_map_pci(const struct pci_dev *pdev, struct of_irq *out_irq);
 
@@ -11,4 +12,7 @@ struct device_node;
 struct device_node *of_pci_find_child_device(struct device_node *parent,
 					     unsigned int devfn);
 
+void pci_process_bridge_OF_ranges(struct pci_controller *hose,
+			struct device_node *dev, int primary);
+
 #endif
-- 
1.7.9.5



From thomas.petazzoni at free-electrons.com  Tue Apr  9 17:06:26 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Tue,  9 Apr 2013 23:06:26 +0200
Subject: [PATCHv8 05/19] of/pci: Add of_pci_parse_bus_range() function
In-Reply-To: <1365541601-14095-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1365541601-14095-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1365541601-14095-6-git-send-email-thomas.petazzoni@free-electrons.com>

From: Thierry Reding <thierry.reding at avionic-design.de>

This function can be used to parse a bus-range property as specified by
device nodes representing PCI bridges.

Signed-off-by: Thierry Reding <thierry.reding at avionic-design.de>
---
 drivers/of/of_pci.c    |   25 +++++++++++++++++++++++++
 include/linux/of_pci.h |    1 +
 2 files changed, 26 insertions(+)

diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
index b77e8d8..e9106dc 100644
--- a/drivers/of/of_pci.c
+++ b/drivers/of/of_pci.c
@@ -232,3 +232,28 @@ int of_pci_get_devfn(struct device_node *np)
 	return (be32_to_cpup(reg) >> 8) & 0xff;
 }
 EXPORT_SYMBOL_GPL(of_pci_get_devfn);
+
+/**
+ * of_pci_parse_bus_range() - parse the bus-range property of a PCI device
+ * @node: device node
+ * @res: address to a struct resource to return the bus-range
+ *
+ * Returns 0 on success or a negative error-code on failure.
+ */
+int of_pci_parse_bus_range(struct device_node *node, struct resource *res)
+{
+	const __be32 *values;
+	int len;
+
+	values = of_get_property(node, "bus-range", &len);
+	if (!values || len < sizeof(*values) * 2)
+		return -EINVAL;
+
+	res->name = node->name;
+	res->start = be32_to_cpup(values++);
+	res->end = be32_to_cpup(values);
+	res->flags = IORESOURCE_BUS;
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(of_pci_parse_bus_range);
diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
index 302aca0..be97a6f 100644
--- a/include/linux/of_pci.h
+++ b/include/linux/of_pci.h
@@ -12,6 +12,7 @@ struct device_node;
 struct device_node *of_pci_find_child_device(struct device_node *parent,
 					     unsigned int devfn);
 int of_pci_get_devfn(struct device_node *np);
+int of_pci_parse_bus_range(struct device_node *node, struct resource *res);
 
 void pci_process_bridge_OF_ranges(struct pci_controller *hose,
 			struct device_node *dev, int primary);
-- 
1.7.9.5



From thomas.petazzoni at free-electrons.com  Tue Apr  9 17:06:24 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Tue,  9 Apr 2013 23:06:24 +0200
Subject: [PATCHv8 03/19] of/pci: mips: convert to common of_pci_range_parser
In-Reply-To: <1365541601-14095-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1365541601-14095-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1365541601-14095-4-git-send-email-thomas.petazzoni@free-electrons.com>

From: Andrew Murray <Andrew.Murray at arm.com>

This patch converts the pci_load_of_ranges function to use the new
common of_pci_range_parser.

Signed-off-by: Andrew Murray <Andrew.Murray at arm.com>
Signed-off-by: Liviu Dudau <Liviu.Dudau at arm.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Cc: monstr at monstr.eu
Cc: benh at kernel.crashing.org
Cc: paulus at samba.org
Cc: Ralf Baechle <ralf at linux-mips.org>
---
 arch/mips/pci/pci.c |   50 ++++++++++++++++----------------------------------
 1 file changed, 16 insertions(+), 34 deletions(-)

diff --git a/arch/mips/pci/pci.c b/arch/mips/pci/pci.c
index 0872f12..bee49a4 100644
--- a/arch/mips/pci/pci.c
+++ b/arch/mips/pci/pci.c
@@ -122,51 +122,33 @@ static void pcibios_scanbus(struct pci_controller *hose)
 #ifdef CONFIG_OF
 void pci_load_of_ranges(struct pci_controller *hose, struct device_node *node)
 {
-	const __be32 *ranges;
-	int rlen;
-	int pna = of_n_addr_cells(node);
-	int np = pna + 5;
+	struct of_pci_range_range range;
+	struct of_pci_range_parser parser;
+	u32 res_type;
 
 	pr_info("PCI host bridge %s ranges:\n", node->full_name);
-	ranges = of_get_property(node, "ranges", &rlen);
-	if (ranges == NULL)
-		return;
 	hose->of_node = node;
 
-	while ((rlen -= np * 4) >= 0) {
-		u32 pci_space;
+	if (of_pci_range_parser(&parser, node))
+		return;
+
+	for_each_of_pci_range(&parser, &range) {
 		struct resource *res = NULL;
-		u64 addr, size;
-
-		pci_space = be32_to_cpup(&ranges[0]);
-		addr = of_translate_address(node, ranges + 3);
-		size = of_read_number(ranges + pna + 3, 2);
-		ranges += np;
-		switch ((pci_space >> 24) & 0x3) {
-		case 1:		/* PCI IO space */
+
+		res_type = range.flags & IORESOURCE_TYPE_BITS;
+		if (res_type == IORESOURCE_IO) {
 			pr_info("  IO 0x%016llx..0x%016llx\n",
-					addr, addr + size - 1);
+				range.addr, range.addr + range.size - 1);
 			hose->io_map_base =
-				(unsigned long)ioremap(addr, size);
+				(unsigned long)ioremap(range.addr, range.size);
 			res = hose->io_resource;
-			res->flags = IORESOURCE_IO;
-			break;
-		case 2:		/* PCI Memory space */
-		case 3:		/* PCI 64 bits Memory space */
+		} else if (res_type == IORESOURCE_MEM) {
 			pr_info(" MEM 0x%016llx..0x%016llx\n",
-					addr, addr + size - 1);
+				range.addr, range.addr + range.size - 1);
 			res = hose->mem_resource;
-			res->flags = IORESOURCE_MEM;
-			break;
-		}
-		if (res != NULL) {
-			res->start = addr;
-			res->name = node->full_name;
-			res->end = res->start + size - 1;
-			res->parent = NULL;
-			res->sibling = NULL;
-			res->child = NULL;
 		}
+		if (res != NULL)
+			of_pci_range_to_resource(&range, node, res);
 	}
 }
 #endif
-- 
1.7.9.5



From thomas.petazzoni at free-electrons.com  Tue Apr  9 17:06:25 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Tue,  9 Apr 2013 23:06:25 +0200
Subject: [PATCHv8 04/19] of/pci: Add of_pci_get_devfn() function
In-Reply-To: <1365541601-14095-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1365541601-14095-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1365541601-14095-5-git-send-email-thomas.petazzoni@free-electrons.com>

From: Thierry Reding <thierry.reding at avionic-design.de>

This function can be used to parse the device and function number from a
standard 5-cell PCI resource. PCI_SLOT() and PCI_FUNC() can be used on
the returned value obtain the device and function numbers respectively.

Signed-off-by: Thierry Reding <thierry.reding at avionic-design.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 drivers/of/of_pci.c    |   34 +++++++++++++++++++++++++++++-----
 include/linux/of_pci.h |    1 +
 2 files changed, 30 insertions(+), 5 deletions(-)

diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
index ebb408b..b77e8d8 100644
--- a/drivers/of/of_pci.c
+++ b/drivers/of/of_pci.c
@@ -9,14 +9,15 @@
 #endif
 
 static inline int __of_pci_pci_compare(struct device_node *node,
-				       unsigned int devfn)
+				       unsigned int data)
 {
-	unsigned int size;
-	const __be32 *reg = of_get_property(node, "reg", &size);
+	int devfn;
 
-	if (!reg || size < 5 * sizeof(__be32))
+	devfn = of_pci_get_devfn(node);
+	if (devfn < 0)
 		return 0;
-	return ((be32_to_cpup(&reg[0]) >> 8) & 0xff) == devfn;
+
+	return devfn == data;
 }
 
 struct device_node *of_pci_find_child_device(struct device_node *parent,
@@ -208,3 +209,26 @@ void pci_process_bridge_OF_ranges(struct pci_controller *hose,
 	}
 }
 #endif
+
+/**
+ * of_pci_get_devfn() - Get device and function numbers for a device node
+ * @np: device node
+ *
+ * Parses a standard 5-cell PCI resource and returns an 8-bit value that can
+ * be passed to the PCI_SLOT() and PCI_FUNC() macros to extract the device
+ * and function numbers respectively. On error a negative error code is
+ * returned.
+ */
+int of_pci_get_devfn(struct device_node *np)
+{
+	unsigned int size;
+	const __be32 *reg;
+
+	reg = of_get_property(np, "reg", &size);
+
+	if (!reg || size < 5 * sizeof(__be32))
+		return -EINVAL;
+
+	return (be32_to_cpup(reg) >> 8) & 0xff;
+}
+EXPORT_SYMBOL_GPL(of_pci_get_devfn);
diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
index e56182f..302aca0 100644
--- a/include/linux/of_pci.h
+++ b/include/linux/of_pci.h
@@ -11,6 +11,7 @@ int of_irq_map_pci(const struct pci_dev *pdev, struct of_irq *out_irq);
 struct device_node;
 struct device_node *of_pci_find_child_device(struct device_node *parent,
 					     unsigned int devfn);
+int of_pci_get_devfn(struct device_node *np);
 
 void pci_process_bridge_OF_ranges(struct pci_controller *hose,
 			struct device_node *dev, int primary);
-- 
1.7.9.5



From thomas.petazzoni at free-electrons.com  Tue Apr  9 17:06:27 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Tue,  9 Apr 2013 23:06:27 +0200
Subject: [PATCHv8 06/19] pci: infrastructure to add drivers in drivers/pci/host
In-Reply-To: <1365541601-14095-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1365541601-14095-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1365541601-14095-7-git-send-email-thomas.petazzoni@free-electrons.com>

As agreed by the community, PCI host drivers will now be stored in
drivers/pci/host. This commit adds this directory and the related
Kconfig/Makefile changes to allow new drivers to be added in this
directory.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Acked-by: Bjorn Helgaas <bhelgaas at google.com>
---
 drivers/pci/Kconfig       |    2 ++
 drivers/pci/Makefile      |    3 +++
 drivers/pci/host/Kconfig  |    4 ++++
 drivers/pci/host/Makefile |    1 +
 4 files changed, 10 insertions(+)
 create mode 100644 drivers/pci/host/Kconfig
 create mode 100644 drivers/pci/host/Makefile

diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
index 6d51aa6..ac45398 100644
--- a/drivers/pci/Kconfig
+++ b/drivers/pci/Kconfig
@@ -119,3 +119,5 @@ config PCI_IOAPIC
 config PCI_LABEL
 	def_bool y if (DMI || ACPI)
 	select NLS
+
+source "drivers/pci/host/Kconfig"
diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile
index 0c3efcf..6ebf5bf 100644
--- a/drivers/pci/Makefile
+++ b/drivers/pci/Makefile
@@ -67,3 +67,6 @@ obj-$(CONFIG_XEN_PCIDEV_FRONTEND) += xen-pcifront.o
 obj-$(CONFIG_OF) += of.o
 
 ccflags-$(CONFIG_PCI_DEBUG) := -DDEBUG
+
+# PCI host controller drivers
+obj-y += host/
diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
new file mode 100644
index 0000000..cc3a1af
--- /dev/null
+++ b/drivers/pci/host/Kconfig
@@ -0,0 +1,4 @@
+menu "PCI host controller drivers"
+	depends on PCI
+
+endmenu
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
new file mode 100644
index 0000000..636bc1a
--- /dev/null
+++ b/drivers/pci/host/Makefile
@@ -0,0 +1 @@
+# intentionally empty
-- 
1.7.9.5



From thomas.petazzoni at free-electrons.com  Tue Apr  9 17:06:29 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Tue,  9 Apr 2013 23:06:29 +0200
Subject: [PATCHv8 08/19] clk: mvebu: create parent-child relation for PCIe
 clocks on Armada 370
In-Reply-To: <1365541601-14095-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1365541601-14095-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1365541601-14095-9-git-send-email-thomas.petazzoni@free-electrons.com>

The Armada 370 has two gatable clocks for each PCIe interface, and we
want both of them to be enabled. We therefore make one of the two
clocks a child of the other, as we did for the sataX and sataXlnk
clocks on Armada XP.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Cc: Mike Turquette <mturquette at linaro.org>
---
 drivers/clk/mvebu/clk-gating-ctrl.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/mvebu/clk-gating-ctrl.c b/drivers/clk/mvebu/clk-gating-ctrl.c
index ebf141d..b35785a 100644
--- a/drivers/clk/mvebu/clk-gating-ctrl.c
+++ b/drivers/clk/mvebu/clk-gating-ctrl.c
@@ -119,8 +119,8 @@ static const struct mvebu_soc_descr __initconst armada_370_gating_descr[] = {
 	{ "pex1_en", NULL,  2 },
 	{ "ge1", NULL, 3 },
 	{ "ge0", NULL, 4 },
-	{ "pex0", NULL, 5 },
-	{ "pex1", NULL, 9 },
+	{ "pex0", "pex0_en", 5 },
+	{ "pex1", "pex1_en", 9 },
 	{ "sata0", NULL, 15 },
 	{ "sdio", NULL, 17 },
 	{ "tdm", NULL, 25 },
-- 
1.7.9.5



From thomas.petazzoni at free-electrons.com  Tue Apr  9 17:06:28 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Tue,  9 Apr 2013 23:06:28 +0200
Subject: [PATCHv8 07/19] arm: pci: add a align_resource hook
In-Reply-To: <1365541601-14095-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1365541601-14095-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1365541601-14095-8-git-send-email-thomas.petazzoni@free-electrons.com>

The PCI specifications says that an I/O region must be aligned on a 4
KB boundary, and a memory region aligned on a 1 MB boundary.

However, the Marvell PCIe interfaces rely on address decoding windows
(which allow to associate a range of physical addresses with a given
device). For PCIe memory windows, those windows are defined with a 1
MB granularity (which matches the PCI specs), but PCIe I/O windows can
only be defined with a 64 KB granularity, so they have to be 64 KB
aligned. We therefore need to tell the PCI core about this special
alignement requirement.

The PCI core already calls pcibios_align_resource() in the ARM PCI
core, specifically for such purposes. So this patch extends the ARM
PCI core so that it calls a ->align_resource() hook registered by the
PCI driver, exactly like the existing ->map_irq() and ->swizzle()
hooks.

A particular PCI driver can register a align_resource() hook, and do
its own specific alignement, depending on the specific constraints of
the underlying hardware.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Cc: Russell King <linux at arm.linux.org.uk>
---
 arch/arm/include/asm/mach/pci.h |   11 +++++++++++
 arch/arm/kernel/bios32.c        |    6 ++++++
 2 files changed, 17 insertions(+)

diff --git a/arch/arm/include/asm/mach/pci.h b/arch/arm/include/asm/mach/pci.h
index 5cf2e97..7d2c3c8 100644
--- a/arch/arm/include/asm/mach/pci.h
+++ b/arch/arm/include/asm/mach/pci.h
@@ -30,6 +30,11 @@ struct hw_pci {
 	void		(*postinit)(void);
 	u8		(*swizzle)(struct pci_dev *dev, u8 *pin);
 	int		(*map_irq)(const struct pci_dev *dev, u8 slot, u8 pin);
+	resource_size_t (*align_resource)(struct pci_dev *dev,
+					  const struct resource *res,
+					  resource_size_t start,
+					  resource_size_t size,
+					  resource_size_t align);
 };
 
 /*
@@ -51,6 +56,12 @@ struct pci_sys_data {
 	u8		(*swizzle)(struct pci_dev *, u8 *);
 					/* IRQ mapping				*/
 	int		(*map_irq)(const struct pci_dev *, u8, u8);
+					/* Resource alignement requirements	*/
+	resource_size_t (*align_resource)(struct pci_dev *dev,
+					  const struct resource *res,
+					  resource_size_t start,
+					  resource_size_t size,
+					  resource_size_t align);
 	void		*private_data;	/* platform controller private data	*/
 };
 
diff --git a/arch/arm/kernel/bios32.c b/arch/arm/kernel/bios32.c
index a1f73b5..b2ed73c 100644
--- a/arch/arm/kernel/bios32.c
+++ b/arch/arm/kernel/bios32.c
@@ -462,6 +462,7 @@ static void pcibios_init_hw(struct hw_pci *hw, struct list_head *head)
 		sys->busnr   = busnr;
 		sys->swizzle = hw->swizzle;
 		sys->map_irq = hw->map_irq;
+		sys->align_resource = hw->align_resource;
 		INIT_LIST_HEAD(&sys->resources);
 
 		if (hw->private_data)
@@ -574,6 +575,8 @@ char * __init pcibios_setup(char *str)
 resource_size_t pcibios_align_resource(void *data, const struct resource *res,
 				resource_size_t size, resource_size_t align)
 {
+	struct pci_dev *dev = data;
+	struct pci_sys_data *sys = dev->sysdata;
 	resource_size_t start = res->start;
 
 	if (res->flags & IORESOURCE_IO && start & 0x300)
@@ -581,6 +584,9 @@ resource_size_t pcibios_align_resource(void *data, const struct resource *res,
 
 	start = (start + align - 1) & ~(align - 1);
 
+	if (sys->align_resource)
+		return sys->align_resource(dev, res, start, size, align);
+
 	return start;
 }
 
-- 
1.7.9.5



From thomas.petazzoni at free-electrons.com  Tue Apr  9 17:06:32 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Tue,  9 Apr 2013 23:06:32 +0200
Subject: [PATCHv8 11/19] arm: mvebu: PCIe support is now available on mvebu
In-Reply-To: <1365541601-14095-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1365541601-14095-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1365541601-14095-12-git-send-email-thomas.petazzoni@free-electrons.com>

Now that the PCIe driver for mvebu has been integrated and all its
relevant dependencies, we can mark the ARCH_MVEBU platform has
MIGHT_HAVE_PCI, which allows to select the PCI bus support if needed.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 arch/arm/mach-mvebu/Kconfig |    2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index c3715a5..d353249 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -14,6 +14,8 @@ config ARCH_MVEBU
 	select MVEBU_CLK_CPU
 	select MVEBU_CLK_GATING
 	select MVEBU_MBUS
+	select MIGHT_HAVE_PCI
+	select PCI_QUIRKS if PCI
 
 if ARCH_MVEBU
 
-- 
1.7.9.5



From thomas.petazzoni at free-electrons.com  Tue Apr  9 17:06:30 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Tue,  9 Apr 2013 23:06:30 +0200
Subject: [PATCHv8 09/19] clk: mvebu: add more PCIe clocks for Armada XP
In-Reply-To: <1365541601-14095-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1365541601-14095-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1365541601-14095-10-git-send-email-thomas.petazzoni@free-electrons.com>

The current revision of the datasheet only mentions the gatable clocks
for the PCIe 0.0, 0.1, 0.2 and 0.3 interfaces, and forgot to mention
the ones for the PCIe 1.0, 1.1, 1.2, 1.3, 2.0 and 3.0
interfaces. After confirmation with Marvell engineers, this patch adds
the missing gatable clocks for those PCIe interfaces.

It also changes the name of the previously existing PCIe gatable
clocks, in order to match the naming using the datasheets.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Cc: Mike Turquette <mturquette at linaro.org>
---
 drivers/clk/mvebu/clk-gating-ctrl.c |   14 ++++++++++----
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/clk/mvebu/clk-gating-ctrl.c b/drivers/clk/mvebu/clk-gating-ctrl.c
index b35785a..2f03723 100644
--- a/drivers/clk/mvebu/clk-gating-ctrl.c
+++ b/drivers/clk/mvebu/clk-gating-ctrl.c
@@ -137,10 +137,14 @@ static const struct mvebu_soc_descr __initconst armada_xp_gating_descr[] = {
 	{ "ge2", NULL,  2 },
 	{ "ge1", NULL, 3 },
 	{ "ge0", NULL, 4 },
-	{ "pex0", NULL, 5 },
-	{ "pex1", NULL, 6 },
-	{ "pex2", NULL, 7 },
-	{ "pex3", NULL, 8 },
+	{ "pex00", NULL, 5 },
+	{ "pex01", NULL, 6 },
+	{ "pex02", NULL, 7 },
+	{ "pex03", NULL, 8 },
+	{ "pex10", NULL, 9 },
+	{ "pex11", NULL, 10 },
+	{ "pex12", NULL, 11 },
+	{ "pex13", NULL, 12 },
 	{ "bp", NULL, 13 },
 	{ "sata0lnk", NULL, 14 },
 	{ "sata0", "sata0lnk", 15 },
@@ -152,6 +156,8 @@ static const struct mvebu_soc_descr __initconst armada_xp_gating_descr[] = {
 	{ "xor0", NULL, 22 },
 	{ "crypto", NULL, 23 },
 	{ "tdm", NULL, 25 },
+	{ "pex20", NULL, 26 },
+	{ "pex30", NULL, 27 },
 	{ "xor1", NULL, 28 },
 	{ "sata1lnk", NULL, 29 },
 	{ "sata1", "sata1lnk", 30 },
-- 
1.7.9.5



From thomas.petazzoni at free-electrons.com  Tue Apr  9 17:06:33 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Tue,  9 Apr 2013 23:06:33 +0200
Subject: [PATCHv8 12/19] arm: mvebu: add PCIe Device Tree informations for
 Armada 370
In-Reply-To: <1365541601-14095-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1365541601-14095-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1365541601-14095-13-git-send-email-thomas.petazzoni@free-electrons.com>

The Armada 370 SoC has two 1x PCIe 2.0 interfaces, so we add the
necessary Device Tree informations to make these interfaces availabel.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 arch/arm/boot/dts/armada-370.dtsi |   51 +++++++++++++++++++++++++++++++++++++
 1 file changed, 51 insertions(+)

diff --git a/arch/arm/boot/dts/armada-370.dtsi b/arch/arm/boot/dts/armada-370.dtsi
index 8188d13..2d9f8d6 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -153,5 +153,56 @@
 			clocks = <&coreclk 0>;
 		};
 
+		pcie-controller {
+			compatible = "marvell,armada-370-pcie";
+			status = "disabled";
+			device_type = "pci";
+
+			#address-cells = <3>;
+			#size-cells = <2>;
+
+			bus-range = <0x00 0xff>;
+
+			reg = <0xd0040000 0x2000>, <0xd0080000 0x2000>;
+
+			reg-names = "pcie0.0", "pcie1.0";
+
+			ranges = <0x82000000 0 0xd0040000 0xd0040000 0 0x00002000   /* Port 0.0 registers */
+				  0x82000000 0 0xd0080000 0xd0080000 0 0x00002000   /* Port 1.0 registers */
+				  0x82000000 0 0xe0000000 0xe0000000 0 0x08000000   /* non-prefetchable memory */
+			          0x81000000 0 0          0xe8000000 0 0x00100000>; /* downstream I/O */
+
+			pcie at 1,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82000800 0 0xd0040000 0 0x2000>;
+				reg = <0x0800 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 58>;
+				marvell,pcie-port = <0>;
+				marvell,pcie-lane = <0>;
+				clocks = <&gateclk 5>;
+				status = "disabled";
+			};
+
+			pcie at 2,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82002800 0 0xd0080000 0 0x2000>;
+				reg = <0x1000 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 62>;
+				marvell,pcie-port = <1>;
+				marvell,pcie-lane = <0>;
+				clocks = <&gateclk 9>;
+				status = "disabled";
+			};
+		};
 	};
 };
-- 
1.7.9.5



From thomas.petazzoni at free-electrons.com  Tue Apr  9 17:06:36 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Tue,  9 Apr 2013 23:06:36 +0200
Subject: [PATCHv8 15/19] arm: mvebu: PCIe Device Tree informations for Armada
 XP DB
In-Reply-To: <1365541601-14095-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1365541601-14095-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1365541601-14095-16-git-send-email-thomas.petazzoni@free-electrons.com>

The Marvell evaluation board (DB) for the Armada XP SoC has 6
physicals full-size PCIe slots, so we enable the corresponding PCIe
interfaces in the Device Tree.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 arch/arm/boot/dts/armada-xp-db.dts |   33 +++++++++++++++++++++++++++++++++
 1 file changed, 33 insertions(+)

diff --git a/arch/arm/boot/dts/armada-xp-db.dts b/arch/arm/boot/dts/armada-xp-db.dts
index e83505e..54cc5bb 100644
--- a/arch/arm/boot/dts/armada-xp-db.dts
+++ b/arch/arm/boot/dts/armada-xp-db.dts
@@ -121,5 +121,38 @@
 				spi-max-frequency = <20000000>;
 			};
 		};
+
+		pcie-controller {
+			status = "okay";
+
+			/*
+			 * All 6 slots are physically present as
+			 * standard PCIe slots on the board.
+			 */
+			pcie at 1,0 {
+				/* Port 0, Lane 0 */
+				status = "okay";
+			};
+			pcie at 2,0 {
+				/* Port 0, Lane 1 */
+				status = "okay";
+			};
+			pcie at 3,0 {
+				/* Port 0, Lane 2 */
+				status = "okay";
+			};
+			pcie at 4,0 {
+				/* Port 0, Lane 3 */
+				status = "okay";
+			};
+			pcie at 9,0 {
+				/* Port 2, Lane 0 */
+				status = "okay";
+			};
+			pcie at 10,0 {
+				/* Port 3, Lane 0 */
+				status = "okay";
+			};
+		};
 	};
 };
-- 
1.7.9.5



From thomas.petazzoni at free-electrons.com  Tue Apr  9 17:06:35 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Tue,  9 Apr 2013 23:06:35 +0200
Subject: [PATCHv8 14/19] arm: mvebu: PCIe Device Tree informations for
 OpenBlocks AX3-4
In-Reply-To: <1365541601-14095-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1365541601-14095-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1365541601-14095-15-git-send-email-thomas.petazzoni@free-electrons.com>

The PlatHome OpenBlocks AX3-4 has an internal mini-PCIe slot that can
be used to plug mini-PCIe devices. We therefore enable the PCIe
interface that corresponds to this slot.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts |    9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
index 3818a82..5a748bd 100644
--- a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
+++ b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
@@ -139,5 +139,14 @@
 		usb at d0051000 {
 			status = "okay";
 		};
+
+		pcie-controller {
+			status = "okay";
+			/* Internal mini-PCIe connector */
+			pcie at 1,0 {
+				/* Port 0, Lane 0 */
+				status = "okay";
+			};
+		};
 	};
 };
-- 
1.7.9.5



From thomas.petazzoni at free-electrons.com  Tue Apr  9 17:06:37 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Tue,  9 Apr 2013 23:06:37 +0200
Subject: [PATCHv8 16/19] arm: mvebu: PCIe Device Tree informations for Armada
 370 Mirabox
In-Reply-To: <1365541601-14095-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1365541601-14095-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1365541601-14095-17-git-send-email-thomas.petazzoni@free-electrons.com>

The Globalscale Mirabox platform uses one PCIe interface for an
available mini-PCIe slot, and the other PCIe interface for an internal
USB 3.0 controller. We add the necessary Device Tree informations to
enable those two interfaces.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 arch/arm/boot/dts/armada-370-mirabox.dts |   16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/arch/arm/boot/dts/armada-370-mirabox.dts b/arch/arm/boot/dts/armada-370-mirabox.dts
index dd0c57d..5549de6 100644
--- a/arch/arm/boot/dts/armada-370-mirabox.dts
+++ b/arch/arm/boot/dts/armada-370-mirabox.dts
@@ -70,5 +70,21 @@
 		usb at d0051000 {
 			status = "okay";
 		};
+
+		pcie-controller {
+			status = "okay";
+
+			/* Internal mini-PCIe connector */
+			pcie at 1,0 {
+				/* Port 0, Lane 0 */
+				status = "okay";
+			};
+
+			/* Connected on the PCB to a USB 3.0 XHCI controller */
+			pcie at 2,0 {
+				/* Port 1, Lane 0 */
+				status = "okay";
+			};
+		};
 	};
 };
-- 
1.7.9.5



From thomas.petazzoni at free-electrons.com  Tue Apr  9 17:06:38 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Tue,  9 Apr 2013 23:06:38 +0200
Subject: [PATCHv8 17/19] arm: mvebu: PCIe Device Tree informations for Armada
 370 DB
In-Reply-To: <1365541601-14095-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1365541601-14095-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1365541601-14095-18-git-send-email-thomas.petazzoni@free-electrons.com>

The Marvell evaluation board (DB) for the Armada 370 SoC has 2
physical full-size PCIe slots, so we enable the corresponding PCIe
interfaces in the Device Tree.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 arch/arm/boot/dts/armada-370-db.dts |   17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/arch/arm/boot/dts/armada-370-db.dts b/arch/arm/boot/dts/armada-370-db.dts
index e34b280..6403acd 100644
--- a/arch/arm/boot/dts/armada-370-db.dts
+++ b/arch/arm/boot/dts/armada-370-db.dts
@@ -94,5 +94,22 @@
 				spi-max-frequency = <50000000>;
 			};
 		};
+
+		pcie-controller {
+			status = "okay";
+			/*
+			 * The two PCIe units are accessible through
+			 * both standard PCIe slots and mini-PCIe
+			 * slots on the board.
+			 */
+			pcie at 1,0 {
+				/* Port 0, Lane 0 */
+				status = "okay";
+			};
+			pcie at 2,0 {
+				/* Port 1, Lane 0 */
+				status = "okay";
+			};
+		};
 	};
 };
-- 
1.7.9.5



From thomas.petazzoni at free-electrons.com  Tue Apr  9 17:06:39 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Tue,  9 Apr 2013 23:06:39 +0200
Subject: [PATCHv8 18/19] arm: mvebu: PCIe Device Tree informations for Armada
 XP GP
In-Reply-To: <1365541601-14095-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1365541601-14095-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1365541601-14095-19-git-send-email-thomas.petazzoni@free-electrons.com>

The Marvell Armada XP GP board has 3 physical full-size PCIe slots, so
we enable the corresponding PCIe interfaces in the Device Tree.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 arch/arm/boot/dts/armada-xp-gp.dts |   21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/arch/arm/boot/dts/armada-xp-gp.dts b/arch/arm/boot/dts/armada-xp-gp.dts
index 1c8afe2..e2bf6b4 100644
--- a/arch/arm/boot/dts/armada-xp-gp.dts
+++ b/arch/arm/boot/dts/armada-xp-gp.dts
@@ -109,5 +109,26 @@
 				spi-max-frequency = <108000000>;
 			};
 		};
+
+		pcie-controller {
+			status = "okay";
+
+			/*
+			 * The 3 slots are physically present as
+			 * standard PCIe slots on the board.
+			 */
+			pcie at 1,0 {
+				/* Port 0, Lane 0 */
+				status = "okay";
+			};
+			pcie at 9,0 {
+				/* Port 2, Lane 0 */
+				status = "okay";
+			};
+			pcie at 10,0 {
+				/* Port 3, Lane 0 */
+				status = "okay";
+			};
+		};
 	};
 };
-- 
1.7.9.5



From thomas.petazzoni at free-electrons.com  Tue Apr  9 17:06:40 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Tue,  9 Apr 2013 23:06:40 +0200
Subject: [PATCHv8 19/19] arm: mvebu: update defconfig with PCI and USB support
In-Reply-To: <1365541601-14095-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1365541601-14095-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1365541601-14095-20-git-send-email-thomas.petazzoni@free-electrons.com>

Now that we have the necessary drivers and Device Tree informations to
support PCIe on Armada 370 and Armada XP, enable the CONFIG_PCI
option.

Also, since the Armada 370 Mirabox has a built-in USB XHCI controller
connected on the PCIe bus, enable the corresponding options as well.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 arch/arm/configs/mvebu_defconfig |    3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/configs/mvebu_defconfig b/arch/arm/configs/mvebu_defconfig
index 2ec8119..071a5b1 100644
--- a/arch/arm/configs/mvebu_defconfig
+++ b/arch/arm/configs/mvebu_defconfig
@@ -13,6 +13,8 @@ CONFIG_MACH_ARMADA_370=y
 CONFIG_MACH_ARMADA_XP=y
 # CONFIG_CACHE_L2X0 is not set
 # CONFIG_SWP_EMULATE is not set
+CONFIG_PCI=y
+CONFIG_PCI_MVEBU=y
 CONFIG_SMP=y
 CONFIG_AEABI=y
 CONFIG_HIGHMEM=y
@@ -53,6 +55,7 @@ CONFIG_USB_SUPPORT=y
 CONFIG_USB=y
 CONFIG_USB_EHCI_HCD=y
 CONFIG_USB_EHCI_ROOT_HUB_TT=y
+CONFIG_USB_XHCI_HCD=y
 CONFIG_MMC=y
 CONFIG_MMC_MVSDIO=y
 CONFIG_NEW_LEDS=y
-- 
1.7.9.5



From thomas.petazzoni at free-electrons.com  Tue Apr  9 17:06:34 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Tue,  9 Apr 2013 23:06:34 +0200
Subject: [PATCHv8 13/19] arm: mvebu: add PCIe Device Tree informations for
 Armada XP
In-Reply-To: <1365541601-14095-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1365541601-14095-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1365541601-14095-14-git-send-email-thomas.petazzoni@free-electrons.com>

The Armada XP SoCs have multiple PCIe interfaces. The MV78230 has 2
PCIe units (one 4x or quad 1x, the other 1x only), the MV78260 has 3
PCIe units (two 4x or quad 1x and one 4x/1x), the MV78460 has 4 PCIe
units (two 4x or quad 1x and two 4x/1x). We therefore add the
necessary Device Tree informations to make those PCIe interfaces
usable.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 arch/arm/boot/dts/armada-xp-mv78230.dtsi |  104 +++++++++++++++++
 arch/arm/boot/dts/armada-xp-mv78260.dtsi |  122 +++++++++++++++++++
 arch/arm/boot/dts/armada-xp-mv78460.dtsi |  188 ++++++++++++++++++++++++++++++
 3 files changed, 414 insertions(+)

diff --git a/arch/arm/boot/dts/armada-xp-mv78230.dtsi b/arch/arm/boot/dts/armada-xp-mv78230.dtsi
index f56c405..c2c7845 100644
--- a/arch/arm/boot/dts/armada-xp-mv78230.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78230.dtsi
@@ -76,5 +76,109 @@
 			#interrupts-cells = <2>;
 			interrupts = <87>, <88>, <89>;
 		};
+
+		/*
+		 * MV78230 has 2 PCIe units Gen2.0: One unit can be
+		 * configured as x4 or quad x1 lanes. One unit is
+		 * x4/x1.
+		 */
+		pcie-controller {
+			compatible = "marvell,armada-xp-pcie";
+			status = "disabled";
+			device_type = "pci";
+
+			#address-cells = <3>;
+			#size-cells = <2>;
+
+			bus-range = <0x00 0xff>;
+
+			ranges = <0x82000000 0 0xd0040000 0xd0040000 0 0x00002000   /* Port 0.0 registers */
+				  0x82000000 0 0xd0042000 0xd0042000 0 0x00002000   /* Port 2.0 registers */
+				  0x82000000 0 0xd0044000 0xd0044000 0 0x00002000   /* Port 0.1 registers */
+				  0x82000000 0 0xd0048000 0xd0048000 0 0x00002000   /* Port 0.2 registers */
+				  0x82000000 0 0xd004c000 0xd004c000 0 0x00002000   /* Port 0.3 registers */
+				  0x82000000 0 0xe0000000 0xe0000000 0 0x08000000   /* non-prefetchable memory */
+				  0x81000000 0 0	  0xe8000000 0 0x00100000>; /* downstream I/O */
+
+			pcie at 1,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82000800 0 0xd0040000 0 0x2000>;
+				reg = <0x0800 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 58>;
+				marvell,pcie-port = <0>;
+				marvell,pcie-lane = <0>;
+				clocks = <&gateclk 5>;
+				status = "disabled";
+			};
+
+			pcie at 2,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82000800 0 0xd0044000 0 0x2000>;
+				reg = <0x1000 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 59>;
+				marvell,pcie-port = <0>;
+				marvell,pcie-lane = <1>;
+				clocks = <&gateclk 6>;
+				status = "disabled";
+			};
+
+			pcie at 3,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82000800 0 0xd0048000 0 0x2000>;
+				reg = <0x1800 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 60>;
+				marvell,pcie-port = <0>;
+				marvell,pcie-lane = <2>;
+				clocks = <&gateclk 7>;
+				status = "disabled";
+			};
+
+			pcie at 4,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82000800 0 0xd004c000 0 0x2000>;
+				reg = <0x2000 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 61>;
+				marvell,pcie-port = <0>;
+				marvell,pcie-lane = <3>;
+				clocks = <&gateclk 8>;
+				status = "disabled";
+			};
+
+			pcie at 9,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82000800 0 0xd0042000 0 0x2000>;
+				reg = <0x4800 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 99>;
+				marvell,pcie-port = <2>;
+				marvell,pcie-lane = <0>;
+				clocks = <&gateclk 26>;
+				status = "disabled";
+			};
+		};
 	};
 };
diff --git a/arch/arm/boot/dts/armada-xp-mv78260.dtsi b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
index f8f2b78..885bf22 100644
--- a/arch/arm/boot/dts/armada-xp-mv78260.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
@@ -96,5 +96,127 @@
 				clocks = <&gateclk 1>;
 				status = "disabled";
 		};
+
+		/*
+		 * MV78260 has 3 PCIe units Gen2.0: Two units can be
+		 * configured as x4 or quad x1 lanes. One unit is
+		 * x4/x1.
+		 */
+		pcie-controller {
+			compatible = "marvell,armada-xp-pcie";
+			status = "disabled";
+			device_type = "pci";
+
+			#address-cells = <3>;
+			#size-cells = <2>;
+
+			bus-range = <0x00 0xff>;
+
+			ranges = <0x82000000 0 0xd0040000 0xd0040000 0 0x00002000   /* Port 0.0 registers */
+				  0x82000000 0 0xd0042000 0xd0042000 0 0x00002000   /* Port 2.0 registers */
+				  0x82000000 0 0xd0044000 0xd0044000 0 0x00002000   /* Port 0.1 registers */
+				  0x82000000 0 0xd0048000 0xd0048000 0 0x00002000   /* Port 0.2 registers */
+				  0x82000000 0 0xd004c000 0xd004c000 0 0x00002000   /* Port 0.3 registers */
+				  0x82000000 0 0xd0080000 0xd0080000 0 0x00002000   /* Port 1.0 registers */
+				  0x82000000 0 0xd0082000 0xd0082000 0 0x00002000   /* Port 3.0 registers */
+				  0x82000000 0 0xe0000000 0xe0000000 0 0x08000000   /* non-prefetchable memory */
+				  0x81000000 0 0	  0xe8000000 0 0x00100000>; /* downstream I/O */
+
+			pcie at 1,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82000800 0 0xd0040000 0 0x2000>;
+				reg = <0x0800 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 58>;
+				marvell,pcie-port = <0>;
+				marvell,pcie-lane = <0>;
+				clocks = <&gateclk 5>;
+				status = "disabled";
+			};
+
+			pcie at 2,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82000800 0 0xd0044000 0 0x2000>;
+				reg = <0x1000 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 59>;
+				marvell,pcie-port = <0>;
+				marvell,pcie-lane = <1>;
+				clocks = <&gateclk 6>;
+				status = "disabled";
+			};
+
+			pcie at 3,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82000800 0 0xd0048000 0 0x2000>;
+				reg = <0x1800 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 60>;
+				marvell,pcie-port = <0>;
+				marvell,pcie-lane = <2>;
+				clocks = <&gateclk 7>;
+				status = "disabled";
+			};
+
+			pcie at 4,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82000800 0 0xd004c000 0 0x2000>;
+				reg = <0x2000 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 61>;
+				marvell,pcie-port = <0>;
+				marvell,pcie-lane = <3>;
+				clocks = <&gateclk 8>;
+				status = "disabled";
+			};
+
+			pcie at 9,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82000800 0 0xd0042000 0 0x2000>;
+				reg = <0x4800 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 99>;
+				marvell,pcie-port = <2>;
+				marvell,pcie-lane = <0>;
+				clocks = <&gateclk 26>;
+				status = "disabled";
+			};
+
+			pcie at 10,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82000800 0 0xd0082000 0 0x2000>;
+				reg = <0x5000 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 103>;
+				marvell,pcie-port = <3>;
+				marvell,pcie-lane = <0>;
+				clocks = <&gateclk 27>;
+				status = "disabled";
+			};
+		};
 	};
 };
diff --git a/arch/arm/boot/dts/armada-xp-mv78460.dtsi b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
index 936c25d..23a5ac4 100644
--- a/arch/arm/boot/dts/armada-xp-mv78460.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
@@ -111,5 +111,193 @@
 				clocks = <&gateclk 1>;
 				status = "disabled";
 		};
+
+		/*
+		 * MV78460 has 4 PCIe units Gen2.0: Two units can be
+		 * configured as x4 or quad x1 lanes. Two units are
+		 * x4/x1.
+		 */
+		pcie-controller {
+			compatible = "marvell,armada-xp-pcie";
+			status = "disabled";
+			device_type = "pci";
+
+			#address-cells = <3>;
+			#size-cells = <2>;
+
+			bus-range = <0x00 0xff>;
+
+			ranges = <0x82000000 0 0xd0040000 0xd0040000 0 0x00002000   /* Port 0.0 registers */
+				  0x82000000 0 0xd0042000 0xd0042000 0 0x00002000   /* Port 2.0 registers */
+				  0x82000000 0 0xd0044000 0xd0044000 0 0x00002000   /* Port 0.1 registers */
+				  0x82000000 0 0xd0048000 0xd0048000 0 0x00002000   /* Port 0.2 registers */
+				  0x82000000 0 0xd004c000 0xd004c000 0 0x00002000   /* Port 0.3 registers */
+				  0x82000000 0 0xd0080000 0xd0080000 0 0x00002000   /* Port 1.0 registers */
+				  0x82000000 0 0xd0082000 0xd0082000 0 0x00002000   /* Port 3.0 registers */
+				  0x82000000 0 0xd0084000 0xd0084000 0 0x00002000   /* Port 1.1 registers */
+				  0x82000000 0 0xd0088000 0xd0088000 0 0x00002000   /* Port 1.2 registers */
+				  0x82000000 0 0xd008c000 0xd008c000 0 0x00002000   /* Port 1.3 registers */
+				  0x82000000 0 0xe0000000 0xe0000000 0 0x08000000   /* non-prefetchable memory */
+				  0x81000000 0 0	  0xe8000000 0 0x00100000>; /* downstream I/O */
+
+			pcie at 1,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82000800 0 0xd0040000 0 0x2000>;
+				reg = <0x0800 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 58>;
+				marvell,pcie-port = <0>;
+				marvell,pcie-lane = <0>;
+				clocks = <&gateclk 5>;
+				status = "disabled";
+			};
+
+			pcie at 2,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82001000 0 0xd0044000 0 0x2000>;
+				reg = <0x1000 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 59>;
+				marvell,pcie-port = <0>;
+				marvell,pcie-lane = <1>;
+				clocks = <&gateclk 6>;
+				status = "disabled";
+			};
+
+			pcie at 3,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82001800 0 0xd0048000 0 0x2000>;
+				reg = <0x1800 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 60>;
+				marvell,pcie-port = <0>;
+				marvell,pcie-lane = <2>;
+				clocks = <&gateclk 7>;
+				status = "disabled";
+			};
+
+			pcie at 4,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82002000 0 0xd004c000 0 0x2000>;
+				reg = <0x2000 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 61>;
+				marvell,pcie-port = <0>;
+				marvell,pcie-lane = <3>;
+				clocks = <&gateclk 8>;
+				status = "disabled";
+			};
+
+			pcie at 5,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82002800 0 0xd0080000 0 0x2000>;
+				reg = <0x2800 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 62>;
+				marvell,pcie-port = <1>;
+				marvell,pcie-lane = <0>;
+				clocks = <&gateclk 9>;
+				status = "disabled";
+			};
+
+			pcie at 6,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82003000 0 0xd0084000 0 0x2000>;
+				reg = <0x3000 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 63>;
+				marvell,pcie-port = <1>;
+				marvell,pcie-lane = <1>;
+				clocks = <&gateclk 10>;
+				status = "disabled";
+			};
+
+			pcie at 7,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82003800 0 0xd0088000 0 0x2000>;
+				reg = <0x3800 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 64>;
+				marvell,pcie-port = <1>;
+				marvell,pcie-lane = <2>;
+				clocks = <&gateclk 11>;
+				status = "disabled";
+			};
+
+			pcie at 8,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82004000 0 0xd008c000 0 0x2000>;
+				reg = <0x4000 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 65>;
+				marvell,pcie-port = <1>;
+				marvell,pcie-lane = <3>;
+				clocks = <&gateclk 12>;
+				status = "disabled";
+			};
+			pcie at 9,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82004800 0 0xd0042000 0 0x2000>;
+				reg = <0x4800 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 99>;
+				marvell,pcie-port = <2>;
+				marvell,pcie-lane = <0>;
+				clocks = <&gateclk 26>;
+				status = "disabled";
+			};
+
+			pcie at 10,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82005000 0 0xd0082000 0 0x2000>;
+				reg = <0x5000 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 103>;
+				marvell,pcie-port = <3>;
+				marvell,pcie-lane = <0>;
+				clocks = <&gateclk 27>;
+				status = "disabled";
+			};
+		};
 	};
  };
-- 
1.7.9.5



From thomas.petazzoni at free-electrons.com  Tue Apr  9 17:06:31 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Tue,  9 Apr 2013 23:06:31 +0200
Subject: [PATCHv8 10/19] pci: PCIe driver for Marvell Armada 370/XP systems
In-Reply-To: <1365541601-14095-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1365541601-14095-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1365541601-14095-11-git-send-email-thomas.petazzoni@free-electrons.com>

This driver implements the support for the PCIe interfaces on the
Marvell Armada 370/XP ARM SoCs. In the future, it might be extended to
cover earlier families of Marvell SoCs, such as Dove, Orion and
Kirkwood.

The driver implements the hw_pci operations needed by the core ARM PCI
code to setup PCI devices and get their corresponding IRQs, and the
pci_ops operations that are used by the PCI core to read/write the
configuration space of PCI devices.

Since the PCIe interfaces of Marvell SoCs are completely separate and
not linked together in a bus, this driver sets up an emulated PCI host
bridge, with one PCI-to-PCI bridge as child for each hardware PCIe
interface.

In addition, this driver enumerates the different PCIe slots, and for
those having a device plugged in, it sets up the necessary address
decoding windows, using the new armada_370_xp_alloc_pcie_window()
function from mach-mvebu/addr-map.c.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Acked-by: Bjorn Helgaas <bhelgaas at google.com>
---
 .../devicetree/bindings/pci/mvebu-pci.txt          |  220 +++++
 drivers/pci/host/Kconfig                           |    4 +
 drivers/pci/host/Makefile                          |    2 +-
 drivers/pci/host/pci-mvebu.c                       |  879 ++++++++++++++++++++
 4 files changed, 1104 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/pci/mvebu-pci.txt
 create mode 100644 drivers/pci/host/pci-mvebu.c

diff --git a/Documentation/devicetree/bindings/pci/mvebu-pci.txt b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
new file mode 100644
index 0000000..eb69d92
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
@@ -0,0 +1,220 @@
+* Marvell EBU PCIe interfaces
+
+Mandatory properties:
+- compatible: one of the following values:
+    marvell,armada-370-pcie
+    marvell,armada-xp-pcie
+- #address-cells, set to <3>
+- #size-cells, set to <2>
+- #interrupt-cells, set to <1>
+- bus-range: PCI bus numbers covered
+- device_type, set to "pci"
+- ranges: ranges for the PCI memory and I/O regions, as well as the
+  MMIO registers to control the PCIe interfaces.
+
+In addition, the Device Tree node must have sub-nodes describing each
+PCIe interface, having the following mandatory properties:
+- reg: used only for interrupt mapping, so only the first four bytes
+  are used to refer to the correct bus number and device number.
+- assigned-addresses: reference to the MMIO registers used to control
+  this PCIe interface.
+- clocks: the clock associated to this PCIe interface
+- marvell,pcie-port: the physical PCIe port number
+- status: either "disabled" or "okay"
+- device_type, set to "pci"
+- #address-cells, set to <3>
+- #size-cells, set to <2>
+- #interrupt-cells, set to <1>
+- ranges, empty property.
+- interrupt-map-mask and interrupt-map, standard PCI properties to
+  define the mapping of the PCIe interface to interrupt numbers.
+
+and the following optional properties:
+- marvell,pcie-lane: the physical PCIe lane number, for ports having
+  multiple lanes. If this property is not found, we assume that the
+  value is 0.
+
+Example:
+
+pcie-controller {
+	compatible = "marvell,armada-xp-pcie";
+	status = "disabled";
+	device_type = "pci";
+
+	#address-cells = <3>;
+	#size-cells = <2>;
+
+	bus-range = <0x00 0xff>;
+
+	ranges = <0x82000000 0 0xd0040000 0xd0040000 0 0x00002000   /* Port 0.0 registers */
+		  0x82000000 0 0xd0042000 0xd0042000 0 0x00002000   /* Port 2.0 registers */
+		  0x82000000 0 0xd0044000 0xd0044000 0 0x00002000   /* Port 0.1 registers */
+		  0x82000000 0 0xd0048000 0xd0048000 0 0x00002000   /* Port 0.2 registers */
+		  0x82000000 0 0xd004c000 0xd004c000 0 0x00002000   /* Port 0.3 registers */
+		  0x82000000 0 0xd0080000 0xd0080000 0 0x00002000   /* Port 1.0 registers */
+		  0x82000000 0 0xd0082000 0xd0082000 0 0x00002000   /* Port 3.0 registers */
+		  0x82000000 0 0xd0084000 0xd0084000 0 0x00002000   /* Port 1.1 registers */
+		  0x82000000 0 0xd0088000 0xd0088000 0 0x00002000   /* Port 1.2 registers */
+		  0x82000000 0 0xd008c000 0xd008c000 0 0x00002000   /* Port 1.3 registers */
+		  0x82000000 0 0xe0000000 0xe0000000 0 0x08000000   /* non-prefetchable memory */
+		  0x81000000 0 0	  0xe8000000 0 0x00100000>; /* downstream I/O */
+
+	pcie at 1,0 {
+		device_type = "pci";
+		assigned-addresses = <0x82000800 0 0xd0040000 0 0x2000>;
+		reg = <0x0800 0 0 0 0>;
+		#address-cells = <3>;
+		#size-cells = <2>;
+		#interrupt-cells = <1>;
+		ranges;
+		interrupt-map-mask = <0 0 0 0>;
+		interrupt-map = <0 0 0 0 &mpic 58>;
+		marvell,pcie-port = <0>;
+		marvell,pcie-lane = <0>;
+		clocks = <&gateclk 5>;
+		status = "disabled";
+	};
+
+	pcie at 2,0 {
+		device_type = "pci";
+		assigned-addresses = <0x82001000 0 0xd0044000 0 0x2000>;
+		reg = <0x1000 0 0 0 0>;
+		#address-cells = <3>;
+		#size-cells = <2>;
+		#interrupt-cells = <1>;
+		ranges;
+		interrupt-map-mask = <0 0 0 0>;
+		interrupt-map = <0 0 0 0 &mpic 59>;
+		marvell,pcie-port = <0>;
+		marvell,pcie-lane = <1>;
+		clocks = <&gateclk 6>;
+		status = "disabled";
+	};
+
+	pcie at 3,0 {
+		device_type = "pci";
+		assigned-addresses = <0x82001800 0 0xd0048000 0 0x2000>;
+		reg = <0x1800 0 0 0 0>;
+		#address-cells = <3>;
+		#size-cells = <2>;
+		#interrupt-cells = <1>;
+		ranges;
+		interrupt-map-mask = <0 0 0 0>;
+		interrupt-map = <0 0 0 0 &mpic 60>;
+		marvell,pcie-port = <0>;
+		marvell,pcie-lane = <2>;
+		clocks = <&gateclk 7>;
+		status = "disabled";
+	};
+
+	pcie at 4,0 {
+		device_type = "pci";
+		assigned-addresses = <0x82002000 0 0xd004c000 0 0x2000>;
+		reg = <0x2000 0 0 0 0>;
+		#address-cells = <3>;
+		#size-cells = <2>;
+		#interrupt-cells = <1>;
+		ranges;
+		interrupt-map-mask = <0 0 0 0>;
+		interrupt-map = <0 0 0 0 &mpic 61>;
+		marvell,pcie-port = <0>;
+		marvell,pcie-lane = <3>;
+		clocks = <&gateclk 8>;
+		status = "disabled";
+	};
+
+	pcie at 5,0 {
+		device_type = "pci";
+		assigned-addresses = <0x82002800 0 0xd0080000 0 0x2000>;
+		reg = <0x2800 0 0 0 0>;
+		#address-cells = <3>;
+		#size-cells = <2>;
+		#interrupt-cells = <1>;
+		ranges;
+		interrupt-map-mask = <0 0 0 0>;
+		interrupt-map = <0 0 0 0 &mpic 62>;
+		marvell,pcie-port = <1>;
+		marvell,pcie-lane = <0>;
+		clocks = <&gateclk 9>;
+		status = "disabled";
+	};
+
+	pcie at 6,0 {
+		device_type = "pci";
+		assigned-addresses = <0x82003000 0 0xd0084000 0 0x2000>;
+		reg = <0x3000 0 0 0 0>;
+		#address-cells = <3>;
+		#size-cells = <2>;
+		#interrupt-cells = <1>;
+		ranges;
+		interrupt-map-mask = <0 0 0 0>;
+		interrupt-map = <0 0 0 0 &mpic 63>;
+		marvell,pcie-port = <1>;
+		marvell,pcie-lane = <1>;
+		clocks = <&gateclk 10>;
+		status = "disabled";
+	};
+
+	pcie at 7,0 {
+		device_type = "pci";
+		assigned-addresses = <0x82003800 0 0xd0088000 0 0x2000>;
+		reg = <0x3800 0 0 0 0>;
+		#address-cells = <3>;
+		#size-cells = <2>;
+		#interrupt-cells = <1>;
+		ranges;
+		interrupt-map-mask = <0 0 0 0>;
+		interrupt-map = <0 0 0 0 &mpic 64>;
+		marvell,pcie-port = <1>;
+		marvell,pcie-lane = <2>;
+		clocks = <&gateclk 11>;
+		status = "disabled";
+	};
+
+	pcie at 8,0 {
+		device_type = "pci";
+		assigned-addresses = <0x82004000 0 0xd008c000 0 0x2000>;
+		reg = <0x4000 0 0 0 0>;
+		#address-cells = <3>;
+		#size-cells = <2>;
+		#interrupt-cells = <1>;
+		ranges;
+		interrupt-map-mask = <0 0 0 0>;
+		interrupt-map = <0 0 0 0 &mpic 65>;
+		marvell,pcie-port = <1>;
+		marvell,pcie-lane = <3>;
+		clocks = <&gateclk 12>;
+		status = "disabled";
+	};
+	pcie at 9,0 {
+		device_type = "pci";
+		assigned-addresses = <0x82004800 0 0xd0042000 0 0x2000>;
+		reg = <0x4800 0 0 0 0>;
+		#address-cells = <3>;
+		#size-cells = <2>;
+		#interrupt-cells = <1>;
+		ranges;
+		interrupt-map-mask = <0 0 0 0>;
+		interrupt-map = <0 0 0 0 &mpic 99>;
+		marvell,pcie-port = <2>;
+		marvell,pcie-lane = <0>;
+		clocks = <&gateclk 26>;
+		status = "disabled";
+	};
+
+	pcie at 10,0 {
+		device_type = "pci";
+		assigned-addresses = <0x82005000 0 0xd0082000 0 0x2000>;
+		reg = <0x5000 0 0 0 0>;
+		#address-cells = <3>;
+		#size-cells = <2>;
+		#interrupt-cells = <1>;
+		ranges;
+		interrupt-map-mask = <0 0 0 0>;
+		interrupt-map = <0 0 0 0 &mpic 103>;
+		marvell,pcie-port = <3>;
+		marvell,pcie-lane = <0>;
+		clocks = <&gateclk 27>;
+		status = "disabled";
+	};
+};
diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index cc3a1af..6918fbc 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -1,4 +1,8 @@
 menu "PCI host controller drivers"
 	depends on PCI
 
+config PCI_MVEBU
+	bool "Marvell EBU PCIe controller"
+	depends on ARCH_MVEBU
+
 endmenu
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index 636bc1a..5ea2d8b 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -1 +1 @@
-# intentionally empty
+obj-$(CONFIG_PCI_MVEBU) += pci-mvebu.o
diff --git a/drivers/pci/host/pci-mvebu.c b/drivers/pci/host/pci-mvebu.c
new file mode 100644
index 0000000..9c15a25
--- /dev/null
+++ b/drivers/pci/host/pci-mvebu.c
@@ -0,0 +1,879 @@
+/*
+ * PCIe driver for Marvell Armada 370 and Armada XP SoCs
+ *
+ * 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/kernel.h>
+#include <linux/pci.h>
+#include <linux/clk.h>
+#include <linux/module.h>
+#include <linux/mbus.h>
+#include <linux/slab.h>
+#include <linux/platform_device.h>
+#include <linux/of_address.h>
+#include <linux/of_pci.h>
+#include <linux/of_irq.h>
+#include <linux/of_platform.h>
+
+/*
+ * PCIe unit register offsets.
+ */
+#define PCIE_DEV_ID_OFF		0x0000
+#define PCIE_CMD_OFF		0x0004
+#define PCIE_DEV_REV_OFF	0x0008
+#define PCIE_BAR_LO_OFF(n)	(0x0010 + ((n) << 3))
+#define PCIE_BAR_HI_OFF(n)	(0x0014 + ((n) << 3))
+#define PCIE_HEADER_LOG_4_OFF	0x0128
+#define PCIE_BAR_CTRL_OFF(n)	(0x1804 + (((n) - 1) * 4))
+#define PCIE_WIN04_CTRL_OFF(n)	(0x1820 + ((n) << 4))
+#define PCIE_WIN04_BASE_OFF(n)	(0x1824 + ((n) << 4))
+#define PCIE_WIN04_REMAP_OFF(n)	(0x182c + ((n) << 4))
+#define PCIE_WIN5_CTRL_OFF	0x1880
+#define PCIE_WIN5_BASE_OFF	0x1884
+#define PCIE_WIN5_REMAP_OFF	0x188c
+#define PCIE_CONF_ADDR_OFF	0x18f8
+#define  PCIE_CONF_ADDR_EN		0x80000000
+#define  PCIE_CONF_REG(r)		((((r) & 0xf00) << 16) | ((r) & 0xfc))
+#define  PCIE_CONF_BUS(b)		(((b) & 0xff) << 16)
+#define  PCIE_CONF_DEV(d)		(((d) & 0x1f) << 11)
+#define  PCIE_CONF_FUNC(f)		(((f) & 0x7) << 8)
+#define  PCIE_CONF_ADDR(bus, devfn, where) \
+	(PCIE_CONF_BUS(bus) | PCIE_CONF_DEV(PCI_SLOT(devfn))    | \
+	 PCIE_CONF_FUNC(PCI_FUNC(devfn)) | PCIE_CONF_REG(where) | \
+	 PCIE_CONF_ADDR_EN)
+#define PCIE_CONF_DATA_OFF	0x18fc
+#define PCIE_MASK_OFF		0x1910
+#define  PCIE_MASK_ENABLE_INTS          0x0f000000
+#define PCIE_CTRL_OFF		0x1a00
+#define  PCIE_CTRL_X1_MODE		0x0001
+#define PCIE_STAT_OFF		0x1a04
+#define  PCIE_STAT_BUS                  0xff00
+#define  PCIE_STAT_LINK_DOWN		BIT(1)
+#define PCIE_DEBUG_CTRL         0x1a60
+#define  PCIE_DEBUG_SOFT_RESET		BIT(20)
+
+/*
+ * This product ID is registered by Marvell, and used when the Marvell
+ * SoC is not the root complex, but an endpoint on the PCIe bus. It is
+ * therefore safe to re-use this PCI ID for our emulated PCI-to-PCI
+ * bridge.
+ */
+#define MARVELL_EMULATED_PCI_PCI_BRIDGE_ID 0x7846
+
+/* PCI configuration space of a PCI-to-PCI bridge */
+struct mvebu_sw_pci_bridge {
+	u16 vendor;
+	u16 device;
+	u16 command;
+	u16 status;
+	u16 class;
+	u8 interface;
+	u8 revision;
+	u8 bist;
+	u8 header_type;
+	u8 latency_timer;
+	u8 cache_line_size;
+	u32 bar[2];
+	u8 primary_bus;
+	u8 secondary_bus;
+	u8 subordinate_bus;
+	u8 secondary_latency_timer;
+	u8 iobase;
+	u8 iolimit;
+	u16 secondary_status;
+	u16 membase;
+	u16 memlimit;
+	u16 prefmembase;
+	u16 prefmemlimit;
+	u32 prefbaseupper;
+	u32 preflimitupper;
+	u16 iobaseupper;
+	u16 iolimitupper;
+	u8 cappointer;
+	u8 reserved1;
+	u16 reserved2;
+	u32 romaddr;
+	u8 intline;
+	u8 intpin;
+	u16 bridgectrl;
+};
+
+struct mvebu_pcie_port;
+
+/* Structure representing all PCIe interfaces */
+struct mvebu_pcie {
+	struct platform_device *pdev;
+	struct mvebu_pcie_port *ports;
+	struct resource io;
+	struct resource realio;
+	struct resource mem;
+	struct resource busn;
+	int nports;
+};
+
+/* Structure representing one PCIe interface */
+struct mvebu_pcie_port {
+	char *name;
+	void __iomem *base;
+	spinlock_t conf_lock;
+	int haslink;
+	u32 port;
+	u32 lane;
+	int devfn;
+	struct clk *clk;
+	struct mvebu_sw_pci_bridge bridge;
+	struct device_node *dn;
+	struct mvebu_pcie *pcie;
+	phys_addr_t memwin_base;
+	size_t memwin_size;
+	phys_addr_t iowin_base;
+	size_t iowin_size;
+};
+
+static bool mvebu_pcie_link_up(struct mvebu_pcie_port *port)
+{
+	return !(readl(port->base + PCIE_STAT_OFF) & PCIE_STAT_LINK_DOWN);
+}
+
+static void mvebu_pcie_set_local_bus_nr(struct mvebu_pcie_port *port, int nr)
+{
+	u32 stat;
+
+	stat = readl(port->base + PCIE_STAT_OFF);
+	stat &= ~PCIE_STAT_BUS;
+	stat |= nr << 8;
+	writel(stat, port->base + PCIE_STAT_OFF);
+}
+
+/*
+ * Setup PCIE BARs and Address Decode Wins:
+ * BAR[0,2] -> disabled, BAR[1] -> covers all DRAM banks
+ * WIN[0-3] -> DRAM bank[0-3]
+ */
+static void __init mvebu_pcie_setup_wins(struct mvebu_pcie_port *port)
+{
+	const struct mbus_dram_target_info *dram;
+	u32 size;
+	int i;
+
+	dram = mv_mbus_dram_info();
+
+	/* First, disable and clear BARs and windows. */
+	for (i = 1; i < 3; i++) {
+		writel(0, port->base + PCIE_BAR_CTRL_OFF(i));
+		writel(0, port->base + PCIE_BAR_LO_OFF(i));
+		writel(0, port->base + PCIE_BAR_HI_OFF(i));
+	}
+
+	for (i = 0; i < 5; i++) {
+		writel(0, port->base + PCIE_WIN04_CTRL_OFF(i));
+		writel(0, port->base + PCIE_WIN04_BASE_OFF(i));
+		writel(0, port->base + PCIE_WIN04_REMAP_OFF(i));
+	}
+
+	writel(0, port->base + PCIE_WIN5_CTRL_OFF);
+	writel(0, port->base + PCIE_WIN5_BASE_OFF);
+	writel(0, port->base + PCIE_WIN5_REMAP_OFF);
+
+	/* Setup windows for DDR banks.  Count total DDR size on the fly. */
+	size = 0;
+	for (i = 0; i < dram->num_cs; i++) {
+		const struct mbus_dram_window *cs = dram->cs + i;
+
+		writel(cs->base & 0xffff0000,
+		       port->base + PCIE_WIN04_BASE_OFF(i));
+		writel(0, port->base + PCIE_WIN04_REMAP_OFF(i));
+		writel(((cs->size - 1) & 0xffff0000) |
+			(cs->mbus_attr << 8) |
+			(dram->mbus_dram_target_id << 4) | 1,
+		       port->base + PCIE_WIN04_CTRL_OFF(i));
+
+		size += cs->size;
+	}
+
+	/* Round up 'size' to the nearest power of two. */
+	if ((size & (size - 1)) != 0)
+		size = 1 << fls(size);
+
+	/* Setup BAR[1] to all DRAM banks. */
+	writel(dram->cs[0].base, port->base + PCIE_BAR_LO_OFF(1));
+	writel(0, port->base + PCIE_BAR_HI_OFF(1));
+	writel(((size - 1) & 0xffff0000) | 1,
+	       port->base + PCIE_BAR_CTRL_OFF(1));
+}
+
+static void __init mvebu_pcie_setup_hw(struct mvebu_pcie_port *port)
+{
+	u16 cmd;
+	u32 mask;
+
+	/* Point PCIe unit MBUS decode windows to DRAM space. */
+	mvebu_pcie_setup_wins(port);
+
+	/* Master + slave enable. */
+	cmd = readw(port->base + PCIE_CMD_OFF);
+	cmd |= PCI_COMMAND_IO;
+	cmd |= PCI_COMMAND_MEMORY;
+	cmd |= PCI_COMMAND_MASTER;
+	writew(cmd, port->base + PCIE_CMD_OFF);
+
+	/* Enable interrupt lines A-D. */
+	mask = readl(port->base + PCIE_MASK_OFF);
+	mask |= PCIE_MASK_ENABLE_INTS;
+	writel(mask, port->base + PCIE_MASK_OFF);
+}
+
+static int mvebu_pcie_hw_rd_conf(struct mvebu_pcie_port *port,
+				 struct pci_bus *bus,
+				 u32 devfn, int where, int size, u32 *val)
+{
+	writel(PCIE_CONF_ADDR(bus->number, devfn, where),
+	       port->base + PCIE_CONF_ADDR_OFF);
+
+	*val = readl(port->base + PCIE_CONF_DATA_OFF);
+
+	if (size == 1)
+		*val = (*val >> (8 * (where & 3))) & 0xff;
+	else if (size == 2)
+		*val = (*val >> (8 * (where & 3))) & 0xffff;
+
+	return PCIBIOS_SUCCESSFUL;
+}
+
+static int mvebu_pcie_hw_wr_conf(struct mvebu_pcie_port *port,
+				 struct pci_bus *bus,
+				 u32 devfn, int where, int size, u32 val)
+{
+	int ret = PCIBIOS_SUCCESSFUL;
+
+	writel(PCIE_CONF_ADDR(bus->number, devfn, where),
+	       port->base + PCIE_CONF_ADDR_OFF);
+
+	if (size == 4)
+		writel(val, port->base + PCIE_CONF_DATA_OFF);
+	else if (size == 2)
+		writew(val, port->base + PCIE_CONF_DATA_OFF + (where & 3));
+	else if (size == 1)
+		writeb(val, port->base + PCIE_CONF_DATA_OFF + (where & 3));
+	else
+		ret = PCIBIOS_BAD_REGISTER_NUMBER;
+
+	return ret;
+}
+
+static void mvebu_pcie_handle_iobase_change(struct mvebu_pcie_port *port)
+{
+	phys_addr_t iobase;
+
+	/* Are the new iobase/iolimit values invalid? */
+	if (port->bridge.iolimit < port->bridge.iobase ||
+	    port->bridge.iolimitupper < port->bridge.iobaseupper) {
+
+		/* If a window was configured, remove it */
+		if (port->iowin_base) {
+			mvebu_mbus_del_window(port->iowin_base,
+					      port->iowin_size);
+			port->iowin_base = 0;
+			port->iowin_size = 0;
+		}
+
+		return;
+	}
+
+	/*
+	 * We read the PCI-to-PCI bridge emulated registers, and
+	 * calculate the base address and size of the address decoding
+	 * window to setup, according to the PCI-to-PCI bridge
+	 * specifications. iobase is the bus address, port->iowin_base
+	 * is the CPU address.
+	 */
+	iobase = ((port->bridge.iobase & 0xF0) << 8) |
+		(port->bridge.iobaseupper << 16);
+	port->iowin_base = port->pcie->io.start + iobase;
+	port->iowin_size = ((0xFFF | ((port->bridge.iolimit & 0xF0) << 8) |
+			    (port->bridge.iolimitupper << 16)) -
+			    iobase);
+
+	mvebu_mbus_add_window_remap_flags(port->name, port->iowin_base,
+					  port->iowin_size,
+					  iobase,
+					  MVEBU_MBUS_PCI_IO);
+
+	pci_ioremap_io(iobase, port->iowin_base);
+}
+
+static void mvebu_pcie_handle_membase_change(struct mvebu_pcie_port *port)
+{
+	/* Are the new membase/memlimit values invalid? */
+	if (port->bridge.memlimit < port->bridge.membase) {
+
+		/* If a window was configured, remove it */
+		if (port->memwin_base) {
+			mvebu_mbus_del_window(port->memwin_base,
+					      port->memwin_size);
+			port->memwin_base = 0;
+			port->memwin_size = 0;
+		}
+
+		return;
+	}
+
+	/*
+	 * We read the PCI-to-PCI bridge emulated registers, and
+	 * calculate the base address and size of the address decoding
+	 * window to setup, according to the PCI-to-PCI bridge
+	 * specifications.
+	 */
+	port->memwin_base  = ((port->bridge.membase & 0xFFF0) << 16);
+	port->memwin_size  =
+		(((port->bridge.memlimit & 0xFFF0) << 16) | 0xFFFFF) -
+		port->memwin_base;
+
+	mvebu_mbus_add_window_remap_flags(port->name, port->memwin_base,
+					  port->memwin_size,
+					  MVEBU_MBUS_NO_REMAP,
+					  MVEBU_MBUS_PCI_MEM);
+}
+
+/*
+ * Initialize the configuration space of the PCI-to-PCI bridge
+ * associated with the given PCIe interface.
+ */
+static void mvebu_sw_pci_bridge_init(struct mvebu_pcie_port *port)
+{
+	struct mvebu_sw_pci_bridge *bridge = &port->bridge;
+
+	memset(bridge, 0, sizeof(struct mvebu_sw_pci_bridge));
+
+	bridge->status = PCI_STATUS_CAP_LIST;
+	bridge->class = PCI_CLASS_BRIDGE_PCI;
+	bridge->vendor = PCI_VENDOR_ID_MARVELL;
+	bridge->device = MARVELL_EMULATED_PCI_PCI_BRIDGE_ID;
+	bridge->header_type = PCI_HEADER_TYPE_BRIDGE;
+	bridge->cache_line_size = 0x10;
+
+	/* We support 32 bits I/O addressing */
+	bridge->iobase = PCI_IO_RANGE_TYPE_32;
+	bridge->iolimit = PCI_IO_RANGE_TYPE_32;
+}
+
+/*
+ * Read the configuration space of the PCI-to-PCI bridge associated to
+ * the given PCIe interface.
+ */
+static int mvebu_sw_pci_bridge_read(struct mvebu_pcie_port *port,
+				  unsigned int where, int size, u32 *value)
+{
+	struct mvebu_sw_pci_bridge *bridge = &port->bridge;
+
+	switch (where & ~3) {
+	case PCI_VENDOR_ID:
+		*value = bridge->device << 16 | bridge->vendor;
+		break;
+
+	case PCI_COMMAND:
+		*value = bridge->status << 16 | bridge->command;
+		break;
+
+	case PCI_CLASS_REVISION:
+		*value = bridge->class << 16 | bridge->interface << 8 |
+			 bridge->revision;
+		break;
+
+	case PCI_CACHE_LINE_SIZE:
+		*value = bridge->bist << 24 | bridge->header_type << 16 |
+			 bridge->latency_timer << 8 | bridge->cache_line_size;
+		break;
+
+	case PCI_BASE_ADDRESS_0 ... PCI_BASE_ADDRESS_1:
+		*value = bridge->bar[((where & ~3) - PCI_BASE_ADDRESS_0) / 4];
+		break;
+
+	case PCI_PRIMARY_BUS:
+		*value = (bridge->secondary_latency_timer << 24 |
+			  bridge->subordinate_bus         << 16 |
+			  bridge->secondary_bus           <<  8 |
+			  bridge->primary_bus);
+		break;
+
+	case PCI_IO_BASE:
+		*value = (bridge->secondary_status << 16 |
+			  bridge->iolimit          <<  8 |
+			  bridge->iobase);
+		break;
+
+	case PCI_MEMORY_BASE:
+		*value = (bridge->memlimit << 16 | bridge->membase);
+		break;
+
+	case PCI_PREF_MEMORY_BASE:
+		*value = (bridge->prefmemlimit << 16 | bridge->prefmembase);
+		break;
+
+	case PCI_PREF_BASE_UPPER32:
+		*value = bridge->prefbaseupper;
+		break;
+
+	case PCI_PREF_LIMIT_UPPER32:
+		*value = bridge->preflimitupper;
+		break;
+
+	case PCI_IO_BASE_UPPER16:
+		*value = (bridge->iolimitupper << 16 | bridge->iobaseupper);
+		break;
+
+	case PCI_ROM_ADDRESS1:
+		*value = 0;
+		break;
+
+	default:
+		*value = 0xffffffff;
+		return PCIBIOS_BAD_REGISTER_NUMBER;
+	}
+
+	if (size == 2)
+		*value = (*value >> (8 * (where & 3))) & 0xffff;
+	else if (size == 1)
+		*value = (*value >> (8 * (where & 3))) & 0xff;
+
+	return PCIBIOS_SUCCESSFUL;
+}
+
+/* Write to the PCI-to-PCI bridge configuration space */
+static int mvebu_sw_pci_bridge_write(struct mvebu_pcie_port *port,
+				     unsigned int where, int size, u32 value)
+{
+	struct mvebu_sw_pci_bridge *bridge = &port->bridge;
+	u32 mask, reg;
+	int err;
+
+	if (size == 4)
+		mask = 0x0;
+	else if (size == 2)
+		mask = ~(0xffff << ((where & 3) * 8));
+	else if (size == 1)
+		mask = ~(0xff << ((where & 3) * 8));
+	else
+		return PCIBIOS_BAD_REGISTER_NUMBER;
+
+	err = mvebu_sw_pci_bridge_read(port, where & ~3, 4, &reg);
+	if (err)
+		return err;
+
+	value = (reg & mask) | value << ((where & 3) * 8);
+
+	switch (where & ~3) {
+	case PCI_COMMAND:
+		bridge->command = value & 0xffff;
+		bridge->status = value >> 16;
+		break;
+
+	case PCI_BASE_ADDRESS_0 ... PCI_BASE_ADDRESS_1:
+		bridge->bar[((where & ~3) - PCI_BASE_ADDRESS_0) / 4] = value;
+		break;
+
+	case PCI_IO_BASE:
+		/*
+		 * We also keep bit 1 set, it is a read-only bit that
+		 * indicates we support 32 bits addressing for the
+		 * I/O
+		 */
+		bridge->iobase = (value & 0xff) | PCI_IO_RANGE_TYPE_32;
+		bridge->iolimit = ((value >> 8) & 0xff) | PCI_IO_RANGE_TYPE_32;
+		bridge->secondary_status = value >> 16;
+		mvebu_pcie_handle_iobase_change(port);
+		break;
+
+	case PCI_MEMORY_BASE:
+		bridge->membase = value & 0xffff;
+		bridge->memlimit = value >> 16;
+		mvebu_pcie_handle_membase_change(port);
+		break;
+
+	case PCI_PREF_MEMORY_BASE:
+		bridge->prefmembase = value & 0xffff;
+		bridge->prefmemlimit = value >> 16;
+		break;
+
+	case PCI_PREF_BASE_UPPER32:
+		bridge->prefbaseupper = value;
+		break;
+
+	case PCI_PREF_LIMIT_UPPER32:
+		bridge->preflimitupper = value;
+		break;
+
+	case PCI_IO_BASE_UPPER16:
+		bridge->iobaseupper = value & 0xffff;
+		bridge->iolimitupper = value >> 16;
+		mvebu_pcie_handle_iobase_change(port);
+		break;
+
+	case PCI_PRIMARY_BUS:
+		bridge->primary_bus             = value & 0xff;
+		bridge->secondary_bus           = (value >> 8) & 0xff;
+		bridge->subordinate_bus         = (value >> 16) & 0xff;
+		bridge->secondary_latency_timer = (value >> 24) & 0xff;
+		mvebu_pcie_set_local_bus_nr(port, bridge->secondary_bus);
+		break;
+
+	default:
+		break;
+	}
+
+	return PCIBIOS_SUCCESSFUL;
+}
+
+static inline struct mvebu_pcie *sys_to_pcie(struct pci_sys_data *sys)
+{
+	return sys->private_data;
+}
+
+static struct mvebu_pcie_port *
+mvebu_pcie_find_port(struct mvebu_pcie *pcie, struct pci_bus *bus,
+		     int devfn)
+{
+	int i;
+
+	for (i = 0; i < pcie->nports; i++) {
+		struct mvebu_pcie_port *port = &pcie->ports[i];
+		if (bus->number == 0 && port->devfn == devfn)
+			return port;
+		if (bus->number != 0 &&
+		    port->bridge.secondary_bus == bus->number)
+			return port;
+	}
+
+	return NULL;
+}
+
+/* PCI configuration space write function */
+static int mvebu_pcie_wr_conf(struct pci_bus *bus, u32 devfn,
+			      int where, int size, u32 val)
+{
+	struct mvebu_pcie *pcie = sys_to_pcie(bus->sysdata);
+	struct mvebu_pcie_port *port;
+	unsigned long flags;
+	int ret;
+
+	port = mvebu_pcie_find_port(pcie, bus, devfn);
+	if (!port)
+		return PCIBIOS_DEVICE_NOT_FOUND;
+
+	/* Access the emulated PCI-to-PCI bridge */
+	if (bus->number == 0)
+		return mvebu_sw_pci_bridge_write(port, where, size, val);
+
+	if (!port->haslink || PCI_SLOT(devfn) != 0)
+		return PCIBIOS_DEVICE_NOT_FOUND;
+
+	/* Access the real PCIe interface */
+	spin_lock_irqsave(&port->conf_lock, flags);
+	ret = mvebu_pcie_hw_wr_conf(port, bus,
+				    PCI_DEVFN(1, PCI_FUNC(devfn)),
+				    where, size, val);
+	spin_unlock_irqrestore(&port->conf_lock, flags);
+
+	return ret;
+}
+
+/* PCI configuration space read function */
+static int mvebu_pcie_rd_conf(struct pci_bus *bus, u32 devfn, int where,
+			      int size, u32 *val)
+{
+	struct mvebu_pcie *pcie = sys_to_pcie(bus->sysdata);
+	struct mvebu_pcie_port *port;
+	unsigned long flags;
+	int ret;
+
+	port = mvebu_pcie_find_port(pcie, bus, devfn);
+	if (!port) {
+		*val = 0xffffffff;
+		return PCIBIOS_DEVICE_NOT_FOUND;
+	}
+
+	/* Access the emulated PCI-to-PCI bridge */
+	if (bus->number == 0)
+		return mvebu_sw_pci_bridge_read(port, where, size, val);
+
+	if (!port->haslink || PCI_SLOT(devfn) != 0) {
+		*val = 0xffffffff;
+		return PCIBIOS_DEVICE_NOT_FOUND;
+	}
+
+	/* Access the real PCIe interface */
+	spin_lock_irqsave(&port->conf_lock, flags);
+	ret = mvebu_pcie_hw_rd_conf(port, bus,
+				    PCI_DEVFN(1, PCI_FUNC(devfn)),
+				    where, size, val);
+	spin_unlock_irqrestore(&port->conf_lock, flags);
+
+	return ret;
+}
+
+static struct pci_ops mvebu_pcie_ops = {
+	.read = mvebu_pcie_rd_conf,
+	.write = mvebu_pcie_wr_conf,
+};
+
+static int __init mvebu_pcie_setup(int nr, struct pci_sys_data *sys)
+{
+	struct mvebu_pcie *pcie = sys_to_pcie(sys);
+	int i;
+
+	pci_add_resource_offset(&sys->resources, &pcie->realio, sys->io_offset);
+	pci_add_resource_offset(&sys->resources, &pcie->mem, sys->mem_offset);
+	pci_add_resource(&sys->resources, &pcie->busn);
+
+	for (i = 0; i < pcie->nports; i++) {
+		struct mvebu_pcie_port *port = &pcie->ports[i];
+		mvebu_pcie_setup_hw(port);
+	}
+
+	return 1;
+}
+
+static int __init mvebu_pcie_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
+{
+	struct of_irq oirq;
+	int ret;
+
+	ret = of_irq_map_pci(dev, &oirq);
+	if (ret)
+		return ret;
+
+	return irq_create_of_mapping(oirq.controller, oirq.specifier,
+				     oirq.size);
+}
+
+static struct pci_bus *mvebu_pcie_scan_bus(int nr, struct pci_sys_data *sys)
+{
+	struct mvebu_pcie *pcie = sys_to_pcie(sys);
+	struct pci_bus *bus;
+
+	bus = pci_create_root_bus(&pcie->pdev->dev, sys->busnr,
+				  &mvebu_pcie_ops, sys, &sys->resources);
+	if (!bus)
+		return NULL;
+
+	pci_scan_child_bus(bus);
+
+	return bus;
+}
+
+resource_size_t mvebu_pcie_align_resource(struct pci_dev *dev,
+					  const struct resource *res,
+					  resource_size_t start,
+					  resource_size_t size,
+					  resource_size_t align)
+{
+	if (dev->bus->number != 0)
+		return start;
+
+	/*
+	 * On the PCI-to-PCI bridge side, the I/O windows must have at
+	 * least a 64 KB size and be aligned on their size, and the
+	 * memory windows must have at least a 1 MB size and be
+	 * aligned on their size
+	 */
+	if (res->flags & IORESOURCE_IO)
+		return round_up(start, max((resource_size_t)SZ_64K, size));
+	else if (res->flags & IORESOURCE_MEM)
+		return round_up(start, max((resource_size_t)SZ_1M, size));
+	else
+		return start;
+}
+
+static void mvebu_pcie_enable(struct mvebu_pcie *pcie)
+{
+	struct hw_pci hw;
+
+	memset(&hw, 0, sizeof(hw));
+
+	hw.nr_controllers = 1;
+	hw.private_data   = (void **)&pcie;
+	hw.setup          = mvebu_pcie_setup;
+	hw.scan           = mvebu_pcie_scan_bus;
+	hw.map_irq        = mvebu_pcie_map_irq;
+	hw.ops            = &mvebu_pcie_ops;
+	hw.align_resource = mvebu_pcie_align_resource;
+
+	pci_common_init(&hw);
+}
+
+/*
+ * Looks up the list of register addresses encoded into the reg =
+ * <...> property for one that matches the given port/lane. Once
+ * found, maps it.
+ */
+static void __iomem *mvebu_pcie_map_registers(struct platform_device *pdev,
+					      struct device_node *np,
+					      struct mvebu_pcie_port *port)
+{
+	struct resource regs;
+	int ret = 0;
+
+	ret = of_address_to_resource(np, 0, &regs);
+	if (ret)
+		return NULL;
+
+	return devm_request_and_ioremap(&pdev->dev, &regs);
+}
+
+static int __init mvebu_pcie_probe(struct platform_device *pdev)
+{
+	struct mvebu_pcie *pcie;
+	struct device_node *np = pdev->dev.of_node;
+	struct of_pci_range range;
+	struct of_pci_range_parser parser;
+	struct device_node *child;
+	int i, ret;
+
+	pcie = devm_kzalloc(&pdev->dev, sizeof(struct mvebu_pcie),
+			    GFP_KERNEL);
+	if (!pcie)
+		return -ENOMEM;
+
+	pcie->pdev = pdev;
+
+	if (of_pci_range_parser(&parser, np))
+		return -EINVAL;
+
+	/* Get the I/O and memory ranges from DT */
+	for_each_of_pci_range(&parser, &range) {
+		unsigned long restype = range.flags & IORESOURCE_TYPE_BITS;
+		if (restype == IORESOURCE_IO) {
+			of_pci_range_to_resource(&range, np, &pcie->io);
+			of_pci_range_to_resource(&range, np, &pcie->realio);
+			pcie->io.name = "I/O";
+			pcie->realio.start = max_t(resource_size_t,
+						   PCIBIOS_MIN_IO,
+						   range.pci_addr);
+			pcie->realio.end = min_t(resource_size_t,
+						 IO_SPACE_LIMIT,
+						 range.pci_addr + range.size);
+		}
+		if (restype == IORESOURCE_MEM) {
+			of_pci_range_to_resource(&range, np, &pcie->mem);
+			pcie->mem.name = "MEM";
+		}
+	}
+
+	/* Get the bus range */
+	ret = of_pci_parse_bus_range(np, &pcie->busn);
+	if (ret) {
+		dev_err(&pdev->dev, "failed to parse bus-range property: %d\n",
+			ret);
+		return ret;
+	}
+
+	for_each_child_of_node(pdev->dev.of_node, child) {
+		if (!of_device_is_available(child))
+			continue;
+		pcie->nports++;
+	}
+
+	pcie->ports = devm_kzalloc(&pdev->dev, pcie->nports *
+				   sizeof(struct mvebu_pcie_port),
+				   GFP_KERNEL);
+	if (!pcie->ports)
+		return -ENOMEM;
+
+	i = 0;
+	for_each_child_of_node(pdev->dev.of_node, child) {
+		struct mvebu_pcie_port *port = &pcie->ports[i];
+
+		if (!of_device_is_available(child))
+			continue;
+
+		port->pcie = pcie;
+
+		if (of_property_read_u32(child, "marvell,pcie-port",
+					 &port->port)) {
+			dev_warn(&pdev->dev,
+				 "ignoring PCIe DT node, missing pcie-port property\n");
+			continue;
+		}
+
+		if (of_property_read_u32(child, "marvell,pcie-lane",
+					 &port->lane))
+			port->lane = 0;
+
+		port->name = kasprintf(GFP_KERNEL, "pcie%d.%d",
+				       port->port, port->lane);
+
+		port->devfn = of_pci_get_devfn(child);
+		if (port->devfn < 0)
+			continue;
+
+		port->base = mvebu_pcie_map_registers(pdev, child, port);
+		if (!port->base) {
+			dev_err(&pdev->dev, "PCIe%d.%d: cannot map registers\n",
+				port->port, port->lane);
+			continue;
+		}
+
+		if (mvebu_pcie_link_up(port)) {
+			port->haslink = 1;
+			dev_info(&pdev->dev, "PCIe%d.%d: link up\n",
+				 port->port, port->lane);
+		} else {
+			port->haslink = 0;
+			dev_info(&pdev->dev, "PCIe%d.%d: link down\n",
+				 port->port, port->lane);
+		}
+
+		port->clk = of_clk_get_by_name(child, NULL);
+		if (!port->clk) {
+			dev_err(&pdev->dev, "PCIe%d.%d: cannot get clock\n",
+			       port->port, port->lane);
+			iounmap(port->base);
+			port->haslink = 0;
+			continue;
+		}
+
+		port->dn = child;
+
+		clk_prepare_enable(port->clk);
+		spin_lock_init(&port->conf_lock);
+
+		mvebu_sw_pci_bridge_init(port);
+
+		i++;
+	}
+
+	mvebu_pcie_enable(pcie);
+
+	return 0;
+}
+
+static const struct of_device_id mvebu_pcie_of_match_table[] = {
+	{ .compatible = "marvell,armada-xp-pcie", },
+	{ .compatible = "marvell,armada-370-pcie", },
+	{},
+};
+MODULE_DEVICE_TABLE(of, mvebu_pcie_of_match_table);
+
+static struct platform_driver mvebu_pcie_driver = {
+	.driver = {
+		.owner = THIS_MODULE,
+		.name = "mvebu-pcie",
+		.of_match_table =
+		   of_match_ptr(mvebu_pcie_of_match_table),
+	},
+};
+
+static int mvebu_pcie_init(void)
+{
+	return platform_driver_probe(&mvebu_pcie_driver,
+				     mvebu_pcie_probe);
+}
+
+subsys_initcall(mvebu_pcie_init);
+
+MODULE_AUTHOR("Thomas Petazzoni <thomas.petazzoni at free-electrons.com>");
+MODULE_DESCRIPTION("Marvell EBU PCIe driver");
+MODULE_LICENSE("GPLv2");
-- 
1.7.9.5



From arnd at arndb.de  Tue Apr  9 17:10:01 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 9 Apr 2013 23:10:01 +0200
Subject: [GIT PULL v2 10/10] devel-samsung for v3.10
In-Reply-To: <51643425.3070108@samsung.com>
References: <51643425.3070108@samsung.com>
Message-ID: <201304092310.01474.arnd@arndb.de>

On Tuesday 09 April 2013, Kukjin Kim wrote:
> Note, this is re-sending because of missed including fixes in previous 
> pull-request [10/10]. Thanks.
> 
> - Kukjin
> 
> The following changes since commit 6dbe51c251a327e012439c4772097a13df43c5b8:
> 
>    Linux 3.9-rc1 (2013-03-03 15:11:05 -0800)
> 
> are available in the git repository at:
> 
>    git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git 
> tags/devel-samsung-for-v3.10
> 

Pulled into next/soc now, thanks!

	Arnd


From jack at suse.cz  Tue Apr  9 17:11:28 2013
From: jack at suse.cz (Jan Kara)
Date: Tue, 9 Apr 2013 23:11:28 +0200
Subject: [PATCH v3] [RESEND] mm: Make snapshotting pages for stable
 writes a per-bio operation
In-Reply-To: <20130409140432.cd69f999302a02caf73788fc@linux-foundation.org>
References: <20130409180617.GB8907@blackbox.djwong.org>
 <20130409140432.cd69f999302a02caf73788fc@linux-foundation.org>
Message-ID: <20130409211128.GD15214@quack.suse.cz>

On Tue 09-04-13 14:04:32, Andrew Morton wrote:
> On Tue, 9 Apr 2013 11:06:17 -0700 "Darrick J. Wong" <darrick.wong at oracle.com> wrote:
> 
> > +		 * Here we write back pagecache data that may be mmaped. Since
> > +		 * we cannot afford to clean the page and set PageWriteback
> > +		 * here due to lock ordering (page lock ranks above transaction
> > +		 * start), the data can change while IO is in flight. Tell the
> > +		 * block layer it should bounce the bio pages if stable data
> > +		 * during write is required.
> 
> I think there are already ab/ba deadlocks between lock_page() and
> journal_start().  iirc one path was write(), I forget which was the
> other path.  This was 10+ years ago and nobody else noticed and I
> didn't know how to fix it so I didn't tell anyone ;)
  Hum, I don't think they are there anymore ;)

> It would be neat to be able to hook things like journal_start() into
> lockdep but I don't think that lockdep has easy provision for wiring
> oddball things into its mechanisms.
  Actually if you look at fs/jbd/transaction.c:start_this_handle(), you
will notice that it is wired into lockdep (the lock_map_acquire() call
there). And it works since I've seen quite some reports from it ;)

								Honza
-- 
Jan Kara <jack at suse.cz>
SUSE Labs, CR


From bhelgaas at google.com  Tue Apr  9 17:12:58 2013
From: bhelgaas at google.com (Bjorn Helgaas)
Date: Tue, 9 Apr 2013 15:12:58 -0600
Subject: [PATCHv8 10/19] pci: PCIe driver for Marvell Armada 370/XP systems
In-Reply-To: <1365541601-14095-11-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1365541601-14095-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1365541601-14095-11-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <CAErSpo4FJVoUxQS6ti0-kUXCuK4HnAxWd_5aYi4NyVykcCABng@mail.gmail.com>

On Tue, Apr 9, 2013 at 3:06 PM, Thomas Petazzoni
<thomas.petazzoni at free-electrons.com> wrote:
> This driver implements the support for the PCIe interfaces on the
> Marvell Armada 370/XP ARM SoCs. In the future, it might be extended to
> cover earlier families of Marvell SoCs, such as Dove, Orion and
> Kirkwood.
>
> The driver implements the hw_pci operations needed by the core ARM PCI
> code to setup PCI devices and get their corresponding IRQs, and the
> pci_ops operations that are used by the PCI core to read/write the
> configuration space of PCI devices.
>
> Since the PCIe interfaces of Marvell SoCs are completely separate and
> not linked together in a bus, this driver sets up an emulated PCI host
> bridge, with one PCI-to-PCI bridge as child for each hardware PCIe
> interface.
>
> In addition, this driver enumerates the different PCIe slots, and for
> those having a device plugged in, it sets up the necessary address
> decoding windows, using the new armada_370_xp_alloc_pcie_window()
> function from mach-mvebu/addr-map.c.
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> Acked-by: Bjorn Helgaas <bhelgaas at google.com>

This and 06/19 look good to me.

> ---
>  .../devicetree/bindings/pci/mvebu-pci.txt          |  220 +++++
>  drivers/pci/host/Kconfig                           |    4 +
>  drivers/pci/host/Makefile                          |    2 +-
>  drivers/pci/host/pci-mvebu.c                       |  879 ++++++++++++++++++++
>  4 files changed, 1104 insertions(+), 1 deletion(-)
>  create mode 100644 Documentation/devicetree/bindings/pci/mvebu-pci.txt
>  create mode 100644 drivers/pci/host/pci-mvebu.c
>
> diff --git a/Documentation/devicetree/bindings/pci/mvebu-pci.txt b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
> new file mode 100644
> index 0000000..eb69d92
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
> @@ -0,0 +1,220 @@
> +* Marvell EBU PCIe interfaces
> +
> +Mandatory properties:
> +- compatible: one of the following values:
> +    marvell,armada-370-pcie
> +    marvell,armada-xp-pcie
> +- #address-cells, set to <3>
> +- #size-cells, set to <2>
> +- #interrupt-cells, set to <1>
> +- bus-range: PCI bus numbers covered
> +- device_type, set to "pci"
> +- ranges: ranges for the PCI memory and I/O regions, as well as the
> +  MMIO registers to control the PCIe interfaces.
> +
> +In addition, the Device Tree node must have sub-nodes describing each
> +PCIe interface, having the following mandatory properties:
> +- reg: used only for interrupt mapping, so only the first four bytes
> +  are used to refer to the correct bus number and device number.
> +- assigned-addresses: reference to the MMIO registers used to control
> +  this PCIe interface.
> +- clocks: the clock associated to this PCIe interface
> +- marvell,pcie-port: the physical PCIe port number
> +- status: either "disabled" or "okay"
> +- device_type, set to "pci"
> +- #address-cells, set to <3>
> +- #size-cells, set to <2>
> +- #interrupt-cells, set to <1>
> +- ranges, empty property.
> +- interrupt-map-mask and interrupt-map, standard PCI properties to
> +  define the mapping of the PCIe interface to interrupt numbers.
> +
> +and the following optional properties:
> +- marvell,pcie-lane: the physical PCIe lane number, for ports having
> +  multiple lanes. If this property is not found, we assume that the
> +  value is 0.
> +
> +Example:
> +
> +pcie-controller {
> +       compatible = "marvell,armada-xp-pcie";
> +       status = "disabled";
> +       device_type = "pci";
> +
> +       #address-cells = <3>;
> +       #size-cells = <2>;
> +
> +       bus-range = <0x00 0xff>;
> +
> +       ranges = <0x82000000 0 0xd0040000 0xd0040000 0 0x00002000   /* Port 0.0 registers */
> +                 0x82000000 0 0xd0042000 0xd0042000 0 0x00002000   /* Port 2.0 registers */
> +                 0x82000000 0 0xd0044000 0xd0044000 0 0x00002000   /* Port 0.1 registers */
> +                 0x82000000 0 0xd0048000 0xd0048000 0 0x00002000   /* Port 0.2 registers */
> +                 0x82000000 0 0xd004c000 0xd004c000 0 0x00002000   /* Port 0.3 registers */
> +                 0x82000000 0 0xd0080000 0xd0080000 0 0x00002000   /* Port 1.0 registers */
> +                 0x82000000 0 0xd0082000 0xd0082000 0 0x00002000   /* Port 3.0 registers */
> +                 0x82000000 0 0xd0084000 0xd0084000 0 0x00002000   /* Port 1.1 registers */
> +                 0x82000000 0 0xd0088000 0xd0088000 0 0x00002000   /* Port 1.2 registers */
> +                 0x82000000 0 0xd008c000 0xd008c000 0 0x00002000   /* Port 1.3 registers */
> +                 0x82000000 0 0xe0000000 0xe0000000 0 0x08000000   /* non-prefetchable memory */
> +                 0x81000000 0 0          0xe8000000 0 0x00100000>; /* downstream I/O */
> +
> +       pcie at 1,0 {
> +               device_type = "pci";
> +               assigned-addresses = <0x82000800 0 0xd0040000 0 0x2000>;
> +               reg = <0x0800 0 0 0 0>;
> +               #address-cells = <3>;
> +               #size-cells = <2>;
> +               #interrupt-cells = <1>;
> +               ranges;
> +               interrupt-map-mask = <0 0 0 0>;
> +               interrupt-map = <0 0 0 0 &mpic 58>;
> +               marvell,pcie-port = <0>;
> +               marvell,pcie-lane = <0>;
> +               clocks = <&gateclk 5>;
> +               status = "disabled";
> +       };
> +
> +       pcie at 2,0 {
> +               device_type = "pci";
> +               assigned-addresses = <0x82001000 0 0xd0044000 0 0x2000>;
> +               reg = <0x1000 0 0 0 0>;
> +               #address-cells = <3>;
> +               #size-cells = <2>;
> +               #interrupt-cells = <1>;
> +               ranges;
> +               interrupt-map-mask = <0 0 0 0>;
> +               interrupt-map = <0 0 0 0 &mpic 59>;
> +               marvell,pcie-port = <0>;
> +               marvell,pcie-lane = <1>;
> +               clocks = <&gateclk 6>;
> +               status = "disabled";
> +       };
> +
> +       pcie at 3,0 {
> +               device_type = "pci";
> +               assigned-addresses = <0x82001800 0 0xd0048000 0 0x2000>;
> +               reg = <0x1800 0 0 0 0>;
> +               #address-cells = <3>;
> +               #size-cells = <2>;
> +               #interrupt-cells = <1>;
> +               ranges;
> +               interrupt-map-mask = <0 0 0 0>;
> +               interrupt-map = <0 0 0 0 &mpic 60>;
> +               marvell,pcie-port = <0>;
> +               marvell,pcie-lane = <2>;
> +               clocks = <&gateclk 7>;
> +               status = "disabled";
> +       };
> +
> +       pcie at 4,0 {
> +               device_type = "pci";
> +               assigned-addresses = <0x82002000 0 0xd004c000 0 0x2000>;
> +               reg = <0x2000 0 0 0 0>;
> +               #address-cells = <3>;
> +               #size-cells = <2>;
> +               #interrupt-cells = <1>;
> +               ranges;
> +               interrupt-map-mask = <0 0 0 0>;
> +               interrupt-map = <0 0 0 0 &mpic 61>;
> +               marvell,pcie-port = <0>;
> +               marvell,pcie-lane = <3>;
> +               clocks = <&gateclk 8>;
> +               status = "disabled";
> +       };
> +
> +       pcie at 5,0 {
> +               device_type = "pci";
> +               assigned-addresses = <0x82002800 0 0xd0080000 0 0x2000>;
> +               reg = <0x2800 0 0 0 0>;
> +               #address-cells = <3>;
> +               #size-cells = <2>;
> +               #interrupt-cells = <1>;
> +               ranges;
> +               interrupt-map-mask = <0 0 0 0>;
> +               interrupt-map = <0 0 0 0 &mpic 62>;
> +               marvell,pcie-port = <1>;
> +               marvell,pcie-lane = <0>;
> +               clocks = <&gateclk 9>;
> +               status = "disabled";
> +       };
> +
> +       pcie at 6,0 {
> +               device_type = "pci";
> +               assigned-addresses = <0x82003000 0 0xd0084000 0 0x2000>;
> +               reg = <0x3000 0 0 0 0>;
> +               #address-cells = <3>;
> +               #size-cells = <2>;
> +               #interrupt-cells = <1>;
> +               ranges;
> +               interrupt-map-mask = <0 0 0 0>;
> +               interrupt-map = <0 0 0 0 &mpic 63>;
> +               marvell,pcie-port = <1>;
> +               marvell,pcie-lane = <1>;
> +               clocks = <&gateclk 10>;
> +               status = "disabled";
> +       };
> +
> +       pcie at 7,0 {
> +               device_type = "pci";
> +               assigned-addresses = <0x82003800 0 0xd0088000 0 0x2000>;
> +               reg = <0x3800 0 0 0 0>;
> +               #address-cells = <3>;
> +               #size-cells = <2>;
> +               #interrupt-cells = <1>;
> +               ranges;
> +               interrupt-map-mask = <0 0 0 0>;
> +               interrupt-map = <0 0 0 0 &mpic 64>;
> +               marvell,pcie-port = <1>;
> +               marvell,pcie-lane = <2>;
> +               clocks = <&gateclk 11>;
> +               status = "disabled";
> +       };
> +
> +       pcie at 8,0 {
> +               device_type = "pci";
> +               assigned-addresses = <0x82004000 0 0xd008c000 0 0x2000>;
> +               reg = <0x4000 0 0 0 0>;
> +               #address-cells = <3>;
> +               #size-cells = <2>;
> +               #interrupt-cells = <1>;
> +               ranges;
> +               interrupt-map-mask = <0 0 0 0>;
> +               interrupt-map = <0 0 0 0 &mpic 65>;
> +               marvell,pcie-port = <1>;
> +               marvell,pcie-lane = <3>;
> +               clocks = <&gateclk 12>;
> +               status = "disabled";
> +       };
> +       pcie at 9,0 {
> +               device_type = "pci";
> +               assigned-addresses = <0x82004800 0 0xd0042000 0 0x2000>;
> +               reg = <0x4800 0 0 0 0>;
> +               #address-cells = <3>;
> +               #size-cells = <2>;
> +               #interrupt-cells = <1>;
> +               ranges;
> +               interrupt-map-mask = <0 0 0 0>;
> +               interrupt-map = <0 0 0 0 &mpic 99>;
> +               marvell,pcie-port = <2>;
> +               marvell,pcie-lane = <0>;
> +               clocks = <&gateclk 26>;
> +               status = "disabled";
> +       };
> +
> +       pcie at 10,0 {
> +               device_type = "pci";
> +               assigned-addresses = <0x82005000 0 0xd0082000 0 0x2000>;
> +               reg = <0x5000 0 0 0 0>;
> +               #address-cells = <3>;
> +               #size-cells = <2>;
> +               #interrupt-cells = <1>;
> +               ranges;
> +               interrupt-map-mask = <0 0 0 0>;
> +               interrupt-map = <0 0 0 0 &mpic 103>;
> +               marvell,pcie-port = <3>;
> +               marvell,pcie-lane = <0>;
> +               clocks = <&gateclk 27>;
> +               status = "disabled";
> +       };
> +};
> diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
> index cc3a1af..6918fbc 100644
> --- a/drivers/pci/host/Kconfig
> +++ b/drivers/pci/host/Kconfig
> @@ -1,4 +1,8 @@
>  menu "PCI host controller drivers"
>         depends on PCI
>
> +config PCI_MVEBU
> +       bool "Marvell EBU PCIe controller"
> +       depends on ARCH_MVEBU
> +
>  endmenu
> diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
> index 636bc1a..5ea2d8b 100644
> --- a/drivers/pci/host/Makefile
> +++ b/drivers/pci/host/Makefile
> @@ -1 +1 @@
> -# intentionally empty
> +obj-$(CONFIG_PCI_MVEBU) += pci-mvebu.o
> diff --git a/drivers/pci/host/pci-mvebu.c b/drivers/pci/host/pci-mvebu.c
> new file mode 100644
> index 0000000..9c15a25
> --- /dev/null
> +++ b/drivers/pci/host/pci-mvebu.c
> @@ -0,0 +1,879 @@
> +/*
> + * PCIe driver for Marvell Armada 370 and Armada XP SoCs
> + *
> + * 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/kernel.h>
> +#include <linux/pci.h>
> +#include <linux/clk.h>
> +#include <linux/module.h>
> +#include <linux/mbus.h>
> +#include <linux/slab.h>
> +#include <linux/platform_device.h>
> +#include <linux/of_address.h>
> +#include <linux/of_pci.h>
> +#include <linux/of_irq.h>
> +#include <linux/of_platform.h>
> +
> +/*
> + * PCIe unit register offsets.
> + */
> +#define PCIE_DEV_ID_OFF                0x0000
> +#define PCIE_CMD_OFF           0x0004
> +#define PCIE_DEV_REV_OFF       0x0008
> +#define PCIE_BAR_LO_OFF(n)     (0x0010 + ((n) << 3))
> +#define PCIE_BAR_HI_OFF(n)     (0x0014 + ((n) << 3))
> +#define PCIE_HEADER_LOG_4_OFF  0x0128
> +#define PCIE_BAR_CTRL_OFF(n)   (0x1804 + (((n) - 1) * 4))
> +#define PCIE_WIN04_CTRL_OFF(n) (0x1820 + ((n) << 4))
> +#define PCIE_WIN04_BASE_OFF(n) (0x1824 + ((n) << 4))
> +#define PCIE_WIN04_REMAP_OFF(n)        (0x182c + ((n) << 4))
> +#define PCIE_WIN5_CTRL_OFF     0x1880
> +#define PCIE_WIN5_BASE_OFF     0x1884
> +#define PCIE_WIN5_REMAP_OFF    0x188c
> +#define PCIE_CONF_ADDR_OFF     0x18f8
> +#define  PCIE_CONF_ADDR_EN             0x80000000
> +#define  PCIE_CONF_REG(r)              ((((r) & 0xf00) << 16) | ((r) & 0xfc))
> +#define  PCIE_CONF_BUS(b)              (((b) & 0xff) << 16)
> +#define  PCIE_CONF_DEV(d)              (((d) & 0x1f) << 11)
> +#define  PCIE_CONF_FUNC(f)             (((f) & 0x7) << 8)
> +#define  PCIE_CONF_ADDR(bus, devfn, where) \
> +       (PCIE_CONF_BUS(bus) | PCIE_CONF_DEV(PCI_SLOT(devfn))    | \
> +        PCIE_CONF_FUNC(PCI_FUNC(devfn)) | PCIE_CONF_REG(where) | \
> +        PCIE_CONF_ADDR_EN)
> +#define PCIE_CONF_DATA_OFF     0x18fc
> +#define PCIE_MASK_OFF          0x1910
> +#define  PCIE_MASK_ENABLE_INTS          0x0f000000
> +#define PCIE_CTRL_OFF          0x1a00
> +#define  PCIE_CTRL_X1_MODE             0x0001
> +#define PCIE_STAT_OFF          0x1a04
> +#define  PCIE_STAT_BUS                  0xff00
> +#define  PCIE_STAT_LINK_DOWN           BIT(1)
> +#define PCIE_DEBUG_CTRL         0x1a60
> +#define  PCIE_DEBUG_SOFT_RESET         BIT(20)
> +
> +/*
> + * This product ID is registered by Marvell, and used when the Marvell
> + * SoC is not the root complex, but an endpoint on the PCIe bus. It is
> + * therefore safe to re-use this PCI ID for our emulated PCI-to-PCI
> + * bridge.
> + */
> +#define MARVELL_EMULATED_PCI_PCI_BRIDGE_ID 0x7846
> +
> +/* PCI configuration space of a PCI-to-PCI bridge */
> +struct mvebu_sw_pci_bridge {
> +       u16 vendor;
> +       u16 device;
> +       u16 command;
> +       u16 status;
> +       u16 class;
> +       u8 interface;
> +       u8 revision;
> +       u8 bist;
> +       u8 header_type;
> +       u8 latency_timer;
> +       u8 cache_line_size;
> +       u32 bar[2];
> +       u8 primary_bus;
> +       u8 secondary_bus;
> +       u8 subordinate_bus;
> +       u8 secondary_latency_timer;
> +       u8 iobase;
> +       u8 iolimit;
> +       u16 secondary_status;
> +       u16 membase;
> +       u16 memlimit;
> +       u16 prefmembase;
> +       u16 prefmemlimit;
> +       u32 prefbaseupper;
> +       u32 preflimitupper;
> +       u16 iobaseupper;
> +       u16 iolimitupper;
> +       u8 cappointer;
> +       u8 reserved1;
> +       u16 reserved2;
> +       u32 romaddr;
> +       u8 intline;
> +       u8 intpin;
> +       u16 bridgectrl;
> +};
> +
> +struct mvebu_pcie_port;
> +
> +/* Structure representing all PCIe interfaces */
> +struct mvebu_pcie {
> +       struct platform_device *pdev;
> +       struct mvebu_pcie_port *ports;
> +       struct resource io;
> +       struct resource realio;
> +       struct resource mem;
> +       struct resource busn;
> +       int nports;
> +};
> +
> +/* Structure representing one PCIe interface */
> +struct mvebu_pcie_port {
> +       char *name;
> +       void __iomem *base;
> +       spinlock_t conf_lock;
> +       int haslink;
> +       u32 port;
> +       u32 lane;
> +       int devfn;
> +       struct clk *clk;
> +       struct mvebu_sw_pci_bridge bridge;
> +       struct device_node *dn;
> +       struct mvebu_pcie *pcie;
> +       phys_addr_t memwin_base;
> +       size_t memwin_size;
> +       phys_addr_t iowin_base;
> +       size_t iowin_size;
> +};
> +
> +static bool mvebu_pcie_link_up(struct mvebu_pcie_port *port)
> +{
> +       return !(readl(port->base + PCIE_STAT_OFF) & PCIE_STAT_LINK_DOWN);
> +}
> +
> +static void mvebu_pcie_set_local_bus_nr(struct mvebu_pcie_port *port, int nr)
> +{
> +       u32 stat;
> +
> +       stat = readl(port->base + PCIE_STAT_OFF);
> +       stat &= ~PCIE_STAT_BUS;
> +       stat |= nr << 8;
> +       writel(stat, port->base + PCIE_STAT_OFF);
> +}
> +
> +/*
> + * Setup PCIE BARs and Address Decode Wins:
> + * BAR[0,2] -> disabled, BAR[1] -> covers all DRAM banks
> + * WIN[0-3] -> DRAM bank[0-3]
> + */
> +static void __init mvebu_pcie_setup_wins(struct mvebu_pcie_port *port)
> +{
> +       const struct mbus_dram_target_info *dram;
> +       u32 size;
> +       int i;
> +
> +       dram = mv_mbus_dram_info();
> +
> +       /* First, disable and clear BARs and windows. */
> +       for (i = 1; i < 3; i++) {
> +               writel(0, port->base + PCIE_BAR_CTRL_OFF(i));
> +               writel(0, port->base + PCIE_BAR_LO_OFF(i));
> +               writel(0, port->base + PCIE_BAR_HI_OFF(i));
> +       }
> +
> +       for (i = 0; i < 5; i++) {
> +               writel(0, port->base + PCIE_WIN04_CTRL_OFF(i));
> +               writel(0, port->base + PCIE_WIN04_BASE_OFF(i));
> +               writel(0, port->base + PCIE_WIN04_REMAP_OFF(i));
> +       }
> +
> +       writel(0, port->base + PCIE_WIN5_CTRL_OFF);
> +       writel(0, port->base + PCIE_WIN5_BASE_OFF);
> +       writel(0, port->base + PCIE_WIN5_REMAP_OFF);
> +
> +       /* Setup windows for DDR banks.  Count total DDR size on the fly. */
> +       size = 0;
> +       for (i = 0; i < dram->num_cs; i++) {
> +               const struct mbus_dram_window *cs = dram->cs + i;
> +
> +               writel(cs->base & 0xffff0000,
> +                      port->base + PCIE_WIN04_BASE_OFF(i));
> +               writel(0, port->base + PCIE_WIN04_REMAP_OFF(i));
> +               writel(((cs->size - 1) & 0xffff0000) |
> +                       (cs->mbus_attr << 8) |
> +                       (dram->mbus_dram_target_id << 4) | 1,
> +                      port->base + PCIE_WIN04_CTRL_OFF(i));
> +
> +               size += cs->size;
> +       }
> +
> +       /* Round up 'size' to the nearest power of two. */
> +       if ((size & (size - 1)) != 0)
> +               size = 1 << fls(size);
> +
> +       /* Setup BAR[1] to all DRAM banks. */
> +       writel(dram->cs[0].base, port->base + PCIE_BAR_LO_OFF(1));
> +       writel(0, port->base + PCIE_BAR_HI_OFF(1));
> +       writel(((size - 1) & 0xffff0000) | 1,
> +              port->base + PCIE_BAR_CTRL_OFF(1));
> +}
> +
> +static void __init mvebu_pcie_setup_hw(struct mvebu_pcie_port *port)
> +{
> +       u16 cmd;
> +       u32 mask;
> +
> +       /* Point PCIe unit MBUS decode windows to DRAM space. */
> +       mvebu_pcie_setup_wins(port);
> +
> +       /* Master + slave enable. */
> +       cmd = readw(port->base + PCIE_CMD_OFF);
> +       cmd |= PCI_COMMAND_IO;
> +       cmd |= PCI_COMMAND_MEMORY;
> +       cmd |= PCI_COMMAND_MASTER;
> +       writew(cmd, port->base + PCIE_CMD_OFF);
> +
> +       /* Enable interrupt lines A-D. */
> +       mask = readl(port->base + PCIE_MASK_OFF);
> +       mask |= PCIE_MASK_ENABLE_INTS;
> +       writel(mask, port->base + PCIE_MASK_OFF);
> +}
> +
> +static int mvebu_pcie_hw_rd_conf(struct mvebu_pcie_port *port,
> +                                struct pci_bus *bus,
> +                                u32 devfn, int where, int size, u32 *val)
> +{
> +       writel(PCIE_CONF_ADDR(bus->number, devfn, where),
> +              port->base + PCIE_CONF_ADDR_OFF);
> +
> +       *val = readl(port->base + PCIE_CONF_DATA_OFF);
> +
> +       if (size == 1)
> +               *val = (*val >> (8 * (where & 3))) & 0xff;
> +       else if (size == 2)
> +               *val = (*val >> (8 * (where & 3))) & 0xffff;
> +
> +       return PCIBIOS_SUCCESSFUL;
> +}
> +
> +static int mvebu_pcie_hw_wr_conf(struct mvebu_pcie_port *port,
> +                                struct pci_bus *bus,
> +                                u32 devfn, int where, int size, u32 val)
> +{
> +       int ret = PCIBIOS_SUCCESSFUL;
> +
> +       writel(PCIE_CONF_ADDR(bus->number, devfn, where),
> +              port->base + PCIE_CONF_ADDR_OFF);
> +
> +       if (size == 4)
> +               writel(val, port->base + PCIE_CONF_DATA_OFF);
> +       else if (size == 2)
> +               writew(val, port->base + PCIE_CONF_DATA_OFF + (where & 3));
> +       else if (size == 1)
> +               writeb(val, port->base + PCIE_CONF_DATA_OFF + (where & 3));
> +       else
> +               ret = PCIBIOS_BAD_REGISTER_NUMBER;
> +
> +       return ret;
> +}
> +
> +static void mvebu_pcie_handle_iobase_change(struct mvebu_pcie_port *port)
> +{
> +       phys_addr_t iobase;
> +
> +       /* Are the new iobase/iolimit values invalid? */
> +       if (port->bridge.iolimit < port->bridge.iobase ||
> +           port->bridge.iolimitupper < port->bridge.iobaseupper) {
> +
> +               /* If a window was configured, remove it */
> +               if (port->iowin_base) {
> +                       mvebu_mbus_del_window(port->iowin_base,
> +                                             port->iowin_size);
> +                       port->iowin_base = 0;
> +                       port->iowin_size = 0;
> +               }
> +
> +               return;
> +       }
> +
> +       /*
> +        * We read the PCI-to-PCI bridge emulated registers, and
> +        * calculate the base address and size of the address decoding
> +        * window to setup, according to the PCI-to-PCI bridge
> +        * specifications. iobase is the bus address, port->iowin_base
> +        * is the CPU address.
> +        */
> +       iobase = ((port->bridge.iobase & 0xF0) << 8) |
> +               (port->bridge.iobaseupper << 16);
> +       port->iowin_base = port->pcie->io.start + iobase;
> +       port->iowin_size = ((0xFFF | ((port->bridge.iolimit & 0xF0) << 8) |
> +                           (port->bridge.iolimitupper << 16)) -
> +                           iobase);
> +
> +       mvebu_mbus_add_window_remap_flags(port->name, port->iowin_base,
> +                                         port->iowin_size,
> +                                         iobase,
> +                                         MVEBU_MBUS_PCI_IO);
> +
> +       pci_ioremap_io(iobase, port->iowin_base);
> +}
> +
> +static void mvebu_pcie_handle_membase_change(struct mvebu_pcie_port *port)
> +{
> +       /* Are the new membase/memlimit values invalid? */
> +       if (port->bridge.memlimit < port->bridge.membase) {
> +
> +               /* If a window was configured, remove it */
> +               if (port->memwin_base) {
> +                       mvebu_mbus_del_window(port->memwin_base,
> +                                             port->memwin_size);
> +                       port->memwin_base = 0;
> +                       port->memwin_size = 0;
> +               }
> +
> +               return;
> +       }
> +
> +       /*
> +        * We read the PCI-to-PCI bridge emulated registers, and
> +        * calculate the base address and size of the address decoding
> +        * window to setup, according to the PCI-to-PCI bridge
> +        * specifications.
> +        */
> +       port->memwin_base  = ((port->bridge.membase & 0xFFF0) << 16);
> +       port->memwin_size  =
> +               (((port->bridge.memlimit & 0xFFF0) << 16) | 0xFFFFF) -
> +               port->memwin_base;
> +
> +       mvebu_mbus_add_window_remap_flags(port->name, port->memwin_base,
> +                                         port->memwin_size,
> +                                         MVEBU_MBUS_NO_REMAP,
> +                                         MVEBU_MBUS_PCI_MEM);
> +}
> +
> +/*
> + * Initialize the configuration space of the PCI-to-PCI bridge
> + * associated with the given PCIe interface.
> + */
> +static void mvebu_sw_pci_bridge_init(struct mvebu_pcie_port *port)
> +{
> +       struct mvebu_sw_pci_bridge *bridge = &port->bridge;
> +
> +       memset(bridge, 0, sizeof(struct mvebu_sw_pci_bridge));
> +
> +       bridge->status = PCI_STATUS_CAP_LIST;
> +       bridge->class = PCI_CLASS_BRIDGE_PCI;
> +       bridge->vendor = PCI_VENDOR_ID_MARVELL;
> +       bridge->device = MARVELL_EMULATED_PCI_PCI_BRIDGE_ID;
> +       bridge->header_type = PCI_HEADER_TYPE_BRIDGE;
> +       bridge->cache_line_size = 0x10;
> +
> +       /* We support 32 bits I/O addressing */
> +       bridge->iobase = PCI_IO_RANGE_TYPE_32;
> +       bridge->iolimit = PCI_IO_RANGE_TYPE_32;
> +}
> +
> +/*
> + * Read the configuration space of the PCI-to-PCI bridge associated to
> + * the given PCIe interface.
> + */
> +static int mvebu_sw_pci_bridge_read(struct mvebu_pcie_port *port,
> +                                 unsigned int where, int size, u32 *value)
> +{
> +       struct mvebu_sw_pci_bridge *bridge = &port->bridge;
> +
> +       switch (where & ~3) {
> +       case PCI_VENDOR_ID:
> +               *value = bridge->device << 16 | bridge->vendor;
> +               break;
> +
> +       case PCI_COMMAND:
> +               *value = bridge->status << 16 | bridge->command;
> +               break;
> +
> +       case PCI_CLASS_REVISION:
> +               *value = bridge->class << 16 | bridge->interface << 8 |
> +                        bridge->revision;
> +               break;
> +
> +       case PCI_CACHE_LINE_SIZE:
> +               *value = bridge->bist << 24 | bridge->header_type << 16 |
> +                        bridge->latency_timer << 8 | bridge->cache_line_size;
> +               break;
> +
> +       case PCI_BASE_ADDRESS_0 ... PCI_BASE_ADDRESS_1:
> +               *value = bridge->bar[((where & ~3) - PCI_BASE_ADDRESS_0) / 4];
> +               break;
> +
> +       case PCI_PRIMARY_BUS:
> +               *value = (bridge->secondary_latency_timer << 24 |
> +                         bridge->subordinate_bus         << 16 |
> +                         bridge->secondary_bus           <<  8 |
> +                         bridge->primary_bus);
> +               break;
> +
> +       case PCI_IO_BASE:
> +               *value = (bridge->secondary_status << 16 |
> +                         bridge->iolimit          <<  8 |
> +                         bridge->iobase);
> +               break;
> +
> +       case PCI_MEMORY_BASE:
> +               *value = (bridge->memlimit << 16 | bridge->membase);
> +               break;
> +
> +       case PCI_PREF_MEMORY_BASE:
> +               *value = (bridge->prefmemlimit << 16 | bridge->prefmembase);
> +               break;
> +
> +       case PCI_PREF_BASE_UPPER32:
> +               *value = bridge->prefbaseupper;
> +               break;
> +
> +       case PCI_PREF_LIMIT_UPPER32:
> +               *value = bridge->preflimitupper;
> +               break;
> +
> +       case PCI_IO_BASE_UPPER16:
> +               *value = (bridge->iolimitupper << 16 | bridge->iobaseupper);
> +               break;
> +
> +       case PCI_ROM_ADDRESS1:
> +               *value = 0;
> +               break;
> +
> +       default:
> +               *value = 0xffffffff;
> +               return PCIBIOS_BAD_REGISTER_NUMBER;
> +       }
> +
> +       if (size == 2)
> +               *value = (*value >> (8 * (where & 3))) & 0xffff;
> +       else if (size == 1)
> +               *value = (*value >> (8 * (where & 3))) & 0xff;
> +
> +       return PCIBIOS_SUCCESSFUL;
> +}
> +
> +/* Write to the PCI-to-PCI bridge configuration space */
> +static int mvebu_sw_pci_bridge_write(struct mvebu_pcie_port *port,
> +                                    unsigned int where, int size, u32 value)
> +{
> +       struct mvebu_sw_pci_bridge *bridge = &port->bridge;
> +       u32 mask, reg;
> +       int err;
> +
> +       if (size == 4)
> +               mask = 0x0;
> +       else if (size == 2)
> +               mask = ~(0xffff << ((where & 3) * 8));
> +       else if (size == 1)
> +               mask = ~(0xff << ((where & 3) * 8));
> +       else
> +               return PCIBIOS_BAD_REGISTER_NUMBER;
> +
> +       err = mvebu_sw_pci_bridge_read(port, where & ~3, 4, &reg);
> +       if (err)
> +               return err;
> +
> +       value = (reg & mask) | value << ((where & 3) * 8);
> +
> +       switch (where & ~3) {
> +       case PCI_COMMAND:
> +               bridge->command = value & 0xffff;
> +               bridge->status = value >> 16;
> +               break;
> +
> +       case PCI_BASE_ADDRESS_0 ... PCI_BASE_ADDRESS_1:
> +               bridge->bar[((where & ~3) - PCI_BASE_ADDRESS_0) / 4] = value;
> +               break;
> +
> +       case PCI_IO_BASE:
> +               /*
> +                * We also keep bit 1 set, it is a read-only bit that
> +                * indicates we support 32 bits addressing for the
> +                * I/O
> +                */
> +               bridge->iobase = (value & 0xff) | PCI_IO_RANGE_TYPE_32;
> +               bridge->iolimit = ((value >> 8) & 0xff) | PCI_IO_RANGE_TYPE_32;
> +               bridge->secondary_status = value >> 16;
> +               mvebu_pcie_handle_iobase_change(port);
> +               break;
> +
> +       case PCI_MEMORY_BASE:
> +               bridge->membase = value & 0xffff;
> +               bridge->memlimit = value >> 16;
> +               mvebu_pcie_handle_membase_change(port);
> +               break;
> +
> +       case PCI_PREF_MEMORY_BASE:
> +               bridge->prefmembase = value & 0xffff;
> +               bridge->prefmemlimit = value >> 16;
> +               break;
> +
> +       case PCI_PREF_BASE_UPPER32:
> +               bridge->prefbaseupper = value;
> +               break;
> +
> +       case PCI_PREF_LIMIT_UPPER32:
> +               bridge->preflimitupper = value;
> +               break;
> +
> +       case PCI_IO_BASE_UPPER16:
> +               bridge->iobaseupper = value & 0xffff;
> +               bridge->iolimitupper = value >> 16;
> +               mvebu_pcie_handle_iobase_change(port);
> +               break;
> +
> +       case PCI_PRIMARY_BUS:
> +               bridge->primary_bus             = value & 0xff;
> +               bridge->secondary_bus           = (value >> 8) & 0xff;
> +               bridge->subordinate_bus         = (value >> 16) & 0xff;
> +               bridge->secondary_latency_timer = (value >> 24) & 0xff;
> +               mvebu_pcie_set_local_bus_nr(port, bridge->secondary_bus);
> +               break;
> +
> +       default:
> +               break;
> +       }
> +
> +       return PCIBIOS_SUCCESSFUL;
> +}
> +
> +static inline struct mvebu_pcie *sys_to_pcie(struct pci_sys_data *sys)
> +{
> +       return sys->private_data;
> +}
> +
> +static struct mvebu_pcie_port *
> +mvebu_pcie_find_port(struct mvebu_pcie *pcie, struct pci_bus *bus,
> +                    int devfn)
> +{
> +       int i;
> +
> +       for (i = 0; i < pcie->nports; i++) {
> +               struct mvebu_pcie_port *port = &pcie->ports[i];
> +               if (bus->number == 0 && port->devfn == devfn)
> +                       return port;
> +               if (bus->number != 0 &&
> +                   port->bridge.secondary_bus == bus->number)
> +                       return port;
> +       }
> +
> +       return NULL;
> +}
> +
> +/* PCI configuration space write function */
> +static int mvebu_pcie_wr_conf(struct pci_bus *bus, u32 devfn,
> +                             int where, int size, u32 val)
> +{
> +       struct mvebu_pcie *pcie = sys_to_pcie(bus->sysdata);
> +       struct mvebu_pcie_port *port;
> +       unsigned long flags;
> +       int ret;
> +
> +       port = mvebu_pcie_find_port(pcie, bus, devfn);
> +       if (!port)
> +               return PCIBIOS_DEVICE_NOT_FOUND;
> +
> +       /* Access the emulated PCI-to-PCI bridge */
> +       if (bus->number == 0)
> +               return mvebu_sw_pci_bridge_write(port, where, size, val);
> +
> +       if (!port->haslink || PCI_SLOT(devfn) != 0)
> +               return PCIBIOS_DEVICE_NOT_FOUND;
> +
> +       /* Access the real PCIe interface */
> +       spin_lock_irqsave(&port->conf_lock, flags);
> +       ret = mvebu_pcie_hw_wr_conf(port, bus,
> +                                   PCI_DEVFN(1, PCI_FUNC(devfn)),
> +                                   where, size, val);
> +       spin_unlock_irqrestore(&port->conf_lock, flags);
> +
> +       return ret;
> +}
> +
> +/* PCI configuration space read function */
> +static int mvebu_pcie_rd_conf(struct pci_bus *bus, u32 devfn, int where,
> +                             int size, u32 *val)
> +{
> +       struct mvebu_pcie *pcie = sys_to_pcie(bus->sysdata);
> +       struct mvebu_pcie_port *port;
> +       unsigned long flags;
> +       int ret;
> +
> +       port = mvebu_pcie_find_port(pcie, bus, devfn);
> +       if (!port) {
> +               *val = 0xffffffff;
> +               return PCIBIOS_DEVICE_NOT_FOUND;
> +       }
> +
> +       /* Access the emulated PCI-to-PCI bridge */
> +       if (bus->number == 0)
> +               return mvebu_sw_pci_bridge_read(port, where, size, val);
> +
> +       if (!port->haslink || PCI_SLOT(devfn) != 0) {
> +               *val = 0xffffffff;
> +               return PCIBIOS_DEVICE_NOT_FOUND;
> +       }
> +
> +       /* Access the real PCIe interface */
> +       spin_lock_irqsave(&port->conf_lock, flags);
> +       ret = mvebu_pcie_hw_rd_conf(port, bus,
> +                                   PCI_DEVFN(1, PCI_FUNC(devfn)),
> +                                   where, size, val);
> +       spin_unlock_irqrestore(&port->conf_lock, flags);
> +
> +       return ret;
> +}
> +
> +static struct pci_ops mvebu_pcie_ops = {
> +       .read = mvebu_pcie_rd_conf,
> +       .write = mvebu_pcie_wr_conf,
> +};
> +
> +static int __init mvebu_pcie_setup(int nr, struct pci_sys_data *sys)
> +{
> +       struct mvebu_pcie *pcie = sys_to_pcie(sys);
> +       int i;
> +
> +       pci_add_resource_offset(&sys->resources, &pcie->realio, sys->io_offset);
> +       pci_add_resource_offset(&sys->resources, &pcie->mem, sys->mem_offset);
> +       pci_add_resource(&sys->resources, &pcie->busn);
> +
> +       for (i = 0; i < pcie->nports; i++) {
> +               struct mvebu_pcie_port *port = &pcie->ports[i];
> +               mvebu_pcie_setup_hw(port);
> +       }
> +
> +       return 1;
> +}
> +
> +static int __init mvebu_pcie_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
> +{
> +       struct of_irq oirq;
> +       int ret;
> +
> +       ret = of_irq_map_pci(dev, &oirq);
> +       if (ret)
> +               return ret;
> +
> +       return irq_create_of_mapping(oirq.controller, oirq.specifier,
> +                                    oirq.size);
> +}
> +
> +static struct pci_bus *mvebu_pcie_scan_bus(int nr, struct pci_sys_data *sys)
> +{
> +       struct mvebu_pcie *pcie = sys_to_pcie(sys);
> +       struct pci_bus *bus;
> +
> +       bus = pci_create_root_bus(&pcie->pdev->dev, sys->busnr,
> +                                 &mvebu_pcie_ops, sys, &sys->resources);
> +       if (!bus)
> +               return NULL;
> +
> +       pci_scan_child_bus(bus);
> +
> +       return bus;
> +}
> +
> +resource_size_t mvebu_pcie_align_resource(struct pci_dev *dev,
> +                                         const struct resource *res,
> +                                         resource_size_t start,
> +                                         resource_size_t size,
> +                                         resource_size_t align)
> +{
> +       if (dev->bus->number != 0)
> +               return start;
> +
> +       /*
> +        * On the PCI-to-PCI bridge side, the I/O windows must have at
> +        * least a 64 KB size and be aligned on their size, and the
> +        * memory windows must have at least a 1 MB size and be
> +        * aligned on their size
> +        */
> +       if (res->flags & IORESOURCE_IO)
> +               return round_up(start, max((resource_size_t)SZ_64K, size));
> +       else if (res->flags & IORESOURCE_MEM)
> +               return round_up(start, max((resource_size_t)SZ_1M, size));
> +       else
> +               return start;
> +}
> +
> +static void mvebu_pcie_enable(struct mvebu_pcie *pcie)
> +{
> +       struct hw_pci hw;
> +
> +       memset(&hw, 0, sizeof(hw));
> +
> +       hw.nr_controllers = 1;
> +       hw.private_data   = (void **)&pcie;
> +       hw.setup          = mvebu_pcie_setup;
> +       hw.scan           = mvebu_pcie_scan_bus;
> +       hw.map_irq        = mvebu_pcie_map_irq;
> +       hw.ops            = &mvebu_pcie_ops;
> +       hw.align_resource = mvebu_pcie_align_resource;
> +
> +       pci_common_init(&hw);
> +}
> +
> +/*
> + * Looks up the list of register addresses encoded into the reg =
> + * <...> property for one that matches the given port/lane. Once
> + * found, maps it.
> + */
> +static void __iomem *mvebu_pcie_map_registers(struct platform_device *pdev,
> +                                             struct device_node *np,
> +                                             struct mvebu_pcie_port *port)
> +{
> +       struct resource regs;
> +       int ret = 0;
> +
> +       ret = of_address_to_resource(np, 0, &regs);
> +       if (ret)
> +               return NULL;
> +
> +       return devm_request_and_ioremap(&pdev->dev, &regs);
> +}
> +
> +static int __init mvebu_pcie_probe(struct platform_device *pdev)
> +{
> +       struct mvebu_pcie *pcie;
> +       struct device_node *np = pdev->dev.of_node;
> +       struct of_pci_range range;
> +       struct of_pci_range_parser parser;
> +       struct device_node *child;
> +       int i, ret;
> +
> +       pcie = devm_kzalloc(&pdev->dev, sizeof(struct mvebu_pcie),
> +                           GFP_KERNEL);
> +       if (!pcie)
> +               return -ENOMEM;
> +
> +       pcie->pdev = pdev;
> +
> +       if (of_pci_range_parser(&parser, np))
> +               return -EINVAL;
> +
> +       /* Get the I/O and memory ranges from DT */
> +       for_each_of_pci_range(&parser, &range) {
> +               unsigned long restype = range.flags & IORESOURCE_TYPE_BITS;
> +               if (restype == IORESOURCE_IO) {
> +                       of_pci_range_to_resource(&range, np, &pcie->io);
> +                       of_pci_range_to_resource(&range, np, &pcie->realio);
> +                       pcie->io.name = "I/O";
> +                       pcie->realio.start = max_t(resource_size_t,
> +                                                  PCIBIOS_MIN_IO,
> +                                                  range.pci_addr);
> +                       pcie->realio.end = min_t(resource_size_t,
> +                                                IO_SPACE_LIMIT,
> +                                                range.pci_addr + range.size);
> +               }
> +               if (restype == IORESOURCE_MEM) {
> +                       of_pci_range_to_resource(&range, np, &pcie->mem);
> +                       pcie->mem.name = "MEM";
> +               }
> +       }
> +
> +       /* Get the bus range */
> +       ret = of_pci_parse_bus_range(np, &pcie->busn);
> +       if (ret) {
> +               dev_err(&pdev->dev, "failed to parse bus-range property: %d\n",
> +                       ret);
> +               return ret;
> +       }
> +
> +       for_each_child_of_node(pdev->dev.of_node, child) {
> +               if (!of_device_is_available(child))
> +                       continue;
> +               pcie->nports++;
> +       }
> +
> +       pcie->ports = devm_kzalloc(&pdev->dev, pcie->nports *
> +                                  sizeof(struct mvebu_pcie_port),
> +                                  GFP_KERNEL);
> +       if (!pcie->ports)
> +               return -ENOMEM;
> +
> +       i = 0;
> +       for_each_child_of_node(pdev->dev.of_node, child) {
> +               struct mvebu_pcie_port *port = &pcie->ports[i];
> +
> +               if (!of_device_is_available(child))
> +                       continue;
> +
> +               port->pcie = pcie;
> +
> +               if (of_property_read_u32(child, "marvell,pcie-port",
> +                                        &port->port)) {
> +                       dev_warn(&pdev->dev,
> +                                "ignoring PCIe DT node, missing pcie-port property\n");
> +                       continue;
> +               }
> +
> +               if (of_property_read_u32(child, "marvell,pcie-lane",
> +                                        &port->lane))
> +                       port->lane = 0;
> +
> +               port->name = kasprintf(GFP_KERNEL, "pcie%d.%d",
> +                                      port->port, port->lane);
> +
> +               port->devfn = of_pci_get_devfn(child);
> +               if (port->devfn < 0)
> +                       continue;
> +
> +               port->base = mvebu_pcie_map_registers(pdev, child, port);
> +               if (!port->base) {
> +                       dev_err(&pdev->dev, "PCIe%d.%d: cannot map registers\n",
> +                               port->port, port->lane);
> +                       continue;
> +               }
> +
> +               if (mvebu_pcie_link_up(port)) {
> +                       port->haslink = 1;
> +                       dev_info(&pdev->dev, "PCIe%d.%d: link up\n",
> +                                port->port, port->lane);
> +               } else {
> +                       port->haslink = 0;
> +                       dev_info(&pdev->dev, "PCIe%d.%d: link down\n",
> +                                port->port, port->lane);
> +               }
> +
> +               port->clk = of_clk_get_by_name(child, NULL);
> +               if (!port->clk) {
> +                       dev_err(&pdev->dev, "PCIe%d.%d: cannot get clock\n",
> +                              port->port, port->lane);
> +                       iounmap(port->base);
> +                       port->haslink = 0;
> +                       continue;
> +               }
> +
> +               port->dn = child;
> +
> +               clk_prepare_enable(port->clk);
> +               spin_lock_init(&port->conf_lock);
> +
> +               mvebu_sw_pci_bridge_init(port);
> +
> +               i++;
> +       }
> +
> +       mvebu_pcie_enable(pcie);
> +
> +       return 0;
> +}
> +
> +static const struct of_device_id mvebu_pcie_of_match_table[] = {
> +       { .compatible = "marvell,armada-xp-pcie", },
> +       { .compatible = "marvell,armada-370-pcie", },
> +       {},
> +};
> +MODULE_DEVICE_TABLE(of, mvebu_pcie_of_match_table);
> +
> +static struct platform_driver mvebu_pcie_driver = {
> +       .driver = {
> +               .owner = THIS_MODULE,
> +               .name = "mvebu-pcie",
> +               .of_match_table =
> +                  of_match_ptr(mvebu_pcie_of_match_table),
> +       },
> +};
> +
> +static int mvebu_pcie_init(void)
> +{
> +       return platform_driver_probe(&mvebu_pcie_driver,
> +                                    mvebu_pcie_probe);
> +}
> +
> +subsys_initcall(mvebu_pcie_init);
> +
> +MODULE_AUTHOR("Thomas Petazzoni <thomas.petazzoni at free-electrons.com>");
> +MODULE_DESCRIPTION("Marvell EBU PCIe driver");
> +MODULE_LICENSE("GPLv2");
> --
> 1.7.9.5
>


From arnd at arndb.de  Tue Apr  9 17:20:06 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 9 Apr 2013 23:20:06 +0200
Subject: [GIT PULL 0/10] Samsung stuff for v3.10
In-Reply-To: <516309C4.3000008@samsung.com>
References: <516309C4.3000008@samsung.com>
Message-ID: <201304092320.06222.arnd@arndb.de>

On Monday 08 April 2013, Kukjin Kim wrote:
> 
> Hi Arnd, Olof
> 
> This is 2nd pull-request for Samsung stuff for v3.10.
> 
> If any problems, please kindly let me know.

I managed to pull them all in, aside from the 6/10, since you asked us
to defer that one. There were a lot more small mistakes, and I think
I've managed to fix them all up, but please check if the for-next
branch now actually works.

A few more requests for the future:

* Please send branches earlier. You already sent a number of them
very early, but then we saw very little until now. I'd rather
get a number of follow-on pull requests than getting everything
at once, which has lead to stuff getting rejected in the past
when things break, as you remember. I've been waiting for
ages now to rebase my multiplatform series on the things you
have in your tree, I hope we can still make it in time.

* Half a sentence of tag description is not really enough for
a long series. Please explain in the tag what the purpose of
the series is, as you do for a patch.

* Mention interdependencies between branches explicitly. It
causes us a lot of extra work having to find out what patches
are actually new in a series when you have based them on earlier
patches.

* Look at the patches that are already merged and test them.
I've had to fix up build errors now that have been present
in linux-next for multiple weeks.

	Arnd


From thomas.petazzoni at free-electrons.com  Tue Apr  9 17:22:59 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Tue, 9 Apr 2013 23:22:59 +0200
Subject: [PATCHv8 10/19] pci: PCIe driver for Marvell Armada 370/XP systems
In-Reply-To: <CAErSpo4FJVoUxQS6ti0-kUXCuK4HnAxWd_5aYi4NyVykcCABng@mail.gmail.com>
References: <1365541601-14095-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1365541601-14095-11-git-send-email-thomas.petazzoni@free-electrons.com>
 <CAErSpo4FJVoUxQS6ti0-kUXCuK4HnAxWd_5aYi4NyVykcCABng@mail.gmail.com>
Message-ID: <20130409232259.2e04588c@skate>

Dear Bjorn Helgaas,

On Tue, 9 Apr 2013 15:12:58 -0600, Bjorn Helgaas wrote:
> On Tue, Apr 9, 2013 at 3:06 PM, Thomas Petazzoni
> <thomas.petazzoni at free-electrons.com> wrote:
> > This driver implements the support for the PCIe interfaces on the
> > Marvell Armada 370/XP ARM SoCs. In the future, it might be extended to
> > cover earlier families of Marvell SoCs, such as Dove, Orion and
> > Kirkwood.
> >
> > The driver implements the hw_pci operations needed by the core ARM PCI
> > code to setup PCI devices and get their corresponding IRQs, and the
> > pci_ops operations that are used by the PCI core to read/write the
> > configuration space of PCI devices.
> >
> > Since the PCIe interfaces of Marvell SoCs are completely separate and
> > not linked together in a bus, this driver sets up an emulated PCI host
> > bridge, with one PCI-to-PCI bridge as child for each hardware PCIe
> > interface.
> >
> > In addition, this driver enumerates the different PCIe slots, and for
> > those having a device plugged in, it sets up the necessary address
> > decoding windows, using the new armada_370_xp_alloc_pcie_window()
> > function from mach-mvebu/addr-map.c.
> >
> > Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> > Acked-by: Bjorn Helgaas <bhelgaas at google.com>
> 
> This and 06/19 look good to me.

Thanks!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From thomas.petazzoni at free-electrons.com  Tue Apr  9 17:26:13 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Tue,  9 Apr 2013 23:26:13 +0200
Subject: [PATCHv1 0/5] Marvell EBU irqchip improvements
Message-ID: <1365542778-27959-1-git-send-email-thomas.petazzoni@free-electrons.com>

Hello,

Here is a set of 5 patches that move the Marvell EBU IRQ controller
driver to drivers/irqchip/ and do a few minor related cleanup or
improvements.

Those commits were originally part of the series introducing PCIe MSI
support for Marvell EBU platform, but the MSI support is not ready for
merging. However, I'd like those preparation patches to be considered
for 3.10.

Thanks,

Thomas

Thomas Petazzoni (5):
  ARM: mvebu: move L2 cache initialization in init_early()
  irqchip: move IRQ driver for Armada 370/XP
  irqchip: armada-370-xp: move IRQ handler to avoid forward declaration
  irqchip: armada-370-xp: slightly cleanup irq controller driver
  ARM: mvebu: do not duplicate the mpic alias

 arch/arm/boot/dts/armada-370.dtsi                  |    2 +-
 arch/arm/boot/dts/armada-xp.dtsi                   |    2 +-
 arch/arm/mach-mvebu/Makefile                       |    2 +-
 arch/arm/mach-mvebu/armada-370-xp.c                |    9 +-
 drivers/irqchip/Makefile                           |    1 +
 .../irqchip}/irq-armada-370-xp.c                   |  106 ++++++++++----------
 6 files changed, 62 insertions(+), 60 deletions(-)
 rename {arch/arm/mach-mvebu => drivers/irqchip}/irq-armada-370-xp.c (91%)

-- 
1.7.9.5



From thomas.petazzoni at free-electrons.com  Tue Apr  9 17:26:14 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Tue,  9 Apr 2013 23:26:14 +0200
Subject: [PATCHv1 1/5] ARM: mvebu: move L2 cache initialization in init_early()
In-Reply-To: <1365542778-27959-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1365542778-27959-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1365542778-27959-2-git-send-email-thomas.petazzoni@free-electrons.com>

In preparation for moving the IRQ controller driver to
drivers/irqchip/, we don't want the IRQ controller driver to be
responsible for initializing the L2 cache. Instead, let's initialize
the L2 cache at the init_early() level, like mach-exynos/common.c is
doing.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 arch/arm/mach-mvebu/armada-370-xp.c     |    5 +++++
 arch/arm/mach-mvebu/irq-armada-370-xp.c |    4 ----
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-mvebu/armada-370-xp.c b/arch/arm/mach-mvebu/armada-370-xp.c
index a5ea616d..c1bbfa7 100644
--- a/arch/arm/mach-mvebu/armada-370-xp.c
+++ b/arch/arm/mach-mvebu/armada-370-xp.c
@@ -19,6 +19,7 @@
 #include <linux/time-armada-370-xp.h>
 #include <linux/clk/mvebu.h>
 #include <linux/dma-mapping.h>
+#include <asm/hardware/cache-l2x0.h>
 #include <asm/mach/arch.h>
 #include <asm/mach/map.h>
 #include <asm/mach/time.h>
@@ -54,6 +55,10 @@ void __init armada_370_xp_init_early(void)
 	 * to make sure such the allocations won't fail.
 	 */
 	init_dma_coherent_pool_size(SZ_1M);
+
+#ifdef CONFIG_CACHE_L2X0
+	l2x0_of_init(0, ~0UL);
+#endif
 }
 
 static void __init armada_370_xp_dt_init(void)
diff --git a/arch/arm/mach-mvebu/irq-armada-370-xp.c b/arch/arm/mach-mvebu/irq-armada-370-xp.c
index 6a9195e..f6699f3 100644
--- a/arch/arm/mach-mvebu/irq-armada-370-xp.c
+++ b/arch/arm/mach-mvebu/irq-armada-370-xp.c
@@ -25,7 +25,6 @@
 #include <asm/mach/arch.h>
 #include <asm/exception.h>
 #include <asm/smp_plat.h>
-#include <asm/hardware/cache-l2x0.h>
 
 /* Interrupt Controller Registers Map */
 #define ARMADA_370_XP_INT_SET_MASK_OFFS		(0x48)
@@ -292,7 +291,4 @@ static const struct of_device_id mpic_of_match[] __initconst = {
 void __init armada_370_xp_init_irq(void)
 {
 	of_irq_init(mpic_of_match);
-#ifdef CONFIG_CACHE_L2X0
-	l2x0_of_init(0, ~0UL);
-#endif
 }
-- 
1.7.9.5



From thomas.petazzoni at free-electrons.com  Tue Apr  9 17:26:15 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Tue,  9 Apr 2013 23:26:15 +0200
Subject: [PATCHv1 2/5] irqchip: move IRQ driver for Armada 370/XP
In-Reply-To: <1365542778-27959-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1365542778-27959-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1365542778-27959-3-git-send-email-thomas.petazzoni@free-electrons.com>

When the Marvell Armada 370/XP support was included in the kernel, the
drivers/irqchip/ directory didn't exist and the minimal infrastructure
in it also didn't exist. Now that we have those things in place, we
move the Armada 370/XP IRQ controller driver from
arch/arm/mach-mvebu/irq-armada-370-xp.c to
drivers/irqchip/irq-armada-370-xp.c.

Note in order to reduce code movement and therefore ease the review of
this patch, we intentionally introduce a forward declaration of
armada_370_xp_handle_irq(). It is in fact not needed because this
handler can now simply be implemented before
armada_370_xp_mpic_of_init(). That will be done in the next commit.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 arch/arm/mach-mvebu/Makefile                       |    2 +-
 arch/arm/mach-mvebu/armada-370-xp.c                |    4 ++--
 drivers/irqchip/Makefile                           |    1 +
 .../irqchip}/irq-armada-370-xp.c                   |   22 ++++++++++----------
 4 files changed, 15 insertions(+), 14 deletions(-)
 rename {arch/arm/mach-mvebu => drivers/irqchip}/irq-armada-370-xp.c (95%)

diff --git a/arch/arm/mach-mvebu/Makefile b/arch/arm/mach-mvebu/Makefile
index da93bcb..c3be068 100644
--- a/arch/arm/mach-mvebu/Makefile
+++ b/arch/arm/mach-mvebu/Makefile
@@ -5,6 +5,6 @@ AFLAGS_coherency_ll.o		:= -Wa,-march=armv7-a
 
 obj-y				 += system-controller.o
 obj-$(CONFIG_MACH_ARMADA_370_XP) += armada-370-xp.o
-obj-$(CONFIG_ARCH_MVEBU)	 += addr-map.o coherency.o coherency_ll.o pmsu.o irq-armada-370-xp.o 
+obj-$(CONFIG_ARCH_MVEBU)	 += addr-map.o coherency.o coherency_ll.o pmsu.o
 obj-$(CONFIG_SMP)                += platsmp.o headsmp.o
 obj-$(CONFIG_HOTPLUG_CPU)        += hotplug.o
diff --git a/arch/arm/mach-mvebu/armada-370-xp.c b/arch/arm/mach-mvebu/armada-370-xp.c
index c1bbfa7..433e8c5 100644
--- a/arch/arm/mach-mvebu/armada-370-xp.c
+++ b/arch/arm/mach-mvebu/armada-370-xp.c
@@ -19,6 +19,7 @@
 #include <linux/time-armada-370-xp.h>
 #include <linux/clk/mvebu.h>
 #include <linux/dma-mapping.h>
+#include <linux/irqchip.h>
 #include <asm/hardware/cache-l2x0.h>
 #include <asm/mach/arch.h>
 #include <asm/mach/map.h>
@@ -77,8 +78,7 @@ DT_MACHINE_START(ARMADA_XP_DT, "Marvell Armada 370/XP (Device Tree)")
 	.init_machine	= armada_370_xp_dt_init,
 	.map_io		= armada_370_xp_map_io,
 	.init_early	= armada_370_xp_init_early,
-	.init_irq	= armada_370_xp_init_irq,
-	.handle_irq     = armada_370_xp_handle_irq,
+	.init_irq	= irqchip_init,
 	.init_time	= armada_370_xp_timer_and_clk_init,
 	.restart	= mvebu_restart,
 	.dt_compat	= armada_370_xp_dt_compat,
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index 98e3b87..dae27a7 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -2,6 +2,7 @@ obj-$(CONFIG_IRQCHIP)			+= irqchip.o
 
 obj-$(CONFIG_ARCH_BCM2835)		+= irq-bcm2835.o
 obj-$(CONFIG_ARCH_EXYNOS)		+= exynos-combiner.o
+obj-$(CONFIG_ARCH_MVEBU)		+= irq-armada-370-xp.o
 obj-$(CONFIG_METAG)			+= irq-metag-ext.o
 obj-$(CONFIG_METAG_PERFCOUNTER_IRQS)	+= irq-metag.o
 obj-$(CONFIG_ARCH_SUNXI)		+= irq-sunxi.o
diff --git a/arch/arm/mach-mvebu/irq-armada-370-xp.c b/drivers/irqchip/irq-armada-370-xp.c
similarity index 95%
rename from arch/arm/mach-mvebu/irq-armada-370-xp.c
rename to drivers/irqchip/irq-armada-370-xp.c
index f6699f3..d20a832 100644
--- a/arch/arm/mach-mvebu/irq-armada-370-xp.c
+++ b/drivers/irqchip/irq-armada-370-xp.c
@@ -25,6 +25,9 @@
 #include <asm/mach/arch.h>
 #include <asm/exception.h>
 #include <asm/smp_plat.h>
+#include <asm/mach/irq.h>
+
+#include "irqchip.h"
 
 /* Interrupt Controller Registers Map */
 #define ARMADA_370_XP_INT_SET_MASK_OFFS		(0x48)
@@ -202,6 +205,9 @@ static struct irq_domain_ops armada_370_xp_mpic_irq_ops = {
 	.xlate = irq_domain_xlate_onecell,
 };
 
+static asmlinkage void __exception_irq_entry
+armada_370_xp_handle_irq(struct pt_regs *regs);
+
 static int __init armada_370_xp_mpic_of_init(struct device_node *node,
 					     struct device_node *parent)
 {
@@ -237,11 +243,13 @@ static int __init armada_370_xp_mpic_of_init(struct device_node *node,
 
 #endif
 
+	set_handle_irq(armada_370_xp_handle_irq);
+
 	return 0;
 }
 
-asmlinkage void __exception_irq_entry armada_370_xp_handle_irq(struct pt_regs
-							       *regs)
+static asmlinkage void __exception_irq_entry
+armada_370_xp_handle_irq(struct pt_regs *regs)
 {
 	u32 irqstat, irqnr;
 
@@ -283,12 +291,4 @@ asmlinkage void __exception_irq_entry armada_370_xp_handle_irq(struct pt_regs
 	} while (1);
 }
 
-static const struct of_device_id mpic_of_match[] __initconst = {
-	{.compatible = "marvell,mpic", .data = armada_370_xp_mpic_of_init},
-	{},
-};
-
-void __init armada_370_xp_init_irq(void)
-{
-	of_irq_init(mpic_of_match);
-}
+IRQCHIP_DECLARE(armada_370_xp_mpic, "marvell,mpic", armada_370_xp_mpic_of_init);
-- 
1.7.9.5



From thomas.petazzoni at free-electrons.com  Tue Apr  9 17:26:16 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Tue,  9 Apr 2013 23:26:16 +0200
Subject: [PATCHv1 3/5] irqchip: armada-370-xp: move IRQ handler to avoid
 forward declaration
In-Reply-To: <1365542778-27959-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1365542778-27959-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1365542778-27959-4-git-send-email-thomas.petazzoni@free-electrons.com>

If we move the IRQ handler function above the initialization function,
we avoid a forward declaration. This wasn't done as part of the
previous commit, in order to increase the readibility of the previous
commit, who was also moving the IRQ controller driver from arch/arm to
drivers/irqchip.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 drivers/irqchip/irq-armada-370-xp.c |   83 +++++++++++++++++------------------
 1 file changed, 40 insertions(+), 43 deletions(-)

diff --git a/drivers/irqchip/irq-armada-370-xp.c b/drivers/irqchip/irq-armada-370-xp.c
index d20a832..1115bf8 100644
--- a/drivers/irqchip/irq-armada-370-xp.c
+++ b/drivers/irqchip/irq-armada-370-xp.c
@@ -206,49 +206,6 @@ static struct irq_domain_ops armada_370_xp_mpic_irq_ops = {
 };
 
 static asmlinkage void __exception_irq_entry
-armada_370_xp_handle_irq(struct pt_regs *regs);
-
-static int __init armada_370_xp_mpic_of_init(struct device_node *node,
-					     struct device_node *parent)
-{
-	u32 control;
-
-	main_int_base = of_iomap(node, 0);
-	per_cpu_int_base = of_iomap(node, 1);
-
-	BUG_ON(!main_int_base);
-	BUG_ON(!per_cpu_int_base);
-
-	control = readl(main_int_base + ARMADA_370_XP_INT_CONTROL);
-
-	armada_370_xp_mpic_domain =
-		irq_domain_add_linear(node, (control >> 2) & 0x3ff,
-				&armada_370_xp_mpic_irq_ops, NULL);
-
-	if (!armada_370_xp_mpic_domain)
-		panic("Unable to add Armada_370_Xp MPIC irq domain (DT)\n");
-
-	irq_set_default_host(armada_370_xp_mpic_domain);
-
-#ifdef CONFIG_SMP
-	armada_xp_mpic_smp_cpu_init();
-
-	/*
-	 * Set the default affinity from all CPUs to the boot cpu.
-	 * This is required since the MPIC doesn't limit several CPUs
-	 * from acknowledging the same interrupt.
-	 */
-	cpumask_clear(irq_default_affinity);
-	cpumask_set_cpu(smp_processor_id(), irq_default_affinity);
-
-#endif
-
-	set_handle_irq(armada_370_xp_handle_irq);
-
-	return 0;
-}
-
-static asmlinkage void __exception_irq_entry
 armada_370_xp_handle_irq(struct pt_regs *regs)
 {
 	u32 irqstat, irqnr;
@@ -291,4 +248,44 @@ armada_370_xp_handle_irq(struct pt_regs *regs)
 	} while (1);
 }
 
+static int __init armada_370_xp_mpic_of_init(struct device_node *node,
+					     struct device_node *parent)
+{
+	u32 control;
+
+	main_int_base = of_iomap(node, 0);
+	per_cpu_int_base = of_iomap(node, 1);
+
+	BUG_ON(!main_int_base);
+	BUG_ON(!per_cpu_int_base);
+
+	control = readl(main_int_base + ARMADA_370_XP_INT_CONTROL);
+
+	armada_370_xp_mpic_domain =
+		irq_domain_add_linear(node, (control >> 2) & 0x3ff,
+				&armada_370_xp_mpic_irq_ops, NULL);
+
+	if (!armada_370_xp_mpic_domain)
+		panic("Unable to add Armada_370_Xp MPIC irq domain (DT)\n");
+
+	irq_set_default_host(armada_370_xp_mpic_domain);
+
+#ifdef CONFIG_SMP
+	armada_xp_mpic_smp_cpu_init();
+
+	/*
+	 * Set the default affinity from all CPUs to the boot cpu.
+	 * This is required since the MPIC doesn't limit several CPUs
+	 * from acknowledging the same interrupt.
+	 */
+	cpumask_clear(irq_default_affinity);
+	cpumask_set_cpu(smp_processor_id(), irq_default_affinity);
+
+#endif
+
+	set_handle_irq(armada_370_xp_handle_irq);
+
+	return 0;
+}
+
 IRQCHIP_DECLARE(armada_370_xp_mpic, "marvell,mpic", armada_370_xp_mpic_of_init);
-- 
1.7.9.5



From thomas.petazzoni at free-electrons.com  Tue Apr  9 17:26:17 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Tue,  9 Apr 2013 23:26:17 +0200
Subject: [PATCHv1 4/5] irqchip: armada-370-xp: slightly cleanup irq controller
 driver
In-Reply-To: <1365542778-27959-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1365542778-27959-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1365542778-27959-5-git-send-email-thomas.petazzoni@free-electrons.com>

In preparation for the introduction of MSI support in the IRQ
controller driver, we clarify the implementation of IPI using
additional defines for the manipulation of doorbells. Just like IPIs
are implemented using doorbells, MSIs will also use doorbells, so it
makes sense to do this preparatory cleanup first.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 drivers/irqchip/irq-armada-370-xp.c |   13 ++++++++-----
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/drivers/irqchip/irq-armada-370-xp.c b/drivers/irqchip/irq-armada-370-xp.c
index 1115bf8..ad1e642 100644
--- a/drivers/irqchip/irq-armada-370-xp.c
+++ b/drivers/irqchip/irq-armada-370-xp.c
@@ -48,7 +48,9 @@
 
 #define ARMADA_370_XP_TIMER0_PER_CPU_IRQ	(5)
 
-#define ACTIVE_DOORBELLS			(8)
+#define IPI_DOORBELL_START                      (0)
+#define IPI_DOORBELL_END                        (8)
+#define IPI_DOORBELL_MASK                       0xFF
 
 static DEFINE_RAW_SPINLOCK(irq_controller_lock);
 
@@ -192,7 +194,7 @@ void armada_xp_mpic_smp_cpu_init(void)
 	writel(0, per_cpu_int_base + ARMADA_370_XP_IN_DRBEL_CAUSE_OFFS);
 
 	/* Enable first 8 IPIs */
-	writel((1 << ACTIVE_DOORBELLS) - 1, per_cpu_int_base +
+	writel(IPI_DOORBELL_MASK, per_cpu_int_base +
 		ARMADA_370_XP_IN_DRBEL_MSK_OFFS);
 
 	/* Unmask IPI interrupt */
@@ -231,13 +233,14 @@ armada_370_xp_handle_irq(struct pt_regs *regs)
 
 			ipimask = readl_relaxed(per_cpu_int_base +
 						ARMADA_370_XP_IN_DRBEL_CAUSE_OFFS)
-				& 0xFF;
+				& IPI_DOORBELL_MASK;
 
-			writel(0x0, per_cpu_int_base +
+			writel(~IPI_DOORBELL_MASK, per_cpu_int_base +
 				ARMADA_370_XP_IN_DRBEL_CAUSE_OFFS);
 
 			/* Handle all pending doorbells */
-			for (ipinr = 0; ipinr < ACTIVE_DOORBELLS; ipinr++) {
+			for (ipinr = IPI_DOORBELL_START;
+			     ipinr < IPI_DOORBELL_END; ipinr++) {
 				if (ipimask & (0x1 << ipinr))
 					handle_IPI(ipinr, regs);
 			}
-- 
1.7.9.5



From thomas.petazzoni at free-electrons.com  Tue Apr  9 17:26:18 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Tue,  9 Apr 2013 23:26:18 +0200
Subject: [PATCHv1 5/5] ARM: mvebu: do not duplicate the mpic alias
In-Reply-To: <1365542778-27959-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1365542778-27959-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1365542778-27959-6-git-send-email-thomas.petazzoni@free-electrons.com>

The mpic alias is already defined in the common armada-370-xp.dtsi, so
there's no need to repeat it at the armada-xp.dtsi and armada-370.dtsi
level.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 arch/arm/boot/dts/armada-370.dtsi |    2 +-
 arch/arm/boot/dts/armada-xp.dtsi  |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/armada-370.dtsi b/arch/arm/boot/dts/armada-370.dtsi
index a195deb..cede6a4 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -33,7 +33,7 @@
 		gpio2 = &gpio2;
 	};
 
-	mpic: interrupt-controller at d0020000 {
+	interrupt-controller at d0020000 {
 	      reg = <0xd0020a00 0x1d0>,
 		    <0xd0021870 0x58>;
 	};
diff --git a/arch/arm/boot/dts/armada-xp.dtsi b/arch/arm/boot/dts/armada-xp.dtsi
index ca00d83..2fed73b 100644
--- a/arch/arm/boot/dts/armada-xp.dtsi
+++ b/arch/arm/boot/dts/armada-xp.dtsi
@@ -29,7 +29,7 @@
 		wt-override;
 	};
 
-	mpic: interrupt-controller at d0020000 {
+	interrupt-controller at d0020000 {
 	      reg = <0xd0020a00 0x2d0>,
 		    <0xd0021070 0x58>;
 	};
-- 
1.7.9.5



From dianders at chromium.org  Tue Apr  9 17:34:30 2013
From: dianders at chromium.org (Doug Anderson)
Date: Tue,  9 Apr 2013 14:34:30 -0700
Subject: [PATCH v5 3/3] ARM: dts: Add sbs-battery for exynos5250-snow
In-Reply-To: <1365543270-10736-1-git-send-email-dianders@chromium.org>
References: <1363192583-26363-1-git-send-email-dianders@chromium.org>
 <1365543270-10736-1-git-send-email-dianders@chromium.org>
Message-ID: <1365543270-10736-3-git-send-email-dianders@chromium.org>

Now that we have i2c-arbitrator in place on bus 4 we can add the
sbs-battery driver.  Future devices will be added onto bus 4 once
drivers are in good shape.

Signed-off-by: Doug Anderson <dianders at chromium.org>
---
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 arch/arm/boot/dts/exynos5250-snow.dts | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5250-snow.dts b/arch/arm/boot/dts/exynos5250-snow.dts
index fa85f58..c115143 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -66,6 +66,12 @@
 			reg = <0>;
 			#address-cells = <1>;
 			#size-cells = <0>;
+
+			battery: sbs-battery at b {
+				compatible = "sbs,sbs-battery";
+				reg = <0xb>;
+				sbs,poll-retry-count = <1>;
+			};
 		};
 	};
 
-- 
1.8.1.3



From dianders at chromium.org  Tue Apr  9 17:34:29 2013
From: dianders at chromium.org (Doug Anderson)
Date: Tue,  9 Apr 2013 14:34:29 -0700
Subject: [PATCH v5 2/3] ARM: dts: Add i2c-arbitrator bus for exynos5250-snow
In-Reply-To: <1365543270-10736-1-git-send-email-dianders@chromium.org>
References: <1363192583-26363-1-git-send-email-dianders@chromium.org>
 <1365543270-10736-1-git-send-email-dianders@chromium.org>
Message-ID: <1365543270-10736-2-git-send-email-dianders@chromium.org>

We need to use the i2c-arbitrator to talk to any of the devices on i2c
bus 4 on exynos5250-snow so that we don't confuse the embedded
controller (EC).  Add the i2c-arbitrator to the device tree.  As we
add future devices (keyboard, sbs, tps65090) we'll add them on top of
this.

The arbitrated bus is numbered 104 simply as a convenience to make it
easier for people poking around to guess that it might have something
to do with the physical bus 4.

The addition is split between the cros5250-common and the snow device
tree file since not all cros5250-class devices use arbitration.

Signed-off-by: Doug Anderson <dianders at chromium.org>
---
Changes in v5:
- Adjust bindings as per Wolfram Sang.

Changes in v4:
- Changed mux gpio syntax to work atop Thomas's "ARM: dts: add pin
  state information in client nodes for Exynos5 platforms"; avoid
  adding gpios property to i2c at 12CA0000 for the same reason.

Changes in v3: None
Changes in v2:
- Use new device tree property names / compatible string.
- Include that the GPIOs for arbitration are active low.

 arch/arm/boot/dts/cros5250-common.dtsi |  3 ++-
 arch/arm/boot/dts/exynos5250-snow.dts  | 25 +++++++++++++++++++++++++
 2 files changed, 27 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/cros5250-common.dtsi b/arch/arm/boot/dts/cros5250-common.dtsi
index 8a5b3a6..0a61bbb 100644
--- a/arch/arm/boot/dts/cros5250-common.dtsi
+++ b/arch/arm/boot/dts/cros5250-common.dtsi
@@ -193,7 +193,8 @@
 	};
 
 	i2c at 12CA0000 {
-		status = "disabled";
+		samsung,i2c-sda-delay = <100>;
+		samsung,i2c-max-bus-freq = <66000>;
 	};
 
 	i2c at 12CB0000 {
diff --git a/arch/arm/boot/dts/exynos5250-snow.dts b/arch/arm/boot/dts/exynos5250-snow.dts
index 581ffae..fa85f58 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -16,6 +16,10 @@
 	model = "Google Snow";
 	compatible = "google,snow", "samsung,exynos5250";
 
+	aliases {
+		i2c104 = &i2c_104;
+	};
+
 	pinctrl at 11400000 {
 		sd3_clk: sd3-clk {
 			samsung,pin-drv = <0>;
@@ -44,6 +48,27 @@
 		};
 	};
 
+	i2c-arbitrator {
+		compatible = "i2c-arb-gpio-challenge";
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		i2c-parent = <&{/i2c at 12CA0000}>;
+
+		our-claim-gpio = <&gpf0 3 1>;
+		their-claim-gpios = <&gpe0 4 1>;
+		slew-delay-us = <10>;
+		wait-retry-us = <3000>;
+		wait-free-us = <50000>;
+
+		/* Use ID 104 as a hint that we're on physical bus 4 */
+		i2c_104: i2c at 0 {
+			reg = <0>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+	};
+
 	/*
 	 * On Snow we've got SIP WiFi and so can keep drive strengths low to
 	 * reduce EMI.
-- 
1.8.1.3



From robherring2 at gmail.com  Tue Apr  9 17:43:48 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Tue, 9 Apr 2013 16:43:48 -0500
Subject: [GIT PULL 08/10] secure-exynos for v3.10
In-Reply-To: <51630A36.6030505@samsung.com>
References: <51630A36.6030505@samsung.com>
Message-ID: <CAL_JsqJLVae44Sr2qf0=YE0DokkeetHFnyFEMKhYpY8sv58Mjw@mail.gmail.com>

On Mon, Apr 8, 2013 at 1:19 PM, Kukjin Kim <kgene.kim at samsung.com> wrote:
> The following changes since commit da821eb7d42935b0f7056d98c75fd1150f6636f4:
>
>   Merge commit 'v3.9-rc5' into next/clk-exynos (2013-04-09 01:10:13 +0900)
>
> are available in the git repository at:
>
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
> tags/secure-exynos-for-v3.10
>
> for you to fetch changes up to beddf63fc8e01f06799bd6d7a2dd879885bbc9c6:
>
>   ARM: EXYNOS: Add secure firmware support to secondary CPU bring-up
> (2013-04-09 01:52:30 +0900)
>
> ----------------------------------------------------------------
> add support secure firmware for exynos
>
> ----------------------------------------------------------------
> Tomasz Figa (5):
>       ARM: Add interface for registering and calling firmware-specific
> operations

I missed the original series, but looking at this patch now I'm not
convinced this is all that generic despite the name. Should PSCI be
using this for example?

Also, a comment from Barry Song that "firmware_ops" is too generic for
global name was not addressed.

Rob

>       ARM: EXYNOS: Add support for secure monitor calls
>       ARM: EXYNOS: Add support for Exynos secure firmware
>       ARM: EXYNOS: Add IO mapping for non-secure SYSRAM.
>       ARM: EXYNOS: Add secure firmware support to secondary CPU bring-up
>
>  Documentation/arm/firmware.txt                     | 88
> ++++++++++++++++++++++
>  .../devicetree/bindings/arm/samsung-boards.txt     | 10 +++
>  arch/arm/common/Makefile                           |  2 +
>  arch/arm/common/firmware.c                         | 18 +++++
>  arch/arm/include/asm/firmware.h                    | 66 ++++++++++++++++
>  arch/arm/mach-exynos/Makefile                      |  6 ++
>  arch/arm/mach-exynos/common.c                      | 35 +++++++++
>  arch/arm/mach-exynos/common.h                      |  2 +
>  arch/arm/mach-exynos/exynos-smc.S                  | 22 ++++++
>  arch/arm/mach-exynos/firmware.c                    | 70 +++++++++++++++++
>  arch/arm/mach-exynos/include/mach/map.h            |  3 +
>  arch/arm/mach-exynos/mach-exynos4-dt.c             |  1 +
>  arch/arm/mach-exynos/platsmp.c                     | 32 ++++++--
>  arch/arm/mach-exynos/smc.h                         | 31 ++++++++
>  arch/arm/plat-samsung/include/plat/map-s5p.h       |  1 +
>  15 files changed, 382 insertions(+), 5 deletions(-)
>  create mode 100644 Documentation/arm/firmware.txt
>  create mode 100644 arch/arm/common/firmware.c
>  create mode 100644 arch/arm/include/asm/firmware.h
>  create mode 100644 arch/arm/mach-exynos/exynos-smc.S
>  create mode 100644 arch/arm/mach-exynos/firmware.c
>  create mode 100644 arch/arm/mach-exynos/smc.h
>
> --
> Thanks.
>
> Best regards,
> Kgene.
> --
> Kukjin Kim <kgene.kim at samsung.com>, Senior Engineer,
> SW Solution Development Team, Samsung Electronics Co., Ltd.
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From khilman at linaro.org  Tue Apr  9 17:47:16 2013
From: khilman at linaro.org (Kevin Hilman)
Date: Tue, 09 Apr 2013 14:47:16 -0700
Subject: [GIT PULL 2/5] omap pm clean-up for v3.10 merge window
In-Reply-To: <5164823B.8070301@linaro.org> (Daniel Lezcano's message of "Tue, 
 09 Apr 2013 23:03:55 +0200")
References: <0MarPy-1U9XGk2D8s-00Ks1o@mx.kundenserver.de>
 <201304091652.28385.arnd@arndb.de> <87vc7virqz.fsf@linaro.org>
 <20130409165633.GN10155@atomide.com> <874nffip2d.fsf@linaro.org>
 <5164823B.8070301@linaro.org>
Message-ID: <87mwt71imz.fsf@linaro.org>

Daniel Lezcano <daniel.lezcano at linaro.org> writes:

[...]

>>>>>>
>>>>>> PM cleanup to prepare for omap5 PM via Kevin Hilman <khilman at linaro.org>:
>>>>>>
>>>>>> OMAP3/4 CPUidle cleanups for v3.10
>>>>>
>>>>> Adding Daniel and Rafael to Cc.
>
> Kevin,
>
> I just want to point you this patch:
>
> https://git.linaro.org/gitweb?p=people/dlezcano/cpuidle-next.git;a=commit;h=e03a37fdf942a25154ccb5539524afd336f130bb
>
> I did not yet send it to Rafael.

I haven't seen that one posted anywhere so it's not in my queue, and
probably too late for v3.10.

Once it's posted, I'll queue it up, and we can maybe get it in for
v3.10-rc.

Kevin




From swarren at wwwdotorg.org  Tue Apr  9 17:49:03 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Tue, 09 Apr 2013 15:49:03 -0600
Subject: [GIT PULL 7/8] ARM: tegra: multi-platform conversion
In-Reply-To: <201304092201.18950.arnd@arndb.de>
References: <1365181426-11547-1-git-send-email-swarren@wwwdotorg.org>
 <1365181426-11547-7-git-send-email-swarren@wwwdotorg.org>
 <201304091659.08376.arnd@arndb.de> <201304092201.18950.arnd@arndb.de>
Message-ID: <51648CCF.80902@wwwdotorg.org>

On 04/09/2013 02:01 PM, Arnd Bergmann wrote:
> On Tuesday 09 April 2013, Arnd Bergmann wrote:
>> On Friday 05 April 2013, Stephen Warren wrote:
>>> This branch converts Tegra to support multi-platform/single-zImage.
> 
>> I had to reorder the branches in arm-soc to avoid starting a
>> next/multiplatform2 branch, but I saw nothing that prevents us from
>> having multiplatform after soc.
> 
> I've applied this patch on top.
...
> Subject: [PATCH] ARM: tegra: build assembly files with -march=armv7-a
> 
> The tegra assembly files are written for ARMv7 and are not compatible
> with ARMv6, which leads to build warnings when compiling a dual
> ARMv6/v7 kernel. Since this code is only ever run on Tegra ARMv7
> hardware, we can tell the assembler which architecture level to
> use.

Ah yes, I hit that problem too, but wasn't sure how to solve it. The
patch below looks good. Now I must go try a combo bcm2835+Tegra kernel
on both devices...


From daniel.lezcano at linaro.org  Tue Apr  9 17:52:29 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Tue, 09 Apr 2013 23:52:29 +0200
Subject: [GIT PULL 2/5] omap pm clean-up for v3.10 merge window
In-Reply-To: <87mwt71imz.fsf@linaro.org>
References: <0MarPy-1U9XGk2D8s-00Ks1o@mx.kundenserver.de>
 <201304091652.28385.arnd@arndb.de> <87vc7virqz.fsf@linaro.org>
 <20130409165633.GN10155@atomide.com> <874nffip2d.fsf@linaro.org>
 <5164823B.8070301@linaro.org> <87mwt71imz.fsf@linaro.org>
Message-ID: <51648D9D.5000204@linaro.org>

On 04/09/2013 11:47 PM, Kevin Hilman wrote:
> Daniel Lezcano <daniel.lezcano at linaro.org> writes:
> 
> [...]
> 
>>>>>>>
>>>>>>> PM cleanup to prepare for omap5 PM via Kevin Hilman <khilman at linaro.org>:
>>>>>>>
>>>>>>> OMAP3/4 CPUidle cleanups for v3.10
>>>>>>
>>>>>> Adding Daniel and Rafael to Cc.
>>
>> Kevin,
>>
>> I just want to point you this patch:
>>
>> https://git.linaro.org/gitweb?p=people/dlezcano/cpuidle-next.git;a=commit;h=e03a37fdf942a25154ccb5539524afd336f130bb
>>
>> I did not yet send it to Rafael.
> 
> I haven't seen that one posted anywhere so it's not in my queue, and
> probably too late for v3.10.
> 
> Once it's posted, I'll queue it up, and we can maybe get it in for
> v3.10-rc.

Yes, I just did the fix very recently. It was just a head up. I will
send it to Rafael as soon as the 'bleeding edge' branch is merged with
'linux-next'.


-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From nm at ti.com  Tue Apr  9 17:54:19 2013
From: nm at ti.com (Nishanth Menon)
Date: Tue, 9 Apr 2013 16:54:19 -0500
Subject: [RFC][PATCH 1/2] ARM: OMAP4: clock: Add device tree support for
 AUXCLKs
In-Reply-To: <20130409204900.GA8815@kahuna>
References: <1363703220-4777-2-git-send-email-rogerq@ti.com>
 <20130403234242.GE10155@atomide.com> <515D2D30.3000306@ti.com>
 <20130404164137.GH10155@atomide.com> <515EA9E3.1010409@ti.com>
 <20130405155851.GA10155@atomide.com> <5163E589.1040809@ti.com>
 <20130409164928.GL10155@atomide.com>
 <20130409174319.GP10155@atomide.com> <20130409204900.GA8815@kahuna>
Message-ID: <20130409215419.GA13731@kahuna>

On 15:49-20130409, Nishanth Menon wrote:
> On 10:43-20130409, Tony Lindgren wrote:
> > * Tony Lindgren <tony at atomide.com> [130409 09:54]:
> > > * Roger Quadros <rogerq at ti.com> [130409 03:00]:
> > > > On 04/05/2013 06:58 PM, Tony Lindgren wrote:
> > > > > 
> > > > > Can't you just use the clock name there to get it?
> > > > 
> > > > In device tree we don't pass around clock names. You can either get
> > > > a phandle or an index to the clock.
> > > > 
> > > > e.g. Documentation/devicetree/bindings/clock/imx31-clock.txt
> > > 
> > > Yes I understand that. But the driver/clock/omap driver can just
> > > remap the DT device initially so the board specific clock is
> > > found from the clock alias table. Basically initially a passthrough
> > > driver that can be enhanced to parse DT clock bindings and load
> > > data from /lib/firmware.
> > 
> > Actually probably the driver/clock/omap can even do even less
> > initially. There probably even no need to remap clocks there.
> > 
> > As long as the DT clock driver understands that a board specific
> > auxclk is specified in the DT it can just call clk_add_alias() so
> > the driver will get the right auxclk from cclock44xx_data.c.
> > 
> > Then other features can be added later on like to allocate a
> > clock entirely based on the binding etc.
> I did try to have an implementation for cpufreq using clock nodes.
> unfortunately, device tree wont let me have arguments of strings :(
> So, I am unable to do clock = <&clk mpu_dpll>;
> instead, I am forced to do clock = <&clk 249>;
> 
> Here is an attempt on beagleXM - adds every clock node to the list.
> Tons of un-necessary prints added to give an idea - see log:
> http://pastebin.com/F9A2zSTr
> 
> Would an cleaned up version be good enough as a step #1 of transition?
> 
Approach #2:
Here is yet another revision -> here I am trying to avoid the risk of
folks messing up indexing. for example: using an older DTB with newer
kernel, clocks being inserted into existing list etc. to prevent these,
we add an "DT_ID" for omap clock nodes, and use it to uniquely identify
the clock node. We try to minimize(not avoidable with integer indexing)
mistakes during development/productization.

>From 2b576affdc6f6bf0b51ebf9b85ef4319357a7994 Mon Sep 17 00:00:00 2001
From: Nishanth Menon <nm at ti.com>
Date: Tue, 26 Mar 2013 10:23:27 +0000
Subject: [RFC PATCH V2] OMAP: add devicetree support for clock nodes.(rev 2)

Dummy patch based on Roger's original idea
this time have lesser possibiltiy of screwing up indices. instead
use a specific integer ID to uniquely (TI SoC wide) identify an clock.
on the flip side, we do not all make clock nodes to be accesible from DT
clock indexing.

Nyet-Signed-off-by: Nishanth Menon <nm at ti.com>
---
 .../devicetree/bindings/clock/ti,clock.txt         |   48 +++++++++++
 arch/arm/boot/dts/omap3.dtsi                       |    5 ++
 arch/arm/boot/dts/omap34xx.dtsi                    |    2 +
 arch/arm/boot/dts/omap4.dtsi                       |    5 ++
 arch/arm/boot/dts/omap443x.dtsi                    |    2 +
 arch/arm/mach-omap2/cclock3xxx_data.c              |    5 +-
 arch/arm/mach-omap2/cclock44xx_data.c              |    5 +-
 arch/arm/mach-omap2/clock.h                        |   12 +++
 arch/arm/mach-omap2/pm.c                           |   11 ++-
 drivers/clk/Kconfig                                |    6 ++
 drivers/clk/Makefile                               |    2 +
 drivers/clk/ti.c                                   |   85 ++++++++++++++++++++
 include/linux/clk/ti.h                             |   30 +++++++
 13 files changed, 211 insertions(+), 7 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/clock/ti,clock.txt
 create mode 100644 drivers/clk/ti.c
 create mode 100644 include/linux/clk/ti.h

diff --git a/Documentation/devicetree/bindings/clock/ti,clock.txt b/Documentation/devicetree/bindings/clock/ti,clock.txt
new file mode 100644
index 0000000..53c947c
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/ti,clock.txt
@@ -0,0 +1,48 @@
+* Clock bindings for Texas Instruments clocks
+
+Required properties:
+- compatible: Should be "ti,clock"
+- #clock-cells: Should be <1>
+
+The clock consumer should specify the desired clock by having the clock
+ID in its "clocks" phandle cell.  The following is a list of ID reservations
+across TI SoCs
+
+       Clock           ID
+       ------------------
+       cpu clock	1
+
+The definition is used by SoC clock data using CLKDT() macro
+(example of OMAP2+).
+
+Example Steps:
+/* step 1: definiting an SoC nodes compatible with ti clocks -skip if already done */
+clks: clocks {
+	compatible = "ti,clock";
+	#clock-cells = <1>;
+};
+
+/* step 2: Modify the bindings documentation to reserve an ID */
+	auxclk0_ck      2
+	auxclk1_ck      3
+	auxclk2_ck      4
+	auxclk3_ck      5
+	auxclk4_ck      6
+	auxclk5_ck      7
+etc. use an unique number not conflicting with previous reservations.
+WARNING: DONOT insert values - this breaks backward compatibility.
+/* Step 3: replace in clock data file */
+	CLK(NULL,	"auxclk0_ck",			&auxclk0_ck,	CK_443X),
+with
+	CLKDT(2, NULL,	"auxclk0_ck",			&auxclk0_ck,	CK_443X),
+
+/* step 4: in device tree entry, now we can use index 2 to uniquely identify auxclk0 clock */
+
+hsusb1_phy: hsusb1_phy {
+	compatible = "usb-nop-xceiv";
+	reset-supply = <&hsusb1_reset>;
+	clocks = <&aux_clks 2>;
+	clock-names = "main_clk";
+	clock-frequency = <19200000>;
+};
+
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 3344f05..a08990d 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -73,6 +73,11 @@
 			ti,hwmods = "counter_32k";
 		};
 
+		clks: clocks {
+			compatible = "ti,clock";
+			#clock-cells = <1>;
+		};
+
 		intc: interrupt-controller at 48200000 {
 			compatible = "ti,omap2-intc";
 			interrupt-controller;
diff --git a/arch/arm/boot/dts/omap34xx.dtsi b/arch/arm/boot/dts/omap34xx.dtsi
index 75ed4ae..de59fb8 100644
--- a/arch/arm/boot/dts/omap34xx.dtsi
+++ b/arch/arm/boot/dts/omap34xx.dtsi
@@ -23,6 +23,8 @@
 				600000  1350000
 			>;
 			clock-latency = <300000>; /* From legacy driver */
+			clocks = <&clks 1>;
+			clock-names = "cpu";
 		};
 	};
 };
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 3329140..ad18d6a 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -106,6 +106,11 @@
 			ti,hwmods = "counter_32k";
 		};
 
+		clks: clocks {
+			compatible = "ti,clock";
+			#clock-cells = <1>;
+		};
+
 		omap4_pmx_core: pinmux at 4a100040 {
 			compatible = "ti,omap4-padconf", "pinctrl-single";
 			reg = <0x4a100040 0x0196>;
diff --git a/arch/arm/boot/dts/omap443x.dtsi b/arch/arm/boot/dts/omap443x.dtsi
index cccf39a..5bfc02b 100644
--- a/arch/arm/boot/dts/omap443x.dtsi
+++ b/arch/arm/boot/dts/omap443x.dtsi
@@ -22,6 +22,8 @@
 				1008000 1375000
 			>;
 			clock-latency = <300000>; /* From legacy driver */
+			clocks = <&clks 1>;
+			clock-names = "cpu";
 		};
 	};
 };
diff --git a/arch/arm/mach-omap2/cclock3xxx_data.c b/arch/arm/mach-omap2/cclock3xxx_data.c
index 4579c3c..2f2932b 100644
--- a/arch/arm/mach-omap2/cclock3xxx_data.c
+++ b/arch/arm/mach-omap2/cclock3xxx_data.c
@@ -22,6 +22,7 @@
 #include <linux/clk-private.h>
 #include <linux/list.h>
 #include <linux/io.h>
+#include <linux/clk/ti.h>
 
 #include "soc.h"
 #include "iomap.h"
@@ -3501,7 +3502,7 @@ static struct omap_clk omap3xxx_clks[] = {
 	CLK(NULL,	"uart4_ick",	&uart4_ick_am35xx,	CK_AM35XX),
 	CLK(NULL,	"timer_32k_ck",	&omap_32k_fck,  CK_3XXX),
 	CLK(NULL,	"timer_sys_ck",	&sys_ck,	CK_3XXX),
-	CLK(NULL,	"cpufreq_ck",	&dpll1_ck,	CK_3XXX),
+	CLKDT(1, NULL,	"cpufreq_ck",	&dpll1_ck,	CK_3XXX),
 };
 
 static const char *enable_init_clks[] = {
@@ -3574,7 +3575,7 @@ int __init omap3xxx_clk_init(void)
 	for (c = omap3xxx_clks; c < omap3xxx_clks + ARRAY_SIZE(omap3xxx_clks);
 	     c++)
 		if (c->cpu & cpu_clkflg) {
-			clkdev_add(&c->lk);
+			ti_clk_node_add(&c->lk, c->dt_clkid);
 			if (!__clk_init(NULL, c->lk.clk))
 				omap2_init_clk_hw_omap_clocks(c->lk.clk);
 		}
diff --git a/arch/arm/mach-omap2/cclock44xx_data.c b/arch/arm/mach-omap2/cclock44xx_data.c
index 0c6834a..74d4e8c 100644
--- a/arch/arm/mach-omap2/cclock44xx_data.c
+++ b/arch/arm/mach-omap2/cclock44xx_data.c
@@ -27,6 +27,7 @@
 #include <linux/clk-private.h>
 #include <linux/clkdev.h>
 #include <linux/io.h>
+#include <linux/clk/ti.h>
 
 #include "soc.h"
 #include "iomap.h"
@@ -1672,7 +1673,7 @@ static struct omap_clk omap44xx_clks[] = {
 	CLK("4013a000.timer",	"timer_sys_ck",	&syc_clk_div_ck,	CK_443X),
 	CLK("4013c000.timer",	"timer_sys_ck",	&syc_clk_div_ck,	CK_443X),
 	CLK("4013e000.timer",	"timer_sys_ck",	&syc_clk_div_ck,	CK_443X),
-	CLK(NULL,	"cpufreq_ck",	&dpll_mpu_ck,	CK_443X),
+	CLKDT(1, NULL,	"cpufreq_ck",	&dpll_mpu_ck,	CK_443X),
 };
 
 int __init omap4xxx_clk_init(void)
@@ -1697,7 +1698,7 @@ int __init omap4xxx_clk_init(void)
 	for (c = omap44xx_clks; c < omap44xx_clks + ARRAY_SIZE(omap44xx_clks);
 									c++) {
 		if (c->cpu & cpu_clkflg) {
-			clkdev_add(&c->lk);
+			ti_clk_node_add(&c->lk, c->dt_clkid);
 			if (!__clk_init(NULL, c->lk.clk))
 				omap2_init_clk_hw_omap_clocks(c->lk.clk);
 		}
diff --git a/arch/arm/mach-omap2/clock.h b/arch/arm/mach-omap2/clock.h
index 60ddd86..9a7c95b 100644
--- a/arch/arm/mach-omap2/clock.h
+++ b/arch/arm/mach-omap2/clock.h
@@ -23,10 +23,22 @@
 #include <linux/clk-provider.h>
 
 struct omap_clk {
+	u16				dt_clkid;
 	u16				cpu;
 	struct clk_lookup		lk;
 };
 
+#define CLKDT(id, dev, con, ck, cp)	\
+	{				\
+		.dt_clkid = id,		\
+		.cpu = cp,		\
+		.lk = {			\
+			.dev_id = dev,	\
+			.con_id = con,	\
+			.clk = ck,	\
+		},			\
+	}
+
 #define CLK(dev, con, ck, cp)		\
 	{				\
 		 .cpu = cp,		\
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index a47e6ee..03c6e48 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -55,6 +55,12 @@ config COMMON_CLK_MAX77686
 	---help---
 	  This driver supports Maxim 77686 crystal oscillator clock. 
 
+config COMMON_CLK_TI
+	tristate "Clock driver for TI SoCs"
+	depends on ARCH_OMAP && OF
+	---help---
+	  Fill me up.. some generic statement ofcourse (lets start with OMAP)
+
 config CLK_TWL6040
 	tristate "External McPDM functional clock from twl6040"
 	depends on TWL6040_CORE
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 300d477..9621815 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -30,6 +30,8 @@ obj-$(CONFIG_ARCH_TEGRA)	+= tegra/
 
 obj-$(CONFIG_X86)		+= x86/
 
+obj-$(CONFIG_COMMON_CLK_TI)	+= ti.o
+
 # Chip specific
 obj-$(CONFIG_COMMON_CLK_WM831X) += clk-wm831x.o
 obj-$(CONFIG_COMMON_CLK_MAX77686) += clk-max77686.o
diff --git a/drivers/clk/ti.c b/drivers/clk/ti.c
new file mode 100644
index 0000000..56b8754
--- /dev/null
+++ b/drivers/clk/ti.c
@@ -0,0 +1,85 @@
+/*
+ * TI Clock node provider
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ *	Nishanth Menon
+ *
+ * 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.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+#include <linux/kernel.h>
+#include <linux/list.h>
+#include <linux/clk-private.h>
+#include <linux/clkdev.h>
+#include <linux/io.h>
+#include <linux/of.h>
+#include <linux/clk/ti.h>
+
+struct ti_clk {
+	struct clk_lookup *lk;
+	u16	id;
+	struct list_head node;
+};
+
+static LIST_HEAD(ti_clk_list);
+
+static struct clk *ti_bypass_clk_get_by_name(struct of_phandle_args *clkspec,
+					     void *data)
+{
+	struct ti_clk *c;
+	int idx = clkspec->args[0];
+
+	list_for_each_entry(c, &ti_clk_list, node) {
+		if (idx == c->id)
+			return c->lk->clk;
+	}
+
+	pr_err("%s: Clock ID %d not found in list\n", __func__, idx);
+	return ERR_PTR(-ENODEV);
+}
+
+static void __init ti_clock_init(struct device_node *node)
+{
+
+	pr_err("%s: START\n", __func__);
+	of_clk_add_provider(node, ti_bypass_clk_get_by_name, NULL);
+	pr_err("%s: END\n", __func__);
+}
+CLK_OF_DECLARE(ti_clk, "ti,clock", ti_clock_init);
+
+void __init ti_clk_node_add(struct clk_lookup *lk, u16 id)
+{
+	struct ti_clk *c;
+	static bool of_added;
+
+	if (lk->dev_id || !id)
+		goto out;
+
+	/* No lists if we did not boot supported by DT entries */
+	if (!of_have_populated_dt())
+		goto out;
+
+	c = kzalloc(sizeof(struct ti_clk), GFP_KERNEL);
+	if (!c) {
+		pr_err("%s: No memory!! cannot add clk node for DT!\n",
+			__func__);
+		/* lets try atleast an regular clock node */
+		goto out;
+	}
+	c->lk = lk;
+	c->id = id;
+	list_add_tail(&c->node, &ti_clk_list);
+	pr_err("%s: Added clock node %s\n", __func__, lk->con_id);
+	if (!of_added) {
+		of_clk_init(NULL);
+		of_added =  true;
+	}
+out:
+	clkdev_add(lk);
+};
diff --git a/include/linux/clk/ti.h b/include/linux/clk/ti.h
new file mode 100644
index 0000000..ebed98a
--- /dev/null
+++ b/include/linux/clk/ti.h
@@ -0,0 +1,30 @@
+/*
+ * TI Clock node provider header
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ *	Nishanth Menon
+ *
+ * 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.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+#ifndef __TI_CLK_H
+#define __TI_CLK_H
+
+#include <linux/clkdev.h>
+
+#ifdef CONFIG_OF
+extern void ti_clk_node_add(struct clk_lookup *lk, u16 id);
+#else
+static inline void ti_clk_node_add(struct clk_lookup *lk, u16 id)
+{
+	clkdev_add(lk);
+}
+#endif /* CONFIG_OF */
+
+#endif	/* __TI_CLK_H */
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index 8d15f9a..6cf95160 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -267,7 +267,12 @@ static void __init omap4_init_voltages(void)
 
 static inline void omap_init_cpufreq(void)
 {
-	struct platform_device_info devinfo = { .name = "omap-cpufreq", };
+	struct platform_device_info devinfo = { };
+
+	if (!of_have_populated_dt())
+		devinfo.name = "omap-cpufreq";
+	else
+		devinfo.name = "cpufreq-cpu0";
 	platform_device_register_full(&devinfo);
 }
 
@@ -301,9 +306,9 @@ int __init omap2_common_pm_late_init(void)
 		/* Smartreflex device init */
 		omap_devinit_smartreflex();
 
-		/* cpufreq dummy device instantiation */
-		omap_init_cpufreq();
 	}
+	/* cpufreq dummy device instantiation */
+	omap_init_cpufreq();
 
 #ifdef CONFIG_SUSPEND
 	suspend_set_ops(&omap_pm_ops);
-- 
1.7.9.5

-- 
Regards,
Nishanth Menon


From tony at atomide.com  Tue Apr  9 18:22:31 2013
From: tony at atomide.com (Tony Lindgren)
Date: Tue, 9 Apr 2013 15:22:31 -0700
Subject: [RFC][PATCH 1/2] ARM: OMAP4: clock: Add device tree support
 for AUXCLKs
In-Reply-To: <20130409204900.GA8815@kahuna>
References: <1363703220-4777-2-git-send-email-rogerq@ti.com>
 <20130403234242.GE10155@atomide.com> <515D2D30.3000306@ti.com>
 <20130404164137.GH10155@atomide.com> <515EA9E3.1010409@ti.com>
 <20130405155851.GA10155@atomide.com> <5163E589.1040809@ti.com>
 <20130409164928.GL10155@atomide.com>
 <20130409174319.GP10155@atomide.com> <20130409204900.GA8815@kahuna>
Message-ID: <20130409222231.GS10155@atomide.com>

* Nishanth Menon <nm at ti.com> [130409 13:53]:
> I did try to have an implementation for cpufreq using clock nodes.
> unfortunately, device tree wont let me have arguments of strings :(
> So, I am unable to do clock = <&clk mpu_dpll>;
> instead, I am forced to do clock = <&clk 249>;

It seems that you should have a separate clock defines for each
clock instead. That way we can later on populate that with
the clock specific data.
 
> Here is an attempt on beagleXM - adds every clock node to the list.
> Tons of un-necessary prints added to give an idea - see log:
> http://pastebin.com/F9A2zSTr
> 
> Would an cleaned up version be good enough as a step #1 of transition?

Well I would make it even simpler initially. Just a standard .dts
clock defined that gets parsed by drivers/clock/ driver that just
calls clk_add_alias(). Then the consumer driver can just do clk_get()
and and the right clock is found, see below.

> --- a/arch/arm/boot/dts/omap3.dtsi
> +++ b/arch/arm/boot/dts/omap3.dtsi
> @@ -73,6 +73,11 @@
>  			ti,hwmods = "counter_32k";
>  		};
>  
> +		clks: clocks {
> +			compatible = "ti,clock";
> +			#clock-cells = <1>;
> +		};
> +
>  		intc: interrupt-controller at 48200000 {
>  			compatible = "ti,omap2-intc";
>  			interrupt-controller;

There should be a separate entry for each clock defined,
like auxclk1 in the USB case assuming the clock being used
is aux clock #1. I doubt that we want to map all the auxclks
as a single clock as they are separate clocks AFAIK.

> --- a/arch/arm/boot/dts/omap34xx.dtsi
> +++ b/arch/arm/boot/dts/omap34xx.dtsi
> @@ -23,6 +23,8 @@
>  				600000  1350000
>  			>;
>  			clock-latency = <300000>; /* From legacy driver */
> +			clocks = <&clks 249>; /* index to cpufreq_ck */
> +			clock-names = "cpu";
>  		};
>  	};
>  };

Then in the consumer driver you would just have:

			clocks = <&auxclk1 0>;

for the USB case, then something else for the cpufreq driver.

> --- a/arch/arm/mach-omap2/cclock3xxx_data.c
> +++ b/arch/arm/mach-omap2/cclock3xxx_data.c
> @@ -22,6 +22,7 @@
>  #include <linux/clk-private.h>
>  #include <linux/list.h>
>  #include <linux/io.h>
> +#include <linux/clk/ti.h>
>  
>  #include "soc.h"
>  #include "iomap.h"
> @@ -3574,7 +3575,7 @@ int __init omap3xxx_clk_init(void)
>  	for (c = omap3xxx_clks; c < omap3xxx_clks + ARRAY_SIZE(omap3xxx_clks);
>  	     c++)
>  		if (c->cpu & cpu_clkflg) {
> -			clkdev_add(&c->lk);
> +			ti_clk_node_add(&c->lk);
>  			if (!__clk_init(NULL, c->lk.clk))
>  				omap2_init_clk_hw_omap_clocks(c->lk.clk);
>  		}

AFAIK no need to tinkering with the clockxxxx_data.c files.

> --- /dev/null
> +++ b/drivers/clk/ti.c
> @@ -0,0 +1,100 @@
> +/*
> + * TI Clock node provider
> + *
> + * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
> + *	Nishanth Menon
> + *
> + * 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.
> + *
> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
> + * kind, whether express or implied; without even the implied warranty
> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +#include <linux/kernel.h>
> +#include <linux/list.h>
> +#include <linux/clk-private.h>
> +#include <linux/clkdev.h>
> +#include <linux/io.h>
> +#include <linux/of.h>
> +#include <linux/clk/ti.h>

Then this can be just a minimal DT device driver that initially just
calls clk_add_alias() so the right clock is found when the driver
does clk_get(). Probably should be drivers/clock/omap/clk.c.

Regards,

Tony



From magnus.damm at gmail.com  Tue Apr  9 18:23:06 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Wed, 10 Apr 2013 07:23:06 +0900
Subject: [PATCH v3] irqchip: renesas-intc-irqpin: DT binding for sense
 bitfield width
In-Reply-To: <Pine.LNX.4.64.1304081002190.29945@axis700.grange>
References: <Pine.LNX.4.64.1304081002190.29945@axis700.grange>
Message-ID: <CANqRtoS7fkYd8iX3yAh7xoTNR39UiquWooUSr8+BjbBSUNozFQ@mail.gmail.com>

Hi Guennadi,

On Mon, Apr 8, 2013 at 5:08 PM, Guennadi Liakhovetski
<g.liakhovetski at gmx.de> wrote:
> Most Renesas irqpin controllers have 4-bit sense fields, however, some
> have different widths. This patch adds a DT binding to optionally
> specify such non-standard values.
>
> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas at gmail.com>
> ---
>
> v3: move the code to a common location, where device configuration
> parameters are retrieved

Thanks for rearranging the code, this looks good to me.

Acked-by: Magnus Damm <damm at opensource.se>

To be clear, I prefer your approach over a per-SoC compatible string.

In general I think a per-SoC compatible string is nice in theory, but
I don't think it is correct to use it to describe a change in a IP
block that just happens to included in the SoC. Instead the version of
the IP block shall be used with the compatible value. In some cases it
may not be easy to retrieve such a version.

The per-SoC compatible string may look good but they come with at
least two drawbacks. Either
1) the driver has to be updated for each new SoC even though the
device IP the driver is handling hasn't changed which leads to
1.1) more need for pointless per-SoC compatible string patches to be
merged and tracked and back ported
and
1.2) less chance of running a standard distro lacking per-SoC
compatible string but has actual code for support
or
2) to ship soon the per-SoC DT will use SoC compatible strings
matching other SoC names which works but is even more confusing.

For the INTC irqpin case I believe this approach with a single
property is the best.

Thanks,

/ magnus


From sergei.shtylyov at cogentembedded.com  Tue Apr  9 18:26:08 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Wed, 10 Apr 2013 02:26:08 +0400
Subject: [PATCH v3 0/9] Reorganize R8A7779/Marzen USB code
Message-ID: <201304100226.08967.sergei.shtylyov@cogentembedded.com>

Hello.

   Here's the set of 9 patches against the Simon Horman's 'renesas.git' repo,
'renesas-next-20130410' tag.  It was created to fix the shortcomings in the
R8A7779/Marzen USB platform code and R8A7779 USB common PHY driver, and so
spans both arch/arm/mach-shmobile/ and drivers/usb/ subtrees (some patches have
to touch both subtrees). The patches were conceived with the complete
bisectability goal in mind.

[1/9] ARM: shmobile: Marzen: move USB EHCI, OHCI, and PHY devices to R8A7779 code
[2/9] ehci-platform: add pre_setup() method to platform data
[3/9] ARM: shmobile: R8A7779: setup EHCI internal buffer
[4/9] rcar-phy: remove EHCI internal buffer setup
[5/9] ARM: shmobile: R8A7779: remove USB PHY 2nd memory resource
[6/9] rcar-phy: correct base address
[7/9] rcar-phy: add platform data
[8/9] ARM: shmobile: Marzen: pass platform data to USB PHY device
[9/9] rcar-phy: handle platform data

   I'm not sure thru which tree this patchset should be merged, however it turns
out that it's too late now to push it thru Felipe Balbi's USB tree for 3.10
(which would have been most convenient probably), and it's probably too late to
merge thru Simon's tree for 3.10 too. So it now have to be postponed to 3.11,
unfortunately...

WBR, Sergei


From magnus.damm at gmail.com  Tue Apr  9 18:27:41 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Wed, 10 Apr 2013 07:27:41 +0900
Subject: [PATCH] ARM: shmobile: Include all 2 GiB of memory on APE6EVM
In-Reply-To: <20130409161410.GA16003@verge.net.au>
References: <20130408014444.18767.64441.sendpatchset@w520>
 <20130409123433.GD15412@verge.net.au>
 <20130409161410.GA16003@verge.net.au>
Message-ID: <CANqRtoTCYVY9Q6-2wUshSxZzXNsUx4xdY+phf2ZyHmwSyj4SRw@mail.gmail.com>

Hi Simon,

On Wed, Apr 10, 2013 at 1:14 AM, Simon Horman <horms at verge.net.au> wrote:
> On Tue, Apr 09, 2013 at 09:34:34PM +0900, Simon Horman wrote:
>> On Mon, Apr 08, 2013 at 10:44:44AM +0900, Magnus Damm wrote:
>> > From: Takashi Yoshii <takashi.yoshii.zj at renesas.com>
>> >
>> > Add 1GiB of DRAM at 0x2_0000_0000
>> >
>> > Signed-off-by: Takashi Yoshii <takashi.yoshii.zj at renesas.com>
>> > Signed-off-by: Magnus Damm <damm at opensource.se>
>>
>> Thanks, queued up in the boards-ape6evm branch.
>
> I have dropped this patch as it appears to prevent
> the board from booting.

Is it possible that LPAE=n and HIGHMEM=y in your particular kernel
configuration?

>From what I can tell HIGHMEM is broken in cases of large amounts of
memory. Try disabling that as a short-term workaround. Then of course
someone needs to track down why the generic code doesn't work as
expected.

Thanks,

/ magnus


From sergei.shtylyov at cogentembedded.com  Tue Apr  9 18:29:28 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Wed, 10 Apr 2013 02:29:28 +0400
Subject: [PATCH v3 1/9] ARM: shmobile: Marzen: move USB EHCI, OHCI,
 and PHY devices to R8A7779 code
Message-ID: <201304100229.29059.sergei.shtylyov@cogentembedded.com>

USB EHCI, OHCI, and common PHY are the SoC devices but are wrongly defined and
registered in the Marzen board file.  Move the data and code to their proper
place in setup-r8a7779.c; while at it, we have to rename 8a7779_late_devices[]
to 8a7779_standard_devices[] -- this seems legitimate since they are registered
from r8a7779_add_standard_devices() anyway.

Note that I'm deliberately changing the USB PHY platform device's 'id' field
from (previously just omitted) 0 to -1 as the device is a single of its kind.

Note also that the board and SoC code have to be in one patch to keep the code
bisectable...

The patch has been tested on the Marzen board.

Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Acked-by: Simon Horman <horms+renesas at verge.net.au>

---
Changes since version 2:
- added a note about testing to the changelog;
- added ACKs from Simon Horman and Kuninori Morimoto.

Changes since the original posting:
- added a note about bisectability to the changelog.

 arch/arm/mach-shmobile/board-marzen.c         |  178 -------------------------
 arch/arm/mach-shmobile/include/mach/r8a7779.h |    1 
 arch/arm/mach-shmobile/setup-r8a7779.c        |  185 +++++++++++++++++++++++++-
 3 files changed, 184 insertions(+), 180 deletions(-)

Index: renesas/arch/arm/mach-shmobile/board-marzen.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/board-marzen.c
+++ renesas/arch/arm/mach-shmobile/board-marzen.c
@@ -36,10 +36,6 @@
 #include <linux/mmc/host.h>
 #include <linux/mmc/sh_mobile_sdhi.h>
 #include <linux/mfd/tmio.h>
-#include <linux/usb/otg.h>
-#include <linux/usb/ehci_pdriver.h>
-#include <linux/usb/ohci_pdriver.h>
-#include <linux/pm_runtime.h>
 #include <mach/hardware.h>
 #include <mach/r8a7779.h>
 #include <mach/common.h>
@@ -149,26 +145,6 @@ static struct platform_device hspi_devic
 	.num_resources	= ARRAY_SIZE(hspi_resources),
 };
 
-/* USB PHY */
-static struct resource usb_phy_resources[] = {
-	[0] = {
-		.start		= 0xffe70000,
-		.end		= 0xffe70900 - 1,
-		.flags		= IORESOURCE_MEM,
-	},
-	[1] = {
-		.start		= 0xfff70000,
-		.end		= 0xfff70900 - 1,
-		.flags		= IORESOURCE_MEM,
-	},
-};
-
-static struct platform_device usb_phy_device = {
-	.name		= "rcar_usb_phy",
-	.resource	= usb_phy_resources,
-	.num_resources	= ARRAY_SIZE(usb_phy_resources),
-};
-
 /* LEDS */
 static struct gpio_led marzen_leds[] = {
 	{
@@ -204,161 +180,9 @@ static struct platform_device *marzen_de
 	&sdhi0_device,
 	&thermal_device,
 	&hspi_device,
-	&usb_phy_device,
 	&leds_device,
 };
 
-/* USB */
-static struct usb_phy *phy;
-static int usb_power_on(struct platform_device *pdev)
-{
-	if (!phy)
-		return -EIO;
-
-	pm_runtime_enable(&pdev->dev);
-	pm_runtime_get_sync(&pdev->dev);
-
-	usb_phy_init(phy);
-
-	return 0;
-}
-
-static void usb_power_off(struct platform_device *pdev)
-{
-	if (!phy)
-		return;
-
-	usb_phy_shutdown(phy);
-
-	pm_runtime_put_sync(&pdev->dev);
-	pm_runtime_disable(&pdev->dev);
-}
-
-static struct usb_ehci_pdata ehcix_pdata = {
-	.power_on	= usb_power_on,
-	.power_off	= usb_power_off,
-	.power_suspend	= usb_power_off,
-};
-
-static struct resource ehci0_resources[] = {
-	[0] = {
-		.start	= 0xffe70000,
-		.end	= 0xffe70400 - 1,
-		.flags	= IORESOURCE_MEM,
-	},
-	[1] = {
-		.start	= gic_iid(0x4c),
-		.flags	= IORESOURCE_IRQ,
-	},
-};
-
-static struct platform_device ehci0_device = {
-	.name	= "ehci-platform",
-	.id	= 0,
-	.dev	= {
-		.dma_mask		= &ehci0_device.dev.coherent_dma_mask,
-		.coherent_dma_mask	= 0xffffffff,
-		.platform_data		= &ehcix_pdata,
-	},
-	.num_resources	= ARRAY_SIZE(ehci0_resources),
-	.resource	= ehci0_resources,
-};
-
-static struct resource ehci1_resources[] = {
-	[0] = {
-		.start	= 0xfff70000,
-		.end	= 0xfff70400 - 1,
-		.flags	= IORESOURCE_MEM,
-	},
-	[1] = {
-		.start	= gic_iid(0x4d),
-		.flags	= IORESOURCE_IRQ,
-	},
-};
-
-static struct platform_device ehci1_device = {
-	.name	= "ehci-platform",
-	.id	= 1,
-	.dev	= {
-		.dma_mask		= &ehci1_device.dev.coherent_dma_mask,
-		.coherent_dma_mask	= 0xffffffff,
-		.platform_data		= &ehcix_pdata,
-	},
-	.num_resources	= ARRAY_SIZE(ehci1_resources),
-	.resource	= ehci1_resources,
-};
-
-static struct usb_ohci_pdata ohcix_pdata = {
-	.power_on	= usb_power_on,
-	.power_off	= usb_power_off,
-	.power_suspend	= usb_power_off,
-};
-
-static struct resource ohci0_resources[] = {
-	[0] = {
-		.start	= 0xffe70400,
-		.end	= 0xffe70800 - 1,
-		.flags	= IORESOURCE_MEM,
-	},
-	[1] = {
-		.start	= gic_iid(0x4c),
-		.flags	= IORESOURCE_IRQ,
-	},
-};
-
-static struct platform_device ohci0_device = {
-	.name	= "ohci-platform",
-	.id	= 0,
-	.dev	= {
-		.dma_mask		= &ohci0_device.dev.coherent_dma_mask,
-		.coherent_dma_mask	= 0xffffffff,
-		.platform_data		= &ohcix_pdata,
-	},
-	.num_resources	= ARRAY_SIZE(ohci0_resources),
-	.resource	= ohci0_resources,
-};
-
-static struct resource ohci1_resources[] = {
-	[0] = {
-		.start	= 0xfff70400,
-		.end	= 0xfff70800 - 1,
-		.flags	= IORESOURCE_MEM,
-	},
-	[1] = {
-		.start	= gic_iid(0x4d),
-		.flags	= IORESOURCE_IRQ,
-	},
-};
-
-static struct platform_device ohci1_device = {
-	.name	= "ohci-platform",
-	.id	= 1,
-	.dev	= {
-		.dma_mask		= &ohci1_device.dev.coherent_dma_mask,
-		.coherent_dma_mask	= 0xffffffff,
-		.platform_data		= &ohcix_pdata,
-	},
-	.num_resources	= ARRAY_SIZE(ohci1_resources),
-	.resource	= ohci1_resources,
-};
-
-static struct platform_device *marzen_late_devices[] __initdata = {
-	&ehci0_device,
-	&ehci1_device,
-	&ohci0_device,
-	&ohci1_device,
-};
-
-void __init marzen_init_late(void)
-{
-	/* get usb phy */
-	phy = usb_get_phy(USB_PHY_TYPE_USB2);
-
-	shmobile_init_late();
-	platform_add_devices(marzen_late_devices,
-			     ARRAY_SIZE(marzen_late_devices));
-}
-
 static const struct pinctrl_map marzen_pinctrl_map[] = {
 	/* HSPI0 */
 	PIN_MAP_MUX_GROUP_DEFAULT("sh-hspi.0", "pfc-r8a7779",
@@ -416,6 +240,6 @@ MACHINE_START(MARZEN, "marzen")
 	.nr_irqs	= NR_IRQS_LEGACY,
 	.init_irq	= r8a7779_init_irq,
 	.init_machine	= marzen_init,
-	.init_late	= marzen_init_late,
+	.init_late	= r8a7779_init_late,
 	.init_time	= r8a7779_earlytimer_init,
 MACHINE_END
Index: renesas/arch/arm/mach-shmobile/include/mach/r8a7779.h
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/include/mach/r8a7779.h
+++ renesas/arch/arm/mach-shmobile/include/mach/r8a7779.h
@@ -33,6 +33,7 @@ extern void r8a7779_add_early_devices(vo
 extern void r8a7779_add_standard_devices(void);
 extern void r8a7779_add_standard_devices_dt(void);
 extern void r8a7779_add_ether_device(struct sh_eth_plat_data *pdata);
+extern void r8a7779_init_late(void);
 extern void r8a7779_clock_init(void);
 extern void r8a7779_pinmux_init(void);
 extern void r8a7779_pm_init(void);
Index: renesas/arch/arm/mach-shmobile/setup-r8a7779.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/setup-r8a7779.c
+++ renesas/arch/arm/mach-shmobile/setup-r8a7779.c
@@ -32,6 +32,10 @@
 #include <linux/sh_intc.h>
 #include <linux/sh_timer.h>
 #include <linux/dma-mapping.h>
+#include <linux/usb/otg.h>
+#include <linux/usb/ehci_pdriver.h>
+#include <linux/usb/ohci_pdriver.h>
+#include <linux/pm_runtime.h>
 #include <mach/hardware.h>
 #include <mach/irqs.h>
 #include <mach/r8a7779.h>
@@ -394,6 +398,162 @@ static struct platform_device sata_devic
 	},
 };
 
+/* USB PHY */
+static struct resource usb_phy_resources[] = {
+	[0] = {
+		.start		= 0xffe70000,
+		.end		= 0xffe70900 - 1,
+		.flags		= IORESOURCE_MEM,
+	},
+	[1] = {
+		.start		= 0xfff70000,
+		.end		= 0xfff70900 - 1,
+		.flags		= IORESOURCE_MEM,
+	},
+};
+
+static struct platform_device usb_phy_device = {
+	.name		= "rcar_usb_phy",
+	.id		= -1,
+	.resource	= usb_phy_resources,
+	.num_resources	= ARRAY_SIZE(usb_phy_resources),
+};
+
+/* USB */
+static struct usb_phy *phy;
+
+static int usb_power_on(struct platform_device *pdev)
+{
+	if (!phy)
+		return -EIO;
+
+	pm_runtime_enable(&pdev->dev);
+	pm_runtime_get_sync(&pdev->dev);
+
+	usb_phy_init(phy);
+
+	return 0;
+}
+
+static void usb_power_off(struct platform_device *pdev)
+{
+	if (!phy)
+		return;
+
+	usb_phy_shutdown(phy);
+
+	pm_runtime_put_sync(&pdev->dev);
+	pm_runtime_disable(&pdev->dev);
+}
+
+static struct usb_ehci_pdata ehcix_pdata = {
+	.power_on	= usb_power_on,
+	.power_off	= usb_power_off,
+	.power_suspend	= usb_power_off,
+};
+
+static struct resource ehci0_resources[] = {
+	[0] = {
+		.start	= 0xffe70000,
+		.end	= 0xffe70400 - 1,
+		.flags	= IORESOURCE_MEM,
+	},
+	[1] = {
+		.start	= gic_iid(0x4c),
+		.flags	= IORESOURCE_IRQ,
+	},
+};
+
+static struct platform_device ehci0_device = {
+	.name	= "ehci-platform",
+	.id	= 0,
+	.dev	= {
+		.dma_mask		= &ehci0_device.dev.coherent_dma_mask,
+		.coherent_dma_mask	= 0xffffffff,
+		.platform_data		= &ehcix_pdata,
+	},
+	.num_resources	= ARRAY_SIZE(ehci0_resources),
+	.resource	= ehci0_resources,
+};
+
+static struct resource ehci1_resources[] = {
+	[0] = {
+		.start	= 0xfff70000,
+		.end	= 0xfff70400 - 1,
+		.flags	= IORESOURCE_MEM,
+	},
+	[1] = {
+		.start	= gic_iid(0x4d),
+		.flags	= IORESOURCE_IRQ,
+	},
+};
+
+static struct platform_device ehci1_device = {
+	.name	= "ehci-platform",
+	.id	= 1,
+	.dev	= {
+		.dma_mask		= &ehci1_device.dev.coherent_dma_mask,
+		.coherent_dma_mask	= 0xffffffff,
+		.platform_data		= &ehcix_pdata,
+	},
+	.num_resources	= ARRAY_SIZE(ehci1_resources),
+	.resource	= ehci1_resources,
+};
+
+static struct usb_ohci_pdata ohcix_pdata = {
+	.power_on	= usb_power_on,
+	.power_off	= usb_power_off,
+	.power_suspend	= usb_power_off,
+};
+
+static struct resource ohci0_resources[] = {
+	[0] = {
+		.start	= 0xffe70400,
+		.end	= 0xffe70800 - 1,
+		.flags	= IORESOURCE_MEM,
+	},
+	[1] = {
+		.start	= gic_iid(0x4c),
+		.flags	= IORESOURCE_IRQ,
+	},
+};
+
+static struct platform_device ohci0_device = {
+	.name	= "ohci-platform",
+	.id	= 0,
+	.dev	= {
+		.dma_mask		= &ohci0_device.dev.coherent_dma_mask,
+		.coherent_dma_mask	= 0xffffffff,
+		.platform_data		= &ohcix_pdata,
+	},
+	.num_resources	= ARRAY_SIZE(ohci0_resources),
+	.resource	= ohci0_resources,
+};
+
+static struct resource ohci1_resources[] = {
+	[0] = {
+		.start	= 0xfff70400,
+		.end	= 0xfff70800 - 1,
+		.flags	= IORESOURCE_MEM,
+	},
+	[1] = {
+		.start	= gic_iid(0x4d),
+		.flags	= IORESOURCE_IRQ,
+	},
+};
+
+static struct platform_device ohci1_device = {
+	.name	= "ohci-platform",
+	.id	= 1,
+	.dev	= {
+		.dma_mask		= &ohci1_device.dev.coherent_dma_mask,
+		.coherent_dma_mask	= 0xffffffff,
+		.platform_data		= &ohcix_pdata,
+	},
+	.num_resources	= ARRAY_SIZE(ohci1_resources),
+	.resource	= ohci1_resources,
+};
+
 /* Ether */
 static struct resource ether_resources[] = {
 	{
@@ -415,9 +575,10 @@ static struct platform_device *r8a7779_d
 	&scif5_device,
 	&tmu00_device,
 	&tmu01_device,
+	&usb_phy_device,
 };
 
-static struct platform_device *r8a7779_late_devices[] __initdata = {
+static struct platform_device *r8a7779_standard_devices[] __initdata = {
 	&i2c0_device,
 	&i2c1_device,
 	&i2c2_device,
@@ -437,8 +598,8 @@ void __init r8a7779_add_standard_devices
 
 	platform_add_devices(r8a7779_devices_dt,
 			    ARRAY_SIZE(r8a7779_devices_dt));
-	platform_add_devices(r8a7779_late_devices,
-			    ARRAY_SIZE(r8a7779_late_devices));
+	platform_add_devices(r8a7779_standard_devices,
+			    ARRAY_SIZE(r8a7779_standard_devices));
 }
 
 void __init r8a7779_add_ether_device(struct sh_eth_plat_data *pdata)
@@ -481,6 +642,23 @@ void __init r8a7779_add_early_devices(vo
 	 */
 }
 
+static struct platform_device *r8a7779_late_devices[] __initdata = {
+	&ehci0_device,
+	&ehci1_device,
+	&ohci0_device,
+	&ohci1_device,
+};
+
+void __init r8a7779_init_late(void)
+{
+	/* get USB PHY */
+	phy = usb_get_phy(USB_PHY_TYPE_USB2);
+
+	shmobile_init_late();
+	platform_add_devices(r8a7779_late_devices,
+			     ARRAY_SIZE(r8a7779_late_devices));
+}
+
 #ifdef CONFIG_USE_OF
 void __init r8a7779_init_delay(void)
 {
@@ -514,6 +692,7 @@ DT_MACHINE_START(R8A7779_DT, "Generic R8
 	.init_irq	= r8a7779_init_irq_dt,
 	.init_machine	= r8a7779_add_standard_devices_dt,
 	.init_time	= shmobile_timer_init,
+	.init_late	= r8a7779_init_late,
 	.dt_compat	= r8a7779_compat_dt,
 MACHINE_END
 #endif /* CONFIG_USE_OF */


From sergei.shtylyov at cogentembedded.com  Tue Apr  9 18:31:48 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Wed, 10 Apr 2013 02:31:48 +0400
Subject: [PATCH v3 3/9] ARM: shmobile: R8A7779: setup EHCI internal buffer
Message-ID: <201304100231.48628.sergei.shtylyov@cogentembedded.com>

Setup the EHCI internal buffer (before EHCI driver has a chance to touch the
registers) using the pre_setup() method in 'struct usb_ehci_pdata'.

The patch has been tested on the Marzen board.

Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Acked-by: Simon Horman <horms+renesas at verge.net.au>

---
Changes since version 2:
- added #include <linux/usb/hcd.h>;
- added a note about testing to the changelog;
- added ACKs from Simon Horman and Kuninori Morimoto.

Changes since the original posting:
- changed from init() platform device method to pre_setup() as per the previous
  patch.

 arch/arm/mach-shmobile/setup-r8a7779.c |   16 ++++++++++++++++
 1 file changed, 16 insertions(+)

Index: renesas/arch/arm/mach-shmobile/setup-r8a7779.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/setup-r8a7779.c
+++ renesas/arch/arm/mach-shmobile/setup-r8a7779.c
@@ -33,6 +33,7 @@
 #include <linux/sh_timer.h>
 #include <linux/dma-mapping.h>
 #include <linux/usb/otg.h>
+#include <linux/usb/hcd.h>
 #include <linux/usb/ehci_pdriver.h>
 #include <linux/usb/ohci_pdriver.h>
 #include <linux/pm_runtime.h>
@@ -446,10 +447,25 @@ static void usb_power_off(struct platfor
 	pm_runtime_disable(&pdev->dev);
 }
 
+static int ehci_init_internal_buffer(struct usb_hcd *hcd)
+{
+	/*
+	 * Below are recommended values from the datasheet;
+	 * see [USB :: Setting of EHCI Internal Buffer].
+	 */
+	/* EHCI IP internal buffer setting */
+	iowrite32(0x00ff0040, hcd->regs + 0x0094);
+	/* EHCI IP internal buffer enable */
+	iowrite32(0x00000001, hcd->regs + 0x009C);
+
+	return 0;
+}
+
 static struct usb_ehci_pdata ehcix_pdata = {
 	.power_on	= usb_power_on,
 	.power_off	= usb_power_off,
 	.power_suspend	= usb_power_off,
+	.pre_setup	= ehci_init_internal_buffer,
 };
 
 static struct resource ehci0_resources[] = {


From sergei.shtylyov at cogentembedded.com  Tue Apr  9 18:32:30 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Wed, 10 Apr 2013 02:32:30 +0400
Subject: [PATCH v3 4/9] rcar-phy: remove EHCI internal buffer setup
Message-ID: <201304100232.30889.sergei.shtylyov@cogentembedded.com>

Now that the EHCI internal  buffer setup is done by the platform code, we  can
remove  such code from this driver as it  never  really belonged here.  We also
no longer need the 2nd memory region now (2nd EHCI controller is simply missing
in e.g. R8A7778 SoC).

The patch has been tested on the Marzen and BOCK-W boards.

Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Acked-by: Simon Horman <horms+renesas at verge.net.au>

---
Changes since version 2:
- added a note about testing to the changelog;
- added ACKs from Simon Horman and Kuninori Morimoto.

Changes since the original posting:
- split R8A7779 SoC file change to a separate patch.

 drivers/usb/phy/rcar-phy.c |   28 ++++------------------------
 1 file changed, 4 insertions(+), 24 deletions(-)

Index: renesas/drivers/usb/phy/rcar-phy.c
===================================================================
--- renesas.orig/drivers/usb/phy/rcar-phy.c
+++ renesas/drivers/usb/phy/rcar-phy.c
@@ -23,8 +23,6 @@
 #define USBEH0		0x080C
 #define USBOH0		0x081C
 #define USBCTL0		0x0858
-#define EIIBC1		0x0094
-#define EIIBC2		0x009C
 
 /* USBPCTRL1 */
 #define PHY_RST		(1 << 2)
@@ -40,7 +38,6 @@ struct rcar_usb_phy_priv {
 	spinlock_t lock;
 
 	void __iomem *reg0;
-	void __iomem *reg1;
 	int counter;
 };
 
@@ -59,7 +56,6 @@ static int rcar_usb_phy_init(struct usb_
 	struct rcar_usb_phy_priv *priv = usb_phy_to_priv(phy);
 	struct device *dev = phy->dev;
 	void __iomem *reg0 = priv->reg0;
-	void __iomem *reg1 = priv->reg1;
 	int i;
 	u32 val;
 	unsigned long flags;
@@ -97,19 +93,6 @@ static int rcar_usb_phy_init(struct usb_
 		iowrite32(0x00000000, (reg0 + USBPCTRL0));
 
 		/*
-		 * EHCI IP internal buffer setting
-		 * EHCI IP internal buffer enable
-		 *
-		 * These are recommended value of a datasheet
-		 * see [USB :: EHCI internal buffer setting]
-		 */
-		iowrite32(0x00ff0040, (reg0 + EIIBC1));
-		iowrite32(0x00ff0040, (reg1 + EIIBC1));
-
-		iowrite32(0x00000001, (reg0 + EIIBC2));
-		iowrite32(0x00000001, (reg1 + EIIBC2));
-
-		/*
 		 * Bus alignment settings
 		 */
 
@@ -145,14 +128,13 @@ static void rcar_usb_phy_shutdown(struct
 static int rcar_usb_phy_probe(struct platform_device *pdev)
 {
 	struct rcar_usb_phy_priv *priv;
-	struct resource *res0, *res1;
+	struct resource *res0;
 	struct device *dev = &pdev->dev;
-	void __iomem *reg0, *reg1;
+	void __iomem *reg0;
 	int ret;
 
 	res0 = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-	res1 = platform_get_resource(pdev, IORESOURCE_MEM, 1);
-	if (!res0 || !res1) {
+	if (!res0) {
 		dev_err(dev, "Not enough platform resources\n");
 		return -EINVAL;
 	}
@@ -164,8 +146,7 @@ static int rcar_usb_phy_probe(struct pla
 	 * this driver can't use devm_request_and_ioremap(dev, res) here
 	 */
 	reg0 = devm_ioremap_nocache(dev, res0->start, resource_size(res0));
-	reg1 = devm_ioremap_nocache(dev, res1->start, resource_size(res1));
-	if (!reg0 || !reg1) {
+	if (!reg0) {
 		dev_err(dev, "ioremap error\n");
 		return -ENOMEM;
 	}
@@ -177,7 +158,6 @@ static int rcar_usb_phy_probe(struct pla
 	}
 
 	priv->reg0		= reg0;
-	priv->reg1		= reg1;
 	priv->counter		= 0;
 	priv->phy.dev		= dev;
 	priv->phy.label		= dev_name(dev);


From sergei.shtylyov at cogentembedded.com  Tue Apr  9 18:35:30 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Wed, 10 Apr 2013 02:35:30 +0400
Subject: [PATCH v3 5/9] ARM: shmobile: R8A7779: remove USB PHY 2nd memory
 resource
Message-ID: <201304100235.30615.sergei.shtylyov@cogentembedded.com>

Now that 'drivers/usb/phy/rcar-phy.c' doesn't require the second memory resource
anymore, we can remove it from the R8A7779's USB PHY platform device.

Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Acked-by: Simon Horman <horms+renesas at verge.net.au>

---
Changes since version 2:
- refreshed atop of the prior patches;
- added a note about testing to the changelog;
- added ACKs from Simon Horman and Kuninori Morimoto.

Changes since the original posting:
- new patch in this version, split from the previous one.

 arch/arm/mach-shmobile/setup-r8a7779.c |    5 -----
 1 file changed, 5 deletions(-)

Index: renesas/arch/arm/mach-shmobile/setup-r8a7779.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/setup-r8a7779.c
+++ renesas/arch/arm/mach-shmobile/setup-r8a7779.c
@@ -406,11 +406,6 @@ static struct resource usb_phy_resources
 		.end		= 0xffe70900 - 1,
 		.flags		= IORESOURCE_MEM,
 	},
-	[1] = {
-		.start		= 0xfff70000,
-		.end		= 0xfff70900 - 1,
-		.flags		= IORESOURCE_MEM,
-	},
 };
 
 static struct platform_device usb_phy_device = {


From sergei.shtylyov at cogentembedded.com  Tue Apr  9 18:36:50 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Wed, 10 Apr 2013 02:36:50 +0400
Subject: [PATCH v3 6/9] rcar-phy: correct base address
Message-ID: <201304100236.50822.sergei.shtylyov@cogentembedded.com>

The memory region that is used by the driver overlaps EHCI and OHCI  register
regions for absolutely no reason now  -- fix it  by adding offset of 0x800 to
the base address, changing the register #define's accordingly. This has extra
positive effect that we now can use devm_ioremap_resource()...

Note that the driver and the SoC code have to be in one patch to keep the code
bisectable...

The patch has been tested on the Marzen board.

Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Acked-by: Simon Horman <horms+renesas at verge.net.au>

---
Changes since version 2:
- refreshed atop of the prior patches;
- added a note about testing to the changelog;
- added ACKs from Simon Horman and Kuninori Morimoto.

Changes since the original posting:
- added a note about bisectability to the changelog.

 arch/arm/mach-shmobile/setup-r8a7779.c |    2 +-
 drivers/usb/phy/rcar-phy.c             |   28 ++++++++++------------------
 2 files changed, 11 insertions(+), 19 deletions(-)

Index: renesas/arch/arm/mach-shmobile/setup-r8a7779.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/setup-r8a7779.c
+++ renesas/arch/arm/mach-shmobile/setup-r8a7779.c
@@ -402,7 +402,7 @@ static struct platform_device sata_devic
 /* USB PHY */
 static struct resource usb_phy_resources[] = {
 	[0] = {
-		.start		= 0xffe70000,
+		.start		= 0xffe70800,
 		.end		= 0xffe70900 - 1,
 		.flags		= IORESOURCE_MEM,
 	},
Index: renesas/drivers/usb/phy/rcar-phy.c
===================================================================
--- renesas.orig/drivers/usb/phy/rcar-phy.c
+++ renesas/drivers/usb/phy/rcar-phy.c
@@ -16,13 +16,13 @@
 #include <linux/spinlock.h>
 #include <linux/module.h>
 
-/* USBH common register */
-#define USBPCTRL0	0x0800
-#define USBPCTRL1	0x0804
-#define USBST		0x0808
-#define USBEH0		0x080C
-#define USBOH0		0x081C
-#define USBCTL0		0x0858
+/* REGS block */
+#define USBPCTRL0	0x00
+#define USBPCTRL1	0x04
+#define USBST		0x08
+#define USBEH0		0x0C
+#define USBOH0		0x1C
+#define USBCTL0		0x58
 
 /* USBPCTRL1 */
 #define PHY_RST		(1 << 2)
@@ -139,17 +139,9 @@ static int rcar_usb_phy_probe(struct pla
 		return -EINVAL;
 	}
 
-	/*
-	 * CAUTION
-	 *
-	 * Because this phy address is also mapped under OHCI/EHCI address area,
-	 * this driver can't use devm_request_and_ioremap(dev, res) here
-	 */
-	reg0 = devm_ioremap_nocache(dev, res0->start, resource_size(res0));
-	if (!reg0) {
-		dev_err(dev, "ioremap error\n");
-		return -ENOMEM;
-	}
+	reg0 = devm_ioremap_resource(dev, res0);
+	if (IS_ERR(reg0))
+		return PTR_ERR(reg0);
 
 	priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
 	if (!priv) {


From sergei.shtylyov at cogentembedded.com  Tue Apr  9 18:38:34 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Wed, 10 Apr 2013 02:38:34 +0400
Subject: [PATCH v3 8/9] ARM: shmobile: Marzen: pass platform data to USB PHY
 device
Message-ID: <201304100238.34847.sergei.shtylyov@cogentembedded.com>

Since we're now going to setup the USBPCTRL0 register using the USB PHY device's
platform data, we now need a way to pass those platform data from the board file
to the device which is situated in setup-r8a7779.c -- and what I'm suggesting is
r8a7779_add_usb_phy_device() that will register USB PHY platform device with the
passed platform data using platform_device_register_resndata() call; creating
this function envolves deletion of 'usb_phy_device' from r8a7779_devices_dt[],
so that it will no longer be registered for the generic R8A7779 machine (where
we can't provide the platform data anyway), hence EHCI/OHCI drivers will fail
to load as well.

For the Marzen board, this new function will be called from marzen_init() to
register the USB PHY device early enough.

Note that the board and the SoC code have to be in one patch to keep the code
bisectable...

The patch has been tested on the Marzen board.

Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Acked-by: Simon Horman <horms+renesas at verge.net.au>

---
Changes since version 2:
- refreshed atop of the prior patches;
- added a note about testing to the changelog;
- added ACKs from Simon Horman and Kuninori Morimoto.

Changes since the original posting:
- added a note about bisectability to the changelog.

 arch/arm/mach-shmobile/board-marzen.c         |    5 +++++
 arch/arm/mach-shmobile/include/mach/r8a7779.h |    2 ++
 arch/arm/mach-shmobile/setup-r8a7779.c        |   16 ++++++++--------
 3 files changed, 15 insertions(+), 8 deletions(-)

Index: renesas/arch/arm/mach-shmobile/board-marzen.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/board-marzen.c
+++ renesas/arch/arm/mach-shmobile/board-marzen.c
@@ -56,6 +56,10 @@ static struct regulator_consumer_supply 
 	REGULATOR_SUPPLY("vdd33a", "smsc911x"),
 };
 
+static struct rcar_phy_platform_data usb_phy_platform_data = {
+	.usbpctrl0	= 0,
+};
+
 /* SMSC LAN89218 */
 static struct resource smsc911x_resources[] = {
 	[0] = {
@@ -230,6 +234,7 @@ static void __init marzen_init(void)
 	r8a7779_pinmux_init();
 
 	r8a7779_add_standard_devices();
+	r8a7779_add_usb_phy_device(&usb_phy_platform_data);
 	platform_add_devices(marzen_devices, ARRAY_SIZE(marzen_devices));
 }
 
Index: renesas/arch/arm/mach-shmobile/include/mach/r8a7779.h
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/include/mach/r8a7779.h
+++ renesas/arch/arm/mach-shmobile/include/mach/r8a7779.h
@@ -4,6 +4,7 @@
 #include <linux/sh_clk.h>
 #include <linux/pm_domain.h>
 #include <linux/sh_eth.h>
+#include <linux/usb/rcar-phy.h>
 
 struct platform_device;
 
@@ -33,6 +34,7 @@ extern void r8a7779_add_early_devices(vo
 extern void r8a7779_add_standard_devices(void);
 extern void r8a7779_add_standard_devices_dt(void);
 extern void r8a7779_add_ether_device(struct sh_eth_plat_data *pdata);
+extern void r8a7779_add_usb_phy_device(struct rcar_phy_platform_data *pdata);
 extern void r8a7779_init_late(void);
 extern void r8a7779_clock_init(void);
 extern void r8a7779_pinmux_init(void);
Index: renesas/arch/arm/mach-shmobile/setup-r8a7779.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/setup-r8a7779.c
+++ renesas/arch/arm/mach-shmobile/setup-r8a7779.c
@@ -408,13 +408,6 @@ static struct resource usb_phy_resources
 	},
 };
 
-static struct platform_device usb_phy_device = {
-	.name		= "rcar_usb_phy",
-	.id		= -1,
-	.resource	= usb_phy_resources,
-	.num_resources	= ARRAY_SIZE(usb_phy_resources),
-};
-
 /* USB */
 static struct usb_phy *phy;
 
@@ -586,7 +579,6 @@ static struct platform_device *r8a7779_d
 	&scif5_device,
 	&tmu00_device,
 	&tmu01_device,
-	&usb_phy_device,
 };
 
 static struct platform_device *r8a7779_standard_devices[] __initdata = {
@@ -621,6 +613,14 @@ void __init r8a7779_add_ether_device(str
 					  pdata, sizeof(*pdata));
 }
 
+void __init r8a7779_add_usb_phy_device(struct rcar_phy_platform_data *pdata)
+{
+	platform_device_register_resndata(&platform_bus, "rcar_usb_phy", -1,
+					  usb_phy_resources,
+					  ARRAY_SIZE(usb_phy_resources),
+					  pdata, sizeof(*pdata));
+}
+
 /* do nothing for !CONFIG_SMP or !CONFIG_HAVE_TWD */
 void __init __weak r8a7779_register_twd(void) { }
 


From sergei.shtylyov at cogentembedded.com  Tue Apr  9 18:47:21 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Wed, 10 Apr 2013 02:47:21 +0400
Subject: [PATCH 0/4] Add USB support to R8A7778/BOCK-W
Message-ID: <201304100247.22615.sergei.shtylyov@cogentembedded.com>

Hello.

   Here's the set of 4 patches against the Simon Horman's 'renesas.git' repo,
'renesas-next-20130410' tag.  It was created to add support of R8A7778/BOCK-W
USB to the platform code and the USB common PHY driver, and so spans both
arch/arm/mach-shmobile/ and drivers/usb/phy/ subtrees.

[1/4] rcar-phy: add R8A7778 support
[2/4] ARM: shmobile: R8A7778: add USB support
[3/4] ARM: shmobile: BOCK-W: add USB support
[4/4] ARM: shmobile: BOCK-W: enable USB in defconfig

   I'm not sure thru which tree this patchset should be merged, however it turns
out that it's too late now to push it thru Felipe Balbi's USB tree for 3.10
(which would have been most convenient probably), and it's probably too late to
merge thru Simon's tree for 3.10 too. So it now have to be postponed to 3.11,
unfortunately...

WBR, Sergei


From sergei.shtylyov at cogentembedded.com  Tue Apr  9 18:52:45 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Wed, 10 Apr 2013 02:52:45 +0400
Subject: [PATCH 2/4] ARM: shmobile: R8A7778: add USB support
In-Reply-To: <201304100247.22615.sergei.shtylyov@cogentembedded.com>
References: <201304100247.22615.sergei.shtylyov@cogentembedded.com>
Message-ID: <201304100252.46139.sergei.shtylyov@cogentembedded.com>

Add USB clock and EHCI, OHCI, and USB PHY platform devices for R8A7778 SoC;  add
a function to register PHY device with board-specific platform data and register
EHCI and OHCI platfrom devices from the init_late() board method.

Also,  don't forget to enable CONFIG_ARCH_HAS_[EO]HCI options for R8A7778 SoC in
Kconfig...

The patch has been tested on the BOCK-W board.

Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

---
 arch/arm/mach-shmobile/Kconfig                |    2 
 arch/arm/mach-shmobile/clock-r8a7778.c        |    4 
 arch/arm/mach-shmobile/include/mach/r8a7778.h |    3 
 arch/arm/mach-shmobile/setup-r8a7778.c        |  108 ++++++++++++++++++++++++++
 4 files changed, 117 insertions(+)

Index: renesas/arch/arm/mach-shmobile/Kconfig
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/Kconfig
+++ renesas/arch/arm/mach-shmobile/Kconfig
@@ -40,6 +40,8 @@ config ARCH_R8A7778
 	select CPU_V7
 	select SH_CLK_CPG
 	select ARM_GIC
+	select USB_ARCH_HAS_EHCI
+	select USB_ARCH_HAS_OHCI
 
 config ARCH_R8A7779
 	bool "R-Car H1 (R8A77790)"
Index: renesas/arch/arm/mach-shmobile/clock-r8a7778.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/clock-r8a7778.c
+++ renesas/arch/arm/mach-shmobile/clock-r8a7778.c
@@ -59,12 +59,14 @@ static struct clk *main_clks[] = {
 
 enum {
 	MSTP114,
+	MSTP100,
 	MSTP026, MSTP025, MSTP024, MSTP023, MSTP022, MSTP021,
 	MSTP016, MSTP015,
 	MSTP_NR };
 
 static struct clk mstp_clks[MSTP_NR] = {
 	[MSTP114] = SH_CLK_MSTP32(&clkp, MSTPCR1, 14, 0), /* Ether */
+	[MSTP100] = SH_CLK_MSTP32(&clkp, MSTPCR1,  0, 0), /* USB0/1 */
 	[MSTP026] = SH_CLK_MSTP32(&clkp, MSTPCR0, 26, 0), /* SCIF0 */
 	[MSTP025] = SH_CLK_MSTP32(&clkp, MSTPCR0, 25, 0), /* SCIF1 */
 	[MSTP024] = SH_CLK_MSTP32(&clkp, MSTPCR0, 24, 0), /* SCIF2 */
@@ -78,6 +80,8 @@ static struct clk mstp_clks[MSTP_NR] = {
 static struct clk_lookup lookups[] = {
 	/* MSTP32 clocks */
 	CLKDEV_DEV_ID("sh-eth",	&mstp_clks[MSTP114]), /* Ether */
+	CLKDEV_DEV_ID("ehci-platform", &mstp_clks[MSTP100]), /* USB EHCI port0/1 */
+	CLKDEV_DEV_ID("ohci-platform", &mstp_clks[MSTP100]), /* USB OHCI port0/1 */
 	CLKDEV_DEV_ID("sh-sci.0", &mstp_clks[MSTP026]), /* SCIF0 */
 	CLKDEV_DEV_ID("sh-sci.1", &mstp_clks[MSTP025]), /* SCIF1 */
 	CLKDEV_DEV_ID("sh-sci.2", &mstp_clks[MSTP024]), /* SCIF2 */
Index: renesas/arch/arm/mach-shmobile/include/mach/r8a7778.h
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/include/mach/r8a7778.h
+++ renesas/arch/arm/mach-shmobile/include/mach/r8a7778.h
@@ -19,10 +19,13 @@
 #define __ASM_R8A7778_H__
 
 #include <linux/sh_eth.h>
+#include <linux/usb/rcar-phy.h>
 
 extern void r8a7778_add_standard_devices(void);
 extern void r8a7778_add_standard_devices_dt(void);
 extern void r8a7778_add_ether_device(struct sh_eth_plat_data *pdata);
+extern void r8a7778_add_usb_phy_device(struct rcar_phy_platform_data *pdata);
+extern void r8a7778_init_late(void);
 extern void r8a7778_init_delay(void);
 extern void r8a7778_init_irq(void);
 extern void r8a7778_init_irq_dt(void);
Index: renesas/arch/arm/mach-shmobile/setup-r8a7778.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/setup-r8a7778.c
+++ renesas/arch/arm/mach-shmobile/setup-r8a7778.c
@@ -29,6 +29,12 @@
 #include <linux/irqchip.h>
 #include <linux/serial_sci.h>
 #include <linux/sh_timer.h>
+#include <linux/pm_runtime.h>
+#include <linux/usb/phy.h>
+#include <linux/usb/hcd.h>
+#include <linux/usb/ehci_pdriver.h>
+#include <linux/usb/ohci_pdriver.h>
+#include <linux/dma-mapping.h>
 #include <mach/irqs.h>
 #include <mach/r8a7778.h>
 #include <mach/common.h>
@@ -88,6 +94,99 @@ static struct sh_timer_config sh_tmu1_pl
 		&sh_tmu##idx##_platform_data,		\
 		sizeof(sh_tmu##idx##_platform_data))
 
+/* USB PHY */
+static struct resource usb_phy_resources[] = {
+	DEFINE_RES_MEM(0xffe70800, 0x100),
+	DEFINE_RES_MEM(0xffe76000, 0x100),
+};
+
+void __init r8a7778_add_usb_phy_device(struct rcar_phy_platform_data *pdata)
+{
+	platform_device_register_resndata(&platform_bus, "rcar_usb_phy", -1,
+					  usb_phy_resources,
+					  ARRAY_SIZE(usb_phy_resources),
+					  pdata, sizeof(*pdata));
+}
+
+/* USB */
+static struct usb_phy *phy;
+
+static int usb_power_on(struct platform_device *pdev)
+{
+	if (!phy)
+		return -EIO;
+
+	pm_runtime_enable(&pdev->dev);
+	pm_runtime_get_sync(&pdev->dev);
+
+	usb_phy_init(phy);
+
+	return 0;
+}
+
+static void usb_power_off(struct platform_device *pdev)
+{
+	if (!phy)
+		return;
+
+	usb_phy_shutdown(phy);
+
+	pm_runtime_put_sync(&pdev->dev);
+	pm_runtime_disable(&pdev->dev);
+}
+
+static int ehci_init_internal_buffer(struct usb_hcd *hcd)
+{
+	/*
+	 * Below are recommended values from the datasheet;
+	 * see [USB :: Setting of EHCI Internal Buffer].
+	 */
+	/* EHCI IP internal buffer setting */
+	iowrite32(0x00ff0040, hcd->regs + 0x0094);
+	/* EHCI IP internal buffer enable */
+	iowrite32(0x00000001, hcd->regs + 0x009C);
+
+	return 0;
+}
+
+static struct usb_ehci_pdata ehci_pdata = {
+	.power_on	= usb_power_on,
+	.power_off	= usb_power_off,
+	.power_suspend	= usb_power_off,
+	.pre_setup	= ehci_init_internal_buffer,
+};
+
+static struct resource ehci_resources[] = {
+	DEFINE_RES_MEM(0xffe70000, 0x400),
+	DEFINE_RES_IRQ(gic_iid(0x4c)),
+};
+
+static struct usb_ohci_pdata ohci_pdata = {
+	.power_on	= usb_power_on,
+	.power_off	= usb_power_off,
+	.power_suspend	= usb_power_off,
+};
+
+static struct resource ohci_resources[] = {
+	DEFINE_RES_MEM(0xffe70400, 0x400),
+	DEFINE_RES_IRQ(gic_iid(0x4c)),
+};
+
+#define USB_PLATFORM_INFO(hci)				\
+static struct platform_device_info hci##_info = {	\
+	.parent		= &platform_bus,		\
+	.name		= #hci "-platform",		\
+	.id		= -1,				\
+	.res		= hci##_resources,		\
+	.num_res	= ARRAY_SIZE(hci##_resources),	\
+	.data		= &hci##_pdata,			\
+	.size_data	= sizeof(hci##_pdata),		\
+	.dma_mask	= DMA_BIT_MASK(32),		\
+}
+
+USB_PLATFORM_INFO(ehci);
+USB_PLATFORM_INFO(ohci);
+
 /* Ether */
 static struct resource ether_resources[] = {
 	DEFINE_RES_MEM(0xfde00000, 0x400),
@@ -126,6 +225,14 @@ void __init r8a7778_add_standard_devices
 	r8a7778_register_tmu(1);
 }
 
+void __init r8a7778_init_late(void)
+{
+	phy = usb_get_phy(USB_PHY_TYPE_USB2);
+
+	platform_device_register_full(&ehci_info);
+	platform_device_register_full(&ohci_info);
+}
+
 static struct renesas_intc_irqpin_config irqpin_platform_data = {
 	.irq_base = irq_pin(0), /* IRQ0 -> IRQ3 */
 	.sense_bitfield_width = 2,
@@ -239,6 +346,7 @@ DT_MACHINE_START(R8A7778_DT, "Generic R8
 	.init_machine	= r8a7778_add_standard_devices_dt,
 	.init_time	= shmobile_timer_init,
 	.dt_compat	= r8a7778_compat_dt,
+	.init_late      = r8a7778_init_late,
 MACHINE_END
 
 #endif /* CONFIG_USE_OF */


From sergei.shtylyov at cogentembedded.com  Tue Apr  9 18:54:55 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Wed, 10 Apr 2013 02:54:55 +0400
Subject: [PATCH 3/4] ARM: shmobile: BOCK-W: add USB support
In-Reply-To: <201304100247.22615.sergei.shtylyov@cogentembedded.com>
References: <201304100247.22615.sergei.shtylyov@cogentembedded.com>
Message-ID: <201304100254.55733.sergei.shtylyov@cogentembedded.com>

Register the USB PHY device from bockw_init(), passing the platform  data to it.
Set machine's init_late() method to r8a7778_init_late() in order for [EO]HCI to
get registered too...

The patch has been tested on the BOCK-W board.

Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

---
 arch/arm/mach-shmobile/board-bockw.c |    7 +++++++
 1 file changed, 7 insertions(+)

Index: renesas/arch/arm/mach-shmobile/board-bockw.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/board-bockw.c
+++ renesas/arch/arm/mach-shmobile/board-bockw.c
@@ -53,6 +53,11 @@ static struct resource smsc911x_resource
 	DEFINE_RES_IRQ(irq_pin(0)), /* IRQ 0 */
 };
 
+static struct rcar_phy_platform_data usb_phy_platform_data = {
+	.usbpctrl0	= 0,
+	.ferrite_bead	= true,		/* ??? */
+};
+
 #define IRQ0MR	0x30
 static void __init bockw_init(void)
 {
@@ -61,6 +66,7 @@ static void __init bockw_init(void)
 	r8a7778_clock_init();
 	r8a7778_init_irq_extpin(1);
 	r8a7778_add_standard_devices();
+	r8a7778_add_usb_phy_device(&usb_phy_platform_data);
 
 	fpga = ioremap_nocache(0x18200000, SZ_1M);
 	if (fpga) {
@@ -97,4 +103,5 @@ DT_MACHINE_START(BOCKW_DT, "bockw")
 	.init_machine	= bockw_init,
 	.init_time	= shmobile_timer_init,
 	.dt_compat	= bockw_boards_compat_dt,
+	.init_late      = r8a7778_init_late,
 MACHINE_END



From sergei.shtylyov at cogentembedded.com  Tue Apr  9 18:59:12 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Wed, 10 Apr 2013 02:59:12 +0400
Subject: [PATCH 4/4] ARM: shmobile: BOCK-W: enable USB in defconfig
In-Reply-To: <201304100247.22615.sergei.shtylyov@cogentembedded.com>
References: <201304100247.22615.sergei.shtylyov@cogentembedded.com>
Message-ID: <201304100259.13346.sergei.shtylyov@cogentembedded.com>

Enable USB platform EHCI/OHCI and common PHY drivers in 'bockw_defconfig'.
Enable USB storage driver and SCSI disk driver that it needs as well...

Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

---
 arch/arm/configs/bockw_defconfig |   11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

Index: renesas/arch/arm/configs/bockw_defconfig
===================================================================
--- renesas.orig/arch/arm/configs/bockw_defconfig
+++ renesas/arch/arm/configs/bockw_defconfig
@@ -48,6 +48,8 @@ CONFIG_DEVTMPFS_MOUNT=y
 # CONFIG_STANDALONE is not set
 # CONFIG_PREVENT_FIRMWARE_BUILD is not set
 # CONFIG_FW_LOADER is not set
+CONFIG_SCSI=y
+CONFIG_BLK_DEV_SD=y
 CONFIG_NETDEVICES=y
 # CONFIG_NET_CADENCE is not set
 # CONFIG_NET_VENDOR_BROADCOM is not set
@@ -71,7 +73,14 @@ CONFIG_SERIAL_SH_SCI_NR_UARTS=6
 CONFIG_SERIAL_SH_SCI_CONSOLE=y
 # CONFIG_HW_RANDOM is not set
 # CONFIG_HWMON is not set
-# CONFIG_USB_SUPPORT is not set
+CONFIG_USB=y
+CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
+CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_OHCI_HCD=y
+CONFIG_USB_OHCI_HCD_PLATFORM=y
+CONFIG_USB_EHCI_HCD_PLATFORM=y
+CONFIG_USB_STORAGE=y
+CONFIG_USB_RCAR_PHY=y
 CONFIG_UIO=y
 CONFIG_UIO_PDRV_GENIRQ=y
 # CONFIG_IOMMU_SUPPORT is not set



From khilman at linaro.org  Tue Apr  9 19:13:29 2013
From: khilman at linaro.org (Kevin Hilman)
Date: Tue, 09 Apr 2013 16:13:29 -0700
Subject: [GIT PULL] OMAP PM cleanups for v3.10
Message-ID: <87ehej1ena.fsf@linaro.org>

Tony,

Here's the final set of OMAP PM cleanups for v3.10.  This is a small set
of cleanups from Santosh to consolidate and prepare for OMAP5 PM additions.

It's based on your cleanup-v2 branch.

Kevin


The following changes since commit c309f7f46167e85d1aae2fd31f23e7d2b5cdfbe0:

  Merge branch 'for_3.10/omap_generic_cleanup_v2' of git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux into omap-for-v3.10/cleanup-v2 (2013-03-28 14:45:31 -0700)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git tags/omap-pm-v3.10/cleanup/pm

for you to fetch changes up to 705814b5ea6ff69d4da8ad581c3da5d26d1eae83:

  ARM: OMAP4+: PM: Consolidate OMAP4 PM code to re-use it for OMAP5 (2013-04-09 10:53:06 -0700)

----------------------------------------------------------------
OMAP PM cleanups for v3.10

----------------------------------------------------------------
Santosh Shilimkar (4):
      ARM: OMAP4: PM: Avoid expensive cpu_suspend() path for all CPU power states except off
      ARM: OMAP4+: PM: Consolidate MPU subsystem PM code for re-use
      ARM: OMAP4+: Make secondary_startup function name more consistent
      ARM: OMAP4+: PM: Consolidate OMAP4 PM code to re-use it for OMAP5

 arch/arm/mach-omap2/common.h              |  4 +-
 arch/arm/mach-omap2/omap-headsmp.S        |  8 ++--
 arch/arm/mach-omap2/omap-mpuss-lowpower.c | 69 +++++++++++++++++++++++++------
 arch/arm/mach-omap2/omap-smp.c            |  6 +--
 arch/arm/mach-omap2/pm44xx.c              | 58 +++++++++++++++++++++-----
 5 files changed, 113 insertions(+), 32 deletions(-)


From gregkh at linuxfoundation.org  Tue Apr  9 19:15:23 2013
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Tue, 9 Apr 2013 16:15:23 -0700
Subject: [PATCH 0/7] i.MX53 IPU + TVE patches
In-Reply-To: <1365493486.4023.13.camel@pizza.hi.pengutronix.de>
References: <1365437078-22579-1-git-send-email-p.zabel@pengutronix.de>
 <20130408174016.GB30036@kroah.com>
 <1365493486.4023.13.camel@pizza.hi.pengutronix.de>
Message-ID: <20130409231523.GA15722@kroah.com>

On Tue, Apr 09, 2013 at 09:44:46AM +0200, Philipp Zabel wrote:
> Hi Greg,
> 
> Am Montag, den 08.04.2013, 10:40 -0700 schrieb Greg Kroah-Hartman:
> > On Mon, Apr 08, 2013 at 06:04:31PM +0200, Philipp Zabel wrote:
> > > Hi,
> > > 
> > > the following patches allow to use the integrated Television Encoder
> > > (TVEv2) on the i.MX53 SoC as VGA output encoder for the IPU. This is
> > > useful for the Freescale i.MX53-QSB and TQ MBa53 boards, which have
> > > VGA and DVI-I connectors, respectively.
> > > 
> > > regards
> > > Philipp
> > > 
> > > ---
> > >  drivers/staging/imx-drm/Kconfig             |   7 +
> > >  drivers/staging/imx-drm/Makefile            |   1 +
> > >  drivers/staging/imx-drm/imx-drm-core.c      |  15 +-
> > >  drivers/staging/imx-drm/imx-drm.h           |  14 +-
> > >  drivers/staging/imx-drm/imx-tve.c           | 755 ++++++++++++++++++++++++++++
> > >  drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h |   3 +
> > >  drivers/staging/imx-drm/ipu-v3/ipu-dc.c     |  55 +-
> > >  drivers/staging/imx-drm/ipu-v3/ipu-di.c     | 100 +++-
> > >  drivers/staging/imx-drm/ipuv3-crtc.c        |  11 +-
> > >  9 files changed, 932 insertions(+), 29 deletions(-)
> > 
> > That's a lot of new features being added here, yet no work seems to be
> > happening to move this out of the staging tree.  What is left to do
> > here, and why isn't that being worked on first, before stuff like this?
> 
> the IPU code could still use a bit of testing, and I hope adding
> features like VGA output on common development boards will increase the
> amount of scrutiny this code will get.
> I expect the structure of the IPU drivers to change when the common
> display framework gets introduced at last, also requiring changes to the
> device tree bindings, and I'm a bit reluctant to push for mainline
> proper while the bindings are still not clear.

Ok, thanks for the information.  Is the TODO file still correct with
these changes?  If not, care to send a patch to update it as well?

thanks,

greg k-h


From khilman at linaro.org  Tue Apr  9 19:19:59 2013
From: khilman at linaro.org (Kevin Hilman)
Date: Tue, 09 Apr 2013 16:19:59 -0700
Subject: [GIT PULL] CPUidle: OMAP cleanups for v3.10
Message-ID: <871uaj1ecg.fsf@linaro.org>

Rafael,

Please pull the following OMAP CPUidle changes for v3.10.

Due to dependencies on other CPUidle changes that are already in your
linux-next branch, this branch is based on the commit where you merged
your pm-cpuidle-next branch into linux-next.

Kevin

The following changes since commit f69e44b2059f2238ac558b4a115ebcdefe20b9be:

  Merge branch 'pm-cpuidle-next' into linux-next (2013-04-08 12:32:07 +0200)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git tags/omap-pm-v3.10/cleanup/cpuidle-v2

for you to fetch changes up to db4f3dab629109882170a7b1b8fb655a34c52846:

  ARM: OMAP4+: CPUidle: Consolidate idle driver for OMAP5 support (2013-04-09 09:48:21 -0700)

----------------------------------------------------------------
OMAP CPUidle cleanups for v3.10

----------------------------------------------------------------
Daniel Lezcano (1):
      ARM: omap3: cpuidle: enable time keeping

Santosh Shilimkar (5):
      ARM: OMAP4: CPUidle: Avoid double idle driver registration
      ARM: OMAP: CPUidle: Unregister drivere on device registration failure
      ARM: OMAP4: CPUidle: Make C-state description field more precise
      ARM: OMAP4+: CPUidle: Deprecate use of omap4_mpuss_read_prev_context_state()
      ARM: OMAP4+: CPUidle: Consolidate idle driver for OMAP5 support

 arch/arm/mach-omap2/common.h              |  5 ----
 arch/arm/mach-omap2/cpuidle34xx.c         | 11 +++++--
 arch/arm/mach-omap2/cpuidle44xx.c         | 48 +++++++++++++++++--------------
 arch/arm/mach-omap2/omap-mpuss-lowpower.c | 14 ---------
 4 files changed, 35 insertions(+), 43 deletions(-)


From khilman at linaro.org  Tue Apr  9 19:22:01 2013
From: khilman at linaro.org (Kevin Hilman)
Date: Tue,  9 Apr 2013 16:22:01 -0700
Subject: [PATCH] cpufreq: OMAP: instantiate omap-cpufreq as a platform_driver
Message-ID: <1365549721-15620-1-git-send-email-khilman@linaro.org>

From: Nishanth Menon <nm at ti.com>

As multi-platform build is being adopted by more and more ARM platforms,
initcall function should be used very carefully.  For example, when
CONFIG_ARM_OMAP2PLUS_CPUFREQ is built in the kernel, omap_cpufreq_init()
will be called on all the platforms to initialize omap-cpufreq driver.

Further, on OMAP, we now use Soc generic cpufreq-cpu0 driver using device
tree entries.  To allow cpufreq-cpu0 and omap-cpufreq drivers to co-exist
for OMAP in a single image, we need to ensure the following:
1. With device tree boot, we use cpufreq-cpu0
2. With non device tree boot, we use omap-cpufreq

In the case of (1), we will have cpu OPPs and regulator registered
as part of the device tree nodes, to ensure that omap-cpufreq
and cpufreq-cpu0 don't conflict in managing the frequency of the
same CPU, we should not permit omap-cpufreq to be probed.

In the case of (2), we will not have the cpufreq-cpu0 device, hence
only omap-cpufreq will be active.

To eliminate this undesired these effects, we change omap-cpufreq
driver to have it instantiated as a platform_driver and register
"omap-cpufreq" device only when booted without device tree nodes on
OMAP platforms.

This allows the following:
a) Will only run on platforms that create the platform_device
   "omap-cpufreq".
b) Since the platform_device is registered only when device tree nodes
   are *not* populated, omap-cpufreq driver does not conflict with
   the usage of cpufreq-cpu0 driver which is used on OMAP platforms when
   device tree nodes are present.

Inspired by commit 5553f9e26f6f49a93ba732fd222eac6973a4cf35
(cpufreq: instantiate cpufreq-cpu0 as a platform_driver)

Cc: Kevin Hilman <khilman at linaro.org>
Cc: Rajendra Nayak <rnayak at ti.com>
Cc: Paul Walmsley <paul at pwsan.com>
Cc: "Beno?t Cousson" <b-cousson at ti.com>
Cc: Jon Hunter <jon-hunter at ti.com>
Cc: Keerthy <j-keerthy at ti.com>
Cc: Santosh Shilimkar <santosh.shilimkar at ti.com>
Cc: Shawn Guo <shawn.guo at linaro.org>
[robherring2 at gmail.com: reported conflict of omap-cpufreq vs other
driver in an non-device tree supported boot]
Reported-by: Rob Herring <robherring2 at gmail.com>
Signed-off-by: Nishanth Menon <nm at ti.com>
Acked-by: Viresh Kumar <viresh.kumar at linaro.org>
Signed-off-by: Kevin Hilman <khilman at linaro.org>
---
Rafael, can you add this one for v3.10?  It applies on top the
rest of your cpufreq changes and I've verified that the OMAP
changes are OK and don't conflict with anything else we have
queued for v3.10 on OMAP.

This patch was previously part of a 2-patch series, but the 
other part is still in discussion, and this part can be merged
independently.

 arch/arm/mach-omap2/pm.c       |  9 +++++++++
 drivers/cpufreq/omap-cpufreq.c | 19 ++++++++++++++-----
 2 files changed, 23 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index 673a4c1..8d15f9a 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -265,6 +265,12 @@ static void __init omap4_init_voltages(void)
 	omap2_set_init_voltage("iva", "dpll_iva_m5x2_ck", "iva");
 }
 
+static inline void omap_init_cpufreq(void)
+{
+	struct platform_device_info devinfo = { .name = "omap-cpufreq", };
+	platform_device_register_full(&devinfo);
+}
+
 static int __init omap2_common_pm_init(void)
 {
 	if (!of_have_populated_dt())
@@ -294,6 +300,9 @@ int __init omap2_common_pm_late_init(void)
 
 		/* Smartreflex device init */
 		omap_devinit_smartreflex();
+
+		/* cpufreq dummy device instantiation */
+		omap_init_cpufreq();
 	}
 
 #ifdef CONFIG_SUSPEND
diff --git a/drivers/cpufreq/omap-cpufreq.c b/drivers/cpufreq/omap-cpufreq.c
index 9128c07..d4f84b8 100644
--- a/drivers/cpufreq/omap-cpufreq.c
+++ b/drivers/cpufreq/omap-cpufreq.c
@@ -25,6 +25,7 @@
 #include <linux/opp.h>
 #include <linux/cpu.h>
 #include <linux/module.h>
+#include <linux/platform_device.h>
 #include <linux/regulator/consumer.h>
 
 #include <asm/smp_plat.h>
@@ -252,7 +253,7 @@ static struct cpufreq_driver omap_driver = {
 	.attr		= omap_cpufreq_attr,
 };
 
-static int __init omap_cpufreq_init(void)
+static int omap_cpufreq_probe(struct platform_device *pdev)
 {
 	mpu_dev = get_cpu_device(0);
 	if (!mpu_dev) {
@@ -280,12 +281,20 @@ static int __init omap_cpufreq_init(void)
 	return cpufreq_register_driver(&omap_driver);
 }
 
-static void __exit omap_cpufreq_exit(void)
+static int omap_cpufreq_remove(struct platform_device *pdev)
 {
-	cpufreq_unregister_driver(&omap_driver);
+	return cpufreq_unregister_driver(&omap_driver);
 }
 
+static struct platform_driver omap_cpufreq_platdrv = {
+	.driver = {
+		.name	= "omap-cpufreq",
+		.owner	= THIS_MODULE,
+	},
+	.probe		= omap_cpufreq_probe,
+	.remove		= omap_cpufreq_remove,
+};
+module_platform_driver(omap_cpufreq_platdrv);
+
 MODULE_DESCRIPTION("cpufreq driver for OMAP SoCs");
 MODULE_LICENSE("GPL");
-module_init(omap_cpufreq_init);
-module_exit(omap_cpufreq_exit);
-- 
1.8.2



From dianders at chromium.org  Tue Apr  9 19:30:09 2013
From: dianders at chromium.org (Doug Anderson)
Date: Tue, 9 Apr 2013 16:30:09 -0700
Subject: [PATCH v4] mmc: dw_mmc: let device core setup the default pin
 configuration
In-Reply-To: <1365487186-4587-1-git-send-email-thomas.abraham@linaro.org>
References: <1365487186-4587-1-git-send-email-thomas.abraham@linaro.org>
Message-ID: <CAD=FV=VJ-ykDNqYKQ=fqxeOD6bRNLW02VT4bjsRHRAuXLcCpQQ@mail.gmail.com>

Thomas,

On Mon, Apr 8, 2013 at 10:59 PM, Thomas Abraham
<thomas.abraham at linaro.org> wrote:
> @@ -2002,7 +1994,7 @@ static int dw_mci_init_slot(struct dw_mci *host, unsigned int id)
>                 if (ret) {
>                         dev_err(host->dev,
>                                 "failed to enable regulator: %d\n", ret);
> -                       goto err_setup_bus;
> +                       return ret;

It seems like you'd need a "mmc_free_host(mmc);" in this case don't
you?  AKA: this should be a goto and not a return.

-Doug


From heiko at sntech.de  Tue Apr  9 19:35:12 2013
From: heiko at sntech.de (Heiko =?utf-8?q?St=C3=BCbner?=)
Date: Wed, 10 Apr 2013 01:35:12 +0200
Subject: [PATCH] pinctrl: Add pinctrl-s3c24xx driver
Message-ID: <201304100135.12471.heiko@sntech.de>

The s3c24xx pins follow a similar pattern as the other Samsung SoCs and
can therefore reuse the already introduced infrastructure.

The s3c24xx SoCs have one design oddity in that the first 4 external
interrupts do not reside in the eint pending register but in the main
interrupt controller instead. We solve this by forwarding the external
interrupt from the main controller into the irq domain of the pin bank.
The masking/acking of these interrupts is handled in the same way.

Furthermore the S3C2412/2413 SoCs contain another oddity in that they
keep the same 4 eints in the main interrupt controller and eintpend
register and requiring ack operations to happen in both. To solve this
a ctrl_type enum is introduced which can keep the type of controller
in the samsung_pin_ctrl struct for later retrieval.

The ctrl_type enum contains only S3C24XX and S3C2412 types, as the
eint-speciality is currently the only use-case. But it can be expaned
if other SoCs gain special handling requirements later on.

Signed-off-by: Heiko Stuebner <heiko at sntech.de>
---
Depends on the s3c64xx pinctrl work from Tomasz Figa.

It also does not yet contain the pin-definitions for all s3c24xx SoCs,
as I don't have datasheets for them.

Tested on a s3c2416 based board.

 .../bindings/pinctrl/samsung-pinctrl.txt           |    4 +
 drivers/gpio/gpio-samsung.c                        |    4 +
 drivers/pinctrl/Kconfig                            |    5 +
 drivers/pinctrl/Makefile                           |    1 +
 drivers/pinctrl/pinctrl-s3c24xx.c                  |  603 ++++++++++++++++++++
 drivers/pinctrl/pinctrl-samsung.c                  |   10 +
 drivers/pinctrl/pinctrl-samsung.h                  |   16 +
 7 files changed, 643 insertions(+), 0 deletions(-)
 create mode 100644 drivers/pinctrl/pinctrl-s3c24xx.c

diff --git a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
index c70fca1..1d8fc3c 100644
--- a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
@@ -7,6 +7,10 @@ on-chip controllers onto these pads.
 
 Required Properties:
 - compatible: should be one of the following.
+  - "samsung,s3c2413-pinctrl": for S3C64xx-compatible pin-controller,
+  - "samsung,s3c2416-pinctrl": for S3C64xx-compatible pin-controller,
+  - "samsung,s3c2440-pinctrl": for S3C64xx-compatible pin-controller,
+  - "samsung,s3c2450-pinctrl": for S3C64xx-compatible pin-controller,
   - "samsung,s3c64xx-pinctrl": for S3C64xx-compatible pin-controller,
   - "samsung,exynos4210-pinctrl": for Exynos4210 compatible pin-controller.
   - "samsung,exynos4x12-pinctrl": for Exynos4x12 compatible pin-controller.
diff --git a/drivers/gpio/gpio-samsung.c b/drivers/gpio/gpio-samsung.c
index dc06a6f..73017b9 100644
--- a/drivers/gpio/gpio-samsung.c
+++ b/drivers/gpio/gpio-samsung.c
@@ -3026,6 +3026,10 @@ static __init int samsung_gpiolib_init(void)
 	*/
 	struct device_node *pctrl_np;
 	static const struct of_device_id exynos_pinctrl_ids[] = {
+		{ .compatible = "samsung,s3c2413-pinctrl", },
+		{ .compatible = "samsung,s3c2416-pinctrl", },
+		{ .compatible = "samsung,s3c2440-pinctrl", },
+		{ .compatible = "samsung,s3c2450-pinctrl", },
 		{ .compatible = "samsung,s3c64xx-pinctrl", },
 		{ .compatible = "samsung,exynos4210-pinctrl", },
 		{ .compatible = "samsung,exynos4x12-pinctrl", },
diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index 7402ac9..58d73ac 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -226,6 +226,11 @@ config PINCTRL_EXYNOS5440
 	select PINMUX
 	select PINCONF
 
+config PINCTRL_S3C24XX
+	bool "Samsung S3C24XX SoC pinctrl driver"
+	depends on ARCH_S3C24XX
+	select PINCTRL_SAMSUNG
+
 config PINCTRL_S3C64XX
 	bool "Samsung S3C64XX SoC pinctrl driver"
 	depends on ARCH_S3C64XX
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index 21d34c2..1ccdfd8 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -45,6 +45,7 @@ obj-$(CONFIG_PINCTRL_COH901)	+= pinctrl-coh901.o
 obj-$(CONFIG_PINCTRL_SAMSUNG)	+= pinctrl-samsung.o
 obj-$(CONFIG_PINCTRL_EXYNOS)	+= pinctrl-exynos.o
 obj-$(CONFIG_PINCTRL_EXYNOS5440)	+= pinctrl-exynos5440.o
+obj-$(CONFIG_PINCTRL_S3C24XX)	+= pinctrl-s3c24xx.o
 obj-$(CONFIG_PINCTRL_S3C64XX)	+= pinctrl-s3c64xx.o
 obj-$(CONFIG_PINCTRL_XWAY)	+= pinctrl-xway.o
 obj-$(CONFIG_PINCTRL_LANTIQ)	+= pinctrl-lantiq.o
diff --git a/drivers/pinctrl/pinctrl-s3c24xx.c b/drivers/pinctrl/pinctrl-s3c24xx.c
new file mode 100644
index 0000000..6b05519
--- /dev/null
+++ b/drivers/pinctrl/pinctrl-s3c24xx.c
@@ -0,0 +1,603 @@
+/*
+ * Exynos specific support for Samsung pinctrl/gpiolib driver with eint support.
+ *
+ * Copyright (c) 2012 Samsung Electronics Co., Ltd.
+ *		http://www.samsung.com
+ * Copyright (c) 2012 Linaro Ltd
+ *		http://www.linaro.org
+ *
+ * Author: Thomas Abraham <thomas.ab at samsung.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This file contains the Samsung Exynos specific information required by the
+ * the Samsung pinctrl/gpiolib driver. It also includes the implementation of
+ * external gpio and wakeup interrupt support.
+ */
+
+#include <linux/module.h>
+#include <linux/device.h>
+#include <linux/interrupt.h>
+#include <linux/irqdomain.h>
+#include <linux/irq.h>
+#include <linux/of_irq.h>
+#include <linux/io.h>
+#include <linux/slab.h>
+#include <linux/err.h>
+
+#include <asm/mach/irq.h>
+
+#include "pinctrl-samsung.h"
+
+#define NUM_EINT	24
+#define NUM_EINT_IRQ	6
+#define EINT_MAX_PER_GROUP	8
+
+#define EINTPEND_REG	0xa8
+#define EINTMASK_REG	0xa4
+
+#define EINT_GROUP(i)		((int)((i) / EINT_MAX_PER_GROUP))
+#define EINT_REG(i)		((EINT_GROUP(i) * 4) + 0x88)
+#define EINT_OFFS(i)		((i) % EINT_MAX_PER_GROUP * 4)
+
+#define EINT_LEVEL_LOW		0
+#define EINT_LEVEL_HIGH		1
+#define EINT_EDGE_FALLING	2
+#define EINT_EDGE_RISING	4
+#define EINT_EDGE_BOTH		6
+#define EINT_MASK		0xf
+
+static struct samsung_pin_bank_type bank_type_1bit = {
+	.fld_width = { 1, 1, },
+	.reg_offset = { 0x00, 0x04, },
+};
+
+static struct samsung_pin_bank_type bank_type_2bit = {
+	.fld_width = { 2, 1, 2, },
+	.reg_offset = { 0x00, 0x04, 0x08, },
+};
+
+#define PIN_BANK_A(pins, reg, id)		\
+	{						\
+		.type		= &bank_type_1bit,	\
+		.pctl_offset	= reg,			\
+		.nr_pins	= pins,			\
+		.eint_type	= EINT_TYPE_NONE,	\
+		.name		= id			\
+	}
+
+#define PIN_BANK_2BIT(pins, reg, id)		\
+	{						\
+		.type		= &bank_type_2bit,	\
+		.pctl_offset	= reg,			\
+		.nr_pins	= pins,			\
+		.eint_type	= EINT_TYPE_NONE,	\
+		.name		= id			\
+	}
+
+#define PIN_BANK_2BIT_EINTW(pins, reg, id, eoffs, emask)\
+	{						\
+		.type		= &bank_type_2bit,	\
+		.pctl_offset	= reg,			\
+		.nr_pins	= pins,			\
+		.eint_type	= EINT_TYPE_WKUP,	\
+		.eint_func	= 2,			\
+		.eint_mask	= emask,		\
+		.eint_offset	= eoffs,		\
+		.name		= id			\
+	}
+
+/**
+ * struct s3c24xx_eint_data: EINT common data
+ * @drvdata: pin controller driver data
+ * @domains: IRQ domains of particular EINT interrupts
+ */
+struct s3c24xx_eint_data {
+	struct samsung_pinctrl_drv_data *drvdata;
+	struct irq_domain *domains[NUM_EINT];
+	int parents[NUM_EINT_IRQ];
+};
+
+struct s3c24xx_eint_domain_data {
+	struct samsung_pin_bank *bank;
+	struct s3c24xx_eint_data *eint_data;
+};
+
+static int s3c24xx_eint_get_trigger(unsigned int type)
+{
+	int trigger;
+
+	switch (type) {
+	case IRQ_TYPE_EDGE_RISING:
+		trigger = EINT_EDGE_RISING;
+		break;
+	case IRQ_TYPE_EDGE_FALLING:
+		trigger = EINT_EDGE_FALLING;
+		break;
+	case IRQ_TYPE_EDGE_BOTH:
+		trigger = EINT_EDGE_BOTH;
+		break;
+	case IRQ_TYPE_LEVEL_HIGH:
+		trigger = EINT_LEVEL_HIGH;
+		break;
+	case IRQ_TYPE_LEVEL_LOW:
+		trigger = EINT_LEVEL_LOW;
+		break;
+	default:
+		return -EINVAL;
+	}
+
+	return trigger;
+}
+
+static void s3c24xx_eint_set_handler(unsigned int irq, unsigned int type)
+{
+	/* Edge- and level-triggered interrupts need different handlers */
+	if (type & IRQ_TYPE_EDGE_BOTH)
+		__irq_set_handler_locked(irq, handle_edge_irq);
+	else
+		__irq_set_handler_locked(irq, handle_level_irq);
+}
+
+static void s3c24xx_eint_set_function(struct samsung_pinctrl_drv_data *d,
+					struct samsung_pin_bank *bank, int pin)
+{
+	struct samsung_pin_bank_type *bank_type = bank->type;
+	unsigned long flags;
+	void __iomem *reg;
+	u8 shift;
+	u32 mask;
+	u32 val;
+
+	/* Make sure that pin is configured as interrupt */
+	reg = d->virt_base + bank->pctl_offset;
+	shift = pin * bank_type->fld_width[PINCFG_TYPE_FUNC];
+	mask = (1 << bank_type->fld_width[PINCFG_TYPE_FUNC]) - 1;
+
+	spin_lock_irqsave(&bank->slock, flags);
+
+	val = readl(reg);
+	val &= ~(mask << shift);
+	val |= bank->eint_func << shift;
+	writel(val, reg);
+
+	spin_unlock_irqrestore(&bank->slock, flags);
+}
+
+static int s3c24xx_eint_type(struct irq_data *data, unsigned int type)
+{
+	struct samsung_pin_bank *bank = irq_data_get_irq_chip_data(data);
+	struct samsung_pinctrl_drv_data *d = bank->drvdata;
+	int index = bank->eint_offset + data->hwirq;
+	void __iomem *reg;
+	int trigger;
+	u8 shift;
+	u32 val;
+
+	trigger = s3c24xx_eint_get_trigger(type);
+	if (trigger < 0) {
+		dev_err(d->dev, "unsupported external interrupt type\n");
+		return -EINVAL;
+	}
+
+	s3c24xx_eint_set_handler(data->irq, type);
+
+	/* Set up interrupt trigger */
+	reg = d->virt_base + EINT_REG(index);
+	shift = EINT_OFFS(index);
+
+	val = readl(reg);
+	val &= ~(EINT_MASK << shift);
+	val |= trigger << shift;
+	writel(val, reg);
+
+	s3c24xx_eint_set_function(d, bank, data->hwirq);
+
+	return 0;
+}
+
+static void s3c24xx_eint0_3_ack(struct irq_data *data)
+{
+	struct samsung_pin_bank *bank = irq_data_get_irq_chip_data(data);
+	struct samsung_pinctrl_drv_data *d = bank->drvdata;
+	struct s3c24xx_eint_domain_data *ddata = bank->irq_domain->host_data;
+	struct s3c24xx_eint_data *eint_data = ddata->eint_data;
+	int parent_irq = eint_data->parents[data->hwirq];
+	struct irq_chip *parent_chip = irq_get_chip(parent_irq);
+
+	if (d->ctrl->type == S3C2412) {
+		unsigned long bitval = 1UL << data->hwirq;
+		writel(bitval, d->virt_base + EINTPEND_REG);
+	}
+
+	if (parent_chip->irq_ack)
+		parent_chip->irq_ack(irq_get_irq_data(parent_irq));
+}
+
+static void s3c24xx_eint0_3_mask(struct irq_data *data)
+{
+	struct samsung_pin_bank *bank = irq_data_get_irq_chip_data(data);
+	struct samsung_pinctrl_drv_data *d = bank->drvdata;
+	struct s3c24xx_eint_domain_data *ddata = bank->irq_domain->host_data;
+	struct s3c24xx_eint_data *eint_data = ddata->eint_data;
+	int parent_irq = eint_data->parents[data->hwirq];
+	struct irq_chip *parent_chip = irq_get_chip(parent_irq);
+
+	if (d->ctrl->type == S3C2412) {
+		unsigned long mask;
+		mask = readl(d->virt_base + EINTMASK_REG);
+		mask |= (1UL << data->hwirq);
+		writel(mask, d->virt_base + EINTMASK_REG);
+	}
+
+	if (parent_chip->irq_mask)
+		parent_chip->irq_mask(irq_get_irq_data(parent_irq));
+}
+
+static void s3c24xx_eint0_3_unmask(struct irq_data *data)
+{
+	struct samsung_pin_bank *bank = irq_data_get_irq_chip_data(data);
+	struct samsung_pinctrl_drv_data *d = bank->drvdata;
+	struct s3c24xx_eint_domain_data *ddata = bank->irq_domain->host_data;
+	struct s3c24xx_eint_data *eint_data = ddata->eint_data;
+	int parent_irq = eint_data->parents[data->hwirq];
+	struct irq_chip *parent_chip = irq_get_chip(parent_irq);
+
+	if (d->ctrl->type == S3C2412) {
+		unsigned long mask;
+		mask = readl(d->virt_base + EINTMASK_REG);
+		mask &= ~(1UL << data->hwirq);
+		writel(mask, d->virt_base + EINTMASK_REG);
+	}
+
+	if (parent_chip->irq_unmask)
+		parent_chip->irq_unmask(irq_get_irq_data(parent_irq));
+}
+
+static struct irq_chip s3c24xx_eint0_3_chip = {
+	.name		= "s3c-eint0_3",
+	.irq_ack	= s3c24xx_eint0_3_ack,
+	.irq_mask	= s3c24xx_eint0_3_mask,
+	.irq_unmask	= s3c24xx_eint0_3_unmask,
+	.irq_set_type	= s3c24xx_eint_type,
+};
+
+static void s3c24xx_eint_ack(struct irq_data *data)
+{
+	struct samsung_pin_bank *bank = irq_data_get_irq_chip_data(data);
+	struct samsung_pinctrl_drv_data *d = bank->drvdata;
+	unsigned char index = bank->eint_offset + data->hwirq;
+
+	writel(1UL << index, d->virt_base + EINTPEND_REG);
+}
+
+static void s3c24xx_eint_mask(struct irq_data *data)
+{
+	struct samsung_pin_bank *bank = irq_data_get_irq_chip_data(data);
+	struct samsung_pinctrl_drv_data *d = bank->drvdata;
+	unsigned char index = bank->eint_offset + data->hwirq;
+	unsigned long mask;
+
+	mask = readl(d->virt_base + EINTMASK_REG);
+	mask |= (1UL << index);
+	writel(mask, d->virt_base + EINTMASK_REG);
+}
+
+static void s3c24xx_eint_unmask(struct irq_data *data)
+{
+	struct samsung_pin_bank *bank = irq_data_get_irq_chip_data(data);
+	struct samsung_pinctrl_drv_data *d = bank->drvdata;
+	unsigned char index = bank->eint_offset + data->hwirq;
+	unsigned long mask;
+
+	mask = readl(d->virt_base + EINTMASK_REG);
+	mask &= ~(1UL << index);
+	writel(mask, d->virt_base + EINTMASK_REG);
+}
+
+static struct irq_chip s3c24xx_eint_chip = {
+	.name		= "s3c-eint",
+	.irq_ack	= s3c24xx_eint_ack,
+	.irq_mask	= s3c24xx_eint_mask,
+	.irq_unmask	= s3c24xx_eint_unmask,
+	.irq_set_type	= s3c24xx_eint_type,
+};
+
+static void s3c24xx_demux_eint0_3(unsigned int irq, struct irq_desc *desc)
+{
+	struct irq_data *data = irq_desc_get_irq_data(desc);
+	struct s3c24xx_eint_data *eint_data = irq_get_handler_data(irq);
+	unsigned int virq;
+
+	/* the first 4 eints have a simple 1 to 1 mapping */
+	virq = irq_linear_revmap(eint_data->domains[data->hwirq], data->hwirq);
+	/* Something must be really wrong if an unmapped EINT
+	 * was unmasked...
+	 */
+	BUG_ON(!virq);
+
+	generic_handle_irq(virq);
+}
+
+static inline void s3c24xx_demux_eint(unsigned int irq, struct irq_desc *desc,
+				      u32 offset, u32 range)
+{
+	struct irq_chip *chip = irq_get_chip(irq);
+	struct s3c24xx_eint_data *data = irq_get_handler_data(irq);
+	struct samsung_pinctrl_drv_data *d = data->drvdata;
+	unsigned int pend, mask;
+
+	chained_irq_enter(chip, desc);
+
+	pend = readl(d->virt_base + EINTPEND_REG);
+	mask = readl(d->virt_base + EINTMASK_REG);
+
+	pend &= ~mask;
+	pend &= range;
+
+	while (pend) {
+		unsigned int virq;
+
+		irq = __ffs(pend);
+		pend &= ~(1 << irq);
+		virq = irq_linear_revmap(data->domains[irq], irq - offset);
+		/* Something must be really wrong if an unmapped EINT
+		 * was unmasked...
+		 */
+		BUG_ON(!virq);
+
+		generic_handle_irq(virq);
+	}
+
+	chained_irq_exit(chip, desc);
+}
+
+static void s3c24xx_demux_eint4_7(unsigned int irq, struct irq_desc *desc)
+{
+	s3c24xx_demux_eint(irq, desc, 0, 0xf0);
+}
+
+static void s3c24xx_demux_eint8_23(unsigned int irq, struct irq_desc *desc)
+{
+	s3c24xx_demux_eint(irq, desc, 8, 0xffff00);
+}
+
+static irq_flow_handler_t s3c24xx_eint_handlers[NUM_EINT_IRQ] = {
+	s3c24xx_demux_eint0_3,
+	s3c24xx_demux_eint0_3,
+	s3c24xx_demux_eint0_3,
+	s3c24xx_demux_eint0_3,
+	s3c24xx_demux_eint4_7,
+	s3c24xx_demux_eint8_23,
+};
+
+static int s3c24xx_gpf_irq_map(struct irq_domain *h, unsigned int virq,
+					irq_hw_number_t hw)
+{
+	struct s3c24xx_eint_domain_data *ddata = h->host_data;
+	struct samsung_pin_bank *bank = ddata->bank;
+
+	if (!(bank->eint_mask & (1 << (bank->eint_offset + hw))))
+		return -EINVAL;
+
+	if (hw <= 3) {
+		irq_set_chip_and_handler(virq, &s3c24xx_eint0_3_chip,
+					 handle_edge_irq);
+		irq_set_chip_data(virq, bank);
+	} else {
+		irq_set_chip_and_handler(virq, &s3c24xx_eint_chip,
+					 handle_edge_irq);
+		irq_set_chip_data(virq, bank);
+	}
+	set_irq_flags(virq, IRQF_VALID);
+	return 0;
+}
+
+static const struct irq_domain_ops s3c24xx_gpf_irq_ops = {
+	.map	= s3c24xx_gpf_irq_map,
+	.xlate	= irq_domain_xlate_twocell,
+};
+
+static int s3c24xx_gpg_irq_map(struct irq_domain *h, unsigned int virq,
+					irq_hw_number_t hw)
+{
+	struct s3c24xx_eint_domain_data *ddata = h->host_data;
+	struct samsung_pin_bank *bank = ddata->bank;
+
+	if (!(bank->eint_mask & (1 << (bank->eint_offset + hw))))
+		return -EINVAL;
+
+	irq_set_chip_and_handler(virq, &s3c24xx_eint_chip, handle_edge_irq);
+	irq_set_chip_data(virq, bank);
+	set_irq_flags(virq, IRQF_VALID);
+	return 0;
+}
+
+static const struct irq_domain_ops s3c24xx_gpg_irq_ops = {
+	.map	= s3c24xx_gpg_irq_map,
+	.xlate	= irq_domain_xlate_twocell,
+};
+
+static const struct of_device_id s3c24xx_eint_irq_ids[] = {
+	{ .compatible = "samsung,s3c24xx-wakeup-eint", },
+	{ }
+};
+
+static int s3c24xx_eint_init(struct samsung_pinctrl_drv_data *d)
+{
+	struct device *dev = d->dev;
+	struct device_node *eint_np = NULL;
+	struct device_node *np;
+	struct samsung_pin_bank *bank;
+	struct s3c24xx_eint_data *eint_data;
+	const struct irq_domain_ops *ops;
+	unsigned int i;
+
+	for_each_child_of_node(dev->of_node, np) {
+		if (of_match_node(s3c24xx_eint_irq_ids, np)) {
+			eint_np = np;
+			break;
+		}
+	}
+	if (!eint_np)
+		return -ENODEV;
+
+	eint_data = devm_kzalloc(dev, sizeof(*eint_data), GFP_KERNEL);
+	if (!eint_data) {
+		dev_err(dev, "could not allocate memory for wkup eint data\n");
+		return -ENOMEM;
+	}
+	eint_data->drvdata = d;
+
+	for (i = 0; i < NUM_EINT_IRQ; ++i) {
+		unsigned int irq;
+
+		irq = irq_of_parse_and_map(eint_np, i);
+		if (!irq) {
+			dev_err(dev, "failed to get wakeup EINT IRQ %d\n", i);
+			return -ENXIO;
+		}
+
+		eint_data->parents[i] = irq;
+		irq_set_chained_handler(irq, s3c24xx_eint_handlers[i]);
+		irq_set_handler_data(irq, eint_data);
+	}
+
+	bank = d->ctrl->pin_banks;
+	for (i = 0; i < d->ctrl->nr_banks; ++i, ++bank) {
+		struct s3c24xx_eint_domain_data *ddata;
+		unsigned int mask;
+		unsigned int irq;
+		unsigned int pin;
+
+		if (bank->eint_type != EINT_TYPE_WKUP)
+			continue;
+
+		ddata = devm_kzalloc(dev, sizeof(*ddata), GFP_KERNEL);
+		if (!ddata) {
+			dev_err(dev, "failed to allocate domain data\n");
+			return -ENOMEM;
+		}
+		ddata->bank = bank;
+		ddata->eint_data = eint_data;
+
+		ops = (bank->eint_offset == 0) ? &s3c24xx_gpf_irq_ops
+					       : &s3c24xx_gpg_irq_ops;
+
+		bank->irq_domain = irq_domain_add_linear(bank->of_node,
+				bank->nr_pins, ops, ddata);
+		if (!bank->irq_domain) {
+			dev_err(dev, "wkup irq domain add failed\n");
+			return -ENXIO;
+		}
+
+		irq = bank->eint_offset;
+		mask = bank->eint_mask;
+		for (pin = 0; mask; ++pin, mask >>= 1) {
+			if (irq > NUM_EINT)
+				break;
+			if (!(mask & 1))
+				continue;
+			eint_data->domains[irq] = bank->irq_domain;
+			++irq;
+		}
+	}
+
+	return 0;
+}
+
+static struct samsung_pin_bank s3c2413_pin_banks[] = {
+	PIN_BANK_A(23, 0x000, "gpa"),
+	PIN_BANK_2BIT(11, 0x010, "gpb"),
+	PIN_BANK_2BIT(16, 0x020, "gpc"),
+	PIN_BANK_2BIT(16, 0x030, "gpd"),
+	PIN_BANK_2BIT(16, 0x040, "gpe"),
+	PIN_BANK_2BIT_EINTW(8, 0x050, "gpf", 0, 0xff),
+	PIN_BANK_2BIT_EINTW(16, 0x060, "gpg", 8, 0xffff00),
+	PIN_BANK_2BIT(11, 0x070, "gph"),
+	PIN_BANK_2BIT(13, 0x080, "gpj"),
+};
+
+struct samsung_pin_ctrl s3c2413_pin_ctrl[] = {
+	{
+		.pin_banks	= s3c2413_pin_banks,
+		.nr_banks	= ARRAY_SIZE(s3c2413_pin_banks),
+		.eint_wkup_init = s3c24xx_eint_init,
+		.label		= "S3C2413-GPIO",
+		.type		= S3C2412,
+	},
+};
+
+static struct samsung_pin_bank s3c2416_pin_banks[] = {
+	PIN_BANK_A(27, 0x000, "gpa"),
+	PIN_BANK_2BIT(11, 0x010, "gpb"),
+	PIN_BANK_2BIT(16, 0x020, "gpc"),
+	PIN_BANK_2BIT(16, 0x030, "gpd"),
+	PIN_BANK_2BIT(16, 0x040, "gpe"),
+	PIN_BANK_2BIT_EINTW(8, 0x050, "gpf", 0, 0xff),
+	PIN_BANK_2BIT_EINTW(8, 0x060, "gpg", 8, 0xff00),
+	PIN_BANK_2BIT(15, 0x070, "gph"),
+	PIN_BANK_2BIT(16, 0x0e0, "gpk"),
+	PIN_BANK_2BIT(14, 0x0f0, "gpl"),
+	PIN_BANK_2BIT(2, 0x100, "gpm"),
+};
+
+struct samsung_pin_ctrl s3c2416_pin_ctrl[] = {
+	{
+		.pin_banks	= s3c2416_pin_banks,
+		.nr_banks	= ARRAY_SIZE(s3c2416_pin_banks),
+		.eint_wkup_init = s3c24xx_eint_init,
+		.label		= "S3C2416-GPIO",
+		.type		= S3C24XX,
+	},
+};
+
+static struct samsung_pin_bank s3c2440_pin_banks[] = {
+	PIN_BANK_A(25, 0x000, "gpa"),
+	PIN_BANK_2BIT(11, 0x010, "gpb"),
+	PIN_BANK_2BIT(16, 0x020, "gpc"),
+	PIN_BANK_2BIT(16, 0x030, "gpd"),
+	PIN_BANK_2BIT(16, 0x040, "gpe"),
+	PIN_BANK_2BIT_EINTW(8, 0x050, "gpf", 0, 0xff),
+	PIN_BANK_2BIT_EINTW(16, 0x060, "gpg", 8, 0xffff00),
+	PIN_BANK_2BIT(11, 0x070, "gph"),
+	PIN_BANK_2BIT(13, 0x0d0, "gpj"),
+};
+
+struct samsung_pin_ctrl s3c2440_pin_ctrl[] = {
+	{
+		.pin_banks	= s3c2440_pin_banks,
+		.nr_banks	= ARRAY_SIZE(s3c2440_pin_banks),
+		.eint_wkup_init = s3c24xx_eint_init,
+		.label		= "S3C2440-GPIO",
+		.type		= S3C24XX,
+	},
+};
+
+static struct samsung_pin_bank s3c2450_pin_banks[] = {
+	PIN_BANK_A(28, 0x000, "gpa"),
+	PIN_BANK_2BIT(11, 0x010, "gpb"),
+	PIN_BANK_2BIT(16, 0x020, "gpc"),
+	PIN_BANK_2BIT(16, 0x030, "gpd"),
+	PIN_BANK_2BIT(16, 0x040, "gpe"),
+	PIN_BANK_2BIT_EINTW(8, 0x050, "gpf", 0, 0xff),
+	PIN_BANK_2BIT_EINTW(16, 0x060, "gpg", 8, 0xffff00),
+	PIN_BANK_2BIT(15, 0x070, "gph"),
+	PIN_BANK_2BIT(16, 0x0d0, "gpj"),
+	PIN_BANK_2BIT(16, 0x0e0, "gpk"),
+	PIN_BANK_2BIT(15, 0x0f0, "gpl"),
+	PIN_BANK_2BIT(2, 0x100, "gpm"),
+};
+
+struct samsung_pin_ctrl s3c2450_pin_ctrl[] = {
+	{
+		.pin_banks	= s3c2450_pin_banks,
+		.nr_banks	= ARRAY_SIZE(s3c2450_pin_banks),
+		.eint_wkup_init = s3c24xx_eint_init,
+		.label		= "S3C2450-GPIO",
+		.type		= S3C24XX,
+	},
+};
diff --git a/drivers/pinctrl/pinctrl-samsung.c b/drivers/pinctrl/pinctrl-samsung.c
index e836135..234c32f 100644
--- a/drivers/pinctrl/pinctrl-samsung.c
+++ b/drivers/pinctrl/pinctrl-samsung.c
@@ -977,6 +977,16 @@ static const struct of_device_id samsung_pinctrl_dt_match[] = {
 	{ .compatible = "samsung,s3c64xx-pinctrl",
 		.data = s3c64xx_pin_ctrl },
 #endif
+#ifdef CONFIG_PINCTRL_S3C24XX
+	{ .compatible = "samsung,s3c2413-pinctrl",
+		.data = s3c2413_pin_ctrl },
+	{ .compatible = "samsung,s3c2416-pinctrl",
+		.data = s3c2416_pin_ctrl },
+	{ .compatible = "samsung,s3c2440-pinctrl",
+		.data = s3c2440_pin_ctrl },
+	{ .compatible = "samsung,s3c2450-pinctrl",
+		.data = s3c2450_pin_ctrl },
+#endif
 	{},
 };
 MODULE_DEVICE_TABLE(of, samsung_pinctrl_dt_match);
diff --git a/drivers/pinctrl/pinctrl-samsung.h b/drivers/pinctrl/pinctrl-samsung.h
index 7c7f9eb..8bd317c 100644
--- a/drivers/pinctrl/pinctrl-samsung.h
+++ b/drivers/pinctrl/pinctrl-samsung.h
@@ -81,6 +81,16 @@ enum eint_type {
 	EINT_TYPE_WKUP_MUX,
 };
 
+/**
+ * enum ctrl_type - variances of a pin controller type
+ * @S3C24XX: generic s3c24xx pin handling
+ * @S3C2412: s3c2412-type eints, existing in the main and eint controllers
+ */
+enum ctrl_type {
+	S3C24XX,
+	S3C2412,
+};
+
 /* maximum length of a pin in pin descriptor (example: "gpa0-0") */
 #define PIN_NAME_LENGTH	10
 
@@ -164,6 +174,7 @@ struct samsung_pin_bank {
  * @eint_wkup_init: platform specific callback to setup the external wakeup
  *	interrupts for the controller.
  * @label: for debug information.
+ * @type: type of pin-controller
  */
 struct samsung_pin_ctrl {
 	struct samsung_pin_bank	*pin_banks;
@@ -185,6 +196,7 @@ struct samsung_pin_ctrl {
 	int		(*eint_gpio_init)(struct samsung_pinctrl_drv_data *);
 	int		(*eint_wkup_init)(struct samsung_pinctrl_drv_data *);
 	char		*label;
+	enum ctrl_type	type;
 };
 
 /**
@@ -246,5 +258,9 @@ extern struct samsung_pin_ctrl exynos4210_pin_ctrl[];
 extern struct samsung_pin_ctrl exynos4x12_pin_ctrl[];
 extern struct samsung_pin_ctrl exynos5250_pin_ctrl[];
 extern struct samsung_pin_ctrl s3c64xx_pin_ctrl[];
+extern struct samsung_pin_ctrl s3c2413_pin_ctrl[];
+extern struct samsung_pin_ctrl s3c2416_pin_ctrl[];
+extern struct samsung_pin_ctrl s3c2440_pin_ctrl[];
+extern struct samsung_pin_ctrl s3c2450_pin_ctrl[];
 
 #endif /* __PINCTRL_SAMSUNG_H */
-- 
1.7.2.3



From khilman at linaro.org  Tue Apr  9 19:40:11 2013
From: khilman at linaro.org (Kevin Hilman)
Date: Tue, 09 Apr 2013 16:40:11 -0700
Subject: [GIT PULL] CPUidle: OMAP cleanups for v3.10
Message-ID: <87txnfz31g.fsf@linaro.org>

[resend with correct address for linux-pm]

Rafael,

Please pull the following OMAP CPUidle changes for v3.10.

Due to dependencies on other CPUidle changes that are already in your
linux-next branch, this branch is based on the commit where you merged
your pm-cpuidle-next branch into linux-next.

Kevin

The following changes since commit f69e44b2059f2238ac558b4a115ebcdefe20b9be:

  Merge branch 'pm-cpuidle-next' into linux-next (2013-04-08 12:32:07 +0200)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git tags/omap-pm-v3.10/cleanup/cpuidle-v2

for you to fetch changes up to db4f3dab629109882170a7b1b8fb655a34c52846:

  ARM: OMAP4+: CPUidle: Consolidate idle driver for OMAP5 support (2013-04-09 09:48:21 -0700)

----------------------------------------------------------------
OMAP CPUidle cleanups for v3.10

----------------------------------------------------------------
Daniel Lezcano (1):
      ARM: omap3: cpuidle: enable time keeping

Santosh Shilimkar (5):
      ARM: OMAP4: CPUidle: Avoid double idle driver registration
      ARM: OMAP: CPUidle: Unregister drivere on device registration failure
      ARM: OMAP4: CPUidle: Make C-state description field more precise
      ARM: OMAP4+: CPUidle: Deprecate use of omap4_mpuss_read_prev_context_state()
      ARM: OMAP4+: CPUidle: Consolidate idle driver for OMAP5 support

 arch/arm/mach-omap2/common.h              |  5 ----
 arch/arm/mach-omap2/cpuidle34xx.c         | 11 +++++--
 arch/arm/mach-omap2/cpuidle44xx.c         | 48 +++++++++++++++++--------------
 arch/arm/mach-omap2/omap-mpuss-lowpower.c | 14 ---------
 4 files changed, 35 insertions(+), 43 deletions(-)


From gveintimilla at freewave.com  Tue Apr  9 19:49:35 2013
From: gveintimilla at freewave.com (Greg Veintimilla)
Date: Tue, 9 Apr 2013 23:49:35 +0000
Subject: [PATCH v9 1/2] ARM: davinci: dm365: add support for v4l2 video
 display
In-Reply-To: <51640004.6020604@ti.com>
References: <1365412636-3468-1-git-send-email-prabhakar.csengg@gmail.com>
 <1365412636-3468-2-git-send-email-prabhakar.csengg@gmail.com>
 <51640004.6020604@ti.com>
Message-ID: <DA5C8125AAC0C2489F8E8E003A30ECAA022E22@MB21.inbox01.com>

Please remove me from this list. Thanks

-----Original Message-----
From: davinci-linux-open-source-bounces+ttran=freewave.com at linux.davincidsp.com [mailto:davinci-linux-open-source-bounces+ttran=freewave.com at linux.davincidsp.com] On Behalf Of Sekhar Nori
Sent: Tuesday, April 09, 2013 5:48 AM
To: Prabhakar lad
Cc: DLOS; LKML; LAK
Subject: Re: [PATCH v9 1/2] ARM: davinci: dm365: add support for v4l2 video display

On 4/8/2013 2:47 PM, Prabhakar lad wrote:
> From: Lad, Prabhakar <prabhakar.csengg at gmail.com>
>
> Create platform devices for various video modules like venc,osd, vpbe
> and v4l2 driver for dm365.
>
> Signed-off-by: Lad, Prabhakar <prabhakar.csengg at gmail.com>
> Acked-by: Sekhar Nori <nsekhar at ti.com>
> ---

> diff --git a/arch/arm/mach-davinci/davinci.h
> b/arch/arm/mach-davinci/davinci.h index 12d544b..a9de512 100644
> --- a/arch/arm/mach-davinci/davinci.h
> +++ b/arch/arm/mach-davinci/davinci.h
> @@ -36,8 +36,13 @@
>  #include <media/davinci/vpbe_osd.h>
>
>  #define DAVINCI_SYSTEM_MODULE_BASE   0x01c40000
> +#define SYSMOD_VDAC_CONFIG           0x2c
>  #define SYSMOD_VIDCLKCTL             0x38
>  #define SYSMOD_VPSS_CLKCTL           0x44
> +#define VPSS_VENCCLKEN_ENABLE                BIT(3)
> +#define VPSS_DACCLKEN_ENABLE         BIT(4)
> +#define VPSS_PLLC2SYSCLK5_ENABLE     BIT(5)
> +

Prabhakar, I noticed it only after I applied these patches, but these bit definitions in between list of register offsets is distracting. Can you please move them down after the register offsets when you send the pull request? You can add a comment /* VPSS CLKCTL bit definitions */ before you start the bit definitions.

>  #define SYSMOD_VDD3P3VPWDN           0x48
>  #define SYSMOD_VSCLKDIS                      0x6c
>  #define SYSMOD_PUPDCTL1                      0x7c

Thanks,
Sekhar
_______________________________________________
Davinci-linux-open-source mailing list
Davinci-linux-open-source at linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
IMPORTANT NOTICE:  This communication, including any attachments, is the property of FreeWave Technologies, Inc. and may contain proprietary, confidential, or privileged information. Unauthorized use or disclosure of this communication is strictly prohibited and may be unlawful. Information contained herein may be subject to a Proprietary Information / Non-Disclosure Agreement and shall be maintained in confidence and not disclosed to third parties without the written consent of FreeWave Technologies, Inc. If you have received this communication in error, please immediately notify the sender and destroy all copies of the communication and any attachments.


From lauraa at codeaurora.org  Tue Apr  9 20:34:56 2013
From: lauraa at codeaurora.org (Laura Abbott)
Date: Tue,  9 Apr 2013 17:34:56 -0700
Subject: [RFC PATCHv2 1/2] arm: highmem: Add support for flushing kmap_atomic
 mappings
Message-ID: <1365554097-21305-1-git-send-email-lauraa@codeaurora.org>

The highmem code provides kmap_flush_unused to ensure all kmap
mappings are really removed if they are unused. This code does not
handle kmap_atomic mappings since they are managed separately.
This prevents an issue for any code which relies on having absolutely
no mappings for a particular page. Rather than pay the penalty of
having CONFIG_DEBUG_HIGHMEM on all the time, add functionality
to remove the kmap_atomic mappings in a similar way to kmap_flush_unused.

Signed-off-by: Laura Abbott <lauraa at codeaurora.org>
---
 arch/arm/Kconfig      |    3 ++
 arch/arm/mm/highmem.c |   57 +++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 60 insertions(+), 0 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 1cacda4..d926d46 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -207,6 +207,9 @@ config NEED_RET_TO_USER
 config ARCH_MTD_XIP
 	bool
 
+config ARCH_WANT_KMAP_ATOMIC_FLUSH
+	bool
+
 config VECTORS_BASE
 	hex
 	default 0xffff0000 if MMU || CPU_HIGH_VECTOR
diff --git a/arch/arm/mm/highmem.c b/arch/arm/mm/highmem.c
index 21b9e1b..fe3d6d9 100644
--- a/arch/arm/mm/highmem.c
+++ b/arch/arm/mm/highmem.c
@@ -10,6 +10,7 @@
  * published by the Free Software Foundation.
  */
 
+#include <linux/cpu.h>
 #include <linux/module.h>
 #include <linux/highmem.h>
 #include <linux/interrupt.h>
@@ -135,3 +136,59 @@ struct page *kmap_atomic_to_page(const void *ptr)
 
 	return pte_page(get_top_pte(vaddr));
 }
+
+#ifdef CONFIG_ARCH_WANT_KMAP_ATOMIC_FLUSH
+static void kmap_remove_unused_cpu(int cpu)
+{
+	int start_idx, idx, type;
+
+	pagefault_disable();
+	type = kmap_atomic_idx();
+	start_idx = type + 1 + KM_TYPE_NR * cpu;
+
+	for (idx = start_idx; idx < KM_TYPE_NR + KM_TYPE_NR * cpu; idx++) {
+		unsigned long vaddr = __fix_to_virt(FIX_KMAP_BEGIN + idx);
+		pte_t ptep;
+
+		ptep = get_top_pte(vaddr);
+		if (ptep)
+			set_top_pte(vaddr, __pte(0));
+	}
+	pagefault_enable();
+}
+
+static void kmap_remove_unused(void *unused)
+{
+	kmap_remove_unused_cpu(smp_processor_id());
+}
+
+void kmap_atomic_flush_unused(void)
+{
+	on_each_cpu(kmap_remove_unused, NULL, 1);
+}
+
+static int hotplug_kmap_atomic_callback(struct notifier_block *nfb,
+                                unsigned long action, void *hcpu)
+{
+        switch (action & (~CPU_TASKS_FROZEN)) {
+        case CPU_DYING:
+		kmap_remove_unused_cpu((int)hcpu);
+                break;
+        default:
+                break;
+        }
+
+        return NOTIFY_OK;
+}
+
+static struct notifier_block hotplug_kmap_atomic_notifier = {
+        .notifier_call = hotplug_kmap_atomic_callback,
+};
+
+static int __init init_kmap_atomic(void)
+{
+
+        return register_hotcpu_notifier(&hotplug_kmap_atomic_notifier);
+}
+early_initcall(init_kmap_atomic);
+#endif
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From lauraa at codeaurora.org  Tue Apr  9 20:34:57 2013
From: lauraa at codeaurora.org (Laura Abbott)
Date: Tue,  9 Apr 2013 17:34:57 -0700
Subject: [RFC PATCHv2 2/2] mm: highmem: Add definitions for
 kmap_atomic_flush_unused
In-Reply-To: <1365554097-21305-1-git-send-email-lauraa@codeaurora.org>
References: <1365554097-21305-1-git-send-email-lauraa@codeaurora.org>
Message-ID: <1365554097-21305-2-git-send-email-lauraa@codeaurora.org>

kmap_flush_unused does not flush kmap_atomic mappings which
are handled separately. Architectures may have use cases to require
these to be flushed. Add an option to let archtectures define
kmap_atomic flushing to get rid of extra mappings.

Signed-off-by: Laura Abbott <lauraa at codeaurora.org>
---
 include/linux/highmem.h |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/include/linux/highmem.h b/include/linux/highmem.h
index 7fb31da..e666549 100644
--- a/include/linux/highmem.h
+++ b/include/linux/highmem.h
@@ -39,6 +39,12 @@ extern unsigned long totalhigh_pages;
 
 void kmap_flush_unused(void);
 
+#ifdef CONFIG_ARCH_WANT_KMAP_ATOMIC_FLUSH
+void kmap_atomic_flush_unused(void);
+#else
+static inline void kmap_atomic_flush_unused(void) { }
+#endif
+
 struct page *kmap_to_page(void *addr);
 
 #else /* CONFIG_HIGHMEM */
@@ -79,6 +85,7 @@ static inline void __kunmap_atomic(void *addr)
 #define kmap_atomic_to_page(ptr)	virt_to_page(ptr)
 
 #define kmap_flush_unused()	do {} while(0)
+#define kmap_atomic_flush_unused()	do {} while(0)
 #endif
 
 #endif /* CONFIG_HIGHMEM */
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From horms at verge.net.au  Tue Apr  9 20:35:38 2013
From: horms at verge.net.au (Simon Horman)
Date: Wed, 10 Apr 2013 09:35:38 +0900
Subject: [PATCH] ARM: shmobile: Include all 2 GiB of memory on APE6EVM
In-Reply-To: <CANqRtoTCYVY9Q6-2wUshSxZzXNsUx4xdY+phf2ZyHmwSyj4SRw@mail.gmail.com>
References: <20130408014444.18767.64441.sendpatchset@w520>
 <20130409123433.GD15412@verge.net.au>
 <20130409161410.GA16003@verge.net.au>
 <CANqRtoTCYVY9Q6-2wUshSxZzXNsUx4xdY+phf2ZyHmwSyj4SRw@mail.gmail.com>
Message-ID: <20130410003535.GA2462@verge.net.au>

On Wed, Apr 10, 2013 at 07:27:41AM +0900, Magnus Damm wrote:
> Hi Simon,
> 
> On Wed, Apr 10, 2013 at 1:14 AM, Simon Horman <horms at verge.net.au> wrote:
> > On Tue, Apr 09, 2013 at 09:34:34PM +0900, Simon Horman wrote:
> >> On Mon, Apr 08, 2013 at 10:44:44AM +0900, Magnus Damm wrote:
> >> > From: Takashi Yoshii <takashi.yoshii.zj at renesas.com>
> >> >
> >> > Add 1GiB of DRAM at 0x2_0000_0000
> >> >
> >> > Signed-off-by: Takashi Yoshii <takashi.yoshii.zj at renesas.com>
> >> > Signed-off-by: Magnus Damm <damm at opensource.se>
> >>
> >> Thanks, queued up in the boards-ape6evm branch.
> >
> > I have dropped this patch as it appears to prevent
> > the board from booting.
> 
> Is it possible that LPAE=n and HIGHMEM=y in your particular kernel
> configuration?

Yes, I have confirmed that is what using the ape6evm_defconfig results in.

> >From what I can tell HIGHMEM is broken in cases of large amounts of
> memory. Try disabling that as a short-term workaround. Then of course
> someone needs to track down why the generic code doesn't work as
> expected.

I have confirmed that disabling HIGHMEM allows the board to boot
with this patch applied.

Should I prepare a patch to the defconfig to accompany this patch?



From horms at verge.net.au  Tue Apr  9 20:41:52 2013
From: horms at verge.net.au (Simon Horman)
Date: Wed, 10 Apr 2013 09:41:52 +0900
Subject: [PATCH 1/2] ARM: shmobile: R8A7778: fix Ether device name
In-Reply-To: <201304092147.51621.sergei.shtylyov@cogentembedded.com>
References: <201304092147.51621.sergei.shtylyov@cogentembedded.com>
Message-ID: <20130410004151.GC2462@verge.net.au>

On Tue, Apr 09, 2013 at 09:47:51PM +0400, Sergei Shtylyov wrote:
> While recasting the commit "ARM: shmobile: R8A7778: add Ether support", I made a
> typo in the platform device's name: used underscore instead of hyphen. 
> 
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
> 
> ---
> The patch is atop of the 'renesas-next-20130410' tag of the 'renesas.git' tree.

Thanks, queued up in the soc-r7a7778 branch.


From horms at verge.net.au  Tue Apr  9 20:42:33 2013
From: horms at verge.net.au (Simon Horman)
Date: Wed, 10 Apr 2013 09:42:33 +0900
Subject: [PATCH 2/2] ARM: shmobile: R8A7779: fix Ether device name
In-Reply-To: <201304092149.00465.sergei.shtylyov@cogentembedded.com>
References: <201304092149.00465.sergei.shtylyov@cogentembedded.com>
Message-ID: <20130410004233.GD2462@verge.net.au>

On Tue, Apr 09, 2013 at 09:48:59PM +0400, Sergei Shtylyov wrote:
> While recasting the commit "ARM: shmobile: R8A7779: add Ether support", I made a
> typo in the platform device's name: used underscore instead of hyphen. 
> 
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
> 
> ---
> The patch is atop of the 'renesas-next-20130410' tag of the 'renesas.git' tree.
> 
>  arch/arm/mach-shmobile/setup-r8a7779.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Thanks, queued up in the soc-r8a7779 branch.


From horms at verge.net.au  Tue Apr  9 20:48:47 2013
From: horms at verge.net.au (Simon Horman)
Date: Wed, 10 Apr 2013 09:48:47 +0900
Subject: [PATCH v3] irqchip: renesas-intc-irqpin: DT binding for sense
 bitfield width
In-Reply-To: <CANqRtoS7fkYd8iX3yAh7xoTNR39UiquWooUSr8+BjbBSUNozFQ@mail.gmail.com>
References: <Pine.LNX.4.64.1304081002190.29945@axis700.grange>
 <CANqRtoS7fkYd8iX3yAh7xoTNR39UiquWooUSr8+BjbBSUNozFQ@mail.gmail.com>
Message-ID: <20130410004846.GF2462@verge.net.au>

On Wed, Apr 10, 2013 at 07:23:06AM +0900, Magnus Damm wrote:
> Hi Guennadi,
> 
> On Mon, Apr 8, 2013 at 5:08 PM, Guennadi Liakhovetski
> <g.liakhovetski at gmx.de> wrote:
> > Most Renesas irqpin controllers have 4-bit sense fields, however, some
> > have different widths. This patch adds a DT binding to optionally
> > specify such non-standard values.
> >
> > Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas at gmail.com>
> > ---
> >
> > v3: move the code to a common location, where device configuration
> > parameters are retrieved
> 
> Thanks for rearranging the code, this looks good to me.
> 
> Acked-by: Magnus Damm <damm at opensource.se>

Thanks, queued-up in the renesas-intc-irqpin branch.

> To be clear, I prefer your approach over a per-SoC compatible string.
> 
> In general I think a per-SoC compatible string is nice in theory, but
> I don't think it is correct to use it to describe a change in a IP
> block that just happens to included in the SoC. Instead the version of
> the IP block shall be used with the compatible value. In some cases it
> may not be easy to retrieve such a version.
> 
> The per-SoC compatible string may look good but they come with at
> least two drawbacks. Either
> 1) the driver has to be updated for each new SoC even though the
> device IP the driver is handling hasn't changed which leads to
> 1.1) more need for pointless per-SoC compatible string patches to be
> merged and tracked and back ported
> and
> 1.2) less chance of running a standard distro lacking per-SoC
> compatible string but has actual code for support
> or
> 2) to ship soon the per-SoC DT will use SoC compatible strings
> matching other SoC names which works but is even more confusing.
> 
> For the INTC irqpin case I believe this approach with a single
> property is the best.
> 
> Thanks,
> 
> / magnus
> 


From horms at verge.net.au  Tue Apr  9 21:08:18 2013
From: horms at verge.net.au (Simon Horman)
Date: Wed, 10 Apr 2013 10:08:18 +0900
Subject: [PATCH/RFC 0/2] ARM: shmobile: DT irqpin for r8a7779 and
 marzen-reference
In-Reply-To: <20130405021339.GZ29203@verge.net.au>
References: <Pine.LNX.4.64.1304031103590.10531@axis700.grange>
 <20130404035426.GC28297@verge.net.au>
 <Pine.LNX.4.64.1304042325140.21548@axis700.grange>
 <20130405014429.GV29203@verge.net.au>
 <20130405021339.GZ29203@verge.net.au>
Message-ID: <20130410010818.GA11105@verge.net.au>

On Fri, Apr 05, 2013 at 11:13:39AM +0900, Simon Horman wrote:
> On Fri, Apr 05, 2013 at 10:44:29AM +0900, Simon Horman wrote:
> > On Thu, Apr 04, 2013 at 11:47:05PM +0200, Guennadi Liakhovetski wrote:
> > > Hi Simon
> > > 
> > > On Thu, 4 Apr 2013, Simon Horman wrote:
> > > 
> > > > On Wed, Apr 03, 2013 at 11:18:57AM +0200, Guennadi Liakhovetski wrote:
> > > > > Hi
> > > > > 
> > > > > This 2 patches add DT irqpin support on marzen-reference. Only 
> > > > > compile-tested due to the lack of hardware. The patches can go 
> > > > > independently via their respective trees. irqpin on marzen will not work 
> > > > > if patch 2 is applied before patch 1, but as long as there are no devices, 
> > > > > using irqpin interrupts, no breakage will be caused.
> > > > 
> > > > I have applied both patches and the dependency I mention below.
> > > > I have also applied the small patch, inlined below, to hook-up
> > > > the LAN controller. Unfortunately it doesn't seem to be receiving
> > > > any interrupts. Perhaps I am missing something?
> > > 
> > > Are you sure 28 is the correct number in the irqpin IRQ space? Seems 
> > > strange to me. Should be 1 perhaps (counting from 0), or 2 - not sure how 
> > > that mapping would look like.
> > 
> > Thanks!
> > 
> > 0 seems to be the lucky number, I have SMSC (and NFS root) working
> > on marzen-reference.
> 
> s/0/1/

After all that it seems that I miss-tested the code somehow.

It turns out that 2 is the lucky number.

> > I have posted "ARM: shmobile: marzen-reference: use irqpin for lan"
> > 
> > > > > Guennadi Liakhovetski (2):
> > > > >       irqchip: renesas-intc-irqpin: DT binding for sense bitfield width
> > > > 
> > > > The above patch depends on "[1/3] ARM: shmobile: irqpin: fix handling of
> > > > spurious interrupts in DT case", right?
> > > 
> > > Not functionally. Spurious interrupts occur on sh73a0, the sense bitfield 
> > > is needed for r8a7779. But the latter won't apply without the former, 
> > > that's right.
> > 
> > Thanks, could you reposts this series rebase so that it doesn't require
> > ""[1/3] ARM: shmobile: irqpin: fix handling of spurious interrupts in DT case"
> > to apply cleanly.
> > 
> > Feel free to break the creation of
> > Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.txt
> > into a separate patch.
> > 
> > Please add "ARM: shmobile: marzen-reference: use irqpin for lan" to
> > the end of the series with an Ack if you have no objections to it.
> > 
> > > > Has there been any progress in your
> > > > discussions with Magnus about what to do about that patch?
> > > 
> > > No, not yet.
> > 
> > Thanks, understood.
> > 
> > And thanks doubly for this series.
> > It is very nice to have bouth irqpin and ethernet working on
> > marzen-reference.
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> > the body of a message to majordomo at vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


From horms+renesas at verge.net.au  Tue Apr  9 21:10:13 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed, 10 Apr 2013 10:10:13 +0900
Subject: [PATCH v2] ARM: shmobile: marzen-reference: use irqpin for lan
Message-ID: <1365556213-11827-1-git-send-email-horms+renesas@verge.net.au>

This corrects the configuration of the SMSC lan controller
to use the newly added irqpin as its IRQ source.

Previously the lan controller did not work. Now it does.

Cc: Guennadi Liakhovetski <g.liakhovetski+renesas at gmail.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>

---

This depends on "[PATCH/RFC 0/2] ARM: shmobile: DT irqpin for r8a7779 and
marzen-reference".

v2
* Use interrupt 2 instead of 1.
  Apparently we should start counting from 1 rather than 0.
---
 arch/arm/boot/dts/r8a7779-marzen-reference.dts |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7779-marzen-reference.dts b/arch/arm/boot/dts/r8a7779-marzen-reference.dts
index 72be4c8..b37c24f 100644
--- a/arch/arm/boot/dts/r8a7779-marzen-reference.dts
+++ b/arch/arm/boot/dts/r8a7779-marzen-reference.dts
@@ -38,8 +38,8 @@
 		compatible = "smsc,lan9220", "smsc,lan9115";
 		reg = <0x18000000 0x100>;
 		phy-mode = "mii";
-		interrupt-parent = <&gic>;
-		interrupts = <0 28 0x4>;
+		interrupt-parent = <&irqpin0>;
+		interrupts = <2 0>;
 		reg-io-width = <4>;
 		vddvario-supply = <&fixedregulator3v3>;
 		vdd33a-supply = <&fixedregulator3v3>;
-- 
1.7.10.4



From horms at verge.net.au  Tue Apr  9 21:11:10 2013
From: horms at verge.net.au (Simon Horman)
Date: Wed, 10 Apr 2013 10:11:10 +0900
Subject: [PATCH/RFC 2/2] ARM: shmobile: marzen-reference: add irqpin
 support in DT
In-Reply-To: <Pine.LNX.4.64.1304031115250.10531@axis700.grange>
References: <Pine.LNX.4.64.1304031103590.10531@axis700.grange>
 <Pine.LNX.4.64.1304031115250.10531@axis700.grange>
Message-ID: <20130410011110.GB11105@verge.net.au>

On Wed, Apr 03, 2013 at 11:19:07AM +0200, Guennadi Liakhovetski wrote:
> Add an irqpin interrupt controller DT node on marzen-reference.
> 
> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas at gmail.com>

Thanks, queued up in the boards-marzen branch.


From horms at verge.net.au  Tue Apr  9 21:12:01 2013
From: horms at verge.net.au (Simon Horman)
Date: Wed, 10 Apr 2013 10:12:01 +0900
Subject: [PATCH v2] ARM: shmobile: marzen-reference: use irqpin for lan
In-Reply-To: <1365556213-11827-1-git-send-email-horms+renesas@verge.net.au>
References: <1365556213-11827-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <20130410011201.GC11105@verge.net.au>

On Wed, Apr 10, 2013 at 10:10:13AM +0900, Simon Horman wrote:
> This corrects the configuration of the SMSC lan controller
> to use the newly added irqpin as its IRQ source.
> 
> Previously the lan controller did not work. Now it does.
> 
> Cc: Guennadi Liakhovetski <g.liakhovetski+renesas at gmail.com>
> Signed-off-by: Simon Horman <horms+renesas at verge.net.au>

Queued up in the marzen-boards branch.


From haojian.zhuang at linaro.org  Tue Apr  9 21:18:24 2013
From: haojian.zhuang at linaro.org (Haojian Zhuang)
Date: Wed, 10 Apr 2013 09:18:24 +0800
Subject: [PATCH 1/3] ARM: pxa: remove cpu_is_xxx in gpio driver
Message-ID: <1365556707-9159-1-git-send-email-haojian.zhuang@linaro.org>

Avoid to use cpu_is_xxx() in pxa gpio driver. Use platform_device_id
to identify the difference.

Signed-off-by: Haojian Zhuang <haojian.zhuang at linaro.org>
---
 arch/arm/mach-mmp/clock-mmp2.c   |    2 +-
 arch/arm/mach-mmp/clock-pxa168.c |    2 +-
 arch/arm/mach-mmp/clock-pxa910.c |    2 +-
 arch/arm/mach-mmp/mmp-dt.c       |    4 +-
 arch/arm/mach-mmp/mmp2-dt.c      |    2 +-
 arch/arm/mach-mmp/mmp2.c         |    2 +-
 arch/arm/mach-mmp/pxa168.c       |    2 +-
 arch/arm/mach-mmp/pxa910.c       |    2 +-
 arch/arm/mach-pxa/devices.c      |   29 ++++++++++-
 arch/arm/mach-pxa/devices.h      |    6 ++-
 arch/arm/mach-pxa/pxa25x.c       |    8 ++-
 arch/arm/mach-pxa/pxa27x.c       |    4 +-
 arch/arm/mach-pxa/pxa3xx.c       |   14 +++--
 arch/arm/mach-pxa/pxa930.c       |    5 ++
 drivers/clk/mmp/clk-mmp2.c       |    2 +-
 drivers/clk/mmp/clk-pxa168.c     |    2 +-
 drivers/clk/mmp/clk-pxa910.c     |    2 +-
 drivers/gpio/gpio-pxa.c          |  106 ++++++++++++++++++++++++++------------
 18 files changed, 140 insertions(+), 56 deletions(-)

diff --git a/arch/arm/mach-mmp/clock-mmp2.c b/arch/arm/mach-mmp/clock-mmp2.c
index 21d2200..53d77cb 100644
--- a/arch/arm/mach-mmp/clock-mmp2.c
+++ b/arch/arm/mach-mmp/clock-mmp2.c
@@ -98,7 +98,7 @@ static struct clk_lookup mmp2_clkregs[] = {
 	INIT_CLKREG(&clk_twsi5, "pxa2xx-i2c.4", NULL),
 	INIT_CLKREG(&clk_twsi6, "pxa2xx-i2c.5", NULL),
 	INIT_CLKREG(&clk_nand, "pxa3xx-nand", NULL),
-	INIT_CLKREG(&clk_gpio, "pxa-gpio", NULL),
+	INIT_CLKREG(&clk_gpio, "mmp2-gpio", NULL),
 	INIT_CLKREG(&clk_sdh0, "sdhci-pxav3.0", "PXA-SDHCLK"),
 	INIT_CLKREG(&clk_sdh1, "sdhci-pxav3.1", "PXA-SDHCLK"),
 	INIT_CLKREG(&clk_sdh2, "sdhci-pxav3.2", "PXA-SDHCLK"),
diff --git a/arch/arm/mach-mmp/clock-pxa168.c b/arch/arm/mach-mmp/clock-pxa168.c
index 5e6c18c..c572f21 100644
--- a/arch/arm/mach-mmp/clock-pxa168.c
+++ b/arch/arm/mach-mmp/clock-pxa168.c
@@ -78,7 +78,7 @@ static struct clk_lookup pxa168_clkregs[] = {
 	INIT_CLKREG(&clk_ssp5, "pxa168-ssp.4", NULL),
 	INIT_CLKREG(&clk_nand, "pxa3xx-nand", NULL),
 	INIT_CLKREG(&clk_lcd, "pxa168-fb", NULL),
-	INIT_CLKREG(&clk_gpio, "pxa-gpio", NULL),
+	INIT_CLKREG(&clk_gpio, "mmp-gpio", NULL),
 	INIT_CLKREG(&clk_keypad, "pxa27x-keypad", NULL),
 	INIT_CLKREG(&clk_eth, "pxa168-eth", "MFUCLK"),
 	INIT_CLKREG(&clk_usb, NULL, "PXA168-USBCLK"),
diff --git a/arch/arm/mach-mmp/clock-pxa910.c b/arch/arm/mach-mmp/clock-pxa910.c
index 933ea71..379e1df 100644
--- a/arch/arm/mach-mmp/clock-pxa910.c
+++ b/arch/arm/mach-mmp/clock-pxa910.c
@@ -56,7 +56,7 @@ static struct clk_lookup pxa910_clkregs[] = {
 	INIT_CLKREG(&clk_pwm3, "pxa910-pwm.2", NULL),
 	INIT_CLKREG(&clk_pwm4, "pxa910-pwm.3", NULL),
 	INIT_CLKREG(&clk_nand, "pxa3xx-nand", NULL),
-	INIT_CLKREG(&clk_gpio, "pxa-gpio", NULL),
+	INIT_CLKREG(&clk_gpio, "mmp-gpio", NULL),
 	INIT_CLKREG(&clk_u2o, NULL, "U2OCLK"),
 	INIT_CLKREG(&clk_rtc, "sa1100-rtc", NULL),
 };
diff --git a/arch/arm/mach-mmp/mmp-dt.c b/arch/arm/mach-mmp/mmp-dt.c
index d063efa..5b890b6 100644
--- a/arch/arm/mach-mmp/mmp-dt.c
+++ b/arch/arm/mach-mmp/mmp-dt.c
@@ -28,7 +28,7 @@ static const struct of_dev_auxdata pxa168_auxdata_lookup[] __initconst = {
 	OF_DEV_AUXDATA("mrvl,mmp-uart", 0xd4026000, "pxa2xx-uart.2", NULL),
 	OF_DEV_AUXDATA("mrvl,mmp-twsi", 0xd4011000, "pxa2xx-i2c.0", NULL),
 	OF_DEV_AUXDATA("mrvl,mmp-twsi", 0xd4025000, "pxa2xx-i2c.1", NULL),
-	OF_DEV_AUXDATA("mrvl,mmp-gpio", 0xd4019000, "pxa-gpio", NULL),
+	OF_DEV_AUXDATA("mrvl,mmp-gpio", 0xd4019000, "mmp-gpio", NULL),
 	OF_DEV_AUXDATA("mrvl,mmp-rtc", 0xd4010000, "sa1100-rtc", NULL),
 	{}
 };
@@ -39,7 +39,7 @@ static const struct of_dev_auxdata pxa910_auxdata_lookup[] __initconst = {
 	OF_DEV_AUXDATA("mrvl,mmp-uart", 0xd4036000, "pxa2xx-uart.2", NULL),
 	OF_DEV_AUXDATA("mrvl,mmp-twsi", 0xd4011000, "pxa2xx-i2c.0", NULL),
 	OF_DEV_AUXDATA("mrvl,mmp-twsi", 0xd4037000, "pxa2xx-i2c.1", NULL),
-	OF_DEV_AUXDATA("mrvl,mmp-gpio", 0xd4019000, "pxa-gpio", NULL),
+	OF_DEV_AUXDATA("mrvl,mmp-gpio", 0xd4019000, "mmp-gpio", NULL),
 	OF_DEV_AUXDATA("mrvl,mmp-rtc", 0xd4010000, "sa1100-rtc", NULL),
 	{}
 };
diff --git a/arch/arm/mach-mmp/mmp2-dt.c b/arch/arm/mach-mmp/mmp2-dt.c
index fad431a..924b6e8 100644
--- a/arch/arm/mach-mmp/mmp2-dt.c
+++ b/arch/arm/mach-mmp/mmp2-dt.c
@@ -31,7 +31,7 @@ static const struct of_dev_auxdata mmp2_auxdata_lookup[] __initconst = {
 	OF_DEV_AUXDATA("mrvl,mmp-uart", 0xd4016000, "pxa2xx-uart.3", NULL),
 	OF_DEV_AUXDATA("mrvl,mmp-twsi", 0xd4011000, "pxa2xx-i2c.0", NULL),
 	OF_DEV_AUXDATA("mrvl,mmp-twsi", 0xd4025000, "pxa2xx-i2c.1", NULL),
-	OF_DEV_AUXDATA("mrvl,mmp-gpio", 0xd4019000, "pxa-gpio", NULL),
+	OF_DEV_AUXDATA("mrvl,mmp-gpio", 0xd4019000, "mmp2-gpio", NULL),
 	OF_DEV_AUXDATA("mrvl,mmp-rtc", 0xd4010000, "sa1100-rtc", NULL),
 	{}
 };
diff --git a/arch/arm/mach-mmp/mmp2.c b/arch/arm/mach-mmp/mmp2.c
index d94d114..c7592f1 100644
--- a/arch/arm/mach-mmp/mmp2.c
+++ b/arch/arm/mach-mmp/mmp2.c
@@ -164,7 +164,7 @@ struct resource mmp2_resource_gpio[] = {
 };
 
 struct platform_device mmp2_device_gpio = {
-	.name		= "pxa-gpio",
+	.name		= "mmp2-gpio",
 	.id		= -1,
 	.num_resources	= ARRAY_SIZE(mmp2_resource_gpio),
 	.resource	= mmp2_resource_gpio,
diff --git a/arch/arm/mach-mmp/pxa168.c b/arch/arm/mach-mmp/pxa168.c
index 9bc7b86..a30dcf3 100644
--- a/arch/arm/mach-mmp/pxa168.c
+++ b/arch/arm/mach-mmp/pxa168.c
@@ -125,7 +125,7 @@ struct resource pxa168_resource_gpio[] = {
 };
 
 struct platform_device pxa168_device_gpio = {
-	.name		= "pxa-gpio",
+	.name		= "mmp-gpio",
 	.id		= -1,
 	.num_resources	= ARRAY_SIZE(pxa168_resource_gpio),
 	.resource	= pxa168_resource_gpio,
diff --git a/arch/arm/mach-mmp/pxa910.c b/arch/arm/mach-mmp/pxa910.c
index 36cb321..ce6393a 100644
--- a/arch/arm/mach-mmp/pxa910.c
+++ b/arch/arm/mach-mmp/pxa910.c
@@ -152,7 +152,7 @@ struct resource pxa910_resource_gpio[] = {
 };
 
 struct platform_device pxa910_device_gpio = {
-	.name		= "pxa-gpio",
+	.name		= "mmp-gpio",
 	.id		= -1,
 	.num_resources	= ARRAY_SIZE(pxa910_resource_gpio),
 	.resource	= pxa910_resource_gpio,
diff --git a/arch/arm/mach-pxa/devices.c b/arch/arm/mach-pxa/devices.c
index daa86d3..6660943 100644
--- a/arch/arm/mach-pxa/devices.c
+++ b/arch/arm/mach-pxa/devices.c
@@ -1107,8 +1107,33 @@ struct resource pxa_resource_gpio[] = {
 	},
 };
 
-struct platform_device pxa_device_gpio = {
-	.name		= "pxa-gpio",
+struct platform_device pxa25x_device_gpio = {
+#ifdef CONFIG_CPU_PXA26x
+	.name		= "pxa26x-gpio",
+#else
+	.name		= "pxa25x-gpio",
+#endif
+	.id		= -1,
+	.num_resources	= ARRAY_SIZE(pxa_resource_gpio),
+	.resource	= pxa_resource_gpio,
+};
+
+struct platform_device pxa27x_device_gpio = {
+	.name		= "pxa27x-gpio",
+	.id		= -1,
+	.num_resources	= ARRAY_SIZE(pxa_resource_gpio),
+	.resource	= pxa_resource_gpio,
+};
+
+struct platform_device pxa3xx_device_gpio = {
+	.name		= "pxa3xx-gpio",
+	.id		= -1,
+	.num_resources	= ARRAY_SIZE(pxa_resource_gpio),
+	.resource	= pxa_resource_gpio,
+};
+
+struct platform_device pxa93x_device_gpio = {
+	.name		= "pxa93x-gpio",
 	.id		= -1,
 	.num_resources	= ARRAY_SIZE(pxa_resource_gpio),
 	.resource	= pxa_resource_gpio,
diff --git a/arch/arm/mach-pxa/devices.h b/arch/arm/mach-pxa/devices.h
index 1475db1..0f3fd0d 100644
--- a/arch/arm/mach-pxa/devices.h
+++ b/arch/arm/mach-pxa/devices.h
@@ -16,7 +16,6 @@ extern struct platform_device pxa_device_ficp;
 extern struct platform_device sa1100_device_rtc;
 extern struct platform_device pxa_device_rtc;
 extern struct platform_device pxa_device_ac97;
-extern struct platform_device pxa_device_gpio;
 
 extern struct platform_device pxa27x_device_i2c_power;
 extern struct platform_device pxa27x_device_ohci;
@@ -46,4 +45,9 @@ extern struct platform_device pxa_device_asoc_ssp2;
 extern struct platform_device pxa_device_asoc_ssp3;
 extern struct platform_device pxa_device_asoc_ssp4;
 
+extern struct platform_device pxa25x_device_gpio;
+extern struct platform_device pxa27x_device_gpio;
+extern struct platform_device pxa3xx_device_gpio;
+extern struct platform_device pxa93x_device_gpio;
+
 void __init pxa_register_device(struct platform_device *dev, void *data);
diff --git a/arch/arm/mach-pxa/pxa25x.c b/arch/arm/mach-pxa/pxa25x.c
index 3f5171e..e31a881 100644
--- a/arch/arm/mach-pxa/pxa25x.c
+++ b/arch/arm/mach-pxa/pxa25x.c
@@ -208,7 +208,11 @@ static struct clk_lookup pxa25x_clkregs[] = {
 	INIT_CLKREG(&clk_pxa25x_gpio11, NULL, "GPIO11_CLK"),
 	INIT_CLKREG(&clk_pxa25x_gpio12, NULL, "GPIO12_CLK"),
 	INIT_CLKREG(&clk_pxa25x_mem, "pxa2xx-pcmcia", NULL),
-	INIT_CLKREG(&clk_dummy, "pxa-gpio", NULL),
+#ifdef CONFIG_CPU_PXA26x
+	INIT_CLKREG(&clk_dummy, "pxa26x-gpio", NULL),
+#else
+	INIT_CLKREG(&clk_dummy, "pxa25x-gpio", NULL),
+#endif
 	INIT_CLKREG(&clk_dummy, "sa1100-rtc", NULL),
 };
 
@@ -375,7 +379,7 @@ static int __init pxa25x_init(void)
 		register_syscore_ops(&pxa2xx_mfp_syscore_ops);
 		register_syscore_ops(&pxa2xx_clock_syscore_ops);
 
-		pxa_register_device(&pxa_device_gpio, &pxa25x_gpio_info);
+		pxa_register_device(&pxa25x_device_gpio, &pxa25x_gpio_info);
 		ret = platform_add_devices(pxa25x_devices,
 					   ARRAY_SIZE(pxa25x_devices));
 		if (ret)
diff --git a/arch/arm/mach-pxa/pxa27x.c b/arch/arm/mach-pxa/pxa27x.c
index 3203a9f..7635ec5 100644
--- a/arch/arm/mach-pxa/pxa27x.c
+++ b/arch/arm/mach-pxa/pxa27x.c
@@ -237,7 +237,7 @@ static struct clk_lookup pxa27x_clkregs[] = {
 	INIT_CLKREG(&clk_pxa27x_im, NULL, "IMCLK"),
 	INIT_CLKREG(&clk_pxa27x_memc, NULL, "MEMCLK"),
 	INIT_CLKREG(&clk_pxa27x_mem, "pxa2xx-pcmcia", NULL),
-	INIT_CLKREG(&clk_dummy, "pxa-gpio", NULL),
+	INIT_CLKREG(&clk_dummy, "pxa27x-gpio", NULL),
 	INIT_CLKREG(&clk_dummy, "sa1100-rtc", NULL),
 };
 
@@ -470,7 +470,7 @@ static int __init pxa27x_init(void)
 		register_syscore_ops(&pxa2xx_mfp_syscore_ops);
 		register_syscore_ops(&pxa2xx_clock_syscore_ops);
 
-		pxa_register_device(&pxa_device_gpio, &pxa27x_gpio_info);
+		pxa_register_device(&pxa27x_device_gpio, &pxa27x_gpio_info);
 		ret = platform_add_devices(devices, ARRAY_SIZE(devices));
 	}
 
diff --git a/arch/arm/mach-pxa/pxa3xx.c b/arch/arm/mach-pxa/pxa3xx.c
index 656a1bb..572666a 100644
--- a/arch/arm/mach-pxa/pxa3xx.c
+++ b/arch/arm/mach-pxa/pxa3xx.c
@@ -92,7 +92,8 @@ static struct clk_lookup pxa3xx_clkregs[] = {
 	INIT_CLKREG(&clk_pxa3xx_mmc1, "pxa2xx-mci.0", NULL),
 	INIT_CLKREG(&clk_pxa3xx_mmc2, "pxa2xx-mci.1", NULL),
 	INIT_CLKREG(&clk_pxa3xx_smemc, "pxa2xx-pcmcia", NULL),
-	INIT_CLKREG(&clk_pxa3xx_gpio, "pxa-gpio", NULL),
+	INIT_CLKREG(&clk_pxa3xx_gpio, "pxa3xx-gpio", NULL),
+	INIT_CLKREG(&clk_pxa3xx_gpio, "pxa93x-gpio", NULL),
 	INIT_CLKREG(&clk_dummy, "sa1100-rtc", NULL),
 };
 
@@ -436,7 +437,6 @@ void __init pxa3xx_set_i2c_power_info(struct i2c_pxa_platform_data *info)
 }
 
 static struct platform_device *devices[] __initdata = {
-	&pxa_device_gpio,
 	&pxa27x_device_udc,
 	&pxa_device_pmu,
 	&pxa_device_i2s,
@@ -482,8 +482,14 @@ static int __init pxa3xx_init(void)
 		register_syscore_ops(&pxa3xx_mfp_syscore_ops);
 		register_syscore_ops(&pxa3xx_clock_syscore_ops);
 
-		if (!of_have_populated_dt())
-			ret = platform_add_devices(devices, ARRAY_SIZE(devices));
+		if (of_have_populated_dt())
+			return 0;
+
+		ret = platform_add_devices(devices, ARRAY_SIZE(devices));
+		if (ret)
+			return ret;
+		if (cpu_is_pxa300() || cpu_is_pxa310() || cpu_is_pxa320())
+			ret = platform_device_register(&pxa3xx_device_gpio);
 	}
 
 	return ret;
diff --git a/arch/arm/mach-pxa/pxa930.c b/arch/arm/mach-pxa/pxa930.c
index 8aeacf9..4693a78 100644
--- a/arch/arm/mach-pxa/pxa930.c
+++ b/arch/arm/mach-pxa/pxa930.c
@@ -18,6 +18,8 @@
 
 #include <mach/pxa930.h>
 
+#include "devices.h"
+
 static struct mfp_addr_map pxa930_mfp_addr_map[] __initdata = {
 
 	MFP_ADDR(GPIO0, 0x02e0),
@@ -192,9 +194,12 @@ static struct mfp_addr_map pxa935_mfp_addr_map[] __initdata = {
 
 static int __init pxa930_init(void)
 {
+	int ret = 0;
+
 	if (cpu_is_pxa93x()) {
 		mfp_init_base(io_p2v(MFPR_BASE));
 		mfp_init_addr(pxa930_mfp_addr_map);
+		ret = platform_device_register(&pxa93x_device_gpio);
 	}
 
 	if (cpu_is_pxa935())
diff --git a/drivers/clk/mmp/clk-mmp2.c b/drivers/clk/mmp/clk-mmp2.c
index ade4358..d1f1a19 100644
--- a/drivers/clk/mmp/clk-mmp2.c
+++ b/drivers/clk/mmp/clk-mmp2.c
@@ -221,7 +221,7 @@ void __init mmp2_clk_init(void)
 
 	clk = mmp_clk_register_apbc("gpio", "vctcxo",
 				apbc_base + APBC_GPIO, 10, 0, &clk_lock);
-	clk_register_clkdev(clk, NULL, "pxa-gpio");
+	clk_register_clkdev(clk, NULL, "mmp2-gpio");
 
 	clk = mmp_clk_register_apbc("kpc", "clk32",
 				apbc_base + APBC_KPC, 10, 0, &clk_lock);
diff --git a/drivers/clk/mmp/clk-pxa168.c b/drivers/clk/mmp/clk-pxa168.c
index e8d036c..28b3b51 100644
--- a/drivers/clk/mmp/clk-pxa168.c
+++ b/drivers/clk/mmp/clk-pxa168.c
@@ -172,7 +172,7 @@ void __init pxa168_clk_init(void)
 
 	clk = mmp_clk_register_apbc("gpio", "vctcxo",
 				apbc_base + APBC_GPIO, 10, 0, &clk_lock);
-	clk_register_clkdev(clk, NULL, "pxa-gpio");
+	clk_register_clkdev(clk, NULL, "mmp-gpio");
 
 	clk = mmp_clk_register_apbc("kpc", "clk32",
 				apbc_base + APBC_KPC, 10, 0, &clk_lock);
diff --git a/drivers/clk/mmp/clk-pxa910.c b/drivers/clk/mmp/clk-pxa910.c
index 7048c31..6ec0569 100644
--- a/drivers/clk/mmp/clk-pxa910.c
+++ b/drivers/clk/mmp/clk-pxa910.c
@@ -177,7 +177,7 @@ void __init pxa910_clk_init(void)
 
 	clk = mmp_clk_register_apbc("gpio", "vctcxo",
 				apbc_base + APBC_GPIO, 10, 0, &clk_lock);
-	clk_register_clkdev(clk, NULL, "pxa-gpio");
+	clk_register_clkdev(clk, NULL, "mmp-gpio");
 
 	clk = mmp_clk_register_apbc("kpc", "clk32",
 				apbc_base + APBC_KPC, 10, 0, &clk_lock);
diff --git a/drivers/gpio/gpio-pxa.c b/drivers/gpio/gpio-pxa.c
index 9ee9f86..6d53882 100644
--- a/drivers/gpio/gpio-pxa.c
+++ b/drivers/gpio/gpio-pxa.c
@@ -85,20 +85,61 @@ struct pxa_gpio_chip {
 #endif
 };
 
-enum {
+enum pxa_gpio_type {
 	PXA25X_GPIO = 0,
 	PXA26X_GPIO,
 	PXA27X_GPIO,
 	PXA3XX_GPIO,
 	PXA93X_GPIO,
 	MMP_GPIO = 0x10,
+	MMP2_GPIO,
+};
+
+struct pxa_gpio_id {
+	enum pxa_gpio_type	type;
+	int			gpio_nums;
 };
 
 static DEFINE_SPINLOCK(gpio_lock);
 static struct pxa_gpio_chip *pxa_gpio_chips;
-static int gpio_type;
+static enum pxa_gpio_type gpio_type;
 static void __iomem *gpio_reg_base;
 
+static struct pxa_gpio_id pxa25x_id = {
+	.type		= PXA25X_GPIO,
+	.gpio_nums	= 85,
+};
+
+static struct pxa_gpio_id pxa26x_id = {
+	.type		= PXA26X_GPIO,
+	.gpio_nums	= 90,
+};
+
+static struct pxa_gpio_id pxa27x_id = {
+	.type		= PXA27X_GPIO,
+	.gpio_nums	= 121,
+};
+
+static struct pxa_gpio_id pxa3xx_id = {
+	.type		= PXA3XX_GPIO,
+	.gpio_nums	= 128,
+};
+
+static struct pxa_gpio_id pxa93x_id = {
+	.type		= PXA93X_GPIO,
+	.gpio_nums	= 192,
+};
+
+static struct pxa_gpio_id mmp_id = {
+	.type		= MMP_GPIO,
+	.gpio_nums	= 128,
+};
+
+static struct pxa_gpio_id mmp2_id = {
+	.type		= MMP2_GPIO,
+	.gpio_nums	= 192,
+};
+
 #define for_each_gpio_chip(i, c)			\
 	for (i = 0, c = &pxa_gpio_chips[0]; i <= pxa_last_gpio; i += 32, c++)
 
@@ -431,40 +472,27 @@ static struct irq_chip pxa_muxed_gpio_chip = {
 	.irq_set_wake	= pxa_gpio_set_wake,
 };
 
-static int pxa_gpio_nums(void)
+static int pxa_gpio_nums(struct platform_device *pdev)
 {
+	const struct platform_device_id *id = platform_get_device_id(pdev);
+	struct pxa_gpio_id *pxa_id = (struct pxa_gpio_id *)id->driver_data;
 	int count = 0;
 
-#ifdef CONFIG_ARCH_PXA
-	if (cpu_is_pxa25x()) {
-#ifdef CONFIG_CPU_PXA26x
-		count = 89;
-		gpio_type = PXA26X_GPIO;
-#elif defined(CONFIG_PXA25x)
-		count = 84;
-		gpio_type = PXA26X_GPIO;
-#endif /* CONFIG_CPU_PXA26x */
-	} else if (cpu_is_pxa27x()) {
-		count = 120;
-		gpio_type = PXA27X_GPIO;
-	} else if (cpu_is_pxa93x()) {
-		count = 191;
-		gpio_type = PXA93X_GPIO;
-	} else if (cpu_is_pxa3xx()) {
-		count = 127;
-		gpio_type = PXA3XX_GPIO;
-	}
-#endif /* CONFIG_ARCH_PXA */
-
-#ifdef CONFIG_ARCH_MMP
-	if (cpu_is_pxa168() || cpu_is_pxa910()) {
-		count = 127;
-		gpio_type = MMP_GPIO;
-	} else if (cpu_is_mmp2()) {
-		count = 191;
-		gpio_type = MMP_GPIO;
+	switch (pxa_id->type) {
+	case PXA25X_GPIO:
+	case PXA26X_GPIO:
+	case PXA27X_GPIO:
+	case PXA3XX_GPIO:
+	case PXA93X_GPIO:
+	case MMP_GPIO:
+	case MMP2_GPIO:
+		gpio_type = pxa_id->type;
+		count = pxa_id->gpio_nums - 1;
+		break;
+	default:
+		count = -EINVAL;
+		break;
 	}
-#endif /* CONFIG_ARCH_MMP */
 	return count;
 }
 
@@ -547,7 +575,7 @@ static int pxa_gpio_probe(struct platform_device *pdev)
 
 	ret = pxa_gpio_probe_dt(pdev);
 	if (ret < 0) {
-		pxa_last_gpio = pxa_gpio_nums();
+		pxa_last_gpio = pxa_gpio_nums(pdev);
 #ifdef CONFIG_ARCH_PXA
 		if (gpio_is_pxa_type(gpio_type))
 			irq_base = PXA_GPIO_TO_IRQ(0);
@@ -634,12 +662,24 @@ static int pxa_gpio_probe(struct platform_device *pdev)
 	return 0;
 }
 
+static const struct platform_device_id gpio_id_table[] = {
+	{ "pxa25x-gpio",	(unsigned long)&pxa25x_id },
+	{ "pxa26x-gpio",	(unsigned long)&pxa26x_id },
+	{ "pxa27x-gpio",	(unsigned long)&pxa27x_id },
+	{ "pxa3xx-gpio",	(unsigned long)&pxa3xx_id },
+	{ "pxa93x-gpio",	(unsigned long)&pxa93x_id },
+	{ "mmp-gpio",		(unsigned long)&mmp_id },
+	{ "mmp2-gpio",		(unsigned long)&mmp2_id },
+	{ },
+};
+
 static struct platform_driver pxa_gpio_driver = {
 	.probe		= pxa_gpio_probe,
 	.driver		= {
 		.name	= "pxa-gpio",
 		.of_match_table = of_match_ptr(pxa_gpio_dt_ids),
 	},
+	.id_table	= gpio_id_table,
 };
 module_platform_driver(pxa_gpio_driver);
 
-- 
1.7.10.4



From haojian.zhuang at linaro.org  Tue Apr  9 21:18:25 2013
From: haojian.zhuang at linaro.org (Haojian Zhuang)
Date: Wed, 10 Apr 2013 09:18:25 +0800
Subject: [PATCH 2/3] ARM: pxa: move PXA_GPIO_TO_IRQ macro
In-Reply-To: <1365556707-9159-1-git-send-email-haojian.zhuang@linaro.org>
References: <1365556707-9159-1-git-send-email-haojian.zhuang@linaro.org>
Message-ID: <1365556707-9159-2-git-send-email-haojian.zhuang@linaro.org>

Since PXA_GPIO_TO_IRQ() & MMP_GPIO_TO_IRQ() macro are depended on
arch code, move them from gpio driver to platform driver instead.

Signed-off-by: Haojian Zhuang <haojian.zhuang at linaro.org>
---
 arch/arm/mach-mmp/aspenite.c      |    7 +++++++
 arch/arm/mach-mmp/avengers_lite.c |    7 +++++++
 arch/arm/mach-mmp/brownstone.c    |    7 +++++++
 arch/arm/mach-mmp/flint.c         |    7 +++++++
 arch/arm/mach-mmp/gplugd.c        |    7 +++++++
 arch/arm/mach-mmp/jasper.c        |    8 ++++++++
 arch/arm/mach-mmp/tavorevb.c      |    7 +++++++
 arch/arm/mach-mmp/teton_bga.c     |    7 +++++++
 arch/arm/mach-mmp/ttc_dkb.c       |    7 +++++++
 arch/arm/mach-pxa/pxa25x.c        |    3 ++-
 arch/arm/mach-pxa/pxa27x.c        |    3 ++-
 arch/arm/mach-pxa/pxa3xx.c        |   11 ++++++++++-
 arch/arm/mach-pxa/pxa930.c        |   12 ++++++++++--
 drivers/gpio/gpio-pxa.c           |   20 +++++++++-----------
 include/linux/gpio-pxa.h          |    1 +
 15 files changed, 98 insertions(+), 16 deletions(-)

diff --git a/arch/arm/mach-mmp/aspenite.c b/arch/arm/mach-mmp/aspenite.c
index 76901f4..5b660ec 100644
--- a/arch/arm/mach-mmp/aspenite.c
+++ b/arch/arm/mach-mmp/aspenite.c
@@ -9,6 +9,7 @@
  *  publishhed by the Free Software Foundation.
  */
 #include <linux/gpio.h>
+#include <linux/gpio-pxa.h>
 #include <linux/init.h>
 #include <linux/kernel.h>
 #include <linux/platform_device.h>
@@ -110,6 +111,10 @@ static unsigned long common_pin_config[] __initdata = {
 	GPIO121_KP_MKIN4,
 };
 
+static struct pxa_gpio_platform_data pxa168_gpio_pdata = {
+	.irq_base	= MMP_GPIO_TO_IRQ(0),
+};
+
 static struct smc91x_platdata smc91x_info = {
 	.flags	= SMC91X_USE_16BIT | SMC91X_NOWAIT,
 };
@@ -242,6 +247,8 @@ static void __init common_init(void)
 	pxa168_add_nand(&aspenite_nand_info);
 	pxa168_add_fb(&aspenite_lcd_info);
 	pxa168_add_keypad(&aspenite_keypad_info);
+	platform_device_add_data(&pxa168_device_gpio, &pxa168_gpio_pdata,
+				 sizeof(struct pxa_gpio_platform_data));
 	platform_device_register(&pxa168_device_gpio);
 
 	/* off-chip devices */
diff --git a/arch/arm/mach-mmp/avengers_lite.c b/arch/arm/mach-mmp/avengers_lite.c
index 1f94957..a451a0f 100644
--- a/arch/arm/mach-mmp/avengers_lite.c
+++ b/arch/arm/mach-mmp/avengers_lite.c
@@ -12,6 +12,7 @@
 
 #include <linux/init.h>
 #include <linux/kernel.h>
+#include <linux/gpio-pxa.h>
 #include <linux/platform_device.h>
 
 #include <asm/mach-types.h>
@@ -32,12 +33,18 @@ static unsigned long avengers_lite_pin_config_V16F[] __initdata = {
 	GPIO89_UART2_RXD,
 };
 
+static struct pxa_gpio_platform_data pxa168_gpio_pdata = {
+	.irq_base	= MMP_GPIO_TO_IRQ(0),
+};
+
 static void __init avengers_lite_init(void)
 {
 	mfp_config(ARRAY_AND_SIZE(avengers_lite_pin_config_V16F));
 
 	/* on-chip devices */
 	pxa168_add_uart(2);
+	platform_device_add_data(&pxa168_device_gpio, &pxa168_gpio_pdata,
+				 sizeof(struct pxa_gpio_platform_data));
 	platform_device_register(&pxa168_device_gpio);
 }
 
diff --git a/arch/arm/mach-mmp/brownstone.c b/arch/arm/mach-mmp/brownstone.c
index 2358011..ac25544 100644
--- a/arch/arm/mach-mmp/brownstone.c
+++ b/arch/arm/mach-mmp/brownstone.c
@@ -14,6 +14,7 @@
 #include <linux/kernel.h>
 #include <linux/platform_device.h>
 #include <linux/io.h>
+#include <linux/gpio-pxa.h>
 #include <linux/regulator/machine.h>
 #include <linux/regulator/max8649.h>
 #include <linux/regulator/fixed.h>
@@ -104,6 +105,10 @@ static unsigned long brownstone_pin_config[] __initdata = {
 	GPIO89_GPIO,
 };
 
+static struct pxa_gpio_platform_data mmp2_gpio_pdata = {
+	.irq_base	= MMP_GPIO_TO_IRQ(0),
+};
+
 static struct regulator_consumer_supply max8649_supply[] = {
 	REGULATOR_SUPPLY("vcc_core", NULL),
 };
@@ -202,6 +207,8 @@ static void __init brownstone_init(void)
 	/* on-chip devices */
 	mmp2_add_uart(1);
 	mmp2_add_uart(3);
+	platform_device_add_data(&mmp2_device_gpio, &mmp2_gpio_pdata,
+				 sizeof(struct pxa_gpio_platform_data));
 	platform_device_register(&mmp2_device_gpio);
 	mmp2_add_twsi(1, NULL, ARRAY_AND_SIZE(brownstone_twsi1_info));
 	mmp2_add_sdhost(0, &mmp2_sdh_platdata_mmc0); /* SD/MMC */
diff --git a/arch/arm/mach-mmp/flint.c b/arch/arm/mach-mmp/flint.c
index 754c352..6291c33 100644
--- a/arch/arm/mach-mmp/flint.c
+++ b/arch/arm/mach-mmp/flint.c
@@ -16,6 +16,7 @@
 #include <linux/smc91x.h>
 #include <linux/io.h>
 #include <linux/gpio.h>
+#include <linux/gpio-pxa.h>
 #include <linux/interrupt.h>
 
 #include <asm/mach-types.h>
@@ -77,6 +78,10 @@ static unsigned long flint_pin_config[] __initdata = {
 	GPIO160_ND_RDY1,
 };
 
+static struct pxa_gpio_platform_data mmp2_gpio_pdata = {
+	.irq_base	= MMP_GPIO_TO_IRQ(0),
+};
+
 static struct smc91x_platdata flint_smc91x_info = {
 	.flags  = SMC91X_USE_16BIT | SMC91X_NOWAIT,
 };
@@ -111,6 +116,8 @@ static void __init flint_init(void)
 	/* on-chip devices */
 	mmp2_add_uart(1);
 	mmp2_add_uart(2);
+	platform_device_add_data(&mmp2_device_gpio, &mmp2_gpio_pdata,
+				 sizeof(struct pxa_gpio_platform_data));
 	platform_device_register(&mmp2_device_gpio);
 
 	/* off-chip devices */
diff --git a/arch/arm/mach-mmp/gplugd.c b/arch/arm/mach-mmp/gplugd.c
index f62b68d..d81b247 100644
--- a/arch/arm/mach-mmp/gplugd.c
+++ b/arch/arm/mach-mmp/gplugd.c
@@ -11,6 +11,7 @@
 #include <linux/init.h>
 #include <linux/platform_device.h>
 #include <linux/gpio.h>
+#include <linux/gpio-pxa.h>
 
 #include <asm/mach/arch.h>
 #include <asm/mach-types.h>
@@ -128,6 +129,10 @@ static unsigned long gplugd_pin_config[] __initdata = {
 	GPIO116_I2S_TXD
 };
 
+static struct pxa_gpio_platform_data pxa168_gpio_pdata = {
+	.irq_base	= MMP_GPIO_TO_IRQ(0),
+};
+
 static struct i2c_board_info gplugd_i2c_board_info[] = {
 	{
 		.type = "isl1208",
@@ -186,6 +191,8 @@ static void __init gplugd_init(void)
 	pxa168_add_uart(3);
 	pxa168_add_ssp(1);
 	pxa168_add_twsi(0, NULL, ARRAY_AND_SIZE(gplugd_i2c_board_info));
+	platform_device_add_data(&pxa168_device_gpio, &pxa168_gpio_pdata,
+				 sizeof(struct pxa_gpio_platform_data));
 	platform_device_register(&pxa168_device_gpio);
 
 	pxa168_add_eth(&gplugd_eth_platform_data);
diff --git a/arch/arm/mach-mmp/jasper.c b/arch/arm/mach-mmp/jasper.c
index 66634fd..0e9e5c0 100644
--- a/arch/arm/mach-mmp/jasper.c
+++ b/arch/arm/mach-mmp/jasper.c
@@ -12,6 +12,7 @@
 
 #include <linux/init.h>
 #include <linux/kernel.h>
+#include <linux/gpio-pxa.h>
 #include <linux/platform_device.h>
 #include <linux/io.h>
 #include <linux/regulator/machine.h>
@@ -99,6 +100,10 @@ static unsigned long jasper_pin_config[] __initdata = {
 	GPIO151_MMC3_CLK,
 };
 
+static struct pxa_gpio_platform_data mmp2_gpio_pdata = {
+	.irq_base	= MMP_GPIO_TO_IRQ(0),
+};
+
 static struct regulator_consumer_supply max8649_supply[] = {
 	REGULATOR_SUPPLY("vcc_core", NULL),
 };
@@ -165,6 +170,9 @@ static void __init jasper_init(void)
 	mmp2_add_uart(1);
 	mmp2_add_uart(3);
 	mmp2_add_twsi(1, NULL, ARRAY_AND_SIZE(jasper_twsi1_info));
+	platform_device_add_data(&mmp2_device_gpio, &mmp2_gpio_pdata,
+				 sizeof(struct pxa_gpio_platform_data));
+	platform_device_register(&mmp2_device_gpio);
 	mmp2_add_sdhost(0, &mmp2_sdh_platdata_mmc0); /* SD/MMC */
 
 	regulator_has_full_constraints();
diff --git a/arch/arm/mach-mmp/tavorevb.c b/arch/arm/mach-mmp/tavorevb.c
index 4c127d2..cdfc9bf 100644
--- a/arch/arm/mach-mmp/tavorevb.c
+++ b/arch/arm/mach-mmp/tavorevb.c
@@ -8,6 +8,7 @@
  *  publishhed by the Free Software Foundation.
  */
 #include <linux/gpio.h>
+#include <linux/gpio-pxa.h>
 #include <linux/init.h>
 #include <linux/kernel.h>
 #include <linux/platform_device.h>
@@ -60,6 +61,10 @@ static unsigned long tavorevb_pin_config[] __initdata = {
 	DF_RDY0_DF_RDY0,
 };
 
+static struct pxa_gpio_platform_data pxa910_gpio_pdata = {
+	.irq_base	= MMP_GPIO_TO_IRQ(0),
+};
+
 static struct smc91x_platdata tavorevb_smc91x_info = {
 	.flags	= SMC91X_USE_16BIT | SMC91X_NOWAIT,
 };
@@ -93,6 +98,8 @@ static void __init tavorevb_init(void)
 
 	/* on-chip devices */
 	pxa910_add_uart(1);
+	platform_device_add_data(&pxa910_device_gpio, &pxa910_gpio_pdata,
+				 sizeof(struct pxa_gpio_platform_data));
 	platform_device_register(&pxa910_device_gpio);
 
 	/* off-chip devices */
diff --git a/arch/arm/mach-mmp/teton_bga.c b/arch/arm/mach-mmp/teton_bga.c
index 8609967..e4d95b4 100644
--- a/arch/arm/mach-mmp/teton_bga.c
+++ b/arch/arm/mach-mmp/teton_bga.c
@@ -16,6 +16,7 @@
 #include <linux/kernel.h>
 #include <linux/platform_device.h>
 #include <linux/gpio.h>
+#include <linux/gpio-pxa.h>
 #include <linux/input.h>
 #include <linux/platform_data/keypad-pxa27x.h>
 #include <linux/i2c.h>
@@ -49,6 +50,10 @@ static unsigned long teton_bga_pin_config[] __initdata = {
 	GPIO78_GPIO,
 };
 
+static struct pxa_gpio_platform_data pxa168_gpio_pdata = {
+	.irq_base	= MMP_GPIO_TO_IRQ(0),
+};
+
 static unsigned int teton_bga_matrix_key_map[] = {
 	KEY(0, 6, KEY_ESC),
 	KEY(0, 7, KEY_ENTER),
@@ -79,6 +84,8 @@ static void __init teton_bga_init(void)
 	pxa168_add_uart(1);
 	pxa168_add_keypad(&teton_bga_keypad_info);
 	pxa168_add_twsi(0, NULL, ARRAY_AND_SIZE(teton_bga_i2c_info));
+	platform_device_add_data(&pxa168_device_gpio, &pxa168_gpio_pdata,
+				 sizeof(struct pxa_gpio_platform_data));
 	platform_device_register(&pxa168_device_gpio);
 }
 
diff --git a/arch/arm/mach-mmp/ttc_dkb.c b/arch/arm/mach-mmp/ttc_dkb.c
index 6528a5f..8483906 100644
--- a/arch/arm/mach-mmp/ttc_dkb.c
+++ b/arch/arm/mach-mmp/ttc_dkb.c
@@ -17,6 +17,7 @@
 #include <linux/interrupt.h>
 #include <linux/i2c/pca953x.h>
 #include <linux/gpio.h>
+#include <linux/gpio-pxa.h>
 #include <linux/mfd/88pm860x.h>
 #include <linux/platform_data/mv_usb.h>
 #include <linux/spi/spi.h>
@@ -75,6 +76,10 @@ static unsigned long ttc_dkb_pin_config[] __initdata = {
 	DF_RDY0_DF_RDY0,
 };
 
+static struct pxa_gpio_platform_data pxa910_gpio_pdata = {
+	.irq_base	= MMP_GPIO_TO_IRQ(0),
+};
+
 static struct mtd_partition ttc_dkb_onenand_partitions[] = {
 	{
 		.name		= "bootloader",
@@ -278,6 +283,8 @@ static void __init ttc_dkb_init(void)
 
 	/* off-chip devices */
 	pxa910_add_twsi(0, NULL, ARRAY_AND_SIZE(ttc_dkb_i2c_info));
+	platform_device_add_data(&pxa910_device_gpio, &pxa910_gpio_pdata,
+				 sizeof(struct pxa_gpio_platform_data));
 	platform_add_devices(ARRAY_AND_SIZE(ttc_dkb_devices));
 
 #ifdef CONFIG_USB_MV_UDC
diff --git a/arch/arm/mach-pxa/pxa25x.c b/arch/arm/mach-pxa/pxa25x.c
index e31a881..f2c2897 100644
--- a/arch/arm/mach-pxa/pxa25x.c
+++ b/arch/arm/mach-pxa/pxa25x.c
@@ -344,7 +344,8 @@ void __init pxa25x_map_io(void)
 }
 
 static struct pxa_gpio_platform_data pxa25x_gpio_info __initdata = {
-	.gpio_set_wake = gpio_set_wake,
+	.irq_base	= PXA_GPIO_TO_IRQ(0),
+	.gpio_set_wake	= gpio_set_wake,
 };
 
 static struct platform_device *pxa25x_devices[] __initdata = {
diff --git a/arch/arm/mach-pxa/pxa27x.c b/arch/arm/mach-pxa/pxa27x.c
index 7635ec5..301471a 100644
--- a/arch/arm/mach-pxa/pxa27x.c
+++ b/arch/arm/mach-pxa/pxa27x.c
@@ -431,7 +431,8 @@ void __init pxa27x_set_i2c_power_info(struct i2c_pxa_platform_data *info)
 }
 
 static struct pxa_gpio_platform_data pxa27x_gpio_info __initdata = {
-	.gpio_set_wake = gpio_set_wake,
+	.irq_base	= PXA_GPIO_TO_IRQ(0),
+	.gpio_set_wake	= gpio_set_wake,
 };
 
 static struct platform_device *devices[] __initdata = {
diff --git a/arch/arm/mach-pxa/pxa3xx.c b/arch/arm/mach-pxa/pxa3xx.c
index 572666a..87011f3 100644
--- a/arch/arm/mach-pxa/pxa3xx.c
+++ b/arch/arm/mach-pxa/pxa3xx.c
@@ -15,6 +15,7 @@
 #include <linux/module.h>
 #include <linux/kernel.h>
 #include <linux/init.h>
+#include <linux/gpio-pxa.h>
 #include <linux/pm.h>
 #include <linux/platform_device.h>
 #include <linux/irq.h>
@@ -436,6 +437,10 @@ void __init pxa3xx_set_i2c_power_info(struct i2c_pxa_platform_data *info)
 	pxa_register_device(&pxa3xx_device_i2c_power, info);
 }
 
+static struct pxa_gpio_platform_data pxa3xx_gpio_pdata = {
+	.irq_base	= PXA_GPIO_TO_IRQ(0),
+};
+
 static struct platform_device *devices[] __initdata = {
 	&pxa27x_device_udc,
 	&pxa_device_pmu,
@@ -488,8 +493,12 @@ static int __init pxa3xx_init(void)
 		ret = platform_add_devices(devices, ARRAY_SIZE(devices));
 		if (ret)
 			return ret;
-		if (cpu_is_pxa300() || cpu_is_pxa310() || cpu_is_pxa320())
+		if (cpu_is_pxa300() || cpu_is_pxa310() || cpu_is_pxa320()) {
+			platform_device_add_data(&pxa3xx_device_gpio,
+						 &pxa3xx_gpio_pdata,
+						 sizeof(pxa3xx_gpio_pdata));
 			ret = platform_device_register(&pxa3xx_device_gpio);
+		}
 	}
 
 	return ret;
diff --git a/arch/arm/mach-pxa/pxa930.c b/arch/arm/mach-pxa/pxa930.c
index 4693a78..ab62448 100644
--- a/arch/arm/mach-pxa/pxa930.c
+++ b/arch/arm/mach-pxa/pxa930.c
@@ -12,9 +12,10 @@
 
 #include <linux/module.h>
 #include <linux/kernel.h>
-#include <linux/platform_device.h>
-#include <linux/irq.h>
 #include <linux/dma-mapping.h>
+#include <linux/irq.h>
+#include <linux/gpio-pxa.h>
+#include <linux/platform_device.h>
 
 #include <mach/pxa930.h>
 
@@ -192,6 +193,10 @@ static struct mfp_addr_map pxa935_mfp_addr_map[] __initdata = {
 	MFP_ADDR_END,
 };
 
+static struct pxa_gpio_platform_data pxa93x_gpio_pdata = {
+	.irq_base	= PXA_GPIO_TO_IRQ(0),
+};
+
 static int __init pxa930_init(void)
 {
 	int ret = 0;
@@ -199,6 +204,9 @@ static int __init pxa930_init(void)
 	if (cpu_is_pxa93x()) {
 		mfp_init_base(io_p2v(MFPR_BASE));
 		mfp_init_addr(pxa930_mfp_addr_map);
+		platform_device_add_data(&pxa93x_device_gpio,
+					 &pxa93x_gpio_pdata,
+					 sizeof(pxa93x_gpio_pdata));
 		ret = platform_device_register(&pxa93x_device_gpio);
 	}
 
diff --git a/drivers/gpio/gpio-pxa.c b/drivers/gpio/gpio-pxa.c
index 6d53882..f4b0737 100644
--- a/drivers/gpio/gpio-pxa.c
+++ b/drivers/gpio/gpio-pxa.c
@@ -573,19 +573,18 @@ static int pxa_gpio_probe(struct platform_device *pdev)
 	int gpio, irq, ret, use_of = 0;
 	int irq0 = 0, irq1 = 0, irq_mux, gpio_offset = 0;
 
-	ret = pxa_gpio_probe_dt(pdev);
-	if (ret < 0) {
+	info = dev_get_platdata(&pdev->dev);
+	if (info) {
+		irq_base = info->irq_base;
+		if (irq_base <= 0)
+			return -EINVAL;
 		pxa_last_gpio = pxa_gpio_nums(pdev);
-#ifdef CONFIG_ARCH_PXA
-		if (gpio_is_pxa_type(gpio_type))
-			irq_base = PXA_GPIO_TO_IRQ(0);
-#endif
-#ifdef CONFIG_ARCH_MMP
-		if (gpio_is_mmp_type(gpio_type))
-			irq_base = MMP_GPIO_TO_IRQ(0);
-#endif
 	} else {
+		irq_base = 0;
 		use_of = 1;
+		ret = pxa_gpio_probe_dt(pdev);
+		if (ret < 0)
+			return -EINVAL;
 	}
 
 	if (!pxa_last_gpio)
@@ -622,7 +621,6 @@ static int pxa_gpio_probe(struct platform_device *pdev)
 	}
 
 	/* Initialize GPIO chips */
-	info = dev_get_platdata(&pdev->dev);
 	pxa_init_gpio_chip(pxa_last_gpio, info ? info->gpio_set_wake : NULL);
 
 	/* clear all GPIO edge detects */
diff --git a/include/linux/gpio-pxa.h b/include/linux/gpio-pxa.h
index d755b28..d90ebbe 100644
--- a/include/linux/gpio-pxa.h
+++ b/include/linux/gpio-pxa.h
@@ -14,6 +14,7 @@ extern int pxa_last_gpio;
 extern int pxa_irq_to_gpio(int irq);
 
 struct pxa_gpio_platform_data {
+	int irq_base;
 	int (*gpio_set_wake)(unsigned int gpio, unsigned int on);
 };
 
-- 
1.7.10.4



From haojian.zhuang at linaro.org  Tue Apr  9 21:18:26 2013
From: haojian.zhuang at linaro.org (Haojian Zhuang)
Date: Wed, 10 Apr 2013 09:18:26 +0800
Subject: [PATCH 3/3] ARM: mmp: add more compatible names in gpio driver
In-Reply-To: <1365556707-9159-1-git-send-email-haojian.zhuang@linaro.org>
References: <1365556707-9159-1-git-send-email-haojian.zhuang@linaro.org>
Message-ID: <1365556707-9159-3-git-send-email-haojian.zhuang@linaro.org>

Since more driver names are added into platform id, do the same thing on
compatible names for DT mode.

Signed-off-by: Haojian Zhuang <haojian.zhuang at linaro.org>
---
 .../devicetree/bindings/gpio/mrvl-gpio.txt         |    7 ++++--
 arch/arm/boot/dts/mmp2.dtsi                        |    2 +-
 arch/arm/boot/dts/pxa168.dtsi                      |    2 +-
 arch/arm/boot/dts/pxa910.dtsi                      |    2 +-
 arch/arm/mach-mmp/mmp-dt.c                         |    4 ++--
 arch/arm/mach-mmp/mmp2-dt.c                        |    2 +-
 drivers/gpio/gpio-pxa.c                            |   25 ++++++++++----------
 7 files changed, 24 insertions(+), 20 deletions(-)

diff --git a/Documentation/devicetree/bindings/gpio/mrvl-gpio.txt b/Documentation/devicetree/bindings/gpio/mrvl-gpio.txt
index e137874..9b3f1d4 100644
--- a/Documentation/devicetree/bindings/gpio/mrvl-gpio.txt
+++ b/Documentation/devicetree/bindings/gpio/mrvl-gpio.txt
@@ -1,7 +1,10 @@
 * Marvell PXA GPIO controller
 
 Required properties:
-- compatible : Should be "mrvl,pxa-gpio" or "mrvl,mmp-gpio"
+- compatible : Should be "intel,pxa25x-gpio", "intel,pxa26x-gpio",
+		"intel,pxa27x-gpio", "intel,pxa3xx-gpio",
+		"marvell,pxa93x-gpio", "marvell,mmp-gpio" or
+		"marvell,mmp2-gpio".
 - reg : Address and length of the register set for the device
 - interrupts : Should be the port interrupt shared by all gpio pins.
   There're three gpio interrupts in arch-pxa, and they're gpio0,
@@ -18,7 +21,7 @@ Required properties:
 Example:
 
 	gpio: gpio at d4019000 {
-		compatible = "mrvl,mmp-gpio";
+		compatible = "marvell,mmp-gpio";
 		reg = <0xd4019000 0x1000>;
 		interrupts = <49>;
 		interrupt-name = "gpio_mux";
diff --git a/arch/arm/boot/dts/mmp2.dtsi b/arch/arm/boot/dts/mmp2.dtsi
index 1429ac0..4e8b08c 100644
--- a/arch/arm/boot/dts/mmp2.dtsi
+++ b/arch/arm/boot/dts/mmp2.dtsi
@@ -160,7 +160,7 @@
 			};
 
 			gpio at d4019000 {
-				compatible = "mrvl,mmp-gpio";
+				compatible = "marvell,mmp2-gpio";
 				#address-cells = <1>;
 				#size-cells = <1>;
 				reg = <0xd4019000 0x1000>;
diff --git a/arch/arm/boot/dts/pxa168.dtsi b/arch/arm/boot/dts/pxa168.dtsi
index 31a7186..975dad2 100644
--- a/arch/arm/boot/dts/pxa168.dtsi
+++ b/arch/arm/boot/dts/pxa168.dtsi
@@ -77,7 +77,7 @@
 			};
 
 			gpio at d4019000 {
-				compatible = "mrvl,mmp-gpio";
+				compatible = "marvell,mmp-gpio";
 				#address-cells = <1>;
 				#size-cells = <1>;
 				reg = <0xd4019000 0x1000>;
diff --git a/arch/arm/boot/dts/pxa910.dtsi b/arch/arm/boot/dts/pxa910.dtsi
index 825aaca..0247c62 100644
--- a/arch/arm/boot/dts/pxa910.dtsi
+++ b/arch/arm/boot/dts/pxa910.dtsi
@@ -89,7 +89,7 @@
 			};
 
 			gpio at d4019000 {
-				compatible = "mrvl,mmp-gpio";
+				compatible = "marvell,mmp-gpio";
 				#address-cells = <1>;
 				#size-cells = <1>;
 				reg = <0xd4019000 0x1000>;
diff --git a/arch/arm/mach-mmp/mmp-dt.c b/arch/arm/mach-mmp/mmp-dt.c
index 5b890b6..b37915d 100644
--- a/arch/arm/mach-mmp/mmp-dt.c
+++ b/arch/arm/mach-mmp/mmp-dt.c
@@ -28,7 +28,7 @@ static const struct of_dev_auxdata pxa168_auxdata_lookup[] __initconst = {
 	OF_DEV_AUXDATA("mrvl,mmp-uart", 0xd4026000, "pxa2xx-uart.2", NULL),
 	OF_DEV_AUXDATA("mrvl,mmp-twsi", 0xd4011000, "pxa2xx-i2c.0", NULL),
 	OF_DEV_AUXDATA("mrvl,mmp-twsi", 0xd4025000, "pxa2xx-i2c.1", NULL),
-	OF_DEV_AUXDATA("mrvl,mmp-gpio", 0xd4019000, "mmp-gpio", NULL),
+	OF_DEV_AUXDATA("marvell,mmp-gpio", 0xd4019000, "mmp-gpio", NULL),
 	OF_DEV_AUXDATA("mrvl,mmp-rtc", 0xd4010000, "sa1100-rtc", NULL),
 	{}
 };
@@ -39,7 +39,7 @@ static const struct of_dev_auxdata pxa910_auxdata_lookup[] __initconst = {
 	OF_DEV_AUXDATA("mrvl,mmp-uart", 0xd4036000, "pxa2xx-uart.2", NULL),
 	OF_DEV_AUXDATA("mrvl,mmp-twsi", 0xd4011000, "pxa2xx-i2c.0", NULL),
 	OF_DEV_AUXDATA("mrvl,mmp-twsi", 0xd4037000, "pxa2xx-i2c.1", NULL),
-	OF_DEV_AUXDATA("mrvl,mmp-gpio", 0xd4019000, "mmp-gpio", NULL),
+	OF_DEV_AUXDATA("marvell,mmp-gpio", 0xd4019000, "mmp-gpio", NULL),
 	OF_DEV_AUXDATA("mrvl,mmp-rtc", 0xd4010000, "sa1100-rtc", NULL),
 	{}
 };
diff --git a/arch/arm/mach-mmp/mmp2-dt.c b/arch/arm/mach-mmp/mmp2-dt.c
index 924b6e8..4ac2567 100644
--- a/arch/arm/mach-mmp/mmp2-dt.c
+++ b/arch/arm/mach-mmp/mmp2-dt.c
@@ -31,7 +31,7 @@ static const struct of_dev_auxdata mmp2_auxdata_lookup[] __initconst = {
 	OF_DEV_AUXDATA("mrvl,mmp-uart", 0xd4016000, "pxa2xx-uart.3", NULL),
 	OF_DEV_AUXDATA("mrvl,mmp-twsi", 0xd4011000, "pxa2xx-i2c.0", NULL),
 	OF_DEV_AUXDATA("mrvl,mmp-twsi", 0xd4025000, "pxa2xx-i2c.1", NULL),
-	OF_DEV_AUXDATA("mrvl,mmp-gpio", 0xd4019000, "mmp2-gpio", NULL),
+	OF_DEV_AUXDATA("marvell,mmp-gpio", 0xd4019000, "mmp2-gpio", NULL),
 	OF_DEV_AUXDATA("mrvl,mmp-rtc", 0xd4010000, "sa1100-rtc", NULL),
 	{}
 };
diff --git a/drivers/gpio/gpio-pxa.c b/drivers/gpio/gpio-pxa.c
index f4b0737..bce9e38 100644
--- a/drivers/gpio/gpio-pxa.c
+++ b/drivers/gpio/gpio-pxa.c
@@ -498,8 +498,13 @@ static int pxa_gpio_nums(struct platform_device *pdev)
 
 #ifdef CONFIG_OF
 static struct of_device_id pxa_gpio_dt_ids[] = {
-	{ .compatible = "mrvl,pxa-gpio" },
-	{ .compatible = "mrvl,mmp-gpio", .data = (void *)MMP_GPIO },
+	{ .compatible = "intel,pxa25x-gpio",	.data = &pxa25x_id, },
+	{ .compatible = "intel,pxa26x-gpio",	.data = &pxa26x_id, },
+	{ .compatible = "intel,pxa27x-gpio",	.data = &pxa27x_id, },
+	{ .compatible = "intel,pxa3xx-gpio",	.data = &pxa3xx_id, },
+	{ .compatible = "marvell,pxa93x-gpio",	.data = &pxa93x_id, },
+	{ .compatible = "marvell,mmp-gpio",	.data = &mmp_id, },
+	{ .compatible = "marvell,mmp2-gpio",	.data = &mmp2_id, },
 	{}
 };
 
@@ -519,16 +524,18 @@ const struct irq_domain_ops pxa_irq_domain_ops = {
 
 static int pxa_gpio_probe_dt(struct platform_device *pdev)
 {
-	int ret, nr_banks, nr_gpios;
+	int ret, nr_gpios;
 	struct device_node *prev, *next, *np = pdev->dev.of_node;
 	const struct of_device_id *of_id =
 				of_match_device(pxa_gpio_dt_ids, &pdev->dev);
+	const struct pxa_gpio_id *gpio_id;
 
-	if (!of_id) {
+	if (!of_id || !of_id->data) {
 		dev_err(&pdev->dev, "Failed to find gpio controller\n");
 		return -EFAULT;
 	}
-	gpio_type = (int)of_id->data;
+	gpio_id = of_id->data;
+	gpio_type = gpio_id->type;
 
 	next = of_get_next_child(np, NULL);
 	prev = next;
@@ -537,14 +544,8 @@ static int pxa_gpio_probe_dt(struct platform_device *pdev)
 		ret = -EINVAL;
 		goto err;
 	}
-	for (nr_banks = 1; ; nr_banks++) {
-		next = of_get_next_child(np, prev);
-		if (!next)
-			break;
-		prev = next;
-	}
 	of_node_put(prev);
-	nr_gpios = nr_banks << 5;
+	nr_gpios = gpio_id->gpio_nums;
 	pxa_last_gpio = nr_gpios - 1;
 
 	irq_base = irq_alloc_descs(-1, 0, nr_gpios, 0);
-- 
1.7.10.4



From horms at verge.net.au  Tue Apr  9 21:25:45 2013
From: horms at verge.net.au (Simon Horman)
Date: Wed, 10 Apr 2013 10:25:45 +0900
Subject: [PATCH v2] ARM: shmobile: marzen-reference: use irqpin for lan
In-Reply-To: <20130410011201.GC11105@verge.net.au>
References: <1365556213-11827-1-git-send-email-horms+renesas@verge.net.au>
 <20130410011201.GC11105@verge.net.au>
Message-ID: <20130410012545.GD11105@verge.net.au>

On Wed, Apr 10, 2013 at 10:12:01AM +0900, Simon Horman wrote:
> On Wed, Apr 10, 2013 at 10:10:13AM +0900, Simon Horman wrote:
> > This corrects the configuration of the SMSC lan controller
> > to use the newly added irqpin as its IRQ source.
> > 
> > Previously the lan controller did not work. Now it does.
> > 
> > Cc: Guennadi Liakhovetski <g.liakhovetski+renesas at gmail.com>
> > Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
> 
> Queued up in the marzen-boards branch.

Scratch that, I miss-tested things (again!) and this does not appear to work.


From kuninori.morimoto.gx at renesas.com  Tue Apr  9 21:31:41 2013
From: kuninori.morimoto.gx at renesas.com (Kuninori Morimoto)
Date: Tue, 09 Apr 2013 18:31:41 -0700 (PDT)
Subject: [PATCH v2 0/9] Reorganize R8A7779/Marzen USB code
In-Reply-To: <51640D21.3090800@cogentembedded.com>
References: <201304090110.50154.sergei.shtylyov@cogentembedded.com>
 <87zjx89rfb.wl%kuninori.morimoto.gx@renesas.com>
 <51640D21.3090800@cogentembedded.com>
Message-ID: <87txnfjhmu.wl%kuninori.morimoto.gx@renesas.com>


Hi Sergei

> > Please add this "tested on xxx" comment on each patch's log area, not only on [0/x].
> > We need it on "git log"
> 
>     I'm going to post R8A7778/BOCK-W series following this one, and all the 
> patches in 1st series should additionally be tested on BOCK-W. Well, I 
> probably can hold up posting version 3 until I have the second series verified.
>     BTW, about R8A7778/BOCK-W, R-Car M1A user manual talks about a ferrite 
> bead in 49.4.1 (3) Setting USB-PHY. Do you know for sure if it's used or not
> on BOCK-W board? PHY initialization seems to work with either settings...

I can ask it to HW team if you want me.
But our local BSP is using "No ferrite bead" settings...


Best regards
---
Kuninori Morimoto


From horms at verge.net.au  Tue Apr  9 21:35:08 2013
From: horms at verge.net.au (Simon Horman)
Date: Wed, 10 Apr 2013 10:35:08 +0900
Subject: [PATCH/RFC 0/2] ARM: shmobile: DT irqpin for r8a7779 and
 marzen-reference
In-Reply-To: <20130410010818.GA11105@verge.net.au>
References: <Pine.LNX.4.64.1304031103590.10531@axis700.grange>
 <20130404035426.GC28297@verge.net.au>
 <Pine.LNX.4.64.1304042325140.21548@axis700.grange>
 <20130405014429.GV29203@verge.net.au>
 <20130405021339.GZ29203@verge.net.au>
 <20130410010818.GA11105@verge.net.au>
Message-ID: <20130410013508.GE11105@verge.net.au>

On Wed, Apr 10, 2013 at 10:08:18AM +0900, Simon Horman wrote:
> On Fri, Apr 05, 2013 at 11:13:39AM +0900, Simon Horman wrote:
> > On Fri, Apr 05, 2013 at 10:44:29AM +0900, Simon Horman wrote:
> > > On Thu, Apr 04, 2013 at 11:47:05PM +0200, Guennadi Liakhovetski wrote:
> > > > Hi Simon
> > > > 
> > > > On Thu, 4 Apr 2013, Simon Horman wrote:
> > > > 
> > > > > On Wed, Apr 03, 2013 at 11:18:57AM +0200, Guennadi Liakhovetski wrote:
> > > > > > Hi
> > > > > > 
> > > > > > This 2 patches add DT irqpin support on marzen-reference. Only 
> > > > > > compile-tested due to the lack of hardware. The patches can go 
> > > > > > independently via their respective trees. irqpin on marzen will not work 
> > > > > > if patch 2 is applied before patch 1, but as long as there are no devices, 
> > > > > > using irqpin interrupts, no breakage will be caused.
> > > > > 
> > > > > I have applied both patches and the dependency I mention below.
> > > > > I have also applied the small patch, inlined below, to hook-up
> > > > > the LAN controller. Unfortunately it doesn't seem to be receiving
> > > > > any interrupts. Perhaps I am missing something?
> > > > 
> > > > Are you sure 28 is the correct number in the irqpin IRQ space? Seems 
> > > > strange to me. Should be 1 perhaps (counting from 0), or 2 - not sure how 
> > > > that mapping would look like.
> > > 
> > > Thanks!
> > > 
> > > 0 seems to be the lucky number, I have SMSC (and NFS root) working
> > > on marzen-reference.
> > 
> > s/0/1/
> 
> After all that it seems that I miss-tested the code somehow.
> 
> It turns out that 2 is the lucky number.

My, what a mess I have made.

It seems that I miss-tested again (using non-reference boot instead
of reference boot).

Unfortunately I am not able to get the NIC running after all.


Booting Linux on physical CPU 0x0
Linux version 3.9.0-rc2-00004-gb1480a8 (horms at ayumi.isobedori.kobe.vergenet.net) (gcc version 4.5.2 (Sourcery G++ Lite 2011.03-41) ) #1642 SMP Wed Apr 10 10:28:59 JST 2013
CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=10c53c7d
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
Machine: marzen, model: marzen
debug: ignoring loglevel setting.
Memory policy: ECC disabled, Data cache writealloc
On node 0 totalpages: 262144
free_area_init_node: node 0, pgdat c0534c00, node_mem_map c082b000
  Normal zone: 1520 pages used for memmap
  Normal zone: 0 pages reserved
  Normal zone: 194560 pages, LIFO batch:31
  HighMem zone: 528 pages used for memmap
  HighMem zone: 67584 pages, LIFO batch:15
PERCPU: Embedded 5 pages/cpu @c1033000 s6720 r0 d13760 u32768
pcpu-alloc: s6720 r0 d13760 u32768 alloc=8*4096
pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 260624
Kernel command line: console=ttySC2,115200 earlyprintk=sh-sci.2,115200 ignore_loglevel root=/dev/nfs ip=on
PID hash table entries: 4096 (order: 2, 16384 bytes)
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
__ex_table already sorted, skipping sort
Memory: 1024MB = 1024MB total
Memory: 1033972k/1033972k available, 14604k reserved, 270336K highmem
Virtual kernel memory layout:
    vector  : 0xffff0000 - 0xffff1000   (   4 kB)
    fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
    vmalloc : 0xf0000000 - 0xff000000   ( 240 MB)
    lowmem  : 0xc0000000 - 0xef800000   ( 760 MB)
    pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
      .text : 0xc0008000 - 0xc037fc60   (3552 kB)
      .init : 0xc0380000 - 0xc0511a40   (1607 kB)
      .data : 0xc0512000 - 0xc05357c0   ( 142 kB)
       .bss : 0xc05357c0 - 0xc0560274   ( 171 kB)
Hierarchical RCU implementation.
NR_IRQS:16 nr_irqs:16 16
sched_clock: 32 bits at 1kHz, resolution 976562ns, wraps every 4194303999ms
Calibrating delay loop (skipped) preset value.. 1000.00 BogoMIPS (lpj=488000)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
Setting up static identity map for 0xc02db328 - 0xc02db380
CPU1: Booted secondary processor
CPU2: Booted secondary processor
CPU3: Booted secondary processor
Brought up 4 CPUs
SMP: Total of 4 processors activated (4000.00 BogoMIPS).
CPU: All CPU(s) started in SVC mode.
devtmpfs: initialized
pinctrl core: initialized pinctrl subsystem
NET: Registered protocol family 16
DMA: preallocated 256 KiB pool for atomic coherent allocations
sh-pfc pfc-r8a7779: r8a7779_pfc support registered
renesas_intc_irqpin fe78001c.irqpin: driving 4 irqs
No ATAGs?
bio: create slab <bio-0> at 0
SCSI subsystem initialized
libata version 3.00 loaded.
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
sh_tmu sh_tmu.0: Runtime PM disabled, clock forced on.
sh_tmu sh_tmu.0: used for clock events
sh_tmu sh_tmu.0: used for periodic clock events
sh_tmu sh_tmu.1: Runtime PM disabled, clock forced on.
sh_tmu sh_tmu.1: used as clock source
Switching to clocksource sh_tmu.1
Clockevents: could not switch to one-shot mode:
Clockevents: could not switch to one-shot mode:
Clockevents: could not switch to one-shot mode:
 dummy_timer is not functional.
 dummy_timer is not functional.
Clockevents: could not switch to one-shot mode: dummy_timer is not functional.
 dummy_timer is not functional.
NET: Registered protocol family 2
TCP established hash table entries: 8192 (order: 4, 65536 bytes)
TCP bind hash table entries: 8192 (order: 4, 65536 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
TCP: reno registered
UDP hash table entries: 512 (order: 2, 16384 bytes)
UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
bounce pool size: 64 pages
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 254)
io scheduler noop registered
io scheduler deadline registered (default)
gpio_rcar gpio_rcar.0: driving 32 GPIOs
gpio_rcar gpio_rcar.1: driving 32 GPIOs
gpio_rcar gpio_rcar.2: driving 32 GPIOs
gpio_rcar gpio_rcar.3: driving 32 GPIOs
gpio_rcar gpio_rcar.4: driving 32 GPIOs
gpio_rcar gpio_rcar.5: driving 32 GPIOs
gpio_rcar gpio_rcar.6: driving 9 GPIOs
SuperH SCI(F) driver initialized
sh-sci sh-sci.0: Runtime PM disabled, clock forced on.
sh-sci.0: ttySC0 at MMIO 0xffe40000 (irq = 120) is a scif
sh-sci sh-sci.1: Runtime PM disabled, clock forced on.
sh-sci.1: ttySC1 at MMIO 0xffe41000 (irq = 121) is a scif
sh-sci sh-sci.2: Runtime PM disabled, clock forced on.
sh-sci.2: ttySC2 at MMIO 0xffe42000 (irq = 122) is a scif
console [ttySC2] enabled
sh-sci sh-sci.3: Runtime PM disabled, clock forced on.
sh-sci.3: ttySC3 at MMIO 0xffe43000 (irq = 123) is a scif
sh-sci sh-sci.4: Runtime PM disabled, clock forced on.
sh-sci.4: ttySC4 at MMIO 0xffe44000 (irq = 124) is a scif
sh-sci sh-sci.5: Runtime PM disabled, clock forced on.
sh-sci.5: ttySC5 at MMIO 0xffe45000 (irq = 125) is a scif
sata_rcar fc600000.sata: Runtime PM disabled, clock forced on.
scsi0 : sata_rcar
ata1: SATA max UDMA/133 irq 132
smsc911x: Driver version 2008-10-21
libphy: smsc911x-mdio: probed
smsc911x 18000000.lan0 eth0: attached PHY driver [Generic PHY] (mii_bus:phy_addr=18000000.lan0-ff:01, irq=-1)
smsc911x 18000000.lan0 eth0: MAC Address: 2e:09:0a:00:3c:de
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ehci-platform: EHCI generic platform driver
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
Initializing USB Mass Storage driver...
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
rcar_thermal ffc48000.thermal: 1 sensor proved
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
TCP: cubic registered
ata1: link resume succeeded after 1 retries
ata1: SATA link down (SStatus 0 SControl 300)
smsc911x 18000000.lan0 eth0: ISR failed signaling test (IRQ 256)
IP-Config: Failed to open eth0
IP-Config: No network devices available
Freeing init memory: 1604K


boot (Linux 3.9.0-rc2-00004-gb1480a8, BusyBox v1.16.0.git, kexec-tools 2.0.1-git)
/ # ip link set up dev eth0
smsc911x 18000000.lan0 eth0: ISR failed signaling test (IRQ 256)
ip: SIOCSIFFLAGS: No such device
/ # cat /proc/interrupts 
           CPU0       CPU1       CPU2       CPU3       
 59:          0          0          0          0       GIC  fe78001c.irqpin
 60:          0          0          0          0       GIC  fe78001c.irqpin
 61:          0          0          0          0       GIC  fe78001c.irqpin
 62:          0          0          0          0       GIC  fe78001c.irqpin
 64:      24370          0          0          0       GIC  sh_tmu.0
122:         97          0          0          0       GIC  sh-sci.2:mux
132:          0          0          0          0       GIC  sata_rcar
173:          0          0          0          0       GIC  gpio_rcar.0
174:          0          0          0          0       GIC  gpio_rcar.1
175:          0          0          0          0       GIC  gpio_rcar.2
176:          0          0          0          0       GIC  gpio_rcar.3
177:          0          0          0          0       GIC  gpio_rcar.4
178:          0          0          0          0       GIC  gpio_rcar.5
179:          0          0          0          0       GIC  gpio_rcar.6
256:          0          0          0          0  fe78001c.irqpin  eth0
IPI0:          0          0          0          0  CPU wakeup interrupts
IPI1:          0      24330      23977      24350  Timer broadcast interrupts
IPI2:        470        458         73         74  Rescheduling interrupts
IPI3:         56         37         40         35  Function call interrupts
IPI4:          0          0          0          0  Single function call interrupts
IPI5:          0          0          0          0  CPU stop interrupts
Err:          0


From magnus.damm at gmail.com  Tue Apr  9 21:38:49 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Wed, 10 Apr 2013 10:38:49 +0900
Subject: [PATCH] ARM: shmobile: Include all 2 GiB of memory on APE6EVM
In-Reply-To: <20130410003535.GA2462@verge.net.au>
References: <20130408014444.18767.64441.sendpatchset@w520>
 <20130409123433.GD15412@verge.net.au>
 <20130409161410.GA16003@verge.net.au>
 <CANqRtoTCYVY9Q6-2wUshSxZzXNsUx4xdY+phf2ZyHmwSyj4SRw@mail.gmail.com>
 <20130410003535.GA2462@verge.net.au>
Message-ID: <CANqRtoSvoyCDGMtLof68y2q1feiEtE=HXMi1=sTi-rOKexAuhQ@mail.gmail.com>

Hi Simon, Arnd,

On Wed, Apr 10, 2013 at 9:35 AM, Simon Horman <horms at verge.net.au> wrote:
> On Wed, Apr 10, 2013 at 07:27:41AM +0900, Magnus Damm wrote:
>> Hi Simon,
>>
>> On Wed, Apr 10, 2013 at 1:14 AM, Simon Horman <horms at verge.net.au> wrote:
>> > On Tue, Apr 09, 2013 at 09:34:34PM +0900, Simon Horman wrote:
>> >> On Mon, Apr 08, 2013 at 10:44:44AM +0900, Magnus Damm wrote:
>> >> > From: Takashi Yoshii <takashi.yoshii.zj at renesas.com>
>> >> >
>> >> > Add 1GiB of DRAM at 0x2_0000_0000
>> >> >
>> >> > Signed-off-by: Takashi Yoshii <takashi.yoshii.zj at renesas.com>
>> >> > Signed-off-by: Magnus Damm <damm at opensource.se>
>> >>
>> >> Thanks, queued up in the boards-ape6evm branch.
>> >
>> > I have dropped this patch as it appears to prevent
>> > the board from booting.
>>
>> Is it possible that LPAE=n and HIGHMEM=y in your particular kernel
>> configuration?
>
> Yes, I have confirmed that is what using the ape6evm_defconfig results in.
>
>> >From what I can tell HIGHMEM is broken in cases of large amounts of
>> memory. Try disabling that as a short-term workaround. Then of course
>> someone needs to track down why the generic code doesn't work as
>> expected.
>
> I have confirmed that disabling HIGHMEM allows the board to boot
> with this patch applied.

Thanks for checking.

So HIGHMEM without LPAE seems busted on boards using more than 32-bits
for memory.

I'd like to help out fixing this issue, but I'd like to make sure that
no one else is working on this.

Arnd, are you aware on any work related to making HIGHMEM work without LPAE?

> Should I prepare a patch to the defconfig to accompany this patch?

I believe that would affect a bunch of boards so I don't think that is
necessary at this point. Thanks anyway.

Would it be possible for you to queue up this change in a APE6EVM topic branch?

Thanks,

/ magnus


From horms at verge.net.au  Tue Apr  9 22:09:37 2013
From: horms at verge.net.au (Simon Horman)
Date: Wed, 10 Apr 2013 11:09:37 +0900
Subject: [PATCH] ARM: shmobile: Include all 2 GiB of memory on APE6EVM
In-Reply-To: <CANqRtoSvoyCDGMtLof68y2q1feiEtE=HXMi1=sTi-rOKexAuhQ@mail.gmail.com>
References: <20130408014444.18767.64441.sendpatchset@w520>
 <20130409123433.GD15412@verge.net.au>
 <20130409161410.GA16003@verge.net.au>
 <CANqRtoTCYVY9Q6-2wUshSxZzXNsUx4xdY+phf2ZyHmwSyj4SRw@mail.gmail.com>
 <20130410003535.GA2462@verge.net.au>
 <CANqRtoSvoyCDGMtLof68y2q1feiEtE=HXMi1=sTi-rOKexAuhQ@mail.gmail.com>
Message-ID: <20130410020936.GI11105@verge.net.au>

On Wed, Apr 10, 2013 at 10:38:49AM +0900, Magnus Damm wrote:
> Hi Simon, Arnd,
> 
> On Wed, Apr 10, 2013 at 9:35 AM, Simon Horman <horms at verge.net.au> wrote:
> > On Wed, Apr 10, 2013 at 07:27:41AM +0900, Magnus Damm wrote:
> >> Hi Simon,
> >>
> >> On Wed, Apr 10, 2013 at 1:14 AM, Simon Horman <horms at verge.net.au> wrote:
> >> > On Tue, Apr 09, 2013 at 09:34:34PM +0900, Simon Horman wrote:
> >> >> On Mon, Apr 08, 2013 at 10:44:44AM +0900, Magnus Damm wrote:
> >> >> > From: Takashi Yoshii <takashi.yoshii.zj at renesas.com>
> >> >> >
> >> >> > Add 1GiB of DRAM at 0x2_0000_0000
> >> >> >
> >> >> > Signed-off-by: Takashi Yoshii <takashi.yoshii.zj at renesas.com>
> >> >> > Signed-off-by: Magnus Damm <damm at opensource.se>
> >> >>
> >> >> Thanks, queued up in the boards-ape6evm branch.
> >> >
> >> > I have dropped this patch as it appears to prevent
> >> > the board from booting.
> >>
> >> Is it possible that LPAE=n and HIGHMEM=y in your particular kernel
> >> configuration?
> >
> > Yes, I have confirmed that is what using the ape6evm_defconfig results in.
oup >
> >> >From what I can tell HIGHMEM is broken in cases of large amounts of
> >> memory. Try disabling that as a short-term workaround. Then of course
> >> someone needs to track down why the generic code doesn't work as
> >> expected.
> >
> > I have confirmed that disabling HIGHMEM allows the board to boot
> > with this patch applied.
> 
> Thanks for checking.
> 
> So HIGHMEM without LPAE seems busted on boards using more than 32-bits
> for memory.
> 
> I'd like to help out fixing this issue, but I'd like to make sure that
> no one else is working on this.
> 
> Arnd, are you aware on any work related to making HIGHMEM work without LPAE?
> 
> > Should I prepare a patch to the defconfig to accompany this patch?
> 
> I believe that would affect a bunch of boards so I don't think that is
> necessary at this point. Thanks anyway.
> 
> Would it be possible for you to queue up this change in a APE6EVM topic branch?

Sure, I have pushed topic/ape6evm-2gb.

I also plan to push topic/ape6evm-2gb+renesas-next-20130410v2
once I have finalised renesas-next-20130410v2.


From shawn.guo at linaro.org  Tue Apr  9 22:54:15 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Wed, 10 Apr 2013 10:54:15 +0800
Subject: [GIT PULL 4/4] ARM: imx: device tree changes for 3.10
In-Reply-To: <1365520775-28478-4-git-send-email-shawn.guo@linaro.org>
References: <1365520775-28478-1-git-send-email-shawn.guo@linaro.org>
 <1365520775-28478-4-git-send-email-shawn.guo@linaro.org>
Message-ID: <20130410025413.GL5047@S2101-09.ap.freescale.net>

On Tue, Apr 09, 2013 at 11:19:35PM +0800, Shawn Guo wrote:
> Hi Arnd, Olof,
> 
> It's based on imx-cleanup-3.10 and Stephen Warren's "[GIT PULL] dt:
> run C pre-processor on *.dts, create some standard headers" to resolve
> dependency and conflicts.

Just a note, Rob just pulled Stephen's branch.  So it will be merged
via DT tree, and we only need it as a dependency in arm-soc tree.

Shawn



From robherring2 at gmail.com  Tue Apr  9 23:08:15 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Tue,  9 Apr 2013 22:08:15 -0500
Subject: [RFC PATCH 1/3] pstore-ram: use write-combine mappings
Message-ID: <1365563297-12480-1-git-send-email-robherring2@gmail.com>

From: Rob Herring <rob.herring at calxeda.com>

Atomic operations are undefined behavior on ARM for device or strongly
ordered memory types. So use write-combine variants for mappings. This
corresponds to normal, non-cacheable memory on ARM. For many other
architectures, this change should not change the mapping type.

Signed-off-by: Rob Herring <rob.herring at calxeda.com>
Cc: Anton Vorontsov <cbouatmailru at gmail.com>
Cc: Colin Cross <ccross at android.com>
Cc: Kees Cook <keescook at chromium.org>
Cc: Tony Luck <tony.luck at intel.com>
Cc: linux-kernel at vger.kernel.org
---
 fs/pstore/ram_core.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/pstore/ram_core.c b/fs/pstore/ram_core.c
index 0306303..e126d9f 100644
--- a/fs/pstore/ram_core.c
+++ b/fs/pstore/ram_core.c
@@ -337,7 +337,7 @@ static void *persistent_ram_vmap(phys_addr_t start, size_t size)
 	page_start = start - offset_in_page(start);
 	page_count = DIV_ROUND_UP(size + offset_in_page(start), PAGE_SIZE);
 
-	prot = pgprot_noncached(PAGE_KERNEL);
+	prot = pgprot_writecombine(PAGE_KERNEL);
 
 	pages = kmalloc(sizeof(struct page *) * page_count, GFP_KERNEL);
 	if (!pages) {
@@ -364,7 +364,7 @@ static void *persistent_ram_iomap(phys_addr_t start, size_t size)
 		return NULL;
 	}
 
-	return ioremap(start, size);
+	return ioremap_wc(start, size);
 }
 
 static int persistent_ram_buffer_map(phys_addr_t start, phys_addr_t size,
-- 
1.7.10.4



From robherring2 at gmail.com  Tue Apr  9 23:08:16 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Tue,  9 Apr 2013 22:08:16 -0500
Subject: [RFC PATCH 2/3] pstore ram: remove the power of buffer size limitation
In-Reply-To: <1365563297-12480-1-git-send-email-robherring2@gmail.com>
References: <1365563297-12480-1-git-send-email-robherring2@gmail.com>
Message-ID: <1365563297-12480-2-git-send-email-robherring2@gmail.com>

From: Rob Herring <rob.herring at calxeda.com>

There doesn't appear to be any reason for the overall pstore RAM buffer to
be a power of 2 size, so remove it. The individual console, ftrace and oops
buffers are still a power of 2 size.

Signed-off-by: Rob Herring <rob.herring at calxeda.com>
Cc: Anton Vorontsov <cbouatmailru at gmail.com>
Cc: Colin Cross <ccross at android.com>
Cc: Kees Cook <keescook at chromium.org>
Cc: Tony Luck <tony.luck at intel.com>
Cc: linux-kernel at vger.kernel.org
---
 fs/pstore/ram.c |    2 --
 1 file changed, 2 deletions(-)

diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c
index 288f068..f980077 100644
--- a/fs/pstore/ram.c
+++ b/fs/pstore/ram.c
@@ -391,8 +391,6 @@ static int ramoops_probe(struct platform_device *pdev)
 		goto fail_out;
 	}
 
-	if (!is_power_of_2(pdata->mem_size))
-		pdata->mem_size = rounddown_pow_of_two(pdata->mem_size);
 	if (!is_power_of_2(pdata->record_size))
 		pdata->record_size = rounddown_pow_of_two(pdata->record_size);
 	if (!is_power_of_2(pdata->console_size))
-- 
1.7.10.4



From robherring2 at gmail.com  Tue Apr  9 23:08:17 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Tue,  9 Apr 2013 22:08:17 -0500
Subject: [RFC PATCH 3/3] pstore/ram: avoid atomic accesses for ioremapped
 regions
In-Reply-To: <1365563297-12480-1-git-send-email-robherring2@gmail.com>
References: <1365563297-12480-1-git-send-email-robherring2@gmail.com>
Message-ID: <1365563297-12480-3-git-send-email-robherring2@gmail.com>

From: Rob Herring <rob.herring at calxeda.com>

For persistent RAM outside of main memory, the memory may have limitations
on supported accesses. For internal RAM on highbank platform exclusive
accesses are not supported and will hang the system. So atomic_cmpxchg
cannot be used. This commit uses spinlock protection for buffer size and
start updates on ioremapped regions instead.

Signed-off-by: Rob Herring <rob.herring at calxeda.com>
Cc: Anton Vorontsov <cbouatmailru at gmail.com>
Cc: Colin Cross <ccross at android.com>
Cc: Kees Cook <keescook at chromium.org>
Cc: Tony Luck <tony.luck at intel.com>
Cc: linux-kernel at vger.kernel.org
---
 fs/pstore/ram_core.c |   54 ++++++++++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 52 insertions(+), 2 deletions(-)

diff --git a/fs/pstore/ram_core.c b/fs/pstore/ram_core.c
index e126d9f..97e640b 100644
--- a/fs/pstore/ram_core.c
+++ b/fs/pstore/ram_core.c
@@ -46,7 +46,7 @@ static inline size_t buffer_start(struct persistent_ram_zone *prz)
 }
 
 /* increase and wrap the start pointer, returning the old value */
-static inline size_t buffer_start_add(struct persistent_ram_zone *prz, size_t a)
+static size_t buffer_start_add_atomic(struct persistent_ram_zone *prz, size_t a)
 {
 	int old;
 	int new;
@@ -62,7 +62,7 @@ static inline size_t buffer_start_add(struct persistent_ram_zone *prz, size_t a)
 }
 
 /* increase the size counter until it hits the max size */
-static inline void buffer_size_add(struct persistent_ram_zone *prz, size_t a)
+static void buffer_size_add_atomic(struct persistent_ram_zone *prz, size_t a)
 {
 	size_t old;
 	size_t new;
@@ -78,6 +78,53 @@ static inline void buffer_size_add(struct persistent_ram_zone *prz, size_t a)
 	} while (atomic_cmpxchg(&prz->buffer->size, old, new) != old);
 }
 
+static DEFINE_RAW_SPINLOCK(buffer_lock);
+
+/* increase and wrap the start pointer, returning the old value */
+static size_t buffer_start_add_locked(struct persistent_ram_zone *prz, size_t a)
+{
+	int old;
+	int new;
+	unsigned long flags;
+
+	raw_spin_lock_irqsave(&buffer_lock, flags);
+
+	old = atomic_read(&prz->buffer->start);
+	new = old + a;
+	while (unlikely(new > prz->buffer_size))
+		new -= prz->buffer_size;
+	atomic_set(&prz->buffer->start, new);
+
+	raw_spin_unlock_irqrestore(&buffer_lock, flags);
+
+	return old;
+}
+
+/* increase the size counter until it hits the max size */
+static void buffer_size_add_locked(struct persistent_ram_zone *prz, size_t a)
+{
+	size_t old;
+	size_t new;
+	unsigned long flags;
+
+	raw_spin_lock_irqsave(&buffer_lock, flags);
+
+	old = atomic_read(&prz->buffer->size);
+	if (old == prz->buffer_size)
+		goto exit;
+
+	new = old + a;
+	if (new > prz->buffer_size)
+		new = prz->buffer_size;
+	atomic_set(&prz->buffer->size, new);
+
+exit:
+	raw_spin_unlock_irqrestore(&buffer_lock, flags);
+}
+
+static size_t (*buffer_start_add)(struct persistent_ram_zone *, size_t) = buffer_start_add_atomic;
+static void (*buffer_size_add)(struct persistent_ram_zone *, size_t) = buffer_size_add_atomic;
+
 static void notrace persistent_ram_encode_rs8(struct persistent_ram_zone *prz,
 	uint8_t *data, size_t len, uint8_t *ecc)
 {
@@ -364,6 +411,9 @@ static void *persistent_ram_iomap(phys_addr_t start, size_t size)
 		return NULL;
 	}
 
+	buffer_start_add = buffer_start_add_locked;
+	buffer_size_add = buffer_size_add_locked;
+
 	return ioremap_wc(start, size);
 }
 
-- 
1.7.10.4



From sachin.kamat at linaro.org  Tue Apr  9 23:48:42 2013
From: sachin.kamat at linaro.org (Sachin Kamat)
Date: Wed, 10 Apr 2013 09:18:42 +0530
Subject: [GIT PULL 04/10] clk-exynos for v3.10
In-Reply-To: <201304092231.18314.arnd@arndb.de>
References: <51630A02.4080905@samsung.com> <201304092231.18314.arnd@arndb.de>
Message-ID: <CAK9yfHzMOmrRMKdc2fUJHnbrOC_-=AR3BnHBDjtvPeinvxOcLg@mail.gmail.com>

On 10 April 2013 02:01, Arnd Bergmann <arnd at arndb.de> wrote:
> On Monday 08 April 2013, Kukjin Kim wrote:
>> The following changes since commit 07961ac7c0ee8b546658717034fe692fd12eefa9:
>>
>>    Linux 3.9-rc5 (2013-03-31 15:12:43 -0700)
>>
>> are available in the git repository at:
>>
>>    git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
>> tags/clk-exynos-for-v3.10
>>
>> for you to fetch changes up to da821eb7d42935b0f7056d98c75fd1150f6636f4:
>>
>>    Merge commit 'v3.9-rc5' into next/clk-exynos (2013-04-09 01:10:13 +0900)
>>
>> ----------------------------------------------------------------
>>
>> add suppport common clock framework for exynos
>
> I got a build warning, probably because of this patch:


IIRC, the patch at [1] was supposed to fix the build warning. Kukjin
had mentioned it was applied [1].

[1] https://patchwork.kernel.org/patch/2010691/


-- 
With warm regards,
Sachin


From ccross at android.com  Tue Apr  9 23:53:18 2013
From: ccross at android.com (Colin Cross)
Date: Tue, 9 Apr 2013 20:53:18 -0700
Subject: [RFC PATCH 1/3] pstore-ram: use write-combine mappings
In-Reply-To: <1365563297-12480-1-git-send-email-robherring2@gmail.com>
References: <1365563297-12480-1-git-send-email-robherring2@gmail.com>
Message-ID: <CAMbhsRSvQPbzJ7Nt=OSSYE_A1e+eaUjO7XY+qRppJ5_gfWmW4A@mail.gmail.com>

On Tue, Apr 9, 2013 at 8:08 PM, Rob Herring <robherring2 at gmail.com> wrote:
> From: Rob Herring <rob.herring at calxeda.com>
>
> Atomic operations are undefined behavior on ARM for device or strongly
> ordered memory types. So use write-combine variants for mappings. This
> corresponds to normal, non-cacheable memory on ARM. For many other
> architectures, this change should not change the mapping type.

This is going to make ramconsole less reliable.  A debugging printk
followed by a __raw_writel that causes an immediate hard crash is
likely to lose the last updates, including the most useful message, in
the write buffers.

Also, isn't this patch unnecessary after patch 3 in this set?

> Signed-off-by: Rob Herring <rob.herring at calxeda.com>
> Cc: Anton Vorontsov <cbouatmailru at gmail.com>
> Cc: Colin Cross <ccross at android.com>
> Cc: Kees Cook <keescook at chromium.org>
> Cc: Tony Luck <tony.luck at intel.com>
> Cc: linux-kernel at vger.kernel.org
> ---
>  fs/pstore/ram_core.c |    4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/fs/pstore/ram_core.c b/fs/pstore/ram_core.c
> index 0306303..e126d9f 100644
> --- a/fs/pstore/ram_core.c
> +++ b/fs/pstore/ram_core.c
> @@ -337,7 +337,7 @@ static void *persistent_ram_vmap(phys_addr_t start, size_t size)
>         page_start = start - offset_in_page(start);
>         page_count = DIV_ROUND_UP(size + offset_in_page(start), PAGE_SIZE);
>
> -       prot = pgprot_noncached(PAGE_KERNEL);
> +       prot = pgprot_writecombine(PAGE_KERNEL);
Is this necessary?  Won't pgprot_noncached already be normal memory?

>         pages = kmalloc(sizeof(struct page *) * page_count, GFP_KERNEL);
>         if (!pages) {
> @@ -364,7 +364,7 @@ static void *persistent_ram_iomap(phys_addr_t start, size_t size)
>                 return NULL;
>         }
>
> -       return ioremap(start, size);
> +       return ioremap_wc(start, size);

ioremap_wc corresponds to MT_DEVICE_WC, which is still device memory,
so I don't see how this helps solve the problem in the commit message.

>  }
>
>  static int persistent_ram_buffer_map(phys_addr_t start, phys_addr_t size,
> --
> 1.7.10.4
>


From haojian.zhuang at linaro.org  Wed Apr 10 00:07:22 2013
From: haojian.zhuang at linaro.org (Haojian Zhuang)
Date: Wed, 10 Apr 2013 12:07:22 +0800
Subject: [PATCH] ARM: pxa: select PXA935 on saar & tavorevb
Message-ID: <1365566842-16407-1-git-send-email-haojian.zhuang@linaro.org>

Since both PXA930 and PXA935 are used in Saar & TavorEVB platform,
select PXA935 too.

Signed-off-by: Haojian Zhuang <haojian.zhuang at linaro.org>
---
 arch/arm/mach-pxa/Kconfig |    2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/mach-pxa/Kconfig b/arch/arm/mach-pxa/Kconfig
index 0e74ba0..96100db 100644
--- a/arch/arm/mach-pxa/Kconfig
+++ b/arch/arm/mach-pxa/Kconfig
@@ -51,11 +51,13 @@ config MACH_LITTLETON
 config MACH_TAVOREVB
 	bool "PXA930 Evaluation Board (aka TavorEVB)"
 	select CPU_PXA930
+	select CPU_PXA935
 	select PXA3xx
 
 config MACH_SAAR
 	bool "PXA930 Handheld Platform (aka SAAR)"
 	select CPU_PXA930
+	select CPU_PXA935
 	select PXA3xx
 
 comment "Third Party Dev Platforms (sorted by vendor name)"
-- 
1.7.10.4



From ccross at android.com  Wed Apr 10 00:10:37 2013
From: ccross at android.com (Colin Cross)
Date: Tue, 9 Apr 2013 21:10:37 -0700
Subject: [RFC PATCH 3/3] pstore/ram: avoid atomic accesses for ioremapped
 regions
In-Reply-To: <1365563297-12480-3-git-send-email-robherring2@gmail.com>
References: <1365563297-12480-1-git-send-email-robherring2@gmail.com>
 <1365563297-12480-3-git-send-email-robherring2@gmail.com>
Message-ID: <CAMbhsRSNPz1d9bGGEjqyTwVg_1pv8PB15WybEL5ZRVgmnTDWLQ@mail.gmail.com>

On Tue, Apr 9, 2013 at 8:08 PM, Rob Herring <robherring2 at gmail.com> wrote:
> From: Rob Herring <rob.herring at calxeda.com>
>
> For persistent RAM outside of main memory, the memory may have limitations
> on supported accesses. For internal RAM on highbank platform exclusive
> accesses are not supported and will hang the system. So atomic_cmpxchg
> cannot be used. This commit uses spinlock protection for buffer size and
> start updates on ioremapped regions instead.

I used atomics in persistent_ram to support persistent ftrace, which
now exists as PSTORE_FTRACE.  At some point during development I had
trouble with recursive tracing causing an infinite loop, so you may
want to test that calling out to spinlock functions with PSTORE_FTRACE
turned on and enabled doesn't cause a problem.


From haojian.zhuang at linaro.org  Wed Apr 10 00:14:03 2013
From: haojian.zhuang at linaro.org (Haojian Zhuang)
Date: Wed, 10 Apr 2013 12:14:03 +0800
Subject: [PATCH] ARM: pxa: move debug uart code
Message-ID: <1365567243-17872-1-git-send-email-haojian.zhuang@linaro.org>

Move debug uart code from mach-pxa/mach-mmp to debug directory.
Since they are similar, merge them together.

Signed-off-by: Haojian Zhuang <haojian.zhuang at linaro.org>
---
 arch/arm/Kconfig.debug                       |    9 +++++++
 arch/arm/include/debug/pxa.S                 |   33 ++++++++++++++++++++++++++
 arch/arm/mach-mmp/include/mach/debug-macro.S |   30 -----------------------
 arch/arm/mach-pxa/include/mach/debug-macro.S |   23 ------------------
 4 files changed, 42 insertions(+), 53 deletions(-)
 create mode 100644 arch/arm/include/debug/pxa.S
 delete mode 100644 arch/arm/mach-mmp/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-pxa/include/mach/debug-macro.S

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 2bf1973..2267ff7 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -330,6 +330,13 @@ choice
 		  Say Y here if you want kernel low-level debugging support
 		  on PicoXcell based platforms.
 
+	config DEBUG_PXA_UART1
+		depends on ARCH_PXA
+		bool "Use PXA UAR0 for low-level debug"
+		help
+		  Say Y here if you want kernel low-level debugging support
+		  on PXA UART1.
+
 	config DEBUG_REALVIEW_STD_PORT
 		bool "RealView Default UART"
 		depends on ARCH_REALVIEW
@@ -615,6 +622,8 @@ config DEBUG_LL_INCLUDE
 	default "debug/mxs.S" if DEBUG_IMX23_UART || DEBUG_IMX28_UART
 	default "debug/omap2plus.S" if DEBUG_OMAP2PLUS_UART
 	default "debug/picoxcell.S" if DEBUG_PICOXCELL_UART
+	default "debug/pxa.S" if DEBUG_PXA_UART1 || DEBUG_MMP_UART2 || \
+				 DEBUG_MMP_UART3
 	default "debug/sirf.S" if DEBUG_SIRFPRIMA2_UART1 || DEBUG_SIRFMARCO_UART1
 	default "debug/socfpga.S" if DEBUG_SOCFPGA_UART
 	default "debug/sunxi.S" if DEBUG_SUNXI_UART0 || DEBUG_SUNXI_UART1
diff --git a/arch/arm/include/debug/pxa.S b/arch/arm/include/debug/pxa.S
new file mode 100644
index 0000000..e1e795a
--- /dev/null
+++ b/arch/arm/include/debug/pxa.S
@@ -0,0 +1,33 @@
+/*
+ * Early serial output macro for Marvell PXA/MMP SoC
+ *
+ * Copyright (C) 1994-1999 Russell King
+ * Moved from linux/arch/arm/kernel/debug.S by Ben Dooks
+ *
+ * Copyright (C) 2013 Haojian Zhuang
+ *
+ * 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.
+*/
+
+#if defined(CONFIG_DEBUG_PXA_UART1)
+#define PXA_UART_REG_PHYS_BASE	0x40100000
+#define PXA_UART_REG_VIRT_BASE	0xf2100000
+#elif defined(CONFIG_DEBUG_MMP_UART2)
+#define PXA_UART_REG_PHYS_BASE	0xd4017000
+#define PXA_UART_REG_VIRT_BASE	0xfe017000
+#elif defined(CONFIG_DEBUG_MMP_UART3)
+#define PXA_UART_REG_PHYS_BASE	0xd4018000
+#define PXA_UART_REG_VIRT_BASE	0xfe018000
+#else
+#error "Select uart for DEBUG_LL"
+#endif
+
+	.macro	addruart, rp, rv, tmp
+	ldr	\rp, =PXA_UART_REG_PHYS_BASE
+	ldr	\rv, =PXA_UART_REG_VIRT_BASE
+	.endm
+
+#define UART_SHIFT	2
+#include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/mach-mmp/include/mach/debug-macro.S b/arch/arm/mach-mmp/include/mach/debug-macro.S
deleted file mode 100644
index 5c3cc29..0000000
--- a/arch/arm/mach-mmp/include/mach/debug-macro.S
+++ /dev/null
@@ -1,30 +0,0 @@
-/* arch/arm/mach-mmp/include/mach/debug-macro.S
- *
- * Debugging macro include header
- *
- *  Copied from arch/arm/mach-pxa/include/mach/debug.S
- *
- * 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.
- */
-
-#if defined(CONFIG_DEBUG_MMP_UART2)
-#define MMP_UART_OFFSET	0x00017000
-#elif defined(CONFIG_DEBUG_MMP_UART3)
-#define MMP_UART_OFFSET	0x00018000
-#else
-#error "Select uart for DEBUG_LL"
-#endif
-
-#include <mach/addr-map.h>
-
-		.macro	addruart, rp, rv, tmp
-		ldr	\rp, =APB_PHYS_BASE		@ physical
-		ldr	\rv, =APB_VIRT_BASE		@ virtual
-		orr	\rp, \rp, #MMP_UART_OFFSET
-		orr	\rv, \rv, #MMP_UART_OFFSET
-		.endm
-
-#define UART_SHIFT	2
-#include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/mach-pxa/include/mach/debug-macro.S b/arch/arm/mach-pxa/include/mach/debug-macro.S
deleted file mode 100644
index 70b112e..0000000
--- a/arch/arm/mach-pxa/include/mach/debug-macro.S
+++ /dev/null
@@ -1,23 +0,0 @@
-/* arch/arm/mach-pxa/include/mach/debug-macro.S
- *
- * Debugging macro include header
- *
- *  Copyright (C) 1994-1999 Russell King
- *  Moved from linux/arch/arm/kernel/debug.S by Ben Dooks
- *
- * 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 "hardware.h"
-
-		.macro	addruart, rp, rv, tmp
-		mov	\rp, #0x00100000
-		orr	\rv, \rp, #io_p2v(0x40000000)	@ virtual
-		orr	\rp, \rp, #0x40000000		@ physical
-		.endm
-
-#define UART_SHIFT	2
-#include <asm/hardware/debug-8250.S>
-- 
1.7.10.4



From prabhakar.csengg at gmail.com  Wed Apr 10 00:39:51 2013
From: prabhakar.csengg at gmail.com (Prabhakar Lad)
Date: Wed, 10 Apr 2013 10:09:51 +0530
Subject: [PATCH] kbuild: generate generic headers before recursing into
 scripts
In-Reply-To: <m2k3ob1tar.fsf_-_@igel.home>
References: <CA+V-a8vYsBLVH-3Bm35Sv9K9ZMTcMB4_P_V3kBjyuEKDozPi5w@mail.gmail.com>
 <1363949290.3528.37.camel@linaro1.home> <m2ip48d62f.fsf@igel.home>
 <CA+V-a8srtwdf1H2JQwbkyMFhXopPEA90RM8Hy+UunM6Mm7-d1w@mail.gmail.com>
 <m2k3ob1tar.fsf_-_@igel.home>
Message-ID: <CA+V-a8th2UnnHf5wNyKg-w30yiJAsPv_BR6bspHe_Tbf4ri_Zw@mail.gmail.com>

On Tue, Apr 9, 2013 at 11:27 PM, Andreas Schwab <schwab at linux-m68k.org> wrote:
> The headers are now needed inside scripts/mod since 6543bec
> ("mod/file2alias: make modalias generation safe for cross compiling").
>
> Signed-off-by: Andreas Schwab <schwab at linux-m68k.org>

Reported-by: Lad, Prabhakar <prabhakar.csengg at gmail.com>
Tested-by: Lad, Prabhakar <prabhakar.csengg at gmail.com>

Regards,
--Prabhakar

> ---
> Prabhakar Lad <prabhakar.csengg at gmail.com> writes:
>
>> Whats the status of it ?
>
> I think it has sufficiently been tested by now.
>
> Andreas.
> ---
>  Makefile | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/Makefile b/Makefile
> index 6db672b..11157bd 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -513,7 +513,8 @@ ifeq ($(KBUILD_EXTMOD),)
>  # Carefully list dependencies so we do not try to build scripts twice
>  # in parallel
>  PHONY += scripts
> -scripts: scripts_basic include/config/auto.conf include/config/tristate.conf
> +scripts: scripts_basic include/config/auto.conf include/config/tristate.conf \
> +        asm-generic
>         $(Q)$(MAKE) $(build)=$(@)
>
>  # Objects we will link into vmlinux / subdirs we need to visit
> --
> 1.8.2.1
>
>
> --
> Andreas Schwab, schwab at linux-m68k.org
> GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
> "And now for something completely different."


From horms at verge.net.au  Wed Apr 10 00:49:23 2013
From: horms at verge.net.au (Simon Horman)
Date: Wed, 10 Apr 2013 13:49:23 +0900
Subject: [PATCH v3 0/9] Reorganize R8A7779/Marzen USB code
In-Reply-To: <201304100226.08967.sergei.shtylyov@cogentembedded.com>
References: <201304100226.08967.sergei.shtylyov@cogentembedded.com>
Message-ID: <20130410044923.GD10044@verge.net.au>

On Wed, Apr 10, 2013 at 02:26:08AM +0400, Sergei Shtylyov wrote:
> Hello.
> 
>    Here's the set of 9 patches against the Simon Horman's 'renesas.git' repo,
> 'renesas-next-20130410' tag.  It was created to fix the shortcomings in the
> R8A7779/Marzen USB platform code and R8A7779 USB common PHY driver, and so
> spans both arch/arm/mach-shmobile/ and drivers/usb/ subtrees (some patches have
> to touch both subtrees). The patches were conceived with the complete
> bisectability goal in mind.
> 
> [1/9] ARM: shmobile: Marzen: move USB EHCI, OHCI, and PHY devices to R8A7779 code
> [2/9] ehci-platform: add pre_setup() method to platform data
> [3/9] ARM: shmobile: R8A7779: setup EHCI internal buffer
> [4/9] rcar-phy: remove EHCI internal buffer setup
> [5/9] ARM: shmobile: R8A7779: remove USB PHY 2nd memory resource
> [6/9] rcar-phy: correct base address
> [7/9] rcar-phy: add platform data
> [8/9] ARM: shmobile: Marzen: pass platform data to USB PHY device
> [9/9] rcar-phy: handle platform data
> 
>    I'm not sure thru which tree this patchset should be merged, however it turns
> out that it's too late now to push it thru Felipe Balbi's USB tree for 3.10
> (which would have been most convenient probably), and it's probably too late to
> merge thru Simon's tree for 3.10 too. So it now have to be postponed to 3.11,
> unfortunately...

Felipe, how would you prefer to handle this?
I'm happy for you to take it or to take it myself.


From horms+renesas at verge.net.au  Wed Apr 10 00:51:14 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed, 10 Apr 2013 13:51:14 +0900
Subject: [GIT PULL] Renesas ARM and SH based SoC pinmux fixes for v3.10 
Message-ID: <1365569475-28721-1-git-send-email-horms+renesas@verge.net.au>

Hi Arnd, Hi Olof,

The following changes since commit 202ac6a21a79500ef5aab4cd8665be2597e9345c:

  sh-pfc: r8a73a4: Remove unused GPIO bias data (2013-04-03 10:30:43 +0900)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas tags/renesas-pinmux-fixes-for-v3.10

for you to fetch changes up to 407cd59798ff3ee2b3acdc149adf1f10fe8a098c:

  sh-pfc: r8a7779: tidyup intc_irq3_b typo (2013-04-09 17:56:08 +0900)

----------------------------------------------------------------
Renesas ARM and SH based SoC pinmux fixes for v3.10

Correct a typo in sh-pfc r8a7779

----------------------------------------------------------------
Kuninori Morimoto (1):
      sh-pfc: r8a7779: tidyup intc_irq3_b typo

 drivers/pinctrl/sh-pfc/pfc-r8a7779.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


From horms+renesas at verge.net.au  Wed Apr 10 00:51:15 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed, 10 Apr 2013 13:51:15 +0900
Subject: [PATCH] sh-pfc: r8a7779: tidyup intc_irq3_b typo
In-Reply-To: <1365569475-28721-1-git-send-email-horms+renesas@verge.net.au>
References: <1365569475-28721-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1365569475-28721-2-git-send-email-horms+renesas@verge.net.au>

From: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Acked-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
Signed-off-by: Simon Horman <horms at verge.net.au>
---
 drivers/pinctrl/sh-pfc/pfc-r8a7779.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a7779.c b/drivers/pinctrl/sh-pfc/pfc-r8a7779.c
index 62dcdcd..791a671 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a7779.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a7779.c
@@ -2552,7 +2552,7 @@ static const char * const intc_groups[] = {
 	"intc_irq2",
 	"intc_irq2_b",
 	"intc_irq3",
-	"intc_irq4_b",
+	"intc_irq3_b",
 };
 
 static const char * const lbsc_groups[] = {
-- 
1.7.10.4



From eric.y.miao at gmail.com  Wed Apr 10 01:03:34 2013
From: eric.y.miao at gmail.com (Eric Miao)
Date: Wed, 10 Apr 2013 13:03:34 +0800
Subject: [PATCH] ARM: pxa: move debug uart code
In-Reply-To: <1365567243-17872-1-git-send-email-haojian.zhuang@linaro.org>
References: <1365567243-17872-1-git-send-email-haojian.zhuang@linaro.org>
Message-ID: <CAMPhdO_prXOJA_ffNqFLy1eRxYy77qHAta8ir4kCKRe3ohK2_w@mail.gmail.com>

On Wed, Apr 10, 2013 at 12:14 PM, Haojian Zhuang
<haojian.zhuang at linaro.org> wrote:
> Move debug uart code from mach-pxa/mach-mmp to debug directory.
> Since they are similar, merge them together.
>
> Signed-off-by: Haojian Zhuang <haojian.zhuang at linaro.org>

Good move,

Acked-by: Eric Miao <eric.y.miao at gmail.com>

> ---
>  arch/arm/Kconfig.debug                       |    9 +++++++
>  arch/arm/include/debug/pxa.S                 |   33 ++++++++++++++++++++++++++
>  arch/arm/mach-mmp/include/mach/debug-macro.S |   30 -----------------------
>  arch/arm/mach-pxa/include/mach/debug-macro.S |   23 ------------------
>  4 files changed, 42 insertions(+), 53 deletions(-)
>  create mode 100644 arch/arm/include/debug/pxa.S
>  delete mode 100644 arch/arm/mach-mmp/include/mach/debug-macro.S
>  delete mode 100644 arch/arm/mach-pxa/include/mach/debug-macro.S
>
> diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
> index 2bf1973..2267ff7 100644
> --- a/arch/arm/Kconfig.debug
> +++ b/arch/arm/Kconfig.debug
> @@ -330,6 +330,13 @@ choice
>                   Say Y here if you want kernel low-level debugging support
>                   on PicoXcell based platforms.
>
> +       config DEBUG_PXA_UART1
> +               depends on ARCH_PXA
> +               bool "Use PXA UAR0 for low-level debug"
> +               help
> +                 Say Y here if you want kernel low-level debugging support
> +                 on PXA UART1.
> +
>         config DEBUG_REALVIEW_STD_PORT
>                 bool "RealView Default UART"
>                 depends on ARCH_REALVIEW
> @@ -615,6 +622,8 @@ config DEBUG_LL_INCLUDE
>         default "debug/mxs.S" if DEBUG_IMX23_UART || DEBUG_IMX28_UART
>         default "debug/omap2plus.S" if DEBUG_OMAP2PLUS_UART
>         default "debug/picoxcell.S" if DEBUG_PICOXCELL_UART
> +       default "debug/pxa.S" if DEBUG_PXA_UART1 || DEBUG_MMP_UART2 || \
> +                                DEBUG_MMP_UART3
>         default "debug/sirf.S" if DEBUG_SIRFPRIMA2_UART1 || DEBUG_SIRFMARCO_UART1
>         default "debug/socfpga.S" if DEBUG_SOCFPGA_UART
>         default "debug/sunxi.S" if DEBUG_SUNXI_UART0 || DEBUG_SUNXI_UART1
> diff --git a/arch/arm/include/debug/pxa.S b/arch/arm/include/debug/pxa.S
> new file mode 100644
> index 0000000..e1e795a
> --- /dev/null
> +++ b/arch/arm/include/debug/pxa.S
> @@ -0,0 +1,33 @@
> +/*
> + * Early serial output macro for Marvell PXA/MMP SoC
> + *
> + * Copyright (C) 1994-1999 Russell King
> + * Moved from linux/arch/arm/kernel/debug.S by Ben Dooks
> + *
> + * Copyright (C) 2013 Haojian Zhuang
> + *
> + * 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.
> +*/
> +
> +#if defined(CONFIG_DEBUG_PXA_UART1)
> +#define PXA_UART_REG_PHYS_BASE 0x40100000
> +#define PXA_UART_REG_VIRT_BASE 0xf2100000
> +#elif defined(CONFIG_DEBUG_MMP_UART2)
> +#define PXA_UART_REG_PHYS_BASE 0xd4017000
> +#define PXA_UART_REG_VIRT_BASE 0xfe017000
> +#elif defined(CONFIG_DEBUG_MMP_UART3)
> +#define PXA_UART_REG_PHYS_BASE 0xd4018000
> +#define PXA_UART_REG_VIRT_BASE 0xfe018000
> +#else
> +#error "Select uart for DEBUG_LL"
> +#endif
> +
> +       .macro  addruart, rp, rv, tmp
> +       ldr     \rp, =PXA_UART_REG_PHYS_BASE
> +       ldr     \rv, =PXA_UART_REG_VIRT_BASE
> +       .endm
> +
> +#define UART_SHIFT     2
> +#include <asm/hardware/debug-8250.S>
> diff --git a/arch/arm/mach-mmp/include/mach/debug-macro.S b/arch/arm/mach-mmp/include/mach/debug-macro.S
> deleted file mode 100644
> index 5c3cc29..0000000
> --- a/arch/arm/mach-mmp/include/mach/debug-macro.S
> +++ /dev/null
> @@ -1,30 +0,0 @@
> -/* arch/arm/mach-mmp/include/mach/debug-macro.S
> - *
> - * Debugging macro include header
> - *
> - *  Copied from arch/arm/mach-pxa/include/mach/debug.S
> - *
> - * 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.
> - */
> -
> -#if defined(CONFIG_DEBUG_MMP_UART2)
> -#define MMP_UART_OFFSET        0x00017000
> -#elif defined(CONFIG_DEBUG_MMP_UART3)
> -#define MMP_UART_OFFSET        0x00018000
> -#else
> -#error "Select uart for DEBUG_LL"
> -#endif
> -
> -#include <mach/addr-map.h>
> -
> -               .macro  addruart, rp, rv, tmp
> -               ldr     \rp, =APB_PHYS_BASE             @ physical
> -               ldr     \rv, =APB_VIRT_BASE             @ virtual
> -               orr     \rp, \rp, #MMP_UART_OFFSET
> -               orr     \rv, \rv, #MMP_UART_OFFSET
> -               .endm
> -
> -#define UART_SHIFT     2
> -#include <asm/hardware/debug-8250.S>
> diff --git a/arch/arm/mach-pxa/include/mach/debug-macro.S b/arch/arm/mach-pxa/include/mach/debug-macro.S
> deleted file mode 100644
> index 70b112e..0000000
> --- a/arch/arm/mach-pxa/include/mach/debug-macro.S
> +++ /dev/null
> @@ -1,23 +0,0 @@
> -/* arch/arm/mach-pxa/include/mach/debug-macro.S
> - *
> - * Debugging macro include header
> - *
> - *  Copyright (C) 1994-1999 Russell King
> - *  Moved from linux/arch/arm/kernel/debug.S by Ben Dooks
> - *
> - * 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 "hardware.h"
> -
> -               .macro  addruart, rp, rv, tmp
> -               mov     \rp, #0x00100000
> -               orr     \rv, \rp, #io_p2v(0x40000000)   @ virtual
> -               orr     \rp, \rp, #0x40000000           @ physical
> -               .endm
> -
> -#define UART_SHIFT     2
> -#include <asm/hardware/debug-8250.S>
> --
> 1.7.10.4
>


From hvaibhav at ti.com  Wed Apr 10 01:11:31 2013
From: hvaibhav at ti.com (Hiremath, Vaibhav)
Date: Wed, 10 Apr 2013 05:11:31 +0000
Subject: [RFC PATCH 3/3] ARM: OMAP2+: Add command line parameter for
 debugSS module control
In-Reply-To: <20130409163459.GJ10155@atomide.com>
References: <hvaibhav@ti.com>
 <1362396957-30113-4-git-send-email-hvaibhav@ti.com>
 <20130408172936.GQ10155@atomide.com>
 <79CD15C6BA57404B839C016229A409A83EC47BB2@DBDE01.ent.ti.com>
 <20130409163459.GJ10155@atomide.com>
Message-ID: <79CD15C6BA57404B839C016229A409A83EC4A236@DBDE01.ent.ti.com>


> -----Original Message-----
> From: Tony Lindgren [mailto:tony at atomide.com]
> Sent: Tuesday, April 09, 2013 10:05 PM
> To: Hiremath, Vaibhav
> Cc: linux-omap at vger.kernel.org; khilman at linaro.org; paul at pwsan.com;
> Nayak, Rajendra; linux-arm-kernel at lists.infradead.org
> Subject: Re: [RFC PATCH 3/3] ARM: OMAP2+: Add command line parameter
> for debugSS module control
> 
> * Hiremath, Vaibhav <hvaibhav at ti.com> [130409 01:12]:
> > > From: Tony Lindgren [mailto:tony at atomide.com]
> > >
> > > I suggest you just make this part into a standard DT only
> > > device driver. That way the command line parsing and clock
> > > enabling can happen the normal way.
> > >
> >
> > That?s good idea, as we are moving towards DT only boot support.
> > Also, are you suggesting to have both command-line param and DT
> > Property for this?
> >
> >
> > > Is there any reason why this could not be a loadable module?
> > >
> >
> > Because we want to keep it enabled before late_initcall. As part of
> late_initcall
> > Clock/hwmod framework will start disabling unused modules, which will
> impact the
> > Debugs as well. Consider the case where this debugss is loaded as a
> module, the user
> > Will loose the JTAG connection until the module is loaded; and once
> module is
> > Loaded, he has to again re-connect to the debugss.
> 
> It will get run before late_initcall if compiled in. Sounds
> like there are no issues also make it work as a loadable module
> as needed.
> 
Agreed on making it as a module.

But do you think we should allow it as a loadable module (M) as well, 
as user will loose Connectivity to JTAG during boot.
Another perspective here would be, user can insert the module and
Get JTAG connectivity, which also seems ok to me.

Can you also confirm on having command line argument? I think
We can only live with DT based approach, right?

Thanks,
Vaibhav 


From avinashphilip at ti.com  Wed Apr 10 01:30:15 2013
From: avinashphilip at ti.com (Philip, Avinash)
Date: Wed, 10 Apr 2013 05:30:15 +0000
Subject: [PATCH v3 3/3] ARM: davinci: da850: add EHRPWM & ECAP DT node
In-Reply-To: <5163FCFD.6070606@ti.com>
References: <1364197789-16783-1-git-send-email-avinashphilip@ti.com>
 <1364197789-16783-4-git-send-email-avinashphilip@ti.com>
 <515A97DE.1080403@ti.com>
 <518397C60809E147AF5323E0420B992E3EAA91B6@DBDE01.ent.ti.com>
 <5162C1A5.5060808@ti.com>
 <518397C60809E147AF5323E0420B992E3EAA9DA3@DBDE01.ent.ti.com>
 <5163FCFD.6070606@ti.com>
Message-ID: <518397C60809E147AF5323E0420B992E3EAAB235@DBDE01.ent.ti.com>

On Tue, Apr 09, 2013 at 17:05:25, Nori, Sekhar wrote:
> On 4/9/2013 2:12 PM, Philip, Avinash wrote:
> > On Mon, Apr 08, 2013 at 18:39:57, Nori, Sekhar wrote:
> >>
> >> On 4/8/2013 2:39 PM, Philip, Avinash wrote:
> >>> On Tue, Apr 02, 2013 at 14:03:34, Nori, Sekhar wrote:
> >>>> On 3/25/2013 1:19 PM, Philip Avinash wrote:
> >>>>> Add da850 EHRPWM & ECAP DT node.
> >>>>> Also adds OF_DEV_AUXDATA for EHRPWM & ECAP driver to use EHRPWM & ECAP
> >>>>> clock.
> >>>>
> >>>> This looks fine to me but I will wait for the bindings to get accepted
> >>>> before taking this one.
> >>>
> >>> Sekhar,
> >>>
> >>> Binding document got accepted in PWM tree [1].
> >>> Can you accept this patch?
> >>
> >> Can you also add the pinmux definitions and resend just this patch?
> >> Sorry I did not notice those were missing earlier.
> > 
> > According to latest schematics, ECAP instance 2 being used for PWM backlight
> > control. Should I add pin-mux only for ECAP2 or for all PWM instances?
> 
> I meant add definitions in .dtsi. Since there is only one pin a given
> functionality can be present on in DaVinci, it can be done in a board
> independent manner.

I think here the expectation would be that .dtsi should populate the complete
pin-mux for SOC and board files should just be able to re-use it (add it as a phandler).
Also as per the above description .dtsi file will end up contain majorly pin-mux info
rather than the hardware data. Is it a good idea?

On looking da850.dtsi file NAND pins were defined for 8-bit part. 
In case of NAND flash, the device might be sitting under different chip-select or may
have 16 bit part on  different boards. So pin-mux defined in soc.dtsi has to be split
separately for CS, DATA, Address.

So it is always challenging to create pin-mux info in .dtsi file. So more useful/meaningful
way is to actually create pin-mux in board file rather in .dtsi file.

> See examples for other peripherals in existing
> da850.dtsi file.

I have gone through .dtsi. But it didn't describe the complete pin-mux like I2C1, MMC1, etc.
So the expectation here is only to add ECAP2 pin-mux. Is it correct?

Thanks
Avinash

> 
> Thanks,
> Sekhar
> 


From nsekhar at ti.com  Wed Apr 10 01:55:19 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Wed, 10 Apr 2013 11:25:19 +0530
Subject: [PATCH v3 3/3] ARM: davinci: da850: add EHRPWM & ECAP DT node
In-Reply-To: <518397C60809E147AF5323E0420B992E3EAAB235@DBDE01.ent.ti.com>
References: <1364197789-16783-1-git-send-email-avinashphilip@ti.com>
 <1364197789-16783-4-git-send-email-avinashphilip@ti.com>
 <515A97DE.1080403@ti.com>
 <518397C60809E147AF5323E0420B992E3EAA91B6@DBDE01.ent.ti.com>
 <5162C1A5.5060808@ti.com>
 <518397C60809E147AF5323E0420B992E3EAA9DA3@DBDE01.ent.ti.com>
 <5163FCFD.6070606@ti.com>
 <518397C60809E147AF5323E0420B992E3EAAB235@DBDE01.ent.ti.com>
Message-ID: <5164FEC7.4010504@ti.com>

On 4/10/2013 11:00 AM, Philip, Avinash wrote:
> On Tue, Apr 09, 2013 at 17:05:25, Nori, Sekhar wrote:
>> On 4/9/2013 2:12 PM, Philip, Avinash wrote:
>>> On Mon, Apr 08, 2013 at 18:39:57, Nori, Sekhar wrote:
>>>>
>>>> On 4/8/2013 2:39 PM, Philip, Avinash wrote:
>>>>> On Tue, Apr 02, 2013 at 14:03:34, Nori, Sekhar wrote:
>>>>>> On 3/25/2013 1:19 PM, Philip Avinash wrote:
>>>>>>> Add da850 EHRPWM & ECAP DT node.
>>>>>>> Also adds OF_DEV_AUXDATA for EHRPWM & ECAP driver to use EHRPWM & ECAP
>>>>>>> clock.
>>>>>>
>>>>>> This looks fine to me but I will wait for the bindings to get accepted
>>>>>> before taking this one.
>>>>>
>>>>> Sekhar,
>>>>>
>>>>> Binding document got accepted in PWM tree [1].
>>>>> Can you accept this patch?
>>>>
>>>> Can you also add the pinmux definitions and resend just this patch?
>>>> Sorry I did not notice those were missing earlier.
>>>
>>> According to latest schematics, ECAP instance 2 being used for PWM backlight
>>> control. Should I add pin-mux only for ECAP2 or for all PWM instances?
>>
>> I meant add definitions in .dtsi. Since there is only one pin a given
>> functionality can be present on in DaVinci, it can be done in a board
>> independent manner.
> 
> I think here the expectation would be that .dtsi should populate the complete
> pin-mux for SOC and board files should just be able to re-use it (add it as a phandler).

Yes, that's the idea.

> Also as per the above description .dtsi file will end up contain majorly pin-mux info
> rather than the hardware data. Is it a good idea?

Pinmux is also hardware data, no? Thats why its present in DT.

> On looking da850.dtsi file NAND pins were defined for 8-bit part. 
> In case of NAND flash, the device might be sitting under different chip-select or may
> have 16 bit part on  different boards. So pin-mux defined in soc.dtsi has to be split
> separately for CS, DATA, Address.

The idea is to define pin groups that most of the time can be reused by
.dts file as-is and if there are any board specific extra pins needed
then they can be handled directly in .dts files. But the common cases
don't have to be repeated in all boards. In case of NAND, CS and the top
8-pins when using a 16-bit bus can be moved to a different group. So, I
agree instead of nand_cs3_pins, we could have had nand_pins and moved cs
definitions to another re-usable group.

> So it is always challenging to create pin-mux info in .dtsi file. So more useful/meaningful
> way is to actually create pin-mux in board file rather in .dtsi file.

I don't see why it is so challenging. Repeating the same pinmux
information over multiple .dts file (while making errors copying) will
be challenging. And its not as if this is my original idea. imx (and I
think some others) are doing it as well. See how pinmux is defined in
imx53.dtsi and reused in a number of boards like evk, qsb, smd and so on.

>> See examples for other peripherals in existing
>> da850.dtsi file.
> 
> I have gone through .dtsi. But it didn't describe the complete pin-mux like I2C1, MMC1, etc.

pinmux should be added for whatever nodes are added since pimux is part
of node.

> So the expectation here is only to add ECAP2 pin-mux. Is it correct?

No, please add pinmux information for all the IP nodes you are adding. I
am not insisting that you add all IP nodes at the same time. You can add
whatever you have tested.

Thanks,
Sekhar


From avinashphilip at ti.com  Wed Apr 10 02:07:41 2013
From: avinashphilip at ti.com (Philip, Avinash)
Date: Wed, 10 Apr 2013 06:07:41 +0000
Subject: [PATCH v3 3/3] ARM: davinci: da850: add EHRPWM & ECAP DT node
In-Reply-To: <5164FEC7.4010504@ti.com>
References: <1364197789-16783-1-git-send-email-avinashphilip@ti.com>
 <1364197789-16783-4-git-send-email-avinashphilip@ti.com>
 <515A97DE.1080403@ti.com>
 <518397C60809E147AF5323E0420B992E3EAA91B6@DBDE01.ent.ti.com>
 <5162C1A5.5060808@ti.com>
 <518397C60809E147AF5323E0420B992E3EAA9DA3@DBDE01.ent.ti.com>
 <5163FCFD.6070606@ti.com>
 <518397C60809E147AF5323E0420B992E3EAAB235@DBDE01.ent.ti.com>
 <5164FEC7.4010504@ti.com>
Message-ID: <518397C60809E147AF5323E0420B992E3EAAB26D@DBDE01.ent.ti.com>

On Wed, Apr 10, 2013 at 11:25:19, Nori, Sekhar wrote:
> On 4/10/2013 11:00 AM, Philip, Avinash wrote:
> > On Tue, Apr 09, 2013 at 17:05:25, Nori, Sekhar wrote:
> >> On 4/9/2013 2:12 PM, Philip, Avinash wrote:
> >>> On Mon, Apr 08, 2013 at 18:39:57, Nori, Sekhar wrote:
> >>>>
> >>>> On 4/8/2013 2:39 PM, Philip, Avinash wrote:
> >>>>> On Tue, Apr 02, 2013 at 14:03:34, Nori, Sekhar wrote:
> >>>>>> On 3/25/2013 1:19 PM, Philip Avinash wrote:
> >>>>>>> Add da850 EHRPWM & ECAP DT node.
> >>>>>>> Also adds OF_DEV_AUXDATA for EHRPWM & ECAP driver to use EHRPWM & ECAP
> >>>>>>> clock.
> >>>>>>
> >>>>>> This looks fine to me but I will wait for the bindings to get accepted
> >>>>>> before taking this one.
> >>>>>
> >>>>> Sekhar,
> >>>>>
> >>>>> Binding document got accepted in PWM tree [1].
> >>>>> Can you accept this patch?
> >>>>
> >>>> Can you also add the pinmux definitions and resend just this patch?
> >>>> Sorry I did not notice those were missing earlier.
> >>>
> >>> According to latest schematics, ECAP instance 2 being used for PWM backlight
> >>> control. Should I add pin-mux only for ECAP2 or for all PWM instances?
> >>
> >> I meant add definitions in .dtsi. Since there is only one pin a given
> >> functionality can be present on in DaVinci, it can be done in a board
> >> independent manner.
> > 
> > I think here the expectation would be that .dtsi should populate the complete
> > pin-mux for SOC and board files should just be able to re-use it (add it as a phandler).
> 
> Yes, that's the idea.

Ok

> 
> > Also as per the above description .dtsi file will end up contain majorly pin-mux info
> > rather than the hardware data. Is it a good idea?
> 
> Pinmux is also hardware data, no? Thats why its present in DT.

I understood.

> 
> > On looking da850.dtsi file NAND pins were defined for 8-bit part. 
> > In case of NAND flash, the device might be sitting under different chip-select or may
> > have 16 bit part on  different boards. So pin-mux defined in soc.dtsi has to be split
> > separately for CS, DATA, Address.
> 
> The idea is to define pin groups that most of the time can be reused by
> .dts file as-is and if there are any board specific extra pins needed
> then they can be handled directly in .dts files. But the common cases
> don't have to be repeated in all boards. In case of NAND, CS and the top
> 8-pins when using a 16-bit bus can be moved to a different group. So, I
> agree instead of nand_cs3_pins, we could have had nand_pins and moved cs
> definitions to another re-usable group.

Ok, thanks for the detailed explanation.

> 
> > So it is always challenging to create pin-mux info in .dtsi file. So more useful/meaningful
> > way is to actually create pin-mux in board file rather in .dtsi file.
> 
> I don't see why it is so challenging. Repeating the same pinmux
> information over multiple .dts file (while making errors copying) will
> be challenging. And its not as if this is my original idea. imx (and I
> think some others) are doing it as well. See how pinmux is defined in
> imx53.dtsi and reused in a number of boards like evk, qsb, smd and so on.
> 
> >> See examples for other peripherals in existing
> >> da850.dtsi file.
> > 
> > I have gone through .dtsi. But it didn't describe the complete pin-mux like I2C1, MMC1, etc.
> 
> pinmux should be added for whatever nodes are added since pimux is part
> of node.
> 
> > So the expectation here is only to add ECAP2 pin-mux. Is it correct?
> 
> No, please add pinmux information for all the IP nodes you are adding. I
> am not insisting that you add all IP nodes at the same time. You can add
> whatever you have tested.

I actually tested EHRPWM1A and EHRPWM1B in older boards for back light support.
But in latest schematics shows ECAP2 being used for backlight control and can't
be tested as boards with this change is not accessible to me.
So I will add tested pin-mux details.

Thanks
Avinash

> 
> Thanks,
> Sekhar
> 


From santosh.shilimkar at ti.com  Wed Apr 10 02:17:15 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Wed, 10 Apr 2013 11:47:15 +0530
Subject: [PATCH v3 2/4] ARM: OMAP4+: PM: Consolidate OMAP4 PM code to
 re-use it for OMAP5
In-Reply-To: <20130409165503.GM10155@atomide.com>
References: <1365166743-5940-1-git-send-email-santosh.shilimkar@ti.com>
 <1365166743-5940-3-git-send-email-santosh.shilimkar@ti.com>
 <20130405213433.GF10155@atomide.com> <5162A093.7090808@ti.com>
 <20130408164228.GK10155@atomide.com> <5163B19E.30105@ti.com>
 <20130409165503.GM10155@atomide.com>
Message-ID: <516503EB.8080805@ti.com>

On Tuesday 09 April 2013 10:25 PM, Tony Lindgren wrote:
> * Santosh Shilimkar <santosh.shilimkar at ti.com> [130408 23:16]:
>>>
>> As I said, the IP has been there from OMAP2XX days. Here the case that
>> IP version is very similar between OMAP4, OMAP5. DRA(next SOC) and its
>> derivatives. Hence can share most of the code. I thought this was good
>> enough reason considering at least 4 family of SOC's can make use
>> of the code.
> 
> Well at least that might be enough of a reasoning to rename it as
> it is somewhat futureproof.
>
Yep. I can't see to much further in future but there is a *strong*
mandate to not break compatibility so hopefully we won't see too
much churn for similar IP blocks in future. 
  
>> It has nothing to do with SMP etc specifically and rather the similarity
>> between the PM infrastructure on the mentioned SOCs. 
>>
>> Let me know if you can suggested better name than what I chose ?
> 
> Not really except something like pm-iprevXXX.[chS] where the rev is
> the first revision that it works with?
> 
> But then again if it's touching registers all over the place directly,
> that naming does not make much sense either :)
> 
Exactly. Thanks for the discussion. I will go ahead with rename
when we add OMAP5 stuff like I did in earlier patch.
i.e
pm44xx.c --> pm_omap4plus.c
sleep44xx.S --> sleep_omap4plus.S

Regrads,
Santosh



From grinberg at compulab.co.il  Wed Apr 10 02:47:03 2013
From: grinberg at compulab.co.il (Igor Grinberg)
Date: Wed, 10 Apr 2013 09:47:03 +0300
Subject: [PATCH] ARM: pxa: move debug uart code
In-Reply-To: <1365567243-17872-1-git-send-email-haojian.zhuang@linaro.org>
References: <1365567243-17872-1-git-send-email-haojian.zhuang@linaro.org>
Message-ID: <51650AE7.5050701@compulab.co.il>

On 04/10/13 07:14, Haojian Zhuang wrote:
> Move debug uart code from mach-pxa/mach-mmp to debug directory.
> Since they are similar, merge them together.
> 
> Signed-off-by: Haojian Zhuang <haojian.zhuang at linaro.org>
> ---
>  arch/arm/Kconfig.debug                       |    9 +++++++
>  arch/arm/include/debug/pxa.S                 |   33 ++++++++++++++++++++++++++
>  arch/arm/mach-mmp/include/mach/debug-macro.S |   30 -----------------------
>  arch/arm/mach-pxa/include/mach/debug-macro.S |   23 ------------------
>  4 files changed, 42 insertions(+), 53 deletions(-)
>  create mode 100644 arch/arm/include/debug/pxa.S
>  delete mode 100644 arch/arm/mach-mmp/include/mach/debug-macro.S
>  delete mode 100644 arch/arm/mach-pxa/include/mach/debug-macro.S
> 
> diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
> index 2bf1973..2267ff7 100644
> --- a/arch/arm/Kconfig.debug
> +++ b/arch/arm/Kconfig.debug
> @@ -330,6 +330,13 @@ choice
>  		  Say Y here if you want kernel low-level debugging support
>  		  on PicoXcell based platforms.
>  
> +	config DEBUG_PXA_UART1
> +		depends on ARCH_PXA
> +		bool "Use PXA UAR0 for low-level debug"

s/UAR0/UART0/

> +		help
> +		  Say Y here if you want kernel low-level debugging support
> +		  on PXA UART1.
> +
>  	config DEBUG_REALVIEW_STD_PORT
>  		bool "RealView Default UART"
>  		depends on ARCH_REALVIEW

[...]


-- 
Regards,
Igor.


From haojian.zhuang at gmail.com  Wed Apr 10 02:52:30 2013
From: haojian.zhuang at gmail.com (Haojian Zhuang)
Date: Wed, 10 Apr 2013 14:52:30 +0800
Subject: [PATCH] ARM: pxa: move debug uart code
In-Reply-To: <51650AE7.5050701@compulab.co.il>
References: <1365567243-17872-1-git-send-email-haojian.zhuang@linaro.org>
 <51650AE7.5050701@compulab.co.il>
Message-ID: <CAN1soZyrDOv=YpxkH73dFLqQviGjTgJc534ccicgpwOyaeUR3w@mail.gmail.com>

On Wed, Apr 10, 2013 at 2:47 PM, Igor Grinberg <grinberg at compulab.co.il> wrote:
> On 04/10/13 07:14, Haojian Zhuang wrote:
>> Move debug uart code from mach-pxa/mach-mmp to debug directory.
>> Since they are similar, merge them together.
>>
>> Signed-off-by: Haojian Zhuang <haojian.zhuang at linaro.org>
>> ---
>>  arch/arm/Kconfig.debug                       |    9 +++++++
>>  arch/arm/include/debug/pxa.S                 |   33 ++++++++++++++++++++++++++
>>  arch/arm/mach-mmp/include/mach/debug-macro.S |   30 -----------------------
>>  arch/arm/mach-pxa/include/mach/debug-macro.S |   23 ------------------
>>  4 files changed, 42 insertions(+), 53 deletions(-)
>>  create mode 100644 arch/arm/include/debug/pxa.S
>>  delete mode 100644 arch/arm/mach-mmp/include/mach/debug-macro.S
>>  delete mode 100644 arch/arm/mach-pxa/include/mach/debug-macro.S
>>
>> diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
>> index 2bf1973..2267ff7 100644
>> --- a/arch/arm/Kconfig.debug
>> +++ b/arch/arm/Kconfig.debug
>> @@ -330,6 +330,13 @@ choice
>>                 Say Y here if you want kernel low-level debugging support
>>                 on PicoXcell based platforms.
>>
>> +     config DEBUG_PXA_UART1
>> +             depends on ARCH_PXA
>> +             bool "Use PXA UAR0 for low-level debug"
>
> s/UAR0/UART0/
Yes, it should be UART1. It's a typo error.

>
>> +             help
>> +               Say Y here if you want kernel low-level debugging support
>> +               on PXA UART1.
>> +
>>       config DEBUG_REALVIEW_STD_PORT
>>               bool "RealView Default UART"
>>               depends on ARCH_REALVIEW
>
> [...]
>
>
> --
> Regards,
> Igor.
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From sfr at canb.auug.org.au  Wed Apr 10 03:10:01 2013
From: sfr at canb.auug.org.au (Stephen Rothwell)
Date: Wed, 10 Apr 2013 17:10:01 +1000
Subject: linux-next: manual merge of the arm-soc tree with the pinctrl tree
Message-ID: <20130410171001.d485e70b48cd1a64dd2a6343@canb.auug.org.au>

Hi all,

Today's linux-next merge of the arm-soc tree got conflicts in
drivers/pinctrl/pinctrl-samsung.c and drivers/pinctrl/pinctrl-samsung.h
between commit 61dd72613177 ("pinctrl: Add pinctrl-s3c64xx driver") from
the pinctrl tree and commit f67faf487fc1 ("pinctrl: exynos: add
exynos5250 SoC specific data") from the arm-soc tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr at canb.auug.org.au

diff --cc drivers/pinctrl/pinctrl-samsung.c
index 4f54faf,fe7ace2..0000000
--- a/drivers/pinctrl/pinctrl-samsung.c
+++ b/drivers/pinctrl/pinctrl-samsung.c
@@@ -970,11 -948,8 +970,13 @@@ static const struct of_device_id samsun
  		.data = (void *)exynos4210_pin_ctrl },
  	{ .compatible = "samsung,exynos4x12-pinctrl",
  		.data = (void *)exynos4x12_pin_ctrl },
 +#endif
 +#ifdef CONFIG_PINCTRL_S3C64XX
 +	{ .compatible = "samsung,s3c64xx-pinctrl",
 +		.data = s3c64xx_pin_ctrl },
 +#endif
+ 	{ .compatible = "samsung,exynos5250-pinctrl",
+ 		.data = (void *)exynos5250_pin_ctrl },
  	{},
  };
  MODULE_DEVICE_TABLE(of, samsung_pinctrl_dt_match);
diff --cc drivers/pinctrl/pinctrl-samsung.h
index 45f27b4,ee964aa..0000000
--- a/drivers/pinctrl/pinctrl-samsung.h
+++ b/drivers/pinctrl/pinctrl-samsung.h
@@@ -244,6 -237,6 +244,7 @@@ struct samsung_pmx_func 
  /* list of all exported SoC specific data */
  extern struct samsung_pin_ctrl exynos4210_pin_ctrl[];
  extern struct samsung_pin_ctrl exynos4x12_pin_ctrl[];
 +extern struct samsung_pin_ctrl s3c64xx_pin_ctrl[];
+ extern struct samsung_pin_ctrl exynos5250_pin_ctrl[];
  
  #endif /* __PINCTRL_SAMSUNG_H */

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130410/7cccf4bf/attachment.sig>

From sfr at canb.auug.org.au  Wed Apr 10 03:17:43 2013
From: sfr at canb.auug.org.au (Stephen Rothwell)
Date: Wed, 10 Apr 2013 17:17:43 +1000
Subject: linux-next: manual merge of the arm-soc tree with the pm tree
Message-ID: <20130410171743.2ffa67388b330991228a6775@canb.auug.org.au>

Hi all,

Today's linux-next merge of the arm-soc tree got a conflict in
arch/arm/mach-s3c24xx/Kconfig between commit 785f40040874 ("cpufreq:
s3c24xx: move cpufreq driver to drivers/cpufreq") from the pm tree and
commits fb278af74b28 ("ARM: S3C24XX: Removed unneeded dependency on
CPU_S3C2410") and a4e4d22c6f53 ("ARM: S3C24XX: Removed unneeded
dependency on CPU_S3C2412") from the arm-soc tree.

I fixed it up by removing the sections from arch/arm/mach-s3c24xx/Kconfig
and can carry thefix as necessary (no action is required).

P.S. those arm-soc tree commits have a bad Author email address ...
-- 
Cheers,
Stephen Rothwell                    sfr at canb.auug.org.au
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130410/0accd4a6/attachment.sig>

From Andrew.Murray at arm.com  Wed Apr 10 03:29:25 2013
From: Andrew.Murray at arm.com (Andrew Murray)
Date: Wed, 10 Apr 2013 08:29:25 +0100
Subject: [PATCH v5 0/3] of/pci: Provide common support for PCI DT parsing
Message-ID: <1365578969-30966-1-git-send-email-Andrew.Murray@arm.com>

This patchset factors out duplicated code associated with parsing PCI
DT "ranges" properties across the architectures and introduces a
"ranges" parser. This parser "of_pci_range_parser" can be used directly
by ARM host bridge drivers enabling them to obtain ranges from device
trees.

Compared to the v4 (incorrectly labelled v3) sent by Andrew Murray,
the following changes have been made:

 * Split the patch as suggested by Rob Herring

Compared to the v3 sent by Andrew Murray, the following changes have
been made:

 * Unify and move duplicate pci_process_bridge_OF_ranges functions to
   drivers/of/of_pci.c as suggested by Rob Herring

 * Fix potential build errors with Microblaze/MIPS

Compared to "[PATCH v5 01/17] of/pci: Provide support for parsing PCI DT
ranges property", the following changes have been made:

 * Correct use of IORESOURCE_* as suggested by Russell King

 * Improved interface and naming as suggested by Thierry Reding

Compared to the v2 sent by Andrew Murray, Thomas Petazzoni did:

 * Add a memset() on the struct of_pci_range_iter when starting the
   for loop in for_each_pci_range(). Otherwise, with an uninitialized
   of_pci_range_iter, of_pci_process_ranges() may crash.

 * Add parenthesis around 'res', 'np' and 'iter' in the
   for_each_of_pci_range macro definitions. Otherwise, passing
   something like &foobar as 'res' didn't work.

 * Rebased on top of 3.9-rc2, which required fixing a few conflicts in
   the Microblaze code.

v2:
  This follows on from suggestions made by Grant Likely
  (marc.info/?l=linux-kernel&m=136079602806328)

Andrew Murray (3):
  of/pci: Unify pci_process_bridge_OF_ranges from Microblaze and
    PowerPC
  of/pci: Provide support for parsing PCI DT ranges property
  of/pci: mips: convert to common of_pci_range_parser

 arch/microblaze/include/asm/pci-bridge.h |    5 +-
 arch/microblaze/pci/pci-common.c         |  192 ------------------------------
 arch/mips/pci/pci.c                      |   50 +++------
 arch/powerpc/include/asm/pci-bridge.h    |    5 +-
 arch/powerpc/kernel/pci-common.c         |  192 ------------------------------
 drivers/of/address.c                     |   63 ++++++++++
 drivers/of/of_pci.c                      |  168 ++++++++++++++++++++++++++
 include/linux/of_address.h               |   42 +++++++
 include/linux/of_pci.h                   |    3 +
 9 files changed, 294 insertions(+), 426 deletions(-)



From Andrew.Murray at arm.com  Wed Apr 10 03:29:27 2013
From: Andrew.Murray at arm.com (Andrew Murray)
Date: Wed, 10 Apr 2013 08:29:27 +0100
Subject: [PATCH v5 2/3] of/pci: Provide support for parsing PCI DT ranges
 property
In-Reply-To: <1365578969-30966-1-git-send-email-Andrew.Murray@arm.com>
References: <1365578969-30966-1-git-send-email-Andrew.Murray@arm.com>
Message-ID: <1365578969-30966-3-git-send-email-Andrew.Murray@arm.com>

This patch factors out common implementation patterns to reduce overall kernel
code and provide a means for host bridge drivers to directly obtain struct
resources from the DT's ranges property without relying on architecture specific
DT handling. This will make it easier to write archiecture independent host bridge
drivers and mitigate against further duplication of DT parsing code.

This patch can be used in the following way:

	struct of_pci_range_parser parser;
	struct of_pci_range range;

	if (of_pci_range_parser(&parser, np))
		; //no ranges property

	for_each_of_pci_range(&parser, &range) {

		/*
			directly access properties of the address range, e.g.:
			range.pci_space, range.pci_addr, range.cpu_addr,
			range.size, range.flags

			alternatively obtain a struct resource, e.g.:
			struct resource res;
			of_pci_range_to_resource(&range, np, &res);
		*/
	}

Additionally the implementation takes care of adjacent ranges and merges them
into a single range (as was the case with powerpc and microblaze).

Signed-off-by: Andrew Murray <Andrew.Murray at arm.com>
Signed-off-by: Liviu Dudau <Liviu.Dudau at arm.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 drivers/of/address.c       |   63 +++++++++++++++++++++++++
 drivers/of/of_pci.c        |  112 ++++++++++++++++----------------------------
 include/linux/of_address.h |   42 ++++++++++++++++
 3 files changed, 145 insertions(+), 72 deletions(-)

diff --git a/drivers/of/address.c b/drivers/of/address.c
index 04da786..e87f45e 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -227,6 +227,69 @@ int of_pci_address_to_resource(struct device_node *dev, int bar,
 	return __of_address_to_resource(dev, addrp, size, flags, NULL, r);
 }
 EXPORT_SYMBOL_GPL(of_pci_address_to_resource);
+
+int of_pci_range_parser(struct of_pci_range_parser *parser,
+			struct device_node *node)
+{
+	const int na = 3, ns = 2;
+	int rlen;
+
+	parser->node = node;
+	parser->pna = of_n_addr_cells(node);
+	parser->np = parser->pna + na + ns;
+
+	parser->range = of_get_property(node, "ranges", &rlen);
+	if (parser->range == NULL)
+		return -ENOENT;
+
+	parser->end = parser->range + rlen / sizeof(__be32);
+
+	return 0;
+}
+
+struct of_pci_range *of_pci_process_ranges(struct of_pci_range_parser *parser,
+						struct of_pci_range *range)
+{
+	const int na = 3, ns = 2;
+
+	if (!parser->range || parser->range + parser->np > parser->end)
+		return NULL;
+
+	range->pci_space = be32_to_cpup(parser->range);
+	range->flags = of_bus_pci_get_flags(parser->range);
+	range->pci_addr = of_read_number(parser->range + 1, ns);
+	range->cpu_addr = of_translate_address(parser->node,
+				parser->range + na);
+	range->size = of_read_number(parser->range + parser->pna + na, ns);
+
+	parser->range += parser->np;
+
+	/* Now consume following elements while they are contiguous */
+	while (parser->range + parser->np <= parser->end) {
+		u32 flags, pci_space;
+		u64 pci_addr, cpu_addr, size;
+
+		pci_space = be32_to_cpup(parser->range);
+		flags = of_bus_pci_get_flags(parser->range);
+		pci_addr = of_read_number(parser->range + 1, ns);
+		cpu_addr = of_translate_address(parser->node,
+				parser->range + na);
+		size = of_read_number(parser->range + parser->pna + na, ns);
+
+		if (flags != range->flags)
+			break;
+		if (pci_addr != range->pci_addr + range->size ||
+		    cpu_addr != range->cpu_addr + range->size)
+			break;
+
+		range->size += size;
+		parser->range += parser->np;
+	}
+
+	return range;
+}
+EXPORT_SYMBOL_GPL(of_pci_process_ranges);
+
 #endif /* CONFIG_PCI */
 
 /*
diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
index 0611248..9680dc6 100644
--- a/drivers/of/of_pci.c
+++ b/drivers/of/of_pci.c
@@ -82,67 +82,43 @@ EXPORT_SYMBOL_GPL(of_pci_find_child_device);
 void pci_process_bridge_OF_ranges(struct pci_controller *hose,
 				  struct device_node *dev, int primary)
 {
-	const u32 *ranges;
-	int rlen;
-	int pna = of_n_addr_cells(dev);
-	int np = pna + 5;
 	int memno = 0, isa_hole = -1;
-	u32 pci_space;
-	unsigned long long pci_addr, cpu_addr, pci_next, cpu_next, size;
 	unsigned long long isa_mb = 0;
 	struct resource *res;
+	struct of_pci_range range;
+	struct of_pci_range_parser parser;
+	u32 res_type;
 
 	pr_info("PCI host bridge %s %s ranges:\n",
 	       dev->full_name, primary ? "(primary)" : "");
 
-	/* Get ranges property */
-	ranges = of_get_property(dev, "ranges", &rlen);
-	if (ranges == NULL)
+	/* Check for ranges property */
+	if (of_pci_range_parser(&parser, dev))
 		return;
 
-	/* Parse it */
 	pr_debug("Parsing ranges property...\n");
-	while ((rlen -= np * 4) >= 0) {
+	for_each_of_pci_range(&parser, &range) {
 		/* Read next ranges element */
-		pci_space = ranges[0];
-		pci_addr = of_read_number(ranges + 1, 2);
-		cpu_addr = of_translate_address(dev, ranges + 3);
-		size = of_read_number(ranges + pna + 3, 2);
-
-		pr_debug("pci_space: 0x%08x pci_addr:0x%016llx ",
-				pci_space, pci_addr);
-		pr_debug("cpu_addr:0x%016llx size:0x%016llx\n",
-					cpu_addr, size);
-
-		ranges += np;
+		pr_debug("pci_space: 0x%08x pci_addr: 0x%016llx ",
+				range.pci_space, range.pci_addr);
+		pr_debug("cpu_addr: 0x%016llx size: 0x%016llx\n",
+				range.cpu_addr, range.size);
 
 		/* If we failed translation or got a zero-sized region
 		 * (some FW try to feed us with non sensical zero sized regions
 		 * such as power3 which look like some kind of attempt
 		 * at exposing the VGA memory hole)
 		 */
-		if (cpu_addr == OF_BAD_ADDR || size == 0)
+		if (range.cpu_addr == OF_BAD_ADDR || range.size == 0)
 			continue;
 
-		/* Now consume following elements while they are contiguous */
-		for (; rlen >= np * sizeof(u32);
-		     ranges += np, rlen -= np * 4) {
-			if (ranges[0] != pci_space)
-				break;
-			pci_next = of_read_number(ranges + 1, 2);
-			cpu_next = of_translate_address(dev, ranges + 3);
-			if (pci_next != pci_addr + size ||
-			    cpu_next != cpu_addr + size)
-				break;
-			size += of_read_number(ranges + pna + 3, 2);
-		}
-
 		/* Act based on address space type */
 		res = NULL;
-		switch ((pci_space >> 24) & 0x3) {
-		case 1:		/* PCI IO space */
+		res_type = range.flags & IORESOURCE_TYPE_BITS;
+		if (res_type == IORESOURCE_IO) {
 			pr_info("  IO 0x%016llx..0x%016llx -> 0x%016llx\n",
-			       cpu_addr, cpu_addr + size - 1, pci_addr);
+				range.cpu_addr, range.cpu_addr + range.size - 1,
+				range.pci_addr);
 
 			/* We support only one IO range */
 			if (hose->pci_io_size) {
@@ -151,11 +127,12 @@ void pci_process_bridge_OF_ranges(struct pci_controller *hose,
 			}
 #if defined(CONFIG_PPC32) || defined(CONFIG_MICROBLAZE)
 			/* On 32 bits, limit I/O space to 16MB */
-			if (size > 0x01000000)
-				size = 0x01000000;
+			if (range.size > 0x01000000)
+				range.size = 0x01000000;
 
 			/* 32 bits needs to map IOs here */
-			hose->io_base_virt = ioremap(cpu_addr, size);
+			hose->io_base_virt = ioremap(range.cpu_addr,
+						range.size);
 
 			/* Expect trouble if pci_addr is not 0 */
 			if (primary)
@@ -165,19 +142,18 @@ void pci_process_bridge_OF_ranges(struct pci_controller *hose,
 			/* pci_io_size and io_base_phys always represent IO
 			 * space starting at 0 so we factor in pci_addr
 			 */
-			hose->pci_io_size = pci_addr + size;
-			hose->io_base_phys = cpu_addr - pci_addr;
+			hose->pci_io_size = range.pci_addr + range.size;
+			hose->io_base_phys = range.cpu_addr - range.pci_addr;
 
 			/* Build resource */
 			res = &hose->io_resource;
-			res->flags = IORESOURCE_IO;
-			res->start = pci_addr;
-			break;
-		case 2:		/* PCI Memory space */
-		case 3:		/* PCI 64 bits Memory space */
+			range.cpu_addr = range.pci_addr;
+		} else if (res_type == IORESOURCE_MEM) {
 			pr_info(" MEM 0x%016llx..0x%016llx -> 0x%016llx %s\n",
-			       cpu_addr, cpu_addr + size - 1, pci_addr,
-			       (pci_space & 0x40000000) ? "Prefetch" : "");
+				range.cpu_addr, range.cpu_addr + range.size - 1,
+				range.pci_addr,
+				(range.pci_space & 0x40000000) ?
+				"Prefetch" : "");
 
 			/* We support only 3 memory ranges */
 			if (memno >= 3) {
@@ -185,13 +161,13 @@ void pci_process_bridge_OF_ranges(struct pci_controller *hose,
 				continue;
 			}
 			/* Handles ISA memory hole space here */
-			if (pci_addr == 0) {
-				isa_mb = cpu_addr;
+			if (range.pci_addr == 0) {
+				isa_mb = range.cpu_addr;
 				isa_hole = memno;
 				if (primary || isa_mem_base == 0)
-					isa_mem_base = cpu_addr;
-				hose->isa_mem_phys = cpu_addr;
-				hose->isa_mem_size = size;
+					isa_mem_base = range.cpu_addr;
+				hose->isa_mem_phys = range.cpu_addr;
+				hose->isa_mem_size = range.size;
 			}
 
 			/* We get the PCI/Mem offset from the first range or
@@ -199,30 +175,22 @@ void pci_process_bridge_OF_ranges(struct pci_controller *hose,
 			 * hole. If they don't match, bugger.
 			 */
 			if (memno == 0 ||
-			    (isa_hole >= 0 && pci_addr != 0 &&
+			(isa_hole >= 0 && range.pci_addr != 0 &&
 			     hose->pci_mem_offset == isa_mb))
-				hose->pci_mem_offset = cpu_addr - pci_addr;
-			else if (pci_addr != 0 &&
-				 hose->pci_mem_offset != cpu_addr - pci_addr) {
+				hose->pci_mem_offset = range.cpu_addr -
+							range.pci_addr;
+			else if (range.pci_addr != 0 &&
+				hose->pci_mem_offset != range.cpu_addr -
+							range.pci_addr) {
 				pr_info(" \\--> Skipped (offset mismatch) !\n");
 				continue;
 			}
 
 			/* Build resource */
 			res = &hose->mem_resources[memno++];
-			res->flags = IORESOURCE_MEM;
-			if (pci_space & 0x40000000)
-				res->flags |= IORESOURCE_PREFETCH;
-			res->start = cpu_addr;
-			break;
-		}
-		if (res != NULL) {
-			res->name = dev->full_name;
-			res->end = res->start + size - 1;
-			res->parent = NULL;
-			res->sibling = NULL;
-			res->child = NULL;
 		}
+		if (res != NULL)
+			of_pci_range_to_resource(&range, dev, res);
 	}
 
 	/* If there's an ISA hole and the pci_mem_offset is -not- matching
diff --git a/include/linux/of_address.h b/include/linux/of_address.h
index 0506eb5..c7003a3 100644
--- a/include/linux/of_address.h
+++ b/include/linux/of_address.h
@@ -4,6 +4,32 @@
 #include <linux/errno.h>
 #include <linux/of.h>
 
+struct of_pci_range_parser {
+	struct device_node *node;
+	const __be32 *range, *end;
+	int np, pna;
+};
+
+struct of_pci_range {
+	u32 pci_space;
+	u64 pci_addr;
+	u64 cpu_addr;
+	u64 size;
+	u32 flags;
+};
+
+#define for_each_of_pci_range(parser, range) \
+	for (; of_pci_process_ranges(parser, range);)
+
+#define of_pci_range_to_resource(range, np, res) \
+	do { \
+		(res)->flags = (range)->flags; \
+		(res)->start = (range)->cpu_addr; \
+		(res)->end = (range)->cpu_addr + (range)->size - 1; \
+		(res)->parent = (res)->child = (res)->sibling = NULL; \
+		(res)->name = (np)->full_name; \
+	} while (0)
+
 #ifdef CONFIG_OF_ADDRESS
 extern u64 of_translate_address(struct device_node *np, const __be32 *addr);
 extern bool of_can_translate_address(struct device_node *dev);
@@ -27,6 +53,10 @@ static inline unsigned long pci_address_to_pio(phys_addr_t addr) { return -1; }
 #define pci_address_to_pio pci_address_to_pio
 #endif
 
+int of_pci_range_parser(struct of_pci_range_parser *parser,
+			struct device_node *node);
+struct of_pci_range *of_pci_process_ranges(struct of_pci_range_parser *parser,
+						struct of_pci_range *range);
 #else /* CONFIG_OF_ADDRESS */
 #ifndef of_address_to_resource
 static inline int of_address_to_resource(struct device_node *dev, int index,
@@ -53,6 +83,18 @@ static inline const __be32 *of_get_address(struct device_node *dev, int index,
 {
 	return NULL;
 }
+
+int of_pci_range_parser(struct of_pci_range_parser *parser,
+			struct device_noed *node)
+{
+	return -1;
+}
+
+struct of_pci_range *of_pci_process_ranges(struct of_pci_range_parser *parser,
+						struct of_pci_range *range)
+{
+	return NULL;
+}
 #endif /* CONFIG_OF_ADDRESS */
 
 
-- 
1.7.0.4



From Andrew.Murray at arm.com  Wed Apr 10 03:29:28 2013
From: Andrew.Murray at arm.com (Andrew Murray)
Date: Wed, 10 Apr 2013 08:29:28 +0100
Subject: [PATCH v5 3/3] of/pci: mips: convert to common of_pci_range_parser
In-Reply-To: <1365578969-30966-1-git-send-email-Andrew.Murray@arm.com>
References: <1365578969-30966-1-git-send-email-Andrew.Murray@arm.com>
Message-ID: <1365578969-30966-4-git-send-email-Andrew.Murray@arm.com>

This patch converts the pci_load_of_ranges function to use the new common
of_pci_range_parser.

Signed-off-by: Andrew Murray <Andrew.Murray at arm.com>
Signed-off-by: Liviu Dudau <Liviu.Dudau at arm.com>
---
 arch/mips/pci/pci.c |   50 ++++++++++++++++----------------------------------
 1 files changed, 16 insertions(+), 34 deletions(-)

diff --git a/arch/mips/pci/pci.c b/arch/mips/pci/pci.c
index 0872f12..bee49a4 100644
--- a/arch/mips/pci/pci.c
+++ b/arch/mips/pci/pci.c
@@ -122,51 +122,33 @@ static void pcibios_scanbus(struct pci_controller *hose)
 #ifdef CONFIG_OF
 void pci_load_of_ranges(struct pci_controller *hose, struct device_node *node)
 {
-	const __be32 *ranges;
-	int rlen;
-	int pna = of_n_addr_cells(node);
-	int np = pna + 5;
+	struct of_pci_range_range range;
+	struct of_pci_range_parser parser;
+	u32 res_type;
 
 	pr_info("PCI host bridge %s ranges:\n", node->full_name);
-	ranges = of_get_property(node, "ranges", &rlen);
-	if (ranges == NULL)
-		return;
 	hose->of_node = node;
 
-	while ((rlen -= np * 4) >= 0) {
-		u32 pci_space;
+	if (of_pci_range_parser(&parser, node))
+		return;
+
+	for_each_of_pci_range(&parser, &range) {
 		struct resource *res = NULL;
-		u64 addr, size;
-
-		pci_space = be32_to_cpup(&ranges[0]);
-		addr = of_translate_address(node, ranges + 3);
-		size = of_read_number(ranges + pna + 3, 2);
-		ranges += np;
-		switch ((pci_space >> 24) & 0x3) {
-		case 1:		/* PCI IO space */
+
+		res_type = range.flags & IORESOURCE_TYPE_BITS;
+		if (res_type == IORESOURCE_IO) {
 			pr_info("  IO 0x%016llx..0x%016llx\n",
-					addr, addr + size - 1);
+				range.addr, range.addr + range.size - 1);
 			hose->io_map_base =
-				(unsigned long)ioremap(addr, size);
+				(unsigned long)ioremap(range.addr, range.size);
 			res = hose->io_resource;
-			res->flags = IORESOURCE_IO;
-			break;
-		case 2:		/* PCI Memory space */
-		case 3:		/* PCI 64 bits Memory space */
+		} else if (res_type == IORESOURCE_MEM) {
 			pr_info(" MEM 0x%016llx..0x%016llx\n",
-					addr, addr + size - 1);
+				range.addr, range.addr + range.size - 1);
 			res = hose->mem_resource;
-			res->flags = IORESOURCE_MEM;
-			break;
-		}
-		if (res != NULL) {
-			res->start = addr;
-			res->name = node->full_name;
-			res->end = res->start + size - 1;
-			res->parent = NULL;
-			res->sibling = NULL;
-			res->child = NULL;
 		}
+		if (res != NULL)
+			of_pci_range_to_resource(&range, node, res);
 	}
 }
 #endif
-- 
1.7.0.4



From Andrew.Murray at arm.com  Wed Apr 10 03:29:26 2013
From: Andrew.Murray at arm.com (Andrew Murray)
Date: Wed, 10 Apr 2013 08:29:26 +0100
Subject: [PATCH v5 1/3] of/pci: Unify pci_process_bridge_OF_ranges from
 Microblaze and PowerPC
In-Reply-To: <1365578969-30966-1-git-send-email-Andrew.Murray@arm.com>
References: <1365578969-30966-1-git-send-email-Andrew.Murray@arm.com>
Message-ID: <1365578969-30966-2-git-send-email-Andrew.Murray@arm.com>

The pci_process_bridge_OF_ranges function, used to parse the "ranges"
property of a PCI host device, is found in both Microblaze and PowerPC
architectures. These implementations are nearly identical. This patch
moves this common code to a common place.

Signed-off-by: Andrew Murray <Andrew.Murray at arm.com>
Signed-off-by: Liviu Dudau <Liviu.Dudau at arm.com>
---
 arch/microblaze/include/asm/pci-bridge.h |    5 +-
 arch/microblaze/pci/pci-common.c         |  192 ----------------------------
 arch/powerpc/include/asm/pci-bridge.h    |    5 +-
 arch/powerpc/kernel/pci-common.c         |  192 ----------------------------
 drivers/of/of_pci.c                      |  200 ++++++++++++++++++++++++++++++
 include/linux/of_pci.h                   |    3 +
 6 files changed, 205 insertions(+), 392 deletions(-)

diff --git a/arch/microblaze/include/asm/pci-bridge.h b/arch/microblaze/include/asm/pci-bridge.h
index cb5d397..5783cd6 100644
--- a/arch/microblaze/include/asm/pci-bridge.h
+++ b/arch/microblaze/include/asm/pci-bridge.h
@@ -10,6 +10,7 @@
 #include <linux/pci.h>
 #include <linux/list.h>
 #include <linux/ioport.h>
+#include <linux/of_pci.h>
 
 struct device_node;
 
@@ -132,10 +133,6 @@ extern void setup_indirect_pci(struct pci_controller *hose,
 extern struct pci_controller *pci_find_hose_for_OF_device(
 			struct device_node *node);
 
-/* Fill up host controller resources from the OF node */
-extern void pci_process_bridge_OF_ranges(struct pci_controller *hose,
-			struct device_node *dev, int primary);
-
 /* Allocate & free a PCI host bridge structure */
 extern struct pci_controller *pcibios_alloc_controller(struct device_node *dev);
 extern void pcibios_free_controller(struct pci_controller *phb);
diff --git a/arch/microblaze/pci/pci-common.c b/arch/microblaze/pci/pci-common.c
index 9ea521e..2735ad9 100644
--- a/arch/microblaze/pci/pci-common.c
+++ b/arch/microblaze/pci/pci-common.c
@@ -622,198 +622,6 @@ void pci_resource_to_user(const struct pci_dev *dev, int bar,
 	*end = rsrc->end - offset;
 }
 
-/**
- * pci_process_bridge_OF_ranges - Parse PCI bridge resources from device tree
- * @hose: newly allocated pci_controller to be setup
- * @dev: device node of the host bridge
- * @primary: set if primary bus (32 bits only, soon to be deprecated)
- *
- * This function will parse the "ranges" property of a PCI host bridge device
- * node and setup the resource mapping of a pci controller based on its
- * content.
- *
- * Life would be boring if it wasn't for a few issues that we have to deal
- * with here:
- *
- *   - We can only cope with one IO space range and up to 3 Memory space
- *     ranges. However, some machines (thanks Apple !) tend to split their
- *     space into lots of small contiguous ranges. So we have to coalesce.
- *
- *   - We can only cope with all memory ranges having the same offset
- *     between CPU addresses and PCI addresses. Unfortunately, some bridges
- *     are setup for a large 1:1 mapping along with a small "window" which
- *     maps PCI address 0 to some arbitrary high address of the CPU space in
- *     order to give access to the ISA memory hole.
- *     The way out of here that I've chosen for now is to always set the
- *     offset based on the first resource found, then override it if we
- *     have a different offset and the previous was set by an ISA hole.
- *
- *   - Some busses have IO space not starting at 0, which causes trouble with
- *     the way we do our IO resource renumbering. The code somewhat deals with
- *     it for 64 bits but I would expect problems on 32 bits.
- *
- *   - Some 32 bits platforms such as 4xx can have physical space larger than
- *     32 bits so we need to use 64 bits values for the parsing
- */
-void pci_process_bridge_OF_ranges(struct pci_controller *hose,
-				  struct device_node *dev, int primary)
-{
-	const u32 *ranges;
-	int rlen;
-	int pna = of_n_addr_cells(dev);
-	int np = pna + 5;
-	int memno = 0, isa_hole = -1;
-	u32 pci_space;
-	unsigned long long pci_addr, cpu_addr, pci_next, cpu_next, size;
-	unsigned long long isa_mb = 0;
-	struct resource *res;
-
-	pr_info("PCI host bridge %s %s ranges:\n",
-	       dev->full_name, primary ? "(primary)" : "");
-
-	/* Get ranges property */
-	ranges = of_get_property(dev, "ranges", &rlen);
-	if (ranges == NULL)
-		return;
-
-	/* Parse it */
-	pr_debug("Parsing ranges property...\n");
-	while ((rlen -= np * 4) >= 0) {
-		/* Read next ranges element */
-		pci_space = ranges[0];
-		pci_addr = of_read_number(ranges + 1, 2);
-		cpu_addr = of_translate_address(dev, ranges + 3);
-		size = of_read_number(ranges + pna + 3, 2);
-
-		pr_debug("pci_space: 0x%08x pci_addr:0x%016llx ",
-				pci_space, pci_addr);
-		pr_debug("cpu_addr:0x%016llx size:0x%016llx\n",
-					cpu_addr, size);
-
-		ranges += np;
-
-		/* If we failed translation or got a zero-sized region
-		 * (some FW try to feed us with non sensical zero sized regions
-		 * such as power3 which look like some kind of attempt
-		 * at exposing the VGA memory hole)
-		 */
-		if (cpu_addr == OF_BAD_ADDR || size == 0)
-			continue;
-
-		/* Now consume following elements while they are contiguous */
-		for (; rlen >= np * sizeof(u32);
-		     ranges += np, rlen -= np * 4) {
-			if (ranges[0] != pci_space)
-				break;
-			pci_next = of_read_number(ranges + 1, 2);
-			cpu_next = of_translate_address(dev, ranges + 3);
-			if (pci_next != pci_addr + size ||
-			    cpu_next != cpu_addr + size)
-				break;
-			size += of_read_number(ranges + pna + 3, 2);
-		}
-
-		/* Act based on address space type */
-		res = NULL;
-		switch ((pci_space >> 24) & 0x3) {
-		case 1:		/* PCI IO space */
-			pr_info("  IO 0x%016llx..0x%016llx -> 0x%016llx\n",
-			       cpu_addr, cpu_addr + size - 1, pci_addr);
-
-			/* We support only one IO range */
-			if (hose->pci_io_size) {
-				pr_info(" \\--> Skipped (too many) !\n");
-				continue;
-			}
-			/* On 32 bits, limit I/O space to 16MB */
-			if (size > 0x01000000)
-				size = 0x01000000;
-
-			/* 32 bits needs to map IOs here */
-			hose->io_base_virt = ioremap(cpu_addr, size);
-
-			/* Expect trouble if pci_addr is not 0 */
-			if (primary)
-				isa_io_base =
-					(unsigned long)hose->io_base_virt;
-			/* pci_io_size and io_base_phys always represent IO
-			 * space starting at 0 so we factor in pci_addr
-			 */
-			hose->pci_io_size = pci_addr + size;
-			hose->io_base_phys = cpu_addr - pci_addr;
-
-			/* Build resource */
-			res = &hose->io_resource;
-			res->flags = IORESOURCE_IO;
-			res->start = pci_addr;
-			break;
-		case 2:		/* PCI Memory space */
-		case 3:		/* PCI 64 bits Memory space */
-			pr_info(" MEM 0x%016llx..0x%016llx -> 0x%016llx %s\n",
-			       cpu_addr, cpu_addr + size - 1, pci_addr,
-			       (pci_space & 0x40000000) ? "Prefetch" : "");
-
-			/* We support only 3 memory ranges */
-			if (memno >= 3) {
-				pr_info(" \\--> Skipped (too many) !\n");
-				continue;
-			}
-			/* Handles ISA memory hole space here */
-			if (pci_addr == 0) {
-				isa_mb = cpu_addr;
-				isa_hole = memno;
-				if (primary || isa_mem_base == 0)
-					isa_mem_base = cpu_addr;
-				hose->isa_mem_phys = cpu_addr;
-				hose->isa_mem_size = size;
-			}
-
-			/* We get the PCI/Mem offset from the first range or
-			 * the, current one if the offset came from an ISA
-			 * hole. If they don't match, bugger.
-			 */
-			if (memno == 0 ||
-			    (isa_hole >= 0 && pci_addr != 0 &&
-			     hose->pci_mem_offset == isa_mb))
-				hose->pci_mem_offset = cpu_addr - pci_addr;
-			else if (pci_addr != 0 &&
-				 hose->pci_mem_offset != cpu_addr - pci_addr) {
-				pr_info(" \\--> Skipped (offset mismatch) !\n");
-				continue;
-			}
-
-			/* Build resource */
-			res = &hose->mem_resources[memno++];
-			res->flags = IORESOURCE_MEM;
-			if (pci_space & 0x40000000)
-				res->flags |= IORESOURCE_PREFETCH;
-			res->start = cpu_addr;
-			break;
-		}
-		if (res != NULL) {
-			res->name = dev->full_name;
-			res->end = res->start + size - 1;
-			res->parent = NULL;
-			res->sibling = NULL;
-			res->child = NULL;
-		}
-	}
-
-	/* If there's an ISA hole and the pci_mem_offset is -not- matching
-	 * the ISA hole offset, then we need to remove the ISA hole from
-	 * the resource list for that brige
-	 */
-	if (isa_hole >= 0 && hose->pci_mem_offset != isa_mb) {
-		unsigned int next = isa_hole + 1;
-		pr_info(" Removing ISA hole at 0x%016llx\n", isa_mb);
-		if (next < memno)
-			memmove(&hose->mem_resources[isa_hole],
-				&hose->mem_resources[next],
-				sizeof(struct resource) * (memno - next));
-		hose->mem_resources[--memno].flags = 0;
-	}
-}
-
 /* Decide whether to display the domain number in /proc */
 int pci_proc_domain(struct pci_bus *bus)
 {
diff --git a/arch/powerpc/include/asm/pci-bridge.h b/arch/powerpc/include/asm/pci-bridge.h
index 025a130..205bfba 100644
--- a/arch/powerpc/include/asm/pci-bridge.h
+++ b/arch/powerpc/include/asm/pci-bridge.h
@@ -10,6 +10,7 @@
 #include <linux/pci.h>
 #include <linux/list.h>
 #include <linux/ioport.h>
+#include <linux/of_pci.h>
 #include <asm-generic/pci-bridge.h>
 
 struct device_node;
@@ -231,10 +232,6 @@ extern int pcibios_map_io_space(struct pci_bus *bus);
 extern struct pci_controller *pci_find_hose_for_OF_device(
 			struct device_node* node);
 
-/* Fill up host controller resources from the OF node */
-extern void pci_process_bridge_OF_ranges(struct pci_controller *hose,
-			struct device_node *dev, int primary);
-
 /* Allocate & free a PCI host bridge structure */
 extern struct pci_controller *pcibios_alloc_controller(struct device_node *dev);
 extern void pcibios_free_controller(struct pci_controller *phb);
diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index fa12ae4..6edf396 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -640,198 +640,6 @@ void pci_resource_to_user(const struct pci_dev *dev, int bar,
 	*end = rsrc->end - offset;
 }
 
-/**
- * pci_process_bridge_OF_ranges - Parse PCI bridge resources from device tree
- * @hose: newly allocated pci_controller to be setup
- * @dev: device node of the host bridge
- * @primary: set if primary bus (32 bits only, soon to be deprecated)
- *
- * This function will parse the "ranges" property of a PCI host bridge device
- * node and setup the resource mapping of a pci controller based on its
- * content.
- *
- * Life would be boring if it wasn't for a few issues that we have to deal
- * with here:
- *
- *   - We can only cope with one IO space range and up to 3 Memory space
- *     ranges. However, some machines (thanks Apple !) tend to split their
- *     space into lots of small contiguous ranges. So we have to coalesce.
- *
- *   - We can only cope with all memory ranges having the same offset
- *     between CPU addresses and PCI addresses. Unfortunately, some bridges
- *     are setup for a large 1:1 mapping along with a small "window" which
- *     maps PCI address 0 to some arbitrary high address of the CPU space in
- *     order to give access to the ISA memory hole.
- *     The way out of here that I've chosen for now is to always set the
- *     offset based on the first resource found, then override it if we
- *     have a different offset and the previous was set by an ISA hole.
- *
- *   - Some busses have IO space not starting at 0, which causes trouble with
- *     the way we do our IO resource renumbering. The code somewhat deals with
- *     it for 64 bits but I would expect problems on 32 bits.
- *
- *   - Some 32 bits platforms such as 4xx can have physical space larger than
- *     32 bits so we need to use 64 bits values for the parsing
- */
-void pci_process_bridge_OF_ranges(struct pci_controller *hose,
-				  struct device_node *dev, int primary)
-{
-	const u32 *ranges;
-	int rlen;
-	int pna = of_n_addr_cells(dev);
-	int np = pna + 5;
-	int memno = 0, isa_hole = -1;
-	u32 pci_space;
-	unsigned long long pci_addr, cpu_addr, pci_next, cpu_next, size;
-	unsigned long long isa_mb = 0;
-	struct resource *res;
-
-	printk(KERN_INFO "PCI host bridge %s %s ranges:\n",
-	       dev->full_name, primary ? "(primary)" : "");
-
-	/* Get ranges property */
-	ranges = of_get_property(dev, "ranges", &rlen);
-	if (ranges == NULL)
-		return;
-
-	/* Parse it */
-	while ((rlen -= np * 4) >= 0) {
-		/* Read next ranges element */
-		pci_space = ranges[0];
-		pci_addr = of_read_number(ranges + 1, 2);
-		cpu_addr = of_translate_address(dev, ranges + 3);
-		size = of_read_number(ranges + pna + 3, 2);
-		ranges += np;
-
-		/* If we failed translation or got a zero-sized region
-		 * (some FW try to feed us with non sensical zero sized regions
-		 * such as power3 which look like some kind of attempt at exposing
-		 * the VGA memory hole)
-		 */
-		if (cpu_addr == OF_BAD_ADDR || size == 0)
-			continue;
-
-		/* Now consume following elements while they are contiguous */
-		for (; rlen >= np * sizeof(u32);
-		     ranges += np, rlen -= np * 4) {
-			if (ranges[0] != pci_space)
-				break;
-			pci_next = of_read_number(ranges + 1, 2);
-			cpu_next = of_translate_address(dev, ranges + 3);
-			if (pci_next != pci_addr + size ||
-			    cpu_next != cpu_addr + size)
-				break;
-			size += of_read_number(ranges + pna + 3, 2);
-		}
-
-		/* Act based on address space type */
-		res = NULL;
-		switch ((pci_space >> 24) & 0x3) {
-		case 1:		/* PCI IO space */
-			printk(KERN_INFO
-			       "  IO 0x%016llx..0x%016llx -> 0x%016llx\n",
-			       cpu_addr, cpu_addr + size - 1, pci_addr);
-
-			/* We support only one IO range */
-			if (hose->pci_io_size) {
-				printk(KERN_INFO
-				       " \\--> Skipped (too many) !\n");
-				continue;
-			}
-#ifdef CONFIG_PPC32
-			/* On 32 bits, limit I/O space to 16MB */
-			if (size > 0x01000000)
-				size = 0x01000000;
-
-			/* 32 bits needs to map IOs here */
-			hose->io_base_virt = ioremap(cpu_addr, size);
-
-			/* Expect trouble if pci_addr is not 0 */
-			if (primary)
-				isa_io_base =
-					(unsigned long)hose->io_base_virt;
-#endif /* CONFIG_PPC32 */
-			/* pci_io_size and io_base_phys always represent IO
-			 * space starting at 0 so we factor in pci_addr
-			 */
-			hose->pci_io_size = pci_addr + size;
-			hose->io_base_phys = cpu_addr - pci_addr;
-
-			/* Build resource */
-			res = &hose->io_resource;
-			res->flags = IORESOURCE_IO;
-			res->start = pci_addr;
-			break;
-		case 2:		/* PCI Memory space */
-		case 3:		/* PCI 64 bits Memory space */
-			printk(KERN_INFO
-			       " MEM 0x%016llx..0x%016llx -> 0x%016llx %s\n",
-			       cpu_addr, cpu_addr + size - 1, pci_addr,
-			       (pci_space & 0x40000000) ? "Prefetch" : "");
-
-			/* We support only 3 memory ranges */
-			if (memno >= 3) {
-				printk(KERN_INFO
-				       " \\--> Skipped (too many) !\n");
-				continue;
-			}
-			/* Handles ISA memory hole space here */
-			if (pci_addr == 0) {
-				isa_mb = cpu_addr;
-				isa_hole = memno;
-				if (primary || isa_mem_base == 0)
-					isa_mem_base = cpu_addr;
-				hose->isa_mem_phys = cpu_addr;
-				hose->isa_mem_size = size;
-			}
-
-			/* We get the PCI/Mem offset from the first range or
-			 * the, current one if the offset came from an ISA
-			 * hole. If they don't match, bugger.
-			 */
-			if (memno == 0 ||
-			    (isa_hole >= 0 && pci_addr != 0 &&
-			     hose->pci_mem_offset == isa_mb))
-				hose->pci_mem_offset = cpu_addr - pci_addr;
-			else if (pci_addr != 0 &&
-				 hose->pci_mem_offset != cpu_addr - pci_addr) {
-				printk(KERN_INFO
-				       " \\--> Skipped (offset mismatch) !\n");
-				continue;
-			}
-
-			/* Build resource */
-			res = &hose->mem_resources[memno++];
-			res->flags = IORESOURCE_MEM;
-			if (pci_space & 0x40000000)
-				res->flags |= IORESOURCE_PREFETCH;
-			res->start = cpu_addr;
-			break;
-		}
-		if (res != NULL) {
-			res->name = dev->full_name;
-			res->end = res->start + size - 1;
-			res->parent = NULL;
-			res->sibling = NULL;
-			res->child = NULL;
-		}
-	}
-
-	/* If there's an ISA hole and the pci_mem_offset is -not- matching
-	 * the ISA hole offset, then we need to remove the ISA hole from
-	 * the resource list for that brige
-	 */
-	if (isa_hole >= 0 && hose->pci_mem_offset != isa_mb) {
-		unsigned int next = isa_hole + 1;
-		printk(KERN_INFO " Removing ISA hole at 0x%016llx\n", isa_mb);
-		if (next < memno)
-			memmove(&hose->mem_resources[isa_hole],
-				&hose->mem_resources[next],
-				sizeof(struct resource) * (memno - next));
-		hose->mem_resources[--memno].flags = 0;
-	}
-}
-
 /* Decide whether to display the domain number in /proc */
 int pci_proc_domain(struct pci_bus *bus)
 {
diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
index 13e37e2..0611248 100644
--- a/drivers/of/of_pci.c
+++ b/drivers/of/of_pci.c
@@ -4,6 +4,10 @@
 #include <linux/of_pci.h>
 #include <asm/prom.h>
 
+#if defined(CONFIG_PPC32) || defined(CONFIG_PPC64) || defined(CONFIG_MICROBLAZE)
+#include <asm/pci-bridge.h>
+#endif
+
 static inline int __of_pci_pci_compare(struct device_node *node,
 				       unsigned int devfn)
 {
@@ -40,3 +44,199 @@ struct device_node *of_pci_find_child_device(struct device_node *parent,
 	return NULL;
 }
 EXPORT_SYMBOL_GPL(of_pci_find_child_device);
+
+/**
+ * pci_process_bridge_OF_ranges - Parse PCI bridge resources from device tree
+ * @hose: newly allocated pci_controller to be setup
+ * @dev: device node of the host bridge
+ * @primary: set if primary bus (32 bits only, soon to be deprecated)
+ *
+ * This function will parse the "ranges" property of a PCI host bridge device
+ * node and setup the resource mapping of a pci controller based on its
+ * content.
+ *
+ * Life would be boring if it wasn't for a few issues that we have to deal
+ * with here:
+ *
+ *   - We can only cope with one IO space range and up to 3 Memory space
+ *     ranges. However, some machines (thanks Apple !) tend to split their
+ *     space into lots of small contiguous ranges. So we have to coalesce.
+ *
+ *   - We can only cope with all memory ranges having the same offset
+ *     between CPU addresses and PCI addresses. Unfortunately, some bridges
+ *     are setup for a large 1:1 mapping along with a small "window" which
+ *     maps PCI address 0 to some arbitrary high address of the CPU space in
+ *     order to give access to the ISA memory hole.
+ *     The way out of here that I've chosen for now is to always set the
+ *     offset based on the first resource found, then override it if we
+ *     have a different offset and the previous was set by an ISA hole.
+ *
+ *   - Some busses have IO space not starting at 0, which causes trouble with
+ *     the way we do our IO resource renumbering. The code somewhat deals with
+ *     it for 64 bits but I would expect problems on 32 bits.
+ *
+ *   - Some 32 bits platforms such as 4xx can have physical space larger than
+ *     32 bits so we need to use 64 bits values for the parsing
+ */
+#if defined(CONFIG_PPC32) || defined(CONFIG_PPC64) || defined(CONFIG_MICROBLAZE)
+void pci_process_bridge_OF_ranges(struct pci_controller *hose,
+				  struct device_node *dev, int primary)
+{
+	const u32 *ranges;
+	int rlen;
+	int pna = of_n_addr_cells(dev);
+	int np = pna + 5;
+	int memno = 0, isa_hole = -1;
+	u32 pci_space;
+	unsigned long long pci_addr, cpu_addr, pci_next, cpu_next, size;
+	unsigned long long isa_mb = 0;
+	struct resource *res;
+
+	pr_info("PCI host bridge %s %s ranges:\n",
+	       dev->full_name, primary ? "(primary)" : "");
+
+	/* Get ranges property */
+	ranges = of_get_property(dev, "ranges", &rlen);
+	if (ranges == NULL)
+		return;
+
+	/* Parse it */
+	pr_debug("Parsing ranges property...\n");
+	while ((rlen -= np * 4) >= 0) {
+		/* Read next ranges element */
+		pci_space = ranges[0];
+		pci_addr = of_read_number(ranges + 1, 2);
+		cpu_addr = of_translate_address(dev, ranges + 3);
+		size = of_read_number(ranges + pna + 3, 2);
+
+		pr_debug("pci_space: 0x%08x pci_addr:0x%016llx ",
+				pci_space, pci_addr);
+		pr_debug("cpu_addr:0x%016llx size:0x%016llx\n",
+					cpu_addr, size);
+
+		ranges += np;
+
+		/* If we failed translation or got a zero-sized region
+		 * (some FW try to feed us with non sensical zero sized regions
+		 * such as power3 which look like some kind of attempt
+		 * at exposing the VGA memory hole)
+		 */
+		if (cpu_addr == OF_BAD_ADDR || size == 0)
+			continue;
+
+		/* Now consume following elements while they are contiguous */
+		for (; rlen >= np * sizeof(u32);
+		     ranges += np, rlen -= np * 4) {
+			if (ranges[0] != pci_space)
+				break;
+			pci_next = of_read_number(ranges + 1, 2);
+			cpu_next = of_translate_address(dev, ranges + 3);
+			if (pci_next != pci_addr + size ||
+			    cpu_next != cpu_addr + size)
+				break;
+			size += of_read_number(ranges + pna + 3, 2);
+		}
+
+		/* Act based on address space type */
+		res = NULL;
+		switch ((pci_space >> 24) & 0x3) {
+		case 1:		/* PCI IO space */
+			pr_info("  IO 0x%016llx..0x%016llx -> 0x%016llx\n",
+			       cpu_addr, cpu_addr + size - 1, pci_addr);
+
+			/* We support only one IO range */
+			if (hose->pci_io_size) {
+				pr_info(" \\--> Skipped (too many) !\n");
+				continue;
+			}
+#if defined(CONFIG_PPC32) || defined(CONFIG_MICROBLAZE)
+			/* On 32 bits, limit I/O space to 16MB */
+			if (size > 0x01000000)
+				size = 0x01000000;
+
+			/* 32 bits needs to map IOs here */
+			hose->io_base_virt = ioremap(cpu_addr, size);
+
+			/* Expect trouble if pci_addr is not 0 */
+			if (primary)
+				isa_io_base =
+					(unsigned long)hose->io_base_virt;
+#endif /* CONFIG_PPC32 || CONFIG_MICROBLAZE */
+			/* pci_io_size and io_base_phys always represent IO
+			 * space starting at 0 so we factor in pci_addr
+			 */
+			hose->pci_io_size = pci_addr + size;
+			hose->io_base_phys = cpu_addr - pci_addr;
+
+			/* Build resource */
+			res = &hose->io_resource;
+			res->flags = IORESOURCE_IO;
+			res->start = pci_addr;
+			break;
+		case 2:		/* PCI Memory space */
+		case 3:		/* PCI 64 bits Memory space */
+			pr_info(" MEM 0x%016llx..0x%016llx -> 0x%016llx %s\n",
+			       cpu_addr, cpu_addr + size - 1, pci_addr,
+			       (pci_space & 0x40000000) ? "Prefetch" : "");
+
+			/* We support only 3 memory ranges */
+			if (memno >= 3) {
+				pr_info(" \\--> Skipped (too many) !\n");
+				continue;
+			}
+			/* Handles ISA memory hole space here */
+			if (pci_addr == 0) {
+				isa_mb = cpu_addr;
+				isa_hole = memno;
+				if (primary || isa_mem_base == 0)
+					isa_mem_base = cpu_addr;
+				hose->isa_mem_phys = cpu_addr;
+				hose->isa_mem_size = size;
+			}
+
+			/* We get the PCI/Mem offset from the first range or
+			 * the, current one if the offset came from an ISA
+			 * hole. If they don't match, bugger.
+			 */
+			if (memno == 0 ||
+			    (isa_hole >= 0 && pci_addr != 0 &&
+			     hose->pci_mem_offset == isa_mb))
+				hose->pci_mem_offset = cpu_addr - pci_addr;
+			else if (pci_addr != 0 &&
+				 hose->pci_mem_offset != cpu_addr - pci_addr) {
+				pr_info(" \\--> Skipped (offset mismatch) !\n");
+				continue;
+			}
+
+			/* Build resource */
+			res = &hose->mem_resources[memno++];
+			res->flags = IORESOURCE_MEM;
+			if (pci_space & 0x40000000)
+				res->flags |= IORESOURCE_PREFETCH;
+			res->start = cpu_addr;
+			break;
+		}
+		if (res != NULL) {
+			res->name = dev->full_name;
+			res->end = res->start + size - 1;
+			res->parent = NULL;
+			res->sibling = NULL;
+			res->child = NULL;
+		}
+	}
+
+	/* If there's an ISA hole and the pci_mem_offset is -not- matching
+	 * the ISA hole offset, then we need to remove the ISA hole from
+	 * the resource list for that brige
+	 */
+	if (isa_hole >= 0 && hose->pci_mem_offset != isa_mb) {
+		unsigned int next = isa_hole + 1;
+		pr_info(" Removing ISA hole at 0x%016llx\n", isa_mb);
+		if (next < memno)
+			memmove(&hose->mem_resources[isa_hole],
+				&hose->mem_resources[next],
+				sizeof(struct resource) * (memno - next));
+		hose->mem_resources[--memno].flags = 0;
+	}
+}
+#endif
diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
index bb115de..6852481 100644
--- a/include/linux/of_pci.h
+++ b/include/linux/of_pci.h
@@ -11,4 +11,7 @@ struct device_node;
 struct device_node *of_pci_find_child_device(struct device_node *parent,
 					     unsigned int devfn);
 
+void pci_process_bridge_OF_ranges(struct pci_controller *hose,
+			struct device_node *dev, int primary);
+
 #endif
-- 
1.7.0.4



From sfr at canb.auug.org.au  Wed Apr 10 03:33:01 2013
From: sfr at canb.auug.org.au (Stephen Rothwell)
Date: Wed, 10 Apr 2013 17:33:01 +1000
Subject: linux-next: manual merge of the imx-mxs tree with the arm-soc tree
Message-ID: <20130410173301.a9fb60beb9ca0865c93930f0@canb.auug.org.au>

Hi Shawn,

Today's linux-next merge of the imx-mxs tree got a conflict in
arch/arm/mach-imx/clk-imx6q.c between commit e8094b2c1712 ("ARM i.MX6:
Fix ldb_di clock selection") from the arm-soc tree and commit
8034cf45ac38 ("ARM i.MX6q: Add audio/video PLL post dividers for i.MX6q
rev 1.1") from the imx-mxs tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr at canb.auug.org.au

diff --cc arch/arm/mach-imx/clk-imx6q.c
index d38e54f,65319d5..0000000
--- a/arch/arm/mach-imx/clk-imx6q.c
+++ b/arch/arm/mach-imx/clk-imx6q.c
@@@ -115,8 -187,8 +187,8 @@@ static const char *gpu2d_core_sels[]	= 
  static const char *gpu3d_core_sels[]	= { "mmdc_ch0_axi", "pll3_usb_otg", "pll2_pfd1_594m", "pll2_pfd2_396m", };
  static const char *gpu3d_shader_sels[] = { "mmdc_ch0_axi", "pll3_usb_otg", "pll2_pfd1_594m", "pll2_pfd9_720m", };
  static const char *ipu_sels[]		= { "mmdc_ch0_axi", "pll2_pfd2_396m", "pll3_120m", "pll3_pfd1_540m", };
- static const char *ldb_di_sels[]	= { "pll5_video", "pll2_pfd0_352m", "pll2_pfd2_396m", "mmdc_ch1_axi", "pll3_usb_otg", };
- static const char *ipu_di_pre_sels[]	= { "mmdc_ch0_axi", "pll3_usb_otg", "pll5_video", "pll2_pfd0_352m", "pll2_pfd2_396m", "pll3_pfd1_540m", };
 -static const char *ldb_di_sels[]	= { "pll5_video_div", "pll2_pfd0_352m", "pll2_pfd2_396m", "mmdc_ch1_axi", "pll3_pfd1_540m", };
++static const char *ldb_di_sels[]	= { "pll5_video_div", "pll2_pfd0_352m", "pll2_pfd2_396m", "mmdc_ch1_axi", "pll3_usb_otg", };
+ static const char *ipu_di_pre_sels[]	= { "mmdc_ch0_axi", "pll3_usb_otg", "pll5_video_div", "pll2_pfd0_352m", "pll2_pfd2_396m", "pll3_pfd1_540m", };
  static const char *ipu1_di0_sels[]	= { "ipu1_di0_pre", "dummy", "dummy", "ldb_di0", "ldb_di1", };
  static const char *ipu1_di1_sels[]	= { "ipu1_di1_pre", "dummy", "dummy", "ldb_di0", "ldb_di1", };
  static const char *ipu2_di0_sels[]	= { "ipu2_di0_pre", "dummy", "dummy", "ldb_di0", "ldb_di1", };
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130410/c275be55/attachment.sig>

From mmarek at suse.cz  Wed Apr 10 03:56:27 2013
From: mmarek at suse.cz (Michal Marek)
Date: Wed, 10 Apr 2013 09:56:27 +0200
Subject: [PATCH] kbuild: generate generic headers before recursing into
 scripts
In-Reply-To: <m2k3ob1tar.fsf_-_@igel.home>
References: <CA+V-a8vYsBLVH-3Bm35Sv9K9ZMTcMB4_P_V3kBjyuEKDozPi5w@mail.gmail.com>
 <1363949290.3528.37.camel@linaro1.home> <m2ip48d62f.fsf@igel.home>
 <CA+V-a8srtwdf1H2JQwbkyMFhXopPEA90RM8Hy+UunM6Mm7-d1w@mail.gmail.com>
 <m2k3ob1tar.fsf_-_@igel.home>
Message-ID: <51651B2B.90206@suse.cz>

On 9.4.2013 19:57, Andreas Schwab wrote:
> The headers are now needed inside scripts/mod since 6543bec
> ("mod/file2alias: make modalias generation safe for cross compiling").
> 
> Signed-off-by: Andreas Schwab <schwab at linux-m68k.org>
> ---
> Prabhakar Lad <prabhakar.csengg at gmail.com> writes:
> 
>> Whats the status of it ?
> 
> I think it has sufficiently been tested by now.

Thanks a lot, I added it to kbuild.git#rc-fixes.

Michal



From avinashphilip at ti.com  Wed Apr 10 04:02:19 2013
From: avinashphilip at ti.com (Philip Avinash)
Date: Wed, 10 Apr 2013 13:32:19 +0530
Subject: [PATCH v4] ARM: davinci: da850: add EHRPWM & ECAP DT node
Message-ID: <1365580939-16839-1-git-send-email-avinashphilip@ti.com>

Add da850 EHRPWM & ECAP DT node along with pin-mux details for EHRPWM1.
Also adds OF_DEV_AUXDATA for EHRPWM & ECAP driver to use EHRPWM & ECAP
clock.

Signed-off-by: Philip Avinash <avinashphilip at ti.com>
---
Changes since v3:
	- add pin mux info for EHRPWM1.

Changes since v1:
	- Reusing ti,am33xx<ecap/ehrpwm> as compatible field as both IP's are
	  similar with am33xx platform and da850 has no platform specific
	  dependency.

 arch/arm/boot/dts/da850.dtsi     |   42 ++++++++++++++++++++++++++++++++++++++
 arch/arm/mach-davinci/da8xx-dt.c |    5 +++++
 2 files changed, 47 insertions(+)

diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 3ade343..3bff30d 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -71,6 +71,18 @@
 					0x28 0x00222222  0x00ffffff
 				>;
 			};
+			ehrpwm1a_pins: pinmux_ehrpwm1a_pins {
+				pinctrl-single,bits = <
+					/* EPWM1A */
+					0x14 0x00000002 0x0000000f
+				>;
+			};
+			ehrpwm1b_pins: pinmux_ehrpwm1b_pins {
+				pinctrl-single,bits = <
+					/* EPWM1B */
+					0x14 0x00000020 0x000000f0
+				>;
+			};
 		};
 		serial0: serial at 1c42000 {
 			compatible = "ns16550a";
@@ -122,6 +134,36 @@
 			interrupts = <16>;
 			status = "disabled";
 		};
+		ehrpwm0: ehrpwm at 01f00000 {
+			compatible = "ti,da850-ehrpwm", "ti,am33xx-ehrpwm";
+			#pwm-cells = <3>;
+			reg = <0x300000 0x2000>;
+			status = "disabled";
+		};
+		ehrpwm1: ehrpwm at 01f02000 {
+			compatible = "ti,da850-ehrpwm", "ti,am33xx-ehrpwm";
+			#pwm-cells = <3>;
+			reg = <0x302000 0x2000>;
+			status = "disabled";
+		};
+		ecap0: ecap at 01f06000 {
+			compatible = "ti,da850-ecap", "ti,am33xx-ecap";
+			#pwm-cells = <3>;
+			reg = <0x306000 0x80>;
+			status = "disabled";
+		};
+		ecap1: ecap at 01f07000 {
+			compatible = "ti,da850-ecap", "ti,am33xx-ecap";
+			#pwm-cells = <3>;
+			reg = <0x307000 0x80>;
+			status = "disabled";
+		};
+		ecap2: ecap at 01f08000 {
+			compatible = "ti,da850-ecap", "ti,am33xx-ecap";
+			#pwm-cells = <3>;
+			reg = <0x308000 0x80>;
+			status = "disabled";
+		};
 	};
 	nand_cs3 at 62000000 {
 		compatible = "ti,davinci-nand";
diff --git a/arch/arm/mach-davinci/da8xx-dt.c b/arch/arm/mach-davinci/da8xx-dt.c
index d83de8f..05bb9a2 100644
--- a/arch/arm/mach-davinci/da8xx-dt.c
+++ b/arch/arm/mach-davinci/da8xx-dt.c
@@ -41,6 +41,11 @@ struct of_dev_auxdata da850_auxdata_lookup[] __initdata = {
 	OF_DEV_AUXDATA("ti,davinci-i2c", 0x01c22000, "i2c_davinci.1", NULL),
 	OF_DEV_AUXDATA("ti,davinci-wdt", 0x01c21000, "watchdog", NULL),
 	OF_DEV_AUXDATA("ti,da830-mmc", 0x01c40000, "da830-mmc.0", NULL),
+	OF_DEV_AUXDATA("ti,da850-ehrpwm", 0x01f00000, "ehrpwm", NULL),
+	OF_DEV_AUXDATA("ti,da850-ehrpwm", 0x01f02000, "ehrpwm", NULL),
+	OF_DEV_AUXDATA("ti,da850-ecap", 0x01f06000, "ecap", NULL),
+	OF_DEV_AUXDATA("ti,da850-ecap", 0x01f07000, "ecap", NULL),
+	OF_DEV_AUXDATA("ti,da850-ecap", 0x01f08000, "ecap", NULL),
 	{}
 };
 
-- 
1.7.9.5



From ulf.hansson at linaro.org  Wed Apr 10 04:02:53 2013
From: ulf.hansson at linaro.org (Ulf Hansson)
Date: Wed, 10 Apr 2013 10:02:53 +0200
Subject: [PATCH V3 1/3] clk: ux500: Add support for sysctrl clocks
In-Reply-To: <20130409011433.14359.14140@quantum>
References: <1364992017-12683-1-git-send-email-ulf.hansson@stericsson.com>
 <20130409011433.14359.14140@quantum>
Message-ID: <CAPDyKFqM+638Q2FRFHu7pLw+MQSvT0yZp7v6dQeYN9gRY4c+aA@mail.gmail.com>

On 9 April 2013 03:14, Mike Turquette <mturquette at linaro.org> wrote:
> Quoting Ulf Hansson (2013-04-03 05:26:57)
>> From: Ulf Hansson <ulf.hansson at linaro.org>
>>
>> The abx500 sysctrl clocks are using the ab8500 sysctrl driver to
>> modify the clock hardware. Sysctrl clocks are represented by a
>> ab8500 sysctrl register and with a corresponding bitmask.
>>
>> The sysctrl clocks are slow path clocks, which means clk_prepare
>> and clk_unprepare will be used to gate|ungate these clocks.
>>
>> Signed-off-by: Ulf Hansson <ulf.hansson at linaro.org>
>
> Hi Ulf,
>
> Is there a V3 update for patches #2 & #3?  I can't seem to find them.

Hi Mike,

Only v3 exist for this patch. Sorry if it was a bit unclear.

Kind regards
Uffe

>
> Regards,
> Mike
>
>> ---
>>
>> Changes in v3:
>>         - Fixed error check at clk registration.
>> Changes in v2:
>>         - Removed wrong header file.
>> ---
>>  drivers/clk/ux500/Makefile      |    1 +
>>  drivers/clk/ux500/clk-sysctrl.c |  221 +++++++++++++++++++++++++++++++++++++++
>>  drivers/clk/ux500/clk.h         |   29 +++++
>>  3 files changed, 251 insertions(+)
>>  create mode 100644 drivers/clk/ux500/clk-sysctrl.c
>>
>> diff --git a/drivers/clk/ux500/Makefile b/drivers/clk/ux500/Makefile
>> index bcc0c11..c6a806e 100644
>> --- a/drivers/clk/ux500/Makefile
>> +++ b/drivers/clk/ux500/Makefile
>> @@ -5,6 +5,7 @@
>>  # Clock types
>>  obj-y += clk-prcc.o
>>  obj-y += clk-prcmu.o
>> +obj-y += clk-sysctrl.o
>>
>>  # Clock definitions
>>  obj-y += u8500_clk.o
>> diff --git a/drivers/clk/ux500/clk-sysctrl.c b/drivers/clk/ux500/clk-sysctrl.c
>> new file mode 100644
>> index 0000000..bc7e9bd
>> --- /dev/null
>> +++ b/drivers/clk/ux500/clk-sysctrl.c
>> @@ -0,0 +1,221 @@
>> +/*
>> + * Sysctrl clock implementation for ux500 platform.
>> + *
>> + * Copyright (C) 2013 ST-Ericsson SA
>> + * Author: Ulf Hansson <ulf.hansson at linaro.org>
>> + *
>> + * License terms: GNU General Public License (GPL) version 2
>> + */
>> +
>> +#include <linux/clk-provider.h>
>> +#include <linux/mfd/abx500/ab8500-sysctrl.h>
>> +#include <linux/device.h>
>> +#include <linux/slab.h>
>> +#include <linux/delay.h>
>> +#include <linux/io.h>
>> +#include <linux/err.h>
>> +#include "clk.h"
>> +
>> +#define SYSCTRL_MAX_NUM_PARENTS 4
>> +
>> +#define to_clk_sysctrl(_hw) container_of(_hw, struct clk_sysctrl, hw)
>> +
>> +struct clk_sysctrl {
>> +       struct clk_hw hw;
>> +       struct device *dev;
>> +       u8 parent_index;
>> +       u16 reg_sel[SYSCTRL_MAX_NUM_PARENTS];
>> +       u8 reg_mask[SYSCTRL_MAX_NUM_PARENTS];
>> +       u8 reg_bits[SYSCTRL_MAX_NUM_PARENTS];
>> +       unsigned long rate;
>> +       unsigned long enable_delay_us;
>> +};
>> +
>> +/* Sysctrl clock operations. */
>> +
>> +static int clk_sysctrl_prepare(struct clk_hw *hw)
>> +{
>> +       int ret;
>> +       struct clk_sysctrl *clk = to_clk_sysctrl(hw);
>> +
>> +       ret = ab8500_sysctrl_write(clk->reg_sel[0], clk->reg_mask[0],
>> +                               clk->reg_bits[0]);
>> +
>> +       if (!ret && clk->enable_delay_us)
>> +               usleep_range(clk->enable_delay_us, clk->enable_delay_us);
>> +
>> +       return ret;
>> +}
>> +
>> +static void clk_sysctrl_unprepare(struct clk_hw *hw)
>> +{
>> +       struct clk_sysctrl *clk = to_clk_sysctrl(hw);
>> +       if (ab8500_sysctrl_clear(clk->reg_sel[0], clk->reg_mask[0]))
>> +               dev_err(clk->dev, "clk_sysctrl: %s fail to clear %s.\n",
>> +                       __func__, __clk_get_name(hw->clk));
>> +}
>> +
>> +static unsigned long clk_sysctrl_recalc_rate(struct clk_hw *hw,
>> +                                       unsigned long parent_rate)
>> +{
>> +       struct clk_sysctrl *clk = to_clk_sysctrl(hw);
>> +       return clk->rate;
>> +}
>> +
>> +static int clk_sysctrl_set_parent(struct clk_hw *hw, u8 index)
>> +{
>> +       struct clk_sysctrl *clk = to_clk_sysctrl(hw);
>> +       u8 old_index = clk->parent_index;
>> +       int ret = 0;
>> +
>> +       if (clk->reg_sel[old_index]) {
>> +               ret = ab8500_sysctrl_clear(clk->reg_sel[old_index],
>> +                                       clk->reg_mask[old_index]);
>> +               if (ret)
>> +                       return ret;
>> +       }
>> +
>> +       if (clk->reg_sel[index]) {
>> +               ret = ab8500_sysctrl_write(clk->reg_sel[index],
>> +                                       clk->reg_mask[index],
>> +                                       clk->reg_bits[index]);
>> +               if (ret) {
>> +                       if (clk->reg_sel[old_index])
>> +                               ab8500_sysctrl_write(clk->reg_sel[old_index],
>> +                                               clk->reg_mask[old_index],
>> +                                               clk->reg_bits[old_index]);
>> +                       return ret;
>> +               }
>> +       }
>> +       clk->parent_index = index;
>> +
>> +       return ret;
>> +}
>> +
>> +static u8 clk_sysctrl_get_parent(struct clk_hw *hw)
>> +{
>> +       struct clk_sysctrl *clk = to_clk_sysctrl(hw);
>> +       return clk->parent_index;
>> +}
>> +
>> +static struct clk_ops clk_sysctrl_gate_ops = {
>> +       .prepare = clk_sysctrl_prepare,
>> +       .unprepare = clk_sysctrl_unprepare,
>> +};
>> +
>> +static struct clk_ops clk_sysctrl_gate_fixed_rate_ops = {
>> +       .prepare = clk_sysctrl_prepare,
>> +       .unprepare = clk_sysctrl_unprepare,
>> +       .recalc_rate = clk_sysctrl_recalc_rate,
>> +};
>> +
>> +static struct clk_ops clk_sysctrl_set_parent_ops = {
>> +       .set_parent = clk_sysctrl_set_parent,
>> +       .get_parent = clk_sysctrl_get_parent,
>> +};
>> +
>> +static struct clk *clk_reg_sysctrl(struct device *dev,
>> +                               const char *name,
>> +                               const char **parent_names,
>> +                               u8 num_parents,
>> +                               u16 *reg_sel,
>> +                               u8 *reg_mask,
>> +                               u8 *reg_bits,
>> +                               unsigned long rate,
>> +                               unsigned long enable_delay_us,
>> +                               unsigned long flags,
>> +                               struct clk_ops *clk_sysctrl_ops)
>> +{
>> +       struct clk_sysctrl *clk;
>> +       struct clk_init_data clk_sysctrl_init;
>> +       struct clk *clk_reg;
>> +       int i;
>> +
>> +       if (!dev)
>> +               return ERR_PTR(-EINVAL);
>> +
>> +       if (!name || (num_parents > SYSCTRL_MAX_NUM_PARENTS)) {
>> +               dev_err(dev, "clk_sysctrl: invalid arguments passed\n");
>> +               return ERR_PTR(-EINVAL);
>> +       }
>> +
>> +       clk = devm_kzalloc(dev, sizeof(struct clk_sysctrl), GFP_KERNEL);
>> +       if (!clk) {
>> +               dev_err(dev, "clk_sysctrl: could not allocate clk\n");
>> +               return ERR_PTR(-ENOMEM);
>> +       }
>> +
>> +       for (i = 0; i < num_parents; i++) {
>> +               clk->reg_sel[i] = reg_sel[i];
>> +               clk->reg_bits[i] = reg_bits[i];
>> +               clk->reg_mask[i] = reg_mask[i];
>> +       }
>> +
>> +       clk->parent_index = 0;
>> +       clk->rate = rate;
>> +       clk->enable_delay_us = enable_delay_us;
>> +       clk->dev = dev;
>> +
>> +       clk_sysctrl_init.name = name;
>> +       clk_sysctrl_init.ops = clk_sysctrl_ops;
>> +       clk_sysctrl_init.flags = flags;
>> +       clk_sysctrl_init.parent_names = parent_names;
>> +       clk_sysctrl_init.num_parents = num_parents;
>> +       clk->hw.init = &clk_sysctrl_init;
>> +
>> +       clk_reg = devm_clk_register(clk->dev, &clk->hw);
>> +       if (IS_ERR(clk_reg))
>> +               dev_err(dev, "clk_sysctrl: clk_register failed\n");
>> +
>> +       return clk_reg;
>> +}
>> +
>> +struct clk *clk_reg_sysctrl_gate(struct device *dev,
>> +                               const char *name,
>> +                               const char *parent_name,
>> +                               u16 reg_sel,
>> +                               u8 reg_mask,
>> +                               u8 reg_bits,
>> +                               unsigned long enable_delay_us,
>> +                               unsigned long flags)
>> +{
>> +       const char **parent_names = (parent_name ? &parent_name : NULL);
>> +       u8 num_parents = (parent_name ? 1 : 0);
>> +
>> +       return clk_reg_sysctrl(dev, name, parent_names, num_parents,
>> +                       &reg_sel, &reg_mask, &reg_bits, 0, enable_delay_us,
>> +                       flags, &clk_sysctrl_gate_ops);
>> +}
>> +
>> +struct clk *clk_reg_sysctrl_gate_fixed_rate(struct device *dev,
>> +                                       const char *name,
>> +                                       const char *parent_name,
>> +                                       u16 reg_sel,
>> +                                       u8 reg_mask,
>> +                                       u8 reg_bits,
>> +                                       unsigned long rate,
>> +                                       unsigned long enable_delay_us,
>> +                                       unsigned long flags)
>> +{
>> +       const char **parent_names = (parent_name ? &parent_name : NULL);
>> +       u8 num_parents = (parent_name ? 1 : 0);
>> +
>> +       return clk_reg_sysctrl(dev, name, parent_names, num_parents,
>> +                       &reg_sel, &reg_mask, &reg_bits,
>> +                       rate, enable_delay_us, flags,
>> +                       &clk_sysctrl_gate_fixed_rate_ops);
>> +}
>> +
>> +struct clk *clk_reg_sysctrl_set_parent(struct device *dev,
>> +                               const char *name,
>> +                               const char **parent_names,
>> +                               u8 num_parents,
>> +                               u16 *reg_sel,
>> +                               u8 *reg_mask,
>> +                               u8 *reg_bits,
>> +                               unsigned long flags)
>> +{
>> +       return clk_reg_sysctrl(dev, name, parent_names, num_parents,
>> +                       reg_sel, reg_mask, reg_bits, 0, 0, flags,
>> +                       &clk_sysctrl_set_parent_ops);
>> +}
>> diff --git a/drivers/clk/ux500/clk.h b/drivers/clk/ux500/clk.h
>> index c3e4491..3d2dfdc 100644
>> --- a/drivers/clk/ux500/clk.h
>> +++ b/drivers/clk/ux500/clk.h
>> @@ -11,6 +11,7 @@
>>  #define __UX500_CLK_H
>>
>>  #include <linux/clk.h>
>> +#include <linux/device.h>
>>
>>  struct clk *clk_reg_prcc_pclk(const char *name,
>>                               const char *parent_name,
>> @@ -57,4 +58,32 @@ struct clk *clk_reg_prcmu_opp_volt_scalable(const char *name,
>>                                             unsigned long rate,
>>                                             unsigned long flags);
>>
>> +struct clk *clk_reg_sysctrl_gate(struct device *dev,
>> +                                const char *name,
>> +                                const char *parent_name,
>> +                                u16 reg_sel,
>> +                                u8 reg_mask,
>> +                                u8 reg_bits,
>> +                                unsigned long enable_delay_us,
>> +                                unsigned long flags);
>> +
>> +struct clk *clk_reg_sysctrl_gate_fixed_rate(struct device *dev,
>> +                                           const char *name,
>> +                                           const char *parent_name,
>> +                                           u16 reg_sel,
>> +                                           u8 reg_mask,
>> +                                           u8 reg_bits,
>> +                                           unsigned long rate,
>> +                                           unsigned long enable_delay_us,
>> +                                           unsigned long flags);
>> +
>> +struct clk *clk_reg_sysctrl_set_parent(struct device *dev,
>> +                                      const char *name,
>> +                                      const char **parent_names,
>> +                                      u8 num_parents,
>> +                                      u16 *reg_sel,
>> +                                      u8 *reg_mask,
>> +                                      u8 *reg_bits,
>> +                                      unsigned long flags);
>> +
>>  #endif /* __UX500_CLK_H */
>> --
>> 1.7.10


From mturquette at linaro.org  Wed Apr 10 04:06:30 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Wed, 10 Apr 2013 01:06:30 -0700
Subject: [RFC][PATCH 1/2] ARM: OMAP4: clock: Add device tree support for
 AUXCLKs
In-Reply-To: <20130409204900.GA8815@kahuna>
References: <1363703220-4777-1-git-send-email-rogerq@ti.com>
 <20130403234242.GE10155@atomide.com> <515D2D30.3000306@ti.com>
 <20130404164137.GH10155@atomide.com> <515EA9E3.1010409@ti.com>
 <20130405155851.GA10155@atomide.com> <5163E589.1040809@ti.com>
 <20130409164928.GL10155@atomide.com> <20130409174319.GP10155@atomide.com>
 <20130409204900.GA8815@kahuna>
Message-ID: <20130410080630.14359.68178@quantum>

Quoting Nishanth Menon (2013-04-09 13:49:00)
> On 10:43-20130409, Tony Lindgren wrote:
> > * Tony Lindgren <tony at atomide.com> [130409 09:54]:
> > > * Roger Quadros <rogerq at ti.com> [130409 03:00]:
> > > > On 04/05/2013 06:58 PM, Tony Lindgren wrote:
> > > > > 
> > > > > Can't you just use the clock name there to get it?
> > > > 
> > > > In device tree we don't pass around clock names. You can either get
> > > > a phandle or an index to the clock.
> > > > 
> > > > e.g. Documentation/devicetree/bindings/clock/imx31-clock.txt
> > > 
> > > Yes I understand that. But the driver/clock/omap driver can just
> > > remap the DT device initially so the board specific clock is
> > > found from the clock alias table. Basically initially a passthrough
> > > driver that can be enhanced to parse DT clock bindings and load
> > > data from /lib/firmware.
> > 
> > Actually probably the driver/clock/omap can even do even less
> > initially. There probably even no need to remap clocks there.
> > 
> > As long as the DT clock driver understands that a board specific
> > auxclk is specified in the DT it can just call clk_add_alias() so
> > the driver will get the right auxclk from cclock44xx_data.c.
> > 
> > Then other features can be added later on like to allocate a
> > clock entirely based on the binding etc.
> I did try to have an implementation for cpufreq using clock nodes.
> unfortunately, device tree wont let me have arguments of strings :(
> So, I am unable to do clock = <&clk mpu_dpll>;
> instead, I am forced to do clock = <&clk 249>;
> 

See http://article.gmane.org/gmane.linux.ports.arm.kernel/229034

Regards,
Mike

> Here is an attempt on beagleXM - adds every clock node to the list.
> Tons of un-necessary prints added to give an idea - see log:
> http://pastebin.com/F9A2zSTr
> 
> Would an cleaned up version be good enough as a step #1 of transition?
> 
> From 7d373bdb9e9549c1b6ba1775a8dfd96ebe78abfb Mon Sep 17 00:00:00 2001
> From: Nishanth Menon <nm at ti.com>
> Date: Tue, 26 Mar 2013 10:23:27 +0000
> Subject: [PATCH] OMAP: add devicetree support for clock nodes.
> 
> Dummy patch based on Roger's original idea
> 
> Nyet-Signed-off-by: Nishanth Menon <nm at ti.com>
> ---
>  arch/arm/boot/dts/omap3.dtsi          |    5 ++
>  arch/arm/boot/dts/omap34xx.dtsi       |    2 +
>  arch/arm/mach-omap2/cclock3xxx_data.c |    3 +-
>  arch/arm/mach-omap2/cclock44xx_data.c |    3 +-
>  arch/arm/mach-omap2/pm.c              |   11 +++-
>  drivers/clk/Kconfig                   |    6 ++
>  drivers/clk/Makefile                  |    2 +
>  drivers/clk/ti.c                      |  100 +++++++++++++++++++++++++++++++++
>  include/linux/clk/ti.h                |   30 ++++++++++
>  9 files changed, 157 insertions(+), 5 deletions(-)
>  create mode 100644 drivers/clk/ti.c
>  create mode 100644 include/linux/clk/ti.h
> 
> diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
> index 3344f05..a08990d 100644
> --- a/arch/arm/boot/dts/omap3.dtsi
> +++ b/arch/arm/boot/dts/omap3.dtsi
> @@ -73,6 +73,11 @@
>                         ti,hwmods = "counter_32k";
>                 };
>  
> +               clks: clocks {
> +                       compatible = "ti,clock";
> +                       #clock-cells = <1>;
> +               };
> +
>                 intc: interrupt-controller at 48200000 {
>                         compatible = "ti,omap2-intc";
>                         interrupt-controller;
> diff --git a/arch/arm/boot/dts/omap34xx.dtsi b/arch/arm/boot/dts/omap34xx.dtsi
> index 75ed4ae..93c2621 100644
> --- a/arch/arm/boot/dts/omap34xx.dtsi
> +++ b/arch/arm/boot/dts/omap34xx.dtsi
> @@ -23,6 +23,8 @@
>                                 600000  1350000
>                         >;
>                         clock-latency = <300000>; /* From legacy driver */
> +                       clocks = <&clks 249>; /* index to cpufreq_ck */
> +                       clock-names = "cpu";
>                 };
>         };
>  };
> diff --git a/arch/arm/mach-omap2/cclock3xxx_data.c b/arch/arm/mach-omap2/cclock3xxx_data.c
> index 4579c3c..d5d5ef5 100644
> --- a/arch/arm/mach-omap2/cclock3xxx_data.c
> +++ b/arch/arm/mach-omap2/cclock3xxx_data.c
> @@ -22,6 +22,7 @@
>  #include <linux/clk-private.h>
>  #include <linux/list.h>
>  #include <linux/io.h>
> +#include <linux/clk/ti.h>
>  
>  #include "soc.h"
>  #include "iomap.h"
> @@ -3574,7 +3575,7 @@ int __init omap3xxx_clk_init(void)
>         for (c = omap3xxx_clks; c < omap3xxx_clks + ARRAY_SIZE(omap3xxx_clks);
>              c++)
>                 if (c->cpu & cpu_clkflg) {
> -                       clkdev_add(&c->lk);
> +                       ti_clk_node_add(&c->lk);
>                         if (!__clk_init(NULL, c->lk.clk))
>                                 omap2_init_clk_hw_omap_clocks(c->lk.clk);
>                 }
> diff --git a/arch/arm/mach-omap2/cclock44xx_data.c b/arch/arm/mach-omap2/cclock44xx_data.c
> index 0c6834a..338ef64 100644
> --- a/arch/arm/mach-omap2/cclock44xx_data.c
> +++ b/arch/arm/mach-omap2/cclock44xx_data.c
> @@ -27,6 +27,7 @@
>  #include <linux/clk-private.h>
>  #include <linux/clkdev.h>
>  #include <linux/io.h>
> +#include <linux/clk/ti.h>
>  
>  #include "soc.h"
>  #include "iomap.h"
> @@ -1697,7 +1698,7 @@ int __init omap4xxx_clk_init(void)
>         for (c = omap44xx_clks; c < omap44xx_clks + ARRAY_SIZE(omap44xx_clks);
>                                                                         c++) {
>                 if (c->cpu & cpu_clkflg) {
> -                       clkdev_add(&c->lk);
> +                       ti_clk_node_add(&c->lk);
>                         if (!__clk_init(NULL, c->lk.clk))
>                                 omap2_init_clk_hw_omap_clocks(c->lk.clk);
>                 }
> diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
> index 8d15f9a..6cf95160 100644
> --- a/arch/arm/mach-omap2/pm.c
> +++ b/arch/arm/mach-omap2/pm.c
> @@ -267,7 +267,12 @@ static void __init omap4_init_voltages(void)
>  
>  static inline void omap_init_cpufreq(void)
>  {
> -       struct platform_device_info devinfo = { .name = "omap-cpufreq", };
> +       struct platform_device_info devinfo = { };
> +
> +       if (!of_have_populated_dt())
> +               devinfo.name = "omap-cpufreq";
> +       else
> +               devinfo.name = "cpufreq-cpu0";
>         platform_device_register_full(&devinfo);
>  }
>  
> @@ -301,9 +306,9 @@ int __init omap2_common_pm_late_init(void)
>                 /* Smartreflex device init */
>                 omap_devinit_smartreflex();
>  
> -               /* cpufreq dummy device instantiation */
> -               omap_init_cpufreq();
>         }
> +       /* cpufreq dummy device instantiation */
> +       omap_init_cpufreq();
>  
>  #ifdef CONFIG_SUSPEND
>         suspend_set_ops(&omap_pm_ops);
> diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
> index a47e6ee..03c6e48 100644
> --- a/drivers/clk/Kconfig
> +++ b/drivers/clk/Kconfig
> @@ -55,6 +55,12 @@ config COMMON_CLK_MAX77686
>         ---help---
>           This driver supports Maxim 77686 crystal oscillator clock. 
>  
> +config COMMON_CLK_TI
> +       tristate "Clock driver for TI SoCs"
> +       depends on ARCH_OMAP && OF
> +       ---help---
> +         Fill me up.. some generic statement ofcourse (lets start with OMAP)
> +
>  config CLK_TWL6040
>         tristate "External McPDM functional clock from twl6040"
>         depends on TWL6040_CORE
> diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
> index 300d477..9621815 100644
> --- a/drivers/clk/Makefile
> +++ b/drivers/clk/Makefile
> @@ -30,6 +30,8 @@ obj-$(CONFIG_ARCH_TEGRA)      += tegra/
>  
>  obj-$(CONFIG_X86)              += x86/
>  
> +obj-$(CONFIG_COMMON_CLK_TI)    += ti.o
> +
>  # Chip specific
>  obj-$(CONFIG_COMMON_CLK_WM831X) += clk-wm831x.o
>  obj-$(CONFIG_COMMON_CLK_MAX77686) += clk-max77686.o
> diff --git a/drivers/clk/ti.c b/drivers/clk/ti.c
> new file mode 100644
> index 0000000..c747381
> --- /dev/null
> +++ b/drivers/clk/ti.c
> @@ -0,0 +1,100 @@
> +/*
> + * TI Clock node provider
> + *
> + * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
> + *     Nishanth Menon
> + *
> + * 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.
> + *
> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
> + * kind, whether express or implied; without even the implied warranty
> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +#include <linux/kernel.h>
> +#include <linux/list.h>
> +#include <linux/clk-private.h>
> +#include <linux/clkdev.h>
> +#include <linux/io.h>
> +#include <linux/of.h>
> +#include <linux/clk/ti.h>
> +
> +struct ti_clk {
> +       struct clk_lookup *lk;
> +       struct list_head node;
> +};
> +
> +static LIST_HEAD(ti_clk_list);
> +
> +static struct clk *ti_bypass_clk_get_by_name(struct of_phandle_args *clkspec,
> +                                            void *data)
> +{
> +       struct ti_clk *c;
> +#if 0
> +       /* Eww.. IF ONLY phandle arguments could be string */
> +       char clk_name[32]; /* 32 is max size of property name */
> +
> +       char *name = clkspec->args[0];
> +
> +       snprintf(clk_name, 32, "%s_ck", name);
> +       list_for_each_entry(c, &ti_clk_list, node) {
> +               int r = strncmp(c->lk->conn_id, clk_name, 32);
> +               pr_err("%s: searching %s in %s - %d\n",
> +                       __func__, clk_name, c->lk->con_id, r);
> +               if (!r) {
> +                       pr_err("%s: found it!\n", __func__);
> +                       return c->lk.clk;
> +               }
> +       }
> +#else
> +       /* Use integer indexing into clkdev list! Sigh.. */
> +       int idx = clkspec->args[0];
> +       int cindex = 1;
> +
> +       list_for_each_entry(c, &ti_clk_list, node) {
> +               int r = (idx == cindex) ? 0 :  1;
> +               pr_err("%s: searching index search = %d in %d in %s - %d\n",
> +                       __func__, idx, cindex, c->lk->con_id, r);
> +               if (!r) {
> +                       pr_err("%s: found it!\n", __func__);
> +                       return c->lk->clk;
> +               }
> +               cindex++;
> +       }
> +#endif
> +
> +       pr_err("%s: ran out of options\n", __func__);
> +       return ERR_PTR(-ENODEV);
> +}
> +
> +static void __init ti_clock_init(struct device_node *node)
> +{
> +
> +       pr_err("%s: START\n", __func__);
> +       of_clk_add_provider(node, ti_bypass_clk_get_by_name, NULL);
> +       pr_err("%s: END\n", __func__);
> +}
> +CLK_OF_DECLARE(ti_clk, "ti,clock", ti_clock_init);
> +
> +void __init ti_clk_node_add(struct clk_lookup *lk)
> +{
> +       struct ti_clk *c;
> +       static bool of_added;
> +
> +       c = kzalloc(sizeof(struct ti_clk), GFP_KERNEL);
> +       if (!c) {
> +               pr_err("%s: No memory!! cannot add clk node!\n", __func__);
> +               return;
> +       }
> +       clkdev_add(lk);
> +       c->lk = lk;
> +       list_add_tail(&c->node, &ti_clk_list);
> +       pr_err("%s: Added clock node %s\n", __func__, lk->con_id);
> +       if (!of_added) {
> +               of_clk_init(NULL);
> +               of_added =  true;
> +       }
> +};
> +
> diff --git a/include/linux/clk/ti.h b/include/linux/clk/ti.h
> new file mode 100644
> index 0000000..eb502a8
> --- /dev/null
> +++ b/include/linux/clk/ti.h
> @@ -0,0 +1,30 @@
> +/*
> + * TI Clock node provider header
> + *
> + * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
> + *     Nishanth Menon
> + *
> + * 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.
> + *
> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
> + * kind, whether express or implied; without even the implied warranty
> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +#ifndef __TI_CLK_H
> +#define __TI_CLK_H
> +
> +#include <linux/clkdev.h>
> +
> +#ifdef CONFIG_OF
> +extern void ti_clk_node_add(struct clk_lookup *lk);
> +#else
> +static inline void ti_clk_node_add(struct clk_lookup *lk)
> +{
> +       clkdev_add(lk);
> +}
> +#endif /* CONFIG_OF */
> +
> +#endif /* __TI_CLK_H */
> -- 
> 1.7.9.5
> 
> 
> -- 
> Regards,
> Nishanth Menon
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


From mturquette at linaro.org  Wed Apr 10 04:08:38 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Wed, 10 Apr 2013 01:08:38 -0700
Subject: [PATCHv7 07/17] clk: mvebu: add more PCIe clocks for Armada XP
In-Reply-To: <1364395234-11195-8-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1364395234-11195-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1364395234-11195-8-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <20130410080838.14359.58967@quantum>

Quoting Thomas Petazzoni (2013-03-27 07:40:24)
> The current revision of the datasheet only mentions the gatable clocks
> for the PCIe 0.0, 0.1, 0.2 and 0.3 interfaces, and forgot to mention
> the ones for the PCIe 1.0, 1.1, 1.2, 1.3, 2.0 and 3.0
> interfaces. After confirmation with Marvell engineers, this patch adds
> the missing gatable clocks for those PCIe interfaces.
> 
> It also changes the name of the previously existing PCIe gatable
> clocks, in order to match the naming using the datasheets.
> 
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>

Acked-by: Mike Turquette <mturquette at linaro.org>

> ---
>  drivers/clk/mvebu/clk-gating-ctrl.c |   14 ++++++++++----
>  1 file changed, 10 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/clk/mvebu/clk-gating-ctrl.c b/drivers/clk/mvebu/clk-gating-ctrl.c
> index b35785a..2f03723 100644
> --- a/drivers/clk/mvebu/clk-gating-ctrl.c
> +++ b/drivers/clk/mvebu/clk-gating-ctrl.c
> @@ -137,10 +137,14 @@ static const struct mvebu_soc_descr __initconst armada_xp_gating_descr[] = {
>         { "ge2", NULL,  2 },
>         { "ge1", NULL, 3 },
>         { "ge0", NULL, 4 },
> -       { "pex0", NULL, 5 },
> -       { "pex1", NULL, 6 },
> -       { "pex2", NULL, 7 },
> -       { "pex3", NULL, 8 },
> +       { "pex00", NULL, 5 },
> +       { "pex01", NULL, 6 },
> +       { "pex02", NULL, 7 },
> +       { "pex03", NULL, 8 },
> +       { "pex10", NULL, 9 },
> +       { "pex11", NULL, 10 },
> +       { "pex12", NULL, 11 },
> +       { "pex13", NULL, 12 },
>         { "bp", NULL, 13 },
>         { "sata0lnk", NULL, 14 },
>         { "sata0", "sata0lnk", 15 },
> @@ -152,6 +156,8 @@ static const struct mvebu_soc_descr __initconst armada_xp_gating_descr[] = {
>         { "xor0", NULL, 22 },
>         { "crypto", NULL, 23 },
>         { "tdm", NULL, 25 },
> +       { "pex20", NULL, 26 },
> +       { "pex30", NULL, 27 },
>         { "xor1", NULL, 28 },
>         { "sata1lnk", NULL, 29 },
>         { "sata1", "sata1lnk", 30 },
> -- 
> 1.7.9.5
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From mturquette at linaro.org  Wed Apr 10 04:09:00 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Wed, 10 Apr 2013 01:09:00 -0700
Subject: [PATCHv7 06/17] clk: mvebu: create parent-child relation for PCIe
 clocks on Armada 370
In-Reply-To: <1364395234-11195-7-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1364395234-11195-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1364395234-11195-7-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <20130410080900.14359.97128@quantum>

Quoting Thomas Petazzoni (2013-03-27 07:40:23)
> The Armada 370 has two gatable clocks for each PCIe interface, and we
> want both of them to be enabled. We therefore make one of the two
> clocks a child of the other, as we did for the sataX and sataXlnk
> clocks on Armada XP.
> 
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> Cc: Mike Turquette <mturquette at linaro.org>

Acked-by: Mike Turquette <mturquette at linaro.org>

> ---
>  drivers/clk/mvebu/clk-gating-ctrl.c |    4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/clk/mvebu/clk-gating-ctrl.c b/drivers/clk/mvebu/clk-gating-ctrl.c
> index ebf141d..b35785a 100644
> --- a/drivers/clk/mvebu/clk-gating-ctrl.c
> +++ b/drivers/clk/mvebu/clk-gating-ctrl.c
> @@ -119,8 +119,8 @@ static const struct mvebu_soc_descr __initconst armada_370_gating_descr[] = {
>         { "pex1_en", NULL,  2 },
>         { "ge1", NULL, 3 },
>         { "ge0", NULL, 4 },
> -       { "pex0", NULL, 5 },
> -       { "pex1", NULL, 9 },
> +       { "pex0", "pex0_en", 5 },
> +       { "pex1", "pex1_en", 9 },
>         { "sata0", NULL, 15 },
>         { "sdio", NULL, 17 },
>         { "tdm", NULL, 25 },
> -- 
> 1.7.9.5


From marc.zyngier at arm.com  Wed Apr 10 04:09:56 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 10 Apr 2013 10:09:56 +0200
Subject: [PATCH v2 6/7] ARM: KVM: switch to a dual-step HYP init code
In-Reply-To: <CAEDV+gK5P+8TEaQoqLoR6a2JWV+kP2tHwShK25tf+xD4k26OdA@mail.gmail.com>
References: <1365435403-29265-1-git-send-email-marc.zyngier@arm.com>
 <1365435403-29265-7-git-send-email-marc.zyngier@arm.com>
 <20130409091813.GC24090@mudshark.cambridge.arm.com>
 <5163F0B0.2000400@arm.com>
 <CAEDV+gK5P+8TEaQoqLoR6a2JWV+kP2tHwShK25tf+xD4k26OdA@mail.gmail.com>
Message-ID: <77d236959fe1da1865e8dce60e475479@localhost>

On Tue, 9 Apr 2013 11:28:07 -0700, Christoffer Dall
<cdall at cs.columbia.edu>
wrote:
> On Tue, Apr 9, 2013 at 3:42 AM, Marc Zyngier <marc.zyngier at arm.com>
wrote:
>> On 09/04/13 10:18, Will Deacon wrote:
>>> On Mon, Apr 08, 2013 at 04:36:42PM +0100, Marc Zyngier wrote:
>>>> Our HYP init code suffers from two major design issues:
>>>> - it cannot support CPU hotplug, as we tear down the idmap very early
>>>> - it cannot perform a TLB invalidation when switching from init to
>>>>   runtime mappings, as pages are manipulated from PL1 exclusively
>>>>
>>>> The hotplug problem mandates that we keep two sets of page tables
>>>> (boot and runtime). The TLB problem mandates that we're able to
>>>> transition from one PGD to another while in HYP, invalidating the
TLBs
>>>> in the process.
>>>>
>>>> To be able to do this, we need to share a page between the two page
>>>> tables. A page that will have the same VA in both configurations. All
>>>> we
>>>> need is a VA that has the following properties:
>>>> - This VA can't be used to represent a kernel mapping.
>>>> - This VA will not conflict with the physical address of the kernel
>>>> text
>>>>
>>>> The vectors page seems to satisfy this requirement:
>>>> - The kernel never maps anything else there
>>>> - The kernel text being copied at the beginning of the physical
memory,
>>>>   it is unlikely to use the last 64kB (I doubt we'll ever support KVM
>>>>   on a system with something like 4MB of RAM, but patches are very
>>>>   welcome).
>>>>
>>>> Let's call this VA the trampoline VA.
>>>>
>>>> Now, we map our init page at 3 locations:
>>>> - idmap in the boot pgd
>>>> - trampoline VA in the boot pgd
>>>> - trampoline VA in the runtime pgd
>>>>
>>>> The init scenario is now the following:
>>>> - We jump in HYP with four parameters: boot HYP pgd, runtime HYP pgd,
>>>>   runtime stack, runtime vectors
>>>> - Enable the MMU with the boot pgd
>>>> - Jump to a target into the trampoline page (remember, this is the
same
>>>>   physical page!)
>>>> - Now switch to the runtime pgd (same VA, and still the same physical
>>>>   page!)
>>>> - Invalidate TLBs
>>>> - Set stack and vectors
>>>> - Profit! (or eret, if you only care about the code).
>>>>
>>>> Note that we keep the boot mapping permanently (it is not strictly an
>>>> idmap anymore) to allow for CPU hotplug in later patches.
>>>>
>>>> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
>>>> ---

[...]

>>>>  int kvm_mmu_init(void)
>>>>  {
>>>> -       unsigned long hyp_idmap_start =
>>>> virt_to_phys(__hyp_idmap_text_start);
>>>> -       unsigned long hyp_idmap_end =
>>>> virt_to_phys(__hyp_idmap_text_end);
>>>>         int err;
>>>>
>>>> +       hyp_idmap_start = virt_to_phys(__hyp_idmap_text_start);
>>>> +       hyp_idmap_end = virt_to_phys(__hyp_idmap_text_end);
>>>> +       hyp_idmap_vector = virt_to_phys(__kvm_hyp_init);
>>>> +
>>>> +       if ((hyp_idmap_start ^ hyp_idmap_end) & PAGE_MASK) {
>>>> +               /*
>>>> +                * Our init code is crossing a page boundary.
Allocate
>>>> +                * a bounce page, copy the code over and use that.
>>>> +                */
>>>> +               size_t len = __hyp_idmap_text_end -
>>>> __hyp_idmap_text_start;
>>>> +               phys_addr_t phys_base;
>>>> +
>>>> +               init_bounce_page = kzalloc(PAGE_SIZE, GFP_KERNEL);
>>>> +               if (!init_bounce_page) {
>>>> +                       kvm_err("Couldn't allocate HYP init bounce
>>>> page\n");
>>>> +                       err = -ENOMEM;
>>>> +                       goto out;
>>>> +               }
>>>
>>> Given that you don't really need a lowmem page for the bounce page,
this
>>> might be better expressed using alloc_page and kmap for the memcpy.
>>
>> I'm a bit dubious about that. We have to make sure that the memory is
>> within the 4GB range, and the only flag I can spot for alloc_page is
>> GFP_DMA32, which is not exactly what we want, even if it may work.
>>
>> And yes, we have a problem with platforms having *all* their memory
>> above 4GB.
>>
> 
> now when we're picking at this, do we really need to memset an entire
> page to zero? I know it's nice for debugging, but it is really
> unnecessary and would slow down boot so slightly, no?

Sure, we don't need the page clearing. Not that it would appear anywhere
on the radar, but I'll turn it into a plain kmalloc call.

Thanks,

        M.
-- 
Fast, cheap, reliable. Pick two.


From prabhakar.csengg at gmail.com  Wed Apr 10 04:12:29 2013
From: prabhakar.csengg at gmail.com (Prabhakar Lad)
Date: Wed, 10 Apr 2013 13:42:29 +0530
Subject: Query on pinctrl usage for DT nodes
In-Reply-To: <5162FD4A.1030909@wwwdotorg.org>
References: <CA+V-a8uiPwsAD--OHFAE=i2ed+-wbXm4p2deZXr92+Zv6GDS1w@mail.gmail.com>
 <515C5C76.3080009@wwwdotorg.org>
 <CA+V-a8t3wtP77DdeUoQHKMjAuWmV+ude+1J3UjJmMTqobgStjA@mail.gmail.com>
 <5162FD4A.1030909@wwwdotorg.org>
Message-ID: <CA+V-a8vwdCkyMqiynj5BodXbjwJ=e4qNb-29FhLweqbjc7DBQA@mail.gmail.com>

Hi Stephen,Peter,

On Mon, Apr 8, 2013 at 10:54 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
> On 04/08/2013 07:12 AM, Prabhakar Lad wrote:
>> On Wed, Apr 3, 2013 at 10:14 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
>>> On 04/03/2013 03:16 AM, Prabhakar Lad wrote:
>>>> Hi Linus/Stephen,
>>>>
>>>> I am working adding  DT nodes for DA850.
> ...
>>>> But while booting I see the following boot log:-
>>>> ...
>>>> cpuidle: using governor menu
>>>> TCP: cubic registered
>>>> NET: Registered protocol family 17
>>>> pinctrl-single 1c14120.pinmux: pin 1c14130 already requested by
>>>> davinci_mdio.0; cannot claim for i2c_davinci.1
>>>> pinctrl-single 1c14120.pinmux: pin-4 (i2c_davinci.1) status -22
>>>> pinctrl-single 1c14120.pinmux: could not request pin 4 on device pinctrl-single
>>>> console [netcon0] enabled
>>>> ....
>>>>
>>>> This is because the mdio and i2c are using same pin 0x10,
>>>
>>> How can two devices use the same pin? I mean physically, in hardware?
>>>
>>> Is this because pinctrl-single uses the register address as the pin
>>> number, whereas you have registers which configure multiple pins at
>>
>> Yes you are correct, we have registers  which configure multiple pins at once.
>> For example for above Pin Multiplexing Control 4 Register (Pinmux4)
>> [1] page(250) : -
>>
>> PINMUX4_31_28 --> SP1_SCS[2]/UART1_TXD/SATA_CP_POD/GP1[0] Control
>> PINMUX4_27_24 --> SPI1_SCS[3]/UART1_RXD/SATA_LED/GP1[1] Control
>> PINMUX4_23_20 --> SPI1_SCS[4]/UART2_TXD/I2C1_SDA/GP1[2] Control
>> PINMUX4_19_16 --> SPI1_SCS[5]/UART2_RXD/I2C1_SCL/GP1[3] Control
>> PINMUX4_15_12 --> SPI1_SCS[6]/I2C0_SDA/TM64P3_OUT12/GP1[4] Control
>> PINMUX4_11_8 --> SPI1_SCS[7]/I2C0_SCL/TM64P2_OUT12/GP1[5] Control
>> PINMUX4_7_4 --> SPI0_SCS[0]/TM64P1_OUT12/GP1[6]/MDIO_D/TM64P1_IN12 Control
>> PINMUX4_3_0 --> SPI0_SCS[1]/TM64P0_OUT12/GP1[7]/MDIO_CLK/TM64P0_IN12 Control
>>
>>> once? If so, your hardware isn't something that can be represented by
>>> pinctrl-single.
>>
>> What is the alternative for such case ? any pointer would be helpful.
>>
>> [1] http://www.ti.com/general/docs/lit/getliterature.tsp?literatureNumber=spruh77a&fileType=pdf
>
> Tony previously replied:
>
> Tony wrote:
>> Tony wrote:
>>> ??? wrote:
>>>> Prabhakar wrote:
>>>>> Is there any
>>>>> alternative way to handle if the two node's are using same pins any
>>>>> pointers could be very much helpful ?
>>>
>>> It could also that the mux register(s) follow the one-mux-per-bit
>>> mapping.
>>>
>>> In that case pinctrl-single,bits option as documented in the
>>> Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt.
>>
>> Oh it's already using pinctrl-single,bits option. Maybe there's a
>> bug, adding Peter to cc.
>
> So I guess you need to debug the code to see why that option isn't
> working for you.
>
Following is the proposed fix/hack let me know if its OK.

Regards,
--Prabhakar

->>>>>>>>>>>>>>>>>>>

diff --git a/drivers/pinctrl/core.h b/drivers/pinctrl/core.h
index ee72f1f..78fb42d 100644
--- a/drivers/pinctrl/core.h
+++ b/drivers/pinctrl/core.h
@@ -46,6 +46,7 @@ struct pinctrl_dev {
        struct pinctrl *p;
        struct pinctrl_state *hog_default;
        struct pinctrl_state *hog_sleep;
+       bool bits_per_mux;
 #ifdef CONFIG_DEBUG_FS
        struct dentry *device_root;
 #endif
diff --git a/drivers/pinctrl/pinctrl-single.c b/drivers/pinctrl/pinctrl-single.c
index 5c32e88..d2a91ec 100644
--- a/drivers/pinctrl/pinctrl-single.c
+++ b/drivers/pinctrl/pinctrl-single.c
@@ -974,6 +974,7 @@ static int pcs_probe(struct platform_device *pdev)
                ret = -EINVAL;
                goto free;
        }
+       pcs->pctl->bits_per_mux = pcs->bits_per_mux;

        dev_info(pcs->dev, "%i pins at pa %p size %u\n",
                 pcs->desc.npins, pcs->base, pcs->size);
diff --git a/drivers/pinctrl/pinmux.c b/drivers/pinctrl/pinmux.c
index 1a00658..4989f01 100644
--- a/drivers/pinctrl/pinmux.c
+++ b/drivers/pinctrl/pinmux.c
@@ -110,7 +110,7 @@ static int pin_request(struct pinctrl_dev *pctldev,

                desc->gpio_owner = owner;
        } else {
-               if (desc->mux_usecount && strcmp(desc->mux_owner, owner)) {
+               if (!pctldev->bits_per_mux && desc->mux_usecount &&
strcmp(desc->mux_owner, owner)) {
                        dev_err(pctldev->dev,
                                "pin %s already requested by %s;
cannot claim for %s\n",
                                desc->name, desc->mux_owner, owner);
@@ -118,7 +118,7 @@ static int pin_request(struct pinctrl_dev *pctldev,
                }

                desc->mux_usecount++;
-               if (desc->mux_usecount > 1)
+               if (desc->mux_usecount > 1 && !pctldev->bits_per_mux)
                        return 0;

                desc->mux_owner = owner;


From steve.capper at arm.com  Wed Apr 10 04:21:00 2013
From: steve.capper at arm.com (Steve Capper)
Date: Wed, 10 Apr 2013 09:21:00 +0100
Subject: [PATCH] arm: mm: lockless get_user_pages_fast
In-Reply-To: <00a201ce35bd$5626fd90$0274f8b0$@samsusng.com>
References: <1360890012-4684-1-git-send-email-chanho61.park@samsung.com>
 <20130405111158.GA13428@e103986-lin>
 <00a201ce35bd$5626fd90$0274f8b0$@samsusng.com>
Message-ID: <20130410082059.GA12296@e103986-lin>

On Wed, Apr 10, 2013 at 08:30:54AM +0100, Chanho Park wrote:
> > Apologies for the tardy response, this patch slipped past me.
> 
> Never mind.
> 
> > I've tested this patch out, unfortunately it treats huge pmds as regular
> > pmds and attempts to traverse them rather than fall back to a slow path.
> > The fix for this is very minor, please see my suggestion below.
> OK. I'll fix it.
> 
> > 
> > As an aside, I would like to extend this fast_gup to include full huge
> > page support and include a __get_user_pages_fast implementation. This will
> > hopefully fix a problem that was brought to my attention by Grazvydas
> > Ignotas whereby a FUTEX_WAIT on a THP tail page will cause an infinite
> > loop due to the stock implementation of __get_user_pages_fast always
> > returning 0.
> 
> I'll add the __get_user_pages_fast implementation. BTW, HugeTLB on ARM
> wasn't
> supported yet. There is no problem to add gup_huge_pmd. But I think it need
> a test
> for hugepages.
> 

Thanks, that would be helpful. My plan was to then put the huge page
specific bits in, with another patch. That way I can test it all out
here.

> > I would suggest:
> > 		if (pmd_none(*pmdp) || pmd_bad(*pmdp))
> > 			return 0;
> > as this will pick up pmds that can't be traversed, and fall back to the
> > slow path.
> 
> Thanks for your suggestion.
> I'll prepare the v2 patch.
> 

Also, just one more thing. In your gup_pte_range function there is
an smp_rmb() just after the pte is dereferenced. I don't understand
why though?

> Best regards,
> Chanho Park
> 
> 

Thanks,
-- 
Steve



From balbi at ti.com  Wed Apr 10 04:27:48 2013
From: balbi at ti.com (Felipe Balbi)
Date: Wed, 10 Apr 2013 11:27:48 +0300
Subject: [PATCH v3 4/9] rcar-phy: remove EHCI internal buffer setup
In-Reply-To: <201304100232.30889.sergei.shtylyov@cogentembedded.com>
References: <201304100232.30889.sergei.shtylyov@cogentembedded.com>
Message-ID: <20130410082748.GJ7983@arwen.pp.htv.fi>

Hi,

On Wed, Apr 10, 2013 at 02:32:30AM +0400, Sergei Shtylyov wrote:
> Now that the EHCI internal  buffer setup is done by the platform code, we  can
> remove  such code from this driver as it  never  really belonged here.  We also
> no longer need the 2nd memory region now (2nd EHCI controller is simply missing
> in e.g. R8A7778 SoC).
> 
> The patch has been tested on the Marzen and BOCK-W boards.
> 
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
> Acked-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
> Acked-by: Simon Horman <horms+renesas at verge.net.au>
> 
> ---
> Changes since version 2:
> - added a note about testing to the changelog;
> - added ACKs from Simon Horman and Kuninori Morimoto.
> 
> Changes since the original posting:
> - split R8A7779 SoC file change to a separate patch.
> 
>  drivers/usb/phy/rcar-phy.c |   28 ++++------------------------

you do realise this won't apply, right ?

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130410/9bdea30f/attachment.sig>

From tomi.valkeinen at ti.com  Wed Apr 10 04:27:59 2013
From: tomi.valkeinen at ti.com (Tomi Valkeinen)
Date: Wed, 10 Apr 2013 11:27:59 +0300
Subject: [PATCH] video: mxsfb: Adapt to new videomode API
In-Reply-To: <1365516978-29888-1-git-send-email-fabio.estevam@freescale.com>
References: <1365516978-29888-1-git-send-email-fabio.estevam@freescale.com>
Message-ID: <5165228F.1020805@ti.com>

On 2013-04-09 17:16, Fabio Estevam wrote:
> commit 6cd2c7db4 (videomode: videomode_from_timing work) changed the name of 
> the function from videomode_from_timing() to videomode_from_timings().
> 
> commit 32ed6ef1 (videomode: create enum for videomode's display flags) changed
> the 'data_flags' field in videomode structure to 'flags'
> 
> Adapt to these changes in order to fix the following errors:
> 
> drivers/video/mxsfb.c:761:3: error: too many arguments to function 'videomode_from_timing'
> drivers/video/mxsfb.c:761:7: error: void value not ignored as it ought to be
> drivers/video/mxsfb.c:768:9: error: 'struct videomode' has no member named 'data_flags'
> drivers/video/mxsfb.c:770:9: error: 'struct videomode' has no member named 'data_flags'
> 
> Also select VIDEOMODE_HELPER in Kconfig to avoid linker errors.
> 
> Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>

The mxsfb.c driver in my tree does not contain such code. Where is this
patch meant to be applied?

 Tomi


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130410/3fb26f04/attachment.sig>

From glacier1980 at gmail.com  Wed Apr 10 04:28:42 2013
From: glacier1980 at gmail.com (Neil Zhang)
Date: Wed, 10 Apr 2013 16:28:42 +0800
Subject: [PATCH] ARM: cache-l2x0: add device tree support for power control
In-Reply-To: <1361935237-12466-1-git-send-email-chao.xie@marvell.com>
References: <1361935237-12466-1-git-send-email-chao.xie@marvell.com>
Message-ID: <CA+2_TibVrbpCWiLrZAGrhwpER0AOK=C_1xKrFakV2SENraVHHA@mail.gmail.com>

2013/2/27 Chao Xie <chao.xie at marvell.com>:
> After version r3p0, cache pl310 has the power control register.
> Adding the device tree support for power control.
> So it can parse the power control register settings.
>
> Signed-off-by: Chao Xie <chao.xie at marvell.com>
> ---
>  Documentation/devicetree/bindings/arm/l2cc.txt |    6 ++++++
>  arch/arm/mm/cache-l2x0.c                       |   16 ++++++++++++++++
>  2 files changed, 22 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/arm/l2cc.txt b/Documentation/devicetree/bindings/arm/l2cc.txt
> index cbef09b..435ead2 100644
> --- a/Documentation/devicetree/bindings/arm/l2cc.txt
> +++ b/Documentation/devicetree/bindings/arm/l2cc.txt
> @@ -34,6 +34,10 @@ Optional properties:
>  - arm,filter-ranges : <start length> Starting address and length of window to
>    filter. Addresses in the filter window are directed to the M1 port. Other
>    addresses will go to the M0 port.
> +- arm,pwr-dynamic-clk-gating: If it is defined. The dynamic clock gating for
> +  better power is enabled. Only availabe after r3p0.
> +- arm,pwr-standby-mode: If it is defined, standby mode is enabled. On available
> +  after r3p0.
>  - interrupts : 1 combined interrupt.
>  - cache-id-part: cache id part number to be used if it is not present
>    on hardware
> @@ -47,6 +51,8 @@ L2: cache-controller {
>          arm,data-latency = <1 1 1>;
>          arm,tag-latency = <2 2 2>;
>          arm,filter-ranges = <0x80000000 0x8000000>;
> +        arm,pwr-dynamic-clk-gating;
> +        arm,pwr-standby-mode;
>          cache-unified;
>          cache-level = <2>;
>         interrupts = <45>;
> diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
> index c2f3739..95a338a 100644
> --- a/arch/arm/mm/cache-l2x0.c
> +++ b/arch/arm/mm/cache-l2x0.c
> @@ -564,6 +564,9 @@ static void __init pl310_of_setup(const struct device_node *np,
>         u32 data[3] = { 0, 0, 0 };
>         u32 tag[3] = { 0, 0, 0 };
>         u32 filter[2] = { 0, 0 };
> +       u32 l2x0_revision;
> +       u32 power;
> +       const unsigned char *prop;
>
>         of_property_read_u32_array(np, "arm,tag-latency", tag, ARRAY_SIZE(tag));
>         if (tag[0] && tag[1] && tag[2])
> @@ -590,6 +593,19 @@ static void __init pl310_of_setup(const struct device_node *np,
>                 writel_relaxed((filter[0] & ~(SZ_1M - 1)) | L2X0_ADDR_FILTER_EN,
>                                l2x0_base + L2X0_ADDR_FILTER_START);
>         }
> +
> +       l2x0_revision = readl_relaxed(l2x0_base + L2X0_CACHE_ID) &
> +               L2X0_CACHE_ID_RTL_MASK;
> +       if (l2x0_revision >= L2X0_CACHE_ID_RTL_R3P0) {
> +               power = 0;
> +               prop = of_get_property(np, "arm,pwr-dynamic-clk-gating", NULL);
> +               if (prop)
> +                       power |= L2X0_DYNAMIC_CLK_GATING_EN;
> +               prop = of_get_property(np, "arm,pwr-standby-mode", NULL);
> +               if (prop)
> +                       power |= L2X0_STNDBY_MODE_EN;
> +               writel_relaxed(power, l2x0_base + L2X0_POWER_CTRL);
> +       }
>  }
>
>  static void __init pl310_save(void)
> --
> 1.7.4.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


Tested-by:  Neil Zhang <zhangwm at marvell.com>


From kgene.kim at samsung.com  Wed Apr 10 04:36:49 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Wed, 10 Apr 2013 17:36:49 +0900
Subject: linux-next: manual merge of the arm-soc tree with the pm tree
In-Reply-To: <20130410171743.2ffa67388b330991228a6775@canb.auug.org.au>
References: <20130410171743.2ffa67388b330991228a6775@canb.auug.org.au>
Message-ID: <30ad01ce35c6$8b13cb10$a13b6130$%kim@samsung.com>

Stephen Rothwell wrote:
> 
> Hi all,
> 
Hi,

> Today's linux-next merge of the arm-soc tree got a conflict in
> arch/arm/mach-s3c24xx/Kconfig between commit 785f40040874 ("cpufreq:
> s3c24xx: move cpufreq driver to drivers/cpufreq") from the pm tree and

As I know, Rafael will drop it in his tree.
http://lists-archives.com/linux-kernel/27815851-cpufreq-s3c24xx-move-cpufreq
-driver-to-drivers-cpufreq.html

> commits fb278af74b28 ("ARM: S3C24XX: Removed unneeded dependency on
> CPU_S3C2410") and a4e4d22c6f53 ("ARM: S3C24XX: Removed unneeded
> dependency on CPU_S3C2412") from the arm-soc tree.
> 
> I fixed it up by removing the sections from arch/arm/mach-s3c24xx/Kconfig
> and can carry thefix as necessary (no action is required).
> 
Thanks.

> P.S. those arm-soc tree commits have a bad Author email address ...

Oops :-( it's my fault due to e-mail client problem...

Arnd, it happened in next/dt-exynos, next/mct-exynos and
next/cleanup-samsung branches in my tree.

And I sorted out in my local just now. Could you please re-pull them into
arm-soc? Then, I will push forced. Sorry about that.

- Kukjin



From kgene.kim at samsung.com  Wed Apr 10 04:42:59 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Wed, 10 Apr 2013 17:42:59 +0900
Subject: [GIT PULL 04/10] clk-exynos for v3.10
In-Reply-To: <CAK9yfHzMOmrRMKdc2fUJHnbrOC_-=AR3BnHBDjtvPeinvxOcLg@mail.gmail.com>
References: <51630A02.4080905@samsung.com> <201304092231.18314.arnd@arndb.de>
 <CAK9yfHzMOmrRMKdc2fUJHnbrOC_-=AR3BnHBDjtvPeinvxOcLg@mail.gmail.com>
Message-ID: <30be01ce35c7$68eab7a0$3ac026e0$%kim@samsung.com>

Sachin Kamat wrote:
> 
> On 10 April 2013 02:01, Arnd Bergmann <arnd at arndb.de> wrote:
> > On Monday 08 April 2013, Kukjin Kim wrote:
> >> The following changes since commit
> 07961ac7c0ee8b546658717034fe692fd12eefa9:
> >>
> >>    Linux 3.9-rc5 (2013-03-31 15:12:43 -0700)
> >>
> >> are available in the git repository at:
> >>
> >>
git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
> >> tags/clk-exynos-for-v3.10
> >>
> >> for you to fetch changes up to
da821eb7d42935b0f7056d98c75fd1150f6636f4:
> >>
> >>    Merge commit 'v3.9-rc5' into next/clk-exynos (2013-04-09 01:10:13
> +0900)
> >>
> >> ----------------------------------------------------------------
> >>
> >> add suppport common clock framework for exynos
> >
> > I got a build warning, probably because of this patch:
> 
> 
> IIRC, the patch at [1] was supposed to fix the build warning. Kukjin
> had mentioned it was applied [1].
> 
> [1] https://patchwork.kernel.org/patch/2010691/
> 
Oops, probably the patch missed :-( Let me fix it.

Thanks.

- Kukjin



From balbi at ti.com  Wed Apr 10 04:50:33 2013
From: balbi at ti.com (Felipe Balbi)
Date: Wed, 10 Apr 2013 11:50:33 +0300
Subject: [PATCH v3 0/9] Reorganize R8A7779/Marzen USB code
In-Reply-To: <20130410044923.GD10044@verge.net.au>
References: <201304100226.08967.sergei.shtylyov@cogentembedded.com>
 <20130410044923.GD10044@verge.net.au>
Message-ID: <20130410085033.GL7983@arwen.pp.htv.fi>

Hi,

On Wed, Apr 10, 2013 at 01:49:23PM +0900, Simon Horman wrote:
> On Wed, Apr 10, 2013 at 02:26:08AM +0400, Sergei Shtylyov wrote:
> > Hello.
> > 
> >    Here's the set of 9 patches against the Simon Horman's 'renesas.git' repo,
> > 'renesas-next-20130410' tag.  It was created to fix the shortcomings in the
> > R8A7779/Marzen USB platform code and R8A7779 USB common PHY driver, and so
> > spans both arch/arm/mach-shmobile/ and drivers/usb/ subtrees (some patches have
> > to touch both subtrees). The patches were conceived with the complete
> > bisectability goal in mind.
> > 
> > [1/9] ARM: shmobile: Marzen: move USB EHCI, OHCI, and PHY devices to R8A7779 code
> > [2/9] ehci-platform: add pre_setup() method to platform data
> > [3/9] ARM: shmobile: R8A7779: setup EHCI internal buffer
> > [4/9] rcar-phy: remove EHCI internal buffer setup
> > [5/9] ARM: shmobile: R8A7779: remove USB PHY 2nd memory resource
> > [6/9] rcar-phy: correct base address
> > [7/9] rcar-phy: add platform data
> > [8/9] ARM: shmobile: Marzen: pass platform data to USB PHY device
> > [9/9] rcar-phy: handle platform data
> > 
> >    I'm not sure thru which tree this patchset should be merged, however it turns
> > out that it's too late now to push it thru Felipe Balbi's USB tree for 3.10
> > (which would have been most convenient probably), and it's probably too late to
> > merge thru Simon's tree for 3.10 too. So it now have to be postponed to 3.11,
> > unfortunately...
> 
> Felipe, how would you prefer to handle this?
> I'm happy for you to take it or to take it myself.

please take it yourself, just keep in mind there will be conflicts, I
will go over the patches now and give my Acked-by so you can queue them
up.

cheers

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130410/70dc1ec8/attachment.sig>

From xobs at kosagi.com  Wed Apr 10 04:53:09 2013
From: xobs at kosagi.com (Sean Cross)
Date: Wed, 10 Apr 2013 08:53:09 +0000
Subject: [PATCH] ARM: imx: add lvds clocks
Message-ID: <1365583989-10308-1-git-send-email-xobs@kosagi.com>

There are two LVDS clocks on the i.MX6 that may be used for a variety of
purposes, including PCI Express.  Add these clocks, as well as their
selectors.

Signed-off-by: Sean Cross <xobs at kosagi.com>
---
 .../devicetree/bindings/clock/imx6q-clock.txt      |    4 ++++
 arch/arm/mach-imx/clk-imx6q.c                      |   10 +++++++++-
 2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/clock/imx6q-clock.txt b/Documentation/devicetree/bindings/clock/imx6q-clock.txt
index 969b38e..0d3b919 100644
--- a/Documentation/devicetree/bindings/clock/imx6q-clock.txt
+++ b/Documentation/devicetree/bindings/clock/imx6q-clock.txt
@@ -205,6 +205,10 @@ clocks and IDs.
 	enet_ref		190
 	usbphy1_gate		191
 	usbphy2_gate		192
+	lvds1_sel		193
+	lvds2_sel		194
+	lvds1			195
+	lvds2			196
 
 Examples:
 
diff --git a/arch/arm/mach-imx/clk-imx6q.c b/arch/arm/mach-imx/clk-imx6q.c
index 2f9ff93..23d7f80 100644
--- a/arch/arm/mach-imx/clk-imx6q.c
+++ b/arch/arm/mach-imx/clk-imx6q.c
@@ -132,6 +132,8 @@ static const char *vpu_axi_sels[]	= { "axi", "pll2_pfd2_396m", "pll2_pfd0_352m",
 static const char *cko1_sels[]	= { "pll3_usb_otg", "pll2_bus", "pll1_sys", "pll5_video",
 				    "dummy", "axi", "enfc", "ipu1_di0", "ipu1_di1", "ipu2_di0",
 				    "ipu2_di1", "ahb", "ipg", "ipg_per", "ckil", "pll4_audio", };
+static const char *lvds1_sels[] = { "dummy", "dummy", "dummy", "dummy", "dummy", "dummy", "pll4_audio", "pll5_video", "pll8_mlb", "enet_ref", "pcie_ref", "sata_ref", "dummy", "dummy", "dummy", "dummy", "dummy", "dummy", "dummy", "lvds1", "lvds2", };
+static const char *lvds2_sels[] = { "dummy", "dummy", "dummy", "dummy", "dummy", "dummy", "pll4_audio", "pll5_video", "pll8_mlb", "enet_ref", "pcie_ref", "sata_ref", "dummy", "dummy", "dummy", "dummy", "dummy", "dummy", "dummy", "lvds1", "lvds2", };
 
 enum mx6q_clks {
 	dummy, ckil, ckih, osc, pll2_pfd0_352m, pll2_pfd1_594m, pll2_pfd2_396m,
@@ -165,7 +167,7 @@ enum mx6q_clks {
 	pll4_audio, pll5_video, pll8_mlb, pll7_usb_host, pll6_enet, ssi1_ipg,
 	ssi2_ipg, ssi3_ipg, rom, usbphy1, usbphy2, ldb_di0_div_3_5, ldb_di1_div_3_5,
 	sata_ref, sata_ref_100m, pcie_ref, pcie_ref_125m, enet_ref, usbphy1_gate,
-	usbphy2_gate, clk_max
+	usbphy2_gate, lvds1_sel, lvds2_sel, lvds1, lvds2, clk_max
 };
 
 static struct clk *clk[clk_max];
@@ -260,6 +262,12 @@ int __init mx6q_clocks_init(void)
 	clk[pll3_60m]  = imx_clk_fixed_factor("pll3_60m",  "pll3_usb_otg",   1, 8);
 	clk[twd]       = imx_clk_fixed_factor("twd",       "arm",            1, 2);
 
+	/*                                  name                reg       shift width parent_names     num_parents */
+	clk[lvds1_sel]        = imx_clk_mux("lvds1_sel",	base + 0x160, 0, 5, lvds1_sels,		ARRAY_SIZE(lvds1_sels));
+	clk[lvds2_sel]        = imx_clk_mux("lvds2_sel",	base + 0x160, 0, 5, lvds2_sels,		ARRAY_SIZE(lvds2_sels));
+
+	clk[lvds1] = imx_clk_gate("lvds1", "dummy", base + 0x160, 10);
+
 	np = of_find_compatible_node(NULL, NULL, "fsl,imx6q-ccm");
 	base = of_iomap(np, 0);
 	WARN_ON(!base);
-- 
1.7.9.5



From balbi at ti.com  Wed Apr 10 04:55:33 2013
From: balbi at ti.com (Felipe Balbi)
Date: Wed, 10 Apr 2013 11:55:33 +0300
Subject: [PATCH v3 4/9] rcar-phy: remove EHCI internal buffer setup
In-Reply-To: <201304100232.30889.sergei.shtylyov@cogentembedded.com>
References: <201304100232.30889.sergei.shtylyov@cogentembedded.com>
Message-ID: <20130410085533.GM7983@arwen.pp.htv.fi>

On Wed, Apr 10, 2013 at 02:32:30AM +0400, Sergei Shtylyov wrote:
> Now that the EHCI internal  buffer setup is done by the platform code, we  can
> remove  such code from this driver as it  never  really belonged here.  We also
> no longer need the 2nd memory region now (2nd EHCI controller is simply missing
> in e.g. R8A7778 SoC).
> 
> The patch has been tested on the Marzen and BOCK-W boards.
> 
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
> Acked-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
> Acked-by: Simon Horman <horms+renesas at verge.net.au>

Acked-by: Felipe Balbi <balbi at ti.com>

Note that this will conflict with my latest phy changes since all phy
drivers got renamed.

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130410/b4797efa/attachment.sig>

From balbi at TI.COM  Wed Apr 10 04:59:05 2013
From: balbi at TI.COM (Felipe Balbi)
Date: Wed, 10 Apr 2013 11:59:05 +0300
Subject: [PATCH v3 6/9] rcar-phy: correct base address
In-Reply-To: <201304100236.50822.sergei.shtylyov@cogentembedded.com>
References: <201304100236.50822.sergei.shtylyov@cogentembedded.com>
Message-ID: <20130410085905.GN7983@arwen.pp.htv.fi>

Hi,

On Wed, Apr 10, 2013 at 02:36:50AM +0400, Sergei Shtylyov wrote:
> The memory region that is used by the driver overlaps EHCI and OHCI  register
> regions for absolutely no reason now  -- fix it  by adding offset of 0x800 to
> the base address, changing the register #define's accordingly. This has extra
> positive effect that we now can use devm_ioremap_resource()...
> 
> Note that the driver and the SoC code have to be in one patch to keep the code
> bisectable...
> 
> The patch has been tested on the Marzen board.
> 
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
> Acked-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
> Acked-by: Simon Horman <horms+renesas at verge.net.au>

Acked-by: Felipe Balbi <balbi at ti.com>

This will conflict with latest phy changes but it's only a rename issue.

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130410/d20b0ddd/attachment-0001.sig>

From kgene.kim at samsung.com  Wed Apr 10 04:59:34 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Wed, 10 Apr 2013 17:59:34 +0900
Subject: [GIT PULL 0/10] Samsung stuff for v3.10
In-Reply-To: <201304092320.06222.arnd@arndb.de>
References: <516309C4.3000008@samsung.com> <201304092320.06222.arnd@arndb.de>
Message-ID: <30bf01ce35c9$b9120e70$2b362b50$%kim@samsung.com>

Arnd Bergmann wrote:
> 
> On Monday 08 April 2013, Kukjin Kim wrote:
> >
> > Hi Arnd, Olof
> >
> > This is 2nd pull-request for Samsung stuff for v3.10.
> >
> > If any problems, please kindly let me know.
> 
> I managed to pull them all in, aside from the 6/10, since you asked us
> to defer that one. There were a lot more small mistakes, and I think
> I've managed to fix them all up, but please check if the for-next
> branch now actually works.
> 
> A few more requests for the future:
> 
> * Please send branches earlier. You already sent a number of them
> very early, but then we saw very little until now. I'd rather
> get a number of follow-on pull requests than getting everything
> at once, which has lead to stuff getting rejected in the past
> when things break, as you remember. I've been waiting for
> ages now to rebase my multiplatform series on the things you
> have in your tree, I hope we can still make it in time.
> 
> * Half a sentence of tag description is not really enough for
> a long series. Please explain in the tag what the purpose of
> the series is, as you do for a patch.
> 
> * Mention interdependencies between branches explicitly. It
> causes us a lot of extra work having to find out what patches
> are actually new in a series when you have based them on earlier
> patches.
> 
> * Look at the patches that are already merged and test them.
> I've had to fix up build errors now that have been present
> in linux-next for multiple weeks.
> 
OK, I see. I will do carefully as per your suggestion.

Thanks.

- Kukjin



From horms at verge.net.au  Wed Apr 10 05:05:43 2013
From: horms at verge.net.au (Simon Horman)
Date: Wed, 10 Apr 2013 18:05:43 +0900
Subject: [PATCH v3 0/9] Reorganize R8A7779/Marzen USB code
In-Reply-To: <20130410085033.GL7983@arwen.pp.htv.fi>
References: <201304100226.08967.sergei.shtylyov@cogentembedded.com>
 <20130410044923.GD10044@verge.net.au>
 <20130410085033.GL7983@arwen.pp.htv.fi>
Message-ID: <20130410090543.GB25890@verge.net.au>

On Wed, Apr 10, 2013 at 11:50:33AM +0300, Felipe Balbi wrote:
> Hi,
> 
> On Wed, Apr 10, 2013 at 01:49:23PM +0900, Simon Horman wrote:
> > On Wed, Apr 10, 2013 at 02:26:08AM +0400, Sergei Shtylyov wrote:
> > > Hello.
> > > 
> > >    Here's the set of 9 patches against the Simon Horman's 'renesas.git' repo,
> > > 'renesas-next-20130410' tag.  It was created to fix the shortcomings in the
> > > R8A7779/Marzen USB platform code and R8A7779 USB common PHY driver, and so
> > > spans both arch/arm/mach-shmobile/ and drivers/usb/ subtrees (some patches have
> > > to touch both subtrees). The patches were conceived with the complete
> > > bisectability goal in mind.
> > > 
> > > [1/9] ARM: shmobile: Marzen: move USB EHCI, OHCI, and PHY devices to R8A7779 code
> > > [2/9] ehci-platform: add pre_setup() method to platform data
> > > [3/9] ARM: shmobile: R8A7779: setup EHCI internal buffer
> > > [4/9] rcar-phy: remove EHCI internal buffer setup
> > > [5/9] ARM: shmobile: R8A7779: remove USB PHY 2nd memory resource
> > > [6/9] rcar-phy: correct base address
> > > [7/9] rcar-phy: add platform data
> > > [8/9] ARM: shmobile: Marzen: pass platform data to USB PHY device
> > > [9/9] rcar-phy: handle platform data
> > > 
> > >    I'm not sure thru which tree this patchset should be merged, however it turns
> > > out that it's too late now to push it thru Felipe Balbi's USB tree for 3.10
> > > (which would have been most convenient probably), and it's probably too late to
> > > merge thru Simon's tree for 3.10 too. So it now have to be postponed to 3.11,
> > > unfortunately...
> > 
> > Felipe, how would you prefer to handle this?
> > I'm happy for you to take it or to take it myself.
> 
> please take it yourself, just keep in mind there will be conflicts, I
> will go over the patches now and give my Acked-by so you can queue them
> up.

Thanks



From peter.ujfalusi at ti.com  Wed Apr 10 05:08:00 2013
From: peter.ujfalusi at ti.com (Peter Ujfalusi)
Date: Wed, 10 Apr 2013 11:08:00 +0200
Subject: [PATCH] ARM: OMAP4+: omap2plus_defconfig: Enable audio via TWL6040 as
 module
Message-ID: <1365584880-25810-1-git-send-email-peter.ujfalusi@ti.com>

Boards supported upstream all use TWL6040 as audio codec, enable the common
ASoC machine driver by default for them.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi at ti.com>
---
 arch/arm/configs/omap2plus_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig
index bd07864..eea501c 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -152,6 +152,7 @@ CONFIG_OMAP_WATCHDOG=y
 CONFIG_TWL4030_WATCHDOG=y
 CONFIG_MFD_TPS65217=y
 CONFIG_MFD_TPS65910=y
+CONFIG_TWL6040_CORE=y
 CONFIG_REGULATOR_TWL4030=y
 CONFIG_REGULATOR_TPS65023=y
 CONFIG_REGULATOR_TPS6507X=y
@@ -194,6 +195,7 @@ CONFIG_SND_USB_AUDIO=m
 CONFIG_SND_SOC=m
 CONFIG_SND_OMAP_SOC=m
 CONFIG_SND_OMAP_SOC_OMAP_TWL4030=m
+CONFIG_SND_OMAP_SOC_OMAP_ABE_TWL6040=m
 CONFIG_SND_OMAP_SOC_OMAP3_PANDORA=m
 CONFIG_USB=y
 CONFIG_USB_DEBUG=y
-- 
1.8.1.5



From mark.rutland at arm.com  Wed Apr 10 05:11:48 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Wed, 10 Apr 2013 10:11:48 +0100
Subject: [PATCH] ARM: cache-l2x0: add device tree support for power control
In-Reply-To: <1361935237-12466-1-git-send-email-chao.xie@marvell.com>
References: <1361935237-12466-1-git-send-email-chao.xie@marvell.com>
Message-ID: <20130410091148.GA8799@e106331-lin.cambridge.arm.com>

Hi,

On Wed, Feb 27, 2013 at 03:20:37AM +0000, Chao Xie wrote:
> After version r3p0, cache pl310 has the power control register.
> Adding the device tree support for power control.
> So it can parse the power control register settings.
> 
> Signed-off-by: Chao Xie <chao.xie at marvell.com>
> ---
>  Documentation/devicetree/bindings/arm/l2cc.txt |    6 ++++++
>  arch/arm/mm/cache-l2x0.c                       |   16 ++++++++++++++++
>  2 files changed, 22 insertions(+), 0 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/arm/l2cc.txt b/Documentation/devicetree/bindings/arm/l2cc.txt
> index cbef09b..435ead2 100644
> --- a/Documentation/devicetree/bindings/arm/l2cc.txt
> +++ b/Documentation/devicetree/bindings/arm/l2cc.txt
> @@ -34,6 +34,10 @@ Optional properties:
>  - arm,filter-ranges : <start length> Starting address and length of window to
>    filter. Addresses in the filter window are directed to the M1 port. Other
>    addresses will go to the M0 port.
> +- arm,pwr-dynamic-clk-gating: If it is defined. The dynamic clock gating for
> +  better power is enabled. Only availabe after r3p0.

This appears to be a configuration option rather than a description of the
hardware.

If we're able to know that this feature is present by reading the id register,
we shouldn't need to describe it in the dt. We should simply work out if and
when we want it enabled within the kernel.

> +- arm,pwr-standby-mode: If it is defined, standby mode is enabled. On available
> +  after r3p0.

This looks like it depends on an additional signal being wired up, so it may be
worth describing.

>  - interrupts : 1 combined interrupt.
>  - cache-id-part: cache id part number to be used if it is not present
>    on hardware
> @@ -47,6 +51,8 @@ L2: cache-controller {
>          arm,data-latency = <1 1 1>;
>          arm,tag-latency = <2 2 2>;
>          arm,filter-ranges = <0x80000000 0x8000000>;
> +        arm,pwr-dynamic-clk-gating;
> +        arm,pwr-standby-mode;
>          cache-unified;
>          cache-level = <2>;
>  	interrupts = <45>;
> diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
> index c2f3739..95a338a 100644
> --- a/arch/arm/mm/cache-l2x0.c
> +++ b/arch/arm/mm/cache-l2x0.c
> @@ -564,6 +564,9 @@ static void __init pl310_of_setup(const struct device_node *np,
>  	u32 data[3] = { 0, 0, 0 };
>  	u32 tag[3] = { 0, 0, 0 };
>  	u32 filter[2] = { 0, 0 };
> +	u32 l2x0_revision;
> +	u32 power;
> +	const unsigned char *prop;
>  
>  	of_property_read_u32_array(np, "arm,tag-latency", tag, ARRAY_SIZE(tag));
>  	if (tag[0] && tag[1] && tag[2])
> @@ -590,6 +593,19 @@ static void __init pl310_of_setup(const struct device_node *np,
>  		writel_relaxed((filter[0] & ~(SZ_1M - 1)) | L2X0_ADDR_FILTER_EN,
>  			       l2x0_base + L2X0_ADDR_FILTER_START);
>  	}
> +
> +	l2x0_revision = readl_relaxed(l2x0_base + L2X0_CACHE_ID) &
> +		L2X0_CACHE_ID_RTL_MASK;
> +	if (l2x0_revision >= L2X0_CACHE_ID_RTL_R3P0) {
> +		power = 0;
> +		prop = of_get_property(np, "arm,pwr-dynamic-clk-gating", NULL);
> +		if (prop)
> +			power |= L2X0_DYNAMIC_CLK_GATING_EN;
> +		prop = of_get_property(np, "arm,pwr-standby-mode", NULL);
> +		if (prop)
> +			power |= L2X0_STNDBY_MODE_EN;

You can use of_property_read_bool for both of the above cases (and you won't
need prop any more):

if (of_property_read_bool(np, "arm,pwr-standby-mode"))
	power |= L2X0_STNDBY_MODE_EN;

If dt info isn't needed, this can probably be moved into l2x0_init.

Mark.


From tomasz.figa at gmail.com  Wed Apr 10 05:19:27 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Wed, 10 Apr 2013 11:19:27 +0200
Subject: [GIT PULL 08/10] secure-exynos for v3.10
In-Reply-To: <CAL_JsqJLVae44Sr2qf0=YE0DokkeetHFnyFEMKhYpY8sv58Mjw@mail.gmail.com>
References: <51630A36.6030505@samsung.com>
 <CAL_JsqJLVae44Sr2qf0=YE0DokkeetHFnyFEMKhYpY8sv58Mjw@mail.gmail.com>
Message-ID: <50580316.bmGRcvNpvy@flatron>

Hi Rob,

On Tuesday 09 of April 2013 16:43:48 Rob Herring wrote:
> On Mon, Apr 8, 2013 at 1:19 PM, Kukjin Kim <kgene.kim at samsung.com> 
wrote:
> > The following changes since commit 
da821eb7d42935b0f7056d98c75fd1150f6636f4:
> >   Merge commit 'v3.9-rc5' into next/clk-exynos (2013-04-09 01:10:13
> >   +0900)> 
> > are available in the git repository at:
> >   git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.gi
> >   t
> > 
> > tags/secure-exynos-for-v3.10
> > 
> > for you to fetch changes up to 
beddf63fc8e01f06799bd6d7a2dd879885bbc9c6:
> >   ARM: EXYNOS: Add secure firmware support to secondary CPU bring-up
> > 
> > (2013-04-09 01:52:30 +0900)
> > 
> > ----------------------------------------------------------------
> > add support secure firmware for exynos
> > 
> > ----------------------------------------------------------------
> > 
> > Tomasz Figa (5):
> >       ARM: Add interface for registering and calling firmware-specific
> > 
> > operations
> 
> I missed the original series, but looking at this patch now I'm not
> convinced this is all that generic despite the name. Should PSCI be
> using this for example?

As far as I remember, nobody had any objections about this interface not 
being generic enough in last version of the series.

In fact it might be hard to make this fully generic (in terms of available 
firmware ops), because each firmware might provide its own, different set 
of operations.
 
> Also, a comment from Barry Song that "firmware_ops" is too generic for
> global name was not addressed.

This doesn't seem like any major issue at the moment. I can send a 
followup patch to rename it to arm_firmware, secure_firmware or whatever 
is preferred after it gets merged.

Btw. Barry's comment is dated to 26 Dec, more than a month since the patch 
was posted and was already merged in Kukjin's tree at that time.

Best regards,
Tomasz

> Rob
> 
> >       ARM: EXYNOS: Add support for secure monitor calls
> >       ARM: EXYNOS: Add support for Exynos secure firmware
> >       ARM: EXYNOS: Add IO mapping for non-secure SYSRAM.
> >       ARM: EXYNOS: Add secure firmware support to secondary CPU
> >       bring-up
> >  
> >  Documentation/arm/firmware.txt                     | 88
> > 
> > ++++++++++++++++++++++
> > 
> >  .../devicetree/bindings/arm/samsung-boards.txt     | 10 +++
> >  arch/arm/common/Makefile                           |  2 +
> >  arch/arm/common/firmware.c                         | 18 +++++
> >  arch/arm/include/asm/firmware.h                    | 66
> >  ++++++++++++++++ arch/arm/mach-exynos/Makefile                     
> >  |  6 ++
> >  arch/arm/mach-exynos/common.c                      | 35 +++++++++
> >  arch/arm/mach-exynos/common.h                      |  2 +
> >  arch/arm/mach-exynos/exynos-smc.S                  | 22 ++++++
> >  arch/arm/mach-exynos/firmware.c                    | 70
> >  +++++++++++++++++ arch/arm/mach-exynos/include/mach/map.h           
> >  |  3 +
> >  arch/arm/mach-exynos/mach-exynos4-dt.c             |  1 +
> >  arch/arm/mach-exynos/platsmp.c                     | 32 ++++++--
> >  arch/arm/mach-exynos/smc.h                         | 31 ++++++++
> >  arch/arm/plat-samsung/include/plat/map-s5p.h       |  1 +
> >  15 files changed, 382 insertions(+), 5 deletions(-)
> >  create mode 100644 Documentation/arm/firmware.txt
> >  create mode 100644 arch/arm/common/firmware.c
> >  create mode 100644 arch/arm/include/asm/firmware.h
> >  create mode 100644 arch/arm/mach-exynos/exynos-smc.S
> >  create mode 100644 arch/arm/mach-exynos/firmware.c
> >  create mode 100644 arch/arm/mach-exynos/smc.h
> > 
> > --
> > Thanks.
> > 
> > Best regards,
> > Kgene.
> > --
> > Kukjin Kim <kgene.kim at samsung.com>, Senior Engineer,
> > SW Solution Development Team, Samsung Electronics Co., Ltd.
> > 
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-samsung-soc" in the body of a message to
> majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


From plagnioj at jcrosoft.com  Wed Apr 10 05:17:24 2013
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Wed, 10 Apr 2013 11:17:24 +0200
Subject: [PATCH 2/2] ARM: at91: move dts to subdir
In-Reply-To: <1365585444-11520-1-git-send-email-plagnioj@jcrosoft.com>
References: <1365585444-11520-1-git-send-email-plagnioj@jcrosoft.com>
Message-ID: <1365585444-11520-2-git-send-email-plagnioj@jcrosoft.com>

Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
Cc: Olof Johansson <olof at lixom.net>
Cc: Nicolas Ferre <nicolas.ferre at atmel.com>
---
 arch/arm/boot/dts/Makefile                         |   42 +++++---------------
 arch/arm/boot/dts/at91/Makefile                    |   38 ++++++++++++++++++
 arch/arm/boot/dts/{ => at91}/aks-cdu.dts           |    0
 arch/arm/boot/dts/{ => at91}/animeo_ip.dts         |    0
 arch/arm/boot/dts/{ => at91}/at91rm9200.dtsi       |    2 +-
 arch/arm/boot/dts/{ => at91}/at91rm9200ek.dts      |    0
 arch/arm/boot/dts/{ => at91}/at91sam9260.dtsi      |    2 +-
 arch/arm/boot/dts/{ => at91}/at91sam9263.dtsi      |    2 +-
 arch/arm/boot/dts/{ => at91}/at91sam9263ek.dts     |    0
 arch/arm/boot/dts/{ => at91}/at91sam9g15.dtsi      |    0
 arch/arm/boot/dts/{ => at91}/at91sam9g15ek.dts     |    0
 arch/arm/boot/dts/{ => at91}/at91sam9g20.dtsi      |    0
 arch/arm/boot/dts/{ => at91}/at91sam9g20ek.dts     |    0
 .../arm/boot/dts/{ => at91}/at91sam9g20ek_2mmc.dts |    0
 .../boot/dts/{ => at91}/at91sam9g20ek_common.dtsi  |    0
 arch/arm/boot/dts/{ => at91}/at91sam9g25.dtsi      |    0
 arch/arm/boot/dts/{ => at91}/at91sam9g25ek.dts     |    0
 arch/arm/boot/dts/{ => at91}/at91sam9g35.dtsi      |    0
 arch/arm/boot/dts/{ => at91}/at91sam9g35ek.dts     |    0
 arch/arm/boot/dts/{ => at91}/at91sam9g45.dtsi      |    2 +-
 arch/arm/boot/dts/{ => at91}/at91sam9m10g45ek.dts  |    0
 arch/arm/boot/dts/{ => at91}/at91sam9n12.dtsi      |    2 +-
 arch/arm/boot/dts/{ => at91}/at91sam9n12ek.dts     |    0
 arch/arm/boot/dts/{ => at91}/at91sam9x25.dtsi      |    0
 arch/arm/boot/dts/{ => at91}/at91sam9x25ek.dts     |    0
 arch/arm/boot/dts/{ => at91}/at91sam9x35.dtsi      |    0
 arch/arm/boot/dts/{ => at91}/at91sam9x35ek.dts     |    0
 arch/arm/boot/dts/{ => at91}/at91sam9x5.dtsi       |    2 +-
 arch/arm/boot/dts/{ => at91}/at91sam9x5cm.dtsi     |    0
 arch/arm/boot/dts/{ => at91}/at91sam9x5ek.dtsi     |    0
 arch/arm/boot/dts/{ => at91}/ethernut5.dts         |    0
 arch/arm/boot/dts/{ => at91}/evk-pro3.dts          |    0
 arch/arm/boot/dts/{ => at91}/ge863-pro3.dtsi       |    0
 arch/arm/boot/dts/{ => at91}/kizbox.dts            |    0
 arch/arm/boot/dts/{ => at91}/pm9g45.dts            |    0
 arch/arm/boot/dts/{ => at91}/tny_a9260.dts         |    0
 arch/arm/boot/dts/{ => at91}/tny_a9260_common.dtsi |    0
 arch/arm/boot/dts/{ => at91}/tny_a9263.dts         |    0
 arch/arm/boot/dts/{ => at91}/tny_a9g20.dts         |    0
 arch/arm/boot/dts/{ => at91}/usb_a9260.dts         |    0
 arch/arm/boot/dts/{ => at91}/usb_a9260_common.dtsi |    0
 arch/arm/boot/dts/{ => at91}/usb_a9263.dts         |    0
 .../arm/boot/dts/{ => at91}/usb_a9g20-dab-mmx.dtsi |    0
 arch/arm/boot/dts/{ => at91}/usb_a9g20.dts         |    0
 44 files changed, 54 insertions(+), 38 deletions(-)
 create mode 100644 arch/arm/boot/dts/at91/Makefile
 rename arch/arm/boot/dts/{ => at91}/aks-cdu.dts (100%)
 rename arch/arm/boot/dts/{ => at91}/animeo_ip.dts (100%)
 rename arch/arm/boot/dts/{ => at91}/at91rm9200.dtsi (99%)
 rename arch/arm/boot/dts/{ => at91}/at91rm9200ek.dts (100%)
 rename arch/arm/boot/dts/{ => at91}/at91sam9260.dtsi (99%)
 rename arch/arm/boot/dts/{ => at91}/at91sam9263.dtsi (99%)
 rename arch/arm/boot/dts/{ => at91}/at91sam9263ek.dts (100%)
 rename arch/arm/boot/dts/{ => at91}/at91sam9g15.dtsi (100%)
 rename arch/arm/boot/dts/{ => at91}/at91sam9g15ek.dts (100%)
 rename arch/arm/boot/dts/{ => at91}/at91sam9g20.dtsi (100%)
 rename arch/arm/boot/dts/{ => at91}/at91sam9g20ek.dts (100%)
 rename arch/arm/boot/dts/{ => at91}/at91sam9g20ek_2mmc.dts (100%)
 rename arch/arm/boot/dts/{ => at91}/at91sam9g20ek_common.dtsi (100%)
 rename arch/arm/boot/dts/{ => at91}/at91sam9g25.dtsi (100%)
 rename arch/arm/boot/dts/{ => at91}/at91sam9g25ek.dts (100%)
 rename arch/arm/boot/dts/{ => at91}/at91sam9g35.dtsi (100%)
 rename arch/arm/boot/dts/{ => at91}/at91sam9g35ek.dts (100%)
 rename arch/arm/boot/dts/{ => at91}/at91sam9g45.dtsi (99%)
 rename arch/arm/boot/dts/{ => at91}/at91sam9m10g45ek.dts (100%)
 rename arch/arm/boot/dts/{ => at91}/at91sam9n12.dtsi (99%)
 rename arch/arm/boot/dts/{ => at91}/at91sam9n12ek.dts (100%)
 rename arch/arm/boot/dts/{ => at91}/at91sam9x25.dtsi (100%)
 rename arch/arm/boot/dts/{ => at91}/at91sam9x25ek.dts (100%)
 rename arch/arm/boot/dts/{ => at91}/at91sam9x35.dtsi (100%)
 rename arch/arm/boot/dts/{ => at91}/at91sam9x35ek.dts (100%)
 rename arch/arm/boot/dts/{ => at91}/at91sam9x5.dtsi (99%)
 rename arch/arm/boot/dts/{ => at91}/at91sam9x5cm.dtsi (100%)
 rename arch/arm/boot/dts/{ => at91}/at91sam9x5ek.dtsi (100%)
 rename arch/arm/boot/dts/{ => at91}/ethernut5.dts (100%)
 rename arch/arm/boot/dts/{ => at91}/evk-pro3.dts (100%)
 rename arch/arm/boot/dts/{ => at91}/ge863-pro3.dtsi (100%)
 rename arch/arm/boot/dts/{ => at91}/kizbox.dts (100%)
 rename arch/arm/boot/dts/{ => at91}/pm9g45.dts (100%)
 rename arch/arm/boot/dts/{ => at91}/tny_a9260.dts (100%)
 rename arch/arm/boot/dts/{ => at91}/tny_a9260_common.dtsi (100%)
 rename arch/arm/boot/dts/{ => at91}/tny_a9263.dts (100%)
 rename arch/arm/boot/dts/{ => at91}/tny_a9g20.dts (100%)
 rename arch/arm/boot/dts/{ => at91}/usb_a9260.dts (100%)
 rename arch/arm/boot/dts/{ => at91}/usb_a9260_common.dtsi (100%)
 rename arch/arm/boot/dts/{ => at91}/usb_a9263.dts (100%)
 rename arch/arm/boot/dts/{ => at91}/usb_a9g20-dab-mmx.dtsi (100%)
 rename arch/arm/boot/dts/{ => at91}/usb_a9g20.dts (100%)

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 2fa303d..a6a34f8 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -2,37 +2,8 @@ ifeq ($(CONFIG_OF),y)
 
 # Keep dtb files sorted alphabetically for each ARCH/SoC
 
-# at91
-# rm9200
-dtb-$(CONFIG_ARCH_AT91) += at91rm9200ek.dtb
-# sam9260
-dtb-$(CONFIG_ARCH_AT91) += animeo_ip.dtb
-dtb-$(CONFIG_ARCH_AT91) += aks-cdu.dtb
-dtb-$(CONFIG_ARCH_AT91) += ethernut5.dtb
-dtb-$(CONFIG_ARCH_AT91) += evk-pro3.dtb
-dtb-$(CONFIG_ARCH_AT91) += tny_a9260.dtb
-dtb-$(CONFIG_ARCH_AT91) += usb_a9260.dtb
-# sam9263
-dtb-$(CONFIG_ARCH_AT91) += at91sam9263ek.dtb
-dtb-$(CONFIG_ARCH_AT91) += tny_a9263.dtb
-dtb-$(CONFIG_ARCH_AT91) += usb_a9263.dtb
-# sam9g20
-dtb-$(CONFIG_ARCH_AT91) += at91sam9g20ek.dtb
-dtb-$(CONFIG_ARCH_AT91) += at91sam9g20ek_2mmc.dtb
-dtb-$(CONFIG_ARCH_AT91) += kizbox.dtb
-dtb-$(CONFIG_ARCH_AT91) += tny_a9g20.dtb
-dtb-$(CONFIG_ARCH_AT91) += usb_a9g20.dtb
-# sam9g45
-dtb-$(CONFIG_ARCH_AT91) += at91sam9m10g45ek.dtb
-dtb-$(CONFIG_ARCH_AT91) += pm9g45.dtb
-# sam9n12
-dtb-$(CONFIG_ARCH_AT91) += at91sam9n12ek.dtb
-# sam9x5
-dtb-$(CONFIG_ARCH_AT91) += at91sam9g15ek.dtb
-dtb-$(CONFIG_ARCH_AT91) += at91sam9g25ek.dtb
-dtb-$(CONFIG_ARCH_AT91) += at91sam9g35ek.dtb
-dtb-$(CONFIG_ARCH_AT91) += at91sam9x25ek.dtb
-dtb-$(CONFIG_ARCH_AT91) += at91sam9x35ek.dtb
+#at91
+dtb-$(CONFIG_ARCH_AT91) += at91/
 
 # bcm2835
 dtb-$(CONFIG_ARCH_BCM2835) += bcm2835-rpi-b.dtb
@@ -260,9 +231,16 @@ targets += dtbs
 targets += $(dtb-y)
 endif
 
+__dtb_subdir-y	:= $(patsubst %/, %/dtbs, $(filter %/, $(dtb-y)))
+dtb_subdir-y	:= $(addprefix $(obj)/, $(__dtb_subdir-y))
+
 # *.dtb used to be generated in the directory above. Clean out the
 # old build results so people don't accidentally use them.
-dtbs: $(addprefix $(obj)/, $(dtb-y))
+dtbs: $(addprefix $(obj)/, $(dtb-y)) $(dtb_subdir-y)
 	$(Q)rm -f $(obj)/../*.dtb
 
+$(dtb_subdir-y):
+	$(Q)rm -f `dirname $@`/*.dtb
+	$(Q)$(MAKE) $(build)=`dirname $@` dtbs
+
 clean-files := *.dtb
diff --git a/arch/arm/boot/dts/at91/Makefile b/arch/arm/boot/dts/at91/Makefile
new file mode 100644
index 0000000..d14a410
--- /dev/null
+++ b/arch/arm/boot/dts/at91/Makefile
@@ -0,0 +1,38 @@
+# Keep dtb files sorted alphabetically for each SoC
+
+# at91
+# rm9200
+dtb-y += at91rm9200ek.dtb
+# sam9260
+dtb-y += animeo_ip.dtb
+dtb-y += aks-cdu.dtb
+dtb-y += ethernut5.dtb
+dtb-y += evk-pro3.dtb
+dtb-y += tny_a9260.dtb
+dtb-y += usb_a9260.dtb
+# sam9263
+dtb-y += at91sam9263ek.dtb
+dtb-y += tny_a9263.dtb
+dtb-y += usb_a9263.dtb
+# sam9g20
+dtb-y += at91sam9g20ek.dtb
+dtb-y += at91sam9g20ek_2mmc.dtb
+dtb-y += kizbox.dtb
+dtb-y += tny_a9g20.dtb
+dtb-y += usb_a9g20.dtb
+# sam9g45
+dtb-y += at91sam9m10g45ek.dtb
+dtb-y += pm9g45.dtb
+# sam9n12
+dtb-y += at91sam9n12ek.dtb
+# sam9x5
+dtb-y += at91sam9g15ek.dtb
+dtb-y += at91sam9g25ek.dtb
+dtb-y += at91sam9g35ek.dtb
+dtb-y += at91sam9x25ek.dtb
+dtb-y += at91sam9x35ek.dtb
+
+targets += dtbs
+targets += $(dtb-y)
+
+dtbs: $(addprefix $(obj)/, $(dtb-y))
diff --git a/arch/arm/boot/dts/aks-cdu.dts b/arch/arm/boot/dts/at91/aks-cdu.dts
similarity index 100%
rename from arch/arm/boot/dts/aks-cdu.dts
rename to arch/arm/boot/dts/at91/aks-cdu.dts
diff --git a/arch/arm/boot/dts/animeo_ip.dts b/arch/arm/boot/dts/at91/animeo_ip.dts
similarity index 100%
rename from arch/arm/boot/dts/animeo_ip.dts
rename to arch/arm/boot/dts/at91/animeo_ip.dts
diff --git a/arch/arm/boot/dts/at91rm9200.dtsi b/arch/arm/boot/dts/at91/at91rm9200.dtsi
similarity index 99%
rename from arch/arm/boot/dts/at91rm9200.dtsi
rename to arch/arm/boot/dts/at91/at91rm9200.dtsi
index b0268a5..6962e75 100644
--- a/arch/arm/boot/dts/at91rm9200.dtsi
+++ b/arch/arm/boot/dts/at91/at91rm9200.dtsi
@@ -10,7 +10,7 @@
  * Licensed under GPLv2 or later.
  */
 
-/include/ "skeleton.dtsi"
+/include/ "../skeleton.dtsi"
 
 / {
 	model = "Atmel AT91RM9200 family SoC";
diff --git a/arch/arm/boot/dts/at91rm9200ek.dts b/arch/arm/boot/dts/at91/at91rm9200ek.dts
similarity index 100%
rename from arch/arm/boot/dts/at91rm9200ek.dts
rename to arch/arm/boot/dts/at91/at91rm9200ek.dts
diff --git a/arch/arm/boot/dts/at91sam9260.dtsi b/arch/arm/boot/dts/at91/at91sam9260.dtsi
similarity index 99%
rename from arch/arm/boot/dts/at91sam9260.dtsi
rename to arch/arm/boot/dts/at91/at91sam9260.dtsi
index cb7bcc5..3f8213b 100644
--- a/arch/arm/boot/dts/at91sam9260.dtsi
+++ b/arch/arm/boot/dts/at91/at91sam9260.dtsi
@@ -8,7 +8,7 @@
  * Licensed under GPLv2 or later.
  */
 
-/include/ "skeleton.dtsi"
+/include/ "../skeleton.dtsi"
 
 / {
 	model = "Atmel AT91SAM9260 family SoC";
diff --git a/arch/arm/boot/dts/at91sam9263.dtsi b/arch/arm/boot/dts/at91/at91sam9263.dtsi
similarity index 99%
rename from arch/arm/boot/dts/at91sam9263.dtsi
rename to arch/arm/boot/dts/at91/at91sam9263.dtsi
index d8146bb6..db3ffe4 100644
--- a/arch/arm/boot/dts/at91sam9263.dtsi
+++ b/arch/arm/boot/dts/at91/at91sam9263.dtsi
@@ -6,7 +6,7 @@
  * Licensed under GPLv2 only.
  */
 
-/include/ "skeleton.dtsi"
+/include/ "../skeleton.dtsi"
 
 / {
 	model = "Atmel AT91SAM9263 family SoC";
diff --git a/arch/arm/boot/dts/at91sam9263ek.dts b/arch/arm/boot/dts/at91/at91sam9263ek.dts
similarity index 100%
rename from arch/arm/boot/dts/at91sam9263ek.dts
rename to arch/arm/boot/dts/at91/at91sam9263ek.dts
diff --git a/arch/arm/boot/dts/at91sam9g15.dtsi b/arch/arm/boot/dts/at91/at91sam9g15.dtsi
similarity index 100%
rename from arch/arm/boot/dts/at91sam9g15.dtsi
rename to arch/arm/boot/dts/at91/at91sam9g15.dtsi
diff --git a/arch/arm/boot/dts/at91sam9g15ek.dts b/arch/arm/boot/dts/at91/at91sam9g15ek.dts
similarity index 100%
rename from arch/arm/boot/dts/at91sam9g15ek.dts
rename to arch/arm/boot/dts/at91/at91sam9g15ek.dts
diff --git a/arch/arm/boot/dts/at91sam9g20.dtsi b/arch/arm/boot/dts/at91/at91sam9g20.dtsi
similarity index 100%
rename from arch/arm/boot/dts/at91sam9g20.dtsi
rename to arch/arm/boot/dts/at91/at91sam9g20.dtsi
diff --git a/arch/arm/boot/dts/at91sam9g20ek.dts b/arch/arm/boot/dts/at91/at91sam9g20ek.dts
similarity index 100%
rename from arch/arm/boot/dts/at91sam9g20ek.dts
rename to arch/arm/boot/dts/at91/at91sam9g20ek.dts
diff --git a/arch/arm/boot/dts/at91sam9g20ek_2mmc.dts b/arch/arm/boot/dts/at91/at91sam9g20ek_2mmc.dts
similarity index 100%
rename from arch/arm/boot/dts/at91sam9g20ek_2mmc.dts
rename to arch/arm/boot/dts/at91/at91sam9g20ek_2mmc.dts
diff --git a/arch/arm/boot/dts/at91sam9g20ek_common.dtsi b/arch/arm/boot/dts/at91/at91sam9g20ek_common.dtsi
similarity index 100%
rename from arch/arm/boot/dts/at91sam9g20ek_common.dtsi
rename to arch/arm/boot/dts/at91/at91sam9g20ek_common.dtsi
diff --git a/arch/arm/boot/dts/at91sam9g25.dtsi b/arch/arm/boot/dts/at91/at91sam9g25.dtsi
similarity index 100%
rename from arch/arm/boot/dts/at91sam9g25.dtsi
rename to arch/arm/boot/dts/at91/at91sam9g25.dtsi
diff --git a/arch/arm/boot/dts/at91sam9g25ek.dts b/arch/arm/boot/dts/at91/at91sam9g25ek.dts
similarity index 100%
rename from arch/arm/boot/dts/at91sam9g25ek.dts
rename to arch/arm/boot/dts/at91/at91sam9g25ek.dts
diff --git a/arch/arm/boot/dts/at91sam9g35.dtsi b/arch/arm/boot/dts/at91/at91sam9g35.dtsi
similarity index 100%
rename from arch/arm/boot/dts/at91sam9g35.dtsi
rename to arch/arm/boot/dts/at91/at91sam9g35.dtsi
diff --git a/arch/arm/boot/dts/at91sam9g35ek.dts b/arch/arm/boot/dts/at91/at91sam9g35ek.dts
similarity index 100%
rename from arch/arm/boot/dts/at91sam9g35ek.dts
rename to arch/arm/boot/dts/at91/at91sam9g35ek.dts
diff --git a/arch/arm/boot/dts/at91sam9g45.dtsi b/arch/arm/boot/dts/at91/at91sam9g45.dtsi
similarity index 99%
rename from arch/arm/boot/dts/at91sam9g45.dtsi
rename to arch/arm/boot/dts/at91/at91sam9g45.dtsi
index bc103bc..58ce2a1 100644
--- a/arch/arm/boot/dts/at91sam9g45.dtsi
+++ b/arch/arm/boot/dts/at91/at91sam9g45.dtsi
@@ -9,7 +9,7 @@
  * Licensed under GPLv2 or later.
  */
 
-/include/ "skeleton.dtsi"
+/include/ "../skeleton.dtsi"
 
 / {
 	model = "Atmel AT91SAM9G45 family SoC";
diff --git a/arch/arm/boot/dts/at91sam9m10g45ek.dts b/arch/arm/boot/dts/at91/at91sam9m10g45ek.dts
similarity index 100%
rename from arch/arm/boot/dts/at91sam9m10g45ek.dts
rename to arch/arm/boot/dts/at91/at91sam9m10g45ek.dts
diff --git a/arch/arm/boot/dts/at91sam9n12.dtsi b/arch/arm/boot/dts/at91/at91sam9n12.dtsi
similarity index 99%
rename from arch/arm/boot/dts/at91sam9n12.dtsi
rename to arch/arm/boot/dts/at91/at91sam9n12.dtsi
index 7750f98..2ae88c1 100644
--- a/arch/arm/boot/dts/at91sam9n12.dtsi
+++ b/arch/arm/boot/dts/at91/at91sam9n12.dtsi
@@ -7,7 +7,7 @@
  * Licensed under GPLv2 or later.
  */
 
-/include/ "skeleton.dtsi"
+/include/ "../skeleton.dtsi"
 
 / {
 	model = "Atmel AT91SAM9N12 SoC";
diff --git a/arch/arm/boot/dts/at91sam9n12ek.dts b/arch/arm/boot/dts/at91/at91sam9n12ek.dts
similarity index 100%
rename from arch/arm/boot/dts/at91sam9n12ek.dts
rename to arch/arm/boot/dts/at91/at91sam9n12ek.dts
diff --git a/arch/arm/boot/dts/at91sam9x25.dtsi b/arch/arm/boot/dts/at91/at91sam9x25.dtsi
similarity index 100%
rename from arch/arm/boot/dts/at91sam9x25.dtsi
rename to arch/arm/boot/dts/at91/at91sam9x25.dtsi
diff --git a/arch/arm/boot/dts/at91sam9x25ek.dts b/arch/arm/boot/dts/at91/at91sam9x25ek.dts
similarity index 100%
rename from arch/arm/boot/dts/at91sam9x25ek.dts
rename to arch/arm/boot/dts/at91/at91sam9x25ek.dts
diff --git a/arch/arm/boot/dts/at91sam9x35.dtsi b/arch/arm/boot/dts/at91/at91sam9x35.dtsi
similarity index 100%
rename from arch/arm/boot/dts/at91sam9x35.dtsi
rename to arch/arm/boot/dts/at91/at91sam9x35.dtsi
diff --git a/arch/arm/boot/dts/at91sam9x35ek.dts b/arch/arm/boot/dts/at91/at91sam9x35ek.dts
similarity index 100%
rename from arch/arm/boot/dts/at91sam9x35ek.dts
rename to arch/arm/boot/dts/at91/at91sam9x35ek.dts
diff --git a/arch/arm/boot/dts/at91sam9x5.dtsi b/arch/arm/boot/dts/at91/at91sam9x5.dtsi
similarity index 99%
rename from arch/arm/boot/dts/at91sam9x5.dtsi
rename to arch/arm/boot/dts/at91/at91sam9x5.dtsi
index a98c0d5..a7966a8 100644
--- a/arch/arm/boot/dts/at91sam9x5.dtsi
+++ b/arch/arm/boot/dts/at91/at91sam9x5.dtsi
@@ -9,7 +9,7 @@
  * Licensed under GPLv2 or later.
  */
 
-/include/ "skeleton.dtsi"
+/include/ "../skeleton.dtsi"
 
 / {
 	model = "Atmel AT91SAM9x5 family SoC";
diff --git a/arch/arm/boot/dts/at91sam9x5cm.dtsi b/arch/arm/boot/dts/at91/at91sam9x5cm.dtsi
similarity index 100%
rename from arch/arm/boot/dts/at91sam9x5cm.dtsi
rename to arch/arm/boot/dts/at91/at91sam9x5cm.dtsi
diff --git a/arch/arm/boot/dts/at91sam9x5ek.dtsi b/arch/arm/boot/dts/at91/at91sam9x5ek.dtsi
similarity index 100%
rename from arch/arm/boot/dts/at91sam9x5ek.dtsi
rename to arch/arm/boot/dts/at91/at91sam9x5ek.dtsi
diff --git a/arch/arm/boot/dts/ethernut5.dts b/arch/arm/boot/dts/at91/ethernut5.dts
similarity index 100%
rename from arch/arm/boot/dts/ethernut5.dts
rename to arch/arm/boot/dts/at91/ethernut5.dts
diff --git a/arch/arm/boot/dts/evk-pro3.dts b/arch/arm/boot/dts/at91/evk-pro3.dts
similarity index 100%
rename from arch/arm/boot/dts/evk-pro3.dts
rename to arch/arm/boot/dts/at91/evk-pro3.dts
diff --git a/arch/arm/boot/dts/ge863-pro3.dtsi b/arch/arm/boot/dts/at91/ge863-pro3.dtsi
similarity index 100%
rename from arch/arm/boot/dts/ge863-pro3.dtsi
rename to arch/arm/boot/dts/at91/ge863-pro3.dtsi
diff --git a/arch/arm/boot/dts/kizbox.dts b/arch/arm/boot/dts/at91/kizbox.dts
similarity index 100%
rename from arch/arm/boot/dts/kizbox.dts
rename to arch/arm/boot/dts/at91/kizbox.dts
diff --git a/arch/arm/boot/dts/pm9g45.dts b/arch/arm/boot/dts/at91/pm9g45.dts
similarity index 100%
rename from arch/arm/boot/dts/pm9g45.dts
rename to arch/arm/boot/dts/at91/pm9g45.dts
diff --git a/arch/arm/boot/dts/tny_a9260.dts b/arch/arm/boot/dts/at91/tny_a9260.dts
similarity index 100%
rename from arch/arm/boot/dts/tny_a9260.dts
rename to arch/arm/boot/dts/at91/tny_a9260.dts
diff --git a/arch/arm/boot/dts/tny_a9260_common.dtsi b/arch/arm/boot/dts/at91/tny_a9260_common.dtsi
similarity index 100%
rename from arch/arm/boot/dts/tny_a9260_common.dtsi
rename to arch/arm/boot/dts/at91/tny_a9260_common.dtsi
diff --git a/arch/arm/boot/dts/tny_a9263.dts b/arch/arm/boot/dts/at91/tny_a9263.dts
similarity index 100%
rename from arch/arm/boot/dts/tny_a9263.dts
rename to arch/arm/boot/dts/at91/tny_a9263.dts
diff --git a/arch/arm/boot/dts/tny_a9g20.dts b/arch/arm/boot/dts/at91/tny_a9g20.dts
similarity index 100%
rename from arch/arm/boot/dts/tny_a9g20.dts
rename to arch/arm/boot/dts/at91/tny_a9g20.dts
diff --git a/arch/arm/boot/dts/usb_a9260.dts b/arch/arm/boot/dts/at91/usb_a9260.dts
similarity index 100%
rename from arch/arm/boot/dts/usb_a9260.dts
rename to arch/arm/boot/dts/at91/usb_a9260.dts
diff --git a/arch/arm/boot/dts/usb_a9260_common.dtsi b/arch/arm/boot/dts/at91/usb_a9260_common.dtsi
similarity index 100%
rename from arch/arm/boot/dts/usb_a9260_common.dtsi
rename to arch/arm/boot/dts/at91/usb_a9260_common.dtsi
diff --git a/arch/arm/boot/dts/usb_a9263.dts b/arch/arm/boot/dts/at91/usb_a9263.dts
similarity index 100%
rename from arch/arm/boot/dts/usb_a9263.dts
rename to arch/arm/boot/dts/at91/usb_a9263.dts
diff --git a/arch/arm/boot/dts/usb_a9g20-dab-mmx.dtsi b/arch/arm/boot/dts/at91/usb_a9g20-dab-mmx.dtsi
similarity index 100%
rename from arch/arm/boot/dts/usb_a9g20-dab-mmx.dtsi
rename to arch/arm/boot/dts/at91/usb_a9g20-dab-mmx.dtsi
diff --git a/arch/arm/boot/dts/usb_a9g20.dts b/arch/arm/boot/dts/at91/usb_a9g20.dts
similarity index 100%
rename from arch/arm/boot/dts/usb_a9g20.dts
rename to arch/arm/boot/dts/at91/usb_a9g20.dts
-- 
1.7.10.4



From plagnioj at jcrosoft.com  Wed Apr 10 05:17:23 2013
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Wed, 10 Apr 2013 11:17:23 +0200
Subject: [PATCH 1/2] ARM: boot/dts/Makefile: drop '\'
Message-ID: <1365585444-11520-1-git-send-email-plagnioj@jcrosoft.com>

when adding multiple new platform this generate comflict
so drop it

Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
Cc: Olof Johansson <olof at lixom.net>
---
 arch/arm/boot/dts/Makefile |  456 ++++++++++++++++++++++++++------------------
 1 file changed, 268 insertions(+), 188 deletions(-)
 rewrite arch/arm/boot/dts/Makefile (67%)

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
dissimilarity index 67%
index 9c62558..2fa303d 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -1,188 +1,268 @@
-ifeq ($(CONFIG_OF),y)
-
-# Keep at91 dtb files sorted alphabetically for each SoC
-# rm9200
-dtb-$(CONFIG_ARCH_AT91) += at91rm9200ek.dtb
-# sam9260
-dtb-$(CONFIG_ARCH_AT91) += animeo_ip.dtb
-dtb-$(CONFIG_ARCH_AT91) += aks-cdu.dtb
-dtb-$(CONFIG_ARCH_AT91) += ethernut5.dtb
-dtb-$(CONFIG_ARCH_AT91) += evk-pro3.dtb
-dtb-$(CONFIG_ARCH_AT91) += tny_a9260.dtb
-dtb-$(CONFIG_ARCH_AT91) += usb_a9260.dtb
-# sam9263
-dtb-$(CONFIG_ARCH_AT91) += at91sam9263ek.dtb
-dtb-$(CONFIG_ARCH_AT91) += tny_a9263.dtb
-dtb-$(CONFIG_ARCH_AT91) += usb_a9263.dtb
-# sam9g20
-dtb-$(CONFIG_ARCH_AT91) += at91sam9g20ek.dtb
-dtb-$(CONFIG_ARCH_AT91) += at91sam9g20ek_2mmc.dtb
-dtb-$(CONFIG_ARCH_AT91) += kizbox.dtb
-dtb-$(CONFIG_ARCH_AT91) += tny_a9g20.dtb
-dtb-$(CONFIG_ARCH_AT91) += usb_a9g20.dtb
-# sam9g45
-dtb-$(CONFIG_ARCH_AT91) += at91sam9m10g45ek.dtb
-dtb-$(CONFIG_ARCH_AT91) += pm9g45.dtb
-# sam9n12
-dtb-$(CONFIG_ARCH_AT91) += at91sam9n12ek.dtb
-# sam9x5
-dtb-$(CONFIG_ARCH_AT91) += at91sam9g15ek.dtb
-dtb-$(CONFIG_ARCH_AT91) += at91sam9g25ek.dtb
-dtb-$(CONFIG_ARCH_AT91) += at91sam9g35ek.dtb
-dtb-$(CONFIG_ARCH_AT91) += at91sam9x25ek.dtb
-dtb-$(CONFIG_ARCH_AT91) += at91sam9x35ek.dtb
-
-dtb-$(CONFIG_ARCH_BCM2835) += bcm2835-rpi-b.dtb
-dtb-$(CONFIG_ARCH_BCM) += bcm11351-brt.dtb
-dtb-$(CONFIG_ARCH_DAVINCI) += da850-enbw-cmc.dtb \
-	da850-evm.dtb
-dtb-$(CONFIG_ARCH_DOVE) += dove-cm-a510.dtb \
-	dove-cubox.dtb \
-	dove-dove-db.dtb
-dtb-$(CONFIG_ARCH_EXYNOS) += exynos4210-origen.dtb \
-	exynos4210-smdkv310.dtb \
-	exynos4210-trats.dtb \
-	exynos4412-smdk4412.dtb \
-	exynos5250-smdk5250.dtb \
-	exynos5250-snow.dtb \
-	exynos5440-ssdk5440.dtb
-dtb-$(CONFIG_ARCH_HIGHBANK) += highbank.dtb \
-	ecx-2000.dtb
-dtb-$(CONFIG_ARCH_INTEGRATOR) += integratorap.dtb \
-	integratorcp.dtb
-dtb-$(CONFIG_ARCH_LPC32XX) += ea3250.dtb phy3250.dtb
-dtb-$(CONFIG_ARCH_KIRKWOOD) += kirkwood-dns320.dtb \
-	kirkwood-dns325.dtb \
-	kirkwood-dockstar.dtb \
-	kirkwood-dreamplug.dtb \
-	kirkwood-goflexnet.dtb \
-	kirkwood-guruplug-server-plus.dtb \
-	kirkwood-ib62x0.dtb \
-	kirkwood-iconnect.dtb \
-	kirkwood-iomega_ix2_200.dtb \
-	kirkwood-is2.dtb \
-	kirkwood-km_kirkwood.dtb \
-	kirkwood-lschlv2.dtb \
-	kirkwood-lsxhl.dtb \
-	kirkwood-mplcec4.dtb \
-	kirkwood-ns2.dtb \
-	kirkwood-ns2lite.dtb \
-	kirkwood-ns2max.dtb \
-	kirkwood-ns2mini.dtb \
-	kirkwood-nsa310.dtb \
-	kirkwood-topkick.dtb \
-	kirkwood-ts219-6281.dtb \
-	kirkwood-ts219-6282.dtb \
-	kirkwood-openblocks_a6.dtb
-dtb-$(CONFIG_ARCH_MARCO) += marco-evb.dtb
-dtb-$(CONFIG_ARCH_MSM) += msm8660-surf.dtb \
-	msm8960-cdp.dtb
-dtb-$(CONFIG_ARCH_MVEBU) += armada-370-db.dtb \
-	armada-370-mirabox.dtb \
-	armada-370-rd.dtb \
-	armada-xp-db.dtb \
-	armada-xp-gp.dtb \
-	armada-xp-openblocks-ax3-4.dtb
-dtb-$(CONFIG_ARCH_MXC) += \
-	imx25-karo-tx25.dtb \
-	imx25-pdk.dtb \
-	imx27-apf27.dtb \
-	imx27-pdk.dtb \
-	imx31-bug.dtb \
-	imx51-apf51.dtb \
-	imx51-babbage.dtb \
-	imx53-ard.dtb \
-	imx53-evk.dtb \
-	imx53-mba53.dtb \
-	imx53-qsb.dtb \
-	imx53-smd.dtb \
-	imx6q-arm2.dtb \
-	imx6q-sabreauto.dtb \
-	imx6q-sabrelite.dtb \
-	imx6q-sabresd.dtb
-dtb-$(CONFIG_ARCH_MXS) += imx23-evk.dtb \
-	imx23-olinuxino.dtb \
-	imx23-stmp378x_devb.dtb \
-	imx28-apf28.dtb \
-	imx28-apf28dev.dtb \
-	imx28-apx4devkit.dtb \
-	imx28-cfa10036.dtb \
-	imx28-cfa10037.dtb \
-	imx28-cfa10049.dtb \
-	imx28-evk.dtb \
-	imx28-m28evk.dtb \
-	imx28-sps1.dtb \
-	imx28-tx28.dtb
-dtb-$(CONFIG_ARCH_NOMADIK) += ste-nomadik-s8815.dtb
-dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
-	omap3-beagle.dtb \
-	omap3-beagle-xm.dtb \
-	omap3-evm.dtb \
-	omap3-tobi.dtb \
-	omap4-panda.dtb \
-	omap4-panda-a4.dtb \
-	omap4-panda-es.dtb \
-	omap4-var-som.dtb \
-	omap4-sdp.dtb \
-	omap5-evm.dtb \
-	am335x-evm.dtb \
-	am335x-evmsk.dtb \
-	am335x-bone.dtb
-dtb-$(CONFIG_ARCH_ORION5X) += orion5x-lacie-ethernet-disk-mini-v2.dtb
-dtb-$(CONFIG_ARCH_PRIMA2) += prima2-evb.dtb
-dtb-$(CONFIG_ARCH_U8500) += snowball.dtb \
-	hrefprev60.dtb \
-	hrefv60plus.dtb \
-	ccu9540.dtb
-dtb-$(CONFIG_ARCH_SHMOBILE) += emev2-kzm9d.dtb \
-	r8a7740-armadillo800eva.dtb \
-	sh73a0-kzm9g.dtb \
-	sh7372-mackerel.dtb
-dtb-$(CONFIG_ARCH_SOCFPGA) += socfpga_cyclone5.dtb \
-	socfpga_vt.dtb
-dtb-$(CONFIG_ARCH_SPEAR13XX) += spear1310-evb.dtb \
-	spear1340-evb.dtb
-dtb-$(CONFIG_ARCH_SPEAR3XX)+= spear300-evb.dtb \
-	spear310-evb.dtb \
-	spear320-evb.dtb \
-	spear320-hmi.dtb
-dtb-$(CONFIG_ARCH_SPEAR6XX)+= spear600-evb.dtb
-dtb-$(CONFIG_ARCH_SUNXI) += sun4i-a10-cubieboard.dtb \
-	sun4i-a10-hackberry.dtb \
-	sun5i-a13-olinuxino.dtb
-dtb-$(CONFIG_ARCH_TEGRA) += tegra20-harmony.dtb \
-	tegra20-iris-512.dtb \
-	tegra20-medcom-wide.dtb \
-	tegra20-paz00.dtb \
-	tegra20-plutux.dtb \
-	tegra20-seaboard.dtb \
-	tegra20-tec.dtb \
-	tegra20-trimslice.dtb \
-	tegra20-ventana.dtb \
-	tegra20-whistler.dtb \
-	tegra30-beaver.dtb \
-	tegra30-cardhu-a02.dtb \
-	tegra30-cardhu-a04.dtb \
-	tegra114-dalmore.dtb \
-	tegra114-pluto.dtb
-dtb-$(CONFIG_ARCH_VEXPRESS) += vexpress-v2p-ca5s.dtb \
-	vexpress-v2p-ca9.dtb \
-	vexpress-v2p-ca15-tc1.dtb \
-	vexpress-v2p-ca15_a7.dtb \
-	xenvm-4.2.dtb
-dtb-$(CONFIG_ARCH_VT8500) += vt8500-bv07.dtb \
-	wm8505-ref.dtb \
-	wm8650-mid.dtb \
-	wm8850-w70v2.dtb
-dtb-$(CONFIG_ARCH_ZYNQ) += zynq-zc702.dtb
-
-targets += dtbs
-targets += $(dtb-y)
-endif
-
-# *.dtb used to be generated in the directory above. Clean out the
-# old build results so people don't accidentally use them.
-dtbs: $(addprefix $(obj)/, $(dtb-y))
-	$(Q)rm -f $(obj)/../*.dtb
-
-clean-files := *.dtb
+ifeq ($(CONFIG_OF),y)
+
+# Keep dtb files sorted alphabetically for each ARCH/SoC
+
+# at91
+# rm9200
+dtb-$(CONFIG_ARCH_AT91) += at91rm9200ek.dtb
+# sam9260
+dtb-$(CONFIG_ARCH_AT91) += animeo_ip.dtb
+dtb-$(CONFIG_ARCH_AT91) += aks-cdu.dtb
+dtb-$(CONFIG_ARCH_AT91) += ethernut5.dtb
+dtb-$(CONFIG_ARCH_AT91) += evk-pro3.dtb
+dtb-$(CONFIG_ARCH_AT91) += tny_a9260.dtb
+dtb-$(CONFIG_ARCH_AT91) += usb_a9260.dtb
+# sam9263
+dtb-$(CONFIG_ARCH_AT91) += at91sam9263ek.dtb
+dtb-$(CONFIG_ARCH_AT91) += tny_a9263.dtb
+dtb-$(CONFIG_ARCH_AT91) += usb_a9263.dtb
+# sam9g20
+dtb-$(CONFIG_ARCH_AT91) += at91sam9g20ek.dtb
+dtb-$(CONFIG_ARCH_AT91) += at91sam9g20ek_2mmc.dtb
+dtb-$(CONFIG_ARCH_AT91) += kizbox.dtb
+dtb-$(CONFIG_ARCH_AT91) += tny_a9g20.dtb
+dtb-$(CONFIG_ARCH_AT91) += usb_a9g20.dtb
+# sam9g45
+dtb-$(CONFIG_ARCH_AT91) += at91sam9m10g45ek.dtb
+dtb-$(CONFIG_ARCH_AT91) += pm9g45.dtb
+# sam9n12
+dtb-$(CONFIG_ARCH_AT91) += at91sam9n12ek.dtb
+# sam9x5
+dtb-$(CONFIG_ARCH_AT91) += at91sam9g15ek.dtb
+dtb-$(CONFIG_ARCH_AT91) += at91sam9g25ek.dtb
+dtb-$(CONFIG_ARCH_AT91) += at91sam9g35ek.dtb
+dtb-$(CONFIG_ARCH_AT91) += at91sam9x25ek.dtb
+dtb-$(CONFIG_ARCH_AT91) += at91sam9x35ek.dtb
+
+# bcm2835
+dtb-$(CONFIG_ARCH_BCM2835) += bcm2835-rpi-b.dtb
+
+# bcm
+dtb-$(CONFIG_ARCH_BCM) += bcm11351-brt.dtb
+
+# davinci
+dtb-$(CONFIG_ARCH_DAVINCI) += da850-enbw-cmc.dtb
+dtb-$(CONFIG_ARCH_DAVINCI) += da850-evm.dtb
+
+# dove
+dtb-$(CONFIG_ARCH_DOVE) += dove-cm-a510.dtb
+dtb-$(CONFIG_ARCH_DOVE) += dove-cubox.dtb
+dtb-$(CONFIG_ARCH_DOVE) += dove-dove-db.dtb
+
+# exynos
+# exynos4210
+dtb-$(CONFIG_ARCH_EXYNOS) += exynos4210-origen.dtb
+dtb-$(CONFIG_ARCH_EXYNOS) += exynos4210-smdkv310.dtb
+dtb-$(CONFIG_ARCH_EXYNOS) += exynos4210-trats.dtb
+# exynos4412
+dtb-$(CONFIG_ARCH_EXYNOS) += exynos4412-smdk4412.dtb
+# exynos5250
+dtb-$(CONFIG_ARCH_EXYNOS) += exynos5250-smdk5250.dtb
+dtb-$(CONFIG_ARCH_EXYNOS) += exynos5250-snow.dtb
+# exynos5440
+dtb-$(CONFIG_ARCH_EXYNOS) += exynos5440-ssdk5440.dtb
+
+# highbank
+dtb-$(CONFIG_ARCH_HIGHBANK) += highbank.dtb
+dtb-$(CONFIG_ARCH_HIGHBANK) += ecx-2000.dtb
+
+# integrator
+dtb-$(CONFIG_ARCH_INTEGRATOR) += integratorap.dtb
+dtb-$(CONFIG_ARCH_INTEGRATOR) += integratorcp.dtb
+
+# lpc32xxx
+dtb-$(CONFIG_ARCH_LPC32XX) += ea3250.dtb phy3250.dtb
+
+# kirkwood
+dtb-$(CONFIG_ARCH_KIRKWOOD) += kirkwood-dns320.dtb
+dtb-$(CONFIG_ARCH_KIRKWOOD) += kirkwood-dns325.dtb
+dtb-$(CONFIG_ARCH_KIRKWOOD) += kirkwood-dockstar.dtb
+dtb-$(CONFIG_ARCH_KIRKWOOD) += kirkwood-dreamplug.dtb
+dtb-$(CONFIG_ARCH_KIRKWOOD) += kirkwood-goflexnet.dtb
+dtb-$(CONFIG_ARCH_KIRKWOOD) += kirkwood-guruplug-server-plus.dtb
+dtb-$(CONFIG_ARCH_KIRKWOOD) += kirkwood-ib62x0.dtb
+dtb-$(CONFIG_ARCH_KIRKWOOD) += kirkwood-iconnect.dtb
+dtb-$(CONFIG_ARCH_KIRKWOOD) += kirkwood-iomega_ix2_200.dtb
+dtb-$(CONFIG_ARCH_KIRKWOOD) += kirkwood-is2.dtb
+dtb-$(CONFIG_ARCH_KIRKWOOD) += kirkwood-km_kirkwood.dtb
+dtb-$(CONFIG_ARCH_KIRKWOOD) += kirkwood-lschlv2.dtb
+dtb-$(CONFIG_ARCH_KIRKWOOD) += kirkwood-lsxhl.dtb
+dtb-$(CONFIG_ARCH_KIRKWOOD) += kirkwood-mplcec4.dtb
+dtb-$(CONFIG_ARCH_KIRKWOOD) += kirkwood-ns2.dtb
+dtb-$(CONFIG_ARCH_KIRKWOOD) += kirkwood-ns2lite.dtb
+dtb-$(CONFIG_ARCH_KIRKWOOD) += kirkwood-ns2max.dtb
+dtb-$(CONFIG_ARCH_KIRKWOOD) += kirkwood-ns2mini.dtb
+dtb-$(CONFIG_ARCH_KIRKWOOD) += kirkwood-nsa310.dtb
+dtb-$(CONFIG_ARCH_KIRKWOOD) += kirkwood-openblocks_a6.dtb
+dtb-$(CONFIG_ARCH_KIRKWOOD) += kirkwood-topkick.dtb
+dtb-$(CONFIG_ARCH_KIRKWOOD) += kirkwood-ts219-6281.dtb
+dtb-$(CONFIG_ARCH_KIRKWOOD) += kirkwood-ts219-6282.dtb
+
+# marco
+dtb-$(CONFIG_ARCH_MARCO) += marco-evb.dtb
+
+# msm
+dtb-$(CONFIG_ARCH_MSM) += msm8660-surf.dtb
+dtb-$(CONFIG_ARCH_MSM) += msm8960-cdp.dtb
+
+# mvebu
+# armada-370
+dtb-$(CONFIG_ARCH_MVEBU) += armada-370-db.dtb
+dtb-$(CONFIG_ARCH_MVEBU) += armada-370-mirabox.dtb
+dtb-$(CONFIG_ARCH_MVEBU) += armada-370-rd.dtb
+# armada-xp
+dtb-$(CONFIG_ARCH_MVEBU) += armada-xp-db.dtb
+dtb-$(CONFIG_ARCH_MVEBU) += armada-xp-gp.dtb
+dtb-$(CONFIG_ARCH_MVEBU) += armada-xp-openblocks-ax3-4.dtb
+
+# mxc
+# imx25
+dtb-$(CONFIG_ARCH_MXC) += imx25-karo-tx25.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx25-pdk.dtb
+# imx27
+dtb-$(CONFIG_ARCH_MXC) += imx27-apf27.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx27-pdk.dtb
+# imx31
+dtb-$(CONFIG_ARCH_MXC) += imx31-bug.dtb
+# imx51
+dtb-$(CONFIG_ARCH_MXC) += imx51-apf51.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx51-babbage.dtb
+# imx53
+dtb-$(CONFIG_ARCH_MXC) += imx53-ard.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx53-evk.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx53-mba53.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx53-qsb.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx53-smd.dtb
+# imx6q
+dtb-$(CONFIG_ARCH_MXC) += imx6q-arm2.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx6q-sabreauto.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx6q-sabrelite.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx6q-sabresd.dtb
+
+# mxs
+# imx23
+dtb-$(CONFIG_ARCH_MXS) += imx23-evk.dtb
+dtb-$(CONFIG_ARCH_MXS) += imx23-olinuxino.dtb
+dtb-$(CONFIG_ARCH_MXS) += imx23-stmp378x_devb.dtb
+# imx28
+dtb-$(CONFIG_ARCH_MXS) += imx28-apf28.dtb
+dtb-$(CONFIG_ARCH_MXS) += imx28-apf28dev.dtb
+dtb-$(CONFIG_ARCH_MXS) += imx28-apx4devkit.dtb
+dtb-$(CONFIG_ARCH_MXS) += imx28-cfa10036.dtb
+dtb-$(CONFIG_ARCH_MXS) += imx28-cfa10037.dtb
+dtb-$(CONFIG_ARCH_MXS) += imx28-cfa10049.dtb
+dtb-$(CONFIG_ARCH_MXS) += imx28-evk.dtb
+dtb-$(CONFIG_ARCH_MXS) += imx28-m28evk.dtb
+dtb-$(CONFIG_ARCH_MXS) += imx28-sps1.dtb
+dtb-$(CONFIG_ARCH_MXS) += imx28-tx28.dtb
+
+# nomdik
+dtb-$(CONFIG_ARCH_NOMADIK) += ste-nomadik-s8815.dtb
+
+# omap2plus
+# am335x
+dtb-$(CONFIG_ARCH_OMAP2PLUS) += am335x-bone.dtb
+dtb-$(CONFIG_ARCH_OMAP2PLUS) += am335x-evm.dtb
+dtb-$(CONFIG_ARCH_OMAP2PLUS) += am335x-evmsk.dtb
+# omap2
+dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb
+# omap3
+dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap3-beagle.dtb
+dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap3-beagle-xm.dtb
+dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap3-evm.dtb
+dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap3-tobi.dtb
+# omap4
+dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap4-panda.dtb
+dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap4-panda-a4.dtb
+dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap4-panda-es.dtb
+dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap4-sdp.dtb
+dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap4-var-som.dtb
+# omap5
+dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap5-evm.dtb
+
+# orion5x
+dtb-$(CONFIG_ARCH_ORION5X) += orion5x-lacie-ethernet-disk-mini-v2.dtb
+
+# prima2
+dtb-$(CONFIG_ARCH_PRIMA2) += prima2-evb.dtb
+
+# u8500
+dtb-$(CONFIG_ARCH_U8500) += ccu9540.dtb
+dtb-$(CONFIG_ARCH_U8500) += hrefprev60.dtb
+dtb-$(CONFIG_ARCH_U8500) += hrefv60plus.dtb
+dtb-$(CONFIG_ARCH_U8500) += snowball.dtb
+
+# shmobile
+dtb-$(CONFIG_ARCH_SHMOBILE) += emev2-kzm9d.dtb
+dtb-$(CONFIG_ARCH_SHMOBILE) += r8a7740-armadillo800eva.dtb
+dtb-$(CONFIG_ARCH_SHMOBILE) += sh73a0-kzm9g.dtb
+dtb-$(CONFIG_ARCH_SHMOBILE) += sh7372-mackerel.dtb
+
+# socfpga
+dtb-$(CONFIG_ARCH_SOCFPGA) += socfpga_cyclone5.dtb
+dtb-$(CONFIG_ARCH_SOCFPGA) += socfpga_vt.dtb
+
+# spear3xx
+dtb-$(CONFIG_ARCH_SPEAR3XX) += spear300-evb.dtb
+dtb-$(CONFIG_ARCH_SPEAR3XX) += spear310-evb.dtb
+dtb-$(CONFIG_ARCH_SPEAR3XX) += spear320-evb.dtb
+dtb-$(CONFIG_ARCH_SPEAR3XX) += spear320-hmi.dtb
+
+# spear6xx
+dtb-$(CONFIG_ARCH_SPEAR6XX) += spear600-evb.dtb
+
+# spear13xx
+dtb-$(CONFIG_ARCH_SPEAR13XX) += spear1310-evb.dtb
+dtb-$(CONFIG_ARCH_SPEAR13XX) += spear1340-evb.dtb
+
+# sunxi
+dtb-$(CONFIG_ARCH_SUNXI) += sun4i-a10-cubieboard.dtb
+dtb-$(CONFIG_ARCH_SUNXI) += sun4i-a10-hackberry.dtb
+dtb-$(CONFIG_ARCH_SUNXI) += sun5i-a13-olinuxino.dtb
+
+# tegra
+# tegra20
+dtb-$(CONFIG_ARCH_TEGRA) += tegra20-harmony.dtb
+dtb-$(CONFIG_ARCH_TEGRA) += tegra20-iris-512.dtb
+dtb-$(CONFIG_ARCH_TEGRA) += tegra20-medcom-wide.dtb
+dtb-$(CONFIG_ARCH_TEGRA) += tegra20-paz00.dtb
+dtb-$(CONFIG_ARCH_TEGRA) += tegra20-plutux.dtb
+dtb-$(CONFIG_ARCH_TEGRA) += tegra20-seaboard.dtb
+dtb-$(CONFIG_ARCH_TEGRA) += tegra20-tec.dtb
+dtb-$(CONFIG_ARCH_TEGRA) += tegra20-trimslice.dtb
+dtb-$(CONFIG_ARCH_TEGRA) += tegra20-ventana.dtb
+dtb-$(CONFIG_ARCH_TEGRA) += tegra20-whistler.dtb
+# tegra30
+dtb-$(CONFIG_ARCH_TEGRA) += tegra30-beaver.dtb
+dtb-$(CONFIG_ARCH_TEGRA) += tegra30-cardhu-a02.dtb
+dtb-$(CONFIG_ARCH_TEGRA) += tegra30-cardhu-a04.dtb
+# tegra114
+dtb-$(CONFIG_ARCH_TEGRA) += tegra114-dalmore.dtb
+dtb-$(CONFIG_ARCH_TEGRA) += tegra114-pluto.dtb
+
+# vexpress
+dtb-$(CONFIG_ARCH_VEXPRESS) += vexpress-v2p-ca5s.dtb
+dtb-$(CONFIG_ARCH_VEXPRESS) += vexpress-v2p-ca9.dtb
+dtb-$(CONFIG_ARCH_VEXPRESS) += vexpress-v2p-ca15-tc1.dtb
+dtb-$(CONFIG_ARCH_VEXPRESS) += vexpress-v2p-ca15_a7.dtb
+dtb-$(CONFIG_ARCH_VEXPRESS) += xenvm-4.2.dtb
+
+# vt8500
+dtb-$(CONFIG_ARCH_VT8500) += vt8500-bv07.dtb
+dtb-$(CONFIG_ARCH_VT8500) += wm8505-ref.dtb
+dtb-$(CONFIG_ARCH_VT8500) += wm8650-mid.dtb
+dtb-$(CONFIG_ARCH_VT8500) += wm8850-w70v2.dtb
+
+# zynq
+dtb-$(CONFIG_ARCH_ZYNQ) += zynq-zc702.dtb
+
+targets += dtbs
+targets += $(dtb-y)
+endif
+
+# *.dtb used to be generated in the directory above. Clean out the
+# old build results so people don't accidentally use them.
+dtbs: $(addprefix $(obj)/, $(dtb-y))
+	$(Q)rm -f $(obj)/../*.dtb
+
+clean-files := *.dtb
-- 
1.7.10.4



From nsekhar at ti.com  Wed Apr 10 05:27:11 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Wed, 10 Apr 2013 14:57:11 +0530
Subject: [PATCH 0/4] ARM: davinci: sparse warning fixes
Message-ID: <1365586035-26583-1-git-send-email-nsekhar@ti.com>

This patch series fixes some sparse errors/warnings
occurring in arch/arm/mach-davinci/*

Tested on DA850 EVM (boot and suspend-to-RAM test).

Sekhar Nori (4):
  ARM: davinci: da850 evm: fix const qualifier placement
  ARM: davinci: da8xx dt: make file local symbols static
  ARM: davinci: sram.c: fix incorrect type in assignment
  ARM: davinci: ensure global variables are declared

 arch/arm/mach-davinci/board-da850-evm.c |    4 ++--
 arch/arm/mach-davinci/da8xx-dt.c        |    4 ++--
 arch/arm/mach-davinci/pm.c              |    1 +
 arch/arm/mach-davinci/sram.c            |    4 ++--
 arch/arm/mach-davinci/usb.c             |    1 +
 5 files changed, 8 insertions(+), 6 deletions(-)

-- 
1.7.10.1



From nsekhar at ti.com  Wed Apr 10 05:27:14 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Wed, 10 Apr 2013 14:57:14 +0530
Subject: [PATCH 3/4] ARM: davinci: sram.c: fix incorrect type in assignment
In-Reply-To: <1365586035-26583-1-git-send-email-nsekhar@ti.com>
References: <1365586035-26583-1-git-send-email-nsekhar@ti.com>
Message-ID: <1365586035-26583-4-git-send-email-nsekhar@ti.com>

Fix missing __iomem attribute. This fixes the sparse warning:

  CHECK   arch/arm/mach-davinci/sram.c
arch/arm/mach-davinci/sram.c:75:8: warning: incorrect type in assignment (different address spaces)
arch/arm/mach-davinci/sram.c:75:8:    expected void *addr
arch/arm/mach-davinci/sram.c:75:8:    got void [noderef] <asn:2>*
arch/arm/mach-davinci/sram.c:81:12: warning: incorrect type in argument 1 (different address spaces)
arch/arm/mach-davinci/sram.c:81:12:    expected void volatile [noderef] <asn:2>*addr
arch/arm/mach-davinci/sram.c:81:12:    got void *addr

Signed-off-by: Sekhar Nori <nsekhar at ti.com>
---
 arch/arm/mach-davinci/sram.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-davinci/sram.c b/arch/arm/mach-davinci/sram.c
index c5f7ee5..f18928b 100644
--- a/arch/arm/mach-davinci/sram.c
+++ b/arch/arm/mach-davinci/sram.c
@@ -62,7 +62,7 @@ static int __init sram_init(void)
 	phys_addr_t phys = davinci_soc_info.sram_dma;
 	unsigned len = davinci_soc_info.sram_len;
 	int status = 0;
-	void *addr;
+	void __iomem *addr;
 
 	if (len) {
 		len = min_t(unsigned, len, SRAM_SIZE);
@@ -75,7 +75,7 @@ static int __init sram_init(void)
 		addr = ioremap(phys, len);
 		if (!addr)
 			return -ENOMEM;
-		status = gen_pool_add_virt(sram_pool, (unsigned)addr,
+		status = gen_pool_add_virt(sram_pool, (unsigned long) addr,
 					   phys, len, -1);
 		if (status < 0)
 			iounmap(addr);
-- 
1.7.10.1



From nsekhar at ti.com  Wed Apr 10 05:27:13 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Wed, 10 Apr 2013 14:57:13 +0530
Subject: [PATCH 2/4] ARM: davinci: da8xx dt: make file local symbols static
In-Reply-To: <1365586035-26583-1-git-send-email-nsekhar@ti.com>
References: <1365586035-26583-1-git-send-email-nsekhar@ti.com>
Message-ID: <1365586035-26583-3-git-send-email-nsekhar@ti.com>

Make some file-local functions static. This fixes the sparse
warnings:

  CHECK   arch/arm/mach-davinci/da8xx-dt.c
arch/arm/mach-davinci/da8xx-dt.c:23:13: warning: symbol 'da8xx_uart_clk_enable' was not declared. Should it be static?
arch/arm/mach-davinci/da8xx-dt.c:40:23: warning: symbol 'da850_auxdata_lookup' was not declared. Should it be static?

Signed-off-by: Sekhar Nori <nsekhar at ti.com>
---
 arch/arm/mach-davinci/da8xx-dt.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-davinci/da8xx-dt.c b/arch/arm/mach-davinci/da8xx-dt.c
index 6b7a0a2..57e14a8 100644
--- a/arch/arm/mach-davinci/da8xx-dt.c
+++ b/arch/arm/mach-davinci/da8xx-dt.c
@@ -20,7 +20,7 @@
 
 #define DA8XX_NUM_UARTS	3
 
-void __init da8xx_uart_clk_enable(void)
+static void __init da8xx_uart_clk_enable(void)
 {
 	int i;
 	for (i = 0; i < DA8XX_NUM_UARTS; i++)
@@ -37,7 +37,7 @@ static void __init da8xx_init_irq(void)
 	of_irq_init(da8xx_irq_match);
 }
 
-struct of_dev_auxdata da850_auxdata_lookup[] __initdata = {
+static struct of_dev_auxdata da850_auxdata_lookup[] __initdata = {
 	OF_DEV_AUXDATA("ti,davinci-i2c", 0x01c22000, "i2c_davinci.1", NULL),
 	OF_DEV_AUXDATA("ti,davinci-wdt", 0x01c21000, "watchdog", NULL),
 	{}
-- 
1.7.10.1



From nsekhar at ti.com  Wed Apr 10 05:27:12 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Wed, 10 Apr 2013 14:57:12 +0530
Subject: [PATCH 1/4] ARM: davinci: da850 evm: fix const qualifier placement
In-Reply-To: <1365586035-26583-1-git-send-email-nsekhar@ti.com>
References: <1365586035-26583-1-git-send-email-nsekhar@ti.com>
Message-ID: <1365586035-26583-2-git-send-email-nsekhar@ti.com>

const qualifier was misplaced in couple of definitions.
This fixes the sparse error:

  CHECK   arch/arm/mach-davinci/board-mityomapl138.c
arch/arm/mach-davinci/board-da850-evm.c:404:19: error: Just how const do you want this type to be?
arch/arm/mach-davinci/board-da850-evm.c:568:19: error: Just how const do you want this type to be?

Signed-off-by: Sekhar Nori <nsekhar at ti.com>
---
 arch/arm/mach-davinci/board-da850-evm.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c
index c2dfe06..1f597b3 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -401,7 +401,7 @@ enum da850_evm_ui_exp_pins {
 	DA850_EVM_UI_EXP_PB1,
 };
 
-static const char const *da850_evm_ui_exp[] = {
+static const char * const da850_evm_ui_exp[] = {
 	[DA850_EVM_UI_EXP_SEL_C]        = "sel_c",
 	[DA850_EVM_UI_EXP_SEL_B]        = "sel_b",
 	[DA850_EVM_UI_EXP_SEL_A]        = "sel_a",
@@ -565,7 +565,7 @@ enum da850_evm_bb_exp_pins {
 	DA850_EVM_BB_EXP_USER_SW8
 };
 
-static const char const *da850_evm_bb_exp[] = {
+static const char * const da850_evm_bb_exp[] = {
 	[DA850_EVM_BB_EXP_DEEP_SLEEP_EN]	= "deep_sleep_en",
 	[DA850_EVM_BB_EXP_SW_RST]		= "sw_rst",
 	[DA850_EVM_BB_EXP_TP_23]		= "tp_23",
-- 
1.7.10.1



From nsekhar at ti.com  Wed Apr 10 05:27:15 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Wed, 10 Apr 2013 14:57:15 +0530
Subject: [PATCH 4/4] ARM: davinci: ensure global variables are declared
In-Reply-To: <1365586035-26583-1-git-send-email-nsekhar@ti.com>
References: <1365586035-26583-1-git-send-email-nsekhar@ti.com>
Message-ID: <1365586035-26583-5-git-send-email-nsekhar@ti.com>

Fix the following sparse warnings by declaring relevant
global variables.

  CHECK   arch/arm/mach-davinci/usb.c
arch/arm/mach-davinci/usb.c:134:12: warning: symbol 'da8xx_register_usb20' was not declared. Should it be static?
arch/arm/mach-davinci/usb.c:169:12: warning: symbol 'da8xx_register_usb11' was not declared. Should it be static?

  CHECK   arch/arm/mach-davinci/pm.c
arch/arm/mach-davinci/pm.c:155:12: warning: symbol 'davinci_pm_init' was not declared. Should it be static?

Signed-off-by: Sekhar Nori <nsekhar at ti.com>
---
 arch/arm/mach-davinci/pm.c  |    1 +
 arch/arm/mach-davinci/usb.c |    1 +
 2 files changed, 2 insertions(+)

diff --git a/arch/arm/mach-davinci/pm.c b/arch/arm/mach-davinci/pm.c
index eb8360b..a508fe5 100644
--- a/arch/arm/mach-davinci/pm.c
+++ b/arch/arm/mach-davinci/pm.c
@@ -19,6 +19,7 @@
 #include <asm/delay.h>
 #include <asm/io.h>
 
+#include <mach/common.h>
 #include <mach/da8xx.h>
 #include <mach/sram.h>
 #include <mach/pm.h>
diff --git a/arch/arm/mach-davinci/usb.c b/arch/arm/mach-davinci/usb.c
index 34509ff..2b4c648 100644
--- a/arch/arm/mach-davinci/usb.c
+++ b/arch/arm/mach-davinci/usb.c
@@ -10,6 +10,7 @@
 #include <mach/common.h>
 #include <mach/irqs.h>
 #include <mach/cputype.h>
+#include <mach/da8xx.h>
 #include <linux/platform_data/usb-davinci.h>
 
 #define DAVINCI_USB_OTG_BASE	0x01c64000
-- 
1.7.10.1



From lee.jones at linaro.org  Wed Apr 10 05:34:12 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Wed, 10 Apr 2013 10:34:12 +0100
Subject: [PATCH 7/8] dmaengine: ste_dma40: Use the BIT macro to replace
 ugly '(1 << x)'s
In-Reply-To: <201304092112.56039.arnd@arndb.de>
References: <1365532783-27425-1-git-send-email-lee.jones@linaro.org>
 <1365532783-27425-7-git-send-email-lee.jones@linaro.org>
 <CAHLZz133b6kydVwh0_Cn2yg-Q_MeUF+Z-7+CMY7TkB7KK2ssAQ@mail.gmail.com>
 <201304092112.56039.arnd@arndb.de>
Message-ID: <20130410093412.GI25316@gmail.com>

On Tue, 09 Apr 2013, Arnd Bergmann wrote:

> On Tuesday 09 April 2013, Harvey Harrison wrote:
> > 
> > On Tue, Apr 9, 2013 at 11:39 AM, Lee Jones <lee.jones at linaro.org> wrote:
> > >
> > > The aim is to make the code that little more readable.
> > >
> > > Signed-off-by: Lee Jones <lee.jones at linaro.org>
> > > ---
> > 
> > >
> > >  #define MAX(a, b) (((a) < (b)) ? (b) : (a))
> > 
> > Not part of your patch, but probably a good idea to switch to the
> > generic MAX macro, this
> > one is evaluating its args twice.
> 
> Yes, good point. The macro is only used in one place, to compare
> two compile-time constant values, but we should define macros in
> drivers that are already provided by the kernel.

Okay, it looks like the generic implementation has brackets in it,
which isn't allowed for this particular usecase. I'll fix this one
instead.

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From omycle at gmail.com  Wed Apr 10 05:35:00 2013
From: omycle at gmail.com (Li Haifeng)
Date: Wed, 10 Apr 2013 17:35:00 +0800
Subject: Kexec couldn't reboot capture kernel on pandaboard ES with OMAP4460
Message-ID: <CAFNq8R5FFUyH+JgjoGc5ctgEfiLvxzi7fzawM7+wFX5nEyTv-w@mail.gmail.com>

Hi, everyone.

Recently, I try to run kdump on pandaboard ES with omap4460. After
load capture kernel by "kexec -l" and execute "kexec -e", the serial
port output "Starting new kernel" and "Bye", then the system hangs up.

I have tried the upstream Linux Kernel v3.4 and v3.8. All are with this issue.

Could you tell my why and how to solve this issue?

Thanks very much.


From sebastian.hesselbarth at gmail.com  Wed Apr 10 05:40:10 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Wed, 10 Apr 2013 11:40:10 +0200
Subject: [PATCH v7] clk: add si5351 i2c common clock driver
In-Reply-To: <1365439617-18816-1-git-send-email-sebastian.hesselbarth@gmail.com>
References: <1365439617-18816-1-git-send-email-sebastian.hesselbarth@gmail.com>
Message-ID: <1365586810-6752-1-git-send-email-sebastian.hesselbarth@gmail.com>

This patch adds a common clock driver for Silicon Labs Si5351a/b/c
i2c programmable clock generators. Currently, the driver does not
support VXCO feature of si5351b. Passing platform_data or DT bindings
selectively allows to overwrite stored Si5351 configuration which is
very helpful for clock generators with empty eeprom configuration.
Corresponding device tree binding documentation is also added.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
---
I consider this v7 now as feature complete. Please review/test a
hopefully last time and add your Acked-By/Tested-By. Thanks!

Changes from v6:
- make invalid DT data parsing fatal (Suggested by Guenter Roeck)
- add more variant checks and return errors
- remove inline from _si5351_* functions
- remove pll reset/clkout powerdown for gapless tuning
  (Provided by Michal Backraty)

Changes from v5:
- removed __clk_set_flags
- remove CONFIG_OF dependency
- introduce si5351_platform_data (non-DT untested)
- parse DT into si5351_platform_data (tested)
- minor cleanups

Changes from v4:
- move from clk-private.h to clk-provider.h (Reported by Mike Turquette)
- use __clk_set_flags() helper

Changes from v3:
- add silabs prefix to custom DT properties (Reported by Lars-Peter Clausen)
- use sizeof(*foo) instead of sizeof(struct bar) (Reported by Lars-Peter Clausen)
- check return value of of_clk_add_provider (Reported by Lars-Peter Clausen)
- clean up i2c client init (Reported by Lars-Peter Clausen)
- silence successful probe (Suggested by Lars-Peter Clausen)
- make CONFIG_CLK_SI5351 depend on CONFIG_OF

Changes from v2:
- add curly brackets to if-else-statements (Reported by Daniel Mack)
- fix div-by-zero for clk6/clk7 (Reported by Daniel Mack)
- fix parameter address calculation for clk6/clk7

Changes from v1:
- remove .is_enabled functions as they read from i2c
  (Reported by Daniel Mack)
- add CLK_SET_RATE_PARENT on clkout reparent if clkout uses
  its own multisync

Cc: Grant Likely <grant.likely at secretlab.ca>
Cc: Rob Herring <rob.herring at calxeda.com>
Cc: Rob Landley <rob at landley.net>
Cc: Mike Turquette <mturquette at linaro.org>
Cc: Stephen Warren <swarren at nvidia.com>
Cc: Thierry Reding <thierry.reding at avionic-design.de>
Cc: Dom Cobley <popcornmix at gmail.com>
Cc: Linus Walleij <linus.walleij at linaro.org>
Cc: Arnd Bergmann <arnd at arndb.de>
Cc: Andrew Morton <akpm at linux-foundation.org>
Cc: Pawel Moll <pawel.moll at arm.com>
Cc: Mark Brown <broonie at opensource.wolfsonmicro.com>
Cc: Russell King - ARM Linux <linux at arm.linux.org.uk>
Cc: Rabeeh Khoury <rabeeh at solid-run.com>
Cc: Daniel Mack <zonque at gmail.com>
Cc: Jean-Francois Moine <moinejf at free.fr>
Cc: Lars-Peter Clausen <lars at metafoo.de>
Cc: Guenter Roeck <linux at roeck-us.net>
Cc: Michal Bachraty <michal.bachraty at streamunlimited.com>
Cc: devicetree-discuss at lists.ozlabs.org
Cc: linux-doc at vger.kernel.org
Cc: linux-kernel at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
---
 .../devicetree/bindings/clock/silabs,si5351.txt    |  114 ++
 .../devicetree/bindings/vendor-prefixes.txt        |    1 +
 drivers/clk/Kconfig                                |    9 +
 drivers/clk/Makefile                               |    1 +
 drivers/clk/clk-si5351.c                           | 1506 ++++++++++++++++++++
 drivers/clk/clk-si5351.h                           |  155 ++
 include/linux/platform_data/si5351.h               |  114 ++
 7 files changed, 1900 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/silabs,si5351.txt
 create mode 100644 drivers/clk/clk-si5351.c
 create mode 100644 drivers/clk/clk-si5351.h
 create mode 100644 include/linux/platform_data/si5351.h

diff --git a/Documentation/devicetree/bindings/clock/silabs,si5351.txt b/Documentation/devicetree/bindings/clock/silabs,si5351.txt
new file mode 100644
index 0000000..cc37465
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/silabs,si5351.txt
@@ -0,0 +1,114 @@
+Binding for Silicon Labs Si5351a/b/c programmable i2c clock generator.
+
+Reference
+[1] Si5351A/B/C Data Sheet
+    http://www.silabs.com/Support%20Documents/TechnicalDocs/Si5351.pdf
+
+The Si5351a/b/c are programmable i2c clock generators with upto 8 output
+clocks. Si5351a also has a reduced pin-count package (MSOP10) where only
+3 output clocks are accessible. The internal structure of the clock
+generators can be found in [1].
+
+==I2C device node==
+
+Required properties:
+- compatible: shall be one of "silabs,si5351{a,a-msop,b,c}".
+- reg: i2c device address, shall be 0x60 or 0x61.
+- #clock-cells: from common clock binding; shall be set to 1.
+- clocks: from common clock binding; list of parent clock
+  handles, shall be xtal reference clock or xtal and clkin for
+  si5351c only.
+- #address-cells: shall be set to 1.
+- #size-cells: shall be set to 0.
+
+Optional properties:
+- silabs,pll-source: pair of (number, source) for each pll. Allows
+  to overwrite clock source of pll A (number=0) or B (number=1).
+
+==Child nodes==
+
+Each of the clock outputs can be overwritten individually by
+using a child node to the I2C device node. If a child node for a clock
+output is not set, the eeprom configuration is not overwritten.
+
+Required child node properties:
+- reg: number of clock output.
+
+Optional child node properties:
+- silabs,clock-source: source clock of the output divider stage N, shall be
+  0 = multisynth N
+  1 = multisynth 0 for output clocks 0-3, else multisynth4
+  2 = xtal
+  3 = clkin (si5351c only)
+- silabs,drive-strength: output drive strength in mA, shall be one of {2,4,6,8}.
+- silabs,multisynth-source: source pll A(0) or B(1) of corresponding multisynth
+  divider.
+- silabs,pll-master: boolean, multisynth can change pll frequency.
+
+==Example==
+
+/* 25MHz reference crystal */
+ref25: ref25M {
+	compatible = "fixed-clock";
+	#clock-cells = <0>;
+	clock-frequency = <25000000>;
+};
+
+i2c-master-node {
+
+	/* Si5351a msop10 i2c clock generator */
+	si5351a: clock-generator at 60 {
+		compatible = "silabs,si5351a-msop";
+		reg = <0x60>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		#clock-cells = <1>;
+
+		/* connect xtal input to 25MHz reference */
+		clocks = <&ref25>;
+
+		/* connect xtal input as source of pll0 and pll1 */
+		silabs,pll-source = <0 0>, <1 0>;
+
+		/*
+		 * overwrite clkout0 configuration with:
+		 * - 8mA output drive strength
+		 * - pll0 as clock source of multisynth0
+		 * - multisynth0 as clock source of output divider
+		 * - multisynth0 can change pll0
+		 * - set initial clock frequency of 74.25MHz
+		 */
+		clkout0 {
+			reg = <0>;
+			silabs,drive-strength = <8>;
+			silabs,multisynth-source = <0>;
+			silabs,clock-source = <0>;
+			silabs,pll-master;
+			clock-frequency = <74250000>;
+		};
+
+		/*
+		 * overwrite clkout1 configuration with:
+		 * - 4mA output drive strength
+		 * - pll1 as clock source of multisynth1
+		 * - multisynth1 as clock source of output divider
+		 * - multisynth1 can change pll1
+		 */
+		clkout1 {
+			reg = <1>;
+			silabs,drive-strength = <4>;
+			silabs,multisynth-source = <1>;
+			silabs,clock-source = <0>;
+			pll-master;
+		};
+
+		/*
+		 * overwrite clkout2 configuration with:
+		 * - xtal as clock source of output divider
+		 */
+		clkout2 {
+			reg = <2>;
+			silabs,clock-source = <2>;
+		};
+	};
+};
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 19e1ef7..ca60849 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -48,6 +48,7 @@ samsung	Samsung Semiconductor
 sbs	Smart Battery System
 schindler	Schindler
 sil	Silicon Image
+silabs	Silicon Laboratories
 simtek
 sirf	SiRF Technology, Inc.
 snps 	Synopsys, Inc.
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index a47e6ee..5039e41 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -55,6 +55,15 @@ config COMMON_CLK_MAX77686
 	---help---
 	  This driver supports Maxim 77686 crystal oscillator clock. 
 
+config COMMON_CLK_SI5351
+	tristate "Clock driver for SiLabs 5351A/B/C"
+	depends on I2C
+	select REGMAP_I2C
+	select RATIONAL
+	---help---
+	  This driver supports Silicon Labs 5351A/B/C programmable clock
+	  generators.
+
 config CLK_TWL6040
 	tristate "External McPDM functional clock from twl6040"
 	depends on TWL6040_CORE
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 300d477..92ca698 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -33,4 +33,5 @@ obj-$(CONFIG_X86)		+= x86/
 # Chip specific
 obj-$(CONFIG_COMMON_CLK_WM831X) += clk-wm831x.o
 obj-$(CONFIG_COMMON_CLK_MAX77686) += clk-max77686.o
+obj-$(CONFIG_COMMON_CLK_SI5351) += clk-si5351.o
 obj-$(CONFIG_CLK_TWL6040)	+= clk-twl6040.o
diff --git a/drivers/clk/clk-si5351.c b/drivers/clk/clk-si5351.c
new file mode 100644
index 0000000..4e2506c
--- /dev/null
+++ b/drivers/clk/clk-si5351.c
@@ -0,0 +1,1506 @@
+/*
+ * clk-si5351.c: Silicon Laboratories Si5351A/B/C I2C Clock Generator
+ *
+ * Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
+ * Rabeeh Khoury <rabeeh at solid-run.com>
+ *
+ * References:
+ * [1] "Si5351A/B/C Data Sheet"
+ *     http://www.silabs.com/Support%20Documents/TechnicalDocs/Si5351.pdf
+ * [2] "Manually Generating an Si5351 Register Map"
+ *     http://www.silabs.com/Support%20Documents/TechnicalDocs/AN619.pdf
+ *
+ * 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.
+ */
+
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/clkdev.h>
+#include <linux/clk-provider.h>
+#include <linux/delay.h>
+#include <linux/err.h>
+#include <linux/errno.h>
+#include <linux/rational.h>
+#include <linux/i2c.h>
+#include <linux/of_platform.h>
+#include <linux/platform_data/si5351.h>
+#include <linux/regmap.h>
+#include <linux/slab.h>
+#include <linux/string.h>
+#include <asm/div64.h>
+
+#include "clk-si5351.h"
+
+struct si5351_driver_data;
+
+struct si5351_parameters {
+	unsigned long	p1;
+	unsigned long	p2;
+	unsigned long	p3;
+	int		valid;
+};
+
+struct si5351_hw_data {
+	struct clk_hw			hw;
+	struct si5351_driver_data	*drvdata;
+	struct si5351_parameters	params;
+	unsigned char			num;
+};
+
+struct si5351_driver_data {
+	enum si5351_variant	variant;
+	struct i2c_client	*client;
+	struct regmap		*regmap;
+	struct clk_onecell_data onecell;
+
+	struct clk		*pxtal;
+	const char		*pxtal_name;
+	struct clk_hw		xtal;
+	struct clk		*pclkin;
+	const char		*pclkin_name;
+	struct clk_hw		clkin;
+
+	struct si5351_hw_data	pll[2];
+	struct si5351_hw_data	*msynth;
+	struct si5351_hw_data	*clkout;
+};
+
+static const char const *si5351_input_names[] = {
+	"xtal", "clkin"
+};
+static const char const *si5351_pll_names[] = {
+	"plla", "pllb", "vxco"
+};
+static const char const *si5351_msynth_names[] = {
+	"ms0", "ms1", "ms2", "ms3", "ms4", "ms5", "ms6", "ms7"
+};
+static const char const *si5351_clkout_names[] = {
+	"clk0", "clk1", "clk2", "clk3", "clk4", "clk5", "clk6", "clk7"
+};
+
+/*
+ * Si5351 i2c regmap
+ */
+static inline u8 si5351_reg_read(struct si5351_driver_data *drvdata, u8 reg)
+{
+	u32 val;
+	int ret;
+
+	ret = regmap_read(drvdata->regmap, reg, &val);
+	if (ret) {
+		dev_err(&drvdata->client->dev,
+			"unable to read from reg%02x\n", reg);
+		return 0;
+	}
+
+	return (u8)val;
+}
+
+static inline int si5351_bulk_read(struct si5351_driver_data *drvdata,
+				   u8 reg, u8 count, u8 *buf)
+{
+	return regmap_bulk_read(drvdata->regmap, reg, buf, count);
+}
+
+static inline int si5351_reg_write(struct si5351_driver_data *drvdata,
+				   u8 reg, u8 val)
+{
+	return regmap_write(drvdata->regmap, reg, val);
+}
+
+static inline int si5351_bulk_write(struct si5351_driver_data *drvdata,
+				    u8 reg, u8 count, const u8 *buf)
+{
+	return regmap_raw_write(drvdata->regmap, reg, buf, count);
+}
+
+static inline int si5351_set_bits(struct si5351_driver_data *drvdata,
+				  u8 reg, u8 mask, u8 val)
+{
+	return regmap_update_bits(drvdata->regmap, reg, mask, val);
+}
+
+static inline u8 si5351_msynth_params_address(int num)
+{
+	if (num > 5)
+		return SI5351_CLK6_PARAMETERS + (num - 6);
+	return SI5351_CLK0_PARAMETERS + (SI5351_PARAMETERS_LENGTH * num);
+}
+
+static void si5351_read_parameters(struct si5351_driver_data *drvdata,
+				   u8 reg, struct si5351_parameters *params)
+{
+	u8 buf[SI5351_PARAMETERS_LENGTH];
+
+	switch (reg) {
+	case SI5351_CLK6_PARAMETERS:
+	case SI5351_CLK7_PARAMETERS:
+		buf[0] = si5351_reg_read(drvdata, reg);
+		params->p1 = buf[0];
+		params->p2 = 0;
+		params->p3 = 1;
+		break;
+	default:
+		si5351_bulk_read(drvdata, reg, SI5351_PARAMETERS_LENGTH, buf);
+		params->p1 = ((buf[2] & 0x03) << 16) | (buf[3] << 8) | buf[4];
+		params->p2 = ((buf[5] & 0x0f) << 16) | (buf[6] << 8) | buf[7];
+		params->p3 = ((buf[5] & 0xf0) << 12) | (buf[0] << 8) | buf[1];
+	}
+	params->valid = 1;
+}
+
+static void si5351_write_parameters(struct si5351_driver_data *drvdata,
+				    u8 reg, struct si5351_parameters *params)
+{
+	u8 buf[SI5351_PARAMETERS_LENGTH];
+
+	switch (reg) {
+	case SI5351_CLK6_PARAMETERS:
+	case SI5351_CLK7_PARAMETERS:
+		buf[0] = params->p1 & 0xff;
+		si5351_reg_write(drvdata, reg, buf[0]);
+		break;
+	default:
+		buf[0] = ((params->p3 & 0x0ff00) >> 8) & 0xff;
+		buf[1] = params->p3 & 0xff;
+		/* save rdiv and divby4 */
+		buf[2] = si5351_reg_read(drvdata, reg + 2) & ~0x03;
+		buf[2] |= ((params->p1 & 0x30000) >> 16) & 0x03;
+		buf[3] = ((params->p1 & 0x0ff00) >> 8) & 0xff;
+		buf[4] = params->p1 & 0xff;
+		buf[5] = ((params->p3 & 0xf0000) >> 12) |
+			((params->p2 & 0xf0000) >> 16);
+		buf[6] = ((params->p2 & 0x0ff00) >> 8) & 0xff;
+		buf[7] = params->p2 & 0xff;
+		si5351_bulk_write(drvdata, reg, SI5351_PARAMETERS_LENGTH, buf);
+	}
+}
+
+static bool si5351_regmap_is_volatile(struct device *dev, unsigned int reg)
+{
+	switch (reg) {
+	case SI5351_DEVICE_STATUS:
+	case SI5351_INTERRUPT_STATUS:
+	case SI5351_PLL_RESET:
+		return true;
+	}
+	return false;
+}
+
+static bool si5351_regmap_is_writeable(struct device *dev, unsigned int reg)
+{
+	/* reserved registers */
+	if (reg >= 4 && reg <= 8)
+		return false;
+	if (reg >= 10 && reg <= 14)
+		return false;
+	if (reg >= 173 && reg <= 176)
+		return false;
+	if (reg >= 178 && reg <= 182)
+		return false;
+	/* read-only */
+	if (reg == SI5351_DEVICE_STATUS)
+		return false;
+	return true;
+}
+
+static struct regmap_config si5351_regmap_config = {
+	.reg_bits = 8,
+	.val_bits = 8,
+	.cache_type = REGCACHE_RBTREE,
+	.max_register = 187,
+	.writeable_reg = si5351_regmap_is_writeable,
+	.volatile_reg = si5351_regmap_is_volatile,
+};
+
+/*
+ * Si5351 xtal clock input
+ */
+static int si5351_xtal_prepare(struct clk_hw *hw)
+{
+	struct si5351_driver_data *drvdata =
+		container_of(hw, struct si5351_driver_data, xtal);
+	si5351_set_bits(drvdata, SI5351_FANOUT_ENABLE,
+			SI5351_XTAL_ENABLE, SI5351_XTAL_ENABLE);
+	return 0;
+}
+
+static void si5351_xtal_unprepare(struct clk_hw *hw)
+{
+	struct si5351_driver_data *drvdata =
+		container_of(hw, struct si5351_driver_data, xtal);
+	si5351_set_bits(drvdata, SI5351_FANOUT_ENABLE,
+			SI5351_XTAL_ENABLE, 0);
+}
+
+static const struct clk_ops si5351_xtal_ops = {
+	.prepare = si5351_xtal_prepare,
+	.unprepare = si5351_xtal_unprepare,
+};
+
+/*
+ * Si5351 clkin clock input (Si5351C only)
+ */
+static int si5351_clkin_prepare(struct clk_hw *hw)
+{
+	struct si5351_driver_data *drvdata =
+		container_of(hw, struct si5351_driver_data, clkin);
+	si5351_set_bits(drvdata, SI5351_FANOUT_ENABLE,
+			SI5351_CLKIN_ENABLE, SI5351_CLKIN_ENABLE);
+	return 0;
+}
+
+static void si5351_clkin_unprepare(struct clk_hw *hw)
+{
+	struct si5351_driver_data *drvdata =
+		container_of(hw, struct si5351_driver_data, clkin);
+	si5351_set_bits(drvdata, SI5351_FANOUT_ENABLE,
+			SI5351_CLKIN_ENABLE, 0);
+}
+
+/*
+ * CMOS clock source constraints:
+ * The input frequency range of the PLL is 10Mhz to 40MHz.
+ * If CLKIN is >40MHz, the input divider must be used.
+ */
+static unsigned long si5351_clkin_recalc_rate(struct clk_hw *hw,
+					      unsigned long parent_rate)
+{
+	struct si5351_driver_data *drvdata =
+		container_of(hw, struct si5351_driver_data, clkin);
+	unsigned long rate;
+	unsigned char idiv;
+
+	rate = parent_rate;
+	if (parent_rate > 160000000) {
+		idiv = SI5351_CLKIN_DIV_8;
+		rate /= 8;
+	} else if (parent_rate > 80000000) {
+		idiv = SI5351_CLKIN_DIV_4;
+		rate /= 4;
+	} else if (parent_rate > 40000000) {
+		idiv = SI5351_CLKIN_DIV_2;
+		rate /= 2;
+	} else {
+		idiv = SI5351_CLKIN_DIV_1;
+	}
+
+	si5351_set_bits(drvdata, SI5351_PLL_INPUT_SOURCE,
+			SI5351_CLKIN_DIV_MASK, idiv);
+
+	dev_dbg(&drvdata->client->dev, "%s - clkin div = %d, rate = %lu\n",
+		__func__, (1 << (idiv >> 6)), rate);
+
+	return rate;
+}
+
+static const struct clk_ops si5351_clkin_ops = {
+	.prepare = si5351_clkin_prepare,
+	.unprepare = si5351_clkin_unprepare,
+	.recalc_rate = si5351_clkin_recalc_rate,
+};
+
+/*
+ * Si5351 vxco clock input (Si5351B only)
+ */
+
+static int si5351_vxco_prepare(struct clk_hw *hw)
+{
+	struct si5351_hw_data *hwdata =
+		container_of(hw, struct si5351_hw_data, hw);
+
+	dev_warn(&hwdata->drvdata->client->dev, "VXCO currently unsupported\n");
+
+	return 0;
+}
+
+static void si5351_vxco_unprepare(struct clk_hw *hw)
+{
+}
+
+static unsigned long si5351_vxco_recalc_rate(struct clk_hw *hw,
+					     unsigned long parent_rate)
+{
+	return 0;
+}
+
+static int si5351_vxco_set_rate(struct clk_hw *hw, unsigned long rate,
+				unsigned long parent)
+{
+	return 0;
+}
+
+static const struct clk_ops si5351_vxco_ops = {
+	.prepare = si5351_vxco_prepare,
+	.unprepare = si5351_vxco_unprepare,
+	.recalc_rate = si5351_vxco_recalc_rate,
+	.set_rate = si5351_vxco_set_rate,
+};
+
+/*
+ * Si5351 pll a/b
+ *
+ * Feedback Multisynth Divider Equations [2]
+ *
+ * fVCO = fIN * (a + b/c)
+ *
+ * with 15 + 0/1048575 <= (a + b/c) <= 90 + 0/1048575 and
+ * fIN = fXTAL or fIN = fCLKIN/CLKIN_DIV
+ *
+ * Feedback Multisynth Register Equations
+ *
+ * (1) MSNx_P1[17:0] = 128 * a + floor(128 * b/c) - 512
+ * (2) MSNx_P2[19:0] = 128 * b - c * floor(128 * b/c) = (128*b) mod c
+ * (3) MSNx_P3[19:0] = c
+ *
+ * Transposing (2) yields: (4) floor(128 * b/c) = (128 * b / MSNx_P2)/c
+ *
+ * Using (4) on (1) yields:
+ * MSNx_P1 = 128 * a + (128 * b/MSNx_P2)/c - 512
+ * MSNx_P1 + 512 + MSNx_P2/c = 128 * a + 128 * b/c
+ *
+ * a + b/c = (MSNx_P1 + MSNx_P2/MSNx_P3 + 512)/128
+ *         = (MSNx_P1*MSNx_P3 + MSNx_P2 + 512*MSNx_P3)/(128*MSNx_P3)
+ *
+ */
+static int _si5351_pll_reparent(struct si5351_driver_data *drvdata,
+				int num, enum si5351_pll_src parent)
+{
+	u8 mask = (num == 0) ? SI5351_PLLA_SOURCE : SI5351_PLLB_SOURCE;
+
+	if (parent == SI5351_PLL_SRC_DEFAULT)
+		return 0;
+
+	if (num > 2)
+		return -EINVAL;
+
+	if (drvdata->variant != SI5351_VARIANT_C &&
+	    parent != SI5351_PLL_SRC_XTAL)
+		return -EINVAL;
+
+	si5351_set_bits(drvdata, SI5351_PLL_INPUT_SOURCE, mask,
+			(parent == SI5351_PLL_SRC_XTAL) ? 0 : mask);
+	return 0;
+}
+
+static unsigned char si5351_pll_get_parent(struct clk_hw *hw)
+{
+	struct si5351_hw_data *hwdata =
+		container_of(hw, struct si5351_hw_data, hw);
+	u8 mask = (hwdata->num == 0) ? SI5351_PLLA_SOURCE : SI5351_PLLB_SOURCE;
+	u8 val;
+
+	val = si5351_reg_read(hwdata->drvdata, SI5351_PLL_INPUT_SOURCE);
+
+	return (val & mask) ? 1 : 0;
+}
+
+static int si5351_pll_set_parent(struct clk_hw *hw, u8 index)
+{
+	struct si5351_hw_data *hwdata =
+		container_of(hw, struct si5351_hw_data, hw);
+
+	if (hwdata->drvdata->variant != SI5351_VARIANT_C &&
+	    index > 0)
+		return -EPERM;
+
+	if (index > 1)
+		return -EINVAL;
+
+	return _si5351_pll_reparent(hwdata->drvdata, hwdata->num,
+			     (index == 0) ? SI5351_PLL_SRC_XTAL :
+			     SI5351_PLL_SRC_CLKIN);
+}
+
+static unsigned long si5351_pll_recalc_rate(struct clk_hw *hw,
+					    unsigned long parent_rate)
+{
+	struct si5351_hw_data *hwdata =
+		container_of(hw, struct si5351_hw_data, hw);
+	u8 reg = (hwdata->num == 0) ? SI5351_PLLA_PARAMETERS :
+		SI5351_PLLB_PARAMETERS;
+	unsigned long long rate;
+
+	if (!hwdata->params.valid)
+		si5351_read_parameters(hwdata->drvdata, reg, &hwdata->params);
+
+	if (hwdata->params.p3 == 0)
+		return parent_rate;
+
+	/* fVCO = fIN * (P1*P3 + 512*P3 + P2)/(128*P3) */
+	rate  = hwdata->params.p1 * hwdata->params.p3;
+	rate += 512 * hwdata->params.p3;
+	rate += hwdata->params.p2;
+	rate *= parent_rate;
+	do_div(rate, 128 * hwdata->params.p3);
+
+	dev_dbg(&hwdata->drvdata->client->dev,
+		"%s - %s: p1 = %lu, p2 = %lu, p3 = %lu, parent_rate = %lu, rate = %lu\n",
+		__func__, __clk_get_name(hwdata->hw.clk),
+		hwdata->params.p1, hwdata->params.p2, hwdata->params.p3,
+		parent_rate, (unsigned long)rate);
+
+	return (unsigned long)rate;
+}
+
+static long si5351_pll_round_rate(struct clk_hw *hw, unsigned long rate,
+				  unsigned long *parent_rate)
+{
+	struct si5351_hw_data *hwdata =
+		container_of(hw, struct si5351_hw_data, hw);
+	unsigned long rfrac, denom, a, b, c;
+	unsigned long long lltmp;
+
+	if (rate < SI5351_PLL_VCO_MIN)
+		rate = SI5351_PLL_VCO_MIN;
+	if (rate > SI5351_PLL_VCO_MAX)
+		rate = SI5351_PLL_VCO_MAX;
+
+	/* determine integer part of feedback equation */
+	a = rate / *parent_rate;
+
+	if (a < SI5351_PLL_A_MIN)
+		rate = *parent_rate * SI5351_PLL_A_MIN;
+	if (a > SI5351_PLL_A_MAX)
+		rate = *parent_rate * SI5351_PLL_A_MAX;
+
+	/* find best approximation for b/c = fVCO mod fIN */
+	denom = 1000 * 1000;
+	lltmp = rate % (*parent_rate);
+	lltmp *= denom;
+	do_div(lltmp, *parent_rate);
+	rfrac = (unsigned long)lltmp;
+
+	b = 0;
+	c = 1;
+	if (rfrac)
+		rational_best_approximation(rfrac, denom,
+				    SI5351_PLL_B_MAX, SI5351_PLL_C_MAX, &b, &c);
+
+	/* calculate parameters */
+	hwdata->params.p3  = c;
+	hwdata->params.p2  = (128 * b) % c;
+	hwdata->params.p1  = 128 * a;
+	hwdata->params.p1 += (128 * b / c);
+	hwdata->params.p1 -= 512;
+
+	/* recalculate rate by fIN * (a + b/c) */
+	lltmp  = *parent_rate;
+	lltmp *= b;
+	do_div(lltmp, c);
+
+	rate  = (unsigned long)lltmp;
+	rate += *parent_rate * a;
+
+	dev_dbg(&hwdata->drvdata->client->dev,
+		"%s - %s: a = %lu, b = %lu, c = %lu, parent_rate = %lu, rate = %lu\n",
+		__func__, __clk_get_name(hwdata->hw.clk), a, b, c,
+		*parent_rate, rate);
+
+	return rate;
+}
+
+static int si5351_pll_set_rate(struct clk_hw *hw, unsigned long rate,
+			       unsigned long parent_rate)
+{
+	struct si5351_hw_data *hwdata =
+		container_of(hw, struct si5351_hw_data, hw);
+	u8 reg = (hwdata->num == 0) ? SI5351_PLLA_PARAMETERS :
+		SI5351_PLLB_PARAMETERS;
+
+	/* write multisynth parameters */
+	si5351_write_parameters(hwdata->drvdata, reg, &hwdata->params);
+
+	/* plla/pllb ctrl is in clk6/clk7 ctrl registers */
+	si5351_set_bits(hwdata->drvdata, SI5351_CLK6_CTRL + hwdata->num,
+		SI5351_CLK_INTEGER_MODE,
+		(hwdata->params.p2 == 0) ? SI5351_CLK_INTEGER_MODE : 0);
+
+	dev_dbg(&hwdata->drvdata->client->dev,
+		"%s - %s: p1 = %lu, p2 = %lu, p3 = %lu, parent_rate = %lu, rate = %lu\n",
+		__func__, __clk_get_name(hwdata->hw.clk),
+		hwdata->params.p1, hwdata->params.p2, hwdata->params.p3,
+		parent_rate, rate);
+
+	return 0;
+}
+
+static const struct clk_ops si5351_pll_ops = {
+	.set_parent = si5351_pll_set_parent,
+	.get_parent = si5351_pll_get_parent,
+	.recalc_rate = si5351_pll_recalc_rate,
+	.round_rate = si5351_pll_round_rate,
+	.set_rate = si5351_pll_set_rate,
+};
+
+/*
+ * Si5351 multisync divider
+ *
+ * for fOUT <= 150 MHz:
+ *
+ * fOUT = (fIN * (a + b/c)) / CLKOUTDIV
+ *
+ * with 6 + 0/1048575 <= (a + b/c) <= 1800 + 0/1048575 and
+ * fIN = fVCO0, fVCO1
+ *
+ * Output Clock Multisynth Register Equations
+ *
+ * MSx_P1[17:0] = 128 * a + floor(128 * b/c) - 512
+ * MSx_P2[19:0] = 128 * b - c * floor(128 * b/c) = (128*b) mod c
+ * MSx_P3[19:0] = c
+ *
+ * MS[6,7] are integer (P1) divide only, P2 = 0, P3 = 0
+ *
+ * for 150MHz < fOUT <= 160MHz:
+ *
+ * MSx_P1 = 0, MSx_P2 = 0, MSx_P3 = 1, MSx_INT = 1, MSx_DIVBY4 = 11b
+ */
+static int _si5351_msynth_reparent(struct si5351_driver_data *drvdata,
+				   int num, enum si5351_multisynth_src parent)
+{
+	if (parent == SI5351_MULTISYNTH_SRC_DEFAULT)
+		return 0;
+
+	if (num > 8)
+		return -EINVAL;
+
+	si5351_set_bits(drvdata, SI5351_CLK0_CTRL + num, SI5351_CLK_PLL_SELECT,
+			(parent == SI5351_MULTISYNTH_SRC_VCO0) ? 0 :
+			SI5351_CLK_PLL_SELECT);
+	return 0;
+}
+
+static unsigned char si5351_msynth_get_parent(struct clk_hw *hw)
+{
+	struct si5351_hw_data *hwdata =
+		container_of(hw, struct si5351_hw_data, hw);
+	u8 val;
+
+	val = si5351_reg_read(hwdata->drvdata, SI5351_CLK0_CTRL + hwdata->num);
+
+	return (val & SI5351_CLK_PLL_SELECT) ? 1 : 0;
+}
+
+static int si5351_msynth_set_parent(struct clk_hw *hw, u8 index)
+{
+	struct si5351_hw_data *hwdata =
+		container_of(hw, struct si5351_hw_data, hw);
+
+	return _si5351_msynth_reparent(hwdata->drvdata, hwdata->num,
+			       (index == 0) ? SI5351_MULTISYNTH_SRC_VCO0 :
+			       SI5351_MULTISYNTH_SRC_VCO1);
+}
+
+static unsigned long si5351_msynth_recalc_rate(struct clk_hw *hw,
+					       unsigned long parent_rate)
+{
+	struct si5351_hw_data *hwdata =
+		container_of(hw, struct si5351_hw_data, hw);
+	u8 reg = si5351_msynth_params_address(hwdata->num);
+	unsigned long long rate;
+	unsigned long m;
+
+	if (!hwdata->params.valid)
+		si5351_read_parameters(hwdata->drvdata, reg, &hwdata->params);
+
+	if (hwdata->params.p3 == 0)
+		return parent_rate;
+
+	/*
+	 * multisync0-5: fOUT = (128 * P3 * fIN) / (P1*P3 + P2 + 512*P3)
+	 * multisync6-7: fOUT = fIN / P1
+	 */
+	rate = parent_rate;
+	if (hwdata->num > 5) {
+		m = hwdata->params.p1;
+	} else if ((si5351_reg_read(hwdata->drvdata, reg + 2) &
+		    SI5351_OUTPUT_CLK_DIVBY4) == SI5351_OUTPUT_CLK_DIVBY4) {
+		m = 4;
+	} else {
+		rate *= 128 * hwdata->params.p3;
+		m = hwdata->params.p1 * hwdata->params.p3;
+		m += hwdata->params.p2;
+		m += 512 * hwdata->params.p3;
+	}
+
+	if (m == 0)
+		return 0;
+	do_div(rate, m);
+
+	dev_dbg(&hwdata->drvdata->client->dev,
+		"%s - %s: p1 = %lu, p2 = %lu, p3 = %lu, m = %lu, parent_rate = %lu, rate = %lu\n",
+		__func__, __clk_get_name(hwdata->hw.clk),
+		hwdata->params.p1, hwdata->params.p2, hwdata->params.p3,
+		m, parent_rate, (unsigned long)rate);
+
+	return (unsigned long)rate;
+}
+
+static long si5351_msynth_round_rate(struct clk_hw *hw, unsigned long rate,
+				     unsigned long *parent_rate)
+{
+	struct si5351_hw_data *hwdata =
+		container_of(hw, struct si5351_hw_data, hw);
+	unsigned long long lltmp;
+	unsigned long a, b, c;
+	int divby4;
+
+	/* multisync6-7 can only handle freqencies < 150MHz */
+	if (hwdata->num >= 6 && rate > SI5351_MULTISYNTH67_MAX_FREQ)
+		rate = SI5351_MULTISYNTH67_MAX_FREQ;
+
+	/* multisync frequency is 1MHz .. 160MHz */
+	if (rate > SI5351_MULTISYNTH_MAX_FREQ)
+		rate = SI5351_MULTISYNTH_MAX_FREQ;
+	if (rate < SI5351_MULTISYNTH_MIN_FREQ)
+		rate = SI5351_MULTISYNTH_MIN_FREQ;
+
+	divby4 = 0;
+	if (rate > SI5351_MULTISYNTH_DIVBY4_FREQ)
+		divby4 = 1;
+
+	/* multisync can set pll */
+	if (__clk_get_flags(hwdata->hw.clk) & CLK_SET_RATE_PARENT) {
+		/*
+		 * find largest integer divider for max
+		 * vco frequency and given target rate
+		 */
+		if (divby4 == 0) {
+			lltmp = SI5351_PLL_VCO_MAX;
+			do_div(lltmp, rate);
+			a = (unsigned long)lltmp;
+		} else
+			a = 4;
+
+		b = 0;
+		c = 1;
+
+		*parent_rate = a * rate;
+	} else {
+		unsigned long rfrac, denom;
+
+		/* disable divby4 */
+		if (divby4) {
+			rate = SI5351_MULTISYNTH_DIVBY4_FREQ;
+			divby4 = 0;
+		}
+
+		/* determine integer part of divider equation */
+		a = *parent_rate / rate;
+		if (a < SI5351_MULTISYNTH_A_MIN)
+			a = SI5351_MULTISYNTH_A_MIN;
+		if (hwdata->num >= 6 && a > SI5351_MULTISYNTH67_A_MAX)
+			a = SI5351_MULTISYNTH67_A_MAX;
+		else if (a > SI5351_MULTISYNTH_A_MAX)
+			a = SI5351_MULTISYNTH_A_MAX;
+
+		/* find best approximation for b/c = fVCO mod fOUT */
+		denom = 1000 * 1000;
+		lltmp = (*parent_rate) % rate;
+		lltmp *= denom;
+		do_div(lltmp, rate);
+		rfrac = (unsigned long)lltmp;
+
+		b = 0;
+		c = 1;
+		if (rfrac)
+			rational_best_approximation(rfrac, denom,
+			    SI5351_MULTISYNTH_B_MAX, SI5351_MULTISYNTH_C_MAX,
+			    &b, &c);
+	}
+
+	/* recalculate rate by fOUT = fIN / (a + b/c) */
+	lltmp  = *parent_rate;
+	lltmp *= c;
+	do_div(lltmp, a * c + b);
+	rate  = (unsigned long)lltmp;
+
+	/* calculate parameters */
+	if (divby4) {
+		hwdata->params.p3 = 1;
+		hwdata->params.p2 = 0;
+		hwdata->params.p1 = 0;
+	} else {
+		hwdata->params.p3  = c;
+		hwdata->params.p2  = (128 * b) % c;
+		hwdata->params.p1  = 128 * a;
+		hwdata->params.p1 += (128 * b / c);
+		hwdata->params.p1 -= 512;
+	}
+
+	dev_dbg(&hwdata->drvdata->client->dev,
+		"%s - %s: a = %lu, b = %lu, c = %lu, divby4 = %d, parent_rate = %lu, rate = %lu\n",
+		__func__, __clk_get_name(hwdata->hw.clk), a, b, c, divby4,
+		*parent_rate, rate);
+
+	return rate;
+}
+
+static int si5351_msynth_set_rate(struct clk_hw *hw, unsigned long rate,
+				  unsigned long parent_rate)
+{
+	struct si5351_hw_data *hwdata =
+		container_of(hw, struct si5351_hw_data, hw);
+	u8 reg = si5351_msynth_params_address(hwdata->num);
+	int divby4 = 0;
+
+	/* write multisynth parameters */
+	si5351_write_parameters(hwdata->drvdata, reg, &hwdata->params);
+
+	if (rate > SI5351_MULTISYNTH_DIVBY4_FREQ)
+		divby4 = 1;
+
+	/* enable/disable integer mode and divby4 on multisynth0-5 */
+	if (hwdata->num < 6) {
+		si5351_set_bits(hwdata->drvdata, reg + 2,
+				SI5351_OUTPUT_CLK_DIVBY4,
+				(divby4) ? SI5351_OUTPUT_CLK_DIVBY4 : 0);
+		si5351_set_bits(hwdata->drvdata, SI5351_CLK0_CTRL + hwdata->num,
+			SI5351_CLK_INTEGER_MODE,
+			(hwdata->params.p2 == 0) ? SI5351_CLK_INTEGER_MODE : 0);
+	}
+
+	dev_dbg(&hwdata->drvdata->client->dev,
+		"%s - %s: p1 = %lu, p2 = %lu, p3 = %lu, divby4 = %d, parent_rate = %lu, rate = %lu\n",
+		__func__, __clk_get_name(hwdata->hw.clk),
+		hwdata->params.p1, hwdata->params.p2, hwdata->params.p3,
+		divby4, parent_rate, rate);
+
+	return 0;
+}
+
+static const struct clk_ops si5351_msynth_ops = {
+	.set_parent = si5351_msynth_set_parent,
+	.get_parent = si5351_msynth_get_parent,
+	.recalc_rate = si5351_msynth_recalc_rate,
+	.round_rate = si5351_msynth_round_rate,
+	.set_rate = si5351_msynth_set_rate,
+};
+
+/*
+ * Si5351 clkout divider
+ */
+static int _si5351_clkout_reparent(struct si5351_driver_data *drvdata,
+				   int num, enum si5351_clkout_src parent)
+{
+	u8 val;
+
+	if (num > 8)
+		return -EINVAL;
+
+	switch (parent) {
+	case SI5351_CLKOUT_SRC_MSYNTH_N:
+		val = SI5351_CLK_INPUT_MULTISYNTH_N;
+		break;
+	case SI5351_CLKOUT_SRC_MSYNTH_0_4:
+		/* clk0/clk4 can only connect to its own multisync */
+		if (num == 0 || num == 4)
+			val = SI5351_CLK_INPUT_MULTISYNTH_N;
+		else
+			val = SI5351_CLK_INPUT_MULTISYNTH_0_4;
+		break;
+	case SI5351_CLKOUT_SRC_XTAL:
+		val = SI5351_CLK_INPUT_XTAL;
+		break;
+	case SI5351_CLKOUT_SRC_CLKIN:
+		if (drvdata->variant != SI5351_VARIANT_C)
+			return -EINVAL;
+
+		val = SI5351_CLK_INPUT_CLKIN;
+		break;
+	default:
+		return 0;
+	}
+
+	si5351_set_bits(drvdata, SI5351_CLK0_CTRL + num,
+			SI5351_CLK_INPUT_MASK, val);
+	return 0;
+}
+
+static int _si5351_clkout_set_drive_strength(
+	struct si5351_driver_data *drvdata, int num,
+	enum si5351_drive_strength drive)
+{
+	u8 mask;
+
+	if (num > 8)
+		return -EINVAL;
+
+	switch (drive) {
+	case SI5351_DRIVE_2MA:
+		mask = SI5351_CLK_DRIVE_STRENGTH_2MA;
+		break;
+	case SI5351_DRIVE_4MA:
+		mask = SI5351_CLK_DRIVE_STRENGTH_4MA;
+		break;
+	case SI5351_DRIVE_6MA:
+		mask = SI5351_CLK_DRIVE_STRENGTH_6MA;
+		break;
+	case SI5351_DRIVE_8MA:
+		mask = SI5351_CLK_DRIVE_STRENGTH_8MA;
+		break;
+	default:
+		return 0;
+	}
+
+	si5351_set_bits(drvdata, SI5351_CLK0_CTRL + num,
+			SI5351_CLK_DRIVE_STRENGTH_MASK, mask);
+	return 0;
+}
+
+static int si5351_clkout_prepare(struct clk_hw *hw)
+{
+	struct si5351_hw_data *hwdata =
+		container_of(hw, struct si5351_hw_data, hw);
+
+	si5351_set_bits(hwdata->drvdata, SI5351_CLK0_CTRL + hwdata->num,
+			SI5351_CLK_POWERDOWN, 0);
+	si5351_set_bits(hwdata->drvdata, SI5351_OUTPUT_ENABLE_CTRL,
+			(1 << hwdata->num), 0);
+	return 0;
+}
+
+static void si5351_clkout_unprepare(struct clk_hw *hw)
+{
+	struct si5351_hw_data *hwdata =
+		container_of(hw, struct si5351_hw_data, hw);
+
+	si5351_set_bits(hwdata->drvdata, SI5351_CLK0_CTRL + hwdata->num,
+			SI5351_CLK_POWERDOWN, SI5351_CLK_POWERDOWN);
+	si5351_set_bits(hwdata->drvdata, SI5351_OUTPUT_ENABLE_CTRL,
+			(1 << hwdata->num), (1 << hwdata->num));
+}
+
+static u8 si5351_clkout_get_parent(struct clk_hw *hw)
+{
+	struct si5351_hw_data *hwdata =
+		container_of(hw, struct si5351_hw_data, hw);
+	int index = 0;
+	unsigned char val;
+
+	val = si5351_reg_read(hwdata->drvdata, SI5351_CLK0_CTRL + hwdata->num);
+	switch (val & SI5351_CLK_INPUT_MASK) {
+	case SI5351_CLK_INPUT_MULTISYNTH_N:
+		index = 0;
+		break;
+	case SI5351_CLK_INPUT_MULTISYNTH_0_4:
+		index = 1;
+		break;
+	case SI5351_CLK_INPUT_XTAL:
+		index = 2;
+		break;
+	case SI5351_CLK_INPUT_CLKIN:
+		index = 3;
+		break;
+	}
+
+	return index;
+}
+
+static int si5351_clkout_set_parent(struct clk_hw *hw, u8 index)
+{
+	struct si5351_hw_data *hwdata =
+		container_of(hw, struct si5351_hw_data, hw);
+	enum si5351_clkout_src parent = SI5351_CLKOUT_SRC_DEFAULT;
+
+	switch (index) {
+	case 0:
+		parent = SI5351_CLKOUT_SRC_MSYNTH_N;
+		break;
+	case 1:
+		parent = SI5351_CLKOUT_SRC_MSYNTH_0_4;
+		break;
+	case 2:
+		parent = SI5351_CLKOUT_SRC_XTAL;
+		break;
+	case 3:
+		parent = SI5351_CLKOUT_SRC_CLKIN;
+		break;
+	}
+
+	return _si5351_clkout_reparent(hwdata->drvdata, hwdata->num, parent);
+}
+
+static unsigned long si5351_clkout_recalc_rate(struct clk_hw *hw,
+					       unsigned long parent_rate)
+{
+	struct si5351_hw_data *hwdata =
+		container_of(hw, struct si5351_hw_data, hw);
+	unsigned char reg;
+	unsigned char rdiv;
+
+	if (hwdata->num > 5)
+		reg = si5351_msynth_params_address(hwdata->num) + 2;
+	else
+		reg = SI5351_CLK6_7_OUTPUT_DIVIDER;
+
+	rdiv = si5351_reg_read(hwdata->drvdata, reg);
+	if (hwdata->num == 6) {
+		rdiv &= SI5351_OUTPUT_CLK6_DIV_MASK;
+	} else {
+		rdiv &= SI5351_OUTPUT_CLK_DIV_MASK;
+		rdiv >>= SI5351_OUTPUT_CLK_DIV_SHIFT;
+	}
+
+	return parent_rate >> rdiv;
+}
+
+static long si5351_clkout_round_rate(struct clk_hw *hw, unsigned long rate,
+				     unsigned long *parent_rate)
+{
+	struct si5351_hw_data *hwdata =
+		container_of(hw, struct si5351_hw_data, hw);
+	unsigned char rdiv;
+
+	/* clkout6/7 can only handle output freqencies < 150MHz */
+	if (hwdata->num >= 6 && rate > SI5351_CLKOUT67_MAX_FREQ)
+		rate = SI5351_CLKOUT67_MAX_FREQ;
+
+	/* clkout freqency is 8kHz - 160MHz */
+	if (rate > SI5351_CLKOUT_MAX_FREQ)
+		rate = SI5351_CLKOUT_MAX_FREQ;
+	if (rate < SI5351_CLKOUT_MIN_FREQ)
+		rate = SI5351_CLKOUT_MIN_FREQ;
+
+	/* request frequency if multisync master */
+	if (__clk_get_flags(hwdata->hw.clk) & CLK_SET_RATE_PARENT) {
+		/* use r divider for frequencies below 1MHz */
+		rdiv = SI5351_OUTPUT_CLK_DIV_1;
+		while (rate < SI5351_MULTISYNTH_MIN_FREQ &&
+		       rdiv < SI5351_OUTPUT_CLK_DIV_128) {
+			rdiv += 1;
+			rate *= 2;
+		}
+		*parent_rate = rate;
+	} else {
+		unsigned long new_rate, new_err, err;
+
+		/* round to closed rdiv */
+		rdiv = SI5351_OUTPUT_CLK_DIV_1;
+		new_rate = *parent_rate;
+		err = abs(new_rate - rate);
+		do {
+			new_rate >>= 1;
+			new_err = abs(new_rate - rate);
+			if (new_err > err || rdiv == SI5351_OUTPUT_CLK_DIV_128)
+				break;
+			rdiv++;
+			err = new_err;
+		} while (1);
+	}
+	rate = *parent_rate >> rdiv;
+
+	dev_dbg(&hwdata->drvdata->client->dev,
+		"%s - %s: rdiv = %u, parent_rate = %lu, rate = %lu\n",
+		__func__, __clk_get_name(hwdata->hw.clk), (1 << rdiv),
+		*parent_rate, rate);
+
+	return rate;
+}
+
+static int si5351_clkout_set_rate(struct clk_hw *hw, unsigned long rate,
+				  unsigned long parent_rate)
+{
+	struct si5351_hw_data *hwdata =
+		container_of(hw, struct si5351_hw_data, hw);
+	unsigned long new_rate, new_err, err;
+	unsigned char rdiv;
+
+	/* round to closed rdiv */
+	rdiv = SI5351_OUTPUT_CLK_DIV_1;
+	new_rate = parent_rate;
+	err = abs(new_rate - rate);
+	do {
+		new_rate >>= 1;
+		new_err = abs(new_rate - rate);
+		if (new_err > err || rdiv == SI5351_OUTPUT_CLK_DIV_128)
+			break;
+		rdiv++;
+		err = new_err;
+	} while (1);
+
+	/* write output divider */
+	switch (hwdata->num) {
+	case 6:
+		si5351_set_bits(hwdata->drvdata, SI5351_CLK6_7_OUTPUT_DIVIDER,
+				SI5351_OUTPUT_CLK6_DIV_MASK, rdiv);
+		break;
+	case 7:
+		si5351_set_bits(hwdata->drvdata, SI5351_CLK6_7_OUTPUT_DIVIDER,
+				SI5351_OUTPUT_CLK_DIV_MASK,
+				rdiv << SI5351_OUTPUT_CLK_DIV_SHIFT);
+		break;
+	default:
+		si5351_set_bits(hwdata->drvdata,
+				si5351_msynth_params_address(hwdata->num) + 2,
+				SI5351_OUTPUT_CLK_DIV_MASK,
+				rdiv << SI5351_OUTPUT_CLK_DIV_SHIFT);
+	}
+
+	dev_dbg(&hwdata->drvdata->client->dev,
+		"%s - %s: rdiv = %u, parent_rate = %lu, rate = %lu\n",
+		__func__, __clk_get_name(hwdata->hw.clk), (1 << rdiv),
+		parent_rate, rate);
+
+	return 0;
+}
+
+static const struct clk_ops si5351_clkout_ops = {
+	.prepare = si5351_clkout_prepare,
+	.unprepare = si5351_clkout_unprepare,
+	.set_parent = si5351_clkout_set_parent,
+	.get_parent = si5351_clkout_get_parent,
+	.recalc_rate = si5351_clkout_recalc_rate,
+	.round_rate = si5351_clkout_round_rate,
+	.set_rate = si5351_clkout_set_rate,
+};
+
+/*
+ * Si5351 i2c probe and DT
+ */
+#ifdef CONFIG_OF
+static const struct of_device_id si5351_dt_ids[] = {
+	{ .compatible = "silabs,si5351a", .data = (void *)SI5351_VARIANT_A, },
+	{ .compatible = "silabs,si5351a-msop",
+					 .data = (void *)SI5351_VARIANT_A3, },
+	{ .compatible = "silabs,si5351b", .data = (void *)SI5351_VARIANT_B, },
+	{ .compatible = "silabs,si5351c", .data = (void *)SI5351_VARIANT_C, },
+	{ }
+};
+MODULE_DEVICE_TABLE(of, si5351_dt_ids);
+
+static int si5351_dt_parse(struct i2c_client *client)
+{
+	struct device_node *child, *np = client->dev.of_node;
+	struct si5351_platform_data *pdata;
+	const struct of_device_id *match;
+	struct property *prop;
+	const __be32 *p;
+	int num = 0;
+	u32 val;
+
+	if (np == NULL)
+		return 0;
+
+	match = of_match_node(si5351_dt_ids, np);
+	if (match == NULL)
+		return -EINVAL;
+
+	pdata = devm_kzalloc(&client->dev, sizeof(*pdata), GFP_KERNEL);
+	if (!pdata)
+		return -ENOMEM;
+
+	pdata->variant = (enum si5351_variant)match->data;
+	pdata->clk_xtal = of_clk_get(np, 0);
+	if (!IS_ERR(pdata->clk_xtal))
+		clk_put(pdata->clk_xtal);
+	pdata->clk_clkin = of_clk_get(np, 1);
+	if (!IS_ERR(pdata->clk_clkin))
+		clk_put(pdata->clk_clkin);
+
+	/*
+	 * property silabs,pll-source : <num src>, [<..>]
+	 * allow to selectively set pll source
+	 */
+	of_property_for_each_u32(np, "silabs,pll-source", prop, p, num) {
+		if (num >= 2) {
+			dev_err(&client->dev,
+				"invalid pll %d on pll-source prop\n", num);
+			return -EINVAL;
+		}
+
+		p = of_prop_next_u32(prop, p, &val);
+		if (!p) {
+			dev_err(&client->dev,
+				"missing pll-source for pll %d\n", num);
+			return -EINVAL;
+		}
+
+		switch (val) {
+		case 0:
+			pdata->pll_src[num] = SI5351_PLL_SRC_XTAL;
+			break;
+		case 1:
+			if (pdata->variant != SI5351_VARIANT_C) {
+				dev_err(&client->dev,
+					"invalid parent %d for pll %d\n",
+					val, num);
+				return -EINVAL;
+			}
+			pdata->pll_src[num] = SI5351_PLL_SRC_CLKIN;
+			break;
+		default:
+			dev_err(&client->dev,
+				 "invalid parent %d for pll %d\n", val, num);
+			return -EINVAL;
+		}
+	}
+
+	/* per clkout properties */
+	for_each_child_of_node(np, child) {
+		if (of_property_read_u32(child, "reg", &num)) {
+			dev_err(&client->dev, "missing reg property of %s\n",
+				child->name);
+			return -EINVAL;
+		}
+
+		if (num >= 8 ||
+		    (pdata->variant == SI5351_VARIANT_A3 && num >= 3)) {
+			dev_err(&client->dev, "invalid clkout %d\n", num);
+			return -EINVAL;
+		}
+
+		if (!of_property_read_u32(child, "silabs,multisynth-source",
+					  &val)) {
+			switch (val) {
+			case 0:
+				pdata->clkout[num].multisynth_src =
+					SI5351_MULTISYNTH_SRC_VCO0;
+				break;
+			case 1:
+				pdata->clkout[num].multisynth_src =
+					SI5351_MULTISYNTH_SRC_VCO1;
+				break;
+			default:
+				dev_err(&client->dev,
+					"invalid parent %d for multisynth %d\n",
+					val, num);
+				return -EINVAL;
+			}
+		}
+
+		if (!of_property_read_u32(child, "silabs,clock-source", &val)) {
+			switch (val) {
+			case 0:
+				pdata->clkout[num].clkout_src =
+					SI5351_CLKOUT_SRC_MSYNTH_N;
+				break;
+			case 1:
+				pdata->clkout[num].clkout_src =
+					SI5351_CLKOUT_SRC_MSYNTH_0_4;
+				break;
+			case 2:
+				pdata->clkout[num].clkout_src =
+					SI5351_CLKOUT_SRC_XTAL;
+				break;
+			case 3:
+				if (pdata->variant != SI5351_VARIANT_C) {
+					dev_err(&client->dev,
+						"invalid parent %d for clkout %d\n",
+						val, num);
+					return -EINVAL;
+				}
+				pdata->clkout[num].clkout_src =
+					SI5351_CLKOUT_SRC_CLKIN;
+				break;
+			default:
+				dev_err(&client->dev,
+					"invalid parent %d for clkout %d\n",
+					val, num);
+				return -EINVAL;
+			}
+		}
+
+		if (!of_property_read_u32(child, "silabs,drive-strength",
+					  &val)) {
+			switch (val) {
+			case SI5351_DRIVE_2MA:
+			case SI5351_DRIVE_4MA:
+			case SI5351_DRIVE_6MA:
+			case SI5351_DRIVE_8MA:
+				pdata->clkout[num].drive = val;
+				break;
+			default:
+				dev_err(&client->dev,
+					"invalid drive strength %d for clkout %d\n",
+					val, num);
+				return -EINVAL;
+			}
+		}
+
+		if (!of_property_read_u32(child, "clock-frequency", &val))
+			pdata->clkout[num].rate = val;
+
+		pdata->clkout[num].pll_master =
+			of_property_read_bool(child, "silabs,pll-master");
+	}
+	client->dev.platform_data = pdata;
+
+	return 0;
+}
+#else
+static int si5351_dt_parse(struct i2c_client *client)
+{
+	return 0;
+}
+#endif /* CONFIG_OF */
+
+static int si5351_i2c_probe(struct i2c_client *client,
+			    const struct i2c_device_id *id)
+{
+	struct si5351_platform_data *pdata;
+	struct si5351_driver_data *drvdata;
+	struct clk_init_data init;
+	struct clk *clk;
+	const char *parent_names[4];
+	u8 num_parents, num_clocks;
+	int ret, n;
+
+	ret = si5351_dt_parse(client);
+	if (ret)
+		return ret;
+
+	pdata = client->dev.platform_data;
+	if (!pdata)
+		return -EINVAL;
+
+	drvdata = devm_kzalloc(&client->dev, sizeof(*drvdata), GFP_KERNEL);
+	if (drvdata == NULL) {
+		dev_err(&client->dev, "unable to allocate driver data\n");
+		return -ENOMEM;
+	}
+
+	i2c_set_clientdata(client, drvdata);
+	drvdata->client = client;
+	drvdata->variant = pdata->variant;
+	drvdata->pxtal = pdata->clk_xtal;
+	drvdata->pclkin = pdata->clk_clkin;
+
+	drvdata->regmap = devm_regmap_init_i2c(client, &si5351_regmap_config);
+	if (IS_ERR(drvdata->regmap)) {
+		dev_err(&client->dev, "failed to allocate register map\n");
+		return PTR_ERR(drvdata->regmap);
+	}
+
+	/* Disable interrupts */
+	si5351_reg_write(drvdata, SI5351_INTERRUPT_MASK, 0xf0);
+	/* Set disabled output drivers to drive low */
+	si5351_reg_write(drvdata, SI5351_CLK3_0_DISABLE_STATE, 0x00);
+	si5351_reg_write(drvdata, SI5351_CLK7_4_DISABLE_STATE, 0x00);
+	/* Ensure pll select is on XTAL for Si5351A/B */
+	if (drvdata->variant != SI5351_VARIANT_C)
+		si5351_set_bits(drvdata, SI5351_PLL_INPUT_SOURCE,
+				SI5351_PLLA_SOURCE | SI5351_PLLB_SOURCE, 0);
+
+	/* setup clock configuration */
+	for (n = 0; n < 2; n++) {
+		ret = _si5351_pll_reparent(drvdata, n, pdata->pll_src[n]);
+		if (ret) {
+			dev_err(&client->dev,
+				"failed to reparent pll %d to %d\n",
+				n, pdata->pll_src[n]);
+			return ret;
+		}
+	}
+
+	for (n = 0; n < 8; n++) {
+		ret = _si5351_msynth_reparent(drvdata, n,
+					      pdata->clkout[n].multisynth_src);
+		if (ret) {
+			dev_err(&client->dev,
+				"failed to reparent multisynth %d to %d\n",
+				n, pdata->clkout[n].multisynth_src);
+			return ret;
+		}
+
+		ret = _si5351_clkout_reparent(drvdata, n,
+					      pdata->clkout[n].clkout_src);
+		if (ret) {
+			dev_err(&client->dev,
+				"failed to reparent clkout %d to %d\n",
+				n, pdata->clkout[n].clkout_src);
+			return ret;
+		}
+
+		ret = _si5351_clkout_set_drive_strength(drvdata, n,
+							pdata->clkout[n].drive);
+		if (ret) {
+			dev_err(&client->dev,
+				"failed set drive strength of clkout%d to %d\n",
+				n, pdata->clkout[n].drive);
+			return ret;
+		}
+	}
+
+	/* register xtal input clock gate */
+	memset(&init, 0, sizeof(init));
+	init.name = si5351_input_names[0];
+	init.ops = &si5351_xtal_ops;
+	init.flags = 0;
+	if (!IS_ERR(drvdata->pxtal)) {
+		drvdata->pxtal_name = __clk_get_name(drvdata->pxtal);
+		init.parent_names = &drvdata->pxtal_name;
+		init.num_parents = 1;
+	}
+	drvdata->xtal.init = &init;
+	clk = devm_clk_register(&client->dev, &drvdata->xtal);
+	if (IS_ERR(clk)) {
+		dev_err(&client->dev, "unable to register %s\n", init.name);
+		return PTR_ERR(clk);
+	}
+
+	/* register clkin input clock gate */
+	if (drvdata->variant == SI5351_VARIANT_C) {
+		memset(&init, 0, sizeof(init));
+		init.name = si5351_input_names[1];
+		init.ops = &si5351_clkin_ops;
+		if (!IS_ERR(drvdata->pclkin)) {
+			drvdata->pclkin_name = __clk_get_name(drvdata->pclkin);
+			init.parent_names = &drvdata->pclkin_name;
+			init.num_parents = 1;
+		}
+		drvdata->clkin.init = &init;
+		clk = devm_clk_register(&client->dev, &drvdata->clkin);
+		if (IS_ERR(clk)) {
+			dev_err(&client->dev, "unable to register %s\n",
+				init.name);
+			return PTR_ERR(clk);
+		}
+	}
+
+	/* Si5351C allows to mux either xtal or clkin to PLL input */
+	num_parents = (drvdata->variant == SI5351_VARIANT_C) ? 2 : 1;
+	parent_names[0] = si5351_input_names[0];
+	parent_names[1] = si5351_input_names[1];
+
+	/* register PLLA */
+	drvdata->pll[0].num = 0;
+	drvdata->pll[0].drvdata = drvdata;
+	drvdata->pll[0].hw.init = &init;
+	memset(&init, 0, sizeof(init));
+	init.name = si5351_pll_names[0];
+	init.ops = &si5351_pll_ops;
+	init.flags = 0;
+	init.parent_names = parent_names;
+	init.num_parents = num_parents;
+	clk = devm_clk_register(&client->dev, &drvdata->pll[0].hw);
+	if (IS_ERR(clk)) {
+		dev_err(&client->dev, "unable to register %s\n", init.name);
+		return -EINVAL;
+	}
+
+	/* register PLLB or VXCO (Si5351B) */
+	drvdata->pll[1].num = 1;
+	drvdata->pll[1].drvdata = drvdata;
+	drvdata->pll[1].hw.init = &init;
+	memset(&init, 0, sizeof(init));
+	if (drvdata->variant == SI5351_VARIANT_B) {
+		init.name = si5351_pll_names[2];
+		init.ops = &si5351_vxco_ops;
+		init.flags = CLK_IS_ROOT;
+		init.parent_names = NULL;
+		init.num_parents = 0;
+	} else {
+		init.name = si5351_pll_names[1];
+		init.ops = &si5351_pll_ops;
+		init.flags = 0;
+		init.parent_names = parent_names;
+		init.num_parents = num_parents;
+	}
+	clk = devm_clk_register(&client->dev, &drvdata->pll[1].hw);
+	if (IS_ERR(clk)) {
+		dev_err(&client->dev, "unable to register %s\n", init.name);
+		return -EINVAL;
+	}
+
+	/* register clk multisync and clk out divider */
+	num_clocks = (drvdata->variant == SI5351_VARIANT_A3) ? 3 : 8;
+	parent_names[0] = si5351_pll_names[0];
+	if (drvdata->variant == SI5351_VARIANT_B)
+		parent_names[1] = si5351_pll_names[2];
+	else
+		parent_names[1] = si5351_pll_names[1];
+
+	drvdata->msynth = devm_kzalloc(&client->dev, num_clocks *
+				       sizeof(*drvdata->msynth), GFP_KERNEL);
+	drvdata->clkout = devm_kzalloc(&client->dev, num_clocks *
+				       sizeof(*drvdata->clkout), GFP_KERNEL);
+
+	drvdata->onecell.clk_num = num_clocks;
+	drvdata->onecell.clks = devm_kzalloc(&client->dev,
+		num_clocks * sizeof(*drvdata->onecell.clks), GFP_KERNEL);
+
+	if (WARN_ON(!drvdata->msynth || !drvdata->clkout ||
+		    !drvdata->onecell.clks))
+		return -ENOMEM;
+
+	for (n = 0; n < num_clocks; n++) {
+		drvdata->msynth[n].num = n;
+		drvdata->msynth[n].drvdata = drvdata;
+		drvdata->msynth[n].hw.init = &init;
+		memset(&init, 0, sizeof(init));
+		init.name = si5351_msynth_names[n];
+		init.ops = &si5351_msynth_ops;
+		init.flags = 0;
+		if (pdata->clkout[n].pll_master)
+			init.flags |= CLK_SET_RATE_PARENT;
+		init.parent_names = parent_names;
+		init.num_parents = 2;
+		clk = devm_clk_register(&client->dev, &drvdata->msynth[n].hw);
+		if (IS_ERR(clk)) {
+			dev_err(&client->dev, "unable to register %s\n",
+				init.name);
+			return -EINVAL;
+		}
+	}
+
+	num_parents = (drvdata->variant == SI5351_VARIANT_C) ? 4 : 3;
+	parent_names[2] = si5351_input_names[0];
+	parent_names[3] = si5351_input_names[1];
+	for (n = 0; n < num_clocks; n++) {
+		parent_names[0] = si5351_msynth_names[n];
+		parent_names[1] = (n < 4) ? si5351_msynth_names[0] :
+			si5351_msynth_names[4];
+
+		drvdata->clkout[n].num = n;
+		drvdata->clkout[n].drvdata = drvdata;
+		drvdata->clkout[n].hw.init = &init;
+		memset(&init, 0, sizeof(init));
+		init.name = si5351_clkout_names[n];
+		init.ops = &si5351_clkout_ops;
+		init.flags = 0;
+		if (pdata->clkout[n].clkout_src == SI5351_CLKOUT_SRC_MSYNTH_N)
+			init.flags |= CLK_SET_RATE_PARENT;
+		init.parent_names = parent_names;
+		init.num_parents = num_parents;
+		clk = devm_clk_register(&client->dev, &drvdata->clkout[n].hw);
+		if (IS_ERR(clk)) {
+			dev_err(&client->dev, "unable to register %s\n",
+				init.name);
+			return -EINVAL;
+		}
+		drvdata->onecell.clks[n] = clk;
+	}
+
+	ret = of_clk_add_provider(client->dev.of_node, of_clk_src_onecell_get,
+				  &drvdata->onecell);
+	if (ret) {
+		dev_err(&client->dev, "unable to add clk provider\n");
+		return ret;
+	}
+
+	return 0;
+}
+
+static const struct i2c_device_id si5351_i2c_ids[] = {
+	{ "silabs,si5351", 0 },
+	{ }
+};
+MODULE_DEVICE_TABLE(i2c, si5351_i2c_ids);
+
+static struct i2c_driver si5351_driver = {
+	.driver = {
+		.name = "si5351",
+		.of_match_table = of_match_ptr(si5351_dt_ids),
+	},
+	.probe = si5351_i2c_probe,
+	.id_table = si5351_i2c_ids,
+};
+module_i2c_driver(si5351_driver);
+
+MODULE_AUTHOR("Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com");
+MODULE_DESCRIPTION("Silicon Labs Si5351A/B/C clock generator driver");
+MODULE_LICENSE("GPL");
diff --git a/drivers/clk/clk-si5351.h b/drivers/clk/clk-si5351.h
new file mode 100644
index 0000000..af41b50
--- /dev/null
+++ b/drivers/clk/clk-si5351.h
@@ -0,0 +1,155 @@
+/*
+ * clk-si5351.h: Silicon Laboratories Si5351A/B/C I2C Clock Generator
+ *
+ * Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
+ * Rabeeh Khoury <rabeeh at solid-run.com>
+ *
+ * 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.
+ */
+
+#ifndef _CLK_SI5351_H_
+#define _CLK_SI5351_H_
+
+#define SI5351_BUS_BASE_ADDR			0x60
+
+#define SI5351_PLL_VCO_MIN			600000000
+#define SI5351_PLL_VCO_MAX			900000000
+#define SI5351_MULTISYNTH_MIN_FREQ		1000000
+#define SI5351_MULTISYNTH_DIVBY4_FREQ		150000000
+#define SI5351_MULTISYNTH_MAX_FREQ		160000000
+#define SI5351_MULTISYNTH67_MAX_FREQ		SI5351_MULTISYNTH_DIVBY4_FREQ
+#define SI5351_CLKOUT_MIN_FREQ			8000
+#define SI5351_CLKOUT_MAX_FREQ			SI5351_MULTISYNTH_MAX_FREQ
+#define SI5351_CLKOUT67_MAX_FREQ		SI5351_MULTISYNTH67_MAX_FREQ
+
+#define SI5351_PLL_A_MIN			15
+#define SI5351_PLL_A_MAX			90
+#define SI5351_PLL_B_MAX			(SI5351_PLL_C_MAX-1)
+#define SI5351_PLL_C_MAX			1048575
+#define SI5351_MULTISYNTH_A_MIN			6
+#define SI5351_MULTISYNTH_A_MAX			1800
+#define SI5351_MULTISYNTH67_A_MAX		254
+#define SI5351_MULTISYNTH_B_MAX			(SI5351_MULTISYNTH_C_MAX-1)
+#define SI5351_MULTISYNTH_C_MAX			1048575
+#define SI5351_MULTISYNTH_P1_MAX		((1<<18)-1)
+#define SI5351_MULTISYNTH_P2_MAX		((1<<20)-1)
+#define SI5351_MULTISYNTH_P3_MAX		((1<<20)-1)
+
+#define SI5351_DEVICE_STATUS			0
+#define SI5351_INTERRUPT_STATUS			1
+#define SI5351_INTERRUPT_MASK			2
+#define  SI5351_STATUS_SYS_INIT			(1<<7)
+#define  SI5351_STATUS_LOL_B			(1<<6)
+#define  SI5351_STATUS_LOL_A			(1<<5)
+#define  SI5351_STATUS_LOS			(1<<4)
+#define SI5351_OUTPUT_ENABLE_CTRL		3
+#define SI5351_OEB_PIN_ENABLE_CTRL		9
+#define SI5351_PLL_INPUT_SOURCE			15
+#define  SI5351_CLKIN_DIV_MASK			(3<<6)
+#define  SI5351_CLKIN_DIV_1			(0<<6)
+#define  SI5351_CLKIN_DIV_2			(1<<6)
+#define  SI5351_CLKIN_DIV_4			(2<<6)
+#define  SI5351_CLKIN_DIV_8			(3<<6)
+#define  SI5351_PLLB_SOURCE			(1<<3)
+#define  SI5351_PLLA_SOURCE			(1<<2)
+
+#define SI5351_CLK0_CTRL			16
+#define SI5351_CLK1_CTRL			17
+#define SI5351_CLK2_CTRL			18
+#define SI5351_CLK3_CTRL			19
+#define SI5351_CLK4_CTRL			20
+#define SI5351_CLK5_CTRL			21
+#define SI5351_CLK6_CTRL			22
+#define SI5351_CLK7_CTRL			23
+#define  SI5351_CLK_POWERDOWN			(1<<7)
+#define  SI5351_CLK_INTEGER_MODE		(1<<6)
+#define  SI5351_CLK_PLL_SELECT			(1<<5)
+#define  SI5351_CLK_INVERT			(1<<4)
+#define  SI5351_CLK_INPUT_MASK			(3<<2)
+#define  SI5351_CLK_INPUT_XTAL			(0<<2)
+#define  SI5351_CLK_INPUT_CLKIN			(1<<2)
+#define  SI5351_CLK_INPUT_MULTISYNTH_0_4	(2<<2)
+#define  SI5351_CLK_INPUT_MULTISYNTH_N		(3<<2)
+#define  SI5351_CLK_DRIVE_STRENGTH_MASK		(3<<0)
+#define  SI5351_CLK_DRIVE_STRENGTH_2MA		(0<<0)
+#define  SI5351_CLK_DRIVE_STRENGTH_4MA		(1<<0)
+#define  SI5351_CLK_DRIVE_STRENGTH_6MA		(2<<0)
+#define  SI5351_CLK_DRIVE_STRENGTH_8MA		(3<<0)
+
+#define SI5351_CLK3_0_DISABLE_STATE		24
+#define SI5351_CLK7_4_DISABLE_STATE		25
+#define  SI5351_CLK_DISABLE_STATE_LOW		0
+#define  SI5351_CLK_DISABLE_STATE_HIGH		1
+#define  SI5351_CLK_DISABLE_STATE_FLOAT		2
+#define  SI5351_CLK_DISABLE_STATE_NEVER		3
+
+#define SI5351_PARAMETERS_LENGTH		8
+#define SI5351_PLLA_PARAMETERS			26
+#define SI5351_PLLB_PARAMETERS			34
+#define SI5351_CLK0_PARAMETERS			42
+#define SI5351_CLK1_PARAMETERS			50
+#define SI5351_CLK2_PARAMETERS			58
+#define SI5351_CLK3_PARAMETERS			66
+#define SI5351_CLK4_PARAMETERS			74
+#define SI5351_CLK5_PARAMETERS			82
+#define SI5351_CLK6_PARAMETERS			90
+#define SI5351_CLK7_PARAMETERS			91
+#define SI5351_CLK6_7_OUTPUT_DIVIDER		92
+#define  SI5351_OUTPUT_CLK_DIV_MASK		(7 << 4)
+#define  SI5351_OUTPUT_CLK6_DIV_MASK		(7 << 0)
+#define  SI5351_OUTPUT_CLK_DIV_SHIFT		4
+#define  SI5351_OUTPUT_CLK_DIV6_SHIFT		0
+#define  SI5351_OUTPUT_CLK_DIV_1		0
+#define  SI5351_OUTPUT_CLK_DIV_2		1
+#define  SI5351_OUTPUT_CLK_DIV_4		2
+#define  SI5351_OUTPUT_CLK_DIV_8		3
+#define  SI5351_OUTPUT_CLK_DIV_16		4
+#define  SI5351_OUTPUT_CLK_DIV_32		5
+#define  SI5351_OUTPUT_CLK_DIV_64		6
+#define  SI5351_OUTPUT_CLK_DIV_128		7
+#define  SI5351_OUTPUT_CLK_DIVBY4		(3<<2)
+
+#define SI5351_SSC_PARAM0			149
+#define SI5351_SSC_PARAM1			150
+#define SI5351_SSC_PARAM2			151
+#define SI5351_SSC_PARAM3			152
+#define SI5351_SSC_PARAM4			153
+#define SI5351_SSC_PARAM5			154
+#define SI5351_SSC_PARAM6			155
+#define SI5351_SSC_PARAM7			156
+#define SI5351_SSC_PARAM8			157
+#define SI5351_SSC_PARAM9			158
+#define SI5351_SSC_PARAM10			159
+#define SI5351_SSC_PARAM11			160
+#define SI5351_SSC_PARAM12			161
+
+#define SI5351_VXCO_PARAMETERS_LOW		162
+#define SI5351_VXCO_PARAMETERS_MID		163
+#define SI5351_VXCO_PARAMETERS_HIGH		164
+
+#define SI5351_CLK0_PHASE_OFFSET		165
+#define SI5351_CLK1_PHASE_OFFSET		166
+#define SI5351_CLK2_PHASE_OFFSET		167
+#define SI5351_CLK3_PHASE_OFFSET		168
+#define SI5351_CLK4_PHASE_OFFSET		169
+#define SI5351_CLK5_PHASE_OFFSET		170
+
+#define SI5351_PLL_RESET			177
+#define  SI5351_PLL_RESET_B			(1<<7)
+#define  SI5351_PLL_RESET_A			(1<<5)
+
+#define SI5351_CRYSTAL_LOAD			183
+#define  SI5351_CRYSTAL_LOAD_MASK		(3<<6)
+#define  SI5351_CRYSTAL_LOAD_6PF		(1<<6)
+#define  SI5351_CRYSTAL_LOAD_8PF		(2<<6)
+#define  SI5351_CRYSTAL_LOAD_10PF		(3<<6)
+
+#define SI5351_FANOUT_ENABLE			187
+#define  SI5351_CLKIN_ENABLE			(1<<7)
+#define  SI5351_XTAL_ENABLE			(1<<6)
+#define  SI5351_MULTISYNTH_ENABLE		(1<<4)
+
+#endif
diff --git a/include/linux/platform_data/si5351.h b/include/linux/platform_data/si5351.h
new file mode 100644
index 0000000..92dabca
--- /dev/null
+++ b/include/linux/platform_data/si5351.h
@@ -0,0 +1,114 @@
+/*
+ * Si5351A/B/C programmable clock generator platform_data.
+ */
+
+#ifndef __LINUX_PLATFORM_DATA_SI5351_H__
+#define __LINUX_PLATFORM_DATA_SI5351_H__
+
+struct clk;
+
+/**
+ * enum si5351_variant - SiLabs Si5351 chip variant
+ * @SI5351_VARIANT_A: Si5351A (8 output clocks, XTAL input)
+ * @SI5351_VARIANT_A3: Si5351A MSOP10 (3 output clocks, XTAL input)
+ * @SI5351_VARIANT_B: Si5351B (8 output clocks, XTAL/VXCO input)
+ * @SI5351_VARIANT_C: Si5351C (8 output clocks, XTAL/CLKIN input)
+ */
+enum si5351_variant {
+	SI5351_VARIANT_A = 1,
+	SI5351_VARIANT_A3 = 2,
+	SI5351_VARIANT_B = 3,
+	SI5351_VARIANT_C = 4,
+};
+
+/**
+ * enum si5351_pll_src - Si5351 pll clock source
+ * @SI5351_PLL_SRC_DEFAULT: default, do not change eeprom config
+ * @SI5351_PLL_SRC_XTAL: pll source clock is XTAL input
+ * @SI5351_PLL_SRC_CLKIN: pll source clock is CLKIN input (Si5351C only)
+ */
+enum si5351_pll_src {
+	SI5351_PLL_SRC_DEFAULT = 0,
+	SI5351_PLL_SRC_XTAL = 1,
+	SI5351_PLL_SRC_CLKIN = 2,
+};
+
+/**
+ * enum si5351_multisynth_src - Si5351 multisynth clock source
+ * @SI5351_MULTISYNTH_SRC_DEFAULT: default, do not change eeprom config
+ * @SI5351_MULTISYNTH_SRC_VCO0: multisynth source clock is VCO0
+ * @SI5351_MULTISYNTH_SRC_VCO1: multisynth source clock is VCO1/VXCO
+ */
+enum si5351_multisynth_src {
+	SI5351_MULTISYNTH_SRC_DEFAULT = 0,
+	SI5351_MULTISYNTH_SRC_VCO0 = 1,
+	SI5351_MULTISYNTH_SRC_VCO1 = 2,
+};
+
+/**
+ * enum si5351_clkout_src - Si5351 clock output clock source
+ * @SI5351_CLKOUT_SRC_DEFAULT: default, do not change eeprom config
+ * @SI5351_CLKOUT_SRC_MSYNTH_N: clkout N source clock is multisynth N
+ * @SI5351_CLKOUT_SRC_MSYNTH_0_4: clkout N source clock is multisynth 0 (N<4)
+ *                                or 4 (N>=4)
+ * @SI5351_CLKOUT_SRC_XTAL: clkout N source clock is XTAL
+ * @SI5351_CLKOUT_SRC_CLKIN: clkout N source clock is CLKIN (Si5351C only)
+ */
+enum si5351_clkout_src {
+	SI5351_CLKOUT_SRC_DEFAULT = 0,
+	SI5351_CLKOUT_SRC_MSYNTH_N = 1,
+	SI5351_CLKOUT_SRC_MSYNTH_0_4 = 2,
+	SI5351_CLKOUT_SRC_XTAL = 3,
+	SI5351_CLKOUT_SRC_CLKIN = 4,
+};
+
+/**
+ * enum si5351_drive_strength - Si5351 clock output drive strength
+ * @SI5351_DRIVE_DEFAULT: default, do not change eeprom config
+ * @SI5351_DRIVE_2MA: 2mA clock output drive strength
+ * @SI5351_DRIVE_4MA: 4mA clock output drive strength
+ * @SI5351_DRIVE_6MA: 6mA clock output drive strength
+ * @SI5351_DRIVE_8MA: 8mA clock output drive strength
+ */
+enum si5351_drive_strength {
+	SI5351_DRIVE_DEFAULT = 0,
+	SI5351_DRIVE_2MA = 2,
+	SI5351_DRIVE_4MA = 4,
+	SI5351_DRIVE_6MA = 6,
+	SI5351_DRIVE_8MA = 8,
+};
+
+/**
+ * struct si5351_clkout_config - Si5351 clock output configuration
+ * @clkout: clkout number
+ * @multisynth_src: multisynth source clock
+ * @clkout_src: clkout source clock
+ * @pll_master: if true, clkout can also change pll rate
+ * @drive: output drive strength
+ * @rate: initial clkout rate, or default if 0
+ */
+struct si5351_clkout_config {
+	enum si5351_multisynth_src multisynth_src;
+	enum si5351_clkout_src clkout_src;
+	enum si5351_drive_strength drive;
+	bool pll_master;
+	unsigned long rate;
+};
+
+/**
+ * struct si5351_platform_data - Platform data for the Si5351 clock driver
+ * @variant: Si5351 chip variant
+ * @clk_xtal: xtal input clock
+ * @clk_clkin: clkin input clock
+ * @pll_src: array of pll source clock setting
+ * @clkout: array of clkout configuration
+ */
+struct si5351_platform_data {
+	enum si5351_variant variant;
+	struct clk *clk_xtal;
+	struct clk *clk_clkin;
+	enum si5351_pll_src pll_src[2];
+	struct si5351_clkout_config clkout[8];
+};
+
+#endif
-- 
1.7.10.4



From cxie4 at marvell.com  Wed Apr 10 05:38:21 2013
From: cxie4 at marvell.com (Chao Xie)
Date: Wed, 10 Apr 2013 02:38:21 -0700
Subject: [PATCH] ARM: cache-l2x0: add device tree support for power control
In-Reply-To: <20130410091148.GA8799@e106331-lin.cambridge.arm.com>
References: <1361935237-12466-1-git-send-email-chao.xie@marvell.com>
 <20130410091148.GA8799@e106331-lin.cambridge.arm.com>
Message-ID: <AAD1C6EB06EE3649B35B7E026785068D1CF0C6B3C4@SC-VEXCH2.marvell.com>

>Hi,

>On Wed, Feb 27, 2013 at 03:20:37AM +0000, Chao Xie wrote:
> After version r3p0, cache pl310 has the power control register.
> Adding the device tree support for power control.
> So it can parse the power control register settings.
> 
> Signed-off-by: Chao Xie <chao.xie at marvell.com>
> ---
>  Documentation/devicetree/bindings/arm/l2cc.txt |    6 ++++++
>  arch/arm/mm/cache-l2x0.c                       |   16 ++++++++++++++++
>  2 files changed, 22 insertions(+), 0 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/arm/l2cc.txt b/Documentation/devicetree/bindings/arm/l2cc.txt
> index cbef09b..435ead2 100644
> --- a/Documentation/devicetree/bindings/arm/l2cc.txt
> +++ b/Documentation/devicetree/bindings/arm/l2cc.txt
> @@ -34,6 +34,10 @@ Optional properties:
>  - arm,filter-ranges : <start length> Starting address and length of window to
>    filter. Addresses in the filter window are directed to the M1 port. Other
>    addresses will go to the M0 port.
> +- arm,pwr-dynamic-clk-gating: If it is defined. The dynamic clock gating for
> +  better power is enabled. Only availabe after r3p0.
>
> This appears to be a configuration option rather than a description of the
> hardware.
>
> If we're able to know that this feature is present by reading the id register,
> we shouldn't need to describe it in the dt. We should simply work out if and
> when we want it enabled within the kernel.

So do you mean that I need directly enable these features and do not need provide the choice at DT?

> +- arm,pwr-standby-mode: If it is defined, standby mode is enabled. On available
> +  after r3p0.

> This looks like it depends on an additional signal being wired up, so it may be
> worth describing.

In fact I do know the details. I can only see PL310 spec that it added these features since r3p0.

>  - interrupts : 1 combined interrupt.
>  - cache-id-part: cache id part number to be used if it is not present
>    on hardware
> @@ -47,6 +51,8 @@ L2: cache-controller {
>          arm,data-latency = <1 1 1>;
>          arm,tag-latency = <2 2 2>;
>          arm,filter-ranges = <0x80000000 0x8000000>;
> +        arm,pwr-dynamic-clk-gating;
> +        arm,pwr-standby-mode;
>          cache-unified;
>          cache-level = <2>;
>  	interrupts = <45>;
> diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
> index c2f3739..95a338a 100644
> --- a/arch/arm/mm/cache-l2x0.c
> +++ b/arch/arm/mm/cache-l2x0.c
> @@ -564,6 +564,9 @@ static void __init pl310_of_setup(const struct device_node *np,
>  	u32 data[3] = { 0, 0, 0 };
>  	u32 tag[3] = { 0, 0, 0 };
>  	u32 filter[2] = { 0, 0 };
> +	u32 l2x0_revision;
> +	u32 power;
> +	const unsigned char *prop;
>  
>  	of_property_read_u32_array(np, "arm,tag-latency", tag, ARRAY_SIZE(tag));
>  	if (tag[0] && tag[1] && tag[2])
> @@ -590,6 +593,19 @@ static void __init pl310_of_setup(const struct device_node *np,
>  		writel_relaxed((filter[0] & ~(SZ_1M - 1)) | L2X0_ADDR_FILTER_EN,
>  			       l2x0_base + L2X0_ADDR_FILTER_START);
>  	}
> +
> +	l2x0_revision = readl_relaxed(l2x0_base + L2X0_CACHE_ID) &
> +		L2X0_CACHE_ID_RTL_MASK;
> +	if (l2x0_revision >= L2X0_CACHE_ID_RTL_R3P0) {
> +		power = 0;
> +		prop = of_get_property(np, "arm,pwr-dynamic-clk-gating", NULL);
> +		if (prop)
> +			power |= L2X0_DYNAMIC_CLK_GATING_EN;
> +		prop = of_get_property(np, "arm,pwr-standby-mode", NULL);
> +		if (prop)
> +			power |= L2X0_STNDBY_MODE_EN;

> You can use of_property_read_bool for both of the above cases (and you won't
> need prop any more):

> if (of_property_read_bool(np, "arm,pwr-standby-mode"))
>	power |= L2X0_STNDBY_MODE_EN;

> If dt info isn't needed, this can probably be moved into l2x0_init.

Sure. If everyone want the power feature enabled, it can be moved to l2x0_init.

> Mark.


From steve.capper at arm.com  Wed Apr 10 05:47:45 2013
From: steve.capper at arm.com (Steve Capper)
Date: Wed, 10 Apr 2013 10:47:45 +0100
Subject: [PATCH] arm: mm: lockless get_user_pages_fast
In-Reply-To: <00bc01ce35cb$38b9ffb0$aa2dff10$@samsusng.com>
References: <1360890012-4684-1-git-send-email-chanho61.park@samsung.com>
 <20130405111158.GA13428@e103986-lin>
 <00a201ce35bd$5626fd90$0274f8b0$@samsusng.com>
 <20130410082059.GA12296@e103986-lin>
 <00bc01ce35cb$38b9ffb0$aa2dff10$@samsusng.com>
Message-ID: <20130410094743.GA13494@e103986-lin>

On Wed, Apr 10, 2013 at 10:10:18AM +0100, Chanho Park wrote:
> > From: Steve Capper [mailto:steve.capper at arm.com]
> > Sent: Wednesday, April 10, 2013 5:21 PM
> > To: Chanho Park
> > Cc: Steve Capper; 'Chanho Park'; linux at arm.linux.org.uk; Catalin Marinas;
> > 'Inki Dae'; linux-mm at kvack.org; 'Kyungmin Park'; 'Myungjoo Ham'; linux-
> > arm-kernel at lists.infradead.org; 'Grazvydas Ignotas'
> > Subject: Re: [PATCH] arm: mm: lockless get_user_pages_fast
> > 
> > On Wed, Apr 10, 2013 at 08:30:54AM +0100, Chanho Park wrote:
> > > > Apologies for the tardy response, this patch slipped past me.
> > >
> > > Never mind.
> > >
> > > > I've tested this patch out, unfortunately it treats huge pmds as
> > > > regular pmds and attempts to traverse them rather than fall back to a
> > slow path.
> > > > The fix for this is very minor, please see my suggestion below.
> > > OK. I'll fix it.
> > >
> > > >
> > > > As an aside, I would like to extend this fast_gup to include full
> > > > huge page support and include a __get_user_pages_fast
> > > > implementation. This will hopefully fix a problem that was brought
> > > > to my attention by Grazvydas Ignotas whereby a FUTEX_WAIT on a THP
> > > > tail page will cause an infinite loop due to the stock
> > > > implementation of __get_user_pages_fast always returning 0.
> > >
> > > I'll add the __get_user_pages_fast implementation. BTW, HugeTLB on ARM
> > > wasn't supported yet. There is no problem to add gup_huge_pmd. But I
> > > think it need a test for hugepages.
> > >
> > 
> > Thanks, that would be helpful. My plan was to then put the huge page
> > specific bits in, with another patch. That way I can test it all out here.
> 
> Can I see the patch? I think it will be helpful to implement the
> gup_huge_pmd.
> Or how about you think except gup_huge_pmd in this patch?
> IMO it will be added easily after hugetlb on arm is merged.
> 

I think it would be better if this patch did not have gup_huge_pmd in it.

I am still working on my implementation and running it through a battery of
tests here. Also, I will likely change a few things in my huge page patches
to make a gup_huge_pmd easier to implement. I will be resending a V2 of my
huge pages soon.

It still would be helpful to have the pmd_bad(*pmdp) condition check in as
I suggested before though.

> > 
> > > > I would suggest:
> > > > 		if (pmd_none(*pmdp) || pmd_bad(*pmdp))
> > > > 			return 0;
> > > > as this will pick up pmds that can't be traversed, and fall back to
> > > > the slow path.
> > >
> > > Thanks for your suggestion.
> > > I'll prepare the v2 patch.
> > >
> > 
> > Also, just one more thing. In your gup_pte_range function there is an
> > smp_rmb() just after the pte is dereferenced. I don't understand why
> > though?
> 
> I think it would be needed for 64 bit machine. A pte of 64bit machine
> consists of low and high value. In this version, there is no need to add it.
> I'll remove it. Thanks.

The pte will only be 64 bit if LPAE is enabled, and LPAE support mandates
that 64 bit page table entries be read atomically. So we should be ok without
the read barrier.

> 
> Best regards,
> Chanho Park
> 
> 

Cheers,
--
Steve



From hechtb at gmail.com  Wed Apr 10 06:04:38 2013
From: hechtb at gmail.com (Bastian Hecht)
Date: Wed, 10 Apr 2013 12:04:38 +0200
Subject: [PATCH] ARM: hw_breakpoint: Do not use __cpuinitdata for dbg_cpu_pm_nb
Message-ID: <1365588278-5185-1-git-send-email-hechtb+renesas@gmail.com>

We must not declare dbg_cpu_pm_nb as __cpuinitdata as we need it after
system initialization for Suspend and CPUIdle.

This was done in commit 9a6eb310eaa5336b89a27a0bbb78da4bba35f6f1
ARM: hw_breakpoint: Debug powerdown support for self-hosted debug

Signed-off-by: Bastian Hecht <hechtb+renesas at gmail.com>
---
Hi,

I've experienced a kernel oops while working on Suspend-To-Ram and CPUIdle
on the Armadillo800EVA from Renesas. After echo mem >/sys/power/state I get:

Unable to handle kernel paging request at virtual address e7fddef0
PC is at 0xe7fddef0
LR is at notifier_call_chain+0x40/0x70

I've bisected the kernel to the commit 9a6eb310eaa5336b89a27a0bbb78da4bba35f6f1

    ARM: hw_breakpoint: Debug powerdown support for self-hosted debug

and succeeded to fix it by removing the __cpuinitdata tag.

Cheers,

 Bastian

 arch/arm/kernel/hw_breakpoint.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/kernel/hw_breakpoint.c b/arch/arm/kernel/hw_breakpoint.c
index 96093b7..8eb67bc 100644
--- a/arch/arm/kernel/hw_breakpoint.c
+++ b/arch/arm/kernel/hw_breakpoint.c
@@ -1043,7 +1043,7 @@ static int dbg_cpu_pm_notify(struct notifier_block *self, unsigned long action,
 	return NOTIFY_OK;
 }
 
-static struct notifier_block __cpuinitdata dbg_cpu_pm_nb = {
+static struct notifier_block dbg_cpu_pm_nb = {
 	.notifier_call = dbg_cpu_pm_notify,
 };
 
-- 
1.7.9.5



From kgene.kim at samsung.com  Wed Apr 10 06:10:44 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Wed, 10 Apr 2013 19:10:44 +0900
Subject: [PATCH] pinctrl: Add pinctrl-s3c24xx driver
In-Reply-To: <201304100135.12471.heiko@sntech.de>
References: <201304100135.12471.heiko@sntech.de>
Message-ID: <30fe01ce35d3$a9b7ce10$fd276a30$%kim@samsung.com>

Heiko St?bner wrote:
> 
> The s3c24xx pins follow a similar pattern as the other Samsung SoCs and
> can therefore reuse the already introduced infrastructure.
> 
> The s3c24xx SoCs have one design oddity in that the first 4 external
> interrupts do not reside in the eint pending register but in the main
> interrupt controller instead. We solve this by forwarding the external
> interrupt from the main controller into the irq domain of the pin bank.
> The masking/acking of these interrupts is handled in the same way.
> 
> Furthermore the S3C2412/2413 SoCs contain another oddity in that they
> keep the same 4 eints in the main interrupt controller and eintpend
> register and requiring ack operations to happen in both. To solve this
> a ctrl_type enum is introduced which can keep the type of controller
> in the samsung_pin_ctrl struct for later retrieval.
> 
> The ctrl_type enum contains only S3C24XX and S3C2412 types, as the
> eint-speciality is currently the only use-case. But it can be expaned
> if other SoCs gain special handling requirements later on.
> 
> Signed-off-by: Heiko Stuebner <heiko at sntech.de>

Looks good to me, need to implement more for other s3c24xx though.

Linus, if you want, please add:

Acked-by: Kukjin Kim <kgene.kim at samsung.com>

Thanks.

- Kukjin



From mark.rutland at arm.com  Wed Apr 10 06:13:36 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Wed, 10 Apr 2013 11:13:36 +0100
Subject: [PATCH 1/4] Documentation: Add memory mapped ARM architected
 timer binding
In-Reply-To: <516444FE.2080200@codeaurora.org>
References: <1365474623-29181-1-git-send-email-sboyd@codeaurora.org>
 <1365474623-29181-2-git-send-email-sboyd@codeaurora.org>
 <20130409090843.GS23725@e106331-lin.cambridge.arm.com>
 <516444FE.2080200@codeaurora.org>
Message-ID: <20130410101336.GB8799@e106331-lin.cambridge.arm.com>

On Tue, Apr 09, 2013 at 05:42:38PM +0100, Stephen Boyd wrote:
> On 04/09/13 02:08, Mark Rutland wrote:
> > On Tue, Apr 09, 2013 at 03:30:20AM +0100, Stephen Boyd wrote:
> >>  
> >> -** Timer node properties:
> >> +** CP15 Timer node properties:
> >>  
> >>  - compatible : Should at least contain one of
> >>  	"arm,armv7-timer"
> >> @@ -26,3 +30,55 @@ Example:
> >>  			     <1 10 0xf08>;
> >>  		clock-frequency = <100000000>;
> >>  	};
> >> +
> >> +** Memory mapped timer node properties
> >> +
> >> +- compatible : Should at least contain "arm,armv7-timer-mem".
> >> +
> >> +- #address-cells : Must be 1.
> > What about LPAE systems?
> >
> > How about something like the following:
> >
> > #address-cells : If the ranges property is empty, the same value as the
> >                  parent node's #address-cells property. Otherwise, a
> > 		 value such that the ranges property specifies a
> > 		 mapping to the parent node's address space.            
> 
> Yes that is much better. I wasn't trying to preclude LPAE or 64 bit systems.

Great.

> 
> >> +
> >> +- #size-cells : Must be 1.
> >> +
> >> +- ranges : Indicates parent and child bus address space are the same.
> >> +
> > Similarly, what if someone wants to write a more complex mapping for some
> > reason?
> >
> > We should be able to handle it if we use the standard accessors.
> 
> Maybe I should just leave this part out? They are standard DT properties
> so I could assume DT writers know what to do.

I'd be happy with that. It may be worth describing them as "as necessary" or
something to that effect.

> 
> >> +- clock-frequency : The frequency of the main counter, in Hz. Optional.
> >> +
> >> +- reg : The control frame base address.
> >> +
> >> +Frame:
> >> +
> >> +- frame-id: Encoded as follows:
> >> +		bits[3:0]  frame number: 0 to 7.
> >> +		bits[10:8] frame usage:
> >> +			0 - user/kernel
> >> +			1 - hyp
> >> +			2 - secure
> >> +
> > Could we not just have a disabled status property for those frames claimed by a
> > higher level (either secure firmware or hypervisor)? Or have I missed something
> > here?
> 
> Using disabled status would work. I was also thinking maybe we should
> use a compatible string in each frame's node. Then we could match
> against compatible children like "frame-user", "frame-kernel",
> "frame-hyp", "frame-secure", "frame-user-kernel", etc. It allows us
> flexibility if we should need to add something else in the future.

I can see why we need to specify secure/non-secure, but I'm not sure why we
need to specify hyp/user/kernel usage. Could we not leave this up to the kernel
to figure out?

A basic overveiew for those that don't know about the memory mapped timers:

* There's one control frame CNTCTLBase. Some registers in this frame are only
  available for secure accesses, including CNTNSAR which sets whether the
  counter frames are accessible from the non-secure side.

* There are up to 8 timer frames, which have their own CNTVOFF and
  physical/virtual timers. Each frame CNTBaseN is duplicated at CNTPL0BaseN
  with CNTVOFF and CNTPL0ACR (which controls PL0 accesses) inaccessible.

I can see that we might have frames/registers we can't access (if we were
booted on the non-secure side), but I can't see anything limiting whether we
use a frame for kernel/hyp/user beyond that. Have I missed something?

Could we not have something like the following for each frame:

frame0 {
	frame-id = <0>;
	status = "disabled"; /* booted NS, secure firmware has not enabled access */
	reg = <0x... 0x1000>, /* CNTBase0 */
	      <0x... 0x1000>; /* CNTPL0Base0 */
};

> 
> Also to get the frame number, I was thinking maybe we should expand the
> reg property to have two address cells. Then we could have reg = <0
> 0xf0001000 0x1000>.

We could do that, but then you definitely need a more complex ranges property,
and additional parsing code to handle grabbing it out of the reg property. I
can't see what it buys us.

Mark.


From kgene.kim at samsung.com  Wed Apr 10 06:15:48 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Wed, 10 Apr 2013 19:15:48 +0900
Subject: [PATCH v2 0/3] ARM: S3C24XX: Add devicetree support for s3c2416
In-Reply-To: <201302180103.53084.heiko@sntech.de>
References: <201302180103.53084.heiko@sntech.de>
Message-ID: <30ff01ce35d4$5f4920d0$1ddb6270$%kim@samsung.com>

Heiko St?bner wrote:
> 
> This is the second installment of beginning devicetree support the
> Samsung S3C24xx architectures and focuses on the s3c2416 for now.
> 
> Included is the devicetree support for the s3c24xx irq controller and
> basic support for smdk2416 boards, which can sucessfully boot.
> 
> 
> After the discussion with Thomas Abraham on v1 and staring to long at all
> of
> this, I'm not even sure if having the interrupt mapping in the binding
> is the correct way to go anymore.
> 
> The key positive aspect of this solution is, that after everything is
> running
> via dt all the SoC specific mapping tables in the driver can go away,
> cutting
> its length in half.
> 
> The other option would be as Thomas suggested to define specific irq-
> controller
> types (i.e. s3c2416-intc, s3c2443-intc, ... resulting in 16 types) and
> keep
> the mapping data in the code, as it is now.
> 
> So I would be very thankful for a bit of guidance on what is the better
> way.
> 
> 
> The series depends on the finalized s3c24xx irq rework, which probably
> won't
> make it into 3.9 and also the clocksource dt support by Tomasz Figa, which
> are not in any tree yet.
> 
> 
> Changes since v1:
> - adapt to changes in the underlying s3c24xx irq rework
>   = more shared init code
> - use irqchip infrastructure
> - limit number of possible irq-types to not encode implementation details
>   into the binding
> - include new samsung-clocksource
> 
> Heiko Stuebner (3):
>   ARM: S3C24XX: move irq driver to drivers/irqchip
>   irqchip: irq-s3c24xx: add devicetree support
>   ARM: S3C24XX: Add devicetree support and dt-board file for s3c2416 SoCs
> 
>  .../interrupt-controller/samsung,s3c24xx-irq.txt   |   53 ++++++
>  arch/arm/boot/dts/Makefile                         |    1 +
>  arch/arm/boot/dts/s3c2416-smdk2416.dts             |   79 ++++++++
>  arch/arm/boot/dts/s3c2416.dtsi                     |  193 ++++++++++++++++++++
>  arch/arm/boot/dts/s3c24xx.dtsi                     |  165 +++++++++++++++++
>  arch/arm/mach-s3c24xx/Kconfig                      |   10 +
>  arch/arm/mach-s3c24xx/Makefile                     |    3 +-
>  arch/arm/mach-s3c24xx/mach-s3c2416-dt.c            |   91 +++++++++
>  drivers/irqchip/Makefile                           |    1 +
>  .../irq.c => drivers/irqchip/irq-s3c24xx.c         |  128 +++++++++++++
>  10 files changed, 723 insertions(+), 1 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/interrupt-
> controller/samsung,s3c24xx-irq.txt
>  create mode 100644 arch/arm/boot/dts/s3c2416-smdk2416.dts
>  create mode 100644 arch/arm/boot/dts/s3c2416.dtsi
>  create mode 100644 arch/arm/boot/dts/s3c24xx.dtsi
>  create mode 100644 arch/arm/mach-s3c24xx/mach-s3c2416-dt.c
>  rename arch/arm/mach-s3c24xx/irq.c => drivers/irqchip/irq-s3c24xx.c (92%)
> 
> --
> 1.7.2.3

Basically, looks good to me and thanks for your effort.

BTW, if you don't mind, would be better to send to upstream next time. Because I need to consider other s3c24xx SoCs for DT...

Thanks.

- Kukjin



From zonque at gmail.com  Wed Apr 10 06:17:34 2013
From: zonque at gmail.com (Daniel Mack)
Date: Wed, 10 Apr 2013 12:17:34 +0200
Subject: [PATCH v7] clk: add si5351 i2c common clock driver
In-Reply-To: <1365586810-6752-1-git-send-email-sebastian.hesselbarth@gmail.com>
References: <1365439617-18816-1-git-send-email-sebastian.hesselbarth@gmail.com>
 <1365586810-6752-1-git-send-email-sebastian.hesselbarth@gmail.com>
Message-ID: <51653C3E.2020702@gmail.com>

On 10.04.2013 11:40, Sebastian Hesselbarth wrote:
> This patch adds a common clock driver for Silicon Labs Si5351a/b/c
> i2c programmable clock generators. Currently, the driver does not
> support VXCO feature of si5351b. Passing platform_data or DT bindings
> selectively allows to overwrite stored Si5351 configuration which is
> very helpful for clock generators with empty eeprom configuration.
> Corresponding device tree binding documentation is also added.
> 
> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
> ---
> I consider this v7 now as feature complete. Please review/test a
> hopefully last time and add your Acked-By/Tested-By. Thanks!

Tested-by: Daniel Mack <zonque at gmail.com>


Thanks again,
Daniel


> 
> Changes from v6:
> - make invalid DT data parsing fatal (Suggested by Guenter Roeck)
> - add more variant checks and return errors
> - remove inline from _si5351_* functions
> - remove pll reset/clkout powerdown for gapless tuning
>   (Provided by Michal Backraty)
> 
> Changes from v5:
> - removed __clk_set_flags
> - remove CONFIG_OF dependency
> - introduce si5351_platform_data (non-DT untested)
> - parse DT into si5351_platform_data (tested)
> - minor cleanups
> 
> Changes from v4:
> - move from clk-private.h to clk-provider.h (Reported by Mike Turquette)
> - use __clk_set_flags() helper
> 
> Changes from v3:
> - add silabs prefix to custom DT properties (Reported by Lars-Peter Clausen)
> - use sizeof(*foo) instead of sizeof(struct bar) (Reported by Lars-Peter Clausen)
> - check return value of of_clk_add_provider (Reported by Lars-Peter Clausen)
> - clean up i2c client init (Reported by Lars-Peter Clausen)
> - silence successful probe (Suggested by Lars-Peter Clausen)
> - make CONFIG_CLK_SI5351 depend on CONFIG_OF
> 
> Changes from v2:
> - add curly brackets to if-else-statements (Reported by Daniel Mack)
> - fix div-by-zero for clk6/clk7 (Reported by Daniel Mack)
> - fix parameter address calculation for clk6/clk7
> 
> Changes from v1:
> - remove .is_enabled functions as they read from i2c
>   (Reported by Daniel Mack)
> - add CLK_SET_RATE_PARENT on clkout reparent if clkout uses
>   its own multisync
> 
> Cc: Grant Likely <grant.likely at secretlab.ca>
> Cc: Rob Herring <rob.herring at calxeda.com>
> Cc: Rob Landley <rob at landley.net>
> Cc: Mike Turquette <mturquette at linaro.org>
> Cc: Stephen Warren <swarren at nvidia.com>
> Cc: Thierry Reding <thierry.reding at avionic-design.de>
> Cc: Dom Cobley <popcornmix at gmail.com>
> Cc: Linus Walleij <linus.walleij at linaro.org>
> Cc: Arnd Bergmann <arnd at arndb.de>
> Cc: Andrew Morton <akpm at linux-foundation.org>
> Cc: Pawel Moll <pawel.moll at arm.com>
> Cc: Mark Brown <broonie at opensource.wolfsonmicro.com>
> Cc: Russell King - ARM Linux <linux at arm.linux.org.uk>
> Cc: Rabeeh Khoury <rabeeh at solid-run.com>
> Cc: Daniel Mack <zonque at gmail.com>
> Cc: Jean-Francois Moine <moinejf at free.fr>
> Cc: Lars-Peter Clausen <lars at metafoo.de>
> Cc: Guenter Roeck <linux at roeck-us.net>
> Cc: Michal Bachraty <michal.bachraty at streamunlimited.com>
> Cc: devicetree-discuss at lists.ozlabs.org
> Cc: linux-doc at vger.kernel.org
> Cc: linux-kernel at vger.kernel.org
> Cc: linux-arm-kernel at lists.infradead.org
> ---
>  .../devicetree/bindings/clock/silabs,si5351.txt    |  114 ++
>  .../devicetree/bindings/vendor-prefixes.txt        |    1 +
>  drivers/clk/Kconfig                                |    9 +
>  drivers/clk/Makefile                               |    1 +
>  drivers/clk/clk-si5351.c                           | 1506 ++++++++++++++++++++
>  drivers/clk/clk-si5351.h                           |  155 ++
>  include/linux/platform_data/si5351.h               |  114 ++
>  7 files changed, 1900 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/clock/silabs,si5351.txt
>  create mode 100644 drivers/clk/clk-si5351.c
>  create mode 100644 drivers/clk/clk-si5351.h
>  create mode 100644 include/linux/platform_data/si5351.h
> 
> diff --git a/Documentation/devicetree/bindings/clock/silabs,si5351.txt b/Documentation/devicetree/bindings/clock/silabs,si5351.txt
> new file mode 100644
> index 0000000..cc37465
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/silabs,si5351.txt
> @@ -0,0 +1,114 @@
> +Binding for Silicon Labs Si5351a/b/c programmable i2c clock generator.
> +
> +Reference
> +[1] Si5351A/B/C Data Sheet
> +    http://www.silabs.com/Support%20Documents/TechnicalDocs/Si5351.pdf
> +
> +The Si5351a/b/c are programmable i2c clock generators with upto 8 output
> +clocks. Si5351a also has a reduced pin-count package (MSOP10) where only
> +3 output clocks are accessible. The internal structure of the clock
> +generators can be found in [1].
> +
> +==I2C device node==
> +
> +Required properties:
> +- compatible: shall be one of "silabs,si5351{a,a-msop,b,c}".
> +- reg: i2c device address, shall be 0x60 or 0x61.
> +- #clock-cells: from common clock binding; shall be set to 1.
> +- clocks: from common clock binding; list of parent clock
> +  handles, shall be xtal reference clock or xtal and clkin for
> +  si5351c only.
> +- #address-cells: shall be set to 1.
> +- #size-cells: shall be set to 0.
> +
> +Optional properties:
> +- silabs,pll-source: pair of (number, source) for each pll. Allows
> +  to overwrite clock source of pll A (number=0) or B (number=1).
> +
> +==Child nodes==
> +
> +Each of the clock outputs can be overwritten individually by
> +using a child node to the I2C device node. If a child node for a clock
> +output is not set, the eeprom configuration is not overwritten.
> +
> +Required child node properties:
> +- reg: number of clock output.
> +
> +Optional child node properties:
> +- silabs,clock-source: source clock of the output divider stage N, shall be
> +  0 = multisynth N
> +  1 = multisynth 0 for output clocks 0-3, else multisynth4
> +  2 = xtal
> +  3 = clkin (si5351c only)
> +- silabs,drive-strength: output drive strength in mA, shall be one of {2,4,6,8}.
> +- silabs,multisynth-source: source pll A(0) or B(1) of corresponding multisynth
> +  divider.
> +- silabs,pll-master: boolean, multisynth can change pll frequency.
> +
> +==Example==
> +
> +/* 25MHz reference crystal */
> +ref25: ref25M {
> +	compatible = "fixed-clock";
> +	#clock-cells = <0>;
> +	clock-frequency = <25000000>;
> +};
> +
> +i2c-master-node {
> +
> +	/* Si5351a msop10 i2c clock generator */
> +	si5351a: clock-generator at 60 {
> +		compatible = "silabs,si5351a-msop";
> +		reg = <0x60>;
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +		#clock-cells = <1>;
> +
> +		/* connect xtal input to 25MHz reference */
> +		clocks = <&ref25>;
> +
> +		/* connect xtal input as source of pll0 and pll1 */
> +		silabs,pll-source = <0 0>, <1 0>;
> +
> +		/*
> +		 * overwrite clkout0 configuration with:
> +		 * - 8mA output drive strength
> +		 * - pll0 as clock source of multisynth0
> +		 * - multisynth0 as clock source of output divider
> +		 * - multisynth0 can change pll0
> +		 * - set initial clock frequency of 74.25MHz
> +		 */
> +		clkout0 {
> +			reg = <0>;
> +			silabs,drive-strength = <8>;
> +			silabs,multisynth-source = <0>;
> +			silabs,clock-source = <0>;
> +			silabs,pll-master;
> +			clock-frequency = <74250000>;
> +		};
> +
> +		/*
> +		 * overwrite clkout1 configuration with:
> +		 * - 4mA output drive strength
> +		 * - pll1 as clock source of multisynth1
> +		 * - multisynth1 as clock source of output divider
> +		 * - multisynth1 can change pll1
> +		 */
> +		clkout1 {
> +			reg = <1>;
> +			silabs,drive-strength = <4>;
> +			silabs,multisynth-source = <1>;
> +			silabs,clock-source = <0>;
> +			pll-master;
> +		};
> +
> +		/*
> +		 * overwrite clkout2 configuration with:
> +		 * - xtal as clock source of output divider
> +		 */
> +		clkout2 {
> +			reg = <2>;
> +			silabs,clock-source = <2>;
> +		};
> +	};
> +};
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
> index 19e1ef7..ca60849 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> @@ -48,6 +48,7 @@ samsung	Samsung Semiconductor
>  sbs	Smart Battery System
>  schindler	Schindler
>  sil	Silicon Image
> +silabs	Silicon Laboratories
>  simtek
>  sirf	SiRF Technology, Inc.
>  snps 	Synopsys, Inc.
> diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
> index a47e6ee..5039e41 100644
> --- a/drivers/clk/Kconfig
> +++ b/drivers/clk/Kconfig
> @@ -55,6 +55,15 @@ config COMMON_CLK_MAX77686
>  	---help---
>  	  This driver supports Maxim 77686 crystal oscillator clock. 
>  
> +config COMMON_CLK_SI5351
> +	tristate "Clock driver for SiLabs 5351A/B/C"
> +	depends on I2C
> +	select REGMAP_I2C
> +	select RATIONAL
> +	---help---
> +	  This driver supports Silicon Labs 5351A/B/C programmable clock
> +	  generators.
> +
>  config CLK_TWL6040
>  	tristate "External McPDM functional clock from twl6040"
>  	depends on TWL6040_CORE
> diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
> index 300d477..92ca698 100644
> --- a/drivers/clk/Makefile
> +++ b/drivers/clk/Makefile
> @@ -33,4 +33,5 @@ obj-$(CONFIG_X86)		+= x86/
>  # Chip specific
>  obj-$(CONFIG_COMMON_CLK_WM831X) += clk-wm831x.o
>  obj-$(CONFIG_COMMON_CLK_MAX77686) += clk-max77686.o
> +obj-$(CONFIG_COMMON_CLK_SI5351) += clk-si5351.o
>  obj-$(CONFIG_CLK_TWL6040)	+= clk-twl6040.o
> diff --git a/drivers/clk/clk-si5351.c b/drivers/clk/clk-si5351.c
> new file mode 100644
> index 0000000..4e2506c
> --- /dev/null
> +++ b/drivers/clk/clk-si5351.c
> @@ -0,0 +1,1506 @@
> +/*
> + * clk-si5351.c: Silicon Laboratories Si5351A/B/C I2C Clock Generator
> + *
> + * Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
> + * Rabeeh Khoury <rabeeh at solid-run.com>
> + *
> + * References:
> + * [1] "Si5351A/B/C Data Sheet"
> + *     http://www.silabs.com/Support%20Documents/TechnicalDocs/Si5351.pdf
> + * [2] "Manually Generating an Si5351 Register Map"
> + *     http://www.silabs.com/Support%20Documents/TechnicalDocs/AN619.pdf
> + *
> + * 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.
> + */
> +
> +#include <linux/module.h>
> +#include <linux/kernel.h>
> +#include <linux/clkdev.h>
> +#include <linux/clk-provider.h>
> +#include <linux/delay.h>
> +#include <linux/err.h>
> +#include <linux/errno.h>
> +#include <linux/rational.h>
> +#include <linux/i2c.h>
> +#include <linux/of_platform.h>
> +#include <linux/platform_data/si5351.h>
> +#include <linux/regmap.h>
> +#include <linux/slab.h>
> +#include <linux/string.h>
> +#include <asm/div64.h>
> +
> +#include "clk-si5351.h"
> +
> +struct si5351_driver_data;
> +
> +struct si5351_parameters {
> +	unsigned long	p1;
> +	unsigned long	p2;
> +	unsigned long	p3;
> +	int		valid;
> +};
> +
> +struct si5351_hw_data {
> +	struct clk_hw			hw;
> +	struct si5351_driver_data	*drvdata;
> +	struct si5351_parameters	params;
> +	unsigned char			num;
> +};
> +
> +struct si5351_driver_data {
> +	enum si5351_variant	variant;
> +	struct i2c_client	*client;
> +	struct regmap		*regmap;
> +	struct clk_onecell_data onecell;
> +
> +	struct clk		*pxtal;
> +	const char		*pxtal_name;
> +	struct clk_hw		xtal;
> +	struct clk		*pclkin;
> +	const char		*pclkin_name;
> +	struct clk_hw		clkin;
> +
> +	struct si5351_hw_data	pll[2];
> +	struct si5351_hw_data	*msynth;
> +	struct si5351_hw_data	*clkout;
> +};
> +
> +static const char const *si5351_input_names[] = {
> +	"xtal", "clkin"
> +};
> +static const char const *si5351_pll_names[] = {
> +	"plla", "pllb", "vxco"
> +};
> +static const char const *si5351_msynth_names[] = {
> +	"ms0", "ms1", "ms2", "ms3", "ms4", "ms5", "ms6", "ms7"
> +};
> +static const char const *si5351_clkout_names[] = {
> +	"clk0", "clk1", "clk2", "clk3", "clk4", "clk5", "clk6", "clk7"
> +};
> +
> +/*
> + * Si5351 i2c regmap
> + */
> +static inline u8 si5351_reg_read(struct si5351_driver_data *drvdata, u8 reg)
> +{
> +	u32 val;
> +	int ret;
> +
> +	ret = regmap_read(drvdata->regmap, reg, &val);
> +	if (ret) {
> +		dev_err(&drvdata->client->dev,
> +			"unable to read from reg%02x\n", reg);
> +		return 0;
> +	}
> +
> +	return (u8)val;
> +}
> +
> +static inline int si5351_bulk_read(struct si5351_driver_data *drvdata,
> +				   u8 reg, u8 count, u8 *buf)
> +{
> +	return regmap_bulk_read(drvdata->regmap, reg, buf, count);
> +}
> +
> +static inline int si5351_reg_write(struct si5351_driver_data *drvdata,
> +				   u8 reg, u8 val)
> +{
> +	return regmap_write(drvdata->regmap, reg, val);
> +}
> +
> +static inline int si5351_bulk_write(struct si5351_driver_data *drvdata,
> +				    u8 reg, u8 count, const u8 *buf)
> +{
> +	return regmap_raw_write(drvdata->regmap, reg, buf, count);
> +}
> +
> +static inline int si5351_set_bits(struct si5351_driver_data *drvdata,
> +				  u8 reg, u8 mask, u8 val)
> +{
> +	return regmap_update_bits(drvdata->regmap, reg, mask, val);
> +}
> +
> +static inline u8 si5351_msynth_params_address(int num)
> +{
> +	if (num > 5)
> +		return SI5351_CLK6_PARAMETERS + (num - 6);
> +	return SI5351_CLK0_PARAMETERS + (SI5351_PARAMETERS_LENGTH * num);
> +}
> +
> +static void si5351_read_parameters(struct si5351_driver_data *drvdata,
> +				   u8 reg, struct si5351_parameters *params)
> +{
> +	u8 buf[SI5351_PARAMETERS_LENGTH];
> +
> +	switch (reg) {
> +	case SI5351_CLK6_PARAMETERS:
> +	case SI5351_CLK7_PARAMETERS:
> +		buf[0] = si5351_reg_read(drvdata, reg);
> +		params->p1 = buf[0];
> +		params->p2 = 0;
> +		params->p3 = 1;
> +		break;
> +	default:
> +		si5351_bulk_read(drvdata, reg, SI5351_PARAMETERS_LENGTH, buf);
> +		params->p1 = ((buf[2] & 0x03) << 16) | (buf[3] << 8) | buf[4];
> +		params->p2 = ((buf[5] & 0x0f) << 16) | (buf[6] << 8) | buf[7];
> +		params->p3 = ((buf[5] & 0xf0) << 12) | (buf[0] << 8) | buf[1];
> +	}
> +	params->valid = 1;
> +}
> +
> +static void si5351_write_parameters(struct si5351_driver_data *drvdata,
> +				    u8 reg, struct si5351_parameters *params)
> +{
> +	u8 buf[SI5351_PARAMETERS_LENGTH];
> +
> +	switch (reg) {
> +	case SI5351_CLK6_PARAMETERS:
> +	case SI5351_CLK7_PARAMETERS:
> +		buf[0] = params->p1 & 0xff;
> +		si5351_reg_write(drvdata, reg, buf[0]);
> +		break;
> +	default:
> +		buf[0] = ((params->p3 & 0x0ff00) >> 8) & 0xff;
> +		buf[1] = params->p3 & 0xff;
> +		/* save rdiv and divby4 */
> +		buf[2] = si5351_reg_read(drvdata, reg + 2) & ~0x03;
> +		buf[2] |= ((params->p1 & 0x30000) >> 16) & 0x03;
> +		buf[3] = ((params->p1 & 0x0ff00) >> 8) & 0xff;
> +		buf[4] = params->p1 & 0xff;
> +		buf[5] = ((params->p3 & 0xf0000) >> 12) |
> +			((params->p2 & 0xf0000) >> 16);
> +		buf[6] = ((params->p2 & 0x0ff00) >> 8) & 0xff;
> +		buf[7] = params->p2 & 0xff;
> +		si5351_bulk_write(drvdata, reg, SI5351_PARAMETERS_LENGTH, buf);
> +	}
> +}
> +
> +static bool si5351_regmap_is_volatile(struct device *dev, unsigned int reg)
> +{
> +	switch (reg) {
> +	case SI5351_DEVICE_STATUS:
> +	case SI5351_INTERRUPT_STATUS:
> +	case SI5351_PLL_RESET:
> +		return true;
> +	}
> +	return false;
> +}
> +
> +static bool si5351_regmap_is_writeable(struct device *dev, unsigned int reg)
> +{
> +	/* reserved registers */
> +	if (reg >= 4 && reg <= 8)
> +		return false;
> +	if (reg >= 10 && reg <= 14)
> +		return false;
> +	if (reg >= 173 && reg <= 176)
> +		return false;
> +	if (reg >= 178 && reg <= 182)
> +		return false;
> +	/* read-only */
> +	if (reg == SI5351_DEVICE_STATUS)
> +		return false;
> +	return true;
> +}
> +
> +static struct regmap_config si5351_regmap_config = {
> +	.reg_bits = 8,
> +	.val_bits = 8,
> +	.cache_type = REGCACHE_RBTREE,
> +	.max_register = 187,
> +	.writeable_reg = si5351_regmap_is_writeable,
> +	.volatile_reg = si5351_regmap_is_volatile,
> +};
> +
> +/*
> + * Si5351 xtal clock input
> + */
> +static int si5351_xtal_prepare(struct clk_hw *hw)
> +{
> +	struct si5351_driver_data *drvdata =
> +		container_of(hw, struct si5351_driver_data, xtal);
> +	si5351_set_bits(drvdata, SI5351_FANOUT_ENABLE,
> +			SI5351_XTAL_ENABLE, SI5351_XTAL_ENABLE);
> +	return 0;
> +}
> +
> +static void si5351_xtal_unprepare(struct clk_hw *hw)
> +{
> +	struct si5351_driver_data *drvdata =
> +		container_of(hw, struct si5351_driver_data, xtal);
> +	si5351_set_bits(drvdata, SI5351_FANOUT_ENABLE,
> +			SI5351_XTAL_ENABLE, 0);
> +}
> +
> +static const struct clk_ops si5351_xtal_ops = {
> +	.prepare = si5351_xtal_prepare,
> +	.unprepare = si5351_xtal_unprepare,
> +};
> +
> +/*
> + * Si5351 clkin clock input (Si5351C only)
> + */
> +static int si5351_clkin_prepare(struct clk_hw *hw)
> +{
> +	struct si5351_driver_data *drvdata =
> +		container_of(hw, struct si5351_driver_data, clkin);
> +	si5351_set_bits(drvdata, SI5351_FANOUT_ENABLE,
> +			SI5351_CLKIN_ENABLE, SI5351_CLKIN_ENABLE);
> +	return 0;
> +}
> +
> +static void si5351_clkin_unprepare(struct clk_hw *hw)
> +{
> +	struct si5351_driver_data *drvdata =
> +		container_of(hw, struct si5351_driver_data, clkin);
> +	si5351_set_bits(drvdata, SI5351_FANOUT_ENABLE,
> +			SI5351_CLKIN_ENABLE, 0);
> +}
> +
> +/*
> + * CMOS clock source constraints:
> + * The input frequency range of the PLL is 10Mhz to 40MHz.
> + * If CLKIN is >40MHz, the input divider must be used.
> + */
> +static unsigned long si5351_clkin_recalc_rate(struct clk_hw *hw,
> +					      unsigned long parent_rate)
> +{
> +	struct si5351_driver_data *drvdata =
> +		container_of(hw, struct si5351_driver_data, clkin);
> +	unsigned long rate;
> +	unsigned char idiv;
> +
> +	rate = parent_rate;
> +	if (parent_rate > 160000000) {
> +		idiv = SI5351_CLKIN_DIV_8;
> +		rate /= 8;
> +	} else if (parent_rate > 80000000) {
> +		idiv = SI5351_CLKIN_DIV_4;
> +		rate /= 4;
> +	} else if (parent_rate > 40000000) {
> +		idiv = SI5351_CLKIN_DIV_2;
> +		rate /= 2;
> +	} else {
> +		idiv = SI5351_CLKIN_DIV_1;
> +	}
> +
> +	si5351_set_bits(drvdata, SI5351_PLL_INPUT_SOURCE,
> +			SI5351_CLKIN_DIV_MASK, idiv);
> +
> +	dev_dbg(&drvdata->client->dev, "%s - clkin div = %d, rate = %lu\n",
> +		__func__, (1 << (idiv >> 6)), rate);
> +
> +	return rate;
> +}
> +
> +static const struct clk_ops si5351_clkin_ops = {
> +	.prepare = si5351_clkin_prepare,
> +	.unprepare = si5351_clkin_unprepare,
> +	.recalc_rate = si5351_clkin_recalc_rate,
> +};
> +
> +/*
> + * Si5351 vxco clock input (Si5351B only)
> + */
> +
> +static int si5351_vxco_prepare(struct clk_hw *hw)
> +{
> +	struct si5351_hw_data *hwdata =
> +		container_of(hw, struct si5351_hw_data, hw);
> +
> +	dev_warn(&hwdata->drvdata->client->dev, "VXCO currently unsupported\n");
> +
> +	return 0;
> +}
> +
> +static void si5351_vxco_unprepare(struct clk_hw *hw)
> +{
> +}
> +
> +static unsigned long si5351_vxco_recalc_rate(struct clk_hw *hw,
> +					     unsigned long parent_rate)
> +{
> +	return 0;
> +}
> +
> +static int si5351_vxco_set_rate(struct clk_hw *hw, unsigned long rate,
> +				unsigned long parent)
> +{
> +	return 0;
> +}
> +
> +static const struct clk_ops si5351_vxco_ops = {
> +	.prepare = si5351_vxco_prepare,
> +	.unprepare = si5351_vxco_unprepare,
> +	.recalc_rate = si5351_vxco_recalc_rate,
> +	.set_rate = si5351_vxco_set_rate,
> +};
> +
> +/*
> + * Si5351 pll a/b
> + *
> + * Feedback Multisynth Divider Equations [2]
> + *
> + * fVCO = fIN * (a + b/c)
> + *
> + * with 15 + 0/1048575 <= (a + b/c) <= 90 + 0/1048575 and
> + * fIN = fXTAL or fIN = fCLKIN/CLKIN_DIV
> + *
> + * Feedback Multisynth Register Equations
> + *
> + * (1) MSNx_P1[17:0] = 128 * a + floor(128 * b/c) - 512
> + * (2) MSNx_P2[19:0] = 128 * b - c * floor(128 * b/c) = (128*b) mod c
> + * (3) MSNx_P3[19:0] = c
> + *
> + * Transposing (2) yields: (4) floor(128 * b/c) = (128 * b / MSNx_P2)/c
> + *
> + * Using (4) on (1) yields:
> + * MSNx_P1 = 128 * a + (128 * b/MSNx_P2)/c - 512
> + * MSNx_P1 + 512 + MSNx_P2/c = 128 * a + 128 * b/c
> + *
> + * a + b/c = (MSNx_P1 + MSNx_P2/MSNx_P3 + 512)/128
> + *         = (MSNx_P1*MSNx_P3 + MSNx_P2 + 512*MSNx_P3)/(128*MSNx_P3)
> + *
> + */
> +static int _si5351_pll_reparent(struct si5351_driver_data *drvdata,
> +				int num, enum si5351_pll_src parent)
> +{
> +	u8 mask = (num == 0) ? SI5351_PLLA_SOURCE : SI5351_PLLB_SOURCE;
> +
> +	if (parent == SI5351_PLL_SRC_DEFAULT)
> +		return 0;
> +
> +	if (num > 2)
> +		return -EINVAL;
> +
> +	if (drvdata->variant != SI5351_VARIANT_C &&
> +	    parent != SI5351_PLL_SRC_XTAL)
> +		return -EINVAL;
> +
> +	si5351_set_bits(drvdata, SI5351_PLL_INPUT_SOURCE, mask,
> +			(parent == SI5351_PLL_SRC_XTAL) ? 0 : mask);
> +	return 0;
> +}
> +
> +static unsigned char si5351_pll_get_parent(struct clk_hw *hw)
> +{
> +	struct si5351_hw_data *hwdata =
> +		container_of(hw, struct si5351_hw_data, hw);
> +	u8 mask = (hwdata->num == 0) ? SI5351_PLLA_SOURCE : SI5351_PLLB_SOURCE;
> +	u8 val;
> +
> +	val = si5351_reg_read(hwdata->drvdata, SI5351_PLL_INPUT_SOURCE);
> +
> +	return (val & mask) ? 1 : 0;
> +}
> +
> +static int si5351_pll_set_parent(struct clk_hw *hw, u8 index)
> +{
> +	struct si5351_hw_data *hwdata =
> +		container_of(hw, struct si5351_hw_data, hw);
> +
> +	if (hwdata->drvdata->variant != SI5351_VARIANT_C &&
> +	    index > 0)
> +		return -EPERM;
> +
> +	if (index > 1)
> +		return -EINVAL;
> +
> +	return _si5351_pll_reparent(hwdata->drvdata, hwdata->num,
> +			     (index == 0) ? SI5351_PLL_SRC_XTAL :
> +			     SI5351_PLL_SRC_CLKIN);
> +}
> +
> +static unsigned long si5351_pll_recalc_rate(struct clk_hw *hw,
> +					    unsigned long parent_rate)
> +{
> +	struct si5351_hw_data *hwdata =
> +		container_of(hw, struct si5351_hw_data, hw);
> +	u8 reg = (hwdata->num == 0) ? SI5351_PLLA_PARAMETERS :
> +		SI5351_PLLB_PARAMETERS;
> +	unsigned long long rate;
> +
> +	if (!hwdata->params.valid)
> +		si5351_read_parameters(hwdata->drvdata, reg, &hwdata->params);
> +
> +	if (hwdata->params.p3 == 0)
> +		return parent_rate;
> +
> +	/* fVCO = fIN * (P1*P3 + 512*P3 + P2)/(128*P3) */
> +	rate  = hwdata->params.p1 * hwdata->params.p3;
> +	rate += 512 * hwdata->params.p3;
> +	rate += hwdata->params.p2;
> +	rate *= parent_rate;
> +	do_div(rate, 128 * hwdata->params.p3);
> +
> +	dev_dbg(&hwdata->drvdata->client->dev,
> +		"%s - %s: p1 = %lu, p2 = %lu, p3 = %lu, parent_rate = %lu, rate = %lu\n",
> +		__func__, __clk_get_name(hwdata->hw.clk),
> +		hwdata->params.p1, hwdata->params.p2, hwdata->params.p3,
> +		parent_rate, (unsigned long)rate);
> +
> +	return (unsigned long)rate;
> +}
> +
> +static long si5351_pll_round_rate(struct clk_hw *hw, unsigned long rate,
> +				  unsigned long *parent_rate)
> +{
> +	struct si5351_hw_data *hwdata =
> +		container_of(hw, struct si5351_hw_data, hw);
> +	unsigned long rfrac, denom, a, b, c;
> +	unsigned long long lltmp;
> +
> +	if (rate < SI5351_PLL_VCO_MIN)
> +		rate = SI5351_PLL_VCO_MIN;
> +	if (rate > SI5351_PLL_VCO_MAX)
> +		rate = SI5351_PLL_VCO_MAX;
> +
> +	/* determine integer part of feedback equation */
> +	a = rate / *parent_rate;
> +
> +	if (a < SI5351_PLL_A_MIN)
> +		rate = *parent_rate * SI5351_PLL_A_MIN;
> +	if (a > SI5351_PLL_A_MAX)
> +		rate = *parent_rate * SI5351_PLL_A_MAX;
> +
> +	/* find best approximation for b/c = fVCO mod fIN */
> +	denom = 1000 * 1000;
> +	lltmp = rate % (*parent_rate);
> +	lltmp *= denom;
> +	do_div(lltmp, *parent_rate);
> +	rfrac = (unsigned long)lltmp;
> +
> +	b = 0;
> +	c = 1;
> +	if (rfrac)
> +		rational_best_approximation(rfrac, denom,
> +				    SI5351_PLL_B_MAX, SI5351_PLL_C_MAX, &b, &c);
> +
> +	/* calculate parameters */
> +	hwdata->params.p3  = c;
> +	hwdata->params.p2  = (128 * b) % c;
> +	hwdata->params.p1  = 128 * a;
> +	hwdata->params.p1 += (128 * b / c);
> +	hwdata->params.p1 -= 512;
> +
> +	/* recalculate rate by fIN * (a + b/c) */
> +	lltmp  = *parent_rate;
> +	lltmp *= b;
> +	do_div(lltmp, c);
> +
> +	rate  = (unsigned long)lltmp;
> +	rate += *parent_rate * a;
> +
> +	dev_dbg(&hwdata->drvdata->client->dev,
> +		"%s - %s: a = %lu, b = %lu, c = %lu, parent_rate = %lu, rate = %lu\n",
> +		__func__, __clk_get_name(hwdata->hw.clk), a, b, c,
> +		*parent_rate, rate);
> +
> +	return rate;
> +}
> +
> +static int si5351_pll_set_rate(struct clk_hw *hw, unsigned long rate,
> +			       unsigned long parent_rate)
> +{
> +	struct si5351_hw_data *hwdata =
> +		container_of(hw, struct si5351_hw_data, hw);
> +	u8 reg = (hwdata->num == 0) ? SI5351_PLLA_PARAMETERS :
> +		SI5351_PLLB_PARAMETERS;
> +
> +	/* write multisynth parameters */
> +	si5351_write_parameters(hwdata->drvdata, reg, &hwdata->params);
> +
> +	/* plla/pllb ctrl is in clk6/clk7 ctrl registers */
> +	si5351_set_bits(hwdata->drvdata, SI5351_CLK6_CTRL + hwdata->num,
> +		SI5351_CLK_INTEGER_MODE,
> +		(hwdata->params.p2 == 0) ? SI5351_CLK_INTEGER_MODE : 0);
> +
> +	dev_dbg(&hwdata->drvdata->client->dev,
> +		"%s - %s: p1 = %lu, p2 = %lu, p3 = %lu, parent_rate = %lu, rate = %lu\n",
> +		__func__, __clk_get_name(hwdata->hw.clk),
> +		hwdata->params.p1, hwdata->params.p2, hwdata->params.p3,
> +		parent_rate, rate);
> +
> +	return 0;
> +}
> +
> +static const struct clk_ops si5351_pll_ops = {
> +	.set_parent = si5351_pll_set_parent,
> +	.get_parent = si5351_pll_get_parent,
> +	.recalc_rate = si5351_pll_recalc_rate,
> +	.round_rate = si5351_pll_round_rate,
> +	.set_rate = si5351_pll_set_rate,
> +};
> +
> +/*
> + * Si5351 multisync divider
> + *
> + * for fOUT <= 150 MHz:
> + *
> + * fOUT = (fIN * (a + b/c)) / CLKOUTDIV
> + *
> + * with 6 + 0/1048575 <= (a + b/c) <= 1800 + 0/1048575 and
> + * fIN = fVCO0, fVCO1
> + *
> + * Output Clock Multisynth Register Equations
> + *
> + * MSx_P1[17:0] = 128 * a + floor(128 * b/c) - 512
> + * MSx_P2[19:0] = 128 * b - c * floor(128 * b/c) = (128*b) mod c
> + * MSx_P3[19:0] = c
> + *
> + * MS[6,7] are integer (P1) divide only, P2 = 0, P3 = 0
> + *
> + * for 150MHz < fOUT <= 160MHz:
> + *
> + * MSx_P1 = 0, MSx_P2 = 0, MSx_P3 = 1, MSx_INT = 1, MSx_DIVBY4 = 11b
> + */
> +static int _si5351_msynth_reparent(struct si5351_driver_data *drvdata,
> +				   int num, enum si5351_multisynth_src parent)
> +{
> +	if (parent == SI5351_MULTISYNTH_SRC_DEFAULT)
> +		return 0;
> +
> +	if (num > 8)
> +		return -EINVAL;
> +
> +	si5351_set_bits(drvdata, SI5351_CLK0_CTRL + num, SI5351_CLK_PLL_SELECT,
> +			(parent == SI5351_MULTISYNTH_SRC_VCO0) ? 0 :
> +			SI5351_CLK_PLL_SELECT);
> +	return 0;
> +}
> +
> +static unsigned char si5351_msynth_get_parent(struct clk_hw *hw)
> +{
> +	struct si5351_hw_data *hwdata =
> +		container_of(hw, struct si5351_hw_data, hw);
> +	u8 val;
> +
> +	val = si5351_reg_read(hwdata->drvdata, SI5351_CLK0_CTRL + hwdata->num);
> +
> +	return (val & SI5351_CLK_PLL_SELECT) ? 1 : 0;
> +}
> +
> +static int si5351_msynth_set_parent(struct clk_hw *hw, u8 index)
> +{
> +	struct si5351_hw_data *hwdata =
> +		container_of(hw, struct si5351_hw_data, hw);
> +
> +	return _si5351_msynth_reparent(hwdata->drvdata, hwdata->num,
> +			       (index == 0) ? SI5351_MULTISYNTH_SRC_VCO0 :
> +			       SI5351_MULTISYNTH_SRC_VCO1);
> +}
> +
> +static unsigned long si5351_msynth_recalc_rate(struct clk_hw *hw,
> +					       unsigned long parent_rate)
> +{
> +	struct si5351_hw_data *hwdata =
> +		container_of(hw, struct si5351_hw_data, hw);
> +	u8 reg = si5351_msynth_params_address(hwdata->num);
> +	unsigned long long rate;
> +	unsigned long m;
> +
> +	if (!hwdata->params.valid)
> +		si5351_read_parameters(hwdata->drvdata, reg, &hwdata->params);
> +
> +	if (hwdata->params.p3 == 0)
> +		return parent_rate;
> +
> +	/*
> +	 * multisync0-5: fOUT = (128 * P3 * fIN) / (P1*P3 + P2 + 512*P3)
> +	 * multisync6-7: fOUT = fIN / P1
> +	 */
> +	rate = parent_rate;
> +	if (hwdata->num > 5) {
> +		m = hwdata->params.p1;
> +	} else if ((si5351_reg_read(hwdata->drvdata, reg + 2) &
> +		    SI5351_OUTPUT_CLK_DIVBY4) == SI5351_OUTPUT_CLK_DIVBY4) {
> +		m = 4;
> +	} else {
> +		rate *= 128 * hwdata->params.p3;
> +		m = hwdata->params.p1 * hwdata->params.p3;
> +		m += hwdata->params.p2;
> +		m += 512 * hwdata->params.p3;
> +	}
> +
> +	if (m == 0)
> +		return 0;
> +	do_div(rate, m);
> +
> +	dev_dbg(&hwdata->drvdata->client->dev,
> +		"%s - %s: p1 = %lu, p2 = %lu, p3 = %lu, m = %lu, parent_rate = %lu, rate = %lu\n",
> +		__func__, __clk_get_name(hwdata->hw.clk),
> +		hwdata->params.p1, hwdata->params.p2, hwdata->params.p3,
> +		m, parent_rate, (unsigned long)rate);
> +
> +	return (unsigned long)rate;
> +}
> +
> +static long si5351_msynth_round_rate(struct clk_hw *hw, unsigned long rate,
> +				     unsigned long *parent_rate)
> +{
> +	struct si5351_hw_data *hwdata =
> +		container_of(hw, struct si5351_hw_data, hw);
> +	unsigned long long lltmp;
> +	unsigned long a, b, c;
> +	int divby4;
> +
> +	/* multisync6-7 can only handle freqencies < 150MHz */
> +	if (hwdata->num >= 6 && rate > SI5351_MULTISYNTH67_MAX_FREQ)
> +		rate = SI5351_MULTISYNTH67_MAX_FREQ;
> +
> +	/* multisync frequency is 1MHz .. 160MHz */
> +	if (rate > SI5351_MULTISYNTH_MAX_FREQ)
> +		rate = SI5351_MULTISYNTH_MAX_FREQ;
> +	if (rate < SI5351_MULTISYNTH_MIN_FREQ)
> +		rate = SI5351_MULTISYNTH_MIN_FREQ;
> +
> +	divby4 = 0;
> +	if (rate > SI5351_MULTISYNTH_DIVBY4_FREQ)
> +		divby4 = 1;
> +
> +	/* multisync can set pll */
> +	if (__clk_get_flags(hwdata->hw.clk) & CLK_SET_RATE_PARENT) {
> +		/*
> +		 * find largest integer divider for max
> +		 * vco frequency and given target rate
> +		 */
> +		if (divby4 == 0) {
> +			lltmp = SI5351_PLL_VCO_MAX;
> +			do_div(lltmp, rate);
> +			a = (unsigned long)lltmp;
> +		} else
> +			a = 4;
> +
> +		b = 0;
> +		c = 1;
> +
> +		*parent_rate = a * rate;
> +	} else {
> +		unsigned long rfrac, denom;
> +
> +		/* disable divby4 */
> +		if (divby4) {
> +			rate = SI5351_MULTISYNTH_DIVBY4_FREQ;
> +			divby4 = 0;
> +		}
> +
> +		/* determine integer part of divider equation */
> +		a = *parent_rate / rate;
> +		if (a < SI5351_MULTISYNTH_A_MIN)
> +			a = SI5351_MULTISYNTH_A_MIN;
> +		if (hwdata->num >= 6 && a > SI5351_MULTISYNTH67_A_MAX)
> +			a = SI5351_MULTISYNTH67_A_MAX;
> +		else if (a > SI5351_MULTISYNTH_A_MAX)
> +			a = SI5351_MULTISYNTH_A_MAX;
> +
> +		/* find best approximation for b/c = fVCO mod fOUT */
> +		denom = 1000 * 1000;
> +		lltmp = (*parent_rate) % rate;
> +		lltmp *= denom;
> +		do_div(lltmp, rate);
> +		rfrac = (unsigned long)lltmp;
> +
> +		b = 0;
> +		c = 1;
> +		if (rfrac)
> +			rational_best_approximation(rfrac, denom,
> +			    SI5351_MULTISYNTH_B_MAX, SI5351_MULTISYNTH_C_MAX,
> +			    &b, &c);
> +	}
> +
> +	/* recalculate rate by fOUT = fIN / (a + b/c) */
> +	lltmp  = *parent_rate;
> +	lltmp *= c;
> +	do_div(lltmp, a * c + b);
> +	rate  = (unsigned long)lltmp;
> +
> +	/* calculate parameters */
> +	if (divby4) {
> +		hwdata->params.p3 = 1;
> +		hwdata->params.p2 = 0;
> +		hwdata->params.p1 = 0;
> +	} else {
> +		hwdata->params.p3  = c;
> +		hwdata->params.p2  = (128 * b) % c;
> +		hwdata->params.p1  = 128 * a;
> +		hwdata->params.p1 += (128 * b / c);
> +		hwdata->params.p1 -= 512;
> +	}
> +
> +	dev_dbg(&hwdata->drvdata->client->dev,
> +		"%s - %s: a = %lu, b = %lu, c = %lu, divby4 = %d, parent_rate = %lu, rate = %lu\n",
> +		__func__, __clk_get_name(hwdata->hw.clk), a, b, c, divby4,
> +		*parent_rate, rate);
> +
> +	return rate;
> +}
> +
> +static int si5351_msynth_set_rate(struct clk_hw *hw, unsigned long rate,
> +				  unsigned long parent_rate)
> +{
> +	struct si5351_hw_data *hwdata =
> +		container_of(hw, struct si5351_hw_data, hw);
> +	u8 reg = si5351_msynth_params_address(hwdata->num);
> +	int divby4 = 0;
> +
> +	/* write multisynth parameters */
> +	si5351_write_parameters(hwdata->drvdata, reg, &hwdata->params);
> +
> +	if (rate > SI5351_MULTISYNTH_DIVBY4_FREQ)
> +		divby4 = 1;
> +
> +	/* enable/disable integer mode and divby4 on multisynth0-5 */
> +	if (hwdata->num < 6) {
> +		si5351_set_bits(hwdata->drvdata, reg + 2,
> +				SI5351_OUTPUT_CLK_DIVBY4,
> +				(divby4) ? SI5351_OUTPUT_CLK_DIVBY4 : 0);
> +		si5351_set_bits(hwdata->drvdata, SI5351_CLK0_CTRL + hwdata->num,
> +			SI5351_CLK_INTEGER_MODE,
> +			(hwdata->params.p2 == 0) ? SI5351_CLK_INTEGER_MODE : 0);
> +	}
> +
> +	dev_dbg(&hwdata->drvdata->client->dev,
> +		"%s - %s: p1 = %lu, p2 = %lu, p3 = %lu, divby4 = %d, parent_rate = %lu, rate = %lu\n",
> +		__func__, __clk_get_name(hwdata->hw.clk),
> +		hwdata->params.p1, hwdata->params.p2, hwdata->params.p3,
> +		divby4, parent_rate, rate);
> +
> +	return 0;
> +}
> +
> +static const struct clk_ops si5351_msynth_ops = {
> +	.set_parent = si5351_msynth_set_parent,
> +	.get_parent = si5351_msynth_get_parent,
> +	.recalc_rate = si5351_msynth_recalc_rate,
> +	.round_rate = si5351_msynth_round_rate,
> +	.set_rate = si5351_msynth_set_rate,
> +};
> +
> +/*
> + * Si5351 clkout divider
> + */
> +static int _si5351_clkout_reparent(struct si5351_driver_data *drvdata,
> +				   int num, enum si5351_clkout_src parent)
> +{
> +	u8 val;
> +
> +	if (num > 8)
> +		return -EINVAL;
> +
> +	switch (parent) {
> +	case SI5351_CLKOUT_SRC_MSYNTH_N:
> +		val = SI5351_CLK_INPUT_MULTISYNTH_N;
> +		break;
> +	case SI5351_CLKOUT_SRC_MSYNTH_0_4:
> +		/* clk0/clk4 can only connect to its own multisync */
> +		if (num == 0 || num == 4)
> +			val = SI5351_CLK_INPUT_MULTISYNTH_N;
> +		else
> +			val = SI5351_CLK_INPUT_MULTISYNTH_0_4;
> +		break;
> +	case SI5351_CLKOUT_SRC_XTAL:
> +		val = SI5351_CLK_INPUT_XTAL;
> +		break;
> +	case SI5351_CLKOUT_SRC_CLKIN:
> +		if (drvdata->variant != SI5351_VARIANT_C)
> +			return -EINVAL;
> +
> +		val = SI5351_CLK_INPUT_CLKIN;
> +		break;
> +	default:
> +		return 0;
> +	}
> +
> +	si5351_set_bits(drvdata, SI5351_CLK0_CTRL + num,
> +			SI5351_CLK_INPUT_MASK, val);
> +	return 0;
> +}
> +
> +static int _si5351_clkout_set_drive_strength(
> +	struct si5351_driver_data *drvdata, int num,
> +	enum si5351_drive_strength drive)
> +{
> +	u8 mask;
> +
> +	if (num > 8)
> +		return -EINVAL;
> +
> +	switch (drive) {
> +	case SI5351_DRIVE_2MA:
> +		mask = SI5351_CLK_DRIVE_STRENGTH_2MA;
> +		break;
> +	case SI5351_DRIVE_4MA:
> +		mask = SI5351_CLK_DRIVE_STRENGTH_4MA;
> +		break;
> +	case SI5351_DRIVE_6MA:
> +		mask = SI5351_CLK_DRIVE_STRENGTH_6MA;
> +		break;
> +	case SI5351_DRIVE_8MA:
> +		mask = SI5351_CLK_DRIVE_STRENGTH_8MA;
> +		break;
> +	default:
> +		return 0;
> +	}
> +
> +	si5351_set_bits(drvdata, SI5351_CLK0_CTRL + num,
> +			SI5351_CLK_DRIVE_STRENGTH_MASK, mask);
> +	return 0;
> +}
> +
> +static int si5351_clkout_prepare(struct clk_hw *hw)
> +{
> +	struct si5351_hw_data *hwdata =
> +		container_of(hw, struct si5351_hw_data, hw);
> +
> +	si5351_set_bits(hwdata->drvdata, SI5351_CLK0_CTRL + hwdata->num,
> +			SI5351_CLK_POWERDOWN, 0);
> +	si5351_set_bits(hwdata->drvdata, SI5351_OUTPUT_ENABLE_CTRL,
> +			(1 << hwdata->num), 0);
> +	return 0;
> +}
> +
> +static void si5351_clkout_unprepare(struct clk_hw *hw)
> +{
> +	struct si5351_hw_data *hwdata =
> +		container_of(hw, struct si5351_hw_data, hw);
> +
> +	si5351_set_bits(hwdata->drvdata, SI5351_CLK0_CTRL + hwdata->num,
> +			SI5351_CLK_POWERDOWN, SI5351_CLK_POWERDOWN);
> +	si5351_set_bits(hwdata->drvdata, SI5351_OUTPUT_ENABLE_CTRL,
> +			(1 << hwdata->num), (1 << hwdata->num));
> +}
> +
> +static u8 si5351_clkout_get_parent(struct clk_hw *hw)
> +{
> +	struct si5351_hw_data *hwdata =
> +		container_of(hw, struct si5351_hw_data, hw);
> +	int index = 0;
> +	unsigned char val;
> +
> +	val = si5351_reg_read(hwdata->drvdata, SI5351_CLK0_CTRL + hwdata->num);
> +	switch (val & SI5351_CLK_INPUT_MASK) {
> +	case SI5351_CLK_INPUT_MULTISYNTH_N:
> +		index = 0;
> +		break;
> +	case SI5351_CLK_INPUT_MULTISYNTH_0_4:
> +		index = 1;
> +		break;
> +	case SI5351_CLK_INPUT_XTAL:
> +		index = 2;
> +		break;
> +	case SI5351_CLK_INPUT_CLKIN:
> +		index = 3;
> +		break;
> +	}
> +
> +	return index;
> +}
> +
> +static int si5351_clkout_set_parent(struct clk_hw *hw, u8 index)
> +{
> +	struct si5351_hw_data *hwdata =
> +		container_of(hw, struct si5351_hw_data, hw);
> +	enum si5351_clkout_src parent = SI5351_CLKOUT_SRC_DEFAULT;
> +
> +	switch (index) {
> +	case 0:
> +		parent = SI5351_CLKOUT_SRC_MSYNTH_N;
> +		break;
> +	case 1:
> +		parent = SI5351_CLKOUT_SRC_MSYNTH_0_4;
> +		break;
> +	case 2:
> +		parent = SI5351_CLKOUT_SRC_XTAL;
> +		break;
> +	case 3:
> +		parent = SI5351_CLKOUT_SRC_CLKIN;
> +		break;
> +	}
> +
> +	return _si5351_clkout_reparent(hwdata->drvdata, hwdata->num, parent);
> +}
> +
> +static unsigned long si5351_clkout_recalc_rate(struct clk_hw *hw,
> +					       unsigned long parent_rate)
> +{
> +	struct si5351_hw_data *hwdata =
> +		container_of(hw, struct si5351_hw_data, hw);
> +	unsigned char reg;
> +	unsigned char rdiv;
> +
> +	if (hwdata->num > 5)
> +		reg = si5351_msynth_params_address(hwdata->num) + 2;
> +	else
> +		reg = SI5351_CLK6_7_OUTPUT_DIVIDER;
> +
> +	rdiv = si5351_reg_read(hwdata->drvdata, reg);
> +	if (hwdata->num == 6) {
> +		rdiv &= SI5351_OUTPUT_CLK6_DIV_MASK;
> +	} else {
> +		rdiv &= SI5351_OUTPUT_CLK_DIV_MASK;
> +		rdiv >>= SI5351_OUTPUT_CLK_DIV_SHIFT;
> +	}
> +
> +	return parent_rate >> rdiv;
> +}
> +
> +static long si5351_clkout_round_rate(struct clk_hw *hw, unsigned long rate,
> +				     unsigned long *parent_rate)
> +{
> +	struct si5351_hw_data *hwdata =
> +		container_of(hw, struct si5351_hw_data, hw);
> +	unsigned char rdiv;
> +
> +	/* clkout6/7 can only handle output freqencies < 150MHz */
> +	if (hwdata->num >= 6 && rate > SI5351_CLKOUT67_MAX_FREQ)
> +		rate = SI5351_CLKOUT67_MAX_FREQ;
> +
> +	/* clkout freqency is 8kHz - 160MHz */
> +	if (rate > SI5351_CLKOUT_MAX_FREQ)
> +		rate = SI5351_CLKOUT_MAX_FREQ;
> +	if (rate < SI5351_CLKOUT_MIN_FREQ)
> +		rate = SI5351_CLKOUT_MIN_FREQ;
> +
> +	/* request frequency if multisync master */
> +	if (__clk_get_flags(hwdata->hw.clk) & CLK_SET_RATE_PARENT) {
> +		/* use r divider for frequencies below 1MHz */
> +		rdiv = SI5351_OUTPUT_CLK_DIV_1;
> +		while (rate < SI5351_MULTISYNTH_MIN_FREQ &&
> +		       rdiv < SI5351_OUTPUT_CLK_DIV_128) {
> +			rdiv += 1;
> +			rate *= 2;
> +		}
> +		*parent_rate = rate;
> +	} else {
> +		unsigned long new_rate, new_err, err;
> +
> +		/* round to closed rdiv */
> +		rdiv = SI5351_OUTPUT_CLK_DIV_1;
> +		new_rate = *parent_rate;
> +		err = abs(new_rate - rate);
> +		do {
> +			new_rate >>= 1;
> +			new_err = abs(new_rate - rate);
> +			if (new_err > err || rdiv == SI5351_OUTPUT_CLK_DIV_128)
> +				break;
> +			rdiv++;
> +			err = new_err;
> +		} while (1);
> +	}
> +	rate = *parent_rate >> rdiv;
> +
> +	dev_dbg(&hwdata->drvdata->client->dev,
> +		"%s - %s: rdiv = %u, parent_rate = %lu, rate = %lu\n",
> +		__func__, __clk_get_name(hwdata->hw.clk), (1 << rdiv),
> +		*parent_rate, rate);
> +
> +	return rate;
> +}
> +
> +static int si5351_clkout_set_rate(struct clk_hw *hw, unsigned long rate,
> +				  unsigned long parent_rate)
> +{
> +	struct si5351_hw_data *hwdata =
> +		container_of(hw, struct si5351_hw_data, hw);
> +	unsigned long new_rate, new_err, err;
> +	unsigned char rdiv;
> +
> +	/* round to closed rdiv */
> +	rdiv = SI5351_OUTPUT_CLK_DIV_1;
> +	new_rate = parent_rate;
> +	err = abs(new_rate - rate);
> +	do {
> +		new_rate >>= 1;
> +		new_err = abs(new_rate - rate);
> +		if (new_err > err || rdiv == SI5351_OUTPUT_CLK_DIV_128)
> +			break;
> +		rdiv++;
> +		err = new_err;
> +	} while (1);
> +
> +	/* write output divider */
> +	switch (hwdata->num) {
> +	case 6:
> +		si5351_set_bits(hwdata->drvdata, SI5351_CLK6_7_OUTPUT_DIVIDER,
> +				SI5351_OUTPUT_CLK6_DIV_MASK, rdiv);
> +		break;
> +	case 7:
> +		si5351_set_bits(hwdata->drvdata, SI5351_CLK6_7_OUTPUT_DIVIDER,
> +				SI5351_OUTPUT_CLK_DIV_MASK,
> +				rdiv << SI5351_OUTPUT_CLK_DIV_SHIFT);
> +		break;
> +	default:
> +		si5351_set_bits(hwdata->drvdata,
> +				si5351_msynth_params_address(hwdata->num) + 2,
> +				SI5351_OUTPUT_CLK_DIV_MASK,
> +				rdiv << SI5351_OUTPUT_CLK_DIV_SHIFT);
> +	}
> +
> +	dev_dbg(&hwdata->drvdata->client->dev,
> +		"%s - %s: rdiv = %u, parent_rate = %lu, rate = %lu\n",
> +		__func__, __clk_get_name(hwdata->hw.clk), (1 << rdiv),
> +		parent_rate, rate);
> +
> +	return 0;
> +}
> +
> +static const struct clk_ops si5351_clkout_ops = {
> +	.prepare = si5351_clkout_prepare,
> +	.unprepare = si5351_clkout_unprepare,
> +	.set_parent = si5351_clkout_set_parent,
> +	.get_parent = si5351_clkout_get_parent,
> +	.recalc_rate = si5351_clkout_recalc_rate,
> +	.round_rate = si5351_clkout_round_rate,
> +	.set_rate = si5351_clkout_set_rate,
> +};
> +
> +/*
> + * Si5351 i2c probe and DT
> + */
> +#ifdef CONFIG_OF
> +static const struct of_device_id si5351_dt_ids[] = {
> +	{ .compatible = "silabs,si5351a", .data = (void *)SI5351_VARIANT_A, },
> +	{ .compatible = "silabs,si5351a-msop",
> +					 .data = (void *)SI5351_VARIANT_A3, },
> +	{ .compatible = "silabs,si5351b", .data = (void *)SI5351_VARIANT_B, },
> +	{ .compatible = "silabs,si5351c", .data = (void *)SI5351_VARIANT_C, },
> +	{ }
> +};
> +MODULE_DEVICE_TABLE(of, si5351_dt_ids);
> +
> +static int si5351_dt_parse(struct i2c_client *client)
> +{
> +	struct device_node *child, *np = client->dev.of_node;
> +	struct si5351_platform_data *pdata;
> +	const struct of_device_id *match;
> +	struct property *prop;
> +	const __be32 *p;
> +	int num = 0;
> +	u32 val;
> +
> +	if (np == NULL)
> +		return 0;
> +
> +	match = of_match_node(si5351_dt_ids, np);
> +	if (match == NULL)
> +		return -EINVAL;
> +
> +	pdata = devm_kzalloc(&client->dev, sizeof(*pdata), GFP_KERNEL);
> +	if (!pdata)
> +		return -ENOMEM;
> +
> +	pdata->variant = (enum si5351_variant)match->data;
> +	pdata->clk_xtal = of_clk_get(np, 0);
> +	if (!IS_ERR(pdata->clk_xtal))
> +		clk_put(pdata->clk_xtal);
> +	pdata->clk_clkin = of_clk_get(np, 1);
> +	if (!IS_ERR(pdata->clk_clkin))
> +		clk_put(pdata->clk_clkin);
> +
> +	/*
> +	 * property silabs,pll-source : <num src>, [<..>]
> +	 * allow to selectively set pll source
> +	 */
> +	of_property_for_each_u32(np, "silabs,pll-source", prop, p, num) {
> +		if (num >= 2) {
> +			dev_err(&client->dev,
> +				"invalid pll %d on pll-source prop\n", num);
> +			return -EINVAL;
> +		}
> +
> +		p = of_prop_next_u32(prop, p, &val);
> +		if (!p) {
> +			dev_err(&client->dev,
> +				"missing pll-source for pll %d\n", num);
> +			return -EINVAL;
> +		}
> +
> +		switch (val) {
> +		case 0:
> +			pdata->pll_src[num] = SI5351_PLL_SRC_XTAL;
> +			break;
> +		case 1:
> +			if (pdata->variant != SI5351_VARIANT_C) {
> +				dev_err(&client->dev,
> +					"invalid parent %d for pll %d\n",
> +					val, num);
> +				return -EINVAL;
> +			}
> +			pdata->pll_src[num] = SI5351_PLL_SRC_CLKIN;
> +			break;
> +		default:
> +			dev_err(&client->dev,
> +				 "invalid parent %d for pll %d\n", val, num);
> +			return -EINVAL;
> +		}
> +	}
> +
> +	/* per clkout properties */
> +	for_each_child_of_node(np, child) {
> +		if (of_property_read_u32(child, "reg", &num)) {
> +			dev_err(&client->dev, "missing reg property of %s\n",
> +				child->name);
> +			return -EINVAL;
> +		}
> +
> +		if (num >= 8 ||
> +		    (pdata->variant == SI5351_VARIANT_A3 && num >= 3)) {
> +			dev_err(&client->dev, "invalid clkout %d\n", num);
> +			return -EINVAL;
> +		}
> +
> +		if (!of_property_read_u32(child, "silabs,multisynth-source",
> +					  &val)) {
> +			switch (val) {
> +			case 0:
> +				pdata->clkout[num].multisynth_src =
> +					SI5351_MULTISYNTH_SRC_VCO0;
> +				break;
> +			case 1:
> +				pdata->clkout[num].multisynth_src =
> +					SI5351_MULTISYNTH_SRC_VCO1;
> +				break;
> +			default:
> +				dev_err(&client->dev,
> +					"invalid parent %d for multisynth %d\n",
> +					val, num);
> +				return -EINVAL;
> +			}
> +		}
> +
> +		if (!of_property_read_u32(child, "silabs,clock-source", &val)) {
> +			switch (val) {
> +			case 0:
> +				pdata->clkout[num].clkout_src =
> +					SI5351_CLKOUT_SRC_MSYNTH_N;
> +				break;
> +			case 1:
> +				pdata->clkout[num].clkout_src =
> +					SI5351_CLKOUT_SRC_MSYNTH_0_4;
> +				break;
> +			case 2:
> +				pdata->clkout[num].clkout_src =
> +					SI5351_CLKOUT_SRC_XTAL;
> +				break;
> +			case 3:
> +				if (pdata->variant != SI5351_VARIANT_C) {
> +					dev_err(&client->dev,
> +						"invalid parent %d for clkout %d\n",
> +						val, num);
> +					return -EINVAL;
> +				}
> +				pdata->clkout[num].clkout_src =
> +					SI5351_CLKOUT_SRC_CLKIN;
> +				break;
> +			default:
> +				dev_err(&client->dev,
> +					"invalid parent %d for clkout %d\n",
> +					val, num);
> +				return -EINVAL;
> +			}
> +		}
> +
> +		if (!of_property_read_u32(child, "silabs,drive-strength",
> +					  &val)) {
> +			switch (val) {
> +			case SI5351_DRIVE_2MA:
> +			case SI5351_DRIVE_4MA:
> +			case SI5351_DRIVE_6MA:
> +			case SI5351_DRIVE_8MA:
> +				pdata->clkout[num].drive = val;
> +				break;
> +			default:
> +				dev_err(&client->dev,
> +					"invalid drive strength %d for clkout %d\n",
> +					val, num);
> +				return -EINVAL;
> +			}
> +		}
> +
> +		if (!of_property_read_u32(child, "clock-frequency", &val))
> +			pdata->clkout[num].rate = val;
> +
> +		pdata->clkout[num].pll_master =
> +			of_property_read_bool(child, "silabs,pll-master");
> +	}
> +	client->dev.platform_data = pdata;
> +
> +	return 0;
> +}
> +#else
> +static int si5351_dt_parse(struct i2c_client *client)
> +{
> +	return 0;
> +}
> +#endif /* CONFIG_OF */
> +
> +static int si5351_i2c_probe(struct i2c_client *client,
> +			    const struct i2c_device_id *id)
> +{
> +	struct si5351_platform_data *pdata;
> +	struct si5351_driver_data *drvdata;
> +	struct clk_init_data init;
> +	struct clk *clk;
> +	const char *parent_names[4];
> +	u8 num_parents, num_clocks;
> +	int ret, n;
> +
> +	ret = si5351_dt_parse(client);
> +	if (ret)
> +		return ret;
> +
> +	pdata = client->dev.platform_data;
> +	if (!pdata)
> +		return -EINVAL;
> +
> +	drvdata = devm_kzalloc(&client->dev, sizeof(*drvdata), GFP_KERNEL);
> +	if (drvdata == NULL) {
> +		dev_err(&client->dev, "unable to allocate driver data\n");
> +		return -ENOMEM;
> +	}
> +
> +	i2c_set_clientdata(client, drvdata);
> +	drvdata->client = client;
> +	drvdata->variant = pdata->variant;
> +	drvdata->pxtal = pdata->clk_xtal;
> +	drvdata->pclkin = pdata->clk_clkin;
> +
> +	drvdata->regmap = devm_regmap_init_i2c(client, &si5351_regmap_config);
> +	if (IS_ERR(drvdata->regmap)) {
> +		dev_err(&client->dev, "failed to allocate register map\n");
> +		return PTR_ERR(drvdata->regmap);
> +	}
> +
> +	/* Disable interrupts */
> +	si5351_reg_write(drvdata, SI5351_INTERRUPT_MASK, 0xf0);
> +	/* Set disabled output drivers to drive low */
> +	si5351_reg_write(drvdata, SI5351_CLK3_0_DISABLE_STATE, 0x00);
> +	si5351_reg_write(drvdata, SI5351_CLK7_4_DISABLE_STATE, 0x00);
> +	/* Ensure pll select is on XTAL for Si5351A/B */
> +	if (drvdata->variant != SI5351_VARIANT_C)
> +		si5351_set_bits(drvdata, SI5351_PLL_INPUT_SOURCE,
> +				SI5351_PLLA_SOURCE | SI5351_PLLB_SOURCE, 0);
> +
> +	/* setup clock configuration */
> +	for (n = 0; n < 2; n++) {
> +		ret = _si5351_pll_reparent(drvdata, n, pdata->pll_src[n]);
> +		if (ret) {
> +			dev_err(&client->dev,
> +				"failed to reparent pll %d to %d\n",
> +				n, pdata->pll_src[n]);
> +			return ret;
> +		}
> +	}
> +
> +	for (n = 0; n < 8; n++) {
> +		ret = _si5351_msynth_reparent(drvdata, n,
> +					      pdata->clkout[n].multisynth_src);
> +		if (ret) {
> +			dev_err(&client->dev,
> +				"failed to reparent multisynth %d to %d\n",
> +				n, pdata->clkout[n].multisynth_src);
> +			return ret;
> +		}
> +
> +		ret = _si5351_clkout_reparent(drvdata, n,
> +					      pdata->clkout[n].clkout_src);
> +		if (ret) {
> +			dev_err(&client->dev,
> +				"failed to reparent clkout %d to %d\n",
> +				n, pdata->clkout[n].clkout_src);
> +			return ret;
> +		}
> +
> +		ret = _si5351_clkout_set_drive_strength(drvdata, n,
> +							pdata->clkout[n].drive);
> +		if (ret) {
> +			dev_err(&client->dev,
> +				"failed set drive strength of clkout%d to %d\n",
> +				n, pdata->clkout[n].drive);
> +			return ret;
> +		}
> +	}
> +
> +	/* register xtal input clock gate */
> +	memset(&init, 0, sizeof(init));
> +	init.name = si5351_input_names[0];
> +	init.ops = &si5351_xtal_ops;
> +	init.flags = 0;
> +	if (!IS_ERR(drvdata->pxtal)) {
> +		drvdata->pxtal_name = __clk_get_name(drvdata->pxtal);
> +		init.parent_names = &drvdata->pxtal_name;
> +		init.num_parents = 1;
> +	}
> +	drvdata->xtal.init = &init;
> +	clk = devm_clk_register(&client->dev, &drvdata->xtal);
> +	if (IS_ERR(clk)) {
> +		dev_err(&client->dev, "unable to register %s\n", init.name);
> +		return PTR_ERR(clk);
> +	}
> +
> +	/* register clkin input clock gate */
> +	if (drvdata->variant == SI5351_VARIANT_C) {
> +		memset(&init, 0, sizeof(init));
> +		init.name = si5351_input_names[1];
> +		init.ops = &si5351_clkin_ops;
> +		if (!IS_ERR(drvdata->pclkin)) {
> +			drvdata->pclkin_name = __clk_get_name(drvdata->pclkin);
> +			init.parent_names = &drvdata->pclkin_name;
> +			init.num_parents = 1;
> +		}
> +		drvdata->clkin.init = &init;
> +		clk = devm_clk_register(&client->dev, &drvdata->clkin);
> +		if (IS_ERR(clk)) {
> +			dev_err(&client->dev, "unable to register %s\n",
> +				init.name);
> +			return PTR_ERR(clk);
> +		}
> +	}
> +
> +	/* Si5351C allows to mux either xtal or clkin to PLL input */
> +	num_parents = (drvdata->variant == SI5351_VARIANT_C) ? 2 : 1;
> +	parent_names[0] = si5351_input_names[0];
> +	parent_names[1] = si5351_input_names[1];
> +
> +	/* register PLLA */
> +	drvdata->pll[0].num = 0;
> +	drvdata->pll[0].drvdata = drvdata;
> +	drvdata->pll[0].hw.init = &init;
> +	memset(&init, 0, sizeof(init));
> +	init.name = si5351_pll_names[0];
> +	init.ops = &si5351_pll_ops;
> +	init.flags = 0;
> +	init.parent_names = parent_names;
> +	init.num_parents = num_parents;
> +	clk = devm_clk_register(&client->dev, &drvdata->pll[0].hw);
> +	if (IS_ERR(clk)) {
> +		dev_err(&client->dev, "unable to register %s\n", init.name);
> +		return -EINVAL;
> +	}
> +
> +	/* register PLLB or VXCO (Si5351B) */
> +	drvdata->pll[1].num = 1;
> +	drvdata->pll[1].drvdata = drvdata;
> +	drvdata->pll[1].hw.init = &init;
> +	memset(&init, 0, sizeof(init));
> +	if (drvdata->variant == SI5351_VARIANT_B) {
> +		init.name = si5351_pll_names[2];
> +		init.ops = &si5351_vxco_ops;
> +		init.flags = CLK_IS_ROOT;
> +		init.parent_names = NULL;
> +		init.num_parents = 0;
> +	} else {
> +		init.name = si5351_pll_names[1];
> +		init.ops = &si5351_pll_ops;
> +		init.flags = 0;
> +		init.parent_names = parent_names;
> +		init.num_parents = num_parents;
> +	}
> +	clk = devm_clk_register(&client->dev, &drvdata->pll[1].hw);
> +	if (IS_ERR(clk)) {
> +		dev_err(&client->dev, "unable to register %s\n", init.name);
> +		return -EINVAL;
> +	}
> +
> +	/* register clk multisync and clk out divider */
> +	num_clocks = (drvdata->variant == SI5351_VARIANT_A3) ? 3 : 8;
> +	parent_names[0] = si5351_pll_names[0];
> +	if (drvdata->variant == SI5351_VARIANT_B)
> +		parent_names[1] = si5351_pll_names[2];
> +	else
> +		parent_names[1] = si5351_pll_names[1];
> +
> +	drvdata->msynth = devm_kzalloc(&client->dev, num_clocks *
> +				       sizeof(*drvdata->msynth), GFP_KERNEL);
> +	drvdata->clkout = devm_kzalloc(&client->dev, num_clocks *
> +				       sizeof(*drvdata->clkout), GFP_KERNEL);
> +
> +	drvdata->onecell.clk_num = num_clocks;
> +	drvdata->onecell.clks = devm_kzalloc(&client->dev,
> +		num_clocks * sizeof(*drvdata->onecell.clks), GFP_KERNEL);
> +
> +	if (WARN_ON(!drvdata->msynth || !drvdata->clkout ||
> +		    !drvdata->onecell.clks))
> +		return -ENOMEM;
> +
> +	for (n = 0; n < num_clocks; n++) {
> +		drvdata->msynth[n].num = n;
> +		drvdata->msynth[n].drvdata = drvdata;
> +		drvdata->msynth[n].hw.init = &init;
> +		memset(&init, 0, sizeof(init));
> +		init.name = si5351_msynth_names[n];
> +		init.ops = &si5351_msynth_ops;
> +		init.flags = 0;
> +		if (pdata->clkout[n].pll_master)
> +			init.flags |= CLK_SET_RATE_PARENT;
> +		init.parent_names = parent_names;
> +		init.num_parents = 2;
> +		clk = devm_clk_register(&client->dev, &drvdata->msynth[n].hw);
> +		if (IS_ERR(clk)) {
> +			dev_err(&client->dev, "unable to register %s\n",
> +				init.name);
> +			return -EINVAL;
> +		}
> +	}
> +
> +	num_parents = (drvdata->variant == SI5351_VARIANT_C) ? 4 : 3;
> +	parent_names[2] = si5351_input_names[0];
> +	parent_names[3] = si5351_input_names[1];
> +	for (n = 0; n < num_clocks; n++) {
> +		parent_names[0] = si5351_msynth_names[n];
> +		parent_names[1] = (n < 4) ? si5351_msynth_names[0] :
> +			si5351_msynth_names[4];
> +
> +		drvdata->clkout[n].num = n;
> +		drvdata->clkout[n].drvdata = drvdata;
> +		drvdata->clkout[n].hw.init = &init;
> +		memset(&init, 0, sizeof(init));
> +		init.name = si5351_clkout_names[n];
> +		init.ops = &si5351_clkout_ops;
> +		init.flags = 0;
> +		if (pdata->clkout[n].clkout_src == SI5351_CLKOUT_SRC_MSYNTH_N)
> +			init.flags |= CLK_SET_RATE_PARENT;
> +		init.parent_names = parent_names;
> +		init.num_parents = num_parents;
> +		clk = devm_clk_register(&client->dev, &drvdata->clkout[n].hw);
> +		if (IS_ERR(clk)) {
> +			dev_err(&client->dev, "unable to register %s\n",
> +				init.name);
> +			return -EINVAL;
> +		}
> +		drvdata->onecell.clks[n] = clk;
> +	}
> +
> +	ret = of_clk_add_provider(client->dev.of_node, of_clk_src_onecell_get,
> +				  &drvdata->onecell);
> +	if (ret) {
> +		dev_err(&client->dev, "unable to add clk provider\n");
> +		return ret;
> +	}
> +
> +	return 0;
> +}
> +
> +static const struct i2c_device_id si5351_i2c_ids[] = {
> +	{ "silabs,si5351", 0 },
> +	{ }
> +};
> +MODULE_DEVICE_TABLE(i2c, si5351_i2c_ids);
> +
> +static struct i2c_driver si5351_driver = {
> +	.driver = {
> +		.name = "si5351",
> +		.of_match_table = of_match_ptr(si5351_dt_ids),
> +	},
> +	.probe = si5351_i2c_probe,
> +	.id_table = si5351_i2c_ids,
> +};
> +module_i2c_driver(si5351_driver);
> +
> +MODULE_AUTHOR("Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com");
> +MODULE_DESCRIPTION("Silicon Labs Si5351A/B/C clock generator driver");
> +MODULE_LICENSE("GPL");
> diff --git a/drivers/clk/clk-si5351.h b/drivers/clk/clk-si5351.h
> new file mode 100644
> index 0000000..af41b50
> --- /dev/null
> +++ b/drivers/clk/clk-si5351.h
> @@ -0,0 +1,155 @@
> +/*
> + * clk-si5351.h: Silicon Laboratories Si5351A/B/C I2C Clock Generator
> + *
> + * Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
> + * Rabeeh Khoury <rabeeh at solid-run.com>
> + *
> + * 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.
> + */
> +
> +#ifndef _CLK_SI5351_H_
> +#define _CLK_SI5351_H_
> +
> +#define SI5351_BUS_BASE_ADDR			0x60
> +
> +#define SI5351_PLL_VCO_MIN			600000000
> +#define SI5351_PLL_VCO_MAX			900000000
> +#define SI5351_MULTISYNTH_MIN_FREQ		1000000
> +#define SI5351_MULTISYNTH_DIVBY4_FREQ		150000000
> +#define SI5351_MULTISYNTH_MAX_FREQ		160000000
> +#define SI5351_MULTISYNTH67_MAX_FREQ		SI5351_MULTISYNTH_DIVBY4_FREQ
> +#define SI5351_CLKOUT_MIN_FREQ			8000
> +#define SI5351_CLKOUT_MAX_FREQ			SI5351_MULTISYNTH_MAX_FREQ
> +#define SI5351_CLKOUT67_MAX_FREQ		SI5351_MULTISYNTH67_MAX_FREQ
> +
> +#define SI5351_PLL_A_MIN			15
> +#define SI5351_PLL_A_MAX			90
> +#define SI5351_PLL_B_MAX			(SI5351_PLL_C_MAX-1)
> +#define SI5351_PLL_C_MAX			1048575
> +#define SI5351_MULTISYNTH_A_MIN			6
> +#define SI5351_MULTISYNTH_A_MAX			1800
> +#define SI5351_MULTISYNTH67_A_MAX		254
> +#define SI5351_MULTISYNTH_B_MAX			(SI5351_MULTISYNTH_C_MAX-1)
> +#define SI5351_MULTISYNTH_C_MAX			1048575
> +#define SI5351_MULTISYNTH_P1_MAX		((1<<18)-1)
> +#define SI5351_MULTISYNTH_P2_MAX		((1<<20)-1)
> +#define SI5351_MULTISYNTH_P3_MAX		((1<<20)-1)
> +
> +#define SI5351_DEVICE_STATUS			0
> +#define SI5351_INTERRUPT_STATUS			1
> +#define SI5351_INTERRUPT_MASK			2
> +#define  SI5351_STATUS_SYS_INIT			(1<<7)
> +#define  SI5351_STATUS_LOL_B			(1<<6)
> +#define  SI5351_STATUS_LOL_A			(1<<5)
> +#define  SI5351_STATUS_LOS			(1<<4)
> +#define SI5351_OUTPUT_ENABLE_CTRL		3
> +#define SI5351_OEB_PIN_ENABLE_CTRL		9
> +#define SI5351_PLL_INPUT_SOURCE			15
> +#define  SI5351_CLKIN_DIV_MASK			(3<<6)
> +#define  SI5351_CLKIN_DIV_1			(0<<6)
> +#define  SI5351_CLKIN_DIV_2			(1<<6)
> +#define  SI5351_CLKIN_DIV_4			(2<<6)
> +#define  SI5351_CLKIN_DIV_8			(3<<6)
> +#define  SI5351_PLLB_SOURCE			(1<<3)
> +#define  SI5351_PLLA_SOURCE			(1<<2)
> +
> +#define SI5351_CLK0_CTRL			16
> +#define SI5351_CLK1_CTRL			17
> +#define SI5351_CLK2_CTRL			18
> +#define SI5351_CLK3_CTRL			19
> +#define SI5351_CLK4_CTRL			20
> +#define SI5351_CLK5_CTRL			21
> +#define SI5351_CLK6_CTRL			22
> +#define SI5351_CLK7_CTRL			23
> +#define  SI5351_CLK_POWERDOWN			(1<<7)
> +#define  SI5351_CLK_INTEGER_MODE		(1<<6)
> +#define  SI5351_CLK_PLL_SELECT			(1<<5)
> +#define  SI5351_CLK_INVERT			(1<<4)
> +#define  SI5351_CLK_INPUT_MASK			(3<<2)
> +#define  SI5351_CLK_INPUT_XTAL			(0<<2)
> +#define  SI5351_CLK_INPUT_CLKIN			(1<<2)
> +#define  SI5351_CLK_INPUT_MULTISYNTH_0_4	(2<<2)
> +#define  SI5351_CLK_INPUT_MULTISYNTH_N		(3<<2)
> +#define  SI5351_CLK_DRIVE_STRENGTH_MASK		(3<<0)
> +#define  SI5351_CLK_DRIVE_STRENGTH_2MA		(0<<0)
> +#define  SI5351_CLK_DRIVE_STRENGTH_4MA		(1<<0)
> +#define  SI5351_CLK_DRIVE_STRENGTH_6MA		(2<<0)
> +#define  SI5351_CLK_DRIVE_STRENGTH_8MA		(3<<0)
> +
> +#define SI5351_CLK3_0_DISABLE_STATE		24
> +#define SI5351_CLK7_4_DISABLE_STATE		25
> +#define  SI5351_CLK_DISABLE_STATE_LOW		0
> +#define  SI5351_CLK_DISABLE_STATE_HIGH		1
> +#define  SI5351_CLK_DISABLE_STATE_FLOAT		2
> +#define  SI5351_CLK_DISABLE_STATE_NEVER		3
> +
> +#define SI5351_PARAMETERS_LENGTH		8
> +#define SI5351_PLLA_PARAMETERS			26
> +#define SI5351_PLLB_PARAMETERS			34
> +#define SI5351_CLK0_PARAMETERS			42
> +#define SI5351_CLK1_PARAMETERS			50
> +#define SI5351_CLK2_PARAMETERS			58
> +#define SI5351_CLK3_PARAMETERS			66
> +#define SI5351_CLK4_PARAMETERS			74
> +#define SI5351_CLK5_PARAMETERS			82
> +#define SI5351_CLK6_PARAMETERS			90
> +#define SI5351_CLK7_PARAMETERS			91
> +#define SI5351_CLK6_7_OUTPUT_DIVIDER		92
> +#define  SI5351_OUTPUT_CLK_DIV_MASK		(7 << 4)
> +#define  SI5351_OUTPUT_CLK6_DIV_MASK		(7 << 0)
> +#define  SI5351_OUTPUT_CLK_DIV_SHIFT		4
> +#define  SI5351_OUTPUT_CLK_DIV6_SHIFT		0
> +#define  SI5351_OUTPUT_CLK_DIV_1		0
> +#define  SI5351_OUTPUT_CLK_DIV_2		1
> +#define  SI5351_OUTPUT_CLK_DIV_4		2
> +#define  SI5351_OUTPUT_CLK_DIV_8		3
> +#define  SI5351_OUTPUT_CLK_DIV_16		4
> +#define  SI5351_OUTPUT_CLK_DIV_32		5
> +#define  SI5351_OUTPUT_CLK_DIV_64		6
> +#define  SI5351_OUTPUT_CLK_DIV_128		7
> +#define  SI5351_OUTPUT_CLK_DIVBY4		(3<<2)
> +
> +#define SI5351_SSC_PARAM0			149
> +#define SI5351_SSC_PARAM1			150
> +#define SI5351_SSC_PARAM2			151
> +#define SI5351_SSC_PARAM3			152
> +#define SI5351_SSC_PARAM4			153
> +#define SI5351_SSC_PARAM5			154
> +#define SI5351_SSC_PARAM6			155
> +#define SI5351_SSC_PARAM7			156
> +#define SI5351_SSC_PARAM8			157
> +#define SI5351_SSC_PARAM9			158
> +#define SI5351_SSC_PARAM10			159
> +#define SI5351_SSC_PARAM11			160
> +#define SI5351_SSC_PARAM12			161
> +
> +#define SI5351_VXCO_PARAMETERS_LOW		162
> +#define SI5351_VXCO_PARAMETERS_MID		163
> +#define SI5351_VXCO_PARAMETERS_HIGH		164
> +
> +#define SI5351_CLK0_PHASE_OFFSET		165
> +#define SI5351_CLK1_PHASE_OFFSET		166
> +#define SI5351_CLK2_PHASE_OFFSET		167
> +#define SI5351_CLK3_PHASE_OFFSET		168
> +#define SI5351_CLK4_PHASE_OFFSET		169
> +#define SI5351_CLK5_PHASE_OFFSET		170
> +
> +#define SI5351_PLL_RESET			177
> +#define  SI5351_PLL_RESET_B			(1<<7)
> +#define  SI5351_PLL_RESET_A			(1<<5)
> +
> +#define SI5351_CRYSTAL_LOAD			183
> +#define  SI5351_CRYSTAL_LOAD_MASK		(3<<6)
> +#define  SI5351_CRYSTAL_LOAD_6PF		(1<<6)
> +#define  SI5351_CRYSTAL_LOAD_8PF		(2<<6)
> +#define  SI5351_CRYSTAL_LOAD_10PF		(3<<6)
> +
> +#define SI5351_FANOUT_ENABLE			187
> +#define  SI5351_CLKIN_ENABLE			(1<<7)
> +#define  SI5351_XTAL_ENABLE			(1<<6)
> +#define  SI5351_MULTISYNTH_ENABLE		(1<<4)
> +
> +#endif
> diff --git a/include/linux/platform_data/si5351.h b/include/linux/platform_data/si5351.h
> new file mode 100644
> index 0000000..92dabca
> --- /dev/null
> +++ b/include/linux/platform_data/si5351.h
> @@ -0,0 +1,114 @@
> +/*
> + * Si5351A/B/C programmable clock generator platform_data.
> + */
> +
> +#ifndef __LINUX_PLATFORM_DATA_SI5351_H__
> +#define __LINUX_PLATFORM_DATA_SI5351_H__
> +
> +struct clk;
> +
> +/**
> + * enum si5351_variant - SiLabs Si5351 chip variant
> + * @SI5351_VARIANT_A: Si5351A (8 output clocks, XTAL input)
> + * @SI5351_VARIANT_A3: Si5351A MSOP10 (3 output clocks, XTAL input)
> + * @SI5351_VARIANT_B: Si5351B (8 output clocks, XTAL/VXCO input)
> + * @SI5351_VARIANT_C: Si5351C (8 output clocks, XTAL/CLKIN input)
> + */
> +enum si5351_variant {
> +	SI5351_VARIANT_A = 1,
> +	SI5351_VARIANT_A3 = 2,
> +	SI5351_VARIANT_B = 3,
> +	SI5351_VARIANT_C = 4,
> +};
> +
> +/**
> + * enum si5351_pll_src - Si5351 pll clock source
> + * @SI5351_PLL_SRC_DEFAULT: default, do not change eeprom config
> + * @SI5351_PLL_SRC_XTAL: pll source clock is XTAL input
> + * @SI5351_PLL_SRC_CLKIN: pll source clock is CLKIN input (Si5351C only)
> + */
> +enum si5351_pll_src {
> +	SI5351_PLL_SRC_DEFAULT = 0,
> +	SI5351_PLL_SRC_XTAL = 1,
> +	SI5351_PLL_SRC_CLKIN = 2,
> +};
> +
> +/**
> + * enum si5351_multisynth_src - Si5351 multisynth clock source
> + * @SI5351_MULTISYNTH_SRC_DEFAULT: default, do not change eeprom config
> + * @SI5351_MULTISYNTH_SRC_VCO0: multisynth source clock is VCO0
> + * @SI5351_MULTISYNTH_SRC_VCO1: multisynth source clock is VCO1/VXCO
> + */
> +enum si5351_multisynth_src {
> +	SI5351_MULTISYNTH_SRC_DEFAULT = 0,
> +	SI5351_MULTISYNTH_SRC_VCO0 = 1,
> +	SI5351_MULTISYNTH_SRC_VCO1 = 2,
> +};
> +
> +/**
> + * enum si5351_clkout_src - Si5351 clock output clock source
> + * @SI5351_CLKOUT_SRC_DEFAULT: default, do not change eeprom config
> + * @SI5351_CLKOUT_SRC_MSYNTH_N: clkout N source clock is multisynth N
> + * @SI5351_CLKOUT_SRC_MSYNTH_0_4: clkout N source clock is multisynth 0 (N<4)
> + *                                or 4 (N>=4)
> + * @SI5351_CLKOUT_SRC_XTAL: clkout N source clock is XTAL
> + * @SI5351_CLKOUT_SRC_CLKIN: clkout N source clock is CLKIN (Si5351C only)
> + */
> +enum si5351_clkout_src {
> +	SI5351_CLKOUT_SRC_DEFAULT = 0,
> +	SI5351_CLKOUT_SRC_MSYNTH_N = 1,
> +	SI5351_CLKOUT_SRC_MSYNTH_0_4 = 2,
> +	SI5351_CLKOUT_SRC_XTAL = 3,
> +	SI5351_CLKOUT_SRC_CLKIN = 4,
> +};
> +
> +/**
> + * enum si5351_drive_strength - Si5351 clock output drive strength
> + * @SI5351_DRIVE_DEFAULT: default, do not change eeprom config
> + * @SI5351_DRIVE_2MA: 2mA clock output drive strength
> + * @SI5351_DRIVE_4MA: 4mA clock output drive strength
> + * @SI5351_DRIVE_6MA: 6mA clock output drive strength
> + * @SI5351_DRIVE_8MA: 8mA clock output drive strength
> + */
> +enum si5351_drive_strength {
> +	SI5351_DRIVE_DEFAULT = 0,
> +	SI5351_DRIVE_2MA = 2,
> +	SI5351_DRIVE_4MA = 4,
> +	SI5351_DRIVE_6MA = 6,
> +	SI5351_DRIVE_8MA = 8,
> +};
> +
> +/**
> + * struct si5351_clkout_config - Si5351 clock output configuration
> + * @clkout: clkout number
> + * @multisynth_src: multisynth source clock
> + * @clkout_src: clkout source clock
> + * @pll_master: if true, clkout can also change pll rate
> + * @drive: output drive strength
> + * @rate: initial clkout rate, or default if 0
> + */
> +struct si5351_clkout_config {
> +	enum si5351_multisynth_src multisynth_src;
> +	enum si5351_clkout_src clkout_src;
> +	enum si5351_drive_strength drive;
> +	bool pll_master;
> +	unsigned long rate;
> +};
> +
> +/**
> + * struct si5351_platform_data - Platform data for the Si5351 clock driver
> + * @variant: Si5351 chip variant
> + * @clk_xtal: xtal input clock
> + * @clk_clkin: clkin input clock
> + * @pll_src: array of pll source clock setting
> + * @clkout: array of clkout configuration
> + */
> +struct si5351_platform_data {
> +	enum si5351_variant variant;
> +	struct clk *clk_xtal;
> +	struct clk *clk_clkin;
> +	enum si5351_pll_src pll_src[2];
> +	struct si5351_clkout_config clkout[8];
> +};
> +
> +#endif
> 



From ezequiel.garcia at free-electrons.com  Wed Apr 10 06:19:57 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Wed, 10 Apr 2013 07:19:57 -0300
Subject: [PATCH v6 1/5] drivers: memory: Introduce Marvell EBU Device Bus
 driver
In-Reply-To: <20130409203855.GA27797@obsidianresearch.com>
References: <1365539181-29242-1-git-send-email-ezequiel.garcia@free-electrons.com>
 <1365539181-29242-2-git-send-email-ezequiel.garcia@free-electrons.com>
 <20130409203855.GA27797@obsidianresearch.com>
Message-ID: <20130410101956.GA2250@localhost>

Hi Jason,

On Tue, Apr 09, 2013 at 02:38:55PM -0600, Jason Gunthorpe wrote:
> On Tue, Apr 09, 2013 at 05:26:17PM -0300, Ezequiel Garcia wrote:
> > +	/*
> > +	 * Since this is only part of the workaround,
> > +	 * we can do this dirty 'ranges' property parsing.
> > +	 * Of course, this will be removed once the address windows
> > +	 * are declared in the device tree.
> > +	 */
> > +	err = of_property_read_u32_array(node, "ranges", addr_region,
> > +					 ARRAY_SIZE(addr_region));
> 
> Oh, this is a dangerous way to parse ranges.. 
> 
> Try something like:
> 
> const __be32 *prop;
> u64 base;
> u64 size;
> 
> prop = of_get_property("ranges",&psize);
> if (prop == NULL || psize != of_n_addr_cells(node) + of_n_size_cells(node))
>    err;
> base = of_translate_address(node,prop);
> if (base == OF_BAD_ADDR)
>    err;
> size = of_read_number(prop + of_n_addr_cells(node),of_n_size_cells(node));
> 

Thanks for giving me these hints!

Following your suggestion, here's a working piece of the ranges parsing code,
how does this look?

const __be32 *ranges;
int addr_cells, p_addr_cells, size_cells;
int ranges_len, tuple_len;
u32 base, size;

p_addr_cells = of_n_addr_cells(node->parent);
addr_cells = of_n_addr_cells(node);
size_cells = of_n_size_cells(node);
tuple_len = (p_addr_cells + addr_cells + size_cells) * sizeof(__be32);

ranges = of_get_property(node, "ranges", &ranges_len);
if (ranges == NULL || ranges_len != tuple_len)
	return -EINVAL;

base = of_translate_address(node, ranges + addr_cells);
if (base == 0 || base == OF_BAD_ADDR)
	return -EINVAL;
size = of_read_number(ranges + addr_cells + p_addr_cells, size_cells);

-- 
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com


From chanho61.park at samsung.com  Wed Apr 10 06:19:52 2013
From: chanho61.park at samsung.com (Chanho Park)
Date: Wed, 10 Apr 2013 19:19:52 +0900
Subject: [PATCHv2] arm: mm: lockless get_user_pages_fast support
Message-ID: <1365589192-5883-1-git-send-email-chanho61.park@samsung.com>

This patch adds get_user_pages_fast(old name is "fast_gup") for ARM.
The fast_gup can walk pagetable without taking mmap_sem or any locks. If there
is not a pte with the correct permissions for the access, we fall back to slow
path(get_user_pages) to get remaining pages. This patch is written on reference
the x86's gup implementation.
When Bill's hugetlb patchset[1] is applied, gup may need a implementation of
gup_huge_pud to traverse hugepages.
The patch also includes __get_user_pages_fast which is same with normal gup
except its IRQ-safe. It will be needed in futex for THP.

[1]: http://lists.infradead.org/pipermail/linux-arm-kernel/2012-October/126382.html

Signed-off-by: Chanho Park <chanho61.park at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
---
Changes from v1:
 - Remove unnecessary smb_rmb barrier in gup_pte_range
 - Add __get_user_pages_fast implementation

 arch/arm/mm/Makefile |    2 +-
 arch/arm/mm/gup.c    |  204 ++++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 205 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/mm/gup.c

diff --git a/arch/arm/mm/Makefile b/arch/arm/mm/Makefile
index 4e333fa..1c2896e 100644
--- a/arch/arm/mm/Makefile
+++ b/arch/arm/mm/Makefile
@@ -6,7 +6,7 @@ obj-y				:= dma-mapping.o extable.o fault.o init.o \
 				   iomap.o
 
 obj-$(CONFIG_MMU)		+= fault-armv.o flush.o idmap.o ioremap.o \
-				   mmap.o pgd.o mmu.o
+				   mmap.o pgd.o mmu.o gup.o
 
 ifneq ($(CONFIG_MMU),y)
 obj-y				+= nommu.o
diff --git a/arch/arm/mm/gup.c b/arch/arm/mm/gup.c
new file mode 100644
index 0000000..0f9adce
--- /dev/null
+++ b/arch/arm/mm/gup.c
@@ -0,0 +1,204 @@
+/*
+ * linux/arch/arm/mm/gup.c - Lockless get_user_pages_fast for arm
+ *
+ * Copyright (c) 2013 Samsung Electronics Co., Ltd.
+ *		http://www.samsung.com
+ * Author : Chanho Park <chanho61.park at samsung.com>
+ *
+ * This code is written on reference from the x86 and PowerPC versions, by:
+ *
+ *	Copyright (C) 2008 Nick Piggin
+ *	Copyright (C) 2008 Novell Inc.
+ *
+ * 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/sched.h>
+#include <linux/mm.h>
+#include <linux/pagemap.h>
+#include <linux/rwsem.h>
+#include <asm/pgtable.h>
+
+/*
+ * The performance critical leaf functions are made noinline otherwise gcc
+ * inlines everything into a single function which results in too much
+ * register pressure.
+ */
+static noinline int gup_pte_range(pmd_t *pmdp, unsigned long addr,
+		unsigned long end, int write, struct page **pages, int *nr)
+{
+	pte_t *ptep, pte;
+
+	ptep = pte_offset_kernel(pmdp, addr);
+	do {
+		struct page *page;
+
+		pte = *ptep;
+
+		if (!pte_present_user(pte) || (write && !pte_write(pte)))
+			return 0;
+
+		VM_BUG_ON(!pfn_valid(pte_pfn(pte)));
+		page = pte_page(pte);
+
+		if (!page_cache_get_speculative(page))
+			return 0;
+
+		pages[*nr] = page;
+		(*nr)++;
+
+	} while (ptep++, addr += PAGE_SIZE, addr != end);
+
+	return 1;
+}
+
+static int gup_pmd_range(pud_t *pudp, unsigned long addr, unsigned long end,
+		int write, struct page **pages, int *nr)
+{
+	unsigned long next;
+	pmd_t *pmdp;
+
+	pmdp = pmd_offset(pudp, addr);
+	do {
+		next = pmd_addr_end(addr, end);
+		if (pmd_none(*pmdp) || pmd_bad(*pmdp))
+			return 0;
+		else if (!gup_pte_range(pmdp, addr, next, write, pages, nr))
+			return 0;
+	} while (pmdp++, addr = next, addr != end);
+
+	return 1;
+}
+
+static int gup_pud_range(pgd_t *pgdp, unsigned long addr, unsigned long end,
+		int write, struct page **pages, int *nr)
+{
+	unsigned long next;
+	pud_t *pudp;
+
+	pudp = pud_offset(pgdp, addr);
+	do {
+		next = pud_addr_end(addr, end);
+		if (pud_none(*pudp))
+			return 0;
+		else if (!gup_pmd_range(pudp, addr, next, write, pages, nr))
+			return 0;
+	} while (pudp++, addr = next, addr != end);
+
+	return 1;
+}
+
+/*
+ * Like get_user_pages_fast() except its IRQ-safe in that it won't fall
+ * back to the regular GUP.
+ */
+int __get_user_pages_fast(unsigned long start, int nr_pages, int write,
+			  struct page **pages)
+{
+	struct mm_struct *mm = current->mm;
+	unsigned long addr, len, end;
+	unsigned long next, flags;
+	pgd_t *pgdp;
+	int nr = 0;
+
+	start &= PAGE_MASK;
+	addr = start;
+	len = (unsigned long) nr_pages << PAGE_SHIFT;
+	end = start + len;
+
+	if (unlikely(!access_ok(write ? VERIFY_WRITE : VERIFY_READ,
+					start, len)))
+		return 0;
+
+	/*
+	 * This doesn't prevent pagetable teardown, but does prevent
+	 * the pagetables from being freed on arm.
+	 *
+	 * So long as we atomically load page table pointers versus teardown,
+	 * we can follow the address down to the the page and take a ref on it.
+	 */
+	local_irq_save(flags);
+
+	pgdp = pgd_offset(mm, addr);
+	do {
+		next = pgd_addr_end(addr, end);
+		if (pgd_none(*pgdp))
+			break;
+		else if (!gup_pud_range(pgdp, addr, next, write, pages, &nr))
+			break;
+	} while (pgdp++, addr = next, addr != end);
+
+	local_irq_restore(flags);
+
+	return nr;
+}
+
+int get_user_pages_fast(unsigned long start, int nr_pages, int write,
+			struct page **pages)
+{
+	struct mm_struct *mm = current->mm;
+	unsigned long addr, len, end;
+	unsigned long next;
+	pgd_t *pgdp;
+	int nr = 0;
+
+	start &= PAGE_MASK;
+	addr = start;
+	len = (unsigned long) nr_pages << PAGE_SHIFT;
+	end = start + len;
+
+	if (unlikely(!access_ok(write ? VERIFY_WRITE : VERIFY_READ,
+					start, len)))
+		goto slow_irqon;
+
+	/*
+	 * This doesn't prevent pagetable teardown, but does prevent
+	 * the pagetables from being freed on arm.
+	 *
+	 * So long as we atomically load page table pointers versus teardown,
+	 * we can follow the address down to the the page and take a ref on it.
+	 */
+	local_irq_disable();
+
+	pgdp = pgd_offset(mm, addr);
+	do {
+		next = pgd_addr_end(addr, end);
+		if (pgd_none(*pgdp))
+			goto slow;
+		else if (!gup_pud_range(pgdp, addr, next, write, pages, &nr))
+			goto slow;
+	} while (pgdp++, addr = next, addr != end);
+
+	local_irq_enable();
+
+	VM_BUG_ON(nr != (end - start) >> PAGE_SHIFT);
+	return nr;
+
+	{
+		int ret;
+
+slow:
+		local_irq_enable();
+slow_irqon:
+		/* Try to get the remaining pages with get_user_pages */
+		start += nr << PAGE_SHIFT;
+		pages += nr;
+
+		down_read(&mm->mmap_sem);
+		ret = get_user_pages(current, mm, start,
+			(end - start) >> PAGE_SHIFT, write, 0, pages, NULL);
+		up_read(&mm->mmap_sem);
+
+		/* Have to be a bit careful with return values */
+		if (nr > 0) {
+			if (ret < 0)
+				ret = nr;
+			else
+				ret += nr;
+		}
+
+		return ret;
+	}
+}
-- 
1.7.9.5



From pawel.moll at arm.com  Wed Apr 10 06:25:00 2013
From: pawel.moll at arm.com (Pawel Moll)
Date: Wed, 10 Apr 2013 11:25:00 +0100
Subject: [PATCH] clk: vexpress: Add separate SP810 driver
In-Reply-To: <1363358409-5693-1-git-send-email-pawel.moll@arm.com>
References: <1363358409-5693-1-git-send-email-pawel.moll@arm.com>
Message-ID: <1365589500.362.15.camel@hornet>

On Fri, 2013-03-15 at 14:40 +0000, Pawel Moll wrote:
> Hi Mike,
> 
> I'd like to get this merged in 3.10. After this arm64
> will be able to avoid any platform clocking code. And
> in case of v7 this will happen once Rob's SP804 work
> is done.
> 
> Thanks!
> 
> Pawel

Ping?

Pawe?




From yuvaraj.cd at gmail.com  Wed Apr 10 06:30:20 2013
From: yuvaraj.cd at gmail.com (Yuvaraj Kumar C D)
Date: Wed, 10 Apr 2013 16:00:20 +0530
Subject: [PATCH] I2C: EXYNOS5: Set up the TX FIFO and RX FIFO for HSI2C
Message-ID: <1365589820-28440-1-git-send-email-yuvaraj.cd@samsung.com>

This patch, set up TX FIFO and RX FIFO of HSI2C controller based
on i2c message length.If we configure TX and RX FIFO for a default
value,the ALMOST_EMPTY and ALMOST_FULL will rise the interrupts
unnecessary.

Signed-off-by: Yuvaraj Kumar C D <yuvaraj.cd at samsung.com>
---
 drivers/i2c/busses/i2c-exynos5.c |   21 ++++++++++++---------
 1 file changed, 12 insertions(+), 9 deletions(-)

diff --git a/drivers/i2c/busses/i2c-exynos5.c b/drivers/i2c/busses/i2c-exynos5.c
index a38c616..b25c717 100644
--- a/drivers/i2c/busses/i2c-exynos5.c
+++ b/drivers/i2c/busses/i2c-exynos5.c
@@ -77,9 +77,9 @@
 /* I2C_FIFO_CTL Register bits */
 #define HSI2C_RXFIFO_EN				(1u << 0)
 #define HSI2C_TXFIFO_EN				(1u << 1)
-#define HSI2C_TXFIFO_TRIGGER_LEVEL		(0x30 << 16)
-#define HSI2C_RXFIFO_TRIGGER_LEVEL		(0x30 << 4)
-
+#define HSI2C_FIFO_MAX				(0x40)
+#define HSI2C_RXFIFO_TRIGGER_LEVEL(x)		((x) << 4)
+#define HSI2C_TXFIFO_TRIGGER_LEVEL(x)		((x) << 16)
 /* I2C_TRAILING_CTL Register bits */
 #define HSI2C_TRAILING_COUNT			(0xf)
 
@@ -400,10 +400,9 @@ static irqreturn_t exynos5_i2c_irq(int irqno, void *dev_id)
 			goto stop;
 		}
 
-		/* 0x30 is the default trigger level for TX FIFO */
-		len = 48 - fifo_level;
-
-		if (len > i2c->msg->len)
+		if (i2c->msg->len > HSI2C_FIFO_MAX)
+			len = HSI2C_FIFO_MAX;
+		else
 			len = i2c->msg->len;
 
 		i2c->msg_len += len;
@@ -492,10 +491,11 @@ static void exynos5_i2c_message_start(struct exynos5_i2c *i2c, int stop)
 	u32 i2c_auto_conf = 0;
 	u32 fifo_ctl;
 
+	unsigned short len = (i2c->msg->len > HSI2C_FIFO_MAX) ?
+					HSI2C_FIFO_MAX : i2c->msg->len;
 	exynos5_i2c_en_timeout(i2c);
 
-	fifo_ctl = HSI2C_RXFIFO_EN | HSI2C_TXFIFO_EN |
-		HSI2C_TXFIFO_TRIGGER_LEVEL | HSI2C_RXFIFO_TRIGGER_LEVEL;
+	fifo_ctl = HSI2C_RXFIFO_EN | HSI2C_TXFIFO_EN;
 	writel(fifo_ctl, i2c->regs + HSI2C_FIFO_CTL);
 
 	i2c_ctl = readl(i2c->regs + HSI2C_CTL);
@@ -506,11 +506,13 @@ static void exynos5_i2c_message_start(struct exynos5_i2c *i2c, int stop)
 
 		i2c_auto_conf |= HSI2C_READ_WRITE;
 
+		fifo_ctl |= HSI2C_RXFIFO_TRIGGER_LEVEL(len);
 		int_en |= (HSI2C_INT_RX_ALMOSTFULL_EN |
 			HSI2C_INT_TRAILING_EN);
 	} else {
 		i2c_ctl |= HSI2C_TXCHON;
 
+		fifo_ctl |= HSI2C_TXFIFO_TRIGGER_LEVEL(len);
 		int_en |= HSI2C_INT_TX_ALMOSTEMPTY_EN;
 	}
 
@@ -519,6 +521,7 @@ static void exynos5_i2c_message_start(struct exynos5_i2c *i2c, int stop)
 
 	writel(HSI2C_SLV_ADDR_MAS(i2c->msg->addr), i2c->regs + HSI2C_ADDR);
 
+	writel(fifo_ctl, i2c->regs + HSI2C_FIFO_CTL);
 	writel(i2c_ctl, i2c->regs + HSI2C_CTL);
 
 	/* In auto mode the length of xfer cannot be 0 */
-- 
1.7.9.5



From kgene.kim at samsung.com  Wed Apr 10 06:34:38 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Wed, 10 Apr 2013 19:34:38 +0900
Subject: [PATCH RESEND] ARM: EXYNOS: no more support non-DT for EXYNOS SoCs
In-Reply-To: <51642dab.e844440a.0ad1.ffffc13f@mx.google.com>
References: <51642dab.e844440a.0ad1.ffffc13f@mx.google.com>
Message-ID: <310101ce35d7$00e7e000$02b7a000$%kim@samsung.com>

Kukjin Kim wrote:
> 
> From: Kukjin Kim <kgene.kim at samsung.com>
> 
> As we discussed in mailing list, non-DT for EXYNOS SoCs will not be
> supported from v3.10. This patch removes regarding files for non-DT
> including board files.
> 
> Signed-off-by: Kukjin Kim <kgene.kim at samsung.com>

I'd like to send this patch for v3.10 in late branch, if possible.

If any objections, please let me know.

- Kukjin



From tomasz.figa at gmail.com  Wed Apr 10 06:36:39 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Wed, 10 Apr 2013 12:36:39 +0200
Subject: [PATCH] pinctrl: Add pinctrl-s3c24xx driver
In-Reply-To: <201304100135.12471.heiko@sntech.de>
References: <201304100135.12471.heiko@sntech.de>
Message-ID: <1376906.qvoN3qK2gl@flatron>

Hi Heiko,

Basically looks good to me, but please see my inline comments about 
handling of EINT0-3.

On Wednesday 10 of April 2013 01:35:12 Heiko St?bner wrote:
> The s3c24xx pins follow a similar pattern as the other Samsung SoCs and
> can therefore reuse the already introduced infrastructure.
> 
> The s3c24xx SoCs have one design oddity in that the first 4 external
> interrupts do not reside in the eint pending register but in the main
> interrupt controller instead. We solve this by forwarding the external
> interrupt from the main controller into the irq domain of the pin bank.
> The masking/acking of these interrupts is handled in the same way.
> 
> Furthermore the S3C2412/2413 SoCs contain another oddity in that they
> keep the same 4 eints in the main interrupt controller and eintpend
> register and requiring ack operations to happen in both. To solve this
> a ctrl_type enum is introduced which can keep the type of controller
> in the samsung_pin_ctrl struct for later retrieval.
> 
> The ctrl_type enum contains only S3C24XX and S3C2412 types, as the
> eint-speciality is currently the only use-case. But it can be expaned
> if other SoCs gain special handling requirements later on.
> 
> Signed-off-by: Heiko Stuebner <heiko at sntech.de>
> ---
> Depends on the s3c64xx pinctrl work from Tomasz Figa.
> 
> It also does not yet contain the pin-definitions for all s3c24xx SoCs,
> as I don't have datasheets for them.
> 
> Tested on a s3c2416 based board.
> 
>  .../bindings/pinctrl/samsung-pinctrl.txt           |    4 +
>  drivers/gpio/gpio-samsung.c                        |    4 +
>  drivers/pinctrl/Kconfig                            |    5 +
>  drivers/pinctrl/Makefile                           |    1 +
>  drivers/pinctrl/pinctrl-s3c24xx.c                  |  603
> ++++++++++++++++++++ drivers/pinctrl/pinctrl-samsung.c                 
> |   10 +
>  drivers/pinctrl/pinctrl-samsung.h                  |   16 +
>  7 files changed, 643 insertions(+), 0 deletions(-)
>  create mode 100644 drivers/pinctrl/pinctrl-s3c24xx.c
> 
> diff --git
> a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
> b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt index
> c70fca1..1d8fc3c 100644
> --- a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
> +++ b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
> @@ -7,6 +7,10 @@ on-chip controllers onto these pads.
> 
>  Required Properties:
>  - compatible: should be one of the following.
> +  - "samsung,s3c2413-pinctrl": for S3C64xx-compatible pin-controller,
> +  - "samsung,s3c2416-pinctrl": for S3C64xx-compatible pin-controller,
> +  - "samsung,s3c2440-pinctrl": for S3C64xx-compatible pin-controller,
> +  - "samsung,s3c2450-pinctrl": for S3C64xx-compatible pin-controller,
>    - "samsung,s3c64xx-pinctrl": for S3C64xx-compatible pin-controller,
>    - "samsung,exynos4210-pinctrl": for Exynos4210 compatible
> pin-controller. - "samsung,exynos4x12-pinctrl": for Exynos4x12
> compatible pin-controller. diff --git a/drivers/gpio/gpio-samsung.c
> b/drivers/gpio/gpio-samsung.c index dc06a6f..73017b9 100644
> --- a/drivers/gpio/gpio-samsung.c
> +++ b/drivers/gpio/gpio-samsung.c
> @@ -3026,6 +3026,10 @@ static __init int samsung_gpiolib_init(void)
>  	*/
>  	struct device_node *pctrl_np;
>  	static const struct of_device_id exynos_pinctrl_ids[] = {
> +		{ .compatible = "samsung,s3c2413-pinctrl", },
> +		{ .compatible = "samsung,s3c2416-pinctrl", },
> +		{ .compatible = "samsung,s3c2440-pinctrl", },
> +		{ .compatible = "samsung,s3c2450-pinctrl", },
>  		{ .compatible = "samsung,s3c64xx-pinctrl", },
>  		{ .compatible = "samsung,exynos4210-pinctrl", },
>  		{ .compatible = "samsung,exynos4x12-pinctrl", },
> diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
> index 7402ac9..58d73ac 100644
> --- a/drivers/pinctrl/Kconfig
> +++ b/drivers/pinctrl/Kconfig
> @@ -226,6 +226,11 @@ config PINCTRL_EXYNOS5440
>  	select PINMUX
>  	select PINCONF
> 
> +config PINCTRL_S3C24XX
> +	bool "Samsung S3C24XX SoC pinctrl driver"
> +	depends on ARCH_S3C24XX
> +	select PINCTRL_SAMSUNG
> +
>  config PINCTRL_S3C64XX
>  	bool "Samsung S3C64XX SoC pinctrl driver"
>  	depends on ARCH_S3C64XX
> diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
> index 21d34c2..1ccdfd8 100644
> --- a/drivers/pinctrl/Makefile
> +++ b/drivers/pinctrl/Makefile
> @@ -45,6 +45,7 @@ obj-$(CONFIG_PINCTRL_COH901)	+= pinctrl-
coh901.o
>  obj-$(CONFIG_PINCTRL_SAMSUNG)	+= pinctrl-samsung.o
>  obj-$(CONFIG_PINCTRL_EXYNOS)	+= pinctrl-exynos.o
>  obj-$(CONFIG_PINCTRL_EXYNOS5440)	+= pinctrl-exynos5440.o
> +obj-$(CONFIG_PINCTRL_S3C24XX)	+= pinctrl-s3c24xx.o
>  obj-$(CONFIG_PINCTRL_S3C64XX)	+= pinctrl-s3c64xx.o
>  obj-$(CONFIG_PINCTRL_XWAY)	+= pinctrl-xway.o
>  obj-$(CONFIG_PINCTRL_LANTIQ)	+= pinctrl-lantiq.o
> diff --git a/drivers/pinctrl/pinctrl-s3c24xx.c
> b/drivers/pinctrl/pinctrl-s3c24xx.c new file mode 100644
> index 0000000..6b05519
> --- /dev/null
> +++ b/drivers/pinctrl/pinctrl-s3c24xx.c
> @@ -0,0 +1,603 @@
> +/*
> + * Exynos specific support for Samsung pinctrl/gpiolib driver with eint
> support. + *
> + * Copyright (c) 2012 Samsung Electronics Co., Ltd.
> + *		http://www.samsung.com
> + * Copyright (c) 2012 Linaro Ltd
> + *		http://www.linaro.org
> + *
> + * Author: Thomas Abraham <thomas.ab at samsung.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published
> by + * the Free Software Foundation; either version 2 of the License,
> or + * (at your option) any later version.
> + *
> + * This file contains the Samsung Exynos specific information required
> by the + * the Samsung pinctrl/gpiolib driver. It also includes the
> implementation of + * external gpio and wakeup interrupt support.
> + */
> +
> +#include <linux/module.h>
> +#include <linux/device.h>
> +#include <linux/interrupt.h>
> +#include <linux/irqdomain.h>
> +#include <linux/irq.h>
> +#include <linux/of_irq.h>
> +#include <linux/io.h>
> +#include <linux/slab.h>
> +#include <linux/err.h>
> +
> +#include <asm/mach/irq.h>
> +
> +#include "pinctrl-samsung.h"
> +
> +#define NUM_EINT	24
> +#define NUM_EINT_IRQ	6
> +#define EINT_MAX_PER_GROUP	8
> +
> +#define EINTPEND_REG	0xa8
> +#define EINTMASK_REG	0xa4
> +
> +#define EINT_GROUP(i)		((int)((i) / EINT_MAX_PER_GROUP))
> +#define EINT_REG(i)		((EINT_GROUP(i) * 4) + 0x88)
> +#define EINT_OFFS(i)		((i) % EINT_MAX_PER_GROUP * 4)
> +
> +#define EINT_LEVEL_LOW		0
> +#define EINT_LEVEL_HIGH		1
> +#define EINT_EDGE_FALLING	2
> +#define EINT_EDGE_RISING	4
> +#define EINT_EDGE_BOTH		6
> +#define EINT_MASK		0xf
> +
> +static struct samsung_pin_bank_type bank_type_1bit = {
> +	.fld_width = { 1, 1, },
> +	.reg_offset = { 0x00, 0x04, },
> +};
> +
> +static struct samsung_pin_bank_type bank_type_2bit = {
> +	.fld_width = { 2, 1, 2, },
> +	.reg_offset = { 0x00, 0x04, 0x08, },
> +};
> +
> +#define PIN_BANK_A(pins, reg, id)		\
> +	{						\
> +		.type		= &bank_type_1bit,	\
> +		.pctl_offset	= reg,			\
> +		.nr_pins	= pins,			\
> +		.eint_type	= EINT_TYPE_NONE,	\
> +		.name		= id			\
> +	}
> +
> +#define PIN_BANK_2BIT(pins, reg, id)		\
> +	{						\
> +		.type		= &bank_type_2bit,	\
> +		.pctl_offset	= reg,			\
> +		.nr_pins	= pins,			\
> +		.eint_type	= EINT_TYPE_NONE,	\
> +		.name		= id			\
> +	}
> +
> +#define PIN_BANK_2BIT_EINTW(pins, reg, id, eoffs, emask)\
> +	{						\
> +		.type		= &bank_type_2bit,	\
> +		.pctl_offset	= reg,			\
> +		.nr_pins	= pins,			\
> +		.eint_type	= EINT_TYPE_WKUP,	\
> +		.eint_func	= 2,			\
> +		.eint_mask	= emask,		\
> +		.eint_offset	= eoffs,		\
> +		.name		= id			\
> +	}
> +
> +/**
> + * struct s3c24xx_eint_data: EINT common data
> + * @drvdata: pin controller driver data
> + * @domains: IRQ domains of particular EINT interrupts
> + */
> +struct s3c24xx_eint_data {
> +	struct samsung_pinctrl_drv_data *drvdata;
> +	struct irq_domain *domains[NUM_EINT];
> +	int parents[NUM_EINT_IRQ];
> +};
> +
> +struct s3c24xx_eint_domain_data {
> +	struct samsung_pin_bank *bank;
> +	struct s3c24xx_eint_data *eint_data;

What about:

+	bool eint0_3_parent_only;

(or whatever name would be more appropriate), which would store the 
information about the s3c24xx-specific quirk in 24xx-specific data 
structure, without the need to add another field to the generic 
samsung_pinctrl_drv_data structure?

See my further comments on how I would see using this field in interrupt 
handling code.

> +};
> +
> +static int s3c24xx_eint_get_trigger(unsigned int type)
> +{
> +	int trigger;
> +
> +	switch (type) {
> +	case IRQ_TYPE_EDGE_RISING:
> +		trigger = EINT_EDGE_RISING;
> +		break;
> +	case IRQ_TYPE_EDGE_FALLING:
> +		trigger = EINT_EDGE_FALLING;
> +		break;
> +	case IRQ_TYPE_EDGE_BOTH:
> +		trigger = EINT_EDGE_BOTH;
> +		break;
> +	case IRQ_TYPE_LEVEL_HIGH:
> +		trigger = EINT_LEVEL_HIGH;
> +		break;
> +	case IRQ_TYPE_LEVEL_LOW:
> +		trigger = EINT_LEVEL_LOW;
> +		break;
> +	default:
> +		return -EINVAL;
> +	}
> +
> +	return trigger;
> +}
> +
> +static void s3c24xx_eint_set_handler(unsigned int irq, unsigned int
> type) +{
> +	/* Edge- and level-triggered interrupts need different handlers */
> +	if (type & IRQ_TYPE_EDGE_BOTH)
> +		__irq_set_handler_locked(irq, handle_edge_irq);
> +	else
> +		__irq_set_handler_locked(irq, handle_level_irq);
> +}
> +
> +static void s3c24xx_eint_set_function(struct samsung_pinctrl_drv_data
> *d, +					struct samsung_pin_bank *bank, int 
pin)
> +{
> +	struct samsung_pin_bank_type *bank_type = bank->type;
> +	unsigned long flags;
> +	void __iomem *reg;
> +	u8 shift;
> +	u32 mask;
> +	u32 val;
> +
> +	/* Make sure that pin is configured as interrupt */
> +	reg = d->virt_base + bank->pctl_offset;
> +	shift = pin * bank_type->fld_width[PINCFG_TYPE_FUNC];
> +	mask = (1 << bank_type->fld_width[PINCFG_TYPE_FUNC]) - 1;
> +
> +	spin_lock_irqsave(&bank->slock, flags);
> +
> +	val = readl(reg);
> +	val &= ~(mask << shift);
> +	val |= bank->eint_func << shift;
> +	writel(val, reg);
> +
> +	spin_unlock_irqrestore(&bank->slock, flags);
> +}
> +
> +static int s3c24xx_eint_type(struct irq_data *data, unsigned int type)
> +{
> +	struct samsung_pin_bank *bank = irq_data_get_irq_chip_data(data);
> +	struct samsung_pinctrl_drv_data *d = bank->drvdata;
> +	int index = bank->eint_offset + data->hwirq;
> +	void __iomem *reg;
> +	int trigger;
> +	u8 shift;
> +	u32 val;
> +
> +	trigger = s3c24xx_eint_get_trigger(type);
> +	if (trigger < 0) {
> +		dev_err(d->dev, "unsupported external interrupt type\n");
> +		return -EINVAL;
> +	}
> +
> +	s3c24xx_eint_set_handler(data->irq, type);
> +
> +	/* Set up interrupt trigger */
> +	reg = d->virt_base + EINT_REG(index);
> +	shift = EINT_OFFS(index);
> +
> +	val = readl(reg);
> +	val &= ~(EINT_MASK << shift);
> +	val |= trigger << shift;
> +	writel(val, reg);
> +
> +	s3c24xx_eint_set_function(d, bank, data->hwirq);
> +
> +	return 0;
> +}

Now I would split the following 3 functions into two sets of 3 functions, 
one set for s3c2412 and other for remaining SoCs and make separate EINT0-3 
IRQ chips for both cases.

> +
> +static void s3c24xx_eint0_3_ack(struct irq_data *data)
> +{
> +	struct samsung_pin_bank *bank = irq_data_get_irq_chip_data(data);
> +	struct samsung_pinctrl_drv_data *d = bank->drvdata;
> +	struct s3c24xx_eint_domain_data *ddata = bank->irq_domain-
>host_data;
> +	struct s3c24xx_eint_data *eint_data = ddata->eint_data;
> +	int parent_irq = eint_data->parents[data->hwirq];
> +	struct irq_chip *parent_chip = irq_get_chip(parent_irq);
> +
> +	if (d->ctrl->type == S3C2412) {
> +		unsigned long bitval = 1UL << data->hwirq;
> +		writel(bitval, d->virt_base + EINTPEND_REG);
> +	}
> +
> +	if (parent_chip->irq_ack)
> +		parent_chip->irq_ack(irq_get_irq_data(parent_irq));

Btw. Is this parent level acking really needed here?

> +}
> +
> +static void s3c24xx_eint0_3_mask(struct irq_data *data)
> +{
> +	struct samsung_pin_bank *bank = irq_data_get_irq_chip_data(data);
> +	struct samsung_pinctrl_drv_data *d = bank->drvdata;
> +	struct s3c24xx_eint_domain_data *ddata = bank->irq_domain-
>host_data;
> +	struct s3c24xx_eint_data *eint_data = ddata->eint_data;
> +	int parent_irq = eint_data->parents[data->hwirq];
> +	struct irq_chip *parent_chip = irq_get_chip(parent_irq);
> +
> +	if (d->ctrl->type == S3C2412) {
> +		unsigned long mask;
> +		mask = readl(d->virt_base + EINTMASK_REG);
> +		mask |= (1UL << data->hwirq);
> +		writel(mask, d->virt_base + EINTMASK_REG);
> +	}
> +
> +	if (parent_chip->irq_mask)
> +		parent_chip->irq_mask(irq_get_irq_data(parent_irq));
> +}
> +
> +static void s3c24xx_eint0_3_unmask(struct irq_data *data)
> +{
> +	struct samsung_pin_bank *bank = irq_data_get_irq_chip_data(data);
> +	struct samsung_pinctrl_drv_data *d = bank->drvdata;
> +	struct s3c24xx_eint_domain_data *ddata = bank->irq_domain-
>host_data;
> +	struct s3c24xx_eint_data *eint_data = ddata->eint_data;
> +	int parent_irq = eint_data->parents[data->hwirq];
> +	struct irq_chip *parent_chip = irq_get_chip(parent_irq);
> +
> +	if (d->ctrl->type == S3C2412) {
> +		unsigned long mask;
> +		mask = readl(d->virt_base + EINTMASK_REG);
> +		mask &= ~(1UL << data->hwirq);
> +		writel(mask, d->virt_base + EINTMASK_REG);
> +	}
> +
> +	if (parent_chip->irq_unmask)
> +		parent_chip->irq_unmask(irq_get_irq_data(parent_irq));
> +}
> +
> +static struct irq_chip s3c24xx_eint0_3_chip = {
> +	.name		= "s3c-eint0_3",
> +	.irq_ack	= s3c24xx_eint0_3_ack,
> +	.irq_mask	= s3c24xx_eint0_3_mask,
> +	.irq_unmask	= s3c24xx_eint0_3_unmask,
> +	.irq_set_type	= s3c24xx_eint_type,
> +};
> +
> +static void s3c24xx_eint_ack(struct irq_data *data)
> +{
> +	struct samsung_pin_bank *bank = irq_data_get_irq_chip_data(data);
> +	struct samsung_pinctrl_drv_data *d = bank->drvdata;
> +	unsigned char index = bank->eint_offset + data->hwirq;
> +
> +	writel(1UL << index, d->virt_base + EINTPEND_REG);
> +}
> +
> +static void s3c24xx_eint_mask(struct irq_data *data)
> +{
> +	struct samsung_pin_bank *bank = irq_data_get_irq_chip_data(data);
> +	struct samsung_pinctrl_drv_data *d = bank->drvdata;
> +	unsigned char index = bank->eint_offset + data->hwirq;
> +	unsigned long mask;
> +
> +	mask = readl(d->virt_base + EINTMASK_REG);
> +	mask |= (1UL << index);
> +	writel(mask, d->virt_base + EINTMASK_REG);
> +}
> +
> +static void s3c24xx_eint_unmask(struct irq_data *data)
> +{
> +	struct samsung_pin_bank *bank = irq_data_get_irq_chip_data(data);
> +	struct samsung_pinctrl_drv_data *d = bank->drvdata;
> +	unsigned char index = bank->eint_offset + data->hwirq;
> +	unsigned long mask;
> +
> +	mask = readl(d->virt_base + EINTMASK_REG);
> +	mask &= ~(1UL << index);
> +	writel(mask, d->virt_base + EINTMASK_REG);
> +}
> +
> +static struct irq_chip s3c24xx_eint_chip = {
> +	.name		= "s3c-eint",
> +	.irq_ack	= s3c24xx_eint_ack,
> +	.irq_mask	= s3c24xx_eint_mask,
> +	.irq_unmask	= s3c24xx_eint_unmask,
> +	.irq_set_type	= s3c24xx_eint_type,
> +};
> +
> +static void s3c24xx_demux_eint0_3(unsigned int irq, struct irq_desc
> *desc) +{
> +	struct irq_data *data = irq_desc_get_irq_data(desc);
> +	struct s3c24xx_eint_data *eint_data = irq_get_handler_data(irq);
> +	unsigned int virq;
> +

Instead of acking the interrupt at parent chip from ack callback of 
EINT0_3 chip, I would rather use chained_irq_enter() here...

> +	/* the first 4 eints have a simple 1 to 1 mapping */
> +	virq = irq_linear_revmap(eint_data->domains[data->hwirq],
> data->hwirq); +	/* Something must be really wrong if an unmapped 
EINT
> +	 * was unmasked...
> +	 */
> +	BUG_ON(!virq);
> +
> +	generic_handle_irq(virq);

...and chained_irq_exit() here.

> +}
> +
> +static inline void s3c24xx_demux_eint(unsigned int irq, struct irq_desc
> *desc, +				      u32 offset, u32 range)
> +{
> +	struct irq_chip *chip = irq_get_chip(irq);
> +	struct s3c24xx_eint_data *data = irq_get_handler_data(irq);
> +	struct samsung_pinctrl_drv_data *d = data->drvdata;
> +	unsigned int pend, mask;
> +
> +	chained_irq_enter(chip, desc);
> +
> +	pend = readl(d->virt_base + EINTPEND_REG);
> +	mask = readl(d->virt_base + EINTMASK_REG);
> +
> +	pend &= ~mask;
> +	pend &= range;
> +
> +	while (pend) {
> +		unsigned int virq;
> +
> +		irq = __ffs(pend);
> +		pend &= ~(1 << irq);
> +		virq = irq_linear_revmap(data->domains[irq], irq - 
offset);
> +		/* Something must be really wrong if an unmapped EINT
> +		 * was unmasked...
> +		 */
> +		BUG_ON(!virq);
> +
> +		generic_handle_irq(virq);
> +	}
> +
> +	chained_irq_exit(chip, desc);
> +}
> +
> +static void s3c24xx_demux_eint4_7(unsigned int irq, struct irq_desc
> *desc) +{
> +	s3c24xx_demux_eint(irq, desc, 0, 0xf0);
> +}
> +
> +static void s3c24xx_demux_eint8_23(unsigned int irq, struct irq_desc
> *desc) +{
> +	s3c24xx_demux_eint(irq, desc, 8, 0xffff00);
> +}
> +
> +static irq_flow_handler_t s3c24xx_eint_handlers[NUM_EINT_IRQ] = {
> +	s3c24xx_demux_eint0_3,
> +	s3c24xx_demux_eint0_3,
> +	s3c24xx_demux_eint0_3,
> +	s3c24xx_demux_eint0_3,
> +	s3c24xx_demux_eint4_7,
> +	s3c24xx_demux_eint8_23,
> +};
> +
> +static int s3c24xx_gpf_irq_map(struct irq_domain *h, unsigned int virq,
> +					irq_hw_number_t hw)
> +{
> +	struct s3c24xx_eint_domain_data *ddata = h->host_data;
> +	struct samsung_pin_bank *bank = ddata->bank;
> +
> +	if (!(bank->eint_mask & (1 << (bank->eint_offset + hw))))
> +		return -EINVAL;
> +
> +	if (hw <= 3) {

Now here I would check ddata->eint0_3_parent_only and set the chip 
conditionally, either to s3c24xx or s3c2412 variant.

> +		irq_set_chip_and_handler(virq, &s3c24xx_eint0_3_chip,
> +					 handle_edge_irq);
> +		irq_set_chip_data(virq, bank);
> +	} else {
> +		irq_set_chip_and_handler(virq, &s3c24xx_eint_chip,
> +					 handle_edge_irq);
> +		irq_set_chip_data(virq, bank);
> +	}
> +	set_irq_flags(virq, IRQF_VALID);
> +	return 0;
> +}
> +
> +static const struct irq_domain_ops s3c24xx_gpf_irq_ops = {
> +	.map	= s3c24xx_gpf_irq_map,
> +	.xlate	= irq_domain_xlate_twocell,
> +};
> +
> +static int s3c24xx_gpg_irq_map(struct irq_domain *h, unsigned int virq,
> +					irq_hw_number_t hw)
> +{
> +	struct s3c24xx_eint_domain_data *ddata = h->host_data;
> +	struct samsung_pin_bank *bank = ddata->bank;
> +
> +	if (!(bank->eint_mask & (1 << (bank->eint_offset + hw))))
> +		return -EINVAL;
> +
> +	irq_set_chip_and_handler(virq, &s3c24xx_eint_chip, 
handle_edge_irq);
> +	irq_set_chip_data(virq, bank);
> +	set_irq_flags(virq, IRQF_VALID);
> +	return 0;
> +}
> +
> +static const struct irq_domain_ops s3c24xx_gpg_irq_ops = {
> +	.map	= s3c24xx_gpg_irq_map,
> +	.xlate	= irq_domain_xlate_twocell,
> +};
> +
> +static const struct of_device_id s3c24xx_eint_irq_ids[] = {
> +	{ .compatible = "samsung,s3c24xx-wakeup-eint", },
> +	{ }
> +};
> +
> +static int s3c24xx_eint_init(struct samsung_pinctrl_drv_data *d)
> +{
> +	struct device *dev = d->dev;
> +	struct device_node *eint_np = NULL;
> +	struct device_node *np;
> +	struct samsung_pin_bank *bank;
> +	struct s3c24xx_eint_data *eint_data;
> +	const struct irq_domain_ops *ops;
> +	unsigned int i;
> +
> +	for_each_child_of_node(dev->of_node, np) {
> +		if (of_match_node(s3c24xx_eint_irq_ids, np)) {
> +			eint_np = np;
> +			break;
> +		}
> +	}
> +	if (!eint_np)
> +		return -ENODEV;
> +
> +	eint_data = devm_kzalloc(dev, sizeof(*eint_data), GFP_KERNEL);
> +	if (!eint_data) {
> +		dev_err(dev, "could not allocate memory for wkup eint 
data\n");
> +		return -ENOMEM;
> +	}
> +	eint_data->drvdata = d;
> +
> +	for (i = 0; i < NUM_EINT_IRQ; ++i) {
> +		unsigned int irq;
> +
> +		irq = irq_of_parse_and_map(eint_np, i);
> +		if (!irq) {
> +			dev_err(dev, "failed to get wakeup EINT IRQ %d\n", 
i);
> +			return -ENXIO;
> +		}
> +
> +		eint_data->parents[i] = irq;
> +		irq_set_chained_handler(irq, s3c24xx_eint_handlers[i]);
> +		irq_set_handler_data(irq, eint_data);
> +	}
> +
> +	bank = d->ctrl->pin_banks;
> +	for (i = 0; i < d->ctrl->nr_banks; ++i, ++bank) {
> +		struct s3c24xx_eint_domain_data *ddata;
> +		unsigned int mask;
> +		unsigned int irq;
> +		unsigned int pin;
> +
> +		if (bank->eint_type != EINT_TYPE_WKUP)
> +			continue;
> +
> +		ddata = devm_kzalloc(dev, sizeof(*ddata), GFP_KERNEL);
> +		if (!ddata) {
> +			dev_err(dev, "failed to allocate domain data\n");
> +			return -ENOMEM;
> +		}
> +		ddata->bank = bank;
> +		ddata->eint_data = eint_data;

Here the eint0_3_parent_only field can be set based on compatible string 
of the EINT controller.

> +
> +		ops = (bank->eint_offset == 0) ? &s3c24xx_gpf_irq_ops
> +					       : &s3c24xx_gpg_irq_ops;
> +
> +		bank->irq_domain = irq_domain_add_linear(bank->of_node,
> +				bank->nr_pins, ops, ddata);
> +		if (!bank->irq_domain) {
> +			dev_err(dev, "wkup irq domain add failed\n");
> +			return -ENXIO;
> +		}
> +
> +		irq = bank->eint_offset;
> +		mask = bank->eint_mask;
> +		for (pin = 0; mask; ++pin, mask >>= 1) {
> +			if (irq > NUM_EINT)
> +				break;
> +			if (!(mask & 1))
> +				continue;
> +			eint_data->domains[irq] = bank->irq_domain;
> +			++irq;
> +		}
> +	}
> +
> +	return 0;
> +}
> +
> +static struct samsung_pin_bank s3c2413_pin_banks[] = {
> +	PIN_BANK_A(23, 0x000, "gpa"),
> +	PIN_BANK_2BIT(11, 0x010, "gpb"),
> +	PIN_BANK_2BIT(16, 0x020, "gpc"),
> +	PIN_BANK_2BIT(16, 0x030, "gpd"),
> +	PIN_BANK_2BIT(16, 0x040, "gpe"),
> +	PIN_BANK_2BIT_EINTW(8, 0x050, "gpf", 0, 0xff),
> +	PIN_BANK_2BIT_EINTW(16, 0x060, "gpg", 8, 0xffff00),
> +	PIN_BANK_2BIT(11, 0x070, "gph"),
> +	PIN_BANK_2BIT(13, 0x080, "gpj"),
> +};
> +
> +struct samsung_pin_ctrl s3c2413_pin_ctrl[] = {
> +	{
> +		.pin_banks	= s3c2413_pin_banks,
> +		.nr_banks	= ARRAY_SIZE(s3c2413_pin_banks),
> +		.eint_wkup_init = s3c24xx_eint_init,
> +		.label		= "S3C2413-GPIO",
> +		.type		= S3C2412,

And then finally you shouldn't need this type field anymore.

Best regards,
Tomasz

> +	},
> +};
> +
> +static struct samsung_pin_bank s3c2416_pin_banks[] = {
> +	PIN_BANK_A(27, 0x000, "gpa"),
> +	PIN_BANK_2BIT(11, 0x010, "gpb"),
> +	PIN_BANK_2BIT(16, 0x020, "gpc"),
> +	PIN_BANK_2BIT(16, 0x030, "gpd"),
> +	PIN_BANK_2BIT(16, 0x040, "gpe"),
> +	PIN_BANK_2BIT_EINTW(8, 0x050, "gpf", 0, 0xff),
> +	PIN_BANK_2BIT_EINTW(8, 0x060, "gpg", 8, 0xff00),
> +	PIN_BANK_2BIT(15, 0x070, "gph"),
> +	PIN_BANK_2BIT(16, 0x0e0, "gpk"),
> +	PIN_BANK_2BIT(14, 0x0f0, "gpl"),
> +	PIN_BANK_2BIT(2, 0x100, "gpm"),
> +};
> +
> +struct samsung_pin_ctrl s3c2416_pin_ctrl[] = {
> +	{
> +		.pin_banks	= s3c2416_pin_banks,
> +		.nr_banks	= ARRAY_SIZE(s3c2416_pin_banks),
> +		.eint_wkup_init = s3c24xx_eint_init,
> +		.label		= "S3C2416-GPIO",
> +		.type		= S3C24XX,
> +	},
> +};
> +
> +static struct samsung_pin_bank s3c2440_pin_banks[] = {
> +	PIN_BANK_A(25, 0x000, "gpa"),
> +	PIN_BANK_2BIT(11, 0x010, "gpb"),
> +	PIN_BANK_2BIT(16, 0x020, "gpc"),
> +	PIN_BANK_2BIT(16, 0x030, "gpd"),
> +	PIN_BANK_2BIT(16, 0x040, "gpe"),
> +	PIN_BANK_2BIT_EINTW(8, 0x050, "gpf", 0, 0xff),
> +	PIN_BANK_2BIT_EINTW(16, 0x060, "gpg", 8, 0xffff00),
> +	PIN_BANK_2BIT(11, 0x070, "gph"),
> +	PIN_BANK_2BIT(13, 0x0d0, "gpj"),
> +};
> +
> +struct samsung_pin_ctrl s3c2440_pin_ctrl[] = {
> +	{
> +		.pin_banks	= s3c2440_pin_banks,
> +		.nr_banks	= ARRAY_SIZE(s3c2440_pin_banks),
> +		.eint_wkup_init = s3c24xx_eint_init,
> +		.label		= "S3C2440-GPIO",
> +		.type		= S3C24XX,
> +	},
> +};
> +
> +static struct samsung_pin_bank s3c2450_pin_banks[] = {
> +	PIN_BANK_A(28, 0x000, "gpa"),
> +	PIN_BANK_2BIT(11, 0x010, "gpb"),
> +	PIN_BANK_2BIT(16, 0x020, "gpc"),
> +	PIN_BANK_2BIT(16, 0x030, "gpd"),
> +	PIN_BANK_2BIT(16, 0x040, "gpe"),
> +	PIN_BANK_2BIT_EINTW(8, 0x050, "gpf", 0, 0xff),
> +	PIN_BANK_2BIT_EINTW(16, 0x060, "gpg", 8, 0xffff00),
> +	PIN_BANK_2BIT(15, 0x070, "gph"),
> +	PIN_BANK_2BIT(16, 0x0d0, "gpj"),
> +	PIN_BANK_2BIT(16, 0x0e0, "gpk"),
> +	PIN_BANK_2BIT(15, 0x0f0, "gpl"),
> +	PIN_BANK_2BIT(2, 0x100, "gpm"),
> +};
> +
> +struct samsung_pin_ctrl s3c2450_pin_ctrl[] = {
> +	{
> +		.pin_banks	= s3c2450_pin_banks,
> +		.nr_banks	= ARRAY_SIZE(s3c2450_pin_banks),
> +		.eint_wkup_init = s3c24xx_eint_init,
> +		.label		= "S3C2450-GPIO",
> +		.type		= S3C24XX,
> +	},
> +};
> diff --git a/drivers/pinctrl/pinctrl-samsung.c
> b/drivers/pinctrl/pinctrl-samsung.c index e836135..234c32f 100644
> --- a/drivers/pinctrl/pinctrl-samsung.c
> +++ b/drivers/pinctrl/pinctrl-samsung.c
> @@ -977,6 +977,16 @@ static const struct of_device_id
> samsung_pinctrl_dt_match[] = { { .compatible =
> "samsung,s3c64xx-pinctrl",
>  		.data = s3c64xx_pin_ctrl },
>  #endif
> +#ifdef CONFIG_PINCTRL_S3C24XX
> +	{ .compatible = "samsung,s3c2413-pinctrl",
> +		.data = s3c2413_pin_ctrl },
> +	{ .compatible = "samsung,s3c2416-pinctrl",
> +		.data = s3c2416_pin_ctrl },
> +	{ .compatible = "samsung,s3c2440-pinctrl",
> +		.data = s3c2440_pin_ctrl },
> +	{ .compatible = "samsung,s3c2450-pinctrl",
> +		.data = s3c2450_pin_ctrl },
> +#endif
>  	{},
>  };
>  MODULE_DEVICE_TABLE(of, samsung_pinctrl_dt_match);
> diff --git a/drivers/pinctrl/pinctrl-samsung.h
> b/drivers/pinctrl/pinctrl-samsung.h index 7c7f9eb..8bd317c 100644
> --- a/drivers/pinctrl/pinctrl-samsung.h
> +++ b/drivers/pinctrl/pinctrl-samsung.h
> @@ -81,6 +81,16 @@ enum eint_type {
>  	EINT_TYPE_WKUP_MUX,
>  };
> 
> +/**
> + * enum ctrl_type - variances of a pin controller type
> + * @S3C24XX: generic s3c24xx pin handling
> + * @S3C2412: s3c2412-type eints, existing in the main and eint
> controllers + */
> +enum ctrl_type {
> +	S3C24XX,
> +	S3C2412,
> +};
> +
>  /* maximum length of a pin in pin descriptor (example: "gpa0-0") */
>  #define PIN_NAME_LENGTH	10
> 
> @@ -164,6 +174,7 @@ struct samsung_pin_bank {
>   * @eint_wkup_init: platform specific callback to setup the external
> wakeup *	interrupts for the controller.
>   * @label: for debug information.
> + * @type: type of pin-controller
>   */
>  struct samsung_pin_ctrl {
>  	struct samsung_pin_bank	*pin_banks;
> @@ -185,6 +196,7 @@ struct samsung_pin_ctrl {
>  	int		(*eint_gpio_init)(struct samsung_pinctrl_drv_data 
*);
>  	int		(*eint_wkup_init)(struct samsung_pinctrl_drv_data 
*);
>  	char		*label;
> +	enum ctrl_type	type;
>  };
> 
>  /**
> @@ -246,5 +258,9 @@ extern struct samsung_pin_ctrl
> exynos4210_pin_ctrl[]; extern struct samsung_pin_ctrl
> exynos4x12_pin_ctrl[];
>  extern struct samsung_pin_ctrl exynos5250_pin_ctrl[];
>  extern struct samsung_pin_ctrl s3c64xx_pin_ctrl[];
> +extern struct samsung_pin_ctrl s3c2413_pin_ctrl[];
> +extern struct samsung_pin_ctrl s3c2416_pin_ctrl[];
> +extern struct samsung_pin_ctrl s3c2440_pin_ctrl[];
> +extern struct samsung_pin_ctrl s3c2450_pin_ctrl[];
> 
>  #endif /* __PINCTRL_SAMSUNG_H */


From heiko at sntech.de  Wed Apr 10 06:37:31 2013
From: heiko at sntech.de (Heiko =?utf-8?q?St=C3=BCbner?=)
Date: Wed, 10 Apr 2013 12:37:31 +0200
Subject: [PATCH v2 0/3] ARM: S3C24XX: Add devicetree support for s3c2416
In-Reply-To: <30ff01ce35d4$5f4920d0$1ddb6270$%kim@samsung.com>
References: <201302180103.53084.heiko@sntech.de>
 <30ff01ce35d4$5f4920d0$1ddb6270$%kim@samsung.com>
Message-ID: <201304101237.31874.heiko@sntech.de>

Am Mittwoch, 10. April 2013, 12:15:48 schrieb Kukjin Kim:
> Heiko St?bner wrote:
> > This is the second installment of beginning devicetree support the
> > Samsung S3C24xx architectures and focuses on the s3c2416 for now.
> > 
> > Included is the devicetree support for the s3c24xx irq controller and
> > basic support for smdk2416 boards, which can sucessfully boot.
> > 
> > 
> > After the discussion with Thomas Abraham on v1 and staring to long at all
> > of
> > this, I'm not even sure if having the interrupt mapping in the binding
> > is the correct way to go anymore.
> > 
> > The key positive aspect of this solution is, that after everything is
> > running
> > via dt all the SoC specific mapping tables in the driver can go away,
> > cutting
> > its length in half.
> > 
> > The other option would be as Thomas suggested to define specific irq-
> > controller
> > types (i.e. s3c2416-intc, s3c2443-intc, ... resulting in 16 types) and
> > keep
> > the mapping data in the code, as it is now.
> > 
> > So I would be very thankful for a bit of guidance on what is the better
> > way.
> > 
> > 
> > The series depends on the finalized s3c24xx irq rework, which probably
> > won't
> > make it into 3.9 and also the clocksource dt support by Tomasz Figa,
> > which are not in any tree yet.
> > 
> > 
> > Changes since v1:
> > - adapt to changes in the underlying s3c24xx irq rework
> > 
> >   = more shared init code
> > 
> > - use irqchip infrastructure
> > - limit number of possible irq-types to not encode implementation details
> > 
> >   into the binding
> > 
> > - include new samsung-clocksource
> > 
> > Heiko Stuebner (3):
> >   ARM: S3C24XX: move irq driver to drivers/irqchip
> >   irqchip: irq-s3c24xx: add devicetree support
> >   ARM: S3C24XX: Add devicetree support and dt-board file for s3c2416 SoCs
> >  
> >  .../interrupt-controller/samsung,s3c24xx-irq.txt   |   53 ++++++
> >  arch/arm/boot/dts/Makefile                         |    1 +
> >  arch/arm/boot/dts/s3c2416-smdk2416.dts             |   79 ++++++++
> >  arch/arm/boot/dts/s3c2416.dtsi                     |  193
> >  ++++++++++++++++++++ arch/arm/boot/dts/s3c24xx.dtsi                    
> >  |  165 +++++++++++++++++ arch/arm/mach-s3c24xx/Kconfig                 
> >      |   10 +
> >  arch/arm/mach-s3c24xx/Makefile                     |    3 +-
> >  arch/arm/mach-s3c24xx/mach-s3c2416-dt.c            |   91 +++++++++
> >  drivers/irqchip/Makefile                           |    1 +
> >  .../irq.c => drivers/irqchip/irq-s3c24xx.c         |  128 +++++++++++++
> >  10 files changed, 723 insertions(+), 1 deletions(-)
> >  create mode 100644 Documentation/devicetree/bindings/interrupt-
> > 
> > controller/samsung,s3c24xx-irq.txt
> > 
> >  create mode 100644 arch/arm/boot/dts/s3c2416-smdk2416.dts
> >  create mode 100644 arch/arm/boot/dts/s3c2416.dtsi
> >  create mode 100644 arch/arm/boot/dts/s3c24xx.dtsi
> >  create mode 100644 arch/arm/mach-s3c24xx/mach-s3c2416-dt.c
> >  rename arch/arm/mach-s3c24xx/irq.c => drivers/irqchip/irq-s3c24xx.c
> >  (92%)
> > 
> > --
> > 1.7.2.3
> 
> Basically, looks good to me and thanks for your effort.
> 
> BTW, if you don't mind, would be better to send to upstream next time.
> Because I need to consider other s3c24xx SoCs for DT...

hehe, you're digging up quite old stuff :-)

This of course got superseeded by the different approach to s3c24xx-irq dt-
support and the pinctrl work.

I'll send a new version of the dt support which takes into account all the 
recent changes in the next couple of days.

Of course I'm ok with delaying this until 3.11. At least all the building 
blocks (irq and pinctrl) are there now.


Heiko


From linux at arm.linux.org.uk  Wed Apr 10 06:40:02 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Wed, 10 Apr 2013 11:40:02 +0100
Subject: Removal of NWFPE in its entirety, and VFP emulation code
Message-ID: <20130410104002.GF14496@n2100.arm.linux.org.uk>

I have just committed a patch to remove the arch/arm/nwfpe code from
the kernel, and the VFP code emulating the FP operations.

This I have done after it has been brought to my attention by the OSADL's
GPL-violations project that the license for the softfloat library is
incompatible with GPLv2.  This is because the FSF have ruled that
indemnification clauses consitute an "additional restriction" which is
incompatible with the GPLv2 section 6.  NWFPE contains the softfloat
library, and VFP's emulation code is a derivative of softfloat.

This will be very disruptive for ARMv4 and ARMv5 CPUs, which will no
longer be able to run userspace with NWFPE support removed.  A possible
solution there is to resurrect FASTFPE support and merge that into
mainline in place of NWFPE.  FASTFPE's hooks are all present in the
kernel, and it should just be a case of adding the FASTFPE code.
However, FASTFPE is probably lacking GDB and signal stack support.
(FastFPE's per-thread workspace is different from NWFPE.)

The situation with VFP is likely less disruptive - only instructions
which aren't implemented in hardware (or, for example, if you ask for
inexact exceptions to be enabled) which are bounced to the software
support code will be affected.  I think OMAP should get away unscathed,
but ARM's implementation will bounce if inexact exceptions are enabled
or in a few corner cases.  Qualcomm is likely to be the worst affected
by this.

Will Deacon has tested debian armhf on a Cortex-A15 with VFP emulation
support removed, which boots successfully.

There is some discussion that needs to happen to investigate possible
solutions to this, which are:

1. Whether we can persuade John to relicense his code.  From what I
   understand from the discussions which have already happened, John
   is against that because he requires the indemnification clause.

   It has been suggested that someone from the community could indemnify
   John, but that doesn't make any sense to me - and it would be hard to
   see how that in itself wouldn't require some kind of additional clause
   which could in itself be seen as an additional restriction.

2. Someone creates a clean-room GPLv2 compatible softfloat
   implementation.

3. Something else?

As I will be away for the next week, and unable to deal with this in any
way, I have taken the only option available to me at the present time and
removed the offending code, which is a change I will be pushing upstream
today.  This brings us back to a compliant situation, to the best of my
knowledge.


From s.nawrocki at samsung.com  Wed Apr 10 06:41:47 2013
From: s.nawrocki at samsung.com (Sylwester Nawrocki)
Date: Wed, 10 Apr 2013 12:41:47 +0200
Subject: [PATCH RESEND] ARM: EXYNOS: no more support non-DT for EXYNOS SoCs
In-Reply-To: <310101ce35d7$00e7e000$02b7a000$%kim@samsung.com>
References: <51642dab.e844440a.0ad1.ffffc13f@mx.google.com>
 <310101ce35d7$00e7e000$02b7a000$%kim@samsung.com>
Message-ID: <516541EB.8080404@samsung.com>

On 04/10/2013 12:34 PM, Kukjin Kim wrote:
> Kukjin Kim wrote:
>>
>> From: Kukjin Kim <kgene.kim at samsung.com>
>>
>> As we discussed in mailing list, non-DT for EXYNOS SoCs will not be
>> supported from v3.10. This patch removes regarding files for non-DT
>> including board files.
>>
>> Signed-off-by: Kukjin Kim <kgene.kim at samsung.com>

It looks OK to me.

> I'd like to send this patch for v3.10 in late branch, if possible.
> 
> If any objections, please let me know.
> 
> - Kukjin

Thanks,
Sylwester



From hechtb at gmail.com  Wed Apr 10 06:43:13 2013
From: hechtb at gmail.com (Bastian Hecht)
Date: Wed, 10 Apr 2013 12:43:13 +0200
Subject: v7_flush_kern_cache_louis flushes up to L2?
Message-ID: <CABYn4sxUCoWhC_4qydzbCtZdQdetqFZ_u5WtXsghprQget9f5g@mail.gmail.com>

Hello,

I've got a Cortex-A9 UP with a L2 and want to submit some PM code I've
written. Just to make sure I've made no mistake, it would be very
helpful if you can confirm a hypothesis I use in my code:

v7_flush_kern_cache_louis: Flush the data cache up to Level of
Unification Inner Shareable

This flushes the data out up to the L2, right? The ARM docs say that
the Point of Unification would be my L2. I'm a bit confused by the
term "Level of Unification Inner Shareable" (that states that in an
SMP system L1 coherency is guaranteed and all is flushed to the L2?).

Thanks,

 Bastian


From rogerq at ti.com  Wed Apr 10 06:55:58 2013
From: rogerq at ti.com (Roger Quadros)
Date: Wed, 10 Apr 2013 13:55:58 +0300
Subject: [RFC][PATCH 1/2] ARM: OMAP4: clock: Add device tree support for
 AUXCLKs
In-Reply-To: <20130410080630.14359.68178@quantum>
References: <1363703220-4777-1-git-send-email-rogerq@ti.com>
 <20130403234242.GE10155@atomide.com> <515D2D30.3000306@ti.com>
 <20130404164137.GH10155@atomide.com> <515EA9E3.1010409@ti.com>
 <20130405155851.GA10155@atomide.com> <5163E589.1040809@ti.com>
 <20130409164928.GL10155@atomide.com> <20130409174319.GP10155@atomide.com>
 <20130409204900.GA8815@kahuna> <20130410080630.14359.68178@quantum>
Message-ID: <5165453E.6090503@ti.com>

On 04/10/2013 11:06 AM, Mike Turquette wrote:
> Quoting Nishanth Menon (2013-04-09 13:49:00)
>> On 10:43-20130409, Tony Lindgren wrote:
>>> * Tony Lindgren <tony at atomide.com> [130409 09:54]:
>>>> * Roger Quadros <rogerq at ti.com> [130409 03:00]:
>>>>> On 04/05/2013 06:58 PM, Tony Lindgren wrote:
>>>>>>
>>>>>> Can't you just use the clock name there to get it?
>>>>>
>>>>> In device tree we don't pass around clock names. You can either get
>>>>> a phandle or an index to the clock.
>>>>>
>>>>> e.g. Documentation/devicetree/bindings/clock/imx31-clock.txt
>>>>
>>>> Yes I understand that. But the driver/clock/omap driver can just
>>>> remap the DT device initially so the board specific clock is
>>>> found from the clock alias table. Basically initially a passthrough
>>>> driver that can be enhanced to parse DT clock bindings and load
>>>> data from /lib/firmware.
>>>
>>> Actually probably the driver/clock/omap can even do even less
>>> initially. There probably even no need to remap clocks there.
>>>
>>> As long as the DT clock driver understands that a board specific
>>> auxclk is specified in the DT it can just call clk_add_alias() so
>>> the driver will get the right auxclk from cclock44xx_data.c.
>>>
>>> Then other features can be added later on like to allocate a
>>> clock entirely based on the binding etc.
>> I did try to have an implementation for cpufreq using clock nodes.
>> unfortunately, device tree wont let me have arguments of strings :(
>> So, I am unable to do clock = <&clk mpu_dpll>;
>> instead, I am forced to do clock = <&clk 249>;
>>
> 
> See http://article.gmane.org/gmane.linux.ports.arm.kernel/229034
> 

Awesome. Thanks for pointing this out Mike.

Now all we need to do is create a named define for each clock index in the
header file.

cheers,
-roger

> 
>> Here is an attempt on beagleXM - adds every clock node to the list.
>> Tons of un-necessary prints added to give an idea - see log:
>> http://pastebin.com/F9A2zSTr
>>
>> Would an cleaned up version be good enough as a step #1 of transition?
>>
>> From 7d373bdb9e9549c1b6ba1775a8dfd96ebe78abfb Mon Sep 17 00:00:00 2001
>> From: Nishanth Menon <nm at ti.com>
>> Date: Tue, 26 Mar 2013 10:23:27 +0000
>> Subject: [PATCH] OMAP: add devicetree support for clock nodes.
>>
>> Dummy patch based on Roger's original idea
>>
>> Nyet-Signed-off-by: Nishanth Menon <nm at ti.com>
>> ---
>>  arch/arm/boot/dts/omap3.dtsi          |    5 ++
>>  arch/arm/boot/dts/omap34xx.dtsi       |    2 +
>>  arch/arm/mach-omap2/cclock3xxx_data.c |    3 +-
>>  arch/arm/mach-omap2/cclock44xx_data.c |    3 +-
>>  arch/arm/mach-omap2/pm.c              |   11 +++-
>>  drivers/clk/Kconfig                   |    6 ++
>>  drivers/clk/Makefile                  |    2 +
>>  drivers/clk/ti.c                      |  100 +++++++++++++++++++++++++++++++++
>>  include/linux/clk/ti.h                |   30 ++++++++++
>>  9 files changed, 157 insertions(+), 5 deletions(-)
>>  create mode 100644 drivers/clk/ti.c
>>  create mode 100644 include/linux/clk/ti.h
>>
>> diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
>> index 3344f05..a08990d 100644
>> --- a/arch/arm/boot/dts/omap3.dtsi
>> +++ b/arch/arm/boot/dts/omap3.dtsi
>> @@ -73,6 +73,11 @@
>>                         ti,hwmods = "counter_32k";
>>                 };
>>  
>> +               clks: clocks {
>> +                       compatible = "ti,clock";
>> +                       #clock-cells = <1>;
>> +               };
>> +
>>                 intc: interrupt-controller at 48200000 {
>>                         compatible = "ti,omap2-intc";
>>                         interrupt-controller;
>> diff --git a/arch/arm/boot/dts/omap34xx.dtsi b/arch/arm/boot/dts/omap34xx.dtsi
>> index 75ed4ae..93c2621 100644
>> --- a/arch/arm/boot/dts/omap34xx.dtsi
>> +++ b/arch/arm/boot/dts/omap34xx.dtsi
>> @@ -23,6 +23,8 @@
>>                                 600000  1350000
>>                         >;
>>                         clock-latency = <300000>; /* From legacy driver */
>> +                       clocks = <&clks 249>; /* index to cpufreq_ck */
>> +                       clock-names = "cpu";
>>                 };
>>         };
>>  };
>> diff --git a/arch/arm/mach-omap2/cclock3xxx_data.c b/arch/arm/mach-omap2/cclock3xxx_data.c
>> index 4579c3c..d5d5ef5 100644
>> --- a/arch/arm/mach-omap2/cclock3xxx_data.c
>> +++ b/arch/arm/mach-omap2/cclock3xxx_data.c
>> @@ -22,6 +22,7 @@
>>  #include <linux/clk-private.h>
>>  #include <linux/list.h>
>>  #include <linux/io.h>
>> +#include <linux/clk/ti.h>
>>  
>>  #include "soc.h"
>>  #include "iomap.h"
>> @@ -3574,7 +3575,7 @@ int __init omap3xxx_clk_init(void)
>>         for (c = omap3xxx_clks; c < omap3xxx_clks + ARRAY_SIZE(omap3xxx_clks);
>>              c++)
>>                 if (c->cpu & cpu_clkflg) {
>> -                       clkdev_add(&c->lk);
>> +                       ti_clk_node_add(&c->lk);
>>                         if (!__clk_init(NULL, c->lk.clk))
>>                                 omap2_init_clk_hw_omap_clocks(c->lk.clk);
>>                 }
>> diff --git a/arch/arm/mach-omap2/cclock44xx_data.c b/arch/arm/mach-omap2/cclock44xx_data.c
>> index 0c6834a..338ef64 100644
>> --- a/arch/arm/mach-omap2/cclock44xx_data.c
>> +++ b/arch/arm/mach-omap2/cclock44xx_data.c
>> @@ -27,6 +27,7 @@
>>  #include <linux/clk-private.h>
>>  #include <linux/clkdev.h>
>>  #include <linux/io.h>
>> +#include <linux/clk/ti.h>
>>  
>>  #include "soc.h"
>>  #include "iomap.h"
>> @@ -1697,7 +1698,7 @@ int __init omap4xxx_clk_init(void)
>>         for (c = omap44xx_clks; c < omap44xx_clks + ARRAY_SIZE(omap44xx_clks);
>>                                                                         c++) {
>>                 if (c->cpu & cpu_clkflg) {
>> -                       clkdev_add(&c->lk);
>> +                       ti_clk_node_add(&c->lk);
>>                         if (!__clk_init(NULL, c->lk.clk))
>>                                 omap2_init_clk_hw_omap_clocks(c->lk.clk);
>>                 }
>> diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
>> index 8d15f9a..6cf95160 100644
>> --- a/arch/arm/mach-omap2/pm.c
>> +++ b/arch/arm/mach-omap2/pm.c
>> @@ -267,7 +267,12 @@ static void __init omap4_init_voltages(void)
>>  
>>  static inline void omap_init_cpufreq(void)
>>  {
>> -       struct platform_device_info devinfo = { .name = "omap-cpufreq", };
>> +       struct platform_device_info devinfo = { };
>> +
>> +       if (!of_have_populated_dt())
>> +               devinfo.name = "omap-cpufreq";
>> +       else
>> +               devinfo.name = "cpufreq-cpu0";
>>         platform_device_register_full(&devinfo);
>>  }
>>  
>> @@ -301,9 +306,9 @@ int __init omap2_common_pm_late_init(void)
>>                 /* Smartreflex device init */
>>                 omap_devinit_smartreflex();
>>  
>> -               /* cpufreq dummy device instantiation */
>> -               omap_init_cpufreq();
>>         }
>> +       /* cpufreq dummy device instantiation */
>> +       omap_init_cpufreq();
>>  
>>  #ifdef CONFIG_SUSPEND
>>         suspend_set_ops(&omap_pm_ops);
>> diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
>> index a47e6ee..03c6e48 100644
>> --- a/drivers/clk/Kconfig
>> +++ b/drivers/clk/Kconfig
>> @@ -55,6 +55,12 @@ config COMMON_CLK_MAX77686
>>         ---help---
>>           This driver supports Maxim 77686 crystal oscillator clock. 
>>  
>> +config COMMON_CLK_TI
>> +       tristate "Clock driver for TI SoCs"
>> +       depends on ARCH_OMAP && OF
>> +       ---help---
>> +         Fill me up.. some generic statement ofcourse (lets start with OMAP)
>> +
>>  config CLK_TWL6040
>>         tristate "External McPDM functional clock from twl6040"
>>         depends on TWL6040_CORE
>> diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
>> index 300d477..9621815 100644
>> --- a/drivers/clk/Makefile
>> +++ b/drivers/clk/Makefile
>> @@ -30,6 +30,8 @@ obj-$(CONFIG_ARCH_TEGRA)      += tegra/
>>  
>>  obj-$(CONFIG_X86)              += x86/
>>  
>> +obj-$(CONFIG_COMMON_CLK_TI)    += ti.o
>> +
>>  # Chip specific
>>  obj-$(CONFIG_COMMON_CLK_WM831X) += clk-wm831x.o
>>  obj-$(CONFIG_COMMON_CLK_MAX77686) += clk-max77686.o
>> diff --git a/drivers/clk/ti.c b/drivers/clk/ti.c
>> new file mode 100644
>> index 0000000..c747381
>> --- /dev/null
>> +++ b/drivers/clk/ti.c
>> @@ -0,0 +1,100 @@
>> +/*
>> + * TI Clock node provider
>> + *
>> + * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
>> + *     Nishanth Menon
>> + *
>> + * 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.
>> + *
>> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
>> + * kind, whether express or implied; without even the implied warranty
>> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + */
>> +#include <linux/kernel.h>
>> +#include <linux/list.h>
>> +#include <linux/clk-private.h>
>> +#include <linux/clkdev.h>
>> +#include <linux/io.h>
>> +#include <linux/of.h>
>> +#include <linux/clk/ti.h>
>> +
>> +struct ti_clk {
>> +       struct clk_lookup *lk;
>> +       struct list_head node;
>> +};
>> +
>> +static LIST_HEAD(ti_clk_list);
>> +
>> +static struct clk *ti_bypass_clk_get_by_name(struct of_phandle_args *clkspec,
>> +                                            void *data)
>> +{
>> +       struct ti_clk *c;
>> +#if 0
>> +       /* Eww.. IF ONLY phandle arguments could be string */
>> +       char clk_name[32]; /* 32 is max size of property name */
>> +
>> +       char *name = clkspec->args[0];
>> +
>> +       snprintf(clk_name, 32, "%s_ck", name);
>> +       list_for_each_entry(c, &ti_clk_list, node) {
>> +               int r = strncmp(c->lk->conn_id, clk_name, 32);
>> +               pr_err("%s: searching %s in %s - %d\n",
>> +                       __func__, clk_name, c->lk->con_id, r);
>> +               if (!r) {
>> +                       pr_err("%s: found it!\n", __func__);
>> +                       return c->lk.clk;
>> +               }
>> +       }
>> +#else
>> +       /* Use integer indexing into clkdev list! Sigh.. */
>> +       int idx = clkspec->args[0];
>> +       int cindex = 1;
>> +
>> +       list_for_each_entry(c, &ti_clk_list, node) {
>> +               int r = (idx == cindex) ? 0 :  1;
>> +               pr_err("%s: searching index search = %d in %d in %s - %d\n",
>> +                       __func__, idx, cindex, c->lk->con_id, r);
>> +               if (!r) {
>> +                       pr_err("%s: found it!\n", __func__);
>> +                       return c->lk->clk;
>> +               }
>> +               cindex++;
>> +       }
>> +#endif
>> +
>> +       pr_err("%s: ran out of options\n", __func__);
>> +       return ERR_PTR(-ENODEV);
>> +}
>> +
>> +static void __init ti_clock_init(struct device_node *node)
>> +{
>> +
>> +       pr_err("%s: START\n", __func__);
>> +       of_clk_add_provider(node, ti_bypass_clk_get_by_name, NULL);
>> +       pr_err("%s: END\n", __func__);
>> +}
>> +CLK_OF_DECLARE(ti_clk, "ti,clock", ti_clock_init);
>> +
>> +void __init ti_clk_node_add(struct clk_lookup *lk)
>> +{
>> +       struct ti_clk *c;
>> +       static bool of_added;
>> +
>> +       c = kzalloc(sizeof(struct ti_clk), GFP_KERNEL);
>> +       if (!c) {
>> +               pr_err("%s: No memory!! cannot add clk node!\n", __func__);
>> +               return;
>> +       }
>> +       clkdev_add(lk);
>> +       c->lk = lk;
>> +       list_add_tail(&c->node, &ti_clk_list);
>> +       pr_err("%s: Added clock node %s\n", __func__, lk->con_id);
>> +       if (!of_added) {
>> +               of_clk_init(NULL);
>> +               of_added =  true;
>> +       }
>> +};
>> +
>> diff --git a/include/linux/clk/ti.h b/include/linux/clk/ti.h
>> new file mode 100644
>> index 0000000..eb502a8
>> --- /dev/null
>> +++ b/include/linux/clk/ti.h
>> @@ -0,0 +1,30 @@
>> +/*
>> + * TI Clock node provider header
>> + *
>> + * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
>> + *     Nishanth Menon
>> + *
>> + * 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.
>> + *
>> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
>> + * kind, whether express or implied; without even the implied warranty
>> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + */
>> +#ifndef __TI_CLK_H
>> +#define __TI_CLK_H
>> +
>> +#include <linux/clkdev.h>
>> +
>> +#ifdef CONFIG_OF
>> +extern void ti_clk_node_add(struct clk_lookup *lk);
>> +#else
>> +static inline void ti_clk_node_add(struct clk_lookup *lk)
>> +{
>> +       clkdev_add(lk);
>> +}
>> +#endif /* CONFIG_OF */
>> +
>> +#endif /* __TI_CLK_H */
>> -- 
>> 1.7.9.5
>>
>>
>> -- 
>> Regards,
>> Nishanth Menon
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html



From kgene.kim at samsung.com  Wed Apr 10 06:59:17 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Wed, 10 Apr 2013 19:59:17 +0900
Subject: [PATCH v5 2/3] ARM: dts: Add i2c-arbitrator bus for
 exynos5250-snow
In-Reply-To: <1365543270-10736-2-git-send-email-dianders@chromium.org>
References: <1363192583-26363-1-git-send-email-dianders@chromium.org>
 <1365543270-10736-1-git-send-email-dianders@chromium.org>
 <1365543270-10736-2-git-send-email-dianders@chromium.org>
Message-ID: <310301ce35da$724dff60$56e9fe20$%kim@samsung.com>

Doug Anderson wrote:
> 
> We need to use the i2c-arbitrator to talk to any of the devices on i2c
> bus 4 on exynos5250-snow so that we don't confuse the embedded
> controller (EC).  Add the i2c-arbitrator to the device tree.  As we
> add future devices (keyboard, sbs, tps65090) we'll add them on top of
> this.
> 
> The arbitrated bus is numbered 104 simply as a convenience to make it
> easier for people poking around to guess that it might have something
> to do with the physical bus 4.
> 
> The addition is split between the cros5250-common and the snow device
> tree file since not all cros5250-class devices use arbitration.
> 
> Signed-off-by: Doug Anderson <dianders at chromium.org>

I'm fine on 2nd and 3rd patches. Shall I take only two patches without 1st
one in samsung tree?

- Kukjin

> ---
> Changes in v5:
> - Adjust bindings as per Wolfram Sang.
> 
> Changes in v4:
> - Changed mux gpio syntax to work atop Thomas's "ARM: dts: add pin
>   state information in client nodes for Exynos5 platforms"; avoid
>   adding gpios property to i2c at 12CA0000 for the same reason.
> 
> Changes in v3: None
> Changes in v2:
> - Use new device tree property names / compatible string.
> - Include that the GPIOs for arbitration are active low.
> 
>  arch/arm/boot/dts/cros5250-common.dtsi |  3 ++-
>  arch/arm/boot/dts/exynos5250-snow.dts  | 25 +++++++++++++++++++++++++
>  2 files changed, 27 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/cros5250-common.dtsi
> b/arch/arm/boot/dts/cros5250-common.dtsi
> index 8a5b3a6..0a61bbb 100644
> --- a/arch/arm/boot/dts/cros5250-common.dtsi
> +++ b/arch/arm/boot/dts/cros5250-common.dtsi
> @@ -193,7 +193,8 @@
>  	};
> 
>  	i2c at 12CA0000 {
> -		status = "disabled";
> +		samsung,i2c-sda-delay = <100>;
> +		samsung,i2c-max-bus-freq = <66000>;
>  	};
> 
>  	i2c at 12CB0000 {
> diff --git a/arch/arm/boot/dts/exynos5250-snow.dts
> b/arch/arm/boot/dts/exynos5250-snow.dts
> index 581ffae..fa85f58 100644
> --- a/arch/arm/boot/dts/exynos5250-snow.dts
> +++ b/arch/arm/boot/dts/exynos5250-snow.dts
> @@ -16,6 +16,10 @@
>  	model = "Google Snow";
>  	compatible = "google,snow", "samsung,exynos5250";
> 
> +	aliases {
> +		i2c104 = &i2c_104;
> +	};
> +
>  	pinctrl at 11400000 {
>  		sd3_clk: sd3-clk {
>  			samsung,pin-drv = <0>;
> @@ -44,6 +48,27 @@
>  		};
>  	};
> 
> +	i2c-arbitrator {
> +		compatible = "i2c-arb-gpio-challenge";
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
> +		i2c-parent = <&{/i2c at 12CA0000}>;
> +
> +		our-claim-gpio = <&gpf0 3 1>;
> +		their-claim-gpios = <&gpe0 4 1>;
> +		slew-delay-us = <10>;
> +		wait-retry-us = <3000>;
> +		wait-free-us = <50000>;
> +
> +		/* Use ID 104 as a hint that we're on physical bus 4 */
> +		i2c_104: i2c at 0 {
> +			reg = <0>;
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +		};
> +	};
> +
>  	/*
>  	 * On Snow we've got SIP WiFi and so can keep drive strengths low
> to
>  	 * reduce EMI.
> --
> 1.8.1.3



From wsa at the-dreams.de  Wed Apr 10 07:02:27 2013
From: wsa at the-dreams.de (Wolfram Sang)
Date: Wed, 10 Apr 2013 13:02:27 +0200
Subject: [PATCH v5 2/3] ARM: dts: Add i2c-arbitrator bus for
 exynos5250-snow
In-Reply-To: <310301ce35da$724dff60$56e9fe20$%kim@samsung.com>
References: <1363192583-26363-1-git-send-email-dianders@chromium.org>
 <1365543270-10736-1-git-send-email-dianders@chromium.org>
 <1365543270-10736-2-git-send-email-dianders@chromium.org>
 <310301ce35da$724dff60$56e9fe20$%kim@samsung.com>
Message-ID: <20130410110226.GA3533@the-dreams.de>

On Wed, Apr 10, 2013 at 07:59:17PM +0900, Kukjin Kim wrote:
> Doug Anderson wrote:
> > 
> > We need to use the i2c-arbitrator to talk to any of the devices on i2c
> > bus 4 on exynos5250-snow so that we don't confuse the embedded
> > controller (EC).  Add the i2c-arbitrator to the device tree.  As we
> > add future devices (keyboard, sbs, tps65090) we'll add them on top of
> > this.
> > 
> > The arbitrated bus is numbered 104 simply as a convenience to make it
> > easier for people poking around to guess that it might have something
> > to do with the physical bus 4.
> > 
> > The addition is split between the cros5250-common and the snow device
> > tree file since not all cros5250-class devices use arbitration.
> > 
> > Signed-off-by: Doug Anderson <dianders at chromium.org>
> 
> I'm fine on 2nd and 3rd patches. Shall I take only two patches without 1st
> one in samsung tree?

Please wait for my OK on patch 1. Or ack patches 2 and 3 and I will pick
them up. I am fine with both.



From mpa at pengutronix.de  Wed Apr 10 07:03:17 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Wed, 10 Apr 2013 13:03:17 +0200
Subject: [PATCH v2 01/11] ASoC: phycore-ac97: Add DT support
In-Reply-To: <516230E1.3070509@tabi.org>
References: <1365362721-3731-1-git-send-email-mpa@pengutronix.de>
 <1365362721-3731-2-git-send-email-mpa@pengutronix.de>
 <516230E1.3070509@tabi.org>
Message-ID: <20130410110317.GA16749@pengutronix.de>

On Sun, Apr 07, 2013 at 09:52:17PM -0500, Timur Tabi wrote:
> Markus Pargmann wrote:
> >Notes:
> >    Changes in v2:
> >     - Simplify the driver, by combining audmux port configurations. The
> >       audmux driver actually knows on which platform he is running and
> >       will return the appropriate error code if we use functions for
> >       another platform. So we don't need to have the knowledge about it
> >       in phycore-ac97 and can try both functions. This removes the need
> >       of different compatibilities and renames it to imx27-ac97.
> >     - Use a phandle for the cpu_dai link.
> >     - Add devicetree binding documentation.
> >     - Rename binding to phytec,phycore-ac97 and fsl,ssi to phytec,ssi
> 
> I think some of this information belongs in the changelog.

Okay

> 
> >+#ifdef CONFIG_MACH_IMX27_DT
> >+		.platform_name	= "imx-fiq-pcm-audio",
> >+#else
> >  		.cpu_dai_name	= "imx-ssi.0",
> >  		.platform_name	= "imx-fiq-pcm-audio.0",
> >+#endif
> 
> What's the difference between "imx-fiq-pcm-audio" and "imx-fiq-pcm-audio.0"?

The previous version of phycore-ac97 was using devices created by the
board init code. They passed a proper pdev id which was used in all
drivers they created. Since fsl-ssi is using DT, that id is -1 and is
ignored for the device name. So we have to remove the .0 for DT here.
This driver is not used multiple times in one system, so it shouldn't be
a problem.

Regards,

Markus

> 
> -- 
> Timur Tabi
> 

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From rogerq at ti.com  Wed Apr 10 07:04:33 2013
From: rogerq at ti.com (Roger Quadros)
Date: Wed, 10 Apr 2013 14:04:33 +0300
Subject: [RFC][PATCH 1/2] ARM: OMAP4: clock: Add device tree support for
 AUXCLKs
In-Reply-To: <20130409215419.GA13731@kahuna>
References: <1363703220-4777-2-git-send-email-rogerq@ti.com>
 <20130403234242.GE10155@atomide.com> <515D2D30.3000306@ti.com>
 <20130404164137.GH10155@atomide.com> <515EA9E3.1010409@ti.com>
 <20130405155851.GA10155@atomide.com> <5163E589.1040809@ti.com>
 <20130409164928.GL10155@atomide.com> <20130409174319.GP10155@atomide.com>
 <20130409204900.GA8815@kahuna> <20130409215419.GA13731@kahuna>
Message-ID: <51654741.30206@ti.com>

On 04/10/2013 12:54 AM, Nishanth Menon wrote:
> On 15:49-20130409, Nishanth Menon wrote:
>> On 10:43-20130409, Tony Lindgren wrote:
>>> * Tony Lindgren <tony at atomide.com> [130409 09:54]:
>>>> * Roger Quadros <rogerq at ti.com> [130409 03:00]:
>>>>> On 04/05/2013 06:58 PM, Tony Lindgren wrote:
>>>>>>
>>>>>> Can't you just use the clock name there to get it?
>>>>>
>>>>> In device tree we don't pass around clock names. You can either get
>>>>> a phandle or an index to the clock.
>>>>>
>>>>> e.g. Documentation/devicetree/bindings/clock/imx31-clock.txt
>>>>
>>>> Yes I understand that. But the driver/clock/omap driver can just
>>>> remap the DT device initially so the board specific clock is
>>>> found from the clock alias table. Basically initially a passthrough
>>>> driver that can be enhanced to parse DT clock bindings and load
>>>> data from /lib/firmware.
>>>
>>> Actually probably the driver/clock/omap can even do even less
>>> initially. There probably even no need to remap clocks there.
>>>
>>> As long as the DT clock driver understands that a board specific
>>> auxclk is specified in the DT it can just call clk_add_alias() so
>>> the driver will get the right auxclk from cclock44xx_data.c.
>>>
>>> Then other features can be added later on like to allocate a
>>> clock entirely based on the binding etc.
>> I did try to have an implementation for cpufreq using clock nodes.
>> unfortunately, device tree wont let me have arguments of strings :(
>> So, I am unable to do clock = <&clk mpu_dpll>;
>> instead, I am forced to do clock = <&clk 249>;
>>
>> Here is an attempt on beagleXM - adds every clock node to the list.
>> Tons of un-necessary prints added to give an idea - see log:
>> http://pastebin.com/F9A2zSTr
>>
>> Would an cleaned up version be good enough as a step #1 of transition?
>>
> Approach #2:
> Here is yet another revision -> here I am trying to avoid the risk of
> folks messing up indexing. for example: using an older DTB with newer
> kernel, clocks being inserted into existing list etc. to prevent these,

Why do you need to worry about users using old DTB with new kernel.
That is entirely the user's fault no?

> we add an "DT_ID" for omap clock nodes, and use it to uniquely identify
> the clock node. We try to minimize(not avoidable with integer indexing)
> mistakes during development/productization.

cheers,
-roger


From dave.martin at linaro.org  Wed Apr 10 07:10:12 2013
From: dave.martin at linaro.org (Dave Martin)
Date: Wed, 10 Apr 2013 12:10:12 +0100
Subject: Anyone implement Cortex A9 FIQ
In-Reply-To: <CAHrpEqR35v76qif0wP=1SNOThLvmzpmEHcbehSNoY7-CO0CRqQ@mail.gmail.com>
References: <CAHrpEqSQ1n_WUfxoraKZFS2A8NjdP_MCcWmJdCjcon_QwgX4Hw@mail.gmail.com>
 <5142FBF5.3010307@arm.com>
 <CAHrpEqSO89Lx=EGTJJ_XOFwkHqL=heoOUQCtJUzm6D7mEAbWiw@mail.gmail.com>
 <514764E2.6040101@arm.com>
 <CAHrpEqT9SSbHYK62i0ZteEd4SfZaa_nw+T0SHunP2W+MUEqmrg@mail.gmail.com>
 <20130408162844.GB2176@linaro.org>
 <CAHrpEqR35v76qif0wP=1SNOThLvmzpmEHcbehSNoY7-CO0CRqQ@mail.gmail.com>
Message-ID: <20130410111012.GA2235@linaro.org>

On Wed, Apr 10, 2013 at 01:45:05PM +0800, Frank Li wrote:
> We already implement FIQ in our platform.
> We want to use it simulate a hardware behavior.  

OK.  If FIQ is available to you, then it should be possible to use it,
but you should avoid relying on it in production code if possible.

There is not much code in the kernel using FIQ today.  You could take
a look at soemthing like drivers/spi/spi-s3c24xx.c, for an example
of how to set up an FIQ handler.

How to route an actual hardware interrupt to FIQ is a separate question.
Depending on what is in your hardware, this may require some interrupt
controller configuration in the GIC and/or elsewhere.

I don't think the GIC support in the kernel has any support for doing
this, but I could be wrong.

Cheers
---Dave

> 
> 
> 2013/4/9 Dave Martin <dave.martin at linaro.org>
> 
>     On Tue, Mar 19, 2013 at 03:49:50PM +0800, Frank Li wrote:
>     > >
>     > > Whether this is feasible will really depend on what platform you're on
>     - if
>     > > there's a secure monitor then FIQs are out of the question anyway. Can
>     you
>     > > tell us more about the system?
>     >
>     > Freescale MX6Q.
>     >
>     > >
>     > > If your average interrupt latency is low then you should just be able
>     to do
>     > > this with normal IRQs (have you got threaded interrupt handlers?)
>     >
>     > Not all drivers use threaded interrupt handler.
>     >
>     > >
>     > > What is it about the situation that leads you to believe that you
>     *need*
>     > > FIQ?
>     >
>     > FIQ can be executed even in spin_lock_saveirq.
>     > We want do very small hardware set at related precision period (every
>     125us).
> 
>     Why is the latency requirement so tight for this one interrupt?
> 
>     Cheers
>     ---Dave
> 
> 


From will.deacon at arm.com  Wed Apr 10 07:11:48 2013
From: will.deacon at arm.com (Will Deacon)
Date: Wed, 10 Apr 2013 12:11:48 +0100
Subject: [PATCH] ARM: hw_breakpoint: Do not use __cpuinitdata for
 dbg_cpu_pm_nb
In-Reply-To: <1365588278-5185-1-git-send-email-hechtb+renesas@gmail.com>
References: <1365588278-5185-1-git-send-email-hechtb+renesas@gmail.com>
Message-ID: <20130410111148.GA26992@mudshark.cambridge.arm.com>

On Wed, Apr 10, 2013 at 11:04:38AM +0100, Bastian Hecht wrote:
> We must not declare dbg_cpu_pm_nb as __cpuinitdata as we need it after
> system initialization for Suspend and CPUIdle.
> 
> This was done in commit 9a6eb310eaa5336b89a27a0bbb78da4bba35f6f1
> ARM: hw_breakpoint: Debug powerdown support for self-hosted debug
> 
> Signed-off-by: Bastian Hecht <hechtb+renesas at gmail.com>

Thanks Bastian, I'll take this into my tree.

Will


From hvaibhav at ti.com  Wed Apr 10 07:15:15 2013
From: hvaibhav at ti.com (Hiremath, Vaibhav)
Date: Wed, 10 Apr 2013 11:15:15 +0000
Subject: [GIT PULL] ARM: OMAP5: hwmod, prm/cm data files and updates for
 3.10
In-Reply-To: <515F00B8.3000501@ti.com>
References: <1363768852-18125-1-git-send-email-santosh.shilimkar@ti.com>
 <20130401170539.GK10155@atomide.com> <515BA76D.3000302@ti.com>
 <alpine.DEB.2.00.1304031146230.2616@utopia.booyaka.com>
 <515D6020.2030103@ti.com> <20130404165208.GI10155@atomide.com>
 <515DB110.9000503@ti.com> <515F00B8.3000501@ti.com>
Message-ID: <79CD15C6BA57404B839C016229A409A83EC4A81D@DBDE01.ent.ti.com>

> -----Original Message-----
> From: Shilimkar, Santosh
> Sent: Friday, April 05, 2013 10:20 PM
> To: Tony Lindgren
> Cc: Paul Walmsley; linux-omap at vger.kernel.org; linux-arm-
> kernel at lists.infradead.org; Kristo, Tero; Menon, Nishanth; Nayak,
> Rajendra; Valentin, Eduardo; Anna, Suman; Bedia, Vaibhav; Hiremath,
> Vaibhav
> Subject: Re: [GIT PULL] ARM: OMAP5: hwmod, prm/cm data files and
> updates for 3.10
> 
> On Thursday 04 April 2013 10:27 PM, Santosh Shilimkar wrote:
> > On Thursday 04 April 2013 10:22 PM, Tony Lindgren wrote:
> >> * Santosh Shilimkar <santosh.shilimkar at ti.com> [130404 04:15]:
> [..]
> 
> >> Can't we already trim the am33xx hwmod data after your patches for
> >> v3.10 as am33xx is already DT only? Unfortunately we cannot create
> >> negative diffstat in other ways for v3.10 merge window as we cannot
> >> make omap4 DT only just quite yet.
> >>
> > Yes we can and I can take a stab it tomorrow. The only thing is I
> > might need some support for testing but thats manageable. Will
> > take a stab at it tomorrow and if everything goes well, post a
> > patch for smae.
> >
> Patch for the AM33XX to trim is end of the email. Thanks to
> Sricharan and Pekon for patch and testing. Looping both
> Vaibhav's if they have any objection on the patch.
> 
> Regards,
> Santosh
> 
> From b95dd33fe59b8e77727eb3b1717d763bbf9a2893 Mon Sep 17 00:00:00 2001
> From: Sricharan R <r.sricharan at ti.com>
> Date: Fri, 5 Apr 2013 20:39:12 +0530
> Subject: [PATCH] ARM: AM33XX: hwmod data: Clean up the data file
> 
> - The IO resource information like dma request lines, irq number and
> ocp address space can be populated via dt blob. So such data can be
> stripped
> from SOC hwmod data file.
> 
> - The devices like adc, mailbox, gpmc which are missing the device
> tree bindings, hwmod data is not added since AM33XX is DT only build.
> When such devices add the dt bindings, respective hwmod data can be
> added along with it.
> 
This seems unnecessary churn to me. DT bindings for most of the devices 
which you mentioned above are submitted and are at various stages of review
process.

ADC:

GPMC:

PWM:


> - The hwmod like firewall etc which are not useful are also dropped.
> 
> This gets us around ~2000 loc of negative diff. Patch is boot tested on
> AM335X EVM.
> 
I would not recommend to get into unnecessary code churn in the future just 
to reduce temp Number of Lines of code. This will also kill our autogeneration 
concept as well.

I would suggest you to just alone drop base-addr, irq and dma references
from hwmod entries.

Thanks,
Vaibhav

> Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
> Signed-off-by: Sricharan R <r.sricharan at ti.com>
> ---
> Patch has to be based of the dt branch and recent cleanups which are
> already in 3.10 queue. The patch also can be found on my git tree.
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux.git
> for_3.10/am33xx_hwmod_cleanup
> 
>  arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 1993 +-------------------
> --------
>  1 file changed, 13 insertions(+), 1980 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
> b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
> index 31bea1c..19a35e8 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
> @@ -35,63 +35,6 @@
>   */
> 
>  /*
> - * 'emif_fw' class
> - * instance(s): emif_fw
> - */
> -static struct omap_hwmod_class am33xx_emif_fw_hwmod_class = {
> -	.name		= "emif_fw",
> -};
> -
> -/* emif_fw */
> -static struct omap_hwmod am33xx_emif_fw_hwmod = {
> -	.name		= "emif_fw",
> -	.class		= &am33xx_emif_fw_hwmod_class,
> -	.clkdm_name	= "l4fw_clkdm",
> -	.main_clk	= "l4fw_gclk",
> -	.flags		= (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET),
> -	.prcm		= {
> -		.omap4	= {
> -			.clkctrl_offs	=
> AM33XX_CM_PER_EMIF_FW_CLKCTRL_OFFSET,
> -			.modulemode	= MODULEMODE_SWCTRL,
> -		},
> -	},
> -};
> -
> -/*
> - * 'emif' class
> - * instance(s): emif
> - */
> -static struct omap_hwmod_class_sysconfig am33xx_emif_sysc = {
> -	.rev_offs	= 0x0000,
> -};
> -
> -static struct omap_hwmod_class am33xx_emif_hwmod_class = {
> -	.name		= "emif",
> -	.sysc		= &am33xx_emif_sysc,
> -};
> -
> -static struct omap_hwmod_irq_info am33xx_emif_irqs[] = {
> -	{ .name = "ddrerr0", .irq = 101 + OMAP_INTC_START, },
> -	{ .irq = -1 },
> -};
> -
> -/* emif */
> -static struct omap_hwmod am33xx_emif_hwmod = {
> -	.name		= "emif",
> -	.class		= &am33xx_emif_hwmod_class,
> -	.clkdm_name	= "l3_clkdm",
> -	.flags		= (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET),
> -	.mpu_irqs	= am33xx_emif_irqs,
> -	.main_clk	= "dpll_ddr_m2_div2_ck",
> -	.prcm		= {
> -		.omap4	= {
> -			.clkctrl_offs	=
> AM33XX_CM_PER_EMIF_CLKCTRL_OFFSET,
> -			.modulemode	= MODULEMODE_SWCTRL,
> -		},
> -	},
> -};
> -
> -/*
>   * 'l3' class
>   * instance(s): l3_main, l3_s, l3_instr
>   */
> @@ -99,19 +42,11 @@ static struct omap_hwmod_class
> am33xx_l3_hwmod_class = {
>  	.name		= "l3",
>  };
> 
> -/* l3_main (l3_fast) */
> -static struct omap_hwmod_irq_info am33xx_l3_main_irqs[] = {
> -	{ .name = "l3debug", .irq = 9 + OMAP_INTC_START, },
> -	{ .name = "l3appint", .irq = 10 + OMAP_INTC_START, },
> -	{ .irq = -1 },
> -};
> -
>  static struct omap_hwmod am33xx_l3_main_hwmod = {
>  	.name		= "l3_main",
>  	.class		= &am33xx_l3_hwmod_class,
>  	.clkdm_name	= "l3_clkdm",
>  	.flags		= (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET),
> -	.mpu_irqs	= am33xx_l3_main_irqs,
>  	.main_clk	= "l3_gclk",
>  	.prcm		= {
>  		.omap4	= {
> @@ -196,20 +131,6 @@ static struct omap_hwmod am33xx_l4_wkup_hwmod = {
>  	},
>  };
> 
> -/* l4_fw */
> -static struct omap_hwmod am33xx_l4_fw_hwmod = {
> -	.name		= "l4_fw",
> -	.class		= &am33xx_l4_hwmod_class,
> -	.clkdm_name	= "l4fw_clkdm",
> -	.flags		= (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET),
> -	.prcm		= {
> -		.omap4	= {
> -			.clkctrl_offs	=
> AM33XX_CM_PER_L4FW_CLKCTRL_OFFSET,
> -			.modulemode	= MODULEMODE_SWCTRL,
> -		},
> -	},
> -};
> -
>  /*
>   * 'mpu' class
>   */
> @@ -217,21 +138,11 @@ static struct omap_hwmod_class
> am33xx_mpu_hwmod_class = {
>  	.name	= "mpu",
>  };
> 
> -/* mpu */
> -static struct omap_hwmod_irq_info am33xx_mpu_irqs[] = {
> -	{ .name = "emuint", .irq = 0 + OMAP_INTC_START, },
> -	{ .name = "commtx", .irq = 1 + OMAP_INTC_START, },
> -	{ .name = "commrx", .irq = 2 + OMAP_INTC_START, },
> -	{ .name = "bench", .irq = 3 + OMAP_INTC_START, },
> -	{ .irq = -1 },
> -};
> -
>  static struct omap_hwmod am33xx_mpu_hwmod = {
>  	.name		= "mpu",
>  	.class		= &am33xx_mpu_hwmod_class,
>  	.clkdm_name	= "mpu_clkdm",
>  	.flags		= (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET),
> -	.mpu_irqs	= am33xx_mpu_irqs,
>  	.main_clk	= "dpll_mpu_m2_ck",
>  	.prcm		= {
>  		.omap4	= {
> @@ -253,11 +164,6 @@ static struct omap_hwmod_rst_info
> am33xx_wkup_m3_resets[] = {
>  	{ .name = "wkup_m3", .rst_shift = 3, .st_shift = 5 },
>  };
> 
> -static struct omap_hwmod_irq_info am33xx_wkup_m3_irqs[] = {
> -	{ .name = "txev", .irq = 78 + OMAP_INTC_START, },
> -	{ .irq = -1 },
> -};
> -
>  /* wkup_m3  */
>  static struct omap_hwmod am33xx_wkup_m3_hwmod = {
>  	.name		= "wkup_m3",
> @@ -265,7 +171,6 @@ static struct omap_hwmod am33xx_wkup_m3_hwmod = {
>  	.clkdm_name	= "l4_wkup_aon_clkdm",
>  	/* Keep hardreset asserted */
>  	.flags		= HWMOD_INIT_NO_RESET | HWMOD_NO_IDLEST,
> -	.mpu_irqs	= am33xx_wkup_m3_irqs,
>  	.main_clk	= "dpll_core_m4_div2_ck",
>  	.prcm		= {
>  		.omap4	= {
> @@ -291,25 +196,12 @@ static struct omap_hwmod_rst_info
> am33xx_pruss_resets[] = {
>  	{ .name = "pruss", .rst_shift = 1 },
>  };
> 
> -static struct omap_hwmod_irq_info am33xx_pruss_irqs[] = {
> -	{ .name = "evtout0", .irq = 20 + OMAP_INTC_START, },
> -	{ .name = "evtout1", .irq = 21 + OMAP_INTC_START, },
> -	{ .name = "evtout2", .irq = 22 + OMAP_INTC_START, },
> -	{ .name = "evtout3", .irq = 23 + OMAP_INTC_START, },
> -	{ .name = "evtout4", .irq = 24 + OMAP_INTC_START, },
> -	{ .name = "evtout5", .irq = 25 + OMAP_INTC_START, },
> -	{ .name = "evtout6", .irq = 26 + OMAP_INTC_START, },
> -	{ .name = "evtout7", .irq = 27 + OMAP_INTC_START, },
> -	{ .irq = -1 },
> -};
> -
>  /* pru-icss */
>  /* Pseudo hwmod for reset control purpose only */
>  static struct omap_hwmod am33xx_pruss_hwmod = {
>  	.name		= "pruss",
>  	.class		= &am33xx_pruss_hwmod_class,
>  	.clkdm_name	= "pruss_ocp_clkdm",
> -	.mpu_irqs	= am33xx_pruss_irqs,
>  	.main_clk	= "pruss_ocp_gclk",
>  	.prcm		= {
>  		.omap4	= {
> @@ -332,16 +224,10 @@ static struct omap_hwmod_rst_info
> am33xx_gfx_resets[] = {
>  	{ .name = "gfx", .rst_shift = 0 },
>  };
> 
> -static struct omap_hwmod_irq_info am33xx_gfx_irqs[] = {
> -	{ .name = "gfxint", .irq = 37 + OMAP_INTC_START, },
> -	{ .irq = -1 },
> -};
> -
>  static struct omap_hwmod am33xx_gfx_hwmod = {
>  	.name		= "gfx",
>  	.class		= &am33xx_gfx_hwmod_class,
>  	.clkdm_name	= "gfx_l3_clkdm",
> -	.mpu_irqs	= am33xx_gfx_irqs,
>  	.main_clk	= "gfx_fck_div_ck",
>  	.prcm		= {
>  		.omap4	= {
> @@ -370,43 +256,6 @@ static struct omap_hwmod am33xx_prcm_hwmod = {
>  };
> 
>  /*
> - * 'adc/tsc' class
> - * TouchScreen Controller (Anolog-To-Digital Converter)
> - */
> -static struct omap_hwmod_class_sysconfig am33xx_adc_tsc_sysc = {
> -	.rev_offs	= 0x00,
> -	.sysc_offs	= 0x10,
> -	.sysc_flags	= SYSC_HAS_SIDLEMODE,
> -	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
> -			SIDLE_SMART_WKUP),
> -	.sysc_fields	= &omap_hwmod_sysc_type2,
> -};
> -
> -static struct omap_hwmod_class am33xx_adc_tsc_hwmod_class = {
> -	.name		= "adc_tsc",
> -	.sysc		= &am33xx_adc_tsc_sysc,
> -};
> -
> -static struct omap_hwmod_irq_info am33xx_adc_tsc_irqs[] = {
> -	{ .irq = 16 + OMAP_INTC_START, },
> -	{ .irq = -1 },
> -};
> -
> -static struct omap_hwmod am33xx_adc_tsc_hwmod = {
> -	.name		= "adc_tsc",
> -	.class		= &am33xx_adc_tsc_hwmod_class,
> -	.clkdm_name	= "l4_wkup_clkdm",
> -	.mpu_irqs	= am33xx_adc_tsc_irqs,
> -	.main_clk	= "adc_tsc_fck",
> -	.prcm		= {
> -		.omap4	= {
> -			.clkctrl_offs	=
> AM33XX_CM_WKUP_ADC_TSC_CLKCTRL_OFFSET,
> -			.modulemode	= MODULEMODE_SWCTRL,
> -		},
> -	},
> -};
> -
> -/*
>   * Modules omap_hwmod structures
>   *
>   * The following IPs are excluded for the moment because:
> @@ -508,16 +357,10 @@ static struct omap_hwmod_class
> am33xx_aes_hwmod_class = {
>  	.name		= "aes",
>  };
> 
> -static struct omap_hwmod_irq_info am33xx_aes0_irqs[] = {
> -	{ .irq = 102 + OMAP_INTC_START, },
> -	{ .irq = -1 },
> -};
> -
>  static struct omap_hwmod am33xx_aes0_hwmod = {
>  	.name		= "aes0",
>  	.class		= &am33xx_aes_hwmod_class,
>  	.clkdm_name	= "l3_clkdm",
> -	.mpu_irqs	= am33xx_aes0_irqs,
>  	.main_clk	= "l3_gclk",
>  	.prcm		= {
>  		.omap4	= {
> @@ -532,16 +375,10 @@ static struct omap_hwmod_class
> am33xx_sha0_hwmod_class = {
>  	.name		= "sha0",
>  };
> 
> -static struct omap_hwmod_irq_info am33xx_sha0_irqs[] = {
> -	{ .irq = 108 + OMAP_INTC_START, },
> -	{ .irq = -1 },
> -};
> -
>  static struct omap_hwmod am33xx_sha0_hwmod = {
>  	.name		= "sha0",
>  	.class		= &am33xx_sha0_hwmod_class,
>  	.clkdm_name	= "l3_clkdm",
> -	.mpu_irqs	= am33xx_sha0_irqs,
>  	.main_clk	= "l3_gclk",
>  	.prcm		= {
>  		.omap4	= {
> @@ -577,17 +414,10 @@ static struct omap_hwmod_class
> am33xx_smartreflex_hwmod_class = {
>  	.name		= "smartreflex",
>  };
> 
> -/* smartreflex0 */
> -static struct omap_hwmod_irq_info am33xx_smartreflex0_irqs[] = {
> -	{ .irq = 120 + OMAP_INTC_START, },
> -	{ .irq = -1 },
> -};
> -
>  static struct omap_hwmod am33xx_smartreflex0_hwmod = {
>  	.name		= "smartreflex0",
>  	.class		= &am33xx_smartreflex_hwmod_class,
>  	.clkdm_name	= "l4_wkup_clkdm",
> -	.mpu_irqs	= am33xx_smartreflex0_irqs,
>  	.main_clk	= "smartreflex0_fck",
>  	.prcm		= {
>  		.omap4	= {
> @@ -597,17 +427,10 @@ static struct omap_hwmod
> am33xx_smartreflex0_hwmod = {
>  	},
>  };
> 
> -/* smartreflex1 */
> -static struct omap_hwmod_irq_info am33xx_smartreflex1_irqs[] = {
> -	{ .irq = 121 + OMAP_INTC_START, },
> -	{ .irq = -1 },
> -};
> -
>  static struct omap_hwmod am33xx_smartreflex1_hwmod = {
>  	.name		= "smartreflex1",
>  	.class		= &am33xx_smartreflex_hwmod_class,
>  	.clkdm_name	= "l4_wkup_clkdm",
> -	.mpu_irqs	= am33xx_smartreflex1_irqs,
>  	.main_clk	= "smartreflex1_fck",
>  	.prcm		= {
>  		.omap4	= {
> @@ -624,17 +447,11 @@ static struct omap_hwmod_class
> am33xx_control_hwmod_class = {
>  	.name		= "control",
>  };
> 
> -static struct omap_hwmod_irq_info am33xx_control_irqs[] = {
> -	{ .irq = 8 + OMAP_INTC_START, },
> -	{ .irq = -1 },
> -};
> -
>  static struct omap_hwmod am33xx_control_hwmod = {
>  	.name		= "control",
>  	.class		= &am33xx_control_hwmod_class,
>  	.clkdm_name	= "l4_wkup_clkdm",
>  	.flags		= (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET),
> -	.mpu_irqs	= am33xx_control_irqs,
>  	.main_clk	= "dpll_core_m4_div2_ck",
>  	.prcm		= {
>  		.omap4	= {
> @@ -664,20 +481,11 @@ static struct omap_hwmod_class
> am33xx_cpgmac0_hwmod_class = {
>  	.sysc		= &am33xx_cpgmac_sysc,
>  };
> 
> -static struct omap_hwmod_irq_info am33xx_cpgmac0_irqs[] = {
> -	{ .name = "c0_rx_thresh_pend", .irq = 40 + OMAP_INTC_START, },
> -	{ .name = "c0_rx_pend", .irq = 41 + OMAP_INTC_START, },
> -	{ .name = "c0_tx_pend", .irq = 42 + OMAP_INTC_START, },
> -	{ .name = "c0_misc_pend", .irq = 43 + OMAP_INTC_START, },
> -	{ .irq = -1 },
> -};
> -
>  static struct omap_hwmod am33xx_cpgmac0_hwmod = {
>  	.name		= "cpgmac0",
>  	.class		= &am33xx_cpgmac0_hwmod_class,
>  	.clkdm_name	= "cpsw_125mhz_clkdm",
>  	.flags		= (HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY),
> -	.mpu_irqs	= am33xx_cpgmac0_irqs,
>  	.main_clk	= "cpsw_125mhz_gclk",
>  	.prcm		= {
>  		.omap4	= {
> @@ -708,18 +516,10 @@ static struct omap_hwmod_class
> am33xx_dcan_hwmod_class = {
>  	.name = "d_can",
>  };
> 
> -/* dcan0 */
> -static struct omap_hwmod_irq_info am33xx_dcan0_irqs[] = {
> -	{ .name = "d_can_ms", .irq = 52 + OMAP_INTC_START, },
> -	{ .name = "d_can_mo", .irq = 53 + OMAP_INTC_START, },
> -	{ .irq = -1 },
> -};
> -
>  static struct omap_hwmod am33xx_dcan0_hwmod = {
>  	.name		= "d_can0",
>  	.class		= &am33xx_dcan_hwmod_class,
>  	.clkdm_name	= "l4ls_clkdm",
> -	.mpu_irqs	= am33xx_dcan0_irqs,
>  	.main_clk	= "dcan0_fck",
>  	.prcm		= {
>  		.omap4	= {
> @@ -729,17 +529,10 @@ static struct omap_hwmod am33xx_dcan0_hwmod = {
>  	},
>  };
> 
> -/* dcan1 */
> -static struct omap_hwmod_irq_info am33xx_dcan1_irqs[] = {
> -	{ .name = "d_can_ms", .irq = 55 + OMAP_INTC_START, },
> -	{ .name = "d_can_mo", .irq = 56 + OMAP_INTC_START, },
> -	{ .irq = -1 },
> -};
>  static struct omap_hwmod am33xx_dcan1_hwmod = {
>  	.name		= "d_can1",
>  	.class		= &am33xx_dcan_hwmod_class,
>  	.clkdm_name	= "l4ls_clkdm",
> -	.mpu_irqs	= am33xx_dcan1_irqs,
>  	.main_clk	= "dcan1_fck",
>  	.prcm		= {
>  		.omap4	= {
> @@ -749,241 +542,6 @@ static struct omap_hwmod am33xx_dcan1_hwmod = {
>  	},
>  };
> 
> -/* elm */
> -static struct omap_hwmod_class_sysconfig am33xx_elm_sysc = {
> -	.rev_offs	= 0x0000,
> -	.sysc_offs	= 0x0010,
> -	.syss_offs	= 0x0014,
> -	.sysc_flags	= (SYSC_HAS_CLOCKACTIVITY | SYSC_HAS_SIDLEMODE |
> -			SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE |
> -			SYSS_HAS_RESET_STATUS),
> -	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
> -	.sysc_fields	= &omap_hwmod_sysc_type1,
> -};
> -
> -static struct omap_hwmod_class am33xx_elm_hwmod_class = {
> -	.name		= "elm",
> -	.sysc		= &am33xx_elm_sysc,
> -};
> -
> -static struct omap_hwmod_irq_info am33xx_elm_irqs[] = {
> -	{ .irq = 4 + OMAP_INTC_START, },
> -	{ .irq = -1 },
> -};
> -
> -static struct omap_hwmod am33xx_elm_hwmod = {
> -	.name		= "elm",
> -	.class		= &am33xx_elm_hwmod_class,
> -	.clkdm_name	= "l4ls_clkdm",
> -	.mpu_irqs	= am33xx_elm_irqs,
> -	.main_clk	= "l4ls_gclk",
> -	.prcm		= {
> -		.omap4	= {
> -			.clkctrl_offs	= AM33XX_CM_PER_ELM_CLKCTRL_OFFSET,
> -			.modulemode	= MODULEMODE_SWCTRL,
> -		},
> -	},
> -};
> -
> -/* pwmss  */
> -static struct omap_hwmod_class_sysconfig am33xx_epwmss_sysc = {
> -	.rev_offs	= 0x0,
> -	.sysc_offs	= 0x4,
> -	.sysc_flags	= (SYSC_HAS_SIDLEMODE | SYSC_HAS_MIDLEMODE),
> -	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
> -			SIDLE_SMART_WKUP | MSTANDBY_FORCE | MSTANDBY_NO |
> -			MSTANDBY_SMART | MSTANDBY_SMART_WKUP),
> -	.sysc_fields	= &omap_hwmod_sysc_type2,
> -};
> -
> -static struct omap_hwmod_class am33xx_epwmss_hwmod_class = {
> -	.name		= "epwmss",
> -	.sysc		= &am33xx_epwmss_sysc,
> -};
> -
> -static struct omap_hwmod_class am33xx_ecap_hwmod_class = {
> -	.name		= "ecap",
> -};
> -
> -static struct omap_hwmod_class am33xx_eqep_hwmod_class = {
> -	.name		= "eqep",
> -};
> -
> -static struct omap_hwmod_class am33xx_ehrpwm_hwmod_class = {
> -	.name		= "ehrpwm",
> -};
> -
> -/* epwmss0 */
> -static struct omap_hwmod am33xx_epwmss0_hwmod = {
> -	.name		= "epwmss0",
> -	.class		= &am33xx_epwmss_hwmod_class,
> -	.clkdm_name	= "l4ls_clkdm",
> -	.main_clk	= "l4ls_gclk",
> -	.prcm		= {
> -		.omap4	= {
> -			.clkctrl_offs	=
> AM33XX_CM_PER_EPWMSS0_CLKCTRL_OFFSET,
> -			.modulemode	= MODULEMODE_SWCTRL,
> -		},
> -	},
> -};
> -
> -/* ecap0 */
> -static struct omap_hwmod_irq_info am33xx_ecap0_irqs[] = {
> -	{ .irq = 31 + OMAP_INTC_START, },
> -	{ .irq = -1 },
> -};
> -
> -static struct omap_hwmod am33xx_ecap0_hwmod = {
> -	.name		= "ecap0",
> -	.class		= &am33xx_ecap_hwmod_class,
> -	.clkdm_name	= "l4ls_clkdm",
> -	.mpu_irqs	= am33xx_ecap0_irqs,
> -	.main_clk	= "l4ls_gclk",
> -};
> -
> -/* eqep0 */
> -static struct omap_hwmod_irq_info am33xx_eqep0_irqs[] = {
> -	{ .irq = 79 + OMAP_INTC_START, },
> -	{ .irq = -1 },
> -};
> -
> -static struct omap_hwmod am33xx_eqep0_hwmod = {
> -	.name		= "eqep0",
> -	.class		= &am33xx_eqep_hwmod_class,
> -	.clkdm_name	= "l4ls_clkdm",
> -	.mpu_irqs	= am33xx_eqep0_irqs,
> -	.main_clk	= "l4ls_gclk",
> -};
> -
> -/* ehrpwm0 */
> -static struct omap_hwmod_irq_info am33xx_ehrpwm0_irqs[] = {
> -	{ .name = "int", .irq = 86 + OMAP_INTC_START, },
> -	{ .name = "tzint", .irq = 58 + OMAP_INTC_START, },
> -	{ .irq = -1 },
> -};
> -
> -static struct omap_hwmod am33xx_ehrpwm0_hwmod = {
> -	.name		= "ehrpwm0",
> -	.class		= &am33xx_ehrpwm_hwmod_class,
> -	.clkdm_name	= "l4ls_clkdm",
> -	.mpu_irqs	= am33xx_ehrpwm0_irqs,
> -	.main_clk	= "l4ls_gclk",
> -};
> -
> -/* epwmss1 */
> -static struct omap_hwmod am33xx_epwmss1_hwmod = {
> -	.name		= "epwmss1",
> -	.class		= &am33xx_epwmss_hwmod_class,
> -	.clkdm_name	= "l4ls_clkdm",
> -	.main_clk	= "l4ls_gclk",
> -	.prcm		= {
> -		.omap4	= {
> -			.clkctrl_offs	=
> AM33XX_CM_PER_EPWMSS1_CLKCTRL_OFFSET,
> -			.modulemode	= MODULEMODE_SWCTRL,
> -		},
> -	},
> -};
> -
> -/* ecap1 */
> -static struct omap_hwmod_irq_info am33xx_ecap1_irqs[] = {
> -	{ .irq = 47 + OMAP_INTC_START, },
> -	{ .irq = -1 },
> -};
> -
> -static struct omap_hwmod am33xx_ecap1_hwmod = {
> -	.name		= "ecap1",
> -	.class		= &am33xx_ecap_hwmod_class,
> -	.clkdm_name	= "l4ls_clkdm",
> -	.mpu_irqs	= am33xx_ecap1_irqs,
> -	.main_clk	= "l4ls_gclk",
> -};
> -
> -/* eqep1 */
> -static struct omap_hwmod_irq_info am33xx_eqep1_irqs[] = {
> -	{ .irq = 88 + OMAP_INTC_START, },
> -	{ .irq = -1 },
> -};
> -
> -static struct omap_hwmod am33xx_eqep1_hwmod = {
> -	.name		= "eqep1",
> -	.class		= &am33xx_eqep_hwmod_class,
> -	.clkdm_name	= "l4ls_clkdm",
> -	.mpu_irqs	= am33xx_eqep1_irqs,
> -	.main_clk	= "l4ls_gclk",
> -};
> -
> -/* ehrpwm1 */
> -static struct omap_hwmod_irq_info am33xx_ehrpwm1_irqs[] = {
> -	{ .name = "int", .irq = 87 + OMAP_INTC_START, },
> -	{ .name = "tzint", .irq = 59 + OMAP_INTC_START, },
> -	{ .irq = -1 },
> -};
> -
> -static struct omap_hwmod am33xx_ehrpwm1_hwmod = {
> -	.name		= "ehrpwm1",
> -	.class		= &am33xx_ehrpwm_hwmod_class,
> -	.clkdm_name	= "l4ls_clkdm",
> -	.mpu_irqs	= am33xx_ehrpwm1_irqs,
> -	.main_clk	= "l4ls_gclk",
> -};
> -
> -/* epwmss2 */
> -static struct omap_hwmod am33xx_epwmss2_hwmod = {
> -	.name		= "epwmss2",
> -	.class		= &am33xx_epwmss_hwmod_class,
> -	.clkdm_name	= "l4ls_clkdm",
> -	.main_clk	= "l4ls_gclk",
> -	.prcm		= {
> -		.omap4	= {
> -			.clkctrl_offs	=
> AM33XX_CM_PER_EPWMSS2_CLKCTRL_OFFSET,
> -			.modulemode	= MODULEMODE_SWCTRL,
> -		},
> -	},
> -};
> -
> -/* ecap2 */
> -static struct omap_hwmod_irq_info am33xx_ecap2_irqs[] = {
> -	{ .irq = 61 + OMAP_INTC_START, },
> -	{ .irq = -1 },
> -};
> -
> -static struct omap_hwmod am33xx_ecap2_hwmod = {
> -	.name		= "ecap2",
> -	.class		= &am33xx_ecap_hwmod_class,
> -	.clkdm_name	= "l4ls_clkdm",
> -	.mpu_irqs	= am33xx_ecap2_irqs,
> -	.main_clk	= "l4ls_gclk",
> -};
> -
> -/* eqep2 */
> -static struct omap_hwmod_irq_info am33xx_eqep2_irqs[] = {
> -	{ .irq = 89 + OMAP_INTC_START, },
> -	{ .irq = -1 },
> -};
> -
> -static struct omap_hwmod am33xx_eqep2_hwmod = {
> -	.name		= "eqep2",
> -	.class		= &am33xx_eqep_hwmod_class,
> -	.clkdm_name	= "l4ls_clkdm",
> -	.mpu_irqs	= am33xx_eqep2_irqs,
> -	.main_clk	= "l4ls_gclk",
> -};
> -
> -/* ehrpwm2 */
> -static struct omap_hwmod_irq_info am33xx_ehrpwm2_irqs[] = {
> -	{ .name = "int", .irq = 39 + OMAP_INTC_START, },
> -	{ .name = "tzint", .irq = 60 + OMAP_INTC_START, },
> -	{ .irq = -1 },
> -};
> -
> -static struct omap_hwmod am33xx_ehrpwm2_hwmod = {
> -	.name		= "ehrpwm2",
> -	.class		= &am33xx_ehrpwm_hwmod_class,
> -	.clkdm_name	= "l4ls_clkdm",
> -	.mpu_irqs	= am33xx_ehrpwm2_irqs,
> -	.main_clk	= "l4ls_gclk",
> -};
> -
>  /*
>   * 'gpio' class: for gpio 0,1,2,3
>   */
> @@ -1015,17 +573,11 @@ static struct omap_hwmod_opt_clk
> gpio0_opt_clks[] = {
>  	{ .role = "dbclk", .clk = "gpio0_dbclk" },
>  };
> 
> -static struct omap_hwmod_irq_info am33xx_gpio0_irqs[] = {
> -	{ .irq = 96 + OMAP_INTC_START, },
> -	{ .irq = -1 },
> -};
> -
>  static struct omap_hwmod am33xx_gpio0_hwmod = {
>  	.name		= "gpio1",
>  	.class		= &am33xx_gpio_hwmod_class,
>  	.clkdm_name	= "l4_wkup_clkdm",
>  	.flags		= HWMOD_CONTROL_OPT_CLKS_IN_RESET,
> -	.mpu_irqs	= am33xx_gpio0_irqs,
>  	.main_clk	= "dpll_core_m4_div2_ck",
>  	.prcm		= {
>  		.omap4	= {
> @@ -1039,11 +591,6 @@ static struct omap_hwmod am33xx_gpio0_hwmod = {
>  };
> 
>  /* gpio1 */
> -static struct omap_hwmod_irq_info am33xx_gpio1_irqs[] = {
> -	{ .irq = 98 + OMAP_INTC_START, },
> -	{ .irq = -1 },
> -};
> -
>  static struct omap_hwmod_opt_clk gpio1_opt_clks[] = {
>  	{ .role = "dbclk", .clk = "gpio1_dbclk" },
>  };
> @@ -1053,7 +600,6 @@ static struct omap_hwmod am33xx_gpio1_hwmod = {
>  	.class		= &am33xx_gpio_hwmod_class,
>  	.clkdm_name	= "l4ls_clkdm",
>  	.flags		= HWMOD_CONTROL_OPT_CLKS_IN_RESET,
> -	.mpu_irqs	= am33xx_gpio1_irqs,
>  	.main_clk	= "l4ls_gclk",
>  	.prcm		= {
>  		.omap4	= {
> @@ -1067,11 +613,6 @@ static struct omap_hwmod am33xx_gpio1_hwmod = {
>  };
> 
>  /* gpio2 */
> -static struct omap_hwmod_irq_info am33xx_gpio2_irqs[] = {
> -	{ .irq = 32 + OMAP_INTC_START, },
> -	{ .irq = -1 },
> -};
> -
>  static struct omap_hwmod_opt_clk gpio2_opt_clks[] = {
>  	{ .role = "dbclk", .clk = "gpio2_dbclk" },
>  };
> @@ -1081,7 +622,6 @@ static struct omap_hwmod am33xx_gpio2_hwmod = {
>  	.class		= &am33xx_gpio_hwmod_class,
>  	.clkdm_name	= "l4ls_clkdm",
>  	.flags		= HWMOD_CONTROL_OPT_CLKS_IN_RESET,
> -	.mpu_irqs	= am33xx_gpio2_irqs,
>  	.main_clk	= "l4ls_gclk",
>  	.prcm		= {
>  		.omap4	= {
> @@ -1095,11 +635,6 @@ static struct omap_hwmod am33xx_gpio2_hwmod = {
>  };
> 
>  /* gpio3 */
> -static struct omap_hwmod_irq_info am33xx_gpio3_irqs[] = {
> -	{ .irq = 62 + OMAP_INTC_START, },
> -	{ .irq = -1 },
> -};
> -
>  static struct omap_hwmod_opt_clk gpio3_opt_clks[] = {
>  	{ .role = "dbclk", .clk = "gpio3_dbclk" },
>  };
> @@ -1109,7 +644,6 @@ static struct omap_hwmod am33xx_gpio3_hwmod = {
>  	.class		= &am33xx_gpio_hwmod_class,
>  	.clkdm_name	= "l4ls_clkdm",
>  	.flags		= HWMOD_CONTROL_OPT_CLKS_IN_RESET,
> -	.mpu_irqs	= am33xx_gpio3_irqs,
>  	.main_clk	= "l4ls_gclk",
>  	.prcm		= {
>  		.omap4	= {
> @@ -1122,42 +656,6 @@ static struct omap_hwmod am33xx_gpio3_hwmod = {
>  	.dev_attr	= &gpio_dev_attr,
>  };
> 
> -/* gpmc */
> -static struct omap_hwmod_class_sysconfig gpmc_sysc = {
> -	.rev_offs	= 0x0,
> -	.sysc_offs	= 0x10,
> -	.syss_offs	= 0x14,
> -	.sysc_flags	= (SYSC_HAS_AUTOIDLE | SYSC_HAS_SIDLEMODE |
> -			SYSC_HAS_SOFTRESET | SYSS_HAS_RESET_STATUS),
> -	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
> -	.sysc_fields	= &omap_hwmod_sysc_type1,
> -};
> -
> -static struct omap_hwmod_class am33xx_gpmc_hwmod_class = {
> -	.name		= "gpmc",
> -	.sysc		= &gpmc_sysc,
> -};
> -
> -static struct omap_hwmod_irq_info am33xx_gpmc_irqs[] = {
> -	{ .irq = 100 + OMAP_INTC_START, },
> -	{ .irq = -1 },
> -};
> -
> -static struct omap_hwmod am33xx_gpmc_hwmod = {
> -	.name		= "gpmc",
> -	.class		= &am33xx_gpmc_hwmod_class,
> -	.clkdm_name	= "l3s_clkdm",
> -	.flags		= (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET),
> -	.mpu_irqs	= am33xx_gpmc_irqs,
> -	.main_clk	= "l3s_gclk",
> -	.prcm		= {
> -		.omap4	= {
> -			.clkctrl_offs	=
> AM33XX_CM_PER_GPMC_CLKCTRL_OFFSET,
> -			.modulemode	= MODULEMODE_SWCTRL,
> -		},
> -	},
> -};
> -
>  /* 'i2c' class */
>  static struct omap_hwmod_class_sysconfig am33xx_i2c_sysc = {
>  	.sysc_offs	= 0x0010,
> @@ -1182,23 +680,10 @@ static struct omap_i2c_dev_attr i2c_dev_attr = {
>  };
> 
>  /* i2c1 */
> -static struct omap_hwmod_irq_info i2c1_mpu_irqs[] = {
> -	{ .irq = 70 + OMAP_INTC_START, },
> -	{ .irq = -1 },
> -};
> -
> -static struct omap_hwmod_dma_info i2c1_edma_reqs[] = {
> -	{ .name = "tx", .dma_req = 0, },
> -	{ .name = "rx", .dma_req = 0, },
> -	{ .dma_req = -1 }
> -};
> -
>  static struct omap_hwmod am33xx_i2c1_hwmod = {
>  	.name		= "i2c1",
>  	.class		= &i2c_class,
>  	.clkdm_name	= "l4_wkup_clkdm",
> -	.mpu_irqs	= i2c1_mpu_irqs,
> -	.sdma_reqs	= i2c1_edma_reqs,
>  	.flags		= HWMOD_16BIT_REG | HWMOD_SET_DEFAULT_CLOCKACT,
>  	.main_clk	= "dpll_per_m2_div4_wkupdm_ck",
>  	.prcm		= {
> @@ -1211,23 +696,10 @@ static struct omap_hwmod am33xx_i2c1_hwmod = {
>  };
> 
>  /* i2c1 */
> -static struct omap_hwmod_irq_info i2c2_mpu_irqs[] = {
> -	{ .irq = 71 + OMAP_INTC_START, },
> -	{ .irq = -1 },
> -};
> -
> -static struct omap_hwmod_dma_info i2c2_edma_reqs[] = {
> -	{ .name = "tx", .dma_req = 0, },
> -	{ .name = "rx", .dma_req = 0, },
> -	{ .dma_req = -1 }
> -};
> -
>  static struct omap_hwmod am33xx_i2c2_hwmod = {
>  	.name		= "i2c2",
>  	.class		= &i2c_class,
>  	.clkdm_name	= "l4ls_clkdm",
> -	.mpu_irqs	= i2c2_mpu_irqs,
> -	.sdma_reqs	= i2c2_edma_reqs,
>  	.flags		= HWMOD_16BIT_REG | HWMOD_SET_DEFAULT_CLOCKACT,
>  	.main_clk	= "dpll_per_m2_div4_ck",
>  	.prcm		= {
> @@ -1240,23 +712,10 @@ static struct omap_hwmod am33xx_i2c2_hwmod = {
>  };
> 
>  /* i2c3 */
> -static struct omap_hwmod_dma_info i2c3_edma_reqs[] = {
> -	{ .name = "tx", .dma_req = 0, },
> -	{ .name = "rx", .dma_req = 0, },
> -	{ .dma_req = -1 }
> -};
> -
> -static struct omap_hwmod_irq_info i2c3_mpu_irqs[] = {
> -	{ .irq = 30 + OMAP_INTC_START, },
> -	{ .irq = -1 },
> -};
> -
>  static struct omap_hwmod am33xx_i2c3_hwmod = {
>  	.name		= "i2c3",
>  	.class		= &i2c_class,
>  	.clkdm_name	= "l4ls_clkdm",
> -	.mpu_irqs	= i2c3_mpu_irqs,
> -	.sdma_reqs	= i2c3_edma_reqs,
>  	.flags		= HWMOD_16BIT_REG | HWMOD_SET_DEFAULT_CLOCKACT,
>  	.main_clk	= "dpll_per_m2_div4_ck",
>  	.prcm		= {
> @@ -1268,292 +727,28 @@ static struct omap_hwmod am33xx_i2c3_hwmod = {
>  	.dev_attr	= &i2c_dev_attr,
>  };
> 
> -
> -/* lcdc */
> -static struct omap_hwmod_class_sysconfig lcdc_sysc = {
> -	.rev_offs	= 0x0,
> -	.sysc_offs	= 0x54,
> -	.sysc_flags	= (SYSC_HAS_SIDLEMODE | SYSC_HAS_MIDLEMODE),
> -	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
> -	.sysc_fields	= &omap_hwmod_sysc_type2,
> -};
> -
> -static struct omap_hwmod_class am33xx_lcdc_hwmod_class = {
> -	.name		= "lcdc",
> -	.sysc		= &lcdc_sysc,
> -};
> -
> -static struct omap_hwmod_irq_info am33xx_lcdc_irqs[] = {
> -	{ .irq = 36 + OMAP_INTC_START, },
> -	{ .irq = -1 },
> -};
> -
> -static struct omap_hwmod am33xx_lcdc_hwmod = {
> -	.name		= "lcdc",
> -	.class		= &am33xx_lcdc_hwmod_class,
> -	.clkdm_name	= "lcdc_clkdm",
> -	.mpu_irqs	= am33xx_lcdc_irqs,
> -	.flags		= HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY,
> -	.main_clk	= "lcd_gclk",
> -	.prcm		= {
> -		.omap4	= {
> -			.clkctrl_offs	=
> AM33XX_CM_PER_LCDC_CLKCTRL_OFFSET,
> -			.modulemode	= MODULEMODE_SWCTRL,
> -		},
> -	},
> -};
> -
> -/*
> - * 'mailbox' class
> - * mailbox module allowing communication between the on-chip
> processors using a
> - * queued mailbox-interrupt mechanism.
> - */
> -static struct omap_hwmod_class_sysconfig am33xx_mailbox_sysc = {
> -	.rev_offs	= 0x0000,
> -	.sysc_offs	= 0x0010,
> -	.sysc_flags	= (SYSC_HAS_RESET_STATUS | SYSC_HAS_SIDLEMODE |
> -			  SYSC_HAS_SOFTRESET),
> -	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
> -	.sysc_fields	= &omap_hwmod_sysc_type2,
> -};
> -
> -static struct omap_hwmod_class am33xx_mailbox_hwmod_class = {
> -	.name	= "mailbox",
> -	.sysc	= &am33xx_mailbox_sysc,
> -};
> -
> -static struct omap_hwmod_irq_info am33xx_mailbox_irqs[] = {
> -	{ .irq = 77 + OMAP_INTC_START, },
> -	{ .irq = -1 },
> -};
> -
> -static struct omap_hwmod am33xx_mailbox_hwmod = {
> -	.name		= "mailbox",
> -	.class		= &am33xx_mailbox_hwmod_class,
> -	.clkdm_name	= "l4ls_clkdm",
> -	.mpu_irqs	= am33xx_mailbox_irqs,
> -	.main_clk	= "l4ls_gclk",
> -	.prcm = {
> -		.omap4 = {
> -			.clkctrl_offs	=
> AM33XX_CM_PER_MAILBOX0_CLKCTRL_OFFSET,
> -			.modulemode	= MODULEMODE_SWCTRL,
> -		},
> -	},
> -};
> -
> -/*
> - * 'mcasp' class
> - */
> -static struct omap_hwmod_class_sysconfig am33xx_mcasp_sysc = {
> -	.rev_offs	= 0x0,
> -	.sysc_offs	= 0x4,
> -	.sysc_flags	= SYSC_HAS_SIDLEMODE,
> -	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
> -	.sysc_fields	= &omap_hwmod_sysc_type3,
> -};
> -
> -static struct omap_hwmod_class am33xx_mcasp_hwmod_class = {
> -	.name		= "mcasp",
> -	.sysc		= &am33xx_mcasp_sysc,
> -};
> -
> -/* mcasp0 */
> -static struct omap_hwmod_irq_info am33xx_mcasp0_irqs[] = {
> -	{ .name = "ax", .irq = 80 + OMAP_INTC_START, },
> -	{ .name = "ar", .irq = 81 + OMAP_INTC_START, },
> -	{ .irq = -1 },
> -};
> -
> -static struct omap_hwmod_dma_info am33xx_mcasp0_edma_reqs[] = {
> -	{ .name = "tx", .dma_req = 8, },
> -	{ .name = "rx", .dma_req = 9, },
> -	{ .dma_req = -1 }
> -};
> -
> -static struct omap_hwmod am33xx_mcasp0_hwmod = {
> -	.name		= "mcasp0",
> -	.class		= &am33xx_mcasp_hwmod_class,
> -	.clkdm_name	= "l3s_clkdm",
> -	.mpu_irqs	= am33xx_mcasp0_irqs,
> -	.sdma_reqs	= am33xx_mcasp0_edma_reqs,
> -	.main_clk	= "mcasp0_fck",
> -	.prcm		= {
> -		.omap4	= {
> -			.clkctrl_offs	=
> AM33XX_CM_PER_MCASP0_CLKCTRL_OFFSET,
> -			.modulemode	= MODULEMODE_SWCTRL,
> -		},
> -	},
> -};
> -
> -/* mcasp1 */
> -static struct omap_hwmod_irq_info am33xx_mcasp1_irqs[] = {
> -	{ .name = "ax", .irq = 82 + OMAP_INTC_START, },
> -	{ .name = "ar", .irq = 83 + OMAP_INTC_START, },
> -	{ .irq = -1 },
> -};
> -
> -static struct omap_hwmod_dma_info am33xx_mcasp1_edma_reqs[] = {
> -	{ .name = "tx", .dma_req = 10, },
> -	{ .name = "rx", .dma_req = 11, },
> -	{ .dma_req = -1 }
> -};
> -
> -static struct omap_hwmod am33xx_mcasp1_hwmod = {
> -	.name		= "mcasp1",
> -	.class		= &am33xx_mcasp_hwmod_class,
> -	.clkdm_name	= "l3s_clkdm",
> -	.mpu_irqs	= am33xx_mcasp1_irqs,
> -	.sdma_reqs	= am33xx_mcasp1_edma_reqs,
> -	.main_clk	= "mcasp1_fck",
> -	.prcm		= {
> -		.omap4	= {
> -			.clkctrl_offs	=
> AM33XX_CM_PER_MCASP1_CLKCTRL_OFFSET,
> -			.modulemode	= MODULEMODE_SWCTRL,
> -		},
> -	},
> -};
> -
> -/* 'mmc' class */
> -static struct omap_hwmod_class_sysconfig am33xx_mmc_sysc = {
> -	.rev_offs	= 0x1fc,
> -	.sysc_offs	= 0x10,
> -	.syss_offs	= 0x14,
> -	.sysc_flags	= (SYSC_HAS_CLOCKACTIVITY | SYSC_HAS_SIDLEMODE |
> -			  SYSC_HAS_ENAWAKEUP | SYSC_HAS_SOFTRESET |
> -			  SYSC_HAS_AUTOIDLE | SYSS_HAS_RESET_STATUS),
> -	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
> -	.sysc_fields	= &omap_hwmod_sysc_type1,
> -};
> -
> -static struct omap_hwmod_class am33xx_mmc_hwmod_class = {
> -	.name		= "mmc",
> -	.sysc		= &am33xx_mmc_sysc,
> -};
> -
> -/* mmc0 */
> -static struct omap_hwmod_irq_info am33xx_mmc0_irqs[] = {
> -	{ .irq = 64 + OMAP_INTC_START, },
> -	{ .irq = -1 },
> -};
> -
> -static struct omap_hwmod_dma_info am33xx_mmc0_edma_reqs[] = {
> -	{ .name = "tx", .dma_req = 24, },
> -	{ .name = "rx", .dma_req = 25, },
> -	{ .dma_req = -1 }
> -};
> -
> -static struct omap_mmc_dev_attr am33xx_mmc0_dev_attr = {
> -	.flags		= OMAP_HSMMC_SUPPORTS_DUAL_VOLT,
> -};
> -
> -static struct omap_hwmod am33xx_mmc0_hwmod = {
> -	.name		= "mmc1",
> -	.class		= &am33xx_mmc_hwmod_class,
> -	.clkdm_name	= "l4ls_clkdm",
> -	.mpu_irqs	= am33xx_mmc0_irqs,
> -	.sdma_reqs	= am33xx_mmc0_edma_reqs,
> -	.main_clk	= "mmc_clk",
> -	.prcm		= {
> -		.omap4	= {
> -			.clkctrl_offs	=
> AM33XX_CM_PER_MMC0_CLKCTRL_OFFSET,
> -			.modulemode	= MODULEMODE_SWCTRL,
> -		},
> -	},
> -	.dev_attr	= &am33xx_mmc0_dev_attr,
> -};
> -
> -/* mmc1 */
> -static struct omap_hwmod_irq_info am33xx_mmc1_irqs[] = {
> -	{ .irq = 28 + OMAP_INTC_START, },
> -	{ .irq = -1 },
> -};
> -
> -static struct omap_hwmod_dma_info am33xx_mmc1_edma_reqs[] = {
> -	{ .name = "tx", .dma_req = 2, },
> -	{ .name = "rx", .dma_req = 3, },
> -	{ .dma_req = -1 }
> -};
> -
> -static struct omap_mmc_dev_attr am33xx_mmc1_dev_attr = {
> -	.flags		= OMAP_HSMMC_SUPPORTS_DUAL_VOLT,
> -};
> -
> -static struct omap_hwmod am33xx_mmc1_hwmod = {
> -	.name		= "mmc2",
> -	.class		= &am33xx_mmc_hwmod_class,
> -	.clkdm_name	= "l4ls_clkdm",
> -	.mpu_irqs	= am33xx_mmc1_irqs,
> -	.sdma_reqs	= am33xx_mmc1_edma_reqs,
> -	.main_clk	= "mmc_clk",
> -	.prcm		= {
> -		.omap4	= {
> -			.clkctrl_offs	=
> AM33XX_CM_PER_MMC1_CLKCTRL_OFFSET,
> -			.modulemode	= MODULEMODE_SWCTRL,
> -		},
> -	},
> -	.dev_attr	= &am33xx_mmc1_dev_attr,
> -};
> -
> -/* mmc2 */
> -static struct omap_hwmod_irq_info am33xx_mmc2_irqs[] = {
> -	{ .irq = 29 + OMAP_INTC_START, },
> -	{ .irq = -1 },
> -};
> -
> -static struct omap_hwmod_dma_info am33xx_mmc2_edma_reqs[] = {
> -	{ .name = "tx", .dma_req = 64, },
> -	{ .name = "rx", .dma_req = 65, },
> -	{ .dma_req = -1 }
> -};
> -
> -static struct omap_mmc_dev_attr am33xx_mmc2_dev_attr = {
> -	.flags		= OMAP_HSMMC_SUPPORTS_DUAL_VOLT,
> -};
> -static struct omap_hwmod am33xx_mmc2_hwmod = {
> -	.name		= "mmc3",
> -	.class		= &am33xx_mmc_hwmod_class,
> -	.clkdm_name	= "l3s_clkdm",
> -	.mpu_irqs	= am33xx_mmc2_irqs,
> -	.sdma_reqs	= am33xx_mmc2_edma_reqs,
> -	.main_clk	= "mmc_clk",
> -	.prcm		= {
> -		.omap4	= {
> -			.clkctrl_offs	=
> AM33XX_CM_PER_MMC2_CLKCTRL_OFFSET,
> -			.modulemode	= MODULEMODE_SWCTRL,
> -		},
> -	},
> -	.dev_attr	= &am33xx_mmc2_dev_attr,
> -};
> -
> -/*
> - * 'rtc' class
> - * rtc subsystem
> - */
> -static struct omap_hwmod_class_sysconfig am33xx_rtc_sysc = {
> -	.rev_offs	= 0x0074,
> -	.sysc_offs	= 0x0078,
> -	.sysc_flags	= SYSC_HAS_SIDLEMODE,
> -	.idlemodes	= (SIDLE_FORCE | SIDLE_NO |
> -			  SIDLE_SMART | SIDLE_SMART_WKUP),
> -	.sysc_fields	= &omap_hwmod_sysc_type3,
> -};
> +/*
> + * 'rtc' class
> + * rtc subsystem
> + */
> +static struct omap_hwmod_class_sysconfig am33xx_rtc_sysc = {
> +	.rev_offs	= 0x0074,
> +	.sysc_offs	= 0x0078,
> +	.sysc_flags	= SYSC_HAS_SIDLEMODE,
> +	.idlemodes	= (SIDLE_FORCE | SIDLE_NO |
> +			  SIDLE_SMART | SIDLE_SMART_WKUP),
> +	.sysc_fields	= &omap_hwmod_sysc_type3,
> +};
> 
>  static struct omap_hwmod_class am33xx_rtc_hwmod_class = {
>  	.name		= "rtc",
>  	.sysc		= &am33xx_rtc_sysc,
>  };
> 
> -static struct omap_hwmod_irq_info am33xx_rtc_irqs[] = {
> -	{ .name = "rtcint", .irq = 75 + OMAP_INTC_START, },
> -	{ .name = "rtcalarmint", .irq = 76 + OMAP_INTC_START, },
> -	{ .irq = -1 },
> -};
> -
>  static struct omap_hwmod am33xx_rtc_hwmod = {
>  	.name		= "rtc",
>  	.class		= &am33xx_rtc_hwmod_class,
>  	.clkdm_name	= "l4_rtc_clkdm",
> -	.mpu_irqs	= am33xx_rtc_irqs,
>  	.main_clk	= "clk_32768_ck",
>  	.prcm		= {
>  		.omap4	= {
> @@ -1582,19 +777,6 @@ static struct omap_hwmod_class
> am33xx_spi_hwmod_class = {
>  };
> 
>  /* spi0 */
> -static struct omap_hwmod_irq_info am33xx_spi0_irqs[] = {
> -	{ .irq = 65 + OMAP_INTC_START, },
> -	{ .irq = -1 },
> -};
> -
> -static struct omap_hwmod_dma_info am33xx_mcspi0_edma_reqs[] = {
> -	{ .name = "rx0", .dma_req = 17 },
> -	{ .name = "tx0", .dma_req = 16 },
> -	{ .name = "rx1", .dma_req = 19 },
> -	{ .name = "tx1", .dma_req = 18 },
> -	{ .dma_req = -1 }
> -};
> -
>  static struct omap2_mcspi_dev_attr mcspi_attrib = {
>  	.num_chipselect	= 2,
>  };
> @@ -1602,8 +784,6 @@ static struct omap_hwmod am33xx_spi0_hwmod = {
>  	.name		= "spi0",
>  	.class		= &am33xx_spi_hwmod_class,
>  	.clkdm_name	= "l4ls_clkdm",
> -	.mpu_irqs	= am33xx_spi0_irqs,
> -	.sdma_reqs	= am33xx_mcspi0_edma_reqs,
>  	.main_clk	= "dpll_per_m2_div4_ck",
>  	.prcm		= {
>  		.omap4	= {
> @@ -1615,25 +795,10 @@ static struct omap_hwmod am33xx_spi0_hwmod = {
>  };
> 
>  /* spi1 */
> -static struct omap_hwmod_irq_info am33xx_spi1_irqs[] = {
> -	{ .irq = 125 + OMAP_INTC_START, },
> -	{ .irq = -1 },
> -};
> -
> -static struct omap_hwmod_dma_info am33xx_mcspi1_edma_reqs[] = {
> -	{ .name = "rx0", .dma_req = 43 },
> -	{ .name = "tx0", .dma_req = 42 },
> -	{ .name = "rx1", .dma_req = 45 },
> -	{ .name = "tx1", .dma_req = 44 },
> -	{ .dma_req = -1 }
> -};
> -
>  static struct omap_hwmod am33xx_spi1_hwmod = {
>  	.name		= "spi1",
>  	.class		= &am33xx_spi_hwmod_class,
>  	.clkdm_name	= "l4ls_clkdm",
> -	.mpu_irqs	= am33xx_spi1_irqs,
> -	.sdma_reqs	= am33xx_mcspi1_edma_reqs,
>  	.main_clk	= "dpll_per_m2_div4_ck",
>  	.prcm		= {
>  		.omap4	= {
> @@ -1699,16 +864,10 @@ static struct omap_hwmod_class
> am33xx_timer1ms_hwmod_class = {
>  	.sysc		= &am33xx_timer1ms_sysc,
>  };
> 
> -static struct omap_hwmod_irq_info am33xx_timer1_irqs[] = {
> -	{ .irq = 67 + OMAP_INTC_START, },
> -	{ .irq = -1 },
> -};
> -
>  static struct omap_hwmod am33xx_timer1_hwmod = {
>  	.name		= "timer1",
>  	.class		= &am33xx_timer1ms_hwmod_class,
>  	.clkdm_name	= "l4_wkup_clkdm",
> -	.mpu_irqs	= am33xx_timer1_irqs,
>  	.main_clk	= "timer1_fck",
>  	.prcm		= {
>  		.omap4	= {
> @@ -1718,16 +877,10 @@ static struct omap_hwmod am33xx_timer1_hwmod = {
>  	},
>  };
> 
> -static struct omap_hwmod_irq_info am33xx_timer2_irqs[] = {
> -	{ .irq = 68 + OMAP_INTC_START, },
> -	{ .irq = -1 },
> -};
> -
>  static struct omap_hwmod am33xx_timer2_hwmod = {
>  	.name		= "timer2",
>  	.class		= &am33xx_timer_hwmod_class,
>  	.clkdm_name	= "l4ls_clkdm",
> -	.mpu_irqs	= am33xx_timer2_irqs,
>  	.main_clk	= "timer2_fck",
>  	.prcm		= {
>  		.omap4	= {
> @@ -1737,16 +890,10 @@ static struct omap_hwmod am33xx_timer2_hwmod = {
>  	},
>  };
> 
> -static struct omap_hwmod_irq_info am33xx_timer3_irqs[] = {
> -	{ .irq = 69 + OMAP_INTC_START, },
> -	{ .irq = -1 },
> -};
> -
>  static struct omap_hwmod am33xx_timer3_hwmod = {
>  	.name		= "timer3",
>  	.class		= &am33xx_timer_hwmod_class,
>  	.clkdm_name	= "l4ls_clkdm",
> -	.mpu_irqs	= am33xx_timer3_irqs,
>  	.main_clk	= "timer3_fck",
>  	.prcm		= {
>  		.omap4	= {
> @@ -1756,16 +903,10 @@ static struct omap_hwmod am33xx_timer3_hwmod = {
>  	},
>  };
> 
> -static struct omap_hwmod_irq_info am33xx_timer4_irqs[] = {
> -	{ .irq = 92 + OMAP_INTC_START, },
> -	{ .irq = -1 },
> -};
> -
>  static struct omap_hwmod am33xx_timer4_hwmod = {
>  	.name		= "timer4",
>  	.class		= &am33xx_timer_hwmod_class,
>  	.clkdm_name	= "l4ls_clkdm",
> -	.mpu_irqs	= am33xx_timer4_irqs,
>  	.main_clk	= "timer4_fck",
>  	.prcm		= {
>  		.omap4	= {
> @@ -1775,16 +916,10 @@ static struct omap_hwmod am33xx_timer4_hwmod = {
>  	},
>  };
> 
> -static struct omap_hwmod_irq_info am33xx_timer5_irqs[] = {
> -	{ .irq = 93 + OMAP_INTC_START, },
> -	{ .irq = -1 },
> -};
> -
>  static struct omap_hwmod am33xx_timer5_hwmod = {
>  	.name		= "timer5",
>  	.class		= &am33xx_timer_hwmod_class,
>  	.clkdm_name	= "l4ls_clkdm",
> -	.mpu_irqs	= am33xx_timer5_irqs,
>  	.main_clk	= "timer5_fck",
>  	.prcm		= {
>  		.omap4	= {
> @@ -1794,16 +929,10 @@ static struct omap_hwmod am33xx_timer5_hwmod = {
>  	},
>  };
> 
> -static struct omap_hwmod_irq_info am33xx_timer6_irqs[] = {
> -	{ .irq = 94 + OMAP_INTC_START, },
> -	{ .irq = -1 },
> -};
> -
>  static struct omap_hwmod am33xx_timer6_hwmod = {
>  	.name		= "timer6",
>  	.class		= &am33xx_timer_hwmod_class,
>  	.clkdm_name	= "l4ls_clkdm",
> -	.mpu_irqs	= am33xx_timer6_irqs,
>  	.main_clk	= "timer6_fck",
>  	.prcm		= {
>  		.omap4	= {
> @@ -1813,16 +942,10 @@ static struct omap_hwmod am33xx_timer6_hwmod = {
>  	},
>  };
> 
> -static struct omap_hwmod_irq_info am33xx_timer7_irqs[] = {
> -	{ .irq = 95 + OMAP_INTC_START, },
> -	{ .irq = -1 },
> -};
> -
>  static struct omap_hwmod am33xx_timer7_hwmod = {
>  	.name		= "timer7",
>  	.class		= &am33xx_timer_hwmod_class,
>  	.clkdm_name	= "l4ls_clkdm",
> -	.mpu_irqs	= am33xx_timer7_irqs,
>  	.main_clk	= "timer7_fck",
>  	.prcm		= {
>  		.omap4	= {
> @@ -1837,18 +960,10 @@ static struct omap_hwmod_class
> am33xx_tpcc_hwmod_class = {
>  	.name		= "tpcc",
>  };
> 
> -static struct omap_hwmod_irq_info am33xx_tpcc_irqs[] = {
> -	{ .name	= "edma0", .irq = 12 + OMAP_INTC_START, },
> -	{ .name = "edma0_mperr", .irq = 13 + OMAP_INTC_START, },
> -	{ .name	= "edma0_err", .irq = 14 + OMAP_INTC_START, },
> -	{ .irq = -1 },
> -};
> -
>  static struct omap_hwmod am33xx_tpcc_hwmod = {
>  	.name		= "tpcc",
>  	.class		= &am33xx_tpcc_hwmod_class,
>  	.clkdm_name	= "l3_clkdm",
> -	.mpu_irqs	= am33xx_tpcc_irqs,
>  	.main_clk	= "l3_gclk",
>  	.prcm		= {
>  		.omap4	= {
> @@ -1858,84 +973,6 @@ static struct omap_hwmod am33xx_tpcc_hwmod = {
>  	},
>  };
> 
> -static struct omap_hwmod_class_sysconfig am33xx_tptc_sysc = {
> -	.rev_offs	= 0x0,
> -	.sysc_offs	= 0x10,
> -	.sysc_flags	= (SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET |
> -			  SYSC_HAS_MIDLEMODE),
> -	.idlemodes	= (SIDLE_FORCE | SIDLE_SMART | MSTANDBY_FORCE),
> -	.sysc_fields	= &omap_hwmod_sysc_type2,
> -};
> -
> -/* 'tptc' class */
> -static struct omap_hwmod_class am33xx_tptc_hwmod_class = {
> -	.name		= "tptc",
> -	.sysc		= &am33xx_tptc_sysc,
> -};
> -
> -/* tptc0 */
> -static struct omap_hwmod_irq_info am33xx_tptc0_irqs[] = {
> -	{ .irq = 112 + OMAP_INTC_START, },
> -	{ .irq = -1 },
> -};
> -
> -static struct omap_hwmod am33xx_tptc0_hwmod = {
> -	.name		= "tptc0",
> -	.class		= &am33xx_tptc_hwmod_class,
> -	.clkdm_name	= "l3_clkdm",
> -	.mpu_irqs	= am33xx_tptc0_irqs,
> -	.flags		= HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY,
> -	.main_clk	= "l3_gclk",
> -	.prcm		= {
> -		.omap4	= {
> -			.clkctrl_offs	=
> AM33XX_CM_PER_TPTC0_CLKCTRL_OFFSET,
> -			.modulemode	= MODULEMODE_SWCTRL,
> -		},
> -	},
> -};
> -
> -/* tptc1 */
> -static struct omap_hwmod_irq_info am33xx_tptc1_irqs[] = {
> -	{ .irq = 113 + OMAP_INTC_START, },
> -	{ .irq = -1 },
> -};
> -
> -static struct omap_hwmod am33xx_tptc1_hwmod = {
> -	.name		= "tptc1",
> -	.class		= &am33xx_tptc_hwmod_class,
> -	.clkdm_name	= "l3_clkdm",
> -	.mpu_irqs	= am33xx_tptc1_irqs,
> -	.flags		= (HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY),
> -	.main_clk	= "l3_gclk",
> -	.prcm		= {
> -		.omap4	= {
> -			.clkctrl_offs	=
> AM33XX_CM_PER_TPTC1_CLKCTRL_OFFSET,
> -			.modulemode	= MODULEMODE_SWCTRL,
> -		},
> -	},
> -};
> -
> -/* tptc2 */
> -static struct omap_hwmod_irq_info am33xx_tptc2_irqs[] = {
> -	{ .irq = 114 + OMAP_INTC_START, },
> -	{ .irq = -1 },
> -};
> -
> -static struct omap_hwmod am33xx_tptc2_hwmod = {
> -	.name		= "tptc2",
> -	.class		= &am33xx_tptc_hwmod_class,
> -	.clkdm_name	= "l3_clkdm",
> -	.mpu_irqs	= am33xx_tptc2_irqs,
> -	.flags		= (HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY),
> -	.main_clk	= "l3_gclk",
> -	.prcm		= {
> -		.omap4	= {
> -			.clkctrl_offs	=
> AM33XX_CM_PER_TPTC2_CLKCTRL_OFFSET,
> -			.modulemode	= MODULEMODE_SWCTRL,
> -		},
> -	},
> -};
> -
>  /* 'uart' class */
>  static struct omap_hwmod_class_sysconfig uart_sysc = {
>  	.rev_offs	= 0x50,
> @@ -1954,23 +991,10 @@ static struct omap_hwmod_class uart_class = {
>  };
> 
>  /* uart1 */
> -static struct omap_hwmod_dma_info uart1_edma_reqs[] = {
> -	{ .name = "tx",	.dma_req = 26, },
> -	{ .name = "rx",	.dma_req = 27, },
> -	{ .dma_req = -1 }
> -};
> -
> -static struct omap_hwmod_irq_info am33xx_uart1_irqs[] = {
> -	{ .irq = 72 + OMAP_INTC_START, },
> -	{ .irq = -1 },
> -};
> -
>  static struct omap_hwmod am33xx_uart1_hwmod = {
>  	.name		= "uart1",
>  	.class		= &uart_class,
>  	.clkdm_name	= "l4_wkup_clkdm",
> -	.mpu_irqs	= am33xx_uart1_irqs,
> -	.sdma_reqs	= uart1_edma_reqs,
>  	.main_clk	= "dpll_per_m2_div4_wkupdm_ck",
>  	.prcm		= {
>  		.omap4	= {
> @@ -1980,17 +1004,10 @@ static struct omap_hwmod am33xx_uart1_hwmod = {
>  	},
>  };
> 
> -static struct omap_hwmod_irq_info am33xx_uart2_irqs[] = {
> -	{ .irq = 73 + OMAP_INTC_START, },
> -	{ .irq = -1 },
> -};
> -
>  static struct omap_hwmod am33xx_uart2_hwmod = {
>  	.name		= "uart2",
>  	.class		= &uart_class,
>  	.clkdm_name	= "l4ls_clkdm",
> -	.mpu_irqs	= am33xx_uart2_irqs,
> -	.sdma_reqs	= uart1_edma_reqs,
>  	.main_clk	= "dpll_per_m2_div4_ck",
>  	.prcm		= {
>  		.omap4	= {
> @@ -2001,23 +1018,10 @@ static struct omap_hwmod am33xx_uart2_hwmod = {
>  };
> 
>  /* uart3 */
> -static struct omap_hwmod_dma_info uart3_edma_reqs[] = {
> -	{ .name = "tx",	.dma_req = 30, },
> -	{ .name = "rx",	.dma_req = 31, },
> -	{ .dma_req = -1 }
> -};
> -
> -static struct omap_hwmod_irq_info am33xx_uart3_irqs[] = {
> -	{ .irq = 74 + OMAP_INTC_START, },
> -	{ .irq = -1 },
> -};
> -
>  static struct omap_hwmod am33xx_uart3_hwmod = {
>  	.name		= "uart3",
>  	.class		= &uart_class,
>  	.clkdm_name	= "l4ls_clkdm",
> -	.mpu_irqs	= am33xx_uart3_irqs,
> -	.sdma_reqs	= uart3_edma_reqs,
>  	.main_clk	= "dpll_per_m2_div4_ck",
>  	.prcm		= {
>  		.omap4	= {
> @@ -2027,17 +1031,10 @@ static struct omap_hwmod am33xx_uart3_hwmod = {
>  	},
>  };
> 
> -static struct omap_hwmod_irq_info am33xx_uart4_irqs[] = {
> -	{ .irq = 44 + OMAP_INTC_START, },
> -	{ .irq = -1 },
> -};
> -
>  static struct omap_hwmod am33xx_uart4_hwmod = {
>  	.name		= "uart4",
>  	.class		= &uart_class,
>  	.clkdm_name	= "l4ls_clkdm",
> -	.mpu_irqs	= am33xx_uart4_irqs,
> -	.sdma_reqs	= uart1_edma_reqs,
>  	.main_clk	= "dpll_per_m2_div4_ck",
>  	.prcm		= {
>  		.omap4	= {
> @@ -2047,17 +1044,10 @@ static struct omap_hwmod am33xx_uart4_hwmod = {
>  	},
>  };
> 
> -static struct omap_hwmod_irq_info am33xx_uart5_irqs[] = {
> -	{ .irq = 45 + OMAP_INTC_START, },
> -	{ .irq = -1 },
> -};
> -
>  static struct omap_hwmod am33xx_uart5_hwmod = {
>  	.name		= "uart5",
>  	.class		= &uart_class,
>  	.clkdm_name	= "l4ls_clkdm",
> -	.mpu_irqs	= am33xx_uart5_irqs,
> -	.sdma_reqs	= uart1_edma_reqs,
>  	.main_clk	= "dpll_per_m2_div4_ck",
>  	.prcm		= {
>  		.omap4	= {
> @@ -2067,17 +1057,10 @@ static struct omap_hwmod am33xx_uart5_hwmod = {
>  	},
>  };
> 
> -static struct omap_hwmod_irq_info am33xx_uart6_irqs[] = {
> -	{ .irq = 46 + OMAP_INTC_START, },
> -	{ .irq = -1 },
> -};
> -
>  static struct omap_hwmod am33xx_uart6_hwmod = {
>  	.name		= "uart6",
>  	.class		= &uart_class,
>  	.clkdm_name	= "l4ls_clkdm",
> -	.mpu_irqs	= am33xx_uart6_irqs,
> -	.sdma_reqs	= uart1_edma_reqs,
>  	.main_clk	= "dpll_per_m2_div4_ck",
>  	.prcm		= {
>  		.omap4	= {
> @@ -2123,7 +1106,7 @@ static struct omap_hwmod am33xx_wd_timer1_hwmod =
> {
>  	},
>  };
> 
> -/*
> + /*
>   * 'usb_otg' class
>   * high-speed on-the-go universal serial bus (usb_otg) controller
>   */
> @@ -2141,18 +1124,10 @@ static struct omap_hwmod_class
> am33xx_usbotg_class = {
>  	.sysc		= &am33xx_usbhsotg_sysc,
>  };
> 
> -static struct omap_hwmod_irq_info am33xx_usbss_mpu_irqs[] = {
> -	{ .name = "usbss-irq", .irq = 17 + OMAP_INTC_START, },
> -	{ .name = "musb0-irq", .irq = 18 + OMAP_INTC_START, },
> -	{ .name = "musb1-irq", .irq = 19 + OMAP_INTC_START, },
> -	{ .irq = -1, },
> -};
> -
>  static struct omap_hwmod am33xx_usbss_hwmod = {
>  	.name		= "usb_otg_hs",
>  	.class		= &am33xx_usbotg_class,
>  	.clkdm_name	= "l3s_clkdm",
> -	.mpu_irqs	= am33xx_usbss_mpu_irqs,
>  	.flags		= HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY,
>  	.main_clk	= "usbotg_fck",
>  	.prcm		= {
> @@ -2163,36 +1138,9 @@ static struct omap_hwmod am33xx_usbss_hwmod = {
>  	},
>  };
> 
> -
>  /*
>   * Interfaces
>   */
> -
> -/* l4 fw -> emif fw */
> -static struct omap_hwmod_ocp_if am33xx_l4_fw__emif_fw = {
> -	.master		= &am33xx_l4_fw_hwmod,
> -	.slave		= &am33xx_emif_fw_hwmod,
> -	.clk		= "l4fw_gclk",
> -	.user		= OCP_USER_MPU,
> -};
> -
> -static struct omap_hwmod_addr_space am33xx_emif_addrs[] = {
> -	{
> -		.pa_start	= 0x4c000000,
> -		.pa_end		= 0x4c000fff,
> -		.flags		= ADDR_TYPE_RT
> -	},
> -	{ }
> -};
> -/* l3 main -> emif */
> -static struct omap_hwmod_ocp_if am33xx_l3_main__emif = {
> -	.master		= &am33xx_l3_main_hwmod,
> -	.slave		= &am33xx_emif_hwmod,
> -	.clk		= "dpll_core_m4_ck",
> -	.addr		= am33xx_emif_addrs,
> -	.user		= OCP_USER_MPU | OCP_USER_SDMA,
> -};
> -
>  /* mpu -> l3 main */
>  static struct omap_hwmod_ocp_if am33xx_mpu__l3_main = {
>  	.master		= &am33xx_mpu_hwmod,
> @@ -2233,14 +1181,6 @@ static struct omap_hwmod_ocp_if
> am33xx_l3_s__l4_wkup = {
>  	.user		= OCP_USER_MPU | OCP_USER_SDMA,
>  };
> 
> -/* l3 s -> l4 fw */
> -static struct omap_hwmod_ocp_if am33xx_l3_s__l4_fw = {
> -	.master		= &am33xx_l3_s_hwmod,
> -	.slave		= &am33xx_l4_fw_hwmod,
> -	.clk		= "l3s_gclk",
> -	.user		= OCP_USER_MPU | OCP_USER_SDMA,
> -};
> -
>  /* l3 main -> l3 instr */
>  static struct omap_hwmod_ocp_if am33xx_l3_main__l3_instr = {
>  	.master		= &am33xx_l3_main_hwmod,
> @@ -2290,1154 +1230,277 @@ static struct omap_hwmod_ocp_if
> am33xx_gfx__l3_main = {
>  };
> 
>  /* l4 wkup -> wkup m3 */
> -static struct omap_hwmod_addr_space am33xx_wkup_m3_addrs[] = {
> -	{
> -		.name		= "umem",
> -		.pa_start	= 0x44d00000,
> -		.pa_end		= 0x44d00000 + SZ_16K - 1,
> -		.flags		= ADDR_TYPE_RT
> -	},
> -	{
> -		.name		= "dmem",
> -		.pa_start	= 0x44d80000,
> -		.pa_end		= 0x44d80000 + SZ_8K - 1,
> -		.flags		= ADDR_TYPE_RT
> -	},
> -	{ }
> -};
> -
>  static struct omap_hwmod_ocp_if am33xx_l4_wkup__wkup_m3 = {
>  	.master		= &am33xx_l4_wkup_hwmod,
>  	.slave		= &am33xx_wkup_m3_hwmod,
>  	.clk		= "dpll_core_m4_div2_ck",
> -	.addr		= am33xx_wkup_m3_addrs,
>  	.user		= OCP_USER_MPU | OCP_USER_SDMA,
>  };
> 
>  /* l4 hs -> pru-icss */
> -static struct omap_hwmod_addr_space am33xx_pruss_addrs[] = {
> -	{
> -		.pa_start	= 0x4a300000,
> -		.pa_end		= 0x4a300000 + SZ_512K - 1,
> -		.flags		= ADDR_TYPE_RT
> -	},
> -	{ }
> -};
> -
>  static struct omap_hwmod_ocp_if am33xx_l4_hs__pruss = {
>  	.master		= &am33xx_l4_hs_hwmod,
>  	.slave		= &am33xx_pruss_hwmod,
>  	.clk		= "dpll_core_m4_ck",
> -	.addr		= am33xx_pruss_addrs,
>  	.user		= OCP_USER_MPU | OCP_USER_SDMA,
>  };
> 
>  /* l3 main -> gfx */
> -static struct omap_hwmod_addr_space am33xx_gfx_addrs[] = {
> -	{
> -		.pa_start	= 0x56000000,
> -		.pa_end		= 0x56000000 + SZ_16M - 1,
> -		.flags		= ADDR_TYPE_RT
> -	},
> -	{ }
> -};
> -
>  static struct omap_hwmod_ocp_if am33xx_l3_main__gfx = {
>  	.master		= &am33xx_l3_main_hwmod,
>  	.slave		= &am33xx_gfx_hwmod,
>  	.clk		= "dpll_core_m4_ck",
> -	.addr		= am33xx_gfx_addrs,
>  	.user		= OCP_USER_MPU | OCP_USER_SDMA,
>  };
> 
>  /* l4 wkup -> smartreflex0 */
> -static struct omap_hwmod_addr_space am33xx_smartreflex0_addrs[] = {
> -	{
> -		.pa_start	= 0x44e37000,
> -		.pa_end		= 0x44e37000 + SZ_4K - 1,
> -		.flags		= ADDR_TYPE_RT
> -	},
> -	{ }
> -};
> -
>  static struct omap_hwmod_ocp_if am33xx_l4_wkup__smartreflex0 = {
>  	.master		= &am33xx_l4_wkup_hwmod,
>  	.slave		= &am33xx_smartreflex0_hwmod,
>  	.clk		= "dpll_core_m4_div2_ck",
> -	.addr		= am33xx_smartreflex0_addrs,
>  	.user		= OCP_USER_MPU,
>  };
> 
>  /* l4 wkup -> smartreflex1 */
> -static struct omap_hwmod_addr_space am33xx_smartreflex1_addrs[] = {
> -	{
> -		.pa_start	= 0x44e39000,
> -		.pa_end		= 0x44e39000 + SZ_4K - 1,
> -		.flags		= ADDR_TYPE_RT
> -	},
> -	{ }
> -};
> -
>  static struct omap_hwmod_ocp_if am33xx_l4_wkup__smartreflex1 = {
>  	.master		= &am33xx_l4_wkup_hwmod,
>  	.slave		= &am33xx_smartreflex1_hwmod,
>  	.clk		= "dpll_core_m4_div2_ck",
> -	.addr		= am33xx_smartreflex1_addrs,
>  	.user		= OCP_USER_MPU,
>  };
> 
>  /* l4 wkup -> control */
> -static struct omap_hwmod_addr_space am33xx_control_addrs[] = {
> -	{
> -		.pa_start	= 0x44e10000,
> -		.pa_end		= 0x44e10000 + SZ_8K - 1,
> -		.flags		= ADDR_TYPE_RT
> -	},
> -	{ }
> -};
> -
>  static struct omap_hwmod_ocp_if am33xx_l4_wkup__control = {
>  	.master		= &am33xx_l4_wkup_hwmod,
>  	.slave		= &am33xx_control_hwmod,
>  	.clk		= "dpll_core_m4_div2_ck",
> -	.addr		= am33xx_control_addrs,
>  	.user		= OCP_USER_MPU,
>  };
> 
>  /* l4 wkup -> rtc */
> -static struct omap_hwmod_addr_space am33xx_rtc_addrs[] = {
> -	{
> -		.pa_start	= 0x44e3e000,
> -		.pa_end		= 0x44e3e000 + SZ_4K - 1,
> -		.flags		= ADDR_TYPE_RT
> -	},
> -	{ }
> -};
> -
>  static struct omap_hwmod_ocp_if am33xx_l4_wkup__rtc = {
>  	.master		= &am33xx_l4_wkup_hwmod,
>  	.slave		= &am33xx_rtc_hwmod,
>  	.clk		= "clkdiv32k_ick",
> -	.addr		= am33xx_rtc_addrs,
>  	.user		= OCP_USER_MPU,
>  };
> 
>  /* l4 per/ls -> DCAN0 */
> -static struct omap_hwmod_addr_space am33xx_dcan0_addrs[] = {
> -	{
> -		.pa_start	= 0x481CC000,
> -		.pa_end		= 0x481CC000 + SZ_4K - 1,
> -		.flags		= ADDR_TYPE_RT
> -	},
> -	{ }
> -};
> -
>  static struct omap_hwmod_ocp_if am33xx_l4_per__dcan0 = {
>  	.master		= &am33xx_l4_ls_hwmod,
>  	.slave		= &am33xx_dcan0_hwmod,
>  	.clk		= "l4ls_gclk",
> -	.addr		= am33xx_dcan0_addrs,
>  	.user		= OCP_USER_MPU | OCP_USER_SDMA,
>  };
> 
>  /* l4 per/ls -> DCAN1 */
> -static struct omap_hwmod_addr_space am33xx_dcan1_addrs[] = {
> -	{
> -		.pa_start	= 0x481D0000,
> -		.pa_end		= 0x481D0000 + SZ_4K - 1,
> -		.flags		= ADDR_TYPE_RT
> -	},
> -	{ }
> -};
> -
>  static struct omap_hwmod_ocp_if am33xx_l4_per__dcan1 = {
>  	.master		= &am33xx_l4_ls_hwmod,
>  	.slave		= &am33xx_dcan1_hwmod,
>  	.clk		= "l4ls_gclk",
> -	.addr		= am33xx_dcan1_addrs,
>  	.user		= OCP_USER_MPU | OCP_USER_SDMA,
>  };
> 
>  /* l4 per/ls -> GPIO2 */
> -static struct omap_hwmod_addr_space am33xx_gpio1_addrs[] = {
> -	{
> -		.pa_start	= 0x4804C000,
> -		.pa_end		= 0x4804C000 + SZ_4K - 1,
> -		.flags		= ADDR_TYPE_RT,
> -	},
> -	{ }
> -};
> -
>  static struct omap_hwmod_ocp_if am33xx_l4_per__gpio1 = {
>  	.master		= &am33xx_l4_ls_hwmod,
>  	.slave		= &am33xx_gpio1_hwmod,
>  	.clk		= "l4ls_gclk",
> -	.addr		= am33xx_gpio1_addrs,
>  	.user		= OCP_USER_MPU | OCP_USER_SDMA,
>  };
> 
>  /* l4 per/ls -> gpio3 */
> -static struct omap_hwmod_addr_space am33xx_gpio2_addrs[] = {
> -	{
> -		.pa_start	= 0x481AC000,
> -		.pa_end		= 0x481AC000 + SZ_4K - 1,
> -		.flags		= ADDR_TYPE_RT,
> -	},
> -	{ }
> -};
> -
>  static struct omap_hwmod_ocp_if am33xx_l4_per__gpio2 = {
>  	.master		= &am33xx_l4_ls_hwmod,
>  	.slave		= &am33xx_gpio2_hwmod,
>  	.clk		= "l4ls_gclk",
> -	.addr		= am33xx_gpio2_addrs,
>  	.user		= OCP_USER_MPU | OCP_USER_SDMA,
>  };
> 
>  /* l4 per/ls -> gpio4 */
> -static struct omap_hwmod_addr_space am33xx_gpio3_addrs[] = {
> -	{
> -		.pa_start	= 0x481AE000,
> -		.pa_end		= 0x481AE000 + SZ_4K - 1,
> -		.flags		= ADDR_TYPE_RT,
> -	},
> -	{ }
> -};
> -
>  static struct omap_hwmod_ocp_if am33xx_l4_per__gpio3 = {
>  	.master		= &am33xx_l4_ls_hwmod,
>  	.slave		= &am33xx_gpio3_hwmod,
>  	.clk		= "l4ls_gclk",
> -	.addr		= am33xx_gpio3_addrs,
>  	.user		= OCP_USER_MPU | OCP_USER_SDMA,
>  };
> 
> -/* L4 WKUP -> I2C1 */
> -static struct omap_hwmod_addr_space am33xx_i2c1_addr_space[] = {
> -	{
> -		.pa_start	= 0x44E0B000,
> -		.pa_end		= 0x44E0B000 + SZ_4K - 1,
> -		.flags		= ADDR_TYPE_RT,
> -	},
> -	{ }
> -};
> -
>  static struct omap_hwmod_ocp_if am33xx_l4_wkup__i2c1 = {
>  	.master		= &am33xx_l4_wkup_hwmod,
>  	.slave		= &am33xx_i2c1_hwmod,
>  	.clk		= "dpll_core_m4_div2_ck",
> -	.addr		= am33xx_i2c1_addr_space,
>  	.user		= OCP_USER_MPU,
>  };
> 
>  /* L4 WKUP -> GPIO1 */
> -static struct omap_hwmod_addr_space am33xx_gpio0_addrs[] = {
> -	{
> -		.pa_start	= 0x44E07000,
> -		.pa_end		= 0x44E07000 + SZ_4K - 1,
> -		.flags		= ADDR_TYPE_RT,
> -	},
> -	{ }
> -};
> -
>  static struct omap_hwmod_ocp_if am33xx_l4_wkup__gpio0 = {
>  	.master		= &am33xx_l4_wkup_hwmod,
>  	.slave		= &am33xx_gpio0_hwmod,
>  	.clk		= "dpll_core_m4_div2_ck",
> -	.addr		= am33xx_gpio0_addrs,
>  	.user		= OCP_USER_MPU | OCP_USER_SDMA,
>  };
> 
> -/* L4 WKUP -> ADC_TSC */
> -static struct omap_hwmod_addr_space am33xx_adc_tsc_addrs[] = {
> -	{
> -		.pa_start	= 0x44E0D000,
> -		.pa_end		= 0x44E0D000 + SZ_8K - 1,
> -		.flags		= ADDR_TYPE_RT
> -	},
> -	{ }
> -};
> -
> -static struct omap_hwmod_ocp_if am33xx_l4_wkup__adc_tsc = {
> -	.master		= &am33xx_l4_wkup_hwmod,
> -	.slave		= &am33xx_adc_tsc_hwmod,
> -	.clk		= "dpll_core_m4_div2_ck",
> -	.addr		= am33xx_adc_tsc_addrs,
> -	.user		= OCP_USER_MPU,
> -};
> -
> -static struct omap_hwmod_addr_space am33xx_cpgmac0_addr_space[] = {
> -	/* cpsw ss */
> -	{
> -		.pa_start	= 0x4a100000,
> -		.pa_end		= 0x4a100000 + SZ_2K - 1,
> -	},
> -	/* cpsw wr */
> -	{
> -		.pa_start	= 0x4a101200,
> -		.pa_end		= 0x4a101200 + SZ_256 - 1,
> -		.flags		= ADDR_TYPE_RT,
> -	},
> -	{ }
> -};
> -
>  static struct omap_hwmod_ocp_if am33xx_l4_hs__cpgmac0 = {
>  	.master		= &am33xx_l4_hs_hwmod,
>  	.slave		= &am33xx_cpgmac0_hwmod,
>  	.clk		= "cpsw_125mhz_gclk",
> -	.addr		= am33xx_cpgmac0_addr_space,
>  	.user		= OCP_USER_MPU,
>  };
> 
> -static struct omap_hwmod_addr_space am33xx_mdio_addr_space[] = {
> -	{
> -		.pa_start	= 0x4A101000,
> -		.pa_end		= 0x4A101000 + SZ_256 - 1,
> -	},
> -	{ }
> -};
> -
>  static struct omap_hwmod_ocp_if am33xx_cpgmac0__mdio = {
>  	.master		= &am33xx_cpgmac0_hwmod,
>  	.slave		= &am33xx_mdio_hwmod,
> -	.addr		= am33xx_mdio_addr_space,
> -	.user		= OCP_USER_MPU,
> -};
> -
> -static struct omap_hwmod_addr_space am33xx_elm_addr_space[] = {
> -	{
> -		.pa_start	= 0x48080000,
> -		.pa_end		= 0x48080000 + SZ_8K - 1,
> -		.flags		= ADDR_TYPE_RT
> -	},
> -	{ }
> -};
> -
> -static struct omap_hwmod_ocp_if am33xx_l4_ls__elm = {
> -	.master		= &am33xx_l4_ls_hwmod,
> -	.slave		= &am33xx_elm_hwmod,
> -	.clk		= "l4ls_gclk",
> -	.addr		= am33xx_elm_addr_space,
> -	.user		= OCP_USER_MPU,
> -};
> -
> -static struct omap_hwmod_addr_space am33xx_epwmss0_addr_space[] = {
> -	{
> -		.pa_start	= 0x48300000,
> -		.pa_end		= 0x48300000 + SZ_16 - 1,
> -		.flags		= ADDR_TYPE_RT
> -	},
> -	{ }
> -};
> -
> -static struct omap_hwmod_ocp_if am33xx_l4_ls__epwmss0 = {
> -	.master		= &am33xx_l4_ls_hwmod,
> -	.slave		= &am33xx_epwmss0_hwmod,
> -	.clk		= "l4ls_gclk",
> -	.addr		= am33xx_epwmss0_addr_space,
> -	.user		= OCP_USER_MPU,
> -};
> -
> -static struct omap_hwmod_addr_space am33xx_ecap0_addr_space[] = {
> -	{
> -		.pa_start	= 0x48300100,
> -		.pa_end		= 0x48300100 + SZ_128 - 1,
> -	},
> -	{ }
> -};
> -
> -static struct omap_hwmod_ocp_if am33xx_epwmss0__ecap0 = {
> -	.master		= &am33xx_epwmss0_hwmod,
> -	.slave		= &am33xx_ecap0_hwmod,
> -	.clk		= "l4ls_gclk",
> -	.addr		= am33xx_ecap0_addr_space,
>  	.user		= OCP_USER_MPU,
>  };
> 
> -static struct omap_hwmod_addr_space am33xx_eqep0_addr_space[] = {
> -	{
> -		.pa_start	= 0x48300180,
> -		.pa_end		= 0x48300180 + SZ_128 - 1,
> -	},
> -	{ }
> -};
> -
> -static struct omap_hwmod_ocp_if am33xx_epwmss0__eqep0 = {
> -	.master		= &am33xx_epwmss0_hwmod,
> -	.slave		= &am33xx_eqep0_hwmod,
> -	.clk		= "l4ls_gclk",
> -	.addr		= am33xx_eqep0_addr_space,
> -	.user		= OCP_USER_MPU,
> -};
> -
> -static struct omap_hwmod_addr_space am33xx_ehrpwm0_addr_space[] = {
> -	{
> -		.pa_start	= 0x48300200,
> -		.pa_end		= 0x48300200 + SZ_128 - 1,
> -	},
> -	{ }
> -};
> -
> -static struct omap_hwmod_ocp_if am33xx_epwmss0__ehrpwm0 = {
> -	.master		= &am33xx_epwmss0_hwmod,
> -	.slave		= &am33xx_ehrpwm0_hwmod,
> -	.clk		= "l4ls_gclk",
> -	.addr		= am33xx_ehrpwm0_addr_space,
> -	.user		= OCP_USER_MPU,
> -};
> -
> -
> -static struct omap_hwmod_addr_space am33xx_epwmss1_addr_space[] = {
> -	{
> -		.pa_start	= 0x48302000,
> -		.pa_end		= 0x48302000 + SZ_16 - 1,
> -		.flags		= ADDR_TYPE_RT
> -	},
> -	{ }
> -};
> -
> -static struct omap_hwmod_ocp_if am33xx_l4_ls__epwmss1 = {
> -	.master		= &am33xx_l4_ls_hwmod,
> -	.slave		= &am33xx_epwmss1_hwmod,
> -	.clk		= "l4ls_gclk",
> -	.addr		= am33xx_epwmss1_addr_space,
> -	.user		= OCP_USER_MPU,
> -};
> -
> -static struct omap_hwmod_addr_space am33xx_ecap1_addr_space[] = {
> -	{
> -		.pa_start	= 0x48302100,
> -		.pa_end		= 0x48302100 + SZ_128 - 1,
> -	},
> -	{ }
> -};
> -
> -static struct omap_hwmod_ocp_if am33xx_epwmss1__ecap1 = {
> -	.master		= &am33xx_epwmss1_hwmod,
> -	.slave		= &am33xx_ecap1_hwmod,
> -	.clk		= "l4ls_gclk",
> -	.addr		= am33xx_ecap1_addr_space,
> -	.user		= OCP_USER_MPU,
> -};
> -
> -static struct omap_hwmod_addr_space am33xx_eqep1_addr_space[] = {
> -	{
> -		.pa_start	= 0x48302180,
> -		.pa_end		= 0x48302180 + SZ_128 - 1,
> -	},
> -	{ }
> -};
> -
> -static struct omap_hwmod_ocp_if am33xx_epwmss1__eqep1 = {
> -	.master		= &am33xx_epwmss1_hwmod,
> -	.slave		= &am33xx_eqep1_hwmod,
> -	.clk		= "l4ls_gclk",
> -	.addr		= am33xx_eqep1_addr_space,
> -	.user		= OCP_USER_MPU,
> -};
> -
> -static struct omap_hwmod_addr_space am33xx_ehrpwm1_addr_space[] = {
> -	{
> -		.pa_start	= 0x48302200,
> -		.pa_end		= 0x48302200 + SZ_128 - 1,
> -	},
> -	{ }
> -};
> -
> -static struct omap_hwmod_ocp_if am33xx_epwmss1__ehrpwm1 = {
> -	.master		= &am33xx_epwmss1_hwmod,
> -	.slave		= &am33xx_ehrpwm1_hwmod,
> -	.clk		= "l4ls_gclk",
> -	.addr		= am33xx_ehrpwm1_addr_space,
> -	.user		= OCP_USER_MPU,
> -};
> -
> -static struct omap_hwmod_addr_space am33xx_epwmss2_addr_space[] = {
> -	{
> -		.pa_start	= 0x48304000,
> -		.pa_end		= 0x48304000 + SZ_16 - 1,
> -		.flags		= ADDR_TYPE_RT
> -	},
> -	{ }
> -};
> -
> -static struct omap_hwmod_ocp_if am33xx_l4_ls__epwmss2 = {
> -	.master		= &am33xx_l4_ls_hwmod,
> -	.slave		= &am33xx_epwmss2_hwmod,
> -	.clk		= "l4ls_gclk",
> -	.addr		= am33xx_epwmss2_addr_space,
> -	.user		= OCP_USER_MPU,
> -};
> -
> -static struct omap_hwmod_addr_space am33xx_ecap2_addr_space[] = {
> -	{
> -		.pa_start	= 0x48304100,
> -		.pa_end		= 0x48304100 + SZ_128 - 1,
> -	},
> -	{ }
> -};
> -
> -static struct omap_hwmod_ocp_if am33xx_epwmss2__ecap2 = {
> -	.master		= &am33xx_epwmss2_hwmod,
> -	.slave		= &am33xx_ecap2_hwmod,
> -	.clk		= "l4ls_gclk",
> -	.addr		= am33xx_ecap2_addr_space,
> -	.user		= OCP_USER_MPU,
> -};
> -
> -static struct omap_hwmod_addr_space am33xx_eqep2_addr_space[] = {
> -	{
> -		.pa_start	= 0x48304180,
> -		.pa_end		= 0x48304180 + SZ_128 - 1,
> -	},
> -	{ }
> -};
> -
> -static struct omap_hwmod_ocp_if am33xx_epwmss2__eqep2 = {
> -	.master		= &am33xx_epwmss2_hwmod,
> -	.slave		= &am33xx_eqep2_hwmod,
> -	.clk		= "l4ls_gclk",
> -	.addr		= am33xx_eqep2_addr_space,
> -	.user		= OCP_USER_MPU,
> -};
> -
> -static struct omap_hwmod_addr_space am33xx_ehrpwm2_addr_space[] = {
> -	{
> -		.pa_start	= 0x48304200,
> -		.pa_end		= 0x48304200 + SZ_128 - 1,
> -	},
> -	{ }
> -};
> -
> -static struct omap_hwmod_ocp_if am33xx_epwmss2__ehrpwm2 = {
> -	.master		= &am33xx_epwmss2_hwmod,
> -	.slave		= &am33xx_ehrpwm2_hwmod,
> -	.clk		= "l4ls_gclk",
> -	.addr		= am33xx_ehrpwm2_addr_space,
> -	.user		= OCP_USER_MPU,
> -};
> -
> -/* l3s cfg -> gpmc */
> -static struct omap_hwmod_addr_space am33xx_gpmc_addr_space[] = {
> -	{
> -		.pa_start	= 0x50000000,
> -		.pa_end		= 0x50000000 + SZ_8K - 1,
> -		.flags		= ADDR_TYPE_RT,
> -	},
> -	{ }
> -};
> -
> -static struct omap_hwmod_ocp_if am33xx_l3_s__gpmc = {
> -	.master		= &am33xx_l3_s_hwmod,
> -	.slave		= &am33xx_gpmc_hwmod,
> -	.clk		= "l3s_gclk",
> -	.addr		= am33xx_gpmc_addr_space,
> -	.user		= OCP_USER_MPU,
> -};
> -
> -/* i2c2 */
> -static struct omap_hwmod_addr_space am33xx_i2c2_addr_space[] = {
> -	{
> -		.pa_start	= 0x4802A000,
> -		.pa_end		= 0x4802A000 + SZ_4K - 1,
> -		.flags		= ADDR_TYPE_RT,
> -	},
> -	{ }
> -};
> -
>  static struct omap_hwmod_ocp_if am33xx_l4_per__i2c2 = {
>  	.master		= &am33xx_l4_ls_hwmod,
>  	.slave		= &am33xx_i2c2_hwmod,
>  	.clk		= "l4ls_gclk",
> -	.addr		= am33xx_i2c2_addr_space,
>  	.user		= OCP_USER_MPU,
>  };
> 
> -static struct omap_hwmod_addr_space am33xx_i2c3_addr_space[] = {
> -	{
> -		.pa_start	= 0x4819C000,
> -		.pa_end		= 0x4819C000 + SZ_4K - 1,
> -		.flags		= ADDR_TYPE_RT
> -	},
> -	{ }
> -};
> -
>  static struct omap_hwmod_ocp_if am33xx_l4_per__i2c3 = {
>  	.master		= &am33xx_l4_ls_hwmod,
>  	.slave		= &am33xx_i2c3_hwmod,
>  	.clk		= "l4ls_gclk",
> -	.addr		= am33xx_i2c3_addr_space,
> -	.user		= OCP_USER_MPU,
> -};
> -
> -static struct omap_hwmod_addr_space am33xx_lcdc_addr_space[] = {
> -	{
> -		.pa_start	= 0x4830E000,
> -		.pa_end		= 0x4830E000 + SZ_8K - 1,
> -		.flags		= ADDR_TYPE_RT,
> -	},
> -	{ }
> -};
> -
> -static struct omap_hwmod_ocp_if am33xx_l3_main__lcdc = {
> -	.master		= &am33xx_l3_main_hwmod,
> -	.slave		= &am33xx_lcdc_hwmod,
> -	.clk		= "dpll_core_m4_ck",
> -	.addr		= am33xx_lcdc_addr_space,
> -	.user		= OCP_USER_MPU,
> -};
> -
> -static struct omap_hwmod_addr_space am33xx_mailbox_addrs[] = {
> -	{
> -		.pa_start	= 0x480C8000,
> -		.pa_end		= 0x480C8000 + (SZ_4K - 1),
> -		.flags		= ADDR_TYPE_RT
> -	},
> -	{ }
> -};
> -
> -/* l4 ls -> mailbox */
> -static struct omap_hwmod_ocp_if am33xx_l4_per__mailbox = {
> -	.master		= &am33xx_l4_ls_hwmod,
> -	.slave		= &am33xx_mailbox_hwmod,
> -	.clk		= "l4ls_gclk",
> -	.addr		= am33xx_mailbox_addrs,
>  	.user		= OCP_USER_MPU,
>  };
> 
>  /* l4 ls -> spinlock */
> -static struct omap_hwmod_addr_space am33xx_spinlock_addrs[] = {
> -	{
> -		.pa_start	= 0x480Ca000,
> -		.pa_end		= 0x480Ca000 + SZ_4K - 1,
> -		.flags		= ADDR_TYPE_RT
> -	},
> -	{ }
> -};
> -
>  static struct omap_hwmod_ocp_if am33xx_l4_ls__spinlock = {
>  	.master		= &am33xx_l4_ls_hwmod,
>  	.slave		= &am33xx_spinlock_hwmod,
>  	.clk		= "l4ls_gclk",
> -	.addr		= am33xx_spinlock_addrs,
>  	.user		= OCP_USER_MPU,
>  };
> 
> -/* l4 ls -> mcasp0 */
> -static struct omap_hwmod_addr_space am33xx_mcasp0_addr_space[] = {
> -	{
> -		.pa_start	= 0x48038000,
> -		.pa_end		= 0x48038000 + SZ_8K - 1,
> -		.flags		= ADDR_TYPE_RT
> -	},
> -	{ }
> -};
> -
> -static struct omap_hwmod_ocp_if am33xx_l4_ls__mcasp0 = {
> -	.master		= &am33xx_l4_ls_hwmod,
> -	.slave		= &am33xx_mcasp0_hwmod,
> -	.clk		= "l4ls_gclk",
> -	.addr		= am33xx_mcasp0_addr_space,
> -	.user		= OCP_USER_MPU,
> -};
> -
> -/* l3 s -> mcasp0 data */
> -static struct omap_hwmod_addr_space am33xx_mcasp0_data_addr_space[] =
> {
> -	{
> -		.pa_start	= 0x46000000,
> -		.pa_end		= 0x46000000 + SZ_4M - 1,
> -		.flags		= ADDR_TYPE_RT
> -	},
> -	{ }
> -};
> -
> -static struct omap_hwmod_ocp_if am33xx_l3_s__mcasp0_data = {
> -	.master		= &am33xx_l3_s_hwmod,
> -	.slave		= &am33xx_mcasp0_hwmod,
> -	.clk		= "l3s_gclk",
> -	.addr		= am33xx_mcasp0_data_addr_space,
> -	.user		= OCP_USER_SDMA,
> -};
> -
> -/* l4 ls -> mcasp1 */
> -static struct omap_hwmod_addr_space am33xx_mcasp1_addr_space[] = {
> -	{
> -		.pa_start	= 0x4803C000,
> -		.pa_end		= 0x4803C000 + SZ_8K - 1,
> -		.flags		= ADDR_TYPE_RT
> -	},
> -	{ }
> -};
> -
> -static struct omap_hwmod_ocp_if am33xx_l4_ls__mcasp1 = {
> -	.master		= &am33xx_l4_ls_hwmod,
> -	.slave		= &am33xx_mcasp1_hwmod,
> -	.clk		= "l4ls_gclk",
> -	.addr		= am33xx_mcasp1_addr_space,
> -	.user		= OCP_USER_MPU,
> -};
> -
> -/* l3 s -> mcasp1 data */
> -static struct omap_hwmod_addr_space am33xx_mcasp1_data_addr_space[] =
> {
> -	{
> -		.pa_start	= 0x46400000,
> -		.pa_end		= 0x46400000 + SZ_4M - 1,
> -		.flags		= ADDR_TYPE_RT
> -	},
> -	{ }
> -};
> -
> -static struct omap_hwmod_ocp_if am33xx_l3_s__mcasp1_data = {
> -	.master		= &am33xx_l3_s_hwmod,
> -	.slave		= &am33xx_mcasp1_hwmod,
> -	.clk		= "l3s_gclk",
> -	.addr		= am33xx_mcasp1_data_addr_space,
> -	.user		= OCP_USER_SDMA,
> -};
> -
> -/* l4 ls -> mmc0 */
> -static struct omap_hwmod_addr_space am33xx_mmc0_addr_space[] = {
> -	{
> -		.pa_start	= 0x48060100,
> -		.pa_end		= 0x48060100 + SZ_4K - 1,
> -		.flags		= ADDR_TYPE_RT,
> -	},
> -	{ }
> -};
> -
> -static struct omap_hwmod_ocp_if am33xx_l4_ls__mmc0 = {
> -	.master		= &am33xx_l4_ls_hwmod,
> -	.slave		= &am33xx_mmc0_hwmod,
> -	.clk		= "l4ls_gclk",
> -	.addr		= am33xx_mmc0_addr_space,
> -	.user		= OCP_USER_MPU,
> -};
> -
> -/* l4 ls -> mmc1 */
> -static struct omap_hwmod_addr_space am33xx_mmc1_addr_space[] = {
> -	{
> -		.pa_start	= 0x481d8100,
> -		.pa_end		= 0x481d8100 + SZ_4K - 1,
> -		.flags		= ADDR_TYPE_RT,
> -	},
> -	{ }
> -};
> -
> -static struct omap_hwmod_ocp_if am33xx_l4_ls__mmc1 = {
> -	.master		= &am33xx_l4_ls_hwmod,
> -	.slave		= &am33xx_mmc1_hwmod,
> -	.clk		= "l4ls_gclk",
> -	.addr		= am33xx_mmc1_addr_space,
> -	.user		= OCP_USER_MPU,
> -};
> -
> -/* l3 s -> mmc2 */
> -static struct omap_hwmod_addr_space am33xx_mmc2_addr_space[] = {
> -	{
> -		.pa_start	= 0x47810100,
> -		.pa_end		= 0x47810100 + SZ_64K - 1,
> -		.flags		= ADDR_TYPE_RT,
> -	},
> -	{ }
> -};
> -
> -static struct omap_hwmod_ocp_if am33xx_l3_s__mmc2 = {
> -	.master		= &am33xx_l3_s_hwmod,
> -	.slave		= &am33xx_mmc2_hwmod,
> -	.clk		= "l3s_gclk",
> -	.addr		= am33xx_mmc2_addr_space,
> -	.user		= OCP_USER_MPU,
> -};
> -
> -/* l4 ls -> mcspi0 */
> -static struct omap_hwmod_addr_space am33xx_mcspi0_addr_space[] = {
> -	{
> -		.pa_start	= 0x48030000,
> -		.pa_end		= 0x48030000 + SZ_1K - 1,
> -		.flags		= ADDR_TYPE_RT,
> -	},
> -	{ }
> -};
> -
>  static struct omap_hwmod_ocp_if am33xx_l4_ls__mcspi0 = {
>  	.master		= &am33xx_l4_ls_hwmod,
>  	.slave		= &am33xx_spi0_hwmod,
>  	.clk		= "l4ls_gclk",
> -	.addr		= am33xx_mcspi0_addr_space,
>  	.user		= OCP_USER_MPU,
>  };
> 
> -/* l4 ls -> mcspi1 */
> -static struct omap_hwmod_addr_space am33xx_mcspi1_addr_space[] = {
> -	{
> -		.pa_start	= 0x481A0000,
> -		.pa_end		= 0x481A0000 + SZ_1K - 1,
> -		.flags		= ADDR_TYPE_RT,
> -	},
> -	{ }
> -};
> -
>  static struct omap_hwmod_ocp_if am33xx_l4_ls__mcspi1 = {
>  	.master		= &am33xx_l4_ls_hwmod,
>  	.slave		= &am33xx_spi1_hwmod,
>  	.clk		= "l4ls_gclk",
> -	.addr		= am33xx_mcspi1_addr_space,
>  	.user		= OCP_USER_MPU,
>  };
> 
> -/* l4 wkup -> timer1 */
> -static struct omap_hwmod_addr_space am33xx_timer1_addr_space[] = {
> -	{
> -		.pa_start	= 0x44E31000,
> -		.pa_end		= 0x44E31000 + SZ_1K - 1,
> -		.flags		= ADDR_TYPE_RT
> -	},
> -	{ }
> -};
> -
>  static struct omap_hwmod_ocp_if am33xx_l4_wkup__timer1 = {
>  	.master		= &am33xx_l4_wkup_hwmod,
>  	.slave		= &am33xx_timer1_hwmod,
>  	.clk		= "dpll_core_m4_div2_ck",
> -	.addr		= am33xx_timer1_addr_space,
>  	.user		= OCP_USER_MPU,
>  };
> 
> -/* l4 per -> timer2 */
> -static struct omap_hwmod_addr_space am33xx_timer2_addr_space[] = {
> -	{
> -		.pa_start	= 0x48040000,
> -		.pa_end		= 0x48040000 + SZ_1K - 1,
> -		.flags		= ADDR_TYPE_RT
> -	},
> -	{ }
> -};
> -
>  static struct omap_hwmod_ocp_if am33xx_l4_ls__timer2 = {
>  	.master		= &am33xx_l4_ls_hwmod,
>  	.slave		= &am33xx_timer2_hwmod,
>  	.clk		= "l4ls_gclk",
> -	.addr		= am33xx_timer2_addr_space,
>  	.user		= OCP_USER_MPU,
>  };
> 
> -/* l4 per -> timer3 */
> -static struct omap_hwmod_addr_space am33xx_timer3_addr_space[] = {
> -	{
> -		.pa_start	= 0x48042000,
> -		.pa_end		= 0x48042000 + SZ_1K - 1,
> -		.flags		= ADDR_TYPE_RT
> -	},
> -	{ }
> -};
> -
>  static struct omap_hwmod_ocp_if am33xx_l4_ls__timer3 = {
>  	.master		= &am33xx_l4_ls_hwmod,
>  	.slave		= &am33xx_timer3_hwmod,
>  	.clk		= "l4ls_gclk",
> -	.addr		= am33xx_timer3_addr_space,
>  	.user		= OCP_USER_MPU,
>  };
> 
> -/* l4 per -> timer4 */
> -static struct omap_hwmod_addr_space am33xx_timer4_addr_space[] = {
> -	{
> -		.pa_start	= 0x48044000,
> -		.pa_end		= 0x48044000 + SZ_1K - 1,
> -		.flags		= ADDR_TYPE_RT
> -	},
> -	{ }
> -};
> -
>  static struct omap_hwmod_ocp_if am33xx_l4_ls__timer4 = {
>  	.master		= &am33xx_l4_ls_hwmod,
>  	.slave		= &am33xx_timer4_hwmod,
>  	.clk		= "l4ls_gclk",
> -	.addr		= am33xx_timer4_addr_space,
>  	.user		= OCP_USER_MPU,
>  };
> 
> -/* l4 per -> timer5 */
> -static struct omap_hwmod_addr_space am33xx_timer5_addr_space[] = {
> -	{
> -		.pa_start	= 0x48046000,
> -		.pa_end		= 0x48046000 + SZ_1K - 1,
> -		.flags		= ADDR_TYPE_RT
> -	},
> -	{ }
> -};
> -
>  static struct omap_hwmod_ocp_if am33xx_l4_ls__timer5 = {
>  	.master		= &am33xx_l4_ls_hwmod,
>  	.slave		= &am33xx_timer5_hwmod,
>  	.clk		= "l4ls_gclk",
> -	.addr		= am33xx_timer5_addr_space,
>  	.user		= OCP_USER_MPU,
>  };
> 
> -/* l4 per -> timer6 */
> -static struct omap_hwmod_addr_space am33xx_timer6_addr_space[] = {
> -	{
> -		.pa_start	= 0x48048000,
> -		.pa_end		= 0x48048000 + SZ_1K - 1,
> -		.flags		= ADDR_TYPE_RT
> -	},
> -	{ }
> -};
> -
>  static struct omap_hwmod_ocp_if am33xx_l4_ls__timer6 = {
>  	.master		= &am33xx_l4_ls_hwmod,
>  	.slave		= &am33xx_timer6_hwmod,
>  	.clk		= "l4ls_gclk",
> -	.addr		= am33xx_timer6_addr_space,
>  	.user		= OCP_USER_MPU,
>  };
> 
> -/* l4 per -> timer7 */
> -static struct omap_hwmod_addr_space am33xx_timer7_addr_space[] = {
> -	{
> -		.pa_start	= 0x4804A000,
> -		.pa_end		= 0x4804A000 + SZ_1K - 1,
> -		.flags		= ADDR_TYPE_RT
> -	},
> -	{ }
> -};
> -
>  static struct omap_hwmod_ocp_if am33xx_l4_ls__timer7 = {
>  	.master		= &am33xx_l4_ls_hwmod,
>  	.slave		= &am33xx_timer7_hwmod,
>  	.clk		= "l4ls_gclk",
> -	.addr		= am33xx_timer7_addr_space,
>  	.user		= OCP_USER_MPU,
>  };
> 
> -/* l3 main -> tpcc */
> -static struct omap_hwmod_addr_space am33xx_tpcc_addr_space[] = {
> -	{
> -		.pa_start	= 0x49000000,
> -		.pa_end		= 0x49000000 + SZ_32K - 1,
> -		.flags		= ADDR_TYPE_RT
> -	},
> -	{ }
> -};
> -
>  static struct omap_hwmod_ocp_if am33xx_l3_main__tpcc = {
>  	.master		= &am33xx_l3_main_hwmod,
>  	.slave		= &am33xx_tpcc_hwmod,
>  	.clk		= "l3_gclk",
> -	.addr		= am33xx_tpcc_addr_space,
> -	.user		= OCP_USER_MPU,
> -};
> -
> -/* l3 main -> tpcc0 */
> -static struct omap_hwmod_addr_space am33xx_tptc0_addr_space[] = {
> -	{
> -		.pa_start	= 0x49800000,
> -		.pa_end		= 0x49800000 + SZ_8K - 1,
> -		.flags		= ADDR_TYPE_RT,
> -	},
> -	{ }
> -};
> -
> -static struct omap_hwmod_ocp_if am33xx_l3_main__tptc0 = {
> -	.master		= &am33xx_l3_main_hwmod,
> -	.slave		= &am33xx_tptc0_hwmod,
> -	.clk		= "l3_gclk",
> -	.addr		= am33xx_tptc0_addr_space,
> -	.user		= OCP_USER_MPU,
> -};
> -
> -/* l3 main -> tpcc1 */
> -static struct omap_hwmod_addr_space am33xx_tptc1_addr_space[] = {
> -	{
> -		.pa_start	= 0x49900000,
> -		.pa_end		= 0x49900000 + SZ_8K - 1,
> -		.flags		= ADDR_TYPE_RT,
> -	},
> -	{ }
> -};
> -
> -static struct omap_hwmod_ocp_if am33xx_l3_main__tptc1 = {
> -	.master		= &am33xx_l3_main_hwmod,
> -	.slave		= &am33xx_tptc1_hwmod,
> -	.clk		= "l3_gclk",
> -	.addr		= am33xx_tptc1_addr_space,
>  	.user		= OCP_USER_MPU,
>  };
> 
> -/* l3 main -> tpcc2 */
> -static struct omap_hwmod_addr_space am33xx_tptc2_addr_space[] = {
> -	{
> -		.pa_start	= 0x49a00000,
> -		.pa_end		= 0x49a00000 + SZ_8K - 1,
> -		.flags		= ADDR_TYPE_RT,
> -	},
> -	{ }
> -};
> -
> -static struct omap_hwmod_ocp_if am33xx_l3_main__tptc2 = {
> -	.master		= &am33xx_l3_main_hwmod,
> -	.slave		= &am33xx_tptc2_hwmod,
> -	.clk		= "l3_gclk",
> -	.addr		= am33xx_tptc2_addr_space,
> -	.user		= OCP_USER_MPU,
> -};
> -
> -/* l4 wkup -> uart1 */
> -static struct omap_hwmod_addr_space am33xx_uart1_addr_space[] = {
> -	{
> -		.pa_start	= 0x44E09000,
> -		.pa_end		= 0x44E09000 + SZ_8K - 1,
> -		.flags		= ADDR_TYPE_RT,
> -	},
> -	{ }
> -};
> -
>  static struct omap_hwmod_ocp_if am33xx_l4_wkup__uart1 = {
>  	.master		= &am33xx_l4_wkup_hwmod,
>  	.slave		= &am33xx_uart1_hwmod,
>  	.clk		= "dpll_core_m4_div2_ck",
> -	.addr		= am33xx_uart1_addr_space,
>  	.user		= OCP_USER_MPU,
>  };
> 
> -/* l4 ls -> uart2 */
> -static struct omap_hwmod_addr_space am33xx_uart2_addr_space[] = {
> -	{
> -		.pa_start	= 0x48022000,
> -		.pa_end		= 0x48022000 + SZ_8K - 1,
> -		.flags		= ADDR_TYPE_RT,
> -	},
> -	{ }
> -};
> -
>  static struct omap_hwmod_ocp_if am33xx_l4_ls__uart2 = {
>  	.master		= &am33xx_l4_ls_hwmod,
>  	.slave		= &am33xx_uart2_hwmod,
>  	.clk		= "l4ls_gclk",
> -	.addr		= am33xx_uart2_addr_space,
>  	.user		= OCP_USER_MPU,
>  };
> 
> -/* l4 ls -> uart3 */
> -static struct omap_hwmod_addr_space am33xx_uart3_addr_space[] = {
> -	{
> -		.pa_start	= 0x48024000,
> -		.pa_end		= 0x48024000 + SZ_8K - 1,
> -		.flags		= ADDR_TYPE_RT,
> -	},
> -	{ }
> -};
> -
>  static struct omap_hwmod_ocp_if am33xx_l4_ls__uart3 = {
>  	.master		= &am33xx_l4_ls_hwmod,
>  	.slave		= &am33xx_uart3_hwmod,
>  	.clk		= "l4ls_gclk",
> -	.addr		= am33xx_uart3_addr_space,
>  	.user		= OCP_USER_MPU,
>  };
> 
> -/* l4 ls -> uart4 */
> -static struct omap_hwmod_addr_space am33xx_uart4_addr_space[] = {
> -	{
> -		.pa_start	= 0x481A6000,
> -		.pa_end		= 0x481A6000 + SZ_8K - 1,
> -		.flags		= ADDR_TYPE_RT,
> -	},
> -	{ }
> -};
> -
>  static struct omap_hwmod_ocp_if am33xx_l4_ls__uart4 = {
>  	.master		= &am33xx_l4_ls_hwmod,
>  	.slave		= &am33xx_uart4_hwmod,
>  	.clk		= "l4ls_gclk",
> -	.addr		= am33xx_uart4_addr_space,
>  	.user		= OCP_USER_MPU,
>  };
> 
> -/* l4 ls -> uart5 */
> -static struct omap_hwmod_addr_space am33xx_uart5_addr_space[] = {
> -	{
> -		.pa_start	= 0x481A8000,
> -		.pa_end		= 0x481A8000 + SZ_8K - 1,
> -		.flags		= ADDR_TYPE_RT,
> -	},
> -	{ }
> -};
> -
>  static struct omap_hwmod_ocp_if am33xx_l4_ls__uart5 = {
>  	.master		= &am33xx_l4_ls_hwmod,
>  	.slave		= &am33xx_uart5_hwmod,
>  	.clk		= "l4ls_gclk",
> -	.addr		= am33xx_uart5_addr_space,
>  	.user		= OCP_USER_MPU,
>  };
> 
> -/* l4 ls -> uart6 */
> -static struct omap_hwmod_addr_space am33xx_uart6_addr_space[] = {
> -	{
> -		.pa_start	= 0x481aa000,
> -		.pa_end		= 0x481aa000 + SZ_8K - 1,
> -		.flags		= ADDR_TYPE_RT,
> -	},
> -	{ }
> -};
> -
>  static struct omap_hwmod_ocp_if am33xx_l4_ls__uart6 = {
>  	.master		= &am33xx_l4_ls_hwmod,
>  	.slave		= &am33xx_uart6_hwmod,
>  	.clk		= "l4ls_gclk",
> -	.addr		= am33xx_uart6_addr_space,
>  	.user		= OCP_USER_MPU,
>  };
> 
>  /* l4 wkup -> wd_timer1 */
> -static struct omap_hwmod_addr_space am33xx_wd_timer1_addrs[] = {
> -	{
> -		.pa_start	= 0x44e35000,
> -		.pa_end		= 0x44e35000 + SZ_4K - 1,
> -		.flags		= ADDR_TYPE_RT
> -	},
> -	{ }
> -};
> -
>  static struct omap_hwmod_ocp_if am33xx_l4_wkup__wd_timer1 = {
>  	.master		= &am33xx_l4_wkup_hwmod,
>  	.slave		= &am33xx_wd_timer1_hwmod,
>  	.clk		= "dpll_core_m4_div2_ck",
> -	.addr		= am33xx_wd_timer1_addrs,
>  	.user		= OCP_USER_MPU,
>  };
> 
>  /* usbss */
>  /* l3 s -> USBSS interface */
> -static struct omap_hwmod_addr_space am33xx_usbss_addr_space[] = {
> -	{
> -		.name		= "usbss",
> -		.pa_start	= 0x47400000,
> -		.pa_end		= 0x47400000 + SZ_4K - 1,
> -		.flags		= ADDR_TYPE_RT
> -	},
> -	{
> -		.name		= "musb0",
> -		.pa_start	= 0x47401000,
> -		.pa_end		= 0x47401000 + SZ_2K - 1,
> -		.flags		= ADDR_TYPE_RT
> -	},
> -	{
> -		.name		= "musb1",
> -		.pa_start	= 0x47401800,
> -		.pa_end		= 0x47401800 + SZ_2K - 1,
> -		.flags		= ADDR_TYPE_RT
> -	},
> -	{ }
> -};
> -
>  static struct omap_hwmod_ocp_if am33xx_l3_s__usbss = {
>  	.master		= &am33xx_l3_s_hwmod,
>  	.slave		= &am33xx_usbss_hwmod,
>  	.clk		= "l3s_gclk",
> -	.addr		= am33xx_usbss_addr_space,
>  	.user		= OCP_USER_MPU,
>  	.flags		= OCPIF_SWSUP_IDLE,
>  };
> @@ -3450,13 +1513,10 @@ static struct omap_hwmod_ocp_if
> am33xx_l3_main__ocmc = {
>  };
> 
>  static struct omap_hwmod_ocp_if *am33xx_hwmod_ocp_ifs[] __initdata = {
> -	&am33xx_l4_fw__emif_fw,
> -	&am33xx_l3_main__emif,
>  	&am33xx_mpu__l3_main,
>  	&am33xx_mpu__prcm,
>  	&am33xx_l3_s__l4_ls,
>  	&am33xx_l3_s__l4_wkup,
> -	&am33xx_l3_s__l4_fw,
>  	&am33xx_l3_main__l4_hs,
>  	&am33xx_l3_main__l3_s,
>  	&am33xx_l3_main__l3_instr,
> @@ -3474,7 +1534,6 @@ static struct omap_hwmod_ocp_if
> *am33xx_hwmod_ocp_ifs[] __initdata = {
>  	&am33xx_l4_wkup__rtc,
>  	&am33xx_l4_wkup__i2c1,
>  	&am33xx_l4_wkup__gpio0,
> -	&am33xx_l4_wkup__adc_tsc,
>  	&am33xx_l4_wkup__wd_timer1,
>  	&am33xx_l4_hs__pruss,
>  	&am33xx_l4_per__dcan0,
> @@ -3484,14 +1543,6 @@ static struct omap_hwmod_ocp_if
> *am33xx_hwmod_ocp_ifs[] __initdata = {
>  	&am33xx_l4_per__gpio3,
>  	&am33xx_l4_per__i2c2,
>  	&am33xx_l4_per__i2c3,
> -	&am33xx_l4_per__mailbox,
> -	&am33xx_l4_ls__mcasp0,
> -	&am33xx_l3_s__mcasp0_data,
> -	&am33xx_l4_ls__mcasp1,
> -	&am33xx_l3_s__mcasp1_data,
> -	&am33xx_l4_ls__mmc0,
> -	&am33xx_l4_ls__mmc1,
> -	&am33xx_l3_s__mmc2,
>  	&am33xx_l4_ls__timer2,
>  	&am33xx_l4_ls__timer3,
>  	&am33xx_l4_ls__timer4,
> @@ -3505,26 +1556,8 @@ static struct omap_hwmod_ocp_if
> *am33xx_hwmod_ocp_ifs[] __initdata = {
>  	&am33xx_l4_ls__uart5,
>  	&am33xx_l4_ls__uart6,
>  	&am33xx_l4_ls__spinlock,
> -	&am33xx_l4_ls__elm,
> -	&am33xx_l4_ls__epwmss0,
> -	&am33xx_epwmss0__ecap0,
> -	&am33xx_epwmss0__eqep0,
> -	&am33xx_epwmss0__ehrpwm0,
> -	&am33xx_l4_ls__epwmss1,
> -	&am33xx_epwmss1__ecap1,
> -	&am33xx_epwmss1__eqep1,
> -	&am33xx_epwmss1__ehrpwm1,
> -	&am33xx_l4_ls__epwmss2,
> -	&am33xx_epwmss2__ecap2,
> -	&am33xx_epwmss2__eqep2,
> -	&am33xx_epwmss2__ehrpwm2,
> -	&am33xx_l3_s__gpmc,
> -	&am33xx_l3_main__lcdc,
>  	&am33xx_l4_ls__mcspi0,
>  	&am33xx_l4_ls__mcspi1,
> -	&am33xx_l3_main__tptc0,
> -	&am33xx_l3_main__tptc1,
> -	&am33xx_l3_main__tptc2,
>  	&am33xx_l3_main__ocmc,
>  	&am33xx_l3_s__usbss,
>  	&am33xx_l4_hs__cpgmac0,
> --
> 1.7.9.5



From mans at mansr.com  Wed Apr 10 07:18:19 2013
From: mans at mansr.com (=?iso-8859-1?Q?M=E5ns_Rullg=E5rd?=)
Date: Wed, 10 Apr 2013 12:18:19 +0100
Subject: Removal of NWFPE in its entirety, and VFP emulation code
In-Reply-To: <20130410104002.GF14496@n2100.arm.linux.org.uk> (Russell King's
 message of "Wed, 10 Apr 2013 11:40:02 +0100")
References: <20130410104002.GF14496@n2100.arm.linux.org.uk>
Message-ID: <yw1xmwt68whw.fsf@unicorn.mansr.com>

Russell King - ARM Linux <linux at arm.linux.org.uk> writes:

> The situation with VFP is likely less disruptive - only instructions
> which aren't implemented in hardware (or, for example, if you ask for
> inexact exceptions to be enabled) which are bounced to the software
> support code will be affected.  I think OMAP should get away unscathed,
> but ARM's implementation will bounce if inexact exceptions are enabled

What do you mean by this?  OMAP uses ARM's cores.

> or in a few corner cases.  Qualcomm is likely to be the worst affected
> by this.
>
> Will Deacon has tested debian armhf on a Cortex-A15 with VFP emulation
> support removed, which boots successfully.

Cortex-A9 and later lack hardware support for VFP vector operations.
Any code using these will fail to run without the software emulation.
Of course such code is already horribly slow on these cores and should
be fixed, so perhaps this is not such a terrible thing.

-- 
M?ns Rullg?rd
mans at mansr.com


From hvaibhav at ti.com  Wed Apr 10 07:23:18 2013
From: hvaibhav at ti.com (Hiremath, Vaibhav)
Date: Wed, 10 Apr 2013 11:23:18 +0000
Subject: [GIT PULL] ARM: OMAP5: hwmod, prm/cm data files and updates for
 3.10
References: <1363768852-18125-1-git-send-email-santosh.shilimkar@ti.com>
 <20130401170539.GK10155@atomide.com> <515BA76D.3000302@ti.com>
 <alpine.DEB.2.00.1304031146230.2616@utopia.booyaka.com>
 <515D6020.2030103@ti.com> <20130404165208.GI10155@atomide.com>
 <515DB110.9000503@ti.com> <515F00B8.3000501@ti.com> 
Message-ID: <79CD15C6BA57404B839C016229A409A83EC4A83F@DBDE01.ent.ti.com>

> -----Original Message-----
> From: Hiremath, Vaibhav
> Sent: Wednesday, April 10, 2013 4:45 PM
> To: Shilimkar, Santosh; Tony Lindgren
> Cc: Paul Walmsley; linux-omap at vger.kernel.org; linux-arm-
> kernel at lists.infradead.org; Kristo, Tero; Menon, Nishanth; Nayak,
> Rajendra; Valentin, Eduardo; Anna, Suman; Bedia, Vaibhav
> Subject: RE: [GIT PULL] ARM: OMAP5: hwmod, prm/cm data files and
> updates for 3.10
> 
> > -----Original Message-----
> > From: Shilimkar, Santosh
> > Sent: Friday, April 05, 2013 10:20 PM
> > To: Tony Lindgren
> > Cc: Paul Walmsley; linux-omap at vger.kernel.org; linux-arm-
> > kernel at lists.infradead.org; Kristo, Tero; Menon, Nishanth; Nayak,
> > Rajendra; Valentin, Eduardo; Anna, Suman; Bedia, Vaibhav; Hiremath,
> > Vaibhav
> > Subject: Re: [GIT PULL] ARM: OMAP5: hwmod, prm/cm data files and
> > updates for 3.10
> >
> > On Thursday 04 April 2013 10:27 PM, Santosh Shilimkar wrote:
> > > On Thursday 04 April 2013 10:22 PM, Tony Lindgren wrote:
> > >> * Santosh Shilimkar <santosh.shilimkar at ti.com> [130404 04:15]:
> > [..]
> >
> > >> Can't we already trim the am33xx hwmod data after your patches for
> > >> v3.10 as am33xx is already DT only? Unfortunately we cannot create
> > >> negative diffstat in other ways for v3.10 merge window as we
> cannot
> > >> make omap4 DT only just quite yet.
> > >>
> > > Yes we can and I can take a stab it tomorrow. The only thing is I
> > > might need some support for testing but thats manageable. Will
> > > take a stab at it tomorrow and if everything goes well, post a
> > > patch for smae.
> > >
> > Patch for the AM33XX to trim is end of the email. Thanks to
> > Sricharan and Pekon for patch and testing. Looping both
> > Vaibhav's if they have any objection on the patch.
> >
> > Regards,
> > Santosh
> >
> > From b95dd33fe59b8e77727eb3b1717d763bbf9a2893 Mon Sep 17 00:00:00
> 2001
> > From: Sricharan R <r.sricharan at ti.com>
> > Date: Fri, 5 Apr 2013 20:39:12 +0530
> > Subject: [PATCH] ARM: AM33XX: hwmod data: Clean up the data file
> >
> > - The IO resource information like dma request lines, irq number and
> > ocp address space can be populated via dt blob. So such data can be
> > stripped
> > from SOC hwmod data file.
> >
> > - The devices like adc, mailbox, gpmc which are missing the device
> > tree bindings, hwmod data is not added since AM33XX is DT only build.
> > When such devices add the dt bindings, respective hwmod data can be
> > added along with it.
> >
> This seems unnecessary churn to me. DT bindings for most of the devices
> which you mentioned above are submitted and are at various stages of
> review
> process.
> 

Hit sent button early, below are the links for the patches which have 
been submitted in the recent past but did not make it due to various
known reasons.

> ADC/TSC:
> 
https://lkml.org/lkml/2013/1/23/722


> GPMC:

http://lkml.indiana.edu/hypermail/linux/kernel/1301.3/00052.html

> 
> PWM:

https://lkml.org/lkml/2012/11/27/120


> 
> 
> > - The hwmod like firewall etc which are not useful are also dropped.
> >
> > This gets us around ~2000 loc of negative diff. Patch is boot tested
> on
> > AM335X EVM.
> >
> I would not recommend to get into unnecessary code churn in the future
> just
> to reduce temp Number of Lines of code. This will also kill our
> autogeneration
> concept as well.
> 
> I would suggest you to just alone drop base-addr, irq and dma
> references
> from hwmod entries.
> 
> Thanks,
> Vaibhav
> 
> > Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
> > Signed-off-by: Sricharan R <r.sricharan at ti.com>
> > ---
> > Patch has to be based of the dt branch and recent cleanups which are
> > already in 3.10 queue. The patch also can be found on my git tree.
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux.git
> > for_3.10/am33xx_hwmod_cleanup
> >
> >  arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 1993 +-----------------
> --
> > --------
> >  1 file changed, 13 insertions(+), 1980 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
> > b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
> > index 31bea1c..19a35e8 100644
> > --- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
> > +++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
> > @@ -35,63 +35,6 @@
> >   */
> >
> >  /*
> > - * 'emif_fw' class
> > - * instance(s): emif_fw
> > - */
> > -static struct omap_hwmod_class am33xx_emif_fw_hwmod_class = {
> > -	.name		= "emif_fw",
> > -};
> > -
> > -/* emif_fw */
> > -static struct omap_hwmod am33xx_emif_fw_hwmod = {
> > -	.name		= "emif_fw",
> > -	.class		= &am33xx_emif_fw_hwmod_class,
> > -	.clkdm_name	= "l4fw_clkdm",
> > -	.main_clk	= "l4fw_gclk",
> > -	.flags		= (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET),
> > -	.prcm		= {
> > -		.omap4	= {
> > -			.clkctrl_offs	=
> > AM33XX_CM_PER_EMIF_FW_CLKCTRL_OFFSET,
> > -			.modulemode	= MODULEMODE_SWCTRL,
> > -		},
> > -	},
> > -};
> > -
> > -/*
> > - * 'emif' class
> > - * instance(s): emif
> > - */
> > -static struct omap_hwmod_class_sysconfig am33xx_emif_sysc = {
> > -	.rev_offs	= 0x0000,
> > -};
> > -
> > -static struct omap_hwmod_class am33xx_emif_hwmod_class = {
> > -	.name		= "emif",
> > -	.sysc		= &am33xx_emif_sysc,
> > -};
> > -
> > -static struct omap_hwmod_irq_info am33xx_emif_irqs[] = {
> > -	{ .name = "ddrerr0", .irq = 101 + OMAP_INTC_START, },
> > -	{ .irq = -1 },
> > -};
> > -
> > -/* emif */
> > -static struct omap_hwmod am33xx_emif_hwmod = {
> > -	.name		= "emif",
> > -	.class		= &am33xx_emif_hwmod_class,
> > -	.clkdm_name	= "l3_clkdm",
> > -	.flags		= (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET),
> > -	.mpu_irqs	= am33xx_emif_irqs,
> > -	.main_clk	= "dpll_ddr_m2_div2_ck",
> > -	.prcm		= {
> > -		.omap4	= {
> > -			.clkctrl_offs	=
> > AM33XX_CM_PER_EMIF_CLKCTRL_OFFSET,
> > -			.modulemode	= MODULEMODE_SWCTRL,
> > -		},
> > -	},
> > -};
> > -
> > -/*
> >   * 'l3' class
> >   * instance(s): l3_main, l3_s, l3_instr
> >   */
> > @@ -99,19 +42,11 @@ static struct omap_hwmod_class
> > am33xx_l3_hwmod_class = {
> >  	.name		= "l3",
> >  };
> >
> > -/* l3_main (l3_fast) */
> > -static struct omap_hwmod_irq_info am33xx_l3_main_irqs[] = {
> > -	{ .name = "l3debug", .irq = 9 + OMAP_INTC_START, },
> > -	{ .name = "l3appint", .irq = 10 + OMAP_INTC_START, },
> > -	{ .irq = -1 },
> > -};
> > -
> >  static struct omap_hwmod am33xx_l3_main_hwmod = {
> >  	.name		= "l3_main",
> >  	.class		= &am33xx_l3_hwmod_class,
> >  	.clkdm_name	= "l3_clkdm",
> >  	.flags		= (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET),
> > -	.mpu_irqs	= am33xx_l3_main_irqs,
> >  	.main_clk	= "l3_gclk",
> >  	.prcm		= {
> >  		.omap4	= {
> > @@ -196,20 +131,6 @@ static struct omap_hwmod am33xx_l4_wkup_hwmod =
> {
> >  	},
> >  };
> >
> > -/* l4_fw */
> > -static struct omap_hwmod am33xx_l4_fw_hwmod = {
> > -	.name		= "l4_fw",
> > -	.class		= &am33xx_l4_hwmod_class,
> > -	.clkdm_name	= "l4fw_clkdm",
> > -	.flags		= (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET),
> > -	.prcm		= {
> > -		.omap4	= {
> > -			.clkctrl_offs	=
> > AM33XX_CM_PER_L4FW_CLKCTRL_OFFSET,
> > -			.modulemode	= MODULEMODE_SWCTRL,
> > -		},
> > -	},
> > -};
> > -
> >  /*
> >   * 'mpu' class
> >   */
> > @@ -217,21 +138,11 @@ static struct omap_hwmod_class
> > am33xx_mpu_hwmod_class = {
> >  	.name	= "mpu",
> >  };
> >
> > -/* mpu */
> > -static struct omap_hwmod_irq_info am33xx_mpu_irqs[] = {
> > -	{ .name = "emuint", .irq = 0 + OMAP_INTC_START, },
> > -	{ .name = "commtx", .irq = 1 + OMAP_INTC_START, },
> > -	{ .name = "commrx", .irq = 2 + OMAP_INTC_START, },
> > -	{ .name = "bench", .irq = 3 + OMAP_INTC_START, },
> > -	{ .irq = -1 },
> > -};
> > -
> >  static struct omap_hwmod am33xx_mpu_hwmod = {
> >  	.name		= "mpu",
> >  	.class		= &am33xx_mpu_hwmod_class,
> >  	.clkdm_name	= "mpu_clkdm",
> >  	.flags		= (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET),
> > -	.mpu_irqs	= am33xx_mpu_irqs,
> >  	.main_clk	= "dpll_mpu_m2_ck",
> >  	.prcm		= {
> >  		.omap4	= {
> > @@ -253,11 +164,6 @@ static struct omap_hwmod_rst_info
> > am33xx_wkup_m3_resets[] = {
> >  	{ .name = "wkup_m3", .rst_shift = 3, .st_shift = 5 },
> >  };
> >
> > -static struct omap_hwmod_irq_info am33xx_wkup_m3_irqs[] = {
> > -	{ .name = "txev", .irq = 78 + OMAP_INTC_START, },
> > -	{ .irq = -1 },
> > -};
> > -
> >  /* wkup_m3  */
> >  static struct omap_hwmod am33xx_wkup_m3_hwmod = {
> >  	.name		= "wkup_m3",
> > @@ -265,7 +171,6 @@ static struct omap_hwmod am33xx_wkup_m3_hwmod = {
> >  	.clkdm_name	= "l4_wkup_aon_clkdm",
> >  	/* Keep hardreset asserted */
> >  	.flags		= HWMOD_INIT_NO_RESET | HWMOD_NO_IDLEST,
> > -	.mpu_irqs	= am33xx_wkup_m3_irqs,
> >  	.main_clk	= "dpll_core_m4_div2_ck",
> >  	.prcm		= {
> >  		.omap4	= {
> > @@ -291,25 +196,12 @@ static struct omap_hwmod_rst_info
> > am33xx_pruss_resets[] = {
> >  	{ .name = "pruss", .rst_shift = 1 },
> >  };
> >
> > -static struct omap_hwmod_irq_info am33xx_pruss_irqs[] = {
> > -	{ .name = "evtout0", .irq = 20 + OMAP_INTC_START, },
> > -	{ .name = "evtout1", .irq = 21 + OMAP_INTC_START, },
> > -	{ .name = "evtout2", .irq = 22 + OMAP_INTC_START, },
> > -	{ .name = "evtout3", .irq = 23 + OMAP_INTC_START, },
> > -	{ .name = "evtout4", .irq = 24 + OMAP_INTC_START, },
> > -	{ .name = "evtout5", .irq = 25 + OMAP_INTC_START, },
> > -	{ .name = "evtout6", .irq = 26 + OMAP_INTC_START, },
> > -	{ .name = "evtout7", .irq = 27 + OMAP_INTC_START, },
> > -	{ .irq = -1 },
> > -};
> > -
> >  /* pru-icss */
> >  /* Pseudo hwmod for reset control purpose only */
> >  static struct omap_hwmod am33xx_pruss_hwmod = {
> >  	.name		= "pruss",
> >  	.class		= &am33xx_pruss_hwmod_class,
> >  	.clkdm_name	= "pruss_ocp_clkdm",
> > -	.mpu_irqs	= am33xx_pruss_irqs,
> >  	.main_clk	= "pruss_ocp_gclk",
> >  	.prcm		= {
> >  		.omap4	= {
> > @@ -332,16 +224,10 @@ static struct omap_hwmod_rst_info
> > am33xx_gfx_resets[] = {
> >  	{ .name = "gfx", .rst_shift = 0 },
> >  };
> >
> > -static struct omap_hwmod_irq_info am33xx_gfx_irqs[] = {
> > -	{ .name = "gfxint", .irq = 37 + OMAP_INTC_START, },
> > -	{ .irq = -1 },
> > -};
> > -
> >  static struct omap_hwmod am33xx_gfx_hwmod = {
> >  	.name		= "gfx",
> >  	.class		= &am33xx_gfx_hwmod_class,
> >  	.clkdm_name	= "gfx_l3_clkdm",
> > -	.mpu_irqs	= am33xx_gfx_irqs,
> >  	.main_clk	= "gfx_fck_div_ck",
> >  	.prcm		= {
> >  		.omap4	= {
> > @@ -370,43 +256,6 @@ static struct omap_hwmod am33xx_prcm_hwmod = {
> >  };
> >
> >  /*
> > - * 'adc/tsc' class
> > - * TouchScreen Controller (Anolog-To-Digital Converter)
> > - */
> > -static struct omap_hwmod_class_sysconfig am33xx_adc_tsc_sysc = {
> > -	.rev_offs	= 0x00,
> > -	.sysc_offs	= 0x10,
> > -	.sysc_flags	= SYSC_HAS_SIDLEMODE,
> > -	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
> > -			SIDLE_SMART_WKUP),
> > -	.sysc_fields	= &omap_hwmod_sysc_type2,
> > -};
> > -
> > -static struct omap_hwmod_class am33xx_adc_tsc_hwmod_class = {
> > -	.name		= "adc_tsc",
> > -	.sysc		= &am33xx_adc_tsc_sysc,
> > -};
> > -
> > -static struct omap_hwmod_irq_info am33xx_adc_tsc_irqs[] = {
> > -	{ .irq = 16 + OMAP_INTC_START, },
> > -	{ .irq = -1 },
> > -};
> > -
> > -static struct omap_hwmod am33xx_adc_tsc_hwmod = {
> > -	.name		= "adc_tsc",
> > -	.class		= &am33xx_adc_tsc_hwmod_class,
> > -	.clkdm_name	= "l4_wkup_clkdm",
> > -	.mpu_irqs	= am33xx_adc_tsc_irqs,
> > -	.main_clk	= "adc_tsc_fck",
> > -	.prcm		= {
> > -		.omap4	= {
> > -			.clkctrl_offs	=
> > AM33XX_CM_WKUP_ADC_TSC_CLKCTRL_OFFSET,
> > -			.modulemode	= MODULEMODE_SWCTRL,
> > -		},
> > -	},
> > -};
> > -
> > -/*
> >   * Modules omap_hwmod structures
> >   *
> >   * The following IPs are excluded for the moment because:
> > @@ -508,16 +357,10 @@ static struct omap_hwmod_class
> > am33xx_aes_hwmod_class = {
> >  	.name		= "aes",
> >  };
> >
> > -static struct omap_hwmod_irq_info am33xx_aes0_irqs[] = {
> > -	{ .irq = 102 + OMAP_INTC_START, },
> > -	{ .irq = -1 },
> > -};
> > -
> >  static struct omap_hwmod am33xx_aes0_hwmod = {
> >  	.name		= "aes0",
> >  	.class		= &am33xx_aes_hwmod_class,
> >  	.clkdm_name	= "l3_clkdm",
> > -	.mpu_irqs	= am33xx_aes0_irqs,
> >  	.main_clk	= "l3_gclk",
> >  	.prcm		= {
> >  		.omap4	= {
> > @@ -532,16 +375,10 @@ static struct omap_hwmod_class
> > am33xx_sha0_hwmod_class = {
> >  	.name		= "sha0",
> >  };
> >
> > -static struct omap_hwmod_irq_info am33xx_sha0_irqs[] = {
> > -	{ .irq = 108 + OMAP_INTC_START, },
> > -	{ .irq = -1 },
> > -};
> > -
> >  static struct omap_hwmod am33xx_sha0_hwmod = {
> >  	.name		= "sha0",
> >  	.class		= &am33xx_sha0_hwmod_class,
> >  	.clkdm_name	= "l3_clkdm",
> > -	.mpu_irqs	= am33xx_sha0_irqs,
> >  	.main_clk	= "l3_gclk",
> >  	.prcm		= {
> >  		.omap4	= {
> > @@ -577,17 +414,10 @@ static struct omap_hwmod_class
> > am33xx_smartreflex_hwmod_class = {
> >  	.name		= "smartreflex",
> >  };
> >
> > -/* smartreflex0 */
> > -static struct omap_hwmod_irq_info am33xx_smartreflex0_irqs[] = {
> > -	{ .irq = 120 + OMAP_INTC_START, },
> > -	{ .irq = -1 },
> > -};
> > -
> >  static struct omap_hwmod am33xx_smartreflex0_hwmod = {
> >  	.name		= "smartreflex0",
> >  	.class		= &am33xx_smartreflex_hwmod_class,
> >  	.clkdm_name	= "l4_wkup_clkdm",
> > -	.mpu_irqs	= am33xx_smartreflex0_irqs,
> >  	.main_clk	= "smartreflex0_fck",
> >  	.prcm		= {
> >  		.omap4	= {
> > @@ -597,17 +427,10 @@ static struct omap_hwmod
> > am33xx_smartreflex0_hwmod = {
> >  	},
> >  };
> >
> > -/* smartreflex1 */
> > -static struct omap_hwmod_irq_info am33xx_smartreflex1_irqs[] = {
> > -	{ .irq = 121 + OMAP_INTC_START, },
> > -	{ .irq = -1 },
> > -};
> > -
> >  static struct omap_hwmod am33xx_smartreflex1_hwmod = {
> >  	.name		= "smartreflex1",
> >  	.class		= &am33xx_smartreflex_hwmod_class,
> >  	.clkdm_name	= "l4_wkup_clkdm",
> > -	.mpu_irqs	= am33xx_smartreflex1_irqs,
> >  	.main_clk	= "smartreflex1_fck",
> >  	.prcm		= {
> >  		.omap4	= {
> > @@ -624,17 +447,11 @@ static struct omap_hwmod_class
> > am33xx_control_hwmod_class = {
> >  	.name		= "control",
> >  };
> >
> > -static struct omap_hwmod_irq_info am33xx_control_irqs[] = {
> > -	{ .irq = 8 + OMAP_INTC_START, },
> > -	{ .irq = -1 },
> > -};
> > -
> >  static struct omap_hwmod am33xx_control_hwmod = {
> >  	.name		= "control",
> >  	.class		= &am33xx_control_hwmod_class,
> >  	.clkdm_name	= "l4_wkup_clkdm",
> >  	.flags		= (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET),
> > -	.mpu_irqs	= am33xx_control_irqs,
> >  	.main_clk	= "dpll_core_m4_div2_ck",
> >  	.prcm		= {
> >  		.omap4	= {
> > @@ -664,20 +481,11 @@ static struct omap_hwmod_class
> > am33xx_cpgmac0_hwmod_class = {
> >  	.sysc		= &am33xx_cpgmac_sysc,
> >  };
> >
> > -static struct omap_hwmod_irq_info am33xx_cpgmac0_irqs[] = {
> > -	{ .name = "c0_rx_thresh_pend", .irq = 40 + OMAP_INTC_START, },
> > -	{ .name = "c0_rx_pend", .irq = 41 + OMAP_INTC_START, },
> > -	{ .name = "c0_tx_pend", .irq = 42 + OMAP_INTC_START, },
> > -	{ .name = "c0_misc_pend", .irq = 43 + OMAP_INTC_START, },
> > -	{ .irq = -1 },
> > -};
> > -
> >  static struct omap_hwmod am33xx_cpgmac0_hwmod = {
> >  	.name		= "cpgmac0",
> >  	.class		= &am33xx_cpgmac0_hwmod_class,
> >  	.clkdm_name	= "cpsw_125mhz_clkdm",
> >  	.flags		= (HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY),
> > -	.mpu_irqs	= am33xx_cpgmac0_irqs,
> >  	.main_clk	= "cpsw_125mhz_gclk",
> >  	.prcm		= {
> >  		.omap4	= {
> > @@ -708,18 +516,10 @@ static struct omap_hwmod_class
> > am33xx_dcan_hwmod_class = {
> >  	.name = "d_can",
> >  };
> >
> > -/* dcan0 */
> > -static struct omap_hwmod_irq_info am33xx_dcan0_irqs[] = {
> > -	{ .name = "d_can_ms", .irq = 52 + OMAP_INTC_START, },
> > -	{ .name = "d_can_mo", .irq = 53 + OMAP_INTC_START, },
> > -	{ .irq = -1 },
> > -};
> > -
> >  static struct omap_hwmod am33xx_dcan0_hwmod = {
> >  	.name		= "d_can0",
> >  	.class		= &am33xx_dcan_hwmod_class,
> >  	.clkdm_name	= "l4ls_clkdm",
> > -	.mpu_irqs	= am33xx_dcan0_irqs,
> >  	.main_clk	= "dcan0_fck",
> >  	.prcm		= {
> >  		.omap4	= {
> > @@ -729,17 +529,10 @@ static struct omap_hwmod am33xx_dcan0_hwmod = {
> >  	},
> >  };
> >
> > -/* dcan1 */
> > -static struct omap_hwmod_irq_info am33xx_dcan1_irqs[] = {
> > -	{ .name = "d_can_ms", .irq = 55 + OMAP_INTC_START, },
> > -	{ .name = "d_can_mo", .irq = 56 + OMAP_INTC_START, },
> > -	{ .irq = -1 },
> > -};
> >  static struct omap_hwmod am33xx_dcan1_hwmod = {
> >  	.name		= "d_can1",
> >  	.class		= &am33xx_dcan_hwmod_class,
> >  	.clkdm_name	= "l4ls_clkdm",
> > -	.mpu_irqs	= am33xx_dcan1_irqs,
> >  	.main_clk	= "dcan1_fck",
> >  	.prcm		= {
> >  		.omap4	= {
> > @@ -749,241 +542,6 @@ static struct omap_hwmod am33xx_dcan1_hwmod = {
> >  	},
> >  };
> >
> > -/* elm */
> > -static struct omap_hwmod_class_sysconfig am33xx_elm_sysc = {
> > -	.rev_offs	= 0x0000,
> > -	.sysc_offs	= 0x0010,
> > -	.syss_offs	= 0x0014,
> > -	.sysc_flags	= (SYSC_HAS_CLOCKACTIVITY | SYSC_HAS_SIDLEMODE |
> > -			SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE |
> > -			SYSS_HAS_RESET_STATUS),
> > -	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
> > -	.sysc_fields	= &omap_hwmod_sysc_type1,
> > -};
> > -
> > -static struct omap_hwmod_class am33xx_elm_hwmod_class = {
> > -	.name		= "elm",
> > -	.sysc		= &am33xx_elm_sysc,
> > -};
> > -
> > -static struct omap_hwmod_irq_info am33xx_elm_irqs[] = {
> > -	{ .irq = 4 + OMAP_INTC_START, },
> > -	{ .irq = -1 },
> > -};
> > -
> > -static struct omap_hwmod am33xx_elm_hwmod = {
> > -	.name		= "elm",
> > -	.class		= &am33xx_elm_hwmod_class,
> > -	.clkdm_name	= "l4ls_clkdm",
> > -	.mpu_irqs	= am33xx_elm_irqs,
> > -	.main_clk	= "l4ls_gclk",
> > -	.prcm		= {
> > -		.omap4	= {
> > -			.clkctrl_offs	= AM33XX_CM_PER_ELM_CLKCTRL_OFFSET,
> > -			.modulemode	= MODULEMODE_SWCTRL,
> > -		},
> > -	},
> > -};
> > -
> > -/* pwmss  */
> > -static struct omap_hwmod_class_sysconfig am33xx_epwmss_sysc = {
> > -	.rev_offs	= 0x0,
> > -	.sysc_offs	= 0x4,
> > -	.sysc_flags	= (SYSC_HAS_SIDLEMODE | SYSC_HAS_MIDLEMODE),
> > -	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
> > -			SIDLE_SMART_WKUP | MSTANDBY_FORCE | MSTANDBY_NO |
> > -			MSTANDBY_SMART | MSTANDBY_SMART_WKUP),
> > -	.sysc_fields	= &omap_hwmod_sysc_type2,
> > -};
> > -
> > -static struct omap_hwmod_class am33xx_epwmss_hwmod_class = {
> > -	.name		= "epwmss",
> > -	.sysc		= &am33xx_epwmss_sysc,
> > -};
> > -
> > -static struct omap_hwmod_class am33xx_ecap_hwmod_class = {
> > -	.name		= "ecap",
> > -};
> > -
> > -static struct omap_hwmod_class am33xx_eqep_hwmod_class = {
> > -	.name		= "eqep",
> > -};
> > -
> > -static struct omap_hwmod_class am33xx_ehrpwm_hwmod_class = {
> > -	.name		= "ehrpwm",
> > -};
> > -
> > -/* epwmss0 */
> > -static struct omap_hwmod am33xx_epwmss0_hwmod = {
> > -	.name		= "epwmss0",
> > -	.class		= &am33xx_epwmss_hwmod_class,
> > -	.clkdm_name	= "l4ls_clkdm",
> > -	.main_clk	= "l4ls_gclk",
> > -	.prcm		= {
> > -		.omap4	= {
> > -			.clkctrl_offs	=
> > AM33XX_CM_PER_EPWMSS0_CLKCTRL_OFFSET,
> > -			.modulemode	= MODULEMODE_SWCTRL,
> > -		},
> > -	},
> > -};
> > -
> > -/* ecap0 */
> > -static struct omap_hwmod_irq_info am33xx_ecap0_irqs[] = {
> > -	{ .irq = 31 + OMAP_INTC_START, },
> > -	{ .irq = -1 },
> > -};
> > -
> > -static struct omap_hwmod am33xx_ecap0_hwmod = {
> > -	.name		= "ecap0",
> > -	.class		= &am33xx_ecap_hwmod_class,
> > -	.clkdm_name	= "l4ls_clkdm",
> > -	.mpu_irqs	= am33xx_ecap0_irqs,
> > -	.main_clk	= "l4ls_gclk",
> > -};
> > -
> > -/* eqep0 */
> > -static struct omap_hwmod_irq_info am33xx_eqep0_irqs[] = {
> > -	{ .irq = 79 + OMAP_INTC_START, },
> > -	{ .irq = -1 },
> > -};
> > -
> > -static struct omap_hwmod am33xx_eqep0_hwmod = {
> > -	.name		= "eqep0",
> > -	.class		= &am33xx_eqep_hwmod_class,
> > -	.clkdm_name	= "l4ls_clkdm",
> > -	.mpu_irqs	= am33xx_eqep0_irqs,
> > -	.main_clk	= "l4ls_gclk",
> > -};
> > -
> > -/* ehrpwm0 */
> > -static struct omap_hwmod_irq_info am33xx_ehrpwm0_irqs[] = {
> > -	{ .name = "int", .irq = 86 + OMAP_INTC_START, },
> > -	{ .name = "tzint", .irq = 58 + OMAP_INTC_START, },
> > -	{ .irq = -1 },
> > -};
> > -
> > -static struct omap_hwmod am33xx_ehrpwm0_hwmod = {
> > -	.name		= "ehrpwm0",
> > -	.class		= &am33xx_ehrpwm_hwmod_class,
> > -	.clkdm_name	= "l4ls_clkdm",
> > -	.mpu_irqs	= am33xx_ehrpwm0_irqs,
> > -	.main_clk	= "l4ls_gclk",
> > -};
> > -
> > -/* epwmss1 */
> > -static struct omap_hwmod am33xx_epwmss1_hwmod = {
> > -	.name		= "epwmss1",
> > -	.class		= &am33xx_epwmss_hwmod_class,
> > -	.clkdm_name	= "l4ls_clkdm",
> > -	.main_clk	= "l4ls_gclk",
> > -	.prcm		= {
> > -		.omap4	= {
> > -			.clkctrl_offs	=
> > AM33XX_CM_PER_EPWMSS1_CLKCTRL_OFFSET,
> > -			.modulemode	= MODULEMODE_SWCTRL,
> > -		},
> > -	},
> > -};
> > -
> > -/* ecap1 */
> > -static struct omap_hwmod_irq_info am33xx_ecap1_irqs[] = {
> > -	{ .irq = 47 + OMAP_INTC_START, },
> > -	{ .irq = -1 },
> > -};
> > -
> > -static struct omap_hwmod am33xx_ecap1_hwmod = {
> > -	.name		= "ecap1",
> > -	.class		= &am33xx_ecap_hwmod_class,
> > -	.clkdm_name	= "l4ls_clkdm",
> > -	.mpu_irqs	= am33xx_ecap1_irqs,
> > -	.main_clk	= "l4ls_gclk",
> > -};
> > -
> > -/* eqep1 */
> > -static struct omap_hwmod_irq_info am33xx_eqep1_irqs[] = {
> > -	{ .irq = 88 + OMAP_INTC_START, },
> > -	{ .irq = -1 },
> > -};
> > -
> > -static struct omap_hwmod am33xx_eqep1_hwmod = {
> > -	.name		= "eqep1",
> > -	.class		= &am33xx_eqep_hwmod_class,
> > -	.clkdm_name	= "l4ls_clkdm",
> > -	.mpu_irqs	= am33xx_eqep1_irqs,
> > -	.main_clk	= "l4ls_gclk",
> > -};
> > -
> > -/* ehrpwm1 */
> > -static struct omap_hwmod_irq_info am33xx_ehrpwm1_irqs[] = {
> > -	{ .name = "int", .irq = 87 + OMAP_INTC_START, },
> > -	{ .name = "tzint", .irq = 59 + OMAP_INTC_START, },
> > -	{ .irq = -1 },
> > -};
> > -
> > -static struct omap_hwmod am33xx_ehrpwm1_hwmod = {
> > -	.name		= "ehrpwm1",
> > -	.class		= &am33xx_ehrpwm_hwmod_class,
> > -	.clkdm_name	= "l4ls_clkdm",
> > -	.mpu_irqs	= am33xx_ehrpwm1_irqs,
> > -	.main_clk	= "l4ls_gclk",
> > -};
> > -
> > -/* epwmss2 */
> > -static struct omap_hwmod am33xx_epwmss2_hwmod = {
> > -	.name		= "epwmss2",
> > -	.class		= &am33xx_epwmss_hwmod_class,
> > -	.clkdm_name	= "l4ls_clkdm",
> > -	.main_clk	= "l4ls_gclk",
> > -	.prcm		= {
> > -		.omap4	= {
> > -			.clkctrl_offs	=
> > AM33XX_CM_PER_EPWMSS2_CLKCTRL_OFFSET,
> > -			.modulemode	= MODULEMODE_SWCTRL,
> > -		},
> > -	},
> > -};
> > -
> > -/* ecap2 */
> > -static struct omap_hwmod_irq_info am33xx_ecap2_irqs[] = {
> > -	{ .irq = 61 + OMAP_INTC_START, },
> > -	{ .irq = -1 },
> > -};
> > -
> > -static struct omap_hwmod am33xx_ecap2_hwmod = {
> > -	.name		= "ecap2",
> > -	.class		= &am33xx_ecap_hwmod_class,
> > -	.clkdm_name	= "l4ls_clkdm",
> > -	.mpu_irqs	= am33xx_ecap2_irqs,
> > -	.main_clk	= "l4ls_gclk",
> > -};
> > -
> > -/* eqep2 */
> > -static struct omap_hwmod_irq_info am33xx_eqep2_irqs[] = {
> > -	{ .irq = 89 + OMAP_INTC_START, },
> > -	{ .irq = -1 },
> > -};
> > -
> > -static struct omap_hwmod am33xx_eqep2_hwmod = {
> > -	.name		= "eqep2",
> > -	.class		= &am33xx_eqep_hwmod_class,
> > -	.clkdm_name	= "l4ls_clkdm",
> > -	.mpu_irqs	= am33xx_eqep2_irqs,
> > -	.main_clk	= "l4ls_gclk",
> > -};
> > -
> > -/* ehrpwm2 */
> > -static struct omap_hwmod_irq_info am33xx_ehrpwm2_irqs[] = {
> > -	{ .name = "int", .irq = 39 + OMAP_INTC_START, },
> > -	{ .name = "tzint", .irq = 60 + OMAP_INTC_START, },
> > -	{ .irq = -1 },
> > -};
> > -
> > -static struct omap_hwmod am33xx_ehrpwm2_hwmod = {
> > -	.name		= "ehrpwm2",
> > -	.class		= &am33xx_ehrpwm_hwmod_class,
> > -	.clkdm_name	= "l4ls_clkdm",
> > -	.mpu_irqs	= am33xx_ehrpwm2_irqs,
> > -	.main_clk	= "l4ls_gclk",
> > -};
> > -
> >  /*
> >   * 'gpio' class: for gpio 0,1,2,3
> >   */
> > @@ -1015,17 +573,11 @@ static struct omap_hwmod_opt_clk
> > gpio0_opt_clks[] = {
> >  	{ .role = "dbclk", .clk = "gpio0_dbclk" },
> >  };
> >
> > -static struct omap_hwmod_irq_info am33xx_gpio0_irqs[] = {
> > -	{ .irq = 96 + OMAP_INTC_START, },
> > -	{ .irq = -1 },
> > -};
> > -
> >  static struct omap_hwmod am33xx_gpio0_hwmod = {
> >  	.name		= "gpio1",
> >  	.class		= &am33xx_gpio_hwmod_class,
> >  	.clkdm_name	= "l4_wkup_clkdm",
> >  	.flags		= HWMOD_CONTROL_OPT_CLKS_IN_RESET,
> > -	.mpu_irqs	= am33xx_gpio0_irqs,
> >  	.main_clk	= "dpll_core_m4_div2_ck",
> >  	.prcm		= {
> >  		.omap4	= {
> > @@ -1039,11 +591,6 @@ static struct omap_hwmod am33xx_gpio0_hwmod = {
> >  };
> >
> >  /* gpio1 */
> > -static struct omap_hwmod_irq_info am33xx_gpio1_irqs[] = {
> > -	{ .irq = 98 + OMAP_INTC_START, },
> > -	{ .irq = -1 },
> > -};
> > -
> >  static struct omap_hwmod_opt_clk gpio1_opt_clks[] = {
> >  	{ .role = "dbclk", .clk = "gpio1_dbclk" },
> >  };
> > @@ -1053,7 +600,6 @@ static struct omap_hwmod am33xx_gpio1_hwmod = {
> >  	.class		= &am33xx_gpio_hwmod_class,
> >  	.clkdm_name	= "l4ls_clkdm",
> >  	.flags		= HWMOD_CONTROL_OPT_CLKS_IN_RESET,
> > -	.mpu_irqs	= am33xx_gpio1_irqs,
> >  	.main_clk	= "l4ls_gclk",
> >  	.prcm		= {
> >  		.omap4	= {
> > @@ -1067,11 +613,6 @@ static struct omap_hwmod am33xx_gpio1_hwmod = {
> >  };
> >
> >  /* gpio2 */
> > -static struct omap_hwmod_irq_info am33xx_gpio2_irqs[] = {
> > -	{ .irq = 32 + OMAP_INTC_START, },
> > -	{ .irq = -1 },
> > -};
> > -
> >  static struct omap_hwmod_opt_clk gpio2_opt_clks[] = {
> >  	{ .role = "dbclk", .clk = "gpio2_dbclk" },
> >  };
> > @@ -1081,7 +622,6 @@ static struct omap_hwmod am33xx_gpio2_hwmod = {
> >  	.class		= &am33xx_gpio_hwmod_class,
> >  	.clkdm_name	= "l4ls_clkdm",
> >  	.flags		= HWMOD_CONTROL_OPT_CLKS_IN_RESET,
> > -	.mpu_irqs	= am33xx_gpio2_irqs,
> >  	.main_clk	= "l4ls_gclk",
> >  	.prcm		= {
> >  		.omap4	= {
> > @@ -1095,11 +635,6 @@ static struct omap_hwmod am33xx_gpio2_hwmod = {
> >  };
> >
> >  /* gpio3 */
> > -static struct omap_hwmod_irq_info am33xx_gpio3_irqs[] = {
> > -	{ .irq = 62 + OMAP_INTC_START, },
> > -	{ .irq = -1 },
> > -};
> > -
> >  static struct omap_hwmod_opt_clk gpio3_opt_clks[] = {
> >  	{ .role = "dbclk", .clk = "gpio3_dbclk" },
> >  };
> > @@ -1109,7 +644,6 @@ static struct omap_hwmod am33xx_gpio3_hwmod = {
> >  	.class		= &am33xx_gpio_hwmod_class,
> >  	.clkdm_name	= "l4ls_clkdm",
> >  	.flags		= HWMOD_CONTROL_OPT_CLKS_IN_RESET,
> > -	.mpu_irqs	= am33xx_gpio3_irqs,
> >  	.main_clk	= "l4ls_gclk",
> >  	.prcm		= {
> >  		.omap4	= {
> > @@ -1122,42 +656,6 @@ static struct omap_hwmod am33xx_gpio3_hwmod = {
> >  	.dev_attr	= &gpio_dev_attr,
> >  };
> >
> > -/* gpmc */
> > -static struct omap_hwmod_class_sysconfig gpmc_sysc = {
> > -	.rev_offs	= 0x0,
> > -	.sysc_offs	= 0x10,
> > -	.syss_offs	= 0x14,
> > -	.sysc_flags	= (SYSC_HAS_AUTOIDLE | SYSC_HAS_SIDLEMODE |
> > -			SYSC_HAS_SOFTRESET | SYSS_HAS_RESET_STATUS),
> > -	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
> > -	.sysc_fields	= &omap_hwmod_sysc_type1,
> > -};
> > -
> > -static struct omap_hwmod_class am33xx_gpmc_hwmod_class = {
> > -	.name		= "gpmc",
> > -	.sysc		= &gpmc_sysc,
> > -};
> > -
> > -static struct omap_hwmod_irq_info am33xx_gpmc_irqs[] = {
> > -	{ .irq = 100 + OMAP_INTC_START, },
> > -	{ .irq = -1 },
> > -};
> > -
> > -static struct omap_hwmod am33xx_gpmc_hwmod = {
> > -	.name		= "gpmc",
> > -	.class		= &am33xx_gpmc_hwmod_class,
> > -	.clkdm_name	= "l3s_clkdm",
> > -	.flags		= (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET),
> > -	.mpu_irqs	= am33xx_gpmc_irqs,
> > -	.main_clk	= "l3s_gclk",
> > -	.prcm		= {
> > -		.omap4	= {
> > -			.clkctrl_offs	=
> > AM33XX_CM_PER_GPMC_CLKCTRL_OFFSET,
> > -			.modulemode	= MODULEMODE_SWCTRL,
> > -		},
> > -	},
> > -};
> > -
> >  /* 'i2c' class */
> >  static struct omap_hwmod_class_sysconfig am33xx_i2c_sysc = {
> >  	.sysc_offs	= 0x0010,
> > @@ -1182,23 +680,10 @@ static struct omap_i2c_dev_attr i2c_dev_attr =
> {
> >  };
> >
> >  /* i2c1 */
> > -static struct omap_hwmod_irq_info i2c1_mpu_irqs[] = {
> > -	{ .irq = 70 + OMAP_INTC_START, },
> > -	{ .irq = -1 },
> > -};
> > -
> > -static struct omap_hwmod_dma_info i2c1_edma_reqs[] = {
> > -	{ .name = "tx", .dma_req = 0, },
> > -	{ .name = "rx", .dma_req = 0, },
> > -	{ .dma_req = -1 }
> > -};
> > -
> >  static struct omap_hwmod am33xx_i2c1_hwmod = {
> >  	.name		= "i2c1",
> >  	.class		= &i2c_class,
> >  	.clkdm_name	= "l4_wkup_clkdm",
> > -	.mpu_irqs	= i2c1_mpu_irqs,
> > -	.sdma_reqs	= i2c1_edma_reqs,
> >  	.flags		= HWMOD_16BIT_REG | HWMOD_SET_DEFAULT_CLOCKACT,
> >  	.main_clk	= "dpll_per_m2_div4_wkupdm_ck",
> >  	.prcm		= {
> > @@ -1211,23 +696,10 @@ static struct omap_hwmod am33xx_i2c1_hwmod = {
> >  };
> >
> >  /* i2c1 */
> > -static struct omap_hwmod_irq_info i2c2_mpu_irqs[] = {
> > -	{ .irq = 71 + OMAP_INTC_START, },
> > -	{ .irq = -1 },
> > -};
> > -
> > -static struct omap_hwmod_dma_info i2c2_edma_reqs[] = {
> > -	{ .name = "tx", .dma_req = 0, },
> > -	{ .name = "rx", .dma_req = 0, },
> > -	{ .dma_req = -1 }
> > -};
> > -
> >  static struct omap_hwmod am33xx_i2c2_hwmod = {
> >  	.name		= "i2c2",
> >  	.class		= &i2c_class,
> >  	.clkdm_name	= "l4ls_clkdm",
> > -	.mpu_irqs	= i2c2_mpu_irqs,
> > -	.sdma_reqs	= i2c2_edma_reqs,
> >  	.flags		= HWMOD_16BIT_REG | HWMOD_SET_DEFAULT_CLOCKACT,
> >  	.main_clk	= "dpll_per_m2_div4_ck",
> >  	.prcm		= {
> > @@ -1240,23 +712,10 @@ static struct omap_hwmod am33xx_i2c2_hwmod = {
> >  };
> >
> >  /* i2c3 */
> > -static struct omap_hwmod_dma_info i2c3_edma_reqs[] = {
> > -	{ .name = "tx", .dma_req = 0, },
> > -	{ .name = "rx", .dma_req = 0, },
> > -	{ .dma_req = -1 }
> > -};
> > -
> > -static struct omap_hwmod_irq_info i2c3_mpu_irqs[] = {
> > -	{ .irq = 30 + OMAP_INTC_START, },
> > -	{ .irq = -1 },
> > -};
> > -
> >  static struct omap_hwmod am33xx_i2c3_hwmod = {
> >  	.name		= "i2c3",
> >  	.class		= &i2c_class,
> >  	.clkdm_name	= "l4ls_clkdm",
> > -	.mpu_irqs	= i2c3_mpu_irqs,
> > -	.sdma_reqs	= i2c3_edma_reqs,
> >  	.flags		= HWMOD_16BIT_REG | HWMOD_SET_DEFAULT_CLOCKACT,
> >  	.main_clk	= "dpll_per_m2_div4_ck",
> >  	.prcm		= {
> > @@ -1268,292 +727,28 @@ static struct omap_hwmod am33xx_i2c3_hwmod =
> {
> >  	.dev_attr	= &i2c_dev_attr,
> >  };
> >
> > -
> > -/* lcdc */
> > -static struct omap_hwmod_class_sysconfig lcdc_sysc = {
> > -	.rev_offs	= 0x0,
> > -	.sysc_offs	= 0x54,
> > -	.sysc_flags	= (SYSC_HAS_SIDLEMODE | SYSC_HAS_MIDLEMODE),
> > -	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
> > -	.sysc_fields	= &omap_hwmod_sysc_type2,
> > -};
> > -
> > -static struct omap_hwmod_class am33xx_lcdc_hwmod_class = {
> > -	.name		= "lcdc",
> > -	.sysc		= &lcdc_sysc,
> > -};
> > -
> > -static struct omap_hwmod_irq_info am33xx_lcdc_irqs[] = {
> > -	{ .irq = 36 + OMAP_INTC_START, },
> > -	{ .irq = -1 },
> > -};
> > -
> > -static struct omap_hwmod am33xx_lcdc_hwmod = {
> > -	.name		= "lcdc",
> > -	.class		= &am33xx_lcdc_hwmod_class,
> > -	.clkdm_name	= "lcdc_clkdm",
> > -	.mpu_irqs	= am33xx_lcdc_irqs,
> > -	.flags		= HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY,
> > -	.main_clk	= "lcd_gclk",
> > -	.prcm		= {
> > -		.omap4	= {
> > -			.clkctrl_offs	=
> > AM33XX_CM_PER_LCDC_CLKCTRL_OFFSET,
> > -			.modulemode	= MODULEMODE_SWCTRL,
> > -		},
> > -	},
> > -};
> > -
> > -/*
> > - * 'mailbox' class
> > - * mailbox module allowing communication between the on-chip
> > processors using a
> > - * queued mailbox-interrupt mechanism.
> > - */
> > -static struct omap_hwmod_class_sysconfig am33xx_mailbox_sysc = {
> > -	.rev_offs	= 0x0000,
> > -	.sysc_offs	= 0x0010,
> > -	.sysc_flags	= (SYSC_HAS_RESET_STATUS | SYSC_HAS_SIDLEMODE |
> > -			  SYSC_HAS_SOFTRESET),
> > -	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
> > -	.sysc_fields	= &omap_hwmod_sysc_type2,
> > -};
> > -
> > -static struct omap_hwmod_class am33xx_mailbox_hwmod_class = {
> > -	.name	= "mailbox",
> > -	.sysc	= &am33xx_mailbox_sysc,
> > -};
> > -
> > -static struct omap_hwmod_irq_info am33xx_mailbox_irqs[] = {
> > -	{ .irq = 77 + OMAP_INTC_START, },
> > -	{ .irq = -1 },
> > -};
> > -
> > -static struct omap_hwmod am33xx_mailbox_hwmod = {
> > -	.name		= "mailbox",
> > -	.class		= &am33xx_mailbox_hwmod_class,
> > -	.clkdm_name	= "l4ls_clkdm",
> > -	.mpu_irqs	= am33xx_mailbox_irqs,
> > -	.main_clk	= "l4ls_gclk",
> > -	.prcm = {
> > -		.omap4 = {
> > -			.clkctrl_offs	=
> > AM33XX_CM_PER_MAILBOX0_CLKCTRL_OFFSET,
> > -			.modulemode	= MODULEMODE_SWCTRL,
> > -		},
> > -	},
> > -};
> > -
> > -/*
> > - * 'mcasp' class
> > - */
> > -static struct omap_hwmod_class_sysconfig am33xx_mcasp_sysc = {
> > -	.rev_offs	= 0x0,
> > -	.sysc_offs	= 0x4,
> > -	.sysc_flags	= SYSC_HAS_SIDLEMODE,
> > -	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
> > -	.sysc_fields	= &omap_hwmod_sysc_type3,
> > -};
> > -
> > -static struct omap_hwmod_class am33xx_mcasp_hwmod_class = {
> > -	.name		= "mcasp",
> > -	.sysc		= &am33xx_mcasp_sysc,
> > -};
> > -
> > -/* mcasp0 */
> > -static struct omap_hwmod_irq_info am33xx_mcasp0_irqs[] = {
> > -	{ .name = "ax", .irq = 80 + OMAP_INTC_START, },
> > -	{ .name = "ar", .irq = 81 + OMAP_INTC_START, },
> > -	{ .irq = -1 },
> > -};
> > -
> > -static struct omap_hwmod_dma_info am33xx_mcasp0_edma_reqs[] = {
> > -	{ .name = "tx", .dma_req = 8, },
> > -	{ .name = "rx", .dma_req = 9, },
> > -	{ .dma_req = -1 }
> > -};
> > -
> > -static struct omap_hwmod am33xx_mcasp0_hwmod = {
> > -	.name		= "mcasp0",
> > -	.class		= &am33xx_mcasp_hwmod_class,
> > -	.clkdm_name	= "l3s_clkdm",
> > -	.mpu_irqs	= am33xx_mcasp0_irqs,
> > -	.sdma_reqs	= am33xx_mcasp0_edma_reqs,
> > -	.main_clk	= "mcasp0_fck",
> > -	.prcm		= {
> > -		.omap4	= {
> > -			.clkctrl_offs	=
> > AM33XX_CM_PER_MCASP0_CLKCTRL_OFFSET,
> > -			.modulemode	= MODULEMODE_SWCTRL,
> > -		},
> > -	},
> > -};
> > -
> > -/* mcasp1 */
> > -static struct omap_hwmod_irq_info am33xx_mcasp1_irqs[] = {
> > -	{ .name = "ax", .irq = 82 + OMAP_INTC_START, },
> > -	{ .name = "ar", .irq = 83 + OMAP_INTC_START, },
> > -	{ .irq = -1 },
> > -};
> > -
> > -static struct omap_hwmod_dma_info am33xx_mcasp1_edma_reqs[] = {
> > -	{ .name = "tx", .dma_req = 10, },
> > -	{ .name = "rx", .dma_req = 11, },
> > -	{ .dma_req = -1 }
> > -};
> > -
> > -static struct omap_hwmod am33xx_mcasp1_hwmod = {
> > -	.name		= "mcasp1",
> > -	.class		= &am33xx_mcasp_hwmod_class,
> > -	.clkdm_name	= "l3s_clkdm",
> > -	.mpu_irqs	= am33xx_mcasp1_irqs,
> > -	.sdma_reqs	= am33xx_mcasp1_edma_reqs,
> > -	.main_clk	= "mcasp1_fck",
> > -	.prcm		= {
> > -		.omap4	= {
> > -			.clkctrl_offs	=
> > AM33XX_CM_PER_MCASP1_CLKCTRL_OFFSET,
> > -			.modulemode	= MODULEMODE_SWCTRL,
> > -		},
> > -	},
> > -};
> > -
> > -/* 'mmc' class */
> > -static struct omap_hwmod_class_sysconfig am33xx_mmc_sysc = {
> > -	.rev_offs	= 0x1fc,
> > -	.sysc_offs	= 0x10,
> > -	.syss_offs	= 0x14,
> > -	.sysc_flags	= (SYSC_HAS_CLOCKACTIVITY | SYSC_HAS_SIDLEMODE |
> > -			  SYSC_HAS_ENAWAKEUP | SYSC_HAS_SOFTRESET |
> > -			  SYSC_HAS_AUTOIDLE | SYSS_HAS_RESET_STATUS),
> > -	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
> > -	.sysc_fields	= &omap_hwmod_sysc_type1,
> > -};
> > -
> > -static struct omap_hwmod_class am33xx_mmc_hwmod_class = {
> > -	.name		= "mmc",
> > -	.sysc		= &am33xx_mmc_sysc,
> > -};
> > -
> > -/* mmc0 */
> > -static struct omap_hwmod_irq_info am33xx_mmc0_irqs[] = {
> > -	{ .irq = 64 + OMAP_INTC_START, },
> > -	{ .irq = -1 },
> > -};
> > -
> > -static struct omap_hwmod_dma_info am33xx_mmc0_edma_reqs[] = {
> > -	{ .name = "tx", .dma_req = 24, },
> > -	{ .name = "rx", .dma_req = 25, },
> > -	{ .dma_req = -1 }
> > -};
> > -
> > -static struct omap_mmc_dev_attr am33xx_mmc0_dev_attr = {
> > -	.flags		= OMAP_HSMMC_SUPPORTS_DUAL_VOLT,
> > -};
> > -
> > -static struct omap_hwmod am33xx_mmc0_hwmod = {
> > -	.name		= "mmc1",
> > -	.class		= &am33xx_mmc_hwmod_class,
> > -	.clkdm_name	= "l4ls_clkdm",
> > -	.mpu_irqs	= am33xx_mmc0_irqs,
> > -	.sdma_reqs	= am33xx_mmc0_edma_reqs,
> > -	.main_clk	= "mmc_clk",
> > -	.prcm		= {
> > -		.omap4	= {
> > -			.clkctrl_offs	=
> > AM33XX_CM_PER_MMC0_CLKCTRL_OFFSET,
> > -			.modulemode	= MODULEMODE_SWCTRL,
> > -		},
> > -	},
> > -	.dev_attr	= &am33xx_mmc0_dev_attr,
> > -};
> > -
> > -/* mmc1 */
> > -static struct omap_hwmod_irq_info am33xx_mmc1_irqs[] = {
> > -	{ .irq = 28 + OMAP_INTC_START, },
> > -	{ .irq = -1 },
> > -};
> > -
> > -static struct omap_hwmod_dma_info am33xx_mmc1_edma_reqs[] = {
> > -	{ .name = "tx", .dma_req = 2, },
> > -	{ .name = "rx", .dma_req = 3, },
> > -	{ .dma_req = -1 }
> > -};
> > -
> > -static struct omap_mmc_dev_attr am33xx_mmc1_dev_attr = {
> > -	.flags		= OMAP_HSMMC_SUPPORTS_DUAL_VOLT,
> > -};
> > -
> > -static struct omap_hwmod am33xx_mmc1_hwmod = {
> > -	.name		= "mmc2",
> > -	.class		= &am33xx_mmc_hwmod_class,
> > -	.clkdm_name	= "l4ls_clkdm",
> > -	.mpu_irqs	= am33xx_mmc1_irqs,
> > -	.sdma_reqs	= am33xx_mmc1_edma_reqs,
> > -	.main_clk	= "mmc_clk",
> > -	.prcm		= {
> > -		.omap4	= {
> > -			.clkctrl_offs	=
> > AM33XX_CM_PER_MMC1_CLKCTRL_OFFSET,
> > -			.modulemode	= MODULEMODE_SWCTRL,
> > -		},
> > -	},
> > -	.dev_attr	= &am33xx_mmc1_dev_attr,
> > -};
> > -
> > -/* mmc2 */
> > -static struct omap_hwmod_irq_info am33xx_mmc2_irqs[] = {
> > -	{ .irq = 29 + OMAP_INTC_START, },
> > -	{ .irq = -1 },
> > -};
> > -
> > -static struct omap_hwmod_dma_info am33xx_mmc2_edma_reqs[] = {
> > -	{ .name = "tx", .dma_req = 64, },
> > -	{ .name = "rx", .dma_req = 65, },
> > -	{ .dma_req = -1 }
> > -};
> > -
> > -static struct omap_mmc_dev_attr am33xx_mmc2_dev_attr = {
> > -	.flags		= OMAP_HSMMC_SUPPORTS_DUAL_VOLT,
> > -};
> > -static struct omap_hwmod am33xx_mmc2_hwmod = {
> > -	.name		= "mmc3",
> > -	.class		= &am33xx_mmc_hwmod_class,
> > -	.clkdm_name	= "l3s_clkdm",
> > -	.mpu_irqs	= am33xx_mmc2_irqs,
> > -	.sdma_reqs	= am33xx_mmc2_edma_reqs,
> > -	.main_clk	= "mmc_clk",
> > -	.prcm		= {
> > -		.omap4	= {
> > -			.clkctrl_offs	=
> > AM33XX_CM_PER_MMC2_CLKCTRL_OFFSET,
> > -			.modulemode	= MODULEMODE_SWCTRL,
> > -		},
> > -	},
> > -	.dev_attr	= &am33xx_mmc2_dev_attr,
> > -};
> > -
> > -/*
> > - * 'rtc' class
> > - * rtc subsystem
> > - */
> > -static struct omap_hwmod_class_sysconfig am33xx_rtc_sysc = {
> > -	.rev_offs	= 0x0074,
> > -	.sysc_offs	= 0x0078,
> > -	.sysc_flags	= SYSC_HAS_SIDLEMODE,
> > -	.idlemodes	= (SIDLE_FORCE | SIDLE_NO |
> > -			  SIDLE_SMART | SIDLE_SMART_WKUP),
> > -	.sysc_fields	= &omap_hwmod_sysc_type3,
> > -};
> > +/*
> > + * 'rtc' class
> > + * rtc subsystem
> > + */
> > +static struct omap_hwmod_class_sysconfig am33xx_rtc_sysc = {
> > +	.rev_offs	= 0x0074,
> > +	.sysc_offs	= 0x0078,
> > +	.sysc_flags	= SYSC_HAS_SIDLEMODE,
> > +	.idlemodes	= (SIDLE_FORCE | SIDLE_NO |
> > +			  SIDLE_SMART | SIDLE_SMART_WKUP),
> > +	.sysc_fields	= &omap_hwmod_sysc_type3,
> > +};
> >
> >  static struct omap_hwmod_class am33xx_rtc_hwmod_class = {
> >  	.name		= "rtc",
> >  	.sysc		= &am33xx_rtc_sysc,
> >  };
> >
> > -static struct omap_hwmod_irq_info am33xx_rtc_irqs[] = {
> > -	{ .name = "rtcint", .irq = 75 + OMAP_INTC_START, },
> > -	{ .name = "rtcalarmint", .irq = 76 + OMAP_INTC_START, },
> > -	{ .irq = -1 },
> > -};
> > -
> >  static struct omap_hwmod am33xx_rtc_hwmod = {
> >  	.name		= "rtc",
> >  	.class		= &am33xx_rtc_hwmod_class,
> >  	.clkdm_name	= "l4_rtc_clkdm",
> > -	.mpu_irqs	= am33xx_rtc_irqs,
> >  	.main_clk	= "clk_32768_ck",
> >  	.prcm		= {
> >  		.omap4	= {
> > @@ -1582,19 +777,6 @@ static struct omap_hwmod_class
> > am33xx_spi_hwmod_class = {
> >  };
> >
> >  /* spi0 */
> > -static struct omap_hwmod_irq_info am33xx_spi0_irqs[] = {
> > -	{ .irq = 65 + OMAP_INTC_START, },
> > -	{ .irq = -1 },
> > -};
> > -
> > -static struct omap_hwmod_dma_info am33xx_mcspi0_edma_reqs[] = {
> > -	{ .name = "rx0", .dma_req = 17 },
> > -	{ .name = "tx0", .dma_req = 16 },
> > -	{ .name = "rx1", .dma_req = 19 },
> > -	{ .name = "tx1", .dma_req = 18 },
> > -	{ .dma_req = -1 }
> > -};
> > -
> >  static struct omap2_mcspi_dev_attr mcspi_attrib = {
> >  	.num_chipselect	= 2,
> >  };
> > @@ -1602,8 +784,6 @@ static struct omap_hwmod am33xx_spi0_hwmod = {
> >  	.name		= "spi0",
> >  	.class		= &am33xx_spi_hwmod_class,
> >  	.clkdm_name	= "l4ls_clkdm",
> > -	.mpu_irqs	= am33xx_spi0_irqs,
> > -	.sdma_reqs	= am33xx_mcspi0_edma_reqs,
> >  	.main_clk	= "dpll_per_m2_div4_ck",
> >  	.prcm		= {
> >  		.omap4	= {
> > @@ -1615,25 +795,10 @@ static struct omap_hwmod am33xx_spi0_hwmod = {
> >  };
> >
> >  /* spi1 */
> > -static struct omap_hwmod_irq_info am33xx_spi1_irqs[] = {
> > -	{ .irq = 125 + OMAP_INTC_START, },
> > -	{ .irq = -1 },
> > -};
> > -
> > -static struct omap_hwmod_dma_info am33xx_mcspi1_edma_reqs[] = {
> > -	{ .name = "rx0", .dma_req = 43 },
> > -	{ .name = "tx0", .dma_req = 42 },
> > -	{ .name = "rx1", .dma_req = 45 },
> > -	{ .name = "tx1", .dma_req = 44 },
> > -	{ .dma_req = -1 }
> > -};
> > -
> >  static struct omap_hwmod am33xx_spi1_hwmod = {
> >  	.name		= "spi1",
> >  	.class		= &am33xx_spi_hwmod_class,
> >  	.clkdm_name	= "l4ls_clkdm",
> > -	.mpu_irqs	= am33xx_spi1_irqs,
> > -	.sdma_reqs	= am33xx_mcspi1_edma_reqs,
> >  	.main_clk	= "dpll_per_m2_div4_ck",
> >  	.prcm		= {
> >  		.omap4	= {
> > @@ -1699,16 +864,10 @@ static struct omap_hwmod_class
> > am33xx_timer1ms_hwmod_class = {
> >  	.sysc		= &am33xx_timer1ms_sysc,
> >  };
> >
> > -static struct omap_hwmod_irq_info am33xx_timer1_irqs[] = {
> > -	{ .irq = 67 + OMAP_INTC_START, },
> > -	{ .irq = -1 },
> > -};
> > -
> >  static struct omap_hwmod am33xx_timer1_hwmod = {
> >  	.name		= "timer1",
> >  	.class		= &am33xx_timer1ms_hwmod_class,
> >  	.clkdm_name	= "l4_wkup_clkdm",
> > -	.mpu_irqs	= am33xx_timer1_irqs,
> >  	.main_clk	= "timer1_fck",
> >  	.prcm		= {
> >  		.omap4	= {
> > @@ -1718,16 +877,10 @@ static struct omap_hwmod am33xx_timer1_hwmod =
> {
> >  	},
> >  };
> >
> > -static struct omap_hwmod_irq_info am33xx_timer2_irqs[] = {
> > -	{ .irq = 68 + OMAP_INTC_START, },
> > -	{ .irq = -1 },
> > -};
> > -
> >  static struct omap_hwmod am33xx_timer2_hwmod = {
> >  	.name		= "timer2",
> >  	.class		= &am33xx_timer_hwmod_class,
> >  	.clkdm_name	= "l4ls_clkdm",
> > -	.mpu_irqs	= am33xx_timer2_irqs,
> >  	.main_clk	= "timer2_fck",
> >  	.prcm		= {
> >  		.omap4	= {
> > @@ -1737,16 +890,10 @@ static struct omap_hwmod am33xx_timer2_hwmod =
> {
> >  	},
> >  };
> >
> > -static struct omap_hwmod_irq_info am33xx_timer3_irqs[] = {
> > -	{ .irq = 69 + OMAP_INTC_START, },
> > -	{ .irq = -1 },
> > -};
> > -
> >  static struct omap_hwmod am33xx_timer3_hwmod = {
> >  	.name		= "timer3",
> >  	.class		= &am33xx_timer_hwmod_class,
> >  	.clkdm_name	= "l4ls_clkdm",
> > -	.mpu_irqs	= am33xx_timer3_irqs,
> >  	.main_clk	= "timer3_fck",
> >  	.prcm		= {
> >  		.omap4	= {
> > @@ -1756,16 +903,10 @@ static struct omap_hwmod am33xx_timer3_hwmod =
> {
> >  	},
> >  };
> >
> > -static struct omap_hwmod_irq_info am33xx_timer4_irqs[] = {
> > -	{ .irq = 92 + OMAP_INTC_START, },
> > -	{ .irq = -1 },
> > -};
> > -
> >  static struct omap_hwmod am33xx_timer4_hwmod = {
> >  	.name		= "timer4",
> >  	.class		= &am33xx_timer_hwmod_class,
> >  	.clkdm_name	= "l4ls_clkdm",
> > -	.mpu_irqs	= am33xx_timer4_irqs,
> >  	.main_clk	= "timer4_fck",
> >  	.prcm		= {
> >  		.omap4	= {
> > @@ -1775,16 +916,10 @@ static struct omap_hwmod am33xx_timer4_hwmod =
> {
> >  	},
> >  };
> >
> > -static struct omap_hwmod_irq_info am33xx_timer5_irqs[] = {
> > -	{ .irq = 93 + OMAP_INTC_START, },
> > -	{ .irq = -1 },
> > -};
> > -
> >  static struct omap_hwmod am33xx_timer5_hwmod = {
> >  	.name		= "timer5",
> >  	.class		= &am33xx_timer_hwmod_class,
> >  	.clkdm_name	= "l4ls_clkdm",
> > -	.mpu_irqs	= am33xx_timer5_irqs,
> >  	.main_clk	= "timer5_fck",
> >  	.prcm		= {
> >  		.omap4	= {
> > @@ -1794,16 +929,10 @@ static struct omap_hwmod am33xx_timer5_hwmod =
> {
> >  	},
> >  };
> >
> > -static struct omap_hwmod_irq_info am33xx_timer6_irqs[] = {
> > -	{ .irq = 94 + OMAP_INTC_START, },
> > -	{ .irq = -1 },
> > -};
> > -
> >  static struct omap_hwmod am33xx_timer6_hwmod = {
> >  	.name		= "timer6",
> >  	.class		= &am33xx_timer_hwmod_class,
> >  	.clkdm_name	= "l4ls_clkdm",
> > -	.mpu_irqs	= am33xx_timer6_irqs,
> >  	.main_clk	= "timer6_fck",
> >  	.prcm		= {
> >  		.omap4	= {
> > @@ -1813,16 +942,10 @@ static struct omap_hwmod am33xx_timer6_hwmod =
> {
> >  	},
> >  };
> >
> > -static struct omap_hwmod_irq_info am33xx_timer7_irqs[] = {
> > -	{ .irq = 95 + OMAP_INTC_START, },
> > -	{ .irq = -1 },
> > -};
> > -
> >  static struct omap_hwmod am33xx_timer7_hwmod = {
> >  	.name		= "timer7",
> >  	.class		= &am33xx_timer_hwmod_class,
> >  	.clkdm_name	= "l4ls_clkdm",
> > -	.mpu_irqs	= am33xx_timer7_irqs,
> >  	.main_clk	= "timer7_fck",
> >  	.prcm		= {
> >  		.omap4	= {
> > @@ -1837,18 +960,10 @@ static struct omap_hwmod_class
> > am33xx_tpcc_hwmod_class = {
> >  	.name		= "tpcc",
> >  };
> >
> > -static struct omap_hwmod_irq_info am33xx_tpcc_irqs[] = {
> > -	{ .name	= "edma0", .irq = 12 + OMAP_INTC_START, },
> > -	{ .name = "edma0_mperr", .irq = 13 + OMAP_INTC_START, },
> > -	{ .name	= "edma0_err", .irq = 14 + OMAP_INTC_START, },
> > -	{ .irq = -1 },
> > -};
> > -
> >  static struct omap_hwmod am33xx_tpcc_hwmod = {
> >  	.name		= "tpcc",
> >  	.class		= &am33xx_tpcc_hwmod_class,
> >  	.clkdm_name	= "l3_clkdm",
> > -	.mpu_irqs	= am33xx_tpcc_irqs,
> >  	.main_clk	= "l3_gclk",
> >  	.prcm		= {
> >  		.omap4	= {
> > @@ -1858,84 +973,6 @@ static struct omap_hwmod am33xx_tpcc_hwmod = {
> >  	},
> >  };
> >
> > -static struct omap_hwmod_class_sysconfig am33xx_tptc_sysc = {
> > -	.rev_offs	= 0x0,
> > -	.sysc_offs	= 0x10,
> > -	.sysc_flags	= (SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET |
> > -			  SYSC_HAS_MIDLEMODE),
> > -	.idlemodes	= (SIDLE_FORCE | SIDLE_SMART | MSTANDBY_FORCE),
> > -	.sysc_fields	= &omap_hwmod_sysc_type2,
> > -};
> > -
> > -/* 'tptc' class */
> > -static struct omap_hwmod_class am33xx_tptc_hwmod_class = {
> > -	.name		= "tptc",
> > -	.sysc		= &am33xx_tptc_sysc,
> > -};
> > -
> > -/* tptc0 */
> > -static struct omap_hwmod_irq_info am33xx_tptc0_irqs[] = {
> > -	{ .irq = 112 + OMAP_INTC_START, },
> > -	{ .irq = -1 },
> > -};
> > -
> > -static struct omap_hwmod am33xx_tptc0_hwmod = {
> > -	.name		= "tptc0",
> > -	.class		= &am33xx_tptc_hwmod_class,
> > -	.clkdm_name	= "l3_clkdm",
> > -	.mpu_irqs	= am33xx_tptc0_irqs,
> > -	.flags		= HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY,
> > -	.main_clk	= "l3_gclk",
> > -	.prcm		= {
> > -		.omap4	= {
> > -			.clkctrl_offs	=
> > AM33XX_CM_PER_TPTC0_CLKCTRL_OFFSET,
> > -			.modulemode	= MODULEMODE_SWCTRL,
> > -		},
> > -	},
> > -};
> > -
> > -/* tptc1 */
> > -static struct omap_hwmod_irq_info am33xx_tptc1_irqs[] = {
> > -	{ .irq = 113 + OMAP_INTC_START, },
> > -	{ .irq = -1 },
> > -};
> > -
> > -static struct omap_hwmod am33xx_tptc1_hwmod = {
> > -	.name		= "tptc1",
> > -	.class		= &am33xx_tptc_hwmod_class,
> > -	.clkdm_name	= "l3_clkdm",
> > -	.mpu_irqs	= am33xx_tptc1_irqs,
> > -	.flags		= (HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY),
> > -	.main_clk	= "l3_gclk",
> > -	.prcm		= {
> > -		.omap4	= {
> > -			.clkctrl_offs	=
> > AM33XX_CM_PER_TPTC1_CLKCTRL_OFFSET,
> > -			.modulemode	= MODULEMODE_SWCTRL,
> > -		},
> > -	},
> > -};
> > -
> > -/* tptc2 */
> > -static struct omap_hwmod_irq_info am33xx_tptc2_irqs[] = {
> > -	{ .irq = 114 + OMAP_INTC_START, },
> > -	{ .irq = -1 },
> > -};
> > -
> > -static struct omap_hwmod am33xx_tptc2_hwmod = {
> > -	.name		= "tptc2",
> > -	.class		= &am33xx_tptc_hwmod_class,
> > -	.clkdm_name	= "l3_clkdm",
> > -	.mpu_irqs	= am33xx_tptc2_irqs,
> > -	.flags		= (HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY),
> > -	.main_clk	= "l3_gclk",
> > -	.prcm		= {
> > -		.omap4	= {
> > -			.clkctrl_offs	=
> > AM33XX_CM_PER_TPTC2_CLKCTRL_OFFSET,
> > -			.modulemode	= MODULEMODE_SWCTRL,
> > -		},
> > -	},
> > -};
> > -
> >  /* 'uart' class */
> >  static struct omap_hwmod_class_sysconfig uart_sysc = {
> >  	.rev_offs	= 0x50,
> > @@ -1954,23 +991,10 @@ static struct omap_hwmod_class uart_class = {
> >  };
> >
> >  /* uart1 */
> > -static struct omap_hwmod_dma_info uart1_edma_reqs[] = {
> > -	{ .name = "tx",	.dma_req = 26, },
> > -	{ .name = "rx",	.dma_req = 27, },
> > -	{ .dma_req = -1 }
> > -};
> > -
> > -static struct omap_hwmod_irq_info am33xx_uart1_irqs[] = {
> > -	{ .irq = 72 + OMAP_INTC_START, },
> > -	{ .irq = -1 },
> > -};
> > -
> >  static struct omap_hwmod am33xx_uart1_hwmod = {
> >  	.name		= "uart1",
> >  	.class		= &uart_class,
> >  	.clkdm_name	= "l4_wkup_clkdm",
> > -	.mpu_irqs	= am33xx_uart1_irqs,
> > -	.sdma_reqs	= uart1_edma_reqs,
> >  	.main_clk	= "dpll_per_m2_div4_wkupdm_ck",
> >  	.prcm		= {
> >  		.omap4	= {
> > @@ -1980,17 +1004,10 @@ static struct omap_hwmod am33xx_uart1_hwmod =
> {
> >  	},
> >  };
> >
> > -static struct omap_hwmod_irq_info am33xx_uart2_irqs[] = {
> > -	{ .irq = 73 + OMAP_INTC_START, },
> > -	{ .irq = -1 },
> > -};
> > -
> >  static struct omap_hwmod am33xx_uart2_hwmod = {
> >  	.name		= "uart2",
> >  	.class		= &uart_class,
> >  	.clkdm_name	= "l4ls_clkdm",
> > -	.mpu_irqs	= am33xx_uart2_irqs,
> > -	.sdma_reqs	= uart1_edma_reqs,
> >  	.main_clk	= "dpll_per_m2_div4_ck",
> >  	.prcm		= {
> >  		.omap4	= {
> > @@ -2001,23 +1018,10 @@ static struct omap_hwmod am33xx_uart2_hwmod =
> {
> >  };
> >
> >  /* uart3 */
> > -static struct omap_hwmod_dma_info uart3_edma_reqs[] = {
> > -	{ .name = "tx",	.dma_req = 30, },
> > -	{ .name = "rx",	.dma_req = 31, },
> > -	{ .dma_req = -1 }
> > -};
> > -
> > -static struct omap_hwmod_irq_info am33xx_uart3_irqs[] = {
> > -	{ .irq = 74 + OMAP_INTC_START, },
> > -	{ .irq = -1 },
> > -};
> > -
> >  static struct omap_hwmod am33xx_uart3_hwmod = {
> >  	.name		= "uart3",
> >  	.class		= &uart_class,
> >  	.clkdm_name	= "l4ls_clkdm",
> > -	.mpu_irqs	= am33xx_uart3_irqs,
> > -	.sdma_reqs	= uart3_edma_reqs,
> >  	.main_clk	= "dpll_per_m2_div4_ck",
> >  	.prcm		= {
> >  		.omap4	= {
> > @@ -2027,17 +1031,10 @@ static struct omap_hwmod am33xx_uart3_hwmod =
> {
> >  	},
> >  };
> >
> > -static struct omap_hwmod_irq_info am33xx_uart4_irqs[] = {
> > -	{ .irq = 44 + OMAP_INTC_START, },
> > -	{ .irq = -1 },
> > -};
> > -
> >  static struct omap_hwmod am33xx_uart4_hwmod = {
> >  	.name		= "uart4",
> >  	.class		= &uart_class,
> >  	.clkdm_name	= "l4ls_clkdm",
> > -	.mpu_irqs	= am33xx_uart4_irqs,
> > -	.sdma_reqs	= uart1_edma_reqs,
> >  	.main_clk	= "dpll_per_m2_div4_ck",
> >  	.prcm		= {
> >  		.omap4	= {
> > @@ -2047,17 +1044,10 @@ static struct omap_hwmod am33xx_uart4_hwmod =
> {
> >  	},
> >  };
> >
> > -static struct omap_hwmod_irq_info am33xx_uart5_irqs[] = {
> > -	{ .irq = 45 + OMAP_INTC_START, },
> > -	{ .irq = -1 },
> > -};
> > -
> >  static struct omap_hwmod am33xx_uart5_hwmod = {
> >  	.name		= "uart5",
> >  	.class		= &uart_class,
> >  	.clkdm_name	= "l4ls_clkdm",
> > -	.mpu_irqs	= am33xx_uart5_irqs,
> > -	.sdma_reqs	= uart1_edma_reqs,
> >  	.main_clk	= "dpll_per_m2_div4_ck",
> >  	.prcm		= {
> >  		.omap4	= {
> > @@ -2067,17 +1057,10 @@ static struct omap_hwmod am33xx_uart5_hwmod =
> {
> >  	},
> >  };
> >
> > -static struct omap_hwmod_irq_info am33xx_uart6_irqs[] = {
> > -	{ .irq = 46 + OMAP_INTC_START, },
> > -	{ .irq = -1 },
> > -};
> > -
> >  static struct omap_hwmod am33xx_uart6_hwmod = {
> >  	.name		= "uart6",
> >  	.class		= &uart_class,
> >  	.clkdm_name	= "l4ls_clkdm",
> > -	.mpu_irqs	= am33xx_uart6_irqs,
> > -	.sdma_reqs	= uart1_edma_reqs,
> >  	.main_clk	= "dpll_per_m2_div4_ck",
> >  	.prcm		= {
> >  		.omap4	= {
> > @@ -2123,7 +1106,7 @@ static struct omap_hwmod am33xx_wd_timer1_hwmod
> =
> > {
> >  	},
> >  };
> >
> > -/*
> > + /*
> >   * 'usb_otg' class
> >   * high-speed on-the-go universal serial bus (usb_otg) controller
> >   */
> > @@ -2141,18 +1124,10 @@ static struct omap_hwmod_class
> > am33xx_usbotg_class = {
> >  	.sysc		= &am33xx_usbhsotg_sysc,
> >  };
> >
> > -static struct omap_hwmod_irq_info am33xx_usbss_mpu_irqs[] = {
> > -	{ .name = "usbss-irq", .irq = 17 + OMAP_INTC_START, },
> > -	{ .name = "musb0-irq", .irq = 18 + OMAP_INTC_START, },
> > -	{ .name = "musb1-irq", .irq = 19 + OMAP_INTC_START, },
> > -	{ .irq = -1, },
> > -};
> > -
> >  static struct omap_hwmod am33xx_usbss_hwmod = {
> >  	.name		= "usb_otg_hs",
> >  	.class		= &am33xx_usbotg_class,
> >  	.clkdm_name	= "l3s_clkdm",
> > -	.mpu_irqs	= am33xx_usbss_mpu_irqs,
> >  	.flags		= HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY,
> >  	.main_clk	= "usbotg_fck",
> >  	.prcm		= {
> > @@ -2163,36 +1138,9 @@ static struct omap_hwmod am33xx_usbss_hwmod =
> {
> >  	},
> >  };
> >
> > -
> >  /*
> >   * Interfaces
> >   */
> > -
> > -/* l4 fw -> emif fw */
> > -static struct omap_hwmod_ocp_if am33xx_l4_fw__emif_fw = {
> > -	.master		= &am33xx_l4_fw_hwmod,
> > -	.slave		= &am33xx_emif_fw_hwmod,
> > -	.clk		= "l4fw_gclk",
> > -	.user		= OCP_USER_MPU,
> > -};
> > -
> > -static struct omap_hwmod_addr_space am33xx_emif_addrs[] = {
> > -	{
> > -		.pa_start	= 0x4c000000,
> > -		.pa_end		= 0x4c000fff,
> > -		.flags		= ADDR_TYPE_RT
> > -	},
> > -	{ }
> > -};
> > -/* l3 main -> emif */
> > -static struct omap_hwmod_ocp_if am33xx_l3_main__emif = {
> > -	.master		= &am33xx_l3_main_hwmod,
> > -	.slave		= &am33xx_emif_hwmod,
> > -	.clk		= "dpll_core_m4_ck",
> > -	.addr		= am33xx_emif_addrs,
> > -	.user		= OCP_USER_MPU | OCP_USER_SDMA,
> > -};
> > -
> >  /* mpu -> l3 main */
> >  static struct omap_hwmod_ocp_if am33xx_mpu__l3_main = {
> >  	.master		= &am33xx_mpu_hwmod,
> > @@ -2233,14 +1181,6 @@ static struct omap_hwmod_ocp_if
> > am33xx_l3_s__l4_wkup = {
> >  	.user		= OCP_USER_MPU | OCP_USER_SDMA,
> >  };
> >
> > -/* l3 s -> l4 fw */
> > -static struct omap_hwmod_ocp_if am33xx_l3_s__l4_fw = {
> > -	.master		= &am33xx_l3_s_hwmod,
> > -	.slave		= &am33xx_l4_fw_hwmod,
> > -	.clk		= "l3s_gclk",
> > -	.user		= OCP_USER_MPU | OCP_USER_SDMA,
> > -};
> > -
> >  /* l3 main -> l3 instr */
> >  static struct omap_hwmod_ocp_if am33xx_l3_main__l3_instr = {
> >  	.master		= &am33xx_l3_main_hwmod,
> > @@ -2290,1154 +1230,277 @@ static struct omap_hwmod_ocp_if
> > am33xx_gfx__l3_main = {
> >  };
> >
> >  /* l4 wkup -> wkup m3 */
> > -static struct omap_hwmod_addr_space am33xx_wkup_m3_addrs[] = {
> > -	{
> > -		.name		= "umem",
> > -		.pa_start	= 0x44d00000,
> > -		.pa_end		= 0x44d00000 + SZ_16K - 1,
> > -		.flags		= ADDR_TYPE_RT
> > -	},
> > -	{
> > -		.name		= "dmem",
> > -		.pa_start	= 0x44d80000,
> > -		.pa_end		= 0x44d80000 + SZ_8K - 1,
> > -		.flags		= ADDR_TYPE_RT
> > -	},
> > -	{ }
> > -};
> > -
> >  static struct omap_hwmod_ocp_if am33xx_l4_wkup__wkup_m3 = {
> >  	.master		= &am33xx_l4_wkup_hwmod,
> >  	.slave		= &am33xx_wkup_m3_hwmod,
> >  	.clk		= "dpll_core_m4_div2_ck",
> > -	.addr		= am33xx_wkup_m3_addrs,
> >  	.user		= OCP_USER_MPU | OCP_USER_SDMA,
> >  };
> >
> >  /* l4 hs -> pru-icss */
> > -static struct omap_hwmod_addr_space am33xx_pruss_addrs[] = {
> > -	{
> > -		.pa_start	= 0x4a300000,
> > -		.pa_end		= 0x4a300000 + SZ_512K - 1,
> > -		.flags		= ADDR_TYPE_RT
> > -	},
> > -	{ }
> > -};
> > -
> >  static struct omap_hwmod_ocp_if am33xx_l4_hs__pruss = {
> >  	.master		= &am33xx_l4_hs_hwmod,
> >  	.slave		= &am33xx_pruss_hwmod,
> >  	.clk		= "dpll_core_m4_ck",
> > -	.addr		= am33xx_pruss_addrs,
> >  	.user		= OCP_USER_MPU | OCP_USER_SDMA,
> >  };
> >
> >  /* l3 main -> gfx */
> > -static struct omap_hwmod_addr_space am33xx_gfx_addrs[] = {
> > -	{
> > -		.pa_start	= 0x56000000,
> > -		.pa_end		= 0x56000000 + SZ_16M - 1,
> > -		.flags		= ADDR_TYPE_RT
> > -	},
> > -	{ }
> > -};
> > -
> >  static struct omap_hwmod_ocp_if am33xx_l3_main__gfx = {
> >  	.master		= &am33xx_l3_main_hwmod,
> >  	.slave		= &am33xx_gfx_hwmod,
> >  	.clk		= "dpll_core_m4_ck",
> > -	.addr		= am33xx_gfx_addrs,
> >  	.user		= OCP_USER_MPU | OCP_USER_SDMA,
> >  };
> >
> >  /* l4 wkup -> smartreflex0 */
> > -static struct omap_hwmod_addr_space am33xx_smartreflex0_addrs[] = {
> > -	{
> > -		.pa_start	= 0x44e37000,
> > -		.pa_end		= 0x44e37000 + SZ_4K - 1,
> > -		.flags		= ADDR_TYPE_RT
> > -	},
> > -	{ }
> > -};
> > -
> >  static struct omap_hwmod_ocp_if am33xx_l4_wkup__smartreflex0 = {
> >  	.master		= &am33xx_l4_wkup_hwmod,
> >  	.slave		= &am33xx_smartreflex0_hwmod,
> >  	.clk		= "dpll_core_m4_div2_ck",
> > -	.addr		= am33xx_smartreflex0_addrs,
> >  	.user		= OCP_USER_MPU,
> >  };
> >
> >  /* l4 wkup -> smartreflex1 */
> > -static struct omap_hwmod_addr_space am33xx_smartreflex1_addrs[] = {
> > -	{
> > -		.pa_start	= 0x44e39000,
> > -		.pa_end		= 0x44e39000 + SZ_4K - 1,
> > -		.flags		= ADDR_TYPE_RT
> > -	},
> > -	{ }
> > -};
> > -
> >  static struct omap_hwmod_ocp_if am33xx_l4_wkup__smartreflex1 = {
> >  	.master		= &am33xx_l4_wkup_hwmod,
> >  	.slave		= &am33xx_smartreflex1_hwmod,
> >  	.clk		= "dpll_core_m4_div2_ck",
> > -	.addr		= am33xx_smartreflex1_addrs,
> >  	.user		= OCP_USER_MPU,
> >  };
> >
> >  /* l4 wkup -> control */
> > -static struct omap_hwmod_addr_space am33xx_control_addrs[] = {
> > -	{
> > -		.pa_start	= 0x44e10000,
> > -		.pa_end		= 0x44e10000 + SZ_8K - 1,
> > -		.flags		= ADDR_TYPE_RT
> > -	},
> > -	{ }
> > -};
> > -
> >  static struct omap_hwmod_ocp_if am33xx_l4_wkup__control = {
> >  	.master		= &am33xx_l4_wkup_hwmod,
> >  	.slave		= &am33xx_control_hwmod,
> >  	.clk		= "dpll_core_m4_div2_ck",
> > -	.addr		= am33xx_control_addrs,
> >  	.user		= OCP_USER_MPU,
> >  };
> >
> >  /* l4 wkup -> rtc */
> > -static struct omap_hwmod_addr_space am33xx_rtc_addrs[] = {
> > -	{
> > -		.pa_start	= 0x44e3e000,
> > -		.pa_end		= 0x44e3e000 + SZ_4K - 1,
> > -		.flags		= ADDR_TYPE_RT
> > -	},
> > -	{ }
> > -};
> > -
> >  static struct omap_hwmod_ocp_if am33xx_l4_wkup__rtc = {
> >  	.master		= &am33xx_l4_wkup_hwmod,
> >  	.slave		= &am33xx_rtc_hwmod,
> >  	.clk		= "clkdiv32k_ick",
> > -	.addr		= am33xx_rtc_addrs,
> >  	.user		= OCP_USER_MPU,
> >  };
> >
> >  /* l4 per/ls -> DCAN0 */
> > -static struct omap_hwmod_addr_space am33xx_dcan0_addrs[] = {
> > -	{
> > -		.pa_start	= 0x481CC000,
> > -		.pa_end		= 0x481CC000 + SZ_4K - 1,
> > -		.flags		= ADDR_TYPE_RT
> > -	},
> > -	{ }
> > -};
> > -
> >  static struct omap_hwmod_ocp_if am33xx_l4_per__dcan0 = {
> >  	.master		= &am33xx_l4_ls_hwmod,
> >  	.slave		= &am33xx_dcan0_hwmod,
> >  	.clk		= "l4ls_gclk",
> > -	.addr		= am33xx_dcan0_addrs,
> >  	.user		= OCP_USER_MPU | OCP_USER_SDMA,
> >  };
> >
> >  /* l4 per/ls -> DCAN1 */
> > -static struct omap_hwmod_addr_space am33xx_dcan1_addrs[] = {
> > -	{
> > -		.pa_start	= 0x481D0000,
> > -		.pa_end		= 0x481D0000 + SZ_4K - 1,
> > -		.flags		= ADDR_TYPE_RT
> > -	},
> > -	{ }
> > -};
> > -
> >  static struct omap_hwmod_ocp_if am33xx_l4_per__dcan1 = {
> >  	.master		= &am33xx_l4_ls_hwmod,
> >  	.slave		= &am33xx_dcan1_hwmod,
> >  	.clk		= "l4ls_gclk",
> > -	.addr		= am33xx_dcan1_addrs,
> >  	.user		= OCP_USER_MPU | OCP_USER_SDMA,
> >  };
> >
> >  /* l4 per/ls -> GPIO2 */
> > -static struct omap_hwmod_addr_space am33xx_gpio1_addrs[] = {
> > -	{
> > -		.pa_start	= 0x4804C000,
> > -		.pa_end		= 0x4804C000 + SZ_4K - 1,
> > -		.flags		= ADDR_TYPE_RT,
> > -	},
> > -	{ }
> > -};
> > -
> >  static struct omap_hwmod_ocp_if am33xx_l4_per__gpio1 = {
> >  	.master		= &am33xx_l4_ls_hwmod,
> >  	.slave		= &am33xx_gpio1_hwmod,
> >  	.clk		= "l4ls_gclk",
> > -	.addr		= am33xx_gpio1_addrs,
> >  	.user		= OCP_USER_MPU | OCP_USER_SDMA,
> >  };
> >
> >  /* l4 per/ls -> gpio3 */
> > -static struct omap_hwmod_addr_space am33xx_gpio2_addrs[] = {
> > -	{
> > -		.pa_start	= 0x481AC000,
> > -		.pa_end		= 0x481AC000 + SZ_4K - 1,
> > -		.flags		= ADDR_TYPE_RT,
> > -	},
> > -	{ }
> > -};
> > -
> >  static struct omap_hwmod_ocp_if am33xx_l4_per__gpio2 = {
> >  	.master		= &am33xx_l4_ls_hwmod,
> >  	.slave		= &am33xx_gpio2_hwmod,
> >  	.clk		= "l4ls_gclk",
> > -	.addr		= am33xx_gpio2_addrs,
> >  	.user		= OCP_USER_MPU | OCP_USER_SDMA,
> >  };
> >
> >  /* l4 per/ls -> gpio4 */
> > -static struct omap_hwmod_addr_space am33xx_gpio3_addrs[] = {
> > -	{
> > -		.pa_start	= 0x481AE000,
> > -		.pa_end		= 0x481AE000 + SZ_4K - 1,
> > -		.flags		= ADDR_TYPE_RT,
> > -	},
> > -	{ }
> > -};
> > -
> >  static struct omap_hwmod_ocp_if am33xx_l4_per__gpio3 = {
> >  	.master		= &am33xx_l4_ls_hwmod,
> >  	.slave		= &am33xx_gpio3_hwmod,
> >  	.clk		= "l4ls_gclk",
> > -	.addr		= am33xx_gpio3_addrs,
> >  	.user		= OCP_USER_MPU | OCP_USER_SDMA,
> >  };
> >
> > -/* L4 WKUP -> I2C1 */
> > -static struct omap_hwmod_addr_space am33xx_i2c1_addr_space[] = {
> > -	{
> > -		.pa_start	= 0x44E0B000,
> > -		.pa_end		= 0x44E0B000 + SZ_4K - 1,
> > -		.flags		= ADDR_TYPE_RT,
> > -	},
> > -	{ }
> > -};
> > -
> >  static struct omap_hwmod_ocp_if am33xx_l4_wkup__i2c1 = {
> >  	.master		= &am33xx_l4_wkup_hwmod,
> >  	.slave		= &am33xx_i2c1_hwmod,
> >  	.clk		= "dpll_core_m4_div2_ck",
> > -	.addr		= am33xx_i2c1_addr_space,
> >  	.user		= OCP_USER_MPU,
> >  };
> >
> >  /* L4 WKUP -> GPIO1 */
> > -static struct omap_hwmod_addr_space am33xx_gpio0_addrs[] = {
> > -	{
> > -		.pa_start	= 0x44E07000,
> > -		.pa_end		= 0x44E07000 + SZ_4K - 1,
> > -		.flags		= ADDR_TYPE_RT,
> > -	},
> > -	{ }
> > -};
> > -
> >  static struct omap_hwmod_ocp_if am33xx_l4_wkup__gpio0 = {
> >  	.master		= &am33xx_l4_wkup_hwmod,
> >  	.slave		= &am33xx_gpio0_hwmod,
> >  	.clk		= "dpll_core_m4_div2_ck",
> > -	.addr		= am33xx_gpio0_addrs,
> >  	.user		= OCP_USER_MPU | OCP_USER_SDMA,
> >  };
> >
> > -/* L4 WKUP -> ADC_TSC */
> > -static struct omap_hwmod_addr_space am33xx_adc_tsc_addrs[] = {
> > -	{
> > -		.pa_start	= 0x44E0D000,
> > -		.pa_end		= 0x44E0D000 + SZ_8K - 1,
> > -		.flags		= ADDR_TYPE_RT
> > -	},
> > -	{ }
> > -};
> > -
> > -static struct omap_hwmod_ocp_if am33xx_l4_wkup__adc_tsc = {
> > -	.master		= &am33xx_l4_wkup_hwmod,
> > -	.slave		= &am33xx_adc_tsc_hwmod,
> > -	.clk		= "dpll_core_m4_div2_ck",
> > -	.addr		= am33xx_adc_tsc_addrs,
> > -	.user		= OCP_USER_MPU,
> > -};
> > -
> > -static struct omap_hwmod_addr_space am33xx_cpgmac0_addr_space[] = {
> > -	/* cpsw ss */
> > -	{
> > -		.pa_start	= 0x4a100000,
> > -		.pa_end		= 0x4a100000 + SZ_2K - 1,
> > -	},
> > -	/* cpsw wr */
> > -	{
> > -		.pa_start	= 0x4a101200,
> > -		.pa_end		= 0x4a101200 + SZ_256 - 1,
> > -		.flags		= ADDR_TYPE_RT,
> > -	},
> > -	{ }
> > -};
> > -
> >  static struct omap_hwmod_ocp_if am33xx_l4_hs__cpgmac0 = {
> >  	.master		= &am33xx_l4_hs_hwmod,
> >  	.slave		= &am33xx_cpgmac0_hwmod,
> >  	.clk		= "cpsw_125mhz_gclk",
> > -	.addr		= am33xx_cpgmac0_addr_space,
> >  	.user		= OCP_USER_MPU,
> >  };
> >
> > -static struct omap_hwmod_addr_space am33xx_mdio_addr_space[] = {
> > -	{
> > -		.pa_start	= 0x4A101000,
> > -		.pa_end		= 0x4A101000 + SZ_256 - 1,
> > -	},
> > -	{ }
> > -};
> > -
> >  static struct omap_hwmod_ocp_if am33xx_cpgmac0__mdio = {
> >  	.master		= &am33xx_cpgmac0_hwmod,
> >  	.slave		= &am33xx_mdio_hwmod,
> > -	.addr		= am33xx_mdio_addr_space,
> > -	.user		= OCP_USER_MPU,
> > -};
> > -
> > -static struct omap_hwmod_addr_space am33xx_elm_addr_space[] = {
> > -	{
> > -		.pa_start	= 0x48080000,
> > -		.pa_end		= 0x48080000 + SZ_8K - 1,
> > -		.flags		= ADDR_TYPE_RT
> > -	},
> > -	{ }
> > -};
> > -
> > -static struct omap_hwmod_ocp_if am33xx_l4_ls__elm = {
> > -	.master		= &am33xx_l4_ls_hwmod,
> > -	.slave		= &am33xx_elm_hwmod,
> > -	.clk		= "l4ls_gclk",
> > -	.addr		= am33xx_elm_addr_space,
> > -	.user		= OCP_USER_MPU,
> > -};
> > -
> > -static struct omap_hwmod_addr_space am33xx_epwmss0_addr_space[] = {
> > -	{
> > -		.pa_start	= 0x48300000,
> > -		.pa_end		= 0x48300000 + SZ_16 - 1,
> > -		.flags		= ADDR_TYPE_RT
> > -	},
> > -	{ }
> > -};
> > -
> > -static struct omap_hwmod_ocp_if am33xx_l4_ls__epwmss0 = {
> > -	.master		= &am33xx_l4_ls_hwmod,
> > -	.slave		= &am33xx_epwmss0_hwmod,
> > -	.clk		= "l4ls_gclk",
> > -	.addr		= am33xx_epwmss0_addr_space,
> > -	.user		= OCP_USER_MPU,
> > -};
> > -
> > -static struct omap_hwmod_addr_space am33xx_ecap0_addr_space[] = {
> > -	{
> > -		.pa_start	= 0x48300100,
> > -		.pa_end		= 0x48300100 + SZ_128 - 1,
> > -	},
> > -	{ }
> > -};
> > -
> > -static struct omap_hwmod_ocp_if am33xx_epwmss0__ecap0 = {
> > -	.master		= &am33xx_epwmss0_hwmod,
> > -	.slave		= &am33xx_ecap0_hwmod,
> > -	.clk		= "l4ls_gclk",
> > -	.addr		= am33xx_ecap0_addr_space,
> >  	.user		= OCP_USER_MPU,
> >  };
> >
> > -static struct omap_hwmod_addr_space am33xx_eqep0_addr_space[] = {
> > -	{
> > -		.pa_start	= 0x48300180,
> > -		.pa_end		= 0x48300180 + SZ_128 - 1,
> > -	},
> > -	{ }
> > -};
> > -
> > -static struct omap_hwmod_ocp_if am33xx_epwmss0__eqep0 = {
> > -	.master		= &am33xx_epwmss0_hwmod,
> > -	.slave		= &am33xx_eqep0_hwmod,
> > -	.clk		= "l4ls_gclk",
> > -	.addr		= am33xx_eqep0_addr_space,
> > -	.user		= OCP_USER_MPU,
> > -};
> > -
> > -static struct omap_hwmod_addr_space am33xx_ehrpwm0_addr_space[] = {
> > -	{
> > -		.pa_start	= 0x48300200,
> > -		.pa_end		= 0x48300200 + SZ_128 - 1,
> > -	},
> > -	{ }
> > -};
> > -
> > -static struct omap_hwmod_ocp_if am33xx_epwmss0__ehrpwm0 = {
> > -	.master		= &am33xx_epwmss0_hwmod,
> > -	.slave		= &am33xx_ehrpwm0_hwmod,
> > -	.clk		= "l4ls_gclk",
> > -	.addr		= am33xx_ehrpwm0_addr_space,
> > -	.user		= OCP_USER_MPU,
> > -};
> > -
> > -
> > -static struct omap_hwmod_addr_space am33xx_epwmss1_addr_space[] = {
> > -	{
> > -		.pa_start	= 0x48302000,
> > -		.pa_end		= 0x48302000 + SZ_16 - 1,
> > -		.flags		= ADDR_TYPE_RT
> > -	},
> > -	{ }
> > -};
> > -
> > -static struct omap_hwmod_ocp_if am33xx_l4_ls__epwmss1 = {
> > -	.master		= &am33xx_l4_ls_hwmod,
> > -	.slave		= &am33xx_epwmss1_hwmod,
> > -	.clk		= "l4ls_gclk",
> > -	.addr		= am33xx_epwmss1_addr_space,
> > -	.user		= OCP_USER_MPU,
> > -};
> > -
> > -static struct omap_hwmod_addr_space am33xx_ecap1_addr_space[] = {
> > -	{
> > -		.pa_start	= 0x48302100,
> > -		.pa_end		= 0x48302100 + SZ_128 - 1,
> > -	},
> > -	{ }
> > -};
> > -
> > -static struct omap_hwmod_ocp_if am33xx_epwmss1__ecap1 = {
> > -	.master		= &am33xx_epwmss1_hwmod,
> > -	.slave		= &am33xx_ecap1_hwmod,
> > -	.clk		= "l4ls_gclk",
> > -	.addr		= am33xx_ecap1_addr_space,
> > -	.user		= OCP_USER_MPU,
> > -};
> > -
> > -static struct omap_hwmod_addr_space am33xx_eqep1_addr_space[] = {
> > -	{
> > -		.pa_start	= 0x48302180,
> > -		.pa_end		= 0x48302180 + SZ_128 - 1,
> > -	},
> > -	{ }
> > -};
> > -
> > -static struct omap_hwmod_ocp_if am33xx_epwmss1__eqep1 = {
> > -	.master		= &am33xx_epwmss1_hwmod,
> > -	.slave		= &am33xx_eqep1_hwmod,
> > -	.clk		= "l4ls_gclk",
> > -	.addr		= am33xx_eqep1_addr_space,
> > -	.user		= OCP_USER_MPU,
> > -};
> > -
> > -static struct omap_hwmod_addr_space am33xx_ehrpwm1_addr_space[] = {
> > -	{
> > -		.pa_start	= 0x48302200,
> > -		.pa_end		= 0x48302200 + SZ_128 - 1,
> > -	},
> > -	{ }
> > -};
> > -
> > -static struct omap_hwmod_ocp_if am33xx_epwmss1__ehrpwm1 = {
> > -	.master		= &am33xx_epwmss1_hwmod,
> > -	.slave		= &am33xx_ehrpwm1_hwmod,
> > -	.clk		= "l4ls_gclk",
> > -	.addr		= am33xx_ehrpwm1_addr_space,
> > -	.user		= OCP_USER_MPU,
> > -};
> > -
> > -static struct omap_hwmod_addr_space am33xx_epwmss2_addr_space[] = {
> > -	{
> > -		.pa_start	= 0x48304000,
> > -		.pa_end		= 0x48304000 + SZ_16 - 1,
> > -		.flags		= ADDR_TYPE_RT
> > -	},
> > -	{ }
> > -};
> > -
> > -static struct omap_hwmod_ocp_if am33xx_l4_ls__epwmss2 = {
> > -	.master		= &am33xx_l4_ls_hwmod,
> > -	.slave		= &am33xx_epwmss2_hwmod,
> > -	.clk		= "l4ls_gclk",
> > -	.addr		= am33xx_epwmss2_addr_space,
> > -	.user		= OCP_USER_MPU,
> > -};
> > -
> > -static struct omap_hwmod_addr_space am33xx_ecap2_addr_space[] = {
> > -	{
> > -		.pa_start	= 0x48304100,
> > -		.pa_end		= 0x48304100 + SZ_128 - 1,
> > -	},
> > -	{ }
> > -};
> > -
> > -static struct omap_hwmod_ocp_if am33xx_epwmss2__ecap2 = {
> > -	.master		= &am33xx_epwmss2_hwmod,
> > -	.slave		= &am33xx_ecap2_hwmod,
> > -	.clk		= "l4ls_gclk",
> > -	.addr		= am33xx_ecap2_addr_space,
> > -	.user		= OCP_USER_MPU,
> > -};
> > -
> > -static struct omap_hwmod_addr_space am33xx_eqep2_addr_space[] = {
> > -	{
> > -		.pa_start	= 0x48304180,
> > -		.pa_end		= 0x48304180 + SZ_128 - 1,
> > -	},
> > -	{ }
> > -};
> > -
> > -static struct omap_hwmod_ocp_if am33xx_epwmss2__eqep2 = {
> > -	.master		= &am33xx_epwmss2_hwmod,
> > -	.slave		= &am33xx_eqep2_hwmod,
> > -	.clk		= "l4ls_gclk",
> > -	.addr		= am33xx_eqep2_addr_space,
> > -	.user		= OCP_USER_MPU,
> > -};
> > -
> > -static struct omap_hwmod_addr_space am33xx_ehrpwm2_addr_space[] = {
> > -	{
> > -		.pa_start	= 0x48304200,
> > -		.pa_end		= 0x48304200 + SZ_128 - 1,
> > -	},
> > -	{ }
> > -};
> > -
> > -static struct omap_hwmod_ocp_if am33xx_epwmss2__ehrpwm2 = {
> > -	.master		= &am33xx_epwmss2_hwmod,
> > -	.slave		= &am33xx_ehrpwm2_hwmod,
> > -	.clk		= "l4ls_gclk",
> > -	.addr		= am33xx_ehrpwm2_addr_space,
> > -	.user		= OCP_USER_MPU,
> > -};
> > -
> > -/* l3s cfg -> gpmc */
> > -static struct omap_hwmod_addr_space am33xx_gpmc_addr_space[] = {
> > -	{
> > -		.pa_start	= 0x50000000,
> > -		.pa_end		= 0x50000000 + SZ_8K - 1,
> > -		.flags		= ADDR_TYPE_RT,
> > -	},
> > -	{ }
> > -};
> > -
> > -static struct omap_hwmod_ocp_if am33xx_l3_s__gpmc = {
> > -	.master		= &am33xx_l3_s_hwmod,
> > -	.slave		= &am33xx_gpmc_hwmod,
> > -	.clk		= "l3s_gclk",
> > -	.addr		= am33xx_gpmc_addr_space,
> > -	.user		= OCP_USER_MPU,
> > -};
> > -
> > -/* i2c2 */
> > -static struct omap_hwmod_addr_space am33xx_i2c2_addr_space[] = {
> > -	{
> > -		.pa_start	= 0x4802A000,
> > -		.pa_end		= 0x4802A000 + SZ_4K - 1,
> > -		.flags		= ADDR_TYPE_RT,
> > -	},
> > -	{ }
> > -};
> > -
> >  static struct omap_hwmod_ocp_if am33xx_l4_per__i2c2 = {
> >  	.master		= &am33xx_l4_ls_hwmod,
> >  	.slave		= &am33xx_i2c2_hwmod,
> >  	.clk		= "l4ls_gclk",
> > -	.addr		= am33xx_i2c2_addr_space,
> >  	.user		= OCP_USER_MPU,
> >  };
> >
> > -static struct omap_hwmod_addr_space am33xx_i2c3_addr_space[] = {
> > -	{
> > -		.pa_start	= 0x4819C000,
> > -		.pa_end		= 0x4819C000 + SZ_4K - 1,
> > -		.flags		= ADDR_TYPE_RT
> > -	},
> > -	{ }
> > -};
> > -
> >  static struct omap_hwmod_ocp_if am33xx_l4_per__i2c3 = {
> >  	.master		= &am33xx_l4_ls_hwmod,
> >  	.slave		= &am33xx_i2c3_hwmod,
> >  	.clk		= "l4ls_gclk",
> > -	.addr		= am33xx_i2c3_addr_space,
> > -	.user		= OCP_USER_MPU,
> > -};
> > -
> > -static struct omap_hwmod_addr_space am33xx_lcdc_addr_space[] = {
> > -	{
> > -		.pa_start	= 0x4830E000,
> > -		.pa_end		= 0x4830E000 + SZ_8K - 1,
> > -		.flags		= ADDR_TYPE_RT,
> > -	},
> > -	{ }
> > -};
> > -
> > -static struct omap_hwmod_ocp_if am33xx_l3_main__lcdc = {
> > -	.master		= &am33xx_l3_main_hwmod,
> > -	.slave		= &am33xx_lcdc_hwmod,
> > -	.clk		= "dpll_core_m4_ck",
> > -	.addr		= am33xx_lcdc_addr_space,
> > -	.user		= OCP_USER_MPU,
> > -};
> > -
> > -static struct omap_hwmod_addr_space am33xx_mailbox_addrs[] = {
> > -	{
> > -		.pa_start	= 0x480C8000,
> > -		.pa_end		= 0x480C8000 + (SZ_4K - 1),
> > -		.flags		= ADDR_TYPE_RT
> > -	},
> > -	{ }
> > -};
> > -
> > -/* l4 ls -> mailbox */
> > -static struct omap_hwmod_ocp_if am33xx_l4_per__mailbox = {
> > -	.master		= &am33xx_l4_ls_hwmod,
> > -	.slave		= &am33xx_mailbox_hwmod,
> > -	.clk		= "l4ls_gclk",
> > -	.addr		= am33xx_mailbox_addrs,
> >  	.user		= OCP_USER_MPU,
> >  };
> >
> >  /* l4 ls -> spinlock */
> > -static struct omap_hwmod_addr_space am33xx_spinlock_addrs[] = {
> > -	{
> > -		.pa_start	= 0x480Ca000,
> > -		.pa_end		= 0x480Ca000 + SZ_4K - 1,
> > -		.flags		= ADDR_TYPE_RT
> > -	},
> > -	{ }
> > -};
> > -
> >  static struct omap_hwmod_ocp_if am33xx_l4_ls__spinlock = {
> >  	.master		= &am33xx_l4_ls_hwmod,
> >  	.slave		= &am33xx_spinlock_hwmod,
> >  	.clk		= "l4ls_gclk",
> > -	.addr		= am33xx_spinlock_addrs,
> >  	.user		= OCP_USER_MPU,
> >  };
> >
> > -/* l4 ls -> mcasp0 */
> > -static struct omap_hwmod_addr_space am33xx_mcasp0_addr_space[] = {
> > -	{
> > -		.pa_start	= 0x48038000,
> > -		.pa_end		= 0x48038000 + SZ_8K - 1,
> > -		.flags		= ADDR_TYPE_RT
> > -	},
> > -	{ }
> > -};
> > -
> > -static struct omap_hwmod_ocp_if am33xx_l4_ls__mcasp0 = {
> > -	.master		= &am33xx_l4_ls_hwmod,
> > -	.slave		= &am33xx_mcasp0_hwmod,
> > -	.clk		= "l4ls_gclk",
> > -	.addr		= am33xx_mcasp0_addr_space,
> > -	.user		= OCP_USER_MPU,
> > -};
> > -
> > -/* l3 s -> mcasp0 data */
> > -static struct omap_hwmod_addr_space am33xx_mcasp0_data_addr_space[]
> =
> > {
> > -	{
> > -		.pa_start	= 0x46000000,
> > -		.pa_end		= 0x46000000 + SZ_4M - 1,
> > -		.flags		= ADDR_TYPE_RT
> > -	},
> > -	{ }
> > -};
> > -
> > -static struct omap_hwmod_ocp_if am33xx_l3_s__mcasp0_data = {
> > -	.master		= &am33xx_l3_s_hwmod,
> > -	.slave		= &am33xx_mcasp0_hwmod,
> > -	.clk		= "l3s_gclk",
> > -	.addr		= am33xx_mcasp0_data_addr_space,
> > -	.user		= OCP_USER_SDMA,
> > -};
> > -
> > -/* l4 ls -> mcasp1 */
> > -static struct omap_hwmod_addr_space am33xx_mcasp1_addr_space[] = {
> > -	{
> > -		.pa_start	= 0x4803C000,
> > -		.pa_end		= 0x4803C000 + SZ_8K - 1,
> > -		.flags		= ADDR_TYPE_RT
> > -	},
> > -	{ }
> > -};
> > -
> > -static struct omap_hwmod_ocp_if am33xx_l4_ls__mcasp1 = {
> > -	.master		= &am33xx_l4_ls_hwmod,
> > -	.slave		= &am33xx_mcasp1_hwmod,
> > -	.clk		= "l4ls_gclk",
> > -	.addr		= am33xx_mcasp1_addr_space,
> > -	.user		= OCP_USER_MPU,
> > -};
> > -
> > -/* l3 s -> mcasp1 data */
> > -static struct omap_hwmod_addr_space am33xx_mcasp1_data_addr_space[]
> =
> > {
> > -	{
> > -		.pa_start	= 0x46400000,
> > -		.pa_end		= 0x46400000 + SZ_4M - 1,
> > -		.flags		= ADDR_TYPE_RT
> > -	},
> > -	{ }
> > -};
> > -
> > -static struct omap_hwmod_ocp_if am33xx_l3_s__mcasp1_data = {
> > -	.master		= &am33xx_l3_s_hwmod,
> > -	.slave		= &am33xx_mcasp1_hwmod,
> > -	.clk		= "l3s_gclk",
> > -	.addr		= am33xx_mcasp1_data_addr_space,
> > -	.user		= OCP_USER_SDMA,
> > -};
> > -
> > -/* l4 ls -> mmc0 */
> > -static struct omap_hwmod_addr_space am33xx_mmc0_addr_space[] = {
> > -	{
> > -		.pa_start	= 0x48060100,
> > -		.pa_end		= 0x48060100 + SZ_4K - 1,
> > -		.flags		= ADDR_TYPE_RT,
> > -	},
> > -	{ }
> > -};
> > -
> > -static struct omap_hwmod_ocp_if am33xx_l4_ls__mmc0 = {
> > -	.master		= &am33xx_l4_ls_hwmod,
> > -	.slave		= &am33xx_mmc0_hwmod,
> > -	.clk		= "l4ls_gclk",
> > -	.addr		= am33xx_mmc0_addr_space,
> > -	.user		= OCP_USER_MPU,
> > -};
> > -
> > -/* l4 ls -> mmc1 */
> > -static struct omap_hwmod_addr_space am33xx_mmc1_addr_space[] = {
> > -	{
> > -		.pa_start	= 0x481d8100,
> > -		.pa_end		= 0x481d8100 + SZ_4K - 1,
> > -		.flags		= ADDR_TYPE_RT,
> > -	},
> > -	{ }
> > -};
> > -
> > -static struct omap_hwmod_ocp_if am33xx_l4_ls__mmc1 = {
> > -	.master		= &am33xx_l4_ls_hwmod,
> > -	.slave		= &am33xx_mmc1_hwmod,
> > -	.clk		= "l4ls_gclk",
> > -	.addr		= am33xx_mmc1_addr_space,
> > -	.user		= OCP_USER_MPU,
> > -};
> > -
> > -/* l3 s -> mmc2 */
> > -static struct omap_hwmod_addr_space am33xx_mmc2_addr_space[] = {
> > -	{
> > -		.pa_start	= 0x47810100,
> > -		.pa_end		= 0x47810100 + SZ_64K - 1,
> > -		.flags		= ADDR_TYPE_RT,
> > -	},
> > -	{ }
> > -};
> > -
> > -static struct omap_hwmod_ocp_if am33xx_l3_s__mmc2 = {
> > -	.master		= &am33xx_l3_s_hwmod,
> > -	.slave		= &am33xx_mmc2_hwmod,
> > -	.clk		= "l3s_gclk",
> > -	.addr		= am33xx_mmc2_addr_space,
> > -	.user		= OCP_USER_MPU,
> > -};
> > -
> > -/* l4 ls -> mcspi0 */
> > -static struct omap_hwmod_addr_space am33xx_mcspi0_addr_space[] = {
> > -	{
> > -		.pa_start	= 0x48030000,
> > -		.pa_end		= 0x48030000 + SZ_1K - 1,
> > -		.flags		= ADDR_TYPE_RT,
> > -	},
> > -	{ }
> > -};
> > -
> >  static struct omap_hwmod_ocp_if am33xx_l4_ls__mcspi0 = {
> >  	.master		= &am33xx_l4_ls_hwmod,
> >  	.slave		= &am33xx_spi0_hwmod,
> >  	.clk		= "l4ls_gclk",
> > -	.addr		= am33xx_mcspi0_addr_space,
> >  	.user		= OCP_USER_MPU,
> >  };
> >
> > -/* l4 ls -> mcspi1 */
> > -static struct omap_hwmod_addr_space am33xx_mcspi1_addr_space[] = {
> > -	{
> > -		.pa_start	= 0x481A0000,
> > -		.pa_end		= 0x481A0000 + SZ_1K - 1,
> > -		.flags		= ADDR_TYPE_RT,
> > -	},
> > -	{ }
> > -};
> > -
> >  static struct omap_hwmod_ocp_if am33xx_l4_ls__mcspi1 = {
> >  	.master		= &am33xx_l4_ls_hwmod,
> >  	.slave		= &am33xx_spi1_hwmod,
> >  	.clk		= "l4ls_gclk",
> > -	.addr		= am33xx_mcspi1_addr_space,
> >  	.user		= OCP_USER_MPU,
> >  };
> >
> > -/* l4 wkup -> timer1 */
> > -static struct omap_hwmod_addr_space am33xx_timer1_addr_space[] = {
> > -	{
> > -		.pa_start	= 0x44E31000,
> > -		.pa_end		= 0x44E31000 + SZ_1K - 1,
> > -		.flags		= ADDR_TYPE_RT
> > -	},
> > -	{ }
> > -};
> > -
> >  static struct omap_hwmod_ocp_if am33xx_l4_wkup__timer1 = {
> >  	.master		= &am33xx_l4_wkup_hwmod,
> >  	.slave		= &am33xx_timer1_hwmod,
> >  	.clk		= "dpll_core_m4_div2_ck",
> > -	.addr		= am33xx_timer1_addr_space,
> >  	.user		= OCP_USER_MPU,
> >  };
> >
> > -/* l4 per -> timer2 */
> > -static struct omap_hwmod_addr_space am33xx_timer2_addr_space[] = {
> > -	{
> > -		.pa_start	= 0x48040000,
> > -		.pa_end		= 0x48040000 + SZ_1K - 1,
> > -		.flags		= ADDR_TYPE_RT
> > -	},
> > -	{ }
> > -};
> > -
> >  static struct omap_hwmod_ocp_if am33xx_l4_ls__timer2 = {
> >  	.master		= &am33xx_l4_ls_hwmod,
> >  	.slave		= &am33xx_timer2_hwmod,
> >  	.clk		= "l4ls_gclk",
> > -	.addr		= am33xx_timer2_addr_space,
> >  	.user		= OCP_USER_MPU,
> >  };
> >
> > -/* l4 per -> timer3 */
> > -static struct omap_hwmod_addr_space am33xx_timer3_addr_space[] = {
> > -	{
> > -		.pa_start	= 0x48042000,
> > -		.pa_end		= 0x48042000 + SZ_1K - 1,
> > -		.flags		= ADDR_TYPE_RT
> > -	},
> > -	{ }
> > -};
> > -
> >  static struct omap_hwmod_ocp_if am33xx_l4_ls__timer3 = {
> >  	.master		= &am33xx_l4_ls_hwmod,
> >  	.slave		= &am33xx_timer3_hwmod,
> >  	.clk		= "l4ls_gclk",
> > -	.addr		= am33xx_timer3_addr_space,
> >  	.user		= OCP_USER_MPU,
> >  };
> >
> > -/* l4 per -> timer4 */
> > -static struct omap_hwmod_addr_space am33xx_timer4_addr_space[] = {
> > -	{
> > -		.pa_start	= 0x48044000,
> > -		.pa_end		= 0x48044000 + SZ_1K - 1,
> > -		.flags		= ADDR_TYPE_RT
> > -	},
> > -	{ }
> > -};
> > -
> >  static struct omap_hwmod_ocp_if am33xx_l4_ls__timer4 = {
> >  	.master		= &am33xx_l4_ls_hwmod,
> >  	.slave		= &am33xx_timer4_hwmod,
> >  	.clk		= "l4ls_gclk",
> > -	.addr		= am33xx_timer4_addr_space,
> >  	.user		= OCP_USER_MPU,
> >  };
> >
> > -/* l4 per -> timer5 */
> > -static struct omap_hwmod_addr_space am33xx_timer5_addr_space[] = {
> > -	{
> > -		.pa_start	= 0x48046000,
> > -		.pa_end		= 0x48046000 + SZ_1K - 1,
> > -		.flags		= ADDR_TYPE_RT
> > -	},
> > -	{ }
> > -};
> > -
> >  static struct omap_hwmod_ocp_if am33xx_l4_ls__timer5 = {
> >  	.master		= &am33xx_l4_ls_hwmod,
> >  	.slave		= &am33xx_timer5_hwmod,
> >  	.clk		= "l4ls_gclk",
> > -	.addr		= am33xx_timer5_addr_space,
> >  	.user		= OCP_USER_MPU,
> >  };
> >
> > -/* l4 per -> timer6 */
> > -static struct omap_hwmod_addr_space am33xx_timer6_addr_space[] = {
> > -	{
> > -		.pa_start	= 0x48048000,
> > -		.pa_end		= 0x48048000 + SZ_1K - 1,
> > -		.flags		= ADDR_TYPE_RT
> > -	},
> > -	{ }
> > -};
> > -
> >  static struct omap_hwmod_ocp_if am33xx_l4_ls__timer6 = {
> >  	.master		= &am33xx_l4_ls_hwmod,
> >  	.slave		= &am33xx_timer6_hwmod,
> >  	.clk		= "l4ls_gclk",
> > -	.addr		= am33xx_timer6_addr_space,
> >  	.user		= OCP_USER_MPU,
> >  };
> >
> > -/* l4 per -> timer7 */
> > -static struct omap_hwmod_addr_space am33xx_timer7_addr_space[] = {
> > -	{
> > -		.pa_start	= 0x4804A000,
> > -		.pa_end		= 0x4804A000 + SZ_1K - 1,
> > -		.flags		= ADDR_TYPE_RT
> > -	},
> > -	{ }
> > -};
> > -
> >  static struct omap_hwmod_ocp_if am33xx_l4_ls__timer7 = {
> >  	.master		= &am33xx_l4_ls_hwmod,
> >  	.slave		= &am33xx_timer7_hwmod,
> >  	.clk		= "l4ls_gclk",
> > -	.addr		= am33xx_timer7_addr_space,
> >  	.user		= OCP_USER_MPU,
> >  };
> >
> > -/* l3 main -> tpcc */
> > -static struct omap_hwmod_addr_space am33xx_tpcc_addr_space[] = {
> > -	{
> > -		.pa_start	= 0x49000000,
> > -		.pa_end		= 0x49000000 + SZ_32K - 1,
> > -		.flags		= ADDR_TYPE_RT
> > -	},
> > -	{ }
> > -};
> > -
> >  static struct omap_hwmod_ocp_if am33xx_l3_main__tpcc = {
> >  	.master		= &am33xx_l3_main_hwmod,
> >  	.slave		= &am33xx_tpcc_hwmod,
> >  	.clk		= "l3_gclk",
> > -	.addr		= am33xx_tpcc_addr_space,
> > -	.user		= OCP_USER_MPU,
> > -};
> > -
> > -/* l3 main -> tpcc0 */
> > -static struct omap_hwmod_addr_space am33xx_tptc0_addr_space[] = {
> > -	{
> > -		.pa_start	= 0x49800000,
> > -		.pa_end		= 0x49800000 + SZ_8K - 1,
> > -		.flags		= ADDR_TYPE_RT,
> > -	},
> > -	{ }
> > -};
> > -
> > -static struct omap_hwmod_ocp_if am33xx_l3_main__tptc0 = {
> > -	.master		= &am33xx_l3_main_hwmod,
> > -	.slave		= &am33xx_tptc0_hwmod,
> > -	.clk		= "l3_gclk",
> > -	.addr		= am33xx_tptc0_addr_space,
> > -	.user		= OCP_USER_MPU,
> > -};
> > -
> > -/* l3 main -> tpcc1 */
> > -static struct omap_hwmod_addr_space am33xx_tptc1_addr_space[] = {
> > -	{
> > -		.pa_start	= 0x49900000,
> > -		.pa_end		= 0x49900000 + SZ_8K - 1,
> > -		.flags		= ADDR_TYPE_RT,
> > -	},
> > -	{ }
> > -};
> > -
> > -static struct omap_hwmod_ocp_if am33xx_l3_main__tptc1 = {
> > -	.master		= &am33xx_l3_main_hwmod,
> > -	.slave		= &am33xx_tptc1_hwmod,
> > -	.clk		= "l3_gclk",
> > -	.addr		= am33xx_tptc1_addr_space,
> >  	.user		= OCP_USER_MPU,
> >  };
> >
> > -/* l3 main -> tpcc2 */
> > -static struct omap_hwmod_addr_space am33xx_tptc2_addr_space[] = {
> > -	{
> > -		.pa_start	= 0x49a00000,
> > -		.pa_end		= 0x49a00000 + SZ_8K - 1,
> > -		.flags		= ADDR_TYPE_RT,
> > -	},
> > -	{ }
> > -};
> > -
> > -static struct omap_hwmod_ocp_if am33xx_l3_main__tptc2 = {
> > -	.master		= &am33xx_l3_main_hwmod,
> > -	.slave		= &am33xx_tptc2_hwmod,
> > -	.clk		= "l3_gclk",
> > -	.addr		= am33xx_tptc2_addr_space,
> > -	.user		= OCP_USER_MPU,
> > -};
> > -
> > -/* l4 wkup -> uart1 */
> > -static struct omap_hwmod_addr_space am33xx_uart1_addr_space[] = {
> > -	{
> > -		.pa_start	= 0x44E09000,
> > -		.pa_end		= 0x44E09000 + SZ_8K - 1,
> > -		.flags		= ADDR_TYPE_RT,
> > -	},
> > -	{ }
> > -};
> > -
> >  static struct omap_hwmod_ocp_if am33xx_l4_wkup__uart1 = {
> >  	.master		= &am33xx_l4_wkup_hwmod,
> >  	.slave		= &am33xx_uart1_hwmod,
> >  	.clk		= "dpll_core_m4_div2_ck",
> > -	.addr		= am33xx_uart1_addr_space,
> >  	.user		= OCP_USER_MPU,
> >  };
> >
> > -/* l4 ls -> uart2 */
> > -static struct omap_hwmod_addr_space am33xx_uart2_addr_space[] = {
> > -	{
> > -		.pa_start	= 0x48022000,
> > -		.pa_end		= 0x48022000 + SZ_8K - 1,
> > -		.flags		= ADDR_TYPE_RT,
> > -	},
> > -	{ }
> > -};
> > -
> >  static struct omap_hwmod_ocp_if am33xx_l4_ls__uart2 = {
> >  	.master		= &am33xx_l4_ls_hwmod,
> >  	.slave		= &am33xx_uart2_hwmod,
> >  	.clk		= "l4ls_gclk",
> > -	.addr		= am33xx_uart2_addr_space,
> >  	.user		= OCP_USER_MPU,
> >  };
> >
> > -/* l4 ls -> uart3 */
> > -static struct omap_hwmod_addr_space am33xx_uart3_addr_space[] = {
> > -	{
> > -		.pa_start	= 0x48024000,
> > -		.pa_end		= 0x48024000 + SZ_8K - 1,
> > -		.flags		= ADDR_TYPE_RT,
> > -	},
> > -	{ }
> > -};
> > -
> >  static struct omap_hwmod_ocp_if am33xx_l4_ls__uart3 = {
> >  	.master		= &am33xx_l4_ls_hwmod,
> >  	.slave		= &am33xx_uart3_hwmod,
> >  	.clk		= "l4ls_gclk",
> > -	.addr		= am33xx_uart3_addr_space,
> >  	.user		= OCP_USER_MPU,
> >  };
> >
> > -/* l4 ls -> uart4 */
> > -static struct omap_hwmod_addr_space am33xx_uart4_addr_space[] = {
> > -	{
> > -		.pa_start	= 0x481A6000,
> > -		.pa_end		= 0x481A6000 + SZ_8K - 1,
> > -		.flags		= ADDR_TYPE_RT,
> > -	},
> > -	{ }
> > -};
> > -
> >  static struct omap_hwmod_ocp_if am33xx_l4_ls__uart4 = {
> >  	.master		= &am33xx_l4_ls_hwmod,
> >  	.slave		= &am33xx_uart4_hwmod,
> >  	.clk		= "l4ls_gclk",
> > -	.addr		= am33xx_uart4_addr_space,
> >  	.user		= OCP_USER_MPU,
> >  };
> >
> > -/* l4 ls -> uart5 */
> > -static struct omap_hwmod_addr_space am33xx_uart5_addr_space[] = {
> > -	{
> > -		.pa_start	= 0x481A8000,
> > -		.pa_end		= 0x481A8000 + SZ_8K - 1,
> > -		.flags		= ADDR_TYPE_RT,
> > -	},
> > -	{ }
> > -};
> > -
> >  static struct omap_hwmod_ocp_if am33xx_l4_ls__uart5 = {
> >  	.master		= &am33xx_l4_ls_hwmod,
> >  	.slave		= &am33xx_uart5_hwmod,
> >  	.clk		= "l4ls_gclk",
> > -	.addr		= am33xx_uart5_addr_space,
> >  	.user		= OCP_USER_MPU,
> >  };
> >
> > -/* l4 ls -> uart6 */
> > -static struct omap_hwmod_addr_space am33xx_uart6_addr_space[] = {
> > -	{
> > -		.pa_start	= 0x481aa000,
> > -		.pa_end		= 0x481aa000 + SZ_8K - 1,
> > -		.flags		= ADDR_TYPE_RT,
> > -	},
> > -	{ }
> > -};
> > -
> >  static struct omap_hwmod_ocp_if am33xx_l4_ls__uart6 = {
> >  	.master		= &am33xx_l4_ls_hwmod,
> >  	.slave		= &am33xx_uart6_hwmod,
> >  	.clk		= "l4ls_gclk",
> > -	.addr		= am33xx_uart6_addr_space,
> >  	.user		= OCP_USER_MPU,
> >  };
> >
> >  /* l4 wkup -> wd_timer1 */
> > -static struct omap_hwmod_addr_space am33xx_wd_timer1_addrs[] = {
> > -	{
> > -		.pa_start	= 0x44e35000,
> > -		.pa_end		= 0x44e35000 + SZ_4K - 1,
> > -		.flags		= ADDR_TYPE_RT
> > -	},
> > -	{ }
> > -};
> > -
> >  static struct omap_hwmod_ocp_if am33xx_l4_wkup__wd_timer1 = {
> >  	.master		= &am33xx_l4_wkup_hwmod,
> >  	.slave		= &am33xx_wd_timer1_hwmod,
> >  	.clk		= "dpll_core_m4_div2_ck",
> > -	.addr		= am33xx_wd_timer1_addrs,
> >  	.user		= OCP_USER_MPU,
> >  };
> >
> >  /* usbss */
> >  /* l3 s -> USBSS interface */
> > -static struct omap_hwmod_addr_space am33xx_usbss_addr_space[] = {
> > -	{
> > -		.name		= "usbss",
> > -		.pa_start	= 0x47400000,
> > -		.pa_end		= 0x47400000 + SZ_4K - 1,
> > -		.flags		= ADDR_TYPE_RT
> > -	},
> > -	{
> > -		.name		= "musb0",
> > -		.pa_start	= 0x47401000,
> > -		.pa_end		= 0x47401000 + SZ_2K - 1,
> > -		.flags		= ADDR_TYPE_RT
> > -	},
> > -	{
> > -		.name		= "musb1",
> > -		.pa_start	= 0x47401800,
> > -		.pa_end		= 0x47401800 + SZ_2K - 1,
> > -		.flags		= ADDR_TYPE_RT
> > -	},
> > -	{ }
> > -};
> > -
> >  static struct omap_hwmod_ocp_if am33xx_l3_s__usbss = {
> >  	.master		= &am33xx_l3_s_hwmod,
> >  	.slave		= &am33xx_usbss_hwmod,
> >  	.clk		= "l3s_gclk",
> > -	.addr		= am33xx_usbss_addr_space,
> >  	.user		= OCP_USER_MPU,
> >  	.flags		= OCPIF_SWSUP_IDLE,
> >  };
> > @@ -3450,13 +1513,10 @@ static struct omap_hwmod_ocp_if
> > am33xx_l3_main__ocmc = {
> >  };
> >
> >  static struct omap_hwmod_ocp_if *am33xx_hwmod_ocp_ifs[] __initdata =
> {
> > -	&am33xx_l4_fw__emif_fw,
> > -	&am33xx_l3_main__emif,
> >  	&am33xx_mpu__l3_main,
> >  	&am33xx_mpu__prcm,
> >  	&am33xx_l3_s__l4_ls,
> >  	&am33xx_l3_s__l4_wkup,
> > -	&am33xx_l3_s__l4_fw,
> >  	&am33xx_l3_main__l4_hs,
> >  	&am33xx_l3_main__l3_s,
> >  	&am33xx_l3_main__l3_instr,
> > @@ -3474,7 +1534,6 @@ static struct omap_hwmod_ocp_if
> > *am33xx_hwmod_ocp_ifs[] __initdata = {
> >  	&am33xx_l4_wkup__rtc,
> >  	&am33xx_l4_wkup__i2c1,
> >  	&am33xx_l4_wkup__gpio0,
> > -	&am33xx_l4_wkup__adc_tsc,
> >  	&am33xx_l4_wkup__wd_timer1,
> >  	&am33xx_l4_hs__pruss,
> >  	&am33xx_l4_per__dcan0,
> > @@ -3484,14 +1543,6 @@ static struct omap_hwmod_ocp_if
> > *am33xx_hwmod_ocp_ifs[] __initdata = {
> >  	&am33xx_l4_per__gpio3,
> >  	&am33xx_l4_per__i2c2,
> >  	&am33xx_l4_per__i2c3,
> > -	&am33xx_l4_per__mailbox,
> > -	&am33xx_l4_ls__mcasp0,
> > -	&am33xx_l3_s__mcasp0_data,
> > -	&am33xx_l4_ls__mcasp1,
> > -	&am33xx_l3_s__mcasp1_data,
> > -	&am33xx_l4_ls__mmc0,
> > -	&am33xx_l4_ls__mmc1,
> > -	&am33xx_l3_s__mmc2,
> >  	&am33xx_l4_ls__timer2,
> >  	&am33xx_l4_ls__timer3,
> >  	&am33xx_l4_ls__timer4,
> > @@ -3505,26 +1556,8 @@ static struct omap_hwmod_ocp_if
> > *am33xx_hwmod_ocp_ifs[] __initdata = {
> >  	&am33xx_l4_ls__uart5,
> >  	&am33xx_l4_ls__uart6,
> >  	&am33xx_l4_ls__spinlock,
> > -	&am33xx_l4_ls__elm,
> > -	&am33xx_l4_ls__epwmss0,
> > -	&am33xx_epwmss0__ecap0,
> > -	&am33xx_epwmss0__eqep0,
> > -	&am33xx_epwmss0__ehrpwm0,
> > -	&am33xx_l4_ls__epwmss1,
> > -	&am33xx_epwmss1__ecap1,
> > -	&am33xx_epwmss1__eqep1,
> > -	&am33xx_epwmss1__ehrpwm1,
> > -	&am33xx_l4_ls__epwmss2,
> > -	&am33xx_epwmss2__ecap2,
> > -	&am33xx_epwmss2__eqep2,
> > -	&am33xx_epwmss2__ehrpwm2,
> > -	&am33xx_l3_s__gpmc,
> > -	&am33xx_l3_main__lcdc,
> >  	&am33xx_l4_ls__mcspi0,
> >  	&am33xx_l4_ls__mcspi1,
> > -	&am33xx_l3_main__tptc0,
> > -	&am33xx_l3_main__tptc1,
> > -	&am33xx_l3_main__tptc2,
> >  	&am33xx_l3_main__ocmc,
> >  	&am33xx_l3_s__usbss,
> >  	&am33xx_l4_hs__cpgmac0,
> > --
> > 1.7.9.5



From hechtb at gmail.com  Wed Apr 10 07:26:12 2013
From: hechtb at gmail.com (Bastian Hecht)
Date: Wed, 10 Apr 2013 13:26:12 +0200
Subject: [PATCH] ARM: hw_breakpoint: Do not use __cpuinitdata for
 dbg_cpu_pm_nb
In-Reply-To: <20130410111148.GA26992@mudshark.cambridge.arm.com>
References: <1365588278-5185-1-git-send-email-hechtb+renesas@gmail.com>
 <20130410111148.GA26992@mudshark.cambridge.arm.com>
Message-ID: <CABYn4szw=kE_DD1eNZ-CsM__o_cJUA5+F4M8T5-Uyf_nw+bfGg@mail.gmail.com>

2013/4/10 Will Deacon <will.deacon at arm.com>:
> On Wed, Apr 10, 2013 at 11:04:38AM +0100, Bastian Hecht wrote:
>> We must not declare dbg_cpu_pm_nb as __cpuinitdata as we need it after
>> system initialization for Suspend and CPUIdle.
>>
>> This was done in commit 9a6eb310eaa5336b89a27a0bbb78da4bba35f6f1
>> ARM: hw_breakpoint: Debug powerdown support for self-hosted debug
>>
>> Signed-off-by: Bastian Hecht <hechtb+renesas at gmail.com>
>
> Thanks Bastian, I'll take this into my tree.
>
> Will

Nice, thanks!


From santosh.shilimkar at ti.com  Wed Apr 10 07:32:21 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Wed, 10 Apr 2013 17:02:21 +0530
Subject: [GIT PULL] ARM: OMAP5: hwmod, prm/cm data files and updates for
 3.10
In-Reply-To: <79CD15C6BA57404B839C016229A409A83EC4A81D@DBDE01.ent.ti.com>
References: <1363768852-18125-1-git-send-email-santosh.shilimkar@ti.com>
 <20130401170539.GK10155@atomide.com> <515BA76D.3000302@ti.com>
 <alpine.DEB.2.00.1304031146230.2616@utopia.booyaka.com>
 <515D6020.2030103@ti.com> <20130404165208.GI10155@atomide.com>
 <515DB110.9000503@ti.com> <515F00B8.3000501@ti.com>
 <79CD15C6BA57404B839C016229A409A83EC4A81D@DBDE01.ent.ti.com>
Message-ID: <51654DC5.2040909@ti.com>

On Wednesday 10 April 2013 04:45 PM, Hiremath, Vaibhav wrote:
>> -----Original Message-----
>> From: Shilimkar, Santosh
>> Sent: Friday, April 05, 2013 10:20 PM
>> To: Tony Lindgren
>> Cc: Paul Walmsley; linux-omap at vger.kernel.org; linux-arm-
>> kernel at lists.infradead.org; Kristo, Tero; Menon, Nishanth; Nayak,
>> Rajendra; Valentin, Eduardo; Anna, Suman; Bedia, Vaibhav; Hiremath,
>> Vaibhav
>> Subject: Re: [GIT PULL] ARM: OMAP5: hwmod, prm/cm data files and
>> updates for 3.10
>>
>> On Thursday 04 April 2013 10:27 PM, Santosh Shilimkar wrote:
>>> On Thursday 04 April 2013 10:22 PM, Tony Lindgren wrote:
>>>> * Santosh Shilimkar <santosh.shilimkar at ti.com> [130404 04:15]:
>> [..]
>>
>>>> Can't we already trim the am33xx hwmod data after your patches for
>>>> v3.10 as am33xx is already DT only? Unfortunately we cannot create
>>>> negative diffstat in other ways for v3.10 merge window as we cannot
>>>> make omap4 DT only just quite yet.
>>>>
>>> Yes we can and I can take a stab it tomorrow. The only thing is I
>>> might need some support for testing but thats manageable. Will
>>> take a stab at it tomorrow and if everything goes well, post a
>>> patch for smae.
>>>
>> Patch for the AM33XX to trim is end of the email. Thanks to
>> Sricharan and Pekon for patch and testing. Looping both
>> Vaibhav's if they have any objection on the patch.
>>
>> Regards,
>> Santosh
>>
>> From b95dd33fe59b8e77727eb3b1717d763bbf9a2893 Mon Sep 17 00:00:00 2001
>> From: Sricharan R <r.sricharan at ti.com>
>> Date: Fri, 5 Apr 2013 20:39:12 +0530
>> Subject: [PATCH] ARM: AM33XX: hwmod data: Clean up the data file
>>
>> - The IO resource information like dma request lines, irq number and
>> ocp address space can be populated via dt blob. So such data can be
>> stripped
>> from SOC hwmod data file.
>>
>> - The devices like adc, mailbox, gpmc which are missing the device
>> tree bindings, hwmod data is not added since AM33XX is DT only build.
>> When such devices add the dt bindings, respective hwmod data can be
>> added along with it.
>>
> This seems unnecessary churn to me. DT bindings for most of the devices 
> which you mentioned above are submitted and are at various stages of review
> process.
> 
> ADC:
> 
> GPMC:
> 
> PWM:
>
The modules are dropped as per what is going for 3.10 merge window.
Above 3 modules can be retained if the DT conversion patches are
under review and can go along with this patch most likely for 3.11.
 
> 
>> - The hwmod like firewall etc which are not useful are also dropped.
>>
>> This gets us around ~2000 loc of negative diff. Patch is boot tested on
>> AM335X EVM.
>>
> I would not recommend to get into unnecessary code churn in the future just 
> to reduce temp Number of Lines of code. This will also kill our autogeneration 
> concept as well.
>
It doesn't break any concept. We just autogenrate what is *useful* rather.
BTW, I didn't find any srcipt to auto-generate the AM33XX data so we have
to manually do the updates. Can you send me a pointer if you have a sript
for this. With script it is much simpler to clean-up the data.

 
> I would suggest you to just alone drop base-addr, irq and dma references
> from hwmod entries.
> 
That we are doing anyways. Apart from that we should also clean-up data
which is not used and useful. Why do you need unused data like firewall and
friends ? 

So as I understood, you would like to keep the data for ADC, PWM and GPMC
which is fine by me. We just need those DT bindings in place so that they
go together. Who is following the DT patches for these ? 

Thanks for looking into it Vaibhav.

Regards,
Santosh


From mpa at pengutronix.de  Wed Apr 10 07:33:04 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Wed, 10 Apr 2013 13:33:04 +0200
Subject: [PATCH v2 08/11] ASoC: fsl-ssi: imx ac97 support
In-Reply-To: <5162301F.9090000@tabi.org>
References: <1365362721-3731-1-git-send-email-mpa@pengutronix.de>
 <1365362721-3731-9-git-send-email-mpa@pengutronix.de>
 <5162301F.9090000@tabi.org>
Message-ID: <20130410113304.GB16749@pengutronix.de>

On Sun, Apr 07, 2013 at 09:49:03PM -0500, Timur Tabi wrote:
> Markus Pargmann wrote:
> >This patch copies some parts from imx-ssi to support AC97 on
> >imx27-pca100 and imx27-pcm043. It is activated with a new fsl,imx-ac97
> >bool property. It was tested on imx27-pca100.
> 
> I'm not crazy about this patch -- it seems a bit hackish.  There are
> too many "if (imx_ac97)" clauses.  Large pieces of code that don't
> appear to be related to AC97 are indented in an if-clause.  I
> especially don't like the "If we use AC97, the registers are already
> setup correctly".
> 

I will try to seperate it a little bit cleaner by using different dai
ops for ac97 for the two big ifs and perhaps use a seperated register
setup function so it can be used from ssi startup and ac97_setup.

Regards,

Markus

> -- 
> Timur Tabi
> 

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From nsekhar at ti.com  Wed Apr 10 07:35:24 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Wed, 10 Apr 2013 17:05:24 +0530
Subject: [PATCH v4] ARM: davinci: da850: add EHRPWM & ECAP DT node
In-Reply-To: <1365580939-16839-1-git-send-email-avinashphilip@ti.com>
References: <1365580939-16839-1-git-send-email-avinashphilip@ti.com>
Message-ID: <51654E7C.5020107@ti.com>

Avinash,

On 4/10/2013 1:32 PM, Philip Avinash wrote:
> Add da850 EHRPWM & ECAP DT node along with pin-mux details for EHRPWM1.
> Also adds OF_DEV_AUXDATA for EHRPWM & ECAP driver to use EHRPWM & ECAP
> clock.
> 
> Signed-off-by: Philip Avinash <avinashphilip at ti.com>
> ---
> Changes since v3:
> 	- add pin mux info for EHRPWM1.

I think you misunderstood what I asked. Please add pinmux information
for all the nodes you are adding (ecap0-2 and ehrpwm0). Without pinmux
setup, these IPs cannot be used anyway. So why leave just the pinmux to
be added by someone else?

Thanks,
Sekhar

> 
> Changes since v1:
> 	- Reusing ti,am33xx<ecap/ehrpwm> as compatible field as both IP's are
> 	  similar with am33xx platform and da850 has no platform specific
> 	  dependency.
> 
>  arch/arm/boot/dts/da850.dtsi     |   42 ++++++++++++++++++++++++++++++++++++++
>  arch/arm/mach-davinci/da8xx-dt.c |    5 +++++
>  2 files changed, 47 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
> index 3ade343..3bff30d 100644
> --- a/arch/arm/boot/dts/da850.dtsi
> +++ b/arch/arm/boot/dts/da850.dtsi
> @@ -71,6 +71,18 @@
>  					0x28 0x00222222  0x00ffffff
>  				>;
>  			};
> +			ehrpwm1a_pins: pinmux_ehrpwm1a_pins {
> +				pinctrl-single,bits = <
> +					/* EPWM1A */
> +					0x14 0x00000002 0x0000000f
> +				>;
> +			};
> +			ehrpwm1b_pins: pinmux_ehrpwm1b_pins {
> +				pinctrl-single,bits = <
> +					/* EPWM1B */
> +					0x14 0x00000020 0x000000f0
> +				>;
> +			};
>  		};
>  		serial0: serial at 1c42000 {
>  			compatible = "ns16550a";
> @@ -122,6 +134,36 @@
>  			interrupts = <16>;
>  			status = "disabled";
>  		};
> +		ehrpwm0: ehrpwm at 01f00000 {
> +			compatible = "ti,da850-ehrpwm", "ti,am33xx-ehrpwm";
> +			#pwm-cells = <3>;
> +			reg = <0x300000 0x2000>;
> +			status = "disabled";
> +		};
> +		ehrpwm1: ehrpwm at 01f02000 {
> +			compatible = "ti,da850-ehrpwm", "ti,am33xx-ehrpwm";
> +			#pwm-cells = <3>;
> +			reg = <0x302000 0x2000>;
> +			status = "disabled";
> +		};
> +		ecap0: ecap at 01f06000 {
> +			compatible = "ti,da850-ecap", "ti,am33xx-ecap";
> +			#pwm-cells = <3>;
> +			reg = <0x306000 0x80>;
> +			status = "disabled";
> +		};
> +		ecap1: ecap at 01f07000 {
> +			compatible = "ti,da850-ecap", "ti,am33xx-ecap";
> +			#pwm-cells = <3>;
> +			reg = <0x307000 0x80>;
> +			status = "disabled";
> +		};
> +		ecap2: ecap at 01f08000 {
> +			compatible = "ti,da850-ecap", "ti,am33xx-ecap";
> +			#pwm-cells = <3>;
> +			reg = <0x308000 0x80>;
> +			status = "disabled";
> +		};
>  	};
>  	nand_cs3 at 62000000 {
>  		compatible = "ti,davinci-nand";
> diff --git a/arch/arm/mach-davinci/da8xx-dt.c b/arch/arm/mach-davinci/da8xx-dt.c
> index d83de8f..05bb9a2 100644
> --- a/arch/arm/mach-davinci/da8xx-dt.c
> +++ b/arch/arm/mach-davinci/da8xx-dt.c
> @@ -41,6 +41,11 @@ struct of_dev_auxdata da850_auxdata_lookup[] __initdata = {
>  	OF_DEV_AUXDATA("ti,davinci-i2c", 0x01c22000, "i2c_davinci.1", NULL),
>  	OF_DEV_AUXDATA("ti,davinci-wdt", 0x01c21000, "watchdog", NULL),
>  	OF_DEV_AUXDATA("ti,da830-mmc", 0x01c40000, "da830-mmc.0", NULL),
> +	OF_DEV_AUXDATA("ti,da850-ehrpwm", 0x01f00000, "ehrpwm", NULL),
> +	OF_DEV_AUXDATA("ti,da850-ehrpwm", 0x01f02000, "ehrpwm", NULL),
> +	OF_DEV_AUXDATA("ti,da850-ecap", 0x01f06000, "ecap", NULL),
> +	OF_DEV_AUXDATA("ti,da850-ecap", 0x01f07000, "ecap", NULL),
> +	OF_DEV_AUXDATA("ti,da850-ecap", 0x01f08000, "ecap", NULL),
>  	{}
>  };
>  
> 


From avinashphilip at ti.com  Wed Apr 10 07:38:26 2013
From: avinashphilip at ti.com (Philip, Avinash)
Date: Wed, 10 Apr 2013 11:38:26 +0000
Subject: [PATCH v4] ARM: davinci: da850: add EHRPWM & ECAP DT node
In-Reply-To: <51654E7C.5020107@ti.com>
References: <1365580939-16839-1-git-send-email-avinashphilip@ti.com>
 <51654E7C.5020107@ti.com>
Message-ID: <518397C60809E147AF5323E0420B992E3EAAB3C1@DBDE01.ent.ti.com>

On Wed, Apr 10, 2013 at 17:05:24, Nori, Sekhar wrote:
> Avinash,
> 
> On 4/10/2013 1:32 PM, Philip Avinash wrote:
> > Add da850 EHRPWM & ECAP DT node along with pin-mux details for EHRPWM1.
> > Also adds OF_DEV_AUXDATA for EHRPWM & ECAP driver to use EHRPWM & ECAP
> > clock.
> > 
> > Signed-off-by: Philip Avinash <avinashphilip at ti.com>
> > ---
> > Changes since v3:
> > 	- add pin mux info for EHRPWM1.
> 
> I think you misunderstood what I asked. Please add pinmux information
> for all the nodes you are adding (ecap0-2 and ehrpwm0). Without pinmux
> setup, these IPs cannot be used anyway. So why leave just the pinmux to
> be added by someone else?

Ok I will add and send updated version.

Thanks
Avinash

> 
> Thanks,
> Sekhar
> 
> > 
> > Changes since v1:
> > 	- Reusing ti,am33xx<ecap/ehrpwm> as compatible field as both IP's are
> > 	  similar with am33xx platform and da850 has no platform specific
> > 	  dependency.
> > 
> >  arch/arm/boot/dts/da850.dtsi     |   42 ++++++++++++++++++++++++++++++++++++++
> >  arch/arm/mach-davinci/da8xx-dt.c |    5 +++++
> >  2 files changed, 47 insertions(+)
> > 
> > diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
> > index 3ade343..3bff30d 100644
> > --- a/arch/arm/boot/dts/da850.dtsi
> > +++ b/arch/arm/boot/dts/da850.dtsi
> > @@ -71,6 +71,18 @@
> >  					0x28 0x00222222  0x00ffffff
> >  				>;
> >  			};
> > +			ehrpwm1a_pins: pinmux_ehrpwm1a_pins {
> > +				pinctrl-single,bits = <
> > +					/* EPWM1A */
> > +					0x14 0x00000002 0x0000000f
> > +				>;
> > +			};
> > +			ehrpwm1b_pins: pinmux_ehrpwm1b_pins {
> > +				pinctrl-single,bits = <
> > +					/* EPWM1B */
> > +					0x14 0x00000020 0x000000f0
> > +				>;
> > +			};
> >  		};
> >  		serial0: serial at 1c42000 {
> >  			compatible = "ns16550a";
> > @@ -122,6 +134,36 @@
> >  			interrupts = <16>;
> >  			status = "disabled";
> >  		};
> > +		ehrpwm0: ehrpwm at 01f00000 {
> > +			compatible = "ti,da850-ehrpwm", "ti,am33xx-ehrpwm";
> > +			#pwm-cells = <3>;
> > +			reg = <0x300000 0x2000>;
> > +			status = "disabled";
> > +		};
> > +		ehrpwm1: ehrpwm at 01f02000 {
> > +			compatible = "ti,da850-ehrpwm", "ti,am33xx-ehrpwm";
> > +			#pwm-cells = <3>;
> > +			reg = <0x302000 0x2000>;
> > +			status = "disabled";
> > +		};
> > +		ecap0: ecap at 01f06000 {
> > +			compatible = "ti,da850-ecap", "ti,am33xx-ecap";
> > +			#pwm-cells = <3>;
> > +			reg = <0x306000 0x80>;
> > +			status = "disabled";
> > +		};
> > +		ecap1: ecap at 01f07000 {
> > +			compatible = "ti,da850-ecap", "ti,am33xx-ecap";
> > +			#pwm-cells = <3>;
> > +			reg = <0x307000 0x80>;
> > +			status = "disabled";
> > +		};
> > +		ecap2: ecap at 01f08000 {
> > +			compatible = "ti,da850-ecap", "ti,am33xx-ecap";
> > +			#pwm-cells = <3>;
> > +			reg = <0x308000 0x80>;
> > +			status = "disabled";
> > +		};
> >  	};
> >  	nand_cs3 at 62000000 {
> >  		compatible = "ti,davinci-nand";
> > diff --git a/arch/arm/mach-davinci/da8xx-dt.c b/arch/arm/mach-davinci/da8xx-dt.c
> > index d83de8f..05bb9a2 100644
> > --- a/arch/arm/mach-davinci/da8xx-dt.c
> > +++ b/arch/arm/mach-davinci/da8xx-dt.c
> > @@ -41,6 +41,11 @@ struct of_dev_auxdata da850_auxdata_lookup[] __initdata = {
> >  	OF_DEV_AUXDATA("ti,davinci-i2c", 0x01c22000, "i2c_davinci.1", NULL),
> >  	OF_DEV_AUXDATA("ti,davinci-wdt", 0x01c21000, "watchdog", NULL),
> >  	OF_DEV_AUXDATA("ti,da830-mmc", 0x01c40000, "da830-mmc.0", NULL),
> > +	OF_DEV_AUXDATA("ti,da850-ehrpwm", 0x01f00000, "ehrpwm", NULL),
> > +	OF_DEV_AUXDATA("ti,da850-ehrpwm", 0x01f02000, "ehrpwm", NULL),
> > +	OF_DEV_AUXDATA("ti,da850-ecap", 0x01f06000, "ecap", NULL),
> > +	OF_DEV_AUXDATA("ti,da850-ecap", 0x01f07000, "ecap", NULL),
> > +	OF_DEV_AUXDATA("ti,da850-ecap", 0x01f08000, "ecap", NULL),
> >  	{}
> >  };
> >  
> > 
> 


From will.deacon at arm.com  Wed Apr 10 07:41:27 2013
From: will.deacon at arm.com (Will Deacon)
Date: Wed, 10 Apr 2013 12:41:27 +0100
Subject: [PATCH v2] arm64: Fix task tracing
In-Reply-To: <1365510814-21343-1-git-send-email-cov@codeaurora.org>
References: <20130408153132.GQ17476@mudshark.cambridge.arm.com>
 <1365510814-21343-1-git-send-email-cov@codeaurora.org>
Message-ID: <20130410114126.GB26992@mudshark.cambridge.arm.com>

On Tue, Apr 09, 2013 at 01:33:34PM +0100, Christopher Covington wrote:
> For accurate accounting pass contextidr_thread_switch the prev
> task pointer, since cpu_switch_to has at that point changed the
> the stack pointer.
> 
> Signed-off-by: Christopher Covington <cov at codeaurora.org>

Thanks Christopher -- I assume that using prev did resolve your issues?

Will


From linux at arm.linux.org.uk  Wed Apr 10 07:42:29 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Wed, 10 Apr 2013 12:42:29 +0100
Subject: Removal of NWFPE in its entirety, and VFP emulation code
In-Reply-To: <yw1xmwt68whw.fsf@unicorn.mansr.com>
References: <20130410104002.GF14496@n2100.arm.linux.org.uk>
 <yw1xmwt68whw.fsf@unicorn.mansr.com>
Message-ID: <20130410114229.GH14496@n2100.arm.linux.org.uk>

On Wed, Apr 10, 2013 at 12:18:19PM +0100, M?ns Rullg?rd wrote:
> Russell King - ARM Linux <linux at arm.linux.org.uk> writes:
> 
> > The situation with VFP is likely less disruptive - only instructions
> > which aren't implemented in hardware (or, for example, if you ask for
> > inexact exceptions to be enabled) which are bounced to the software
> > support code will be affected.  I think OMAP should get away unscathed,
> > but ARM's implementation will bounce if inexact exceptions are enabled
> 
> What do you mean by this?  OMAP uses ARM's cores.

OMAP's VFP reports that it never traps to support code for VFP instructions,
so the emulation code is never used on OMAP.

> > or in a few corner cases.  Qualcomm is likely to be the worst affected
> > by this.
> >
> > Will Deacon has tested debian armhf on a Cortex-A15 with VFP emulation
> > support removed, which boots successfully.
> 
> Cortex-A9 and later lack hardware support for VFP vector operations.
> Any code using these will fail to run without the software emulation.
> Of course such code is already horribly slow on these cores and should
> be fixed, so perhaps this is not such a terrible thing.

It's probably not "horribly slow" because unlike NWFPE, I went to great
efforts through my derivation of softfloat to ensure that it was as fast
and efficient as possible on ARM hardware.

If we can identify those which support the full range of VFP instructions
without trapping, but not the vector operations, we could implement the
vector iterations in the support code, executing non-vectored VFP
instructions instead.

But... the problem is identifying those implementations.  We aren't told
all the details about what the implementation supports and what it traps.
:(


From ldewangan at nvidia.com  Wed Apr 10 07:47:33 2013
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Wed, 10 Apr 2013 17:17:33 +0530
Subject: [PATCH 1/2] ARM: tegra: dalmore: populate key mapping
Message-ID: <1365594454-20614-1-git-send-email-ldewangan@nvidia.com>

Keys on Dalmore interfaced through Tegra KBC controller
in key matrix topology.

Add the key mapping for the keys.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
---
The system is booted on Dalmore SKU1000 with the fastboot.

 arch/arm/boot/dts/tegra114-dalmore.dts |   12 ++++++++++++
 1 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/tegra114-dalmore.dts b/arch/arm/boot/dts/tegra114-dalmore.dts
index 72c1f27..12198d1 100644
--- a/arch/arm/boot/dts/tegra114-dalmore.dts
+++ b/arch/arm/boot/dts/tegra114-dalmore.dts
@@ -823,6 +823,18 @@
 		};
 	};
 
+	kbc {
+		status = "okay";
+		nvidia,debounce-delay-ms = <640>;
+		nvidia,repeat-delay-ms = <1>;
+		nvidia,kbc-row-pins = <0 1 2>;
+		nvidia,kbc-col-pins = <11 12 13>;
+		linux,keymap = < 0x00000074	/* KEY_POWER */
+				 0x00010066	/* KEY_HOME */
+				 0x01010072	/* KEY_VOLUMEDOWN */
+				 0x02010073>;	/* KEY_VOLUMEUP */
+	};
+
 	pmc {
 		nvidia,invert-interrupt;
 	};
-- 
1.7.1.1



From ldewangan at nvidia.com  Wed Apr 10 07:47:34 2013
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Wed, 10 Apr 2013 17:17:34 +0530
Subject: [PATCH 2/2] ARM: tegra: pluto: populate key mapping
In-Reply-To: <1365594454-20614-1-git-send-email-ldewangan@nvidia.com>
References: <1365594454-20614-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1365594454-20614-2-git-send-email-ldewangan@nvidia.com>

Keys on Pluto interfaced through Tegra KBC controller
in key matrix topology.

Add the key mapping for the keys

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
---
The system is booted on Pluto with the fastboot.

 arch/arm/boot/dts/tegra114-pluto.dts |   17 +++++++++++++++++
 1 files changed, 17 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/tegra114-pluto.dts b/arch/arm/boot/dts/tegra114-pluto.dts
index 6bbc8ef..290c9ce 100644
--- a/arch/arm/boot/dts/tegra114-pluto.dts
+++ b/arch/arm/boot/dts/tegra114-pluto.dts
@@ -14,6 +14,23 @@
 		status = "okay";
 	};
 
+	kbc {
+		status = "okay";
+		nvidia,debounce-delay-ms = <640>;
+		nvidia,repeat-delay-ms = <1>;
+		nvidia,kbc-row-pins = <0 1 2>;
+		nvidia,kbc-col-pins = <11 12 13>;
+		linux,keymap = < 0x00000074	/* KEY_POWER */
+				 0x00010073	/* KEY_VOLUMEUP */
+				 0x00020072	/* KEY_VOLUMEDOWN */
+				 0x010000D9	/* KEY_SEARCH */
+				 0x010100D4	/* KEY_CAMERA */
+				 0x010200D2	/* KEY_CAMERA_FOCUS */
+				 0x02000066	/* KEY_HOME */
+				 0x0201009E	/* KEY_BACK */
+				 0x0202008B>;	/* KEY_MENU */
+	};
+
 	pmc {
 		nvidia,invert-interrupt;
 	};
-- 
1.7.1.1



From ldewangan at nvidia.com  Wed Apr 10 07:48:03 2013
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Wed, 10 Apr 2013 17:18:03 +0530
Subject: [PATCH 2/2] ARM: tegra: dts: dalmore: enable spi4
In-Reply-To: <1365594483-20651-1-git-send-email-ldewangan@nvidia.com>
References: <1365594483-20651-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1365594483-20651-2-git-send-email-ldewangan@nvidia.com>

Enable SPI4 and add Winbond SPI flash W25Q32DW device
on CS0 line.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
---
 arch/arm/boot/dts/tegra114-dalmore.dts |   10 ++++++++++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/tegra114-dalmore.dts b/arch/arm/boot/dts/tegra114-dalmore.dts
index 12198d1..295a1be 100644
--- a/arch/arm/boot/dts/tegra114-dalmore.dts
+++ b/arch/arm/boot/dts/tegra114-dalmore.dts
@@ -823,6 +823,16 @@
 		};
 	};
 
+	spi at 7000da00 {
+		status = "okay";
+		spi-max-frequency = <25000000>;
+		spi-flash at 0 {
+			compatible = "winbond,w25q32dw";
+			reg = <0>;
+			spi-max-frequency = <20000000>;
+		};
+	};
+
 	kbc {
 		status = "okay";
 		nvidia,debounce-delay-ms = <640>;
-- 
1.7.1.1



From ldewangan at nvidia.com  Wed Apr 10 07:48:02 2013
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Wed, 10 Apr 2013 17:18:02 +0530
Subject: [PATCH 1/2] ARM: config: tegra: enable T114 SPI
Message-ID: <1365594483-20651-1-git-send-email-ldewangan@nvidia.com>

Nvidia Tegra114 has the new spi controller whose driver
is not compatible with older SoCs. The new driver is added
for Tegra114 spi controller.

Enabling the config of this driver.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
---
 arch/arm/configs/tegra_defconfig |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/arm/configs/tegra_defconfig b/arch/arm/configs/tegra_defconfig
index a5f0485..8a50fc8 100644
--- a/arch/arm/configs/tegra_defconfig
+++ b/arch/arm/configs/tegra_defconfig
@@ -121,6 +121,7 @@ CONFIG_I2C_MUX=y
 CONFIG_I2C_MUX_PINCTRL=y
 CONFIG_I2C_TEGRA=y
 CONFIG_SPI=y
+CONFIG_SPI_TEGRA114=y
 CONFIG_SPI_TEGRA20_SFLASH=y
 CONFIG_SPI_TEGRA20_SLINK=y
 CONFIG_GPIO_PCA953X_IRQ=y
-- 
1.7.1.1



From jonathan.austin at arm.com  Wed Apr 10 07:51:36 2013
From: jonathan.austin at arm.com (Jonathan Austin)
Date: Wed, 10 Apr 2013 12:51:36 +0100
Subject: v7_flush_kern_cache_louis flushes up to L2?
In-Reply-To: <CABYn4sxUCoWhC_4qydzbCtZdQdetqFZ_u5WtXsghprQget9f5g@mail.gmail.com>
References: <CABYn4sxUCoWhC_4qydzbCtZdQdetqFZ_u5WtXsghprQget9f5g@mail.gmail.com>
Message-ID: <51655248.7000401@arm.com>

Hi Bastian,

On 10/04/13 11:43, Bastian Hecht wrote:
> Hello,
>
> I've got a Cortex-A9 UP with a L2 and want to submit some PM code I've

To clarify, is this an MPCore with a single core, or a genuine UP? This 
can be established from the 'U' bit of the MPIDR.

> written. Just to make sure I've made no mistake, it would be very
> helpful if you can confirm a hypothesis I use in my code:
>
> v7_flush_kern_cache_louis: Flush the data cache up to Level of
> Unification Inner Shareable
>

Depending on whether you're SMP or UP (bearing in mind that you can be 
SMP, but still only have one processor!) the IS is ignored in the 
v7_flush_dcache_louis operation:
(from cache-v7.S)

         mrc     p15, 1, r0, c0, c0, 1           @ read clidr, r0 = clidr
         ALT_SMP(ands    r3, r0, #(7 << 21))     @ extract LoUIS from clidr
         ALT_UP(ands     r3, r0, #(7 << 27))     @ extract LoUU from clidr
         ALT_SMP(mov     r3, r3, lsr #20)        @ r3 = LoUIS * 2
         ALT_UP(mov      r3, r3, lsr #26)        @ r3 = LoUU * 2
	...
	flush levels based on value in r3

> This flushes the data out up to the L2, right? The ARM docs say that
> the Point of Unification would be my L2. I'm a bit confused by the
> term "Level of Unification Inner Shareable" (that states that in an
> SMP system L1 coherency is guaranteed and all is flushed to the L2?).
>

As you say, for the A9 (from the TRM) the CLIDR reports LoUIS is the 
same as LoUU and both specify L2.

Does that make things clearer, or are you still unsure about something?

Jonny



From mans at mansr.com  Wed Apr 10 07:58:09 2013
From: mans at mansr.com (=?iso-8859-1?Q?M=E5ns_Rullg=E5rd?=)
Date: Wed, 10 Apr 2013 12:58:09 +0100
Subject: Removal of NWFPE in its entirety, and VFP emulation code
In-Reply-To: <20130410114229.GH14496@n2100.arm.linux.org.uk> (Russell King's
 message of "Wed, 10 Apr 2013 12:42:29 +0100")
References: <20130410104002.GF14496@n2100.arm.linux.org.uk>
 <yw1xmwt68whw.fsf@unicorn.mansr.com>
 <20130410114229.GH14496@n2100.arm.linux.org.uk>
Message-ID: <yw1xip3u8uni.fsf@unicorn.mansr.com>

Russell King - ARM Linux <linux at arm.linux.org.uk> writes:

> On Wed, Apr 10, 2013 at 12:18:19PM +0100, M?ns Rullg?rd wrote:
>> Russell King - ARM Linux <linux at arm.linux.org.uk> writes:
>> 
>> > The situation with VFP is likely less disruptive - only instructions
>> > which aren't implemented in hardware (or, for example, if you ask for
>> > inexact exceptions to be enabled) which are bounced to the software
>> > support code will be affected.  I think OMAP should get away unscathed,
>> > but ARM's implementation will bounce if inexact exceptions are enabled
>> 
>> What do you mean by this?  OMAP uses ARM's cores.
>
> OMAP's VFP reports that it never traps to support code for VFP instructions,
> so the emulation code is never used on OMAP.

That is true for OMAP2 (ARM1136/VFP11) and OMAP3 (Cortex-A8).  OMAP4
(Cortex-A9) and OMAP5 (Cortex-A15) both trap on vector operations.

>> > or in a few corner cases.  Qualcomm is likely to be the worst affected
>> > by this.
>> >
>> > Will Deacon has tested debian armhf on a Cortex-A15 with VFP emulation
>> > support removed, which boots successfully.
>> 
>> Cortex-A9 and later lack hardware support for VFP vector operations.
>> Any code using these will fail to run without the software emulation.
>> Of course such code is already horribly slow on these cores and should
>> be fixed, so perhaps this is not such a terrible thing.
>
> It's probably not "horribly slow" because unlike NWFPE, I went to great
> efforts through my derivation of softfloat to ensure that it was as fast
> and efficient as possible on ARM hardware.

It's several orders of magnitude slower than not using the vector
operations.  This is as one would expect when taking a kernel trap on
almost every instruction.

-- 
M?ns Rullg?rd
mans at mansr.com


From dietmar.eggemann at arm.com  Wed Apr 10 08:04:29 2013
From: dietmar.eggemann at arm.com (Dietmar Eggemann)
Date: Wed, 10 Apr 2013 13:04:29 +0100
Subject: [PATCH] ARM: hw_breakpoint: Do not use __cpuinitdata for
 dbg_cpu_pm_nb
In-Reply-To: <CABYn4szw=kE_DD1eNZ-CsM__o_cJUA5+F4M8T5-Uyf_nw+bfGg@mail.gmail.com>
References: <1365588278-5185-1-git-send-email-hechtb+renesas@gmail.com>
 <20130410111148.GA26992@mudshark.cambridge.arm.com>
 <CABYn4szw=kE_DD1eNZ-CsM__o_cJUA5+F4M8T5-Uyf_nw+bfGg@mail.gmail.com>
Message-ID: <5165554D.3040107@arm.com>

On 10/04/13 12:26, Bastian Hecht wrote:
> 2013/4/10 Will Deacon <will.deacon at arm.com>:
>> On Wed, Apr 10, 2013 at 11:04:38AM +0100, Bastian Hecht wrote:
>>> We must not declare dbg_cpu_pm_nb as __cpuinitdata as we need it after
>>> system initialization for Suspend and CPUIdle.
>>>
>>> This was done in commit 9a6eb310eaa5336b89a27a0bbb78da4bba35f6f1
>>> ARM: hw_breakpoint: Debug powerdown support for self-hosted debug
>>>
>>> Signed-off-by: Bastian Hecht <hechtb+renesas at gmail.com>
>>
>> Thanks Bastian, I'll take this into my tree.
>>
>> Will
>
> Nice, thanks!
>

Hi Bastian,

thanks for catching this. Is my assumption right that you used an UP kernel?

I didn't catch this error during my Suspend-To-Ram/CPUidle tests because
I tested only on SMP kernels where 'dbg_cpu_pm_nb' is placed into the
.data and not in the .init.data section.


Will, we have the same issue in arch/arm/kernel/perf_event_cpu.c.
Lorenzo is currently working on an appropriate patch.

-- Dietmar

-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium.  Thank you.



From hechtb at gmail.com  Wed Apr 10 08:11:16 2013
From: hechtb at gmail.com (Bastian Hecht)
Date: Wed, 10 Apr 2013 14:11:16 +0200
Subject: [PATCH] ARM: hw_breakpoint: Do not use __cpuinitdata for
 dbg_cpu_pm_nb
In-Reply-To: <5165554D.3040107@arm.com>
References: <1365588278-5185-1-git-send-email-hechtb+renesas@gmail.com>
 <20130410111148.GA26992@mudshark.cambridge.arm.com>
 <CABYn4szw=kE_DD1eNZ-CsM__o_cJUA5+F4M8T5-Uyf_nw+bfGg@mail.gmail.com>
 <5165554D.3040107@arm.com>
Message-ID: <CABYn4szX3k2m-BZRTH3xKGChHGu212cHnEAoYakbctHOia+ibA@mail.gmail.com>

Hi Dietmar,

2013/4/10 Dietmar Eggemann <dietmar.eggemann at arm.com>:
> On 10/04/13 12:26, Bastian Hecht wrote:
>>
>> 2013/4/10 Will Deacon <will.deacon at arm.com>:
>>>
>>> On Wed, Apr 10, 2013 at 11:04:38AM +0100, Bastian Hecht wrote:
>>>>
>>>> We must not declare dbg_cpu_pm_nb as __cpuinitdata as we need it after
>>>> system initialization for Suspend and CPUIdle.
>>>>
>>>> This was done in commit 9a6eb310eaa5336b89a27a0bbb78da4bba35f6f1
>>>> ARM: hw_breakpoint: Debug powerdown support for self-hosted debug
>>>>
>>>> Signed-off-by: Bastian Hecht <hechtb+renesas at gmail.com>
>>>
>>>
>>> Thanks Bastian, I'll take this into my tree.
>>>
>>> Will
>>
>>
>> Nice, thanks!
>>
>
> Hi Bastian,
>
> thanks for catching this. Is my assumption right that you used an UP kernel?

Yes exactly, it's for a Cortex A9 UP core, so a UP kernel. Glad I could help.

> I didn't catch this error during my Suspend-To-Ram/CPUidle tests because
> I tested only on SMP kernels where 'dbg_cpu_pm_nb' is placed into the
> .data and not in the .init.data section.
>
>
> Will, we have the same issue in arch/arm/kernel/perf_event_cpu.c.
> Lorenzo is currently working on an appropriate patch.
>
> -- Dietmar
>
> -- IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium.  Thank you.
>


From rjw at sisk.pl  Wed Apr 10 08:19:30 2013
From: rjw at sisk.pl (Rafael J. Wysocki)
Date: Wed, 10 Apr 2013 14:19:30 +0200
Subject: [GIT PULL] CPUidle: OMAP cleanups for v3.10
In-Reply-To: <87txnfz31g.fsf@linaro.org>
References: <87txnfz31g.fsf@linaro.org>
Message-ID: <13035794.tRqHcUoFsl@vostro.rjw.lan>

On Tuesday, April 09, 2013 04:40:11 PM Kevin Hilman wrote:
> [resend with correct address for linux-pm]
> 
> Rafael,
> 
> Please pull the following OMAP CPUidle changes for v3.10.
> 
> Due to dependencies on other CPUidle changes that are already in your
> linux-next branch, this branch is based on the commit where you merged
> your pm-cpuidle-next branch into linux-next.
> 
> Kevin
> 
> The following changes since commit f69e44b2059f2238ac558b4a115ebcdefe20b9be:
> 
>   Merge branch 'pm-cpuidle-next' into linux-next (2013-04-08 12:32:07 +0200)
> 
> are available in the git repository at:
> 
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git tags/omap-pm-v3.10/cleanup/cpuidle-v2

Pulled into my bleeding-edge branch.  I'll move it to linux-next tomorrow.

Thanks,
Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.


From avinashphilip at ti.com  Wed Apr 10 08:12:41 2013
From: avinashphilip at ti.com (Philip Avinash)
Date: Wed, 10 Apr 2013 17:42:41 +0530
Subject: [PATCH v5] ARM: davinci: da850: add EHRPWM & ECAP DT node
Message-ID: <1365595961-4060-1-git-send-email-avinashphilip@ti.com>

Add da850 EHRPWM & ECAP DT node along with pin-mux details.
Also adds OF_DEV_AUXDATA for EHRPWM & ECAP driver to use EHRPWM & ECAP
clock.

Signed-off-by: Philip Avinash <avinashphilip at ti.com>
---
Changes since v4:
	- Add pin mux for PWM devices ECAP & EHRPWM.

Changes since v3:
	- add pin mux info for EHRPWM1.

Changes since v1:
	- Reusing ti,am33xx<ecap/ehrpwm> as compatible field as both IP's are
	  similar with am33xx platform and da850 has no platform specific
	  dependency.

 arch/arm/boot/dts/da850.dtsi     |   73 ++++++++++++++++++++++++++++++++++++++
 arch/arm/mach-davinci/da8xx-dt.c |    5 +++
 2 files changed, 78 insertions(+)

diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 3ade343..b2ae730 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -71,6 +71,49 @@
 					0x28 0x00222222  0x00ffffff
 				>;
 			};
+			ehrpwm0a_pins: pinmux_ehrpwm0a_pins {
+				pinctrl-single,bits = <
+					/* EPWM0A */
+					0xc 0x00000002 0x0000000f
+				>;
+			};
+			ehrpwm0b_pins: pinmux_ehrpwm0b_pins {
+				pinctrl-single,bits = <
+					/* EPWM0B */
+					0xc 0x00000020 0x000000f0
+				>;
+			};
+			ehrpwm1a_pins: pinmux_ehrpwm1a_pins {
+				pinctrl-single,bits = <
+					/* EPWM1A */
+					0x14 0x00000002 0x0000000f
+				>;
+			};
+			ehrpwm1b_pins: pinmux_ehrpwm1b_pins {
+				pinctrl-single,bits = <
+					/* EPWM1B */
+					0x14 0x00000020 0x000000f0
+				>;
+			};
+			ecap0_pins: pinmux_ecap0_pins {
+				pinctrl-single,bits = <
+					/* ECAP0_APWM0 */
+					0x8 0x20000000 0xf0000000
+				>;
+			};
+			ecap1_pins: pinmux_ecap1_pins {
+				pinctrl-single,bits = <
+					/* ECAP1_APWM1 */
+					0x4 0x40000000 0xf0000000
+				>;
+			};
+			ecap2_pins: pinmux_ecap2_pins {
+				pinctrl-single,bits = <
+					/* ECAP2_APWM2 */
+					0x4 0x00000004 0x0000000f
+				>;
+			};
+
 		};
 		serial0: serial at 1c42000 {
 			compatible = "ns16550a";
@@ -122,6 +165,36 @@
 			interrupts = <16>;
 			status = "disabled";
 		};
+		ehrpwm0: ehrpwm at 01f00000 {
+			compatible = "ti,da850-ehrpwm", "ti,am33xx-ehrpwm";
+			#pwm-cells = <3>;
+			reg = <0x300000 0x2000>;
+			status = "disabled";
+		};
+		ehrpwm1: ehrpwm at 01f02000 {
+			compatible = "ti,da850-ehrpwm", "ti,am33xx-ehrpwm";
+			#pwm-cells = <3>;
+			reg = <0x302000 0x2000>;
+			status = "disabled";
+		};
+		ecap0: ecap at 01f06000 {
+			compatible = "ti,da850-ecap", "ti,am33xx-ecap";
+			#pwm-cells = <3>;
+			reg = <0x306000 0x80>;
+			status = "disabled";
+		};
+		ecap1: ecap at 01f07000 {
+			compatible = "ti,da850-ecap", "ti,am33xx-ecap";
+			#pwm-cells = <3>;
+			reg = <0x307000 0x80>;
+			status = "disabled";
+		};
+		ecap2: ecap at 01f08000 {
+			compatible = "ti,da850-ecap", "ti,am33xx-ecap";
+			#pwm-cells = <3>;
+			reg = <0x308000 0x80>;
+			status = "disabled";
+		};
 	};
 	nand_cs3 at 62000000 {
 		compatible = "ti,davinci-nand";
diff --git a/arch/arm/mach-davinci/da8xx-dt.c b/arch/arm/mach-davinci/da8xx-dt.c
index d83de8f..05bb9a2 100644
--- a/arch/arm/mach-davinci/da8xx-dt.c
+++ b/arch/arm/mach-davinci/da8xx-dt.c
@@ -41,6 +41,11 @@ struct of_dev_auxdata da850_auxdata_lookup[] __initdata = {
 	OF_DEV_AUXDATA("ti,davinci-i2c", 0x01c22000, "i2c_davinci.1", NULL),
 	OF_DEV_AUXDATA("ti,davinci-wdt", 0x01c21000, "watchdog", NULL),
 	OF_DEV_AUXDATA("ti,da830-mmc", 0x01c40000, "da830-mmc.0", NULL),
+	OF_DEV_AUXDATA("ti,da850-ehrpwm", 0x01f00000, "ehrpwm", NULL),
+	OF_DEV_AUXDATA("ti,da850-ehrpwm", 0x01f02000, "ehrpwm", NULL),
+	OF_DEV_AUXDATA("ti,da850-ecap", 0x01f06000, "ecap", NULL),
+	OF_DEV_AUXDATA("ti,da850-ecap", 0x01f07000, "ecap", NULL),
+	OF_DEV_AUXDATA("ti,da850-ecap", 0x01f08000, "ecap", NULL),
 	{}
 };
 
-- 
1.7.9.5



From rjw at sisk.pl  Wed Apr 10 08:20:26 2013
From: rjw at sisk.pl (Rafael J. Wysocki)
Date: Wed, 10 Apr 2013 14:20:26 +0200
Subject: [PATCH] cpufreq: OMAP: instantiate omap-cpufreq as a
 platform_driver
In-Reply-To: <1365549721-15620-1-git-send-email-khilman@linaro.org>
References: <1365549721-15620-1-git-send-email-khilman@linaro.org>
Message-ID: <7179834.vhxUWUzCyV@vostro.rjw.lan>

On Tuesday, April 09, 2013 04:22:01 PM Kevin Hilman wrote:
> From: Nishanth Menon <nm at ti.com>
> 
> As multi-platform build is being adopted by more and more ARM platforms,
> initcall function should be used very carefully.  For example, when
> CONFIG_ARM_OMAP2PLUS_CPUFREQ is built in the kernel, omap_cpufreq_init()
> will be called on all the platforms to initialize omap-cpufreq driver.
> 
> Further, on OMAP, we now use Soc generic cpufreq-cpu0 driver using device
> tree entries.  To allow cpufreq-cpu0 and omap-cpufreq drivers to co-exist
> for OMAP in a single image, we need to ensure the following:
> 1. With device tree boot, we use cpufreq-cpu0
> 2. With non device tree boot, we use omap-cpufreq
> 
> In the case of (1), we will have cpu OPPs and regulator registered
> as part of the device tree nodes, to ensure that omap-cpufreq
> and cpufreq-cpu0 don't conflict in managing the frequency of the
> same CPU, we should not permit omap-cpufreq to be probed.
> 
> In the case of (2), we will not have the cpufreq-cpu0 device, hence
> only omap-cpufreq will be active.
> 
> To eliminate this undesired these effects, we change omap-cpufreq
> driver to have it instantiated as a platform_driver and register
> "omap-cpufreq" device only when booted without device tree nodes on
> OMAP platforms.
> 
> This allows the following:
> a) Will only run on platforms that create the platform_device
>    "omap-cpufreq".
> b) Since the platform_device is registered only when device tree nodes
>    are *not* populated, omap-cpufreq driver does not conflict with
>    the usage of cpufreq-cpu0 driver which is used on OMAP platforms when
>    device tree nodes are present.
> 
> Inspired by commit 5553f9e26f6f49a93ba732fd222eac6973a4cf35
> (cpufreq: instantiate cpufreq-cpu0 as a platform_driver)
> 
> Cc: Kevin Hilman <khilman at linaro.org>
> Cc: Rajendra Nayak <rnayak at ti.com>
> Cc: Paul Walmsley <paul at pwsan.com>
> Cc: "Beno?t Cousson" <b-cousson at ti.com>
> Cc: Jon Hunter <jon-hunter at ti.com>
> Cc: Keerthy <j-keerthy at ti.com>
> Cc: Santosh Shilimkar <santosh.shilimkar at ti.com>
> Cc: Shawn Guo <shawn.guo at linaro.org>
> [robherring2 at gmail.com: reported conflict of omap-cpufreq vs other
> driver in an non-device tree supported boot]
> Reported-by: Rob Herring <robherring2 at gmail.com>
> Signed-off-by: Nishanth Menon <nm at ti.com>
> Acked-by: Viresh Kumar <viresh.kumar at linaro.org>
> Signed-off-by: Kevin Hilman <khilman at linaro.org>
> ---
> Rafael, can you add this one for v3.10?  It applies on top the
> rest of your cpufreq changes and I've verified that the OMAP
> changes are OK and don't conflict with anything else we have
> queued for v3.10 on OMAP.
> 
> This patch was previously part of a 2-patch series, but the 
> other part is still in discussion, and this part can be merged
> independently.

Applied to my bleeding-edge branch and will go to linux-next after build testing.

Thanks,
Rafael


>  arch/arm/mach-omap2/pm.c       |  9 +++++++++
>  drivers/cpufreq/omap-cpufreq.c | 19 ++++++++++++++-----
>  2 files changed, 23 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
> index 673a4c1..8d15f9a 100644
> --- a/arch/arm/mach-omap2/pm.c
> +++ b/arch/arm/mach-omap2/pm.c
> @@ -265,6 +265,12 @@ static void __init omap4_init_voltages(void)
>  	omap2_set_init_voltage("iva", "dpll_iva_m5x2_ck", "iva");
>  }
>  
> +static inline void omap_init_cpufreq(void)
> +{
> +	struct platform_device_info devinfo = { .name = "omap-cpufreq", };
> +	platform_device_register_full(&devinfo);
> +}
> +
>  static int __init omap2_common_pm_init(void)
>  {
>  	if (!of_have_populated_dt())
> @@ -294,6 +300,9 @@ int __init omap2_common_pm_late_init(void)
>  
>  		/* Smartreflex device init */
>  		omap_devinit_smartreflex();
> +
> +		/* cpufreq dummy device instantiation */
> +		omap_init_cpufreq();
>  	}
>  
>  #ifdef CONFIG_SUSPEND
> diff --git a/drivers/cpufreq/omap-cpufreq.c b/drivers/cpufreq/omap-cpufreq.c
> index 9128c07..d4f84b8 100644
> --- a/drivers/cpufreq/omap-cpufreq.c
> +++ b/drivers/cpufreq/omap-cpufreq.c
> @@ -25,6 +25,7 @@
>  #include <linux/opp.h>
>  #include <linux/cpu.h>
>  #include <linux/module.h>
> +#include <linux/platform_device.h>
>  #include <linux/regulator/consumer.h>
>  
>  #include <asm/smp_plat.h>
> @@ -252,7 +253,7 @@ static struct cpufreq_driver omap_driver = {
>  	.attr		= omap_cpufreq_attr,
>  };
>  
> -static int __init omap_cpufreq_init(void)
> +static int omap_cpufreq_probe(struct platform_device *pdev)
>  {
>  	mpu_dev = get_cpu_device(0);
>  	if (!mpu_dev) {
> @@ -280,12 +281,20 @@ static int __init omap_cpufreq_init(void)
>  	return cpufreq_register_driver(&omap_driver);
>  }
>  
> -static void __exit omap_cpufreq_exit(void)
> +static int omap_cpufreq_remove(struct platform_device *pdev)
>  {
> -	cpufreq_unregister_driver(&omap_driver);
> +	return cpufreq_unregister_driver(&omap_driver);
>  }
>  
> +static struct platform_driver omap_cpufreq_platdrv = {
> +	.driver = {
> +		.name	= "omap-cpufreq",
> +		.owner	= THIS_MODULE,
> +	},
> +	.probe		= omap_cpufreq_probe,
> +	.remove		= omap_cpufreq_remove,
> +};
> +module_platform_driver(omap_cpufreq_platdrv);
> +
>  MODULE_DESCRIPTION("cpufreq driver for OMAP SoCs");
>  MODULE_LICENSE("GPL");
> -module_init(omap_cpufreq_init);
> -module_exit(omap_cpufreq_exit);
> 
-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.


From hechtb at gmail.com  Wed Apr 10 08:16:03 2013
From: hechtb at gmail.com (Bastian Hecht)
Date: Wed, 10 Apr 2013 14:16:03 +0200
Subject: v7_flush_kern_cache_louis flushes up to L2?
In-Reply-To: <51655248.7000401@arm.com>
References: <CABYn4sxUCoWhC_4qydzbCtZdQdetqFZ_u5WtXsghprQget9f5g@mail.gmail.com>
 <51655248.7000401@arm.com>
Message-ID: <CABYn4swK_FB+nPO4vKZM8khp+mjaPwkAv_GF+XDg5SYz0VLf0Q@mail.gmail.com>

Hi Jonny!

2013/4/10 Jonathan Austin <jonathan.austin at arm.com>:
> Hi Bastian,
>
>
> On 10/04/13 11:43, Bastian Hecht wrote:
>>
>> Hello,
>>
>> I've got a Cortex-A9 UP with a L2 and want to submit some PM code I've
>
>
> To clarify, is this an MPCore with a single core, or a genuine UP? This can
> be established from the 'U' bit of the MPIDR.
>

I didn't actually read out the U bit, but I'm sure I've got no SCU, so
I bet high that it's a genuine UP system.

>> written. Just to make sure I've made no mistake, it would be very
>> helpful if you can confirm a hypothesis I use in my code:
>>
>> v7_flush_kern_cache_louis: Flush the data cache up to Level of
>> Unification Inner Shareable
>>
>
> Depending on whether you're SMP or UP (bearing in mind that you can be SMP,
> but still only have one processor!) the IS is ignored in the
> v7_flush_dcache_louis operation:
> (from cache-v7.S)
>
>         mrc     p15, 1, r0, c0, c0, 1           @ read clidr, r0 = clidr
>         ALT_SMP(ands    r3, r0, #(7 << 21))     @ extract LoUIS from clidr
>         ALT_UP(ands     r3, r0, #(7 << 27))     @ extract LoUU from clidr
>         ALT_SMP(mov     r3, r3, lsr #20)        @ r3 = LoUIS * 2
>         ALT_UP(mov      r3, r3, lsr #26)        @ r3 = LoUU * 2
>         ...
>         flush levels based on value in r3
>
>
>> This flushes the data out up to the L2, right? The ARM docs say that
>> the Point of Unification would be my L2. I'm a bit confused by the
>> term "Level of Unification Inner Shareable" (that states that in an
>> SMP system L1 coherency is guaranteed and all is flushed to the L2?).
>>
>
> As you say, for the A9 (from the TRM) the CLIDR reports LoUIS is the same as
> LoUU and both specify L2.

Ok, this is the golden info I was looking for. So after cpu_suspend()
I am good with the following sequence?
flush L2 (outer_flush_all)
disable L2 (outer_disable)
Clear the SCTLR.C bit and issue an "isb"
flush L1 (v7_flush_dcache_all)
cpu_do_idle

and for resume:
invalidate L1
(trust cpu_resume to resume the L1 and enable the SCTLR.C bit)
resume L2 (outer_resume)

> Does that make things clearer, or are you still unsure about something?

If you could confirm the above sequence, I'm perfectly fine. Thanks
for the quick and exhaustive support.

Cheers,

 Bastian


From heiko at sntech.de  Wed Apr 10 08:20:22 2013
From: heiko at sntech.de (Heiko =?iso-8859-1?q?St=FCbner?=)
Date: Wed, 10 Apr 2013 14:20:22 +0200
Subject: [PATCH] pinctrl: Add pinctrl-s3c24xx driver
In-Reply-To: <1376906.qvoN3qK2gl@flatron>
References: <201304100135.12471.heiko@sntech.de> <1376906.qvoN3qK2gl@flatron>
Message-ID: <201304101420.23106.heiko@sntech.de>

Hi Tomasz,

thanks for your comments, more inline.


Am Mittwoch, 10. April 2013, 12:36:39 schrieb Tomasz Figa:
> Hi Heiko,
> 
> Basically looks good to me, but please see my inline comments about
> handling of EINT0-3.
> 
> On Wednesday 10 of April 2013 01:35:12 Heiko St?bner wrote:
> > The s3c24xx pins follow a similar pattern as the other Samsung SoCs and
> > can therefore reuse the already introduced infrastructure.

[...]

> > +struct s3c24xx_eint_data {
> > +	struct samsung_pinctrl_drv_data *drvdata;
> > +	struct irq_domain *domains[NUM_EINT];
> > +	int parents[NUM_EINT_IRQ];
> > +};
> > +
> > +struct s3c24xx_eint_domain_data {
> > +	struct samsung_pin_bank *bank;
> > +	struct s3c24xx_eint_data *eint_data;
> 
> What about:
> 
> +	bool eint0_3_parent_only;
> 
> (or whatever name would be more appropriate), which would store the
> information about the s3c24xx-specific quirk in 24xx-specific data
> structure, without the need to add another field to the generic
> samsung_pinctrl_drv_data structure?
> 
> See my further comments on how I would see using this field in interrupt
> handling code.

ok, sounds good, especially gathering the type from the wakeup-int property

> > +};

[...]

> Now I would split the following 3 functions into two sets of 3 functions,
> one set for s3c2412 and other for remaining SoCs and make separate EINT0-3
> IRQ chips for both cases.

Not doing the decision every time, might bring some very slight speed 
improvements, so is probably the right way to go.

> > +
> > +static void s3c24xx_eint0_3_ack(struct irq_data *data)
> > +{
> > +	struct samsung_pin_bank *bank = irq_data_get_irq_chip_data(data);
> > +	struct samsung_pinctrl_drv_data *d = bank->drvdata;
> > +	struct s3c24xx_eint_domain_data *ddata = bank->irq_domain-
> >
> >host_data;
> >
> > +	struct s3c24xx_eint_data *eint_data = ddata->eint_data;
> > +	int parent_irq = eint_data->parents[data->hwirq];
> > +	struct irq_chip *parent_chip = irq_get_chip(parent_irq);
> > +
> > +	if (d->ctrl->type == S3C2412) {
> > +		unsigned long bitval = 1UL << data->hwirq;
> > +		writel(bitval, d->virt_base + EINTPEND_REG);
> > +	}
> > +
> > +	if (parent_chip->irq_ack)
> > +		parent_chip->irq_ack(irq_get_irq_data(parent_irq));
> 
> Btw. Is this parent level acking really needed here?

Depends. If using chained_irq_* of course not, but if the irq-handler should 
stay in charge of when to ack it might be better this way.

Generic s3c24xx SoCs need acking in the main controller only, while s3c2412 
needs acking in both the main controller and eintpend.

> > +}

[...]

> > +static void s3c24xx_demux_eint0_3(unsigned int irq, struct irq_desc
> > *desc) +{
> > +	struct irq_data *data = irq_desc_get_irq_data(desc);
> > +	struct s3c24xx_eint_data *eint_data = irq_get_handler_data(irq);
> > +	unsigned int virq;
> > +
> 
> Instead of acking the interrupt at parent chip from ack callback of
> EINT0_3 chip, I would rather use chained_irq_enter() here...
> 
> > +	/* the first 4 eints have a simple 1 to 1 mapping */
> > +	virq = irq_linear_revmap(eint_data->domains[data->hwirq],
> > data->hwirq); +	/* Something must be really wrong if an unmapped
> 
> EINT
> 
> > +	 * was unmasked...
> > +	 */
> > +	BUG_ON(!virq);
> > +
> > +	generic_handle_irq(virq);
> 
> ...and chained_irq_exit() here.

If I understand it correctly, the way chained_irq_* works it would limit the 
eints to a level style handling. With the way it's currently the whole 
determination of when to ack,mask and unmask is completely for the real 
handler (edge or level) to decide, as the original interrupt gets completely 
forwarded into the irq-domain without further constraints.

So, after the change on regular s3c24xx SoCs when the real irq handler wants 
to ack the irq, it would be a no-op, as it would already have been acked by 
chained_irq_enter.

Masking might be even more interesting. Currently control is transfered 
completely to the pinctrl irq-domain, which then controls the masking of the 
interrupt thru the parent-calls - on regular s3c24xx the masking of these is 
also only done in the main controller.

When using chained_irq_* it also wants to mask the interrupt which might 
conflict with regular enable_irq/disable_irq calls being done for example in 
driver code.


So in short I agree with the earlier split of the irqchip, but would keep the 
irq operations themself centralized in the pinctrl driver, instead of using 
chained_irq_* functions.


Heiko
 

> > +}
> > +
> > +static inline void s3c24xx_demux_eint(unsigned int irq, struct irq_desc
> > *desc, +				      u32 offset, u32 range)
> > +{
> > +	struct irq_chip *chip = irq_get_chip(irq);
> > +	struct s3c24xx_eint_data *data = irq_get_handler_data(irq);
> > +	struct samsung_pinctrl_drv_data *d = data->drvdata;
> > +	unsigned int pend, mask;
> > +
> > +	chained_irq_enter(chip, desc);
> > +
> > +	pend = readl(d->virt_base + EINTPEND_REG);
> > +	mask = readl(d->virt_base + EINTMASK_REG);
> > +
> > +	pend &= ~mask;
> > +	pend &= range;
> > +
> > +	while (pend) {
> > +		unsigned int virq;
> > +
> > +		irq = __ffs(pend);
> > +		pend &= ~(1 << irq);
> > +		virq = irq_linear_revmap(data->domains[irq], irq -
> 
> offset);
> 
> > +		/* Something must be really wrong if an unmapped EINT
> > +		 * was unmasked...
> > +		 */
> > +		BUG_ON(!virq);
> > +
> > +		generic_handle_irq(virq);
> > +	}
> > +
> > +	chained_irq_exit(chip, desc);
> > +}
> > +
> > +static void s3c24xx_demux_eint4_7(unsigned int irq, struct irq_desc
> > *desc) +{
> > +	s3c24xx_demux_eint(irq, desc, 0, 0xf0);
> > +}
> > +
> > +static void s3c24xx_demux_eint8_23(unsigned int irq, struct irq_desc
> > *desc) +{
> > +	s3c24xx_demux_eint(irq, desc, 8, 0xffff00);
> > +}
> > +
> > +static irq_flow_handler_t s3c24xx_eint_handlers[NUM_EINT_IRQ] = {
> > +	s3c24xx_demux_eint0_3,
> > +	s3c24xx_demux_eint0_3,
> > +	s3c24xx_demux_eint0_3,
> > +	s3c24xx_demux_eint0_3,
> > +	s3c24xx_demux_eint4_7,
> > +	s3c24xx_demux_eint8_23,
> > +};
> > +
> > +static int s3c24xx_gpf_irq_map(struct irq_domain *h, unsigned int virq,
> > +					irq_hw_number_t hw)
> > +{
> > +	struct s3c24xx_eint_domain_data *ddata = h->host_data;
> > +	struct samsung_pin_bank *bank = ddata->bank;
> > +
> > +	if (!(bank->eint_mask & (1 << (bank->eint_offset + hw))))
> > +		return -EINVAL;
> > +
> > +	if (hw <= 3) {
> 
> Now here I would check ddata->eint0_3_parent_only and set the chip
> conditionally, either to s3c24xx or s3c2412 variant.
> 
> > +		irq_set_chip_and_handler(virq, &s3c24xx_eint0_3_chip,
> > +					 handle_edge_irq);
> > +		irq_set_chip_data(virq, bank);
> > +	} else {
> > +		irq_set_chip_and_handler(virq, &s3c24xx_eint_chip,
> > +					 handle_edge_irq);
> > +		irq_set_chip_data(virq, bank);
> > +	}
> > +	set_irq_flags(virq, IRQF_VALID);
> > +	return 0;
> > +}
> > +
> > +static const struct irq_domain_ops s3c24xx_gpf_irq_ops = {
> > +	.map	= s3c24xx_gpf_irq_map,
> > +	.xlate	= irq_domain_xlate_twocell,
> > +};
> > +
> > +static int s3c24xx_gpg_irq_map(struct irq_domain *h, unsigned int virq,
> > +					irq_hw_number_t hw)
> > +{
> > +	struct s3c24xx_eint_domain_data *ddata = h->host_data;
> > +	struct samsung_pin_bank *bank = ddata->bank;
> > +
> > +	if (!(bank->eint_mask & (1 << (bank->eint_offset + hw))))
> > +		return -EINVAL;
> > +
> > +	irq_set_chip_and_handler(virq, &s3c24xx_eint_chip,
> 
> handle_edge_irq);
> 
> > +	irq_set_chip_data(virq, bank);
> > +	set_irq_flags(virq, IRQF_VALID);
> > +	return 0;
> > +}
> > +
> > +static const struct irq_domain_ops s3c24xx_gpg_irq_ops = {
> > +	.map	= s3c24xx_gpg_irq_map,
> > +	.xlate	= irq_domain_xlate_twocell,
> > +};
> > +
> > +static const struct of_device_id s3c24xx_eint_irq_ids[] = {
> > +	{ .compatible = "samsung,s3c24xx-wakeup-eint", },
> > +	{ }
> > +};
> > +
> > +static int s3c24xx_eint_init(struct samsung_pinctrl_drv_data *d)
> > +{
> > +	struct device *dev = d->dev;
> > +	struct device_node *eint_np = NULL;
> > +	struct device_node *np;
> > +	struct samsung_pin_bank *bank;
> > +	struct s3c24xx_eint_data *eint_data;
> > +	const struct irq_domain_ops *ops;
> > +	unsigned int i;
> > +
> > +	for_each_child_of_node(dev->of_node, np) {
> > +		if (of_match_node(s3c24xx_eint_irq_ids, np)) {
> > +			eint_np = np;
> > +			break;
> > +		}
> > +	}
> > +	if (!eint_np)
> > +		return -ENODEV;
> > +
> > +	eint_data = devm_kzalloc(dev, sizeof(*eint_data), GFP_KERNEL);
> > +	if (!eint_data) {
> > +		dev_err(dev, "could not allocate memory for wkup eint
> 
> data\n");
> 
> > +		return -ENOMEM;
> > +	}
> > +	eint_data->drvdata = d;
> > +
> > +	for (i = 0; i < NUM_EINT_IRQ; ++i) {
> > +		unsigned int irq;
> > +
> > +		irq = irq_of_parse_and_map(eint_np, i);
> > +		if (!irq) {
> > +			dev_err(dev, "failed to get wakeup EINT IRQ %d\n",
> 
> i);
> 
> > +			return -ENXIO;
> > +		}
> > +
> > +		eint_data->parents[i] = irq;
> > +		irq_set_chained_handler(irq, s3c24xx_eint_handlers[i]);
> > +		irq_set_handler_data(irq, eint_data);
> > +	}
> > +
> > +	bank = d->ctrl->pin_banks;
> > +	for (i = 0; i < d->ctrl->nr_banks; ++i, ++bank) {
> > +		struct s3c24xx_eint_domain_data *ddata;
> > +		unsigned int mask;
> > +		unsigned int irq;
> > +		unsigned int pin;
> > +
> > +		if (bank->eint_type != EINT_TYPE_WKUP)
> > +			continue;
> > +
> > +		ddata = devm_kzalloc(dev, sizeof(*ddata), GFP_KERNEL);
> > +		if (!ddata) {
> > +			dev_err(dev, "failed to allocate domain data\n");
> > +			return -ENOMEM;
> > +		}
> > +		ddata->bank = bank;
> > +		ddata->eint_data = eint_data;
> 
> Here the eint0_3_parent_only field can be set based on compatible string
> of the EINT controller.
> 
> > +
> > +		ops = (bank->eint_offset == 0) ? &s3c24xx_gpf_irq_ops
> > +					       : &s3c24xx_gpg_irq_ops;
> > +
> > +		bank->irq_domain = irq_domain_add_linear(bank->of_node,
> > +				bank->nr_pins, ops, ddata);
> > +		if (!bank->irq_domain) {
> > +			dev_err(dev, "wkup irq domain add failed\n");
> > +			return -ENXIO;
> > +		}
> > +
> > +		irq = bank->eint_offset;
> > +		mask = bank->eint_mask;
> > +		for (pin = 0; mask; ++pin, mask >>= 1) {
> > +			if (irq > NUM_EINT)
> > +				break;
> > +			if (!(mask & 1))
> > +				continue;
> > +			eint_data->domains[irq] = bank->irq_domain;
> > +			++irq;
> > +		}
> > +	}
> > +
> > +	return 0;
> > +}
> > +
> > +static struct samsung_pin_bank s3c2413_pin_banks[] = {
> > +	PIN_BANK_A(23, 0x000, "gpa"),
> > +	PIN_BANK_2BIT(11, 0x010, "gpb"),
> > +	PIN_BANK_2BIT(16, 0x020, "gpc"),
> > +	PIN_BANK_2BIT(16, 0x030, "gpd"),
> > +	PIN_BANK_2BIT(16, 0x040, "gpe"),
> > +	PIN_BANK_2BIT_EINTW(8, 0x050, "gpf", 0, 0xff),
> > +	PIN_BANK_2BIT_EINTW(16, 0x060, "gpg", 8, 0xffff00),
> > +	PIN_BANK_2BIT(11, 0x070, "gph"),
> > +	PIN_BANK_2BIT(13, 0x080, "gpj"),
> > +};
> > +
> > +struct samsung_pin_ctrl s3c2413_pin_ctrl[] = {
> > +	{
> > +		.pin_banks	= s3c2413_pin_banks,
> > +		.nr_banks	= ARRAY_SIZE(s3c2413_pin_banks),
> > +		.eint_wkup_init = s3c24xx_eint_init,
> > +		.label		= "S3C2413-GPIO",
> > +		.type		= S3C2412,
> 
> And then finally you shouldn't need this type field anymore.


From arnd at arndb.de  Wed Apr 10 08:22:31 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed, 10 Apr 2013 14:22:31 +0200
Subject: [PATCH 7/8] dmaengine: ste_dma40: Use the BIT macro to replace
 ugly '(1 << x)'s
In-Reply-To: <20130410093412.GI25316@gmail.com>
References: <1365532783-27425-1-git-send-email-lee.jones@linaro.org>
 <201304092112.56039.arnd@arndb.de> <20130410093412.GI25316@gmail.com>
Message-ID: <201304101422.31601.arnd@arndb.de>

On Wednesday 10 April 2013, Lee Jones wrote:
> On Tue, 09 Apr 2013, Arnd Bergmann wrote:

> > Yes, good point. The macro is only used in one place, to compare
> > two compile-time constant values, but we should define macros in
> > drivers that are already provided by the kernel.
> 
> Okay, it looks like the generic implementation has brackets in it,
> which isn't allowed for this particular usecase.

Ah, right.

> I'll fix this one instead.

Probably not worth then. You could open-code the comparison where
it is used and remove the macro if you want, but I probably
would not bother.

	Arnd



From tomasz.figa at gmail.com  Wed Apr 10 08:31:29 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Wed, 10 Apr 2013 14:31:29 +0200
Subject: [PATCH] pinctrl: Add pinctrl-s3c24xx driver
In-Reply-To: <201304101420.23106.heiko@sntech.de>
References: <201304100135.12471.heiko@sntech.de> <1376906.qvoN3qK2gl@flatron>
 <201304101420.23106.heiko@sntech.de>
Message-ID: <136562781.D2dqZAGJoQ@flatron>

On Wednesday 10 of April 2013 14:20:22 Heiko St?bner wrote:
> Hi Tomasz,
> 
> thanks for your comments, more inline.
> 
> Am Mittwoch, 10. April 2013, 12:36:39 schrieb Tomasz Figa:
> > Hi Heiko,
> > 
> > Basically looks good to me, but please see my inline comments about
> > handling of EINT0-3.
> > 
> > On Wednesday 10 of April 2013 01:35:12 Heiko St?bner wrote:
> > > The s3c24xx pins follow a similar pattern as the other Samsung SoCs
> > > and
> > > can therefore reuse the already introduced infrastructure.
> 
> [...]
> 
> > > +struct s3c24xx_eint_data {
> > > +	struct samsung_pinctrl_drv_data *drvdata;
> > > +	struct irq_domain *domains[NUM_EINT];
> > > +	int parents[NUM_EINT_IRQ];
> > > +};
> > > +
> > > +struct s3c24xx_eint_domain_data {
> > > +	struct samsung_pin_bank *bank;
> > > +	struct s3c24xx_eint_data *eint_data;
> > 
> > What about:
> > 
> > +	bool eint0_3_parent_only;
> > 
> > (or whatever name would be more appropriate), which would store the
> > information about the s3c24xx-specific quirk in 24xx-specific data
> > structure, without the need to add another field to the generic
> > samsung_pinctrl_drv_data structure?
> > 
> > See my further comments on how I would see using this field in
> > interrupt handling code.
> 
> ok, sounds good, especially gathering the type from the wakeup-int
> property
> > > +};
> 
> [...]
> 
> > Now I would split the following 3 functions into two sets of 3
> > functions, one set for s3c2412 and other for remaining SoCs and make
> > separate EINT0-3 IRQ chips for both cases.
> 
> Not doing the decision every time, might bring some very slight speed
> improvements, so is probably the right way to go.
> 
> > > +
> > > +static void s3c24xx_eint0_3_ack(struct irq_data *data)
> > > +{
> > > +	struct samsung_pin_bank *bank = irq_data_get_irq_chip_data(data);
> > > +	struct samsung_pinctrl_drv_data *d = bank->drvdata;
> > > +	struct s3c24xx_eint_domain_data *ddata = bank->irq_domain-
> > >
> > >host_data;
> > >
> > > +	struct s3c24xx_eint_data *eint_data = ddata->eint_data;
> > > +	int parent_irq = eint_data->parents[data->hwirq];
> > > +	struct irq_chip *parent_chip = irq_get_chip(parent_irq);
> > > +
> > > +	if (d->ctrl->type == S3C2412) {
> > > +		unsigned long bitval = 1UL << data->hwirq;
> > > +		writel(bitval, d->virt_base + EINTPEND_REG);
> > > +	}
> > > +
> > > +	if (parent_chip->irq_ack)
> > > +		parent_chip->irq_ack(irq_get_irq_data(parent_irq));
> > 
> > Btw. Is this parent level acking really needed here?
> 
> Depends. If using chained_irq_* of course not, but if the irq-handler
> should stay in charge of when to ack it might be better this way.
> 
> Generic s3c24xx SoCs need acking in the main controller only, while
> s3c2412 needs acking in both the main controller and eintpend.
> 
> > > +}
> 
> [...]
> 
> > > +static void s3c24xx_demux_eint0_3(unsigned int irq, struct irq_desc
> > > *desc) +{
> > > +	struct irq_data *data = irq_desc_get_irq_data(desc);
> > > +	struct s3c24xx_eint_data *eint_data = irq_get_handler_data(irq);
> > > +	unsigned int virq;
> > > +
> > 
> > Instead of acking the interrupt at parent chip from ack callback of
> > EINT0_3 chip, I would rather use chained_irq_enter() here...
> > 
> > > +	/* the first 4 eints have a simple 1 to 1 mapping */
> > > +	virq = irq_linear_revmap(eint_data->domains[data->hwirq],
> > > data->hwirq); +	/* Something must be really wrong if an unmapped
> > 
> > EINT
> > 
> > > +	 * was unmasked...
> > > +	 */
> > > +	BUG_ON(!virq);
> > > +
> > > +	generic_handle_irq(virq);
> > 
> > ...and chained_irq_exit() here.
> 
> If I understand it correctly, the way chained_irq_* works it would limit
> the eints to a level style handling. With the way it's currently the
> whole determination of when to ack,mask and unmask is completely for
> the real handler (edge or level) to decide, as the original interrupt
> gets completely forwarded into the irq-domain without further
> constraints.
> 
> So, after the change on regular s3c24xx SoCs when the real irq handler
> wants to ack the irq, it would be a no-op, as it would already have
> been acked by chained_irq_enter.
> 
> Masking might be even more interesting. Currently control is transfered
> completely to the pinctrl irq-domain, which then controls the masking of
> the interrupt thru the parent-calls - on regular s3c24xx the masking of
> these is also only done in the main controller.
> 
> When using chained_irq_* it also wants to mask the interrupt which might
> conflict with regular enable_irq/disable_irq calls being done for
> example in driver code.
> 
> 
> So in short I agree with the earlier split of the irqchip, but would
> keep the irq operations themself centralized in the pinctrl driver,
> instead of using chained_irq_* functions.
> 

Right, my solution wouldn't work properly in case of regular s3c24xx and 
edge triggered interrupts. 

However I'm still wondering if it's OK to manually call parent chip 
operations in case of s3c2416. This would imply the same operation calling 
order as imposed by flow handler of the chained EINT (which can be 
handle_edge_irq), while the parent chip is probably level triggered, isn't 
it?

Best regards,
Tomasz

> 
> Heiko
> 
> > > +}
> > > +
> > > +static inline void s3c24xx_demux_eint(unsigned int irq, struct
> > > irq_desc *desc, +				      u32 offset, u32 
range)
> > > +{
> > > +	struct irq_chip *chip = irq_get_chip(irq);
> > > +	struct s3c24xx_eint_data *data = irq_get_handler_data(irq);
> > > +	struct samsung_pinctrl_drv_data *d = data->drvdata;
> > > +	unsigned int pend, mask;
> > > +
> > > +	chained_irq_enter(chip, desc);
> > > +
> > > +	pend = readl(d->virt_base + EINTPEND_REG);
> > > +	mask = readl(d->virt_base + EINTMASK_REG);
> > > +
> > > +	pend &= ~mask;
> > > +	pend &= range;
> > > +
> > > +	while (pend) {
> > > +		unsigned int virq;
> > > +
> > > +		irq = __ffs(pend);
> > > +		pend &= ~(1 << irq);
> > > +		virq = irq_linear_revmap(data->domains[irq], irq -
> > 
> > offset);
> > 
> > > +		/* Something must be really wrong if an unmapped EINT
> > > +		 * was unmasked...
> > > +		 */
> > > +		BUG_ON(!virq);
> > > +
> > > +		generic_handle_irq(virq);
> > > +	}
> > > +
> > > +	chained_irq_exit(chip, desc);
> > > +}
> > > +
> > > +static void s3c24xx_demux_eint4_7(unsigned int irq, struct irq_desc
> > > *desc) +{
> > > +	s3c24xx_demux_eint(irq, desc, 0, 0xf0);
> > > +}
> > > +
> > > +static void s3c24xx_demux_eint8_23(unsigned int irq, struct
> > > irq_desc
> > > *desc) +{
> > > +	s3c24xx_demux_eint(irq, desc, 8, 0xffff00);
> > > +}
> > > +
> > > +static irq_flow_handler_t s3c24xx_eint_handlers[NUM_EINT_IRQ] = {
> > > +	s3c24xx_demux_eint0_3,
> > > +	s3c24xx_demux_eint0_3,
> > > +	s3c24xx_demux_eint0_3,
> > > +	s3c24xx_demux_eint0_3,
> > > +	s3c24xx_demux_eint4_7,
> > > +	s3c24xx_demux_eint8_23,
> > > +};
> > > +
> > > +static int s3c24xx_gpf_irq_map(struct irq_domain *h, unsigned int
> > > virq, +					irq_hw_number_t hw)
> > > +{
> > > +	struct s3c24xx_eint_domain_data *ddata = h->host_data;
> > > +	struct samsung_pin_bank *bank = ddata->bank;
> > > +
> > > +	if (!(bank->eint_mask & (1 << (bank->eint_offset + hw))))
> > > +		return -EINVAL;
> > > +
> > > +	if (hw <= 3) {
> > 
> > Now here I would check ddata->eint0_3_parent_only and set the chip
> > conditionally, either to s3c24xx or s3c2412 variant.
> > 
> > > +		irq_set_chip_and_handler(virq, &s3c24xx_eint0_3_chip,
> > > +					 handle_edge_irq);
> > > +		irq_set_chip_data(virq, bank);
> > > +	} else {
> > > +		irq_set_chip_and_handler(virq, &s3c24xx_eint_chip,
> > > +					 handle_edge_irq);
> > > +		irq_set_chip_data(virq, bank);
> > > +	}
> > > +	set_irq_flags(virq, IRQF_VALID);
> > > +	return 0;
> > > +}
> > > +
> > > +static const struct irq_domain_ops s3c24xx_gpf_irq_ops = {
> > > +	.map	= s3c24xx_gpf_irq_map,
> > > +	.xlate	= irq_domain_xlate_twocell,
> > > +};
> > > +
> > > +static int s3c24xx_gpg_irq_map(struct irq_domain *h, unsigned int
> > > virq, +					irq_hw_number_t hw)
> > > +{
> > > +	struct s3c24xx_eint_domain_data *ddata = h->host_data;
> > > +	struct samsung_pin_bank *bank = ddata->bank;
> > > +
> > > +	if (!(bank->eint_mask & (1 << (bank->eint_offset + hw))))
> > > +		return -EINVAL;
> > > +
> > > +	irq_set_chip_and_handler(virq, &s3c24xx_eint_chip,
> > 
> > handle_edge_irq);
> > 
> > > +	irq_set_chip_data(virq, bank);
> > > +	set_irq_flags(virq, IRQF_VALID);
> > > +	return 0;
> > > +}
> > > +
> > > +static const struct irq_domain_ops s3c24xx_gpg_irq_ops = {
> > > +	.map	= s3c24xx_gpg_irq_map,
> > > +	.xlate	= irq_domain_xlate_twocell,
> > > +};
> > > +
> > > +static const struct of_device_id s3c24xx_eint_irq_ids[] = {
> > > +	{ .compatible = "samsung,s3c24xx-wakeup-eint", },
> > > +	{ }
> > > +};
> > > +
> > > +static int s3c24xx_eint_init(struct samsung_pinctrl_drv_data *d)
> > > +{
> > > +	struct device *dev = d->dev;
> > > +	struct device_node *eint_np = NULL;
> > > +	struct device_node *np;
> > > +	struct samsung_pin_bank *bank;
> > > +	struct s3c24xx_eint_data *eint_data;
> > > +	const struct irq_domain_ops *ops;
> > > +	unsigned int i;
> > > +
> > > +	for_each_child_of_node(dev->of_node, np) {
> > > +		if (of_match_node(s3c24xx_eint_irq_ids, np)) {
> > > +			eint_np = np;
> > > +			break;
> > > +		}
> > > +	}
> > > +	if (!eint_np)
> > > +		return -ENODEV;
> > > +
> > > +	eint_data = devm_kzalloc(dev, sizeof(*eint_data), GFP_KERNEL);
> > > +	if (!eint_data) {
> > > +		dev_err(dev, "could not allocate memory for wkup eint
> > 
> > data\n");
> > 
> > > +		return -ENOMEM;
> > > +	}
> > > +	eint_data->drvdata = d;
> > > +
> > > +	for (i = 0; i < NUM_EINT_IRQ; ++i) {
> > > +		unsigned int irq;
> > > +
> > > +		irq = irq_of_parse_and_map(eint_np, i);
> > > +		if (!irq) {
> > > +			dev_err(dev, "failed to get wakeup EINT IRQ %d\n",
> > 
> > i);
> > 
> > > +			return -ENXIO;
> > > +		}
> > > +
> > > +		eint_data->parents[i] = irq;
> > > +		irq_set_chained_handler(irq, s3c24xx_eint_handlers[i]);
> > > +		irq_set_handler_data(irq, eint_data);
> > > +	}
> > > +
> > > +	bank = d->ctrl->pin_banks;
> > > +	for (i = 0; i < d->ctrl->nr_banks; ++i, ++bank) {
> > > +		struct s3c24xx_eint_domain_data *ddata;
> > > +		unsigned int mask;
> > > +		unsigned int irq;
> > > +		unsigned int pin;
> > > +
> > > +		if (bank->eint_type != EINT_TYPE_WKUP)
> > > +			continue;
> > > +
> > > +		ddata = devm_kzalloc(dev, sizeof(*ddata), GFP_KERNEL);
> > > +		if (!ddata) {
> > > +			dev_err(dev, "failed to allocate domain data\n");
> > > +			return -ENOMEM;
> > > +		}
> > > +		ddata->bank = bank;
> > > +		ddata->eint_data = eint_data;
> > 
> > Here the eint0_3_parent_only field can be set based on compatible
> > string of the EINT controller.
> > 
> > > +
> > > +		ops = (bank->eint_offset == 0) ? &s3c24xx_gpf_irq_ops
> > > +					       : &s3c24xx_gpg_irq_ops;
> > > +
> > > +		bank->irq_domain = irq_domain_add_linear(bank->of_node,
> > > +				bank->nr_pins, ops, ddata);
> > > +		if (!bank->irq_domain) {
> > > +			dev_err(dev, "wkup irq domain add failed\n");
> > > +			return -ENXIO;
> > > +		}
> > > +
> > > +		irq = bank->eint_offset;
> > > +		mask = bank->eint_mask;
> > > +		for (pin = 0; mask; ++pin, mask >>= 1) {
> > > +			if (irq > NUM_EINT)
> > > +				break;
> > > +			if (!(mask & 1))
> > > +				continue;
> > > +			eint_data->domains[irq] = bank->irq_domain;
> > > +			++irq;
> > > +		}
> > > +	}
> > > +
> > > +	return 0;
> > > +}
> > > +
> > > +static struct samsung_pin_bank s3c2413_pin_banks[] = {
> > > +	PIN_BANK_A(23, 0x000, "gpa"),
> > > +	PIN_BANK_2BIT(11, 0x010, "gpb"),
> > > +	PIN_BANK_2BIT(16, 0x020, "gpc"),
> > > +	PIN_BANK_2BIT(16, 0x030, "gpd"),
> > > +	PIN_BANK_2BIT(16, 0x040, "gpe"),
> > > +	PIN_BANK_2BIT_EINTW(8, 0x050, "gpf", 0, 0xff),
> > > +	PIN_BANK_2BIT_EINTW(16, 0x060, "gpg", 8, 0xffff00),
> > > +	PIN_BANK_2BIT(11, 0x070, "gph"),
> > > +	PIN_BANK_2BIT(13, 0x080, "gpj"),
> > > +};
> > > +
> > > +struct samsung_pin_ctrl s3c2413_pin_ctrl[] = {
> > > +	{
> > > +		.pin_banks	= s3c2413_pin_banks,
> > > +		.nr_banks	= ARRAY_SIZE(s3c2413_pin_banks),
> > > +		.eint_wkup_init = s3c24xx_eint_init,
> > > +		.label		= "S3C2413-GPIO",
> > > +		.type		= S3C2412,
> > 
> > And then finally you shouldn't need this type field anymore.


From nicolas.ferre at atmel.com  Wed Apr 10 08:36:22 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Wed, 10 Apr 2013 14:36:22 +0200
Subject: [PATCH] watchdog: Revert the AT91RM9200_WATCHDOG dependency
In-Reply-To: <20130409202711.GG7867@spo001.leaseweb.com>
References: <20130409202711.GG7867@spo001.leaseweb.com>
Message-ID: <1365597382-15455-1-git-send-email-nicolas.ferre@atmel.com>

Compiling the at91rm9200_wdt.c driver without at91rm9200
support was leading to several errors:

drivers/built-in.o: In function `at91_wdt_close':
at91_adc.c:(.text+0xc9fe4): undefined reference to `at91_st_base'
drivers/built-in.o: In function `at91_wdt_write':
at91_adc.c:(.text+0xca004): undefined reference to `at91_st_base'
drivers/built-in.o: In function `at91wdt_shutdown':
at91_adc.c:(.text+0xca01c): undefined reference to `at91_st_base'
drivers/built-in.o: In function `at91wdt_suspend':
at91_adc.c:(.text+0xca038): undefined reference to `at91_st_base'
drivers/built-in.o: In function `at91_wdt_open':
at91_adc.c:(.text+0xca0cc): undefined reference to `at91_st_base'
drivers/built-in.o:at91_adc.c:(.text+0xca2c8): more undefined references to
`at91_st_base' follow

So, reverting the modification of the "depends" Kconfig line
introduced by patch a6a1bcd37 (watchdog: at91rm9200: add DT support)
seems to be the good solution.

Signed-off-by: Nicolas Ferre <nicolas.ferre at atmel.com>
---
 drivers/watchdog/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 9fcc70c..e89fc31 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -117,7 +117,7 @@ config ARM_SP805_WATCHDOG
 
 config AT91RM9200_WATCHDOG
 	tristate "AT91RM9200 watchdog"
-	depends on ARCH_AT91
+	depends on ARCH_AT91RM9200
 	help
 	  Watchdog timer embedded into AT91RM9200 chips. This will reboot your
 	  system when the timeout is reached.
-- 
1.8.0



From festevam at gmail.com  Wed Apr 10 08:36:31 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Wed, 10 Apr 2013 09:36:31 -0300
Subject: [PATCH] video: mxsfb: Adapt to new videomode API
In-Reply-To: <5165228F.1020805@ti.com>
References: <1365516978-29888-1-git-send-email-fabio.estevam@freescale.com>
 <5165228F.1020805@ti.com>
Message-ID: <CAOMZO5BY0mpYC1sjkRsnX-jnj8X4u9ZH15GCQ=MqMYeQ-LAfuQ@mail.gmail.com>

On Wed, Apr 10, 2013 at 5:27 AM, Tomi Valkeinen <tomi.valkeinen at ti.com> wrote:

> The mxsfb.c driver in my tree does not contain such code. Where is this
> patch meant to be applied?

linux-next 20130408 is broken for mxs without this fix. Maybe Shawn can take it?


From sergei.shtylyov at cogentembedded.com  Wed Apr 10 08:46:31 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Wed, 10 Apr 2013 16:46:31 +0400
Subject: [PATCH 0/4] Add USB support to R8A7778/BOCK-W
In-Reply-To: <201304100247.22615.sergei.shtylyov@cogentembedded.com>
References: <201304100247.22615.sergei.shtylyov@cogentembedded.com>
Message-ID: <51655F27.90008@cogentembedded.com>

Hello.

On 10-04-2013 2:47, Sergei Shtylyov wrote:

>     Here's the set of 4 patches against the Simon Horman's 'renesas.git' repo,
> 'renesas-next-20130410' tag.

    Sorry, forgot to mention that it is atop the previous R8A7779/Marzen USB 
patchset.

WBR, Sergei



From thomas.abraham at linaro.org  Wed Apr 10 08:48:37 2013
From: thomas.abraham at linaro.org (Thomas Abraham)
Date: Wed, 10 Apr 2013 18:18:37 +0530
Subject: [PATCH v4] mmc: dw_mmc: let device core setup the default pin
 configuration
In-Reply-To: <CAD=FV=VJ-ykDNqYKQ=fqxeOD6bRNLW02VT4bjsRHRAuXLcCpQQ@mail.gmail.com>
References: <1365487186-4587-1-git-send-email-thomas.abraham@linaro.org>
 <CAD=FV=VJ-ykDNqYKQ=fqxeOD6bRNLW02VT4bjsRHRAuXLcCpQQ@mail.gmail.com>
Message-ID: <CAJuYYwQT=povqiutVHXkF5jxTAnjpwTMQ5G0Z6xKGnnM7qYADQ@mail.gmail.com>

On 10 April 2013 05:00, Doug Anderson <dianders at chromium.org> wrote:
> Thomas,
>
> On Mon, Apr 8, 2013 at 10:59 PM, Thomas Abraham
> <thomas.abraham at linaro.org> wrote:
>> @@ -2002,7 +1994,7 @@ static int dw_mci_init_slot(struct dw_mci *host, unsigned int id)
>>                 if (ret) {
>>                         dev_err(host->dev,
>>                                 "failed to enable regulator: %d\n", ret);
>> -                       goto err_setup_bus;
>> +                       return ret;
>
> It seems like you'd need a "mmc_free_host(mmc);" in this case don't
> you?  AKA: this should be a goto and not a return.

Hi Doug,

The call to regulator_enable() is prior to the call to mmc_add_host().
Hence, call to mmc_fre_host is not required in this case. So the above
change should be right.

Thanks,
Thomas.

>
> -Doug


From will.deacon at arm.com  Wed Apr 10 08:53:16 2013
From: will.deacon at arm.com (Will Deacon)
Date: Wed, 10 Apr 2013 13:53:16 +0100
Subject: [PATCH] ARM: hw_breakpoint: Do not use __cpuinitdata for
 dbg_cpu_pm_nb
In-Reply-To: <CABYn4szX3k2m-BZRTH3xKGChHGu212cHnEAoYakbctHOia+ibA@mail.gmail.com>
References: <1365588278-5185-1-git-send-email-hechtb+renesas@gmail.com>
 <20130410111148.GA26992@mudshark.cambridge.arm.com>
 <CABYn4szw=kE_DD1eNZ-CsM__o_cJUA5+F4M8T5-Uyf_nw+bfGg@mail.gmail.com>
 <5165554D.3040107@arm.com>
 <CABYn4szX3k2m-BZRTH3xKGChHGu212cHnEAoYakbctHOia+ibA@mail.gmail.com>
Message-ID: <20130410125316.GC26992@mudshark.cambridge.arm.com>

On Wed, Apr 10, 2013 at 01:11:16PM +0100, Bastian Hecht wrote:
> > Will, we have the same issue in arch/arm/kernel/perf_event_cpu.c.
> > Lorenzo is currently working on an appropriate patch.

I don't think we do. The __cpuinitdata annotation there is only used on a
hotplug notifier, which should be fine.

Will


From arnd at arndb.de  Wed Apr 10 08:59:07 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed, 10 Apr 2013 14:59:07 +0200
Subject: [PATCH RESEND] ARM: EXYNOS: no more support non-DT for EXYNOS SoCs
In-Reply-To: <516541EB.8080404@samsung.com>
References: <51642dab.e844440a.0ad1.ffffc13f@mx.google.com>
 <310101ce35d7$00e7e000$02b7a000$%kim@samsung.com>
 <516541EB.8080404@samsung.com>
Message-ID: <201304101459.07263.arnd@arndb.de>

On Wednesday 10 April 2013, Sylwester Nawrocki wrote:
> On 04/10/2013 12:34 PM, Kukjin Kim wrote:
> > Kukjin Kim wrote:
> >>
> >> From: Kukjin Kim <kgene.kim at samsung.com>
> >>
> >> As we discussed in mailing list, non-DT for EXYNOS SoCs will not be
> >> supported from v3.10. This patch removes regarding files for non-DT
> >> including board files.
> >>
> >> Signed-off-by: Kukjin Kim <kgene.kim at samsung.com>
> 
> It looks OK to me.

Ok. I am currently rebuilding my exynos multiplatform series on top of the
branches merged yesterday, but keeping ATAGS support alive there.

Should I rebase on top of this patch instead?

	Arnd


From dietmar.eggemann at arm.com  Wed Apr 10 09:04:30 2013
From: dietmar.eggemann at arm.com (Dietmar Eggemann)
Date: Wed, 10 Apr 2013 14:04:30 +0100
Subject: [PATCH] ARM: hw_breakpoint: Do not use __cpuinitdata for
 dbg_cpu_pm_nb
In-Reply-To: <20130410125316.GC26992@mudshark.cambridge.arm.com>
References: <1365588278-5185-1-git-send-email-hechtb+renesas@gmail.com>
 <20130410111148.GA26992@mudshark.cambridge.arm.com>
 <CABYn4szw=kE_DD1eNZ-CsM__o_cJUA5+F4M8T5-Uyf_nw+bfGg@mail.gmail.com>
 <5165554D.3040107@arm.com>
 <CABYn4szX3k2m-BZRTH3xKGChHGu212cHnEAoYakbctHOia+ibA@mail.gmail.com>
 <20130410125316.GC26992@mudshark.cambridge.arm.com>
Message-ID: <5165635E.50804@arm.com>

On 10/04/13 13:53, Will Deacon wrote:
> On Wed, Apr 10, 2013 at 01:11:16PM +0100, Bastian Hecht wrote:
>>> Will, we have the same issue in arch/arm/kernel/perf_event_cpu.c.
>>> Lorenzo is currently working on an appropriate patch.
>
> I don't think we do. The __cpuinitdata annotation there is only used on a
> hotplug notifier, which should be fine.

You right, I got confused about what is already upstream.

-- Dietmar

>
> Will
>

-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium.  Thank you.



From patrice.chotard at st.com  Wed Apr 10 09:04:47 2013
From: patrice.chotard at st.com (Patrice CHOTARD)
Date: Wed, 10 Apr 2013 15:04:47 +0200
Subject: [PATCH] pinctrl: move subsystem mutex to pinctrl_dev struct
In-Reply-To: <515381AC.4050206@wwwdotorg.org>
References: <1363189479-11240-1-git-send-email-linus.walleij@stericsson.com>
 <5140C3F5.9030406@wwwdotorg.org> <514201F1.6080508@st.com>
 <CACRpkdZ_Np-NMwO+nVLYnyUWPcidHq-MN8Ls0YMr4WxTLCLKjw@mail.gmail.com>
 <515381AC.4050206@wwwdotorg.org>
Message-ID: <5165636F.2000602@st.com>

On 03/28/2013 12:33 AM, Stephen Warren wrote:

> On 03/27/2013 03:45 PM, Linus Walleij wrote:
>> On Thu, Mar 14, 2013 at 5:59 PM, Patrice CHOTARD <patrice.chotard at st.com> wrote:
>>> On 03/13/2013 07:22 PM, Stephen Warren wrote:
>>>
>>>> On 03/13/2013 09:44 AM, Linus Walleij wrote:
>>>>> From: Patrice Chotard <patrice.chotard at st.com>
>>>>>
>>>>> This mutex avoids deadlock in case of use of multiple pin
>>>>> controllers. Before this modification, by using a global
>>>>> mutex, deadlock appeared when, for example, a call to
>>>>> pinctrl_pins_show() locked the pinctrl_mutex, called the
>>>>> ops->pin_dbg_show of a particular pin controller. If this
>>>>> pin controller needs I2C access to retrieve configuration
>>>>> information and I2C driver is using pinctrl to drive its
>>>>> pins, a call to pinctrl_select_state() try to lock again
>>>>> pinctrl_mutex which leads to a deadlock.
>>>>>
>>>>> Notice that the mutex grab from the two direction functions
>>>>> was moved into pinctrl_gpio_direction().
>>>>>
>>>>> For two cases, we can't replace pinctrl_mutex by
>>>>> pctldev->mutex, because at this stage, pctldev is
>>>>> not accessible :
>>>>>      - pinctrl_get()/pinctrl_put()
>>>>>      - pinctrl_register_maps()
>>>>>
>>>>> So add respectively pinctrl_list_mutex and
>>>>> pinctrl_maps_mutex in order to protect
>>>>> pinctrl_list and pinctrl_maps list instead.
>>>>
>>>> I can't see how this would be safe, or even how it would solve the
>>>> problem (and still be safe).
>>>>
>>>> In the scenario described above, pinctrl_pins_show() would need to lock
>>>> the list mutex since it's interacting with the list of pinctrl devices.
>>>> Then, the I2C drivers'c pinctrl_select() also needs to acquire that same
>>>> lock, since it's interacting with another entry in that same list in
>>>> order to re-program the other pinctrl device to route I2C to the correct
>>>> location.
>>>>
>>>
>>> Hi Stephen,
>>>
>>> Thanks for your review.
>>>
>>> I don't understand why, in pinctrl_pins_show(), pinctrl_list_mutex
>>> should be locked whereas pinctrl_list is not updated or parsed ?
> 
> Sorry for the slow response.
> 
> If pinctrl_pins_show() calls into a pin controller, then the list of pin
> controllers must be locked to prevent that pin controller from being
> destroyed while the "show" code is still using it.
> 


Hi all,

Correct me if i am wrong, but i can't see any issue.

A pin controller can't be destroyed while a pinctrl_pins_show() call. In
both pinctrl_pins_show() and pinctrl_unregister(),
mutex_lock(&pctldev->mutex) is perfomed. So during pinctrl_pins_show()
execution, a pinctrl can't be unregistered/removed.


> I suppose an alternative would be module_get() the relevant driver's
> module to prevent it from being unloaded. I'm not sure if that would
> remove the need to scan through the list of pin controllers (which would
> then require taking the lock), or whether something else knows which
> driver is related to each debugfs file so that no list lookup is
> required? Perhaps debugfs already does that internally somehow?
> 
>>>> So, I can't see how separating out the map lock would make any difference.
>>>>
>>>> Also, why is the map lock relevant here at all anyway? The I2C mux's
>>>> probe() should have executed pinctrl_get(), and isn't the map parsed at
>>>> that time, and converted to a struct pinctrl, and hence any later call
>>>> to pinctrl_select() doesn't touch the map?
>>>
>>> Sorry, but i don't follow what you mean ....
>>> In create_pinctrl(), maps is protected by pinctrl_maps_mutex.
> 
>>> I don't understand the link between maps and pinctrl_select(),
>>> pinctrl_select_state_locked() doesn't touch the map.
> 
> Yes, pinctrl_select() shouldn't touch the map since it's already been
> parsed.
> 
> But if there's a per-pinctrl-driver lock, then pinctrl_select() needs to
> lock all those locks for each driver referenced by a struct
> pinctrl_state entry.
> 
> Perhaps it doesn't need to hold more than one of those at a time though;
> that might help remove any possibility of deadlock.


Ok, regarding pinctrl_select(), i will propose a new patch version which
hold the per-pincontrol-driver lock referenced by each struct
pinctrl_state entry.

> 
>>>> Is there a recursive lock type that could be used instead? I'm not sure
>>>> if that'd still be safe though.
>>>>
>>>> Finally, a long while ago when I removed these separate locks and
>>>> created the single lock, I raised a slew of complex points re: why it
>>>> was extremely hard to split up the locking. I talked about a number of
>>>> AB/BA deadlock cases IIRC mostly w.r.t pinctrl device registration. Were
>>>> those considered when writing this patch? What's the solution?
>>>
>>> I suppose you make reference to the comment you put on this commit ?
>>> 57b676f9c1b7cd84397fe5a86c9bd2788ac4bd32 : pinctrl: fix and simplify
>>> locking
> 
> Yes, that commit and the email thread surrounding it.
> 
>>> Added in CC Seraphin Bonnafe as he has reported the deadlock issue using
>>> several pin ctrollers.
>>
>> Any reaction to this?
> 
> I was hoping that Patrice would go through the various issues I raised
> in that commit log and the surrounding email discussion and point out
> exactly why the proposed locking scheme would not cause the problems I
> mentioned there.
> 
>> I can intuitively agree with the idea that the locking should not
>> be for the entire subsystem but preferably per-controller.
> 
> Yes, that would be great if it doesn't introduce any issues.
> 
>> Indeed that commit says:
>>
>>     Solving this requires the introduction of a higher-level lock, at least
>>     a lock per pin controller, which both gpio range registration and
>>     pinctrl_get()/put() will acquire.
>>
>> So this is the "atleast".
> 
> Yup.
> 
>> Then it says:
>>
>>     Related, a future change will add a
>>     "complete" op to the pin controller drivers, the idea being that each
>>     state's programming will be programmed into the pinctrl driver followed
>>     by the "complete" call,
>>
>> Hm that is actually quite useful but we haven't got around to
>> doing that, and it should be able to use the same per-controller mutex.
> 
> Indeed. I guess nobody ended up caring about that optimization yet.
> Still, it's something that should be easy to add any time it's useful.
> 
>> And that of course brings into the question of locking when accessing
>> the list of such controllers, or the maps, neither of which are part
>> of any controller. So these needs to be a separate mutexes.
>>
>> The old locking would be per-descriptor but this patch preserves
>> part of the reform in Stephen's patch, it keeps one big lock for
>> everything happening in a certain pin controller, but brings back
>> the two locks for lists and maps.
> 
> OK.
> 
>> The commit message also states:
>>
>>     However, each pinctrl mapping table entry may affect a different pin
>>     controller if necessary. Hence, with a per-pin-controller lock, almost
>>     any pinctrl API may need to acquire multiple locks, one per controller.
>>     To avoid deadlock, these would need to be acquired in the same order in
>>     all cases. This is extremely difficult to implement in the case of
>>     pinctrl_get(), which doesn't know which pin controllers to lock until it
>>     has parsed the entire mapping table, since it contains somewhat arbitrary
>>     data.
>>
>> This is the real problem, right?
> 
> That's one issue.
> 
> Perhaps if we acquire and release the locks for each controller as we
> process each individual entry in struct pinctrl_state, we'll never hold
> more than one per-pinctrl-driver lock at once, so there won't be any
> possibility of ABBA locking problems across multiple pinctrl drivers.
> 
> But there's at least one more issue that I vaguely recall now: When
> registering a pinctrl driver, the pinctrl core can automatically select
> that device's own default state (a/k/a hogging). pinctrl_register()
> would need to hold the list lock since it's manipulating the list.
> However, if we re-use the pinctrl_select() code, then that requires
> recursive locking; the lock is held once by pinctrl_register, and would
> need to be taken during map->pinctrl_state conversion in order to look
> up the pinctrl driver for each map entry. There was some reason it
> didn't make sense to first register the new pinctrl driver, then drop
> the list lock, then apply the hogs outside the lock, but I forget what
> that was:-( Perhaps I was mistaken here. Or perhaps, I was just trying
> to avoid many lock/unlock operations during register, and I should have
> just not tried to avoid that.
> 
>> This patch will just take the pinctrl_list_mutex in the pinctrl_get()
>> path. If it then ends up in create_pinctrl() from there
>> it is iterating the map, and should thus also take the
>> pinctrl_maps_mutex, which it does.
>>
>> I don't quite see how taking these two orthogonal mutexes would
>> be so complicated to get right, so please help me out here.
> 
> The main issue I was trying to avoid was deadlock due to ABBA lock
> acquisition.



From ulf.hansson at stericsson.com  Wed Apr 10 09:06:15 2013
From: ulf.hansson at stericsson.com (Ulf Hansson)
Date: Wed, 10 Apr 2013 15:06:15 +0200
Subject: [PATCH] cpufreq: dbx500: Round to closest available freq
Message-ID: <1365599175-22361-1-git-send-email-ulf.hansson@stericsson.com>

From: Mats Fagerstrom <mats.fagerstrom at stericsson.com>

When reading the cpu speed, round it to the closest available
frequency from the table.

Signed-off-by: Ulf Hansson <ulf.hansson at linaro.org>
Signed-off-by: Mats Fagerstrom <mats.fagerstrom at stericsson.com>
---
 drivers/cpufreq/dbx500-cpufreq.c |   10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/cpufreq/dbx500-cpufreq.c b/drivers/cpufreq/dbx500-cpufreq.c
index 15ed367..6ec6539 100644
--- a/drivers/cpufreq/dbx500-cpufreq.c
+++ b/drivers/cpufreq/dbx500-cpufreq.c
@@ -71,15 +71,15 @@ static unsigned int dbx500_cpufreq_getspeed(unsigned int cpu)
 	int i = 0;
 	unsigned long freq = clk_get_rate(armss_clk) / 1000;
 
-	while (freq_table[i].frequency != CPUFREQ_TABLE_END) {
-		if (freq <= freq_table[i].frequency)
+	/* The value is rounded to closest frequency in the defined table. */
+	while (freq_table[i + 1].frequency != CPUFREQ_TABLE_END) {
+		if (freq < freq_table[i].frequency +
+		   (freq_table[i + 1].frequency - freq_table[i].frequency) / 2)
 			return freq_table[i].frequency;
 		i++;
 	}
 
-	/* We could not find a corresponding frequency. */
-	pr_err("dbx500-cpufreq: Failed to find cpufreq speed\n");
-	return 0;
+	return freq_table[i].frequency;
 }
 
 static int __cpuinit dbx500_cpufreq_init(struct cpufreq_policy *policy)
-- 
1.7.10



From ezequiel.garcia at free-electrons.com  Wed Apr 10 09:09:03 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Wed, 10 Apr 2013 10:09:03 -0300
Subject: [PATCHv1 0/5] Marvell EBU irqchip improvements
In-Reply-To: <1365542778-27959-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1365542778-27959-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <20130410130902.GA29100@localhost>

Hi Thomas,

On Tue, Apr 09, 2013 at 11:26:13PM +0200, Thomas Petazzoni wrote:
> Hello,
> 
> Here is a set of 5 patches that move the Marvell EBU IRQ controller
> driver to drivers/irqchip/ and do a few minor related cleanup or
> improvements.
> 
> Those commits were originally part of the series introducing PCIe MSI
> support for Marvell EBU platform, but the MSI support is not ready for
> merging. However, I'd like those preparation patches to be considered
> for 3.10.
> 

I'm trying to test this patchset, assuming you've based it on top of
v3.9-rc5.

However, patch 4/5 doesn't apply and I'm not really sure which
other patches may be depending on this.

Any hints?
-- 
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com


From cov at codeaurora.org  Wed Apr 10 09:12:04 2013
From: cov at codeaurora.org (Christopher Covington)
Date: Wed, 10 Apr 2013 09:12:04 -0400
Subject: [PATCH v2] arm64: Fix task tracing
In-Reply-To: <20130410114126.GB26992@mudshark.cambridge.arm.com>
References: <20130408153132.GQ17476@mudshark.cambridge.arm.com>
 <1365510814-21343-1-git-send-email-cov@codeaurora.org>
 <20130410114126.GB26992@mudshark.cambridge.arm.com>
Message-ID: <51656524.10708@codeaurora.org>

Hi Will,

On 04/10/2013 07:41 AM, Will Deacon wrote:
> On Tue, Apr 09, 2013 at 01:33:34PM +0100, Christopher Covington wrote:
>> For accurate accounting pass contextidr_thread_switch the prev
>> task pointer, since cpu_switch_to has at that point changed the
>> the stack pointer.
>>
>> Signed-off-by: Christopher Covington <cov at codeaurora.org>
> 
> Thanks Christopher -- I assume that using prev did resolve your issues?

Yes indeed. We're now able to see in simulation that if a userspace process
uses 100% CPU, its thread ID, rather than what was usually some random
kthread, gets written out most of the time. I donno if that meets your
criteria for a "real" use case, but I hope it's at least sufficient testing of
the code for now.

Thanks,
Christopher

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by the Linux Foundation.


From robherring2 at gmail.com  Wed Apr 10 09:13:54 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Wed, 10 Apr 2013 08:13:54 -0500
Subject: [PATCH v5 1/3] of/pci: Unify pci_process_bridge_OF_ranges from
 Microblaze and PowerPC
In-Reply-To: <1365578969-30966-2-git-send-email-Andrew.Murray@arm.com>
References: <1365578969-30966-1-git-send-email-Andrew.Murray@arm.com>
 <1365578969-30966-2-git-send-email-Andrew.Murray@arm.com>
Message-ID: <51656592.7070806@gmail.com>

Adding Ben H and Michal...

On 04/10/2013 02:29 AM, Andrew Murray wrote:
> The pci_process_bridge_OF_ranges function, used to parse the "ranges"
> property of a PCI host device, is found in both Microblaze and PowerPC
> architectures. These implementations are nearly identical. This patch
> moves this common code to a common place.
> 
> Signed-off-by: Andrew Murray <Andrew.Murray at arm.com>
> Signed-off-by: Liviu Dudau <Liviu.Dudau at arm.com>

One comment below. Otherwise,

Reviewed-by: Rob Herring <rob.herring at calxeda.com>

You need also need acks from Ben and Michal.

[...]

> +		/* Act based on address space type */
> +		res = NULL;
> +		switch ((pci_space >> 24) & 0x3) {
> +		case 1:		/* PCI IO space */
> +			pr_info("  IO 0x%016llx..0x%016llx -> 0x%016llx\n",
> +			       cpu_addr, cpu_addr + size - 1, pci_addr);
> +
> +			/* We support only one IO range */
> +			if (hose->pci_io_size) {
> +				pr_info(" \\--> Skipped (too many) !\n");
> +				continue;
> +			}
> +#if defined(CONFIG_PPC32) || defined(CONFIG_MICROBLAZE)

How about "if (!IS_ENABLED(CONFIG_64BIT))" instead.

> +			/* On 32 bits, limit I/O space to 16MB */
> +			if (size > 0x01000000)
> +				size = 0x01000000;
> +
> +			/* 32 bits needs to map IOs here */
> +			hose->io_base_virt = ioremap(cpu_addr, size);
> +
> +			/* Expect trouble if pci_addr is not 0 */
> +			if (primary)
> +				isa_io_base =
> +					(unsigned long)hose->io_base_virt;
> +#endif /* CONFIG_PPC32 || CONFIG_MICROBLAZE */
> +			/* pci_io_size and io_base_phys always represent IO
> +			 * space starting at 0 so we factor in pci_addr
> +			 */
> +			hose->pci_io_size = pci_addr + size;
> +			hose->io_base_phys = cpu_addr - pci_addr;



From will.deacon at arm.com  Wed Apr 10 09:21:27 2013
From: will.deacon at arm.com (Will Deacon)
Date: Wed, 10 Apr 2013 14:21:27 +0100
Subject: Removal of NWFPE in its entirety, and VFP emulation code
In-Reply-To: <20130410104002.GF14496@n2100.arm.linux.org.uk>
References: <20130410104002.GF14496@n2100.arm.linux.org.uk>
Message-ID: <20130410132126.GD26992@mudshark.cambridge.arm.com>

Hi Russell,

On Wed, Apr 10, 2013 at 11:40:02AM +0100, Russell King - ARM Linux wrote:
> I have just committed a patch to remove the arch/arm/nwfpe code from
> the kernel, and the VFP code emulating the FP operations.

[...]

I just had a play with your for-next branch, and noticed a couple of issues
arising from this:

	1. Removing vfpinstr.h leads to a couple of build failures, as it is
	   still included by arch/arm/kvm/coproc.c (for fmrx, which we should
	   continue to provide) and arch/arm/vfp/vfpmodule.c (similarly, but
	   also fmxr).

	2. vfp.h now contains a bunch of dead function declarations (e.g.
	   vfp_double_normaliseround) which should probably be removed. In
	   fact, the inline functions are unused too, so they could also go.

Will


From robherring2 at gmail.com  Wed Apr 10 09:30:58 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Wed, 10 Apr 2013 08:30:58 -0500
Subject: [RFC PATCH 1/3] pstore-ram: use write-combine mappings
In-Reply-To: <CAMbhsRSvQPbzJ7Nt=OSSYE_A1e+eaUjO7XY+qRppJ5_gfWmW4A@mail.gmail.com>
References: <1365563297-12480-1-git-send-email-robherring2@gmail.com>
 <CAMbhsRSvQPbzJ7Nt=OSSYE_A1e+eaUjO7XY+qRppJ5_gfWmW4A@mail.gmail.com>
Message-ID: <51656992.60203@gmail.com>

On 04/09/2013 10:53 PM, Colin Cross wrote:
> On Tue, Apr 9, 2013 at 8:08 PM, Rob Herring <robherring2 at gmail.com> wrote:
>> From: Rob Herring <rob.herring at calxeda.com>
>>
>> Atomic operations are undefined behavior on ARM for device or strongly
>> ordered memory types. So use write-combine variants for mappings. This
>> corresponds to normal, non-cacheable memory on ARM. For many other
>> architectures, this change should not change the mapping type.
> 
> This is going to make ramconsole less reliable.  A debugging printk
> followed by a __raw_writel that causes an immediate hard crash is
> likely to lose the last updates, including the most useful message, in
> the write buffers.

It would have to be a write that hangs the bus. In my experience with
AXI, the bus doesn't actually hang until you hit max outstanding
transactions.

I think exclusive stores will limit the buffering, but that is probably
not architecturally guaranteed.

I could put a wb() in at the end of persistent_ram_write.

> Also, isn't this patch unnecessary after patch 3 in this set?

It is still needed in the main memory case to be architecturally correct
to avoid multiple mappings of different memory types and exclusive
accesses to device memory. At least on an A9, it doesn't really seem to
matter. I could remove this for the ioremap case.

Rob

>> Signed-off-by: Rob Herring <rob.herring at calxeda.com>
>> Cc: Anton Vorontsov <cbouatmailru at gmail.com>
>> Cc: Colin Cross <ccross at android.com>
>> Cc: Kees Cook <keescook at chromium.org>
>> Cc: Tony Luck <tony.luck at intel.com>
>> Cc: linux-kernel at vger.kernel.org
>> ---
>>  fs/pstore/ram_core.c |    4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/fs/pstore/ram_core.c b/fs/pstore/ram_core.c
>> index 0306303..e126d9f 100644
>> --- a/fs/pstore/ram_core.c
>> +++ b/fs/pstore/ram_core.c
>> @@ -337,7 +337,7 @@ static void *persistent_ram_vmap(phys_addr_t start, size_t size)
>>         page_start = start - offset_in_page(start);
>>         page_count = DIV_ROUND_UP(size + offset_in_page(start), PAGE_SIZE);
>>
>> -       prot = pgprot_noncached(PAGE_KERNEL);
>> +       prot = pgprot_writecombine(PAGE_KERNEL);
> Is this necessary?  Won't pgprot_noncached already be normal memory?
> 
>>         pages = kmalloc(sizeof(struct page *) * page_count, GFP_KERNEL);
>>         if (!pages) {
>> @@ -364,7 +364,7 @@ static void *persistent_ram_iomap(phys_addr_t start, size_t size)
>>                 return NULL;
>>         }
>>
>> -       return ioremap(start, size);
>> +       return ioremap_wc(start, size);
> 
> ioremap_wc corresponds to MT_DEVICE_WC, which is still device memory,
> so I don't see how this helps solve the problem in the commit message.
> 
>>  }
>>
>>  static int persistent_ram_buffer_map(phys_addr_t start, phys_addr_t size,
>> --
>> 1.7.10.4
>>



From linux at roeck-us.net  Wed Apr 10 09:33:51 2013
From: linux at roeck-us.net (Guenter Roeck)
Date: Wed, 10 Apr 2013 06:33:51 -0700
Subject: [PATCH] watchdog: Revert the AT91RM9200_WATCHDOG dependency
In-Reply-To: <1365597382-15455-1-git-send-email-nicolas.ferre@atmel.com>
References: <20130409202711.GG7867@spo001.leaseweb.com>
 <1365597382-15455-1-git-send-email-nicolas.ferre@atmel.com>
Message-ID: <20130410133351.GA7295@roeck-us.net>

On Wed, Apr 10, 2013 at 02:36:22PM +0200, Nicolas Ferre wrote:
> Compiling the at91rm9200_wdt.c driver without at91rm9200
> support was leading to several errors:
> 
> drivers/built-in.o: In function `at91_wdt_close':
> at91_adc.c:(.text+0xc9fe4): undefined reference to `at91_st_base'
> drivers/built-in.o: In function `at91_wdt_write':
> at91_adc.c:(.text+0xca004): undefined reference to `at91_st_base'
> drivers/built-in.o: In function `at91wdt_shutdown':
> at91_adc.c:(.text+0xca01c): undefined reference to `at91_st_base'
> drivers/built-in.o: In function `at91wdt_suspend':
> at91_adc.c:(.text+0xca038): undefined reference to `at91_st_base'
> drivers/built-in.o: In function `at91_wdt_open':
> at91_adc.c:(.text+0xca0cc): undefined reference to `at91_st_base'
> drivers/built-in.o:at91_adc.c:(.text+0xca2c8): more undefined references to
> `at91_st_base' follow
> 
> So, reverting the modification of the "depends" Kconfig line
> introduced by patch a6a1bcd37 (watchdog: at91rm9200: add DT support)
> seems to be the good solution.
> 
Really ? Why ? I mean, this was supposed to be for at91rm9200, wasn't it ?
And why would want try to compile a watchdog for at91rm9200 without at91rm9200
support ?

I understand there is a problem, I just don't see how removing that line would
solgve it.

Guenter

> Signed-off-by: Nicolas Ferre <nicolas.ferre at atmel.com>
> ---
>  drivers/watchdog/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> index 9fcc70c..e89fc31 100644
> --- a/drivers/watchdog/Kconfig
> +++ b/drivers/watchdog/Kconfig
> @@ -117,7 +117,7 @@ config ARM_SP805_WATCHDOG
>  
>  config AT91RM9200_WATCHDOG
>  	tristate "AT91RM9200 watchdog"
> -	depends on ARCH_AT91
> +	depends on ARCH_AT91RM9200
>  	help
>  	  Watchdog timer embedded into AT91RM9200 chips. This will reboot your
>  	  system when the timeout is reached.
> -- 
> 1.8.0
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-watchdog" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


From jonathan.austin at arm.com  Wed Apr 10 09:35:05 2013
From: jonathan.austin at arm.com (Jonathan Austin)
Date: Wed, 10 Apr 2013 14:35:05 +0100
Subject: v7_flush_kern_cache_louis flushes up to L2?
In-Reply-To: <CABYn4swK_FB+nPO4vKZM8khp+mjaPwkAv_GF+XDg5SYz0VLf0Q@mail.gmail.com>
References: <CABYn4sxUCoWhC_4qydzbCtZdQdetqFZ_u5WtXsghprQget9f5g@mail.gmail.com>
 <51655248.7000401@arm.com>
 <CABYn4swK_FB+nPO4vKZM8khp+mjaPwkAv_GF+XDg5SYz0VLf0Q@mail.gmail.com>
Message-ID: <51656A89.9090600@arm.com>

Hi again Bastian,

On 10/04/13 13:16, Bastian Hecht wrote:
[...]
>>> This flushes the data out up to the L2, right? The ARM docs say that
>>> the Point of Unification would be my L2. I'm a bit confused by the
>>> term "Level of Unification Inner Shareable" (that states that in an
>>> SMP system L1 coherency is guaranteed and all is flushed to the L2?).
>>>
>>
>> As you say, for the A9 (from the TRM) the CLIDR reports LoUIS is the same as
>> LoUU and both specify L2.
>
> Ok, this is the golden info I was looking for. So after cpu_suspend()
> I am good with the following sequence?
> flush L2 (outer_flush_all)
> disable L2 (outer_disable)
> Clear the SCTLR.C bit and issue an "isb"
> flush L1 (v7_flush_dcache_all)

This looks good but I think there's a minor modification to be made to 
the sequence here:

After you turn of the caches with the SCTLR.C bit, you can no longer hit 
in the L1 cache:
SCTLR.C = 0:
"The Cortex-A9 L1 Data Cache is not enabled. All memory accesses to 
Normal Memory Cacheable regions are treated as Normal Memory 
Non-Cacheable, without lookup and without allocation in the L1 Data Cache."

If you had dirty data in the L1 cache you will lose it at that point.

So, you should flush L1 before turning off caches.

Note that on SMP, you would also need to clean/flush again after turning 
off the caches, as read-speculation could have sucked dirty data from 
another cache in to your cache, which would need to be written back 
before sleeping.

> cpu_do_idle
>
> and for resume:
> invalidate L1

How do you plan to do this? I notice that there's an increasing tendency 
to call v7_invalidate_l1 which isn't actually part of the cacheflush API 
(see arch/arm/include/asm/cacheflush.h arch/arm/include/asm/glue-cache.h...)

Does your cache definitely come up in an undefined state? If not, could 
you use v7_flush_dcache_all? (see the comment above v7_invalidate_l1 in 
arch/arm/mm/cache-v7.S)

Hope that helps,

Jonny




From linux at roeck-us.net  Wed Apr 10 09:41:56 2013
From: linux at roeck-us.net (Guenter Roeck)
Date: Wed, 10 Apr 2013 06:41:56 -0700
Subject: [PATCH] watchdog: Revert the AT91RM9200_WATCHDOG dependency
In-Reply-To: <20130410133351.GA7295@roeck-us.net>
References: <20130409202711.GG7867@spo001.leaseweb.com>
 <1365597382-15455-1-git-send-email-nicolas.ferre@atmel.com>
 <20130410133351.GA7295@roeck-us.net>
Message-ID: <20130410134156.GA15456@roeck-us.net>

On Wed, Apr 10, 2013 at 06:33:51AM -0700, Guenter Roeck wrote:
> On Wed, Apr 10, 2013 at 02:36:22PM +0200, Nicolas Ferre wrote:
> > Compiling the at91rm9200_wdt.c driver without at91rm9200
> > support was leading to several errors:
> > 
> > drivers/built-in.o: In function `at91_wdt_close':
> > at91_adc.c:(.text+0xc9fe4): undefined reference to `at91_st_base'
> > drivers/built-in.o: In function `at91_wdt_write':
> > at91_adc.c:(.text+0xca004): undefined reference to `at91_st_base'
> > drivers/built-in.o: In function `at91wdt_shutdown':
> > at91_adc.c:(.text+0xca01c): undefined reference to `at91_st_base'
> > drivers/built-in.o: In function `at91wdt_suspend':
> > at91_adc.c:(.text+0xca038): undefined reference to `at91_st_base'
> > drivers/built-in.o: In function `at91_wdt_open':
> > at91_adc.c:(.text+0xca0cc): undefined reference to `at91_st_base'
> > drivers/built-in.o:at91_adc.c:(.text+0xca2c8): more undefined references to
> > `at91_st_base' follow
> > 
> > So, reverting the modification of the "depends" Kconfig line
> > introduced by patch a6a1bcd37 (watchdog: at91rm9200: add DT support)
> > seems to be the good solution.
> > 
> Really ? Why ? I mean, this was supposed to be for at91rm9200, wasn't it ?
> And why would want try to compile a watchdog for at91rm9200 without at91rm9200
> support ?
> 
> I understand there is a problem, I just don't see how removing that line would
> solve it.
> 
Me confused, sorry. I somehow thought you were removing the ARCH_AT91RM9200
dependency, not adding it.

Acked-by: Guenter Roeck <linux at roeck-us.net>

Guenter


From heiko at sntech.de  Wed Apr 10 09:45:48 2013
From: heiko at sntech.de (Heiko =?iso-8859-1?q?St=FCbner?=)
Date: Wed, 10 Apr 2013 15:45:48 +0200
Subject: [PATCH] pinctrl: Add pinctrl-s3c24xx driver
In-Reply-To: <136562781.D2dqZAGJoQ@flatron>
References: <201304100135.12471.heiko@sntech.de>
 <201304101420.23106.heiko@sntech.de> <136562781.D2dqZAGJoQ@flatron>
Message-ID: <201304101545.49264.heiko@sntech.de>

Am Mittwoch, 10. April 2013, 14:31:29 schrieb Tomasz Figa:
> On Wednesday 10 of April 2013 14:20:22 Heiko St?bner wrote:
> > Hi Tomasz,
> > 
> > thanks for your comments, more inline.
> > 
> > Am Mittwoch, 10. April 2013, 12:36:39 schrieb Tomasz Figa:
> > > Hi Heiko,
> > > 
> > > Basically looks good to me, but please see my inline comments about
> > > handling of EINT0-3.
> > > 
> > > On Wednesday 10 of April 2013 01:35:12 Heiko St?bner wrote:
> > > > The s3c24xx pins follow a similar pattern as the other Samsung SoCs
> > > > and
> > > > can therefore reuse the already introduced infrastructure.
> > 
> > [...]
> > 
> > > > +struct s3c24xx_eint_data {
> > > > +	struct samsung_pinctrl_drv_data *drvdata;
> > > > +	struct irq_domain *domains[NUM_EINT];
> > > > +	int parents[NUM_EINT_IRQ];
> > > > +};
> > > > +
> > > > +struct s3c24xx_eint_domain_data {
> > > > +	struct samsung_pin_bank *bank;
> > > > +	struct s3c24xx_eint_data *eint_data;
> > > 
> > > What about:
> > > 
> > > +	bool eint0_3_parent_only;
> > > 
> > > (or whatever name would be more appropriate), which would store the
> > > information about the s3c24xx-specific quirk in 24xx-specific data
> > > structure, without the need to add another field to the generic
> > > samsung_pinctrl_drv_data structure?
> > > 
> > > See my further comments on how I would see using this field in
> > > interrupt handling code.
> > 
> > ok, sounds good, especially gathering the type from the wakeup-int
> > property
> > 
> > > > +};
> > 
> > [...]
> > 
> > > Now I would split the following 3 functions into two sets of 3
> > > functions, one set for s3c2412 and other for remaining SoCs and make
> > > separate EINT0-3 IRQ chips for both cases.
> > 
> > Not doing the decision every time, might bring some very slight speed
> > improvements, so is probably the right way to go.
> > 
> > > > +
> > > > +static void s3c24xx_eint0_3_ack(struct irq_data *data)
> > > > +{
> > > > +	struct samsung_pin_bank *bank = irq_data_get_irq_chip_data(data);
> > > > +	struct samsung_pinctrl_drv_data *d = bank->drvdata;
> > > > +	struct s3c24xx_eint_domain_data *ddata = bank->irq_domain-
> > > >
> > > >host_data;
> > > >
> > > > +	struct s3c24xx_eint_data *eint_data = ddata->eint_data;
> > > > +	int parent_irq = eint_data->parents[data->hwirq];
> > > > +	struct irq_chip *parent_chip = irq_get_chip(parent_irq);
> > > > +
> > > > +	if (d->ctrl->type == S3C2412) {
> > > > +		unsigned long bitval = 1UL << data->hwirq;
> > > > +		writel(bitval, d->virt_base + EINTPEND_REG);
> > > > +	}
> > > > +
> > > > +	if (parent_chip->irq_ack)
> > > > +		parent_chip->irq_ack(irq_get_irq_data(parent_irq));
> > > 
> > > Btw. Is this parent level acking really needed here?
> > 
> > Depends. If using chained_irq_* of course not, but if the irq-handler
> > should stay in charge of when to ack it might be better this way.
> > 
> > Generic s3c24xx SoCs need acking in the main controller only, while
> > s3c2412 needs acking in both the main controller and eintpend.
> > 
> > > > +}
> > 
> > [...]
> > 
> > > > +static void s3c24xx_demux_eint0_3(unsigned int irq, struct irq_desc
> > > > *desc) +{
> > > > +	struct irq_data *data = irq_desc_get_irq_data(desc);
> > > > +	struct s3c24xx_eint_data *eint_data = irq_get_handler_data(irq);
> > > > +	unsigned int virq;
> > > > +
> > > 
> > > Instead of acking the interrupt at parent chip from ack callback of
> > > EINT0_3 chip, I would rather use chained_irq_enter() here...
> > > 
> > > > +	/* the first 4 eints have a simple 1 to 1 mapping */
> > > > +	virq = irq_linear_revmap(eint_data->domains[data->hwirq],
> > > > data->hwirq); +	/* Something must be really wrong if an unmapped
> > > 
> > > EINT
> > > 
> > > > +	 * was unmasked...
> > > > +	 */
> > > > +	BUG_ON(!virq);
> > > > +
> > > > +	generic_handle_irq(virq);
> > > 
> > > ...and chained_irq_exit() here.
> > 
> > If I understand it correctly, the way chained_irq_* works it would limit
> > the eints to a level style handling. With the way it's currently the
> > whole determination of when to ack,mask and unmask is completely for
> > the real handler (edge or level) to decide, as the original interrupt
> > gets completely forwarded into the irq-domain without further
> > constraints.
> > 
> > So, after the change on regular s3c24xx SoCs when the real irq handler
> > wants to ack the irq, it would be a no-op, as it would already have
> > been acked by chained_irq_enter.
> > 
> > Masking might be even more interesting. Currently control is transfered
> > completely to the pinctrl irq-domain, which then controls the masking of
> > the interrupt thru the parent-calls - on regular s3c24xx the masking of
> > these is also only done in the main controller.
> > 
> > When using chained_irq_* it also wants to mask the interrupt which might
> > conflict with regular enable_irq/disable_irq calls being done for
> > example in driver code.
> > 
> > 
> > So in short I agree with the earlier split of the irqchip, but would
> > keep the irq operations themself centralized in the pinctrl driver,
> > instead of using chained_irq_* functions.
> 
> Right, my solution wouldn't work properly in case of regular s3c24xx and
> edge triggered interrupts.
> 
> However I'm still wondering if it's OK to manually call parent chip
> operations in case of s3c2416. This would imply the same operation calling
> order as imposed by flow handler of the chained EINT (which can be
> handle_edge_irq), while the parent chip is probably level triggered, isn't
> it?

I think imposing the same calling order is the right way to go :-) .

The eints can be set hardware-wise to either level or edge triggered, but 
their flow handler is currently hard set to handle_edge_irq. I remember seeing 
a patch from the Openmoko guys somewhere indicating that this does not work at 
all with level irqs.

Only the main interrupts of the real demuxed eints (3_to_7 and 8_to...) are 
always level triggered, and therefore already use chained_irq...

In the current pinctrl driver, the parent eints do not have a flow handler of 
their own (as the chained handler replaces it). So all flow handling is done 
by the flowhandler of the irq in the pinctrl domain.

handle_IRQ(main_eint)
-> demux_eint0_3
-> generic_handle_irq(pinctrl_eint)
-> handle_edge_irq (or handle_level_irq)
-> call ack, mask or unmask of the pinctrl eint
-> call ack, mask or unmask of the underlying main eint


Heiko


From s.nawrocki at samsung.com  Wed Apr 10 09:46:21 2013
From: s.nawrocki at samsung.com (Sylwester Nawrocki)
Date: Wed, 10 Apr 2013 15:46:21 +0200
Subject: [PATCH RESEND] ARM: EXYNOS: no more support non-DT for EXYNOS SoCs
In-Reply-To: <201304101459.07263.arnd@arndb.de>
References: <51642dab.e844440a.0ad1.ffffc13f@mx.google.com>
 <310101ce35d7$00e7e000$02b7a000$%kim@samsung.com>
 <516541EB.8080404@samsung.com> <201304101459.07263.arnd@arndb.de>
Message-ID: <51656D2D.7060004@samsung.com>

On 04/10/2013 02:59 PM, Arnd Bergmann wrote:
> On Wednesday 10 April 2013, Sylwester Nawrocki wrote:
>> On 04/10/2013 12:34 PM, Kukjin Kim wrote:
>>> Kukjin Kim wrote:
>>>>
>>>> From: Kukjin Kim <kgene.kim at samsung.com>
>>>>
>>>> As we discussed in mailing list, non-DT for EXYNOS SoCs will not be
>>>> supported from v3.10. This patch removes regarding files for non-DT
>>>> including board files.
>>>>
>>>> Signed-off-by: Kukjin Kim <kgene.kim at samsung.com>
>>
>> It looks OK to me.
> 
> Ok. I am currently rebuilding my exynos multiplatform series on top of the
> branches merged yesterday, but keeping ATAGS support alive there.
> 
> Should I rebase on top of this patch instead?

Hmm, it turns out we are still actively using some boards based on
Exynos4210 EVT0 SoCs. And since it seems unlikely the patches from
Tomasz [1] adding basic DT support for those will get merged for
3.10, it would be a bit inconvenient to remove the ATAGS support
now, leaving Exynos4210 Rev. 0 not supported at all.

Not sure what's others opinion on that, and what would be an advantage
of removing non-dt support for Exynos now, rather than in 3.11, vs. any
possible inconvenience and regressions this could cause.

[1] http://www.spinics.net/lists/arm-kernel/msg235745.html

Thanks,
Sylwester


From lorenzo.pieralisi at arm.com  Wed Apr 10 09:51:43 2013
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Wed, 10 Apr 2013 14:51:43 +0100
Subject: v7_flush_kern_cache_louis flushes up to L2?
In-Reply-To: <CABYn4swK_FB+nPO4vKZM8khp+mjaPwkAv_GF+XDg5SYz0VLf0Q@mail.gmail.com>
References: <CABYn4sxUCoWhC_4qydzbCtZdQdetqFZ_u5WtXsghprQget9f5g@mail.gmail.com>
 <51655248.7000401@arm.com>
 <CABYn4swK_FB+nPO4vKZM8khp+mjaPwkAv_GF+XDg5SYz0VLf0Q@mail.gmail.com>
Message-ID: <20130410135138.GA9210@e102568-lin.cambridge.arm.com>

On Wed, Apr 10, 2013 at 01:16:03PM +0100, Bastian Hecht wrote:
> Hi Jonny!
> 
> 2013/4/10 Jonathan Austin <jonathan.austin at arm.com>:
> > Hi Bastian,
> >
> >
> > On 10/04/13 11:43, Bastian Hecht wrote:
> >>
> >> Hello,
> >>
> >> I've got a Cortex-A9 UP with a L2 and want to submit some PM code I've
> >
> >
> > To clarify, is this an MPCore with a single core, or a genuine UP? This can
> > be established from the 'U' bit of the MPIDR.
> >
> 
> I didn't actually read out the U bit, but I'm sure I've got no SCU, so
> I bet high that it's a genuine UP system.
> 
> >> written. Just to make sure I've made no mistake, it would be very
> >> helpful if you can confirm a hypothesis I use in my code:
> >>
> >> v7_flush_kern_cache_louis: Flush the data cache up to Level of
> >> Unification Inner Shareable
> >>
> >
> > Depending on whether you're SMP or UP (bearing in mind that you can be SMP,
> > but still only have one processor!) the IS is ignored in the
> > v7_flush_dcache_louis operation:
> > (from cache-v7.S)
> >
> >         mrc     p15, 1, r0, c0, c0, 1           @ read clidr, r0 = clidr
> >         ALT_SMP(ands    r3, r0, #(7 << 21))     @ extract LoUIS from clidr
> >         ALT_UP(ands     r3, r0, #(7 << 27))     @ extract LoUU from clidr
> >         ALT_SMP(mov     r3, r3, lsr #20)        @ r3 = LoUIS * 2
> >         ALT_UP(mov      r3, r3, lsr #26)        @ r3 = LoUU * 2
> >         ...
> >         flush levels based on value in r3
> >
> >
> >> This flushes the data out up to the L2, right? The ARM docs say that
> >> the Point of Unification would be my L2. I'm a bit confused by the
> >> term "Level of Unification Inner Shareable" (that states that in an
> >> SMP system L1 coherency is guaranteed and all is flushed to the L2?).
> >>
> >
> > As you say, for the A9 (from the TRM) the CLIDR reports LoUIS is the same as
> > LoUU and both specify L2.
> 
> Ok, this is the golden info I was looking for. So after cpu_suspend()
> I am good with the following sequence?

Is L2 RAM retained on power down ?

> flush L2 (outer_flush_all)
> disable L2 (outer_disable)

Disabling L2 is not mandatory. And the code above (if L2 RAM is not
retained) can be simply

outer_disable

the cleaning is done in the PL310 disable function properly.

> Clear the SCTLR.C bit and issue an "isb"
> flush L1 (v7_flush_dcache_all)

Two steps above are ok, as long as flush L1 does not push data on the
stack on entry and L1 clean routine does not need any dirty data present
in L1. Clearing C bit on A9 stops the core from searching the
cache so data writes should not be executed with C bit cleared and a
data cache still containing dirty lines. For the same reason the cache
cleaning routine should not require any data to execute since the data
can be sitting in the cache that is not searched anymore when the C bit
is cleared.

The sequence:

clear C bit
bl v7_flush_dcache_all

is better coded in assembly (in the cpu_suspend finisher, ie the
function you pass as cpu_suspend 2 argument) to control what you are doing.

The cache cleaning routine (v7_flush_dcache_all) does not require any
data to execute, so running it with C bit cleared is fine.

> cpu_do_idle
> 
> and for resume:
> invalidate L1

Use v7_invalidate_l1 here.

> (trust cpu_resume to resume the L1 and enable the SCTLR.C bit)
> resume L2 (outer_resume)

Again, it depends on L2 behaviour on shutdown, if it is retained or not.
If L2 RAM content is lost on power down the sequence above seems ok.

Post the code, happy to have a look.

Lorenzo



From kgene.kim at samsung.com  Wed Apr 10 09:52:45 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Wed, 10 Apr 2013 22:52:45 +0900
Subject: [GIT PULL v2 1/4] cleanup-samsung v2 for v3.10
Message-ID: <51656EAD.1000407@samsung.com>

Hi Arnd, Olof,

This is for replacing previous pull-request for 
tags/cleanup-samsung-for-v3.10 because it included wrong e-mail address 
for author.
Please pull this instead. Sorry for that.

Thanks.

- Kukjin
----------------------------------------------------------------

The following changes since commit a937536b868b8369b98967929045f1df54234323:

   Linux 3.9-rc3 (2013-03-17 15:59:32 -0700)

are available in the git repository at:

   git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git 
tags/cleanup-samsung-v2-for-v3.10

for you to fetch changes up to 9bf38322c8ecb0892cc11a61decb870520753673:

   ARM: EXYNOS: remove "config EXYNOS_DEV_DRM" (2013-04-10 17:26:05 +0900)

----------------------------------------------------------------
This cleans unused codes and removes unneeded dependencies for Samsung. 
Note, this is 2nd version because of wrong e-mail address for author

----------------------------------------------------------------
Alexander Shiyan (3):
       ARM: S3C24XX: Removed unneeded dependency on ARCH_S3C24XX for boards
       ARM: S3C24XX: Removed unneeded dependency on CPU_S3C2410
       ARM: S3C24XX: Removed unneeded dependency on CPU_S3C2412

Jingoo Han (1):
       ARM: EXYNOS: change the name of USB ohci header

Padmavathi Venna (1):
       ARM: SAMSUNG: Remove unnecessary code for dma

Paul Bolle (11):
       ARM: S3C24XX: drop "select MACH_N35"
       ARM: S3C24XX: drop "select MACH_NEO1973"
       ARM: EXYNOS: drop "select HAVE_SCHED_CLOCK"
       ARM: EXYNOS: change HAVE_SAMSUNG_KEYPAD to KEYBOARD_SAMSUNG
       ARM: SAMSUNG: remove "config S3C_BOOT_WATCHDOG"
       ARM: SAMSUNG: Remove useless Samsung GPIO related CONFIG
       ARM: S3C24XX: remove unneeded "config SMDK2440_CPU2442"
       ARM: S3C64XX: remove obsolete Makefile line
       ARM: S5P64X0: Fix typo "CONFIG_S5P64X0_SETUP_SDHCI"
       ARM: SAMSUNG: Fix typo "CONFIG_SAMSUNG_DEV_RTC"
       ARM: EXYNOS: remove "config EXYNOS_DEV_DRM"

Sylwester Nawrocki (1):
       ARM: S3C24XX: Remove unused GPIO drive strength register definitions

Wei Yongjun (1):
       ARM: EXYNOS: remove duplicated include from common.c

  arch/arm/Kconfig                                   |   1 -
  arch/arm/mach-exynos/Kconfig                       |  13 +-
  arch/arm/mach-exynos/common.c                      |   1 -
  arch/arm/mach-exynos/dev-ohci.c                    |   2 +-
  arch/arm/mach-exynos/mach-origen.c                 |   2 +-
  arch/arm/mach-exynos/mach-smdkv310.c               |   2 +-
  arch/arm/mach-s3c24xx/Kconfig                      |  22 +--
  arch/arm/mach-s3c24xx/include/mach/dma.h           |   1 -
  arch/arm/mach-s3c24xx/regs-dsc.h                   | 203 
+--------------------
  arch/arm/mach-s3c64xx/Makefile                     |   1 -
  arch/arm/mach-s3c64xx/include/mach/dma.h           |   1 -
  arch/arm/plat-samsung/Kconfig                      |  14 --
  arch/arm/plat-samsung/dma-ops.c                    |  10 +-
  arch/arm/plat-samsung/include/plat/dma-ops.h       |   1 -
  arch/arm/plat-samsung/include/plat/dma-pl330.h     |   1 -
  arch/arm/plat-samsung/include/plat/rtc-core.h      |   2 +-
  arch/arm/plat-samsung/include/plat/sdhci.h         |   4 +-
  drivers/usb/host/ohci-exynos.c                     |   3 +-
  .../{usb-exynos.h => usb-ohci-exynos.h}            |   0
  19 files changed, 20 insertions(+), 264 deletions(-)
  rename include/linux/platform_data/{usb-exynos.h => usb-ohci-exynos.h} 
(100%)



From kgene.kim at samsung.com  Wed Apr 10 09:53:03 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Wed, 10 Apr 2013 22:53:03 +0900
Subject: [GIT PULL v2 2/4] dt-exynos v2 for v3.10
Message-ID: <51656EBF.5090804@samsung.com>

Hi Arnd, Olof,

Please pull this instead of tags/dt-exynos-for-v3.10 because of wrong 
e-mail address for author. Sorry for that.

Thanks.

- Kukjin
----------------------------------------------------------------
The following changes since commit da821eb7d42935b0f7056d98c75fd1150f6636f4:

   Merge commit 'v3.9-rc5' into next/clk-exynos (2013-04-09 01:10:13 +0900)

are available in the git repository at:


   git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git 
tags/dt-exynos-v2-for-v3.10

for you to fetch changes up to 31d39248810072dec3279463d5fda0001721c01c:

   ARM: dts: add mshc controller node for Exynos4x12 SoCs (2013-04-10 
17:51:32 +0900)

----------------------------------------------------------------
This updates device tree for exynos4210 (origen and smdkv310 boards), 
exynos4412 (origen and smdk4412 boards), exynos5250 (arndale, smdk5250 
and snow boards), and exynos5440 (sd5v1 and ssdk5440 boards). And adds 
support for exynos5250 pinctrl. And includes bindings for g2d, usb and 
fimd. Note, this is 2nd version because of wrong e-mail address for author

----------------------------------------------------------------
Alexander Graf (2):
       ARM: dts: Declare the gic as a15 compatible for exynos5250
       ARM: dts: Add architected timer nodes for exynos5250

Amit Daniel Kachhap (2):
       ARM: dts: Add PMIC node entry for Arndale board
       ARM: dts: Add cpufreq controller node for Exynos5440 SoC

Byungho An (1):
       ARM: dts: Add node for GMAC for exynos5440

Doug Anderson (2):
       ARM: dts: add usb 2.0 clock references to exynos5250 device tree
       ARM: dts: Document usb clocks in samsung,exynos4210-ehci/ohci 
bindings

Giridhar Maruthy (1):
       ARM: dts: Add virtual GIC DT bindings for exynos5440

Kukjin Kim (1):
       ARM: dts: add device tree file for SD5v1 board

Leela Krishna Amudala (2):
       ARM: dts: Add FIMD node to exynos5
       ARM: dts: Add display timing node to exynos5250-smdk5250.dts

Sachin Kamat (11):
       ARM: dts: Add G2D node to exynos4210.dtsi
       ARM: dts: Add G2D node to SMDKV310
       ARM: dts: Add G2D node to exynos4210-origen
       ARM: dts: Add G2D node to exynos4x12.dtsi
       ARM: dts: Add G2D node to SMDK4412
       ARM: dts: Add G2D node to exynos4412-origen
       ARM: dts: Add Samsung G2D DT bindings documentation
       ARM: dts: Add disable-wp for card slot on exynos5250-arndale
       ARM: dts: Add vmmc regulator support for Arndale board
       ARM: dts: Add MFC codec support for Arndale board
       ARM: dts: Add HDMI HPD and regulator node for Arndale board

Subash Patel (3):
       ARM: dts: add PMU support in exynos5440
       ARM: dts: update bootargs to boot from sda2 for exynos5440-ssdk5440
       ARM: dts: add PDMA0 changes for exynos5440

Sylwester Nawrocki (1):
       ARM: dts: Add SYSREG block node for S5P/Exynos4 SoC series

Thomas Abraham (5):
       ARM: dts: add pin state information in client nodes for Exynos4 
platforms
       ARM: dts: add pin state information in client nodes for Exynos5 
platforms
       ARM: dts: list the interrupts generated by pin-controller on 
Exynos5440
       ARM: dts: Fix gmac clock ids due to changes in Exynos5440
       ARM: dts: add mshc controller node for Exynos4x12 SoCs

Tushar Behera (2):
       ARM: dts: Add pin-control related changes for Arndale board
       ARM: dts: Add gpio-button entries for Arndale board

Vikas Sajjan (3):
       ARM: dts: Add FIMD node to exynos4
       ARM: dts: Add FIMD node and display timing node to 
exynos4412-origen.dts
       ARM: dts: Add FIMD DT binding Documentation

  .../devicetree/bindings/arm/samsung/sysreg.txt     |   7 +
  .../devicetree/bindings/gpu/samsung-g2d.txt        |  20 +
  .../devicetree/bindings/usb/exynos-usb.txt         |  10 +
  .../devicetree/bindings/video/samsung-fimd.txt     |  65 ++
  arch/arm/boot/dts/Makefile                         |   1 +
  arch/arm/boot/dts/cros5250-common.dtsi             |  51 +-
  arch/arm/boot/dts/exynos4.dtsi                     |  27 +
  arch/arm/boot/dts/exynos4210-origen.dts            |   4 +
  arch/arm/boot/dts/exynos4210-smdkv310.dts          |  57 +-
  arch/arm/boot/dts/exynos4210.dtsi                  |   7 +
  arch/arm/boot/dts/exynos4412-origen.dts            |  21 +
  arch/arm/boot/dts/exynos4412-smdk4412.dts          |   8 +
  arch/arm/boot/dts/exynos4412.dtsi                  |   8 +
  arch/arm/boot/dts/exynos4x12.dtsi                  |   7 +
  arch/arm/boot/dts/exynos5250-arndale.dts           | 343 ++++++++-
  arch/arm/boot/dts/exynos5250-pinctrl.dtsi          | 783 
+++++++++++++++++++++
  arch/arm/boot/dts/exynos5250-smdk5250.dts          |  49 +-
  arch/arm/boot/dts/exynos5250-snow.dts              |  22 +-
  arch/arm/boot/dts/exynos5250.dtsi                  | 343 +++------
  arch/arm/boot/dts/exynos5440-sd5v1.dts             |  39 +
  arch/arm/boot/dts/exynos5440-ssdk5440.dts          |   6 +-
  arch/arm/boot/dts/exynos5440.dtsi                  |  55 +-
  22 files changed, 1567 insertions(+), 366 deletions(-)
  create mode 100644 
Documentation/devicetree/bindings/arm/samsung/sysreg.txt
  create mode 100644 Documentation/devicetree/bindings/gpu/samsung-g2d.txt
  create mode 100644 
Documentation/devicetree/bindings/video/samsung-fimd.txt
  create mode 100644 arch/arm/boot/dts/exynos5250-pinctrl.dtsi
  create mode 100644 arch/arm/boot/dts/exynos5440-sd5v1.dts


From kgene.kim at samsung.com  Wed Apr 10 09:53:16 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Wed, 10 Apr 2013 22:53:16 +0900
Subject: [GIT PULL v2 3/4] mct-exynos v2 for v3.10
Message-ID: <51656ECC.5070101@samsung.com>

Hi Arnd, Olof,

Please pull this instead of tags/mct-exynos-for-v3.10 because of wrong 
e-mail address for author. Sorry for that.

Thanks.

- Kukjin
----------------------------------------------------------------

The following changes since commit 6dbe51c251a327e012439c4772097a13df43c5b8:

   Linux 3.9-rc1 (2013-03-03 15:11:05 -0800)

are available in the git repository at:

   git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git 
tags/mct-exynos-v2-for-v3.10

for you to fetch changes up to 00cf16bc88b4ce15ccd85671e6b0ee54405c32e2:

   clocksource: mct: Add terminating entry for exynos_mct_ids table 
(2013-04-10 17:28:51 +0900)

----------------------------------------------------------------
This adds mct device tree node for all EXYNOS SoCs and moves into 
drivers/clocksource. Note, this is 2nd version because of wrong e-mail 
address for author

----------------------------------------------------------------
Axel Lin (1):
       clocksource: mct: Add terminating entry for exynos_mct_ids table

Doug Anderson (1):
       clocksource: mct: Add missing semicolons in exynos_mct.c

Thomas Abraham (7):
       ARM: EXYNOS: add a register base address variable in mct 
controller driver
       ARM: EXYNOS: prepare an array of MCT interrupt numbers and use it
       ARM: EXYNOS: add device tree support for MCT controller driver
       ARM: EXYNOS: allow dt based discovery of mct controller using 
clocksource_of_init
       ARM: dts: add mct device tree node for all supported Exynos SoC's
       ARM: EXYNOS: remove static io-remapping of mct registers for Exynos5
       ARM: EXYNOS: move mct driver to drivers/clocksource

  .../bindings/timer/samsung,exynos4210-mct.txt      |  68 +++++++
  arch/arm/Kconfig                                   |   2 +-
  arch/arm/boot/dts/exynos4210.dtsi                  |  22 +++
  arch/arm/boot/dts/exynos4212.dtsi                  |  22 +++
  arch/arm/boot/dts/exynos4412.dtsi                  |  24 +++
  arch/arm/boot/dts/exynos5250.dtsi                  |  22 +++
  arch/arm/mach-exynos/Kconfig                       |   8 +-
  arch/arm/mach-exynos/Makefile                      |   2 -
  arch/arm/mach-exynos/common.c                      |   5 -
  arch/arm/mach-exynos/common.h                      |   2 +-
  arch/arm/mach-exynos/include/mach/irqs.h           |   6 -
  arch/arm/mach-exynos/include/mach/map.h            |   1 -
  arch/arm/mach-exynos/include/mach/regs-mct.h       |  53 ------
  arch/arm/mach-exynos/mach-armlex4210.c             |   2 +-
  arch/arm/mach-exynos/mach-exynos4-dt.c             |   3 +-
  arch/arm/mach-exynos/mach-exynos5-dt.c             |   3 +-
  arch/arm/mach-exynos/mach-nuri.c                   |   2 +-
  arch/arm/mach-exynos/mach-origen.c                 |   2 +-
  arch/arm/mach-exynos/mach-smdk4x12.c               |   4 +-
  arch/arm/mach-exynos/mach-smdkv310.c               |   4 +-
  drivers/clocksource/Kconfig                        |   5 +
  drivers/clocksource/Makefile                       |   1 +
  .../mct.c => drivers/clocksource/exynos_mct.c      | 196 
++++++++++++++-------
  23 files changed, 310 insertions(+), 149 deletions(-)
  create mode 100644 
Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.txt
  delete mode 100644 arch/arm/mach-exynos/include/mach/regs-mct.h
  rename arch/arm/mach-exynos/mct.c => drivers/clocksource/exynos_mct.c 
(67%)


From kgene.kim at samsung.com  Wed Apr 10 09:53:27 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Wed, 10 Apr 2013 22:53:27 +0900
Subject: [GIT PULL 4/4] dt-exynos 2 for v3.10
Message-ID: <51656ED7.90506@samsung.com>

Hi Arnd, Olof,

This is one more pull-request for exynos dt update for v3.10.
Please pull.

Thanks.

- Kukjin
----------------------------------------------------------------

The following changes since commit 31d39248810072dec3279463d5fda0001721c01c:

   ARM: dts: add mshc controller node for Exynos4x12 SoCs (2013-04-10 
17:51:32 +0900)

are available in the git repository at:

   git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git 
tags/dt-exynos-2-for-v3.10

for you to fetch changes up to 9251646b7a36059f8667f87fa00361a776bf19a2:

   ARM: EXYNOS: Enable XHCI support on exynos5 (2013-04-10 19:38:41 +0900)

----------------------------------------------------------------
This updates device tree for keypad for smdk4412 and origen4412 boards 
and adds mfc clock entries for exynos4 and enables usb2phy and usb3phy 
and dwc3-exynos for exynos5250

----------------------------------------------------------------
Sachin Kamat (5):
       ARM: dts: Remove keypad entries from exynos4x12-pinctrl.dtsi
       ARM: dts: Add keypad entries to Exynos4412 based Origen
       ARM: dts: Add keypad entries to SMDK4412
       ARM: dts: Add MFC clock entries for exynos4
       ARM: dts: Update MFC documentation for clock entries

Vivek Gautam (5):
       ARM: dts: Enabling samsung-usb2phy driver for exynos5250
       ARM: dts: Enabling samsung-usb3phy driver for exynos5250
       ARM: dts: Add device tree bindings for dwc3-exynos
       ARM: dts: Enabling dwc3-exynos driver for exynos5250
       ARM: EXYNOS: Enable XHCI support on exynos5

  .../devicetree/bindings/media/s5p-mfc.txt          |  5 ++
  .../devicetree/bindings/usb/exynos-usb.txt         | 34 +++++++++
  arch/arm/boot/dts/exynos4.dtsi                     |  2 +
  arch/arm/boot/dts/exynos4412-origen.dts            | 62 +++++++++++++++
  arch/arm/boot/dts/exynos4412-smdk4412.dts          | 87 
++++++++++++++++++++++
  arch/arm/boot/dts/exynos4x12-pinctrl.dtsi          | 56 --------------
  arch/arm/boot/dts/exynos5250.dtsi                  | 45 +++++++++++
  arch/arm/mach-exynos/Kconfig                       |  1 +
  8 files changed, 236 insertions(+), 56 deletions(-)


From arnd at arndb.de  Wed Apr 10 09:55:27 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed, 10 Apr 2013 15:55:27 +0200
Subject: [PATCH RESEND] ARM: EXYNOS: no more support non-DT for EXYNOS SoCs
In-Reply-To: <51656D2D.7060004@samsung.com>
References: <51642dab.e844440a.0ad1.ffffc13f@mx.google.com>
 <201304101459.07263.arnd@arndb.de> <51656D2D.7060004@samsung.com>
Message-ID: <201304101555.27984.arnd@arndb.de>

On Wednesday 10 April 2013, Sylwester Nawrocki wrote:
> Hmm, it turns out we are still actively using some boards based on
> Exynos4210 EVT0 SoCs. And since it seems unlikely the patches from
> Tomasz [1] adding basic DT support for those will get merged for
> 3.10, it would be a bit inconvenient to remove the ATAGS support
> now, leaving Exynos4210 Rev. 0 not supported at all.

I still have hope to get those included.

> Not sure what's others opinion on that, and what would be an advantage
> of removing non-dt support for Exynos now, rather than in 3.11, vs. any
> possible inconvenience and regressions this could cause.

A multiplatform kernel will not work on an ATAGS based Exynos platform,
but I think we can have it both ways and allow either multiplatform
DT-only or single-platform with both DT and ATAGS in 3.10.

	Arnd


From dianders at chromium.org  Wed Apr 10 09:56:48 2013
From: dianders at chromium.org (Doug Anderson)
Date: Wed, 10 Apr 2013 06:56:48 -0700
Subject: [PATCH v4] mmc: dw_mmc: let device core setup the default pin
 configuration
In-Reply-To: <CAJuYYwQT=povqiutVHXkF5jxTAnjpwTMQ5G0Z6xKGnnM7qYADQ@mail.gmail.com>
References: <1365487186-4587-1-git-send-email-thomas.abraham@linaro.org>
 <CAD=FV=VJ-ykDNqYKQ=fqxeOD6bRNLW02VT4bjsRHRAuXLcCpQQ@mail.gmail.com>
 <CAJuYYwQT=povqiutVHXkF5jxTAnjpwTMQ5G0Z6xKGnnM7qYADQ@mail.gmail.com>
Message-ID: <CAD=FV=UddWM=yc5N9=jwbMDpZ7Bpg7o3Z714CnBSg=iHhmPxWw@mail.gmail.com>

Thomas,

On Wed, Apr 10, 2013 at 5:48 AM, Thomas Abraham
<thomas.abraham at linaro.org> wrote:
> The call to regulator_enable() is prior to the call to mmc_add_host().
> Hence, call to mmc_fre_host is not required in this case. So the above
> change should be right.

Are you sure that mmc_free_host() is the opposite of mmc_add_host()
and not mmc_alloc_host()?

I'll double-check myself in a few hours when I'm in front of a computer.

-Doug


From kgene.kim at samsung.com  Wed Apr 10 10:05:48 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Wed, 10 Apr 2013 23:05:48 +0900
Subject: [PATCH RESEND] ARM: EXYNOS: no more support non-DT for EXYNOS SoCs
In-Reply-To: <201304101555.27984.arnd@arndb.de>
References: <51642dab.e844440a.0ad1.ffffc13f@mx.google.com>
 <201304101459.07263.arnd@arndb.de> <51656D2D.7060004@samsung.com>
 <201304101555.27984.arnd@arndb.de>
Message-ID: <516571BC.9030909@samsung.com>

On 04/10/13 22:55, Arnd Bergmann wrote:
> On Wednesday 10 April 2013, Sylwester Nawrocki wrote:
>> Hmm, it turns out we are still actively using some boards based on
>> Exynos4210 EVT0 SoCs. And since it seems unlikely the patches from
>> Tomasz [1] adding basic DT support for those will get merged for
>> 3.10, it would be a bit inconvenient to remove the ATAGS support
>> now, leaving Exynos4210 Rev. 0 not supported at all.
>
> I still have hope to get those included.
>
I agree and I asked Tomasz to re-send universal dt patch.

>> Not sure what's others opinion on that, and what would be an advantage
>> of removing non-dt support for Exynos now, rather than in 3.11, vs. any
>> possible inconvenience and regressions this could cause.
>
> A multiplatform kernel will not work on an ATAGS based Exynos platform,
> but I think we can have it both ways and allow either multiplatform
> DT-only or single-platform with both DT and ATAGS in 3.10.
>
I think, if possible, keeping both way would be nice to us.

Thanks.

- Kukjin


From will.deacon at arm.com  Wed Apr 10 10:07:06 2013
From: will.deacon at arm.com (Will Deacon)
Date: Wed, 10 Apr 2013 15:07:06 +0100
Subject: [PATCH v3 02/32] arm64: KVM: define HYP and Stage-2 translation
 page flags
In-Reply-To: <1365437854-30214-3-git-send-email-marc.zyngier@arm.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
 <1365437854-30214-3-git-send-email-marc.zyngier@arm.com>
Message-ID: <20130410140706.GF26992@mudshark.cambridge.arm.com>

On Mon, Apr 08, 2013 at 05:17:04PM +0100, Marc Zyngier wrote:
> Add HYP and S2 page flags, for both normal and device memory.
> 
> Reviewed-by: Christopher Covington <cov at codeaurora.org>
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> ---
>  arch/arm64/include/asm/pgtable-hwdef.h | 13 +++++++++++++
>  arch/arm64/include/asm/pgtable.h       | 12 ++++++++++++
>  2 files changed, 25 insertions(+)
> 
> diff --git a/arch/arm64/include/asm/pgtable-hwdef.h b/arch/arm64/include/asm/pgtable-hwdef.h
> index 75fd13d..acb4ee5 100644
> --- a/arch/arm64/include/asm/pgtable-hwdef.h
> +++ b/arch/arm64/include/asm/pgtable-hwdef.h
> @@ -35,6 +35,7 @@
>  /*
>   * Section
>   */
> +#define PMD_SECT_USER		(_AT(pteval_t, 1) << 6)		/* AP[1] */
>  #define PMD_SECT_S		(_AT(pmdval_t, 3) << 8)
>  #define PMD_SECT_AF		(_AT(pmdval_t, 1) << 10)
>  #define PMD_SECT_NG		(_AT(pmdval_t, 1) << 11)
> @@ -68,6 +69,18 @@
>  #define PTE_ATTRINDX_MASK	(_AT(pteval_t, 7) << 2)
>  
>  /*
> + * 2nd stage PTE definitions
> + */
> +#define PTE_S2_RDONLY		 (_AT(pteval_t, 1) << 6)   /* HAP[1]   */
> +#define PTE_S2_RDWR		 (_AT(pteval_t, 2) << 6)   /* HAP[2:1] */

Is this correct? My reading of the translation spec is that this is
write-only.

> +
> +/*
> + * EL2/HYP PTE/PMD definitions
> + */
> +#define PMD_HYP			PMD_SECT_USER
> +#define PTE_HYP			PTE_USER
> +
> +/*
>   * 40-bit physical address supported.
>   */
>  #define PHYS_MASK_SHIFT		(40)
> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
> index e333a24..7c84ab4 100644
> --- a/arch/arm64/include/asm/pgtable.h
> +++ b/arch/arm64/include/asm/pgtable.h
> @@ -76,6 +76,12 @@ extern pgprot_t pgprot_default;
>  #define PAGE_KERNEL		_MOD_PROT(pgprot_default, PTE_PXN | PTE_UXN | PTE_DIRTY)
>  #define PAGE_KERNEL_EXEC	_MOD_PROT(pgprot_default, PTE_UXN | PTE_DIRTY)
>  
> +#define PAGE_HYP		_MOD_PROT(pgprot_default, PTE_HYP)
> +#define PAGE_HYP_DEVICE		_MOD_PROT(__pgprot(PROT_DEVICE_nGnRE), PTE_HYP)

You're dragging in UXN and PXN bits from PROT_DEVICE_nGnRE, which I don't
think exist at EL2.

> +#define PAGE_S2			_MOD_PROT(pgprot_default, PTE_USER | PTE_S2_RDONLY)
> +#define PAGE_S2_DEVICE		_MOD_PROT(__pgprot(PROT_DEVICE_nGnRE), PTE_USER | PTE_S2_RDWR)

You shouldn't set the user bit for stage-2 entries.

Will


From sergei.shtylyov at cogentembedded.com  Wed Apr 10 10:11:54 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Wed, 10 Apr 2013 18:11:54 +0400
Subject: [PATCH v3 4/9] rcar-phy: remove EHCI internal buffer setup
In-Reply-To: <20130410082748.GJ7983@arwen.pp.htv.fi>
References: <201304100232.30889.sergei.shtylyov@cogentembedded.com>
 <20130410082748.GJ7983@arwen.pp.htv.fi>
Message-ID: <5165732A.8050901@cogentembedded.com>

Hello.

On 10-04-2013 12:27, Felipe Balbi wrote:

> On Wed, Apr 10, 2013 at 02:32:30AM +0400, Sergei Shtylyov wrote:
>> Now that the EHCI internal  buffer setup is done by the platform code, we  can
>> remove  such code from this driver as it  never  really belonged here.  We also
>> no longer need the 2nd memory region now (2nd EHCI controller is simply missing
>> in e.g. R8A7778 SoC).

>> The patch has been tested on the Marzen and BOCK-W boards.

>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
>> Acked-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
>> Acked-by: Simon Horman <horms+renesas at verge.net.au>

>> ---
>> Changes since version 2:
>> - added a note about testing to the changelog;
>> - added ACKs from Simon Horman and Kuninori Morimoto.

>> Changes since the original posting:
>> - split R8A7779 SoC file change to a separate patch.

>>   drivers/usb/phy/rcar-phy.c |   28 ++++------------------------

> you do realise this won't apply, right ?

    Because of the rename you've done? No, I didn't realize it until you told.
I wasn't watching changes in your tree...

WBR, Sergei



From kgene.kim at samsung.com  Wed Apr 10 10:12:58 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Wed, 10 Apr 2013 23:12:58 +0900
Subject: [PATCH v5 2/3] ARM: dts: Add i2c-arbitrator bus for
 exynos5250-snow
In-Reply-To: <20130410110226.GA3533@the-dreams.de>
References: <1363192583-26363-1-git-send-email-dianders@chromium.org>
 <1365543270-10736-1-git-send-email-dianders@chromium.org>
 <1365543270-10736-2-git-send-email-dianders@chromium.org>
 <310301ce35da$724dff60$56e9fe20$%kim@samsung.com>
 <20130410110226.GA3533@the-dreams.de>
Message-ID: <5165736A.2060308@samsung.com>

On 04/10/13 20:02, Wolfram Sang wrote:
> On Wed, Apr 10, 2013 at 07:59:17PM +0900, Kukjin Kim wrote:
>> Doug Anderson wrote:
>>>
>>> We need to use the i2c-arbitrator to talk to any of the devices on i2c
>>> bus 4 on exynos5250-snow so that we don't confuse the embedded
>>> controller (EC).  Add the i2c-arbitrator to the device tree.  As we
>>> add future devices (keyboard, sbs, tps65090) we'll add them on top of
>>> this.
>>>
>>> The arbitrated bus is numbered 104 simply as a convenience to make it
>>> easier for people poking around to guess that it might have something
>>> to do with the physical bus 4.
>>>
>>> The addition is split between the cros5250-common and the snow device
>>> tree file since not all cros5250-class devices use arbitration.
>>>
>>> Signed-off-by: Doug Anderson<dianders at chromium.org>
>>
>> I'm fine on 2nd and 3rd patches. Shall I take only two patches without 1st
>> one in samsung tree?
>
> Please wait for my OK on patch 1. Or ack patches 2 and 3 and I will pick
> them up. I am fine with both.
>
OK, I will wait for your reply on this. Because I suppose if the dt 
patches in your tree could make useless conflicts. Anyway let me know 
your opinion on that.

Thanks.

- Kukjin


From daniel.lezcano at linaro.org  Wed Apr 10 10:22:05 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Wed, 10 Apr 2013 16:22:05 +0200
Subject: [PATCH 00/18] cpuidle: code consolidation
Message-ID: <1365603743-5618-1-git-send-email-daniel.lezcano@linaro.org>

This patchset series provide some code consolidation across the different
cpuidle drivers. It contains two parts, the first one is the removal of
the time keeping flag and the second one, is a common initialization routine.

All the drivers use the en_core_tk_irqen flag, which means it is not necessary
to make the time computation optional. We can remove this flag and assume the
cpuidle framework always manage this operation.

The cpuidle code initialization is duplicated across the different drivers in
the same manner.

The repeating pattern is:

SMP:

cpuidle_register_driver(drv);
for_each_possible_cpu(cpu) {
	dev = per_cpu(cpuidle_device, cpu);
	cpuidle_register_device(dev);
}

UP:

cpuidle_register_driver(drv);
cpuidle_register_device(dev);

As on a UP machine the macro 'for_each_cpu' is a one iteration loop, using the
initialization loop from SMP to UP works.

The patchset does some cleanup for different drivers in order to make the init
code the same. Then it introduces a generic function:

  cpuidle_register(struct cpuidle_driver *drv, struct cpumask *cpumask)

The cpumask is for the coupled idle states.

The drivers are then modified to take into account this new function and
to remove the duplicated code.

The benefit is observable in the diffstat: 332 lines of code removed.

Tested-on: u8500
Tested-on: at91
Tested-on: intel i5
Tested-on: OMAP4

Compiled with and without CPU_IDLE for:
 u8500, at91, davinci, exynos, imx5, imx6, kirkwood, multi_v7 (for calxeda),
 omap2plus, s3c64, tegra1, tegra2, tegra3


Daniel Lezcano (18):
  ARM: OMAP3: remove cpuidle_wrap_enter
  cpuidle: remove en_core_tk_irqen flag
  ARM: ux500: cpuidle: replace for_each_online_cpu by
    for_each_possible_cpu
  ARM: imx: cpuidle: create separate drivers for imx5/imx6
  cpuidle: make a single register function for all
  ARM: ux500: cpuidle: use init/exit common routine
  ARM: at91: cpuidle: use init/exit common routine
  ARM: OMAP3: cpuidle: use init/exit common routine
  ARM: s3c64xx: cpuidle: use init/exit common routine
  ARM: tegra1: cpuidle: use init/exit common routine
  ARM: shmobile: cpuidle: use init/exit common routine
  ARM: OMAP4: cpuidle: use init/exit common routine
  ARM: tegra2: cpuidle: use init/exit common routine
  ARM: tegra3: cpuidle: use init/exit common routine
  ARM: calxeda: cpuidle: use init/exit common routine
  ARM: kirkwood: cpuidle: use init/exit common routine
  ARM: davinci: cpuidle: use init/exit common routine
  ARM: imx: cpuidle: use init/exit common routine

 arch/arm/mach-at91/cpuidle.c                    |   18 +--
 arch/arm/mach-davinci/cpuidle.c                 |   21 +---
 arch/arm/mach-exynos/cpuidle.c                  |    1 -
 arch/arm/mach-imx/Makefile                      |    1 +
 arch/arm/mach-imx/cpuidle-imx5.c                |   40 +++++++
 arch/arm/mach-imx/cpuidle-imx6q.c               |    3 +-
 arch/arm/mach-imx/cpuidle.c                     |   80 -------------
 arch/arm/mach-imx/cpuidle.h                     |   10 +-
 arch/arm/mach-imx/pm-imx5.c                     |   30 +----
 arch/arm/mach-omap2/cpuidle34xx.c               |   49 ++------
 arch/arm/mach-omap2/cpuidle44xx.c               |   23 +---
 arch/arm/mach-s3c64xx/cpuidle.c                 |   15 +--
 arch/arm/mach-shmobile/cpuidle.c                |   11 +-
 arch/arm/mach-shmobile/pm-sh7372.c              |    1 -
 arch/arm/mach-tegra/cpuidle-tegra114.c          |   27 +----
 arch/arm/mach-tegra/cpuidle-tegra20.c           |   34 +-----
 arch/arm/mach-tegra/cpuidle-tegra30.c           |   28 +----
 arch/arm/mach-ux500/cpuidle.c                   |   33 +-----
 arch/powerpc/platforms/pseries/processor_idle.c |    1 -
 arch/sh/kernel/cpu/shmobile/cpuidle.c           |    1 -
 arch/x86/kernel/apm_32.c                        |    1 -
 drivers/acpi/processor_idle.c                   |    1 -
 drivers/cpuidle/cpuidle-calxeda.c               |   53 +--------
 drivers/cpuidle/cpuidle-kirkwood.c              |   18 +--
 drivers/cpuidle/cpuidle.c                       |  137 ++++++++++++++---------
 drivers/idle/intel_idle.c                       |    1 -
 include/linux/cpuidle.h                         |   20 ++--
 27 files changed, 162 insertions(+), 496 deletions(-)
 create mode 100644 arch/arm/mach-imx/cpuidle-imx5.c
 delete mode 100644 arch/arm/mach-imx/cpuidle.c

-- 
1.7.9.5



From daniel.lezcano at linaro.org  Wed Apr 10 10:22:06 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Wed, 10 Apr 2013 16:22:06 +0200
Subject: [PATCH 01/18] ARM: OMAP3: remove cpuidle_wrap_enter
In-Reply-To: <1365603743-5618-1-git-send-email-daniel.lezcano@linaro.org>
References: <1365603743-5618-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1365603743-5618-2-git-send-email-daniel.lezcano@linaro.org>

In a previous commit the en_core_tk_irqen flag has been added but we missed
the cpuidle_wrap_enter which was doing the job to measure the time for the
'omap3_enter_idle' function.

Actually, I don't see any reason to use this wrapper in the code. In the better
case, the time computation is not correctly done because of the different
operations done in omap3_enter_idle_bm which were not taken into account
before the en_core_tk_irqen flag was set.

As the time is reflected for the state overridden by the omap3_enter_idle_bm,
using the wrapper is pointless now, so removing it.

Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
---
 arch/arm/mach-omap2/cpuidle34xx.c |   30 +++++++++---------------------
 1 file changed, 9 insertions(+), 21 deletions(-)

diff --git a/arch/arm/mach-omap2/cpuidle34xx.c b/arch/arm/mach-omap2/cpuidle34xx.c
index 4f67a5b..a56310a 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -99,11 +99,15 @@ static struct omap3_idle_statedata omap3_idle_data[] = {
 	},
 };
 
-/* Private functions */
-
-static int __omap3_enter_idle(struct cpuidle_device *dev,
-				struct cpuidle_driver *drv,
-				int index)
+/**
+ * omap3_enter_idle - Programs OMAP3 to enter the specified state
+ * @dev: cpuidle device
+ * @drv: cpuidle driver
+ * @index: the index of state to be entered
+ */
+static int omap3_enter_idle(struct cpuidle_device *dev,
+			    struct cpuidle_driver *drv,
+			    int index)
 {
 	struct omap3_idle_statedata *cx = &omap3_idle_data[index];
 
@@ -149,22 +153,6 @@ return_sleep_time:
 }
 
 /**
- * omap3_enter_idle - Programs OMAP3 to enter the specified state
- * @dev: cpuidle device
- * @drv: cpuidle driver
- * @index: the index of state to be entered
- *
- * Called from the CPUidle framework to program the device to the
- * specified target state selected by the governor.
- */
-static inline int omap3_enter_idle(struct cpuidle_device *dev,
-				struct cpuidle_driver *drv,
-				int index)
-{
-	return cpuidle_wrap_enter(dev, drv, index, __omap3_enter_idle);
-}
-
-/**
  * next_valid_state - Find next valid C-state
  * @dev: cpuidle device
  * @drv: cpuidle driver
-- 
1.7.9.5



From daniel.lezcano at linaro.org  Wed Apr 10 10:22:08 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Wed, 10 Apr 2013 16:22:08 +0200
Subject: [PATCH 03/18] ARM: ux500: cpuidle: replace for_each_online_cpu by
 for_each_possible_cpu
In-Reply-To: <1365603743-5618-1-git-send-email-daniel.lezcano@linaro.org>
References: <1365603743-5618-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1365603743-5618-4-git-send-email-daniel.lezcano@linaro.org>

All the drivers are using, in their initialization function, the
for_each_possible_cpu macro.

Using for_each_online_cpu means the driver must handle the initialization
of the cpuidle device when a cpu is up which is not the case here.

Change the macro to for_each_possible_cpu as that fix the hotplug
initialization and make the initialization routine consistent with the
rest of the code in the different drivers.

Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
---
 arch/arm/mach-ux500/cpuidle.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-ux500/cpuidle.c b/arch/arm/mach-ux500/cpuidle.c
index c29c1bf..5657d4a 100644
--- a/arch/arm/mach-ux500/cpuidle.c
+++ b/arch/arm/mach-ux500/cpuidle.c
@@ -125,7 +125,7 @@ int __init ux500_idle_init(void)
 		return ret;
 	}
 
-	for_each_online_cpu(cpu) {
+	for_each_possible(cpu) {
 		device = &per_cpu(ux500_cpuidle_device, cpu);
 		device->cpu = cpu;
 		ret = cpuidle_register_device(device);
@@ -139,7 +139,7 @@ out:
 	return ret;
 
 out_unregister:
-	for_each_online_cpu(cpu) {
+	for_each_possible_cpu(cpu) {
 		device = &per_cpu(ux500_cpuidle_device, cpu);
 		cpuidle_unregister_device(device);
 	}
-- 
1.7.9.5



From daniel.lezcano at linaro.org  Wed Apr 10 10:22:07 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Wed, 10 Apr 2013 16:22:07 +0200
Subject: [PATCH 02/18] cpuidle: remove en_core_tk_irqen flag
In-Reply-To: <1365603743-5618-1-git-send-email-daniel.lezcano@linaro.org>
References: <1365603743-5618-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1365603743-5618-3-git-send-email-daniel.lezcano@linaro.org>

The en_core_tk_irqen flag is set in all the cpuidle driver which
means it is not necessary to specify this flag.

Remove the flag and the code related to it.

Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
---
 arch/arm/mach-at91/cpuidle.c                    |    1 -
 arch/arm/mach-davinci/cpuidle.c                 |    1 -
 arch/arm/mach-exynos/cpuidle.c                  |    1 -
 arch/arm/mach-imx/cpuidle-imx6q.c               |    1 -
 arch/arm/mach-imx/pm-imx5.c                     |    1 -
 arch/arm/mach-omap2/cpuidle34xx.c               |    1 -
 arch/arm/mach-omap2/cpuidle44xx.c               |    1 -
 arch/arm/mach-s3c64xx/cpuidle.c                 |    1 -
 arch/arm/mach-shmobile/cpuidle.c                |    1 -
 arch/arm/mach-shmobile/pm-sh7372.c              |    1 -
 arch/arm/mach-tegra/cpuidle-tegra114.c          |    1 -
 arch/arm/mach-tegra/cpuidle-tegra20.c           |    1 -
 arch/arm/mach-tegra/cpuidle-tegra30.c           |    1 -
 arch/arm/mach-ux500/cpuidle.c                   |    1 -
 arch/powerpc/platforms/pseries/processor_idle.c |    1 -
 arch/sh/kernel/cpu/shmobile/cpuidle.c           |    1 -
 arch/x86/kernel/apm_32.c                        |    1 -
 drivers/acpi/processor_idle.c                   |    1 -
 drivers/cpuidle/cpuidle-calxeda.c               |    1 -
 drivers/cpuidle/cpuidle-kirkwood.c              |    1 -
 drivers/cpuidle/cpuidle.c                       |   72 ++++++-----------------
 drivers/idle/intel_idle.c                       |    1 -
 include/linux/cpuidle.h                         |   11 ----
 23 files changed, 18 insertions(+), 86 deletions(-)

diff --git a/arch/arm/mach-at91/cpuidle.c b/arch/arm/mach-at91/cpuidle.c
index 0c63815..0130df7 100644
--- a/arch/arm/mach-at91/cpuidle.c
+++ b/arch/arm/mach-at91/cpuidle.c
@@ -47,7 +47,6 @@ static int at91_enter_idle(struct cpuidle_device *dev,
 static struct cpuidle_driver at91_idle_driver = {
 	.name			= "at91_idle",
 	.owner			= THIS_MODULE,
-	.en_core_tk_irqen	= 1,
 	.states[0]		= ARM_CPUIDLE_WFI_STATE,
 	.states[1]		= {
 		.enter			= at91_enter_idle,
diff --git a/arch/arm/mach-davinci/cpuidle.c b/arch/arm/mach-davinci/cpuidle.c
index 22d6d4a..c2887c5 100644
--- a/arch/arm/mach-davinci/cpuidle.c
+++ b/arch/arm/mach-davinci/cpuidle.c
@@ -62,7 +62,6 @@ static int davinci_enter_idle(struct cpuidle_device *dev,
 static struct cpuidle_driver davinci_idle_driver = {
 	.name			= "cpuidle-davinci",
 	.owner			= THIS_MODULE,
-	.en_core_tk_irqen	= 1,
 	.states[0]		= ARM_CPUIDLE_WFI_STATE,
 	.states[1]		= {
 		.enter			= davinci_enter_idle,
diff --git a/arch/arm/mach-exynos/cpuidle.c b/arch/arm/mach-exynos/cpuidle.c
index fcfe025..498a7a2 100644
--- a/arch/arm/mach-exynos/cpuidle.c
+++ b/arch/arm/mach-exynos/cpuidle.c
@@ -58,7 +58,6 @@ static DEFINE_PER_CPU(struct cpuidle_device, exynos4_cpuidle_device);
 static struct cpuidle_driver exynos4_idle_driver = {
 	.name			= "exynos4_idle",
 	.owner			= THIS_MODULE,
-	.en_core_tk_irqen	= 1,
 };
 
 /* Ext-GIC nIRQ/nFIQ is the only wakeup source in AFTR */
diff --git a/arch/arm/mach-imx/cpuidle-imx6q.c b/arch/arm/mach-imx/cpuidle-imx6q.c
index a783a63..e2739ad 100644
--- a/arch/arm/mach-imx/cpuidle-imx6q.c
+++ b/arch/arm/mach-imx/cpuidle-imx6q.c
@@ -45,7 +45,6 @@ done:
 static struct cpuidle_driver imx6q_cpuidle_driver = {
 	.name = "imx6q_cpuidle",
 	.owner = THIS_MODULE,
-	.en_core_tk_irqen = 1,
 	.states = {
 		/* WFI */
 		ARM_CPUIDLE_WFI_STATE,
diff --git a/arch/arm/mach-imx/pm-imx5.c b/arch/arm/mach-imx/pm-imx5.c
index f67fd7e..4b52b3e 100644
--- a/arch/arm/mach-imx/pm-imx5.c
+++ b/arch/arm/mach-imx/pm-imx5.c
@@ -164,7 +164,6 @@ static int imx5_cpuidle_enter(struct cpuidle_device *dev,
 static struct cpuidle_driver imx5_cpuidle_driver = {
 	.name			= "imx5_cpuidle",
 	.owner			= THIS_MODULE,
-	.en_core_tk_irqen	= 1,
 	.states[0]	= {
 		.enter			= imx5_cpuidle_enter,
 		.exit_latency		= 2,
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c b/arch/arm/mach-omap2/cpuidle34xx.c
index a56310a..027a787 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -264,7 +264,6 @@ static DEFINE_PER_CPU(struct cpuidle_device, omap3_idle_dev);
 static struct cpuidle_driver omap3_idle_driver = {
 	.name             = "omap3_idle",
 	.owner            = THIS_MODULE,
-	.en_core_tk_irqen = 1,
 	.states = {
 		{
 			.enter		  = omap3_enter_idle_bm,
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c b/arch/arm/mach-omap2/cpuidle44xx.c
index f4b1b23..cd188de 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -162,7 +162,6 @@ static DEFINE_PER_CPU(struct cpuidle_device, omap4_idle_dev);
 static struct cpuidle_driver omap4_idle_driver = {
 	.name				= "omap4_idle",
 	.owner				= THIS_MODULE,
-	.en_core_tk_irqen		= 1,
 	.states = {
 		{
 			/* C1 - CPU0 ON + CPU1 ON + MPU ON */
diff --git a/arch/arm/mach-s3c64xx/cpuidle.c b/arch/arm/mach-s3c64xx/cpuidle.c
index ead5fab..852ff16 100644
--- a/arch/arm/mach-s3c64xx/cpuidle.c
+++ b/arch/arm/mach-s3c64xx/cpuidle.c
@@ -45,7 +45,6 @@ static DEFINE_PER_CPU(struct cpuidle_device, s3c64xx_cpuidle_device);
 static struct cpuidle_driver s3c64xx_cpuidle_driver = {
 	.name	= "s3c64xx_cpuidle",
 	.owner  = THIS_MODULE,
-	.en_core_tk_irqen = 1,
 	.states = {
 		{
 			.enter            = s3c64xx_enter_idle,
diff --git a/arch/arm/mach-shmobile/cpuidle.c b/arch/arm/mach-shmobile/cpuidle.c
index c872ae8..d671ae9 100644
--- a/arch/arm/mach-shmobile/cpuidle.c
+++ b/arch/arm/mach-shmobile/cpuidle.c
@@ -20,7 +20,6 @@ static struct cpuidle_device shmobile_cpuidle_dev;
 static struct cpuidle_driver shmobile_cpuidle_default_driver = {
 	.name			= "shmobile_cpuidle",
 	.owner			= THIS_MODULE,
-	.en_core_tk_irqen	= 1,
 	.states[0]		= ARM_CPUIDLE_WFI_STATE,
 	.safe_state_index	= 0, /* C1 */
 	.state_count		= 1,
diff --git a/arch/arm/mach-shmobile/pm-sh7372.c b/arch/arm/mach-shmobile/pm-sh7372.c
index f6b14ca..cbc2c36 100644
--- a/arch/arm/mach-shmobile/pm-sh7372.c
+++ b/arch/arm/mach-shmobile/pm-sh7372.c
@@ -410,7 +410,6 @@ static int sh7372_enter_a4s(struct cpuidle_device *dev,
 static struct cpuidle_driver sh7372_cpuidle_driver = {
 	.name			= "sh7372_cpuidle",
 	.owner			= THIS_MODULE,
-	.en_core_tk_irqen	= 1,
 	.state_count		= 5,
 	.safe_state_index	= 0, /* C1 */
 	.states[0] = ARM_CPUIDLE_WFI_STATE,
diff --git a/arch/arm/mach-tegra/cpuidle-tegra114.c b/arch/arm/mach-tegra/cpuidle-tegra114.c
index c527cff..c5fadf9 100644
--- a/arch/arm/mach-tegra/cpuidle-tegra114.c
+++ b/arch/arm/mach-tegra/cpuidle-tegra114.c
@@ -23,7 +23,6 @@
 static struct cpuidle_driver tegra_idle_driver = {
 	.name = "tegra_idle",
 	.owner = THIS_MODULE,
-	.en_core_tk_irqen = 1,
 	.state_count = 1,
 	.states = {
 		[0] = ARM_CPUIDLE_WFI_STATE_PWR(600),
diff --git a/arch/arm/mach-tegra/cpuidle-tegra20.c b/arch/arm/mach-tegra/cpuidle-tegra20.c
index b94d76a..f1f6ac4 100644
--- a/arch/arm/mach-tegra/cpuidle-tegra20.c
+++ b/arch/arm/mach-tegra/cpuidle-tegra20.c
@@ -51,7 +51,6 @@ static int tegra20_idle_lp2_coupled(struct cpuidle_device *dev,
 static struct cpuidle_driver tegra_idle_driver = {
 	.name = "tegra_idle",
 	.owner = THIS_MODULE,
-	.en_core_tk_irqen = 1,
 	.states = {
 		ARM_CPUIDLE_WFI_STATE_PWR(600),
 #ifdef CONFIG_PM_SLEEP
diff --git a/arch/arm/mach-tegra/cpuidle-tegra30.c b/arch/arm/mach-tegra/cpuidle-tegra30.c
index c4e01fe..f6a0c72 100644
--- a/arch/arm/mach-tegra/cpuidle-tegra30.c
+++ b/arch/arm/mach-tegra/cpuidle-tegra30.c
@@ -43,7 +43,6 @@ static int tegra30_idle_lp2(struct cpuidle_device *dev,
 static struct cpuidle_driver tegra_idle_driver = {
 	.name = "tegra_idle",
 	.owner = THIS_MODULE,
-	.en_core_tk_irqen = 1,
 #ifdef CONFIG_PM_SLEEP
 	.state_count = 2,
 #else
diff --git a/arch/arm/mach-ux500/cpuidle.c b/arch/arm/mach-ux500/cpuidle.c
index 1b16d9e..c29c1bf 100644
--- a/arch/arm/mach-ux500/cpuidle.c
+++ b/arch/arm/mach-ux500/cpuidle.c
@@ -94,7 +94,6 @@ out:
 static struct cpuidle_driver ux500_idle_driver = {
 	.name = "ux500_idle",
 	.owner = THIS_MODULE,
-	.en_core_tk_irqen = 1,
 	.states = {
 		ARM_CPUIDLE_WFI_STATE,
 		{
diff --git a/arch/powerpc/platforms/pseries/processor_idle.c b/arch/powerpc/platforms/pseries/processor_idle.c
index a197120..4644efa0 100644
--- a/arch/powerpc/platforms/pseries/processor_idle.c
+++ b/arch/powerpc/platforms/pseries/processor_idle.c
@@ -25,7 +25,6 @@
 struct cpuidle_driver pseries_idle_driver = {
 	.name             = "pseries_idle",
 	.owner            = THIS_MODULE,
-	.en_core_tk_irqen = 1,
 };
 
 #define MAX_IDLE_STATE_COUNT	2
diff --git a/arch/sh/kernel/cpu/shmobile/cpuidle.c b/arch/sh/kernel/cpu/shmobile/cpuidle.c
index 1ddc876..0986f21 100644
--- a/arch/sh/kernel/cpu/shmobile/cpuidle.c
+++ b/arch/sh/kernel/cpu/shmobile/cpuidle.c
@@ -55,7 +55,6 @@ static struct cpuidle_device cpuidle_dev;
 static struct cpuidle_driver cpuidle_driver = {
 	.name			= "sh_idle",
 	.owner			= THIS_MODULE,
-	.en_core_tk_irqen	= 1,
 };
 
 void sh_mobile_setup_cpuidle(void)
diff --git a/arch/x86/kernel/apm_32.c b/arch/x86/kernel/apm_32.c
index 66b5faf..53a4e27 100644
--- a/arch/x86/kernel/apm_32.c
+++ b/arch/x86/kernel/apm_32.c
@@ -373,7 +373,6 @@ static int apm_cpu_idle(struct cpuidle_device *dev,
 static struct cpuidle_driver apm_idle_driver = {
 	.name = "apm_idle",
 	.owner = THIS_MODULE,
-	.en_core_tk_irqen = 1,
 	.states = {
 		{ /* entry 0 is for polling */ },
 		{ /* entry 1 is for APM idle */
diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c
index ee255c6..f0df2c9 100644
--- a/drivers/acpi/processor_idle.c
+++ b/drivers/acpi/processor_idle.c
@@ -918,7 +918,6 @@ static int acpi_idle_enter_bm(struct cpuidle_device *dev,
 struct cpuidle_driver acpi_idle_driver = {
 	.name =		"acpi_idle",
 	.owner =	THIS_MODULE,
-	.en_core_tk_irqen = 1,
 };
 
 /**
diff --git a/drivers/cpuidle/cpuidle-calxeda.c b/drivers/cpuidle/cpuidle-calxeda.c
index e1aab38..a3b56f5 100644
--- a/drivers/cpuidle/cpuidle-calxeda.c
+++ b/drivers/cpuidle/cpuidle-calxeda.c
@@ -100,7 +100,6 @@ static void calxeda_idle_cpuidle_devices_uninit(void)
 
 static struct cpuidle_driver calxeda_idle_driver = {
 	.name = "calxeda_idle",
-	.en_core_tk_irqen = 1,
 	.states = {
 		ARM_CPUIDLE_WFI_STATE,
 		{
diff --git a/drivers/cpuidle/cpuidle-kirkwood.c b/drivers/cpuidle/cpuidle-kirkwood.c
index 53aad73..6f31524 100644
--- a/drivers/cpuidle/cpuidle-kirkwood.c
+++ b/drivers/cpuidle/cpuidle-kirkwood.c
@@ -41,7 +41,6 @@ static int kirkwood_enter_idle(struct cpuidle_device *dev,
 static struct cpuidle_driver kirkwood_idle_driver = {
 	.name			= "kirkwood_idle",
 	.owner			= THIS_MODULE,
-	.en_core_tk_irqen	= 1,
 	.states[0]		= ARM_CPUIDLE_WFI_STATE,
 	.states[1]		= {
 		.enter			= kirkwood_enter_idle,
diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
index c500370..0da795b 100644
--- a/drivers/cpuidle/cpuidle.c
+++ b/drivers/cpuidle/cpuidle.c
@@ -43,24 +43,6 @@ void disable_cpuidle(void)
 
 static int __cpuidle_register_device(struct cpuidle_device *dev);
 
-static inline int cpuidle_enter(struct cpuidle_device *dev,
-				struct cpuidle_driver *drv, int index)
-{
-	struct cpuidle_state *target_state = &drv->states[index];
-	return target_state->enter(dev, drv, index);
-}
-
-static inline int cpuidle_enter_tk(struct cpuidle_device *dev,
-			       struct cpuidle_driver *drv, int index)
-{
-	return cpuidle_wrap_enter(dev, drv, index, cpuidle_enter);
-}
-
-typedef int (*cpuidle_enter_t)(struct cpuidle_device *dev,
-			       struct cpuidle_driver *drv, int index);
-
-static cpuidle_enter_t cpuidle_enter_ops;
-
 /**
  * cpuidle_play_dead - cpu off-lining
  *
@@ -90,11 +72,27 @@ int cpuidle_play_dead(void)
  * @next_state: index into drv->states of the state to enter
  */
 int cpuidle_enter_state(struct cpuidle_device *dev, struct cpuidle_driver *drv,
-		int next_state)
+			int index)
 {
 	int entered_state;
 
-	entered_state = cpuidle_enter_ops(dev, drv, next_state);
+	struct cpuidle_state *target_state = &drv->states[index];
+	ktime_t time_start, time_end;
+	s64 diff;
+
+	time_start = ktime_get();
+
+	entered_state = target_state->enter(dev, drv, index);
+
+	time_end = ktime_get();
+
+	local_irq_enable();
+
+	diff = ktime_to_us(ktime_sub(time_end, time_start));
+	if (diff > INT_MAX)
+		diff = INT_MAX;
+
+	dev->last_residency = (int) diff;
 
 	if (entered_state >= 0) {
 		/* Update cpuidle counters */
@@ -231,37 +229,6 @@ void cpuidle_resume(void)
 	mutex_unlock(&cpuidle_lock);
 }
 
-/**
- * cpuidle_wrap_enter - performs timekeeping and irqen around enter function
- * @dev: pointer to a valid cpuidle_device object
- * @drv: pointer to a valid cpuidle_driver object
- * @index: index of the target cpuidle state.
- */
-int cpuidle_wrap_enter(struct cpuidle_device *dev,
-				struct cpuidle_driver *drv, int index,
-				int (*enter)(struct cpuidle_device *dev,
-					struct cpuidle_driver *drv, int index))
-{
-	ktime_t time_start, time_end;
-	s64 diff;
-
-	time_start = ktime_get();
-
-	index = enter(dev, drv, index);
-
-	time_end = ktime_get();
-
-	local_irq_enable();
-
-	diff = ktime_to_us(ktime_sub(time_end, time_start));
-	if (diff > INT_MAX)
-		diff = INT_MAX;
-
-	dev->last_residency = (int) diff;
-
-	return index;
-}
-
 #ifdef CONFIG_ARCH_HAS_CPU_RELAX
 static int poll_idle(struct cpuidle_device *dev,
 		struct cpuidle_driver *drv, int index)
@@ -333,9 +300,6 @@ int cpuidle_enable_device(struct cpuidle_device *dev)
 			return ret;
 	}
 
-	cpuidle_enter_ops = drv->en_core_tk_irqen ?
-		cpuidle_enter_tk : cpuidle_enter;
-
 	poll_idle_init(drv);
 
 	ret = cpuidle_add_device_sysfs(dev);
diff --git a/drivers/idle/intel_idle.c b/drivers/idle/intel_idle.c
index 5d66750..48d7584 100644
--- a/drivers/idle/intel_idle.c
+++ b/drivers/idle/intel_idle.c
@@ -71,7 +71,6 @@
 static struct cpuidle_driver intel_idle_driver = {
 	.name = "intel_idle",
 	.owner = THIS_MODULE,
-	.en_core_tk_irqen = 1,
 };
 /* intel_idle.max_cstate=0 disables driver */
 static int max_cstate = CPUIDLE_STATE_MAX - 1;
diff --git a/include/linux/cpuidle.h b/include/linux/cpuidle.h
index fc3e580..79e3811 100644
--- a/include/linux/cpuidle.h
+++ b/include/linux/cpuidle.h
@@ -105,8 +105,6 @@ struct cpuidle_driver {
 	struct module 		*owner;
 	int                     refcnt;
 
-	/* set to 1 to use the core cpuidle time keeping (for all states). */
-	unsigned int		en_core_tk_irqen:1;
         /* used by the cpuidle framework to setup the broadcast timer */
 	unsigned int            bctimer:1;
 	/* states array must be ordered in decreasing power consumption */
@@ -132,10 +130,6 @@ extern void cpuidle_pause(void);
 extern void cpuidle_resume(void);
 extern int cpuidle_enable_device(struct cpuidle_device *dev);
 extern void cpuidle_disable_device(struct cpuidle_device *dev);
-extern int cpuidle_wrap_enter(struct cpuidle_device *dev,
-				struct cpuidle_driver *drv, int index,
-				int (*enter)(struct cpuidle_device *dev,
-					struct cpuidle_driver *drv, int index));
 extern int cpuidle_play_dead(void);
 
 extern struct cpuidle_driver *cpuidle_get_cpu_driver(struct cpuidle_device *dev);
@@ -162,11 +156,6 @@ static inline void cpuidle_resume(void) { }
 static inline int cpuidle_enable_device(struct cpuidle_device *dev)
 {return -ENODEV; }
 static inline void cpuidle_disable_device(struct cpuidle_device *dev) { }
-static inline int cpuidle_wrap_enter(struct cpuidle_device *dev,
-				struct cpuidle_driver *drv, int index,
-				int (*enter)(struct cpuidle_device *dev,
-					struct cpuidle_driver *drv, int index))
-{ return -ENODEV; }
 static inline int cpuidle_play_dead(void) {return -ENODEV; }
 #endif
 
-- 
1.7.9.5



From daniel.lezcano at linaro.org  Wed Apr 10 10:22:09 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Wed, 10 Apr 2013 16:22:09 +0200
Subject: [PATCH 04/18] ARM: imx: cpuidle: create separate drivers for imx5/imx6
In-Reply-To: <1365603743-5618-1-git-send-email-daniel.lezcano@linaro.org>
References: <1365603743-5618-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1365603743-5618-5-git-send-email-daniel.lezcano@linaro.org>

The code intializes the cpuidle driver at different places.
The cpuidle driver for :
  * imx5 : is in the pm-imx5.c, the init function is in cpuidle.c
  * imx6 : is in cpuidle-imx6q.c, the init function is in cpuidle.c
           and cpuidle-imx6q.c

Instead of having the cpuidle code spread across different files,
let's write a driver for each SoC and make the code similar.

That implies some code duplication but that will be fixed with the
next patches which consolidate the initialization for all the drivers.

Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
---
 arch/arm/mach-imx/Makefile        |    1 +
 arch/arm/mach-imx/cpuidle-imx5.c  |   74 ++++++++++++++++++++++++++++++++++
 arch/arm/mach-imx/cpuidle-imx6q.c |   36 ++++++++++++++++-
 arch/arm/mach-imx/cpuidle.c       |   80 -------------------------------------
 arch/arm/mach-imx/cpuidle.h       |   10 ++---
 arch/arm/mach-imx/pm-imx5.c       |   29 +-------------
 6 files changed, 115 insertions(+), 115 deletions(-)
 create mode 100644 arch/arm/mach-imx/cpuidle-imx5.c
 delete mode 100644 arch/arm/mach-imx/cpuidle.c

diff --git a/arch/arm/mach-imx/Makefile b/arch/arm/mach-imx/Makefile
index c4ce090..bfd5f5b 100644
--- a/arch/arm/mach-imx/Makefile
+++ b/arch/arm/mach-imx/Makefile
@@ -31,6 +31,7 @@ obj-$(CONFIG_CPU_FREQ_IMX)    += cpufreq.o
 
 ifeq ($(CONFIG_CPU_IDLE),y)
 obj-y += cpuidle.o
+obj-$(CONFIG_SOC_IMX5) += cpuidle-imx5.o
 obj-$(CONFIG_SOC_IMX6Q) += cpuidle-imx6q.o
 endif
 
diff --git a/arch/arm/mach-imx/cpuidle-imx5.c b/arch/arm/mach-imx/cpuidle-imx5.c
new file mode 100644
index 0000000..3d9f0c9
--- /dev/null
+++ b/arch/arm/mach-imx/cpuidle-imx5.c
@@ -0,0 +1,74 @@
+/*
+ * Copyright (C) 2012 Freescale Semiconductor, Inc.
+ *
+ * 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/cpuidle.h>
+#include <linux/module.h>
+#include <asm/system_misc.h>
+#include <asm/proc-fns.h>
+
+#include "hardware.h"
+
+static DEFINE_PER_CPU(struct cpuidle_device, devices);
+
+static int imx5_cpuidle_enter(struct cpuidle_device *dev,
+			      struct cpuidle_driver *drv, int index)
+{
+	arm_pm_idle();
+	return index;
+}
+
+static struct cpuidle_driver imx5_cpuidle_driver = {
+	.name             = "imx5_cpuidle",
+	.owner            = THIS_MODULE,
+	.states[0] = {
+		.enter            = imx5_cpuidle_enter,
+		.exit_latency     = 2,
+		.target_residency = 1,
+		.flags            = CPUIDLE_FLAG_TIME_VALID,
+		.name             = "IMX5 SRPG",
+		.desc             = "CPU state retained,powered off",
+	},
+	.state_count = 1,
+};
+
+int __init imx5_cpuidle_init(void)
+{
+	struct cpuidle_device *dev;
+	int cpu, ret;
+
+	ret = cpuidle_register_driver(&imx5_cpuidle_driver);
+	if (ret) {
+		pr_err("%s: Failed to register cpuidle driver with error: %d\n",
+			 __func__, ret);
+		return ret;
+	}
+
+	/* initialize state data for each cpuidle_device */
+	for_each_possible_cpu(cpu) {
+		dev = &per_cpu(devices, cpu);
+		dev->cpu = cpu;
+
+		ret = cpuidle_register_device(dev);
+		if (ret) {
+			pr_err("%s: Failed to register cpu %u, error: %d\n",
+				__func__, cpu, ret);
+			goto out_unregister;
+		}
+	}
+
+	return 0;
+
+out_unregister:
+	for_each_possible_cpu(cpu) {
+		dev = &per_cpu(devices, cpu);
+		cpuidle_unregister_device(dev);
+	}
+
+	cpuidle_unregister_driver(&imx5_cpuidle_driver);
+	return ret;
+}
diff --git a/arch/arm/mach-imx/cpuidle-imx6q.c b/arch/arm/mach-imx/cpuidle-imx6q.c
index e2739ad..c066b74faa 100644
--- a/arch/arm/mach-imx/cpuidle-imx6q.c
+++ b/arch/arm/mach-imx/cpuidle-imx6q.c
@@ -14,6 +14,8 @@
 #include "common.h"
 #include "cpuidle.h"
 
+static DEFINE_PER_CPU(struct cpuidle_device, devices);
+
 static atomic_t master = ATOMIC_INIT(0);
 static DEFINE_SPINLOCK(master_lock);
 
@@ -65,11 +67,43 @@ static struct cpuidle_driver imx6q_cpuidle_driver = {
 
 int __init imx6q_cpuidle_init(void)
 {
+	struct cpuidle_device *dev;
+	int cpu, ret;
+
 	/* Need to enable SCU standby for entering WAIT modes */
 	imx_scu_standby_enable();
 
 	/* Set chicken bit to get a reliable WAIT mode support */
 	imx6q_set_chicken_bit();
 
-	return imx_cpuidle_init(&imx6q_cpuidle_driver);
+	ret = cpuidle_register_driver(&imx6q_cpuidle_driver);
+	if (ret) {
+		pr_err("%s: Failed to register cpuidle driver with error: %d\n",
+			 __func__, ret);
+		return ret;
+	}
+
+	/* initialize state data for each cpuidle_device */
+	for_each_possible_cpu(cpu) {
+		dev = &per_cpu(devices, cpu);
+		dev->cpu = cpu;
+
+		ret = cpuidle_register_device(dev);
+		if (ret) {
+			pr_err("%s: Failed to register cpu %u, error: %d\n",
+				__func__, cpu, ret);
+			goto out_unregister;
+		}
+	}
+
+	return 0;
+
+out_unregister:
+	for_each_possible_cpu(cpu) {
+		dev = &per_cpu(devices, cpu);
+		cpuidle_unregister_device(dev);
+	}
+
+	cpuidle_unregister_driver(&imx6q_cpuidle_driver);
+	return ret;
 }
diff --git a/arch/arm/mach-imx/cpuidle.c b/arch/arm/mach-imx/cpuidle.c
deleted file mode 100644
index d4cb511..0000000
--- a/arch/arm/mach-imx/cpuidle.c
+++ /dev/null
@@ -1,80 +0,0 @@
-/*
- * Copyright 2012 Freescale Semiconductor, Inc.
- * Copyright 2012 Linaro Ltd.
- *
- * The code contained herein is licensed under the GNU General Public
- * License. You may obtain a copy of the GNU General Public License
- * Version 2 or later at the following locations:
- *
- * http://www.opensource.org/licenses/gpl-license.html
- * http://www.gnu.org/copyleft/gpl.html
- */
-
-#include <linux/cpuidle.h>
-#include <linux/err.h>
-#include <linux/hrtimer.h>
-#include <linux/io.h>
-#include <linux/kernel.h>
-#include <linux/slab.h>
-
-static struct cpuidle_device __percpu * imx_cpuidle_devices;
-
-static void __init imx_cpuidle_devices_uninit(void)
-{
-	int cpu_id;
-	struct cpuidle_device *dev;
-
-	for_each_possible_cpu(cpu_id) {
-		dev = per_cpu_ptr(imx_cpuidle_devices, cpu_id);
-		cpuidle_unregister_device(dev);
-	}
-
-	free_percpu(imx_cpuidle_devices);
-}
-
-int __init imx_cpuidle_init(struct cpuidle_driver *drv)
-{
-	struct cpuidle_device *dev;
-	int cpu_id, ret;
-
-	if (drv->state_count > CPUIDLE_STATE_MAX) {
-		pr_err("%s: state_count exceeds maximum\n", __func__);
-		return -EINVAL;
-	}
-
-	ret = cpuidle_register_driver(drv);
-	if (ret) {
-		pr_err("%s: Failed to register cpuidle driver with error: %d\n",
-			 __func__, ret);
-		return ret;
-	}
-
-	imx_cpuidle_devices = alloc_percpu(struct cpuidle_device);
-	if (imx_cpuidle_devices == NULL) {
-		ret = -ENOMEM;
-		goto unregister_drv;
-	}
-
-	/* initialize state data for each cpuidle_device */
-	for_each_possible_cpu(cpu_id) {
-		dev = per_cpu_ptr(imx_cpuidle_devices, cpu_id);
-		dev->cpu = cpu_id;
-		dev->state_count = drv->state_count;
-
-		ret = cpuidle_register_device(dev);
-		if (ret) {
-			pr_err("%s: Failed to register cpu %u, error: %d\n",
-				__func__, cpu_id, ret);
-			goto uninit;
-		}
-	}
-
-	return 0;
-
-uninit:
-	imx_cpuidle_devices_uninit();
-
-unregister_drv:
-	cpuidle_unregister_driver(drv);
-	return ret;
-}
diff --git a/arch/arm/mach-imx/cpuidle.h b/arch/arm/mach-imx/cpuidle.h
index e092d13..786f98e 100644
--- a/arch/arm/mach-imx/cpuidle.h
+++ b/arch/arm/mach-imx/cpuidle.h
@@ -10,18 +10,16 @@
  * http://www.gnu.org/copyleft/gpl.html
  */
 
-#include <linux/cpuidle.h>
-
 #ifdef CONFIG_CPU_IDLE
-extern int imx_cpuidle_init(struct cpuidle_driver *drv);
+extern int imx5_cpuidle_init(void);
 extern int imx6q_cpuidle_init(void);
 #else
-static inline int imx_cpuidle_init(struct cpuidle_driver *drv)
+static inline int imx5_cpuidle_init(void)
 {
-	return -ENODEV;
+	return 0;
 }
 static inline int imx6q_cpuidle_init(void)
 {
-	return -ENODEV;
+	return 0;
 }
 #endif
diff --git a/arch/arm/mach-imx/pm-imx5.c b/arch/arm/mach-imx/pm-imx5.c
index 4b52b3e..82e79c6 100644
--- a/arch/arm/mach-imx/pm-imx5.c
+++ b/arch/arm/mach-imx/pm-imx5.c
@@ -149,32 +149,6 @@ static void imx5_pm_idle(void)
 	imx5_cpu_do_idle();
 }
 
-static int imx5_cpuidle_enter(struct cpuidle_device *dev,
-				struct cpuidle_driver *drv, int idx)
-{
-	int ret;
-
-	ret = imx5_cpu_do_idle();
-	if (ret < 0)
-		return ret;
-
-	return idx;
-}
-
-static struct cpuidle_driver imx5_cpuidle_driver = {
-	.name			= "imx5_cpuidle",
-	.owner			= THIS_MODULE,
-	.states[0]	= {
-		.enter			= imx5_cpuidle_enter,
-		.exit_latency		= 2,
-		.target_residency	= 1,
-		.flags			= CPUIDLE_FLAG_TIME_VALID,
-		.name			= "IMX5 SRPG",
-		.desc			= "CPU state retained,powered off",
-	},
-	.state_count		= 1,
-};
-
 static int __init imx5_pm_common_init(void)
 {
 	int ret;
@@ -192,8 +166,7 @@ static int __init imx5_pm_common_init(void)
 	/* Set the registers to the default cpu idle state. */
 	mx5_cpu_lp_set(IMX5_DEFAULT_CPU_IDLE_STATE);
 
-	imx_cpuidle_init(&imx5_cpuidle_driver);
-	return 0;
+	return imx5_cpuidle_init();
 }
 
 void __init imx51_pm_init(void)
-- 
1.7.9.5



From daniel.lezcano at linaro.org  Wed Apr 10 10:22:10 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Wed, 10 Apr 2013 16:22:10 +0200
Subject: [PATCH 05/18] cpuidle: make a single register function for all
In-Reply-To: <1365603743-5618-1-git-send-email-daniel.lezcano@linaro.org>
References: <1365603743-5618-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1365603743-5618-6-git-send-email-daniel.lezcano@linaro.org>

The usual scheme to initialize a cpuidle driver on a SMP is:

	cpuidle_register_driver(drv);
	for_each_possible_cpu(cpu) {
		device = &per_cpu(cpuidle_dev, cpu);
		cpuidle_register_device(device);
	}

This code is duplicated in each cpuidle driver.

On UP systems, it is done this way:

	cpuidle_register_driver(drv);
	device = &per_cpu(cpuidle_dev, cpu);
	cpuidle_register_device(device);

On UP, the macro 'for_each_cpu' does one iteration:

#define for_each_cpu(cpu, mask)                 \
        for ((cpu) = 0; (cpu) < 1; (cpu)++, (void)mask)

Hence, the initialization loop is the same for UP than SMP.

Beside, we saw different bugs / mis-initialization / return code unchecked in
the different drivers, the code is duplicated including bugs. After fixing all
these ones, it appears the initialization pattern is the same for everyone.

Let's add a wrapper function doing this initialization with a cpumask parameter
for the coupled idle states and use it for all the drivers.

That will save a lot of LOC, consolidate the code, and the modifications in the
future could be done in a single place. Another benefit is the consolidation of
the cpuidle_device variable which is now in the cpuidle framework and no longer
spread accross the different arch specific drivers.

Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
---
 drivers/cpuidle/cpuidle.c |   65 +++++++++++++++++++++++++++++++++++++++++++++
 include/linux/cpuidle.h   |    9 +++++--
 2 files changed, 72 insertions(+), 2 deletions(-)

diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
index 0da795b..3a5454b 100644
--- a/drivers/cpuidle/cpuidle.c
+++ b/drivers/cpuidle/cpuidle.c
@@ -24,6 +24,7 @@
 #include "cpuidle.h"
 
 DEFINE_PER_CPU(struct cpuidle_device *, cpuidle_devices);
+DEFINE_PER_CPU(struct cpuidle_device, cpuidle_dev);
 
 DEFINE_MUTEX(cpuidle_lock);
 LIST_HEAD(cpuidle_detected_devices);
@@ -453,6 +454,70 @@ void cpuidle_unregister_device(struct cpuidle_device *dev)
 
 EXPORT_SYMBOL_GPL(cpuidle_unregister_device);
 
+/*
+ * cpuidle_unregister: unregister a driver and the devices. This function
+ * can be used only if the driver has been previously registered through
+ * the cpuidle_register function.
+ *
+ * @drv: a valid pointer to a struct cpuidle_driver
+ */
+void cpuidle_unregister(struct cpuidle_driver *drv)
+{
+	int cpu;
+	struct cpuidle_device *device;
+
+	for_each_possible_cpu(cpu) {
+		device = &per_cpu(cpuidle_dev, cpu);
+		cpuidle_unregister_device(device);
+	}
+
+	cpuidle_unregister_driver(drv);
+}
+EXPORT_SYMBOL_GPL(cpuidle_unregister);
+
+/**
+ * cpuidle_register: registers the driver and the cpu devices with the
+ * coupled_cpus passed as parameter. This function is used for all common
+ * initialization pattern there are in the arch specific drivers. The
+ * devices is globally defined in this file.
+ *
+ * @drv         : a valid pointer to a struct cpuidle_driver
+ * @coupled_cpus: a cpumask for the coupled states
+ *
+ * Returns 0 on success, < 0 otherwise
+ */
+int cpuidle_register(struct cpuidle_driver *drv,
+		     const struct cpumask *const coupled_cpus)
+{
+	int ret, cpu;
+	struct cpuidle_device *device;
+
+	ret = cpuidle_register_driver(drv);
+	if (ret) {
+		printk(KERN_ERR "failed to register cpuidle driver\n");
+		return ret;
+	}
+
+	for_each_possible_cpu(cpu) {
+		device = &per_cpu(cpuidle_dev, cpu);
+		device->cpu = cpu;
+#ifdef CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED
+		device->coupled_cpus = *coupled_cpus;
+#endif
+		ret = cpuidle_register_device(device);
+		if (!ret)
+			continue;
+
+		printk(KERN_ERR "Failed to register cpuidle "
+		       "device for cpu%d\n", cpu);
+		cpuidle_unregister(drv);
+		break;
+	}
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(cpuidle_register);
+
 #ifdef CONFIG_SMP
 
 static void smp_callback(void *v)
diff --git a/include/linux/cpuidle.h b/include/linux/cpuidle.h
index 79e3811..3c86faa 100644
--- a/include/linux/cpuidle.h
+++ b/include/linux/cpuidle.h
@@ -123,7 +123,9 @@ extern void cpuidle_driver_unref(void);
 extern void cpuidle_unregister_driver(struct cpuidle_driver *drv);
 extern int cpuidle_register_device(struct cpuidle_device *dev);
 extern void cpuidle_unregister_device(struct cpuidle_device *dev);
-
+extern int cpuidle_register(struct cpuidle_driver *drv,
+			    const struct cpumask *const coupled_cpus);
+extern void cpuidle_unregister(struct cpuidle_driver *drv);
 extern void cpuidle_pause_and_lock(void);
 extern void cpuidle_resume_and_unlock(void);
 extern void cpuidle_pause(void);
@@ -148,7 +150,10 @@ static inline void cpuidle_unregister_driver(struct cpuidle_driver *drv) { }
 static inline int cpuidle_register_device(struct cpuidle_device *dev)
 {return -ENODEV; }
 static inline void cpuidle_unregister_device(struct cpuidle_device *dev) { }
-
+static inline int cpuidle_register(struct cpuidle_driver *drv,
+				   const struct cpumask *const coupled_cpus)
+{return -ENODEV; }
+static inline void cpuidle_unregister(struct cpuidle_driver *drv) { }
 static inline void cpuidle_pause_and_lock(void) { }
 static inline void cpuidle_resume_and_unlock(void) { }
 static inline void cpuidle_pause(void) { }
-- 
1.7.9.5



From daniel.lezcano at linaro.org  Wed Apr 10 10:22:11 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Wed, 10 Apr 2013 16:22:11 +0200
Subject: [PATCH 06/18] ARM: ux500: cpuidle: use init/exit common routine
In-Reply-To: <1365603743-5618-1-git-send-email-daniel.lezcano@linaro.org>
References: <1365603743-5618-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1365603743-5618-7-git-send-email-daniel.lezcano@linaro.org>

Remove the duplicate code and use the cpuidle common code for initialization.

Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
---
 arch/arm/mach-ux500/cpuidle.c |   32 +-------------------------------
 1 file changed, 1 insertion(+), 31 deletions(-)

diff --git a/arch/arm/mach-ux500/cpuidle.c b/arch/arm/mach-ux500/cpuidle.c
index 5657d4a..488e074 100644
--- a/arch/arm/mach-ux500/cpuidle.c
+++ b/arch/arm/mach-ux500/cpuidle.c
@@ -21,7 +21,6 @@
 
 static atomic_t master = ATOMIC_INIT(0);
 static DEFINE_SPINLOCK(master_lock);
-static DEFINE_PER_CPU(struct cpuidle_device, ux500_cpuidle_device);
 
 static inline int ux500_enter_idle(struct cpuidle_device *dev,
 				   struct cpuidle_driver *drv, int index)
@@ -112,40 +111,11 @@ static struct cpuidle_driver ux500_idle_driver = {
 
 int __init ux500_idle_init(void)
 {
-	int ret, cpu;
-	struct cpuidle_device *device;
-
         /* Configure wake up reasons */
 	prcmu_enable_wakeups(PRCMU_WAKEUP(ARM) | PRCMU_WAKEUP(RTC) |
 			     PRCMU_WAKEUP(ABB));
 
-	ret = cpuidle_register_driver(&ux500_idle_driver);
-	if (ret) {
-		printk(KERN_ERR "failed to register ux500 idle driver\n");
-		return ret;
-	}
-
-	for_each_possible(cpu) {
-		device = &per_cpu(ux500_cpuidle_device, cpu);
-		device->cpu = cpu;
-		ret = cpuidle_register_device(device);
-		if (ret) {
-			printk(KERN_ERR "Failed to register cpuidle "
-			       "device for cpu%d\n", cpu);
-			goto out_unregister;
-		}
-	}
-out:
-	return ret;
-
-out_unregister:
-	for_each_possible_cpu(cpu) {
-		device = &per_cpu(ux500_cpuidle_device, cpu);
-		cpuidle_unregister_device(device);
-	}
-
-	cpuidle_unregister_driver(&ux500_idle_driver);
-	goto out;
+	return cpuidle_register(&ux500_idle_driver, NULL);
 }
 
 device_initcall(ux500_idle_init);
-- 
1.7.9.5



From daniel.lezcano at linaro.org  Wed Apr 10 10:22:12 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Wed, 10 Apr 2013 16:22:12 +0200
Subject: [PATCH 07/18] ARM: at91: cpuidle: use init/exit common routine
In-Reply-To: <1365603743-5618-1-git-send-email-daniel.lezcano@linaro.org>
References: <1365603743-5618-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1365603743-5618-8-git-send-email-daniel.lezcano@linaro.org>

Remove the duplicate code and use the arm cpuidle driver's common code
for initialization.

Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
---
 arch/arm/mach-at91/cpuidle.c |   17 ++---------------
 1 file changed, 2 insertions(+), 15 deletions(-)

diff --git a/arch/arm/mach-at91/cpuidle.c b/arch/arm/mach-at91/cpuidle.c
index 0130df7..48f1228 100644
--- a/arch/arm/mach-at91/cpuidle.c
+++ b/arch/arm/mach-at91/cpuidle.c
@@ -27,8 +27,6 @@
 
 #define AT91_MAX_STATES	2
 
-static DEFINE_PER_CPU(struct cpuidle_device, at91_cpuidle_device);
-
 /* Actual code that puts the SoC in different idle states */
 static int at91_enter_idle(struct cpuidle_device *dev,
 			struct cpuidle_driver *drv,
@@ -60,20 +58,9 @@ static struct cpuidle_driver at91_idle_driver = {
 };
 
 /* Initialize CPU idle by registering the idle states */
-static int at91_init_cpuidle(void)
+static int __init at91_init_cpuidle(void)
 {
-	struct cpuidle_device *device;
-
-	device = &per_cpu(at91_cpuidle_device, smp_processor_id());
-	device->state_count = AT91_MAX_STATES;
-
-	cpuidle_register_driver(&at91_idle_driver);
-
-	if (cpuidle_register_device(device)) {
-		printk(KERN_ERR "at91_init_cpuidle: Failed registering\n");
-		return -EIO;
-	}
-	return 0;
+	return cpuidle_register(&at91_idle_driver, NULL);
 }
 
 device_initcall(at91_init_cpuidle);
-- 
1.7.9.5



From daniel.lezcano at linaro.org  Wed Apr 10 10:22:13 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Wed, 10 Apr 2013 16:22:13 +0200
Subject: [PATCH 08/18] ARM: OMAP3: cpuidle: use init/exit common routine
In-Reply-To: <1365603743-5618-1-git-send-email-daniel.lezcano@linaro.org>
References: <1365603743-5618-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1365603743-5618-9-git-send-email-daniel.lezcano@linaro.org>

Remove the duplicated code and use the cpuidle common code for initialization.

Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
---
 arch/arm/mach-omap2/cpuidle34xx.c |   18 ++----------------
 1 file changed, 2 insertions(+), 16 deletions(-)

diff --git a/arch/arm/mach-omap2/cpuidle34xx.c b/arch/arm/mach-omap2/cpuidle34xx.c
index 027a787..cca045c 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -26,6 +26,7 @@
 #include <linux/cpuidle.h>
 #include <linux/export.h>
 #include <linux/cpu_pm.h>
+#include <asm/cpuidle.h>
 
 #include "powerdomain.h"
 #include "clockdomain.h"
@@ -259,8 +260,6 @@ static int omap3_enter_idle_bm(struct cpuidle_device *dev,
 	return ret;
 }
 
-static DEFINE_PER_CPU(struct cpuidle_device, omap3_idle_dev);
-
 static struct cpuidle_driver omap3_idle_driver = {
 	.name             = "omap3_idle",
 	.owner            = THIS_MODULE,
@@ -336,8 +335,6 @@ static struct cpuidle_driver omap3_idle_driver = {
  */
 int __init omap3_idle_init(void)
 {
-	struct cpuidle_device *dev;
-
 	mpu_pd = pwrdm_lookup("mpu_pwrdm");
 	core_pd = pwrdm_lookup("core_pwrdm");
 	per_pd = pwrdm_lookup("per_pwrdm");
@@ -346,16 +343,5 @@ int __init omap3_idle_init(void)
 	if (!mpu_pd || !core_pd || !per_pd || !cam_pd)
 		return -ENODEV;
 
-	cpuidle_register_driver(&omap3_idle_driver);
-
-	dev = &per_cpu(omap3_idle_dev, smp_processor_id());
-	dev->cpu = 0;
-
-	if (cpuidle_register_device(dev)) {
-		printk(KERN_ERR "%s: CPUidle register device failed\n",
-		       __func__);
-		return -EIO;
-	}
-
-	return 0;
+	return cpuidle_register(&omap3_idle_driver, NULL);
 }
-- 
1.7.9.5



From daniel.lezcano at linaro.org  Wed Apr 10 10:22:14 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Wed, 10 Apr 2013 16:22:14 +0200
Subject: [PATCH 09/18] ARM: s3c64xx: cpuidle: use init/exit common routine
In-Reply-To: <1365603743-5618-1-git-send-email-daniel.lezcano@linaro.org>
References: <1365603743-5618-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1365603743-5618-10-git-send-email-daniel.lezcano@linaro.org>

Remove the duplicated code and use the cpuidle common code for initialization.

Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
---
 arch/arm/mach-s3c64xx/cpuidle.c |   14 +-------------
 1 file changed, 1 insertion(+), 13 deletions(-)

diff --git a/arch/arm/mach-s3c64xx/cpuidle.c b/arch/arm/mach-s3c64xx/cpuidle.c
index 852ff16..3c8ab07 100644
--- a/arch/arm/mach-s3c64xx/cpuidle.c
+++ b/arch/arm/mach-s3c64xx/cpuidle.c
@@ -40,8 +40,6 @@ static int s3c64xx_enter_idle(struct cpuidle_device *dev,
 	return index;
 }
 
-static DEFINE_PER_CPU(struct cpuidle_device, s3c64xx_cpuidle_device);
-
 static struct cpuidle_driver s3c64xx_cpuidle_driver = {
 	.name	= "s3c64xx_cpuidle",
 	.owner  = THIS_MODULE,
@@ -60,16 +58,6 @@ static struct cpuidle_driver s3c64xx_cpuidle_driver = {
 
 static int __init s3c64xx_init_cpuidle(void)
 {
-	int ret;
-
-	cpuidle_register_driver(&s3c64xx_cpuidle_driver);
-
-	ret = cpuidle_register_device(&s3c64xx_cpuidle_device);
-	if (ret) {
-		pr_err("Failed to register cpuidle device: %d\n", ret);
-		return ret;
-	}
-
-	return 0;
+	return cpuidle_register(&s3c64xx_cpuidle_driver, NULL);
 }
 device_initcall(s3c64xx_init_cpuidle);
-- 
1.7.9.5



From daniel.lezcano at linaro.org  Wed Apr 10 10:22:15 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Wed, 10 Apr 2013 16:22:15 +0200
Subject: [PATCH 10/18] ARM: tegra1: cpuidle: use init/exit common routine
In-Reply-To: <1365603743-5618-1-git-send-email-daniel.lezcano@linaro.org>
References: <1365603743-5618-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1365603743-5618-11-git-send-email-daniel.lezcano@linaro.org>

Remove the duplicated code and use the cpuidle common code for initialization.

Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
---
 arch/arm/mach-tegra/cpuidle-tegra114.c |   26 +-------------------------
 1 file changed, 1 insertion(+), 25 deletions(-)

diff --git a/arch/arm/mach-tegra/cpuidle-tegra114.c b/arch/arm/mach-tegra/cpuidle-tegra114.c
index c5fadf9..1d1c602 100644
--- a/arch/arm/mach-tegra/cpuidle-tegra114.c
+++ b/arch/arm/mach-tegra/cpuidle-tegra114.c
@@ -29,31 +29,7 @@ static struct cpuidle_driver tegra_idle_driver = {
 	},
 };
 
-static DEFINE_PER_CPU(struct cpuidle_device, tegra_idle_device);
-
 int __init tegra114_cpuidle_init(void)
 {
-	int ret;
-	unsigned int cpu;
-	struct cpuidle_device *dev;
-	struct cpuidle_driver *drv = &tegra_idle_driver;
-
-	ret = cpuidle_register_driver(&tegra_idle_driver);
-	if (ret) {
-		pr_err("CPUidle driver registration failed\n");
-		return ret;
-	}
-
-	for_each_possible_cpu(cpu) {
-		dev = &per_cpu(tegra_idle_device, cpu);
-		dev->cpu = cpu;
-
-		ret = cpuidle_register_device(dev);
-		if (ret) {
-			pr_err("CPU%u: CPUidle device registration failed\n",
-				cpu);
-			return ret;
-		}
-	}
-	return 0;
+	return cpuidle_register(&tegra_idle_driver, NULL);
 }
-- 
1.7.9.5



From daniel.lezcano at linaro.org  Wed Apr 10 10:22:16 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Wed, 10 Apr 2013 16:22:16 +0200
Subject: [PATCH 11/18] ARM: shmobile: cpuidle: use init/exit common routine
In-Reply-To: <1365603743-5618-1-git-send-email-daniel.lezcano@linaro.org>
References: <1365603743-5618-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1365603743-5618-12-git-send-email-daniel.lezcano@linaro.org>

Remove the duplicated code and use the cpuidle common code for initialization.

Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
---
 arch/arm/mach-shmobile/cpuidle.c |   10 +---------
 1 file changed, 1 insertion(+), 9 deletions(-)

diff --git a/arch/arm/mach-shmobile/cpuidle.c b/arch/arm/mach-shmobile/cpuidle.c
index d671ae9..0afeb5c 100644
--- a/arch/arm/mach-shmobile/cpuidle.c
+++ b/arch/arm/mach-shmobile/cpuidle.c
@@ -16,7 +16,6 @@
 #include <asm/cpuidle.h>
 #include <asm/io.h>
 
-static struct cpuidle_device shmobile_cpuidle_dev;
 static struct cpuidle_driver shmobile_cpuidle_default_driver = {
 	.name			= "shmobile_cpuidle",
 	.owner			= THIS_MODULE,
@@ -34,12 +33,5 @@ void __init shmobile_cpuidle_set_driver(struct cpuidle_driver *drv)
 
 int __init shmobile_cpuidle_init(void)
 {
-	struct cpuidle_device *dev = &shmobile_cpuidle_dev;
-
-	cpuidle_register_driver(cpuidle_drv);
-
-	dev->state_count = cpuidle_drv->state_count;
-	cpuidle_register_device(dev);
-
-	return 0;
+	return cpuidle_register(cpuidle_drv, NULL);
 }
-- 
1.7.9.5



From daniel.lezcano at linaro.org  Wed Apr 10 10:22:20 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Wed, 10 Apr 2013 16:22:20 +0200
Subject: [PATCH 15/18] ARM: calxeda: cpuidle: use init/exit common routine
In-Reply-To: <1365603743-5618-1-git-send-email-daniel.lezcano@linaro.org>
References: <1365603743-5618-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1365603743-5618-16-git-send-email-daniel.lezcano@linaro.org>

Remove the duplicated code and use the cpuidle common code for initialization.

Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
---
 drivers/cpuidle/cpuidle-calxeda.c |   52 +------------------------------------
 1 file changed, 1 insertion(+), 51 deletions(-)

diff --git a/drivers/cpuidle/cpuidle-calxeda.c b/drivers/cpuidle/cpuidle-calxeda.c
index a3b56f5..e344b56 100644
--- a/drivers/cpuidle/cpuidle-calxeda.c
+++ b/drivers/cpuidle/cpuidle-calxeda.c
@@ -35,8 +35,6 @@
 extern void highbank_set_cpu_jump(int cpu, void *jump_addr);
 extern void *scu_base_addr;
 
-static struct cpuidle_device __percpu *calxeda_idle_cpuidle_devices;
-
 static inline unsigned int get_auxcr(void)
 {
 	unsigned int val;
@@ -85,19 +83,6 @@ static int calxeda_pwrdown_idle(struct cpuidle_device *dev,
 	return index;
 }
 
-static void calxeda_idle_cpuidle_devices_uninit(void)
-{
-	int i;
-	struct cpuidle_device *dev;
-
-	for_each_possible_cpu(i) {
-		dev = per_cpu_ptr(calxeda_idle_cpuidle_devices, i);
-		cpuidle_unregister_device(dev);
-	}
-
-	free_percpu(calxeda_idle_cpuidle_devices);
-}
-
 static struct cpuidle_driver calxeda_idle_driver = {
 	.name = "calxeda_idle",
 	.states = {
@@ -117,44 +102,9 @@ static struct cpuidle_driver calxeda_idle_driver = {
 
 static int __init calxeda_cpuidle_init(void)
 {
-	int cpu_id;
-	int ret;
-	struct cpuidle_device *dev;
-	struct cpuidle_driver *drv = &calxeda_idle_driver;
-
 	if (!of_machine_is_compatible("calxeda,highbank"))
 		return -ENODEV;
 
-	ret = cpuidle_register_driver(drv);
-	if (ret)
-		return ret;
-
-	calxeda_idle_cpuidle_devices = alloc_percpu(struct cpuidle_device);
-	if (calxeda_idle_cpuidle_devices == NULL) {
-		ret = -ENOMEM;
-		goto unregister_drv;
-	}
-
-	/* initialize state data for each cpuidle_device */
-	for_each_possible_cpu(cpu_id) {
-		dev = per_cpu_ptr(calxeda_idle_cpuidle_devices, cpu_id);
-		dev->cpu = cpu_id;
-		dev->state_count = drv->state_count;
-
-		ret = cpuidle_register_device(dev);
-		if (ret) {
-			pr_err("Failed to register cpu %u, error: %d\n",
-			       cpu_id, ret);
-			goto uninit;
-		}
-	}
-
-	return 0;
-
-uninit:
-	calxeda_idle_cpuidle_devices_uninit();
-unregister_drv:
-	cpuidle_unregister_driver(drv);
-	return ret;
+	return cpuidle_register(&calxeda_idle_driver, NULL);
 }
 module_init(calxeda_cpuidle_init);
-- 
1.7.9.5



From daniel.lezcano at linaro.org  Wed Apr 10 10:22:19 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Wed, 10 Apr 2013 16:22:19 +0200
Subject: [PATCH 14/18] ARM: tegra3: cpuidle: use init/exit common routine
In-Reply-To: <1365603743-5618-1-git-send-email-daniel.lezcano@linaro.org>
References: <1365603743-5618-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1365603743-5618-15-git-send-email-daniel.lezcano@linaro.org>

Remove the duplicated code and use the cpuidle common code for initialization.

Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
---
 arch/arm/mach-tegra/cpuidle-tegra30.c |   27 +--------------------------
 1 file changed, 1 insertion(+), 26 deletions(-)

diff --git a/arch/arm/mach-tegra/cpuidle-tegra30.c b/arch/arm/mach-tegra/cpuidle-tegra30.c
index f6a0c72..36dc2be 100644
--- a/arch/arm/mach-tegra/cpuidle-tegra30.c
+++ b/arch/arm/mach-tegra/cpuidle-tegra30.c
@@ -64,8 +64,6 @@ static struct cpuidle_driver tegra_idle_driver = {
 	},
 };
 
-static DEFINE_PER_CPU(struct cpuidle_device, tegra_idle_device);
-
 #ifdef CONFIG_PM_SLEEP
 static bool tegra30_cpu_cluster_power_down(struct cpuidle_device *dev,
 					   struct cpuidle_driver *drv,
@@ -156,31 +154,8 @@ static int tegra30_idle_lp2(struct cpuidle_device *dev,
 
 int __init tegra30_cpuidle_init(void)
 {
-	int ret;
-	unsigned int cpu;
-	struct cpuidle_device *dev;
-	struct cpuidle_driver *drv = &tegra_idle_driver;
-
 #ifdef CONFIG_PM_SLEEP
 	tegra_tear_down_cpu = tegra30_tear_down_cpu;
 #endif
-
-	ret = cpuidle_register_driver(&tegra_idle_driver);
-	if (ret) {
-		pr_err("CPUidle driver registration failed\n");
-		return ret;
-	}
-
-	for_each_possible_cpu(cpu) {
-		dev = &per_cpu(tegra_idle_device, cpu);
-		dev->cpu = cpu;
-
-		ret = cpuidle_register_device(dev);
-		if (ret) {
-			pr_err("CPU%u: CPUidle device registration failed\n",
-				cpu);
-			return ret;
-		}
-	}
-	return 0;
+	return cpuidle_register(&tegra_idle_driver, NULL);
 }
-- 
1.7.9.5



From daniel.lezcano at linaro.org  Wed Apr 10 10:22:22 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Wed, 10 Apr 2013 16:22:22 +0200
Subject: [PATCH 17/18] ARM: davinci: cpuidle: use init/exit common routine
In-Reply-To: <1365603743-5618-1-git-send-email-daniel.lezcano@linaro.org>
References: <1365603743-5618-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1365603743-5618-18-git-send-email-daniel.lezcano@linaro.org>

Remove the duplicated code and use the cpuidle common code for initialization.

Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
---
 arch/arm/mach-davinci/cpuidle.c |   20 +-------------------
 1 file changed, 1 insertion(+), 19 deletions(-)

diff --git a/arch/arm/mach-davinci/cpuidle.c b/arch/arm/mach-davinci/cpuidle.c
index c2887c5..36aef3a 100644
--- a/arch/arm/mach-davinci/cpuidle.c
+++ b/arch/arm/mach-davinci/cpuidle.c
@@ -25,7 +25,6 @@
 
 #define DAVINCI_CPUIDLE_MAX_STATES	2
 
-static DEFINE_PER_CPU(struct cpuidle_device, davinci_cpuidle_device);
 static void __iomem *ddr2_reg_base;
 static bool ddr2_pdown;
 
@@ -76,12 +75,8 @@ static struct cpuidle_driver davinci_idle_driver = {
 
 static int __init davinci_cpuidle_probe(struct platform_device *pdev)
 {
-	int ret;
-	struct cpuidle_device *device;
 	struct davinci_cpuidle_config *pdata = pdev->dev.platform_data;
 
-	device = &per_cpu(davinci_cpuidle_device, smp_processor_id());
-
 	if (!pdata) {
 		dev_err(&pdev->dev, "cannot get platform data\n");
 		return -ENOENT;
@@ -91,20 +86,7 @@ static int __init davinci_cpuidle_probe(struct platform_device *pdev)
 
 	ddr2_pdown = pdata->ddr2_pdown;
 
-	ret = cpuidle_register_driver(&davinci_idle_driver);
-	if (ret) {
-		dev_err(&pdev->dev, "failed to register driver\n");
-		return ret;
-	}
-
-	ret = cpuidle_register_device(device);
-	if (ret) {
-		dev_err(&pdev->dev, "failed to register device\n");
-		cpuidle_unregister_driver(&davinci_idle_driver);
-		return ret;
-	}
-
-	return 0;
+	return cpuidle_register(&davinci_idle_driver, NULL);
 }
 
 static struct platform_driver davinci_cpuidle_driver = {
-- 
1.7.9.5



From daniel.lezcano at linaro.org  Wed Apr 10 10:22:21 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Wed, 10 Apr 2013 16:22:21 +0200
Subject: [PATCH 16/18] ARM: kirkwood: cpuidle: use init/exit common routine
In-Reply-To: <1365603743-5618-1-git-send-email-daniel.lezcano@linaro.org>
References: <1365603743-5618-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1365603743-5618-17-git-send-email-daniel.lezcano@linaro.org>

Remove the duplicated code and use the cpuidle common code for initialization.

Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
---
 drivers/cpuidle/cpuidle-kirkwood.c |   17 ++---------------
 1 file changed, 2 insertions(+), 15 deletions(-)

diff --git a/drivers/cpuidle/cpuidle-kirkwood.c b/drivers/cpuidle/cpuidle-kirkwood.c
index 6f31524..53290e1 100644
--- a/drivers/cpuidle/cpuidle-kirkwood.c
+++ b/drivers/cpuidle/cpuidle-kirkwood.c
@@ -52,9 +52,6 @@ static struct cpuidle_driver kirkwood_idle_driver = {
 	},
 	.state_count = KIRKWOOD_MAX_STATES,
 };
-static struct cpuidle_device *device;
-
-static DEFINE_PER_CPU(struct cpuidle_device, kirkwood_cpuidle_device);
 
 /* Initialize CPU idle by registering the idle states */
 static int kirkwood_cpuidle_probe(struct platform_device *pdev)
@@ -69,22 +66,12 @@ static int kirkwood_cpuidle_probe(struct platform_device *pdev)
 	if (IS_ERR(ddr_operation_base))
 		return PTR_ERR(ddr_operation_base);
 
-	device = &per_cpu(kirkwood_cpuidle_device, smp_processor_id());
-	device->state_count = KIRKWOOD_MAX_STATES;
-
-	cpuidle_register_driver(&kirkwood_idle_driver);
-	if (cpuidle_register_device(device)) {
-		pr_err("kirkwood_init_cpuidle: Failed registering\n");
-		return -EIO;
-	}
-	return 0;
+	return cpuidle_register(&kirkwood_idle_driver, NULL);
 }
 
 int kirkwood_cpuidle_remove(struct platform_device *pdev)
 {
-	cpuidle_unregister_device(device);
-	cpuidle_unregister_driver(&kirkwood_idle_driver);
-
+	cpuidle_unregister(&kirkwood_idle_driver);
 	return 0;
 }
 
-- 
1.7.9.5



From daniel.lezcano at linaro.org  Wed Apr 10 10:22:18 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Wed, 10 Apr 2013 16:22:18 +0200
Subject: [PATCH 13/18] ARM: tegra2: cpuidle: use init/exit common routine
In-Reply-To: <1365603743-5618-1-git-send-email-daniel.lezcano@linaro.org>
References: <1365603743-5618-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1365603743-5618-14-git-send-email-daniel.lezcano@linaro.org>

Remove the duplicated code and use the cpuidle common code for initialization.

Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
---
 arch/arm/mach-tegra/cpuidle-tegra20.c |   33 +--------------------------------
 1 file changed, 1 insertion(+), 32 deletions(-)

diff --git a/arch/arm/mach-tegra/cpuidle-tegra20.c b/arch/arm/mach-tegra/cpuidle-tegra20.c
index f1f6ac4..d6c2ba6 100644
--- a/arch/arm/mach-tegra/cpuidle-tegra20.c
+++ b/arch/arm/mach-tegra/cpuidle-tegra20.c
@@ -70,8 +70,6 @@ static struct cpuidle_driver tegra_idle_driver = {
 	.safe_state_index = 0,
 };
 
-static DEFINE_PER_CPU(struct cpuidle_device, tegra_idle_device);
-
 #ifdef CONFIG_PM_SLEEP
 #ifdef CONFIG_SMP
 static void __iomem *pmc = IO_ADDRESS(TEGRA_PMC_BASE);
@@ -220,34 +218,5 @@ static int tegra20_idle_lp2_coupled(struct cpuidle_device *dev,
 
 int __init tegra20_cpuidle_init(void)
 {
-	int ret;
-	unsigned int cpu;
-	struct cpuidle_device *dev;
-	struct cpuidle_driver *drv = &tegra_idle_driver;
-
-#ifdef CONFIG_PM_SLEEP
-	tegra_tear_down_cpu = tegra20_tear_down_cpu;
-#endif
-
-	ret = cpuidle_register_driver(&tegra_idle_driver);
-	if (ret) {
-		pr_err("CPUidle driver registration failed\n");
-		return ret;
-	}
-
-	for_each_possible_cpu(cpu) {
-		dev = &per_cpu(tegra_idle_device, cpu);
-		dev->cpu = cpu;
-#ifdef CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED
-		dev->coupled_cpus = *cpu_possible_mask;
-#endif
-
-		ret = cpuidle_register_device(dev);
-		if (ret) {
-			pr_err("CPU%u: CPUidle device registration failed\n",
-				cpu);
-			return ret;
-		}
-	}
-	return 0;
+	return cpuidle_register(&tegra_idle_driver, cpu_possible_mask);
 }
-- 
1.7.9.5



From daniel.lezcano at linaro.org  Wed Apr 10 10:22:23 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Wed, 10 Apr 2013 16:22:23 +0200
Subject: [PATCH 18/18] ARM: imx: cpuidle: use init/exit common routine
In-Reply-To: <1365603743-5618-1-git-send-email-daniel.lezcano@linaro.org>
References: <1365603743-5618-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1365603743-5618-19-git-send-email-daniel.lezcano@linaro.org>

Remove the duplicated code and use the cpuidle common code for initialization.

Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
---
 arch/arm/mach-imx/cpuidle-imx5.c  |   36 +-----------------------------------
 arch/arm/mach-imx/cpuidle-imx6q.c |   36 +-----------------------------------
 2 files changed, 2 insertions(+), 70 deletions(-)

diff --git a/arch/arm/mach-imx/cpuidle-imx5.c b/arch/arm/mach-imx/cpuidle-imx5.c
index 3d9f0c9..ba4565f 100644
--- a/arch/arm/mach-imx/cpuidle-imx5.c
+++ b/arch/arm/mach-imx/cpuidle-imx5.c
@@ -13,8 +13,6 @@
 
 #include "hardware.h"
 
-static DEFINE_PER_CPU(struct cpuidle_device, devices);
-
 static int imx5_cpuidle_enter(struct cpuidle_device *dev,
 			      struct cpuidle_driver *drv, int index)
 {
@@ -38,37 +36,5 @@ static struct cpuidle_driver imx5_cpuidle_driver = {
 
 int __init imx5_cpuidle_init(void)
 {
-	struct cpuidle_device *dev;
-	int cpu, ret;
-
-	ret = cpuidle_register_driver(&imx5_cpuidle_driver);
-	if (ret) {
-		pr_err("%s: Failed to register cpuidle driver with error: %d\n",
-			 __func__, ret);
-		return ret;
-	}
-
-	/* initialize state data for each cpuidle_device */
-	for_each_possible_cpu(cpu) {
-		dev = &per_cpu(devices, cpu);
-		dev->cpu = cpu;
-
-		ret = cpuidle_register_device(dev);
-		if (ret) {
-			pr_err("%s: Failed to register cpu %u, error: %d\n",
-				__func__, cpu, ret);
-			goto out_unregister;
-		}
-	}
-
-	return 0;
-
-out_unregister:
-	for_each_possible_cpu(cpu) {
-		dev = &per_cpu(devices, cpu);
-		cpuidle_unregister_device(dev);
-	}
-
-	cpuidle_unregister_driver(&imx5_cpuidle_driver);
-	return ret;
+	return cpuidle_register(&imx5_cpuidle_driver, NULL);
 }
diff --git a/arch/arm/mach-imx/cpuidle-imx6q.c b/arch/arm/mach-imx/cpuidle-imx6q.c
index c066b74faa..23ddfb6 100644
--- a/arch/arm/mach-imx/cpuidle-imx6q.c
+++ b/arch/arm/mach-imx/cpuidle-imx6q.c
@@ -14,8 +14,6 @@
 #include "common.h"
 #include "cpuidle.h"
 
-static DEFINE_PER_CPU(struct cpuidle_device, devices);
-
 static atomic_t master = ATOMIC_INIT(0);
 static DEFINE_SPINLOCK(master_lock);
 
@@ -67,43 +65,11 @@ static struct cpuidle_driver imx6q_cpuidle_driver = {
 
 int __init imx6q_cpuidle_init(void)
 {
-	struct cpuidle_device *dev;
-	int cpu, ret;
-
 	/* Need to enable SCU standby for entering WAIT modes */
 	imx_scu_standby_enable();
 
 	/* Set chicken bit to get a reliable WAIT mode support */
 	imx6q_set_chicken_bit();
 
-	ret = cpuidle_register_driver(&imx6q_cpuidle_driver);
-	if (ret) {
-		pr_err("%s: Failed to register cpuidle driver with error: %d\n",
-			 __func__, ret);
-		return ret;
-	}
-
-	/* initialize state data for each cpuidle_device */
-	for_each_possible_cpu(cpu) {
-		dev = &per_cpu(devices, cpu);
-		dev->cpu = cpu;
-
-		ret = cpuidle_register_device(dev);
-		if (ret) {
-			pr_err("%s: Failed to register cpu %u, error: %d\n",
-				__func__, cpu, ret);
-			goto out_unregister;
-		}
-	}
-
-	return 0;
-
-out_unregister:
-	for_each_possible_cpu(cpu) {
-		dev = &per_cpu(devices, cpu);
-		cpuidle_unregister_device(dev);
-	}
-
-	cpuidle_unregister_driver(&imx6q_cpuidle_driver);
-	return ret;
+	return cpuidle_register(&imx6q_cpuidle_driver, NULL);
 }
-- 
1.7.9.5



From daniel.lezcano at linaro.org  Wed Apr 10 10:22:17 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Wed, 10 Apr 2013 16:22:17 +0200
Subject: [PATCH 12/18] ARM: OMAP4: cpuidle: use init/exit common routine
In-Reply-To: <1365603743-5618-1-git-send-email-daniel.lezcano@linaro.org>
References: <1365603743-5618-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1365603743-5618-13-git-send-email-daniel.lezcano@linaro.org>

Remove the duplicated code and use the cpuidle common code for initialization.

Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
---
 arch/arm/mach-omap2/cpuidle44xx.c |   22 ++--------------------
 1 file changed, 2 insertions(+), 20 deletions(-)

diff --git a/arch/arm/mach-omap2/cpuidle44xx.c b/arch/arm/mach-omap2/cpuidle44xx.c
index cd188de..861dd90 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -15,6 +15,7 @@
 #include <linux/cpu_pm.h>
 #include <linux/export.h>
 
+#include <asm/cpuidle.h>
 #include <asm/proc-fns.h>
 
 #include "common.h"
@@ -157,8 +158,6 @@ fail:
 	return index;
 }
 
-static DEFINE_PER_CPU(struct cpuidle_device, omap4_idle_dev);
-
 static struct cpuidle_driver omap4_idle_driver = {
 	.name				= "omap4_idle",
 	.owner				= THIS_MODULE,
@@ -207,9 +206,6 @@ static struct cpuidle_driver omap4_idle_driver = {
  */
 int __init omap4_idle_init(void)
 {
-	struct cpuidle_device *dev;
-	unsigned int cpu_id = 0;
-
 	mpu_pd = pwrdm_lookup("mpu_pwrdm");
 	cpu_pd[0] = pwrdm_lookup("cpu0_pwrdm");
 	cpu_pd[1] = pwrdm_lookup("cpu1_pwrdm");
@@ -221,19 +217,5 @@ int __init omap4_idle_init(void)
 	if (!cpu_clkdm[0] || !cpu_clkdm[1])
 		return -ENODEV;
 
-	for_each_cpu(cpu_id, cpu_online_mask) {
-		dev = &per_cpu(omap4_idle_dev, cpu_id);
-		dev->cpu = cpu_id;
-#ifdef CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED
-		dev->coupled_cpus = *cpu_online_mask;
-#endif
-		cpuidle_register_driver(&omap4_idle_driver);
-
-		if (cpuidle_register_device(dev)) {
-			pr_err("%s: CPUidle register failed\n", __func__);
-			return -EIO;
-		}
-	}
-
-	return 0;
+	return cpuidle_register(&omap4_idle_driver, cpu_online_mask);
 }
-- 
1.7.9.5



From robherring2 at gmail.com  Wed Apr 10 10:31:27 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Wed, 10 Apr 2013 09:31:27 -0500
Subject: [PATCH 15/18] ARM: calxeda: cpuidle: use init/exit common routine
In-Reply-To: <1365603743-5618-16-git-send-email-daniel.lezcano@linaro.org>
References: <1365603743-5618-1-git-send-email-daniel.lezcano@linaro.org>
 <1365603743-5618-16-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <516577BF.1010809@gmail.com>

On 04/10/2013 09:22 AM, Daniel Lezcano wrote:
> Remove the duplicated code and use the cpuidle common code for initialization.
> 
> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
> ---
>  drivers/cpuidle/cpuidle-calxeda.c |   52 +------------------------------------
>  1 file changed, 1 insertion(+), 51 deletions(-)

For this and patch #5:

Acked-by: Rob Herring <rob.herring at calxeda.com>

Rob

> 
> diff --git a/drivers/cpuidle/cpuidle-calxeda.c b/drivers/cpuidle/cpuidle-calxeda.c
> index a3b56f5..e344b56 100644
> --- a/drivers/cpuidle/cpuidle-calxeda.c
> +++ b/drivers/cpuidle/cpuidle-calxeda.c
> @@ -35,8 +35,6 @@
>  extern void highbank_set_cpu_jump(int cpu, void *jump_addr);
>  extern void *scu_base_addr;
>  
> -static struct cpuidle_device __percpu *calxeda_idle_cpuidle_devices;
> -
>  static inline unsigned int get_auxcr(void)
>  {
>  	unsigned int val;
> @@ -85,19 +83,6 @@ static int calxeda_pwrdown_idle(struct cpuidle_device *dev,
>  	return index;
>  }
>  
> -static void calxeda_idle_cpuidle_devices_uninit(void)
> -{
> -	int i;
> -	struct cpuidle_device *dev;
> -
> -	for_each_possible_cpu(i) {
> -		dev = per_cpu_ptr(calxeda_idle_cpuidle_devices, i);
> -		cpuidle_unregister_device(dev);
> -	}
> -
> -	free_percpu(calxeda_idle_cpuidle_devices);
> -}
> -
>  static struct cpuidle_driver calxeda_idle_driver = {
>  	.name = "calxeda_idle",
>  	.states = {
> @@ -117,44 +102,9 @@ static struct cpuidle_driver calxeda_idle_driver = {
>  
>  static int __init calxeda_cpuidle_init(void)
>  {
> -	int cpu_id;
> -	int ret;
> -	struct cpuidle_device *dev;
> -	struct cpuidle_driver *drv = &calxeda_idle_driver;
> -
>  	if (!of_machine_is_compatible("calxeda,highbank"))
>  		return -ENODEV;
>  
> -	ret = cpuidle_register_driver(drv);
> -	if (ret)
> -		return ret;
> -
> -	calxeda_idle_cpuidle_devices = alloc_percpu(struct cpuidle_device);
> -	if (calxeda_idle_cpuidle_devices == NULL) {
> -		ret = -ENOMEM;
> -		goto unregister_drv;
> -	}
> -
> -	/* initialize state data for each cpuidle_device */
> -	for_each_possible_cpu(cpu_id) {
> -		dev = per_cpu_ptr(calxeda_idle_cpuidle_devices, cpu_id);
> -		dev->cpu = cpu_id;
> -		dev->state_count = drv->state_count;
> -
> -		ret = cpuidle_register_device(dev);
> -		if (ret) {
> -			pr_err("Failed to register cpu %u, error: %d\n",
> -			       cpu_id, ret);
> -			goto uninit;
> -		}
> -	}
> -
> -	return 0;
> -
> -uninit:
> -	calxeda_idle_cpuidle_devices_uninit();
> -unregister_drv:
> -	cpuidle_unregister_driver(drv);
> -	return ret;
> +	return cpuidle_register(&calxeda_idle_driver, NULL);
>  }
>  module_init(calxeda_cpuidle_init);
> 



From nicolas.ferre at atmel.com  Wed Apr 10 10:39:13 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Wed, 10 Apr 2013 16:39:13 +0200
Subject: [PATCH 07/18] ARM: at91: cpuidle: use init/exit common routine
In-Reply-To: <1365603743-5618-8-git-send-email-daniel.lezcano@linaro.org>
References: <1365603743-5618-1-git-send-email-daniel.lezcano@linaro.org>
 <1365603743-5618-8-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <51657991.5010205@atmel.com>

On 04/10/2013 04:22 PM, Daniel Lezcano :
> Remove the duplicate code and use the arm cpuidle driver's common code
> for initialization.
> 
> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>

Seems okay:

Acked-by: Nicolas Ferre <nicolas.ferre at atmel.com>


> ---
>  arch/arm/mach-at91/cpuidle.c |   17 ++---------------
>  1 file changed, 2 insertions(+), 15 deletions(-)
> 
> diff --git a/arch/arm/mach-at91/cpuidle.c b/arch/arm/mach-at91/cpuidle.c
> index 0130df7..48f1228 100644
> --- a/arch/arm/mach-at91/cpuidle.c
> +++ b/arch/arm/mach-at91/cpuidle.c
> @@ -27,8 +27,6 @@
>  
>  #define AT91_MAX_STATES	2
>  
> -static DEFINE_PER_CPU(struct cpuidle_device, at91_cpuidle_device);
> -
>  /* Actual code that puts the SoC in different idle states */
>  static int at91_enter_idle(struct cpuidle_device *dev,
>  			struct cpuidle_driver *drv,
> @@ -60,20 +58,9 @@ static struct cpuidle_driver at91_idle_driver = {
>  };
>  
>  /* Initialize CPU idle by registering the idle states */
> -static int at91_init_cpuidle(void)
> +static int __init at91_init_cpuidle(void)
>  {
> -	struct cpuidle_device *device;
> -
> -	device = &per_cpu(at91_cpuidle_device, smp_processor_id());
> -	device->state_count = AT91_MAX_STATES;
> -
> -	cpuidle_register_driver(&at91_idle_driver);
> -
> -	if (cpuidle_register_device(device)) {
> -		printk(KERN_ERR "at91_init_cpuidle: Failed registering\n");
> -		return -EIO;
> -	}
> -	return 0;
> +	return cpuidle_register(&at91_idle_driver, NULL);
>  }
>  
>  device_initcall(at91_init_cpuidle);
> 


-- 
Nicolas Ferre


From ulf.hansson at stericsson.com  Wed Apr 10 10:45:25 2013
From: ulf.hansson at stericsson.com (Ulf Hansson)
Date: Wed, 10 Apr 2013 16:45:25 +0200
Subject: [PATCH] PM / Runtime: Idle devices asynchronously after probe|release
Message-ID: <1365605125-27538-1-git-send-email-ulf.hansson@stericsson.com>

From: Ulf Hansson <ulf.hansson at linaro.org>

Putting devices into idle|suspend in a synchronous manner means we are
waiting for each device to become idle|suspended before the probe|release
is fully done.

This patch switch to use the asynchronous runtime PM API:s instead and
thus improves the parallelism since we can move on and handle the next
device in queue in an earlier phase.

Signed-off-by: Ulf Hansson <ulf.hansson at linaro.org>
Cc: Kevin Hilman <khilman at linaro.org>
Cc: Alan Stern <stern at rowland.harvard.edu>
Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
---
 drivers/base/dd.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index bb5645e..35fa368 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -380,7 +380,7 @@ int driver_probe_device(struct device_driver *drv, struct device *dev)
 
 	pm_runtime_barrier(dev);
 	ret = really_probe(dev, drv);
-	pm_runtime_idle(dev);
+	pm_request_idle(dev);
 
 	return ret;
 }
@@ -428,7 +428,7 @@ int device_attach(struct device *dev)
 		}
 	} else {
 		ret = bus_for_each_drv(dev->bus, NULL, dev, __device_attach);
-		pm_runtime_idle(dev);
+		pm_request_idle(dev);
 	}
 out_unlock:
 	device_unlock(dev);
@@ -499,7 +499,7 @@ static void __device_release_driver(struct device *dev)
 						     BUS_NOTIFY_UNBIND_DRIVER,
 						     dev);
 
-		pm_runtime_put_sync(dev);
+		pm_runtime_put(dev);
 
 		if (dev->bus && dev->bus->remove)
 			dev->bus->remove(dev);
-- 
1.7.10



From michal.bachraty at streamunlimited.com  Wed Apr 10 10:48:25 2013
From: michal.bachraty at streamunlimited.com (Michal Bachraty)
Date: Wed, 10 Apr 2013 16:48:25 +0200
Subject: [PATCH v7] clk: add si5351 i2c common clock driver
In-Reply-To: <51653C3E.2020702@gmail.com>
References: <1365439617-18816-1-git-send-email-sebastian.hesselbarth@gmail.com>
 <1365586810-6752-1-git-send-email-sebastian.hesselbarth@gmail.com>
 <51653C3E.2020702@gmail.com>
Message-ID: <14854575.YAd2OMKOy9@ganymedes>

Hi Sebastian,
This driver doesn't work for me. In my case, u-boot initializes si-5351 and 
power down unused clocks while booting kernel.  there is need for power up 
clocks as was in previous versions of your driver.  
See patch, whre the problem is fixed:

@@ -992,6 +992,10 @@ static long si5351_clkout_round_rate(struct clk_hw *hw, 
unsigned long rate,
 		} while (1);
 	}
 	rate = *parent_rate >> rdiv;
+	
+	/* powerup clkout */
+	si5351_set_bits(hwdata->drvdata, SI5351_CLK0_CTRL + hwdata->num,
+			SI5351_CLK_POWERDOWN, 0);
 
 	dev_dbg(&hwdata->drvdata->client->dev,
 		"%s - %s: rdiv = %u, parent_rate = %lu, rate = %lu\n",

With this lines, driver works well.

Also, 

> > +==Example==
> > +
> > +/* 25MHz reference crystal */
> > +ref25: ref25M {
> > +	compatible = "fixed-clock";
> > +	#clock-cells = <0>;
> > +	clock-frequency = <25000000>;
> > +};
> > +
> > +i2c-master-node {
> > +
> > +	/* Si5351a msop10 i2c clock generator */
> > +	si5351a: clock-generator at 60 {
> > +		compatible = "silabs,si5351a-msop";
> > +		reg = <0x60>;
> > +		#address-cells = <1>;
> > +		#size-cells = <0>;
> > +		#clock-cells = <1>;
> > +
> > +		/* connect xtal input to 25MHz reference */
> > +		clocks = <&ref25>;
> > +
> > +		/* connect xtal input as source of pll0 and pll1 */
> > +		silabs,pll-source = <0 0>, <1 0>;
> > +
> > +		/*
> > +		 * overwrite clkout0 configuration with:
> > +		 * - 8mA output drive strength
> > +		 * - pll0 as clock source of multisynth0
> > +		 * - multisynth0 as clock source of output divider
> > +		 * - multisynth0 can change pll0
> > +		 * - set initial clock frequency of 74.25MHz
> > +		 */
> > +		clkout0 {
> > +			reg = <0>;
> > +			silabs,drive-strength = <8>;
> > +			silabs,multisynth-source = <0>;
> > +			silabs,clock-source = <0>;
> > +			silabs,pll-master;
> > +			clock-frequency = <74250000>;
> > +		};
> > +
> > +		/*
> > +		 * overwrite clkout1 configuration with:
> > +		 * - 4mA output drive strength
> > +		 * - pll1 as clock source of multisynth1
> > +		 * - multisynth1 as clock source of output divider
> > +		 * - multisynth1 can change pll1
> > +		 */
> > +		clkout1 {
> > +			reg = <1>;
> > +			silabs,drive-strength = <4>;
> > +			silabs,multisynth-source = <1>;
> > +			silabs,clock-source = <0>;
> > +			pll-master;
> > +		};
> > +
 Is definition of pll-master in clkout1 correct? should not be silabs,pll-
master ?

Best regards,
Michal


From hechtb at gmail.com  Wed Apr 10 10:49:47 2013
From: hechtb at gmail.com (Bastian Hecht)
Date: Wed, 10 Apr 2013 16:49:47 +0200
Subject: v7_flush_kern_cache_louis flushes up to L2?
In-Reply-To: <51656A89.9090600@arm.com>
References: <CABYn4sxUCoWhC_4qydzbCtZdQdetqFZ_u5WtXsghprQget9f5g@mail.gmail.com>
 <51655248.7000401@arm.com>
 <CABYn4swK_FB+nPO4vKZM8khp+mjaPwkAv_GF+XDg5SYz0VLf0Q@mail.gmail.com>
 <51656A89.9090600@arm.com>
Message-ID: <CABYn4sxWPXhR7sdCDvnh5NAkpjmFJs4PfZdKizGKgaADbgvLcA@mail.gmail.com>

Heyho!

2013/4/10 Jonathan Austin <jonathan.austin at arm.com>:
> Hi again Bastian,
>
> On 10/04/13 13:16, Bastian Hecht wrote:
> [...]
>
>>>> This flushes the data out up to the L2, right? The ARM docs say that
>>>> the Point of Unification would be my L2. I'm a bit confused by the
>>>> term "Level of Unification Inner Shareable" (that states that in an
>>>> SMP system L1 coherency is guaranteed and all is flushed to the L2?).
>>>>
>>>
>>> As you say, for the A9 (from the TRM) the CLIDR reports LoUIS is the same
>>> as
>>> LoUU and both specify L2.
>>
>>
>> Ok, this is the golden info I was looking for. So after cpu_suspend()
>> I am good with the following sequence?
>> flush L2 (outer_flush_all)
>> disable L2 (outer_disable)
>> Clear the SCTLR.C bit and issue an "isb"
>> flush L1 (v7_flush_dcache_all)
>
>
> This looks good but I think there's a minor modification to be made to the
> sequence here:
>
> After you turn of the caches with the SCTLR.C bit, you can no longer hit in
> the L1 cache:
> SCTLR.C = 0:
> "The Cortex-A9 L1 Data Cache is not enabled. All memory accesses to Normal
> Memory Cacheable regions are treated as Normal Memory Non-Cacheable, without
> lookup and without allocation in the L1 Data Cache."
>
> If you had dirty data in the L1 cache you will lose it at that point.
>
> So, you should flush L1 before turning off caches.

Hmm, I wondered if I need that as cpu_suspend flushes all out to the
L2 as we discussed. So if I don't write anything to RAM after
cpu_suspend why do I need the extra flush before turning off
L1-caching?

> Note that on SMP, you would also need to clean/flush again after turning off
> the caches, as read-speculation could have sucked dirty data from another
> cache in to your cache, which would need to be written back before sleeping.
>

Aaaaaah, thanks! I always wondered why this is needed, but that makes sense.

>> cpu_do_idle
>>
>> and for resume:
>> invalidate L1
>
>
> How do you plan to do this? I notice that there's an increasing tendency to
> call v7_invalidate_l1 which isn't actually part of the cacheflush API (see
> arch/arm/include/asm/cacheflush.h arch/arm/include/asm/glue-cache.h...)

I used to have my gazillionth version of v7_invalidate_l1 in my
assembly code but as it is in cache-v7.S now, I use this.

> Does your cache definitely come up in an undefined state? If not, could you
> use v7_flush_dcache_all? (see the comment above v7_invalidate_l1 in
> arch/arm/mm/cache-v7.S)

To be honest, I have no clue if my cache comes up in an undefined
state. But the comment about random data getting flushed to RAM scared
me so much that I blindly go with what other Cortex A9 users do.

> Hope that helps,

It does!

Thanks,

 Bastian


From dianders at chromium.org  Wed Apr 10 10:55:25 2013
From: dianders at chromium.org (Doug Anderson)
Date: Wed, 10 Apr 2013 07:55:25 -0700
Subject: [PATCH v4] mmc: dw_mmc: let device core setup the default pin
 configuration
In-Reply-To: <CAD=FV=UddWM=yc5N9=jwbMDpZ7Bpg7o3Z714CnBSg=iHhmPxWw@mail.gmail.com>
References: <1365487186-4587-1-git-send-email-thomas.abraham@linaro.org>
 <CAD=FV=VJ-ykDNqYKQ=fqxeOD6bRNLW02VT4bjsRHRAuXLcCpQQ@mail.gmail.com>
 <CAJuYYwQT=povqiutVHXkF5jxTAnjpwTMQ5G0Z6xKGnnM7qYADQ@mail.gmail.com>
 <CAD=FV=UddWM=yc5N9=jwbMDpZ7Bpg7o3Z714CnBSg=iHhmPxWw@mail.gmail.com>
Message-ID: <CAD=FV=WyPbkYvq9udPzQtVnaXZR3jzXTPnBrrdxpUuX3CZT=Og@mail.gmail.com>

Thomas,

On Wed, Apr 10, 2013 at 6:56 AM, Doug Anderson <dianders at chromium.org> wrote:
> On Wed, Apr 10, 2013 at 5:48 AM, Thomas Abraham
> <thomas.abraham at linaro.org> wrote:
>> The call to regulator_enable() is prior to the call to mmc_add_host().
>> Hence, call to mmc_fre_host is not required in this case. So the above
>> change should be right.
>
> Are you sure that mmc_free_host() is the opposite of mmc_add_host()
> and not mmc_alloc_host()?
>
> I'll double-check myself in a few hours when I'm in front of a computer.

OK, I double checked and I'm still convinced that the free is needed
because we've already called mmc_alloc_host().  Current code always
makes sure to free when it returns an error and that seems right to
me.

-Doug


From robherring2 at gmail.com  Wed Apr 10 10:59:45 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Wed, 10 Apr 2013 09:59:45 -0500
Subject: [PATCH 05/18] cpuidle: make a single register function for all
In-Reply-To: <1365603743-5618-6-git-send-email-daniel.lezcano@linaro.org>
References: <1365603743-5618-1-git-send-email-daniel.lezcano@linaro.org>
 <1365603743-5618-6-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <51657E61.9010701@gmail.com>

On 04/10/2013 09:22 AM, Daniel Lezcano wrote:
> The usual scheme to initialize a cpuidle driver on a SMP is:
> 
> 	cpuidle_register_driver(drv);
> 	for_each_possible_cpu(cpu) {
> 		device = &per_cpu(cpuidle_dev, cpu);
> 		cpuidle_register_device(device);
> 	}
> 
> This code is duplicated in each cpuidle driver.
> 
> On UP systems, it is done this way:
> 
> 	cpuidle_register_driver(drv);
> 	device = &per_cpu(cpuidle_dev, cpu);
> 	cpuidle_register_device(device);
> 
> On UP, the macro 'for_each_cpu' does one iteration:
> 
> #define for_each_cpu(cpu, mask)                 \
>         for ((cpu) = 0; (cpu) < 1; (cpu)++, (void)mask)
> 
> Hence, the initialization loop is the same for UP than SMP.
> 
> Beside, we saw different bugs / mis-initialization / return code unchecked in
> the different drivers, the code is duplicated including bugs. After fixing all
> these ones, it appears the initialization pattern is the same for everyone.
> 
> Let's add a wrapper function doing this initialization with a cpumask parameter
> for the coupled idle states and use it for all the drivers.
> 
> That will save a lot of LOC, consolidate the code, and the modifications in the
> future could be done in a single place. Another benefit is the consolidation of
> the cpuidle_device variable which is now in the cpuidle framework and no longer
> spread accross the different arch specific drivers.
> 
> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
> ---

Perhaps my ack was too quick...

> +int cpuidle_register(struct cpuidle_driver *drv,
> +		     const struct cpumask *const coupled_cpus)
> +{
> +	int ret, cpu;
> +	struct cpuidle_device *device;
> +
> +	ret = cpuidle_register_driver(drv);
> +	if (ret) {
> +		printk(KERN_ERR "failed to register cpuidle driver\n");
> +		return ret;
> +	}
> +
> +	for_each_possible_cpu(cpu) {
> +		device = &per_cpu(cpuidle_dev, cpu);
> +		device->cpu = cpu;
> +#ifdef CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED
> +		device->coupled_cpus = *coupled_cpus;

This needs a NULL check. CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED is most
likely going to be enabled with multi-platform kernels and this will crash.

Also, I think typically struct copies have a note that it is copy.

Rob



From ulf.hansson at stericsson.com  Wed Apr 10 11:00:48 2013
From: ulf.hansson at stericsson.com (Ulf Hansson)
Date: Wed, 10 Apr 2013 17:00:48 +0200
Subject: [RESEND PATCH] PM / Runtime: Idle devices asynchronously after
 probe|release
Message-ID: <1365606048-27603-1-git-send-email-ulf.hansson@stericsson.com>

From: Ulf Hansson <ulf.hansson at linaro.org>

Putting devices into idle|suspend in a synchronous manner means we are
waiting for each device to become idle|suspended before the probe|release
is fully done.

This patch switch to use the asynchronous runtime PM API:s instead and
thus improves the parallelism since we can move on and handle the next
device in queue in an earlier phase.

Signed-off-by: Ulf Hansson <ulf.hansson at linaro.org>
Cc: Kevin Hilman <khilman at linaro.org>
Cc: Alan Stern <stern at rowland.harvard.edu>
Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
---
 drivers/base/dd.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index bb5645e..35fa368 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -380,7 +380,7 @@ int driver_probe_device(struct device_driver *drv, struct device *dev)
 
 	pm_runtime_barrier(dev);
 	ret = really_probe(dev, drv);
-	pm_runtime_idle(dev);
+	pm_request_idle(dev);
 
 	return ret;
 }
@@ -428,7 +428,7 @@ int device_attach(struct device *dev)
 		}
 	} else {
 		ret = bus_for_each_drv(dev->bus, NULL, dev, __device_attach);
-		pm_runtime_idle(dev);
+		pm_request_idle(dev);
 	}
 out_unlock:
 	device_unlock(dev);
@@ -499,7 +499,7 @@ static void __device_release_driver(struct device *dev)
 						     BUS_NOTIFY_UNBIND_DRIVER,
 						     dev);
 
-		pm_runtime_put_sync(dev);
+		pm_runtime_put(dev);
 
 		if (dev->bus && dev->bus->remove)
 			dev->bus->remove(dev);
-- 
1.7.10



From daniel.lezcano at linaro.org  Wed Apr 10 11:05:21 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Wed, 10 Apr 2013 17:05:21 +0200
Subject: [PATCH 05/18] cpuidle: make a single register function for all
In-Reply-To: <51657E61.9010701@gmail.com>
References: <1365603743-5618-1-git-send-email-daniel.lezcano@linaro.org>
 <1365603743-5618-6-git-send-email-daniel.lezcano@linaro.org>
 <51657E61.9010701@gmail.com>
Message-ID: <51657FB1.6030209@linaro.org>

On 04/10/2013 04:59 PM, Rob Herring wrote:
> On 04/10/2013 09:22 AM, Daniel Lezcano wrote:
>> The usual scheme to initialize a cpuidle driver on a SMP is:
>>
>> 	cpuidle_register_driver(drv);
>> 	for_each_possible_cpu(cpu) {
>> 		device = &per_cpu(cpuidle_dev, cpu);
>> 		cpuidle_register_device(device);
>> 	}
>>
>> This code is duplicated in each cpuidle driver.
>>
>> On UP systems, it is done this way:
>>
>> 	cpuidle_register_driver(drv);
>> 	device = &per_cpu(cpuidle_dev, cpu);
>> 	cpuidle_register_device(device);
>>
>> On UP, the macro 'for_each_cpu' does one iteration:
>>
>> #define for_each_cpu(cpu, mask)                 \
>>         for ((cpu) = 0; (cpu) < 1; (cpu)++, (void)mask)
>>
>> Hence, the initialization loop is the same for UP than SMP.
>>
>> Beside, we saw different bugs / mis-initialization / return code unchecked in
>> the different drivers, the code is duplicated including bugs. After fixing all
>> these ones, it appears the initialization pattern is the same for everyone.
>>
>> Let's add a wrapper function doing this initialization with a cpumask parameter
>> for the coupled idle states and use it for all the drivers.
>>
>> That will save a lot of LOC, consolidate the code, and the modifications in the
>> future could be done in a single place. Another benefit is the consolidation of
>> the cpuidle_device variable which is now in the cpuidle framework and no longer
>> spread accross the different arch specific drivers.
>>
>> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
>> ---
> 
> Perhaps my ack was too quick...
> 
>> +int cpuidle_register(struct cpuidle_driver *drv,
>> +		     const struct cpumask *const coupled_cpus)
>> +{
>> +	int ret, cpu;
>> +	struct cpuidle_device *device;
>> +
>> +	ret = cpuidle_register_driver(drv);
>> +	if (ret) {
>> +		printk(KERN_ERR "failed to register cpuidle driver\n");
>> +		return ret;
>> +	}
>> +
>> +	for_each_possible_cpu(cpu) {
>> +		device = &per_cpu(cpuidle_dev, cpu);
>> +		device->cpu = cpu;
>> +#ifdef CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED
>> +		device->coupled_cpus = *coupled_cpus;
> 
> This needs a NULL check. CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED is most
> likely going to be enabled with multi-platform kernels and this will crash.

Good point, I will fix it.

> Also, I think typically struct copies have a note that it is copy.
> 
> Rob
> 


-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From hechtb at gmail.com  Wed Apr 10 11:08:25 2013
From: hechtb at gmail.com (Bastian Hecht)
Date: Wed, 10 Apr 2013 17:08:25 +0200
Subject: v7_flush_kern_cache_louis flushes up to L2?
In-Reply-To: <20130410135138.GA9210@e102568-lin.cambridge.arm.com>
References: <CABYn4sxUCoWhC_4qydzbCtZdQdetqFZ_u5WtXsghprQget9f5g@mail.gmail.com>
 <51655248.7000401@arm.com>
 <CABYn4swK_FB+nPO4vKZM8khp+mjaPwkAv_GF+XDg5SYz0VLf0Q@mail.gmail.com>
 <20130410135138.GA9210@e102568-lin.cambridge.arm.com>
Message-ID: <CABYn4sya=N7Hof7D_rmGJJtqjL5-27qnk39EUMRmRUB7_s+G5g@mail.gmail.com>

Hi Lorenzo,

2013/4/10 Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>:
> On Wed, Apr 10, 2013 at 01:16:03PM +0100, Bastian Hecht wrote:
>> Hi Jonny!
>>
>> 2013/4/10 Jonathan Austin <jonathan.austin at arm.com>:
>> > Hi Bastian,
>> >
>> >
>> > On 10/04/13 11:43, Bastian Hecht wrote:
>> >>
>> >> Hello,
>> >>
>> >> I've got a Cortex-A9 UP with a L2 and want to submit some PM code I've
>> >
>> >
>> > To clarify, is this an MPCore with a single core, or a genuine UP? This can
>> > be established from the 'U' bit of the MPIDR.
>> >
>>
>> I didn't actually read out the U bit, but I'm sure I've got no SCU, so
>> I bet high that it's a genuine UP system.
>>
>> >> written. Just to make sure I've made no mistake, it would be very
>> >> helpful if you can confirm a hypothesis I use in my code:
>> >>
>> >> v7_flush_kern_cache_louis: Flush the data cache up to Level of
>> >> Unification Inner Shareable
>> >>
>> >
>> > Depending on whether you're SMP or UP (bearing in mind that you can be SMP,
>> > but still only have one processor!) the IS is ignored in the
>> > v7_flush_dcache_louis operation:
>> > (from cache-v7.S)
>> >
>> >         mrc     p15, 1, r0, c0, c0, 1           @ read clidr, r0 = clidr
>> >         ALT_SMP(ands    r3, r0, #(7 << 21))     @ extract LoUIS from clidr
>> >         ALT_UP(ands     r3, r0, #(7 << 27))     @ extract LoUU from clidr
>> >         ALT_SMP(mov     r3, r3, lsr #20)        @ r3 = LoUIS * 2
>> >         ALT_UP(mov      r3, r3, lsr #26)        @ r3 = LoUU * 2
>> >         ...
>> >         flush levels based on value in r3
>> >
>> >
>> >> This flushes the data out up to the L2, right? The ARM docs say that
>> >> the Point of Unification would be my L2. I'm a bit confused by the
>> >> term "Level of Unification Inner Shareable" (that states that in an
>> >> SMP system L1 coherency is guaranteed and all is flushed to the L2?).
>> >>
>> >
>> > As you say, for the A9 (from the TRM) the CLIDR reports LoUIS is the same as
>> > LoUU and both specify L2.
>>
>> Ok, this is the golden info I was looking for. So after cpu_suspend()
>> I am good with the following sequence?
>
> Is L2 RAM retained on power down ?

I have two different versions of powering down the SoC. Currently I'm
focusing on a shutdown mode that contains the powering off of the L2.

>> flush L2 (outer_flush_all)
>> disable L2 (outer_disable)
>
> Disabling L2 is not mandatory. And the code above (if L2 RAM is not
> retained) can be simply
>
> outer_disable
>
> the cleaning is done in the PL310 disable function properly.

The problem I see with this approach is:
What advantage do we get at all if we have to flush the L2 (which is
done in the PL310 disable routine)? Isn't this exactly the part we
want to save? Not to have to flush the L2.

>> Clear the SCTLR.C bit and issue an "isb"
>> flush L1 (v7_flush_dcache_all)
>
> Two steps above are ok, as long as flush L1 does not push data on the
> stack on entry and L1 clean routine does not need any dirty data present
> in L1. Clearing C bit on A9 stops the core from searching the
> cache so data writes should not be executed with C bit cleared and a
> data cache still containing dirty lines. For the same reason the cache
> cleaning routine should not require any data to execute since the data
> can be sitting in the cache that is not searched anymore when the C bit
> is cleared.

Ah true! When I enter my assembly code there are of course stack modifications.
And here comes a point I've just realized recently: Sometimes the WFI
command doesn't enter the low power state mode I've requested. I
haven't observed this when using Suspend-To-Ram but when using
CPUIdle.
I've seen code from the OMAP people that check for the case that WFI
doesn't succeed. Probably I need to do the same. And for this I need
the stack to be synced.

> The sequence:
>
> clear C bit
> bl v7_flush_dcache_all
>
> is better coded in assembly (in the cpu_suspend finisher, ie the
> function you pass as cpu_suspend 2 argument) to control what you are doing.
>
> The cache cleaning routine (v7_flush_dcache_all) does not require any
> data to execute, so running it with C bit cleared is fine.
>
>> cpu_do_idle
>>
>> and for resume:
>> invalidate L1
>
> Use v7_invalidate_l1 here.
>
>> (trust cpu_resume to resume the L1 and enable the SCTLR.C bit)
>> resume L2 (outer_resume)
>
> Again, it depends on L2 behaviour on shutdown, if it is retained or not.
> If L2 RAM content is lost on power down the sequence above seems ok.
>
> Post the code, happy to have a look.
>

Ok great, I'm quite blown away by the support here, should have
contacted you earlier!

Bastian


From christian.ruppert at abilis.com  Wed Apr 10 11:40:43 2013
From: christian.ruppert at abilis.com (Christian Ruppert)
Date: Wed, 10 Apr 2013 17:40:43 +0200
Subject: [PATCH] clk: Add device tree binding to clk-fixed-factor
Message-ID: <1365608443-30350-1-git-send-email-christian.ruppert@abilis.com>

This patch adds a device tree binding for the simple fixed factor clock
divider/multiplier of the common clock tree binding.

Signed-off-by: Christian Ruppert <christian.ruppert at abilis.com>
---
 .../bindings/clock/fixed-factor-clkdiv.txt         |   24 +++++++++++++++
 drivers/clk/clk-fixed-factor.c                     |   32 ++++++++++++++++++++
 include/linux/clk-provider.h                       |    1 +
 3 files changed, 57 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/clock/fixed-factor-clkdiv.txt

diff --git a/Documentation/devicetree/bindings/clock/fixed-factor-clkdiv.txt b/Documentation/devicetree/bindings/clock/fixed-factor-clkdiv.txt
new file mode 100644
index 0000000..352bac4
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/fixed-factor-clkdiv.txt
@@ -0,0 +1,24 @@
+Device Tree Clock bindings for plat-tb10x
+
+This binding uses the common clock binding[1].
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties:
+- compatible : shall be "fixed-factor-clkdiv"
+- #clock-cells: from common clock binding; shall be set to 0
+- clocks: shall be the input parent clock phandle for the clock.
+- clock-mult: defines the multiplication factor of the output clock frequency
+  wrt. the input clock frequency.
+- clock-div: defines the division factor of the output clock frequency wrt.
+  the input clock frequency.
+
+Example:
+cpu_clk: clkdiv_cpu {	/* CPU clock derived from pll0. 1/2 of pll frequency */
+	compatible = "fixed-factor-clkdiv";
+	#clock-cells = <0>;
+	clocks = <&pll0>;
+	clock-mult = <1>;
+	clock-div = <2>;
+	clock-output-names = "cpu_clk";
+};
diff --git a/drivers/clk/clk-fixed-factor.c b/drivers/clk/clk-fixed-factor.c
index 1ef271e..85e45f1 100644
--- a/drivers/clk/clk-fixed-factor.c
+++ b/drivers/clk/clk-fixed-factor.c
@@ -11,6 +11,7 @@
 #include <linux/clk-provider.h>
 #include <linux/slab.h>
 #include <linux/err.h>
+#include <linux/of.h>
 
 /*
  * DOC: basic fixed multiplier and divider clock that cannot gate
@@ -96,3 +97,34 @@ struct clk *clk_register_fixed_factor(struct device *dev, const char *name,
 
 	return clk;
 }
+
+#ifdef CONFIG_OF
+/**
+ * of_fixed_factor_clkdiv_setup() - Set up simple fixed factor clock divider
+ */
+void of_fixed_factor_clkdiv_setup(struct device_node *node)
+{
+	struct clk *clk;
+	const char *clk_name = node->name;
+	const char *parent_name;
+	u32 mult, div;
+
+	if (of_property_read_u32(node, "clock-mult", &mult))
+		return;
+
+	if (of_property_read_u32(node, "clock-div", &div))
+		return;
+
+	parent_name = of_clk_get_parent_name(node, 0);
+
+	of_property_read_string(node, "clock-output-names", &clk_name);
+
+	clk = clk_register_fixed_factor(NULL, clk_name, parent_name, 0,
+					mult, div);
+	if (!IS_ERR(clk))
+		of_clk_add_provider(node, of_clk_src_simple_get, clk);
+}
+EXPORT_SYMBOL_GPL(of_fixed_factor_clkdiv_setup);
+CLK_OF_DECLARE(fixed_clkdiv, "fixed-factor-clkdiv",
+		of_fixed_factor_clkdiv_setup);
+#endif
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 7f197d7..d4937cf 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -184,6 +184,7 @@ struct clk *clk_register_fixed_rate(struct device *dev, const char *name,
 		unsigned long fixed_rate);
 
 void of_fixed_clk_setup(struct device_node *np);
+void of_fixed_factor_clkdiv_setup(struct device_node *node);
 
 /**
  * struct clk_gate - gating clock
-- 
1.7.1



From hechtb at gmail.com  Wed Apr 10 11:51:47 2013
From: hechtb at gmail.com (Bastian Hecht)
Date: Wed, 10 Apr 2013 17:51:47 +0200
Subject: [PATCH] ARM: shmobile: r8a7740: Add Suspend-To-RAM modes and CPUIdle
Message-ID: <1365609107-14290-1-git-send-email-hechtb+renesas@gmail.com>

We add 2 sleep modes and register a CPUIdle driver that uses them.

- A3SM PLL0 on/off:     Power domain A3SM that contains the ARM core
                        and the 2nd level cache with either PLL0 on
			or off

As the suspend to memory mechanism we use A3SM PLL off.

The setup of the SYSC regarding the external IRQs is taken from
pm-sh7372.c from Magnus Damm.

Signed-off-by: Bastian Hecht <hechtb+renesas at gmail.com>
---
Ok I need to add some remarks here:

First this patch relies on a fix I've sent out today:
"ARM: hw_breakpoint: Do not use __cpuinitdata for dbg_cpu_pm_nb"
Without it we can't use suspend at all without a kernel panic.

Next you can test this in two ways:
Either add IRQF_NO_SUSPEND to the touchscreen driver st1232 at IRQ registration
(hack) or extend the irqpin driver to support wakeup devices properly, meaning
adding suspend and resume callbacks that handle it (proper way). Or you can add
no_console_suspend to the boot options in r8a7740-armadillo800eva.dts. This way
you can use the serial console as wakeup device.


 arch/arm/mach-shmobile/Makefile               |    2 +-
 arch/arm/mach-shmobile/include/mach/r8a7740.h |    2 +
 arch/arm/mach-shmobile/pm-r8a7740.c           |  220 ++++++++++++++++++++++++-
 arch/arm/mach-shmobile/sleep-r8a7740.S        |   68 ++++++++
 4 files changed, 289 insertions(+), 3 deletions(-)
 create mode 100644 arch/arm/mach-shmobile/sleep-r8a7740.S

diff --git a/arch/arm/mach-shmobile/Makefile b/arch/arm/mach-shmobile/Makefile
index 068f1da..0568894 100644
--- a/arch/arm/mach-shmobile/Makefile
+++ b/arch/arm/mach-shmobile/Makefile
@@ -30,7 +30,7 @@ obj-$(CONFIG_SUSPEND)		+= suspend.o
 obj-$(CONFIG_CPU_IDLE)		+= cpuidle.o
 obj-$(CONFIG_ARCH_SHMOBILE)	+= pm-rmobile.o
 obj-$(CONFIG_ARCH_SH7372)	+= pm-sh7372.o sleep-sh7372.o
-obj-$(CONFIG_ARCH_R8A7740)	+= pm-r8a7740.o
+obj-$(CONFIG_ARCH_R8A7740)	+= pm-r8a7740.o sleep-r8a7740.o
 obj-$(CONFIG_ARCH_R8A7779)	+= pm-r8a7779.o
 obj-$(CONFIG_ARCH_SH73A0)	+= pm-sh73a0.o
 
diff --git a/arch/arm/mach-shmobile/include/mach/r8a7740.h b/arch/arm/mach-shmobile/include/mach/r8a7740.h
index abdc4d4..ba4707b 100644
--- a/arch/arm/mach-shmobile/include/mach/r8a7740.h
+++ b/arch/arm/mach-shmobile/include/mach/r8a7740.h
@@ -540,6 +540,8 @@ extern void r8a7740_add_standard_devices(void);
 extern void r8a7740_clock_init(u8 md_ck);
 extern void r8a7740_pinmux_init(void);
 extern void r8a7740_pm_init(void);
+extern void r8a7740_resume(void);
+extern void r8a7740_shutdown(void);
 
 #ifdef CONFIG_PM
 extern void __init r8a7740_init_pm_domains(void);
diff --git a/arch/arm/mach-shmobile/pm-r8a7740.c b/arch/arm/mach-shmobile/pm-r8a7740.c
index 40b87aa..d4613f0 100644
--- a/arch/arm/mach-shmobile/pm-r8a7740.c
+++ b/arch/arm/mach-shmobile/pm-r8a7740.c
@@ -8,10 +8,54 @@
  * License.  See the file "COPYING" in the main directory of this archive
  * for more details.
  */
+#include <linux/bitrev.h>
 #include <linux/console.h>
+#include <linux/cpuidle.h>
+#include <linux/module.h>
 #include <linux/suspend.h>
+#include <linux/io.h>
+#include <asm/suspend.h>
+#include <asm/cacheflush.h>
+#include <asm/cpuidle.h>
+#include <asm/hardware/cache-l2x0.h>
 #include <mach/pm-rmobile.h>
 #include <mach/common.h>
+#include <mach/r8a7740.h>
+
+/* CPGA */
+#define PLLC01STPCR 	IOMEM(0xe61500c8)
+#define SYSTBCR		IOMEM(0xe6150024)
+
+/* SYSC */
+#define STBCHR		IOMEM(0xe6180000)
+#define STBCHRB		IOMEM(0xe6180040)
+#define SPDCR		IOMEM(0xe6180008)
+#define SBAR		IOMEM(0xe6180020)
+#define SRSTFR		IOMEM(0xe61800B4)
+#define WUPSMSK		IOMEM(0xe618002c)
+#define WUPSMSK2	IOMEM(0xe6180048)
+#define WUPSFAC		IOMEM(0xe6180098)
+#define IRQCR 		IOMEM(0xe618022c)
+#define IRQCR2 		IOMEM(0xe6180238)
+#define IRQCR3		IOMEM(0xe6180244)
+#define IRQCR4		IOMEM(0xe6180248)
+
+/* SRSTFR flags */
+#define RAMST		(1 << 19)
+#define RCLNKA		(1 << 7)
+#define RCPRES		(1 << 5)
+#define RCWD1		(1 << 4)
+#define RPF		(1 << 0)
+
+/* INTC */
+#define ICR1A		IOMEM(0xe6900000)
+#define ICR2A		IOMEM(0xe6900004)
+#define ICR3A		IOMEM(0xe6900008)
+#define ICR4A		IOMEM(0xe690000c)
+#define INTMSK00A	IOMEM(0xe6900040)
+#define INTMSK10A	IOMEM(0xe6900044)
+#define INTMSK20A	IOMEM(0xe6900048)
+#define INTMSK30A	IOMEM(0xe690004c)
 
 #ifdef CONFIG_PM
 static int r8a7740_pd_a4s_suspend(void)
@@ -58,12 +102,183 @@ void __init r8a7740_init_pm_domains(void)
 	rmobile_init_domains(r8a7740_pm_domains, ARRAY_SIZE(r8a7740_pm_domains));
 	pm_genpd_add_subdomain_names("A4S", "A3SP");
 }
-
 #endif /* CONFIG_PM */
 
+#if defined(CONFIG_SUSPEND) || defined(CONFIG_CPU_IDLE)
+static void r8a7740_set_reset_vector(unsigned long address)
+{
+	__raw_writel(address, SBAR);
+}
+
+static void r8a7740_icr_to_irqcr(unsigned long icr, u16 *irqcr1p, u16 *irqcr2p)
+{
+	u16 tmp, irqcr1, irqcr2;
+	int k;
+
+	irqcr1 = 0;
+	irqcr2 = 0;
+
+	/* convert INTCA ICR register layout to SYSC IRQCR+IRQCR2 */
+	for (k = 0; k <= 7; k++) {
+		tmp = (icr >> ((7 - k) * 4)) & 0xf;
+		irqcr1 |= (tmp & 0x03) << (k * 2);
+		irqcr2 |= (tmp >> 2) << (k * 2);
+	}
+
+	*irqcr1p = irqcr1;
+	*irqcr2p = irqcr2;
+}
+
+static void r8a7740_setup_sysc(unsigned long msk, unsigned long msk2)
+{
+	u16 irqcrx_low, irqcrx_high, irqcry_low, irqcry_high;
+	unsigned long tmp;
+
+	/* read IRQ0A -> IRQ15A mask */
+	tmp = bitrev8(__raw_readb(INTMSK00A));
+	tmp |= bitrev8(__raw_readb(INTMSK10A)) << 8;
+
+	/* setup WUPSMSK from clocks and external IRQ mask */
+	msk = (~msk & 0xc030000f) | (tmp << 4);
+	__raw_writel(msk, WUPSMSK);
+
+	/* propage level/edge trigger for external IRQ 0->15 */
+	r8a7740_icr_to_irqcr(__raw_readl(ICR1A), &irqcrx_low, &irqcry_low);
+	r8a7740_icr_to_irqcr(__raw_readl(ICR2A), &irqcrx_high, &irqcry_high);
+	__raw_writel((irqcrx_high << 16) | irqcrx_low, IRQCR);
+	__raw_writel((irqcry_high << 16) | irqcry_low, IRQCR2);
+
+	/* read IRQ16A -> IRQ31A mask */
+	tmp = bitrev8(__raw_readb(INTMSK20A));
+	tmp |= bitrev8(__raw_readb(INTMSK30A)) << 8;
+
+	/* setup WUPSMSK2 from clocks and external IRQ mask */
+	msk2 = (~msk2 & 0x00030000) | tmp;
+	__raw_writel(msk2, WUPSMSK2);
+
+	/* propage level/edge trigger for external IRQ 16->31 */
+	r8a7740_icr_to_irqcr(__raw_readl(ICR3A), &irqcrx_low, &irqcry_low);
+	r8a7740_icr_to_irqcr(__raw_readl(ICR4A), &irqcrx_high, &irqcry_high);
+	__raw_writel((irqcrx_high << 16) | irqcrx_low, IRQCR3);
+	__raw_writel((irqcry_high << 16) | irqcry_low, IRQCR4);
+}
+
+static void r8a7740_prepare_wakeup(void)
+{
+	/* clear all flags that lead to a cold boot */
+	__raw_writel(~(RAMST | RCLNKA | RCPRES | RCWD1 | RPF), SRSTFR);
+	/* indicate warm boot */
+	__raw_writel(0x80000000, STBCHRB);
+	/* clear other flags checked by internal ROM boot loader */
+	__raw_writel(0x00000000, STBCHR);
+}
+
+static int r8a7740_do_suspend(unsigned long unused)
+{
+	/*
+	 * cpu_suspend() guarantees that all data made it to the L2.
+	 * Flush it out now and disable the cache controller.
+	 */
+	outer_flush_all();
+	outer_disable();
+
+	r8a7740_shutdown();
+
+	/* in case WFI fails to enter the low power state, restore things */
+	outer_resume();
+
+	return 0;
+}
+
+static void r8a7740_enter_a3sm_common(int pllc0_on)
+{
+	u32 reg32;
+
+	if (pllc0_on)
+		__raw_writel(0, PLLC01STPCR);
+	else
+		__raw_writel(1 << 28, PLLC01STPCR);
+
+	r8a7740_set_reset_vector(__pa(r8a7740_resume));
+	r8a7740_prepare_wakeup();
+	r8a7740_setup_sysc(1 << 0, 0);
+
+	/* Activate delayed shutdown of A3SM */
+	reg32 = __raw_readl(SPDCR);
+	reg32 |= (1 << 31) | (1 << 12);
+	__raw_writel(reg32, SPDCR);
+
+	/* We activate CPU Core Standby as well here */
+	reg32 = __raw_readl(SYSTBCR);
+	reg32 |= (1 << 4);
+	__raw_writel(reg32, SYSTBCR);
+
+	/* Clear Wakeup Factors and do suspend */
+	reg32 = __raw_readl(WUPSFAC);
+	cpu_suspend(0, r8a7740_do_suspend);
+	outer_resume();
+	reg32 = __raw_readl(WUPSFAC);
+
+	/* Clear CPU Core Standby flag for other WFI instructions */
+	reg32 &= ~(1 << 4);
+	__raw_writel(reg32, SYSTBCR);
+
+}
+#endif /* CONFIG_SUSPEND || CONFIG_CPU_IDLE */
+
+#ifdef CONFIG_CPU_IDLE
+static int r8a7740_enter_a3sm_pll_on(struct cpuidle_device *dev,
+					struct cpuidle_driver *drv, int index)
+{
+	r8a7740_enter_a3sm_common(1);
+	return 1;
+}
+
+static int r8a7740_enter_a3sm_pll_off(struct cpuidle_device *dev,
+					struct cpuidle_driver *drv, int index)
+{
+	r8a7740_enter_a3sm_common(0);
+	return 2;
+}
+
+static struct cpuidle_driver r8a7740_cpuidle_driver = {
+	.name			= "r8a7740_cpuidle",
+	.owner			= THIS_MODULE,
+	.en_core_tk_irqen	= 1,
+	.state_count		= 3,
+	.safe_state_index	= 0, /* C1 */
+	.states[0] = ARM_CPUIDLE_WFI_STATE,
+	.states[0].enter = shmobile_enter_wfi,
+	.states[1] = {
+		.name = "C2",
+		.desc = "A3SM PLL ON",
+		.exit_latency = 40,
+		.target_residency = 30 + 40,
+		.flags = CPUIDLE_FLAG_TIME_VALID,
+		.enter = r8a7740_enter_a3sm_pll_on,
+	},
+	.states[2] = {
+		.name = "C3",
+		.desc = "A3SM PLL OFF",
+		.exit_latency = 120,
+		.target_residency = 30 + 120,
+		.flags = CPUIDLE_FLAG_TIME_VALID,
+		.enter = r8a7740_enter_a3sm_pll_off,
+	},
+};
+
+static void r8a7740_cpuidle_init(void)
+{
+	shmobile_cpuidle_set_driver(&r8a7740_cpuidle_driver);
+}
+#else
+static void r8a7740_cpuidle_init(void) {}
+#endif /* CONFIG_CPU_IDLE */
+
 #ifdef CONFIG_SUSPEND
 static int r8a7740_enter_suspend(suspend_state_t suspend_state)
 {
+	r8a7740_enter_a3sm_common(0);
 	cpu_do_idle();
 	return 0;
 }
@@ -74,9 +289,10 @@ static void r8a7740_suspend_init(void)
 }
 #else
 static void r8a7740_suspend_init(void) {}
-#endif
+#endif /* CONFIG_SUSPEND */
 
 void __init r8a7740_pm_init(void)
 {
 	r8a7740_suspend_init();
+	r8a7740_cpuidle_init();
 }
diff --git a/arch/arm/mach-shmobile/sleep-r8a7740.S b/arch/arm/mach-shmobile/sleep-r8a7740.S
new file mode 100644
index 0000000..0ae310d
--- /dev/null
+++ b/arch/arm/mach-shmobile/sleep-r8a7740.S
@@ -0,0 +1,68 @@
+/*
+ * Low level sleep code for the SoC r8a7740
+ *
+ * Copyright (C) 2013 Bastian Hecht
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License.  See the file "COPYING" in the main directory of this archive
+ * for more details.
+ */
+
+#include <linux/linkage.h>
+#include <linux/init.h>
+#include <asm/memory.h>
+
+#if defined(CONFIG_SUSPEND) || defined(CONFIG_CPU_IDLE)
+
+/* r8a7740_shutdown expects L1 and L2 to be flushed */
+	.text
+ENTRY(r8a7740_shutdown)
+	stmfd   sp!, {r4-r12, lr}
+
+	/* make sure the stack stays intact */
+	bl      v7_flush_dcache_all
+
+	/*
+	 * Clear the SCTLR.C bit to prevent further data cache
+	 * allocation. Clearing SCTLR.C would make all the data accesses
+	 * strongly ordered and would not hit the cache.
+	 */
+	mrc	p15, 0, r0, c1, c0, 0
+	bic	r0, r0, #(1 << 2)		@ Disable the C bit
+	mcr	p15, 0, r0, c1, c0, 0
+	isb
+
+	bl      v7_flush_dcache_all
+	bl	cpu_v7_do_idle
+
+	/* in rare cases when WFI fails we end up here and restore things */
+	mrc	p15, 0, r0, c1, c0, 0
+	orr	r0, r0, #(1 << 2)		@ Enable the C bit
+	mcr	p15, 0, r0, c1, c0, 0
+	isb
+
+	ldmfd   sp!, {r4-r12, pc}
+ENDPROC(r8a7740)
+
+	.text
+ENTRY(v7_cpu_resume)
+	bl	v7_invalidate_l1
+	b	cpu_resume
+ENDPROC(v7_cpu_resume)
+
+/*
+ * The entry point of a warm reboot, used by wakeup scenarios
+ *
+ * The CPU jumps in this case to (0xfffff000 & SBAR), so we need
+ * to align this function properly.
+ * We use a long jump into the text segment and use the physical
+ * address as the MMU is still turned off.
+ */
+	.align	12
+	.text
+ENTRY(r8a7740_resume)
+	ldr	pc, 1f
+1:	.long	v7_cpu_resume - PAGE_OFFSET + PLAT_PHYS_OFFSET
+ENDPROC(r8a7740_resume_core_standby)
+#endif
-- 
1.7.9.5



From swarren at wwwdotorg.org  Wed Apr 10 11:54:02 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Wed, 10 Apr 2013 09:54:02 -0600
Subject: Kexec couldn't reboot capture kernel on pandaboard ES with
 OMAP4460
In-Reply-To: <CAFNq8R5FFUyH+JgjoGc5ctgEfiLvxzi7fzawM7+wFX5nEyTv-w@mail.gmail.com>
References: <CAFNq8R5FFUyH+JgjoGc5ctgEfiLvxzi7fzawM7+wFX5nEyTv-w@mail.gmail.com>
Message-ID: <51658B1A.6090706@wwwdotorg.org>

On 04/10/2013 03:35 AM, Li Haifeng wrote:
> Hi, everyone.
> 
> Recently, I try to run kdump on pandaboard ES with omap4460. After
> load capture kernel by "kexec -l" and execute "kexec -e", the serial
> port output "Starting new kernel" and "Bye", then the system hangs up.
> 
> I have tried the upstream Linux Kernel v3.4 and v3.8. All are with this issue.

This is a shot in the dark. I assume you have SMP enabled. Can you use
hotplug to remove all CPUs other than CPU0, so that the kexec happens on
the boot CPU? That is certainly necessary for kexec to work correctly on
Tegra.


From robherring2 at gmail.com  Wed Apr 10 11:55:35 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Wed, 10 Apr 2013 10:55:35 -0500
Subject: [RFC PATCH 3/3] pstore/ram: avoid atomic accesses for ioremapped
 regions
In-Reply-To: <CAMbhsRSNPz1d9bGGEjqyTwVg_1pv8PB15WybEL5ZRVgmnTDWLQ@mail.gmail.com>
References: <1365563297-12480-1-git-send-email-robherring2@gmail.com>
 <1365563297-12480-3-git-send-email-robherring2@gmail.com>
 <CAMbhsRSNPz1d9bGGEjqyTwVg_1pv8PB15WybEL5ZRVgmnTDWLQ@mail.gmail.com>
Message-ID: <51658B77.4050400@gmail.com>

On 04/09/2013 11:10 PM, Colin Cross wrote:
> On Tue, Apr 9, 2013 at 8:08 PM, Rob Herring <robherring2 at gmail.com> wrote:
>> From: Rob Herring <rob.herring at calxeda.com>
>>
>> For persistent RAM outside of main memory, the memory may have limitations
>> on supported accesses. For internal RAM on highbank platform exclusive
>> accesses are not supported and will hang the system. So atomic_cmpxchg
>> cannot be used. This commit uses spinlock protection for buffer size and
>> start updates on ioremapped regions instead.
> 
> I used atomics in persistent_ram to support persistent ftrace, which
> now exists as PSTORE_FTRACE.  At some point during development I had
> trouble with recursive tracing causing an infinite loop, so you may
> want to test that calling out to spinlock functions with PSTORE_FTRACE
> turned on and enabled doesn't cause a problem.

I've tested that now and it appears to work fine. Was there some
specific setup of ftrace that caused problems?

Rob



From gregory.clement at free-electrons.com  Wed Apr 10 11:56:25 2013
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Wed, 10 Apr 2013 17:56:25 +0200
Subject: [PATCH] clk: Add device tree binding to clk-fixed-factor
In-Reply-To: <1365608443-30350-1-git-send-email-christian.ruppert@abilis.com>
References: <1365608443-30350-1-git-send-email-christian.ruppert@abilis.com>
Message-ID: <51658BA9.7030508@free-electrons.com>

Hi Christian,

On 04/10/2013 05:40 PM, Christian Ruppert wrote:
> This patch adds a device tree binding for the simple fixed factor clock
> divider/multiplier of the common clock tree binding.

This patch remind me of something :
http://lists.infradead.org/pipermail/linux-arm-kernel/2012-August/116405.html

Do you have a use case for it, this time?

My version have been hold off waiting for an user for it.
Will you need it for a driver?

Regards,

> 
> Signed-off-by: Christian Ruppert <christian.ruppert at abilis.com>
> ---
>  .../bindings/clock/fixed-factor-clkdiv.txt         |   24 +++++++++++++++
>  drivers/clk/clk-fixed-factor.c                     |   32 ++++++++++++++++++++
>  include/linux/clk-provider.h                       |    1 +
>  3 files changed, 57 insertions(+), 0 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/clock/fixed-factor-clkdiv.txt
> 
> diff --git a/Documentation/devicetree/bindings/clock/fixed-factor-clkdiv.txt b/Documentation/devicetree/bindings/clock/fixed-factor-clkdiv.txt
> new file mode 100644
> index 0000000..352bac4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/fixed-factor-clkdiv.txt
> @@ -0,0 +1,24 @@
> +Device Tree Clock bindings for plat-tb10x
> +
> +This binding uses the common clock binding[1].
> +
> +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
> +
> +Required properties:
> +- compatible : shall be "fixed-factor-clkdiv"
> +- #clock-cells: from common clock binding; shall be set to 0
> +- clocks: shall be the input parent clock phandle for the clock.
> +- clock-mult: defines the multiplication factor of the output clock frequency
> +  wrt. the input clock frequency.
> +- clock-div: defines the division factor of the output clock frequency wrt.
> +  the input clock frequency.
> +
> +Example:
> +cpu_clk: clkdiv_cpu {	/* CPU clock derived from pll0. 1/2 of pll frequency */
> +	compatible = "fixed-factor-clkdiv";
> +	#clock-cells = <0>;
> +	clocks = <&pll0>;
> +	clock-mult = <1>;
> +	clock-div = <2>;
> +	clock-output-names = "cpu_clk";
> +};
> diff --git a/drivers/clk/clk-fixed-factor.c b/drivers/clk/clk-fixed-factor.c
> index 1ef271e..85e45f1 100644
> --- a/drivers/clk/clk-fixed-factor.c
> +++ b/drivers/clk/clk-fixed-factor.c
> @@ -11,6 +11,7 @@
>  #include <linux/clk-provider.h>
>  #include <linux/slab.h>
>  #include <linux/err.h>
> +#include <linux/of.h>
>  
>  /*
>   * DOC: basic fixed multiplier and divider clock that cannot gate
> @@ -96,3 +97,34 @@ struct clk *clk_register_fixed_factor(struct device *dev, const char *name,
>  
>  	return clk;
>  }
> +
> +#ifdef CONFIG_OF
> +/**
> + * of_fixed_factor_clkdiv_setup() - Set up simple fixed factor clock divider
> + */
> +void of_fixed_factor_clkdiv_setup(struct device_node *node)
> +{
> +	struct clk *clk;
> +	const char *clk_name = node->name;
> +	const char *parent_name;
> +	u32 mult, div;
> +
> +	if (of_property_read_u32(node, "clock-mult", &mult))
> +		return;
> +
> +	if (of_property_read_u32(node, "clock-div", &div))
> +		return;
> +
> +	parent_name = of_clk_get_parent_name(node, 0);
> +
> +	of_property_read_string(node, "clock-output-names", &clk_name);
> +
> +	clk = clk_register_fixed_factor(NULL, clk_name, parent_name, 0,
> +					mult, div);
> +	if (!IS_ERR(clk))
> +		of_clk_add_provider(node, of_clk_src_simple_get, clk);
> +}
> +EXPORT_SYMBOL_GPL(of_fixed_factor_clkdiv_setup);
> +CLK_OF_DECLARE(fixed_clkdiv, "fixed-factor-clkdiv",
> +		of_fixed_factor_clkdiv_setup);
> +#endif
> diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
> index 7f197d7..d4937cf 100644
> --- a/include/linux/clk-provider.h
> +++ b/include/linux/clk-provider.h
> @@ -184,6 +184,7 @@ struct clk *clk_register_fixed_rate(struct device *dev, const char *name,
>  		unsigned long fixed_rate);
>  
>  void of_fixed_clk_setup(struct device_node *np);
> +void of_fixed_factor_clkdiv_setup(struct device_node *node);
>  
>  /**
>   * struct clk_gate - gating clock
> 


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From christian.ruppert at abilis.com  Wed Apr 10 12:27:47 2013
From: christian.ruppert at abilis.com (Christian Ruppert)
Date: Wed, 10 Apr 2013 18:27:47 +0200
Subject: [PATCH] clk: Add device tree binding to clk-fixed-factor
In-Reply-To: <51658BA9.7030508@free-electrons.com>
References: <1365608443-30350-1-git-send-email-christian.ruppert@abilis.com>
 <51658BA9.7030508@free-electrons.com>
Message-ID: <20130410162747.GG32603@ab42.lan>

Hi Gregory,

We use derived clocks with fixed ratios for our TB10x platform. I
originally had this in the platform code but Vineet (the platform
maintainer) rightly pointed out that the common clock framework would
be the correct place for it.
Is there any reason not to support this functionality? After all, the
generic fixed rate clock also has a device tree binding and I'd guess
we're not the only ones statically deriving one clock from another in
our SOCs.

Greetings,
  Christian

On Wed, Apr 10, 2013 at 05:56:25PM +0200, Gregory CLEMENT wrote:
> Hi Christian,
> 
> On 04/10/2013 05:40 PM, Christian Ruppert wrote:
> > This patch adds a device tree binding for the simple fixed factor clock
> > divider/multiplier of the common clock tree binding.
> 
> This patch remind me of something :
> http://lists.infradead.org/pipermail/linux-arm-kernel/2012-August/116405.html
> 
> Do you have a use case for it, this time?
> 
> My version have been hold off waiting for an user for it.
> Will you need it for a driver?
> 
> Regards,
> 
> > 
> > Signed-off-by: Christian Ruppert <christian.ruppert at abilis.com>
> > ---
> >  .../bindings/clock/fixed-factor-clkdiv.txt         |   24 +++++++++++++++
> >  drivers/clk/clk-fixed-factor.c                     |   32 ++++++++++++++++++++
> >  include/linux/clk-provider.h                       |    1 +
> >  3 files changed, 57 insertions(+), 0 deletions(-)
> >  create mode 100644 Documentation/devicetree/bindings/clock/fixed-factor-clkdiv.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/clock/fixed-factor-clkdiv.txt b/Documentation/devicetree/bindings/clock/fixed-factor-clkdiv.txt
> > new file mode 100644
> > index 0000000..352bac4
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/clock/fixed-factor-clkdiv.txt
> > @@ -0,0 +1,24 @@
> > +Device Tree Clock bindings for plat-tb10x
> > +
> > +This binding uses the common clock binding[1].
> > +
> > +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
> > +
> > +Required properties:
> > +- compatible : shall be "fixed-factor-clkdiv"
> > +- #clock-cells: from common clock binding; shall be set to 0
> > +- clocks: shall be the input parent clock phandle for the clock.
> > +- clock-mult: defines the multiplication factor of the output clock frequency
> > +  wrt. the input clock frequency.
> > +- clock-div: defines the division factor of the output clock frequency wrt.
> > +  the input clock frequency.
> > +
> > +Example:
> > +cpu_clk: clkdiv_cpu {	/* CPU clock derived from pll0. 1/2 of pll frequency */
> > +	compatible = "fixed-factor-clkdiv";
> > +	#clock-cells = <0>;
> > +	clocks = <&pll0>;
> > +	clock-mult = <1>;
> > +	clock-div = <2>;
> > +	clock-output-names = "cpu_clk";
> > +};
> > diff --git a/drivers/clk/clk-fixed-factor.c b/drivers/clk/clk-fixed-factor.c
> > index 1ef271e..85e45f1 100644
> > --- a/drivers/clk/clk-fixed-factor.c
> > +++ b/drivers/clk/clk-fixed-factor.c
> > @@ -11,6 +11,7 @@
> >  #include <linux/clk-provider.h>
> >  #include <linux/slab.h>
> >  #include <linux/err.h>
> > +#include <linux/of.h>
> >  
> >  /*
> >   * DOC: basic fixed multiplier and divider clock that cannot gate
> > @@ -96,3 +97,34 @@ struct clk *clk_register_fixed_factor(struct device *dev, const char *name,
> >  
> >  	return clk;
> >  }
> > +
> > +#ifdef CONFIG_OF
> > +/**
> > + * of_fixed_factor_clkdiv_setup() - Set up simple fixed factor clock divider
> > + */
> > +void of_fixed_factor_clkdiv_setup(struct device_node *node)
> > +{
> > +	struct clk *clk;
> > +	const char *clk_name = node->name;
> > +	const char *parent_name;
> > +	u32 mult, div;
> > +
> > +	if (of_property_read_u32(node, "clock-mult", &mult))
> > +		return;
> > +
> > +	if (of_property_read_u32(node, "clock-div", &div))
> > +		return;
> > +
> > +	parent_name = of_clk_get_parent_name(node, 0);
> > +
> > +	of_property_read_string(node, "clock-output-names", &clk_name);
> > +
> > +	clk = clk_register_fixed_factor(NULL, clk_name, parent_name, 0,
> > +					mult, div);
> > +	if (!IS_ERR(clk))
> > +		of_clk_add_provider(node, of_clk_src_simple_get, clk);
> > +}
> > +EXPORT_SYMBOL_GPL(of_fixed_factor_clkdiv_setup);
> > +CLK_OF_DECLARE(fixed_clkdiv, "fixed-factor-clkdiv",
> > +		of_fixed_factor_clkdiv_setup);
> > +#endif
> > diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
> > index 7f197d7..d4937cf 100644
> > --- a/include/linux/clk-provider.h
> > +++ b/include/linux/clk-provider.h
> > @@ -184,6 +184,7 @@ struct clk *clk_register_fixed_rate(struct device *dev, const char *name,
> >  		unsigned long fixed_rate);
> >  
> >  void of_fixed_clk_setup(struct device_node *np);
> > +void of_fixed_factor_clkdiv_setup(struct device_node *node);
> >  
> >  /**
> >   * struct clk_gate - gating clock
> > 
> 
> 
> -- 
> Gregory Clement, Free Electrons
> Kernel, drivers, real-time and embedded Linux
> development, consulting, training and support.
> http://free-electrons.com

-- 
  Christian Ruppert              ,          <christian.ruppert at abilis.com>
                                /|
  Tel: +41/(0)22 816 19-42     //|                 3, Chemin du Pr?-Fleuri
                             _// | bilis Systems   CH-1228 Plan-les-Ouates


From will.deacon at arm.com  Wed Apr 10 12:40:38 2013
From: will.deacon at arm.com (Will Deacon)
Date: Wed, 10 Apr 2013 17:40:38 +0100
Subject: [PATCH v3 07/32] arm64: KVM: fault injection into a guest
In-Reply-To: <1365437854-30214-8-git-send-email-marc.zyngier@arm.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
 <1365437854-30214-8-git-send-email-marc.zyngier@arm.com>
Message-ID: <20130410164038.GI26992@mudshark.cambridge.arm.com>

On Mon, Apr 08, 2013 at 05:17:09PM +0100, Marc Zyngier wrote:
> Implement the injection of a fault (undefined, data abort or
> prefetch abort) into a 64bit guest.
> 
> Reviewed-by: Christopher Covington <cov at codeaurora.org>
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> ---
>  arch/arm64/kvm/inject_fault.c | 118 ++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 118 insertions(+)
>  create mode 100644 arch/arm64/kvm/inject_fault.c
> 
> diff --git a/arch/arm64/kvm/inject_fault.c b/arch/arm64/kvm/inject_fault.c
> new file mode 100644
> index 0000000..2ff3b78
> --- /dev/null
> +++ b/arch/arm64/kvm/inject_fault.c
> @@ -0,0 +1,118 @@
> +/*
> + * Fault injection for 64bit guests.
> + *
> + * Copyright (C) 2012,2013 - ARM Ltd
> + * Author: Marc Zyngier <marc.zyngier at arm.com>
> + *
> + * Based on arch/arm/kvm/emulate.c
> + * Copyright (C) 2012 - Virtual Open Systems and Columbia University
> + * Author: Christoffer Dall <c.dall at virtualopensystems.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.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +#include <linux/kvm_host.h>
> +#include <asm/kvm_emulate.h>
> +#include <asm/esr.h>
> +
> +static void inject_abt64(struct kvm_vcpu *vcpu, bool is_iabt, unsigned long addr)
> +{
> +	unsigned long cpsr = *vcpu_cpsr(vcpu);
> +	int is_aarch32;
> +	u32 esr = 0;
> +
> +	is_aarch32 = vcpu_mode_is_32bit(vcpu);
> +
> +	*vcpu_spsr(vcpu) = cpsr;
> +	*vcpu_elr_el1(vcpu) = *vcpu_pc(vcpu);
> +
> +	*vcpu_cpsr(vcpu) = PSR_MODE_EL1h | PSR_A_BIT | PSR_F_BIT | PSR_I_BIT;

You probably want to set PSR_D_BIT too.

> +	*vcpu_pc(vcpu) = vcpu_sys_reg(vcpu, VBAR_EL1) + 0x200;
> +
> +	vcpu_sys_reg(vcpu, FAR_EL1) = addr;
> +
> +	/*
> +	 * Build an {i,d}abort, depending on the level and the
> +	 * instruction set. Report an external synchronous abort.
> +	 */
> +	if (kvm_vcpu_trap_il_is32bit(vcpu))
> +		esr |= ESR_EL1_IL;
> +
> +	if (is_aarch32 || (cpsr & PSR_MODE_MASK) == PSR_MODE_EL0t)
> +		esr |= (ESR_EL1_EC_IABT_EL0 << ESR_EL1_EC_SHIFT);
> +	else
> +		esr |= (ESR_EL1_EC_IABT_EL1 << ESR_EL1_EC_SHIFT);
> +
> +	if (!is_iabt)
> +		esr |= ESR_EL1_EC_DABT_EL0;
> +
> +	vcpu_sys_reg(vcpu, ESR_EL1) = esr | 0x10; /* External abort */
> +}

Probably worth #defining the el1_sync offset and also the esr external abort
class.

Will


From will.deacon at arm.com  Wed Apr 10 12:45:09 2013
From: will.deacon at arm.com (Will Deacon)
Date: Wed, 10 Apr 2013 17:45:09 +0100
Subject: [PATCH v3 09/32] arm64: KVM: user space interface
In-Reply-To: <1365437854-30214-10-git-send-email-marc.zyngier@arm.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
 <1365437854-30214-10-git-send-email-marc.zyngier@arm.com>
Message-ID: <20130410164509.GJ26992@mudshark.cambridge.arm.com>

On Mon, Apr 08, 2013 at 05:17:11PM +0100, Marc Zyngier wrote:
> Provide the kvm.h file that defines the user space visible
> interface.
> 
> Reviewed-by: Christopher Covington <cov at codeaurora.org>
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> ---
>  arch/arm64/include/uapi/asm/kvm.h | 117 ++++++++++++++++++++++++++++++++++++++
>  1 file changed, 117 insertions(+)
>  create mode 100644 arch/arm64/include/uapi/asm/kvm.h
> 
> diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
> new file mode 100644
> index 0000000..4e64570
> --- /dev/null
> +++ b/arch/arm64/include/uapi/asm/kvm.h
> @@ -0,0 +1,117 @@
> +/*
> + * Copyright (C) 2012,2013 - ARM Ltd
> + * Author: Marc Zyngier <marc.zyngier at arm.com>
> + *
> + * Derived from arch/arm/include/uapi/asm/kvm.h:
> + * Copyright (C) 2012 - Virtual Open Systems and Columbia University
> + * Author: Christoffer Dall <c.dall at virtualopensystems.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.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +#ifndef __ARM_KVM_H__
> +#define __ARM_KVM_H__
> +
> +#define KVM_SPSR_EL1	0
> +#define KVM_NR_SPSR	1
> +
> +#ifndef __ASSEMBLY__
> +#include <asm/types.h>
> +#include <asm/ptrace.h>
> +
> +#define __KVM_HAVE_GUEST_DEBUG
> +#define __KVM_HAVE_IRQ_LINE
> +
> +#define KVM_REG_SIZE(id)						\
> +	(1U << (((id) & KVM_REG_SIZE_MASK) >> KVM_REG_SIZE_SHIFT))
> +
> +struct kvm_regs {
> +	struct user_pt_regs regs;	/* sp = sp_el0 */
> +
> +	__u64	sp_el1;
> +	__u64	elr_el1;
> +
> +	__u64	spsr[KVM_NR_SPSR];
> +
> +	struct user_fpsimd_state fp_regs;
> +};
> +
> +/* Supported Processor Types */
> +#define KVM_ARM_TARGET_AEM_V8		0
> +#define KVM_ARM_TARGET_FOUNDATION_V8	1
> +#define KVM_ARM_TARGET_CORTEX_A57	2
> +
> +#define KVM_ARM_NUM_TARGETS		3
> +
> +/* KVM_ARM_SET_DEVICE_ADDR ioctl id encoding */
> +#define KVM_ARM_DEVICE_TYPE_SHIFT	0
> +#define KVM_ARM_DEVICE_TYPE_MASK	(0xffff << KVM_ARM_DEVICE_TYPE_SHIFT)
> +#define KVM_ARM_DEVICE_ID_SHIFT		16
> +#define KVM_ARM_DEVICE_ID_MASK		(0xffff << KVM_ARM_DEVICE_ID_SHIFT)
> +
> +/* Supported device IDs */
> +#define KVM_ARM_DEVICE_VGIC_V2		0
> +
> +/* Supported VGIC address types  */
> +#define KVM_VGIC_V2_ADDR_TYPE_DIST	0
> +#define KVM_VGIC_V2_ADDR_TYPE_CPU	1
> +
> +#define KVM_VGIC_V2_DIST_SIZE		0x1000
> +#define KVM_VGIC_V2_CPU_SIZE		0x2000

How does this work with 64k pages?

> +struct kvm_vcpu_init {
> +	__u32 target;
> +	__u32 features[7];
> +};
> +
> +struct kvm_sregs {
> +};
> +
> +struct kvm_fpu {
> +};
> +
> +struct kvm_guest_debug_arch {
> +};
> +
> +struct kvm_debug_exit_arch {
> +};
> +
> +struct kvm_sync_regs {
> +};
> +
> +struct kvm_arch_memory_slot {
> +};
> +
> +/* KVM_IRQ_LINE irq field index values */
> +#define KVM_ARM_IRQ_TYPE_SHIFT		24
> +#define KVM_ARM_IRQ_TYPE_MASK		0xff
> +#define KVM_ARM_IRQ_VCPU_SHIFT		16
> +#define KVM_ARM_IRQ_VCPU_MASK		0xff
> +#define KVM_ARM_IRQ_NUM_SHIFT		0
> +#define KVM_ARM_IRQ_NUM_MASK		0xffff
> +
> +/* irq_type field */
> +#define KVM_ARM_IRQ_TYPE_CPU		0
> +#define KVM_ARM_IRQ_TYPE_SPI		1
> +#define KVM_ARM_IRQ_TYPE_PPI		2
> +
> +/* out-of-kernel GIC cpu interrupt injection irq_number field */
> +#define KVM_ARM_IRQ_CPU_IRQ		0
> +#define KVM_ARM_IRQ_CPU_FIQ		1

Do we need this support for AArch64?


From jason at lakedaemon.net  Wed Apr 10 12:55:58 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Wed, 10 Apr 2013 12:55:58 -0400
Subject: [PATCH 2/2] Fix GE0/GE1 init on ix2-200 as GE0 has no PHY
In-Reply-To: <1364703204-14982-3-git-send-email-nigel@nobiscuit.com>
References: <1364703204-14982-1-git-send-email-nigel@nobiscuit.com>
 <1364703204-14982-3-git-send-email-nigel@nobiscuit.com>
Message-ID: <20130410165558.GB28693@titan.lakedaemon.net>

On Sun, Mar 31, 2013 at 03:13:24PM +1100, Nigel Roberts wrote:
> ---
>  arch/arm/mach-kirkwood/board-iomega_ix2_200.c |    7 ++++++-
>  1 file changed, 6 insertions(+), 1 deletion(-)

Applied to mvebu/fixes

thx,

Jason.


From jgunthorpe at obsidianresearch.com  Wed Apr 10 12:57:50 2013
From: jgunthorpe at obsidianresearch.com (Jason Gunthorpe)
Date: Wed, 10 Apr 2013 10:57:50 -0600
Subject: [PATCH v6 1/5] drivers: memory: Introduce Marvell EBU Device Bus
 driver
In-Reply-To: <20130410101956.GA2250@localhost>
References: <1365539181-29242-1-git-send-email-ezequiel.garcia@free-electrons.com>
 <1365539181-29242-2-git-send-email-ezequiel.garcia@free-electrons.com>
 <20130409203855.GA27797@obsidianresearch.com>
 <20130410101956.GA2250@localhost>
Message-ID: <20130410165750.GA6441@obsidianresearch.com>

On Wed, Apr 10, 2013 at 07:19:57AM -0300, Ezequiel Garcia wrote:
> Hi Jason,
> 
> On Tue, Apr 09, 2013 at 02:38:55PM -0600, Jason Gunthorpe wrote:
> > On Tue, Apr 09, 2013 at 05:26:17PM -0300, Ezequiel Garcia wrote:
> > > +	/*
> > > +	 * Since this is only part of the workaround,
> > > +	 * we can do this dirty 'ranges' property parsing.
> > > +	 * Of course, this will be removed once the address windows
> > > +	 * are declared in the device tree.
> > > +	 */
> > > +	err = of_property_read_u32_array(node, "ranges", addr_region,
> > > +					 ARRAY_SIZE(addr_region));
> > 
> > Oh, this is a dangerous way to parse ranges.. 
> > 
> > Try something like:
> > 
> > const __be32 *prop;
> > u64 base;
> > u64 size;
> > 
> > prop = of_get_property("ranges",&psize);
> > if (prop == NULL || psize != of_n_addr_cells(node) + of_n_size_cells(node))
> >    err;
> > base = of_translate_address(node,prop);
> > if (base == OF_BAD_ADDR)
> >    err;
> > size = of_read_number(prop + of_n_addr_cells(node),of_n_size_cells(node));
> > 
> 
> Thanks for giving me these hints!

NP, the motivation for doing this properly is to support cases where
p_addr_cells/addr_cells/size_cells is != 1, and to support cases where
the parent bus address is not the CPU address. The proposed bindings
for mbus will exercise both of these conditions..

> Following your suggestion, here's a working piece of the ranges parsing code,
> how does this look?
> 
> const __be32 *ranges;
> int addr_cells, p_addr_cells, size_cells;
> int ranges_len, tuple_len;
> u32 base, size;
> 
> p_addr_cells = of_n_addr_cells(node->parent);

I wonder if of_get_parent / of_node_put is technically needed here?

> addr_cells = of_n_addr_cells(node);
> size_cells = of_n_size_cells(node);
> tuple_len = (p_addr_cells + addr_cells + size_cells) * sizeof(__be32);
> 
> ranges = of_get_property(node, "ranges", &ranges_len);
> if (ranges == NULL || ranges_len != tuple_len)
> 	return -EINVAL;
> 
> base = of_translate_address(node, ranges + addr_cells);
> if (base == 0 || base == OF_BAD_ADDR)
> 	return -EINVAL;

Why the check for base == 0?

> size = of_read_number(ranges + addr_cells + p_addr_cells, size_cells);

Everything basically looks right. I definitely forgot the include the
p_addr in my quick sample.

Jason


From andrew at lunn.ch  Wed Apr 10 12:55:09 2013
From: andrew at lunn.ch (Andrew Lunn)
Date: Wed, 10 Apr 2013 18:55:09 +0200
Subject: [PATCH 05/18] cpuidle: make a single register function for all
In-Reply-To: <1365603743-5618-6-git-send-email-daniel.lezcano@linaro.org>
References: <1365603743-5618-1-git-send-email-daniel.lezcano@linaro.org>
 <1365603743-5618-6-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <20130410165509.GK13524@lunn.ch>

> +/**
> + * cpuidle_register: registers the driver and the cpu devices with the
> + * coupled_cpus passed as parameter. This function is used for all common
> + * initialization pattern there are in the arch specific drivers. The
> + * devices is globally defined in this file.
> + *
> + * @drv         : a valid pointer to a struct cpuidle_driver
> + * @coupled_cpus: a cpumask for the coupled states
> + *
> + * Returns 0 on success, < 0 otherwise
> + */
> +int cpuidle_register(struct cpuidle_driver *drv,
> +		     const struct cpumask *const coupled_cpus)
> +{
> +	int ret, cpu;
> +	struct cpuidle_device *device;
> +
> +	ret = cpuidle_register_driver(drv);
> +	if (ret) {
> +		printk(KERN_ERR "failed to register cpuidle driver\n");

pr_err()

> +		return ret;
> +	}
> +
> +	for_each_possible_cpu(cpu) {
> +		device = &per_cpu(cpuidle_dev, cpu);
> +		device->cpu = cpu;
> +#ifdef CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED
> +		device->coupled_cpus = *coupled_cpus;
> +#endif
> +		ret = cpuidle_register_device(device);
> +		if (!ret)
> +			continue;
> +
> +		printk(KERN_ERR "Failed to register cpuidle "
> +		       "device for cpu%d\n", cpu);

pr_err() and don't split the message over two lines, it makes it
harder for somebody to find with

grep -r "Failed to register cpuidle device for cpu" *

> +		cpuidle_unregister(drv);
> +		break;
> +	}
> +
> +	return 0;

You should return an error code, so that the caller can also return an
error code. If you look at cpuidle-kirkwood and cpuidle-calxeda, and
maybe others, if the registration fails, the probe function returns an
error code, as it should. With your change, its always going to return
0, even if it fails.

   Andrew




From jason at lakedaemon.net  Wed Apr 10 13:02:16 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Wed, 10 Apr 2013 13:02:16 -0400
Subject: [PATCH] arm: mvebu: Fix the irq map function in SMP mode
In-Reply-To: <1365165172-11447-2-git-send-email-gregory.clement@free-electrons.com>
References: <1365165172-11447-1-git-send-email-gregory.clement@free-electrons.com>
 <1365165172-11447-2-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <20130410170216.GC28693@titan.lakedaemon.net>

On Fri, Apr 05, 2013 at 02:32:52PM +0200, Gregory CLEMENT wrote:
> This patch fix the regression introduced by the commit 3202bf0157ccb
> "arm: mvebu: Improve the SMP support of the interrupt controller":
> GPIO IRQ were no longer delivered to the CPUs.
> 
> To be delivered to a CPU an interrupt must be enabled at CPU level and
> at interrupt source level. Before the offending patch, all the
> interrupts were enabled at source level during map() function. Mask()
> and unmask() was done by handling the per-CPU part. It was fine when
> running in UP with only one CPU.
> 
> The offending patch added support for SMP, in this case mask() and
> unmask() was done by handling the interrupt source level part. The
> per-CPU level part was handled by the affinity API to select the CPU
> which will receive the interrupt. (Due to some hardware limitation
> only one CPU at a time can received a given interrupt).
> 
> For "normal" interrupt __setup_irq() was called when an irq was
> registered. irq_set_affinity() is called from this function, which
> enabled the interrupt on one of the CPUs. Whereas for GPIO IRQ which
> were chained interrupts, the irq_set_affinity() was never called and
> none of the CPUs was selected to receive the interrupt.
> 
> With this patch all the interrupt are enable on the current CPU during
> map() function. Enabling the interrupts on a CPU doesn't depend
> anymore on irq_set_affinity() and then the chained irq are not anymore
> a special case. However the CPU which will receive the irq can still
> be modify later using irq_set_affinity().
> 
> Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
> Reported-by: Ryan Press <ryan at presslab.us>
> Investigated-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
> Tested-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
> 
> Tested with Mirabox (A370) and Openblocks AX3 (AXP), rootfs mounted
> over NFS, compiled with CONFIG_SMP=y/N.
> ---
>  arch/arm/mach-mvebu/irq-armada-370-xp.c |   16 +++++-----------
>  1 file changed, 5 insertions(+), 11 deletions(-)

Applied to mvebu/fixes with one small change, I moved the "*-by: ..."
block to the end of the commit message and added Ryan's Tested-by:

thx,

Jason.


From will.deacon at arm.com  Wed Apr 10 13:04:35 2013
From: will.deacon at arm.com (Will Deacon)
Date: Wed, 10 Apr 2013 18:04:35 +0100
Subject: [PATCH v3 10/32] arm64: KVM: system register handling
In-Reply-To: <1365437854-30214-11-git-send-email-marc.zyngier@arm.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
 <1365437854-30214-11-git-send-email-marc.zyngier@arm.com>
Message-ID: <20130410170435.GK26992@mudshark.cambridge.arm.com>

On Mon, Apr 08, 2013 at 05:17:12PM +0100, Marc Zyngier wrote:
> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> new file mode 100644
> index 0000000..9df3b32
> --- /dev/null
> +++ b/arch/arm64/kvm/sys_regs.c
> @@ -0,0 +1,871 @@
> +/*
> + * Copyright (C) 2012,2013 - ARM Ltd
> + * Author: Marc Zyngier <marc.zyngier at arm.com>
> + *
> + * Derived from arch/arm/kvm/coproc.c:
> + * Copyright (C) 2012 - Virtual Open Systems and Columbia University
> + * Authors: Rusty Russell <rusty at rustcorp.com.au>
> + *          Christoffer Dall <c.dall at virtualopensystems.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.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +#include <linux/mm.h>
> +#include <linux/kvm_host.h>
> +#include <linux/uaccess.h>
> +#include <asm/kvm_arm.h>
> +#include <asm/kvm_host.h>
> +#include <asm/kvm_emulate.h>
> +#include <asm/kvm_coproc.h>
> +#include <asm/cacheflush.h>
> +#include <asm/cputype.h>
> +#include <trace/events/kvm.h>
> +
> +#include "sys_regs.h"
> +
> +/*
> + * All of this file is extremly similar to the ARM coproc.c, but the
> + * types are different. My gut feeling is that it should be pretty
> + * easy to merge, but that would be an ABI breakage -- again. VFP
> + * would also need to be abstracted.
> + */

Yes, there's a lot of duplication here.

> +/* 3 bits per cache level, as per CLIDR, but non-existent caches always 0 */
> +static u32 cache_levels;
> +
> +/* CSSELR values; used to index KVM_REG_ARM_DEMUX_ID_CCSIDR */
> +#define CSSELR_MAX 12
> +
> +/* Which cache CCSIDR represents depends on CSSELR value. */
> +static u32 get_ccsidr(u32 csselr)
> +{
> +       u32 ccsidr;
> +
> +       /* Make sure noone else changes CSSELR during this! */
> +       local_irq_disable();
> +       /* Put value into CSSELR */
> +       asm volatile("msr csselr_el1, %x0" : : "r" (csselr));
> +       /* Read result out of CCSIDR */
> +       asm volatile("mrs %0, ccsidr_el1" : "=r" (ccsidr));
> +       local_irq_enable();

Case in point: you're missing an isb here, which I remember pointing out
when Christoffer made the same mistake...

> +       return ccsidr;
> +}
> +
> +static void do_dc_cisw(u32 val)
> +{
> +       asm volatile("dc cisw, %x0" : : "r" (val));
> +}
> +
> +static void do_dc_csw(u32 val)
> +{
> +       asm volatile("dc csw, %x0" : : "r" (val));
> +}

You don't have any barriers here. Whilst you could expect the guest to take
care of barriers, I don't think that works if you are preempted and handle
this on a different core.

> +/* See note at ARM ARM B1.14.4 */
> +static bool access_dcsw(struct kvm_vcpu *vcpu,
> +                       const struct sys_reg_params *p,
> +                       const struct sys_reg_desc *r)
> +{
> +       unsigned long val;
> +       int cpu;
> +
> +       cpu = get_cpu();
> +
> +       if (!p->is_write)
> +               return read_from_write_only(vcpu, p);

Missing put_cpu().

Will


From robertcnelson at gmail.com  Wed Apr 10 13:05:32 2013
From: robertcnelson at gmail.com (Robert Nelson)
Date: Wed, 10 Apr 2013 12:05:32 -0500
Subject: [PATCH] ARM: at91/dts: at91sam9g20ek_2mmc: fix card detection
Message-ID: <1365613532-18919-1-git-send-email-robertcnelson@gmail.com>

Use cd-inverted to fix card detection on the at91sam9g20-ek Rev C Dev board.

With: v3.9-rc6:
atmel_mci fffa8000.mmc: version: 0x210
atmel_mci fffa8000.mmc: using PDC
atmel_mci fffa8000.mmc: Atmel MCI controller at 0xfffa8000 irq 30, 2 slots
Waiting for root device /dev/mmcblk0p2...

With: v3.9-rc6 + this patch, card is now detected.
atmel_mci fffa8000.mmc: version: 0x210
atmel_mci fffa8000.mmc: using PDC
mmc0: host does not support reading read-only switch. assuming write-enable.
mmc0: new SD card at address 0007
atmel_mci fffa8000.mmc: Atmel MCI controller at 0xfffa8000 irq 30, 2 slots
mmcblk0: mmc0:0007 SD02G 1.89 GiB
mmcblk0: p1 p2

Although other issues still remain:
mmcblk0: retrying using single block read
mmcblk0: error -115 sending stop command, original cmd response 0xb00, card status 0x900
mmcblk0: error -110 transferring data, sector 834296, nr 8, cmd response 0xb00, card status 0x0
mmcblk0: retrying using single block read

Signed-off-by: Robert Nelson <robertcnelson at gmail.com>
---
 arch/arm/boot/dts/at91sam9g20ek_2mmc.dts |    1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/at91sam9g20ek_2mmc.dts b/arch/arm/boot/dts/at91sam9g20ek_2mmc.dts
index 66467b1..d1b1521 100644
--- a/arch/arm/boot/dts/at91sam9g20ek_2mmc.dts
+++ b/arch/arm/boot/dts/at91sam9g20ek_2mmc.dts
@@ -24,6 +24,7 @@
 					reg = <0>;
 					bus-width = <4>;
 					cd-gpios = <&pioC 2 0>;
+					cd-inverted;
 				};
 			};
 
-- 
1.7.10.4



From will.deacon at arm.com  Wed Apr 10 13:06:24 2013
From: will.deacon at arm.com (Will Deacon)
Date: Wed, 10 Apr 2013 18:06:24 +0100
Subject: [PATCH v3 11/32] arm64: KVM: CPU specific system registers
 handling
In-Reply-To: <1365437854-30214-12-git-send-email-marc.zyngier@arm.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
 <1365437854-30214-12-git-send-email-marc.zyngier@arm.com>
Message-ID: <20130410170624.GL26992@mudshark.cambridge.arm.com>

On Mon, Apr 08, 2013 at 05:17:13PM +0100, Marc Zyngier wrote:
> Add the support code for CPU specific system registers. Not much
> here yet.
> 
> Reviewed-by: Christopher Covington <cov at codeaurora.org>
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> ---
>  arch/arm64/kvm/sys_regs_generic_v8.c | 85 ++++++++++++++++++++++++++++++++++++
>  1 file changed, 85 insertions(+)
>  create mode 100644 arch/arm64/kvm/sys_regs_generic_v8.c
> 
> diff --git a/arch/arm64/kvm/sys_regs_generic_v8.c b/arch/arm64/kvm/sys_regs_generic_v8.c
> new file mode 100644
> index 0000000..d4e8039
> --- /dev/null
> +++ b/arch/arm64/kvm/sys_regs_generic_v8.c
> @@ -0,0 +1,85 @@
> +/*
> + * Copyright (C) 2012,2013 - ARM Ltd
> + * Author: Marc Zyngier <marc.zyngier at arm.com>
> + *
> + * Based on arch/arm/kvm/coproc_a15.c:
> + * Copyright (C) 2012 - Virtual Open Systems and Columbia University
> + * Authors: Rusty Russell <rusty at rustcorp.au>
> + *          Christoffer Dall <c.dall at virtualopensystems.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.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
> + */
> +#include <linux/kvm_host.h>
> +#include <asm/cputype.h>
> +#include <asm/kvm_arm.h>
> +#include <asm/kvm_asm.h>
> +#include <asm/kvm_host.h>
> +#include <asm/kvm_emulate.h>
> +#include <asm/kvm_coproc.h>
> +#include <linux/init.h>
> +
> +#include "sys_regs.h"
> +
> +static bool access_actlr(struct kvm_vcpu *vcpu,
> +			 const struct sys_reg_params *p,
> +			 const struct sys_reg_desc *r)
> +{
> +	if (p->is_write)
> +		return ignore_write(vcpu, p);
> +
> +	*vcpu_reg(vcpu, p->Rt) = vcpu_sys_reg(vcpu, ACTLR_EL1);
> +	return true;
> +}
> +
> +static void reset_actlr(struct kvm_vcpu *vcpu, const struct sys_reg_desc *r)
> +{
> +	u64 actlr;
> +
> +	asm volatile("mrs %0, actlr_el1\n" : "=r" (actlr));
> +	vcpu_sys_reg(vcpu, ACTLR_EL1) = actlr;
> +}

Do we actually need this? If so, there are likely other registers (things
like the ectlr) that should be considered too.

Will


From andrew at lunn.ch  Wed Apr 10 13:04:57 2013
From: andrew at lunn.ch (Andrew Lunn)
Date: Wed, 10 Apr 2013 19:04:57 +0200
Subject: [PATCH 05/18] cpuidle: make a single register function for all
In-Reply-To: <1365603743-5618-6-git-send-email-daniel.lezcano@linaro.org>
References: <1365603743-5618-1-git-send-email-daniel.lezcano@linaro.org>
 <1365603743-5618-6-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <20130410170457.GL13524@lunn.ch>

> +int cpuidle_register(struct cpuidle_driver *drv,
> +		     const struct cpumask *const coupled_cpus)
> +{
> +	int ret, cpu;
> +	struct cpuidle_device *device;
> +
> +	ret = cpuidle_register_driver(drv);
> +	if (ret) {
> +		printk(KERN_ERR "failed to register cpuidle driver\n");
> +		return ret;
> +	}
> +
> +	for_each_possible_cpu(cpu) {
> +		device = &per_cpu(cpuidle_dev, cpu);
> +		device->cpu = cpu;
> +#ifdef CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED
> +		device->coupled_cpus = *coupled_cpus;
> +#endif

At least the kirkwood and the calxeda driver set 

   device->state_count

which you don't appear to do. cpuidle_add_state_sysfs() and
cpuidle_remove_state_sysfs() use this. Is it now being set somewhere
else?

Thanks
	Andrew


From will.deacon at arm.com  Wed Apr 10 13:07:07 2013
From: will.deacon at arm.com (Will Deacon)
Date: Wed, 10 Apr 2013 18:07:07 +0100
Subject: [PATCH v3 12/32] arm64: KVM: virtual CPU reset
In-Reply-To: <1365437854-30214-13-git-send-email-marc.zyngier@arm.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
 <1365437854-30214-13-git-send-email-marc.zyngier@arm.com>
Message-ID: <20130410170707.GM26992@mudshark.cambridge.arm.com>

On Mon, Apr 08, 2013 at 05:17:14PM +0100, Marc Zyngier wrote:
> Provide the reset code for a virtual CPU booted in 64bit mode.
> 
> Reviewed-by: Christopher Covington <cov at codeaurora.org>
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> ---
>  arch/arm64/kvm/reset.c | 76 ++++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 76 insertions(+)
>  create mode 100644 arch/arm64/kvm/reset.c
> 
> diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
> new file mode 100644
> index 0000000..bc33e76
> --- /dev/null
> +++ b/arch/arm64/kvm/reset.c
> @@ -0,0 +1,76 @@
> +/*
> + * Copyright (C) 2012,2013 - ARM Ltd
> + * Author: Marc Zyngier <marc.zyngier at arm.com>
> + *
> + * Derived from arch/arm/kvm/reset.c
> + * Copyright (C) 2012 - Virtual Open Systems and Columbia University
> + * Author: Christoffer Dall <c.dall at virtualopensystems.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.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +#include <linux/errno.h>
> +#include <linux/kvm_host.h>
> +#include <linux/kvm.h>
> +
> +#include <asm/cputype.h>
> +#include <asm/ptrace.h>
> +#include <asm/kvm_arm.h>
> +#include <asm/kvm_coproc.h>
> +
> +/*
> + * ARMv8 Reset Values
> + */
> +static struct kvm_regs default_regs_reset = {
> +	.regs.pstate = PSR_MODE_EL1h | PSR_A_BIT | PSR_I_BIT | PSR_F_BIT,

PSR_D_BIT again.

Will


From tony at atomide.com  Wed Apr 10 13:07:39 2013
From: tony at atomide.com (Tony Lindgren)
Date: Wed, 10 Apr 2013 10:07:39 -0700
Subject: [RFC PATCH 3/3] ARM: OMAP2+: Add command line parameter for
 debugSS module control
In-Reply-To: <79CD15C6BA57404B839C016229A409A83EC4A236@DBDE01.ent.ti.com>
References: <hvaibhav@ti.com>
 <1362396957-30113-4-git-send-email-hvaibhav@ti.com>
 <20130408172936.GQ10155@atomide.com>
 <79CD15C6BA57404B839C016229A409A83EC47BB2@DBDE01.ent.ti.com>
 <20130409163459.GJ10155@atomide.com>
 <79CD15C6BA57404B839C016229A409A83EC4A236@DBDE01.ent.ti.com>
Message-ID: <20130410170737.GA10155@atomide.com>

* Hiremath, Vaibhav <hvaibhav at ti.com> [130409 22:16]:
> Agreed on making it as a module.
> 
> But do you think we should allow it as a loadable module (M) as well, 
> as user will loose Connectivity to JTAG during boot.
> Another perspective here would be, user can insert the module and
> Get JTAG connectivity, which also seems ok to me.

Yes both ways should be doable.
 
> Can you also confirm on having command line argument? I think
> We can only live with DT based approach, right?

Well I doubt that anybody wants to keep it permanently enabled
because of the power consumption and blocking of PM states, so
an additional cmdline might make sense.

It would be nice to have it most of the time built-in but disable
itself unless something debug is specified in the cmdline.

Maybe the JTAG driver can detect when the cable is connected?
Or maybe that would be only when there's clock coming over
JTAG?

Regards,

Tony


From jason at lakedaemon.net  Wed Apr 10 13:12:54 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Wed, 10 Apr 2013 13:12:54 -0400
Subject: [GIT PULL] ARM: mvebu: fixes for v3.9 (round 3)
Message-ID: <20130410171254.GD28693@titan.lakedaemon.net>


The following changes since commit 879d68a445dd7073a8c022fcdd21dc27eca7f192:

  arm: mvebu: Fix pinctrl for Armada 370 Mirabox SDIO port. (2013-03-28 17:29:23 +0000)

are available in the git repository at:

  git://git.infradead.org/users/jcooper/linux.git tags/mvebu_fixes_for_v3.9_round3

for you to fetch changes up to 600468d0686096ddc1000c8a2e69475931084414:

  arm: mvebu: Fix the irq map function in SMP mode (2013-04-10 16:59:14 +0000)

----------------------------------------------------------------
mvebu fixes for v3.9 round 3

 - Kirkwood
    - a couple of small fixes for the Iomega ix2-200 board (ether and led)
 - mvebu
    - allow GPIO button to work on Mirabox when running SMP

----------------------------------------------------------------
Gregory CLEMENT (1):
      arm: mvebu: Fix the irq map function in SMP mode

Nigel Roberts (2):
      ARM: Kirkwood: Fix typo in the definition of ix2-200 rebuild LED
      Fix GE0/GE1 init on ix2-200 as GE0 has no PHY

 arch/arm/boot/dts/kirkwood-iomega_ix2_200.dts | 14 +++++++-------
 arch/arm/mach-kirkwood/board-iomega_ix2_200.c |  7 ++++++-
 arch/arm/mach-mvebu/irq-armada-370-xp.c       | 16 +++++-----------
 3 files changed, 18 insertions(+), 19 deletions(-)


From will.deacon at arm.com  Wed Apr 10 13:13:39 2013
From: will.deacon at arm.com (Will Deacon)
Date: Wed, 10 Apr 2013 18:13:39 +0100
Subject: [PATCH v3 15/32] arm64: KVM: guest one-reg interface
In-Reply-To: <1365437854-30214-16-git-send-email-marc.zyngier@arm.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
 <1365437854-30214-16-git-send-email-marc.zyngier@arm.com>
Message-ID: <20130410171339.GN26992@mudshark.cambridge.arm.com>

On Mon, Apr 08, 2013 at 05:17:17PM +0100, Marc Zyngier wrote:
> Let userspace play with the guest registers.
> 
> Reviewed-by: Christopher Covington <cov at codeaurora.org>
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> ---
>  arch/arm64/kvm/guest.c | 254 +++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 254 insertions(+)
>  create mode 100644 arch/arm64/kvm/guest.c
> 
> diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
> new file mode 100644
> index 0000000..47d3729
> --- /dev/null
> +++ b/arch/arm64/kvm/guest.c
> @@ -0,0 +1,254 @@
> +/*
> + * Copyright (C) 2012,2013 - ARM Ltd
> + * Author: Marc Zyngier <marc.zyngier at arm.com>
> + *
> + * Derived from arch/arm/kvm/guest.c:
> + * Copyright (C) 2012 - Virtual Open Systems and Columbia University
> + * Author: Christoffer Dall <c.dall at virtualopensystems.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.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +#include <linux/errno.h>
> +#include <linux/err.h>
> +#include <linux/kvm_host.h>
> +#include <linux/module.h>
> +#include <linux/vmalloc.h>
> +#include <linux/fs.h>
> +#include <asm/cputype.h>
> +#include <asm/uaccess.h>
> +#include <asm/kvm.h>
> +#include <asm/kvm_asm.h>
> +#include <asm/kvm_emulate.h>
> +#include <asm/kvm_coproc.h>
> +
> +struct kvm_stats_debugfs_item debugfs_entries[] = {
> +	{ NULL }
> +};
> +
> +int kvm_arch_vcpu_setup(struct kvm_vcpu *vcpu)
> +{
> +	vcpu->arch.hcr_el2 = HCR_GUEST_FLAGS;
> +	return 0;
> +}
> +
> +static u64 core_reg_offset_from_id(u64 id)
> +{
> +	return id & ~(KVM_REG_ARCH_MASK | KVM_REG_SIZE_MASK | KVM_REG_ARM_CORE);
> +}
> +
> +static int get_core_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> +{
> +	__u32 __user *uaddr = (__u32 __user *)(unsigned long)reg->addr;
> +	struct kvm_regs *regs = vcpu_gp_regs(vcpu);
> +	int nr_regs = sizeof(*regs) / sizeof(__u32);

Why are you treating the registers as u32?

Will


From thomas.petazzoni at free-electrons.com  Wed Apr 10 13:21:06 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Wed, 10 Apr 2013 19:21:06 +0200
Subject: [PATCHv1 0/5] Marvell EBU irqchip improvements
In-Reply-To: <20130410130902.GA29100@localhost>
References: <1365542778-27959-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <20130410130902.GA29100@localhost>
Message-ID: <20130410192106.73d81f2c@skate>

Dear Ezequiel Garcia,

On Wed, 10 Apr 2013 10:09:03 -0300, Ezequiel Garcia wrote:

> I'm trying to test this patchset, assuming you've based it on top of
> v3.9-rc5.
> 
> However, patch 4/5 doesn't apply and I'm not really sure which
> other patches may be depending on this.
> 
> Any hints?

The patch set is based on 3.9-rc6, with no other dependencies. However,
since a patch has been applied on the mvebu IRQ controller driver
between 3.9-rc5 and 3.9-rc6, it probably explains the fact that the
patch set doesn't apply as is on 3.9-rc5.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From swarren at wwwdotorg.org  Wed Apr 10 13:23:13 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Wed, 10 Apr 2013 11:23:13 -0600
Subject: [PATCH 1/3] ARM: tegra: pcie: Add tegra3 support
In-Reply-To: <1365435688-4179-1-git-send-email-jagarwal@nvidia.com>
References: <1365435688-4179-1-git-send-email-jagarwal@nvidia.com>
Message-ID: <5165A001.9030408@wwwdotorg.org>

On 04/08/2013 09:41 AM, Jay Agarwal wrote:
> Signed-off-by: Jay Agarwal <jagarwal at nvidia.com>
> 
> - Enable pcie root port 2 for cardhu
> - Make private data structure for each SOC
> - Add required tegra3 clocks and regulators
> - Add tegra3 specific code in enable controller
> - Modify clock tree to get clocks based on device
> - Based on git://gitorious.org/thierryreding/linux.git

Did you test these patches? They don't work for me on my Cardhu A04.

First off, I had to change the num-lanes properties to match Cardhu's
actual configuration:

> diff --git a/arch/arm/boot/dts/tegra30-cardhu.dtsi b/arch/arm/boot/dts/tegra30-cardhu.dtsi
> index d64d12c..6426226 100644
> --- a/arch/arm/boot/dts/tegra30-cardhu.dtsi
> +++ b/arch/arm/boot/dts/tegra30-cardhu.dtsi
> @@ -143,8 +143,17 @@
>                 vdd-supply = <&ldo1_reg>;
>                 avdd-supply = <&ldo2_reg>;
>  
> +               pci at 1,0 {
> +                       nvidia,num-lanes = <4>;
> +               };
> +
> +               pci at 2,0 {
> +                       nvidia,num-lanes = <1>;
> +               };
> +
>                 pci at 3,0 {
>                         status = "okay";
> +                       nvidia,num-lanes = <1>;
>                 };
>         };
>  

However, even after doing that, the driver doesn't detect anything
attached to port at 3,0, even though I have the board plugged into the
docking station, and hence the PCI Ethernet should be detected:

> [    3.103860] tegra-pcie 3000.pcie-controller: 4x1, 1x2 configuration
> [    3.113755] tegra-pcie 3000.pcie-controller: probing port 2, using 1 lanes
> [    3.324364] tegra-pcie 3000.pcie-controller: link 2 down, retrying
> [    3.534249] tegra-pcie 3000.pcie-controller: link 2 down, retrying
> [    3.744160] tegra-pcie 3000.pcie-controller: link 2 down, retrying
> [    3.751359] tegra-pcie 3000.pcie-controller: link 2 down, ignoring

(I see the same messages even without fixing the lane configuration,
exception for the first configuration message obviously prints something
different).

Are you testing with U-Boot, or using our binary bootloader? Upstream
code must be tested with U-Boot, to make sure it doesn't rely on any HW
programming performed by the bootloader.


From jason at lakedaemon.net  Wed Apr 10 12:48:05 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Wed, 10 Apr 2013 12:48:05 -0400
Subject: [PATCH RESEND v2 1/1] ARM Feroceon: fix kexec by setting
 outer_cache.inv_all
In-Reply-To: <51631BAF.40408@grapecom.com>
References: <51631B12.2010908@grapecom.com>
 <51631BAF.40408@grapecom.com>
Message-ID: <20130410164805.GA28693@titan.lakedaemon.net>

On Mon, Apr 08, 2013 at 10:34:07PM +0300, Elijah Ragozin wrote:
> On Feroceon the L2 cache becomes non-coherent with the CPU
> when the L1 caches are disabled. Thus the L2 needs to be invalidated
> after both L1 caches are disabled.
> 
> On kexec before the starting the code for relocation the kernel,
> the L1 caches are disabled in cpu_froc_fin (cpu_v7_proc_fin for Feroceon),
> but after L2 cache is never invalidated, because inv_all is not set
> in cache-feroceon-l2.c.
> So kernel relocation and decompression may has (and usually has) errors.
> Setting the function enables L2 invalidation and fixes the issue.
> 
> Signed-off-by: Illia Ragozin <illia.ragozin at grapecom.com>
> ---
>  arch/arm/mm/cache-feroceon-l2.c | 1 +
>  1 file changed, 1 insertion(+)

fwiw,

Acked-by: Jason Cooper <jason at lakedaemon.net>

Please put this in Russell King's patch tracker so he can pull it in.

thx,

Jason.


From sebastian.hesselbarth at gmail.com  Wed Apr 10 13:27:25 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Wed, 10 Apr 2013 19:27:25 +0200
Subject: [PATCH v7] clk: add si5351 i2c common clock driver
In-Reply-To: <14854575.YAd2OMKOy9@ganymedes>
References: <1365439617-18816-1-git-send-email-sebastian.hesselbarth@gmail.com>
 <1365586810-6752-1-git-send-email-sebastian.hesselbarth@gmail.com>
 <51653C3E.2020702@gmail.com> <14854575.YAd2OMKOy9@ganymedes>
Message-ID: <5165A0FD.5030308@gmail.com>

Hooray Google!

Thanks for removing plain text sending from gmail web-frontend.. *sigh*
Sorry for resending this, but HTML mails get rejected by linux mailing lists.

On 04/10/2013 04:48 PM, Michal Bachraty wrote:
> Hi Sebastian,
> This driver doesn't work for me. In my case, u-boot initializes si-5351 and
> power down unused clocks while booting kernel.  there is need for power up
> clocks as was in previous versions of your driver.
> See patch, whre the problem is fixed:
>
> @@ -992,6 +992,10 @@ static long si5351_clkout_round_rate(struct clk_hw *hw,
> unsigned long rate,
>   		} while (1);
>   	}
>   	rate = *parent_rate>>  rdiv;
> +	
> +	/* powerup clkout */
> +	si5351_set_bits(hwdata->drvdata, SI5351_CLK0_CTRL + hwdata->num,
> +			SI5351_CLK_POWERDOWN, 0);
>
>   	dev_dbg(&hwdata->drvdata->client->dev,
>   		"%s - %s: rdiv = %u, parent_rate = %lu, rate = %lu\n",
>
> With this lines, driver works well.

Hmm, is there any driver using the clock output? Does it clk_prepare_enable() the clock?
I tend not to mess with anything the bootloader or eeprom config left disabled. It works
for me, but here the driver will prepare/enable the clock prior use.

> Also,
>
>>> +==Example==
>>> +
>>> +/* 25MHz reference crystal */
>>> +ref25: ref25M {
>>> +	compatible = "fixed-clock";
>>> +	#clock-cells =<0>;
>>> +	clock-frequency =<25000000>;
>>> +};
>>> +
>>> +i2c-master-node {
>>> +
>>> +	/* Si5351a msop10 i2c clock generator */
>>> +	si5351a: clock-generator at 60 {
>>> +		compatible = "silabs,si5351a-msop";
>>> +		reg =<0x60>;
>>> +		#address-cells =<1>;
>>> +		#size-cells =<0>;
>>> +		#clock-cells =<1>;
>>> +
>>> +		/* connect xtal input to 25MHz reference */
>>> +		clocks =<&ref25>;
>>> +
>>> +		/* connect xtal input as source of pll0 and pll1 */
>>> +		silabs,pll-source =<0 0>,<1 0>;
>>> +
>>> +		/*
>>> +		 * overwrite clkout0 configuration with:
>>> +		 * - 8mA output drive strength
>>> +		 * - pll0 as clock source of multisynth0
>>> +		 * - multisynth0 as clock source of output divider
>>> +		 * - multisynth0 can change pll0
>>> +		 * - set initial clock frequency of 74.25MHz
>>> +		 */
>>> +		clkout0 {
>>> +			reg =<0>;
>>> +			silabs,drive-strength =<8>;
>>> +			silabs,multisynth-source =<0>;
>>> +			silabs,clock-source =<0>;
>>> +			silabs,pll-master;
>>> +			clock-frequency =<74250000>;
>>> +		};
>>> +
>>> +		/*
>>> +		 * overwrite clkout1 configuration with:
>>> +		 * - 4mA output drive strength
>>> +		 * - pll1 as clock source of multisynth1
>>> +		 * - multisynth1 as clock source of output divider
>>> +		 * - multisynth1 can change pll1
>>> +		 */
>>> +		clkout1 {
>>> +			reg =<1>;
>>> +			silabs,drive-strength =<4>;
>>> +			silabs,multisynth-source =<1>;
>>> +			silabs,clock-source =<0>;
>>> +			pll-master;
>>> +		};
>>> +
>   Is definition of pll-master in clkout1 correct? should not be silabs,pll-
> master ?

Good catch.

Sebastian


From swarren at wwwdotorg.org  Wed Apr 10 13:29:09 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Wed, 10 Apr 2013 11:29:09 -0600
Subject: [PATCH 10/18] ARM: tegra1: cpuidle: use init/exit common routine
In-Reply-To: <1365603743-5618-11-git-send-email-daniel.lezcano@linaro.org>
References: <1365603743-5618-1-git-send-email-daniel.lezcano@linaro.org>
 <1365603743-5618-11-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <5165A165.3000105@wwwdotorg.org>

On 04/10/2013 08:22 AM, Daniel Lezcano wrote:
> Subject: ARM: tegra1: cpuidle: use init/exit common routine

The tag there should be just ARM: tegra: - Tegra1 isn't something that's
supported upstream. Same comment for the other two Tegra patches.

> Remove the duplicated code and use the cpuidle common code for initialization.

Other than that, the 3 Tegra patches look reasonable assuming the
patches that implement the new common APIs are accepted, so the 3 Tegra
patches,

Acked-by: Stephen Warren <swarren at nvidia.com>


From swarren at wwwdotorg.org  Wed Apr 10 13:32:27 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Wed, 10 Apr 2013 11:32:27 -0600
Subject: Query on pinctrl usage for DT nodes
In-Reply-To: <CA+V-a8vwdCkyMqiynj5BodXbjwJ=e4qNb-29FhLweqbjc7DBQA@mail.gmail.com>
References: <CA+V-a8uiPwsAD--OHFAE=i2ed+-wbXm4p2deZXr92+Zv6GDS1w@mail.gmail.com>
 <515C5C76.3080009@wwwdotorg.org>
 <CA+V-a8t3wtP77DdeUoQHKMjAuWmV+ude+1J3UjJmMTqobgStjA@mail.gmail.com>
 <5162FD4A.1030909@wwwdotorg.org>
 <CA+V-a8vwdCkyMqiynj5BodXbjwJ=e4qNb-29FhLweqbjc7DBQA@mail.gmail.com>
Message-ID: <5165A22B.4070200@wwwdotorg.org>

On 04/10/2013 02:12 AM, Prabhakar Lad wrote:
...
> Following is the proposed fix/hack let me know if its OK.
> 
> Regards,
> --Prabhakar
> 
> ->>>>>>>>>>>>>>>>>>>
> 
> diff --git a/drivers/pinctrl/core.h b/drivers/pinctrl/core.h
> index ee72f1f..78fb42d 100644
> --- a/drivers/pinctrl/core.h
> +++ b/drivers/pinctrl/core.h
> @@ -46,6 +46,7 @@ struct pinctrl_dev {
>         struct pinctrl *p;
>         struct pinctrl_state *hog_default;
>         struct pinctrl_state *hog_sleep;
> +       bool bits_per_mux;

This clearly isn't correct; any change to solve this problem should only
touch the internals of the pinctrl-single driver, not the pinctrl core.


From swarren at wwwdotorg.org  Wed Apr 10 13:35:34 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Wed, 10 Apr 2013 11:35:34 -0600
Subject: [PATCH 1/2] ARM: boot/dts/Makefile: drop '\'
In-Reply-To: <1365585444-11520-1-git-send-email-plagnioj@jcrosoft.com>
References: <1365585444-11520-1-git-send-email-plagnioj@jcrosoft.com>
Message-ID: <5165A2E6.7010108@wwwdotorg.org>

On 04/10/2013 03:17 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:
> when adding multiple new platform this generate comflict

"When" and "conflict".

> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile

> -ifeq ($(CONFIG_OF),y)

> -targets += dtbs
> -targets += $(dtb-y)
> -endif
> -
> -# *.dtb used to be generated in the directory above. Clean out the
> -# old build results so people don't accidentally use them.
> -dtbs: $(addprefix $(obj)/, $(dtb-y))
> -	$(Q)rm -f $(obj)/../*.dtb
> -
> -clean-files := *.dtb

I'm not sure why those parts show up in the diff. I guess the -/+ lines
look the same though, so the result is fine. did line-endings change or
something?


From ezequiel.garcia at free-electrons.com  Wed Apr 10 13:37:42 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Wed, 10 Apr 2013 14:37:42 -0300
Subject: [PATCH v6 1/5] drivers: memory: Introduce Marvell EBU Device Bus
 driver
In-Reply-To: <20130410165750.GA6441@obsidianresearch.com>
References: <1365539181-29242-1-git-send-email-ezequiel.garcia@free-electrons.com>
 <1365539181-29242-2-git-send-email-ezequiel.garcia@free-electrons.com>
 <20130409203855.GA27797@obsidianresearch.com>
 <20130410101956.GA2250@localhost>
 <20130410165750.GA6441@obsidianresearch.com>
Message-ID: <20130410173740.GA2275@localhost>

Hi Jason,

On Wed, Apr 10, 2013 at 10:57:50AM -0600, Jason Gunthorpe wrote:
> On Wed, Apr 10, 2013 at 07:19:57AM -0300, Ezequiel Garcia wrote:
> > Hi Jason,
> > 
> > On Tue, Apr 09, 2013 at 02:38:55PM -0600, Jason Gunthorpe wrote:
> > > On Tue, Apr 09, 2013 at 05:26:17PM -0300, Ezequiel Garcia wrote:
> > > > +	/*
> > > > +	 * Since this is only part of the workaround,
> > > > +	 * we can do this dirty 'ranges' property parsing.
> > > > +	 * Of course, this will be removed once the address windows
> > > > +	 * are declared in the device tree.
> > > > +	 */
> > > > +	err = of_property_read_u32_array(node, "ranges", addr_region,
> > > > +					 ARRAY_SIZE(addr_region));
> > > 
> > > Oh, this is a dangerous way to parse ranges.. 
> > > 
> > > Try something like:
> > > 
> > > const __be32 *prop;
> > > u64 base;
> > > u64 size;
> > > 
> > > prop = of_get_property("ranges",&psize);
> > > if (prop == NULL || psize != of_n_addr_cells(node) + of_n_size_cells(node))
> > >    err;
> > > base = of_translate_address(node,prop);
> > > if (base == OF_BAD_ADDR)
> > >    err;
> > > size = of_read_number(prop + of_n_addr_cells(node),of_n_size_cells(node));
> > > 
> > 
> > Thanks for giving me these hints!
> 
> NP, the motivation for doing this properly is to support cases where
> p_addr_cells/addr_cells/size_cells is != 1, and to support cases where
> the parent bus address is not the CPU address. The proposed bindings
> for mbus will exercise both of these conditions..
> 
> > Following your suggestion, here's a working piece of the ranges parsing code,
> > how does this look?
> > 
> > const __be32 *ranges;
> > int addr_cells, p_addr_cells, size_cells;
> > int ranges_len, tuple_len;
> > u32 base, size;
> > 
> > p_addr_cells = of_n_addr_cells(node->parent);
> 
> I wonder if of_get_parent / of_node_put is technically needed here?
>

Yes, that sounds definitely better.

> > addr_cells = of_n_addr_cells(node);
> > size_cells = of_n_size_cells(node);
> > tuple_len = (p_addr_cells + addr_cells + size_cells) * sizeof(__be32);
> > 
> > ranges = of_get_property(node, "ranges", &ranges_len);
> > if (ranges == NULL || ranges_len != tuple_len)
> > 	return -EINVAL;
> > 
> > base = of_translate_address(node, ranges + addr_cells);
> > if (base == 0 || base == OF_BAD_ADDR)
> > 	return -EINVAL;
> 
> Why the check for base == 0?
> 

Well, when writing this code my first experiments where failing
(because the code was wrong) and I was getting base=0.
So I added this to catch that error.

Thinking it twice, it doesn't seem correct to check that.

> > size = of_read_number(ranges + addr_cells + p_addr_cells, size_cells);
> 
> Everything basically looks right. I definitely forgot the include the
> p_addr in my quick sample.
> 

Great, I'll send the v7, with these two fixes.

-- 
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com


From will.deacon at arm.com  Wed Apr 10 13:37:32 2013
From: will.deacon at arm.com (Will Deacon)
Date: Wed, 10 Apr 2013 18:37:32 +0100
Subject: [PATCH] documentation: iommu: add description of ARM System MMU
 binding
In-Reply-To: <5162F87A.7070409@codeaurora.org>
References: <1365094259-24847-1-git-send-email-will.deacon@arm.com>
 <515F37C1.4000109@codeaurora.org>
 <20130408092535.GA17476@mudshark.cambridge.arm.com>
 <5162F87A.7070409@codeaurora.org>
Message-ID: <20130410173732.GQ26992@mudshark.cambridge.arm.com>

On Mon, Apr 08, 2013 at 06:03:54PM +0100, Olav Haugan wrote:
> Hi Will,

Hello,

> > Generally, the StreamIDs are fixed in hardware (as a function of various AXI
> > bits -- see the SMMU integration guide) and cannot be set by software.
> > Furthermore, when the StreamIDs have an implicit effect on IOMMU domain
> > configuration, since stream-matching may not be always be able to identify a
> > master uniquely.
> 
> Let me clarify what I mean by "our SMMU driver programs the SMMU SIDs".
> What I meant to say is that our SMMU driver programs the SID into the
> Stream Match Register (SMR) to route the transactions to the correct
> context bank based on the SID.

Ok, but then how does that interact with the IOMMU API in Linux? e.g. if a
client asks for an iova <-> pa mapping on a device, then you need to lookup
the StreamIDs for that device, no?

> > This really looks specific to your implementation/integration and I can't
> > see that we'd want this in the binding to be honest. It would be good to
> > have PMU support in the future, but I've not thought about that part yet.
> 
> Yes, some of this is specific to our implementation. However, the
> properties related to regulators and PMU are not specific I believe. How
> do you do handle regulators?

As I said, I'm just using a software model more the moment, so no clocks or
regulators. We can add these later, since Linux has good support for things
like that already.

> >> - List of sub nodes, one for each of the translation context banks
> >> supported.
> >>   Each sub node has the following required properties:
> >>
> >>   - reg : offset and length of the register set for the context bank.
> > 
> > Why do you need this? The structure of the context banks is well defined by
> > the SMMU architecture.
> 
> Since we specify the context banks as children of the IOMMU we specify
> the address of each node. I believe you should be specifying the "reg"
> property for the nodes when you do this.

It's completely redundant information though!

> >>   - interrupts : should contain the context bank interrupt.
> >>   - qcom,iommu-ctx-sids : List of stream identifiers associated with
> >> this translation context.
> > 
> > StreamIDs aren't statically associated with a translation context. Why do
> > you put them here? Also, how do this interact with stream matching?
> 
> We put the StreamIDs in the context bank to tell our driver that these
> StreamIDs should be programmed into the Stream Match Register (SMR) to
> route the transactions bearing these StreamIDs to this context bank. We
> don't really change the SID2CB mapping during run-time. It is set during
> compile time.

Again, I'm struggling to see how this interfaces to the more general-purpose
IOMMU API.

> >> Optional sub-node properties:
> >>    - qcom,secure-context : boolean indicating that a context is secure
> >>  and programmed by the secure environment.
> > 
> > Why does Linux care about this?
> 
> Linux cares about this because if we are doing content protection using
> one of the context banks then the context bank is programmed by the
> secure environment and not accessible/programmable by the HLOS.

Why can't the secure world just hide those context banks by using
SMMU_SCR1.NSNUMCBO?

> > I'd really rather start off small, and describe precisely what we need to
> > get architecturally-compliant SMMUs off the ground. Then, as the code grows
> > to use more features (PM, PMU, ...) then we can extend the binding.
> > Otherwise, we paint ourselves into a corner with the binding before we've
> > developed any driver code.
> 
> Sure, I did not mean to add implementation specific stuff to upstream
> bindings. Does it makes sense to you thought the way we modeled context
> banks as child nodes?

Not really, no. It seems to configure everything up-front, which makes
dynamic use of the IOMMU difficult afaict. It may suit your use-case (as you
say, you even set up the mappings at compile-time) but it's not especially
general.

Will


From swarren at wwwdotorg.org  Wed Apr 10 13:39:10 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Wed, 10 Apr 2013 11:39:10 -0600
Subject: [PATCH 2/2] ARM: at91: move dts to subdir
In-Reply-To: <1365585444-11520-2-git-send-email-plagnioj@jcrosoft.com>
References: <1365585444-11520-1-git-send-email-plagnioj@jcrosoft.com>
 <1365585444-11520-2-git-send-email-plagnioj@jcrosoft.com>
Message-ID: <5165A3BE.4070001@wwwdotorg.org>

On 04/10/2013 03:17 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>

A patch description might be nice.

This seems like a nice cleanup to keep the dts directory organized.
However, it does mean that the *.dtb files get moved again. I know that
when they moved from boot/ to boot/dts/ in 3.9 (or 3.8?) there were some
complaints that this made it difficult to write scripts that find the
built DTB and copy it somewhere. This change would cause the exact same
problem again.

Perhaps it's time to create an install_dtbs target to solve this problem?


From nm at ti.com  Wed Apr 10 13:39:21 2013
From: nm at ti.com (Nishanth Menon)
Date: Wed, 10 Apr 2013 12:39:21 -0500
Subject: [RFC][PATCH 1/2] ARM: OMAP4: clock: Add device tree support for
 AUXCLKs
In-Reply-To: <5165453E.6090503@ti.com>
References: <515D2D30.3000306@ti.com> <20130404164137.GH10155@atomide.com>
 <515EA9E3.1010409@ti.com> <20130405155851.GA10155@atomide.com>
 <5163E589.1040809@ti.com> <20130409164928.GL10155@atomide.com>
 <20130409174319.GP10155@atomide.com> <20130409204900.GA8815@kahuna>
 <20130410080630.14359.68178@quantum> <5165453E.6090503@ti.com>
Message-ID: <20130410173921.GA31017@kahuna>

On 13:55-20130410, Roger Quadros wrote:
> On 04/10/2013 11:06 AM, Mike Turquette wrote:
> > Quoting Nishanth Menon (2013-04-09 13:49:00)
> >> On 10:43-20130409, Tony Lindgren wrote:
> >>> * Tony Lindgren <tony at atomide.com> [130409 09:54]:
> >>>> * Roger Quadros <rogerq at ti.com> [130409 03:00]:
> >>>>> On 04/05/2013 06:58 PM, Tony Lindgren wrote:
> >>>>>>
> >>>>>> Can't you just use the clock name there to get it?
> >>>>>
> >>>>> In device tree we don't pass around clock names. You can either get
> >>>>> a phandle or an index to the clock.
> >>>>>
> >>>>> e.g. Documentation/devicetree/bindings/clock/imx31-clock.txt
> >>>>
> >>>> Yes I understand that. But the driver/clock/omap driver can just
> >>>> remap the DT device initially so the board specific clock is
> >>>> found from the clock alias table. Basically initially a passthrough
> >>>> driver that can be enhanced to parse DT clock bindings and load
> >>>> data from /lib/firmware.
> >>>
> >>> Actually probably the driver/clock/omap can even do even less
> >>> initially. There probably even no need to remap clocks there.
> >>>
> >>> As long as the DT clock driver understands that a board specific
> >>> auxclk is specified in the DT it can just call clk_add_alias() so
> >>> the driver will get the right auxclk from cclock44xx_data.c.
> >>>
> >>> Then other features can be added later on like to allocate a
> >>> clock entirely based on the binding etc.
> >> I did try to have an implementation for cpufreq using clock nodes.
> >> unfortunately, device tree wont let me have arguments of strings :(
> >> So, I am unable to do clock = <&clk mpu_dpll>;
> >> instead, I am forced to do clock = <&clk 249>;
> >>
> > 
> > See http://article.gmane.org/gmane.linux.ports.arm.kernel/229034
> > 
> 
> Awesome. Thanks for pointing this out Mike.
> 
> Now all we need to do is create a named define for each clock index in the
> header file.
Approach #3: Thanks to Tony for collaborating on this:
Works for cpufreq-cpu0 - additional patches:
http://pastebin.com/GHnTRVJf, http://pastebin.com/FZS89J6L (tested on
beagleXM)
Work for USB - http://pastebin.com/aJpDnXci - thanks Roger for testing
this.
Details in the patch below (Tony, I have added you as collaborator for
helping in getting this working-clk_add_alias was'nt needed in the
internal patch discussion we had - I have taken a bit of freedom in
adding your contributions to the patch below)

Folks, this does seem to be the best compromise we can achieve at this
point in time. feedback on this approach is much appreciated - if folks
are ok, I can post this as an formal patch series.

>From 130a41821bf57081ca45ef654029175d173135e6 Mon Sep 17 00:00:00 2001
From: Nishanth Menon <nm at ti.com>
Date: Tue, 9 Apr 2013 19:26:40 -0500
Subject: [RFC PATCH] clk: OMAP: introduce device tree binding to kernel clock
 data

OMAP clock data is located in arch/arm/mach-omap2/cclockXYZ_data.c.
However, this presents an obstacle for using these clock nodes in
Device Tree definitions. There are many possible approaches to this
problem as discussed in the following thread:
http://marc.info/?t=136370325600009&r=1&w=2
Highlights of the options:
a) device specific clk_add_alias:
	cons: driver handling required
b) using an generic clk node and indexing to reach the clock required.
   This is similar in approach taken by tegra and few other platforms.
   example clock = <&clk 5>;
   cons: potential to have mismatches in indexed table and associated
   dtb data. In addition, managing continued documentation in bindings
   as clock indexing increases. Even though readability angle could be
   improved by using preprocessing of DT using macros, indexed approach
   is inherently risky from cases like the following:
   clk indexes in kernel:
   1 - mpu_dpll
   2 - aux_clk1
   3 - core_clk
   DT entry for peripheral x uses <&clk 2>, kernel updates to:
   1 - mpu_dpll
   2 - per_dpll
   3 - aux_clk1
   4 - core_clk
   using the old dtb(or dts missing an update), on new kernel which has
   updated indices will result in per_dpll now controlled for peripheral
   X without warning or any potential error detection and warning.

   Even though we can claim this is user error, such errors are hard to
   track down and fix.

An alternate approach introduced here is to introduce device tree bindings
corresponding to the clock nodes required in DT definition for SoC which
automatically maps back to the definitions in cclockXYZ_data.c.

The driver introduced here to do this mapping will eventually be the
place where the clock handling will migrate to. We need to consider this
angle as well so that the solution will be an valid transition point for
moving the clock data out of kernel image (into device tree or firmware load
etc..).

Overall strategy introduced here is simple: an clock node described in
device tree blob is used to identify the exact clock provided in the SoC
specific data. This is then linked back using of_clk_add_provider to the
device node to be accessible by of_clk_get.

Based on discussion contributions from Roger Quadros, Grygorii Strashko
and others.

[tony at atomide.com: co-developed]
Signed-off-by: Tony Lindgren <tony at atomide.com>
Signed-off-by: Nishanth Menon <nm at ti.com>
---
 .../devicetree/bindings/clock/omap-clock.txt       |   40 +++++++++
 drivers/clk/Makefile                               |    1 +
 drivers/clk/omap/Makefile                          |    1 +
 drivers/clk/omap/clk.c                             |   94 ++++++++++++++++++++
 4 files changed, 136 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/omap-clock.txt
 create mode 100644 drivers/clk/omap/Makefile
 create mode 100644 drivers/clk/omap/clk.c

diff --git a/Documentation/devicetree/bindings/clock/omap-clock.txt b/Documentation/devicetree/bindings/clock/omap-clock.txt
new file mode 100644
index 0000000..07e3ff8
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/omap-clock.txt
@@ -0,0 +1,40 @@
+Device Tree Clock bindings for Texas Instrument's OMAP compatible platforms
+
+This binding is a work-in-progress, and meant to be stage #1 of transitioning
+OMAP clock data out of kernel image.
+
+This binding uses the common clock binding[1].
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties:
+- compatible : shall be "ti,omap-clock"
+- #clock-cells : from common clock binding; shall be set to 0.
+NOTE:
+node name should map to clock database in arch/arm/mach-omap2/cclock<SoC>_data.c
+Since all clocks are described with _ck, the node name is optimized to drop the
+usage of _ck. For example, a clock called dpll1_ck will be defined as dpll1.
+
+Example #1: describing clock node for CPU on OMAP34xx platform:
+Ref: arch/arm/mach-omap2/cclock3xxx_data.c
+describes the CPU clock to be as follows
+	CLK(NULL,	"dpll1_ck",	&dpll1_ck,	CK_3XXX),
+Corresponding binding will be:
+	dpll1: dpll1 {
+		#clock-cells = <0>;
+		compatible = "ti,omap-clock";
+	};
+And it's usage will be:
+		clocks = <&dpll1>;
+
+Example #2: describing clock node for auxilary clock #3 on OMAP443x platform:
+Ref: arch/arm/mach-omap2/cclock44xx_data.c
+describes the auxclk3 clock to be as follows:
+	CLK(NULL,	"auxclk3_ck",	&auxclk3_ck,	CK_443X),
+Corresponding binding will be:
+	auxclk3: auxclk3 {
+		#clock-cells = <1>;
+		compatible = "ti,omap-clock";
+	};
+And it's usage will be:
+	clocks = <&auxclk3>;
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 300d477..a0209d7 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -27,6 +27,7 @@ obj-$(CONFIG_ARCH_U8500)	+= ux500/
 obj-$(CONFIG_ARCH_VT8500)	+= clk-vt8500.o
 obj-$(CONFIG_ARCH_ZYNQ)		+= clk-zynq.o
 obj-$(CONFIG_ARCH_TEGRA)	+= tegra/
+obj-$(CONFIG_ARCH_OMAP)		+= omap/
 
 obj-$(CONFIG_X86)		+= x86/
 
diff --git a/drivers/clk/omap/Makefile b/drivers/clk/omap/Makefile
new file mode 100644
index 0000000..8195931
--- /dev/null
+++ b/drivers/clk/omap/Makefile
@@ -0,0 +1 @@
+obj-y					+= clk.o
diff --git a/drivers/clk/omap/clk.c b/drivers/clk/omap/clk.c
new file mode 100644
index 0000000..63a4cce
--- /dev/null
+++ b/drivers/clk/omap/clk.c
@@ -0,0 +1,94 @@
+/*
+ * Texas Instruments OMAP Clock driver
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ *	Nishanth Menon
+ *	Tony Lindgren <tony at atomide.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.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/clkdev.h>
+#include <linux/clk-private.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include <linux/string.h>
+
+static const struct of_device_id omap_clk_of_match[] = {
+	{.compatible = "ti,omap-clock",},
+	{},
+};
+
+MODULE_DEVICE_TABLE(of, omap_clk_of_match);
+
+/**
+ * omap_clk_probe() - create link from DT definition to clock data
+ * @pdev:	device node
+ *
+ * REVISIT: We are now assuming the following:
+ * 1. omap clock names end with _ck
+ * 2. omap clocks don't get removed
+ */
+static int omap_clk_probe(struct platform_device *pdev)
+{
+	struct clk *clk;
+	int res;
+
+	const struct of_device_id *match;
+	struct device_node *np = pdev->dev.of_node;
+	char clk_name[32];
+
+	match = of_match_device(omap_clk_of_match, &pdev->dev);
+
+	/* Set up things so consumer can call clk_get() with name */
+	snprintf(clk_name, 32, "%s_ck", np->name);
+	clk = clk_get(NULL, clk_name);
+	if (IS_ERR(clk)) {
+		res = PTR_ERR(clk);
+		dev_err(&pdev->dev, "could not get clock %s (%d)\n",
+			clk_name, res);
+		goto out;
+	}
+
+	/* This allows the driver to of_clk_get() */
+	res = of_clk_add_provider(np, of_clk_src_simple_get, clk);
+	if (res)
+		dev_err(&pdev->dev, "could not add provider for %s (%d)\n",
+			clk_name, res);
+
+	clk_put(clk);
+out:
+	return res;
+}
+
+MODULE_ALIAS("platform:omap_clk");
+
+/* We assume here that OMAP clocks will not be removed */
+static struct platform_driver omap_clk_driver = {
+	.probe = omap_clk_probe,
+	.driver = {
+		   .name = "omap_clk",
+		   .owner = THIS_MODULE,
+		   .of_match_table = of_match_ptr(omap_clk_of_match),
+		   },
+};
+
+static int __init omap_clk_init(void)
+{
+	return platform_driver_register(&omap_clk_driver);
+}
+
+arch_initcall(omap_clk_init);
+
+MODULE_DESCRIPTION("OMAP Clock driver");
+MODULE_AUTHOR("Texas Instruments Inc.");
+MODULE_LICENSE("GPL v2");
-- 
1.7.9.5

-- 
Regards,
Nishanth Menon


From nico at fluxnic.net  Wed Apr 10 13:30:35 2013
From: nico at fluxnic.net (Nicolas Pitre)
Date: Wed, 10 Apr 2013 13:30:35 -0400 (EDT)
Subject: Removal of NWFPE in its entirety, and VFP emulation code
In-Reply-To: <20130410104002.GF14496@n2100.arm.linux.org.uk>
References: <20130410104002.GF14496@n2100.arm.linux.org.uk>
Message-ID: <alpine.LFD.2.03.1304101307280.17375@syhkavp.arg>

On Wed, 10 Apr 2013, Russell King - ARM Linux wrote:

> I have just committed a patch to remove the arch/arm/nwfpe code from
> the kernel, and the VFP code emulating the FP operations.
> 
> This I have done after it has been brought to my attention by the OSADL's
> GPL-violations project that the license for the softfloat library is
> incompatible with GPLv2.  This is because the FSF have ruled that
> indemnification clauses consitute an "additional restriction" which is
> incompatible with the GPLv2 section 6.  NWFPE contains the softfloat
> library, and VFP's emulation code is a derivative of softfloat.
> 
> This will be very disruptive for ARMv4 and ARMv5 CPUs, which will no
> longer be able to run userspace with NWFPE support removed.  A possible
> solution there is to resurrect FASTFPE support and merge that into
> mainline in place of NWFPE.  FASTFPE's hooks are all present in the
> kernel, and it should just be a case of adding the FASTFPE code.
> However, FASTFPE is probably lacking GDB and signal stack support.
> (FastFPE's per-thread workspace is different from NWFPE.)

A point worth mentioning is the EABI availability since 2006 which moved 
away from FPA completely. A soft-float library in user space is used in 
that case.  Major ARM binary producers including all ARM distros moved 
to EABI with user space soft-float since then as it is order of 
magnitude faster than FPA emulation.  So 99.99% of ARMv4 and ARMv5 users 
are unlikely to be affected.

So another option here might imply deprecating OABI support entirely, 
given that it is useless without FPA and people keeping current with the 
latest kernel are very likely to already use EABI user space.


Nicolas


From olof at lixom.net  Wed Apr 10 13:47:32 2013
From: olof at lixom.net (Olof Johansson)
Date: Wed, 10 Apr 2013 10:47:32 -0700
Subject: [PATCH 2/2] ARM: at91: move dts to subdir
In-Reply-To: <5165A3BE.4070001@wwwdotorg.org>
References: <1365585444-11520-1-git-send-email-plagnioj@jcrosoft.com>
 <1365585444-11520-2-git-send-email-plagnioj@jcrosoft.com>
 <5165A3BE.4070001@wwwdotorg.org>
Message-ID: <CAOesGMgu5reWnhYGiDTM+92znRpx7R1vJT1DmVOOyQrpSW5C+w@mail.gmail.com>

On Wed, Apr 10, 2013 at 10:39 AM, Stephen Warren <swarren at wwwdotorg.org> wrote:
> On 04/10/2013 03:17 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:
>> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
>
> A patch description might be nice.
>
> This seems like a nice cleanup to keep the dts directory organized.
> However, it does mean that the *.dtb files get moved again. I know that
> when they moved from boot/ to boot/dts/ in 3.9 (or 3.8?) there were some
> complaints that this made it difficult to write scripts that find the
> built DTB and copy it somewhere. This change would cause the exact same
> problem again.
>
> Perhaps it's time to create an install_dtbs target to solve this problem?

Yes, that's a prerequisite in my opinion.

Also, I said in the previous thread that I want to hold this off for a
couple of releases since it's pure churn. So I'm not interested in
picking this up until 3.12. install_dtbs would be great to see for
3.11 though.


-Olof


From csd at broadcom.com  Wed Apr 10 13:33:37 2013
From: csd at broadcom.com (Christian Daudt)
Date: Wed, 10 Apr 2013 10:33:37 -0700
Subject: [GIT PULL] ARM: bcm281xx firmware tags
In-Reply-To: <201303061128.57127.arnd@arndb.de>
References: <1362451632-18806-1-git-send-email-csd@broadcom.com>
 <201303060631.03782.arnd@arndb.de> <5136F816.2070909@broadcom.com>
 <201303061128.57127.arnd@arndb.de>
Message-ID: <5165A271.6060407@broadcom.com>

Hi Arnd, Olof,
  Please pull the branch below - it contains the BCM281xx l2 cache 
enabling code.

  Thanks,
    csd


The following changes since commit 07961ac7c0ee8b546658717034fe692fd12eefa9:

   Linux 3.9-rc5 (2013-03-31 15:12:43 -0700)

are available in the git repository at:

   git://github.com/broadcom/bcm11351.git tags/fw-for-3.10

for you to fetch changes up to 7f6c62e2695bcb1547afdeb4ad3bcdf8c610be2c:

   ARM: bcm281xx: Add DT support for SMC handler (2013-04-09 09:21:59 -0700)

----------------------------------------------------------------
l2cache driver for bcm281xx SoC

----------------------------------------------------------------
Christian Daudt (2):
       ARM: bcm281xx: Add L2 cache enable code
       ARM: bcm281xx: Add DT support for SMC handler

  Documentation/devicetree/bindings/misc/smc.txt |   14 +++++++++++
  arch/arm/boot/dts/bcm11351.dtsi                |    5 ++++
  arch/arm/mach-bcm/Makefile                     |    4 +++-
  arch/arm/mach-bcm/bcm_kona_smc.c               |  118 
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
  arch/arm/mach-bcm/bcm_kona_smc.h               |   80 
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
  arch/arm/mach-bcm/bcm_kona_smc_asm.S           |   41 
++++++++++++++++++++++++++++++++
  arch/arm/mach-bcm/board_bcm.c                  |   23 ++++++++++++++++++
  7 files changed, 284 insertions(+), 1 deletion(-)
  create mode 100644 Documentation/devicetree/bindings/misc/smc.txt
  create mode 100644 arch/arm/mach-bcm/bcm_kona_smc.c
  create mode 100644 arch/arm/mach-bcm/bcm_kona_smc.h
  create mode 100644 arch/arm/mach-bcm/bcm_kona_smc_asm.S




From plagnioj at jcrosoft.com  Wed Apr 10 13:44:25 2013
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Wed, 10 Apr 2013 19:44:25 +0200
Subject: [PATCH 2/2] ARM: at91: move dts to subdir
In-Reply-To: <5165A3BE.4070001@wwwdotorg.org>
References: <1365585444-11520-1-git-send-email-plagnioj@jcrosoft.com>
 <1365585444-11520-2-git-send-email-plagnioj@jcrosoft.com>
 <5165A3BE.4070001@wwwdotorg.org>
Message-ID: <20130410174425.GA20693@game.jcrosoft.org>

On 11:39 Wed 10 Apr     , Stephen Warren wrote:
> On 04/10/2013 03:17 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
> 
> A patch description might be nice.
> 
> This seems like a nice cleanup to keep the dts directory organized.
yeah I was really not a fan on the prefix stuff
> However, it does mean that the *.dtb files get moved again. I know that
> when they moved from boot/ to boot/dts/ in 3.9 (or 3.8?) there were some
> complaints that this made it difficult to write scripts that find the
> built DTB and copy it somewhere. This change would cause the exact same
> problem again.
yes this will move the dtb location to the subdir

> 
> Perhaps it's time to create an install_dtbs target to solve this problem?

I think about it too but was not sure if it will be usefull
as you may end with all the mach-xxx dtb generated and on embedded system you
do not want all of them on contrary on Ubuntu & co

I was also think to make it more generic so move the code to Kbuild
so any arch can use it


From olof at lixom.net  Wed Apr 10 13:48:38 2013
From: olof at lixom.net (Olof Johansson)
Date: Wed, 10 Apr 2013 10:48:38 -0700
Subject: [PATCH 1/2] ARM: boot/dts/Makefile: drop '\'
In-Reply-To: <5165A2E6.7010108@wwwdotorg.org>
References: <1365585444-11520-1-git-send-email-plagnioj@jcrosoft.com>
 <5165A2E6.7010108@wwwdotorg.org>
Message-ID: <CAOesGMhcT+0X9pFx7m2TVFFHAbnh443fqEgfY3zCvn9H04No5w@mail.gmail.com>

On Wed, Apr 10, 2013 at 10:35 AM, Stephen Warren <swarren at wwwdotorg.org> wrote:
> On 04/10/2013 03:17 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:
>> when adding multiple new platform this generate comflict
>
> "When" and "conflict".
>
>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>
>> -ifeq ($(CONFIG_OF),y)
>
>> -targets += dtbs
>> -targets += $(dtb-y)
>> -endif
>> -
>> -# *.dtb used to be generated in the directory above. Clean out the
>> -# old build results so people don't accidentally use them.
>> -dtbs: $(addprefix $(obj)/, $(dtb-y))
>> -     $(Q)rm -f $(obj)/../*.dtb
>> -
>> -clean-files := *.dtb
>
> I'm not sure why those parts show up in the diff. I guess the -/+ lines
> look the same though, so the result is fine. did line-endings change or
> something?

There's no point in picking up this patch now if the move to
directories will happen in a release or two, it's again pure churn. We
can live with the conflicts for another release.


-Olof


From daniel.lezcano at linaro.org  Wed Apr 10 14:02:31 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Wed, 10 Apr 2013 20:02:31 +0200
Subject: [PATCH 05/18] cpuidle: make a single register function for all
In-Reply-To: <20130410170457.GL13524@lunn.ch>
References: <1365603743-5618-1-git-send-email-daniel.lezcano@linaro.org>
 <1365603743-5618-6-git-send-email-daniel.lezcano@linaro.org>
 <20130410170457.GL13524@lunn.ch>
Message-ID: <5165A937.70705@linaro.org>

On 04/10/2013 07:04 PM, Andrew Lunn wrote:
>> +int cpuidle_register(struct cpuidle_driver *drv,
>> +		     const struct cpumask *const coupled_cpus)
>> +{
>> +	int ret, cpu;
>> +	struct cpuidle_device *device;
>> +
>> +	ret = cpuidle_register_driver(drv);
>> +	if (ret) {
>> +		printk(KERN_ERR "failed to register cpuidle driver\n");
>> +		return ret;
>> +	}
>> +
>> +	for_each_possible_cpu(cpu) {
>> +		device = &per_cpu(cpuidle_dev, cpu);
>> +		device->cpu = cpu;
>> +#ifdef CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED
>> +		device->coupled_cpus = *coupled_cpus;
>> +#endif
> 
> At least the kirkwood and the calxeda driver set 
> 
>    device->state_count
> 
> which you don't appear to do. cpuidle_add_state_sysfs() and
> cpuidle_remove_state_sysfs() use this. Is it now being set somewhere
> else?

Yes, in cpuidle_enable_device called from cpuidle_register_device:


int cpuidle_enable_device(struct cpuidle_device *dev)
{
	...

        if (!dev->state_count)
                dev->state_count = drv->state_count;

	...
}

-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From daniel.lezcano at linaro.org  Wed Apr 10 14:04:22 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Wed, 10 Apr 2013 20:04:22 +0200
Subject: [PATCH 05/18] cpuidle: make a single register function for all
In-Reply-To: <20130410165509.GK13524@lunn.ch>
References: <1365603743-5618-1-git-send-email-daniel.lezcano@linaro.org>
 <1365603743-5618-6-git-send-email-daniel.lezcano@linaro.org>
 <20130410165509.GK13524@lunn.ch>
Message-ID: <5165A9A6.70905@linaro.org>

On 04/10/2013 06:55 PM, Andrew Lunn wrote:
>> +/**
>> + * cpuidle_register: registers the driver and the cpu devices with the
>> + * coupled_cpus passed as parameter. This function is used for all common
>> + * initialization pattern there are in the arch specific drivers. The
>> + * devices is globally defined in this file.
>> + *
>> + * @drv         : a valid pointer to a struct cpuidle_driver
>> + * @coupled_cpus: a cpumask for the coupled states
>> + *
>> + * Returns 0 on success, < 0 otherwise
>> + */
>> +int cpuidle_register(struct cpuidle_driver *drv,
>> +		     const struct cpumask *const coupled_cpus)
>> +{
>> +	int ret, cpu;
>> +	struct cpuidle_device *device;
>> +
>> +	ret = cpuidle_register_driver(drv);
>> +	if (ret) {
>> +		printk(KERN_ERR "failed to register cpuidle driver\n");
> 
> pr_err()

Ok.

>> +		return ret;
>> +	}
>> +
>> +	for_each_possible_cpu(cpu) {
>> +		device = &per_cpu(cpuidle_dev, cpu);
>> +		device->cpu = cpu;
>> +#ifdef CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED
>> +		device->coupled_cpus = *coupled_cpus;
>> +#endif
>> +		ret = cpuidle_register_device(device);
>> +		if (!ret)
>> +			continue;
>> +
>> +		printk(KERN_ERR "Failed to register cpuidle "
>> +		       "device for cpu%d\n", cpu);
> 
> pr_err() and don't split the message over two lines, it makes it
> harder for somebody to find with
> 
> grep -r "Failed to register cpuidle device for cpu" *

Ok if the line length is under 80 chars.

>> +		cpuidle_unregister(drv);
>> +		break;
>> +	}
>> +
>> +	return 0;
> 
> You should return an error code, so that the caller can also return an
> error code. If you look at cpuidle-kirkwood and cpuidle-calxeda, and
> maybe others, if the registration fails, the probe function returns an
> error code, as it should. With your change, its always going to return
> 0, even if it fails.

Right, right :)

it should be 'return ret;'

Thanks for pointing this.

  -- Daniel


-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From daniel.lezcano at linaro.org  Wed Apr 10 14:05:25 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Wed, 10 Apr 2013 20:05:25 +0200
Subject: [PATCH 10/18] ARM: tegra1: cpuidle: use init/exit common routine
In-Reply-To: <5165A165.3000105@wwwdotorg.org>
References: <1365603743-5618-1-git-send-email-daniel.lezcano@linaro.org>
 <1365603743-5618-11-git-send-email-daniel.lezcano@linaro.org>
 <5165A165.3000105@wwwdotorg.org>
Message-ID: <5165A9E5.1070107@linaro.org>

On 04/10/2013 07:29 PM, Stephen Warren wrote:
> On 04/10/2013 08:22 AM, Daniel Lezcano wrote:
>> Subject: ARM: tegra1: cpuidle: use init/exit common routine
> 
> The tag there should be just ARM: tegra: - Tegra1 isn't something that's
> supported upstream. Same comment for the other two Tegra patches.

Ok.

>> Remove the duplicated code and use the cpuidle common code for initialization.
> 
> Other than that, the 3 Tegra patches look reasonable assuming the
> patches that implement the new common APIs are accepted, so the 3 Tegra
> patches,
> 
> Acked-by: Stephen Warren <swarren at nvidia.com>

Thanks for review

  -- Daniel

-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From linus.walleij at linaro.org  Wed Apr 10 14:12:54 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Wed, 10 Apr 2013 20:12:54 +0200
Subject: [PATCH 3/5] gpio/omap: Add DT support to GPIO driver
In-Reply-To: <5155C902.7080207@wwwdotorg.org>
References: <1329321854-24490-1-git-send-email-b-cousson@ti.com>
 <1329321854-24490-4-git-send-email-b-cousson@ti.com>
 <4F44FA56.7020000@gmail.com> <4F44FC37.2000701@ti.com>
 <4F452484.5080503@gmail.com>
 <74CDBE0F657A3D45AFBB94109FB122FF17BD8BC6C1@HQMAIL01.nvidia.com>
 <4F47AD08.4030504@ti.com>
 <CAAwP0s0cB368R2mtbJpTZJreR-5GSRLfxC+8DJLo5nw3_OwBuA@mail.gmail.com>
 <512D39DA.7020306@ti.com> <512D3AB1.1080202@wwwdotorg.org>
 <512D3EC2.6050408@ti.com> <20130302200524.D230F3E1571@localhost>
 <51391F41.5000303@ti.com>
 <CAAwP0s1CFRO-rf==p5sYs1n0gigMif7wuT8Yv0N_iLUDMrtcOg@mail.gmail.com>
 <CACRpkdYHj-rEF3Rk_CWnmmMw_Amr7m8SgQ=-2zsDYuLeuu3azw@mail.gmail.com>
 <514C79E1.4090106@wwwdotorg.org> <514CE0AB.6060207@ti.com>
 <CACRpkdZmv-rAoKSQYpkHHSMzKJOn5TixVW_P3=m7ZNagBYCUPw@mail.gmail.com>
 <515319D5.20105@wwwdotorg.org>
 <CACRpkdYXVLgCz1Tyu-Ls2V2OTc4R3cGNJhfQJB6Hiz_K9dkZYQ@mail.gmail.com>
 <5155C902.7080207@wwwdotorg.org>
Message-ID: <CACRpkdYbs4-uudpRUY8e+7icYYkZrfM0kReP3pLL5DMiURJ4dg@mail.gmail.com>

On Fri, Mar 29, 2013 at 6:01 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
> On 03/27/2013 02:55 PM, Linus Walleij wrote:
>> On Wed, Mar 27, 2013 at 5:09 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
>>
>> This is the case for some SMSC911x clients like the snowball
>> routing it to a GPIO, whereas I think the RealView and Integrator/CP
>> has a dedicated IRQ line for it on the FPGA so it's a good example.
>>
>> In such cases the right thing to do is for the platform
>> code populating the platform data with the int irq field, or device tree
>> core, or whatever piece of code that knows about
>> the actual GPIO shall start from the GPIO, request it and
>> then convert it to an IRQ.
>
> So board code could easily do that; plenty of opportunity to put
> whatever custom code is needed right there.
>
> For DT core code to do that, we'd need some alternative way of
> specifying interrupts. That would change the DT bindings for interrupts.
> I don't think we can do that...

Sorry, I'm probably not knowledgeable about DT to understand this.
The information for what GPIO corresponds to what IRQ is
present in the device tree, is it not?

If the information is there, whether to convert from IRQ to GPIO
or from GPIO to IRQ is a technicality and any order should be
feasible in some way?

I just can't get the necessity to do it one way preferred over the
other through my head, sorry...

>> If it seems like identical boilerplate in every machine we can
>> simply centralize it to gpiolib. Something like
>>
>> int gpio_add_single_irq_resource(struct platform_device *pdev, int
>> gpio, unsigned flags)
> ... [code to convert GPIO to IRQ and create IORESOURCE_IRQ from it]
>
>> int gpio_populate_irq_resource(struct platform_device *pdev, int gpio,
>>                               unsigned flags, struct resource *r)
> ... [code to create IORESOURCE_IRQ from the IRQ]
>
> ...
>> gpio_populate_irq_resource(&ethernet, 17,
>>      IORESOURCE_IRQ_HIGHEDGE, &ethernet_res[1]);
>> platform_device_register(&ethernet);
>>
>> That populates the device with the single GPIO IRQ from
>> the GPIO number in a smooth way.
>>
>> Of course it has to be done after the GPIO driver is up
>> and running so may require some other refactoring,
>> but it should work.
>
> That latter issue also somewhat scuppers this approach; then you have to
> somehow run a bunch of your board file code inter-mixed with various
> driver probe() calls. That will quickly get nasy.

No, just use a module_init() for the above code in the board
file and it will defer just like any other initcall.

> And it doesn't address how the DT core will know when to call
> gpio_add_single_irq_resource() vs. gpio_populate_irq_resource() without
> changing the DT binding for interrupts.

Is it not possible to do this in
drivers/gpio/gpiolib-of.c: of_gpiochip_add(), if the DT *know*
which GPIOs will be used as plain IRQs? That is the point with
the gpio hogs I talk about ...

GPIO hogs would hog input pins here and immediately
call gpio_to_irq() on them, and from that point on they can
only be used for input, and only for generating IRQs.

>>> And then, given that irq_to_gpio() isn't semantically possible, there's
>>> no way for the driver to be able to gpio_request() anything, since it
>>> doesn't, can't, and shouldn't know whether there is in fact any GPIO ID
>>> that it should request, let alone what that GPIO ID is.
>>
>> That's cool. The driver does not have to know the IRQ is backed by a
>> GPIO, but somewhere in the system something should know this.
>
> Something already does; the irqchip driver for the IRQ in question would
> always know whether it's programming a plain IRQ controller, or an IRQ
> controller that's part of a GPIO controller. In the GPIO case, the
> irqchip driver also has enought HW-specific information to perform
> whatever GPIO<->IRQ number conversion is needed.

So I'm opposed to doing these things both ways because
I think it's getting messy. We have already has irq_to_gpio()
cause problems in the past and this reminds me heavily
about that.

> Or, were you thinking of creating some kind of hogging system for
> gpiolib itself?

Yes.

Yours,
Linus Walleij


From andrew at lunn.ch  Wed Apr 10 14:18:17 2013
From: andrew at lunn.ch (Andrew Lunn)
Date: Wed, 10 Apr 2013 20:18:17 +0200
Subject: [PATCH 05/18] cpuidle: make a single register function for all
In-Reply-To: <5165A9A6.70905@linaro.org>
References: <1365603743-5618-1-git-send-email-daniel.lezcano@linaro.org>
 <1365603743-5618-6-git-send-email-daniel.lezcano@linaro.org>
 <20130410165509.GK13524@lunn.ch> <5165A9A6.70905@linaro.org>
Message-ID: <20130410181817.GM13524@lunn.ch>

On Wed, Apr 10, 2013 at 08:04:22PM +0200, Daniel Lezcano wrote:
> On 04/10/2013 06:55 PM, Andrew Lunn wrote:
> >> +/**
> >> + * cpuidle_register: registers the driver and the cpu devices with the
> >> + * coupled_cpus passed as parameter. This function is used for all common
> >> + * initialization pattern there are in the arch specific drivers. The
> >> + * devices is globally defined in this file.
> >> + *
> >> + * @drv         : a valid pointer to a struct cpuidle_driver
> >> + * @coupled_cpus: a cpumask for the coupled states
> >> + *
> >> + * Returns 0 on success, < 0 otherwise
> >> + */
> >> +int cpuidle_register(struct cpuidle_driver *drv,
> >> +		     const struct cpumask *const coupled_cpus)
> >> +{
> >> +	int ret, cpu;
> >> +	struct cpuidle_device *device;
> >> +
> >> +	ret = cpuidle_register_driver(drv);
> >> +	if (ret) {
> >> +		printk(KERN_ERR "failed to register cpuidle driver\n");
> > 
> > pr_err()
> 
> Ok.
> 
> >> +		return ret;
> >> +	}
> >> +
> >> +	for_each_possible_cpu(cpu) {
> >> +		device = &per_cpu(cpuidle_dev, cpu);
> >> +		device->cpu = cpu;
> >> +#ifdef CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED
> >> +		device->coupled_cpus = *coupled_cpus;
> >> +#endif
> >> +		ret = cpuidle_register_device(device);
> >> +		if (!ret)
> >> +			continue;
> >> +
> >> +		printk(KERN_ERR "Failed to register cpuidle "
> >> +		       "device for cpu%d\n", cpu);
> > 
> > pr_err() and don't split the message over two lines, it makes it
> > harder for somebody to find with
> > 
> > grep -r "Failed to register cpuidle device for cpu" *
> 
> Ok if the line length is under 80 chars.

Take a closer look at the CodingStyle documents. This is one except to
the rule. Such lines can be longer than 80 characters.

    Andrew


From jason at lakedaemon.net  Wed Apr 10 14:21:18 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Wed, 10 Apr 2013 14:21:18 -0400
Subject: [PATCH v2 0/3] Add DT board setup for LaCie CloudBox
In-Reply-To: <1365460889-22965-1-git-send-email-simon.guinot@sequanux.org>
References: <1365460889-22965-1-git-send-email-simon.guinot@sequanux.org>
Message-ID: <20130410182118.GE28693@titan.lakedaemon.net>

On Tue, Apr 09, 2013 at 12:41:26AM +0200, Simon Guinot wrote:
> This patch series adds DT board setup for the LaCie CloudBox machine.
> Note that two patches have been added for this v2. The first,
> "ARM: Kirkwood: sort board entries by ASCII-code order" helps to respect
> alphabetical order while adding a new board entry. The last,
> "ARM: Kirkwood: update Network Space Mini v2 description" could be
> useful to differentiate the cloudbox and netspace_v2_mini machines
> (both embedded in products named LaCie CloudBox).
> 
> Regards,
> 
> Simon
> 
> Changes for v2:
>  - Add patch "ARM: Kirkwood: sort board entries by ASCII-code order".
>  - Add patch "ARM: Kirkwood: update Network Space Mini v2 description".
>  - Rebase against Jason's branch marvell/mvebu/boards.
>  - Remove i2c pinctrl declaration (not used).
>  - For all modified files, respect alphabetical order while inserting cloudbox
>    entries.
>  - Enhance patch description to avoid confusion between the two LaCie
>    products named CloudBox.
> 
> Simon Guinot (3):
>   ARM: Kirkwood: sort board entries by ASCII-code order
>   ARM: Kirkwood: DT board setup for CloudBox
>   ARM: Kirkwood: update Network Space Mini v2 description
> 
>  arch/arm/boot/dts/Makefile              |    3 +-
>  arch/arm/boot/dts/kirkwood-cloudbox.dts |   89 +++++++++
>  arch/arm/boot/dts/kirkwood-ns2mini.dts  |    1 +
>  arch/arm/configs/kirkwood_defconfig     |   51 ++---
>  arch/arm/mach-kirkwood/Kconfig          |  325 ++++++++++++++++---------------
>  arch/arm/mach-kirkwood/Makefile         |   41 ++--
>  arch/arm/mach-kirkwood/board-dt.c       |   14 +-
>  arch/arm/mach-kirkwood/board-ns2.c      |    3 +-
>  arch/arm/mach-kirkwood/common.h         |    6 +
>  9 files changed, 324 insertions(+), 209 deletions(-)
>  create mode 100644 arch/arm/boot/dts/kirkwood-cloudbox.dts

Whole series applied to mvebu/boards

thx,

Jason.


From ccross at google.com  Wed Apr 10 14:22:37 2013
From: ccross at google.com (Colin Cross)
Date: Wed, 10 Apr 2013 11:22:37 -0700
Subject: [PATCH 05/18] cpuidle: make a single register function for all
In-Reply-To: <1365603743-5618-6-git-send-email-daniel.lezcano@linaro.org>
References: <1365603743-5618-1-git-send-email-daniel.lezcano@linaro.org>
 <1365603743-5618-6-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <CAMbhsRSigxzDK3v20ARhXaXK11KL1xZRWkFOXA16YUZ=FtJN9g@mail.gmail.com>

On Wed, Apr 10, 2013 at 7:22 AM, Daniel Lezcano
<daniel.lezcano at linaro.org> wrote:
> The usual scheme to initialize a cpuidle driver on a SMP is:
>
>         cpuidle_register_driver(drv);
>         for_each_possible_cpu(cpu) {
>                 device = &per_cpu(cpuidle_dev, cpu);
>                 cpuidle_register_device(device);
>         }
>
> This code is duplicated in each cpuidle driver.
>
> On UP systems, it is done this way:
>
>         cpuidle_register_driver(drv);
>         device = &per_cpu(cpuidle_dev, cpu);
>         cpuidle_register_device(device);
>
> On UP, the macro 'for_each_cpu' does one iteration:
>
> #define for_each_cpu(cpu, mask)                 \
>         for ((cpu) = 0; (cpu) < 1; (cpu)++, (void)mask)
>
> Hence, the initialization loop is the same for UP than SMP.
>
> Beside, we saw different bugs / mis-initialization / return code unchecked in
> the different drivers, the code is duplicated including bugs. After fixing all
> these ones, it appears the initialization pattern is the same for everyone.
>
> Let's add a wrapper function doing this initialization with a cpumask parameter
> for the coupled idle states and use it for all the drivers.

Isn't this going to cause problems for big.LITTLE, which has two
independent sets of coupled cpus, and may even have different drivers
for the two types of cpu?


From andrew at lunn.ch  Wed Apr 10 14:23:59 2013
From: andrew at lunn.ch (Andrew Lunn)
Date: Wed, 10 Apr 2013 20:23:59 +0200
Subject: [PATCH 05/18] cpuidle: make a single register function for all
In-Reply-To: <5165A937.70705@linaro.org>
References: <1365603743-5618-1-git-send-email-daniel.lezcano@linaro.org>
 <1365603743-5618-6-git-send-email-daniel.lezcano@linaro.org>
 <20130410170457.GL13524@lunn.ch> <5165A937.70705@linaro.org>
Message-ID: <20130410182359.GN13524@lunn.ch>

On Wed, Apr 10, 2013 at 08:02:31PM +0200, Daniel Lezcano wrote:
> On 04/10/2013 07:04 PM, Andrew Lunn wrote:
> >> +int cpuidle_register(struct cpuidle_driver *drv,
> >> +		     const struct cpumask *const coupled_cpus)
> >> +{
> >> +	int ret, cpu;
> >> +	struct cpuidle_device *device;
> >> +
> >> +	ret = cpuidle_register_driver(drv);
> >> +	if (ret) {
> >> +		printk(KERN_ERR "failed to register cpuidle driver\n");
> >> +		return ret;
> >> +	}
> >> +
> >> +	for_each_possible_cpu(cpu) {
> >> +		device = &per_cpu(cpuidle_dev, cpu);
> >> +		device->cpu = cpu;
> >> +#ifdef CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED
> >> +		device->coupled_cpus = *coupled_cpus;
> >> +#endif
> > 
> > At least the kirkwood and the calxeda driver set 
> > 
> >    device->state_count
> > 
> > which you don't appear to do. cpuidle_add_state_sysfs() and
> > cpuidle_remove_state_sysfs() use this. Is it now being set somewhere
> > else?
> 
> Yes, in cpuidle_enable_device called from cpuidle_register_device:

O.K. It would be nice to add a comment in the change log message about
this.

Ah, also, it would be good to update Documentation/cpuidle/drivers.txt
with these new functions and update the text.

     Thanks
	Andrew



From steve.mcintyre at linaro.org  Wed Apr 10 14:24:15 2013
From: steve.mcintyre at linaro.org (Steve McIntyre)
Date: Wed, 10 Apr 2013 19:24:15 +0100
Subject: Removal of NWFPE in its entirety, and VFP emulation code
In-Reply-To: <alpine.LFD.2.03.1304101307280.17375@syhkavp.arg>
References: <20130410104002.GF14496@n2100.arm.linux.org.uk>
 <alpine.LFD.2.03.1304101307280.17375@syhkavp.arg>
Message-ID: <20130410182415.GD19224@einval.com>

On Wed, Apr 10, 2013 at 01:30:35PM -0400, Nicolas Pitre wrote:
>On Wed, 10 Apr 2013, Russell King - ARM Linux wrote:
>
>> I have just committed a patch to remove the arch/arm/nwfpe code from
>> the kernel, and the VFP code emulating the FP operations.
>> 
>> This I have done after it has been brought to my attention by the OSADL's
>> GPL-violations project that the license for the softfloat library is
>> incompatible with GPLv2.  This is because the FSF have ruled that
>> indemnification clauses consitute an "additional restriction" which is
>> incompatible with the GPLv2 section 6.  NWFPE contains the softfloat
>> library, and VFP's emulation code is a derivative of softfloat.
>> 
>> This will be very disruptive for ARMv4 and ARMv5 CPUs, which will no
>> longer be able to run userspace with NWFPE support removed.  A possible
>> solution there is to resurrect FASTFPE support and merge that into
>> mainline in place of NWFPE.  FASTFPE's hooks are all present in the
>> kernel, and it should just be a case of adding the FASTFPE code.
>> However, FASTFPE is probably lacking GDB and signal stack support.
>> (FastFPE's per-thread workspace is different from NWFPE.)
>
>A point worth mentioning is the EABI availability since 2006 which moved 
>away from FPA completely. A soft-float library in user space is used in 
>that case.  Major ARM binary producers including all ARM distros moved 
>to EABI with user space soft-float since then as it is order of 
>magnitude faster than FPA emulation.  So 99.99% of ARMv4 and ARMv5 users 
>are unlikely to be affected.
>
>So another option here might imply deprecating OABI support entirely, 
>given that it is useless without FPA and people keeping current with the 
>latest kernel are very likely to already use EABI user space.

Plus, OABI is just about dead in major places like glibc too.

Cheers,
-- 
Steve McIntyre                                steve.mcintyre at linaro.org
<http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs



From robherring2 at gmail.com  Wed Apr 10 14:26:02 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Wed, 10 Apr 2013 13:26:02 -0500
Subject: [PATCH v5 2/3] of/pci: Provide support for parsing PCI DT ranges
 property
In-Reply-To: <1365578969-30966-3-git-send-email-Andrew.Murray@arm.com>
References: <1365578969-30966-1-git-send-email-Andrew.Murray@arm.com>
 <1365578969-30966-3-git-send-email-Andrew.Murray@arm.com>
Message-ID: <5165AEBA.7000803@gmail.com>

On 04/10/2013 02:29 AM, Andrew Murray wrote:
> This patch factors out common implementation patterns to reduce overall kernel
> code and provide a means for host bridge drivers to directly obtain struct
> resources from the DT's ranges property without relying on architecture specific
> DT handling. This will make it easier to write archiecture independent host bridge
> drivers and mitigate against further duplication of DT parsing code.
> 
> This patch can be used in the following way:
> 
> 	struct of_pci_range_parser parser;
> 	struct of_pci_range range;
> 
> 	if (of_pci_range_parser(&parser, np))
> 		; //no ranges property
> 
> 	for_each_of_pci_range(&parser, &range) {
> 
> 		/*
> 			directly access properties of the address range, e.g.:
> 			range.pci_space, range.pci_addr, range.cpu_addr,
> 			range.size, range.flags
> 
> 			alternatively obtain a struct resource, e.g.:
> 			struct resource res;
> 			of_pci_range_to_resource(&range, np, &res);
> 		*/
> 	}
> 
> Additionally the implementation takes care of adjacent ranges and merges them
> into a single range (as was the case with powerpc and microblaze).
> 
> Signed-off-by: Andrew Murray <Andrew.Murray at arm.com>
> Signed-off-by: Liviu Dudau <Liviu.Dudau at arm.com>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> ---

A few minor things below, otherwise:

Reviewed-by: Rob Herring <rob.herring at calxeda.com>

>  drivers/of/address.c       |   63 +++++++++++++++++++++++++
>  drivers/of/of_pci.c        |  112 ++++++++++++++++----------------------------
>  include/linux/of_address.h |   42 ++++++++++++++++
>  3 files changed, 145 insertions(+), 72 deletions(-)
> 
> diff --git a/drivers/of/address.c b/drivers/of/address.c
> index 04da786..e87f45e 100644
> --- a/drivers/of/address.c
> +++ b/drivers/of/address.c
> @@ -227,6 +227,69 @@ int of_pci_address_to_resource(struct device_node *dev, int bar,
>  	return __of_address_to_resource(dev, addrp, size, flags, NULL, r);
>  }
>  EXPORT_SYMBOL_GPL(of_pci_address_to_resource);
> +
> +int of_pci_range_parser(struct of_pci_range_parser *parser,
> +			struct device_node *node)
> +{
> +	const int na = 3, ns = 2;
> +	int rlen;
> +
> +	parser->node = node;
> +	parser->pna = of_n_addr_cells(node);
> +	parser->np = parser->pna + na + ns;
> +
> +	parser->range = of_get_property(node, "ranges", &rlen);
> +	if (parser->range == NULL)
> +		return -ENOENT;
> +
> +	parser->end = parser->range + rlen / sizeof(__be32);
> +
> +	return 0;
> +}
> +
> +struct of_pci_range *of_pci_process_ranges(struct of_pci_range_parser *parser,
> +						struct of_pci_range *range)
> +{
> +	const int na = 3, ns = 2;
> +
> +	if (!parser->range || parser->range + parser->np > parser->end)

Add a !range check

> +		return NULL;
> +
> +	range->pci_space = be32_to_cpup(parser->range);
> +	range->flags = of_bus_pci_get_flags(parser->range);
> +	range->pci_addr = of_read_number(parser->range + 1, ns);
> +	range->cpu_addr = of_translate_address(parser->node,
> +				parser->range + na);
> +	range->size = of_read_number(parser->range + parser->pna + na, ns);
> +
> +	parser->range += parser->np;
> +
> +	/* Now consume following elements while they are contiguous */
> +	while (parser->range + parser->np <= parser->end) {
> +		u32 flags, pci_space;
> +		u64 pci_addr, cpu_addr, size;
> +
> +		pci_space = be32_to_cpup(parser->range);

This line doesn't do anything.

> +		flags = of_bus_pci_get_flags(parser->range);
> +		pci_addr = of_read_number(parser->range + 1, ns);
> +		cpu_addr = of_translate_address(parser->node,
> +				parser->range + na);
> +		size = of_read_number(parser->range + parser->pna + na, ns);
> +
> +		if (flags != range->flags)
> +			break;
> +		if (pci_addr != range->pci_addr + range->size ||
> +		    cpu_addr != range->cpu_addr + range->size)
> +			break;
> +
> +		range->size += size;
> +		parser->range += parser->np;
> +	}
> +
> +	return range;
> +}
> +EXPORT_SYMBOL_GPL(of_pci_process_ranges);
> +
>  #endif /* CONFIG_PCI */
>  
>  /*
> diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
> index 0611248..9680dc6 100644
> --- a/drivers/of/of_pci.c
> +++ b/drivers/of/of_pci.c
> @@ -82,67 +82,43 @@ EXPORT_SYMBOL_GPL(of_pci_find_child_device);
>  void pci_process_bridge_OF_ranges(struct pci_controller *hose,
>  				  struct device_node *dev, int primary)
>  {
> -	const u32 *ranges;
> -	int rlen;
> -	int pna = of_n_addr_cells(dev);
> -	int np = pna + 5;
>  	int memno = 0, isa_hole = -1;
> -	u32 pci_space;
> -	unsigned long long pci_addr, cpu_addr, pci_next, cpu_next, size;
>  	unsigned long long isa_mb = 0;
>  	struct resource *res;
> +	struct of_pci_range range;
> +	struct of_pci_range_parser parser;
> +	u32 res_type;
>  
>  	pr_info("PCI host bridge %s %s ranges:\n",
>  	       dev->full_name, primary ? "(primary)" : "");
>  
> -	/* Get ranges property */
> -	ranges = of_get_property(dev, "ranges", &rlen);
> -	if (ranges == NULL)
> +	/* Check for ranges property */
> +	if (of_pci_range_parser(&parser, dev))
>  		return;
>  
> -	/* Parse it */
>  	pr_debug("Parsing ranges property...\n");
> -	while ((rlen -= np * 4) >= 0) {
> +	for_each_of_pci_range(&parser, &range) {
>  		/* Read next ranges element */
> -		pci_space = ranges[0];
> -		pci_addr = of_read_number(ranges + 1, 2);
> -		cpu_addr = of_translate_address(dev, ranges + 3);
> -		size = of_read_number(ranges + pna + 3, 2);
> -
> -		pr_debug("pci_space: 0x%08x pci_addr:0x%016llx ",
> -				pci_space, pci_addr);
> -		pr_debug("cpu_addr:0x%016llx size:0x%016llx\n",
> -					cpu_addr, size);
> -
> -		ranges += np;
> +		pr_debug("pci_space: 0x%08x pci_addr: 0x%016llx ",
> +				range.pci_space, range.pci_addr);
> +		pr_debug("cpu_addr: 0x%016llx size: 0x%016llx\n",
> +				range.cpu_addr, range.size);
>  
>  		/* If we failed translation or got a zero-sized region
>  		 * (some FW try to feed us with non sensical zero sized regions
>  		 * such as power3 which look like some kind of attempt
>  		 * at exposing the VGA memory hole)
>  		 */
> -		if (cpu_addr == OF_BAD_ADDR || size == 0)
> +		if (range.cpu_addr == OF_BAD_ADDR || range.size == 0)
>  			continue;
>  
> -		/* Now consume following elements while they are contiguous */
> -		for (; rlen >= np * sizeof(u32);
> -		     ranges += np, rlen -= np * 4) {
> -			if (ranges[0] != pci_space)
> -				break;
> -			pci_next = of_read_number(ranges + 1, 2);
> -			cpu_next = of_translate_address(dev, ranges + 3);
> -			if (pci_next != pci_addr + size ||
> -			    cpu_next != cpu_addr + size)
> -				break;
> -			size += of_read_number(ranges + pna + 3, 2);
> -		}
> -
>  		/* Act based on address space type */
>  		res = NULL;
> -		switch ((pci_space >> 24) & 0x3) {
> -		case 1:		/* PCI IO space */
> +		res_type = range.flags & IORESOURCE_TYPE_BITS;
> +		if (res_type == IORESOURCE_IO) {
>  			pr_info("  IO 0x%016llx..0x%016llx -> 0x%016llx\n",
> -			       cpu_addr, cpu_addr + size - 1, pci_addr);
> +				range.cpu_addr, range.cpu_addr + range.size - 1,
> +				range.pci_addr);
>  
>  			/* We support only one IO range */
>  			if (hose->pci_io_size) {
> @@ -151,11 +127,12 @@ void pci_process_bridge_OF_ranges(struct pci_controller *hose,
>  			}
>  #if defined(CONFIG_PPC32) || defined(CONFIG_MICROBLAZE)
>  			/* On 32 bits, limit I/O space to 16MB */
> -			if (size > 0x01000000)
> -				size = 0x01000000;
> +			if (range.size > 0x01000000)
> +				range.size = 0x01000000;
>  
>  			/* 32 bits needs to map IOs here */
> -			hose->io_base_virt = ioremap(cpu_addr, size);
> +			hose->io_base_virt = ioremap(range.cpu_addr,
> +						range.size);
>  
>  			/* Expect trouble if pci_addr is not 0 */
>  			if (primary)
> @@ -165,19 +142,18 @@ void pci_process_bridge_OF_ranges(struct pci_controller *hose,
>  			/* pci_io_size and io_base_phys always represent IO
>  			 * space starting at 0 so we factor in pci_addr
>  			 */
> -			hose->pci_io_size = pci_addr + size;
> -			hose->io_base_phys = cpu_addr - pci_addr;
> +			hose->pci_io_size = range.pci_addr + range.size;
> +			hose->io_base_phys = range.cpu_addr - range.pci_addr;
>  
>  			/* Build resource */
>  			res = &hose->io_resource;
> -			res->flags = IORESOURCE_IO;
> -			res->start = pci_addr;
> -			break;
> -		case 2:		/* PCI Memory space */
> -		case 3:		/* PCI 64 bits Memory space */
> +			range.cpu_addr = range.pci_addr;
> +		} else if (res_type == IORESOURCE_MEM) {
>  			pr_info(" MEM 0x%016llx..0x%016llx -> 0x%016llx %s\n",
> -			       cpu_addr, cpu_addr + size - 1, pci_addr,
> -			       (pci_space & 0x40000000) ? "Prefetch" : "");
> +				range.cpu_addr, range.cpu_addr + range.size - 1,
> +				range.pci_addr,
> +				(range.pci_space & 0x40000000) ?
> +				"Prefetch" : "");
>  
>  			/* We support only 3 memory ranges */
>  			if (memno >= 3) {
> @@ -185,13 +161,13 @@ void pci_process_bridge_OF_ranges(struct pci_controller *hose,
>  				continue;
>  			}
>  			/* Handles ISA memory hole space here */
> -			if (pci_addr == 0) {
> -				isa_mb = cpu_addr;
> +			if (range.pci_addr == 0) {
> +				isa_mb = range.cpu_addr;
>  				isa_hole = memno;
>  				if (primary || isa_mem_base == 0)
> -					isa_mem_base = cpu_addr;
> -				hose->isa_mem_phys = cpu_addr;
> -				hose->isa_mem_size = size;
> +					isa_mem_base = range.cpu_addr;
> +				hose->isa_mem_phys = range.cpu_addr;
> +				hose->isa_mem_size = range.size;
>  			}
>  
>  			/* We get the PCI/Mem offset from the first range or
> @@ -199,30 +175,22 @@ void pci_process_bridge_OF_ranges(struct pci_controller *hose,
>  			 * hole. If they don't match, bugger.
>  			 */
>  			if (memno == 0 ||
> -			    (isa_hole >= 0 && pci_addr != 0 &&
> +			(isa_hole >= 0 && range.pci_addr != 0 &&
>  			     hose->pci_mem_offset == isa_mb))
> -				hose->pci_mem_offset = cpu_addr - pci_addr;
> -			else if (pci_addr != 0 &&
> -				 hose->pci_mem_offset != cpu_addr - pci_addr) {
> +				hose->pci_mem_offset = range.cpu_addr -
> +							range.pci_addr;
> +			else if (range.pci_addr != 0 &&
> +				hose->pci_mem_offset != range.cpu_addr -
> +							range.pci_addr) {
>  				pr_info(" \\--> Skipped (offset mismatch) !\n");
>  				continue;
>  			}
>  
>  			/* Build resource */
>  			res = &hose->mem_resources[memno++];
> -			res->flags = IORESOURCE_MEM;
> -			if (pci_space & 0x40000000)
> -				res->flags |= IORESOURCE_PREFETCH;
> -			res->start = cpu_addr;
> -			break;
> -		}
> -		if (res != NULL) {
> -			res->name = dev->full_name;
> -			res->end = res->start + size - 1;
> -			res->parent = NULL;
> -			res->sibling = NULL;
> -			res->child = NULL;
>  		}
> +		if (res != NULL)
> +			of_pci_range_to_resource(&range, dev, res);
>  	}
>  
>  	/* If there's an ISA hole and the pci_mem_offset is -not- matching
> diff --git a/include/linux/of_address.h b/include/linux/of_address.h
> index 0506eb5..c7003a3 100644
> --- a/include/linux/of_address.h
> +++ b/include/linux/of_address.h
> @@ -4,6 +4,32 @@
>  #include <linux/errno.h>
>  #include <linux/of.h>
>  
> +struct of_pci_range_parser {
> +	struct device_node *node;
> +	const __be32 *range, *end;

Split these on to separate lines.

> +	int np, pna;

ditto

> +};
> +
> +struct of_pci_range {
> +	u32 pci_space;
> +	u64 pci_addr;
> +	u64 cpu_addr;
> +	u64 size;
> +	u32 flags;
> +};
> +
> +#define for_each_of_pci_range(parser, range) \
> +	for (; of_pci_process_ranges(parser, range);)
> +
> +#define of_pci_range_to_resource(range, np, res) \

Why not a static inline here?

> +	do { \
> +		(res)->flags = (range)->flags; \
> +		(res)->start = (range)->cpu_addr; \
> +		(res)->end = (range)->cpu_addr + (range)->size - 1; \
> +		(res)->parent = (res)->child = (res)->sibling = NULL; \
> +		(res)->name = (np)->full_name; \
> +	} while (0)
> +
>  #ifdef CONFIG_OF_ADDRESS
>  extern u64 of_translate_address(struct device_node *np, const __be32 *addr);
>  extern bool of_can_translate_address(struct device_node *dev);
> @@ -27,6 +53,10 @@ static inline unsigned long pci_address_to_pio(phys_addr_t addr) { return -1; }
>  #define pci_address_to_pio pci_address_to_pio
>  #endif
>  
> +int of_pci_range_parser(struct of_pci_range_parser *parser,
> +			struct device_node *node);
> +struct of_pci_range *of_pci_process_ranges(struct of_pci_range_parser *parser,
> +						struct of_pci_range *range);
>  #else /* CONFIG_OF_ADDRESS */
>  #ifndef of_address_to_resource
>  static inline int of_address_to_resource(struct device_node *dev, int index,
> @@ -53,6 +83,18 @@ static inline const __be32 *of_get_address(struct device_node *dev, int index,
>  {
>  	return NULL;
>  }
> +
> +int of_pci_range_parser(struct of_pci_range_parser *parser,
> +			struct device_noed *node)
> +{
> +	return -1;
> +}
> +
> +struct of_pci_range *of_pci_process_ranges(struct of_pci_range_parser *parser,
> +						struct of_pci_range *range)
> +{
> +	return NULL;
> +}
>  #endif /* CONFIG_OF_ADDRESS */
>  
>  
> 



From robherring2 at gmail.com  Wed Apr 10 14:28:34 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Wed, 10 Apr 2013 13:28:34 -0500
Subject: [PATCH v5 3/3] of/pci: mips: convert to common of_pci_range_parser
In-Reply-To: <1365578969-30966-4-git-send-email-Andrew.Murray@arm.com>
References: <1365578969-30966-1-git-send-email-Andrew.Murray@arm.com>
 <1365578969-30966-4-git-send-email-Andrew.Murray@arm.com>
Message-ID: <5165AF52.9000001@gmail.com>

On 04/10/2013 02:29 AM, Andrew Murray wrote:
> This patch converts the pci_load_of_ranges function to use the new common
> of_pci_range_parser.
> 
> Signed-off-by: Andrew Murray <Andrew.Murray at arm.com>
> Signed-off-by: Liviu Dudau <Liviu.Dudau at arm.com>

Reviewed-by: Rob Herring <rob.herring at calxeda.com>


> ---
>  arch/mips/pci/pci.c |   50 ++++++++++++++++----------------------------------
>  1 files changed, 16 insertions(+), 34 deletions(-)
> 
> diff --git a/arch/mips/pci/pci.c b/arch/mips/pci/pci.c
> index 0872f12..bee49a4 100644
> --- a/arch/mips/pci/pci.c
> +++ b/arch/mips/pci/pci.c
> @@ -122,51 +122,33 @@ static void pcibios_scanbus(struct pci_controller *hose)
>  #ifdef CONFIG_OF
>  void pci_load_of_ranges(struct pci_controller *hose, struct device_node *node)
>  {
> -	const __be32 *ranges;
> -	int rlen;
> -	int pna = of_n_addr_cells(node);
> -	int np = pna + 5;
> +	struct of_pci_range_range range;
> +	struct of_pci_range_parser parser;
> +	u32 res_type;
>  
>  	pr_info("PCI host bridge %s ranges:\n", node->full_name);
> -	ranges = of_get_property(node, "ranges", &rlen);
> -	if (ranges == NULL)
> -		return;
>  	hose->of_node = node;
>  
> -	while ((rlen -= np * 4) >= 0) {
> -		u32 pci_space;
> +	if (of_pci_range_parser(&parser, node))
> +		return;
> +
> +	for_each_of_pci_range(&parser, &range) {
>  		struct resource *res = NULL;
> -		u64 addr, size;
> -
> -		pci_space = be32_to_cpup(&ranges[0]);
> -		addr = of_translate_address(node, ranges + 3);
> -		size = of_read_number(ranges + pna + 3, 2);
> -		ranges += np;
> -		switch ((pci_space >> 24) & 0x3) {
> -		case 1:		/* PCI IO space */
> +
> +		res_type = range.flags & IORESOURCE_TYPE_BITS;
> +		if (res_type == IORESOURCE_IO) {
>  			pr_info("  IO 0x%016llx..0x%016llx\n",
> -					addr, addr + size - 1);
> +				range.addr, range.addr + range.size - 1);
>  			hose->io_map_base =
> -				(unsigned long)ioremap(addr, size);
> +				(unsigned long)ioremap(range.addr, range.size);
>  			res = hose->io_resource;
> -			res->flags = IORESOURCE_IO;
> -			break;
> -		case 2:		/* PCI Memory space */
> -		case 3:		/* PCI 64 bits Memory space */
> +		} else if (res_type == IORESOURCE_MEM) {
>  			pr_info(" MEM 0x%016llx..0x%016llx\n",
> -					addr, addr + size - 1);
> +				range.addr, range.addr + range.size - 1);
>  			res = hose->mem_resource;
> -			res->flags = IORESOURCE_MEM;
> -			break;
> -		}
> -		if (res != NULL) {
> -			res->start = addr;
> -			res->name = node->full_name;
> -			res->end = res->start + size - 1;
> -			res->parent = NULL;
> -			res->sibling = NULL;
> -			res->child = NULL;
>  		}
> +		if (res != NULL)
> +			of_pci_range_to_resource(&range, node, res);
>  	}
>  }
>  #endif
> 



From mturquette at linaro.org  Wed Apr 10 14:29:10 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Wed, 10 Apr 2013 11:29:10 -0700
Subject: [PATCH V3 1/3] clk: ux500: Add support for sysctrl clocks
In-Reply-To: <CAPDyKFqM+638Q2FRFHu7pLw+MQSvT0yZp7v6dQeYN9gRY4c+aA@mail.gmail.com>
References: <1364992017-12683-1-git-send-email-ulf.hansson@stericsson.com>
 <20130409011433.14359.14140@quantum>
 <CAPDyKFqM+638Q2FRFHu7pLw+MQSvT0yZp7v6dQeYN9gRY4c+aA@mail.gmail.com>
Message-ID: <20130410182910.14359.31168@quantum>

Quoting Ulf Hansson (2013-04-10 01:02:53)
> On 9 April 2013 03:14, Mike Turquette <mturquette at linaro.org> wrote:
> > Quoting Ulf Hansson (2013-04-03 05:26:57)
> >> From: Ulf Hansson <ulf.hansson at linaro.org>
> >>
> >> The abx500 sysctrl clocks are using the ab8500 sysctrl driver to
> >> modify the clock hardware. Sysctrl clocks are represented by a
> >> ab8500 sysctrl register and with a corresponding bitmask.
> >>
> >> The sysctrl clocks are slow path clocks, which means clk_prepare
> >> and clk_unprepare will be used to gate|ungate these clocks.
> >>
> >> Signed-off-by: Ulf Hansson <ulf.hansson at linaro.org>
> >
> > Hi Ulf,
> >
> > Is there a V3 update for patches #2 & #3?  I can't seem to find them.
> 
> Hi Mike,
> 
> Only v3 exist for this patch. Sorry if it was a bit unclear.
> 

Taken into clk-next.

Regards,
Mike

> Kind regards
> Uffe
> 
> >
> > Regards,
> > Mike
> >
> >> ---
> >>
> >> Changes in v3:
> >>         - Fixed error check at clk registration.
> >> Changes in v2:
> >>         - Removed wrong header file.
> >> ---
> >>  drivers/clk/ux500/Makefile      |    1 +
> >>  drivers/clk/ux500/clk-sysctrl.c |  221 +++++++++++++++++++++++++++++++++++++++
> >>  drivers/clk/ux500/clk.h         |   29 +++++
> >>  3 files changed, 251 insertions(+)
> >>  create mode 100644 drivers/clk/ux500/clk-sysctrl.c
> >>
> >> diff --git a/drivers/clk/ux500/Makefile b/drivers/clk/ux500/Makefile
> >> index bcc0c11..c6a806e 100644
> >> --- a/drivers/clk/ux500/Makefile
> >> +++ b/drivers/clk/ux500/Makefile
> >> @@ -5,6 +5,7 @@
> >>  # Clock types
> >>  obj-y += clk-prcc.o
> >>  obj-y += clk-prcmu.o
> >> +obj-y += clk-sysctrl.o
> >>
> >>  # Clock definitions
> >>  obj-y += u8500_clk.o
> >> diff --git a/drivers/clk/ux500/clk-sysctrl.c b/drivers/clk/ux500/clk-sysctrl.c
> >> new file mode 100644
> >> index 0000000..bc7e9bd
> >> --- /dev/null
> >> +++ b/drivers/clk/ux500/clk-sysctrl.c
> >> @@ -0,0 +1,221 @@
> >> +/*
> >> + * Sysctrl clock implementation for ux500 platform.
> >> + *
> >> + * Copyright (C) 2013 ST-Ericsson SA
> >> + * Author: Ulf Hansson <ulf.hansson at linaro.org>
> >> + *
> >> + * License terms: GNU General Public License (GPL) version 2
> >> + */
> >> +
> >> +#include <linux/clk-provider.h>
> >> +#include <linux/mfd/abx500/ab8500-sysctrl.h>
> >> +#include <linux/device.h>
> >> +#include <linux/slab.h>
> >> +#include <linux/delay.h>
> >> +#include <linux/io.h>
> >> +#include <linux/err.h>
> >> +#include "clk.h"
> >> +
> >> +#define SYSCTRL_MAX_NUM_PARENTS 4
> >> +
> >> +#define to_clk_sysctrl(_hw) container_of(_hw, struct clk_sysctrl, hw)
> >> +
> >> +struct clk_sysctrl {
> >> +       struct clk_hw hw;
> >> +       struct device *dev;
> >> +       u8 parent_index;
> >> +       u16 reg_sel[SYSCTRL_MAX_NUM_PARENTS];
> >> +       u8 reg_mask[SYSCTRL_MAX_NUM_PARENTS];
> >> +       u8 reg_bits[SYSCTRL_MAX_NUM_PARENTS];
> >> +       unsigned long rate;
> >> +       unsigned long enable_delay_us;
> >> +};
> >> +
> >> +/* Sysctrl clock operations. */
> >> +
> >> +static int clk_sysctrl_prepare(struct clk_hw *hw)
> >> +{
> >> +       int ret;
> >> +       struct clk_sysctrl *clk = to_clk_sysctrl(hw);
> >> +
> >> +       ret = ab8500_sysctrl_write(clk->reg_sel[0], clk->reg_mask[0],
> >> +                               clk->reg_bits[0]);
> >> +
> >> +       if (!ret && clk->enable_delay_us)
> >> +               usleep_range(clk->enable_delay_us, clk->enable_delay_us);
> >> +
> >> +       return ret;
> >> +}
> >> +
> >> +static void clk_sysctrl_unprepare(struct clk_hw *hw)
> >> +{
> >> +       struct clk_sysctrl *clk = to_clk_sysctrl(hw);
> >> +       if (ab8500_sysctrl_clear(clk->reg_sel[0], clk->reg_mask[0]))
> >> +               dev_err(clk->dev, "clk_sysctrl: %s fail to clear %s.\n",
> >> +                       __func__, __clk_get_name(hw->clk));
> >> +}
> >> +
> >> +static unsigned long clk_sysctrl_recalc_rate(struct clk_hw *hw,
> >> +                                       unsigned long parent_rate)
> >> +{
> >> +       struct clk_sysctrl *clk = to_clk_sysctrl(hw);
> >> +       return clk->rate;
> >> +}
> >> +
> >> +static int clk_sysctrl_set_parent(struct clk_hw *hw, u8 index)
> >> +{
> >> +       struct clk_sysctrl *clk = to_clk_sysctrl(hw);
> >> +       u8 old_index = clk->parent_index;
> >> +       int ret = 0;
> >> +
> >> +       if (clk->reg_sel[old_index]) {
> >> +               ret = ab8500_sysctrl_clear(clk->reg_sel[old_index],
> >> +                                       clk->reg_mask[old_index]);
> >> +               if (ret)
> >> +                       return ret;
> >> +       }
> >> +
> >> +       if (clk->reg_sel[index]) {
> >> +               ret = ab8500_sysctrl_write(clk->reg_sel[index],
> >> +                                       clk->reg_mask[index],
> >> +                                       clk->reg_bits[index]);
> >> +               if (ret) {
> >> +                       if (clk->reg_sel[old_index])
> >> +                               ab8500_sysctrl_write(clk->reg_sel[old_index],
> >> +                                               clk->reg_mask[old_index],
> >> +                                               clk->reg_bits[old_index]);
> >> +                       return ret;
> >> +               }
> >> +       }
> >> +       clk->parent_index = index;
> >> +
> >> +       return ret;
> >> +}
> >> +
> >> +static u8 clk_sysctrl_get_parent(struct clk_hw *hw)
> >> +{
> >> +       struct clk_sysctrl *clk = to_clk_sysctrl(hw);
> >> +       return clk->parent_index;
> >> +}
> >> +
> >> +static struct clk_ops clk_sysctrl_gate_ops = {
> >> +       .prepare = clk_sysctrl_prepare,
> >> +       .unprepare = clk_sysctrl_unprepare,
> >> +};
> >> +
> >> +static struct clk_ops clk_sysctrl_gate_fixed_rate_ops = {
> >> +       .prepare = clk_sysctrl_prepare,
> >> +       .unprepare = clk_sysctrl_unprepare,
> >> +       .recalc_rate = clk_sysctrl_recalc_rate,
> >> +};
> >> +
> >> +static struct clk_ops clk_sysctrl_set_parent_ops = {
> >> +       .set_parent = clk_sysctrl_set_parent,
> >> +       .get_parent = clk_sysctrl_get_parent,
> >> +};
> >> +
> >> +static struct clk *clk_reg_sysctrl(struct device *dev,
> >> +                               const char *name,
> >> +                               const char **parent_names,
> >> +                               u8 num_parents,
> >> +                               u16 *reg_sel,
> >> +                               u8 *reg_mask,
> >> +                               u8 *reg_bits,
> >> +                               unsigned long rate,
> >> +                               unsigned long enable_delay_us,
> >> +                               unsigned long flags,
> >> +                               struct clk_ops *clk_sysctrl_ops)
> >> +{
> >> +       struct clk_sysctrl *clk;
> >> +       struct clk_init_data clk_sysctrl_init;
> >> +       struct clk *clk_reg;
> >> +       int i;
> >> +
> >> +       if (!dev)
> >> +               return ERR_PTR(-EINVAL);
> >> +
> >> +       if (!name || (num_parents > SYSCTRL_MAX_NUM_PARENTS)) {
> >> +               dev_err(dev, "clk_sysctrl: invalid arguments passed\n");
> >> +               return ERR_PTR(-EINVAL);
> >> +       }
> >> +
> >> +       clk = devm_kzalloc(dev, sizeof(struct clk_sysctrl), GFP_KERNEL);
> >> +       if (!clk) {
> >> +               dev_err(dev, "clk_sysctrl: could not allocate clk\n");
> >> +               return ERR_PTR(-ENOMEM);
> >> +       }
> >> +
> >> +       for (i = 0; i < num_parents; i++) {
> >> +               clk->reg_sel[i] = reg_sel[i];
> >> +               clk->reg_bits[i] = reg_bits[i];
> >> +               clk->reg_mask[i] = reg_mask[i];
> >> +       }
> >> +
> >> +       clk->parent_index = 0;
> >> +       clk->rate = rate;
> >> +       clk->enable_delay_us = enable_delay_us;
> >> +       clk->dev = dev;
> >> +
> >> +       clk_sysctrl_init.name = name;
> >> +       clk_sysctrl_init.ops = clk_sysctrl_ops;
> >> +       clk_sysctrl_init.flags = flags;
> >> +       clk_sysctrl_init.parent_names = parent_names;
> >> +       clk_sysctrl_init.num_parents = num_parents;
> >> +       clk->hw.init = &clk_sysctrl_init;
> >> +
> >> +       clk_reg = devm_clk_register(clk->dev, &clk->hw);
> >> +       if (IS_ERR(clk_reg))
> >> +               dev_err(dev, "clk_sysctrl: clk_register failed\n");
> >> +
> >> +       return clk_reg;
> >> +}
> >> +
> >> +struct clk *clk_reg_sysctrl_gate(struct device *dev,
> >> +                               const char *name,
> >> +                               const char *parent_name,
> >> +                               u16 reg_sel,
> >> +                               u8 reg_mask,
> >> +                               u8 reg_bits,
> >> +                               unsigned long enable_delay_us,
> >> +                               unsigned long flags)
> >> +{
> >> +       const char **parent_names = (parent_name ? &parent_name : NULL);
> >> +       u8 num_parents = (parent_name ? 1 : 0);
> >> +
> >> +       return clk_reg_sysctrl(dev, name, parent_names, num_parents,
> >> +                       &reg_sel, &reg_mask, &reg_bits, 0, enable_delay_us,
> >> +                       flags, &clk_sysctrl_gate_ops);
> >> +}
> >> +
> >> +struct clk *clk_reg_sysctrl_gate_fixed_rate(struct device *dev,
> >> +                                       const char *name,
> >> +                                       const char *parent_name,
> >> +                                       u16 reg_sel,
> >> +                                       u8 reg_mask,
> >> +                                       u8 reg_bits,
> >> +                                       unsigned long rate,
> >> +                                       unsigned long enable_delay_us,
> >> +                                       unsigned long flags)
> >> +{
> >> +       const char **parent_names = (parent_name ? &parent_name : NULL);
> >> +       u8 num_parents = (parent_name ? 1 : 0);
> >> +
> >> +       return clk_reg_sysctrl(dev, name, parent_names, num_parents,
> >> +                       &reg_sel, &reg_mask, &reg_bits,
> >> +                       rate, enable_delay_us, flags,
> >> +                       &clk_sysctrl_gate_fixed_rate_ops);
> >> +}
> >> +
> >> +struct clk *clk_reg_sysctrl_set_parent(struct device *dev,
> >> +                               const char *name,
> >> +                               const char **parent_names,
> >> +                               u8 num_parents,
> >> +                               u16 *reg_sel,
> >> +                               u8 *reg_mask,
> >> +                               u8 *reg_bits,
> >> +                               unsigned long flags)
> >> +{
> >> +       return clk_reg_sysctrl(dev, name, parent_names, num_parents,
> >> +                       reg_sel, reg_mask, reg_bits, 0, 0, flags,
> >> +                       &clk_sysctrl_set_parent_ops);
> >> +}
> >> diff --git a/drivers/clk/ux500/clk.h b/drivers/clk/ux500/clk.h
> >> index c3e4491..3d2dfdc 100644
> >> --- a/drivers/clk/ux500/clk.h
> >> +++ b/drivers/clk/ux500/clk.h
> >> @@ -11,6 +11,7 @@
> >>  #define __UX500_CLK_H
> >>
> >>  #include <linux/clk.h>
> >> +#include <linux/device.h>
> >>
> >>  struct clk *clk_reg_prcc_pclk(const char *name,
> >>                               const char *parent_name,
> >> @@ -57,4 +58,32 @@ struct clk *clk_reg_prcmu_opp_volt_scalable(const char *name,
> >>                                             unsigned long rate,
> >>                                             unsigned long flags);
> >>
> >> +struct clk *clk_reg_sysctrl_gate(struct device *dev,
> >> +                                const char *name,
> >> +                                const char *parent_name,
> >> +                                u16 reg_sel,
> >> +                                u8 reg_mask,
> >> +                                u8 reg_bits,
> >> +                                unsigned long enable_delay_us,
> >> +                                unsigned long flags);
> >> +
> >> +struct clk *clk_reg_sysctrl_gate_fixed_rate(struct device *dev,
> >> +                                           const char *name,
> >> +                                           const char *parent_name,
> >> +                                           u16 reg_sel,
> >> +                                           u8 reg_mask,
> >> +                                           u8 reg_bits,
> >> +                                           unsigned long rate,
> >> +                                           unsigned long enable_delay_us,
> >> +                                           unsigned long flags);
> >> +
> >> +struct clk *clk_reg_sysctrl_set_parent(struct device *dev,
> >> +                                      const char *name,
> >> +                                      const char **parent_names,
> >> +                                      u8 num_parents,
> >> +                                      u16 *reg_sel,
> >> +                                      u8 *reg_mask,
> >> +                                      u8 *reg_bits,
> >> +                                      unsigned long flags);
> >> +
> >>  #endif /* __UX500_CLK_H */
> >> --
> >> 1.7.10


From mturquette at linaro.org  Wed Apr 10 14:29:53 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Wed, 10 Apr 2013 11:29:53 -0700
Subject: [PATCH 2/3] clk: ux500: abx500: Define clock tree for ab850x
In-Reply-To: <1364943987-1338-3-git-send-email-ulf.hansson@stericsson.com>
References: <1364943987-1338-1-git-send-email-ulf.hansson@stericsson.com>
 <1364943987-1338-3-git-send-email-ulf.hansson@stericsson.com>
Message-ID: <20130410182953.14359.99861@quantum>

Quoting Ulf Hansson (2013-04-02 16:06:26)
> From: Ulf Hansson <ulf.hansson at linaro.org>
> 
> The patch setups the first version of the clock tree for ab850x, which
> is used by u8500 platforms. Mainly sysctrl clocks are used.
> 
> Signed-off-by: Ulf Hansson <ulf.hansson at linaro.org>

Taken into clk-next.

Regards,
Mike

> ---
>  drivers/clk/ux500/abx500-clk.c |   71 ++++++++++++++++++++++++++++++++++++++--
>  1 file changed, 68 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/clk/ux500/abx500-clk.c b/drivers/clk/ux500/abx500-clk.c
> index 9f7400d..a0fca00 100644
> --- a/drivers/clk/ux500/abx500-clk.c
> +++ b/drivers/clk/ux500/abx500-clk.c
> @@ -12,13 +12,78 @@
>  #include <linux/device.h>
>  #include <linux/platform_device.h>
>  #include <linux/mfd/abx500/ab8500.h>
> -
> -/* TODO: Add clock implementations here */
> -
> +#include <linux/mfd/abx500/ab8500-sysctrl.h>
> +#include <linux/clk.h>
> +#include <linux/clkdev.h>
> +#include <linux/clk-provider.h>
> +#include <linux/mfd/dbx500-prcmu.h>
> +#include "clk.h"
>  
>  /* Clock definitions for ab8500 */
>  static int ab8500_reg_clks(struct device *dev)
>  {
> +       int ret;
> +       struct clk *clk;
> +
> +       const char *intclk_parents[] = {"ab8500_sysclk", "ulpclk"};
> +       u16 intclk_reg_sel[] = {0 , AB8500_SYSULPCLKCTRL1};
> +       u8 intclk_reg_mask[] = {0 , AB8500_SYSULPCLKCTRL1_SYSULPCLKINTSEL_MASK};
> +       u8 intclk_reg_bits[] = {
> +               0 ,
> +               (1 << AB8500_SYSULPCLKCTRL1_SYSULPCLKINTSEL_SHIFT)
> +       };
> +
> +       dev_info(dev, "register clocks for ab850x\n");
> +
> +       /* Enable SWAT */
> +       ret = ab8500_sysctrl_set(AB8500_SWATCTRL, AB8500_SWATCTRL_SWATENABLE);
> +       if (ret)
> +               return ret;
> +
> +       /* ab8500_sysclk */
> +       clk = clk_reg_prcmu_gate("ab8500_sysclk", NULL, PRCMU_SYSCLK,
> +                               CLK_IS_ROOT);
> +       clk_register_clkdev(clk, "sysclk", "ab8500-usb.0");
> +       clk_register_clkdev(clk, "sysclk", "ab-iddet.0");
> +       clk_register_clkdev(clk, "sysclk", "ab85xx-codec.0");
> +       clk_register_clkdev(clk, "sysclk", "shrm_bus");
> +
> +       /* ab8500_sysclk2 */
> +       clk = clk_reg_sysctrl_gate(dev , "ab8500_sysclk2", "ab8500_sysclk",
> +               AB8500_SYSULPCLKCTRL1, AB8500_SYSULPCLKCTRL1_SYSCLKBUF2REQ,
> +               AB8500_SYSULPCLKCTRL1_SYSCLKBUF2REQ, 0, 0);
> +       clk_register_clkdev(clk, "sysclk", "0-0070");
> +
> +       /* ab8500_sysclk3 */
> +       clk = clk_reg_sysctrl_gate(dev , "ab8500_sysclk3", "ab8500_sysclk",
> +               AB8500_SYSULPCLKCTRL1, AB8500_SYSULPCLKCTRL1_SYSCLKBUF3REQ,
> +               AB8500_SYSULPCLKCTRL1_SYSCLKBUF3REQ, 0, 0);
> +       clk_register_clkdev(clk, "sysclk", "cg1960_core.0");
> +
> +       /* ab8500_sysclk4 */
> +       clk = clk_reg_sysctrl_gate(dev , "ab8500_sysclk4", "ab8500_sysclk",
> +               AB8500_SYSULPCLKCTRL1, AB8500_SYSULPCLKCTRL1_SYSCLKBUF4REQ,
> +               AB8500_SYSULPCLKCTRL1_SYSCLKBUF4REQ, 0, 0);
> +
> +       /* ab_ulpclk */
> +       clk = clk_reg_sysctrl_gate_fixed_rate(dev, "ulpclk", NULL,
> +               AB8500_SYSULPCLKCTRL1, AB8500_SYSULPCLKCTRL1_ULPCLKREQ,
> +               AB8500_SYSULPCLKCTRL1_ULPCLKREQ,
> +               38400000, 9000, CLK_IS_ROOT);
> +       clk_register_clkdev(clk, "ulpclk", "ab85xx-codec.0");
> +
> +       /* ab8500_intclk */
> +       clk = clk_reg_sysctrl_set_parent(dev , "intclk", intclk_parents, 2,
> +               intclk_reg_sel, intclk_reg_mask, intclk_reg_bits, 0);
> +       clk_register_clkdev(clk, "intclk", "ab85xx-codec.0");
> +       clk_register_clkdev(clk, NULL, "ab8500-pwm.1");
> +
> +       /* ab8500_audioclk */
> +       clk = clk_reg_sysctrl_gate(dev , "audioclk", "intclk",
> +               AB8500_SYSULPCLKCTRL1, AB8500_SYSULPCLKCTRL1_AUDIOCLKENA,
> +               AB8500_SYSULPCLKCTRL1_AUDIOCLKENA, 0, 0);
> +       clk_register_clkdev(clk, "audioclk", "ab85xx-codec.0");
> +
>         return 0;
>  }
>  
> -- 
> 1.7.10


From ezequiel.garcia at free-electrons.com  Wed Apr 10 14:30:25 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Wed, 10 Apr 2013 15:30:25 -0300
Subject: [PATCHv1 0/5] Marvell EBU irqchip improvements
In-Reply-To: <20130410192106.73d81f2c@skate>
References: <1365542778-27959-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <20130410130902.GA29100@localhost> <20130410192106.73d81f2c@skate>
Message-ID: <20130410183024.GB2275@localhost>

On Wed, Apr 10, 2013 at 07:21:06PM +0200, Thomas Petazzoni wrote:
> Dear Ezequiel Garcia,
> 
> On Wed, 10 Apr 2013 10:09:03 -0300, Ezequiel Garcia wrote:
> 
> > I'm trying to test this patchset, assuming you've based it on top of
> > v3.9-rc5.
> > 
> > However, patch 4/5 doesn't apply and I'm not really sure which
> > other patches may be depending on this.
> > 
> > Any hints?
> 
> The patch set is based on 3.9-rc6, with no other dependencies. However,
> since a patch has been applied on the mvebu IRQ controller driver
> between 3.9-rc5 and 3.9-rc6, it probably explains the fact that the
> patch set doesn't apply as is on 3.9-rc5.
> 

Indeed it applies cleanly on v3.9-rc6, thank you. On my AXP and A370 boards:

Tested-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>

Also, FWIW, I've applied recent Greg's fix for GPIO IRQ:
"arm: mvebu: Fix the irq map function in SMP mode"

which applies cleanly on top of your patches!
(git can be really magical)
-- 
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com


From robherring2 at gmail.com  Wed Apr 10 14:37:04 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Wed, 10 Apr 2013 13:37:04 -0500
Subject: [PATCHv8 05/19] of/pci: Add of_pci_parse_bus_range() function
In-Reply-To: <1365541601-14095-6-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1365541601-14095-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1365541601-14095-6-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <5165B150.6050809@gmail.com>

On 04/09/2013 04:06 PM, Thomas Petazzoni wrote:
> From: Thierry Reding <thierry.reding at avionic-design.de>
> 
> This function can be used to parse a bus-range property as specified by
> device nodes representing PCI bridges.
> 
> Signed-off-by: Thierry Reding <thierry.reding at avionic-design.de>

Reviewed-by: Rob Herring <rob.herring at calxeda.com>

> ---
>  drivers/of/of_pci.c    |   25 +++++++++++++++++++++++++
>  include/linux/of_pci.h |    1 +
>  2 files changed, 26 insertions(+)
> 
> diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
> index b77e8d8..e9106dc 100644
> --- a/drivers/of/of_pci.c
> +++ b/drivers/of/of_pci.c
> @@ -232,3 +232,28 @@ int of_pci_get_devfn(struct device_node *np)
>  	return (be32_to_cpup(reg) >> 8) & 0xff;
>  }
>  EXPORT_SYMBOL_GPL(of_pci_get_devfn);
> +
> +/**
> + * of_pci_parse_bus_range() - parse the bus-range property of a PCI device
> + * @node: device node
> + * @res: address to a struct resource to return the bus-range
> + *
> + * Returns 0 on success or a negative error-code on failure.
> + */
> +int of_pci_parse_bus_range(struct device_node *node, struct resource *res)
> +{
> +	const __be32 *values;
> +	int len;
> +
> +	values = of_get_property(node, "bus-range", &len);
> +	if (!values || len < sizeof(*values) * 2)
> +		return -EINVAL;
> +
> +	res->name = node->name;
> +	res->start = be32_to_cpup(values++);
> +	res->end = be32_to_cpup(values);
> +	res->flags = IORESOURCE_BUS;
> +
> +	return 0;
> +}
> +EXPORT_SYMBOL_GPL(of_pci_parse_bus_range);
> diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
> index 302aca0..be97a6f 100644
> --- a/include/linux/of_pci.h
> +++ b/include/linux/of_pci.h
> @@ -12,6 +12,7 @@ struct device_node;
>  struct device_node *of_pci_find_child_device(struct device_node *parent,
>  					     unsigned int devfn);
>  int of_pci_get_devfn(struct device_node *np);
> +int of_pci_parse_bus_range(struct device_node *node, struct resource *res);
>  
>  void pci_process_bridge_OF_ranges(struct pci_controller *hose,
>  			struct device_node *dev, int primary);
> 



From tony at atomide.com  Wed Apr 10 14:14:52 2013
From: tony at atomide.com (Tony Lindgren)
Date: Wed, 10 Apr 2013 11:14:52 -0700
Subject: [GIT PULL] OMAP PM cleanups for v3.10
In-Reply-To: <87ehej1ena.fsf@linaro.org>
References: <87ehej1ena.fsf@linaro.org>
Message-ID: <20130410181452.GG10155@atomide.com>

Hi,

Added Olof to cc, I suggest Olof pull this directly as we're starting
to run out of time.

Regards,

Tony

* Kevin Hilman <khilman at linaro.org> [130409 16:18]:
> Tony,
> 
> Here's the final set of OMAP PM cleanups for v3.10.  This is a small set
> of cleanups from Santosh to consolidate and prepare for OMAP5 PM additions.
> 
> It's based on your cleanup-v2 branch.
> 
> Kevin
> 
> 
> The following changes since commit c309f7f46167e85d1aae2fd31f23e7d2b5cdfbe0:
> 
>   Merge branch 'for_3.10/omap_generic_cleanup_v2' of git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux into omap-for-v3.10/cleanup-v2 (2013-03-28 14:45:31 -0700)
> 
> are available in the git repository at:
> 
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git tags/omap-pm-v3.10/cleanup/pm
> 
> for you to fetch changes up to 705814b5ea6ff69d4da8ad581c3da5d26d1eae83:
> 
>   ARM: OMAP4+: PM: Consolidate OMAP4 PM code to re-use it for OMAP5 (2013-04-09 10:53:06 -0700)
> 
> ----------------------------------------------------------------
> OMAP PM cleanups for v3.10
> 
> ----------------------------------------------------------------
> Santosh Shilimkar (4):
>       ARM: OMAP4: PM: Avoid expensive cpu_suspend() path for all CPU power states except off
>       ARM: OMAP4+: PM: Consolidate MPU subsystem PM code for re-use
>       ARM: OMAP4+: Make secondary_startup function name more consistent
>       ARM: OMAP4+: PM: Consolidate OMAP4 PM code to re-use it for OMAP5
> 
>  arch/arm/mach-omap2/common.h              |  4 +-
>  arch/arm/mach-omap2/omap-headsmp.S        |  8 ++--
>  arch/arm/mach-omap2/omap-mpuss-lowpower.c | 69 +++++++++++++++++++++++++------
>  arch/arm/mach-omap2/omap-smp.c            |  6 +--
>  arch/arm/mach-omap2/pm44xx.c              | 58 +++++++++++++++++++++-----
>  5 files changed, 113 insertions(+), 32 deletions(-)


From jonsmirl at gmail.com  Wed Apr 10 14:38:21 2013
From: jonsmirl at gmail.com (jonsmirl at gmail.com)
Date: Wed, 10 Apr 2013 14:38:21 -0400
Subject: Removal of NWFPE in its entirety, and VFP emulation code
In-Reply-To: <20130410104002.GF14496@n2100.arm.linux.org.uk>
References: <20130410104002.GF14496@n2100.arm.linux.org.uk>
Message-ID: <CAKON4Ozhk1kfnzi4+j_2dkGbAG07MKFa3SXOKjy7oWhNh6HNVg@mail.gmail.com>

On Wed, Apr 10, 2013 at 6:40 AM, Russell King - ARM Linux
<linux at arm.linux.org.uk> wrote:
> I have just committed a patch to remove the arch/arm/nwfpe code from
> the kernel, and the VFP code emulating the FP operations.
>
> This I have done after it has been brought to my attention by the OSADL's
> GPL-violations project that the license for the softfloat library is
> incompatible with GPLv2.  This is because the FSF have ruled that
> indemnification clauses consitute an "additional restriction" which is
> incompatible with the GPLv2 section 6.  NWFPE contains the softfloat
> library, and VFP's emulation code is a derivative of softfloat.
>
> This will be very disruptive for ARMv4 and ARMv5 CPUs, which will no
> longer be able to run userspace with NWFPE support removed.  A possible
> solution there is to resurrect FASTFPE support and merge that into
> mainline in place of NWFPE.  FASTFPE's hooks are all present in the
> kernel, and it should just be a case of adding the FASTFPE code.
> However, FASTFPE is probably lacking GDB and signal stack support.
> (FastFPE's per-thread workspace is different from NWFPE.)
>
> The situation with VFP is likely less disruptive - only instructions
> which aren't implemented in hardware (or, for example, if you ask for
> inexact exceptions to be enabled) which are bounced to the software
> support code will be affected.  I think OMAP should get away unscathed,
> but ARM's implementation will bounce if inexact exceptions are enabled
> or in a few corner cases.  Qualcomm is likely to be the worst affected
> by this.
>
> Will Deacon has tested debian armhf on a Cortex-A15 with VFP emulation
> support removed, which boots successfully.
>
> There is some discussion that needs to happen to investigate possible
> solutions to this, which are:
>
> 1. Whether we can persuade John to relicense his code.  From what I
>    understand from the discussions which have already happened, John
>    is against that because he requires the indemnification clause.

Does it work to have him donate the copyright for the code to the FSF?
Then he wouldn't own it anymore and wouldn't need indemnification. FSF
would reissue under GPLv2 since it would be the owner of the copyright
with the ability to relicense.

>
>    It has been suggested that someone from the community could indemnify
>    John, but that doesn't make any sense to me - and it would be hard to
>    see how that in itself wouldn't require some kind of additional clause
>    which could in itself be seen as an additional restriction.
>
> 2. Someone creates a clean-room GPLv2 compatible softfloat
>    implementation.
>
> 3. Something else?
>
> As I will be away for the next week, and unable to deal with this in any
> way, I have taken the only option available to me at the present time and
> removed the offending code, which is a change I will be pushing upstream
> today.  This brings us back to a compliant situation, to the best of my
> knowledge.
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel



--
Jon Smirl
jonsmirl at gmail.com


From robherring2 at gmail.com  Wed Apr 10 14:33:37 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Wed, 10 Apr 2013 13:33:37 -0500
Subject: [PATCHv8 04/19] of/pci: Add of_pci_get_devfn() function
In-Reply-To: <1365541601-14095-5-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1365541601-14095-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1365541601-14095-5-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <5165B081.1030105@gmail.com>

On 04/09/2013 04:06 PM, Thomas Petazzoni wrote:
> From: Thierry Reding <thierry.reding at avionic-design.de>
> 
> This function can be used to parse the device and function number from a
> standard 5-cell PCI resource. PCI_SLOT() and PCI_FUNC() can be used on
> the returned value obtain the device and function numbers respectively.
> 
> Signed-off-by: Thierry Reding <thierry.reding at avionic-design.de>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>

Reviewed-by: Rob Herring <rob.herring at calxeda.com>

> ---
>  drivers/of/of_pci.c    |   34 +++++++++++++++++++++++++++++-----
>  include/linux/of_pci.h |    1 +
>  2 files changed, 30 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
> index ebb408b..b77e8d8 100644
> --- a/drivers/of/of_pci.c
> +++ b/drivers/of/of_pci.c
> @@ -9,14 +9,15 @@
>  #endif
>  
>  static inline int __of_pci_pci_compare(struct device_node *node,
> -				       unsigned int devfn)
> +				       unsigned int data)
>  {
> -	unsigned int size;
> -	const __be32 *reg = of_get_property(node, "reg", &size);
> +	int devfn;
>  
> -	if (!reg || size < 5 * sizeof(__be32))
> +	devfn = of_pci_get_devfn(node);
> +	if (devfn < 0)
>  		return 0;
> -	return ((be32_to_cpup(&reg[0]) >> 8) & 0xff) == devfn;
> +
> +	return devfn == data;
>  }
>  
>  struct device_node *of_pci_find_child_device(struct device_node *parent,
> @@ -208,3 +209,26 @@ void pci_process_bridge_OF_ranges(struct pci_controller *hose,
>  	}
>  }
>  #endif
> +
> +/**
> + * of_pci_get_devfn() - Get device and function numbers for a device node
> + * @np: device node
> + *
> + * Parses a standard 5-cell PCI resource and returns an 8-bit value that can
> + * be passed to the PCI_SLOT() and PCI_FUNC() macros to extract the device
> + * and function numbers respectively. On error a negative error code is
> + * returned.
> + */
> +int of_pci_get_devfn(struct device_node *np)
> +{
> +	unsigned int size;
> +	const __be32 *reg;
> +
> +	reg = of_get_property(np, "reg", &size);
> +
> +	if (!reg || size < 5 * sizeof(__be32))
> +		return -EINVAL;
> +
> +	return (be32_to_cpup(reg) >> 8) & 0xff;
> +}
> +EXPORT_SYMBOL_GPL(of_pci_get_devfn);
> diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
> index e56182f..302aca0 100644
> --- a/include/linux/of_pci.h
> +++ b/include/linux/of_pci.h
> @@ -11,6 +11,7 @@ int of_irq_map_pci(const struct pci_dev *pdev, struct of_irq *out_irq);
>  struct device_node;
>  struct device_node *of_pci_find_child_device(struct device_node *parent,
>  					     unsigned int devfn);
> +int of_pci_get_devfn(struct device_node *np);
>  
>  void pci_process_bridge_OF_ranges(struct pci_controller *hose,
>  			struct device_node *dev, int primary);
> 



From illia.ragozin at grapecom.com  Wed Apr 10 14:42:12 2013
From: illia.ragozin at grapecom.com (Elijah Ragozin)
Date: Wed, 10 Apr 2013 21:42:12 +0300
Subject: [PATCH RESEND v2 1/1] ARM Feroceon: fix kexec by setting
 outer_cache.inv_all
In-Reply-To: <20130410164805.GA28693@titan.lakedaemon.net>
References: <51631B12.2010908@grapecom.com> <51631BAF.40408@grapecom.com>
 <20130410164805.GA28693@titan.lakedaemon.net>
Message-ID: <5165B284.9020700@grapecom.com>

On 10.04.2013 19:48, Jason Cooper wrote:
> On Mon, Apr 08, 2013 at 10:34:07PM +0300, Elijah Ragozin wrote:
>> On Feroceon the L2 cache becomes non-coherent with the CPU
>> when the L1 caches are disabled. Thus the L2 needs to be invalidated
>> after both L1 caches are disabled.
>>
>> On kexec before the starting the code for relocation the kernel,
>> the L1 caches are disabled in cpu_froc_fin (cpu_v7_proc_fin for Feroceon),
>> but after L2 cache is never invalidated, because inv_all is not set
>> in cache-feroceon-l2.c.
>> So kernel relocation and decompression may has (and usually has) errors.
>> Setting the function enables L2 invalidation and fixes the issue.
>>
>> Signed-off-by: Illia Ragozin <illia.ragozin at grapecom.com>
>> ---
>>   arch/arm/mm/cache-feroceon-l2.c | 1 +
>>   1 file changed, 1 insertion(+)
> fwiw,
>
> Acked-by: Jason Cooper <jason at lakedaemon.net>
>
> Please put this in Russell King's patch tracker so he can pull it in.
>
> thx,
>
> Jason.
>

Jason,

thank you for reviewing and acking,
I just put the patch to the Russell King's patch tracker.

-- 
Best Regards,
Illia Ragozin.



From tony at atomide.com  Wed Apr 10 14:49:20 2013
From: tony at atomide.com (Tony Lindgren)
Date: Wed, 10 Apr 2013 11:49:20 -0700
Subject: [RFC][PATCH 1/2] ARM: OMAP4: clock: Add device tree support
 for AUXCLKs
In-Reply-To: <20130410173921.GA31017@kahuna>
References: <20130404164137.GH10155@atomide.com> <515EA9E3.1010409@ti.com>
 <20130405155851.GA10155@atomide.com> <5163E589.1040809@ti.com>
 <20130409164928.GL10155@atomide.com>
 <20130409174319.GP10155@atomide.com> <20130409204900.GA8815@kahuna>
 <20130410080630.14359.68178@quantum> <5165453E.6090503@ti.com>
 <20130410173921.GA31017@kahuna>
Message-ID: <20130410184919.GJ10155@atomide.com>

* Nishanth Menon <nm at ti.com> [130410 10:44]:
> Details in the patch below (Tony, I have added you as collaborator for
> helping in getting this working-clk_add_alias was'nt needed in the
> internal patch discussion we had - I have taken a bit of freedom in
> adding your contributions to the patch below)

OK thanks. Noticed few minor things, see below.
 
> Folks, this does seem to be the best compromise we can achieve at this
> point in time. feedback on this approach is much appreciated - if folks
> are ok, I can post this as an formal patch series.
> 
> From 130a41821bf57081ca45ef654029175d173135e6 Mon Sep 17 00:00:00 2001
> From: Nishanth Menon <nm at ti.com>
> Date: Tue, 9 Apr 2013 19:26:40 -0500
> Subject: [RFC PATCH] clk: OMAP: introduce device tree binding to kernel clock
>  data
> 
> OMAP clock data is located in arch/arm/mach-omap2/cclockXYZ_data.c.
> However, this presents an obstacle for using these clock nodes in
> Device Tree definitions. There are many possible approaches to this
> problem as discussed in the following thread:
> http://marc.info/?t=136370325600009&r=1&w=2

It might be worth clarifying that this is especially for the board
specific clocks initially. The fixed clocks are currently found via
the clock aliases table.

> Highlights of the options:
> a) device specific clk_add_alias:
> 	cons: driver handling required
> b) using an generic clk node and indexing to reach the clock required.
>    This is similar in approach taken by tegra and few other platforms.
>    example clock = <&clk 5>;
>    cons: potential to have mismatches in indexed table and associated
>    dtb data. In addition, managing continued documentation in bindings
>    as clock indexing increases. Even though readability angle could be
>    improved by using preprocessing of DT using macros, indexed approach
>    is inherently risky from cases like the following:
>    clk indexes in kernel:
>    1 - mpu_dpll
>    2 - aux_clk1
>    3 - core_clk
>    DT entry for peripheral x uses <&clk 2>, kernel updates to:
>    1 - mpu_dpll
>    2 - per_dpll
>    3 - aux_clk1
>    4 - core_clk
>    using the old dtb(or dts missing an update), on new kernel which has
>    updated indices will result in per_dpll now controlled for peripheral
>    X without warning or any potential error detection and warning.
> 
>    Even though we can claim this is user error, such errors are hard to
>    track down and fix.
> 
> An alternate approach introduced here is to introduce device tree bindings
> corresponding to the clock nodes required in DT definition for SoC which
> automatically maps back to the definitions in cclockXYZ_data.c.
> 
> The driver introduced here to do this mapping will eventually be the
> place where the clock handling will migrate to. We need to consider this
> angle as well so that the solution will be an valid transition point for
> moving the clock data out of kernel image (into device tree or firmware load
> etc..).
> 
> Overall strategy introduced here is simple: an clock node described in
> device tree blob is used to identify the exact clock provided in the SoC
> specific data. This is then linked back using of_clk_add_provider to the
> device node to be accessible by of_clk_get.
> 
> Based on discussion contributions from Roger Quadros, Grygorii Strashko
> and others.
> 
> [tony at atomide.com: co-developed]
> Signed-off-by: Tony Lindgren <tony at atomide.com>
> Signed-off-by: Nishanth Menon <nm at ti.com>
> ---
>  .../devicetree/bindings/clock/omap-clock.txt       |   40 +++++++++
>  drivers/clk/Makefile                               |    1 +
>  drivers/clk/omap/Makefile                          |    1 +
>  drivers/clk/omap/clk.c                             |   94 ++++++++++++++++++++
>  4 files changed, 136 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/clock/omap-clock.txt
>  create mode 100644 drivers/clk/omap/Makefile
>  create mode 100644 drivers/clk/omap/clk.c
> 
> diff --git a/Documentation/devicetree/bindings/clock/omap-clock.txt b/Documentation/devicetree/bindings/clock/omap-clock.txt
> new file mode 100644
> index 0000000..07e3ff8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/omap-clock.txt
> @@ -0,0 +1,40 @@
> +Device Tree Clock bindings for Texas Instrument's OMAP compatible platforms
> +
> +This binding is a work-in-progress, and meant to be stage #1 of transitioning
> +OMAP clock data out of kernel image.

As it's using the common clock binding, this will be supported in the
long run too. So maybe replace work-in-progress with initial minimal
binding that can be enhanced later on.

> +This binding uses the common clock binding[1].
> +
> +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
> +
> +Required properties:
> +- compatible : shall be "ti,omap-clock"
> +- #clock-cells : from common clock binding; shall be set to 0.
> +NOTE:
> +node name should map to clock database in arch/arm/mach-omap2/cclock<SoC>_data.c
> +Since all clocks are described with _ck, the node name is optimized to drop the
> +usage of _ck. For example, a clock called dpll1_ck will be defined as dpll1.
> +
> +Example #1: describing clock node for CPU on OMAP34xx platform:
> +Ref: arch/arm/mach-omap2/cclock3xxx_data.c
> +describes the CPU clock to be as follows
> +	CLK(NULL,	"dpll1_ck",	&dpll1_ck,	CK_3XXX),
> +Corresponding binding will be:
> +	dpll1: dpll1 {
> +		#clock-cells = <0>;
> +		compatible = "ti,omap-clock";
> +	};
> +And it's usage will be:
> +		clocks = <&dpll1>;
> +
> +Example #2: describing clock node for auxilary clock #3 on OMAP443x platform:
> +Ref: arch/arm/mach-omap2/cclock44xx_data.c
> +describes the auxclk3 clock to be as follows:
> +	CLK(NULL,	"auxclk3_ck",	&auxclk3_ck,	CK_443X),
> +Corresponding binding will be:
> +	auxclk3: auxclk3 {
> +		#clock-cells = <1>;
> +		compatible = "ti,omap-clock";
> +	};
> +And it's usage will be:
> +	clocks = <&auxclk3>;

The #clock-cells in the auxclk3 example should also be 0 instead of 1
AFAIK. We should only use #clock-cells = <1> when the same physical
clock provides multiple outputs. I believe the auxclocks are all separate,
but that needs to be verified.

> diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
> index 300d477..a0209d7 100644
> --- a/drivers/clk/Makefile
> +++ b/drivers/clk/Makefile
> @@ -27,6 +27,7 @@ obj-$(CONFIG_ARCH_U8500)	+= ux500/
>  obj-$(CONFIG_ARCH_VT8500)	+= clk-vt8500.o
>  obj-$(CONFIG_ARCH_ZYNQ)		+= clk-zynq.o
>  obj-$(CONFIG_ARCH_TEGRA)	+= tegra/
> +obj-$(CONFIG_ARCH_OMAP)		+= omap/
>  
>  obj-$(CONFIG_X86)		+= x86/
>  
> diff --git a/drivers/clk/omap/Makefile b/drivers/clk/omap/Makefile
> new file mode 100644
> index 0000000..8195931
> --- /dev/null
> +++ b/drivers/clk/omap/Makefile
> @@ -0,0 +1 @@
> +obj-y					+= clk.o
> diff --git a/drivers/clk/omap/clk.c b/drivers/clk/omap/clk.c
> new file mode 100644
> index 0000000..63a4cce
> --- /dev/null
> +++ b/drivers/clk/omap/clk.c
> @@ -0,0 +1,94 @@
> +/*
> + * Texas Instruments OMAP Clock driver
> + *
> + * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
> + *	Nishanth Menon
> + *	Tony Lindgren <tony at atomide.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.
> + *
> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
> + * kind, whether express or implied; without even the implied warranty
> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include <linux/clkdev.h>
> +#include <linux/clk-private.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/of_device.h>
> +#include <linux/platform_device.h>
> +#include <linux/string.h>
> +
> +static const struct of_device_id omap_clk_of_match[] = {
> +	{.compatible = "ti,omap-clock",},
> +	{},
> +};
> +
> +MODULE_DEVICE_TABLE(of, omap_clk_of_match);
> +
> +/**
> + * omap_clk_probe() - create link from DT definition to clock data
> + * @pdev:	device node
> + *
> + * REVISIT: We are now assuming the following:
> + * 1. omap clock names end with _ck
> + * 2. omap clocks don't get removed
> + */
> +static int omap_clk_probe(struct platform_device *pdev)
> +{
> +	struct clk *clk;
> +	int res;
> +
> +	const struct of_device_id *match;
> +	struct device_node *np = pdev->dev.of_node;
> +	char clk_name[32];
> +
> +	match = of_match_device(omap_clk_of_match, &pdev->dev);
> +
> +	/* Set up things so consumer can call clk_get() with name */
> +	snprintf(clk_name, 32, "%s_ck", np->name);
> +	clk = clk_get(NULL, clk_name);
> +	if (IS_ERR(clk)) {
> +		res = PTR_ERR(clk);
> +		dev_err(&pdev->dev, "could not get clock %s (%d)\n",
> +			clk_name, res);
> +		goto out;
> +	}

It seems that at least for now we can assume the naming will stay
that way, then if we need other rules for finding clocks, we can
add omap_match_clock() function or something.

> +	/* This allows the driver to of_clk_get() */
> +	res = of_clk_add_provider(np, of_clk_src_simple_get, clk);
> +	if (res)
> +		dev_err(&pdev->dev, "could not add provider for %s (%d)\n",
> +			clk_name, res);
> +
> +	clk_put(clk);
> +out:
> +	return res;
> +}

We can avoid the concern of storing the struct clk * and do the
look up lazily on consumer driver probe by setting a dummy struct
clk * here. Then replace of_clk_src_simple_get() with a custom
omap_clk_src_get() that does the lookup and replaces the struct
clk * with the real one.

> +MODULE_ALIAS("platform:omap_clk");
> +
> +/* We assume here that OMAP clocks will not be removed */
> +static struct platform_driver omap_clk_driver = {
> +	.probe = omap_clk_probe,
> +	.driver = {
> +		   .name = "omap_clk",
> +		   .owner = THIS_MODULE,
> +		   .of_match_table = of_match_ptr(omap_clk_of_match),
> +		   },
> +};
> +
> +static int __init omap_clk_init(void)
> +{
> +	return platform_driver_register(&omap_clk_driver);
> +}
> +
> +arch_initcall(omap_clk_init);
>
> +MODULE_DESCRIPTION("OMAP Clock driver");
> +MODULE_AUTHOR("Texas Instruments Inc.");
> +MODULE_LICENSE("GPL v2");

Regards,

Tony


From thomas.petazzoni at free-electrons.com  Wed Apr 10 14:51:02 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Wed, 10 Apr 2013 20:51:02 +0200
Subject: [PATCHv1 0/5] Marvell EBU irqchip improvements
In-Reply-To: <20130410183024.GB2275@localhost>
References: <1365542778-27959-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <20130410130902.GA29100@localhost> <20130410192106.73d81f2c@skate>
 <20130410183024.GB2275@localhost>
Message-ID: <20130410205102.0c7d3b53@skate>

Hello,

On Wed, 10 Apr 2013 15:30:25 -0300, Ezequiel Garcia wrote:

> Indeed it applies cleanly on v3.9-rc6, thank you. On my AXP and A370
> boards:
> 
> Tested-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>

Thanks for your testing!

Thomas (tglx), are you ok with the drivers/irqchip/ changes?

Thanks!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From robertcnelson at gmail.com  Wed Apr 10 14:54:08 2013
From: robertcnelson at gmail.com (Robert Nelson)
Date: Wed, 10 Apr 2013 13:54:08 -0500
Subject: [PATCH] ARM: at91/dts: at91sam9g20ek_2mmc: fix card detection
In-Reply-To: <1365613532-18919-1-git-send-email-robertcnelson@gmail.com>
References: <1365613532-18919-1-git-send-email-robertcnelson@gmail.com>
Message-ID: <CAOCHtYjqaiR9eiZ-CXHuHyB-bij0Ew6p930Nd88SmeFSHMMRZw@mail.gmail.com>

On Wed, Apr 10, 2013 at 12:05 PM, Robert Nelson <robertcnelson at gmail.com> wrote:
> Use cd-inverted to fix card detection on the at91sam9g20-ek Rev C Dev board.

Please Ignore this patch for now... As after more testing it looks
more like pinmux problem..  Aka removing a card (used to load
at91bootstrap/u-boot) during boot and then inserting the card again
after "Waiting for root device" shows up.. Results in nothing...

[    1.023437] atmel_mci fffa8000.mmc: version: 0x210
[    1.031250] atmel_mci fffa8000.mmc: no DMA channel available
[    1.039062] atmel_mci fffa8000.mmc: using PDC
[    1.132812] atmel_mci fffa8000.mmc: Atmel MCI controller at
0xfffa8000 irq 30, 2 slots
[    1.140625] Waiting for root device /dev/mmcblk0p2...

Regards,

-- 
Robert Nelson
http://www.rcn-ee.com/


From linux at arm.linux.org.uk  Wed Apr 10 14:54:21 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Wed, 10 Apr 2013 19:54:21 +0100
Subject: Removal of NWFPE in its entirety, and VFP emulation code
In-Reply-To: <yw1xip3u8uni.fsf@unicorn.mansr.com>
References: <20130410104002.GF14496@n2100.arm.linux.org.uk>
 <yw1xmwt68whw.fsf@unicorn.mansr.com>
 <20130410114229.GH14496@n2100.arm.linux.org.uk>
 <yw1xip3u8uni.fsf@unicorn.mansr.com>
Message-ID: <20130410185421.GI14496@n2100.arm.linux.org.uk>

On Wed, Apr 10, 2013 at 12:58:09PM +0100, M?ns Rullg?rd wrote:
> Russell King - ARM Linux <linux at arm.linux.org.uk> writes:
> 
> > On Wed, Apr 10, 2013 at 12:18:19PM +0100, M?ns Rullg?rd wrote:
> >> Russell King - ARM Linux <linux at arm.linux.org.uk> writes:
> >> 
> >> > The situation with VFP is likely less disruptive - only instructions
> >> > which aren't implemented in hardware (or, for example, if you ask for
> >> > inexact exceptions to be enabled) which are bounced to the software
> >> > support code will be affected.  I think OMAP should get away unscathed,
> >> > but ARM's implementation will bounce if inexact exceptions are enabled
> >> 
> >> What do you mean by this?  OMAP uses ARM's cores.
> >
> > OMAP's VFP reports that it never traps to support code for VFP instructions,
> > so the emulation code is never used on OMAP.
> 
> That is true for OMAP2 (ARM1136/VFP11) and OMAP3 (Cortex-A8).  OMAP4
> (Cortex-A9) and OMAP5 (Cortex-A15) both trap on vector operations.

No.  Both OMAP3 and OMAP4 report that they are VFP subarchitecture 3,
and the VFP subarchitecture 3 never traps to support code for any
instruction (it's the "null subarchitecture" value.)

These are the values reported by various platforms I have access to:

+ * Dove:  VFP support v0.3: implementor 56 architecture 2 part 20 variant 9 rev 5
+ * OMAP4: VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 1
+ * OMAP3: VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 1
+ * Pi:    VFP support v0.3: implementor 41 architecture 1 part 20 variant b rev 5

and "architecture" is actually the VFP subarchitecture number.


From linux at arm.linux.org.uk  Wed Apr 10 14:55:22 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Wed, 10 Apr 2013 19:55:22 +0100
Subject: Removal of NWFPE in its entirety, and VFP emulation code
In-Reply-To: <alpine.LFD.2.03.1304101307280.17375@syhkavp.arg>
References: <20130410104002.GF14496@n2100.arm.linux.org.uk>
 <alpine.LFD.2.03.1304101307280.17375@syhkavp.arg>
Message-ID: <20130410185522.GJ14496@n2100.arm.linux.org.uk>

On Wed, Apr 10, 2013 at 01:30:35PM -0400, Nicolas Pitre wrote:
> On Wed, 10 Apr 2013, Russell King - ARM Linux wrote:
> 
> > I have just committed a patch to remove the arch/arm/nwfpe code from
> > the kernel, and the VFP code emulating the FP operations.
> > 
> > This I have done after it has been brought to my attention by the OSADL's
> > GPL-violations project that the license for the softfloat library is
> > incompatible with GPLv2.  This is because the FSF have ruled that
> > indemnification clauses consitute an "additional restriction" which is
> > incompatible with the GPLv2 section 6.  NWFPE contains the softfloat
> > library, and VFP's emulation code is a derivative of softfloat.
> > 
> > This will be very disruptive for ARMv4 and ARMv5 CPUs, which will no
> > longer be able to run userspace with NWFPE support removed.  A possible
> > solution there is to resurrect FASTFPE support and merge that into
> > mainline in place of NWFPE.  FASTFPE's hooks are all present in the
> > kernel, and it should just be a case of adding the FASTFPE code.
> > However, FASTFPE is probably lacking GDB and signal stack support.
> > (FastFPE's per-thread workspace is different from NWFPE.)
> 
> A point worth mentioning is the EABI availability since 2006 which moved 
> away from FPA completely. A soft-float library in user space is used in 
> that case.  Major ARM binary producers including all ARM distros moved 
> to EABI with user space soft-float since then as it is order of 
> magnitude faster than FPA emulation.  So 99.99% of ARMv4 and ARMv5 users 
> are unlikely to be affected.
> 
> So another option here might imply deprecating OABI support entirely, 
> given that it is useless without FPA and people keeping current with the 
> latest kernel are very likely to already use EABI user space.

Unfortunately, I _still_ can't move off OABI.


From rjw at sisk.pl  Wed Apr 10 15:05:30 2013
From: rjw at sisk.pl (Rafael J. Wysocki)
Date: Wed, 10 Apr 2013 21:05:30 +0200
Subject: [RESEND PATCH] PM / Runtime: Idle devices asynchronously after
 probe|release
In-Reply-To: <1365606048-27603-1-git-send-email-ulf.hansson@stericsson.com>
References: <1365606048-27603-1-git-send-email-ulf.hansson@stericsson.com>
Message-ID: <2251384.jZjddUxBss@vostro.rjw.lan>

On Wednesday, April 10, 2013 05:00:48 PM Ulf Hansson wrote:
> From: Ulf Hansson <ulf.hansson at linaro.org>
> 
> Putting devices into idle|suspend in a synchronous manner means we are
> waiting for each device to become idle|suspended before the probe|release
> is fully done.
> 
> This patch switch to use the asynchronous runtime PM API:s instead and
> thus improves the parallelism since we can move on and handle the next
> device in queue in an earlier phase.

Acked-by: Rafael J. Wysocki <rafael.j.wysocki at intel.com>

> Signed-off-by: Ulf Hansson <ulf.hansson at linaro.org>
> Cc: Kevin Hilman <khilman at linaro.org>
> Cc: Alan Stern <stern at rowland.harvard.edu>
> Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
> ---
>  drivers/base/dd.c |    6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/base/dd.c b/drivers/base/dd.c
> index bb5645e..35fa368 100644
> --- a/drivers/base/dd.c
> +++ b/drivers/base/dd.c
> @@ -380,7 +380,7 @@ int driver_probe_device(struct device_driver *drv, struct device *dev)
>  
>  	pm_runtime_barrier(dev);
>  	ret = really_probe(dev, drv);
> -	pm_runtime_idle(dev);
> +	pm_request_idle(dev);
>  
>  	return ret;
>  }
> @@ -428,7 +428,7 @@ int device_attach(struct device *dev)
>  		}
>  	} else {
>  		ret = bus_for_each_drv(dev->bus, NULL, dev, __device_attach);
> -		pm_runtime_idle(dev);
> +		pm_request_idle(dev);
>  	}
>  out_unlock:
>  	device_unlock(dev);
> @@ -499,7 +499,7 @@ static void __device_release_driver(struct device *dev)
>  						     BUS_NOTIFY_UNBIND_DRIVER,
>  						     dev);
>  
> -		pm_runtime_put_sync(dev);
> +		pm_runtime_put(dev);
>  
>  		if (dev->bus && dev->bus->remove)
>  			dev->bus->remove(dev);
> 
-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.


From jason at lakedaemon.net  Wed Apr 10 14:57:57 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Wed, 10 Apr 2013 14:57:57 -0400
Subject: [PATCHv1 0/5] Marvell EBU irqchip improvements
In-Reply-To: <20130410205102.0c7d3b53@skate>
References: <1365542778-27959-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <20130410130902.GA29100@localhost> <20130410192106.73d81f2c@skate>
 <20130410183024.GB2275@localhost> <20130410205102.0c7d3b53@skate>
Message-ID: <20130410185757.GF28693@titan.lakedaemon.net>

Thomas (both),

On Wed, Apr 10, 2013 at 08:51:02PM +0200, Thomas Petazzoni wrote:
> On Wed, 10 Apr 2013 15:30:25 -0300, Ezequiel Garcia wrote:
> 
> > Indeed it applies cleanly on v3.9-rc6, thank you. On my AXP and A370
> > boards:
> > 
> > Tested-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
> 
> Thanks for your testing!
> 
> Thomas (tglx), are you ok with the drivers/irqchip/ changes?


Would it be alright if we took this series through arm-soc with your
Ack?  Unfortunately, I see no way to reorder it or split it up to
prevent cross tree dependencies.  Conflicts on your side should be
trivial.

thx,

Jason.


From nico at fluxnic.net  Wed Apr 10 14:58:57 2013
From: nico at fluxnic.net (Nicolas Pitre)
Date: Wed, 10 Apr 2013 14:58:57 -0400 (EDT)
Subject: Removal of NWFPE in its entirety, and VFP emulation code
In-Reply-To: <20130410185522.GJ14496@n2100.arm.linux.org.uk>
References: <20130410104002.GF14496@n2100.arm.linux.org.uk>
 <alpine.LFD.2.03.1304101307280.17375@syhkavp.arg>
 <20130410185522.GJ14496@n2100.arm.linux.org.uk>
Message-ID: <alpine.LFD.2.03.1304101457440.17375@syhkavp.arg>

On Wed, 10 Apr 2013, Russell King - ARM Linux wrote:

> On Wed, Apr 10, 2013 at 01:30:35PM -0400, Nicolas Pitre wrote:
> > On Wed, 10 Apr 2013, Russell King - ARM Linux wrote:
> > 
> > > I have just committed a patch to remove the arch/arm/nwfpe code from
> > > the kernel, and the VFP code emulating the FP operations.
> > > 
> > > This I have done after it has been brought to my attention by the OSADL's
> > > GPL-violations project that the license for the softfloat library is
> > > incompatible with GPLv2.  This is because the FSF have ruled that
> > > indemnification clauses consitute an "additional restriction" which is
> > > incompatible with the GPLv2 section 6.  NWFPE contains the softfloat
> > > library, and VFP's emulation code is a derivative of softfloat.
> > > 
> > > This will be very disruptive for ARMv4 and ARMv5 CPUs, which will no
> > > longer be able to run userspace with NWFPE support removed.  A possible
> > > solution there is to resurrect FASTFPE support and merge that into
> > > mainline in place of NWFPE.  FASTFPE's hooks are all present in the
> > > kernel, and it should just be a case of adding the FASTFPE code.
> > > However, FASTFPE is probably lacking GDB and signal stack support.
> > > (FastFPE's per-thread workspace is different from NWFPE.)
> > 
> > A point worth mentioning is the EABI availability since 2006 which moved 
> > away from FPA completely. A soft-float library in user space is used in 
> > that case.  Major ARM binary producers including all ARM distros moved 
> > to EABI with user space soft-float since then as it is order of 
> > magnitude faster than FPA emulation.  So 99.99% of ARMv4 and ARMv5 users 
> > are unlikely to be affected.
> > 
> > So another option here might imply deprecating OABI support entirely, 
> > given that it is useless without FPA and people keeping current with the 
> > latest kernel are very likely to already use EABI user space.
> 
> Unfortunately, I _still_ can't move off OABI.

How can this be helped?


Nicolas


From aaro.koskinen at iki.fi  Wed Apr 10 15:00:52 2013
From: aaro.koskinen at iki.fi (Aaro Koskinen)
Date: Wed, 10 Apr 2013 22:00:52 +0300
Subject: Removal of NWFPE in its entirety, and VFP emulation code
In-Reply-To: <alpine.LFD.2.03.1304101307280.17375@syhkavp.arg>
References: <20130410104002.GF14496@n2100.arm.linux.org.uk>
 <alpine.LFD.2.03.1304101307280.17375@syhkavp.arg>
Message-ID: <20130410190052.GC18196@blackmetal.musicnaut.iki.fi>

On Wed, Apr 10, 2013 at 01:30:35PM -0400, Nicolas Pitre wrote:
> On Wed, 10 Apr 2013, Russell King - ARM Linux wrote:
> 
> > I have just committed a patch to remove the arch/arm/nwfpe code from
> > the kernel, and the VFP code emulating the FP operations.
> > 
> > This I have done after it has been brought to my attention by the OSADL's
> > GPL-violations project that the license for the softfloat library is
> > incompatible with GPLv2.  This is because the FSF have ruled that
> > indemnification clauses consitute an "additional restriction" which is
> > incompatible with the GPLv2 section 6.  NWFPE contains the softfloat
> > library, and VFP's emulation code is a derivative of softfloat.
> > 
> > This will be very disruptive for ARMv4 and ARMv5 CPUs, which will no
> > longer be able to run userspace with NWFPE support removed.  A possible
> > solution there is to resurrect FASTFPE support and merge that into
> > mainline in place of NWFPE.  FASTFPE's hooks are all present in the
> > kernel, and it should just be a case of adding the FASTFPE code.
> > However, FASTFPE is probably lacking GDB and signal stack support.
> > (FastFPE's per-thread workspace is different from NWFPE.)
> 
> A point worth mentioning is the EABI availability since 2006 which moved 
> away from FPA completely. A soft-float library in user space is used in 
> that case.  Major ARM binary producers including all ARM distros moved 
> to EABI with user space soft-float since then as it is order of 
> magnitude faster than FPA emulation.  So 99.99% of ARMv4 and ARMv5 users 
> are unlikely to be affected.

Menuconfig mentions under "Floating point emulation" that "At least one
emulation must be selected". But if I compile my OS with EABI userspace
soft-float I guess I won't actually need to select any emulation,
or have I missed something? (I just checked my configs, and at least
on Kirkwood/openrd I have been already running without any emulation,
so I guess the help text is wrong?)

A.


From linux at arm.linux.org.uk  Wed Apr 10 15:02:33 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Wed, 10 Apr 2013 20:02:33 +0100
Subject: Removal of NWFPE in its entirety, and VFP emulation code
In-Reply-To: <alpine.LFD.2.03.1304101457440.17375@syhkavp.arg>
References: <20130410104002.GF14496@n2100.arm.linux.org.uk>
 <alpine.LFD.2.03.1304101307280.17375@syhkavp.arg>
 <20130410185522.GJ14496@n2100.arm.linux.org.uk>
 <alpine.LFD.2.03.1304101457440.17375@syhkavp.arg>
Message-ID: <20130410190233.GK14496@n2100.arm.linux.org.uk>

On Wed, Apr 10, 2013 at 02:58:57PM -0400, Nicolas Pitre wrote:
> On Wed, 10 Apr 2013, Russell King - ARM Linux wrote:
> 
> > On Wed, Apr 10, 2013 at 01:30:35PM -0400, Nicolas Pitre wrote:
> > > On Wed, 10 Apr 2013, Russell King - ARM Linux wrote:
> > > 
> > > > I have just committed a patch to remove the arch/arm/nwfpe code from
> > > > the kernel, and the VFP code emulating the FP operations.
> > > > 
> > > > This I have done after it has been brought to my attention by the OSADL's
> > > > GPL-violations project that the license for the softfloat library is
> > > > incompatible with GPLv2.  This is because the FSF have ruled that
> > > > indemnification clauses consitute an "additional restriction" which is
> > > > incompatible with the GPLv2 section 6.  NWFPE contains the softfloat
> > > > library, and VFP's emulation code is a derivative of softfloat.
> > > > 
> > > > This will be very disruptive for ARMv4 and ARMv5 CPUs, which will no
> > > > longer be able to run userspace with NWFPE support removed.  A possible
> > > > solution there is to resurrect FASTFPE support and merge that into
> > > > mainline in place of NWFPE.  FASTFPE's hooks are all present in the
> > > > kernel, and it should just be a case of adding the FASTFPE code.
> > > > However, FASTFPE is probably lacking GDB and signal stack support.
> > > > (FastFPE's per-thread workspace is different from NWFPE.)
> > > 
> > > A point worth mentioning is the EABI availability since 2006 which moved 
> > > away from FPA completely. A soft-float library in user space is used in 
> > > that case.  Major ARM binary producers including all ARM distros moved 
> > > to EABI with user space soft-float since then as it is order of 
> > > magnitude faster than FPA emulation.  So 99.99% of ARMv4 and ARMv5 users 
> > > are unlikely to be affected.
> > > 
> > > So another option here might imply deprecating OABI support entirely, 
> > > given that it is useless without FPA and people keeping current with the 
> > > latest kernel are very likely to already use EABI user space.
> > 
> > Unfortunately, I _still_ can't move off OABI.
> 
> How can this be helped?

I don't think there is a solution - as StrongARM is ARMv4 without Thumb
support, which means that it's incompatible with EABI which uses bx and
blx instructions.


From nico at fluxnic.net  Wed Apr 10 15:03:37 2013
From: nico at fluxnic.net (Nicolas Pitre)
Date: Wed, 10 Apr 2013 15:03:37 -0400 (EDT)
Subject: Removal of NWFPE in its entirety, and VFP emulation code
In-Reply-To: <20130410190052.GC18196@blackmetal.musicnaut.iki.fi>
References: <20130410104002.GF14496@n2100.arm.linux.org.uk>
 <alpine.LFD.2.03.1304101307280.17375@syhkavp.arg>
 <20130410190052.GC18196@blackmetal.musicnaut.iki.fi>
Message-ID: <alpine.LFD.2.03.1304101502090.17375@syhkavp.arg>

On Wed, 10 Apr 2013, Aaro Koskinen wrote:

> On Wed, Apr 10, 2013 at 01:30:35PM -0400, Nicolas Pitre wrote:
> > On Wed, 10 Apr 2013, Russell King - ARM Linux wrote:
> > 
> > > I have just committed a patch to remove the arch/arm/nwfpe code from
> > > the kernel, and the VFP code emulating the FP operations.
> > > 
> > > This I have done after it has been brought to my attention by the OSADL's
> > > GPL-violations project that the license for the softfloat library is
> > > incompatible with GPLv2.  This is because the FSF have ruled that
> > > indemnification clauses consitute an "additional restriction" which is
> > > incompatible with the GPLv2 section 6.  NWFPE contains the softfloat
> > > library, and VFP's emulation code is a derivative of softfloat.
> > > 
> > > This will be very disruptive for ARMv4 and ARMv5 CPUs, which will no
> > > longer be able to run userspace with NWFPE support removed.  A possible
> > > solution there is to resurrect FASTFPE support and merge that into
> > > mainline in place of NWFPE.  FASTFPE's hooks are all present in the
> > > kernel, and it should just be a case of adding the FASTFPE code.
> > > However, FASTFPE is probably lacking GDB and signal stack support.
> > > (FastFPE's per-thread workspace is different from NWFPE.)
> > 
> > A point worth mentioning is the EABI availability since 2006 which moved 
> > away from FPA completely. A soft-float library in user space is used in 
> > that case.  Major ARM binary producers including all ARM distros moved 
> > to EABI with user space soft-float since then as it is order of 
> > magnitude faster than FPA emulation.  So 99.99% of ARMv4 and ARMv5 users 
> > are unlikely to be affected.
> 
> Menuconfig mentions under "Floating point emulation" that "At least one
> emulation must be selected". But if I compile my OS with EABI userspace
> soft-float I guess I won't actually need to select any emulation,
> or have I missed something? (I just checked my configs, and at least
> on Kirkwood/openrd I have been already running without any emulation,
> so I guess the help text is wrong?)

It is wrong in the EABI case.  This help text probably predates the 
introduction of EABI.


Nicolas


From ezequiel.garcia at free-electrons.com  Wed Apr 10 15:03:59 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Wed, 10 Apr 2013 16:03:59 -0300
Subject: [PATCH v7 0/5] Device Bus support for Marvell EBU SoC
Message-ID: <1365620644-15790-1-git-send-email-ezequiel.garcia@free-electrons.com>

This patchset continues the effort to add Device Bus support
on Marvell EBU SoC.

If you're reading this for the first time you can grab the full details here:

  http://www.spinics.net/lists/arm-kernel/msg236151.html

This new version changes the way each chip select is described in the DT.
Now there's a separate node for each Device Bus chip select, like this:

	devbus-bootcs at d0010400 {
		compatible = "marvell,mvebu-devbus";
		reg = <0xd0010400 0x8>;
		ranges = <0 0xf0000000 0x8000000>; /* @addr 0xf000000, size 0x8000000 */

		device at 0 {
			reg = <0 0x8000000>;
		}
	};

	// ...

	devbus-cs1 at d0010410 {
		compatible = "marvell,mvebu-devbus";
		reg = <0xd0010410 0x8>;
	};

In particular, please note that once the window handling is properly added
to the DT, and we remove the mbus usage from this driver, in the above DT nodes
the ranges property value will have to be changed, but the ABI will be the same.

This applies on top of v3.9-rc6 with mbus patches applied, which can 
be found in Jason Cooper's mvebus/soc branch.

Changes from v6:
 
  * Rework shamelessly dirty 'ranges' parsing,
    as suggested by Jason Gunthorpe.

Changes from v5:
  Pointed out by both Arnd Bergmann and Jason Gunthorpe (thanks!):

  * Instead of translating the child address, parse the 'ranges'
    property. This is possible because the 'ranges' is mandatory
    and will a single entry to describing the address window.
    This allows to remove every reference to child nodes, and will
    be removed later, once the mbus binding is added.

  * Use of_platform_populate to register all child nodes.
    This way we solve the one-child only constraint present
    in the previous v5 of this series.

  * Rework the driver registration. Now there's a module_init()
    to register the platform driver, but there's no module_exit()
    to unregister it. This is done because currently there's no
    function opposite to of_platform_populate() to unregister all
    devices from a DT tree.

Changes from v4:

  * Calculate the chip select from the base address
    and drop the 2-cell address size.
    Suggested by Arnd Bergmann and Jason Gunthorpe.

  * The mvebu driver can't be compiled as a module, since the mbus
    API is not exported yet, so remove that option.

  * Bunch of comments here and there...

Changes from v3:

  * Rename devbus,dev-width to devbus,bus-width and changed the
    parameter value from bytes to bits: <8>, <16>, ...
    Suggested by Arnd Bergmann.

  * As suggested by Jason Gunthorpe and agreed by Arnd Bergmann.
    Reworked the whole devbus child chip-select device tree design.
    Now there's a separate devbus at addr DT node for each controller
    chip select. The impact of this is:
      1. Timing parameters now go into the parent node.
      2. There can only be one child per devbus node.

  * Remove unneeded bank-width parameter read.

Changes from v2:

  * Replace the 'NOR' specific probe by a generic probe.
    Currently, we don't see anything specific to NOR in this driver.
    Suggested by Jason Gunthorpe.

  * Add a check to detect that every timing parameter is specified
    in the device tree node.
    Suggested by Jason Gunthorpe.

Changes from v1:

  * Added a remove() function to unregister childs and remove address windows,
    as suggested by Thomas Petazzoni.

  * Remove unneeded 'inline' prefix on functions as suggested by Thomas Petazzoni.

  * Timings parameters are now mandatory and expressed in picoseconds,
    as requested by Jason Gunthorpe.
    This is consistent with OMAP's GPMC dts binding.

  * Fix documentation as suggested by Jason Gunthorpe.

Thanks!

Ezequiel Garcia (5):
  drivers: memory: Introduce Marvell EBU Device Bus driver
  ARM: mvebu: Add Device Bus support for Armada 370/XP SoC
  ARM: mvebu: Add support for NOR flash device on Armada XP-GP board
  ARM: mvebu: Add support for NOR flash device on Openblocks AX3 board
  ARM: mvebu: Add Device Bus and CFI flash memory support to defconfig

 .../bindings/memory-controllers/mvebu-devbus.txt   | 156 ++++++++++
 arch/arm/boot/dts/armada-370-xp.dtsi               |  45 +++
 arch/arm/boot/dts/armada-xp-gp.dts                 |  29 ++
 arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts   |  29 ++
 arch/arm/configs/mvebu_defconfig                   |   7 +
 drivers/memory/Kconfig                             |  10 +
 drivers/memory/Makefile                            |   1 +
 drivers/memory/mvebu-devbus.c                      | 340 +++++++++++++++++++++
 8 files changed, 617 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/memory-controllers/mvebu-devbus.txt
 create mode 100644 drivers/memory/mvebu-devbus.c

-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Wed Apr 10 15:04:00 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Wed, 10 Apr 2013 16:04:00 -0300
Subject: [PATCH v7 1/5] drivers: memory: Introduce Marvell EBU Device Bus
 driver
In-Reply-To: <1365620644-15790-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1365620644-15790-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1365620644-15790-2-git-send-email-ezequiel.garcia@free-electrons.com>

Marvell EBU SoCs such as Armada 370/XP, Orion5x (88f5xxx) and
Discovery (mv78xx0) supports a Device Bus controller to access several
kinds of memories and I/O devices (NOR, NAND, SRAM, FPGA).

This commit adds a driver to handle this controller. So far only
Armada 370, Armada XP and Discovery SoCs are supported.

The driver must be registered through a device tree node;
as explained in the binding document.

For each child node in the device tree, this driver will:
  * set timing parameters
  * register a child device
  * setup an address decoding window, using the mbus driver

Keep in mind the address decoding window setup is only a temporary hack.
This code will be removed from this devbus driver as soon as a proper device
tree binding for the mbus driver is added.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
Acked-by: Arnd Bergmann <arnd at arndb.de>
---
 .../bindings/memory-controllers/mvebu-devbus.txt   | 156 ++++++++++
 drivers/memory/Kconfig                             |  10 +
 drivers/memory/Makefile                            |   1 +
 drivers/memory/mvebu-devbus.c                      | 340 +++++++++++++++++++++
 4 files changed, 507 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/memory-controllers/mvebu-devbus.txt
 create mode 100644 drivers/memory/mvebu-devbus.c

diff --git a/Documentation/devicetree/bindings/memory-controllers/mvebu-devbus.txt b/Documentation/devicetree/bindings/memory-controllers/mvebu-devbus.txt
new file mode 100644
index 0000000..653c90c
--- /dev/null
+++ b/Documentation/devicetree/bindings/memory-controllers/mvebu-devbus.txt
@@ -0,0 +1,156 @@
+Device tree bindings for MVEBU Device Bus controllers
+
+The Device Bus controller available in some Marvell's SoC allows to control
+different types of standard memory and I/O devices such as NOR, NAND, and FPGA.
+The actual devices are instantiated from the child nodes of a Device Bus node.
+
+Required properties:
+
+ - compatible:          Currently only Armada 370/XP SoC are supported,
+                        with this compatible string:
+
+                        marvell,mvebu-devbus
+
+ - reg:                 A resource specifier for the register space.
+                        This is the base address of a chip select within
+			the controller's register space.
+                        (see the example below)
+
+ - #address-cells:      Must be set to 1
+ - #size-cells:         Must be set to 1
+ - ranges:              Must be set up to reflect the memory layout with four
+                        integer values for each chip-select line in use:
+                        0 <physical address of mapping> <size>
+
+Mandatory timing properties for child nodes:
+
+Read parameters:
+
+ - devbus,turn-off-ps:  Defines the time during which the controller does not
+                        drive the AD bus after the completion of a device read.
+                        This prevents contentions on the Device Bus after a read
+                        cycle from a slow device.
+
+ - devbus,bus-width:    Defines the bus width (e.g. <16>)
+
+ - devbus,badr-skew-ps: Defines the time delay from from A[2:0] toggle,
+                        to read data sample. This parameter is useful for
+                        synchronous pipelined devices, where the address
+                        precedes the read data by one or two cycles.
+
+ - devbus,acc-first-ps: Defines the time delay from the negation of
+                        ALE[0] to the cycle that the first read data is sampled
+                        by the controller.
+
+ - devbus,acc-next-ps:  Defines the time delay between the cycle that
+                        samples data N and the cycle that samples data N+1
+                        (in burst accesses).
+
+ - devbus,rd-setup-ps:  Defines the time delay between DEV_CSn assertion to
+			DEV_OEn assertion. If set to 0 (default),
+                        DEV_OEn and DEV_CSn are asserted at the same cycle.
+                        This parameter has no affect on <acc-first-ps> parameter
+                        (no affect on first data sample). Set <rd-setup-ps>
+                        to a value smaller than <acc-first-ps>.
+
+ - devbus,rd-hold-ps:   Defines the time between the last data sample to the
+			de-assertion of DEV_CSn. If set to 0 (default),
+			DEV_OEn and DEV_CSn are de-asserted at the same cycle
+			(the cycle of the last data sample).
+                        This parameter has no affect on DEV_OEn de-assertion.
+                        DEV_OEn is always de-asserted the next cycle after
+                        last data sampled. Also this parameter has no
+                        affect on <turn-off-ps> parameter.
+                        Set <rd-hold-ps> to a value smaller than <turn-off-ps>.
+
+Write parameters:
+
+ - devbus,ale-wr-ps:    Defines the time delay from the ALE[0] negation cycle
+			to the DEV_WEn assertion.
+
+ - devbus,wr-low-ps:    Defines the time during which DEV_WEn is active.
+                        A[2:0] and Data are kept valid as long as DEV_WEn
+                        is active. This parameter defines the setup time of
+                        address and data to DEV_WEn rise.
+
+ - devbus,wr-high-ps:   Defines the time during which DEV_WEn is kept
+                        inactive (high) between data beats of a burst write.
+                        DEV_A[2:0] and Data are kept valid (do not toggle) for
+                        <wr-high-ps> - <tick> ps.
+			This parameter defines the hold time of address and
+			data after DEV_WEn rise.
+
+ - devbus,sync-enable: Synchronous device enable.
+                       1: True
+                       0: False
+
+An example for an Armada XP GP board, with a 16 MiB NOR device as child
+is showed below. Note that the Device Bus driver is in charge of allocating
+the mbus address decoding window for each of its child devices.
+The window is created using the chip select specified in the child
+device node together with the base address and size specified in the ranges
+property. For instance, in the example below the allocated decoding window
+will start at base address 0xf0000000, with a size 0x1000000 (16 MiB)
+for chip select 0 (a.k.a DEV_BOOTCS).
+
+This address window handling is done in this mvebu-devbus only as a temporary
+solution. It will be removed when the support for mbus device tree binding is
+added.
+
+The reg property implicitly specifies the chip select as this:
+
+  0x10400: DEV_BOOTCS
+  0x10408: DEV_CS0
+  0x10410: DEV_CS1
+  0x10418: DEV_CS2
+  0x10420: DEV_CS3
+
+Example:
+
+	devbus-bootcs at d0010400 {
+		status = "okay";
+		ranges = <0 0xf0000000 0x1000000>; /* @addr 0xf0000000, size 0x1000000 */
+		#address-cells = <1>;
+		#size-cells = <1>;
+
+		/* Device Bus parameters are required */
+
+		/* Read parameters */
+		devbus,bus-width    = <8>;
+		devbus,turn-off-ps  = <60000>;
+		devbus,badr-skew-ps = <0>;
+		devbus,acc-first-ps = <124000>;
+		devbus,acc-next-ps  = <248000>;
+		devbus,rd-setup-ps  = <0>;
+		devbus,rd-hold-ps   = <0>;
+
+		/* Write parameters */
+		devbus,sync-enable = <0>;
+		devbus,wr-high-ps  = <60000>;
+		devbus,wr-low-ps   = <60000>;
+		devbus,ale-wr-ps   = <60000>;
+
+		flash at 0 {
+			compatible = "cfi-flash";
+
+			/* 16 MiB */
+			reg = <0 0x1000000>;
+			bank-width = <2>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+
+			/*
+			 * We split the 16 MiB in two partitions,
+			 * just as an example.
+			 */
+			partition at 0 {
+				label = "First";
+				reg = <0 0x800000>;
+			};
+
+			partition at 800000 {
+				label = "Second";
+				reg = <0x800000 0x800000>;
+			};
+		};
+	};
diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig
index 067f311..29a11db 100644
--- a/drivers/memory/Kconfig
+++ b/drivers/memory/Kconfig
@@ -20,6 +20,16 @@ config TI_EMIF
 	  parameters and other settings during frequency, voltage and
 	  temperature changes
 
+config MVEBU_DEVBUS
+	bool "Marvell EBU Device Bus Controller"
+	default y
+	depends on PLAT_ORION && OF
+	help
+	  This driver is for the Device Bus controller available in some
+	  Marvell EBU SoCs such as Discovery (mv78xx0), Orion (88f5xxx) and
+	  Armada 370 and Armada XP. This controller allows to handle flash
+	  devices such as NOR, NAND, SRAM, and FPGA.
+
 config TEGRA20_MC
 	bool "Tegra20 Memory Controller(MC) driver"
 	default y
diff --git a/drivers/memory/Makefile b/drivers/memory/Makefile
index 9cce5d7..969d923 100644
--- a/drivers/memory/Makefile
+++ b/drivers/memory/Makefile
@@ -6,5 +6,6 @@ ifeq ($(CONFIG_DDR),y)
 obj-$(CONFIG_OF)		+= of_memory.o
 endif
 obj-$(CONFIG_TI_EMIF)		+= emif.o
+obj-$(CONFIG_MVEBU_DEVBUS)	+= mvebu-devbus.o
 obj-$(CONFIG_TEGRA20_MC)	+= tegra20-mc.o
 obj-$(CONFIG_TEGRA30_MC)	+= tegra30-mc.o
diff --git a/drivers/memory/mvebu-devbus.c b/drivers/memory/mvebu-devbus.c
new file mode 100644
index 0000000..978e8e3
--- /dev/null
+++ b/drivers/memory/mvebu-devbus.c
@@ -0,0 +1,340 @@
+/*
+ * Marvell EBU SoC Device Bus Controller
+ * (memory controller for NOR/NAND/SRAM/FPGA devices)
+ *
+ * Copyright (C) 2013 Marvell
+ *
+ * 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 version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
+ *
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/slab.h>
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/clk.h>
+#include <linux/mbus.h>
+#include <linux/of_platform.h>
+#include <linux/of_address.h>
+#include <linux/platform_device.h>
+
+/* Register definitions */
+#define DEV_WIDTH_BIT		30
+#define BADR_SKEW_BIT		28
+#define RD_HOLD_BIT		23
+#define ACC_NEXT_BIT		17
+#define RD_SETUP_BIT		12
+#define ACC_FIRST_BIT		6
+
+#define SYNC_ENABLE_BIT		24
+#define WR_HIGH_BIT		16
+#define WR_LOW_BIT		8
+
+#define READ_PARAM_OFFSET	0x0
+#define WRITE_PARAM_OFFSET	0x4
+
+static const char * const devbus_wins[] = {
+	"devbus-boot",
+	"devbus-cs0",
+	"devbus-cs1",
+	"devbus-cs2",
+	"devbus-cs3",
+};
+
+struct devbus_read_params {
+	u32 bus_width;
+	u32 badr_skew;
+	u32 turn_off;
+	u32 acc_first;
+	u32 acc_next;
+	u32 rd_setup;
+	u32 rd_hold;
+};
+
+struct devbus_write_params {
+	u32 sync_enable;
+	u32 wr_high;
+	u32 wr_low;
+	u32 ale_wr;
+};
+
+struct devbus {
+	struct device *dev;
+	void __iomem *base;
+	unsigned long tick_ps;
+};
+
+static int get_timing_param_ps(struct devbus *devbus,
+			       struct device_node *node,
+			       const char *name,
+			       u32 *ticks)
+{
+	u32 time_ps;
+	int err;
+
+	err = of_property_read_u32(node, name, &time_ps);
+	if (err < 0) {
+		dev_err(devbus->dev, "%s has no '%s' property\n",
+			name, node->full_name);
+		return err;
+	}
+
+	*ticks = (time_ps + devbus->tick_ps - 1) / devbus->tick_ps;
+
+	dev_dbg(devbus->dev, "%s: %u ps -> 0x%x\n",
+		name, time_ps, *ticks);
+	return 0;
+}
+
+static int devbus_set_timing_params(struct devbus *devbus,
+				    struct device_node *node)
+{
+	struct devbus_read_params r;
+	struct devbus_write_params w;
+	u32 value;
+	int err;
+
+	dev_dbg(devbus->dev, "Setting timing parameter, tick is %lu ps\n",
+		devbus->tick_ps);
+
+	/* Get read timings */
+	err = of_property_read_u32(node, "devbus,bus-width", &r.bus_width);
+	if (err < 0) {
+		dev_err(devbus->dev,
+			"%s has no 'devbus,bus-width' property\n",
+			node->full_name);
+		return err;
+	}
+	/* Convert bit width to byte width */
+	r.bus_width /= 8;
+
+	err = get_timing_param_ps(devbus, node, "devbus,badr-skew-ps",
+				 &r.badr_skew);
+	if (err < 0)
+		return err;
+
+	err = get_timing_param_ps(devbus, node, "devbus,turn-off-ps",
+				 &r.turn_off);
+	if (err < 0)
+		return err;
+
+	err = get_timing_param_ps(devbus, node, "devbus,acc-first-ps",
+				 &r.acc_first);
+	if (err < 0)
+		return err;
+
+	err = get_timing_param_ps(devbus, node, "devbus,acc-next-ps",
+				 &r.acc_next);
+	if (err < 0)
+		return err;
+
+	err = get_timing_param_ps(devbus, node, "devbus,rd-setup-ps",
+				 &r.rd_setup);
+	if (err < 0)
+		return err;
+
+	err = get_timing_param_ps(devbus, node, "devbus,rd-hold-ps",
+				 &r.rd_hold);
+	if (err < 0)
+		return err;
+
+	/* Get write timings */
+	err = of_property_read_u32(node, "devbus,sync-enable",
+				  &w.sync_enable);
+	if (err < 0) {
+		dev_err(devbus->dev,
+			"%s has no 'devbus,sync-enable' property\n",
+			node->full_name);
+		return err;
+	}
+
+	err = get_timing_param_ps(devbus, node, "devbus,ale-wr-ps",
+				 &w.ale_wr);
+	if (err < 0)
+		return err;
+
+	err = get_timing_param_ps(devbus, node, "devbus,wr-low-ps",
+				 &w.wr_low);
+	if (err < 0)
+		return err;
+
+	err = get_timing_param_ps(devbus, node, "devbus,wr-high-ps",
+				 &w.wr_high);
+	if (err < 0)
+		return err;
+
+	/* Set read timings */
+	value = r.bus_width << DEV_WIDTH_BIT |
+		r.badr_skew << BADR_SKEW_BIT |
+		r.rd_hold   << RD_HOLD_BIT   |
+		r.acc_next  << ACC_NEXT_BIT  |
+		r.rd_setup  << RD_SETUP_BIT  |
+		r.acc_first << ACC_FIRST_BIT |
+		r.turn_off;
+
+	dev_dbg(devbus->dev, "read parameters register 0x%p = 0x%x\n",
+		devbus->base + READ_PARAM_OFFSET,
+		value);
+
+	writel(value, devbus->base + READ_PARAM_OFFSET);
+
+	/* Set write timings */
+	value = w.sync_enable  << SYNC_ENABLE_BIT |
+		w.wr_low       << WR_LOW_BIT      |
+		w.wr_high      << WR_HIGH_BIT     |
+		w.ale_wr;
+
+	dev_dbg(devbus->dev, "write parameters register: 0x%p = 0x%x\n",
+		devbus->base + WRITE_PARAM_OFFSET,
+		value);
+
+	writel(value, devbus->base + WRITE_PARAM_OFFSET);
+
+	return 0;
+}
+
+static int mvebu_devbus_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct device_node *node = pdev->dev.of_node;
+	struct device_node *parent;
+	struct devbus *devbus;
+	struct resource *res;
+	struct clk *clk;
+	unsigned long rate;
+	const __be32 *ranges;
+	int err, cs;
+	int addr_cells, p_addr_cells, size_cells;
+	int ranges_len, tuple_len;
+	u32 base, size;
+
+	devbus = devm_kzalloc(&pdev->dev, sizeof(struct devbus), GFP_KERNEL);
+	if (!devbus)
+		return -ENOMEM;
+
+	devbus->dev = dev;
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	devbus->base = devm_ioremap_resource(&pdev->dev, res);
+	if (IS_ERR(devbus->base))
+		return PTR_ERR(devbus->base);
+
+	clk = devm_clk_get(&pdev->dev, NULL);
+	if (IS_ERR(clk))
+		return PTR_ERR(clk);
+	clk_prepare_enable(clk);
+
+	/*
+	 * Obtain clock period in picoseconds,
+	 * we need this in order to convert timing
+	 * parameters from cycles to picoseconds.
+	 */
+	rate = clk_get_rate(clk) / 1000;
+	devbus->tick_ps = 1000000000 / rate;
+
+	/* Read the device tree node and set the new timing parameters */
+	err = devbus_set_timing_params(devbus, node);
+	if (err < 0)
+		return err;
+
+	/*
+	 * Allocate an address window for this device.
+	 * If the device probing fails, then we won't be able to
+	 * remove the allocated address decoding window.
+	 *
+	 * FIXME: This is only a temporary hack! We need to do this here
+	 * because we still don't have device tree bindings for mbus.
+	 * Once that support is added, we will declare these address windows
+	 * statically in the device tree, and remove the window configuration
+	 * from here.
+	 */
+
+	/*
+	 * Get the CS to choose the window string.
+	 * This is a bit hacky, but it will be removed once the
+	 * address windows are declared in the device tree.
+	 */
+	cs = (((unsigned long)devbus->base) % 0x400) / 8;
+
+	/*
+	 * Parse 'ranges' property to obtain a (base,size) window tuple.
+	 * This will be removed once the address windows
+	 * are declared in the device tree.
+	 */
+	parent = of_get_parent(node);
+	if (!parent)
+		return -EINVAL;
+
+	p_addr_cells = of_n_addr_cells(parent);
+	of_node_put(parent);
+
+	addr_cells = of_n_addr_cells(node);
+	size_cells = of_n_size_cells(node);
+	tuple_len = (p_addr_cells + addr_cells + size_cells) * sizeof(__be32);
+
+	ranges = of_get_property(node, "ranges", &ranges_len);
+	if (ranges == NULL || ranges_len != tuple_len)
+		return -EINVAL;
+
+	base = of_translate_address(node, ranges + addr_cells);
+	if (base == OF_BAD_ADDR)
+		return -EINVAL;
+	size = of_read_number(ranges + addr_cells + p_addr_cells, size_cells);
+
+	/*
+	 * Create an mbus address windows.
+	 * FIXME: Remove this, together with the above code, once the
+	 * address windows are declared in the device tree.
+	 */
+	err = mvebu_mbus_add_window(devbus_wins[cs], base, size);
+	if (err < 0)
+		return err;
+
+	/*
+	 * We need to create a child device explicitly from here to
+	 * guarantee that the child will be probed after the timing
+	 * parameters for the bus are written.
+	 */
+	err = of_platform_populate(node, NULL, NULL, dev);
+	if (err < 0) {
+		mvebu_mbus_del_window(base, size);
+		return err;
+	}
+
+	return 0;
+}
+
+static const struct of_device_id mvebu_devbus_of_match[] = {
+	{ .compatible = "marvell,mvebu-devbus" },
+	{},
+};
+MODULE_DEVICE_TABLE(of, mvebu_devbus_of_match);
+
+static struct platform_driver mvebu_devbus_driver = {
+	.probe		= mvebu_devbus_probe,
+	.driver		= {
+		.name	= "mvebu-devbus",
+		.owner	= THIS_MODULE,
+		.of_match_table = mvebu_devbus_of_match,
+	},
+};
+
+static int __init mvebu_devbus_init(void)
+{
+	return platform_driver_register(&mvebu_devbus_driver);
+}
+module_init(mvebu_devbus_init);
+
+MODULE_LICENSE("GPL v2");
+MODULE_AUTHOR("Ezequiel Garcia <ezequiel.garcia at free-electrons.com>");
+MODULE_DESCRIPTION("Marvell EBU SoC Device Bus controller");
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Wed Apr 10 15:04:01 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Wed, 10 Apr 2013 16:04:01 -0300
Subject: [PATCH v7 2/5] ARM: mvebu: Add Device Bus support for Armada 370/XP
 SoC
In-Reply-To: <1365620644-15790-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1365620644-15790-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1365620644-15790-3-git-send-email-ezequiel.garcia@free-electrons.com>

Armada 370 and Armada XP SoC have a Device Bus controller to
handle NOR, NAND, SRAM and FPGA devices.
This patch adds the device tree node to enable the controller.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
Acked-by: Arnd Bergmann <arnd at arndb.de>
---
 arch/arm/boot/dts/armada-370-xp.dtsi | 45 ++++++++++++++++++++++++++++++++++++
 1 file changed, 45 insertions(+)

diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi b/arch/arm/boot/dts/armada-370-xp.dtsi
index 7704829..9693f79 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -176,6 +176,51 @@
 			clocks = <&coreclk 0>;
 			status = "disabled";
 		};
+
+		devbus-bootcs at d0010400 {
+			compatible = "marvell,mvebu-devbus";
+			reg = <0xd0010400 0x8>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			clocks = <&coreclk 0>;
+			status = "disabled";
+		};
+
+		devbus-cs0 at d0010408 {
+			compatible = "marvell,mvebu-devbus";
+			reg = <0xd0010408 0x8>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			clocks = <&coreclk 0>;
+			status = "disabled";
+		};
+
+		devbus-cs1 at d0010410 {
+			compatible = "marvell,mvebu-devbus";
+			reg = <0xd0010410 0x8>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			clocks = <&coreclk 0>;
+			status = "disabled";
+		};
+
+		devbus-cs2 at d0010418 {
+			compatible = "marvell,mvebu-devbus";
+			reg = <0xd0010418 0x8>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			clocks = <&coreclk 0>;
+			status = "disabled";
+		};
+
+		devbus-cs3 at d0010420 {
+			compatible = "marvell,mvebu-devbus";
+			reg = <0xd0010420 0x8>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			clocks = <&coreclk 0>;
+			status = "disabled";
+		};
 	};
 };
 
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Wed Apr 10 15:04:02 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Wed, 10 Apr 2013 16:04:02 -0300
Subject: [PATCH v7 3/5] ARM: mvebu: Add support for NOR flash device on Armada
 XP-GP board
In-Reply-To: <1365620644-15790-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1365620644-15790-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1365620644-15790-4-git-send-email-ezequiel.garcia@free-electrons.com>

The Armada XP Development Board DB-MV784MP-GP has a NOR flash device
connected to the Device Bus. This commit adds the device tree node
to support this device.

This SoC supports a flexible and dynamic decoding window allocation
scheme; but since this feature is still not implemented we need
to specify the window base address in the device tree node itself.

This base address has been selected in a completely arbitrary fashion.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
Acked-by: Arnd Bergmann <arnd at arndb.de>
---
 arch/arm/boot/dts/armada-xp-gp.dts | 29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)

diff --git a/arch/arm/boot/dts/armada-xp-gp.dts b/arch/arm/boot/dts/armada-xp-gp.dts
index 1c8afe2..e57e9c7 100644
--- a/arch/arm/boot/dts/armada-xp-gp.dts
+++ b/arch/arm/boot/dts/armada-xp-gp.dts
@@ -109,5 +109,34 @@
 				spi-max-frequency = <108000000>;
 			};
 		};
+
+		devbus-bootcs at d0010400 {
+			status = "okay";
+			ranges = <0 0xf0000000 0x1000000>; /* @addr 0xf000000, size 0x1000000 */
+
+			/* Device Bus parameters are required */
+
+			/* Read parameters */
+			devbus,bus-width    = <8>;
+			devbus,turn-off-ps  = <60000>;
+			devbus,badr-skew-ps = <0>;
+			devbus,acc-first-ps = <124000>;
+			devbus,acc-next-ps  = <248000>;
+			devbus,rd-setup-ps  = <0>;
+			devbus,rd-hold-ps   = <0>;
+
+			/* Write parameters */
+			devbus,sync-enable = <0>;
+			devbus,wr-high-ps  = <60000>;
+			devbus,wr-low-ps   = <60000>;
+			devbus,ale-wr-ps   = <60000>;
+
+			/* NOR 16 MiB */
+			nor at 0 {
+				compatible = "cfi-flash";
+				reg = <0 0x1000000>;
+				bank-width = <2>;
+			};
+		};
 	};
 };
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Wed Apr 10 15:04:03 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Wed, 10 Apr 2013 16:04:03 -0300
Subject: [PATCH v7 4/5] ARM: mvebu: Add support for NOR flash device on
 Openblocks AX3 board
In-Reply-To: <1365620644-15790-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1365620644-15790-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1365620644-15790-5-git-send-email-ezequiel.garcia@free-electrons.com>

The Plat'home Openblocks AX3 has a 128 MiB NOR flash device connected
to the Device Bus. This commit adds the device tree node to support this device.

The SoC supports a flexible and dynamic decoding window allocation scheme;
but since this feature is still not implemented we need to specify the window
base address in the device tree node itself.
This base address has been selected in a completely arbitrary fashion.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
Acked-by: Arnd Bergmann <arnd at arndb.de>
---
 arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 29 ++++++++++++++++++++++++
 1 file changed, 29 insertions(+)

diff --git a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
index 3818a82..b5c5f4d 100644
--- a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
+++ b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
@@ -139,5 +139,34 @@
 		usb at d0051000 {
 			status = "okay";
 		};
+
+		devbus-bootcs at d0010400 {
+			status = "okay";
+			ranges = <0 0xf0000000 0x8000000>; /* @addr 0xf000000, size 0x8000000 */
+
+			/* Device Bus parameters are required */
+
+			/* Read parameters */
+			devbus,bus-width    = <8>;
+			devbus,turn-off-ps  = <60000>;
+			devbus,badr-skew-ps = <0>;
+			devbus,acc-first-ps = <124000>;
+			devbus,acc-next-ps  = <248000>;
+			devbus,rd-setup-ps  = <0>;
+			devbus,rd-hold-ps   = <0>;
+
+			/* Write parameters */
+			devbus,sync-enable = <0>;
+			devbus,wr-high-ps  = <60000>;
+			devbus,wr-low-ps   = <60000>;
+			devbus,ale-wr-ps   = <60000>;
+
+			/* NOR 128 MiB */
+			nor at 0 {
+				compatible = "cfi-flash";
+				reg = <0 0x8000000>;
+				bank-width = <2>;
+			};
+		};
 	};
 };
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Wed Apr 10 15:04:04 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Wed, 10 Apr 2013 16:04:04 -0300
Subject: [PATCH v7 5/5] ARM: mvebu: Add Device Bus and CFI flash memory
 support to defconfig
In-Reply-To: <1365620644-15790-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1365620644-15790-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1365620644-15790-6-git-send-email-ezequiel.garcia@free-electrons.com>

This patch selects the devbus driver as part of the mvebu default
config, along with the required options to detect and support
CFI flash memories.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
Acked-by: Arnd Bergmann <arnd at arndb.de>
---
 arch/arm/configs/mvebu_defconfig | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/configs/mvebu_defconfig b/arch/arm/configs/mvebu_defconfig
index 2ec8119..fe8ba26 100644
--- a/arch/arm/configs/mvebu_defconfig
+++ b/arch/arm/configs/mvebu_defconfig
@@ -46,6 +46,11 @@ CONFIG_I2C_MV64XXX=y
 CONFIG_MTD=y
 CONFIG_MTD_CHAR=y
 CONFIG_MTD_M25P80=y
+CONFIG_MTD_CFI=y
+CONFIG_MTD_CFI_INTELEXT=y
+CONFIG_MTD_CFI_AMDSTD=y
+CONFIG_MTD_CFI_STAA=y
+CONFIG_MTD_PHYSMAP_OF=y
 CONFIG_SERIAL_8250_DW=y
 CONFIG_GPIOLIB=y
 CONFIG_GPIO_SYSFS=y
@@ -65,6 +70,8 @@ CONFIG_RTC_DRV_S35390A=y
 CONFIG_RTC_DRV_MV=y
 CONFIG_DMADEVICES=y
 CONFIG_MV_XOR=y
+CONFIG_MEMORY=y
+CONFIG_MVEBU_DEVBUS=y
 # CONFIG_IOMMU_SUPPORT is not set
 CONFIG_EXT2_FS=y
 CONFIG_EXT3_FS=y
-- 
1.8.1.5



From rjw at sisk.pl  Wed Apr 10 15:12:38 2013
From: rjw at sisk.pl (Rafael J. Wysocki)
Date: Wed, 10 Apr 2013 21:12:38 +0200
Subject: [PATCH 00/18] cpuidle: code consolidation
In-Reply-To: <1365603743-5618-1-git-send-email-daniel.lezcano@linaro.org>
References: <1365603743-5618-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <17970296.uCm16aDdBG@vostro.rjw.lan>

On Wednesday, April 10, 2013 04:22:05 PM Daniel Lezcano wrote:
> This patchset series provide some code consolidation across the different
> cpuidle drivers. It contains two parts, the first one is the removal of
> the time keeping flag and the second one, is a common initialization routine.
> 
> All the drivers use the en_core_tk_irqen flag, which means it is not necessary
> to make the time computation optional. We can remove this flag and assume the
> cpuidle framework always manage this operation.
> 
> The cpuidle code initialization is duplicated across the different drivers in
> the same manner.
> 
> The repeating pattern is:
> 
> SMP:
> 
> cpuidle_register_driver(drv);
> for_each_possible_cpu(cpu) {
> 	dev = per_cpu(cpuidle_device, cpu);
> 	cpuidle_register_device(dev);
> }
> 
> UP:
> 
> cpuidle_register_driver(drv);
> cpuidle_register_device(dev);
> 
> As on a UP machine the macro 'for_each_cpu' is a one iteration loop, using the
> initialization loop from SMP to UP works.
> 
> The patchset does some cleanup for different drivers in order to make the init
> code the same. Then it introduces a generic function:
> 
>   cpuidle_register(struct cpuidle_driver *drv, struct cpumask *cpumask)
> 
> The cpumask is for the coupled idle states.
> 
> The drivers are then modified to take into account this new function and
> to remove the duplicated code.
> 
> The benefit is observable in the diffstat: 332 lines of code removed.
> 
> Tested-on: u8500
> Tested-on: at91
> Tested-on: intel i5
> Tested-on: OMAP4
> 
> Compiled with and without CPU_IDLE for:
>  u8500, at91, davinci, exynos, imx5, imx6, kirkwood, multi_v7 (for calxeda),
>  omap2plus, s3c64, tegra1, tegra2, tegra3
> 
> 
> Daniel Lezcano (18):
>   ARM: OMAP3: remove cpuidle_wrap_enter
>   cpuidle: remove en_core_tk_irqen flag
>   ARM: ux500: cpuidle: replace for_each_online_cpu by
>     for_each_possible_cpu
>   ARM: imx: cpuidle: create separate drivers for imx5/imx6
>   cpuidle: make a single register function for all
>   ARM: ux500: cpuidle: use init/exit common routine
>   ARM: at91: cpuidle: use init/exit common routine
>   ARM: OMAP3: cpuidle: use init/exit common routine
>   ARM: s3c64xx: cpuidle: use init/exit common routine
>   ARM: tegra1: cpuidle: use init/exit common routine
>   ARM: shmobile: cpuidle: use init/exit common routine
>   ARM: OMAP4: cpuidle: use init/exit common routine
>   ARM: tegra2: cpuidle: use init/exit common routine
>   ARM: tegra3: cpuidle: use init/exit common routine
>   ARM: calxeda: cpuidle: use init/exit common routine
>   ARM: kirkwood: cpuidle: use init/exit common routine
>   ARM: davinci: cpuidle: use init/exit common routine
>   ARM: imx: cpuidle: use init/exit common routine
> 
>  arch/arm/mach-at91/cpuidle.c                    |   18 +--
>  arch/arm/mach-davinci/cpuidle.c                 |   21 +---
>  arch/arm/mach-exynos/cpuidle.c                  |    1 -
>  arch/arm/mach-imx/Makefile                      |    1 +
>  arch/arm/mach-imx/cpuidle-imx5.c                |   40 +++++++
>  arch/arm/mach-imx/cpuidle-imx6q.c               |    3 +-
>  arch/arm/mach-imx/cpuidle.c                     |   80 -------------
>  arch/arm/mach-imx/cpuidle.h                     |   10 +-
>  arch/arm/mach-imx/pm-imx5.c                     |   30 +----
>  arch/arm/mach-omap2/cpuidle34xx.c               |   49 ++------
>  arch/arm/mach-omap2/cpuidle44xx.c               |   23 +---
>  arch/arm/mach-s3c64xx/cpuidle.c                 |   15 +--
>  arch/arm/mach-shmobile/cpuidle.c                |   11 +-
>  arch/arm/mach-shmobile/pm-sh7372.c              |    1 -
>  arch/arm/mach-tegra/cpuidle-tegra114.c          |   27 +----
>  arch/arm/mach-tegra/cpuidle-tegra20.c           |   34 +-----
>  arch/arm/mach-tegra/cpuidle-tegra30.c           |   28 +----
>  arch/arm/mach-ux500/cpuidle.c                   |   33 +-----
>  arch/powerpc/platforms/pseries/processor_idle.c |    1 -
>  arch/sh/kernel/cpu/shmobile/cpuidle.c           |    1 -
>  arch/x86/kernel/apm_32.c                        |    1 -
>  drivers/acpi/processor_idle.c                   |    1 -
>  drivers/cpuidle/cpuidle-calxeda.c               |   53 +--------
>  drivers/cpuidle/cpuidle-kirkwood.c              |   18 +--
>  drivers/cpuidle/cpuidle.c                       |  137 ++++++++++++++---------
>  drivers/idle/intel_idle.c                       |    1 -
>  include/linux/cpuidle.h                         |   20 ++--
>  27 files changed, 162 insertions(+), 496 deletions(-)
>  create mode 100644 arch/arm/mach-imx/cpuidle-imx5.c
>  delete mode 100644 arch/arm/mach-imx/cpuidle.c

I will be traveling from Saturday onwards pretty much until the beginning of
the 3.10 merge window, so I'm afraid this will have to wait for the next
release cycle.  At least I'm not going to take patches that haven't been
ACKed before tomorrow evening (CEST).

Thanks,
Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.


From linux at arm.linux.org.uk  Wed Apr 10 15:06:03 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Wed, 10 Apr 2013 20:06:03 +0100
Subject: Removal of NWFPE in its entirety, and VFP emulation code
In-Reply-To: <20130410190052.GC18196@blackmetal.musicnaut.iki.fi>
References: <20130410104002.GF14496@n2100.arm.linux.org.uk>
 <alpine.LFD.2.03.1304101307280.17375@syhkavp.arg>
 <20130410190052.GC18196@blackmetal.musicnaut.iki.fi>
Message-ID: <20130410190603.GL14496@n2100.arm.linux.org.uk>

On Wed, Apr 10, 2013 at 10:00:52PM +0300, Aaro Koskinen wrote:
> Menuconfig mentions under "Floating point emulation" that "At least one
> emulation must be selected". But if I compile my OS with EABI userspace
> soft-float I guess I won't actually need to select any emulation,
> or have I missed something? (I just checked my configs, and at least
> on Kirkwood/openrd I have been already running without any emulation,
> so I guess the help text is wrong?)

Well, it's that way to stop us being flooded with "why does my kernel
stop after mounting the rootfs" questions.  Maybe that can be changed
now, it depends whether we're absolutely certain that there's no FPA
instructions in any binary being run on EABI-only userspaces.

Given that such instructions will still be emulated if they're
encountered, I think we need to have another option to at least report
an error via the kernel message log should a FPA instruction be trapped.


From linux at arm.linux.org.uk  Wed Apr 10 15:12:06 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Wed, 10 Apr 2013 20:12:06 +0100
Subject: Removal of NWFPE in its entirety, and VFP emulation code
In-Reply-To: <CAKON4Ozhk1kfnzi4+j_2dkGbAG07MKFa3SXOKjy7oWhNh6HNVg@mail.gmail.com>
References: <20130410104002.GF14496@n2100.arm.linux.org.uk>
 <CAKON4Ozhk1kfnzi4+j_2dkGbAG07MKFa3SXOKjy7oWhNh6HNVg@mail.gmail.com>
Message-ID: <20130410191206.GM14496@n2100.arm.linux.org.uk>

On Wed, Apr 10, 2013 at 02:38:21PM -0400, jonsmirl at gmail.com wrote:
> On Wed, Apr 10, 2013 at 6:40 AM, Russell King - ARM Linux
> <linux at arm.linux.org.uk> wrote:
> > 1. Whether we can persuade John to relicense his code.  From what I
> >    understand from the discussions which have already happened, John
> >    is against that because he requires the indemnification clause.
> 
> Does it work to have him donate the copyright for the code to the FSF?
> Then he wouldn't own it anymore and wouldn't need indemnification. FSF
> would reissue under GPLv2 since it would be the owner of the copyright
> with the ability to relicense.

I don't know - and I'm not going to be able to look at this anymore until
about a weeks time, by which time this thread will be dead and buried,
and I'll have long forgotten about it...

Even if it is transferred to the FSF, that implies a change to the license,
which the copyright holder(s) would have to authorise.  The problem with
that is, if you read the license, it has been developed as part of a much
larger project, with a grant, and there may be strings attached which
prevent that happening.  I'm not saying it's not worth asking the question
though.


From linux at arm.linux.org.uk  Wed Apr 10 15:15:26 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Wed, 10 Apr 2013 20:15:26 +0100
Subject: Removal of NWFPE in its entirety, and VFP emulation code
In-Reply-To: <20130410132126.GD26992@mudshark.cambridge.arm.com>
References: <20130410104002.GF14496@n2100.arm.linux.org.uk>
 <20130410132126.GD26992@mudshark.cambridge.arm.com>
Message-ID: <20130410191526.GN14496@n2100.arm.linux.org.uk>

On Wed, Apr 10, 2013 at 02:21:27PM +0100, Will Deacon wrote:
> Hi Russell,
> 
> On Wed, Apr 10, 2013 at 11:40:02AM +0100, Russell King - ARM Linux wrote:
> > I have just committed a patch to remove the arch/arm/nwfpe code from
> > the kernel, and the VFP code emulating the FP operations.
> 
> [...]
> 
> I just had a play with your for-next branch, and noticed a couple of issues
> arising from this:
> 
> 	1. Removing vfpinstr.h leads to a couple of build failures, as it is
> 	   still included by arch/arm/kvm/coproc.c (for fmrx, which we should
> 	   continue to provide) and arch/arm/vfp/vfpmodule.c (similarly, but
> 	   also fmxr).

Grr, this is why relative include paths are bad news.  It breaks the
localisation of includes.  Okay, I'll add that include back, even
though nothing in arch/arm/vfp will be using it.

I'll leave everything else though... the functions in vfp.h will take
too much time to work out what's required and what isn't, and I don't
have the available bandwidth before I go away to work out what functions
are used and what aren't.


From jason at lakedaemon.net  Wed Apr 10 15:16:41 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Wed, 10 Apr 2013 15:16:41 -0400
Subject: [PATCH v7 1/5] drivers: memory: Introduce Marvell EBU Device
 Bus driver
In-Reply-To: <1365620644-15790-2-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1365620644-15790-1-git-send-email-ezequiel.garcia@free-electrons.com>
 <1365620644-15790-2-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <20130410191641.GG28693@titan.lakedaemon.net>

gregkh,

On Wed, Apr 10, 2013 at 04:04:00PM -0300, Ezequiel Garcia wrote:
> Marvell EBU SoCs such as Armada 370/XP, Orion5x (88f5xxx) and
> Discovery (mv78xx0) supports a Device Bus controller to access several
> kinds of memories and I/O devices (NOR, NAND, SRAM, FPGA).
> 
> This commit adds a driver to handle this controller. So far only
> Armada 370, Armada XP and Discovery SoCs are supported.
> 
> The driver must be registered through a device tree node;
> as explained in the binding document.
> 
> For each child node in the device tree, this driver will:
>   * set timing parameters
>   * register a child device
>   * setup an address decoding window, using the mbus driver
> 
> Keep in mind the address decoding window setup is only a temporary hack.
> This code will be removed from this devbus driver as soon as a proper device
> tree binding for the mbus driver is added.
> 
> Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
> Acked-by: Arnd Bergmann <arnd at arndb.de>
> ---
>  .../bindings/memory-controllers/mvebu-devbus.txt   | 156 ++++++++++
>  drivers/memory/Kconfig                             |  10 +
>  drivers/memory/Makefile                            |   1 +
>  drivers/memory/mvebu-devbus.c                      | 340 +++++++++++++++++++++
>  4 files changed, 507 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/memory-controllers/mvebu-devbus.txt
>  create mode 100644 drivers/memory/mvebu-devbus.c

As every commit to drivers/memory has been signed by you, would you like
to take this patch through your tree?  Or, I'll take it through arm-soc
with your Ack to keep the series together.

thx,

Jason.

> 
> diff --git a/Documentation/devicetree/bindings/memory-controllers/mvebu-devbus.txt b/Documentation/devicetree/bindings/memory-controllers/mvebu-devbus.txt
> new file mode 100644
> index 0000000..653c90c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/memory-controllers/mvebu-devbus.txt
> @@ -0,0 +1,156 @@
> +Device tree bindings for MVEBU Device Bus controllers
> +
> +The Device Bus controller available in some Marvell's SoC allows to control
> +different types of standard memory and I/O devices such as NOR, NAND, and FPGA.
> +The actual devices are instantiated from the child nodes of a Device Bus node.
> +
> +Required properties:
> +
> + - compatible:          Currently only Armada 370/XP SoC are supported,
> +                        with this compatible string:
> +
> +                        marvell,mvebu-devbus
> +
> + - reg:                 A resource specifier for the register space.
> +                        This is the base address of a chip select within
> +			the controller's register space.
> +                        (see the example below)
> +
> + - #address-cells:      Must be set to 1
> + - #size-cells:         Must be set to 1
> + - ranges:              Must be set up to reflect the memory layout with four
> +                        integer values for each chip-select line in use:
> +                        0 <physical address of mapping> <size>
> +
> +Mandatory timing properties for child nodes:
> +
> +Read parameters:
> +
> + - devbus,turn-off-ps:  Defines the time during which the controller does not
> +                        drive the AD bus after the completion of a device read.
> +                        This prevents contentions on the Device Bus after a read
> +                        cycle from a slow device.
> +
> + - devbus,bus-width:    Defines the bus width (e.g. <16>)
> +
> + - devbus,badr-skew-ps: Defines the time delay from from A[2:0] toggle,
> +                        to read data sample. This parameter is useful for
> +                        synchronous pipelined devices, where the address
> +                        precedes the read data by one or two cycles.
> +
> + - devbus,acc-first-ps: Defines the time delay from the negation of
> +                        ALE[0] to the cycle that the first read data is sampled
> +                        by the controller.
> +
> + - devbus,acc-next-ps:  Defines the time delay between the cycle that
> +                        samples data N and the cycle that samples data N+1
> +                        (in burst accesses).
> +
> + - devbus,rd-setup-ps:  Defines the time delay between DEV_CSn assertion to
> +			DEV_OEn assertion. If set to 0 (default),
> +                        DEV_OEn and DEV_CSn are asserted at the same cycle.
> +                        This parameter has no affect on <acc-first-ps> parameter
> +                        (no affect on first data sample). Set <rd-setup-ps>
> +                        to a value smaller than <acc-first-ps>.
> +
> + - devbus,rd-hold-ps:   Defines the time between the last data sample to the
> +			de-assertion of DEV_CSn. If set to 0 (default),
> +			DEV_OEn and DEV_CSn are de-asserted at the same cycle
> +			(the cycle of the last data sample).
> +                        This parameter has no affect on DEV_OEn de-assertion.
> +                        DEV_OEn is always de-asserted the next cycle after
> +                        last data sampled. Also this parameter has no
> +                        affect on <turn-off-ps> parameter.
> +                        Set <rd-hold-ps> to a value smaller than <turn-off-ps>.
> +
> +Write parameters:
> +
> + - devbus,ale-wr-ps:    Defines the time delay from the ALE[0] negation cycle
> +			to the DEV_WEn assertion.
> +
> + - devbus,wr-low-ps:    Defines the time during which DEV_WEn is active.
> +                        A[2:0] and Data are kept valid as long as DEV_WEn
> +                        is active. This parameter defines the setup time of
> +                        address and data to DEV_WEn rise.
> +
> + - devbus,wr-high-ps:   Defines the time during which DEV_WEn is kept
> +                        inactive (high) between data beats of a burst write.
> +                        DEV_A[2:0] and Data are kept valid (do not toggle) for
> +                        <wr-high-ps> - <tick> ps.
> +			This parameter defines the hold time of address and
> +			data after DEV_WEn rise.
> +
> + - devbus,sync-enable: Synchronous device enable.
> +                       1: True
> +                       0: False
> +
> +An example for an Armada XP GP board, with a 16 MiB NOR device as child
> +is showed below. Note that the Device Bus driver is in charge of allocating
> +the mbus address decoding window for each of its child devices.
> +The window is created using the chip select specified in the child
> +device node together with the base address and size specified in the ranges
> +property. For instance, in the example below the allocated decoding window
> +will start at base address 0xf0000000, with a size 0x1000000 (16 MiB)
> +for chip select 0 (a.k.a DEV_BOOTCS).
> +
> +This address window handling is done in this mvebu-devbus only as a temporary
> +solution. It will be removed when the support for mbus device tree binding is
> +added.
> +
> +The reg property implicitly specifies the chip select as this:
> +
> +  0x10400: DEV_BOOTCS
> +  0x10408: DEV_CS0
> +  0x10410: DEV_CS1
> +  0x10418: DEV_CS2
> +  0x10420: DEV_CS3
> +
> +Example:
> +
> +	devbus-bootcs at d0010400 {
> +		status = "okay";
> +		ranges = <0 0xf0000000 0x1000000>; /* @addr 0xf0000000, size 0x1000000 */
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +
> +		/* Device Bus parameters are required */
> +
> +		/* Read parameters */
> +		devbus,bus-width    = <8>;
> +		devbus,turn-off-ps  = <60000>;
> +		devbus,badr-skew-ps = <0>;
> +		devbus,acc-first-ps = <124000>;
> +		devbus,acc-next-ps  = <248000>;
> +		devbus,rd-setup-ps  = <0>;
> +		devbus,rd-hold-ps   = <0>;
> +
> +		/* Write parameters */
> +		devbus,sync-enable = <0>;
> +		devbus,wr-high-ps  = <60000>;
> +		devbus,wr-low-ps   = <60000>;
> +		devbus,ale-wr-ps   = <60000>;
> +
> +		flash at 0 {
> +			compatible = "cfi-flash";
> +
> +			/* 16 MiB */
> +			reg = <0 0x1000000>;
> +			bank-width = <2>;
> +			#address-cells = <1>;
> +			#size-cells = <1>;
> +
> +			/*
> +			 * We split the 16 MiB in two partitions,
> +			 * just as an example.
> +			 */
> +			partition at 0 {
> +				label = "First";
> +				reg = <0 0x800000>;
> +			};
> +
> +			partition at 800000 {
> +				label = "Second";
> +				reg = <0x800000 0x800000>;
> +			};
> +		};
> +	};
> diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig
> index 067f311..29a11db 100644
> --- a/drivers/memory/Kconfig
> +++ b/drivers/memory/Kconfig
> @@ -20,6 +20,16 @@ config TI_EMIF
>  	  parameters and other settings during frequency, voltage and
>  	  temperature changes
>  
> +config MVEBU_DEVBUS
> +	bool "Marvell EBU Device Bus Controller"
> +	default y
> +	depends on PLAT_ORION && OF
> +	help
> +	  This driver is for the Device Bus controller available in some
> +	  Marvell EBU SoCs such as Discovery (mv78xx0), Orion (88f5xxx) and
> +	  Armada 370 and Armada XP. This controller allows to handle flash
> +	  devices such as NOR, NAND, SRAM, and FPGA.
> +
>  config TEGRA20_MC
>  	bool "Tegra20 Memory Controller(MC) driver"
>  	default y
> diff --git a/drivers/memory/Makefile b/drivers/memory/Makefile
> index 9cce5d7..969d923 100644
> --- a/drivers/memory/Makefile
> +++ b/drivers/memory/Makefile
> @@ -6,5 +6,6 @@ ifeq ($(CONFIG_DDR),y)
>  obj-$(CONFIG_OF)		+= of_memory.o
>  endif
>  obj-$(CONFIG_TI_EMIF)		+= emif.o
> +obj-$(CONFIG_MVEBU_DEVBUS)	+= mvebu-devbus.o
>  obj-$(CONFIG_TEGRA20_MC)	+= tegra20-mc.o
>  obj-$(CONFIG_TEGRA30_MC)	+= tegra30-mc.o
> diff --git a/drivers/memory/mvebu-devbus.c b/drivers/memory/mvebu-devbus.c
> new file mode 100644
> index 0000000..978e8e3
> --- /dev/null
> +++ b/drivers/memory/mvebu-devbus.c
> @@ -0,0 +1,340 @@
> +/*
> + * Marvell EBU SoC Device Bus Controller
> + * (memory controller for NOR/NAND/SRAM/FPGA devices)
> + *
> + * Copyright (C) 2013 Marvell
> + *
> + * 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 version 2 of the License.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
> + *
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/slab.h>
> +#include <linux/err.h>
> +#include <linux/io.h>
> +#include <linux/clk.h>
> +#include <linux/mbus.h>
> +#include <linux/of_platform.h>
> +#include <linux/of_address.h>
> +#include <linux/platform_device.h>
> +
> +/* Register definitions */
> +#define DEV_WIDTH_BIT		30
> +#define BADR_SKEW_BIT		28
> +#define RD_HOLD_BIT		23
> +#define ACC_NEXT_BIT		17
> +#define RD_SETUP_BIT		12
> +#define ACC_FIRST_BIT		6
> +
> +#define SYNC_ENABLE_BIT		24
> +#define WR_HIGH_BIT		16
> +#define WR_LOW_BIT		8
> +
> +#define READ_PARAM_OFFSET	0x0
> +#define WRITE_PARAM_OFFSET	0x4
> +
> +static const char * const devbus_wins[] = {
> +	"devbus-boot",
> +	"devbus-cs0",
> +	"devbus-cs1",
> +	"devbus-cs2",
> +	"devbus-cs3",
> +};
> +
> +struct devbus_read_params {
> +	u32 bus_width;
> +	u32 badr_skew;
> +	u32 turn_off;
> +	u32 acc_first;
> +	u32 acc_next;
> +	u32 rd_setup;
> +	u32 rd_hold;
> +};
> +
> +struct devbus_write_params {
> +	u32 sync_enable;
> +	u32 wr_high;
> +	u32 wr_low;
> +	u32 ale_wr;
> +};
> +
> +struct devbus {
> +	struct device *dev;
> +	void __iomem *base;
> +	unsigned long tick_ps;
> +};
> +
> +static int get_timing_param_ps(struct devbus *devbus,
> +			       struct device_node *node,
> +			       const char *name,
> +			       u32 *ticks)
> +{
> +	u32 time_ps;
> +	int err;
> +
> +	err = of_property_read_u32(node, name, &time_ps);
> +	if (err < 0) {
> +		dev_err(devbus->dev, "%s has no '%s' property\n",
> +			name, node->full_name);
> +		return err;
> +	}
> +
> +	*ticks = (time_ps + devbus->tick_ps - 1) / devbus->tick_ps;
> +
> +	dev_dbg(devbus->dev, "%s: %u ps -> 0x%x\n",
> +		name, time_ps, *ticks);
> +	return 0;
> +}
> +
> +static int devbus_set_timing_params(struct devbus *devbus,
> +				    struct device_node *node)
> +{
> +	struct devbus_read_params r;
> +	struct devbus_write_params w;
> +	u32 value;
> +	int err;
> +
> +	dev_dbg(devbus->dev, "Setting timing parameter, tick is %lu ps\n",
> +		devbus->tick_ps);
> +
> +	/* Get read timings */
> +	err = of_property_read_u32(node, "devbus,bus-width", &r.bus_width);
> +	if (err < 0) {
> +		dev_err(devbus->dev,
> +			"%s has no 'devbus,bus-width' property\n",
> +			node->full_name);
> +		return err;
> +	}
> +	/* Convert bit width to byte width */
> +	r.bus_width /= 8;
> +
> +	err = get_timing_param_ps(devbus, node, "devbus,badr-skew-ps",
> +				 &r.badr_skew);
> +	if (err < 0)
> +		return err;
> +
> +	err = get_timing_param_ps(devbus, node, "devbus,turn-off-ps",
> +				 &r.turn_off);
> +	if (err < 0)
> +		return err;
> +
> +	err = get_timing_param_ps(devbus, node, "devbus,acc-first-ps",
> +				 &r.acc_first);
> +	if (err < 0)
> +		return err;
> +
> +	err = get_timing_param_ps(devbus, node, "devbus,acc-next-ps",
> +				 &r.acc_next);
> +	if (err < 0)
> +		return err;
> +
> +	err = get_timing_param_ps(devbus, node, "devbus,rd-setup-ps",
> +				 &r.rd_setup);
> +	if (err < 0)
> +		return err;
> +
> +	err = get_timing_param_ps(devbus, node, "devbus,rd-hold-ps",
> +				 &r.rd_hold);
> +	if (err < 0)
> +		return err;
> +
> +	/* Get write timings */
> +	err = of_property_read_u32(node, "devbus,sync-enable",
> +				  &w.sync_enable);
> +	if (err < 0) {
> +		dev_err(devbus->dev,
> +			"%s has no 'devbus,sync-enable' property\n",
> +			node->full_name);
> +		return err;
> +	}
> +
> +	err = get_timing_param_ps(devbus, node, "devbus,ale-wr-ps",
> +				 &w.ale_wr);
> +	if (err < 0)
> +		return err;
> +
> +	err = get_timing_param_ps(devbus, node, "devbus,wr-low-ps",
> +				 &w.wr_low);
> +	if (err < 0)
> +		return err;
> +
> +	err = get_timing_param_ps(devbus, node, "devbus,wr-high-ps",
> +				 &w.wr_high);
> +	if (err < 0)
> +		return err;
> +
> +	/* Set read timings */
> +	value = r.bus_width << DEV_WIDTH_BIT |
> +		r.badr_skew << BADR_SKEW_BIT |
> +		r.rd_hold   << RD_HOLD_BIT   |
> +		r.acc_next  << ACC_NEXT_BIT  |
> +		r.rd_setup  << RD_SETUP_BIT  |
> +		r.acc_first << ACC_FIRST_BIT |
> +		r.turn_off;
> +
> +	dev_dbg(devbus->dev, "read parameters register 0x%p = 0x%x\n",
> +		devbus->base + READ_PARAM_OFFSET,
> +		value);
> +
> +	writel(value, devbus->base + READ_PARAM_OFFSET);
> +
> +	/* Set write timings */
> +	value = w.sync_enable  << SYNC_ENABLE_BIT |
> +		w.wr_low       << WR_LOW_BIT      |
> +		w.wr_high      << WR_HIGH_BIT     |
> +		w.ale_wr;
> +
> +	dev_dbg(devbus->dev, "write parameters register: 0x%p = 0x%x\n",
> +		devbus->base + WRITE_PARAM_OFFSET,
> +		value);
> +
> +	writel(value, devbus->base + WRITE_PARAM_OFFSET);
> +
> +	return 0;
> +}
> +
> +static int mvebu_devbus_probe(struct platform_device *pdev)
> +{
> +	struct device *dev = &pdev->dev;
> +	struct device_node *node = pdev->dev.of_node;
> +	struct device_node *parent;
> +	struct devbus *devbus;
> +	struct resource *res;
> +	struct clk *clk;
> +	unsigned long rate;
> +	const __be32 *ranges;
> +	int err, cs;
> +	int addr_cells, p_addr_cells, size_cells;
> +	int ranges_len, tuple_len;
> +	u32 base, size;
> +
> +	devbus = devm_kzalloc(&pdev->dev, sizeof(struct devbus), GFP_KERNEL);
> +	if (!devbus)
> +		return -ENOMEM;
> +
> +	devbus->dev = dev;
> +	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +	devbus->base = devm_ioremap_resource(&pdev->dev, res);
> +	if (IS_ERR(devbus->base))
> +		return PTR_ERR(devbus->base);
> +
> +	clk = devm_clk_get(&pdev->dev, NULL);
> +	if (IS_ERR(clk))
> +		return PTR_ERR(clk);
> +	clk_prepare_enable(clk);
> +
> +	/*
> +	 * Obtain clock period in picoseconds,
> +	 * we need this in order to convert timing
> +	 * parameters from cycles to picoseconds.
> +	 */
> +	rate = clk_get_rate(clk) / 1000;
> +	devbus->tick_ps = 1000000000 / rate;
> +
> +	/* Read the device tree node and set the new timing parameters */
> +	err = devbus_set_timing_params(devbus, node);
> +	if (err < 0)
> +		return err;
> +
> +	/*
> +	 * Allocate an address window for this device.
> +	 * If the device probing fails, then we won't be able to
> +	 * remove the allocated address decoding window.
> +	 *
> +	 * FIXME: This is only a temporary hack! We need to do this here
> +	 * because we still don't have device tree bindings for mbus.
> +	 * Once that support is added, we will declare these address windows
> +	 * statically in the device tree, and remove the window configuration
> +	 * from here.
> +	 */
> +
> +	/*
> +	 * Get the CS to choose the window string.
> +	 * This is a bit hacky, but it will be removed once the
> +	 * address windows are declared in the device tree.
> +	 */
> +	cs = (((unsigned long)devbus->base) % 0x400) / 8;
> +
> +	/*
> +	 * Parse 'ranges' property to obtain a (base,size) window tuple.
> +	 * This will be removed once the address windows
> +	 * are declared in the device tree.
> +	 */
> +	parent = of_get_parent(node);
> +	if (!parent)
> +		return -EINVAL;
> +
> +	p_addr_cells = of_n_addr_cells(parent);
> +	of_node_put(parent);
> +
> +	addr_cells = of_n_addr_cells(node);
> +	size_cells = of_n_size_cells(node);
> +	tuple_len = (p_addr_cells + addr_cells + size_cells) * sizeof(__be32);
> +
> +	ranges = of_get_property(node, "ranges", &ranges_len);
> +	if (ranges == NULL || ranges_len != tuple_len)
> +		return -EINVAL;
> +
> +	base = of_translate_address(node, ranges + addr_cells);
> +	if (base == OF_BAD_ADDR)
> +		return -EINVAL;
> +	size = of_read_number(ranges + addr_cells + p_addr_cells, size_cells);
> +
> +	/*
> +	 * Create an mbus address windows.
> +	 * FIXME: Remove this, together with the above code, once the
> +	 * address windows are declared in the device tree.
> +	 */
> +	err = mvebu_mbus_add_window(devbus_wins[cs], base, size);
> +	if (err < 0)
> +		return err;
> +
> +	/*
> +	 * We need to create a child device explicitly from here to
> +	 * guarantee that the child will be probed after the timing
> +	 * parameters for the bus are written.
> +	 */
> +	err = of_platform_populate(node, NULL, NULL, dev);
> +	if (err < 0) {
> +		mvebu_mbus_del_window(base, size);
> +		return err;
> +	}
> +
> +	return 0;
> +}
> +
> +static const struct of_device_id mvebu_devbus_of_match[] = {
> +	{ .compatible = "marvell,mvebu-devbus" },
> +	{},
> +};
> +MODULE_DEVICE_TABLE(of, mvebu_devbus_of_match);
> +
> +static struct platform_driver mvebu_devbus_driver = {
> +	.probe		= mvebu_devbus_probe,
> +	.driver		= {
> +		.name	= "mvebu-devbus",
> +		.owner	= THIS_MODULE,
> +		.of_match_table = mvebu_devbus_of_match,
> +	},
> +};
> +
> +static int __init mvebu_devbus_init(void)
> +{
> +	return platform_driver_register(&mvebu_devbus_driver);
> +}
> +module_init(mvebu_devbus_init);
> +
> +MODULE_LICENSE("GPL v2");
> +MODULE_AUTHOR("Ezequiel Garcia <ezequiel.garcia at free-electrons.com>");
> +MODULE_DESCRIPTION("Marvell EBU SoC Device Bus controller");
> -- 
> 1.8.1.5
> 


From nm at ti.com  Wed Apr 10 15:19:13 2013
From: nm at ti.com (Nishanth Menon)
Date: Wed, 10 Apr 2013 14:19:13 -0500
Subject: [RFC][PATCH 1/2] ARM: OMAP4: clock: Add device tree support for
 AUXCLKs
In-Reply-To: <20130410184919.GJ10155@atomide.com>
References: <20130404164137.GH10155@atomide.com> <515EA9E3.1010409@ti.com>
 <20130405155851.GA10155@atomide.com> <5163E589.1040809@ti.com>
 <20130409164928.GL10155@atomide.com>
 <20130409174319.GP10155@atomide.com> <20130409204900.GA8815@kahuna>
 <20130410080630.14359.68178@quantum> <5165453E.6090503@ti.com>
 <20130410173921.GA31017@kahuna>
 <20130410184919.GJ10155@atomide.com>
Message-ID: <CAGo_u6rqN6YFQ6vX87-Cg28RbiR9UU2JHgLecOU5Nd=B5XPUEA@mail.gmail.com>

Hi Tony,
On Wed, Apr 10, 2013 at 1:49 PM, Tony Lindgren <tony at atomide.com> wrote:
> * Nishanth Menon <nm at ti.com> [130410 10:44]:
>> Details in the patch below (Tony, I have added you as collaborator for
>> helping in getting this working-clk_add_alias was'nt needed in the
>> internal patch discussion we had - I have taken a bit of freedom in
>> adding your contributions to the patch below)
>
> OK thanks. Noticed few minor things, see below.
Thanks on the checkup
>
>> Folks, this does seem to be the best compromise we can achieve at this
>> point in time. feedback on this approach is much appreciated - if folks
>> are ok, I can post this as an formal patch series.
>>
>> From 130a41821bf57081ca45ef654029175d173135e6 Mon Sep 17 00:00:00 2001
>> From: Nishanth Menon <nm at ti.com>
>> Date: Tue, 9 Apr 2013 19:26:40 -0500
>> Subject: [RFC PATCH] clk: OMAP: introduce device tree binding to kernel clock
>>  data
>>
>> OMAP clock data is located in arch/arm/mach-omap2/cclockXYZ_data.c.
>> However, this presents an obstacle for using these clock nodes in
>> Device Tree definitions. There are many possible approaches to this
>> problem as discussed in the following thread:
>> http://marc.info/?t=136370325600009&r=1&w=2
>
> It might be worth clarifying that this is especially for the board
> specific clocks initially. The fixed clocks are currently found via
> the clock aliases table.
Ack.
[...]
>
>> +Example #2: describing clock node for auxilary clock #3 on OMAP443x platform:
>> +Ref: arch/arm/mach-omap2/cclock44xx_data.c
>> +describes the auxclk3 clock to be as follows:
>> +     CLK(NULL,       "auxclk3_ck",   &auxclk3_ck,    CK_443X),
>> +Corresponding binding will be:
>> +     auxclk3: auxclk3 {
>> +             #clock-cells = <1>;
>> +             compatible = "ti,omap-clock";
>> +     };
>> +And it's usage will be:
>> +     clocks = <&auxclk3>;
>
> The #clock-cells in the auxclk3 example should also be 0 instead of 1
> AFAIK. We should only use #clock-cells = <1> when the same physical
> clock provides multiple outputs. I believe the auxclocks are all separate,
> but that needs to be verified.
Oops.. my bad. you are correct here - auxclk is single output. all of them.
will fix.
[...]
>> +static int omap_clk_probe(struct platform_device *pdev)
>> +{
>> +     struct clk *clk;
>> +     int res;
>> +
>> +     const struct of_device_id *match;
>> +     struct device_node *np = pdev->dev.of_node;
>> +     char clk_name[32];
>> +
>> +     match = of_match_device(omap_clk_of_match, &pdev->dev);
>> +
>> +     /* Set up things so consumer can call clk_get() with name */
>> +     snprintf(clk_name, 32, "%s_ck", np->name);
>> +     clk = clk_get(NULL, clk_name);
>> +     if (IS_ERR(clk)) {
>> +             res = PTR_ERR(clk);
>> +             dev_err(&pdev->dev, "could not get clock %s (%d)\n",
>> +                     clk_name, res);
>> +             goto out;
>> +     }
>
> It seems that at least for now we can assume the naming will stay
> that way, then if we need other rules for finding clocks, we can
> add omap_match_clock() function or something.
ack.
>
>> +     /* This allows the driver to of_clk_get() */
>> +     res = of_clk_add_provider(np, of_clk_src_simple_get, clk);
>> +     if (res)
>> +             dev_err(&pdev->dev, "could not add provider for %s (%d)\n",
>> +                     clk_name, res);
>> +
>> +     clk_put(clk);
>> +out:
>> +     return res;
>> +}
>
> We can avoid the concern of storing the struct clk * and do the
> look up lazily on consumer driver probe by setting a dummy struct
> clk * here. Then replace of_clk_src_simple_get() with a custom
> omap_clk_src_get() that does the lookup and replaces the struct
> clk * with the real one.
Hmm.. this is interesting. will give it a try. Thanks on the suggestion.

Regards,
Nishanth Menon


From nico at fluxnic.net  Wed Apr 10 15:19:33 2013
From: nico at fluxnic.net (Nicolas Pitre)
Date: Wed, 10 Apr 2013 15:19:33 -0400 (EDT)
Subject: Removal of NWFPE in its entirety, and VFP emulation code
In-Reply-To: <20130410190603.GL14496@n2100.arm.linux.org.uk>
References: <20130410104002.GF14496@n2100.arm.linux.org.uk>
 <alpine.LFD.2.03.1304101307280.17375@syhkavp.arg>
 <20130410190052.GC18196@blackmetal.musicnaut.iki.fi>
 <20130410190603.GL14496@n2100.arm.linux.org.uk>
Message-ID: <alpine.LFD.2.03.1304101510230.17375@syhkavp.arg>

On Wed, 10 Apr 2013, Russell King - ARM Linux wrote:

> On Wed, Apr 10, 2013 at 10:00:52PM +0300, Aaro Koskinen wrote:
> > Menuconfig mentions under "Floating point emulation" that "At least one
> > emulation must be selected". But if I compile my OS with EABI userspace
> > soft-float I guess I won't actually need to select any emulation,
> > or have I missed something? (I just checked my configs, and at least
> > on Kirkwood/openrd I have been already running without any emulation,
> > so I guess the help text is wrong?)
> 
> Well, it's that way to stop us being flooded with "why does my kernel
> stop after mounting the rootfs" questions.  Maybe that can be changed
> now, it depends whether we're absolutely certain that there's no FPA
> instructions in any binary being run on EABI-only userspaces.

It is at least clear according to the EABI documentation. The double 
float word ordering is also defined to be different from FPA's, making 
EABI and FPA incompatible.

> Given that such instructions will still be emulated if they're
> encountered, I think we need to have another option to at least report
> an error via the kernel message log should a FPA instruction be trapped.

Agreed.


Nicolas


From mans at mansr.com  Wed Apr 10 15:23:30 2013
From: mans at mansr.com (=?iso-8859-1?Q?M=E5ns_Rullg=E5rd?=)
Date: Wed, 10 Apr 2013 20:23:30 +0100
Subject: Removal of NWFPE in its entirety, and VFP emulation code
In-Reply-To: <20130410185421.GI14496@n2100.arm.linux.org.uk> (Russell King's
 message of "Wed, 10 Apr 2013 19:54:21 +0100")
References: <20130410104002.GF14496@n2100.arm.linux.org.uk>
 <yw1xmwt68whw.fsf@unicorn.mansr.com>
 <20130410114229.GH14496@n2100.arm.linux.org.uk>
 <yw1xip3u8uni.fsf@unicorn.mansr.com>
 <20130410185421.GI14496@n2100.arm.linux.org.uk>
Message-ID: <yw1xehei8a19.fsf@unicorn.mansr.com>

Russell King - ARM Linux <linux at arm.linux.org.uk> writes:

> On Wed, Apr 10, 2013 at 12:58:09PM +0100, M?ns Rullg?rd wrote:
>> Russell King - ARM Linux <linux at arm.linux.org.uk> writes:
>> 
>> > On Wed, Apr 10, 2013 at 12:18:19PM +0100, M?ns Rullg?rd wrote:
>> >> Russell King - ARM Linux <linux at arm.linux.org.uk> writes:
>> >> 
>> >> > The situation with VFP is likely less disruptive - only instructions
>> >> > which aren't implemented in hardware (or, for example, if you ask for
>> >> > inexact exceptions to be enabled) which are bounced to the software
>> >> > support code will be affected.  I think OMAP should get away unscathed,
>> >> > but ARM's implementation will bounce if inexact exceptions are enabled
>> >> 
>> >> What do you mean by this?  OMAP uses ARM's cores.
>> >
>> > OMAP's VFP reports that it never traps to support code for VFP instructions,
>> > so the emulation code is never used on OMAP.
>> 
>> That is true for OMAP2 (ARM1136/VFP11) and OMAP3 (Cortex-A8).  OMAP4
>> (Cortex-A9) and OMAP5 (Cortex-A15) both trap on vector operations.
>
> No.  Both OMAP3 and OMAP4 report that they are VFP subarchitecture 3,
> and the VFP subarchitecture 3 never traps to support code for any
> instruction (it's the "null subarchitecture" value.)

VFPv3 does not require hardware support for vector operations, and the
Cortex-A9 NEON TRM [1] says this:

   ARMv7 deprecates the use of VFP vector mode. The Cortex-A9 NEON MPE
   hardware does not support VFP vector operations. [...] The Cortex-A9
   NEON MPE provides high speed VFP operation without support code.
   However, if an application requires VFP vector operation, then it
   must use support code.

[1] http://infocenter.arm.com/help/topic/com.arm.doc.ddi0409i/CHDEEJDB.html

The VFP-only TRM [2] contains similar language:

  The use of VFP vector mode is deprecated in ARMv7.  Vector operations
  are not supported in hardware.  If you use vectors, support code is
  required.

[2] http://infocenter.arm.com/help/topic/com.arm.doc.ddi0408i/I1019986.html

The Cortex-A15 TRM [3] follows suit:

  Vector operations are not supported.  Any attempt to execute a vector
  operation results in an Undefined Instruction exception.  If an
  application requires VFP vector operation, then it must use VFP
  support code.

[3] http://infocenter.arm.com/help/topic/com.arm.doc.ddi0438h/CEGCDBHC.html

In future, if you checked the relevant documentation before making bold
claims, you might avoid making a fool of yourself.

-- 
M?ns Rullg?rd
mans at mansr.com


From mans at mansr.com  Wed Apr 10 15:25:59 2013
From: mans at mansr.com (=?iso-8859-1?Q?M=E5ns_Rullg=E5rd?=)
Date: Wed, 10 Apr 2013 20:25:59 +0100
Subject: Removal of NWFPE in its entirety, and VFP emulation code
In-Reply-To: <alpine.LFD.2.03.1304101307280.17375@syhkavp.arg> (Nicolas
 Pitre's message of "Wed, 10 Apr 2013 13:30:35 -0400 (EDT)")
References: <20130410104002.GF14496@n2100.arm.linux.org.uk>
 <alpine.LFD.2.03.1304101307280.17375@syhkavp.arg>
Message-ID: <yw1xa9p689x4.fsf@unicorn.mansr.com>

Nicolas Pitre <nico at fluxnic.net> writes:

> So another option here might imply deprecating OABI support entirely, 

I'd support such a move.

-- 
M?ns Rullg?rd
mans at mansr.com


From linus.walleij at linaro.org  Wed Apr 10 15:33:16 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Wed, 10 Apr 2013 21:33:16 +0200
Subject: [PATCH 1/5] gpio/omap: free irq domain in probe() failure paths
In-Reply-To: <1365106576-31816-2-git-send-email-jon-hunter@ti.com>
References: <1365106576-31816-1-git-send-email-jon-hunter@ti.com>
 <1365106576-31816-2-git-send-email-jon-hunter@ti.com>
Message-ID: <CACRpkdbGw8_eL2KbXU2FxSrDof=O_5tA+siZDLvTqERqa650wA@mail.gmail.com>

On Thu, Apr 4, 2013 at 10:16 PM, Jon Hunter <jon-hunter at ti.com> wrote:

> Currently the IRQ domain is not freed once allocated, in the case where
> omap_gpio_probe() fails. Therefore, ensure we free the domain if the
> probe does fail. Furthermore, the local variable "ret" is not needed
> and so remove this.
>
> Signed-off-by: Jon Hunter <jon-hunter at ti.com>

Hm Kevin is still listed as maintainer on this driver but on a mail
address that bounces, can you send a patch replacing him in MAINTAINERS
with yourself if you're willing to pick it up?

Anyway, patch applied.

Yours,
Linus Walleij


From linux at roeck-us.net  Wed Apr 10 15:34:32 2013
From: linux at roeck-us.net (Guenter Roeck)
Date: Wed, 10 Apr 2013 12:34:32 -0700
Subject: [PATCH v7] clk: add si5351 i2c common clock driver
In-Reply-To: <1365586810-6752-1-git-send-email-sebastian.hesselbarth@gmail.com>
References: <1365439617-18816-1-git-send-email-sebastian.hesselbarth@gmail.com>
 <1365586810-6752-1-git-send-email-sebastian.hesselbarth@gmail.com>
Message-ID: <20130410193432.GA25678@roeck-us.net>

On Wed, Apr 10, 2013 at 11:40:10AM +0200, Sebastian Hesselbarth wrote:
> This patch adds a common clock driver for Silicon Labs Si5351a/b/c
> i2c programmable clock generators. Currently, the driver does not
> support VXCO feature of si5351b. Passing platform_data or DT bindings
> selectively allows to overwrite stored Si5351 configuration which is
> very helpful for clock generators with empty eeprom configuration.
> Corresponding device tree binding documentation is also added.
> 
> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
> ---
> I consider this v7 now as feature complete. Please review/test a
> hopefully last time and add your Acked-By/Tested-By. Thanks!
> 
> Changes from v6:
> - make invalid DT data parsing fatal (Suggested by Guenter Roeck)
> - add more variant checks and return errors
> - remove inline from _si5351_* functions
> - remove pll reset/clkout powerdown for gapless tuning
>   (Provided by Michal Backraty)
> 
> Changes from v5:
> - removed __clk_set_flags
> - remove CONFIG_OF dependency
> - introduce si5351_platform_data (non-DT untested)
> - parse DT into si5351_platform_data (tested)
> - minor cleanups
> 
> Changes from v4:
> - move from clk-private.h to clk-provider.h (Reported by Mike Turquette)
> - use __clk_set_flags() helper
> 
> Changes from v3:
> - add silabs prefix to custom DT properties (Reported by Lars-Peter Clausen)
> - use sizeof(*foo) instead of sizeof(struct bar) (Reported by Lars-Peter Clausen)
> - check return value of of_clk_add_provider (Reported by Lars-Peter Clausen)
> - clean up i2c client init (Reported by Lars-Peter Clausen)
> - silence successful probe (Suggested by Lars-Peter Clausen)
> - make CONFIG_CLK_SI5351 depend on CONFIG_OF
> 
> Changes from v2:
> - add curly brackets to if-else-statements (Reported by Daniel Mack)
> - fix div-by-zero for clk6/clk7 (Reported by Daniel Mack)
> - fix parameter address calculation for clk6/clk7
> 
> Changes from v1:
> - remove .is_enabled functions as they read from i2c
>   (Reported by Daniel Mack)
> - add CLK_SET_RATE_PARENT on clkout reparent if clkout uses
>   its own multisync
> 
> Cc: Grant Likely <grant.likely at secretlab.ca>
> Cc: Rob Herring <rob.herring at calxeda.com>
> Cc: Rob Landley <rob at landley.net>
> Cc: Mike Turquette <mturquette at linaro.org>
> Cc: Stephen Warren <swarren at nvidia.com>
> Cc: Thierry Reding <thierry.reding at avionic-design.de>
> Cc: Dom Cobley <popcornmix at gmail.com>
> Cc: Linus Walleij <linus.walleij at linaro.org>
> Cc: Arnd Bergmann <arnd at arndb.de>
> Cc: Andrew Morton <akpm at linux-foundation.org>
> Cc: Pawel Moll <pawel.moll at arm.com>
> Cc: Mark Brown <broonie at opensource.wolfsonmicro.com>
> Cc: Russell King - ARM Linux <linux at arm.linux.org.uk>
> Cc: Rabeeh Khoury <rabeeh at solid-run.com>
> Cc: Daniel Mack <zonque at gmail.com>
> Cc: Jean-Francois Moine <moinejf at free.fr>
> Cc: Lars-Peter Clausen <lars at metafoo.de>
> Cc: Guenter Roeck <linux at roeck-us.net>

Acked-by: Guenter Roeck <linux at roeck-us.net>

> Cc: Michal Bachraty <michal.bachraty at streamunlimited.com>
> Cc: devicetree-discuss at lists.ozlabs.org
> Cc: linux-doc at vger.kernel.org
> Cc: linux-kernel at vger.kernel.org
> Cc: linux-arm-kernel at lists.infradead.org
> ---
>  .../devicetree/bindings/clock/silabs,si5351.txt    |  114 ++
>  .../devicetree/bindings/vendor-prefixes.txt        |    1 +
>  drivers/clk/Kconfig                                |    9 +
>  drivers/clk/Makefile                               |    1 +
>  drivers/clk/clk-si5351.c                           | 1506 ++++++++++++++++++++
>  drivers/clk/clk-si5351.h                           |  155 ++
>  include/linux/platform_data/si5351.h               |  114 ++
>  7 files changed, 1900 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/clock/silabs,si5351.txt
>  create mode 100644 drivers/clk/clk-si5351.c
>  create mode 100644 drivers/clk/clk-si5351.h
>  create mode 100644 include/linux/platform_data/si5351.h
> 
> diff --git a/Documentation/devicetree/bindings/clock/silabs,si5351.txt b/Documentation/devicetree/bindings/clock/silabs,si5351.txt
> new file mode 100644
> index 0000000..cc37465
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/silabs,si5351.txt
> @@ -0,0 +1,114 @@
> +Binding for Silicon Labs Si5351a/b/c programmable i2c clock generator.
> +
> +Reference
> +[1] Si5351A/B/C Data Sheet
> +    http://www.silabs.com/Support%20Documents/TechnicalDocs/Si5351.pdf
> +
> +The Si5351a/b/c are programmable i2c clock generators with upto 8 output
> +clocks. Si5351a also has a reduced pin-count package (MSOP10) where only
> +3 output clocks are accessible. The internal structure of the clock
> +generators can be found in [1].
> +
> +==I2C device node==
> +
> +Required properties:
> +- compatible: shall be one of "silabs,si5351{a,a-msop,b,c}".
> +- reg: i2c device address, shall be 0x60 or 0x61.
> +- #clock-cells: from common clock binding; shall be set to 1.
> +- clocks: from common clock binding; list of parent clock
> +  handles, shall be xtal reference clock or xtal and clkin for
> +  si5351c only.
> +- #address-cells: shall be set to 1.
> +- #size-cells: shall be set to 0.
> +
> +Optional properties:
> +- silabs,pll-source: pair of (number, source) for each pll. Allows
> +  to overwrite clock source of pll A (number=0) or B (number=1).
> +
> +==Child nodes==
> +
> +Each of the clock outputs can be overwritten individually by
> +using a child node to the I2C device node. If a child node for a clock
> +output is not set, the eeprom configuration is not overwritten.
> +
> +Required child node properties:
> +- reg: number of clock output.
> +
> +Optional child node properties:
> +- silabs,clock-source: source clock of the output divider stage N, shall be
> +  0 = multisynth N
> +  1 = multisynth 0 for output clocks 0-3, else multisynth4
> +  2 = xtal
> +  3 = clkin (si5351c only)
> +- silabs,drive-strength: output drive strength in mA, shall be one of {2,4,6,8}.
> +- silabs,multisynth-source: source pll A(0) or B(1) of corresponding multisynth
> +  divider.
> +- silabs,pll-master: boolean, multisynth can change pll frequency.
> +
> +==Example==
> +
> +/* 25MHz reference crystal */
> +ref25: ref25M {
> +	compatible = "fixed-clock";
> +	#clock-cells = <0>;
> +	clock-frequency = <25000000>;
> +};
> +
> +i2c-master-node {
> +
> +	/* Si5351a msop10 i2c clock generator */
> +	si5351a: clock-generator at 60 {
> +		compatible = "silabs,si5351a-msop";
> +		reg = <0x60>;
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +		#clock-cells = <1>;
> +
> +		/* connect xtal input to 25MHz reference */
> +		clocks = <&ref25>;
> +
> +		/* connect xtal input as source of pll0 and pll1 */
> +		silabs,pll-source = <0 0>, <1 0>;
> +
> +		/*
> +		 * overwrite clkout0 configuration with:
> +		 * - 8mA output drive strength
> +		 * - pll0 as clock source of multisynth0
> +		 * - multisynth0 as clock source of output divider
> +		 * - multisynth0 can change pll0
> +		 * - set initial clock frequency of 74.25MHz
> +		 */
> +		clkout0 {
> +			reg = <0>;
> +			silabs,drive-strength = <8>;
> +			silabs,multisynth-source = <0>;
> +			silabs,clock-source = <0>;
> +			silabs,pll-master;
> +			clock-frequency = <74250000>;
> +		};
> +
> +		/*
> +		 * overwrite clkout1 configuration with:
> +		 * - 4mA output drive strength
> +		 * - pll1 as clock source of multisynth1
> +		 * - multisynth1 as clock source of output divider
> +		 * - multisynth1 can change pll1
> +		 */
> +		clkout1 {
> +			reg = <1>;
> +			silabs,drive-strength = <4>;
> +			silabs,multisynth-source = <1>;
> +			silabs,clock-source = <0>;
> +			pll-master;
> +		};
> +
> +		/*
> +		 * overwrite clkout2 configuration with:
> +		 * - xtal as clock source of output divider
> +		 */
> +		clkout2 {
> +			reg = <2>;
> +			silabs,clock-source = <2>;
> +		};
> +	};
> +};
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
> index 19e1ef7..ca60849 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> @@ -48,6 +48,7 @@ samsung	Samsung Semiconductor
>  sbs	Smart Battery System
>  schindler	Schindler
>  sil	Silicon Image
> +silabs	Silicon Laboratories
>  simtek
>  sirf	SiRF Technology, Inc.
>  snps 	Synopsys, Inc.
> diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
> index a47e6ee..5039e41 100644
> --- a/drivers/clk/Kconfig
> +++ b/drivers/clk/Kconfig
> @@ -55,6 +55,15 @@ config COMMON_CLK_MAX77686
>  	---help---
>  	  This driver supports Maxim 77686 crystal oscillator clock. 
>  
> +config COMMON_CLK_SI5351
> +	tristate "Clock driver for SiLabs 5351A/B/C"
> +	depends on I2C
> +	select REGMAP_I2C
> +	select RATIONAL
> +	---help---
> +	  This driver supports Silicon Labs 5351A/B/C programmable clock
> +	  generators.
> +
>  config CLK_TWL6040
>  	tristate "External McPDM functional clock from twl6040"
>  	depends on TWL6040_CORE
> diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
> index 300d477..92ca698 100644
> --- a/drivers/clk/Makefile
> +++ b/drivers/clk/Makefile
> @@ -33,4 +33,5 @@ obj-$(CONFIG_X86)		+= x86/
>  # Chip specific
>  obj-$(CONFIG_COMMON_CLK_WM831X) += clk-wm831x.o
>  obj-$(CONFIG_COMMON_CLK_MAX77686) += clk-max77686.o
> +obj-$(CONFIG_COMMON_CLK_SI5351) += clk-si5351.o
>  obj-$(CONFIG_CLK_TWL6040)	+= clk-twl6040.o
> diff --git a/drivers/clk/clk-si5351.c b/drivers/clk/clk-si5351.c
> new file mode 100644
> index 0000000..4e2506c
> --- /dev/null
> +++ b/drivers/clk/clk-si5351.c
> @@ -0,0 +1,1506 @@
> +/*
> + * clk-si5351.c: Silicon Laboratories Si5351A/B/C I2C Clock Generator
> + *
> + * Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
> + * Rabeeh Khoury <rabeeh at solid-run.com>
> + *
> + * References:
> + * [1] "Si5351A/B/C Data Sheet"
> + *     http://www.silabs.com/Support%20Documents/TechnicalDocs/Si5351.pdf
> + * [2] "Manually Generating an Si5351 Register Map"
> + *     http://www.silabs.com/Support%20Documents/TechnicalDocs/AN619.pdf
> + *
> + * 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.
> + */
> +
> +#include <linux/module.h>
> +#include <linux/kernel.h>
> +#include <linux/clkdev.h>
> +#include <linux/clk-provider.h>
> +#include <linux/delay.h>
> +#include <linux/err.h>
> +#include <linux/errno.h>
> +#include <linux/rational.h>
> +#include <linux/i2c.h>
> +#include <linux/of_platform.h>
> +#include <linux/platform_data/si5351.h>
> +#include <linux/regmap.h>
> +#include <linux/slab.h>
> +#include <linux/string.h>
> +#include <asm/div64.h>
> +
> +#include "clk-si5351.h"
> +
> +struct si5351_driver_data;
> +
> +struct si5351_parameters {
> +	unsigned long	p1;
> +	unsigned long	p2;
> +	unsigned long	p3;
> +	int		valid;
> +};
> +
> +struct si5351_hw_data {
> +	struct clk_hw			hw;
> +	struct si5351_driver_data	*drvdata;
> +	struct si5351_parameters	params;
> +	unsigned char			num;
> +};
> +
> +struct si5351_driver_data {
> +	enum si5351_variant	variant;
> +	struct i2c_client	*client;
> +	struct regmap		*regmap;
> +	struct clk_onecell_data onecell;
> +
> +	struct clk		*pxtal;
> +	const char		*pxtal_name;
> +	struct clk_hw		xtal;
> +	struct clk		*pclkin;
> +	const char		*pclkin_name;
> +	struct clk_hw		clkin;
> +
> +	struct si5351_hw_data	pll[2];
> +	struct si5351_hw_data	*msynth;
> +	struct si5351_hw_data	*clkout;
> +};
> +
> +static const char const *si5351_input_names[] = {
> +	"xtal", "clkin"
> +};
> +static const char const *si5351_pll_names[] = {
> +	"plla", "pllb", "vxco"
> +};
> +static const char const *si5351_msynth_names[] = {
> +	"ms0", "ms1", "ms2", "ms3", "ms4", "ms5", "ms6", "ms7"
> +};
> +static const char const *si5351_clkout_names[] = {
> +	"clk0", "clk1", "clk2", "clk3", "clk4", "clk5", "clk6", "clk7"
> +};
> +
> +/*
> + * Si5351 i2c regmap
> + */
> +static inline u8 si5351_reg_read(struct si5351_driver_data *drvdata, u8 reg)
> +{
> +	u32 val;
> +	int ret;
> +
> +	ret = regmap_read(drvdata->regmap, reg, &val);
> +	if (ret) {
> +		dev_err(&drvdata->client->dev,
> +			"unable to read from reg%02x\n", reg);
> +		return 0;
> +	}
> +
> +	return (u8)val;
> +}
> +
> +static inline int si5351_bulk_read(struct si5351_driver_data *drvdata,
> +				   u8 reg, u8 count, u8 *buf)
> +{
> +	return regmap_bulk_read(drvdata->regmap, reg, buf, count);
> +}
> +
> +static inline int si5351_reg_write(struct si5351_driver_data *drvdata,
> +				   u8 reg, u8 val)
> +{
> +	return regmap_write(drvdata->regmap, reg, val);
> +}
> +
> +static inline int si5351_bulk_write(struct si5351_driver_data *drvdata,
> +				    u8 reg, u8 count, const u8 *buf)
> +{
> +	return regmap_raw_write(drvdata->regmap, reg, buf, count);
> +}
> +
> +static inline int si5351_set_bits(struct si5351_driver_data *drvdata,
> +				  u8 reg, u8 mask, u8 val)
> +{
> +	return regmap_update_bits(drvdata->regmap, reg, mask, val);
> +}
> +
> +static inline u8 si5351_msynth_params_address(int num)
> +{
> +	if (num > 5)
> +		return SI5351_CLK6_PARAMETERS + (num - 6);
> +	return SI5351_CLK0_PARAMETERS + (SI5351_PARAMETERS_LENGTH * num);
> +}
> +
> +static void si5351_read_parameters(struct si5351_driver_data *drvdata,
> +				   u8 reg, struct si5351_parameters *params)
> +{
> +	u8 buf[SI5351_PARAMETERS_LENGTH];
> +
> +	switch (reg) {
> +	case SI5351_CLK6_PARAMETERS:
> +	case SI5351_CLK7_PARAMETERS:
> +		buf[0] = si5351_reg_read(drvdata, reg);
> +		params->p1 = buf[0];
> +		params->p2 = 0;
> +		params->p3 = 1;
> +		break;
> +	default:
> +		si5351_bulk_read(drvdata, reg, SI5351_PARAMETERS_LENGTH, buf);
> +		params->p1 = ((buf[2] & 0x03) << 16) | (buf[3] << 8) | buf[4];
> +		params->p2 = ((buf[5] & 0x0f) << 16) | (buf[6] << 8) | buf[7];
> +		params->p3 = ((buf[5] & 0xf0) << 12) | (buf[0] << 8) | buf[1];
> +	}
> +	params->valid = 1;
> +}
> +
> +static void si5351_write_parameters(struct si5351_driver_data *drvdata,
> +				    u8 reg, struct si5351_parameters *params)
> +{
> +	u8 buf[SI5351_PARAMETERS_LENGTH];
> +
> +	switch (reg) {
> +	case SI5351_CLK6_PARAMETERS:
> +	case SI5351_CLK7_PARAMETERS:
> +		buf[0] = params->p1 & 0xff;
> +		si5351_reg_write(drvdata, reg, buf[0]);
> +		break;
> +	default:
> +		buf[0] = ((params->p3 & 0x0ff00) >> 8) & 0xff;
> +		buf[1] = params->p3 & 0xff;
> +		/* save rdiv and divby4 */
> +		buf[2] = si5351_reg_read(drvdata, reg + 2) & ~0x03;
> +		buf[2] |= ((params->p1 & 0x30000) >> 16) & 0x03;
> +		buf[3] = ((params->p1 & 0x0ff00) >> 8) & 0xff;
> +		buf[4] = params->p1 & 0xff;
> +		buf[5] = ((params->p3 & 0xf0000) >> 12) |
> +			((params->p2 & 0xf0000) >> 16);
> +		buf[6] = ((params->p2 & 0x0ff00) >> 8) & 0xff;
> +		buf[7] = params->p2 & 0xff;
> +		si5351_bulk_write(drvdata, reg, SI5351_PARAMETERS_LENGTH, buf);
> +	}
> +}
> +
> +static bool si5351_regmap_is_volatile(struct device *dev, unsigned int reg)
> +{
> +	switch (reg) {
> +	case SI5351_DEVICE_STATUS:
> +	case SI5351_INTERRUPT_STATUS:
> +	case SI5351_PLL_RESET:
> +		return true;
> +	}
> +	return false;
> +}
> +
> +static bool si5351_regmap_is_writeable(struct device *dev, unsigned int reg)
> +{
> +	/* reserved registers */
> +	if (reg >= 4 && reg <= 8)
> +		return false;
> +	if (reg >= 10 && reg <= 14)
> +		return false;
> +	if (reg >= 173 && reg <= 176)
> +		return false;
> +	if (reg >= 178 && reg <= 182)
> +		return false;
> +	/* read-only */
> +	if (reg == SI5351_DEVICE_STATUS)
> +		return false;
> +	return true;
> +}
> +
> +static struct regmap_config si5351_regmap_config = {
> +	.reg_bits = 8,
> +	.val_bits = 8,
> +	.cache_type = REGCACHE_RBTREE,
> +	.max_register = 187,
> +	.writeable_reg = si5351_regmap_is_writeable,
> +	.volatile_reg = si5351_regmap_is_volatile,
> +};
> +
> +/*
> + * Si5351 xtal clock input
> + */
> +static int si5351_xtal_prepare(struct clk_hw *hw)
> +{
> +	struct si5351_driver_data *drvdata =
> +		container_of(hw, struct si5351_driver_data, xtal);
> +	si5351_set_bits(drvdata, SI5351_FANOUT_ENABLE,
> +			SI5351_XTAL_ENABLE, SI5351_XTAL_ENABLE);
> +	return 0;
> +}
> +
> +static void si5351_xtal_unprepare(struct clk_hw *hw)
> +{
> +	struct si5351_driver_data *drvdata =
> +		container_of(hw, struct si5351_driver_data, xtal);
> +	si5351_set_bits(drvdata, SI5351_FANOUT_ENABLE,
> +			SI5351_XTAL_ENABLE, 0);
> +}
> +
> +static const struct clk_ops si5351_xtal_ops = {
> +	.prepare = si5351_xtal_prepare,
> +	.unprepare = si5351_xtal_unprepare,
> +};
> +
> +/*
> + * Si5351 clkin clock input (Si5351C only)
> + */
> +static int si5351_clkin_prepare(struct clk_hw *hw)
> +{
> +	struct si5351_driver_data *drvdata =
> +		container_of(hw, struct si5351_driver_data, clkin);
> +	si5351_set_bits(drvdata, SI5351_FANOUT_ENABLE,
> +			SI5351_CLKIN_ENABLE, SI5351_CLKIN_ENABLE);
> +	return 0;
> +}
> +
> +static void si5351_clkin_unprepare(struct clk_hw *hw)
> +{
> +	struct si5351_driver_data *drvdata =
> +		container_of(hw, struct si5351_driver_data, clkin);
> +	si5351_set_bits(drvdata, SI5351_FANOUT_ENABLE,
> +			SI5351_CLKIN_ENABLE, 0);
> +}
> +
> +/*
> + * CMOS clock source constraints:
> + * The input frequency range of the PLL is 10Mhz to 40MHz.
> + * If CLKIN is >40MHz, the input divider must be used.
> + */
> +static unsigned long si5351_clkin_recalc_rate(struct clk_hw *hw,
> +					      unsigned long parent_rate)
> +{
> +	struct si5351_driver_data *drvdata =
> +		container_of(hw, struct si5351_driver_data, clkin);
> +	unsigned long rate;
> +	unsigned char idiv;
> +
> +	rate = parent_rate;
> +	if (parent_rate > 160000000) {
> +		idiv = SI5351_CLKIN_DIV_8;
> +		rate /= 8;
> +	} else if (parent_rate > 80000000) {
> +		idiv = SI5351_CLKIN_DIV_4;
> +		rate /= 4;
> +	} else if (parent_rate > 40000000) {
> +		idiv = SI5351_CLKIN_DIV_2;
> +		rate /= 2;
> +	} else {
> +		idiv = SI5351_CLKIN_DIV_1;
> +	}
> +
> +	si5351_set_bits(drvdata, SI5351_PLL_INPUT_SOURCE,
> +			SI5351_CLKIN_DIV_MASK, idiv);
> +
> +	dev_dbg(&drvdata->client->dev, "%s - clkin div = %d, rate = %lu\n",
> +		__func__, (1 << (idiv >> 6)), rate);
> +
> +	return rate;
> +}
> +
> +static const struct clk_ops si5351_clkin_ops = {
> +	.prepare = si5351_clkin_prepare,
> +	.unprepare = si5351_clkin_unprepare,
> +	.recalc_rate = si5351_clkin_recalc_rate,
> +};
> +
> +/*
> + * Si5351 vxco clock input (Si5351B only)
> + */
> +
> +static int si5351_vxco_prepare(struct clk_hw *hw)
> +{
> +	struct si5351_hw_data *hwdata =
> +		container_of(hw, struct si5351_hw_data, hw);
> +
> +	dev_warn(&hwdata->drvdata->client->dev, "VXCO currently unsupported\n");
> +
> +	return 0;
> +}
> +
> +static void si5351_vxco_unprepare(struct clk_hw *hw)
> +{
> +}
> +
> +static unsigned long si5351_vxco_recalc_rate(struct clk_hw *hw,
> +					     unsigned long parent_rate)
> +{
> +	return 0;
> +}
> +
> +static int si5351_vxco_set_rate(struct clk_hw *hw, unsigned long rate,
> +				unsigned long parent)
> +{
> +	return 0;
> +}
> +
> +static const struct clk_ops si5351_vxco_ops = {
> +	.prepare = si5351_vxco_prepare,
> +	.unprepare = si5351_vxco_unprepare,
> +	.recalc_rate = si5351_vxco_recalc_rate,
> +	.set_rate = si5351_vxco_set_rate,
> +};
> +
> +/*
> + * Si5351 pll a/b
> + *
> + * Feedback Multisynth Divider Equations [2]
> + *
> + * fVCO = fIN * (a + b/c)
> + *
> + * with 15 + 0/1048575 <= (a + b/c) <= 90 + 0/1048575 and
> + * fIN = fXTAL or fIN = fCLKIN/CLKIN_DIV
> + *
> + * Feedback Multisynth Register Equations
> + *
> + * (1) MSNx_P1[17:0] = 128 * a + floor(128 * b/c) - 512
> + * (2) MSNx_P2[19:0] = 128 * b - c * floor(128 * b/c) = (128*b) mod c
> + * (3) MSNx_P3[19:0] = c
> + *
> + * Transposing (2) yields: (4) floor(128 * b/c) = (128 * b / MSNx_P2)/c
> + *
> + * Using (4) on (1) yields:
> + * MSNx_P1 = 128 * a + (128 * b/MSNx_P2)/c - 512
> + * MSNx_P1 + 512 + MSNx_P2/c = 128 * a + 128 * b/c
> + *
> + * a + b/c = (MSNx_P1 + MSNx_P2/MSNx_P3 + 512)/128
> + *         = (MSNx_P1*MSNx_P3 + MSNx_P2 + 512*MSNx_P3)/(128*MSNx_P3)
> + *
> + */
> +static int _si5351_pll_reparent(struct si5351_driver_data *drvdata,
> +				int num, enum si5351_pll_src parent)
> +{
> +	u8 mask = (num == 0) ? SI5351_PLLA_SOURCE : SI5351_PLLB_SOURCE;
> +
> +	if (parent == SI5351_PLL_SRC_DEFAULT)
> +		return 0;
> +
> +	if (num > 2)
> +		return -EINVAL;
> +
> +	if (drvdata->variant != SI5351_VARIANT_C &&
> +	    parent != SI5351_PLL_SRC_XTAL)
> +		return -EINVAL;
> +
> +	si5351_set_bits(drvdata, SI5351_PLL_INPUT_SOURCE, mask,
> +			(parent == SI5351_PLL_SRC_XTAL) ? 0 : mask);
> +	return 0;
> +}
> +
> +static unsigned char si5351_pll_get_parent(struct clk_hw *hw)
> +{
> +	struct si5351_hw_data *hwdata =
> +		container_of(hw, struct si5351_hw_data, hw);
> +	u8 mask = (hwdata->num == 0) ? SI5351_PLLA_SOURCE : SI5351_PLLB_SOURCE;
> +	u8 val;
> +
> +	val = si5351_reg_read(hwdata->drvdata, SI5351_PLL_INPUT_SOURCE);
> +
> +	return (val & mask) ? 1 : 0;
> +}
> +
> +static int si5351_pll_set_parent(struct clk_hw *hw, u8 index)
> +{
> +	struct si5351_hw_data *hwdata =
> +		container_of(hw, struct si5351_hw_data, hw);
> +
> +	if (hwdata->drvdata->variant != SI5351_VARIANT_C &&
> +	    index > 0)
> +		return -EPERM;
> +
> +	if (index > 1)
> +		return -EINVAL;
> +
> +	return _si5351_pll_reparent(hwdata->drvdata, hwdata->num,
> +			     (index == 0) ? SI5351_PLL_SRC_XTAL :
> +			     SI5351_PLL_SRC_CLKIN);
> +}
> +
> +static unsigned long si5351_pll_recalc_rate(struct clk_hw *hw,
> +					    unsigned long parent_rate)
> +{
> +	struct si5351_hw_data *hwdata =
> +		container_of(hw, struct si5351_hw_data, hw);
> +	u8 reg = (hwdata->num == 0) ? SI5351_PLLA_PARAMETERS :
> +		SI5351_PLLB_PARAMETERS;
> +	unsigned long long rate;
> +
> +	if (!hwdata->params.valid)
> +		si5351_read_parameters(hwdata->drvdata, reg, &hwdata->params);
> +
> +	if (hwdata->params.p3 == 0)
> +		return parent_rate;
> +
> +	/* fVCO = fIN * (P1*P3 + 512*P3 + P2)/(128*P3) */
> +	rate  = hwdata->params.p1 * hwdata->params.p3;
> +	rate += 512 * hwdata->params.p3;
> +	rate += hwdata->params.p2;
> +	rate *= parent_rate;
> +	do_div(rate, 128 * hwdata->params.p3);
> +
> +	dev_dbg(&hwdata->drvdata->client->dev,
> +		"%s - %s: p1 = %lu, p2 = %lu, p3 = %lu, parent_rate = %lu, rate = %lu\n",
> +		__func__, __clk_get_name(hwdata->hw.clk),
> +		hwdata->params.p1, hwdata->params.p2, hwdata->params.p3,
> +		parent_rate, (unsigned long)rate);
> +
> +	return (unsigned long)rate;
> +}
> +
> +static long si5351_pll_round_rate(struct clk_hw *hw, unsigned long rate,
> +				  unsigned long *parent_rate)
> +{
> +	struct si5351_hw_data *hwdata =
> +		container_of(hw, struct si5351_hw_data, hw);
> +	unsigned long rfrac, denom, a, b, c;
> +	unsigned long long lltmp;
> +
> +	if (rate < SI5351_PLL_VCO_MIN)
> +		rate = SI5351_PLL_VCO_MIN;
> +	if (rate > SI5351_PLL_VCO_MAX)
> +		rate = SI5351_PLL_VCO_MAX;
> +
> +	/* determine integer part of feedback equation */
> +	a = rate / *parent_rate;
> +
> +	if (a < SI5351_PLL_A_MIN)
> +		rate = *parent_rate * SI5351_PLL_A_MIN;
> +	if (a > SI5351_PLL_A_MAX)
> +		rate = *parent_rate * SI5351_PLL_A_MAX;
> +
> +	/* find best approximation for b/c = fVCO mod fIN */
> +	denom = 1000 * 1000;
> +	lltmp = rate % (*parent_rate);
> +	lltmp *= denom;
> +	do_div(lltmp, *parent_rate);
> +	rfrac = (unsigned long)lltmp;
> +
> +	b = 0;
> +	c = 1;
> +	if (rfrac)
> +		rational_best_approximation(rfrac, denom,
> +				    SI5351_PLL_B_MAX, SI5351_PLL_C_MAX, &b, &c);
> +
> +	/* calculate parameters */
> +	hwdata->params.p3  = c;
> +	hwdata->params.p2  = (128 * b) % c;
> +	hwdata->params.p1  = 128 * a;
> +	hwdata->params.p1 += (128 * b / c);
> +	hwdata->params.p1 -= 512;
> +
> +	/* recalculate rate by fIN * (a + b/c) */
> +	lltmp  = *parent_rate;
> +	lltmp *= b;
> +	do_div(lltmp, c);
> +
> +	rate  = (unsigned long)lltmp;
> +	rate += *parent_rate * a;
> +
> +	dev_dbg(&hwdata->drvdata->client->dev,
> +		"%s - %s: a = %lu, b = %lu, c = %lu, parent_rate = %lu, rate = %lu\n",
> +		__func__, __clk_get_name(hwdata->hw.clk), a, b, c,
> +		*parent_rate, rate);
> +
> +	return rate;
> +}
> +
> +static int si5351_pll_set_rate(struct clk_hw *hw, unsigned long rate,
> +			       unsigned long parent_rate)
> +{
> +	struct si5351_hw_data *hwdata =
> +		container_of(hw, struct si5351_hw_data, hw);
> +	u8 reg = (hwdata->num == 0) ? SI5351_PLLA_PARAMETERS :
> +		SI5351_PLLB_PARAMETERS;
> +
> +	/* write multisynth parameters */
> +	si5351_write_parameters(hwdata->drvdata, reg, &hwdata->params);
> +
> +	/* plla/pllb ctrl is in clk6/clk7 ctrl registers */
> +	si5351_set_bits(hwdata->drvdata, SI5351_CLK6_CTRL + hwdata->num,
> +		SI5351_CLK_INTEGER_MODE,
> +		(hwdata->params.p2 == 0) ? SI5351_CLK_INTEGER_MODE : 0);
> +
> +	dev_dbg(&hwdata->drvdata->client->dev,
> +		"%s - %s: p1 = %lu, p2 = %lu, p3 = %lu, parent_rate = %lu, rate = %lu\n",
> +		__func__, __clk_get_name(hwdata->hw.clk),
> +		hwdata->params.p1, hwdata->params.p2, hwdata->params.p3,
> +		parent_rate, rate);
> +
> +	return 0;
> +}
> +
> +static const struct clk_ops si5351_pll_ops = {
> +	.set_parent = si5351_pll_set_parent,
> +	.get_parent = si5351_pll_get_parent,
> +	.recalc_rate = si5351_pll_recalc_rate,
> +	.round_rate = si5351_pll_round_rate,
> +	.set_rate = si5351_pll_set_rate,
> +};
> +
> +/*
> + * Si5351 multisync divider
> + *
> + * for fOUT <= 150 MHz:
> + *
> + * fOUT = (fIN * (a + b/c)) / CLKOUTDIV
> + *
> + * with 6 + 0/1048575 <= (a + b/c) <= 1800 + 0/1048575 and
> + * fIN = fVCO0, fVCO1
> + *
> + * Output Clock Multisynth Register Equations
> + *
> + * MSx_P1[17:0] = 128 * a + floor(128 * b/c) - 512
> + * MSx_P2[19:0] = 128 * b - c * floor(128 * b/c) = (128*b) mod c
> + * MSx_P3[19:0] = c
> + *
> + * MS[6,7] are integer (P1) divide only, P2 = 0, P3 = 0
> + *
> + * for 150MHz < fOUT <= 160MHz:
> + *
> + * MSx_P1 = 0, MSx_P2 = 0, MSx_P3 = 1, MSx_INT = 1, MSx_DIVBY4 = 11b
> + */
> +static int _si5351_msynth_reparent(struct si5351_driver_data *drvdata,
> +				   int num, enum si5351_multisynth_src parent)
> +{
> +	if (parent == SI5351_MULTISYNTH_SRC_DEFAULT)
> +		return 0;
> +
> +	if (num > 8)
> +		return -EINVAL;
> +
> +	si5351_set_bits(drvdata, SI5351_CLK0_CTRL + num, SI5351_CLK_PLL_SELECT,
> +			(parent == SI5351_MULTISYNTH_SRC_VCO0) ? 0 :
> +			SI5351_CLK_PLL_SELECT);
> +	return 0;
> +}
> +
> +static unsigned char si5351_msynth_get_parent(struct clk_hw *hw)
> +{
> +	struct si5351_hw_data *hwdata =
> +		container_of(hw, struct si5351_hw_data, hw);
> +	u8 val;
> +
> +	val = si5351_reg_read(hwdata->drvdata, SI5351_CLK0_CTRL + hwdata->num);
> +
> +	return (val & SI5351_CLK_PLL_SELECT) ? 1 : 0;
> +}
> +
> +static int si5351_msynth_set_parent(struct clk_hw *hw, u8 index)
> +{
> +	struct si5351_hw_data *hwdata =
> +		container_of(hw, struct si5351_hw_data, hw);
> +
> +	return _si5351_msynth_reparent(hwdata->drvdata, hwdata->num,
> +			       (index == 0) ? SI5351_MULTISYNTH_SRC_VCO0 :
> +			       SI5351_MULTISYNTH_SRC_VCO1);
> +}
> +
> +static unsigned long si5351_msynth_recalc_rate(struct clk_hw *hw,
> +					       unsigned long parent_rate)
> +{
> +	struct si5351_hw_data *hwdata =
> +		container_of(hw, struct si5351_hw_data, hw);
> +	u8 reg = si5351_msynth_params_address(hwdata->num);
> +	unsigned long long rate;
> +	unsigned long m;
> +
> +	if (!hwdata->params.valid)
> +		si5351_read_parameters(hwdata->drvdata, reg, &hwdata->params);
> +
> +	if (hwdata->params.p3 == 0)
> +		return parent_rate;
> +
> +	/*
> +	 * multisync0-5: fOUT = (128 * P3 * fIN) / (P1*P3 + P2 + 512*P3)
> +	 * multisync6-7: fOUT = fIN / P1
> +	 */
> +	rate = parent_rate;
> +	if (hwdata->num > 5) {
> +		m = hwdata->params.p1;
> +	} else if ((si5351_reg_read(hwdata->drvdata, reg + 2) &
> +		    SI5351_OUTPUT_CLK_DIVBY4) == SI5351_OUTPUT_CLK_DIVBY4) {
> +		m = 4;
> +	} else {
> +		rate *= 128 * hwdata->params.p3;
> +		m = hwdata->params.p1 * hwdata->params.p3;
> +		m += hwdata->params.p2;
> +		m += 512 * hwdata->params.p3;
> +	}
> +
> +	if (m == 0)
> +		return 0;
> +	do_div(rate, m);
> +
> +	dev_dbg(&hwdata->drvdata->client->dev,
> +		"%s - %s: p1 = %lu, p2 = %lu, p3 = %lu, m = %lu, parent_rate = %lu, rate = %lu\n",
> +		__func__, __clk_get_name(hwdata->hw.clk),
> +		hwdata->params.p1, hwdata->params.p2, hwdata->params.p3,
> +		m, parent_rate, (unsigned long)rate);
> +
> +	return (unsigned long)rate;
> +}
> +
> +static long si5351_msynth_round_rate(struct clk_hw *hw, unsigned long rate,
> +				     unsigned long *parent_rate)
> +{
> +	struct si5351_hw_data *hwdata =
> +		container_of(hw, struct si5351_hw_data, hw);
> +	unsigned long long lltmp;
> +	unsigned long a, b, c;
> +	int divby4;
> +
> +	/* multisync6-7 can only handle freqencies < 150MHz */
> +	if (hwdata->num >= 6 && rate > SI5351_MULTISYNTH67_MAX_FREQ)
> +		rate = SI5351_MULTISYNTH67_MAX_FREQ;
> +
> +	/* multisync frequency is 1MHz .. 160MHz */
> +	if (rate > SI5351_MULTISYNTH_MAX_FREQ)
> +		rate = SI5351_MULTISYNTH_MAX_FREQ;
> +	if (rate < SI5351_MULTISYNTH_MIN_FREQ)
> +		rate = SI5351_MULTISYNTH_MIN_FREQ;
> +
> +	divby4 = 0;
> +	if (rate > SI5351_MULTISYNTH_DIVBY4_FREQ)
> +		divby4 = 1;
> +
> +	/* multisync can set pll */
> +	if (__clk_get_flags(hwdata->hw.clk) & CLK_SET_RATE_PARENT) {
> +		/*
> +		 * find largest integer divider for max
> +		 * vco frequency and given target rate
> +		 */
> +		if (divby4 == 0) {
> +			lltmp = SI5351_PLL_VCO_MAX;
> +			do_div(lltmp, rate);
> +			a = (unsigned long)lltmp;
> +		} else
> +			a = 4;
> +
> +		b = 0;
> +		c = 1;
> +
> +		*parent_rate = a * rate;
> +	} else {
> +		unsigned long rfrac, denom;
> +
> +		/* disable divby4 */
> +		if (divby4) {
> +			rate = SI5351_MULTISYNTH_DIVBY4_FREQ;
> +			divby4 = 0;
> +		}
> +
> +		/* determine integer part of divider equation */
> +		a = *parent_rate / rate;
> +		if (a < SI5351_MULTISYNTH_A_MIN)
> +			a = SI5351_MULTISYNTH_A_MIN;
> +		if (hwdata->num >= 6 && a > SI5351_MULTISYNTH67_A_MAX)
> +			a = SI5351_MULTISYNTH67_A_MAX;
> +		else if (a > SI5351_MULTISYNTH_A_MAX)
> +			a = SI5351_MULTISYNTH_A_MAX;
> +
> +		/* find best approximation for b/c = fVCO mod fOUT */
> +		denom = 1000 * 1000;
> +		lltmp = (*parent_rate) % rate;
> +		lltmp *= denom;
> +		do_div(lltmp, rate);
> +		rfrac = (unsigned long)lltmp;
> +
> +		b = 0;
> +		c = 1;
> +		if (rfrac)
> +			rational_best_approximation(rfrac, denom,
> +			    SI5351_MULTISYNTH_B_MAX, SI5351_MULTISYNTH_C_MAX,
> +			    &b, &c);
> +	}
> +
> +	/* recalculate rate by fOUT = fIN / (a + b/c) */
> +	lltmp  = *parent_rate;
> +	lltmp *= c;
> +	do_div(lltmp, a * c + b);
> +	rate  = (unsigned long)lltmp;
> +
> +	/* calculate parameters */
> +	if (divby4) {
> +		hwdata->params.p3 = 1;
> +		hwdata->params.p2 = 0;
> +		hwdata->params.p1 = 0;
> +	} else {
> +		hwdata->params.p3  = c;
> +		hwdata->params.p2  = (128 * b) % c;
> +		hwdata->params.p1  = 128 * a;
> +		hwdata->params.p1 += (128 * b / c);
> +		hwdata->params.p1 -= 512;
> +	}
> +
> +	dev_dbg(&hwdata->drvdata->client->dev,
> +		"%s - %s: a = %lu, b = %lu, c = %lu, divby4 = %d, parent_rate = %lu, rate = %lu\n",
> +		__func__, __clk_get_name(hwdata->hw.clk), a, b, c, divby4,
> +		*parent_rate, rate);
> +
> +	return rate;
> +}
> +
> +static int si5351_msynth_set_rate(struct clk_hw *hw, unsigned long rate,
> +				  unsigned long parent_rate)
> +{
> +	struct si5351_hw_data *hwdata =
> +		container_of(hw, struct si5351_hw_data, hw);
> +	u8 reg = si5351_msynth_params_address(hwdata->num);
> +	int divby4 = 0;
> +
> +	/* write multisynth parameters */
> +	si5351_write_parameters(hwdata->drvdata, reg, &hwdata->params);
> +
> +	if (rate > SI5351_MULTISYNTH_DIVBY4_FREQ)
> +		divby4 = 1;
> +
> +	/* enable/disable integer mode and divby4 on multisynth0-5 */
> +	if (hwdata->num < 6) {
> +		si5351_set_bits(hwdata->drvdata, reg + 2,
> +				SI5351_OUTPUT_CLK_DIVBY4,
> +				(divby4) ? SI5351_OUTPUT_CLK_DIVBY4 : 0);
> +		si5351_set_bits(hwdata->drvdata, SI5351_CLK0_CTRL + hwdata->num,
> +			SI5351_CLK_INTEGER_MODE,
> +			(hwdata->params.p2 == 0) ? SI5351_CLK_INTEGER_MODE : 0);
> +	}
> +
> +	dev_dbg(&hwdata->drvdata->client->dev,
> +		"%s - %s: p1 = %lu, p2 = %lu, p3 = %lu, divby4 = %d, parent_rate = %lu, rate = %lu\n",
> +		__func__, __clk_get_name(hwdata->hw.clk),
> +		hwdata->params.p1, hwdata->params.p2, hwdata->params.p3,
> +		divby4, parent_rate, rate);
> +
> +	return 0;
> +}
> +
> +static const struct clk_ops si5351_msynth_ops = {
> +	.set_parent = si5351_msynth_set_parent,
> +	.get_parent = si5351_msynth_get_parent,
> +	.recalc_rate = si5351_msynth_recalc_rate,
> +	.round_rate = si5351_msynth_round_rate,
> +	.set_rate = si5351_msynth_set_rate,
> +};
> +
> +/*
> + * Si5351 clkout divider
> + */
> +static int _si5351_clkout_reparent(struct si5351_driver_data *drvdata,
> +				   int num, enum si5351_clkout_src parent)
> +{
> +	u8 val;
> +
> +	if (num > 8)
> +		return -EINVAL;
> +
> +	switch (parent) {
> +	case SI5351_CLKOUT_SRC_MSYNTH_N:
> +		val = SI5351_CLK_INPUT_MULTISYNTH_N;
> +		break;
> +	case SI5351_CLKOUT_SRC_MSYNTH_0_4:
> +		/* clk0/clk4 can only connect to its own multisync */
> +		if (num == 0 || num == 4)
> +			val = SI5351_CLK_INPUT_MULTISYNTH_N;
> +		else
> +			val = SI5351_CLK_INPUT_MULTISYNTH_0_4;
> +		break;
> +	case SI5351_CLKOUT_SRC_XTAL:
> +		val = SI5351_CLK_INPUT_XTAL;
> +		break;
> +	case SI5351_CLKOUT_SRC_CLKIN:
> +		if (drvdata->variant != SI5351_VARIANT_C)
> +			return -EINVAL;
> +
> +		val = SI5351_CLK_INPUT_CLKIN;
> +		break;
> +	default:
> +		return 0;
> +	}
> +
> +	si5351_set_bits(drvdata, SI5351_CLK0_CTRL + num,
> +			SI5351_CLK_INPUT_MASK, val);
> +	return 0;
> +}
> +
> +static int _si5351_clkout_set_drive_strength(
> +	struct si5351_driver_data *drvdata, int num,
> +	enum si5351_drive_strength drive)
> +{
> +	u8 mask;
> +
> +	if (num > 8)
> +		return -EINVAL;
> +
> +	switch (drive) {
> +	case SI5351_DRIVE_2MA:
> +		mask = SI5351_CLK_DRIVE_STRENGTH_2MA;
> +		break;
> +	case SI5351_DRIVE_4MA:
> +		mask = SI5351_CLK_DRIVE_STRENGTH_4MA;
> +		break;
> +	case SI5351_DRIVE_6MA:
> +		mask = SI5351_CLK_DRIVE_STRENGTH_6MA;
> +		break;
> +	case SI5351_DRIVE_8MA:
> +		mask = SI5351_CLK_DRIVE_STRENGTH_8MA;
> +		break;
> +	default:
> +		return 0;
> +	}
> +
> +	si5351_set_bits(drvdata, SI5351_CLK0_CTRL + num,
> +			SI5351_CLK_DRIVE_STRENGTH_MASK, mask);
> +	return 0;
> +}
> +
> +static int si5351_clkout_prepare(struct clk_hw *hw)
> +{
> +	struct si5351_hw_data *hwdata =
> +		container_of(hw, struct si5351_hw_data, hw);
> +
> +	si5351_set_bits(hwdata->drvdata, SI5351_CLK0_CTRL + hwdata->num,
> +			SI5351_CLK_POWERDOWN, 0);
> +	si5351_set_bits(hwdata->drvdata, SI5351_OUTPUT_ENABLE_CTRL,
> +			(1 << hwdata->num), 0);
> +	return 0;
> +}
> +
> +static void si5351_clkout_unprepare(struct clk_hw *hw)
> +{
> +	struct si5351_hw_data *hwdata =
> +		container_of(hw, struct si5351_hw_data, hw);
> +
> +	si5351_set_bits(hwdata->drvdata, SI5351_CLK0_CTRL + hwdata->num,
> +			SI5351_CLK_POWERDOWN, SI5351_CLK_POWERDOWN);
> +	si5351_set_bits(hwdata->drvdata, SI5351_OUTPUT_ENABLE_CTRL,
> +			(1 << hwdata->num), (1 << hwdata->num));
> +}
> +
> +static u8 si5351_clkout_get_parent(struct clk_hw *hw)
> +{
> +	struct si5351_hw_data *hwdata =
> +		container_of(hw, struct si5351_hw_data, hw);
> +	int index = 0;
> +	unsigned char val;
> +
> +	val = si5351_reg_read(hwdata->drvdata, SI5351_CLK0_CTRL + hwdata->num);
> +	switch (val & SI5351_CLK_INPUT_MASK) {
> +	case SI5351_CLK_INPUT_MULTISYNTH_N:
> +		index = 0;
> +		break;
> +	case SI5351_CLK_INPUT_MULTISYNTH_0_4:
> +		index = 1;
> +		break;
> +	case SI5351_CLK_INPUT_XTAL:
> +		index = 2;
> +		break;
> +	case SI5351_CLK_INPUT_CLKIN:
> +		index = 3;
> +		break;
> +	}
> +
> +	return index;
> +}
> +
> +static int si5351_clkout_set_parent(struct clk_hw *hw, u8 index)
> +{
> +	struct si5351_hw_data *hwdata =
> +		container_of(hw, struct si5351_hw_data, hw);
> +	enum si5351_clkout_src parent = SI5351_CLKOUT_SRC_DEFAULT;
> +
> +	switch (index) {
> +	case 0:
> +		parent = SI5351_CLKOUT_SRC_MSYNTH_N;
> +		break;
> +	case 1:
> +		parent = SI5351_CLKOUT_SRC_MSYNTH_0_4;
> +		break;
> +	case 2:
> +		parent = SI5351_CLKOUT_SRC_XTAL;
> +		break;
> +	case 3:
> +		parent = SI5351_CLKOUT_SRC_CLKIN;
> +		break;
> +	}
> +
> +	return _si5351_clkout_reparent(hwdata->drvdata, hwdata->num, parent);
> +}
> +
> +static unsigned long si5351_clkout_recalc_rate(struct clk_hw *hw,
> +					       unsigned long parent_rate)
> +{
> +	struct si5351_hw_data *hwdata =
> +		container_of(hw, struct si5351_hw_data, hw);
> +	unsigned char reg;
> +	unsigned char rdiv;
> +
> +	if (hwdata->num > 5)
> +		reg = si5351_msynth_params_address(hwdata->num) + 2;
> +	else
> +		reg = SI5351_CLK6_7_OUTPUT_DIVIDER;
> +
> +	rdiv = si5351_reg_read(hwdata->drvdata, reg);
> +	if (hwdata->num == 6) {
> +		rdiv &= SI5351_OUTPUT_CLK6_DIV_MASK;
> +	} else {
> +		rdiv &= SI5351_OUTPUT_CLK_DIV_MASK;
> +		rdiv >>= SI5351_OUTPUT_CLK_DIV_SHIFT;
> +	}
> +
> +	return parent_rate >> rdiv;
> +}
> +
> +static long si5351_clkout_round_rate(struct clk_hw *hw, unsigned long rate,
> +				     unsigned long *parent_rate)
> +{
> +	struct si5351_hw_data *hwdata =
> +		container_of(hw, struct si5351_hw_data, hw);
> +	unsigned char rdiv;
> +
> +	/* clkout6/7 can only handle output freqencies < 150MHz */
> +	if (hwdata->num >= 6 && rate > SI5351_CLKOUT67_MAX_FREQ)
> +		rate = SI5351_CLKOUT67_MAX_FREQ;
> +
> +	/* clkout freqency is 8kHz - 160MHz */
> +	if (rate > SI5351_CLKOUT_MAX_FREQ)
> +		rate = SI5351_CLKOUT_MAX_FREQ;
> +	if (rate < SI5351_CLKOUT_MIN_FREQ)
> +		rate = SI5351_CLKOUT_MIN_FREQ;
> +
> +	/* request frequency if multisync master */
> +	if (__clk_get_flags(hwdata->hw.clk) & CLK_SET_RATE_PARENT) {
> +		/* use r divider for frequencies below 1MHz */
> +		rdiv = SI5351_OUTPUT_CLK_DIV_1;
> +		while (rate < SI5351_MULTISYNTH_MIN_FREQ &&
> +		       rdiv < SI5351_OUTPUT_CLK_DIV_128) {
> +			rdiv += 1;
> +			rate *= 2;
> +		}
> +		*parent_rate = rate;
> +	} else {
> +		unsigned long new_rate, new_err, err;
> +
> +		/* round to closed rdiv */
> +		rdiv = SI5351_OUTPUT_CLK_DIV_1;
> +		new_rate = *parent_rate;
> +		err = abs(new_rate - rate);
> +		do {
> +			new_rate >>= 1;
> +			new_err = abs(new_rate - rate);
> +			if (new_err > err || rdiv == SI5351_OUTPUT_CLK_DIV_128)
> +				break;
> +			rdiv++;
> +			err = new_err;
> +		} while (1);
> +	}
> +	rate = *parent_rate >> rdiv;
> +
> +	dev_dbg(&hwdata->drvdata->client->dev,
> +		"%s - %s: rdiv = %u, parent_rate = %lu, rate = %lu\n",
> +		__func__, __clk_get_name(hwdata->hw.clk), (1 << rdiv),
> +		*parent_rate, rate);
> +
> +	return rate;
> +}
> +
> +static int si5351_clkout_set_rate(struct clk_hw *hw, unsigned long rate,
> +				  unsigned long parent_rate)
> +{
> +	struct si5351_hw_data *hwdata =
> +		container_of(hw, struct si5351_hw_data, hw);
> +	unsigned long new_rate, new_err, err;
> +	unsigned char rdiv;
> +
> +	/* round to closed rdiv */
> +	rdiv = SI5351_OUTPUT_CLK_DIV_1;
> +	new_rate = parent_rate;
> +	err = abs(new_rate - rate);
> +	do {
> +		new_rate >>= 1;
> +		new_err = abs(new_rate - rate);
> +		if (new_err > err || rdiv == SI5351_OUTPUT_CLK_DIV_128)
> +			break;
> +		rdiv++;
> +		err = new_err;
> +	} while (1);
> +
> +	/* write output divider */
> +	switch (hwdata->num) {
> +	case 6:
> +		si5351_set_bits(hwdata->drvdata, SI5351_CLK6_7_OUTPUT_DIVIDER,
> +				SI5351_OUTPUT_CLK6_DIV_MASK, rdiv);
> +		break;
> +	case 7:
> +		si5351_set_bits(hwdata->drvdata, SI5351_CLK6_7_OUTPUT_DIVIDER,
> +				SI5351_OUTPUT_CLK_DIV_MASK,
> +				rdiv << SI5351_OUTPUT_CLK_DIV_SHIFT);
> +		break;
> +	default:
> +		si5351_set_bits(hwdata->drvdata,
> +				si5351_msynth_params_address(hwdata->num) + 2,
> +				SI5351_OUTPUT_CLK_DIV_MASK,
> +				rdiv << SI5351_OUTPUT_CLK_DIV_SHIFT);
> +	}
> +
> +	dev_dbg(&hwdata->drvdata->client->dev,
> +		"%s - %s: rdiv = %u, parent_rate = %lu, rate = %lu\n",
> +		__func__, __clk_get_name(hwdata->hw.clk), (1 << rdiv),
> +		parent_rate, rate);
> +
> +	return 0;
> +}
> +
> +static const struct clk_ops si5351_clkout_ops = {
> +	.prepare = si5351_clkout_prepare,
> +	.unprepare = si5351_clkout_unprepare,
> +	.set_parent = si5351_clkout_set_parent,
> +	.get_parent = si5351_clkout_get_parent,
> +	.recalc_rate = si5351_clkout_recalc_rate,
> +	.round_rate = si5351_clkout_round_rate,
> +	.set_rate = si5351_clkout_set_rate,
> +};
> +
> +/*
> + * Si5351 i2c probe and DT
> + */
> +#ifdef CONFIG_OF
> +static const struct of_device_id si5351_dt_ids[] = {
> +	{ .compatible = "silabs,si5351a", .data = (void *)SI5351_VARIANT_A, },
> +	{ .compatible = "silabs,si5351a-msop",
> +					 .data = (void *)SI5351_VARIANT_A3, },
> +	{ .compatible = "silabs,si5351b", .data = (void *)SI5351_VARIANT_B, },
> +	{ .compatible = "silabs,si5351c", .data = (void *)SI5351_VARIANT_C, },
> +	{ }
> +};
> +MODULE_DEVICE_TABLE(of, si5351_dt_ids);
> +
> +static int si5351_dt_parse(struct i2c_client *client)
> +{
> +	struct device_node *child, *np = client->dev.of_node;
> +	struct si5351_platform_data *pdata;
> +	const struct of_device_id *match;
> +	struct property *prop;
> +	const __be32 *p;
> +	int num = 0;
> +	u32 val;
> +
> +	if (np == NULL)
> +		return 0;
> +
> +	match = of_match_node(si5351_dt_ids, np);
> +	if (match == NULL)
> +		return -EINVAL;
> +
> +	pdata = devm_kzalloc(&client->dev, sizeof(*pdata), GFP_KERNEL);
> +	if (!pdata)
> +		return -ENOMEM;
> +
> +	pdata->variant = (enum si5351_variant)match->data;
> +	pdata->clk_xtal = of_clk_get(np, 0);
> +	if (!IS_ERR(pdata->clk_xtal))
> +		clk_put(pdata->clk_xtal);
> +	pdata->clk_clkin = of_clk_get(np, 1);
> +	if (!IS_ERR(pdata->clk_clkin))
> +		clk_put(pdata->clk_clkin);
> +
> +	/*
> +	 * property silabs,pll-source : <num src>, [<..>]
> +	 * allow to selectively set pll source
> +	 */
> +	of_property_for_each_u32(np, "silabs,pll-source", prop, p, num) {
> +		if (num >= 2) {
> +			dev_err(&client->dev,
> +				"invalid pll %d on pll-source prop\n", num);
> +			return -EINVAL;
> +		}
> +
> +		p = of_prop_next_u32(prop, p, &val);
> +		if (!p) {
> +			dev_err(&client->dev,
> +				"missing pll-source for pll %d\n", num);
> +			return -EINVAL;
> +		}
> +
> +		switch (val) {
> +		case 0:
> +			pdata->pll_src[num] = SI5351_PLL_SRC_XTAL;
> +			break;
> +		case 1:
> +			if (pdata->variant != SI5351_VARIANT_C) {
> +				dev_err(&client->dev,
> +					"invalid parent %d for pll %d\n",
> +					val, num);
> +				return -EINVAL;
> +			}
> +			pdata->pll_src[num] = SI5351_PLL_SRC_CLKIN;
> +			break;
> +		default:
> +			dev_err(&client->dev,
> +				 "invalid parent %d for pll %d\n", val, num);
> +			return -EINVAL;
> +		}
> +	}
> +
> +	/* per clkout properties */
> +	for_each_child_of_node(np, child) {
> +		if (of_property_read_u32(child, "reg", &num)) {
> +			dev_err(&client->dev, "missing reg property of %s\n",
> +				child->name);
> +			return -EINVAL;
> +		}
> +
> +		if (num >= 8 ||
> +		    (pdata->variant == SI5351_VARIANT_A3 && num >= 3)) {
> +			dev_err(&client->dev, "invalid clkout %d\n", num);
> +			return -EINVAL;
> +		}
> +
> +		if (!of_property_read_u32(child, "silabs,multisynth-source",
> +					  &val)) {
> +			switch (val) {
> +			case 0:
> +				pdata->clkout[num].multisynth_src =
> +					SI5351_MULTISYNTH_SRC_VCO0;
> +				break;
> +			case 1:
> +				pdata->clkout[num].multisynth_src =
> +					SI5351_MULTISYNTH_SRC_VCO1;
> +				break;
> +			default:
> +				dev_err(&client->dev,
> +					"invalid parent %d for multisynth %d\n",
> +					val, num);
> +				return -EINVAL;
> +			}
> +		}
> +
> +		if (!of_property_read_u32(child, "silabs,clock-source", &val)) {
> +			switch (val) {
> +			case 0:
> +				pdata->clkout[num].clkout_src =
> +					SI5351_CLKOUT_SRC_MSYNTH_N;
> +				break;
> +			case 1:
> +				pdata->clkout[num].clkout_src =
> +					SI5351_CLKOUT_SRC_MSYNTH_0_4;
> +				break;
> +			case 2:
> +				pdata->clkout[num].clkout_src =
> +					SI5351_CLKOUT_SRC_XTAL;
> +				break;
> +			case 3:
> +				if (pdata->variant != SI5351_VARIANT_C) {
> +					dev_err(&client->dev,
> +						"invalid parent %d for clkout %d\n",
> +						val, num);
> +					return -EINVAL;
> +				}
> +				pdata->clkout[num].clkout_src =
> +					SI5351_CLKOUT_SRC_CLKIN;
> +				break;
> +			default:
> +				dev_err(&client->dev,
> +					"invalid parent %d for clkout %d\n",
> +					val, num);
> +				return -EINVAL;
> +			}
> +		}
> +
> +		if (!of_property_read_u32(child, "silabs,drive-strength",
> +					  &val)) {
> +			switch (val) {
> +			case SI5351_DRIVE_2MA:
> +			case SI5351_DRIVE_4MA:
> +			case SI5351_DRIVE_6MA:
> +			case SI5351_DRIVE_8MA:
> +				pdata->clkout[num].drive = val;
> +				break;
> +			default:
> +				dev_err(&client->dev,
> +					"invalid drive strength %d for clkout %d\n",
> +					val, num);
> +				return -EINVAL;
> +			}
> +		}
> +
> +		if (!of_property_read_u32(child, "clock-frequency", &val))
> +			pdata->clkout[num].rate = val;
> +
> +		pdata->clkout[num].pll_master =
> +			of_property_read_bool(child, "silabs,pll-master");
> +	}
> +	client->dev.platform_data = pdata;
> +
> +	return 0;
> +}
> +#else
> +static int si5351_dt_parse(struct i2c_client *client)
> +{
> +	return 0;
> +}
> +#endif /* CONFIG_OF */
> +
> +static int si5351_i2c_probe(struct i2c_client *client,
> +			    const struct i2c_device_id *id)
> +{
> +	struct si5351_platform_data *pdata;
> +	struct si5351_driver_data *drvdata;
> +	struct clk_init_data init;
> +	struct clk *clk;
> +	const char *parent_names[4];
> +	u8 num_parents, num_clocks;
> +	int ret, n;
> +
> +	ret = si5351_dt_parse(client);
> +	if (ret)
> +		return ret;
> +
> +	pdata = client->dev.platform_data;
> +	if (!pdata)
> +		return -EINVAL;
> +
> +	drvdata = devm_kzalloc(&client->dev, sizeof(*drvdata), GFP_KERNEL);
> +	if (drvdata == NULL) {
> +		dev_err(&client->dev, "unable to allocate driver data\n");
> +		return -ENOMEM;
> +	}
> +
> +	i2c_set_clientdata(client, drvdata);
> +	drvdata->client = client;
> +	drvdata->variant = pdata->variant;
> +	drvdata->pxtal = pdata->clk_xtal;
> +	drvdata->pclkin = pdata->clk_clkin;
> +
> +	drvdata->regmap = devm_regmap_init_i2c(client, &si5351_regmap_config);
> +	if (IS_ERR(drvdata->regmap)) {
> +		dev_err(&client->dev, "failed to allocate register map\n");
> +		return PTR_ERR(drvdata->regmap);
> +	}
> +
> +	/* Disable interrupts */
> +	si5351_reg_write(drvdata, SI5351_INTERRUPT_MASK, 0xf0);
> +	/* Set disabled output drivers to drive low */
> +	si5351_reg_write(drvdata, SI5351_CLK3_0_DISABLE_STATE, 0x00);
> +	si5351_reg_write(drvdata, SI5351_CLK7_4_DISABLE_STATE, 0x00);
> +	/* Ensure pll select is on XTAL for Si5351A/B */
> +	if (drvdata->variant != SI5351_VARIANT_C)
> +		si5351_set_bits(drvdata, SI5351_PLL_INPUT_SOURCE,
> +				SI5351_PLLA_SOURCE | SI5351_PLLB_SOURCE, 0);
> +
> +	/* setup clock configuration */
> +	for (n = 0; n < 2; n++) {
> +		ret = _si5351_pll_reparent(drvdata, n, pdata->pll_src[n]);
> +		if (ret) {
> +			dev_err(&client->dev,
> +				"failed to reparent pll %d to %d\n",
> +				n, pdata->pll_src[n]);
> +			return ret;
> +		}
> +	}
> +
> +	for (n = 0; n < 8; n++) {
> +		ret = _si5351_msynth_reparent(drvdata, n,
> +					      pdata->clkout[n].multisynth_src);
> +		if (ret) {
> +			dev_err(&client->dev,
> +				"failed to reparent multisynth %d to %d\n",
> +				n, pdata->clkout[n].multisynth_src);
> +			return ret;
> +		}
> +
> +		ret = _si5351_clkout_reparent(drvdata, n,
> +					      pdata->clkout[n].clkout_src);
> +		if (ret) {
> +			dev_err(&client->dev,
> +				"failed to reparent clkout %d to %d\n",
> +				n, pdata->clkout[n].clkout_src);
> +			return ret;
> +		}
> +
> +		ret = _si5351_clkout_set_drive_strength(drvdata, n,
> +							pdata->clkout[n].drive);
> +		if (ret) {
> +			dev_err(&client->dev,
> +				"failed set drive strength of clkout%d to %d\n",
> +				n, pdata->clkout[n].drive);
> +			return ret;
> +		}
> +	}
> +
> +	/* register xtal input clock gate */
> +	memset(&init, 0, sizeof(init));
> +	init.name = si5351_input_names[0];
> +	init.ops = &si5351_xtal_ops;
> +	init.flags = 0;
> +	if (!IS_ERR(drvdata->pxtal)) {
> +		drvdata->pxtal_name = __clk_get_name(drvdata->pxtal);
> +		init.parent_names = &drvdata->pxtal_name;
> +		init.num_parents = 1;
> +	}
> +	drvdata->xtal.init = &init;
> +	clk = devm_clk_register(&client->dev, &drvdata->xtal);
> +	if (IS_ERR(clk)) {
> +		dev_err(&client->dev, "unable to register %s\n", init.name);
> +		return PTR_ERR(clk);
> +	}
> +
> +	/* register clkin input clock gate */
> +	if (drvdata->variant == SI5351_VARIANT_C) {
> +		memset(&init, 0, sizeof(init));
> +		init.name = si5351_input_names[1];
> +		init.ops = &si5351_clkin_ops;
> +		if (!IS_ERR(drvdata->pclkin)) {
> +			drvdata->pclkin_name = __clk_get_name(drvdata->pclkin);
> +			init.parent_names = &drvdata->pclkin_name;
> +			init.num_parents = 1;
> +		}
> +		drvdata->clkin.init = &init;
> +		clk = devm_clk_register(&client->dev, &drvdata->clkin);
> +		if (IS_ERR(clk)) {
> +			dev_err(&client->dev, "unable to register %s\n",
> +				init.name);
> +			return PTR_ERR(clk);
> +		}
> +	}
> +
> +	/* Si5351C allows to mux either xtal or clkin to PLL input */
> +	num_parents = (drvdata->variant == SI5351_VARIANT_C) ? 2 : 1;
> +	parent_names[0] = si5351_input_names[0];
> +	parent_names[1] = si5351_input_names[1];
> +
> +	/* register PLLA */
> +	drvdata->pll[0].num = 0;
> +	drvdata->pll[0].drvdata = drvdata;
> +	drvdata->pll[0].hw.init = &init;
> +	memset(&init, 0, sizeof(init));
> +	init.name = si5351_pll_names[0];
> +	init.ops = &si5351_pll_ops;
> +	init.flags = 0;
> +	init.parent_names = parent_names;
> +	init.num_parents = num_parents;
> +	clk = devm_clk_register(&client->dev, &drvdata->pll[0].hw);
> +	if (IS_ERR(clk)) {
> +		dev_err(&client->dev, "unable to register %s\n", init.name);
> +		return -EINVAL;
> +	}
> +
> +	/* register PLLB or VXCO (Si5351B) */
> +	drvdata->pll[1].num = 1;
> +	drvdata->pll[1].drvdata = drvdata;
> +	drvdata->pll[1].hw.init = &init;
> +	memset(&init, 0, sizeof(init));
> +	if (drvdata->variant == SI5351_VARIANT_B) {
> +		init.name = si5351_pll_names[2];
> +		init.ops = &si5351_vxco_ops;
> +		init.flags = CLK_IS_ROOT;
> +		init.parent_names = NULL;
> +		init.num_parents = 0;
> +	} else {
> +		init.name = si5351_pll_names[1];
> +		init.ops = &si5351_pll_ops;
> +		init.flags = 0;
> +		init.parent_names = parent_names;
> +		init.num_parents = num_parents;
> +	}
> +	clk = devm_clk_register(&client->dev, &drvdata->pll[1].hw);
> +	if (IS_ERR(clk)) {
> +		dev_err(&client->dev, "unable to register %s\n", init.name);
> +		return -EINVAL;
> +	}
> +
> +	/* register clk multisync and clk out divider */
> +	num_clocks = (drvdata->variant == SI5351_VARIANT_A3) ? 3 : 8;
> +	parent_names[0] = si5351_pll_names[0];
> +	if (drvdata->variant == SI5351_VARIANT_B)
> +		parent_names[1] = si5351_pll_names[2];
> +	else
> +		parent_names[1] = si5351_pll_names[1];
> +
> +	drvdata->msynth = devm_kzalloc(&client->dev, num_clocks *
> +				       sizeof(*drvdata->msynth), GFP_KERNEL);
> +	drvdata->clkout = devm_kzalloc(&client->dev, num_clocks *
> +				       sizeof(*drvdata->clkout), GFP_KERNEL);
> +
> +	drvdata->onecell.clk_num = num_clocks;
> +	drvdata->onecell.clks = devm_kzalloc(&client->dev,
> +		num_clocks * sizeof(*drvdata->onecell.clks), GFP_KERNEL);
> +
> +	if (WARN_ON(!drvdata->msynth || !drvdata->clkout ||
> +		    !drvdata->onecell.clks))
> +		return -ENOMEM;
> +
> +	for (n = 0; n < num_clocks; n++) {
> +		drvdata->msynth[n].num = n;
> +		drvdata->msynth[n].drvdata = drvdata;
> +		drvdata->msynth[n].hw.init = &init;
> +		memset(&init, 0, sizeof(init));
> +		init.name = si5351_msynth_names[n];
> +		init.ops = &si5351_msynth_ops;
> +		init.flags = 0;
> +		if (pdata->clkout[n].pll_master)
> +			init.flags |= CLK_SET_RATE_PARENT;
> +		init.parent_names = parent_names;
> +		init.num_parents = 2;
> +		clk = devm_clk_register(&client->dev, &drvdata->msynth[n].hw);
> +		if (IS_ERR(clk)) {
> +			dev_err(&client->dev, "unable to register %s\n",
> +				init.name);
> +			return -EINVAL;
> +		}
> +	}
> +
> +	num_parents = (drvdata->variant == SI5351_VARIANT_C) ? 4 : 3;
> +	parent_names[2] = si5351_input_names[0];
> +	parent_names[3] = si5351_input_names[1];
> +	for (n = 0; n < num_clocks; n++) {
> +		parent_names[0] = si5351_msynth_names[n];
> +		parent_names[1] = (n < 4) ? si5351_msynth_names[0] :
> +			si5351_msynth_names[4];
> +
> +		drvdata->clkout[n].num = n;
> +		drvdata->clkout[n].drvdata = drvdata;
> +		drvdata->clkout[n].hw.init = &init;
> +		memset(&init, 0, sizeof(init));
> +		init.name = si5351_clkout_names[n];
> +		init.ops = &si5351_clkout_ops;
> +		init.flags = 0;
> +		if (pdata->clkout[n].clkout_src == SI5351_CLKOUT_SRC_MSYNTH_N)
> +			init.flags |= CLK_SET_RATE_PARENT;
> +		init.parent_names = parent_names;
> +		init.num_parents = num_parents;
> +		clk = devm_clk_register(&client->dev, &drvdata->clkout[n].hw);
> +		if (IS_ERR(clk)) {
> +			dev_err(&client->dev, "unable to register %s\n",
> +				init.name);
> +			return -EINVAL;
> +		}
> +		drvdata->onecell.clks[n] = clk;
> +	}
> +
> +	ret = of_clk_add_provider(client->dev.of_node, of_clk_src_onecell_get,
> +				  &drvdata->onecell);
> +	if (ret) {
> +		dev_err(&client->dev, "unable to add clk provider\n");
> +		return ret;
> +	}
> +
> +	return 0;
> +}
> +
> +static const struct i2c_device_id si5351_i2c_ids[] = {
> +	{ "silabs,si5351", 0 },
> +	{ }
> +};
> +MODULE_DEVICE_TABLE(i2c, si5351_i2c_ids);
> +
> +static struct i2c_driver si5351_driver = {
> +	.driver = {
> +		.name = "si5351",
> +		.of_match_table = of_match_ptr(si5351_dt_ids),
> +	},
> +	.probe = si5351_i2c_probe,
> +	.id_table = si5351_i2c_ids,
> +};
> +module_i2c_driver(si5351_driver);
> +
> +MODULE_AUTHOR("Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com");
> +MODULE_DESCRIPTION("Silicon Labs Si5351A/B/C clock generator driver");
> +MODULE_LICENSE("GPL");
> diff --git a/drivers/clk/clk-si5351.h b/drivers/clk/clk-si5351.h
> new file mode 100644
> index 0000000..af41b50
> --- /dev/null
> +++ b/drivers/clk/clk-si5351.h
> @@ -0,0 +1,155 @@
> +/*
> + * clk-si5351.h: Silicon Laboratories Si5351A/B/C I2C Clock Generator
> + *
> + * Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
> + * Rabeeh Khoury <rabeeh at solid-run.com>
> + *
> + * 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.
> + */
> +
> +#ifndef _CLK_SI5351_H_
> +#define _CLK_SI5351_H_
> +
> +#define SI5351_BUS_BASE_ADDR			0x60
> +
> +#define SI5351_PLL_VCO_MIN			600000000
> +#define SI5351_PLL_VCO_MAX			900000000
> +#define SI5351_MULTISYNTH_MIN_FREQ		1000000
> +#define SI5351_MULTISYNTH_DIVBY4_FREQ		150000000
> +#define SI5351_MULTISYNTH_MAX_FREQ		160000000
> +#define SI5351_MULTISYNTH67_MAX_FREQ		SI5351_MULTISYNTH_DIVBY4_FREQ
> +#define SI5351_CLKOUT_MIN_FREQ			8000
> +#define SI5351_CLKOUT_MAX_FREQ			SI5351_MULTISYNTH_MAX_FREQ
> +#define SI5351_CLKOUT67_MAX_FREQ		SI5351_MULTISYNTH67_MAX_FREQ
> +
> +#define SI5351_PLL_A_MIN			15
> +#define SI5351_PLL_A_MAX			90
> +#define SI5351_PLL_B_MAX			(SI5351_PLL_C_MAX-1)
> +#define SI5351_PLL_C_MAX			1048575
> +#define SI5351_MULTISYNTH_A_MIN			6
> +#define SI5351_MULTISYNTH_A_MAX			1800
> +#define SI5351_MULTISYNTH67_A_MAX		254
> +#define SI5351_MULTISYNTH_B_MAX			(SI5351_MULTISYNTH_C_MAX-1)
> +#define SI5351_MULTISYNTH_C_MAX			1048575
> +#define SI5351_MULTISYNTH_P1_MAX		((1<<18)-1)
> +#define SI5351_MULTISYNTH_P2_MAX		((1<<20)-1)
> +#define SI5351_MULTISYNTH_P3_MAX		((1<<20)-1)
> +
> +#define SI5351_DEVICE_STATUS			0
> +#define SI5351_INTERRUPT_STATUS			1
> +#define SI5351_INTERRUPT_MASK			2
> +#define  SI5351_STATUS_SYS_INIT			(1<<7)
> +#define  SI5351_STATUS_LOL_B			(1<<6)
> +#define  SI5351_STATUS_LOL_A			(1<<5)
> +#define  SI5351_STATUS_LOS			(1<<4)
> +#define SI5351_OUTPUT_ENABLE_CTRL		3
> +#define SI5351_OEB_PIN_ENABLE_CTRL		9
> +#define SI5351_PLL_INPUT_SOURCE			15
> +#define  SI5351_CLKIN_DIV_MASK			(3<<6)
> +#define  SI5351_CLKIN_DIV_1			(0<<6)
> +#define  SI5351_CLKIN_DIV_2			(1<<6)
> +#define  SI5351_CLKIN_DIV_4			(2<<6)
> +#define  SI5351_CLKIN_DIV_8			(3<<6)
> +#define  SI5351_PLLB_SOURCE			(1<<3)
> +#define  SI5351_PLLA_SOURCE			(1<<2)
> +
> +#define SI5351_CLK0_CTRL			16
> +#define SI5351_CLK1_CTRL			17
> +#define SI5351_CLK2_CTRL			18
> +#define SI5351_CLK3_CTRL			19
> +#define SI5351_CLK4_CTRL			20
> +#define SI5351_CLK5_CTRL			21
> +#define SI5351_CLK6_CTRL			22
> +#define SI5351_CLK7_CTRL			23
> +#define  SI5351_CLK_POWERDOWN			(1<<7)
> +#define  SI5351_CLK_INTEGER_MODE		(1<<6)
> +#define  SI5351_CLK_PLL_SELECT			(1<<5)
> +#define  SI5351_CLK_INVERT			(1<<4)
> +#define  SI5351_CLK_INPUT_MASK			(3<<2)
> +#define  SI5351_CLK_INPUT_XTAL			(0<<2)
> +#define  SI5351_CLK_INPUT_CLKIN			(1<<2)
> +#define  SI5351_CLK_INPUT_MULTISYNTH_0_4	(2<<2)
> +#define  SI5351_CLK_INPUT_MULTISYNTH_N		(3<<2)
> +#define  SI5351_CLK_DRIVE_STRENGTH_MASK		(3<<0)
> +#define  SI5351_CLK_DRIVE_STRENGTH_2MA		(0<<0)
> +#define  SI5351_CLK_DRIVE_STRENGTH_4MA		(1<<0)
> +#define  SI5351_CLK_DRIVE_STRENGTH_6MA		(2<<0)
> +#define  SI5351_CLK_DRIVE_STRENGTH_8MA		(3<<0)
> +
> +#define SI5351_CLK3_0_DISABLE_STATE		24
> +#define SI5351_CLK7_4_DISABLE_STATE		25
> +#define  SI5351_CLK_DISABLE_STATE_LOW		0
> +#define  SI5351_CLK_DISABLE_STATE_HIGH		1
> +#define  SI5351_CLK_DISABLE_STATE_FLOAT		2
> +#define  SI5351_CLK_DISABLE_STATE_NEVER		3
> +
> +#define SI5351_PARAMETERS_LENGTH		8
> +#define SI5351_PLLA_PARAMETERS			26
> +#define SI5351_PLLB_PARAMETERS			34
> +#define SI5351_CLK0_PARAMETERS			42
> +#define SI5351_CLK1_PARAMETERS			50
> +#define SI5351_CLK2_PARAMETERS			58
> +#define SI5351_CLK3_PARAMETERS			66
> +#define SI5351_CLK4_PARAMETERS			74
> +#define SI5351_CLK5_PARAMETERS			82
> +#define SI5351_CLK6_PARAMETERS			90
> +#define SI5351_CLK7_PARAMETERS			91
> +#define SI5351_CLK6_7_OUTPUT_DIVIDER		92
> +#define  SI5351_OUTPUT_CLK_DIV_MASK		(7 << 4)
> +#define  SI5351_OUTPUT_CLK6_DIV_MASK		(7 << 0)
> +#define  SI5351_OUTPUT_CLK_DIV_SHIFT		4
> +#define  SI5351_OUTPUT_CLK_DIV6_SHIFT		0
> +#define  SI5351_OUTPUT_CLK_DIV_1		0
> +#define  SI5351_OUTPUT_CLK_DIV_2		1
> +#define  SI5351_OUTPUT_CLK_DIV_4		2
> +#define  SI5351_OUTPUT_CLK_DIV_8		3
> +#define  SI5351_OUTPUT_CLK_DIV_16		4
> +#define  SI5351_OUTPUT_CLK_DIV_32		5
> +#define  SI5351_OUTPUT_CLK_DIV_64		6
> +#define  SI5351_OUTPUT_CLK_DIV_128		7
> +#define  SI5351_OUTPUT_CLK_DIVBY4		(3<<2)
> +
> +#define SI5351_SSC_PARAM0			149
> +#define SI5351_SSC_PARAM1			150
> +#define SI5351_SSC_PARAM2			151
> +#define SI5351_SSC_PARAM3			152
> +#define SI5351_SSC_PARAM4			153
> +#define SI5351_SSC_PARAM5			154
> +#define SI5351_SSC_PARAM6			155
> +#define SI5351_SSC_PARAM7			156
> +#define SI5351_SSC_PARAM8			157
> +#define SI5351_SSC_PARAM9			158
> +#define SI5351_SSC_PARAM10			159
> +#define SI5351_SSC_PARAM11			160
> +#define SI5351_SSC_PARAM12			161
> +
> +#define SI5351_VXCO_PARAMETERS_LOW		162
> +#define SI5351_VXCO_PARAMETERS_MID		163
> +#define SI5351_VXCO_PARAMETERS_HIGH		164
> +
> +#define SI5351_CLK0_PHASE_OFFSET		165
> +#define SI5351_CLK1_PHASE_OFFSET		166
> +#define SI5351_CLK2_PHASE_OFFSET		167
> +#define SI5351_CLK3_PHASE_OFFSET		168
> +#define SI5351_CLK4_PHASE_OFFSET		169
> +#define SI5351_CLK5_PHASE_OFFSET		170
> +
> +#define SI5351_PLL_RESET			177
> +#define  SI5351_PLL_RESET_B			(1<<7)
> +#define  SI5351_PLL_RESET_A			(1<<5)
> +
> +#define SI5351_CRYSTAL_LOAD			183
> +#define  SI5351_CRYSTAL_LOAD_MASK		(3<<6)
> +#define  SI5351_CRYSTAL_LOAD_6PF		(1<<6)
> +#define  SI5351_CRYSTAL_LOAD_8PF		(2<<6)
> +#define  SI5351_CRYSTAL_LOAD_10PF		(3<<6)
> +
> +#define SI5351_FANOUT_ENABLE			187
> +#define  SI5351_CLKIN_ENABLE			(1<<7)
> +#define  SI5351_XTAL_ENABLE			(1<<6)
> +#define  SI5351_MULTISYNTH_ENABLE		(1<<4)
> +
> +#endif
> diff --git a/include/linux/platform_data/si5351.h b/include/linux/platform_data/si5351.h
> new file mode 100644
> index 0000000..92dabca
> --- /dev/null
> +++ b/include/linux/platform_data/si5351.h
> @@ -0,0 +1,114 @@
> +/*
> + * Si5351A/B/C programmable clock generator platform_data.
> + */
> +
> +#ifndef __LINUX_PLATFORM_DATA_SI5351_H__
> +#define __LINUX_PLATFORM_DATA_SI5351_H__
> +
> +struct clk;
> +
> +/**
> + * enum si5351_variant - SiLabs Si5351 chip variant
> + * @SI5351_VARIANT_A: Si5351A (8 output clocks, XTAL input)
> + * @SI5351_VARIANT_A3: Si5351A MSOP10 (3 output clocks, XTAL input)
> + * @SI5351_VARIANT_B: Si5351B (8 output clocks, XTAL/VXCO input)
> + * @SI5351_VARIANT_C: Si5351C (8 output clocks, XTAL/CLKIN input)
> + */
> +enum si5351_variant {
> +	SI5351_VARIANT_A = 1,
> +	SI5351_VARIANT_A3 = 2,
> +	SI5351_VARIANT_B = 3,
> +	SI5351_VARIANT_C = 4,
> +};
> +
> +/**
> + * enum si5351_pll_src - Si5351 pll clock source
> + * @SI5351_PLL_SRC_DEFAULT: default, do not change eeprom config
> + * @SI5351_PLL_SRC_XTAL: pll source clock is XTAL input
> + * @SI5351_PLL_SRC_CLKIN: pll source clock is CLKIN input (Si5351C only)
> + */
> +enum si5351_pll_src {
> +	SI5351_PLL_SRC_DEFAULT = 0,
> +	SI5351_PLL_SRC_XTAL = 1,
> +	SI5351_PLL_SRC_CLKIN = 2,
> +};
> +
> +/**
> + * enum si5351_multisynth_src - Si5351 multisynth clock source
> + * @SI5351_MULTISYNTH_SRC_DEFAULT: default, do not change eeprom config
> + * @SI5351_MULTISYNTH_SRC_VCO0: multisynth source clock is VCO0
> + * @SI5351_MULTISYNTH_SRC_VCO1: multisynth source clock is VCO1/VXCO
> + */
> +enum si5351_multisynth_src {
> +	SI5351_MULTISYNTH_SRC_DEFAULT = 0,
> +	SI5351_MULTISYNTH_SRC_VCO0 = 1,
> +	SI5351_MULTISYNTH_SRC_VCO1 = 2,
> +};
> +
> +/**
> + * enum si5351_clkout_src - Si5351 clock output clock source
> + * @SI5351_CLKOUT_SRC_DEFAULT: default, do not change eeprom config
> + * @SI5351_CLKOUT_SRC_MSYNTH_N: clkout N source clock is multisynth N
> + * @SI5351_CLKOUT_SRC_MSYNTH_0_4: clkout N source clock is multisynth 0 (N<4)
> + *                                or 4 (N>=4)
> + * @SI5351_CLKOUT_SRC_XTAL: clkout N source clock is XTAL
> + * @SI5351_CLKOUT_SRC_CLKIN: clkout N source clock is CLKIN (Si5351C only)
> + */
> +enum si5351_clkout_src {
> +	SI5351_CLKOUT_SRC_DEFAULT = 0,
> +	SI5351_CLKOUT_SRC_MSYNTH_N = 1,
> +	SI5351_CLKOUT_SRC_MSYNTH_0_4 = 2,
> +	SI5351_CLKOUT_SRC_XTAL = 3,
> +	SI5351_CLKOUT_SRC_CLKIN = 4,
> +};
> +
> +/**
> + * enum si5351_drive_strength - Si5351 clock output drive strength
> + * @SI5351_DRIVE_DEFAULT: default, do not change eeprom config
> + * @SI5351_DRIVE_2MA: 2mA clock output drive strength
> + * @SI5351_DRIVE_4MA: 4mA clock output drive strength
> + * @SI5351_DRIVE_6MA: 6mA clock output drive strength
> + * @SI5351_DRIVE_8MA: 8mA clock output drive strength
> + */
> +enum si5351_drive_strength {
> +	SI5351_DRIVE_DEFAULT = 0,
> +	SI5351_DRIVE_2MA = 2,
> +	SI5351_DRIVE_4MA = 4,
> +	SI5351_DRIVE_6MA = 6,
> +	SI5351_DRIVE_8MA = 8,
> +};
> +
> +/**
> + * struct si5351_clkout_config - Si5351 clock output configuration
> + * @clkout: clkout number
> + * @multisynth_src: multisynth source clock
> + * @clkout_src: clkout source clock
> + * @pll_master: if true, clkout can also change pll rate
> + * @drive: output drive strength
> + * @rate: initial clkout rate, or default if 0
> + */
> +struct si5351_clkout_config {
> +	enum si5351_multisynth_src multisynth_src;
> +	enum si5351_clkout_src clkout_src;
> +	enum si5351_drive_strength drive;
> +	bool pll_master;
> +	unsigned long rate;
> +};
> +
> +/**
> + * struct si5351_platform_data - Platform data for the Si5351 clock driver
> + * @variant: Si5351 chip variant
> + * @clk_xtal: xtal input clock
> + * @clk_clkin: clkin input clock
> + * @pll_src: array of pll source clock setting
> + * @clkout: array of clkout configuration
> + */
> +struct si5351_platform_data {
> +	enum si5351_variant variant;
> +	struct clk *clk_xtal;
> +	struct clk *clk_clkin;
> +	enum si5351_pll_src pll_src[2];
> +	struct si5351_clkout_config clkout[8];
> +};
> +
> +#endif
> -- 
> 1.7.10.4
> 
> 


From linus.walleij at linaro.org  Wed Apr 10 15:34:40 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Wed, 10 Apr 2013 21:34:40 +0200
Subject: [PATCH 2/5] gpio/omap: remove extra context restores in
 *_runtime_resume()
In-Reply-To: <1365106576-31816-3-git-send-email-jon-hunter@ti.com>
References: <1365106576-31816-1-git-send-email-jon-hunter@ti.com>
 <1365106576-31816-3-git-send-email-jon-hunter@ti.com>
Message-ID: <CACRpkdaR0tL=2uvr+SP4uKW-BPmAHm=mL3rkaD79ELyPhDF1ag@mail.gmail.com>

On Thu, Apr 4, 2013 at 10:16 PM, Jon Hunter <jon-hunter at ti.com> wrote:

> From: Tarun Kanti DebBarma <tarun.kanti at ti.com>
>
> 68942edb09f69b6e09522d1d346665eb3aadde49 (gpio/omap: fix wakeups
> on level-triggered GPIOs) already restores the fallingdetect and
> risingdetect contexts in *_runtime_resume(). These registers were
> modified in *_runtime_suspend() to include even those configured
> as level-triggered since only edge-triggered gpios can generate
> wakeup events. Therefore, the old context restores of the same
> registers present later in the code is not needed any more.
> Remove them.
>
> Signed-off-by: Tarun Kanti DebBarma <tarun.kanti at ti.com>
> Signed-off-by: Jon Hunter <jon-hunter at ti.com>

Patch applied unless somebody complains.

Yours,
Linus Walleij


From linus.walleij at linaro.org  Wed Apr 10 15:37:02 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Wed, 10 Apr 2013 21:37:02 +0200
Subject: [PATCH 3/5] gpio/omap: optimise interrupt service routine
In-Reply-To: <1365106576-31816-4-git-send-email-jon-hunter@ti.com>
References: <1365106576-31816-1-git-send-email-jon-hunter@ti.com>
 <1365106576-31816-4-git-send-email-jon-hunter@ti.com>
Message-ID: <CACRpkdZ46vq6GOtS31DYSVZj44GawxT-PabqRr=0nmam6kBsTQ@mail.gmail.com>

On Thu, Apr 4, 2013 at 10:16 PM, Jon Hunter <jon-hunter at ti.com> wrote:

> The OMAP GPIO interrupt service routine is checking each bit in the
> GPIO interrupt status register to see which bits are set. It is not
> efficient to check every bit especially if only a few bits are set.
> Therefore, instead of checking every bit use the __ffs() function,
> which returns the location of the first set bit, to find all the set
> bits.
>
> This optimisation was suggested-by and developed in collaboration
> with Felipe Balbi.
>
> Cc: Felipe Balbi <balbi at ti.com>
>
> Signed-off-by: Jon Hunter <jon-hunter at ti.com>

Patch applied with Felipe's Reviewed-by tag.

Thanks,
Linus Walleij


From linus.walleij at linaro.org  Wed Apr 10 15:39:40 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Wed, 10 Apr 2013 21:39:40 +0200
Subject: [PATCH 4/5] gpio/omap: force restore if context loss is not
 detectable
In-Reply-To: <1365106576-31816-5-git-send-email-jon-hunter@ti.com>
References: <1365106576-31816-1-git-send-email-jon-hunter@ti.com>
 <1365106576-31816-5-git-send-email-jon-hunter@ti.com>
Message-ID: <CACRpkdbeABuFXr0Gt6gRto3Pmo0m88AFn_xKJq14VonGg7Doww@mail.gmail.com>

On Thu, Apr 4, 2013 at 10:16 PM, Jon Hunter <jon-hunter at ti.com> wrote:

> When booting with device-tree the function pointer for detecting context
> loss is not populated. Ideally, the pm_runtime framework should be
> enhanced to allow a means for reporting context/state loss and we could
> avoid populating such function pointers altogether. In the interim until
> a generic non-device specific solution is in place, force a restore of
> the gpio bank when enabling the gpio controller.
>
> Adds a new device-tree property for the OMAP GPIO controller to indicate
> if the GPIO controller is located in a power-domain that never loses
> power and hence will always maintain its logic state.
>
> Signed-off-by: Jon Hunter <jon-hunter at ti.com>

In this case it'd be really helpful to get an ACK from somebody else.
I have no clue whether this thing is doing what it should, and if
you were the maintainer I'd apply it but now I'd like to hear from
Kevin or Santosh first...

Yours,
Linus Walleij


From paul at pwsan.com  Wed Apr 10 15:41:38 2013
From: paul at pwsan.com (Paul Walmsley)
Date: Wed, 10 Apr 2013 19:41:38 +0000 (UTC)
Subject: [PATCH v2] ARM: OMAP4: hwmod data: make 'ocp2scp_usb_phy_phy_48m"
 as the main clock
In-Reply-To: <alpine.DEB.2.00.1304092058450.26840@utopia.booyaka.com>
References: <1365496101-7829-1-git-send-email-kishon@ti.com>
 <alpine.DEB.2.00.1304092058450.26840@utopia.booyaka.com>
Message-ID: <alpine.DEB.2.00.1304101935450.25123@utopia.booyaka.com>

From: Kishon Vijay Abraham I <kishon at ti.com>

Commit 92702df3570e ("ARM: OMAP4: PM: fix PM regression introduced by recent
clock cleanup") makes the 'ocp2scp_usb_phy_phy_48m' as optional
functional clock causing regression in MUSB. But this 48MHz clock is a
mandatory clock for usb phy attached to ocp2scp and hence made as the main
clock for ocp2scp.

Cc: Keerthy <j-keerthy at ti.com>
Cc: Beno?t Cousson <b-cousson at ti.com>
Cc: Paul Walmsley <paul at pwsan.com>
Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
[paul at pwsan.com: add comment to the hwmod data to try to prevent any
 future mistakes here]
Signed-off-by: Paul Walmsley <paul at pwsan.com>
---

Nothing further received from Kishon per the request:

http://marc.info/?l=linux-omap&m=136554118302342&w=2

Since the deadline for v3.9-rc fixes is quite close, have added the 
comment myself, and have confirmed that this patch does not cause 
additional PM regressions on 4460 Panda-ES in the tests here.

 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |   18 +++++++++++-------
 1 file changed, 11 insertions(+), 7 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 9e05765..eaba9dc 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -2714,16 +2714,22 @@ static struct omap_ocp2scp_dev ocp2scp_dev_attr[] = {
 	{ }
 };
 
-static struct omap_hwmod_opt_clk ocp2scp_usb_phy_opt_clks[] = {
-	{ .role = "48mhz", .clk = "ocp2scp_usb_phy_phy_48m" },
-};
-
 /* ocp2scp_usb_phy */
 static struct omap_hwmod omap44xx_ocp2scp_usb_phy_hwmod = {
 	.name		= "ocp2scp_usb_phy",
 	.class		= &omap44xx_ocp2scp_hwmod_class,
 	.clkdm_name	= "l3_init_clkdm",
-	.main_clk	= "func_48m_fclk",
+	/*
+	 * ocp2scp_usb_phy_phy_48m is provided by the OMAP4 PRCM IP
+	 * block as an "optional clock," and normally should never be
+	 * specified as the main_clk for an OMAP IP block.  However it
+	 * turns out that this clock is actually the main clock for
+	 * the ocp2scp_usb_phy IP block:
+	 * http://lists.infradead.org/pipermail/linux-arm-kernel/2012-September/119943.html
+	 * So listing ocp2scp_usb_phy_phy_48m as a main_clk here seems
+	 * to be the best workaround.
+	 */
+	.main_clk	= "ocp2scp_usb_phy_phy_48m",
 	.prcm = {
 		.omap4 = {
 			.clkctrl_offs = OMAP4_CM_L3INIT_USBPHYOCP2SCP_CLKCTRL_OFFSET,
@@ -2732,8 +2738,6 @@ static struct omap_hwmod omap44xx_ocp2scp_usb_phy_hwmod = {
 		},
 	},
 	.dev_attr	= ocp2scp_dev_attr,
-	.opt_clks	= ocp2scp_usb_phy_opt_clks,
-	.opt_clks_cnt	= ARRAY_SIZE(ocp2scp_usb_phy_opt_clks),
 };
 
 /*
-- 
1.7.10.4

From jon-hunter at ti.com  Wed Apr 10 15:41:58 2013
From: jon-hunter at ti.com (Jon Hunter)
Date: Wed, 10 Apr 2013 14:41:58 -0500
Subject: [PATCH 4/5] gpio/omap: force restore if context loss is not
 detectable
In-Reply-To: <CACRpkdbeABuFXr0Gt6gRto3Pmo0m88AFn_xKJq14VonGg7Doww@mail.gmail.com>
References: <1365106576-31816-1-git-send-email-jon-hunter@ti.com>
 <1365106576-31816-5-git-send-email-jon-hunter@ti.com>
 <CACRpkdbeABuFXr0Gt6gRto3Pmo0m88AFn_xKJq14VonGg7Doww@mail.gmail.com>
Message-ID: <5165C086.5010105@ti.com>


On 04/10/2013 02:39 PM, Linus Walleij wrote:
> On Thu, Apr 4, 2013 at 10:16 PM, Jon Hunter <jon-hunter at ti.com> wrote:
> 
>> When booting with device-tree the function pointer for detecting context
>> loss is not populated. Ideally, the pm_runtime framework should be
>> enhanced to allow a means for reporting context/state loss and we could
>> avoid populating such function pointers altogether. In the interim until
>> a generic non-device specific solution is in place, force a restore of
>> the gpio bank when enabling the gpio controller.
>>
>> Adds a new device-tree property for the OMAP GPIO controller to indicate
>> if the GPIO controller is located in a power-domain that never loses
>> power and hence will always maintain its logic state.
>>
>> Signed-off-by: Jon Hunter <jon-hunter at ti.com>
> 
> In this case it'd be really helpful to get an ACK from somebody else.
> I have no clue whether this thing is doing what it should, and if
> you were the maintainer I'd apply it but now I'd like to hear from
> Kevin or Santosh first...

Santosh gave the his ACK for 1-4 (see 0/5) and Kevin added his
reviewed-by for 1-4 (again see 0/5).

Cheers
Jon


From paul at pwsan.com  Wed Apr 10 15:43:25 2013
From: paul at pwsan.com (Paul Walmsley)
Date: Wed, 10 Apr 2013 19:43:25 +0000 (UTC)
Subject: [PATCH v2] ARM: OMAP4: hwmod data: make 'ocp2scp_usb_phy_phy_48m"
 as the main clock (fwd)
Message-ID: <alpine.DEB.2.00.1304101941550.25123@utopia.booyaka.com>


Hi Tony,

could you send this one upstream for v3.9-rc fixes?  Should prevent 
a MUSB regression in v3.9, mostly due to my own incompetence.


- Paul

---------- Forwarded message ----------
Date: Wed, 10 Apr 2013 19:41:38 +0000 (UTC)
From: Paul Walmsley <paul at pwsan.com>
To: linux-omap at vger.kernel.org, linux-arm-kernel at lists.infradead.org
Cc: Kishon Vijay Abraham I <kishon at ti.com>, rnayak at ti.com, b-cousson at ti.com,
    tony at atomide.com, linux at arm.linux.org.uk, linux-kernel at vger.kernel.org,
    Keerthy <j-keerthy at ti.com>
Subject: [PATCH v2] ARM: OMAP4: hwmod data: make
    'ocp2scp_usb_phy_phy_48m" as the main clock

From: Kishon Vijay Abraham I <kishon at ti.com>

Commit 92702df3570e ("ARM: OMAP4: PM: fix PM regression introduced by recent
clock cleanup") makes the 'ocp2scp_usb_phy_phy_48m' as optional
functional clock causing regression in MUSB. But this 48MHz clock is a
mandatory clock for usb phy attached to ocp2scp and hence made as the main
clock for ocp2scp.

Cc: Keerthy <j-keerthy at ti.com>
Cc: Beno?t Cousson <b-cousson at ti.com>
Cc: Paul Walmsley <paul at pwsan.com>
Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
[paul at pwsan.com: add comment to the hwmod data to try to prevent any
 future mistakes here]
Signed-off-by: Paul Walmsley <paul at pwsan.com>
---

Nothing further received from Kishon per the request:

http://marc.info/?l=linux-omap&m=136554118302342&w=2

Since the deadline for v3.9-rc fixes is quite close, have added the 
comment myself, and have confirmed that this patch does not cause 
additional PM regressions on 4460 Panda-ES in the tests here.

 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |   18 +++++++++++-------
 1 file changed, 11 insertions(+), 7 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 9e05765..eaba9dc 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -2714,16 +2714,22 @@ static struct omap_ocp2scp_dev ocp2scp_dev_attr[] = {
 	{ }
 };
 
-static struct omap_hwmod_opt_clk ocp2scp_usb_phy_opt_clks[] = {
-	{ .role = "48mhz", .clk = "ocp2scp_usb_phy_phy_48m" },
-};
-
 /* ocp2scp_usb_phy */
 static struct omap_hwmod omap44xx_ocp2scp_usb_phy_hwmod = {
 	.name		= "ocp2scp_usb_phy",
 	.class		= &omap44xx_ocp2scp_hwmod_class,
 	.clkdm_name	= "l3_init_clkdm",
-	.main_clk	= "func_48m_fclk",
+	/*
+	 * ocp2scp_usb_phy_phy_48m is provided by the OMAP4 PRCM IP
+	 * block as an "optional clock," and normally should never be
+	 * specified as the main_clk for an OMAP IP block.  However it
+	 * turns out that this clock is actually the main clock for
+	 * the ocp2scp_usb_phy IP block:
+	 * http://lists.infradead.org/pipermail/linux-arm-kernel/2012-September/119943.html
+	 * So listing ocp2scp_usb_phy_phy_48m as a main_clk here seems
+	 * to be the best workaround.
+	 */
+	.main_clk	= "ocp2scp_usb_phy_phy_48m",
 	.prcm = {
 		.omap4 = {
 			.clkctrl_offs = OMAP4_CM_L3INIT_USBPHYOCP2SCP_CLKCTRL_OFFSET,
@@ -2732,8 +2738,6 @@ static struct omap_hwmod omap44xx_ocp2scp_usb_phy_hwmod = {
 		},
 	},
 	.dev_attr	= ocp2scp_dev_attr,
-	.opt_clks	= ocp2scp_usb_phy_opt_clks,
-	.opt_clks_cnt	= ARRAY_SIZE(ocp2scp_usb_phy_opt_clks),
 };
 
 /*
-- 
1.7.10.4

From gregkh at linuxfoundation.org  Wed Apr 10 15:43:37 2013
From: gregkh at linuxfoundation.org (Greg KH)
Date: Wed, 10 Apr 2013 12:43:37 -0700
Subject: [PATCH v7 1/5] drivers: memory: Introduce Marvell EBU Device Bus
 driver
In-Reply-To: <20130410191641.GG28693@titan.lakedaemon.net>
References: <1365620644-15790-1-git-send-email-ezequiel.garcia@free-electrons.com>
 <1365620644-15790-2-git-send-email-ezequiel.garcia@free-electrons.com>
 <20130410191641.GG28693@titan.lakedaemon.net>
Message-ID: <20130410194337.GA5681@kroah.com>

On Wed, Apr 10, 2013 at 03:16:41PM -0400, Jason Cooper wrote:
> gregkh,
> 
> On Wed, Apr 10, 2013 at 04:04:00PM -0300, Ezequiel Garcia wrote:
> > Marvell EBU SoCs such as Armada 370/XP, Orion5x (88f5xxx) and
> > Discovery (mv78xx0) supports a Device Bus controller to access several
> > kinds of memories and I/O devices (NOR, NAND, SRAM, FPGA).
> > 
> > This commit adds a driver to handle this controller. So far only
> > Armada 370, Armada XP and Discovery SoCs are supported.
> > 
> > The driver must be registered through a device tree node;
> > as explained in the binding document.
> > 
> > For each child node in the device tree, this driver will:
> >   * set timing parameters
> >   * register a child device
> >   * setup an address decoding window, using the mbus driver
> > 
> > Keep in mind the address decoding window setup is only a temporary hack.
> > This code will be removed from this devbus driver as soon as a proper device
> > tree binding for the mbus driver is added.
> > 
> > Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
> > Acked-by: Arnd Bergmann <arnd at arndb.de>
> > ---
> >  .../bindings/memory-controllers/mvebu-devbus.txt   | 156 ++++++++++
> >  drivers/memory/Kconfig                             |  10 +
> >  drivers/memory/Makefile                            |   1 +
> >  drivers/memory/mvebu-devbus.c                      | 340 +++++++++++++++++++++
> >  4 files changed, 507 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/memory-controllers/mvebu-devbus.txt
> >  create mode 100644 drivers/memory/mvebu-devbus.c
> 
> As every commit to drivers/memory has been signed by you, would you like
> to take this patch through your tree?  Or, I'll take it through arm-soc
> with your Ack to keep the series together.

Sure, feel free to take this through your tree and add:

Acked-by: Greg Kroah-Hartman <gregkh at linuxfoundation.org>


From linus.walleij at linaro.org  Wed Apr 10 15:44:53 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Wed, 10 Apr 2013 21:44:53 +0200
Subject: [PATCH 4/5] gpio/omap: force restore if context loss is not
 detectable
In-Reply-To: <5165C086.5010105@ti.com>
References: <1365106576-31816-1-git-send-email-jon-hunter@ti.com>
 <1365106576-31816-5-git-send-email-jon-hunter@ti.com>
 <CACRpkdbeABuFXr0Gt6gRto3Pmo0m88AFn_xKJq14VonGg7Doww@mail.gmail.com>
 <5165C086.5010105@ti.com>
Message-ID: <CACRpkdZciGZkWR-qxT96c9pO9UM4fPh_1BUJP9-b1fhjL6-uDg@mail.gmail.com>

On Wed, Apr 10, 2013 at 9:41 PM, Jon Hunter <jon-hunter at ti.com> wrote:
> On 04/10/2013 02:39 PM, Linus Walleij wrote:
>> On Thu, Apr 4, 2013 at 10:16 PM, Jon Hunter <jon-hunter at ti.com> wrote:
>>
>>> When booting with device-tree the function pointer for detecting context
>>> loss is not populated. Ideally, the pm_runtime framework should be
>>> enhanced to allow a means for reporting context/state loss and we could
>>> avoid populating such function pointers altogether. In the interim until
>>> a generic non-device specific solution is in place, force a restore of
>>> the gpio bank when enabling the gpio controller.
>>>
>>> Adds a new device-tree property for the OMAP GPIO controller to indicate
>>> if the GPIO controller is located in a power-domain that never loses
>>> power and hence will always maintain its logic state.
>>>
>>> Signed-off-by: Jon Hunter <jon-hunter at ti.com>
>>
>> In this case it'd be really helpful to get an ACK from somebody else.
>> I have no clue whether this thing is doing what it should, and if
>> you were the maintainer I'd apply it but now I'd like to hear from
>> Kevin or Santosh first...
>
> Santosh gave the his ACK for 1-4 (see 0/5) and Kevin added his
> reviewed-by for 1-4 (again see 0/5).

OK all in patch 0 how confusing #-)

All patches applied with Kevin's and Santosh's tags!

Yours,
Linus Walleij


From jon-hunter at ti.com  Wed Apr 10 15:48:17 2013
From: jon-hunter at ti.com (Jon Hunter)
Date: Wed, 10 Apr 2013 14:48:17 -0500
Subject: [PATCH 1/5] gpio/omap: free irq domain in probe() failure paths
In-Reply-To: <CACRpkdbGw8_eL2KbXU2FxSrDof=O_5tA+siZDLvTqERqa650wA@mail.gmail.com>
References: <1365106576-31816-1-git-send-email-jon-hunter@ti.com>
 <1365106576-31816-2-git-send-email-jon-hunter@ti.com>
 <CACRpkdbGw8_eL2KbXU2FxSrDof=O_5tA+siZDLvTqERqa650wA@mail.gmail.com>
Message-ID: <5165C201.8010500@ti.com>


On 04/10/2013 02:33 PM, Linus Walleij wrote:
> On Thu, Apr 4, 2013 at 10:16 PM, Jon Hunter <jon-hunter at ti.com> wrote:
> 
>> Currently the IRQ domain is not freed once allocated, in the case where
>> omap_gpio_probe() fails. Therefore, ensure we free the domain if the
>> probe does fail. Furthermore, the local variable "ret" is not needed
>> and so remove this.
>>
>> Signed-off-by: Jon Hunter <jon-hunter at ti.com>
> 
> Hm Kevin is still listed as maintainer on this driver but on a mail
> address that bounces, can you send a patch replacing him in MAINTAINERS
> with yourself if you're willing to pick it up?
> 
> Anyway, patch applied.

Thanks. There is a patch to fix this queued for v3.10 [1].

Cheers
Jon

[1]
http://git.kernel.org/cgit/linux/kernel/git/arm/arm-soc.git/commit/MAINTAINERS?h=for-next&id=c69d72aec52eb5234f433259ac5dcc3b68f1480d


From jon-hunter at ti.com  Wed Apr 10 15:50:22 2013
From: jon-hunter at ti.com (Jon Hunter)
Date: Wed, 10 Apr 2013 14:50:22 -0500
Subject: [PATCH 4/5] gpio/omap: force restore if context loss is not
 detectable
In-Reply-To: <CACRpkdZciGZkWR-qxT96c9pO9UM4fPh_1BUJP9-b1fhjL6-uDg@mail.gmail.com>
References: <1365106576-31816-1-git-send-email-jon-hunter@ti.com>
 <1365106576-31816-5-git-send-email-jon-hunter@ti.com>
 <CACRpkdbeABuFXr0Gt6gRto3Pmo0m88AFn_xKJq14VonGg7Doww@mail.gmail.com>
 <5165C086.5010105@ti.com>
 <CACRpkdZciGZkWR-qxT96c9pO9UM4fPh_1BUJP9-b1fhjL6-uDg@mail.gmail.com>
Message-ID: <5165C27E.1060704@ti.com>


On 04/10/2013 02:44 PM, Linus Walleij wrote:
> On Wed, Apr 10, 2013 at 9:41 PM, Jon Hunter <jon-hunter at ti.com> wrote:
>> On 04/10/2013 02:39 PM, Linus Walleij wrote:
>>> On Thu, Apr 4, 2013 at 10:16 PM, Jon Hunter <jon-hunter at ti.com> wrote:
>>>
>>>> When booting with device-tree the function pointer for detecting context
>>>> loss is not populated. Ideally, the pm_runtime framework should be
>>>> enhanced to allow a means for reporting context/state loss and we could
>>>> avoid populating such function pointers altogether. In the interim until
>>>> a generic non-device specific solution is in place, force a restore of
>>>> the gpio bank when enabling the gpio controller.
>>>>
>>>> Adds a new device-tree property for the OMAP GPIO controller to indicate
>>>> if the GPIO controller is located in a power-domain that never loses
>>>> power and hence will always maintain its logic state.
>>>>
>>>> Signed-off-by: Jon Hunter <jon-hunter at ti.com>
>>>
>>> In this case it'd be really helpful to get an ACK from somebody else.
>>> I have no clue whether this thing is doing what it should, and if
>>> you were the maintainer I'd apply it but now I'd like to hear from
>>> Kevin or Santosh first...
>>
>> Santosh gave the his ACK for 1-4 (see 0/5) and Kevin added his
>> reviewed-by for 1-4 (again see 0/5).
> 
> OK all in patch 0 how confusing #-)
> 
> All patches applied with Kevin's and Santosh's tags!

Thanks. Sorry for the confusion!

By the way, I am hoping you only took 1-4, per the cover-letter I was
planning to have Benoit take 5 through his DT branch as there could be
conflicts if you merge this with Benoit's branch. Again sorry if this is
even more confusing ;-)

Cheers
Jon


From tomasz.figa at gmail.com  Wed Apr 10 15:51:11 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Wed, 10 Apr 2013 21:51:11 +0200
Subject: [PATCH] pinctrl: Add pinctrl-s3c24xx driver
In-Reply-To: <201304101545.49264.heiko@sntech.de>
References: <201304100135.12471.heiko@sntech.de>
 <136562781.D2dqZAGJoQ@flatron> <201304101545.49264.heiko@sntech.de>
Message-ID: <124150661.H9fd6KrsIX@flatron>

On Wednesday 10 of April 2013 15:45:48 Heiko St?bner wrote:
> Am Mittwoch, 10. April 2013, 14:31:29 schrieb Tomasz Figa:
> > On Wednesday 10 of April 2013 14:20:22 Heiko St?bner wrote:
> > > Hi Tomasz,
> > > 
> > > thanks for your comments, more inline.
> > > 
> > > Am Mittwoch, 10. April 2013, 12:36:39 schrieb Tomasz Figa:
> > > > Hi Heiko,
> > > > 
> > > > Basically looks good to me, but please see my inline comments
> > > > about
> > > > handling of EINT0-3.
> > > > 
> > > > On Wednesday 10 of April 2013 01:35:12 Heiko St?bner wrote:
> > > > > The s3c24xx pins follow a similar pattern as the other Samsung
> > > > > SoCs
> > > > > and
> > > > > can therefore reuse the already introduced infrastructure.
> > > 
> > > [...]
> > > 
> > > > > +struct s3c24xx_eint_data {
> > > > > +	struct samsung_pinctrl_drv_data *drvdata;
> > > > > +	struct irq_domain *domains[NUM_EINT];
> > > > > +	int parents[NUM_EINT_IRQ];
> > > > > +};
> > > > > +
> > > > > +struct s3c24xx_eint_domain_data {
> > > > > +	struct samsung_pin_bank *bank;
> > > > > +	struct s3c24xx_eint_data *eint_data;
> > > > 
> > > > What about:
> > > > 
> > > > +	bool eint0_3_parent_only;
> > > > 
> > > > (or whatever name would be more appropriate), which would store
> > > > the
> > > > information about the s3c24xx-specific quirk in 24xx-specific data
> > > > structure, without the need to add another field to the generic
> > > > samsung_pinctrl_drv_data structure?
> > > > 
> > > > See my further comments on how I would see using this field in
> > > > interrupt handling code.
> > > 
> > > ok, sounds good, especially gathering the type from the wakeup-int
> > > property
> > > 
> > > > > +};
> > > 
> > > [...]
> > > 
> > > > Now I would split the following 3 functions into two sets of 3
> > > > functions, one set for s3c2412 and other for remaining SoCs and
> > > > make
> > > > separate EINT0-3 IRQ chips for both cases.
> > > 
> > > Not doing the decision every time, might bring some very slight
> > > speed
> > > improvements, so is probably the right way to go.
> > > 
> > > > > +
> > > > > +static void s3c24xx_eint0_3_ack(struct irq_data *data)
> > > > > +{
> > > > > +	struct samsung_pin_bank *bank =
> > > > > irq_data_get_irq_chip_data(data);
> > > > > +	struct samsung_pinctrl_drv_data *d = bank->drvdata;
> > > > > +	struct s3c24xx_eint_domain_data *ddata = bank->irq_domain-
> > > > >
> > > > >host_data;
> > > > >
> > > > > +	struct s3c24xx_eint_data *eint_data = ddata->eint_data;
> > > > > +	int parent_irq = eint_data->parents[data->hwirq];
> > > > > +	struct irq_chip *parent_chip = irq_get_chip(parent_irq);
> > > > > +
> > > > > +	if (d->ctrl->type == S3C2412) {
> > > > > +		unsigned long bitval = 1UL << data->hwirq;
> > > > > +		writel(bitval, d->virt_base + EINTPEND_REG);
> > > > > +	}
> > > > > +
> > > > > +	if (parent_chip->irq_ack)
> > > > > +		parent_chip-
>irq_ack(irq_get_irq_data(parent_irq));
> > > > 
> > > > Btw. Is this parent level acking really needed here?
> > > 
> > > Depends. If using chained_irq_* of course not, but if the
> > > irq-handler
> > > should stay in charge of when to ack it might be better this way.
> > > 
> > > Generic s3c24xx SoCs need acking in the main controller only, while
> > > s3c2412 needs acking in both the main controller and eintpend.
> > > 
> > > > > +}
> > > 
> > > [...]
> > > 
> > > > > +static void s3c24xx_demux_eint0_3(unsigned int irq, struct
> > > > > irq_desc
> > > > > *desc) +{
> > > > > +	struct irq_data *data = irq_desc_get_irq_data(desc);
> > > > > +	struct s3c24xx_eint_data *eint_data =
> > > > > irq_get_handler_data(irq);
> > > > > +	unsigned int virq;
> > > > > +
> > > > 
> > > > Instead of acking the interrupt at parent chip from ack callback
> > > > of
> > > > EINT0_3 chip, I would rather use chained_irq_enter() here...
> > > > 
> > > > > +	/* the first 4 eints have a simple 1 to 1 mapping */
> > > > > +	virq = irq_linear_revmap(eint_data->domains[data->hwirq],
> > > > > data->hwirq); +	/* Something must be really wrong if an 
unmapped
> > > > 
> > > > EINT
> > > > 
> > > > > +	 * was unmasked...
> > > > > +	 */
> > > > > +	BUG_ON(!virq);
> > > > > +
> > > > > +	generic_handle_irq(virq);
> > > > 
> > > > ...and chained_irq_exit() here.
> > > 
> > > If I understand it correctly, the way chained_irq_* works it would
> > > limit the eints to a level style handling. With the way it's
> > > currently the whole determination of when to ack,mask and unmask is
> > > completely for the real handler (edge or level) to decide, as the
> > > original interrupt gets completely forwarded into the irq-domain
> > > without further
> > > constraints.
> > > 
> > > So, after the change on regular s3c24xx SoCs when the real irq
> > > handler
> > > wants to ack the irq, it would be a no-op, as it would already have
> > > been acked by chained_irq_enter.
> > > 
> > > Masking might be even more interesting. Currently control is
> > > transfered
> > > completely to the pinctrl irq-domain, which then controls the
> > > masking of the interrupt thru the parent-calls - on regular s3c24xx
> > > the masking of these is also only done in the main controller.
> > > 
> > > When using chained_irq_* it also wants to mask the interrupt which
> > > might conflict with regular enable_irq/disable_irq calls being done
> > > for example in driver code.
> > > 
> > > 
> > > So in short I agree with the earlier split of the irqchip, but would
> > > keep the irq operations themself centralized in the pinctrl driver,
> > > instead of using chained_irq_* functions.
> > 
> > Right, my solution wouldn't work properly in case of regular s3c24xx
> > and edge triggered interrupts.
> > 
> > However I'm still wondering if it's OK to manually call parent chip
> > operations in case of s3c2416. This would imply the same operation
> > calling order as imposed by flow handler of the chained EINT (which
> > can be handle_edge_irq), while the parent chip is probably level
> > triggered, isn't it?
> 
> I think imposing the same calling order is the right way to go :-) .
> 
> The eints can be set hardware-wise to either level or edge triggered,
> but their flow handler is currently hard set to handle_edge_irq. I
> remember seeing a patch from the Openmoko guys somewhere indicating
> that this does not work at all with level irqs.

Sounds like something broken to me. Level-triggered interrupts need 
different handling than edge-triggered handling and so different flow 
handlers exist for them.

To make my doubts clear, this is how I'm seeing the hardware on 2412:

  edge or level triggered     level triggered
       |   ___________________   |   ________________
       |  |                   |  |  |                |
EINT0 --> | EINT0   EINT0PEND | --> | IRQ0   ARM_INT | --> to the ARM core
       |  |                   |  |  |                |
EINT1 --> | EINT1   EINT1PEND | --> | IRQ1           |
       |  |                   |  |  |                |
EINT2 --> | EINT2   EINT2PEND | --> | IRQ2           |
       |  |                   |  |  |                |
EINT3 --> | EINT3   EINT3PEND | --> | IRQ3           |
          |___________________|     |________________|

             GPIO controller       Interrupt controller

Now EINT0-EINT3 signals of the GPIO controller are directly driven with 
external interrupt signals, either edge or level triggered, but the 
interrupt status is latched in EINT0PEND-EINT3PEND bits inside the GPIO 
controller and state of those bits is exported through EINT0PEND-EINT3PEND 
signals to the interrupt controller's IRQ0-IRQ3 signals, which are now 
level-triggered, since the interrupt is active only when EINTxPEND bit is 
high.

Now, if my vision is wrong, and the hardware has simply EINT0-EINT3 pins 
routed to IRQ0-IRQ3 signals of the interrupt controller, then what you're 
saying is completely right. In this case just ignore my moaning. ;)

Best regards,
Tomasz

> Only the main interrupts of the real demuxed eints (3_to_7 and 8_to...)
> are always level triggered, and therefore already use chained_irq...
> 
> In the current pinctrl driver, the parent eints do not have a flow
> handler of their own (as the chained handler replaces it). So all flow
> handling is done by the flowhandler of the irq in the pinctrl domain.
> 
> handle_IRQ(main_eint)
> -> demux_eint0_3
> -> generic_handle_irq(pinctrl_eint)
> -> handle_edge_irq (or handle_level_irq)
> -> call ack, mask or unmask of the pinctrl eint
> -> call ack, mask or unmask of the underlying main eint
> 
> 
> Heiko


From rklein at nvidia.com  Wed Apr 10 15:51:45 2013
From: rklein at nvidia.com (Rhyland Klein)
Date: Wed, 10 Apr 2013 15:51:45 -0400
Subject: [PATCH] ARM: tegra: Add charger subnode to tps65090 node
Message-ID: <1365623505-6309-1-git-send-email-rklein@nvidia.com>

The charger is now represented by a distinct subnode of the tps65090
device. Add this node and enable low current charging with it.

Signed-off-by: Rhyland Klein <rklein at nvidia.com>
---
- This patch is dependent upon the following fixup-patch.
  http://patchwork.ozlabs.org/patch/235434/

 arch/arm/boot/dts/tegra114-dalmore.dts |    5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/tegra114-dalmore.dts b/arch/arm/boot/dts/tegra114-dalmore.dts
index 72c1f27..d257441 100644
--- a/arch/arm/boot/dts/tegra114-dalmore.dts
+++ b/arch/arm/boot/dts/tegra114-dalmore.dts
@@ -763,6 +763,11 @@
 			vsys-l1-supply = <&vdd_ac_bat_reg>;
 			vsys-l2-supply = <&vdd_ac_bat_reg>;
 
+			charger {
+				compatible = "ti,tps65090-charger";
+				ti,enable-low-current-chrg;
+			};
+
 			regulators {
 				tps65090_dcdc1_reg: dcdc1 {
 					regulator-name = "vdd-sys-5v0";
-- 
1.7.9.5



From daniel.lezcano at linaro.org  Wed Apr 10 15:59:09 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Wed, 10 Apr 2013 21:59:09 +0200
Subject: [PATCH 05/18] cpuidle: make a single register function for all
In-Reply-To: <CAMbhsRSigxzDK3v20ARhXaXK11KL1xZRWkFOXA16YUZ=FtJN9g@mail.gmail.com>
References: <1365603743-5618-1-git-send-email-daniel.lezcano@linaro.org>
 <1365603743-5618-6-git-send-email-daniel.lezcano@linaro.org>
 <CAMbhsRSigxzDK3v20ARhXaXK11KL1xZRWkFOXA16YUZ=FtJN9g@mail.gmail.com>
Message-ID: <5165C48D.5060303@linaro.org>

On 04/10/2013 08:22 PM, Colin Cross wrote:
> On Wed, Apr 10, 2013 at 7:22 AM, Daniel Lezcano
> <daniel.lezcano at linaro.org> wrote:
>> The usual scheme to initialize a cpuidle driver on a SMP is:
>>
>>         cpuidle_register_driver(drv);
>>         for_each_possible_cpu(cpu) {
>>                 device = &per_cpu(cpuidle_dev, cpu);
>>                 cpuidle_register_device(device);
>>         }
>>
>> This code is duplicated in each cpuidle driver.
>>
>> On UP systems, it is done this way:
>>
>>         cpuidle_register_driver(drv);
>>         device = &per_cpu(cpuidle_dev, cpu);
>>         cpuidle_register_device(device);
>>
>> On UP, the macro 'for_each_cpu' does one iteration:
>>
>> #define for_each_cpu(cpu, mask)                 \
>>         for ((cpu) = 0; (cpu) < 1; (cpu)++, (void)mask)
>>
>> Hence, the initialization loop is the same for UP than SMP.
>>
>> Beside, we saw different bugs / mis-initialization / return code unchecked in
>> the different drivers, the code is duplicated including bugs. After fixing all
>> these ones, it appears the initialization pattern is the same for everyone.
>>
>> Let's add a wrapper function doing this initialization with a cpumask parameter
>> for the coupled idle states and use it for all the drivers.
> 
> Isn't this going to cause problems for big.LITTLE, which has two
> independent sets of coupled cpus, and may even have different drivers
> for the two types of cpu?

AFAICT no, because the "low levels" API are still there, I mean
cpuidle_register_driver and cpuidle_register_device. That will be up to
the b.L driver to use the API which fits its need.


-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From daniel.lezcano at linaro.org  Wed Apr 10 15:59:51 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Wed, 10 Apr 2013 21:59:51 +0200
Subject: [PATCH 05/18] cpuidle: make a single register function for all
In-Reply-To: <20130410182359.GN13524@lunn.ch>
References: <1365603743-5618-1-git-send-email-daniel.lezcano@linaro.org>
 <1365603743-5618-6-git-send-email-daniel.lezcano@linaro.org>
 <20130410170457.GL13524@lunn.ch> <5165A937.70705@linaro.org>
 <20130410182359.GN13524@lunn.ch>
Message-ID: <5165C4B7.30601@linaro.org>

On 04/10/2013 08:23 PM, Andrew Lunn wrote:
> On Wed, Apr 10, 2013 at 08:02:31PM +0200, Daniel Lezcano wrote:
>> On 04/10/2013 07:04 PM, Andrew Lunn wrote:
>>>> +int cpuidle_register(struct cpuidle_driver *drv,
>>>> +		     const struct cpumask *const coupled_cpus)
>>>> +{
>>>> +	int ret, cpu;
>>>> +	struct cpuidle_device *device;
>>>> +
>>>> +	ret = cpuidle_register_driver(drv);
>>>> +	if (ret) {
>>>> +		printk(KERN_ERR "failed to register cpuidle driver\n");
>>>> +		return ret;
>>>> +	}
>>>> +
>>>> +	for_each_possible_cpu(cpu) {
>>>> +		device = &per_cpu(cpuidle_dev, cpu);
>>>> +		device->cpu = cpu;
>>>> +#ifdef CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED
>>>> +		device->coupled_cpus = *coupled_cpus;
>>>> +#endif
>>>
>>> At least the kirkwood and the calxeda driver set 
>>>
>>>    device->state_count
>>>
>>> which you don't appear to do. cpuidle_add_state_sysfs() and
>>> cpuidle_remove_state_sysfs() use this. Is it now being set somewhere
>>> else?
>>
>> Yes, in cpuidle_enable_device called from cpuidle_register_device:
> 
> O.K. It would be nice to add a comment in the change log message about
> this.
> 
> Ah, also, it would be good to update Documentation/cpuidle/drivers.txt
> with these new functions and update the text.

Ok, I will take care of that.

Thanks.
  -- Daniel


-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From daniel.lezcano at linaro.org  Wed Apr 10 16:01:30 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Wed, 10 Apr 2013 22:01:30 +0200
Subject: [PATCH 00/18] cpuidle: code consolidation
In-Reply-To: <17970296.uCm16aDdBG@vostro.rjw.lan>
References: <1365603743-5618-1-git-send-email-daniel.lezcano@linaro.org>
 <17970296.uCm16aDdBG@vostro.rjw.lan>
Message-ID: <5165C51A.2010601@linaro.org>

On 04/10/2013 09:12 PM, Rafael J. Wysocki wrote:
> On Wednesday, April 10, 2013 04:22:05 PM Daniel Lezcano wrote:
>> This patchset series provide some code consolidation across the different
>> cpuidle drivers. It contains two parts, the first one is the removal of
>> the time keeping flag and the second one, is a common initialization routine.
>>
>> All the drivers use the en_core_tk_irqen flag, which means it is not necessary
>> to make the time computation optional. We can remove this flag and assume the
>> cpuidle framework always manage this operation.
>>
>> The cpuidle code initialization is duplicated across the different drivers in
>> the same manner.
>>
>> The repeating pattern is:
>>
>> SMP:
>>
>> cpuidle_register_driver(drv);
>> for_each_possible_cpu(cpu) {
>> 	dev = per_cpu(cpuidle_device, cpu);
>> 	cpuidle_register_device(dev);
>> }
>>
>> UP:
>>
>> cpuidle_register_driver(drv);
>> cpuidle_register_device(dev);
>>
>> As on a UP machine the macro 'for_each_cpu' is a one iteration loop, using the
>> initialization loop from SMP to UP works.
>>
>> The patchset does some cleanup for different drivers in order to make the init
>> code the same. Then it introduces a generic function:
>>
>>   cpuidle_register(struct cpuidle_driver *drv, struct cpumask *cpumask)
>>
>> The cpumask is for the coupled idle states.
>>
>> The drivers are then modified to take into account this new function and
>> to remove the duplicated code.
>>
>> The benefit is observable in the diffstat: 332 lines of code removed.
>>
>> Tested-on: u8500
>> Tested-on: at91
>> Tested-on: intel i5
>> Tested-on: OMAP4
>>
>> Compiled with and without CPU_IDLE for:
>>  u8500, at91, davinci, exynos, imx5, imx6, kirkwood, multi_v7 (for calxeda),
>>  omap2plus, s3c64, tegra1, tegra2, tegra3
>>
>>
>> Daniel Lezcano (18):
>>   ARM: OMAP3: remove cpuidle_wrap_enter
>>   cpuidle: remove en_core_tk_irqen flag
>>   ARM: ux500: cpuidle: replace for_each_online_cpu by
>>     for_each_possible_cpu
>>   ARM: imx: cpuidle: create separate drivers for imx5/imx6
>>   cpuidle: make a single register function for all
>>   ARM: ux500: cpuidle: use init/exit common routine
>>   ARM: at91: cpuidle: use init/exit common routine
>>   ARM: OMAP3: cpuidle: use init/exit common routine
>>   ARM: s3c64xx: cpuidle: use init/exit common routine
>>   ARM: tegra1: cpuidle: use init/exit common routine
>>   ARM: shmobile: cpuidle: use init/exit common routine
>>   ARM: OMAP4: cpuidle: use init/exit common routine
>>   ARM: tegra2: cpuidle: use init/exit common routine
>>   ARM: tegra3: cpuidle: use init/exit common routine
>>   ARM: calxeda: cpuidle: use init/exit common routine
>>   ARM: kirkwood: cpuidle: use init/exit common routine
>>   ARM: davinci: cpuidle: use init/exit common routine
>>   ARM: imx: cpuidle: use init/exit common routine
>>
>>  arch/arm/mach-at91/cpuidle.c                    |   18 +--
>>  arch/arm/mach-davinci/cpuidle.c                 |   21 +---
>>  arch/arm/mach-exynos/cpuidle.c                  |    1 -
>>  arch/arm/mach-imx/Makefile                      |    1 +
>>  arch/arm/mach-imx/cpuidle-imx5.c                |   40 +++++++
>>  arch/arm/mach-imx/cpuidle-imx6q.c               |    3 +-
>>  arch/arm/mach-imx/cpuidle.c                     |   80 -------------
>>  arch/arm/mach-imx/cpuidle.h                     |   10 +-
>>  arch/arm/mach-imx/pm-imx5.c                     |   30 +----
>>  arch/arm/mach-omap2/cpuidle34xx.c               |   49 ++------
>>  arch/arm/mach-omap2/cpuidle44xx.c               |   23 +---
>>  arch/arm/mach-s3c64xx/cpuidle.c                 |   15 +--
>>  arch/arm/mach-shmobile/cpuidle.c                |   11 +-
>>  arch/arm/mach-shmobile/pm-sh7372.c              |    1 -
>>  arch/arm/mach-tegra/cpuidle-tegra114.c          |   27 +----
>>  arch/arm/mach-tegra/cpuidle-tegra20.c           |   34 +-----
>>  arch/arm/mach-tegra/cpuidle-tegra30.c           |   28 +----
>>  arch/arm/mach-ux500/cpuidle.c                   |   33 +-----
>>  arch/powerpc/platforms/pseries/processor_idle.c |    1 -
>>  arch/sh/kernel/cpu/shmobile/cpuidle.c           |    1 -
>>  arch/x86/kernel/apm_32.c                        |    1 -
>>  drivers/acpi/processor_idle.c                   |    1 -
>>  drivers/cpuidle/cpuidle-calxeda.c               |   53 +--------
>>  drivers/cpuidle/cpuidle-kirkwood.c              |   18 +--
>>  drivers/cpuidle/cpuidle.c                       |  137 ++++++++++++++---------
>>  drivers/idle/intel_idle.c                       |    1 -
>>  include/linux/cpuidle.h                         |   20 ++--
>>  27 files changed, 162 insertions(+), 496 deletions(-)
>>  create mode 100644 arch/arm/mach-imx/cpuidle-imx5.c
>>  delete mode 100644 arch/arm/mach-imx/cpuidle.c
> 
> I will be traveling from Saturday onwards pretty much until the beginning of
> the 3.10 merge window, so I'm afraid this will have to wait for the next
> release cycle.  At least I'm not going to take patches that haven't been
> ACKed before tomorrow evening (CEST).

Ok, thanks for the heads-up.

  -- Daniel


-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From linux at arm.linux.org.uk  Wed Apr 10 16:03:44 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Wed, 10 Apr 2013 21:03:44 +0100
Subject: Removal of NWFPE in its entirety, and VFP emulation code
In-Reply-To: <yw1xehei8a19.fsf@unicorn.mansr.com>
References: <20130410104002.GF14496@n2100.arm.linux.org.uk>
 <yw1xmwt68whw.fsf@unicorn.mansr.com>
 <20130410114229.GH14496@n2100.arm.linux.org.uk>
 <yw1xip3u8uni.fsf@unicorn.mansr.com>
 <20130410185421.GI14496@n2100.arm.linux.org.uk>
 <yw1xehei8a19.fsf@unicorn.mansr.com>
Message-ID: <20130410200344.GO14496@n2100.arm.linux.org.uk>

On Wed, Apr 10, 2013 at 08:23:30PM +0100, M?ns Rullg?rd wrote:
> Russell King - ARM Linux <linux at arm.linux.org.uk> writes:
> 
> > On Wed, Apr 10, 2013 at 12:58:09PM +0100, M?ns Rullg?rd wrote:
> >> Russell King - ARM Linux <linux at arm.linux.org.uk> writes:
> >> 
> >> > On Wed, Apr 10, 2013 at 12:18:19PM +0100, M?ns Rullg?rd wrote:
> >> >> Russell King - ARM Linux <linux at arm.linux.org.uk> writes:
> >> >> 
> >> >> > The situation with VFP is likely less disruptive - only instructions
> >> >> > which aren't implemented in hardware (or, for example, if you ask for
> >> >> > inexact exceptions to be enabled) which are bounced to the software
> >> >> > support code will be affected.  I think OMAP should get away unscathed,
> >> >> > but ARM's implementation will bounce if inexact exceptions are enabled
> >> >> 
> >> >> What do you mean by this?  OMAP uses ARM's cores.
> >> >
> >> > OMAP's VFP reports that it never traps to support code for VFP instructions,
> >> > so the emulation code is never used on OMAP.
> >> 
> >> That is true for OMAP2 (ARM1136/VFP11) and OMAP3 (Cortex-A8).  OMAP4
> >> (Cortex-A9) and OMAP5 (Cortex-A15) both trap on vector operations.
> >
> > No.  Both OMAP3 and OMAP4 report that they are VFP subarchitecture 3,
> > and the VFP subarchitecture 3 never traps to support code for any
> > instruction (it's the "null subarchitecture" value.)
> 
> VFPv3 does not require hardware support for vector operations, and the
> Cortex-A9 NEON TRM [1] says this:
>
>    ARMv7 deprecates the use of VFP vector mode. The Cortex-A9 NEON MPE
>    hardware does not support VFP vector operations. [...] The Cortex-A9
>    NEON MPE provides high speed VFP operation without support code.
>    However, if an application requires VFP vector operation, then it
>    must use support code.
> 
> [1] http://infocenter.arm.com/help/topic/com.arm.doc.ddi0409i/CHDEEJDB.html
> 
> The VFP-only TRM [2] contains similar language:
> 
>   The use of VFP vector mode is deprecated in ARMv7.  Vector operations
>   are not supported in hardware.  If you use vectors, support code is
>   required.
> 
> [2] http://infocenter.arm.com/help/topic/com.arm.doc.ddi0408i/I1019986.html
> 
> The Cortex-A15 TRM [3] follows suit:
> 
>   Vector operations are not supported.  Any attempt to execute a vector
>   operation results in an Undefined Instruction exception.  If an
>   application requires VFP vector operation, then it must use VFP
>   support code.
> 
> [3] http://infocenter.arm.com/help/topic/com.arm.doc.ddi0438h/CEGCDBHC.html
> 
> In future, if you checked the relevant documentation before making bold
> claims, you might avoid making a fool of yourself.

Oh fuck off, just really fuck off you total dickface.  Really, do you
think that I, being the one who created the VFP support code, haven't
read the VFP documentation?  Christ, you are fucking thick.

Subarchitecture, bits [22:16]
0b0000011
VFP architecture v3 or later with Null subarchitecture. The entire floating-point
implementation is in hardware, and no software support code is required. The
VFP architecture version is indicated by the MVFR0 and MVFR1 registers.
This value can be used only by an implementation that does not support the trap
enable bits in the FPSCR, see Floating-point Status and Control Register
(FPSCR) on page A2-28.

And both OMAP3 and OMAP4 report *this* subarchitecture version.  Maybe
it's you who needs to take a reading lesson instead of making a prat of
*yourself*.


From linux at arm.linux.org.uk  Wed Apr 10 16:04:41 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Wed, 10 Apr 2013 21:04:41 +0100
Subject: Removal of NWFPE in its entirety, and VFP emulation code
In-Reply-To: <yw1xa9p689x4.fsf@unicorn.mansr.com>
References: <20130410104002.GF14496@n2100.arm.linux.org.uk>
 <alpine.LFD.2.03.1304101307280.17375@syhkavp.arg>
 <yw1xa9p689x4.fsf@unicorn.mansr.com>
Message-ID: <20130410200441.GP14496@n2100.arm.linux.org.uk>

On Wed, Apr 10, 2013 at 08:25:59PM +0100, M?ns Rullg?rd wrote:
> Nicolas Pitre <nico at fluxnic.net> writes:
> 
> > So another option here might imply deprecating OABI support entirely, 
> 
> I'd support such a move.

And your previous reply disqualified your opinions on any subject.
Sorry.  If you want to have a public flame war instead of being
reasonable, you can't expect your opinions to be taken seriously.


From paul at pwsan.com  Wed Apr 10 16:05:05 2013
From: paul at pwsan.com (Paul Walmsley)
Date: Wed, 10 Apr 2013 20:05:05 +0000 (UTC)
Subject: OMAP baseline test results for v3.9-rc6
Message-ID: <alpine.DEB.2.00.1304102003190.25123@utopia.booyaka.com>


Here are some basic OMAP test results for Linux v3.9-rc6.
Logs and other details at:

    http://www.pwsan.com/omap/testlogs/test_v3.9-rc6/20130410123059/


Test summary
------------

Build:
    FAIL ( 2/16): am33xx_only, omap2plus_defconfig_2430sdp_only
    Pass (14/16): n800_multi_omap2xxx, n800_only_a, omap1_defconfig,
		  omap1_defconfig_1510innovator_only, 
		  omap1_defconfig_5912osk_only,
		  omap2plus_defconfig, omap2plus_defconfig_cpupm,
		  omap2plus_defconfig_no_pm,
		  omap2plus_defconfig_omap2_4_only,
		  omap2plus_defconfig_omap3_4_only,
		  rmk_omap3430_ldp_allnoconfig,
		  rmk_omap3430_ldp_oldconfig,
		  rmk_omap4430_sdp_allnoconfig
		  rmk_omap4430_sdp_oldconfig

Boot to userspace:
    FAIL ( 1/11): am335xbone
    Pass (10/11): 2420n800, 2430sdp, 3517evm, 3530es3beagle,
  	   	  3730beaglexm, 37xxevm, 4430es2panda, 4460pandaes,
		  5912osk, cmt3517

PM ret, suspend:
    FAIL ( 3/ 6): 2430sdp, 37xxevm, 4430es2panda
    Pass ( 3/ 6): 3530es3beagle, 3730beaglexm, 4460pandaes

PM ret, dynamic idle:
    FAIL ( 4/ 6): 2430sdp, 37xxevm, 4430es2panda, 4460pandaes
    Pass ( 2/ 6): 3530es3beagle, 3730beaglexm

PM off, suspend:
    FAIL ( 3/ 5): 37xxevm, 4430es2panda, 4460pandaes
    Pass ( 2/ 5): 3530es3beagle, 3730beaglexm

PM off, dynamic idle:
    FAIL ( 3/ 5): 37xxevm, 4430es2panda, 4460pandaes
    Pass ( 2/ 5): 3530es3beagle, 3730beaglexm


Failing tests: fixed by posted patches
--------------------------------------

Build:

* am33xx_only, omap2plus_defconfig_2430sdp_only: omap-{smp,hotplug}.c link 
errors
  - Discussion & RFC patch: 
http://www.spinics.net/lists/arm-kernel/msg230017.html
  - Still needs revision of the patch


Failing tests: needing investigation
------------------------------------

Boot tests:

* 3517EVM & CM-T3517: boot hangs with NFS root
  - Likely some Kconfig, board file, and PM issues with EMAC
  - Longstanding bug
  - Not currently part of the automated test suite

Boot warnings:

* CM-T3517: L3 in-band error with IPSS during boot
  - Cause unknown but see 
http://marc.info/?l=linux-omap&m=134833869730129&w=2
  - Longstanding issue; does not occur on the 3517EVM

PM tests:

* 2430sdp: pwrdm state mismatch(dsp_pwrdm) 0 != 3
  - need to doublecheck wakeup dependencies
  - (am assuming it's still there; userspace problems prevent the test
     from running, probably due to the lock warning)

* 2430sdp: power domains not entering retention
  - Cause unknown
  - (am assuming it's still there; userspace problems prevent the test
     from running, probably due to the lock warning)

* 4430es2panda, 4460pandaes: pwrdm state mismatch on CAM, DSS, ABE

* 4460pandaes: pwrdm state mismatch on IVAHD, TESLA 

* 4430es2panda: CORE, TESLA, IVAHD, L3INIT didn't enter target state
  - Probably due to lack of reset code for M3, DSP, SL2IF, FSUSB
    per discussion with Tero Kristo
  - Likely dependent on the bootloader version
    - fails with 2012.07-00136-g755de79
  - http://marc.info/?l=linux-arm-kernel&m=136432340618226&w=2

* 4460pandaes: chip not entering retention in dynamic idle
  - Presumably 4430es2panda also fails this
  - Suspend-to-RAM enters full chip retention

* 3730 Beagle XM: does not serial wake from off-idle suspend when console
  UART doesn't clock-gate ("debug ignore_loglevel")
  - Cause unknown
  - Not yet part of the automated test suite
  - Re-tested at v3.7; still failing:
    
http://www.pwsan.com/omap/transcripts/20121211-3730beaglexm-3.7-pm-offmode-fail-debug.txt

Other:

* 4430es2panda: omap_hwmod: l3_instr: _wait_target_disable failed
  - Unknown cause; could be due to the lack of hierarchical enable/disable
    in hwmod code
  - Jon Hunter and Santosh Shilimkar report this does not appear with
    the same X-loader/bootloader on his 4430ES2.3 Panda, so could be
    ES-level dependent


Failing tests: reported by others 
---------------------------------

- MUSB broken after v3.9-rc6
  - due to commit 92702df3570e1ccfa050e135e50c450502251b79
  - discussion here: http://marc.info/?l=linux-omap&m=136544098331552&w=2
  - patch here but needs work:
    http://marc.info/?l=linux-kernel&m=136554118002341&w=2


vmlinux object size
(delta in bytes from test_v3.9-rc5 
(07961ac7c0ee8b546658717034fe692fd12eefa9)):
   text     data      bss    total  kernel
   +579     +104      +64     +747  n800_multi_omap2xxx
   +503      +88        0     +591  n800_only_a
  +1111      -40        0    +1071  omap1_defconfig
  +1123      -72        0    +1051  omap1_defconfig_1510innovator_only
  +1107      -32        0    +1075  omap1_defconfig_5912osk_only
  +1291     +248        0    +1539  omap2plus_defconfig
  +1223     +216        0    +1439  omap2plus_defconfig_cpupm
  +1287     +184        0    +1471  omap2plus_defconfig_no_pm
  +1015     +184      +64    +1263  omap2plus_defconfig_omap2_4_only
  +1159     +184      +64    +1407  omap2plus_defconfig_omap3_4_only
   +780     +136     -124     +792  rmk_omap3430_ldp_allnoconfig
  +1075     +144        0    +1219  rmk_omap3430_ldp_oldconfig
   +780     +136     -124     +792  rmk_omap4430_sdp_allnoconfig
  +1155     +144        0    +1299  rmk_omap4430_sdp_oldconfig

Boot-time memory difference
(delta in bytes from test_v3.9-rc5 
(07961ac7c0ee8b546658717034fe692fd12eefa9))
  avail  rsrvd   high  freed  board          kconfig
    -4k     4k      .      .  2420n800       n800_only_a
    -8k     8k      .      .  2430sdp        omap2plus_defconfig
    -8k     8k      .      .  3517evm        omap2plus_defconfig
    -8k     8k      .      .  3530es3beagle  omap2plus_defconfig
    -8k     8k      .      .  3730beaglexm   omap2plus_defconfig
    -8k     8k      .      .  37xxevm        omap2plus_defconfig
    -8k     8k      .      .  4430es2panda   omap2plus_defconfig
    -8k     8k      .      .  4460pandaes    omap2plus_defconfig
    -8k     8k      .      .  5912osk        omap1_defconfig


- Paul


From paul at pwsan.com  Wed Apr 10 16:09:30 2013
From: paul at pwsan.com (Paul Walmsley)
Date: Wed, 10 Apr 2013 20:09:30 +0000 (UTC)
Subject: [PATCH] ARM: OMAP4: PM: fix PM regression introduced by recent
 clock cleanup
In-Reply-To: <alpine.DEB.2.00.1302122026530.29149@utopia.booyaka.com>
References: <alpine.DEB.2.00.1302122026530.29149@utopia.booyaka.com>
Message-ID: <alpine.DEB.2.00.1304102007030.25123@utopia.booyaka.com>

On Tue, 12 Feb 2013, Paul Walmsley wrote:

> First, I missed the retention entry failure in the branch test logs:
> 
> http://www.pwsan.com/omap/testlogs/cleanup_a_3.9/20130126014242/pm/4460pandaes/4460pandaes_log.txt

Just a brief note.  For the past few -rc releases, have switched here to 
using scripts that parse the PM result logs, for PM validation.

The scripts are probably not perfect, but they're less likely to miss the 
cases they're set up to test.


- Paul


From heiko at sntech.de  Wed Apr 10 16:11:03 2013
From: heiko at sntech.de (Heiko =?iso-8859-1?q?St=FCbner?=)
Date: Wed, 10 Apr 2013 22:11:03 +0200
Subject: [PATCH] pinctrl: Add pinctrl-s3c24xx driver
In-Reply-To: <124150661.H9fd6KrsIX@flatron>
References: <201304100135.12471.heiko@sntech.de>
 <201304101545.49264.heiko@sntech.de> <124150661.H9fd6KrsIX@flatron>
Message-ID: <201304102211.03870.heiko@sntech.de>

Am Mittwoch, 10. April 2013, 21:51:11 schrieb Tomasz Figa:
> On Wednesday 10 of April 2013 15:45:48 Heiko St?bner wrote:
> > Am Mittwoch, 10. April 2013, 14:31:29 schrieb Tomasz Figa:
> > > On Wednesday 10 of April 2013 14:20:22 Heiko St?bner wrote:
> > > > Hi Tomasz,
> > > > 
> > > > thanks for your comments, more inline.
> > > > 
> > > > Am Mittwoch, 10. April 2013, 12:36:39 schrieb Tomasz Figa:
> > > > > Hi Heiko,
> > > > > 
> > > > > Basically looks good to me, but please see my inline comments
> > > > > about
> > > > > handling of EINT0-3.
> > > > > 
> > > > > On Wednesday 10 of April 2013 01:35:12 Heiko St?bner wrote:
> > > > > > The s3c24xx pins follow a similar pattern as the other Samsung
> > > > > > SoCs
> > > > > > and
> > > > > > can therefore reuse the already introduced infrastructure.
> > > > 
> > > > [...]
> > > > 
> > > > > > +struct s3c24xx_eint_data {
> > > > > > +	struct samsung_pinctrl_drv_data *drvdata;
> > > > > > +	struct irq_domain *domains[NUM_EINT];
> > > > > > +	int parents[NUM_EINT_IRQ];
> > > > > > +};
> > > > > > +
> > > > > > +struct s3c24xx_eint_domain_data {
> > > > > > +	struct samsung_pin_bank *bank;
> > > > > > +	struct s3c24xx_eint_data *eint_data;
> > > > > 
> > > > > What about:
> > > > > 
> > > > > +	bool eint0_3_parent_only;
> > > > > 
> > > > > (or whatever name would be more appropriate), which would store
> > > > > the
> > > > > information about the s3c24xx-specific quirk in 24xx-specific data
> > > > > structure, without the need to add another field to the generic
> > > > > samsung_pinctrl_drv_data structure?
> > > > > 
> > > > > See my further comments on how I would see using this field in
> > > > > interrupt handling code.
> > > > 
> > > > ok, sounds good, especially gathering the type from the wakeup-int
> > > > property
> > > > 
> > > > > > +};
> > > > 
> > > > [...]
> > > > 
> > > > > Now I would split the following 3 functions into two sets of 3
> > > > > functions, one set for s3c2412 and other for remaining SoCs and
> > > > > make
> > > > > separate EINT0-3 IRQ chips for both cases.
> > > > 
> > > > Not doing the decision every time, might bring some very slight
> > > > speed
> > > > improvements, so is probably the right way to go.
> > > > 
> > > > > > +
> > > > > > +static void s3c24xx_eint0_3_ack(struct irq_data *data)
> > > > > > +{
> > > > > > +	struct samsung_pin_bank *bank =
> > > > > > irq_data_get_irq_chip_data(data);
> > > > > > +	struct samsung_pinctrl_drv_data *d = bank->drvdata;
> > > > > > +	struct s3c24xx_eint_domain_data *ddata = bank->irq_domain-
> > > > > >
> > > > > >host_data;
> > > > > >
> > > > > > +	struct s3c24xx_eint_data *eint_data = ddata->eint_data;
> > > > > > +	int parent_irq = eint_data->parents[data->hwirq];
> > > > > > +	struct irq_chip *parent_chip = irq_get_chip(parent_irq);
> > > > > > +
> > > > > > +	if (d->ctrl->type == S3C2412) {
> > > > > > +		unsigned long bitval = 1UL << data->hwirq;
> > > > > > +		writel(bitval, d->virt_base + EINTPEND_REG);
> > > > > > +	}
> > > > > > +
> > > > > > +	if (parent_chip->irq_ack)
> > > > > > +		parent_chip-
> >
> >irq_ack(irq_get_irq_data(parent_irq));
> >
> > > > > Btw. Is this parent level acking really needed here?
> > > > 
> > > > Depends. If using chained_irq_* of course not, but if the
> > > > irq-handler
> > > > should stay in charge of when to ack it might be better this way.
> > > > 
> > > > Generic s3c24xx SoCs need acking in the main controller only, while
> > > > s3c2412 needs acking in both the main controller and eintpend.
> > > > 
> > > > > > +}
> > > > 
> > > > [...]
> > > > 
> > > > > > +static void s3c24xx_demux_eint0_3(unsigned int irq, struct
> > > > > > irq_desc
> > > > > > *desc) +{
> > > > > > +	struct irq_data *data = irq_desc_get_irq_data(desc);
> > > > > > +	struct s3c24xx_eint_data *eint_data =
> > > > > > irq_get_handler_data(irq);
> > > > > > +	unsigned int virq;
> > > > > > +
> > > > > 
> > > > > Instead of acking the interrupt at parent chip from ack callback
> > > > > of
> > > > > EINT0_3 chip, I would rather use chained_irq_enter() here...
> > > > > 
> > > > > > +	/* the first 4 eints have a simple 1 to 1 mapping */
> > > > > > +	virq = irq_linear_revmap(eint_data->domains[data->hwirq],
> > > > > > data->hwirq); +	/* Something must be really wrong if an
> 
> unmapped
> 
> > > > > EINT
> > > > > 
> > > > > > +	 * was unmasked...
> > > > > > +	 */
> > > > > > +	BUG_ON(!virq);
> > > > > > +
> > > > > > +	generic_handle_irq(virq);
> > > > > 
> > > > > ...and chained_irq_exit() here.
> > > > 
> > > > If I understand it correctly, the way chained_irq_* works it would
> > > > limit the eints to a level style handling. With the way it's
> > > > currently the whole determination of when to ack,mask and unmask is
> > > > completely for the real handler (edge or level) to decide, as the
> > > > original interrupt gets completely forwarded into the irq-domain
> > > > without further
> > > > constraints.
> > > > 
> > > > So, after the change on regular s3c24xx SoCs when the real irq
> > > > handler
> > > > wants to ack the irq, it would be a no-op, as it would already have
> > > > been acked by chained_irq_enter.
> > > > 
> > > > Masking might be even more interesting. Currently control is
> > > > transfered
> > > > completely to the pinctrl irq-domain, which then controls the
> > > > masking of the interrupt thru the parent-calls - on regular s3c24xx
> > > > the masking of these is also only done in the main controller.
> > > > 
> > > > When using chained_irq_* it also wants to mask the interrupt which
> > > > might conflict with regular enable_irq/disable_irq calls being done
> > > > for example in driver code.
> > > > 
> > > > 
> > > > So in short I agree with the earlier split of the irqchip, but would
> > > > keep the irq operations themself centralized in the pinctrl driver,
> > > > instead of using chained_irq_* functions.
> > > 
> > > Right, my solution wouldn't work properly in case of regular s3c24xx
> > > and edge triggered interrupts.
> > > 
> > > However I'm still wondering if it's OK to manually call parent chip
> > > operations in case of s3c2416. This would imply the same operation
> > > calling order as imposed by flow handler of the chained EINT (which
> > > can be handle_edge_irq), while the parent chip is probably level
> > > triggered, isn't it?
> > 
> > I think imposing the same calling order is the right way to go :-) .
> > 
> > The eints can be set hardware-wise to either level or edge triggered,
> > but their flow handler is currently hard set to handle_edge_irq. I
> > remember seeing a patch from the Openmoko guys somewhere indicating
> > that this does not work at all with level irqs.
> 
> Sounds like something broken to me. Level-triggered interrupts need
> different handling than edge-triggered handling and so different flow
> handlers exist for them.
> 
> To make my doubts clear, this is how I'm seeing the hardware on 2412:
> 
>   edge or level triggered     level triggered
> 
>        |   ___________________   |   ________________
> 
> EINT0 --> | EINT0   EINT0PEND | --> | IRQ0   ARM_INT | --> to the ARM core
> 
> EINT1 --> | EINT1   EINT1PEND | --> | IRQ1           |
> 
> EINT2 --> | EINT2   EINT2PEND | --> | IRQ2           |
> 
> EINT3 --> | EINT3   EINT3PEND | --> | IRQ3           |
> 
>           |___________________|     |________________|
> 
>              GPIO controller       Interrupt controller
> 
> Now EINT0-EINT3 signals of the GPIO controller are directly driven with
> external interrupt signals, either edge or level triggered, but the
> interrupt status is latched in EINT0PEND-EINT3PEND bits inside the GPIO
> controller and state of those bits is exported through EINT0PEND-EINT3PEND
> signals to the interrupt controller's IRQ0-IRQ3 signals, which are now
> level-triggered, since the interrupt is active only when EINTxPEND bit is
> high.
> 
> Now, if my vision is wrong, and the hardware has simply EINT0-EINT3 pins
> routed to IRQ0-IRQ3 signals of the interrupt controller, then what you're
> saying is completely right. In this case just ignore my moaning. ;)

I know the s3c2412 only in theory myself and am just going with the old code 
:-) . So all the irq rework stuff I did was only done on a theoretical level 
for s3c2412, so I don't really know if the current irq code runs for sure 
there.

But when looking at the real old code that must have run sucessfully at some 
point in the past [0], the comment says

"the s3c2412 changes the behaviour of IRQ_EINT0 through IRQ_EINT3 by
 having them turn up in both the INT* and the EINT* registers. Whilst
 both show the status, they both now need to be acked when the IRQs
 go off."

And then simply doing a
	__raw_writel(bitval, S3C2412_EINTPEND);
	__raw_writel(bitval, S3C2410_SRCPND);
	__raw_writel(bitval, S3C2410_INTPND);
there - which is essentially the same that happens in the current pinctrl ack 
code.

So if we assume the really old code worked at some point, I'm relativly sure 
the new one will too :-). I'll just exchange the mask ordering in 
s3c2412_eint0_3_mask, to match the ordering in the original function.


Heiko


[0] 
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/mach-
s3c24xx/irq-s3c2412.c


From tomasz.figa at gmail.com  Wed Apr 10 16:17:43 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Wed, 10 Apr 2013 22:17:43 +0200
Subject: [PATCH] pinctrl: Add pinctrl-s3c24xx driver
In-Reply-To: <201304102211.03870.heiko@sntech.de>
References: <201304100135.12471.heiko@sntech.de>
 <124150661.H9fd6KrsIX@flatron> <201304102211.03870.heiko@sntech.de>
Message-ID: <1454321.I0NHk7e3H9@flatron>

On Wednesday 10 of April 2013 22:11:03 Heiko St?bner wrote:
> Am Mittwoch, 10. April 2013, 21:51:11 schrieb Tomasz Figa:
> > On Wednesday 10 of April 2013 15:45:48 Heiko St?bner wrote:
> > > Am Mittwoch, 10. April 2013, 14:31:29 schrieb Tomasz Figa:
> > > > On Wednesday 10 of April 2013 14:20:22 Heiko St?bner wrote:
> > > > > Hi Tomasz,
> > > > > 
> > > > > thanks for your comments, more inline.
> > > > > 
> > > > > Am Mittwoch, 10. April 2013, 12:36:39 schrieb Tomasz Figa:
> > > > > > Hi Heiko,
> > > > > > 
> > > > > > Basically looks good to me, but please see my inline comments
> > > > > > about
> > > > > > handling of EINT0-3.
> > > > > > 
> > > > > > On Wednesday 10 of April 2013 01:35:12 Heiko St?bner wrote:
> > > > > > > The s3c24xx pins follow a similar pattern as the other
> > > > > > > Samsung
> > > > > > > SoCs
> > > > > > > and
> > > > > > > can therefore reuse the already introduced infrastructure.
> > > > > 
> > > > > [...]
> > > > > 
> > > > > > > +struct s3c24xx_eint_data {
> > > > > > > +	struct samsung_pinctrl_drv_data *drvdata;
> > > > > > > +	struct irq_domain *domains[NUM_EINT];
> > > > > > > +	int parents[NUM_EINT_IRQ];
> > > > > > > +};
> > > > > > > +
> > > > > > > +struct s3c24xx_eint_domain_data {
> > > > > > > +	struct samsung_pin_bank *bank;
> > > > > > > +	struct s3c24xx_eint_data *eint_data;
> > > > > > 
> > > > > > What about:
> > > > > > 
> > > > > > +	bool eint0_3_parent_only;
> > > > > > 
> > > > > > (or whatever name would be more appropriate), which would
> > > > > > store
> > > > > > the
> > > > > > information about the s3c24xx-specific quirk in 24xx-specific
> > > > > > data
> > > > > > structure, without the need to add another field to the
> > > > > > generic
> > > > > > samsung_pinctrl_drv_data structure?
> > > > > > 
> > > > > > See my further comments on how I would see using this field in
> > > > > > interrupt handling code.
> > > > > 
> > > > > ok, sounds good, especially gathering the type from the
> > > > > wakeup-int
> > > > > property
> > > > > 
> > > > > > > +};
> > > > > 
> > > > > [...]
> > > > > 
> > > > > > Now I would split the following 3 functions into two sets of 3
> > > > > > functions, one set for s3c2412 and other for remaining SoCs
> > > > > > and
> > > > > > make
> > > > > > separate EINT0-3 IRQ chips for both cases.
> > > > > 
> > > > > Not doing the decision every time, might bring some very slight
> > > > > speed
> > > > > improvements, so is probably the right way to go.
> > > > > 
> > > > > > > +
> > > > > > > +static void s3c24xx_eint0_3_ack(struct irq_data *data)
> > > > > > > +{
> > > > > > > +	struct samsung_pin_bank *bank =
> > > > > > > irq_data_get_irq_chip_data(data);
> > > > > > > +	struct samsung_pinctrl_drv_data *d = bank->drvdata;
> > > > > > > +	struct s3c24xx_eint_domain_data *ddata = bank->irq_domain-
> > > > > > >
> > > > > > >host_data;
> > > > > > >
> > > > > > > +	struct s3c24xx_eint_data *eint_data = ddata->eint_data;
> > > > > > > +	int parent_irq = eint_data->parents[data->hwirq];
> > > > > > > +	struct irq_chip *parent_chip = irq_get_chip(parent_irq);
> > > > > > > +
> > > > > > > +	if (d->ctrl->type == S3C2412) {
> > > > > > > +		unsigned long bitval = 1UL << data->hwirq;
> > > > > > > +		writel(bitval, d->virt_base + EINTPEND_REG);
> > > > > > > +	}
> > > > > > > +
> > > > > > > +	if (parent_chip->irq_ack)
> > > > > > > +		parent_chip-
> > >
> > >irq_ack(irq_get_irq_data(parent_irq));
> > >
> > > > > > Btw. Is this parent level acking really needed here?
> > > > > 
> > > > > Depends. If using chained_irq_* of course not, but if the
> > > > > irq-handler
> > > > > should stay in charge of when to ack it might be better this
> > > > > way.
> > > > > 
> > > > > Generic s3c24xx SoCs need acking in the main controller only,
> > > > > while
> > > > > s3c2412 needs acking in both the main controller and eintpend.
> > > > > 
> > > > > > > +}
> > > > > 
> > > > > [...]
> > > > > 
> > > > > > > +static void s3c24xx_demux_eint0_3(unsigned int irq, struct
> > > > > > > irq_desc
> > > > > > > *desc) +{
> > > > > > > +	struct irq_data *data = irq_desc_get_irq_data(desc);
> > > > > > > +	struct s3c24xx_eint_data *eint_data =
> > > > > > > irq_get_handler_data(irq);
> > > > > > > +	unsigned int virq;
> > > > > > > +
> > > > > > 
> > > > > > Instead of acking the interrupt at parent chip from ack
> > > > > > callback
> > > > > > of
> > > > > > EINT0_3 chip, I would rather use chained_irq_enter() here...
> > > > > > 
> > > > > > > +	/* the first 4 eints have a simple 1 to 1 mapping */
> > > > > > > +	virq = irq_linear_revmap(eint_data->domains[data->hwirq],
> > > > > > > data->hwirq); +	/* Something must be really wrong if an
> > 
> > unmapped
> > 
> > > > > > EINT
> > > > > > 
> > > > > > > +	 * was unmasked...
> > > > > > > +	 */
> > > > > > > +	BUG_ON(!virq);
> > > > > > > +
> > > > > > > +	generic_handle_irq(virq);
> > > > > > 
> > > > > > ...and chained_irq_exit() here.
> > > > > 
> > > > > If I understand it correctly, the way chained_irq_* works it
> > > > > would
> > > > > limit the eints to a level style handling. With the way it's
> > > > > currently the whole determination of when to ack,mask and unmask
> > > > > is
> > > > > completely for the real handler (edge or level) to decide, as
> > > > > the
> > > > > original interrupt gets completely forwarded into the irq-domain
> > > > > without further
> > > > > constraints.
> > > > > 
> > > > > So, after the change on regular s3c24xx SoCs when the real irq
> > > > > handler
> > > > > wants to ack the irq, it would be a no-op, as it would already
> > > > > have
> > > > > been acked by chained_irq_enter.
> > > > > 
> > > > > Masking might be even more interesting. Currently control is
> > > > > transfered
> > > > > completely to the pinctrl irq-domain, which then controls the
> > > > > masking of the interrupt thru the parent-calls - on regular
> > > > > s3c24xx
> > > > > the masking of these is also only done in the main controller.
> > > > > 
> > > > > When using chained_irq_* it also wants to mask the interrupt
> > > > > which
> > > > > might conflict with regular enable_irq/disable_irq calls being
> > > > > done
> > > > > for example in driver code.
> > > > > 
> > > > > 
> > > > > So in short I agree with the earlier split of the irqchip, but
> > > > > would
> > > > > keep the irq operations themself centralized in the pinctrl
> > > > > driver,
> > > > > instead of using chained_irq_* functions.
> > > > 
> > > > Right, my solution wouldn't work properly in case of regular
> > > > s3c24xx
> > > > and edge triggered interrupts.
> > > > 
> > > > However I'm still wondering if it's OK to manually call parent
> > > > chip
> > > > operations in case of s3c2416. This would imply the same operation
> > > > calling order as imposed by flow handler of the chained EINT
> > > > (which
> > > > can be handle_edge_irq), while the parent chip is probably level
> > > > triggered, isn't it?
> > > 
> > > I think imposing the same calling order is the right way to go :-) .
> > > 
> > > The eints can be set hardware-wise to either level or edge
> > > triggered,
> > > but their flow handler is currently hard set to handle_edge_irq. I
> > > remember seeing a patch from the Openmoko guys somewhere indicating
> > > that this does not work at all with level irqs.
> > 
> > Sounds like something broken to me. Level-triggered interrupts need
> > different handling than edge-triggered handling and so different flow
> > handlers exist for them.
> > 
> > To make my doubts clear, this is how I'm seeing the hardware on 2412:
> >   edge or level triggered     level triggered
> >   
> >        |   ___________________   |   ________________
> > 
> > EINT0 --> | EINT0   EINT0PEND | --> | IRQ0   ARM_INT | --> to the ARM
> > core
> > 
> > EINT1 --> | EINT1   EINT1PEND | --> | IRQ1           |
> > 
> > EINT2 --> | EINT2   EINT2PEND | --> | IRQ2           |
> > 
> > EINT3 --> | EINT3   EINT3PEND | --> | IRQ3           |
> > 
> >           |___________________|     |________________|
> >           |
> >              GPIO controller       Interrupt controller
> > 
> > Now EINT0-EINT3 signals of the GPIO controller are directly driven
> > with
> > external interrupt signals, either edge or level triggered, but the
> > interrupt status is latched in EINT0PEND-EINT3PEND bits inside the
> > GPIO
> > controller and state of those bits is exported through
> > EINT0PEND-EINT3PEND signals to the interrupt controller's IRQ0-IRQ3
> > signals, which are now level-triggered, since the interrupt is active
> > only when EINTxPEND bit is high.
> > 
> > Now, if my vision is wrong, and the hardware has simply EINT0-EINT3
> > pins routed to IRQ0-IRQ3 signals of the interrupt controller, then
> > what you're saying is completely right. In this case just ignore my
> > moaning. ;)
> I know the s3c2412 only in theory myself and am just going with the old
> code
> :-) . So all the irq rework stuff I did was only done on a theoretical
> :level
> for s3c2412, so I don't really know if the current irq code runs for
> sure there.
> 
> But when looking at the real old code that must have run sucessfully at
> some point in the past [0], the comment says
> 
> "the s3c2412 changes the behaviour of IRQ_EINT0 through IRQ_EINT3 by
>  having them turn up in both the INT* and the EINT* registers. Whilst
>  both show the status, they both now need to be acked when the IRQs
>  go off."
> 
> And then simply doing a
> 	__raw_writel(bitval, S3C2412_EINTPEND);
> 	__raw_writel(bitval, S3C2410_SRCPND);
> 	__raw_writel(bitval, S3C2410_INTPND);
> there - which is essentially the same that happens in the current
> pinctrl ack code.
> 
> So if we assume the really old code worked at some point, I'm relativly
> sure the new one will too :-). I'll just exchange the mask ordering in
> s3c2412_eint0_3_mask, to match the ordering in the original function.

Still, the old code seems to support only edge-triggered interrupts and 
this might be why it's working. I guess we won't know that without testing 
it on a S3C2412, though.

OK, it should be fine to keep the old behavior for now, but I think this 
is something that should be investigated in future and, if needed, fixed 
with another patch.

Btw. I wonder if I can get somewhere a board with S3C2412. Such board 
would be really useful for testing any of my patches touching plat-samsung 
and mach-s3c* on s3c24xx, as currently I can only test on s3c6410.

Best regards,
Tomasz

> 
> Heiko
> 
> 
> [0]
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arc
> h/arm/mach- s3c24xx/irq-s3c2412.c


From tony at atomide.com  Wed Apr 10 16:21:21 2013
From: tony at atomide.com (Tony Lindgren)
Date: Wed, 10 Apr 2013 13:21:21 -0700
Subject: [RFC][PATCH 1/2] ARM: OMAP4: clock: Add device tree support
 for AUXCLKs
In-Reply-To: <CAGo_u6rqN6YFQ6vX87-Cg28RbiR9UU2JHgLecOU5Nd=B5XPUEA@mail.gmail.com>
References: <20130405155851.GA10155@atomide.com> <5163E589.1040809@ti.com>
 <20130409164928.GL10155@atomide.com>
 <20130409174319.GP10155@atomide.com> <20130409204900.GA8815@kahuna>
 <20130410080630.14359.68178@quantum> <5165453E.6090503@ti.com>
 <20130410173921.GA31017@kahuna>
 <20130410184919.GJ10155@atomide.com>
 <CAGo_u6rqN6YFQ6vX87-Cg28RbiR9UU2JHgLecOU5Nd=B5XPUEA@mail.gmail.com>
Message-ID: <20130410202121.GM10155@atomide.com>

* Nishanth Menon <nm at ti.com> [130410 12:23]:
> On Wed, Apr 10, 2013 at 1:49 PM, Tony Lindgren <tony at atomide.com> wrote:
> >
> > We can avoid the concern of storing the struct clk * and do the
> > look up lazily on consumer driver probe by setting a dummy struct
> > clk * here. Then replace of_clk_src_simple_get() with a custom
> > omap_clk_src_get() that does the lookup and replaces the struct
> > clk * with the real one.
> Hmm.. this is interesting. will give it a try. Thanks on the suggestion.

Setting the struct clk * to NULL initially might work too, but that
needs to be checked.

Regards,

Tony


From tony at atomide.com  Wed Apr 10 16:26:53 2013
From: tony at atomide.com (Tony Lindgren)
Date: Wed, 10 Apr 2013 13:26:53 -0700
Subject: [PATCH v2] ARM: OMAP4: hwmod data: make
 'ocp2scp_usb_phy_phy_48m" as the main clock (fwd)
In-Reply-To: <alpine.DEB.2.00.1304101941550.25123@utopia.booyaka.com>
References: <alpine.DEB.2.00.1304101941550.25123@utopia.booyaka.com>
Message-ID: <20130410202653.GN10155@atomide.com>

* Paul Walmsley <paul at pwsan.com> [130410 12:48]:
> 
> Hi Tony,
> 
> could you send this one upstream for v3.9-rc fixes?  Should prevent 
> a MUSB regression in v3.9, mostly due to my own incompetence.

Thanks will do, applying into omap-for-v3.9-rc6/fixes.

Regards,

Tony


From swarren at wwwdotorg.org  Wed Apr 10 16:29:17 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Wed, 10 Apr 2013 14:29:17 -0600
Subject: [PATCH 3/5] gpio/omap: Add DT support to GPIO driver
In-Reply-To: <CACRpkdYbs4-uudpRUY8e+7icYYkZrfM0kReP3pLL5DMiURJ4dg@mail.gmail.com>
References: <1329321854-24490-1-git-send-email-b-cousson@ti.com>
 <1329321854-24490-4-git-send-email-b-cousson@ti.com>
 <4F44FA56.7020000@gmail.com> <4F44FC37.2000701@ti.com>
 <4F452484.5080503@gmail.com>
 <74CDBE0F657A3D45AFBB94109FB122FF17BD8BC6C1@HQMAIL01.nvidia.com>
 <4F47AD08.4030504@ti.com>
 <CAAwP0s0cB368R2mtbJpTZJreR-5GSRLfxC+8DJLo5nw3_OwBuA@mail.gmail.com>
 <512D39DA.7020306@ti.com> <512D3AB1.1080202@wwwdotorg.org>
 <512D3EC2.6050408@ti.com> <20130302200524.D230F3E1571@localhost>
 <51391F41.5000303@ti.com>
 <CAAwP0s1CFRO-rf==p5sYs1n0gigMif7wuT8Yv0N_iLUDMrtcOg@mail.gmail.com>
 <CACRpkdYHj-rEF3Rk_CWnmmMw_Amr7m8SgQ=-2zsDYuLeuu3azw@mail.gmail.com>
 <514C79E1.4090106@wwwdotorg.org> <514CE0AB.6060207@ti.com>
 <CACRpkdZmv-rAoKSQYpkHHSMzKJOn5TixVW_P3=m7ZNagBYCUPw@mail.gmail.com>
 <515319D5.20105@wwwdotorg.org>
 <CACRpkdYXVLgCz1Tyu-Ls2V2OTc4R3cGNJhfQJB6Hiz_K9dkZYQ@mail.gmail.com>
 <5155C902.7080207@wwwdotorg.org>
 <CACRpkdYbs4-uudpRUY8e+7icYYkZrfM0kReP3pLL5DMiURJ4dg@mail.gmail.com>
Message-ID: <5165CB9D.1090202@wwwdotorg.org>

On 04/10/2013 12:12 PM, Linus Walleij wrote:
> On Fri, Mar 29, 2013 at 6:01 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
>> On 03/27/2013 02:55 PM, Linus Walleij wrote:
>>> On Wed, Mar 27, 2013 at 5:09 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
>>>
>>> This is the case for some SMSC911x clients like the snowball
>>> routing it to a GPIO, whereas I think the RealView and Integrator/CP
>>> has a dedicated IRQ line for it on the FPGA so it's a good example.
>>>
>>> In such cases the right thing to do is for the platform
>>> code populating the platform data with the int irq field, or device tree
>>> core, or whatever piece of code that knows about
>>> the actual GPIO shall start from the GPIO, request it and
>>> then convert it to an IRQ.
>>
>> So board code could easily do that; plenty of opportunity to put
>> whatever custom code is needed right there.
>>
>> For DT core code to do that, we'd need some alternative way of
>> specifying interrupts. That would change the DT bindings for interrupts.
>> I don't think we can do that...
> 
> Sorry, I'm probably not knowledgeable about DT to understand this.
> The information for what GPIO corresponds to what IRQ is
> present in the device tree, is it not?

No, I don't think so. DT treats the IRQ and GPIO numbering spaces as
entirely unrelated things, just like the kernel APIs do.

The fact that some DT nodes (device/drivers) happen to be both GPIO and
IRQ providers (implement gpio_chip and irq_chip) and happen to use the
same numbering scheme for both GPIO and IRQ IDs is purely an
implementation detail within individual drivers (or rather, of specific
DT binding definitions really), and not a general truism.

> If the information is there, whether to convert from IRQ to GPIO
> or from GPIO to IRQ is a technicality and any order should be
> feasible in some way?

There isn't always a unique 1:1 mapping between GPIOs and IRQs. Put
another way, a single GPIO would likely only ever trigger a single IRQ,
but a single IRQ might easily be triggered by any number of GPIOs. This
is exactly why the function irq_to_gpio() isn't something one should use
any more. I think there was an effort to outright remove the API,
although it doesn't look like that's entirely complete yet. I guess you
know this given your mentions of problem with gpio_to_irq() later on, so
I'm not quite sure what your paragraph above was supposed to mean.

> I just can't get the necessity to do it one way preferred over the
> other through my head, sorry...
> 
>>> If it seems like identical boilerplate in every machine we can
>>> simply centralize it to gpiolib. Something like
>>>
>>> int gpio_add_single_irq_resource(struct platform_device *pdev, int
>>> gpio, unsigned flags)
>> ... [code to convert GPIO to IRQ and create IORESOURCE_IRQ from it]
>>
>>> int gpio_populate_irq_resource(struct platform_device *pdev, int gpio,
>>>                               unsigned flags, struct resource *r)
>> ... [code to create IORESOURCE_IRQ from the IRQ]
>>
>> ...
>>> gpio_populate_irq_resource(&ethernet, 17,
>>>      IORESOURCE_IRQ_HIGHEDGE, &ethernet_res[1]);
>>> platform_device_register(&ethernet);
>>>
>>> That populates the device with the single GPIO IRQ from
>>> the GPIO number in a smooth way.
>>>
>>> Of course it has to be done after the GPIO driver is up
>>> and running so may require some other refactoring,
>>> but it should work.
>>
>> That latter issue also somewhat scuppers this approach; then you have to
>> somehow run a bunch of your board file code inter-mixed with various
>> driver probe() calls. That will quickly get nasy.
> 
> No, just use a module_init() for the above code in the board
> file and it will defer just like any other initcall.

Using initcalls to order things is rather fragile. Perhaps it could work
out OK with board files, but it's certainly something that's frowned
upon now for DT-based systems, since deferred probe solves it much more
generally, and without any maintenance issues (e.g. continual
re-shuffling of the initcall order, not having enough initcall levels if
you end up with more dependencies being added, etc.).

>> And it doesn't address how the DT core will know when to call
>> gpio_add_single_irq_resource() vs. gpio_populate_irq_resource() without
>> changing the DT binding for interrupts.
> 
> Is it not possible to do this in
> drivers/gpio/gpiolib-of.c: of_gpiochip_add(), if the DT *know*
> which GPIOs will be used as plain IRQs? That is the point with
> the gpio hogs I talk about ...

I suppose that if you modified the device tree bindings (schema
definitions), you could have every GPIO provider DT node indicate which
GPIOs were used as IRQs instead. However,

a) This would be an incompatible change to the DT bindings, and they're
supposed to be a stable ABI; old DTBs should work unmodified with new
kernels.

b) This would place GPIO usage information in multiple places. Right
now, GPIO consumers list which GPIO(s) they use. The same goes for IRQs.
If a GPIO provider started listing which GPIOs were really IRQs, then
that'd mean configuring each GPIO-as-an-IRQ in two places; once in the
client node to indicate which IRQ it should hook/register, and once in
the provider node to indicate that the GPIO is really an IRQ. Two places
is more hassle for people to implement, and more opportunity for mistakes.


From tony at atomide.com  Wed Apr 10 16:34:09 2013
From: tony at atomide.com (Tony Lindgren)
Date: Wed, 10 Apr 2013 13:34:09 -0700
Subject: Query on pinctrl usage for DT nodes
In-Reply-To: <5165A22B.4070200@wwwdotorg.org>
References: <CA+V-a8uiPwsAD--OHFAE=i2ed+-wbXm4p2deZXr92+Zv6GDS1w@mail.gmail.com>
 <515C5C76.3080009@wwwdotorg.org>
 <CA+V-a8t3wtP77DdeUoQHKMjAuWmV+ude+1J3UjJmMTqobgStjA@mail.gmail.com>
 <5162FD4A.1030909@wwwdotorg.org>
 <CA+V-a8vwdCkyMqiynj5BodXbjwJ=e4qNb-29FhLweqbjc7DBQA@mail.gmail.com>
 <5165A22B.4070200@wwwdotorg.org>
Message-ID: <20130410203408.GP10155@atomide.com>

* Stephen Warren <swarren at wwwdotorg.org> [130410 10:37]:
> On 04/10/2013 02:12 AM, Prabhakar Lad wrote:
> ...
> > Following is the proposed fix/hack let me know if its OK.
> > 
> > Regards,
> > --Prabhakar
> > 
> > ->>>>>>>>>>>>>>>>>>>
> > 
> > diff --git a/drivers/pinctrl/core.h b/drivers/pinctrl/core.h
> > index ee72f1f..78fb42d 100644
> > --- a/drivers/pinctrl/core.h
> > +++ b/drivers/pinctrl/core.h
> > @@ -46,6 +46,7 @@ struct pinctrl_dev {
> >         struct pinctrl *p;
> >         struct pinctrl_state *hog_default;
> >         struct pinctrl_state *hog_sleep;
> > +       bool bits_per_mux;
> 
> This clearly isn't correct; any change to solve this problem should only
> touch the internals of the pinctrl-single driver, not the pinctrl core.

Yeah how about just change the pintctrl-single,bits register
naming to be register + bit?  Something like 0xdeadbeef.0 and
0xdeadbeef.1 and so on.

Regards,

Tony


From heiko at sntech.de  Wed Apr 10 16:42:52 2013
From: heiko at sntech.de (Heiko =?iso-8859-1?q?St=FCbner?=)
Date: Wed, 10 Apr 2013 22:42:52 +0200
Subject: [PATCH] pinctrl: Add pinctrl-s3c24xx driver
In-Reply-To: <1454321.I0NHk7e3H9@flatron>
References: <201304100135.12471.heiko@sntech.de>
 <201304102211.03870.heiko@sntech.de> <1454321.I0NHk7e3H9@flatron>
Message-ID: <201304102242.52958.heiko@sntech.de>

Am Mittwoch, 10. April 2013, 22:17:43 schrieb Tomasz Figa:
> On Wednesday 10 of April 2013 22:11:03 Heiko St?bner wrote:
> > Am Mittwoch, 10. April 2013, 21:51:11 schrieb Tomasz Figa:
> > > On Wednesday 10 of April 2013 15:45:48 Heiko St?bner wrote:
> > > > Am Mittwoch, 10. April 2013, 14:31:29 schrieb Tomasz Figa:
> > > > > On Wednesday 10 of April 2013 14:20:22 Heiko St?bner wrote:
> > > > > > Hi Tomasz,
> > > > > > 
> > > > > > thanks for your comments, more inline.
> > > > > > 
> > > > > > Am Mittwoch, 10. April 2013, 12:36:39 schrieb Tomasz Figa:
> > > > > > > Hi Heiko,
> > > > > > > 
> > > > > > > Basically looks good to me, but please see my inline comments
> > > > > > > about
> > > > > > > handling of EINT0-3.
> > > > > > > 
> > > > > > > On Wednesday 10 of April 2013 01:35:12 Heiko St?bner wrote:
> > > > > > > > The s3c24xx pins follow a similar pattern as the other
> > > > > > > > Samsung
> > > > > > > > SoCs
> > > > > > > > and
> > > > > > > > can therefore reuse the already introduced infrastructure.
> > > > > > 
> > > > > > [...]
> > > > > > 
> > > > > > > > +struct s3c24xx_eint_data {
> > > > > > > > +	struct samsung_pinctrl_drv_data *drvdata;
> > > > > > > > +	struct irq_domain *domains[NUM_EINT];
> > > > > > > > +	int parents[NUM_EINT_IRQ];
> > > > > > > > +};
> > > > > > > > +
> > > > > > > > +struct s3c24xx_eint_domain_data {
> > > > > > > > +	struct samsung_pin_bank *bank;
> > > > > > > > +	struct s3c24xx_eint_data *eint_data;
> > > > > > > 
> > > > > > > What about:
> > > > > > > 
> > > > > > > +	bool eint0_3_parent_only;
> > > > > > > 
> > > > > > > (or whatever name would be more appropriate), which would
> > > > > > > store
> > > > > > > the
> > > > > > > information about the s3c24xx-specific quirk in 24xx-specific
> > > > > > > data
> > > > > > > structure, without the need to add another field to the
> > > > > > > generic
> > > > > > > samsung_pinctrl_drv_data structure?
> > > > > > > 
> > > > > > > See my further comments on how I would see using this field in
> > > > > > > interrupt handling code.
> > > > > > 
> > > > > > ok, sounds good, especially gathering the type from the
> > > > > > wakeup-int
> > > > > > property
> > > > > > 
> > > > > > > > +};
> > > > > > 
> > > > > > [...]
> > > > > > 
> > > > > > > Now I would split the following 3 functions into two sets of 3
> > > > > > > functions, one set for s3c2412 and other for remaining SoCs
> > > > > > > and
> > > > > > > make
> > > > > > > separate EINT0-3 IRQ chips for both cases.
> > > > > > 
> > > > > > Not doing the decision every time, might bring some very slight
> > > > > > speed
> > > > > > improvements, so is probably the right way to go.
> > > > > > 
> > > > > > > > +
> > > > > > > > +static void s3c24xx_eint0_3_ack(struct irq_data *data)
> > > > > > > > +{
> > > > > > > > +	struct samsung_pin_bank *bank =
> > > > > > > > irq_data_get_irq_chip_data(data);
> > > > > > > > +	struct samsung_pinctrl_drv_data *d = bank->drvdata;
> > > > > > > > +	struct s3c24xx_eint_domain_data *ddata = bank->irq_domain-
> > > > > > > >
> > > > > > > >host_data;
> > > > > > > >
> > > > > > > > +	struct s3c24xx_eint_data *eint_data = ddata->eint_data;
> > > > > > > > +	int parent_irq = eint_data->parents[data->hwirq];
> > > > > > > > +	struct irq_chip *parent_chip = irq_get_chip(parent_irq);
> > > > > > > > +
> > > > > > > > +	if (d->ctrl->type == S3C2412) {
> > > > > > > > +		unsigned long bitval = 1UL << data->hwirq;
> > > > > > > > +		writel(bitval, d->virt_base + EINTPEND_REG);
> > > > > > > > +	}
> > > > > > > > +
> > > > > > > > +	if (parent_chip->irq_ack)
> > > > > > > > +		parent_chip-
> > > >
> > > >irq_ack(irq_get_irq_data(parent_irq));
> > > >
> > > > > > > Btw. Is this parent level acking really needed here?
> > > > > > 
> > > > > > Depends. If using chained_irq_* of course not, but if the
> > > > > > irq-handler
> > > > > > should stay in charge of when to ack it might be better this
> > > > > > way.
> > > > > > 
> > > > > > Generic s3c24xx SoCs need acking in the main controller only,
> > > > > > while
> > > > > > s3c2412 needs acking in both the main controller and eintpend.
> > > > > > 
> > > > > > > > +}
> > > > > > 
> > > > > > [...]
> > > > > > 
> > > > > > > > +static void s3c24xx_demux_eint0_3(unsigned int irq, struct
> > > > > > > > irq_desc
> > > > > > > > *desc) +{
> > > > > > > > +	struct irq_data *data = irq_desc_get_irq_data(desc);
> > > > > > > > +	struct s3c24xx_eint_data *eint_data =
> > > > > > > > irq_get_handler_data(irq);
> > > > > > > > +	unsigned int virq;
> > > > > > > > +
> > > > > > > 
> > > > > > > Instead of acking the interrupt at parent chip from ack
> > > > > > > callback
> > > > > > > of
> > > > > > > EINT0_3 chip, I would rather use chained_irq_enter() here...
> > > > > > > 
> > > > > > > > +	/* the first 4 eints have a simple 1 to 1 mapping */
> > > > > > > > +	virq = irq_linear_revmap(eint_data->domains[data->hwirq],
> > > > > > > > data->hwirq); +	/* Something must be really wrong if an
> > > 
> > > unmapped
> > > 
> > > > > > > EINT
> > > > > > > 
> > > > > > > > +	 * was unmasked...
> > > > > > > > +	 */
> > > > > > > > +	BUG_ON(!virq);
> > > > > > > > +
> > > > > > > > +	generic_handle_irq(virq);
> > > > > > > 
> > > > > > > ...and chained_irq_exit() here.
> > > > > > 
> > > > > > If I understand it correctly, the way chained_irq_* works it
> > > > > > would
> > > > > > limit the eints to a level style handling. With the way it's
> > > > > > currently the whole determination of when to ack,mask and unmask
> > > > > > is
> > > > > > completely for the real handler (edge or level) to decide, as
> > > > > > the
> > > > > > original interrupt gets completely forwarded into the irq-domain
> > > > > > without further
> > > > > > constraints.
> > > > > > 
> > > > > > So, after the change on regular s3c24xx SoCs when the real irq
> > > > > > handler
> > > > > > wants to ack the irq, it would be a no-op, as it would already
> > > > > > have
> > > > > > been acked by chained_irq_enter.
> > > > > > 
> > > > > > Masking might be even more interesting. Currently control is
> > > > > > transfered
> > > > > > completely to the pinctrl irq-domain, which then controls the
> > > > > > masking of the interrupt thru the parent-calls - on regular
> > > > > > s3c24xx
> > > > > > the masking of these is also only done in the main controller.
> > > > > > 
> > > > > > When using chained_irq_* it also wants to mask the interrupt
> > > > > > which
> > > > > > might conflict with regular enable_irq/disable_irq calls being
> > > > > > done
> > > > > > for example in driver code.
> > > > > > 
> > > > > > 
> > > > > > So in short I agree with the earlier split of the irqchip, but
> > > > > > would
> > > > > > keep the irq operations themself centralized in the pinctrl
> > > > > > driver,
> > > > > > instead of using chained_irq_* functions.
> > > > > 
> > > > > Right, my solution wouldn't work properly in case of regular
> > > > > s3c24xx
> > > > > and edge triggered interrupts.
> > > > > 
> > > > > However I'm still wondering if it's OK to manually call parent
> > > > > chip
> > > > > operations in case of s3c2416. This would imply the same operation
> > > > > calling order as imposed by flow handler of the chained EINT
> > > > > (which
> > > > > can be handle_edge_irq), while the parent chip is probably level
> > > > > triggered, isn't it?
> > > > 
> > > > I think imposing the same calling order is the right way to go :-) .
> > > > 
> > > > The eints can be set hardware-wise to either level or edge
> > > > triggered,
> > > > but their flow handler is currently hard set to handle_edge_irq. I
> > > > remember seeing a patch from the Openmoko guys somewhere indicating
> > > > that this does not work at all with level irqs.
> > > 
> > > Sounds like something broken to me. Level-triggered interrupts need
> > > different handling than edge-triggered handling and so different flow
> > > handlers exist for them.
> > > 
> > > To make my doubts clear, this is how I'm seeing the hardware on 2412:
> > >   edge or level triggered     level triggered
> > >   
> > >        |   ___________________   |   ________________
> > > 
> > > EINT0 --> | EINT0   EINT0PEND | --> | IRQ0   ARM_INT | --> to the ARM
> > > core
> > > 
> > > EINT1 --> | EINT1   EINT1PEND | --> | IRQ1           |
> > > 
> > > EINT2 --> | EINT2   EINT2PEND | --> | IRQ2           |
> > > 
> > > EINT3 --> | EINT3   EINT3PEND | --> | IRQ3           |
> > > 
> > >           |___________________|     |________________|
> > >           |
> > >              GPIO controller       Interrupt controller
> > > 
> > > Now EINT0-EINT3 signals of the GPIO controller are directly driven
> > > with
> > > external interrupt signals, either edge or level triggered, but the
> > > interrupt status is latched in EINT0PEND-EINT3PEND bits inside the
> > > GPIO
> > > controller and state of those bits is exported through
> > > EINT0PEND-EINT3PEND signals to the interrupt controller's IRQ0-IRQ3
> > > signals, which are now level-triggered, since the interrupt is active
> > > only when EINTxPEND bit is high.
> > > 
> > > Now, if my vision is wrong, and the hardware has simply EINT0-EINT3
> > > pins routed to IRQ0-IRQ3 signals of the interrupt controller, then
> > > what you're saying is completely right. In this case just ignore my
> > > moaning. ;)
> > 
> > I know the s3c2412 only in theory myself and am just going with the old
> > code
> > 
> > :-) . So all the irq rework stuff I did was only done on a theoretical
> > :level
> > 
> > for s3c2412, so I don't really know if the current irq code runs for
> > sure there.
> > 
> > But when looking at the real old code that must have run sucessfully at
> > some point in the past [0], the comment says
> > 
> > "the s3c2412 changes the behaviour of IRQ_EINT0 through IRQ_EINT3 by
> > 
> >  having them turn up in both the INT* and the EINT* registers. Whilst
> >  both show the status, they both now need to be acked when the IRQs
> >  go off."
> > 
> > And then simply doing a
> > 
> > 	__raw_writel(bitval, S3C2412_EINTPEND);
> > 	__raw_writel(bitval, S3C2410_SRCPND);
> > 	__raw_writel(bitval, S3C2410_INTPND);
> > 
> > there - which is essentially the same that happens in the current
> > pinctrl ack code.
> > 
> > So if we assume the really old code worked at some point, I'm relativly
> > sure the new one will too :-). I'll just exchange the mask ordering in
> > s3c2412_eint0_3_mask, to match the ordering in the original function.
> 
> Still, the old code seems to support only edge-triggered interrupts and
> this might be why it's working. I guess we won't know that without testing
> it on a S3C2412, though.
> 
> OK, it should be fine to keep the old behavior for now, but I think this
> is something that should be investigated in future and, if needed, fixed
> with another patch.

Ok, I'll prepare another patch with the other proposed changes.


> Btw. I wonder if I can get somewhere a board with S3C2412. Such board
> would be really useful for testing any of my patches touching plat-samsung
> and mach-s3c* on s3c24xx, as currently I can only test on s3c6410.

Personally I found the S3C2412-based Logitech Squeezebox Controller [0] quite 
intriguing some time ago. And if only s3c24xx instead of s3c2412 is mandatory, 
there should also still be quite a lot of s3c2416/2450 based ebook-readers 
around [1] :-) .


Heiko

[0] http://wiki.slimdevices.com/index.php/Squeezebox_Controller
[1] http://www.youtube.com/mmind81


> > Heiko
> > 
> > 
> > [0]
> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arc
> > h/arm/mach- s3c24xx/irq-s3c2412.c



From mans at mansr.com  Wed Apr 10 16:46:50 2013
From: mans at mansr.com (=?iso-8859-1?Q?M=E5ns_Rullg=E5rd?=)
Date: Wed, 10 Apr 2013 21:46:50 +0100
Subject: Removal of NWFPE in its entirety, and VFP emulation code
In-Reply-To: <20130410200344.GO14496@n2100.arm.linux.org.uk> (Russell King's
 message of "Wed, 10 Apr 2013 21:03:44 +0100")
References: <20130410104002.GF14496@n2100.arm.linux.org.uk>
 <yw1xmwt68whw.fsf@unicorn.mansr.com>
 <20130410114229.GH14496@n2100.arm.linux.org.uk>
 <yw1xip3u8uni.fsf@unicorn.mansr.com>
 <20130410185421.GI14496@n2100.arm.linux.org.uk>
 <yw1xehei8a19.fsf@unicorn.mansr.com>
 <20130410200344.GO14496@n2100.arm.linux.org.uk>
Message-ID: <yw1x61zu866d.fsf@unicorn.mansr.com>

Russell King - ARM Linux <linux at arm.linux.org.uk> writes:

> On Wed, Apr 10, 2013 at 08:23:30PM +0100, M?ns Rullg?rd wrote:
>> Russell King - ARM Linux <linux at arm.linux.org.uk> writes:
>> 
>> > On Wed, Apr 10, 2013 at 12:58:09PM +0100, M?ns Rullg?rd wrote:
>> >> Russell King - ARM Linux <linux at arm.linux.org.uk> writes:
>> >> 
>> >> > On Wed, Apr 10, 2013 at 12:18:19PM +0100, M?ns Rullg?rd wrote:
>> >> >> Russell King - ARM Linux <linux at arm.linux.org.uk> writes:
>> >> >> 
>> >> >> > The situation with VFP is likely less disruptive - only instructions
>> >> >> > which aren't implemented in hardware (or, for example, if you ask for
>> >> >> > inexact exceptions to be enabled) which are bounced to the software
>> >> >> > support code will be affected.  I think OMAP should get away unscathed,
>> >> >> > but ARM's implementation will bounce if inexact exceptions are enabled
>> >> >> 
>> >> >> What do you mean by this?  OMAP uses ARM's cores.
>> >> >
>> >> > OMAP's VFP reports that it never traps to support code for VFP instructions,
>> >> > so the emulation code is never used on OMAP.
>> >> 
>> >> That is true for OMAP2 (ARM1136/VFP11) and OMAP3 (Cortex-A8).  OMAP4
>> >> (Cortex-A9) and OMAP5 (Cortex-A15) both trap on vector operations.
>> >
>> > No.  Both OMAP3 and OMAP4 report that they are VFP subarchitecture 3,
>> > and the VFP subarchitecture 3 never traps to support code for any
>> > instruction (it's the "null subarchitecture" value.)
>> 
>> VFPv3 does not require hardware support for vector operations, and the
>> Cortex-A9 NEON TRM [1] says this:
>>
>>    ARMv7 deprecates the use of VFP vector mode. The Cortex-A9 NEON MPE
>>    hardware does not support VFP vector operations. [...] The Cortex-A9
>>    NEON MPE provides high speed VFP operation without support code.
>>    However, if an application requires VFP vector operation, then it
>>    must use support code.
>> 
>> [1] http://infocenter.arm.com/help/topic/com.arm.doc.ddi0409i/CHDEEJDB.html
>> 
>> The VFP-only TRM [2] contains similar language:
>> 
>>   The use of VFP vector mode is deprecated in ARMv7.  Vector operations
>>   are not supported in hardware.  If you use vectors, support code is
>>   required.
>> 
>> [2] http://infocenter.arm.com/help/topic/com.arm.doc.ddi0408i/I1019986.html
>> 
>> The Cortex-A15 TRM [3] follows suit:
>> 
>>   Vector operations are not supported.  Any attempt to execute a vector
>>   operation results in an Undefined Instruction exception.  If an
>>   application requires VFP vector operation, then it must use VFP
>>   support code.
>> 
>> [3] http://infocenter.arm.com/help/topic/com.arm.doc.ddi0438h/CEGCDBHC.html
>> 
>> In future, if you checked the relevant documentation before making bold
>> claims, you might avoid making a fool of yourself.
>
> Oh fuck off, just really fuck off you total dickface.  Really, do you
> think that I, being the one who created the VFP support code, haven't
> read the VFP documentation?  Christ, you are fucking thick.

I'll ignore the insults for now, but you really should consider watching
your tone if you want to be taken seriously.

> Subarchitecture, bits [22:16]
> 0b0000011
> VFP architecture v3 or later with Null subarchitecture. The entire floating-point
> implementation is in hardware, and no software support code is required. The
> VFP architecture version is indicated by the MVFR0 and MVFR1 registers.
> This value can be used only by an implementation that does not support the trap
> enable bits in the FPSCR, see Floating-point Status and Control Register
> (FPSCR) on page A2-28.

This means merely that the implementation never traps on things like
denormal inputs or over/underflow.  It has nothing to do with vector
support.

Both the ARM ARM and the various TRMs make it abundantly clear that
vector operations are optional *and* that some of the cores do *not*
implement them in hardware.

I have also run code with vector operations on A9, and I assure you it
does trap.

> And both OMAP3 and OMAP4 report *this* subarchitecture version.  Maybe
> it's you who needs to take a reading lesson instead of making a prat of
> *yourself*.

Same subarchitecture, different variants.  

-- 
M?ns Rullg?rd
mans at mansr.com


From linus.walleij at linaro.org  Wed Apr 10 16:47:04 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Wed, 10 Apr 2013 22:47:04 +0200
Subject: [PATCH 4/5] gpio/omap: force restore if context loss is not
 detectable
In-Reply-To: <5165C27E.1060704@ti.com>
References: <1365106576-31816-1-git-send-email-jon-hunter@ti.com>
 <1365106576-31816-5-git-send-email-jon-hunter@ti.com>
 <CACRpkdbeABuFXr0Gt6gRto3Pmo0m88AFn_xKJq14VonGg7Doww@mail.gmail.com>
 <5165C086.5010105@ti.com>
 <CACRpkdZciGZkWR-qxT96c9pO9UM4fPh_1BUJP9-b1fhjL6-uDg@mail.gmail.com>
 <5165C27E.1060704@ti.com>
Message-ID: <CACRpkdaA2gZBEG73jOgrXPcVW5rD-_SpXTw5z63Q_isWuz-YBg@mail.gmail.com>

On Wed, Apr 10, 2013 at 9:50 PM, Jon Hunter <jon-hunter at ti.com> wrote:
> On 04/10/2013 02:44 PM, Linus Walleij wrote:

>> All patches applied with Kevin's and Santosh's tags!
>
> Thanks. Sorry for the confusion!
>
> By the way, I am hoping you only took 1-4,

Yeah I only took 1-4, no problem...

Yours,
Linus Walleij


From linus.walleij at linaro.org  Wed Apr 10 16:59:39 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Wed, 10 Apr 2013 22:59:39 +0200
Subject: [PATCH 1/3] ARM: pxa: remove cpu_is_xxx in gpio driver
In-Reply-To: <1365556707-9159-1-git-send-email-haojian.zhuang@linaro.org>
References: <1365556707-9159-1-git-send-email-haojian.zhuang@linaro.org>
Message-ID: <CACRpkdbr=VT8g03S=KUMUReJe+6aU0n1Pfy2nk=XErKfYojwBw@mail.gmail.com>

On Wed, Apr 10, 2013 at 3:18 AM, Haojian Zhuang
<haojian.zhuang at linaro.org> wrote:

> Avoid to use cpu_is_xxx() in pxa gpio driver. Use platform_device_id
> to identify the difference.
>
> Signed-off-by: Haojian Zhuang <haojian.zhuang at linaro.org>

Acked-by: Linus Walleij <linus.walleij at linaro.org>

I guess this will go through some PXA/MMP tree?

Yours,
Linus Walleij


From linus.walleij at linaro.org  Wed Apr 10 17:01:27 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Wed, 10 Apr 2013 23:01:27 +0200
Subject: [PATCH 2/3] ARM: pxa: move PXA_GPIO_TO_IRQ macro
In-Reply-To: <1365556707-9159-2-git-send-email-haojian.zhuang@linaro.org>
References: <1365556707-9159-1-git-send-email-haojian.zhuang@linaro.org>
 <1365556707-9159-2-git-send-email-haojian.zhuang@linaro.org>
Message-ID: <CACRpkdYJqyhYRn-xQ_R1ca+4mHpJYQduRXPnj4pgQV+zK_EdOQ@mail.gmail.com>

On Wed, Apr 10, 2013 at 3:18 AM, Haojian Zhuang
<haojian.zhuang at linaro.org> wrote:

> Since PXA_GPIO_TO_IRQ() & MMP_GPIO_TO_IRQ() macro are depended on
> arch code, move them from gpio driver to platform driver instead.
>
> Signed-off-by: Haojian Zhuang <haojian.zhuang at linaro.org>

Acked-by: Linus Walleij <linus.walleij at linaro.org>

Yours,
Linus Walleij


From linus.walleij at linaro.org  Wed Apr 10 17:02:32 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Wed, 10 Apr 2013 23:02:32 +0200
Subject: [PATCH 3/3] ARM: mmp: add more compatible names in gpio driver
In-Reply-To: <1365556707-9159-3-git-send-email-haojian.zhuang@linaro.org>
References: <1365556707-9159-1-git-send-email-haojian.zhuang@linaro.org>
 <1365556707-9159-3-git-send-email-haojian.zhuang@linaro.org>
Message-ID: <CACRpkdYbjZOWgTb=hV5eM6WUU0ZL35ubW4TVBN6JxCxgU6uj9w@mail.gmail.com>

On Wed, Apr 10, 2013 at 3:18 AM, Haojian Zhuang
<haojian.zhuang at linaro.org> wrote:

> Since more driver names are added into platform id, do the same thing on
> compatible names for DT mode.
>
> Signed-off-by: Haojian Zhuang <haojian.zhuang at linaro.org>

Acked-by: Linus Walleij <linus.walleij at linaro.org>

Yours,
Linus Walleij


From linux at arm.linux.org.uk  Wed Apr 10 17:04:31 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Wed, 10 Apr 2013 22:04:31 +0100
Subject: Removal of NWFPE in its entirety, and VFP emulation code
In-Reply-To: <yw1x61zu866d.fsf@unicorn.mansr.com>
References: <20130410104002.GF14496@n2100.arm.linux.org.uk>
 <yw1xmwt68whw.fsf@unicorn.mansr.com>
 <20130410114229.GH14496@n2100.arm.linux.org.uk>
 <yw1xip3u8uni.fsf@unicorn.mansr.com>
 <20130410185421.GI14496@n2100.arm.linux.org.uk>
 <yw1xehei8a19.fsf@unicorn.mansr.com>
 <20130410200344.GO14496@n2100.arm.linux.org.uk>
 <yw1x61zu866d.fsf@unicorn.mansr.com>
Message-ID: <20130410210431.GQ14496@n2100.arm.linux.org.uk>

On Wed, Apr 10, 2013 at 09:46:50PM +0100, M?ns Rullg?rd wrote:
> Russell King - ARM Linux <linux at arm.linux.org.uk> writes:
> > Oh fuck off, just really fuck off you total dickface.  Really, do you
> > think that I, being the one who created the VFP support code, haven't
> > read the VFP documentation?  Christ, you are fucking thick.
> 
> I'll ignore the insults for now, but you really should consider watching
> your tone if you want to be taken seriously.

Really?  After you accused me of not reading the documentation?  What
planet are you on?  Planet lunacy?  *You* need to learn some bloody
respect.

> > Subarchitecture, bits [22:16]
> > 0b0000011
> > VFP architecture v3 or later with Null subarchitecture. The entire floating-point
> > implementation is in hardware, and no software support code is required. The
> > VFP architecture version is indicated by the MVFR0 and MVFR1 registers.
> > This value can be used only by an implementation that does not support the trap
> > enable bits in the FPSCR, see Floating-point Status and Control Register
> > (FPSCR) on page A2-28.
> 
> This means merely that the implementation never traps on things like
> denormal inputs or over/underflow.  It has nothing to do with vector
> support.

Wrong.  The VFP subarchitecture defines the interface between *VFP
hardware* and the *VFP support code*.  I suggest you read carefully the
chapter in the ARM ARM *before* you make any further comment, and make
yourself look any more a fool than you already do.


From linus.walleij at linaro.org  Wed Apr 10 17:10:56 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Wed, 10 Apr 2013 23:10:56 +0200
Subject: [PATCH] PM / Runtime: Idle devices asynchronously after
 probe|release
In-Reply-To: <1365605125-27538-1-git-send-email-ulf.hansson@stericsson.com>
References: <1365605125-27538-1-git-send-email-ulf.hansson@stericsson.com>
Message-ID: <CACRpkdYwuUJLRQPbd=nRfSONRxHuZNLuGt_fpp3jd4YWkgtMTA@mail.gmail.com>

On Wed, Apr 10, 2013 at 4:45 PM, Ulf Hansson <ulf.hansson at stericsson.com> wrote:

> From: Ulf Hansson <ulf.hansson at linaro.org>
>
> Putting devices into idle|suspend in a synchronous manner means we are
> waiting for each device to become idle|suspended before the probe|release
> is fully done.
>
> This patch switch to use the asynchronous runtime PM API:s instead and
> thus improves the parallelism since we can move on and handle the next
> device in queue in an earlier phase.
>
> Signed-off-by: Ulf Hansson <ulf.hansson at linaro.org>
> Cc: Kevin Hilman <khilman at linaro.org>
> Cc: Alan Stern <stern at rowland.harvard.edu>
> Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>

Looks correct to me.
Acked-by: Linus Walleij <linus.walleij at linaro.org>

Yours,
Linus Walleij


From mans at mansr.com  Wed Apr 10 17:18:42 2013
From: mans at mansr.com (=?iso-8859-1?Q?M=E5ns_Rullg=E5rd?=)
Date: Wed, 10 Apr 2013 22:18:42 +0100
Subject: Removal of NWFPE in its entirety, and VFP emulation code
In-Reply-To: <20130410210431.GQ14496@n2100.arm.linux.org.uk> (Russell King's
 message of "Wed, 10 Apr 2013 22:04:31 +0100")
References: <20130410104002.GF14496@n2100.arm.linux.org.uk>
 <yw1xmwt68whw.fsf@unicorn.mansr.com>
 <20130410114229.GH14496@n2100.arm.linux.org.uk>
 <yw1xip3u8uni.fsf@unicorn.mansr.com>
 <20130410185421.GI14496@n2100.arm.linux.org.uk>
 <yw1xehei8a19.fsf@unicorn.mansr.com>
 <20130410200344.GO14496@n2100.arm.linux.org.uk>
 <yw1x61zu866d.fsf@unicorn.mansr.com>
 <20130410210431.GQ14496@n2100.arm.linux.org.uk>
Message-ID: <yw1x1uai84p9.fsf@unicorn.mansr.com>

Russell King - ARM Linux <linux at arm.linux.org.uk> writes:

>> > Subarchitecture, bits [22:16]
>> > 0b0000011
>> > VFP architecture v3 or later with Null subarchitecture. The entire floating-point
>> > implementation is in hardware, and no software support code is required. The
>> > VFP architecture version is indicated by the MVFR0 and MVFR1 registers.
>> > This value can be used only by an implementation that does not support the trap
>> > enable bits in the FPSCR, see Floating-point Status and Control Register
>> > (FPSCR) on page A2-28.
>> 
>> This means merely that the implementation never traps on things like
>> denormal inputs or over/underflow.  It has nothing to do with vector
>> support.
>
> Wrong.  The VFP subarchitecture defines the interface between *VFP
> hardware* and the *VFP support code*.  I suggest you read carefully the
> chapter in the ARM ARM *before* you make any further comment, and make
> yourself look any more a fool than you already do.

Yet the A9 clearly does trap, just like the TRM says it should.  So
which is more likely, that the TRM and silicon are both wrong, or that
you are wrong?  Perhaps we should put it to a vote.

-- 
M?ns Rullg?rd
mans at mansr.com


From linus.walleij at linaro.org  Wed Apr 10 17:28:01 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Wed, 10 Apr 2013 23:28:01 +0200
Subject: [PATCH 3/5] gpio/omap: Add DT support to GPIO driver
In-Reply-To: <5165CB9D.1090202@wwwdotorg.org>
References: <1329321854-24490-1-git-send-email-b-cousson@ti.com>
 <1329321854-24490-4-git-send-email-b-cousson@ti.com>
 <4F44FA56.7020000@gmail.com> <4F44FC37.2000701@ti.com>
 <4F452484.5080503@gmail.com>
 <74CDBE0F657A3D45AFBB94109FB122FF17BD8BC6C1@HQMAIL01.nvidia.com>
 <4F47AD08.4030504@ti.com>
 <CAAwP0s0cB368R2mtbJpTZJreR-5GSRLfxC+8DJLo5nw3_OwBuA@mail.gmail.com>
 <512D39DA.7020306@ti.com> <512D3AB1.1080202@wwwdotorg.org>
 <512D3EC2.6050408@ti.com> <20130302200524.D230F3E1571@localhost>
 <51391F41.5000303@ti.com>
 <CAAwP0s1CFRO-rf==p5sYs1n0gigMif7wuT8Yv0N_iLUDMrtcOg@mail.gmail.com>
 <CACRpkdYHj-rEF3Rk_CWnmmMw_Amr7m8SgQ=-2zsDYuLeuu3azw@mail.gmail.com>
 <514C79E1.4090106@wwwdotorg.org> <514CE0AB.6060207@ti.com>
 <CACRpkdZmv-rAoKSQYpkHHSMzKJOn5TixVW_P3=m7ZNagBYCUPw@mail.gmail.com>
 <515319D5.20105@wwwdotorg.org>
 <CACRpkdYXVLgCz1Tyu-Ls2V2OTc4R3cGNJhfQJB6Hiz_K9dkZYQ@mail.gmail.com>
 <5155C902.7080207@wwwdotorg.org>
 <CACRpkdYbs4-uudpRUY8e+7icYYkZrfM0kReP3pLL5DMiURJ4dg@mail.gmail.com>
 <5165CB9D.1090202@wwwdotorg.org>
Message-ID: <CACRpkdYirFNqmGhA4K9CL4ve4NYhs8Rd3SFt1iwW9vHBkrcz8g@mail.gmail.com>

On Wed, Apr 10, 2013 at 10:29 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
> On 04/10/2013 12:12 PM, Linus Walleij wrote:

>> If the information is there, whether to convert from IRQ to GPIO
>> or from GPIO to IRQ is a technicality and any order should be
>> feasible in some way?
>
> There isn't always a unique 1:1 mapping between GPIOs and IRQs. Put
> another way, a single GPIO would likely only ever trigger a single IRQ,
> but a single IRQ might easily be triggered by any number of GPIOs. This
> is exactly why the function irq_to_gpio() isn't something one should use
> any more. I think there was an effort to outright remove the API,
> although it doesn't look like that's entirely complete yet. I guess you
> know this given your mentions of problem with gpio_to_irq() later on, so
> I'm not quite sure what your paragraph above was supposed to mean.

So the only reason I'm rambing on about this is that it breaks the
connection between GPIOs and their IRQs and at one point
I percieved it as there was going to be some IRQ -> GPIO lookup,
and it would sneak back in. But now I realize that may have been
supposed to be something local to the driver, in it's irqchip portions
and then it's actually no problem for the kernel at large.

Let's restate: I'm also after something fragile here.

IIUC, it will be possible for a GPIO to be set up as input and used
as an IRQ without the GPIO subsystem knowing it. And it will be
possible for the GPIO subsystem to go in and request the same pin
and set it as output and e.g. bit-bang it. I wonder what happens then.

If the drive code is written in such a way that this will be denied,
I'll soften up, but I'd like to see the code first.

Then the same mistake has to be avoided in all drivers.

And that makes me want to probe for solutions tying them
up in the core so no mistakes can be made.

>> Is it not possible to do this in
>> drivers/gpio/gpiolib-of.c: of_gpiochip_add(), if the DT *know*
>> which GPIOs will be used as plain IRQs? That is the point with
>> the gpio hogs I talk about ...
>
> I suppose that if you modified the device tree bindings (schema
> definitions), you could have every GPIO provider DT node indicate which
> GPIOs were used as IRQs instead. However,
>
> a) This would be an incompatible change to the DT bindings, and they're
> supposed to be a stable ABI; old DTBs should work unmodified with new
> kernels.
>
> b) This would place GPIO usage information in multiple places. Right
> now, GPIO consumers list which GPIO(s) they use. The same goes for IRQs.
> If a GPIO provider started listing which GPIOs were really IRQs, then
> that'd mean configuring each GPIO-as-an-IRQ in two places; once in the
> client node to indicate which IRQ it should hook/register, and once in
> the provider node to indicate that the GPIO is really an IRQ. Two places
> is more hassle for people to implement, and more opportunity for mistakes.

Yeah but the current approach AFAICT isn't exactly safe either.

So I need some more convincing... or code rather, I guess.
If I can't point out the problems I see in a piece of code I guess
I'm just plain wrong :-)

Yours,
Linus Walleij


From nico at fluxnic.net  Wed Apr 10 17:29:18 2013
From: nico at fluxnic.net (Nicolas Pitre)
Date: Wed, 10 Apr 2013 17:29:18 -0400 (EDT)
Subject: Removal of NWFPE in its entirety, and VFP emulation code
In-Reply-To: <yw1x1uai84p9.fsf@unicorn.mansr.com>
References: <20130410104002.GF14496@n2100.arm.linux.org.uk>
 <yw1xmwt68whw.fsf@unicorn.mansr.com>
 <20130410114229.GH14496@n2100.arm.linux.org.uk>
 <yw1xip3u8uni.fsf@unicorn.mansr.com>
 <20130410185421.GI14496@n2100.arm.linux.org.uk>
 <yw1xehei8a19.fsf@unicorn.mansr.com>
 <20130410200344.GO14496@n2100.arm.linux.org.uk>
 <yw1x61zu866d.fsf@unicorn.mansr.com>
 <20130410210431.GQ14496@n2100.arm.linux.org.uk>
 <yw1x1uai84p9.fsf@unicorn.mansr.com>
Message-ID: <alpine.LFD.2.03.1304101725280.17375@syhkavp.arg>

On Wed, 10 Apr 2013, M?ns Rullg?rd wrote:

> Yet the A9 clearly does trap, just like the TRM says it should.  So
> which is more likely, that the TRM and silicon are both wrong, or that
> you are wrong?  Perhaps we should put it to a vote.

Instead of encouraging the pissing contest, could you please provide 
compilable example code that would trap so that anyone can test and 
report results back?


Nicolas

From thomas.petazzoni at free-electrons.com  Wed Apr 10 17:30:59 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Wed, 10 Apr 2013 23:30:59 +0200
Subject: [PATCH v5 1/3] of/pci: Unify pci_process_bridge_OF_ranges from
 Microblaze and PowerPC
In-Reply-To: <51656592.7070806@gmail.com>
References: <1365578969-30966-1-git-send-email-Andrew.Murray@arm.com>
 <1365578969-30966-2-git-send-email-Andrew.Murray@arm.com>
 <51656592.7070806@gmail.com>
Message-ID: <20130410233059.5cdcc119@skate>

Ben, Michal,

On Wed, 10 Apr 2013 08:13:54 -0500, Rob Herring wrote:
> Adding Ben H and Michal...
> 
> On 04/10/2013 02:29 AM, Andrew Murray wrote:
> > The pci_process_bridge_OF_ranges function, used to parse the
> > "ranges" property of a PCI host device, is found in both Microblaze
> > and PowerPC architectures. These implementations are nearly
> > identical. This patch moves this common code to a common place.
> > 
> > Signed-off-by: Andrew Murray <Andrew.Murray at arm.com>
> > Signed-off-by: Liviu Dudau <Liviu.Dudau at arm.com>
> 
> One comment below. Otherwise,
> 
> Reviewed-by: Rob Herring <rob.herring at calxeda.com>
> 
> You need also need acks from Ben and Michal.

Ben, Michal, could you review/test this patch from Andrew Murray? I
need it as a dependency of "[PATCH v5 2/3] of/pci: Provide support for
parsing PCI DT ranges property", which itself is used by the Marvell
PCIe driver I'm hoping to get merged in 3.10.

Thanks a lot for your feedback,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From thomas.petazzoni at free-electrons.com  Wed Apr 10 17:33:30 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Wed, 10 Apr 2013 23:33:30 +0200
Subject: [PATCH v5 1/3] of/pci: Unify pci_process_bridge_OF_ranges from
 Microblaze and PowerPC
In-Reply-To: <1365578969-30966-2-git-send-email-Andrew.Murray@arm.com>
References: <1365578969-30966-1-git-send-email-Andrew.Murray@arm.com>
 <1365578969-30966-2-git-send-email-Andrew.Murray@arm.com>
Message-ID: <20130410233330.4e9479b0@skate>

Dear Andrew Murray,

On Wed, 10 Apr 2013 08:29:26 +0100, Andrew Murray wrote:

> diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
> index bb115de..6852481 100644
> --- a/include/linux/of_pci.h
> +++ b/include/linux/of_pci.h
> @@ -11,4 +11,7 @@ struct device_node;
>  struct device_node *of_pci_find_child_device(struct device_node *parent,
>  					     unsigned int devfn);
>  
> +void pci_process_bridge_OF_ranges(struct pci_controller *hose,
> +			struct device_node *dev, int primary);
> +
>  #endif

In this file, 'struct pci_controller' is not defined anywhere, and not
in any header file that is included. So I get a warning at compile time
when <linux/of_pci.h> is included, but nothing has defined 'struct
pci_controller' beforehand. So I think this file should carry a change
like:

+struct pci_controller;

In my version of the patch I added it, see:

diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
index bb115de..e56182f 100644
--- a/include/linux/of_pci.h
+++ b/include/linux/of_pci.h
@@ -4,6 +4,7 @@
 #include <linux/pci.h>
 
 struct pci_dev;
+struct pci_controller;
 struct of_irq;
 int of_irq_map_pci(const struct pci_dev *pdev, struct of_irq *out_irq);
 
@@ -11,4 +12,7 @@ struct device_node;
 struct device_node *of_pci_find_child_device(struct device_node *parent,
 					     unsigned int devfn);
 
+void pci_process_bridge_OF_ranges(struct pci_controller *hose,
+			struct device_node *dev, int primary);
+
 #endif

But otherwise, for PATCH 1/3 and 2/3,

Tested-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From mans at mansr.com  Wed Apr 10 17:39:18 2013
From: mans at mansr.com (=?iso-8859-1?Q?M=E5ns_Rullg=E5rd?=)
Date: Wed, 10 Apr 2013 22:39:18 +0100
Subject: Removal of NWFPE in its entirety, and VFP emulation code
In-Reply-To: <alpine.LFD.2.03.1304101725280.17375@syhkavp.arg> (Nicolas
 Pitre's message of "Wed, 10 Apr 2013 17:29:18 -0400 (EDT)")
References: <20130410104002.GF14496@n2100.arm.linux.org.uk>
 <yw1xmwt68whw.fsf@unicorn.mansr.com>
 <20130410114229.GH14496@n2100.arm.linux.org.uk>
 <yw1xip3u8uni.fsf@unicorn.mansr.com>
 <20130410185421.GI14496@n2100.arm.linux.org.uk>
 <yw1xehei8a19.fsf@unicorn.mansr.com>
 <20130410200344.GO14496@n2100.arm.linux.org.uk>
 <yw1x61zu866d.fsf@unicorn.mansr.com>
 <20130410210431.GQ14496@n2100.arm.linux.org.uk>
 <yw1x1uai84p9.fsf@unicorn.mansr.com>
 <alpine.LFD.2.03.1304101725280.17375@syhkavp.arg>
Message-ID: <yw1xwqsa6p6h.fsf@unicorn.mansr.com>

Nicolas Pitre <nico at fluxnic.net> writes:

> On Wed, 10 Apr 2013, M?ns Rullg?rd wrote:
>
>> Yet the A9 clearly does trap, just like the TRM says it should.  So
>> which is more likely, that the TRM and silicon are both wrong, or that
>> you are wrong?  Perhaps we should put it to a vote.
>
> Instead of encouraging the pissing contest, could you please provide 
> compilable example code that would trap so that anyone can test and 
> report results back?

Certainly.  What's the simplest way of telling whether it trapped?

-- 
M?ns Rullg?rd
mans at mansr.com


From arnd at arndb.de  Wed Apr 10 17:44:52 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed, 10 Apr 2013 23:44:52 +0200
Subject: [PATCH 3/5] gpio/omap: Add DT support to GPIO driver
In-Reply-To: <5165CB9D.1090202@wwwdotorg.org>
References: <1329321854-24490-1-git-send-email-b-cousson@ti.com>
 <CACRpkdYbs4-uudpRUY8e+7icYYkZrfM0kReP3pLL5DMiURJ4dg@mail.gmail.com>
 <5165CB9D.1090202@wwwdotorg.org>
Message-ID: <1580096.AHFBPvEqBp@wuerfel>

On Wednesday 10 April 2013 14:29:17 Stephen Warren wrote:
> 
> > If the information is there, whether to convert from IRQ to GPIO
> > or from GPIO to IRQ is a technicality and any order should be
> > feasible in some way?
> 
> There isn't always a unique 1:1 mapping between GPIOs and IRQs. Put
> another way, a single GPIO would likely only ever trigger a single IRQ,
> but a single IRQ might easily be triggered by any number of GPIOs. This
> is exactly why the function irq_to_gpio() isn't something one should use
> any more.

More importantly, most irqs don't have any GPIO associated with them
at all. The interface made some sense for simple platforms that had
a linear range of GPIO IRQs, but that also isn't true these days,
with arbitrary IRQ domains.

> I think there was an effort to outright remove the API,
> although it doesn't look like that's entirely complete yet.

It's essentially complete. There are a few remnants in areas of the kernel
that we don't like to look at:

* The blackfin architecture provides the interface and uses it in the
  pata_rb532_cf driver.

* MIPS provides it on a few older platforms, and it's used on the alchemy
  pcmcia driver.

* avr32, m68k, sh and unicore32 provide the interface but don't use it.

* On ARM, the interface is provided on iop, gemini, ixp4xx, ks8695
  and w90x900.  None of these use it, and they rarely see any patches
  at all these days.

* ARM/davinci provides a stub but always return -ENOSYS.

* One driver for PXA (tosa_battery) still uses this interface, but PXA stopped
  providing it long ago.

	Arnd


From linux at arm.linux.org.uk  Wed Apr 10 17:45:09 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Wed, 10 Apr 2013 22:45:09 +0100
Subject: Removal of NWFPE in its entirety, and VFP emulation code
In-Reply-To: <yw1x1uai84p9.fsf@unicorn.mansr.com>
References: <20130410104002.GF14496@n2100.arm.linux.org.uk>
 <yw1xmwt68whw.fsf@unicorn.mansr.com>
 <20130410114229.GH14496@n2100.arm.linux.org.uk>
 <yw1xip3u8uni.fsf@unicorn.mansr.com>
 <20130410185421.GI14496@n2100.arm.linux.org.uk>
 <yw1xehei8a19.fsf@unicorn.mansr.com>
 <20130410200344.GO14496@n2100.arm.linux.org.uk>
 <yw1x61zu866d.fsf@unicorn.mansr.com>
 <20130410210431.GQ14496@n2100.arm.linux.org.uk>
 <yw1x1uai84p9.fsf@unicorn.mansr.com>
Message-ID: <20130410214509.GT14496@n2100.arm.linux.org.uk>

On Wed, Apr 10, 2013 at 10:18:42PM +0100, M?ns Rullg?rd wrote:
> Russell King - ARM Linux <linux at arm.linux.org.uk> writes:
> 
> >> > Subarchitecture, bits [22:16]
> >> > 0b0000011
> >> > VFP architecture v3 or later with Null subarchitecture. The entire floating-point
> >> > implementation is in hardware, and no software support code is required. The
> >> > VFP architecture version is indicated by the MVFR0 and MVFR1 registers.
> >> > This value can be used only by an implementation that does not support the trap
> >> > enable bits in the FPSCR, see Floating-point Status and Control Register
> >> > (FPSCR) on page A2-28.
> >> 
> >> This means merely that the implementation never traps on things like
> >> denormal inputs or over/underflow.  It has nothing to do with vector
> >> support.
> >
> > Wrong.  The VFP subarchitecture defines the interface between *VFP
> > hardware* and the *VFP support code*.  I suggest you read carefully the
> > chapter in the ARM ARM *before* you make any further comment, and make
> > yourself look any more a fool than you already do.
> 
> Yet the A9 clearly does trap, just like the TRM says it should.  So
> which is more likely, that the TRM and silicon are both wrong, or that
> you are wrong?  Perhaps we should put it to a vote.

Look, it's all very simple for those who know how this works, which *you*
plainly don't - but rather than admit that you'll much rather insult
those who do.

- A9 is ARMv7.
- Vector operations are deprecated in ARMv7.
- Whether vector operations are implemented is up to the implementer.
- If they aren't implemented, they will cause an undefined instruction
  exception.
- If the VFP subarchitecture says '3' that means no support code is
  required by the implementation.

All together, that means that on ARMv7, of which Cortex-A9 is one such
implementation, vector operations *are* *deprecated* may or may not be
implement in hardware.  If they are not implemented in hardware *and*
the VFP subarchitecture reports '3', then you _should_ strictly get a
SIGILL for them and not have them executed because they are _deprecated_
*and* _unsupported_ instructions.

The current VFP support code behaviour can *not* be relied upon as being
correct, because it was implemented for VFP9 hardware, and has only been
tweaked so that it apparantly works with later VFP hardware.  There are
a bunch of known errors and problems with it with later VFP hardware,
one of which is providing emulation of all VFP instructions even for
subarch v3.

Subarch v3 _will_ eventually result in no VFP instruction emulation at
all when fixed, and it _will_ provoke a SIGILL instead.

I don't expect you to understand this, and you'll continue whinging.
Feel free, I won't be listening.  I'll be the other side of the country
really not caring in the least what stupid theory you're whining about.


From linux at arm.linux.org.uk  Wed Apr 10 17:46:51 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Wed, 10 Apr 2013 22:46:51 +0100
Subject: Removal of NWFPE in its entirety, and VFP emulation code
In-Reply-To: <20130410104002.GF14496@n2100.arm.linux.org.uk>
References: <20130410104002.GF14496@n2100.arm.linux.org.uk>
Message-ID: <20130410214650.GU14496@n2100.arm.linux.org.uk>

On Wed, Apr 10, 2013 at 11:40:02AM +0100, Russell King - ARM Linux wrote:
> I have just committed a patch to remove the arch/arm/nwfpe code from
> the kernel, and the VFP code emulating the FP operations.

It seems that Linus wishes to fight against this, so we'll just have to
wait and see what happens.  Linus is saying that he's perfectly happy
that the licenses _are_ compatible irrespective of what the FSF say.


From mturquette at linaro.org  Wed Apr 10 18:02:54 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Wed, 10 Apr 2013 15:02:54 -0700
Subject: [PATCH 0/3] fixed-rate and fixed-factor clocks in composite clock
In-Reply-To: <1365515284-32061-2-git-send-email-emilio@elopez.com.ar>
References: <1365515284-32061-2-git-send-email-emilio@elopez.com.ar>
Message-ID: <1365631378-16103-1-git-send-email-mturquette@linaro.org>

The series to add a gateable fixed-rate clock to the composite clock[1]
highlights some weaknesses in the composite clock's design.  This series
addresses those concerns (and hopefully supercedes that series) by allowing
more flexibility in the clock ops that can be registered for a composite clock,
namely by making .round_rate and .set_rate optional.

The last patch in this series is a respin of Emilio's changes to the
sunxi clock driver which makes use of the changes to the composite
clock.

Only compile tested, not run tested.

[1] http://article.gmane.org/gmane.linux.ports.arm.kernel/230004

Emilio L?pez (1):
  clk: sunxi: Unify oscillator clock

Mike Turquette (2):
  clk: composite: rename 'div' references to 'rate'
  clk: composite: allow fixed rates & fixed dividers

 drivers/clk/clk-composite.c   |   49 +++++++++++++++++++++++------------------
 drivers/clk/sunxi/clk-sunxi.c |   33 +++++++++++++++++++++------
 include/linux/clk-provider.h  |   14 ++++++------
 3 files changed, 60 insertions(+), 36 deletions(-)

-- 
1.7.10.4



From mturquette at linaro.org  Wed Apr 10 18:02:55 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Wed, 10 Apr 2013 15:02:55 -0700
Subject: [PATCH 1/3] clk: composite: rename 'div' references to 'rate'
In-Reply-To: <1365631378-16103-1-git-send-email-mturquette@linaro.org>
References: <1365515284-32061-2-git-send-email-emilio@elopez.com.ar>
 <1365631378-16103-1-git-send-email-mturquette@linaro.org>
Message-ID: <1365631378-16103-2-git-send-email-mturquette@linaro.org>

Rename all div_hw and div_ops related variables and functions to use
rate_hw, rate_ops, etc.  This is to make the rate-change portion of the
composite clk implementation more generic.  A patch following this one
will allow for fixed-rate clocks to reuse this infrastructure.

Signed-off-by: Mike Turquette <mturquette at linaro.org>
Cc: Prashant Gaikwad <pgaikwad at nvidia.com>
Cc: Emilio L?pez <emilio at elopez.com.ar>
Cc: Gregory CLEMENT <gregory.clement at free-electrons.com>
---
 drivers/clk/clk-composite.c  |   40 ++++++++++++++++++++--------------------
 include/linux/clk-provider.h |   14 +++++++-------
 2 files changed, 27 insertions(+), 27 deletions(-)

diff --git a/drivers/clk/clk-composite.c b/drivers/clk/clk-composite.c
index 097dee4..6f4728c 100644
--- a/drivers/clk/clk-composite.c
+++ b/drivers/clk/clk-composite.c
@@ -47,36 +47,36 @@ static unsigned long clk_composite_recalc_rate(struct clk_hw *hw,
 					    unsigned long parent_rate)
 {
 	struct clk_composite *composite = to_clk_composite(hw);
-	const struct clk_ops *div_ops = composite->div_ops;
-	struct clk_hw *div_hw = composite->div_hw;
+	const struct clk_ops *rate_ops = composite->rate_ops;
+	struct clk_hw *rate_hw = composite->rate_hw;
 
-	div_hw->clk = hw->clk;
+	rate_hw->clk = hw->clk;
 
-	return div_ops->recalc_rate(div_hw, parent_rate);
+	return rate_ops->recalc_rate(rate_hw, parent_rate);
 }
 
 static long clk_composite_round_rate(struct clk_hw *hw, unsigned long rate,
 				  unsigned long *prate)
 {
 	struct clk_composite *composite = to_clk_composite(hw);
-	const struct clk_ops *div_ops = composite->div_ops;
-	struct clk_hw *div_hw = composite->div_hw;
+	const struct clk_ops *rate_ops = composite->rate_ops;
+	struct clk_hw *rate_hw = composite->rate_hw;
 
-	div_hw->clk = hw->clk;
+	rate_hw->clk = hw->clk;
 
-	return div_ops->round_rate(div_hw, rate, prate);
+	return rate_ops->round_rate(rate_hw, rate, prate);
 }
 
 static int clk_composite_set_rate(struct clk_hw *hw, unsigned long rate,
 			       unsigned long parent_rate)
 {
 	struct clk_composite *composite = to_clk_composite(hw);
-	const struct clk_ops *div_ops = composite->div_ops;
-	struct clk_hw *div_hw = composite->div_hw;
+	const struct clk_ops *rate_ops = composite->rate_ops;
+	struct clk_hw *rate_hw = composite->rate_hw;
 
-	div_hw->clk = hw->clk;
+	rate_hw->clk = hw->clk;
 
-	return div_ops->set_rate(div_hw, rate, parent_rate);
+	return rate_ops->set_rate(rate_hw, rate, parent_rate);
 }
 
 static int clk_composite_is_enabled(struct clk_hw *hw)
@@ -115,7 +115,7 @@ static void clk_composite_disable(struct clk_hw *hw)
 struct clk *clk_register_composite(struct device *dev, const char *name,
 			const char **parent_names, int num_parents,
 			struct clk_hw *mux_hw, const struct clk_ops *mux_ops,
-			struct clk_hw *div_hw, const struct clk_ops *div_ops,
+			struct clk_hw *rate_hw, const struct clk_ops *rate_ops,
 			struct clk_hw *gate_hw, const struct clk_ops *gate_ops,
 			unsigned long flags)
 {
@@ -149,15 +149,15 @@ struct clk *clk_register_composite(struct device *dev, const char *name,
 		clk_composite_ops->set_parent = clk_composite_set_parent;
 	}
 
-	if (div_hw && div_ops) {
-		if (!div_ops->recalc_rate || !div_ops->round_rate ||
-		    !div_ops->set_rate) {
+	if (rate_hw && rate_ops) {
+		if (!rate_ops->recalc_rate || !rate_ops->round_rate ||
+		    !rate_ops->set_rate) {
 			clk = ERR_PTR(-EINVAL);
 			goto err;
 		}
 
-		composite->div_hw = div_hw;
-		composite->div_ops = div_ops;
+		composite->rate_hw = rate_hw;
+		composite->rate_ops = rate_ops;
 		clk_composite_ops->recalc_rate = clk_composite_recalc_rate;
 		clk_composite_ops->round_rate = clk_composite_round_rate;
 		clk_composite_ops->set_rate = clk_composite_set_rate;
@@ -187,8 +187,8 @@ struct clk *clk_register_composite(struct device *dev, const char *name,
 	if (composite->mux_hw)
 		composite->mux_hw->clk = clk;
 
-	if (composite->div_hw)
-		composite->div_hw->clk = clk;
+	if (composite->rate_hw)
+		composite->rate_hw->clk = clk;
 
 	if (composite->gate_hw)
 		composite->gate_hw->clk = clk;
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 9fdfae7..f5ba8c5 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -352,11 +352,11 @@ struct clk *clk_register_fixed_factor(struct device *dev, const char *name,
  * struct clk_composite - aggregate clock of mux, divider and gate clocks
  *
  * @hw:		handle between common and hardware-specific interfaces
- * @mux_hw:	handle between composite and hardware-specifix mux clock
- * @div_hw:	handle between composite and hardware-specifix divider clock
- * @gate_hw:	handle between composite and hardware-specifix gate clock
+ * @mux_hw:	handle between composite and hardware-specific mux clock
+ * @rate_hw:	handle between composite and hardware-specific rateider clock
+ * @gate_hw:	handle between composite and hardware-specific gate clock
  * @mux_ops:	clock ops for mux
- * @div_ops:	clock ops for divider
+ * @rate_ops:	clock ops for rateider
  * @gate_ops:	clock ops for gate
  */
 struct clk_composite {
@@ -364,18 +364,18 @@ struct clk_composite {
 	struct clk_ops	ops;
 
 	struct clk_hw	*mux_hw;
-	struct clk_hw	*div_hw;
+	struct clk_hw	*rate_hw;
 	struct clk_hw	*gate_hw;
 
 	const struct clk_ops	*mux_ops;
-	const struct clk_ops	*div_ops;
+	const struct clk_ops	*rate_ops;
 	const struct clk_ops	*gate_ops;
 };
 
 struct clk *clk_register_composite(struct device *dev, const char *name,
 		const char **parent_names, int num_parents,
 		struct clk_hw *mux_hw, const struct clk_ops *mux_ops,
-		struct clk_hw *div_hw, const struct clk_ops *div_ops,
+		struct clk_hw *rate_hw, const struct clk_ops *rate_ops,
 		struct clk_hw *gate_hw, const struct clk_ops *gate_ops,
 		unsigned long flags);
 
-- 
1.7.10.4



From mturquette at linaro.org  Wed Apr 10 18:02:56 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Wed, 10 Apr 2013 15:02:56 -0700
Subject: [PATCH 2/3] clk: composite: allow fixed rates & fixed dividers
In-Reply-To: <1365631378-16103-1-git-send-email-mturquette@linaro.org>
References: <1365515284-32061-2-git-send-email-emilio@elopez.com.ar>
 <1365631378-16103-1-git-send-email-mturquette@linaro.org>
Message-ID: <1365631378-16103-3-git-send-email-mturquette@linaro.org>

The composite clock assumes that any clock implementing the .recalc_rate
callback will also implement .round_rate and .set_rate.  This is not
always true; the basic fixed-rate clock will only implement .recalc_rate
and a fixed-divider clock may choose to implement .recalc_rate and
.round_rate but not .set_rate.

Fix this by conditionally registering .round_rate and .set_rate
callbacks based on the rate_ops passed in to clk_composite_register.

Signed-off-by: Mike Turquette <mturquette at linaro.org>
Cc: Prashant Gaikwad <pgaikwad at nvidia.com>
Cc: Emilio L?pez <emilio at elopez.com.ar>
Cc: Gregory CLEMENT <gregory.clement at free-electrons.com>
---
 drivers/clk/clk-composite.c |   13 +++++++++----
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/clk/clk-composite.c b/drivers/clk/clk-composite.c
index 6f4728c..2779fb3 100644
--- a/drivers/clk/clk-composite.c
+++ b/drivers/clk/clk-composite.c
@@ -150,17 +150,22 @@ struct clk *clk_register_composite(struct device *dev, const char *name,
 	}
 
 	if (rate_hw && rate_ops) {
-		if (!rate_ops->recalc_rate || !rate_ops->round_rate ||
-		    !rate_ops->set_rate) {
+		if (!rate_ops->recalc_rate) {
 			clk = ERR_PTR(-EINVAL);
 			goto err;
 		}
 
+		/* .round_rate is a prerequisite for .set_rate */
+		if (rate_ops->round_rate) {
+			clk_composite_ops->round_rate = clk_composite_round_rate;
+			if (rate_ops->set_rate) {
+				clk_composite_ops->set_rate = clk_composite_set_rate;
+			}
+		}
+
 		composite->rate_hw = rate_hw;
 		composite->rate_ops = rate_ops;
 		clk_composite_ops->recalc_rate = clk_composite_recalc_rate;
-		clk_composite_ops->round_rate = clk_composite_round_rate;
-		clk_composite_ops->set_rate = clk_composite_set_rate;
 	}
 
 	if (gate_hw && gate_ops) {
-- 
1.7.10.4



From mturquette at linaro.org  Wed Apr 10 18:02:57 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Wed, 10 Apr 2013 15:02:57 -0700
Subject: [PATCH v2 3/3] clk: sunxi: Unify oscillator clock
In-Reply-To: <1365631378-16103-1-git-send-email-mturquette@linaro.org>
References: <1365515284-32061-2-git-send-email-emilio@elopez.com.ar>
 <1365631378-16103-1-git-send-email-mturquette@linaro.org>
Message-ID: <1365631378-16103-4-git-send-email-mturquette@linaro.org>

From: Emilio L?pez <emilio at elopez.com.ar>

This commit uses the new fixed-rate support on the composite clock to
unify osc24M_fixed and osc24M clocks, so it matches the actual hardware.

Signed-off-by: Emilio L?pez <emilio at elopez.com.ar>
Signed-off-by: Mike Turquette <mturquette at linaro.org>
[mturquette at linaro.org: replace clk_register_gatable_osc with a call to
clk_register_composite]
---
Emilio,

I haven't been able to test these changes at run-time.  Can you see if
they are valid for solving your issue on sunxi?

 drivers/clk/sunxi/clk-sunxi.c |   33 ++++++++++++++++++++++++++-------
 1 file changed, 26 insertions(+), 7 deletions(-)

diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
index 0bb0eb4..8492ad1 100644
--- a/drivers/clk/sunxi/clk-sunxi.c
+++ b/drivers/clk/sunxi/clk-sunxi.c
@@ -33,16 +33,36 @@ static DEFINE_SPINLOCK(clk_lock);
 static void __init sunxi_osc_clk_setup(struct device_node *node)
 {
 	struct clk *clk;
+	struct clk_fixed_rate *fixed;
+	struct clk_gate *gate;
 	const char *clk_name = node->name;
-	const char *parent;
-	void *reg;
+	u32 rate;
 
-	reg = of_iomap(node, 0);
+	/* allocate fixed-rate and gate clock structs */
+	fixed = kzalloc(sizeof(struct clk_fixed_rate), GFP_KERNEL);
+	if (!fixed)
+		return;
+	gate = kzalloc(sizeof(struct clk_gate), GFP_KERNEL);
+	if (!gate) {
+		kfree(fixed);
+		return;
+	}
 
-	parent = of_clk_get_parent_name(node, 0);
+	if (of_property_read_u32(node, "clock-frequency", &rate))
+		return;
+
+	/* set up gate and fixed rate properties */
+	gate->reg = of_iomap(node, 0);
+	gate->bit_idx = SUNXI_OSC24M_GATE;
+	gate->lock = &clk_lock;
+	fixed->fixed_rate = rate;
 
-	clk = clk_register_gate(NULL, clk_name, parent, 0, reg,
-				SUNXI_OSC24M_GATE, 0, &clk_lock);
+	clk = clk_register_composite(NULL, clk_name,
+			NULL, 0,
+			NULL, NULL,
+			&fixed->hw, &clk_fixed_rate_ops,
+			&gate->hw, &clk_gate_ops,
+			CLK_IS_ROOT);
 
 	if (clk) {
 		of_clk_add_provider(node, of_clk_src_simple_get, clk);
@@ -380,7 +400,6 @@ static void __init sunxi_gates_clk_setup(struct device_node *node,
 
 /* Matches for of_clk_init */
 static const __initconst struct of_device_id clk_match[] = {
-	{.compatible = "fixed-clock", .data = of_fixed_clk_setup,},
 	{.compatible = "allwinner,sun4i-osc-clk", .data = sunxi_osc_clk_setup,},
 	{}
 };
-- 
1.7.10.4



From daniel.lezcano at linaro.org  Wed Apr 10 18:07:33 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Thu, 11 Apr 2013 00:07:33 +0200
Subject: [PATCH 05/18] cpuidle: make a single register function for all
In-Reply-To: <20130410181817.GM13524@lunn.ch>
References: <1365603743-5618-1-git-send-email-daniel.lezcano@linaro.org>
 <1365603743-5618-6-git-send-email-daniel.lezcano@linaro.org>
 <20130410165509.GK13524@lunn.ch> <5165A9A6.70905@linaro.org>
 <20130410181817.GM13524@lunn.ch>
Message-ID: <5165E2A5.4040401@linaro.org>

On 04/10/2013 08:18 PM, Andrew Lunn wrote:
> On Wed, Apr 10, 2013 at 08:04:22PM +0200, Daniel Lezcano wrote:
>> On 04/10/2013 06:55 PM, Andrew Lunn wrote:
>>>> +/**
>>>> + * cpuidle_register: registers the driver and the cpu devices with the
>>>> + * coupled_cpus passed as parameter. This function is used for all common
>>>> + * initialization pattern there are in the arch specific drivers. The
>>>> + * devices is globally defined in this file.
>>>> + *
>>>> + * @drv         : a valid pointer to a struct cpuidle_driver
>>>> + * @coupled_cpus: a cpumask for the coupled states
>>>> + *
>>>> + * Returns 0 on success, < 0 otherwise
>>>> + */
>>>> +int cpuidle_register(struct cpuidle_driver *drv,
>>>> +		     const struct cpumask *const coupled_cpus)
>>>> +{
>>>> +	int ret, cpu;
>>>> +	struct cpuidle_device *device;
>>>> +
>>>> +	ret = cpuidle_register_driver(drv);
>>>> +	if (ret) {
>>>> +		printk(KERN_ERR "failed to register cpuidle driver\n");
>>>
>>> pr_err()
>>
>> Ok.
>>
>>>> +		return ret;
>>>> +	}
>>>> +
>>>> +	for_each_possible_cpu(cpu) {
>>>> +		device = &per_cpu(cpuidle_dev, cpu);
>>>> +		device->cpu = cpu;
>>>> +#ifdef CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED
>>>> +		device->coupled_cpus = *coupled_cpus;
>>>> +#endif
>>>> +		ret = cpuidle_register_device(device);
>>>> +		if (!ret)
>>>> +			continue;
>>>> +
>>>> +		printk(KERN_ERR "Failed to register cpuidle "
>>>> +		       "device for cpu%d\n", cpu);
>>>
>>> pr_err() and don't split the message over two lines, it makes it
>>> harder for somebody to find with
>>>
>>> grep -r "Failed to register cpuidle device for cpu" *
>>
>> Ok if the line length is under 80 chars.
> 
> Take a closer look at the CodingStyle documents. This is one except to
> the rule. Such lines can be longer than 80 characters.

Oh, right !

"However, never break user-visible strings such as printk messages,
because that breaks the ability to grep for them."

Will fix it, thanks.

  -- Daniel

-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From thomas.petazzoni at free-electrons.com  Wed Apr 10 18:20:26 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Thu, 11 Apr 2013 00:20:26 +0200
Subject: [PATCHv2 00/10] Use the mvebu PCIe driver on Kirkwood
Message-ID: <1365632436-25367-1-git-send-email-thomas.petazzoni@free-electrons.com>

Hello,

Here is a set of patches that migrates adds support for Kirkwood
platforms to use the mvebu PCIe driver. All the Kirkwood platforms
that have already been converted to the Device Tree are converted to
use the new driver, and the DB-88F6281 evaluation board from Marvell
is also converted to the Device Tree and the usage of the new PCIe
driver.

Only non-DT platforms continue to use the legacy code in
arch/arm/mach-kirkwood/pcie.c.

This branch depends on the mvebu-mbus driver and the mvebu-pcie
driver. I have pushed this branch to the following Git repository for
easier testing:

  https://github.com/MISL-EBU-System-SW/mainline-public/tree/kirkwood-dt

# /usr/sbin/lspci
00:01.0 PCI bridge: Marvell Technology Group Ltd. Device 7846
00:02.0 PCI bridge: Marvell Technology Group Ltd. Device 7846
01:00.0 SCSI storage controller: Marvell Technology Group Ltd. 88SX7042 PCI-e 4-port SATA-II (rev 02)
02:00.0 Ethernet controller: Intel Corporation 82572EI Gigabit Ethernet Controller (Copper) (rev 06)

# cat /proc/cpuinfo | grep ^Hardware
Hardware	: Marvell Kirkwood (Flattened Device Tree)

I've tested both the e1000e NIC card and the SATA 4 ports card and
they work fine.

Changes between v1 and v2:

 * Remove the 'needs_pcie_win' logic, and instead move the static
   initialization of PCIe windows into the legacy PCIe code, for the
   platforms that will still be using it. Platforms that will use the
   new PCIe driver benefit directly from dynamic allocation of PCIe
   windows.

 * Move the PCIe interface definitions from kirkwood.dtsi to
   kirkwood-6281.dtsi and kirkwood-6282.dtsi to take into account the
   fact that the 6281 has one PCIe interface, and the 6282 has two of
   them.

 * Convert all DT-platforms that were initializing PCIe using the
   legacy driver to use the DT to initialize the PCIe interface. This
   includes the Iomega Iconnect, the MPL CEC4, the ZyXEL NSA310and the
   QNAP TS219.

 * Fix the conversion to the Device Tree of the DB-88F6181/6282
   board. We now have two Device Trees, one for the 6281 variant of
   the board (one PCIe interface) and another for the 6282 variant of
   the board (two PCIe interfaces).

 * Update the defconfig with PCIe driver enabled and some board
   updates.

Best regards,

Thomas

Thomas Petazzoni (10):
  pci: mvebu: enable driver usage on Kirkwood
  bus: mvebu: fix mistake in PCIe window target attribute for Kirkwood
  arm: kirkwood: move PCIe window init to legacy driver
  arm: kirkwood: add SoC-level Device Tree data for PCIe interfaces
  arm: kirkwood: convert Iomega Iconnect to use DT for the PCIe
    interface
  arm: kirkwood: convert MPL CEC4 to use DT for the PCIe interface
  arm: kirkwood: convert ZyXEL NSA310 to use DT for the PCIe interface
  arm: kirkwood: convert QNAP TS219 to use DT for the PCIe interface
  arm: kirkwood: convert db-88f6281 to the Device Tree
  arm: kirkwood: update defconfig with PCIe driver and board updates

 .../devicetree/bindings/pci/mvebu-pci.txt          |    1 +
 arch/arm/boot/dts/Makefile                         |    5 +-
 arch/arm/boot/dts/kirkwood-6281.dtsi               |   31 ++++++
 arch/arm/boot/dts/kirkwood-6282.dtsi               |   48 +++++++++
 arch/arm/boot/dts/kirkwood-db-88f6281.dts          |   30 ++++++
 arch/arm/boot/dts/kirkwood-db-88f6282.dts          |   34 ++++++
 arch/arm/boot/dts/kirkwood-db.dtsi                 |   89 ++++++++++++++++
 arch/arm/boot/dts/kirkwood-iconnect.dts            |    8 ++
 arch/arm/boot/dts/kirkwood-mplcec4.dts             |    8 ++
 arch/arm/boot/dts/kirkwood-nsa310.dts              |    8 ++
 arch/arm/boot/dts/kirkwood-ts219.dtsi              |    7 ++
 arch/arm/boot/dts/kirkwood.dtsi                    |    1 +
 arch/arm/configs/kirkwood_defconfig                |    6 +-
 arch/arm/mach-kirkwood/Kconfig                     |   21 ++--
 arch/arm/mach-kirkwood/Makefile                    |    3 +-
 arch/arm/mach-kirkwood/board-db88f6281-bp.c        |   26 +++++
 arch/arm/mach-kirkwood/board-dt.c                  |    2 +
 arch/arm/mach-kirkwood/board-iconnect.c            |    8 --
 arch/arm/mach-kirkwood/board-mplcec4.c             |    1 -
 arch/arm/mach-kirkwood/board-nsa310.c              |   25 -----
 arch/arm/mach-kirkwood/board-ts219.c               |   10 --
 arch/arm/mach-kirkwood/common.c                    |   24 -----
 arch/arm/mach-kirkwood/common.h                    |    6 ++
 arch/arm/mach-kirkwood/db88f6281-bp-setup.c        |  108 --------------------
 arch/arm/mach-kirkwood/pcie.c                      |   22 ++++
 drivers/bus/mvebu-mbus.c                           |    2 +-
 drivers/pci/host/Kconfig                           |    2 +-
 drivers/pci/host/pci-mvebu.c                       |    1 +
 28 files changed, 339 insertions(+), 198 deletions(-)
 create mode 100644 arch/arm/boot/dts/kirkwood-db-88f6281.dts
 create mode 100644 arch/arm/boot/dts/kirkwood-db-88f6282.dts
 create mode 100644 arch/arm/boot/dts/kirkwood-db.dtsi
 create mode 100644 arch/arm/mach-kirkwood/board-db88f6281-bp.c
 delete mode 100644 arch/arm/mach-kirkwood/board-nsa310.c
 delete mode 100644 arch/arm/mach-kirkwood/db88f6281-bp-setup.c

-- 
1.7.9.5



From thomas.petazzoni at free-electrons.com  Wed Apr 10 18:20:27 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Thu, 11 Apr 2013 00:20:27 +0200
Subject: [PATCHv2 01/10] pci: mvebu: enable driver usage on Kirkwood
In-Reply-To: <1365632436-25367-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1365632436-25367-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1365632436-25367-2-git-send-email-thomas.petazzoni@free-electrons.com>

We allow the pci-mvebu driver to be compiled on the Kirkwood platform,
and add the 'marvell,kirkwood-pcie' as a compatible string supported
by the driver.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 .../devicetree/bindings/pci/mvebu-pci.txt          |    1 +
 drivers/pci/host/Kconfig                           |    2 +-
 drivers/pci/host/pci-mvebu.c                       |    1 +
 3 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/pci/mvebu-pci.txt b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
index eb69d92..f8d4058 100644
--- a/Documentation/devicetree/bindings/pci/mvebu-pci.txt
+++ b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
@@ -4,6 +4,7 @@ Mandatory properties:
 - compatible: one of the following values:
     marvell,armada-370-pcie
     marvell,armada-xp-pcie
+    marvell,kirkwood-pcie
 - #address-cells, set to <3>
 - #size-cells, set to <2>
 - #interrupt-cells, set to <1>
diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index 6918fbc..1f1d67f 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -3,6 +3,6 @@ menu "PCI host controller drivers"
 
 config PCI_MVEBU
 	bool "Marvell EBU PCIe controller"
-	depends on ARCH_MVEBU
+	depends on ARCH_MVEBU || ARCH_KIRKWOOD
 
 endmenu
diff --git a/drivers/pci/host/pci-mvebu.c b/drivers/pci/host/pci-mvebu.c
index 9c15a25..a083d19 100644
--- a/drivers/pci/host/pci-mvebu.c
+++ b/drivers/pci/host/pci-mvebu.c
@@ -853,6 +853,7 @@ static int __init mvebu_pcie_probe(struct platform_device *pdev)
 static const struct of_device_id mvebu_pcie_of_match_table[] = {
 	{ .compatible = "marvell,armada-xp-pcie", },
 	{ .compatible = "marvell,armada-370-pcie", },
+	{ .compatible = "marvell,kirkwood-pcie", },
 	{},
 };
 MODULE_DEVICE_TABLE(of, mvebu_pcie_of_match_table);
-- 
1.7.9.5



From thomas.petazzoni at free-electrons.com  Wed Apr 10 18:20:28 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Thu, 11 Apr 2013 00:20:28 +0200
Subject: [PATCHv2 02/10] bus: mvebu: fix mistake in PCIe window target
 attribute for Kirkwood
In-Reply-To: <1365632436-25367-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1365632436-25367-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1365632436-25367-3-git-send-email-thomas.petazzoni@free-electrons.com>

The target and attributes for the PCIe address decoding windows were
not correct on Kirkwood for the second PCIe interface.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
Note: this patch should be merged with the existing mvebu-mbus driver.
---
 drivers/bus/mvebu-mbus.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
index 586d03e..4de2c6b 100644
--- a/drivers/bus/mvebu-mbus.c
+++ b/drivers/bus/mvebu-mbus.c
@@ -626,7 +626,7 @@ static const struct mvebu_mbus_soc_data armada_xp_mbus_data = {
 
 static const struct mvebu_mbus_mapping kirkwood_map[] = {
 	MAPDEF("pcie0.0", 4, 0xe0, MAPDEF_PCIMASK),
-	MAPDEF("pcie1.0", 8, 0xe0, MAPDEF_PCIMASK),
+	MAPDEF("pcie1.0", 4, 0xd0, MAPDEF_PCIMASK),
 	MAPDEF("sram",    3, 0x01, MAPDEF_NOMASK),
 	MAPDEF("nand",    1, 0x2f, MAPDEF_NOMASK),
 	{},
-- 
1.7.9.5



From thomas.petazzoni at free-electrons.com  Wed Apr 10 18:20:30 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Thu, 11 Apr 2013 00:20:30 +0200
Subject: [PATCHv2 04/10] arm: kirkwood: add SoC-level Device Tree data for
 PCIe interfaces
In-Reply-To: <1365632436-25367-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1365632436-25367-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1365632436-25367-5-git-send-email-thomas.petazzoni@free-electrons.com>

This commit adds Device Tree details to enable the PCIe interfaces on
Kirkwood. The 6281 has one PCIe interface, the 6282 has two PCIe
interfaces.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 arch/arm/boot/dts/kirkwood-6281.dtsi |   31 ++++++++++++++++++++++
 arch/arm/boot/dts/kirkwood-6282.dtsi |   48 ++++++++++++++++++++++++++++++++++
 arch/arm/boot/dts/kirkwood.dtsi      |    1 +
 3 files changed, 80 insertions(+)

diff --git a/arch/arm/boot/dts/kirkwood-6281.dtsi b/arch/arm/boot/dts/kirkwood-6281.dtsi
index d6c9d65..5137668 100644
--- a/arch/arm/boot/dts/kirkwood-6281.dtsi
+++ b/arch/arm/boot/dts/kirkwood-6281.dtsi
@@ -40,5 +40,36 @@
 				marvell,function = "sdio";
 			};
 		};
+
+		pcie-controller {
+			compatible = "marvell,kirkwood-pcie";
+			status = "disabled";
+			device_type = "pci";
+
+			#address-cells = <3>;
+			#size-cells = <2>;
+
+			bus-range = <0x00 0xff>;
+
+			ranges = <0x82000000 0 0x00040000 0x00040000 0 0x00002000   /* Port 0.0 registers */
+				  0x82000000 0 0xe0000000 0xe0000000 0 0x08000000   /* non-prefetchable memory */
+			          0x81000000 0 0          0xe8000000 0 0x00100000>; /* downstream I/O */
+
+			pcie at 1,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82000800 0 0x00040000 0 0x2000>;
+				reg = <0x0800 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &intc 9>;
+				marvell,pcie-port = <0>;
+				marvell,pcie-lane = <0>;
+				clocks = <&gate_clk 2>;
+				status = "disabled";
+			};
+		};
 	};
 };
diff --git a/arch/arm/boot/dts/kirkwood-6282.dtsi b/arch/arm/boot/dts/kirkwood-6282.dtsi
index 192cf76..00a698e 100644
--- a/arch/arm/boot/dts/kirkwood-6282.dtsi
+++ b/arch/arm/boot/dts/kirkwood-6282.dtsi
@@ -59,5 +59,53 @@
 			clocks = <&gate_clk 7>;
 			status = "disabled";
 		};
+
+		pcie-controller {
+			compatible = "marvell,kirkwood-pcie";
+			status = "disabled";
+			device_type = "pci";
+
+			#address-cells = <3>;
+			#size-cells = <2>;
+
+			bus-range = <0x00 0xff>;
+
+			ranges = <0x82000000 0 0x00040000 0x00040000 0 0x00002000   /* Port 0.0 registers */
+			          0x82000000 0 0x00044000 0x00044000 0 0x00002000   /* Port 1.0 registers */
+				  0x82000000 0 0xe0000000 0xe0000000 0 0x08000000   /* non-prefetchable memory */
+			          0x81000000 0 0          0xe8000000 0 0x00100000>; /* downstream I/O */
+
+			pcie at 1,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82000800 0 0x00040000 0 0x2000>;
+				reg = <0x0800 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &intc 9>;
+				marvell,pcie-port = <0>;
+				marvell,pcie-lane = <0>;
+				clocks = <&gate_clk 2>;
+				status = "disabled";
+			};
+
+			pcie at 2,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82001000 0 0x00044000 0 0x2000>;
+				reg = <0x1000 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &intc 10>;
+				marvell,pcie-port = <1>;
+				marvell,pcie-lane = <0>;
+				clocks = <&gate_clk 18>;
+				status = "disabled";
+			};
+		};
 	};
 };
diff --git a/arch/arm/boot/dts/kirkwood.dtsi b/arch/arm/boot/dts/kirkwood.dtsi
index 2c738d9..8aae1cf 100644
--- a/arch/arm/boot/dts/kirkwood.dtsi
+++ b/arch/arm/boot/dts/kirkwood.dtsi
@@ -19,6 +19,7 @@
 	ocp at f1000000 {
 		compatible = "simple-bus";
 		ranges = <0x00000000 0xf1000000 0x4000000
+		          0xe0000000 0xe0000000 0x8100000 /* PCIE */
 		          0xf5000000 0xf5000000 0x0000400>;
 		#address-cells = <1>;
 		#size-cells = <1>;
-- 
1.7.9.5



From thomas.petazzoni at free-electrons.com  Wed Apr 10 18:20:29 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Thu, 11 Apr 2013 00:20:29 +0200
Subject: [PATCHv2 03/10] arm: kirkwood: move PCIe window init to legacy driver
In-Reply-To: <1365632436-25367-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1365632436-25367-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1365632436-25367-4-git-send-email-thomas.petazzoni@free-electrons.com>

Since we are going to enable the usage of the mvebu PCIe driver on
Kirkwood, we don't want the PCIe windows to be unconditionally created
by kirkwood_setup_wins(). Therefore, we move the PCIe window
initialization into the legacy PCIe driver
(arch/arm/mach-kirkwood/pcie.c).

The platforms using the legacy driver will see their windows
statically allocated by
arch/arm/mach-kirkwood/pcie.c:kirkwood_pcie_init(). The platforms
using the new driver in drivers/pci/ will see their windows
dynamically allocated directly by the driver.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 arch/arm/mach-kirkwood/common.c |   24 ------------------------
 arch/arm/mach-kirkwood/pcie.c   |   22 ++++++++++++++++++++++
 2 files changed, 22 insertions(+), 24 deletions(-)

diff --git a/arch/arm/mach-kirkwood/common.c b/arch/arm/mach-kirkwood/common.c
index c2cae69..9b0b901 100644
--- a/arch/arm/mach-kirkwood/common.c
+++ b/arch/arm/mach-kirkwood/common.c
@@ -654,30 +654,6 @@ char * __init kirkwood_id(void)
 
 void __init kirkwood_setup_wins(void)
 {
-	/*
-	 * The PCIe windows will no longer be statically allocated
-	 * here once Kirkwood is migrated to the pci-mvebu driver.
-	 */
-	mvebu_mbus_add_window_remap_flags("pcie0.0",
-					  KIRKWOOD_PCIE_IO_PHYS_BASE,
-					  KIRKWOOD_PCIE_IO_SIZE,
-					  KIRKWOOD_PCIE_IO_BUS_BASE,
-					  MVEBU_MBUS_PCI_IO);
-	mvebu_mbus_add_window_remap_flags("pcie0.0",
-					  KIRKWOOD_PCIE_MEM_PHYS_BASE,
-					  KIRKWOOD_PCIE_MEM_SIZE,
-					  MVEBU_MBUS_NO_REMAP,
-					  MVEBU_MBUS_PCI_MEM);
-	mvebu_mbus_add_window_remap_flags("pcie1.0",
-					  KIRKWOOD_PCIE1_IO_PHYS_BASE,
-					  KIRKWOOD_PCIE1_IO_SIZE,
-					  KIRKWOOD_PCIE1_IO_BUS_BASE,
-					  MVEBU_MBUS_PCI_IO);
-	mvebu_mbus_add_window_remap_flags("pcie1.0",
-					  KIRKWOOD_PCIE1_MEM_PHYS_BASE,
-					  KIRKWOOD_PCIE1_MEM_SIZE,
-					  MVEBU_MBUS_NO_REMAP,
-					  MVEBU_MBUS_PCI_MEM);
 	mvebu_mbus_add_window("nand", KIRKWOOD_NAND_MEM_PHYS_BASE,
 			      KIRKWOOD_NAND_MEM_SIZE);
 	mvebu_mbus_add_window("sram", KIRKWOOD_SRAM_PHYS_BASE,
diff --git a/arch/arm/mach-kirkwood/pcie.c b/arch/arm/mach-kirkwood/pcie.c
index 7f43e6c..ddcb09f 100644
--- a/arch/arm/mach-kirkwood/pcie.c
+++ b/arch/arm/mach-kirkwood/pcie.c
@@ -12,6 +12,7 @@
 #include <linux/pci.h>
 #include <linux/slab.h>
 #include <linux/clk.h>
+#include <linux/mbus.h>
 #include <video/vga.h>
 #include <asm/irq.h>
 #include <asm/mach/pci.h>
@@ -253,6 +254,27 @@ static void __init add_pcie_port(int index, void __iomem *base)
 
 void __init kirkwood_pcie_init(unsigned int portmask)
 {
+	mvebu_mbus_add_window_remap_flags("pcie0.0",
+					  KIRKWOOD_PCIE_IO_PHYS_BASE,
+					  KIRKWOOD_PCIE_IO_SIZE,
+					  KIRKWOOD_PCIE_IO_BUS_BASE,
+					  MVEBU_MBUS_PCI_IO);
+	mvebu_mbus_add_window_remap_flags("pcie0.0",
+					  KIRKWOOD_PCIE_MEM_PHYS_BASE,
+					  KIRKWOOD_PCIE_MEM_SIZE,
+					  MVEBU_MBUS_NO_REMAP,
+					  MVEBU_MBUS_PCI_MEM);
+	mvebu_mbus_add_window_remap_flags("pcie1.0",
+					  KIRKWOOD_PCIE1_IO_PHYS_BASE,
+					  KIRKWOOD_PCIE1_IO_SIZE,
+					  KIRKWOOD_PCIE1_IO_BUS_BASE,
+					  MVEBU_MBUS_PCI_IO);
+	mvebu_mbus_add_window_remap_flags("pcie1.0",
+					  KIRKWOOD_PCIE1_MEM_PHYS_BASE,
+					  KIRKWOOD_PCIE1_MEM_SIZE,
+					  MVEBU_MBUS_NO_REMAP,
+					  MVEBU_MBUS_PCI_MEM);
+
 	vga_base = KIRKWOOD_PCIE_MEM_PHYS_BASE;
 
 	if (portmask & KW_PCIE0)
-- 
1.7.9.5



From thomas.petazzoni at free-electrons.com  Wed Apr 10 18:20:31 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Thu, 11 Apr 2013 00:20:31 +0200
Subject: [PATCHv2 05/10] arm: kirkwood: convert Iomega Iconnect to use DT for
 the PCIe interface
In-Reply-To: <1365632436-25367-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1365632436-25367-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1365632436-25367-6-git-send-email-thomas.petazzoni@free-electrons.com>

Now that the PCIe mvebu driver is usable on Kirkwood, use it instead
of the legacy PCIe code, since it allows to describe the PCIe
interfaces in the Device Tree.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 arch/arm/boot/dts/kirkwood-iconnect.dts |    8 ++++++++
 arch/arm/mach-kirkwood/board-iconnect.c |    8 --------
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/arch/arm/boot/dts/kirkwood-iconnect.dts b/arch/arm/boot/dts/kirkwood-iconnect.dts
index 504f16b..4c8f0df 100644
--- a/arch/arm/boot/dts/kirkwood-iconnect.dts
+++ b/arch/arm/boot/dts/kirkwood-iconnect.dts
@@ -110,6 +110,14 @@
 				reg = <0x980000 0x1f400000>;
 			};
 		};
+
+		pcie-controller {
+			status = "okay";
+
+			pcie at 1,0 {
+				status = "okay";
+			};
+		};
 	};
 
 	gpio-leds {
diff --git a/arch/arm/mach-kirkwood/board-iconnect.c b/arch/arm/mach-kirkwood/board-iconnect.c
index c8ebde4..98b5ad1 100644
--- a/arch/arm/mach-kirkwood/board-iconnect.c
+++ b/arch/arm/mach-kirkwood/board-iconnect.c
@@ -22,11 +22,3 @@ void __init iconnect_init(void)
 {
 	kirkwood_ge00_init(&iconnect_ge00_data);
 }
-
-static int __init iconnect_pci_init(void)
-{
-	if (of_machine_is_compatible("iom,iconnect"))
-		kirkwood_pcie_init(KW_PCIE0);
-	return 0;
-}
-subsys_initcall(iconnect_pci_init);
-- 
1.7.9.5



From thomas.petazzoni at free-electrons.com  Wed Apr 10 18:20:32 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Thu, 11 Apr 2013 00:20:32 +0200
Subject: [PATCHv2 06/10] arm: kirkwood: convert MPL CEC4 to use DT for the
 PCIe interface
In-Reply-To: <1365632436-25367-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1365632436-25367-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1365632436-25367-7-git-send-email-thomas.petazzoni@free-electrons.com>

Now that the PCIe mvebu driver is usable on Kirkwood, use it instead
of the legacy PCIe code, since it allows to describe the PCIe
interfaces in the Device Tree.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 arch/arm/boot/dts/kirkwood-mplcec4.dts |    8 ++++++++
 arch/arm/mach-kirkwood/board-mplcec4.c |    1 -
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/kirkwood-mplcec4.dts b/arch/arm/boot/dts/kirkwood-mplcec4.dts
index 662dfd8..080f28e 100644
--- a/arch/arm/boot/dts/kirkwood-mplcec4.dts
+++ b/arch/arm/boot/dts/kirkwood-mplcec4.dts
@@ -140,6 +140,14 @@
 			cd-gpios = <&gpio1 15 0>;
 			/* No WP GPIO */
 		};
+
+		pcie-controller {
+			status = "okay";
+
+			pcie at 1,0 {
+				status = "okay";
+			};
+		};
 	};
 
 	gpio-leds {
diff --git a/arch/arm/mach-kirkwood/board-mplcec4.c b/arch/arm/mach-kirkwood/board-mplcec4.c
index 7d6dc66..938712e 100644
--- a/arch/arm/mach-kirkwood/board-mplcec4.c
+++ b/arch/arm/mach-kirkwood/board-mplcec4.c
@@ -29,7 +29,6 @@ void __init mplcec4_init(void)
 	 */
 	kirkwood_ge00_init(&mplcec4_ge00_data);
 	kirkwood_ge01_init(&mplcec4_ge01_data);
-	kirkwood_pcie_init(KW_PCIE0);
 }
 
 
-- 
1.7.9.5



From thomas.petazzoni at free-electrons.com  Wed Apr 10 18:20:33 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Thu, 11 Apr 2013 00:20:33 +0200
Subject: [PATCHv2 07/10] arm: kirkwood: convert ZyXEL NSA310 to use DT for the
 PCIe interface
In-Reply-To: <1365632436-25367-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1365632436-25367-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1365632436-25367-8-git-send-email-thomas.petazzoni@free-electrons.com>

Now that the PCIe mvebu driver is usable on Kirkwood, use it instead
of the legacy PCIe code, since it allows to describe the PCIe
interfaces in the Device Tree.

Since it was the only device left that prevented this platform to use
the Device Tree only, we remove the board-nsa310.c file and the
related Kconfig/Makefile bits.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 arch/arm/boot/dts/kirkwood-nsa310.dts |    8 ++++++++
 arch/arm/mach-kirkwood/Kconfig        |    8 --------
 arch/arm/mach-kirkwood/Makefile       |    1 -
 arch/arm/mach-kirkwood/board-nsa310.c |   25 -------------------------
 4 files changed, 8 insertions(+), 34 deletions(-)
 delete mode 100644 arch/arm/mach-kirkwood/board-nsa310.c

diff --git a/arch/arm/boot/dts/kirkwood-nsa310.dts b/arch/arm/boot/dts/kirkwood-nsa310.dts
index 3a178cf..1cd15ba 100644
--- a/arch/arm/boot/dts/kirkwood-nsa310.dts
+++ b/arch/arm/boot/dts/kirkwood-nsa310.dts
@@ -177,6 +177,14 @@
 				reg = <0x5040000 0x2fc0000>;
 			};
 		};
+
+		pcie-controller {
+			status = "okay";
+
+			pcie at 1,0 {
+				status = "okay";
+			};
+		};
 	};
 
 	gpio_keys {
diff --git a/arch/arm/mach-kirkwood/Kconfig b/arch/arm/mach-kirkwood/Kconfig
index 7b6a64b..1fe5f2f 100644
--- a/arch/arm/mach-kirkwood/Kconfig
+++ b/arch/arm/mach-kirkwood/Kconfig
@@ -287,14 +287,6 @@ config MACH_T5325
 	  Say 'Y' here if you want your kernel to support the
 	  HP t5325 Thin Client.
 
-config MACH_NSA310_DT
-	bool "ZyXEL NSA-310 (Flattened Device Tree)"
-	select ARCH_KIRKWOOD_DT
-	select ARM_ATAG_DTB_COMPAT
-	help
-	  Say 'Y' here if you want your kernel to support the
-	  ZyXEL NSA-310 board (Flattened Device Tree).
-
 endmenu
 
 endif
diff --git a/arch/arm/mach-kirkwood/Makefile b/arch/arm/mach-kirkwood/Makefile
index d805f80..0e5ccad 100644
--- a/arch/arm/mach-kirkwood/Makefile
+++ b/arch/arm/mach-kirkwood/Makefile
@@ -37,6 +37,5 @@ obj-$(CONFIG_MACH_NETSPACE_V2_DT)	+= board-ns2.o
 obj-$(CONFIG_MACH_NETSPACE_MAX_V2_DT)	+= board-ns2.o
 obj-$(CONFIG_MACH_NETSPACE_LITE_V2_DT)	+= board-ns2.o
 obj-$(CONFIG_MACH_NETSPACE_MINI_V2_DT)	+= board-ns2.o
-obj-$(CONFIG_MACH_NSA310_DT)		+= board-nsa310.o
 obj-$(CONFIG_MACH_OPENBLOCKS_A6_DT)	+= board-openblocks_a6.o
 obj-$(CONFIG_MACH_TOPKICK_DT)		+= board-usi_topkick.o
diff --git a/arch/arm/mach-kirkwood/board-nsa310.c b/arch/arm/mach-kirkwood/board-nsa310.c
deleted file mode 100644
index 55ade93..0000000
--- a/arch/arm/mach-kirkwood/board-nsa310.c
+++ /dev/null
@@ -1,25 +0,0 @@
-/*
- * arch/arm/mach-kirkwood/nsa-310-setup.c
- *
- * ZyXEL NSA-310 Setup
- *
- * 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/kernel.h>
-#include <linux/init.h>
-#include <mach/kirkwood.h>
-#include <linux/of.h>
-#include "common.h"
-
-static int __init nsa310_pci_init(void)
-{
-	if (of_machine_is_compatible("zyxel,nsa310"))
-		kirkwood_pcie_init(KW_PCIE0);
-
-	return 0;
-}
-
-subsys_initcall(nsa310_pci_init);
-- 
1.7.9.5



From thomas.petazzoni at free-electrons.com  Wed Apr 10 18:20:34 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Thu, 11 Apr 2013 00:20:34 +0200
Subject: [PATCHv2 08/10] arm: kirkwood: convert QNAP TS219 to use DT for the
 PCIe interface
In-Reply-To: <1365632436-25367-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1365632436-25367-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1365632436-25367-9-git-send-email-thomas.petazzoni@free-electrons.com>

Now that the PCIe mvebu driver is usable on Kirkwood, use it instead
of the legacy PCIe code, since it allows to describe the PCIe
interfaces in the Device Tree.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 arch/arm/boot/dts/kirkwood-ts219.dtsi |    7 +++++++
 arch/arm/mach-kirkwood/board-ts219.c  |   10 ----------
 2 files changed, 7 insertions(+), 10 deletions(-)

diff --git a/arch/arm/boot/dts/kirkwood-ts219.dtsi b/arch/arm/boot/dts/kirkwood-ts219.dtsi
index 64ea27c..341e1d8 100644
--- a/arch/arm/boot/dts/kirkwood-ts219.dtsi
+++ b/arch/arm/boot/dts/kirkwood-ts219.dtsi
@@ -74,5 +74,12 @@
 			status = "okay";
 			nr-ports = <2>;
 		};
+		pcie-controller {
+			status = "okay";
+
+			pcie at 1,0 {
+				status = "okay";
+			};
+		};
 	};
 };
diff --git a/arch/arm/mach-kirkwood/board-ts219.c b/arch/arm/mach-kirkwood/board-ts219.c
index acb0187..4695d5f 100644
--- a/arch/arm/mach-kirkwood/board-ts219.c
+++ b/arch/arm/mach-kirkwood/board-ts219.c
@@ -41,13 +41,3 @@ void __init qnap_dt_ts219_init(void)
 
 	pm_power_off = qnap_tsx1x_power_off;
 }
-
-/* FIXME: Will not work with DT. Maybe use MPP40_GPIO? */
-static int __init ts219_pci_init(void)
-{
-	if (machine_is_ts219())
-		kirkwood_pcie_init(KW_PCIE0);
-
-	return 0;
-}
-subsys_initcall(ts219_pci_init);
-- 
1.7.9.5



From mans at mansr.com  Wed Apr 10 18:21:31 2013
From: mans at mansr.com (=?iso-8859-1?Q?M=E5ns_Rullg=E5rd?=)
Date: Wed, 10 Apr 2013 23:21:31 +0100
Subject: Removal of NWFPE in its entirety, and VFP emulation code
In-Reply-To: <20130410214509.GT14496@n2100.arm.linux.org.uk> (Russell King's
 message of "Wed, 10 Apr 2013 22:45:09 +0100")
References: <20130410104002.GF14496@n2100.arm.linux.org.uk>
 <yw1xmwt68whw.fsf@unicorn.mansr.com>
 <20130410114229.GH14496@n2100.arm.linux.org.uk>
 <yw1xip3u8uni.fsf@unicorn.mansr.com>
 <20130410185421.GI14496@n2100.arm.linux.org.uk>
 <yw1xehei8a19.fsf@unicorn.mansr.com>
 <20130410200344.GO14496@n2100.arm.linux.org.uk>
 <yw1x61zu866d.fsf@unicorn.mansr.com>
 <20130410210431.GQ14496@n2100.arm.linux.org.uk>
 <yw1x1uai84p9.fsf@unicorn.mansr.com>
 <20130410214509.GT14496@n2100.arm.linux.org.uk>
Message-ID: <yw1xsj2y6n84.fsf@unicorn.mansr.com>

Russell King - ARM Linux <linux at arm.linux.org.uk> writes:

> On Wed, Apr 10, 2013 at 10:18:42PM +0100, M?ns Rullg?rd wrote:
>> Russell King - ARM Linux <linux at arm.linux.org.uk> writes:
>> 
>> >> > Subarchitecture, bits [22:16]
>> >> > 0b0000011
>> >> > VFP architecture v3 or later with Null subarchitecture. The entire floating-point
>> >> > implementation is in hardware, and no software support code is required. The
>> >> > VFP architecture version is indicated by the MVFR0 and MVFR1 registers.
>> >> > This value can be used only by an implementation that does not support the trap
>> >> > enable bits in the FPSCR, see Floating-point Status and Control Register
>> >> > (FPSCR) on page A2-28.
>> >> 
>> >> This means merely that the implementation never traps on things like
>> >> denormal inputs or over/underflow.  It has nothing to do with vector
>> >> support.
>> >
>> > Wrong.  The VFP subarchitecture defines the interface between *VFP
>> > hardware* and the *VFP support code*.  I suggest you read carefully the
>> > chapter in the ARM ARM *before* you make any further comment, and make
>> > yourself look any more a fool than you already do.
>> 
>> Yet the A9 clearly does trap, just like the TRM says it should.  So
>> which is more likely, that the TRM and silicon are both wrong, or that
>> you are wrong?  Perhaps we should put it to a vote.
>
> Look, it's all very simple for those who know how this works, which *you*
> plainly don't - but rather than admit that you'll much rather insult
> those who do.
>
> - A9 is ARMv7.
> - Vector operations are deprecated in ARMv7.
> - Whether vector operations are implemented is up to the implementer.
> - If they aren't implemented, they will cause an undefined instruction
>   exception.
> - If the VFP subarchitecture says '3' that means no support code is
>   required by the implementation.
>
> All together, that means that on ARMv7, of which Cortex-A9 is one such
> implementation, vector operations *are* *deprecated* may or may not be
> implement in hardware.  If they are not implemented in hardware *and*
> the VFP subarchitecture reports '3', then you _should_ strictly get a
> SIGILL for them and not have them executed because they are _deprecated_
> *and* _unsupported_ instructions.

So you're saying the current kernel behaviour of emulating the vector
operations on A9 is in error.  I suppose I could agree with that
(although the system response to an undefined instruction is not
specified by the architecture), and I'm glad you finally admit that some
VFP instructions can indeed trap on ARMv7.

That said, we should still be prepared to handle reports of previously
(apparently) working software starting to break if the emulation is
dropped.

-- 
M?ns Rullg?rd
mans at mansr.com


From thomas.petazzoni at free-electrons.com  Wed Apr 10 18:20:35 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Thu, 11 Apr 2013 00:20:35 +0200
Subject: [PATCHv2 09/10] arm: kirkwood: convert db-88f6281 to the Device Tree
In-Reply-To: <1365632436-25367-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1365632436-25367-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1365632436-25367-10-git-send-email-thomas.petazzoni@free-electrons.com>

This commit converts the Marvell DB-88F6281/DB-88F6282 board to the
Device Tree. In fact, the code was supporting two different boards:
one with the 6281 SoC variant, and one with the 6282 SoC variant. The
difference between the two being that the 6281 has one PCIe interface,
and the 6282 has two PCIe interfaces.

In order to handle that with the Device Tree, we create a
'kirkwood-db.dtsi' file that contains the definitions common to both
boards, and 'kirkwood-db-88f6281.dts' and 'kirkwood-db-88f6282.dts'
for the definitions specific to each board. This is similar to what is
done for the QNAP TS219 Kirkwood platform.

We have kept one single Kconfig option, just like it was before.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 arch/arm/boot/dts/Makefile                  |    5 +-
 arch/arm/boot/dts/kirkwood-db-88f6281.dts   |   30 ++++++++
 arch/arm/boot/dts/kirkwood-db-88f6282.dts   |   34 +++++++++
 arch/arm/boot/dts/kirkwood-db.dtsi          |   89 ++++++++++++++++++++++
 arch/arm/mach-kirkwood/Kconfig              |   13 ++--
 arch/arm/mach-kirkwood/Makefile             |    2 +-
 arch/arm/mach-kirkwood/board-db88f6281-bp.c |   26 +++++++
 arch/arm/mach-kirkwood/board-dt.c           |    2 +
 arch/arm/mach-kirkwood/common.h             |    6 ++
 arch/arm/mach-kirkwood/db88f6281-bp-setup.c |  108 ---------------------------
 10 files changed, 199 insertions(+), 116 deletions(-)
 create mode 100644 arch/arm/boot/dts/kirkwood-db-88f6281.dts
 create mode 100644 arch/arm/boot/dts/kirkwood-db-88f6282.dts
 create mode 100644 arch/arm/boot/dts/kirkwood-db.dtsi
 create mode 100644 arch/arm/mach-kirkwood/board-db88f6281-bp.c
 delete mode 100644 arch/arm/mach-kirkwood/db88f6281-bp-setup.c

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 9c62558..f28a23e 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -51,7 +51,10 @@ dtb-$(CONFIG_ARCH_HIGHBANK) += highbank.dtb \
 dtb-$(CONFIG_ARCH_INTEGRATOR) += integratorap.dtb \
 	integratorcp.dtb
 dtb-$(CONFIG_ARCH_LPC32XX) += ea3250.dtb phy3250.dtb
-dtb-$(CONFIG_ARCH_KIRKWOOD) += kirkwood-dns320.dtb \
+dtb-$(CONFIG_ARCH_KIRKWOOD) += \
+	kirkwood-db-88f6281.dtb \
+	kirkwood-db-88f6282.dtb \
+	kirkwood-dns320.dtb \
 	kirkwood-dns325.dtb \
 	kirkwood-dockstar.dtb \
 	kirkwood-dreamplug.dtb \
diff --git a/arch/arm/boot/dts/kirkwood-db-88f6281.dts b/arch/arm/boot/dts/kirkwood-db-88f6281.dts
new file mode 100644
index 0000000..9d777ed
--- /dev/null
+++ b/arch/arm/boot/dts/kirkwood-db-88f6281.dts
@@ -0,0 +1,30 @@
+/*
+ * Marvell DB-88F6281-BP Development Board Setup
+ *
+ * Saeed Bishara <saeed at marvell.com>
+ * Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
+ *
+ * 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.
+ */
+
+/dts-v1/;
+
+/include/ "kirkwood-db.dtsi"
+/include/ "kirkwood-6281.dtsi"
+
+/ {
+	model = "Marvell DB-88F6281-BP Development Board";
+	compatible = "marvell,db-88f6281-bp", "marvell,kirkwood-88f6281", "marvell,kirkwood";
+
+	ocp at f1000000 {
+		pcie-controller {
+			status = "okay";
+
+			pcie at 1,0 {
+				status = "okay";
+			};
+		};
+	};
+};
diff --git a/arch/arm/boot/dts/kirkwood-db-88f6282.dts b/arch/arm/boot/dts/kirkwood-db-88f6282.dts
new file mode 100644
index 0000000..f4c8528
--- /dev/null
+++ b/arch/arm/boot/dts/kirkwood-db-88f6282.dts
@@ -0,0 +1,34 @@
+/*
+ * Marvell DB-88F6282-BP Development Board Setup
+ *
+ * Saeed Bishara <saeed at marvell.com>
+ * Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
+ *
+ * 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.
+ */
+
+/dts-v1/;
+
+/include/ "kirkwood-db.dtsi"
+/include/ "kirkwood-6282.dtsi"
+
+/ {
+	model = "Marvell DB-88F6282-BP Development Board";
+	compatible = "marvell,db-88f6282-bp", "marvell,kirkwood-88f6282", "marvell,kirkwood";
+
+	ocp at f1000000 {
+		pcie-controller {
+			status = "okay";
+
+			pcie at 1,0 {
+				status = "okay";
+			};
+
+			pcie at 2,0 {
+				status = "okay";
+			};
+		};
+	};
+};
diff --git a/arch/arm/boot/dts/kirkwood-db.dtsi b/arch/arm/boot/dts/kirkwood-db.dtsi
new file mode 100644
index 0000000..c87cfb8
--- /dev/null
+++ b/arch/arm/boot/dts/kirkwood-db.dtsi
@@ -0,0 +1,89 @@
+/*
+ * Marvell DB-{88F6281,88F6282}-BP Development Board Setup
+ *
+ * Saeed Bishara <saeed at marvell.com>
+ * Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
+ *
+ * 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.
+ *
+ * This file contains the definitions that are common between the 6281
+ * and 6282 variants of the Marvell Kirkwood Development Board.
+ */
+
+/include/ "kirkwood.dtsi"
+
+/ {
+	memory {
+		device_type = "memory";
+		reg = <0x00000000 0x20000000>; /* 512 MB */
+	};
+
+	chosen {
+		bootargs = "console=ttyS0,115200n8 earlyprintk";
+	};
+
+	ocp at f1000000 {
+		pinctrl at 10000 {
+			pmx_sdio_gpios: pmx-sdio-gpios {
+				marvell,pins = "mpp37", "mpp38";
+				marvell,function = "gpio";
+			};
+		};
+
+		serial at 12000 {
+			pinctrl-0 = <&pmx_uart0>;
+			pinctrl-names = "default";
+			clock-frequency = <200000000>;
+			status = "ok";
+		};
+
+		nand at 3000000 {
+			pinctrl-0 = <&pmx_nand>;
+			pinctrl-names = "default";
+			chip-delay = <25>;
+			status = "okay";
+
+			partition at 0 {
+				label = "uboot";
+				reg = <0x0 0x100000>;
+			};
+
+			partition at 100000 {
+				label = "uImage";
+				reg = <0x100000 0x400000>;
+			};
+
+			partition at 500000 {
+				label = "root";
+				reg = <0x500000 0x1fb00000>;
+			};
+		};
+
+		sata at 80000 {
+			nr-ports = <2>;
+			status = "okay";
+		};
+
+		ehci at 50000 {
+			status = "okay";
+		};
+
+		mvsdio at 90000 {
+			pinctrl-0 = <&pmx_sdio_gpios>;
+			pinctrl-names = "default";
+			wp-gpios = <&gpio1 5 0>;
+			cd-gpios = <&gpio1 6 0>;
+			status = "okay";
+		};
+
+		pcie-controller {
+			status = "okay";
+
+			pcie at 1,0 {
+				status = "okay";
+			};
+		};
+	};
+};
diff --git a/arch/arm/mach-kirkwood/Kconfig b/arch/arm/mach-kirkwood/Kconfig
index 1fe5f2f..b09afca 100644
--- a/arch/arm/mach-kirkwood/Kconfig
+++ b/arch/arm/mach-kirkwood/Kconfig
@@ -2,12 +2,6 @@ if ARCH_KIRKWOOD
 
 menu "Marvell Kirkwood Implementations"
 
-config MACH_DB88F6281_BP
-	bool "Marvell DB-88F6281-BP Development Board"
-	help
-	  Say 'Y' here if you want your kernel to support the
-	  Marvell DB-88F6281-BP Development Board.
-
 config MACH_RD88F6192_NAS
 	bool "Marvell RD-88F6192-NAS Reference Board"
 	help
@@ -58,6 +52,13 @@ config ARCH_KIRKWOOD_DT
 	  Say 'Y' here if you want your kernel to support the
 	  Marvell Kirkwood using flattened device tree.
 
+config MACH_DB88F6281_BP_DT
+	bool "Marvell DB-88F6281-BP Development Board (Flattened Device Tree)"
+	help
+	  Say 'Y' here if you want your kernel to support the Marvell
+	  DB-88F6281-BP and DB-88F6282-BP Development Board (Flattened
+	  Device Tree).
+
 config MACH_GURUPLUG_DT
 	bool "Marvell GuruPlug Reference Board (Flattened Device Tree)"
 	select ARCH_KIRKWOOD_DT
diff --git a/arch/arm/mach-kirkwood/Makefile b/arch/arm/mach-kirkwood/Makefile
index 0e5ccad..e6a88ab 100644
--- a/arch/arm/mach-kirkwood/Makefile
+++ b/arch/arm/mach-kirkwood/Makefile
@@ -1,6 +1,5 @@
 obj-y				+= common.o irq.o pcie.o mpp.o
 
-obj-$(CONFIG_MACH_DB88F6281_BP)		+= db88f6281-bp-setup.o
 obj-$(CONFIG_MACH_RD88F6192_NAS)	+= rd88f6192-nas-setup.o
 obj-$(CONFIG_MACH_RD88F6281)		+= rd88f6281-setup.o
 obj-$(CONFIG_MACH_MV88F6281GTW_GE)	+= mv88f6281gtw_ge-setup.o
@@ -20,6 +19,7 @@ obj-$(CONFIG_MACH_NET5BIG_V2)		+= netxbig_v2-setup.o lacie_v2-common.o
 obj-$(CONFIG_MACH_T5325)		+= t5325-setup.o
 
 obj-$(CONFIG_ARCH_KIRKWOOD_DT)		+= board-dt.o
+obj-$(CONFIG_MACH_DB88F6281_BP_DT)	+= board-db88f6281-bp.o
 obj-$(CONFIG_MACH_DREAMPLUG_DT)		+= board-dreamplug.o
 obj-$(CONFIG_MACH_GURUPLUG_DT)		+= board-guruplug.o
 obj-$(CONFIG_MACH_ICONNECT_DT)		+= board-iconnect.o
diff --git a/arch/arm/mach-kirkwood/board-db88f6281-bp.c b/arch/arm/mach-kirkwood/board-db88f6281-bp.c
new file mode 100644
index 0000000..bffd160
--- /dev/null
+++ b/arch/arm/mach-kirkwood/board-db88f6281-bp.c
@@ -0,0 +1,26 @@
+/*
+ * arch/arm/mach-kirkwood/db88f6281-bp-setup.c
+ *
+ * Saeed Bishara <saeed at marvell.com>
+ *
+ * Marvell DB-88F6281-BP Development Board Setup
+ *
+ * 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/kernel.h>
+#include <linux/init.h>
+#include <linux/of.h>
+#include <linux/mv643xx_eth.h>
+#include "common.h"
+
+static struct mv643xx_eth_platform_data db88f6281_ge00_data = {
+	.phy_addr	= MV643XX_ETH_PHY_ADDR(8),
+};
+
+void __init db88f6281_init(void)
+{
+	kirkwood_ge00_init(&db88f6281_ge00_data);
+}
diff --git a/arch/arm/mach-kirkwood/board-dt.c b/arch/arm/mach-kirkwood/board-dt.c
index ea49476..b6cb807 100644
--- a/arch/arm/mach-kirkwood/board-dt.c
+++ b/arch/arm/mach-kirkwood/board-dt.c
@@ -165,6 +165,8 @@ static const char * const kirkwood_dt_board_compat[] = {
 	"lacie,netspace_v2",
 	"lacie,netspace_lite_v2",
 	"lacie,netspace_mini_v2",
+	"marvell,db-88f6281-bp",
+	"marvell,db-88f6282-bp",
 	"mpl,cec4",
 	"plathome,openblocks-a6",
 	"usi,topkick",
diff --git a/arch/arm/mach-kirkwood/common.h b/arch/arm/mach-kirkwood/common.h
index e24f743..d174ab5 100644
--- a/arch/arm/mach-kirkwood/common.h
+++ b/arch/arm/mach-kirkwood/common.h
@@ -119,6 +119,12 @@ void km_kirkwood_init(void);
 static inline void km_kirkwood_init(void) {};
 #endif
 
+#ifdef CONFIG_MACH_DB88F6281_BP_DT
+void db88f6281_init(void);
+#else
+static inline void db88f6281_init(void) {};
+#endif
+
 #ifdef CONFIG_MACH_MPLCEC4_DT
 void mplcec4_init(void);
 #else
diff --git a/arch/arm/mach-kirkwood/db88f6281-bp-setup.c b/arch/arm/mach-kirkwood/db88f6281-bp-setup.c
deleted file mode 100644
index 5a369fe..0000000
--- a/arch/arm/mach-kirkwood/db88f6281-bp-setup.c
+++ /dev/null
@@ -1,108 +0,0 @@
-/*
- * arch/arm/mach-kirkwood/db88f6281-bp-setup.c
- *
- * Marvell DB-88F6281-BP Development Board Setup
- *
- * 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/kernel.h>
-#include <linux/init.h>
-#include <linux/sizes.h>
-#include <linux/platform_device.h>
-#include <linux/mtd/partitions.h>
-#include <linux/ata_platform.h>
-#include <linux/mv643xx_eth.h>
-#include <asm/mach-types.h>
-#include <asm/mach/arch.h>
-#include <mach/kirkwood.h>
-#include <linux/platform_data/mmc-mvsdio.h>
-#include "common.h"
-#include "mpp.h"
-
-static struct mtd_partition db88f6281_nand_parts[] = {
-	{
-		.name = "u-boot",
-		.offset = 0,
-		.size = SZ_1M
-	}, {
-		.name = "uImage",
-		.offset = MTDPART_OFS_NXTBLK,
-		.size = SZ_4M
-	}, {
-		.name = "root",
-		.offset = MTDPART_OFS_NXTBLK,
-		.size = MTDPART_SIZ_FULL
-	},
-};
-
-static struct mv643xx_eth_platform_data db88f6281_ge00_data = {
-	.phy_addr	= MV643XX_ETH_PHY_ADDR(8),
-};
-
-static struct mv_sata_platform_data db88f6281_sata_data = {
-	.n_ports	= 2,
-};
-
-static struct mvsdio_platform_data db88f6281_mvsdio_data = {
-	.gpio_write_protect	= 37,
-	.gpio_card_detect	= 38,
-};
-
-static unsigned int db88f6281_mpp_config[] __initdata = {
-	MPP0_NF_IO2,
-	MPP1_NF_IO3,
-	MPP2_NF_IO4,
-	MPP3_NF_IO5,
-	MPP4_NF_IO6,
-	MPP5_NF_IO7,
-	MPP18_NF_IO0,
-	MPP19_NF_IO1,
-	MPP37_GPIO,
-	MPP38_GPIO,
-	0
-};
-
-static void __init db88f6281_init(void)
-{
-	/*
-	 * Basic setup. Needs to be called early.
-	 */
-	kirkwood_init();
-	kirkwood_mpp_conf(db88f6281_mpp_config);
-
-	kirkwood_nand_init(ARRAY_AND_SIZE(db88f6281_nand_parts), 25);
-	kirkwood_ehci_init();
-	kirkwood_ge00_init(&db88f6281_ge00_data);
-	kirkwood_sata_init(&db88f6281_sata_data);
-	kirkwood_uart0_init();
-	kirkwood_sdio_init(&db88f6281_mvsdio_data);
-}
-
-static int __init db88f6281_pci_init(void)
-{
-	if (machine_is_db88f6281_bp()) {
-		u32 dev, rev;
-
-		kirkwood_pcie_id(&dev, &rev);
-		if (dev == MV88F6282_DEV_ID)
-			kirkwood_pcie_init(KW_PCIE1 | KW_PCIE0);
-		else
-			kirkwood_pcie_init(KW_PCIE0);
-	}
-	return 0;
-}
-subsys_initcall(db88f6281_pci_init);
-
-MACHINE_START(DB88F6281_BP, "Marvell DB-88F6281-BP Development Board")
-	/* Maintainer: Saeed Bishara <saeed at marvell.com> */
-	.atag_offset	= 0x100,
-	.init_machine	= db88f6281_init,
-	.map_io		= kirkwood_map_io,
-	.init_early	= kirkwood_init_early,
-	.init_irq	= kirkwood_init_irq,
-	.init_time	= kirkwood_timer_init,
-	.restart	= kirkwood_restart,
-MACHINE_END
-- 
1.7.9.5



From thomas.petazzoni at free-electrons.com  Wed Apr 10 18:20:36 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Thu, 11 Apr 2013 00:20:36 +0200
Subject: [PATCHv2 10/10] arm: kirkwood: update defconfig with PCIe driver and
 board updates
In-Reply-To: <1365632436-25367-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1365632436-25367-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1365632436-25367-11-git-send-email-thomas.petazzoni@free-electrons.com>

This commit enables the mvebu PCIe driver in kirkwood_defconfig and
updates various options related to Kirkwood boards.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 arch/arm/configs/kirkwood_defconfig |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/configs/kirkwood_defconfig b/arch/arm/configs/kirkwood_defconfig
index 13482ea..c5275ea 100644
--- a/arch/arm/configs/kirkwood_defconfig
+++ b/arch/arm/configs/kirkwood_defconfig
@@ -10,13 +10,13 @@ CONFIG_MODULES=y
 CONFIG_MODULE_UNLOAD=y
 # CONFIG_BLK_DEV_BSG is not set
 CONFIG_ARCH_KIRKWOOD=y
-CONFIG_MACH_DB88F6281_BP=y
 CONFIG_MACH_RD88F6192_NAS=y
 CONFIG_MACH_RD88F6281=y
 CONFIG_MACH_MV88F6281GTW_GE=y
 CONFIG_MACH_SHEEVAPLUG=y
 CONFIG_MACH_ESATA_SHEEVAPLUG=y
-CONFIG_MACH_GURUPLUG=y
+CONFIG_MACH_DB88F6281_BP_DT=y
+CONFIG_MACH_GURUPLUG_DT=y
 CONFIG_MACH_DREAMPLUG_DT=y
 CONFIG_MACH_ICONNECT_DT=y
 CONFIG_MACH_DLINK_KIRKWOOD_DT=y
@@ -48,8 +48,8 @@ CONFIG_MACH_D2NET_V2=y
 CONFIG_MACH_NET2BIG_V2=y
 CONFIG_MACH_NET5BIG_V2=y
 CONFIG_MACH_T5325=y
-CONFIG_MACH_NSA310_DT=y
 # CONFIG_CPU_FEROCEON_OLD_ID is not set
+CONFIG_PCI_MVEBU=y
 CONFIG_PREEMPT=y
 CONFIG_AEABI=y
 # CONFIG_OABI_COMPAT is not set
-- 
1.7.9.5



From swarren at wwwdotorg.org  Wed Apr 10 18:29:32 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Wed, 10 Apr 2013 16:29:32 -0600
Subject: [PATCH 1/2] ARM: config: tegra: enable T114 SPI
In-Reply-To: <1365594483-20651-1-git-send-email-ldewangan@nvidia.com>
References: <1365594483-20651-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <5165E7CC.1010101@wwwdotorg.org>

On 04/10/2013 05:48 AM, Laxman Dewangan wrote:
> Nvidia Tegra114 has the new spi controller whose driver
> is not compatible with older SoCs. The new driver is added
> for Tegra114 spi controller.

These 2, and the other 2 KBC patches you posted, all look reasonable.
They'll have to wait until 3.11 though.


From swarren at wwwdotorg.org  Wed Apr 10 18:30:37 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Wed, 10 Apr 2013 16:30:37 -0600
Subject: [PATCH] ARM: tegra: Add charger subnode to tps65090 node
In-Reply-To: <1365623505-6309-1-git-send-email-rklein@nvidia.com>
References: <1365623505-6309-1-git-send-email-rklein@nvidia.com>
Message-ID: <5165E80D.7050106@wwwdotorg.org>

On 04/10/2013 01:51 PM, Rhyland Klein wrote:
> The charger is now represented by a distinct subnode of the tps65090
> device. Add this node and enable low current charging with it.

> diff --git a/arch/arm/boot/dts/tegra114-dalmore.dts b/arch/arm/boot/dts/tegra114-dalmore.dts

> +			charger {
> +				compatible = "ti,tps65090-charger";
> +				ti,enable-low-current-chrg;

So does the TPS65090 driver scan all its sub-nodes like a bus an
instantiate anything? That's a little odd since the regulators node is
at the same level, yet doesn't represent a device on that same internal
bus...


From daniel.lezcano at linaro.org  Wed Apr 10 18:35:21 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Thu, 11 Apr 2013 00:35:21 +0200
Subject: [PATCH] ARM: shmobile: r8a7740: Add Suspend-To-RAM modes and
 CPUIdle
In-Reply-To: <1365609107-14290-1-git-send-email-hechtb+renesas@gmail.com>
References: <1365609107-14290-1-git-send-email-hechtb+renesas@gmail.com>
Message-ID: <5165E929.9030309@linaro.org>

On 04/10/2013 05:51 PM, Bastian Hecht wrote:
> We add 2 sleep modes and register a CPUIdle driver that uses them.
> 
> - A3SM PLL0 on/off:     Power domain A3SM that contains the ARM core
>                         and the 2nd level cache with either PLL0 on
> 			or off
> 
> As the suspend to memory mechanism we use A3SM PLL off.
> 
> The setup of the SYSC regarding the external IRQs is taken from
> pm-sh7372.c from Magnus Damm.
> 
> Signed-off-by: Bastian Hecht <hechtb+renesas at gmail.com>
> ---
> Ok I need to add some remarks here:
> 
> First this patch relies on a fix I've sent out today:
> "ARM: hw_breakpoint: Do not use __cpuinitdata for dbg_cpu_pm_nb"
> Without it we can't use suspend at all without a kernel panic.
> 
> Next you can test this in two ways:
> Either add IRQF_NO_SUSPEND to the touchscreen driver st1232 at IRQ registration
> (hack) or extend the irqpin driver to support wakeup devices properly, meaning
> adding suspend and resume callbacks that handle it (proper way). Or you can add
> no_console_suspend to the boot options in r8a7740-armadillo800eva.dts. This way
> you can use the serial console as wakeup device.
> 
> 
>  arch/arm/mach-shmobile/Makefile               |    2 +-
>  arch/arm/mach-shmobile/include/mach/r8a7740.h |    2 +
>  arch/arm/mach-shmobile/pm-r8a7740.c           |  220 ++++++++++++++++++++++++-
>  arch/arm/mach-shmobile/sleep-r8a7740.S        |   68 ++++++++
>  4 files changed, 289 insertions(+), 3 deletions(-)
>  create mode 100644 arch/arm/mach-shmobile/sleep-r8a7740.S
> 
> diff --git a/arch/arm/mach-shmobile/Makefile b/arch/arm/mach-shmobile/Makefile
> index 068f1da..0568894 100644
> --- a/arch/arm/mach-shmobile/Makefile
> +++ b/arch/arm/mach-shmobile/Makefile
> @@ -30,7 +30,7 @@ obj-$(CONFIG_SUSPEND)		+= suspend.o
>  obj-$(CONFIG_CPU_IDLE)		+= cpuidle.o
>  obj-$(CONFIG_ARCH_SHMOBILE)	+= pm-rmobile.o
>  obj-$(CONFIG_ARCH_SH7372)	+= pm-sh7372.o sleep-sh7372.o
> -obj-$(CONFIG_ARCH_R8A7740)	+= pm-r8a7740.o
> +obj-$(CONFIG_ARCH_R8A7740)	+= pm-r8a7740.o sleep-r8a7740.o
>  obj-$(CONFIG_ARCH_R8A7779)	+= pm-r8a7779.o
>  obj-$(CONFIG_ARCH_SH73A0)	+= pm-sh73a0.o
>  
> diff --git a/arch/arm/mach-shmobile/include/mach/r8a7740.h b/arch/arm/mach-shmobile/include/mach/r8a7740.h
> index abdc4d4..ba4707b 100644
> --- a/arch/arm/mach-shmobile/include/mach/r8a7740.h
> +++ b/arch/arm/mach-shmobile/include/mach/r8a7740.h
> @@ -540,6 +540,8 @@ extern void r8a7740_add_standard_devices(void);
>  extern void r8a7740_clock_init(u8 md_ck);
>  extern void r8a7740_pinmux_init(void);
>  extern void r8a7740_pm_init(void);
> +extern void r8a7740_resume(void);
> +extern void r8a7740_shutdown(void);
>  
>  #ifdef CONFIG_PM
>  extern void __init r8a7740_init_pm_domains(void);
> diff --git a/arch/arm/mach-shmobile/pm-r8a7740.c b/arch/arm/mach-shmobile/pm-r8a7740.c
> index 40b87aa..d4613f0 100644
> --- a/arch/arm/mach-shmobile/pm-r8a7740.c
> +++ b/arch/arm/mach-shmobile/pm-r8a7740.c
> @@ -8,10 +8,54 @@
>   * License.  See the file "COPYING" in the main directory of this archive
>   * for more details.
>   */
> +#include <linux/bitrev.h>
>  #include <linux/console.h>
> +#include <linux/cpuidle.h>
> +#include <linux/module.h>
>  #include <linux/suspend.h>
> +#include <linux/io.h>
> +#include <asm/suspend.h>
> +#include <asm/cacheflush.h>
> +#include <asm/cpuidle.h>
> +#include <asm/hardware/cache-l2x0.h>
>  #include <mach/pm-rmobile.h>
>  #include <mach/common.h>
> +#include <mach/r8a7740.h>
> +
> +/* CPGA */
> +#define PLLC01STPCR 	IOMEM(0xe61500c8)
> +#define SYSTBCR		IOMEM(0xe6150024)
> +
> +/* SYSC */
> +#define STBCHR		IOMEM(0xe6180000)
> +#define STBCHRB		IOMEM(0xe6180040)
> +#define SPDCR		IOMEM(0xe6180008)
> +#define SBAR		IOMEM(0xe6180020)
> +#define SRSTFR		IOMEM(0xe61800B4)
> +#define WUPSMSK		IOMEM(0xe618002c)
> +#define WUPSMSK2	IOMEM(0xe6180048)
> +#define WUPSFAC		IOMEM(0xe6180098)
> +#define IRQCR 		IOMEM(0xe618022c)
> +#define IRQCR2 		IOMEM(0xe6180238)
> +#define IRQCR3		IOMEM(0xe6180244)
> +#define IRQCR4		IOMEM(0xe6180248)
> +
> +/* SRSTFR flags */
> +#define RAMST		(1 << 19)
> +#define RCLNKA		(1 << 7)
> +#define RCPRES		(1 << 5)
> +#define RCWD1		(1 << 4)
> +#define RPF		(1 << 0)
> +
> +/* INTC */
> +#define ICR1A		IOMEM(0xe6900000)
> +#define ICR2A		IOMEM(0xe6900004)
> +#define ICR3A		IOMEM(0xe6900008)
> +#define ICR4A		IOMEM(0xe690000c)
> +#define INTMSK00A	IOMEM(0xe6900040)
> +#define INTMSK10A	IOMEM(0xe6900044)
> +#define INTMSK20A	IOMEM(0xe6900048)
> +#define INTMSK30A	IOMEM(0xe690004c)
>  
>  #ifdef CONFIG_PM
>  static int r8a7740_pd_a4s_suspend(void)
> @@ -58,12 +102,183 @@ void __init r8a7740_init_pm_domains(void)
>  	rmobile_init_domains(r8a7740_pm_domains, ARRAY_SIZE(r8a7740_pm_domains));
>  	pm_genpd_add_subdomain_names("A4S", "A3SP");
>  }
> -
>  #endif /* CONFIG_PM */
>  
> +#if defined(CONFIG_SUSPEND) || defined(CONFIG_CPU_IDLE)
> +static void r8a7740_set_reset_vector(unsigned long address)
> +{
> +	__raw_writel(address, SBAR);
> +}
> +
> +static void r8a7740_icr_to_irqcr(unsigned long icr, u16 *irqcr1p, u16 *irqcr2p)
> +{
> +	u16 tmp, irqcr1, irqcr2;
> +	int k;
> +
> +	irqcr1 = 0;
> +	irqcr2 = 0;
> +
> +	/* convert INTCA ICR register layout to SYSC IRQCR+IRQCR2 */
> +	for (k = 0; k <= 7; k++) {
> +		tmp = (icr >> ((7 - k) * 4)) & 0xf;
> +		irqcr1 |= (tmp & 0x03) << (k * 2);
> +		irqcr2 |= (tmp >> 2) << (k * 2);
> +	}
> +
> +	*irqcr1p = irqcr1;
> +	*irqcr2p = irqcr2;
> +}
> +
> +static void r8a7740_setup_sysc(unsigned long msk, unsigned long msk2)
> +{
> +	u16 irqcrx_low, irqcrx_high, irqcry_low, irqcry_high;
> +	unsigned long tmp;
> +
> +	/* read IRQ0A -> IRQ15A mask */
> +	tmp = bitrev8(__raw_readb(INTMSK00A));
> +	tmp |= bitrev8(__raw_readb(INTMSK10A)) << 8;
> +
> +	/* setup WUPSMSK from clocks and external IRQ mask */
> +	msk = (~msk & 0xc030000f) | (tmp << 4);
> +	__raw_writel(msk, WUPSMSK);
> +
> +	/* propage level/edge trigger for external IRQ 0->15 */
> +	r8a7740_icr_to_irqcr(__raw_readl(ICR1A), &irqcrx_low, &irqcry_low);
> +	r8a7740_icr_to_irqcr(__raw_readl(ICR2A), &irqcrx_high, &irqcry_high);
> +	__raw_writel((irqcrx_high << 16) | irqcrx_low, IRQCR);
> +	__raw_writel((irqcry_high << 16) | irqcry_low, IRQCR2);
> +
> +	/* read IRQ16A -> IRQ31A mask */
> +	tmp = bitrev8(__raw_readb(INTMSK20A));
> +	tmp |= bitrev8(__raw_readb(INTMSK30A)) << 8;
> +
> +	/* setup WUPSMSK2 from clocks and external IRQ mask */
> +	msk2 = (~msk2 & 0x00030000) | tmp;
> +	__raw_writel(msk2, WUPSMSK2);
> +
> +	/* propage level/edge trigger for external IRQ 16->31 */
> +	r8a7740_icr_to_irqcr(__raw_readl(ICR3A), &irqcrx_low, &irqcry_low);
> +	r8a7740_icr_to_irqcr(__raw_readl(ICR4A), &irqcrx_high, &irqcry_high);
> +	__raw_writel((irqcrx_high << 16) | irqcrx_low, IRQCR3);
> +	__raw_writel((irqcry_high << 16) | irqcry_low, IRQCR4);
> +}
> +
> +static void r8a7740_prepare_wakeup(void)
> +{
> +	/* clear all flags that lead to a cold boot */
> +	__raw_writel(~(RAMST | RCLNKA | RCPRES | RCWD1 | RPF), SRSTFR);
> +	/* indicate warm boot */
> +	__raw_writel(0x80000000, STBCHRB);
> +	/* clear other flags checked by internal ROM boot loader */
> +	__raw_writel(0x00000000, STBCHR);
> +}
> +
> +static int r8a7740_do_suspend(unsigned long unused)
> +{
> +	/*
> +	 * cpu_suspend() guarantees that all data made it to the L2.
> +	 * Flush it out now and disable the cache controller.
> +	 */
> +	outer_flush_all();
> +	outer_disable();
> +
> +	r8a7740_shutdown();
> +
> +	/* in case WFI fails to enter the low power state, restore things */
> +	outer_resume();
> +
> +	return 0;
> +}
> +
> +static void r8a7740_enter_a3sm_common(int pllc0_on)
> +{
> +	u32 reg32;
> +
> +	if (pllc0_on)
> +		__raw_writel(0, PLLC01STPCR);
> +	else
> +		__raw_writel(1 << 28, PLLC01STPCR);
> +
> +	r8a7740_set_reset_vector(__pa(r8a7740_resume));
> +	r8a7740_prepare_wakeup();
> +	r8a7740_setup_sysc(1 << 0, 0);
> +
> +	/* Activate delayed shutdown of A3SM */
> +	reg32 = __raw_readl(SPDCR);
> +	reg32 |= (1 << 31) | (1 << 12);
> +	__raw_writel(reg32, SPDCR);
> +
> +	/* We activate CPU Core Standby as well here */
> +	reg32 = __raw_readl(SYSTBCR);
> +	reg32 |= (1 << 4);
> +	__raw_writel(reg32, SYSTBCR);
> +
> +	/* Clear Wakeup Factors and do suspend */
> +	reg32 = __raw_readl(WUPSFAC);
> +	cpu_suspend(0, r8a7740_do_suspend);
> +	outer_resume();
> +	reg32 = __raw_readl(WUPSFAC);
> +
> +	/* Clear CPU Core Standby flag for other WFI instructions */
> +	reg32 &= ~(1 << 4);
> +	__raw_writel(reg32, SYSTBCR);
> +
> +}
> +#endif /* CONFIG_SUSPEND || CONFIG_CPU_IDLE */
> +
> +#ifdef CONFIG_CPU_IDLE
> +static int r8a7740_enter_a3sm_pll_on(struct cpuidle_device *dev,
> +					struct cpuidle_driver *drv, int index)
> +{
> +	r8a7740_enter_a3sm_common(1);
> +	return 1;
> +}
> +
> +static int r8a7740_enter_a3sm_pll_off(struct cpuidle_device *dev,
> +					struct cpuidle_driver *drv, int index)
> +{
> +	r8a7740_enter_a3sm_common(0);
> +	return 2;
> +}
> +
> +static struct cpuidle_driver r8a7740_cpuidle_driver = {
> +	.name			= "r8a7740_cpuidle",
> +	.owner			= THIS_MODULE,
> +	.en_core_tk_irqen	= 1,
> +	.state_count		= 3,
> +	.safe_state_index	= 0, /* C1 */
> +	.states[0] = ARM_CPUIDLE_WFI_STATE,
> +	.states[0].enter = shmobile_enter_wfi,

The WFI macro already set a simple enter function doing cpu_do_idle.

We are trying to consolidate the cpuidle drivers across the different
platforms [1]. One of the objective is to move the cpuidle drivers to
drivers/cpuidle, a place where they belong to.

Do you think it is possible you split your code to have one part with
the cpuidle driver and another part with the PM code ?

[1] http://www.spinics.net/lists/arm-kernel/msg237282.html
[2] https://patchwork.kernel.org/patch/2365041/

> +	.states[1] = {
> +		.name = "C2",
> +		.desc = "A3SM PLL ON",
> +		.exit_latency = 40,
> +		.target_residency = 30 + 40,
> +		.flags = CPUIDLE_FLAG_TIME_VALID,
> +		.enter = r8a7740_enter_a3sm_pll_on,
> +	},
> +	.states[2] = {
> +		.name = "C3",
> +		.desc = "A3SM PLL OFF",
> +		.exit_latency = 120,
> +		.target_residency = 30 + 120,
> +		.flags = CPUIDLE_FLAG_TIME_VALID,
> +		.enter = r8a7740_enter_a3sm_pll_off,
> +	},
> +};
> +
> +static void r8a7740_cpuidle_init(void)
> +{
> +	shmobile_cpuidle_set_driver(&r8a7740_cpuidle_driver);
> +}
> +#else
> +static void r8a7740_cpuidle_init(void) {}
> +#endif /* CONFIG_CPU_IDLE */
> +
>  #ifdef CONFIG_SUSPEND
>  static int r8a7740_enter_suspend(suspend_state_t suspend_state)
>  {
> +	r8a7740_enter_a3sm_common(0);
>  	cpu_do_idle();
>  	return 0;
>  }
> @@ -74,9 +289,10 @@ static void r8a7740_suspend_init(void)
>  }
>  #else
>  static void r8a7740_suspend_init(void) {}
> -#endif
> +#endif /* CONFIG_SUSPEND */
>  
>  void __init r8a7740_pm_init(void)
>  {
>  	r8a7740_suspend_init();
> +	r8a7740_cpuidle_init();
>  }
> diff --git a/arch/arm/mach-shmobile/sleep-r8a7740.S b/arch/arm/mach-shmobile/sleep-r8a7740.S
> new file mode 100644
> index 0000000..0ae310d
> --- /dev/null
> +++ b/arch/arm/mach-shmobile/sleep-r8a7740.S
> @@ -0,0 +1,68 @@
> +/*
> + * Low level sleep code for the SoC r8a7740
> + *
> + * Copyright (C) 2013 Bastian Hecht
> + *
> + * This file is subject to the terms and conditions of the GNU General Public
> + * License.  See the file "COPYING" in the main directory of this archive
> + * for more details.
> + */
> +
> +#include <linux/linkage.h>
> +#include <linux/init.h>
> +#include <asm/memory.h>
> +
> +#if defined(CONFIG_SUSPEND) || defined(CONFIG_CPU_IDLE)
> +
> +/* r8a7740_shutdown expects L1 and L2 to be flushed */
> +	.text
> +ENTRY(r8a7740_shutdown)
> +	stmfd   sp!, {r4-r12, lr}
> +
> +	/* make sure the stack stays intact */
> +	bl      v7_flush_dcache_all
> +
> +	/*
> +	 * Clear the SCTLR.C bit to prevent further data cache
> +	 * allocation. Clearing SCTLR.C would make all the data accesses
> +	 * strongly ordered and would not hit the cache.
> +	 */
> +	mrc	p15, 0, r0, c1, c0, 0
> +	bic	r0, r0, #(1 << 2)		@ Disable the C bit
> +	mcr	p15, 0, r0, c1, c0, 0
> +	isb
> +
> +	bl      v7_flush_dcache_all
> +	bl	cpu_v7_do_idle
> +
> +	/* in rare cases when WFI fails we end up here and restore things */
> +	mrc	p15, 0, r0, c1, c0, 0
> +	orr	r0, r0, #(1 << 2)		@ Enable the C bit
> +	mcr	p15, 0, r0, c1, c0, 0
> +	isb
> +
> +	ldmfd   sp!, {r4-r12, pc}
> +ENDPROC(r8a7740)
> +
> +	.text
> +ENTRY(v7_cpu_resume)
> +	bl	v7_invalidate_l1
> +	b	cpu_resume
> +ENDPROC(v7_cpu_resume)
> +
> +/*
> + * The entry point of a warm reboot, used by wakeup scenarios
> + *
> + * The CPU jumps in this case to (0xfffff000 & SBAR), so we need
> + * to align this function properly.
> + * We use a long jump into the text segment and use the physical
> + * address as the MMU is still turned off.
> + */
> +	.align	12
> +	.text
> +ENTRY(r8a7740_resume)
> +	ldr	pc, 1f
> +1:	.long	v7_cpu_resume - PAGE_OFFSET + PLAT_PHYS_OFFSET
> +ENDPROC(r8a7740_resume_core_standby)
> +#endif
> 


-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From arnd at arndb.de  Wed Apr 10 18:35:47 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 11 Apr 2013 00:35:47 +0200
Subject: [PATCH v4 04/14] mfd: Add Samsung PWM/timer master driver
In-Reply-To: <5357756.gKmBOZlWcd@flatron>
References: <1365093431-30621-1-git-send-email-t.figa@samsung.com>
 <2359597.ofbj7Kvioz@flatron> <5357756.gKmBOZlWcd@flatron>
Message-ID: <201304110035.47776.arnd@arndb.de>

On Monday 08 April 2013, Tomasz Figa wrote:
> On Saturday 06 of April 2013 00:24:18 Tomasz Figa wrote:
> > On Friday 05 of April 2013 21:54:21 Arnd Bergmann wrote:
> > > On Friday 05 April 2013, Tomasz Figa wrote:
> > 
> > I'm not sure what you mean by a register-level interface. Something like
> > samsung_pwm_update_reg(reg, mask, val), which modifies bitfields
> > according to the mask and value with appropriate synchronization? If
> > yes, this solves only the problem of access to shared registers.
> > 
> > The other problems that remain:
> > 
> > - negotiation of PWM channels to use for clock source and clock events,
> >   because each board can use different channels for PWM outputs,
> > 
> > - code duplication caused by both of the drivers doing mostly the same
> >   things and or having to parse the same data from device tree,
> > 
> > - both non-DT and DT platforms must be supported,
> > 
> > - how to keep the ability to load PWM driver as a module (or not load it
> > at all when PWM is not used on particular board), while retaining
> > everything that is needed for the clocksource driver in kernel,
> > 
> > - some platforms can't use PWM timers as system clocksources, while on
> >   others this is the only timekeeping hardware available.
> > 
> 
> Hmm. Does anybody have an idea of a better way of implementing this PWM 
> timer support, which solves the above problems?
> 
> This series is a dependency for moving Universal C210 board to DT-based 
> description and it's already almost out of time to get this included for 
> 3.10...
> 

Sorry for not replying earlier. My idea for the register level interface
was to create a platform_device for each PWM, e.g. using the mfd_cell
infrastructure. You can then pass a "struct regmap" as the platform
data for each child of the timer node, and all the DT handling code
can stay in the parent driver.

	Arnd


From swarren at wwwdotorg.org  Wed Apr 10 18:46:54 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Wed, 10 Apr 2013 16:46:54 -0600
Subject: [PATCH v3 07/12] PCI: tegra: Move PCIe driver to drivers/pci/host
In-Reply-To: <20130405060351.GA15848@avionic-0098.mockup.avionic-design.de>
References: <1365000318-28256-1-git-send-email-thierry.reding@avionic-design.de>
 <1365000318-28256-8-git-send-email-thierry.reding@avionic-design.de>
 <515DF096.2000703@wwwdotorg.org> <515DF0D9.40007@wwwdotorg.org>
 <20130405060351.GA15848@avionic-0098.mockup.avionic-design.de>
Message-ID: <5165EBDE.3080202@wwwdotorg.org>

On 04/05/2013 12:03 AM, Thierry Reding wrote:
> On Thu, Apr 04, 2013 at 03:30:01PM -0600, Stephen Warren wrote:
>> On 04/04/2013 03:28 PM, Stephen Warren wrote:
>>> On 04/03/2013 08:45 AM, Thierry Reding wrote:
>>>> Move the PCIe driver from arch/arm/mach-tegra into the
>>>> drivers/pci/host directory. The motivation is to collect
>>>> various host controller drivers in the same location in order
>>>> to facilitate refactoring.
>>>> 
>>>> The Tegra PCIe driver has been largely rewritten, both in
>>>> order to turn it into a proper platform driver and to add MSI
>>>> (based on code by Krishna Kishore <kthota at nvidia.com>) as
>>>> well as device tree support.
>>> 
>>>> arch/arm/boot/dts/tegra20.dtsi                     |   53 +
>>> 
>>> I guess this has to touch both the driver and the dtsi file so
>>> that bisectabilty isn't broken? I guess that's OK.
>> 
>> Actually, can't you move all the *.dts/*.dtsi changes to the
>> start of the series, then put the driver conversion patch last,
>> to avoid any bisectability issues and still keep code and DT
>> changes separate?
> 
> I'm not sure if that'll work. There's this oddity in the Harmony
> DTS where the regulator at 3 is disabled with a comment that this is a
> hack required until board-harmony-pcie.c is removed. If we change
> the DTS before the driver rewrite I think that would break
> requesting the GPIO in the board file.

Hmm. Well I guess that PCIe doesn't really work right now anyway. I
mean the enumeration works, but actual instantiation of the Linux
devices doesn't due to the resource conflict issues, which your new
driver works around.

As such, it might be simplest to just submit all the following in a
single kernel version:

* Delete old Tegra PCI support.
* Add new driver (add not move); this would just touch drivers/pci/host.
* Add all the required new DT content.

That would be basically what you've already posted, except that the DT
changes in this patch can be moved later, and all the arch/arm/*.c
patches can happen earlier if you want.

Does that sound reasonable?

I think you can do:

* All the DT changes first, except the one-line change to enable the
regulator. DT additions for the new PCIe controller would be
status=disabled.

* Add/move the new PCI.

We'd probably still want all this to go through a single tree so (i.e.
the Tegra tree, and not submit the drivers/pci/host addition through
the PCI tree) to avoid ever having 2 drivers at once for the Tegra PCI
controller.


From swarren at wwwdotorg.org  Wed Apr 10 19:05:00 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Wed, 10 Apr 2013 17:05:00 -0600
Subject: [PATCH v3 07/12] PCI: tegra: Move PCIe driver to drivers/pci/host
In-Reply-To: <20130405073703.GB15848@avionic-0098.mockup.avionic-design.de>
References: <1365000318-28256-1-git-send-email-thierry.reding@avionic-design.de>
 <1365000318-28256-8-git-send-email-thierry.reding@avionic-design.de>
 <515DF096.2000703@wwwdotorg.org>
 <20130405073703.GB15848@avionic-0098.mockup.avionic-design.de>
Message-ID: <5165F01C.70703@wwwdotorg.org>

On 04/05/2013 01:37 AM, Thierry Reding wrote:
> On Thu, Apr 04, 2013 at 03:28:54PM -0600, Stephen Warren wrote: 
> [...]
>>> diff --git
>>> a/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt
>>> b/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt
>>
>>>
>>> 
+Required properties:
>> 
>>> +- interrupts: the interrupt outputs of the controller +-
>>> interrupt-names: list of names to identify interrupts
>> 
>> The specification part of this file should define which
>> interrupt outputs must be included in this list, and the order
>> they must appear in the list.
...
>> I believe that the entries in the interrupts property must have a
>> defined order, so I'm not sure whether interrupt-names is useful 
>> here?
> 
> Actually the interrupt-names property is there specifically so that
> the order doesn't matter. The driver uses
> platform_get_irq_byname(), using "intr" and "msi" respectively so
> that they don't have to appear in a specific order. I did this so
> that it is more in line with properties such as clocks and reg.

I believe that reg and interrupts must be possible to interpret
without resorting to reg-names and interrupt-names. In other words,
one must always define a specific order for those properties, and the
-names properties must follow that order. This is different than some
newer bindings where the order is arbitrary and based on whatever
random order the entries appear in *-names.

Given that, I'm not actually convinced that reg-names or
interrupt-names actually make any sense...

For background, see:
http://www.spinics.net/lists/linux-samsung-soc/msg16704.html

>>> +- ranges: describes the translation of addresses for root
>>> ports
>> 
>> Shouldn't there be some discussion re: how the range are expected
>> to be set up so that everything works? We shouldn't expect people
>> to just blindly copy the example without any way of understanding
>> it.
> 
> Possibly. I wouldn't like to go too much into the details, though,
> since the ranges property is not only rather complex but also well
> documented in other places.

The complexity is exactly why this needs to be fully documented. It's
very important to document not only what needs to be there, but also
the rationale behind the choice of exactly what and how to represent
in ranges. This is necessary so that (a) everyone who participated in
the discussion of that ranges definition can ensure that the final
result and rationale is what was expected (b) if somebody else extends
the binding for a new Tegra SoC in the future, they will have enough
information to fully respect the rationale behind the existing binding.

Is ranges really well-documented elsewhere? The raw property certainly
is (although a link would be useful), but I'm not convinced that the
concept of what each cell in the PCIe controller's own internal
address space means actually is documented. Otherwise, why would there
have been such a discussion on this topic?

> But I could add some explanation about which entries are expected
> and how they work together. In this case even order is important.
> The port register entries need to be listed before the 
> non-prefetchable memory window entry, otherwise the ranges parser
> gets confused. How does the following sound?
> 
> - ranges: Describes the translation of addresses for root ports and
> standard PCI regions. The entries must be 6 cells each, where the
> first three cells correspond to the address as described for the
> #address-cells property above, the fourth cell is the physical CPU
> address to translate to and the fifth and six cells are as
> described for the #size-cells property above. - The first two
> entries are expected to translate the addresses for the root port
> registers, which are referenced by the assigned-addresses property
> of the root port nodes (see below). - The remaining entries setup
> the mapping for the standard I/O, memory and

s/setup/set up/

> prefetchable PCI regions. The first cell determines the type of
> region

I assume this definition of "the first cell determines ..." only
applies to these remaining entries, and not the first two entries.
Perhaps prefix that sentence with "For these entries, "?

> that is setup: - 0x81000000: I/O memory region - 0x82000000:
> non-prefetchable memory region - 0xc2000000: prefetchable memory
> region Please refer to the standard PCI bus binding document for a
> more detailed explanation.

That looks OK, yes.


>>> +- clocks: the clock inputs of the controller +- clock-names:
>>> list of names to identify clocks
>> 
>> The specification part of this file should define which clocks
>> are required, and not rely on the example below to do this. I
>> would suggest re-writing this as:
>> 
>> - clocks : Must contain an entry for each entry in clock-names. -
>> clock-names : Must include the following entries: "pex" (The
>> Tegra clock of that name) "afi" (The Tegra clock of that name) 
>> "pcie_xclk" (The Tegra clock of that name) "pll_e" (The Tegra
>> clock of that name)
> 
> Okay, sounds good. Although the Tegra clocks are named somewhat 
> differently.

Hmm. That's true. Perhaps replace "(The Tegra clock of that name)"
with some more logical-level description of what those clocks are used
for by the module.

> "pex" is named "pcie" and "pcie_xclk" is "unassigned" (!) according
> to the nvidia,tegra20-car.txt binding document. Perhaps I should
> update the binding document to replace unassigned with pcie_xclk 
> for clock 74.

The CAR binding shouldn't change for now at least. The clock IDs there
were chosen to match /both/ the CAR clock enable registers /and/ the
CAR module reset registers. Where there isn't an exact 1:1
correspondance between those two sets of registers, that clock ID was
not used, and instead a clock ID >96 was chosen. This was done to
hightlight the lack of 1:1 correspondence. See the explanatory text
before the list, in the CAR binding document.

> And maybe rename pex in the PCIe binding to pcie to match the CAR
> binding?

The PCIe binding should really name its resources based on what makes
sense for the PCIe HW in isolation. pex is probably fine here,
especially if it happens to match some PCIe signal.

>>> +Board DTS: + +	pcie-controller { +		status = "okay"; + +
>>> vdd-supply = <&pci_vdd_reg>; +		pex-clk-supply =
>>> <&pci_clk_reg>; + +		/* root port 00:01.0 */ +		pci at 1,0 { +
>>> status = "okay";
>> 
>> Is it worth putting a comment here stating that the explicit
>> devices included below in this example are entirely optional?
> 
> Would it be acceptable to annotate the 01:00.0 bridge with
> "optional"? Like so:
> 
> pcie-controller { ... pci at 1,0 { ... /* bridge 01:00.0 (optional)
> */ pci at 0,0 {

Yes, that'd be fine.

> Alternatively I could add something like below:
> 
> ---snip---
> 
> Note that devices on the PCI bus are dynamically discovered using
> PCI's bus enumeration and therefore don't need corresponding device
> nodes in DT. However if a device on the PCI bus provides a
> non-probeable bus such as I2C or SPI, device nodes need to be added
> in order to allow the bus' children to be instantiated at the
> proper location in the operating system's device tree (as 
> illustrated by the optional nodes in the example above).
> 
> ---snip---
> 
> Maybe I'll just do both.

Yes, that explanatory text is very useful & good.


From heiko at sntech.de  Wed Apr 10 19:16:41 2013
From: heiko at sntech.de (Heiko =?utf-8?q?St=C3=BCbner?=)
Date: Thu, 11 Apr 2013 01:16:41 +0200
Subject: [PATCH v2] pinctrl: Add pinctrl-s3c24xx driver
Message-ID: <201304110116.41525.heiko@sntech.de>

The s3c24xx pins follow a similar pattern as the other Samsung SoCs and
can therefore reuse the already introduced infrastructure.

The s3c24xx SoCs have one design oddity in that the first 4 external
interrupts do not reside in the eint pending register but in the main
interrupt controller instead. We solve this by forwarding the external
interrupt from the main controller into the irq domain of the pin bank.
The masking/acking of these interrupts is handled in the same way.

Furthermore the S3C2412/2413 SoCs contain another oddity in that they
keep the same 4 eints in the main interrupt controller and eintpend
register and requiring ack operations to happen in both. To solve this
a ctrl_type enum is introduced which can keep the type of controller
in the samsung_pin_ctrl struct for later retrieval.

The ctrl_type enum contains only S3C24XX and S3C2412 types, as the
eint-speciality is currently the only use-case. But it can be expaned
if other SoCs gain special handling requirements later on.

Signed-off-by: Heiko Stuebner <heiko at sntech.de>
---
changes since v1:
- address comments from Tomasz Figa:
  * split handling functions for eints 0-3 for s3c2412 and all others
  * change the handling for s3c2412 eints 0-3 in that they now use
    chained_irq_* for the outer parent interrupt

 .../bindings/pinctrl/samsung-pinctrl.txt           |    8 +
 drivers/gpio/gpio-samsung.c                        |    4 +
 drivers/pinctrl/Kconfig                            |    5 +
 drivers/pinctrl/Makefile                           |    1 +
 drivers/pinctrl/pinctrl-s3c24xx.c                  |  664 ++++++++++++++++++++
 drivers/pinctrl/pinctrl-samsung.c                  |   10 +
 drivers/pinctrl/pinctrl-samsung.h                  |   16 +
 7 files changed, 708 insertions(+), 0 deletions(-)
 create mode 100644 drivers/pinctrl/pinctrl-s3c24xx.c

diff --git a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
index c70fca1..e4443e3 100644
--- a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
@@ -7,6 +7,10 @@ on-chip controllers onto these pads.
 
 Required Properties:
 - compatible: should be one of the following.
+  - "samsung,s3c2413-pinctrl": for S3C64xx-compatible pin-controller,
+  - "samsung,s3c2416-pinctrl": for S3C64xx-compatible pin-controller,
+  - "samsung,s3c2440-pinctrl": for S3C64xx-compatible pin-controller,
+  - "samsung,s3c2450-pinctrl": for S3C64xx-compatible pin-controller,
   - "samsung,s3c64xx-pinctrl": for S3C64xx-compatible pin-controller,
   - "samsung,exynos4210-pinctrl": for Exynos4210 compatible pin-controller.
   - "samsung,exynos4x12-pinctrl": for Exynos4x12 compatible pin-controller.
@@ -106,6 +110,10 @@ B. External Wakeup Interrupts: For supporting external wakeup interrupts, a
 
    - compatible: identifies the type of the external wakeup interrupt controller
      The possible values are:
+     - samsung,s3c2410-wakeup-eint: represents wakeup interrupt controller
+       found on Samsung S3C24xx SoCs except S3C2412 and S3C2413,
+     - samsung,s3c2412-wakeup-eint: represents wakeup interrupt controller
+       found on Samsung S3C2412 and S3C2413 SoCs,
      - samsung,s3c64xx-wakeup-eint: represents wakeup interrupt controller
        found on Samsung S3C64xx SoCs,
      - samsung,exynos4210-wakeup-eint: represents wakeup interrupt controller
diff --git a/drivers/gpio/gpio-samsung.c b/drivers/gpio/gpio-samsung.c
index dc06a6f..73017b9 100644
--- a/drivers/gpio/gpio-samsung.c
+++ b/drivers/gpio/gpio-samsung.c
@@ -3026,6 +3026,10 @@ static __init int samsung_gpiolib_init(void)
 	*/
 	struct device_node *pctrl_np;
 	static const struct of_device_id exynos_pinctrl_ids[] = {
+		{ .compatible = "samsung,s3c2413-pinctrl", },
+		{ .compatible = "samsung,s3c2416-pinctrl", },
+		{ .compatible = "samsung,s3c2440-pinctrl", },
+		{ .compatible = "samsung,s3c2450-pinctrl", },
 		{ .compatible = "samsung,s3c64xx-pinctrl", },
 		{ .compatible = "samsung,exynos4210-pinctrl", },
 		{ .compatible = "samsung,exynos4x12-pinctrl", },
diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index 7402ac9..58d73ac 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -226,6 +226,11 @@ config PINCTRL_EXYNOS5440
 	select PINMUX
 	select PINCONF
 
+config PINCTRL_S3C24XX
+	bool "Samsung S3C24XX SoC pinctrl driver"
+	depends on ARCH_S3C24XX
+	select PINCTRL_SAMSUNG
+
 config PINCTRL_S3C64XX
 	bool "Samsung S3C64XX SoC pinctrl driver"
 	depends on ARCH_S3C64XX
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index 21d34c2..1ccdfd8 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -45,6 +45,7 @@ obj-$(CONFIG_PINCTRL_COH901)	+= pinctrl-coh901.o
 obj-$(CONFIG_PINCTRL_SAMSUNG)	+= pinctrl-samsung.o
 obj-$(CONFIG_PINCTRL_EXYNOS)	+= pinctrl-exynos.o
 obj-$(CONFIG_PINCTRL_EXYNOS5440)	+= pinctrl-exynos5440.o
+obj-$(CONFIG_PINCTRL_S3C24XX)	+= pinctrl-s3c24xx.o
 obj-$(CONFIG_PINCTRL_S3C64XX)	+= pinctrl-s3c64xx.o
 obj-$(CONFIG_PINCTRL_XWAY)	+= pinctrl-xway.o
 obj-$(CONFIG_PINCTRL_LANTIQ)	+= pinctrl-lantiq.o
diff --git a/drivers/pinctrl/pinctrl-s3c24xx.c b/drivers/pinctrl/pinctrl-s3c24xx.c
new file mode 100644
index 0000000..8dffa2a
--- /dev/null
+++ b/drivers/pinctrl/pinctrl-s3c24xx.c
@@ -0,0 +1,664 @@
+/*
+ * S3C24XX specific support for Samsung pinctrl/gpiolib driver.
+ *
+ * Copyright (c) 2013 Heiko Stuebner <heiko at sntech.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.
+ *
+ * This file contains the SamsungS3C24XX specific information required by the
+ * the Samsung pinctrl/gpiolib driver. It also includes the implementation of
+ * external gpio and wakeup interrupt support.
+ */
+
+#include <linux/module.h>
+#include <linux/device.h>
+#include <linux/interrupt.h>
+#include <linux/irqdomain.h>
+#include <linux/irq.h>
+#include <linux/of_irq.h>
+#include <linux/io.h>
+#include <linux/slab.h>
+#include <linux/err.h>
+
+#include <asm/mach/irq.h>
+
+#include "pinctrl-samsung.h"
+
+#define NUM_EINT	24
+#define NUM_EINT_IRQ	6
+#define EINT_MAX_PER_GROUP	8
+
+#define EINTPEND_REG	0xa8
+#define EINTMASK_REG	0xa4
+
+#define EINT_GROUP(i)		((int)((i) / EINT_MAX_PER_GROUP))
+#define EINT_REG(i)		((EINT_GROUP(i) * 4) + 0x88)
+#define EINT_OFFS(i)		((i) % EINT_MAX_PER_GROUP * 4)
+
+#define EINT_LEVEL_LOW		0
+#define EINT_LEVEL_HIGH		1
+#define EINT_EDGE_FALLING	2
+#define EINT_EDGE_RISING	4
+#define EINT_EDGE_BOTH		6
+#define EINT_MASK		0xf
+
+static struct samsung_pin_bank_type bank_type_1bit = {
+	.fld_width = { 1, 1, },
+	.reg_offset = { 0x00, 0x04, },
+};
+
+static struct samsung_pin_bank_type bank_type_2bit = {
+	.fld_width = { 2, 1, 2, },
+	.reg_offset = { 0x00, 0x04, 0x08, },
+};
+
+#define PIN_BANK_A(pins, reg, id)		\
+	{						\
+		.type		= &bank_type_1bit,	\
+		.pctl_offset	= reg,			\
+		.nr_pins	= pins,			\
+		.eint_type	= EINT_TYPE_NONE,	\
+		.name		= id			\
+	}
+
+#define PIN_BANK_2BIT(pins, reg, id)		\
+	{						\
+		.type		= &bank_type_2bit,	\
+		.pctl_offset	= reg,			\
+		.nr_pins	= pins,			\
+		.eint_type	= EINT_TYPE_NONE,	\
+		.name		= id			\
+	}
+
+#define PIN_BANK_2BIT_EINTW(pins, reg, id, eoffs, emask)\
+	{						\
+		.type		= &bank_type_2bit,	\
+		.pctl_offset	= reg,			\
+		.nr_pins	= pins,			\
+		.eint_type	= EINT_TYPE_WKUP,	\
+		.eint_func	= 2,			\
+		.eint_mask	= emask,		\
+		.eint_offset	= eoffs,		\
+		.name		= id			\
+	}
+
+/**
+ * struct s3c24xx_eint_data: EINT common data
+ * @drvdata: pin controller driver data
+ * @domains: IRQ domains of particular EINT interrupts
+ */
+struct s3c24xx_eint_data {
+	struct samsung_pinctrl_drv_data *drvdata;
+	struct irq_domain *domains[NUM_EINT];
+	int parents[NUM_EINT_IRQ];
+};
+
+struct s3c24xx_eint_domain_data {
+	struct samsung_pin_bank *bank;
+	struct s3c24xx_eint_data *eint_data;
+	bool eint0_3_parent_only;
+};
+
+static int s3c24xx_eint_get_trigger(unsigned int type)
+{
+	int trigger;
+
+	switch (type) {
+	case IRQ_TYPE_EDGE_RISING:
+		trigger = EINT_EDGE_RISING;
+		break;
+	case IRQ_TYPE_EDGE_FALLING:
+		trigger = EINT_EDGE_FALLING;
+		break;
+	case IRQ_TYPE_EDGE_BOTH:
+		trigger = EINT_EDGE_BOTH;
+		break;
+	case IRQ_TYPE_LEVEL_HIGH:
+		trigger = EINT_LEVEL_HIGH;
+		break;
+	case IRQ_TYPE_LEVEL_LOW:
+		trigger = EINT_LEVEL_LOW;
+		break;
+	default:
+		return -EINVAL;
+	}
+
+	return trigger;
+}
+
+static void s3c24xx_eint_set_handler(unsigned int irq, unsigned int type)
+{
+	/* Edge- and level-triggered interrupts need different handlers */
+	if (type & IRQ_TYPE_EDGE_BOTH)
+		__irq_set_handler_locked(irq, handle_edge_irq);
+	else
+		__irq_set_handler_locked(irq, handle_level_irq);
+}
+
+static void s3c24xx_eint_set_function(struct samsung_pinctrl_drv_data *d,
+					struct samsung_pin_bank *bank, int pin)
+{
+	struct samsung_pin_bank_type *bank_type = bank->type;
+	unsigned long flags;
+	void __iomem *reg;
+	u8 shift;
+	u32 mask;
+	u32 val;
+
+	/* Make sure that pin is configured as interrupt */
+	reg = d->virt_base + bank->pctl_offset;
+	shift = pin * bank_type->fld_width[PINCFG_TYPE_FUNC];
+	mask = (1 << bank_type->fld_width[PINCFG_TYPE_FUNC]) - 1;
+
+	spin_lock_irqsave(&bank->slock, flags);
+
+	val = readl(reg);
+	val &= ~(mask << shift);
+	val |= bank->eint_func << shift;
+	writel(val, reg);
+
+	spin_unlock_irqrestore(&bank->slock, flags);
+}
+
+static int s3c24xx_eint_type(struct irq_data *data, unsigned int type)
+{
+	struct samsung_pin_bank *bank = irq_data_get_irq_chip_data(data);
+	struct samsung_pinctrl_drv_data *d = bank->drvdata;
+	int index = bank->eint_offset + data->hwirq;
+	void __iomem *reg;
+	int trigger;
+	u8 shift;
+	u32 val;
+
+	trigger = s3c24xx_eint_get_trigger(type);
+	if (trigger < 0) {
+		dev_err(d->dev, "unsupported external interrupt type\n");
+		return -EINVAL;
+	}
+
+	s3c24xx_eint_set_handler(data->irq, type);
+
+	/* Set up interrupt trigger */
+	reg = d->virt_base + EINT_REG(index);
+	shift = EINT_OFFS(index);
+
+	val = readl(reg);
+	val &= ~(EINT_MASK << shift);
+	val |= trigger << shift;
+	writel(val, reg);
+
+	s3c24xx_eint_set_function(d, bank, data->hwirq);
+
+	return 0;
+}
+
+/* handling of EINTs 0-3 on all except S3C2412 and S3C2413 */
+
+static void s3c2410_eint0_3_ack(struct irq_data *data)
+{
+	struct samsung_pin_bank *bank = irq_data_get_irq_chip_data(data);
+	struct s3c24xx_eint_domain_data *ddata = bank->irq_domain->host_data;
+	struct s3c24xx_eint_data *eint_data = ddata->eint_data;
+	int parent_irq = eint_data->parents[data->hwirq];
+	struct irq_chip *parent_chip = irq_get_chip(parent_irq);
+
+	if (likely(parent_chip))
+		parent_chip->irq_ack(irq_get_irq_data(parent_irq));
+}
+
+static void s3c2410_eint0_3_mask(struct irq_data *data)
+{
+	struct samsung_pin_bank *bank = irq_data_get_irq_chip_data(data);
+	struct s3c24xx_eint_domain_data *ddata = bank->irq_domain->host_data;
+	struct s3c24xx_eint_data *eint_data = ddata->eint_data;
+	int parent_irq = eint_data->parents[data->hwirq];
+	struct irq_chip *parent_chip = irq_get_chip(parent_irq);
+
+	if (likely(parent_chip))
+		parent_chip->irq_mask(irq_get_irq_data(parent_irq));
+}
+
+static void s3c2410_eint0_3_unmask(struct irq_data *data)
+{
+	struct samsung_pin_bank *bank = irq_data_get_irq_chip_data(data);
+	struct s3c24xx_eint_domain_data *ddata = bank->irq_domain->host_data;
+	struct s3c24xx_eint_data *eint_data = ddata->eint_data;
+	int parent_irq = eint_data->parents[data->hwirq];
+	struct irq_chip *parent_chip = irq_get_chip(parent_irq);
+
+	if (likely(parent_chip))
+		parent_chip->irq_unmask(irq_get_irq_data(parent_irq));
+}
+
+static struct irq_chip s3c2410_eint0_3_chip = {
+	.name		= "s3c2410-eint0_3",
+	.irq_ack	= s3c2410_eint0_3_ack,
+	.irq_mask	= s3c2410_eint0_3_mask,
+	.irq_unmask	= s3c2410_eint0_3_unmask,
+	.irq_set_type	= s3c24xx_eint_type,
+};
+
+static void s3c2410_demux_eint0_3(unsigned int irq, struct irq_desc *desc)
+{
+	struct irq_data *data = irq_desc_get_irq_data(desc);
+	struct s3c24xx_eint_data *eint_data = irq_get_handler_data(irq);
+	unsigned int virq;
+
+	/* the first 4 eints have a simple 1 to 1 mapping */
+	virq = irq_linear_revmap(eint_data->domains[data->hwirq], data->hwirq);
+	/* Something must be really wrong if an unmapped EINT
+	 * was unmasked...
+	 */
+	BUG_ON(!virq);
+
+	generic_handle_irq(virq);
+}
+
+/* handling of EINTs 0-3 on S3C2412 and S3C2413 */
+
+static void s3c2412_eint0_3_ack(struct irq_data *data)
+{
+	struct samsung_pin_bank *bank = irq_data_get_irq_chip_data(data);
+	struct samsung_pinctrl_drv_data *d = bank->drvdata;
+
+	unsigned long bitval = 1UL << data->hwirq;
+	writel(bitval, d->virt_base + EINTPEND_REG);
+}
+
+static void s3c2412_eint0_3_mask(struct irq_data *data)
+{
+	struct samsung_pin_bank *bank = irq_data_get_irq_chip_data(data);
+	struct samsung_pinctrl_drv_data *d = bank->drvdata;
+	unsigned long mask;
+
+	mask = readl(d->virt_base + EINTMASK_REG);
+	mask |= (1UL << data->hwirq);
+	writel(mask, d->virt_base + EINTMASK_REG);
+}
+
+static void s3c2412_eint0_3_unmask(struct irq_data *data)
+{
+	struct samsung_pin_bank *bank = irq_data_get_irq_chip_data(data);
+	struct samsung_pinctrl_drv_data *d = bank->drvdata;
+	unsigned long mask;
+
+	mask = readl(d->virt_base + EINTMASK_REG);
+	mask &= ~(1UL << data->hwirq);
+	writel(mask, d->virt_base + EINTMASK_REG);
+}
+
+static struct irq_chip s3c2412_eint0_3_chip = {
+	.name		= "s3c2412-eint0_3",
+	.irq_ack	= s3c2412_eint0_3_ack,
+	.irq_mask	= s3c2412_eint0_3_mask,
+	.irq_unmask	= s3c2412_eint0_3_unmask,
+	.irq_set_type	= s3c24xx_eint_type,
+};
+
+static void s3c2412_demux_eint0_3(unsigned int irq, struct irq_desc *desc)
+{
+	struct irq_chip *chip = irq_get_chip(irq);
+	struct irq_data *data = irq_desc_get_irq_data(desc);
+	struct s3c24xx_eint_data *eint_data = irq_get_handler_data(irq);
+	unsigned int virq;
+
+	chained_irq_enter(chip, desc);
+
+	/* the first 4 eints have a simple 1 to 1 mapping */
+	virq = irq_linear_revmap(eint_data->domains[data->hwirq], data->hwirq);
+	/* Something must be really wrong if an unmapped EINT
+	 * was unmasked...
+	 */
+	BUG_ON(!virq);
+
+	generic_handle_irq(virq);
+
+	chained_irq_exit(chip, desc);
+}
+
+/* handling of all other eints */
+
+static void s3c24xx_eint_ack(struct irq_data *data)
+{
+	struct samsung_pin_bank *bank = irq_data_get_irq_chip_data(data);
+	struct samsung_pinctrl_drv_data *d = bank->drvdata;
+	unsigned char index = bank->eint_offset + data->hwirq;
+
+	writel(1UL << index, d->virt_base + EINTPEND_REG);
+}
+
+static void s3c24xx_eint_mask(struct irq_data *data)
+{
+	struct samsung_pin_bank *bank = irq_data_get_irq_chip_data(data);
+	struct samsung_pinctrl_drv_data *d = bank->drvdata;
+	unsigned char index = bank->eint_offset + data->hwirq;
+	unsigned long mask;
+
+	mask = readl(d->virt_base + EINTMASK_REG);
+	mask |= (1UL << index);
+	writel(mask, d->virt_base + EINTMASK_REG);
+}
+
+static void s3c24xx_eint_unmask(struct irq_data *data)
+{
+	struct samsung_pin_bank *bank = irq_data_get_irq_chip_data(data);
+	struct samsung_pinctrl_drv_data *d = bank->drvdata;
+	unsigned char index = bank->eint_offset + data->hwirq;
+	unsigned long mask;
+
+	mask = readl(d->virt_base + EINTMASK_REG);
+	mask &= ~(1UL << index);
+	writel(mask, d->virt_base + EINTMASK_REG);
+}
+
+static struct irq_chip s3c24xx_eint_chip = {
+	.name		= "s3c-eint",
+	.irq_ack	= s3c24xx_eint_ack,
+	.irq_mask	= s3c24xx_eint_mask,
+	.irq_unmask	= s3c24xx_eint_unmask,
+	.irq_set_type	= s3c24xx_eint_type,
+};
+
+static inline void s3c24xx_demux_eint(unsigned int irq, struct irq_desc *desc,
+				      u32 offset, u32 range)
+{
+	struct irq_chip *chip = irq_get_chip(irq);
+	struct s3c24xx_eint_data *data = irq_get_handler_data(irq);
+	struct samsung_pinctrl_drv_data *d = data->drvdata;
+	unsigned int pend, mask;
+
+	chained_irq_enter(chip, desc);
+
+	pend = readl(d->virt_base + EINTPEND_REG);
+	mask = readl(d->virt_base + EINTMASK_REG);
+
+	pend &= ~mask;
+	pend &= range;
+
+	while (pend) {
+		unsigned int virq;
+
+		irq = __ffs(pend);
+		pend &= ~(1 << irq);
+		virq = irq_linear_revmap(data->domains[irq], irq - offset);
+		/* Something must be really wrong if an unmapped EINT
+		 * was unmasked...
+		 */
+		BUG_ON(!virq);
+
+		generic_handle_irq(virq);
+	}
+
+	chained_irq_exit(chip, desc);
+}
+
+static void s3c24xx_demux_eint4_7(unsigned int irq, struct irq_desc *desc)
+{
+	s3c24xx_demux_eint(irq, desc, 0, 0xf0);
+}
+
+static void s3c24xx_demux_eint8_23(unsigned int irq, struct irq_desc *desc)
+{
+	s3c24xx_demux_eint(irq, desc, 8, 0xffff00);
+}
+
+static irq_flow_handler_t s3c2410_eint_handlers[NUM_EINT_IRQ] = {
+	s3c2410_demux_eint0_3,
+	s3c2410_demux_eint0_3,
+	s3c2410_demux_eint0_3,
+	s3c2410_demux_eint0_3,
+	s3c24xx_demux_eint4_7,
+	s3c24xx_demux_eint8_23,
+};
+
+static irq_flow_handler_t s3c2412_eint_handlers[NUM_EINT_IRQ] = {
+	s3c2412_demux_eint0_3,
+	s3c2412_demux_eint0_3,
+	s3c2412_demux_eint0_3,
+	s3c2412_demux_eint0_3,
+	s3c24xx_demux_eint4_7,
+	s3c24xx_demux_eint8_23,
+};
+
+static int s3c24xx_gpf_irq_map(struct irq_domain *h, unsigned int virq,
+					irq_hw_number_t hw)
+{
+	struct s3c24xx_eint_domain_data *ddata = h->host_data;
+	struct samsung_pin_bank *bank = ddata->bank;
+
+	if (!(bank->eint_mask & (1 << (bank->eint_offset + hw))))
+		return -EINVAL;
+
+	if (hw <= 3) {
+		if (ddata->eint0_3_parent_only)
+			irq_set_chip_and_handler(virq, &s3c2410_eint0_3_chip,
+						 handle_edge_irq);
+		else
+			irq_set_chip_and_handler(virq, &s3c2412_eint0_3_chip,
+						 handle_edge_irq);
+	} else {
+		irq_set_chip_and_handler(virq, &s3c24xx_eint_chip,
+					 handle_edge_irq);
+	}
+	irq_set_chip_data(virq, bank);
+	set_irq_flags(virq, IRQF_VALID);
+	return 0;
+}
+
+static const struct irq_domain_ops s3c24xx_gpf_irq_ops = {
+	.map	= s3c24xx_gpf_irq_map,
+	.xlate	= irq_domain_xlate_twocell,
+};
+
+static int s3c24xx_gpg_irq_map(struct irq_domain *h, unsigned int virq,
+					irq_hw_number_t hw)
+{
+	struct s3c24xx_eint_domain_data *ddata = h->host_data;
+	struct samsung_pin_bank *bank = ddata->bank;
+
+	if (!(bank->eint_mask & (1 << (bank->eint_offset + hw))))
+		return -EINVAL;
+
+	irq_set_chip_and_handler(virq, &s3c24xx_eint_chip, handle_edge_irq);
+	irq_set_chip_data(virq, bank);
+	set_irq_flags(virq, IRQF_VALID);
+	return 0;
+}
+
+static const struct irq_domain_ops s3c24xx_gpg_irq_ops = {
+	.map	= s3c24xx_gpg_irq_map,
+	.xlate	= irq_domain_xlate_twocell,
+};
+
+static const struct of_device_id s3c24xx_eint_irq_ids[] = {
+	{ .compatible = "samsung,s3c2410-wakeup-eint", .data = (void *)1 },
+	{ .compatible = "samsung,s3c2412-wakeup-eint", .data = (void *)0 },
+	{ }
+};
+
+static int s3c24xx_eint_init(struct samsung_pinctrl_drv_data *d)
+{
+	struct device *dev = d->dev;
+	const struct of_device_id *match;
+	struct device_node *eint_np = NULL;
+	struct device_node *np;
+	struct samsung_pin_bank *bank;
+	struct s3c24xx_eint_data *eint_data;
+	const struct irq_domain_ops *ops;
+	unsigned int i;
+	bool eint0_3_parent_only;
+	irq_flow_handler_t *handlers;
+
+	for_each_child_of_node(dev->of_node, np) {
+		match = of_match_node(s3c24xx_eint_irq_ids, np);
+		if (match) {
+			eint_np = np;
+			eint0_3_parent_only = (bool)match->data;
+			break;
+		}
+	}
+	if (!eint_np)
+		return -ENODEV;
+
+	eint_data = devm_kzalloc(dev, sizeof(*eint_data), GFP_KERNEL);
+	if (!eint_data) {
+		dev_err(dev, "could not allocate memory for wkup eint data\n");
+		return -ENOMEM;
+	}
+	eint_data->drvdata = d;
+
+	handlers = eint0_3_parent_only ? s3c2410_eint_handlers
+				       : s3c2412_eint_handlers;
+	for (i = 0; i < NUM_EINT_IRQ; ++i) {
+		unsigned int irq;
+
+		irq = irq_of_parse_and_map(eint_np, i);
+		if (!irq) {
+			dev_err(dev, "failed to get wakeup EINT IRQ %d\n", i);
+			return -ENXIO;
+		}
+
+		eint_data->parents[i] = irq;
+		irq_set_chained_handler(irq, handlers[i]);
+		irq_set_handler_data(irq, eint_data);
+	}
+
+	bank = d->ctrl->pin_banks;
+	for (i = 0; i < d->ctrl->nr_banks; ++i, ++bank) {
+		struct s3c24xx_eint_domain_data *ddata;
+		unsigned int mask;
+		unsigned int irq;
+		unsigned int pin;
+
+		if (bank->eint_type != EINT_TYPE_WKUP)
+			continue;
+
+		ddata = devm_kzalloc(dev, sizeof(*ddata), GFP_KERNEL);
+		if (!ddata) {
+			dev_err(dev, "failed to allocate domain data\n");
+			return -ENOMEM;
+		}
+		ddata->bank = bank;
+		ddata->eint_data = eint_data;
+		ddata->eint0_3_parent_only = eint0_3_parent_only;
+
+		ops = (bank->eint_offset == 0) ? &s3c24xx_gpf_irq_ops
+					       : &s3c24xx_gpg_irq_ops;
+
+		bank->irq_domain = irq_domain_add_linear(bank->of_node,
+				bank->nr_pins, ops, ddata);
+		if (!bank->irq_domain) {
+			dev_err(dev, "wkup irq domain add failed\n");
+			return -ENXIO;
+		}
+
+		irq = bank->eint_offset;
+		mask = bank->eint_mask;
+		for (pin = 0; mask; ++pin, mask >>= 1) {
+			if (irq > NUM_EINT)
+				break;
+			if (!(mask & 1))
+				continue;
+			eint_data->domains[irq] = bank->irq_domain;
+			++irq;
+		}
+	}
+
+	return 0;
+}
+
+static struct samsung_pin_bank s3c2413_pin_banks[] = {
+	PIN_BANK_A(23, 0x000, "gpa"),
+	PIN_BANK_2BIT(11, 0x010, "gpb"),
+	PIN_BANK_2BIT(16, 0x020, "gpc"),
+	PIN_BANK_2BIT(16, 0x030, "gpd"),
+	PIN_BANK_2BIT(16, 0x040, "gpe"),
+	PIN_BANK_2BIT_EINTW(8, 0x050, "gpf", 0, 0xff),
+	PIN_BANK_2BIT_EINTW(16, 0x060, "gpg", 8, 0xffff00),
+	PIN_BANK_2BIT(11, 0x070, "gph"),
+	PIN_BANK_2BIT(13, 0x080, "gpj"),
+};
+
+struct samsung_pin_ctrl s3c2413_pin_ctrl[] = {
+	{
+		.pin_banks	= s3c2413_pin_banks,
+		.nr_banks	= ARRAY_SIZE(s3c2413_pin_banks),
+		.eint_wkup_init = s3c24xx_eint_init,
+		.label		= "S3C2413-GPIO",
+		.type		= S3C2412,
+	},
+};
+
+static struct samsung_pin_bank s3c2416_pin_banks[] = {
+	PIN_BANK_A(27, 0x000, "gpa"),
+	PIN_BANK_2BIT(11, 0x010, "gpb"),
+	PIN_BANK_2BIT(16, 0x020, "gpc"),
+	PIN_BANK_2BIT(16, 0x030, "gpd"),
+	PIN_BANK_2BIT(16, 0x040, "gpe"),
+	PIN_BANK_2BIT_EINTW(8, 0x050, "gpf", 0, 0xff),
+	PIN_BANK_2BIT_EINTW(8, 0x060, "gpg", 8, 0xff00),
+	PIN_BANK_2BIT(15, 0x070, "gph"),
+	PIN_BANK_2BIT(16, 0x0e0, "gpk"),
+	PIN_BANK_2BIT(14, 0x0f0, "gpl"),
+	PIN_BANK_2BIT(2, 0x100, "gpm"),
+};
+
+struct samsung_pin_ctrl s3c2416_pin_ctrl[] = {
+	{
+		.pin_banks	= s3c2416_pin_banks,
+		.nr_banks	= ARRAY_SIZE(s3c2416_pin_banks),
+		.eint_wkup_init = s3c24xx_eint_init,
+		.label		= "S3C2416-GPIO",
+		.type		= S3C24XX,
+	},
+};
+
+static struct samsung_pin_bank s3c2440_pin_banks[] = {
+	PIN_BANK_A(25, 0x000, "gpa"),
+	PIN_BANK_2BIT(11, 0x010, "gpb"),
+	PIN_BANK_2BIT(16, 0x020, "gpc"),
+	PIN_BANK_2BIT(16, 0x030, "gpd"),
+	PIN_BANK_2BIT(16, 0x040, "gpe"),
+	PIN_BANK_2BIT_EINTW(8, 0x050, "gpf", 0, 0xff),
+	PIN_BANK_2BIT_EINTW(16, 0x060, "gpg", 8, 0xffff00),
+	PIN_BANK_2BIT(11, 0x070, "gph"),
+	PIN_BANK_2BIT(13, 0x0d0, "gpj"),
+};
+
+struct samsung_pin_ctrl s3c2440_pin_ctrl[] = {
+	{
+		.pin_banks	= s3c2440_pin_banks,
+		.nr_banks	= ARRAY_SIZE(s3c2440_pin_banks),
+		.eint_wkup_init = s3c24xx_eint_init,
+		.label		= "S3C2440-GPIO",
+		.type		= S3C24XX,
+	},
+};
+
+static struct samsung_pin_bank s3c2450_pin_banks[] = {
+	PIN_BANK_A(28, 0x000, "gpa"),
+	PIN_BANK_2BIT(11, 0x010, "gpb"),
+	PIN_BANK_2BIT(16, 0x020, "gpc"),
+	PIN_BANK_2BIT(16, 0x030, "gpd"),
+	PIN_BANK_2BIT(16, 0x040, "gpe"),
+	PIN_BANK_2BIT_EINTW(8, 0x050, "gpf", 0, 0xff),
+	PIN_BANK_2BIT_EINTW(16, 0x060, "gpg", 8, 0xffff00),
+	PIN_BANK_2BIT(15, 0x070, "gph"),
+	PIN_BANK_2BIT(16, 0x0d0, "gpj"),
+	PIN_BANK_2BIT(16, 0x0e0, "gpk"),
+	PIN_BANK_2BIT(15, 0x0f0, "gpl"),
+	PIN_BANK_2BIT(2, 0x100, "gpm"),
+};
+
+struct samsung_pin_ctrl s3c2450_pin_ctrl[] = {
+	{
+		.pin_banks	= s3c2450_pin_banks,
+		.nr_banks	= ARRAY_SIZE(s3c2450_pin_banks),
+		.eint_wkup_init = s3c24xx_eint_init,
+		.label		= "S3C2450-GPIO",
+		.type		= S3C24XX,
+	},
+};
diff --git a/drivers/pinctrl/pinctrl-samsung.c b/drivers/pinctrl/pinctrl-samsung.c
index e836135..234c32f 100644
--- a/drivers/pinctrl/pinctrl-samsung.c
+++ b/drivers/pinctrl/pinctrl-samsung.c
@@ -977,6 +977,16 @@ static const struct of_device_id samsung_pinctrl_dt_match[] = {
 	{ .compatible = "samsung,s3c64xx-pinctrl",
 		.data = s3c64xx_pin_ctrl },
 #endif
+#ifdef CONFIG_PINCTRL_S3C24XX
+	{ .compatible = "samsung,s3c2413-pinctrl",
+		.data = s3c2413_pin_ctrl },
+	{ .compatible = "samsung,s3c2416-pinctrl",
+		.data = s3c2416_pin_ctrl },
+	{ .compatible = "samsung,s3c2440-pinctrl",
+		.data = s3c2440_pin_ctrl },
+	{ .compatible = "samsung,s3c2450-pinctrl",
+		.data = s3c2450_pin_ctrl },
+#endif
 	{},
 };
 MODULE_DEVICE_TABLE(of, samsung_pinctrl_dt_match);
diff --git a/drivers/pinctrl/pinctrl-samsung.h b/drivers/pinctrl/pinctrl-samsung.h
index 7c7f9eb..8bd317c 100644
--- a/drivers/pinctrl/pinctrl-samsung.h
+++ b/drivers/pinctrl/pinctrl-samsung.h
@@ -81,6 +81,16 @@ enum eint_type {
 	EINT_TYPE_WKUP_MUX,
 };
 
+/**
+ * enum ctrl_type - variances of a pin controller type
+ * @S3C24XX: generic s3c24xx pin handling
+ * @S3C2412: s3c2412-type eints, existing in the main and eint controllers
+ */
+enum ctrl_type {
+	S3C24XX,
+	S3C2412,
+};
+
 /* maximum length of a pin in pin descriptor (example: "gpa0-0") */
 #define PIN_NAME_LENGTH	10
 
@@ -164,6 +174,7 @@ struct samsung_pin_bank {
  * @eint_wkup_init: platform specific callback to setup the external wakeup
  *	interrupts for the controller.
  * @label: for debug information.
+ * @type: type of pin-controller
  */
 struct samsung_pin_ctrl {
 	struct samsung_pin_bank	*pin_banks;
@@ -185,6 +196,7 @@ struct samsung_pin_ctrl {
 	int		(*eint_gpio_init)(struct samsung_pinctrl_drv_data *);
 	int		(*eint_wkup_init)(struct samsung_pinctrl_drv_data *);
 	char		*label;
+	enum ctrl_type	type;
 };
 
 /**
@@ -246,5 +258,9 @@ extern struct samsung_pin_ctrl exynos4210_pin_ctrl[];
 extern struct samsung_pin_ctrl exynos4x12_pin_ctrl[];
 extern struct samsung_pin_ctrl exynos5250_pin_ctrl[];
 extern struct samsung_pin_ctrl s3c64xx_pin_ctrl[];
+extern struct samsung_pin_ctrl s3c2413_pin_ctrl[];
+extern struct samsung_pin_ctrl s3c2416_pin_ctrl[];
+extern struct samsung_pin_ctrl s3c2440_pin_ctrl[];
+extern struct samsung_pin_ctrl s3c2450_pin_ctrl[];
 
 #endif /* __PINCTRL_SAMSUNG_H */
-- 
1.7.2.3



From robherring2 at gmail.com  Wed Apr 10 19:17:31 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Wed, 10 Apr 2013 18:17:31 -0500
Subject: [PATCH v2 02/13] ARM: convert arm/arm64 arch timer to use
 CLKSRC_OF init
In-Reply-To: <20130404055615.GI28297@verge.net.au>
References: <1364854883-5961-1-git-send-email-robherring2@gmail.com>
 <1364854883-5961-3-git-send-email-robherring2@gmail.com>
 <20130404055615.GI28297@verge.net.au>
Message-ID: <5165F30B.1040602@gmail.com>

On 04/04/2013 12:56 AM, Simon Horman wrote:
> On Mon, Apr 01, 2013 at 05:21:12PM -0500, Rob Herring wrote:
>> From: Rob Herring <rob.herring at calxeda.com>
>>
>> This converts arm and arm64 to use CLKSRC_OF DT based initialization for
>> the arch timer. A new function arch_timer_arch_init is added to allow for
>> arch specific setup.
>>
>> This has a side effect of enabling sched_clock on omap5 and exynos5. There
>> should not be any reason not to use the arch timers for sched_clock.
> 
> Would it be possible for you to either delay the removal of
> shmobile_timer_init. In general I am in favour of the following
> approach to wide changes such as this one:

I will simply change shmobile_timer_init to call clocksource_of_init
rather than deleting it. That should keep the new users working and then
it can be deleted latter.

> 1. Add new feature
> 2. Convert users to new feature
> 3. Remove old feature.
> 
> If it is not possible to delay the removal of shmobile_timer_init could you
> update your base such that you also remove its usage from the following
> files:
> 
> arch/arm/mach-shmobile/board-kzm9g-reference.c
> arch/arm/mach-shmobile/setup-r8a73a4.c
> arch/arm/mach-shmobile/setup-r8a7779.c
> arch/arm/mach-shmobile/board-lager.c
> arch/arm/mach-shmobile/board-ape6evm.c
> arch/arm/mach-shmobile/setup-r8a7778.c
> arch/arm/mach-shmobile/board-marzen-reference.c
> arch/arm/mach-shmobile/setup-r8a7790.c
> arch/arm/mach-shmobile/board-bockw.c

Why so many boards? There's been prior discussions about whether to add
DT into existing board files or start with a minimal DT board file and
add to it. The fact that there are 14 mach desc's using
shmobile_timer_init which is a function only used for DT and 17 DT mach
descs total for shmobile tells me perhaps the latter approach is needed.

Either way, it is good to see progress on DT support in shmobile.

Rob

> The above files are all present in the arm-soc/next/boards2 branch
> of the arm-soc tree which has pulled the renesas-boards3-for-v3.10 tag
> of git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git.
> I am happy for you use the later as a base if you wish.
> 
>> Signed-off-by: Rob Herring <rob.herring at calxeda.com>
>> Cc: Russell King <linux at arm.linux.org.uk>
>> Cc: Kukjin Kim <kgene.kim at samsung.com>
>> Cc: Tony Lindgren <tony at atomide.com>
>> Cc: Simon Horman <horms at verge.net.au>
>> Cc: Magnus Damm <magnus.damm at gmail.com>
>> Cc: Catalin Marinas <catalin.marinas at arm.com>
>> Cc: Will Deacon <will.deacon at arm.com>
>> Cc: John Stultz <john.stultz at linaro.org>
>> Cc: Thomas Gleixner <tglx at linutronix.de>
>> Cc: linux-samsung-soc at vger.kernel.org
>> Cc: linux-omap at vger.kernel.org
>> Cc: linux-sh at vger.kernel.org
>> ---
>>  arch/arm/include/asm/arch_timer.h            |   13 +------------
>>  arch/arm/kernel/arch_timer.c                 |   17 +++--------------
>>  arch/arm/mach-exynos/mach-exynos5-dt.c       |    1 -
>>  arch/arm/mach-exynos/mct.c                   |    6 ------
>>  arch/arm/mach-highbank/highbank.c            |    5 +----
>>  arch/arm/mach-omap2/timer.c                  |    5 +----
>>  arch/arm/mach-shmobile/board-kzm9d.c         |    1 -
> 
> I have boot tested the board-kzm9d change on the kzm9d board, it seems fine.
> 
>>  arch/arm/mach-shmobile/include/mach/common.h |    1 -
>>  arch/arm/mach-shmobile/setup-emev2.c         |    1 -
> 
> I am not able to test the setup-emev2 portion properly at this time,
> booting the kzm9d board without the board-kzm9d file seems broken without
> your patch. However, your change seems reasonable to me.
> 
>>  arch/arm/mach-shmobile/setup-r8a7740.c       |    1 -
> 
> I am not able to test the setup-r8a7740 portion properly at this time,
> booting the armadillo800eva board without the board-armadillo800eva file
> seems broken without your patch. However, your change seems reasonable to
> me.
> 
>>  arch/arm/mach-shmobile/setup-sh7372.c        |    1 -
> 
> I am not able to test the setup-sh7372 portion properly at this time,
> booting the mackerel board without the board-mackerel file seems broken without
> your patch. However, your change seems reasonable to me.
> 
>>  arch/arm/mach-shmobile/setup-sh73a0.c        |    1 -
> 
> I have boot tested the setup-sh73a0 change on the kzm9g board, it seems fine.
> 
> 
> The tests above were made by merging
> 
> git://sources.calxeda.com/kernel/linux.git arm-timers
> head commit: df3f518db302caf9fc0511917c5e9021037f6fcd
> 	     ("devtree: add binding documentation for sp804")
> 
> and the renesas-next-20130403 tag of the renesas tree (URL above).
> 
>>  arch/arm/mach-shmobile/timer.c               |    6 ------
>>  arch/arm/mach-vexpress/v2m.c                 |    7 ++-----
>>  arch/arm/mach-virt/virt.c                    |    9 ---------
>>  arch/arm64/include/asm/arch_timer.h          |    5 +++++
>>  arch/arm64/kernel/time.c                     |    6 ++++--
>>  drivers/clocksource/Kconfig                  |    1 +
>>  drivers/clocksource/arm_arch_timer.c         |   23 +++++++++--------------
>>  include/clocksource/arm_arch_timer.h         |    6 ------
>>  20 files changed, 27 insertions(+), 89 deletions(-)
>>
>> diff --git a/arch/arm/include/asm/arch_timer.h b/arch/arm/include/asm/arch_timer.h
>> index 7ade91d..7c1bfc0 100644
>> --- a/arch/arm/include/asm/arch_timer.h
>> +++ b/arch/arm/include/asm/arch_timer.h
>> @@ -10,8 +10,7 @@
>>  #include <clocksource/arm_arch_timer.h>
>>  
>>  #ifdef CONFIG_ARM_ARCH_TIMER
>> -int arch_timer_of_register(void);
>> -int arch_timer_sched_clock_init(void);
>> +int arch_timer_arch_init(void);
>>  
>>  /*
>>   * These register accessors are marked inline so the compiler can
>> @@ -110,16 +109,6 @@ static inline void __cpuinit arch_counter_set_user_access(void)
>>  
>>  	asm volatile("mcr p15, 0, %0, c14, c1, 0" : : "r" (cntkctl));
>>  }
>> -#else
>> -static inline int arch_timer_of_register(void)
>> -{
>> -	return -ENXIO;
>> -}
>> -
>> -static inline int arch_timer_sched_clock_init(void)
>> -{
>> -	return -ENXIO;
>> -}
>>  #endif
>>  
>>  #endif
>> diff --git a/arch/arm/kernel/arch_timer.c b/arch/arm/kernel/arch_timer.c
>> index a7536d4..dc74048 100644
>> --- a/arch/arm/kernel/arch_timer.c
>> +++ b/arch/arm/kernel/arch_timer.c
>> @@ -39,26 +39,15 @@ static void __init arch_timer_delay_timer_register(void)
>>  	register_current_timer_delay(&arch_delay_timer);
>>  }
>>  
>> -int __init arch_timer_of_register(void)
>> -{
>> -	int ret;
>> -
>> -	ret = arch_timer_init();
>> -	if (ret)
>> -		return ret;
>> -
>> -	arch_timer_delay_timer_register();
>> -
>> -	return 0;
>> -}
>> -
>> -int __init arch_timer_sched_clock_init(void)
>> +int __init arch_timer_arch_init(void)
>>  {
>>          u32 arch_timer_rate = arch_timer_get_rate();
>>  
>>  	if (arch_timer_rate == 0)
>>  		return -ENXIO;
>>  
>> +	arch_timer_delay_timer_register();
>> +
>>  	/* Cache the sched_clock multiplier to save a divide in the hot path. */
>>  	sched_clock_mult = NSEC_PER_SEC / arch_timer_rate;
>>  	sched_clock_func = arch_timer_sched_clock;
>> diff --git a/arch/arm/mach-exynos/mach-exynos5-dt.c b/arch/arm/mach-exynos/mach-exynos5-dt.c
>> index acaeb14..4d97b43 100644
>> --- a/arch/arm/mach-exynos/mach-exynos5-dt.c
>> +++ b/arch/arm/mach-exynos/mach-exynos5-dt.c
>> @@ -216,7 +216,6 @@ DT_MACHINE_START(EXYNOS5_DT, "SAMSUNG EXYNOS5 (Flattened Device Tree)")
>>  	.map_io		= exynos5_dt_map_io,
>>  	.init_machine	= exynos5_dt_machine_init,
>>  	.init_late	= exynos_init_late,
>> -	.init_time	= exynos4_timer_init,
>>  	.dt_compat	= exynos5_dt_compat,
>>  	.restart        = exynos5_restart,
>>  	.reserve	= exynos5_reserve,
>> diff --git a/arch/arm/mach-exynos/mct.c b/arch/arm/mach-exynos/mct.c
>> index c9d6650..04aff6a 100644
>> --- a/arch/arm/mach-exynos/mct.c
>> +++ b/arch/arm/mach-exynos/mct.c
>> @@ -21,7 +21,6 @@
>>  #include <linux/percpu.h>
>>  #include <linux/of.h>
>>  
>> -#include <asm/arch_timer.h>
>>  #include <asm/localtimer.h>
>>  
>>  #include <plat/cpu.h>
>> @@ -469,11 +468,6 @@ static void __init exynos4_timer_resources(void)
>>  
>>  void __init exynos4_timer_init(void)
>>  {
>> -	if (soc_is_exynos5440()) {
>> -		arch_timer_of_register();
>> -		return;
>> -	}
>> -
>>  	if ((soc_is_exynos4210()) || (soc_is_exynos5250()))
>>  		mct_int_type = MCT_INT_SPI;
>>  	else
>> diff --git a/arch/arm/mach-highbank/highbank.c b/arch/arm/mach-highbank/highbank.c
>> index 76c1170..758150e 100644
>> --- a/arch/arm/mach-highbank/highbank.c
>> +++ b/arch/arm/mach-highbank/highbank.c
>> @@ -15,6 +15,7 @@
>>   */
>>  #include <linux/clk.h>
>>  #include <linux/clkdev.h>
>> +#include <linux/clocksource.h>
>>  #include <linux/dma-mapping.h>
>>  #include <linux/io.h>
>>  #include <linux/irq.h>
>> @@ -28,7 +29,6 @@
>>  #include <linux/amba/bus.h>
>>  #include <linux/clk-provider.h>
>>  
>> -#include <asm/arch_timer.h>
>>  #include <asm/cacheflush.h>
>>  #include <asm/cputype.h>
>>  #include <asm/smp_plat.h>
>> @@ -118,9 +118,6 @@ static void __init highbank_timer_init(void)
>>  	sp804_clocksource_and_sched_clock_init(timer_base + 0x20, "timer1");
>>  	sp804_clockevents_init(timer_base, irq, "timer0");
>>  
>> -	arch_timer_of_register();
>> -	arch_timer_sched_clock_init();
>> -
>>  	clocksource_of_init();
>>  }
>>  
>> diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
>> index 4fd8025..7dd6453 100644
>> --- a/arch/arm/mach-omap2/timer.c
>> +++ b/arch/arm/mach-omap2/timer.c
>> @@ -46,7 +46,6 @@
>>  #include <asm/smp_twd.h>
>>  #include <asm/sched_clock.h>
>>  
>> -#include <asm/arch_timer.h>
>>  #include "omap_hwmod.h"
>>  #include "omap_device.h"
>>  #include <plat/counter-32k.h>
>> @@ -624,9 +623,7 @@ void __init omap5_realtime_timer_init(void)
>>  	omap5_sync32k_timer_init();
>>  	realtime_counter_init();
>>  
>> -	err = arch_timer_of_register();
>> -	if (err)
>> -		pr_err("%s: arch_timer_register failed %d\n", __func__, err);
>> +        clocksource_of_init();
>>  }
>>  #endif /* CONFIG_SOC_OMAP5 */
>>  
>> diff --git a/arch/arm/mach-shmobile/board-kzm9d.c b/arch/arm/mach-shmobile/board-kzm9d.c
>> index c254782..c016ccd 100644
>> --- a/arch/arm/mach-shmobile/board-kzm9d.c
>> +++ b/arch/arm/mach-shmobile/board-kzm9d.c
>> @@ -90,6 +90,5 @@ DT_MACHINE_START(KZM9D_DT, "kzm9d")
>>  	.init_irq	= emev2_init_irq,
>>  	.init_machine	= kzm9d_add_standard_devices,
>>  	.init_late	= shmobile_init_late,
>> -	.init_time	= shmobile_timer_init,
>>  	.dt_compat	= kzm9d_boards_compat_dt,
>>  MACHINE_END
>> diff --git a/arch/arm/mach-shmobile/include/mach/common.h b/arch/arm/mach-shmobile/include/mach/common.h
>> index e48606d..5efc0f0 100644
>> --- a/arch/arm/mach-shmobile/include/mach/common.h
>> +++ b/arch/arm/mach-shmobile/include/mach/common.h
>> @@ -2,7 +2,6 @@
>>  #define __ARCH_MACH_COMMON_H
>>  
>>  extern void shmobile_earlytimer_init(void);
>> -extern void shmobile_timer_init(void);
>>  extern void shmobile_setup_delay(unsigned int max_cpu_core_mhz,
>>  			 unsigned int mult, unsigned int div);
>>  struct twd_local_timer;
>> diff --git a/arch/arm/mach-shmobile/setup-emev2.c b/arch/arm/mach-shmobile/setup-emev2.c
>> index 47662a5..4e38a66 100644
>> --- a/arch/arm/mach-shmobile/setup-emev2.c
>> +++ b/arch/arm/mach-shmobile/setup-emev2.c
>> @@ -456,7 +456,6 @@ DT_MACHINE_START(EMEV2_DT, "Generic Emma Mobile EV2 (Flattened Device Tree)")
>>  	.nr_irqs	= NR_IRQS_LEGACY,
>>  	.init_irq	= irqchip_init,
>>  	.init_machine	= emev2_add_standard_devices_dt,
>> -	.init_time	= shmobile_timer_init,
>>  	.dt_compat	= emev2_boards_compat_dt,
>>  MACHINE_END
>>  
>> diff --git a/arch/arm/mach-shmobile/setup-r8a7740.c b/arch/arm/mach-shmobile/setup-r8a7740.c
>> index 8b85d4d..104b474 100644
>> --- a/arch/arm/mach-shmobile/setup-r8a7740.c
>> +++ b/arch/arm/mach-shmobile/setup-r8a7740.c
>> @@ -906,7 +906,6 @@ DT_MACHINE_START(R8A7740_DT, "Generic R8A7740 (Flattened Device Tree)")
>>  	.init_irq	= r8a7740_init_irq,
>>  	.handle_irq	= shmobile_handle_irq_intc,
>>  	.init_machine	= r8a7740_add_standard_devices_dt,
>> -	.init_time	= shmobile_timer_init,
>>  	.dt_compat	= r8a7740_boards_compat_dt,
>>  MACHINE_END
>>  
>> diff --git a/arch/arm/mach-shmobile/setup-sh7372.c b/arch/arm/mach-shmobile/setup-sh7372.c
>> index 59c7146..5502d62 100644
>> --- a/arch/arm/mach-shmobile/setup-sh7372.c
>> +++ b/arch/arm/mach-shmobile/setup-sh7372.c
>> @@ -1175,7 +1175,6 @@ DT_MACHINE_START(SH7372_DT, "Generic SH7372 (Flattened Device Tree)")
>>  	.init_irq	= sh7372_init_irq,
>>  	.handle_irq	= shmobile_handle_irq_intc,
>>  	.init_machine	= sh7372_add_standard_devices_dt,
>> -	.init_time	= shmobile_timer_init,
>>  	.dt_compat	= sh7372_boards_compat_dt,
>>  MACHINE_END
>>  
>> diff --git a/arch/arm/mach-shmobile/setup-sh73a0.c b/arch/arm/mach-shmobile/setup-sh73a0.c
>> index bdab575..ea66316 100644
>> --- a/arch/arm/mach-shmobile/setup-sh73a0.c
>> +++ b/arch/arm/mach-shmobile/setup-sh73a0.c
>> @@ -923,7 +923,6 @@ DT_MACHINE_START(SH73A0_DT, "Generic SH73A0 (Flattened Device Tree)")
>>  	.nr_irqs	= NR_IRQS_LEGACY,
>>  	.init_irq	= sh73a0_init_irq_dt,
>>  	.init_machine	= sh73a0_add_standard_devices_dt,
>> -	.init_time	= shmobile_timer_init,
>>  	.dt_compat	= sh73a0_boards_compat_dt,
>>  MACHINE_END
>>  #endif /* CONFIG_USE_OF */
>> diff --git a/arch/arm/mach-shmobile/timer.c b/arch/arm/mach-shmobile/timer.c
>> index 3d16d4d..add2f15 100644
>> --- a/arch/arm/mach-shmobile/timer.c
>> +++ b/arch/arm/mach-shmobile/timer.c
>> @@ -60,9 +60,3 @@ void __init shmobile_earlytimer_init(void)
>>  {
>>  	late_time_init = shmobile_late_time_init;
>>  }
>> -
>> -void __init shmobile_timer_init(void)
>> -{
>> -	arch_timer_of_register();
>> -	arch_timer_sched_clock_init();
>> -}
>> diff --git a/arch/arm/mach-vexpress/v2m.c b/arch/arm/mach-vexpress/v2m.c
>> index d0ad789..6215717 100644
>> --- a/arch/arm/mach-vexpress/v2m.c
>> +++ b/arch/arm/mach-vexpress/v2m.c
>> @@ -1,6 +1,7 @@
>>  /*
>>   * Versatile Express V2M Motherboard Support
>>   */
>> +#include <linux/clocksource.h>
>>  #include <linux/device.h>
>>  #include <linux/amba/bus.h>
>>  #include <linux/amba/mmci.h>
>> @@ -23,7 +24,6 @@
>>  #include <linux/regulator/machine.h>
>>  #include <linux/vexpress.h>
>>  
>> -#include <asm/arch_timer.h>
>>  #include <asm/mach-types.h>
>>  #include <asm/sizes.h>
>>  #include <asm/mach/arch.h>
>> @@ -446,10 +446,7 @@ static void __init v2m_dt_timer_init(void)
>>  				irq_of_parse_and_map(node, 0));
>>  	}
>>  
>> -	arch_timer_of_register();
>> -
>> -	if (arch_timer_sched_clock_init() != 0)
>> -		versatile_sched_clock_init(vexpress_get_24mhz_clock_base(),
>> +	versatile_sched_clock_init(vexpress_get_24mhz_clock_base(),
>>  				24000000);
>>  }
>>  
>> diff --git a/arch/arm/mach-virt/virt.c b/arch/arm/mach-virt/virt.c
>> index 31666f6..adc0945 100644
>> --- a/arch/arm/mach-virt/virt.c
>> +++ b/arch/arm/mach-virt/virt.c
>> @@ -23,21 +23,13 @@
>>  #include <linux/of_platform.h>
>>  #include <linux/smp.h>
>>  
>> -#include <asm/arch_timer.h>
>>  #include <asm/mach/arch.h>
>> -#include <asm/mach/time.h>
>>  
>>  static void __init virt_init(void)
>>  {
>>  	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
>>  }
>>  
>> -static void __init virt_timer_init(void)
>> -{
>> -	WARN_ON(arch_timer_of_register() != 0);
>> -	WARN_ON(arch_timer_sched_clock_init() != 0);
>> -}
>> -
>>  static const char *virt_dt_match[] = {
>>  	"linux,dummy-virt",
>>  	NULL
>> @@ -47,7 +39,6 @@ extern struct smp_operations virt_smp_ops;
>>  
>>  DT_MACHINE_START(VIRT, "Dummy Virtual Machine")
>>  	.init_irq	= irqchip_init,
>> -	.init_time	= virt_timer_init,
>>  	.init_machine	= virt_init,
>>  	.smp		= smp_ops(virt_smp_ops),
>>  	.dt_compat	= virt_dt_match,
>> diff --git a/arch/arm64/include/asm/arch_timer.h b/arch/arm64/include/asm/arch_timer.h
>> index 91e2a6a..bf6ab242 100644
>> --- a/arch/arm64/include/asm/arch_timer.h
>> +++ b/arch/arm64/include/asm/arch_timer.h
>> @@ -130,4 +130,9 @@ static inline u64 arch_counter_get_cntvct(void)
>>  	return cval;
>>  }
>>  
>> +static inline int arch_timer_arch_init(void)
>> +{
>> +	return 0;
>> +}
>> +
>>  #endif
>> diff --git a/arch/arm64/kernel/time.c b/arch/arm64/kernel/time.c
>> index b0ef18d..a551f88 100644
>> --- a/arch/arm64/kernel/time.c
>> +++ b/arch/arm64/kernel/time.c
>> @@ -32,6 +32,7 @@
>>  #include <linux/timer.h>
>>  #include <linux/irq.h>
>>  #include <linux/delay.h>
>> +#include <linux/clocksource.h>
>>  
>>  #include <clocksource/arm_arch_timer.h>
>>  
>> @@ -77,10 +78,11 @@ void __init time_init(void)
>>  {
>>  	u32 arch_timer_rate;
>>  
>> -	if (arch_timer_init())
>> -		panic("Unable to initialise architected timer.\n");
>> +	clocksource_of_init();
>>  
>>  	arch_timer_rate = arch_timer_get_rate();
>> +	if (!arch_timer_rate)
>> +		panic("Unable to initialise architected timer.\n");
>>  
>>  	/* Cache the sched_clock multiplier to save a divide in the hot path. */
>>  	sched_clock_mult = NSEC_PER_SEC / arch_timer_rate;
>> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
>> index e507ab7..d98e7e1 100644
>> --- a/drivers/clocksource/Kconfig
>> +++ b/drivers/clocksource/Kconfig
>> @@ -62,6 +62,7 @@ config CLKSRC_DBX500_PRCMU_SCHED_CLOCK
>>  
>>  config ARM_ARCH_TIMER
>>  	bool
>> +	select CLKSRC_OF if OF
>>  
>>  config CLKSRC_METAG_GENERIC
>>  	def_bool y if METAG
>> diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
>> index d7ad425..122ff05 100644
>> --- a/drivers/clocksource/arm_arch_timer.c
>> +++ b/drivers/clocksource/arm_arch_timer.c
>> @@ -337,22 +337,14 @@ out:
>>  	return err;
>>  }
>>  
>> -static const struct of_device_id arch_timer_of_match[] __initconst = {
>> -	{ .compatible	= "arm,armv7-timer",	},
>> -	{ .compatible	= "arm,armv8-timer",	},
>> -	{},
>> -};
>> -
>> -int __init arch_timer_init(void)
>> +static void __init arch_timer_init(struct device_node *np)
>>  {
>> -	struct device_node *np;
>>  	u32 freq;
>>  	int i;
>>  
>> -	np = of_find_matching_node(NULL, arch_timer_of_match);
>> -	if (!np) {
>> -		pr_err("arch_timer: can't find DT node\n");
>> -		return -ENODEV;
>> +	if (arch_timer_get_rate()) {
>> +		pr_warn("arch_timer: multiple nodes in dt, skipping\n");
>> +		return;
>>  	}
>>  
>>  	/* Try to determine the frequency from the device tree or CNTFRQ */
>> @@ -378,7 +370,7 @@ int __init arch_timer_init(void)
>>  		if (!arch_timer_ppi[PHYS_SECURE_PPI] ||
>>  		    !arch_timer_ppi[PHYS_NONSECURE_PPI]) {
>>  			pr_warn("arch_timer: No interrupt available, giving up\n");
>> -			return -EINVAL;
>> +			return;
>>  		}
>>  	}
>>  
>> @@ -387,5 +379,8 @@ int __init arch_timer_init(void)
>>  	else
>>  		arch_timer_read_counter = arch_counter_get_cntpct;
>>  
>> -	return arch_timer_register();
>> +	arch_timer_register();
>> +	arch_timer_arch_init();
>>  }
>> +CLOCKSOURCE_OF_DECLARE(armv7_arch_timer, "arm,armv7-timer", arch_timer_init);
>> +CLOCKSOURCE_OF_DECLARE(armv8_arch_timer, "arm,armv8-timer", arch_timer_init);
>> diff --git a/include/clocksource/arm_arch_timer.h b/include/clocksource/arm_arch_timer.h
>> index 2603267..e6c9c4c 100644
>> --- a/include/clocksource/arm_arch_timer.h
>> +++ b/include/clocksource/arm_arch_timer.h
>> @@ -31,18 +31,12 @@
>>  
>>  #ifdef CONFIG_ARM_ARCH_TIMER
>>  
>> -extern int arch_timer_init(void);
>>  extern u32 arch_timer_get_rate(void);
>>  extern u64 (*arch_timer_read_counter)(void);
>>  extern struct timecounter *arch_timer_get_timecounter(void);
>>  
>>  #else
>>  
>> -static inline int arch_timer_init(void)
>> -{
>> -	return -ENXIO;
>> -}
>> -
>>  static inline u32 arch_timer_get_rate(void)
>>  {
>>  	return 0;
>> -- 
>> 1.7.10.4
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>



From nico at fluxnic.net  Wed Apr 10 19:19:34 2013
From: nico at fluxnic.net (Nicolas Pitre)
Date: Wed, 10 Apr 2013 19:19:34 -0400 (EDT)
Subject: Removal of NWFPE in its entirety, and VFP emulation code
In-Reply-To: <yw1xsj2y6n84.fsf@unicorn.mansr.com>
References: <20130410104002.GF14496@n2100.arm.linux.org.uk>
 <yw1xmwt68whw.fsf@unicorn.mansr.com>
 <20130410114229.GH14496@n2100.arm.linux.org.uk>
 <yw1xip3u8uni.fsf@unicorn.mansr.com>
 <20130410185421.GI14496@n2100.arm.linux.org.uk>
 <yw1xehei8a19.fsf@unicorn.mansr.com>
 <20130410200344.GO14496@n2100.arm.linux.org.uk>
 <yw1x61zu866d.fsf@unicorn.mansr.com>
 <20130410210431.GQ14496@n2100.arm.linux.org.uk>
 <yw1x1uai84p9.fsf@unicorn.mansr.com>
 <20130410214509.GT14496@n2100.arm.linux.org.uk>
 <yw1xsj2y6n84.fsf@unicorn.mansr.com>
Message-ID: <alpine.LFD.2.03.1304101912020.17375@syhkavp.arg>

On Wed, 10 Apr 2013, M?ns Rullg?rd wrote:

> Russell King - ARM Linux <linux at arm.linux.org.uk> writes:
> 
> > - A9 is ARMv7.
> > - Vector operations are deprecated in ARMv7.
> > - Whether vector operations are implemented is up to the implementer.
> > - If they aren't implemented, they will cause an undefined instruction
> >   exception.
> > - If the VFP subarchitecture says '3' that means no support code is
> >   required by the implementation.
> >
> > All together, that means that on ARMv7, of which Cortex-A9 is one such
> > implementation, vector operations *are* *deprecated* may or may not be
> > implement in hardware.  If they are not implemented in hardware *and*
> > the VFP subarchitecture reports '3', then you _should_ strictly get a
> > SIGILL for them and not have them executed because they are _deprecated_
> > *and* _unsupported_ instructions.
> 
> So you're saying the current kernel behaviour of emulating the vector
> operations on A9 is in error.  I suppose I could agree with that

Given Russell's explanation above that's my opinion too.

> (although the system response to an undefined instruction is not
> specified by the architecture),

It is defined by POSIX.


Nicolas

From robherring2 at gmail.com  Wed Apr 10 19:23:34 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Wed, 10 Apr 2013 18:23:34 -0500
Subject: [PATCH v2 12/13] ARM: move sp804 and integrator timers to
 drivers/clocksource
In-Reply-To: <515B7AC1.9090403@linaro.org>
References: <1364854883-5961-1-git-send-email-robherring2@gmail.com>
 <1364854883-5961-13-git-send-email-robherring2@gmail.com>
 <515A179A.8020800@linaro.org> <515B3637.8090603@gmail.com>
 <515B7AC1.9090403@linaro.org>
Message-ID: <5165F476.7010807@gmail.com>

On 04/02/2013 07:41 PM, John Stultz wrote:
> On 04/02/2013 12:49 PM, Rob Herring wrote:
>> On 04/01/2013 06:26 PM, John Stultz wrote:
>>> On 04/01/2013 03:21 PM, Rob Herring wrote:
>>>> diff --git a/drivers/clocksource/integrator_ap_timer.c
>>>> b/drivers/clocksource/integrator_ap_timer.c
>>>> new file mode 100644
>>>> index 0000000..05e6204
>>>> --- /dev/null
>>>> +++ b/drivers/clocksource/integrator_ap_timer.c
>>> [snip]
>>
>>>> +CLOCKSOURCE_OF_DECLARE(integrator_ap, "integrator-timer",
>>>> ap_of_timer_init);
>>> So, most of the code here is really clockevent code and not clocksource
>>> code. I realize they were combined in the mach directory you're copying
>>> them from, but if we're going to move all this code out of the arch
>>> directory and into drivers/, I'd like to propose we not dump it all into
>>> drivers/clocksource.
>> Arguably, half the h/w is used for clocksource and half for clockevent
>> so it is equal. :) The sp804 and integrator are somewhat separated that
>> carving them up may be possible, but there are examples like i.MX timers
>> where the implementations are tied more closely together (the clockevent
>> compare value is the clocksource counter + delta).
>>
>> Where do I put the init functions which need to know about both?
> 
> Either have them init themselves via *_initcall, or call out from one to
> the other?
> 
>> What about all the other timers that are already in drivers/clocksource?
> 
> I'm hoping to start moving those out soon.
> 
> 
>>> For more context here see:
>>> http://www.spinics.net/lists/arm-kernel/msg234074.html
>> Seems like this is more a maintainer issue than necessarily what is the
>> right split of code (not that those are completely unrelated). Perhaps
>> splitting maintainership between core and drivers is needed. It
>> definitely seems Thomas cannot keep up with the plethora of ARM related
>> timers and irqchips getting moved into drivers/.
> 
> Well, I'm hoping Daniel can help offload Thomas, but I've still not
> heard back if Thomas is ok with this whole proposal or not.

I'm waiting until there is some clear direction on how or if to split up
clksrc and clkevt drivers. So I will drop this patch for 3.10 unless you
are okay with moving it to drivers/clocksource first and sorting out how
to split things later.

Rob



From mturquette at linaro.org  Wed Apr 10 19:51:15 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Wed, 10 Apr 2013 16:51:15 -0700
Subject: [PATCH] clk: Properly handle notifier return values
In-Reply-To: <a2f153b2-9266-4ddc-94a9-3efbcbe9768c@CH1EHSMHS018.ehs.local>
References: <a2f153b2-9266-4ddc-94a9-3efbcbe9768c@CH1EHSMHS018.ehs.local>
Message-ID: <20130410235115.14528.14648@quantum>

Quoting Soren Brinkmann (2013-04-03 12:17:12)
> Notifiers may return NOTIFY_(OK|DONE|STOP|BAD). The CCF uses an
> inconsistent mix of checking against NOTIFY_STOP or NOTIFY_BAD.
> This inconsistency leaves errors undetected in some cases:
> clk_set_parent() calls __clk_speculate_rates(), which stops when it
> hits a NOTIFIER_BAD (STOP is ignored), and passes this value back to the
> caller.
> clk_set_parent() compares this return value against NOTIFY_STOP only,
> ignoring NOTIFY_BAD returns.
> 
> Use NOTIFY_STOP_MASK to detect a negative notifier return value and
> document all four return value options.
> 
> Signed-off-by: Soren Brinkmann <soren.brinkmann at xilinx.com>

Taken into clk-next.

Thanks for the fix,
Mike

> ---
>  drivers/clk/clk.c   | 10 +++++-----
>  include/linux/clk.h |  8 ++++----
>  2 files changed, 9 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index ed87b24..68bd38c 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -876,16 +876,16 @@ static int __clk_speculate_rates(struct clk *clk, unsigned long parent_rate)
>         else
>                 new_rate = parent_rate;
>  
> -       /* abort the rate change if a driver returns NOTIFY_BAD */
> +       /* abort rate change if a driver returns NOTIFY_BAD or NOTIFY_STOP */
>         if (clk->notifier_count)
>                 ret = __clk_notify(clk, PRE_RATE_CHANGE, clk->rate, new_rate);
>  
> -       if (ret == NOTIFY_BAD)
> +       if (ret & NOTIFY_STOP_MASK)
>                 goto out;
>  
>         hlist_for_each_entry(child, &clk->children, child_node) {
>                 ret = __clk_speculate_rates(child, new_rate);
> -               if (ret == NOTIFY_BAD)
> +               if (ret & NOTIFY_STOP_MASK)
>                         break;
>         }
>  
> @@ -978,7 +978,7 @@ static struct clk *clk_propagate_rate_change(struct clk *clk, unsigned long even
>  
>         if (clk->notifier_count) {
>                 ret = __clk_notify(clk, event, clk->rate, clk->new_rate);
> -               if (ret == NOTIFY_BAD)
> +               if (ret & NOTIFY_STOP_MASK)
>                         fail_clk = clk;
>         }
>  
> @@ -1296,7 +1296,7 @@ int clk_set_parent(struct clk *clk, struct clk *parent)
>                 ret = __clk_speculate_rates(clk, parent->rate);
>  
>         /* abort if a driver objects */
> -       if (ret == NOTIFY_STOP)
> +       if (ret & NOTIFY_STOP_MASK)
>                 goto out;
>  
>         /* only re-parent if the clock is not in use */
> diff --git a/include/linux/clk.h b/include/linux/clk.h
> index b3ac22d..9a6d045 100644
> --- a/include/linux/clk.h
> +++ b/include/linux/clk.h
> @@ -28,16 +28,16 @@ struct clk;
>   * PRE_RATE_CHANGE - called immediately before the clk rate is changed,
>   *     to indicate that the rate change will proceed.  Drivers must
>   *     immediately terminate any operations that will be affected by the
> - *     rate change.  Callbacks may either return NOTIFY_DONE or
> - *     NOTIFY_STOP.
> + *     rate change.  Callbacks may either return NOTIFY_DONE, NOTIFY_OK,
> + *     NOTIFY_STOP or NOTIFY_BAD.
>   *
>   * ABORT_RATE_CHANGE: called if the rate change failed for some reason
>   *     after PRE_RATE_CHANGE.  In this case, all registered notifiers on
>   *     the clk will be called with ABORT_RATE_CHANGE. Callbacks must
> - *     always return NOTIFY_DONE.
> + *     always return NOTIFY_DONE or NOTIFY_OK.
>   *
>   * POST_RATE_CHANGE - called after the clk rate change has successfully
> - *     completed.  Callbacks must always return NOTIFY_DONE.
> + *     completed.  Callbacks must always return NOTIFY_DONE or NOTIFY_OK.
>   *
>   */
>  #define PRE_RATE_CHANGE                        BIT(0)
> -- 
> 1.8.2


From arnd at arndb.de  Wed Apr 10 20:04:46 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 11 Apr 2013 02:04:46 +0200
Subject: [PATCH 04/30] ARM: samsung: move mfc device definition to
 s5p-dev-mfc.c
In-Reply-To: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
References: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
Message-ID: <1365638712-1028578-5-git-send-email-arnd@arndb.de>

For a DT-only build we don't want to compile devs.c, but we do need
the mfc device, which is also referenced by the DT based platforms,
so move it all into one place.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 arch/arm/plat-samsung/devs.c        | 45 -------------------------------------
 arch/arm/plat-samsung/s5p-dev-mfc.c | 42 +++++++++++++++++++++++++++++++++-
 2 files changed, 41 insertions(+), 46 deletions(-)

diff --git a/arch/arm/plat-samsung/devs.c b/arch/arm/plat-samsung/devs.c
index e1124d9..4cf660e 100644
--- a/arch/arm/plat-samsung/devs.c
+++ b/arch/arm/plat-samsung/devs.c
@@ -878,51 +878,6 @@ void __init s3c24xx_fb_set_platdata(struct s3c2410fb_mach_info *pd)
 }
 #endif /* CONFIG_PLAT_S3C24XX */
 
-/* MFC */
-
-#ifdef CONFIG_S5P_DEV_MFC
-static struct resource s5p_mfc_resource[] = {
-	[0] = DEFINE_RES_MEM(S5P_PA_MFC, SZ_64K),
-	[1] = DEFINE_RES_IRQ(IRQ_MFC),
-};
-
-struct platform_device s5p_device_mfc = {
-	.name		= "s5p-mfc",
-	.id		= -1,
-	.num_resources	= ARRAY_SIZE(s5p_mfc_resource),
-	.resource	= s5p_mfc_resource,
-};
-
-/*
- * MFC hardware has 2 memory interfaces which are modelled as two separate
- * platform devices to let dma-mapping distinguish between them.
- *
- * MFC parent device (s5p_device_mfc) must be registered before memory
- * interface specific devices (s5p_device_mfc_l and s5p_device_mfc_r).
- */
-
-struct platform_device s5p_device_mfc_l = {
-	.name		= "s5p-mfc-l",
-	.id		= -1,
-	.dev		= {
-		.parent			= &s5p_device_mfc.dev,
-		.dma_mask		= &samsung_device_dma_mask,
-		.coherent_dma_mask	= DMA_BIT_MASK(32),
-	},
-};
-
-struct platform_device s5p_device_mfc_r = {
-	.name		= "s5p-mfc-r",
-	.id		= -1,
-	.dev		= {
-		.parent			= &s5p_device_mfc.dev,
-		.dma_mask		= &samsung_device_dma_mask,
-		.coherent_dma_mask	= DMA_BIT_MASK(32),
-	},
-};
-
-#endif /* CONFIG_S5P_DEV_MFC */
-
 /* MIPI CSIS */
 
 #ifdef CONFIG_S5P_DEV_CSIS0
diff --git a/arch/arm/plat-samsung/s5p-dev-mfc.c b/arch/arm/plat-samsung/s5p-dev-mfc.c
index 5ec104b..a93fb6f 100644
--- a/arch/arm/plat-samsung/s5p-dev-mfc.c
+++ b/arch/arm/plat-samsung/s5p-dev-mfc.c
@@ -18,10 +18,50 @@
 #include <linux/of.h>
 
 #include <mach/map.h>
+#include <mach/irqs.h>
 #include <plat/devs.h>
-#include <plat/irqs.h>
 #include <plat/mfc.h>
 
+static struct resource s5p_mfc_resource[] = {
+	[0] = DEFINE_RES_MEM(S5P_PA_MFC, SZ_64K),
+	[1] = DEFINE_RES_IRQ(IRQ_MFC),
+};
+
+struct platform_device s5p_device_mfc = {
+	.name		= "s5p-mfc",
+	.id		= -1,
+	.num_resources	= ARRAY_SIZE(s5p_mfc_resource),
+	.resource	= s5p_mfc_resource,
+};
+
+/*
+ * MFC hardware has 2 memory interfaces which are modelled as two separate
+ * platform devices to let dma-mapping distinguish between them.
+ *
+ * MFC parent device (s5p_device_mfc) must be registered before memory
+ * interface specific devices (s5p_device_mfc_l and s5p_device_mfc_r).
+ */
+
+struct platform_device s5p_device_mfc_l = {
+	.name		= "s5p-mfc-l",
+	.id		= -1,
+	.dev		= {
+		.parent			= &s5p_device_mfc.dev,
+		.dma_mask		= &s5p_device_mfc_l.dev.coherent_dma_mask,
+		.coherent_dma_mask	= DMA_BIT_MASK(32),
+	},
+};
+
+struct platform_device s5p_device_mfc_r = {
+	.name		= "s5p-mfc-r",
+	.id		= -1,
+	.dev		= {
+		.parent			= &s5p_device_mfc.dev,
+		.dma_mask		= &s5p_device_mfc_r.dev.coherent_dma_mask,
+		.coherent_dma_mask	= DMA_BIT_MASK(32),
+	},
+};
+
 struct s5p_mfc_reserved_mem {
 	phys_addr_t	base;
 	unsigned long	size;
-- 
1.8.1.2



From arnd at arndb.de  Wed Apr 10 20:04:44 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 11 Apr 2013 02:04:44 +0200
Subject: [PATCH 02/30] ARM: exynos: prepare for sparse IRQ
In-Reply-To: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
References: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
Message-ID: <1365638712-1028578-3-git-send-email-arnd@arndb.de>

When we enable CONFIG_SPARSE_IRQ, we have to set the value of NR_IRQS in
the machine_desc for legacy IRQ domains, and any file referring to the
number of interrupts or a specific number must include the mach/irqs.h
header file explicitly.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 arch/arm/mach-exynos/dev-uart.c          | 1 +
 arch/arm/mach-exynos/include/mach/irqs.h | 5 ++++-
 arch/arm/mach-exynos/mach-armlex4210.c   | 2 ++
 arch/arm/mach-exynos/mach-exynos4-dt.c   | 3 +++
 arch/arm/mach-exynos/mach-exynos5-dt.c   | 2 ++
 arch/arm/mach-exynos/mach-nuri.c         | 2 ++
 arch/arm/mach-exynos/mach-origen.c       | 2 ++
 arch/arm/mach-exynos/mach-smdk4x12.c     | 2 ++
 arch/arm/mach-exynos/mach-smdkv310.c     | 3 +++
 arch/arm/plat-samsung/irq-vic-timer.c    | 1 +
 arch/arm/plat-samsung/pm.c               | 1 +
 arch/arm/plat-samsung/s5p-irq.c          | 1 +
 12 files changed, 24 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-exynos/dev-uart.c b/arch/arm/mach-exynos/dev-uart.c
index 7c42f4b..c48aff0 100644
--- a/arch/arm/mach-exynos/dev-uart.c
+++ b/arch/arm/mach-exynos/dev-uart.c
@@ -20,6 +20,7 @@
 #include <asm/mach/irq.h>
 #include <mach/hardware.h>
 #include <mach/map.h>
+#include <mach/irqs.h>
 
 #include <plat/devs.h>
 
diff --git a/arch/arm/mach-exynos/include/mach/irqs.h b/arch/arm/mach-exynos/include/mach/irqs.h
index 35fe6d5..c72f59d 100644
--- a/arch/arm/mach-exynos/include/mach/irqs.h
+++ b/arch/arm/mach-exynos/include/mach/irqs.h
@@ -467,7 +467,10 @@
 #define IRQ_TIMER_BASE			(IRQ_GPIO_END + 64)
 
 /* Set the default NR_IRQS */
+#define EXYNOS_NR_IRQS			(IRQ_TIMER_BASE + IRQ_TIMER_COUNT)
 
-#define NR_IRQS				(IRQ_TIMER_BASE + IRQ_TIMER_COUNT)
+#ifndef CONFIG_SPARSE_IRQ
+#define NR_IRQS				EXYNOS_NR_IRQS
+#endif
 
 #endif /* __ASM_ARCH_IRQS_H */
diff --git a/arch/arm/mach-exynos/mach-armlex4210.c b/arch/arm/mach-exynos/mach-armlex4210.c
index 2c23b65..a503e02 100644
--- a/arch/arm/mach-exynos/mach-armlex4210.c
+++ b/arch/arm/mach-exynos/mach-armlex4210.c
@@ -25,6 +25,7 @@
 #include <plat/regs-srom.h>
 #include <plat/sdhci.h>
 
+#include <mach/irqs.h>
 #include <mach/map.h>
 
 #include "common.h"
@@ -196,6 +197,7 @@ static void __init armlex4210_machine_init(void)
 MACHINE_START(ARMLEX4210, "ARMLEX4210")
 	/* Maintainer: Alim Akhtar <alim.akhtar at samsung.com> */
 	.atag_offset	= 0x100,
+	.nr_irqs	= EXYNOS_NR_IRQS,
 	.smp		= smp_ops(exynos_smp_ops),
 	.init_irq	= exynos4_init_irq,
 	.map_io		= armlex4210_map_io,
diff --git a/arch/arm/mach-exynos/mach-exynos4-dt.c b/arch/arm/mach-exynos/mach-exynos4-dt.c
index b9ed834..5f23682 100644
--- a/arch/arm/mach-exynos/mach-exynos4-dt.c
+++ b/arch/arm/mach-exynos/mach-exynos4-dt.c
@@ -20,6 +20,8 @@
 
 #include <asm/mach/arch.h>
 #include <plat/mfc.h>
+#include <mach/irqs.h>
+
 
 #include "common.h"
 
@@ -54,6 +56,7 @@ static void __init exynos4_reserve(void)
 }
 DT_MACHINE_START(EXYNOS4210_DT, "Samsung Exynos4 (Flattened Device Tree)")
 	/* Maintainer: Thomas Abraham <thomas.abraham at linaro.org> */
+	.nr_irqs	= EXYNOS_NR_IRQS,
 	.smp		= smp_ops(exynos_smp_ops),
 	.init_irq	= exynos4_init_irq,
 	.map_io		= exynos4_dt_map_io,
diff --git a/arch/arm/mach-exynos/mach-exynos5-dt.c b/arch/arm/mach-exynos/mach-exynos5-dt.c
index 753b94f..8b7456a 100644
--- a/arch/arm/mach-exynos/mach-exynos5-dt.c
+++ b/arch/arm/mach-exynos/mach-exynos5-dt.c
@@ -16,6 +16,7 @@
 #include <linux/clocksource.h>
 
 #include <asm/mach/arch.h>
+#include <mach/irqs.h>
 #include <mach/regs-pmu.h>
 
 #include <plat/cpu.h>
@@ -76,6 +77,7 @@ static void __init exynos5_reserve(void)
 
 DT_MACHINE_START(EXYNOS5_DT, "SAMSUNG EXYNOS5 (Flattened Device Tree)")
 	/* Maintainer: Kukjin Kim <kgene.kim at samsung.com> */
+	.nr_irqs	= EXYNOS_NR_IRQS,
 	.init_irq	= exynos5_init_irq,
 	.smp		= smp_ops(exynos_smp_ops),
 	.map_io		= exynos5_dt_map_io,
diff --git a/arch/arm/mach-exynos/mach-nuri.c b/arch/arm/mach-exynos/mach-nuri.c
index 0c10852..fbae331 100644
--- a/arch/arm/mach-exynos/mach-nuri.c
+++ b/arch/arm/mach-exynos/mach-nuri.c
@@ -53,6 +53,7 @@
 #include <plat/fimc-core.h>
 #include <plat/camport.h>
 
+#include <mach/irqs.h>
 #include <mach/map.h>
 
 #include "common.h"
@@ -1376,6 +1377,7 @@ static void __init nuri_machine_init(void)
 MACHINE_START(NURI, "NURI")
 	/* Maintainer: Kyungmin Park <kyungmin.park at samsung.com> */
 	.atag_offset	= 0x100,
+	.nr_irqs	= EXYNOS_NR_IRQS,
 	.smp		= smp_ops(exynos_smp_ops),
 	.init_irq	= exynos4_init_irq,
 	.map_io		= nuri_map_io,
diff --git a/arch/arm/mach-exynos/mach-origen.c b/arch/arm/mach-exynos/mach-origen.c
index f662345..a3ee06a 100644
--- a/arch/arm/mach-exynos/mach-origen.c
+++ b/arch/arm/mach-exynos/mach-origen.c
@@ -46,6 +46,7 @@
 #include <plat/hdmi.h>
 
 #include <mach/map.h>
+#include <mach/irqs.h>
 
 #include <drm/exynos_drm.h>
 #include "common.h"
@@ -811,6 +812,7 @@ static void __init origen_machine_init(void)
 MACHINE_START(ORIGEN, "ORIGEN")
 	/* Maintainer: JeongHyeon Kim <jhkim at insignal.co.kr> */
 	.atag_offset	= 0x100,
+	.nr_irqs	= EXYNOS_NR_IRQS,
 	.smp		= smp_ops(exynos_smp_ops),
 	.init_irq	= exynos4_init_irq,
 	.map_io		= origen_map_io,
diff --git a/arch/arm/mach-exynos/mach-smdk4x12.c b/arch/arm/mach-exynos/mach-smdk4x12.c
index 184faa3..3ebd5e4 100644
--- a/arch/arm/mach-exynos/mach-smdk4x12.c
+++ b/arch/arm/mach-exynos/mach-smdk4x12.c
@@ -39,6 +39,7 @@
 #include <plat/regs-serial.h>
 #include <plat/sdhci.h>
 
+#include <mach/irqs.h>
 #include <mach/map.h>
 
 #include <drm/exynos_drm.h>
@@ -384,6 +385,7 @@ MACHINE_START(SMDK4412, "SMDK4412")
 	/* Maintainer: Kukjin Kim <kgene.kim at samsung.com> */
 	/* Maintainer: Changhwan Youn <chaos.youn at samsung.com> */
 	.atag_offset	= 0x100,
+	.nr_irqs	= EXYNOS_NR_IRQS,
 	.smp		= smp_ops(exynos_smp_ops),
 	.init_irq	= exynos4_init_irq,
 	.map_io		= smdk4x12_map_io,
diff --git a/arch/arm/mach-exynos/mach-smdkv310.c b/arch/arm/mach-exynos/mach-smdkv310.c
index ee815a7..5527a28 100644
--- a/arch/arm/mach-exynos/mach-smdkv310.c
+++ b/arch/arm/mach-exynos/mach-smdkv310.c
@@ -43,6 +43,7 @@
 #include <plat/clock.h>
 #include <plat/hdmi.h>
 
+#include <mach/irqs.h>
 #include <mach/map.h>
 
 #include <drm/exynos_drm.h>
@@ -420,6 +421,7 @@ MACHINE_START(SMDKV310, "SMDKV310")
 	/* Maintainer: Kukjin Kim <kgene.kim at samsung.com> */
 	/* Maintainer: Changhwan Youn <chaos.youn at samsung.com> */
 	.atag_offset	= 0x100,
+	.nr_irqs	= EXYNOS_NR_IRQS,
 	.smp		= smp_ops(exynos_smp_ops),
 	.init_irq	= exynos4_init_irq,
 	.map_io		= smdkv310_map_io,
@@ -432,6 +434,7 @@ MACHINE_END
 MACHINE_START(SMDKC210, "SMDKC210")
 	/* Maintainer: Kukjin Kim <kgene.kim at samsung.com> */
 	.atag_offset	= 0x100,
+	.nr_irqs	= EXYNOS_NR_IRQS,
 	.smp		= smp_ops(exynos_smp_ops),
 	.init_irq	= exynos4_init_irq,
 	.map_io		= smdkv310_map_io,
diff --git a/arch/arm/plat-samsung/irq-vic-timer.c b/arch/arm/plat-samsung/irq-vic-timer.c
index 5d205e7..0fceb42 100644
--- a/arch/arm/plat-samsung/irq-vic-timer.c
+++ b/arch/arm/plat-samsung/irq-vic-timer.c
@@ -20,6 +20,7 @@
 #include <linux/io.h>
 
 #include <mach/map.h>
+#include <mach/irqs.h>
 #include <plat/cpu.h>
 #include <plat/irq-vic-timer.h>
 #include <plat/regs-timer.h>
diff --git a/arch/arm/plat-samsung/pm.c b/arch/arm/plat-samsung/pm.c
index 002b147..53210ec 100644
--- a/arch/arm/plat-samsung/pm.c
+++ b/arch/arm/plat-samsung/pm.c
@@ -27,6 +27,7 @@
 #include <plat/regs-serial.h>
 #include <mach/regs-clock.h>
 #include <mach/regs-irq.h>
+#include <mach/irqs.h>
 #include <asm/irq.h>
 
 #include <plat/pm.h>
diff --git a/arch/arm/plat-samsung/s5p-irq.c b/arch/arm/plat-samsung/s5p-irq.c
index 103e371..ff1a760 100644
--- a/arch/arm/plat-samsung/s5p-irq.c
+++ b/arch/arm/plat-samsung/s5p-irq.c
@@ -15,6 +15,7 @@
 #include <linux/io.h>
 #include <linux/irqchip/arm-vic.h>
 
+#include <mach/irqs.h>
 #include <mach/map.h>
 #include <plat/regs-timer.h>
 #include <plat/cpu.h>
-- 
1.8.1.2



From arnd at arndb.de  Wed Apr 10 20:04:49 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 11 Apr 2013 02:04:49 +0200
Subject: [PATCH 07/30] tty: serial/samsung: fix modular build
In-Reply-To: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
References: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
Message-ID: <1365638712-1028578-8-git-send-email-arnd@arndb.de>

There are a few bugs in the samsung serial driver when built as a
loadable module, which makes the console code unavailable, as well as
giving no access to the 'printascii' early debug function. This adds
the appropriate compile time conditionals.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Cc: linux-serial at vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
---
 drivers/tty/serial/samsung.c | 4 ++--
 drivers/tty/serial/samsung.h | 4 +++-
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/tty/serial/samsung.c b/drivers/tty/serial/samsung.c
index 729a60d..a3277ca 100644
--- a/drivers/tty/serial/samsung.c
+++ b/drivers/tty/serial/samsung.c
@@ -894,7 +894,7 @@ console_initcall(s3c24xx_serial_console_init);
 #define S3C24XX_SERIAL_CONSOLE NULL
 #endif
 
-#ifdef CONFIG_CONSOLE_POLL
+#if defined(CONFIG_SERIAL_SAMSUNG_CONSOLE) && defined(CONFIG_CONSOLE_POLL)
 static int s3c24xx_serial_get_poll_char(struct uart_port *port);
 static void s3c24xx_serial_put_poll_char(struct uart_port *port,
 			 unsigned char c);
@@ -918,7 +918,7 @@ static struct uart_ops s3c24xx_serial_ops = {
 	.request_port	= s3c24xx_serial_request_port,
 	.config_port	= s3c24xx_serial_config_port,
 	.verify_port	= s3c24xx_serial_verify_port,
-#ifdef CONFIG_CONSOLE_POLL
+#if defined(CONFIG_SERIAL_SAMSUNG_CONSOLE) && defined(CONFIG_CONSOLE_POLL)
 	.poll_get_char = s3c24xx_serial_get_poll_char,
 	.poll_put_char = s3c24xx_serial_put_poll_char,
 #endif
diff --git a/drivers/tty/serial/samsung.h b/drivers/tty/serial/samsung.h
index 1a4bca3..00a499e 100644
--- a/drivers/tty/serial/samsung.h
+++ b/drivers/tty/serial/samsung.h
@@ -76,7 +76,9 @@ struct s3c24xx_uart_port {
 #define wr_regb(port, reg, val) __raw_writeb(val, portaddr(port, reg))
 #define wr_regl(port, reg, val) __raw_writel(val, portaddr(port, reg))
 
-#ifdef CONFIG_SERIAL_SAMSUNG_DEBUG
+#if defined(CONFIG_SERIAL_SAMSUNG_DEBUG) && \
+    defined(CONFIG_DEBUG_LL) && \
+    !defined(MODULE)
 
 extern void printascii(const char *);
 
-- 
1.8.1.2



From arnd at arndb.de  Wed Apr 10 20:04:53 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 11 Apr 2013 02:04:53 +0200
Subject: [PATCH 11/30] [media] exynos: remove unnecessary header inclusions
In-Reply-To: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
References: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
Message-ID: <1365638712-1028578-12-git-send-email-arnd@arndb.de>

In multiplatform configurations, we cannot include headers
provided by only the exynos platform. Fortunately a number
of drivers that include those headers do not actually need
them, so we can just remove the inclusions.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Cc: linux-media at vger.kernel.org
Cc: Mauro Carvalho Chehab <mchehab at redhat.com>
---
 drivers/media/platform/exynos-gsc/gsc-regs.c | 1 -
 drivers/media/platform/s5p-tv/sii9234_drv.c  | 3 ---
 2 files changed, 4 deletions(-)

diff --git a/drivers/media/platform/exynos-gsc/gsc-regs.c b/drivers/media/platform/exynos-gsc/gsc-regs.c
index 6f5b5a4..e22d147 100644
--- a/drivers/media/platform/exynos-gsc/gsc-regs.c
+++ b/drivers/media/platform/exynos-gsc/gsc-regs.c
@@ -12,7 +12,6 @@
 
 #include <linux/io.h>
 #include <linux/delay.h>
-#include <mach/map.h>
 
 #include "gsc-core.h"
 
diff --git a/drivers/media/platform/s5p-tv/sii9234_drv.c b/drivers/media/platform/s5p-tv/sii9234_drv.c
index d90d228..39b77d2 100644
--- a/drivers/media/platform/s5p-tv/sii9234_drv.c
+++ b/drivers/media/platform/s5p-tv/sii9234_drv.c
@@ -23,9 +23,6 @@
 #include <linux/regulator/machine.h>
 #include <linux/slab.h>
 
-#include <mach/gpio.h>
-#include <plat/gpio-cfg.h>
-
 #include <media/sii9234.h>
 #include <media/v4l2-subdev.h>
 
-- 
1.8.1.2



From arnd at arndb.de  Wed Apr 10 20:04:50 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 11 Apr 2013 02:04:50 +0200
Subject: [PATCH 08/30] i2c: s3c2410: make header file local
In-Reply-To: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
References: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
Message-ID: <1365638712-1028578-9-git-send-email-arnd@arndb.de>

No other file in the kernel besides i2c-s3c2410.c uses the current
plat/regs-iic.h, so we can simply move the header file to live in the
same directory as the driver, as a preparation to multiplatform builds.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Cc: linux-i2c at vger.kernel.org
Cc: Wolfram Sang <wsa at the-dreams.de>
Cc: Ben Dooks <ben-linux at fluff.org>
---
 arch/arm/mach-s3c24xx/mach-rx1950.c                                    | 1 -
 arch/arm/plat-samsung/devs.c                                           | 1 -
 drivers/i2c/busses/i2c-s3c2410.c                                       | 3 ++-
 .../include/plat/regs-iic.h => drivers/i2c/busses/i2c-s3c2410.h        | 0
 4 files changed, 2 insertions(+), 3 deletions(-)
 rename arch/arm/plat-samsung/include/plat/regs-iic.h => drivers/i2c/busses/i2c-s3c2410.h (100%)

diff --git a/arch/arm/mach-s3c24xx/mach-rx1950.c b/arch/arm/mach-s3c24xx/mach-rx1950.c
index e4d67a3..44ca018 100644
--- a/arch/arm/mach-s3c24xx/mach-rx1950.c
+++ b/arch/arm/mach-s3c24xx/mach-rx1950.c
@@ -56,7 +56,6 @@
 #include <plat/cpu.h>
 #include <plat/devs.h>
 #include <plat/pm.h>
-#include <plat/regs-iic.h>
 #include <plat/regs-serial.h>
 #include <plat/samsung-time.h>
 
diff --git a/arch/arm/plat-samsung/devs.c b/arch/arm/plat-samsung/devs.c
index 4cf660e..78be9c0 100644
--- a/arch/arm/plat-samsung/devs.c
+++ b/arch/arm/plat-samsung/devs.c
@@ -62,7 +62,6 @@
 #include <linux/platform_data/usb-s3c2410_udc.h>
 #include <linux/platform_data/usb-ohci-s3c2410.h>
 #include <plat/usb-phy.h>
-#include <plat/regs-iic.h>
 #include <plat/regs-serial.h>
 #include <plat/regs-spi.h>
 #include <linux/platform_data/spi-s3c64xx.h>
diff --git a/drivers/i2c/busses/i2c-s3c2410.c b/drivers/i2c/busses/i2c-s3c2410.c
index f6b880b..d042ad0 100644
--- a/drivers/i2c/busses/i2c-s3c2410.c
+++ b/drivers/i2c/busses/i2c-s3c2410.c
@@ -42,9 +42,10 @@
 
 #include <asm/irq.h>
 
-#include <plat/regs-iic.h>
 #include <linux/platform_data/i2c-s3c2410.h>
 
+#include "i2c-s3c2410.h"
+
 /* Treat S3C2410 as baseline hardware, anything else is supported via quirks */
 #define QUIRK_S3C2440		(1 << 0)
 #define QUIRK_HDMIPHY		(1 << 1)
diff --git a/arch/arm/plat-samsung/include/plat/regs-iic.h b/drivers/i2c/busses/i2c-s3c2410.h
similarity index 100%
rename from arch/arm/plat-samsung/include/plat/regs-iic.h
rename to drivers/i2c/busses/i2c-s3c2410.h
-- 
1.8.1.2



From arnd at arndb.de  Wed Apr 10 20:04:45 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 11 Apr 2013 02:04:45 +0200
Subject: [PATCH 03/30] ARM: exynos: move debug-macro.S to include/debug/
In-Reply-To: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
References: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
Message-ID: <1365638712-1028578-4-git-send-email-arnd@arndb.de>

The move is necessary to support early debug output on exynos
with multiplatform configurations. This implies also moving the
plat/debug-macro.S file, but we are leaving the remaining users of that
file in place, to avoid adding large numbers of extra configuration
options to Kconfig.debug

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 arch/arm/Kconfig.debug                                       |  8 ++++++++
 .../include/mach/debug-macro.S => include/debug/exynos.S}    | 12 ++++++------
 .../include/plat/debug-macro.S => include/debug/samsung.S}   |  2 +-
 arch/arm/mach-s3c24xx/include/mach/debug-macro.S             |  2 +-
 arch/arm/mach-s3c64xx/include/mach/debug-macro.S             |  2 +-
 arch/arm/mach-s5p64x0/include/mach/debug-macro.S             |  2 +-
 arch/arm/mach-s5pc100/include/mach/debug-macro.S             |  2 +-
 arch/arm/mach-s5pv210/include/mach/debug-macro.S             |  2 +-
 8 files changed, 20 insertions(+), 12 deletions(-)
 rename arch/arm/{mach-exynos/include/mach/debug-macro.S => include/debug/exynos.S} (84%)
 rename arch/arm/{plat-samsung/include/plat/debug-macro.S => include/debug/samsung.S} (98%)

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index e00bd4d..54d6fdc 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -348,6 +348,7 @@ choice
 
 	config DEBUG_S3C_UART0
 		depends on PLAT_SAMSUNG
+		select DEBUG_EXYNOS_UART if ARCH_EXYNOS
 		bool "Use S3C UART 0 for low-level debug"
 		help
 		  Say Y here if you want the debug print routines to direct
@@ -359,6 +360,7 @@ choice
 
 	config DEBUG_S3C_UART1
 		depends on PLAT_SAMSUNG
+		select DEBUG_EXYNOS_UART if ARCH_EXYNOS
 		bool "Use S3C UART 1 for low-level debug"
 		help
 		  Say Y here if you want the debug print routines to direct
@@ -370,6 +372,7 @@ choice
 
 	config DEBUG_S3C_UART2
 		depends on PLAT_SAMSUNG
+		select DEBUG_EXYNOS_UART if ARCH_EXYNOS
 		bool "Use S3C UART 2 for low-level debug"
 		help
 		  Say Y here if you want the debug print routines to direct
@@ -381,6 +384,7 @@ choice
 
 	config DEBUG_S3C_UART3
 		depends on PLAT_SAMSUNG && ARCH_EXYNOS
+		select DEBUG_EXYNOS_UART
 		bool "Use S3C UART 3 for low-level debug"
 		help
 		  Say Y here if you want the debug print routines to direct
@@ -510,6 +514,9 @@ choice
 
 endchoice
 
+config DEBUG_EXYNOS_UART
+	bool
+
 config DEBUG_IMX_UART_PORT
 	int "i.MX Debug UART Port Selection" if DEBUG_IMX1_UART || \
 						DEBUG_IMX25_UART || \
@@ -607,6 +614,7 @@ config DEBUG_LL_INCLUDE
 	string
 	default "debug/bcm2835.S" if DEBUG_BCM2835
 	default "debug/cns3xxx.S" if DEBUG_CNS3XXX
+	default "debug/exynos.S" if DEBUG_EXYNOS_UART
 	default "debug/icedcc.S" if DEBUG_ICEDCC
 	default "debug/imx.S" if DEBUG_IMX1_UART || \
 				 DEBUG_IMX25_UART || \
diff --git a/arch/arm/mach-exynos/include/mach/debug-macro.S b/arch/arm/include/debug/exynos.S
similarity index 84%
rename from arch/arm/mach-exynos/include/mach/debug-macro.S
rename to arch/arm/include/debug/exynos.S
index e0c86ea..b17fdb7 100644
--- a/arch/arm/mach-exynos/include/mach/debug-macro.S
+++ b/arch/arm/include/debug/exynos.S
@@ -1,10 +1,7 @@
-/* linux/arch/arm/mach-exynos4/include/mach/debug-macro.S
- *
+/*
  * Copyright (c) 2010-2011 Samsung Electronics Co., Ltd.
  *		http://www.samsung.com
  *
- * Based on arch/arm/mach-s3c6400/include/mach/debug-macro.S
- *
  * 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.
@@ -12,7 +9,10 @@
 
 /* pull in the relevant register and map files. */
 
-#include <mach/map.h>
+#define S3C_ADDR_BASE   0xF6000000
+#define S3C_VA_UART	S3C_ADDR_BASE + 0x01000000
+#define EXYNOS4_PA_UART	0x13800000
+#define EXYNOS5_PA_UART	0x12C00000
 
 	/* note, for the boot process to work we have to keep the UART
 	 * virtual address aligned to an 1MiB boundary for the L1
@@ -36,4 +36,4 @@
 #define fifo_full fifo_full_s5pv210
 #define fifo_level fifo_level_s5pv210
 
-#include <plat/debug-macro.S>
+#include <debug/samsung.S>
diff --git a/arch/arm/plat-samsung/include/plat/debug-macro.S b/arch/arm/include/debug/samsung.S
similarity index 98%
rename from arch/arm/plat-samsung/include/plat/debug-macro.S
rename to arch/arm/include/debug/samsung.S
index f3a9cff..8d8d922 100644
--- a/arch/arm/plat-samsung/include/plat/debug-macro.S
+++ b/arch/arm/include/debug/samsung.S
@@ -9,7 +9,7 @@
  * published by the Free Software Foundation.
 */
 
-#include <plat/regs-serial.h>
+#include <linux/serial_s3c.h>
 
 /* The S5PV210/S5PC110 implementations are as belows. */
 
diff --git a/arch/arm/mach-s3c24xx/include/mach/debug-macro.S b/arch/arm/mach-s3c24xx/include/mach/debug-macro.S
index 13ed33c..2558952 100644
--- a/arch/arm/mach-s3c24xx/include/mach/debug-macro.S
+++ b/arch/arm/mach-s3c24xx/include/mach/debug-macro.S
@@ -98,4 +98,4 @@
 
 /* include the reset of the code which will do the work */
 
-#include <plat/debug-macro.S>
+#include <debug/samsung.S>
diff --git a/arch/arm/mach-s3c64xx/include/mach/debug-macro.S b/arch/arm/mach-s3c64xx/include/mach/debug-macro.S
index c0c076a..dd9ccca 100644
--- a/arch/arm/mach-s3c64xx/include/mach/debug-macro.S
+++ b/arch/arm/mach-s3c64xx/include/mach/debug-macro.S
@@ -35,4 +35,4 @@
  * will be fine with us.
  */
 
-#include <plat/debug-macro.S>
+#include <debug/samsung.S>
diff --git a/arch/arm/mach-s5p64x0/include/mach/debug-macro.S b/arch/arm/mach-s5p64x0/include/mach/debug-macro.S
index e80ba3c..5e2916f 100644
--- a/arch/arm/mach-s5p64x0/include/mach/debug-macro.S
+++ b/arch/arm/mach-s5p64x0/include/mach/debug-macro.S
@@ -30,4 +30,4 @@
 #endif
 	.endm
 
-#include <plat/debug-macro.S>
+#include <debug/samsung.S>
diff --git a/arch/arm/mach-s5pc100/include/mach/debug-macro.S b/arch/arm/mach-s5pc100/include/mach/debug-macro.S
index 694f759..66cb7f1 100644
--- a/arch/arm/mach-s5pc100/include/mach/debug-macro.S
+++ b/arch/arm/mach-s5pc100/include/mach/debug-macro.S
@@ -36,4 +36,4 @@
  * will be fine with us.
  */
 
-#include <plat/debug-macro.S>
+#include <debug/samsung.S>
diff --git a/arch/arm/mach-s5pv210/include/mach/debug-macro.S b/arch/arm/mach-s5pv210/include/mach/debug-macro.S
index 79e5559..80c2199 100644
--- a/arch/arm/mach-s5pv210/include/mach/debug-macro.S
+++ b/arch/arm/mach-s5pv210/include/mach/debug-macro.S
@@ -38,4 +38,4 @@
  * will be fine with us.
  */
 
-#include <plat/debug-macro.S>
+#include <debug/samsung.S>
-- 
1.8.1.2



From arnd at arndb.de  Wed Apr 10 20:04:57 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 11 Apr 2013 02:04:57 +0200
Subject: [PATCH 15/30] mtd: onenand/samsung: make regs-onenand.h file local
In-Reply-To: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
References: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
Message-ID: <1365638712-1028578-16-git-send-email-arnd@arndb.de>

Nothing uses the NAND register definitions other than the
actual driver, so we can move the header file into the
same local directory, which lets us build it in a multiplatform
configuration.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Cc: linux-mtd at lists.infradead.org
Cc: Kyungmin Park <kyungmin.park at samsung.com>
Cc: David Woodhouse <dwmw2 at infradead.org>
---
 drivers/mtd/onenand/samsung.c                                         | 4 ++--
 .../include/plat/regs-onenand.h => drivers/mtd/onenand/samsung.h      | 2 --
 2 files changed, 2 insertions(+), 4 deletions(-)
 rename arch/arm/plat-samsung/include/plat/regs-onenand.h => drivers/mtd/onenand/samsung.h (98%)

diff --git a/drivers/mtd/onenand/samsung.c b/drivers/mtd/onenand/samsung.c
index 33f2a8f..2cf7408 100644
--- a/drivers/mtd/onenand/samsung.c
+++ b/drivers/mtd/onenand/samsung.c
@@ -23,11 +23,11 @@
 #include <linux/mtd/partitions.h>
 #include <linux/dma-mapping.h>
 #include <linux/interrupt.h>
+#include <linux/io.h>
 
 #include <asm/mach/flash.h>
-#include <plat/regs-onenand.h>
 
-#include <linux/io.h>
+#include "samsung.h"
 
 enum soc_type {
 	TYPE_S3C6400,
diff --git a/arch/arm/plat-samsung/include/plat/regs-onenand.h b/drivers/mtd/onenand/samsung.h
similarity index 98%
rename from arch/arm/plat-samsung/include/plat/regs-onenand.h
rename to drivers/mtd/onenand/samsung.h
index 930ea8b..c4a80e6 100644
--- a/arch/arm/plat-samsung/include/plat/regs-onenand.h
+++ b/drivers/mtd/onenand/samsung.h
@@ -11,8 +11,6 @@
 #ifndef __SAMSUNG_ONENAND_H__
 #define __SAMSUNG_ONENAND_H__
 
-#include <mach/hardware.h>
-
 /*
  * OneNAND Controller
  */
-- 
1.8.1.2



From arnd at arndb.de  Wed Apr 10 20:04:47 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 11 Apr 2013 02:04:47 +0200
Subject: [PATCH 05/30] tty: serial/samsung: prepare for common clock API
In-Reply-To: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
References: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
Message-ID: <1365638712-1028578-6-git-send-email-arnd@arndb.de>

With the common clock interface, there is no way to provide the
"clock_source" sysfs attribute for the samsung serial ports. Given that
this file was purely informational and had fixed contents, we have reason
to believe that no user space programs were relying on it.

The sysfs file is not documented in the ABI docs.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Cc: linux-serial at vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
---
 drivers/tty/serial/samsung.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/tty/serial/samsung.c b/drivers/tty/serial/samsung.c
index 2769a38..603f3f3 100644
--- a/drivers/tty/serial/samsung.c
+++ b/drivers/tty/serial/samsung.c
@@ -1179,6 +1179,7 @@ static int s3c24xx_serial_init_port(struct s3c24xx_uart_port *ourport,
 	return 0;
 }
 
+#ifdef CONFIG_SAMSUNG_CLOCK
 static ssize_t s3c24xx_serial_show_clksrc(struct device *dev,
 					  struct device_attribute *attr,
 					  char *buf)
@@ -1194,7 +1195,7 @@ static ssize_t s3c24xx_serial_show_clksrc(struct device *dev,
 }
 
 static DEVICE_ATTR(clock_source, S_IRUGO, s3c24xx_serial_show_clksrc, NULL);
-
+#endif
 
 /* Device driver serial port probe */
 
@@ -1252,9 +1253,11 @@ static int s3c24xx_serial_probe(struct platform_device *pdev)
 	uart_add_one_port(&s3c24xx_uart_drv, &ourport->port);
 	platform_set_drvdata(pdev, &ourport->port);
 
+#ifdef CONFIG_SAMSUNG_CLOCK
 	ret = device_create_file(&pdev->dev, &dev_attr_clock_source);
 	if (ret < 0)
 		dev_err(&pdev->dev, "failed to add clock source attr.\n");
+#endif
 
 	ret = s3c24xx_serial_cpufreq_register(ourport);
 	if (ret < 0)
@@ -1272,7 +1275,9 @@ static int s3c24xx_serial_remove(struct platform_device *dev)
 
 	if (port) {
 		s3c24xx_serial_cpufreq_deregister(to_ourport(port));
+#ifdef CONFIG_SAMSUNG_CLOCK
 		device_remove_file(&dev->dev, &dev_attr_clock_source);
+#endif
 		uart_remove_one_port(&s3c24xx_uart_drv, port);
 	}
 
-- 
1.8.1.2



From arnd at arndb.de  Wed Apr 10 20:04:43 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 11 Apr 2013 02:04:43 +0200
Subject: [PATCH 01/30] ARM: exynos: introduce EXYNOS_ATAGS symbol
In-Reply-To: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
References: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
Message-ID: <1365638712-1028578-2-git-send-email-arnd@arndb.de>

As a preparation for multiplatform support, this introduces
a new Kconfig symbol to split the ATAGS based EXYNOS platforms
from the DT based ones. Turning off CONFIG_EXYNOS_ATAGS disables
all platforms that are not yet converted to DT, and we can
have code that relies on DT checking for this symbol being
disabled.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 arch/arm/mach-exynos/Kconfig | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index a62cfa0..e815057 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -82,6 +82,19 @@ config SOC_EXYNOS5440
 	help
 	  Enable EXYNOS5440 SoC support
 
+config EXYNOS_ATAGS
+	bool "ATAGS based boot for EXYNOS (deprecated)"
+	depends on ARCH_EXYNOS_SINGLE
+	depends on ATAGS
+	default y
+	help
+	  The EXYNOS platform is moving towards being completely probed
+	  through device tree. This enables support for board files using
+	  the traditional ATAGS boot format.
+	  Note that this option is not available for multiplatform builds.
+
+if EXYNOS_ATAGS
+
 config EXYNOS_DEV_DMA
 	bool
 	help
@@ -386,6 +399,8 @@ config MACH_SMDK4412
 	  Machine support for Samsung SMDK4412
 endif
 
+endif
+
 comment "Flattened Device Tree based board for EXYNOS SoCs"
 
 config MACH_EXYNOS4_DT
-- 
1.8.1.2



From arnd at arndb.de  Wed Apr 10 20:04:52 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 11 Apr 2013 02:04:52 +0200
Subject: [PATCH 10/30] usb: exynos: do not include plat/usb-phy.h
In-Reply-To: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
References: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
Message-ID: <1365638712-1028578-11-git-send-email-arnd@arndb.de>

The definitions have moved to include/linux/usb/samsung-usb-phy.h,
and plat/usb-phy.h is unavailable from drivers in a multiplatform
configuration.

Also fix up the plat/usb-phy.h header file to use the definitions
from the new header instead of providing a separate copy.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Cc: linux-usb at vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
Cc: Alan Stern <stern at rowland.harvard.edu>
---
 arch/arm/mach-exynos/setup-usb-phy.c         | 8 ++++----
 arch/arm/mach-s3c64xx/setup-usb-phy.c        | 4 ++--
 arch/arm/mach-s5pv210/setup-usb-phy.c        | 4 ++--
 arch/arm/plat-samsung/include/plat/usb-phy.h | 5 +----
 drivers/usb/host/ehci-s5p.c                  | 1 -
 drivers/usb/host/ohci-exynos.c               | 1 -
 6 files changed, 9 insertions(+), 14 deletions(-)

diff --git a/arch/arm/mach-exynos/setup-usb-phy.c b/arch/arm/mach-exynos/setup-usb-phy.c
index b81cc56..6af4066 100644
--- a/arch/arm/mach-exynos/setup-usb-phy.c
+++ b/arch/arm/mach-exynos/setup-usb-phy.c
@@ -204,9 +204,9 @@ static int exynos4210_usb_phy1_exit(struct platform_device *pdev)
 
 int s5p_usb_phy_init(struct platform_device *pdev, int type)
 {
-	if (type == S5P_USB_PHY_DEVICE)
+	if (type == USB_PHY_TYPE_DEVICE)
 		return exynos4210_usb_phy0_init(pdev);
-	else if (type == S5P_USB_PHY_HOST)
+	else if (type == USB_PHY_TYPE_HOST)
 		return exynos4210_usb_phy1_init(pdev);
 
 	return -EINVAL;
@@ -214,9 +214,9 @@ int s5p_usb_phy_init(struct platform_device *pdev, int type)
 
 int s5p_usb_phy_exit(struct platform_device *pdev, int type)
 {
-	if (type == S5P_USB_PHY_DEVICE)
+	if (type == USB_PHY_TYPE_DEVICE)
 		return exynos4210_usb_phy0_exit(pdev);
-	else if (type == S5P_USB_PHY_HOST)
+	else if (type == USB_PHY_TYPE_HOST)
 		return exynos4210_usb_phy1_exit(pdev);
 
 	return -EINVAL;
diff --git a/arch/arm/mach-s3c64xx/setup-usb-phy.c b/arch/arm/mach-s3c64xx/setup-usb-phy.c
index c8174d9..ca960bd 100644
--- a/arch/arm/mach-s3c64xx/setup-usb-phy.c
+++ b/arch/arm/mach-s3c64xx/setup-usb-phy.c
@@ -76,7 +76,7 @@ static int s3c_usb_otgphy_exit(struct platform_device *pdev)
 
 int s5p_usb_phy_init(struct platform_device *pdev, int type)
 {
-	if (type == S5P_USB_PHY_DEVICE)
+	if (type == USB_PHY_TYPE_DEVICE)
 		return s3c_usb_otgphy_init(pdev);
 
 	return -EINVAL;
@@ -84,7 +84,7 @@ int s5p_usb_phy_init(struct platform_device *pdev, int type)
 
 int s5p_usb_phy_exit(struct platform_device *pdev, int type)
 {
-	if (type == S5P_USB_PHY_DEVICE)
+	if (type == USB_PHY_TYPE_DEVICE)
 		return s3c_usb_otgphy_exit(pdev);
 
 	return -EINVAL;
diff --git a/arch/arm/mach-s5pv210/setup-usb-phy.c b/arch/arm/mach-s5pv210/setup-usb-phy.c
index 356a090..b2ee533 100644
--- a/arch/arm/mach-s5pv210/setup-usb-phy.c
+++ b/arch/arm/mach-s5pv210/setup-usb-phy.c
@@ -80,7 +80,7 @@ static int s5pv210_usb_otgphy_exit(struct platform_device *pdev)
 
 int s5p_usb_phy_init(struct platform_device *pdev, int type)
 {
-	if (type == S5P_USB_PHY_DEVICE)
+	if (type == USB_PHY_TYPE_DEVICE)
 		return s5pv210_usb_otgphy_init(pdev);
 
 	return -EINVAL;
@@ -88,7 +88,7 @@ int s5p_usb_phy_init(struct platform_device *pdev, int type)
 
 int s5p_usb_phy_exit(struct platform_device *pdev, int type)
 {
-	if (type == S5P_USB_PHY_DEVICE)
+	if (type == USB_PHY_TYPE_DEVICE)
 		return s5pv210_usb_otgphy_exit(pdev);
 
 	return -EINVAL;
diff --git a/arch/arm/plat-samsung/include/plat/usb-phy.h b/arch/arm/plat-samsung/include/plat/usb-phy.h
index 959bcdb..ab34dfa 100644
--- a/arch/arm/plat-samsung/include/plat/usb-phy.h
+++ b/arch/arm/plat-samsung/include/plat/usb-phy.h
@@ -11,10 +11,7 @@
 #ifndef __PLAT_SAMSUNG_USB_PHY_H
 #define __PLAT_SAMSUNG_USB_PHY_H __FILE__
 
-enum s5p_usb_phy_type {
-	S5P_USB_PHY_DEVICE,
-	S5P_USB_PHY_HOST,
-};
+#include <linux/usb/samsung_usb_phy.h>
 
 extern int s5p_usb_phy_init(struct platform_device *pdev, int type);
 extern int s5p_usb_phy_exit(struct platform_device *pdev, int type);
diff --git a/drivers/usb/host/ehci-s5p.c b/drivers/usb/host/ehci-s5p.c
index 20ebf6a..7dc9c15 100644
--- a/drivers/usb/host/ehci-s5p.c
+++ b/drivers/usb/host/ehci-s5p.c
@@ -19,7 +19,6 @@
 #include <linux/platform_data/usb-ehci-s5p.h>
 #include <linux/usb/phy.h>
 #include <linux/usb/samsung_usb_phy.h>
-#include <plat/usb-phy.h>
 
 #define EHCI_INSNREG00(base)			(base + 0x90)
 #define EHCI_INSNREG00_ENA_INCR16		(0x1 << 25)
diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
index 0bd6f47..0792bfd 100644
--- a/drivers/usb/host/ohci-exynos.c
+++ b/drivers/usb/host/ohci-exynos.c
@@ -18,7 +18,6 @@
 #include <linux/usb/phy.h>
 #include <linux/usb/samsung_usb_phy.h>
 
-#include <plat/usb-phy.h>
 
 struct exynos_ohci_hcd {
 	struct device *dev;
-- 
1.8.1.2



From arnd at arndb.de  Wed Apr 10 20:05:08 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 11 Apr 2013 02:05:08 +0200
Subject: [PATCH 26/30] irqchip: exynos: allocate combiner_data dynamically
In-Reply-To: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
References: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
Message-ID: <1365638712-1028578-27-git-send-email-arnd@arndb.de>

The number of combiners on a given SoC is a platform specific
constant, and we cannot encode this number on a multiplatform
kernel since the header file defining it is not available.

Allocating the structure dynamically ends up cleaner anyway
since we keep all the data local.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Cc: Thomas Gleixner <tglx at linutronix.de>
---
 drivers/irqchip/exynos-combiner.c | 36 +++++++++++++++++++++++-------------
 1 file changed, 23 insertions(+), 13 deletions(-)

diff --git a/drivers/irqchip/exynos-combiner.c b/drivers/irqchip/exynos-combiner.c
index e7aef59..ffb10aa 100644
--- a/drivers/irqchip/exynos-combiner.c
+++ b/drivers/irqchip/exynos-combiner.c
@@ -12,6 +12,7 @@
 #include <linux/export.h>
 #include <linux/init.h>
 #include <linux/io.h>
+#include <linux/slab.h>
 #include <linux/irqdomain.h>
 #include <linux/irqchip/chained_irq.h>
 #include <linux/of_address.h>
@@ -38,7 +39,6 @@ struct combiner_chip_data {
 };
 
 static struct irq_domain *combiner_irq_domain;
-static struct combiner_chip_data combiner_data[MAX_COMBINER_NR];
 
 static inline void __iomem *combiner_base(struct irq_data *data)
 {
@@ -115,26 +115,26 @@ static struct irq_chip combiner_chip = {
 #endif
 };
 
-static void __init combiner_cascade_irq(unsigned int combiner_nr,
+static void __init combiner_cascade_irq(struct combiner_chip_data *combiner_data,
 					unsigned int irq)
 {
-	if (irq_set_handler_data(irq, &combiner_data[combiner_nr]) != 0)
+	if (irq_set_handler_data(irq, combiner_data) != 0)
 		BUG();
 	irq_set_chained_handler(irq, combiner_handle_cascade_irq);
 }
 
-static void __init combiner_init_one(unsigned int combiner_nr,
+static void __init combiner_init_one(struct combiner_chip_data *combiner_data,
+				     unsigned int combiner_nr,
 				     void __iomem *base, unsigned int irq)
 {
-	combiner_data[combiner_nr].base = base;
-	combiner_data[combiner_nr].irq_offset = irq_find_mapping(
+	combiner_data->base = base;
+	combiner_data->irq_offset = irq_find_mapping(
 		combiner_irq_domain, combiner_nr * IRQ_IN_COMBINER);
-	combiner_data[combiner_nr].irq_mask = 0xff << ((combiner_nr % 4) << 3);
-	combiner_data[combiner_nr].parent_irq = irq;
+	combiner_data->irq_mask = 0xff << ((combiner_nr % 4) << 3);
+	combiner_data->parent_irq = irq;
 
 	/* Disable all interrupts */
-	__raw_writel(combiner_data[combiner_nr].irq_mask,
-		     base + COMBINER_ENABLE_CLEAR);
+	__raw_writel(combiner_data->irq_mask, base + COMBINER_ENABLE_CLEAR);
 }
 
 #ifdef CONFIG_OF
@@ -169,6 +169,8 @@ static int combiner_irq_domain_xlate(struct irq_domain *d,
 static int combiner_irq_domain_map(struct irq_domain *d, unsigned int irq,
 				   irq_hw_number_t hw)
 {
+	struct combiner_chip_data *combiner_data = d->host_data;
+
 	irq_set_chip_and_handler(irq, &combiner_chip, handle_level_irq);
 	irq_set_chip_data(irq, &combiner_data[hw >> 3]);
 	set_irq_flags(irq, IRQF_VALID | IRQF_PROBE);
@@ -203,6 +205,7 @@ void __init combiner_init(void __iomem *combiner_base,
 {
 	int i, irq, irq_base;
 	unsigned int nr_irq;
+	struct combiner_chip_data *combiner_data;
 
 	nr_irq = max_nr * IRQ_IN_COMBINER;
 
@@ -212,8 +215,14 @@ void __init combiner_init(void __iomem *combiner_base,
 		pr_warning("%s: irq desc alloc failed. Continuing with %d as linux irq base\n", __func__, irq_base);
 	}
 
+	combiner_data = kcalloc(max_nr, sizeof (*combiner_data), GFP_KERNEL);
+	if (!combiner_data) {
+		pr_warning("%s: could not allocate combiner data\n", __func__);
+		return;
+	}
+
 	combiner_irq_domain = irq_domain_add_legacy(np, nr_irq, irq_base, 0,
-				&combiner_irq_domain_ops, &combiner_data);
+				&combiner_irq_domain_ops, combiner_data);
 	if (WARN_ON(!combiner_irq_domain)) {
 		pr_warning("%s: irq domain init failed\n", __func__);
 		return;
@@ -228,8 +237,9 @@ void __init combiner_init(void __iomem *combiner_base,
 		if (np)
 			irq = irq_of_parse_and_map(np, i);
 #endif
-		combiner_init_one(i, combiner_base + (i >> 2) * 0x10, irq);
-		combiner_cascade_irq(i, irq);
+		combiner_init_one(&combiner_data[i], i,
+				  combiner_base + (i >> 2) * 0x10, irq);
+		combiner_cascade_irq(&combiner_data[i], irq);
 	}
 }
 
-- 
1.8.1.2



From arnd at arndb.de  Wed Apr 10 20:04:54 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 11 Apr 2013 02:04:54 +0200
Subject: [PATCH 12/30] video/exynos: remove unnecessary header inclusions
In-Reply-To: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
References: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
Message-ID: <1365638712-1028578-13-git-send-email-arnd@arndb.de>

In multiplatform configurations, we cannot include headers
provided by only the exynos platform. Fortunately a number
of drivers that include those headers do not actually need
them, so we can just remove the inclusions.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Cc: linux-fbdev at vger.kernel.org
Cc: Jingoo Han <jg1.han at samsung.com>
---
 drivers/video/exynos/exynos_mipi_dsi.c          | 2 --
 drivers/video/exynos/exynos_mipi_dsi_common.c   | 2 --
 drivers/video/exynos/exynos_mipi_dsi_lowlevel.c | 2 --
 3 files changed, 6 deletions(-)

diff --git a/drivers/video/exynos/exynos_mipi_dsi.c b/drivers/video/exynos/exynos_mipi_dsi.c
index fac7df6..3dd43ca 100644
--- a/drivers/video/exynos/exynos_mipi_dsi.c
+++ b/drivers/video/exynos/exynos_mipi_dsi.c
@@ -35,8 +35,6 @@
 
 #include <video/exynos_mipi_dsim.h>
 
-#include <plat/fb.h>
-
 #include "exynos_mipi_dsi_common.h"
 #include "exynos_mipi_dsi_lowlevel.h"
 
diff --git a/drivers/video/exynos/exynos_mipi_dsi_common.c b/drivers/video/exynos/exynos_mipi_dsi_common.c
index c70cb89..520fc9b 100644
--- a/drivers/video/exynos/exynos_mipi_dsi_common.c
+++ b/drivers/video/exynos/exynos_mipi_dsi_common.c
@@ -31,8 +31,6 @@
 #include <video/mipi_display.h>
 #include <video/exynos_mipi_dsim.h>
 
-#include <mach/map.h>
-
 #include "exynos_mipi_dsi_regs.h"
 #include "exynos_mipi_dsi_lowlevel.h"
 #include "exynos_mipi_dsi_common.h"
diff --git a/drivers/video/exynos/exynos_mipi_dsi_lowlevel.c b/drivers/video/exynos/exynos_mipi_dsi_lowlevel.c
index 95cb99a..15c5abd 100644
--- a/drivers/video/exynos/exynos_mipi_dsi_lowlevel.c
+++ b/drivers/video/exynos/exynos_mipi_dsi_lowlevel.c
@@ -26,8 +26,6 @@
 
 #include <video/exynos_mipi_dsim.h>
 
-#include <mach/map.h>
-
 #include "exynos_mipi_dsi_regs.h"
 
 void exynos_mipi_dsi_func_reset(struct mipi_dsim_device *dsim)
-- 
1.8.1.2



From arnd at arndb.de  Wed Apr 10 20:05:03 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 11 Apr 2013 02:05:03 +0200
Subject: [PATCH 21/30] ASoC: samsung/i2s: fix module_device_table
In-Reply-To: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
References: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
Message-ID: <1365638712-1028578-22-git-send-email-arnd@arndb.de>

The second argument to the module_device_table macro must be the
name of the device id array. In the samsung i2s driver, there
was a small typo, resulting in a build error when building it
as a loadable module.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Cc: alsa-devel at alsa-project.org
Cc: Mark Brown <broonie at opensource.wolfsonmicro.com>
Cc: Liam Girdwood <lgirdwood at gmail.com>
---
 sound/soc/samsung/i2s.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/samsung/i2s.c b/sound/soc/samsung/i2s.c
index 61f2622..f7c6816 100644
--- a/sound/soc/samsung/i2s.c
+++ b/sound/soc/samsung/i2s.c
@@ -1289,7 +1289,7 @@ static struct platform_device_id samsung_i2s_driver_ids[] = {
 	},
 	{},
 };
-MODULE_DEVICE_TABLE(platform, samsung-i2s-driver-ids);
+MODULE_DEVICE_TABLE(platform, samsung_i2s_driver_ids);
 
 #ifdef CONFIG_OF
 static struct samsung_i2s_dai_data samsung_i2s_dai_data_array[] = {
-- 
1.8.1.2



From arnd at arndb.de  Wed Apr 10 20:04:59 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 11 Apr 2013 02:04:59 +0200
Subject: [PATCH 17/30] pwm: samsung: repair the worst MMIO abuses
In-Reply-To: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
References: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
Message-ID: <1365638712-1028578-18-git-send-email-arnd@arndb.de>

The Samsung PWM driver uses "magic" pointers that are mapped
at boot time to point its MMIO registers. This fails horribly
with a multiplatform kernel, which can not rely on platform
specific header files to contain the right values, aside from
this being a really bad idea in general.

This changes the driver to at least pass an __iomem token
around in the device structure to dereference that. Fixing
the platform code is much harder, so we'll leave that
until we have a DT binding for pwm-samsung, which may require
other changes in this area. Since we are already touching
every MMIO accessor in this driver, let's also use the
proper readl_relaxed variant rather than __raw_readl.

Tomasz Figa has a set of patches to clean this up in a proper
way, but that might be too late for 3.10.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Cc: Tomasz Figa <t.figa at samsung.com>
Cc: Thierry Reding <thierry.reding at avionic-design.de>
---
 drivers/pwm/pwm-samsung.c | 60 +++++++++++++++++++++++++++++++++--------------
 1 file changed, 42 insertions(+), 18 deletions(-)

diff --git a/drivers/pwm/pwm-samsung.c b/drivers/pwm/pwm-samsung.c
index 5207e6c..9d7234d 100644
--- a/drivers/pwm/pwm-samsung.c
+++ b/drivers/pwm/pwm-samsung.c
@@ -22,9 +22,25 @@
 #include <linux/io.h>
 #include <linux/pwm.h>
 
-#include <mach/map.h>
+#ifndef CONFIG_ARCH_MULTIPLATFORM
+/*
+ * This is gross: the platform maps the timer at a fixed
+ * virtual address and expects us to use that address
+ * rather than a proper resource. This should get done properly
+ * when we get a DT binding for this driver.
+ */
+#include <plat/map-base.h>
+static inline void dummy(void)
+{
+	BUILD_BUG_ON(S3C_VA_TIMER != IOMEM(0xf6300000));
+}
+#else
+#define S3C_VA_TIMER IOMEM(0xf6300000);
+#endif
 
-#include <plat/regs-timer.h>
+#define S3C2410_TCON		8
+#define S3C2410_TCNTB(tmr)	(0x0c + (tmr)*0x0c + 0x00)
+#define S3C2410_TCMPB(tmr)	(0x0c + (tmr)*0x0c + 0x04)
 
 struct s3c_chip {
 	struct platform_device	*pdev;
@@ -38,6 +54,7 @@ struct s3c_chip {
 
 	unsigned char		 tcon_base;
 	unsigned char		 pwm_id;
+	void __iomem		*base;
 	struct pwm_chip		 chip;
 };
 
@@ -65,9 +82,9 @@ static int s3c_pwm_enable(struct pwm_chip *chip, struct pwm_device *pwm)
 
 	local_irq_save(flags);
 
-	tcon = __raw_readl(S3C2410_TCON);
+	tcon = readl_relaxed(s3c->base + S3C2410_TCON);
 	tcon |= pwm_tcon_start(s3c);
-	__raw_writel(tcon, S3C2410_TCON);
+	writel_relaxed(tcon, s3c->base + S3C2410_TCON);
 
 	local_irq_restore(flags);
 
@@ -82,9 +99,9 @@ static void s3c_pwm_disable(struct pwm_chip *chip, struct pwm_device *pwm)
 
 	local_irq_save(flags);
 
-	tcon = __raw_readl(S3C2410_TCON);
+	tcon = readl_relaxed(s3c->base + S3C2410_TCON);
 	tcon &= ~pwm_tcon_start(s3c);
-	__raw_writel(tcon, S3C2410_TCON);
+	writel_relaxed(tcon, s3c->base + S3C2410_TCON);
 
 	local_irq_restore(flags);
 }
@@ -133,8 +150,8 @@ static int s3c_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
 	/* The TCMP and TCNT can be read without a lock, they're not
 	 * shared between the timers. */
 
-	tcmp = __raw_readl(S3C2410_TCMPB(s3c->pwm_id));
-	tcnt = __raw_readl(S3C2410_TCNTB(s3c->pwm_id));
+	tcmp = readl_relaxed(s3c->base + S3C2410_TCMPB(s3c->pwm_id));
+	tcnt = readl_relaxed(s3c->base + S3C2410_TCNTB(s3c->pwm_id));
 
 	period = NS_IN_HZ / period_ns;
 
@@ -177,16 +194,16 @@ static int s3c_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
 
 	local_irq_save(flags);
 
-	__raw_writel(tcmp, S3C2410_TCMPB(s3c->pwm_id));
-	__raw_writel(tcnt, S3C2410_TCNTB(s3c->pwm_id));
+	writel_relaxed(tcmp, s3c->base + S3C2410_TCMPB(s3c->pwm_id));
+	writel_relaxed(tcnt, s3c->base + S3C2410_TCNTB(s3c->pwm_id));
 
-	tcon = __raw_readl(S3C2410_TCON);
+	tcon = readl_relaxed(s3c->base + S3C2410_TCON);
 	tcon |= pwm_tcon_manulupdate(s3c);
 	tcon |= pwm_tcon_autoreload(s3c);
-	__raw_writel(tcon, S3C2410_TCON);
+	writel_relaxed(tcon, s3c->base + S3C2410_TCON);
 
 	tcon &= ~pwm_tcon_manulupdate(s3c);
-	__raw_writel(tcon, S3C2410_TCON);
+	writel_relaxed(tcon, s3c->base + S3C2410_TCON);
 
 	local_irq_restore(flags);
 
@@ -207,6 +224,7 @@ static int s3c_pwm_probe(struct platform_device *pdev)
 	unsigned long flags;
 	unsigned long tcon;
 	unsigned int id = pdev->id;
+	struct resource *res;
 	int ret;
 
 	if (id == 4) {
@@ -220,6 +238,12 @@ static int s3c_pwm_probe(struct platform_device *pdev)
 		return -ENOMEM;
 	}
 
+	/* try to get a proper base address, fall back to S3C_VA_TIMER */
+	s3c->base = S3C_VA_TIMER;
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	if (res)
+		s3c->base = devm_ioremap(dev, res->start, resource_size(res));
+
 	/* calculate base of control bits in TCON */
 	s3c->tcon_base = id == 0 ? 0 : (id * 4) + 4;
 	s3c->pwm_id = id;
@@ -245,9 +269,9 @@ static int s3c_pwm_probe(struct platform_device *pdev)
 
 	local_irq_save(flags);
 
-	tcon = __raw_readl(S3C2410_TCON);
+	tcon = readl_relaxed(s3c->base + S3C2410_TCON);
 	tcon |= pwm_tcon_invert(s3c);
-	__raw_writel(tcon, S3C2410_TCON);
+	writel_relaxed(tcon, s3c->base + S3C2410_TCON);
 
 	local_irq_restore(flags);
 
@@ -258,7 +282,7 @@ static int s3c_pwm_probe(struct platform_device *pdev)
 	}
 
 	pwm_dbg(s3c, "config bits %02x\n",
-		(__raw_readl(S3C2410_TCON) >> s3c->tcon_base) & 0x0f);
+		(readl_relaxed(s3c->base + S3C2410_TCON) >> s3c->tcon_base) & 0x0f);
 
 	dev_info(dev, "tin at %lu, tdiv at %lu, tin=%sclk, base %d\n",
 		 clk_get_rate(s3c->clk),
@@ -310,9 +334,9 @@ static int s3c_pwm_resume(struct platform_device *pdev)
 	unsigned long tcon;
 
 	/* Restore invertion */
-	tcon = __raw_readl(S3C2410_TCON);
+	tcon = readl_relaxed(s3c->base + S3C2410_TCON);
 	tcon |= pwm_tcon_invert(s3c);
-	__raw_writel(tcon, S3C2410_TCON);
+	writel_relaxed(tcon, s3c->base + S3C2410_TCON);
 
 	return 0;
 }
-- 
1.8.1.2



From arnd at arndb.de  Wed Apr 10 20:04:55 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 11 Apr 2013 02:04:55 +0200
Subject: [PATCH 13/30] video/s3c: move platform_data out of arch/arm
In-Reply-To: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
References: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
Message-ID: <1365638712-1028578-14-git-send-email-arnd@arndb.de>

The s3c-fb driver requires header files from the samsung platforms
to find its platform_data definition, but this no longer works on
multiplatform kernels, so let's move the data into a new header
file under include/linux/platform_data.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Cc: linux-fbdev at vger.kernel.org
Cc: Jingoo Han <jg1.han at samsung.com>
---
 arch/arm/plat-samsung/include/plat/fb.h | 50 +-----------------------------
 drivers/video/s3c-fb.c                  |  3 +-
 include/linux/platform_data/video_s3c.h | 54 +++++++++++++++++++++++++++++++++
 3 files changed, 56 insertions(+), 51 deletions(-)
 create mode 100644 include/linux/platform_data/video_s3c.h

diff --git a/arch/arm/plat-samsung/include/plat/fb.h b/arch/arm/plat-samsung/include/plat/fb.h
index b885322..9ae5072 100644
--- a/arch/arm/plat-samsung/include/plat/fb.h
+++ b/arch/arm/plat-samsung/include/plat/fb.h
@@ -15,55 +15,7 @@
 #ifndef __PLAT_S3C_FB_H
 #define __PLAT_S3C_FB_H __FILE__
 
-/* S3C_FB_MAX_WIN
- * Set to the maximum number of windows that any of the supported hardware
- * can use. Since the platform data uses this for an array size, having it
- * set to the maximum of any version of the hardware can do is safe.
- */
-#define S3C_FB_MAX_WIN	(5)
-
-/**
- * struct s3c_fb_pd_win - per window setup data
- * @xres     : The window X size.
- * @yres     : The window Y size.
- * @virtual_x: The virtual X size.
- * @virtual_y: The virtual Y size.
- */
-struct s3c_fb_pd_win {
-	unsigned short		default_bpp;
-	unsigned short		max_bpp;
-	unsigned short		xres;
-	unsigned short		yres;
-	unsigned short		virtual_x;
-	unsigned short		virtual_y;
-};
-
-/**
- * struct s3c_fb_platdata -  S3C driver platform specific information
- * @setup_gpio: Setup the external GPIO pins to the right state to transfer
- *		the data from the display system to the connected display
- *		device.
- * @vidcon0: The base vidcon0 values to control the panel data format.
- * @vidcon1: The base vidcon1 values to control the panel data output.
- * @vtiming: Video timing when connected to a RGB type panel.
- * @win: The setup data for each hardware window, or NULL for unused.
- * @display_mode: The LCD output display mode.
- *
- * The platform data supplies the video driver with all the information
- * it requires to work with the display(s) attached to the machine. It
- * controls the initial mode, the number of display windows (0 is always
- * the base framebuffer) that are initialised etc.
- *
- */
-struct s3c_fb_platdata {
-	void	(*setup_gpio)(void);
-
-	struct s3c_fb_pd_win	*win[S3C_FB_MAX_WIN];
-	struct fb_videomode     *vtiming;
-
-	u32			 vidcon0;
-	u32			 vidcon1;
-};
+#include <linux/platform_data/video_s3c.h>
 
 /**
  * s3c_fb_set_platdata() - Setup the FB device with platform data.
diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
index 968a625..2e7991c 100644
--- a/drivers/video/s3c-fb.c
+++ b/drivers/video/s3c-fb.c
@@ -24,10 +24,9 @@
 #include <linux/uaccess.h>
 #include <linux/interrupt.h>
 #include <linux/pm_runtime.h>
+#include <linux/platform_data/video_s3c.h>
 
 #include <video/samsung_fimd.h>
-#include <mach/map.h>
-#include <plat/fb.h>
 
 /* This driver will export a number of framebuffer interfaces depending
  * on the configuration passed in via the platform data. Each fb instance
diff --git a/include/linux/platform_data/video_s3c.h b/include/linux/platform_data/video_s3c.h
new file mode 100644
index 0000000..fa40f96
--- /dev/null
+++ b/include/linux/platform_data/video_s3c.h
@@ -0,0 +1,54 @@
+#ifndef __PLATFORM_DATA_VIDEO_S3C
+#define __PLATFORM_DATA_VIDEO_S3C
+
+/* S3C_FB_MAX_WIN
+ * Set to the maximum number of windows that any of the supported hardware
+ * can use. Since the platform data uses this for an array size, having it
+ * set to the maximum of any version of the hardware can do is safe.
+ */
+#define S3C_FB_MAX_WIN	(5)
+
+/**
+ * struct s3c_fb_pd_win - per window setup data
+ * @xres     : The window X size.
+ * @yres     : The window Y size.
+ * @virtual_x: The virtual X size.
+ * @virtual_y: The virtual Y size.
+ */
+struct s3c_fb_pd_win {
+	unsigned short		default_bpp;
+	unsigned short		max_bpp;
+	unsigned short		xres;
+	unsigned short		yres;
+	unsigned short		virtual_x;
+	unsigned short		virtual_y;
+};
+
+/**
+ * struct s3c_fb_platdata -  S3C driver platform specific information
+ * @setup_gpio: Setup the external GPIO pins to the right state to transfer
+ *		the data from the display system to the connected display
+ *		device.
+ * @vidcon0: The base vidcon0 values to control the panel data format.
+ * @vidcon1: The base vidcon1 values to control the panel data output.
+ * @vtiming: Video timing when connected to a RGB type panel.
+ * @win: The setup data for each hardware window, or NULL for unused.
+ * @display_mode: The LCD output display mode.
+ *
+ * The platform data supplies the video driver with all the information
+ * it requires to work with the display(s) attached to the machine. It
+ * controls the initial mode, the number of display windows (0 is always
+ * the base framebuffer) that are initialised etc.
+ *
+ */
+struct s3c_fb_platdata {
+	void	(*setup_gpio)(void);
+
+	struct s3c_fb_pd_win	*win[S3C_FB_MAX_WIN];
+	struct fb_videomode     *vtiming;
+
+	u32			 vidcon0;
+	u32			 vidcon1;
+};
+ 
+#endif
-- 
1.8.1.2



From arnd at arndb.de  Wed Apr 10 20:05:10 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 11 Apr 2013 02:05:10 +0200
Subject: [PATCH 28/30] irqchip: exynos: pass irq_base from platform
In-Reply-To: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
References: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
Message-ID: <1365638712-1028578-29-git-send-email-arnd@arndb.de>

The platform code knows the IRQ base, while the irqchip driver
should really not. This is a littly hacky because we still
hardwire the IRQ base to 160 for the combiner in the DT case,
when we should really use -1. Removing that line will cause
a linear IRQ domain to be use, as we should.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Cc: Thomas Gleixner <tglx at linutronix.de>
---
 arch/arm/mach-exynos/common.c     |  3 ++-
 arch/arm/mach-exynos/common.h     |  2 +-
 drivers/irqchip/exynos-combiner.c | 23 +++++++++++++----------
 3 files changed, 16 insertions(+), 12 deletions(-)

diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
index b0e0b41..0634f99 100644
--- a/arch/arm/mach-exynos/common.c
+++ b/arch/arm/mach-exynos/common.c
@@ -479,7 +479,8 @@ void __init exynos4_init_irq(void)
 #endif
 
 	if (!of_have_populated_dt())
-		combiner_init(S5P_VA_COMBINER_BASE, NULL, max_combiner_nr());
+		combiner_init(S5P_VA_COMBINER_BASE, NULL,
+			      max_combiner_nr(), COMBINER_IRQ(0, 0));
 
 	/*
 	 * The parameters of s5p_init_irq() are for VIC init.
diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
index 49bebd1..60dd35c 100644
--- a/arch/arm/mach-exynos/common.h
+++ b/arch/arm/mach-exynos/common.h
@@ -72,7 +72,7 @@ void exynos4212_register_clocks(void);
 
 struct device_node;
 void combiner_init(void __iomem *combiner_base, struct device_node *np,
-			unsigned int max_nr);
+			unsigned int max_nr, int irq_base);
 
 extern struct smp_operations exynos_smp_ops;
 
diff --git a/drivers/irqchip/exynos-combiner.c b/drivers/irqchip/exynos-combiner.c
index 31a4e96..7e876b5 100644
--- a/drivers/irqchip/exynos-combiner.c
+++ b/drivers/irqchip/exynos-combiner.c
@@ -207,27 +207,22 @@ static unsigned int combiner_lookup_irq(int group)
 
 void __init combiner_init(void __iomem *combiner_base,
 			  struct device_node *np,
-			  unsigned int max_nr)
+			  unsigned int max_nr,
+			  int irq_base)
 {
-	int i, irq, irq_base;
+	int i, irq;
 	unsigned int nr_irq;
 	struct combiner_chip_data *combiner_data;
 
 	nr_irq = max_nr * IRQ_IN_COMBINER;
 
-	irq_base = irq_alloc_descs(COMBINER_IRQ(0, 0), 1, nr_irq, 0);
-	if (IS_ERR_VALUE(irq_base)) {
-		irq_base = COMBINER_IRQ(0, 0);
-		pr_warning("%s: irq desc alloc failed. Continuing with %d as linux irq base\n", __func__, irq_base);
-	}
-
 	combiner_data = kcalloc(max_nr, sizeof (*combiner_data), GFP_KERNEL);
 	if (!combiner_data) {
 		pr_warning("%s: could not allocate combiner data\n", __func__);
 		return;
 	}
 
-	combiner_irq_domain = irq_domain_add_legacy(np, nr_irq, irq_base, 0,
+	combiner_irq_domain = irq_domain_add_simple(np, nr_irq, irq_base,
 				&combiner_irq_domain_ops, combiner_data);
 	if (WARN_ON(!combiner_irq_domain)) {
 		pr_warning("%s: irq domain init failed\n", __func__);
@@ -254,6 +249,7 @@ static int __init combiner_of_init(struct device_node *np,
 {
 	void __iomem *combiner_base;
 	unsigned int max_nr;
+	int irq_base = -1;
 
 	combiner_base = of_iomap(np, 0);
 	if (!combiner_base) {
@@ -267,7 +263,14 @@ static int __init combiner_of_init(struct device_node *np,
 			__func__, max_nr);
 	}
 
-	combiner_init(combiner_base, np, max_nr);
+	/* 
+	 * FIXME: This is a hardwired COMBINER_IRQ(0,0). Once all devices
+	 * get their IRQ from DT, remove this in order to get dynamic
+	 * allocation.
+	 */
+	irq_base = 160;
+
+	combiner_init(combiner_base, np, max_nr, irq_base);
 
 	return 0;
 }
-- 
1.8.1.2



From arnd at arndb.de  Wed Apr 10 20:04:56 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 11 Apr 2013 02:04:56 +0200
Subject: [PATCH 14/30] thermal/exynos: remove unnecessary header inclusions
In-Reply-To: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
References: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
Message-ID: <1365638712-1028578-15-git-send-email-arnd@arndb.de>

In multiplatform configurations, we cannot include headers
provided by only the exynos platform. Fortunately a number
of drivers that include those headers do not actually need
them, so we can just remove the inclusions.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Cc: linux-pm at vger.kernel.org
Cc: Zhang Rui <rui.zhang at intel.com>
---
 drivers/thermal/exynos_thermal.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/thermal/exynos_thermal.c b/drivers/thermal/exynos_thermal.c
index 46568c0..b777ae6 100644
--- a/drivers/thermal/exynos_thermal.c
+++ b/drivers/thermal/exynos_thermal.c
@@ -39,8 +39,6 @@
 #include <linux/cpu_cooling.h>
 #include <linux/of.h>
 
-#include <plat/cpu.h>
-
 /* Exynos generic registers */
 #define EXYNOS_TMU_REG_TRIMINFO		0x0
 #define EXYNOS_TMU_REG_CONTROL		0x20
-- 
1.8.1.2



From arnd at arndb.de  Wed Apr 10 20:04:51 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 11 Apr 2013 02:04:51 +0200
Subject: [PATCH 09/30] mmc: sdhci-s3c: remove platform dependencies
In-Reply-To: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
References: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
Message-ID: <1365638712-1028578-10-git-send-email-arnd@arndb.de>

plat/regs-sdhci.h is not used anywhere but in the sdhci-s3c
driver, so it can become a local file there and all other
inclusions removed.

plat/sdhci.h is used only to define the platform devices,
and with the exception of the platform_data structure not
needed by the driver, so we can split out the platform_data
definition instead and leave the rest to platform code.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Cc: linux-mmc at vger.kernel.org
Cc: Chris Ball <cjb at laptop.org>
---
 arch/arm/mach-exynos/setup-sdhci-gpio.c            |  2 +-
 arch/arm/mach-s5pc100/setup-sdhci-gpio.c           |  1 -
 arch/arm/mach-s5pv210/setup-sdhci-gpio.c           |  1 -
 arch/arm/plat-samsung/include/plat/sdhci.h         | 56 +---------------------
 drivers/mmc/host/Kconfig                           |  2 +-
 .../mmc/host/sdhci-s3c-regs.h                      |  0
 drivers/mmc/host/sdhci-s3c.c                       |  5 +-
 include/linux/platform_data/mmc-sdhci-s3c.h        | 56 ++++++++++++++++++++++
 8 files changed, 61 insertions(+), 62 deletions(-)
 rename arch/arm/plat-samsung/include/plat/regs-sdhci.h => drivers/mmc/host/sdhci-s3c-regs.h (100%)
 create mode 100644 include/linux/platform_data/mmc-sdhci-s3c.h

diff --git a/arch/arm/mach-exynos/setup-sdhci-gpio.c b/arch/arm/mach-exynos/setup-sdhci-gpio.c
index e8d08bf..d5b98c8 100644
--- a/arch/arm/mach-exynos/setup-sdhci-gpio.c
+++ b/arch/arm/mach-exynos/setup-sdhci-gpio.c
@@ -19,8 +19,8 @@
 #include <linux/mmc/host.h>
 #include <linux/mmc/card.h>
 
+#include <mach/gpio.h>
 #include <plat/gpio-cfg.h>
-#include <plat/regs-sdhci.h>
 #include <plat/sdhci.h>
 
 void exynos4_setup_sdhci0_cfg_gpio(struct platform_device *dev, int width)
diff --git a/arch/arm/mach-s5pc100/setup-sdhci-gpio.c b/arch/arm/mach-s5pc100/setup-sdhci-gpio.c
index 03c02d0..6010c03 100644
--- a/arch/arm/mach-s5pc100/setup-sdhci-gpio.c
+++ b/arch/arm/mach-s5pc100/setup-sdhci-gpio.c
@@ -19,7 +19,6 @@
 #include <linux/mmc/card.h>
 
 #include <plat/gpio-cfg.h>
-#include <plat/regs-sdhci.h>
 #include <plat/sdhci.h>
 
 void s5pc100_setup_sdhci0_cfg_gpio(struct platform_device *dev, int width)
diff --git a/arch/arm/mach-s5pv210/setup-sdhci-gpio.c b/arch/arm/mach-s5pv210/setup-sdhci-gpio.c
index 3e3ac05..0512ada 100644
--- a/arch/arm/mach-s5pv210/setup-sdhci-gpio.c
+++ b/arch/arm/mach-s5pv210/setup-sdhci-gpio.c
@@ -20,7 +20,6 @@
 #include <linux/mmc/card.h>
 
 #include <plat/gpio-cfg.h>
-#include <plat/regs-sdhci.h>
 #include <plat/sdhci.h>
 
 void s5pv210_setup_sdhci0_cfg_gpio(struct platform_device *dev, int width)
diff --git a/arch/arm/plat-samsung/include/plat/sdhci.h b/arch/arm/plat-samsung/include/plat/sdhci.h
index 5560586..ce1d0f7 100644
--- a/arch/arm/plat-samsung/include/plat/sdhci.h
+++ b/arch/arm/plat-samsung/include/plat/sdhci.h
@@ -18,62 +18,9 @@
 #ifndef __PLAT_S3C_SDHCI_H
 #define __PLAT_S3C_SDHCI_H __FILE__
 
+#include <linux/platform_data/mmc-sdhci-s3c.h>
 #include <plat/devs.h>
 
-struct platform_device;
-struct mmc_host;
-struct mmc_card;
-struct mmc_ios;
-
-enum cd_types {
-	S3C_SDHCI_CD_INTERNAL,	/* use mmc internal CD line */
-	S3C_SDHCI_CD_EXTERNAL,	/* use external callback */
-	S3C_SDHCI_CD_GPIO,	/* use external gpio pin for CD line */
-	S3C_SDHCI_CD_NONE,	/* no CD line, use polling to detect card */
-	S3C_SDHCI_CD_PERMANENT,	/* no CD line, card permanently wired to host */
-};
-
-/**
- * struct s3c_sdhci_platdata() - Platform device data for Samsung SDHCI
- * @max_width: The maximum number of data bits supported.
- * @host_caps: Standard MMC host capabilities bit field.
- * @host_caps2: The second standard MMC host capabilities bit field.
- * @cd_type: Type of Card Detection method (see cd_types enum above)
- * @ext_cd_init: Initialize external card detect subsystem. Called on
- *		 sdhci-s3c driver probe when cd_type == S3C_SDHCI_CD_EXTERNAL.
- *		 notify_func argument is a callback to the sdhci-s3c driver
- *		 that triggers the card detection event. Callback arguments:
- *		 dev is pointer to platform device of the host controller,
- *		 state is new state of the card (0 - removed, 1 - inserted).
- * @ext_cd_cleanup: Cleanup external card detect subsystem. Called on
- *		 sdhci-s3c driver remove when cd_type == S3C_SDHCI_CD_EXTERNAL.
- *		 notify_func argument is the same callback as for ext_cd_init.
- * @ext_cd_gpio: gpio pin used for external CD line, valid only if
- *		 cd_type == S3C_SDHCI_CD_GPIO
- * @ext_cd_gpio_invert: invert values for external CD gpio line
- * @cfg_gpio: Configure the GPIO for a specific card bit-width
- *
- * Initialisation data specific to either the machine or the platform
- * for the device driver to use or call-back when configuring gpio or
- * card speed information.
-*/
-struct s3c_sdhci_platdata {
-	unsigned int	max_width;
-	unsigned int	host_caps;
-	unsigned int	host_caps2;
-	unsigned int	pm_caps;
-	enum cd_types	cd_type;
-
-	int		ext_cd_gpio;
-	bool		ext_cd_gpio_invert;
-	int	(*ext_cd_init)(void (*notify_func)(struct platform_device *,
-						   int state));
-	int	(*ext_cd_cleanup)(void (*notify_func)(struct platform_device *,
-						      int state));
-
-	void	(*cfg_gpio)(struct platform_device *dev, int width);
-};
-
 /* s3c_sdhci_set_platdata() - common helper for setting SDHCI platform data
  * @pd: The default platform data for this device.
  * @set: Pointer to the platform data to fill in.
@@ -378,5 +325,4 @@ static inline void s3c_sdhci_setname(int id, char *name)
 		break;
 	}
 }
-
 #endif /* __PLAT_S3C_SDHCI_H */
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index d88219e..d054744 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -180,7 +180,7 @@ config MMC_SDHCI_TEGRA
 
 config MMC_SDHCI_S3C
 	tristate "SDHCI support on Samsung S3C SoC"
-	depends on MMC_SDHCI && PLAT_SAMSUNG
+	depends on MMC_SDHCI && PLAT_SAMSUNG_SINGLE
 	help
 	  This selects the Secure Digital Host Controller Interface (SDHCI)
 	  often referrered to as the HSMMC block in some of the Samsung S3C
diff --git a/arch/arm/plat-samsung/include/plat/regs-sdhci.h b/drivers/mmc/host/sdhci-s3c-regs.h
similarity index 100%
rename from arch/arm/plat-samsung/include/plat/regs-sdhci.h
rename to drivers/mmc/host/sdhci-s3c-regs.h
diff --git a/drivers/mmc/host/sdhci-s3c.c b/drivers/mmc/host/sdhci-s3c.c
index 7363efe..e4f52b5 100644
--- a/drivers/mmc/host/sdhci-s3c.c
+++ b/drivers/mmc/host/sdhci-s3c.c
@@ -15,6 +15,7 @@
 #include <linux/delay.h>
 #include <linux/dma-mapping.h>
 #include <linux/platform_device.h>
+#include <linux/platform_data/mmc-sdhci-s3c.h>
 #include <linux/slab.h>
 #include <linux/clk.h>
 #include <linux/io.h>
@@ -28,9 +29,7 @@
 
 #include <linux/mmc/host.h>
 
-#include <plat/sdhci.h>
-#include <plat/regs-sdhci.h>
-
+#include "sdhci-s3c-regs.h"
 #include "sdhci.h"
 
 #define MAX_BUS_CLK	(4)
diff --git a/include/linux/platform_data/mmc-sdhci-s3c.h b/include/linux/platform_data/mmc-sdhci-s3c.h
new file mode 100644
index 0000000..249f023
--- /dev/null
+++ b/include/linux/platform_data/mmc-sdhci-s3c.h
@@ -0,0 +1,56 @@
+#ifndef __PLATFORM_DATA_SDHCI_S3C_H
+#define __PLATFORM_DATA_SDHCI_S3C_H
+
+struct platform_device;
+
+enum cd_types {
+	S3C_SDHCI_CD_INTERNAL,	/* use mmc internal CD line */
+	S3C_SDHCI_CD_EXTERNAL,	/* use external callback */
+	S3C_SDHCI_CD_GPIO,	/* use external gpio pin for CD line */
+	S3C_SDHCI_CD_NONE,	/* no CD line, use polling to detect card */
+	S3C_SDHCI_CD_PERMANENT,	/* no CD line, card permanently wired to host */
+};
+
+/**
+ * struct s3c_sdhci_platdata() - Platform device data for Samsung SDHCI
+ * @max_width: The maximum number of data bits supported.
+ * @host_caps: Standard MMC host capabilities bit field.
+ * @host_caps2: The second standard MMC host capabilities bit field.
+ * @cd_type: Type of Card Detection method (see cd_types enum above)
+ * @ext_cd_init: Initialize external card detect subsystem. Called on
+ *		 sdhci-s3c driver probe when cd_type == S3C_SDHCI_CD_EXTERNAL.
+ *		 notify_func argument is a callback to the sdhci-s3c driver
+ *		 that triggers the card detection event. Callback arguments:
+ *		 dev is pointer to platform device of the host controller,
+ *		 state is new state of the card (0 - removed, 1 - inserted).
+ * @ext_cd_cleanup: Cleanup external card detect subsystem. Called on
+ *		 sdhci-s3c driver remove when cd_type == S3C_SDHCI_CD_EXTERNAL.
+ *		 notify_func argument is the same callback as for ext_cd_init.
+ * @ext_cd_gpio: gpio pin used for external CD line, valid only if
+ *		 cd_type == S3C_SDHCI_CD_GPIO
+ * @ext_cd_gpio_invert: invert values for external CD gpio line
+ * @cfg_gpio: Configure the GPIO for a specific card bit-width
+ *
+ * Initialisation data specific to either the machine or the platform
+ * for the device driver to use or call-back when configuring gpio or
+ * card speed information.
+*/
+struct s3c_sdhci_platdata {
+	unsigned int	max_width;
+	unsigned int	host_caps;
+	unsigned int	host_caps2;
+	unsigned int	pm_caps;
+	enum cd_types	cd_type;
+
+	int		ext_cd_gpio;
+	bool		ext_cd_gpio_invert;
+	int	(*ext_cd_init)(void (*notify_func)(struct platform_device *,
+						   int state));
+	int	(*ext_cd_cleanup)(void (*notify_func)(struct platform_device *,
+						      int state));
+
+	void	(*cfg_gpio)(struct platform_device *dev, int width);
+};
+
+
+#endif /* __PLATFORM_DATA_SDHCI_S3C_H */
-- 
1.8.1.2



From arnd at arndb.de  Wed Apr 10 20:05:04 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 11 Apr 2013 02:05:04 +0200
Subject: [PATCH 22/30] ASoC: samsung/idma: export idma_reg_addr_init
In-Reply-To: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
References: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
Message-ID: <1365638712-1028578-23-git-send-email-arnd@arndb.de>

The idma_reg_addr_init function is used by the samsung i2s driver,
which can be a loadable module, so we have to export this function.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Cc: alsa-devel at alsa-project.org
Cc: Mark Brown <broonie at opensource.wolfsonmicro.com>
Cc: Liam Girdwood <lgirdwood at gmail.com>
---
 sound/soc/samsung/idma.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sound/soc/samsung/idma.c b/sound/soc/samsung/idma.c
index f36a541..6e5fed3 100644
--- a/sound/soc/samsung/idma.c
+++ b/sound/soc/samsung/idma.c
@@ -411,6 +411,7 @@ void idma_reg_addr_init(void __iomem *regs, dma_addr_t addr)
 	idma.regs = regs;
 	idma.lp_tx_addr = addr;
 }
+EXPORT_SYMBOL_GPL(idma_reg_addr_init);
 
 static struct snd_soc_platform_driver asoc_idma_platform = {
 	.ops = &idma_ops,
-- 
1.8.1.2



From arnd at arndb.de  Wed Apr 10 20:05:00 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 11 Apr 2013 02:05:00 +0200
Subject: [PATCH 18/30] ASoC: samsung: move plat/ headers to local directory
In-Reply-To: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
References: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
Message-ID: <1365638712-1028578-19-git-send-email-arnd@arndb.de>

The plat/iis.h and plat/ac97.h files in the samsung platform are
only needed by the ASoC drivers, so they can be moved into the
same directory, as one more step towards a multiplatform build.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Cc: alsa-devel at alsa-project.org
Cc: Mark Brown <broonie at opensource.wolfsonmicro.com>
Cc: Liam Girdwood <lgirdwood at gmail.com>
---
 arch/arm/mach-s3c24xx/dma-s3c2410.c                                   | 2 --
 arch/arm/mach-s3c24xx/dma-s3c2412.c                                   | 2 --
 arch/arm/mach-s3c24xx/dma-s3c2440.c                                   | 2 --
 arch/arm/mach-s3c24xx/dma-s3c2443.c                                   | 2 --
 sound/soc/samsung/ac97.c                                              | 2 +-
 sound/soc/samsung/h1940_uda1380.c                                     | 2 +-
 sound/soc/samsung/neo1973_wm8753.c                                    | 2 +-
 {arch/arm/plat-samsung/include/plat => sound/soc/samsung}/regs-ac97.h | 0
 {arch/arm/plat-samsung/include/plat => sound/soc/samsung}/regs-iis.h  | 0
 sound/soc/samsung/rx1950_uda1380.c                                    | 2 +-
 sound/soc/samsung/s3c24xx-i2s.c                                       | 2 +-
 sound/soc/samsung/s3c24xx_uda134x.c                                   | 2 +-
 12 files changed, 6 insertions(+), 14 deletions(-)
 rename {arch/arm/plat-samsung/include/plat => sound/soc/samsung}/regs-ac97.h (100%)
 rename {arch/arm/plat-samsung/include/plat => sound/soc/samsung}/regs-iis.h (100%)

diff --git a/arch/arm/mach-s3c24xx/dma-s3c2410.c b/arch/arm/mach-s3c24xx/dma-s3c2410.c
index a6c94b8..30aa53f 100644
--- a/arch/arm/mach-s3c24xx/dma-s3c2410.c
+++ b/arch/arm/mach-s3c24xx/dma-s3c2410.c
@@ -25,10 +25,8 @@
 
 #include <plat/regs-serial.h>
 #include <mach/regs-gpio.h>
-#include <plat/regs-ac97.h>
 #include <plat/regs-dma.h>
 #include <mach/regs-lcd.h>
-#include <plat/regs-iis.h>
 #include <plat/regs-spi.h>
 
 static struct s3c24xx_dma_map __initdata s3c2410_dma_mappings[] = {
diff --git a/arch/arm/mach-s3c24xx/dma-s3c2412.c b/arch/arm/mach-s3c24xx/dma-s3c2412.c
index c0e8c3f..ab1700e 100644
--- a/arch/arm/mach-s3c24xx/dma-s3c2412.c
+++ b/arch/arm/mach-s3c24xx/dma-s3c2412.c
@@ -25,10 +25,8 @@
 
 #include <plat/regs-serial.h>
 #include <mach/regs-gpio.h>
-#include <plat/regs-ac97.h>
 #include <plat/regs-dma.h>
 #include <mach/regs-lcd.h>
-#include <plat/regs-iis.h>
 #include <plat/regs-spi.h>
 
 #define MAP(x) { (x)| DMA_CH_VALID, (x)| DMA_CH_VALID, (x)| DMA_CH_VALID, (x)| DMA_CH_VALID }
diff --git a/arch/arm/mach-s3c24xx/dma-s3c2440.c b/arch/arm/mach-s3c24xx/dma-s3c2440.c
index 1c08eccd..cd25de2 100644
--- a/arch/arm/mach-s3c24xx/dma-s3c2440.c
+++ b/arch/arm/mach-s3c24xx/dma-s3c2440.c
@@ -25,10 +25,8 @@
 
 #include <plat/regs-serial.h>
 #include <mach/regs-gpio.h>
-#include <plat/regs-ac97.h>
 #include <plat/regs-dma.h>
 #include <mach/regs-lcd.h>
-#include <plat/regs-iis.h>
 #include <plat/regs-spi.h>
 
 static struct s3c24xx_dma_map __initdata s3c2440_dma_mappings[] = {
diff --git a/arch/arm/mach-s3c24xx/dma-s3c2443.c b/arch/arm/mach-s3c24xx/dma-s3c2443.c
index 000e4c6..5fe3539 100644
--- a/arch/arm/mach-s3c24xx/dma-s3c2443.c
+++ b/arch/arm/mach-s3c24xx/dma-s3c2443.c
@@ -25,10 +25,8 @@
 
 #include <plat/regs-serial.h>
 #include <mach/regs-gpio.h>
-#include <plat/regs-ac97.h>
 #include <plat/regs-dma.h>
 #include <mach/regs-lcd.h>
-#include <plat/regs-iis.h>
 #include <plat/regs-spi.h>
 
 #define MAP(x) { \
diff --git a/sound/soc/samsung/ac97.c b/sound/soc/samsung/ac97.c
index 0df3c56..c76abdf 100644
--- a/sound/soc/samsung/ac97.c
+++ b/sound/soc/samsung/ac97.c
@@ -20,7 +20,7 @@
 #include <sound/soc.h>
 
 #include <mach/dma.h>
-#include <plat/regs-ac97.h>
+#include "regs-ac97.h"
 #include <linux/platform_data/asoc-s3c.h>
 
 #include "dma.h"
diff --git a/sound/soc/samsung/h1940_uda1380.c b/sound/soc/samsung/h1940_uda1380.c
index 15a3817..fa91376 100644
--- a/sound/soc/samsung/h1940_uda1380.c
+++ b/sound/soc/samsung/h1940_uda1380.c
@@ -20,7 +20,7 @@
 #include <sound/soc.h>
 #include <sound/jack.h>
 
-#include <plat/regs-iis.h>
+#include "regs-iis.h"
 #include <asm/mach-types.h>
 
 #include "s3c24xx-i2s.h"
diff --git a/sound/soc/samsung/neo1973_wm8753.c b/sound/soc/samsung/neo1973_wm8753.c
index a301d8c..ccc601d 100644
--- a/sound/soc/samsung/neo1973_wm8753.c
+++ b/sound/soc/samsung/neo1973_wm8753.c
@@ -21,7 +21,7 @@
 #include <sound/soc.h>
 
 #include <asm/mach-types.h>
-#include <plat/regs-iis.h>
+#include "regs-iis.h"
 #include <mach/gta02.h>
 
 #include "../codecs/wm8753.h"
diff --git a/arch/arm/plat-samsung/include/plat/regs-ac97.h b/sound/soc/samsung/regs-ac97.h
similarity index 100%
rename from arch/arm/plat-samsung/include/plat/regs-ac97.h
rename to sound/soc/samsung/regs-ac97.h
diff --git a/arch/arm/plat-samsung/include/plat/regs-iis.h b/sound/soc/samsung/regs-iis.h
similarity index 100%
rename from arch/arm/plat-samsung/include/plat/regs-iis.h
rename to sound/soc/samsung/regs-iis.h
diff --git a/sound/soc/samsung/rx1950_uda1380.c b/sound/soc/samsung/rx1950_uda1380.c
index a5826ea..704460a 100644
--- a/sound/soc/samsung/rx1950_uda1380.c
+++ b/sound/soc/samsung/rx1950_uda1380.c
@@ -24,7 +24,7 @@
 #include <sound/soc.h>
 #include <sound/jack.h>
 
-#include <plat/regs-iis.h>
+#include "regs-iis.h"
 #include <asm/mach-types.h>
 
 #include "s3c24xx-i2s.h"
diff --git a/sound/soc/samsung/s3c24xx-i2s.c b/sound/soc/samsung/s3c24xx-i2s.c
index 13f6dd1..a7b17c1 100644
--- a/sound/soc/samsung/s3c24xx-i2s.c
+++ b/sound/soc/samsung/s3c24xx-i2s.c
@@ -24,7 +24,7 @@
 #include <sound/pcm_params.h>
 
 #include <mach/dma.h>
-#include <plat/regs-iis.h>
+#include "regs-iis.h"
 
 #include "dma.h"
 #include "s3c24xx-i2s.h"
diff --git a/sound/soc/samsung/s3c24xx_uda134x.c b/sound/soc/samsung/s3c24xx_uda134x.c
index 333e1b7..1b7b52b 100644
--- a/sound/soc/samsung/s3c24xx_uda134x.c
+++ b/sound/soc/samsung/s3c24xx_uda134x.c
@@ -18,7 +18,7 @@
 #include <sound/soc.h>
 #include <sound/s3c24xx_uda134x.h>
 
-#include <plat/regs-iis.h>
+#include "regs-iis.h"
 
 #include "s3c24xx-i2s.h"
 
-- 
1.8.1.2



From arnd at arndb.de  Wed Apr 10 20:05:01 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 11 Apr 2013 02:05:01 +0200
Subject: [PATCH 19/30] ASoC: samsung: use irq resource for idma
In-Reply-To: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
References: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
Message-ID: <1365638712-1028578-20-git-send-email-arnd@arndb.de>

With multiplatform kernels, we cannot use hardwired IRQ
numbers in device drivers. This changes the idma driver
to use a proper resource, like all other drivers do.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Cc: alsa-devel at alsa-project.org
Cc: Mark Brown <broonie at opensource.wolfsonmicro.com>
Cc: Liam Girdwood <lgirdwood at gmail.com>
---
 arch/arm/plat-samsung/devs.c |  6 ++++++
 sound/soc/samsung/idma.c     | 10 ++++++++--
 2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/arch/arm/plat-samsung/devs.c b/arch/arm/plat-samsung/devs.c
index 78be9c0..b441908 100644
--- a/arch/arm/plat-samsung/devs.c
+++ b/arch/arm/plat-samsung/devs.c
@@ -145,14 +145,20 @@ struct platform_device s3c_device_camif = {
 
 /* ASOC DMA */
 
+#ifdef CONFIG_PLAT_S5P 
+static struct resource samsung_asoc_idma_resource = DEFINE_RES_IRQ(IRQ_I2S0);
+
 struct platform_device samsung_asoc_idma = {
 	.name		= "samsung-idma",
 	.id		= -1,
+	.num_resources	= 1,
+	.resource	= &samsung_asoc_idma_resource,
 	.dev		= {
 		.dma_mask		= &samsung_device_dma_mask,
 		.coherent_dma_mask	= DMA_BIT_MASK(32),
 	}
 };
+#endif
 
 /* FB */
 
diff --git a/sound/soc/samsung/idma.c b/sound/soc/samsung/idma.c
index a07950b..f36a541 100644
--- a/sound/soc/samsung/idma.c
+++ b/sound/soc/samsung/idma.c
@@ -68,6 +68,8 @@ static struct idma_info {
 	dma_addr_t	lp_tx_addr;
 } idma;
 
+static int idma_irq;
+
 static void idma_getpos(dma_addr_t *src)
 {
 	*src = idma.lp_tx_addr +
@@ -305,7 +307,7 @@ static int idma_open(struct snd_pcm_substream *substream)
 	if (prtd == NULL)
 		return -ENOMEM;
 
-	ret = request_irq(IRQ_I2S0, iis_irq, 0, "i2s", prtd);
+	ret = request_irq(idma_irq, iis_irq, 0, "i2s", prtd);
 	if (ret < 0) {
 		pr_err("fail to claim i2s irq , ret = %d\n", ret);
 		kfree(prtd);
@@ -324,7 +326,7 @@ static int idma_close(struct snd_pcm_substream *substream)
 	struct snd_pcm_runtime *runtime = substream->runtime;
 	struct idma_ctrl *prtd = runtime->private_data;
 
-	free_irq(IRQ_I2S0, prtd);
+	free_irq(idma_irq, prtd);
 
 	if (!prtd)
 		pr_err("idma_close called with prtd == NULL\n");
@@ -418,6 +420,10 @@ static struct snd_soc_platform_driver asoc_idma_platform = {
 
 static int asoc_idma_platform_probe(struct platform_device *pdev)
 {
+	idma_irq = platform_get_irq(pdev, 0);
+	if (idma_irq < 0)
+		return idma_irq;
+
 	return snd_soc_register_platform(&pdev->dev, &asoc_idma_platform);
 }
 
-- 
1.8.1.2



From arnd at arndb.de  Wed Apr 10 20:05:05 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 11 Apr 2013 02:05:05 +0200
Subject: [PATCH 23/30] clk: exynos: prepare for multiplatform
In-Reply-To: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
References: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
Message-ID: <1365638712-1028578-24-git-send-email-arnd@arndb.de>

The new common clock drivers for exynos are using compile
time constants and soc_is_exynos* macros to provide backwards
compatibility for pre-DT systems, which is not possible with
multiplatform kernels. This moves all the necessary
information back into platform code and removes the mach/*
header inclusions.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Cc: Mike Turquette <mturquette at linaro.org>
---
 arch/arm/mach-exynos/common.c        |  2 +-
 arch/arm/mach-exynos/common.h        |  2 +-
 drivers/clk/samsung/clk-exynos4.c    | 93 ++++++++++++++++--------------------
 drivers/clk/samsung/clk-exynos5250.c |  1 -
 drivers/clk/samsung/clk-exynos5440.c |  1 -
 drivers/clk/samsung/clk.h            |  2 -
 6 files changed, 44 insertions(+), 57 deletions(-)

diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
index 46089fe..87b2e06 100644
--- a/arch/arm/mach-exynos/common.c
+++ b/arch/arm/mach-exynos/common.c
@@ -445,7 +445,7 @@ void __init exynos_init_time(void)
 	} else {
 		/* todo: remove after migrating legacy E4 platforms to dt */
 #ifdef CONFIG_ARCH_EXYNOS4
-		exynos4_clk_init(NULL);
+		exynos4_clk_init(NULL, !soc_is_exynos4210(), S5P_VA_CMU, readl(S5P_VA_CHIPID + 8) & 1);
 		exynos4_clk_register_fixed_ext(xxti_f, xusbxti_f);
 #endif
 		mct_init();
diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
index b17448c..9832e03 100644
--- a/arch/arm/mach-exynos/common.h
+++ b/arch/arm/mach-exynos/common.h
@@ -27,7 +27,7 @@ void exynos5_restart(char mode, const char *cmd);
 void exynos_init_late(void);
 
 /* ToDo: remove these after migrating legacy exynos4 platforms to dt */
-void exynos4_clk_init(struct device_node *np);
+void exynos4_clk_init(struct device_node *np, int is_exynos4210, void __iomem *reg_base, unsigned long xom);
 void exynos4_clk_register_fixed_ext(unsigned long, unsigned long);
 
 void exynos_firmware_init(void);
diff --git a/drivers/clk/samsung/clk-exynos4.c b/drivers/clk/samsung/clk-exynos4.c
index 7104669..d0940e6 100644
--- a/drivers/clk/samsung/clk-exynos4.c
+++ b/drivers/clk/samsung/clk-exynos4.c
@@ -16,7 +16,6 @@
 #include <linux/of.h>
 #include <linux/of_address.h>
 
-#include <plat/cpu.h>
 #include "clk.h"
 #include "clk-pll.h"
 
@@ -910,16 +909,6 @@ struct samsung_gate_clock exynos4x12_gate_clks[] __initdata = {
 			CLK_IGNORE_UNUSED, 0),
 };
 
-#ifdef CONFIG_OF
-static struct of_device_id exynos4_clk_ids[] __initdata = {
-	{ .compatible = "samsung,exynos4210-clock",
-			.data = (void *)EXYNOS4210, },
-	{ .compatible = "samsung,exynos4412-clock",
-			.data = (void *)EXYNOS4X12, },
-	{ },
-};
-#endif
-
 /*
  * The parent of the fin_pll clock is selected by the XOM[0] bit. This bit
  * resides in chipid register space, outside of the clock controller memory
@@ -927,33 +916,40 @@ static struct of_device_id exynos4_clk_ids[] __initdata = {
  * controller is first remapped and the value of XOM[0] bit is read to
  * determine the parent clock.
  */
-static void __init exynos4_clk_register_finpll(void)
+static unsigned long exynos4_get_xom(void)
 {
-	struct samsung_fixed_rate_clock fclk;
+	unsigned long xom = 0;
+	void __iomem *chipid_base;
 	struct device_node *np;
-	struct clk *clk;
-	void __iomem *chipid_base = S5P_VA_CHIPID;
-	unsigned long xom, finpll_f = 24000000;
-	char *parent_name;
 
 	np = of_find_compatible_node(NULL, NULL, "samsung,exynos4210-chipid");
-	if (np)
+	if (np) {
 		chipid_base = of_iomap(np, 0);
 
-	if (chipid_base) {
-		xom = readl(chipid_base + 8);
-		parent_name = xom & 1 ? "xusbxti" : "xxti";
-		clk = clk_get(NULL, parent_name);
-		if (IS_ERR(clk)) {
-			pr_err("%s: failed to lookup parent clock %s, assuming "
-				"fin_pll clock frequency is 24MHz\n", __func__,
-				parent_name);
-		} else {
-			finpll_f = clk_get_rate(clk);
-		}
+		if (chipid_base)
+			xom = readl(chipid_base + 8);
+
+		iounmap(chipid_base);
+	}
+
+	return xom;
+}
+
+static void __init exynos4_clk_register_finpll(unsigned long xom)
+{
+	struct samsung_fixed_rate_clock fclk;
+	struct clk *clk;
+	unsigned long finpll_f = 24000000;
+	char *parent_name;
+
+	parent_name = xom & 1 ? "xusbxti" : "xxti";
+	clk = clk_get(NULL, parent_name);
+	if (IS_ERR(clk)) {
+		pr_err("%s: failed to lookup parent clock %s, assuming "
+			"fin_pll clock frequency is 24MHz\n", __func__,
+			parent_name);
 	} else {
-		pr_err("%s: failed to map chipid registers, assuming "
-			"fin_pll clock frequency is 24MHz\n", __func__);
+		finpll_f = clk_get_rate(clk);
 	}
 
 	fclk.id = fin_pll;
@@ -963,8 +959,6 @@ static void __init exynos4_clk_register_finpll(void)
 	fclk.fixed_rate = finpll_f;
 	samsung_clk_register_fixed_rate(&fclk, 1);
 
-	if (np)
-		iounmap(chipid_base);
 }
 
 /*
@@ -988,28 +982,14 @@ static __initdata struct of_device_id ext_clk_match[] = {
 };
 
 /* register exynos4 clocks */
-void __init exynos4_clk_init(struct device_node *np)
+void __init exynos4_clk_init(struct device_node *np, enum exynos4_soc exynos4_soc, void __iomem *reg_base, unsigned long xom)
 {
-	void __iomem *reg_base;
 	struct clk *apll, *mpll, *epll, *vpll;
-	u32 exynos4_soc;
 
 	if (np) {
-		const struct of_device_id *match;
-		match = of_match_node(exynos4_clk_ids, np);
-		exynos4_soc = (u32)match->data;
-
 		reg_base = of_iomap(np, 0);
 		if (!reg_base)
 			panic("%s: failed to map registers\n", __func__);
-	} else {
-		reg_base = S5P_VA_CMU;
-		if (soc_is_exynos4210())
-			exynos4_soc = EXYNOS4210;
-		else if (soc_is_exynos4212() || soc_is_exynos4412())
-			exynos4_soc = EXYNOS4X12;
-		else
-			panic("%s: unable to determine soc\n", __func__);
 	}
 
 	if (exynos4_soc == EXYNOS4210)
@@ -1026,7 +1006,7 @@ void __init exynos4_clk_init(struct device_node *np)
 			ARRAY_SIZE(exynos4_fixed_rate_ext_clks),
 			ext_clk_match);
 
-	exynos4_clk_register_finpll();
+	exynos4_clk_register_finpll(xom);
 
 	if (exynos4_soc == EXYNOS4210) {
 		apll = samsung_clk_register_pll45xx("fout_apll", "fin_pll",
@@ -1087,5 +1067,16 @@ void __init exynos4_clk_init(struct device_node *np)
 		_get_rate("sclk_epll"), _get_rate("sclk_vpll"),
 		_get_rate("arm_clk"));
 }
-CLK_OF_DECLARE(exynos4210_clk, "samsung,exynos4210-clock", exynos4_clk_init);
-CLK_OF_DECLARE(exynos4412_clk, "samsung,exynos4412-clock", exynos4_clk_init);
+
+
+static void __init exynos4210_clk_init(struct device_node *np)
+{
+	exynos4_clk_init(np, EXYNOS4210, NULL, exynos4_get_xom());
+}
+CLK_OF_DECLARE(exynos4210_clk, "samsung,exynos4210-clock", exynos4210_clk_init);
+
+static void __init exynos4412_clk_init(struct device_node *np)
+{
+	exynos4_clk_init(np, EXYNOS4X12, NULL, exynos4_get_xom());
+}
+CLK_OF_DECLARE(exynos4412_clk, "samsung,exynos4412-clock", exynos4412_clk_init);
diff --git a/drivers/clk/samsung/clk-exynos5250.c b/drivers/clk/samsung/clk-exynos5250.c
index 7290faa..61068cd 100644
--- a/drivers/clk/samsung/clk-exynos5250.c
+++ b/drivers/clk/samsung/clk-exynos5250.c
@@ -16,7 +16,6 @@
 #include <linux/of.h>
 #include <linux/of_address.h>
 
-#include <plat/cpu.h>
 #include "clk.h"
 #include "clk-pll.h"
 
diff --git a/drivers/clk/samsung/clk-exynos5440.c b/drivers/clk/samsung/clk-exynos5440.c
index a0a094c..7d54341 100644
--- a/drivers/clk/samsung/clk-exynos5440.c
+++ b/drivers/clk/samsung/clk-exynos5440.c
@@ -15,7 +15,6 @@
 #include <linux/of.h>
 #include <linux/of_address.h>
 
-#include <plat/cpu.h>
 #include "clk.h"
 #include "clk-pll.h"
 
diff --git a/drivers/clk/samsung/clk.h b/drivers/clk/samsung/clk.h
index 10b2111..e4ad6ea 100644
--- a/drivers/clk/samsung/clk.h
+++ b/drivers/clk/samsung/clk.h
@@ -20,8 +20,6 @@
 #include <linux/of.h>
 #include <linux/of_address.h>
 
-#include <mach/map.h>
-
 /**
  * struct samsung_clock_alias: information about mux clock
  * @id: platform specific id of the clock.
-- 
1.8.1.2



From arnd at arndb.de  Wed Apr 10 20:05:09 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 11 Apr 2013 02:05:09 +0200
Subject: [PATCH 27/30] irqchip: exynos: localize irq lookup for ATAGS
In-Reply-To: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
References: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
Message-ID: <1365638712-1028578-28-git-send-email-arnd@arndb.de>

The IRQ_SPI() macro is not available in the driver when building with sparse
IRQs or multiplatform, so let's move all users of this into one function
that we can leave out when building DT-only.

Signed-off-by: Arnd Bergmann <arnd at arnd.de>
Cc: Thomas Gleixner <tglx at linutronix.de>
---
 drivers/irqchip/exynos-combiner.c | 19 ++++++++++++-------
 1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/drivers/irqchip/exynos-combiner.c b/drivers/irqchip/exynos-combiner.c
index ffb10aa..31a4e96 100644
--- a/drivers/irqchip/exynos-combiner.c
+++ b/drivers/irqchip/exynos-combiner.c
@@ -19,7 +19,9 @@
 #include <linux/of_irq.h>
 #include <asm/mach/irq.h>
 
+#ifdef CONFIG_EXYNOS_ATAGS
 #include <plat/cpu.h>
+#endif
 
 #include "irqchip.h"
 
@@ -183,8 +185,12 @@ static struct irq_domain_ops combiner_irq_domain_ops = {
 	.map	= combiner_irq_domain_map,
 };
 
-static unsigned int exynos4x12_combiner_extra_irq(int group)
+static unsigned int combiner_lookup_irq(int group)
 {
+#ifdef CONFIG_EXYNOS_ATAGS
+	if (group < EXYNOS4210_MAX_COMBINER_NR || soc_is_exynos5250())
+		return IRQ_SPI(group);
+
 	switch (group) {
 	case 16:
 		return IRQ_SPI(107);
@@ -194,9 +200,9 @@ static unsigned int exynos4x12_combiner_extra_irq(int group)
 		return IRQ_SPI(48);
 	case 19:
 		return IRQ_SPI(42);
-	default:
-		return 0;
 	}
+#endif
+	return 0;
 }
 
 void __init combiner_init(void __iomem *combiner_base,
@@ -229,14 +235,13 @@ void __init combiner_init(void __iomem *combiner_base,
 	}
 
 	for (i = 0; i < max_nr; i++) {
-		if (i < EXYNOS4210_MAX_COMBINER_NR || soc_is_exynos5250())
-			irq = IRQ_SPI(i);
-		else
-			irq = exynos4x12_combiner_extra_irq(i);
 #ifdef CONFIG_OF
 		if (np)
 			irq = irq_of_parse_and_map(np, i);
+		else
 #endif
+			irq = combiner_lookup_irq(i);
+
 		combiner_init_one(&combiner_data[i], i,
 				  combiner_base + (i >> 2) * 0x10, irq);
 		combiner_cascade_irq(&combiner_data[i], irq);
-- 
1.8.1.2



From arnd at arndb.de  Wed Apr 10 20:05:02 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 11 Apr 2013 02:05:02 +0200
Subject: [PATCH 20/30] ASoC: samsung: convert to dmaengine API
In-Reply-To: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
References: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
Message-ID: <1365638712-1028578-21-git-send-email-arnd@arndb.de>

In order to build the exynos kernel with CONFIG_ARCH_MULTIPLATFORM,
we must convert all users of the Samsung private DMA interface to
the generic dmaengine API. This version of the patch adds the
generic dmaengine API as an alternative to the existing samsung
specific one. Once all the older platforms provide support for
the common dmaengine interfaces, we can remove the old code.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Cc: alsa-devel at alsa-project.org
Cc: Mark Brown <broonie at opensource.wolfsonmicro.com>
Cc: Liam Girdwood <lgirdwood at gmail.com>
---
 sound/soc/samsung/dma.c   | 219 ++++++++++++++++++++++++++++++++++++++++++++++
 sound/soc/samsung/dma.h   |  15 +++-
 sound/soc/samsung/i2s.c   |   2 -
 sound/soc/samsung/pcm.c   |   1 -
 sound/soc/samsung/spdif.c |   1 -
 5 files changed, 232 insertions(+), 6 deletions(-)

diff --git a/sound/soc/samsung/dma.c b/sound/soc/samsung/dma.c
index 21b7926..9fd53df 100644
--- a/sound/soc/samsung/dma.c
+++ b/sound/soc/samsung/dma.c
@@ -22,8 +22,14 @@
 #include <sound/pcm_params.h>
 
 #include <asm/dma.h>
+
+#ifdef CONFIG_SAMSUNG_DMADEV
 #include <mach/hardware.h>
 #include <mach/dma.h>
+#else
+#include <linux/dmaengine.h>
+#include <linux/amba/pl330.h>
+#endif
 
 #include "dma.h"
 
@@ -62,11 +68,13 @@ struct runtime_data {
 
 static void audio_buffdone(void *data);
 
+#ifdef CONFIG_SAMSUNG_DMADEV
 /* dma_enqueue
  *
  * place a dma buffer onto the queue for the dma system
  * to handle.
  */
+
 static void dma_enqueue(struct snd_pcm_substream *substream)
 {
 	struct runtime_data *prtd = substream->runtime->private_data;
@@ -265,6 +273,217 @@ static int dma_trigger(struct snd_pcm_substream *substream, int cmd)
 
 	return ret;
 }
+#else
+/* dma_enqueue
+ *
+ * place a dma buffer onto the queue for the dma system
+ * to handle.
+ */
+
+static void dma_enqueue(struct snd_pcm_substream *substream)
+{
+	struct runtime_data *prtd = substream->runtime->private_data;
+	dma_addr_t pos = prtd->dma_pos;
+	unsigned long period = prtd->dma_period;
+	unsigned int limit;
+	enum dma_transfer_direction direction;
+	struct dma_chan *chan = prtd->params->ch;
+	struct dma_async_tx_descriptor *desc;
+
+	pr_debug("Entered %s\n", __func__);
+
+	limit = (prtd->dma_end - prtd->dma_start) / prtd->dma_period;
+
+	pr_debug("%s: loaded %d, limit %d\n",
+				__func__, prtd->dma_loaded, limit);
+
+	direction = (substream->stream == SNDRV_PCM_STREAM_PLAYBACK
+		     ? DMA_MEM_TO_DEV : DMA_DEV_TO_MEM);
+
+	while (prtd->dma_loaded < limit) {
+		pr_debug("dma_loaded: %d\n", prtd->dma_loaded);
+
+		if ((pos + period) > prtd->dma_end) {
+			period  = prtd->dma_end - pos;
+			pr_debug("%s: corrected dma len %ld\n",
+					__func__, period);
+		}
+
+		desc = dmaengine_prep_dma_cyclic(chan, pos,
+			 prtd->dma_period*limit, period, direction,
+			DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
+
+		if (desc) {
+			desc->callback = audio_buffdone;
+			desc->callback_param = substream;
+			dmaengine_submit(desc);
+		}
+
+		prtd->dma_loaded++;
+		pos += period;
+		if (pos >= prtd->dma_end)
+			pos = prtd->dma_start;
+	}
+
+	prtd->dma_pos = pos;
+}
+
+static void audio_buffdone(void *data)
+{
+	struct snd_pcm_substream *substream = data;
+	struct runtime_data *prtd = substream->runtime->private_data;
+
+	pr_debug("Entered %s\n", __func__);
+
+	if (prtd->state & ST_RUNNING) {
+		prtd->dma_pos += prtd->dma_period;
+		if (prtd->dma_pos >= prtd->dma_end)
+			prtd->dma_pos = prtd->dma_start;
+
+		if (substream)
+			snd_pcm_period_elapsed(substream);
+	}
+}
+
+static int dma_hw_params(struct snd_pcm_substream *substream,
+	struct snd_pcm_hw_params *params)
+{
+	struct snd_pcm_runtime *runtime = substream->runtime;
+	struct runtime_data *prtd = runtime->private_data;
+	struct snd_soc_pcm_runtime *rtd = substream->private_data;
+	unsigned long totbytes = params_buffer_bytes(params);
+	struct s3c_dma_params *dma =
+		snd_soc_dai_get_dma_data(rtd->cpu_dai, substream);
+
+	pr_debug("Entered %s\n", __func__);
+
+	/* return if this is a bufferless transfer e.g.
+	 * codec <--> BT codec or GSM modem -- lg FIXME */
+	if (!dma)
+		return 0;
+
+	/* this may get called several times by oss emulation
+	 * with different params -HW */
+	if (prtd->params == NULL) {
+		struct dma_slave_config config;
+		dma_cap_mask_t mask;
+
+		/* prepare DMA */
+		prtd->params = dma;
+
+		pr_debug("params %p, channel %d\n", prtd->params,
+			 prtd->params->channel);
+
+		dma_cap_zero(mask);
+		dma_cap_set(DMA_CYCLIC, mask);
+
+		prtd->params->ch = dma_request_slave_channel_compat(mask,
+			pl330_filter, (void *)prtd->params->channel,
+			rtd->cpu_dai->dev, prtd->params->ch_name);
+
+		memset(&config, 0, sizeof(struct dma_slave_config));
+
+		if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
+			config.direction = DMA_MEM_TO_DEV;
+			config.dst_addr = prtd->params->dma_addr;
+			config.dst_addr_width = prtd->params->dma_size;
+			config.dst_maxburst = 1;
+			dmaengine_slave_config(prtd->params->ch, &config);
+		} else {
+			config.direction = DMA_DEV_TO_MEM;
+			config.src_addr = prtd->params->dma_addr;
+			config.src_addr_width = prtd->params->dma_size;
+			config.src_maxburst = 1;
+			dmaengine_slave_config(prtd->params->ch, &config);
+		}
+	}
+
+	snd_pcm_set_runtime_buffer(substream, &substream->dma_buffer);
+
+	runtime->dma_bytes = totbytes;
+
+	spin_lock_irq(&prtd->lock);
+	prtd->dma_loaded = 0;
+	prtd->dma_period = params_period_bytes(params);
+	prtd->dma_start = runtime->dma_addr;
+	prtd->dma_pos = prtd->dma_start;
+	prtd->dma_end = prtd->dma_start + totbytes;
+	spin_unlock_irq(&prtd->lock);
+
+	return 0;
+}
+
+static int dma_hw_free(struct snd_pcm_substream *substream)
+{
+	struct runtime_data *prtd = substream->runtime->private_data;
+
+	pr_debug("Entered %s\n", __func__);
+
+	snd_pcm_set_runtime_buffer(substream, NULL);
+
+	if (prtd->params) {
+		dmaengine_terminate_all(prtd->params->ch);
+		dma_release_channel(prtd->params->ch);
+		prtd->params = NULL;
+	}
+
+	return 0;
+}
+
+static int dma_prepare(struct snd_pcm_substream *substream)
+{
+	struct runtime_data *prtd = substream->runtime->private_data;
+	int ret = 0;
+
+	pr_debug("Entered %s\n", __func__);
+
+	/* return if this is a bufferless transfer e.g.
+	 * codec <--> BT codec or GSM modem -- lg FIXME */
+	if (!prtd->params)
+		return 0;
+
+	/* flush the DMA channel */
+	dmaengine_terminate_all(prtd->params->ch);
+
+	prtd->dma_loaded = 0;
+	prtd->dma_pos = prtd->dma_start;
+
+	/* enqueue dma buffers */
+	dma_enqueue(substream);
+
+	return ret;
+}
+
+static int dma_trigger(struct snd_pcm_substream *substream, int cmd)
+{
+	struct runtime_data *prtd = substream->runtime->private_data;
+	int ret = 0;
+
+	pr_debug("Entered %s\n", __func__);
+
+	spin_lock(&prtd->lock);
+
+	switch (cmd) {
+	case SNDRV_PCM_TRIGGER_START:
+		prtd->state |= ST_RUNNING;
+		dma_async_issue_pending(prtd->params->ch);
+		break;
+
+	case SNDRV_PCM_TRIGGER_STOP:
+		prtd->state &= ~ST_RUNNING;
+		dmaengine_terminate_all(prtd->params->ch);
+		break;
+
+	default:
+		ret = -EINVAL;
+		break;
+	}
+
+	spin_unlock(&prtd->lock);
+
+	return ret;
+}
+#endif
 
 static snd_pcm_uframes_t
 dma_pointer(struct snd_pcm_substream *substream)
diff --git a/sound/soc/samsung/dma.h b/sound/soc/samsung/dma.h
index 189a7a6..6bd1857 100644
--- a/sound/soc/samsung/dma.h
+++ b/sound/soc/samsung/dma.h
@@ -12,13 +12,24 @@
 #ifndef _S3C_AUDIO_H
 #define _S3C_AUDIO_H
 
+#ifdef CONFIG_SAMSUNG_DMADEV
+#include <mach/dma.h>
+#endif
+
 struct s3c_dma_params {
+#ifdef CONFIG_SAMSUNG_DMADEV
 	struct s3c2410_dma_client *client;	/* stream identifier */
+	unsigned ch;
+	struct samsung_dma_ops *ops;
+#else
+	struct s3c2410_dma_client {
+		char *name;			/* unused */
+	} *client;
+	struct dma_chan *ch;
+#endif
 	int channel;				/* Channel ID */
 	dma_addr_t dma_addr;
 	int dma_size;			/* Size of the DMA transfer */
-	unsigned ch;
-	struct samsung_dma_ops *ops;
 	char *ch_name;
 };
 
diff --git a/sound/soc/samsung/i2s.c b/sound/soc/samsung/i2s.c
index d7231e3..61f2622 100644
--- a/sound/soc/samsung/i2s.c
+++ b/sound/soc/samsung/i2s.c
@@ -22,8 +22,6 @@
 #include <sound/soc.h>
 #include <sound/pcm_params.h>
 
-#include <mach/dma.h>
-
 #include <linux/platform_data/asoc-s3c.h>
 
 #include "dma.h"
diff --git a/sound/soc/samsung/pcm.c b/sound/soc/samsung/pcm.c
index 13bab79..b5f267c 100644
--- a/sound/soc/samsung/pcm.c
+++ b/sound/soc/samsung/pcm.c
@@ -20,7 +20,6 @@
 #include <sound/pcm_params.h>
 
 #include <linux/platform_data/asoc-s3c.h>
-#include <mach/dma.h>
 
 #include "dma.h"
 #include "pcm.h"
diff --git a/sound/soc/samsung/spdif.c b/sound/soc/samsung/spdif.c
index 5008e5b..ee792aa 100644
--- a/sound/soc/samsung/spdif.c
+++ b/sound/soc/samsung/spdif.c
@@ -18,7 +18,6 @@
 #include <sound/pcm_params.h>
 
 #include <linux/platform_data/asoc-s3c.h>
-#include <mach/dma.h>
 
 #include "dma.h"
 #include "spdif.h"
-- 
1.8.1.2



From arnd at arndb.de  Wed Apr 10 20:04:48 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 11 Apr 2013 02:04:48 +0200
Subject: [PATCH 06/30] tty: serial/samsung: make register definitions global
In-Reply-To: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
References: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
Message-ID: <1365638712-1028578-7-git-send-email-arnd@arndb.de>

The registers for the Samsung S3C serial port are currently defined in
the platform specific arch/arm/plat-samsung/include/plat/regs-serial.h
file, which is not visible to multiplatform capable drivers.

Unfortunately, it is not possible to move the file into a more local
place as we should normally try to, because the same registers
may be used in one of four places:

* In the driver itself
* In platform-independent ARM code for early debug output
* In platform_data definitions
* In the Samsung platform power management code

I have also found no way to logically split out a platform_data
file, other than possibly move everything into
include/linux/platform_data, which also felt wrong. The only
part of this file that makes sense to keep specific to the s3c24xx
platform are the virtual and physical addresses defined here,
which are needed in no other location.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Cc: linux-serial at vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
---
 arch/arm/mach-s3c24xx/clock-s3c2440.c            |   5 +
 arch/arm/mach-s3c24xx/common.c                   |   5 +
 arch/arm/plat-samsung/include/plat/regs-serial.h | 282 +----------------------
 drivers/tty/serial/samsung.c                     |   6 +-
 include/linux/serial_s3c.h                       | 260 +++++++++++++++++++++
 5 files changed, 274 insertions(+), 284 deletions(-)
 create mode 100644 include/linux/serial_s3c.h

diff --git a/arch/arm/mach-s3c24xx/clock-s3c2440.c b/arch/arm/mach-s3c24xx/clock-s3c2440.c
index 04b87ec..1069b56 100644
--- a/arch/arm/mach-s3c24xx/clock-s3c2440.c
+++ b/arch/arm/mach-s3c24xx/clock-s3c2440.c
@@ -123,6 +123,11 @@ static struct clk s3c2440_clk_ac97 = {
 	.ctrlbit	= S3C2440_CLKCON_AC97,
 };
 
+#define S3C24XX_VA_UART0      (S3C_VA_UART)
+#define S3C24XX_VA_UART1      (S3C_VA_UART + 0x4000 )
+#define S3C24XX_VA_UART2      (S3C_VA_UART + 0x8000 )
+#define S3C24XX_VA_UART3      (S3C_VA_UART + 0xC000 )
+
 static unsigned long  s3c2440_fclk_n_getrate(struct clk *clk)
 {
 	unsigned long ucon0, ucon1, ucon2, divisor;
diff --git a/arch/arm/mach-s3c24xx/common.c b/arch/arm/mach-s3c24xx/common.c
index d97533d..c157103 100644
--- a/arch/arm/mach-s3c24xx/common.c
+++ b/arch/arm/mach-s3c24xx/common.c
@@ -236,6 +236,11 @@ void __init s3c24xx_init_io(struct map_desc *mach_desc, int size)
 
 /* Serial port registrations */
 
+#define S3C2410_PA_UART0      (S3C24XX_PA_UART)
+#define S3C2410_PA_UART1      (S3C24XX_PA_UART + 0x4000 )
+#define S3C2410_PA_UART2      (S3C24XX_PA_UART + 0x8000 )
+#define S3C2443_PA_UART3      (S3C24XX_PA_UART + 0xC000 )
+
 static struct resource s3c2410_uart0_resource[] = {
 	[0] = DEFINE_RES_MEM(S3C2410_PA_UART0, SZ_16K),
 	[1] = DEFINE_RES_NAMED(IRQ_S3CUART_RX0, \
diff --git a/arch/arm/plat-samsung/include/plat/regs-serial.h b/arch/arm/plat-samsung/include/plat/regs-serial.h
index 29c26a8..f05f2af 100644
--- a/arch/arm/plat-samsung/include/plat/regs-serial.h
+++ b/arch/arm/plat-samsung/include/plat/regs-serial.h
@@ -1,281 +1 @@
-/* arch/arm/plat-samsung/include/plat/regs-serial.h
- *
- *  From linux/include/asm-arm/hardware/serial_s3c2410.h
- *
- *  Internal header file for Samsung S3C2410 serial ports (UART0-2)
- *
- *  Copyright (C) 2002 Shane Nay (shane at minirl.com)
- *
- *  Additional defines, Copyright 2003 Simtec Electronics (linux at simtec.co.uk)
- *
- *  Adapted from:
- *
- *  Internal header file for MX1ADS serial ports (UART1 & 2)
- *
- *  Copyright (C) 2002 Shane Nay (shane at minirl.com)
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
-*/
-
-#ifndef __ASM_ARM_REGS_SERIAL_H
-#define __ASM_ARM_REGS_SERIAL_H
-
-#define S3C24XX_VA_UART0      (S3C_VA_UART)
-#define S3C24XX_VA_UART1      (S3C_VA_UART + 0x4000 )
-#define S3C24XX_VA_UART2      (S3C_VA_UART + 0x8000 )
-#define S3C24XX_VA_UART3      (S3C_VA_UART + 0xC000 )
-
-#define S3C2410_PA_UART0      (S3C24XX_PA_UART)
-#define S3C2410_PA_UART1      (S3C24XX_PA_UART + 0x4000 )
-#define S3C2410_PA_UART2      (S3C24XX_PA_UART + 0x8000 )
-#define S3C2443_PA_UART3      (S3C24XX_PA_UART + 0xC000 )
-
-#define S3C2410_URXH	  (0x24)
-#define S3C2410_UTXH	  (0x20)
-#define S3C2410_ULCON	  (0x00)
-#define S3C2410_UCON	  (0x04)
-#define S3C2410_UFCON	  (0x08)
-#define S3C2410_UMCON	  (0x0C)
-#define S3C2410_UBRDIV	  (0x28)
-#define S3C2410_UTRSTAT	  (0x10)
-#define S3C2410_UERSTAT	  (0x14)
-#define S3C2410_UFSTAT	  (0x18)
-#define S3C2410_UMSTAT	  (0x1C)
-
-#define S3C2410_LCON_CFGMASK	  ((0xF<<3)|(0x3))
-
-#define S3C2410_LCON_CS5	  (0x0)
-#define S3C2410_LCON_CS6	  (0x1)
-#define S3C2410_LCON_CS7	  (0x2)
-#define S3C2410_LCON_CS8	  (0x3)
-#define S3C2410_LCON_CSMASK	  (0x3)
-
-#define S3C2410_LCON_PNONE	  (0x0)
-#define S3C2410_LCON_PEVEN	  (0x5 << 3)
-#define S3C2410_LCON_PODD	  (0x4 << 3)
-#define S3C2410_LCON_PMASK	  (0x7 << 3)
-
-#define S3C2410_LCON_STOPB	  (1<<2)
-#define S3C2410_LCON_IRM          (1<<6)
-
-#define S3C2440_UCON_CLKMASK	  (3<<10)
-#define S3C2440_UCON_CLKSHIFT	  (10)
-#define S3C2440_UCON_PCLK	  (0<<10)
-#define S3C2440_UCON_UCLK	  (1<<10)
-#define S3C2440_UCON_PCLK2	  (2<<10)
-#define S3C2440_UCON_FCLK	  (3<<10)
-#define S3C2443_UCON_EPLL	  (3<<10)
-
-#define S3C6400_UCON_CLKMASK	(3<<10)
-#define S3C6400_UCON_CLKSHIFT	(10)
-#define S3C6400_UCON_PCLK	(0<<10)
-#define S3C6400_UCON_PCLK2	(2<<10)
-#define S3C6400_UCON_UCLK0	(1<<10)
-#define S3C6400_UCON_UCLK1	(3<<10)
-
-#define S3C2440_UCON2_FCLK_EN	  (1<<15)
-#define S3C2440_UCON0_DIVMASK	  (15 << 12)
-#define S3C2440_UCON1_DIVMASK	  (15 << 12)
-#define S3C2440_UCON2_DIVMASK	  (7 << 12)
-#define S3C2440_UCON_DIVSHIFT	  (12)
-
-#define S3C2412_UCON_CLKMASK	(3<<10)
-#define S3C2412_UCON_CLKSHIFT	(10)
-#define S3C2412_UCON_UCLK	(1<<10)
-#define S3C2412_UCON_USYSCLK	(3<<10)
-#define S3C2412_UCON_PCLK	(0<<10)
-#define S3C2412_UCON_PCLK2	(2<<10)
-
-#define S3C2410_UCON_CLKMASK	(1 << 10)
-#define S3C2410_UCON_CLKSHIFT	(10)
-#define S3C2410_UCON_UCLK	  (1<<10)
-#define S3C2410_UCON_SBREAK	  (1<<4)
-
-#define S3C2410_UCON_TXILEVEL	  (1<<9)
-#define S3C2410_UCON_RXILEVEL	  (1<<8)
-#define S3C2410_UCON_TXIRQMODE	  (1<<2)
-#define S3C2410_UCON_RXIRQMODE	  (1<<0)
-#define S3C2410_UCON_RXFIFO_TOI	  (1<<7)
-#define S3C2443_UCON_RXERR_IRQEN  (1<<6)
-#define S3C2443_UCON_LOOPBACK	  (1<<5)
-
-#define S3C2410_UCON_DEFAULT	  (S3C2410_UCON_TXILEVEL  | \
-				   S3C2410_UCON_RXILEVEL  | \
-				   S3C2410_UCON_TXIRQMODE | \
-				   S3C2410_UCON_RXIRQMODE | \
-				   S3C2410_UCON_RXFIFO_TOI)
-
-#define S3C2410_UFCON_FIFOMODE	  (1<<0)
-#define S3C2410_UFCON_TXTRIG0	  (0<<6)
-#define S3C2410_UFCON_RXTRIG8	  (1<<4)
-#define S3C2410_UFCON_RXTRIG12	  (2<<4)
-
-/* S3C2440 FIFO trigger levels */
-#define S3C2440_UFCON_RXTRIG1	  (0<<4)
-#define S3C2440_UFCON_RXTRIG8	  (1<<4)
-#define S3C2440_UFCON_RXTRIG16	  (2<<4)
-#define S3C2440_UFCON_RXTRIG32	  (3<<4)
-
-#define S3C2440_UFCON_TXTRIG0	  (0<<6)
-#define S3C2440_UFCON_TXTRIG16	  (1<<6)
-#define S3C2440_UFCON_TXTRIG32	  (2<<6)
-#define S3C2440_UFCON_TXTRIG48	  (3<<6)
-
-#define S3C2410_UFCON_RESETBOTH	  (3<<1)
-#define S3C2410_UFCON_RESETTX	  (1<<2)
-#define S3C2410_UFCON_RESETRX	  (1<<1)
-
-#define S3C2410_UFCON_DEFAULT	  (S3C2410_UFCON_FIFOMODE | \
-				   S3C2410_UFCON_TXTRIG0  | \
-				   S3C2410_UFCON_RXTRIG8 )
-
-#define	S3C2410_UMCOM_AFC	  (1<<4)
-#define	S3C2410_UMCOM_RTS_LOW	  (1<<0)
-
-#define S3C2412_UMCON_AFC_63	(0<<5)		/* same as s3c2443 */
-#define S3C2412_UMCON_AFC_56	(1<<5)
-#define S3C2412_UMCON_AFC_48	(2<<5)
-#define S3C2412_UMCON_AFC_40	(3<<5)
-#define S3C2412_UMCON_AFC_32	(4<<5)
-#define S3C2412_UMCON_AFC_24	(5<<5)
-#define S3C2412_UMCON_AFC_16	(6<<5)
-#define S3C2412_UMCON_AFC_8	(7<<5)
-
-#define S3C2410_UFSTAT_TXFULL	  (1<<9)
-#define S3C2410_UFSTAT_RXFULL	  (1<<8)
-#define S3C2410_UFSTAT_TXMASK	  (15<<4)
-#define S3C2410_UFSTAT_TXSHIFT	  (4)
-#define S3C2410_UFSTAT_RXMASK	  (15<<0)
-#define S3C2410_UFSTAT_RXSHIFT	  (0)
-
-/* UFSTAT S3C2443 same as S3C2440 */
-#define S3C2440_UFSTAT_TXFULL	  (1<<14)
-#define S3C2440_UFSTAT_RXFULL	  (1<<6)
-#define S3C2440_UFSTAT_TXSHIFT	  (8)
-#define S3C2440_UFSTAT_RXSHIFT	  (0)
-#define S3C2440_UFSTAT_TXMASK	  (63<<8)
-#define S3C2440_UFSTAT_RXMASK	  (63)
-
-#define S3C2410_UTRSTAT_TXE	  (1<<2)
-#define S3C2410_UTRSTAT_TXFE	  (1<<1)
-#define S3C2410_UTRSTAT_RXDR	  (1<<0)
-
-#define S3C2410_UERSTAT_OVERRUN	  (1<<0)
-#define S3C2410_UERSTAT_FRAME	  (1<<2)
-#define S3C2410_UERSTAT_BREAK	  (1<<3)
-#define S3C2443_UERSTAT_PARITY	  (1<<1)
-
-#define S3C2410_UERSTAT_ANY	  (S3C2410_UERSTAT_OVERRUN | \
-				   S3C2410_UERSTAT_FRAME | \
-				   S3C2410_UERSTAT_BREAK)
-
-#define S3C2410_UMSTAT_CTS	  (1<<0)
-#define S3C2410_UMSTAT_DeltaCTS	  (1<<2)
-
-#define S3C2443_DIVSLOT		  (0x2C)
-
-/* S3C64XX interrupt registers. */
-#define S3C64XX_UINTP		0x30
-#define S3C64XX_UINTSP		0x34
-#define S3C64XX_UINTM		0x38
-
-#define S3C64XX_UINTM_RXD	(0)
-#define S3C64XX_UINTM_TXD	(2)
-#define S3C64XX_UINTM_RXD_MSK	(1 << S3C64XX_UINTM_RXD)
-#define S3C64XX_UINTM_TXD_MSK	(1 << S3C64XX_UINTM_TXD)
-
-/* Following are specific to S5PV210 */
-#define S5PV210_UCON_CLKMASK	(1<<10)
-#define S5PV210_UCON_CLKSHIFT	(10)
-#define S5PV210_UCON_PCLK	(0<<10)
-#define S5PV210_UCON_UCLK	(1<<10)
-
-#define S5PV210_UFCON_TXTRIG0	(0<<8)
-#define S5PV210_UFCON_TXTRIG4	(1<<8)
-#define S5PV210_UFCON_TXTRIG8	(2<<8)
-#define S5PV210_UFCON_TXTRIG16	(3<<8)
-#define S5PV210_UFCON_TXTRIG32	(4<<8)
-#define S5PV210_UFCON_TXTRIG64	(5<<8)
-#define S5PV210_UFCON_TXTRIG128 (6<<8)
-#define S5PV210_UFCON_TXTRIG256 (7<<8)
-
-#define S5PV210_UFCON_RXTRIG1	(0<<4)
-#define S5PV210_UFCON_RXTRIG4	(1<<4)
-#define S5PV210_UFCON_RXTRIG8	(2<<4)
-#define S5PV210_UFCON_RXTRIG16	(3<<4)
-#define S5PV210_UFCON_RXTRIG32	(4<<4)
-#define S5PV210_UFCON_RXTRIG64	(5<<4)
-#define S5PV210_UFCON_RXTRIG128	(6<<4)
-#define S5PV210_UFCON_RXTRIG256	(7<<4)
-
-#define S5PV210_UFSTAT_TXFULL	(1<<24)
-#define S5PV210_UFSTAT_RXFULL	(1<<8)
-#define S5PV210_UFSTAT_TXMASK	(255<<16)
-#define S5PV210_UFSTAT_TXSHIFT	(16)
-#define S5PV210_UFSTAT_RXMASK	(255<<0)
-#define S5PV210_UFSTAT_RXSHIFT	(0)
-
-#define S3C2410_UCON_CLKSEL0	(1 << 0)
-#define S3C2410_UCON_CLKSEL1	(1 << 1)
-#define S3C2410_UCON_CLKSEL2	(1 << 2)
-#define S3C2410_UCON_CLKSEL3	(1 << 3)
-
-/* Default values for s5pv210 UCON and UFCON uart registers */
-#define S5PV210_UCON_DEFAULT	(S3C2410_UCON_TXILEVEL |	\
-				 S3C2410_UCON_RXILEVEL |	\
-				 S3C2410_UCON_TXIRQMODE |	\
-				 S3C2410_UCON_RXIRQMODE |	\
-				 S3C2410_UCON_RXFIFO_TOI |	\
-				 S3C2443_UCON_RXERR_IRQEN)
-
-#define S5PV210_UFCON_DEFAULT	(S3C2410_UFCON_FIFOMODE |	\
-				 S5PV210_UFCON_TXTRIG4 |	\
-				 S5PV210_UFCON_RXTRIG4)
-
-#ifndef __ASSEMBLY__
-
-/* configuration structure for per-machine configurations for the
- * serial port
- *
- * the pointer is setup by the machine specific initialisation from the
- * arch/arm/mach-s3c2410/ directory.
-*/
-
-struct s3c2410_uartcfg {
-	unsigned char	   hwport;	 /* hardware port number */
-	unsigned char	   unused;
-	unsigned short	   flags;
-	upf_t		   uart_flags;	 /* default uart flags */
-	unsigned int	   clk_sel;
-
-	unsigned int	   has_fracval;
-
-	unsigned long	   ucon;	 /* value of ucon for port */
-	unsigned long	   ulcon;	 /* value of ulcon for port */
-	unsigned long	   ufcon;	 /* value of ufcon for port */
-};
-
-/* s3c24xx_uart_devs
- *
- * this is exported from the core as we cannot use driver_register(),
- * or platform_add_device() before the console_initcall()
-*/
-
-extern struct platform_device *s3c24xx_uart_devs[4];
-
-#endif /* __ASSEMBLY__ */
-
-#endif /* __ASM_ARM_REGS_SERIAL_H */
-
+#include <linux/serial_s3c.h>
diff --git a/drivers/tty/serial/samsung.c b/drivers/tty/serial/samsung.c
index 603f3f3..729a60d 100644
--- a/drivers/tty/serial/samsung.c
+++ b/drivers/tty/serial/samsung.c
@@ -39,6 +39,7 @@
 #include <linux/tty_flip.h>
 #include <linux/serial_core.h>
 #include <linux/serial.h>
+#include <linux/serial_s3c.h>
 #include <linux/delay.h>
 #include <linux/clk.h>
 #include <linux/cpufreq.h>
@@ -46,10 +47,9 @@
 
 #include <asm/irq.h>
 
-#include <mach/hardware.h>
-
-#include <plat/regs-serial.h>
+#ifdef CONFIG_SAMSUNG_CLOCK
 #include <plat/clock.h>
+#endif
 
 #include "samsung.h"
 
diff --git a/include/linux/serial_s3c.h b/include/linux/serial_s3c.h
new file mode 100644
index 0000000..907d9d1
--- /dev/null
+++ b/include/linux/serial_s3c.h
@@ -0,0 +1,260 @@
+/*
+ *  Internal header file for Samsung S3C2410 serial ports (UART0-2)
+ *
+ *  Copyright (C) 2002 Shane Nay (shane at minirl.com)
+ *
+ *  Additional defines, Copyright 2003 Simtec Electronics (linux at simtec.co.uk)
+ *
+ *  Adapted from:
+ *
+ *  Internal header file for MX1ADS serial ports (UART1 & 2)
+ *
+ *  Copyright (C) 2002 Shane Nay (shane at minirl.com)
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+*/
+
+#ifndef __ASM_ARM_REGS_SERIAL_H
+#define __ASM_ARM_REGS_SERIAL_H
+
+#define S3C2410_URXH	  (0x24)
+#define S3C2410_UTXH	  (0x20)
+#define S3C2410_ULCON	  (0x00)
+#define S3C2410_UCON	  (0x04)
+#define S3C2410_UFCON	  (0x08)
+#define S3C2410_UMCON	  (0x0C)
+#define S3C2410_UBRDIV	  (0x28)
+#define S3C2410_UTRSTAT	  (0x10)
+#define S3C2410_UERSTAT	  (0x14)
+#define S3C2410_UFSTAT	  (0x18)
+#define S3C2410_UMSTAT	  (0x1C)
+
+#define S3C2410_LCON_CFGMASK	  ((0xF<<3)|(0x3))
+
+#define S3C2410_LCON_CS5	  (0x0)
+#define S3C2410_LCON_CS6	  (0x1)
+#define S3C2410_LCON_CS7	  (0x2)
+#define S3C2410_LCON_CS8	  (0x3)
+#define S3C2410_LCON_CSMASK	  (0x3)
+
+#define S3C2410_LCON_PNONE	  (0x0)
+#define S3C2410_LCON_PEVEN	  (0x5 << 3)
+#define S3C2410_LCON_PODD	  (0x4 << 3)
+#define S3C2410_LCON_PMASK	  (0x7 << 3)
+
+#define S3C2410_LCON_STOPB	  (1<<2)
+#define S3C2410_LCON_IRM          (1<<6)
+
+#define S3C2440_UCON_CLKMASK	  (3<<10)
+#define S3C2440_UCON_CLKSHIFT	  (10)
+#define S3C2440_UCON_PCLK	  (0<<10)
+#define S3C2440_UCON_UCLK	  (1<<10)
+#define S3C2440_UCON_PCLK2	  (2<<10)
+#define S3C2440_UCON_FCLK	  (3<<10)
+#define S3C2443_UCON_EPLL	  (3<<10)
+
+#define S3C6400_UCON_CLKMASK	(3<<10)
+#define S3C6400_UCON_CLKSHIFT	(10)
+#define S3C6400_UCON_PCLK	(0<<10)
+#define S3C6400_UCON_PCLK2	(2<<10)
+#define S3C6400_UCON_UCLK0	(1<<10)
+#define S3C6400_UCON_UCLK1	(3<<10)
+
+#define S3C2440_UCON2_FCLK_EN	  (1<<15)
+#define S3C2440_UCON0_DIVMASK	  (15 << 12)
+#define S3C2440_UCON1_DIVMASK	  (15 << 12)
+#define S3C2440_UCON2_DIVMASK	  (7 << 12)
+#define S3C2440_UCON_DIVSHIFT	  (12)
+
+#define S3C2412_UCON_CLKMASK	(3<<10)
+#define S3C2412_UCON_CLKSHIFT	(10)
+#define S3C2412_UCON_UCLK	(1<<10)
+#define S3C2412_UCON_USYSCLK	(3<<10)
+#define S3C2412_UCON_PCLK	(0<<10)
+#define S3C2412_UCON_PCLK2	(2<<10)
+
+#define S3C2410_UCON_CLKMASK	(1 << 10)
+#define S3C2410_UCON_CLKSHIFT	(10)
+#define S3C2410_UCON_UCLK	  (1<<10)
+#define S3C2410_UCON_SBREAK	  (1<<4)
+
+#define S3C2410_UCON_TXILEVEL	  (1<<9)
+#define S3C2410_UCON_RXILEVEL	  (1<<8)
+#define S3C2410_UCON_TXIRQMODE	  (1<<2)
+#define S3C2410_UCON_RXIRQMODE	  (1<<0)
+#define S3C2410_UCON_RXFIFO_TOI	  (1<<7)
+#define S3C2443_UCON_RXERR_IRQEN  (1<<6)
+#define S3C2443_UCON_LOOPBACK	  (1<<5)
+
+#define S3C2410_UCON_DEFAULT	  (S3C2410_UCON_TXILEVEL  | \
+				   S3C2410_UCON_RXILEVEL  | \
+				   S3C2410_UCON_TXIRQMODE | \
+				   S3C2410_UCON_RXIRQMODE | \
+				   S3C2410_UCON_RXFIFO_TOI)
+
+#define S3C2410_UFCON_FIFOMODE	  (1<<0)
+#define S3C2410_UFCON_TXTRIG0	  (0<<6)
+#define S3C2410_UFCON_RXTRIG8	  (1<<4)
+#define S3C2410_UFCON_RXTRIG12	  (2<<4)
+
+/* S3C2440 FIFO trigger levels */
+#define S3C2440_UFCON_RXTRIG1	  (0<<4)
+#define S3C2440_UFCON_RXTRIG8	  (1<<4)
+#define S3C2440_UFCON_RXTRIG16	  (2<<4)
+#define S3C2440_UFCON_RXTRIG32	  (3<<4)
+
+#define S3C2440_UFCON_TXTRIG0	  (0<<6)
+#define S3C2440_UFCON_TXTRIG16	  (1<<6)
+#define S3C2440_UFCON_TXTRIG32	  (2<<6)
+#define S3C2440_UFCON_TXTRIG48	  (3<<6)
+
+#define S3C2410_UFCON_RESETBOTH	  (3<<1)
+#define S3C2410_UFCON_RESETTX	  (1<<2)
+#define S3C2410_UFCON_RESETRX	  (1<<1)
+
+#define S3C2410_UFCON_DEFAULT	  (S3C2410_UFCON_FIFOMODE | \
+				   S3C2410_UFCON_TXTRIG0  | \
+				   S3C2410_UFCON_RXTRIG8 )
+
+#define	S3C2410_UMCOM_AFC	  (1<<4)
+#define	S3C2410_UMCOM_RTS_LOW	  (1<<0)
+
+#define S3C2412_UMCON_AFC_63	(0<<5)		/* same as s3c2443 */
+#define S3C2412_UMCON_AFC_56	(1<<5)
+#define S3C2412_UMCON_AFC_48	(2<<5)
+#define S3C2412_UMCON_AFC_40	(3<<5)
+#define S3C2412_UMCON_AFC_32	(4<<5)
+#define S3C2412_UMCON_AFC_24	(5<<5)
+#define S3C2412_UMCON_AFC_16	(6<<5)
+#define S3C2412_UMCON_AFC_8	(7<<5)
+
+#define S3C2410_UFSTAT_TXFULL	  (1<<9)
+#define S3C2410_UFSTAT_RXFULL	  (1<<8)
+#define S3C2410_UFSTAT_TXMASK	  (15<<4)
+#define S3C2410_UFSTAT_TXSHIFT	  (4)
+#define S3C2410_UFSTAT_RXMASK	  (15<<0)
+#define S3C2410_UFSTAT_RXSHIFT	  (0)
+
+/* UFSTAT S3C2443 same as S3C2440 */
+#define S3C2440_UFSTAT_TXFULL	  (1<<14)
+#define S3C2440_UFSTAT_RXFULL	  (1<<6)
+#define S3C2440_UFSTAT_TXSHIFT	  (8)
+#define S3C2440_UFSTAT_RXSHIFT	  (0)
+#define S3C2440_UFSTAT_TXMASK	  (63<<8)
+#define S3C2440_UFSTAT_RXMASK	  (63)
+
+#define S3C2410_UTRSTAT_TXE	  (1<<2)
+#define S3C2410_UTRSTAT_TXFE	  (1<<1)
+#define S3C2410_UTRSTAT_RXDR	  (1<<0)
+
+#define S3C2410_UERSTAT_OVERRUN	  (1<<0)
+#define S3C2410_UERSTAT_FRAME	  (1<<2)
+#define S3C2410_UERSTAT_BREAK	  (1<<3)
+#define S3C2443_UERSTAT_PARITY	  (1<<1)
+
+#define S3C2410_UERSTAT_ANY	  (S3C2410_UERSTAT_OVERRUN | \
+				   S3C2410_UERSTAT_FRAME | \
+				   S3C2410_UERSTAT_BREAK)
+
+#define S3C2410_UMSTAT_CTS	  (1<<0)
+#define S3C2410_UMSTAT_DeltaCTS	  (1<<2)
+
+#define S3C2443_DIVSLOT		  (0x2C)
+
+/* S3C64XX interrupt registers. */
+#define S3C64XX_UINTP		0x30
+#define S3C64XX_UINTSP		0x34
+#define S3C64XX_UINTM		0x38
+
+#define S3C64XX_UINTM_RXD	(0)
+#define S3C64XX_UINTM_TXD	(2)
+#define S3C64XX_UINTM_RXD_MSK	(1 << S3C64XX_UINTM_RXD)
+#define S3C64XX_UINTM_TXD_MSK	(1 << S3C64XX_UINTM_TXD)
+
+/* Following are specific to S5PV210 */
+#define S5PV210_UCON_CLKMASK	(1<<10)
+#define S5PV210_UCON_CLKSHIFT	(10)
+#define S5PV210_UCON_PCLK	(0<<10)
+#define S5PV210_UCON_UCLK	(1<<10)
+
+#define S5PV210_UFCON_TXTRIG0	(0<<8)
+#define S5PV210_UFCON_TXTRIG4	(1<<8)
+#define S5PV210_UFCON_TXTRIG8	(2<<8)
+#define S5PV210_UFCON_TXTRIG16	(3<<8)
+#define S5PV210_UFCON_TXTRIG32	(4<<8)
+#define S5PV210_UFCON_TXTRIG64	(5<<8)
+#define S5PV210_UFCON_TXTRIG128 (6<<8)
+#define S5PV210_UFCON_TXTRIG256 (7<<8)
+
+#define S5PV210_UFCON_RXTRIG1	(0<<4)
+#define S5PV210_UFCON_RXTRIG4	(1<<4)
+#define S5PV210_UFCON_RXTRIG8	(2<<4)
+#define S5PV210_UFCON_RXTRIG16	(3<<4)
+#define S5PV210_UFCON_RXTRIG32	(4<<4)
+#define S5PV210_UFCON_RXTRIG64	(5<<4)
+#define S5PV210_UFCON_RXTRIG128	(6<<4)
+#define S5PV210_UFCON_RXTRIG256	(7<<4)
+
+#define S5PV210_UFSTAT_TXFULL	(1<<24)
+#define S5PV210_UFSTAT_RXFULL	(1<<8)
+#define S5PV210_UFSTAT_TXMASK	(255<<16)
+#define S5PV210_UFSTAT_TXSHIFT	(16)
+#define S5PV210_UFSTAT_RXMASK	(255<<0)
+#define S5PV210_UFSTAT_RXSHIFT	(0)
+
+#define S3C2410_UCON_CLKSEL0	(1 << 0)
+#define S3C2410_UCON_CLKSEL1	(1 << 1)
+#define S3C2410_UCON_CLKSEL2	(1 << 2)
+#define S3C2410_UCON_CLKSEL3	(1 << 3)
+
+/* Default values for s5pv210 UCON and UFCON uart registers */
+#define S5PV210_UCON_DEFAULT	(S3C2410_UCON_TXILEVEL |	\
+				 S3C2410_UCON_RXILEVEL |	\
+				 S3C2410_UCON_TXIRQMODE |	\
+				 S3C2410_UCON_RXIRQMODE |	\
+				 S3C2410_UCON_RXFIFO_TOI |	\
+				 S3C2443_UCON_RXERR_IRQEN)
+
+#define S5PV210_UFCON_DEFAULT	(S3C2410_UFCON_FIFOMODE |	\
+				 S5PV210_UFCON_TXTRIG4 |	\
+				 S5PV210_UFCON_RXTRIG4)
+
+#ifndef __ASSEMBLY__
+
+/* configuration structure for per-machine configurations for the
+ * serial port
+ *
+ * the pointer is setup by the machine specific initialisation from the
+ * arch/arm/mach-s3c2410/ directory.
+*/
+
+struct s3c2410_uartcfg {
+	unsigned char	   hwport;	 /* hardware port number */
+	unsigned char	   unused;
+	unsigned short	   flags;
+	upf_t		   uart_flags;	 /* default uart flags */
+	unsigned int	   clk_sel;
+
+	unsigned int	   has_fracval;
+
+	unsigned long	   ucon;	 /* value of ucon for port */
+	unsigned long	   ulcon;	 /* value of ulcon for port */
+	unsigned long	   ufcon;	 /* value of ufcon for port */
+};
+
+#endif /* __ASSEMBLY__ */
+
+#endif /* __ASM_ARM_REGS_SERIAL_H */
+
-- 
1.8.1.2



From arnd at arndb.de  Wed Apr 10 20:05:06 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 11 Apr 2013 02:05:06 +0200
Subject: [PATCH 24/30] clocksource: exynos_mct: remove platform header
 dependency
In-Reply-To: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
References: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
Message-ID: <1365638712-1028578-25-git-send-email-arnd@arndb.de>

For the non-DT case, the mct_init() function requires access
to a couple of platform specific constants, but cannot include
the header files in case we are building for multiplatform.

This changes the interface to the platform so we pass all
the necessary data as arguments to mct_init.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Cc: Thomas Gleixner <tglx at linutronix.de>
Cc: John Stultz <john.stultz at linaro.org>
---
 arch/arm/mach-exynos/common.c    |  2 +-
 arch/arm/mach-exynos/common.h    |  2 +-
 drivers/clocksource/exynos_mct.c | 21 ++++++---------------
 3 files changed, 8 insertions(+), 17 deletions(-)

diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
index 87b2e06..8e85d6c 100644
--- a/arch/arm/mach-exynos/common.c
+++ b/arch/arm/mach-exynos/common.c
@@ -448,7 +448,7 @@ void __init exynos_init_time(void)
 		exynos4_clk_init(NULL, !soc_is_exynos4210(), S5P_VA_CMU, readl(S5P_VA_CHIPID + 8) & 1);
 		exynos4_clk_register_fixed_ext(xxti_f, xusbxti_f);
 #endif
-		mct_init();
+		mct_init(S5P_VA_SYSTIMER, EXYNOS4_IRQ_MCT_G0, EXYNOS4_IRQ_MCT_L0, EXYNOS4_IRQ_MCT_L1);
 	}
 }
 
diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
index 9832e03..f426a5b 100644
--- a/arch/arm/mach-exynos/common.h
+++ b/arch/arm/mach-exynos/common.h
@@ -14,7 +14,7 @@
 
 #include <linux/of.h>
 
-extern void mct_init(void);
+void mct_init(void __iomem *base, int irq_g0, int irq_l0, int irq_l1);
 void exynos_init_time(void);
 extern unsigned long xxti_f, xusbxti_f;
 
diff --git a/drivers/clocksource/exynos_mct.c b/drivers/clocksource/exynos_mct.c
index 020ba55..88ff404 100644
--- a/drivers/clocksource/exynos_mct.c
+++ b/drivers/clocksource/exynos_mct.c
@@ -26,11 +26,6 @@
 
 #include <asm/arch_timer.h>
 #include <asm/localtimer.h>
-
-#include <plat/cpu.h>
-
-#include <mach/map.h>
-#include <mach/irqs.h>
 #include <asm/mach/time.h>
 
 #define EXYNOS4_MCTREG(x)		(x)
@@ -511,18 +506,14 @@ static void __init exynos4_timer_resources(struct device_node *np, void __iomem
 #endif /* CONFIG_LOCAL_TIMERS */
 }
 
-void __init mct_init(void)
+void __init mct_init(void __iomem *base, int irq_g0, int irq_l0, int irq_l1)
 {
-	if (soc_is_exynos4210()) {
-		mct_irqs[MCT_G0_IRQ] = EXYNOS4_IRQ_MCT_G0;
-		mct_irqs[MCT_L0_IRQ] = EXYNOS4_IRQ_MCT_L0;
-		mct_irqs[MCT_L1_IRQ] = EXYNOS4_IRQ_MCT_L1;
-		mct_int_type = MCT_INT_SPI;
-	} else {
-		panic("unable to determine mct controller type\n");
-	}
+	mct_irqs[MCT_G0_IRQ] = irq_g0;
+	mct_irqs[MCT_L0_IRQ] = irq_l0;
+	mct_irqs[MCT_L1_IRQ] = irq_l1;
+	mct_int_type = MCT_INT_SPI;
 
-	exynos4_timer_resources(NULL, S5P_VA_SYSTIMER);
+	exynos4_timer_resources(NULL, base);
 	exynos4_clocksource_init();
 	exynos4_clockevent_init();
 }
-- 
1.8.1.2



From arnd at arndb.de  Wed Apr 10 20:05:12 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 11 Apr 2013 02:05:12 +0200
Subject: [PATCH 30/30] ARM: exynos: enable multiplatform support
In-Reply-To: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
References: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
Message-ID: <1365638712-1028578-31-git-send-email-arnd@arndb.de>

This makes it possible to enable the exynos platform as part of a
multiplatform kernel, in addition to keeping the single-platform
exynos support.

The multiplatform variant has a number of limitations at the moment:

* It only supports DT-enabled machines. This is not a problem in
  the long run, as non-DT machines for exynos are going away.
  The main problem here is that the gpio code and the exynos_eint
  irqchip are not multiplatform capable but still required for
  ATAGS based boot.
* The watchdog driver is still missing a conversion.
* sparsemem and memory_holes are currently not supported in
  multiplatform.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 arch/arm/Kconfig                        | 10 +---------
 arch/arm/configs/exynos4_defconfig      |  2 +-
 arch/arm/mach-exynos/Kconfig            | 25 +++++++++++++++++++++----
 arch/arm/mach-exynos/Makefile           |  5 +++--
 arch/arm/mach-exynos/common.c           |  6 ++++++
 arch/arm/plat-samsung/Kconfig           |  7 ++++++-
 arch/arm/plat-samsung/Makefile          |  8 ++++++--
 arch/arm/plat-samsung/include/plat/pm.h |  5 +++++
 drivers/gpio/Makefile                   |  2 +-
 9 files changed, 50 insertions(+), 20 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index c451112..81185a5 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -775,19 +775,11 @@ config ARCH_S5PV210
 	help
 	  Samsung S5PV210/S5PC110 series based systems
 
-config ARCH_EXYNOS
+config ARCH_EXYNOS_SINGLE
 	bool "Samsung EXYNOS"
-	select ARCH_HAS_CPUFREQ
 	select ARCH_HAS_HOLES_MEMORYMODEL
 	select ARCH_SPARSEMEM_ENABLE
-	select CLKDEV_LOOKUP
-	select COMMON_CLK
-	select CPU_V7
-	select GENERIC_CLOCKEVENTS
-	select HAVE_CLK
-	select HAVE_S3C2410_I2C if I2C
 	select HAVE_S3C2410_WATCHDOG if WATCHDOG
-	select HAVE_S3C_RTC if RTC_CLASS
 	select NEED_MACH_GPIO_H
 	select NEED_MACH_MEMORY_H
 	help
diff --git a/arch/arm/configs/exynos4_defconfig b/arch/arm/configs/exynos4_defconfig
index bffe68e..ae90a0f 100644
--- a/arch/arm/configs/exynos4_defconfig
+++ b/arch/arm/configs/exynos4_defconfig
@@ -4,7 +4,7 @@ CONFIG_KALLSYMS_ALL=y
 CONFIG_MODULES=y
 CONFIG_MODULE_UNLOAD=y
 # CONFIG_BLK_DEV_BSG is not set
-CONFIG_ARCH_EXYNOS=y
+CONFIG_ARCH_EXYNOS_SINGLE=y
 CONFIG_S3C_LOWLEVEL_UART_PORT=1
 CONFIG_MACH_SMDKC210=y
 CONFIG_MACH_ARMLEX4210=y
diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index e815057..f19cf65 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -7,6 +7,20 @@
 
 # Configuration options for the EXYNOS4
 
+config ARCH_EXYNOS
+	bool "Samsung EXYNOS" if ARCH_MULTI_V7
+	default ARCH_EXYNOS_SINGLE
+	select ARCH_HAS_CPUFREQ
+	select CLKDEV_LOOKUP
+	select COMMON_CLK
+	select CPU_V7
+	select GENERIC_CLOCKEVENTS
+	select HAVE_CLK
+	select HAVE_S3C2410_I2C if I2C
+	select HAVE_S3C_RTC if RTC_CLASS
+	help
+	  Support for SAMSUNG's EXYNOS SoCs (EXYNOS4/5)
+
 if ARCH_EXYNOS
 
 menu "SAMSUNG EXYNOS SoCs Support"
@@ -20,6 +34,9 @@ config ARCH_EXYNOS4
 	help
 	  Samsung EXYNOS4 SoCs based systems
 
+config ARCH_EXYNOS4_SINGLE
+	def_bool ARCH_EXYNOS4 && ARCH_EXYNOS_SINGLE
+
 config ARCH_EXYNOS5
 	bool "SAMSUNG EXYNOS5"
 	select HAVE_ARM_SCU if SMP
@@ -37,7 +54,7 @@ config CPU_EXYNOS4210
 	select PM_GENERIC_DOMAINS
 	select S5P_PM if PM
 	select S5P_SLEEP if PM
-	select SAMSUNG_DMADEV
+	select SAMSUNG_DMADEV if ARCH_EXYNOS_SINGLE
 	help
 	  Enable EXYNOS4210 CPU support
 
@@ -47,7 +64,7 @@ config SOC_EXYNOS4212
 	depends on ARCH_EXYNOS4
 	select S5P_PM if PM
 	select S5P_SLEEP if PM
-	select SAMSUNG_DMADEV
+	select SAMSUNG_DMADEV if ARCH_EXYNOS_SINGLE
 	help
 	  Enable EXYNOS4212 SoC support
 
@@ -55,7 +72,7 @@ config SOC_EXYNOS4412
 	bool "SAMSUNG EXYNOS4412"
 	default y
 	depends on ARCH_EXYNOS4
-	select SAMSUNG_DMADEV
+	select SAMSUNG_DMADEV if ARCH_EXYNOS_SINGLE
 	help
 	  Enable EXYNOS4412 SoC support
 
@@ -67,7 +84,7 @@ config SOC_EXYNOS5250
 	select S5P_PM if PM
 	select S5P_SLEEP if PM
 	select S5P_DEV_MFC
-	select SAMSUNG_DMADEV
+	select SAMSUNG_DMADEV if ARCH_EXYNOS_SINGLE
 	help
 	  Enable EXYNOS5250 SoC support
 
diff --git a/arch/arm/mach-exynos/Makefile b/arch/arm/mach-exynos/Makefile
index b09b027..ef6860b 100644
--- a/arch/arm/mach-exynos/Makefile
+++ b/arch/arm/mach-exynos/Makefile
@@ -4,6 +4,7 @@
 #		http://www.samsung.com/
 #
 # Licensed under GPLv2
+ccflags-$(CONFIG_ARCH_MULTIPLATFORM) += -I$(srctree)/$(src)/include -I$(srctree)/arch/arm/plat-samsung/include
 
 obj-y				:=
 obj-m				:=
@@ -48,12 +49,12 @@ obj-$(CONFIG_MACH_EXYNOS5_DT)		+= mach-exynos5-dt.o
 # device support
 
 obj-y					+= dev-uart.o
-obj-$(CONFIG_ARCH_EXYNOS4)		+= dev-audio.o
+obj-$(CONFIG_ARCH_EXYNOS4_SINGLE)	+= dev-audio.o
 obj-$(CONFIG_EXYNOS4_DEV_AHCI)		+= dev-ahci.o
 obj-$(CONFIG_EXYNOS_DEV_DMA)		+= dma.o
 obj-$(CONFIG_EXYNOS4_DEV_USB_OHCI)	+= dev-ohci.o
 
-obj-$(CONFIG_ARCH_EXYNOS)		+= setup-i2c0.o
+obj-$(CONFIG_ARCH_EXYNOS_SINGLE)	+= setup-i2c0.o
 obj-$(CONFIG_EXYNOS4_SETUP_FIMC)	+= setup-fimc.o
 obj-$(CONFIG_EXYNOS4_SETUP_FIMD0)	+= setup-fimd0.o
 obj-$(CONFIG_EXYNOS4_SETUP_I2C1)	+= setup-i2c1.o
diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
index 0634f99..8419190 100644
--- a/arch/arm/mach-exynos/common.c
+++ b/arch/arm/mach-exynos/common.c
@@ -393,6 +393,9 @@ static void __init exynos4_map_io(void)
 	if (soc_is_exynos4212() || soc_is_exynos4412())
 		iotable_init(exynos4x12_iodesc, ARRAY_SIZE(exynos4x12_iodesc));
 
+	if (!IS_ENABLED(CONFIG_EXYNOS_ATAGS))
+		return
+
 	/* initialize device information early */
 	exynos4_default_sdhci0();
 	exynos4_default_sdhci1();
@@ -597,6 +600,8 @@ static void __init exynos4_init_uarts(struct s3c2410_uartcfg *cfg, int no)
 	s3c24xx_init_uartdevs("exynos4210-uart", exynos4_uart_resources, cfg, no);
 }
 
+
+#ifdef CONFIG_EXYNOS_ATAGS
 static void __iomem *exynos_eint_base;
 
 static DEFINE_SPINLOCK(eint_lock);
@@ -903,6 +908,7 @@ static int __init exynos_init_irq_eint(void)
 	return 0;
 }
 arch_initcall(exynos_init_irq_eint);
+#endif
 
 static struct resource exynos4_pmu_resource[] = {
 	DEFINE_RES_IRQ(EXYNOS4_IRQ_PMU),
diff --git a/arch/arm/plat-samsung/Kconfig b/arch/arm/plat-samsung/Kconfig
index 54d1861..53e7eeb 100644
--- a/arch/arm/plat-samsung/Kconfig
+++ b/arch/arm/plat-samsung/Kconfig
@@ -13,6 +13,10 @@ config PLAT_SAMSUNG
 	help
 	  Base platform code for all Samsung SoC based systems
 
+config PLAT_SAMSUNG_SINGLE
+	def_bool PLAT_SAMSUNG && !ARCH_MULTIPLATFORM
+	
+
 config PLAT_S5P
 	bool
 	depends on (ARCH_S5P64X0 || ARCH_S5PC100 || ARCH_S5PV210 || ARCH_EXYNOS)
@@ -23,7 +27,7 @@ config PLAT_S5P
 	select GIC_NON_BANKED if ARCH_EXYNOS4
 	select NO_IOPORT
 	select PLAT_SAMSUNG
-	select S3C_GPIO_TRACK
+	select S3C_GPIO_TRACK if PLAT_SAMSUNG_SINGLE
 	select S5P_GPIO_DRVSTR
 	select SAMSUNG_CLKSRC if !COMMON_CLK
 	select SAMSUNG_GPIOLIB_4BIT
@@ -164,6 +168,7 @@ config S5P_DEV_UART
 
 config S3C_ADC
 	bool "ADC common driver support"
+	depends on PLAT_SAMSUNG_SINGLE
 	help
 	  Core support for the ADC block found in the Samsung SoC systems
 	  for drivers such as the touchscreen and hwmon to use to share
diff --git a/arch/arm/plat-samsung/Makefile b/arch/arm/plat-samsung/Makefile
index a23c460..f38ce84 100644
--- a/arch/arm/plat-samsung/Makefile
+++ b/arch/arm/plat-samsung/Makefile
@@ -4,6 +4,9 @@
 #
 # Licensed under GPLv2
 
+ccflags-$(CONFIG_ARCH_MULTI_V7) += -I$(srctree)/$(src)/include
+ccflags-$(CONFIG_ARCH_EXYNOS)	+= -I$(srctree)/arch/arm/mach-exynos/include
+
 obj-y				:=
 obj-m				:=
 obj-n				:= dummy.o
@@ -33,7 +36,7 @@ obj-$(CONFIG_S3C_ADC)	+= adc.o
 
 obj-y				+= platformdata.o
 
-obj-y				+= devs.o
+obj-$(CONFIG_PLAT_SAMSUNG_SINGLE)	+= devs.o
 obj-y				+= dev-uart.o
 obj-$(CONFIG_S5P_DEV_MFC)	+= s5p-dev-mfc.o
 obj-$(CONFIG_S5P_DEV_UART)	+= s5p-dev-uart.o
@@ -50,9 +53,10 @@ obj-$(CONFIG_S3C_DMA)		+= dma.o s3c-dma-ops.o
 obj-$(CONFIG_SAMSUNG_DMADEV)	+= dma-ops.o
 
 # PM support
-
 obj-$(CONFIG_PM)		+= pm.o
+ifdef CONFIG_PLAT_SAMSUNG_SINGLE
 obj-$(CONFIG_PM)		+= pm-gpio.o
+endif
 obj-$(CONFIG_SAMSUNG_PM_CHECK)	+= pm-check.o
 
 obj-$(CONFIG_SAMSUNG_WAKEMASK)	+= wakeup-mask.o
diff --git a/arch/arm/plat-samsung/include/plat/pm.h b/arch/arm/plat-samsung/include/plat/pm.h
index f6fcade..266a4e3 100644
--- a/arch/arm/plat-samsung/include/plat/pm.h
+++ b/arch/arm/plat-samsung/include/plat/pm.h
@@ -166,6 +166,7 @@ extern void s3c_pm_check_store(void);
  */
 extern void s3c_pm_configure_extint(void);
 
+#ifdef CONFIG_PLAT_SAMSUNG_SINGLE
 /**
  * samsung_pm_restore_gpios() - restore the state of the gpios after sleep.
  *
@@ -181,6 +182,10 @@ extern void samsung_pm_restore_gpios(void);
  * Save the GPIO states for resotration on resume. See samsung_pm_restore_gpios().
  */
 extern void samsung_pm_save_gpios(void);
+#else
+#define samsung_pm_restore_gpios()	do { } while(0)
+#define samsung_pm_save_gpios()		do { } while(0)
+#endif
 
 extern void s3c_pm_save_core(void);
 extern void s3c_pm_restore_core(void);
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index e005ad5..3faff2c 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -58,7 +58,7 @@ obj-$(CONFIG_GPIO_PXA)		+= gpio-pxa.o
 obj-$(CONFIG_GPIO_RC5T583)	+= gpio-rc5t583.o
 obj-$(CONFIG_GPIO_RDC321X)	+= gpio-rdc321x.o
 obj-$(CONFIG_GPIO_RCAR)		+= gpio-rcar.o
-obj-$(CONFIG_PLAT_SAMSUNG)	+= gpio-samsung.o
+obj-$(CONFIG_PLAT_SAMSUNG_SINGLE)	+= gpio-samsung.o
 obj-$(CONFIG_ARCH_SA1100)	+= gpio-sa1100.o
 obj-$(CONFIG_GPIO_SCH)		+= gpio-sch.o
 obj-$(CONFIG_GPIO_SODAVILLE)	+= gpio-sodaville.o
-- 
1.8.1.2



From arnd at arndb.de  Wed Apr 10 20:05:07 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 11 Apr 2013 02:05:07 +0200
Subject: [PATCH 25/30] irqchip: exynos: pass max combiner number to
 combiner_init
In-Reply-To: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
References: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
Message-ID: <1365638712-1028578-26-git-send-email-arnd@arndb.de>

We can find out the number of combined IRQs from the device
tree, but in case of ATAGS boot, the driver currently uses
hardcoded values based on the SoC type. We can't do that
in general for a multiplatform kernel, so let's instead pass
this information from platform code directly in case of
ATAGS boot.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Cc: Thomas Gleixner <tglx at linutronix.de>
---
 arch/arm/mach-exynos/common.c     | 15 ++++++++++++-
 arch/arm/mach-exynos/common.h     |  3 ++-
 drivers/irqchip/exynos-combiner.c | 46 ++++++++++++++-------------------------
 3 files changed, 32 insertions(+), 32 deletions(-)

diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
index 8e85d6c..b0e0b41 100644
--- a/arch/arm/mach-exynos/common.c
+++ b/arch/arm/mach-exynos/common.c
@@ -452,6 +452,19 @@ void __init exynos_init_time(void)
 	}
 }
 
+static unsigned int max_combiner_nr(void)
+{
+	if (soc_is_exynos5250())
+		return EXYNOS5_MAX_COMBINER_NR;
+	else if (soc_is_exynos4412())
+		return EXYNOS4412_MAX_COMBINER_NR;
+	else if (soc_is_exynos4212())
+		return EXYNOS4212_MAX_COMBINER_NR;
+	else
+		return EXYNOS4210_MAX_COMBINER_NR;
+}
+
+
 void __init exynos4_init_irq(void)
 {
 	unsigned int gic_bank_offset;
@@ -466,7 +479,7 @@ void __init exynos4_init_irq(void)
 #endif
 
 	if (!of_have_populated_dt())
-		combiner_init(S5P_VA_COMBINER_BASE, NULL);
+		combiner_init(S5P_VA_COMBINER_BASE, NULL, max_combiner_nr());
 
 	/*
 	 * The parameters of s5p_init_irq() are for VIC init.
diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
index f426a5b..49bebd1 100644
--- a/arch/arm/mach-exynos/common.h
+++ b/arch/arm/mach-exynos/common.h
@@ -71,7 +71,8 @@ void exynos4212_register_clocks(void);
 #endif
 
 struct device_node;
-void combiner_init(void __iomem *combiner_base, struct device_node *np);
+void combiner_init(void __iomem *combiner_base, struct device_node *np,
+			unsigned int max_nr);
 
 extern struct smp_operations exynos_smp_ops;
 
diff --git a/drivers/irqchip/exynos-combiner.c b/drivers/irqchip/exynos-combiner.c
index 02492ab..e7aef59 100644
--- a/drivers/irqchip/exynos-combiner.c
+++ b/drivers/irqchip/exynos-combiner.c
@@ -26,6 +26,8 @@
 #define COMBINER_ENABLE_CLEAR	0x4
 #define COMBINER_INT_STATUS	0xC
 
+#define IRQ_IN_COMBINER		8
+
 static DEFINE_SPINLOCK(irq_controller_lock);
 
 struct combiner_chip_data {
@@ -113,23 +115,9 @@ static struct irq_chip combiner_chip = {
 #endif
 };
 
-static unsigned int max_combiner_nr(void)
-{
-	if (soc_is_exynos5250())
-		return EXYNOS5_MAX_COMBINER_NR;
-	else if (soc_is_exynos4412())
-		return EXYNOS4412_MAX_COMBINER_NR;
-	else if (soc_is_exynos4212())
-		return EXYNOS4212_MAX_COMBINER_NR;
-	else
-		return EXYNOS4210_MAX_COMBINER_NR;
-}
-
 static void __init combiner_cascade_irq(unsigned int combiner_nr,
 					unsigned int irq)
 {
-	if (combiner_nr >= max_combiner_nr())
-		BUG();
 	if (irq_set_handler_data(irq, &combiner_data[combiner_nr]) != 0)
 		BUG();
 	irq_set_chained_handler(irq, combiner_handle_cascade_irq);
@@ -140,7 +128,7 @@ static void __init combiner_init_one(unsigned int combiner_nr,
 {
 	combiner_data[combiner_nr].base = base;
 	combiner_data[combiner_nr].irq_offset = irq_find_mapping(
-		combiner_irq_domain, combiner_nr * MAX_IRQ_IN_COMBINER);
+		combiner_irq_domain, combiner_nr * IRQ_IN_COMBINER);
 	combiner_data[combiner_nr].irq_mask = 0xff << ((combiner_nr % 4) << 3);
 	combiner_data[combiner_nr].parent_irq = irq;
 
@@ -162,7 +150,7 @@ static int combiner_irq_domain_xlate(struct irq_domain *d,
 	if (intsize < 2)
 		return -EINVAL;
 
-	*out_hwirq = intspec[0] * MAX_IRQ_IN_COMBINER + intspec[1];
+	*out_hwirq = intspec[0] * IRQ_IN_COMBINER + intspec[1];
 	*out_type = 0;
 
 	return 0;
@@ -210,22 +198,13 @@ static unsigned int exynos4x12_combiner_extra_irq(int group)
 }
 
 void __init combiner_init(void __iomem *combiner_base,
-			  struct device_node *np)
+			  struct device_node *np,
+			  unsigned int max_nr)
 {
 	int i, irq, irq_base;
-	unsigned int max_nr, nr_irq;
+	unsigned int nr_irq;
 
-	max_nr = max_combiner_nr();
-
-	if (np) {
-		if (of_property_read_u32(np, "samsung,combiner-nr", &max_nr)) {
-			pr_info("%s: number of combiners not specified, "
-				"setting default as %d.\n",
-				__func__, max_nr);
-		}
-	}
-
-	nr_irq = max_nr * MAX_IRQ_IN_COMBINER;
+	nr_irq = max_nr * IRQ_IN_COMBINER;
 
 	irq_base = irq_alloc_descs(COMBINER_IRQ(0, 0), 1, nr_irq, 0);
 	if (IS_ERR_VALUE(irq_base)) {
@@ -259,6 +238,7 @@ static int __init combiner_of_init(struct device_node *np,
 				   struct device_node *parent)
 {
 	void __iomem *combiner_base;
+	unsigned int max_nr;
 
 	combiner_base = of_iomap(np, 0);
 	if (!combiner_base) {
@@ -266,7 +246,13 @@ static int __init combiner_of_init(struct device_node *np,
 		return -ENXIO;
 	}
 
-	combiner_init(combiner_base, np);
+	if (of_property_read_u32(np, "samsung,combiner-nr", &max_nr)) {
+		pr_info("%s: number of combiners not specified, "
+			"setting default as %d.\n",
+			__func__, max_nr);
+	}
+
+	combiner_init(combiner_base, np, max_nr);
 
 	return 0;
 }
-- 
1.8.1.2



From arnd at arndb.de  Wed Apr 10 20:05:11 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 11 Apr 2013 02:05:11 +0200
Subject: [PATCH 29/30] spi: s3c64xx: move to generic dmaengine API
In-Reply-To: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
References: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
Message-ID: <1365638712-1028578-30-git-send-email-arnd@arndb.de>

The spi-s3c64xx uses a Samsung proprietary interface for
talking to the DMA engine, which does not work with
multiplatform kernels.

This version of the patch leaves the old code in place,
behind an #ifdef. This can be removed in the future,
after the s3c64xx platform start supporting the regular
dmaengine interface. An earlier version of this patch was
tested successfully on exynos5250 by Padma Venkat.

The conversion was rather mechanical, since the samsung
interface is just a shallow wrapper around the dmaengine
interface.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Cc: spi-devel-general at lists.sourceforge.net
Cc: Mark Brown <broonie at opensource.wolfsonmicro.com>
Cc: Grant Likely <grant.likely at secretlab.ca>
Cc: Padma Venkat <padma.kvr at gmail.com>
---
 arch/arm/plat-samsung/devs.c              |  10 ++
 drivers/spi/spi-s3c64xx.c                 | 185 +++++++++++++++++++++++-------
 include/linux/platform_data/spi-s3c64xx.h |   3 +
 3 files changed, 154 insertions(+), 44 deletions(-)

diff --git a/arch/arm/plat-samsung/devs.c b/arch/arm/plat-samsung/devs.c
index b441908..30c2fe2 100644
--- a/arch/arm/plat-samsung/devs.c
+++ b/arch/arm/plat-samsung/devs.c
@@ -10,6 +10,7 @@
  * published by the Free Software Foundation.
 */
 
+#include <linux/amba/pl330.h>
 #include <linux/kernel.h>
 #include <linux/types.h>
 #include <linux/interrupt.h>
@@ -1512,6 +1513,9 @@ void __init s3c64xx_spi0_set_platdata(int (*cfg_gpio)(void), int src_clk_nr,
 	pd.num_cs = num_cs;
 	pd.src_clk_nr = src_clk_nr;
 	pd.cfg_gpio = (cfg_gpio) ? cfg_gpio : s3c64xx_spi0_cfg_gpio;
+#ifdef CONFIG_PL330_DMA
+	pd.filter = pl330_filter;
+#endif
 
 	s3c_set_platdata(&pd, sizeof(pd), &s3c64xx_device_spi0);
 }
@@ -1550,6 +1554,9 @@ void __init s3c64xx_spi1_set_platdata(int (*cfg_gpio)(void), int src_clk_nr,
 	pd.num_cs = num_cs;
 	pd.src_clk_nr = src_clk_nr;
 	pd.cfg_gpio = (cfg_gpio) ? cfg_gpio : s3c64xx_spi1_cfg_gpio;
+#ifdef CONFIG_PL330_DMA
+	pd.filter = pl330_filter;
+#endif
 
 	s3c_set_platdata(&pd, sizeof(pd), &s3c64xx_device_spi1);
 }
@@ -1588,6 +1595,9 @@ void __init s3c64xx_spi2_set_platdata(int (*cfg_gpio)(void), int src_clk_nr,
 	pd.num_cs = num_cs;
 	pd.src_clk_nr = src_clk_nr;
 	pd.cfg_gpio = (cfg_gpio) ? cfg_gpio : s3c64xx_spi2_cfg_gpio;
+#ifdef CONFIG_PL330_DMA
+	pd.filter = pl330_filter;
+#endif
 
 	s3c_set_platdata(&pd, sizeof(pd), &s3c64xx_device_spi2);
 }
diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index 4188b2f..74809af 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -24,6 +24,7 @@
 #include <linux/delay.h>
 #include <linux/clk.h>
 #include <linux/dma-mapping.h>
+#include <linux/dmaengine.h>
 #include <linux/platform_device.h>
 #include <linux/pm_runtime.h>
 #include <linux/spi/spi.h>
@@ -31,9 +32,12 @@
 #include <linux/of.h>
 #include <linux/of_gpio.h>
 
-#include <mach/dma.h>
 #include <linux/platform_data/spi-s3c64xx.h>
 
+#ifdef CONFIG_SAMSUNG_DMADEV
+#include <mach/dma.h>
+#endif
+
 #define MAX_SPI_PORTS		3
 
 /* Registers and bit-fields */
@@ -131,9 +135,9 @@
 #define TXBUSY    (1<<3)
 
 struct s3c64xx_spi_dma_data {
-	unsigned		ch;
+	struct dma_chan *ch;
 	enum dma_transfer_direction direction;
-	enum dma_ch	dmach;
+	unsigned int dmach;
 };
 
 /**
@@ -195,16 +199,14 @@ struct s3c64xx_spi_driver_data {
 	unsigned                        cur_speed;
 	struct s3c64xx_spi_dma_data	rx_dma;
 	struct s3c64xx_spi_dma_data	tx_dma;
+#ifdef CONFIG_SAMSUNG_DMADEV
 	struct samsung_dma_ops		*ops;
+#endif
 	struct s3c64xx_spi_port_config	*port_conf;
 	unsigned int			port_id;
 	unsigned long			gpios[4];
 };
 
-static struct s3c2410_dma_client s3c64xx_spi_dma_client = {
-	.name = "samsung-spi-dma",
-};
-
 static void flush_fifo(struct s3c64xx_spi_driver_data *sdd)
 {
 	void __iomem *regs = sdd->regs;
@@ -281,6 +283,13 @@ static void s3c64xx_spi_dmacb(void *data)
 	spin_unlock_irqrestore(&sdd->lock, flags);
 }
 
+#ifdef CONFIG_SAMSUNG_DMADEV
+/* FIXME: remove this section once arch/arm/mach-s3c64xx uses dmaengine */
+
+static struct s3c2410_dma_client s3c64xx_spi_dma_client = {
+	.name = "samsung-spi-dma",
+};
+
 static void prepare_dma(struct s3c64xx_spi_dma_data *dma,
 					unsigned len, dma_addr_t buf)
 {
@@ -294,14 +303,14 @@ static void prepare_dma(struct s3c64xx_spi_dma_data *dma,
 		config.direction = sdd->rx_dma.direction;
 		config.fifo = sdd->sfr_start + S3C64XX_SPI_RX_DATA;
 		config.width = sdd->cur_bpw / 8;
-		sdd->ops->config(sdd->rx_dma.ch, &config);
+		sdd->ops->config((enum dma_ch)sdd->rx_dma.ch, &config);
 	} else {
 		sdd = container_of((void *)dma,
 			struct s3c64xx_spi_driver_data, tx_dma);
 		config.direction =  sdd->tx_dma.direction;
 		config.fifo = sdd->sfr_start + S3C64XX_SPI_TX_DATA;
 		config.width = sdd->cur_bpw / 8;
-		sdd->ops->config(sdd->tx_dma.ch, &config);
+		sdd->ops->config((enum dma_ch)sdd->tx_dma.ch, &config);
 	}
 
 	info.cap = DMA_SLAVE;
@@ -311,8 +320,8 @@ static void prepare_dma(struct s3c64xx_spi_dma_data *dma,
 	info.direction = dma->direction;
 	info.buf = buf;
 
-	sdd->ops->prepare(dma->ch, &info);
-	sdd->ops->trigger(dma->ch);
+	sdd->ops->prepare((enum dma_ch)dma->ch, &info);
+	sdd->ops->trigger((enum dma_ch)dma->ch);
 }
 
 static int acquire_dma(struct s3c64xx_spi_driver_data *sdd)
@@ -325,12 +334,126 @@ static int acquire_dma(struct s3c64xx_spi_driver_data *sdd)
 	req.cap = DMA_SLAVE;
 	req.client = &s3c64xx_spi_dma_client;
 
-	sdd->rx_dma.ch = sdd->ops->request(sdd->rx_dma.dmach, &req, dev, "rx");
-	sdd->tx_dma.ch = sdd->ops->request(sdd->tx_dma.dmach, &req, dev, "tx");
+	sdd->rx_dma.ch = (void *)sdd->ops->request(sdd->rx_dma.dmach, &req, dev, "rx");
+	sdd->tx_dma.ch = (void *)sdd->ops->request(sdd->tx_dma.dmach, &req, dev, "tx");
 
 	return 1;
 }
 
+static int s3c64xx_spi_prepare_transfer(struct spi_master *spi)
+{
+	struct s3c64xx_spi_driver_data *sdd = spi_master_get_devdata(spi);
+
+	/* Acquire DMA channels */
+	while (!acquire_dma(sdd))
+		usleep_range(10000, 11000);
+
+	pm_runtime_get_sync(&sdd->pdev->dev);
+
+	return 0;
+}
+
+static int s3c64xx_spi_unprepare_transfer(struct spi_master *spi)
+{
+	struct s3c64xx_spi_driver_data *sdd = spi_master_get_devdata(spi);
+
+	/* Free DMA channels */
+	sdd->ops->release((enum dma_ch)sdd->rx_dma.ch, &s3c64xx_spi_dma_client);
+	sdd->ops->release((enum dma_ch)sdd->tx_dma.ch, &s3c64xx_spi_dma_client);
+
+	pm_runtime_put(&sdd->pdev->dev);
+
+	return 0;
+}
+
+static void s3c64xx_spi_dma_stop(struct s3c64xx_spi_driver_data *sdd,
+				 struct s3c64xx_spi_dma_data *dma)
+{
+	sdd->ops->stop((enum dma_ch)dma->ch);
+}
+#else
+
+static void prepare_dma(struct s3c64xx_spi_dma_data *dma,
+					unsigned len, dma_addr_t buf)
+{
+	struct s3c64xx_spi_driver_data *sdd;
+	struct dma_slave_config config;
+	struct scatterlist sg;
+	struct dma_async_tx_descriptor *desc;
+
+	if (dma->direction == DMA_DEV_TO_MEM) {
+		sdd = container_of((void *)dma,
+			struct s3c64xx_spi_driver_data, rx_dma);
+		config.direction = dma->direction;
+		config.src_addr = sdd->sfr_start + S3C64XX_SPI_RX_DATA;
+		config.src_addr_width = sdd->cur_bpw / 8;
+		config.src_maxburst = 1;
+		dmaengine_slave_config(dma->ch, &config);
+	} else {
+		sdd = container_of((void *)dma,
+			struct s3c64xx_spi_driver_data, tx_dma);
+		config.direction = dma->direction;
+		config.dst_addr = sdd->sfr_start + S3C64XX_SPI_TX_DATA;
+		config.dst_addr_width = sdd->cur_bpw / 8;
+		config.dst_maxburst = 1;
+		dmaengine_slave_config(dma->ch, &config);
+	}
+
+	sg_init_table(&sg, 1);
+	sg_dma_len(&sg) = len;
+	sg_set_page(&sg, pfn_to_page(PFN_DOWN(buf)),
+		    len, offset_in_page(buf));
+	sg_dma_address(&sg) = buf;
+
+	desc = dmaengine_prep_slave_sg(dma->ch,
+		&sg, 1, dma->direction, DMA_PREP_INTERRUPT);
+
+	desc->callback = s3c64xx_spi_dmacb;
+	desc->callback_param = dma;
+
+	dmaengine_submit(desc);
+	dma_async_issue_pending(dma->ch);
+}
+
+static int s3c64xx_spi_prepare_transfer(struct spi_master *spi)
+{
+	struct s3c64xx_spi_driver_data *sdd = spi_master_get_devdata(spi);
+	dma_filter_fn filter = sdd->cntrlr_info->filter;
+	struct device *dev = &sdd->pdev->dev;
+	dma_cap_mask_t mask;
+
+	dma_cap_zero(mask);
+	dma_cap_set(DMA_SLAVE, mask);
+
+	/* Acquire DMA channels */
+	sdd->rx_dma.ch = dma_request_slave_channel_compat(mask, filter,
+				(void*)sdd->rx_dma.dmach, dev, "rx");
+	sdd->tx_dma.ch = dma_request_slave_channel_compat(mask, filter,
+				(void*)sdd->tx_dma.dmach, dev, "tx");
+	pm_runtime_get_sync(&sdd->pdev->dev);
+
+	return 0;
+}
+
+static int s3c64xx_spi_unprepare_transfer(struct spi_master *spi)
+{
+	struct s3c64xx_spi_driver_data *sdd = spi_master_get_devdata(spi);
+
+	/* Free DMA channels */
+	dma_release_channel(sdd->rx_dma.ch);
+	dma_release_channel(sdd->tx_dma.ch);
+
+	pm_runtime_put(&sdd->pdev->dev);
+	return 0;
+}
+
+static void s3c64xx_spi_dma_stop(struct s3c64xx_spi_driver_data *sdd,
+				 struct s3c64xx_spi_dma_data *dma)
+{
+	dmaengine_terminate_all(dma->ch);
+}
+#endif
+
 static void enable_datapath(struct s3c64xx_spi_driver_data *sdd,
 				struct spi_device *spi,
 				struct spi_transfer *xfer, int dma_mode)
@@ -713,9 +836,9 @@ static int s3c64xx_spi_transfer_one_message(struct spi_master *master,
 		}
 
 		/* Polling method for xfers not bigger than FIFO capacity */
-		if (xfer->len <= ((FIFO_LVL_MASK(sdd) >> 1) + 1))
-			use_dma = 0;
-		else
+		use_dma = 0;
+		if (sdd->rx_dma.ch && sdd->tx_dma.ch &&
+		    (xfer->len > ((FIFO_LVL_MASK(sdd) >> 1) + 1)))
 			use_dma = 1;
 
 		spin_lock_irqsave(&sdd->lock, flags);
@@ -750,10 +873,10 @@ static int s3c64xx_spi_transfer_one_message(struct spi_master *master,
 			if (use_dma) {
 				if (xfer->tx_buf != NULL
 						&& (sdd->state & TXBUSY))
-					sdd->ops->stop(sdd->tx_dma.ch);
+					s3c64xx_spi_dma_stop(sdd, &sdd->tx_dma);
 				if (xfer->rx_buf != NULL
 						&& (sdd->state & RXBUSY))
-					sdd->ops->stop(sdd->rx_dma.ch);
+					s3c64xx_spi_dma_stop(sdd, &sdd->rx_dma);
 			}
 
 			goto out;
@@ -790,32 +913,6 @@ out:
 	return 0;
 }
 
-static int s3c64xx_spi_prepare_transfer(struct spi_master *spi)
-{
-	struct s3c64xx_spi_driver_data *sdd = spi_master_get_devdata(spi);
-
-	/* Acquire DMA channels */
-	while (!acquire_dma(sdd))
-		usleep_range(10000, 11000);
-
-	pm_runtime_get_sync(&sdd->pdev->dev);
-
-	return 0;
-}
-
-static int s3c64xx_spi_unprepare_transfer(struct spi_master *spi)
-{
-	struct s3c64xx_spi_driver_data *sdd = spi_master_get_devdata(spi);
-
-	/* Free DMA channels */
-	sdd->ops->release(sdd->rx_dma.ch, &s3c64xx_spi_dma_client);
-	sdd->ops->release(sdd->tx_dma.ch, &s3c64xx_spi_dma_client);
-
-	pm_runtime_put(&sdd->pdev->dev);
-
-	return 0;
-}
-
 static struct s3c64xx_spi_csinfo *s3c64xx_get_slave_ctrldata(
 				struct s3c64xx_spi_driver_data *sdd,
 				struct spi_device *spi)
diff --git a/include/linux/platform_data/spi-s3c64xx.h b/include/linux/platform_data/spi-s3c64xx.h
index ceba18d..8447f63 100644
--- a/include/linux/platform_data/spi-s3c64xx.h
+++ b/include/linux/platform_data/spi-s3c64xx.h
@@ -11,6 +11,8 @@
 #ifndef __S3C64XX_PLAT_SPI_H
 #define __S3C64XX_PLAT_SPI_H
 
+#include <linux/dmaengine.h>
+
 struct platform_device;
 
 /**
@@ -38,6 +40,7 @@ struct s3c64xx_spi_info {
 	int src_clk_nr;
 	int num_cs;
 	int (*cfg_gpio)(void);
+	dma_filter_fn filter;
 };
 
 /**
-- 
1.8.1.2



From arnd at arndb.de  Wed Apr 10 20:04:58 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 11 Apr 2013 02:04:58 +0200
Subject: [PATCH 16/30] rtc: s3c: make header file local
In-Reply-To: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
References: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
Message-ID: <1365638712-1028578-17-git-send-email-arnd@arndb.de>

Nothing outside of the rtc driver includes plat/regs-rtc.h,
so we can simply move the file into the same directory,
which allows us to build the file as platform-independent
code.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Cc: rtc-linux at googlegroups.com
Cc: Alessandro Zummo <a.zummo at towertech.it>
---
 drivers/rtc/rtc-s3c.c                                                  | 3 +--
 arch/arm/plat-samsung/include/plat/regs-rtc.h => drivers/rtc/rtc-s3c.h | 3 +--
 2 files changed, 2 insertions(+), 4 deletions(-)
 rename arch/arm/plat-samsung/include/plat/regs-rtc.h => drivers/rtc/rtc-s3c.h (97%)

diff --git a/drivers/rtc/rtc-s3c.c b/drivers/rtc/rtc-s3c.c
index fb994e9..7995f79 100644
--- a/drivers/rtc/rtc-s3c.c
+++ b/drivers/rtc/rtc-s3c.c
@@ -29,9 +29,8 @@
 #include <linux/uaccess.h>
 #include <linux/io.h>
 
-#include <mach/hardware.h>
 #include <asm/irq.h>
-#include <plat/regs-rtc.h>
+#include "rtc-s3c.h"
 
 enum s3c_cpu_type {
 	TYPE_S3C2410,
diff --git a/arch/arm/plat-samsung/include/plat/regs-rtc.h b/drivers/rtc/rtc-s3c.h
similarity index 97%
rename from arch/arm/plat-samsung/include/plat/regs-rtc.h
rename to drivers/rtc/rtc-s3c.h
index 0f8263e..004b61a 100644
--- a/arch/arm/plat-samsung/include/plat/regs-rtc.h
+++ b/drivers/rtc/rtc-s3c.h
@@ -1,5 +1,4 @@
-/* arch/arm/mach-s3c2410/include/mach/regs-rtc.h
- *
+/*
  * Copyright (c) 2003 Simtec Electronics <linux at simtec.co.uk>
  *		      http://www.simtec.co.uk/products/SWLINUX/
  *
-- 
1.8.1.2



From emilio at elopez.com.ar  Wed Apr 10 20:07:21 2013
From: emilio at elopez.com.ar (=?UTF-8?B?RW1pbGlvIEzDs3Bleg==?=)
Date: Wed, 10 Apr 2013 21:07:21 -0300
Subject: [PATCH v2 3/3] clk: sunxi: Unify oscillator clock
In-Reply-To: <1365631378-16103-4-git-send-email-mturquette@linaro.org>
References: <1365515284-32061-2-git-send-email-emilio@elopez.com.ar>
 <1365631378-16103-1-git-send-email-mturquette@linaro.org>
 <1365631378-16103-4-git-send-email-mturquette@linaro.org>
Message-ID: <5165FEB9.9080906@elopez.com.ar>

Hi Mike,

El 10/04/13 19:02, Mike Turquette escribi?:
> From: Emilio L?pez <emilio at elopez.com.ar>
> 
> This commit uses the new fixed-rate support on the composite clock to
> unify osc24M_fixed and osc24M clocks, so it matches the actual hardware.
> 
> Signed-off-by: Emilio L?pez <emilio at elopez.com.ar>
> Signed-off-by: Mike Turquette <mturquette at linaro.org>
> [mturquette at linaro.org: replace clk_register_gatable_osc with a call to
> clk_register_composite]
> ---
> Emilio,
> 
> I haven't been able to test these changes at run-time.  Can you see if
> they are valid for solving your issue on sunxi?

I tested the three patches you sent + 3/3 from the original series which
is the DT part.

$ git log --oneline -n 4
b63f51e ARM: sunxi: unify osc24M_fixed and osc24M
7f86473 clk: sunxi: Unify oscillator clock
78c8aaf clk: composite: allow fixed rates & fixed dividers
2d52a44 clk: composite: rename 'div' references to 'rate'

It seems to be working fine as far as I can tell, so

Tested-by: Emilio L?pez <emilio at elopez.com.ar>

Thanks,

Emilio


From arnd at arndb.de  Wed Apr 10 20:04:42 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 11 Apr 2013 02:04:42 +0200
Subject: [PATCH 00/30] ARM: exynos multiplatform support
Message-ID: <1365638712-1028578-1-git-send-email-arnd@arndb.de>

Hi everyone,

I have updated my series for multiplatform support of the ARM exynos
platform, based on what is currently queued up in arm-soc.

It would be really nice to still get this merged for 3.10. A lot of
the patches are really trivial, but there are some complex ones
as well.

To all subsystem maintainers: feel free to directly apply the patches
for your subsystem, there should be no dependencies between any of them,
aside from the last patch requiring all of the earlier ones to be applied
first. Getting an Ack is also fine so we can put the patches into arm-soc.

	Arnd

Arnd Bergmann (30):
  ARM: exynos: introduce EXYNOS_ATAGS symbol
  ARM: exynos: prepare for sparse IRQ
  ARM: exynos: move debug-macro.S to include/debug/
  ARM: samsung: move mfc device definition to s5p-dev-mfc.c
  tty: serial/samsung: prepare for common clock API
  tty: serial/samsung: make register definitions global
  tty: serial/samsung: fix modular build
  i2c: s3c2410: make header file local
  mmc: sdhci-s3c: remove platform dependencies
  usb: exynos: do not include plat/usb-phy.h
  [media] exynos: remove unnecessary header inclusions
  video/exynos: remove unnecessary header inclusions
  video/s3c: move platform_data out of arch/arm
  thermal/exynos: remove unnecessary header inclusions
  mtd: onenand/samsung: make regs-onenand.h file local
  rtc: s3c: make header file local
  pwm: samsung: repair the worst MMIO abuses
  ASoC: samsung: move plat/ headers to local directory
  ASoC: samsung: use irq resource for idma
  ASoC: samsung: convert to dmaengine API
  ASoC: samsung/i2s: fix module_device_table
  ASoC: samsung/idma: export idma_reg_addr_init
  clk: exynos: prepare for multiplatform
  clocksource: exynos_mct: remove platform header dependency
  irqchip: exynos: pass max combiner number to combiner_init
  irqchip: exynos: allocate combiner_data dynamically
  irqchip: exynos: localize irq lookup for ATAGS
  irqchip: exynos: pass irq_base from platform
  spi: s3c64xx: move to generic dmaengine API
  ARM: exynos: enable multiplatform support

 arch/arm/Kconfig                                   |  10 +-
 arch/arm/Kconfig.debug                             |   8 +
 arch/arm/configs/exynos4_defconfig                 |   2 +-
 .../mach/debug-macro.S => include/debug/exynos.S}  |  12 +-
 .../plat/debug-macro.S => include/debug/samsung.S} |   2 +-
 arch/arm/mach-exynos/Kconfig                       |  40 ++-
 arch/arm/mach-exynos/Makefile                      |   5 +-
 arch/arm/mach-exynos/common.c                      |  26 +-
 arch/arm/mach-exynos/common.h                      |   7 +-
 arch/arm/mach-exynos/dev-uart.c                    |   1 +
 arch/arm/mach-exynos/include/mach/irqs.h           |   5 +-
 arch/arm/mach-exynos/mach-armlex4210.c             |   2 +
 arch/arm/mach-exynos/mach-exynos4-dt.c             |   3 +
 arch/arm/mach-exynos/mach-exynos5-dt.c             |   2 +
 arch/arm/mach-exynos/mach-nuri.c                   |   2 +
 arch/arm/mach-exynos/mach-origen.c                 |   2 +
 arch/arm/mach-exynos/mach-smdk4x12.c               |   2 +
 arch/arm/mach-exynos/mach-smdkv310.c               |   3 +
 arch/arm/mach-exynos/setup-sdhci-gpio.c            |   2 +-
 arch/arm/mach-exynos/setup-usb-phy.c               |   8 +-
 arch/arm/mach-s3c24xx/clock-s3c2440.c              |   5 +
 arch/arm/mach-s3c24xx/common.c                     |   5 +
 arch/arm/mach-s3c24xx/dma-s3c2410.c                |   2 -
 arch/arm/mach-s3c24xx/dma-s3c2412.c                |   2 -
 arch/arm/mach-s3c24xx/dma-s3c2440.c                |   2 -
 arch/arm/mach-s3c24xx/dma-s3c2443.c                |   2 -
 arch/arm/mach-s3c24xx/include/mach/debug-macro.S   |   2 +-
 arch/arm/mach-s3c24xx/mach-rx1950.c                |   1 -
 arch/arm/mach-s3c64xx/include/mach/debug-macro.S   |   2 +-
 arch/arm/mach-s3c64xx/setup-usb-phy.c              |   4 +-
 arch/arm/mach-s5p64x0/include/mach/debug-macro.S   |   2 +-
 arch/arm/mach-s5pc100/include/mach/debug-macro.S   |   2 +-
 arch/arm/mach-s5pc100/setup-sdhci-gpio.c           |   1 -
 arch/arm/mach-s5pv210/include/mach/debug-macro.S   |   2 +-
 arch/arm/mach-s5pv210/setup-sdhci-gpio.c           |   1 -
 arch/arm/mach-s5pv210/setup-usb-phy.c              |   4 +-
 arch/arm/plat-samsung/Kconfig                      |   7 +-
 arch/arm/plat-samsung/Makefile                     |   8 +-
 arch/arm/plat-samsung/devs.c                       |  62 ++---
 arch/arm/plat-samsung/include/plat/fb.h            |  50 +---
 arch/arm/plat-samsung/include/plat/pm.h            |   5 +
 arch/arm/plat-samsung/include/plat/regs-serial.h   | 282 +--------------------
 arch/arm/plat-samsung/include/plat/sdhci.h         |  56 +---
 arch/arm/plat-samsung/include/plat/usb-phy.h       |   5 +-
 arch/arm/plat-samsung/irq-vic-timer.c              |   1 +
 arch/arm/plat-samsung/pm.c                         |   1 +
 arch/arm/plat-samsung/s5p-dev-mfc.c                |  42 ++-
 arch/arm/plat-samsung/s5p-irq.c                    |   1 +
 drivers/clk/samsung/clk-exynos4.c                  |  93 +++----
 drivers/clk/samsung/clk-exynos5250.c               |   1 -
 drivers/clk/samsung/clk-exynos5440.c               |   1 -
 drivers/clk/samsung/clk.h                          |   2 -
 drivers/clocksource/exynos_mct.c                   |  21 +-
 drivers/gpio/Makefile                              |   2 +-
 drivers/i2c/busses/i2c-s3c2410.c                   |   3 +-
 .../regs-iic.h => drivers/i2c/busses/i2c-s3c2410.h |   0
 drivers/irqchip/exynos-combiner.c                  | 116 +++++----
 drivers/media/platform/exynos-gsc/gsc-regs.c       |   1 -
 drivers/media/platform/s5p-tv/sii9234_drv.c        |   3 -
 drivers/mmc/host/Kconfig                           |   2 +-
 .../mmc/host/sdhci-s3c-regs.h                      |   0
 drivers/mmc/host/sdhci-s3c.c                       |   5 +-
 drivers/mtd/onenand/samsung.c                      |   4 +-
 .../mtd/onenand/samsung.h                          |   2 -
 drivers/pwm/pwm-samsung.c                          |  60 +++--
 drivers/rtc/rtc-s3c.c                              |   3 +-
 .../plat/regs-rtc.h => drivers/rtc/rtc-s3c.h       |   3 +-
 drivers/spi/spi-s3c64xx.c                          | 185 ++++++++++----
 drivers/thermal/exynos_thermal.c                   |   2 -
 drivers/tty/serial/samsung.c                       |  17 +-
 drivers/tty/serial/samsung.h                       |   4 +-
 drivers/usb/host/ehci-s5p.c                        |   1 -
 drivers/usb/host/ohci-exynos.c                     |   1 -
 drivers/video/exynos/exynos_mipi_dsi.c             |   2 -
 drivers/video/exynos/exynos_mipi_dsi_common.c      |   2 -
 drivers/video/exynos/exynos_mipi_dsi_lowlevel.c    |   2 -
 drivers/video/s3c-fb.c                             |   3 +-
 include/linux/platform_data/mmc-sdhci-s3c.h        |  56 ++++
 include/linux/platform_data/spi-s3c64xx.h          |   3 +
 include/linux/platform_data/video_s3c.h            |  54 ++++
 include/linux/serial_s3c.h                         | 260 +++++++++++++++++++
 sound/soc/samsung/ac97.c                           |   2 +-
 sound/soc/samsung/dma.c                            | 219 ++++++++++++++++
 sound/soc/samsung/dma.h                            |  15 +-
 sound/soc/samsung/h1940_uda1380.c                  |   2 +-
 sound/soc/samsung/i2s.c                            |   4 +-
 sound/soc/samsung/idma.c                           |  11 +-
 sound/soc/samsung/neo1973_wm8753.c                 |   2 +-
 sound/soc/samsung/pcm.c                            |   1 -
 .../include/plat => sound/soc/samsung}/regs-ac97.h |   0
 .../include/plat => sound/soc/samsung}/regs-iis.h  |   0
 sound/soc/samsung/rx1950_uda1380.c                 |   2 +-
 sound/soc/samsung/s3c24xx-i2s.c                    |   2 +-
 sound/soc/samsung/s3c24xx_uda134x.c                |   2 +-
 sound/soc/samsung/spdif.c                          |   1 -
 95 files changed, 1146 insertions(+), 734 deletions(-)
 rename arch/arm/{mach-exynos/include/mach/debug-macro.S => include/debug/exynos.S} (84%)
 rename arch/arm/{plat-samsung/include/plat/debug-macro.S => include/debug/samsung.S} (98%)
 rename arch/arm/plat-samsung/include/plat/regs-iic.h => drivers/i2c/busses/i2c-s3c2410.h (100%)
 rename arch/arm/plat-samsung/include/plat/regs-sdhci.h => drivers/mmc/host/sdhci-s3c-regs.h (100%)
 rename arch/arm/plat-samsung/include/plat/regs-onenand.h => drivers/mtd/onenand/samsung.h (98%)
 rename arch/arm/plat-samsung/include/plat/regs-rtc.h => drivers/rtc/rtc-s3c.h (97%)
 create mode 100644 include/linux/platform_data/mmc-sdhci-s3c.h
 create mode 100644 include/linux/platform_data/video_s3c.h
 create mode 100644 include/linux/serial_s3c.h
 rename {arch/arm/plat-samsung/include/plat => sound/soc/samsung}/regs-ac97.h (100%)
 rename {arch/arm/plat-samsung/include/plat => sound/soc/samsung}/regs-iis.h (100%)

-- 
1.8.1.2

Cc: stern at rowland.harvard.edu
Cc: a.zummo at towertech.it
Cc: ben-linux at fluff.org
Cc: cjb at laptop.org
Cc: dwmw2 at infradead.org
Cc: grant.likely at secretlab.ca
Cc: gregkh at linuxfoundation.org
Cc: jg1.han at samsung.com
Cc: john.stultz at linaro.org
Cc: broonie at opensource.wolfsonmicro.com
Cc: mchehab at redhat.com
Cc: mturquette at linaro.org
Cc: padma.kvr at gmail.com
Cc: thierry.reding at avionic-design.de
Cc: tglx at linutronix.de
Cc: t.figa at samsung.com
Cc: wsa at the-dreams.de
Cc: rui.zhang at intel.com
Cc: alsa-devel at alsa-project.org
Cc: linux-fbdev at vger.kernel.org
Cc: linux-i2c at vger.kernel.org
Cc: linux-media at vger.kernel.org
Cc: linux-mmc at vger.kernel.org
Cc: linux-mtd at lists.infradead.org
Cc: linux-pm at vger.kernel.org
Cc: linux-serial at vger.kernel.org
Cc: linux-usb at vger.kernel.org
Cc: rtc-linux at googlegroups.com
Cc: spi-devel-general at lists.sourceforge.net
.


From horms at verge.net.au  Wed Apr 10 20:09:33 2013
From: horms at verge.net.au (Simon Horman)
Date: Thu, 11 Apr 2013 09:09:33 +0900
Subject: [PATCH v2 02/13] ARM: convert arm/arm64 arch timer to use
 CLKSRC_OF init
In-Reply-To: <5165F30B.1040602@gmail.com>
References: <1364854883-5961-1-git-send-email-robherring2@gmail.com>
 <1364854883-5961-3-git-send-email-robherring2@gmail.com>
 <20130404055615.GI28297@verge.net.au> <5165F30B.1040602@gmail.com>
Message-ID: <20130411000933.GC1205@verge.net.au>

[ CC Magnus Damm ]

On Wed, Apr 10, 2013 at 06:17:31PM -0500, Rob Herring wrote:
> On 04/04/2013 12:56 AM, Simon Horman wrote:
> > On Mon, Apr 01, 2013 at 05:21:12PM -0500, Rob Herring wrote:
> >> From: Rob Herring <rob.herring at calxeda.com>
> >>
> >> This converts arm and arm64 to use CLKSRC_OF DT based initialization for
> >> the arch timer. A new function arch_timer_arch_init is added to allow for
> >> arch specific setup.
> >>
> >> This has a side effect of enabling sched_clock on omap5 and exynos5. There
> >> should not be any reason not to use the arch timers for sched_clock.
> > 
> > Would it be possible for you to either delay the removal of
> > shmobile_timer_init. In general I am in favour of the following
> > approach to wide changes such as this one:
> 
> I will simply change shmobile_timer_init to call clocksource_of_init
> rather than deleting it. That should keep the new users working and then
> it can be deleted latter.

Thanks.

> > 1. Add new feature
> > 2. Convert users to new feature
> > 3. Remove old feature.
> > 
> > If it is not possible to delay the removal of shmobile_timer_init could you
> > update your base such that you also remove its usage from the following
> > files:
> > 
> > arch/arm/mach-shmobile/board-kzm9g-reference.c
> > arch/arm/mach-shmobile/setup-r8a73a4.c
> > arch/arm/mach-shmobile/setup-r8a7779.c
> > arch/arm/mach-shmobile/board-lager.c
> > arch/arm/mach-shmobile/board-ape6evm.c
> > arch/arm/mach-shmobile/setup-r8a7778.c
> > arch/arm/mach-shmobile/board-marzen-reference.c
> > arch/arm/mach-shmobile/setup-r8a7790.c
> > arch/arm/mach-shmobile/board-bockw.c
> 
> Why so many boards? There's been prior discussions about whether to add
> DT into existing board files or start with a minimal DT board file and
> add to it. The fact that there are 14 mach desc's using
> shmobile_timer_init which is a function only used for DT and 17 DT mach
> descs total for shmobile tells me perhaps the latter approach is needed.
> 
> Either way, it is good to see progress on DT support in shmobile.

I've CCed Magnus who can answer that question better than I.
But in general I believe the answer is that because DT support for
many of the drivers that the boards and SoCs rely on isn't quite (or
in some cases at all) ready yet we need to bring things up using C code.

I realise that there are other approaches to this problem, but
this is the one we're taking at this time.

> 
> Rob
> 
> > The above files are all present in the arm-soc/next/boards2 branch
> > of the arm-soc tree which has pulled the renesas-boards3-for-v3.10 tag
> > of git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git.
> > I am happy for you use the later as a base if you wish.
> > 
> >> Signed-off-by: Rob Herring <rob.herring at calxeda.com>
> >> Cc: Russell King <linux at arm.linux.org.uk>
> >> Cc: Kukjin Kim <kgene.kim at samsung.com>
> >> Cc: Tony Lindgren <tony at atomide.com>
> >> Cc: Simon Horman <horms at verge.net.au>
> >> Cc: Magnus Damm <magnus.damm at gmail.com>
> >> Cc: Catalin Marinas <catalin.marinas at arm.com>
> >> Cc: Will Deacon <will.deacon at arm.com>
> >> Cc: John Stultz <john.stultz at linaro.org>
> >> Cc: Thomas Gleixner <tglx at linutronix.de>
> >> Cc: linux-samsung-soc at vger.kernel.org
> >> Cc: linux-omap at vger.kernel.org
> >> Cc: linux-sh at vger.kernel.org
> >> ---
> >>  arch/arm/include/asm/arch_timer.h            |   13 +------------
> >>  arch/arm/kernel/arch_timer.c                 |   17 +++--------------
> >>  arch/arm/mach-exynos/mach-exynos5-dt.c       |    1 -
> >>  arch/arm/mach-exynos/mct.c                   |    6 ------
> >>  arch/arm/mach-highbank/highbank.c            |    5 +----
> >>  arch/arm/mach-omap2/timer.c                  |    5 +----
> >>  arch/arm/mach-shmobile/board-kzm9d.c         |    1 -
> > 
> > I have boot tested the board-kzm9d change on the kzm9d board, it seems fine.
> > 
> >>  arch/arm/mach-shmobile/include/mach/common.h |    1 -
> >>  arch/arm/mach-shmobile/setup-emev2.c         |    1 -
> > 
> > I am not able to test the setup-emev2 portion properly at this time,
> > booting the kzm9d board without the board-kzm9d file seems broken without
> > your patch. However, your change seems reasonable to me.
> > 
> >>  arch/arm/mach-shmobile/setup-r8a7740.c       |    1 -
> > 
> > I am not able to test the setup-r8a7740 portion properly at this time,
> > booting the armadillo800eva board without the board-armadillo800eva file
> > seems broken without your patch. However, your change seems reasonable to
> > me.
> > 
> >>  arch/arm/mach-shmobile/setup-sh7372.c        |    1 -
> > 
> > I am not able to test the setup-sh7372 portion properly at this time,
> > booting the mackerel board without the board-mackerel file seems broken without
> > your patch. However, your change seems reasonable to me.
> > 
> >>  arch/arm/mach-shmobile/setup-sh73a0.c        |    1 -
> > 
> > I have boot tested the setup-sh73a0 change on the kzm9g board, it seems fine.
> > 
> > 
> > The tests above were made by merging
> > 
> > git://sources.calxeda.com/kernel/linux.git arm-timers
> > head commit: df3f518db302caf9fc0511917c5e9021037f6fcd
> > 	     ("devtree: add binding documentation for sp804")
> > 
> > and the renesas-next-20130403 tag of the renesas tree (URL above).
> > 
> >>  arch/arm/mach-shmobile/timer.c               |    6 ------
> >>  arch/arm/mach-vexpress/v2m.c                 |    7 ++-----
> >>  arch/arm/mach-virt/virt.c                    |    9 ---------
> >>  arch/arm64/include/asm/arch_timer.h          |    5 +++++
> >>  arch/arm64/kernel/time.c                     |    6 ++++--
> >>  drivers/clocksource/Kconfig                  |    1 +
> >>  drivers/clocksource/arm_arch_timer.c         |   23 +++++++++--------------
> >>  include/clocksource/arm_arch_timer.h         |    6 ------
> >>  20 files changed, 27 insertions(+), 89 deletions(-)
> >>
> >> diff --git a/arch/arm/include/asm/arch_timer.h b/arch/arm/include/asm/arch_timer.h
> >> index 7ade91d..7c1bfc0 100644
> >> --- a/arch/arm/include/asm/arch_timer.h
> >> +++ b/arch/arm/include/asm/arch_timer.h
> >> @@ -10,8 +10,7 @@
> >>  #include <clocksource/arm_arch_timer.h>
> >>  
> >>  #ifdef CONFIG_ARM_ARCH_TIMER
> >> -int arch_timer_of_register(void);
> >> -int arch_timer_sched_clock_init(void);
> >> +int arch_timer_arch_init(void);
> >>  
> >>  /*
> >>   * These register accessors are marked inline so the compiler can
> >> @@ -110,16 +109,6 @@ static inline void __cpuinit arch_counter_set_user_access(void)
> >>  
> >>  	asm volatile("mcr p15, 0, %0, c14, c1, 0" : : "r" (cntkctl));
> >>  }
> >> -#else
> >> -static inline int arch_timer_of_register(void)
> >> -{
> >> -	return -ENXIO;
> >> -}
> >> -
> >> -static inline int arch_timer_sched_clock_init(void)
> >> -{
> >> -	return -ENXIO;
> >> -}
> >>  #endif
> >>  
> >>  #endif
> >> diff --git a/arch/arm/kernel/arch_timer.c b/arch/arm/kernel/arch_timer.c
> >> index a7536d4..dc74048 100644
> >> --- a/arch/arm/kernel/arch_timer.c
> >> +++ b/arch/arm/kernel/arch_timer.c
> >> @@ -39,26 +39,15 @@ static void __init arch_timer_delay_timer_register(void)
> >>  	register_current_timer_delay(&arch_delay_timer);
> >>  }
> >>  
> >> -int __init arch_timer_of_register(void)
> >> -{
> >> -	int ret;
> >> -
> >> -	ret = arch_timer_init();
> >> -	if (ret)
> >> -		return ret;
> >> -
> >> -	arch_timer_delay_timer_register();
> >> -
> >> -	return 0;
> >> -}
> >> -
> >> -int __init arch_timer_sched_clock_init(void)
> >> +int __init arch_timer_arch_init(void)
> >>  {
> >>          u32 arch_timer_rate = arch_timer_get_rate();
> >>  
> >>  	if (arch_timer_rate == 0)
> >>  		return -ENXIO;
> >>  
> >> +	arch_timer_delay_timer_register();
> >> +
> >>  	/* Cache the sched_clock multiplier to save a divide in the hot path. */
> >>  	sched_clock_mult = NSEC_PER_SEC / arch_timer_rate;
> >>  	sched_clock_func = arch_timer_sched_clock;
> >> diff --git a/arch/arm/mach-exynos/mach-exynos5-dt.c b/arch/arm/mach-exynos/mach-exynos5-dt.c
> >> index acaeb14..4d97b43 100644
> >> --- a/arch/arm/mach-exynos/mach-exynos5-dt.c
> >> +++ b/arch/arm/mach-exynos/mach-exynos5-dt.c
> >> @@ -216,7 +216,6 @@ DT_MACHINE_START(EXYNOS5_DT, "SAMSUNG EXYNOS5 (Flattened Device Tree)")
> >>  	.map_io		= exynos5_dt_map_io,
> >>  	.init_machine	= exynos5_dt_machine_init,
> >>  	.init_late	= exynos_init_late,
> >> -	.init_time	= exynos4_timer_init,
> >>  	.dt_compat	= exynos5_dt_compat,
> >>  	.restart        = exynos5_restart,
> >>  	.reserve	= exynos5_reserve,
> >> diff --git a/arch/arm/mach-exynos/mct.c b/arch/arm/mach-exynos/mct.c
> >> index c9d6650..04aff6a 100644
> >> --- a/arch/arm/mach-exynos/mct.c
> >> +++ b/arch/arm/mach-exynos/mct.c
> >> @@ -21,7 +21,6 @@
> >>  #include <linux/percpu.h>
> >>  #include <linux/of.h>
> >>  
> >> -#include <asm/arch_timer.h>
> >>  #include <asm/localtimer.h>
> >>  
> >>  #include <plat/cpu.h>
> >> @@ -469,11 +468,6 @@ static void __init exynos4_timer_resources(void)
> >>  
> >>  void __init exynos4_timer_init(void)
> >>  {
> >> -	if (soc_is_exynos5440()) {
> >> -		arch_timer_of_register();
> >> -		return;
> >> -	}
> >> -
> >>  	if ((soc_is_exynos4210()) || (soc_is_exynos5250()))
> >>  		mct_int_type = MCT_INT_SPI;
> >>  	else
> >> diff --git a/arch/arm/mach-highbank/highbank.c b/arch/arm/mach-highbank/highbank.c
> >> index 76c1170..758150e 100644
> >> --- a/arch/arm/mach-highbank/highbank.c
> >> +++ b/arch/arm/mach-highbank/highbank.c
> >> @@ -15,6 +15,7 @@
> >>   */
> >>  #include <linux/clk.h>
> >>  #include <linux/clkdev.h>
> >> +#include <linux/clocksource.h>
> >>  #include <linux/dma-mapping.h>
> >>  #include <linux/io.h>
> >>  #include <linux/irq.h>
> >> @@ -28,7 +29,6 @@
> >>  #include <linux/amba/bus.h>
> >>  #include <linux/clk-provider.h>
> >>  
> >> -#include <asm/arch_timer.h>
> >>  #include <asm/cacheflush.h>
> >>  #include <asm/cputype.h>
> >>  #include <asm/smp_plat.h>
> >> @@ -118,9 +118,6 @@ static void __init highbank_timer_init(void)
> >>  	sp804_clocksource_and_sched_clock_init(timer_base + 0x20, "timer1");
> >>  	sp804_clockevents_init(timer_base, irq, "timer0");
> >>  
> >> -	arch_timer_of_register();
> >> -	arch_timer_sched_clock_init();
> >> -
> >>  	clocksource_of_init();
> >>  }
> >>  
> >> diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
> >> index 4fd8025..7dd6453 100644
> >> --- a/arch/arm/mach-omap2/timer.c
> >> +++ b/arch/arm/mach-omap2/timer.c
> >> @@ -46,7 +46,6 @@
> >>  #include <asm/smp_twd.h>
> >>  #include <asm/sched_clock.h>
> >>  
> >> -#include <asm/arch_timer.h>
> >>  #include "omap_hwmod.h"
> >>  #include "omap_device.h"
> >>  #include <plat/counter-32k.h>
> >> @@ -624,9 +623,7 @@ void __init omap5_realtime_timer_init(void)
> >>  	omap5_sync32k_timer_init();
> >>  	realtime_counter_init();
> >>  
> >> -	err = arch_timer_of_register();
> >> -	if (err)
> >> -		pr_err("%s: arch_timer_register failed %d\n", __func__, err);
> >> +        clocksource_of_init();
> >>  }
> >>  #endif /* CONFIG_SOC_OMAP5 */
> >>  
> >> diff --git a/arch/arm/mach-shmobile/board-kzm9d.c b/arch/arm/mach-shmobile/board-kzm9d.c
> >> index c254782..c016ccd 100644
> >> --- a/arch/arm/mach-shmobile/board-kzm9d.c
> >> +++ b/arch/arm/mach-shmobile/board-kzm9d.c
> >> @@ -90,6 +90,5 @@ DT_MACHINE_START(KZM9D_DT, "kzm9d")
> >>  	.init_irq	= emev2_init_irq,
> >>  	.init_machine	= kzm9d_add_standard_devices,
> >>  	.init_late	= shmobile_init_late,
> >> -	.init_time	= shmobile_timer_init,
> >>  	.dt_compat	= kzm9d_boards_compat_dt,
> >>  MACHINE_END
> >> diff --git a/arch/arm/mach-shmobile/include/mach/common.h b/arch/arm/mach-shmobile/include/mach/common.h
> >> index e48606d..5efc0f0 100644
> >> --- a/arch/arm/mach-shmobile/include/mach/common.h
> >> +++ b/arch/arm/mach-shmobile/include/mach/common.h
> >> @@ -2,7 +2,6 @@
> >>  #define __ARCH_MACH_COMMON_H
> >>  
> >>  extern void shmobile_earlytimer_init(void);
> >> -extern void shmobile_timer_init(void);
> >>  extern void shmobile_setup_delay(unsigned int max_cpu_core_mhz,
> >>  			 unsigned int mult, unsigned int div);
> >>  struct twd_local_timer;
> >> diff --git a/arch/arm/mach-shmobile/setup-emev2.c b/arch/arm/mach-shmobile/setup-emev2.c
> >> index 47662a5..4e38a66 100644
> >> --- a/arch/arm/mach-shmobile/setup-emev2.c
> >> +++ b/arch/arm/mach-shmobile/setup-emev2.c
> >> @@ -456,7 +456,6 @@ DT_MACHINE_START(EMEV2_DT, "Generic Emma Mobile EV2 (Flattened Device Tree)")
> >>  	.nr_irqs	= NR_IRQS_LEGACY,
> >>  	.init_irq	= irqchip_init,
> >>  	.init_machine	= emev2_add_standard_devices_dt,
> >> -	.init_time	= shmobile_timer_init,
> >>  	.dt_compat	= emev2_boards_compat_dt,
> >>  MACHINE_END
> >>  
> >> diff --git a/arch/arm/mach-shmobile/setup-r8a7740.c b/arch/arm/mach-shmobile/setup-r8a7740.c
> >> index 8b85d4d..104b474 100644
> >> --- a/arch/arm/mach-shmobile/setup-r8a7740.c
> >> +++ b/arch/arm/mach-shmobile/setup-r8a7740.c
> >> @@ -906,7 +906,6 @@ DT_MACHINE_START(R8A7740_DT, "Generic R8A7740 (Flattened Device Tree)")
> >>  	.init_irq	= r8a7740_init_irq,
> >>  	.handle_irq	= shmobile_handle_irq_intc,
> >>  	.init_machine	= r8a7740_add_standard_devices_dt,
> >> -	.init_time	= shmobile_timer_init,
> >>  	.dt_compat	= r8a7740_boards_compat_dt,
> >>  MACHINE_END
> >>  
> >> diff --git a/arch/arm/mach-shmobile/setup-sh7372.c b/arch/arm/mach-shmobile/setup-sh7372.c
> >> index 59c7146..5502d62 100644
> >> --- a/arch/arm/mach-shmobile/setup-sh7372.c
> >> +++ b/arch/arm/mach-shmobile/setup-sh7372.c
> >> @@ -1175,7 +1175,6 @@ DT_MACHINE_START(SH7372_DT, "Generic SH7372 (Flattened Device Tree)")
> >>  	.init_irq	= sh7372_init_irq,
> >>  	.handle_irq	= shmobile_handle_irq_intc,
> >>  	.init_machine	= sh7372_add_standard_devices_dt,
> >> -	.init_time	= shmobile_timer_init,
> >>  	.dt_compat	= sh7372_boards_compat_dt,
> >>  MACHINE_END
> >>  
> >> diff --git a/arch/arm/mach-shmobile/setup-sh73a0.c b/arch/arm/mach-shmobile/setup-sh73a0.c
> >> index bdab575..ea66316 100644
> >> --- a/arch/arm/mach-shmobile/setup-sh73a0.c
> >> +++ b/arch/arm/mach-shmobile/setup-sh73a0.c
> >> @@ -923,7 +923,6 @@ DT_MACHINE_START(SH73A0_DT, "Generic SH73A0 (Flattened Device Tree)")
> >>  	.nr_irqs	= NR_IRQS_LEGACY,
> >>  	.init_irq	= sh73a0_init_irq_dt,
> >>  	.init_machine	= sh73a0_add_standard_devices_dt,
> >> -	.init_time	= shmobile_timer_init,
> >>  	.dt_compat	= sh73a0_boards_compat_dt,
> >>  MACHINE_END
> >>  #endif /* CONFIG_USE_OF */
> >> diff --git a/arch/arm/mach-shmobile/timer.c b/arch/arm/mach-shmobile/timer.c
> >> index 3d16d4d..add2f15 100644
> >> --- a/arch/arm/mach-shmobile/timer.c
> >> +++ b/arch/arm/mach-shmobile/timer.c
> >> @@ -60,9 +60,3 @@ void __init shmobile_earlytimer_init(void)
> >>  {
> >>  	late_time_init = shmobile_late_time_init;
> >>  }
> >> -
> >> -void __init shmobile_timer_init(void)
> >> -{
> >> -	arch_timer_of_register();
> >> -	arch_timer_sched_clock_init();
> >> -}
> >> diff --git a/arch/arm/mach-vexpress/v2m.c b/arch/arm/mach-vexpress/v2m.c
> >> index d0ad789..6215717 100644
> >> --- a/arch/arm/mach-vexpress/v2m.c
> >> +++ b/arch/arm/mach-vexpress/v2m.c
> >> @@ -1,6 +1,7 @@
> >>  /*
> >>   * Versatile Express V2M Motherboard Support
> >>   */
> >> +#include <linux/clocksource.h>
> >>  #include <linux/device.h>
> >>  #include <linux/amba/bus.h>
> >>  #include <linux/amba/mmci.h>
> >> @@ -23,7 +24,6 @@
> >>  #include <linux/regulator/machine.h>
> >>  #include <linux/vexpress.h>
> >>  
> >> -#include <asm/arch_timer.h>
> >>  #include <asm/mach-types.h>
> >>  #include <asm/sizes.h>
> >>  #include <asm/mach/arch.h>
> >> @@ -446,10 +446,7 @@ static void __init v2m_dt_timer_init(void)
> >>  				irq_of_parse_and_map(node, 0));
> >>  	}
> >>  
> >> -	arch_timer_of_register();
> >> -
> >> -	if (arch_timer_sched_clock_init() != 0)
> >> -		versatile_sched_clock_init(vexpress_get_24mhz_clock_base(),
> >> +	versatile_sched_clock_init(vexpress_get_24mhz_clock_base(),
> >>  				24000000);
> >>  }
> >>  
> >> diff --git a/arch/arm/mach-virt/virt.c b/arch/arm/mach-virt/virt.c
> >> index 31666f6..adc0945 100644
> >> --- a/arch/arm/mach-virt/virt.c
> >> +++ b/arch/arm/mach-virt/virt.c
> >> @@ -23,21 +23,13 @@
> >>  #include <linux/of_platform.h>
> >>  #include <linux/smp.h>
> >>  
> >> -#include <asm/arch_timer.h>
> >>  #include <asm/mach/arch.h>
> >> -#include <asm/mach/time.h>
> >>  
> >>  static void __init virt_init(void)
> >>  {
> >>  	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
> >>  }
> >>  
> >> -static void __init virt_timer_init(void)
> >> -{
> >> -	WARN_ON(arch_timer_of_register() != 0);
> >> -	WARN_ON(arch_timer_sched_clock_init() != 0);
> >> -}
> >> -
> >>  static const char *virt_dt_match[] = {
> >>  	"linux,dummy-virt",
> >>  	NULL
> >> @@ -47,7 +39,6 @@ extern struct smp_operations virt_smp_ops;
> >>  
> >>  DT_MACHINE_START(VIRT, "Dummy Virtual Machine")
> >>  	.init_irq	= irqchip_init,
> >> -	.init_time	= virt_timer_init,
> >>  	.init_machine	= virt_init,
> >>  	.smp		= smp_ops(virt_smp_ops),
> >>  	.dt_compat	= virt_dt_match,
> >> diff --git a/arch/arm64/include/asm/arch_timer.h b/arch/arm64/include/asm/arch_timer.h
> >> index 91e2a6a..bf6ab242 100644
> >> --- a/arch/arm64/include/asm/arch_timer.h
> >> +++ b/arch/arm64/include/asm/arch_timer.h
> >> @@ -130,4 +130,9 @@ static inline u64 arch_counter_get_cntvct(void)
> >>  	return cval;
> >>  }
> >>  
> >> +static inline int arch_timer_arch_init(void)
> >> +{
> >> +	return 0;
> >> +}
> >> +
> >>  #endif
> >> diff --git a/arch/arm64/kernel/time.c b/arch/arm64/kernel/time.c
> >> index b0ef18d..a551f88 100644
> >> --- a/arch/arm64/kernel/time.c
> >> +++ b/arch/arm64/kernel/time.c
> >> @@ -32,6 +32,7 @@
> >>  #include <linux/timer.h>
> >>  #include <linux/irq.h>
> >>  #include <linux/delay.h>
> >> +#include <linux/clocksource.h>
> >>  
> >>  #include <clocksource/arm_arch_timer.h>
> >>  
> >> @@ -77,10 +78,11 @@ void __init time_init(void)
> >>  {
> >>  	u32 arch_timer_rate;
> >>  
> >> -	if (arch_timer_init())
> >> -		panic("Unable to initialise architected timer.\n");
> >> +	clocksource_of_init();
> >>  
> >>  	arch_timer_rate = arch_timer_get_rate();
> >> +	if (!arch_timer_rate)
> >> +		panic("Unable to initialise architected timer.\n");
> >>  
> >>  	/* Cache the sched_clock multiplier to save a divide in the hot path. */
> >>  	sched_clock_mult = NSEC_PER_SEC / arch_timer_rate;
> >> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
> >> index e507ab7..d98e7e1 100644
> >> --- a/drivers/clocksource/Kconfig
> >> +++ b/drivers/clocksource/Kconfig
> >> @@ -62,6 +62,7 @@ config CLKSRC_DBX500_PRCMU_SCHED_CLOCK
> >>  
> >>  config ARM_ARCH_TIMER
> >>  	bool
> >> +	select CLKSRC_OF if OF
> >>  
> >>  config CLKSRC_METAG_GENERIC
> >>  	def_bool y if METAG
> >> diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
> >> index d7ad425..122ff05 100644
> >> --- a/drivers/clocksource/arm_arch_timer.c
> >> +++ b/drivers/clocksource/arm_arch_timer.c
> >> @@ -337,22 +337,14 @@ out:
> >>  	return err;
> >>  }
> >>  
> >> -static const struct of_device_id arch_timer_of_match[] __initconst = {
> >> -	{ .compatible	= "arm,armv7-timer",	},
> >> -	{ .compatible	= "arm,armv8-timer",	},
> >> -	{},
> >> -};
> >> -
> >> -int __init arch_timer_init(void)
> >> +static void __init arch_timer_init(struct device_node *np)
> >>  {
> >> -	struct device_node *np;
> >>  	u32 freq;
> >>  	int i;
> >>  
> >> -	np = of_find_matching_node(NULL, arch_timer_of_match);
> >> -	if (!np) {
> >> -		pr_err("arch_timer: can't find DT node\n");
> >> -		return -ENODEV;
> >> +	if (arch_timer_get_rate()) {
> >> +		pr_warn("arch_timer: multiple nodes in dt, skipping\n");
> >> +		return;
> >>  	}
> >>  
> >>  	/* Try to determine the frequency from the device tree or CNTFRQ */
> >> @@ -378,7 +370,7 @@ int __init arch_timer_init(void)
> >>  		if (!arch_timer_ppi[PHYS_SECURE_PPI] ||
> >>  		    !arch_timer_ppi[PHYS_NONSECURE_PPI]) {
> >>  			pr_warn("arch_timer: No interrupt available, giving up\n");
> >> -			return -EINVAL;
> >> +			return;
> >>  		}
> >>  	}
> >>  
> >> @@ -387,5 +379,8 @@ int __init arch_timer_init(void)
> >>  	else
> >>  		arch_timer_read_counter = arch_counter_get_cntpct;
> >>  
> >> -	return arch_timer_register();
> >> +	arch_timer_register();
> >> +	arch_timer_arch_init();
> >>  }
> >> +CLOCKSOURCE_OF_DECLARE(armv7_arch_timer, "arm,armv7-timer", arch_timer_init);
> >> +CLOCKSOURCE_OF_DECLARE(armv8_arch_timer, "arm,armv8-timer", arch_timer_init);
> >> diff --git a/include/clocksource/arm_arch_timer.h b/include/clocksource/arm_arch_timer.h
> >> index 2603267..e6c9c4c 100644
> >> --- a/include/clocksource/arm_arch_timer.h
> >> +++ b/include/clocksource/arm_arch_timer.h
> >> @@ -31,18 +31,12 @@
> >>  
> >>  #ifdef CONFIG_ARM_ARCH_TIMER
> >>  
> >> -extern int arch_timer_init(void);
> >>  extern u32 arch_timer_get_rate(void);
> >>  extern u64 (*arch_timer_read_counter)(void);
> >>  extern struct timecounter *arch_timer_get_timecounter(void);
> >>  
> >>  #else
> >>  
> >> -static inline int arch_timer_init(void)
> >> -{
> >> -	return -ENXIO;
> >> -}
> >> -
> >>  static inline u32 arch_timer_get_rate(void)
> >>  {
> >>  	return 0;
> >> -- 
> >> 1.7.10.4
> >>
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> >> the body of a message to majordomo at vger.kernel.org
> >> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >>
> 


From mchehab at redhat.com  Wed Apr 10 20:13:54 2013
From: mchehab at redhat.com (Mauro Carvalho Chehab)
Date: Wed, 10 Apr 2013 21:13:54 -0300
Subject: [PATCH 11/30] [media] exynos: remove unnecessary header inclusions
In-Reply-To: <1365638712-1028578-12-git-send-email-arnd@arndb.de>
References: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
 <1365638712-1028578-12-git-send-email-arnd@arndb.de>
Message-ID: <20130410211354.397d5689@redhat.com>

Em Thu, 11 Apr 2013 02:04:53 +0200
Arnd Bergmann <arnd at arndb.de> escreveu:

> In multiplatform configurations, we cannot include headers
> provided by only the exynos platform. Fortunately a number
> of drivers that include those headers do not actually need
> them, so we can just remove the inclusions.
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Cc: linux-media at vger.kernel.org
> Cc: Mauro Carvalho Chehab <mchehab at redhat.com>

Acked-by: Mauro Carvalho Chehab <mchehab at redhat.com>
> ---
>  drivers/media/platform/exynos-gsc/gsc-regs.c | 1 -
>  drivers/media/platform/s5p-tv/sii9234_drv.c  | 3 ---
>  2 files changed, 4 deletions(-)
> 
> diff --git a/drivers/media/platform/exynos-gsc/gsc-regs.c b/drivers/media/platform/exynos-gsc/gsc-regs.c
> index 6f5b5a4..e22d147 100644
> --- a/drivers/media/platform/exynos-gsc/gsc-regs.c
> +++ b/drivers/media/platform/exynos-gsc/gsc-regs.c
> @@ -12,7 +12,6 @@
>  
>  #include <linux/io.h>
>  #include <linux/delay.h>
> -#include <mach/map.h>
>  
>  #include "gsc-core.h"
>  
> diff --git a/drivers/media/platform/s5p-tv/sii9234_drv.c b/drivers/media/platform/s5p-tv/sii9234_drv.c
> index d90d228..39b77d2 100644
> --- a/drivers/media/platform/s5p-tv/sii9234_drv.c
> +++ b/drivers/media/platform/s5p-tv/sii9234_drv.c
> @@ -23,9 +23,6 @@
>  #include <linux/regulator/machine.h>
>  #include <linux/slab.h>
>  
> -#include <mach/gpio.h>
> -#include <plat/gpio-cfg.h>
> -
>  #include <media/sii9234.h>
>  #include <media/v4l2-subdev.h>
>  


-- 

Cheers,
Mauro


From kmpark at infradead.org  Wed Apr 10 20:17:43 2013
From: kmpark at infradead.org (Kyungmin Park)
Date: Thu, 11 Apr 2013 09:17:43 +0900
Subject: [PATCH 02/30] ARM: exynos: prepare for sparse IRQ
In-Reply-To: <1365638712-1028578-3-git-send-email-arnd@arndb.de>
References: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
 <1365638712-1028578-3-git-send-email-arnd@arndb.de>
Message-ID: <CAH9JG2VC9EPnhij=VOrVOmhMHdJ_AfruT62weHALOE5e=ViFUw@mail.gmail.com>

On Thu, Apr 11, 2013 at 9:04 AM, Arnd Bergmann <arnd at arndb.de> wrote:
> When we enable CONFIG_SPARSE_IRQ, we have to set the value of NR_IRQS in
> the machine_desc for legacy IRQ domains, and any file referring to the
> number of interrupts or a specific number must include the mach/irqs.h
> header file explicitly.

It's really wanted feature.
>
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Acked-by: Kyungmin Park <kyungmin.park at samsung.com>
> ---
>  arch/arm/mach-exynos/dev-uart.c          | 1 +
>  arch/arm/mach-exynos/include/mach/irqs.h | 5 ++++-
>  arch/arm/mach-exynos/mach-armlex4210.c   | 2 ++
>  arch/arm/mach-exynos/mach-exynos4-dt.c   | 3 +++
>  arch/arm/mach-exynos/mach-exynos5-dt.c   | 2 ++
>  arch/arm/mach-exynos/mach-nuri.c         | 2 ++
>  arch/arm/mach-exynos/mach-origen.c       | 2 ++
>  arch/arm/mach-exynos/mach-smdk4x12.c     | 2 ++
>  arch/arm/mach-exynos/mach-smdkv310.c     | 3 +++
>  arch/arm/plat-samsung/irq-vic-timer.c    | 1 +
>  arch/arm/plat-samsung/pm.c               | 1 +
>  arch/arm/plat-samsung/s5p-irq.c          | 1 +
>  12 files changed, 24 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-exynos/dev-uart.c b/arch/arm/mach-exynos/dev-uart.c
> index 7c42f4b..c48aff0 100644
> --- a/arch/arm/mach-exynos/dev-uart.c
> +++ b/arch/arm/mach-exynos/dev-uart.c
> @@ -20,6 +20,7 @@
>  #include <asm/mach/irq.h>
>  #include <mach/hardware.h>
>  #include <mach/map.h>
> +#include <mach/irqs.h>
>
>  #include <plat/devs.h>
>
> diff --git a/arch/arm/mach-exynos/include/mach/irqs.h b/arch/arm/mach-exynos/include/mach/irqs.h
> index 35fe6d5..c72f59d 100644
> --- a/arch/arm/mach-exynos/include/mach/irqs.h
> +++ b/arch/arm/mach-exynos/include/mach/irqs.h
> @@ -467,7 +467,10 @@
>  #define IRQ_TIMER_BASE                 (IRQ_GPIO_END + 64)
>
>  /* Set the default NR_IRQS */
> +#define EXYNOS_NR_IRQS                 (IRQ_TIMER_BASE + IRQ_TIMER_COUNT)
>
> -#define NR_IRQS                                (IRQ_TIMER_BASE + IRQ_TIMER_COUNT)
> +#ifndef CONFIG_SPARSE_IRQ
> +#define NR_IRQS                                EXYNOS_NR_IRQS
> +#endif
>
>  #endif /* __ASM_ARCH_IRQS_H */
> diff --git a/arch/arm/mach-exynos/mach-armlex4210.c b/arch/arm/mach-exynos/mach-armlex4210.c
> index 2c23b65..a503e02 100644
> --- a/arch/arm/mach-exynos/mach-armlex4210.c
> +++ b/arch/arm/mach-exynos/mach-armlex4210.c
> @@ -25,6 +25,7 @@
>  #include <plat/regs-srom.h>
>  #include <plat/sdhci.h>
>
> +#include <mach/irqs.h>
>  #include <mach/map.h>
>
>  #include "common.h"
> @@ -196,6 +197,7 @@ static void __init armlex4210_machine_init(void)
>  MACHINE_START(ARMLEX4210, "ARMLEX4210")
>         /* Maintainer: Alim Akhtar <alim.akhtar at samsung.com> */
>         .atag_offset    = 0x100,
> +       .nr_irqs        = EXYNOS_NR_IRQS,
>         .smp            = smp_ops(exynos_smp_ops),
>         .init_irq       = exynos4_init_irq,
>         .map_io         = armlex4210_map_io,
> diff --git a/arch/arm/mach-exynos/mach-exynos4-dt.c b/arch/arm/mach-exynos/mach-exynos4-dt.c
> index b9ed834..5f23682 100644
> --- a/arch/arm/mach-exynos/mach-exynos4-dt.c
> +++ b/arch/arm/mach-exynos/mach-exynos4-dt.c
> @@ -20,6 +20,8 @@
>
>  #include <asm/mach/arch.h>
>  #include <plat/mfc.h>
> +#include <mach/irqs.h>
> +
>
>  #include "common.h"
>
> @@ -54,6 +56,7 @@ static void __init exynos4_reserve(void)
>  }
>  DT_MACHINE_START(EXYNOS4210_DT, "Samsung Exynos4 (Flattened Device Tree)")
>         /* Maintainer: Thomas Abraham <thomas.abraham at linaro.org> */
> +       .nr_irqs        = EXYNOS_NR_IRQS,
>         .smp            = smp_ops(exynos_smp_ops),
>         .init_irq       = exynos4_init_irq,
>         .map_io         = exynos4_dt_map_io,
> diff --git a/arch/arm/mach-exynos/mach-exynos5-dt.c b/arch/arm/mach-exynos/mach-exynos5-dt.c
> index 753b94f..8b7456a 100644
> --- a/arch/arm/mach-exynos/mach-exynos5-dt.c
> +++ b/arch/arm/mach-exynos/mach-exynos5-dt.c
> @@ -16,6 +16,7 @@
>  #include <linux/clocksource.h>
>
>  #include <asm/mach/arch.h>
> +#include <mach/irqs.h>
>  #include <mach/regs-pmu.h>
>
>  #include <plat/cpu.h>
> @@ -76,6 +77,7 @@ static void __init exynos5_reserve(void)
>
>  DT_MACHINE_START(EXYNOS5_DT, "SAMSUNG EXYNOS5 (Flattened Device Tree)")
>         /* Maintainer: Kukjin Kim <kgene.kim at samsung.com> */
> +       .nr_irqs        = EXYNOS_NR_IRQS,
>         .init_irq       = exynos5_init_irq,
>         .smp            = smp_ops(exynos_smp_ops),
>         .map_io         = exynos5_dt_map_io,
> diff --git a/arch/arm/mach-exynos/mach-nuri.c b/arch/arm/mach-exynos/mach-nuri.c
> index 0c10852..fbae331 100644
> --- a/arch/arm/mach-exynos/mach-nuri.c
> +++ b/arch/arm/mach-exynos/mach-nuri.c
> @@ -53,6 +53,7 @@
>  #include <plat/fimc-core.h>
>  #include <plat/camport.h>
>
> +#include <mach/irqs.h>
>  #include <mach/map.h>
>
>  #include "common.h"
> @@ -1376,6 +1377,7 @@ static void __init nuri_machine_init(void)
>  MACHINE_START(NURI, "NURI")
>         /* Maintainer: Kyungmin Park <kyungmin.park at samsung.com> */
>         .atag_offset    = 0x100,
> +       .nr_irqs        = EXYNOS_NR_IRQS,
>         .smp            = smp_ops(exynos_smp_ops),
>         .init_irq       = exynos4_init_irq,
>         .map_io         = nuri_map_io,
> diff --git a/arch/arm/mach-exynos/mach-origen.c b/arch/arm/mach-exynos/mach-origen.c
> index f662345..a3ee06a 100644
> --- a/arch/arm/mach-exynos/mach-origen.c
> +++ b/arch/arm/mach-exynos/mach-origen.c
> @@ -46,6 +46,7 @@
>  #include <plat/hdmi.h>
>
>  #include <mach/map.h>
> +#include <mach/irqs.h>
>
>  #include <drm/exynos_drm.h>
>  #include "common.h"
> @@ -811,6 +812,7 @@ static void __init origen_machine_init(void)
>  MACHINE_START(ORIGEN, "ORIGEN")
>         /* Maintainer: JeongHyeon Kim <jhkim at insignal.co.kr> */
>         .atag_offset    = 0x100,
> +       .nr_irqs        = EXYNOS_NR_IRQS,
>         .smp            = smp_ops(exynos_smp_ops),
>         .init_irq       = exynos4_init_irq,
>         .map_io         = origen_map_io,
> diff --git a/arch/arm/mach-exynos/mach-smdk4x12.c b/arch/arm/mach-exynos/mach-smdk4x12.c
> index 184faa3..3ebd5e4 100644
> --- a/arch/arm/mach-exynos/mach-smdk4x12.c
> +++ b/arch/arm/mach-exynos/mach-smdk4x12.c
> @@ -39,6 +39,7 @@
>  #include <plat/regs-serial.h>
>  #include <plat/sdhci.h>
>
> +#include <mach/irqs.h>
>  #include <mach/map.h>
>
>  #include <drm/exynos_drm.h>
> @@ -384,6 +385,7 @@ MACHINE_START(SMDK4412, "SMDK4412")
>         /* Maintainer: Kukjin Kim <kgene.kim at samsung.com> */
>         /* Maintainer: Changhwan Youn <chaos.youn at samsung.com> */
>         .atag_offset    = 0x100,
> +       .nr_irqs        = EXYNOS_NR_IRQS,
>         .smp            = smp_ops(exynos_smp_ops),
>         .init_irq       = exynos4_init_irq,
>         .map_io         = smdk4x12_map_io,
> diff --git a/arch/arm/mach-exynos/mach-smdkv310.c b/arch/arm/mach-exynos/mach-smdkv310.c
> index ee815a7..5527a28 100644
> --- a/arch/arm/mach-exynos/mach-smdkv310.c
> +++ b/arch/arm/mach-exynos/mach-smdkv310.c
> @@ -43,6 +43,7 @@
>  #include <plat/clock.h>
>  #include <plat/hdmi.h>
>
> +#include <mach/irqs.h>
>  #include <mach/map.h>
>
>  #include <drm/exynos_drm.h>
> @@ -420,6 +421,7 @@ MACHINE_START(SMDKV310, "SMDKV310")
>         /* Maintainer: Kukjin Kim <kgene.kim at samsung.com> */
>         /* Maintainer: Changhwan Youn <chaos.youn at samsung.com> */
>         .atag_offset    = 0x100,
> +       .nr_irqs        = EXYNOS_NR_IRQS,
>         .smp            = smp_ops(exynos_smp_ops),
>         .init_irq       = exynos4_init_irq,
>         .map_io         = smdkv310_map_io,
> @@ -432,6 +434,7 @@ MACHINE_END
>  MACHINE_START(SMDKC210, "SMDKC210")
>         /* Maintainer: Kukjin Kim <kgene.kim at samsung.com> */
>         .atag_offset    = 0x100,
> +       .nr_irqs        = EXYNOS_NR_IRQS,
>         .smp            = smp_ops(exynos_smp_ops),
>         .init_irq       = exynos4_init_irq,
>         .map_io         = smdkv310_map_io,
> diff --git a/arch/arm/plat-samsung/irq-vic-timer.c b/arch/arm/plat-samsung/irq-vic-timer.c
> index 5d205e7..0fceb42 100644
> --- a/arch/arm/plat-samsung/irq-vic-timer.c
> +++ b/arch/arm/plat-samsung/irq-vic-timer.c
> @@ -20,6 +20,7 @@
>  #include <linux/io.h>
>
>  #include <mach/map.h>
> +#include <mach/irqs.h>
>  #include <plat/cpu.h>
>  #include <plat/irq-vic-timer.h>
>  #include <plat/regs-timer.h>
> diff --git a/arch/arm/plat-samsung/pm.c b/arch/arm/plat-samsung/pm.c
> index 002b147..53210ec 100644
> --- a/arch/arm/plat-samsung/pm.c
> +++ b/arch/arm/plat-samsung/pm.c
> @@ -27,6 +27,7 @@
>  #include <plat/regs-serial.h>
>  #include <mach/regs-clock.h>
>  #include <mach/regs-irq.h>
> +#include <mach/irqs.h>
>  #include <asm/irq.h>
>
>  #include <plat/pm.h>
> diff --git a/arch/arm/plat-samsung/s5p-irq.c b/arch/arm/plat-samsung/s5p-irq.c
> index 103e371..ff1a760 100644
> --- a/arch/arm/plat-samsung/s5p-irq.c
> +++ b/arch/arm/plat-samsung/s5p-irq.c
> @@ -15,6 +15,7 @@
>  #include <linux/io.h>
>  #include <linux/irqchip/arm-vic.h>
>
> +#include <mach/irqs.h>
>  #include <mach/map.h>
>  #include <plat/regs-timer.h>
>  #include <plat/cpu.h>
> --
> 1.8.1.2
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From kmpark at infradead.org  Wed Apr 10 20:18:32 2013
From: kmpark at infradead.org (Kyungmin Park)
Date: Thu, 11 Apr 2013 09:18:32 +0900
Subject: [PATCH 15/30] mtd: onenand/samsung: make regs-onenand.h file local
In-Reply-To: <1365638712-1028578-16-git-send-email-arnd@arndb.de>
References: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
 <1365638712-1028578-16-git-send-email-arnd@arndb.de>
Message-ID: <CAH9JG2UK2KuX6c7YL8Mva+T+HmAH8F39oUbrK9eZkMO1KzPKFg@mail.gmail.com>

Thanks Arnd.

On Thu, Apr 11, 2013 at 9:04 AM, Arnd Bergmann <arnd at arndb.de> wrote:
> Nothing uses the NAND register definitions other than the
> actual driver, so we can move the header file into the
> same local directory, which lets us build it in a multiplatform
> configuration.
>
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Cc: linux-mtd at lists.infradead.org
> Cc: Kyungmin Park <kyungmin.park at samsung.com>
Acked-by: Kyungmin Park <kyungmin.park at samsung.com>
> Cc: David Woodhouse <dwmw2 at infradead.org>
> ---
>  drivers/mtd/onenand/samsung.c                                         | 4 ++--
>  .../include/plat/regs-onenand.h => drivers/mtd/onenand/samsung.h      | 2 --
>  2 files changed, 2 insertions(+), 4 deletions(-)
>  rename arch/arm/plat-samsung/include/plat/regs-onenand.h => drivers/mtd/onenand/samsung.h (98%)
>
> diff --git a/drivers/mtd/onenand/samsung.c b/drivers/mtd/onenand/samsung.c
> index 33f2a8f..2cf7408 100644
> --- a/drivers/mtd/onenand/samsung.c
> +++ b/drivers/mtd/onenand/samsung.c
> @@ -23,11 +23,11 @@
>  #include <linux/mtd/partitions.h>
>  #include <linux/dma-mapping.h>
>  #include <linux/interrupt.h>
> +#include <linux/io.h>
>
>  #include <asm/mach/flash.h>
> -#include <plat/regs-onenand.h>
>
> -#include <linux/io.h>
> +#include "samsung.h"
>
>  enum soc_type {
>         TYPE_S3C6400,
> diff --git a/arch/arm/plat-samsung/include/plat/regs-onenand.h b/drivers/mtd/onenand/samsung.h
> similarity index 98%
> rename from arch/arm/plat-samsung/include/plat/regs-onenand.h
> rename to drivers/mtd/onenand/samsung.h
> index 930ea8b..c4a80e6 100644
> --- a/arch/arm/plat-samsung/include/plat/regs-onenand.h
> +++ b/drivers/mtd/onenand/samsung.h
> @@ -11,8 +11,6 @@
>  #ifndef __SAMSUNG_ONENAND_H__
>  #define __SAMSUNG_ONENAND_H__
>
> -#include <mach/hardware.h>
> -
>  /*
>   * OneNAND Controller
>   */
> --
> 1.8.1.2
>
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/


From jason at lakedaemon.net  Wed Apr 10 20:33:01 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Wed, 10 Apr 2013 20:33:01 -0400
Subject: [PATCHv2 08/10] arm: kirkwood: convert QNAP TS219 to use DT
 for the PCIe interface
In-Reply-To: <1365632436-25367-9-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1365632436-25367-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1365632436-25367-9-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <20130411003301.GH28693@titan.lakedaemon.net>

On Thu, Apr 11, 2013 at 12:20:34AM +0200, Thomas Petazzoni wrote:
> Now that the PCIe mvebu driver is usable on Kirkwood, use it instead
> of the legacy PCIe code, since it allows to describe the PCIe
> interfaces in the Device Tree.
> 
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> ---
>  arch/arm/boot/dts/kirkwood-ts219.dtsi |    7 +++++++
>  arch/arm/mach-kirkwood/board-ts219.c  |   10 ----------
>  2 files changed, 7 insertions(+), 10 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/kirkwood-ts219.dtsi b/arch/arm/boot/dts/kirkwood-ts219.dtsi
> index 64ea27c..341e1d8 100644
> --- a/arch/arm/boot/dts/kirkwood-ts219.dtsi
> +++ b/arch/arm/boot/dts/kirkwood-ts219.dtsi
> @@ -74,5 +74,12 @@
>  			status = "okay";
>  			nr-ports = <2>;
>  		};
> +		pcie-controller {
> +			status = "okay";
> +
> +			pcie at 1,0 {
> +				status = "okay";
> +			};
> +		};
>  	};
>  };
> diff --git a/arch/arm/mach-kirkwood/board-ts219.c b/arch/arm/mach-kirkwood/board-ts219.c
> index acb0187..4695d5f 100644
> --- a/arch/arm/mach-kirkwood/board-ts219.c
> +++ b/arch/arm/mach-kirkwood/board-ts219.c
> @@ -41,13 +41,3 @@ void __init qnap_dt_ts219_init(void)
>  
>  	pm_power_off = qnap_tsx1x_power_off;
>  }
> -
> -/* FIXME: Will not work with DT. Maybe use MPP40_GPIO? */
> -static int __init ts219_pci_init(void)
> -{
> -	if (machine_is_ts219())
> -		kirkwood_pcie_init(KW_PCIE0);
> -
> -	return 0;
> -}
> -subsys_initcall(ts219_pci_init);

This doesn't look right.  There are two dts files, one for 6281, and one
for 6282...

thx,

Jason.


From horms at verge.net.au  Wed Apr 10 20:51:56 2013
From: horms at verge.net.au (Simon Horman)
Date: Thu, 11 Apr 2013 09:51:56 +0900
Subject: [PATCH v3 0/9] Reorganize R8A7779/Marzen USB code
In-Reply-To: <20130410090543.GB25890@verge.net.au>
References: <201304100226.08967.sergei.shtylyov@cogentembedded.com>
 <20130410044923.GD10044@verge.net.au>
 <20130410085033.GL7983@arwen.pp.htv.fi>
 <20130410090543.GB25890@verge.net.au>
Message-ID: <20130411005155.GA18530@verge.net.au>

On Wed, Apr 10, 2013 at 06:05:43PM +0900, Simon Horman wrote:
> On Wed, Apr 10, 2013 at 11:50:33AM +0300, Felipe Balbi wrote:
> > Hi,
> > 
> > On Wed, Apr 10, 2013 at 01:49:23PM +0900, Simon Horman wrote:
> > > On Wed, Apr 10, 2013 at 02:26:08AM +0400, Sergei Shtylyov wrote:
> > > > Hello.
> > > > 
> > > >    Here's the set of 9 patches against the Simon Horman's 'renesas.git' repo,
> > > > 'renesas-next-20130410' tag.  It was created to fix the shortcomings in the
> > > > R8A7779/Marzen USB platform code and R8A7779 USB common PHY driver, and so
> > > > spans both arch/arm/mach-shmobile/ and drivers/usb/ subtrees (some patches have
> > > > to touch both subtrees). The patches were conceived with the complete
> > > > bisectability goal in mind.
> > > > 
> > > > [1/9] ARM: shmobile: Marzen: move USB EHCI, OHCI, and PHY devices to R8A7779 code
> > > > [2/9] ehci-platform: add pre_setup() method to platform data
> > > > [3/9] ARM: shmobile: R8A7779: setup EHCI internal buffer
> > > > [4/9] rcar-phy: remove EHCI internal buffer setup
> > > > [5/9] ARM: shmobile: R8A7779: remove USB PHY 2nd memory resource
> > > > [6/9] rcar-phy: correct base address
> > > > [7/9] rcar-phy: add platform data
> > > > [8/9] ARM: shmobile: Marzen: pass platform data to USB PHY device
> > > > [9/9] rcar-phy: handle platform data
> > > > 
> > > >    I'm not sure thru which tree this patchset should be merged, however it turns
> > > > out that it's too late now to push it thru Felipe Balbi's USB tree for 3.10
> > > > (which would have been most convenient probably), and it's probably too late to
> > > > merge thru Simon's tree for 3.10 too. So it now have to be postponed to 3.11,
> > > > unfortunately...
> > > 
> > > Felipe, how would you prefer to handle this?
> > > I'm happy for you to take it or to take it myself.
> > 
> > please take it yourself, just keep in mind there will be conflicts, I
> > will go over the patches now and give my Acked-by so you can queue them
> > up.
> 
> Thanks

Sergei, it looks like patches 1-7 are clear.
Do you want me to start queueing them up.
Or would you rather wait for the issue with patch 6 to be resolved?


From horms at verge.net.au  Wed Apr 10 20:53:25 2013
From: horms at verge.net.au (Simon Horman)
Date: Thu, 11 Apr 2013 09:53:25 +0900
Subject: [PATCH 0/4] Add USB support to R8A7778/BOCK-W
In-Reply-To: <51655F27.90008@cogentembedded.com>
References: <201304100247.22615.sergei.shtylyov@cogentembedded.com>
 <51655F27.90008@cogentembedded.com>
Message-ID: <20130411005324.GG1205@verge.net.au>

On Wed, Apr 10, 2013 at 04:46:31PM +0400, Sergei Shtylyov wrote:
> Hello.
> 
> On 10-04-2013 2:47, Sergei Shtylyov wrote:
> 
> >    Here's the set of 4 patches against the Simon Horman's 'renesas.git' repo,
> >'renesas-next-20130410' tag.
> 
>    Sorry, forgot to mention that it is atop the previous
> R8A7779/Marzen USB patchset.

Thanks, got it.


From sboyd at codeaurora.org  Wed Apr 10 21:00:11 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Wed, 10 Apr 2013 18:00:11 -0700
Subject: [PATCH] ARM: msm: Fix uncompess.h tx underrun check
Message-ID: <1365642011-4664-1-git-send-email-sboyd@codeaurora.org>

Bit 3 of the SR register is set if there is a tx underrun. If
this bit isn't set, we should loop on the tx ready bit until we
can transmit again. Otherwise we should skip the loop and
transmit immediately. The code is doing the opposite though,
checking for an underrun and then looping on the tx ready bit
causing us to never loop on the tx read bit when the tx buffer
may not be ready.

This doesn't seem to affect my 8960 device too often, but in some
cases I see a lost character or two from the decompressor prints.
This also matches what we do in the assembly in debug-macro.S.

Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---

Nobody has noticed this so far so I'm ok waiting for 3.10 on this one. Also
it doesn't improve stability (debug feature) so I don't see a reason to send
it to stable.

 arch/arm/mach-msm/include/mach/uncompress.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-msm/include/mach/uncompress.h b/arch/arm/mach-msm/include/mach/uncompress.h
index fa97a10..9432487 100644
--- a/arch/arm/mach-msm/include/mach/uncompress.h
+++ b/arch/arm/mach-msm/include/mach/uncompress.h
@@ -37,7 +37,7 @@ static void putc(int c)
 	 * Wait for TX_READY to be set; but skip it if we have a
 	 * TX underrun.
 	 */
-	if (UART_DM_SR & 0x08)
+	if (!(UART_DM_SR & 0x08))
 		while (!(UART_DM_ISR & 0x80))
 			cpu_relax();
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From josephl at nvidia.com  Wed Apr 10 21:01:40 2013
From: josephl at nvidia.com (Joseph Lo)
Date: Thu, 11 Apr 2013 09:01:40 +0800
Subject: [PATCH 13/18] ARM: tegra2: cpuidle: use init/exit common routine
In-Reply-To: <1365603743-5618-14-git-send-email-daniel.lezcano@linaro.org>
References: <1365603743-5618-1-git-send-email-daniel.lezcano@linaro.org>
 <1365603743-5618-14-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1365642100.1806.5.camel@jlo-ubuntu-64.nvidia.com>

On Wed, 2013-04-10 at 22:22 +0800, Daniel Lezcano wrote:
> Remove the duplicated code and use the cpuidle common code for initialization.
> 
> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
> ---
>  arch/arm/mach-tegra/cpuidle-tegra20.c |   33 +--------------------------------
>  1 file changed, 1 insertion(+), 32 deletions(-)
> 
> diff --git a/arch/arm/mach-tegra/cpuidle-tegra20.c b/arch/arm/mach-tegra/cpuidle-tegra20.c
> index f1f6ac4..d6c2ba6 100644
> --- a/arch/arm/mach-tegra/cpuidle-tegra20.c
> +++ b/arch/arm/mach-tegra/cpuidle-tegra20.c
> @@ -70,8 +70,6 @@ static struct cpuidle_driver tegra_idle_driver = {
>  	.safe_state_index = 0,
>  };
>  
> -static DEFINE_PER_CPU(struct cpuidle_device, tegra_idle_device);
> -
>  #ifdef CONFIG_PM_SLEEP
>  #ifdef CONFIG_SMP
>  static void __iomem *pmc = IO_ADDRESS(TEGRA_PMC_BASE);
> @@ -220,34 +218,5 @@ static int tegra20_idle_lp2_coupled(struct cpuidle_device *dev,
>  
>  int __init tegra20_cpuidle_init(void)
>  {
> -	int ret;
> -	unsigned int cpu;
> -	struct cpuidle_device *dev;
> -	struct cpuidle_driver *drv = &tegra_idle_driver;
> -
> -#ifdef CONFIG_PM_SLEEP
> -	tegra_tear_down_cpu = tegra20_tear_down_cpu;
> -#endif

Hi Daniel,

Please keep these 3 lines above, just like you did for Tegra30.

Thanks,
Joseph

> +	return cpuidle_register(&tegra_idle_driver, cpu_possible_mask);
>  }




From cjb at laptop.org  Wed Apr 10 21:06:18 2013
From: cjb at laptop.org (Chris Ball)
Date: Wed, 10 Apr 2013 21:06:18 -0400
Subject: [PATCH 09/30] mmc: sdhci-s3c: remove platform dependencies
In-Reply-To: <1365638712-1028578-10-git-send-email-arnd@arndb.de> (Arnd
 Bergmann's message of "Thu, 11 Apr 2013 02:04:51 +0200")
References: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
 <1365638712-1028578-10-git-send-email-arnd@arndb.de>
Message-ID: <877gk9j2ph.fsf@octavius.laptop.org>

Hi,

On Wed, Apr 10 2013, Arnd Bergmann wrote:
> plat/regs-sdhci.h is not used anywhere but in the sdhci-s3c
> driver, so it can become a local file there and all other
> inclusions removed.
>
> plat/sdhci.h is used only to define the platform devices,
> and with the exception of the platform_data structure not
> needed by the driver, so we can split out the platform_data
> definition instead and leave the rest to platform code.
>
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Cc: linux-mmc at vger.kernel.org
> Cc: Chris Ball <cjb at laptop.org>

Acked-by: Chris Ball <cjb at laptop.org>

- Chris.
-- 
Chris Ball   <cjb at laptop.org>   <http://printf.net/>
One Laptop Per Child


From eduardo.valentin at ti.com  Wed Apr 10 21:19:01 2013
From: eduardo.valentin at ti.com (Eduardo Valentin)
Date: Wed, 10 Apr 2013 21:19:01 -0400
Subject: [PATCH 14/30] thermal/exynos: remove unnecessary header inclusions
In-Reply-To: <1365638712-1028578-15-git-send-email-arnd@arndb.de>
References: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
 <1365638712-1028578-15-git-send-email-arnd@arndb.de>
Message-ID: <51660F85.4000105@ti.com>

Rui, Arnd,

As agreed in [1], I will be helping on the thermal maintenance.

On 10-04-2013 20:04, Arnd Bergmann wrote:
> In multiplatform configurations, we cannot include headers
> provided by only the exynos platform. Fortunately a number
> of drivers that include those headers do not actually need
> them, so we can just remove the inclusions.
>
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Cc: linux-pm at vger.kernel.org
> Cc: Zhang Rui <rui.zhang at intel.com>

This patch looks good to me.

You can add my:
Acked-by: Eduardo Valentin <eduardo.valentin at ti.com>


[1] - http://marc.info/?l=linux-pm&m=136560509922173&w=2


From jon-hunter at ti.com  Wed Apr 10 21:46:59 2013
From: jon-hunter at ti.com (Jon Hunter)
Date: Wed, 10 Apr 2013 20:46:59 -0500
Subject: [PATCH v2 11/11] ARM: OMAP2+: omap_hwmod: Don't call
 _init_mpu_rt_base if no sysc
In-Reply-To: <1363699857-5505-12-git-send-email-santosh.shilimkar@ti.com>
References: <1363699857-5505-1-git-send-email-santosh.shilimkar@ti.com>
 <1363699857-5505-12-git-send-email-santosh.shilimkar@ti.com>
Message-ID: <51661613.4070405@ti.com>


On 03/19/2013 08:30 AM, Santosh Shilimkar wrote:
> OMAP hwmod layer does the reset of the IPs in early code so that
> we have SOC in sane state. To do the soft-reset, it needs to ioremap()
> the ip address space to be able to write to sysconfig registers.
> 
> But there are few hwmod which doesn't have sysconfig registers and hence
> no need to ioremap() them in early init code.
> 
> So this patch makes prevet calling the _init_mpu_rt_base() conditional
> based on sysc availability.
> 
> Cc: Benoit Cousson <b-cousson at ti.com>
> 
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
> ---
>  arch/arm/mach-omap2/omap_hwmod.c |    3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
> index 4501038..1a1f0a4 100644
> --- a/arch/arm/mach-omap2/omap_hwmod.c
> +++ b/arch/arm/mach-omap2/omap_hwmod.c
> @@ -2449,7 +2449,8 @@ static int __init _init(struct omap_hwmod *oh, void *data)
>  	if (oh->_state != _HWMOD_STATE_REGISTERED)
>  		return 0;
>  
> -	_init_mpu_rt_base(oh, NULL);
> +	if (oh->class->sysc)
> +		_init_mpu_rt_base(oh, NULL);
>  
>  	r = _init_clocks(oh, NULL);
>  	if (IS_ERR_VALUE(r)) {

I have not looked into why, but this commit is triggering the following
panic on am335x-evm. I don't see this on the omap platforms only am335x. 

Adding Vaibhav ...

Jon

[    2.059957] Unhandled fault: external abort on non-linefetch (0x1028) at 0xf9e35034
[    2.068067] Internal error: : 1028 [#1] SMP ARM
[    2.072856] Modules linked in:
[    2.076102] CPU: 0    Not tainted  (3.9.0-rc3-00051-g4a98c2d #774)
[    2.082651] PC is at omap_wdt_disable.isra.5+0xc/0x60
[    2.087988] LR is at omap_wdt_probe+0x170/0x200
[    2.092774] pc : [<c04447b8>]    lr : [<c0444b00>]    psr: 60000113
[    2.092774] sp : de05de68  ip : 00000001  fp : 00000000
[    2.104888] r10: dd2243c0  r9 : 00000000  r8 : c1312c38
[    2.110404] r7 : dd2403d0  r6 : de0ae3c0  r5 : de0e7c10  r4 : dd181210
[    2.117293] r3 : f9e35034  r2 : 00000000  r1 : 04a00000  r0 : f9e35000
[    2.124185] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
[    2.131901] Control: 10c5387d  Table: 80004019  DAC: 00000017
[    2.137967] Process swapper/0 (pid: 1, stack limit = 0xde05c240)
[    2.144308] Stack: (0xde05de68 to 0xde05e000)
[    2.148915] de60:   
[    2.151231] de80: c0db1f98 c07afe40 c07893f8 c0364284 c036426c c0362ef4 de0e7c10 c0db1f98
[    2.159870] dea0: de0e7c44 00000000 00000000 c036309c c0db1f98 c0363008 00000000 c03615e4
[    2.168509] dec0: de01e2a8 de0cdb10 c0db1f98 c0da0b38 dd240440 c036256c c069606c 00000000
[    2.177148] dee0: de051d40 c0db1f98 de05c000 c0dbdd00 00000000 00000000 c07afe40 c07893f8
[    2.185786] df00: 00000000 c0363568 c03642ac c0793ec4 de05c000 c0dbdd00 00000000 000000a3
[    2.194424] df20: c07893f8 c00086a4 c07306d8 c0731108 c1722d6b c07893f8 00000001 c1722d77
[    2.203061] df40: c06f1144 00000000 00000006 00000006 00000001 c0793ec4 00000006 c0793ea4
[    2.211699] df60: c0dbdd00 000000a3 c07afe40 c075f1c4 00000000 c075f8f8 00000006 00000006
[    2.220338] df80: c075f1c4 00000000 00000000 c0547dec 00000000 00000000 00000000 00000000
[    2.228975] dfa0: 00000000 c0547df4 00000000 c0013e50 00000000 00000000 00000000 00000000
[    2.237615] dfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[    2.246252] dfe0: 00000000 00000000 00000000 00000000 00000013 00000000 fbffffeb ff3fbefe
[    2.254904] [<c04447b8>] (omap_wdt_disable.isra.5+0xc/0x60) from [<c0444b00>] (omap_wdt_probe+0x170/0x200)
[    2.265118] [<c0444b00>] (omap_wdt_probe+0x170/0x200) from [<c0364284>] (platform_drv_probe+0x18/0x1c)
[    2.274955] [<c0364284>] (platform_drv_probe+0x18/0x1c) from [<c0362ef4>] (driver_probe_device+0x108/0x21c)
[    2.285248] [<c0362ef4>] (driver_probe_device+0x108/0x21c) from [<c036309c>] (__driver_attach+0x94/0x98)
[    2.295263] [<c036309c>] (__driver_attach+0x94/0x98) from [<c03615e4>] (bus_for_each_dev+0x54/0x88)
[    2.304822] [<c03615e4>] (bus_for_each_dev+0x54/0x88) from [<c036256c>] (bus_add_driver+0xdc/0x29c)
[    2.314381] [<c036256c>] (bus_add_driver+0xdc/0x29c) from [<c0363568>] (driver_register+0x78/0x190)
[    2.323941] [<c0363568>] (driver_register+0x78/0x190) from [<c00086a4>] (do_one_initcall+0x34/0x178)
[    2.333605] [<c00086a4>] (do_one_initcall+0x34/0x178) from [<c075f8f8>] (kernel_init_freeable+0xfc/0x1c4)
[    2.343728] [<c075f8f8>] (kernel_init_freeable+0xfc/0x1c4) from [<c0547df4>] (kernel_init+0x8/0xe4)
[    2.353300] [<c0547df4>] (kernel_init+0x8/0xe4) from [<c0013e50>] (ret_from_fork+0x14/0x24)
[    2.362124] Code: e8bd80f8 e59f3050 e5803048 e2803034 (e5902034) 
[    2.368631] ---[ end trace 63f90a88f45b89ae ]---
[    2.373734] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
 


From haojian.zhuang at linaro.org  Wed Apr 10 22:13:06 2013
From: haojian.zhuang at linaro.org (Haojian Zhuang)
Date: Thu, 11 Apr 2013 10:13:06 +0800
Subject: [PATCH 1/3] ARM: pxa: remove cpu_is_xxx in gpio driver
In-Reply-To: <CACRpkdbr=VT8g03S=KUMUReJe+6aU0n1Pfy2nk=XErKfYojwBw@mail.gmail.com>
References: <1365556707-9159-1-git-send-email-haojian.zhuang@linaro.org>
 <CACRpkdbr=VT8g03S=KUMUReJe+6aU0n1Pfy2nk=XErKfYojwBw@mail.gmail.com>
Message-ID: <CAD6h2NTjQGyqqFwAHHimXmvCbrm60rssrP1Ys4SSa4TymrXyJA@mail.gmail.com>

On 11 April 2013 04:59, Linus Walleij <linus.walleij at linaro.org> wrote:
> On Wed, Apr 10, 2013 at 3:18 AM, Haojian Zhuang
> <haojian.zhuang at linaro.org> wrote:
>
>> Avoid to use cpu_is_xxx() in pxa gpio driver. Use platform_device_id
>> to identify the difference.
>>
>> Signed-off-by: Haojian Zhuang <haojian.zhuang at linaro.org>
>
> Acked-by: Linus Walleij <linus.walleij at linaro.org>
>
> I guess this will go through some PXA/MMP tree?
>
> Yours,
> Linus Walleij

Yes, I hope it go through PXA tree.

Regards
Haojian


From haojian.zhuang at gmail.com  Wed Apr 10 22:30:30 2013
From: haojian.zhuang at gmail.com (Haojian Zhuang)
Date: Thu, 11 Apr 2013 10:30:30 +0800
Subject: [GIT PULL][for 3.10] pull request from armsoc/pxa branch in pxa git
 tree
Message-ID: <CAN1soZzqag7W3Yz07-2KV-4BVd1eN0dYMiFhsg6+NEc1hRZKjg@mail.gmail.com>

Hi Arnd & Olof,

Please help to merge armsoc/pxa branch from pxa git tree.

Regards
Haojian

The following changes since commit 31880c37c11e28cb81c70757e38392b42e695dc6:

  Linux 3.9-rc6 (2013-04-07 20:49:54 -0700)

are available in the git repository at:

  git://github.com/hzhuang1/linux.git armsoc/pxa

for you to fetch changes up to 0a43cd3b1cc1b7e1dfc461cf55b414610d038769:

  ARM: pxa: move debug uart code (2013-04-11 10:02:31 +0800)

----------------------------------------------------------------
Haojian Zhuang (5):
      ARM: pxa: remove cpu_is_xxx in gpio driver
      ARM: pxa: move PXA_GPIO_TO_IRQ macro
      ARM: mmp: add more compatible names in gpio driver
      ARM: pxa: select PXA935 on saar & tavorevb
      ARM: pxa: move debug uart code

 Documentation/devicetree/bindings/gpio/mrvl-gpio.txt |    7 +++--
 arch/arm/Kconfig.debug                               |    9 ++++++
 arch/arm/boot/dts/mmp2.dtsi                          |    2 +-
 arch/arm/boot/dts/pxa168.dtsi                        |    2 +-
 arch/arm/boot/dts/pxa910.dtsi                        |    2 +-
 arch/arm/include/debug/pxa.S                         |   33
++++++++++++++++++++
 arch/arm/mach-mmp/aspenite.c                         |    7 +++++
 arch/arm/mach-mmp/avengers_lite.c                    |    7 +++++
 arch/arm/mach-mmp/brownstone.c                       |    7 +++++
 arch/arm/mach-mmp/clock-mmp2.c                       |    2 +-
 arch/arm/mach-mmp/clock-pxa168.c                     |    2 +-
 arch/arm/mach-mmp/clock-pxa910.c                     |    2 +-
 arch/arm/mach-mmp/flint.c                            |    7 +++++
 arch/arm/mach-mmp/gplugd.c                           |    7 +++++
 arch/arm/mach-mmp/include/mach/debug-macro.S         |   30 ------------------
 arch/arm/mach-mmp/jasper.c                           |    8 +++++
 arch/arm/mach-mmp/mmp-dt.c                           |    4 +--
 arch/arm/mach-mmp/mmp2-dt.c                          |    2 +-
 arch/arm/mach-mmp/mmp2.c                             |    2 +-
 arch/arm/mach-mmp/pxa168.c                           |    2 +-
 arch/arm/mach-mmp/pxa910.c                           |    2 +-
 arch/arm/mach-mmp/tavorevb.c                         |    7 +++++
 arch/arm/mach-mmp/teton_bga.c                        |    7 +++++
 arch/arm/mach-mmp/ttc_dkb.c                          |    7 +++++
 arch/arm/mach-pxa/Kconfig                            |    2 ++
 arch/arm/mach-pxa/devices.c                          |   29 +++++++++++++++--
 arch/arm/mach-pxa/devices.h                          |    6 +++-
 arch/arm/mach-pxa/include/mach/debug-macro.S         |   23 --------------
 arch/arm/mach-pxa/pxa25x.c                           |   11 +++++--
 arch/arm/mach-pxa/pxa27x.c                           |    7 +++--
 arch/arm/mach-pxa/pxa3xx.c                           |   23 +++++++++++---
 arch/arm/mach-pxa/pxa930.c                           |   17 ++++++++--
 drivers/clk/mmp/clk-mmp2.c                           |    2 +-
 drivers/clk/mmp/clk-pxa168.c                         |    2 +-
 drivers/clk/mmp/clk-pxa910.c                         |    2 +-
 drivers/gpio/gpio-pxa.c                              |  151
+++++++++++++++++++++++++++++++++++++++++++++++++++++++---------------------------------
 include/linux/gpio-pxa.h                             |    1 +
 37 files changed, 302 insertions(+), 141 deletions(-)
 create mode 100644 arch/arm/include/debug/pxa.S
 delete mode 100644 arch/arm/mach-mmp/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-pxa/include/mach/debug-macro.S


From jhbird.choi at samsung.com  Wed Apr 10 22:37:17 2013
From: jhbird.choi at samsung.com (Jonghwan Choi)
Date: Thu, 11 Apr 2013 11:37:17 +0900
Subject: [PATCH] KVM: ARM: Fix wrong address in comment
Message-ID: <000801ce365d$7b9bce70$72d36b50$%choi@samsung.com>

hyp_hvc vector offset should be 0x14 and hyp_svc vector offset should be
0x8.

Signed-off-by: Jonghwan Choi <jhbird.choi at samsung.com>
---
 arch/arm/kvm/interrupts.S |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/kvm/interrupts.S b/arch/arm/kvm/interrupts.S
index 8ca87ab..a8e0c2d 100644
--- a/arch/arm/kvm/interrupts.S
+++ b/arch/arm/kvm/interrupts.S
@@ -235,9 +235,9 @@ ENTRY(kvm_call_hyp)
  * instruction is issued since all traps are disabled when running the host
  * kernel as per the Hyp-mode initialization at boot time.
  *
- * HVC instructions cause a trap to the vector page + offset 0x18 (see
hyp_hvc
+ * HVC instructions cause a trap to the vector page + offset 0x14 (see
hyp_hvc
  * below) when the HVC instruction is called from SVC mode (i.e. a guest or
the
- * host kernel) and they cause a trap to the vector page + offset 0xc when
HVC
+ * host kernel) and they cause a trap to the vector page + offset 0x8 when
HVC
  * instructions are called from within Hyp-mode.
  *
  * Hyp-ABI: Calling HYP-mode functions from host (in SVC mode):
-- 
1.7.9.5



From horms at verge.net.au  Wed Apr 10 22:46:39 2013
From: horms at verge.net.au (Simon Horman)
Date: Thu, 11 Apr 2013 11:46:39 +0900
Subject: [PATCH 11/18] ARM: shmobile: cpuidle: use init/exit common routine
In-Reply-To: <1365603743-5618-12-git-send-email-daniel.lezcano@linaro.org>
References: <1365603743-5618-1-git-send-email-daniel.lezcano@linaro.org>
 <1365603743-5618-12-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <20130411024639.GD21037@verge.net.au>

On Wed, Apr 10, 2013 at 04:22:16PM +0200, Daniel Lezcano wrote:
> Remove the duplicated code and use the cpuidle common code for initialization.
> 
> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>

Acked-by: Simon Horman <horms+renesas at verge.net.au>

> ---
>  arch/arm/mach-shmobile/cpuidle.c |   10 +---------
>  1 file changed, 1 insertion(+), 9 deletions(-)
> 
> diff --git a/arch/arm/mach-shmobile/cpuidle.c b/arch/arm/mach-shmobile/cpuidle.c
> index d671ae9..0afeb5c 100644
> --- a/arch/arm/mach-shmobile/cpuidle.c
> +++ b/arch/arm/mach-shmobile/cpuidle.c
> @@ -16,7 +16,6 @@
>  #include <asm/cpuidle.h>
>  #include <asm/io.h>
>  
> -static struct cpuidle_device shmobile_cpuidle_dev;
>  static struct cpuidle_driver shmobile_cpuidle_default_driver = {
>  	.name			= "shmobile_cpuidle",
>  	.owner			= THIS_MODULE,
> @@ -34,12 +33,5 @@ void __init shmobile_cpuidle_set_driver(struct cpuidle_driver *drv)
>  
>  int __init shmobile_cpuidle_init(void)
>  {
> -	struct cpuidle_device *dev = &shmobile_cpuidle_dev;
> -
> -	cpuidle_register_driver(cpuidle_drv);
> -
> -	dev->state_count = cpuidle_drv->state_count;
> -	cpuidle_register_device(dev);
> -
> -	return 0;
> +	return cpuidle_register(cpuidle_drv, NULL);
>  }
> -- 
> 1.7.9.5
> 


From sboyd at codeaurora.org  Wed Apr 10 22:52:52 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Wed, 10 Apr 2013 19:52:52 -0700
Subject: [PATCH 1/4] Documentation: Add memory mapped ARM architected
 timer binding
In-Reply-To: <20130410101336.GB8799@e106331-lin.cambridge.arm.com>
References: <1365474623-29181-1-git-send-email-sboyd@codeaurora.org>
 <1365474623-29181-2-git-send-email-sboyd@codeaurora.org>
 <20130409090843.GS23725@e106331-lin.cambridge.arm.com>
 <516444FE.2080200@codeaurora.org>
 <20130410101336.GB8799@e106331-lin.cambridge.arm.com>
Message-ID: <51662584.6070906@codeaurora.org>

On 04/10/13 03:13, Mark Rutland wrote:
>>>> +
>>>> +- #size-cells : Must be 1.
>>>> +
>>>> +- ranges : Indicates parent and child bus address space are the same.
>>>> +
>>> Similarly, what if someone wants to write a more complex mapping for some
>>> reason?
>>>
>>> We should be able to handle it if we use the standard accessors.
>> Maybe I should just leave this part out? They are standard DT properties
>> so I could assume DT writers know what to do.
> I'd be happy with that. It may be worth describing them as "as necessary" or
> something to that effect.

Ok. I added this and removed the property descriptions:

Note that #address-cells, #size-cells, and ranges shall be present to ensure
the CPU can address a frame's registers.

> I can see why we need to specify secure/non-secure, but I'm not sure why we
> need to specify hyp/user/kernel usage. Could we not leave this up to the kernel
> to figure out?
>
> A basic overveiew for those that don't know about the memory mapped timers:
>
> * There's one control frame CNTCTLBase. Some registers in this frame are only
>   available for secure accesses, including CNTNSAR which sets whether the
>   counter frames are accessible from the non-secure side.
>
> * There are up to 8 timer frames, which have their own CNTVOFF and
>   physical/virtual timers. Each frame CNTBaseN is duplicated at CNTPL0BaseN
>   with CNTVOFF and CNTPL0ACR (which controls PL0 accesses) inaccessible.
>
> I can see that we might have frames/registers we can't access (if we were
> booted on the non-secure side), but I can't see anything limiting whether we
> use a frame for kernel/hyp/user beyond that. Have I missed something?
>
> Could we not have something like the following for each frame:
>
> frame0 {
> 	frame-id = <0>;
> 	status = "disabled"; /* booted NS, secure firmware has not enabled access */
> 	reg = <0x... 0x1000>, /* CNTBase0 */
> 	      <0x... 0x1000>; /* CNTPL0Base0 */
> };
>

I don't think you're missing anything. Technically the second view is
not always implemented though. Using the status property should be
sufficient I think.

>> Also to get the frame number, I was thinking maybe we should expand the
>> reg property to have two address cells. Then we could have reg = <0
>> 0xf0001000 0x1000>.
> We could do that, but then you definitely need a more complex ranges property,
> and additional parsing code to handle grabbing it out of the reg property. I
> can't see what it buys us.

Ok. It would mandate node names like "frame at 0", "frame at 1", but I'll drop
the idea unless someone else finds it useful.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation



From horms at verge.net.au  Wed Apr 10 23:09:13 2013
From: horms at verge.net.au (Simon Horman)
Date: Thu, 11 Apr 2013 12:09:13 +0900
Subject: [PATCH 1/2] ARM: r8a7740: Add interim sh-eth device name to
 clocks list
In-Reply-To: <20130109020647.GB6496@verge.net.au>
References: <1355851359-8871-1-git-send-email-hechtb+renesas@gmail.com>
 <1355851359-8871-2-git-send-email-hechtb+renesas@gmail.com>
 <20130109020647.GB6496@verge.net.au>
Message-ID: <20130411030913.GA13456@verge.net.au>

On Wed, Jan 09, 2013 at 11:06:47AM +0900, Simon Horman wrote:
> On Tue, Dec 18, 2012 at 06:22:38PM +0100, Bastian Hecht wrote:
> > When we use the ethernet device via DT setup, we need to add it
> > to a lookup list until this is properly handled later in a DT-only
> > fashion.
> 
> Thanks, looks good.
> I will apply this.

Apparently I forgot to actually do that.
I have done so now, it is queued up for v3.11 in the soc-r8a7740 branch.


From tgih.jun at samsung.com  Wed Apr 10 23:13:09 2013
From: tgih.jun at samsung.com (Seungwon Jeon)
Date: Thu, 11 Apr 2013 12:13:09 +0900
Subject: [PATCH v4] mmc: dw_mmc: let device core setup the default pin
 configuration
In-Reply-To: <CAD=FV=WyPbkYvq9udPzQtVnaXZR3jzXTPnBrrdxpUuX3CZT=Og@mail.gmail.com>
References: <1365487186-4587-1-git-send-email-thomas.abraham@linaro.org>
 <CAD=FV=VJ-ykDNqYKQ=fqxeOD6bRNLW02VT4bjsRHRAuXLcCpQQ@mail.gmail.com>
 <CAJuYYwQT=povqiutVHXkF5jxTAnjpwTMQ5G0Z6xKGnnM7qYADQ@mail.gmail.com>
 <CAD=FV=UddWM=yc5N9=jwbMDpZ7Bpg7o3Z714CnBSg=iHhmPxWw@mail.gmail.com>
 <CAD=FV=WyPbkYvq9udPzQtVnaXZR3jzXTPnBrrdxpUuX3CZT=Og@mail.gmail.com>
Message-ID: <001101ce3662$7ecb9850$7c62c8f0$%jun@samsung.com>

On Wednesday, April 10, 2013, Doug Anderson wrote:
> Thomas,
> 
> On Wed, Apr 10, 2013 at 6:56 AM, Doug Anderson <dianders at chromium.org> wrote:
> > On Wed, Apr 10, 2013 at 5:48 AM, Thomas Abraham
> > <thomas.abraham at linaro.org> wrote:
> >> The call to regulator_enable() is prior to the call to mmc_add_host().
> >> Hence, call to mmc_fre_host is not required in this case. So the above
> >> change should be right.
> >
> > Are you sure that mmc_free_host() is the opposite of mmc_add_host()
> > and not mmc_alloc_host()?
> >
> > I'll double-check myself in a few hours when I'm in front of a computer.
> 
> OK, I double checked and I'm still convinced that the free is needed
> because we've already called mmc_alloc_host().  Current code always
> makes sure to free when it returns an error and that seems right to
> me.
mmc_alloc_host corresponds to mmc_free_host. And mmc_add_host matches
with mmc_remove_host. Let's focus on mmc_alloc_host.
mmc_alloc_host is called prior to regulator_enable.
So, if regulator_enable is failed, call of mmc_free_host makes sense.

Thanks,
Seungwon Jeon
> 
> -Doug
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



From zhangwm at marvell.com  Wed Apr 10 23:37:40 2013
From: zhangwm at marvell.com (Neil Zhang)
Date: Thu, 11 Apr 2013 11:37:40 +0800
Subject: [PATCH 1/4] ARM: mmp: add wakeup function for ICU
In-Reply-To: <1365651463-11502-1-git-send-email-zhangwm@marvell.com>
References: <1365651463-11502-1-git-send-email-zhangwm@marvell.com>
Message-ID: <1365651463-11502-2-git-send-email-zhangwm@marvell.com>

From: Chao Xie <chao.xie at marvell.com>

PXA988 will use GIC as its interrupt controller, and ICU is used as wakeup
logic. When AP subsystem is powered off, GIC will lose its context, the
PMU will need ICU to wakeup the AP subsystem.
When ICU works as wakeup logic, there is no need to know intc-nr-irqs,
change the corresponding code.

Signed-off-by: Chao Xie <chao.xie at marvell.com>
Signed-off-by: Neil Zhang <zhangwm at marvell.com>
---
 .../devicetree/bindings/arm/mrvl/intc.txt          |    9 ++++
 arch/arm/mach-mmp/irq.c                            |   51 ++++++++++++++++----
 2 files changed, 50 insertions(+), 10 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/mrvl/intc.txt b/Documentation/devicetree/bindings/arm/mrvl/intc.txt
index 8b53273..58c0e74 100644
--- a/Documentation/devicetree/bindings/arm/mrvl/intc.txt
+++ b/Documentation/devicetree/bindings/arm/mrvl/intc.txt
@@ -15,6 +15,8 @@ Required properties:
 - interrupt-controller : Identifies the node as an interrupt controller.
 - #interrupt-cells : Specifies the number of cells needed to encode an
   interrupt source.
+- mrvl,intc-wakeup : Specifies the address and value for global mask in the
+  interrupt controller.
 - mrvl,intc-nr-irqs : Specifies the number of interrupts in the interrupt
   controller.
 - mrvl,clr-mfp-irq : Specifies the interrupt that needs to clear MFP edge
@@ -39,6 +41,13 @@ Example:
 		mrvl,intc-nr-irqs = <2>;
 	};
 
+	intc: interrupt-controller at d4282000 {
+		compatible = "mrvl,mmp-intc";
+		reg = <0xd4282000 0x1000>;
+		mrvl,intc-wakeup = <0x114 0x3
+		                    0x144 0x3>;
+	};
+
 * Marvell Orion Interrupt controller
 
 Required properties
diff --git a/arch/arm/mach-mmp/irq.c b/arch/arm/mach-mmp/irq.c
index 3c71246..b8df948 100644
--- a/arch/arm/mach-mmp/irq.c
+++ b/arch/arm/mach-mmp/irq.c
@@ -16,6 +16,7 @@
 #include <linux/init.h>
 #include <linux/irq.h>
 #include <linux/irqdomain.h>
+#include <linux/irqchip/arm-gic.h>
 #include <linux/io.h>
 #include <linux/ioport.h>
 #include <linux/of_address.h>
@@ -57,6 +58,7 @@ struct mmp_intc_conf {
 void __iomem *mmp_icu_base;
 static struct icu_chip_data icu_data[MAX_ICU_NR];
 static int max_icu_nr;
+static bool mmp_icu_wakeup;
 
 extern void mmp2_clear_pmic_int(void);
 
@@ -91,8 +93,11 @@ static void icu_mask_irq(struct irq_data *d)
 	int hwirq;
 	u32 r;
 
-	hwirq = d->irq - data->virq_base;
-	if (data == &icu_data[0]) {
+	if (mmp_icu_wakeup)
+		hwirq = d->hwirq;
+	else
+		hwirq = d->irq - data->virq_base;
+	if (data == &icu_data[0] || mmp_icu_wakeup) {
 		r = readl_relaxed(mmp_icu_base + (hwirq << 2));
 		r &= ~data->conf_mask;
 		r |= data->conf_disable;
@@ -110,8 +115,11 @@ static void icu_unmask_irq(struct irq_data *d)
 	int hwirq;
 	u32 r;
 
-	hwirq = d->irq - data->virq_base;
-	if (data == &icu_data[0]) {
+	if (mmp_icu_wakeup)
+		hwirq = d->hwirq;
+	else
+		hwirq = d->irq - data->virq_base;
+	if (data == &icu_data[0] || mmp_icu_wakeup) {
 		r = readl_relaxed(mmp_icu_base + (hwirq << 2));
 		r &= ~data->conf_mask;
 		r |= data->conf_enable;
@@ -415,6 +423,8 @@ void __init mmp_dt_irq_init(void)
 	const struct of_device_id *of_id;
 	struct mmp_intc_conf *conf;
 	int nr_irqs, irq_base, ret, irq;
+	const __be32 *wakeup_reg;
+	int size, i;
 
 	node = of_find_matching_node(NULL, intc_ids);
 	if (!node) {
@@ -424,18 +434,39 @@ void __init mmp_dt_irq_init(void)
 	of_id = of_match_node(intc_ids, node);
 	conf = of_id->data;
 
-	ret = of_property_read_u32(node, "mrvl,intc-nr-irqs", &nr_irqs);
-	if (ret) {
-		pr_err("Not found mrvl,intc-nr-irqs property\n");
-		return;
-	}
-
 	mmp_icu_base = of_iomap(node, 0);
 	if (!mmp_icu_base) {
 		pr_err("Failed to get interrupt controller register\n");
 		return;
 	}
 
+	/* ICU is only used as wake up logic. */
+	wakeup_reg = of_get_property(node, "mrvl,intc-wakeup", &size);
+	if (wakeup_reg) {
+		mmp_icu_wakeup = 1;
+		size /= sizeof(*wakeup_reg);
+		i = 0;
+		/* disable the global irq/fiq in icu for all cores. */
+		while (i < size) {
+			unsigned offset, val;
+
+			offset = be32_to_cpup(wakeup_reg + i++);
+			val = be32_to_cpup(wakeup_reg + i++);
+			writel_relaxed(val, mmp_icu_base + offset);
+		}
+
+		gic_arch_extn.irq_mask = icu_mask_irq;
+		gic_arch_extn.irq_unmask = icu_unmask_irq;
+
+		return;
+	}
+
+	ret = of_property_read_u32(node, "mrvl,intc-nr-irqs", &nr_irqs);
+	if (ret) {
+		pr_err("Not found mrvl,intc-nr-irqs property\n");
+		return;
+	}
+
 	irq_base = irq_alloc_descs(-1, 0, nr_irqs - NR_IRQS_LEGACY, 0);
 	if (irq_base < 0) {
 		pr_err("Failed to allocate IRQ numbers\n");
-- 
1.7.4.1



From zhangwm at marvell.com  Wed Apr 10 23:39:07 2013
From: zhangwm at marvell.com (Neil Zhang)
Date: Thu, 11 Apr 2013 11:39:07 +0800
Subject: [PATCH 4/4] ARM: mmp: add SMP support for pxa988
Message-ID: <1365651547-11583-1-git-send-email-zhangwm@marvell.com>

Add SMP support for pxa988.

Signed-off-by: Neil Zhang <zhangwm at marvell.com>
Signed-off-by: Chao Xie <chao.xie at marvell.com>
---
 arch/arm/mach-mmp/Makefile  |    4 +
 arch/arm/mach-mmp/common.h  |    2 +
 arch/arm/mach-mmp/headsmp.S |  104 ++++++++++++++++++++++++++
 arch/arm/mach-mmp/mmpx-dt.c |    1 +
 arch/arm/mach-mmp/platsmp.c |  170 +++++++++++++++++++++++++++++++++++++++++++
 arch/arm/mach-mmp/reset.c   |   66 +++++++++++++++++
 arch/arm/mach-mmp/reset.h   |   29 +++++++
 7 files changed, 376 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/mach-mmp/headsmp.S
 create mode 100644 arch/arm/mach-mmp/platsmp.c
 create mode 100644 arch/arm/mach-mmp/reset.c
 create mode 100644 arch/arm/mach-mmp/reset.h

diff --git a/arch/arm/mach-mmp/Makefile b/arch/arm/mach-mmp/Makefile
index b60065f..e7b6173 100644
--- a/arch/arm/mach-mmp/Makefile
+++ b/arch/arm/mach-mmp/Makefile
@@ -9,6 +9,10 @@ obj-$(CONFIG_CPU_PXA168)	+= pxa168.o
 obj-$(CONFIG_CPU_PXA910)	+= pxa910.o
 obj-$(CONFIG_CPU_MMP2)		+= mmp2.o sram.o
 
+ifeq ($(CONFIG_SMP),y)
+obj-$(CONFIG_CPU_PXA988)	+= platsmp.o headsmp.o reset.o
+endif
+
 ifeq ($(CONFIG_COMMON_CLK), )
 obj-y				+= clock.o
 obj-$(CONFIG_CPU_PXA168)	+= clock-pxa168.o
diff --git a/arch/arm/mach-mmp/common.h b/arch/arm/mach-mmp/common.h
index 8c9b510..7496cd0 100644
--- a/arch/arm/mach-mmp/common.h
+++ b/arch/arm/mach-mmp/common.h
@@ -1,5 +1,7 @@
 #define ARRAY_AND_SIZE(x)	(x), ARRAY_SIZE(x)
 
+extern struct smp_operations mmp_smp_ops;
+
 extern void timer_init(int irq);
 
 extern void __init icu_init_irq(void);
diff --git a/arch/arm/mach-mmp/headsmp.S b/arch/arm/mach-mmp/headsmp.S
new file mode 100644
index 0000000..2b6177e
--- /dev/null
+++ b/arch/arm/mach-mmp/headsmp.S
@@ -0,0 +1,104 @@
+/*
+ * linux/arch/arm/mach-mmp/headsmp.S
+ *
+ * Copyright (C) 2012 Marvell, Inc.
+ *
+ * Author: Neil Zhang <zhangwm at marvell.com>
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+#include <linux/linkage.h>
+#include <linux/init.h>
+#include <asm/memory.h>
+#include <asm/cache.h>
+#include <asm/assembler.h>
+#include <mach/addr-map.h>
+
+	__CPUINIT
+
+/*
+ * Marvell specific entry point for secondary CPUs.
+ * The secondary kernel init calls v7_flush_dcache_all before it enables
+ * the L1; however, the L1 comes out of reset in an undefined state, so
+ * the clean + invalidate performed by v7_flush_dcache_all causes a bunch
+ * of cache lines with uninitialized data and uninitialized tags to get
+ * written out to memory, which does really unpleasant things to the main
+ * processor.  We fix this by performing an invalidate, rather than a
+ * clean + invalidate for secondary core, before jumping into the kernel.
+ *
+ * This funciton is cloned from arch/arm/mach-tegra/headsmp.S, and needs
+ * to be called for both secondary cores startup and primary core resume
+ * procedures.
+ */
+	.align L1_CACHE_SHIFT
+
+
+/*
+ * PXA specific entry point for secondary CPUs.  This provides
+ * a "holding pen" into which all secondary cores are held until we're
+ * ready for them to initialise.
+ */
+ENTRY(mmp_secondary_startup)
+	mrc	p15, 0, r0, c0, c0, 5
+	and	r0, r0, #15
+	adr	r4, 1f
+	ldmia	r4, {r5, r6}
+	sub	r4, r4, r5
+	add	r6, r6, r4
+pen:	ldr	r7, [r6]
+	cmp	r7, r0
+	bne	pen
+
+	/*
+	 * we've been released from the holding pen: secondary_stack
+	 * should now contain the SVC stack for this core
+	 */
+	bl	v7_invalidate_l1
+	b	secondary_startup
+ENDPROC(mmp_secondary_startup)
+
+	.align	2
+1:	.long	.
+	.long	pen_release
+
+
+/*
+ * Note: The following code is located into the .data section. This is to
+ *       allow sw_reset_flag and cpu_plugin_handler to be accessed with a
+ *       relative load while we can't rely on any MMU translation.
+ *       Reference from: arch/arm/kernel/sleep.S
+ */
+
+	.data
+	.align
+
+/*
+ * ROM code jumps to this function while waking up from CPU
+ * OFF or software reset state. Physical address of the function is
+ * stored at CA9_WARM_RESET_VECTOR while system is bring up.
+ */
+ENTRY(mmp_cpu_reset_entry)
+	adr	r1, mmp_entry_vectors
+	mrc	p15, 0, r0, c0, c0, 5
+	and	r0, r0, #15		@ fetch CPUID
+1:
+	ldr	r2, [r1, r0, lsl #2]    @ get the handler addr for this core
+	cmp	r2, #0
+	movne	pc, r2			@ jump to the handler
+	beq	1b
+ENDPROC(mmp_cpu_reset_entry)
+
+	/* Point to the address that save handlers for each core */
+	.global mmp_entry_vectors
+mmp_entry_vectors:
+	.rept   CONFIG_NR_CPUS
+        .long   0                               @ preserve stack phys ptr here
+	.endr
diff --git a/arch/arm/mach-mmp/mmpx-dt.c b/arch/arm/mach-mmp/mmpx-dt.c
index bbc0c50..a5f5501 100644
--- a/arch/arm/mach-mmp/mmpx-dt.c
+++ b/arch/arm/mach-mmp/mmpx-dt.c
@@ -71,6 +71,7 @@ static const char *pxa988_dt_board_compat[] __initdata = {
 };
 
 DT_MACHINE_START(PXA988_DT, "Marvell PXA988 (Device Tree Support)")
+	.smp            = smp_ops(mmp_smp_ops),
 	.map_io		= mmp_map_io,
 	.init_irq	= pxa988_dt_gic_init,
 	.init_time	= pxa988_dt_init_timer,
diff --git a/arch/arm/mach-mmp/platsmp.c b/arch/arm/mach-mmp/platsmp.c
new file mode 100644
index 0000000..a6590a3
--- /dev/null
+++ b/arch/arm/mach-mmp/platsmp.c
@@ -0,0 +1,170 @@
+/*
+ *  linux/arch/arm/mach-mmp/platsmp.c
+ *
+ *  Copyright (C) 2002 ARM Ltd.
+ *  All Rights Reserved
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include <linux/init.h>
+#include <linux/errno.h>
+#include <linux/delay.h>
+#include <linux/device.h>
+#include <linux/jiffies.h>
+#include <linux/smp.h>
+#include <linux/io.h>
+#include <linux/irq.h>
+
+#include <asm/cacheflush.h>
+#include <mach/hardware.h>
+#include <linux/irqchip/arm-gic.h>
+#include <asm/mach-types.h>
+#include <asm/localtimer.h>
+#include <asm/smp_scu.h>
+
+#include <mach/irqs.h>
+#include <mach/addr-map.h>
+
+#include "common.h"
+#include "reset.h"
+
+/*
+ * Write pen_release in a way that is guaranteed to be visible to all
+ * observers, irrespective of whether they're taking part in coherency
+ * or not.  This is necessary for the hotplug code to work reliably.
+ */
+static void __cpuinit write_pen_release(int val)
+{
+	pen_release = val;
+	smp_wmb();
+	__cpuc_flush_dcache_area((void *)&pen_release, sizeof(pen_release));
+	outer_clean_range(__pa(&pen_release), __pa(&pen_release + 1));
+}
+
+#ifdef CONFIG_HAVE_ARM_SCU
+static void __iomem *scu_get_base_addr(void)
+{
+	return SCU_VIRT_BASE;
+}
+#endif
+
+static inline unsigned int get_core_count(void)
+{
+	u32 ret = 1;
+#ifdef CONFIG_HAVE_ARM_SCU
+	ret = scu_get_core_count(scu_get_base_addr());
+#endif
+
+	return ret;
+}
+
+static DEFINE_SPINLOCK(boot_lock);
+
+static void __cpuinit mmp_secondary_init(unsigned int cpu)
+{
+	/*
+	 * if any interrupts are already enabled for the primary
+	 * core (e.g. timer irq), then they will not have been enabled
+	 * for us: do so
+	 */
+	gic_secondary_init(0);
+
+	/*
+	 * let the primary processor know we're out of the
+	 * pen, then head off into the C entry point
+	 */
+	write_pen_release(-1);
+
+	/*
+	 * Synchronise with the boot thread.
+	 */
+	spin_lock(&boot_lock);
+	spin_unlock(&boot_lock);
+}
+
+static int __cpuinit mmp_boot_secondary(unsigned int cpu, struct task_struct *idle)
+{
+	unsigned long timeout;
+
+	/*
+	 * Avoid timer calibration on slave cpus. Use the value calibrated
+	 * on master cpu. Referenced from tegra3
+	 */
+	preset_lpj = loops_per_jiffy;
+
+	/*
+	 * set synchronisation state between this boot processor
+	 * and the secondary one
+	 */
+
+	spin_lock(&boot_lock);
+
+	/*
+	 * The secondary processor is waiting to be released from
+	 * the holding pen - release it, then wait for it to flag
+	 * that it has been released by resetting pen_release.
+	 *
+	 * Note that "pen_release" is the hardware CPU ID, whereas
+	 * "cpu" is Linux's internal ID.
+	 */
+	write_pen_release(cpu);
+
+	/* reset the cpu, let it branch to the kernel entry */
+	mmp_cpu_power_up(cpu);
+
+	timeout = jiffies + (1 * HZ);
+	while (time_before(jiffies, timeout)) {
+		smp_rmb();
+		if (pen_release == -1)
+			break;
+
+		udelay(10);
+	}
+
+	/*
+	 * now the secondary core is starting up let it run its
+	 * calibrations, then wait for it to finish
+	 */
+	spin_unlock(&boot_lock);
+
+	return pen_release != -1 ? -ENOSYS : 0;
+}
+
+/*
+ * Initialise the CPU possible map early - this describes the CPUs
+ * which may be present or become present in the system.
+ */
+static void __init mmp_smp_init_cpus(void)
+{
+	unsigned int i, ncores = get_core_count();
+
+	for (i = 0; i < ncores; i++)
+		set_cpu_possible(i, true);
+}
+
+static void __init mmp_smp_prepare_cpus(unsigned int max_cpus)
+{
+	int i;
+
+	/*
+	 * Initialise the present map, which describes the set of CPUs
+	 * actually populated at the present time.
+	 */
+	for (i = 0; i < max_cpus; i++)
+		set_cpu_present(i, true);
+
+#ifdef CONFIG_HAVE_ARM_SCU
+	scu_enable(scu_get_base_addr());
+#endif
+
+	mmp_entry_vector_init();
+}
+
+struct smp_operations mmp_smp_ops __initdata = {
+	.smp_init_cpus		= mmp_smp_init_cpus,
+	.smp_prepare_cpus	= mmp_smp_prepare_cpus,
+	.smp_secondary_init	= mmp_secondary_init,
+	.smp_boot_secondary	= mmp_boot_secondary,
+};
diff --git a/arch/arm/mach-mmp/reset.c b/arch/arm/mach-mmp/reset.c
new file mode 100644
index 0000000..b47e400
--- /dev/null
+++ b/arch/arm/mach-mmp/reset.c
@@ -0,0 +1,66 @@
+/*
+ * linux/arch/arm/mach-mmp/reset.c
+ *
+ * Author:	Neil Zhang <zhangwm at marvell.com>
+ * Copyright:	(C) 2012 Marvell International Ltd.
+ *
+ * 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.
+ */
+
+#include <linux/kernel.h>
+#include <linux/smp.h>
+
+#include <asm/io.h>
+#include <asm/cacheflush.h>
+#include <asm/mach/map.h>
+
+#include <mach/addr-map.h>
+
+#include "reset.h"
+
+#define PMU_CC2_AP			APMU_REG(0x0100)
+#define CIU_CA9_WARM_RESET_VECTOR	CIU_REG(0x00d8)
+
+/*
+ * This function is called from boot_secondary to bootup the secondary cpu.
+ */
+void mmp_cpu_power_up(u32 cpu)
+{
+	u32 tmp;
+
+	BUG_ON(cpu == 0);
+
+	tmp = readl(PMU_CC2_AP);
+	if (tmp & CPU_CORE_RST(cpu)) {
+		/* Release secondary core from reset */
+		tmp &= ~(CPU_CORE_RST(cpu)
+			| CPU_DBG_RST(cpu) | CPU_WDOG_RST(cpu));
+		writel(tmp, PMU_CC2_AP);
+	}
+}
+
+void mmp_set_entry_vector(u32 cpu, u32 addr)
+{
+	BUG_ON(cpu >= CONFIG_NR_CPUS);
+
+	mmp_entry_vectors[cpu] = addr;
+	smp_wmb();
+	__cpuc_flush_dcache_area((void *)&mmp_entry_vectors[cpu],
+				sizeof(mmp_entry_vectors[cpu]));
+	outer_clean_range(__pa(&mmp_entry_vectors[cpu]),
+				__pa(&mmp_entry_vectors[cpu + 1]));
+}
+
+void __init mmp_entry_vector_init(void)
+{
+	int cpu;
+
+	/* We will reset from DDR directly by default */
+	writel(__pa(mmp_cpu_reset_entry), CIU_CA9_WARM_RESET_VECTOR);
+
+	for (cpu = 1; cpu < CONFIG_NR_CPUS; cpu++)
+		mmp_set_entry_vector(cpu, __pa(mmp_secondary_startup));
+}
diff --git a/arch/arm/mach-mmp/reset.h b/arch/arm/mach-mmp/reset.h
new file mode 100644
index 0000000..78d5486
--- /dev/null
+++ b/arch/arm/mach-mmp/reset.h
@@ -0,0 +1,29 @@
+/*
+ * linux/arch/arm/mach-mmp/include/mach/reset.h
+ *
+ * Author:	Neil Zhang <zhangwm at marvell.com>
+ * Copyright:	(C) 2012 Marvell International Ltd.
+ *
+ * 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.
+ */
+
+#ifndef __RESET_PXA988_H__
+#define __RESET_PXA988_H__
+
+#define CPU_CORE_RST(n)	(1 << ((n) * 4 + 16))
+#define CPU_DBG_RST(n)	(1 << ((n) * 4 + 18))
+#define CPU_WDOG_RST(n)	(1 << ((n) * 4 + 19))
+
+extern u32 mmp_entry_vectors[CONFIG_NR_CPUS];
+
+void mmp_secondary_startup(void);
+void mmp_cpu_reset_entry(void);
+
+void mmp_cpu_power_up(u32 cpu);
+void mmp_set_entry_vector(u32 cpu, u32 addr);
+void __init mmp_entry_vector_init(void);
+
+#endif /* __RESET_PXA988_H__ */
-- 
1.7.4.1



From zhangwm at marvell.com  Wed Apr 10 23:37:39 2013
From: zhangwm at marvell.com (Neil Zhang)
Date: Thu, 11 Apr 2013 11:37:39 +0800
Subject: [PATCH 0/4] bring up pxa988 with DT
Message-ID: <1365651463-11502-1-git-send-email-zhangwm@marvell.com>

This patch sets do the following things:
1. add wakeup function for ICU.
2. move some common funciton declaration to common.h
3. bring up pxa988 with DT support

Chao Xie (1):
  ARM: mmp: add wakeup function for ICU

Neil Zhang (3):
  ARM: mmp: move function declaration to head file
  ARM: mmp: bring up pxa988 with device tree support
  ARM: mmp: add SMP support for pxa988

 .../devicetree/bindings/arm/mrvl/intc.txt          |    9 +
 arch/arm/boot/dts/pxa988-dkb.dts                   |   36 ++++
 arch/arm/boot/dts/pxa988.dtsi                      |  196 ++++++++++++++++++++
 arch/arm/mach-mmp/Kconfig                          |   25 +++
 arch/arm/mach-mmp/Makefile                         |    5 +
 arch/arm/mach-mmp/common.c                         |   11 +-
 arch/arm/mach-mmp/common.h                         |    5 +
 arch/arm/mach-mmp/headsmp.S                        |  104 +++++++++++
 arch/arm/mach-mmp/include/mach/addr-map.h          |    6 +
 arch/arm/mach-mmp/irq.c                            |   51 ++++-
 arch/arm/mach-mmp/mmp-dt.c                         |    3 -
 arch/arm/mach-mmp/mmp2-dt.c                        |    3 -
 arch/arm/mach-mmp/mmpx-dt.c                        |   80 ++++++++
 arch/arm/mach-mmp/platsmp.c                        |  170 +++++++++++++++++
 arch/arm/mach-mmp/reset.c                          |   66 +++++++
 arch/arm/mach-mmp/reset.h                          |   29 +++
 drivers/clk/mmp/Makefile                           |    1 +
 17 files changed, 783 insertions(+), 17 deletions(-)
 create mode 100644 arch/arm/boot/dts/pxa988-dkb.dts
 create mode 100644 arch/arm/boot/dts/pxa988.dtsi
 create mode 100644 arch/arm/mach-mmp/headsmp.S
 create mode 100644 arch/arm/mach-mmp/mmpx-dt.c
 create mode 100644 arch/arm/mach-mmp/platsmp.c
 create mode 100644 arch/arm/mach-mmp/reset.c
 create mode 100644 arch/arm/mach-mmp/reset.h

-- 
1.7.4.1



From zhangwm at marvell.com  Wed Apr 10 23:37:41 2013
From: zhangwm at marvell.com (Neil Zhang)
Date: Thu, 11 Apr 2013 11:37:41 +0800
Subject: [PATCH 2/4] ARM: mmp: move function declaration to head file
In-Reply-To: <1365651463-11502-1-git-send-email-zhangwm@marvell.com>
References: <1365651463-11502-1-git-send-email-zhangwm@marvell.com>
Message-ID: <1365651463-11502-3-git-send-email-zhangwm@marvell.com>

Move some of the function declaration to head file.

Signed-off-by: Neil Zhang <zhangwm at marvell.com>
Signed-off-by: Chao Xie <chao.xie at marvell.com>
---
 arch/arm/mach-mmp/common.h  |    3 +++
 arch/arm/mach-mmp/mmp-dt.c  |    3 ---
 arch/arm/mach-mmp/mmp2-dt.c |    3 ---
 3 files changed, 3 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-mmp/common.h b/arch/arm/mach-mmp/common.h
index 0bdc50b..8c9b510 100644
--- a/arch/arm/mach-mmp/common.h
+++ b/arch/arm/mach-mmp/common.h
@@ -8,3 +8,6 @@ extern void mmp_restart(char, const char *);
 extern void __init pxa168_clk_init(void);
 extern void __init pxa910_clk_init(void);
 extern void __init mmp2_clk_init(void);
+
+extern void __init mmp_dt_irq_init(void);
+extern void __init mmp_dt_init_timer(void);
diff --git a/arch/arm/mach-mmp/mmp-dt.c b/arch/arm/mach-mmp/mmp-dt.c
index d063efa..af0bb5b 100644
--- a/arch/arm/mach-mmp/mmp-dt.c
+++ b/arch/arm/mach-mmp/mmp-dt.c
@@ -19,9 +19,6 @@
 
 #include "common.h"
 
-extern void __init mmp_dt_irq_init(void);
-extern void __init mmp_dt_init_timer(void);
-
 static const struct of_dev_auxdata pxa168_auxdata_lookup[] __initconst = {
 	OF_DEV_AUXDATA("mrvl,mmp-uart", 0xd4017000, "pxa2xx-uart.0", NULL),
 	OF_DEV_AUXDATA("mrvl,mmp-uart", 0xd4018000, "pxa2xx-uart.1", NULL),
diff --git a/arch/arm/mach-mmp/mmp2-dt.c b/arch/arm/mach-mmp/mmp2-dt.c
index fad431a..4ba1fbe 100644
--- a/arch/arm/mach-mmp/mmp2-dt.c
+++ b/arch/arm/mach-mmp/mmp2-dt.c
@@ -21,9 +21,6 @@
 
 #include "common.h"
 
-extern void __init mmp_dt_irq_init(void);
-extern void __init mmp_dt_init_timer(void);
-
 static const struct of_dev_auxdata mmp2_auxdata_lookup[] __initconst = {
 	OF_DEV_AUXDATA("mrvl,mmp-uart", 0xd4030000, "pxa2xx-uart.0", NULL),
 	OF_DEV_AUXDATA("mrvl,mmp-uart", 0xd4017000, "pxa2xx-uart.1", NULL),
-- 
1.7.4.1



From zhangwm at marvell.com  Wed Apr 10 23:38:49 2013
From: zhangwm at marvell.com (Neil Zhang)
Date: Thu, 11 Apr 2013 11:38:49 +0800
Subject: [PATCH 3/4] ARM: mmp: bring up pxa988 with device tree support
Message-ID: <1365651529-11545-1-git-send-email-zhangwm@marvell.com>

bring up pxa988 with device tree support.

Signed-off-by: Neil Zhang <zhangwm at marvell.com>
Signed-off-by: Chao Xie <chao.xie at marvell.com>
---
 arch/arm/boot/dts/pxa988-dkb.dts          |   36 ++++++
 arch/arm/boot/dts/pxa988.dtsi             |  196 +++++++++++++++++++++++++++++
 arch/arm/mach-mmp/Kconfig                 |   25 ++++
 arch/arm/mach-mmp/Makefile                |    1 +
 arch/arm/mach-mmp/common.c                |   11 ++-
 arch/arm/mach-mmp/include/mach/addr-map.h |    6 +
 arch/arm/mach-mmp/mmpx-dt.c               |   79 ++++++++++++
 drivers/clk/mmp/Makefile                  |    1 +
 8 files changed, 354 insertions(+), 1 deletions(-)
 create mode 100644 arch/arm/boot/dts/pxa988-dkb.dts
 create mode 100644 arch/arm/boot/dts/pxa988.dtsi
 create mode 100644 arch/arm/mach-mmp/mmpx-dt.c

diff --git a/arch/arm/boot/dts/pxa988-dkb.dts b/arch/arm/boot/dts/pxa988-dkb.dts
new file mode 100644
index 0000000..2cee3ed
--- /dev/null
+++ b/arch/arm/boot/dts/pxa988-dkb.dts
@@ -0,0 +1,36 @@
+/*
+ *  Copyright (C) 2012 Marvell Technology Group Ltd.
+ *  Author: Haojian Zhuang <haojian.zhuang at marvell.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
+ *  publishhed by the Free Software Foundation.
+ */
+
+/dts-v1/;
+/include/ "pxa988.dtsi"
+
+/ {
+	model = "Marvell PXA988 DKB Development Board";
+	compatible = "mrvl,pxa988-dkb", "mrvl,pxa988";
+
+	chosen {
+		bootargs = "console=ttyS0,115200 root=/dev/nfs nfsroot=192.168.1.100:/nfsroot/ ip=192.168.1.101:192.168.1.100::255.255.255.0::eth0:on";
+	};
+
+	memory {
+		reg = <0x00000000 0x10000000>;
+	};
+
+	soc {
+		apb at d4000000 {
+			uart1: uart at d4017000 {
+				status = "okay";
+			};
+
+			rtc: rtc at d4010000 {
+				status = "okay";
+			};
+		};
+	};
+};
diff --git a/arch/arm/boot/dts/pxa988.dtsi b/arch/arm/boot/dts/pxa988.dtsi
new file mode 100644
index 0000000..8ec89b0
--- /dev/null
+++ b/arch/arm/boot/dts/pxa988.dtsi
@@ -0,0 +1,196 @@
+/*
+ *  Copyright (C) 2013 Marvell Technology Group Ltd.
+ *  Author: Chao Xie <chao.xie at marvell.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
+ *  publishhed by the Free Software Foundation.
+ */
+
+/include/ "skeleton.dtsi"
+
+/ {
+	interrupt-parent = <&gic>;
+
+	aliases {
+		serial0 = &uart1;
+		serial1 = &uart2;
+		serial2 = &uart3;
+		i2c0 = &twsi1;
+		i2c1 = &twsi2;
+	};
+
+	cpus {
+		cpu at 0 {
+			compatible = "arm,cortex-a9";
+			next-level-cache = <&L2>;
+		};
+		cpu at 1 {
+			compatible = "arm,cortex-a9";
+			next-level-cache = <&L2>;
+		};
+	};
+
+	gic: interrupt-controller at d1dfe100 {
+		compatible = "arm,cortex-a9-gic";
+		interrupt-controller;
+		#interrupt-cells = <3>;
+		reg = <0xd1dff000 0x1000>,
+		      <0xd1dfe100 0x0100>;
+	};
+
+	L2: l2-cache-controller at d1dfb000 {
+		compatible = "arm,pl310-cache";
+		reg = <0xd1dfb000 0x1000>;
+		arm,data-latency = <2 1 1>;
+		arm,tag-latency = <2 1 1>;
+		arm,pwr-dynamic-clk-gating;
+		arm,pwr-standby-mode;
+		cache-unified;
+		cache-level = <2>;
+	};
+
+	local-timer at d1dfe600 {
+		compatible = "arm,cortex-a9-twd-timer";
+		reg = <0xd1dfe600 0x20>;
+		interrupts = <1 13 0x304>;
+	};
+
+	soc {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		compatible = "simple-bus";
+		interrupt-parent = <&gic>;
+		ranges;
+
+		axi at d4200000 {	/* AXI */
+			compatible = "mrvl,axi-bus", "simple-bus";
+			#address-cells = <1>;
+			#size-cells = <1>;
+			reg = <0xd4200000 0x00200000>;
+			ranges;
+
+			intc: interrupt-controller at d4282000 {
+				compatible = "mrvl,mmp-intc";
+				reg = <0xd4282000 0x1000>;
+				mrvl,intc-wakeup = <0x114 0x3
+						    0x144 0x3>;
+			};
+
+		};
+
+		apb at d4000000 {	/* APB */
+			compatible = "mrvl,apb-bus", "simple-bus";
+			#address-cells = <1>;
+			#size-cells = <1>;
+			reg = <0xd4000000 0x00200000>;
+			ranges;
+
+			timer0: timer at d4014000 {
+				compatible = "mrvl,mmp-timer";
+				reg = <0xd4014000 0x100>;
+				interrupts = <0 13 0x4>;
+			};
+
+			timer1: timer at d4016000 {
+				compatible = "mrvl,mmp-timer";
+				reg = <0xd4016000 0x100>;
+				interrupts = <0 29 0x4>;
+				status = "disabled";
+			};
+
+			uart1: uart at d4017000 {
+				compatible = "mrvl,mmp-uart";
+				reg = <0xd4017000 0x1000>;
+				interrupts = <0 27 0x4>;
+				status = "disabled";
+			};
+
+			uart2: uart at d4018000 {
+				compatible = "mrvl,mmp-uart";
+				reg = <0xd4018000 0x1000>;
+				interrupts = <0 28 0x4>;
+				status = "disabled";
+			};
+
+			uart3: uart at d4036000 {
+				compatible = "mrvl,mmp-uart";
+				reg = <0xd4036000 0x1000>;
+				interrupts = <0 59 0x4>;
+				status = "disabled";
+			};
+
+			gpio at d4019000 {
+				compatible = "mrvl,mmp-gpio";
+				#address-cells = <1>;
+				#size-cells = <1>;
+				reg = <0xd4019000 0x1000>;
+				gpio-controller;
+				#gpio-cells = <2>;
+				interrupts = <49>;
+				interrupt-names = "gpio_mux";
+				interrupt-controller;
+				#interrupt-cells = <1>;
+				ranges;
+
+				gcb0: gpio at d4019000 {
+					reg = <0xd4019000 0x4>;
+				};
+
+				gcb1: gpio at d4019004 {
+					reg = <0xd4019004 0x4>;
+				};
+
+				gcb2: gpio at d4019008 {
+					reg = <0xd4019008 0x4>;
+				};
+
+				gcb3: gpio at d4019100 {
+					reg = <0xd4019100 0x4>;
+				};
+			};
+
+			twsi1: i2c at d4011000 {
+				compatible = "mrvl,mmp-twsi";
+				#address-cells = <1>;
+				#size-cells = <0>;
+				reg = <0xd4011000 0x1000>;
+				interrupts = <0 7 0x4>;
+				mrvl,i2c-fast-mode;
+				status = "disabled";
+			};
+
+			twsi2: i2c at d4037000 {
+				compatible = "mrvl,mmp-twsi";
+				#address-cells = <1>;
+				#size-cells = <0>;
+				reg = <0xd4037000 0x1000>;
+				interrupts = <0 54 0x4>;
+				status = "disabled";
+			};
+
+			rtc: rtc at d4010000 {
+				compatible = "mrvl,mmp-rtc";
+				reg = <0xd4010000 0x1000>;
+				interrupts = <0 5 0x4>,<0 6 0x4>;
+				interrupt-names = "rtc 1Hz", "rtc alarm";
+				status = "disabled";
+			};
+			pmx: pinmux at d401e000 {
+				compatible = "pinconf-single";
+				reg = <0xd401e000 0x330>;
+				#address-cells = <1>;
+				#size-cells = <1>;
+				#gpio-range-cells = <3>;
+				ranges;
+
+				pinctrl-single,register-width = <32>;
+				pinctrl-single,function-mask = <7>;
+
+				range: gpio-range {
+					#pinctrl-single,gpio-range-cells = <3>;
+				};
+			};
+		};
+	};
+};
diff --git a/arch/arm/mach-mmp/Kconfig b/arch/arm/mach-mmp/Kconfig
index ebdda83..ffdbab9 100644
--- a/arch/arm/mach-mmp/Kconfig
+++ b/arch/arm/mach-mmp/Kconfig
@@ -107,6 +107,16 @@ config MACH_MMP2_DT
 	  Include support for Marvell MMP2 based platforms using
 	  the device tree.
 
+config MACH_MMPX_DT
+	bool "Support no-PJ/PJ4(ARMv7) platforms from device tree"
+	depends on !CPU_MOHAWK && !CPU_PJ4
+	select CPU_PXA988
+	select USE_OF
+	select PINCTRL
+	select PINCTRL_SINGLE
+	help
+	  Include support for Marvell MMP2 based platforms using
+	  the device tree.
 endmenu
 
 config CPU_PXA168
@@ -123,6 +133,21 @@ config CPU_PXA910
 	help
 	  Select code specific to PXA910
 
+config CPU_PXA988
+	bool
+	select CPU_V7
+	select ARM_GIC
+	select HAVE_SMP
+	select SOC_LOCAL_TIMERS
+	select COMMON_CLK
+	select CLKSRC_OF
+	select MIGHT_HAVE_CACHE_L2X0
+	help
+	  Say 'Y' here if you want to support the Marvell pxa988-base
+	  platforms.
+	  PXA988 is an SoC with dual-core Cotex-A9 and comunication
+	  processor, code name "Emei".
+
 config CPU_MMP2
 	bool
 	select COMMON_CLK
diff --git a/arch/arm/mach-mmp/Makefile b/arch/arm/mach-mmp/Makefile
index 095c155..b60065f 100644
--- a/arch/arm/mach-mmp/Makefile
+++ b/arch/arm/mach-mmp/Makefile
@@ -31,5 +31,6 @@ obj-$(CONFIG_MACH_FLINT)	+= flint.o
 obj-$(CONFIG_MACH_MARVELL_JASPER) += jasper.o
 obj-$(CONFIG_MACH_MMP_DT)	+= mmp-dt.o
 obj-$(CONFIG_MACH_MMP2_DT)	+= mmp2-dt.o
+obj-$(CONFIG_MACH_MMPX_DT)	+= mmpx-dt.o
 obj-$(CONFIG_MACH_TETON_BGA)	+= teton_bga.o
 obj-$(CONFIG_MACH_GPLUGD)	+= gplugd.o
diff --git a/arch/arm/mach-mmp/common.c b/arch/arm/mach-mmp/common.c
index 9292b79..0c621bc 100644
--- a/arch/arm/mach-mmp/common.c
+++ b/arch/arm/mach-mmp/common.c
@@ -11,6 +11,10 @@
 #include <linux/init.h>
 #include <linux/kernel.h>
 #include <linux/module.h>
+#include <linux/of.h>
+#include <linux/io.h>
+#include <linux/ioport.h>
+#include <linux/of_address.h>
 
 #include <asm/page.h>
 #include <asm/mach/map.h>
@@ -36,7 +40,12 @@ static struct map_desc standard_io_desc[] __initdata = {
 		.virtual	= (unsigned long)AXI_VIRT_BASE,
 		.length		= AXI_PHYS_SIZE,
 		.type		= MT_DEVICE,
-	},
+	}, {
+		.pfn		= __phys_to_pfn(MMP_CORE_PERIPH_PHYS_BASE),
+		.virtual	= (unsigned long)MMP_CORE_PERIPH_VIRT_BASE,
+		.length		= MMP_CORE_PERIPH_PHYS_SIZE,
+		.type		= MT_DEVICE,
+	}
 };
 
 void __init mmp_map_io(void)
diff --git a/arch/arm/mach-mmp/include/mach/addr-map.h b/arch/arm/mach-mmp/include/mach/addr-map.h
index f88a44c..092005b 100644
--- a/arch/arm/mach-mmp/include/mach/addr-map.h
+++ b/arch/arm/mach-mmp/include/mach/addr-map.h
@@ -25,6 +25,10 @@
 #define AXI_VIRT_BASE		IOMEM(0xfe200000)
 #define AXI_PHYS_SIZE		0x00200000
 
+#define MMP_CORE_PERIPH_PHYS_BASE	0xd1dfe000
+#define MMP_CORE_PERIPH_VIRT_BASE	IOMEM(0xfe400000)
+#define MMP_CORE_PERIPH_PHYS_SIZE	0x00002000
+
 /* Static Memory Controller - Chip Select 0 and 1 */
 #define SMC_CS0_PHYS_BASE	0x80000000
 #define SMC_CS0_PHYS_SIZE	0x10000000
@@ -43,4 +47,6 @@
 #define CIU_VIRT_BASE		(AXI_VIRT_BASE + 0x82c00)
 #define CIU_REG(x)		(CIU_VIRT_BASE + (x))
 
+#define SCU_VIRT_BASE		(MMP_CORE_PERIPH_VIRT_BASE)
+
 #endif /* __ASM_MACH_ADDR_MAP_H */
diff --git a/arch/arm/mach-mmp/mmpx-dt.c b/arch/arm/mach-mmp/mmpx-dt.c
new file mode 100644
index 0000000..bbc0c50
--- /dev/null
+++ b/arch/arm/mach-mmp/mmpx-dt.c
@@ -0,0 +1,79 @@
+/*
+ *  linux/arch/arm/mach-mmp/mmpx-dt.c
+ *
+ *  Copyright (C) 2012 Marvell Technology Group Ltd.
+ *  Author: Haojian Zhuang <haojian.zhuang at marvell.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
+ *  publishhed by the Free Software Foundation.
+ */
+
+#include <linux/clocksource.h>
+#include <linux/io.h>
+#include <linux/irq.h>
+#include <linux/irqdomain.h>
+#include <linux/irqchip.h>
+#include <linux/of_irq.h>
+#include <linux/of_platform.h>
+#include <asm/smp_twd.h>
+#include <asm/hardware/cache-l2x0.h>
+#include <asm/mach/arch.h>
+#include <asm/mach/time.h>
+#include <mach/irqs.h>
+#include <mach/regs-apbc.h>
+
+#include "common.h"
+
+/* PXA988 */
+static const struct of_dev_auxdata pxa988_auxdata_lookup[] __initconst = {
+	OF_DEV_AUXDATA("mrvl,mmp-uart", 0xd4017000, "pxa2xx-uart.0", NULL),
+	OF_DEV_AUXDATA("mrvl,mmp-uart", 0xd4018000, "pxa2xx-uart.1", NULL),
+	OF_DEV_AUXDATA("mrvl,mmp-uart", 0xd4036000, "pxa2xx-uart.2", NULL),
+	OF_DEV_AUXDATA("mrvl,mmp-twsi", 0xd4011000, "pxa2xx-i2c.0", NULL),
+	OF_DEV_AUXDATA("mrvl,mmp-twsi", 0xd4037000, "pxa2xx-i2c.1", NULL),
+	OF_DEV_AUXDATA("mrvl,mmp-gpio", 0xd4019000, "pxa-gpio", NULL),
+	OF_DEV_AUXDATA("mrvl,mmp-rtc", 0xd4010000, "sa1100-rtc", NULL),
+	{}
+};
+
+static void __init pxa988_dt_gic_init(void)
+{
+	irqchip_init();
+	/* only for wake up */
+	mmp_dt_irq_init();
+}
+
+void __init pxa988_dt_init_timer(void)
+{
+	/*
+	 * Is is a SOC timer, and will be used for broadcasting
+	 * when local timers are disabled.
+	 */
+	mmp_dt_init_timer();
+
+	clocksource_of_init();
+}
+
+static void __init pxa988_dt_init(void)
+{
+	l2x0_of_init(0x30800000, 0xFE7FFFFF);
+
+	pxa910_clk_init();
+
+	of_platform_populate(NULL, of_default_bus_match_table,
+			     pxa988_auxdata_lookup, NULL);
+}
+
+static const char *pxa988_dt_board_compat[] __initdata = {
+	"mrvl,pxa988-dkb",
+	NULL,
+};
+
+DT_MACHINE_START(PXA988_DT, "Marvell PXA988 (Device Tree Support)")
+	.map_io		= mmp_map_io,
+	.init_irq	= pxa988_dt_gic_init,
+	.init_time	= pxa988_dt_init_timer,
+	.init_machine	= pxa988_dt_init,
+	.dt_compat	= pxa988_dt_board_compat,
+MACHINE_END
diff --git a/drivers/clk/mmp/Makefile b/drivers/clk/mmp/Makefile
index 392d780..59a3f9f7 100644
--- a/drivers/clk/mmp/Makefile
+++ b/drivers/clk/mmp/Makefile
@@ -7,3 +7,4 @@ obj-y += clk-apbc.o clk-apmu.o clk-frac.o
 obj-$(CONFIG_CPU_PXA168) += clk-pxa168.o
 obj-$(CONFIG_CPU_PXA910) += clk-pxa910.o
 obj-$(CONFIG_CPU_MMP2) += clk-mmp2.o
+obj-$(CONFIG_CPU_PXA988) += clk-pxa910.o
-- 
1.7.4.1



From jg1.han at samsung.com  Thu Apr 11 00:34:34 2013
From: jg1.han at samsung.com (Jingoo Han)
Date: Thu, 11 Apr 2013 13:34:34 +0900
Subject: [PATCH 13/30] video/s3c: move platform_data out of arch/arm
In-Reply-To: <1365638712-1028578-14-git-send-email-arnd@arndb.de>
References: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
 <1365638712-1028578-14-git-send-email-arnd@arndb.de>
Message-ID: <003001ce366d$de38c280$9aaa4780$%han@samsung.com>

On Thursday, April 11, 2013 9:05 AM, Arnd Bergmann wrote:
> 
> The s3c-fb driver requires header files from the samsung platforms
> to find its platform_data definition, but this no longer works on
> multiplatform kernels, so let's move the data into a new header
> file under include/linux/platform_data.
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Cc: linux-fbdev at vger.kernel.org
> Cc: Jingoo Han <jg1.han at samsung.com>

CC'ed Tomi Valkeinen.


Hi Arnd,
It looks good. Thank you for your patch. :)

Acked-by: Jingoo Han <jg1.han at samsung.com>

Best regards,
Jingoo Han

> ---
>  arch/arm/plat-samsung/include/plat/fb.h | 50 +-----------------------------
>  drivers/video/s3c-fb.c                  |  3 +-
>  include/linux/platform_data/video_s3c.h | 54 +++++++++++++++++++++++++++++++++
>  3 files changed, 56 insertions(+), 51 deletions(-)
>  create mode 100644 include/linux/platform_data/video_s3c.h
> 
> diff --git a/arch/arm/plat-samsung/include/plat/fb.h b/arch/arm/plat-samsung/include/plat/fb.h
> index b885322..9ae5072 100644
> --- a/arch/arm/plat-samsung/include/plat/fb.h
> +++ b/arch/arm/plat-samsung/include/plat/fb.h
> @@ -15,55 +15,7 @@
>  #ifndef __PLAT_S3C_FB_H
>  #define __PLAT_S3C_FB_H __FILE__
> 
> -/* S3C_FB_MAX_WIN
> - * Set to the maximum number of windows that any of the supported hardware
> - * can use. Since the platform data uses this for an array size, having it
> - * set to the maximum of any version of the hardware can do is safe.
> - */
> -#define S3C_FB_MAX_WIN	(5)
> -
> -/**
> - * struct s3c_fb_pd_win - per window setup data
> - * @xres     : The window X size.
> - * @yres     : The window Y size.
> - * @virtual_x: The virtual X size.
> - * @virtual_y: The virtual Y size.
> - */
> -struct s3c_fb_pd_win {
> -	unsigned short		default_bpp;
> -	unsigned short		max_bpp;
> -	unsigned short		xres;
> -	unsigned short		yres;
> -	unsigned short		virtual_x;
> -	unsigned short		virtual_y;
> -};
> -
> -/**
> - * struct s3c_fb_platdata -  S3C driver platform specific information
> - * @setup_gpio: Setup the external GPIO pins to the right state to transfer
> - *		the data from the display system to the connected display
> - *		device.
> - * @vidcon0: The base vidcon0 values to control the panel data format.
> - * @vidcon1: The base vidcon1 values to control the panel data output.
> - * @vtiming: Video timing when connected to a RGB type panel.
> - * @win: The setup data for each hardware window, or NULL for unused.
> - * @display_mode: The LCD output display mode.
> - *
> - * The platform data supplies the video driver with all the information
> - * it requires to work with the display(s) attached to the machine. It
> - * controls the initial mode, the number of display windows (0 is always
> - * the base framebuffer) that are initialised etc.
> - *
> - */
> -struct s3c_fb_platdata {
> -	void	(*setup_gpio)(void);
> -
> -	struct s3c_fb_pd_win	*win[S3C_FB_MAX_WIN];
> -	struct fb_videomode     *vtiming;
> -
> -	u32			 vidcon0;
> -	u32			 vidcon1;
> -};
> +#include <linux/platform_data/video_s3c.h>
> 
>  /**
>   * s3c_fb_set_platdata() - Setup the FB device with platform data.
> diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
> index 968a625..2e7991c 100644
> --- a/drivers/video/s3c-fb.c
> +++ b/drivers/video/s3c-fb.c
> @@ -24,10 +24,9 @@
>  #include <linux/uaccess.h>
>  #include <linux/interrupt.h>
>  #include <linux/pm_runtime.h>
> +#include <linux/platform_data/video_s3c.h>
> 
>  #include <video/samsung_fimd.h>
> -#include <mach/map.h>
> -#include <plat/fb.h>
> 
>  /* This driver will export a number of framebuffer interfaces depending
>   * on the configuration passed in via the platform data. Each fb instance
> diff --git a/include/linux/platform_data/video_s3c.h b/include/linux/platform_data/video_s3c.h
> new file mode 100644
> index 0000000..fa40f96
> --- /dev/null
> +++ b/include/linux/platform_data/video_s3c.h
> @@ -0,0 +1,54 @@
> +#ifndef __PLATFORM_DATA_VIDEO_S3C
> +#define __PLATFORM_DATA_VIDEO_S3C
> +
> +/* S3C_FB_MAX_WIN
> + * Set to the maximum number of windows that any of the supported hardware
> + * can use. Since the platform data uses this for an array size, having it
> + * set to the maximum of any version of the hardware can do is safe.
> + */
> +#define S3C_FB_MAX_WIN	(5)
> +
> +/**
> + * struct s3c_fb_pd_win - per window setup data
> + * @xres     : The window X size.
> + * @yres     : The window Y size.
> + * @virtual_x: The virtual X size.
> + * @virtual_y: The virtual Y size.
> + */
> +struct s3c_fb_pd_win {
> +	unsigned short		default_bpp;
> +	unsigned short		max_bpp;
> +	unsigned short		xres;
> +	unsigned short		yres;
> +	unsigned short		virtual_x;
> +	unsigned short		virtual_y;
> +};
> +
> +/**
> + * struct s3c_fb_platdata -  S3C driver platform specific information
> + * @setup_gpio: Setup the external GPIO pins to the right state to transfer
> + *		the data from the display system to the connected display
> + *		device.
> + * @vidcon0: The base vidcon0 values to control the panel data format.
> + * @vidcon1: The base vidcon1 values to control the panel data output.
> + * @vtiming: Video timing when connected to a RGB type panel.
> + * @win: The setup data for each hardware window, or NULL for unused.
> + * @display_mode: The LCD output display mode.
> + *
> + * The platform data supplies the video driver with all the information
> + * it requires to work with the display(s) attached to the machine. It
> + * controls the initial mode, the number of display windows (0 is always
> + * the base framebuffer) that are initialised etc.
> + *
> + */
> +struct s3c_fb_platdata {
> +	void	(*setup_gpio)(void);
> +
> +	struct s3c_fb_pd_win	*win[S3C_FB_MAX_WIN];
> +	struct fb_videomode     *vtiming;
> +
> +	u32			 vidcon0;
> +	u32			 vidcon1;
> +};
> +
> +#endif
> --
> 1.8.1.2



From omycle at gmail.com  Thu Apr 11 00:46:07 2013
From: omycle at gmail.com (Li Haifeng)
Date: Thu, 11 Apr 2013 12:46:07 +0800
Subject: Kexec couldn't reboot capture kernel on pandaboard ES with
 OMAP4460
In-Reply-To: <51658B1A.6090706@wwwdotorg.org>
References: <CAFNq8R5FFUyH+JgjoGc5ctgEfiLvxzi7fzawM7+wFX5nEyTv-w@mail.gmail.com>
 <51658B1A.6090706@wwwdotorg.org>
Message-ID: <CAFNq8R6mRJRygfnYvZgwVWOqsrhrjNUYzyZGU0cVsnE30W_xGg@mail.gmail.com>

2013/4/10 Stephen Warren <swarren at wwwdotorg.org>:
> On 04/10/2013 03:35 AM, Li Haifeng wrote:
>> Hi, everyone.
>>
>> Recently, I try to run kdump on pandaboard ES with omap4460. After
>> load capture kernel by "kexec -l" and execute "kexec -e", the serial
>> port output "Starting new kernel" and "Bye", then the system hangs up.
>>
>> I have tried the upstream Linux Kernel v3.4 and v3.8. All are with this issue.
>
> This is a shot in the dark. I assume you have SMP enabled. Can you use
> hotplug to remove all CPUs other than CPU0, so that the kexec happens on
> the boot CPU? That is certainly necessary for kexec to work correctly on
> Tegra.

Thanks for your attention.

I do disable SMP feature. And the .config file for v3.8 could be found here:
http://pastehtml.com/view/cylyrfejt.txt

The log and operation could be found here:
http://pastehtml.com/view/cylyfrb3a.txt

Some key setting list below.

bootargs:
rw vram=32M fixrtc mem=1G at 0x80000000 root=/dev/mmcblk0p2
console=ttyO2,115200n8 rootwait crashkernel=64M at 0x82000000

operation:
/ # ./kexec -l  --append="rw vram=32M fixrtc  root=/dev/mmcblk0p2 console=ttyO2,
115200n8 rootwait" uImage
/ # ./kexec -d -e

The output:
[   57.373687] Starting new kernel
[   57.377044] Bye!

Then system hangs.


From jg1.han at samsung.com  Thu Apr 11 01:07:02 2013
From: jg1.han at samsung.com (Jingoo Han)
Date: Thu, 11 Apr 2013 14:07:02 +0900
Subject: [PATCH 12/30] video/exynos: remove unnecessary header inclusions
In-Reply-To: <1365638712-1028578-13-git-send-email-arnd@arndb.de>
References: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
 <1365638712-1028578-13-git-send-email-arnd@arndb.de>
Message-ID: <003201ce3672$66f72e50$34e58af0$%han@samsung.com>

On Thursday, April 11, 2013 9:05 AM, Arnd Bergmann wrote:
> 
> In multiplatform configurations, we cannot include headers
> provided by only the exynos platform. Fortunately a number
> of drivers that include those headers do not actually need
> them, so we can just remove the inclusions.
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Cc: linux-fbdev at vger.kernel.org
> Cc: Jingoo Han <jg1.han at samsung.com>

CC'ed Tomi Valkeinen, Inki Dae, Donghwa Lee, Kyungmin Park


Acked-by: Jingoo Han <jg1.han at samsung.com>

Best regards,
Jingoo Han

> ---
>  drivers/video/exynos/exynos_mipi_dsi.c          | 2 --
>  drivers/video/exynos/exynos_mipi_dsi_common.c   | 2 --
>  drivers/video/exynos/exynos_mipi_dsi_lowlevel.c | 2 --
>  3 files changed, 6 deletions(-)
> 
> diff --git a/drivers/video/exynos/exynos_mipi_dsi.c b/drivers/video/exynos/exynos_mipi_dsi.c
> index fac7df6..3dd43ca 100644
> --- a/drivers/video/exynos/exynos_mipi_dsi.c
> +++ b/drivers/video/exynos/exynos_mipi_dsi.c
> @@ -35,8 +35,6 @@
> 
>  #include <video/exynos_mipi_dsim.h>
> 
> -#include <plat/fb.h>
> -
>  #include "exynos_mipi_dsi_common.h"
>  #include "exynos_mipi_dsi_lowlevel.h"
> 
> diff --git a/drivers/video/exynos/exynos_mipi_dsi_common.c
> b/drivers/video/exynos/exynos_mipi_dsi_common.c
> index c70cb89..520fc9b 100644
> --- a/drivers/video/exynos/exynos_mipi_dsi_common.c
> +++ b/drivers/video/exynos/exynos_mipi_dsi_common.c
> @@ -31,8 +31,6 @@
>  #include <video/mipi_display.h>
>  #include <video/exynos_mipi_dsim.h>
> 
> -#include <mach/map.h>
> -
>  #include "exynos_mipi_dsi_regs.h"
>  #include "exynos_mipi_dsi_lowlevel.h"
>  #include "exynos_mipi_dsi_common.h"
> diff --git a/drivers/video/exynos/exynos_mipi_dsi_lowlevel.c
> b/drivers/video/exynos/exynos_mipi_dsi_lowlevel.c
> index 95cb99a..15c5abd 100644
> --- a/drivers/video/exynos/exynos_mipi_dsi_lowlevel.c
> +++ b/drivers/video/exynos/exynos_mipi_dsi_lowlevel.c
> @@ -26,8 +26,6 @@
> 
>  #include <video/exynos_mipi_dsim.h>
> 
> -#include <mach/map.h>
> -
>  #include "exynos_mipi_dsi_regs.h"
> 
>  void exynos_mipi_dsi_func_reset(struct mipi_dsim_device *dsim)
> --
> 1.8.1.2



From jg1.han at samsung.com  Thu Apr 11 01:12:18 2013
From: jg1.han at samsung.com (Jingoo Han)
Date: Thu, 11 Apr 2013 14:12:18 +0900
Subject: [PATCH 13/30] video/s3c: move platform_data out of arch/arm
In-Reply-To: <1365638712-1028578-14-git-send-email-arnd@arndb.de>
References: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
 <1365638712-1028578-14-git-send-email-arnd@arndb.de>
Message-ID: <003301ce3673$23ae2f80$6b0a8e80$%han@samsung.com>

On Thursday, April 11, 2013 9:05 AM, Arnd Bergmann wrote:
> 
> The s3c-fb driver requires header files from the samsung platforms
> to find its platform_data definition, but this no longer works on
> multiplatform kernels, so let's move the data into a new header
> file under include/linux/platform_data.
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Cc: linux-fbdev at vger.kernel.org
> Cc: Jingoo Han <jg1.han at samsung.com>
> ---
>  arch/arm/plat-samsung/include/plat/fb.h | 50 +-----------------------------
>  drivers/video/s3c-fb.c                  |  3 +-
>  include/linux/platform_data/video_s3c.h | 54 +++++++++++++++++++++++++++++++++
>  3 files changed, 56 insertions(+), 51 deletions(-)
>  create mode 100644 include/linux/platform_data/video_s3c.h
> 

[.....]

> +struct s3c_fb_platdata {
> +	void	(*setup_gpio)(void);
> +
> +	struct s3c_fb_pd_win	*win[S3C_FB_MAX_WIN];
> +	struct fb_videomode     *vtiming;
> +
> +	u32			 vidcon0;
> +	u32			 vidcon1;
> +};
> + 

There is an unnecessary space.
When the patch is merged, this space should be removed.


Best regards,
Jingoo Han

> +#endif
> --
> 1.8.1.2



From andrew at lunn.ch  Thu Apr 11 01:24:32 2013
From: andrew at lunn.ch (Andrew Lunn)
Date: Thu, 11 Apr 2013 07:24:32 +0200
Subject: [PATCHv2 08/10] arm: kirkwood: convert QNAP TS219 to use DT for
 the PCIe interface
In-Reply-To: <20130411003301.GH28693@titan.lakedaemon.net>
References: <1365632436-25367-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1365632436-25367-9-git-send-email-thomas.petazzoni@free-electrons.com>
 <20130411003301.GH28693@titan.lakedaemon.net>
Message-ID: <20130411052432.GP13524@lunn.ch>

On Wed, Apr 10, 2013 at 08:33:01PM -0400, Jason Cooper wrote:
> On Thu, Apr 11, 2013 at 12:20:34AM +0200, Thomas Petazzoni wrote:
> > Now that the PCIe mvebu driver is usable on Kirkwood, use it instead
> > of the legacy PCIe code, since it allows to describe the PCIe
> > interfaces in the Device Tree.
> > 
> > Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> > ---
> >  arch/arm/boot/dts/kirkwood-ts219.dtsi |    7 +++++++
> >  arch/arm/mach-kirkwood/board-ts219.c  |   10 ----------
> >  2 files changed, 7 insertions(+), 10 deletions(-)
> > 
> > diff --git a/arch/arm/boot/dts/kirkwood-ts219.dtsi b/arch/arm/boot/dts/kirkwood-ts219.dtsi
> > index 64ea27c..341e1d8 100644
> > --- a/arch/arm/boot/dts/kirkwood-ts219.dtsi
> > +++ b/arch/arm/boot/dts/kirkwood-ts219.dtsi
> > @@ -74,5 +74,12 @@
> >  			status = "okay";
> >  			nr-ports = <2>;
> >  		};
> > +		pcie-controller {
> > +			status = "okay";
> > +
> > +			pcie at 1,0 {
> > +				status = "okay";
> > +			};
> > +		};
> >  	};
> >  };
> > diff --git a/arch/arm/mach-kirkwood/board-ts219.c b/arch/arm/mach-kirkwood/board-ts219.c
> > index acb0187..4695d5f 100644
> > --- a/arch/arm/mach-kirkwood/board-ts219.c
> > +++ b/arch/arm/mach-kirkwood/board-ts219.c
> > @@ -41,13 +41,3 @@ void __init qnap_dt_ts219_init(void)
> >  
> >  	pm_power_off = qnap_tsx1x_power_off;
> >  }
> > -
> > -/* FIXME: Will not work with DT. Maybe use MPP40_GPIO? */
> > -static int __init ts219_pci_init(void)
> > -{
> > -	if (machine_is_ts219())
> > -		kirkwood_pcie_init(KW_PCIE0);
> > -
> > -	return 0;
> > -}
> > -subsys_initcall(ts219_pci_init);
> 
> This doesn't look right.  There are two dts files, one for 6281, and one
> for 6282...
> 
> thx,
> 
> Jason.

Hi Jason

It has been broken for a while, hence the FIXME!

Looking at the old style code, only a machine whos bootloader passed
the machine ID ts219 has PCI. This is the only difference between
ts219 and all other similar devices that use this DT description.

The FIXME comment is referring to a comment in the code:

        MPP44_GPIO,             /* Board ID: 0: TS-11x, 1: TS-21x */

so it seems like you can read this gpio line but strictly, this tells
you how many disks bays the box has, and not if its a ts219.

I've hacked around with PCI driver on my QNAP TS119P+, which does not
have any PCI devices, and never had any problems with the driver
enabled and finding two empty PCI busses. PCI does not share any pins
with anything else. So i think it is safe to just enable it for all
devices.

I will test it out on my device and report back.

  Andrew


From daniel.lezcano at free.fr  Thu Apr 11 01:58:26 2013
From: daniel.lezcano at free.fr (Daniel Lezcano)
Date: Thu, 11 Apr 2013 07:58:26 +0200
Subject: [PATCH 13/18] ARM: tegra2: cpuidle: use init/exit common routine
In-Reply-To: <1365642100.1806.5.camel@jlo-ubuntu-64.nvidia.com>
References: <1365603743-5618-1-git-send-email-daniel.lezcano@linaro.org>
 <1365603743-5618-14-git-send-email-daniel.lezcano@linaro.org>
 <1365642100.1806.5.camel@jlo-ubuntu-64.nvidia.com>
Message-ID: <51665102.10301@free.fr>

On 04/11/2013 03:01 AM, Joseph Lo wrote:
> On Wed, 2013-04-10 at 22:22 +0800, Daniel Lezcano wrote:
>> Remove the duplicated code and use the cpuidle common code for initialization.
>>
>> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
>> ---
>>  arch/arm/mach-tegra/cpuidle-tegra20.c |   33 +--------------------------------
>>  1 file changed, 1 insertion(+), 32 deletions(-)
>>
>> diff --git a/arch/arm/mach-tegra/cpuidle-tegra20.c b/arch/arm/mach-tegra/cpuidle-tegra20.c
>> index f1f6ac4..d6c2ba6 100644
>> --- a/arch/arm/mach-tegra/cpuidle-tegra20.c
>> +++ b/arch/arm/mach-tegra/cpuidle-tegra20.c
>> @@ -70,8 +70,6 @@ static struct cpuidle_driver tegra_idle_driver = {
>>  	.safe_state_index = 0,
>>  };
>>  
>> -static DEFINE_PER_CPU(struct cpuidle_device, tegra_idle_device);
>> -
>>  #ifdef CONFIG_PM_SLEEP
>>  #ifdef CONFIG_SMP
>>  static void __iomem *pmc = IO_ADDRESS(TEGRA_PMC_BASE);
>> @@ -220,34 +218,5 @@ static int tegra20_idle_lp2_coupled(struct cpuidle_device *dev,
>>  
>>  int __init tegra20_cpuidle_init(void)
>>  {
>> -	int ret;
>> -	unsigned int cpu;
>> -	struct cpuidle_device *dev;
>> -	struct cpuidle_driver *drv = &tegra_idle_driver;
>> -
>> -#ifdef CONFIG_PM_SLEEP
>> -	tegra_tear_down_cpu = tegra20_tear_down_cpu;
>> -#endif
> Hi Daniel,
>
> Please keep these 3 lines above, just like you did for Tegra30.
>
> Thanks,
> Joseph

Oups, thanks !

  -- Daniel


From Barry.Song at csr.com  Thu Apr 11 02:09:28 2013
From: Barry.Song at csr.com (Barry Song)
Date: Thu, 11 Apr 2013 14:09:28 +0800
Subject: [PATCH] dmaengine: sirf: move driver init from module_init to
 subsys_initcall
Message-ID: <1365660568-2588-1-git-send-email-Barry.Song@csr.com>

From: Barry Song <Baohua.Song at csr.com>

if we initilize dma driver by module_init, there are still many devices
which will be initilized earlier than dma. these devices will fail to
get dma channel.
this moves dmaengine earlier than device_initcall and make dma available
for all devices.

Reported-by: Renwei Wu <Renwei.Wu at csr.com>
Signed-off-by: Barry Song <Baohua.Song at csr.com>
---
 drivers/dma/sirf-dma.c |   13 ++++++++++++-
 1 files changed, 12 insertions(+), 1 deletions(-)

diff --git a/drivers/dma/sirf-dma.c b/drivers/dma/sirf-dma.c
index 1d627e2..c35fa34 100644
--- a/drivers/dma/sirf-dma.c
+++ b/drivers/dma/sirf-dma.c
@@ -742,7 +742,18 @@ static struct platform_driver sirfsoc_dma_driver = {
 	},
 };
 
-module_platform_driver(sirfsoc_dma_driver);
+static __init int sirfsoc_dma_init(void)
+{
+	return platform_driver_register(&sirfsoc_dma_driver);
+}
+
+static void __exit sirfsoc_dma_exit(void)
+{
+	platform_driver_unregister(&sirfsoc_dma_driver);
+}
+
+subsys_initcall(sirfsoc_dma_init);
+module_exit(sirfsoc_dma_exit);
 
 MODULE_AUTHOR("Rongjun Ying <rongjun.ying at csr.com>, "
 	"Barry Song <baohua.song at csr.com>");
-- 
1.7.5.4



Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at www.csr.com. Follow CSR on Twitter at http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog


From sfr at canb.auug.org.au  Thu Apr 11 02:21:21 2013
From: sfr at canb.auug.org.au (Stephen Rothwell)
Date: Thu, 11 Apr 2013 16:21:21 +1000
Subject: linux-next: manual merge of the arm-soc tree with the arm-current tree
Message-ID: <20130411162121.02448747195d0d5fa6ce0124@canb.auug.org.au>

Hi all,

Today's linux-next merge of the arm-soc tree got conflicts in
arch/arm/configs/h7201_defconfig and arch/arm/configs/h7202_defconfig
between commit e42c3074c8f7 ("ARM: remove NWFPE and VFP emulation code
from the kernel") from the arm-current tree and commit 293eb135a924
("ARM: kill Hynix h720x platform") from the arm-soc tree.

The latter deleted the files, so I did that and can carry the fix as
necessary (no action is required).

-- 
Cheers,
Stephen Rothwell                    sfr at canb.auug.org.au
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130411/0ab6cbd7/attachment.sig>

From olof at lixom.net  Thu Apr 11 02:52:27 2013
From: olof at lixom.net (Olof Johansson)
Date: Wed, 10 Apr 2013 23:52:27 -0700
Subject: [GIT PULL] ARM: bcm281xx firmware tags
In-Reply-To: <5165A271.6060407@broadcom.com>
References: <1362451632-18806-1-git-send-email-csd@broadcom.com>
 <201303060631.03782.arnd@arndb.de> <5136F816.2070909@broadcom.com>
 <201303061128.57127.arnd@arndb.de> <5165A271.6060407@broadcom.com>
Message-ID: <20130411065227.GA31465@quad.lixom.net>

On Wed, Apr 10, 2013 at 10:33:37AM -0700, Christian Daudt wrote:
> Hi Arnd, Olof,
>  Please pull the branch below - it contains the BCM281xx l2 cache
> enabling code.
> 
>  Thanks,
>    csd
> 
> 
> The following changes since commit 07961ac7c0ee8b546658717034fe692fd12eefa9:
> 
>   Linux 3.9-rc5 (2013-03-31 15:12:43 -0700)
> 
> are available in the git repository at:
> 
>   git://github.com/broadcom/bcm11351.git tags/fw-for-3.10

Thanks, pulled into next/soc (local branch name bcm/smc-l2)


-Olof


From olof at lixom.net  Thu Apr 11 03:03:17 2013
From: olof at lixom.net (Olof Johansson)
Date: Thu, 11 Apr 2013 00:03:17 -0700
Subject: [PATCHv2 00/10] ARM: sunxi: Architecture cleanups and rework
In-Reply-To: <20130408170331.14359.52789@quantum>
References: <1364289198-11589-1-git-send-email-maxime.ripard@free-electrons.com>
 <51555CCF.2090005@free-electrons.com>
 <20130402183100.GM25867@quad.lixom.net>
 <515F0743.4010509@free-electrons.com>
 <20130408170331.14359.52789@quantum>
Message-ID: <20130411070317.GC31465@quad.lixom.net>

On Mon, Apr 08, 2013 at 10:03:31AM -0700, Mike Turquette wrote:
> Quoting Maxime Ripard (2013-04-05 10:17:55)
> > Le 02/04/2013 20:31, Olof Johansson a ?crit :
> > > On Fri, Mar 29, 2013 at 10:20:15AM +0100, Maxime Ripard wrote:
> > >> Hi Mike,
> > >>
> > >> Le 26/03/2013 10:13, Maxime Ripard a ?crit :
> > >>> Hi,
> > >>>
> > >>> This patchset is a serie of various cleanups and reworks in the sunxi
> > >>> architecture to prepare a clean landing for the next Allwinner SoC, the
> > >>> A31 (sun6i).
> > >>>
> > >>> The A31 is significantly different from the previous Allwinner SoC we
> > >>> supported, the A10 and A13, to no longer make the generic sunxi prefix
> > >>> we used in most compatible string relevant, while it should really have
> > >>> been sun4i in the first place.
> > >>>
> > >>> This set is also the occasion to cleanup the timer and irq code by
> > >>> switching to the recently introduced clocksource and irqchip
> > >>> infrastructures.
> > >>>
> > >>> This set depends on the UART patches I sent previously.
> > >>
> > >> I was meaning to take this branch, but some of the drivers changes in it
> > >> depends on the clock patches that Emilio sent and that are in clk-next.
> > >> Is it ok to merge clk-next into my branch?
> > > 
> > > All of of a <subsystem>-next branch is usually asking for trouble, since it'll
> > > cause all sorts of pain if the other maintianer is rebasing his for-next
> > > branch.
> > > 
> > > Best is to get those patches on just a minimal topic branch (that is still
> > > bisectable) that is shared between the trees.
> > > 
> > > Mike?
> > 
> > Mike, could you comment on that? I'd very much like to see this patches
> > come into 3.10.
> > 
> 
> Sorry for not seeing this earlier.  This thread ended up in my mail
> killfile somehow.
> 
> I have already merged the patches that this series depends on into my
> immutable clk-for-3.10 branch.  Unfortunately that means that they
> cannot be separated out into a shared topic branch.  However
> clk-for-3.10 is immutable and will never be rebased, so it is safe to
> pull in as a dependency.
> 
> Does that solve the issue adequately?

Yes.

> Just for reference, the clk-for-3.x branch is always a subset of
> clk-next.  Once some patches from clk-next have had some cycles in
> linux-next and enough time has passed since being merged without any
> regressions or other issues I migrate them over into clk-for-3.x.
> clk-next itself is typically just clk-for-3.x with between 3 and 10
> patches on top that may be dropped or rebased or merged into
> clk-for-3.x.

We have been burned by other maintainers that normally have stable branches
rebasing them since they thought nobody was looking and they had to fix
something. :-) So even for these cases I want to see a three-way handshake.
Like we just had.


-Olof


From hechtb at gmail.com  Thu Apr 11 03:07:10 2013
From: hechtb at gmail.com (Bastian Hecht)
Date: Thu, 11 Apr 2013 09:07:10 +0200
Subject: [PATCH] ARM: shmobile: r8a7740: Add Suspend-To-RAM modes and
 CPUIdle
In-Reply-To: <5165E929.9030309@linaro.org>
References: <1365609107-14290-1-git-send-email-hechtb+renesas@gmail.com>
 <5165E929.9030309@linaro.org>
Message-ID: <CABYn4sxEOvQhZP7GnS5-AgNjkvJJXyv4n1UjVGBjXbVq0N+9_A@mail.gmail.com>

Hello Daniel,

thanks for the consolidation efforts.

2013/4/11 Daniel Lezcano <daniel.lezcano at linaro.org>:
> On 04/10/2013 05:51 PM, Bastian Hecht wrote:
>> We add 2 sleep modes and register a CPUIdle driver that uses them.
>>
>> - A3SM PLL0 on/off:     Power domain A3SM that contains the ARM core
>>                         and the 2nd level cache with either PLL0 on
>>                       or off
>>
>> As the suspend to memory mechanism we use A3SM PLL off.
>>
>> The setup of the SYSC regarding the external IRQs is taken from
>> pm-sh7372.c from Magnus Damm.
>>
>> Signed-off-by: Bastian Hecht <hechtb+renesas at gmail.com>
>> ---
>> Ok I need to add some remarks here:
>>
>> First this patch relies on a fix I've sent out today:
>> "ARM: hw_breakpoint: Do not use __cpuinitdata for dbg_cpu_pm_nb"
>> Without it we can't use suspend at all without a kernel panic.
>>
>> Next you can test this in two ways:
>> Either add IRQF_NO_SUSPEND to the touchscreen driver st1232 at IRQ registration
>> (hack) or extend the irqpin driver to support wakeup devices properly, meaning
>> adding suspend and resume callbacks that handle it (proper way). Or you can add
>> no_console_suspend to the boot options in r8a7740-armadillo800eva.dts. This way
>> you can use the serial console as wakeup device.
>>
>>
>>  arch/arm/mach-shmobile/Makefile               |    2 +-
>>  arch/arm/mach-shmobile/include/mach/r8a7740.h |    2 +
>>  arch/arm/mach-shmobile/pm-r8a7740.c           |  220 ++++++++++++++++++++++++-
>>  arch/arm/mach-shmobile/sleep-r8a7740.S        |   68 ++++++++
>>  4 files changed, 289 insertions(+), 3 deletions(-)
>>  create mode 100644 arch/arm/mach-shmobile/sleep-r8a7740.S
>>
>> diff --git a/arch/arm/mach-shmobile/Makefile b/arch/arm/mach-shmobile/Makefile
>> index 068f1da..0568894 100644
>> --- a/arch/arm/mach-shmobile/Makefile
>> +++ b/arch/arm/mach-shmobile/Makefile
>> @@ -30,7 +30,7 @@ obj-$(CONFIG_SUSPEND)               += suspend.o
>>  obj-$(CONFIG_CPU_IDLE)               += cpuidle.o
>>  obj-$(CONFIG_ARCH_SHMOBILE)  += pm-rmobile.o
>>  obj-$(CONFIG_ARCH_SH7372)    += pm-sh7372.o sleep-sh7372.o
>> -obj-$(CONFIG_ARCH_R8A7740)   += pm-r8a7740.o
>> +obj-$(CONFIG_ARCH_R8A7740)   += pm-r8a7740.o sleep-r8a7740.o
>>  obj-$(CONFIG_ARCH_R8A7779)   += pm-r8a7779.o
>>  obj-$(CONFIG_ARCH_SH73A0)    += pm-sh73a0.o
>>
>> diff --git a/arch/arm/mach-shmobile/include/mach/r8a7740.h b/arch/arm/mach-shmobile/include/mach/r8a7740.h
>> index abdc4d4..ba4707b 100644
>> --- a/arch/arm/mach-shmobile/include/mach/r8a7740.h
>> +++ b/arch/arm/mach-shmobile/include/mach/r8a7740.h
>> @@ -540,6 +540,8 @@ extern void r8a7740_add_standard_devices(void);
>>  extern void r8a7740_clock_init(u8 md_ck);
>>  extern void r8a7740_pinmux_init(void);
>>  extern void r8a7740_pm_init(void);
>> +extern void r8a7740_resume(void);
>> +extern void r8a7740_shutdown(void);
>>
>>  #ifdef CONFIG_PM
>>  extern void __init r8a7740_init_pm_domains(void);
>> diff --git a/arch/arm/mach-shmobile/pm-r8a7740.c b/arch/arm/mach-shmobile/pm-r8a7740.c
>> index 40b87aa..d4613f0 100644
>> --- a/arch/arm/mach-shmobile/pm-r8a7740.c
>> +++ b/arch/arm/mach-shmobile/pm-r8a7740.c
>> @@ -8,10 +8,54 @@
>>   * License.  See the file "COPYING" in the main directory of this archive
>>   * for more details.
>>   */
>> +#include <linux/bitrev.h>
>>  #include <linux/console.h>
>> +#include <linux/cpuidle.h>
>> +#include <linux/module.h>
>>  #include <linux/suspend.h>
>> +#include <linux/io.h>
>> +#include <asm/suspend.h>
>> +#include <asm/cacheflush.h>
>> +#include <asm/cpuidle.h>
>> +#include <asm/hardware/cache-l2x0.h>
>>  #include <mach/pm-rmobile.h>
>>  #include <mach/common.h>
>> +#include <mach/r8a7740.h>
>> +
>> +/* CPGA */
>> +#define PLLC01STPCR  IOMEM(0xe61500c8)
>> +#define SYSTBCR              IOMEM(0xe6150024)
>> +
>> +/* SYSC */
>> +#define STBCHR               IOMEM(0xe6180000)
>> +#define STBCHRB              IOMEM(0xe6180040)
>> +#define SPDCR                IOMEM(0xe6180008)
>> +#define SBAR         IOMEM(0xe6180020)
>> +#define SRSTFR               IOMEM(0xe61800B4)
>> +#define WUPSMSK              IOMEM(0xe618002c)
>> +#define WUPSMSK2     IOMEM(0xe6180048)
>> +#define WUPSFAC              IOMEM(0xe6180098)
>> +#define IRQCR                IOMEM(0xe618022c)
>> +#define IRQCR2               IOMEM(0xe6180238)
>> +#define IRQCR3               IOMEM(0xe6180244)
>> +#define IRQCR4               IOMEM(0xe6180248)
>> +
>> +/* SRSTFR flags */
>> +#define RAMST                (1 << 19)
>> +#define RCLNKA               (1 << 7)
>> +#define RCPRES               (1 << 5)
>> +#define RCWD1                (1 << 4)
>> +#define RPF          (1 << 0)
>> +
>> +/* INTC */
>> +#define ICR1A                IOMEM(0xe6900000)
>> +#define ICR2A                IOMEM(0xe6900004)
>> +#define ICR3A                IOMEM(0xe6900008)
>> +#define ICR4A                IOMEM(0xe690000c)
>> +#define INTMSK00A    IOMEM(0xe6900040)
>> +#define INTMSK10A    IOMEM(0xe6900044)
>> +#define INTMSK20A    IOMEM(0xe6900048)
>> +#define INTMSK30A    IOMEM(0xe690004c)
>>
>>  #ifdef CONFIG_PM
>>  static int r8a7740_pd_a4s_suspend(void)
>> @@ -58,12 +102,183 @@ void __init r8a7740_init_pm_domains(void)
>>       rmobile_init_domains(r8a7740_pm_domains, ARRAY_SIZE(r8a7740_pm_domains));
>>       pm_genpd_add_subdomain_names("A4S", "A3SP");
>>  }
>> -
>>  #endif /* CONFIG_PM */
>>
>> +#if defined(CONFIG_SUSPEND) || defined(CONFIG_CPU_IDLE)
>> +static void r8a7740_set_reset_vector(unsigned long address)
>> +{
>> +     __raw_writel(address, SBAR);
>> +}
>> +
>> +static void r8a7740_icr_to_irqcr(unsigned long icr, u16 *irqcr1p, u16 *irqcr2p)
>> +{
>> +     u16 tmp, irqcr1, irqcr2;
>> +     int k;
>> +
>> +     irqcr1 = 0;
>> +     irqcr2 = 0;
>> +
>> +     /* convert INTCA ICR register layout to SYSC IRQCR+IRQCR2 */
>> +     for (k = 0; k <= 7; k++) {
>> +             tmp = (icr >> ((7 - k) * 4)) & 0xf;
>> +             irqcr1 |= (tmp & 0x03) << (k * 2);
>> +             irqcr2 |= (tmp >> 2) << (k * 2);
>> +     }
>> +
>> +     *irqcr1p = irqcr1;
>> +     *irqcr2p = irqcr2;
>> +}
>> +
>> +static void r8a7740_setup_sysc(unsigned long msk, unsigned long msk2)
>> +{
>> +     u16 irqcrx_low, irqcrx_high, irqcry_low, irqcry_high;
>> +     unsigned long tmp;
>> +
>> +     /* read IRQ0A -> IRQ15A mask */
>> +     tmp = bitrev8(__raw_readb(INTMSK00A));
>> +     tmp |= bitrev8(__raw_readb(INTMSK10A)) << 8;
>> +
>> +     /* setup WUPSMSK from clocks and external IRQ mask */
>> +     msk = (~msk & 0xc030000f) | (tmp << 4);
>> +     __raw_writel(msk, WUPSMSK);
>> +
>> +     /* propage level/edge trigger for external IRQ 0->15 */
>> +     r8a7740_icr_to_irqcr(__raw_readl(ICR1A), &irqcrx_low, &irqcry_low);
>> +     r8a7740_icr_to_irqcr(__raw_readl(ICR2A), &irqcrx_high, &irqcry_high);
>> +     __raw_writel((irqcrx_high << 16) | irqcrx_low, IRQCR);
>> +     __raw_writel((irqcry_high << 16) | irqcry_low, IRQCR2);
>> +
>> +     /* read IRQ16A -> IRQ31A mask */
>> +     tmp = bitrev8(__raw_readb(INTMSK20A));
>> +     tmp |= bitrev8(__raw_readb(INTMSK30A)) << 8;
>> +
>> +     /* setup WUPSMSK2 from clocks and external IRQ mask */
>> +     msk2 = (~msk2 & 0x00030000) | tmp;
>> +     __raw_writel(msk2, WUPSMSK2);
>> +
>> +     /* propage level/edge trigger for external IRQ 16->31 */
>> +     r8a7740_icr_to_irqcr(__raw_readl(ICR3A), &irqcrx_low, &irqcry_low);
>> +     r8a7740_icr_to_irqcr(__raw_readl(ICR4A), &irqcrx_high, &irqcry_high);
>> +     __raw_writel((irqcrx_high << 16) | irqcrx_low, IRQCR3);
>> +     __raw_writel((irqcry_high << 16) | irqcry_low, IRQCR4);
>> +}
>> +
>> +static void r8a7740_prepare_wakeup(void)
>> +{
>> +     /* clear all flags that lead to a cold boot */
>> +     __raw_writel(~(RAMST | RCLNKA | RCPRES | RCWD1 | RPF), SRSTFR);
>> +     /* indicate warm boot */
>> +     __raw_writel(0x80000000, STBCHRB);
>> +     /* clear other flags checked by internal ROM boot loader */
>> +     __raw_writel(0x00000000, STBCHR);
>> +}
>> +
>> +static int r8a7740_do_suspend(unsigned long unused)
>> +{
>> +     /*
>> +      * cpu_suspend() guarantees that all data made it to the L2.
>> +      * Flush it out now and disable the cache controller.
>> +      */
>> +     outer_flush_all();
>> +     outer_disable();
>> +
>> +     r8a7740_shutdown();
>> +
>> +     /* in case WFI fails to enter the low power state, restore things */
>> +     outer_resume();
>> +
>> +     return 0;
>> +}
>> +
>> +static void r8a7740_enter_a3sm_common(int pllc0_on)
>> +{
>> +     u32 reg32;
>> +
>> +     if (pllc0_on)
>> +             __raw_writel(0, PLLC01STPCR);
>> +     else
>> +             __raw_writel(1 << 28, PLLC01STPCR);
>> +
>> +     r8a7740_set_reset_vector(__pa(r8a7740_resume));
>> +     r8a7740_prepare_wakeup();
>> +     r8a7740_setup_sysc(1 << 0, 0);
>> +
>> +     /* Activate delayed shutdown of A3SM */
>> +     reg32 = __raw_readl(SPDCR);
>> +     reg32 |= (1 << 31) | (1 << 12);
>> +     __raw_writel(reg32, SPDCR);
>> +
>> +     /* We activate CPU Core Standby as well here */
>> +     reg32 = __raw_readl(SYSTBCR);
>> +     reg32 |= (1 << 4);
>> +     __raw_writel(reg32, SYSTBCR);
>> +
>> +     /* Clear Wakeup Factors and do suspend */
>> +     reg32 = __raw_readl(WUPSFAC);
>> +     cpu_suspend(0, r8a7740_do_suspend);
>> +     outer_resume();
>> +     reg32 = __raw_readl(WUPSFAC);
>> +
>> +     /* Clear CPU Core Standby flag for other WFI instructions */
>> +     reg32 &= ~(1 << 4);
>> +     __raw_writel(reg32, SYSTBCR);
>> +
>> +}
>> +#endif /* CONFIG_SUSPEND || CONFIG_CPU_IDLE */
>> +
>> +#ifdef CONFIG_CPU_IDLE
>> +static int r8a7740_enter_a3sm_pll_on(struct cpuidle_device *dev,
>> +                                     struct cpuidle_driver *drv, int index)
>> +{
>> +     r8a7740_enter_a3sm_common(1);
>> +     return 1;
>> +}
>> +
>> +static int r8a7740_enter_a3sm_pll_off(struct cpuidle_device *dev,
>> +                                     struct cpuidle_driver *drv, int index)
>> +{
>> +     r8a7740_enter_a3sm_common(0);
>> +     return 2;
>> +}
>> +
>> +static struct cpuidle_driver r8a7740_cpuidle_driver = {
>> +     .name                   = "r8a7740_cpuidle",
>> +     .owner                  = THIS_MODULE,
>> +     .en_core_tk_irqen       = 1,
>> +     .state_count            = 3,
>> +     .safe_state_index       = 0, /* C1 */
>> +     .states[0] = ARM_CPUIDLE_WFI_STATE,
>> +     .states[0].enter = shmobile_enter_wfi,
>
> The WFI macro already set a simple enter function doing cpu_do_idle.

Oh yes, I'll remove it.

> We are trying to consolidate the cpuidle drivers across the different
> platforms [1]. One of the objective is to move the cpuidle drivers to
> drivers/cpuidle, a place where they belong to.
>
> Do you think it is possible you split your code to have one part with
> the cpuidle driver and another part with the PM code ?

Hmm. The CPUIdle part is enclosed in the #ifdef CONFIG_CPU_IDLE part anyway.
The other part (CONFIG_SUSPEND | CONFIG_CPU_IDLE) contains the part
that actually does drive down the hardware and is needed as soon as
SUSPEND or CPUIdle is used.

So is it split well enough already or does it help if I split my patch
into 2, first adding suspend and then CPUIdle to the same file? But
the outcome will be the same I think.

Cheers,

 Bastian


From tangchen at cn.fujitsu.com  Thu Apr 11 03:41:36 2013
From: tangchen at cn.fujitsu.com (Tang Chen)
Date: Thu, 11 Apr 2013 15:41:36 +0800
Subject: [PATCH 0/2] mm: vmemmap: add vmemmap_verify check for hot-add
 node/memory case
In-Reply-To: <CAE9FiQVaByGOTjLVthRkEze_ekXm5LAKgKdHzrD+q1iYmjgZFQ@mail.gmail.com>
References: <1365415000-10389-1-git-send-email-linfeng@cn.fujitsu.com>
 <CAE9FiQVaByGOTjLVthRkEze_ekXm5LAKgKdHzrD+q1iYmjgZFQ@mail.gmail.com>
Message-ID: <51666930.6090702@cn.fujitsu.com>

Hi Yinghai,

(Add cc Liu Jiang.)

On 04/09/2013 02:40 AM, Yinghai Lu wrote:
> On Mon, Apr 8, 2013 at 2:56 AM, Lin Feng<linfeng at cn.fujitsu.com>  wrote:
>> In hot add node(memory) case, vmemmap pages are always allocated from other
>> node,
>
> that is broken, and should be fixed.
> vmemmap should be on local node even for hot add node.
>

I want some info sharing. :)

Here is the work I'm trying to do.

1. As most of people don't like movablemem_map idea, we decide to
    drop "specifying physical address" thing, and restart a new solution
    to support using SRAT info only.

    We want to modify movablecore to support "movablecore=acpi" to
    enable/disable limiting hotpluggable memory in ZONE_MOVABLE.
    And we dropped all the old design and data structures.

2. As Liu Jiang mentioned before, we can add a flag to memblock to mark
    special memory. Since we are dropping all the old data structures,
    I think I want to reuse his idea to reserve movable memory with memblock
    when booting.

3. If we add flag to memblock, we can mark different memory. And I remember
    you mentioned before that we can use memblock to reserve local node 
data
    for node-life-cycle data, like vmemmap, pagetable.

    So are you doing the similar work now ?

    If not, I think I can merge it into mine, and push a new patch-set with
    hot-add, hot-remove code modified to support putting vmemmap, 
pagetable,
    pgdat, page_cgroup, ..., on local node.

    If you are doing the similar work, I will only finish my work and wait
    for your patch.

Thanks. :)












From michal.bachraty at streamunlimited.com  Thu Apr 11 03:44:47 2013
From: michal.bachraty at streamunlimited.com (Michal Bachraty)
Date: Thu, 11 Apr 2013 09:44:47 +0200
Subject: [PATCH v7] clk: add si5351 i2c common clock driver
In-Reply-To: <5165A0FD.5030308@gmail.com>
References: <1365439617-18816-1-git-send-email-sebastian.hesselbarth@gmail.com>
 <14854575.YAd2OMKOy9@ganymedes> <5165A0FD.5030308@gmail.com>
Message-ID: <11205025.2MA5VbIUoF@ganymedes>

Hi Sebastian,

On Wednesday, April 10, 2013 19:27:25 Sebastian Hesselbarth wrote:
> Hmm, is there any driver using the clock output? Does it
> clk_prepare_enable() the clock? I tend not to mess with anything the
> bootloader or eeprom config left disabled. It works for me, but here the
> driver will prepare/enable the clock prior use.

For my case, disabled clock outputs in bootloader are correct. I'm working on 
module board with lot of purposes. For one I need to tune frequncy, for other 
not. In some cases I can use  clk_prepare_enable. For now, I need to tune clk, 
so I can't use clk_prepare_enable. Si5351 chip has no problem with enabling 
clock output multiple times, when calling clk_set_rate. So if this feature 
will not be in driver, I need to stay with patch upon driver.

Many thaks for writting driver,

Michal



From rogerq at ti.com  Thu Apr 11 03:48:56 2013
From: rogerq at ti.com (Roger Quadros)
Date: Thu, 11 Apr 2013 10:48:56 +0300
Subject: [RFC][PATCH 1/2] ARM: OMAP4: clock: Add device tree support for
 AUXCLKs
In-Reply-To: <20130410173921.GA31017@kahuna>
References: <515D2D30.3000306@ti.com> <20130404164137.GH10155@atomide.com>
 <515EA9E3.1010409@ti.com> <20130405155851.GA10155@atomide.com>
 <5163E589.1040809@ti.com> <20130409164928.GL10155@atomide.com>
 <20130409174319.GP10155@atomide.com> <20130409204900.GA8815@kahuna>
 <20130410080630.14359.68178@quantum> <5165453E.6090503@ti.com>
 <20130410173921.GA31017@kahuna>
Message-ID: <51666AE8.9060602@ti.com>

On 04/10/2013 08:39 PM, Nishanth Menon wrote:
> On 13:55-20130410, Roger Quadros wrote:
>> On 04/10/2013 11:06 AM, Mike Turquette wrote:
>>> Quoting Nishanth Menon (2013-04-09 13:49:00)
>>>> On 10:43-20130409, Tony Lindgren wrote:
>>>>> * Tony Lindgren <tony at atomide.com> [130409 09:54]:
>>>>>> * Roger Quadros <rogerq at ti.com> [130409 03:00]:
>>>>>>> On 04/05/2013 06:58 PM, Tony Lindgren wrote:
>>>>>>>>
>>>>>>>> Can't you just use the clock name there to get it?
>>>>>>>
>>>>>>> In device tree we don't pass around clock names. You can either get
>>>>>>> a phandle or an index to the clock.
>>>>>>>
>>>>>>> e.g. Documentation/devicetree/bindings/clock/imx31-clock.txt
>>>>>>
>>>>>> Yes I understand that. But the driver/clock/omap driver can just
>>>>>> remap the DT device initially so the board specific clock is
>>>>>> found from the clock alias table. Basically initially a passthrough
>>>>>> driver that can be enhanced to parse DT clock bindings and load
>>>>>> data from /lib/firmware.
>>>>>
>>>>> Actually probably the driver/clock/omap can even do even less
>>>>> initially. There probably even no need to remap clocks there.
>>>>>
>>>>> As long as the DT clock driver understands that a board specific
>>>>> auxclk is specified in the DT it can just call clk_add_alias() so
>>>>> the driver will get the right auxclk from cclock44xx_data.c.
>>>>>
>>>>> Then other features can be added later on like to allocate a
>>>>> clock entirely based on the binding etc.
>>>> I did try to have an implementation for cpufreq using clock nodes.
>>>> unfortunately, device tree wont let me have arguments of strings :(
>>>> So, I am unable to do clock = <&clk mpu_dpll>;
>>>> instead, I am forced to do clock = <&clk 249>;
>>>>
>>>
>>> See http://article.gmane.org/gmane.linux.ports.arm.kernel/229034
>>>
>>
>> Awesome. Thanks for pointing this out Mike.
>>
>> Now all we need to do is create a named define for each clock index in the
>> header file.
> Approach #3: Thanks to Tony for collaborating on this:
> Works for cpufreq-cpu0 - additional patches:
> http://pastebin.com/GHnTRVJf, http://pastebin.com/FZS89J6L (tested on
> beagleXM)
> Work for USB - http://pastebin.com/aJpDnXci - thanks Roger for testing
> this.
> Details in the patch below (Tony, I have added you as collaborator for
> helping in getting this working-clk_add_alias was'nt needed in the
> internal patch discussion we had - I have taken a bit of freedom in
> adding your contributions to the patch below)
> 
> Folks, this does seem to be the best compromise we can achieve at this
> point in time. feedback on this approach is much appreciated - if folks
> are ok, I can post this as an formal patch series.

This looks fine to me. Minor comments below.

> 
> From 130a41821bf57081ca45ef654029175d173135e6 Mon Sep 17 00:00:00 2001
> From: Nishanth Menon <nm at ti.com>
> Date: Tue, 9 Apr 2013 19:26:40 -0500
> Subject: [RFC PATCH] clk: OMAP: introduce device tree binding to kernel clock
>  data
> 
> OMAP clock data is located in arch/arm/mach-omap2/cclockXYZ_data.c.
> However, this presents an obstacle for using these clock nodes in
> Device Tree definitions. There are many possible approaches to this
> problem as discussed in the following thread:
> http://marc.info/?t=136370325600009&r=1&w=2
> Highlights of the options:
> a) device specific clk_add_alias:
> 	cons: driver handling required
> b) using an generic clk node and indexing to reach the clock required.
>    This is similar in approach taken by tegra and few other platforms.
>    example clock = <&clk 5>;
>    cons: potential to have mismatches in indexed table and associated
>    dtb data. In addition, managing continued documentation in bindings
>    as clock indexing increases. Even though readability angle could be
>    improved by using preprocessing of DT using macros, indexed approach
>    is inherently risky from cases like the following:
>    clk indexes in kernel:
>    1 - mpu_dpll
>    2 - aux_clk1
>    3 - core_clk
>    DT entry for peripheral x uses <&clk 2>, kernel updates to:
>    1 - mpu_dpll
>    2 - per_dpll
>    3 - aux_clk1
>    4 - core_clk
>    using the old dtb(or dts missing an update), on new kernel which has
>    updated indices will result in per_dpll now controlled for peripheral
>    X without warning or any potential error detection and warning.
> 
>    Even though we can claim this is user error, such errors are hard to
>    track down and fix.
> 
> An alternate approach introduced here is to introduce device tree bindings
> corresponding to the clock nodes required in DT definition for SoC which
> automatically maps back to the definitions in cclockXYZ_data.c.
> 
> The driver introduced here to do this mapping will eventually be the
> place where the clock handling will migrate to. We need to consider this
> angle as well so that the solution will be an valid transition point for
> moving the clock data out of kernel image (into device tree or firmware load
> etc..).
> 
> Overall strategy introduced here is simple: an clock node described in

typo: "an"->"a"

> device tree blob is used to identify the exact clock provided in the SoC
> specific data. This is then linked back using of_clk_add_provider to the
> device node to be accessible by of_clk_get.
> 
> Based on discussion contributions from Roger Quadros, Grygorii Strashko
> and others.
> 
> [tony at atomide.com: co-developed]
> Signed-off-by: Tony Lindgren <tony at atomide.com>
> Signed-off-by: Nishanth Menon <nm at ti.com>
> ---
>  .../devicetree/bindings/clock/omap-clock.txt       |   40 +++++++++
>  drivers/clk/Makefile                               |    1 +
>  drivers/clk/omap/Makefile                          |    1 +
>  drivers/clk/omap/clk.c                             |   94 ++++++++++++++++++++
>  4 files changed, 136 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/clock/omap-clock.txt
>  create mode 100644 drivers/clk/omap/Makefile
>  create mode 100644 drivers/clk/omap/clk.c
> 
> diff --git a/Documentation/devicetree/bindings/clock/omap-clock.txt b/Documentation/devicetree/bindings/clock/omap-clock.txt
> new file mode 100644
> index 0000000..07e3ff8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/omap-clock.txt
> @@ -0,0 +1,40 @@
> +Device Tree Clock bindings for Texas Instrument's OMAP compatible platforms
> +
> +This binding is a work-in-progress, and meant to be stage #1 of transitioning
> +OMAP clock data out of kernel image.
> +
> +This binding uses the common clock binding[1].
> +
> +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
> +
> +Required properties:
> +- compatible : shall be "ti,omap-clock"
> +- #clock-cells : from common clock binding; shall be set to 0.
> +NOTE:
> +node name should map to clock database in arch/arm/mach-omap2/cclock<SoC>_data.c
> +Since all clocks are described with _ck, the node name is optimized to drop the
> +usage of _ck. For example, a clock called dpll1_ck will be defined as dpll1.
> +
> +Example #1: describing clock node for CPU on OMAP34xx platform:
> +Ref: arch/arm/mach-omap2/cclock3xxx_data.c
> +describes the CPU clock to be as follows
> +	CLK(NULL,	"dpll1_ck",	&dpll1_ck,	CK_3XXX),
> +Corresponding binding will be:
> +	dpll1: dpll1 {
> +		#clock-cells = <0>;
> +		compatible = "ti,omap-clock";
> +	};
> +And it's usage will be:
> +		clocks = <&dpll1>;
> +
> +Example #2: describing clock node for auxilary clock #3 on OMAP443x platform:
> +Ref: arch/arm/mach-omap2/cclock44xx_data.c
> +describes the auxclk3 clock to be as follows:
> +	CLK(NULL,	"auxclk3_ck",	&auxclk3_ck,	CK_443X),
> +Corresponding binding will be:
> +	auxclk3: auxclk3 {
> +		#clock-cells = <1>;
> +		compatible = "ti,omap-clock";
> +	};
> +And it's usage will be:
> +	clocks = <&auxclk3>;
> diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
> index 300d477..a0209d7 100644
> --- a/drivers/clk/Makefile
> +++ b/drivers/clk/Makefile
> @@ -27,6 +27,7 @@ obj-$(CONFIG_ARCH_U8500)	+= ux500/
>  obj-$(CONFIG_ARCH_VT8500)	+= clk-vt8500.o
>  obj-$(CONFIG_ARCH_ZYNQ)		+= clk-zynq.o
>  obj-$(CONFIG_ARCH_TEGRA)	+= tegra/
> +obj-$(CONFIG_ARCH_OMAP)		+= omap/
>  
>  obj-$(CONFIG_X86)		+= x86/
>  
> diff --git a/drivers/clk/omap/Makefile b/drivers/clk/omap/Makefile
> new file mode 100644
> index 0000000..8195931
> --- /dev/null
> +++ b/drivers/clk/omap/Makefile
> @@ -0,0 +1 @@
> +obj-y					+= clk.o
> diff --git a/drivers/clk/omap/clk.c b/drivers/clk/omap/clk.c
> new file mode 100644
> index 0000000..63a4cce
> --- /dev/null
> +++ b/drivers/clk/omap/clk.c
> @@ -0,0 +1,94 @@
> +/*
> + * Texas Instruments OMAP Clock driver
> + *
> + * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
> + *	Nishanth Menon

missing e-mail id.

> + *	Tony Lindgren <tony at atomide.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.
> + *
> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
> + * kind, whether express or implied; without even the implied warranty
> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include <linux/clkdev.h>
> +#include <linux/clk-private.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/of_device.h>
> +#include <linux/platform_device.h>
> +#include <linux/string.h>
> +
> +static const struct of_device_id omap_clk_of_match[] = {
> +	{.compatible = "ti,omap-clock",},
> +	{},
> +};
> +
> +MODULE_DEVICE_TABLE(of, omap_clk_of_match);
> +
Is this driver ever going to be a loadable module? If not then you don't need this.

> +/**
> + * omap_clk_probe() - create link from DT definition to clock data
> + * @pdev:	device node
> + *
> + * REVISIT: We are now assuming the following:
> + * 1. omap clock names end with _ck
> + * 2. omap clocks don't get removed
> + */
> +static int omap_clk_probe(struct platform_device *pdev)
> +{
> +	struct clk *clk;
> +	int res;
> +
> +	const struct of_device_id *match;
> +	struct device_node *np = pdev->dev.of_node;
> +	char clk_name[32];
> +
> +	match = of_match_device(omap_clk_of_match, &pdev->dev);
> +
> +	/* Set up things so consumer can call clk_get() with name */
> +	snprintf(clk_name, 32, "%s_ck", np->name);
> +	clk = clk_get(NULL, clk_name);
> +	if (IS_ERR(clk)) {
> +		res = PTR_ERR(clk);
> +		dev_err(&pdev->dev, "could not get clock %s (%d)\n",
> +			clk_name, res);
> +		goto out;
> +	}
> +
> +	/* This allows the driver to of_clk_get() */
> +	res = of_clk_add_provider(np, of_clk_src_simple_get, clk);
> +	if (res)
> +		dev_err(&pdev->dev, "could not add provider for %s (%d)\n",
> +			clk_name, res);
> +
> +	clk_put(clk);
> +out:
> +	return res;
> +}
> +
> +MODULE_ALIAS("platform:omap_clk");

ditto.

> +
> +/* We assume here that OMAP clocks will not be removed */
> +static struct platform_driver omap_clk_driver = {
> +	.probe = omap_clk_probe,
> +	.driver = {
> +		   .name = "omap_clk",
> +		   .owner = THIS_MODULE,

same here.

> +		   .of_match_table = of_match_ptr(omap_clk_of_match),
> +		   },
> +};
> +
> +static int __init omap_clk_init(void)
> +{
> +	return platform_driver_register(&omap_clk_driver);
> +}
> +
> +arch_initcall(omap_clk_init);
> +
> +MODULE_DESCRIPTION("OMAP Clock driver");
> +MODULE_AUTHOR("Texas Instruments Inc.");
> +MODULE_LICENSE("GPL v2");
> 

cheers,
-roger


From hechtb at gmail.com  Thu Apr 11 04:01:57 2013
From: hechtb at gmail.com (Bastian Hecht)
Date: Thu, 11 Apr 2013 10:01:57 +0200
Subject: [PATCH v3 2/7] clocksource: sh_cmt: Add OF support
In-Reply-To: <CABYn4sw20M=KB9kJN8HOD4ofdknSSKrUNzpss2e9aG-ELRMNrg@mail.gmail.com>
References: <1363535031-21402-1-git-send-email-hechtb+renesas@gmail.com>
 <1363535031-21402-2-git-send-email-hechtb+renesas@gmail.com>
 <20130321130714.GE24470@verge.net.au>
 <20130409133805.GA21875@verge.net.au>
 <CABYn4sw20M=KB9kJN8HOD4ofdknSSKrUNzpss2e9aG-ELRMNrg@mail.gmail.com>
Message-ID: <CABYn4sy4oGiSAxyi86i=KGuuNWHDQQzj=vsVYX4hJerAs9+U_w@mail.gmail.com>

Hi Simon,

2013/4/9 Bastian Hecht <hechtb at gmail.com>:
> Hi Simon,
>
> 2013/4/9 Simon Horman <horms at verge.net.au>:
>> On ?,  3? 21, 2013 at 10:07:15?? +0900, Simon Horman wrote:
>>> On Sun, Mar 17, 2013 at 04:43:46PM +0100, Bastian Hecht wrote:
>>> > We add the capabilty to probe SH CMT timer devices using Device Tree
>>> > setup.
>>> >
>>> > Signed-off-by: Bastian Hecht <hechtb+renesas at gmail.com>
>>> > ---
>>> > v3: same (only patch 0003 changed)
>>> >
>>> >  drivers/clocksource/sh_cmt.c |  109 +++++++++++++++++++++++++++++++++++++-----
>>>
>>>
>>> This change appears to break booting of kzm9g-reference
>>> with MMC enabled. I assume because it somehow causes CMT to
>>> (once again) be initialised after SDHI and/or MMC.
>>>
>>> Tested using next with the defconfig + CONFIG_MACH_KZM9G_REFERENCE=y +
>>> initrd root fs.
>>
>
> Thanks for finding this flaw. I've got it on my agenda.
>
> Bastian
>
>>> >  1 file changed, 96 insertions(+), 13 deletions(-)
>>> >
>>> > diff --git a/drivers/clocksource/sh_cmt.c b/drivers/clocksource/sh_cmt.c
>>> > index 08d0c41..79bc526 100644
>>> > --- a/drivers/clocksource/sh_cmt.c
>>> > +++ b/drivers/clocksource/sh_cmt.c
>>> > @@ -34,10 +34,13 @@
>>> >  #include <linux/module.h>
>>> >  #include <linux/pm_domain.h>
>>> >  #include <linux/pm_runtime.h>
>>> > +#include <linux/of.h>
>>> >
>>> >  struct sh_cmt_priv {
>>> >     void __iomem *mapbase;
>>> >     struct clk *clk;
>>> > +   long channel_offset;
>>> > +   int timer_bit;
>>> >     unsigned long width; /* 16 or 32 bit version of hardware block */
>>> >     unsigned long overflow_bit;
>>> >     unsigned long clear_bits;
>>> > @@ -109,9 +112,7 @@ static void sh_cmt_write32(void __iomem *base, unsigned long offs,
>>> >
>>> >  static inline unsigned long sh_cmt_read_cmstr(struct sh_cmt_priv *p)
>>> >  {
>>> > -   struct sh_timer_config *cfg = p->pdev->dev.platform_data;
>>> > -
>>> > -   return p->read_control(p->mapbase - cfg->channel_offset, 0);
>>> > +   return p->read_control(p->mapbase - p->channel_offset, 0);
>>> >  }
>>> >
>>> >  static inline unsigned long sh_cmt_read_cmcsr(struct sh_cmt_priv *p)
>>> > @@ -127,9 +128,7 @@ static inline unsigned long sh_cmt_read_cmcnt(struct sh_cmt_priv *p)
>>> >  static inline void sh_cmt_write_cmstr(struct sh_cmt_priv *p,
>>> >                                   unsigned long value)
>>> >  {
>>> > -   struct sh_timer_config *cfg = p->pdev->dev.platform_data;
>>> > -
>>> > -   p->write_control(p->mapbase - cfg->channel_offset, 0, value);
>>> > +   p->write_control(p->mapbase - p->channel_offset, 0, value);
>>> >  }
>>> >
>>> >  static inline void sh_cmt_write_cmcsr(struct sh_cmt_priv *p,
>>> > @@ -176,7 +175,6 @@ static DEFINE_RAW_SPINLOCK(sh_cmt_lock);
>>> >
>>> >  static void sh_cmt_start_stop_ch(struct sh_cmt_priv *p, int start)
>>> >  {
>>> > -   struct sh_timer_config *cfg = p->pdev->dev.platform_data;
>>> >     unsigned long flags, value;
>>> >
>>> >     /* start stop register shared by multiple timer channels */
>>> > @@ -184,9 +182,9 @@ static void sh_cmt_start_stop_ch(struct sh_cmt_priv *p, int start)
>>> >     value = sh_cmt_read_cmstr(p);
>>> >
>>> >     if (start)
>>> > -           value |= 1 << cfg->timer_bit;
>>> > +           value |= 1 << p->timer_bit;
>>> >     else
>>> > -           value &= ~(1 << cfg->timer_bit);
>>> > +           value &= ~(1 << p->timer_bit);
>>> >
>>> >     sh_cmt_write_cmstr(p, value);
>>> >     raw_spin_unlock_irqrestore(&sh_cmt_lock, flags);
>>> > @@ -673,9 +671,85 @@ static int sh_cmt_register(struct sh_cmt_priv *p, char *name,
>>> >     return 0;
>>> >  }
>>> >
>>> > -static int sh_cmt_setup(struct sh_cmt_priv *p, struct platform_device *pdev)
>>> > +static const struct of_device_id of_sh_cmt_match[] = {
>>> > +   { .compatible = "renesas,cmt-timer" },
>>> > +   {},
>>> > +};
>>> > +MODULE_DEVICE_TABLE(of, of_sh_cmt_match);
>>> > +
>>> > +static const int sh_cmt_offset_multiplier[] = { 0x60, 0x10, 0x40, 0x40, 0x40 };
>>> > +#define CMT_MAX_CHANNELS   6
>>> > +
>>> > +static struct sh_timer_config *sh_cmt_parse_dt(struct device *dev)
>>> > +{
>>> > +   struct sh_timer_config *cfg;
>>> > +   struct device_node *np = dev->of_node;
>>> > +   u32 timer_id, channel_id, rating;
>>> > +
>>> > +   if (!IS_ENABLED(CONFIG_OF) || !np)
>>> > +           return NULL;
>>> > +
>>> > +   cfg = devm_kzalloc(dev, sizeof(struct sh_timer_config), GFP_KERNEL);
>>> > +   if (!cfg) {
>>> > +           dev_err(dev, "failed to allocate DT config data\n");
>>> > +           return NULL;
>>> > +   }
>>> > +
>>> > +   if (of_property_read_u32(np, "renesas,device-id", &timer_id)) {
>>> > +           dev_err(dev, "device id missing\n");
>>> > +           return NULL;
>>> > +   }
>>> > +   if (timer_id >= ARRAY_SIZE(sh_cmt_offset_multiplier)) {
>>> > +           dev_err(dev, "invalid device id\n");
>>> > +           return NULL;
>>> > +   }
>>> > +
>>> > +   if (of_property_read_u32(np, "renesas,channel-id", &channel_id)) {
>>> > +           dev_err(dev, "channel id missing\n");
>>> > +           return NULL;
>>> > +   }
>>> > +   if (channel_id >= CMT_MAX_CHANNELS) {
>>> > +           dev_err(dev, "invalid channel id\n");
>>> > +           return NULL;
>>> > +   }
>>> > +
>>> > +   cfg->channel_offset = sh_cmt_offset_multiplier[timer_id] *
>>> > +                                                   (channel_id + 1);
>>> > +   cfg->timer_bit = channel_id;
>>> > +
>>> > +   /*
>>> > +    * We convert the {source,event}-quality DT properties to linux specific
>>> > +    * clock{source,event}_ratings.
>>> > +    */
>>> > +   if (!of_property_read_u32(np, "renesas,source-quality", &rating)) {
>>> > +           if (rating > 10) {
>>> > +                   dev_err(dev, "invalid source-quality\n");
>>> > +                   return NULL;
>>> > +           }
>>> > +           if (rating)
>>> > +                   cfg->clocksource_rating = rating * 50 - 1;
>>> > +   }
>>> > +
>>> > +   if (!of_property_read_u32(np, "renesas,event-quality", &rating)) {
>>> > +           if (rating > 10) {
>>> > +                   dev_err(dev, "invalid event-quality\n");
>>> > +                   return NULL;
>>> > +           }
>>> > +           if (rating)
>>> > +                   cfg->clockevent_rating = rating * 50 - 1;
>>> > +   }
>>> > +
>>> > +   if (!cfg->clocksource_rating && !cfg->clockevent_rating) {
>>> > +           dev_err(dev, "source- and event-quality 0, timer is unused\n");
>>> > +           return NULL;
>>> > +   }
>>> > +
>>> > +   return cfg;
>>> > +}
>>> > +
>>> > +static int sh_cmt_setup(struct sh_cmt_priv *p, struct platform_device *pdev,
>>> > +                                           struct sh_timer_config *cfg)
>>> >  {
>>> > -   struct sh_timer_config *cfg = pdev->dev.platform_data;
>>> >     struct resource *res;
>>> >     int irq, ret;
>>> >     ret = -ENXIO;
>>> > @@ -762,6 +836,9 @@ static int sh_cmt_setup(struct sh_cmt_priv *p, struct platform_device *pdev)
>>> >             goto err2;
>>> >     }
>>> >
>>> > +   p->channel_offset = cfg->channel_offset;
>>> > +   p->timer_bit = cfg->timer_bit;
>>> > +

This happens too late. After interrupt registration. I have to check
the TMU patch as well and I'll send out a v4 later.

Thanks again for detecting this flaw.

Bastian


>>> >     platform_set_drvdata(pdev, p);
>>> >
>>> >     return 0;
>>> > @@ -777,7 +854,7 @@ err0:
>>> >  static int sh_cmt_probe(struct platform_device *pdev)
>>> >  {
>>> >     struct sh_cmt_priv *p = platform_get_drvdata(pdev);
>>> > -   struct sh_timer_config *cfg = pdev->dev.platform_data;
>>> > +   struct sh_timer_config *cfg;
>>> >     int ret;
>>> >
>>> >     if (!is_early_platform_device(pdev)) {
>>> > @@ -785,6 +862,11 @@ static int sh_cmt_probe(struct platform_device *pdev)
>>> >             pm_runtime_enable(&pdev->dev);
>>> >     }
>>> >
>>> > +   if (pdev->dev.of_node)
>>> > +           cfg = sh_cmt_parse_dt(&pdev->dev);
>>> > +   else
>>> > +           cfg = pdev->dev.platform_data;
>>> > +
>>> >     if (p) {
>>> >             dev_info(&pdev->dev, "kept as earlytimer\n");
>>> >             goto out;
>>> > @@ -796,7 +878,7 @@ static int sh_cmt_probe(struct platform_device *pdev)
>>> >             return -ENOMEM;
>>> >     }
>>> >
>>> > -   ret = sh_cmt_setup(p, pdev);
>>> > +   ret = sh_cmt_setup(p, pdev, cfg);
>>> >     if (ret) {
>>> >             kfree(p);
>>> >             pm_runtime_idle(&pdev->dev);
>>> > @@ -824,6 +906,7 @@ static struct platform_driver sh_cmt_device_driver = {
>>> >     .remove         = sh_cmt_remove,
>>> >     .driver         = {
>>> >             .name   = "sh_cmt",
>>> > +           .of_match_table = of_match_ptr(of_sh_cmt_match),
>>> >     }
>>> >  };
>>> >
>>> > --
>>> > 1.7.9.5
>>> >
>>> > --
>>> > To unsubscribe from this list: send the line "unsubscribe linux-sh" in
>>> > the body of a message to majordomo at vger.kernel.org
>>> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>> >
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
>>> the body of a message to majordomo at vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>


From horms+renesas at verge.net.au  Thu Apr 11 04:14:59 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu, 11 Apr 2013 17:14:59 +0900
Subject: [GIT PULL] Renesas ARM based r8a7790 SoC update for v3.10
Message-ID: <1365668101-21723-1-git-send-email-horms+renesas@verge.net.au>

Hi Arnd, Hi Olof,

The following changes since commit 8585deb18580d04209a2986430aa0959ef38fce2:

  ARM: shmobile: r8a7790 SoC 64-bit DT support (2013-04-02 11:02:21 +0900)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-soc-r8a7790-for-v3.10

for you to fetch changes up to ab5fdfd5ea621b629da9bfda987af301da973525:

  ARM: shmobile: force enable of r8a7790 arch timer (2013-04-09 21:37:36 +0900)

----------------------------------------------------------------
Renesas ARM based r8a7790 SoC update for v3.10

* Force architecture timer to be activated regardless of bootloader
  - This is necessary for the lager board to boot
* Add second memory range to r8a7790 PFC device
  - This is in preparation for further PFC work.
    It should not break anything as it is not used yet.

This pull request is based on:
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git renesas-soc2-for-v3.10

----------------------------------------------------------------
Magnus Damm (2):
      ARM: shmobile: Add second I/O range for r8a7790 PFC
      ARM: shmobile: force enable of r8a7790 arch timer

 arch/arm/mach-shmobile/include/mach/r8a7790.h |    1 +
 arch/arm/mach-shmobile/setup-r8a7790.c        |   15 ++++++++++++++-
 2 files changed, 15 insertions(+), 1 deletion(-)


From horms+renesas at verge.net.au  Thu Apr 11 04:15:00 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu, 11 Apr 2013 17:15:00 +0900
Subject: [PATCH 1/2] ARM: shmobile: Add second I/O range for r8a7790 PFC
In-Reply-To: <1365668101-21723-1-git-send-email-horms+renesas@verge.net.au>
References: <1365668101-21723-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1365668101-21723-2-git-send-email-horms+renesas@verge.net.au>

From: Magnus Damm <damm at opensource.se>

Add the GPIO I/O memory range to the r8a7790 PFC device.

This extra I/O memory range is needed when using the PFC
tables to drive both pin functions (using PINCTRL or
function GPIO for old code) and actual GPIO. The goal is
however to use a separate GPIO driver in the long run
and when that happens this extra I/O memory range can
be removed.

Signed-off-by: Magnus Damm <damm at opensource.se>
Acked-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/setup-r8a7790.c |    1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-shmobile/setup-r8a7790.c b/arch/arm/mach-shmobile/setup-r8a7790.c
index 481201a..cfccf6c 100644
--- a/arch/arm/mach-shmobile/setup-r8a7790.c
+++ b/arch/arm/mach-shmobile/setup-r8a7790.c
@@ -31,6 +31,7 @@
 
 static const struct resource pfc_resources[] = {
 	DEFINE_RES_MEM(0xe6060000, 0x250),
+	DEFINE_RES_MEM(0xe6050000, 0x5050),
 };
 
 void __init r8a7790_pinmux_init(void)
-- 
1.7.10.4



From horms+renesas at verge.net.au  Thu Apr 11 04:15:01 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu, 11 Apr 2013 17:15:01 +0900
Subject: [PATCH 2/2] ARM: shmobile: force enable of r8a7790 arch timer
In-Reply-To: <1365668101-21723-1-git-send-email-horms+renesas@verge.net.au>
References: <1365668101-21723-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1365668101-21723-3-git-send-email-horms+renesas@verge.net.au>

From: Magnus Damm <damm at opensource.se>

Implement a SoC-specific timer init function for
r8a7790 that makes sure the architected timer
is started regardless of boot loader setting.

Signed-off-by: Magnus Damm <damm at opensource.se>
Tested-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/include/mach/r8a7790.h |    1 +
 arch/arm/mach-shmobile/setup-r8a7790.c        |   14 +++++++++++++-
 2 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-shmobile/include/mach/r8a7790.h b/arch/arm/mach-shmobile/include/mach/r8a7790.h
index 9bd6f5c..2e919e6 100644
--- a/arch/arm/mach-shmobile/include/mach/r8a7790.h
+++ b/arch/arm/mach-shmobile/include/mach/r8a7790.h
@@ -4,5 +4,6 @@
 void r8a7790_add_standard_devices(void);
 void r8a7790_clock_init(void);
 void r8a7790_pinmux_init(void);
+void r8a7790_timer_init(void);
 
 #endif /* __ASM_R8A7790_H__ */
diff --git a/arch/arm/mach-shmobile/setup-r8a7790.c b/arch/arm/mach-shmobile/setup-r8a7790.c
index cfccf6c..49de2d5 100644
--- a/arch/arm/mach-shmobile/setup-r8a7790.c
+++ b/arch/arm/mach-shmobile/setup-r8a7790.c
@@ -118,6 +118,18 @@ void __init r8a7790_add_standard_devices(void)
 	r8a7790_register_irqc(0);
 }
 
+void __init r8a7790_timer_init(void)
+{
+	void __iomem *cntcr;
+
+	/* make sure arch timer is started by setting bit 0 of CNTCT */
+	cntcr = ioremap(0xe6080000, PAGE_SIZE);
+	iowrite32(1, cntcr);
+	iounmap(cntcr);
+
+	shmobile_timer_init();
+}
+
 #ifdef CONFIG_USE_OF
 void __init r8a7790_add_standard_devices_dt(void)
 {
@@ -132,7 +144,7 @@ static const char *r8a7790_boards_compat_dt[] __initdata = {
 DT_MACHINE_START(R8A7790_DT, "Generic R8A7790 (Flattened Device Tree)")
 	.init_irq	= irqchip_init,
 	.init_machine	= r8a7790_add_standard_devices_dt,
-	.init_time	= shmobile_timer_init,
+	.init_time	= r8a7790_timer_init,
 	.dt_compat	= r8a7790_boards_compat_dt,
 MACHINE_END
 #endif /* CONFIG_USE_OF */
-- 
1.7.10.4



From horms+renesas at verge.net.au  Thu Apr 11 04:18:46 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu, 11 Apr 2013 17:18:46 +0900
Subject: [PATCH] ARM: shmobile: use r8a7790 timer setup code on Lager
In-Reply-To: <1365668326-22518-1-git-send-email-horms+renesas@verge.net.au>
References: <1365668326-22518-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1365668326-22518-2-git-send-email-horms+renesas@verge.net.au>

From: Magnus Damm <damm at opensource.se>

Use the r8a7790 timer init function on Lager
to make sure the architected timer is started
regardless of boot loader setting.

Signed-off-by: Magnus Damm <damm at opensource.se>
Tested-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/board-lager.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-shmobile/board-lager.c b/arch/arm/mach-shmobile/board-lager.c
index ea6f9e5..f587187 100644
--- a/arch/arm/mach-shmobile/board-lager.c
+++ b/arch/arm/mach-shmobile/board-lager.c
@@ -40,7 +40,7 @@ static const char *lager_boards_compat_dt[] __initdata = {
 
 DT_MACHINE_START(LAGER_DT, "lager")
 	.init_irq	= irqchip_init,
-	.init_time	= shmobile_timer_init,
+	.init_time	= r8a7790_timer_init,
 	.init_machine	= lager_add_standard_devices,
 	.dt_compat	= lager_boards_compat_dt,
 MACHINE_END
-- 
1.7.10.4



From horms+renesas at verge.net.au  Thu Apr 11 04:18:45 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu, 11 Apr 2013 17:18:45 +0900
Subject: [GIT PULL] Renesas ARM based SoC lager board updates for v3.10
Message-ID: <1365668326-22518-1-git-send-email-horms+renesas@verge.net.au>

Hi Arnd, Hi Olof,

Please note this is based on a merge with renesas-soc-r8a7790-for-v3.10
which corresponds to the pull request I sent a few minutes ago:
"[GIT PULL] Renesas ARM based r8a7790 SoC update for v3.10".

The following changes since commit ac119ccd80eb914185229c4c4086f3debdd4c764:

  Merge branch 'soc-r8a7790' into boards-lager (2013-04-09 21:40:20 +0900)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-boards-lager-for-v3.10

for you to fetch changes up to 65be2de17aae0fd94e55f7c4a474933cf4607ea2:

  ARM: shmobile: use r8a7790 timer setup code on Lager (2013-04-09 21:40:59 +0900)

----------------------------------------------------------------
Renesas ARM based SoC lager board updates for v3.10

* Use r8a7790 timer setup code to force the
  arch timer to be enabled regardless of the bootloader setting
  - This is necessary for the lager board to boot

This pull request is based on:
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git renesas-boards3-for-v3.10
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git renesas-soc-r8a7790-for-v3.10

The merge was made to provide the r8a7790 timer setup code

----------------------------------------------------------------
Magnus Damm (1):
      ARM: shmobile: use r8a7790 timer setup code on Lager

 arch/arm/mach-shmobile/board-lager.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


From 21cnbao at gmail.com  Thu Apr 11 04:22:03 2013
From: 21cnbao at gmail.com (Barry Song)
Date: Thu, 11 Apr 2013 16:22:03 +0800
Subject: [PATCH v8 1/7] media: V4L2: add temporary clock helpers
In-Reply-To: <Pine.LNX.4.64.1304110921480.23859@axis700.grange>
References: <CAGsJ_4zCRBvEX9xEDCr27JLK6wYp_2T_wk2hzVjqpKinbL=9pg@mail.gmail.com>
 <Pine.LNX.4.64.1304110921480.23859@axis700.grange>
Message-ID: <CAGsJ_4xXRHDbpuqT3e5=0vz9_NxxCXfvrci+h567HP9=AhwRiQ@mail.gmail.com>

2013/4/11 Guennadi Liakhovetski <g.liakhovetski at gmx.de>:
> Hi Barry
>
> On Thu, 11 Apr 2013, Barry Song wrote:
>
>> Hi Guennadi,
>>
>> > Typical video devices like camera sensors require an external clock source.
>> > Many such devices cannot even access their hardware registers without a
>> > running clock. These clock sources should be controlled by their consumers.
>> > This should be performed, using the generic clock framework. Unfortunately
>> > so far only very few systems have been ported to that framework. This patch
>> > adds a set of temporary helpers, mimicking the generic clock API, to V4L2.
>> > Platforms, adopting the clock API, should switch to using it. Eventually
>> > this temporary API should be removed.
>>
>> > Signed-off-by: Guennadi Liakhovetski <g.liakhovetski at xxxxxx>
>> > ---
>>
>> for your patch 1/8 and 3/8, i think it makes a lot of senses to let
>> the object manages its own clock by itself.
>> is it possible for us to implement v4l2-clk.c directly as an instance
>> of standard clk driver for those systems which don't have generic
>> clock,  and remove the V4L2 clock APIs like v4l2_clk_get,
>> v4l2_clk_enable from the first day? i mean v4l2-clk.c becomes a temp
>> and fake clock controller driver. finally, after people have
>> generically clk, remove it.
>
> I don't think you can force-enable the CFF on systems, that don't support
> it, e.g. PXA.

yes. we can. clock is only a framework, has it any limitation to
implement a driver instance on any platform?
people have tried to move to common clk and generic framework for a
long time, now you still try to provide a v4l2 specific clock APIs, it
just makes v4l2 unacceptable and much complex.

>
> Thanks
> Guennadi
>
>> > v8: Updated both (C) dates
>>
>> >  drivers/media/v4l2-core/Makefile   |    2 +-
>> >  drivers/media/v4l2-core/v4l2-clk.c |  177 ++++++++++++++++++++++++++++++++++++
>> >  include/media/v4l2-clk.h           |   54 +++++++++++
>> >  3 files changed, 232 insertions(+), 1 deletions(-)
>> >  create mode 100644 drivers/media/v4l2-core/v4l2-clk.c
>> >  create mode 100644 include/media/v4l2-clk.h
>>
>> > diff --git a/drivers/media/v4l2-core/Makefile b/drivers/media/v4l2-core/Makefile
>> > index aa50c46..628c630 100644
>> > --- a/drivers/media/v4l2-core/Makefile
>> > +++ b/drivers/media/v4l2-core/Makefile
>> > @@ -5,7 +5,7 @@
>> >  tuner-objs :=      tuner-core.o
>>
>> >  videodev-objs      :=      v4l2-dev.o v4l2-ioctl.o v4l2-device.o v4l2-fh.o \
>> > -                   v4l2-event.o v4l2-ctrls.o v4l2-subdev.o
>> > +                   v4l2-event.o v4l2-ctrls.o v4l2-subdev.o v4l2-clk.o
>> > ifeq ($(CONFIG_COMPAT),y)
>> >    videodev-objs += v4l2-compat-ioctl32.o
>> >  endif
>> > diff --git a/drivers/media/v4l2-core/v4l2-clk.c b/drivers/media/v4l2-core/v4l2-clk.c
>> > new file mode 100644
>> > index 0000000..d7cc13e
>> > --- /dev/null
>> > +++ b/drivers/media/v4l2-core/v4l2-clk.c
>> > @@ -0,0 +1,177 @@
>>
>> -barry

-barry


From sebastian.hesselbarth at gmail.com  Thu Apr 11 04:22:48 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Thu, 11 Apr 2013 10:22:48 +0200
Subject: [PATCH v7] clk: add si5351 i2c common clock driver
In-Reply-To: <11205025.2MA5VbIUoF@ganymedes>
References: <1365439617-18816-1-git-send-email-sebastian.hesselbarth@gmail.com>
 <14854575.YAd2OMKOy9@ganymedes> <5165A0FD.5030308@gmail.com>
 <11205025.2MA5VbIUoF@ganymedes>
Message-ID: <CABJ1b_S_Tz9WBuO1==7ZU-fuAnYRwRZUcLCM=Zq+6tLCZyEevw@mail.gmail.com>

On Thu, Apr 11, 2013 at 9:44 AM, Michal Bachraty
<michal.bachraty at streamunlimited.com> wrote:
> On Wednesday, April 10, 2013 19:27:25 Sebastian Hesselbarth wrote:
>> Hmm, is there any driver using the clock output? Does it
>> clk_prepare_enable() the clock? I tend not to mess with anything the
>> bootloader or eeprom config left disabled. It works for me, but here the
>> driver will prepare/enable the clock prior use.
>
> For my case, disabled clock outputs in bootloader are correct. I'm working on
> module board with lot of purposes. For one I need to tune frequncy, for other
> not. In some cases I can use  clk_prepare_enable. For now, I need to tune clk,
> so I can't use clk_prepare_enable. Si5351 chip has no problem with enabling
> clock output multiple times, when calling clk_set_rate. So if this feature
> will not be in driver, I need to stay with patch upon driver.

Michal,

after thinking about it, I will re-add the power-on on rate change.
Not because I
want to have a workaround for not using clk_prepare_enable() before
clk_set_rate(),
but clkout will remain disabled if you set clock-frequency by DT.
There will be no
superfluous writes to i2c resisters anyway, because clk-si5351 is
using regmap-i2c
that takes care of caching.

Sebastian


From olof at lixom.net  Thu Apr 11 04:25:19 2013
From: olof at lixom.net (Olof Johansson)
Date: Thu, 11 Apr 2013 01:25:19 -0700
Subject: [PATCH 0/4 v6] arm: introduce psci_smp_ops and use them on Xen
In-Reply-To: <alpine.DEB.2.02.1304081102500.5353@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1304031239550.5078@kaball.uk.xensource.com>
 <alpine.DEB.2.02.1304081102500.5353@kaball.uk.xensource.com>
Message-ID: <20130411082519.GD31465@quad.lixom.net>

On Mon, Apr 08, 2013 at 12:05:17PM +0100, Stefano Stabellini wrote:
> Arnd, Olof,
> do you have any thoughts on this series?
> Would you be happy to carry it in the arm-soc tree?
> 
> The last patch, "xen/arm: introduce xen_early_init, use PSCI on xen" has
> a (small) dependency on this series:
> 
> http://marc.info/?l=linux-kernel&m=136430893610688&w=2
> 
> would you be OK with taking that one too, or should that go through the
> Xen tree?

I think it'd make sense to get Russell to ack the changes to the core ARM code.
We can merge the series through arm-soc, or he can take them, whatever is
easiest for everybody.

Given the dependencies on the second branch it might be easier to merge
through Russell's tree.


-Olof


From linus.walleij at linaro.org  Thu Apr 11 04:33:11 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 11 Apr 2013 10:33:11 +0200
Subject: [PATCH v2 12/13] ARM: move sp804 and integrator timers to
 drivers/clocksource
In-Reply-To: <5165F476.7010807@gmail.com>
References: <1364854883-5961-1-git-send-email-robherring2@gmail.com>
 <1364854883-5961-13-git-send-email-robherring2@gmail.com>
 <515A179A.8020800@linaro.org> <515B3637.8090603@gmail.com>
 <515B7AC1.9090403@linaro.org> <5165F476.7010807@gmail.com>
Message-ID: <CACRpkda_57wCFTOXv9ijfKycGO7-y6gvJA+3N=mNaMpNKbMHgg@mail.gmail.com>

On Thu, Apr 11, 2013 at 1:23 AM, Rob Herring <robherring2 at gmail.com> wrote:

> I'm waiting until there is some clear direction on how or if to split up
> clksrc and clkevt drivers. So I will drop this patch for 3.10 unless you
> are okay with moving it to drivers/clocksource first and sorting out how
> to split things later.

No hurries.

What do you think about my proposal to create drivers/timer
and move the clocksource drivers in a subdir there?

Yours,
Linus Walleij


From olof at lixom.net  Thu Apr 11 04:37:02 2013
From: olof at lixom.net (Olof Johansson)
Date: Thu, 11 Apr 2013 01:37:02 -0700
Subject: linux-next: manual merge of the arm-soc tree with the pm tree
In-Reply-To: <30ad01ce35c6$8b13cb10$a13b6130$%kim@samsung.com>
References: <20130410171743.2ffa67388b330991228a6775@canb.auug.org.au>
 <30ad01ce35c6$8b13cb10$a13b6130$%kim@samsung.com>
Message-ID: <20130411083702.GE31465@quad.lixom.net>

On Wed, Apr 10, 2013 at 05:36:49PM +0900, Kukjin Kim wrote:
> Stephen Rothwell wrote:
> > 
> > Hi all,
> > 
> Hi,
> 
> > Today's linux-next merge of the arm-soc tree got a conflict in
> > arch/arm/mach-s3c24xx/Kconfig between commit 785f40040874 ("cpufreq:
> > s3c24xx: move cpufreq driver to drivers/cpufreq") from the pm tree and
> 
> As I know, Rafael will drop it in his tree.
> http://lists-archives.com/linux-kernel/27815851-cpufreq-s3c24xx-move-cpufreq
> -driver-to-drivers-cpufreq.html
> 
> > commits fb278af74b28 ("ARM: S3C24XX: Removed unneeded dependency on
> > CPU_S3C2410") and a4e4d22c6f53 ("ARM: S3C24XX: Removed unneeded
> > dependency on CPU_S3C2412") from the arm-soc tree.
> > 
> > I fixed it up by removing the sections from arch/arm/mach-s3c24xx/Kconfig
> > and can carry thefix as necessary (no action is required).
> > 
> Thanks.
> 
> > P.S. those arm-soc tree commits have a bad Author email address ...
> 
> Oops :-( it's my fault due to e-mail client problem...
> 
> Arnd, it happened in next/dt-exynos, next/mct-exynos and
> next/cleanup-samsung branches in my tree.
> 
> And I sorted out in my local just now. Could you please re-pull them into
> arm-soc? Then, I will push forced. Sorry about that.

Given that it's "just" formatting errors, I would prefer not repulling and
rebuilding just because of it. For someone reading the information it's pretty
obvious what the valid email address would be. Please try to be mindful of it
in the future though (and we'll try to double-check these things too).


-Olof


From g.liakhovetski at gmx.de  Thu Apr 11 04:36:22 2013
From: g.liakhovetski at gmx.de (Guennadi Liakhovetski)
Date: Thu, 11 Apr 2013 10:36:22 +0200 (CEST)
Subject: [PATCH v8 1/7] media: V4L2: add temporary clock helpers
In-Reply-To: <CAGsJ_4xXRHDbpuqT3e5=0vz9_NxxCXfvrci+h567HP9=AhwRiQ@mail.gmail.com>
References: <CAGsJ_4zCRBvEX9xEDCr27JLK6wYp_2T_wk2hzVjqpKinbL=9pg@mail.gmail.com>
 <Pine.LNX.4.64.1304110921480.23859@axis700.grange>
 <CAGsJ_4xXRHDbpuqT3e5=0vz9_NxxCXfvrci+h567HP9=AhwRiQ@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1304111028090.23859@axis700.grange>

On Thu, 11 Apr 2013, Barry Song wrote:

> 2013/4/11 Guennadi Liakhovetski <g.liakhovetski at gmx.de>:
> > Hi Barry
> >
> > On Thu, 11 Apr 2013, Barry Song wrote:
> >
> >> Hi Guennadi,
> >>
> >> > Typical video devices like camera sensors require an external clock source.
> >> > Many such devices cannot even access their hardware registers without a
> >> > running clock. These clock sources should be controlled by their consumers.
> >> > This should be performed, using the generic clock framework. Unfortunately
> >> > so far only very few systems have been ported to that framework. This patch
> >> > adds a set of temporary helpers, mimicking the generic clock API, to V4L2.
> >> > Platforms, adopting the clock API, should switch to using it. Eventually
> >> > this temporary API should be removed.
> >>
> >> > Signed-off-by: Guennadi Liakhovetski <g.liakhovetski at xxxxxx>
> >> > ---
> >>
> >> for your patch 1/8 and 3/8, i think it makes a lot of senses to let
> >> the object manages its own clock by itself.
> >> is it possible for us to implement v4l2-clk.c directly as an instance
> >> of standard clk driver for those systems which don't have generic
> >> clock,  and remove the V4L2 clock APIs like v4l2_clk_get,
> >> v4l2_clk_enable from the first day? i mean v4l2-clk.c becomes a temp
> >> and fake clock controller driver. finally, after people have
> >> generically clk, remove it.
> >
> > I don't think you can force-enable the CFF on systems, that don't support
> > it, e.g. PXA.
> 
> yes. we can. clock is only a framework, has it any limitation to
> implement a driver instance on any platform?

So, you enable CFF, it provides its own clk_* implementation like 
clk_get_rate() etc. Now, PXA already has it defined in 
arch/arm/mach-pxa/clock.c. Don't think this is going to fly.

Thanks
Guennadi

> people have tried to move to common clk and generic framework for a
> long time, now you still try to provide a v4l2 specific clock APIs, it
> just makes v4l2 unacceptable and much complex.
> 
> >
> > Thanks
> > Guennadi
> >
> >> > v8: Updated both (C) dates
> >>
> >> >  drivers/media/v4l2-core/Makefile   |    2 +-
> >> >  drivers/media/v4l2-core/v4l2-clk.c |  177 ++++++++++++++++++++++++++++++++++++
> >> >  include/media/v4l2-clk.h           |   54 +++++++++++
> >> >  3 files changed, 232 insertions(+), 1 deletions(-)
> >> >  create mode 100644 drivers/media/v4l2-core/v4l2-clk.c
> >> >  create mode 100644 include/media/v4l2-clk.h
> >>
> >> > diff --git a/drivers/media/v4l2-core/Makefile b/drivers/media/v4l2-core/Makefile
> >> > index aa50c46..628c630 100644
> >> > --- a/drivers/media/v4l2-core/Makefile
> >> > +++ b/drivers/media/v4l2-core/Makefile
> >> > @@ -5,7 +5,7 @@
> >> >  tuner-objs :=      tuner-core.o
> >>
> >> >  videodev-objs      :=      v4l2-dev.o v4l2-ioctl.o v4l2-device.o v4l2-fh.o \
> >> > -                   v4l2-event.o v4l2-ctrls.o v4l2-subdev.o
> >> > +                   v4l2-event.o v4l2-ctrls.o v4l2-subdev.o v4l2-clk.o
> >> > ifeq ($(CONFIG_COMPAT),y)
> >> >    videodev-objs += v4l2-compat-ioctl32.o
> >> >  endif
> >> > diff --git a/drivers/media/v4l2-core/v4l2-clk.c b/drivers/media/v4l2-core/v4l2-clk.c
> >> > new file mode 100644
> >> > index 0000000..d7cc13e
> >> > --- /dev/null
> >> > +++ b/drivers/media/v4l2-core/v4l2-clk.c
> >> > @@ -0,0 +1,177 @@
> >>
> >> -barry
> 
> -barry
> 

---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/


From olof at lixom.net  Thu Apr 11 04:52:33 2013
From: olof at lixom.net (Olof Johansson)
Date: Thu, 11 Apr 2013 01:52:33 -0700
Subject: [GIT PULL] ARM: bcm281xx firmware tags
In-Reply-To: <20130411065227.GA31465@quad.lixom.net>
References: <1362451632-18806-1-git-send-email-csd@broadcom.com>
 <201303060631.03782.arnd@arndb.de> <5136F816.2070909@broadcom.com>
 <201303061128.57127.arnd@arndb.de> <5165A271.6060407@broadcom.com>
 <20130411065227.GA31465@quad.lixom.net>
Message-ID: <CAOesGMiiDei3HOop4YkiE2qw1R5opBpRYJEU0Vp3izEyB=r=Mw@mail.gmail.com>

On Wed, Apr 10, 2013 at 11:52 PM, Olof Johansson <olof at lixom.net> wrote:
> On Wed, Apr 10, 2013 at 10:33:37AM -0700, Christian Daudt wrote:
>> Hi Arnd, Olof,
>>  Please pull the branch below - it contains the BCM281xx l2 cache
>> enabling code.
>>
>>  Thanks,
>>    csd
>>
>>
>> The following changes since commit 07961ac7c0ee8b546658717034fe692fd12eefa9:
>>
>>   Linux 3.9-rc5 (2013-03-31 15:12:43 -0700)
>>
>> are available in the git repository at:
>>
>>   git://github.com/broadcom/bcm11351.git tags/fw-for-3.10
>
> Thanks, pulled into next/soc (local branch name bcm/smc-l2)

Based on later thread about the exynos smc ops, I moved this branch
over to next/firmware instead.


-Olof


From t.figa at samsung.com  Thu Apr 11 04:54:45 2013
From: t.figa at samsung.com (Tomasz Figa)
Date: Thu, 11 Apr 2013 10:54:45 +0200
Subject: [PATCH v2] pinctrl: Add pinctrl-s3c24xx driver
In-Reply-To: <201304110116.41525.heiko@sntech.de>
References: <201304110116.41525.heiko@sntech.de>
Message-ID: <3905101.tGGPWFz8Ff@amdc1227>

Hi Heiko,

As previously, generally looks good to me, but see my comments inline.

On Thursday 11 of April 2013 01:16:41 Heiko St?bner wrote:
> The s3c24xx pins follow a similar pattern as the other Samsung SoCs and
> can therefore reuse the already introduced infrastructure.
> 
> The s3c24xx SoCs have one design oddity in that the first 4 external
> interrupts do not reside in the eint pending register but in the main
> interrupt controller instead. We solve this by forwarding the external
> interrupt from the main controller into the irq domain of the pin bank.
> The masking/acking of these interrupts is handled in the same way.
> 
> Furthermore the S3C2412/2413 SoCs contain another oddity in that they
> keep the same 4 eints in the main interrupt controller and eintpend
> register and requiring ack operations to happen in both. To solve this
> a ctrl_type enum is introduced which can keep the type of controller

Hmm, I think you forgot to edit the commit message, since we decided to 
replace ctrl_type with another compatible string.

> in the samsung_pin_ctrl struct for later retrieval.
> 
> The ctrl_type enum contains only S3C24XX and S3C2412 types, as the
> eint-speciality is currently the only use-case. But it can be expaned
> if other SoCs gain special handling requirements later on.
> 
> Signed-off-by: Heiko Stuebner <heiko at sntech.de>
> ---
> changes since v1:
> - address comments from Tomasz Figa:
>   * split handling functions for eints 0-3 for s3c2412 and all others
>   * change the handling for s3c2412 eints 0-3 in that they now use
>     chained_irq_* for the outer parent interrupt

OK, so you finally decided to use the way I suggested. Have you managed to do 
some testing on a S3C2412?

> 
>  .../bindings/pinctrl/samsung-pinctrl.txt           |    8 +
>  drivers/gpio/gpio-samsung.c                        |    4 +
>  drivers/pinctrl/Kconfig                            |    5 +
>  drivers/pinctrl/Makefile                           |    1 +
>  drivers/pinctrl/pinctrl-s3c24xx.c                  |  664
> ++++++++++++++++++++ drivers/pinctrl/pinctrl-samsung.c                  |  
> 10 +
>  drivers/pinctrl/pinctrl-samsung.h                  |   16 +
>  7 files changed, 708 insertions(+), 0 deletions(-)
>  create mode 100644 drivers/pinctrl/pinctrl-s3c24xx.c
> 
> diff --git a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
> b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt index
> c70fca1..e4443e3 100644
> --- a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
> +++ b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
> @@ -7,6 +7,10 @@ on-chip controllers onto these pads.
> 
>  Required Properties:
>  - compatible: should be one of the following.
> +  - "samsung,s3c2413-pinctrl": for S3C64xx-compatible pin-controller,
> +  - "samsung,s3c2416-pinctrl": for S3C64xx-compatible pin-controller,
> +  - "samsung,s3c2440-pinctrl": for S3C64xx-compatible pin-controller,
> +  - "samsung,s3c2450-pinctrl": for S3C64xx-compatible pin-controller,
>    - "samsung,s3c64xx-pinctrl": for S3C64xx-compatible pin-controller,
>    - "samsung,exynos4210-pinctrl": for Exynos4210 compatible pin-controller.
> - "samsung,exynos4x12-pinctrl": for Exynos4x12 compatible pin-controller.
> @@ -106,6 +110,10 @@ B. External Wakeup Interrupts: For supporting external
> wakeup interrupts, a
> 
>     - compatible: identifies the type of the external wakeup interrupt
> controller The possible values are:
> +     - samsung,s3c2410-wakeup-eint: represents wakeup interrupt controller
> +       found on Samsung S3C24xx SoCs except S3C2412 and S3C2413,
> +     - samsung,s3c2412-wakeup-eint: represents wakeup interrupt controller
> +       found on Samsung S3C2412 and S3C2413 SoCs,
>       - samsung,s3c64xx-wakeup-eint: represents wakeup interrupt controller
>         found on Samsung S3C64xx SoCs,
>       - samsung,exynos4210-wakeup-eint: represents wakeup interrupt
> controller diff --git a/drivers/gpio/gpio-samsung.c
> b/drivers/gpio/gpio-samsung.c index dc06a6f..73017b9 100644
> --- a/drivers/gpio/gpio-samsung.c
> +++ b/drivers/gpio/gpio-samsung.c
> @@ -3026,6 +3026,10 @@ static __init int samsung_gpiolib_init(void)
>  	*/
>  	struct device_node *pctrl_np;
>  	static const struct of_device_id exynos_pinctrl_ids[] = {
> +		{ .compatible = "samsung,s3c2413-pinctrl", },
> +		{ .compatible = "samsung,s3c2416-pinctrl", },
> +		{ .compatible = "samsung,s3c2440-pinctrl", },
> +		{ .compatible = "samsung,s3c2450-pinctrl", },
>  		{ .compatible = "samsung,s3c64xx-pinctrl", },
>  		{ .compatible = "samsung,exynos4210-pinctrl", },
>  		{ .compatible = "samsung,exynos4x12-pinctrl", },
> diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
> index 7402ac9..58d73ac 100644
> --- a/drivers/pinctrl/Kconfig
> +++ b/drivers/pinctrl/Kconfig
> @@ -226,6 +226,11 @@ config PINCTRL_EXYNOS5440
>  	select PINMUX
>  	select PINCONF
> 
> +config PINCTRL_S3C24XX
> +	bool "Samsung S3C24XX SoC pinctrl driver"
> +	depends on ARCH_S3C24XX
> +	select PINCTRL_SAMSUNG
> +
>  config PINCTRL_S3C64XX
>  	bool "Samsung S3C64XX SoC pinctrl driver"
>  	depends on ARCH_S3C64XX
> diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
> index 21d34c2..1ccdfd8 100644
> --- a/drivers/pinctrl/Makefile
> +++ b/drivers/pinctrl/Makefile
> @@ -45,6 +45,7 @@ obj-$(CONFIG_PINCTRL_COH901)	+= pinctrl-coh901.o
>  obj-$(CONFIG_PINCTRL_SAMSUNG)	+= pinctrl-samsung.o
>  obj-$(CONFIG_PINCTRL_EXYNOS)	+= pinctrl-exynos.o
>  obj-$(CONFIG_PINCTRL_EXYNOS5440)	+= pinctrl-exynos5440.o
> +obj-$(CONFIG_PINCTRL_S3C24XX)	+= pinctrl-s3c24xx.o
>  obj-$(CONFIG_PINCTRL_S3C64XX)	+= pinctrl-s3c64xx.o
>  obj-$(CONFIG_PINCTRL_XWAY)	+= pinctrl-xway.o
>  obj-$(CONFIG_PINCTRL_LANTIQ)	+= pinctrl-lantiq.o
> diff --git a/drivers/pinctrl/pinctrl-s3c24xx.c
> b/drivers/pinctrl/pinctrl-s3c24xx.c new file mode 100644
> index 0000000..8dffa2a
> --- /dev/null
> +++ b/drivers/pinctrl/pinctrl-s3c24xx.c
> @@ -0,0 +1,664 @@
> +/*
> + * S3C24XX specific support for Samsung pinctrl/gpiolib driver.
> + *
> + * Copyright (c) 2013 Heiko Stuebner <heiko at sntech.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.
> + *
> + * This file contains the SamsungS3C24XX specific information required by
> the + * the Samsung pinctrl/gpiolib driver. It also includes the
> implementation of + * external gpio and wakeup interrupt support.
> + */
> +
> +#include <linux/module.h>
> +#include <linux/device.h>
> +#include <linux/interrupt.h>
> +#include <linux/irqdomain.h>
> +#include <linux/irq.h>
> +#include <linux/of_irq.h>
> +#include <linux/io.h>
> +#include <linux/slab.h>
> +#include <linux/err.h>
> +
> +#include <asm/mach/irq.h>
> +
> +#include "pinctrl-samsung.h"
> +
> +#define NUM_EINT	24
> +#define NUM_EINT_IRQ	6
> +#define EINT_MAX_PER_GROUP	8
> +
> +#define EINTPEND_REG	0xa8
> +#define EINTMASK_REG	0xa4
> +
> +#define EINT_GROUP(i)		((int)((i) / EINT_MAX_PER_GROUP))
> +#define EINT_REG(i)		((EINT_GROUP(i) * 4) + 0x88)
> +#define EINT_OFFS(i)		((i) % EINT_MAX_PER_GROUP * 4)
> +
> +#define EINT_LEVEL_LOW		0
> +#define EINT_LEVEL_HIGH		1
> +#define EINT_EDGE_FALLING	2
> +#define EINT_EDGE_RISING	4
> +#define EINT_EDGE_BOTH		6
> +#define EINT_MASK		0xf
> +
> +static struct samsung_pin_bank_type bank_type_1bit = {
> +	.fld_width = { 1, 1, },
> +	.reg_offset = { 0x00, 0x04, },
> +};
> +
> +static struct samsung_pin_bank_type bank_type_2bit = {
> +	.fld_width = { 2, 1, 2, },
> +	.reg_offset = { 0x00, 0x04, 0x08, },
> +};
> +
> +#define PIN_BANK_A(pins, reg, id)		\
> +	{						\
> +		.type		= &bank_type_1bit,	\
> +		.pctl_offset	= reg,			\
> +		.nr_pins	= pins,			\
> +		.eint_type	= EINT_TYPE_NONE,	\
> +		.name		= id			\
> +	}
> +
> +#define PIN_BANK_2BIT(pins, reg, id)		\
> +	{						\
> +		.type		= &bank_type_2bit,	\
> +		.pctl_offset	= reg,			\
> +		.nr_pins	= pins,			\
> +		.eint_type	= EINT_TYPE_NONE,	\
> +		.name		= id			\
> +	}
> +
> +#define PIN_BANK_2BIT_EINTW(pins, reg, id, eoffs, emask)\
> +	{						\
> +		.type		= &bank_type_2bit,	\
> +		.pctl_offset	= reg,			\
> +		.nr_pins	= pins,			\
> +		.eint_type	= EINT_TYPE_WKUP,	\
> +		.eint_func	= 2,			\
> +		.eint_mask	= emask,		\
> +		.eint_offset	= eoffs,		\
> +		.name		= id			\
> +	}
> +
> +/**
> + * struct s3c24xx_eint_data: EINT common data
> + * @drvdata: pin controller driver data
> + * @domains: IRQ domains of particular EINT interrupts

@parents:

> + */
> +struct s3c24xx_eint_data {
> +	struct samsung_pinctrl_drv_data *drvdata;
> +	struct irq_domain *domains[NUM_EINT];
> +	int parents[NUM_EINT_IRQ];
> +};
> +

I wonder if this struct should be documented as well.

> +struct s3c24xx_eint_domain_data {
> +	struct samsung_pin_bank *bank;
> +	struct s3c24xx_eint_data *eint_data;
> +	bool eint0_3_parent_only;
> +};
> +
> +static int s3c24xx_eint_get_trigger(unsigned int type)
> +{
> +	int trigger;
> +
> +	switch (type) {
> +	case IRQ_TYPE_EDGE_RISING:
> +		trigger = EINT_EDGE_RISING;
> +		break;
> +	case IRQ_TYPE_EDGE_FALLING:
> +		trigger = EINT_EDGE_FALLING;
> +		break;
> +	case IRQ_TYPE_EDGE_BOTH:
> +		trigger = EINT_EDGE_BOTH;
> +		break;
> +	case IRQ_TYPE_LEVEL_HIGH:
> +		trigger = EINT_LEVEL_HIGH;
> +		break;
> +	case IRQ_TYPE_LEVEL_LOW:
> +		trigger = EINT_LEVEL_LOW;
> +		break;
> +	default:
> +		return -EINVAL;
> +	}
> +
> +	return trigger;
> +}
> +
> +static void s3c24xx_eint_set_handler(unsigned int irq, unsigned int type)
> +{
> +	/* Edge- and level-triggered interrupts need different handlers */
> +	if (type & IRQ_TYPE_EDGE_BOTH)
> +		__irq_set_handler_locked(irq, handle_edge_irq);
> +	else
> +		__irq_set_handler_locked(irq, handle_level_irq);
> +}
> +
> +static void s3c24xx_eint_set_function(struct samsung_pinctrl_drv_data *d,
> +					struct samsung_pin_bank *bank, int pin)
> +{
> +	struct samsung_pin_bank_type *bank_type = bank->type;
> +	unsigned long flags;
> +	void __iomem *reg;
> +	u8 shift;
> +	u32 mask;
> +	u32 val;
> +
> +	/* Make sure that pin is configured as interrupt */
> +	reg = d->virt_base + bank->pctl_offset;
> +	shift = pin * bank_type->fld_width[PINCFG_TYPE_FUNC];
> +	mask = (1 << bank_type->fld_width[PINCFG_TYPE_FUNC]) - 1;
> +
> +	spin_lock_irqsave(&bank->slock, flags);
> +
> +	val = readl(reg);
> +	val &= ~(mask << shift);
> +	val |= bank->eint_func << shift;
> +	writel(val, reg);
> +
> +	spin_unlock_irqrestore(&bank->slock, flags);
> +}
> +
> +static int s3c24xx_eint_type(struct irq_data *data, unsigned int type)
> +{
> +	struct samsung_pin_bank *bank = irq_data_get_irq_chip_data(data);
> +	struct samsung_pinctrl_drv_data *d = bank->drvdata;
> +	int index = bank->eint_offset + data->hwirq;
> +	void __iomem *reg;
> +	int trigger;
> +	u8 shift;
> +	u32 val;
> +
> +	trigger = s3c24xx_eint_get_trigger(type);
> +	if (trigger < 0) {
> +		dev_err(d->dev, "unsupported external interrupt type\n");
> +		return -EINVAL;
> +	}
> +
> +	s3c24xx_eint_set_handler(data->irq, type);
> +
> +	/* Set up interrupt trigger */
> +	reg = d->virt_base + EINT_REG(index);
> +	shift = EINT_OFFS(index);
> +
> +	val = readl(reg);
> +	val &= ~(EINT_MASK << shift);
> +	val |= trigger << shift;
> +	writel(val, reg);
> +
> +	s3c24xx_eint_set_function(d, bank, data->hwirq);
> +
> +	return 0;
> +}
> +
> +/* handling of EINTs 0-3 on all except S3C2412 and S3C2413 */
> +
> +static void s3c2410_eint0_3_ack(struct irq_data *data)
> +{
> +	struct samsung_pin_bank *bank = irq_data_get_irq_chip_data(data);
> +	struct s3c24xx_eint_domain_data *ddata = bank->irq_domain->host_data;
> +	struct s3c24xx_eint_data *eint_data = ddata->eint_data;
> +	int parent_irq = eint_data->parents[data->hwirq];
> +	struct irq_chip *parent_chip = irq_get_chip(parent_irq);
> +
> +	if (likely(parent_chip))

Hmm, is it possible that there is no parent chip here?

> +		parent_chip->irq_ack(irq_get_irq_data(parent_irq));
> +}
> +
> +static void s3c2410_eint0_3_mask(struct irq_data *data)
> +{
> +	struct samsung_pin_bank *bank = irq_data_get_irq_chip_data(data);
> +	struct s3c24xx_eint_domain_data *ddata = bank->irq_domain->host_data;
> +	struct s3c24xx_eint_data *eint_data = ddata->eint_data;
> +	int parent_irq = eint_data->parents[data->hwirq];
> +	struct irq_chip *parent_chip = irq_get_chip(parent_irq);
> +
> +	if (likely(parent_chip))

Ditto.

> +		parent_chip->irq_mask(irq_get_irq_data(parent_irq));
> +}
> +
> +static void s3c2410_eint0_3_unmask(struct irq_data *data)
> +{
> +	struct samsung_pin_bank *bank = irq_data_get_irq_chip_data(data);
> +	struct s3c24xx_eint_domain_data *ddata = bank->irq_domain->host_data;
> +	struct s3c24xx_eint_data *eint_data = ddata->eint_data;
> +	int parent_irq = eint_data->parents[data->hwirq];
> +	struct irq_chip *parent_chip = irq_get_chip(parent_irq);
> +
> +	if (likely(parent_chip))

Ditto.

> +		parent_chip->irq_unmask(irq_get_irq_data(parent_irq));
> +}
> +
> +static struct irq_chip s3c2410_eint0_3_chip = {
> +	.name		= "s3c2410-eint0_3",
> +	.irq_ack	= s3c2410_eint0_3_ack,
> +	.irq_mask	= s3c2410_eint0_3_mask,
> +	.irq_unmask	= s3c2410_eint0_3_unmask,
> +	.irq_set_type	= s3c24xx_eint_type,
> +};
> +
> +static void s3c2410_demux_eint0_3(unsigned int irq, struct irq_desc *desc)
> +{
> +	struct irq_data *data = irq_desc_get_irq_data(desc);
> +	struct s3c24xx_eint_data *eint_data = irq_get_handler_data(irq);
> +	unsigned int virq;
> +
> +	/* the first 4 eints have a simple 1 to 1 mapping */
> +	virq = irq_linear_revmap(eint_data->domains[data->hwirq], data->hwirq);
> +	/* Something must be really wrong if an unmapped EINT
> +	 * was unmasked...
> +	 */
> +	BUG_ON(!virq);
> +
> +	generic_handle_irq(virq);
> +}
> +
> +/* handling of EINTs 0-3 on S3C2412 and S3C2413 */
> +
> +static void s3c2412_eint0_3_ack(struct irq_data *data)
> +{
> +	struct samsung_pin_bank *bank = irq_data_get_irq_chip_data(data);
> +	struct samsung_pinctrl_drv_data *d = bank->drvdata;
> +
> +	unsigned long bitval = 1UL << data->hwirq;
> +	writel(bitval, d->virt_base + EINTPEND_REG);
> +}
> +
> +static void s3c2412_eint0_3_mask(struct irq_data *data)
> +{
> +	struct samsung_pin_bank *bank = irq_data_get_irq_chip_data(data);
> +	struct samsung_pinctrl_drv_data *d = bank->drvdata;
> +	unsigned long mask;
> +
> +	mask = readl(d->virt_base + EINTMASK_REG);
> +	mask |= (1UL << data->hwirq);
> +	writel(mask, d->virt_base + EINTMASK_REG);
> +}
> +
> +static void s3c2412_eint0_3_unmask(struct irq_data *data)
> +{
> +	struct samsung_pin_bank *bank = irq_data_get_irq_chip_data(data);
> +	struct samsung_pinctrl_drv_data *d = bank->drvdata;
> +	unsigned long mask;
> +
> +	mask = readl(d->virt_base + EINTMASK_REG);
> +	mask &= ~(1UL << data->hwirq);
> +	writel(mask, d->virt_base + EINTMASK_REG);
> +}
> +
> +static struct irq_chip s3c2412_eint0_3_chip = {
> +	.name		= "s3c2412-eint0_3",
> +	.irq_ack	= s3c2412_eint0_3_ack,
> +	.irq_mask	= s3c2412_eint0_3_mask,
> +	.irq_unmask	= s3c2412_eint0_3_unmask,
> +	.irq_set_type	= s3c24xx_eint_type,
> +};
> +
> +static void s3c2412_demux_eint0_3(unsigned int irq, struct irq_desc *desc)
> +{
> +	struct irq_chip *chip = irq_get_chip(irq);
> +	struct irq_data *data = irq_desc_get_irq_data(desc);
> +	struct s3c24xx_eint_data *eint_data = irq_get_handler_data(irq);
> +	unsigned int virq;
> +
> +	chained_irq_enter(chip, desc);
> +
> +	/* the first 4 eints have a simple 1 to 1 mapping */
> +	virq = irq_linear_revmap(eint_data->domains[data->hwirq], data->hwirq);
> +	/* Something must be really wrong if an unmapped EINT
> +	 * was unmasked...
> +	 */
> +	BUG_ON(!virq);
> +
> +	generic_handle_irq(virq);
> +
> +	chained_irq_exit(chip, desc);
> +}
> +
> +/* handling of all other eints */
> +
> +static void s3c24xx_eint_ack(struct irq_data *data)
> +{
> +	struct samsung_pin_bank *bank = irq_data_get_irq_chip_data(data);
> +	struct samsung_pinctrl_drv_data *d = bank->drvdata;
> +	unsigned char index = bank->eint_offset + data->hwirq;
> +
> +	writel(1UL << index, d->virt_base + EINTPEND_REG);
> +}
> +
> +static void s3c24xx_eint_mask(struct irq_data *data)
> +{
> +	struct samsung_pin_bank *bank = irq_data_get_irq_chip_data(data);
> +	struct samsung_pinctrl_drv_data *d = bank->drvdata;
> +	unsigned char index = bank->eint_offset + data->hwirq;
> +	unsigned long mask;
> +
> +	mask = readl(d->virt_base + EINTMASK_REG);
> +	mask |= (1UL << index);
> +	writel(mask, d->virt_base + EINTMASK_REG);
> +}
> +
> +static void s3c24xx_eint_unmask(struct irq_data *data)
> +{
> +	struct samsung_pin_bank *bank = irq_data_get_irq_chip_data(data);
> +	struct samsung_pinctrl_drv_data *d = bank->drvdata;
> +	unsigned char index = bank->eint_offset + data->hwirq;
> +	unsigned long mask;
> +
> +	mask = readl(d->virt_base + EINTMASK_REG);
> +	mask &= ~(1UL << index);
> +	writel(mask, d->virt_base + EINTMASK_REG);
> +}
> +
> +static struct irq_chip s3c24xx_eint_chip = {
> +	.name		= "s3c-eint",
> +	.irq_ack	= s3c24xx_eint_ack,
> +	.irq_mask	= s3c24xx_eint_mask,
> +	.irq_unmask	= s3c24xx_eint_unmask,
> +	.irq_set_type	= s3c24xx_eint_type,
> +};
> +
> +static inline void s3c24xx_demux_eint(unsigned int irq, struct irq_desc
> *desc, +				      u32 offset, u32 range)
> +{
> +	struct irq_chip *chip = irq_get_chip(irq);
> +	struct s3c24xx_eint_data *data = irq_get_handler_data(irq);
> +	struct samsung_pinctrl_drv_data *d = data->drvdata;
> +	unsigned int pend, mask;
> +
> +	chained_irq_enter(chip, desc);
> +
> +	pend = readl(d->virt_base + EINTPEND_REG);
> +	mask = readl(d->virt_base + EINTMASK_REG);
> +
> +	pend &= ~mask;
> +	pend &= range;
> +
> +	while (pend) {
> +		unsigned int virq;
> +
> +		irq = __ffs(pend);
> +		pend &= ~(1 << irq);
> +		virq = irq_linear_revmap(data->domains[irq], irq - offset);
> +		/* Something must be really wrong if an unmapped EINT
> +		 * was unmasked...
> +		 */
> +		BUG_ON(!virq);
> +
> +		generic_handle_irq(virq);
> +	}
> +
> +	chained_irq_exit(chip, desc);
> +}
> +
> +static void s3c24xx_demux_eint4_7(unsigned int irq, struct irq_desc *desc)
> +{
> +	s3c24xx_demux_eint(irq, desc, 0, 0xf0);
> +}
> +
> +static void s3c24xx_demux_eint8_23(unsigned int irq, struct irq_desc *desc)
> +{
> +	s3c24xx_demux_eint(irq, desc, 8, 0xffff00);
> +}
> +
> +static irq_flow_handler_t s3c2410_eint_handlers[NUM_EINT_IRQ] = {
> +	s3c2410_demux_eint0_3,
> +	s3c2410_demux_eint0_3,
> +	s3c2410_demux_eint0_3,
> +	s3c2410_demux_eint0_3,
> +	s3c24xx_demux_eint4_7,
> +	s3c24xx_demux_eint8_23,
> +};
> +
> +static irq_flow_handler_t s3c2412_eint_handlers[NUM_EINT_IRQ] = {
> +	s3c2412_demux_eint0_3,
> +	s3c2412_demux_eint0_3,
> +	s3c2412_demux_eint0_3,
> +	s3c2412_demux_eint0_3,
> +	s3c24xx_demux_eint4_7,
> +	s3c24xx_demux_eint8_23,
> +};
> +
> +static int s3c24xx_gpf_irq_map(struct irq_domain *h, unsigned int virq,
> +					irq_hw_number_t hw)
> +{
> +	struct s3c24xx_eint_domain_data *ddata = h->host_data;
> +	struct samsung_pin_bank *bank = ddata->bank;
> +
> +	if (!(bank->eint_mask & (1 << (bank->eint_offset + hw))))
> +		return -EINVAL;
> +
> +	if (hw <= 3) {
> +		if (ddata->eint0_3_parent_only)
> +			irq_set_chip_and_handler(virq, &s3c2410_eint0_3_chip,
> +						 handle_edge_irq);
> +		else
> +			irq_set_chip_and_handler(virq, &s3c2412_eint0_3_chip,
> +						 handle_edge_irq);
> +	} else {
> +		irq_set_chip_and_handler(virq, &s3c24xx_eint_chip,
> +					 handle_edge_irq);
> +	}
> +	irq_set_chip_data(virq, bank);
> +	set_irq_flags(virq, IRQF_VALID);
> +	return 0;
> +}
> +
> +static const struct irq_domain_ops s3c24xx_gpf_irq_ops = {
> +	.map	= s3c24xx_gpf_irq_map,
> +	.xlate	= irq_domain_xlate_twocell,
> +};
> +
> +static int s3c24xx_gpg_irq_map(struct irq_domain *h, unsigned int virq,
> +					irq_hw_number_t hw)
> +{
> +	struct s3c24xx_eint_domain_data *ddata = h->host_data;
> +	struct samsung_pin_bank *bank = ddata->bank;
> +
> +	if (!(bank->eint_mask & (1 << (bank->eint_offset + hw))))
> +		return -EINVAL;
> +
> +	irq_set_chip_and_handler(virq, &s3c24xx_eint_chip, handle_edge_irq);
> +	irq_set_chip_data(virq, bank);
> +	set_irq_flags(virq, IRQF_VALID);
> +	return 0;
> +}
> +
> +static const struct irq_domain_ops s3c24xx_gpg_irq_ops = {
> +	.map	= s3c24xx_gpg_irq_map,
> +	.xlate	= irq_domain_xlate_twocell,
> +};
> +
> +static const struct of_device_id s3c24xx_eint_irq_ids[] = {
> +	{ .compatible = "samsung,s3c2410-wakeup-eint", .data = (void *)1 },
> +	{ .compatible = "samsung,s3c2412-wakeup-eint", .data = (void *)0 },
> +	{ }
> +};
> +
> +static int s3c24xx_eint_init(struct samsung_pinctrl_drv_data *d)
> +{
> +	struct device *dev = d->dev;
> +	const struct of_device_id *match;
> +	struct device_node *eint_np = NULL;
> +	struct device_node *np;
> +	struct samsung_pin_bank *bank;
> +	struct s3c24xx_eint_data *eint_data;
> +	const struct irq_domain_ops *ops;
> +	unsigned int i;
> +	bool eint0_3_parent_only;
> +	irq_flow_handler_t *handlers;
> +
> +	for_each_child_of_node(dev->of_node, np) {
> +		match = of_match_node(s3c24xx_eint_irq_ids, np);
> +		if (match) {
> +			eint_np = np;
> +			eint0_3_parent_only = (bool)match->data;
> +			break;
> +		}
> +	}
> +	if (!eint_np)
> +		return -ENODEV;
> +
> +	eint_data = devm_kzalloc(dev, sizeof(*eint_data), GFP_KERNEL);
> +	if (!eint_data) {
> +		dev_err(dev, "could not allocate memory for wkup eint data\n");
> +		return -ENOMEM;
> +	}
> +	eint_data->drvdata = d;
> +
> +	handlers = eint0_3_parent_only ? s3c2410_eint_handlers
> +				       : s3c2412_eint_handlers;
> +	for (i = 0; i < NUM_EINT_IRQ; ++i) {
> +		unsigned int irq;
> +
> +		irq = irq_of_parse_and_map(eint_np, i);
> +		if (!irq) {
> +			dev_err(dev, "failed to get wakeup EINT IRQ %d\n", i);
> +			return -ENXIO;
> +		}
> +
> +		eint_data->parents[i] = irq;
> +		irq_set_chained_handler(irq, handlers[i]);
> +		irq_set_handler_data(irq, eint_data);
> +	}
> +
> +	bank = d->ctrl->pin_banks;
> +	for (i = 0; i < d->ctrl->nr_banks; ++i, ++bank) {
> +		struct s3c24xx_eint_domain_data *ddata;
> +		unsigned int mask;
> +		unsigned int irq;
> +		unsigned int pin;
> +
> +		if (bank->eint_type != EINT_TYPE_WKUP)
> +			continue;
> +
> +		ddata = devm_kzalloc(dev, sizeof(*ddata), GFP_KERNEL);
> +		if (!ddata) {
> +			dev_err(dev, "failed to allocate domain data\n");
> +			return -ENOMEM;
> +		}
> +		ddata->bank = bank;
> +		ddata->eint_data = eint_data;
> +		ddata->eint0_3_parent_only = eint0_3_parent_only;
> +
> +		ops = (bank->eint_offset == 0) ? &s3c24xx_gpf_irq_ops
> +					       : &s3c24xx_gpg_irq_ops;
> +
> +		bank->irq_domain = irq_domain_add_linear(bank->of_node,
> +				bank->nr_pins, ops, ddata);
> +		if (!bank->irq_domain) {
> +			dev_err(dev, "wkup irq domain add failed\n");
> +			return -ENXIO;
> +		}
> +
> +		irq = bank->eint_offset;
> +		mask = bank->eint_mask;
> +		for (pin = 0; mask; ++pin, mask >>= 1) {
> +			if (irq > NUM_EINT)
> +				break;
> +			if (!(mask & 1))
> +				continue;
> +			eint_data->domains[irq] = bank->irq_domain;
> +			++irq;
> +		}
> +	}
> +
> +	return 0;
> +}
> +
> +static struct samsung_pin_bank s3c2413_pin_banks[] = {
> +	PIN_BANK_A(23, 0x000, "gpa"),
> +	PIN_BANK_2BIT(11, 0x010, "gpb"),
> +	PIN_BANK_2BIT(16, 0x020, "gpc"),
> +	PIN_BANK_2BIT(16, 0x030, "gpd"),
> +	PIN_BANK_2BIT(16, 0x040, "gpe"),
> +	PIN_BANK_2BIT_EINTW(8, 0x050, "gpf", 0, 0xff),
> +	PIN_BANK_2BIT_EINTW(16, 0x060, "gpg", 8, 0xffff00),
> +	PIN_BANK_2BIT(11, 0x070, "gph"),
> +	PIN_BANK_2BIT(13, 0x080, "gpj"),
> +};
> +
> +struct samsung_pin_ctrl s3c2413_pin_ctrl[] = {
> +	{
> +		.pin_banks	= s3c2413_pin_banks,
> +		.nr_banks	= ARRAY_SIZE(s3c2413_pin_banks),
> +		.eint_wkup_init = s3c24xx_eint_init,
> +		.label		= "S3C2413-GPIO",
> +		.type		= S3C2412,

This should be removed as well, shouldn't it?

> +	},
> +};
> +
> +static struct samsung_pin_bank s3c2416_pin_banks[] = {
> +	PIN_BANK_A(27, 0x000, "gpa"),
> +	PIN_BANK_2BIT(11, 0x010, "gpb"),
> +	PIN_BANK_2BIT(16, 0x020, "gpc"),
> +	PIN_BANK_2BIT(16, 0x030, "gpd"),
> +	PIN_BANK_2BIT(16, 0x040, "gpe"),
> +	PIN_BANK_2BIT_EINTW(8, 0x050, "gpf", 0, 0xff),
> +	PIN_BANK_2BIT_EINTW(8, 0x060, "gpg", 8, 0xff00),
> +	PIN_BANK_2BIT(15, 0x070, "gph"),
> +	PIN_BANK_2BIT(16, 0x0e0, "gpk"),
> +	PIN_BANK_2BIT(14, 0x0f0, "gpl"),
> +	PIN_BANK_2BIT(2, 0x100, "gpm"),
> +};
> +
> +struct samsung_pin_ctrl s3c2416_pin_ctrl[] = {
> +	{
> +		.pin_banks	= s3c2416_pin_banks,
> +		.nr_banks	= ARRAY_SIZE(s3c2416_pin_banks),
> +		.eint_wkup_init = s3c24xx_eint_init,
> +		.label		= "S3C2416-GPIO",
> +		.type		= S3C24XX,

Ditto.

> +	},
> +};
> +
> +static struct samsung_pin_bank s3c2440_pin_banks[] = {
> +	PIN_BANK_A(25, 0x000, "gpa"),
> +	PIN_BANK_2BIT(11, 0x010, "gpb"),
> +	PIN_BANK_2BIT(16, 0x020, "gpc"),
> +	PIN_BANK_2BIT(16, 0x030, "gpd"),
> +	PIN_BANK_2BIT(16, 0x040, "gpe"),
> +	PIN_BANK_2BIT_EINTW(8, 0x050, "gpf", 0, 0xff),
> +	PIN_BANK_2BIT_EINTW(16, 0x060, "gpg", 8, 0xffff00),
> +	PIN_BANK_2BIT(11, 0x070, "gph"),
> +	PIN_BANK_2BIT(13, 0x0d0, "gpj"),
> +};
> +
> +struct samsung_pin_ctrl s3c2440_pin_ctrl[] = {
> +	{
> +		.pin_banks	= s3c2440_pin_banks,
> +		.nr_banks	= ARRAY_SIZE(s3c2440_pin_banks),
> +		.eint_wkup_init = s3c24xx_eint_init,
> +		.label		= "S3C2440-GPIO",
> +		.type		= S3C24XX,

Ditto.

> +	},
> +};
> +
> +static struct samsung_pin_bank s3c2450_pin_banks[] = {
> +	PIN_BANK_A(28, 0x000, "gpa"),
> +	PIN_BANK_2BIT(11, 0x010, "gpb"),
> +	PIN_BANK_2BIT(16, 0x020, "gpc"),
> +	PIN_BANK_2BIT(16, 0x030, "gpd"),
> +	PIN_BANK_2BIT(16, 0x040, "gpe"),
> +	PIN_BANK_2BIT_EINTW(8, 0x050, "gpf", 0, 0xff),
> +	PIN_BANK_2BIT_EINTW(16, 0x060, "gpg", 8, 0xffff00),
> +	PIN_BANK_2BIT(15, 0x070, "gph"),
> +	PIN_BANK_2BIT(16, 0x0d0, "gpj"),
> +	PIN_BANK_2BIT(16, 0x0e0, "gpk"),
> +	PIN_BANK_2BIT(15, 0x0f0, "gpl"),
> +	PIN_BANK_2BIT(2, 0x100, "gpm"),
> +};
> +
> +struct samsung_pin_ctrl s3c2450_pin_ctrl[] = {
> +	{
> +		.pin_banks	= s3c2450_pin_banks,
> +		.nr_banks	= ARRAY_SIZE(s3c2450_pin_banks),
> +		.eint_wkup_init = s3c24xx_eint_init,
> +		.label		= "S3C2450-GPIO",
> +		.type		= S3C24XX,

Ditto.

> +	},
> +};
> diff --git a/drivers/pinctrl/pinctrl-samsung.c
> b/drivers/pinctrl/pinctrl-samsung.c index e836135..234c32f 100644
> --- a/drivers/pinctrl/pinctrl-samsung.c
> +++ b/drivers/pinctrl/pinctrl-samsung.c
> @@ -977,6 +977,16 @@ static const struct of_device_id
> samsung_pinctrl_dt_match[] = { { .compatible = "samsung,s3c64xx-pinctrl",
>  		.data = s3c64xx_pin_ctrl },
>  #endif
> +#ifdef CONFIG_PINCTRL_S3C24XX
> +	{ .compatible = "samsung,s3c2413-pinctrl",
> +		.data = s3c2413_pin_ctrl },
> +	{ .compatible = "samsung,s3c2416-pinctrl",
> +		.data = s3c2416_pin_ctrl },
> +	{ .compatible = "samsung,s3c2440-pinctrl",
> +		.data = s3c2440_pin_ctrl },
> +	{ .compatible = "samsung,s3c2450-pinctrl",
> +		.data = s3c2450_pin_ctrl },
> +#endif
>  	{},
>  };
>  MODULE_DEVICE_TABLE(of, samsung_pinctrl_dt_match);
> diff --git a/drivers/pinctrl/pinctrl-samsung.h
> b/drivers/pinctrl/pinctrl-samsung.h index 7c7f9eb..8bd317c 100644
> --- a/drivers/pinctrl/pinctrl-samsung.h
> +++ b/drivers/pinctrl/pinctrl-samsung.h
> @@ -81,6 +81,16 @@ enum eint_type {
>  	EINT_TYPE_WKUP_MUX,
>  };
> 
> +/**
> + * enum ctrl_type - variances of a pin controller type
> + * @S3C24XX: generic s3c24xx pin handling
> + * @S3C2412: s3c2412-type eints, existing in the main and eint controllers
> + */
> +enum ctrl_type {
> +	S3C24XX,
> +	S3C2412,
> +};

Diito.

> +
>  /* maximum length of a pin in pin descriptor (example: "gpa0-0") */
>  #define PIN_NAME_LENGTH	10
> 
> @@ -164,6 +174,7 @@ struct samsung_pin_bank {
>   * @eint_wkup_init: platform specific callback to setup the external wakeup
> *	interrupts for the controller.
>   * @label: for debug information.
> + * @type: type of pin-controller
>   */
>  struct samsung_pin_ctrl {
>  	struct samsung_pin_bank	*pin_banks;
> @@ -185,6 +196,7 @@ struct samsung_pin_ctrl {
>  	int		(*eint_gpio_init)(struct samsung_pinctrl_drv_data *);
>  	int		(*eint_wkup_init)(struct samsung_pinctrl_drv_data *);
>  	char		*label;
> +	enum ctrl_type	type;

Ditto.

Best regards,
--
Tomasz Figa
Samsung Poland R&D Center
SW Solution Development, Kernel and System Framework

>  };
> 
>  /**
> @@ -246,5 +258,9 @@ extern struct samsung_pin_ctrl exynos4210_pin_ctrl[];
>  extern struct samsung_pin_ctrl exynos4x12_pin_ctrl[];
>  extern struct samsung_pin_ctrl exynos5250_pin_ctrl[];
>  extern struct samsung_pin_ctrl s3c64xx_pin_ctrl[];
> +extern struct samsung_pin_ctrl s3c2413_pin_ctrl[];
> +extern struct samsung_pin_ctrl s3c2416_pin_ctrl[];
> +extern struct samsung_pin_ctrl s3c2440_pin_ctrl[];
> +extern struct samsung_pin_ctrl s3c2450_pin_ctrl[];
> 
>  #endif /* __PINCTRL_SAMSUNG_H */



From 21cnbao at gmail.com  Thu Apr 11 04:59:28 2013
From: 21cnbao at gmail.com (Barry Song)
Date: Thu, 11 Apr 2013 16:59:28 +0800
Subject: [PATCH v8 1/7] media: V4L2: add temporary clock helpers
In-Reply-To: <Pine.LNX.4.64.1304111028090.23859@axis700.grange>
References: <CAGsJ_4zCRBvEX9xEDCr27JLK6wYp_2T_wk2hzVjqpKinbL=9pg@mail.gmail.com>
 <Pine.LNX.4.64.1304110921480.23859@axis700.grange>
 <CAGsJ_4xXRHDbpuqT3e5=0vz9_NxxCXfvrci+h567HP9=AhwRiQ@mail.gmail.com>
 <Pine.LNX.4.64.1304111028090.23859@axis700.grange>
Message-ID: <CAGsJ_4yXE7SYLgPucW9kAEYgKg+z93j8yN3d+gvhqeLAn-sSOw@mail.gmail.com>

2013/4/11 Guennadi Liakhovetski <g.liakhovetski at gmx.de>:
> On Thu, 11 Apr 2013, Barry Song wrote:
>
>> 2013/4/11 Guennadi Liakhovetski <g.liakhovetski at gmx.de>:
>> > Hi Barry
>> >
>> > On Thu, 11 Apr 2013, Barry Song wrote:
>> >
>> >> Hi Guennadi,
>> >>
>> >> > Typical video devices like camera sensors require an external clock source.
>> >> > Many such devices cannot even access their hardware registers without a
>> >> > running clock. These clock sources should be controlled by their consumers.
>> >> > This should be performed, using the generic clock framework. Unfortunately
>> >> > so far only very few systems have been ported to that framework. This patch
>> >> > adds a set of temporary helpers, mimicking the generic clock API, to V4L2.
>> >> > Platforms, adopting the clock API, should switch to using it. Eventually
>> >> > this temporary API should be removed.
>> >>
>> >> > Signed-off-by: Guennadi Liakhovetski <g.liakhovetski at xxxxxx>
>> >> > ---
>> >>
>> >> for your patch 1/8 and 3/8, i think it makes a lot of senses to let
>> >> the object manages its own clock by itself.
>> >> is it possible for us to implement v4l2-clk.c directly as an instance
>> >> of standard clk driver for those systems which don't have generic
>> >> clock,  and remove the V4L2 clock APIs like v4l2_clk_get,
>> >> v4l2_clk_enable from the first day? i mean v4l2-clk.c becomes a temp
>> >> and fake clock controller driver. finally, after people have
>> >> generically clk, remove it.
>> >
>> > I don't think you can force-enable the CFF on systems, that don't support
>> > it, e.g. PXA.
>>
>> yes. we can. clock is only a framework, has it any limitation to
>> implement a driver instance on any platform?
>
> So, you enable CFF, it provides its own clk_* implementation like
> clk_get_rate() etc. Now, PXA already has it defined in
> arch/arm/mach-pxa/clock.c. Don't think this is going to fly.

agree.

>
> Thanks
> Guennadi
>
>> people have tried to move to common clk and generic framework for a
>> long time, now you still try to provide a v4l2 specific clock APIs, it
>> just makes v4l2 unacceptable and much complex.
>>
>> >
>> > Thanks
>> > Guennadi
>> >
>> >> > v8: Updated both (C) dates
>> >>
>> >> >  drivers/media/v4l2-core/Makefile   |    2 +-
>> >> >  drivers/media/v4l2-core/v4l2-clk.c |  177 ++++++++++++++++++++++++++++++++++++
>> >> >  include/media/v4l2-clk.h           |   54 +++++++++++
>> >> >  3 files changed, 232 insertions(+), 1 deletions(-)
>> >> >  create mode 100644 drivers/media/v4l2-core/v4l2-clk.c
>> >> >  create mode 100644 include/media/v4l2-clk.h
>> >>
>> >> > diff --git a/drivers/media/v4l2-core/Makefile b/drivers/media/v4l2-core/Makefile
>> >> > index aa50c46..628c630 100644
>> >> > --- a/drivers/media/v4l2-core/Makefile
>> >> > +++ b/drivers/media/v4l2-core/Makefile
>> >> > @@ -5,7 +5,7 @@
>> >> >  tuner-objs :=      tuner-core.o
>> >>
>> >> >  videodev-objs      :=      v4l2-dev.o v4l2-ioctl.o v4l2-device.o v4l2-fh.o \
>> >> > -                   v4l2-event.o v4l2-ctrls.o v4l2-subdev.o
>> >> > +                   v4l2-event.o v4l2-ctrls.o v4l2-subdev.o v4l2-clk.o
>> >> > ifeq ($(CONFIG_COMPAT),y)
>> >> >    videodev-objs += v4l2-compat-ioctl32.o
>> >> >  endif
>> >> > diff --git a/drivers/media/v4l2-core/v4l2-clk.c b/drivers/media/v4l2-core/v4l2-clk.c
>> >> > new file mode 100644
>> >> > index 0000000..d7cc13e
>> >> > --- /dev/null
>> >> > +++ b/drivers/media/v4l2-core/v4l2-clk.c
>> >> > @@ -0,0 +1,177 @@
>> >>
>> >> -barry

-barry


From s.hauer at pengutronix.de  Thu Apr 11 05:04:21 2013
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Thu, 11 Apr 2013 11:04:21 +0200
Subject: [PATCH] staging: drm/imx: update TODO file
In-Reply-To: <20130409231523.GA15722@kroah.com>
References: <20130409231523.GA15722@kroah.com>
Message-ID: <1365671061-10486-1-git-send-email-s.hauer@pengutronix.de>

One of the main things to do to the driver is to support
the common display famework (CDF) to hit mainline. As this will
make some changes to the devicetree bindings necessary it makes
sense to do it before we move out of staging.

Signed-off-by: Sascha Hauer <s.hauer at pengutronix.de>
---
 drivers/staging/imx-drm/TODO | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/staging/imx-drm/TODO b/drivers/staging/imx-drm/TODO
index e52adc4..123acbe 100644
--- a/drivers/staging/imx-drm/TODO
+++ b/drivers/staging/imx-drm/TODO
@@ -1,5 +1,8 @@
 TODO:
 - get DRM Maintainer review for this code
+- Wait for common display framework to hit mainline and update the IPU
+  driver to use it. This will most probably make changes to the devicetree
+  bindings necessary.
 - Factor out more code to common helper functions
 - decide where to put the base driver. It is not specific to a subsystem
   and would be used by DRM/KMS and media/V4L2
-- 
1.8.2.rc2



From grygorii.strashko at ti.com  Thu Apr 11 05:04:29 2013
From: grygorii.strashko at ti.com (Grygorii Strashko)
Date: Thu, 11 Apr 2013 12:04:29 +0300
Subject: [RFC][PATCH 1/2] ARM: OMAP4: clock: Add device tree support for
 AUXCLKs
In-Reply-To: <51666AE8.9060602@ti.com>
References: <515D2D30.3000306@ti.com> <20130404164137.GH10155@atomide.com>
 <515EA9E3.1010409@ti.com> <20130405155851.GA10155@atomide.com>
 <5163E589.1040809@ti.com> <20130409164928.GL10155@atomide.com>
 <20130409174319.GP10155@atomide.com> <20130409204900.GA8815@kahuna>
 <20130410080630.14359.68178@quantum> <5165453E.6090503@ti.com>
 <20130410173921.GA31017@kahuna> <51666AE8.9060602@ti.com>
Message-ID: <51667C9D.8080409@ti.com>

On 04/11/2013 10:48 AM, Roger Quadros wrote:
> On 04/10/2013 08:39 PM, Nishanth Menon wrote:
>> On 13:55-20130410, Roger Quadros wrote:
>>> On 04/10/2013 11:06 AM, Mike Turquette wrote:
>>>> Quoting Nishanth Menon (2013-04-09 13:49:00)
>>>>> On 10:43-20130409, Tony Lindgren wrote:
>>>>>> * Tony Lindgren <tony at atomide.com> [130409 09:54]:
>>>>>>> * Roger Quadros <rogerq at ti.com> [130409 03:00]:
>>>>>>>> On 04/05/2013 06:58 PM, Tony Lindgren wrote:
>>>>>>>>> Can't you just use the clock name there to get it?
>>>>>>>> In device tree we don't pass around clock names. You can either get
>>>>>>>> a phandle or an index to the clock.
>>>>>>>>
>>>>>>>> e.g. Documentation/devicetree/bindings/clock/imx31-clock.txt
>>>>>>> Yes I understand that. But the driver/clock/omap driver can just
>>>>>>> remap the DT device initially so the board specific clock is
>>>>>>> found from the clock alias table. Basically initially a passthrough
>>>>>>> driver that can be enhanced to parse DT clock bindings and load
>>>>>>> data from /lib/firmware.
>>>>>> Actually probably the driver/clock/omap can even do even less
>>>>>> initially. There probably even no need to remap clocks there.
>>>>>>
>>>>>> As long as the DT clock driver understands that a board specific
>>>>>> auxclk is specified in the DT it can just call clk_add_alias() so
>>>>>> the driver will get the right auxclk from cclock44xx_data.c.
>>>>>>
>>>>>> Then other features can be added later on like to allocate a
>>>>>> clock entirely based on the binding etc.
>>>>> I did try to have an implementation for cpufreq using clock nodes.
>>>>> unfortunately, device tree wont let me have arguments of strings :(
>>>>> So, I am unable to do clock = <&clk mpu_dpll>;
>>>>> instead, I am forced to do clock = <&clk 249>;
>>>>>
>>>> See http://article.gmane.org/gmane.linux.ports.arm.kernel/229034
>>>>
>>> Awesome. Thanks for pointing this out Mike.
>>>
>>> Now all we need to do is create a named define for each clock index in the
>>> header file.
>> Approach #3: Thanks to Tony for collaborating on this:
>> Works for cpufreq-cpu0 - additional patches:
>> http://pastebin.com/GHnTRVJf, http://pastebin.com/FZS89J6L (tested on
>> beagleXM)
>> Work for USB - http://pastebin.com/aJpDnXci - thanks Roger for testing
>> this.
>> Details in the patch below (Tony, I have added you as collaborator for
>> helping in getting this working-clk_add_alias was'nt needed in the
>> internal patch discussion we had - I have taken a bit of freedom in
>> adding your contributions to the patch below)
>>
>> Folks, this does seem to be the best compromise we can achieve at this
>> point in time. feedback on this approach is much appreciated - if folks
>> are ok, I can post this as an formal patch series.
> This looks fine to me. Minor comments below.

I like it. No IDs and can add clocks support in DT as needed.

>
>>  From 130a41821bf57081ca45ef654029175d173135e6 Mon Sep 17 00:00:00 2001
>> From: Nishanth Menon <nm at ti.com>
>> Date: Tue, 9 Apr 2013 19:26:40 -0500
>> Subject: [RFC PATCH] clk: OMAP: introduce device tree binding to kernel clock
>>   data
>>
>> OMAP clock data is located in arch/arm/mach-omap2/cclockXYZ_data.c.
>> However, this presents an obstacle for using these clock nodes in
>> Device Tree definitions. There are many possible approaches to this
>> problem as discussed in the following thread:
>> http://marc.info/?t=136370325600009&r=1&w=2
>> Highlights of the options:
>> a) device specific clk_add_alias:
>> 	cons: driver handling required
>> b) using an generic clk node and indexing to reach the clock required.
>>     This is similar in approach taken by tegra and few other platforms.
>>     example clock = <&clk 5>;
>>     cons: potential to have mismatches in indexed table and associated
>>     dtb data. In addition, managing continued documentation in bindings
>>     as clock indexing increases. Even though readability angle could be
>>     improved by using preprocessing of DT using macros, indexed approach
>>     is inherently risky from cases like the following:
>>     clk indexes in kernel:
>>     1 - mpu_dpll
>>     2 - aux_clk1
>>     3 - core_clk
>>     DT entry for peripheral x uses <&clk 2>, kernel updates to:
>>     1 - mpu_dpll
>>     2 - per_dpll
>>     3 - aux_clk1
>>     4 - core_clk
>>     using the old dtb(or dts missing an update), on new kernel which has
>>     updated indices will result in per_dpll now controlled for peripheral
>>     X without warning or any potential error detection and warning.
>>
>>     Even though we can claim this is user error, such errors are hard to
>>     track down and fix.
>>
>> An alternate approach introduced here is to introduce device tree bindings
>> corresponding to the clock nodes required in DT definition for SoC which
>> automatically maps back to the definitions in cclockXYZ_data.c.
>>
>> The driver introduced here to do this mapping will eventually be the
>> place where the clock handling will migrate to. We need to consider this
>> angle as well so that the solution will be an valid transition point for
>> moving the clock data out of kernel image (into device tree or firmware load
>> etc..).
>>
>> Overall strategy introduced here is simple: an clock node described in
> typo: "an"->"a"
>
>> device tree blob is used to identify the exact clock provided in the SoC
>> specific data. This is then linked back using of_clk_add_provider to the
>> device node to be accessible by of_clk_get.
>>
>> Based on discussion contributions from Roger Quadros, Grygorii Strashko
>> and others.
>>
>> [tony at atomide.com: co-developed]
>> Signed-off-by: Tony Lindgren <tony at atomide.com>
>> Signed-off-by: Nishanth Menon <nm at ti.com>
>> ---
>>   .../devicetree/bindings/clock/omap-clock.txt       |   40 +++++++++
>>   drivers/clk/Makefile                               |    1 +
>>   drivers/clk/omap/Makefile                          |    1 +
>>   drivers/clk/omap/clk.c                             |   94 ++++++++++++++++++++
>>   4 files changed, 136 insertions(+)
>>   create mode 100644 Documentation/devicetree/bindings/clock/omap-clock.txt
>>   create mode 100644 drivers/clk/omap/Makefile
>>   create mode 100644 drivers/clk/omap/clk.c
>>
>> diff --git a/Documentation/devicetree/bindings/clock/omap-clock.txt b/Documentation/devicetree/bindings/clock/omap-clock.txt
>> new file mode 100644
>> index 0000000..07e3ff8
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/clock/omap-clock.txt
>> @@ -0,0 +1,40 @@
>> +Device Tree Clock bindings for Texas Instrument's OMAP compatible platforms
>> +
>> +This binding is a work-in-progress, and meant to be stage #1 of transitioning
>> +OMAP clock data out of kernel image.
>> +
>> +This binding uses the common clock binding[1].
>> +
>> +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
>> +
>> +Required properties:
>> +- compatible : shall be "ti,omap-clock"
>> +- #clock-cells : from common clock binding; shall be set to 0.
>> +NOTE:
>> +node name should map to clock database in arch/arm/mach-omap2/cclock<SoC>_data.c
>> +Since all clocks are described with _ck, the node name is optimized to drop the
>> +usage of _ck. For example, a clock called dpll1_ck will be defined as dpll1.
>> +
>> +Example #1: describing clock node for CPU on OMAP34xx platform:
>> +Ref: arch/arm/mach-omap2/cclock3xxx_data.c
>> +describes the CPU clock to be as follows
>> +	CLK(NULL,	"dpll1_ck",	&dpll1_ck,	CK_3XXX),
>> +Corresponding binding will be:
>> +	dpll1: dpll1 {
>> +		#clock-cells = <0>;
>> +		compatible = "ti,omap-clock";
>> +	};
>> +And it's usage will be:
>> +		clocks = <&dpll1>;
>> +
>> +Example #2: describing clock node for auxilary clock #3 on OMAP443x platform:
>> +Ref: arch/arm/mach-omap2/cclock44xx_data.c
>> +describes the auxclk3 clock to be as follows:
>> +	CLK(NULL,	"auxclk3_ck",	&auxclk3_ck,	CK_443X),
>> +Corresponding binding will be:
>> +	auxclk3: auxclk3 {
>> +		#clock-cells = <1>;
>> +		compatible = "ti,omap-clock";
>> +	};
>> +And it's usage will be:
>> +	clocks = <&auxclk3>;
>> diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
>> index 300d477..a0209d7 100644
>> --- a/drivers/clk/Makefile
>> +++ b/drivers/clk/Makefile
>> @@ -27,6 +27,7 @@ obj-$(CONFIG_ARCH_U8500)	+= ux500/
>>   obj-$(CONFIG_ARCH_VT8500)	+= clk-vt8500.o
>>   obj-$(CONFIG_ARCH_ZYNQ)		+= clk-zynq.o
>>   obj-$(CONFIG_ARCH_TEGRA)	+= tegra/
>> +obj-$(CONFIG_ARCH_OMAP)		+= omap/
>>   
>>   obj-$(CONFIG_X86)		+= x86/
>>   
>> diff --git a/drivers/clk/omap/Makefile b/drivers/clk/omap/Makefile
>> new file mode 100644
>> index 0000000..8195931
>> --- /dev/null
>> +++ b/drivers/clk/omap/Makefile
>> @@ -0,0 +1 @@
>> +obj-y					+= clk.o
>> diff --git a/drivers/clk/omap/clk.c b/drivers/clk/omap/clk.c
>> new file mode 100644
>> index 0000000..63a4cce
>> --- /dev/null
>> +++ b/drivers/clk/omap/clk.c
>> @@ -0,0 +1,94 @@
>> +/*
>> + * Texas Instruments OMAP Clock driver
>> + *
>> + * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
>> + *	Nishanth Menon
> missing e-mail id.
>
>> + *	Tony Lindgren <tony at atomide.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.
>> + *
>> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
>> + * kind, whether express or implied; without even the implied warranty
>> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + */
>> +
>> +#include <linux/clkdev.h>
>> +#include <linux/clk-private.h>
>> +#include <linux/kernel.h>
>> +#include <linux/module.h>
>> +#include <linux/of_device.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/string.h>
>> +
>> +static const struct of_device_id omap_clk_of_match[] = {
>> +	{.compatible = "ti,omap-clock",},
>> +	{},
>> +};
>> +
>> +MODULE_DEVICE_TABLE(of, omap_clk_of_match);
>> +
> Is this driver ever going to be a loadable module? If not then you don't need this.
>
>> +/**
>> + * omap_clk_probe() - create link from DT definition to clock data
>> + * @pdev:	device node
>> + *
>> + * REVISIT: We are now assuming the following:
>> + * 1. omap clock names end with _ck
>> + * 2. omap clocks don't get removed
>> + */
>> +static int omap_clk_probe(struct platform_device *pdev)
>> +{
>> +	struct clk *clk;
>> +	int res;
>> +
>> +	const struct of_device_id *match;
>> +	struct device_node *np = pdev->dev.of_node;
>> +	char clk_name[32];
>> +
>> +	match = of_match_device(omap_clk_of_match, &pdev->dev);
>> +
>> +	/* Set up things so consumer can call clk_get() with name */
>> +	snprintf(clk_name, 32, "%s_ck", np->name);
>> +	clk = clk_get(NULL, clk_name);
>> +	if (IS_ERR(clk)) {
>> +		res = PTR_ERR(clk);
>> +		dev_err(&pdev->dev, "could not get clock %s (%d)\n",
>> +			clk_name, res);
>> +		goto out;
>> +	}
>> +
>> +	/* This allows the driver to of_clk_get() */
>> +	res = of_clk_add_provider(np, of_clk_src_simple_get, clk);
>> +	if (res)
>> +		dev_err(&pdev->dev, "could not add provider for %s (%d)\n",
>> +			clk_name, res);
>> +
>> +	clk_put(clk);
>> +out:
>> +	return res;
>> +}
>> +
>> +MODULE_ALIAS("platform:omap_clk");
> ditto.
>
>> +
>> +/* We assume here that OMAP clocks will not be removed */
>> +static struct platform_driver omap_clk_driver = {
>> +	.probe = omap_clk_probe,
>> +	.driver = {
>> +		   .name = "omap_clk",
>> +		   .owner = THIS_MODULE,
> same here.
>
>> +		   .of_match_table = of_match_ptr(omap_clk_of_match),
>> +		   },
>> +};
>> +
>> +static int __init omap_clk_init(void)
>> +{
>> +	return platform_driver_register(&omap_clk_driver);
>> +}
>> +
>> +arch_initcall(omap_clk_init);
>> +
>> +MODULE_DESCRIPTION("OMAP Clock driver");
>> +MODULE_AUTHOR("Texas Instruments Inc.");
>> +MODULE_LICENSE("GPL v2");
>>
> cheers,
> -roger

-grygorii


From s.nawrocki at samsung.com  Thu Apr 11 05:07:09 2013
From: s.nawrocki at samsung.com (Sylwester Nawrocki)
Date: Thu, 11 Apr 2013 11:07:09 +0200
Subject: [PATCH 11/30] [media] exynos: remove unnecessary header inclusions
In-Reply-To: <20130410211354.397d5689@redhat.com>
References: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
 <1365638712-1028578-12-git-send-email-arnd@arndb.de>
 <20130410211354.397d5689@redhat.com>
Message-ID: <51667D3D.20103@samsung.com>

On 04/11/2013 02:13 AM, Mauro Carvalho Chehab wrote:
> Em Thu, 11 Apr 2013 02:04:53 +0200
> Arnd Bergmann <arnd at arndb.de> escreveu:
> 
>> In multiplatform configurations, we cannot include headers
>> provided by only the exynos platform. Fortunately a number
>> of drivers that include those headers do not actually need
>> them, so we can just remove the inclusions.
>>
>> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
>> Cc: linux-media at vger.kernel.org
>> Cc: Mauro Carvalho Chehab <mchehab at redhat.com>
> 
> Acked-by: Mauro Carvalho Chehab <mchehab at redhat.com>

This patch is already queued in the media tree for 3.10, and it can
be found in -next now.

Thanks,
Sylwester



From daniel.lezcano at linaro.org  Thu Apr 11 05:07:52 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Thu, 11 Apr 2013 11:07:52 +0200
Subject: [PATCH] ARM: shmobile: r8a7740: Add Suspend-To-RAM modes and
 CPUIdle
In-Reply-To: <CABYn4sxEOvQhZP7GnS5-AgNjkvJJXyv4n1UjVGBjXbVq0N+9_A@mail.gmail.com>
References: <1365609107-14290-1-git-send-email-hechtb+renesas@gmail.com>
 <5165E929.9030309@linaro.org>
 <CABYn4sxEOvQhZP7GnS5-AgNjkvJJXyv4n1UjVGBjXbVq0N+9_A@mail.gmail.com>
Message-ID: <51667D68.7070804@linaro.org>

On 04/11/2013 09:07 AM, Bastian Hecht wrote:
> Hello Daniel,
> 
> thanks for the consolidation efforts.
> 
> 2013/4/11 Daniel Lezcano <daniel.lezcano at linaro.org>:
>> On 04/10/2013 05:51 PM, Bastian Hecht wrote:
>>> We add 2 sleep modes and register a CPUIdle driver that uses them.
>>>
>>> - A3SM PLL0 on/off:     Power domain A3SM that contains the ARM core
>>>                         and the 2nd level cache with either PLL0 on
>>>                       or off
>>>
>>> As the suspend to memory mechanism we use A3SM PLL off.
>>>
>>> The setup of the SYSC regarding the external IRQs is taken from
>>> pm-sh7372.c from Magnus Damm.
>>>
>>> Signed-off-by: Bastian Hecht <hechtb+renesas at gmail.com>
>>> ---
>>> Ok I need to add some remarks here:
>>>
>>> First this patch relies on a fix I've sent out today:
>>> "ARM: hw_breakpoint: Do not use __cpuinitdata for dbg_cpu_pm_nb"
>>> Without it we can't use suspend at all without a kernel panic.
>>>
>>> Next you can test this in two ways:
>>> Either add IRQF_NO_SUSPEND to the touchscreen driver st1232 at IRQ registration
>>> (hack) or extend the irqpin driver to support wakeup devices properly, meaning
>>> adding suspend and resume callbacks that handle it (proper way). Or you can add
>>> no_console_suspend to the boot options in r8a7740-armadillo800eva.dts. This way
>>> you can use the serial console as wakeup device.
>>>
>>>
>>>  arch/arm/mach-shmobile/Makefile               |    2 +-
>>>  arch/arm/mach-shmobile/include/mach/r8a7740.h |    2 +
>>>  arch/arm/mach-shmobile/pm-r8a7740.c           |  220 ++++++++++++++++++++++++-
>>>  arch/arm/mach-shmobile/sleep-r8a7740.S        |   68 ++++++++
>>>  4 files changed, 289 insertions(+), 3 deletions(-)
>>>  create mode 100644 arch/arm/mach-shmobile/sleep-r8a7740.S
>>>
>>> diff --git a/arch/arm/mach-shmobile/Makefile b/arch/arm/mach-shmobile/Makefile
>>> index 068f1da..0568894 100644
>>> --- a/arch/arm/mach-shmobile/Makefile
>>> +++ b/arch/arm/mach-shmobile/Makefile
>>> @@ -30,7 +30,7 @@ obj-$(CONFIG_SUSPEND)               += suspend.o
>>>  obj-$(CONFIG_CPU_IDLE)               += cpuidle.o
>>>  obj-$(CONFIG_ARCH_SHMOBILE)  += pm-rmobile.o
>>>  obj-$(CONFIG_ARCH_SH7372)    += pm-sh7372.o sleep-sh7372.o
>>> -obj-$(CONFIG_ARCH_R8A7740)   += pm-r8a7740.o
>>> +obj-$(CONFIG_ARCH_R8A7740)   += pm-r8a7740.o sleep-r8a7740.o
>>>  obj-$(CONFIG_ARCH_R8A7779)   += pm-r8a7779.o
>>>  obj-$(CONFIG_ARCH_SH73A0)    += pm-sh73a0.o
>>>
>>> diff --git a/arch/arm/mach-shmobile/include/mach/r8a7740.h b/arch/arm/mach-shmobile/include/mach/r8a7740.h
>>> index abdc4d4..ba4707b 100644
>>> --- a/arch/arm/mach-shmobile/include/mach/r8a7740.h
>>> +++ b/arch/arm/mach-shmobile/include/mach/r8a7740.h
>>> @@ -540,6 +540,8 @@ extern void r8a7740_add_standard_devices(void);
>>>  extern void r8a7740_clock_init(u8 md_ck);
>>>  extern void r8a7740_pinmux_init(void);
>>>  extern void r8a7740_pm_init(void);
>>> +extern void r8a7740_resume(void);
>>> +extern void r8a7740_shutdown(void);
>>>
>>>  #ifdef CONFIG_PM
>>>  extern void __init r8a7740_init_pm_domains(void);
>>> diff --git a/arch/arm/mach-shmobile/pm-r8a7740.c b/arch/arm/mach-shmobile/pm-r8a7740.c
>>> index 40b87aa..d4613f0 100644
>>> --- a/arch/arm/mach-shmobile/pm-r8a7740.c
>>> +++ b/arch/arm/mach-shmobile/pm-r8a7740.c
>>> @@ -8,10 +8,54 @@
>>>   * License.  See the file "COPYING" in the main directory of this archive
>>>   * for more details.
>>>   */
>>> +#include <linux/bitrev.h>
>>>  #include <linux/console.h>
>>> +#include <linux/cpuidle.h>
>>> +#include <linux/module.h>
>>>  #include <linux/suspend.h>
>>> +#include <linux/io.h>
>>> +#include <asm/suspend.h>
>>> +#include <asm/cacheflush.h>
>>> +#include <asm/cpuidle.h>
>>> +#include <asm/hardware/cache-l2x0.h>
>>>  #include <mach/pm-rmobile.h>
>>>  #include <mach/common.h>
>>> +#include <mach/r8a7740.h>
>>> +
>>> +/* CPGA */
>>> +#define PLLC01STPCR  IOMEM(0xe61500c8)
>>> +#define SYSTBCR              IOMEM(0xe6150024)
>>> +
>>> +/* SYSC */
>>> +#define STBCHR               IOMEM(0xe6180000)
>>> +#define STBCHRB              IOMEM(0xe6180040)
>>> +#define SPDCR                IOMEM(0xe6180008)
>>> +#define SBAR         IOMEM(0xe6180020)
>>> +#define SRSTFR               IOMEM(0xe61800B4)
>>> +#define WUPSMSK              IOMEM(0xe618002c)
>>> +#define WUPSMSK2     IOMEM(0xe6180048)
>>> +#define WUPSFAC              IOMEM(0xe6180098)
>>> +#define IRQCR                IOMEM(0xe618022c)
>>> +#define IRQCR2               IOMEM(0xe6180238)
>>> +#define IRQCR3               IOMEM(0xe6180244)
>>> +#define IRQCR4               IOMEM(0xe6180248)
>>> +
>>> +/* SRSTFR flags */
>>> +#define RAMST                (1 << 19)
>>> +#define RCLNKA               (1 << 7)
>>> +#define RCPRES               (1 << 5)
>>> +#define RCWD1                (1 << 4)
>>> +#define RPF          (1 << 0)
>>> +
>>> +/* INTC */
>>> +#define ICR1A                IOMEM(0xe6900000)
>>> +#define ICR2A                IOMEM(0xe6900004)
>>> +#define ICR3A                IOMEM(0xe6900008)
>>> +#define ICR4A                IOMEM(0xe690000c)
>>> +#define INTMSK00A    IOMEM(0xe6900040)
>>> +#define INTMSK10A    IOMEM(0xe6900044)
>>> +#define INTMSK20A    IOMEM(0xe6900048)
>>> +#define INTMSK30A    IOMEM(0xe690004c)
>>>
>>>  #ifdef CONFIG_PM
>>>  static int r8a7740_pd_a4s_suspend(void)
>>> @@ -58,12 +102,183 @@ void __init r8a7740_init_pm_domains(void)
>>>       rmobile_init_domains(r8a7740_pm_domains, ARRAY_SIZE(r8a7740_pm_domains));
>>>       pm_genpd_add_subdomain_names("A4S", "A3SP");
>>>  }
>>> -
>>>  #endif /* CONFIG_PM */
>>>
>>> +#if defined(CONFIG_SUSPEND) || defined(CONFIG_CPU_IDLE)
>>> +static void r8a7740_set_reset_vector(unsigned long address)
>>> +{
>>> +     __raw_writel(address, SBAR);
>>> +}
>>> +
>>> +static void r8a7740_icr_to_irqcr(unsigned long icr, u16 *irqcr1p, u16 *irqcr2p)
>>> +{
>>> +     u16 tmp, irqcr1, irqcr2;
>>> +     int k;
>>> +
>>> +     irqcr1 = 0;
>>> +     irqcr2 = 0;
>>> +
>>> +     /* convert INTCA ICR register layout to SYSC IRQCR+IRQCR2 */
>>> +     for (k = 0; k <= 7; k++) {
>>> +             tmp = (icr >> ((7 - k) * 4)) & 0xf;
>>> +             irqcr1 |= (tmp & 0x03) << (k * 2);
>>> +             irqcr2 |= (tmp >> 2) << (k * 2);
>>> +     }
>>> +
>>> +     *irqcr1p = irqcr1;
>>> +     *irqcr2p = irqcr2;
>>> +}
>>> +
>>> +static void r8a7740_setup_sysc(unsigned long msk, unsigned long msk2)
>>> +{
>>> +     u16 irqcrx_low, irqcrx_high, irqcry_low, irqcry_high;
>>> +     unsigned long tmp;
>>> +
>>> +     /* read IRQ0A -> IRQ15A mask */
>>> +     tmp = bitrev8(__raw_readb(INTMSK00A));
>>> +     tmp |= bitrev8(__raw_readb(INTMSK10A)) << 8;
>>> +
>>> +     /* setup WUPSMSK from clocks and external IRQ mask */
>>> +     msk = (~msk & 0xc030000f) | (tmp << 4);
>>> +     __raw_writel(msk, WUPSMSK);
>>> +
>>> +     /* propage level/edge trigger for external IRQ 0->15 */
>>> +     r8a7740_icr_to_irqcr(__raw_readl(ICR1A), &irqcrx_low, &irqcry_low);
>>> +     r8a7740_icr_to_irqcr(__raw_readl(ICR2A), &irqcrx_high, &irqcry_high);
>>> +     __raw_writel((irqcrx_high << 16) | irqcrx_low, IRQCR);
>>> +     __raw_writel((irqcry_high << 16) | irqcry_low, IRQCR2);
>>> +
>>> +     /* read IRQ16A -> IRQ31A mask */
>>> +     tmp = bitrev8(__raw_readb(INTMSK20A));
>>> +     tmp |= bitrev8(__raw_readb(INTMSK30A)) << 8;
>>> +
>>> +     /* setup WUPSMSK2 from clocks and external IRQ mask */
>>> +     msk2 = (~msk2 & 0x00030000) | tmp;
>>> +     __raw_writel(msk2, WUPSMSK2);
>>> +
>>> +     /* propage level/edge trigger for external IRQ 16->31 */
>>> +     r8a7740_icr_to_irqcr(__raw_readl(ICR3A), &irqcrx_low, &irqcry_low);
>>> +     r8a7740_icr_to_irqcr(__raw_readl(ICR4A), &irqcrx_high, &irqcry_high);
>>> +     __raw_writel((irqcrx_high << 16) | irqcrx_low, IRQCR3);
>>> +     __raw_writel((irqcry_high << 16) | irqcry_low, IRQCR4);
>>> +}
>>> +
>>> +static void r8a7740_prepare_wakeup(void)
>>> +{
>>> +     /* clear all flags that lead to a cold boot */
>>> +     __raw_writel(~(RAMST | RCLNKA | RCPRES | RCWD1 | RPF), SRSTFR);
>>> +     /* indicate warm boot */
>>> +     __raw_writel(0x80000000, STBCHRB);
>>> +     /* clear other flags checked by internal ROM boot loader */
>>> +     __raw_writel(0x00000000, STBCHR);
>>> +}
>>> +
>>> +static int r8a7740_do_suspend(unsigned long unused)
>>> +{
>>> +     /*
>>> +      * cpu_suspend() guarantees that all data made it to the L2.
>>> +      * Flush it out now and disable the cache controller.
>>> +      */
>>> +     outer_flush_all();
>>> +     outer_disable();
>>> +
>>> +     r8a7740_shutdown();
>>> +
>>> +     /* in case WFI fails to enter the low power state, restore things */
>>> +     outer_resume();
>>> +
>>> +     return 0;
>>> +}
>>> +
>>> +static void r8a7740_enter_a3sm_common(int pllc0_on)
>>> +{
>>> +     u32 reg32;
>>> +
>>> +     if (pllc0_on)
>>> +             __raw_writel(0, PLLC01STPCR);
>>> +     else
>>> +             __raw_writel(1 << 28, PLLC01STPCR);
>>> +
>>> +     r8a7740_set_reset_vector(__pa(r8a7740_resume));
>>> +     r8a7740_prepare_wakeup();
>>> +     r8a7740_setup_sysc(1 << 0, 0);
>>> +
>>> +     /* Activate delayed shutdown of A3SM */
>>> +     reg32 = __raw_readl(SPDCR);
>>> +     reg32 |= (1 << 31) | (1 << 12);
>>> +     __raw_writel(reg32, SPDCR);
>>> +
>>> +     /* We activate CPU Core Standby as well here */
>>> +     reg32 = __raw_readl(SYSTBCR);
>>> +     reg32 |= (1 << 4);
>>> +     __raw_writel(reg32, SYSTBCR);
>>> +
>>> +     /* Clear Wakeup Factors and do suspend */
>>> +     reg32 = __raw_readl(WUPSFAC);
>>> +     cpu_suspend(0, r8a7740_do_suspend);
>>> +     outer_resume();
>>> +     reg32 = __raw_readl(WUPSFAC);
>>> +
>>> +     /* Clear CPU Core Standby flag for other WFI instructions */
>>> +     reg32 &= ~(1 << 4);
>>> +     __raw_writel(reg32, SYSTBCR);
>>> +
>>> +}
>>> +#endif /* CONFIG_SUSPEND || CONFIG_CPU_IDLE */
>>> +
>>> +#ifdef CONFIG_CPU_IDLE
>>> +static int r8a7740_enter_a3sm_pll_on(struct cpuidle_device *dev,
>>> +                                     struct cpuidle_driver *drv, int index)
>>> +{
>>> +     r8a7740_enter_a3sm_common(1);
>>> +     return 1;
>>> +}
>>> +
>>> +static int r8a7740_enter_a3sm_pll_off(struct cpuidle_device *dev,
>>> +                                     struct cpuidle_driver *drv, int index)
>>> +{
>>> +     r8a7740_enter_a3sm_common(0);
>>> +     return 2;
>>> +}
>>> +
>>> +static struct cpuidle_driver r8a7740_cpuidle_driver = {
>>> +     .name                   = "r8a7740_cpuidle",
>>> +     .owner                  = THIS_MODULE,
>>> +     .en_core_tk_irqen       = 1,
>>> +     .state_count            = 3,
>>> +     .safe_state_index       = 0, /* C1 */
>>> +     .states[0] = ARM_CPUIDLE_WFI_STATE,
>>> +     .states[0].enter = shmobile_enter_wfi,
>>
>> The WFI macro already set a simple enter function doing cpu_do_idle.
> 
> Oh yes, I'll remove it.
> 
>> We are trying to consolidate the cpuidle drivers across the different
>> platforms [1]. One of the objective is to move the cpuidle drivers to
>> drivers/cpuidle, a place where they belong to.
>>
>> Do you think it is possible you split your code to have one part with
>> the cpuidle driver and another part with the PM code ?
> 
> Hmm. The CPUIdle part is enclosed in the #ifdef CONFIG_CPU_IDLE part anyway.
> The other part (CONFIG_SUSPEND | CONFIG_CPU_IDLE) contains the part
> that actually does drive down the hardware and is needed as soon as
> SUSPEND or CPUIdle is used.
> 
> So is it split well enough already or does it help if I split my patch
> into 2, first adding suspend and then CPUIdle to the same file? But
> the outcome will be the same I think.


Well, if you can convert the pm functions into ops used in the cpuidle
driver and then create a file eg. cpuidle-r8a7740.c with the cpuidle
code calling the ops that will separate clearly the cpuidle code from
the pm code and make easier to move the cpuidle driver to the
drivers/cpuidle directory. Also, I think that will help to consolidate
the other shmobile cpuidle drivers, maybe into a single one.






-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From mark.rutland at arm.com  Thu Apr 11 05:12:31 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Thu, 11 Apr 2013 10:12:31 +0100
Subject: [RFC PATCH 00/11] Topology bindings / Perf for big.LITTLE systems
Message-ID: <1365671562-2403-1-git-send-email-mark.rutland@arm.com>

The following patches implement perf support for big.LITTLE systems
(e.g. the A15x2 A7x3 coretile). The current implementation of one
virtual PMU across all CPUs is modified to have one virtual PMU per set
of compatible CPUs (e.g. one for the A15s, one for the A7s). Multiple
compatible clusters may be combined in one virtual PMU.

The affinity of these virtual PMUs is determined by the affinity of
interrupts for constituent physical PMUs. An interrupts-affinity
property is added to the PMU devicetree binding to handle this, which
refers to nodes in a topology description. When affinity information is
not provided, affinity information is determined in the same way as the
current implementation - interrupts are in order of (logical) cpu id,
and each is affine to a single CPU.

The topology description is necessary due to the lax nature of MPIDR
assignments in the wild, making them unsuitable in general for
determining the hierarchical structure of CPUs and clusters.

I've had a couple of previous attempts at representing this information in
devicetree [1,2], this series adds an example consumer (perf) and adds more
general infrastructure rather than limiting the use of the binding to
interrupts only.

Patches are based on v3.9-rc6.

Thanks,
Mark.

[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2012-October/128205.html
[2] http://lists.infradead.org/pipermail/linux-arm-kernel/2012-December/137290.html

Lorenzo Pieralisi (1):
  Documentation: DT: arm: define CPU topology bindings

Mark Rutland (10):
  arm: add functions to parse cpu affinity from dt
  arm: perf: clean up PMU names
  arm: perf: use IDR types for CPU PMUs
  arm: perf: make get_hw_events take arm_pmu
  arm: perf: dynamically allocate cpu hardware data
  arm: perf: treat PMUs as CPU affine
  arm: perf: probe number of counters on affine CPUs
  arm: perf: parse cpu affinity from dt
  arm: perf: allow multiple CPU PMUs to be registered
  arm: dts: add all PMUs for A15x2 A7x3 coretile

 Documentation/devicetree/bindings/arm/pmu.txt      |   7 +
 Documentation/devicetree/bindings/arm/topology.txt | 524 +++++++++++++++++++++
 arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts         |  44 +-
 arch/arm/include/asm/dt_affinity.h                 |  12 +
 arch/arm/include/asm/pmu.h                         |   3 +-
 arch/arm/kernel/devtree.c                          | 139 ++++++
 arch/arm/kernel/perf_event.c                       |  32 +-
 arch/arm/kernel/perf_event_cpu.c                   | 270 ++++++++---
 arch/arm/kernel/perf_event_v6.c                    |  16 +-
 arch/arm/kernel/perf_event_v7.c                    |  55 ++-
 arch/arm/kernel/perf_event_xscale.c                |  20 +-
 arch/arm/oprofile/common.c                         |   8 +-
 12 files changed, 1004 insertions(+), 126 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/topology.txt
 create mode 100644 arch/arm/include/asm/dt_affinity.h

-- 
1.8.1.1




From mark.rutland at arm.com  Thu Apr 11 05:12:32 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Thu, 11 Apr 2013 10:12:32 +0100
Subject: [RFC PATCH 01/11] Documentation: DT: arm: define CPU topology bindings
In-Reply-To: <1365671562-2403-1-git-send-email-mark.rutland@arm.com>
References: <1365671562-2403-1-git-send-email-mark.rutland@arm.com>
Message-ID: <1365671562-2403-2-git-send-email-mark.rutland@arm.com>

From: Lorenzo Pieralisi <Lorenzo.Pieralisi at arm.com>

The advent of multi-cluster ARM systems requires a mechanism to describe
how in hierarchical terms CPUs are connected in ARM SoCs so that the kernel
can initialize and map resources like IRQs and memory space to specific
group(s) of CPUs.

The CPU topology is made up of multiple hierarchy levels whose bottom
layers (aka leaf nodes in device tree syntax) contain links to the HW
CPUs in the system.

The topology bindings are generic for both 32-bit and 64-bit systems and
lay the groundwork on top of which affinity schemes can be built.

This patch provides the documentation in the kernel required to define the
device tree bindings describing the CPU topology for ARM 32-bit and 64-bit
systems.

Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
Signed-off-by: Mark Rutland <mark.rutland at arm.com>
---
 Documentation/devicetree/bindings/arm/topology.txt | 524 +++++++++++++++++++++
 1 file changed, 524 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/topology.txt

diff --git a/Documentation/devicetree/bindings/arm/topology.txt b/Documentation/devicetree/bindings/arm/topology.txt
new file mode 100644
index 0000000..07c4961
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/topology.txt
@@ -0,0 +1,524 @@
+===========================================
+ARM topology binding description
+===========================================
+
+===========================================
+1 - Introduction
+===========================================
+
+In an ARM system, the hierarchy of CPUs is defined through three entities that
+are used to describe the layout of physical CPUs in the system:
+
+- cluster
+- core
+- thread
+
+The cpu nodes (bindings defined in [1]) represent the devices that
+correspond to physical CPUs and are to be mapped to the hierarchy levels.
+
+The bottom hierarchy level sits at core or thread level depending on whether
+symmetric multi-threading (SMT) is supported or not.
+
+For instance in a system where CPUs support SMT, "cpu" nodes represent all
+threads existing in the system and map to the hierarchy level "thread" above.
+In systems where SMT is not supported "cpu" nodes represent all cores present
+in the system and map to the hierarchy level "core" above.
+
+ARM topology bindings allow one to associate cpu nodes with hierarchical groups
+corresponding to the system hierarchy; syntactically they are defined as device
+tree nodes.
+
+The remainder of this document provides the topology bindings for ARM, based
+on the ePAPR standard, available from:
+
+http://devicetree.org
+
+If not stated otherwise, whenever a reference to a cpu node phandle is made its
+value must point to a cpu node compliant with the cpu node bindings as
+documented in [1].
+A topology description containing phandles to cpu nodes that are not compliant
+with bindings standardized in [1] is therefore considered invalid.
+
+===========================================
+2 - cpu-map node
+===========================================
+
+The ARM CPU topology is defined within a container node, sitting at the top
+level of the device tree (/), the cpu-map node.
+
+- cpu-map node
+
+	Usage: Required to define ARM CPU topology
+
+	Description: The cpu-map node is just a container node where its
+		     subnodes describe the CPU topology
+
+	Node name must be "cpu-map".
+
+	A cpu-map node's child nodes can be:
+
+	- one or more cluster nodes
+
+	Any other configuration is considered invalid.
+
+The cpu-map node can only contain three types of child nodes:
+
+- cluster node
+- core node
+- thread node
+
+whose bindings are described in paragraph 3.
+
+The nodes describing the CPU topology (cluster/core/thread) can only be
+defined within the cpu-map node.
+Any other configuration is consider invalid and therefore must be ignored.
+
+===========================================
+2.1 - cpu-map child nodes naming convention
+===========================================
+
+cpu-map child nodes must follow a naming convention where the node name
+must be "clusterN", "coreN", "threadN" depending on the node type (ie
+cluster/core/thread) (where N = {0, 1, ...} is the node number; nodes which
+are siblings within a single common parent node must be given a unique and
+sequential N value, starting from 0).
+cpu-map child nodes which do not share a common parent node can have the same
+name (ie same number N as other cpu-map child nodes at different device tree
+levels) since name uniqueness will be guaranteed by the device tree hierarchy.
+
+===========================================
+3 - cluster/core/thread node bindings
+===========================================
+
+Bindings for cluster/cpu/thread nodes are defined as follows:
+
+- cluster node
+
+	 Description: must be declared within a cpu-map node, one node
+		      per cluster. A system can contain several layers of
+		      clustering and cluster nodes can be contained in parent
+		      cluster nodes.
+
+	The cluster node name must be "clusterN" as described in 2.1 above.
+	A cluster node can not be a leaf node.
+
+	A cluster node's child nodes must be:
+
+	- one or more cluster nodes; or
+	- one or more core nodes
+
+	Any other configuration is considered invalid.
+
+- core node
+
+	Description: must be declared in a cluster node, one node per core in
+		     the cluster. If the system does not support SMT, core
+		     nodes are leaf nodes, otherwise they become containers of
+		     thread nodes.
+
+	The core node name must be "coreN" as described in 2.1 above.
+
+	A core node must be a leaf node if SMT is not supported.
+
+	Properties for core nodes that are leaf nodes:
+
+	- cpu
+		Usage: required
+		Value type: <phandle>
+		Definition: a phandle to the cpu node that corresponds to the
+			    core node.
+
+	If a core node is not a leaf node (CPUs supporting SMT) a core node's
+	child nodes can be:
+
+	- one or more thread nodes
+
+	Any other configuration is considered invalid.
+
+- thread node
+
+	Description: must be declared in a core node, one node per thread
+		     in the core if the system supports SMT. Thread nodes are
+		     always leaf nodes in the device tree.
+
+	The thread node name must be "threadN" as described in 2.1 above.
+
+	A thread node must be a leaf node.
+
+	A thread node must contain the following property:
+
+	- cpu
+		Usage: required
+		Value type: <phandle>
+		Definition: a phandle to the cpu node that corresponds to
+			    the thread node.
+
+===========================================
+4 - Example dts
+===========================================
+
+Example 1 (ARM 64-bit, 16-cpu system, two clusters of clusters):
+
+cpu-map {
+
+	cluster0 {
+
+		cluster0 {
+
+			core0 {
+
+				thread0 {
+					cpu = <&CPU0>;
+				};
+
+				thread1 {
+					cpu = <&CPU1>;
+				};
+			};
+
+			core1 {
+
+				thread0 {
+					cpu = <&CPU2>;
+				};
+
+				thread1 {
+					cpu = <&CPU3>;
+				};
+			};
+		};
+
+		cluster1 {
+
+			core0 {
+
+				thread0 {
+					cpu = <&CPU4>;
+				};
+
+				thread1 {
+					cpu = <&CPU5>;
+				};
+			};
+
+			core1 {
+
+				thread0 {
+					cpu = <&CPU6>;
+				};
+
+				thread1 {
+					cpu = <&CPU7>;
+				};
+			};
+		};
+	};
+
+	cluster1 {
+
+		cluster0 {
+
+			core0 {
+
+				thread0 {
+					cpu = <&CPU8>;
+				};
+
+				thread1 {
+					cpu = <&CPU9>;
+				};
+			};
+
+			core1 {
+
+				thread0 {
+					cpu = <&CPU10>;
+				};
+
+				thread1 {
+					cpu = <&CPU11>;
+				};
+			};
+		};
+
+		cluster1 {
+
+			core0 {
+
+				thread0 {
+					cpu = <&CPU12>;
+				};
+
+				thread1 {
+					cpu = <&CPU13>;
+				};
+			};
+
+			core1 {
+
+				thread0 {
+					cpu = <&CPU14>;
+				};
+
+				thread1 {
+					cpu = <&CPU15>;
+				};
+			};
+		};
+	};
+};
+
+cpus {
+	#size-cells = <0>;
+	#address-cells = <2>;
+
+	CPU0: cpu at 0 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a57";
+		reg = <0x0 0x0>;
+		enable-method = "spin-table";
+		cpu-release-addr = <0 0x20000000>;
+	};
+
+	CPU1: cpu at 1 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a57";
+		reg = <0x0 0x1>;
+		enable-method = "spin-table";
+		cpu-release-addr = <0 0x20000000>;
+	};
+
+	CPU2: cpu at 100 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a57";
+		reg = <0x0 0x100>;
+		enable-method = "spin-table";
+		cpu-release-addr = <0 0x20000000>;
+	};
+
+	CPU3: cpu at 101 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a57";
+		reg = <0x0 0x101>;
+		enable-method = "spin-table";
+		cpu-release-addr = <0 0x20000000>;
+	};
+
+	CPU4: cpu at 10000 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a57";
+		reg = <0x0 0x10000>;
+		enable-method = "spin-table";
+		cpu-release-addr = <0 0x20000000>;
+	};
+
+	CPU5: cpu at 10001 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a57";
+		reg = <0x0 0x10001>;
+		enable-method = "spin-table";
+		cpu-release-addr = <0 0x20000000>;
+	};
+
+	CPU6: cpu at 10100 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a57";
+		reg = <0x0 0x10100>;
+		enable-method = "spin-table";
+		cpu-release-addr = <0 0x20000000>;
+	};
+
+	CPU7: cpu at 10101 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a57";
+		reg = <0x0 0x10101>;
+		enable-method = "spin-table";
+		cpu-release-addr = <0 0x20000000>;
+	};
+
+	CPU8: cpu at 100000000 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a57";
+		reg = <0x1 0x0>;
+		enable-method = "spin-table";
+		cpu-release-addr = <0 0x20000000>;
+	};
+
+	CPU9: cpu at 100000001 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a57";
+		reg = <0x1 0x1>;
+		enable-method = "spin-table";
+		cpu-release-addr = <0 0x20000000>;
+	};
+
+	CPU10: cpu at 100000100 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a57";
+		reg = <0x1 0x100>;
+		enable-method = "spin-table";
+		cpu-release-addr = <0 0x20000000>;
+	};
+
+	CPU11: cpu at 100000101 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a57";
+		reg = <0x1 0x101>;
+		enable-method = "spin-table";
+		cpu-release-addr = <0 0x20000000>;
+	};
+
+	CPU12: cpu at 100010000 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a57";
+		reg = <0x1 0x10000>;
+		enable-method = "spin-table";
+		cpu-release-addr = <0 0x20000000>;
+	};
+
+	CPU13: cpu at 100010001 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a57";
+		reg = <0x1 0x10001>;
+		enable-method = "spin-table";
+		cpu-release-addr = <0 0x20000000>;
+	};
+
+	CPU14: cpu at 100010100 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a57";
+		reg = <0x1 0x10100>;
+		enable-method = "spin-table";
+		cpu-release-addr = <0 0x20000000>;
+	};
+
+	CPU15: cpu at 100010101 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a57";
+		reg = <0x1 0x10101>;
+		enable-method = "spin-table";
+		cpu-release-addr = <0 0x20000000>;
+	};
+};
+
+Example 2 (ARM 32-bit, dual-cluster, 8-cpu system, no SMT):
+
+cpu-map {
+
+	cluster0 {
+
+		core0 {
+			cpu = <&CPU0>;
+		};
+
+		core1 {
+			cpu = <&CPU1>;
+		};
+
+		core2 {
+			cpu = <&CPU2>;
+		};
+
+		core3 {
+			cpu = <&CPU3>;
+		};
+
+	};
+
+	cluster1 {
+
+		core0 {
+			cpu = <&CPU4>;
+		};
+
+		core1 {
+			cpu = <&CPU5>;
+		};
+
+		core2 {
+			cpu = <&CPU6>;
+		};
+
+		core3 {
+			cpu = <&CPU7>;
+		};
+
+	};
+
+cpus {
+	#size-cells = <0>;
+	#address-cells = <1>;
+
+	CPU0: cpu at 0 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a15";
+		reg = <0x0>;
+	};
+
+	CPU1: cpu at 1 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a15";
+		reg = <0x1>;
+	};
+
+	CPU2: cpu at 2 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a15";
+		reg = <0x2>;
+	};
+
+	CPU3: cpu at 3 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a15";
+		reg = <0x3>;
+	};
+
+	CPU4: cpu at 100 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a7";
+		reg = <0x100>;
+	};
+
+	CPU5: cpu at 101 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a7";
+		reg = <0x101>;
+	};
+
+	CPU6: cpu at 102 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a7";
+		reg = <0x102>;
+	};
+
+	CPU7: cpu at 103 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a7";
+		reg = <0x103>;
+	};
+};
+
+Example 3 (ARM 32-bit, cortex-a8 single core):
+
+cpu-map {
+	cluster0 {
+		core0 {
+			cpu = <&CPU0>;
+		};
+	};
+};
+
+cpus {
+	#size-cells = <0>;
+	#address-cells = <1>;
+
+	CPU0: cpu at 0 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a8";
+		reg = <0x0>;
+	};
+};
+
+===============================================================================
+[1] ARM Linux kernel documentation
+    Documentation/devicetree/bindings/arm/cpus.txt
-- 
1.8.1.1




From mark.rutland at arm.com  Thu Apr 11 05:12:33 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Thu, 11 Apr 2013 10:12:33 +0100
Subject: [RFC PATCH 02/11] arm: add functions to parse cpu affinity from dt
In-Reply-To: <1365671562-2403-1-git-send-email-mark.rutland@arm.com>
References: <1365671562-2403-1-git-send-email-mark.rutland@arm.com>
Message-ID: <1365671562-2403-3-git-send-email-mark.rutland@arm.com>

Depending on hardware configuration, some devices may only be accessible
from certain CPUs, may have interrupts wired up to a subset of CPUs, or
may have operations which affect subsets of CPUs. To handle these
devices it is necessary to describe this affinity information in
devicetree.

This patch adds functions to handle parsing the CPU affinity of
properties from devicetree, based on Lorenzo's topology binding,
allowing subsets of CPUs to be associated with interrupts, hardware
ports, etc. The functions can be used to build cpumasks and also to test
whether an affinity property only targets one CPU independent of the
current configuration (e.g. when the kernel supports fewer CPUs than are
physically present). This is useful for dealing with mixed SPI/PPI
devices.

A device may have an arbitrary number of affinity properties, the
meaning of which is device-specific and should be specified in a given
device's binding document.

For example, an affinity property describing interrupt routing may
consist of a phandle pointing to a subtree of the topology nodes,
indicating the set of CPUs an interrupt originates from or may be taken
on. Bindings may have restrictions on the topology nodes referenced -
for describing coherency controls an affinity property may indicate a
whole cluster (uncluding any non-CPU logic it contains) is affected by
some configuration.

Signed-off-by: Mark Rutland <mark.rutland at arm.com>
---
 arch/arm/include/asm/dt_affinity.h |  12 ++++
 arch/arm/kernel/devtree.c          | 139 +++++++++++++++++++++++++++++++++++++
 2 files changed, 151 insertions(+)
 create mode 100644 arch/arm/include/asm/dt_affinity.h

diff --git a/arch/arm/include/asm/dt_affinity.h b/arch/arm/include/asm/dt_affinity.h
new file mode 100644
index 0000000..3acc7ce
--- /dev/null
+++ b/arch/arm/include/asm/dt_affinity.h
@@ -0,0 +1,12 @@
+#ifndef ARM_ASM_DT_IRQ_H
+#define ARM_ASM_DT_IRQ_H
+
+#include <linux/cpumask.h>
+#include <linux/of.h>
+#include <linux/types.h>
+
+int arm_dt_affine_get_mask(struct device_node *node, char *prop,
+			   int idx, cpumask_t *mask);
+bool arm_dt_affine_is_single(struct device_node *node, char *prop,
+			     int idx);
+#endif /* ARM_ASM_DT_IRQ_H */
diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
index 70f1bde..f31ab1e 100644
--- a/arch/arm/kernel/devtree.c
+++ b/arch/arm/kernel/devtree.c
@@ -20,6 +20,7 @@
 #include <linux/of_platform.h>
 
 #include <asm/cputype.h>
+#include <asm/dt_affinity.h>
 #include <asm/setup.h>
 #include <asm/page.h>
 #include <asm/smp_plat.h>
@@ -165,6 +166,144 @@ void __init arm_dt_init_cpu_maps(void)
 	}
 }
 
+/*
+ * Test if the node is within the topology tree.
+ * Walk up to the root, keeping refcounts balanced.
+ */
+static bool is_topology_node(struct device_node *node)
+{
+	/*
+	 * of_get_next_parent decrements the refcount of the provided node.
+	 * Increment it first to keep things balanced.
+	 */
+	struct device_node *parent = of_node_get(node);
+	if (!parent)
+		return false;
+
+	do {
+		if (parent->name && of_node_cmp(parent->name, "cpu-map") == 0) {
+			of_node_put(parent);
+			return true;
+		}
+	} while ((parent = of_get_next_parent(parent)));
+
+	return false;
+}
+
+static int cpu_node_to_id(struct device_node *node)
+{
+	u32 reg;
+
+	if (of_property_read_u32(node, "reg", &reg) != 0)
+		return -EINVAL;
+
+	return get_logical_index(reg);
+}
+
+static int arm_dt_affine_build_mask(struct device_node *affine,
+				    cpumask_t *mask)
+{
+	struct device_node *child, *parent = NULL;
+	int ret = -EINVAL;
+
+	if (!is_topology_node(affine))
+		return -EINVAL;
+
+	child = of_node_get(affine);
+	if (!child)
+		goto out_invalid;
+
+	parent = of_get_parent(child);
+	if (!parent)
+		goto out_invalid;
+
+	if (!cpumask_empty(mask))
+		goto out_invalid;
+
+	/*
+	 * Depth-first search over the topology tree, iterating over leaf nodes
+	 * and adding all referenced CPUs to the cpumask. Almost all of the
+	 * of_* iterators are built for breadth-first search, which means we
+	 * have to do a little more work to ensure refcounts are balanced.
+	 */
+	do {
+		struct device_node *tmp, *cpu_node;
+		int cpu;
+
+		/* head down to the leaf */
+		while ((tmp = of_get_next_child(child, NULL))) {
+			of_node_put(parent);
+			parent = child;
+			child = tmp;
+		}
+
+		cpu_node = of_parse_phandle(child, "cpu", 0);
+		cpu = cpu_node_to_id(cpu_node);
+
+		if (cpu < 0)
+			pr_warn("Invalid or unused cpu in topology description '%s', skipping\n",
+				cpu_node->full_name);
+		else
+			cpumask_set_cpu(cpu, mask);
+
+		of_node_put(cpu_node);
+
+		/*
+		 * Find the next sibling, or transitively a parent's sibling.
+		 * Don't go further up the tree than the affine node we were
+		 * handed.
+		 */
+		while (child != affine &&
+			!(child = of_get_next_child(parent, child))) {
+			child = parent;
+			parent = of_get_parent(parent);
+		}
+
+	} while (child != affine); /* all children covered. Time to stop */
+
+	ret = 0;
+
+out_invalid:
+	of_node_put(child);
+	of_node_put(parent);
+	return ret;
+}
+
+int arm_dt_affine_get_mask(struct device_node *node, char *prop,
+				  int idx, cpumask_t *mask)
+{
+	int ret = -EINVAL;
+	struct device_node *affine = of_parse_phandle(node, prop, idx);
+	if (!affine)
+		return -EINVAL;
+
+	if (!is_topology_node(affine))
+		goto out;
+
+	ret = arm_dt_affine_build_mask(affine, mask);
+
+out:
+	of_node_put(affine);
+	return ret;
+}
+
+bool arm_dt_affine_is_single(struct device_node *node, char *prop,
+			     int idx)
+{
+	bool ret;
+	struct device_node *affine = of_parse_phandle(node, prop, idx);
+	if (!affine || !is_topology_node(affine)) {
+		pr_warn("%s called on invalid node '%s'", __func__,
+			node ? node->full_name : "NULL");
+		of_node_put(affine);
+		return true;
+	}
+
+	ret = !!of_get_property(affine, "cpu", NULL);
+	of_node_put(affine);
+	return ret;
+}
+
 /**
  * setup_machine_fdt - Machine setup when an dtb was passed to the kernel
  * @dt_phys: physical address of dt blob
-- 
1.8.1.1




From mark.rutland at arm.com  Thu Apr 11 05:12:34 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Thu, 11 Apr 2013 10:12:34 +0100
Subject: [RFC PATCH 03/11] arm: perf: clean up PMU names
In-Reply-To: <1365671562-2403-1-git-send-email-mark.rutland@arm.com>
References: <1365671562-2403-1-git-send-email-mark.rutland@arm.com>
Message-ID: <1365671562-2403-4-git-send-email-mark.rutland@arm.com>

The perf userspace tools can't handle dashes or spaces in PMU names,
which conflicts with the current naming scheme in the arm perf backend.
This prevents these PMUs from being accessed by name from the perf
tools. Additionally the ARMv6 pmus are named "v6", which does not fully
distinguish them in the sys/bus/event_source namespace.

This patch replaces the spaces and dashes in pmu names with underscores,
and renames "v6" => "ARMv6" to better describe the PMU to userspace. The
oprofile name conversion code is updated to handle this.

Signed-off-by: Mark Rutland <mark.rutland at arm.com>
Reviewed-by: Will Deacon <will.deacon at arm.com>
---
 arch/arm/kernel/perf_event_v6.c |  4 ++--
 arch/arm/kernel/perf_event_v7.c | 10 +++++-----
 arch/arm/oprofile/common.c      |  8 ++++----
 3 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/arch/arm/kernel/perf_event_v6.c b/arch/arm/kernel/perf_event_v6.c
index 03664b0..e2e5795 100644
--- a/arch/arm/kernel/perf_event_v6.c
+++ b/arch/arm/kernel/perf_event_v6.c
@@ -655,7 +655,7 @@ static int armv6_map_event(struct perf_event *event)
 
 static int armv6pmu_init(struct arm_pmu *cpu_pmu)
 {
-	cpu_pmu->name		= "v6";
+	cpu_pmu->name		= "ARMv6";
 	cpu_pmu->handle_irq	= armv6pmu_handle_irq;
 	cpu_pmu->enable		= armv6pmu_enable_event;
 	cpu_pmu->disable	= armv6pmu_disable_event;
@@ -687,7 +687,7 @@ static int armv6mpcore_map_event(struct perf_event *event)
 
 static int armv6mpcore_pmu_init(struct arm_pmu *cpu_pmu)
 {
-	cpu_pmu->name		= "v6mpcore";
+	cpu_pmu->name		= "ARMv6mpcore";
 	cpu_pmu->handle_irq	= armv6pmu_handle_irq;
 	cpu_pmu->enable		= armv6pmu_enable_event;
 	cpu_pmu->disable	= armv6mpcore_pmu_disable_event;
diff --git a/arch/arm/kernel/perf_event_v7.c b/arch/arm/kernel/perf_event_v7.c
index 039cffb..16a0455 100644
--- a/arch/arm/kernel/perf_event_v7.c
+++ b/arch/arm/kernel/perf_event_v7.c
@@ -1240,7 +1240,7 @@ static u32 armv7_read_num_pmnc_events(void)
 static int armv7_a8_pmu_init(struct arm_pmu *cpu_pmu)
 {
 	armv7pmu_init(cpu_pmu);
-	cpu_pmu->name		= "ARMv7 Cortex-A8";
+	cpu_pmu->name		= "ARMv7_Cortex_A8";
 	cpu_pmu->map_event	= armv7_a8_map_event;
 	cpu_pmu->num_events	= armv7_read_num_pmnc_events();
 	return 0;
@@ -1249,7 +1249,7 @@ static int armv7_a8_pmu_init(struct arm_pmu *cpu_pmu)
 static int armv7_a9_pmu_init(struct arm_pmu *cpu_pmu)
 {
 	armv7pmu_init(cpu_pmu);
-	cpu_pmu->name		= "ARMv7 Cortex-A9";
+	cpu_pmu->name		= "ARMv7_Cortex_A9";
 	cpu_pmu->map_event	= armv7_a9_map_event;
 	cpu_pmu->num_events	= armv7_read_num_pmnc_events();
 	return 0;
@@ -1258,7 +1258,7 @@ static int armv7_a9_pmu_init(struct arm_pmu *cpu_pmu)
 static int armv7_a5_pmu_init(struct arm_pmu *cpu_pmu)
 {
 	armv7pmu_init(cpu_pmu);
-	cpu_pmu->name		= "ARMv7 Cortex-A5";
+	cpu_pmu->name		= "ARMv7_Cortex_A5";
 	cpu_pmu->map_event	= armv7_a5_map_event;
 	cpu_pmu->num_events	= armv7_read_num_pmnc_events();
 	return 0;
@@ -1267,7 +1267,7 @@ static int armv7_a5_pmu_init(struct arm_pmu *cpu_pmu)
 static int armv7_a15_pmu_init(struct arm_pmu *cpu_pmu)
 {
 	armv7pmu_init(cpu_pmu);
-	cpu_pmu->name		= "ARMv7 Cortex-A15";
+	cpu_pmu->name		= "ARMv7_Cortex_A15";
 	cpu_pmu->map_event	= armv7_a15_map_event;
 	cpu_pmu->num_events	= armv7_read_num_pmnc_events();
 	cpu_pmu->set_event_filter = armv7pmu_set_event_filter;
@@ -1277,7 +1277,7 @@ static int armv7_a15_pmu_init(struct arm_pmu *cpu_pmu)
 static int armv7_a7_pmu_init(struct arm_pmu *cpu_pmu)
 {
 	armv7pmu_init(cpu_pmu);
-	cpu_pmu->name		= "ARMv7 Cortex-A7";
+	cpu_pmu->name		= "ARMv7_Cortex_A7";
 	cpu_pmu->map_event	= armv7_a7_map_event;
 	cpu_pmu->num_events	= armv7_read_num_pmnc_events();
 	cpu_pmu->set_event_filter = armv7pmu_set_event_filter;
diff --git a/arch/arm/oprofile/common.c b/arch/arm/oprofile/common.c
index 99c63d4b..31be981 100644
--- a/arch/arm/oprofile/common.c
+++ b/arch/arm/oprofile/common.c
@@ -35,10 +35,10 @@ static struct op_perf_name {
 } op_perf_name_map[] = {
 	{ "xscale1",		"arm/xscale1"	},
 	{ "xscale1",		"arm/xscale2"	},
-	{ "v6",			"arm/armv6"	},
-	{ "v6mpcore",		"arm/mpcore"	},
-	{ "ARMv7 Cortex-A8",	"arm/armv7"	},
-	{ "ARMv7 Cortex-A9",	"arm/armv7-ca9"	},
+	{ "ARMv6",		"arm/armv6"	},
+	{ "ARMv6mpcore",	"arm/mpcore"	},
+	{ "ARMv7_Cortex_A8",	"arm/armv7"	},
+	{ "ARMv7_Cortex_A9",	"arm/armv7-ca9"	},
 };
 
 char *op_name_from_perf_id(void)
-- 
1.8.1.1




From mark.rutland at arm.com  Thu Apr 11 05:12:35 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Thu, 11 Apr 2013 10:12:35 +0100
Subject: [RFC PATCH 04/11] arm: perf: use IDR types for CPU PMUs
In-Reply-To: <1365671562-2403-1-git-send-email-mark.rutland@arm.com>
References: <1365671562-2403-1-git-send-email-mark.rutland@arm.com>
Message-ID: <1365671562-2403-5-git-send-email-mark.rutland@arm.com>

For systems with heterogeneous CPUs (e.g. big.LITTLE systems) the PMUs
can be different in each cluster, and not all events can be migrated
between clusters. To allow userspace to deal with this, it must be
possible to address each PMU independently.

This patch changes PMUs to be registered with dynamic (IDR) types,
allowing them to be targeted individually. Each PMU's type can be found
in ${SYSFS_ROOT}/bus/event_source/devices/${PMU_NAME}/type.

>From userspace, raw events can be targeted at a specific PMU:
$ perf stat -e ${PMU_NAME}/config=V,config1=V1,.../

Doing this does not break existing tools which use existing perf types:
when perf core can't find a PMU of matching type (in perf_init_event)
it'll iterate over the set of all PMUs. If a compatible PMU exists,
it'll be found eventually. If more than one compatible PMU exists, the
event will be handled by whichever PMU happens to be earlier in the pmus
list (which currently will be the last compatible PMU registered).

Signed-off-by: Mark Rutland <mark.rutland at arm.com>
Reviewed-by: Will Deacon <will.deacon at arm.com>
---
 arch/arm/kernel/perf_event.c     | 6 +++++-
 arch/arm/kernel/perf_event_cpu.c | 2 +-
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c
index 146157d..3e20fa5 100644
--- a/arch/arm/kernel/perf_event.c
+++ b/arch/arm/kernel/perf_event.c
@@ -73,8 +73,12 @@ armpmu_map_event(struct perf_event *event,
 		 u32 raw_event_mask)
 {
 	u64 config = event->attr.config;
+	int type = event->attr.type;
 
-	switch (event->attr.type) {
+	if (type >= PERF_TYPE_MAX && type == event->pmu->type)
+		return armpmu_map_raw_event(raw_event_mask, config);
+
+	switch (type) {
 	case PERF_TYPE_HARDWARE:
 		return armpmu_map_hw_event(event_map, config);
 	case PERF_TYPE_HW_CACHE:
diff --git a/arch/arm/kernel/perf_event_cpu.c b/arch/arm/kernel/perf_event_cpu.c
index 1f2740e..31e9c41 100644
--- a/arch/arm/kernel/perf_event_cpu.c
+++ b/arch/arm/kernel/perf_event_cpu.c
@@ -284,7 +284,7 @@ static int cpu_pmu_device_probe(struct platform_device *pdev)
 	cpu_pmu = pmu;
 	cpu_pmu->plat_device = pdev;
 	cpu_pmu_init(cpu_pmu);
-	ret = armpmu_register(cpu_pmu, PERF_TYPE_RAW);
+	ret = armpmu_register(cpu_pmu, -1);
 
 	if (!ret)
 		return 0;
-- 
1.8.1.1




From mark.rutland at arm.com  Thu Apr 11 05:12:36 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Thu, 11 Apr 2013 10:12:36 +0100
Subject: [RFC PATCH 05/11] arm: perf: make get_hw_events take arm_pmu
In-Reply-To: <1365671562-2403-1-git-send-email-mark.rutland@arm.com>
References: <1365671562-2403-1-git-send-email-mark.rutland@arm.com>
Message-ID: <1365671562-2403-6-git-send-email-mark.rutland@arm.com>

Currently get_hw_events can only handle one PMU of a particular type, as
it doesn't receive any input to differentiate instances. To support
multiple instances of similar PMUs, each with their own set of
pmu_hw_events structures, get_hw_events must be passed some value that
can be used to find the correct set of pmu_hw_events structures.

This patch changes the interface of get_hw_events to take a struct
arm_pmu pointer, to enable future support for multiple PMUs.

Signed-off-by: Mark Rutland <mark.rutland at arm.com>
Reviewed-by: Will Deacon <will.deacon at arm.com>
---
 arch/arm/include/asm/pmu.h          |  2 +-
 arch/arm/kernel/perf_event.c        |  6 +++---
 arch/arm/kernel/perf_event_cpu.c    |  2 +-
 arch/arm/kernel/perf_event_v6.c     | 12 ++++++------
 arch/arm/kernel/perf_event_v7.c     | 10 +++++-----
 arch/arm/kernel/perf_event_xscale.c | 20 ++++++++++----------
 6 files changed, 26 insertions(+), 26 deletions(-)

diff --git a/arch/arm/include/asm/pmu.h b/arch/arm/include/asm/pmu.h
index f24edad..56724b2 100644
--- a/arch/arm/include/asm/pmu.h
+++ b/arch/arm/include/asm/pmu.h
@@ -86,7 +86,7 @@ struct arm_pmu {
 	struct mutex	reserve_mutex;
 	u64		max_period;
 	struct platform_device	*plat_device;
-	struct pmu_hw_events	*(*get_hw_events)(void);
+	struct pmu_hw_events	*(*get_hw_events)(struct arm_pmu *pmu);
 };
 
 #define to_arm_pmu(p) (container_of(p, struct arm_pmu, pmu))
diff --git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c
index 3e20fa5..5bcd8ac 100644
--- a/arch/arm/kernel/perf_event.c
+++ b/arch/arm/kernel/perf_event.c
@@ -201,7 +201,7 @@ static void
 armpmu_del(struct perf_event *event, int flags)
 {
 	struct arm_pmu *armpmu = to_arm_pmu(event->pmu);
-	struct pmu_hw_events *hw_events = armpmu->get_hw_events();
+	struct pmu_hw_events *hw_events = armpmu->get_hw_events(armpmu);
 	struct hw_perf_event *hwc = &event->hw;
 	int idx = hwc->idx;
 
@@ -216,7 +216,7 @@ static int
 armpmu_add(struct perf_event *event, int flags)
 {
 	struct arm_pmu *armpmu = to_arm_pmu(event->pmu);
-	struct pmu_hw_events *hw_events = armpmu->get_hw_events();
+	struct pmu_hw_events *hw_events = armpmu->get_hw_events(armpmu);
 	struct hw_perf_event *hwc = &event->hw;
 	int idx;
 	int err = 0;
@@ -449,7 +449,7 @@ static int armpmu_event_init(struct perf_event *event)
 static void armpmu_enable(struct pmu *pmu)
 {
 	struct arm_pmu *armpmu = to_arm_pmu(pmu);
-	struct pmu_hw_events *hw_events = armpmu->get_hw_events();
+	struct pmu_hw_events *hw_events = armpmu->get_hw_events(armpmu);
 	int enabled = bitmap_weight(hw_events->used_mask, armpmu->num_events);
 
 	if (enabled)
diff --git a/arch/arm/kernel/perf_event_cpu.c b/arch/arm/kernel/perf_event_cpu.c
index 31e9c41..80f1a26 100644
--- a/arch/arm/kernel/perf_event_cpu.c
+++ b/arch/arm/kernel/perf_event_cpu.c
@@ -66,7 +66,7 @@ EXPORT_SYMBOL_GPL(perf_num_counters);
 #include "perf_event_v6.c"
 #include "perf_event_v7.c"
 
-static struct pmu_hw_events *cpu_pmu_get_cpu_events(void)
+static struct pmu_hw_events *cpu_pmu_get_cpu_events(struct arm_pmu *pmu)
 {
 	return &__get_cpu_var(cpu_hw_events);
 }
diff --git a/arch/arm/kernel/perf_event_v6.c b/arch/arm/kernel/perf_event_v6.c
index e2e5795..1647716 100644
--- a/arch/arm/kernel/perf_event_v6.c
+++ b/arch/arm/kernel/perf_event_v6.c
@@ -439,7 +439,7 @@ static void armv6pmu_enable_event(struct perf_event *event)
 	unsigned long val, mask, evt, flags;
 	struct arm_pmu *cpu_pmu = to_arm_pmu(event->pmu);
 	struct hw_perf_event *hwc = &event->hw;
-	struct pmu_hw_events *events = cpu_pmu->get_hw_events();
+	struct pmu_hw_events *events = cpu_pmu->get_hw_events(cpu_pmu);
 	int idx = hwc->idx;
 
 	if (ARMV6_CYCLE_COUNTER == idx) {
@@ -477,7 +477,7 @@ armv6pmu_handle_irq(int irq_num,
 	unsigned long pmcr = armv6_pmcr_read();
 	struct perf_sample_data data;
 	struct arm_pmu *cpu_pmu = (struct arm_pmu *)dev;
-	struct pmu_hw_events *cpuc = cpu_pmu->get_hw_events();
+	struct pmu_hw_events *cpuc = cpu_pmu->get_hw_events(cpu_pmu);
 	struct pt_regs *regs;
 	int idx;
 
@@ -533,7 +533,7 @@ armv6pmu_handle_irq(int irq_num,
 static void armv6pmu_start(struct arm_pmu *cpu_pmu)
 {
 	unsigned long flags, val;
-	struct pmu_hw_events *events = cpu_pmu->get_hw_events();
+	struct pmu_hw_events *events = cpu_pmu->get_hw_events(cpu_pmu);
 
 	raw_spin_lock_irqsave(&events->pmu_lock, flags);
 	val = armv6_pmcr_read();
@@ -545,7 +545,7 @@ static void armv6pmu_start(struct arm_pmu *cpu_pmu)
 static void armv6pmu_stop(struct arm_pmu *cpu_pmu)
 {
 	unsigned long flags, val;
-	struct pmu_hw_events *events = cpu_pmu->get_hw_events();
+	struct pmu_hw_events *events = cpu_pmu->get_hw_events(cpu_pmu);
 
 	raw_spin_lock_irqsave(&events->pmu_lock, flags);
 	val = armv6_pmcr_read();
@@ -586,7 +586,7 @@ static void armv6pmu_disable_event(struct perf_event *event)
 	unsigned long val, mask, evt, flags;
 	struct arm_pmu *cpu_pmu = to_arm_pmu(event->pmu);
 	struct hw_perf_event *hwc = &event->hw;
-	struct pmu_hw_events *events = cpu_pmu->get_hw_events();
+	struct pmu_hw_events *events = cpu_pmu->get_hw_events(cpu_pmu);
 	int idx = hwc->idx;
 
 	if (ARMV6_CYCLE_COUNTER == idx) {
@@ -621,7 +621,7 @@ static void armv6mpcore_pmu_disable_event(struct perf_event *event)
 	unsigned long val, mask, flags, evt = 0;
 	struct arm_pmu *cpu_pmu = to_arm_pmu(event->pmu);
 	struct hw_perf_event *hwc = &event->hw;
-	struct pmu_hw_events *events = cpu_pmu->get_hw_events();
+	struct pmu_hw_events *events = cpu_pmu->get_hw_events(cpu_pmu);
 	int idx = hwc->idx;
 
 	if (ARMV6_CYCLE_COUNTER == idx) {
diff --git a/arch/arm/kernel/perf_event_v7.c b/arch/arm/kernel/perf_event_v7.c
index 16a0455..f4d185e 100644
--- a/arch/arm/kernel/perf_event_v7.c
+++ b/arch/arm/kernel/perf_event_v7.c
@@ -955,7 +955,7 @@ static void armv7pmu_enable_event(struct perf_event *event)
 	unsigned long flags;
 	struct hw_perf_event *hwc = &event->hw;
 	struct arm_pmu *cpu_pmu = to_arm_pmu(event->pmu);
-	struct pmu_hw_events *events = cpu_pmu->get_hw_events();
+	struct pmu_hw_events *events = cpu_pmu->get_hw_events(cpu_pmu);
 	int idx = hwc->idx;
 
 	if (!armv7_pmnc_counter_valid(cpu_pmu, idx)) {
@@ -1001,7 +1001,7 @@ static void armv7pmu_disable_event(struct perf_event *event)
 	unsigned long flags;
 	struct hw_perf_event *hwc = &event->hw;
 	struct arm_pmu *cpu_pmu = to_arm_pmu(event->pmu);
-	struct pmu_hw_events *events = cpu_pmu->get_hw_events();
+	struct pmu_hw_events *events = cpu_pmu->get_hw_events(cpu_pmu);
 	int idx = hwc->idx;
 
 	if (!armv7_pmnc_counter_valid(cpu_pmu, idx)) {
@@ -1033,7 +1033,7 @@ static irqreturn_t armv7pmu_handle_irq(int irq_num, void *dev)
 	u32 pmnc;
 	struct perf_sample_data data;
 	struct arm_pmu *cpu_pmu = (struct arm_pmu *)dev;
-	struct pmu_hw_events *cpuc = cpu_pmu->get_hw_events();
+	struct pmu_hw_events *cpuc = cpu_pmu->get_hw_events(cpu_pmu);
 	struct pt_regs *regs;
 	int idx;
 
@@ -1093,7 +1093,7 @@ static irqreturn_t armv7pmu_handle_irq(int irq_num, void *dev)
 static void armv7pmu_start(struct arm_pmu *cpu_pmu)
 {
 	unsigned long flags;
-	struct pmu_hw_events *events = cpu_pmu->get_hw_events();
+	struct pmu_hw_events *events = cpu_pmu->get_hw_events(cpu_pmu);
 
 	raw_spin_lock_irqsave(&events->pmu_lock, flags);
 	/* Enable all counters */
@@ -1104,7 +1104,7 @@ static void armv7pmu_start(struct arm_pmu *cpu_pmu)
 static void armv7pmu_stop(struct arm_pmu *cpu_pmu)
 {
 	unsigned long flags;
-	struct pmu_hw_events *events = cpu_pmu->get_hw_events();
+	struct pmu_hw_events *events = cpu_pmu->get_hw_events(cpu_pmu);
 
 	raw_spin_lock_irqsave(&events->pmu_lock, flags);
 	/* Disable all counters */
diff --git a/arch/arm/kernel/perf_event_xscale.c b/arch/arm/kernel/perf_event_xscale.c
index 63990c4..cd670ea 100644
--- a/arch/arm/kernel/perf_event_xscale.c
+++ b/arch/arm/kernel/perf_event_xscale.c
@@ -225,7 +225,7 @@ xscale1pmu_handle_irq(int irq_num, void *dev)
 	unsigned long pmnc;
 	struct perf_sample_data data;
 	struct arm_pmu *cpu_pmu = (struct arm_pmu *)dev;
-	struct pmu_hw_events *cpuc = cpu_pmu->get_hw_events();
+	struct pmu_hw_events *cpuc = cpu_pmu->get_hw_events(cpu_pmu);
 	struct pt_regs *regs;
 	int idx;
 
@@ -285,7 +285,7 @@ static void xscale1pmu_enable_event(struct perf_event *event)
 	unsigned long val, mask, evt, flags;
 	struct arm_pmu *cpu_pmu = to_arm_pmu(event->pmu);
 	struct hw_perf_event *hwc = &event->hw;
-	struct pmu_hw_events *events = cpu_pmu->get_hw_events();
+	struct pmu_hw_events *events = cpu_pmu->get_hw_events(cpu_pmu);
 	int idx = hwc->idx;
 
 	switch (idx) {
@@ -321,7 +321,7 @@ static void xscale1pmu_disable_event(struct perf_event *event)
 	unsigned long val, mask, evt, flags;
 	struct arm_pmu *cpu_pmu = to_arm_pmu(event->pmu);
 	struct hw_perf_event *hwc = &event->hw;
-	struct pmu_hw_events *events = cpu_pmu->get_hw_events();
+	struct pmu_hw_events *events = cpu_pmu->get_hw_events(cpu_pmu);
 	int idx = hwc->idx;
 
 	switch (idx) {
@@ -374,7 +374,7 @@ xscale1pmu_get_event_idx(struct pmu_hw_events *cpuc,
 static void xscale1pmu_start(struct arm_pmu *cpu_pmu)
 {
 	unsigned long flags, val;
-	struct pmu_hw_events *events = cpu_pmu->get_hw_events();
+	struct pmu_hw_events *events = cpu_pmu->get_hw_events(cpu_pmu);
 
 	raw_spin_lock_irqsave(&events->pmu_lock, flags);
 	val = xscale1pmu_read_pmnc();
@@ -386,7 +386,7 @@ static void xscale1pmu_start(struct arm_pmu *cpu_pmu)
 static void xscale1pmu_stop(struct arm_pmu *cpu_pmu)
 {
 	unsigned long flags, val;
-	struct pmu_hw_events *events = cpu_pmu->get_hw_events();
+	struct pmu_hw_events *events = cpu_pmu->get_hw_events(cpu_pmu);
 
 	raw_spin_lock_irqsave(&events->pmu_lock, flags);
 	val = xscale1pmu_read_pmnc();
@@ -572,7 +572,7 @@ xscale2pmu_handle_irq(int irq_num, void *dev)
 	unsigned long pmnc, of_flags;
 	struct perf_sample_data data;
 	struct arm_pmu *cpu_pmu = (struct arm_pmu *)dev;
-	struct pmu_hw_events *cpuc = cpu_pmu->get_hw_events();
+	struct pmu_hw_events *cpuc = cpu_pmu->get_hw_events(cpu_pmu);
 	struct pt_regs *regs;
 	int idx;
 
@@ -626,7 +626,7 @@ static void xscale2pmu_enable_event(struct perf_event *event)
 	unsigned long flags, ien, evtsel;
 	struct arm_pmu *cpu_pmu = to_arm_pmu(event->pmu);
 	struct hw_perf_event *hwc = &event->hw;
-	struct pmu_hw_events *events = cpu_pmu->get_hw_events();
+	struct pmu_hw_events *events = cpu_pmu->get_hw_events(cpu_pmu);
 	int idx = hwc->idx;
 
 	ien = xscale2pmu_read_int_enable();
@@ -672,7 +672,7 @@ static void xscale2pmu_disable_event(struct perf_event *event)
 	unsigned long flags, ien, evtsel, of_flags;
 	struct arm_pmu *cpu_pmu = to_arm_pmu(event->pmu);
 	struct hw_perf_event *hwc = &event->hw;
-	struct pmu_hw_events *events = cpu_pmu->get_hw_events();
+	struct pmu_hw_events *events = cpu_pmu->get_hw_events(cpu_pmu);
 	int idx = hwc->idx;
 
 	ien = xscale2pmu_read_int_enable();
@@ -738,7 +738,7 @@ out:
 static void xscale2pmu_start(struct arm_pmu *cpu_pmu)
 {
 	unsigned long flags, val;
-	struct pmu_hw_events *events = cpu_pmu->get_hw_events();
+	struct pmu_hw_events *events = cpu_pmu->get_hw_events(cpu_pmu);
 
 	raw_spin_lock_irqsave(&events->pmu_lock, flags);
 	val = xscale2pmu_read_pmnc() & ~XSCALE_PMU_CNT64;
@@ -750,7 +750,7 @@ static void xscale2pmu_start(struct arm_pmu *cpu_pmu)
 static void xscale2pmu_stop(struct arm_pmu *cpu_pmu)
 {
 	unsigned long flags, val;
-	struct pmu_hw_events *events = cpu_pmu->get_hw_events();
+	struct pmu_hw_events *events = cpu_pmu->get_hw_events(cpu_pmu);
 
 	raw_spin_lock_irqsave(&events->pmu_lock, flags);
 	val = xscale2pmu_read_pmnc();
-- 
1.8.1.1




From mark.rutland at arm.com  Thu Apr 11 05:12:37 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Thu, 11 Apr 2013 10:12:37 +0100
Subject: [RFC PATCH 06/11] arm: perf: dynamically allocate cpu hardware data
In-Reply-To: <1365671562-2403-1-git-send-email-mark.rutland@arm.com>
References: <1365671562-2403-1-git-send-email-mark.rutland@arm.com>
Message-ID: <1365671562-2403-7-git-send-email-mark.rutland@arm.com>

To support multiple PMUs, each PMU will need its own accounting data.
As we don't know how (in general) many PMUs we'll have to support at
compile-time, we must allocate the data at runtime dynamically

Signed-off-by: Mark Rutland <mark.rutland at arm.com>
Reviewed-by: Will Deacon <will.deacon at arm.com>
---
 arch/arm/kernel/perf_event_cpu.c | 73 ++++++++++++++++++++++++++++------------
 1 file changed, 51 insertions(+), 22 deletions(-)

diff --git a/arch/arm/kernel/perf_event_cpu.c b/arch/arm/kernel/perf_event_cpu.c
index 80f1a26..ae5be75 100644
--- a/arch/arm/kernel/perf_event_cpu.c
+++ b/arch/arm/kernel/perf_event_cpu.c
@@ -33,9 +33,25 @@
 /* Set at runtime when we know what CPU type we are. */
 static struct arm_pmu *cpu_pmu;
 
-static DEFINE_PER_CPU(struct perf_event * [ARMPMU_MAX_HWEVENTS], hw_events);
-static DEFINE_PER_CPU(unsigned long [BITS_TO_LONGS(ARMPMU_MAX_HWEVENTS)], used_mask);
-static DEFINE_PER_CPU(struct pmu_hw_events, cpu_hw_events);
+/*
+ * All of the dynamically sized pmu_hw data for the number of events supported
+ * by CPU PMUs, aggregated together for easier allocation / freeing.
+ */
+struct cpu_pmu_hw {
+	struct pmu_hw_events cpu_hw_events;
+	struct perf_event *hw_events[ARMPMU_MAX_HWEVENTS];
+	unsigned long used_mask[BITS_TO_LONGS(ARMPMU_MAX_HWEVENTS)];
+};
+
+/*
+ * For mapping between an arm_pmu for a CPU and its CPU-affine data.
+ */
+struct cpu_pmu {
+	struct arm_pmu armpmu;
+	struct cpu_pmu_hw __percpu *cpu_hw;
+};
+
+#define to_cpu_pmu(p) (container_of(p, struct cpu_pmu, armpmu))
 
 /*
  * Despite the names, these two functions are CPU-specific and are used
@@ -68,7 +84,9 @@ EXPORT_SYMBOL_GPL(perf_num_counters);
 
 static struct pmu_hw_events *cpu_pmu_get_cpu_events(struct arm_pmu *pmu)
 {
-	return &__get_cpu_var(cpu_hw_events);
+	struct cpu_pmu *cpu_pmu = to_cpu_pmu(pmu);
+	struct cpu_pmu_hw *hw = this_cpu_ptr(cpu_pmu->cpu_hw);
+	return &hw->cpu_hw_events;
 }
 
 static void cpu_pmu_free_irq(struct arm_pmu *cpu_pmu)
@@ -132,23 +150,25 @@ static int cpu_pmu_request_irq(struct arm_pmu *cpu_pmu, irq_handler_t handler)
 	return 0;
 }
 
-static void cpu_pmu_init(struct arm_pmu *cpu_pmu)
+static void cpu_pmu_init(struct cpu_pmu *cpu_pmu)
 {
 	int cpu;
+	struct arm_pmu *arm_pmu = &cpu_pmu->armpmu;
+
 	for_each_possible_cpu(cpu) {
-		struct pmu_hw_events *events = &per_cpu(cpu_hw_events, cpu);
-		events->events = per_cpu(hw_events, cpu);
-		events->used_mask = per_cpu(used_mask, cpu);
-		raw_spin_lock_init(&events->pmu_lock);
+		struct cpu_pmu_hw *cpu_hw = per_cpu_ptr(cpu_pmu->cpu_hw, cpu);
+		cpu_hw->cpu_hw_events.events = cpu_hw->hw_events;
+		cpu_hw->cpu_hw_events.used_mask = cpu_hw->used_mask;
+		raw_spin_lock_init(&cpu_hw->cpu_hw_events.pmu_lock);
 	}
 
-	cpu_pmu->get_hw_events	= cpu_pmu_get_cpu_events;
-	cpu_pmu->request_irq	= cpu_pmu_request_irq;
-	cpu_pmu->free_irq	= cpu_pmu_free_irq;
+	arm_pmu->get_hw_events	= cpu_pmu_get_cpu_events;
+	arm_pmu->request_irq	= cpu_pmu_request_irq;
+	arm_pmu->free_irq	= cpu_pmu_free_irq;
 
 	/* Ensure the PMU has sane values out of reset. */
-	if (cpu_pmu->reset)
-		on_each_cpu(cpu_pmu->reset, cpu_pmu, 1);
+	if (arm_pmu->reset)
+		on_each_cpu(arm_pmu->reset, arm_pmu, 1);
 }
 
 /*
@@ -255,7 +275,7 @@ static int cpu_pmu_device_probe(struct platform_device *pdev)
 	const struct of_device_id *of_id;
 	int (*init_fn)(struct arm_pmu *);
 	struct device_node *node = pdev->dev.of_node;
-	struct arm_pmu *pmu;
+	struct cpu_pmu *pmu;
 	int ret = -ENODEV;
 
 	if (cpu_pmu) {
@@ -263,34 +283,43 @@ static int cpu_pmu_device_probe(struct platform_device *pdev)
 		return -ENOSPC;
 	}
 
-	pmu = kzalloc(sizeof(struct arm_pmu), GFP_KERNEL);
+	pmu = kzalloc(sizeof(*pmu), GFP_KERNEL);
 	if (!pmu) {
 		pr_info("failed to allocate PMU device!");
 		return -ENOMEM;
 	}
 
+	pmu->cpu_hw = alloc_percpu(struct cpu_pmu_hw);
+	if (!pmu->cpu_hw) {
+		pr_info("failed to allocate PMU hw data!\n");
+		ret = -ENOMEM;
+		goto out_pmu;
+	}
+
 	if (node && (of_id = of_match_node(cpu_pmu_of_device_ids, pdev->dev.of_node))) {
 		init_fn = of_id->data;
-		ret = init_fn(pmu);
+		ret = init_fn(&pmu->armpmu);
 	} else {
-		ret = probe_current_pmu(pmu);
+		ret = probe_current_pmu(&pmu->armpmu);
 	}
 
 	if (ret) {
 		pr_info("failed to probe PMU!");
-		goto out_free;
+		goto out_hw;
 	}
 
-	cpu_pmu = pmu;
+	cpu_pmu = &pmu->armpmu;
 	cpu_pmu->plat_device = pdev;
-	cpu_pmu_init(cpu_pmu);
+	cpu_pmu_init(pmu);
 	ret = armpmu_register(cpu_pmu, -1);
 
 	if (!ret)
 		return 0;
 
-out_free:
+out_hw:
+	free_percpu(pmu->cpu_hw);
 	pr_info("failed to register PMU devices!");
+out_pmu:
 	kfree(pmu);
 	return ret;
 }
-- 
1.8.1.1




From mark.rutland at arm.com  Thu Apr 11 05:12:38 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Thu, 11 Apr 2013 10:12:38 +0100
Subject: [RFC PATCH 07/11] arm: perf: treat PMUs as CPU affine
In-Reply-To: <1365671562-2403-1-git-send-email-mark.rutland@arm.com>
References: <1365671562-2403-1-git-send-email-mark.rutland@arm.com>
Message-ID: <1365671562-2403-8-git-send-email-mark.rutland@arm.com>

In multi-cluster systems, the PMUs can be different across clusters, and
so our logical PMU may not be able to schedule events on all CPUs.

This patch adds a cpumask to encode which CPUs a PMU driver supports
controlling events for, and limits the driver to scheduling events on
those CPUs. Currently the cpumask is set to match all CPUs.

Signed-off-by: Mark Rutland <mark.rutland at arm.com>
Reviewed-by: Will Deacon <will.deacon at arm.com>
---
 arch/arm/include/asm/pmu.h       |  1 +
 arch/arm/kernel/perf_event.c     | 20 ++++++++++++++++++++
 arch/arm/kernel/perf_event_cpu.c | 10 +++++++++-
 3 files changed, 30 insertions(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/pmu.h b/arch/arm/include/asm/pmu.h
index 56724b2..4688692 100644
--- a/arch/arm/include/asm/pmu.h
+++ b/arch/arm/include/asm/pmu.h
@@ -65,6 +65,7 @@ struct pmu_hw_events {
 struct arm_pmu {
 	struct pmu	pmu;
 	cpumask_t	active_irqs;
+	cpumask_t	supported_cpus;
 	char		*name;
 	irqreturn_t	(*handle_irq)(int irq_num, void *dev);
 	void		(*enable)(struct perf_event *event);
diff --git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c
index 5bcd8ac..ebcd123 100644
--- a/arch/arm/kernel/perf_event.c
+++ b/arch/arm/kernel/perf_event.c
@@ -12,6 +12,7 @@
  */
 #define pr_fmt(fmt) "hw perfevents: " fmt
 
+#include <linux/cpumask.h>
 #include <linux/kernel.h>
 #include <linux/platform_device.h>
 #include <linux/pm_runtime.h>
@@ -21,6 +22,11 @@
 #include <asm/pmu.h>
 #include <asm/stacktrace.h>
 
+static bool cpu_supported(struct arm_pmu *armpmu, int cpu)
+{
+	return cpumask_test_cpu(cpu, &armpmu->supported_cpus);
+}
+
 static int
 armpmu_map_cache_event(const unsigned (*cache_map)
 				      [PERF_COUNT_HW_CACHE_MAX]
@@ -221,6 +227,10 @@ armpmu_add(struct perf_event *event, int flags)
 	int idx;
 	int err = 0;
 
+	/* An event following a process won't be stopped earlier */
+	if (!cpu_supported(armpmu, smp_processor_id()))
+		return -ENOENT;
+
 	perf_pmu_disable(event->pmu);
 
 	/* If we don't have a space for the counter then finish early. */
@@ -417,6 +427,16 @@ static int armpmu_event_init(struct perf_event *event)
 	int err = 0;
 	atomic_t *active_events = &armpmu->active_events;
 
+	/*
+	 * Reject CPU-affine events for CPUs that are of a different class to
+	 * that which this PMU handles. Process-following events (where
+	 * event->cpu == -1) can be migrated between CPUs, and thus we have to
+	 * reject them later (in armpmu_add) if they're scheduled on a
+	 * different class of CPU.
+	 */
+	if (event->cpu != -1 && !cpu_supported(armpmu, event->cpu))
+		return -ENOENT;
+
 	/* does not support taken branch sampling */
 	if (has_branch_stack(event))
 		return -EOPNOTSUPP;
diff --git a/arch/arm/kernel/perf_event_cpu.c b/arch/arm/kernel/perf_event_cpu.c
index ae5be75..c1a9880c 100644
--- a/arch/arm/kernel/perf_event_cpu.c
+++ b/arch/arm/kernel/perf_event_cpu.c
@@ -168,7 +168,8 @@ static void cpu_pmu_init(struct cpu_pmu *cpu_pmu)
 
 	/* Ensure the PMU has sane values out of reset. */
 	if (arm_pmu->reset)
-		on_each_cpu(arm_pmu->reset, arm_pmu, 1);
+		on_each_cpu_mask(&arm_pmu->supported_cpus, arm_pmu->reset,
+				 arm_pmu, 1);
 }
 
 /*
@@ -180,9 +181,13 @@ static void cpu_pmu_init(struct cpu_pmu *cpu_pmu)
 static int __cpuinit cpu_pmu_notify(struct notifier_block *b,
 				    unsigned long action, void *hcpu)
 {
+	int cpu = (long)hcpu;
 	if ((action & ~CPU_TASKS_FROZEN) != CPU_STARTING)
 		return NOTIFY_DONE;
 
+	if (!cpumask_test_cpu(cpu, &cpu_pmu->supported_cpus))
+		return NOTIFY_DONE;
+
 	if (cpu_pmu && cpu_pmu->reset)
 		cpu_pmu->reset(cpu_pmu);
 	else
@@ -296,6 +301,9 @@ static int cpu_pmu_device_probe(struct platform_device *pdev)
 		goto out_pmu;
 	}
 
+	/* Assume by default that we're on a homogeneous system */
+	cpumask_setall(&pmu->armpmu.supported_cpus);
+
 	if (node && (of_id = of_match_node(cpu_pmu_of_device_ids, pdev->dev.of_node))) {
 		init_fn = of_id->data;
 		ret = init_fn(&pmu->armpmu);
-- 
1.8.1.1




From mark.rutland at arm.com  Thu Apr 11 05:12:39 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Thu, 11 Apr 2013 10:12:39 +0100
Subject: [RFC PATCH 08/11] arm: perf: probe number of counters on affine CPUs
In-Reply-To: <1365671562-2403-1-git-send-email-mark.rutland@arm.com>
References: <1365671562-2403-1-git-send-email-mark.rutland@arm.com>
Message-ID: <1365671562-2403-9-git-send-email-mark.rutland@arm.com>

In heterogeneous systems, the  number of counters may differ across
clusters. To find the number of counters for a cluster, we must probe
the PMU from a CPU in that cluster.

Signed-off-by: Mark Rutland <mark.rutland at arm.com>
Reviewed-by: Will Deacon <will.deacon at arm.com>
---
 arch/arm/kernel/perf_event_v7.c | 35 ++++++++++++++++++++---------------
 1 file changed, 20 insertions(+), 15 deletions(-)

diff --git a/arch/arm/kernel/perf_event_v7.c b/arch/arm/kernel/perf_event_v7.c
index f4d185e..519948f 100644
--- a/arch/arm/kernel/perf_event_v7.c
+++ b/arch/arm/kernel/perf_event_v7.c
@@ -1226,15 +1226,25 @@ static void armv7pmu_init(struct arm_pmu *cpu_pmu)
 	cpu_pmu->max_period	= (1LLU << 32) - 1;
 };
 
-static u32 armv7_read_num_pmnc_events(void)
+static void armv7_read_num_pmnc_events(void *info)
 {
-	u32 nb_cnt;
+	int *nb_cnt = info;
 
 	/* Read the nb of CNTx counters supported from PMNC */
-	nb_cnt = (armv7_pmnc_read() >> ARMV7_PMNC_N_SHIFT) & ARMV7_PMNC_N_MASK;
+	*nb_cnt = (armv7_pmnc_read() >> ARMV7_PMNC_N_SHIFT) & ARMV7_PMNC_N_MASK;
 
-	/* Add the CPU cycles counter and return */
-	return nb_cnt + 1;
+	/* Add the CPU cycles counter */
+	*nb_cnt += 1;
+}
+
+static int armv7_probe_num_events(struct arm_pmu *arm_pmu)
+{
+	int ret;
+	ret = smp_call_function_any(&arm_pmu->supported_cpus,
+				    armv7_read_num_pmnc_events,
+				    &arm_pmu->num_events, 1);
+
+	return ret;
 }
 
 static int armv7_a8_pmu_init(struct arm_pmu *cpu_pmu)
@@ -1242,8 +1252,7 @@ static int armv7_a8_pmu_init(struct arm_pmu *cpu_pmu)
 	armv7pmu_init(cpu_pmu);
 	cpu_pmu->name		= "ARMv7_Cortex_A8";
 	cpu_pmu->map_event	= armv7_a8_map_event;
-	cpu_pmu->num_events	= armv7_read_num_pmnc_events();
-	return 0;
+	return armv7_probe_num_events(cpu_pmu);
 }
 
 static int armv7_a9_pmu_init(struct arm_pmu *cpu_pmu)
@@ -1251,8 +1260,7 @@ static int armv7_a9_pmu_init(struct arm_pmu *cpu_pmu)
 	armv7pmu_init(cpu_pmu);
 	cpu_pmu->name		= "ARMv7_Cortex_A9";
 	cpu_pmu->map_event	= armv7_a9_map_event;
-	cpu_pmu->num_events	= armv7_read_num_pmnc_events();
-	return 0;
+	return armv7_probe_num_events(cpu_pmu);
 }
 
 static int armv7_a5_pmu_init(struct arm_pmu *cpu_pmu)
@@ -1260,8 +1268,7 @@ static int armv7_a5_pmu_init(struct arm_pmu *cpu_pmu)
 	armv7pmu_init(cpu_pmu);
 	cpu_pmu->name		= "ARMv7_Cortex_A5";
 	cpu_pmu->map_event	= armv7_a5_map_event;
-	cpu_pmu->num_events	= armv7_read_num_pmnc_events();
-	return 0;
+	return armv7_probe_num_events(cpu_pmu);
 }
 
 static int armv7_a15_pmu_init(struct arm_pmu *cpu_pmu)
@@ -1269,9 +1276,8 @@ static int armv7_a15_pmu_init(struct arm_pmu *cpu_pmu)
 	armv7pmu_init(cpu_pmu);
 	cpu_pmu->name		= "ARMv7_Cortex_A15";
 	cpu_pmu->map_event	= armv7_a15_map_event;
-	cpu_pmu->num_events	= armv7_read_num_pmnc_events();
 	cpu_pmu->set_event_filter = armv7pmu_set_event_filter;
-	return 0;
+	return armv7_probe_num_events(cpu_pmu);
 }
 
 static int armv7_a7_pmu_init(struct arm_pmu *cpu_pmu)
@@ -1279,9 +1285,8 @@ static int armv7_a7_pmu_init(struct arm_pmu *cpu_pmu)
 	armv7pmu_init(cpu_pmu);
 	cpu_pmu->name		= "ARMv7_Cortex_A7";
 	cpu_pmu->map_event	= armv7_a7_map_event;
-	cpu_pmu->num_events	= armv7_read_num_pmnc_events();
 	cpu_pmu->set_event_filter = armv7pmu_set_event_filter;
-	return 0;
+	return armv7_probe_num_events(cpu_pmu);
 }
 #else
 static inline int armv7_a8_pmu_init(struct arm_pmu *cpu_pmu)
-- 
1.8.1.1




From mark.rutland at arm.com  Thu Apr 11 05:12:40 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Thu, 11 Apr 2013 10:12:40 +0100
Subject: [RFC PATCH 09/11] arm: perf: parse cpu affinity from dt
In-Reply-To: <1365671562-2403-1-git-send-email-mark.rutland@arm.com>
References: <1365671562-2403-1-git-send-email-mark.rutland@arm.com>
Message-ID: <1365671562-2403-10-git-send-email-mark.rutland@arm.com>

The current way we read interrupts form devicetree assumes that
interrupts are in increasing order of logical cpu id (MPIDR.Aff{2,1,0}),
and that these logical ids are in a contiguous block. This may not be
the case in general - after a kexec cpu ids may be arbitrarily assigned,
and multi-cluster systems do not have a contiguous range of cpu ids.

This patch parses cpu affinity information for interrupts from an
optional "interrupts-affinity" devicetree property described in the
devicetree binding document. Currently only SPIs are supported.

Signed-off-by: Mark Rutland <mark.rutland at arm.com>
---
 Documentation/devicetree/bindings/arm/pmu.txt |   7 ++
 arch/arm/kernel/perf_event_cpu.c              | 136 ++++++++++++++++++++------
 2 files changed, 115 insertions(+), 28 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/pmu.txt b/Documentation/devicetree/bindings/arm/pmu.txt
index 343781b..0caf968 100644
--- a/Documentation/devicetree/bindings/arm/pmu.txt
+++ b/Documentation/devicetree/bindings/arm/pmu.txt
@@ -17,6 +17,13 @@ Required properties:
 	"arm,arm1136-pmu"
 - interrupts : 1 combined interrupt or 1 per core.
 
+Optional properties:
+
+- interrupts-affinity : a list of phandles to topology nodes as described in
+                        Documentation/devicetree/bindings/arm/topology.txt.
+			Each phandle describes the affinity of the element in
+			the interrupts property at the same index.
+
 Example:
 
 pmu {
diff --git a/arch/arm/kernel/perf_event_cpu.c b/arch/arm/kernel/perf_event_cpu.c
index c1a9880c..6d8cbb1 100644
--- a/arch/arm/kernel/perf_event_cpu.c
+++ b/arch/arm/kernel/perf_event_cpu.c
@@ -27,9 +27,15 @@
 #include <linux/spinlock.h>
 
 #include <asm/cputype.h>
+#include <asm/dt_affinity.h>
 #include <asm/irq_regs.h>
 #include <asm/pmu.h>
 
+struct cpu_pmu_irq {
+	int irq;
+	int cpu;
+};
+
 /* Set at runtime when we know what CPU type we are. */
 static struct arm_pmu *cpu_pmu;
 
@@ -49,6 +55,8 @@ struct cpu_pmu_hw {
 struct cpu_pmu {
 	struct arm_pmu armpmu;
 	struct cpu_pmu_hw __percpu *cpu_hw;
+	struct cpu_pmu_irq *interrupts;
+	int nr_irqs;
 };
 
 #define to_cpu_pmu(p) (container_of(p, struct cpu_pmu, armpmu))
@@ -89,62 +97,58 @@ static struct pmu_hw_events *cpu_pmu_get_cpu_events(struct arm_pmu *pmu)
 	return &hw->cpu_hw_events;
 }
 
-static void cpu_pmu_free_irq(struct arm_pmu *cpu_pmu)
+static void cpu_pmu_free_irq(struct arm_pmu *pmu)
 {
-	int i, irq, irqs;
-	struct platform_device *pmu_device = cpu_pmu->plat_device;
+	int i, irq, irqs, cpu;
+	struct cpu_pmu *cpu_pmu = container_of(pmu, struct cpu_pmu, armpmu);
 
-	irqs = min(pmu_device->num_resources, num_possible_cpus());
+	irqs = cpu_pmu->nr_irqs;
 
 	for (i = 0; i < irqs; ++i) {
-		if (!cpumask_test_and_clear_cpu(i, &cpu_pmu->active_irqs))
+		cpu = cpu_pmu->interrupts[i].cpu;
+		irq = cpu_pmu->interrupts[i].irq;
+		if (irq < 0 || cpu < 0)
+			continue;
+		if (!cpumask_test_and_clear_cpu(cpu, &pmu->active_irqs))
 			continue;
-		irq = platform_get_irq(pmu_device, i);
 		if (irq >= 0)
-			free_irq(irq, cpu_pmu);
+			free_irq(irq, pmu);
 	}
 }
 
-static int cpu_pmu_request_irq(struct arm_pmu *cpu_pmu, irq_handler_t handler)
+static int cpu_pmu_request_irq(struct arm_pmu *pmu, irq_handler_t handler)
 {
-	int i, err, irq, irqs;
-	struct platform_device *pmu_device = cpu_pmu->plat_device;
+	int err, i, irq, irqs, cpu;
+	struct cpu_pmu *cpu_pmu = container_of(pmu, struct cpu_pmu, armpmu);
 
-	if (!pmu_device)
-		return -ENODEV;
+	irqs = cpu_pmu->nr_irqs;
 
-	irqs = min(pmu_device->num_resources, num_possible_cpus());
-	if (irqs < 1) {
-		pr_err("no irqs for PMUs defined\n");
-		return -ENODEV;
-	}
+	for (i = 0; i < irqs; i++) {
+		irq = cpu_pmu->interrupts[i].irq;
+		cpu = cpu_pmu->interrupts[i].cpu;
 
-	for (i = 0; i < irqs; ++i) {
-		err = 0;
-		irq = platform_get_irq(pmu_device, i);
-		if (irq < 0)
+		if (irq < 0 || cpu < 0)
 			continue;
-
 		/*
 		 * If we have a single PMU interrupt that we can't shift,
 		 * assume that we're running on a uniprocessor machine and
 		 * continue. Otherwise, continue without this interrupt.
 		 */
-		if (irq_set_affinity(irq, cpumask_of(i)) && irqs > 1) {
+		if (irq_set_affinity(irq, cpumask_of(cpu)) && irqs > 1) {
 			pr_warning("unable to set irq affinity (irq=%d, cpu=%u)\n",
-				    irq, i);
+				    irq, cpu);
 			continue;
 		}
 
 		err = request_irq(irq, handler, IRQF_NOBALANCING, "arm-pmu",
-				  cpu_pmu);
+				  pmu);
 		if (err) {
 			pr_err("unable to request IRQ%d for ARM PMU counters\n",
 				irq);
 			return err;
 		}
 
-		cpumask_set_cpu(i, &cpu_pmu->active_irqs);
+		cpumask_set_cpu(cpu, &pmu->active_irqs);
 	}
 
 	return 0;
@@ -275,6 +279,79 @@ static int probe_current_pmu(struct arm_pmu *pmu)
 	return ret;
 }
 
+static int parse_platdata(struct cpu_pmu *cpu_pmu, struct platform_device *pdev)
+{
+	int err;
+	cpumask_var_t tmp_mask;
+	struct cpu_pmu_irq *interrupts;
+	int i, irqs = pdev->num_resources;
+	struct device_node *node;
+	bool affine;
+
+	node = pdev->dev.of_node;
+	affine = node && of_get_property(node, "interrupts-affinity", NULL);
+
+	if (!affine)
+		irqs = min(pdev->num_resources, num_possible_cpus());
+
+	if (irqs < 1)
+		return -ENODEV;
+
+	cpu_pmu->nr_irqs = irqs;
+
+	interrupts = kzalloc(sizeof(*interrupts) * irqs, GFP_KERNEL);
+	if (!interrupts)
+		return -ENOMEM;
+
+	if (!alloc_cpumask_var(&tmp_mask, GFP_KERNEL)) {
+		err = -ENOMEM;
+		goto out;
+	}
+
+	for (i = 0; i < irqs; i++) {
+		int cpu = i;
+
+		interrupts[i].irq = platform_get_irq(pdev, i);
+		if (interrupts[i].irq < 0) {
+			interrupts[i].cpu = -1;
+			continue;
+		}
+
+		if (affine) {
+			if (!arm_dt_affine_is_single(node,
+				"interrupts-affinity", i)) {
+				pr_err("PPIs not supported (%s[%d])\n",
+					node->full_name, i);
+				err = -EINVAL;
+				goto out;
+			}
+			cpumask_clear(tmp_mask);
+			err = arm_dt_affine_get_mask(node,
+				"interrupts-affinity", i, tmp_mask);
+			if (err)
+				goto out;
+
+			if (cpumask_weight(tmp_mask) <= 0) {
+				interrupts[i].cpu = -1;
+				continue;
+			}
+
+			cpu = cpumask_first(tmp_mask);
+		}
+
+		interrupts[i].cpu = cpu;
+		cpumask_set_cpu(cpu, &cpu_pmu->armpmu.supported_cpus);
+	}
+
+	cpu_pmu->interrupts = interrupts;
+
+out:
+	free_cpumask_var(tmp_mask);
+	if (err)
+		kfree(interrupts);
+	return err;
+}
+
 static int cpu_pmu_device_probe(struct platform_device *pdev)
 {
 	const struct of_device_id *of_id;
@@ -301,8 +378,11 @@ static int cpu_pmu_device_probe(struct platform_device *pdev)
 		goto out_pmu;
 	}
 
-	/* Assume by default that we're on a homogeneous system */
-	cpumask_setall(&pmu->armpmu.supported_cpus);
+	ret = parse_platdata(pmu, pdev);
+	if (ret) {
+		pr_info("Could not parse irq information\n");
+		goto out_hw;
+	}
 
 	if (node && (of_id = of_match_node(cpu_pmu_of_device_ids, pdev->dev.of_node))) {
 		init_fn = of_id->data;
-- 
1.8.1.1




From mark.rutland at arm.com  Thu Apr 11 05:12:41 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Thu, 11 Apr 2013 10:12:41 +0100
Subject: [RFC PATCH 10/11] arm: perf: allow multiple CPU PMUs to be registered
In-Reply-To: <1365671562-2403-1-git-send-email-mark.rutland@arm.com>
References: <1365671562-2403-1-git-send-email-mark.rutland@arm.com>
Message-ID: <1365671562-2403-11-git-send-email-mark.rutland@arm.com>

In systems with multiple clusters, the CPUs may be different in each
cluster, and their PMUs may not be entirely compatible. As they cannot
be managed as one logical homogeneous unit, we will have to support each
set of compatible PMUs separately. To do so, we need to be able to
register and use multiple PMUs simultaneously.

This patch replaces the global cpu_pmu pointer with a list of cpu_pmus,
enabling multiple PMUs to be registered and used simultaneously.

Signed-off-by: Mark Rutland <mark.rutland at arm.com>
---
 arch/arm/kernel/perf_event_cpu.c | 61 +++++++++++++++++++++++++---------------
 1 file changed, 38 insertions(+), 23 deletions(-)

diff --git a/arch/arm/kernel/perf_event_cpu.c b/arch/arm/kernel/perf_event_cpu.c
index 6d8cbb1..4d6bfbb 100644
--- a/arch/arm/kernel/perf_event_cpu.c
+++ b/arch/arm/kernel/perf_event_cpu.c
@@ -37,7 +37,7 @@ struct cpu_pmu_irq {
 };
 
 /* Set at runtime when we know what CPU type we are. */
-static struct arm_pmu *cpu_pmu;
+static LIST_HEAD(pmus_list);
 
 /*
  * All of the dynamically sized pmu_hw data for the number of events supported
@@ -57,20 +57,28 @@ struct cpu_pmu {
 	struct cpu_pmu_hw __percpu *cpu_hw;
 	struct cpu_pmu_irq *interrupts;
 	int nr_irqs;
+	struct list_head list;
 };
 
 #define to_cpu_pmu(p) (container_of(p, struct cpu_pmu, armpmu))
 
+static void cpu_pmu_add(struct cpu_pmu *pmu)
+{
+	list_add_tail(&pmu->list, &pmus_list);
+}
+
 /*
  * Despite the names, these two functions are CPU-specific and are used
  * by the OProfile/perf code.
  */
 const char *perf_pmu_name(void)
 {
-	if (!cpu_pmu)
+	struct cpu_pmu *pmu = list_first_entry(&pmus_list,
+					       struct cpu_pmu, list);
+	if (!pmu)
 		return NULL;
 
-	return cpu_pmu->name;
+	return pmu->armpmu.name;
 }
 EXPORT_SYMBOL_GPL(perf_pmu_name);
 
@@ -78,8 +86,10 @@ int perf_num_counters(void)
 {
 	int max_events = 0;
 
-	if (cpu_pmu != NULL)
-		max_events = cpu_pmu->num_events;
+	struct cpu_pmu *pmu = list_first_entry(&pmus_list,
+					       struct cpu_pmu, list);
+	if (pmu != NULL)
+		max_events = pmu->armpmu.num_events;
 
 	return max_events;
 }
@@ -186,18 +196,26 @@ static int __cpuinit cpu_pmu_notify(struct notifier_block *b,
 				    unsigned long action, void *hcpu)
 {
 	int cpu = (long)hcpu;
+	int ret = NOTIFY_DONE;
+	struct cpu_pmu *cpu_pmu;
+
 	if ((action & ~CPU_TASKS_FROZEN) != CPU_STARTING)
-		return NOTIFY_DONE;
+		return ret;
 
-	if (!cpumask_test_cpu(cpu, &cpu_pmu->supported_cpus))
-		return NOTIFY_DONE;
+	list_for_each_entry(cpu_pmu, &pmus_list, list) {
+		struct arm_pmu *arm_pmu = &cpu_pmu->armpmu;
 
-	if (cpu_pmu && cpu_pmu->reset)
-		cpu_pmu->reset(cpu_pmu);
-	else
-		return NOTIFY_DONE;
+		if (!arm_pmu->reset)
+			continue;
+
+		if (!cpumask_test_cpu(cpu, &arm_pmu->supported_cpus))
+			continue;
 
-	return NOTIFY_OK;
+		arm_pmu->reset(arm_pmu);
+		ret = NOTIFY_OK;
+	}
+
+	return ret;
 }
 
 static struct notifier_block __cpuinitdata cpu_pmu_hotplug_notifier = {
@@ -360,11 +378,6 @@ static int cpu_pmu_device_probe(struct platform_device *pdev)
 	struct cpu_pmu *pmu;
 	int ret = -ENODEV;
 
-	if (cpu_pmu) {
-		pr_info("attempt to register multiple PMU devices!");
-		return -ENOSPC;
-	}
-
 	pmu = kzalloc(sizeof(*pmu), GFP_KERNEL);
 	if (!pmu) {
 		pr_info("failed to allocate PMU device!");
@@ -396,13 +409,15 @@ static int cpu_pmu_device_probe(struct platform_device *pdev)
 		goto out_hw;
 	}
 
-	cpu_pmu = &pmu->armpmu;
-	cpu_pmu->plat_device = pdev;
+	pmu->armpmu.plat_device = pdev;
 	cpu_pmu_init(pmu);
-	ret = armpmu_register(cpu_pmu, -1);
 
-	if (!ret)
-		return 0;
+	ret = armpmu_register(&pmu->armpmu, -1);
+	if (ret)
+		goto out_hw;
+
+	cpu_pmu_add(pmu);
+	return 0;
 
 out_hw:
 	free_percpu(pmu->cpu_hw);
-- 
1.8.1.1




From mark.rutland at arm.com  Thu Apr 11 05:12:42 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Thu, 11 Apr 2013 10:12:42 +0100
Subject: [RFC PATCH 11/11] arm: dts: add all PMUs for A15x2 A7x3 coretile
In-Reply-To: <1365671562-2403-1-git-send-email-mark.rutland@arm.com>
References: <1365671562-2403-1-git-send-email-mark.rutland@arm.com>
Message-ID: <1365671562-2403-12-git-send-email-mark.rutland@arm.com>

Currently we only describe the A15 PMUs, as previously it was not
possible to describe the A7 PMUs.

This patch adds a cpu-map node and interrupts-affinity information
for the PMUs to the dts, enabling the use of both PMUs. It also
corrects the unit addresses of the cpu nodes, which should match
their reg properties. As the A15 PMU has different events than the
A9 PMU, this patch also removes the "arm,cortex-a9-pmu" compatible
string from the dts.

Signed-off-by: Mark Rutland <mark.rutland at arm.com>
---
 arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts | 44 ++++++++++++++++++++++++++----
 1 file changed, 39 insertions(+), 5 deletions(-)

diff --git a/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts b/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
index dfe371e..4117b1b 100644
--- a/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
+++ b/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
@@ -45,25 +45,47 @@
 			reg = <1>;
 		};
 
-		cpu2: cpu at 2 {
+		cpu2: cpu at 100 {
 			device_type = "cpu";
 			compatible = "arm,cortex-a7";
 			reg = <0x100>;
 		};
 
-		cpu3: cpu at 3 {
+		cpu3: cpu at 101 {
 			device_type = "cpu";
 			compatible = "arm,cortex-a7";
 			reg = <0x101>;
 		};
 
-		cpu4: cpu at 4 {
+		cpu4: cpu at 102 {
 			device_type = "cpu";
 			compatible = "arm,cortex-a7";
 			reg = <0x102>;
 		};
 	};
 
+	cpu-map {
+		cluster0 {
+			core0_0: core0 {
+				cpu = <&cpu0>;
+			};
+			core0_1: core1 {
+				cpu = <&cpu1>;
+			};
+		};
+		cluster1 {
+			core1_0: core0 {
+				cpu = <&cpu2>;
+			};
+			core1_1: core1 {
+				cpu = <&cpu3>;
+			};
+			core1_2: core2 {
+				cpu = <&cpu4>;
+			};
+		};
+	};
+
 	memory at 80000000 {
 		device_type = "memory";
 		reg = <0 0x80000000 0 0x40000000>;
@@ -133,10 +155,22 @@
 			     <1 10 0xf08>;
 	};
 
-	pmu {
-		compatible = "arm,cortex-a15-pmu", "arm,cortex-a9-pmu";
+	pmu_a15s {
+		compatible = "arm,cortex-a15-pmu";
 		interrupts = <0 68 4>,
 			     <0 69 4>;
+		interrupts-affinity = <&core0_0>,
+				      <&core0_1>;
+	};
+
+	pmu_a7s {
+		compatible = "arm,cortex-a7-pmu";
+		interrupts = <0 128 4>,
+			     <0 129 4>,
+			     <0 130 4>;
+		interrupts-affinity = <&core1_0>,
+				      <&core1_1>,
+				      <&core1_2>;
 	};
 
 	oscclk6a: oscclk6a {
-- 
1.8.1.1




From christian.ruppert at abilis.com  Thu Apr 11 05:19:53 2013
From: christian.ruppert at abilis.com (Christian Ruppert)
Date: Thu, 11 Apr 2013 11:19:53 +0200
Subject: [PATCH] clk: Add device tree binding to clk-fixed-factor
In-Reply-To: <20130410162747.GG32603@ab42.lan>
References: <1365608443-30350-1-git-send-email-christian.ruppert@abilis.com>
 <51658BA9.7030508@free-electrons.com>
 <20130410162747.GG32603@ab42.lan>
Message-ID: <20130411091952.GF8400@ab42.lan>

Hi Gregory,

Since there doesn't seem to be anyone opposing this feature I just
checked your patch and after adding the CLK_OF_DECLARE macro in the end
it works well for us. Tell me if you would like to rebase and resubmit
your patch or if I should follow up on our own.

Greetings,
  Christian

On Wed, Apr 10, 2013 at 06:27:47PM +0200, christian ruppert wrote:
> Hi Gregory,
> 
> We use derived clocks with fixed ratios for our TB10x platform. I
> originally had this in the platform code but Vineet (the platform
> maintainer) rightly pointed out that the common clock framework would
> be the correct place for it.
> Is there any reason not to support this functionality? After all, the
> generic fixed rate clock also has a device tree binding and I'd guess
> we're not the only ones statically deriving one clock from another in
> our SOCs.
> 
> Greetings,
>   Christian
> 
> On Wed, Apr 10, 2013 at 05:56:25PM +0200, Gregory CLEMENT wrote:
> > Hi Christian,
> > 
> > On 04/10/2013 05:40 PM, Christian Ruppert wrote:
> > > This patch adds a device tree binding for the simple fixed factor clock
> > > divider/multiplier of the common clock tree binding.
> > 
> > This patch remind me of something :
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2012-August/116405.html
> > 
> > Do you have a use case for it, this time?
> > 
> > My version have been hold off waiting for an user for it.
> > Will you need it for a driver?
> > 
> > Regards,
> > 
> > > 
> > > Signed-off-by: Christian Ruppert <christian.ruppert at abilis.com>
> > > ---
> > >  .../bindings/clock/fixed-factor-clkdiv.txt         |   24 +++++++++++++++
> > >  drivers/clk/clk-fixed-factor.c                     |   32 ++++++++++++++++++++
> > >  include/linux/clk-provider.h                       |    1 +
> > >  3 files changed, 57 insertions(+), 0 deletions(-)
> > >  create mode 100644 Documentation/devicetree/bindings/clock/fixed-factor-clkdiv.txt
> > > 
> > > diff --git a/Documentation/devicetree/bindings/clock/fixed-factor-clkdiv.txt b/Documentation/devicetree/bindings/clock/fixed-factor-clkdiv.txt
> > > new file mode 100644
> > > index 0000000..352bac4
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/clock/fixed-factor-clkdiv.txt
> > > @@ -0,0 +1,24 @@
> > > +Device Tree Clock bindings for plat-tb10x
> > > +
> > > +This binding uses the common clock binding[1].
> > > +
> > > +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
> > > +
> > > +Required properties:
> > > +- compatible : shall be "fixed-factor-clkdiv"
> > > +- #clock-cells: from common clock binding; shall be set to 0
> > > +- clocks: shall be the input parent clock phandle for the clock.
> > > +- clock-mult: defines the multiplication factor of the output clock frequency
> > > +  wrt. the input clock frequency.
> > > +- clock-div: defines the division factor of the output clock frequency wrt.
> > > +  the input clock frequency.
> > > +
> > > +Example:
> > > +cpu_clk: clkdiv_cpu {	/* CPU clock derived from pll0. 1/2 of pll frequency */
> > > +	compatible = "fixed-factor-clkdiv";
> > > +	#clock-cells = <0>;
> > > +	clocks = <&pll0>;
> > > +	clock-mult = <1>;
> > > +	clock-div = <2>;
> > > +	clock-output-names = "cpu_clk";
> > > +};
> > > diff --git a/drivers/clk/clk-fixed-factor.c b/drivers/clk/clk-fixed-factor.c
> > > index 1ef271e..85e45f1 100644
> > > --- a/drivers/clk/clk-fixed-factor.c
> > > +++ b/drivers/clk/clk-fixed-factor.c
> > > @@ -11,6 +11,7 @@
> > >  #include <linux/clk-provider.h>
> > >  #include <linux/slab.h>
> > >  #include <linux/err.h>
> > > +#include <linux/of.h>
> > >  
> > >  /*
> > >   * DOC: basic fixed multiplier and divider clock that cannot gate
> > > @@ -96,3 +97,34 @@ struct clk *clk_register_fixed_factor(struct device *dev, const char *name,
> > >  
> > >  	return clk;
> > >  }
> > > +
> > > +#ifdef CONFIG_OF
> > > +/**
> > > + * of_fixed_factor_clkdiv_setup() - Set up simple fixed factor clock divider
> > > + */
> > > +void of_fixed_factor_clkdiv_setup(struct device_node *node)
> > > +{
> > > +	struct clk *clk;
> > > +	const char *clk_name = node->name;
> > > +	const char *parent_name;
> > > +	u32 mult, div;
> > > +
> > > +	if (of_property_read_u32(node, "clock-mult", &mult))
> > > +		return;
> > > +
> > > +	if (of_property_read_u32(node, "clock-div", &div))
> > > +		return;
> > > +
> > > +	parent_name = of_clk_get_parent_name(node, 0);
> > > +
> > > +	of_property_read_string(node, "clock-output-names", &clk_name);
> > > +
> > > +	clk = clk_register_fixed_factor(NULL, clk_name, parent_name, 0,
> > > +					mult, div);
> > > +	if (!IS_ERR(clk))
> > > +		of_clk_add_provider(node, of_clk_src_simple_get, clk);
> > > +}
> > > +EXPORT_SYMBOL_GPL(of_fixed_factor_clkdiv_setup);
> > > +CLK_OF_DECLARE(fixed_clkdiv, "fixed-factor-clkdiv",
> > > +		of_fixed_factor_clkdiv_setup);
> > > +#endif
> > > diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
> > > index 7f197d7..d4937cf 100644
> > > --- a/include/linux/clk-provider.h
> > > +++ b/include/linux/clk-provider.h
> > > @@ -184,6 +184,7 @@ struct clk *clk_register_fixed_rate(struct device *dev, const char *name,
> > >  		unsigned long fixed_rate);
> > >  
> > >  void of_fixed_clk_setup(struct device_node *np);
> > > +void of_fixed_factor_clkdiv_setup(struct device_node *node);
> > >  
> > >  /**
> > >   * struct clk_gate - gating clock
> > > 
> > 
> > 
> > -- 
> > Gregory Clement, Free Electrons
> > Kernel, drivers, real-time and embedded Linux
> > development, consulting, training and support.
> > http://free-electrons.com
> 
> -- 
>   Christian Ruppert              ,          <christian.ruppert at abilis.com>
>                                 /|
>   Tel: +41/(0)22 816 19-42     //|                 3, Chemin du Pr?-Fleuri
>                              _// | bilis Systems   CH-1228 Plan-les-Ouates

-- 
  Christian Ruppert              ,          <christian.ruppert at abilis.com>
                                /|
  Tel: +41/(0)22 816 19-42     //|                 3, Chemin du Pr?-Fleuri
                             _// | bilis Systems   CH-1228 Plan-les-Ouates


From heiko at sntech.de  Thu Apr 11 05:32:03 2013
From: heiko at sntech.de (Heiko =?iso-8859-1?q?St=FCbner?=)
Date: Thu, 11 Apr 2013 11:32:03 +0200
Subject: [PATCH v2] pinctrl: Add pinctrl-s3c24xx driver
In-Reply-To: <3905101.tGGPWFz8Ff@amdc1227>
References: <201304110116.41525.heiko@sntech.de> <3905101.tGGPWFz8Ff@amdc1227>
Message-ID: <201304111132.05009.heiko@sntech.de>

Am Donnerstag, 11. April 2013, 10:54:45 schrieb Tomasz Figa:
> Hi Heiko,
> 
> As previously, generally looks good to me, but see my comments inline.
> 
> On Thursday 11 of April 2013 01:16:41 Heiko St?bner wrote:
> > The s3c24xx pins follow a similar pattern as the other Samsung SoCs and
> > can therefore reuse the already introduced infrastructure.
> > 
> > The s3c24xx SoCs have one design oddity in that the first 4 external
> > interrupts do not reside in the eint pending register but in the main
> > interrupt controller instead. We solve this by forwarding the external
> > interrupt from the main controller into the irq domain of the pin bank.
> > The masking/acking of these interrupts is handled in the same way.
> > 
> > Furthermore the S3C2412/2413 SoCs contain another oddity in that they
> > keep the same 4 eints in the main interrupt controller and eintpend
> > register and requiring ack operations to happen in both. To solve this
> > a ctrl_type enum is introduced which can keep the type of controller
> 
> Hmm, I think you forgot to edit the commit message, since we decided to
> replace ctrl_type with another compatible string.

One should not do these things after midnight :-) [true for most of the other 
mistakes below too].


> > in the samsung_pin_ctrl struct for later retrieval.
> > 
> > The ctrl_type enum contains only S3C24XX and S3C2412 types, as the
> > eint-speciality is currently the only use-case. But it can be expaned
> > if other SoCs gain special handling requirements later on.
> > 
> > Signed-off-by: Heiko Stuebner <heiko at sntech.de>
> > ---
> > changes since v1:
> > 
> > - address comments from Tomasz Figa:
> >   * split handling functions for eints 0-3 for s3c2412 and all others
> >   * change the handling for s3c2412 eints 0-3 in that they now use
> >   
> >     chained_irq_* for the outer parent interrupt
> 
> OK, so you finally decided to use the way I suggested. Have you managed to
> do some testing on a S3C2412?

Nope, after pondering everything a bit more ... your description just sounded 
more plausible :-) . I only have access to s3c2416 and s3c2450 boards, so 
everything else is just done according to datasheets and in the hope of it 
being correct. S3C2412 is really the only familiy member having the 4 eints in 
both registers.

Also the (reworked) legacy eint code also uses this scheme ... so at least now 
both are either correct or wrong. We will only know if someone with a s3c2412 
comes along at some point :-) .


> >  .../bindings/pinctrl/samsung-pinctrl.txt           |    8 +
> >  drivers/gpio/gpio-samsung.c                        |    4 +
> >  drivers/pinctrl/Kconfig                            |    5 +
> >  drivers/pinctrl/Makefile                           |    1 +
> >  drivers/pinctrl/pinctrl-s3c24xx.c                  |  664
> > 
> > ++++++++++++++++++++ drivers/pinctrl/pinctrl-samsung.c                  |
> > 10 +
> > 
> >  drivers/pinctrl/pinctrl-samsung.h                  |   16 +
> >  7 files changed, 708 insertions(+), 0 deletions(-)
> >  create mode 100644 drivers/pinctrl/pinctrl-s3c24xx.c
> > 
> > diff --git
> > a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
> > b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt index
> > c70fca1..e4443e3 100644
> > --- a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
> > +++ b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
> > @@ -7,6 +7,10 @@ on-chip controllers onto these pads.
> > 
> >  Required Properties:
> >  - compatible: should be one of the following.
> > 
> > +  - "samsung,s3c2413-pinctrl": for S3C64xx-compatible pin-controller,
> > +  - "samsung,s3c2416-pinctrl": for S3C64xx-compatible pin-controller,
> > +  - "samsung,s3c2440-pinctrl": for S3C64xx-compatible pin-controller,
> > +  - "samsung,s3c2450-pinctrl": for S3C64xx-compatible pin-controller,
> > 
> >    - "samsung,s3c64xx-pinctrl": for S3C64xx-compatible pin-controller,
> >    - "samsung,exynos4210-pinctrl": for Exynos4210 compatible
> >    pin-controller.
> > 
> > - "samsung,exynos4x12-pinctrl": for Exynos4x12 compatible pin-controller.
> > @@ -106,6 +110,10 @@ B. External Wakeup Interrupts: For supporting
> > external wakeup interrupts, a
> > 
> >     - compatible: identifies the type of the external wakeup interrupt
> > 
> > controller The possible values are:
> > +     - samsung,s3c2410-wakeup-eint: represents wakeup interrupt
> > controller +       found on Samsung S3C24xx SoCs except S3C2412 and
> > S3C2413, +     - samsung,s3c2412-wakeup-eint: represents wakeup
> > interrupt controller +       found on Samsung S3C2412 and S3C2413 SoCs,
> > 
> >       - samsung,s3c64xx-wakeup-eint: represents wakeup interrupt
> >       controller
> >       
> >         found on Samsung S3C64xx SoCs,
> >       
> >       - samsung,exynos4210-wakeup-eint: represents wakeup interrupt
> > 
> > controller diff --git a/drivers/gpio/gpio-samsung.c
> > b/drivers/gpio/gpio-samsung.c index dc06a6f..73017b9 100644
> > --- a/drivers/gpio/gpio-samsung.c
> > +++ b/drivers/gpio/gpio-samsung.c
> > @@ -3026,6 +3026,10 @@ static __init int samsung_gpiolib_init(void)
> > 
> >  	*/
> >  	struct device_node *pctrl_np;
> >  	static const struct of_device_id exynos_pinctrl_ids[] = {
> > 
> > +		{ .compatible = "samsung,s3c2413-pinctrl", },
> > +		{ .compatible = "samsung,s3c2416-pinctrl", },
> > +		{ .compatible = "samsung,s3c2440-pinctrl", },
> > +		{ .compatible = "samsung,s3c2450-pinctrl", },
> > 
> >  		{ .compatible = "samsung,s3c64xx-pinctrl", },
> >  		{ .compatible = "samsung,exynos4210-pinctrl", },
> >  		{ .compatible = "samsung,exynos4x12-pinctrl", },
> > 
> > diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
> > index 7402ac9..58d73ac 100644
> > --- a/drivers/pinctrl/Kconfig
> > +++ b/drivers/pinctrl/Kconfig
> > @@ -226,6 +226,11 @@ config PINCTRL_EXYNOS5440
> > 
> >  	select PINMUX
> >  	select PINCONF
> > 
> > +config PINCTRL_S3C24XX
> > +	bool "Samsung S3C24XX SoC pinctrl driver"
> > +	depends on ARCH_S3C24XX
> > +	select PINCTRL_SAMSUNG
> > +
> > 
> >  config PINCTRL_S3C64XX
> >  
> >  	bool "Samsung S3C64XX SoC pinctrl driver"
> >  	depends on ARCH_S3C64XX
> > 
> > diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
> > index 21d34c2..1ccdfd8 100644
> > --- a/drivers/pinctrl/Makefile
> > +++ b/drivers/pinctrl/Makefile
> > @@ -45,6 +45,7 @@ obj-$(CONFIG_PINCTRL_COH901)	+= pinctrl-coh901.o
> > 
> >  obj-$(CONFIG_PINCTRL_SAMSUNG)	+= pinctrl-samsung.o
> >  obj-$(CONFIG_PINCTRL_EXYNOS)	+= pinctrl-exynos.o
> >  obj-$(CONFIG_PINCTRL_EXYNOS5440)	+= pinctrl-exynos5440.o
> > 
> > +obj-$(CONFIG_PINCTRL_S3C24XX)	+= pinctrl-s3c24xx.o
> > 
> >  obj-$(CONFIG_PINCTRL_S3C64XX)	+= pinctrl-s3c64xx.o
> >  obj-$(CONFIG_PINCTRL_XWAY)	+= pinctrl-xway.o
> >  obj-$(CONFIG_PINCTRL_LANTIQ)	+= pinctrl-lantiq.o
> > 
> > diff --git a/drivers/pinctrl/pinctrl-s3c24xx.c
> > b/drivers/pinctrl/pinctrl-s3c24xx.c new file mode 100644
> > index 0000000..8dffa2a
> > --- /dev/null
> > +++ b/drivers/pinctrl/pinctrl-s3c24xx.c
> > @@ -0,0 +1,664 @@
> > +/*
> > + * S3C24XX specific support for Samsung pinctrl/gpiolib driver.
> > + *
> > + * Copyright (c) 2013 Heiko Stuebner <heiko at sntech.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.
> > + *
> > + * This file contains the SamsungS3C24XX specific information required
> > by the + * the Samsung pinctrl/gpiolib driver. It also includes the
> > implementation of + * external gpio and wakeup interrupt support. + */
> > +
> > +#include <linux/module.h>
> > +#include <linux/device.h>
> > +#include <linux/interrupt.h>
> > +#include <linux/irqdomain.h>
> > +#include <linux/irq.h>
> > +#include <linux/of_irq.h>
> > +#include <linux/io.h>
> > +#include <linux/slab.h>
> > +#include <linux/err.h>
> > +
> > +#include <asm/mach/irq.h>
> > +
> > +#include "pinctrl-samsung.h"
> > +
> > +#define NUM_EINT	24
> > +#define NUM_EINT_IRQ	6
> > +#define EINT_MAX_PER_GROUP	8
> > +
> > +#define EINTPEND_REG	0xa8
> > +#define EINTMASK_REG	0xa4
> > +
> > +#define EINT_GROUP(i)		((int)((i) / EINT_MAX_PER_GROUP))
> > +#define EINT_REG(i)		((EINT_GROUP(i) * 4) + 0x88)
> > +#define EINT_OFFS(i)		((i) % EINT_MAX_PER_GROUP * 4)
> > +
> > +#define EINT_LEVEL_LOW		0
> > +#define EINT_LEVEL_HIGH		1
> > +#define EINT_EDGE_FALLING	2
> > +#define EINT_EDGE_RISING	4
> > +#define EINT_EDGE_BOTH		6
> > +#define EINT_MASK		0xf
> > +
> > +static struct samsung_pin_bank_type bank_type_1bit = {
> > +	.fld_width = { 1, 1, },
> > +	.reg_offset = { 0x00, 0x04, },
> > +};
> > +
> > +static struct samsung_pin_bank_type bank_type_2bit = {
> > +	.fld_width = { 2, 1, 2, },
> > +	.reg_offset = { 0x00, 0x04, 0x08, },
> > +};
> > +
> > +#define PIN_BANK_A(pins, reg, id)		\
> > +	{						\
> > +		.type		= &bank_type_1bit,	\
> > +		.pctl_offset	= reg,			\
> > +		.nr_pins	= pins,			\
> > +		.eint_type	= EINT_TYPE_NONE,	\
> > +		.name		= id			\
> > +	}
> > +
> > +#define PIN_BANK_2BIT(pins, reg, id)		\
> > +	{						\
> > +		.type		= &bank_type_2bit,	\
> > +		.pctl_offset	= reg,			\
> > +		.nr_pins	= pins,			\
> > +		.eint_type	= EINT_TYPE_NONE,	\
> > +		.name		= id			\
> > +	}
> > +
> > +#define PIN_BANK_2BIT_EINTW(pins, reg, id, eoffs, emask)\
> > +	{						\
> > +		.type		= &bank_type_2bit,	\
> > +		.pctl_offset	= reg,			\
> > +		.nr_pins	= pins,			\
> > +		.eint_type	= EINT_TYPE_WKUP,	\
> > +		.eint_func	= 2,			\
> > +		.eint_mask	= emask,		\
> > +		.eint_offset	= eoffs,		\
> > +		.name		= id			\
> > +	}
> > +
> > +/**
> > + * struct s3c24xx_eint_data: EINT common data
> > + * @drvdata: pin controller driver data
> > + * @domains: IRQ domains of particular EINT interrupts
> 
> @parents:

ok

> > + */
> > +struct s3c24xx_eint_data {
> > +	struct samsung_pinctrl_drv_data *drvdata;
> > +	struct irq_domain *domains[NUM_EINT];
> > +	int parents[NUM_EINT_IRQ];
> > +};
> > +
> 
> I wonder if this struct should be documented as well.

ok

> > +struct s3c24xx_eint_domain_data {
> > +	struct samsung_pin_bank *bank;
> > +	struct s3c24xx_eint_data *eint_data;
> > +	bool eint0_3_parent_only;
> > +};
> > +
> > +static int s3c24xx_eint_get_trigger(unsigned int type)
> > +{
> > +	int trigger;
> > +
> > +	switch (type) {
> > +	case IRQ_TYPE_EDGE_RISING:
> > +		trigger = EINT_EDGE_RISING;
> > +		break;
> > +	case IRQ_TYPE_EDGE_FALLING:
> > +		trigger = EINT_EDGE_FALLING;
> > +		break;
> > +	case IRQ_TYPE_EDGE_BOTH:
> > +		trigger = EINT_EDGE_BOTH;
> > +		break;
> > +	case IRQ_TYPE_LEVEL_HIGH:
> > +		trigger = EINT_LEVEL_HIGH;
> > +		break;
> > +	case IRQ_TYPE_LEVEL_LOW:
> > +		trigger = EINT_LEVEL_LOW;
> > +		break;
> > +	default:
> > +		return -EINVAL;
> > +	}
> > +
> > +	return trigger;
> > +}
> > +
> > +static void s3c24xx_eint_set_handler(unsigned int irq, unsigned int
> > type) +{
> > +	/* Edge- and level-triggered interrupts need different handlers */
> > +	if (type & IRQ_TYPE_EDGE_BOTH)
> > +		__irq_set_handler_locked(irq, handle_edge_irq);
> > +	else
> > +		__irq_set_handler_locked(irq, handle_level_irq);
> > +}
> > +
> > +static void s3c24xx_eint_set_function(struct samsung_pinctrl_drv_data
> > *d, +					struct samsung_pin_bank *bank, int pin)
> > +{
> > +	struct samsung_pin_bank_type *bank_type = bank->type;
> > +	unsigned long flags;
> > +	void __iomem *reg;
> > +	u8 shift;
> > +	u32 mask;
> > +	u32 val;
> > +
> > +	/* Make sure that pin is configured as interrupt */
> > +	reg = d->virt_base + bank->pctl_offset;
> > +	shift = pin * bank_type->fld_width[PINCFG_TYPE_FUNC];
> > +	mask = (1 << bank_type->fld_width[PINCFG_TYPE_FUNC]) - 1;
> > +
> > +	spin_lock_irqsave(&bank->slock, flags);
> > +
> > +	val = readl(reg);
> > +	val &= ~(mask << shift);
> > +	val |= bank->eint_func << shift;
> > +	writel(val, reg);
> > +
> > +	spin_unlock_irqrestore(&bank->slock, flags);
> > +}
> > +
> > +static int s3c24xx_eint_type(struct irq_data *data, unsigned int type)
> > +{
> > +	struct samsung_pin_bank *bank = irq_data_get_irq_chip_data(data);
> > +	struct samsung_pinctrl_drv_data *d = bank->drvdata;
> > +	int index = bank->eint_offset + data->hwirq;
> > +	void __iomem *reg;
> > +	int trigger;
> > +	u8 shift;
> > +	u32 val;
> > +
> > +	trigger = s3c24xx_eint_get_trigger(type);
> > +	if (trigger < 0) {
> > +		dev_err(d->dev, "unsupported external interrupt type\n");
> > +		return -EINVAL;
> > +	}
> > +
> > +	s3c24xx_eint_set_handler(data->irq, type);
> > +
> > +	/* Set up interrupt trigger */
> > +	reg = d->virt_base + EINT_REG(index);
> > +	shift = EINT_OFFS(index);
> > +
> > +	val = readl(reg);
> > +	val &= ~(EINT_MASK << shift);
> > +	val |= trigger << shift;
> > +	writel(val, reg);
> > +
> > +	s3c24xx_eint_set_function(d, bank, data->hwirq);
> > +
> > +	return 0;
> > +}
> > +
> > +/* handling of EINTs 0-3 on all except S3C2412 and S3C2413 */
> > +
> > +static void s3c2410_eint0_3_ack(struct irq_data *data)
> > +{
> > +	struct samsung_pin_bank *bank = irq_data_get_irq_chip_data(data);
> > +	struct s3c24xx_eint_domain_data *ddata = bank->irq_domain->host_data;
> > +	struct s3c24xx_eint_data *eint_data = ddata->eint_data;
> > +	int parent_irq = eint_data->parents[data->hwirq];
> > +	struct irq_chip *parent_chip = irq_get_chip(parent_irq);
> > +
> > +	if (likely(parent_chip))
> 
> Hmm, is it possible that there is no parent chip here?

hmm ... irq_get_chip is null when irq_get_data fails. But when we reach these 
ack/mask/unmask functions, the demux of the parent irq already has retrieved 
the irq_data sucessfully once ... so they can go away

 
> > +		parent_chip->irq_ack(irq_get_irq_data(parent_irq));
> > +}
> > +
> > +static void s3c2410_eint0_3_mask(struct irq_data *data)
> > +{
> > +	struct samsung_pin_bank *bank = irq_data_get_irq_chip_data(data);
> > +	struct s3c24xx_eint_domain_data *ddata = bank->irq_domain->host_data;
> > +	struct s3c24xx_eint_data *eint_data = ddata->eint_data;
> > +	int parent_irq = eint_data->parents[data->hwirq];
> > +	struct irq_chip *parent_chip = irq_get_chip(parent_irq);
> > +
> > +	if (likely(parent_chip))
> 
> Ditto.
> 
> > +		parent_chip->irq_mask(irq_get_irq_data(parent_irq));
> > +}
> > +
> > +static void s3c2410_eint0_3_unmask(struct irq_data *data)
> > +{
> > +	struct samsung_pin_bank *bank = irq_data_get_irq_chip_data(data);
> > +	struct s3c24xx_eint_domain_data *ddata = bank->irq_domain->host_data;
> > +	struct s3c24xx_eint_data *eint_data = ddata->eint_data;
> > +	int parent_irq = eint_data->parents[data->hwirq];
> > +	struct irq_chip *parent_chip = irq_get_chip(parent_irq);
> > +
> > +	if (likely(parent_chip))
> 
> Ditto.
> 
> > +		parent_chip->irq_unmask(irq_get_irq_data(parent_irq));
> > +}
> > +
> > +static struct irq_chip s3c2410_eint0_3_chip = {
> > +	.name		= "s3c2410-eint0_3",
> > +	.irq_ack	= s3c2410_eint0_3_ack,
> > +	.irq_mask	= s3c2410_eint0_3_mask,
> > +	.irq_unmask	= s3c2410_eint0_3_unmask,
> > +	.irq_set_type	= s3c24xx_eint_type,
> > +};
> > +
> > +static void s3c2410_demux_eint0_3(unsigned int irq, struct irq_desc
> > *desc) +{
> > +	struct irq_data *data = irq_desc_get_irq_data(desc);
> > +	struct s3c24xx_eint_data *eint_data = irq_get_handler_data(irq);
> > +	unsigned int virq;
> > +
> > +	/* the first 4 eints have a simple 1 to 1 mapping */
> > +	virq = irq_linear_revmap(eint_data->domains[data->hwirq], data-
>hwirq);
> > +	/* Something must be really wrong if an unmapped EINT
> > +	 * was unmasked...
> > +	 */
> > +	BUG_ON(!virq);
> > +
> > +	generic_handle_irq(virq);
> > +}
> > +
> > +/* handling of EINTs 0-3 on S3C2412 and S3C2413 */
> > +
> > +static void s3c2412_eint0_3_ack(struct irq_data *data)
> > +{
> > +	struct samsung_pin_bank *bank = irq_data_get_irq_chip_data(data);
> > +	struct samsung_pinctrl_drv_data *d = bank->drvdata;
> > +
> > +	unsigned long bitval = 1UL << data->hwirq;
> > +	writel(bitval, d->virt_base + EINTPEND_REG);
> > +}
> > +
> > +static void s3c2412_eint0_3_mask(struct irq_data *data)
> > +{
> > +	struct samsung_pin_bank *bank = irq_data_get_irq_chip_data(data);
> > +	struct samsung_pinctrl_drv_data *d = bank->drvdata;
> > +	unsigned long mask;
> > +
> > +	mask = readl(d->virt_base + EINTMASK_REG);
> > +	mask |= (1UL << data->hwirq);
> > +	writel(mask, d->virt_base + EINTMASK_REG);
> > +}
> > +
> > +static void s3c2412_eint0_3_unmask(struct irq_data *data)
> > +{
> > +	struct samsung_pin_bank *bank = irq_data_get_irq_chip_data(data);
> > +	struct samsung_pinctrl_drv_data *d = bank->drvdata;
> > +	unsigned long mask;
> > +
> > +	mask = readl(d->virt_base + EINTMASK_REG);
> > +	mask &= ~(1UL << data->hwirq);
> > +	writel(mask, d->virt_base + EINTMASK_REG);
> > +}
> > +
> > +static struct irq_chip s3c2412_eint0_3_chip = {
> > +	.name		= "s3c2412-eint0_3",
> > +	.irq_ack	= s3c2412_eint0_3_ack,
> > +	.irq_mask	= s3c2412_eint0_3_mask,
> > +	.irq_unmask	= s3c2412_eint0_3_unmask,
> > +	.irq_set_type	= s3c24xx_eint_type,
> > +};
> > +
> > +static void s3c2412_demux_eint0_3(unsigned int irq, struct irq_desc
> > *desc) +{
> > +	struct irq_chip *chip = irq_get_chip(irq);
> > +	struct irq_data *data = irq_desc_get_irq_data(desc);
> > +	struct s3c24xx_eint_data *eint_data = irq_get_handler_data(irq);
> > +	unsigned int virq;
> > +
> > +	chained_irq_enter(chip, desc);
> > +
> > +	/* the first 4 eints have a simple 1 to 1 mapping */
> > +	virq = irq_linear_revmap(eint_data->domains[data->hwirq], data-
>hwirq);
> > +	/* Something must be really wrong if an unmapped EINT
> > +	 * was unmasked...
> > +	 */
> > +	BUG_ON(!virq);
> > +
> > +	generic_handle_irq(virq);
> > +
> > +	chained_irq_exit(chip, desc);
> > +}
> > +
> > +/* handling of all other eints */
> > +
> > +static void s3c24xx_eint_ack(struct irq_data *data)
> > +{
> > +	struct samsung_pin_bank *bank = irq_data_get_irq_chip_data(data);
> > +	struct samsung_pinctrl_drv_data *d = bank->drvdata;
> > +	unsigned char index = bank->eint_offset + data->hwirq;
> > +
> > +	writel(1UL << index, d->virt_base + EINTPEND_REG);
> > +}
> > +
> > +static void s3c24xx_eint_mask(struct irq_data *data)
> > +{
> > +	struct samsung_pin_bank *bank = irq_data_get_irq_chip_data(data);
> > +	struct samsung_pinctrl_drv_data *d = bank->drvdata;
> > +	unsigned char index = bank->eint_offset + data->hwirq;
> > +	unsigned long mask;
> > +
> > +	mask = readl(d->virt_base + EINTMASK_REG);
> > +	mask |= (1UL << index);
> > +	writel(mask, d->virt_base + EINTMASK_REG);
> > +}
> > +
> > +static void s3c24xx_eint_unmask(struct irq_data *data)
> > +{
> > +	struct samsung_pin_bank *bank = irq_data_get_irq_chip_data(data);
> > +	struct samsung_pinctrl_drv_data *d = bank->drvdata;
> > +	unsigned char index = bank->eint_offset + data->hwirq;
> > +	unsigned long mask;
> > +
> > +	mask = readl(d->virt_base + EINTMASK_REG);
> > +	mask &= ~(1UL << index);
> > +	writel(mask, d->virt_base + EINTMASK_REG);
> > +}
> > +
> > +static struct irq_chip s3c24xx_eint_chip = {
> > +	.name		= "s3c-eint",
> > +	.irq_ack	= s3c24xx_eint_ack,
> > +	.irq_mask	= s3c24xx_eint_mask,
> > +	.irq_unmask	= s3c24xx_eint_unmask,
> > +	.irq_set_type	= s3c24xx_eint_type,
> > +};
> > +
> > +static inline void s3c24xx_demux_eint(unsigned int irq, struct irq_desc
> > *desc, +				      u32 offset, u32 range)
> > +{
> > +	struct irq_chip *chip = irq_get_chip(irq);
> > +	struct s3c24xx_eint_data *data = irq_get_handler_data(irq);
> > +	struct samsung_pinctrl_drv_data *d = data->drvdata;
> > +	unsigned int pend, mask;
> > +
> > +	chained_irq_enter(chip, desc);
> > +
> > +	pend = readl(d->virt_base + EINTPEND_REG);
> > +	mask = readl(d->virt_base + EINTMASK_REG);
> > +
> > +	pend &= ~mask;
> > +	pend &= range;
> > +
> > +	while (pend) {
> > +		unsigned int virq;
> > +
> > +		irq = __ffs(pend);
> > +		pend &= ~(1 << irq);
> > +		virq = irq_linear_revmap(data->domains[irq], irq - offset);
> > +		/* Something must be really wrong if an unmapped EINT
> > +		 * was unmasked...
> > +		 */
> > +		BUG_ON(!virq);
> > +
> > +		generic_handle_irq(virq);
> > +	}
> > +
> > +	chained_irq_exit(chip, desc);
> > +}
> > +
> > +static void s3c24xx_demux_eint4_7(unsigned int irq, struct irq_desc
> > *desc) +{
> > +	s3c24xx_demux_eint(irq, desc, 0, 0xf0);
> > +}
> > +
> > +static void s3c24xx_demux_eint8_23(unsigned int irq, struct irq_desc
> > *desc) +{
> > +	s3c24xx_demux_eint(irq, desc, 8, 0xffff00);
> > +}
> > +
> > +static irq_flow_handler_t s3c2410_eint_handlers[NUM_EINT_IRQ] = {
> > +	s3c2410_demux_eint0_3,
> > +	s3c2410_demux_eint0_3,
> > +	s3c2410_demux_eint0_3,
> > +	s3c2410_demux_eint0_3,
> > +	s3c24xx_demux_eint4_7,
> > +	s3c24xx_demux_eint8_23,
> > +};
> > +
> > +static irq_flow_handler_t s3c2412_eint_handlers[NUM_EINT_IRQ] = {
> > +	s3c2412_demux_eint0_3,
> > +	s3c2412_demux_eint0_3,
> > +	s3c2412_demux_eint0_3,
> > +	s3c2412_demux_eint0_3,
> > +	s3c24xx_demux_eint4_7,
> > +	s3c24xx_demux_eint8_23,
> > +};
> > +
> > +static int s3c24xx_gpf_irq_map(struct irq_domain *h, unsigned int virq,
> > +					irq_hw_number_t hw)
> > +{
> > +	struct s3c24xx_eint_domain_data *ddata = h->host_data;
> > +	struct samsung_pin_bank *bank = ddata->bank;
> > +
> > +	if (!(bank->eint_mask & (1 << (bank->eint_offset + hw))))
> > +		return -EINVAL;
> > +
> > +	if (hw <= 3) {
> > +		if (ddata->eint0_3_parent_only)
> > +			irq_set_chip_and_handler(virq, &s3c2410_eint0_3_chip,
> > +						 handle_edge_irq);
> > +		else
> > +			irq_set_chip_and_handler(virq, &s3c2412_eint0_3_chip,
> > +						 handle_edge_irq);
> > +	} else {
> > +		irq_set_chip_and_handler(virq, &s3c24xx_eint_chip,
> > +					 handle_edge_irq);
> > +	}
> > +	irq_set_chip_data(virq, bank);
> > +	set_irq_flags(virq, IRQF_VALID);
> > +	return 0;
> > +}
> > +
> > +static const struct irq_domain_ops s3c24xx_gpf_irq_ops = {
> > +	.map	= s3c24xx_gpf_irq_map,
> > +	.xlate	= irq_domain_xlate_twocell,
> > +};
> > +
> > +static int s3c24xx_gpg_irq_map(struct irq_domain *h, unsigned int virq,
> > +					irq_hw_number_t hw)
> > +{
> > +	struct s3c24xx_eint_domain_data *ddata = h->host_data;
> > +	struct samsung_pin_bank *bank = ddata->bank;
> > +
> > +	if (!(bank->eint_mask & (1 << (bank->eint_offset + hw))))
> > +		return -EINVAL;
> > +
> > +	irq_set_chip_and_handler(virq, &s3c24xx_eint_chip, handle_edge_irq);
> > +	irq_set_chip_data(virq, bank);
> > +	set_irq_flags(virq, IRQF_VALID);
> > +	return 0;
> > +}
> > +
> > +static const struct irq_domain_ops s3c24xx_gpg_irq_ops = {
> > +	.map	= s3c24xx_gpg_irq_map,
> > +	.xlate	= irq_domain_xlate_twocell,
> > +};
> > +
> > +static const struct of_device_id s3c24xx_eint_irq_ids[] = {
> > +	{ .compatible = "samsung,s3c2410-wakeup-eint", .data = (void *)1 },
> > +	{ .compatible = "samsung,s3c2412-wakeup-eint", .data = (void *)0 },
> > +	{ }
> > +};
> > +
> > +static int s3c24xx_eint_init(struct samsung_pinctrl_drv_data *d)
> > +{
> > +	struct device *dev = d->dev;
> > +	const struct of_device_id *match;
> > +	struct device_node *eint_np = NULL;
> > +	struct device_node *np;
> > +	struct samsung_pin_bank *bank;
> > +	struct s3c24xx_eint_data *eint_data;
> > +	const struct irq_domain_ops *ops;
> > +	unsigned int i;
> > +	bool eint0_3_parent_only;
> > +	irq_flow_handler_t *handlers;
> > +
> > +	for_each_child_of_node(dev->of_node, np) {
> > +		match = of_match_node(s3c24xx_eint_irq_ids, np);
> > +		if (match) {
> > +			eint_np = np;
> > +			eint0_3_parent_only = (bool)match->data;
> > +			break;
> > +		}
> > +	}
> > +	if (!eint_np)
> > +		return -ENODEV;
> > +
> > +	eint_data = devm_kzalloc(dev, sizeof(*eint_data), GFP_KERNEL);
> > +	if (!eint_data) {
> > +		dev_err(dev, "could not allocate memory for wkup eint data\n");
> > +		return -ENOMEM;
> > +	}
> > +	eint_data->drvdata = d;
> > +
> > +	handlers = eint0_3_parent_only ? s3c2410_eint_handlers
> > +				       : s3c2412_eint_handlers;
> > +	for (i = 0; i < NUM_EINT_IRQ; ++i) {
> > +		unsigned int irq;
> > +
> > +		irq = irq_of_parse_and_map(eint_np, i);
> > +		if (!irq) {
> > +			dev_err(dev, "failed to get wakeup EINT IRQ %d\n", i);
> > +			return -ENXIO;
> > +		}
> > +
> > +		eint_data->parents[i] = irq;
> > +		irq_set_chained_handler(irq, handlers[i]);
> > +		irq_set_handler_data(irq, eint_data);
> > +	}
> > +
> > +	bank = d->ctrl->pin_banks;
> > +	for (i = 0; i < d->ctrl->nr_banks; ++i, ++bank) {
> > +		struct s3c24xx_eint_domain_data *ddata;
> > +		unsigned int mask;
> > +		unsigned int irq;
> > +		unsigned int pin;
> > +
> > +		if (bank->eint_type != EINT_TYPE_WKUP)
> > +			continue;
> > +
> > +		ddata = devm_kzalloc(dev, sizeof(*ddata), GFP_KERNEL);
> > +		if (!ddata) {
> > +			dev_err(dev, "failed to allocate domain data\n");
> > +			return -ENOMEM;
> > +		}
> > +		ddata->bank = bank;
> > +		ddata->eint_data = eint_data;
> > +		ddata->eint0_3_parent_only = eint0_3_parent_only;
> > +
> > +		ops = (bank->eint_offset == 0) ? &s3c24xx_gpf_irq_ops
> > +					       : &s3c24xx_gpg_irq_ops;
> > +
> > +		bank->irq_domain = irq_domain_add_linear(bank->of_node,
> > +				bank->nr_pins, ops, ddata);
> > +		if (!bank->irq_domain) {
> > +			dev_err(dev, "wkup irq domain add failed\n");
> > +			return -ENXIO;
> > +		}
> > +
> > +		irq = bank->eint_offset;
> > +		mask = bank->eint_mask;
> > +		for (pin = 0; mask; ++pin, mask >>= 1) {
> > +			if (irq > NUM_EINT)
> > +				break;
> > +			if (!(mask & 1))
> > +				continue;
> > +			eint_data->domains[irq] = bank->irq_domain;
> > +			++irq;
> > +		}
> > +	}
> > +
> > +	return 0;
> > +}
> > +
> > +static struct samsung_pin_bank s3c2413_pin_banks[] = {
> > +	PIN_BANK_A(23, 0x000, "gpa"),
> > +	PIN_BANK_2BIT(11, 0x010, "gpb"),
> > +	PIN_BANK_2BIT(16, 0x020, "gpc"),
> > +	PIN_BANK_2BIT(16, 0x030, "gpd"),
> > +	PIN_BANK_2BIT(16, 0x040, "gpe"),
> > +	PIN_BANK_2BIT_EINTW(8, 0x050, "gpf", 0, 0xff),
> > +	PIN_BANK_2BIT_EINTW(16, 0x060, "gpg", 8, 0xffff00),
> > +	PIN_BANK_2BIT(11, 0x070, "gph"),
> > +	PIN_BANK_2BIT(13, 0x080, "gpj"),
> > +};
> > +
> > +struct samsung_pin_ctrl s3c2413_pin_ctrl[] = {
> > +	{
> > +		.pin_banks	= s3c2413_pin_banks,
> > +		.nr_banks	= ARRAY_SIZE(s3c2413_pin_banks),
> > +		.eint_wkup_init = s3c24xx_eint_init,
> > +		.label		= "S3C2413-GPIO",
> > +		.type		= S3C2412,
> 
> This should be removed as well, shouldn't it?

yes of course

> > +	},
> > +};
> > +
> > +static struct samsung_pin_bank s3c2416_pin_banks[] = {
> > +	PIN_BANK_A(27, 0x000, "gpa"),
> > +	PIN_BANK_2BIT(11, 0x010, "gpb"),
> > +	PIN_BANK_2BIT(16, 0x020, "gpc"),
> > +	PIN_BANK_2BIT(16, 0x030, "gpd"),
> > +	PIN_BANK_2BIT(16, 0x040, "gpe"),
> > +	PIN_BANK_2BIT_EINTW(8, 0x050, "gpf", 0, 0xff),
> > +	PIN_BANK_2BIT_EINTW(8, 0x060, "gpg", 8, 0xff00),
> > +	PIN_BANK_2BIT(15, 0x070, "gph"),
> > +	PIN_BANK_2BIT(16, 0x0e0, "gpk"),
> > +	PIN_BANK_2BIT(14, 0x0f0, "gpl"),
> > +	PIN_BANK_2BIT(2, 0x100, "gpm"),
> > +};
> > +
> > +struct samsung_pin_ctrl s3c2416_pin_ctrl[] = {
> > +	{
> > +		.pin_banks	= s3c2416_pin_banks,
> > +		.nr_banks	= ARRAY_SIZE(s3c2416_pin_banks),
> > +		.eint_wkup_init = s3c24xx_eint_init,
> > +		.label		= "S3C2416-GPIO",
> > +		.type		= S3C24XX,
> 
> Ditto.
> 
> > +	},
> > +};
> > +
> > +static struct samsung_pin_bank s3c2440_pin_banks[] = {
> > +	PIN_BANK_A(25, 0x000, "gpa"),
> > +	PIN_BANK_2BIT(11, 0x010, "gpb"),
> > +	PIN_BANK_2BIT(16, 0x020, "gpc"),
> > +	PIN_BANK_2BIT(16, 0x030, "gpd"),
> > +	PIN_BANK_2BIT(16, 0x040, "gpe"),
> > +	PIN_BANK_2BIT_EINTW(8, 0x050, "gpf", 0, 0xff),
> > +	PIN_BANK_2BIT_EINTW(16, 0x060, "gpg", 8, 0xffff00),
> > +	PIN_BANK_2BIT(11, 0x070, "gph"),
> > +	PIN_BANK_2BIT(13, 0x0d0, "gpj"),
> > +};
> > +
> > +struct samsung_pin_ctrl s3c2440_pin_ctrl[] = {
> > +	{
> > +		.pin_banks	= s3c2440_pin_banks,
> > +		.nr_banks	= ARRAY_SIZE(s3c2440_pin_banks),
> > +		.eint_wkup_init = s3c24xx_eint_init,
> > +		.label		= "S3C2440-GPIO",
> > +		.type		= S3C24XX,
> 
> Ditto.
> 
> > +	},
> > +};
> > +
> > +static struct samsung_pin_bank s3c2450_pin_banks[] = {
> > +	PIN_BANK_A(28, 0x000, "gpa"),
> > +	PIN_BANK_2BIT(11, 0x010, "gpb"),
> > +	PIN_BANK_2BIT(16, 0x020, "gpc"),
> > +	PIN_BANK_2BIT(16, 0x030, "gpd"),
> > +	PIN_BANK_2BIT(16, 0x040, "gpe"),
> > +	PIN_BANK_2BIT_EINTW(8, 0x050, "gpf", 0, 0xff),
> > +	PIN_BANK_2BIT_EINTW(16, 0x060, "gpg", 8, 0xffff00),
> > +	PIN_BANK_2BIT(15, 0x070, "gph"),
> > +	PIN_BANK_2BIT(16, 0x0d0, "gpj"),
> > +	PIN_BANK_2BIT(16, 0x0e0, "gpk"),
> > +	PIN_BANK_2BIT(15, 0x0f0, "gpl"),
> > +	PIN_BANK_2BIT(2, 0x100, "gpm"),
> > +};
> > +
> > +struct samsung_pin_ctrl s3c2450_pin_ctrl[] = {
> > +	{
> > +		.pin_banks	= s3c2450_pin_banks,
> > +		.nr_banks	= ARRAY_SIZE(s3c2450_pin_banks),
> > +		.eint_wkup_init = s3c24xx_eint_init,
> > +		.label		= "S3C2450-GPIO",
> > +		.type		= S3C24XX,
> 
> Ditto.
> 
> > +	},
> > +};
> > diff --git a/drivers/pinctrl/pinctrl-samsung.c
> > b/drivers/pinctrl/pinctrl-samsung.c index e836135..234c32f 100644
> > --- a/drivers/pinctrl/pinctrl-samsung.c
> > +++ b/drivers/pinctrl/pinctrl-samsung.c
> > @@ -977,6 +977,16 @@ static const struct of_device_id
> > samsung_pinctrl_dt_match[] = { { .compatible = "samsung,s3c64xx-pinctrl",
> > 
> >  		.data = s3c64xx_pin_ctrl },
> >  
> >  #endif
> > 
> > +#ifdef CONFIG_PINCTRL_S3C24XX
> > +	{ .compatible = "samsung,s3c2413-pinctrl",
> > +		.data = s3c2413_pin_ctrl },
> > +	{ .compatible = "samsung,s3c2416-pinctrl",
> > +		.data = s3c2416_pin_ctrl },
> > +	{ .compatible = "samsung,s3c2440-pinctrl",
> > +		.data = s3c2440_pin_ctrl },
> > +	{ .compatible = "samsung,s3c2450-pinctrl",
> > +		.data = s3c2450_pin_ctrl },
> > +#endif
> > 
> >  	{},
> >  
> >  };
> >  MODULE_DEVICE_TABLE(of, samsung_pinctrl_dt_match);
> > 
> > diff --git a/drivers/pinctrl/pinctrl-samsung.h
> > b/drivers/pinctrl/pinctrl-samsung.h index 7c7f9eb..8bd317c 100644
> > --- a/drivers/pinctrl/pinctrl-samsung.h
> > +++ b/drivers/pinctrl/pinctrl-samsung.h
> > @@ -81,6 +81,16 @@ enum eint_type {
> > 
> >  	EINT_TYPE_WKUP_MUX,
> >  
> >  };
> > 
> > +/**
> > + * enum ctrl_type - variances of a pin controller type
> > + * @S3C24XX: generic s3c24xx pin handling
> > + * @S3C2412: s3c2412-type eints, existing in the main and eint
> > controllers + */
> > +enum ctrl_type {
> > +	S3C24XX,
> > +	S3C2412,
> > +};
> 
> Diito.
> 
> > +
> > 
> >  /* maximum length of a pin in pin descriptor (example: "gpa0-0") */
> >  #define PIN_NAME_LENGTH	10
> > 
> > @@ -164,6 +174,7 @@ struct samsung_pin_bank {
> > 
> >   * @eint_wkup_init: platform specific callback to setup the external
> >   wakeup
> > 
> > *	interrupts for the controller.
> > 
> >   * @label: for debug information.
> > 
> > + * @type: type of pin-controller
> > 
> >   */
> >  
> >  struct samsung_pin_ctrl {
> >  
> >  	struct samsung_pin_bank	*pin_banks;
> > 
> > @@ -185,6 +196,7 @@ struct samsung_pin_ctrl {
> > 
> >  	int		(*eint_gpio_init)(struct samsung_pinctrl_drv_data *);
> >  	int		(*eint_wkup_init)(struct samsung_pinctrl_drv_data *);
> >  	char		*label;
> > 
> > +	enum ctrl_type	type;
> 
> Ditto.
> 
> Best regards,
> --
> Tomasz Figa
> Samsung Poland R&D Center
> SW Solution Development, Kernel and System Framework
> 
> >  };
> >  
> >  /**
> > 
> > @@ -246,5 +258,9 @@ extern struct samsung_pin_ctrl exynos4210_pin_ctrl[];
> > 
> >  extern struct samsung_pin_ctrl exynos4x12_pin_ctrl[];
> >  extern struct samsung_pin_ctrl exynos5250_pin_ctrl[];
> >  extern struct samsung_pin_ctrl s3c64xx_pin_ctrl[];
> > 
> > +extern struct samsung_pin_ctrl s3c2413_pin_ctrl[];
> > +extern struct samsung_pin_ctrl s3c2416_pin_ctrl[];
> > +extern struct samsung_pin_ctrl s3c2440_pin_ctrl[];
> > +extern struct samsung_pin_ctrl s3c2450_pin_ctrl[];
> > 
> >  #endif /* __PINCTRL_SAMSUNG_H */



From t.figa at samsung.com  Thu Apr 11 05:43:19 2013
From: t.figa at samsung.com (Tomasz Figa)
Date: Thu, 11 Apr 2013 11:43:19 +0200
Subject: [PATCH v2] pinctrl: Add pinctrl-s3c24xx driver
In-Reply-To: <201304111132.05009.heiko@sntech.de>
References: <201304110116.41525.heiko@sntech.de> <3905101.tGGPWFz8Ff@amdc1227>
 <201304111132.05009.heiko@sntech.de>
Message-ID: <3973166.f1dd7C8GWR@amdc1227>

On Thursday 11 of April 2013 11:32:03 Heiko St?bner wrote:
> Am Donnerstag, 11. April 2013, 10:54:45 schrieb Tomasz Figa:
> > Hi Heiko,
> > 
> > As previously, generally looks good to me, but see my comments inline.
> > 
> > On Thursday 11 of April 2013 01:16:41 Heiko St?bner wrote:
> > > The s3c24xx pins follow a similar pattern as the other Samsung SoCs and
> > > can therefore reuse the already introduced infrastructure.
> > > 
> > > The s3c24xx SoCs have one design oddity in that the first 4 external
> > > interrupts do not reside in the eint pending register but in the main
> > > interrupt controller instead. We solve this by forwarding the external
> > > interrupt from the main controller into the irq domain of the pin bank.
> > > The masking/acking of these interrupts is handled in the same way.
> > > 
> > > Furthermore the S3C2412/2413 SoCs contain another oddity in that they
> > > keep the same 4 eints in the main interrupt controller and eintpend
> > > register and requiring ack operations to happen in both. To solve this
> > > a ctrl_type enum is introduced which can keep the type of controller
> > 
> > Hmm, I think you forgot to edit the commit message, since we decided to
> > replace ctrl_type with another compatible string.
> 
> One should not do these things after midnight :-) [true for most of the
> other mistakes below too].
> 
> > > in the samsung_pin_ctrl struct for later retrieval.
> > > 
> > > The ctrl_type enum contains only S3C24XX and S3C2412 types, as the
> > > eint-speciality is currently the only use-case. But it can be expaned
> > > if other SoCs gain special handling requirements later on.
> > > 
> > > Signed-off-by: Heiko Stuebner <heiko at sntech.de>
> > > ---
> > > changes since v1:
> > > 
> > > - address comments from Tomasz Figa:
> > >   * split handling functions for eints 0-3 for s3c2412 and all others
> > >   * change the handling for s3c2412 eints 0-3 in that they now use
> > >   
> > >     chained_irq_* for the outer parent interrupt
> > 
> > OK, so you finally decided to use the way I suggested. Have you managed to
> > do some testing on a S3C2412?
> 
> Nope, after pondering everything a bit more ... your description just
> sounded more plausible :-) . I only have access to s3c2416 and s3c2450
> boards, so everything else is just done according to datasheets and in the
> hope of it being correct. S3C2412 is really the only familiy member having
> the 4 eints in both registers.
> 
> Also the (reworked) legacy eint code also uses this scheme ... so at least
> now both are either correct or wrong. We will only know if someone with a
> s3c2412 comes along at some point :-) .

That's why I was wondering whether it is possible to get a board with S3C2412 
or 13 somewhere. The Logitech controller would be pretty interesting, but is 
it still possible to get it? (Btw. Is it mach-jive in the kernel?)

Best regards,
-- 
Tomasz Figa
Samsung Poland R&D Center
SW Solution Development, Kernel and System Framework



From olof at lixom.net  Thu Apr 11 05:51:46 2013
From: olof at lixom.net (Olof Johansson)
Date: Thu, 11 Apr 2013 02:51:46 -0700
Subject: [GIT PULL][for 3.10] pull request from armsoc/pxa branch in pxa
 git tree
In-Reply-To: <CAN1soZzqag7W3Yz07-2KV-4BVd1eN0dYMiFhsg6+NEc1hRZKjg@mail.gmail.com>
References: <CAN1soZzqag7W3Yz07-2KV-4BVd1eN0dYMiFhsg6+NEc1hRZKjg@mail.gmail.com>
Message-ID: <20130411095146.GF31465@quad.lixom.net>

On Thu, Apr 11, 2013 at 10:30:30AM +0800, Haojian Zhuang wrote:
> Hi Arnd & Olof,
> 
> Please help to merge armsoc/pxa branch from pxa git tree.
> 
> Regards
> Haojian
> 
> The following changes since commit 31880c37c11e28cb81c70757e38392b42e695dc6:
> 
>   Linux 3.9-rc6 (2013-04-07 20:49:54 -0700)
> 
> are available in the git repository at:
> 
>   git://github.com/hzhuang1/linux.git armsoc/pxa

Thanks. These short branches for "minor" platforms don't really fit in our
flow of categories. I wonder if we should start a separate next/ category for
them next release.

Anyway, since this modifies a bunch of board files to deal with the new gpio
config, I've merged it somewhat randomly into next/boards.


-Olof


From heiko at sntech.de  Thu Apr 11 05:54:21 2013
From: heiko at sntech.de (Heiko =?iso-8859-1?q?St=FCbner?=)
Date: Thu, 11 Apr 2013 11:54:21 +0200
Subject: [PATCH v2] pinctrl: Add pinctrl-s3c24xx driver
In-Reply-To: <3973166.f1dd7C8GWR@amdc1227>
References: <201304110116.41525.heiko@sntech.de>
 <201304111132.05009.heiko@sntech.de> <3973166.f1dd7C8GWR@amdc1227>
Message-ID: <201304111154.22073.heiko@sntech.de>

Am Donnerstag, 11. April 2013, 11:43:19 schrieb Tomasz Figa:
> On Thursday 11 of April 2013 11:32:03 Heiko St?bner wrote:
> > Am Donnerstag, 11. April 2013, 10:54:45 schrieb Tomasz Figa:
> > > Hi Heiko,
> > > 
> > > As previously, generally looks good to me, but see my comments inline.
> > > 
> > > On Thursday 11 of April 2013 01:16:41 Heiko St?bner wrote:
> > > > The s3c24xx pins follow a similar pattern as the other Samsung SoCs
> > > > and can therefore reuse the already introduced infrastructure.
> > > > 
> > > > The s3c24xx SoCs have one design oddity in that the first 4 external
> > > > interrupts do not reside in the eint pending register but in the main
> > > > interrupt controller instead. We solve this by forwarding the
> > > > external interrupt from the main controller into the irq domain of
> > > > the pin bank. The masking/acking of these interrupts is handled in
> > > > the same way.
> > > > 
> > > > Furthermore the S3C2412/2413 SoCs contain another oddity in that they
> > > > keep the same 4 eints in the main interrupt controller and eintpend
> > > > register and requiring ack operations to happen in both. To solve
> > > > this a ctrl_type enum is introduced which can keep the type of
> > > > controller
> > > 
> > > Hmm, I think you forgot to edit the commit message, since we decided to
> > > replace ctrl_type with another compatible string.
> > 
> > One should not do these things after midnight :-) [true for most of the
> > other mistakes below too].
> > 
> > > > in the samsung_pin_ctrl struct for later retrieval.
> > > > 
> > > > The ctrl_type enum contains only S3C24XX and S3C2412 types, as the
> > > > eint-speciality is currently the only use-case. But it can be expaned
> > > > if other SoCs gain special handling requirements later on.
> > > > 
> > > > Signed-off-by: Heiko Stuebner <heiko at sntech.de>
> > > > ---
> > > > changes since v1:
> > > > 
> > > > - address comments from Tomasz Figa:
> > > >   * split handling functions for eints 0-3 for s3c2412 and all others
> > > >   * change the handling for s3c2412 eints 0-3 in that they now use
> > > >   
> > > >     chained_irq_* for the outer parent interrupt
> > > 
> > > OK, so you finally decided to use the way I suggested. Have you managed
> > > to do some testing on a S3C2412?
> > 
> > Nope, after pondering everything a bit more ... your description just
> > sounded more plausible :-) . I only have access to s3c2416 and s3c2450
> > boards, so everything else is just done according to datasheets and in
> > the hope of it being correct. S3C2412 is really the only familiy member
> > having the 4 eints in both registers.
> > 
> > Also the (reworked) legacy eint code also uses this scheme ... so at
> > least now both are either correct or wrong. We will only know if someone
> > with a s3c2412 comes along at some point :-) .
> 
> That's why I was wondering whether it is possible to get a board with
> S3C2412 or 13 somewhere. The Logitech controller would be pretty
> interesting, but is it still possible to get it? (Btw. Is it mach-jive in
> the kernel?)

The squeezebox controller is still available in some shops, but the prices 
their asking (>=160 EUR for the controller alone) are in no relation to the 
age and "power" of the hardware. And yes they're the jive mach.



From laurent.pinchart at ideasonboard.com  Thu Apr 11 05:56:31 2013
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Thu, 11 Apr 2013 11:56:31 +0200
Subject: [PATCH V2] video: implement a simple framebuffer driver
In-Reply-To: <20130408171637.98b5ad1f867bcbda883af68b@linux-foundation.org>
References: <1365043183-28905-1-git-send-email-swarren@wwwdotorg.org>
 <20130408171637.98b5ad1f867bcbda883af68b@linux-foundation.org>
Message-ID: <2569832.XQDrhUGNaI@avalon>

On Monday 08 April 2013 17:16:37 Andrew Morton wrote:
> On Wed,  3 Apr 2013 20:39:43 -0600 Stephen Warren wrote:
> > A simple frame-buffer describes a raw memory region that may be rendered
> > to, with the assumption that the display hardware has already been set
> > up to scan out from that buffer.
> > 
> > This is useful in cases where a bootloader exists and has set up the
> > display hardware, but a Linux driver doesn't yet exist for the display
> > hardware.
> > 
> > ...
> > 
> > +config FB_SIMPLE
> > +	bool "Simple framebuffer support"
> > +	depends on (FB = y) && OF
> 
> It's sad that this simple little thing requires Open Firmware.  Could
> it be generalised in some way so that the small amount of setup info
> could be provided by other means (eg, module_param) or does the
> dependency go deeper than that?

I second that request. I like the idea of a simple framebuffer driver if it 
helps deprecating fbdev in the long term, but I don't want it to offer an 
excuse not to implement a DRM/KMS driver. In particular adding DT bindings 
would force us to keep supporting the ABI for a (too) long time.

> > +struct simplefb_format simplefb_formats[] = {
> > +	{ "r5g6b5", 16, {11, 5}, {5, 6}, {0, 5}, {0, 0} },
> > +};
> 
> I'll make this static.

-- 
Regards,

Laurent Pinchart



From olof at lixom.net  Thu Apr 11 06:05:25 2013
From: olof at lixom.net (Olof Johansson)
Date: Thu, 11 Apr 2013 03:05:25 -0700
Subject: [GIT PULL 1/4] ARM: imx: noncritical fixes for 3.10
In-Reply-To: <1365520775-28478-1-git-send-email-shawn.guo@linaro.org>
References: <1365520775-28478-1-git-send-email-shawn.guo@linaro.org>
Message-ID: <20130411100525.GH31465@quad.lixom.net>

On Tue, Apr 09, 2013 at 11:19:32PM +0800, Shawn Guo wrote:
> The following changes since commit 07961ac7c0ee8b546658717034fe692fd12eefa9:
> 
>   Linux 3.9-rc5 (2013-03-31 15:12:43 -0700)
> 
> are available in the git repository at:
> 
>   git://git.linaro.org/people/shawnguo/linux-2.6.git tags/imx-noncritical-fixes-3.10

Thanks, pulled into next/fixes-non-critical.


-Oof


From olof at lixom.net  Thu Apr 11 06:02:22 2013
From: olof at lixom.net (Olof Johansson)
Date: Thu, 11 Apr 2013 03:02:22 -0700
Subject: [PATCH] ARM: vexpress: Remove A9 PMU compatible values for
 non-A9 platforms
In-Reply-To: <1365513470-2680-1-git-send-email-pawel.moll@arm.com>
References: <1365513470-2680-1-git-send-email-pawel.moll@arm.com>
Message-ID: <20130411100222.GG31465@quad.lixom.net>

On Tue, Apr 09, 2013 at 02:17:50PM +0100, Pawel Moll wrote:
> The ARM perf core code used to rely on the pmu node being
> compatible with "arm,cortex-a9-pmu", even when the PMUs
> of the different Cortex-A processors are not really
> compatible... This is no longer required and actually
> became harmful, so remove all the offending values
> from Versatile Express DTS files.
> 
> Signed-off-by: Pawel Moll <pawel.moll at arm.com>
> ---
> Hello Arnd, Olof,
> 
> Could you please add this patch to your fixes branch for 3.10 or
> to pull from the tag below?

Hi,

Please base all branches on a full -rc. To avoid respinning just for one patch
in this case, I just cherry-picked it in instead.

It's applied to next/fixes-non-critical.

Thanks!


-Olof



From olof at lixom.net  Thu Apr 11 06:08:56 2013
From: olof at lixom.net (Olof Johansson)
Date: Thu, 11 Apr 2013 03:08:56 -0700
Subject: [GIT PULL 2/4] ARM: imx: cleanup for 3.10
In-Reply-To: <1365520775-28478-2-git-send-email-shawn.guo@linaro.org>
References: <1365520775-28478-1-git-send-email-shawn.guo@linaro.org>
 <1365520775-28478-2-git-send-email-shawn.guo@linaro.org>
Message-ID: <20130411100856.GI31465@quad.lixom.net>

On Tue, Apr 09, 2013 at 11:19:33PM +0800, Shawn Guo wrote:
> The following changes since commit 07961ac7c0ee8b546658717034fe692fd12eefa9:
> 
>   Linux 3.9-rc5 (2013-03-31 15:12:43 -0700)
> 
> are available in the git repository at:
> 
>   git://git.linaro.org/people/shawnguo/linux-2.6.git tags/imx-cleanup-3.10

Merged into next/cleanup.


-Olof


From m.grzeschik at pengutronix.de  Thu Apr 11 06:13:13 2013
From: m.grzeschik at pengutronix.de (Michael Grzeschik)
Date: Thu, 11 Apr 2013 12:13:13 +0200
Subject: [PATCH 0/4] ARM: dts: imx: basic dts for mx5x
Message-ID: <1365675197-9687-1-git-send-email-m.grzeschik@pengutronix.de>

This patchset adds basic usb support for the qsb.

Michael Grzeschik (4):
  ARM: dts: imx: add imx5x usbmisc entries
  ARM: dts: imx: add imx5x usb clock DT lookups
  ARM: dts: imx: use usb-nop-xceiv usbphy entries for imx5x
  ARM: dts: imx: imx53-qsb.dts: enable usbotg and usbh1

 arch/arm/boot/dts/imx51.dtsi    | 23 +++++++++++++++++++++++
 arch/arm/boot/dts/imx53-qsb.dts |  8 ++++++++
 arch/arm/boot/dts/imx53.dtsi    | 31 +++++++++++++++++++++++++++++++
 3 files changed, 62 insertions(+)

-- 
1.8.2.rc2



From m.grzeschik at pengutronix.de  Thu Apr 11 06:13:15 2013
From: m.grzeschik at pengutronix.de (Michael Grzeschik)
Date: Thu, 11 Apr 2013 12:13:15 +0200
Subject: [PATCH 2/4] ARM: dts: imx: add imx5x usb clock DT lookups
In-Reply-To: <1365675197-9687-1-git-send-email-m.grzeschik@pengutronix.de>
References: <1365675197-9687-1-git-send-email-m.grzeschik@pengutronix.de>
Message-ID: <1365675197-9687-3-git-send-email-m.grzeschik@pengutronix.de>

Signed-off-by: Michael Grzeschik <m.grzeschik at pengutronix.de>
---
 arch/arm/boot/dts/imx51.dtsi | 5 +++++
 arch/arm/boot/dts/imx53.dtsi | 5 +++++
 2 files changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/imx51.dtsi b/arch/arm/boot/dts/imx51.dtsi
index 2316472..01fe241 100644
--- a/arch/arm/boot/dts/imx51.dtsi
+++ b/arch/arm/boot/dts/imx51.dtsi
@@ -157,6 +157,7 @@
 				compatible = "fsl,imx51-usb", "fsl,imx27-usb";
 				reg = <0x73f80000 0x0200>;
 				interrupts = <18>;
+				clocks = <&clks 108>;
 				fsl,usbmisc = <&usbmisc 0>;
 				status = "disabled";
 			};
@@ -165,6 +166,7 @@
 				compatible = "fsl,imx51-usb", "fsl,imx27-usb";
 				reg = <0x73f80200 0x0200>;
 				interrupts = <14>;
+				clocks = <&clks 108>;
 				fsl,usbmisc = <&usbmisc 1>;
 				status = "disabled";
 			};
@@ -173,6 +175,7 @@
 				compatible = "fsl,imx51-usb", "fsl,imx27-usb";
 				reg = <0x73f80400 0x0200>;
 				interrupts = <16>;
+				clocks = <&clks 108>;
 				fsl,usbmisc = <&usbmisc 2>;
 				status = "disabled";
 			};
@@ -181,6 +184,7 @@
 				compatible = "fsl,imx51-usb", "fsl,imx27-usb";
 				reg = <0x73f80600 0x0200>;
 				interrupts = <17>;
+				clocks = <&clks 108>;
 				fsl,usbmisc = <&usbmisc 3>;
 				status = "disabled";
 			};
@@ -189,6 +193,7 @@
 				#index-cells = <1>;
 				compatible = "fsl,imx51-usbmisc";
 				reg = <0x73f80800 0x200>;
+				clocks = <&clks 108>;
 			};
 
 			gpio1: gpio at 73f84000 {
diff --git a/arch/arm/boot/dts/imx53.dtsi b/arch/arm/boot/dts/imx53.dtsi
index c00a100..9a1595f 100644
--- a/arch/arm/boot/dts/imx53.dtsi
+++ b/arch/arm/boot/dts/imx53.dtsi
@@ -163,6 +163,7 @@
 				compatible = "fsl,imx53-usb", "fsl,imx27-usb";
 				reg = <0x53f80000 0x0200>;
 				interrupts = <18>;
+				clocks = <&clks 108>;
 				fsl,usbmisc = <&usbmisc 0>;
 				status = "disabled";
 			};
@@ -171,6 +172,7 @@
 				compatible = "fsl,imx53-usb", "fsl,imx27-usb";
 				reg = <0x53f80200 0x0200>;
 				interrupts = <14>;
+				clocks = <&clks 108>;
 				fsl,usbmisc = <&usbmisc 1>;
 				status = "disabled";
 			};
@@ -179,6 +181,7 @@
 				compatible = "fsl,imx53-usb", "fsl,imx27-usb";
 				reg = <0x53f80400 0x0200>;
 				interrupts = <16>;
+				clocks = <&clks 108>;
 				fsl,usbmisc = <&usbmisc 2>;
 				status = "disabled";
 			};
@@ -187,6 +190,7 @@
 				compatible = "fsl,imx53-usb", "fsl,imx27-usb";
 				reg = <0x53f80600 0x0200>;
 				interrupts = <17>;
+				clocks = <&clks 108>;
 				fsl,usbmisc = <&usbmisc 3>;
 				status = "disabled";
 			};
@@ -195,6 +199,7 @@
 				#index-cells = <1>;
 				compatible = "fsl,imx53-usbmisc";
 				reg = <0x53f80800 0x200>;
+				clocks = <&clks 108>;
 			};
 
 			gpio1: gpio at 53f84000 {
-- 
1.8.2.rc2



From m.grzeschik at pengutronix.de  Thu Apr 11 06:13:16 2013
From: m.grzeschik at pengutronix.de (Michael Grzeschik)
Date: Thu, 11 Apr 2013 12:13:16 +0200
Subject: [PATCH 3/4] ARM: dts: imx: use usb-nop-xceiv usbphy entries for imx5x
In-Reply-To: <1365675197-9687-1-git-send-email-m.grzeschik@pengutronix.de>
References: <1365675197-9687-1-git-send-email-m.grzeschik@pengutronix.de>
Message-ID: <1365675197-9687-4-git-send-email-m.grzeschik@pengutronix.de>

Signed-off-by: Michael Grzeschik <m.grzeschik at pengutronix.de>
---
 arch/arm/boot/dts/imx51.dtsi |  8 ++++++++
 arch/arm/boot/dts/imx53.dtsi | 16 ++++++++++++++++
 2 files changed, 24 insertions(+)

diff --git a/arch/arm/boot/dts/imx51.dtsi b/arch/arm/boot/dts/imx51.dtsi
index 01fe241..53fe73c 100644
--- a/arch/arm/boot/dts/imx51.dtsi
+++ b/arch/arm/boot/dts/imx51.dtsi
@@ -153,12 +153,20 @@
 				};
 			};
 
+			usbphy0: usbphy at 0 {
+				compatible = "usb-nop-xceiv";
+				clocks = <&clks 124>;
+				clock-names = "main_clk";
+				status = "okay";
+			};
+
 			usbotg: usb at 73f80000 {
 				compatible = "fsl,imx51-usb", "fsl,imx27-usb";
 				reg = <0x73f80000 0x0200>;
 				interrupts = <18>;
 				clocks = <&clks 108>;
 				fsl,usbmisc = <&usbmisc 0>;
+				fsl,usbphy = <&usbphy0>;
 				status = "disabled";
 			};
 
diff --git a/arch/arm/boot/dts/imx53.dtsi b/arch/arm/boot/dts/imx53.dtsi
index 9a1595f..f8e0adb 100644
--- a/arch/arm/boot/dts/imx53.dtsi
+++ b/arch/arm/boot/dts/imx53.dtsi
@@ -159,12 +159,27 @@
 				};
 			};
 
+			usbphy0: usbphy at 0 {
+				compatible = "usb-nop-xceiv";
+				clocks = <&clks 124>;
+				clock-names = "main_clk";
+				status = "okay";
+			};
+
+			usbphy1: usbphy at 1 {
+				compatible = "usb-nop-xceiv";
+				clocks = <&clks 125>;
+				clock-names = "main_clk";
+				status = "okay";
+			};
+
 			usbotg: usb at 53f80000 {
 				compatible = "fsl,imx53-usb", "fsl,imx27-usb";
 				reg = <0x53f80000 0x0200>;
 				interrupts = <18>;
 				clocks = <&clks 108>;
 				fsl,usbmisc = <&usbmisc 0>;
+				fsl,usbphy = <&usbphy0>;
 				status = "disabled";
 			};
 
@@ -174,6 +189,7 @@
 				interrupts = <14>;
 				clocks = <&clks 108>;
 				fsl,usbmisc = <&usbmisc 1>;
+				fsl,usbphy = <&usbphy1>;
 				status = "disabled";
 			};
 
-- 
1.8.2.rc2



From m.grzeschik at pengutronix.de  Thu Apr 11 06:13:17 2013
From: m.grzeschik at pengutronix.de (Michael Grzeschik)
Date: Thu, 11 Apr 2013 12:13:17 +0200
Subject: [PATCH 4/4] ARM: dts: imx: imx53-qsb.dts: enable usbotg and usbh1
In-Reply-To: <1365675197-9687-1-git-send-email-m.grzeschik@pengutronix.de>
References: <1365675197-9687-1-git-send-email-m.grzeschik@pengutronix.de>
Message-ID: <1365675197-9687-5-git-send-email-m.grzeschik@pengutronix.de>

Signed-off-by: Michael Grzeschik <m.grzeschik at pengutronix.de>
---
 arch/arm/boot/dts/imx53-qsb.dts | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/imx53-qsb.dts b/arch/arm/boot/dts/imx53-qsb.dts
index 05cc562..953b2d4 100644
--- a/arch/arm/boot/dts/imx53-qsb.dts
+++ b/arch/arm/boot/dts/imx53-qsb.dts
@@ -83,6 +83,14 @@
 	};
 };
 
+&usbotg {
+       status = "okay";
+};
+
+&usbh1 {
+       status = "okay";
+};
+
 &esdhc1 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&pinctrl_esdhc1_1>;
-- 
1.8.2.rc2



From m.grzeschik at pengutronix.de  Thu Apr 11 06:13:14 2013
From: m.grzeschik at pengutronix.de (Michael Grzeschik)
Date: Thu, 11 Apr 2013 12:13:14 +0200
Subject: [PATCH 1/4] ARM: dts: imx: add imx5x usbmisc entries
In-Reply-To: <1365675197-9687-1-git-send-email-m.grzeschik@pengutronix.de>
References: <1365675197-9687-1-git-send-email-m.grzeschik@pengutronix.de>
Message-ID: <1365675197-9687-2-git-send-email-m.grzeschik@pengutronix.de>

Signed-off-by: Michael Grzeschik <m.grzeschik at pengutronix.de>
---
 arch/arm/boot/dts/imx51.dtsi | 10 ++++++++++
 arch/arm/boot/dts/imx53.dtsi | 10 ++++++++++
 2 files changed, 20 insertions(+)

diff --git a/arch/arm/boot/dts/imx51.dtsi b/arch/arm/boot/dts/imx51.dtsi
index fcf035b..2316472 100644
--- a/arch/arm/boot/dts/imx51.dtsi
+++ b/arch/arm/boot/dts/imx51.dtsi
@@ -157,6 +157,7 @@
 				compatible = "fsl,imx51-usb", "fsl,imx27-usb";
 				reg = <0x73f80000 0x0200>;
 				interrupts = <18>;
+				fsl,usbmisc = <&usbmisc 0>;
 				status = "disabled";
 			};
 
@@ -164,6 +165,7 @@
 				compatible = "fsl,imx51-usb", "fsl,imx27-usb";
 				reg = <0x73f80200 0x0200>;
 				interrupts = <14>;
+				fsl,usbmisc = <&usbmisc 1>;
 				status = "disabled";
 			};
 
@@ -171,6 +173,7 @@
 				compatible = "fsl,imx51-usb", "fsl,imx27-usb";
 				reg = <0x73f80400 0x0200>;
 				interrupts = <16>;
+				fsl,usbmisc = <&usbmisc 2>;
 				status = "disabled";
 			};
 
@@ -178,9 +181,16 @@
 				compatible = "fsl,imx51-usb", "fsl,imx27-usb";
 				reg = <0x73f80600 0x0200>;
 				interrupts = <17>;
+				fsl,usbmisc = <&usbmisc 3>;
 				status = "disabled";
 			};
 
+			usbmisc: usbmisc at 73f80800 {
+				#index-cells = <1>;
+				compatible = "fsl,imx51-usbmisc";
+				reg = <0x73f80800 0x200>;
+			};
+
 			gpio1: gpio at 73f84000 {
 				compatible = "fsl,imx51-gpio", "fsl,imx35-gpio";
 				reg = <0x73f84000 0x4000>;
diff --git a/arch/arm/boot/dts/imx53.dtsi b/arch/arm/boot/dts/imx53.dtsi
index d05aa21..c00a100 100644
--- a/arch/arm/boot/dts/imx53.dtsi
+++ b/arch/arm/boot/dts/imx53.dtsi
@@ -163,6 +163,7 @@
 				compatible = "fsl,imx53-usb", "fsl,imx27-usb";
 				reg = <0x53f80000 0x0200>;
 				interrupts = <18>;
+				fsl,usbmisc = <&usbmisc 0>;
 				status = "disabled";
 			};
 
@@ -170,6 +171,7 @@
 				compatible = "fsl,imx53-usb", "fsl,imx27-usb";
 				reg = <0x53f80200 0x0200>;
 				interrupts = <14>;
+				fsl,usbmisc = <&usbmisc 1>;
 				status = "disabled";
 			};
 
@@ -177,6 +179,7 @@
 				compatible = "fsl,imx53-usb", "fsl,imx27-usb";
 				reg = <0x53f80400 0x0200>;
 				interrupts = <16>;
+				fsl,usbmisc = <&usbmisc 2>;
 				status = "disabled";
 			};
 
@@ -184,9 +187,16 @@
 				compatible = "fsl,imx53-usb", "fsl,imx27-usb";
 				reg = <0x53f80600 0x0200>;
 				interrupts = <17>;
+				fsl,usbmisc = <&usbmisc 3>;
 				status = "disabled";
 			};
 
+			usbmisc: usbmisc at 53f80800 {
+				#index-cells = <1>;
+				compatible = "fsl,imx53-usbmisc";
+				reg = <0x53f80800 0x200>;
+			};
+
 			gpio1: gpio at 53f84000 {
 				compatible = "fsl,imx53-gpio", "fsl,imx35-gpio";
 				reg = <0x53f84000 0x4000>;
-- 
1.8.2.rc2



From olof at lixom.net  Thu Apr 11 06:20:47 2013
From: olof at lixom.net (Olof Johansson)
Date: Thu, 11 Apr 2013 03:20:47 -0700
Subject: [GIT PULL v2] Reset controller API
In-Reply-To: <1365495574.4023.32.camel@pizza.hi.pengutronix.de>
References: <1365495574.4023.32.camel@pizza.hi.pengutronix.de>
Message-ID: <20130411102047.GA7437@quad.lixom.net>

On Tue, Apr 09, 2013 at 10:19:34AM +0200, Philipp Zabel wrote:
> Hi Olof,
> 
> I have added two fixes on top of the reset series at
> git://git.pengutronix.de/git/pza/linux.git reset/for_v3.10.
> Could you pull them in together with the rest?
> 
> The following changes since commit 8bb9660418e05bb1845ac1a2428444d78e322cc7:
> 
>   Linux 3.9-rc4 (2013-03-23 16:52:44 -0700)
> 
> are available in the git repository at:
> 
>   git://git.pengutronix.de/git/pza/linux.git reset/for_v3.10
> 
> for you to fetch changes up to fbdb93ecb869f02a5f8f145fa06a0984c415a7d4:
> 
>   Documentation: gpio-reset.txt: Fix 'initially-in-reset' example (2013-04-09 09:55:00 +0200)
> 
> They add a simple API for devices to request being reset by separate
> reset controller hardware and implement the reset signal device tree
> bindings proposed by Stephen Warren.
> The patches have been discussed on the linux-arm-kernel list under the topic
> "Reset controller API to reset IP modules on i.MX5 and i.MX6".
> 
> ----------------------------------------------------------------
> Dan Carpenter (1):
>       reset: NULL deref on allocation failure
> 
> Fabio Estevam (1):
>       Documentation: gpio-reset.txt: Fix 'initially-in-reset' example
> 
> Philipp Zabel (2):
>       reset: Add reset controller API
>       reset: Add driver for gpio-controlled reset pins
> 
> Stephen Warren (1):
>       dt: describe base reset signal binding

Hmm, I don't see an ack or reviewed-by on these subsystem bindings from
neither Rob nor Grant.

Since it's a brand new subsystem binding, I'd like to see them ack it
before we pick it up.


-Olof


From p.zabel at pengutronix.de  Thu Apr 11 06:23:32 2013
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Thu, 11 Apr 2013 12:23:32 +0200
Subject: [PATCH] ARM i.MX6q: Fix periph_clk2_sel and periph2_clk2_sel clocks
Message-ID: <1365675812-21600-1-git-send-email-p.zabel@pengutronix.de>

The periph_clk2_sel mux can be set to pll3, pll1, or
osc/pll2-bypass/pll2_burn_in_clk. The periph2_clk2_sel
mux can be set to pll3 or pll2.

Signed-off-by: Philipp Zabel <p.zabel at pengutronix.de>
---
 arch/arm/mach-imx/clk-imx6q.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-imx/clk-imx6q.c b/arch/arm/mach-imx/clk-imx6q.c
index 65319d5..bdeddf3 100644
--- a/arch/arm/mach-imx/clk-imx6q.c
+++ b/arch/arm/mach-imx/clk-imx6q.c
@@ -177,7 +177,8 @@ int imx6q_set_lpm(enum mxc_cpu_pwr_mode mode)
 static const char *step_sels[]	= { "osc", "pll2_pfd2_396m", };
 static const char *pll1_sw_sels[]	= { "pll1_sys", "step", };
 static const char *periph_pre_sels[]	= { "pll2_bus", "pll2_pfd2_396m", "pll2_pfd0_352m", "pll2_198m", };
-static const char *periph_clk2_sels[]	= { "pll3_usb_otg", "osc", };
+static const char *periph_clk2_sels[]	= { "pll3_usb_otg", "pll1_sys", "osc", "dummy", };
+static const char *periph2_clk2_sels[]	= { "pll3_usb_otg", "pll2_bus", };
 static const char *periph_sels[]	= { "periph_pre", "periph_clk2", };
 static const char *periph2_sels[]	= { "periph2_pre", "periph2_clk2", };
 static const char *axi_sels[]		= { "periph", "pll2_pfd2_396m", "pll3_pfd1_540m", };
@@ -369,8 +370,8 @@ int __init mx6q_clocks_init(void)
 	clk[pll1_sw]          = imx_clk_mux("pll1_sw",	        base + 0xc,  2,  1, pll1_sw_sels,      ARRAY_SIZE(pll1_sw_sels));
 	clk[periph_pre]       = imx_clk_mux("periph_pre",       base + 0x18, 18, 2, periph_pre_sels,   ARRAY_SIZE(periph_pre_sels));
 	clk[periph2_pre]      = imx_clk_mux("periph2_pre",      base + 0x18, 21, 2, periph_pre_sels,   ARRAY_SIZE(periph_pre_sels));
-	clk[periph_clk2_sel]  = imx_clk_mux("periph_clk2_sel",  base + 0x18, 12, 1, periph_clk2_sels,  ARRAY_SIZE(periph_clk2_sels));
-	clk[periph2_clk2_sel] = imx_clk_mux("periph2_clk2_sel", base + 0x18, 20, 1, periph_clk2_sels,  ARRAY_SIZE(periph_clk2_sels));
+	clk[periph_clk2_sel]  = imx_clk_mux("periph_clk2_sel",  base + 0x18, 12, 2, periph_clk2_sels,  ARRAY_SIZE(periph_clk2_sels));
+	clk[periph2_clk2_sel] = imx_clk_mux("periph2_clk2_sel", base + 0x18, 20, 1, periph2_clk2_sels, ARRAY_SIZE(periph2_clk2_sels));
 	clk[axi_sel]          = imx_clk_mux("axi_sel",          base + 0x14, 6,  2, axi_sels,          ARRAY_SIZE(axi_sels));
 	clk[esai_sel]         = imx_clk_mux("esai_sel",         base + 0x20, 19, 2, audio_sels,        ARRAY_SIZE(audio_sels));
 	clk[asrc_sel]         = imx_clk_mux("asrc_sel",         base + 0x30, 7,  2, audio_sels,        ARRAY_SIZE(audio_sels));
-- 
1.8.2.rc2



From olof at lixom.net  Thu Apr 11 06:25:53 2013
From: olof at lixom.net (Olof Johansson)
Date: Thu, 11 Apr 2013 03:25:53 -0700
Subject: [GIT PULL v2] Reset controller API
In-Reply-To: <20130411102047.GA7437@quad.lixom.net>
References: <1365495574.4023.32.camel@pizza.hi.pengutronix.de>
 <20130411102047.GA7437@quad.lixom.net>
Message-ID: <CAOesGMidoasD35LL4VvCUPwTPrrRE9hxPGUVmuGQtuvH_nxs0g@mail.gmail.com>

On Thu, Apr 11, 2013 at 3:20 AM, Olof Johansson <olof at lixom.net> wrote:
> On Tue, Apr 09, 2013 at 10:19:34AM +0200, Philipp Zabel wrote:
>> Hi Olof,
>>
>> I have added two fixes on top of the reset series at
>> git://git.pengutronix.de/git/pza/linux.git reset/for_v3.10.
>> Could you pull them in together with the rest?
>>
>> The following changes since commit 8bb9660418e05bb1845ac1a2428444d78e322cc7:
>>
>>   Linux 3.9-rc4 (2013-03-23 16:52:44 -0700)
>>
>> are available in the git repository at:
>>
>>   git://git.pengutronix.de/git/pza/linux.git reset/for_v3.10
>>
>> for you to fetch changes up to fbdb93ecb869f02a5f8f145fa06a0984c415a7d4:
>>
>>   Documentation: gpio-reset.txt: Fix 'initially-in-reset' example (2013-04-09 09:55:00 +0200)
>>
>> They add a simple API for devices to request being reset by separate
>> reset controller hardware and implement the reset signal device tree
>> bindings proposed by Stephen Warren.
>> The patches have been discussed on the linux-arm-kernel list under the topic
>> "Reset controller API to reset IP modules on i.MX5 and i.MX6".
>>
>> ----------------------------------------------------------------
>> Dan Carpenter (1):
>>       reset: NULL deref on allocation failure
>>
>> Fabio Estevam (1):
>>       Documentation: gpio-reset.txt: Fix 'initially-in-reset' example
>>
>> Philipp Zabel (2):
>>       reset: Add reset controller API
>>       reset: Add driver for gpio-controlled reset pins
>>
>> Stephen Warren (1):
>>       dt: describe base reset signal binding
>
> Hmm, I don't see an ack or reviewed-by on these subsystem bindings from
> neither Rob nor Grant.
>
> Since it's a brand new subsystem binding, I'd like to see them ack it
> before we pick it up.

Sigh. Ok, so I now stumbled across the Ack from Rob that you didn't
pick up. Don't do it like that again, please. If Shawn prematurely
bases his code on top of unacked patches, then that's his problem, not
yours.

The problem still remains though, since the gpio-reset binding hasn't
seen an ack on the list, as far as I can tell. And I'll have a comment
on that as well in a minute, see separate reply on that patch.


-Olof


From olof at lixom.net  Thu Apr 11 06:35:37 2013
From: olof at lixom.net (Olof Johansson)
Date: Thu, 11 Apr 2013 03:35:37 -0700
Subject: [PATCH v6 3/8] reset: Add driver for gpio-controlled reset pins
In-Reply-To: <1364488523-20310-4-git-send-email-p.zabel@pengutronix.de>
References: <1364488523-20310-1-git-send-email-p.zabel@pengutronix.de>
 <1364488523-20310-4-git-send-email-p.zabel@pengutronix.de>
Message-ID: <CAOesGMgo61M=oxG6_6EEGu7kL3Wa+HsdEomCxUnvj-Rbdhujgg@mail.gmail.com>

Hi,

On Thu, Mar 28, 2013 at 9:35 AM, Philipp Zabel <p.zabel at pengutronix.de> wrote:
> This driver implements a reset controller device that toggles gpios
> connected to reset pins of peripheral ICs. The delay between assertion
> and de-assertion of the reset signal can be configured.
>
> Signed-off-by: Philipp Zabel <p.zabel at pengutronix.de>
> Reviewed-by: Stephen Warren <swarren at nvidia.com>
> Reviewed-by: Marek Vasut <marex at denx.de>
> Reviewed-by: Shawn Guo <shawn.guo at linaro.org>
> ---
>  .../devicetree/bindings/reset/gpio-reset.txt       |  37 ++++
>  drivers/reset/Kconfig                              |  13 ++
>  drivers/reset/Makefile                             |   1 +
>  drivers/reset/gpio-reset.c                         | 208 +++++++++++++++++++++
>  4 files changed, 259 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/reset/gpio-reset.txt
>  create mode 100644 drivers/reset/gpio-reset.c
>
> diff --git a/Documentation/devicetree/bindings/reset/gpio-reset.txt b/Documentation/devicetree/bindings/reset/gpio-reset.txt
> new file mode 100644
> index 0000000..1f203eb
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/reset/gpio-reset.txt
> @@ -0,0 +1,37 @@
> +GPIO reset controller
> +=====================
> +
> +A GPIO reset controller controls a number of GPIOs that are connected
> +to reset pins of peripheral ICs.
> +
> +Please also refer to reset.txt in this directory for common reset
> +controller binding usage.
> +
> +Required properties:
> +- compatible: Should be "gpio-reset"
> +- reset-gpios: List of gpios used as reset lines. The gpio specifier for this
> +               property depends on the gpio controller that provides the gpio.
> +- #reset-cells: 1, see below
> +
> +Optional properties:
> +- reset-delays: List of delays in microseconds. The corresponding gpio reset
> +                line should be asserted for this duration to reset.
> +- initially-in-reset: List of integers. Zero if the initial state should be
> +                      a deasserted reset line, nonzero if the line should be
> +                      kept in reset.
> +
> +example:
> +
> +gpio_reset: gpio-reset {
> +       compatible = "gpio-reset";
> +       reset-gpios = <&gpio5 0 1>; /* active-low */
> +       reset-delays = <10000>; /* 10 ms */
> +       initially-in-reset: <1>;
> +       #reset-cells = <1>;
> +};

I find this binding that uses an array of GPIOs and their state to be
a bit awkward, especially if you compare it to something like the
simple gpio regulators that have a simpler one-to-one mapping.

Also, if you did one node per gpio you'd have a boolean property for
"initially-in-reset" which seems much more logical (i.e. the property
is either there, or it's not).

A couple of more comments:

> +config RESET_GPIO
> +       tristate "GPIO reset controller support"
> +       depends on GENERIC_GPIO
> +       help
> +         This driver provides support for reset lines that are controlled
> +         directly by GPIOs.
> +         The delay between assertion and de-assertion of the reset signal
> +         can be configured.

Can be configured how? And why would I care about that when I'm trying
to decide if I need to include this driver in my kernel configuration
or not? Seems like misplaced information.

Since this is a platform driver and not just an OF driver, shouldn't
you provide a way to specify the same configuration data through a
platform_data structure as well?


-Olof


From geert at linux-m68k.org  Thu Apr 11 06:42:29 2013
From: geert at linux-m68k.org (Geert Uytterhoeven)
Date: Thu, 11 Apr 2013 12:42:29 +0200
Subject: [PATCH V2] video: implement a simple framebuffer driver
In-Reply-To: <1365043183-28905-1-git-send-email-swarren@wwwdotorg.org>
References: <1365043183-28905-1-git-send-email-swarren@wwwdotorg.org>
Message-ID: <CAMuHMdWFVi=AFR8prins0mees4BFUUXirCC2swyQPwGs7Tt8uQ@mail.gmail.com>

On Thu, Apr 4, 2013 at 4:39 AM, Stephen Warren <swarren at wwwdotorg.org> wrote:
> +       { "r5g6b5", 16, {11, 5}, {5, 6}, {0, 5}, {0, 0} },

Why "r5g6b5" instead of "rgb565", which is what's commonly used?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds


From olof at lixom.net  Thu Apr 11 06:44:49 2013
From: olof at lixom.net (Olof Johansson)
Date: Thu, 11 Apr 2013 03:44:49 -0700
Subject: [GIT PULL] Sunxi Cleanups for 3.10
In-Reply-To: <51643864.4050906@free-electrons.com>
References: <51643864.4050906@free-electrons.com>
Message-ID: <20130411104449.GA7943@quad.lixom.net>

On Tue, Apr 09, 2013 at 05:48:52PM +0200, Maxime Ripard wrote:
> Hi Arnd, Olof,
> 
> Here is a pull request for the various cleanups for the sunXi platform
> for 3.10.
> 
> It is based both on Mike Turquette's clk-for-3.10 branch and on the
> branch clksrc/cleanup found in arm-soc
> 
> The following changes since commit 7c91d302ffe2ffac813c47d6ba2e7489a2ccb35f:
> 
>   Merge remote-tracking branch 'clk/clk-for-3.10' into sunxi/core-for-3.10 (2013-04-08 21:39:22 +0200)
> 
> are available in the git repository at:
> 
> 
>   git://github.com/mripard/linux.git tags/sunxi-cleanup-for-3.10

Thanks, pulled into next/cleanup and I have added the dependent branch as
depends/clk-for-3.10


-Olof


From olof at lixom.net  Thu Apr 11 06:49:47 2013
From: olof at lixom.net (Olof Johansson)
Date: Thu, 11 Apr 2013 03:49:47 -0700
Subject: [GIT PULL] sunXi DT additions for 3.10, take 3
In-Reply-To: <516439DC.5010009@free-electrons.com>
References: <516439DC.5010009@free-electrons.com>
Message-ID: <20130411104947.GB7943@quad.lixom.net>

On Tue, Apr 09, 2013 at 05:55:08PM +0200, Maxime Ripard wrote:
> Hi Arnd, Olof,
> 
> Please consider pulling the following pull request.
> 
> It should be our last for the 3.10 merge window.
> 
> Thanks,
> Maxime
> 
> The following changes since commit 36386d6e54d0ebcd5b2e0869f837800293d94c3c:
> 
>   arm: sunxi: Add clock to pinctrl node (2013-04-04 23:45:30 +0200)
> 
> are available in the git repository at:
> 
>   git://github.com/mripard/linux.git tags/sunxi-dt-for-3.10-3
> 
> for you to fetch changes up to 0b19b7c2c6e169efccb4b1632fe628969d001618:
> 
>   ARM: sunxi: dt: Update watchdog compatible string (2013-04-08 21:56:34 +0200)

Thanks, pulled into next/dt.


-Olof


From arnd at arndb.de  Thu Apr 11 06:52:03 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 11 Apr 2013 12:52:03 +0200
Subject: [PATCH 11/30] [media] exynos: remove unnecessary header inclusions
In-Reply-To: <51667D3D.20103@samsung.com>
References: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
 <20130410211354.397d5689@redhat.com> <51667D3D.20103@samsung.com>
Message-ID: <201304111252.04023.arnd@arndb.de>

On Thursday 11 April 2013, Sylwester Nawrocki wrote:
> On 04/11/2013 02:13 AM, Mauro Carvalho Chehab wrote:
> > Em Thu, 11 Apr 2013 02:04:53 +0200
> > Arnd Bergmann <arnd at arndb.de> escreveu:
> > 
> >> In multiplatform configurations, we cannot include headers
> >> provided by only the exynos platform. Fortunately a number
> >> of drivers that include those headers do not actually need
> >> them, so we can just remove the inclusions.
> >>
> >> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> >> Cc: linux-media at vger.kernel.org
> >> Cc: Mauro Carvalho Chehab <mchehab at redhat.com>
> > 
> > Acked-by: Mauro Carvalho Chehab <mchehab at redhat.com>
> 
> This patch is already queued in the media tree for 3.10, and it can
> be found in -next now.
> 

Ok, thanks! I'll drop it from my series then.

	Arnd


From olof at lixom.net  Thu Apr 11 07:06:45 2013
From: olof at lixom.net (Olof Johansson)
Date: Thu, 11 Apr 2013 04:06:45 -0700
Subject: [GIT PULL 5/5] omap dt changes for v3.10 merge window
In-Reply-To: <51639e43.d294dc0a.2f07.03b4SMTPIN_ADDED_MISSING@mx.google.com>
References: <pull-1365483063-475562>
 <51639e43.d294dc0a.2f07.03b4SMTPIN_ADDED_MISSING@mx.google.com>
Message-ID: <20130411110645.GA8802@quad.lixom.net>

Hi,

On Mon, Apr 08, 2013 at 09:51:03PM -0700, Tony Lindgren wrote:
> The following changes since commit 5852264f9d6139751796853fdfca9d5230cbfb97:
> 
>   Merge tag 'omap-devel-b-for-3.10' of git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending into for_3.10/dts_merged (2013-04-09 00:11:05 +0200)
> 
> are available in the git repository at:
> 
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.10/dt-signed-v2
> 
> for you to fetch changes up to 161e89a689bb88004b757986eefda2402448eef7:
> 
>   ARM/dts: OMAP3: fix pinctrl-single configuration (2013-04-08 17:00:22 -0700)
> 
> ----------------------------------------------------------------
> Device tree updates for omaps via Benoit Cousson <b-cousson at ti.com>.
> 
> Note that the branch has dependencies to two other branches:
> 
> - omap-devel-b-for-3.10 from Paul to get the AM33xx missing
>   hwmod and thus avoid a regression with Santosh's hwmod
>   cleanup including in this DT series [1]. It avoids breaking
>   bisect if this series is merged before Paul's fixes.

Looks like this was part of omap/fixes-non-critical, the branch name from Paul
just didn't percolate up. At least the topmost SHA from that merge in your
history seems to be part of said branch. :)


> - omap-for-v3.10/usb branch to avoid nasty merge conflict in
>   omap3.dtsi and omap4.dtsi due to the DTS patches contained
>   in the USB branch because of a screw up by the unnamed person
>   typing this signed tag based on Benoit's comments.


Ok, it looks like this one was merged in next/drivers as omap/usb.


So based on the above, I've merged in omap/fixes-non-critical and omap/usb as
a base, and merged this on top. All of this has gone into next/dt2.

-Olof


From m.szyprowski at samsung.com  Thu Apr 11 07:22:08 2013
From: m.szyprowski at samsung.com (Marek Szyprowski)
Date: Thu, 11 Apr 2013 13:22:08 +0200
Subject: [RFC/PATCH v2 0/2] Device Tree support for CMA (Contiguous Memory
 Allocator)
Message-ID: <1365679330-2514-1-git-send-email-m.szyprowski@samsung.com>

Hello,

This is an update for my proposal for device tree integration for
Contiguous Memory Allocator. The code is quite straightforward, but
expect again that the device tree bindings will trigger some discussion.

Just a few words for those who see this code for the first time:

The proposed bindings allows to define contiguous memory regions of
specified base address and size. Then, the defined regions can be
assigned to the given device(s) by adding a property with a phanle to
the defined contiguous memory region. From the device tree perspective
that's all. Once the bindings are added, all the memory allocations from
dma-mapping subsystem will be served from the defined contiguous memory
regions.

Contiguous Memory Allocator is a framework, which lets to provide a
large contiguous memory buffers for (usually a multimedia) devices. The
contiguous memory is reserved during early boot and then shared with
kernel, which is allowed to allocate it for movable pages. Then, when
device driver requests a contigouous buffer, the framework migrates
movable pages out of contiguous region and gives it to the driver. When
device driver frees the buffer, it is added to kernel memory pool again.
For more information, please refer to commit c64be2bb1c6eb43c838b2c6d57
("drivers: add Contiguous Memory Allocator") and d484864dd96e1830e76895
(CMA merge commit).

Why we need device tree bindings for CMA at all?

Older ARM kernels used so called board-based initialization. Those board
files contained a definition of all hardware blocks available on the
target system and particular kernel and driver software configuration
selected by the board maintainer. 

In the new approach the board files will be removed completely and
Device Tree approach is used to describe all hardware blocks available
on the target system. By definition, the bindings should be software
independent, so at least in theory it should be possible to use those
bindings with other operating systems than Linux kernel. 

However we also need to pass somehow the information about kernel and
device driver software-only configuration data, which were earlier
encoded in the board file. For such data I propose to use /chosen node,
where kernel command line has been already stored. Future bootloaders
will allow to modify or replace particular nodes and one will be able to
use custom /chosen node to configure his system. The proposed patches
introduce /chosen/contiguous-memory node and related bindings, to avoid
complicated encoding of CMA related configuration to kernel command
line.

Best regards
Marek Szyprowski
Samsung Poland R&D Center

Changelog:

v2:
- moved contiguous-memory bindings from /memory to /chosen/contiguous-memory/
  node to avoid spreading Linux specific parameters over the whole device
  tree definitions
- added support for autoconfigured regions (use zero base)
- fixes minor bugs

v1: http://thread.gmane.org/gmane.linux.drivers.devicetree/30111/
- initial proposal

Patch summary:

Marek Szyprowski (2):
  drivers: dma-contiguous: clean source code and prepare for device
    tree
  drivers: dma-contiguous: add initialization from device tree

 Documentation/devicetree/bindings/memory.txt |  101 ++++++++++
 arch/arm/boot/dts/skeleton.dtsi              |    7 +-
 drivers/base/dma-contiguous.c                |  278 +++++++++++++++++++-------
 include/asm-generic/dma-contiguous.h         |    4 +-
 include/linux/dma-contiguous.h               |   32 ++-
 5 files changed, 338 insertions(+), 84 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/memory.txt

-- 
1.7.9.5



From m.szyprowski at samsung.com  Thu Apr 11 07:22:09 2013
From: m.szyprowski at samsung.com (Marek Szyprowski)
Date: Thu, 11 Apr 2013 13:22:09 +0200
Subject: [RFC/PATCH v2 1/2] drivers: dma-contiguous: clean source code and
 prepare for device tree
In-Reply-To: <1365679330-2514-1-git-send-email-m.szyprowski@samsung.com>
References: <1365679330-2514-1-git-send-email-m.szyprowski@samsung.com>
Message-ID: <1365679330-2514-2-git-send-email-m.szyprowski@samsung.com>

This patch cleans the initialization of dma contiguous framework. The
all-in-one dma_declare_contiguous() function is now separated into
dma_contiguous_reserve_area() which only steals the the memory from
memblock allocator and dma_contiguous_add_device() function, which
assigns given device to the specified reserved memory area. This improves
the flexibility in defining contiguous memory areas and assigning device
to them, because now it is possible to assign more than one device to
the given contiguous memory area. This split in initialization is also
required for upcoming device tree support.

Signed-off-by: Marek Szyprowski <m.szyprowski at samsung.com>
Acked-by: Kyungmin Park <kyungmin.park at samsung.com>
---
 drivers/base/dma-contiguous.c        |  211 ++++++++++++++++------------------
 include/asm-generic/dma-contiguous.h |    2 -
 include/linux/dma-contiguous.h       |   32 +++++-
 3 files changed, 129 insertions(+), 116 deletions(-)

diff --git a/drivers/base/dma-contiguous.c b/drivers/base/dma-contiguous.c
index 0ca5442..01fe743 100644
--- a/drivers/base/dma-contiguous.c
+++ b/drivers/base/dma-contiguous.c
@@ -39,8 +39,15 @@ struct cma {
 	unsigned long	*bitmap;
 };
 
+static DEFINE_MUTEX(cma_mutex);
+
+static struct cma cma_areas[MAX_CMA_AREAS];
+static unsigned cma_area_count;
+
 struct cma *dma_contiguous_default_area;
 
+/*****************************************************************************/
+
 #ifdef CONFIG_CMA_SIZE_MBYTES
 #define CMA_SIZE_MBYTES CONFIG_CMA_SIZE_MBYTES
 #else
@@ -95,51 +102,20 @@ static inline __maybe_unused phys_addr_t cma_early_percent_memory(void)
 
 #endif
 
-/**
- * dma_contiguous_reserve() - reserve area for contiguous memory handling
- * @limit: End address of the reserved memory (optional, 0 for any).
- *
- * This function reserves memory from early allocator. It should be
- * called by arch specific code once the early allocator (memblock or bootmem)
- * has been activated and all other subsystems have already allocated/reserved
- * memory.
- */
-void __init dma_contiguous_reserve(phys_addr_t limit)
-{
-	phys_addr_t selected_size = 0;
-
-	pr_debug("%s(limit %08lx)\n", __func__, (unsigned long)limit);
-
-	if (size_cmdline != -1) {
-		selected_size = size_cmdline;
-	} else {
-#ifdef CONFIG_CMA_SIZE_SEL_MBYTES
-		selected_size = size_bytes;
-#elif defined(CONFIG_CMA_SIZE_SEL_PERCENTAGE)
-		selected_size = cma_early_percent_memory();
-#elif defined(CONFIG_CMA_SIZE_SEL_MIN)
-		selected_size = min(size_bytes, cma_early_percent_memory());
-#elif defined(CONFIG_CMA_SIZE_SEL_MAX)
-		selected_size = max(size_bytes, cma_early_percent_memory());
-#endif
-	}
-
-	if (selected_size) {
-		pr_debug("%s: reserving %ld MiB for global area\n", __func__,
-			 (unsigned long)selected_size / SZ_1M);
-
-		dma_declare_contiguous(NULL, selected_size, 0, limit);
-	}
-};
-
-static DEFINE_MUTEX(cma_mutex);
+/*************************************************************************/
 
-static __init int cma_activate_area(unsigned long base_pfn, unsigned long count)
+static __init int cma_activate_area(struct cma *cma)
 {
-	unsigned long pfn = base_pfn;
-	unsigned i = count >> pageblock_order;
+	int bitmap_size = BITS_TO_LONGS(cma->count) * sizeof(long);
+	unsigned long base_pfn = cma->base_pfn, pfn = base_pfn;
+	unsigned i = cma->count >> pageblock_order;
 	struct zone *zone;
 
+	cma->bitmap = kzalloc(bitmap_size, GFP_KERNEL);
+
+	if (!cma->bitmap)
+		return -ENOMEM;
+
 	WARN_ON_ONCE(!pfn_valid(pfn));
 	zone = page_zone(pfn_to_page(pfn));
 
@@ -153,92 +129,74 @@ static __init int cma_activate_area(unsigned long base_pfn, unsigned long count)
 		}
 		init_cma_reserved_pageblock(pfn_to_page(base_pfn));
 	} while (--i);
+
 	return 0;
 }
 
-static __init struct cma *cma_create_area(unsigned long base_pfn,
-				     unsigned long count)
+/**
+ * dma_contiguous_reserve() - reserve area(s) for contiguous memory handling
+ * @limit: End address of the reserved memory (optional, 0 for any).
+ *
+ * This function reserves memory from early allocator. It should be
+ * called by arch specific code once the early allocator (memblock or bootmem)
+ * has been activated and all other subsystems have already allocated/reserved
+ * memory. It reserves contiguous areas for global, device independent
+ * allocations and (optionally) all areas defined in device tree structures.
+ */
+void __init dma_contiguous_reserve(phys_addr_t limit)
 {
-	int bitmap_size = BITS_TO_LONGS(count) * sizeof(long);
-	struct cma *cma;
-	int ret = -ENOMEM;
-
-	pr_debug("%s(base %08lx, count %lx)\n", __func__, base_pfn, count);
-
-	cma = kmalloc(sizeof *cma, GFP_KERNEL);
-	if (!cma)
-		return ERR_PTR(-ENOMEM);
+	phys_addr_t sel_size = 0;
 
-	cma->base_pfn = base_pfn;
-	cma->count = count;
-	cma->bitmap = kzalloc(bitmap_size, GFP_KERNEL);
-
-	if (!cma->bitmap)
-		goto no_mem;
-
-	ret = cma_activate_area(base_pfn, count);
-	if (ret)
-		goto error;
-
-	pr_debug("%s: returned %p\n", __func__, (void *)cma);
-	return cma;
-
-error:
-	kfree(cma->bitmap);
-no_mem:
-	kfree(cma);
-	return ERR_PTR(ret);
-}
-
-static struct cma_reserved {
-	phys_addr_t start;
-	unsigned long size;
-	struct device *dev;
-} cma_reserved[MAX_CMA_AREAS] __initdata;
-static unsigned cma_reserved_count __initdata;
+	pr_debug("%s(limit %08lx)\n", __func__, (unsigned long)limit);
 
-static int __init cma_init_reserved_areas(void)
-{
-	struct cma_reserved *r = cma_reserved;
-	unsigned i = cma_reserved_count;
+	if (size_cmdline != -1) {
+		sel_size = size_cmdline;
+	} else {
+#ifdef CONFIG_CMA_SIZE_SEL_MBYTES
+		sel_size = size_bytes;
+#elif defined(CONFIG_CMA_SIZE_SEL_PERCENTAGE)
+		sel_size = cma_early_percent_memory();
+#elif defined(CONFIG_CMA_SIZE_SEL_MIN)
+		sel_size = min(size_bytes, cma_early_percent_memory());
+#elif defined(CONFIG_CMA_SIZE_SEL_MAX)
+		sel_size = max(size_bytes, cma_early_percent_memory());
+#endif
+	}
 
-	pr_debug("%s()\n", __func__);
+	if (sel_size && !dma_contiguous_default_area) {
+		pr_debug("%s: reserving %ld MiB for global area\n", __func__,
+			 (unsigned long)sel_size / SZ_1M);
 
-	for (; i; --i, ++r) {
-		struct cma *cma;
-		cma = cma_create_area(PFN_DOWN(r->start),
-				      r->size >> PAGE_SHIFT);
-		if (!IS_ERR(cma))
-			dev_set_cma_area(r->dev, cma);
+		dma_contiguous_reserve_area(sel_size, 0, limit,
+					    &dma_contiguous_default_area);
 	}
-	return 0;
-}
-core_initcall(cma_init_reserved_areas);
+};
 
 /**
- * dma_declare_contiguous() - reserve area for contiguous memory handling
- *			      for particular device
- * @dev:   Pointer to device structure.
- * @size:  Size of the reserved memory.
- * @base:  Start address of the reserved memory (optional, 0 for any).
+ * dma_contiguous_reserve_area() - reserve custom contiguous area
+ * @size: Size of the reserved area (in bytes),
+ * @base: Base address of the reserved area optional, use 0 for any
  * @limit: End address of the reserved memory (optional, 0 for any).
+ * @res_cma: Pointer to store the created cma region.
  *
- * This function reserves memory for specified device. It should be
- * called by board specific code when early allocator (memblock or bootmem)
- * is still activate.
+ * This function reserves memory from early allocator. It should be
+ * called by arch specific code once the early allocator (memblock or bootmem)
+ * has been activated and all other subsystems have already allocated/reserved
+ * memory. This function allows to create custom reserved areas for specific
+ * devices.
  */
-int __init dma_declare_contiguous(struct device *dev, phys_addr_t size,
-				  phys_addr_t base, phys_addr_t limit)
+int __init dma_contiguous_reserve_area(phys_addr_t size, phys_addr_t base,
+				       phys_addr_t limit, struct cma **res_cma)
 {
-	struct cma_reserved *r = &cma_reserved[cma_reserved_count];
 	phys_addr_t alignment;
+	int ret = 0;
 
 	pr_debug("%s(size %lx, base %08lx, limit %08lx)\n", __func__,
 		 (unsigned long)size, (unsigned long)base,
 		 (unsigned long)limit);
 
 	/* Sanity checks */
-	if (cma_reserved_count == ARRAY_SIZE(cma_reserved)) {
+	if (cma_area_count == ARRAY_SIZE(cma_areas)) {
 		pr_err("Not enough slots for CMA reserved regions!\n");
 		return -ENOSPC;
 	}
@@ -256,7 +214,7 @@ int __init dma_declare_contiguous(struct device *dev, phys_addr_t size,
 	if (base) {
 		if (memblock_is_region_reserved(base, size) ||
 		    memblock_reserve(base, size) < 0) {
-			base = -EBUSY;
+			ret = -EBUSY;
 			goto err;
 		}
 	} else {
@@ -266,7 +224,7 @@ int __init dma_declare_contiguous(struct device *dev, phys_addr_t size,
 		 */
 		phys_addr_t addr = __memblock_alloc_base(size, alignment, limit);
 		if (!addr) {
-			base = -ENOMEM;
+			ret = -ENOMEM;
 			goto err;
 		} else {
 			base = addr;
@@ -277,10 +235,11 @@ int __init dma_declare_contiguous(struct device *dev, phys_addr_t size,
 	 * Each reserved area must be initialised later, when more kernel
 	 * subsystems (like slab allocator) are available.
 	 */
-	r->start = base;
-	r->size = size;
-	r->dev = dev;
-	cma_reserved_count++;
+	cma_areas[cma_area_count].base_pfn = PFN_DOWN(base);
+	cma_areas[cma_area_count].count = size >> PAGE_SHIFT;
+	*res_cma = &cma_areas[cma_area_count];
+	cma_area_count++;
+
 	pr_info("CMA: reserved %ld MiB at %08lx\n", (unsigned long)size / SZ_1M,
 		(unsigned long)base);
 
@@ -289,10 +248,38 @@ int __init dma_declare_contiguous(struct device *dev, phys_addr_t size,
 	return 0;
 err:
 	pr_err("CMA: failed to reserve %ld MiB\n", (unsigned long)size / SZ_1M);
-	return base;
+	return ret;
 }
 
 /**
+ * dma_contiguous_add_device() - add device to custom contiguous reserved area
+ * @dev:   Pointer to device structure.
+ * @cma:   Pointer to the cma structure for the reserved area
+ *
+ * This function assigns the given device to the contiguous memory area
+ * reserved earlier by dma_contiguous_reserve_area() function.
+ */
+int __init dma_contiguous_add_device(struct device *dev, struct cma *cma)
+{
+	dev_set_cma_area(dev, cma);
+	return 0;
+}
+
+static int __init cma_init_reserved_areas(void)
+{
+	int i;
+
+	for (i = 0; i < cma_area_count; i++) {
+		int ret = cma_activate_area(&cma_areas[i]);
+		if (ret)
+			return ret;
+	}
+
+	return 0;
+}
+core_initcall(cma_init_reserved_areas);
+
+/**
  * dma_alloc_from_contiguous() - allocate pages from contiguous area
  * @dev:   Pointer to device for which the allocation is performed.
  * @count: Requested number of pages.
diff --git a/include/asm-generic/dma-contiguous.h b/include/asm-generic/dma-contiguous.h
index 294b1e7..8979f86 100644
--- a/include/asm-generic/dma-contiguous.h
+++ b/include/asm-generic/dma-contiguous.h
@@ -18,8 +18,6 @@ static inline void dev_set_cma_area(struct device *dev, struct cma *cma)
 {
 	if (dev)
 		dev->cma_area = cma;
-	if (!dev && !dma_contiguous_default_area)
-		dma_contiguous_default_area = cma;
 }
 
 #endif
diff --git a/include/linux/dma-contiguous.h b/include/linux/dma-contiguous.h
index 01b5c84..28c31fe 100644
--- a/include/linux/dma-contiguous.h
+++ b/include/linux/dma-contiguous.h
@@ -68,8 +68,36 @@ struct device;
 extern struct cma *dma_contiguous_default_area;
 
 void dma_contiguous_reserve(phys_addr_t addr_limit);
-int dma_declare_contiguous(struct device *dev, phys_addr_t size,
-			   phys_addr_t base, phys_addr_t limit);
+
+int __init dma_contiguous_reserve_area(phys_addr_t size, phys_addr_t base,
+				       phys_addr_t limit, struct cma **res_cma);
+
+int dma_contiguous_add_device(struct device *dev, struct cma *cma);
+
+/**
+ * dma_declare_contiguous() - reserve area for contiguous memory handling
+ *			      for particular device
+ * @dev:   Pointer to device structure.
+ * @size:  Size of the reserved memory.
+ * @base:  Start address of the reserved memory (optional, 0 for any).
+ * @limit: End address of the reserved memory (optional, 0 for any).
+ *
+ * This function reserves memory for specified device. It should be
+ * called by board specific code when early allocator (memblock or bootmem)
+ * is still activate.
+ */
+
+static inline int dma_declare_contiguous(struct device *dev, phys_addr_t size,
+					 phys_addr_t base, phys_addr_t limit)
+{
+	struct cma *cma;
+	int ret;
+	ret = dma_contiguous_reserve_area(size, base, limit, &cma);
+	if (ret == 0)
+		dma_contiguous_add_device(dev, cma);
+
+	return ret;
+}
 
 struct page *dma_alloc_from_contiguous(struct device *dev, int count,
 				       unsigned int order);
-- 
1.7.9.5



From hechtb at gmail.com  Thu Apr 11 07:23:57 2013
From: hechtb at gmail.com (Bastian Hecht)
Date: Thu, 11 Apr 2013 13:23:57 +0200
Subject: [PATCH v4 1/7] ARM: shmobile: Define DT bindings for timer devices
Message-ID: <1365679443-25456-1-git-send-email-hechtb+renesas@gmail.com>

The SH mobile series currently features 3 timer devices in the kernel:
Compare Match Timer (CMT), Timer Unit (TMU) and MTU2. These devices
share register layout characteristics amongst each that enable us to
define common DT bindings for them.

Signed-off-by: Bastian Hecht <hechtb+renesas at gmail.com>
---
v4: same. only patch 2 and 3 changed

 .../devicetree/bindings/timer/renesas,timer.txt    |   45 ++++++++++++++++++++
 1 file changed, 45 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/timer/renesas,timer.txt

diff --git a/Documentation/devicetree/bindings/timer/renesas,timer.txt b/Documentation/devicetree/bindings/timer/renesas,timer.txt
new file mode 100644
index 0000000..2c001bf
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/renesas,timer.txt
@@ -0,0 +1,45 @@
+* Renesas SH Mobile Timer
+
+Bindings for several timer devices from Renesas including CMT, TMU and MTU2.
+
+Required properties:
+- compatible : Should be "renesas,{device}-timer",
+  whereas device is "cmt", "tmu" or "mtu2".
+- reg : Address and length of the register set for the device
+- interrupts : Timer interrupt
+- renesas,device-id : The ID of the timer device
+- renesas,channel-id : The channel ID of the timer device
+- renesas,source-quality : The viability to use this device as a free
+  running clock. From 0 (do not use) to 10 (best possible clock).
+- renesas,event-quality : The viability to use this device as an event
+  generator. From 0 (do not use) to 10 (best possible clock).
+
+The properties renesas,{source,event}-quality reflect the situation that the
+usability of the timer devices depend on the location within their SoCs. E.g.
+the power domain affinty affects power management, some mux-ed lines might be
+preferred to be assigned to other functions and other constraints.
+
+Example for CMT1 channel 0 on the R8A7740 SoC:
+
+	timer at e6138010 {
+		compatible = "renesas,cmt-timer";
+		interrupt-parent = <&intca>;
+		reg = <0xe6138010 0xc>;
+		interrupts = <0x0b00>;
+		renesas,device-id = <1>;
+		renesas,channel-id = <0>;
+		renesas,source-quality = <3>;
+		renesas,event-quality = <3>;
+	};
+
+Example for TMU0 channel 1 on the SH7372 SoC:
+	timer at fff60014 {
+		compatible = "renesas,tmu-timer";
+		interrupt-parent = <&intcs>;
+		reg = <0xfff60014 0xc>;
+		interrupts = <0xea0>;
+		renesas,device-id = <0>;
+		renesas,channel-id = <1>;
+		renesas,source-quality = <4>;
+		renesas,event-quality = <0>;
+	};
-- 
1.7.9.5



From hechtb at gmail.com  Thu Apr 11 07:23:58 2013
From: hechtb at gmail.com (Bastian Hecht)
Date: Thu, 11 Apr 2013 13:23:58 +0200
Subject: [PATCH v4 2/7] clocksource: sh_cmt: Add OF support
In-Reply-To: <1365679443-25456-1-git-send-email-hechtb+renesas@gmail.com>
References: <1365679443-25456-1-git-send-email-hechtb+renesas@gmail.com>
Message-ID: <1365679443-25456-2-git-send-email-hechtb+renesas@gmail.com>

We add the capabilty to probe SH CMT timer devices using Device Tree
setup.

Signed-off-by: Bastian Hecht <hechtb+renesas at gmail.com>
---
v4:
Moved the assignments of p->channel_offset and p->timer_bit so that
they are ready as soon as setup_irq() is called

 drivers/clocksource/sh_cmt.c |  108 +++++++++++++++++++++++++++++++++++++-----
 1 file changed, 95 insertions(+), 13 deletions(-)

diff --git a/drivers/clocksource/sh_cmt.c b/drivers/clocksource/sh_cmt.c
index 08d0c41..66a12e9 100644
--- a/drivers/clocksource/sh_cmt.c
+++ b/drivers/clocksource/sh_cmt.c
@@ -34,10 +34,13 @@
 #include <linux/module.h>
 #include <linux/pm_domain.h>
 #include <linux/pm_runtime.h>
+#include <linux/of.h>
 
 struct sh_cmt_priv {
 	void __iomem *mapbase;
 	struct clk *clk;
+	long channel_offset;
+	int timer_bit;
 	unsigned long width; /* 16 or 32 bit version of hardware block */
 	unsigned long overflow_bit;
 	unsigned long clear_bits;
@@ -109,9 +112,7 @@ static void sh_cmt_write32(void __iomem *base, unsigned long offs,
 
 static inline unsigned long sh_cmt_read_cmstr(struct sh_cmt_priv *p)
 {
-	struct sh_timer_config *cfg = p->pdev->dev.platform_data;
-
-	return p->read_control(p->mapbase - cfg->channel_offset, 0);
+	return p->read_control(p->mapbase - p->channel_offset, 0);
 }
 
 static inline unsigned long sh_cmt_read_cmcsr(struct sh_cmt_priv *p)
@@ -127,9 +128,7 @@ static inline unsigned long sh_cmt_read_cmcnt(struct sh_cmt_priv *p)
 static inline void sh_cmt_write_cmstr(struct sh_cmt_priv *p,
 				      unsigned long value)
 {
-	struct sh_timer_config *cfg = p->pdev->dev.platform_data;
-
-	p->write_control(p->mapbase - cfg->channel_offset, 0, value);
+	p->write_control(p->mapbase - p->channel_offset, 0, value);
 }
 
 static inline void sh_cmt_write_cmcsr(struct sh_cmt_priv *p,
@@ -176,7 +175,6 @@ static DEFINE_RAW_SPINLOCK(sh_cmt_lock);
 
 static void sh_cmt_start_stop_ch(struct sh_cmt_priv *p, int start)
 {
-	struct sh_timer_config *cfg = p->pdev->dev.platform_data;
 	unsigned long flags, value;
 
 	/* start stop register shared by multiple timer channels */
@@ -184,9 +182,9 @@ static void sh_cmt_start_stop_ch(struct sh_cmt_priv *p, int start)
 	value = sh_cmt_read_cmstr(p);
 
 	if (start)
-		value |= 1 << cfg->timer_bit;
+		value |= 1 << p->timer_bit;
 	else
-		value &= ~(1 << cfg->timer_bit);
+		value &= ~(1 << p->timer_bit);
 
 	sh_cmt_write_cmstr(p, value);
 	raw_spin_unlock_irqrestore(&sh_cmt_lock, flags);
@@ -673,15 +671,93 @@ static int sh_cmt_register(struct sh_cmt_priv *p, char *name,
 	return 0;
 }
 
-static int sh_cmt_setup(struct sh_cmt_priv *p, struct platform_device *pdev)
+static const struct of_device_id of_sh_cmt_match[] = {
+	{ .compatible = "renesas,cmt-timer" },
+	{},
+};
+MODULE_DEVICE_TABLE(of, of_sh_cmt_match);
+
+static const int sh_cmt_offset_multiplier[] = { 0x60, 0x10, 0x40, 0x40, 0x40 };
+#define CMT_MAX_CHANNELS	6
+
+static struct sh_timer_config *sh_cmt_parse_dt(struct device *dev)
+{
+	struct sh_timer_config *cfg;
+	struct device_node *np = dev->of_node;
+	u32 timer_id, channel_id, rating;
+
+	if (!IS_ENABLED(CONFIG_OF) || !np)
+		return NULL;
+
+	cfg = devm_kzalloc(dev, sizeof(struct sh_timer_config), GFP_KERNEL);
+	if (!cfg) {
+		dev_err(dev, "failed to allocate DT config data\n");
+		return NULL;
+	}
+
+	if (of_property_read_u32(np, "renesas,device-id", &timer_id)) {
+		dev_err(dev, "device id missing\n");
+		return NULL;
+	}
+	if (timer_id >= ARRAY_SIZE(sh_cmt_offset_multiplier)) {
+		dev_err(dev, "invalid device id\n");
+		return NULL;
+	}
+
+	if (of_property_read_u32(np, "renesas,channel-id", &channel_id)) {
+		dev_err(dev, "channel id missing\n");
+		return NULL;
+	}
+	if (channel_id >= CMT_MAX_CHANNELS) {
+		dev_err(dev, "invalid channel id\n");
+		return NULL;
+	}
+
+	cfg->channel_offset = sh_cmt_offset_multiplier[timer_id] *
+							(channel_id + 1);
+	cfg->timer_bit = channel_id;
+
+	/*
+	 * We convert the {source,event}-quality DT properties to linux specific
+	 * clock{source,event}_ratings.
+	 */
+	if (!of_property_read_u32(np, "renesas,source-quality", &rating)) {
+		if (rating > 10) {
+			dev_err(dev, "invalid source-quality\n");
+			return NULL;
+		}
+		if (rating)
+			cfg->clocksource_rating = rating * 50 - 1;
+	}
+
+	if (!of_property_read_u32(np, "renesas,event-quality", &rating)) {
+		if (rating > 10) {
+			dev_err(dev, "invalid event-quality\n");
+			return NULL;
+		}
+		if (rating)
+			cfg->clockevent_rating = rating * 50 - 1;
+	}
+
+	if (!cfg->clocksource_rating && !cfg->clockevent_rating) {
+		dev_err(dev, "source- and event-quality 0, timer is unused\n");
+		return NULL;
+	}
+
+	return cfg;
+}
+
+static int sh_cmt_setup(struct sh_cmt_priv *p, struct platform_device *pdev,
+						struct sh_timer_config *cfg)
 {
-	struct sh_timer_config *cfg = pdev->dev.platform_data;
 	struct resource *res;
 	int irq, ret;
 	ret = -ENXIO;
 
 	memset(p, 0, sizeof(*p));
 	p->pdev = pdev;
+	p->channel_offset = cfg->channel_offset;
+	p->timer_bit = cfg->timer_bit;
 
 	if (!cfg) {
 		dev_err(&p->pdev->dev, "missing platform data\n");
@@ -777,7 +853,7 @@ err0:
 static int sh_cmt_probe(struct platform_device *pdev)
 {
 	struct sh_cmt_priv *p = platform_get_drvdata(pdev);
-	struct sh_timer_config *cfg = pdev->dev.platform_data;
+	struct sh_timer_config *cfg;
 	int ret;
 
 	if (!is_early_platform_device(pdev)) {
@@ -785,6 +861,11 @@ static int sh_cmt_probe(struct platform_device *pdev)
 		pm_runtime_enable(&pdev->dev);
 	}
 
+	if (pdev->dev.of_node)
+		cfg = sh_cmt_parse_dt(&pdev->dev);
+	else
+		cfg = pdev->dev.platform_data;
+
 	if (p) {
 		dev_info(&pdev->dev, "kept as earlytimer\n");
 		goto out;
@@ -796,7 +877,7 @@ static int sh_cmt_probe(struct platform_device *pdev)
 		return -ENOMEM;
 	}
 
-	ret = sh_cmt_setup(p, pdev);
+	ret = sh_cmt_setup(p, pdev, cfg);
 	if (ret) {
 		kfree(p);
 		pm_runtime_idle(&pdev->dev);
@@ -824,6 +905,7 @@ static struct platform_driver sh_cmt_device_driver = {
 	.remove		= sh_cmt_remove,
 	.driver		= {
 		.name	= "sh_cmt",
+		.of_match_table = of_match_ptr(of_sh_cmt_match),
 	}
 };
 
-- 
1.7.9.5



From hechtb at gmail.com  Thu Apr 11 07:24:00 2013
From: hechtb at gmail.com (Bastian Hecht)
Date: Thu, 11 Apr 2013 13:24:00 +0200
Subject: [PATCH v4 4/7] ARM: shmobile: sh73a0: Add timer DT names to clock list
In-Reply-To: <1365679443-25456-1-git-send-email-hechtb+renesas@gmail.com>
References: <1365679443-25456-1-git-send-email-hechtb+renesas@gmail.com>
Message-ID: <1365679443-25456-4-git-send-email-hechtb+renesas@gmail.com>

This adds temporarily the alternative device names to the clock list
that are used when booting via Device Tree setup.

Signed-off-by: Bastian Hecht <hechtb+renesas at gmail.com>
---
v4: same. only patches 2 and 3 are changed.

 arch/arm/mach-shmobile/clock-sh73a0.c |    3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/mach-shmobile/clock-sh73a0.c b/arch/arm/mach-shmobile/clock-sh73a0.c
index 784fbaa..5d98322 100644
--- a/arch/arm/mach-shmobile/clock-sh73a0.c
+++ b/arch/arm/mach-shmobile/clock-sh73a0.c
@@ -535,7 +535,9 @@ static struct clk_lookup lookups[] = {
 	CLKDEV_DEV_ID("sh_mobile_ceu.0", &mstp_clks[MSTP127]), /* CEU0 */
 	CLKDEV_DEV_ID("sh-mobile-csi2.0", &mstp_clks[MSTP126]), /* CSI2-RX0 */
 	CLKDEV_DEV_ID("sh_tmu.0", &mstp_clks[MSTP125]), /* TMU00 */
+	CLKDEV_DEV_ID("fff60008.timer", &mstp_clks[MSTP125]), /* TMU00 */
 	CLKDEV_DEV_ID("sh_tmu.1", &mstp_clks[MSTP125]), /* TMU01 */
+	CLKDEV_DEV_ID("fff60014.timer", &mstp_clks[MSTP125]), /* TMU01 */
 	CLKDEV_DEV_ID("sh-mipi-dsi.0", &mstp_clks[MSTP118]), /* DSITX */
 	CLKDEV_DEV_ID("i2c-sh_mobile.0", &mstp_clks[MSTP116]), /* I2C0 */
 	CLKDEV_DEV_ID("e6820000.i2c", &mstp_clks[MSTP116]), /* I2C0 */
@@ -552,6 +554,7 @@ static struct clk_lookup lookups[] = {
 	CLKDEV_DEV_ID("sh-sci.4", &mstp_clks[MSTP200]), /* SCIFA4 */
 	CLKDEV_DEV_ID("sh-sci.6", &mstp_clks[MSTP331]), /* SCIFA6 */
 	CLKDEV_DEV_ID("sh_cmt.10", &mstp_clks[MSTP329]), /* CMT10 */
+	CLKDEV_DEV_ID("e6138010.timer", &mstp_clks[MSTP329]), /* CMT10 */
 	CLKDEV_DEV_ID("sh_fsi2", &mstp_clks[MSTP328]), /* FSI */
 	CLKDEV_DEV_ID("sh_irda.0", &mstp_clks[MSTP325]), /* IrDA */
 	CLKDEV_DEV_ID("i2c-sh_mobile.1", &mstp_clks[MSTP323]), /* I2C1 */
-- 
1.7.9.5



From hechtb at gmail.com  Thu Apr 11 07:23:59 2013
From: hechtb at gmail.com (Bastian Hecht)
Date: Thu, 11 Apr 2013 13:23:59 +0200
Subject: [PATCH v4 3/7] clocksource: sh_tmu: Add OF support
In-Reply-To: <1365679443-25456-1-git-send-email-hechtb+renesas@gmail.com>
References: <1365679443-25456-1-git-send-email-hechtb+renesas@gmail.com>
Message-ID: <1365679443-25456-3-git-send-email-hechtb+renesas@gmail.com>

We add the capabilty to probe SH CMT timer devices using Device Tree
setup.

Signed-off-by: Bastian Hecht <hechtb+renesas at gmail.com>
---
v4:
Moved the assignments of p->channel_offset and p->timer_bit so that
they are ready as soon as setup_irq() is called.

 drivers/clocksource/sh_tmu.c |   96 +++++++++++++++++++++++++++++++++++++-----
 1 file changed, 85 insertions(+), 11 deletions(-)

diff --git a/drivers/clocksource/sh_tmu.c b/drivers/clocksource/sh_tmu.c
index 78b8dae..17bb607 100644
--- a/drivers/clocksource/sh_tmu.c
+++ b/drivers/clocksource/sh_tmu.c
@@ -34,10 +34,13 @@
 #include <linux/module.h>
 #include <linux/pm_domain.h>
 #include <linux/pm_runtime.h>
+#include <linux/of.h>
 
 struct sh_tmu_priv {
 	void __iomem *mapbase;
 	struct clk *clk;
+	long channel_offset;
+	int timer_bit;
 	struct irqaction irqaction;
 	struct platform_device *pdev;
 	unsigned long rate;
@@ -57,12 +60,11 @@ static DEFINE_RAW_SPINLOCK(sh_tmu_lock);
 
 static inline unsigned long sh_tmu_read(struct sh_tmu_priv *p, int reg_nr)
 {
-	struct sh_timer_config *cfg = p->pdev->dev.platform_data;
 	void __iomem *base = p->mapbase;
 	unsigned long offs;
 
 	if (reg_nr == TSTR)
-		return ioread8(base - cfg->channel_offset);
+		return ioread8(base - p->channel_offset);
 
 	offs = reg_nr << 2;
 
@@ -75,12 +77,11 @@ static inline unsigned long sh_tmu_read(struct sh_tmu_priv *p, int reg_nr)
 static inline void sh_tmu_write(struct sh_tmu_priv *p, int reg_nr,
 				unsigned long value)
 {
-	struct sh_timer_config *cfg = p->pdev->dev.platform_data;
 	void __iomem *base = p->mapbase;
 	unsigned long offs;
 
 	if (reg_nr == TSTR) {
-		iowrite8(value, base - cfg->channel_offset);
+		iowrite8(value, base - p->channel_offset);
 		return;
 	}
 
@@ -94,7 +95,6 @@ static inline void sh_tmu_write(struct sh_tmu_priv *p, int reg_nr,
 
 static void sh_tmu_start_stop_ch(struct sh_tmu_priv *p, int start)
 {
-	struct sh_timer_config *cfg = p->pdev->dev.platform_data;
 	unsigned long flags, value;
 
 	/* start stop register shared by multiple timer channels */
@@ -102,9 +102,9 @@ static void sh_tmu_start_stop_ch(struct sh_tmu_priv *p, int start)
 	value = sh_tmu_read(p, TSTR);
 
 	if (start)
-		value |= 1 << cfg->timer_bit;
+		value |= 1 << p->timer_bit;
 	else
-		value &= ~(1 << cfg->timer_bit);
+		value &= ~(1 << p->timer_bit);
 
 	sh_tmu_write(p, TSTR, value);
 	raw_spin_unlock_irqrestore(&sh_tmu_lock, flags);
@@ -421,15 +421,83 @@ static int sh_tmu_register(struct sh_tmu_priv *p, char *name,
 	return 0;
 }
 
-static int sh_tmu_setup(struct sh_tmu_priv *p, struct platform_device *pdev)
+static const struct of_device_id of_sh_tmu_match[] = {
+	{ .compatible = "renesas,tmu-timer" },
+	{},
+};
+MODULE_DEVICE_TABLE(of, of_sh_tmu_match);
+
+#define TMU_OFFSET_MULTIPLIER	0xc
+#define TMU_MAX_CHANNELS	3
+
+static struct sh_timer_config *sh_tmu_parse_dt(struct device *dev)
+{
+	struct sh_timer_config *cfg;
+	struct device_node *np = dev->of_node;
+	u32 channel_id, rating;
+
+	if (!IS_ENABLED(CONFIG_OF) || !np)
+		return NULL;
+
+	cfg = devm_kzalloc(dev, sizeof(struct sh_timer_config), GFP_KERNEL);
+	if (!cfg) {
+		dev_err(dev, "failed to allocate DT config data\n");
+		return NULL;
+	}
+
+	if (of_property_read_u32(np, "renesas,channel-id", &channel_id)) {
+		dev_err(dev, "channel id missing\n");
+		return NULL;
+	}
+	if (channel_id >= TMU_MAX_CHANNELS) {
+		dev_err(dev, "invalid channel id\n");
+		return NULL;
+	}
+
+	cfg->channel_offset = channel_id * TMU_OFFSET_MULTIPLIER + 4;
+	cfg->timer_bit = channel_id;
+
+	/*
+	 * We convert the {source,event}-quality DT properties to linux specific
+	 * clock{source,event}_ratings.
+	 */
+	if (!of_property_read_u32(np, "renesas,source-quality", &rating)) {
+		if (rating > 10) {
+			dev_err(dev, "invalid source-quality\n");
+			return NULL;
+		}
+		if (rating)
+			cfg->clocksource_rating = rating * 50 - 1;
+	}
+
+	if (!of_property_read_u32(np, "renesas,event-quality", &rating)) {
+		if (rating > 10) {
+			dev_err(dev, "invalid event-quality\n");
+			return NULL;
+		}
+		if (rating)
+			cfg->clockevent_rating = rating * 50 - 1;
+	}
+
+	if (!cfg->clocksource_rating && !cfg->clockevent_rating) {
+		dev_err(dev, "source- and event-quality 0, timer is unused\n");
+		return NULL;
+	}
+
+	return cfg;
+}
+
+static int sh_tmu_setup(struct sh_tmu_priv *p, struct platform_device *pdev,
+						struct sh_timer_config *cfg)
 {
-	struct sh_timer_config *cfg = pdev->dev.platform_data;
 	struct resource *res;
 	int irq, ret;
 	ret = -ENXIO;
 
 	memset(p, 0, sizeof(*p));
 	p->pdev = pdev;
+	p->channel_offset = cfg->channel_offset;
+	p->timer_bit = cfg->timer_bit;
 
 	if (!cfg) {
 		dev_err(&p->pdev->dev, "missing platform data\n");
@@ -487,7 +555,7 @@ static int sh_tmu_setup(struct sh_tmu_priv *p, struct platform_device *pdev)
 static int sh_tmu_probe(struct platform_device *pdev)
 {
 	struct sh_tmu_priv *p = platform_get_drvdata(pdev);
-	struct sh_timer_config *cfg = pdev->dev.platform_data;
+	struct sh_timer_config *cfg;
 	int ret;
 
 	if (!is_early_platform_device(pdev)) {
@@ -495,6 +563,11 @@ static int sh_tmu_probe(struct platform_device *pdev)
 		pm_runtime_enable(&pdev->dev);
 	}
 
+	if (pdev->dev.of_node)
+		cfg = sh_tmu_parse_dt(&pdev->dev);
+	else
+		cfg = pdev->dev.platform_data;
+
 	if (p) {
 		dev_info(&pdev->dev, "kept as earlytimer\n");
 		goto out;
@@ -506,7 +579,7 @@ static int sh_tmu_probe(struct platform_device *pdev)
 		return -ENOMEM;
 	}
 
-	ret = sh_tmu_setup(p, pdev);
+	ret = sh_tmu_setup(p, pdev, cfg);
 	if (ret) {
 		kfree(p);
 		platform_set_drvdata(pdev, NULL);
@@ -535,6 +608,7 @@ static struct platform_driver sh_tmu_device_driver = {
 	.remove		= sh_tmu_remove,
 	.driver		= {
 		.name	= "sh_tmu",
+		.of_match_table = of_sh_tmu_match,
 	}
 };
 
-- 
1.7.9.5



From hechtb at gmail.com  Thu Apr 11 07:24:02 2013
From: hechtb at gmail.com (Bastian Hecht)
Date: Thu, 11 Apr 2013 13:24:02 +0200
Subject: [PATCH v4 6/7] ARM: shmobile: r8a7740: Add DT name to clock list for
 CMT10
In-Reply-To: <1365679443-25456-1-git-send-email-hechtb+renesas@gmail.com>
References: <1365679443-25456-1-git-send-email-hechtb+renesas@gmail.com>
Message-ID: <1365679443-25456-6-git-send-email-hechtb+renesas@gmail.com>

This adds temporarily the alternative device name to the clock list
that is used when booting via Device Tree setup.

Signed-off-by: Bastian Hecht <hechtb+renesas at gmail.com>
---
v4: same. only patch 2 and 3 changed

 arch/arm/mach-shmobile/clock-r8a7740.c |    1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-shmobile/clock-r8a7740.c b/arch/arm/mach-shmobile/clock-r8a7740.c
index 5bd8da0..8fc396a 100644
--- a/arch/arm/mach-shmobile/clock-r8a7740.c
+++ b/arch/arm/mach-shmobile/clock-r8a7740.c
@@ -582,6 +582,7 @@ static struct clk_lookup lookups[] = {
 	CLKDEV_DEV_ID("e6cc0000.sci",		&mstp_clks[MSTP230]),
 
 	CLKDEV_DEV_ID("sh_cmt.10",		&mstp_clks[MSTP329]),
+	CLKDEV_DEV_ID("e6138010.timer",		&mstp_clks[MSTP329]),
 	CLKDEV_DEV_ID("sh_fsi2",		&mstp_clks[MSTP328]),
 	CLKDEV_DEV_ID("i2c-sh_mobile.1",	&mstp_clks[MSTP323]),
 	CLKDEV_DEV_ID("renesas_usbhs",		&mstp_clks[MSTP320]),
-- 
1.7.9.5



From hechtb at gmail.com  Thu Apr 11 07:24:01 2013
From: hechtb at gmail.com (Bastian Hecht)
Date: Thu, 11 Apr 2013 13:24:01 +0200
Subject: [PATCH v4 5/7] ARM: mach-shmobile: sh73a0: Setup the timer CMT10
 using DT
In-Reply-To: <1365679443-25456-1-git-send-email-hechtb+renesas@gmail.com>
References: <1365679443-25456-1-git-send-email-hechtb+renesas@gmail.com>
Message-ID: <1365679443-25456-5-git-send-email-hechtb+renesas@gmail.com>

We can now use the Device Tree for bringing up our timer device CMT10 on
the SoC sh73a0.

Signed-off-by: Bastian Hecht <hechtb+renesas at gmail.com>
---
v4: same. only patch 2 and 3 changed

 arch/arm/boot/dts/sh73a0.dtsi         |   11 +++++++++++
 arch/arm/mach-shmobile/setup-sh73a0.c |   32 --------------------------------
 2 files changed, 11 insertions(+), 32 deletions(-)

diff --git a/arch/arm/boot/dts/sh73a0.dtsi b/arch/arm/boot/dts/sh73a0.dtsi
index ec40bf7..67b5089 100644
--- a/arch/arm/boot/dts/sh73a0.dtsi
+++ b/arch/arm/boot/dts/sh73a0.dtsi
@@ -222,4 +222,15 @@
 		cap-sd-highspeed;
 		status = "disabled";
 	};
+
+	timer at e6138010 {
+		compatible = "renesas,cmt-timer";
+		interrupt-parent = <&gic>;
+		reg = <0xe6138010 0xc>;
+		interrupts = <0 65 0x4>;
+		renesas,device-id = <1>;
+		renesas,channel-id = <0>;
+		renesas,source-quality = <3>;
+		renesas,event-quality = <3>;
+	};
 };
diff --git a/arch/arm/mach-shmobile/setup-sh73a0.c b/arch/arm/mach-shmobile/setup-sh73a0.c
index d10ded0..024b7a6 100644
--- a/arch/arm/mach-shmobile/setup-sh73a0.c
+++ b/arch/arm/mach-shmobile/setup-sh73a0.c
@@ -235,37 +235,6 @@ static struct platform_device scif8_device = {
 	},
 };
 
-static struct sh_timer_config cmt10_platform_data = {
-	.name = "CMT10",
-	.channel_offset = 0x10,
-	.timer_bit = 0,
-	.clockevent_rating = 125,
-	.clocksource_rating = 125,
-};
-
-static struct resource cmt10_resources[] = {
-	[0] = {
-		.name	= "CMT10",
-		.start	= 0xe6138010,
-		.end	= 0xe613801b,
-		.flags	= IORESOURCE_MEM,
-	},
-	[1] = {
-		.start	= gic_spi(65),
-		.flags	= IORESOURCE_IRQ,
-	},
-};
-
-static struct platform_device cmt10_device = {
-	.name		= "sh_cmt",
-	.id		= 10,
-	.dev = {
-		.platform_data	= &cmt10_platform_data,
-	},
-	.resource	= cmt10_resources,
-	.num_resources	= ARRAY_SIZE(cmt10_resources),
-};
-
 /* TMU */
 static struct sh_timer_config tmu00_platform_data = {
 	.name = "TMU00",
@@ -930,7 +899,6 @@ static struct platform_device *sh73a0_devices_dt[] __initdata = {
 	&scif6_device,
 	&scif7_device,
 	&scif8_device,
-	&cmt10_device,
 };
 
 static struct platform_device *sh73a0_early_devices[] __initdata = {
-- 
1.7.9.5



From hechtb at gmail.com  Thu Apr 11 07:24:03 2013
From: hechtb at gmail.com (Bastian Hecht)
Date: Thu, 11 Apr 2013 13:24:03 +0200
Subject: [PATCH v4 7/7] ARM: mach-shmobile: r8a7740: Setup the timer CMT10
 using DT
In-Reply-To: <1365679443-25456-1-git-send-email-hechtb+renesas@gmail.com>
References: <1365679443-25456-1-git-send-email-hechtb+renesas@gmail.com>
Message-ID: <1365679443-25456-7-git-send-email-hechtb+renesas@gmail.com>

We can now use the Device Tree for bringing up our timer device CMT10 on
the SoC r8a7740.

Signed-off-by: Bastian Hecht <hechtb+renesas at gmail.com>
---
v4: same. only patch 2 and 3 changed

 arch/arm/mach-shmobile/setup-r8a7740.c |   33 --------------------------------
 1 file changed, 33 deletions(-)

diff --git a/arch/arm/mach-shmobile/setup-r8a7740.c b/arch/arm/mach-shmobile/setup-r8a7740.c
index c2ac4aa..e88b50d 100644
--- a/arch/arm/mach-shmobile/setup-r8a7740.c
+++ b/arch/arm/mach-shmobile/setup-r8a7740.c
@@ -363,38 +363,6 @@ static struct platform_device scifb_device = {
 	},
 };
 
-/* CMT */
-static struct sh_timer_config cmt10_platform_data = {
-	.name = "CMT10",
-	.channel_offset = 0x10,
-	.timer_bit = 0,
-	.clockevent_rating = 125,
-	.clocksource_rating = 125,
-};
-
-static struct resource cmt10_resources[] = {
-	[0] = {
-		.name	= "CMT10",
-		.start	= 0xe6138010,
-		.end	= 0xe613801b,
-		.flags	= IORESOURCE_MEM,
-	},
-	[1] = {
-		.start	= gic_spi(58),
-		.flags	= IORESOURCE_IRQ,
-	},
-};
-
-static struct platform_device cmt10_device = {
-	.name		= "sh_cmt",
-	.id		= 10,
-	.dev = {
-		.platform_data	= &cmt10_platform_data,
-	},
-	.resource	= cmt10_resources,
-	.num_resources	= ARRAY_SIZE(cmt10_resources),
-};
-
 /* TMU */
 static struct sh_timer_config tmu00_platform_data = {
 	.name = "TMU00",
@@ -531,7 +499,6 @@ static struct platform_device *r8a7740_early_devices[] __initdata = {
 	&scif6_device,
 	&scif7_device,
 	&scifb_device,
-	&cmt10_device,
 	&tmu00_device,
 	&tmu01_device,
 	&tmu02_device,
-- 
1.7.9.5



From mark.rutland at arm.com  Thu Apr 11 07:24:07 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Thu, 11 Apr 2013 12:24:07 +0100
Subject: [PATCH 1/4] Documentation: Add memory mapped ARM architected
 timer binding
In-Reply-To: <51662584.6070906@codeaurora.org>
References: <1365474623-29181-1-git-send-email-sboyd@codeaurora.org>
 <1365474623-29181-2-git-send-email-sboyd@codeaurora.org>
 <20130409090843.GS23725@e106331-lin.cambridge.arm.com>
 <516444FE.2080200@codeaurora.org>
 <20130410101336.GB8799@e106331-lin.cambridge.arm.com>
 <51662584.6070906@codeaurora.org>
Message-ID: <20130411112407.GD8259@e106331-lin.cambridge.arm.com>

On Thu, Apr 11, 2013 at 03:52:52AM +0100, Stephen Boyd wrote:
> On 04/10/13 03:13, Mark Rutland wrote:
> >>>> +
> >>>> +- #size-cells : Must be 1.
> >>>> +
> >>>> +- ranges : Indicates parent and child bus address space are the same.
> >>>> +
> >>> Similarly, what if someone wants to write a more complex mapping for some
> >>> reason?
> >>>
> >>> We should be able to handle it if we use the standard accessors.
> >> Maybe I should just leave this part out? They are standard DT properties
> >> so I could assume DT writers know what to do.
> > I'd be happy with that. It may be worth describing them as "as necessary" or
> > something to that effect.
> 
> Ok. I added this and removed the property descriptions:
> 
> Note that #address-cells, #size-cells, and ranges shall be present to ensure
> the CPU can address a frame's registers.

Sounds good to me.

> 
> > I can see why we need to specify secure/non-secure, but I'm not sure why we
> > need to specify hyp/user/kernel usage. Could we not leave this up to the kernel
> > to figure out?
> >
> > A basic overveiew for those that don't know about the memory mapped timers:
> >
> > * There's one control frame CNTCTLBase. Some registers in this frame are only
> >   available for secure accesses, including CNTNSAR which sets whether the
> >   counter frames are accessible from the non-secure side.
> >
> > * There are up to 8 timer frames, which have their own CNTVOFF and
> >   physical/virtual timers. Each frame CNTBaseN is duplicated at CNTPL0BaseN
> >   with CNTVOFF and CNTPL0ACR (which controls PL0 accesses) inaccessible.
> >
> > I can see that we might have frames/registers we can't access (if we were
> > booted on the non-secure side), but I can't see anything limiting whether we
> > use a frame for kernel/hyp/user beyond that. Have I missed something?
> >
> > Could we not have something like the following for each frame:
> >
> > frame0 {
> > 	frame-id = <0>;
> > 	status = "disabled"; /* booted NS, secure firmware has not enabled access */
> > 	reg = <0x... 0x1000>, /* CNTBase0 */
> > 	      <0x... 0x1000>; /* CNTPL0Base0 */
> > };
> >
> 
> I don't think you're missing anything. Technically the second view is
> not always implemented though. Using the status property should be
> sufficient I think.

Could we say the reg for the second view is optional?

Might we have a hardware / firmware configuration where the kernel can only access
the secondary view?

> 
> >> Also to get the frame number, I was thinking maybe we should expand the
> >> reg property to have two address cells. Then we could have reg = <0
> >> 0xf0001000 0x1000>.
> > We could do that, but then you definitely need a more complex ranges property,
> > and additional parsing code to handle grabbing it out of the reg property. I
> > can't see what it buys us.
> 
> Ok. It would mandate node names like "frame at 0", "frame at 1", but I'll drop
> the idea unless someone else finds it useful.

I see. I'd prefer to use a separate property for the id. Placing it in the reg
and then requiring a mapping sounds like it's going to cause a lot of pain.

Cheers,
Mark.


From m.szyprowski at samsung.com  Thu Apr 11 07:22:10 2013
From: m.szyprowski at samsung.com (Marek Szyprowski)
Date: Thu, 11 Apr 2013 13:22:10 +0200
Subject: [RFC/PATCH v2 2/2] drivers: dma-contiguous: add initialization from
 device tree
In-Reply-To: <1365679330-2514-1-git-send-email-m.szyprowski@samsung.com>
References: <1365679330-2514-1-git-send-email-m.szyprowski@samsung.com>
Message-ID: <1365679330-2514-3-git-send-email-m.szyprowski@samsung.com>

Add device tree support for contiguous memory regions defined in device
tree. Initialization is done in 2 steps. First, the contiguous memory is
reserved, what happens very early, when only flattened device tree is
available. Then on device initialization the corresponding cma regions are
assigned to device structures.

Signed-off-by: Marek Szyprowski <m.szyprowski at samsung.com>
Acked-by: Kyungmin Park <kyungmin.park at samsung.com>
---
 .../devicetree/bindings/contiguous-memory.txt      |   69 +++++++++++
 arch/arm/boot/dts/skeleton.dtsi                    |    8 +-
 drivers/base/dma-contiguous.c                      |  124 ++++++++++++++++++++
 3 files changed, 200 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/contiguous-memory.txt

diff --git a/Documentation/devicetree/bindings/contiguous-memory.txt b/Documentation/devicetree/bindings/contiguous-memory.txt
new file mode 100644
index 0000000..fa598bf
--- /dev/null
+++ b/Documentation/devicetree/bindings/contiguous-memory.txt
@@ -0,0 +1,69 @@
+* Contiguous memory binding
+
+The /chosen/contiguous-memory node provides runtime configuration of
+contiguous memory regions for Linux kernel. One can create such regions
+for special usage by various device drivers. A good example are
+contiguous memory allocations or memory sharing with other operating
+system on the same hardware board. Those special memory regions might
+depend on the board configuration and devices used on the target system.
+
+Parameters for each memory region can be encoded into the device tree
+wit the following convention:
+
+contiguous-memory {
+
+	(name): region@(base-address) {
+		reg = <(baseaddr) (size)>;
+		(linux,default-contiguous-region);
+		device = <&device_0 &device_1 ...>
+	};
+};
+
+name:		an name given to the defined region.
+base-address:	the base address of the defined region.
+size:		the size of the memory region (bytes).
+linux,default-contiguous-region: property indicating that the region
+		is the default region for all contiguous memory
+		allocations, Linux specific (optional)
+device:		array of phandles to the client device nodes, which use
+		the given contiguous region
+
+* Example:
+
+This example defines a memory configuration containing 2 contiguous
+regions for Linux kernel, one default of all device drivers (named
+contig_mem, placed at 0x72000000, 64MiB) and one dedicated to the
+framebuffer device (named display_mem, placed at 0x78000000, 16MiB). The
+display_mem region is then assigned to fb at 12300000 device for contiguous
+memory allocation with Linux kernel drivers.
+
+The reason for creating a separate region for framebuffer device is to
+match the framebuffer address of from configuration done by bootloader,
+so once Linux kernel drivers starts, no glitches on the displayed boot
+logo appears.
+
+/ {
+	/* ... */
+
+	chosen {
+		bootargs = /* ... */
+
+		contiguous-memory {
+			contig_mem: region at 72000000 {
+				reg = <0x72000000 0x4000000>;
+				linux,default-contiguous-region;
+			};
+
+			display_mem: region at 78000000 {
+				reg = <0x78000000 0x1000000>;
+				device = <&fb0>;
+			};
+		};
+	};
+
+	/* ... */
+
+	fb0: fb at 12300000 {
+		status = "okay";
+	};
+};
diff --git a/arch/arm/boot/dts/skeleton.dtsi b/arch/arm/boot/dts/skeleton.dtsi
index b41d241..538a868 100644
--- a/arch/arm/boot/dts/skeleton.dtsi
+++ b/arch/arm/boot/dts/skeleton.dtsi
@@ -7,7 +7,13 @@
 / {
 	#address-cells = <1>;
 	#size-cells = <1>;
-	chosen { };
+	chosen {
+		contiguous-memory {
+			#address-cells = <1>;
+			#size-cells = <1>;
+		};
+	};
 	aliases { };
 	memory { device_type = "memory"; reg = <0 0>; };
 };
+
diff --git a/drivers/base/dma-contiguous.c b/drivers/base/dma-contiguous.c
index 01fe743..6a8abab 100644
--- a/drivers/base/dma-contiguous.c
+++ b/drivers/base/dma-contiguous.c
@@ -24,6 +24,9 @@
 
 #include <linux/memblock.h>
 #include <linux/err.h>
+#include <linux/of.h>
+#include <linux/of_fdt.h>
+#include <linux/of_platform.h>
 #include <linux/mm.h>
 #include <linux/mutex.h>
 #include <linux/page-isolation.h>
@@ -37,6 +40,7 @@ struct cma {
 	unsigned long	base_pfn;
 	unsigned long	count;
 	unsigned long	*bitmap;
+	char		full_name[32];
 };
 
 static DEFINE_MUTEX(cma_mutex);
@@ -133,6 +137,53 @@ static __init int cma_activate_area(struct cma *cma)
 	return 0;
 }
 
+/*****************************************************************************/
+
+#ifdef CONFIG_OF
+int __init cma_fdt_scan(unsigned long node, const char *uname,
+				int depth, void *data)
+{
+	static int level;
+	phys_addr_t base, size;
+	unsigned long len;
+	struct cma *cma;
+	__be32 *prop;
+
+	if (depth == 1 && strcmp(uname, "chosen") == 0) {
+		level = depth;
+		return 0;
+	}
+
+	if (depth == 2 && strcmp(uname, "contiguous-memory") == 0) {
+		level = depth;
+		return 0;
+	}
+
+	if (level != 2 || depth != 3 || strncmp(uname, "region@", 7) != 0)
+		return 0;
+
+	prop = of_get_flat_dt_prop(node, "reg", &len);
+	if (!prop || (len != 2 * sizeof(unsigned long)))
+		return 0;
+
+	base = be32_to_cpu(prop[0]);
+	size = be32_to_cpu(prop[1]);
+
+	pr_info("Found %s, memory base %lx, size %ld MiB\n", uname,
+		(unsigned long)base, (unsigned long)size / SZ_1M);
+
+	dma_contiguous_reserve_area(size, base, 0, &cma);
+
+	strcpy(cma->full_name, uname);
+
+	if (of_get_flat_dt_prop(node, "linux,default-contiguous-region", NULL)) {
+
+		dma_contiguous_default_area = cma;
+	}
+	return 0;
+}
+#endif
+
 /**
  * dma_contiguous_reserve() - reserve area(s) for contiguous memory handling
  * @limit: End address of the reserved memory (optional, 0 for any).
@@ -149,6 +200,10 @@ void __init dma_contiguous_reserve(phys_addr_t limit)
 
 	pr_debug("%s(limit %08lx)\n", __func__, (unsigned long)limit);
 
+#ifdef CONFIG_OF
+	of_scan_flat_dt(cma_fdt_scan, NULL);
+#endif
+
 	if (size_cmdline != -1) {
 		sel_size = size_cmdline;
 	} else {
@@ -265,6 +320,71 @@ int __init dma_contiguous_add_device(struct device *dev, struct cma *cma)
 	return 0;
 }
 
+#ifdef CONFIG_OF
+static struct cma_map {
+	struct cma *cma;
+	struct device_node *node;
+} cma_maps[MAX_CMA_AREAS];
+static unsigned cma_map_count;
+
+static void cma_assign_device_from_dt(struct device *dev)
+{
+	int i;
+	for (i=0; i<cma_map_count; i++) {
+		if (cma_maps[i].node == dev->of_node) {
+			dev_set_cma_area(dev, cma_maps[i].cma);
+			pr_info("Assigned CMA %s to %s device\n",
+				cma_maps[i].cma->full_name,
+				dev_name(dev));
+		}
+	}
+}
+
+static int cma_device_init_notifier_call(struct notifier_block *nb,
+					 unsigned long event, void *data)
+{
+	struct device *dev = data;
+	if (event == BUS_NOTIFY_ADD_DEVICE && dev->of_node)
+		cma_assign_device_from_dt(dev);
+	return NOTIFY_DONE;
+}
+
+static struct notifier_block cma_dev_init_nb = {
+	.notifier_call = cma_device_init_notifier_call,
+};
+
+void scan_cma_nodes(void)
+{
+	struct device_node *parent = of_find_node_by_path("/chosen/contiguous-memory");
+	struct device_node *child;
+
+	if (!parent)
+		return;
+
+	for_each_child_of_node(parent, child) {
+		struct cma *cma = NULL;
+		int i;
+
+		for (i=0; i<cma_area_count; i++)
+			if (strstr(child->full_name, cma_areas[i].full_name))
+				cma = &cma_areas[i];
+		if (!cma)
+			continue;
+
+		for (i=0;; i++) {
+			struct device_node *node;
+			node = of_parse_phandle(child, "device", i);
+			if (!node)
+				break;
+
+			cma_maps[cma_map_count].cma = cma;
+			cma_maps[cma_map_count].node = node;
+			cma_map_count++;
+		}
+	}
+}
+#endif
+
 static int __init cma_init_reserved_areas(void)
 {
 	int i;
@@ -275,6 +395,10 @@ static int __init cma_init_reserved_areas(void)
 			return ret;
 	}
 
+#ifdef CONFIG_OF
+	scan_cma_nodes();
+	bus_register_notifier(&platform_bus_type, &cma_dev_init_nb);
+#endif
 	return 0;
 }
 core_initcall(cma_init_reserved_areas);
-- 
1.7.9.5



From thomas.ab at samsung.com  Thu Apr 11 07:44:53 2013
From: thomas.ab at samsung.com (Thomas Abraham)
Date: Thu, 11 Apr 2013 17:14:53 +0530
Subject: [PATCH] ARM: dts: add ohci and ehci controller nodes for Exynos5440
 SoC
Message-ID: <1365680693-22449-1-git-send-email-thomas.ab@samsung.com>

Exynos5440 includes both OHCI and EHCI usb host controllers. Add device tree
nodes for both of these controllers.

Signed-off-by: Thomas Abraham <thomas.ab at samsung.com>
---
 arch/arm/boot/dts/exynos5440.dtsi |   15 +++++++++++++++
 1 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5440.dtsi b/arch/arm/boot/dts/exynos5440.dtsi
index 0607ae5..4448b55 100644
--- a/arch/arm/boot/dts/exynos5440.dtsi
+++ b/arch/arm/boot/dts/exynos5440.dtsi
@@ -208,4 +208,19 @@
 		clock-names = "sata";
 	};
 
+	ohci at 220000 {
+		compatible = "samsung,exynos5440-ohci";
+		reg = <0x220000 0x1000>;
+		interrupts = <0 29 0>;
+		clocks = <&clock 11>;
+		clock-names = "usbhost";
+	};
+
+	ehci at 221000 {
+		compatible = "samsung,exynos5440-ehci";
+		reg = <0x221000 0x1000>;
+		interrupts = <0 29 0>;
+		clocks = <&clock 11>;
+		clock-names = "usbhost";
+	};
 };
-- 
1.6.6.rc2



From pgaikwad at nvidia.com  Thu Apr 11 07:40:55 2013
From: pgaikwad at nvidia.com (Prashant Gaikwad)
Date: Thu, 11 Apr 2013 17:10:55 +0530
Subject: [PATCH 1/3] clk: composite: rename 'div' references to 'rate'
In-Reply-To: <1365631378-16103-2-git-send-email-mturquette@linaro.org>
References: <1365515284-32061-2-git-send-email-emilio@elopez.com.ar>
 <1365631378-16103-1-git-send-email-mturquette@linaro.org>
 <1365631378-16103-2-git-send-email-mturquette@linaro.org>
Message-ID: <5166A147.1050505@nvidia.com>

On Thursday 11 April 2013 03:32 AM, Mike Turquette wrote:
> Rename all div_hw and div_ops related variables and functions to use
> rate_hw, rate_ops, etc.  This is to make the rate-change portion of the
> composite clk implementation more generic.  A patch following this one
> will allow for fixed-rate clocks to reuse this infrastructure.
>
> Signed-off-by: Mike Turquette <mturquette at linaro.org>
> Cc: Prashant Gaikwad <pgaikwad at nvidia.com>
> Cc: Emilio L?pez <emilio at elopez.com.ar>
> Cc: Gregory CLEMENT <gregory.clement at free-electrons.com>
> ---
>   drivers/clk/clk-composite.c  |   40 ++++++++++++++++++++--------------------
>   include/linux/clk-provider.h |   14 +++++++-------
>   2 files changed, 27 insertions(+), 27 deletions(-)
>
<snip>

>   
>   	if (composite->gate_hw)
>   		composite->gate_hw->clk = clk;
> diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
> index 9fdfae7..f5ba8c5 100644
> --- a/include/linux/clk-provider.h
> +++ b/include/linux/clk-provider.h
> @@ -352,11 +352,11 @@ struct clk *clk_register_fixed_factor(struct device *dev, const char *name,
>    * struct clk_composite - aggregate clock of mux, divider and gate clocks
>    *
>    * @hw:		handle between common and hardware-specific interfaces
> - * @mux_hw:	handle between composite and hardware-specifix mux clock
> - * @div_hw:	handle between composite and hardware-specifix divider clock
> - * @gate_hw:	handle between composite and hardware-specifix gate clock
> + * @mux_hw:	handle between composite and hardware-specific mux clock
> + * @rate_hw:	handle between composite and hardware-specific rateider clock

Small nitpick s/rateider/rate

Reviewed-by: Prashant Gaikwad <pgaikwad at nvidia.com>

> + * @gate_hw:	handle between composite and hardware-specific gate clock
>    * @mux_ops:	clock ops for mux
> - * @div_ops:	clock ops for divider
> + * @rate_ops:	clock ops for rateider
>    * @gate_ops:	clock ops for gate
>    */
>   struct clk_composite {
> @@ -364,18 +364,18 @@ struct clk_composite {
>   	struct clk_ops	ops;
>   
>   	struct clk_hw	*mux_hw;
> -	struct clk_hw	*div_hw;
> +	struct clk_hw	*rate_hw;
>   	struct clk_hw	*gate_hw;
>   
>   	const struct clk_ops	*mux_ops;
> -	const struct clk_ops	*div_ops;
> +	const struct clk_ops	*rate_ops;
>   	const struct clk_ops	*gate_ops;
>   };
>   
>   struct clk *clk_register_composite(struct device *dev, const char *name,
>   		const char **parent_names, int num_parents,
>   		struct clk_hw *mux_hw, const struct clk_ops *mux_ops,
> -		struct clk_hw *div_hw, const struct clk_ops *div_ops,
> +		struct clk_hw *rate_hw, const struct clk_ops *rate_ops,
>   		struct clk_hw *gate_hw, const struct clk_ops *gate_ops,
>   		unsigned long flags);
>   



From pgaikwad at nvidia.com  Thu Apr 11 07:47:50 2013
From: pgaikwad at nvidia.com (Prashant Gaikwad)
Date: Thu, 11 Apr 2013 17:17:50 +0530
Subject: [PATCH 2/3] clk: composite: allow fixed rates & fixed dividers
In-Reply-To: <1365631378-16103-3-git-send-email-mturquette@linaro.org>
References: <1365515284-32061-2-git-send-email-emilio@elopez.com.ar>
 <1365631378-16103-1-git-send-email-mturquette@linaro.org>
 <1365631378-16103-3-git-send-email-mturquette@linaro.org>
Message-ID: <5166A2E6.70907@nvidia.com>

On Thursday 11 April 2013 03:32 AM, Mike Turquette wrote:
> The composite clock assumes that any clock implementing the .recalc_rate
> callback will also implement .round_rate and .set_rate.  This is not
> always true; the basic fixed-rate clock will only implement .recalc_rate
> and a fixed-divider clock may choose to implement .recalc_rate and
> .round_rate but not .set_rate.
>
> Fix this by conditionally registering .round_rate and .set_rate
> callbacks based on the rate_ops passed in to clk_composite_register.
>
> Signed-off-by: Mike Turquette <mturquette at linaro.org>
> Cc: Prashant Gaikwad <pgaikwad at nvidia.com>
> Cc: Emilio L?pez <emilio at elopez.com.ar>
> Cc: Gregory CLEMENT <gregory.clement at free-electrons.com>
> ---
>   drivers/clk/clk-composite.c |   13 +++++++++----
>   1 file changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/clk/clk-composite.c b/drivers/clk/clk-composite.c
> index 6f4728c..2779fb3 100644
> --- a/drivers/clk/clk-composite.c
> +++ b/drivers/clk/clk-composite.c
> @@ -150,17 +150,22 @@ struct clk *clk_register_composite(struct device *dev, const char *name,
>   	}
>   
>   	if (rate_hw && rate_ops) {
> -		if (!rate_ops->recalc_rate || !rate_ops->round_rate ||
> -		    !rate_ops->set_rate) {
> +		if (!rate_ops->recalc_rate) {
>   			clk = ERR_PTR(-EINVAL);
>   			goto err;
>   		}
>   
> +		/* .round_rate is a prerequisite for .set_rate */
> +		if (rate_ops->round_rate) {
> +			clk_composite_ops->round_rate = clk_composite_round_rate;
> +			if (rate_ops->set_rate) {
> +				clk_composite_ops->set_rate = clk_composite_set_rate;
> +			}
> +		}
> +

What if rate_ops has only recalc_rate and set_rate? clk_composite_ops 
will have only recalc_rate and it will pass the sanity check in clk_init 
and caller of clk_register_composite will expect set_rate to work.
We should check here if rate_ops has set_rate but not round_rate then 
return error.

>   		composite->rate_hw = rate_hw;
>   		composite->rate_ops = rate_ops;
>   		clk_composite_ops->recalc_rate = clk_composite_recalc_rate;
> -		clk_composite_ops->round_rate = clk_composite_round_rate;
> -		clk_composite_ops->set_rate = clk_composite_set_rate;
>   	}
>   
>   	if (gate_hw && gate_ops) {



From tomi.valkeinen at ti.com  Thu Apr 11 07:51:55 2013
From: tomi.valkeinen at ti.com (Tomi Valkeinen)
Date: Thu, 11 Apr 2013 14:51:55 +0300
Subject: [PATCH 12/30] video/exynos: remove unnecessary header inclusions
In-Reply-To: <1365638712-1028578-13-git-send-email-arnd@arndb.de>
References: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
 <1365638712-1028578-13-git-send-email-arnd@arndb.de>
Message-ID: <5166A3DB.6060700@ti.com>

Hi,

On 2013-04-11 03:04, Arnd Bergmann wrote:
> In multiplatform configurations, we cannot include headers
> provided by only the exynos platform. Fortunately a number
> of drivers that include those headers do not actually need
> them, so we can just remove the inclusions.
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Cc: linux-fbdev at vger.kernel.org
> Cc: Jingoo Han <jg1.han at samsung.com>
> ---
>  drivers/video/exynos/exynos_mipi_dsi.c          | 2 --
>  drivers/video/exynos/exynos_mipi_dsi_common.c   | 2 --
>  drivers/video/exynos/exynos_mipi_dsi_lowlevel.c | 2 --
>  3 files changed, 6 deletions(-)

I've applied this and the next patch ([PATCH 13/30] video/s3c: move
platform_data out of arch/arm) to fbdev.

I also fixed the extra space mentioned by Jingoo.

 Tomi


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130411/62aa70ae/attachment.sig>

From dt.tangr at gmail.com  Thu Apr 11 07:51:43 2013
From: dt.tangr at gmail.com (Daniel Tang)
Date: Thu, 11 Apr 2013 21:51:43 +1000
Subject: [RFC PATCHv2 arm: initial TI-Nspire support]
Message-ID: <8E071E2D-4FF3-487E-A53B-B6A7C427E421@gmail.com>

This is another updated patch for Linux on TI-Nspire support. 

Apologies for previously posting updated patches as replies to the first thread. I'll send updated patches in new threads from now to avoid confusion.

Changes between http://archive.arm.linux.org.uk/lurker/message/20130408.113343.585af217.en.html and v2:
* Added new drivers to support the irqchip and timers on older models.
* Added new device trees to support the other models.

Signed-off-by: Daniel Tang <dt.tangr at gmail.com>
---
 arch/arm/Kconfig                            |   2 +
 arch/arm/Kconfig.debug                      |  16 ++
 arch/arm/Makefile                           |   1 +
 arch/arm/boot/dts/Makefile                  |   3 +
 arch/arm/boot/dts/nspire-classic.dtsi       |  68 ++++++
 arch/arm/boot/dts/nspire-clp.dts            |  45 ++++
 arch/arm/boot/dts/nspire-cx.dts             | 115 ++++++++++
 arch/arm/boot/dts/nspire-tp.dts             |  44 ++++
 arch/arm/boot/dts/nspire.dtsi               | 159 ++++++++++++++
 arch/arm/include/debug/nspire.S             |  28 +++
 arch/arm/mach-nspire/Kconfig                |  15 ++
 arch/arm/mach-nspire/Makefile               |   2 +
 arch/arm/mach-nspire/Makefile.boot          |   0
 arch/arm/mach-nspire/clcd.c                 | 118 +++++++++++
 arch/arm/mach-nspire/clcd.h                 |  14 ++
 arch/arm/mach-nspire/mmio.h                 |  15 ++
 arch/arm/mach-nspire/nspire.c               | 142 +++++++++++++
 drivers/clocksource/Makefile                |   1 +
 drivers/clocksource/nspire-classic-timer.c  | 216 +++++++++++++++++++
 drivers/input/keyboard/Kconfig              |  10 +
 drivers/input/keyboard/Makefile             |   1 +
 drivers/input/keyboard/nspire-keypad.c      | 316 ++++++++++++++++++++++++++++
 drivers/irqchip/Makefile                    |   1 +
 drivers/irqchip/irq-nspire-classic.c        | 177 ++++++++++++++++
 include/clocksource/nspire_classic_timer.h  |  16 ++
 include/linux/platform_data/nspire-keypad.h |  28 +++
 26 files changed, 1553 insertions(+)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 1cacda4..3f0cd8c 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1081,6 +1081,8 @@ source "arch/arm/mach-netx/Kconfig"
 
 source "arch/arm/mach-nomadik/Kconfig"
 
+source "arch/arm/mach-nspire/Kconfig"
+
 source "arch/arm/plat-omap/Kconfig"
 
 source "arch/arm/mach-omap1/Kconfig"
diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 9b31f43..5da3a50 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -298,6 +298,20 @@ choice
 		  Say Y here if you want kernel low-level debugging support
 		  on MVEBU based platforms.
 
+	config DEBUG_NSPIRE_CLASSIC_UART
+		bool "Kernel low-level debugging via TI-NSPIRE 8250 UART"
+		depends on ARCH_NSPIRE
+		help
+		  Say Y here if you want kernel low-level debugging support
+		  on TI-NSPIRE classic models.
+
+	config DEBUG_NSPIRE_CX_UART
+		bool "Kernel low-level debugging via TI-NSPIRE PL011 UART"
+		depends on ARCH_NSPIRE
+		help
+		  Say Y here if you want kernel low-level debugging support
+		  on TI-NSPIRE CX models.
+
 	config DEBUG_OMAP2PLUS_UART
 		bool "Kernel low-level debugging messages via OMAP2PLUS UART"
 		depends on ARCH_OMAP2PLUS
@@ -591,6 +605,8 @@ config DEBUG_LL_INCLUDE
 				 DEBUG_IMX6Q_UART
 	default "debug/highbank.S" if DEBUG_HIGHBANK_UART
 	default "debug/mvebu.S" if DEBUG_MVEBU_UART
+	default "debug/nspire.S" if 	DEBUG_NSPIRE_CX_UART || \
+					DEBUG_NSPIRE_CLASSIC_UART
 	default "debug/omap2plus.S" if DEBUG_OMAP2PLUS_UART
 	default "debug/picoxcell.S" if DEBUG_PICOXCELL_UART
 	default "debug/socfpga.S" if DEBUG_SOCFPGA_UART
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index ee4605f..2580d2b 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -165,6 +165,7 @@ machine-$(CONFIG_ARCH_MXS)		+= mxs
 machine-$(CONFIG_ARCH_MVEBU)		+= mvebu
 machine-$(CONFIG_ARCH_NETX)		+= netx
 machine-$(CONFIG_ARCH_NOMADIK)		+= nomadik
+machine-$(CONFIG_ARCH_NSPIRE)		+= nspire
 machine-$(CONFIG_ARCH_OMAP1)		+= omap1
 machine-$(CONFIG_ARCH_OMAP2PLUS)	+= omap2
 machine-$(CONFIG_ARCH_ORION5X)		+= orion5x
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 9c62558..21d161b 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -114,6 +114,9 @@ dtb-$(CONFIG_ARCH_MXS) += imx23-evk.dtb \
 	imx28-sps1.dtb \
 	imx28-tx28.dtb
 dtb-$(CONFIG_ARCH_NOMADIK) += ste-nomadik-s8815.dtb
+dtb-$(CONFIG_ARCH_NSPIRE) += nspire-cx.dtb \
+	nspire-tp.dtb \
+	nspire-clp.dtb
 dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
 	omap3-beagle.dtb \
 	omap3-beagle-xm.dtb \
diff --git a/arch/arm/boot/dts/nspire-classic.dtsi b/arch/arm/boot/dts/nspire-classic.dtsi
new file mode 100644
index 0000000..56f5e39
--- /dev/null
+++ b/arch/arm/boot/dts/nspire-classic.dtsi
@@ -0,0 +1,68 @@
+/*
+ *  linux/arch/arm/boot/nspire-classic.dts
+ *
+ *  Copyright (C) 2012 Daniel Tang <tangrs at tangrs.id.au>
+ *
+ * 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/ "nspire.dtsi"
+
+&lcd {
+	lcd-type = "classic";
+};
+
+&fast_timer {
+	/* compatible = "nspire-classic-timer"; */
+	reg = <0x90010000 0x1000>, <0x900A0010 0x8>;
+};
+
+&uart {
+	compatible = "ns16550";
+	reg-shift = <2>;
+	reg-io-width = <4>;
+	clock-frequency = <29491200>;
+	no-loopback-test;
+};
+
+&timer0 {
+	compatible = "nspire-classic-timer";
+	reg = <0x900C0000 0x1000>, <0x900A0018 0x8>;
+};
+
+&timer1 {
+	compatible = "nspire-classic-timer";
+	reg = <0x900D0000 0x1000>, <0x900A0020 0x8>;
+};
+
+/ {
+	memory {
+		device_type = "memory";
+		reg = <0x10000000 0x2000000>; /* 32 MB */
+	};
+
+	/* Not really a fixed clock but we'll fix this later */
+	apb_pclk: apb_pclk {
+		#clock-cells = <0>;
+		compatible = "fixed-clock";
+		clock-frequency = <30000000>;
+	};
+
+	ahb {
+		#address-cells = <1>;
+		#size-cells = <1>;
+
+		intc: interrupt-controller at DC000000 {
+			compatible = "nspire-classic-intc";
+			interrupt-controller;
+			reg = <0xDC000000 0x1000>;
+			#interrupt-cells = <1>;
+		};
+	};
+	chosen {
+		bootargs = "debug earlyprintk console=tty0 console=ttyS0,115200n8 root=/dev/ram0";
+	};
+};
diff --git a/arch/arm/boot/dts/nspire-clp.dts b/arch/arm/boot/dts/nspire-clp.dts
new file mode 100644
index 0000000..7f25f44
--- /dev/null
+++ b/arch/arm/boot/dts/nspire-clp.dts
@@ -0,0 +1,45 @@
+/*
+ *  linux/arch/arm/boot/nspire-clp.dts
+ *
+ *  Copyright (C) 2013 Daniel Tang <tangrs at tangrs.id.au>
+ *
+ * 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.
+ *
+ */
+/dts-v1/;
+
+/include/ "nspire-classic.dtsi"
+
+&keypad {
+	keymap = <
+	0x0000001c 	0x0001001c 	0x00020039
+	0x0004002c 	0x00050034 	0x00060015
+	0x0007000b 	0x0008002d 	0x01000033
+	0x0101004e 	0x01020011 	0x01030004
+	0x0104002f 	0x01050003 	0x01060016
+	0x01070002 	0x01080014 	0x02000062
+	0x0201000c 	0x0202001f 	0x02030007
+	0x02040013 	0x02050006 	0x02060010
+	0x02070005 	0x02080019 	0x03000027
+	0x03010037 	0x03020018 	0x0303000a
+	0x03040031 	0x03050009 	0x03060032
+	0x03070008 	0x03080026 	0x04000028
+	0x04010035 	0x04020025 	0x04040024
+	0x04060017 	0x04080023 	0x05000028
+	0x05020022 	0x0503001b 	0x05040021
+	0x0505001a 	0x05060012 	0x0507006f
+	0x05080020 	0x0509002a 	0x0601001c
+	0x0602002e 	0x06030068 	0x06040030
+	0x0605006d 	0x0606001e 	0x06070001
+	0x0608002b 	0x0609000f 	0x07000067
+	0x0702006a 	0x0704006c 	0x07060069
+	0x0707000e 	0x0708001d 	0x070a000d
+	>;
+};
+
+/ {
+	model = "TI-NSPIRE Clickpad";
+	compatible = "arm,nspire-clp";
+};
diff --git a/arch/arm/boot/dts/nspire-cx.dts b/arch/arm/boot/dts/nspire-cx.dts
new file mode 100644
index 0000000..890dd98
--- /dev/null
+++ b/arch/arm/boot/dts/nspire-cx.dts
@@ -0,0 +1,115 @@
+/*
+ *  linux/arch/arm/boot/nspire-cx.dts
+ *
+ *  Copyright (C) 2012 Daniel Tang <tangrs at tangrs.id.au>
+ *
+ * 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.
+ *
+ */
+/dts-v1/;
+
+/include/ "nspire.dtsi"
+
+&lcd {
+	lcd-type = "cx";
+};
+
+&fast_timer {
+	/* compatible = "arm,sp804", "arm,primecell"; */
+};
+
+&uart {
+	compatible = "arm,pl011", "arm,primecell";
+
+	clocks = <&uart_clk>, <&apb_pclk>;
+	clock-names = "uart_clk", "apb_pclk";
+};
+
+&timer0 {
+	compatible = "arm,sp804", "arm,primecell";
+};
+
+&timer1 {
+	compatible = "arm,sp804", "arm,primecell";
+};
+
+&keypad {
+	keymap = <
+	0x0000001c 	0x0001001c 	0x00040039
+	0x0005002c 	0x00060015 	0x0007000b
+	0x0008000f 	0x0100002d 	0x01010011
+	0x0102002f 	0x01030004 	0x01040016
+	0x01050014 	0x0106001f 	0x01070002
+	0x010a006a 	0x02000013 	0x02010010
+	0x02020019 	0x02030007 	0x02040018
+	0x02050031 	0x02060032 	0x02070005
+	0x02080028 	0x0209006c 	0x03000026
+	0x03010025 	0x03020024 	0x0303000a
+	0x03040017 	0x03050023 	0x03060022
+	0x03070008 	0x03080035 	0x03090069
+	0x04000021 	0x04010012 	0x04020020
+	0x0404002e 	0x04050030 	0x0406001e
+	0x0407000d 	0x04080037 	0x04090067
+	0x05010038 	0x0502000c 	0x0503001b
+	0x05040034 	0x0505001a 	0x05060006
+	0x05080027 	0x0509000e 	0x050a006f
+	0x0600002b 	0x0602004e 	0x06030068
+	0x06040003 	0x0605006d 	0x06060009
+	0x06070001 	0x0609000f 	0x0708002a
+	0x0709001d 	0x070a0033 	>;
+};
+
+/ {
+	model = "TI-NSPIRE CX";
+	compatible = "arm,nspire-cx";
+
+	memory {
+		device_type = "memory";
+		reg = <0x10000000 0x4000000>; /* 64 MB */
+	};
+
+	uart_clk: uart_clk {
+		#clock-cells = <0>;
+		compatible = "fixed-clock";
+		clock-frequency = <12000000>;
+	};
+
+	/* Not really a fixed clock but we'll fix this later */
+	apb_pclk: apb_pclk {
+		#clock-cells = <0>;
+		compatible = "fixed-clock";
+		clock-frequency = <33000000>;
+	};
+
+	ahb {
+		#address-cells = <1>;
+		#size-cells = <1>;
+
+		intc: interrupt-controller at DC000000 {
+			compatible = "arm,pl190-vic";
+			interrupt-controller;
+			reg = <0xDC000000 0x1000>;
+			#interrupt-cells = <1>;
+		};
+
+		lcd: lcd at C0000000 {
+			lcd-type = "cx";
+		};
+
+		apb at 90000000 {
+			#address-cells = <1>;
+			#size-cells = <1>;
+
+			i2c at 90050000 {
+				compatible = "snps,designware-i2c";
+				reg = <0x90050000 0x1000>;
+				interrupts = <20>;
+			};
+		};
+	};
+	chosen {
+		bootargs = "debug earlyprintk console=tty0 console=ttyAMA0,115200n8 root=/dev/ram0";
+	};
+};
diff --git a/arch/arm/boot/dts/nspire-tp.dts b/arch/arm/boot/dts/nspire-tp.dts
new file mode 100644
index 0000000..485d0ff
--- /dev/null
+++ b/arch/arm/boot/dts/nspire-tp.dts
@@ -0,0 +1,44 @@
+/*
+ *  linux/arch/arm/boot/nspire-tp.dts
+ *
+ *  Copyright (C) 2013 Daniel Tang <tangrs at tangrs.id.au>
+ *
+ * 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.
+ *
+ */
+/dts-v1/;
+
+/include/ "nspire-classic.dtsi"
+
+&keypad {
+	keymap = <
+	0x0000001c 	0x0001001c 	0x00040039
+	0x0005002c 	0x00060015 	0x0007000b
+	0x0008000f 	0x0100002d 	0x01010011
+	0x0102002f 	0x01030004 	0x01040016
+	0x01050014 	0x0106001f 	0x01070002
+	0x010a006a 	0x02000013 	0x02010010
+	0x02020019 	0x02030007 	0x02040018
+	0x02050031 	0x02060032 	0x02070005
+	0x02080028 	0x0209006c 	0x03000026
+	0x03010025 	0x03020024 	0x0303000a
+	0x03040017 	0x03050023 	0x03060022
+	0x03070008 	0x03080035 	0x03090069
+	0x04000021 	0x04010012 	0x04020020
+	0x0404002e 	0x04050030 	0x0406001e
+	0x0407000d 	0x04080037 	0x04090067
+	0x05010038 	0x0502000c 	0x0503001b
+	0x05040034 	0x0505001a 	0x05060006
+	0x05080027 	0x0509000e 	0x050a006f
+	0x0600002b 	0x0602004e 	0x06030068
+	0x06040003 	0x0605006d 	0x06060009
+	0x06070001 	0x0609000f 	0x0708002a
+	0x0709001d 	0x070a0033 	>;
+};
+
+/ {
+	model = "TI-NSPIRE Touchpad";
+	compatible = "arm,nspire-tp";
+};
diff --git a/arch/arm/boot/dts/nspire.dtsi b/arch/arm/boot/dts/nspire.dtsi
new file mode 100644
index 0000000..31c9172
--- /dev/null
+++ b/arch/arm/boot/dts/nspire.dtsi
@@ -0,0 +1,159 @@
+/*
+ *  linux/arch/arm/boot/nspire.dtsi
+ *
+ *  Copyright (C) 2012 Daniel Tang <tangrs at tangrs.id.au>
+ *
+ * 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/ "skeleton.dtsi"
+
+/ {
+	interrupt-parent = <&intc>;
+
+	cpus {
+		cpu at 0 {
+			compatible = "arm,arm926ejs";
+		};
+	};
+
+	bootrom: bootrom at 00000000 {
+		reg = <0x00000000 0x80000>;
+	};
+
+	sram: sram at A4000000 {
+		device = "memory";
+		reg = <0xA4000000 0x20000>;
+	};
+
+	timer_clk: timer_clk {
+		#clock-cells = <0>;
+		compatible = "fixed-clock";
+		clock-frequency = <32768>;
+	};
+
+	ahb {
+		compatible = "simple-bus";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges;
+
+		spi: spi at A9000000 {
+			reg = <0xA9000000 0x1000>;
+		};
+
+		usb0: usb at B0000000 {
+			reg = <0xB0000000 0x1000>;
+			interrupts = <8>;
+		};
+
+		usb1: usb at B4000000 {
+			reg = <0xB4000000 0x1000>;
+			interrupts = <9>;
+			status = "disabled";
+		};
+
+		lcd: lcd at C0000000 {
+			compatible = "arm,pl111", "arm,primecell";
+			reg = <0xC0000000 0x1000>;
+			interrupts = <21>;
+
+			clocks = <&apb_pclk>;
+			clock-names = "apb_pclk";
+		};
+
+		adc: adc at C4000000 {
+			reg = <0xC4000000 0x1000>;
+			interrupts = <11>;
+		};
+
+		tdes: crypto at C8010000 {
+			reg = <0xC8010000 0x1000>;
+		};
+
+		sha256: crypto at CC000000 {
+			reg = <0xCC000000 0x1000>;
+		};
+
+		apb at 90000000 {
+			compatible = "simple-bus";
+			#address-cells = <1>;
+			#size-cells = <1>;
+			clock-ranges;
+			ranges;
+
+			gpio: gpio at 90000000 {
+				reg = <0x90000000 0x1000>;
+				interrupts = <7>;
+			};
+
+			fast_timer: timer at 90010000 {
+				reg = <0x90010000 0x1000>;
+				interrupts = <17>;
+			};
+
+			uart: serial at 90020000 {
+				reg = <0x90020000 0x1000>;
+				interrupts = <1>;
+			};
+
+			timer0: timer at 900C0000 {
+				reg = <0x900C0000 0x1000>;
+
+				clocks = <&timer_clk>;
+				clock-names = "timer_clk";
+			};
+
+			timer1: timer at 900D0000 {
+				reg = <0x900D0000 0x1000>;
+				interrupts = <19>;
+
+				clocks = <&timer_clk>;
+				clock-names = "timer_clk";
+			};
+
+			watchdog: watchdog at 90060000 {
+				compatible = "arm,amba-primecell";
+				reg = <0x90060000 0x1000>;
+				interrupts = <3>;
+			};
+
+			rtc: rtc at 90090000 {
+				reg = <0x90090000 0x1000>;
+				interrupts = <4>;
+			};
+
+			misc: misc at 900A0000 {
+				reg = <0x900A0000 0x1000>;
+			};
+
+			pwr: pwr at 900B0000 {
+				reg = <0x900B0000 0x1000>;
+				interrupts = <15>;
+			};
+
+			keypad: input at 900E0000 {
+				compatible = "nspire-keypad";
+				reg = <0x900E0000 0x1000>;
+				interrupts = <16>;
+
+				scan-interval = <1000>;
+				row-delay = <200>;
+
+				clocks = <&apb_pclk>;
+				clock-names = "apb_pclk";
+			};
+
+			contrast: contrast at 900F0000 {
+				reg = <0x900F0000 0x1000>;
+			};
+
+			led: led at 90110000 {
+				reg = <0x90110000 0x1000>;
+			};
+		};
+	};
+};
diff --git a/arch/arm/include/debug/nspire.S b/arch/arm/include/debug/nspire.S
new file mode 100644
index 0000000..3a9729c
--- /dev/null
+++ b/arch/arm/include/debug/nspire.S
@@ -0,0 +1,28 @@
+/*
+ *	linux/arch/arm/include/debug/nspire.S
+ *
+ *	Copyright (C) 2012 Daniel Tang <tangrs at tangrs.id.au>
+ *
+ * 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.
+ *
+ */
+
+#define NSPIRE_EARLY_UART_PHYS_BASE	   0x90020000
+#define NSPIRE_EARLY_UART_VIRT_BASE	   0xfee20000
+
+.macro	addruart, rp, rv, tmp
+	ldr \rp, =(NSPIRE_EARLY_UART_PHYS_BASE)		@ physical base address
+	ldr \rv, =(NSPIRE_EARLY_UART_VIRT_BASE)		@ virtual base address
+.endm
+
+
+#ifdef CONFIG_DEBUG_NSPIRE_CX_UART
+#include <asm/hardware/debug-pl01x.S>
+#endif
+
+#ifdef CONFIG_DEBUG_NSPIRE_CLASSIC_UART
+#define UART_SHIFT 2
+#include <asm/hardware/debug-8250.S>
+#endif
diff --git a/arch/arm/mach-nspire/Kconfig b/arch/arm/mach-nspire/Kconfig
new file mode 100644
index 0000000..a295b18
--- /dev/null
+++ b/arch/arm/mach-nspire/Kconfig
@@ -0,0 +1,15 @@
+config ARCH_NSPIRE
+	bool "TI-NSPIRE based"
+	depends on ARCH_MULTI_V4_V5
+	depends on MMU
+	select CPU_ARM926T
+	select COMMON_CLK
+	select GENERIC_CLOCKEVENTS
+	select SPARSE_IRQ
+	select ARM_AMBA
+	select ARM_VIC
+	select ARM_TIMER_SP804
+	select USE_OF
+	select CLKSRC_OF
+	help
+	  This enables support for systems using the TI-NSPIRE CPU
diff --git a/arch/arm/mach-nspire/Makefile b/arch/arm/mach-nspire/Makefile
new file mode 100644
index 0000000..1bec256
--- /dev/null
+++ b/arch/arm/mach-nspire/Makefile
@@ -0,0 +1,2 @@
+obj-y				+= nspire.o
+obj-y				+= clcd.o
diff --git a/arch/arm/mach-nspire/Makefile.boot b/arch/arm/mach-nspire/Makefile.boot
new file mode 100644
index 0000000..e69de29
diff --git a/arch/arm/mach-nspire/clcd.c b/arch/arm/mach-nspire/clcd.c
new file mode 100644
index 0000000..09f7dc7
--- /dev/null
+++ b/arch/arm/mach-nspire/clcd.c
@@ -0,0 +1,118 @@
+/*
+ *	linux/arch/arm/mach-nspire/clcd.c
+ *
+ *	Copyright (C) 2012 Daniel Tang <tangrs at tangrs.id.au>
+ *
+ * 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/init.h>
+#include <linux/of.h>
+#include <linux/amba/bus.h>
+#include <linux/amba/clcd.h>
+#include <linux/dma-mapping.h>
+
+static struct clcd_panel nspire_cx_lcd_panel = {
+	.mode		= {
+		.name		= "Color LCD",
+		.refresh	= 60,
+		.xres		= 320,
+		.yres		= 240,
+		.sync		= 0,
+		.vmode		= FB_VMODE_NONINTERLACED,
+		.pixclock	= 1,
+		.hsync_len	= 6,
+		.vsync_len	= 1,
+		.right_margin	= 50,
+		.left_margin	= 38,
+		.lower_margin	= 3,
+		.upper_margin	= 17,
+	},
+	.width		= 65, /* ~6.50 cm */
+	.height		= 49, /* ~4.87 cm */
+	.tim2		= TIM2_IPC,
+	.cntl		= (CNTL_BGR | CNTL_LCDTFT | CNTL_LCDVCOMP(1) |
+				CNTL_LCDBPP16_565),
+	.bpp		= 16,
+};
+
+static struct clcd_panel nspire_classic_lcd_panel = {
+	.mode		= {
+		.name		= "Grayscale LCD",
+		.refresh	= 60,
+		.xres		= 320,
+		.yres		= 240,
+		.sync		= FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,
+		.vmode		= FB_VMODE_NONINTERLACED,
+		.pixclock	= 1,
+		.hsync_len	= 6,
+		.vsync_len	= 1,
+		.right_margin	= 6,
+		.left_margin	= 6,
+	},
+	.width		= 71, /* 7.11cm */
+	.height		= 53, /* 5.33cm */
+	.tim2		= 0x80007d0,
+	.cntl		= CNTL_LCDBPP8 | CNTL_LCDMONO8,
+	.bpp		= 8,
+	.grayscale	= 1
+};
+
+int nspire_clcd_setup(struct clcd_fb *fb)
+{
+	struct clcd_panel *panel;
+	size_t panel_size;
+	const char *type;
+	dma_addr_t dma;
+	int err;
+
+	BUG_ON(!fb->dev->dev.of_node);
+
+	err = of_property_read_string(fb->dev->dev.of_node, "lcd-type", &type);
+	if (err) {
+		pr_err("CLCD: Could not find lcd-type property\n");
+		return err;
+	}
+
+	if (!strcmp(type, "cx")) {
+		panel = &nspire_cx_lcd_panel;
+	} else if (!strcmp(type, "classic")) {
+		panel = &nspire_classic_lcd_panel;
+	} else {
+		pr_err("CLCD: Unknown lcd-type %s\n", type);
+		return -EINVAL;
+	}
+
+	panel_size = ((panel->mode.xres * panel->mode.yres) * panel->bpp) / 8;
+	panel_size = ALIGN(panel_size, PAGE_SIZE);
+
+	fb->fb.screen_base = dma_alloc_writecombine(&fb->dev->dev,
+		panel_size, &dma, GFP_KERNEL);
+
+	if (!fb->fb.screen_base) {
+		pr_err("CLCD: unable to map framebuffer\n");
+		return -ENOMEM;
+	}
+
+	fb->fb.fix.smem_start = dma;
+	fb->fb.fix.smem_len = panel_size;
+	fb->panel = panel;
+
+	return 0;
+}
+
+int nspire_clcd_mmap(struct clcd_fb *fb, struct vm_area_struct *vma)
+{
+	return dma_mmap_writecombine(&fb->dev->dev, vma,
+		fb->fb.screen_base, fb->fb.fix.smem_start,
+		fb->fb.fix.smem_len);
+}
+
+void nspire_clcd_remove(struct clcd_fb *fb)
+{
+	dma_free_writecombine(&fb->dev->dev, fb->fb.fix.smem_len,
+		fb->fb.screen_base, fb->fb.fix.smem_start);
+}
diff --git a/arch/arm/mach-nspire/clcd.h b/arch/arm/mach-nspire/clcd.h
new file mode 100644
index 0000000..7144399
--- /dev/null
+++ b/arch/arm/mach-nspire/clcd.h
@@ -0,0 +1,14 @@
+/*
+ *	linux/arch/arm/mach-nspire/clcd.h
+ *
+ *	Copyright (C) 2012 Daniel Tang <tangrs at tangrs.id.au>
+ *
+ * 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.
+ *
+ */
+
+int nspire_clcd_setup(struct clcd_fb *fb);
+int nspire_clcd_mmap(struct clcd_fb *fb, struct vm_area_struct *vma);
+void nspire_clcd_remove(struct clcd_fb *fb);
diff --git a/arch/arm/mach-nspire/mmio.h b/arch/arm/mach-nspire/mmio.h
new file mode 100644
index 0000000..f0a1fa5
--- /dev/null
+++ b/arch/arm/mach-nspire/mmio.h
@@ -0,0 +1,15 @@
+/*
+ *	linux/arch/arm/mach-nspire/mmio.h
+ *
+ *	Copyright (C) 2012 Daniel Tang <tangrs at tangrs.id.au>
+ *
+ * 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.
+ *
+ */
+
+#define NSPIRE_EARLY_UART_PHYS_BASE	0x90020000
+#define NSPIRE_EARLY_UART_VIRT_BASE	0xfee20000
+
+#define NSPIRE_LCD_PHYS_BASE		0xC0000000
diff --git a/arch/arm/mach-nspire/nspire.c b/arch/arm/mach-nspire/nspire.c
new file mode 100644
index 0000000..bb1c8b3
--- /dev/null
+++ b/arch/arm/mach-nspire/nspire.c
@@ -0,0 +1,142 @@
+/*
+ *	linux/arch/arm/mach-nspire/nspire.c
+ *
+ *	Copyright (C) 2012 Daniel Tang <tangrs at tangrs.id.au>
+ *
+ * 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/init.h>
+#include <linux/of_irq.h>
+#include <linux/of_address.h>
+#include <linux/of_platform.h>
+#include <linux/irqchip.h>
+#include <linux/irqchip/arm-vic.h>
+#include <linux/clk-provider.h>
+#include <linux/clkdev.h>
+#include <linux/amba/bus.h>
+#include <linux/amba/clcd.h>
+
+#include <clocksource/nspire_classic_timer.h>
+
+#include <asm/mach/arch.h>
+#include <asm/mach-types.h>
+#include <asm/mach/map.h>
+
+#include <asm/hardware/timer-sp.h>
+
+#include "mmio.h"
+#include "clcd.h"
+
+static const char *nspire_dt_match[] __initconst = {
+	"arm,nspire",
+	"arm,nspire-cx",
+	"arm,nspire-tp",
+	"arm,nspire-clp",
+	NULL,
+};
+
+static struct map_desc nspire_io_desc[] __initdata = {
+	{
+		.virtual	=  NSPIRE_EARLY_UART_VIRT_BASE,
+		.pfn		= __phys_to_pfn(NSPIRE_EARLY_UART_PHYS_BASE),
+		.length		= SZ_4K,
+		.type		= MT_DEVICE
+	}
+};
+
+#define TIMER_NAME_MAXLEN 32
+static void __init nspire_add_sp804_timers(void)
+{
+	struct device_node *of_timer;
+	int clockevents_found = 0;
+
+	for_each_compatible_node(of_timer, NULL, "arm,sp804") {
+		struct resource res;
+		void __iomem *base;
+		char *name;
+		struct clk *clk;
+		int irq;
+
+		clk = of_clk_get_by_name(of_timer, NULL);
+		if (WARN_ON(!clk))
+			continue;
+
+		name = kzalloc(TIMER_NAME_MAXLEN, GFP_ATOMIC);
+		if (!name)
+			break;
+
+		base = of_iomap(of_timer, 0);
+		if (WARN_ON(!base)) {
+			kfree(name);
+			continue;
+		}
+
+		of_address_to_resource(of_timer, 0, &res);
+		scnprintf(name, TIMER_NAME_MAXLEN, "%llx.%s",
+				(unsigned long long)res.start,
+				of_timer->name);
+
+		clk_register_clkdev(clk, name, "sp804");
+		if (!clockevents_found) {
+			irq = irq_of_parse_and_map(of_timer, 0);
+			if (irq) {
+				sp804_clockevents_init(base, irq, name);
+				clockevents_found = 1;
+				continue;
+			}
+		}
+
+		sp804_clocksource_init(base, name);
+	}
+}
+
+
+static void __init nspire_init_timer(void)
+{
+	of_clk_init(NULL);
+	nspire_classic_timer_init();
+	nspire_add_sp804_timers();
+}
+
+static void __init nspire_map_io(void)
+{
+	iotable_init(nspire_io_desc, ARRAY_SIZE(nspire_io_desc));
+}
+
+static struct clcd_board nspire_clcd_data = {
+	.name		= "LCD",
+	.check		= clcdfb_check,
+	.decode		= clcdfb_decode,
+	.setup		= nspire_clcd_setup,
+	.mmap		= nspire_clcd_mmap,
+	.remove		= nspire_clcd_remove,
+};
+
+
+static struct of_dev_auxdata nspire_auxdata[] __initdata = {
+	OF_DEV_AUXDATA("arm,pl111", NSPIRE_LCD_PHYS_BASE,
+			NULL, &nspire_clcd_data),
+	{ }
+};
+
+static void __init nspire_init(void)
+{
+	of_platform_populate(NULL, of_default_bus_match_table,
+			nspire_auxdata, NULL);
+}
+
+static void nspire_restart(char mode, const char *cmd)
+{
+}
+
+DT_MACHINE_START(NSPIRE, "TI-NSPIRE")
+	.map_io		= nspire_map_io,
+	.init_irq	= irqchip_init,
+	.init_time	= nspire_init_timer,
+	.init_machine	= nspire_init,
+	.dt_compat	= nspire_dt_match,
+	.restart	= nspire_restart,
+MACHINE_END
diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index 4d8283a..0a8e6b7 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -19,6 +19,7 @@ obj-$(CONFIG_ARCH_BCM2835)	+= bcm2835_timer.o
 obj-$(CONFIG_SUNXI_TIMER)	+= sunxi_timer.o
 obj-$(CONFIG_ARCH_TEGRA)	+= tegra20_timer.o
 obj-$(CONFIG_VT8500_TIMER)	+= vt8500_timer.o
+obj-$(CONFIG_ARCH_NSPIRE)	+= nspire-classic-timer.o
 
 obj-$(CONFIG_ARM_ARCH_TIMER)		+= arm_arch_timer.o
 obj-$(CONFIG_CLKSRC_METAG_GENERIC)	+= metag_generic.o
diff --git a/drivers/clocksource/nspire-classic-timer.c b/drivers/clocksource/nspire-classic-timer.c
new file mode 100644
index 0000000..b5aa32e
--- /dev/null
+++ b/drivers/clocksource/nspire-classic-timer.c
@@ -0,0 +1,216 @@
+/*
+ *  linux/drivers/clocksource/nspire-classic-timer.c
+ *
+ *  Copyright (C) 2013 Daniel Tang <tangrs at tangrs.id.au>
+ *
+ * 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/io.h>
+#include <linux/irq.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+#include <linux/clk.h>
+#include <linux/clockchips.h>
+#include <linux/cpumask.h>
+#include <linux/interrupt.h>
+#include <linux/slab.h>
+
+#define DT_COMPAT	"nspire-classic-timer"
+
+#define IO_CURRENT_VAL	0x00
+#define IO_DIVIDER	0x04
+#define IO_CONTROL	0x08
+
+#define IO_TIMER1	0x00
+#define IO_TIMER2	0x0C
+
+#define IO_MATCH1	0x18
+#define IO_MATCH2	0x1C
+#define IO_MATCH3	0x20
+#define IO_MATCH4	0x24
+#define IO_MATCH5	0x28
+#define IO_MATCH6	0x2C
+
+#define IO_INTR_STS	0x00
+#define IO_INTR_ACK	0x00
+#define IO_INTR_MSK	0x04
+
+#define CNTL_STOP_TIMER	(1<<4)
+#define CNTL_RUN_TIMER	(0<<4)
+
+#define CNTL_INC	(1<<3)
+#define CNTL_DEC	(0<<3)
+
+#define CNTL_TOZERO	0
+#define CNTL_MATCH1	1
+#define CNTL_MATCH2	2
+#define CNTL_MATCH3	3
+#define CNTL_MATCH4	4
+#define CNTL_MATCH5	5
+#define CNTL_MATCH6	6
+#define CNTL_FOREVER	7
+
+struct nspire_timer {
+	void __iomem *base;
+	void __iomem *timer1, *timer2;
+	void __iomem *interrupt_regs;
+
+	int irqnr;
+
+	struct clk *clk;
+	struct clock_event_device clkevt;
+	struct irqaction clkevt_irq;
+
+	char clocksource_name[64];
+	char clockevent_name[64];
+};
+
+static int nspire_timer_set_event(unsigned long delta,
+		struct clock_event_device *dev)
+{
+	unsigned long flags;
+	struct nspire_timer *timer = container_of(dev,
+			struct nspire_timer,
+			clkevt);
+
+	local_irq_save(flags);
+
+	writel(delta, timer->timer1 + IO_CURRENT_VAL);
+	writel(CNTL_RUN_TIMER | CNTL_DEC | CNTL_MATCH1,
+			timer->timer1 + IO_CONTROL);
+
+	local_irq_restore(flags);
+
+	return 0;
+}
+static void nspire_timer_set_mode(enum clock_event_mode mode,
+		struct clock_event_device *evt)
+{
+	evt->mode = mode;
+}
+
+static irqreturn_t nspire_timer_interrupt(int irq, void *dev_id)
+{
+	struct nspire_timer *timer = dev_id;
+
+	writel((1<<0), timer->interrupt_regs + IO_INTR_ACK);
+	writel(CNTL_STOP_TIMER, timer->timer1 + IO_CONTROL);
+
+	if (timer->clkevt.event_handler)
+		timer->clkevt.event_handler(&timer->clkevt);
+
+	return IRQ_HANDLED;
+}
+
+static int __init nspire_timer_add(struct device_node *node)
+{
+	struct nspire_timer *timer;
+	struct resource res;
+	int ret;
+
+	timer = kzalloc(sizeof(*timer), GFP_ATOMIC);
+	if (!timer)
+		return -ENOMEM;
+
+	timer->base = of_iomap(node, 0);
+	if (!timer->base) {
+		ret = -EINVAL;
+		goto error_free;
+	}
+	timer->timer1 = timer->base + IO_TIMER1;
+	timer->timer2 = timer->base + IO_TIMER2;
+
+	timer->clk = of_clk_get(node, 0);
+	if (!timer->clk) {
+		ret = -EINVAL;
+		pr_err("Timer clock not found!\n");
+		goto error_unmap;
+	}
+
+	timer->interrupt_regs = of_iomap(node, 1);
+	timer->irqnr = irq_of_parse_and_map(node, 0);
+
+	of_address_to_resource(node, 0, &res);
+	scnprintf(timer->clocksource_name, sizeof(timer->clocksource_name),
+			"%llx.%s_clocksource",
+			(unsigned long long)res.start, node->name);
+
+	scnprintf(timer->clockevent_name, sizeof(timer->clockevent_name),
+			"%llx.%s_clockevent",
+			(unsigned long long)res.start, node->name);
+
+	if (timer->interrupt_regs && timer->irqnr) {
+		timer->clkevt.name	= timer->clockevent_name;
+		timer->clkevt.set_next_event = nspire_timer_set_event;
+		timer->clkevt.set_mode	= nspire_timer_set_mode;
+		timer->clkevt.rating	= 200;
+		timer->clkevt.shift	= 32;
+		timer->clkevt.cpumask	= cpu_all_mask;
+		timer->clkevt.features	=
+			CLOCK_EVT_FEAT_ONESHOT;
+
+		writel(CNTL_STOP_TIMER, timer->timer1 + IO_CONTROL);
+		writel(0, timer->timer1 + IO_DIVIDER);
+
+		/* Mask out interrupts except the one we're using */
+		writel((1<<0), timer->interrupt_regs + IO_INTR_MSK);
+		writel(0x3F, timer->interrupt_regs + IO_INTR_ACK);
+
+		/* Interrupt to occur when timer value matches 0 */
+		writel(0, timer->base + IO_MATCH1);
+
+		timer->clkevt_irq.name	= timer->clockevent_name;
+		timer->clkevt_irq.handler = nspire_timer_interrupt;
+		timer->clkevt_irq.dev_id = timer;
+		timer->clkevt_irq.flags	=
+			IRQF_DISABLED | IRQF_TIMER | IRQF_IRQPOLL;
+
+		setup_irq(timer->irqnr, &timer->clkevt_irq);
+
+		clockevents_config_and_register(&timer->clkevt,
+				clk_get_rate(timer->clk), 0x0001, 0xfffe);
+		pr_info("Added %s as clockevent\n", timer->clockevent_name);
+	}
+
+	writel(CNTL_RUN_TIMER | CNTL_FOREVER | CNTL_INC,
+			timer->timer2 + IO_CONTROL);
+
+	clocksource_mmio_init(timer->timer2 + IO_CURRENT_VAL,
+			timer->clocksource_name,
+			clk_get_rate(timer->clk),
+			200, 16,
+			clocksource_mmio_readw_up);
+
+	pr_info("Added %s as clocksource\n", timer->clocksource_name);
+
+	return 0;
+error_unmap:
+	iounmap(timer->base);
+error_free:
+	kfree(timer);
+	return ret;
+}
+
+bool timer_init;
+
+void __init nspire_classic_timer_init(void)
+{
+	struct device_node *node;
+
+	if (timer_init)
+		return;
+
+	for_each_compatible_node(node, NULL, DT_COMPAT) {
+		nspire_timer_add(node);
+	}
+
+	timer_init = 1;
+}
+
+CLOCKSOURCE_OF_DECLARE(nspire_classic_timer,
+		DT_COMPAT, nspire_classic_timer_init)
diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
index ac05006..677adba 100644
--- a/drivers/input/keyboard/Kconfig
+++ b/drivers/input/keyboard/Kconfig
@@ -418,6 +418,16 @@ config KEYBOARD_NOMADIK
 	  To compile this driver as a module, choose M here: the
 	  module will be called nmk-ske-keypad.
 
+config KEYBOARD_NSPIRE
+	tristate "TI-NSPIRE builtin keyboard"
+	depends on ARCH_NSPIRE
+	select INPUT_MATRIXKMAP
+	help
+	  Say Y here if you want to use the builtin keypad on the TI-NSPIRE.
+
+	  To compile this driver as a module, choose M here: the
+	  module will be called nspire-keypad.
+
 config KEYBOARD_TEGRA
 	tristate "NVIDIA Tegra internal matrix keyboard controller support"
 	depends on ARCH_TEGRA && OF
diff --git a/drivers/input/keyboard/Makefile b/drivers/input/keyboard/Makefile
index 49b1645..89d997b 100644
--- a/drivers/input/keyboard/Makefile
+++ b/drivers/input/keyboard/Makefile
@@ -35,6 +35,7 @@ obj-$(CONFIG_KEYBOARD_MCS)		+= mcs_touchkey.o
 obj-$(CONFIG_KEYBOARD_MPR121)		+= mpr121_touchkey.o
 obj-$(CONFIG_KEYBOARD_NEWTON)		+= newtonkbd.o
 obj-$(CONFIG_KEYBOARD_NOMADIK)		+= nomadik-ske-keypad.o
+obj-$(CONFIG_KEYBOARD_NSPIRE)		+= nspire-keypad.o
 obj-$(CONFIG_KEYBOARD_OMAP)		+= omap-keypad.o
 obj-$(CONFIG_KEYBOARD_OMAP4)		+= omap4-keypad.o
 obj-$(CONFIG_KEYBOARD_OPENCORES)	+= opencores-kbd.o
diff --git a/drivers/input/keyboard/nspire-keypad.c b/drivers/input/keyboard/nspire-keypad.c
new file mode 100644
index 0000000..581dea5
--- /dev/null
+++ b/drivers/input/keyboard/nspire-keypad.c
@@ -0,0 +1,316 @@
+/*
+ *  linux/drivers/input/keyboard/nspire-keypad.c
+ *
+ *  Copyright (C) 2013 Daniel Tang <tangrs at tangrs.id.au>
+ *
+ * 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/input/matrix_keypad.h>
+#include <linux/platform_device.h>
+#include <linux/interrupt.h>
+#include <linux/spinlock.h>
+#include <linux/io.h>
+#include <linux/delay.h>
+#include <linux/input.h>
+#include <linux/slab.h>
+#include <linux/clk.h>
+#include <linux/module.h>
+#include <linux/of.h>
+
+#include <linux/platform_data/nspire-keypad.h>
+
+#define KEYPAD_SCAN_MODE	0x00
+#define KEYPAD_CNTL		0x04
+#define KEYPAD_INT		0x08
+#define KEYPAD_INTMSK		0x0C
+
+#define KEYPAD_DATA		0x10
+#define KEYPAD_GPIO		0x30
+
+#define KEYPAD_UNKNOWN_INT	0x40
+#define KEYPAD_UNKNOWN_INT_STS	0x44
+
+
+struct nspire_keypad {
+	spinlock_t lock;
+
+	void __iomem *reg_base;
+	int irq;
+	u32 int_mask;
+
+	struct input_dev *input;
+	struct clk *clk;
+
+	struct nspire_keypad_data options;
+	int row_shift;
+};
+
+static inline void nspire_report_state(struct nspire_keypad *keypad,
+		int row, int col, unsigned int state)
+{
+	int code = MATRIX_SCAN_CODE(row, col, keypad->row_shift);
+	unsigned short *keymap = keypad->input->keycode;
+
+	state = keypad->options.active_low ? !state : !!state;
+	input_report_key(keypad->input, keymap[code], state);
+}
+
+static irqreturn_t nspire_keypad_irq(int irq, void *dev_id)
+{
+	struct nspire_keypad *keypad = dev_id;
+	u32 int_sts;
+	u16 state[8];
+	int row, col;
+
+	int_sts = readl(keypad->reg_base + KEYPAD_INT) & keypad->int_mask;
+
+	if (!int_sts)
+		return IRQ_NONE;
+
+	spin_lock(&keypad->lock);
+
+	memcpy_fromio(state, keypad->reg_base + KEYPAD_DATA, sizeof(state));
+
+	for (row = 0; row < KEYPAD_BITMASK_ROWS; row++) {
+		u16 bits = state[row];
+		for (col = 0; col < KEYPAD_BITMASK_COLS; col++)
+			nspire_report_state(keypad, row, col, bits & (1<<col));
+	}
+	input_sync(keypad->input);
+	writel(0x3, keypad->reg_base + KEYPAD_INT);
+
+	spin_unlock(&keypad->lock);
+
+	return IRQ_HANDLED;
+}
+
+static int nspire_keypad_chip_init(struct nspire_keypad *keypad)
+{
+	unsigned long val = 0, cycles_per_us, delay_cycles, row_delay_cycles;
+
+	cycles_per_us = (clk_get_rate(keypad->clk) / 1000000);
+	if (cycles_per_us == 0)
+		cycles_per_us = 1;
+
+	delay_cycles = cycles_per_us * keypad->options.scan_interval;
+	WARN_ON(delay_cycles >= (1<<16)); /* Overflow */
+	delay_cycles &= 0xffff;
+
+	row_delay_cycles = cycles_per_us * keypad->options.row_delay;
+	WARN_ON(row_delay_cycles >= (1<<14)); /* Overflow */
+	row_delay_cycles &= 0x3fff;
+
+
+	val |= (3<<0); /* Set scan mode to 3 (continuous scan) */
+	val |= (row_delay_cycles<<2); /* Delay between scanning each row */
+	val |= (delay_cycles<<16); /* Delay between scans */
+	writel(val, keypad->reg_base + KEYPAD_SCAN_MODE);
+
+	val = (KEYPAD_BITMASK_ROWS & 0xff) | (KEYPAD_BITMASK_COLS & 0xff)<<8;
+	writel(val, keypad->reg_base + KEYPAD_CNTL);
+
+	/* Enable interrupts */
+	keypad->int_mask = (1<<1);
+	writel(keypad->int_mask, keypad->reg_base + 0xc);
+
+	/* Disable GPIO interrupts to prevent hanging on touchpad */
+	/* Possibly used to detect touchpad events */
+	writel(0, keypad->reg_base + KEYPAD_UNKNOWN_INT);
+	/* Acknowledge existing interrupts */
+	writel(~0, keypad->reg_base + KEYPAD_UNKNOWN_INT_STS);
+
+	return 0;
+}
+
+static int nspire_keypad_probe(struct platform_device *pdev)
+{
+	const struct nspire_keypad_data *plat = pdev->dev.platform_data;
+	const struct device_node *of_node = pdev->dev.of_node;
+	struct nspire_keypad *keypad;
+	struct input_dev *input;
+	struct resource *res;
+	struct clk *clk;
+	int irq, error;
+
+	irq = platform_get_irq(pdev, 0);
+	if (irq < 0) {
+		dev_err(&pdev->dev, "failed to get keypad irq\n");
+		return -EINVAL;
+	}
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	if (!res) {
+		dev_err(&pdev->dev, "missing platform resources\n");
+		return -EINVAL;
+	}
+
+	clk = clk_get(&pdev->dev, NULL);
+	if (IS_ERR(clk)) {
+		dev_err(&pdev->dev, "unable to get clock\n");
+		return -EINVAL;
+	}
+
+	clk_prepare(clk);
+	error = clk_enable(clk);
+	if (error)
+		goto err_put_clk;
+
+	keypad = kzalloc(sizeof(struct nspire_keypad), GFP_KERNEL);
+	input = input_allocate_device();
+	if (!keypad || !input) {
+		dev_err(&pdev->dev, "failed to allocate keypad memory\n");
+		error = -ENOMEM;
+		goto err_free_mem;
+	}
+
+	if (plat) {
+		memcpy(&keypad->options, plat, sizeof(*plat));
+	} else {
+		/* Load values from device tree */
+
+		error = of_property_read_u32(of_node, "scan-interval",
+				&keypad->options.scan_interval);
+		if (error) {
+			dev_err(&pdev->dev, "failed to get scan-interval\n");
+			goto err_free_mem;
+		}
+
+		error = of_property_read_u32(of_node, "row-delay",
+				&keypad->options.row_delay);
+		if (error) {
+			dev_err(&pdev->dev, "failed to get row-delay\n");
+			goto err_free_mem;
+		}
+
+		keypad->options.active_low = of_property_read_bool(of_node,
+				"active-low");
+
+		keypad->options.keymap = NULL;
+	}
+
+	keypad->row_shift = get_count_order(KEYPAD_BITMASK_COLS);
+	keypad->irq = irq;
+	keypad->clk = clk;
+	keypad->input = input;
+	spin_lock_init(&keypad->lock);
+
+	if (!request_mem_region(res->start, resource_size(res), pdev->name)) {
+		dev_err(&pdev->dev, "failed to request I/O memory\n");
+		error = -EBUSY;
+		goto err_free_mem;
+	}
+
+	keypad->reg_base = ioremap(res->start, resource_size(res));
+	if (!keypad->reg_base) {
+		dev_err(&pdev->dev, "failed to remap I/O memory\n");
+		error = -ENXIO;
+		goto err_free_mem_region;
+	}
+
+	input->id.bustype = BUS_HOST;
+	input->name = "nspire-keypad";
+	input->dev.parent = &pdev->dev;
+
+	set_bit(EV_KEY, input->evbit);
+	set_bit(EV_REP, input->evbit);
+
+	error = matrix_keypad_build_keymap(keypad->options.keymap, "keymap",
+			KEYPAD_BITMASK_ROWS, KEYPAD_BITMASK_COLS, NULL, input);
+	if (error) {
+		dev_err(&pdev->dev, "building keymap failed\n");
+		goto err_iounmap;
+	}
+
+	error = nspire_keypad_chip_init(keypad);
+	if (error) {
+		dev_err(&pdev->dev, "unable to init keypad hardware\n");
+		goto err_iounmap;
+	}
+
+	error = request_irq(keypad->irq, nspire_keypad_irq, 0,
+			"nspire_keypad", keypad);
+	if (error) {
+		dev_err(&pdev->dev, "allocate irq %d failed\n", keypad->irq);
+		goto err_iounmap;
+	}
+
+	error = input_register_device(input);
+	if (error) {
+		dev_err(&pdev->dev,
+				"unable to register input device: %d\n", error);
+		goto err_free_irq;
+	}
+
+	platform_set_drvdata(pdev, keypad);
+
+	dev_info(&pdev->dev, "TI-NSPIRE keypad at %#08x ("
+			"scan_interval=%uus,row_delay=%uus"
+			"%s)\n", res->start,
+			keypad->options.row_delay,
+			keypad->options.scan_interval,
+			keypad->options.active_low ? ",active_low" : "");
+
+	return 0;
+
+err_free_irq:
+	free_irq(keypad->irq, keypad);
+err_iounmap:
+	iounmap(keypad->reg_base);
+err_free_mem_region:
+	release_mem_region(res->start, resource_size(res));
+err_free_mem:
+	input_free_device(input);
+	kfree(keypad);
+
+	clk_disable(clk);
+err_put_clk:
+	clk_unprepare(clk);
+	clk_put(clk);
+	return error;
+}
+
+static int nspire_keypad_remove(struct platform_device *pdev)
+{
+	struct nspire_keypad *keypad = platform_get_drvdata(pdev);
+	struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+
+	free_irq(keypad->irq, keypad);
+
+	input_unregister_device(keypad->input);
+
+	iounmap(keypad->reg_base);
+	release_mem_region(res->start, resource_size(res));
+	kfree(keypad);
+
+	clk_disable(keypad->clk);
+	clk_unprepare(keypad->clk);
+	clk_put(keypad->clk);
+
+	return 0;
+}
+#ifdef CONFIG_OF
+static const struct of_device_id nspire_keypad_dt_match[] = {
+	{ .compatible = "nspire-keypad" },
+	{ },
+};
+MODULE_DEVICE_TABLE(of, nspire_keypad_dt_match);
+#endif
+
+static struct platform_driver nspire_keypad_driver = {
+	.driver = {
+		.name = "nspire-keypad",
+		.owner  = THIS_MODULE,
+		.of_match_table = of_match_ptr(nspire_keypad_dt_match),
+	},
+	.remove = nspire_keypad_remove,
+	.probe = nspire_keypad_probe
+};
+
+module_platform_driver(nspire_keypad_driver);
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("TI-NSPIRE Keypad Driver");
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index 98e3b87..9e7f5f5 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -9,3 +9,4 @@ obj-$(CONFIG_ARCH_SPEAR3XX)		+= spear-shirq.o
 obj-$(CONFIG_ARM_GIC)			+= irq-gic.o
 obj-$(CONFIG_ARM_VIC)			+= irq-vic.o
 obj-$(CONFIG_VERSATILE_FPGA_IRQ)	+= irq-versatile-fpga.o
+obj-$(CONFIG_ARCH_NSPIRE)		+= irq-nspire-classic.o
diff --git a/drivers/irqchip/irq-nspire-classic.c b/drivers/irqchip/irq-nspire-classic.c
new file mode 100644
index 0000000..9e6413a
--- /dev/null
+++ b/drivers/irqchip/irq-nspire-classic.c
@@ -0,0 +1,177 @@
+/*
+ *  linux/drivers/irqchip/irq-nspire-classic.c
+ *
+ *  Copyright (C) 2013 Daniel Tang <tangrs at tangrs.id.au>
+ *
+ * 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/io.h>
+#include <linux/irq.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+
+#include <asm/mach/irq.h>
+#include <asm/exception.h>
+
+#include "irqchip.h"
+
+#define IO_STATUS	0x000
+#define IO_RAW_STATUS	0x004
+#define IO_ENABLE	0x008
+#define IO_DISABLE	0x00C
+#define IO_CURRENT	0x020
+#define IO_RESET	0x028
+#define IO_MAX_PRIOTY	0x02C
+
+#define IO_IRQ_BASE	0x000
+#define IO_FIQ_BASE	0x100
+
+#define IO_INVERT_SEL	0x200
+#define IO_STICKY_SEL	0x204
+#define IO_PRIORITY_SEL	0x300
+
+#define MAX_INTRS	32
+#define FIQ_START	MAX_INTRS
+
+
+static void __iomem *irq_io_base;
+static struct irq_domain *nspire_irq_domain;
+
+static void nspire_irq_ack(struct irq_data *irqd)
+{
+	void __iomem *base = irq_io_base;
+
+	if (irqd->hwirq < FIQ_START)
+		base += IO_IRQ_BASE;
+	else
+		base += IO_FIQ_BASE;
+
+	readl(base + IO_RESET);
+}
+
+static void nspire_irq_unmask(struct irq_data *irqd)
+{
+	void __iomem *base = irq_io_base;
+	int irqnr = irqd->hwirq;
+
+	if (irqnr < FIQ_START) {
+		base += IO_IRQ_BASE;
+	} else {
+		irqnr -= MAX_INTRS;
+		base += IO_FIQ_BASE;
+	}
+
+	writel((1<<irqnr), base + IO_ENABLE);
+}
+
+static void nspire_irq_mask(struct irq_data *irqd)
+{
+	void __iomem *base = irq_io_base;
+	int irqnr = irqd->hwirq;
+
+	if (irqnr < FIQ_START) {
+		base += IO_IRQ_BASE;
+	} else {
+		irqnr -= FIQ_START;
+		base += IO_FIQ_BASE;
+	}
+
+	writel((1<<irqnr), base + IO_DISABLE);
+}
+
+static struct irq_chip nspire_irq_chip = {
+	.name		= "nspire_irq",
+	.irq_ack	= nspire_irq_ack,
+	.irq_mask	= nspire_irq_mask,
+	.irq_unmask	= nspire_irq_unmask,
+};
+
+
+static int nspire_irq_map(struct irq_domain *dom, unsigned int virq,
+		irq_hw_number_t hw)
+{
+	irq_set_chip_and_handler(virq, &nspire_irq_chip, handle_level_irq);
+	set_irq_flags(virq, IRQF_VALID | IRQF_PROBE);
+
+	return 0;
+}
+
+static struct irq_domain_ops nspire_irq_ops = {
+	.map = nspire_irq_map,
+	.xlate = irq_domain_xlate_onecell,
+};
+
+static void init_base(void __iomem *base)
+{
+	/* Disable all interrupts */
+	writel(~0, base + IO_DISABLE);
+
+	/* Accept interrupts of all priorities */
+	writel(0xF, base + IO_MAX_PRIOTY);
+
+	/* Reset existing interrupts */
+	readl(base + IO_RESET);
+}
+
+static int process_base(void __iomem *base, struct pt_regs *regs)
+{
+	int irqnr;
+
+
+	if (!readl(base + IO_STATUS))
+		return 0;
+
+	irqnr = readl(base + IO_CURRENT);
+	irqnr = irq_find_mapping(nspire_irq_domain, irqnr);
+	handle_IRQ(irqnr, regs);
+
+	return 1;
+}
+
+asmlinkage void __exception_irq_entry nspire_handle_irq(struct pt_regs *regs)
+{
+	while (process_base(irq_io_base + IO_FIQ_BASE, regs))
+		;
+	while (process_base(irq_io_base + IO_IRQ_BASE, regs))
+		;
+}
+
+static int __init nspire_of_init(struct device_node *node,
+				struct device_node *parent)
+{
+	if (WARN_ON(irq_io_base))
+		return -EBUSY;
+
+	irq_io_base = of_iomap(node, 0);
+	BUG_ON(!irq_io_base);
+
+	/* Do not invert interrupt status bits */
+	writel(~0, irq_io_base + IO_INVERT_SEL);
+
+	/* Disable sticky interrupts */
+	writel(0, irq_io_base + IO_STICKY_SEL);
+
+	/* We don't use IRQ priorities. Set each IRQ to highest priority. */
+	memset_io(irq_io_base + IO_PRIORITY_SEL, 0, MAX_INTRS * sizeof(u32));
+
+	/* Init IRQ and FIQ */
+	init_base(irq_io_base + IO_IRQ_BASE);
+	init_base(irq_io_base + IO_FIQ_BASE);
+
+	nspire_irq_domain = irq_domain_add_linear(node, MAX_INTRS,
+						 &nspire_irq_ops, NULL);
+
+	BUG_ON(!nspire_irq_domain);
+
+	set_handle_irq(nspire_handle_irq);
+
+	pr_info("TI-NSPIRE classic IRQ controller\n");
+	return 0;
+}
+
+IRQCHIP_DECLARE(nspire_classic_irq, "nspire-classic-intc", nspire_of_init);
diff --git a/include/clocksource/nspire_classic_timer.h b/include/clocksource/nspire_classic_timer.h
new file mode 100644
index 0000000..39236f1
--- /dev/null
+++ b/include/clocksource/nspire_classic_timer.h
@@ -0,0 +1,16 @@
+/*
+ *  linux/include/clocksource/nspire_classic_timer.h
+ *
+ *  Copyright (C) 2013 Daniel Tang <tangrs at tangrs.id.au>
+ *
+ * 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.
+ *
+ */
+#ifndef __CLKSOURCE_NSPIRE_CLASSIC_TIMER_H
+#define __CLKSOURCE_NSPIRE_CLASSIC_TIMER_H
+
+void __init nspire_classic_timer_init(void);
+
+#endif
diff --git a/include/linux/platform_data/nspire-keypad.h b/include/linux/platform_data/nspire-keypad.h
new file mode 100644
index 0000000..03deb64
--- /dev/null
+++ b/include/linux/platform_data/nspire-keypad.h
@@ -0,0 +1,28 @@
+/*
+ *  linux/include/linux/platform_data/nspire-keypad.h
+ *
+ *  Copyright (C) 2012 Daniel Tang <tangrs at tangrs.id.au>
+ *
+ * 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.
+ *
+ */
+
+#ifndef _LINUX_NSPIRE_KEYPAD_H
+#define _LINUX_NSPIRE_KEYPAD_H
+
+#define KEYPAD_BITMASK_COLS	11
+#define KEYPAD_BITMASK_ROWS	8
+
+struct nspire_keypad_data {
+	struct matrix_keymap_data *keymap;
+
+	/* Maximum delay estimated assuming 33MHz APB */
+	u32 scan_interval;	/* In microseconds (~2000us max) */
+	u32 row_delay;		/* In microseconds (~500us max) */
+
+	bool active_low;
+};
+
+#endif



From sergei.shtylyov at cogentembedded.com  Thu Apr 11 08:02:33 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Thu, 11 Apr 2013 16:02:33 +0400
Subject: [PATCH v3 0/9] Reorganize R8A7779/Marzen USB code
In-Reply-To: <20130411005155.GA18530@verge.net.au>
References: <201304100226.08967.sergei.shtylyov@cogentembedded.com>
 <20130410044923.GD10044@verge.net.au> <20130410085033.GL7983@arwen.pp.htv.fi>
 <20130410090543.GB25890@verge.net.au> <20130411005155.GA18530@verge.net.au>
Message-ID: <5166A659.6060405@cogentembedded.com>

Hello.

On 11-04-2013 4:51, Simon Horman wrote:

>>>>>     Here's the set of 9 patches against the Simon Horman's 'renesas.git' repo,
>>>>> 'renesas-next-20130410' tag.  It was created to fix the shortcomings in the
>>>>> R8A7779/Marzen USB platform code and R8A7779 USB common PHY driver, and so
>>>>> spans both arch/arm/mach-shmobile/ and drivers/usb/ subtrees (some patches have
>>>>> to touch both subtrees). The patches were conceived with the complete
>>>>> bisectability goal in mind.

>>>>> [1/9] ARM: shmobile: Marzen: move USB EHCI, OHCI, and PHY devices to R8A7779 code
>>>>> [2/9] ehci-platform: add pre_setup() method to platform data
>>>>> [3/9] ARM: shmobile: R8A7779: setup EHCI internal buffer
>>>>> [4/9] rcar-phy: remove EHCI internal buffer setup
>>>>> [5/9] ARM: shmobile: R8A7779: remove USB PHY 2nd memory resource
>>>>> [6/9] rcar-phy: correct base address
>>>>> [7/9] rcar-phy: add platform data
>>>>> [8/9] ARM: shmobile: Marzen: pass platform data to USB PHY device
>>>>> [9/9] rcar-phy: handle platform data

>>>>>     I'm not sure thru which tree this patchset should be merged, however it turns
>>>>> out that it's too late now to push it thru Felipe Balbi's USB tree for 3.10
>>>>> (which would have been most convenient probably), and it's probably too late to
>>>>> merge thru Simon's tree for 3.10 too. So it now have to be postponed to 3.11,
>>>>> unfortunately...

>>>> Felipe, how would you prefer to handle this?
>>>> I'm happy for you to take it or to take it myself.

>>> please take it yourself, just keep in mind there will be conflicts, I
>>> will go over the patches now and give my Acked-by so you can queue them
>>> up.

>> Thanks

> Sergei, it looks like patches 1-7 are clear.

    #7 & #9 have been refused by Felipe (hence #8 isn't good too).

> Do you want me to start queueing them up.

    I was going to repost the whole series soon, adding ACK from Alan to the 
patch #2 and resolving issues with patches #7..#9. It's worth waiting for that 
to happen I think.

> Or would you rather wait for the issue with patch 6 to be resolved?

    There's no special issue with patch #6 other than the PHY driver files 
being renamed in Felipe's tree -- but that concerns all patches touching 
drivers/usb/phy/rcar-phy.c (some of which precede #6).
    I don't know how the rename conflict will be handled (this is really bad 
coincidence), perhaps I still should have done this patchset against Felipe's 
'next' branch and pushed it thru his tree. If the patches will be queued for 
3.11 anyway, maybe it's worth doing that -- I'm still of the opinion that his 
tree would be the one most fitting for this patchset.

WBR, Sergei



From andrew.murray at arm.com  Thu Apr 11 08:03:22 2013
From: andrew.murray at arm.com (Andrew Murray)
Date: Thu, 11 Apr 2013 13:03:22 +0100
Subject: [PATCH v5 1/3] of/pci: Unify pci_process_bridge_OF_ranges from
 Microblaze and PowerPC
In-Reply-To: <51656592.7070806@gmail.com>
References: <1365578969-30966-1-git-send-email-Andrew.Murray@arm.com>
 <1365578969-30966-2-git-send-email-Andrew.Murray@arm.com>
 <51656592.7070806@gmail.com>
Message-ID: <20130411120322.GA28981@arm.com>

On Wed, Apr 10, 2013 at 02:13:54PM +0100, Rob Herring wrote:
> Adding Ben H and Michal...
> 
> On 04/10/2013 02:29 AM, Andrew Murray wrote:
> > The pci_process_bridge_OF_ranges function, used to parse the "ranges"
> > property of a PCI host device, is found in both Microblaze and PowerPC
> > architectures. These implementations are nearly identical. This patch
> > moves this common code to a common place.
> > 
> > Signed-off-by: Andrew Murray <Andrew.Murray at arm.com>
> > Signed-off-by: Liviu Dudau <Liviu.Dudau at arm.com>
> 
> One comment below. Otherwise,
> 
> Reviewed-by: Rob Herring <rob.herring at calxeda.com>
> 
> You need also need acks from Ben and Michal.
> 
> [...]
> 
> > +		/* Act based on address space type */
> > +		res = NULL;
> > +		switch ((pci_space >> 24) & 0x3) {
> > +		case 1:		/* PCI IO space */
> > +			pr_info("  IO 0x%016llx..0x%016llx -> 0x%016llx\n",
> > +			       cpu_addr, cpu_addr + size - 1, pci_addr);
> > +
> > +			/* We support only one IO range */
> > +			if (hose->pci_io_size) {
> > +				pr_info(" \\--> Skipped (too many) !\n");
> > +				continue;
> > +			}
> > +#if defined(CONFIG_PPC32) || defined(CONFIG_MICROBLAZE)
> 
> How about "if (!IS_ENABLED(CONFIG_64BIT))" instead.

OK I'll add in my next re-spin. Would "#ifndef CONFIG_64BIT" suffice?

> 
> > +			/* On 32 bits, limit I/O space to 16MB */
> > +			if (size > 0x01000000)
> > +				size = 0x01000000;
> > +
> > +			/* 32 bits needs to map IOs here */
> > +			hose->io_base_virt = ioremap(cpu_addr, size);
> > +
> > +			/* Expect trouble if pci_addr is not 0 */
> > +			if (primary)
> > +				isa_io_base =
> > +					(unsigned long)hose->io_base_virt;
> > +#endif /* CONFIG_PPC32 || CONFIG_MICROBLAZE */
> > +			/* pci_io_size and io_base_phys always represent IO
> > +			 * space starting at 0 so we factor in pci_addr
> > +			 */
> > +			hose->pci_io_size = pci_addr + size;
> > +			hose->io_base_phys = cpu_addr - pci_addr;
> 
> 


From hechtb at gmail.com  Thu Apr 11 08:06:24 2013
From: hechtb at gmail.com (Bastian Hecht)
Date: Thu, 11 Apr 2013 14:06:24 +0200
Subject: [PATCH] ARM: shmobile: r8a7740: Add Suspend-To-RAM modes and
 CPUIdle
In-Reply-To: <51667D68.7070804@linaro.org>
References: <1365609107-14290-1-git-send-email-hechtb+renesas@gmail.com>
 <5165E929.9030309@linaro.org>
 <CABYn4sxEOvQhZP7GnS5-AgNjkvJJXyv4n1UjVGBjXbVq0N+9_A@mail.gmail.com>
 <51667D68.7070804@linaro.org>
Message-ID: <CABYn4syA6R0PU1xEQLcm29sYkD+fGi6vx+tCrFSNfA4qPo0npg@mail.gmail.com>

Hi Daniel,

>>>> +
>>>> +static struct cpuidle_driver r8a7740_cpuidle_driver = {
>>>> +     .name                   = "r8a7740_cpuidle",
>>>> +     .owner                  = THIS_MODULE,
>>>> +     .en_core_tk_irqen       = 1,
>>>> +     .state_count            = 3,
>>>> +     .safe_state_index       = 0, /* C1 */
>>>> +     .states[0] = ARM_CPUIDLE_WFI_STATE,
>>>> +     .states[0].enter = shmobile_enter_wfi,
>>>
>>> The WFI macro already set a simple enter function doing cpu_do_idle.
>>
>> Oh yes, I'll remove it.
>>
>>> We are trying to consolidate the cpuidle drivers across the different
>>> platforms [1]. One of the objective is to move the cpuidle drivers to
>>> drivers/cpuidle, a place where they belong to.
>>>
>>> Do you think it is possible you split your code to have one part with
>>> the cpuidle driver and another part with the PM code ?
>>
>> Hmm. The CPUIdle part is enclosed in the #ifdef CONFIG_CPU_IDLE part anyway.
>> The other part (CONFIG_SUSPEND | CONFIG_CPU_IDLE) contains the part
>> that actually does drive down the hardware and is needed as soon as
>> SUSPEND or CPUIdle is used.
>>
>> So is it split well enough already or does it help if I split my patch
>> into 2, first adding suspend and then CPUIdle to the same file? But
>> the outcome will be the same I think.
>
>
> Well, if you can convert the pm functions into ops used in the cpuidle
> driver and then create a file eg. cpuidle-r8a7740.c with the cpuidle
> code calling the ops that will separate clearly the cpuidle code from
> the pm code and make easier to move the cpuidle driver to the
> drivers/cpuidle directory. Also, I think that will help to consolidate
> the other shmobile cpuidle drivers, maybe into a single one.
>
>

Ok I've prepared a new patchset and think the splitting looks good .
As this is a sensitive code area I want to retest it though and post
it in a couple of hours.

Cheers,

 Bastian


From thomas.abraham at linaro.org  Thu Apr 11 08:06:32 2013
From: thomas.abraham at linaro.org (Thomas Abraham)
Date: Thu, 11 Apr 2013 17:36:32 +0530
Subject: [PATCH v4] mmc: dw_mmc: let device core setup the default pin
 configuration
In-Reply-To: <001101ce3662$7ecb9850$7c62c8f0$%jun@samsung.com>
References: <1365487186-4587-1-git-send-email-thomas.abraham@linaro.org>
 <CAD=FV=VJ-ykDNqYKQ=fqxeOD6bRNLW02VT4bjsRHRAuXLcCpQQ@mail.gmail.com>
 <CAJuYYwQT=povqiutVHXkF5jxTAnjpwTMQ5G0Z6xKGnnM7qYADQ@mail.gmail.com>
 <CAD=FV=UddWM=yc5N9=jwbMDpZ7Bpg7o3Z714CnBSg=iHhmPxWw@mail.gmail.com>
 <CAD=FV=WyPbkYvq9udPzQtVnaXZR3jzXTPnBrrdxpUuX3CZT=Og@mail.gmail.com>
 <001101ce3662$7ecb9850$7c62c8f0$%jun@samsung.com>
Message-ID: <CAJuYYwQaO1dArYPAbr3mW3gJQjK4bSWGYvgT_t+aUsZTxDgnUg@mail.gmail.com>

On 11 April 2013 08:43, Seungwon Jeon <tgih.jun at samsung.com> wrote:
> On Wednesday, April 10, 2013, Doug Anderson wrote:
>> Thomas,
>>
>> On Wed, Apr 10, 2013 at 6:56 AM, Doug Anderson <dianders at chromium.org> wrote:
>> > On Wed, Apr 10, 2013 at 5:48 AM, Thomas Abraham
>> > <thomas.abraham at linaro.org> wrote:
>> >> The call to regulator_enable() is prior to the call to mmc_add_host().
>> >> Hence, call to mmc_fre_host is not required in this case. So the above
>> >> change should be right.
>> >
>> > Are you sure that mmc_free_host() is the opposite of mmc_add_host()
>> > and not mmc_alloc_host()?
>> >
>> > I'll double-check myself in a few hours when I'm in front of a computer.
>>
>> OK, I double checked and I'm still convinced that the free is needed
>> because we've already called mmc_alloc_host().  Current code always
>> makes sure to free when it returns an error and that seems right to
>> me.
> mmc_alloc_host corresponds to mmc_free_host. And mmc_add_host matches
> with mmc_remove_host. Let's focus on mmc_alloc_host.
> mmc_alloc_host is called prior to regulator_enable.
> So, if regulator_enable is failed, call of mmc_free_host makes sense.
>

Hi Doug, Seungwon,

Ok, I got it wrong again. Thanks for letting me know. I will fix this
and send the v5 of this patch.

Thanks,
Thomas.


> Thanks,
> Seungwon Jeon
>>
>> -Doug
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>


From thomas.abraham at linaro.org  Thu Apr 11 08:24:07 2013
From: thomas.abraham at linaro.org (Thomas Abraham)
Date: Thu, 11 Apr 2013 17:54:07 +0530
Subject: [PATCH v5] mmc: dw_mmc: let device core setup the default pin
 configuration
Message-ID: <1365683047-8829-1-git-send-email-thomas.abraham@linaro.org>

With device core now able to setup the default pin configuration,
the pin configuration code based on the deprecated Samsung specific
gpio bindings is removed.

Signed-off-by: Thomas Abraham <thomas.abraham at linaro.org>
Acked-by: Linus Walleij <linus.walleij at linaro.org>
Reviewed-by: Doug Anderson <dianders at chromium.org>
Tested-by: Doug Anderson <dianders at chromium.org>
Acked-by: Seungwon Jeon <tgih.jun at samsung.com>
---
Changes since v4:
- Fixed the incorrecr return path after error in enabling vmmc regulator
  as pointed out by Doug.

Changes since v3:
- Rebased to the latest mmc-next branch, resolving the compilation
  error with this patch due to changes in commit f2f942ce
  "mmc: dw_mmc: Check return value of regulator_enable".
  Thanks to Doug for pointing out this issue with the v3 patch.

 drivers/mmc/host/dw_mmc-exynos.c |   38 --------------------------------------
 drivers/mmc/host/dw_mmc.c        |    8 --------
 drivers/mmc/host/dw_mmc.h        |    3 ---
 3 files changed, 0 insertions(+), 49 deletions(-)

diff --git a/drivers/mmc/host/dw_mmc-exynos.c b/drivers/mmc/host/dw_mmc-exynos.c
index c7f0976..f013e7e 100644
--- a/drivers/mmc/host/dw_mmc-exynos.c
+++ b/drivers/mmc/host/dw_mmc-exynos.c
@@ -152,43 +152,6 @@ static int dw_mci_exynos_parse_dt(struct dw_mci *host)
 	return 0;
 }
 
-static int dw_mci_exynos_setup_bus(struct dw_mci *host,
-				struct device_node *slot_np, u8 bus_width)
-{
-	int idx, gpio, ret;
-
-	if (!slot_np)
-		return -EINVAL;
-
-	/* cmd + clock + bus-width pins */
-	for (idx = 0; idx < NUM_PINS(bus_width); idx++) {
-		gpio = of_get_gpio(slot_np, idx);
-		if (!gpio_is_valid(gpio)) {
-			dev_err(host->dev, "invalid gpio: %d\n", gpio);
-			return -EINVAL;
-		}
-
-		ret = devm_gpio_request(host->dev, gpio, "dw-mci-bus");
-		if (ret) {
-			dev_err(host->dev, "gpio [%d] request failed\n", gpio);
-			return -EBUSY;
-		}
-	}
-
-	if (host->pdata->quirks & DW_MCI_QUIRK_BROKEN_CARD_DETECTION)
-		return 0;
-
-	gpio = of_get_named_gpio(slot_np, "samsung,cd-pinmux-gpio", 0);
-	if (gpio_is_valid(gpio)) {
-		if (devm_gpio_request(host->dev, gpio, "dw-mci-cd"))
-			dev_err(host->dev, "gpio [%d] request failed\n", gpio);
-	} else {
-		dev_info(host->dev, "cd gpio not available");
-	}
-
-	return 0;
-}
-
 /* Common capabilities of Exynos4/Exynos5 SoC */
 static unsigned long exynos_dwmmc_caps[4] = {
 	MMC_CAP_UHS_DDR50 | MMC_CAP_1_8V_DDR |
@@ -205,7 +168,6 @@ static const struct dw_mci_drv_data exynos_drv_data = {
 	.prepare_command	= dw_mci_exynos_prepare_command,
 	.set_ios		= dw_mci_exynos_set_ios,
 	.parse_dt		= dw_mci_exynos_parse_dt,
-	.setup_bus		= dw_mci_exynos_setup_bus,
 };
 
 static const struct of_device_id dw_mci_exynos_match[] = {
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 45d9216..bc3a1bc 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -1952,14 +1952,6 @@ static int dw_mci_init_slot(struct dw_mci *host, unsigned int id)
 	else
 		bus_width = 1;
 
-	if (drv_data && drv_data->setup_bus) {
-		struct device_node *slot_np;
-		slot_np = dw_mci_of_find_slot_node(host->dev, slot->id);
-		ret = drv_data->setup_bus(host, slot_np, bus_width);
-		if (ret)
-			goto err_setup_bus;
-	}
-
 	switch (bus_width) {
 	case 8:
 		mmc->caps |= MMC_CAP_8_BIT_DATA;
diff --git a/drivers/mmc/host/dw_mmc.h b/drivers/mmc/host/dw_mmc.h
index 53b8fd9..0b74189 100644
--- a/drivers/mmc/host/dw_mmc.h
+++ b/drivers/mmc/host/dw_mmc.h
@@ -190,7 +190,6 @@ extern int dw_mci_resume(struct dw_mci *host);
  * @prepare_command: handle CMD register extensions.
  * @set_ios: handle bus specific extensions.
  * @parse_dt: parse implementation specific device tree properties.
- * @setup_bus: initialize io-interface
  *
  * Provide controller implementation specific extensions. The usage of this
  * data structure is fully optional and usage of each member in this structure
@@ -203,7 +202,5 @@ struct dw_mci_drv_data {
 	void		(*prepare_command)(struct dw_mci *host, u32 *cmdr);
 	void		(*set_ios)(struct dw_mci *host, struct mmc_ios *ios);
 	int		(*parse_dt)(struct dw_mci *host);
-	int		(*setup_bus)(struct dw_mci *host,
-				struct device_node *slot_np, u8 bus_width);
 };
 #endif /* _DW_MMC_H_ */
-- 
1.6.6.rc2



From balbi at ti.com  Thu Apr 11 08:06:49 2013
From: balbi at ti.com (Felipe Balbi)
Date: Thu, 11 Apr 2013 15:06:49 +0300
Subject: [PATCH v3 0/9] Reorganize R8A7779/Marzen USB code
In-Reply-To: <5166A659.6060405@cogentembedded.com>
References: <201304100226.08967.sergei.shtylyov@cogentembedded.com>
 <20130410044923.GD10044@verge.net.au>
 <20130410085033.GL7983@arwen.pp.htv.fi>
 <20130410090543.GB25890@verge.net.au>
 <20130411005155.GA18530@verge.net.au>
 <5166A659.6060405@cogentembedded.com>
Message-ID: <20130411120649.GM14394@arwen.pp.htv.fi>

Hi,

On Thu, Apr 11, 2013 at 04:02:33PM +0400, Sergei Shtylyov wrote:
> Hello.
> 
> On 11-04-2013 4:51, Simon Horman wrote:
> 
> >>>>>    Here's the set of 9 patches against the Simon Horman's 'renesas.git' repo,
> >>>>>'renesas-next-20130410' tag.  It was created to fix the shortcomings in the
> >>>>>R8A7779/Marzen USB platform code and R8A7779 USB common PHY driver, and so
> >>>>>spans both arch/arm/mach-shmobile/ and drivers/usb/ subtrees (some patches have
> >>>>>to touch both subtrees). The patches were conceived with the complete
> >>>>>bisectability goal in mind.
> 
> >>>>>[1/9] ARM: shmobile: Marzen: move USB EHCI, OHCI, and PHY devices to R8A7779 code
> >>>>>[2/9] ehci-platform: add pre_setup() method to platform data
> >>>>>[3/9] ARM: shmobile: R8A7779: setup EHCI internal buffer
> >>>>>[4/9] rcar-phy: remove EHCI internal buffer setup
> >>>>>[5/9] ARM: shmobile: R8A7779: remove USB PHY 2nd memory resource
> >>>>>[6/9] rcar-phy: correct base address
> >>>>>[7/9] rcar-phy: add platform data
> >>>>>[8/9] ARM: shmobile: Marzen: pass platform data to USB PHY device
> >>>>>[9/9] rcar-phy: handle platform data
> 
> >>>>>    I'm not sure thru which tree this patchset should be merged, however it turns
> >>>>>out that it's too late now to push it thru Felipe Balbi's USB tree for 3.10
> >>>>>(which would have been most convenient probably), and it's probably too late to
> >>>>>merge thru Simon's tree for 3.10 too. So it now have to be postponed to 3.11,
> >>>>>unfortunately...
> 
> >>>>Felipe, how would you prefer to handle this?
> >>>>I'm happy for you to take it or to take it myself.
> 
> >>>please take it yourself, just keep in mind there will be conflicts, I
> >>>will go over the patches now and give my Acked-by so you can queue them
> >>>up.
> 
> >>Thanks
> 
> >Sergei, it looks like patches 1-7 are clear.
> 
>    #7 & #9 have been refused by Felipe (hence #8 isn't good too).
> 
> >Do you want me to start queueing them up.
> 
>    I was going to repost the whole series soon, adding ACK from Alan
> to the patch #2 and resolving issues with patches #7..#9. It's worth
> waiting for that to happen I think.
> 
> >Or would you rather wait for the issue with patch 6 to be resolved?
> 
>    There's no special issue with patch #6 other than the PHY driver
> files being renamed in Felipe's tree -- but that concerns all patches
> touching drivers/usb/phy/rcar-phy.c (some of which precede #6).
>    I don't know how the rename conflict will be handled (this is
> really bad coincidence), perhaps I still should have done this
> patchset against Felipe's 'next' branch and pushed it thru his tree.
> If the patches will be queued for 3.11 anyway, maybe it's worth doing
> that -- I'm still of the opinion that his tree would be the one most
> fitting for this patchset.

git can handle renames well, don't worry. Conflict will be easy to
resolve.

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130411/0702ce2d/attachment.sig>

From arnd at arndb.de  Thu Apr 11 08:08:11 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 11 Apr 2013 14:08:11 +0200
Subject: [PATCH 12/30] video/exynos: remove unnecessary header inclusions
In-Reply-To: <5166A3DB.6060700@ti.com>
References: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
 <1365638712-1028578-13-git-send-email-arnd@arndb.de>
 <5166A3DB.6060700@ti.com>
Message-ID: <3895822.NrzbfBoRSl@wuerfel>

On Thursday 11 April 2013 14:51:55 Tomi Valkeinen wrote:

> I've applied this and the next patch ([PATCH 13/30] video/s3c: move
> platform_data out of arch/arm) to fbdev.
> 
> I also fixed the extra space mentioned by Jingoo.

Thanks!

	Arnd


From heiko at sntech.de  Thu Apr 11 08:09:01 2013
From: heiko at sntech.de (Heiko =?utf-8?q?St=C3=BCbner?=)
Date: Thu, 11 Apr 2013 14:09:01 +0200
Subject: [PATCH v3] pinctrl: Add pinctrl-s3c24xx driver
Message-ID: <201304111409.01983.heiko@sntech.de>

The s3c24xx pins follow a similar pattern as the other Samsung SoCs and
can therefore reuse the already introduced infrastructure.

The s3c24xx SoCs have one design oddity in that the first 4 external
interrupts do not reside in the eint pending register but in the main
interrupt controller instead. We solve this by forwarding the external
interrupt from the main controller into the irq domain of the pin bank.
The masking/acking of these interrupts is handled in the same way.

Furthermore the S3C2412/2413 SoCs contain another oddity in that they
keep the same 4 eints in the main interrupt controller and eintpend
register and requiring ack operations to happen in both. This is solved
by using different compatible properties for the wakeup eint node which
set a property accordingly.

Signed-off-by: Heiko Stuebner <heiko at sntech.de>
---
changes since v2:
- address more comments from Tomasz Figa:
  * remove obsolete ctrl_type references
  * remove redundant check for parent_chip
  * update docs and commit message

changes since v1:
- address comments from Tomasz Figa:
  * split handling functions for eints 0-3 for s3c2412 and all others
  * change the handling for s3c2412 eints 0-3 in that they now use
    chained_irq_* for the outer parent interrupt

 .../bindings/pinctrl/samsung-pinctrl.txt           |    8 +
 drivers/gpio/gpio-samsung.c                        |    4 +
 drivers/pinctrl/Kconfig                            |    5 +
 drivers/pinctrl/Makefile                           |    1 +
 drivers/pinctrl/pinctrl-s3c24xx.c                  |  664 ++++++++++++++++++++
 drivers/pinctrl/pinctrl-samsung.c                  |   10 +
 drivers/pinctrl/pinctrl-samsung.h                  |    4 +
 7 files changed, 696 insertions(+), 0 deletions(-)
 create mode 100644 drivers/pinctrl/pinctrl-s3c24xx.c

diff --git a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
index c70fca1..e4443e3 100644
--- a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
@@ -7,6 +7,10 @@ on-chip controllers onto these pads.
 
 Required Properties:
 - compatible: should be one of the following.
+  - "samsung,s3c2413-pinctrl": for S3C64xx-compatible pin-controller,
+  - "samsung,s3c2416-pinctrl": for S3C64xx-compatible pin-controller,
+  - "samsung,s3c2440-pinctrl": for S3C64xx-compatible pin-controller,
+  - "samsung,s3c2450-pinctrl": for S3C64xx-compatible pin-controller,
   - "samsung,s3c64xx-pinctrl": for S3C64xx-compatible pin-controller,
   - "samsung,exynos4210-pinctrl": for Exynos4210 compatible pin-controller.
   - "samsung,exynos4x12-pinctrl": for Exynos4x12 compatible pin-controller.
@@ -106,6 +110,10 @@ B. External Wakeup Interrupts: For supporting external wakeup interrupts, a
 
    - compatible: identifies the type of the external wakeup interrupt controller
      The possible values are:
+     - samsung,s3c2410-wakeup-eint: represents wakeup interrupt controller
+       found on Samsung S3C24xx SoCs except S3C2412 and S3C2413,
+     - samsung,s3c2412-wakeup-eint: represents wakeup interrupt controller
+       found on Samsung S3C2412 and S3C2413 SoCs,
      - samsung,s3c64xx-wakeup-eint: represents wakeup interrupt controller
        found on Samsung S3C64xx SoCs,
      - samsung,exynos4210-wakeup-eint: represents wakeup interrupt controller
diff --git a/drivers/gpio/gpio-samsung.c b/drivers/gpio/gpio-samsung.c
index dc06a6f..73017b9 100644
--- a/drivers/gpio/gpio-samsung.c
+++ b/drivers/gpio/gpio-samsung.c
@@ -3026,6 +3026,10 @@ static __init int samsung_gpiolib_init(void)
 	*/
 	struct device_node *pctrl_np;
 	static const struct of_device_id exynos_pinctrl_ids[] = {
+		{ .compatible = "samsung,s3c2413-pinctrl", },
+		{ .compatible = "samsung,s3c2416-pinctrl", },
+		{ .compatible = "samsung,s3c2440-pinctrl", },
+		{ .compatible = "samsung,s3c2450-pinctrl", },
 		{ .compatible = "samsung,s3c64xx-pinctrl", },
 		{ .compatible = "samsung,exynos4210-pinctrl", },
 		{ .compatible = "samsung,exynos4x12-pinctrl", },
diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index 7402ac9..58d73ac 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -226,6 +226,11 @@ config PINCTRL_EXYNOS5440
 	select PINMUX
 	select PINCONF
 
+config PINCTRL_S3C24XX
+	bool "Samsung S3C24XX SoC pinctrl driver"
+	depends on ARCH_S3C24XX
+	select PINCTRL_SAMSUNG
+
 config PINCTRL_S3C64XX
 	bool "Samsung S3C64XX SoC pinctrl driver"
 	depends on ARCH_S3C64XX
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index 21d34c2..1ccdfd8 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -45,6 +45,7 @@ obj-$(CONFIG_PINCTRL_COH901)	+= pinctrl-coh901.o
 obj-$(CONFIG_PINCTRL_SAMSUNG)	+= pinctrl-samsung.o
 obj-$(CONFIG_PINCTRL_EXYNOS)	+= pinctrl-exynos.o
 obj-$(CONFIG_PINCTRL_EXYNOS5440)	+= pinctrl-exynos5440.o
+obj-$(CONFIG_PINCTRL_S3C24XX)	+= pinctrl-s3c24xx.o
 obj-$(CONFIG_PINCTRL_S3C64XX)	+= pinctrl-s3c64xx.o
 obj-$(CONFIG_PINCTRL_XWAY)	+= pinctrl-xway.o
 obj-$(CONFIG_PINCTRL_LANTIQ)	+= pinctrl-lantiq.o
diff --git a/drivers/pinctrl/pinctrl-s3c24xx.c b/drivers/pinctrl/pinctrl-s3c24xx.c
new file mode 100644
index 0000000..4b03c8f
--- /dev/null
+++ b/drivers/pinctrl/pinctrl-s3c24xx.c
@@ -0,0 +1,664 @@
+/*
+ * S3C24XX specific support for Samsung pinctrl/gpiolib driver.
+ *
+ * Copyright (c) 2013 Heiko Stuebner <heiko at sntech.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.
+ *
+ * This file contains the SamsungS3C24XX specific information required by the
+ * the Samsung pinctrl/gpiolib driver. It also includes the implementation of
+ * external gpio and wakeup interrupt support.
+ */
+
+#include <linux/module.h>
+#include <linux/device.h>
+#include <linux/interrupt.h>
+#include <linux/irqdomain.h>
+#include <linux/irq.h>
+#include <linux/of_irq.h>
+#include <linux/io.h>
+#include <linux/slab.h>
+#include <linux/err.h>
+
+#include <asm/mach/irq.h>
+
+#include "pinctrl-samsung.h"
+
+#define NUM_EINT	24
+#define NUM_EINT_IRQ	6
+#define EINT_MAX_PER_GROUP	8
+
+#define EINTPEND_REG	0xa8
+#define EINTMASK_REG	0xa4
+
+#define EINT_GROUP(i)		((int)((i) / EINT_MAX_PER_GROUP))
+#define EINT_REG(i)		((EINT_GROUP(i) * 4) + 0x88)
+#define EINT_OFFS(i)		((i) % EINT_MAX_PER_GROUP * 4)
+
+#define EINT_LEVEL_LOW		0
+#define EINT_LEVEL_HIGH		1
+#define EINT_EDGE_FALLING	2
+#define EINT_EDGE_RISING	4
+#define EINT_EDGE_BOTH		6
+#define EINT_MASK		0xf
+
+static struct samsung_pin_bank_type bank_type_1bit = {
+	.fld_width = { 1, 1, },
+	.reg_offset = { 0x00, 0x04, },
+};
+
+static struct samsung_pin_bank_type bank_type_2bit = {
+	.fld_width = { 2, 1, 2, },
+	.reg_offset = { 0x00, 0x04, 0x08, },
+};
+
+#define PIN_BANK_A(pins, reg, id)		\
+	{						\
+		.type		= &bank_type_1bit,	\
+		.pctl_offset	= reg,			\
+		.nr_pins	= pins,			\
+		.eint_type	= EINT_TYPE_NONE,	\
+		.name		= id			\
+	}
+
+#define PIN_BANK_2BIT(pins, reg, id)		\
+	{						\
+		.type		= &bank_type_2bit,	\
+		.pctl_offset	= reg,			\
+		.nr_pins	= pins,			\
+		.eint_type	= EINT_TYPE_NONE,	\
+		.name		= id			\
+	}
+
+#define PIN_BANK_2BIT_EINTW(pins, reg, id, eoffs, emask)\
+	{						\
+		.type		= &bank_type_2bit,	\
+		.pctl_offset	= reg,			\
+		.nr_pins	= pins,			\
+		.eint_type	= EINT_TYPE_WKUP,	\
+		.eint_func	= 2,			\
+		.eint_mask	= emask,		\
+		.eint_offset	= eoffs,		\
+		.name		= id			\
+	}
+
+/**
+ * struct s3c24xx_eint_data: EINT common data
+ * @drvdata: pin controller driver data
+ * @domains: IRQ domains of particular EINT interrupts
+ * @parents: mapped parent irqs in the main interrupt controller
+ */
+struct s3c24xx_eint_data {
+	struct samsung_pinctrl_drv_data *drvdata;
+	struct irq_domain *domains[NUM_EINT];
+	int parents[NUM_EINT_IRQ];
+};
+
+/**
+ * struct s3c24xx_eint_domain_data: per irq-domain data
+ * @bank
+ * @eint_data: common data
+ * eint0_3_parent_only: live eints 0-3 only in the main intc
+ */
+struct s3c24xx_eint_domain_data {
+	struct samsung_pin_bank *bank;
+	struct s3c24xx_eint_data *eint_data;
+	bool eint0_3_parent_only;
+};
+
+static int s3c24xx_eint_get_trigger(unsigned int type)
+{
+	int trigger;
+
+	switch (type) {
+	case IRQ_TYPE_EDGE_RISING:
+		trigger = EINT_EDGE_RISING;
+		break;
+	case IRQ_TYPE_EDGE_FALLING:
+		trigger = EINT_EDGE_FALLING;
+		break;
+	case IRQ_TYPE_EDGE_BOTH:
+		trigger = EINT_EDGE_BOTH;
+		break;
+	case IRQ_TYPE_LEVEL_HIGH:
+		trigger = EINT_LEVEL_HIGH;
+		break;
+	case IRQ_TYPE_LEVEL_LOW:
+		trigger = EINT_LEVEL_LOW;
+		break;
+	default:
+		return -EINVAL;
+	}
+
+	return trigger;
+}
+
+static void s3c24xx_eint_set_handler(unsigned int irq, unsigned int type)
+{
+	/* Edge- and level-triggered interrupts need different handlers */
+	if (type & IRQ_TYPE_EDGE_BOTH)
+		__irq_set_handler_locked(irq, handle_edge_irq);
+	else
+		__irq_set_handler_locked(irq, handle_level_irq);
+}
+
+static void s3c24xx_eint_set_function(struct samsung_pinctrl_drv_data *d,
+					struct samsung_pin_bank *bank, int pin)
+{
+	struct samsung_pin_bank_type *bank_type = bank->type;
+	unsigned long flags;
+	void __iomem *reg;
+	u8 shift;
+	u32 mask;
+	u32 val;
+
+	/* Make sure that pin is configured as interrupt */
+	reg = d->virt_base + bank->pctl_offset;
+	shift = pin * bank_type->fld_width[PINCFG_TYPE_FUNC];
+	mask = (1 << bank_type->fld_width[PINCFG_TYPE_FUNC]) - 1;
+
+	spin_lock_irqsave(&bank->slock, flags);
+
+	val = readl(reg);
+	val &= ~(mask << shift);
+	val |= bank->eint_func << shift;
+	writel(val, reg);
+
+	spin_unlock_irqrestore(&bank->slock, flags);
+}
+
+static int s3c24xx_eint_type(struct irq_data *data, unsigned int type)
+{
+	struct samsung_pin_bank *bank = irq_data_get_irq_chip_data(data);
+	struct samsung_pinctrl_drv_data *d = bank->drvdata;
+	int index = bank->eint_offset + data->hwirq;
+	void __iomem *reg;
+	int trigger;
+	u8 shift;
+	u32 val;
+
+	trigger = s3c24xx_eint_get_trigger(type);
+	if (trigger < 0) {
+		dev_err(d->dev, "unsupported external interrupt type\n");
+		return -EINVAL;
+	}
+
+	s3c24xx_eint_set_handler(data->irq, type);
+
+	/* Set up interrupt trigger */
+	reg = d->virt_base + EINT_REG(index);
+	shift = EINT_OFFS(index);
+
+	val = readl(reg);
+	val &= ~(EINT_MASK << shift);
+	val |= trigger << shift;
+	writel(val, reg);
+
+	s3c24xx_eint_set_function(d, bank, data->hwirq);
+
+	return 0;
+}
+
+/* handling of EINTs 0-3 on all except S3C2412 and S3C2413 */
+
+static void s3c2410_eint0_3_ack(struct irq_data *data)
+{
+	struct samsung_pin_bank *bank = irq_data_get_irq_chip_data(data);
+	struct s3c24xx_eint_domain_data *ddata = bank->irq_domain->host_data;
+	struct s3c24xx_eint_data *eint_data = ddata->eint_data;
+	int parent_irq = eint_data->parents[data->hwirq];
+	struct irq_chip *parent_chip = irq_get_chip(parent_irq);
+
+	parent_chip->irq_ack(irq_get_irq_data(parent_irq));
+}
+
+static void s3c2410_eint0_3_mask(struct irq_data *data)
+{
+	struct samsung_pin_bank *bank = irq_data_get_irq_chip_data(data);
+	struct s3c24xx_eint_domain_data *ddata = bank->irq_domain->host_data;
+	struct s3c24xx_eint_data *eint_data = ddata->eint_data;
+	int parent_irq = eint_data->parents[data->hwirq];
+	struct irq_chip *parent_chip = irq_get_chip(parent_irq);
+
+	parent_chip->irq_mask(irq_get_irq_data(parent_irq));
+}
+
+static void s3c2410_eint0_3_unmask(struct irq_data *data)
+{
+	struct samsung_pin_bank *bank = irq_data_get_irq_chip_data(data);
+	struct s3c24xx_eint_domain_data *ddata = bank->irq_domain->host_data;
+	struct s3c24xx_eint_data *eint_data = ddata->eint_data;
+	int parent_irq = eint_data->parents[data->hwirq];
+	struct irq_chip *parent_chip = irq_get_chip(parent_irq);
+
+	parent_chip->irq_unmask(irq_get_irq_data(parent_irq));
+}
+
+static struct irq_chip s3c2410_eint0_3_chip = {
+	.name		= "s3c2410-eint0_3",
+	.irq_ack	= s3c2410_eint0_3_ack,
+	.irq_mask	= s3c2410_eint0_3_mask,
+	.irq_unmask	= s3c2410_eint0_3_unmask,
+	.irq_set_type	= s3c24xx_eint_type,
+};
+
+static void s3c2410_demux_eint0_3(unsigned int irq, struct irq_desc *desc)
+{
+	struct irq_data *data = irq_desc_get_irq_data(desc);
+	struct s3c24xx_eint_data *eint_data = irq_get_handler_data(irq);
+	unsigned int virq;
+
+	/* the first 4 eints have a simple 1 to 1 mapping */
+	virq = irq_linear_revmap(eint_data->domains[data->hwirq], data->hwirq);
+	/* Something must be really wrong if an unmapped EINT
+	 * was unmasked...
+	 */
+	BUG_ON(!virq);
+
+	generic_handle_irq(virq);
+}
+
+/* handling of EINTs 0-3 on S3C2412 and S3C2413 */
+
+static void s3c2412_eint0_3_ack(struct irq_data *data)
+{
+	struct samsung_pin_bank *bank = irq_data_get_irq_chip_data(data);
+	struct samsung_pinctrl_drv_data *d = bank->drvdata;
+
+	unsigned long bitval = 1UL << data->hwirq;
+	writel(bitval, d->virt_base + EINTPEND_REG);
+}
+
+static void s3c2412_eint0_3_mask(struct irq_data *data)
+{
+	struct samsung_pin_bank *bank = irq_data_get_irq_chip_data(data);
+	struct samsung_pinctrl_drv_data *d = bank->drvdata;
+	unsigned long mask;
+
+	mask = readl(d->virt_base + EINTMASK_REG);
+	mask |= (1UL << data->hwirq);
+	writel(mask, d->virt_base + EINTMASK_REG);
+}
+
+static void s3c2412_eint0_3_unmask(struct irq_data *data)
+{
+	struct samsung_pin_bank *bank = irq_data_get_irq_chip_data(data);
+	struct samsung_pinctrl_drv_data *d = bank->drvdata;
+	unsigned long mask;
+
+	mask = readl(d->virt_base + EINTMASK_REG);
+	mask &= ~(1UL << data->hwirq);
+	writel(mask, d->virt_base + EINTMASK_REG);
+}
+
+static struct irq_chip s3c2412_eint0_3_chip = {
+	.name		= "s3c2412-eint0_3",
+	.irq_ack	= s3c2412_eint0_3_ack,
+	.irq_mask	= s3c2412_eint0_3_mask,
+	.irq_unmask	= s3c2412_eint0_3_unmask,
+	.irq_set_type	= s3c24xx_eint_type,
+};
+
+static void s3c2412_demux_eint0_3(unsigned int irq, struct irq_desc *desc)
+{
+	struct irq_chip *chip = irq_get_chip(irq);
+	struct irq_data *data = irq_desc_get_irq_data(desc);
+	struct s3c24xx_eint_data *eint_data = irq_get_handler_data(irq);
+	unsigned int virq;
+
+	chained_irq_enter(chip, desc);
+
+	/* the first 4 eints have a simple 1 to 1 mapping */
+	virq = irq_linear_revmap(eint_data->domains[data->hwirq], data->hwirq);
+	/* Something must be really wrong if an unmapped EINT
+	 * was unmasked...
+	 */
+	BUG_ON(!virq);
+
+	generic_handle_irq(virq);
+
+	chained_irq_exit(chip, desc);
+}
+
+/* handling of all other eints */
+
+static void s3c24xx_eint_ack(struct irq_data *data)
+{
+	struct samsung_pin_bank *bank = irq_data_get_irq_chip_data(data);
+	struct samsung_pinctrl_drv_data *d = bank->drvdata;
+	unsigned char index = bank->eint_offset + data->hwirq;
+
+	writel(1UL << index, d->virt_base + EINTPEND_REG);
+}
+
+static void s3c24xx_eint_mask(struct irq_data *data)
+{
+	struct samsung_pin_bank *bank = irq_data_get_irq_chip_data(data);
+	struct samsung_pinctrl_drv_data *d = bank->drvdata;
+	unsigned char index = bank->eint_offset + data->hwirq;
+	unsigned long mask;
+
+	mask = readl(d->virt_base + EINTMASK_REG);
+	mask |= (1UL << index);
+	writel(mask, d->virt_base + EINTMASK_REG);
+}
+
+static void s3c24xx_eint_unmask(struct irq_data *data)
+{
+	struct samsung_pin_bank *bank = irq_data_get_irq_chip_data(data);
+	struct samsung_pinctrl_drv_data *d = bank->drvdata;
+	unsigned char index = bank->eint_offset + data->hwirq;
+	unsigned long mask;
+
+	mask = readl(d->virt_base + EINTMASK_REG);
+	mask &= ~(1UL << index);
+	writel(mask, d->virt_base + EINTMASK_REG);
+}
+
+static struct irq_chip s3c24xx_eint_chip = {
+	.name		= "s3c-eint",
+	.irq_ack	= s3c24xx_eint_ack,
+	.irq_mask	= s3c24xx_eint_mask,
+	.irq_unmask	= s3c24xx_eint_unmask,
+	.irq_set_type	= s3c24xx_eint_type,
+};
+
+static inline void s3c24xx_demux_eint(unsigned int irq, struct irq_desc *desc,
+				      u32 offset, u32 range)
+{
+	struct irq_chip *chip = irq_get_chip(irq);
+	struct s3c24xx_eint_data *data = irq_get_handler_data(irq);
+	struct samsung_pinctrl_drv_data *d = data->drvdata;
+	unsigned int pend, mask;
+
+	chained_irq_enter(chip, desc);
+
+	pend = readl(d->virt_base + EINTPEND_REG);
+	mask = readl(d->virt_base + EINTMASK_REG);
+
+	pend &= ~mask;
+	pend &= range;
+
+	while (pend) {
+		unsigned int virq;
+
+		irq = __ffs(pend);
+		pend &= ~(1 << irq);
+		virq = irq_linear_revmap(data->domains[irq], irq - offset);
+		/* Something must be really wrong if an unmapped EINT
+		 * was unmasked...
+		 */
+		BUG_ON(!virq);
+
+		generic_handle_irq(virq);
+	}
+
+	chained_irq_exit(chip, desc);
+}
+
+static void s3c24xx_demux_eint4_7(unsigned int irq, struct irq_desc *desc)
+{
+	s3c24xx_demux_eint(irq, desc, 0, 0xf0);
+}
+
+static void s3c24xx_demux_eint8_23(unsigned int irq, struct irq_desc *desc)
+{
+	s3c24xx_demux_eint(irq, desc, 8, 0xffff00);
+}
+
+static irq_flow_handler_t s3c2410_eint_handlers[NUM_EINT_IRQ] = {
+	s3c2410_demux_eint0_3,
+	s3c2410_demux_eint0_3,
+	s3c2410_demux_eint0_3,
+	s3c2410_demux_eint0_3,
+	s3c24xx_demux_eint4_7,
+	s3c24xx_demux_eint8_23,
+};
+
+static irq_flow_handler_t s3c2412_eint_handlers[NUM_EINT_IRQ] = {
+	s3c2412_demux_eint0_3,
+	s3c2412_demux_eint0_3,
+	s3c2412_demux_eint0_3,
+	s3c2412_demux_eint0_3,
+	s3c24xx_demux_eint4_7,
+	s3c24xx_demux_eint8_23,
+};
+
+static int s3c24xx_gpf_irq_map(struct irq_domain *h, unsigned int virq,
+					irq_hw_number_t hw)
+{
+	struct s3c24xx_eint_domain_data *ddata = h->host_data;
+	struct samsung_pin_bank *bank = ddata->bank;
+
+	if (!(bank->eint_mask & (1 << (bank->eint_offset + hw))))
+		return -EINVAL;
+
+	if (hw <= 3) {
+		if (ddata->eint0_3_parent_only)
+			irq_set_chip_and_handler(virq, &s3c2410_eint0_3_chip,
+						 handle_edge_irq);
+		else
+			irq_set_chip_and_handler(virq, &s3c2412_eint0_3_chip,
+						 handle_edge_irq);
+	} else {
+		irq_set_chip_and_handler(virq, &s3c24xx_eint_chip,
+					 handle_edge_irq);
+	}
+	irq_set_chip_data(virq, bank);
+	set_irq_flags(virq, IRQF_VALID);
+	return 0;
+}
+
+static const struct irq_domain_ops s3c24xx_gpf_irq_ops = {
+	.map	= s3c24xx_gpf_irq_map,
+	.xlate	= irq_domain_xlate_twocell,
+};
+
+static int s3c24xx_gpg_irq_map(struct irq_domain *h, unsigned int virq,
+					irq_hw_number_t hw)
+{
+	struct s3c24xx_eint_domain_data *ddata = h->host_data;
+	struct samsung_pin_bank *bank = ddata->bank;
+
+	if (!(bank->eint_mask & (1 << (bank->eint_offset + hw))))
+		return -EINVAL;
+
+	irq_set_chip_and_handler(virq, &s3c24xx_eint_chip, handle_edge_irq);
+	irq_set_chip_data(virq, bank);
+	set_irq_flags(virq, IRQF_VALID);
+	return 0;
+}
+
+static const struct irq_domain_ops s3c24xx_gpg_irq_ops = {
+	.map	= s3c24xx_gpg_irq_map,
+	.xlate	= irq_domain_xlate_twocell,
+};
+
+static const struct of_device_id s3c24xx_eint_irq_ids[] = {
+	{ .compatible = "samsung,s3c2410-wakeup-eint", .data = (void *)1 },
+	{ .compatible = "samsung,s3c2412-wakeup-eint", .data = (void *)0 },
+	{ }
+};
+
+static int s3c24xx_eint_init(struct samsung_pinctrl_drv_data *d)
+{
+	struct device *dev = d->dev;
+	const struct of_device_id *match;
+	struct device_node *eint_np = NULL;
+	struct device_node *np;
+	struct samsung_pin_bank *bank;
+	struct s3c24xx_eint_data *eint_data;
+	const struct irq_domain_ops *ops;
+	unsigned int i;
+	bool eint0_3_parent_only;
+	irq_flow_handler_t *handlers;
+
+	for_each_child_of_node(dev->of_node, np) {
+		match = of_match_node(s3c24xx_eint_irq_ids, np);
+		if (match) {
+			eint_np = np;
+			eint0_3_parent_only = (bool)match->data;
+			break;
+		}
+	}
+	if (!eint_np)
+		return -ENODEV;
+
+	eint_data = devm_kzalloc(dev, sizeof(*eint_data), GFP_KERNEL);
+	if (!eint_data) {
+		dev_err(dev, "could not allocate memory for wkup eint data\n");
+		return -ENOMEM;
+	}
+	eint_data->drvdata = d;
+
+	handlers = eint0_3_parent_only ? s3c2410_eint_handlers
+				       : s3c2412_eint_handlers;
+	for (i = 0; i < NUM_EINT_IRQ; ++i) {
+		unsigned int irq;
+
+		irq = irq_of_parse_and_map(eint_np, i);
+		if (!irq) {
+			dev_err(dev, "failed to get wakeup EINT IRQ %d\n", i);
+			return -ENXIO;
+		}
+
+		eint_data->parents[i] = irq;
+		irq_set_chained_handler(irq, handlers[i]);
+		irq_set_handler_data(irq, eint_data);
+	}
+
+	bank = d->ctrl->pin_banks;
+	for (i = 0; i < d->ctrl->nr_banks; ++i, ++bank) {
+		struct s3c24xx_eint_domain_data *ddata;
+		unsigned int mask;
+		unsigned int irq;
+		unsigned int pin;
+
+		if (bank->eint_type != EINT_TYPE_WKUP)
+			continue;
+
+		ddata = devm_kzalloc(dev, sizeof(*ddata), GFP_KERNEL);
+		if (!ddata) {
+			dev_err(dev, "failed to allocate domain data\n");
+			return -ENOMEM;
+		}
+		ddata->bank = bank;
+		ddata->eint_data = eint_data;
+		ddata->eint0_3_parent_only = eint0_3_parent_only;
+
+		ops = (bank->eint_offset == 0) ? &s3c24xx_gpf_irq_ops
+					       : &s3c24xx_gpg_irq_ops;
+
+		bank->irq_domain = irq_domain_add_linear(bank->of_node,
+				bank->nr_pins, ops, ddata);
+		if (!bank->irq_domain) {
+			dev_err(dev, "wkup irq domain add failed\n");
+			return -ENXIO;
+		}
+
+		irq = bank->eint_offset;
+		mask = bank->eint_mask;
+		for (pin = 0; mask; ++pin, mask >>= 1) {
+			if (irq > NUM_EINT)
+				break;
+			if (!(mask & 1))
+				continue;
+			eint_data->domains[irq] = bank->irq_domain;
+			++irq;
+		}
+	}
+
+	return 0;
+}
+
+static struct samsung_pin_bank s3c2413_pin_banks[] = {
+	PIN_BANK_A(23, 0x000, "gpa"),
+	PIN_BANK_2BIT(11, 0x010, "gpb"),
+	PIN_BANK_2BIT(16, 0x020, "gpc"),
+	PIN_BANK_2BIT(16, 0x030, "gpd"),
+	PIN_BANK_2BIT(16, 0x040, "gpe"),
+	PIN_BANK_2BIT_EINTW(8, 0x050, "gpf", 0, 0xff),
+	PIN_BANK_2BIT_EINTW(16, 0x060, "gpg", 8, 0xffff00),
+	PIN_BANK_2BIT(11, 0x070, "gph"),
+	PIN_BANK_2BIT(13, 0x080, "gpj"),
+};
+
+struct samsung_pin_ctrl s3c2413_pin_ctrl[] = {
+	{
+		.pin_banks	= s3c2413_pin_banks,
+		.nr_banks	= ARRAY_SIZE(s3c2413_pin_banks),
+		.eint_wkup_init = s3c24xx_eint_init,
+		.label		= "S3C2413-GPIO",
+	},
+};
+
+static struct samsung_pin_bank s3c2416_pin_banks[] = {
+	PIN_BANK_A(27, 0x000, "gpa"),
+	PIN_BANK_2BIT(11, 0x010, "gpb"),
+	PIN_BANK_2BIT(16, 0x020, "gpc"),
+	PIN_BANK_2BIT(16, 0x030, "gpd"),
+	PIN_BANK_2BIT(16, 0x040, "gpe"),
+	PIN_BANK_2BIT_EINTW(8, 0x050, "gpf", 0, 0xff),
+	PIN_BANK_2BIT_EINTW(8, 0x060, "gpg", 8, 0xff00),
+	PIN_BANK_2BIT(15, 0x070, "gph"),
+	PIN_BANK_2BIT(16, 0x0e0, "gpk"),
+	PIN_BANK_2BIT(14, 0x0f0, "gpl"),
+	PIN_BANK_2BIT(2, 0x100, "gpm"),
+};
+
+struct samsung_pin_ctrl s3c2416_pin_ctrl[] = {
+	{
+		.pin_banks	= s3c2416_pin_banks,
+		.nr_banks	= ARRAY_SIZE(s3c2416_pin_banks),
+		.eint_wkup_init = s3c24xx_eint_init,
+		.label		= "S3C2416-GPIO",
+	},
+};
+
+static struct samsung_pin_bank s3c2440_pin_banks[] = {
+	PIN_BANK_A(25, 0x000, "gpa"),
+	PIN_BANK_2BIT(11, 0x010, "gpb"),
+	PIN_BANK_2BIT(16, 0x020, "gpc"),
+	PIN_BANK_2BIT(16, 0x030, "gpd"),
+	PIN_BANK_2BIT(16, 0x040, "gpe"),
+	PIN_BANK_2BIT_EINTW(8, 0x050, "gpf", 0, 0xff),
+	PIN_BANK_2BIT_EINTW(16, 0x060, "gpg", 8, 0xffff00),
+	PIN_BANK_2BIT(11, 0x070, "gph"),
+	PIN_BANK_2BIT(13, 0x0d0, "gpj"),
+};
+
+struct samsung_pin_ctrl s3c2440_pin_ctrl[] = {
+	{
+		.pin_banks	= s3c2440_pin_banks,
+		.nr_banks	= ARRAY_SIZE(s3c2440_pin_banks),
+		.eint_wkup_init = s3c24xx_eint_init,
+		.label		= "S3C2440-GPIO",
+	},
+};
+
+static struct samsung_pin_bank s3c2450_pin_banks[] = {
+	PIN_BANK_A(28, 0x000, "gpa"),
+	PIN_BANK_2BIT(11, 0x010, "gpb"),
+	PIN_BANK_2BIT(16, 0x020, "gpc"),
+	PIN_BANK_2BIT(16, 0x030, "gpd"),
+	PIN_BANK_2BIT(16, 0x040, "gpe"),
+	PIN_BANK_2BIT_EINTW(8, 0x050, "gpf", 0, 0xff),
+	PIN_BANK_2BIT_EINTW(16, 0x060, "gpg", 8, 0xffff00),
+	PIN_BANK_2BIT(15, 0x070, "gph"),
+	PIN_BANK_2BIT(16, 0x0d0, "gpj"),
+	PIN_BANK_2BIT(16, 0x0e0, "gpk"),
+	PIN_BANK_2BIT(15, 0x0f0, "gpl"),
+	PIN_BANK_2BIT(2, 0x100, "gpm"),
+};
+
+struct samsung_pin_ctrl s3c2450_pin_ctrl[] = {
+	{
+		.pin_banks	= s3c2450_pin_banks,
+		.nr_banks	= ARRAY_SIZE(s3c2450_pin_banks),
+		.eint_wkup_init = s3c24xx_eint_init,
+		.label		= "S3C2450-GPIO",
+	},
+};
diff --git a/drivers/pinctrl/pinctrl-samsung.c b/drivers/pinctrl/pinctrl-samsung.c
index e836135..234c32f 100644
--- a/drivers/pinctrl/pinctrl-samsung.c
+++ b/drivers/pinctrl/pinctrl-samsung.c
@@ -977,6 +977,16 @@ static const struct of_device_id samsung_pinctrl_dt_match[] = {
 	{ .compatible = "samsung,s3c64xx-pinctrl",
 		.data = s3c64xx_pin_ctrl },
 #endif
+#ifdef CONFIG_PINCTRL_S3C24XX
+	{ .compatible = "samsung,s3c2413-pinctrl",
+		.data = s3c2413_pin_ctrl },
+	{ .compatible = "samsung,s3c2416-pinctrl",
+		.data = s3c2416_pin_ctrl },
+	{ .compatible = "samsung,s3c2440-pinctrl",
+		.data = s3c2440_pin_ctrl },
+	{ .compatible = "samsung,s3c2450-pinctrl",
+		.data = s3c2450_pin_ctrl },
+#endif
 	{},
 };
 MODULE_DEVICE_TABLE(of, samsung_pinctrl_dt_match);
diff --git a/drivers/pinctrl/pinctrl-samsung.h b/drivers/pinctrl/pinctrl-samsung.h
index 7c7f9eb..c79d634 100644
--- a/drivers/pinctrl/pinctrl-samsung.h
+++ b/drivers/pinctrl/pinctrl-samsung.h
@@ -246,5 +246,9 @@ extern struct samsung_pin_ctrl exynos4210_pin_ctrl[];
 extern struct samsung_pin_ctrl exynos4x12_pin_ctrl[];
 extern struct samsung_pin_ctrl exynos5250_pin_ctrl[];
 extern struct samsung_pin_ctrl s3c64xx_pin_ctrl[];
+extern struct samsung_pin_ctrl s3c2413_pin_ctrl[];
+extern struct samsung_pin_ctrl s3c2416_pin_ctrl[];
+extern struct samsung_pin_ctrl s3c2440_pin_ctrl[];
+extern struct samsung_pin_ctrl s3c2450_pin_ctrl[];
 
 #endif /* __PINCTRL_SAMSUNG_H */
-- 
1.7.2.3



From andrew.murray at arm.com  Thu Apr 11 08:12:42 2013
From: andrew.murray at arm.com (Andrew Murray)
Date: Thu, 11 Apr 2013 13:12:42 +0100
Subject: [PATCH v5 1/3] of/pci: Unify pci_process_bridge_OF_ranges from
 Microblaze and PowerPC
In-Reply-To: <20130410233330.4e9479b0@skate>
References: <1365578969-30966-1-git-send-email-Andrew.Murray@arm.com>
 <1365578969-30966-2-git-send-email-Andrew.Murray@arm.com>
 <20130410233330.4e9479b0@skate>
Message-ID: <20130411121242.GB28981@arm.com>

On Wed, Apr 10, 2013 at 10:33:30PM +0100, Thomas Petazzoni wrote:
> Dear Andrew Murray,
> 
> On Wed, 10 Apr 2013 08:29:26 +0100, Andrew Murray wrote:
> 
> > diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
> > index bb115de..6852481 100644
> > --- a/include/linux/of_pci.h
> > +++ b/include/linux/of_pci.h
> > @@ -11,4 +11,7 @@ struct device_node;
> >  struct device_node *of_pci_find_child_device(struct device_node *parent,
> >  					     unsigned int devfn);
> >  
> > +void pci_process_bridge_OF_ranges(struct pci_controller *hose,
> > +			struct device_node *dev, int primary);
> > +
> >  #endif
> 
> In this file, 'struct pci_controller' is not defined anywhere, and not
> in any header file that is included. So I get a warning at compile time
> when <linux/of_pci.h> is included, but nothing has defined 'struct
> pci_controller' beforehand. So I think this file should carry a change
> like:
> 
> +struct pci_controller;
> 
> In my version of the patch I added it, see:
> 
> diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
> index bb115de..e56182f 100644
> --- a/include/linux/of_pci.h
> +++ b/include/linux/of_pci.h
> @@ -4,6 +4,7 @@
>  #include <linux/pci.h>
>  
>  struct pci_dev;
> +struct pci_controller;
>  struct of_irq;
>  int of_irq_map_pci(const struct pci_dev *pdev, struct of_irq *out_irq);
>  
> @@ -11,4 +12,7 @@ struct device_node;
>  struct device_node *of_pci_find_child_device(struct device_node *parent,
>  					     unsigned int devfn);
>  
> +void pci_process_bridge_OF_ranges(struct pci_controller *hose,
> +			struct device_node *dev, int primary);
> +
>  #endif
> 
> But otherwise, for PATCH 1/3 and 2/3,

Thanks - I somehow missed this.

I've included this change in my next respin - but I've put
'struct pci_controller' immediately before 'pci_process_bridge_OF_ranges'
rather than above of_irq_map_pci to be consistent with the rest of the file.

Andrew Murray


> 
> Tested-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> 
> Thomas
> -- 
> Thomas Petazzoni, Free Electrons
> Kernel, drivers, real-time and embedded Linux
> development, consulting, training and support.
> http://free-electrons.com
> 


From t.figa at samsung.com  Thu Apr 11 08:12:57 2013
From: t.figa at samsung.com (Tomasz Figa)
Date: Thu, 11 Apr 2013 14:12:57 +0200
Subject: [PATCH v3] pinctrl: Add pinctrl-s3c24xx driver
In-Reply-To: <201304111409.01983.heiko@sntech.de>
References: <201304111409.01983.heiko@sntech.de>
Message-ID: <1706031.H7t4gja446@amdc1227>

Hi Heiko,

On Thursday 11 of April 2013 14:09:01 Heiko St?bner wrote:
> The s3c24xx pins follow a similar pattern as the other Samsung SoCs and
> can therefore reuse the already introduced infrastructure.
> 
> The s3c24xx SoCs have one design oddity in that the first 4 external
> interrupts do not reside in the eint pending register but in the main
> interrupt controller instead. We solve this by forwarding the external
> interrupt from the main controller into the irq domain of the pin bank.
> The masking/acking of these interrupts is handled in the same way.
> 
> Furthermore the S3C2412/2413 SoCs contain another oddity in that they
> keep the same 4 eints in the main interrupt controller and eintpend
> register and requiring ack operations to happen in both. This is solved
> by using different compatible properties for the wakeup eint node which
> set a property accordingly.
> 
> Signed-off-by: Heiko Stuebner <heiko at sntech.de>
> ---
> changes since v2:
> - address more comments from Tomasz Figa:
>   * remove obsolete ctrl_type references
>   * remove redundant check for parent_chip
>   * update docs and commit message
> 
> changes since v1:
> - address comments from Tomasz Figa:
>   * split handling functions for eints 0-3 for s3c2412 and all others
>   * change the handling for s3c2412 eints 0-3 in that they now use
>     chained_irq_* for the outer parent interrupt
> 
>  .../bindings/pinctrl/samsung-pinctrl.txt           |    8 +
>  drivers/gpio/gpio-samsung.c                        |    4 +
>  drivers/pinctrl/Kconfig                            |    5 +
>  drivers/pinctrl/Makefile                           |    1 +
>  drivers/pinctrl/pinctrl-s3c24xx.c                  |  664
> ++++++++++++++++++++ drivers/pinctrl/pinctrl-samsung.c                  |  
> 10 +
>  drivers/pinctrl/pinctrl-samsung.h                  |    4 +
>  7 files changed, 696 insertions(+), 0 deletions(-)
>  create mode 100644 drivers/pinctrl/pinctrl-s3c24xx.c

Looks good to me, thanks for the patch.

Reviewed-by: Tomasz Figa <t.figa at samsung.com>

Best regards,
-- 
Tomasz Figa
Samsung Poland R&D Center
SW Solution Development, Kernel and System Framework



From sergei.shtylyov at cogentembedded.com  Thu Apr 11 08:20:49 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Thu, 11 Apr 2013 16:20:49 +0400
Subject: [PATCH v3 0/9] Reorganize R8A7779/Marzen USB code
In-Reply-To: <20130411120649.GM14394@arwen.pp.htv.fi>
References: <201304100226.08967.sergei.shtylyov@cogentembedded.com>
 <20130410044923.GD10044@verge.net.au> <20130410085033.GL7983@arwen.pp.htv.fi>
 <20130410090543.GB25890@verge.net.au> <20130411005155.GA18530@verge.net.au>
 <5166A659.6060405@cogentembedded.com>
 <20130411120649.GM14394@arwen.pp.htv.fi>
Message-ID: <5166AAA1.3060905@cogentembedded.com>

Hello.

On 11-04-2013 16:06, Felipe Balbi wrote:

>>>>>>>     Here's the set of 9 patches against the Simon Horman's 'renesas.git' repo,
>>>>>>> 'renesas-next-20130410' tag.  It was created to fix the shortcomings in the
>>>>>>> R8A7779/Marzen USB platform code and R8A7779 USB common PHY driver, and so
>>>>>>> spans both arch/arm/mach-shmobile/ and drivers/usb/ subtrees (some patches have
>>>>>>> to touch both subtrees). The patches were conceived with the complete
>>>>>>> bisectability goal in mind.

>>>>>>> [1/9] ARM: shmobile: Marzen: move USB EHCI, OHCI, and PHY devices to R8A7779 code
>>>>>>> [2/9] ehci-platform: add pre_setup() method to platform data
>>>>>>> [3/9] ARM: shmobile: R8A7779: setup EHCI internal buffer
>>>>>>> [4/9] rcar-phy: remove EHCI internal buffer setup
>>>>>>> [5/9] ARM: shmobile: R8A7779: remove USB PHY 2nd memory resource
>>>>>>> [6/9] rcar-phy: correct base address
>>>>>>> [7/9] rcar-phy: add platform data
>>>>>>> [8/9] ARM: shmobile: Marzen: pass platform data to USB PHY device
>>>>>>> [9/9] rcar-phy: handle platform data

>>>>>>>     I'm not sure thru which tree this patchset should be merged, however it turns
>>>>>>> out that it's too late now to push it thru Felipe Balbi's USB tree for 3.10
>>>>>>> (which would have been most convenient probably), and it's probably too late to
>>>>>>> merge thru Simon's tree for 3.10 too. So it now have to be postponed to 3.11,
>>>>>>> unfortunately...

>>>>>> Felipe, how would you prefer to handle this?
>>>>>> I'm happy for you to take it or to take it myself.

>>>>> please take it yourself, just keep in mind there will be conflicts, I
>>>>> will go over the patches now and give my Acked-by so you can queue them
>>>>> up.

>>>> Thanks

>>> Sergei, it looks like patches 1-7 are clear.

>>     #7 & #9 have been refused by Felipe (hence #8 isn't good too).

>>> Do you want me to start queueing them up.

>>     I was going to repost the whole series soon, adding ACK from Alan
>> to the patch #2 and resolving issues with patches #7..#9. It's worth
>> waiting for that to happen I think.

>>> Or would you rather wait for the issue with patch 6 to be resolved?

>>     There's no special issue with patch #6 other than the PHY driver
>> files being renamed in Felipe's tree -- but that concerns all patches
>> touching drivers/usb/phy/rcar-phy.c (some of which precede #6).
>>     I don't know how the rename conflict will be handled (this is
>> really bad coincidence), perhaps I still should have done this
>> patchset against Felipe's 'next' branch and pushed it thru his tree.
>> If the patches will be queued for 3.11 anyway, maybe it's worth doing
>> that -- I'm still of the opinion that his tree would be the one most
>> fitting for this patchset.

> git can handle renames well, don't worry. Conflict will be easy to
> resolve.

    I'm adding a header file to include/linux/usb/ which now should probably 
be renamed too, after the driver, to 'phy-rcar-usb.h'. I prbably should rename 
it now, in anticipation, or the one who would resolve the conflict, won't 
figure it out to do it. Or perhaps indeed patches #1..#6 can be merged now, 
and the rest postponed...

WBR, Sergei



From arnd at arndb.de  Thu Apr 11 08:30:05 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 11 Apr 2013 14:30:05 +0200
Subject: [RFC PATCHv2 arm: initial TI-Nspire support]
In-Reply-To: <8E071E2D-4FF3-487E-A53B-B6A7C427E421@gmail.com>
References: <8E071E2D-4FF3-487E-A53B-B6A7C427E421@gmail.com>
Message-ID: <201304111430.05528.arnd@arndb.de>

On Thursday 11 April 2013, Daniel Tang wrote:
> This is another updated patch for Linux on TI-Nspire support. 
> 
> Apologies for previously posting updated patches as replies to the first thread. I'll send updated patches in new threads from now to avoid confusion.
> 
> Changes between http://archive.arm.linux.org.uk/lurker/message/20130408.113343.585af217.en.html and v2:
> * Added new drivers to support the irqchip and timers on older models.
> * Added new device trees to support the other models.
> 
> Signed-off-by: Daniel Tang <dt.tangr at gmail.com>

Nice!

>  arch/arm/Kconfig                            |   2 +
>  arch/arm/Kconfig.debug                      |  16 ++
>  arch/arm/Makefile                           |   1 +
>  arch/arm/boot/dts/Makefile                  |   3 +
>  arch/arm/boot/dts/nspire-classic.dtsi       |  68 ++++++
>  arch/arm/boot/dts/nspire-clp.dts            |  45 ++++
>  arch/arm/boot/dts/nspire-cx.dts             | 115 ++++++++++
>  arch/arm/boot/dts/nspire-tp.dts             |  44 ++++
>  arch/arm/boot/dts/nspire.dtsi               | 159 ++++++++++++++
>  arch/arm/include/debug/nspire.S             |  28 +++
>  arch/arm/mach-nspire/Kconfig                |  15 ++
>  arch/arm/mach-nspire/Makefile               |   2 +
>  arch/arm/mach-nspire/Makefile.boot          |   0
>  arch/arm/mach-nspire/clcd.c                 | 118 +++++++++++
>  arch/arm/mach-nspire/clcd.h                 |  14 ++
>  arch/arm/mach-nspire/mmio.h                 |  15 ++
>  arch/arm/mach-nspire/nspire.c               | 142 +++++++++++++
>  drivers/clocksource/Makefile                |   1 +
>  drivers/clocksource/nspire-classic-timer.c  | 216 +++++++++++++++++++
>  drivers/input/keyboard/Kconfig              |  10 +
>  drivers/input/keyboard/Makefile             |   1 +
>  drivers/input/keyboard/nspire-keypad.c      | 316 ++++++++++++++++++++++++++++
>  drivers/irqchip/Makefile                    |   1 +
>  drivers/irqchip/irq-nspire-classic.c        | 177 ++++++++++++++++
>  include/clocksource/nspire_classic_timer.h  |  16 ++
>  include/linux/platform_data/nspire-keypad.h |  28 +++
>  26 files changed, 1553 insertions(+)

Please split this up into a series of patches, one for each subsystem.
I would also keep the dts files in a separate patch from the platform
code.


> +bool timer_init;
> +
> +void __init nspire_classic_timer_init(void)
> +{
> +	struct device_node *node;
> +
> +	if (timer_init)
> +		return;
> +
> +	for_each_compatible_node(node, NULL, DT_COMPAT) {
> +		nspire_timer_add(node);
> +	}
> +
> +	timer_init = 1;
> +}
> +
> +CLOCKSOURCE_OF_DECLARE(nspire_classic_timer,
> +		DT_COMPAT, nspire_classic_timer_init)

Why do you need the logic to prevent it from being initilized
twice?  Can't you just remove the direct call to nspire_classic_timer_init
from platform code and rely on of_clk_init() to call it?

Note that the interface has changed in linux-next, you now
get called separately for each matching device, with the device_node
as the argument, so you no longer have to search the device tree,
and can essentially do

CLOCKSOURCE_OF_DECLARE(nspire_classic_timer, DT_COMPAT, nspire_timer_add);

Feel free to rebase your patch on top of the clksrc/cleanup branch
in arm-soc to get the new behavior.

> +#ifdef CONFIG_OF
> +static const struct of_device_id nspire_keypad_dt_match[] = {
> +	{ .compatible = "nspire-keypad" },
> +	{ },
> +};
> +MODULE_DEVICE_TABLE(of, nspire_keypad_dt_match);
> +#endif

You should not need the #ifdef.

> +static struct platform_driver nspire_keypad_driver = {
> +	.driver = {
> +		.name = "nspire-keypad",
> +		.owner  = THIS_MODULE,
> +		.of_match_table = of_match_ptr(nspire_keypad_dt_match),
> +	},
> +	.remove = nspire_keypad_remove,
> +	.probe = nspire_keypad_probe
> +};

Please put a comma at the end of the last line in definitions like this.

> diff --git a/include/clocksource/nspire_classic_timer.h b/include/clocksource/nspire_classic_timer.h
> new file mode 100644
> index 0000000..39236f1
> --- /dev/null
> +++ b/include/clocksource/nspire_classic_timer.h

You should not need this file if you do the above.

> diff --git a/include/linux/platform_data/nspire-keypad.h b/include/linux/platform_data/nspire-keypad.h
> new file mode 100644
> index 0000000..03deb64
> --- /dev/null
> +++ b/include/linux/platform_data/nspire-keypad.h

And this file now also isn't needed any more, you can just merge the
fields of struct nspire_keypad_data into struct nspire_keypad.

	Arnd


From p.zabel at pengutronix.de  Thu Apr 11 08:37:09 2013
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Thu, 11 Apr 2013 14:37:09 +0200
Subject: [GIT PULL v2] Reset controller API
In-Reply-To: <CAOesGMidoasD35LL4VvCUPwTPrrRE9hxPGUVmuGQtuvH_nxs0g@mail.gmail.com>
References: <1365495574.4023.32.camel@pizza.hi.pengutronix.de>
 <20130411102047.GA7437@quad.lixom.net>
 <CAOesGMidoasD35LL4VvCUPwTPrrRE9hxPGUVmuGQtuvH_nxs0g@mail.gmail.com>
Message-ID: <1365683829.4388.52.camel@pizza.hi.pengutronix.de>

Hi Olof,

Am Donnerstag, den 11.04.2013, 03:25 -0700 schrieb Olof Johansson:
> On Thu, Apr 11, 2013 at 3:20 AM, Olof Johansson <olof at lixom.net> wrote:
> > On Tue, Apr 09, 2013 at 10:19:34AM +0200, Philipp Zabel wrote:
> >> Hi Olof,
> >>
> >> I have added two fixes on top of the reset series at
> >> git://git.pengutronix.de/git/pza/linux.git reset/for_v3.10.
> >> Could you pull them in together with the rest?
> >>
> >> The following changes since commit 8bb9660418e05bb1845ac1a2428444d78e322cc7:
> >>
> >>   Linux 3.9-rc4 (2013-03-23 16:52:44 -0700)
> >>
> >> are available in the git repository at:
> >>
> >>   git://git.pengutronix.de/git/pza/linux.git reset/for_v3.10
> >>
> >> for you to fetch changes up to fbdb93ecb869f02a5f8f145fa06a0984c415a7d4:
> >>
> >>   Documentation: gpio-reset.txt: Fix 'initially-in-reset' example (2013-04-09 09:55:00 +0200)
> >>
> >> They add a simple API for devices to request being reset by separate
> >> reset controller hardware and implement the reset signal device tree
> >> bindings proposed by Stephen Warren.
> >> The patches have been discussed on the linux-arm-kernel list under the topic
> >> "Reset controller API to reset IP modules on i.MX5 and i.MX6".
> >>
> >> ----------------------------------------------------------------
> >> Dan Carpenter (1):
> >>       reset: NULL deref on allocation failure
> >>
> >> Fabio Estevam (1):
> >>       Documentation: gpio-reset.txt: Fix 'initially-in-reset' example
> >>
> >> Philipp Zabel (2):
> >>       reset: Add reset controller API
> >>       reset: Add driver for gpio-controlled reset pins
> >>
> >> Stephen Warren (1):
> >>       dt: describe base reset signal binding
> >
> > Hmm, I don't see an ack or reviewed-by on these subsystem bindings from
> > neither Rob nor Grant.
> >
> > Since it's a brand new subsystem binding, I'd like to see them ack it
> > before we pick it up.
> 
> Sigh. Ok, so I now stumbled across the Ack from Rob that you didn't
> pick up. Don't do it like that again, please. If Shawn prematurely
> bases his code on top of unacked patches, then that's his problem, not
> yours.

Sorry I didn't notice that Rob's ack didn't have you in Cc. So shall I
leave the dt binding patch untouched this time? I'll take note of this
for the future.

> The problem still remains though, since the gpio-reset binding hasn't
> seen an ack on the list, as far as I can tell. And I'll have a comment
> on that as well in a minute, see separate reply on that patch.

Ok. What would you have me do now? I could revert the gpio-reset patch
(possibly asking Shawn to pull that, too), and have it do another round
on the list instead. Or I could address your comments with a relative
patch, and put that on top.

thanks
Philipp



From p.zabel at pengutronix.de  Thu Apr 11 08:37:16 2013
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Thu, 11 Apr 2013 14:37:16 +0200
Subject: [PATCH v6 3/8] reset: Add driver for gpio-controlled reset pins
In-Reply-To: <CAOesGMgo61M=oxG6_6EEGu7kL3Wa+HsdEomCxUnvj-Rbdhujgg@mail.gmail.com>
References: <1364488523-20310-1-git-send-email-p.zabel@pengutronix.de>
 <1364488523-20310-4-git-send-email-p.zabel@pengutronix.de>
 <CAOesGMgo61M=oxG6_6EEGu7kL3Wa+HsdEomCxUnvj-Rbdhujgg@mail.gmail.com>
Message-ID: <1365683836.4388.54.camel@pizza.hi.pengutronix.de>

Hi Olof,

Am Donnerstag, den 11.04.2013, 03:35 -0700 schrieb Olof Johansson:
> Hi,
> 
> On Thu, Mar 28, 2013 at 9:35 AM, Philipp Zabel <p.zabel at pengutronix.de> wrote:
> > This driver implements a reset controller device that toggles gpios
> > connected to reset pins of peripheral ICs. The delay between assertion
> > and de-assertion of the reset signal can be configured.
> >
> > Signed-off-by: Philipp Zabel <p.zabel at pengutronix.de>
> > Reviewed-by: Stephen Warren <swarren at nvidia.com>
> > Reviewed-by: Marek Vasut <marex at denx.de>
> > Reviewed-by: Shawn Guo <shawn.guo at linaro.org>
> > ---
> >  .../devicetree/bindings/reset/gpio-reset.txt       |  37 ++++
> >  drivers/reset/Kconfig                              |  13 ++
> >  drivers/reset/Makefile                             |   1 +
> >  drivers/reset/gpio-reset.c                         | 208 +++++++++++++++++++++
> >  4 files changed, 259 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/reset/gpio-reset.txt
> >  create mode 100644 drivers/reset/gpio-reset.c
> >
> > diff --git a/Documentation/devicetree/bindings/reset/gpio-reset.txt b/Documentation/devicetree/bindings/reset/gpio-reset.txt
> > new file mode 100644
> > index 0000000..1f203eb
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/reset/gpio-reset.txt
> > @@ -0,0 +1,37 @@
> > +GPIO reset controller
> > +=====================
> > +
> > +A GPIO reset controller controls a number of GPIOs that are connected
> > +to reset pins of peripheral ICs.
> > +
> > +Please also refer to reset.txt in this directory for common reset
> > +controller binding usage.
> > +
> > +Required properties:
> > +- compatible: Should be "gpio-reset"
> > +- reset-gpios: List of gpios used as reset lines. The gpio specifier for this
> > +               property depends on the gpio controller that provides the gpio.
> > +- #reset-cells: 1, see below
> > +
> > +Optional properties:
> > +- reset-delays: List of delays in microseconds. The corresponding gpio reset
> > +                line should be asserted for this duration to reset.
> > +- initially-in-reset: List of integers. Zero if the initial state should be
> > +                      a deasserted reset line, nonzero if the line should be
> > +                      kept in reset.
> > +
> > +example:
> > +
> > +gpio_reset: gpio-reset {
> > +       compatible = "gpio-reset";
> > +       reset-gpios = <&gpio5 0 1>; /* active-low */
> > +       reset-delays = <10000>; /* 10 ms */
> > +       initially-in-reset: <1>;
> > +       #reset-cells = <1>;
> > +};
> 
> I find this binding that uses an array of GPIOs and their state to be
> a bit awkward, especially if you compare it to something like the
> simple gpio regulators that have a simpler one-to-one mapping.
> 
> Also, if you did one node per gpio you'd have a boolean property for
> "initially-in-reset" which seems much more logical (i.e. the property
> is either there, or it's not).

Thank you for your comments. I agree, to a degree.
The initially-in-reset array is a bit weird, and in principle, there is
no reason to group different reset gpios into the same platform device.
The main difference to the gpio regulator is that that one registers
multiple gpios per regulator, but only one regulator per platform
device. Do you propose to make the reset-gpio driver strictly control
only one reset gpio per platform device? In that case, the
fixed-regulator probably is a better example. How about this:

    resets {
        compatible = "simple-bus";

        reset1: gpio-reset {
            compatible = "gpio-reset";
            reset-gpio = <&gpio5 0 1>; /* active-low */
            reset-delay = <10000>; /* 10 ms */
            initially-in-reset;
            #reset-cells = <0>;
        };

        reset2: gpio-reset {
            compatible = "gpio-reset";
            reset-gpio = <&gpio3 5 0>;
            /* no reset delay, consumer has to (de)assert manually */
            #reset-cells = <0>;
        };
    };

> A couple of more comments:
> 
> > +config RESET_GPIO
> > +       tristate "GPIO reset controller support"
> > +       depends on GENERIC_GPIO
> > +       help
> > +         This driver provides support for reset lines that are controlled
> > +         directly by GPIOs.
> > +         The delay between assertion and de-assertion of the reset signal
> > +         can be configured.
> 
> Can be configured how? And why would I care about that when I'm trying
> to decide if I need to include this driver in my kernel configuration
> or not? Seems like misplaced information.

Configured via device tree. I'll just drop the second sentence. The idea
was to point out once more that it's the reset driver that carries the
timing information, but this really isn't the best place.

> Since this is a platform driver and not just an OF driver, shouldn't
> you provide a way to specify the same configuration data through a
> platform_data structure as well?

Will there be new non-OF platforms for which this is even useful? I can
add platform data support, if you like.

regards
Philipp



From jhovold at gmail.com  Thu Apr 11 08:39:08 2013
From: jhovold at gmail.com (Johan Hovold)
Date: Thu, 11 Apr 2013 14:39:08 +0200
Subject: [RFC 1/5] ARM: at91: add general purpose backup register (GPBR)
 support
In-Reply-To: <20130408100417.GT20693@game.jcrosoft.org>
References: <20130407150938.GA25605@localhost>
 <1365347572-14972-1-git-send-email-jhovold@gmail.com>
 <20130408073329.GO20693@game.jcrosoft.org>
 <20130408084618.GB25605@localhost>
 <20130408100417.GT20693@game.jcrosoft.org>
Message-ID: <20130411123908.GB21305@localhost>

On Mon, Apr 08, 2013 at 12:04:17PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 10:46 Mon 08 Apr     , Johan Hovold wrote:
> > On Mon, Apr 08, 2013 at 09:33:29AM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > > On 17:12 Sun 07 Apr     , Johan Hovold wrote:
> > > > 
> > > > Add General Purpose Backup Register (GPBR) support.
> > > > 
> > > > Most at91 SoCs have at least four 32-bit General Purpose Backup
> > > > Registers (GPBR) powered by backup-power (VDDBU). One such register is
> > > > currently used by rtc-at91sam9 driver to store the RTC time base.
> > > > 
> > > > Make sure the registers are mapped by arch setup code and add generic
> > > > accessors for in-kernel use.
> > > > 
> > > > This is a step in adding device-tree support to the rtc-at91sam9 driver.
> > > > 
> > > This is a regression
> > > 
> > > we loose the tracking of what request and use the GPBR
> > 
> > Implementing the GPBR accessors using a simple global resource was one
> > quick way forward to decouple and generalise the GPBR. Of course, this
> > could be turned into a more elaborate framework or driver where
> > registers are requested and released by other drivers and possibly also
> > by user-space.
> yes must as we used on SAMA5 to pass the boot source from the firstage
> of the boot loader to the other software

Could you please elaborate on this; how is the GPBR used, how many
registers, and when is it accessed?

Is there already code in at91/at91-3.10-soc or are you referring to
a userspace consumer?

Thanks,
Johan


From sebastian.hesselbarth at gmail.com  Thu Apr 11 08:40:23 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Thu, 11 Apr 2013 14:40:23 +0200
Subject: [PATCH] net: mv643xx_eth: Add GRO support
Message-ID: <1365684023-9967-1-git-send-email-sebastian.hesselbarth@gmail.com>

This patch adds GRO support to mv643xx_eth by making it invoke
napi_gro_receive instead of netif_receive_skb.

Signed-off-by: Soeren Moch <smoch at web.de>
Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
---
Cc: "David S. Miller" <davem at davemloft.net>
Cc: Lennert Buytenhek <buytenh at wantstofly.org>
Cc: Andrew Lunn <andrew at lunn.ch>
Cc: Jason Cooper <jason at lakedaemon.net>
Cc: Florian Fainelli <florian at openwrt.org>
Cc: Benjamin Herrenschmidt <benh at kernel.crashing.org>
Cc: Paul Mackerras <paulus at samba.org>
Cc: Dale Farnsworth <dale at farnsworth.org>
Cc: netdev at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linuxppc-dev at lists.ozlabs.org
Cc: linux-kernel at vger.kernel.org
---
 drivers/net/ethernet/marvell/mv643xx_eth.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c b/drivers/net/ethernet/marvell/mv643xx_eth.c
index 305038f..c850d04 100644
--- a/drivers/net/ethernet/marvell/mv643xx_eth.c
+++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
@@ -604,7 +604,7 @@ static int rxq_process(struct rx_queue *rxq, int budget)
 			lro_receive_skb(&rxq->lro_mgr, skb, (void *)cmd_sts);
 			lro_flush_needed = 1;
 		} else
-			netif_receive_skb(skb);
+			napi_gro_receive(&mp->napi, skb);
 
 		continue;
 
-- 
1.7.10.4



From dt.tangr at gmail.com  Thu Apr 11 08:42:51 2013
From: dt.tangr at gmail.com (Daniel Tang)
Date: Thu, 11 Apr 2013 22:42:51 +1000
Subject: [RFC PATCHv2 arm: initial TI-Nspire support]
In-Reply-To: <201304111430.05528.arnd@arndb.de>
References: <8E071E2D-4FF3-487E-A53B-B6A7C427E421@gmail.com>
 <201304111430.05528.arnd@arndb.de>
Message-ID: <C576ECFF-EF90-4995-AD28-1CEEE660DBAB@gmail.com>


On 11/04/2013, at 10:30 PM, Arnd Bergmann <arnd at arndb.de> wrote:

> On Thursday 11 April 2013, Daniel Tang wrote:
>> This is another updated patch for Linux on TI-Nspire support. 
>> 
>> Apologies for previously posting updated patches as replies to the first thread. I'll send updated patches in new threads from now to avoid confusion.
>> 
>> Changes between http://archive.arm.linux.org.uk/lurker/message/20130408.113343.585af217.en.html and v2:
>> * Added new drivers to support the irqchip and timers on older models.
>> * Added new device trees to support the other models.
>> 
>> Signed-off-by: Daniel Tang <dt.tangr at gmail.com>
> 
> Nice!
> 
>> arch/arm/Kconfig                            |   2 +
>> arch/arm/Kconfig.debug                      |  16 ++
>> arch/arm/Makefile                           |   1 +
>> arch/arm/boot/dts/Makefile                  |   3 +
>> arch/arm/boot/dts/nspire-classic.dtsi       |  68 ++++++
>> arch/arm/boot/dts/nspire-clp.dts            |  45 ++++
>> arch/arm/boot/dts/nspire-cx.dts             | 115 ++++++++++
>> arch/arm/boot/dts/nspire-tp.dts             |  44 ++++
>> arch/arm/boot/dts/nspire.dtsi               | 159 ++++++++++++++
>> arch/arm/include/debug/nspire.S             |  28 +++
>> arch/arm/mach-nspire/Kconfig                |  15 ++
>> arch/arm/mach-nspire/Makefile               |   2 +
>> arch/arm/mach-nspire/Makefile.boot          |   0
>> arch/arm/mach-nspire/clcd.c                 | 118 +++++++++++
>> arch/arm/mach-nspire/clcd.h                 |  14 ++
>> arch/arm/mach-nspire/mmio.h                 |  15 ++
>> arch/arm/mach-nspire/nspire.c               | 142 +++++++++++++
>> drivers/clocksource/Makefile                |   1 +
>> drivers/clocksource/nspire-classic-timer.c  | 216 +++++++++++++++++++
>> drivers/input/keyboard/Kconfig              |  10 +
>> drivers/input/keyboard/Makefile             |   1 +
>> drivers/input/keyboard/nspire-keypad.c      | 316 ++++++++++++++++++++++++++++
>> drivers/irqchip/Makefile                    |   1 +
>> drivers/irqchip/irq-nspire-classic.c        | 177 ++++++++++++++++
>> include/clocksource/nspire_classic_timer.h  |  16 ++
>> include/linux/platform_data/nspire-keypad.h |  28 +++
>> 26 files changed, 1553 insertions(+)
> 
> Please split this up into a series of patches, one for each subsystem.
> I would also keep the dts files in a separate patch from the platform
> code.

Fair enough. I'll keep that in mind for the next round of patches.

> 
> 
>> +bool timer_init;
>> +
>> +void __init nspire_classic_timer_init(void)
>> +{
>> +	struct device_node *node;
>> +
>> +	if (timer_init)
>> +		return;
>> +
>> +	for_each_compatible_node(node, NULL, DT_COMPAT) {
>> +		nspire_timer_add(node);
>> +	}
>> +
>> +	timer_init = 1;
>> +}
>> +
>> +CLOCKSOURCE_OF_DECLARE(nspire_classic_timer,
>> +		DT_COMPAT, nspire_classic_timer_init)
> 
> Why do you need the logic to prevent it from being initilized
> twice?  Can't you just remove the direct call to nspire_classic_timer_init
> from platform code and rely on of_clk_init() to call it?
> 

Ah, I wasn't aware that of_clk_init() would call the init functions. I thought it was up to clocksource_of_init() to do that.

Originally, I was adding a call to clocksource_of_init() to the platform code but that resulted in the timers being added twice. If of_clk_init() already calls the init functions, that would explain it. 

> Note that the interface has changed in linux-next, you now
> get called separately for each matching device, with the device_node
> as the argument, so you no longer have to search the device tree,
> and can essentially do
> 
> CLOCKSOURCE_OF_DECLARE(nspire_classic_timer, DT_COMPAT, nspire_timer_add);
> 
> Feel free to rebase your patch on top of the clksrc/cleanup branch
> in arm-soc to get the new behavior.

That's perfect. That'll also let me kick the whole timer_init boolean thing.

> 
>> diff --git a/include/linux/platform_data/nspire-keypad.h b/include/linux/platform_data/nspire-keypad.h
>> new file mode 100644
>> index 0000000..03deb64
>> --- /dev/null
>> +++ b/include/linux/platform_data/nspire-keypad.h
> 
> And this file now also isn't needed any more, you can just merge the
> fields of struct nspire_keypad_data into struct nspire_keypad.
> 
> 	Arnd

Thanks again,
tangrs

From jhovold at gmail.com  Thu Apr 11 08:57:26 2013
From: jhovold at gmail.com (Johan Hovold)
Date: Thu, 11 Apr 2013 14:57:26 +0200
Subject: [RFC 4/5] RTC: rtc-at91sam9: add device-tree support
In-Reply-To: <20130408111113.GX20693@game.jcrosoft.org>
References: <20130407150938.GA25605@localhost>
 <1365347572-14972-1-git-send-email-jhovold@gmail.com>
 <1365347572-14972-4-git-send-email-jhovold@gmail.com>
 <20130408073807.GQ20693@game.jcrosoft.org>
 <20130408090023.GC25605@localhost> <51629472.3070404@atmel.com>
 <20130408103847.GE25605@localhost>
 <20130408111113.GX20693@game.jcrosoft.org>
Message-ID: <20130411125726.GC21305@localhost>

On Mon, Apr 08, 2013 at 01:11:13PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 12:38 Mon 08 Apr     , Johan Hovold wrote:
> > On Mon, Apr 08, 2013 at 11:57:06AM +0200, Nicolas Ferre wrote:
> > > On 04/08/2013 11:00 AM, Johan Hovold :
> > > > On Mon, Apr 08, 2013 at 09:38:07AM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > > >> On 17:12 Sun 07 Apr     , Johan Hovold wrote:

[...]

> > > >>> +rtt at fffffd20 {
> > > >>> +		compatible = "atmel,at91sam9g45-rtt", "atmel,at91sam9260-rtt";
> > > 
> > > No, there is no visible difference between the sam9g45 RTT and the
> > > sam9260 one. So the most precise compatibility string is still sam9260.
> > > If one day we feel the need for a advanced feature that exists on a more
> > > recent SoC, we have the possibility to add it at that time...
> > 
> > Yes, this should be just "atmel,at91sam9260-rtt" to follow the current
> > practise in AT91. However, as I mentioned in an earlier mail one could
> > interpret
> > 
> > 	"The first string in the list specifies the exact device that
> > 	the node represents in the form "<manufacturer>,<model>". The
> > 	following strings represent other devices that the device is
> > 	compatible with.
> > 
> > 	For example, the Freescale MPC8349 System on Chip (SoC) has a
> > 	serial device which implements the National Semiconductor
> > 	ns16550 register interface. The compatible property for the
> > 	MPC8349 serial device should therefore be: compatible =
> > 	"fsl,mpc8349-uart", "ns16550". In this case, fsl,mpc8349-uart
> > 	specifies the exact device, and ns16550 states that it is
> > 	register-level compatible with a National Semiconductor 16550
> > 	UART."
> > 
> > 	http://www.devicetree.org/Device_Tree_Usage#Understanding_the_compatible_Property
> > 
> > to mean that the compatible property should always be exact SoC-IP
> > followed by the first (most generic) compatible one.
>
> here you describe compatible IP not drivers implementation

I'm referring to the IP and not drivers.

> they are both usuart IP that are compatible at IP level.

Fair enough, I see how this can be considered to be in accordance with
the above quotation.

Johan


From arnd at arndb.de  Thu Apr 11 09:06:33 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 11 Apr 2013 15:06:33 +0200
Subject: [RFC PATCHv2 arm: initial TI-Nspire support]
In-Reply-To: <C576ECFF-EF90-4995-AD28-1CEEE660DBAB@gmail.com>
References: <8E071E2D-4FF3-487E-A53B-B6A7C427E421@gmail.com>
 <201304111430.05528.arnd@arndb.de>
 <C576ECFF-EF90-4995-AD28-1CEEE660DBAB@gmail.com>
Message-ID: <201304111506.34229.arnd@arndb.de>

On Thursday 11 April 2013, Daniel Tang wrote:
> >> +
> >> +CLOCKSOURCE_OF_DECLARE(nspire_classic_timer,
> >> +            DT_COMPAT, nspire_classic_timer_init)
> > 
> > Why do you need the logic to prevent it from being initilized
> > twice?  Can't you just remove the direct call to nspire_classic_timer_init
> > from platform code and rely on of_clk_init() to call it?
> > 
> 
> Ah, I wasn't aware that of_clk_init() would call the init functions. I thought it was up to clocksource_of_init() to do that.
> 
> Originally, I was adding a call to clocksource_of_init() to the platform code but
> that resulted in the timers being added twice. If of_clk_init() already calls the
> init functions, that would explain it. 

Sorry, I was confusing the calls, I meant clocksource_of_init() not of_clk_init().

I think the reason why they were added twice is that you have two nodes
matching "nspire-classic-timer", so you get called for each one, but the
existing code (pre linux-next) does not actually pass the node and you
end up looping through both for each of the two calls.

	Arnd


From andrew.murray at arm.com  Thu Apr 11 09:11:34 2013
From: andrew.murray at arm.com (Andrew Murray)
Date: Thu, 11 Apr 2013 14:11:34 +0100
Subject: [PATCH v5 2/3] of/pci: Provide support for parsing PCI DT
 ranges property
In-Reply-To: <5165AEBA.7000803@gmail.com>
References: <1365578969-30966-1-git-send-email-Andrew.Murray@arm.com>
 <1365578969-30966-3-git-send-email-Andrew.Murray@arm.com>
 <5165AEBA.7000803@gmail.com>
Message-ID: <20130411131134.GC28981@arm.com>

On Wed, Apr 10, 2013 at 07:26:02PM +0100, Rob Herring wrote:
> On 04/10/2013 02:29 AM, Andrew Murray wrote:
> > This patch factors out common implementation patterns to reduce overall kernel
> > code and provide a means for host bridge drivers to directly obtain struct
> > resources from the DT's ranges property without relying on architecture specific
> > DT handling. This will make it easier to write archiecture independent host bridge
> > drivers and mitigate against further duplication of DT parsing code.
> >
> > This patch can be used in the following way:
> >
> >       struct of_pci_range_parser parser;
> >       struct of_pci_range range;
> >
> >       if (of_pci_range_parser(&parser, np))
> >               ; //no ranges property
> >
> >       for_each_of_pci_range(&parser, &range) {
> >
> >               /*
> >                       directly access properties of the address range, e.g.:
> >                       range.pci_space, range.pci_addr, range.cpu_addr,
> >                       range.size, range.flags
> >
> >                       alternatively obtain a struct resource, e.g.:
> >                       struct resource res;
> >                       of_pci_range_to_resource(&range, np, &res);
> >               */
> >       }
> >
> > Additionally the implementation takes care of adjacent ranges and merges them
> > into a single range (as was the case with powerpc and microblaze).
> >
> > Signed-off-by: Andrew Murray <Andrew.Murray at arm.com>
> > Signed-off-by: Liviu Dudau <Liviu.Dudau at arm.com>
> > Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> > ---
> 
> A few minor things below, otherwise:
> 
> Reviewed-by: Rob Herring <rob.herring at calxeda.com>
> 

Thanks for the feedback, I've included this in my next spin.

Andrew Murray


From w at 1wt.eu  Thu Apr 11 09:13:33 2013
From: w at 1wt.eu (Willy Tarreau)
Date: Thu, 11 Apr 2013 15:13:33 +0200
Subject: [PATCH] net: mv643xx_eth: Add GRO support
In-Reply-To: <1365684023-9967-1-git-send-email-sebastian.hesselbarth@gmail.com>
References: <1365684023-9967-1-git-send-email-sebastian.hesselbarth@gmail.com>
Message-ID: <20130411131333.GD1910@1wt.eu>

Hi,

On Thu, Apr 11, 2013 at 02:40:23PM +0200, Sebastian Hesselbarth wrote:
> This patch adds GRO support to mv643xx_eth by making it invoke
> napi_gro_receive instead of netif_receive_skb.
> 
> Signed-off-by: Soeren Moch <smoch at web.de>
> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
> ---
> Cc: "David S. Miller" <davem at davemloft.net>
> Cc: Lennert Buytenhek <buytenh at wantstofly.org>
> Cc: Andrew Lunn <andrew at lunn.ch>
> Cc: Jason Cooper <jason at lakedaemon.net>
> Cc: Florian Fainelli <florian at openwrt.org>
> Cc: Benjamin Herrenschmidt <benh at kernel.crashing.org>
> Cc: Paul Mackerras <paulus at samba.org>
> Cc: Dale Farnsworth <dale at farnsworth.org>
> Cc: netdev at vger.kernel.org
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linuxppc-dev at lists.ozlabs.org
> Cc: linux-kernel at vger.kernel.org
> ---
>  drivers/net/ethernet/marvell/mv643xx_eth.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c b/drivers/net/ethernet/marvell/mv643xx_eth.c
> index 305038f..c850d04 100644
> --- a/drivers/net/ethernet/marvell/mv643xx_eth.c
> +++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
> @@ -604,7 +604,7 @@ static int rxq_process(struct rx_queue *rxq, int budget)
>  			lro_receive_skb(&rxq->lro_mgr, skb, (void *)cmd_sts);
>  			lro_flush_needed = 1;
>  		} else
> -			netif_receive_skb(skb);
> +			napi_gro_receive(&mp->napi, skb);
>  
>  		continue;

I remember having experimented with this on 3.6 a few months ago with this
driver and finally switching back to something like this instead which
showed better performance on my tests :

               if (skb->ip_summed == CHECKSUM_UNNECESSARY)
                       napi_gro_receive(napi, skb);
               else
                       netif_receive_skb(skb);

Unfortunately I don't have more details as my commit message was rather
short due to this resulting from experimentation. Did you verify that
you did not lose any performance in various workloads ? I was playing
with bridges at this time, it's possible that I got better performance
on bridging with netif_receive_skb() than with napi_gro_receive().

Regards,
Willy



From dhowells at redhat.com  Thu Apr 11 09:30:58 2013
From: dhowells at redhat.com (David Howells)
Date: Thu, 11 Apr 2013 14:30:58 +0100
Subject: [PATCH 25/26] arm: Don't use create_proc_read_entry() [RFC]
In-Reply-To: <20130411132739.32763.82609.stgit@warthog.procyon.org.uk>
References: <20130411132739.32763.82609.stgit@warthog.procyon.org.uk>
Message-ID: <20130411133058.32763.5466.stgit@warthog.procyon.org.uk>

Don't use create_proc_read_entry() as that is deprecated, but rather use
proc_create_data() and seq_file instead.

Signed-off-by: David Howells <dhowells at redhat.com>
cc: Russell King <linux at arm.linux.org.uk>
cc: Kevin Hilman <khilman at deeprootsystems.com>
cc: Tony Lindgren <tony at atomide.com>
cc: linux-arm-kernel at lists.infradead.org
cc: linux-omap at vger.kernel.org
---

 arch/arm/kernel/swp_emulate.c |   42 +++++++++++++-----------------
 arch/arm/mach-omap1/pm.c      |   58 +++++++++++++++++------------------------
 2 files changed, 43 insertions(+), 57 deletions(-)

diff --git a/arch/arm/kernel/swp_emulate.c b/arch/arm/kernel/swp_emulate.c
index 0bba47a..087fc32 100644
--- a/arch/arm/kernel/swp_emulate.c
+++ b/arch/arm/kernel/swp_emulate.c
@@ -21,6 +21,7 @@
 #include <linux/init.h>
 #include <linux/kernel.h>
 #include <linux/proc_fs.h>
+#include <linux/seq_file.h>
 #include <linux/sched.h>
 #include <linux/syscalls.h>
 #include <linux/perf_event.h>
@@ -79,27 +80,27 @@ static unsigned long abtcounter;
 static pid_t         previous_pid;
 
 #ifdef CONFIG_PROC_FS
-static int proc_read_status(char *page, char **start, off_t off, int count,
-			    int *eof, void *data)
+static int proc_status_show(struct seq_file *m, void *v)
 {
-	char *p = page;
-	int len;
-
-	p += sprintf(p, "Emulated SWP:\t\t%lu\n", swpcounter);
-	p += sprintf(p, "Emulated SWPB:\t\t%lu\n", swpbcounter);
-	p += sprintf(p, "Aborted SWP{B}:\t\t%lu\n", abtcounter);
+	seq_printf(m, "Emulated SWP:\t\t%lu\n", swpcounter);
+	seq_printf(m, "Emulated SWPB:\t\t%lu\n", swpbcounter);
+	seq_printf(m, "Aborted SWP{B}:\t\t%lu\n", abtcounter);
 	if (previous_pid != 0)
-		p += sprintf(p, "Last process:\t\t%d\n", previous_pid);
-
-	len = (p - page) - off;
-	if (len < 0)
-		len = 0;
-
-	*eof = (len <= count) ? 1 : 0;
-	*start = page + off;
+		seq_printf(m, "Last process:\t\t%d\n", previous_pid);
+	return 0;
+}
 
-	return len;
+static int proc_status_open(struct inode *inode, struct file *file)
+{
+	return single_open(file, proc_status_show, PDE_DATA(inode));
 }
+
+static const struct file_operations proc_status_fops = {
+	.open		= proc_status_open,
+	.read		= seq_read,
+	.llseek		= seq_lseek,
+	.release	= seq_release,
+};
 #endif
 
 /*
@@ -266,12 +267,7 @@ static struct undef_hook swp_hook = {
 static int __init swp_emulation_init(void)
 {
 #ifdef CONFIG_PROC_FS
-	struct proc_dir_entry *res;
-
-	res = create_proc_read_entry("cpu/swp_emulation", S_IRUGO, NULL,
-					proc_read_status, NULL);
-
-	if (!res)
+	if (!proc_create("cpu/swp_emulation", S_IRUGO, NULL, &proc_status_fops))
 		return -ENOMEM;
 #endif /* CONFIG_PROC_FS */
 
diff --git a/arch/arm/mach-omap1/pm.c b/arch/arm/mach-omap1/pm.c
index 7a7690a..2645e37 100644
--- a/arch/arm/mach-omap1/pm.c
+++ b/arch/arm/mach-omap1/pm.c
@@ -38,6 +38,7 @@
 #include <linux/suspend.h>
 #include <linux/sched.h>
 #include <linux/proc_fs.h>
+#include <linux/seq_file.h>
 #include <linux/interrupt.h>
 #include <linux/sysfs.h>
 #include <linux/module.h>
@@ -423,22 +424,11 @@ void omap1_pm_suspend(void)
 }
 
 #if defined(DEBUG) && defined(CONFIG_PROC_FS)
-static int g_read_completed;
-
 /*
  * Read system PM registers for debugging
  */
-static int omap_pm_read_proc(
-	char *page_buffer,
-	char **my_first_byte,
-	off_t virtual_start,
-	int length,
-	int *eof,
-	void *data)
+static int omap_pm_proc_show(struct seq_file *m, void *v)
 {
-	int my_buffer_offset = 0;
-	char * const my_base = page_buffer;
-
 	ARM_SAVE(ARM_CKCTL);
 	ARM_SAVE(ARM_IDLECT1);
 	ARM_SAVE(ARM_IDLECT2);
@@ -479,10 +469,7 @@ static int omap_pm_read_proc(
 		MPUI1610_SAVE(EMIFS_CONFIG);
 	}
 
-	if (virtual_start == 0) {
-		g_read_completed = 0;
-
-		my_buffer_offset += sprintf(my_base + my_buffer_offset,
+	seq_printf(m,
 		   "ARM_CKCTL_REG:            0x%-8x     \n"
 		   "ARM_IDLECT1_REG:          0x%-8x     \n"
 		   "ARM_IDLECT2_REG:          0x%-8x     \n"
@@ -512,8 +499,8 @@ static int omap_pm_read_proc(
 		   ULPD_SHOW(ULPD_STATUS_REQ),
 		   ULPD_SHOW(ULPD_POWER_CTRL));
 
-		if (cpu_is_omap7xx()) {
-			my_buffer_offset += sprintf(my_base + my_buffer_offset,
+	if (cpu_is_omap7xx()) {
+		seq_printf(m,
 			   "MPUI7XX_CTRL_REG	     0x%-8x \n"
 			   "MPUI7XX_DSP_STATUS_REG:      0x%-8x \n"
 			   "MPUI7XX_DSP_BOOT_CONFIG_REG: 0x%-8x \n"
@@ -526,8 +513,8 @@ static int omap_pm_read_proc(
 			   MPUI7XX_SHOW(MPUI_DSP_API_CONFIG),
 			   MPUI7XX_SHOW(EMIFF_SDRAM_CONFIG),
 			   MPUI7XX_SHOW(EMIFS_CONFIG));
-		} else if (cpu_is_omap15xx()) {
-			my_buffer_offset += sprintf(my_base + my_buffer_offset,
+	} else if (cpu_is_omap15xx()) {
+		seq_printf(m,
 			   "MPUI1510_CTRL_REG             0x%-8x \n"
 			   "MPUI1510_DSP_STATUS_REG:      0x%-8x \n"
 			   "MPUI1510_DSP_BOOT_CONFIG_REG: 0x%-8x \n"
@@ -540,8 +527,8 @@ static int omap_pm_read_proc(
 			   MPUI1510_SHOW(MPUI_DSP_API_CONFIG),
 			   MPUI1510_SHOW(EMIFF_SDRAM_CONFIG),
 			   MPUI1510_SHOW(EMIFS_CONFIG));
-		} else if (cpu_is_omap16xx()) {
-			my_buffer_offset += sprintf(my_base + my_buffer_offset,
+	} else if (cpu_is_omap16xx()) {
+		seq_printf(m,
 			   "MPUI1610_CTRL_REG             0x%-8x \n"
 			   "MPUI1610_DSP_STATUS_REG:      0x%-8x \n"
 			   "MPUI1610_DSP_BOOT_CONFIG_REG: 0x%-8x \n"
@@ -554,25 +541,28 @@ static int omap_pm_read_proc(
 			   MPUI1610_SHOW(MPUI_DSP_API_CONFIG),
 			   MPUI1610_SHOW(EMIFF_SDRAM_CONFIG),
 			   MPUI1610_SHOW(EMIFS_CONFIG));
-		}
-
-		g_read_completed++;
-	} else if (g_read_completed >= 1) {
-		 *eof = 1;
-		 return 0;
 	}
-	g_read_completed++;
 
-	*my_first_byte = page_buffer;
-	return  my_buffer_offset;
+	return 0;
+}
+
+static int omap_pm_proc_open(struct inode *inode, struct file *file)
+{
+	return single_open(file, omap_pm_proc_show, PDE_DATA(inode));
 }
 
+static const struct file_operations omap_pm_proc_fops = {
+	.open		= omap_pm_proc_open,
+	.read		= seq_read,
+	.llseek		= seq_lseek,
+	.release	= seq_release,
+};
+
 static void omap_pm_init_proc(void)
 {
 	/* XXX Appears to leak memory */
-	create_proc_read_entry("driver/omap_pm",
-			       S_IWUSR | S_IRUGO, NULL,
-			       omap_pm_read_proc, NULL);
+	create_proc("driver/omap_pm", S_IWUSR | S_IRUGO, NULL,
+		    &omap_pm_proc_fops);
 }
 
 #endif /* DEBUG && CONFIG_PROC_FS */



From Ian.Campbell at citrix.com  Thu Apr 11 09:32:28 2013
From: Ian.Campbell at citrix.com (Ian Campbell)
Date: Thu, 11 Apr 2013 14:32:28 +0100
Subject: hypervisor/firmware calling conventions (Was: Re: [Xen-devel]
 [PATCH 1/4] xen/arm: basic PSCI support,	implement cpu_on)
In-Reply-To: <1365515874.10725.33.camel@zakaz.uk.xensource.com>
References: <alpine.DEB.2.02.1303211837140.5135@kaball.uk.xensource.com>
 <1363891353-13827-1-git-send-email-stefano.stabellini@eu.citrix.com>
 <1365515874.10725.33.camel@zakaz.uk.xensource.com>
Message-ID: <1365687148.8036.140.camel@zakaz.uk.xensource.com>

Adding Charles and the l-a-k list which I hadn't noticed wasn't CC'd
before. Are there other lists which would be useful to include?

On Tue, 2013-04-09 at 14:57 +0100, Ian Campbell wrote:
> > +        if ( !hsr.iss )
> > +            return do_trap_psci(regs);
> 
> Ugh, using ISS==0 for this interface is a bit unfortunate, who
> arbitrates this namespace?

Xen chose to use a non-0 immediate for its hypercalls so we are lucky
that we don't have to play tricks to distinguish PSCI calls from
hypercalls but it seems to me that either there needs to be some
semi-formal registry for smv/hvc immediates to avoid clashes or that
interfaces need to pick a random non-zero number to try and minimise the
chances of a clash.

Or maybe it gets pushed down a layer and the registry is of r0/x0
function ids and the immediate argument is generally ignored?

But in general we need some way for interfaces provided by hypervisors
and secure mode monitors to safely co-exist, I think, both for the case
where the hypervisor is implementing a shim for a secure mode interface
(i.e. implementing PSCI with hvc) and for the case where there are
multiple interfaces at each layer (e.g. hypervisors sometimes want to
implement foreign hypervisor interfaces and I can easily imagine other
firmware level interfaces than PSCI coming into existence in the
future).

In the specific case of PSCI I couldn't actually find the calling
convention (i.e. the specific registers to use). I suspect I'm just
looking at an old version of the spec...

Ian.



From hechtb at gmail.com  Thu Apr 11 10:07:43 2013
From: hechtb at gmail.com (Bastian Hecht)
Date: Thu, 11 Apr 2013 16:07:43 +0200
Subject: [PATCH v2 1/2] ARM: shmobile: r8a7740: Add Suspend-To-RAM A3SM
Message-ID: <1365689264-14410-1-git-send-email-hechtb+renesas@gmail.com>

We add 2 Suspend to RAM modes:
- A3SM PLL0 on/off:     Power domain A3SM that contains the ARM core
                        and the 2nd level cache with either PLL0 on
                        or off

As the suspend to memory mechanism we use A3SM PLL off. A3SM PLL on
is included here too, so CPUIdle can use both power down modes (not
included in this patch).

The setup of the SYSC regarding the external IRQs is taken from
pm-sh7372.c from Magnus Damm.

Signed-off-by: Bastian Hecht <hechtb+renesas at gmail.com>
---
This patch relies on
ARM: hw_breakpoint: Do not use __cpuinitdata for dbg_cpu_pm_nb

v2: successor to [PATCH] ARM: shmobile: r8a7740: Add Suspend-To-RAM modes and CPUIdle

- Removed the 2nd L1 flush in the asm shutdown code. See comment in code for explanation.
- Reworked the ifdefs: We can only use CPUIdle if SUSPEND is set as well.
- Removed cpu_do_idle() in r8a7740_enter_suspend: We don't want to sleep twice...

If you want to test this use this workaround in the st1232 driver in
drivers/input/touchscreen/st1232.c:

        error = request_threaded_irq(client->irq, NULL, st1232_ts_irq_handler,
-                                    IRQF_ONESHOT, client->name, ts);
+                                    IRQF_NO_SUSPEND | IRQF_ONESHOT, client->name, ts);

You need it as the current irqpin driver doesn't handle wakeup devices properly yet.

Tested with the 4 possiblities 	L2 on - Suspend on/off - CPUIdle on/off
and with the additional test	L2 off - Suspend on - CPUIdle on

 arch/arm/mach-shmobile/Makefile               |    2 +-
 arch/arm/mach-shmobile/include/mach/r8a7740.h |    3 +
 arch/arm/mach-shmobile/pm-r8a7740.c           |  167 ++++++++++++++++++++++++-
 arch/arm/mach-shmobile/sleep-r8a7740.S        |   72 +++++++++++
 4 files changed, 240 insertions(+), 4 deletions(-)
 create mode 100644 arch/arm/mach-shmobile/sleep-r8a7740.S

diff --git a/arch/arm/mach-shmobile/Makefile b/arch/arm/mach-shmobile/Makefile
index 068f1da..0568894 100644
--- a/arch/arm/mach-shmobile/Makefile
+++ b/arch/arm/mach-shmobile/Makefile
@@ -30,7 +30,7 @@ obj-$(CONFIG_SUSPEND)		+= suspend.o
 obj-$(CONFIG_CPU_IDLE)		+= cpuidle.o
 obj-$(CONFIG_ARCH_SHMOBILE)	+= pm-rmobile.o
 obj-$(CONFIG_ARCH_SH7372)	+= pm-sh7372.o sleep-sh7372.o
-obj-$(CONFIG_ARCH_R8A7740)	+= pm-r8a7740.o
+obj-$(CONFIG_ARCH_R8A7740)	+= pm-r8a7740.o sleep-r8a7740.o
 obj-$(CONFIG_ARCH_R8A7779)	+= pm-r8a7779.o
 obj-$(CONFIG_ARCH_SH73A0)	+= pm-sh73a0.o
 
diff --git a/arch/arm/mach-shmobile/include/mach/r8a7740.h b/arch/arm/mach-shmobile/include/mach/r8a7740.h
index abdc4d4..05551ee 100644
--- a/arch/arm/mach-shmobile/include/mach/r8a7740.h
+++ b/arch/arm/mach-shmobile/include/mach/r8a7740.h
@@ -540,6 +540,9 @@ extern void r8a7740_add_standard_devices(void);
 extern void r8a7740_clock_init(u8 md_ck);
 extern void r8a7740_pinmux_init(void);
 extern void r8a7740_pm_init(void);
+extern void r8a7740_resume(void);
+extern void r8a7740_shutdown(void);
+extern void r8a7740_enter_a3sm_common(int);
 
 #ifdef CONFIG_PM
 extern void __init r8a7740_init_pm_domains(void);
diff --git a/arch/arm/mach-shmobile/pm-r8a7740.c b/arch/arm/mach-shmobile/pm-r8a7740.c
index 40b87aa..adadac4 100644
--- a/arch/arm/mach-shmobile/pm-r8a7740.c
+++ b/arch/arm/mach-shmobile/pm-r8a7740.c
@@ -8,10 +8,52 @@
  * License.  See the file "COPYING" in the main directory of this archive
  * for more details.
  */
+#include <linux/bitrev.h>
 #include <linux/console.h>
+#include <linux/module.h>
 #include <linux/suspend.h>
+#include <linux/io.h>
+#include <asm/suspend.h>
+#include <asm/cacheflush.h>
+#include <asm/hardware/cache-l2x0.h>
 #include <mach/pm-rmobile.h>
 #include <mach/common.h>
+#include <mach/r8a7740.h>
+
+/* CPGA */
+#define PLLC01STPCR 	IOMEM(0xe61500c8)
+#define SYSTBCR		IOMEM(0xe6150024)
+
+/* SYSC */
+#define STBCHR		IOMEM(0xe6180000)
+#define STBCHRB		IOMEM(0xe6180040)
+#define SPDCR		IOMEM(0xe6180008)
+#define SBAR		IOMEM(0xe6180020)
+#define SRSTFR		IOMEM(0xe61800B4)
+#define WUPSMSK		IOMEM(0xe618002c)
+#define WUPSMSK2	IOMEM(0xe6180048)
+#define WUPSFAC		IOMEM(0xe6180098)
+#define IRQCR 		IOMEM(0xe618022c)
+#define IRQCR2 		IOMEM(0xe6180238)
+#define IRQCR3		IOMEM(0xe6180244)
+#define IRQCR4		IOMEM(0xe6180248)
+
+/* SRSTFR flags */
+#define RAMST		(1 << 19)
+#define RCLNKA		(1 << 7)
+#define RCPRES		(1 << 5)
+#define RCWD1		(1 << 4)
+#define RPF		(1 << 0)
+
+/* INTC */
+#define ICR1A		IOMEM(0xe6900000)
+#define ICR2A		IOMEM(0xe6900004)
+#define ICR3A		IOMEM(0xe6900008)
+#define ICR4A		IOMEM(0xe690000c)
+#define INTMSK00A	IOMEM(0xe6900040)
+#define INTMSK10A	IOMEM(0xe6900044)
+#define INTMSK20A	IOMEM(0xe6900048)
+#define INTMSK30A	IOMEM(0xe690004c)
 
 #ifdef CONFIG_PM
 static int r8a7740_pd_a4s_suspend(void)
@@ -58,13 +100,132 @@ void __init r8a7740_init_pm_domains(void)
 	rmobile_init_domains(r8a7740_pm_domains, ARRAY_SIZE(r8a7740_pm_domains));
 	pm_genpd_add_subdomain_names("A4S", "A3SP");
 }
-
 #endif /* CONFIG_PM */
 
 #ifdef CONFIG_SUSPEND
+static void r8a7740_set_reset_vector(unsigned long address)
+{
+	__raw_writel(address, SBAR);
+}
+
+static void r8a7740_icr_to_irqcr(unsigned long icr, u16 *irqcr1p, u16 *irqcr2p)
+{
+	u16 tmp, irqcr1, irqcr2;
+	int k;
+
+	irqcr1 = 0;
+	irqcr2 = 0;
+
+	/* convert INTCA ICR register layout to SYSC IRQCR+IRQCR2 */
+	for (k = 0; k <= 7; k++) {
+		tmp = (icr >> ((7 - k) * 4)) & 0xf;
+		irqcr1 |= (tmp & 0x03) << (k * 2);
+		irqcr2 |= (tmp >> 2) << (k * 2);
+	}
+
+	*irqcr1p = irqcr1;
+	*irqcr2p = irqcr2;
+}
+
+static void r8a7740_setup_sysc(unsigned long msk, unsigned long msk2)
+{
+	u16 irqcrx_low, irqcrx_high, irqcry_low, irqcry_high;
+	unsigned long tmp;
+
+	/* read IRQ0A -> IRQ15A mask */
+	tmp = bitrev8(__raw_readb(INTMSK00A));
+	tmp |= bitrev8(__raw_readb(INTMSK10A)) << 8;
+
+	/* setup WUPSMSK from clocks and external IRQ mask */
+	msk = (~msk & 0xc030000f) | (tmp << 4);
+	__raw_writel(msk, WUPSMSK);
+
+	/* propage level/edge trigger for external IRQ 0->15 */
+	r8a7740_icr_to_irqcr(__raw_readl(ICR1A), &irqcrx_low, &irqcry_low);
+	r8a7740_icr_to_irqcr(__raw_readl(ICR2A), &irqcrx_high, &irqcry_high);
+	__raw_writel((irqcrx_high << 16) | irqcrx_low, IRQCR);
+	__raw_writel((irqcry_high << 16) | irqcry_low, IRQCR2);
+
+	/* read IRQ16A -> IRQ31A mask */
+	tmp = bitrev8(__raw_readb(INTMSK20A));
+	tmp |= bitrev8(__raw_readb(INTMSK30A)) << 8;
+
+	/* setup WUPSMSK2 from clocks and external IRQ mask */
+	msk2 = (~msk2 & 0x00030000) | tmp;
+	__raw_writel(msk2, WUPSMSK2);
+
+	/* propage level/edge trigger for external IRQ 16->31 */
+	r8a7740_icr_to_irqcr(__raw_readl(ICR3A), &irqcrx_low, &irqcry_low);
+	r8a7740_icr_to_irqcr(__raw_readl(ICR4A), &irqcrx_high, &irqcry_high);
+	__raw_writel((irqcrx_high << 16) | irqcrx_low, IRQCR3);
+	__raw_writel((irqcry_high << 16) | irqcry_low, IRQCR4);
+}
+
+static void r8a7740_prepare_wakeup(void)
+{
+	/* clear all flags that lead to a cold boot */
+	__raw_writel(~(RAMST | RCLNKA | RCPRES | RCWD1 | RPF), SRSTFR);
+	/* indicate warm boot */
+	__raw_writel(0x80000000, STBCHRB);
+	/* clear other flags checked by internal ROM boot loader */
+	__raw_writel(0x00000000, STBCHR);
+}
+
+static int r8a7740_do_suspend(unsigned long unused)
+{
+	/*
+	 * cpu_suspend() guarantees that all data made it to the L2.
+	 * Flush it out now and disable the cache controller.
+	 */
+	outer_flush_all();
+	outer_disable();
+
+	r8a7740_shutdown();
+
+	/* in case WFI fails to enter the low power state, restore things */
+	outer_resume();
+
+	return 0;
+}
+
+void r8a7740_enter_a3sm_common(int pllc0_on)
+{
+	u32 reg32;
+
+	if (pllc0_on)
+		__raw_writel(0, PLLC01STPCR);
+	else
+		__raw_writel(1 << 28, PLLC01STPCR);
+
+	r8a7740_set_reset_vector(__pa(r8a7740_resume));
+	r8a7740_prepare_wakeup();
+	r8a7740_setup_sysc(1 << 0, 0);
+
+	/* Activate delayed shutdown of A3SM */
+	reg32 = __raw_readl(SPDCR);
+	reg32 |= (1 << 31) | (1 << 12);
+	__raw_writel(reg32, SPDCR);
+
+	/* We activate CPU Core Standby as well here */
+	reg32 = __raw_readl(SYSTBCR);
+	reg32 |= (1 << 4);
+	__raw_writel(reg32, SYSTBCR);
+
+	/* Clear Wakeup Factors and do suspend */
+	reg32 = __raw_readl(WUPSFAC);
+	cpu_suspend(0, r8a7740_do_suspend);
+	outer_resume();
+	reg32 = __raw_readl(WUPSFAC);
+
+	/* Clear CPU Core Standby flag for other WFI instructions */
+	reg32 &= ~(1 << 4);
+	__raw_writel(reg32, SYSTBCR);
+
+}
+
 static int r8a7740_enter_suspend(suspend_state_t suspend_state)
 {
-	cpu_do_idle();
+	r8a7740_enter_a3sm_common(0);
 	return 0;
 }
 
@@ -74,7 +235,7 @@ static void r8a7740_suspend_init(void)
 }
 #else
 static void r8a7740_suspend_init(void) {}
-#endif
+#endif /* CONFIG_SUSPEND */
 
 void __init r8a7740_pm_init(void)
 {
diff --git a/arch/arm/mach-shmobile/sleep-r8a7740.S b/arch/arm/mach-shmobile/sleep-r8a7740.S
new file mode 100644
index 0000000..762f978
--- /dev/null
+++ b/arch/arm/mach-shmobile/sleep-r8a7740.S
@@ -0,0 +1,72 @@
+/*
+ * Low level sleep code for the SoC r8a7740
+ *
+ * Copyright (C) 2013 Bastian Hecht
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License.  See the file "COPYING" in the main directory of this archive
+ * for more details.
+ */
+
+#include <linux/linkage.h>
+#include <linux/init.h>
+#include <asm/memory.h>
+
+#ifdef CONFIG_SUSPEND
+
+/* r8a7740_shutdown expects L2 to be flushed */
+	.text
+ENTRY(r8a7740_shutdown)
+	stmfd   sp!, {r4-r12, lr}
+
+	/* make sure the stack stays intact */
+	bl      v7_flush_dcache_all
+
+	/*
+	 * Clear the SCTLR.C bit to prevent further data cache
+	 * allocation. Clearing SCTLR.C would make all the data accesses
+	 * strongly ordered and would not hit the cache.
+	 */
+	mrc	p15, 0, r0, c1, c0, 0
+	bic	r0, r0, #(1 << 2)		@ Disable the C bit
+	mcr	p15, 0, r0, c1, c0, 0
+	isb
+
+	/*
+	 * We don't issue another v7_flush_dcache_all here as seen in many
+	 * other places as we have a UP core and the L1 could not soak up
+	 * data from other L1 caches in the meantime.
+	 */
+
+	bl	cpu_v7_do_idle
+
+	/* in rare cases when WFI fails we end up here and restore things */
+	mrc	p15, 0, r0, c1, c0, 0
+	orr	r0, r0, #(1 << 2)		@ Enable the C bit
+	mcr	p15, 0, r0, c1, c0, 0
+	isb
+
+	ldmfd   sp!, {r4-r12, pc}
+ENDPROC(r8a7740)
+
+	.text
+ENTRY(v7_cpu_resume)
+	bl	v7_invalidate_l1
+	b	cpu_resume
+ENDPROC(v7_cpu_resume)
+
+/*
+ * The entry point of a warm reboot, used by wakeup scenarios
+ *
+ * The CPU jumps in this case to (0xfffff000 & SBAR), so we need
+ * to align this function properly.
+ * We use a long jump into the text segment and use the physical
+ * address as the MMU is still turned off.
+ */
+	.align	12
+	.text
+ENTRY(r8a7740_resume)
+	ldr	pc, 1f
+1:	.long	v7_cpu_resume - PAGE_OFFSET + PLAT_PHYS_OFFSET
+ENDPROC(r8a7740_resume_core_standby)
+#endif
-- 
1.7.9.5



From hechtb at gmail.com  Thu Apr 11 10:07:44 2013
From: hechtb at gmail.com (Bastian Hecht)
Date: Thu, 11 Apr 2013 16:07:44 +0200
Subject: [PATCH v2 2/2] ARM: shmobile: r8a7740: Add CPUIdle
In-Reply-To: <1365689264-14410-1-git-send-email-hechtb+renesas@gmail.com>
References: <1365689264-14410-1-git-send-email-hechtb+renesas@gmail.com>
Message-ID: <1365689264-14410-2-git-send-email-hechtb+renesas@gmail.com>

We make use of the r8a7740 Suspend To Ram code to plug together a
CPUIdle driver.

Signed-off-by: Bastian Hecht<hechtb+renesas at gmail.com>
---
v2:
new patch: Moved out the CPUIdle part

 arch/arm/mach-shmobile/Makefile               |    2 +-
 arch/arm/mach-shmobile/cpuidle-r8a7740.c      |   62 +++++++++++++++++++++++++
 arch/arm/mach-shmobile/include/mach/r8a7740.h |    1 +
 arch/arm/mach-shmobile/pm-r8a7740.c           |    1 +
 4 files changed, 65 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/mach-shmobile/cpuidle-r8a7740.c

diff --git a/arch/arm/mach-shmobile/Makefile b/arch/arm/mach-shmobile/Makefile
index 0568894..2852dcf 100644
--- a/arch/arm/mach-shmobile/Makefile
+++ b/arch/arm/mach-shmobile/Makefile
@@ -30,7 +30,7 @@ obj-$(CONFIG_SUSPEND)		+= suspend.o
 obj-$(CONFIG_CPU_IDLE)		+= cpuidle.o
 obj-$(CONFIG_ARCH_SHMOBILE)	+= pm-rmobile.o
 obj-$(CONFIG_ARCH_SH7372)	+= pm-sh7372.o sleep-sh7372.o
-obj-$(CONFIG_ARCH_R8A7740)	+= pm-r8a7740.o sleep-r8a7740.o
+obj-$(CONFIG_ARCH_R8A7740)	+= pm-r8a7740.o sleep-r8a7740.o cpuidle-r8a7740.o
 obj-$(CONFIG_ARCH_R8A7779)	+= pm-r8a7779.o
 obj-$(CONFIG_ARCH_SH73A0)	+= pm-sh73a0.o
 
diff --git a/arch/arm/mach-shmobile/cpuidle-r8a7740.c b/arch/arm/mach-shmobile/cpuidle-r8a7740.c
new file mode 100644
index 0000000..48c7a6c
--- /dev/null
+++ b/arch/arm/mach-shmobile/cpuidle-r8a7740.c
@@ -0,0 +1,62 @@
+/*
+ * CPUIdle code for SoC r8a7740
+ *
+ * Copyright (C) 2013 Bastian Hecht
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License.  See the file "COPYING" in the main directory of this archive
+ * for more details.
+ */
+#include <linux/cpuidle.h>
+#include <linux/module.h>
+#include <asm/cpuidle.h>
+#include <mach/common.h>
+#include <mach/r8a7740.h>
+
+#if defined(CONFIG_SUSPEND) && defined(CONFIG_CPU_IDLE)
+static int r8a7740_enter_a3sm_pll_on(struct cpuidle_device *dev,
+					struct cpuidle_driver *drv, int index)
+{
+	r8a7740_enter_a3sm_common(1);
+	return 1;
+}
+
+static int r8a7740_enter_a3sm_pll_off(struct cpuidle_device *dev,
+					struct cpuidle_driver *drv, int index)
+{
+	r8a7740_enter_a3sm_common(0);
+	return 2;
+}
+
+static struct cpuidle_driver r8a7740_cpuidle_driver = {
+	.name			= "r8a7740_cpuidle",
+	.owner			= THIS_MODULE,
+	.en_core_tk_irqen	= 1,
+	.state_count		= 3,
+	.safe_state_index	= 0, /* C1 */
+	.states[0] = ARM_CPUIDLE_WFI_STATE,
+	.states[1] = {
+		.name = "C2",
+		.desc = "A3SM PLL ON",
+		.exit_latency = 40,
+		.target_residency = 30 + 40,
+		.flags = CPUIDLE_FLAG_TIME_VALID,
+		.enter = r8a7740_enter_a3sm_pll_on,
+	},
+	.states[2] = {
+		.name = "C3",
+		.desc = "A3SM PLL OFF",
+		.exit_latency = 120,
+		.target_residency = 30 + 120,
+		.flags = CPUIDLE_FLAG_TIME_VALID,
+		.enter = r8a7740_enter_a3sm_pll_off,
+	},
+};
+
+void r8a7740_cpuidle_init(void)
+{
+	shmobile_cpuidle_set_driver(&r8a7740_cpuidle_driver);
+}
+#else
+void r8a7740_cpuidle_init(void) {}
+#endif
diff --git a/arch/arm/mach-shmobile/include/mach/r8a7740.h b/arch/arm/mach-shmobile/include/mach/r8a7740.h
index 05551ee..5c3361a 100644
--- a/arch/arm/mach-shmobile/include/mach/r8a7740.h
+++ b/arch/arm/mach-shmobile/include/mach/r8a7740.h
@@ -542,6 +542,7 @@ extern void r8a7740_pinmux_init(void);
 extern void r8a7740_pm_init(void);
 extern void r8a7740_resume(void);
 extern void r8a7740_shutdown(void);
+extern void r8a7740_cpuidle_init(void);
 extern void r8a7740_enter_a3sm_common(int);
 
 #ifdef CONFIG_PM
diff --git a/arch/arm/mach-shmobile/pm-r8a7740.c b/arch/arm/mach-shmobile/pm-r8a7740.c
index adadac4..1b1fba2 100644
--- a/arch/arm/mach-shmobile/pm-r8a7740.c
+++ b/arch/arm/mach-shmobile/pm-r8a7740.c
@@ -240,4 +240,5 @@ static void r8a7740_suspend_init(void) {}
 void __init r8a7740_pm_init(void)
 {
 	r8a7740_suspend_init();
+	r8a7740_cpuidle_init();
 }
-- 
1.7.9.5



From hechtb at gmail.com  Thu Apr 11 10:09:01 2013
From: hechtb at gmail.com (Bastian Hecht)
Date: Thu, 11 Apr 2013 16:09:01 +0200
Subject: [PATCH] ARM: shmobile: r8a7740: Add Suspend-To-RAM modes and
 CPUIdle
In-Reply-To: <CABYn4syA6R0PU1xEQLcm29sYkD+fGi6vx+tCrFSNfA4qPo0npg@mail.gmail.com>
References: <1365609107-14290-1-git-send-email-hechtb+renesas@gmail.com>
 <5165E929.9030309@linaro.org>
 <CABYn4sxEOvQhZP7GnS5-AgNjkvJJXyv4n1UjVGBjXbVq0N+9_A@mail.gmail.com>
 <51667D68.7070804@linaro.org>
 <CABYn4syA6R0PU1xEQLcm29sYkD+fGi6vx+tCrFSNfA4qPo0npg@mail.gmail.com>
Message-ID: <CABYn4sz2fziF6zXfkGYpz2Nqq7hZNhRLE9Zn6y9AoSoQ4Qy5ow@mail.gmail.com>

2013/4/11 Bastian Hecht <hechtb at gmail.com>:
> Hi Daniel,
>
>>>>> +
>>>>> +static struct cpuidle_driver r8a7740_cpuidle_driver = {
>>>>> +     .name                   = "r8a7740_cpuidle",
>>>>> +     .owner                  = THIS_MODULE,
>>>>> +     .en_core_tk_irqen       = 1,
>>>>> +     .state_count            = 3,
>>>>> +     .safe_state_index       = 0, /* C1 */
>>>>> +     .states[0] = ARM_CPUIDLE_WFI_STATE,
>>>>> +     .states[0].enter = shmobile_enter_wfi,
>>>>
>>>> The WFI macro already set a simple enter function doing cpu_do_idle.
>>>
>>> Oh yes, I'll remove it.
>>>
>>>> We are trying to consolidate the cpuidle drivers across the different
>>>> platforms [1]. One of the objective is to move the cpuidle drivers to
>>>> drivers/cpuidle, a place where they belong to.
>>>>
>>>> Do you think it is possible you split your code to have one part with
>>>> the cpuidle driver and another part with the PM code ?
>>>
>>> Hmm. The CPUIdle part is enclosed in the #ifdef CONFIG_CPU_IDLE part anyway.
>>> The other part (CONFIG_SUSPEND | CONFIG_CPU_IDLE) contains the part
>>> that actually does drive down the hardware and is needed as soon as
>>> SUSPEND or CPUIdle is used.
>>>
>>> So is it split well enough already or does it help if I split my patch
>>> into 2, first adding suspend and then CPUIdle to the same file? But
>>> the outcome will be the same I think.
>>
>>
>> Well, if you can convert the pm functions into ops used in the cpuidle
>> driver and then create a file eg. cpuidle-r8a7740.c with the cpuidle
>> code calling the ops that will separate clearly the cpuidle code from
>> the pm code and make easier to move the cpuidle driver to the
>> drivers/cpuidle directory. Also, I think that will help to consolidate
>> the other shmobile cpuidle drivers, maybe into a single one.
>>
>>
>
> Ok I've prepared a new patchset and think the splitting looks good .
> As this is a sensitive code area I want to retest it though and post
> it in a couple of hours.

Ok they are out and named:
[PATCH v2 1/2] ARM: shmobile: r8a7740: Add Suspend-To-RAM A3SM
[PATCH v2 2/2] ARM: shmobile: r8a7740: Add CPUIdle

> Cheers,
>
>  Bastian


From khilman at linaro.org  Thu Apr 11 10:20:59 2013
From: khilman at linaro.org (Kevin Hilman)
Date: Thu, 11 Apr 2013 07:20:59 -0700
Subject: [RESEND PATCH] PM / Runtime: Idle devices asynchronously after
 probe|release
In-Reply-To: <1365606048-27603-1-git-send-email-ulf.hansson@stericsson.com>
 (Ulf Hansson's message of "Wed, 10 Apr 2013 17:00:48 +0200")
References: <1365606048-27603-1-git-send-email-ulf.hansson@stericsson.com>
Message-ID: <87txndxi5w.fsf@linaro.org>

Ulf Hansson <ulf.hansson at stericsson.com> writes:

> From: Ulf Hansson <ulf.hansson at linaro.org>
>
> Putting devices into idle|suspend in a synchronous manner means we are
> waiting for each device to become idle|suspended before the probe|release
> is fully done.
>
> This patch switch to use the asynchronous runtime PM API:s instead and
> thus improves the parallelism since we can move on and handle the next
> device in queue in an earlier phase.
>
> Signed-off-by: Ulf Hansson <ulf.hansson at linaro.org>
> Cc: Kevin Hilman <khilman at linaro.org>
> Cc: Alan Stern <stern at rowland.harvard.edu>
> Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>

Acked-by: Kevin Hilman <khilman at linaro.org>


From broonie at opensource.wolfsonmicro.com  Thu Apr 11 10:27:06 2013
From: broonie at opensource.wolfsonmicro.com (Mark Brown)
Date: Thu, 11 Apr 2013 15:27:06 +0100
Subject: [PATCH 20/30] ASoC: samsung: convert to dmaengine API
In-Reply-To: <1365638712-1028578-21-git-send-email-arnd@arndb.de>
References: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
 <1365638712-1028578-21-git-send-email-arnd@arndb.de>
Message-ID: <20130411142706.GB24971@opensource.wolfsonmicro.com>

On Thu, Apr 11, 2013 at 02:05:02AM +0200, Arnd Bergmann wrote:
> In order to build the exynos kernel with CONFIG_ARCH_MULTIPLATFORM,
> we must convert all users of the Samsung private DMA interface to
> the generic dmaengine API. This version of the patch adds the
> generic dmaengine API as an alternative to the existing samsung
> specific one. Once all the older platforms provide support for
> the common dmaengine interfaces, we can remove the old code.

There's generic ASoC dmaengine code which should be used instead of open
coding this.  Lars-Peter Clausen and Lee Jones have been working on
making this a totally generic driver, right now it's a library.


From daniel.lezcano at linaro.org  Thu Apr 11 10:30:46 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Thu, 11 Apr 2013 16:30:46 +0200
Subject: [PATCH v2 2/2] ARM: shmobile: r8a7740: Add CPUIdle
In-Reply-To: <1365689264-14410-2-git-send-email-hechtb+renesas@gmail.com>
References: <1365689264-14410-1-git-send-email-hechtb+renesas@gmail.com>
 <1365689264-14410-2-git-send-email-hechtb+renesas@gmail.com>
Message-ID: <5166C916.7050402@linaro.org>

On 04/11/2013 04:07 PM, Bastian Hecht wrote:
> We make use of the r8a7740 Suspend To Ram code to plug together a
> CPUIdle driver.
> 
> Signed-off-by: Bastian Hecht<hechtb+renesas at gmail.com>

Acked-by: Daniel Lezcano <daniel.lezcano at linaro.org>

Thanks !

  -- Daniel

-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From arnd at arndb.de  Thu Apr 11 10:47:17 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 11 Apr 2013 16:47:17 +0200
Subject: [PATCH 20/30] ASoC: samsung: convert to dmaengine API
In-Reply-To: <20130411142706.GB24971@opensource.wolfsonmicro.com>
References: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
 <1365638712-1028578-21-git-send-email-arnd@arndb.de>
 <20130411142706.GB24971@opensource.wolfsonmicro.com>
Message-ID: <201304111647.17796.arnd@arndb.de>

On Thursday 11 April 2013, Mark Brown wrote:
> 
> On Thu, Apr 11, 2013 at 02:05:02AM +0200, Arnd Bergmann wrote:
> > In order to build the exynos kernel with CONFIG_ARCH_MULTIPLATFORM,
> > we must convert all users of the Samsung private DMA interface to
> > the generic dmaengine API. This version of the patch adds the
> > generic dmaengine API as an alternative to the existing samsung
> > specific one. Once all the older platforms provide support for
> > the common dmaengine interfaces, we can remove the old code.
> 
> There's generic ASoC dmaengine code which should be used instead of open
> coding this.  Lars-Peter Clausen and Lee Jones have been working on
> making this a totally generic driver, right now it's a library.

Ok, I see. I'll drop this patch from my series then and will let someone
else handle this driver in 3.11. We can probably live without sound support
in 3.10 when running a multiplatform kernel, and it will keep working
for exynos-only kernels without the patch.

Can you have a look at the other three ASoC patches in the series? I think
it would still be useful to merge them.

	Arnd


From sebastian.hesselbarth at gmail.com  Thu Apr 11 10:47:49 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Thu, 11 Apr 2013 16:47:49 +0200
Subject: [PATCH] net: mv643xx_eth: Add GRO support
In-Reply-To: <20130411131333.GD1910@1wt.eu>
References: <1365684023-9967-1-git-send-email-sebastian.hesselbarth@gmail.com>
 <20130411131333.GD1910@1wt.eu>
Message-ID: <CABJ1b_TQDabT1J7ffo5cb1Th=71bcSduifMJaDpfVRiiHvtWDw@mail.gmail.com>

On Thu, Apr 11, 2013 at 3:13 PM, Willy Tarreau <w at 1wt.eu> wrote:
> On Thu, Apr 11, 2013 at 02:40:23PM +0200, Sebastian Hesselbarth wrote:
>> This patch adds GRO support to mv643xx_eth by making it invoke
>> napi_gro_receive instead of netif_receive_skb.
>>
>> Signed-off-by: Soeren Moch <smoch at web.de>
>> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
>> ---
>> Cc: "David S. Miller" <davem at davemloft.net>
>> Cc: Lennert Buytenhek <buytenh at wantstofly.org>
>> Cc: Andrew Lunn <andrew at lunn.ch>
>> Cc: Jason Cooper <jason at lakedaemon.net>
>> Cc: Florian Fainelli <florian at openwrt.org>
>> Cc: Benjamin Herrenschmidt <benh at kernel.crashing.org>
>> Cc: Paul Mackerras <paulus at samba.org>
>> Cc: Dale Farnsworth <dale at farnsworth.org>
>> Cc: netdev at vger.kernel.org
>> Cc: linux-arm-kernel at lists.infradead.org
>> Cc: linuxppc-dev at lists.ozlabs.org
>> Cc: linux-kernel at vger.kernel.org
>> ---
>>  drivers/net/ethernet/marvell/mv643xx_eth.c |    2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c b/drivers/net/ethernet/marvell/mv643xx_eth.c
>> index 305038f..c850d04 100644
>> --- a/drivers/net/ethernet/marvell/mv643xx_eth.c
>> +++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
>> @@ -604,7 +604,7 @@ static int rxq_process(struct rx_queue *rxq, int budget)
>>                       lro_receive_skb(&rxq->lro_mgr, skb, (void *)cmd_sts);
>>                       lro_flush_needed = 1;
>>               } else
>> -                     netif_receive_skb(skb);
>> +                     napi_gro_receive(&mp->napi, skb);
>>
>>               continue;
>
> I remember having experimented with this on 3.6 a few months ago with this
> driver and finally switching back to something like this instead which
> showed better performance on my tests :
>
>                if (skb->ip_summed == CHECKSUM_UNNECESSARY)
>                        napi_gro_receive(napi, skb);
>                else
>                        netif_receive_skb(skb);
>
> Unfortunately I don't have more details as my commit message was rather
> short due to this resulting from experimentation. Did you verify that
> you did not lose any performance in various workloads ? I was playing
> with bridges at this time, it's possible that I got better performance
> on bridging with netif_receive_skb() than with napi_gro_receive().

Hi Willy,

I did some simple tests on Dove/Cubox with 'netperf -cCD' and
gso/gro/lro options on
mv643xx_eth. The tests may not be sufficient, as I am not that into
net performance
testing.

I tried todays net-next on top of 3.9-rc6 without any gro patch, with
the initial
patch (Soeren) and your proposed patch (Willy). The results show that
both patches
allow a significant increase in throughput compared to
netif_receive_skb (!gro, !lro)
alone. Having gro with lro disabled gives some 2% more throughput
compared to lro only.

Sebastian

Recv   Send    Send                          Utilization       Service Demand
Socket Socket  Message  Elapsed              Send     Recv     Send    Recv
Size   Size    Size     Time     Throughput  local    remote   local   remote
bytes  bytes   bytes    secs.    10^6bits/s  % S      % S      us/KB   us/KB

 87380  16384  16384    10.02       615.65   19.15    99.90    5.097
13.293 (3.9-rc6: gso)
 87380  16384  16384    10.02       615.82   19.05    99.90    5.067
13.289 (3.9-rc6: gso, gro)
 87380  16384  16384    10.03       747.44   23.17    99.80    5.079
10.938 (3.9-rc6: gso, lro)
 87380  16384  16384    10.02       745.28   22.57    99.80    4.963
10.970 (3.9.rc6: gso, gro, lro)

 87380  16384  16384    10.02       600.34   19.10    99.90    5.211
13.632 (3.9-rc6+soeren: gso)
 87380  16384  16384    10.02       764.23   23.42    99.80    5.021
10.698 (3.9-rc6+soeren: gso, gro)
 87380  16384  16384    10.02       749.81   23.13    99.80    5.055
10.904 (3.9-rc6+soeren: gso, lro)
 87380  16384  16384    10.02       745.84   22.34    99.80    4.907
10.962 (3.9.rc6+soeren: gso, gro, lro)

 87380  16384  16384    10.02       605.79   18.79    100.00   5.082
13.523 (3.9-rc6+willy: gso)
 87380  16384  16384    10.02       765.64   24.68    99.80    5.281
10.678 (3.9-rc6+willy: gso, gro)
 87380  16384  16384    10.02       750.30   26.02    99.80    5.682
10.897 (3.9-rc6+willy: gso, lro)
 87380  16384  16384    10.03       749.40   21.86    99.80    4.778
10.910 (3.9.rc6+willy: gso, gro, lro)


From lorenzo.pieralisi at arm.com  Thu Apr 11 10:47:58 2013
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Thu, 11 Apr 2013 15:47:58 +0100
Subject: [RFC PATCH] ARM CCI support
Message-ID: <1365691679-28674-1-git-send-email-lorenzo.pieralisi@arm.com>

ARM multi-cluster systems rely on the cache coherent interconnect (CCI) to
support inter-cluster cache coherency and distributed virtual memory (DVM)
messaging.

CCI kernel driver requires tweaks to the kernel and device tree
bindings in order to link specific resources to groups of logical CPUs
so that resources can be associated to specific cpu sets (slave ports can
be associated with a set of CPUs which are part of a cluster).

ARM DT topology bindings [1] allow one to describe the hierarchy of CPUs in the
system. Cache Coherent Interconnect CCI is by definition a consumer of
topology bindings in that CCI slave ports must be associated with specific
bus masters in the system so that whenever a CCI operation is requested for
a specific master (ie disable its CCI slave port, read its PMU counters) the
association can be carried out dynamically in the OS through dynamically
built data structures.

The CCI driver provides an example of how to use the newly introduced bindings
and is meant to kickstart discussion on the best way to deploy them on
forthcoming ARM systems.

The current CCI DT bindings define the CCI address space as the same one
as the root device tree node, which means that the CCI bus can address the
entire address space visible to CPUs.

CCI driver code relies on patches 1 and 2 of the series [1] to define
topology bindings and ARM kernel core layer to parse them.

This code is meant to supersede the previous CCI driver posted to LAKML:

http://lists.infradead.org/pipermail/linux-arm-kernel/2013-February/147482.html

upon review completion.

[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2013-April/162457.html

Thank you very much,
Lorenzo

Lorenzo Pieralisi (1):
  drivers: bus: add ARM CCI support

 Documentation/devicetree/bindings/arm/cci.txt | 184 ++++++++++++++
 drivers/bus/Kconfig                           |   7 +
 drivers/bus/Makefile                          |   2 +
 drivers/bus/arm-cci.c                         | 344 ++++++++++++++++++++++++++
 include/linux/arm-cci.h                       |  44 ++++
 5 files changed, 581 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/cci.txt
 create mode 100644 drivers/bus/arm-cci.c
 create mode 100644 include/linux/arm-cci.h

-- 
1.7.12




From lorenzo.pieralisi at arm.com  Thu Apr 11 10:47:59 2013
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Thu, 11 Apr 2013 15:47:59 +0100
Subject: [RFC PATCH] drivers: bus: add ARM CCI support
In-Reply-To: <1365691679-28674-1-git-send-email-lorenzo.pieralisi@arm.com>
References: <1365691679-28674-1-git-send-email-lorenzo.pieralisi@arm.com>
Message-ID: <1365691679-28674-2-git-send-email-lorenzo.pieralisi@arm.com>

On ARM multi-cluster systems coherency between cores running on
different clusters is managed by the cache-coherent interconnect (CCI).
It allows broadcasting of TLB invalidates and memory barriers and it
guarantees cache coherency at system level through snooping of slave
interfaces connected to it.

This patch enables the basic infrastructure required in Linux to handle and
programme the CCI component. The first implementation is based on a platform
device, its relative DT compatible property and a simple programming interface.

Non-local variables used by the CCI management functions called by power
down function calls after disabling the cache must be flushed out to main
memory in advance, otherwise incoherency of those values may occur if they
are sitting in the cache of some other CPU when power down functions
execute. Driver code insures that relevant data structures are flushed
from inner and outer caches after the driver probe is completed.

CCI slave port resources are linked to set of CPUs through CCI interfaces
phandle properties that link the interface resources to topology node in
the device tree.

Documentation describing the CCI DT bindings is provided with the patch.

Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
---
 Documentation/devicetree/bindings/arm/cci.txt | 184 ++++++++++++++
 drivers/bus/Kconfig                           |   7 +
 drivers/bus/Makefile                          |   2 +
 drivers/bus/arm-cci.c                         | 344 ++++++++++++++++++++++++++
 include/linux/arm-cci.h                       |  44 ++++
 5 files changed, 581 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/cci.txt
 create mode 100644 drivers/bus/arm-cci.c
 create mode 100644 include/linux/arm-cci.h

diff --git a/Documentation/devicetree/bindings/arm/cci.txt b/Documentation/devicetree/bindings/arm/cci.txt
new file mode 100644
index 0000000..9a7bb7b
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/cci.txt
@@ -0,0 +1,184 @@
+=======================================================
+ARM CCI cache coherent interconnect binding description
+=======================================================
+
+ARM multi-cluster systems maintain intra-cluster coherency through a
+cache coherent interconnect (CCI) that is capable of monitoring bus
+transactions and manage coherency, TLB invalidations and memory barriers.
+
+It allows snooping and distributed virtual memory message broadcast across
+clusters, through memory mapped interface, with a global control register
+space and multiple sets of interface control registers, one per slave
+interface.
+
+Bindings for the CCI node follow the ePAPR standard, available from:
+
+http://devicetree.org
+
+with the addition of the bindings described in this document which are
+specific to ARM.
+
+- cci node
+	Description: Describes a CCI cache coherent Interconnect component
+
+	Node name must be "cci".
+	Node's parent must be the root node /, and the address space visible
+	through the CCI interconnect is the same as the one seen from the
+	root node (ie from CPUs perspective as per DT standard).
+	Every CCI node has to define the following properties:
+
+	- compatible
+		Usage: required
+		Value type: <string>
+		Definition: must be set to
+			"arm,cci-400"
+
+	- reg
+		Usage: required
+		Value type: <prop-encoded-array>
+		Definition: A standard property. Specifies base physical
+			    address of CCI control registers common to all
+			    interfaces.
+
+	- ranges:
+		Usage: required
+		Value type: <prop-encoded-array>
+		Definition: A standard property. Follow rules in the ePAPR for
+			    hierarchical bus addressing. CCI interfaces
+			    addresses refer to the parent node addressing
+			    scheme to declare their register bases.
+
+- CCI interface nodes
+
+	Node name must be "slave-if".
+
+	A CCI interface node must contain the following properties:
+	- interface-type:
+		Usage: required
+		Value type: <string>
+		Definition: must be set to one of {"ace", "ace-lite"}
+			    depending on the interface type the node
+			    represents.
+
+	- reg:
+		Usage: required
+		Value type: <prop-encoded-array>
+                Definition: the base address and size of the corresponding
+			    interface programming registers.
+
+	- master:
+		Usage: required
+		Value type: <phandle>
+		Definition: if the interface-type is set to "ace", so the
+			    interface is an ACE port, this property must be a
+			    phandle to the node within the cpu-map node ([1])
+			    that describes the CPUs connected to the interface
+			    port. Valid phandles are nodes contained in
+			    the cpu-map node, as defined in [1]. If the
+			    interface-type is set to "ace-lite" so the
+			    interface describes an ACE LITE port, this property
+			    must be a phandle pointing at the device node
+			    representing the bus-master connected to this port.
+
+Example:
+
+	cpu-map {
+
+		cluster0 {
+
+			core0 {
+				cpu = <&CPU0>;
+			};
+
+			core1 {
+				cpu = <&CPU1>;
+			};
+
+		};
+
+		cluster1 {
+
+			core0 {
+				cpu = <&CPU2>;
+			};
+
+			core1 {
+				cpu = <&CPU3>;
+			};
+
+		};
+	};
+
+	cpus {
+		#size-cells = <0>;
+		#address-cells = <1>;
+
+		CPU0: cpu at 0 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a15";
+			reg = <0x0>;
+		};
+
+		CPU1: cpu at 1 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a15";
+			reg = <0x1>;
+		};
+
+		CPU2: cpu at 100 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a7";
+			reg = <0x100>;
+		};
+
+		CPU3: cpu at 101 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a7";
+			reg = <0x101>;
+		};
+
+	};
+
+	dma0: dma at 3000000 {
+		compatible = "arm,pl330", "arm,primecell";
+		reg = <0x0 0x3000000 0x0 0x1000>;
+		interrupts = <10>;
+		#dma-cells = <1>;
+		#dma-channels = <8>;
+		#dma-requests = <32>;
+	};
+
+	cci at 2c090000 {
+		compatible = "arm,cci";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		reg = <0x0 0x2c090000 0 0x1000>;
+		ranges = <0x0 0x0 0x2c090000 0x6000>;
+
+		slave-if at 1000 {
+			interface-type = "ace-lite";
+			reg = <0x1000 0x1000>;
+			master = <&dma0>;
+		};
+
+		slave-if at 4000 {
+			interface-type = "ace";
+			reg = <0x4000 0x1000>;
+			master = <&cluster0>;
+		};
+
+		slave-if at 5000 {
+			interface-type = "ace";
+			reg = <0x5000 0x1000>;
+			master = <&cluster1>;
+		};
+	};
+
+This CCI node corresponds to a CCI component whose control registers sits
+at address 0x000000002c090000.
+CCI slave interface @0x000000002c091000 maps to dma controller dma0.
+CCI slave interface @0x000000002c094000 maps to all CPUs contained in cluster0.
+CCI slave interface @0x000000002c095000 maps to all CPUs contained in cluster1.
+
+[1] Linux kernel documentation,
+	Documentation/devicetree/bindings/arm/topology.txt
diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
index 0f51ed6..38ea85c 100644
--- a/drivers/bus/Kconfig
+++ b/drivers/bus/Kconfig
@@ -19,4 +19,11 @@ config OMAP_INTERCONNECT
 
 	help
 	  Driver to enable OMAP interconnect error handling driver.
+
+config ARM_CCI
+	bool "ARM CCI driver support"
+	depends on ARM
+	help
+	  Driver supporting the CCI cache coherent interconnect for ARM
+	  platforms.
 endmenu
diff --git a/drivers/bus/Makefile b/drivers/bus/Makefile
index 45d997c..2bd9947 100644
--- a/drivers/bus/Makefile
+++ b/drivers/bus/Makefile
@@ -6,3 +6,5 @@ obj-$(CONFIG_OMAP_OCP2SCP)	+= omap-ocp2scp.o
 
 # Interconnect bus driver for OMAP SoCs.
 obj-$(CONFIG_OMAP_INTERCONNECT)	+= omap_l3_smx.o omap_l3_noc.o
+# CCI cache coherent interconnect for ARM platforms
+obj-$(CONFIG_ARM_CCI)		+= arm-cci.o
diff --git a/drivers/bus/arm-cci.c b/drivers/bus/arm-cci.c
new file mode 100644
index 0000000..81953de
--- /dev/null
+++ b/drivers/bus/arm-cci.c
@@ -0,0 +1,344 @@
+/*
+ * CCI cache coherent interconnect driver
+ *
+ * Copyright (C) 2013 ARM Ltd.
+ * Author: Lorenzo Pieralisi <lorenzo.pieralisi at arm.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.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/arm-cci.h>
+#include <linux/device.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/of_address.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+
+#include <asm/cacheflush.h>
+#include <asm/dt_affinity.h>
+#include <asm/outercache.h>
+#include <asm/smp_plat.h>
+
+#define DRIVER_NAME		"CCI"
+#define CCI_CTRL_STATUS		0xc
+
+#define CCI_PORT_CTRL		0x0
+
+struct cci_nb_ports {
+	unsigned int nb_ace;
+	unsigned int nb_ace_lite;
+};
+
+enum cci_ace_port_type {
+	ACE_INVALID_PORT = 0x0,
+	ACE_PORT,
+	ACE_LITE_PORT,
+};
+
+struct cci_ace_port {
+	void __iomem *base;
+	int type;
+	union {
+		cpumask_t match_mask;
+		struct device_node *np;
+	} match;
+};
+
+static struct cci_ace_port *ports;
+static unsigned int nb_cci_ports;
+
+static void __iomem *cci_ctrl_base;
+#define INVALID_PORT_IDX	-1
+static int cpu_port[NR_CPUS] = { [0 ... NR_CPUS-1] = INVALID_PORT_IDX };
+
+static void __init cci_ace_init_ports(void)
+{
+	bool is_ace;
+	int port, cpu;
+	/*
+	 * Port index look-up speeds up the function disabling ports by CPU,
+	 * since the logical to port index mapping is done once and does
+	 * not change after system boot.
+	 * The stashed index array is initialized for all possible CPUs
+	 * at probe time.
+	 */
+	for_each_possible_cpu(cpu) {
+		for (port = 0; port < nb_cci_ports; port++) {
+			is_ace = ports[port].type == ACE_PORT;
+			if (is_ace && cpu_isset(cpu,
+					 ports[port].match.match_mask)) {
+				cpu_port[cpu] = port;
+				break;
+			}
+		}
+		WARN(cpu_port[cpu] == INVALID_PORT_IDX, "CPU %d has an invalid"
+							" CCI port index\n",
+							cpu);
+	}
+}
+
+/*
+ * cci_ace_lite_port - Function to retrieve the port index corresponding to
+ *		       a device tree node
+ *
+ * @np = device tree node to match
+ *
+ * Return value:
+ *	- ACE LITE port index if success
+ *	- -EINVAL if failure
+ *
+ */
+static int cci_ace_lite_port(struct device_node *np)
+{
+	int i;
+	bool is_ace_lite;
+
+	for (i = 0; i < nb_cci_ports; i++) {
+		is_ace_lite = ports[i].type == ACE_LITE_PORT;
+		if (is_ace_lite && np == ports[i].match.np)
+			return i;
+	}
+	return -ENODEV;
+}
+
+/*
+ * Functions to enable/disable a CCI interconnect slave port
+ *
+ * They are called by low-level power management code to disable slave
+ * interfaces snoops and DVM broadcast.
+ * Since they may execute with cache data allocation disabled and
+ * after the caches have been cleaned and invalidated the functions provide
+ * no explicit locking since they may run with D-cache disabled, so normal
+ * cacheable kernel locks based on ldrex/strex may not work.
+ * Locking has to be provided by BSP implementations to ensure proper
+ * operations.
+ */
+
+/*
+ * cci_port_control()
+ *	@port = index of the port to setup
+ *	@enable = if true enables the port, if false disables it
+ */
+static void notrace cci_port_control(unsigned int port, bool enable)
+{
+	void __iomem *base = ports[port].base;
+
+	if (!base)
+		return;
+
+	writel_relaxed(enable, base + CCI_PORT_CTRL);
+	while (readl_relaxed(cci_ctrl_base + CCI_CTRL_STATUS) & 0x1)
+			;
+}
+
+/*
+ * cci_disable_port_by_cpu()
+ *	@mpidr = mpidr of the CPU whose CCI port should be disabled
+ *	Returns:
+ *		0 on success
+ *		-ENODEV on port look-up failure
+ *
+ * Disabling a CCI port for a CPU implies disabling the CCI port
+ * controlling that CPU cluster. Code disabling CPU CCI ports
+ * must make sure that the CPU running the code is the last active CPU
+ * in the cluster ie all other CPUs are quiescent in a low power state.
+ */
+int notrace cci_disable_port_by_cpu(u64 mpidr)
+{
+	int cpu = get_logical_index(mpidr & MPIDR_HWID_BITMASK);
+
+	if (cpu < 0 || cpu_port[cpu] == INVALID_PORT_IDX)
+		return -ENODEV;
+	cci_port_control(cpu_port[cpu], false);
+	return 0;
+}
+EXPORT_SYMBOL_GPL(cci_disable_port_by_cpu);
+
+/*
+ * __cci_control_port_by_device()
+ *	@np = device_node of the device whose CCI port should be enabled
+ *	@enable = if true enables the port, if false disables it
+ *	Returns:
+ *		0 on success
+ *		-ENODEV on port look-up failure
+ */
+int notrace __cci_control_port_by_device(struct device_node *np, bool enable)
+{
+	int port = cci_ace_lite_port(np);
+	if (WARN_ONCE(port < 0,
+		      "ACE lite port look-up failure, node %p\n", np))
+		return -ENODEV;
+	cci_port_control(port, enable);
+	return 0;
+}
+EXPORT_SYMBOL_GPL(__cci_control_port_by_device);
+
+static const struct of_device_id arm_cci_matches[];
+
+static int __init cci_driver_probe(struct platform_device *pdev)
+{
+	const struct of_device_id *match;
+	struct cci_nb_ports const *cci_config;
+	int ret, j, i, nb_ace = 0, nb_ace_lite = 0;
+	struct device_node *np, *cp;
+	const char *match_str;
+
+	match = of_match_device(arm_cci_matches, &pdev->dev);
+
+	if (!match)
+		return -ENODEV;
+
+	cci_config = (struct cci_nb_ports const *)match->data;
+	nb_cci_ports = cci_config->nb_ace + cci_config->nb_ace_lite;
+	ports = kzalloc(sizeof(*ports) * nb_cci_ports, GFP_KERNEL);
+	if (!ports)
+		return -ENOMEM;
+
+	np = pdev->dev.of_node;
+	cci_ctrl_base = of_iomap(np, 0);
+
+	if (!cci_ctrl_base) {
+		dev_err(&pdev->dev, "unable to ioremap CCI ctrl\n");
+		ret = -ENXIO;
+		goto memalloc_err;
+	}
+	for_each_child_of_node(np, cp) {
+		i = nb_ace + nb_ace_lite;
+
+		if (i >= nb_cci_ports)
+			break;
+
+		if (of_property_read_string(cp, "interface-type",
+					    &match_str)) {
+			WARN(1, " * %s missing interface-type property\n",
+				  cp->full_name);
+			continue;
+		}
+
+		/*
+		 * A CCI interface has to define a "master" affinity
+		 * property otherwise it is not considered valid
+		 */
+		if (!strcmp(match_str, "ace")) {
+			if (WARN_ON(nb_ace >= cci_config->nb_ace))
+				continue;
+			cpumask_clear(&ports[i].match.match_mask);
+			if (arm_dt_affine_get_mask(cp, "master", 0,
+					&ports[i].match.match_mask))
+				continue;
+			ports[i].type = ACE_PORT;
+			++nb_ace;
+		} else if (!strcmp(match_str, "ace-lite")) {
+			if (WARN_ON(nb_ace_lite >= cci_config->nb_ace_lite))
+				continue;
+
+			ports[i].match.np =
+				of_parse_phandle(cp, "master", 0);
+
+			if (!ports[i].match.np)
+				continue;
+			of_node_put(ports[i].match.np);
+			ports[i].type = ACE_LITE_PORT;
+			++nb_ace_lite;
+		} else {
+			WARN(1, " * %s containing invalid interface-type"
+				" property, skipping it\n", cp->full_name);
+			continue;
+		}
+
+		ports[i].base = of_iomap(cp, 0);
+
+		if (!ports[i].base) {
+			dev_err(&pdev->dev, "unable to ioremap "
+					    "ace port %d\n", i);
+			ret = -ENXIO;
+			goto ioremap_err;
+		}
+	}
+	cci_ace_init_ports();
+	/*
+	 * Multi-cluster systems may need this data when non-coherent, during
+	 * cluster power-up/power-down. Make sure it reaches main memory:
+	 */
+	__cpuc_flush_dcache_area(ports, sizeof(*ports) * nb_cci_ports);
+	__cpuc_flush_dcache_area(&cci_ctrl_base, sizeof cci_ctrl_base);
+	__cpuc_flush_dcache_area(cpu_port, sizeof cpu_port);
+	outer_clean_range(virt_to_phys(ports),
+			  virt_to_phys(ports + nb_cci_ports));
+	outer_clean_range(virt_to_phys(&cci_ctrl_base),
+			  virt_to_phys(&cci_ctrl_base + 1));
+	outer_clean_range(virt_to_phys(cpu_port),
+			  virt_to_phys(cpu_port + NR_CPUS));
+	dev_info(&pdev->dev, "ARM CCI driver probed\n");
+	return 0;
+
+ioremap_err:
+	for (j = 0; j < nb_cci_ports; j++) {
+		if (j == i)
+			break;
+		iounmap(ports[j].base);
+	}
+
+	iounmap(cci_ctrl_base);
+memalloc_err:
+
+	kfree(ports);
+	return ret;
+}
+
+static int __exit cci_driver_remove(struct platform_device *pdev)
+{
+	int i;
+
+	for (i = 0; i < nb_cci_ports; i++)
+		if (ports[i].base)
+			iounmap(ports[i].base);
+
+	iounmap(cci_ctrl_base);
+	kfree(ports);
+	return 0;
+}
+
+static const struct cci_nb_ports cci400_ports = {
+	.nb_ace = 2,
+	.nb_ace_lite = 3
+};
+
+static const struct of_device_id arm_cci_matches[] = {
+	{.compatible = "arm,cci-400", .data = &cci400_ports },
+	{},
+};
+
+static struct platform_driver cci_platform_driver = {
+	.driver = {
+		   .owner = THIS_MODULE,
+		   .name = DRIVER_NAME,
+		   .of_match_table = arm_cci_matches,
+		   },
+	.probe = cci_driver_probe,
+	.remove = cci_driver_remove,
+};
+
+static int __init cci_init(void)
+{
+	return platform_driver_register(&cci_platform_driver);
+}
+
+static void __exit cci_exit(void)
+{
+	platform_driver_unregister(&cci_platform_driver);
+}
+
+core_initcall(cci_init);
+module_exit(cci_exit);
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("ARM CCI support");
diff --git a/include/linux/arm-cci.h b/include/linux/arm-cci.h
new file mode 100644
index 0000000..e9514a2
--- /dev/null
+++ b/include/linux/arm-cci.h
@@ -0,0 +1,44 @@
+/*
+ * CCI cache coherent interconnect support
+ *
+ * Copyright (C) 2012 ARM Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+
+#ifndef __LINUX_ARM_CCI_H
+#define __LINUX_ARM_CCI_H
+
+#include <linux/errno.h>
+#include <linux/of.h>
+#include <linux/types.h>
+
+#ifdef CONFIG_ARM_CCI
+extern int cci_disable_port_by_cpu(u64 mpidr);
+extern int __cci_control_port_by_device(struct device_node *np, bool enable);
+#else
+static inline int cci_disable_port_by_cpu(u64 mpidr) { return -ENODEV; }
+static inline int __cci_control_port_by_device(struct device_node *np,
+						bool enable)
+{
+	return -ENODEV;
+}
+#endif
+#define cci_disable_port_by_device(node) \
+	__cci_control_port_by_device(node, false)
+#define cci_enable_port_by_device(node) \
+	__cci_control_port_by_device(node, true)
+
+#endif
-- 
1.7.12




From plagnioj at jcrosoft.com  Thu Apr 11 10:53:03 2013
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Thu, 11 Apr 2013 16:53:03 +0200
Subject: [RFC 1/5] ARM: at91: add general purpose backup register
 (GPBR) support
In-Reply-To: <20130411123908.GB21305@localhost>
References: <20130407150938.GA25605@localhost>
 <1365347572-14972-1-git-send-email-jhovold@gmail.com>
 <20130408073329.GO20693@game.jcrosoft.org>
 <20130408084618.GB25605@localhost>
 <20130408100417.GT20693@game.jcrosoft.org>
 <20130411123908.GB21305@localhost>
Message-ID: <20130411145303.GA25242@game.jcrosoft.org>

On 14:39 Thu 11 Apr     , Johan Hovold wrote:
> On Mon, Apr 08, 2013 at 12:04:17PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > On 10:46 Mon 08 Apr     , Johan Hovold wrote:
> > > On Mon, Apr 08, 2013 at 09:33:29AM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > > > On 17:12 Sun 07 Apr     , Johan Hovold wrote:
> > > > > 
> > > > > Add General Purpose Backup Register (GPBR) support.
> > > > > 
> > > > > Most at91 SoCs have at least four 32-bit General Purpose Backup
> > > > > Registers (GPBR) powered by backup-power (VDDBU). One such register is
> > > > > currently used by rtc-at91sam9 driver to store the RTC time base.
> > > > > 
> > > > > Make sure the registers are mapped by arch setup code and add generic
> > > > > accessors for in-kernel use.
> > > > > 
> > > > > This is a step in adding device-tree support to the rtc-at91sam9 driver.
> > > > > 
> > > > This is a regression
> > > > 
> > > > we loose the tracking of what request and use the GPBR
> > > 
> > > Implementing the GPBR accessors using a simple global resource was one
> > > quick way forward to decouple and generalise the GPBR. Of course, this
> > > could be turned into a more elaborate framework or driver where
> > > registers are requested and released by other drivers and possibly also
> > > by user-space.
> > yes must as we used on SAMA5 to pass the boot source from the firstage
> > of the boot loader to the other software
> 
> Could you please elaborate on this; how is the GPBR used, how many
> registers, and when is it accessed?

The second stage bootloader store the content of the boot mode passs via r4
from the Rom-Code in the 2nd gpbr
> 
> Is there already code in at91/at91-3.10-soc or are you referring to
> a userspace consumer?
no user you can see the code in barebox
you can see the code of barebox here
http://git.linupdate.org/git?p=barebox.git;a=shortlog;h=refs/heads/delivery/sama5-release-bootmode

Best Regards,
J.
> 
> Thanks,
> Johan


From arnd at arndb.de  Thu Apr 11 10:59:50 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 11 Apr 2013 16:59:50 +0200
Subject: [GIT PULL] ARM: mvebu: fixes for v3.9 (round 3)
In-Reply-To: <20130410171254.GD28693@titan.lakedaemon.net>
References: <20130410171254.GD28693@titan.lakedaemon.net>
Message-ID: <201304111659.50770.arnd@arndb.de>

On Wednesday 10 April 2013, Jason Cooper wrote:
> 
> The following changes since commit 879d68a445dd7073a8c022fcdd21dc27eca7f192:
> 
>   arm: mvebu: Fix pinctrl for Armada 370 Mirabox SDIO port. (2013-03-28 17:29:23 +0000)
> 
> are available in the git repository at:
> 
>   git://git.infradead.org/users/jcooper/linux.git tags/mvebu_fixes_for_v3.9_round3
> 
> for you to fetch changes up to 600468d0686096ddc1000c8a2e69475931084414:
> 
>   arm: mvebu: Fix the irq map function in SMP mode (2013-04-10 16:59:14 +0000)
> 
> ----------------------------------------------------------------
> mvebu fixes for v3.9 round 3
> 
>  - Kirkwood
>     - a couple of small fixes for the Iomega ix2-200 board (ether and led)
>  - mvebu
>     - allow GPIO button to work on Mirabox when running SMP

Pulled into the fixes branch. I'll try to get a pull request out to Linus today,
since we already have a few other patches pending.

	Arnd


From robherring2 at gmail.com  Thu Apr 11 11:00:47 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Thu, 11 Apr 2013 10:00:47 -0500
Subject: [RFC PATCH 01/11] Documentation: DT: arm: define CPU topology
 bindings
In-Reply-To: <1365671562-2403-2-git-send-email-mark.rutland@arm.com>
References: <1365671562-2403-1-git-send-email-mark.rutland@arm.com>
 <1365671562-2403-2-git-send-email-mark.rutland@arm.com>
Message-ID: <5166D01F.5070404@gmail.com>

On 04/11/2013 04:12 AM, Mark Rutland wrote:
> From: Lorenzo Pieralisi <Lorenzo.Pieralisi at arm.com>
> 
> The advent of multi-cluster ARM systems requires a mechanism to describe
> how in hierarchical terms CPUs are connected in ARM SoCs so that the kernel
> can initialize and map resources like IRQs and memory space to specific
> group(s) of CPUs.
> 
> The CPU topology is made up of multiple hierarchy levels whose bottom
> layers (aka leaf nodes in device tree syntax) contain links to the HW
> CPUs in the system.
> 
> The topology bindings are generic for both 32-bit and 64-bit systems and
> lay the groundwork on top of which affinity schemes can be built.
> 
> This patch provides the documentation in the kernel required to define the
> device tree bindings describing the CPU topology for ARM 32-bit and 64-bit
> systems.

I'm now very weary of continued /cpu changes after the pain of making
the reg property reflect the mpidr value in 3.8.

> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
> Signed-off-by: Mark Rutland <mark.rutland at arm.com>
> ---
>  Documentation/devicetree/bindings/arm/topology.txt | 524 +++++++++++++++++++++
>  1 file changed, 524 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/arm/topology.txt
> 
> diff --git a/Documentation/devicetree/bindings/arm/topology.txt b/Documentation/devicetree/bindings/arm/topology.txt
> new file mode 100644
> index 0000000..07c4961
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/topology.txt
> @@ -0,0 +1,524 @@
> +===========================================
> +ARM topology binding description
> +===========================================
> +
> +===========================================
> +1 - Introduction
> +===========================================
> +
> +In an ARM system, the hierarchy of CPUs is defined through three entities that
> +are used to describe the layout of physical CPUs in the system:
> +
> +- cluster
> +- core
> +- thread
> +
> +The cpu nodes (bindings defined in [1]) represent the devices that
> +correspond to physical CPUs and are to be mapped to the hierarchy levels.
> +
> +The bottom hierarchy level sits at core or thread level depending on whether
> +symmetric multi-threading (SMT) is supported or not.
> +
> +For instance in a system where CPUs support SMT, "cpu" nodes represent all
> +threads existing in the system and map to the hierarchy level "thread" above.
> +In systems where SMT is not supported "cpu" nodes represent all cores present
> +in the system and map to the hierarchy level "core" above.
> +
> +ARM topology bindings allow one to associate cpu nodes with hierarchical groups
> +corresponding to the system hierarchy; syntactically they are defined as device
> +tree nodes.
> +
> +The remainder of this document provides the topology bindings for ARM, based
> +on the ePAPR standard, available from:
> +
> +http://devicetree.org
> +
> +If not stated otherwise, whenever a reference to a cpu node phandle is made its
> +value must point to a cpu node compliant with the cpu node bindings as
> +documented in [1].
> +A topology description containing phandles to cpu nodes that are not compliant
> +with bindings standardized in [1] is therefore considered invalid.
> +
> +===========================================
> +2 - cpu-map node
> +===========================================
> +
> +The ARM CPU topology is defined within a container node, sitting at the top
> +level of the device tree (/), the cpu-map node.
> +
> +- cpu-map node
> +
> +	Usage: Required to define ARM CPU topology
> +
> +	Description: The cpu-map node is just a container node where its
> +		     subnodes describe the CPU topology
> +
> +	Node name must be "cpu-map".
> +
> +	A cpu-map node's child nodes can be:
> +
> +	- one or more cluster nodes
> +
> +	Any other configuration is considered invalid.
> +
> +The cpu-map node can only contain three types of child nodes:
> +
> +- cluster node
> +- core node
> +- thread node
> +

Why not put the topology in the /cpus nodes? I don't really see the
point of having a flat list of cpus and separate topology info. There is
some compatibility issue, but adding optional levels for clusters can be
handled.

> +whose bindings are described in paragraph 3.
> +
> +The nodes describing the CPU topology (cluster/core/thread) can only be
> +defined within the cpu-map node.
> +Any other configuration is consider invalid and therefore must be ignored.
> +
> +===========================================
> +2.1 - cpu-map child nodes naming convention
> +===========================================
> +
> +cpu-map child nodes must follow a naming convention where the node name
> +must be "clusterN", "coreN", "threadN" depending on the node type (ie
> +cluster/core/thread) (where N = {0, 1, ...} is the node number; nodes which
> +are siblings within a single common parent node must be given a unique and
> +sequential N value, starting from 0).
> +cpu-map child nodes which do not share a common parent node can have the same
> +name (ie same number N as other cpu-map child nodes at different device tree
> +levels) since name uniqueness will be guaranteed by the device tree hierarchy.
> +
> +===========================================
> +3 - cluster/core/thread node bindings
> +===========================================
> +
> +Bindings for cluster/cpu/thread nodes are defined as follows:
> +
> +- cluster node
> +
> +	 Description: must be declared within a cpu-map node, one node
> +		      per cluster. A system can contain several layers of
> +		      clustering and cluster nodes can be contained in parent
> +		      cluster nodes.
> +
> +	The cluster node name must be "clusterN" as described in 2.1 above.
> +	A cluster node can not be a leaf node.

Follow standard conventions with "cluster at N" and a reg property with the
number.

> +
> +	A cluster node's child nodes must be:
> +
> +	- one or more cluster nodes; or
> +	- one or more core nodes
> +
> +	Any other configuration is considered invalid.
> +
> +- core node
> +
> +	Description: must be declared in a cluster node, one node per core in
> +		     the cluster. If the system does not support SMT, core
> +		     nodes are leaf nodes, otherwise they become containers of
> +		     thread nodes.
> +
> +	The core node name must be "coreN" as described in 2.1 above.
> +
> +	A core node must be a leaf node if SMT is not supported.
> +
> +	Properties for core nodes that are leaf nodes:
> +
> +	- cpu
> +		Usage: required
> +		Value type: <phandle>
> +		Definition: a phandle to the cpu node that corresponds to the
> +			    core node.
> +
> +	If a core node is not a leaf node (CPUs supporting SMT) a core node's
> +	child nodes can be:
> +
> +	- one or more thread nodes
> +
> +	Any other configuration is considered invalid.
> +
> +- thread node
> +
> +	Description: must be declared in a core node, one node per thread
> +		     in the core if the system supports SMT. Thread nodes are
> +		     always leaf nodes in the device tree.
> +
> +	The thread node name must be "threadN" as described in 2.1 above.
> +
> +	A thread node must be a leaf node.
> +
> +	A thread node must contain the following property:
> +
> +	- cpu
> +		Usage: required
> +		Value type: <phandle>
> +		Definition: a phandle to the cpu node that corresponds to
> +			    the thread node.


According to the ePAPR, threads are represented by an array of ids for
reg property, not another cpu node. Why the deviation.

Rob




From w at 1wt.eu  Thu Apr 11 11:03:26 2013
From: w at 1wt.eu (Willy Tarreau)
Date: Thu, 11 Apr 2013 17:03:26 +0200
Subject: [PATCH] net: mv643xx_eth: Add GRO support
In-Reply-To: <CABJ1b_TQDabT1J7ffo5cb1Th=71bcSduifMJaDpfVRiiHvtWDw@mail.gmail.com>
References: <1365684023-9967-1-git-send-email-sebastian.hesselbarth@gmail.com>
 <20130411131333.GD1910@1wt.eu>
 <CABJ1b_TQDabT1J7ffo5cb1Th=71bcSduifMJaDpfVRiiHvtWDw@mail.gmail.com>
Message-ID: <20130411150326.GA19978@1wt.eu>

Hi Sebastian,

On Thu, Apr 11, 2013 at 04:47:49PM +0200, Sebastian Hesselbarth wrote:
> I did some simple tests on Dove/Cubox with 'netperf -cCD' and
> gso/gro/lro options on
> mv643xx_eth. The tests may not be sufficient, as I am not that into
> net performance testing.

In fact the difference only happens when the NIC has not verified the
checksum itself IIRC, which should be for non-IPv4 traffic. I agree
that it's not easy to test a bridge with a cubox which has a single
port :-) Maybe you'll see a difference in IPv6 traffic or with VLAN
traffic, as I seem to remember this chip does not do cksum offloading
on VLANs, but I could be wrong.

> I tried todays net-next on top of 3.9-rc6 without any gro patch, with
> the initial
> patch (Soeren) and your proposed patch (Willy). The results show that
> both patches
> allow a significant increase in throughput compared to
> netif_receive_skb (!gro, !lro)
> alone. Having gro with lro disabled gives some 2% more throughput
> compared to lro only.

Indeed this is consistent with my memories, since Eric improved the
GRO path, it became faster than LRO on this chip.

Regards,
Willy



From plagnioj at jcrosoft.com  Thu Apr 11 11:00:17 2013
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Thu, 11 Apr 2013 17:00:17 +0200
Subject: [PATCH 3/8] video: atmel_lcdfb: pass the pdata as params
In-Reply-To: <1365692422-9565-1-git-send-email-plagnioj@jcrosoft.com>
References: <20130411145741.GB25242@game.jcrosoft.org>
 <1365692422-9565-1-git-send-email-plagnioj@jcrosoft.com>
Message-ID: <1365692422-9565-3-git-send-email-plagnioj@jcrosoft.com>

so we can use have list gpio as example (probe via DT)

Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
Cc: linux-fbdev at vger.kernel.org
Cc: Nicolas Ferre <nicolas.ferre at atmel.com>
Cc: Andrew Morton <akpm at linux-foundation.org>
---
 arch/arm/mach-at91/board-sam9261ek.c   |    4 ++--
 arch/arm/mach-at91/board-sam9263ek.c   |    2 +-
 arch/arm/mach-at91/board-sam9rlek.c    |    2 +-
 arch/avr32/boards/atngw100/evklcd10x.c |    2 +-
 drivers/video/atmel_lcdfb.c            |    2 +-
 include/video/atmel_lcdc.h             |    4 +++-
 6 files changed, 9 insertions(+), 7 deletions(-)

diff --git a/arch/arm/mach-at91/board-sam9261ek.c b/arch/arm/mach-at91/board-sam9261ek.c
index c819e29..9a6618a 100644
--- a/arch/arm/mach-at91/board-sam9261ek.c
+++ b/arch/arm/mach-at91/board-sam9261ek.c
@@ -393,7 +393,7 @@ static struct fb_monspecs at91fb_default_stn_monspecs = {
 					| ATMEL_LCDC_IFWIDTH_4 \
 					| ATMEL_LCDC_SCANMOD_SINGLE)
 
-static void at91_lcdc_stn_power_control(int on)
+static void at91_lcdc_stn_power_control(struct atmel_lcdfb_pdata *pdata, int on)
 {
 	/* backlight */
 	if (on) {	/* power up */
@@ -452,7 +452,7 @@ static struct fb_monspecs at91fb_default_tft_monspecs = {
 					| ATMEL_LCDC_DISTYPE_TFT    \
 					| ATMEL_LCDC_CLKMOD_ALWAYSACTIVE)
 
-static void at91_lcdc_tft_power_control(int on)
+static void at91_lcdc_tft_power_control(struct atmel_lcdfb_pdata *pdata, int on)
 {
 	if (on)
 		at91_set_gpio_value(AT91_PIN_PA12, 0);	/* power up */
diff --git a/arch/arm/mach-at91/board-sam9263ek.c b/arch/arm/mach-at91/board-sam9263ek.c
index 0fdae3f..8b4942c 100644
--- a/arch/arm/mach-at91/board-sam9263ek.c
+++ b/arch/arm/mach-at91/board-sam9263ek.c
@@ -275,7 +275,7 @@ static struct fb_monspecs at91fb_default_monspecs = {
 					| ATMEL_LCDC_DISTYPE_TFT \
 					| ATMEL_LCDC_CLKMOD_ALWAYSACTIVE)
 
-static void at91_lcdc_power_control(int on)
+static void at91_lcdc_power_control(struct atmel_lcdfb_pdata *pdata, int on)
 {
 	at91_set_gpio_value(AT91_PIN_PA30, on);
 }
diff --git a/arch/arm/mach-at91/board-sam9rlek.c b/arch/arm/mach-at91/board-sam9rlek.c
index b77d7a9..604eecf 100644
--- a/arch/arm/mach-at91/board-sam9rlek.c
+++ b/arch/arm/mach-at91/board-sam9rlek.c
@@ -170,7 +170,7 @@ static struct fb_monspecs at91fb_default_monspecs = {
 					| ATMEL_LCDC_DISTYPE_TFT \
 					| ATMEL_LCDC_CLKMOD_ALWAYSACTIVE)
 
-static void at91_lcdc_power_control(int on)
+static void at91_lcdc_power_control(struct atmel_lcdfb_pdata *pdata, int on)
 {
 	if (on)
 		at91_set_gpio_value(AT91_PIN_PC1, 0);	/* power up */
diff --git a/arch/avr32/boards/atngw100/evklcd10x.c b/arch/avr32/boards/atngw100/evklcd10x.c
index dc42804..64919b0 100644
--- a/arch/avr32/boards/atngw100/evklcd10x.c
+++ b/arch/avr32/boards/atngw100/evklcd10x.c
@@ -145,7 +145,7 @@ static struct atmel_lcdfb_pdata __initdata atevklcd10x_lcdc_data = {
 };
 #endif
 
-static void atevklcd10x_lcdc_power_control(int on)
+static void atevklcd10x_lcdc_power_control(struct atmel_lcdfb_pdata *pdata, int on)
 {
 	gpio_set_value(GPIO_PIN_PB(15), on);
 }
diff --git a/drivers/video/atmel_lcdfb.c b/drivers/video/atmel_lcdfb.c
index 9574c47..f67e226 100644
--- a/drivers/video/atmel_lcdfb.c
+++ b/drivers/video/atmel_lcdfb.c
@@ -288,7 +288,7 @@ static inline void atmel_lcdfb_power_control(struct atmel_lcdfb_info *sinfo, int
 	struct atmel_lcdfb_pdata *pdata = &sinfo->pdata;
 
 	if (pdata->atmel_lcdfb_power_control)
-		pdata->atmel_lcdfb_power_control(on);
+		pdata->atmel_lcdfb_power_control(pdata, on);
 }
 
 static struct fb_fix_screeninfo atmel_lcdfb_fix __initdata = {
diff --git a/include/video/atmel_lcdc.h b/include/video/atmel_lcdc.h
index 2eb601c..f624c51 100644
--- a/include/video/atmel_lcdc.h
+++ b/include/video/atmel_lcdc.h
@@ -40,8 +40,10 @@ struct atmel_lcdfb_pdata {
 	u8			lcd_wiring_mode;
 	unsigned int		default_lcdcon2;
 	unsigned int		default_dmacon;
-	void (*atmel_lcdfb_power_control)(int on);
+	void (*atmel_lcdfb_power_control)(struct atmel_lcdfb_pdata *pdata, int on);
 	struct fb_monspecs	*default_monspecs;
+
+	struct list_head	pwr_gpios;
 };
 
 #define ATMEL_LCDC_DMABADDR1	0x00
-- 
1.7.10.4



From plagnioj at jcrosoft.com  Thu Apr 11 11:00:16 2013
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Thu, 11 Apr 2013 17:00:16 +0200
Subject: [PATCH 2/8] video: atmel_lcdfb: introduce atmel_lcdfb_power_control
In-Reply-To: <1365692422-9565-1-git-send-email-plagnioj@jcrosoft.com>
References: <20130411145741.GB25242@game.jcrosoft.org>
 <1365692422-9565-1-git-send-email-plagnioj@jcrosoft.com>
Message-ID: <1365692422-9565-2-git-send-email-plagnioj@jcrosoft.com>

to simplify the check on the presence of the callback

Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
Cc: linux-fbdev at vger.kernel.org
Cc: Nicolas Ferre <nicolas.ferre at atmel.com>
Cc: Andrew Morton <akpm at linux-foundation.org>
---
 drivers/video/atmel_lcdfb.c |   22 +++++++++++-----------
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/video/atmel_lcdfb.c b/drivers/video/atmel_lcdfb.c
index 98733cd4..9574c47 100644
--- a/drivers/video/atmel_lcdfb.c
+++ b/drivers/video/atmel_lcdfb.c
@@ -283,6 +283,13 @@ static void init_contrast(struct atmel_lcdfb_info *sinfo)
 		init_backlight(sinfo);
 }
 
+static inline void atmel_lcdfb_power_control(struct atmel_lcdfb_info *sinfo, int on)
+{
+	struct atmel_lcdfb_pdata *pdata = &sinfo->pdata;
+
+	if (pdata->atmel_lcdfb_power_control)
+		pdata->atmel_lcdfb_power_control(on);
+}
 
 static struct fb_fix_screeninfo atmel_lcdfb_fix __initdata = {
 	.type		= FB_TYPE_PACKED_PIXELS,
@@ -1114,8 +1121,7 @@ static int __init atmel_lcdfb_probe(struct platform_device *pdev)
 	fb_add_videomode(&fbmode, &info->modelist);
 
 	/* Power up the LCDC screen */
-	if (pdata->atmel_lcdfb_power_control)
-		pdata->atmel_lcdfb_power_control(1);
+	atmel_lcdfb_power_control(sinfo, 1);
 
 	dev_info(dev, "fb%d: Atmel LCDC at 0x%08lx (mapped at %p), irq %d\n",
 		       info->node, info->fix.mmio_start, sinfo->mmio, sinfo->irq_base);
@@ -1169,8 +1175,7 @@ static int __exit atmel_lcdfb_remove(struct platform_device *pdev)
 
 	cancel_work_sync(&sinfo->task);
 	exit_backlight(sinfo);
-	if (pdata->atmel_lcdfb_power_control)
-		pdata->atmel_lcdfb_power_control(0);
+	atmel_lcdfb_power_control(sinfo, 0);
 	unregister_framebuffer(info);
 	atmel_lcdfb_stop_clock(sinfo);
 	clk_put(sinfo->lcdc_clk);
@@ -1198,7 +1203,6 @@ static int atmel_lcdfb_suspend(struct platform_device *pdev, pm_message_t mesg)
 {
 	struct fb_info *info = platform_get_drvdata(pdev);
 	struct atmel_lcdfb_info *sinfo = info->par;
-	struct atmel_lcdfb_pdata *pdata = &sinfo->pdata;
 
 	/*
 	 * We don't want to handle interrupts while the clock is
@@ -1208,9 +1212,7 @@ static int atmel_lcdfb_suspend(struct platform_device *pdev, pm_message_t mesg)
 
 	sinfo->saved_lcdcon = lcdc_readl(sinfo, ATMEL_LCDC_CONTRAST_CTR);
 	lcdc_writel(sinfo, ATMEL_LCDC_CONTRAST_CTR, 0);
-	if (pdata->atmel_lcdfb_power_control)
-		pdata->atmel_lcdfb_power_control(0);
-
+	atmel_lcdfb_power_control(sinfo, 0);
 	atmel_lcdfb_stop(sinfo);
 	atmel_lcdfb_stop_clock(sinfo);
 
@@ -1221,12 +1223,10 @@ static int atmel_lcdfb_resume(struct platform_device *pdev)
 {
 	struct fb_info *info = platform_get_drvdata(pdev);
 	struct atmel_lcdfb_info *sinfo = info->par;
-	struct atmel_lcdfb_pdata *pdata = &sinfo->pdata;
 
 	atmel_lcdfb_start_clock(sinfo);
 	atmel_lcdfb_start(sinfo);
-	if (pdata->atmel_lcdfb_power_control)
-		pdata->atmel_lcdfb_power_control(1);
+	atmel_lcdfb_power_control(sinfo, 1);
 	lcdc_writel(sinfo, ATMEL_LCDC_CONTRAST_CTR, sinfo->saved_lcdcon);
 
 	/* Enable FIFO & DMA errors */
-- 
1.7.10.4



From plagnioj at jcrosoft.com  Thu Apr 11 11:00:19 2013
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Thu, 11 Apr 2013 17:00:19 +0200
Subject: [PATCH 5/8] ARM: at91: sam9g45: add lcd support
In-Reply-To: <1365692422-9565-1-git-send-email-plagnioj@jcrosoft.com>
References: <20130411145741.GB25242@game.jcrosoft.org>
 <1365692422-9565-1-git-send-email-plagnioj@jcrosoft.com>
Message-ID: <1365692422-9565-5-git-send-email-plagnioj@jcrosoft.com>

Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
Cc: Nicolas Ferre <nicolas.ferre at atmel.com>
---
 arch/arm/boot/dts/at91sam9g45.dtsi |   47 ++++++++++++++++++++++++++++++++++++
 1 file changed, 47 insertions(+)

diff --git a/arch/arm/boot/dts/at91sam9g45.dtsi b/arch/arm/boot/dts/at91sam9g45.dtsi
index 6b1d4ca..ab8a8fc 100644
--- a/arch/arm/boot/dts/at91sam9g45.dtsi
+++ b/arch/arm/boot/dts/at91sam9g45.dtsi
@@ -322,6 +322,42 @@
 					};
 				};
 
+				fb {
+					pinctrl_fb: fb-0 {
+						atmel,pins =
+							<4 0 0x1 0x0	/* PE0 periph A */
+							 4 2 0x1 0x0	/* PE2 periph A */
+							 4 3 0x1 0x0	/* PE3 periph A */
+							 4 4 0x1 0x0	/* PE4 periph A */
+							 4 5 0x1 0x0	/* PE5 periph A */
+							 4 6 0x1 0x0	/* PE6 periph A */
+							 4 7 0x1 0x0	/* PE7 periph A */
+							 4 8 0x1 0x0	/* PE8 periph A */
+							 4 9 0x1 0x0	/* PE9 periph A */
+							 4 10 0x1 0x0	/* PE10 periph A */
+							 4 11 0x1 0x0	/* PE11 periph A */
+							 4 12 0x1 0x0	/* PE12 periph A */
+							 4 13 0x1 0x0	/* PE13 periph A */
+							 4 14 0x1 0x0	/* PE14 periph A */
+							 4 15 0x1 0x0	/* PE15 periph A */
+							 4 16 0x1 0x0	/* PE16 periph A */
+							 4 17 0x1 0x0	/* PE17 periph A */
+							 4 18 0x1 0x0	/* PE18 periph A */
+							 4 19 0x1 0x0	/* PE19 periph A */
+							 4 20 0x1 0x0	/* PE20 periph A */
+							 4 21 0x1 0x0	/* PE21 periph A */
+							 4 22 0x1 0x0	/* PE22 periph A */
+							 4 23 0x1 0x0	/* PE23 periph A */
+							 4 24 0x1 0x0	/* PE24 periph A */
+							 4 25 0x1 0x0	/* PE25 periph A */
+							 4 26 0x1 0x0	/* PE26 periph A */
+							 4 27 0x1 0x0	/* PE27 periph A */
+							 4 28 0x1 0x0	/* PE28 periph A */
+							 4 29 0x1 0x0	/* PE29 periph A */
+							 4 30 0x1 0x0>;	/* PE30 periph A */
+					};
+				};
+
 				pioA: gpio at fffff200 {
 					compatible = "atmel,at91rm9200-gpio";
 					reg = <0xfffff200 0x200>;
@@ -533,6 +569,17 @@
 			};
 		};
 
+		fb0: fb at 0x00500000 {
+			compatible = "atmel,at91sam9g45-lcdc";
+			reg = <0x00500000 0x1000>;
+			interrupts = <23 3 0>;
+			pinctrl-names = "default";
+			pinctrl-0 = <&pinctrl_fb>;
+			status = "disabled";
+			#address-cells = <1>;
+			#size-cells = <1>;
+		};
+
 		nand0: nand at 40000000 {
 			compatible = "atmel,at91rm9200-nand";
 			#address-cells = <1>;
-- 
1.7.10.4



From plagnioj at jcrosoft.com  Thu Apr 11 11:00:15 2013
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Thu, 11 Apr 2013 17:00:15 +0200
Subject: [PATCH 1/8] video: atmel_lcdfb: fix platform data struct
In-Reply-To: <20130411145741.GB25242@game.jcrosoft.org>
References: <20130411145741.GB25242@game.jcrosoft.org>
Message-ID: <1365692422-9565-1-git-send-email-plagnioj@jcrosoft.com>

Today we mix pdata and drivers data in the struct atmel_lcdfb_info
Fix it and introduce a new struct atmel_lcdfb_pdata for platform data only

Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
Cc: linux-fbdev at vger.kernel.org
Cc: Nicolas Ferre <nicolas.ferre at atmel.com>
Cc: Andrew Morton <akpm at linux-foundation.org>
Cc: Hans-Christian Egtvedt <egtvedt at samfundet.no>
---
 arch/arm/mach-at91/at91sam9261_devices.c    |    6 +-
 arch/arm/mach-at91/at91sam9263_devices.c    |    6 +-
 arch/arm/mach-at91/at91sam9g45_devices.c    |    6 +-
 arch/arm/mach-at91/at91sam9rl_devices.c     |    6 +-
 arch/arm/mach-at91/board-sam9261ek.c        |    6 +-
 arch/arm/mach-at91/board-sam9263ek.c        |    4 +-
 arch/arm/mach-at91/board-sam9m10g45ek.c     |    4 +-
 arch/arm/mach-at91/board-sam9rlek.c         |    4 +-
 arch/arm/mach-at91/board.h                  |    4 +-
 arch/avr32/boards/atngw100/evklcd10x.c      |    6 +-
 arch/avr32/boards/atngw100/mrmt.c           |    4 +-
 arch/avr32/boards/atstk1000/atstk1000.h     |    2 +-
 arch/avr32/boards/atstk1000/setup.c         |    2 +-
 arch/avr32/boards/favr-32/setup.c           |    2 +-
 arch/avr32/boards/hammerhead/setup.c        |    2 +-
 arch/avr32/boards/merisc/display.c          |    2 +-
 arch/avr32/boards/mimc200/setup.c           |    4 +-
 arch/avr32/mach-at32ap/at32ap700x.c         |    8 +--
 arch/avr32/mach-at32ap/include/mach/board.h |    4 +-
 drivers/video/atmel_lcdfb.c                 |  104 +++++++++++++++++----------
 include/video/atmel_lcdc.h                  |   24 +------
 21 files changed, 109 insertions(+), 101 deletions(-)

diff --git a/arch/arm/mach-at91/at91sam9261_devices.c b/arch/arm/mach-at91/at91sam9261_devices.c
index 629ea5f..b2a3474 100644
--- a/arch/arm/mach-at91/at91sam9261_devices.c
+++ b/arch/arm/mach-at91/at91sam9261_devices.c
@@ -465,7 +465,7 @@ void __init at91_add_device_spi(struct spi_board_info *devices, int nr_devices)
 
 #if defined(CONFIG_FB_ATMEL) || defined(CONFIG_FB_ATMEL_MODULE)
 static u64 lcdc_dmamask = DMA_BIT_MASK(32);
-static struct atmel_lcdfb_info lcdc_data;
+static struct atmel_lcdfb_pdata lcdc_data;
 
 static struct resource lcdc_resources[] = {
 	[0] = {
@@ -498,7 +498,7 @@ static struct platform_device at91_lcdc_device = {
 	.num_resources	= ARRAY_SIZE(lcdc_resources),
 };
 
-void __init at91_add_device_lcdc(struct atmel_lcdfb_info *data)
+void __init at91_add_device_lcdc(struct atmel_lcdfb_pdata *data)
 {
 	if (!data) {
 		return;
@@ -559,7 +559,7 @@ void __init at91_add_device_lcdc(struct atmel_lcdfb_info *data)
 	platform_device_register(&at91_lcdc_device);
 }
 #else
-void __init at91_add_device_lcdc(struct atmel_lcdfb_info *data) {}
+void __init at91_add_device_lcdc(struct atmel_lcdfb_pdata *data) {}
 #endif
 
 
diff --git a/arch/arm/mach-at91/at91sam9263_devices.c b/arch/arm/mach-at91/at91sam9263_devices.c
index 858c8aa..4aeaddd 100644
--- a/arch/arm/mach-at91/at91sam9263_devices.c
+++ b/arch/arm/mach-at91/at91sam9263_devices.c
@@ -832,7 +832,7 @@ void __init at91_add_device_can(struct at91_can_data *data) {}
 
 #if defined(CONFIG_FB_ATMEL) || defined(CONFIG_FB_ATMEL_MODULE)
 static u64 lcdc_dmamask = DMA_BIT_MASK(32);
-static struct atmel_lcdfb_info lcdc_data;
+static struct atmel_lcdfb_pdata lcdc_data;
 
 static struct resource lcdc_resources[] = {
 	[0] = {
@@ -859,7 +859,7 @@ static struct platform_device at91_lcdc_device = {
 	.num_resources	= ARRAY_SIZE(lcdc_resources),
 };
 
-void __init at91_add_device_lcdc(struct atmel_lcdfb_info *data)
+void __init at91_add_device_lcdc(struct atmel_lcdfb_pdata *data)
 {
 	if (!data)
 		return;
@@ -891,7 +891,7 @@ void __init at91_add_device_lcdc(struct atmel_lcdfb_info *data)
 	platform_device_register(&at91_lcdc_device);
 }
 #else
-void __init at91_add_device_lcdc(struct atmel_lcdfb_info *data) {}
+void __init at91_add_device_lcdc(struct atmel_lcdfb_pdata *data) {}
 #endif
 
 
diff --git a/arch/arm/mach-at91/at91sam9g45_devices.c b/arch/arm/mach-at91/at91sam9g45_devices.c
index fe626d4..82636c7 100644
--- a/arch/arm/mach-at91/at91sam9g45_devices.c
+++ b/arch/arm/mach-at91/at91sam9g45_devices.c
@@ -965,7 +965,7 @@ void __init at91_add_device_isi(struct isi_platform_data *data,
 
 #if defined(CONFIG_FB_ATMEL) || defined(CONFIG_FB_ATMEL_MODULE)
 static u64 lcdc_dmamask = DMA_BIT_MASK(32);
-static struct atmel_lcdfb_info lcdc_data;
+static struct atmel_lcdfb_pdata lcdc_data;
 
 static struct resource lcdc_resources[] = {
 	[0] = {
@@ -991,7 +991,7 @@ static struct platform_device at91_lcdc_device = {
 	.num_resources	= ARRAY_SIZE(lcdc_resources),
 };
 
-void __init at91_add_device_lcdc(struct atmel_lcdfb_info *data)
+void __init at91_add_device_lcdc(struct atmel_lcdfb_pdata *data)
 {
 	if (!data)
 		return;
@@ -1037,7 +1037,7 @@ void __init at91_add_device_lcdc(struct atmel_lcdfb_info *data)
 	platform_device_register(&at91_lcdc_device);
 }
 #else
-void __init at91_add_device_lcdc(struct atmel_lcdfb_info *data) {}
+void __init at91_add_device_lcdc(struct atmel_lcdfb_pdata *data) {}
 #endif
 
 
diff --git a/arch/arm/mach-at91/at91sam9rl_devices.c b/arch/arm/mach-at91/at91sam9rl_devices.c
index 352468f..a698bda 100644
--- a/arch/arm/mach-at91/at91sam9rl_devices.c
+++ b/arch/arm/mach-at91/at91sam9rl_devices.c
@@ -498,7 +498,7 @@ void __init at91_add_device_ac97(struct ac97c_platform_data *data) {}
 
 #if defined(CONFIG_FB_ATMEL) || defined(CONFIG_FB_ATMEL_MODULE)
 static u64 lcdc_dmamask = DMA_BIT_MASK(32);
-static struct atmel_lcdfb_info lcdc_data;
+static struct atmel_lcdfb_pdata lcdc_data;
 
 static struct resource lcdc_resources[] = {
 	[0] = {
@@ -525,7 +525,7 @@ static struct platform_device at91_lcdc_device = {
 	.num_resources	= ARRAY_SIZE(lcdc_resources),
 };
 
-void __init at91_add_device_lcdc(struct atmel_lcdfb_info *data)
+void __init at91_add_device_lcdc(struct atmel_lcdfb_pdata *data)
 {
 	if (!data) {
 		return;
@@ -557,7 +557,7 @@ void __init at91_add_device_lcdc(struct atmel_lcdfb_info *data)
 	platform_device_register(&at91_lcdc_device);
 }
 #else
-void __init at91_add_device_lcdc(struct atmel_lcdfb_info *data) {}
+void __init at91_add_device_lcdc(struct atmel_lcdfb_pdata *data) {}
 #endif
 
 
diff --git a/arch/arm/mach-at91/board-sam9261ek.c b/arch/arm/mach-at91/board-sam9261ek.c
index b446645..c819e29 100644
--- a/arch/arm/mach-at91/board-sam9261ek.c
+++ b/arch/arm/mach-at91/board-sam9261ek.c
@@ -405,7 +405,7 @@ static void at91_lcdc_stn_power_control(int on)
 	}
 }
 
-static struct atmel_lcdfb_info __initdata ek_lcdc_data = {
+static struct atmel_lcdfb_pdata __initdata ek_lcdc_data = {
 	.default_bpp			= 1,
 	.default_dmacon			= ATMEL_LCDC_DMAEN,
 	.default_lcdcon2		= AT91SAM9261_DEFAULT_STN_LCDCON2,
@@ -460,7 +460,7 @@ static void at91_lcdc_tft_power_control(int on)
 		at91_set_gpio_value(AT91_PIN_PA12, 1);	/* power down */
 }
 
-static struct atmel_lcdfb_info __initdata ek_lcdc_data = {
+static struct atmel_lcdfb_pdata __initdata ek_lcdc_data = {
 	.lcdcon_is_backlight		= true,
 	.default_bpp			= 16,
 	.default_dmacon			= ATMEL_LCDC_DMAEN,
@@ -475,7 +475,7 @@ static struct atmel_lcdfb_info __initdata ek_lcdc_data = {
 #endif
 
 #else
-static struct atmel_lcdfb_info __initdata ek_lcdc_data;
+static struct atmel_lcdfb_pdata __initdata ek_lcdc_data;
 #endif
 
 
diff --git a/arch/arm/mach-at91/board-sam9263ek.c b/arch/arm/mach-at91/board-sam9263ek.c
index 3284df0..0fdae3f 100644
--- a/arch/arm/mach-at91/board-sam9263ek.c
+++ b/arch/arm/mach-at91/board-sam9263ek.c
@@ -281,7 +281,7 @@ static void at91_lcdc_power_control(int on)
 }
 
 /* Driver datas */
-static struct atmel_lcdfb_info __initdata ek_lcdc_data = {
+static struct atmel_lcdfb_pdata __initdata ek_lcdc_data = {
 	.lcdcon_is_backlight		= true,
 	.default_bpp			= 16,
 	.default_dmacon			= ATMEL_LCDC_DMAEN,
@@ -292,7 +292,7 @@ static struct atmel_lcdfb_info __initdata ek_lcdc_data = {
 };
 
 #else
-static struct atmel_lcdfb_info __initdata ek_lcdc_data;
+static struct atmel_lcdfb_pdata __initdata ek_lcdc_data;
 #endif
 
 
diff --git a/arch/arm/mach-at91/board-sam9m10g45ek.c b/arch/arm/mach-at91/board-sam9m10g45ek.c
index 2a94896..ef39078 100644
--- a/arch/arm/mach-at91/board-sam9m10g45ek.c
+++ b/arch/arm/mach-at91/board-sam9m10g45ek.c
@@ -284,7 +284,7 @@ static struct fb_monspecs at91fb_default_monspecs = {
 					| ATMEL_LCDC_CLKMOD_ALWAYSACTIVE)
 
 /* Driver datas */
-static struct atmel_lcdfb_info __initdata ek_lcdc_data = {
+static struct atmel_lcdfb_pdata __initdata ek_lcdc_data = {
 	.lcdcon_is_backlight		= true,
 	.default_bpp			= 32,
 	.default_dmacon			= ATMEL_LCDC_DMAEN,
@@ -295,7 +295,7 @@ static struct atmel_lcdfb_info __initdata ek_lcdc_data = {
 };
 
 #else
-static struct atmel_lcdfb_info __initdata ek_lcdc_data;
+static struct atmel_lcdfb_pdata __initdata ek_lcdc_data;
 #endif
 
 
diff --git a/arch/arm/mach-at91/board-sam9rlek.c b/arch/arm/mach-at91/board-sam9rlek.c
index aa265dc..b77d7a9 100644
--- a/arch/arm/mach-at91/board-sam9rlek.c
+++ b/arch/arm/mach-at91/board-sam9rlek.c
@@ -179,7 +179,7 @@ static void at91_lcdc_power_control(int on)
 }
 
 /* Driver datas */
-static struct atmel_lcdfb_info __initdata ek_lcdc_data = {
+static struct atmel_lcdfb_pdata __initdata ek_lcdc_data = {
 	.lcdcon_is_backlight            = true,
 	.default_bpp			= 16,
 	.default_dmacon			= ATMEL_LCDC_DMAEN,
@@ -191,7 +191,7 @@ static struct atmel_lcdfb_info __initdata ek_lcdc_data = {
 };
 
 #else
-static struct atmel_lcdfb_info __initdata ek_lcdc_data;
+static struct atmel_lcdfb_pdata __initdata ek_lcdc_data;
 #endif
 
 
diff --git a/arch/arm/mach-at91/board.h b/arch/arm/mach-at91/board.h
index 4a234fb..6c08b34 100644
--- a/arch/arm/mach-at91/board.h
+++ b/arch/arm/mach-at91/board.h
@@ -107,8 +107,8 @@ extern void __init at91_add_device_pwm(u32 mask);
 extern void __init at91_add_device_ssc(unsigned id, unsigned pins);
 
  /* LCD Controller */
-struct atmel_lcdfb_info;
-extern void __init at91_add_device_lcdc(struct atmel_lcdfb_info *data);
+struct atmel_lcdfb_pdata;
+extern void __init at91_add_device_lcdc(struct atmel_lcdfb_pdata *data);
 
  /* AC97 */
 extern void __init at91_add_device_ac97(struct ac97c_platform_data *data);
diff --git a/arch/avr32/boards/atngw100/evklcd10x.c b/arch/avr32/boards/atngw100/evklcd10x.c
index 2038875..dc42804 100644
--- a/arch/avr32/boards/atngw100/evklcd10x.c
+++ b/arch/avr32/boards/atngw100/evklcd10x.c
@@ -58,7 +58,7 @@ static struct fb_monspecs __initdata atevklcd10x_default_monspecs = {
 	.dclkmax		= 28330000,
 };
 
-static struct atmel_lcdfb_info __initdata atevklcd10x_lcdc_data = {
+static struct atmel_lcdfb_pdata __initdata atevklcd10x_lcdc_data = {
 	.default_bpp		= 16,
 	.default_dmacon		= ATMEL_LCDC_DMAEN | ATMEL_LCDC_DMA2DEN,
 	.default_lcdcon2	= (ATMEL_LCDC_DISTYPE_TFT
@@ -96,7 +96,7 @@ static struct fb_monspecs __initdata atevklcd10x_default_monspecs = {
 	.dclkmax		= 7000000,
 };
 
-static struct atmel_lcdfb_info __initdata atevklcd10x_lcdc_data = {
+static struct atmel_lcdfb_pdata __initdata atevklcd10x_lcdc_data = {
 	.default_bpp		= 16,
 	.default_dmacon		= ATMEL_LCDC_DMAEN | ATMEL_LCDC_DMA2DEN,
 	.default_lcdcon2	= (ATMEL_LCDC_DISTYPE_TFT
@@ -134,7 +134,7 @@ static struct fb_monspecs __initdata atevklcd10x_default_monspecs = {
 	.dclkmax		= 6400000,
 };
 
-static struct atmel_lcdfb_info __initdata atevklcd10x_lcdc_data = {
+static struct atmel_lcdfb_pdata __initdata atevklcd10x_lcdc_data = {
 	.default_bpp		= 16,
 	.default_dmacon		= ATMEL_LCDC_DMAEN | ATMEL_LCDC_DMA2DEN,
 	.default_lcdcon2	= (ATMEL_LCDC_DISTYPE_TFT
diff --git a/arch/avr32/boards/atngw100/mrmt.c b/arch/avr32/boards/atngw100/mrmt.c
index f914319..ccc9599 100644
--- a/arch/avr32/boards/atngw100/mrmt.c
+++ b/arch/avr32/boards/atngw100/mrmt.c
@@ -83,7 +83,7 @@ static struct fb_monspecs __initdata lcd_fb_default_monspecs = {
 	.dclkmax		= 9260000,
 };
 
-static struct atmel_lcdfb_info __initdata rmt_lcdc_data = {
+static struct atmel_lcdfb_pdata __initdata rmt_lcdc_data = {
 	.default_bpp		= 24,
 	.default_dmacon		= ATMEL_LCDC_DMAEN | ATMEL_LCDC_DMA2DEN,
 	.default_lcdcon2	= (ATMEL_LCDC_DISTYPE_TFT
@@ -126,7 +126,7 @@ static struct fb_monspecs __initdata lcd_fb_default_monspecs = {
 	.dclkmax		= 9260000,
 };
 
-static struct atmel_lcdfb_info __initdata rmt_lcdc_data = {
+static struct atmel_lcdfb_pdata __initdata rmt_lcdc_data = {
 	.default_bpp		= 24,
 	.default_dmacon		= ATMEL_LCDC_DMAEN | ATMEL_LCDC_DMA2DEN,
 	.default_lcdcon2	= (ATMEL_LCDC_DISTYPE_TFT
diff --git a/arch/avr32/boards/atstk1000/atstk1000.h b/arch/avr32/boards/atstk1000/atstk1000.h
index 9392d32..653cc09 100644
--- a/arch/avr32/boards/atstk1000/atstk1000.h
+++ b/arch/avr32/boards/atstk1000/atstk1000.h
@@ -10,7 +10,7 @@
 #ifndef __ARCH_AVR32_BOARDS_ATSTK1000_ATSTK1000_H
 #define __ARCH_AVR32_BOARDS_ATSTK1000_ATSTK1000_H
 
-extern struct atmel_lcdfb_info atstk1000_lcdc_data;
+extern struct atmel_lcdfb_pdata atstk1000_lcdc_data;
 
 void atstk1000_setup_j2_leds(void);
 
diff --git a/arch/avr32/boards/atstk1000/setup.c b/arch/avr32/boards/atstk1000/setup.c
index 2d6b560..b6b88f5 100644
--- a/arch/avr32/boards/atstk1000/setup.c
+++ b/arch/avr32/boards/atstk1000/setup.c
@@ -55,7 +55,7 @@ static struct fb_monspecs __initdata atstk1000_default_monspecs = {
 	.dclkmax		= 30000000,
 };
 
-struct atmel_lcdfb_info __initdata atstk1000_lcdc_data = {
+struct atmel_lcdfb_pdata __initdata atstk1000_lcdc_data = {
 	.default_bpp		= 24,
 	.default_dmacon		= ATMEL_LCDC_DMAEN | ATMEL_LCDC_DMA2DEN,
 	.default_lcdcon2	= (ATMEL_LCDC_DISTYPE_TFT
diff --git a/arch/avr32/boards/favr-32/setup.c b/arch/avr32/boards/favr-32/setup.c
index 27bd6fb..7b1f2cd 100644
--- a/arch/avr32/boards/favr-32/setup.c
+++ b/arch/avr32/boards/favr-32/setup.c
@@ -125,7 +125,7 @@ static struct fb_monspecs __initdata favr32_default_monspecs = {
 	.dclkmax		= 28000000,
 };
 
-struct atmel_lcdfb_info __initdata favr32_lcdc_data = {
+struct atmel_lcdfb_pdata __initdata favr32_lcdc_data = {
 	.default_bpp		= 16,
 	.default_dmacon		= ATMEL_LCDC_DMAEN | ATMEL_LCDC_DMA2DEN,
 	.default_lcdcon2	= (ATMEL_LCDC_DISTYPE_TFT
diff --git a/arch/avr32/boards/hammerhead/setup.c b/arch/avr32/boards/hammerhead/setup.c
index 9d1efd1..dc0e317 100644
--- a/arch/avr32/boards/hammerhead/setup.c
+++ b/arch/avr32/boards/hammerhead/setup.c
@@ -77,7 +77,7 @@ static struct fb_monspecs __initdata hammerhead_hda350t_monspecs = {
 	.dclkmax		= 10000000,
 };
 
-struct atmel_lcdfb_info __initdata hammerhead_lcdc_data = {
+struct atmel_lcdfb_pdata __initdata hammerhead_lcdc_data = {
 	.default_bpp		= 24,
 	.default_dmacon		= ATMEL_LCDC_DMAEN | ATMEL_LCDC_DMA2DEN,
 	.default_lcdcon2	= (ATMEL_LCDC_DISTYPE_TFT
diff --git a/arch/avr32/boards/merisc/display.c b/arch/avr32/boards/merisc/display.c
index 85a543c..e7683ee 100644
--- a/arch/avr32/boards/merisc/display.c
+++ b/arch/avr32/boards/merisc/display.c
@@ -45,7 +45,7 @@ static struct fb_monspecs merisc_fb_monspecs = {
 	.dclkmax	= 30000000,
 };
 
-struct atmel_lcdfb_info merisc_lcdc_data = {
+struct atmel_lcdfb_pdata merisc_lcdc_data = {
 	.default_bpp		= 24,
 	.default_dmacon		= ATMEL_LCDC_DMAEN | ATMEL_LCDC_DMA2DEN,
 	.default_lcdcon2	= (ATMEL_LCDC_DISTYPE_TFT
diff --git a/arch/avr32/boards/mimc200/setup.c b/arch/avr32/boards/mimc200/setup.c
index 05358aa..1cb8e9c 100644
--- a/arch/avr32/boards/mimc200/setup.c
+++ b/arch/avr32/boards/mimc200/setup.c
@@ -8,7 +8,7 @@
  * published by the Free Software Foundation.
  */
 
-extern struct atmel_lcdfb_info mimc200_lcdc_data;
+extern struct atmel_lcdfb_pdata mimc200_lcdc_data;
 
 #include <linux/clk.h>
 #include <linux/etherdevice.h>
@@ -71,7 +71,7 @@ static struct fb_monspecs __initdata mimc200_default_monspecs = {
 	.dclkmax		= 25200000,
 };
 
-struct atmel_lcdfb_info __initdata mimc200_lcdc_data = {
+struct atmel_lcdfb_pdata __initdata mimc200_lcdc_data = {
 	.default_bpp		= 16,
 	.default_dmacon		= ATMEL_LCDC_DMAEN | ATMEL_LCDC_DMA2DEN,
 	.default_lcdcon2	= (ATMEL_LCDC_DISTYPE_TFT
diff --git a/arch/avr32/mach-at32ap/at32ap700x.c b/arch/avr32/mach-at32ap/at32ap700x.c
index 7c2f668..0badb05 100644
--- a/arch/avr32/mach-at32ap/at32ap700x.c
+++ b/arch/avr32/mach-at32ap/at32ap700x.c
@@ -1437,7 +1437,7 @@ fail:
  *  LCDC
  * -------------------------------------------------------------------- */
 #if defined(CONFIG_CPU_AT32AP7000) || defined(CONFIG_CPU_AT32AP7002)
-static struct atmel_lcdfb_info atmel_lcdfb0_data;
+static struct atmel_lcdfb_pdata atmel_lcdfb0_data;
 static struct resource atmel_lcdfb0_resource[] = {
 	{
 		.start		= 0xff000000,
@@ -1465,12 +1465,12 @@ static struct clk atmel_lcdfb0_pixclk = {
 };
 
 struct platform_device *__init
-at32_add_device_lcdc(unsigned int id, struct atmel_lcdfb_info *data,
+at32_add_device_lcdc(unsigned int id, struct atmel_lcdfb_pdata *data,
 		     unsigned long fbmem_start, unsigned long fbmem_len,
 		     u64 pin_mask)
 {
 	struct platform_device *pdev;
-	struct atmel_lcdfb_info *info;
+	struct atmel_lcdfb_pdata *info;
 	struct fb_monspecs *monspecs;
 	struct fb_videomode *modedb;
 	unsigned int modedb_size;
@@ -1527,7 +1527,7 @@ at32_add_device_lcdc(unsigned int id, struct atmel_lcdfb_info *data,
 	}
 
 	info = pdev->dev.platform_data;
-	memcpy(info, data, sizeof(struct atmel_lcdfb_info));
+	memcpy(info, data, sizeof(struct atmel_lcdfb_pdata));
 	info->default_monspecs = monspecs;
 
 	pdev->name = "at32ap-lcdfb";
diff --git a/arch/avr32/mach-at32ap/include/mach/board.h b/arch/avr32/mach-at32ap/include/mach/board.h
index d485b03..f1a316d 100644
--- a/arch/avr32/mach-at32ap/include/mach/board.h
+++ b/arch/avr32/mach-at32ap/include/mach/board.h
@@ -44,9 +44,9 @@ struct platform_device *
 at32_add_device_spi(unsigned int id, struct spi_board_info *b, unsigned int n);
 void at32_spi_setup_slaves(unsigned int bus_num, struct spi_board_info *b, unsigned int n);
 
-struct atmel_lcdfb_info;
+struct atmel_lcdfb_pdata;
 struct platform_device *
-at32_add_device_lcdc(unsigned int id, struct atmel_lcdfb_info *data,
+at32_add_device_lcdc(unsigned int id, struct atmel_lcdfb_pdata *data,
 		     unsigned long fbmem_start, unsigned long fbmem_len,
 		     u64 pin_mask);
 
diff --git a/drivers/video/atmel_lcdfb.c b/drivers/video/atmel_lcdfb.c
index c1a2914..98733cd4 100644
--- a/drivers/video/atmel_lcdfb.c
+++ b/drivers/video/atmel_lcdfb.c
@@ -20,12 +20,45 @@
 #include <linux/gfp.h>
 #include <linux/module.h>
 #include <linux/platform_data/atmel.h>
+#include <video/of_display_timing.h>
 
 #include <mach/cpu.h>
 #include <asm/gpio.h>
 
 #include <video/atmel_lcdc.h>
 
+struct atmel_lcdfb_config {
+	bool have_alt_pixclock;
+	bool have_hozval;
+	bool have_intensity_bit;
+};
+
+ /* LCD Controller info data structure, stored in device platform_data */
+struct atmel_lcdfb_info {
+	spinlock_t		lock;
+	struct fb_info		*info;
+	void __iomem		*mmio;
+	int			irq_base;
+	struct work_struct	task;
+
+	unsigned int		smem_len;
+	struct platform_device	*pdev;
+	struct clk		*bus_clk;
+	struct clk		*lcdc_clk;
+
+	struct backlight_device	*backlight;
+	u8			bl_power;
+	bool			lcdcon_pol_negative;
+	u8			saved_lcdcon;
+
+	u32			pseudo_palette[16];
+	bool			have_intensity_bit;
+
+	struct atmel_lcdfb_pdata pdata;
+
+	struct atmel_lcdfb_config *config;
+};
+
 #define lcdc_readl(sinfo, reg)		__raw_readl((sinfo)->mmio+(reg))
 #define lcdc_writel(sinfo, reg, val)	__raw_writel((val), (sinfo)->mmio+(reg))
 
@@ -34,12 +67,6 @@
 #define ATMEL_LCDC_DMA_BURST_LEN	8	/* words */
 #define ATMEL_LCDC_FIFO_SIZE		512	/* words */
 
-struct atmel_lcdfb_config {
-	bool have_alt_pixclock;
-	bool have_hozval;
-	bool have_intensity_bit;
-};
-
 static struct atmel_lcdfb_config at91sam9261_config = {
 	.have_hozval		= true,
 	.have_intensity_bit	= true,
@@ -242,6 +269,8 @@ static void exit_backlight(struct atmel_lcdfb_info *sinfo)
 
 static void init_contrast(struct atmel_lcdfb_info *sinfo)
 {
+	struct atmel_lcdfb_pdata *pdata = &sinfo->pdata;
+
 	/* contrast pwm can be 'inverted' */
 	if (sinfo->lcdcon_pol_negative)
 			contrast_ctr &= ~(ATMEL_LCDC_POL_POSITIVE);
@@ -250,7 +279,7 @@ static void init_contrast(struct atmel_lcdfb_info *sinfo)
 	lcdc_writel(sinfo, ATMEL_LCDC_CONTRAST_CTR, contrast_ctr);
 	lcdc_writel(sinfo, ATMEL_LCDC_CONTRAST_VAL, ATMEL_LCDC_CVAL_DEFAULT);
 
-	if (sinfo->lcdcon_is_backlight)
+	if (pdata->lcdcon_is_backlight)
 		init_backlight(sinfo);
 }
 
@@ -293,9 +322,11 @@ static unsigned long compute_hozval(struct atmel_lcdfb_info *sinfo,
 
 static void atmel_lcdfb_stop_nowait(struct atmel_lcdfb_info *sinfo)
 {
+	struct atmel_lcdfb_pdata *pdata = &sinfo->pdata;
+
 	/* Turn off the LCD controller and the DMA controller */
 	lcdc_writel(sinfo, ATMEL_LCDC_PWRCON,
-			sinfo->guard_time << ATMEL_LCDC_GUARDT_OFFSET);
+			pdata->guard_time << ATMEL_LCDC_GUARDT_OFFSET);
 
 	/* Wait for the LCDC core to become idle */
 	while (lcdc_readl(sinfo, ATMEL_LCDC_PWRCON) & ATMEL_LCDC_BUSY)
@@ -315,9 +346,11 @@ static void atmel_lcdfb_stop(struct atmel_lcdfb_info *sinfo)
 
 static void atmel_lcdfb_start(struct atmel_lcdfb_info *sinfo)
 {
-	lcdc_writel(sinfo, ATMEL_LCDC_DMACON, sinfo->default_dmacon);
+	struct atmel_lcdfb_pdata *pdata = &sinfo->pdata;
+
+	lcdc_writel(sinfo, ATMEL_LCDC_DMACON, pdata->default_dmacon);
 	lcdc_writel(sinfo, ATMEL_LCDC_PWRCON,
-		(sinfo->guard_time << ATMEL_LCDC_GUARDT_OFFSET)
+		(pdata->guard_time << ATMEL_LCDC_GUARDT_OFFSET)
 		| ATMEL_LCDC_PWR);
 }
 
@@ -418,6 +451,7 @@ static int atmel_lcdfb_check_var(struct fb_var_screeninfo *var,
 {
 	struct device *dev = info->device;
 	struct atmel_lcdfb_info *sinfo = info->par;
+	struct atmel_lcdfb_pdata *pdata = &sinfo->pdata;
 	unsigned long clk_value_khz;
 
 	clk_value_khz = clk_get_rate(sinfo->lcdc_clk) / 1000;
@@ -501,7 +535,7 @@ static int atmel_lcdfb_check_var(struct fb_var_screeninfo *var,
 		else
 			var->green.length = 6;
 
-		if (sinfo->lcd_wiring_mode == ATMEL_LCDC_WIRING_RGB) {
+		if (pdata->lcd_wiring_mode == ATMEL_LCDC_WIRING_RGB) {
 			/* RGB:5X5 mode */
 			var->red.offset = var->green.length + 5;
 			var->blue.offset = 0;
@@ -518,7 +552,7 @@ static int atmel_lcdfb_check_var(struct fb_var_screeninfo *var,
 		var->transp.length = 8;
 		/* fall through */
 	case 24:
-		if (sinfo->lcd_wiring_mode == ATMEL_LCDC_WIRING_RGB) {
+		if (pdata->lcd_wiring_mode == ATMEL_LCDC_WIRING_RGB) {
 			/* RGB:888 mode */
 			var->red.offset = 16;
 			var->blue.offset = 0;
@@ -567,6 +601,7 @@ static void atmel_lcdfb_reset(struct atmel_lcdfb_info *sinfo)
 static int atmel_lcdfb_set_par(struct fb_info *info)
 {
 	struct atmel_lcdfb_info *sinfo = info->par;
+	struct atmel_lcdfb_pdata *pdata = &sinfo->pdata;
 	unsigned long hozval_linesz;
 	unsigned long value;
 	unsigned long clk_value_khz;
@@ -628,7 +663,7 @@ static int atmel_lcdfb_set_par(struct fb_info *info)
 
 
 	/* Initialize control register 2 */
-	value = sinfo->default_lcdcon2;
+	value = pdata->default_lcdcon2;
 
 	if (!(info->var.sync & FB_SYNC_HOR_HIGH_ACT))
 		value |= ATMEL_LCDC_INVLINE_INVERTED;
@@ -732,6 +767,7 @@ static int atmel_lcdfb_setcolreg(unsigned int regno, unsigned int red,
 			     unsigned int transp, struct fb_info *info)
 {
 	struct atmel_lcdfb_info *sinfo = info->par;
+	struct atmel_lcdfb_pdata *pdata = &sinfo->pdata;
 	unsigned int val;
 	u32 *pal;
 	int ret = 1;
@@ -768,8 +804,7 @@ static int atmel_lcdfb_setcolreg(unsigned int regno, unsigned int red,
 				 */
 			} else {
 				/* new style BGR:565 / RGB:565 */
-				if (sinfo->lcd_wiring_mode ==
-				    ATMEL_LCDC_WIRING_RGB) {
+				if (pdata->lcd_wiring_mode == ATMEL_LCDC_WIRING_RGB) {
 					val  = ((blue >> 11) & 0x001f);
 					val |= ((red  >>  0) & 0xf800);
 				} else {
@@ -909,7 +944,7 @@ static int __init atmel_lcdfb_probe(struct platform_device *pdev)
 	struct device *dev = &pdev->dev;
 	struct fb_info *info;
 	struct atmel_lcdfb_info *sinfo;
-	struct atmel_lcdfb_info *pdata_sinfo;
+	struct atmel_lcdfb_pdata *pdata;
 	struct fb_videomode fbmode;
 	struct resource *regs = NULL;
 	struct resource *map = NULL;
@@ -927,17 +962,8 @@ static int __init atmel_lcdfb_probe(struct platform_device *pdev)
 	sinfo = info->par;
 
 	if (dev->platform_data) {
-		pdata_sinfo = (struct atmel_lcdfb_info *)dev->platform_data;
-		sinfo->default_bpp = pdata_sinfo->default_bpp;
-		sinfo->default_dmacon = pdata_sinfo->default_dmacon;
-		sinfo->default_lcdcon2 = pdata_sinfo->default_lcdcon2;
-		sinfo->default_monspecs = pdata_sinfo->default_monspecs;
-		sinfo->atmel_lcdfb_power_control = pdata_sinfo->atmel_lcdfb_power_control;
-		sinfo->guard_time = pdata_sinfo->guard_time;
-		sinfo->smem_len = pdata_sinfo->smem_len;
-		sinfo->lcdcon_is_backlight = pdata_sinfo->lcdcon_is_backlight;
-		sinfo->lcdcon_pol_negative = pdata_sinfo->lcdcon_pol_negative;
-		sinfo->lcd_wiring_mode = pdata_sinfo->lcd_wiring_mode;
+		pdata = (struct atmel_lcdfb_pdata *)dev->platform_data;
+		sinfo->pdata = *pdata;
 	} else {
 		dev_err(dev, "cannot get default configuration\n");
 		goto free_info;
@@ -953,7 +979,7 @@ static int __init atmel_lcdfb_probe(struct platform_device *pdev)
 	info->pseudo_palette = sinfo->pseudo_palette;
 	info->fbops = &atmel_lcdfb_ops;
 
-	memcpy(&info->monspecs, sinfo->default_monspecs, sizeof(info->monspecs));
+	memcpy(&info->monspecs, pdata->default_monspecs, sizeof(info->monspecs));
 	info->fix = atmel_lcdfb_fix;
 
 	/* Enable LCDC Clocks */
@@ -971,7 +997,7 @@ static int __init atmel_lcdfb_probe(struct platform_device *pdev)
 
 	ret = fb_find_mode(&info->var, info, NULL, info->monspecs.modedb,
 			info->monspecs.modedb_len, info->monspecs.modedb,
-			sinfo->default_bpp);
+			pdata->default_bpp);
 	if (!ret) {
 		dev_err(dev, "no suitable video mode found\n");
 		goto stop_clk;
@@ -1088,8 +1114,8 @@ static int __init atmel_lcdfb_probe(struct platform_device *pdev)
 	fb_add_videomode(&fbmode, &info->modelist);
 
 	/* Power up the LCDC screen */
-	if (sinfo->atmel_lcdfb_power_control)
-		sinfo->atmel_lcdfb_power_control(1);
+	if (pdata->atmel_lcdfb_power_control)
+		pdata->atmel_lcdfb_power_control(1);
 
 	dev_info(dev, "fb%d: Atmel LCDC at 0x%08lx (mapped at %p), irq %d\n",
 		       info->node, info->fix.mmio_start, sinfo->mmio, sinfo->irq_base);
@@ -1134,15 +1160,17 @@ static int __exit atmel_lcdfb_remove(struct platform_device *pdev)
 	struct device *dev = &pdev->dev;
 	struct fb_info *info = dev_get_drvdata(dev);
 	struct atmel_lcdfb_info *sinfo;
+	struct atmel_lcdfb_pdata *pdata;
 
 	if (!info || !info->par)
 		return 0;
 	sinfo = info->par;
+	pdata = &sinfo->pdata;
 
 	cancel_work_sync(&sinfo->task);
 	exit_backlight(sinfo);
-	if (sinfo->atmel_lcdfb_power_control)
-		sinfo->atmel_lcdfb_power_control(0);
+	if (pdata->atmel_lcdfb_power_control)
+		pdata->atmel_lcdfb_power_control(0);
 	unregister_framebuffer(info);
 	atmel_lcdfb_stop_clock(sinfo);
 	clk_put(sinfo->lcdc_clk);
@@ -1170,6 +1198,7 @@ static int atmel_lcdfb_suspend(struct platform_device *pdev, pm_message_t mesg)
 {
 	struct fb_info *info = platform_get_drvdata(pdev);
 	struct atmel_lcdfb_info *sinfo = info->par;
+	struct atmel_lcdfb_pdata *pdata = &sinfo->pdata;
 
 	/*
 	 * We don't want to handle interrupts while the clock is
@@ -1179,8 +1208,8 @@ static int atmel_lcdfb_suspend(struct platform_device *pdev, pm_message_t mesg)
 
 	sinfo->saved_lcdcon = lcdc_readl(sinfo, ATMEL_LCDC_CONTRAST_CTR);
 	lcdc_writel(sinfo, ATMEL_LCDC_CONTRAST_CTR, 0);
-	if (sinfo->atmel_lcdfb_power_control)
-		sinfo->atmel_lcdfb_power_control(0);
+	if (pdata->atmel_lcdfb_power_control)
+		pdata->atmel_lcdfb_power_control(0);
 
 	atmel_lcdfb_stop(sinfo);
 	atmel_lcdfb_stop_clock(sinfo);
@@ -1192,11 +1221,12 @@ static int atmel_lcdfb_resume(struct platform_device *pdev)
 {
 	struct fb_info *info = platform_get_drvdata(pdev);
 	struct atmel_lcdfb_info *sinfo = info->par;
+	struct atmel_lcdfb_pdata *pdata = &sinfo->pdata;
 
 	atmel_lcdfb_start_clock(sinfo);
 	atmel_lcdfb_start(sinfo);
-	if (sinfo->atmel_lcdfb_power_control)
-		sinfo->atmel_lcdfb_power_control(1);
+	if (pdata->atmel_lcdfb_power_control)
+		pdata->atmel_lcdfb_power_control(1);
 	lcdc_writel(sinfo, ATMEL_LCDC_CONTRAST_CTR, sinfo->saved_lcdcon);
 
 	/* Enable FIFO & DMA errors */
diff --git a/include/video/atmel_lcdc.h b/include/video/atmel_lcdc.h
index 0f5a2fc..2eb601c 100644
--- a/include/video/atmel_lcdc.h
+++ b/include/video/atmel_lcdc.h
@@ -31,39 +31,17 @@
 #define ATMEL_LCDC_WIRING_BGR	0
 #define ATMEL_LCDC_WIRING_RGB	1
 
-struct atmel_lcdfb_config;
 
  /* LCD Controller info data structure, stored in device platform_data */
-struct atmel_lcdfb_info {
-	spinlock_t		lock;
-	struct fb_info		*info;
-	void __iomem		*mmio;
-	int			irq_base;
-	struct work_struct	task;
-
+struct atmel_lcdfb_pdata {
 	unsigned int		guard_time;
-	unsigned int 		smem_len;
-	struct platform_device	*pdev;
-	struct clk		*bus_clk;
-	struct clk		*lcdc_clk;
-
-#ifdef CONFIG_BACKLIGHT_ATMEL_LCDC
-	struct backlight_device	*backlight;
-	u8			bl_power;
-#endif
 	bool			lcdcon_is_backlight;
-	bool			lcdcon_pol_negative;
-	u8			saved_lcdcon;
-
 	u8			default_bpp;
 	u8			lcd_wiring_mode;
 	unsigned int		default_lcdcon2;
 	unsigned int		default_dmacon;
 	void (*atmel_lcdfb_power_control)(int on);
 	struct fb_monspecs	*default_monspecs;
-	u32			pseudo_palette[16];
-
-	struct atmel_lcdfb_config *config;
 };
 
 #define ATMEL_LCDC_DMABADDR1	0x00
-- 
1.7.10.4



From plagnioj at jcrosoft.com  Thu Apr 11 11:00:21 2013
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Thu, 11 Apr 2013 17:00:21 +0200
Subject: [PATCH 7/8] ARM: at91: at9sam9m10g45ek: add dt lcd support
In-Reply-To: <1365692422-9565-1-git-send-email-plagnioj@jcrosoft.com>
References: <20130411145741.GB25242@game.jcrosoft.org>
 <1365692422-9565-1-git-send-email-plagnioj@jcrosoft.com>
Message-ID: <1365692422-9565-7-git-send-email-plagnioj@jcrosoft.com>

Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
Cc: Nicolas Ferre <nicolas.ferre at atmel.com>
---
 arch/arm/boot/dts/at91sam9m10g45ek.dts |   29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)

diff --git a/arch/arm/boot/dts/at91sam9m10g45ek.dts b/arch/arm/boot/dts/at91sam9m10g45ek.dts
index 20c3191..79dc034 100644
--- a/arch/arm/boot/dts/at91sam9m10g45ek.dts
+++ b/arch/arm/boot/dts/at91sam9m10g45ek.dts
@@ -104,6 +104,35 @@
 			};
 		};
 
+		fb0: fb at 0x00500000 {
+			display = <&display0>;
+			status = "okay";
+
+			display0: display {
+				bits-per-pixel = <32>;
+				atmel,lcdcon-backlight;
+				atmel,dmacon = <0x1>;
+				atmel,lcdcon2 = <0x80008002>;
+				atmel,guard-time = <9>;
+				atmel,lcd-wiring-mode = "RGB";
+
+				display-timings {
+					native-mode = <&timing0>;
+					timing0: timing0 {
+						clock-frequency = <9000000>;
+						hactive = <480>;
+						vactive = <272>;
+						hback-porch = <1>;
+						hfront-porch = <1>;
+						vback-porch = <40>;
+						vfront-porch = <1>;
+						hsync-len = <45>;
+						vsync-len = <1>;
+					};
+				};
+			};
+		};
+
 		nand0: nand at 40000000 {
 			nand-bus-width = <8>;
 			nand-ecc-mode = "soft";
-- 
1.7.10.4



From plagnioj at jcrosoft.com  Thu Apr 11 11:00:20 2013
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Thu, 11 Apr 2013 17:00:20 +0200
Subject: [PATCH 6/8] ARM: at91: sam9263: add fb dt support
In-Reply-To: <1365692422-9565-1-git-send-email-plagnioj@jcrosoft.com>
References: <20130411145741.GB25242@game.jcrosoft.org>
 <1365692422-9565-1-git-send-email-plagnioj@jcrosoft.com>
Message-ID: <1365692422-9565-6-git-send-email-plagnioj@jcrosoft.com>

Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
Cc: Nicolas Ferre <nicolas.ferre at atmel.com>
---
 arch/arm/boot/dts/at91sam9263.dtsi |   39 ++++++++++++++++++++++++++++++++++++
 1 file changed, 39 insertions(+)

diff --git a/arch/arm/boot/dts/at91sam9263.dtsi b/arch/arm/boot/dts/at91sam9263.dtsi
index 271d4de..3d0effa 100644
--- a/arch/arm/boot/dts/at91sam9263.dtsi
+++ b/arch/arm/boot/dts/at91sam9263.dtsi
@@ -303,6 +303,34 @@
 					};
 				};
 
+				fb {
+					pinctrl_fb: fb-0 {
+						atmel,pins =
+							<2 1 0x1 0x0	/* PC1 periph A */
+							 2 2 0x1 0x0	/* PC2 periph A */
+							 2 3 0x1 0x0	/* PC3 periph A */
+							 1 9 0x2 0x0	/* PB9 periph B */
+							 2 6 0x1 0x0	/* PC6 periph A */
+							 2 7 0x1 0x0	/* PC7 periph A */
+							 2 8 0x1 0x0	/* PC8 periph A */
+							 2 9 0x1 0x0	/* PC9 periph A */
+							 2 10 0x1 0x0	/* PC10 periph A */
+							 2 11 0x1 0x0	/* PC11 periph A */
+							 2 14 0x1 0x0	/* PC14 periph A */
+							 2 15 0x1 0x0	/* PC15 periph A */
+							 2 16 0x1 0x0	/* PC16 periph A */
+							 2 12 0x2 0x0	/* PC12 periph B */
+							 2 18 0x1 0x0	/* PC18 periph A */
+							 2 19 0x1 0x0	/* PC19 periph A */
+							 2 22 0x1 0x0	/* PC22 periph A */
+							 2 23 0x1 0x0	/* PC23 periph A */
+							 2 24 0x1 0x0	/* PC24 periph A */
+							 2 17 0x2 0x0	/* PC17 periph B */
+							 2 26 0x1 0x0	/* PC26 periph A */
+							 2 27 0x1 0x0>;	/* PC27 periph A */
+					};
+				};
+
 				pioA: gpio at fffff200 {
 					compatible = "atmel,at91rm9200-gpio";
 					reg = <0xfffff200 0x200>;
@@ -464,6 +492,17 @@
 			};
 		};
 
+		fb0: fb at 0x00500000 {
+			compatible = "atmel,at91sam9263-lcdc";
+			reg = <0x00700000 0x1000>;
+			interrupts = <26 3 0>;
+			pinctrl-names = "default";
+			pinctrl-0 = <&pinctrl_fb>;
+			status = "disabled";
+			#address-cells = <1>;
+			#size-cells = <1>;
+		};
+
 		nand0: nand at 40000000 {
 			compatible = "atmel,at91rm9200-nand";
 			#address-cells = <1>;
-- 
1.7.10.4



From plagnioj at jcrosoft.com  Thu Apr 11 11:00:22 2013
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Thu, 11 Apr 2013 17:00:22 +0200
Subject: [PATCH 8/8] ARM: at91: sam9263ek: add dt lcd support
In-Reply-To: <1365692422-9565-1-git-send-email-plagnioj@jcrosoft.com>
References: <20130411145741.GB25242@game.jcrosoft.org>
 <1365692422-9565-1-git-send-email-plagnioj@jcrosoft.com>
Message-ID: <1365692422-9565-8-git-send-email-plagnioj@jcrosoft.com>

Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
Cc: Nicolas Ferre <nicolas.ferre at atmel.com>
---
 arch/arm/boot/dts/at91sam9263ek.dts |   30 ++++++++++++++++++++++++++++++
 1 file changed, 30 insertions(+)

diff --git a/arch/arm/boot/dts/at91sam9263ek.dts b/arch/arm/boot/dts/at91sam9263ek.dts
index 1eb0872..d471b49 100644
--- a/arch/arm/boot/dts/at91sam9263ek.dts
+++ b/arch/arm/boot/dts/at91sam9263ek.dts
@@ -81,6 +81,36 @@
 			};
 		};
 
+		fb0: fb at 0x00500000 {
+			display = <&display0>;
+			status = "okay";
+
+			display0: display {
+				bits-per-pixel = <16>;
+				atmel,lcdcon-backlight;
+				atmel,dmacon = <0x1>;
+				atmel,lcdcon2 = <0x80008002>;
+				atmel,guard-time = <1>;
+
+				display-timings {
+					native-mode = <&timing0>;
+					timing0: timing0 {
+						clock-frequency = <4965000>;
+						hactive = <240>;
+						vactive = <320>;
+						hback-porch = <1>;
+						hfront-porch = <33>;
+						vback-porch = <1>;
+						vfront-porch = <0>;
+						hsync-len = <5>;
+						vsync-len = <1>;
+						hsync-active = <1>;
+						vsync-active = <1>;
+					};
+				};
+			};
+		};
+
 		nand0: nand at 40000000 {
 			nand-bus-width = <8>;
 			nand-ecc-mode = "soft";
-- 
1.7.10.4



From plagnioj at jcrosoft.com  Thu Apr 11 11:00:18 2013
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Thu, 11 Apr 2013 17:00:18 +0200
Subject: [PATCH 4/8] video: atmel_lcdfb: add device tree suport
In-Reply-To: <1365692422-9565-1-git-send-email-plagnioj@jcrosoft.com>
References: <20130411145741.GB25242@game.jcrosoft.org>
 <1365692422-9565-1-git-send-email-plagnioj@jcrosoft.com>
Message-ID: <1365692422-9565-4-git-send-email-plagnioj@jcrosoft.com>

get display timings from device tree
Use videomode helpers to get display timings and configurations from
device tree

Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
Cc: linux-fbdev at vger.kernel.org
Cc: Nicolas Ferre <nicolas.ferre at atmel.com>
Cc: Andrew Morton <akpm at linux-foundation.org>
---
 .../devicetree/bindings/video/atmel,lcdc.txt       |   75 ++++++
 drivers/video/Kconfig                              |    2 +
 drivers/video/atmel_lcdfb.c                        |  244 +++++++++++++++++---
 3 files changed, 289 insertions(+), 32 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/video/atmel,lcdc.txt

diff --git a/Documentation/devicetree/bindings/video/atmel,lcdc.txt b/Documentation/devicetree/bindings/video/atmel,lcdc.txt
new file mode 100644
index 0000000..1ec175e
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/atmel,lcdc.txt
@@ -0,0 +1,75 @@
+Atmel LCDC Framebuffer
+-----------------------------------------------------
+
+Required properties:
+- compatible :
+	"atmel,at91sam9261-lcdc" , 
+	"atmel,at91sam9263-lcdc" ,
+	"atmel,at91sam9g10-lcdc" ,
+	"atmel,at91sam9g45-lcdc" ,
+	"atmel,at91sam9g45es-lcdc" ,
+	"atmel,at91sam9rl-lcdc" ,
+	"atmel,at32ap-lcdc"
+- reg : Should contain 1 register ranges(address and length)
+- interrupts : framebuffer controller interrupt
+- display: a phandle pointing to the display node
+
+Required nodes:
+- display: a display node is required to initialize the lcd panel
+	This should be in the board dts.
+- default-mode: a videomode within the display with timing parameters
+	as specified below.
+
+Example:
+
+	fb0: fb at 0x00500000 {
+		compatible = "atmel,at91sam9g45-lcdc";
+		reg = <0x00500000 0x1000>;
+		interrupts = <23 3 0>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_fb>;
+		display = <&display0>;
+		status = "okay";
+		#address-cells = <1>;
+		#size-cells = <1>;
+
+	};
+
+Atmel LCDC Display
+-----------------------------------------------------
+Required properties (as per of_videomode_helper):
+
+ - atmel,dmacon: dma controler configuration
+ - atmel,lcdcon2: lcd controler configuration
+ - atmel,guard-time: lcd guard time (Delay in frame periods)
+ - bits-per-pixel: lcd panel bit-depth.
+
+Optional properties (as per of_videomode_helper):
+ - atmel,lcdcon-backlight: enable backlight
+ - atmel,lcd-wiring-mode: lcd wiring mode "RGB" or "BRG"
+ - atmel,power-control-gpio: gpio to power on or off the LCD (as many as needed)
+
+Example:
+	display0: display {
+		bits-per-pixel = <32>;
+		atmel,lcdcon-backlight;
+		atmel,dmacon = <0x1>;
+		atmel,lcdcon2 = <0x80008002>;
+		atmel,guard-time = <9>;
+		atmel,lcd-wiring-mode = <1>;
+
+		display-timings {
+			native-mode = <&timing0>;
+			timing0: timing0 {
+				clock-frequency = <9000000>;
+				hactive = <480>;
+				vactive = <272>;
+				hback-porch = <1>;
+				hfront-porch = <1>;
+				vback-porch = <40>;
+				vfront-porch = <1>;
+				hsync-len = <45>;
+				vsync-len = <1>;
+			};
+		};
+	};
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 4c1546f..0687482 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -1018,6 +1018,8 @@ config FB_ATMEL
 	select FB_CFB_FILLRECT
 	select FB_CFB_COPYAREA
 	select FB_CFB_IMAGEBLIT
+	select FB_MODE_HELPERS
+	select OF_VIDEOMODE
 	help
 	  This enables support for the AT91/AT32 LCD Controller.
 
diff --git a/drivers/video/atmel_lcdfb.c b/drivers/video/atmel_lcdfb.c
index f67e226..4a31570 100644
--- a/drivers/video/atmel_lcdfb.c
+++ b/drivers/video/atmel_lcdfb.c
@@ -20,7 +20,11 @@
 #include <linux/gfp.h>
 #include <linux/module.h>
 #include <linux/platform_data/atmel.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/of_gpio.h>
 #include <video/of_display_timing.h>
+#include <video/videomode.h>
 
 #include <mach/cpu.h>
 #include <asm/gpio.h>
@@ -59,6 +63,13 @@ struct atmel_lcdfb_info {
 	struct atmel_lcdfb_config *config;
 };
 
+struct atmel_lcdfb_power_ctrl_gpio {
+	int gpio;
+	int active_low;
+
+	struct list_head list;
+};
+
 #define lcdc_readl(sinfo, reg)		__raw_readl((sinfo)->mmio+(reg))
 #define lcdc_writel(sinfo, reg, val)	__raw_writel((val), (sinfo)->mmio+(reg))
 
@@ -945,16 +956,187 @@ static void atmel_lcdfb_stop_clock(struct atmel_lcdfb_info *sinfo)
 	clk_disable(sinfo->lcdc_clk);
 }
 
+#ifdef CONFIG_OF
+static const struct of_device_id atmel_lcdfb_dt_ids[] = {
+	{ .compatible = "atmel,at91sam9261-lcdc" , .data = &at91sam9261_config, },
+	{ .compatible = "atmel,at91sam9263-lcdc" , .data = &at91sam9263_config, },
+	{ .compatible = "atmel,at91sam9g10-lcdc" , .data = &at91sam9g10_config, },
+	{ .compatible = "atmel,at91sam9g45-lcdc" , .data = &at91sam9g45_config, },
+	{ .compatible = "atmel,at91sam9g45es-lcdc" , .data = &at91sam9g45es_config, },
+	{ .compatible = "atmel,at91sam9rl-lcdc" , .data = &at91sam9rl_config, },
+	{ .compatible = "atmel,at32ap-lcdc" , .data = &at32ap_config, },
+	{ /* sentinel */ }
+};
+
+MODULE_DEVICE_TABLE(of, atmel_lcdfb_dt_ids);
+
+static const char *atmel_lcdfb_wiring_modes[] = {
+	[ATMEL_LCDC_WIRING_BGR]	= "BRG",
+	[ATMEL_LCDC_WIRING_RGB]	= "RGB",
+};
+
+const int atmel_lcdfb_get_of_wiring_modes(struct device_node *np)
+{
+	const char *mode;
+	int err, i;
+
+	err = of_property_read_string(np, "atmel,lcd-wiring-mode", &mode);
+	if (err < 0)
+		return ATMEL_LCDC_WIRING_BGR;
+
+	for (i = 0; i < ARRAY_SIZE(atmel_lcdfb_wiring_modes); i++)
+		if (!strcasecmp(mode, atmel_lcdfb_wiring_modes[i]))
+			return i;
+
+	return -ENODEV;
+}
+
+static void atmel_lcdfb_power_control_gpio(struct atmel_lcdfb_pdata *pdata, int on)
+{
+	struct atmel_lcdfb_power_ctrl_gpio *og;
+
+	list_for_each_entry(og, &pdata->pwr_gpios, list)
+		gpio_set_value(og->gpio, on);
+}
+
+static int atmel_lcdfb_of_init(struct atmel_lcdfb_info *sinfo)
+{
+	struct fb_info *info = sinfo->info;
+	struct atmel_lcdfb_pdata *pdata = &sinfo->pdata;
+	struct fb_var_screeninfo *var = &info->var;
+	struct device *dev = &sinfo->pdev->dev;
+	struct device_node *np =dev->of_node;
+	struct device_node *display_np;
+	struct device_node *timings_np;
+	struct display_timings *timings;
+	enum of_gpio_flags flags;
+	struct atmel_lcdfb_power_ctrl_gpio *og;
+	bool is_gpio_power = false;
+	int ret = -ENOENT;
+	int i, gpio;
+
+	sinfo->config = (struct atmel_lcdfb_config*)
+		of_match_device(atmel_lcdfb_dt_ids, dev)->data;
+
+	display_np = of_parse_phandle(np, "display", 0);
+	if (!display_np) {
+		dev_err(dev, "failed to find display phandle\n");
+		return -ENOENT;
+	}
+
+	ret = of_property_read_u32(display_np, "bits-per-pixel", &var->bits_per_pixel);
+	if (ret < 0) {
+		dev_err(dev, "failed to get property bits-per-pixel\n");
+		goto put_display_node;
+	}
+
+	ret = of_property_read_u32(display_np, "atmel,guard-time", &pdata->guard_time);
+	if (ret < 0) {
+		dev_err(dev, "failed to get property atmel,guard-time\n");
+		goto put_display_node;
+	}
+
+	ret = of_property_read_u32(display_np, "atmel,lcdcon2", &pdata->default_lcdcon2);
+	if (ret < 0) {
+		dev_err(dev, "failed to get property atmel,lcdcon2\n");
+		goto put_display_node;
+	}
+
+	ret = of_property_read_u32(display_np, "atmel,dmacon", &pdata->default_dmacon);
+	if (ret < 0) {
+		dev_err(dev, "failed to get property bits-per-pixel\n");
+		goto put_display_node;
+	}
+
+	ret = -ENOMEM;
+	for (i = 0; i < of_gpio_named_count(display_np, "atmel,power-control-gpio"); i++) {
+		gpio = of_get_named_gpio_flags(display_np, "atmel,power-control-gpio",
+					       i, &flags);
+		if (gpio < 0)
+			continue;
+
+		og = devm_kzalloc(dev, sizeof(*og), GFP_KERNEL);
+		if (!og)
+			goto put_display_node;
+
+		og->gpio = gpio;
+		og->active_low = flags & OF_GPIO_ACTIVE_LOW;
+		is_gpio_power = true;
+		ret = devm_gpio_request(dev, gpio, "lcd-power-control-gpio");
+		if (ret) {
+			dev_err(dev, "request gpio %d failed\n", gpio);
+			goto put_display_node;
+		}
+
+		ret = gpio_direction_output(gpio, og->active_low);
+		if (ret) {
+			dev_err(dev, "set direction output gpio %d failed\n", gpio);
+			goto put_display_node;
+		}
+	}
+
+	if (is_gpio_power)
+		pdata->atmel_lcdfb_power_control = atmel_lcdfb_power_control_gpio;
+
+	ret = atmel_lcdfb_get_of_wiring_modes(display_np);
+	if (ret < 0) {
+		dev_err(dev, "invalid atmel,lcd-wiring-mode\n");
+		goto put_display_node;
+	}
+	pdata->lcd_wiring_mode = ret;
+
+	pdata->lcdcon_is_backlight = of_property_read_bool(display_np, "atmel,lcdcon-backlight");
+
+	timings = of_get_display_timings(display_np);
+	if (!timings) {
+		dev_err(dev, "failed to get display timings\n");
+		goto put_display_node;
+	}
+
+	timings_np = of_find_node_by_name(display_np, "display-timings");
+	if (!timings_np) {
+		dev_err(dev, "failed to find display-timings node\n");
+		goto put_display_node;
+	}
+
+	for (i = 0; i < of_get_child_count(timings_np); i++) {
+		struct videomode vm;
+		struct fb_videomode fb_vm;
+
+		ret = videomode_from_timing(timings, &vm, i);
+		if (ret < 0)
+			goto put_timings_node;
+		ret = fb_videomode_from_videomode(&vm, &fb_vm);
+		if (ret < 0)
+			goto put_timings_node;
+
+		fb_add_videomode(&fb_vm, &info->modelist);
+	}
+
+	return 0;
+
+put_timings_node:
+	of_node_put(timings_np);
+put_display_node:
+	of_node_put(display_np);
+	return ret;
+}
+#else
+static int atmel_lcdfb_of_init(struct atmel_lcdfb_info *sinfo)
+{
+	return 0;
+}
+#endif
 
 static int __init atmel_lcdfb_probe(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
 	struct fb_info *info;
 	struct atmel_lcdfb_info *sinfo;
-	struct atmel_lcdfb_pdata *pdata;
-	struct fb_videomode fbmode;
+	struct atmel_lcdfb_pdata *pdata = NULL;
 	struct resource *regs = NULL;
 	struct resource *map = NULL;
+	struct fb_modelist *modelist;
 	int ret;
 
 	dev_dbg(dev, "%s BEGIN\n", __func__);
@@ -967,17 +1149,35 @@ static int __init atmel_lcdfb_probe(struct platform_device *pdev)
 	}
 
 	sinfo = info->par;
+	sinfo->pdev = pdev;
+	sinfo->info = info;
+
+	INIT_LIST_HEAD(&info->modelist);
 
-	if (dev->platform_data) {
-		pdata = (struct atmel_lcdfb_pdata *)dev->platform_data;
+	if (pdev->dev.of_node) {
+		ret = atmel_lcdfb_of_init(sinfo);
+		if (ret)
+			goto free_info;
+	} else if (dev->platform_data) {
+		struct fb_monspecs *monspecs;
+		int i;
+
+		pdata = dev->platform_data;
+		monspecs = pdata->default_monspecs;
 		sinfo->pdata = *pdata;
+
+		for (i = 0; i < monspecs->modedb_len; i++)
+			fb_add_videomode(&monspecs->modedb[i], &info->modelist);
+
+		sinfo->config = atmel_lcdfb_get_config(pdev);
+
+		info->var.bits_per_pixel = pdata->default_bpp ? pdata->default_bpp : 16;
+		memcpy(&info->monspecs, pdata->default_monspecs, sizeof(info->monspecs));
 	} else {
 		dev_err(dev, "cannot get default configuration\n");
 		goto free_info;
 	}
-	sinfo->info = info;
-	sinfo->pdev = pdev;
-	sinfo->config = atmel_lcdfb_get_config(pdev);
+
 	if (!sinfo->config)
 		goto free_info;
 
@@ -986,7 +1186,6 @@ static int __init atmel_lcdfb_probe(struct platform_device *pdev)
 	info->pseudo_palette = sinfo->pseudo_palette;
 	info->fbops = &atmel_lcdfb_ops;
 
-	memcpy(&info->monspecs, pdata->default_monspecs, sizeof(info->monspecs));
 	info->fix = atmel_lcdfb_fix;
 
 	/* Enable LCDC Clocks */
@@ -1002,14 +1201,11 @@ static int __init atmel_lcdfb_probe(struct platform_device *pdev)
 	}
 	atmel_lcdfb_start_clock(sinfo);
 
-	ret = fb_find_mode(&info->var, info, NULL, info->monspecs.modedb,
-			info->monspecs.modedb_len, info->monspecs.modedb,
-			pdata->default_bpp);
-	if (!ret) {
-		dev_err(dev, "no suitable video mode found\n");
-		goto stop_clk;
-	}
+	modelist = list_first_entry(&info->modelist,
+			struct fb_modelist, list);
+	fb_videomode_to_var(&info->var, &modelist->mode);
 
+	atmel_lcdfb_check_var(&info->var, info);
 
 	regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 	if (!regs) {
@@ -1093,18 +1289,6 @@ static int __init atmel_lcdfb_probe(struct platform_device *pdev)
 		goto unregister_irqs;
 	}
 
-	/*
-	 * This makes sure that our colour bitfield
-	 * descriptors are correctly initialised.
-	 */
-	atmel_lcdfb_check_var(&info->var, info);
-
-	ret = fb_set_var(info, &info->var);
-	if (ret) {
-		dev_warn(dev, "unable to set display parameters\n");
-		goto free_cmap;
-	}
-
 	dev_set_drvdata(dev, info);
 
 	/*
@@ -1116,10 +1300,6 @@ static int __init atmel_lcdfb_probe(struct platform_device *pdev)
 		goto reset_drvdata;
 	}
 
-	/* add selected videomode to modelist */
-	fb_var_to_videomode(&fbmode, &info->var);
-	fb_add_videomode(&fbmode, &info->modelist);
-
 	/* Power up the LCDC screen */
 	atmel_lcdfb_power_control(sinfo, 1);
 
@@ -1130,7 +1310,6 @@ static int __init atmel_lcdfb_probe(struct platform_device *pdev)
 
 reset_drvdata:
 	dev_set_drvdata(dev, NULL);
-free_cmap:
 	fb_dealloc_cmap(&info->cmap);
 unregister_irqs:
 	cancel_work_sync(&sinfo->task);
@@ -1249,6 +1428,7 @@ static struct platform_driver atmel_lcdfb_driver = {
 	.driver		= {
 		.name	= "atmel_lcdfb",
 		.owner	= THIS_MODULE,
+		.of_match_table	= of_match_ptr(atmel_lcdfb_dt_ids),
 	},
 };
 
-- 
1.7.10.4



From yinghai at kernel.org  Thu Apr 11 11:10:28 2013
From: yinghai at kernel.org (Yinghai Lu)
Date: Thu, 11 Apr 2013 08:10:28 -0700
Subject: [PATCH 0/2] mm: vmemmap: add vmemmap_verify check for hot-add
 node/memory case
In-Reply-To: <51666930.6090702@cn.fujitsu.com>
References: <1365415000-10389-1-git-send-email-linfeng@cn.fujitsu.com>
 <CAE9FiQVaByGOTjLVthRkEze_ekXm5LAKgKdHzrD+q1iYmjgZFQ@mail.gmail.com>
 <51666930.6090702@cn.fujitsu.com>
Message-ID: <CAE9FiQU-zqFdSz-7yq5EgV1YCzyNH_BY36Ym3tdHVEHHY6cdNg@mail.gmail.com>

On Thu, Apr 11, 2013 at 12:41 AM, Tang Chen <tangchen at cn.fujitsu.com> wrote:
>
> 3. If we add flag to memblock, we can mark different memory. And I remember
>    you mentioned before that we can use memblock to reserve local node data
>    for node-life-cycle data, like vmemmap, pagetable.
>
>    So are you doing the similar work now ?

No, i did not start it yet.

>
>    If not, I think I can merge it into mine, and push a new patch-set with
>    hot-add, hot-remove code modified to support putting vmemmap, pagetable,
>    pgdat, page_cgroup, ..., on local node.

Need to have it separated with moving_zone.

1. rework memblock to keep alive all the way for hotplug usage.
2. put pagetable and vmemap on the local node range with help of memblock.


Thanks

Yinghai


From robherring2 at gmail.com  Thu Apr 11 11:12:19 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Thu, 11 Apr 2013 10:12:19 -0500
Subject: [PATCH v2 12/13] ARM: move sp804 and integrator timers to
 drivers/clocksource
In-Reply-To: <CACRpkda_57wCFTOXv9ijfKycGO7-y6gvJA+3N=mNaMpNKbMHgg@mail.gmail.com>
References: <1364854883-5961-1-git-send-email-robherring2@gmail.com>
 <1364854883-5961-13-git-send-email-robherring2@gmail.com>
 <515A179A.8020800@linaro.org> <515B3637.8090603@gmail.com>
 <515B7AC1.9090403@linaro.org> <5165F476.7010807@gmail.com>
 <CACRpkda_57wCFTOXv9ijfKycGO7-y6gvJA+3N=mNaMpNKbMHgg@mail.gmail.com>
Message-ID: <5166D2D3.2090606@gmail.com>

On 04/11/2013 03:33 AM, Linus Walleij wrote:
> On Thu, Apr 11, 2013 at 1:23 AM, Rob Herring <robherring2 at gmail.com> wrote:
> 
>> I'm waiting until there is some clear direction on how or if to split up
>> clksrc and clkevt drivers. So I will drop this patch for 3.10 unless you
>> are okay with moving it to drivers/clocksource first and sorting out how
>> to split things later.
> 
> No hurries.
> 
> What do you think about my proposal to create drivers/timer
> and move the clocksource drivers in a subdir there?

I had the exact same idea. I not convinced on how many of the drivers
could be split though. So if everything just ends up in drivers/timers
rather than drivers/timers/ subdirectories, we haven't really
accomplished anything.

Rob



From arnd at arndb.de  Thu Apr 11 11:18:12 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 11 Apr 2013 17:18:12 +0200
Subject: [GIT PULL] arm-soc fixes for 3.9-rc6
Message-ID: <201304111718.13017.arnd@arndb.de>

A little later during the week than the last few pull requests, since there
was very little that came in before 3.9-rc6. At least things have calmed
down again here.

	Arnd

The following changes since commit 31880c37c11e28cb81c70757e38392b42e695dc6:

  Linux 3.9-rc6 (2013-04-07 20:49:54 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/arm-soc-fixes

for you to fetch changes up to 71bd98aff05a644a2cfc3ac6ca848a586fa210b9:

  Merge tag 'mvebu_fixes_for_v3.9_round3' of git://git.infradead.org/users/jcooper/linux into fixes (2013-04-11 16:55:29 +0200)

----------------------------------------------------------------

arm-soc: bug fixes for 3.9-rc6

Some important bug fixes that came in over the last 10 days,
mostly mvebu and imx:

- Multiple regressions on i.mx following the conversion of
  the clock code, hopefully the last we are seeing of those.
- a regression in the mvebu irq handling code
- An incorrect register offset in the rewritten s3c24xx irq code.
- Two bugs in setting up the iomega_ix2_200 machine
- Turning on an extra bus clock on imx
- A MAINTAINERS file entry for Roland Stigge

----------------------------------------------------------------
Arnd Bergmann (4):
      Merge tag 'mxs-fixes-3.9-4' of git://git.linaro.org/people/shawnguo/linux-2.6 into fixes
      Merge tag 'imx-fixes-3.9-5' of git://git.linaro.org/people/shawnguo/linux-2.6 into fixes
      Merge tag 'samsung-fixes-for-v3.9' of git://git.kernel.org/.../kgene/linux-samsung into fixes
      Merge tag 'mvebu_fixes_for_v3.9_round3' of git://git.infradead.org/users/jcooper/linux into fixes

Dirk Behme (1):
      ARM i.MX6: Fix ldb_di clock selection

Gregory CLEMENT (1):
      arm: mvebu: Fix the irq map function in SMP mode

Marek Vasut (1):
      ARM: mxs: Slow down the I2C clock speed

Markus Pargmann (2):
      ARM: clk-imx35: Bugfix iomux clock
      ARM: imx35 Bugfix admux clock

Nigel Roberts (2):
      ARM: Kirkwood: Fix typo in the definition of ix2-200 rebuild LED
      Fix GE0/GE1 init on ix2-200 as GE0 has no PHY

Roland Stigge (1):
      MAINTAINERS: Add maintainer for LPC32xx

Shawn Guo (1):
      ARM: imx: provide twd clock lookup from device tree

Sylwester Nawrocki (2):
      ARM: S3C24XX: Correct NR_IRQS definition for s3c2440
      ARM: S3C24XX: Fix interrupt pending register offset of the EINT controller

 MAINTAINERS                                   |  6 ++++++
 arch/arm/boot/dts/imx28-m28evk.dts            |  1 -
 arch/arm/boot/dts/imx28-sps1.dts              |  1 -
 arch/arm/boot/dts/imx6qdl.dtsi                |  1 +
 arch/arm/boot/dts/kirkwood-iomega_ix2_200.dts | 14 +++++++-------
 arch/arm/mach-imx/clk-imx35.c                 |  2 ++
 arch/arm/mach-imx/clk-imx6q.c                 |  3 +--
 arch/arm/mach-kirkwood/board-iomega_ix2_200.c |  7 ++++++-
 arch/arm/mach-mvebu/irq-armada-370-xp.c       | 16 +++++-----------
 arch/arm/mach-s3c24xx/include/mach/irqs.h     |  4 +---
 arch/arm/mach-s3c24xx/irq.c                   |  2 +-
 11 files changed, 30 insertions(+), 27 deletions(-)


From Andrew.Murray at arm.com  Thu Apr 11 11:26:08 2013
From: Andrew.Murray at arm.com (Andrew Murray)
Date: Thu, 11 Apr 2013 16:26:08 +0100
Subject: [PATCH v6 2/3] of/pci: Provide support for parsing PCI DT ranges
 property
In-Reply-To: <1365693969-23907-1-git-send-email-Andrew.Murray@arm.com>
References: <1365693969-23907-1-git-send-email-Andrew.Murray@arm.com>
Message-ID: <1365693969-23907-3-git-send-email-Andrew.Murray@arm.com>

This patch factors out common implementation patterns to reduce overall kernel
code and provide a means for host bridge drivers to directly obtain struct
resources from the DT's ranges property without relying on architecture specific
DT handling. This will make it easier to write archiecture independent host bridge
drivers and mitigate against further duplication of DT parsing code.

This patch can be used in the following way:

	struct of_pci_range_parser parser;
	struct of_pci_range range;

	if (of_pci_range_parser(&parser, np))
		; //no ranges property

	for_each_of_pci_range(&parser, &range) {

		/*
			directly access properties of the address range, e.g.:
			range.pci_space, range.pci_addr, range.cpu_addr,
			range.size, range.flags

			alternatively obtain a struct resource, e.g.:
			struct resource res;
			of_pci_range_to_resource(&range, np, &res);
		*/
	}

Additionally the implementation takes care of adjacent ranges and merges them
into a single range (as was the case with powerpc and microblaze).

Signed-off-by: Andrew Murray <Andrew.Murray at arm.com>
Signed-off-by: Liviu Dudau <Liviu.Dudau at arm.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Reviewed-by: Rob Herring <rob.herring at calxeda.com>
Tested-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 drivers/of/address.c       |   66 ++++++++++++++++++++++++++
 drivers/of/of_pci.c        |  112 ++++++++++++++++----------------------------
 include/linux/of_address.h |   46 ++++++++++++++++++
 3 files changed, 152 insertions(+), 72 deletions(-)

diff --git a/drivers/of/address.c b/drivers/of/address.c
index 04da786..d3c4f2f 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -227,6 +227,72 @@ int of_pci_address_to_resource(struct device_node *dev, int bar,
 	return __of_address_to_resource(dev, addrp, size, flags, NULL, r);
 }
 EXPORT_SYMBOL_GPL(of_pci_address_to_resource);
+
+int of_pci_range_parser(struct of_pci_range_parser *parser,
+			struct device_node *node)
+{
+	const int na = 3, ns = 2;
+	int rlen;
+
+	parser->node = node;
+	parser->pna = of_n_addr_cells(node);
+	parser->np = parser->pna + na + ns;
+
+	parser->range = of_get_property(node, "ranges", &rlen);
+	if (parser->range == NULL)
+		return -ENOENT;
+
+	parser->end = parser->range + rlen / sizeof(__be32);
+
+	return 0;
+}
+
+struct of_pci_range *of_pci_process_ranges(struct of_pci_range_parser *parser,
+						struct of_pci_range *range)
+{
+	const int na = 3, ns = 2;
+
+	if (!range)
+		return NULL;
+
+	if (!parser->range || parser->range + parser->np > parser->end)
+		return NULL;
+
+	range->pci_space = parser->range[0];
+	range->flags = of_bus_pci_get_flags(parser->range);
+	range->pci_addr = of_read_number(parser->range + 1, ns);
+	range->cpu_addr = of_translate_address(parser->node,
+				parser->range + na);
+	range->size = of_read_number(parser->range + parser->pna + na, ns);
+
+	parser->range += parser->np;
+
+	/* Now consume following elements while they are contiguous */
+	while (parser->range + parser->np <= parser->end) {
+		u32 flags, pci_space;
+		u64 pci_addr, cpu_addr, size;
+
+		pci_space = be32_to_cpup(parser->range);
+		flags = of_bus_pci_get_flags(parser->range);
+		pci_addr = of_read_number(parser->range + 1, ns);
+		cpu_addr = of_translate_address(parser->node,
+				parser->range + na);
+		size = of_read_number(parser->range + parser->pna + na, ns);
+
+		if (flags != range->flags)
+			break;
+		if (pci_addr != range->pci_addr + range->size ||
+		    cpu_addr != range->cpu_addr + range->size)
+			break;
+
+		range->size += size;
+		parser->range += parser->np;
+	}
+
+	return range;
+}
+EXPORT_SYMBOL_GPL(of_pci_process_ranges);
+
 #endif /* CONFIG_PCI */
 
 /*
diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
index 1626172..3e428a1 100644
--- a/drivers/of/of_pci.c
+++ b/drivers/of/of_pci.c
@@ -82,67 +82,43 @@ EXPORT_SYMBOL_GPL(of_pci_find_child_device);
 void pci_process_bridge_OF_ranges(struct pci_controller *hose,
 				  struct device_node *dev, int primary)
 {
-	const u32 *ranges;
-	int rlen;
-	int pna = of_n_addr_cells(dev);
-	int np = pna + 5;
 	int memno = 0, isa_hole = -1;
-	u32 pci_space;
-	unsigned long long pci_addr, cpu_addr, pci_next, cpu_next, size;
 	unsigned long long isa_mb = 0;
 	struct resource *res;
+	struct of_pci_range range;
+	struct of_pci_range_parser parser;
+	u32 res_type;
 
 	pr_info("PCI host bridge %s %s ranges:\n",
 	       dev->full_name, primary ? "(primary)" : "");
 
-	/* Get ranges property */
-	ranges = of_get_property(dev, "ranges", &rlen);
-	if (ranges == NULL)
+	/* Check for ranges property */
+	if (of_pci_range_parser(&parser, dev))
 		return;
 
-	/* Parse it */
 	pr_debug("Parsing ranges property...\n");
-	while ((rlen -= np * 4) >= 0) {
+	for_each_of_pci_range(&parser, &range) {
 		/* Read next ranges element */
-		pci_space = ranges[0];
-		pci_addr = of_read_number(ranges + 1, 2);
-		cpu_addr = of_translate_address(dev, ranges + 3);
-		size = of_read_number(ranges + pna + 3, 2);
-
-		pr_debug("pci_space: 0x%08x pci_addr:0x%016llx ",
-				pci_space, pci_addr);
-		pr_debug("cpu_addr:0x%016llx size:0x%016llx\n",
-					cpu_addr, size);
-
-		ranges += np;
+		pr_debug("pci_space: 0x%08x pci_addr: 0x%016llx ",
+				range.pci_space, range.pci_addr);
+		pr_debug("cpu_addr: 0x%016llx size: 0x%016llx\n",
+				range.cpu_addr, range.size);
 
 		/* If we failed translation or got a zero-sized region
 		 * (some FW try to feed us with non sensical zero sized regions
 		 * such as power3 which look like some kind of attempt
 		 * at exposing the VGA memory hole)
 		 */
-		if (cpu_addr == OF_BAD_ADDR || size == 0)
+		if (range.cpu_addr == OF_BAD_ADDR || range.size == 0)
 			continue;
 
-		/* Now consume following elements while they are contiguous */
-		for (; rlen >= np * sizeof(u32);
-		     ranges += np, rlen -= np * 4) {
-			if (ranges[0] != pci_space)
-				break;
-			pci_next = of_read_number(ranges + 1, 2);
-			cpu_next = of_translate_address(dev, ranges + 3);
-			if (pci_next != pci_addr + size ||
-			    cpu_next != cpu_addr + size)
-				break;
-			size += of_read_number(ranges + pna + 3, 2);
-		}
-
 		/* Act based on address space type */
 		res = NULL;
-		switch ((pci_space >> 24) & 0x3) {
-		case 1:		/* PCI IO space */
+		res_type = range.flags & IORESOURCE_TYPE_BITS;
+		if (res_type == IORESOURCE_IO) {
 			pr_info("  IO 0x%016llx..0x%016llx -> 0x%016llx\n",
-			       cpu_addr, cpu_addr + size - 1, pci_addr);
+				range.cpu_addr, range.cpu_addr + range.size - 1,
+				range.pci_addr);
 
 			/* We support only one IO range */
 			if (hose->pci_io_size) {
@@ -151,11 +127,12 @@ void pci_process_bridge_OF_ranges(struct pci_controller *hose,
 			}
 #if (!IS_ENABLED(CONFIG_64BIT))
 			/* On 32 bits, limit I/O space to 16MB */
-			if (size > 0x01000000)
-				size = 0x01000000;
+			if (range.size > 0x01000000)
+				range.size = 0x01000000;
 
 			/* 32 bits needs to map IOs here */
-			hose->io_base_virt = ioremap(cpu_addr, size);
+			hose->io_base_virt = ioremap(range.cpu_addr,
+						range.size);
 
 			/* Expect trouble if pci_addr is not 0 */
 			if (primary)
@@ -165,19 +142,18 @@ void pci_process_bridge_OF_ranges(struct pci_controller *hose,
 			/* pci_io_size and io_base_phys always represent IO
 			 * space starting at 0 so we factor in pci_addr
 			 */
-			hose->pci_io_size = pci_addr + size;
-			hose->io_base_phys = cpu_addr - pci_addr;
+			hose->pci_io_size = range.pci_addr + range.size;
+			hose->io_base_phys = range.cpu_addr - range.pci_addr;
 
 			/* Build resource */
 			res = &hose->io_resource;
-			res->flags = IORESOURCE_IO;
-			res->start = pci_addr;
-			break;
-		case 2:		/* PCI Memory space */
-		case 3:		/* PCI 64 bits Memory space */
+			range.cpu_addr = range.pci_addr;
+		} else if (res_type == IORESOURCE_MEM) {
 			pr_info(" MEM 0x%016llx..0x%016llx -> 0x%016llx %s\n",
-			       cpu_addr, cpu_addr + size - 1, pci_addr,
-			       (pci_space & 0x40000000) ? "Prefetch" : "");
+				range.cpu_addr, range.cpu_addr + range.size - 1,
+				range.pci_addr,
+				(range.pci_space & 0x40000000) ?
+				"Prefetch" : "");
 
 			/* We support only 3 memory ranges */
 			if (memno >= 3) {
@@ -185,13 +161,13 @@ void pci_process_bridge_OF_ranges(struct pci_controller *hose,
 				continue;
 			}
 			/* Handles ISA memory hole space here */
-			if (pci_addr == 0) {
-				isa_mb = cpu_addr;
+			if (range.pci_addr == 0) {
+				isa_mb = range.cpu_addr;
 				isa_hole = memno;
 				if (primary || isa_mem_base == 0)
-					isa_mem_base = cpu_addr;
-				hose->isa_mem_phys = cpu_addr;
-				hose->isa_mem_size = size;
+					isa_mem_base = range.cpu_addr;
+				hose->isa_mem_phys = range.cpu_addr;
+				hose->isa_mem_size = range.size;
 			}
 
 			/* We get the PCI/Mem offset from the first range or
@@ -199,30 +175,22 @@ void pci_process_bridge_OF_ranges(struct pci_controller *hose,
 			 * hole. If they don't match, bugger.
 			 */
 			if (memno == 0 ||
-			    (isa_hole >= 0 && pci_addr != 0 &&
+			(isa_hole >= 0 && range.pci_addr != 0 &&
 			     hose->pci_mem_offset == isa_mb))
-				hose->pci_mem_offset = cpu_addr - pci_addr;
-			else if (pci_addr != 0 &&
-				 hose->pci_mem_offset != cpu_addr - pci_addr) {
+				hose->pci_mem_offset = range.cpu_addr -
+							range.pci_addr;
+			else if (range.pci_addr != 0 &&
+				hose->pci_mem_offset != range.cpu_addr -
+							range.pci_addr) {
 				pr_info(" \\--> Skipped (offset mismatch) !\n");
 				continue;
 			}
 
 			/* Build resource */
 			res = &hose->mem_resources[memno++];
-			res->flags = IORESOURCE_MEM;
-			if (pci_space & 0x40000000)
-				res->flags |= IORESOURCE_PREFETCH;
-			res->start = cpu_addr;
-			break;
-		}
-		if (res != NULL) {
-			res->name = dev->full_name;
-			res->end = res->start + size - 1;
-			res->parent = NULL;
-			res->sibling = NULL;
-			res->child = NULL;
 		}
+		if (res != NULL)
+			of_pci_range_to_resource(&range, dev, res);
 	}
 
 	/* If there's an ISA hole and the pci_mem_offset is -not- matching
diff --git a/include/linux/of_address.h b/include/linux/of_address.h
index 0506eb5..9702255 100644
--- a/include/linux/of_address.h
+++ b/include/linux/of_address.h
@@ -4,6 +4,36 @@
 #include <linux/errno.h>
 #include <linux/of.h>
 
+struct of_pci_range_parser {
+	struct device_node *node;
+	const __be32 *range;
+	const __be32 *end;
+	int np;
+	int pna;
+};
+
+struct of_pci_range {
+	u32 pci_space;
+	u64 pci_addr;
+	u64 cpu_addr;
+	u64 size;
+	u32 flags;
+};
+
+#define for_each_of_pci_range(parser, range) \
+	for (; of_pci_process_ranges(parser, range);)
+
+static inline void of_pci_range_to_resource(struct of_pci_range *range,
+					    struct device_node *np,
+					    struct resource *res)
+{
+	res->flags = range->flags;
+	res->start = range->cpu_addr;
+	res->end = range->cpu_addr + range->size - 1;
+	res->parent = res->child = res->sibling = NULL;
+	res->name = np->full_name;
+}
+
 #ifdef CONFIG_OF_ADDRESS
 extern u64 of_translate_address(struct device_node *np, const __be32 *addr);
 extern bool of_can_translate_address(struct device_node *dev);
@@ -27,6 +57,10 @@ static inline unsigned long pci_address_to_pio(phys_addr_t addr) { return -1; }
 #define pci_address_to_pio pci_address_to_pio
 #endif
 
+int of_pci_range_parser(struct of_pci_range_parser *parser,
+			struct device_node *node);
+struct of_pci_range *of_pci_process_ranges(struct of_pci_range_parser *parser,
+						struct of_pci_range *range);
 #else /* CONFIG_OF_ADDRESS */
 #ifndef of_address_to_resource
 static inline int of_address_to_resource(struct device_node *dev, int index,
@@ -53,6 +87,18 @@ static inline const __be32 *of_get_address(struct device_node *dev, int index,
 {
 	return NULL;
 }
+
+int of_pci_range_parser(struct of_pci_range_parser *parser,
+			struct device_noed *node)
+{
+	return -1;
+}
+
+struct of_pci_range *of_pci_process_ranges(struct of_pci_range_parser *parser,
+						struct of_pci_range *range)
+{
+	return NULL;
+}
 #endif /* CONFIG_OF_ADDRESS */
 
 
-- 
1.7.0.4



From Andrew.Murray at arm.com  Thu Apr 11 11:26:09 2013
From: Andrew.Murray at arm.com (Andrew Murray)
Date: Thu, 11 Apr 2013 16:26:09 +0100
Subject: [PATCH v6 3/3] of/pci: mips: convert to common of_pci_range_parser
In-Reply-To: <1365693969-23907-1-git-send-email-Andrew.Murray@arm.com>
References: <1365693969-23907-1-git-send-email-Andrew.Murray@arm.com>
Message-ID: <1365693969-23907-4-git-send-email-Andrew.Murray@arm.com>

This patch converts the pci_load_of_ranges function to use the new common
of_pci_range_parser.

Signed-off-by: Andrew Murray <Andrew.Murray at arm.com>
Signed-off-by: Liviu Dudau <Liviu.Dudau at arm.com>
Reviewed-by: Rob Herring <rob.herring at calxeda.com>
---
 arch/mips/pci/pci.c |   50 ++++++++++++++++----------------------------------
 1 files changed, 16 insertions(+), 34 deletions(-)

diff --git a/arch/mips/pci/pci.c b/arch/mips/pci/pci.c
index 0872f12..bee49a4 100644
--- a/arch/mips/pci/pci.c
+++ b/arch/mips/pci/pci.c
@@ -122,51 +122,33 @@ static void pcibios_scanbus(struct pci_controller *hose)
 #ifdef CONFIG_OF
 void pci_load_of_ranges(struct pci_controller *hose, struct device_node *node)
 {
-	const __be32 *ranges;
-	int rlen;
-	int pna = of_n_addr_cells(node);
-	int np = pna + 5;
+	struct of_pci_range_range range;
+	struct of_pci_range_parser parser;
+	u32 res_type;
 
 	pr_info("PCI host bridge %s ranges:\n", node->full_name);
-	ranges = of_get_property(node, "ranges", &rlen);
-	if (ranges == NULL)
-		return;
 	hose->of_node = node;
 
-	while ((rlen -= np * 4) >= 0) {
-		u32 pci_space;
+	if (of_pci_range_parser(&parser, node))
+		return;
+
+	for_each_of_pci_range(&parser, &range) {
 		struct resource *res = NULL;
-		u64 addr, size;
-
-		pci_space = be32_to_cpup(&ranges[0]);
-		addr = of_translate_address(node, ranges + 3);
-		size = of_read_number(ranges + pna + 3, 2);
-		ranges += np;
-		switch ((pci_space >> 24) & 0x3) {
-		case 1:		/* PCI IO space */
+
+		res_type = range.flags & IORESOURCE_TYPE_BITS;
+		if (res_type == IORESOURCE_IO) {
 			pr_info("  IO 0x%016llx..0x%016llx\n",
-					addr, addr + size - 1);
+				range.addr, range.addr + range.size - 1);
 			hose->io_map_base =
-				(unsigned long)ioremap(addr, size);
+				(unsigned long)ioremap(range.addr, range.size);
 			res = hose->io_resource;
-			res->flags = IORESOURCE_IO;
-			break;
-		case 2:		/* PCI Memory space */
-		case 3:		/* PCI 64 bits Memory space */
+		} else if (res_type == IORESOURCE_MEM) {
 			pr_info(" MEM 0x%016llx..0x%016llx\n",
-					addr, addr + size - 1);
+				range.addr, range.addr + range.size - 1);
 			res = hose->mem_resource;
-			res->flags = IORESOURCE_MEM;
-			break;
-		}
-		if (res != NULL) {
-			res->start = addr;
-			res->name = node->full_name;
-			res->end = res->start + size - 1;
-			res->parent = NULL;
-			res->sibling = NULL;
-			res->child = NULL;
 		}
+		if (res != NULL)
+			of_pci_range_to_resource(&range, node, res);
 	}
 }
 #endif
-- 
1.7.0.4



From Andrew.Murray at arm.com  Thu Apr 11 11:26:06 2013
From: Andrew.Murray at arm.com (Andrew Murray)
Date: Thu, 11 Apr 2013 16:26:06 +0100
Subject: [PATCH v6 0/3] of/pci: Provide common support for PCI DT parsing
Message-ID: <1365693969-23907-1-git-send-email-Andrew.Murray@arm.com>

This patchset factors out duplicated code associated with parsing PCI
DT "ranges" properties across the architectures and introduces a
"ranges" parser. This parser "of_pci_range_parser" can be used directly
by ARM host bridge drivers enabling them to obtain ranges from device
trees.

I've included the Reviewed-by and Tested-by's received from v5 in this
patchset, earlier versions of this patchset (v3) have been tested-by:

Thierry Reding <thierry.reding at avionic-design.de>
Jingoo Han <jg1.han at samsung.com>

I believe a version of this patchset has also been tested through its
inclusion in Thomas Petazzoni's Armada 370 and Armada XP SoCs PCIe support by:

Linus Walleij <linus.walleij at linaro.org>

I've tested that this patchset builds and runs on ARM and that it builds on
PowerPC.

Compared to the v5 sent by Andrew Murray, the following changes have
been made:

 * Use of CONFIG_64BIT instead of CONFIG_[a32bitarch] as suggested by
   Rob Herring in drivers/of/of_pci.c

 * Added forward declaration of struct pci_controller in linux/of_pci.h
   to prevent compiler warning as suggested by Thomas Petazzoni

 * Improved error checking (!range check), removal of unnecessary be32_to_cpup
   call, improved formatting of struct of_pci_range_parser layout and
   replacement of macro with a static inline. All suggested by Rob Herring.

Compared to the v4 (incorrectly labelled v3) sent by Andrew Murray,
the following changes have been made:

 * Split the patch as suggested by Rob Herring

Compared to the v3 sent by Andrew Murray, the following changes have
been made:

 * Unify and move duplicate pci_process_bridge_OF_ranges functions to
   drivers/of/of_pci.c as suggested by Rob Herring

 * Fix potential build errors with Microblaze/MIPS

Compared to "[PATCH v5 01/17] of/pci: Provide support for parsing PCI DT
ranges property", the following changes have been made:

 * Correct use of IORESOURCE_* as suggested by Russell King

 * Improved interface and naming as suggested by Thierry Reding

Compared to the v2 sent by Andrew Murray, Thomas Petazzoni did:

 * Add a memset() on the struct of_pci_range_iter when starting the
   for loop in for_each_pci_range(). Otherwise, with an uninitialized
   of_pci_range_iter, of_pci_process_ranges() may crash.

 * Add parenthesis around 'res', 'np' and 'iter' in the
   for_each_of_pci_range macro definitions. Otherwise, passing
   something like &foobar as 'res' didn't work.

 * Rebased on top of 3.9-rc2, which required fixing a few conflicts in
   the Microblaze code.

v2:
  This follows on from suggestions made by Grant Likely
  (marc.info/?l=linux-kernel&m=136079602806328)

Andrew Murray (3):
  of/pci: Unify pci_process_bridge_OF_ranges from Microblaze and
    PowerPC
  of/pci: Provide support for parsing PCI DT ranges property
  of/pci: mips: convert to common of_pci_range_parser

 arch/microblaze/include/asm/pci-bridge.h |    5 +-
 arch/microblaze/pci/pci-common.c         |  192 ------------------------------
 arch/mips/pci/pci.c                      |   50 +++------
 arch/powerpc/include/asm/pci-bridge.h    |    5 +-
 arch/powerpc/kernel/pci-common.c         |  192 ------------------------------
 drivers/of/address.c                     |   66 ++++++++++
 drivers/of/of_pci.c                      |  168 ++++++++++++++++++++++++++
 include/linux/of_address.h               |   46 +++++++
 include/linux/of_pci.h                   |    4 +
 9 files changed, 302 insertions(+), 426 deletions(-)



From Andrew.Murray at arm.com  Thu Apr 11 11:26:07 2013
From: Andrew.Murray at arm.com (Andrew Murray)
Date: Thu, 11 Apr 2013 16:26:07 +0100
Subject: [PATCH v6 1/3] of/pci: Unify pci_process_bridge_OF_ranges from
 Microblaze and PowerPC
In-Reply-To: <1365693969-23907-1-git-send-email-Andrew.Murray@arm.com>
References: <1365693969-23907-1-git-send-email-Andrew.Murray@arm.com>
Message-ID: <1365693969-23907-2-git-send-email-Andrew.Murray@arm.com>

The pci_process_bridge_OF_ranges function, used to parse the "ranges"
property of a PCI host device, is found in both Microblaze and PowerPC
architectures. These implementations are nearly identical. This patch
moves this common code to a common place.

Signed-off-by: Andrew Murray <Andrew.Murray at arm.com>
Signed-off-by: Liviu Dudau <Liviu.Dudau at arm.com>
Reviewed-by: Rob Herring <rob.herring at calxeda.com>
Tested-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 arch/microblaze/include/asm/pci-bridge.h |    5 +-
 arch/microblaze/pci/pci-common.c         |  192 ----------------------------
 arch/powerpc/include/asm/pci-bridge.h    |    5 +-
 arch/powerpc/kernel/pci-common.c         |  192 ----------------------------
 drivers/of/of_pci.c                      |  200 ++++++++++++++++++++++++++++++
 include/linux/of_pci.h                   |    4 +
 6 files changed, 206 insertions(+), 392 deletions(-)

diff --git a/arch/microblaze/include/asm/pci-bridge.h b/arch/microblaze/include/asm/pci-bridge.h
index cb5d397..5783cd6 100644
--- a/arch/microblaze/include/asm/pci-bridge.h
+++ b/arch/microblaze/include/asm/pci-bridge.h
@@ -10,6 +10,7 @@
 #include <linux/pci.h>
 #include <linux/list.h>
 #include <linux/ioport.h>
+#include <linux/of_pci.h>
 
 struct device_node;
 
@@ -132,10 +133,6 @@ extern void setup_indirect_pci(struct pci_controller *hose,
 extern struct pci_controller *pci_find_hose_for_OF_device(
 			struct device_node *node);
 
-/* Fill up host controller resources from the OF node */
-extern void pci_process_bridge_OF_ranges(struct pci_controller *hose,
-			struct device_node *dev, int primary);
-
 /* Allocate & free a PCI host bridge structure */
 extern struct pci_controller *pcibios_alloc_controller(struct device_node *dev);
 extern void pcibios_free_controller(struct pci_controller *phb);
diff --git a/arch/microblaze/pci/pci-common.c b/arch/microblaze/pci/pci-common.c
index 9ea521e..2735ad9 100644
--- a/arch/microblaze/pci/pci-common.c
+++ b/arch/microblaze/pci/pci-common.c
@@ -622,198 +622,6 @@ void pci_resource_to_user(const struct pci_dev *dev, int bar,
 	*end = rsrc->end - offset;
 }
 
-/**
- * pci_process_bridge_OF_ranges - Parse PCI bridge resources from device tree
- * @hose: newly allocated pci_controller to be setup
- * @dev: device node of the host bridge
- * @primary: set if primary bus (32 bits only, soon to be deprecated)
- *
- * This function will parse the "ranges" property of a PCI host bridge device
- * node and setup the resource mapping of a pci controller based on its
- * content.
- *
- * Life would be boring if it wasn't for a few issues that we have to deal
- * with here:
- *
- *   - We can only cope with one IO space range and up to 3 Memory space
- *     ranges. However, some machines (thanks Apple !) tend to split their
- *     space into lots of small contiguous ranges. So we have to coalesce.
- *
- *   - We can only cope with all memory ranges having the same offset
- *     between CPU addresses and PCI addresses. Unfortunately, some bridges
- *     are setup for a large 1:1 mapping along with a small "window" which
- *     maps PCI address 0 to some arbitrary high address of the CPU space in
- *     order to give access to the ISA memory hole.
- *     The way out of here that I've chosen for now is to always set the
- *     offset based on the first resource found, then override it if we
- *     have a different offset and the previous was set by an ISA hole.
- *
- *   - Some busses have IO space not starting at 0, which causes trouble with
- *     the way we do our IO resource renumbering. The code somewhat deals with
- *     it for 64 bits but I would expect problems on 32 bits.
- *
- *   - Some 32 bits platforms such as 4xx can have physical space larger than
- *     32 bits so we need to use 64 bits values for the parsing
- */
-void pci_process_bridge_OF_ranges(struct pci_controller *hose,
-				  struct device_node *dev, int primary)
-{
-	const u32 *ranges;
-	int rlen;
-	int pna = of_n_addr_cells(dev);
-	int np = pna + 5;
-	int memno = 0, isa_hole = -1;
-	u32 pci_space;
-	unsigned long long pci_addr, cpu_addr, pci_next, cpu_next, size;
-	unsigned long long isa_mb = 0;
-	struct resource *res;
-
-	pr_info("PCI host bridge %s %s ranges:\n",
-	       dev->full_name, primary ? "(primary)" : "");
-
-	/* Get ranges property */
-	ranges = of_get_property(dev, "ranges", &rlen);
-	if (ranges == NULL)
-		return;
-
-	/* Parse it */
-	pr_debug("Parsing ranges property...\n");
-	while ((rlen -= np * 4) >= 0) {
-		/* Read next ranges element */
-		pci_space = ranges[0];
-		pci_addr = of_read_number(ranges + 1, 2);
-		cpu_addr = of_translate_address(dev, ranges + 3);
-		size = of_read_number(ranges + pna + 3, 2);
-
-		pr_debug("pci_space: 0x%08x pci_addr:0x%016llx ",
-				pci_space, pci_addr);
-		pr_debug("cpu_addr:0x%016llx size:0x%016llx\n",
-					cpu_addr, size);
-
-		ranges += np;
-
-		/* If we failed translation or got a zero-sized region
-		 * (some FW try to feed us with non sensical zero sized regions
-		 * such as power3 which look like some kind of attempt
-		 * at exposing the VGA memory hole)
-		 */
-		if (cpu_addr == OF_BAD_ADDR || size == 0)
-			continue;
-
-		/* Now consume following elements while they are contiguous */
-		for (; rlen >= np * sizeof(u32);
-		     ranges += np, rlen -= np * 4) {
-			if (ranges[0] != pci_space)
-				break;
-			pci_next = of_read_number(ranges + 1, 2);
-			cpu_next = of_translate_address(dev, ranges + 3);
-			if (pci_next != pci_addr + size ||
-			    cpu_next != cpu_addr + size)
-				break;
-			size += of_read_number(ranges + pna + 3, 2);
-		}
-
-		/* Act based on address space type */
-		res = NULL;
-		switch ((pci_space >> 24) & 0x3) {
-		case 1:		/* PCI IO space */
-			pr_info("  IO 0x%016llx..0x%016llx -> 0x%016llx\n",
-			       cpu_addr, cpu_addr + size - 1, pci_addr);
-
-			/* We support only one IO range */
-			if (hose->pci_io_size) {
-				pr_info(" \\--> Skipped (too many) !\n");
-				continue;
-			}
-			/* On 32 bits, limit I/O space to 16MB */
-			if (size > 0x01000000)
-				size = 0x01000000;
-
-			/* 32 bits needs to map IOs here */
-			hose->io_base_virt = ioremap(cpu_addr, size);
-
-			/* Expect trouble if pci_addr is not 0 */
-			if (primary)
-				isa_io_base =
-					(unsigned long)hose->io_base_virt;
-			/* pci_io_size and io_base_phys always represent IO
-			 * space starting at 0 so we factor in pci_addr
-			 */
-			hose->pci_io_size = pci_addr + size;
-			hose->io_base_phys = cpu_addr - pci_addr;
-
-			/* Build resource */
-			res = &hose->io_resource;
-			res->flags = IORESOURCE_IO;
-			res->start = pci_addr;
-			break;
-		case 2:		/* PCI Memory space */
-		case 3:		/* PCI 64 bits Memory space */
-			pr_info(" MEM 0x%016llx..0x%016llx -> 0x%016llx %s\n",
-			       cpu_addr, cpu_addr + size - 1, pci_addr,
-			       (pci_space & 0x40000000) ? "Prefetch" : "");
-
-			/* We support only 3 memory ranges */
-			if (memno >= 3) {
-				pr_info(" \\--> Skipped (too many) !\n");
-				continue;
-			}
-			/* Handles ISA memory hole space here */
-			if (pci_addr == 0) {
-				isa_mb = cpu_addr;
-				isa_hole = memno;
-				if (primary || isa_mem_base == 0)
-					isa_mem_base = cpu_addr;
-				hose->isa_mem_phys = cpu_addr;
-				hose->isa_mem_size = size;
-			}
-
-			/* We get the PCI/Mem offset from the first range or
-			 * the, current one if the offset came from an ISA
-			 * hole. If they don't match, bugger.
-			 */
-			if (memno == 0 ||
-			    (isa_hole >= 0 && pci_addr != 0 &&
-			     hose->pci_mem_offset == isa_mb))
-				hose->pci_mem_offset = cpu_addr - pci_addr;
-			else if (pci_addr != 0 &&
-				 hose->pci_mem_offset != cpu_addr - pci_addr) {
-				pr_info(" \\--> Skipped (offset mismatch) !\n");
-				continue;
-			}
-
-			/* Build resource */
-			res = &hose->mem_resources[memno++];
-			res->flags = IORESOURCE_MEM;
-			if (pci_space & 0x40000000)
-				res->flags |= IORESOURCE_PREFETCH;
-			res->start = cpu_addr;
-			break;
-		}
-		if (res != NULL) {
-			res->name = dev->full_name;
-			res->end = res->start + size - 1;
-			res->parent = NULL;
-			res->sibling = NULL;
-			res->child = NULL;
-		}
-	}
-
-	/* If there's an ISA hole and the pci_mem_offset is -not- matching
-	 * the ISA hole offset, then we need to remove the ISA hole from
-	 * the resource list for that brige
-	 */
-	if (isa_hole >= 0 && hose->pci_mem_offset != isa_mb) {
-		unsigned int next = isa_hole + 1;
-		pr_info(" Removing ISA hole at 0x%016llx\n", isa_mb);
-		if (next < memno)
-			memmove(&hose->mem_resources[isa_hole],
-				&hose->mem_resources[next],
-				sizeof(struct resource) * (memno - next));
-		hose->mem_resources[--memno].flags = 0;
-	}
-}
-
 /* Decide whether to display the domain number in /proc */
 int pci_proc_domain(struct pci_bus *bus)
 {
diff --git a/arch/powerpc/include/asm/pci-bridge.h b/arch/powerpc/include/asm/pci-bridge.h
index 025a130..205bfba 100644
--- a/arch/powerpc/include/asm/pci-bridge.h
+++ b/arch/powerpc/include/asm/pci-bridge.h
@@ -10,6 +10,7 @@
 #include <linux/pci.h>
 #include <linux/list.h>
 #include <linux/ioport.h>
+#include <linux/of_pci.h>
 #include <asm-generic/pci-bridge.h>
 
 struct device_node;
@@ -231,10 +232,6 @@ extern int pcibios_map_io_space(struct pci_bus *bus);
 extern struct pci_controller *pci_find_hose_for_OF_device(
 			struct device_node* node);
 
-/* Fill up host controller resources from the OF node */
-extern void pci_process_bridge_OF_ranges(struct pci_controller *hose,
-			struct device_node *dev, int primary);
-
 /* Allocate & free a PCI host bridge structure */
 extern struct pci_controller *pcibios_alloc_controller(struct device_node *dev);
 extern void pcibios_free_controller(struct pci_controller *phb);
diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index fa12ae4..6edf396 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -640,198 +640,6 @@ void pci_resource_to_user(const struct pci_dev *dev, int bar,
 	*end = rsrc->end - offset;
 }
 
-/**
- * pci_process_bridge_OF_ranges - Parse PCI bridge resources from device tree
- * @hose: newly allocated pci_controller to be setup
- * @dev: device node of the host bridge
- * @primary: set if primary bus (32 bits only, soon to be deprecated)
- *
- * This function will parse the "ranges" property of a PCI host bridge device
- * node and setup the resource mapping of a pci controller based on its
- * content.
- *
- * Life would be boring if it wasn't for a few issues that we have to deal
- * with here:
- *
- *   - We can only cope with one IO space range and up to 3 Memory space
- *     ranges. However, some machines (thanks Apple !) tend to split their
- *     space into lots of small contiguous ranges. So we have to coalesce.
- *
- *   - We can only cope with all memory ranges having the same offset
- *     between CPU addresses and PCI addresses. Unfortunately, some bridges
- *     are setup for a large 1:1 mapping along with a small "window" which
- *     maps PCI address 0 to some arbitrary high address of the CPU space in
- *     order to give access to the ISA memory hole.
- *     The way out of here that I've chosen for now is to always set the
- *     offset based on the first resource found, then override it if we
- *     have a different offset and the previous was set by an ISA hole.
- *
- *   - Some busses have IO space not starting at 0, which causes trouble with
- *     the way we do our IO resource renumbering. The code somewhat deals with
- *     it for 64 bits but I would expect problems on 32 bits.
- *
- *   - Some 32 bits platforms such as 4xx can have physical space larger than
- *     32 bits so we need to use 64 bits values for the parsing
- */
-void pci_process_bridge_OF_ranges(struct pci_controller *hose,
-				  struct device_node *dev, int primary)
-{
-	const u32 *ranges;
-	int rlen;
-	int pna = of_n_addr_cells(dev);
-	int np = pna + 5;
-	int memno = 0, isa_hole = -1;
-	u32 pci_space;
-	unsigned long long pci_addr, cpu_addr, pci_next, cpu_next, size;
-	unsigned long long isa_mb = 0;
-	struct resource *res;
-
-	printk(KERN_INFO "PCI host bridge %s %s ranges:\n",
-	       dev->full_name, primary ? "(primary)" : "");
-
-	/* Get ranges property */
-	ranges = of_get_property(dev, "ranges", &rlen);
-	if (ranges == NULL)
-		return;
-
-	/* Parse it */
-	while ((rlen -= np * 4) >= 0) {
-		/* Read next ranges element */
-		pci_space = ranges[0];
-		pci_addr = of_read_number(ranges + 1, 2);
-		cpu_addr = of_translate_address(dev, ranges + 3);
-		size = of_read_number(ranges + pna + 3, 2);
-		ranges += np;
-
-		/* If we failed translation or got a zero-sized region
-		 * (some FW try to feed us with non sensical zero sized regions
-		 * such as power3 which look like some kind of attempt at exposing
-		 * the VGA memory hole)
-		 */
-		if (cpu_addr == OF_BAD_ADDR || size == 0)
-			continue;
-
-		/* Now consume following elements while they are contiguous */
-		for (; rlen >= np * sizeof(u32);
-		     ranges += np, rlen -= np * 4) {
-			if (ranges[0] != pci_space)
-				break;
-			pci_next = of_read_number(ranges + 1, 2);
-			cpu_next = of_translate_address(dev, ranges + 3);
-			if (pci_next != pci_addr + size ||
-			    cpu_next != cpu_addr + size)
-				break;
-			size += of_read_number(ranges + pna + 3, 2);
-		}
-
-		/* Act based on address space type */
-		res = NULL;
-		switch ((pci_space >> 24) & 0x3) {
-		case 1:		/* PCI IO space */
-			printk(KERN_INFO
-			       "  IO 0x%016llx..0x%016llx -> 0x%016llx\n",
-			       cpu_addr, cpu_addr + size - 1, pci_addr);
-
-			/* We support only one IO range */
-			if (hose->pci_io_size) {
-				printk(KERN_INFO
-				       " \\--> Skipped (too many) !\n");
-				continue;
-			}
-#ifdef CONFIG_PPC32
-			/* On 32 bits, limit I/O space to 16MB */
-			if (size > 0x01000000)
-				size = 0x01000000;
-
-			/* 32 bits needs to map IOs here */
-			hose->io_base_virt = ioremap(cpu_addr, size);
-
-			/* Expect trouble if pci_addr is not 0 */
-			if (primary)
-				isa_io_base =
-					(unsigned long)hose->io_base_virt;
-#endif /* CONFIG_PPC32 */
-			/* pci_io_size and io_base_phys always represent IO
-			 * space starting at 0 so we factor in pci_addr
-			 */
-			hose->pci_io_size = pci_addr + size;
-			hose->io_base_phys = cpu_addr - pci_addr;
-
-			/* Build resource */
-			res = &hose->io_resource;
-			res->flags = IORESOURCE_IO;
-			res->start = pci_addr;
-			break;
-		case 2:		/* PCI Memory space */
-		case 3:		/* PCI 64 bits Memory space */
-			printk(KERN_INFO
-			       " MEM 0x%016llx..0x%016llx -> 0x%016llx %s\n",
-			       cpu_addr, cpu_addr + size - 1, pci_addr,
-			       (pci_space & 0x40000000) ? "Prefetch" : "");
-
-			/* We support only 3 memory ranges */
-			if (memno >= 3) {
-				printk(KERN_INFO
-				       " \\--> Skipped (too many) !\n");
-				continue;
-			}
-			/* Handles ISA memory hole space here */
-			if (pci_addr == 0) {
-				isa_mb = cpu_addr;
-				isa_hole = memno;
-				if (primary || isa_mem_base == 0)
-					isa_mem_base = cpu_addr;
-				hose->isa_mem_phys = cpu_addr;
-				hose->isa_mem_size = size;
-			}
-
-			/* We get the PCI/Mem offset from the first range or
-			 * the, current one if the offset came from an ISA
-			 * hole. If they don't match, bugger.
-			 */
-			if (memno == 0 ||
-			    (isa_hole >= 0 && pci_addr != 0 &&
-			     hose->pci_mem_offset == isa_mb))
-				hose->pci_mem_offset = cpu_addr - pci_addr;
-			else if (pci_addr != 0 &&
-				 hose->pci_mem_offset != cpu_addr - pci_addr) {
-				printk(KERN_INFO
-				       " \\--> Skipped (offset mismatch) !\n");
-				continue;
-			}
-
-			/* Build resource */
-			res = &hose->mem_resources[memno++];
-			res->flags = IORESOURCE_MEM;
-			if (pci_space & 0x40000000)
-				res->flags |= IORESOURCE_PREFETCH;
-			res->start = cpu_addr;
-			break;
-		}
-		if (res != NULL) {
-			res->name = dev->full_name;
-			res->end = res->start + size - 1;
-			res->parent = NULL;
-			res->sibling = NULL;
-			res->child = NULL;
-		}
-	}
-
-	/* If there's an ISA hole and the pci_mem_offset is -not- matching
-	 * the ISA hole offset, then we need to remove the ISA hole from
-	 * the resource list for that brige
-	 */
-	if (isa_hole >= 0 && hose->pci_mem_offset != isa_mb) {
-		unsigned int next = isa_hole + 1;
-		printk(KERN_INFO " Removing ISA hole at 0x%016llx\n", isa_mb);
-		if (next < memno)
-			memmove(&hose->mem_resources[isa_hole],
-				&hose->mem_resources[next],
-				sizeof(struct resource) * (memno - next));
-		hose->mem_resources[--memno].flags = 0;
-	}
-}
-
 /* Decide whether to display the domain number in /proc */
 int pci_proc_domain(struct pci_bus *bus)
 {
diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
index 13e37e2..1626172 100644
--- a/drivers/of/of_pci.c
+++ b/drivers/of/of_pci.c
@@ -4,6 +4,10 @@
 #include <linux/of_pci.h>
 #include <asm/prom.h>
 
+#if defined(CONFIG_PPC32) || defined(CONFIG_PPC64) || defined(CONFIG_MICROBLAZE)
+#include <asm/pci-bridge.h>
+#endif
+
 static inline int __of_pci_pci_compare(struct device_node *node,
 				       unsigned int devfn)
 {
@@ -40,3 +44,199 @@ struct device_node *of_pci_find_child_device(struct device_node *parent,
 	return NULL;
 }
 EXPORT_SYMBOL_GPL(of_pci_find_child_device);
+
+/**
+ * pci_process_bridge_OF_ranges - Parse PCI bridge resources from device tree
+ * @hose: newly allocated pci_controller to be setup
+ * @dev: device node of the host bridge
+ * @primary: set if primary bus (32 bits only, soon to be deprecated)
+ *
+ * This function will parse the "ranges" property of a PCI host bridge device
+ * node and setup the resource mapping of a pci controller based on its
+ * content.
+ *
+ * Life would be boring if it wasn't for a few issues that we have to deal
+ * with here:
+ *
+ *   - We can only cope with one IO space range and up to 3 Memory space
+ *     ranges. However, some machines (thanks Apple !) tend to split their
+ *     space into lots of small contiguous ranges. So we have to coalesce.
+ *
+ *   - We can only cope with all memory ranges having the same offset
+ *     between CPU addresses and PCI addresses. Unfortunately, some bridges
+ *     are setup for a large 1:1 mapping along with a small "window" which
+ *     maps PCI address 0 to some arbitrary high address of the CPU space in
+ *     order to give access to the ISA memory hole.
+ *     The way out of here that I've chosen for now is to always set the
+ *     offset based on the first resource found, then override it if we
+ *     have a different offset and the previous was set by an ISA hole.
+ *
+ *   - Some busses have IO space not starting at 0, which causes trouble with
+ *     the way we do our IO resource renumbering. The code somewhat deals with
+ *     it for 64 bits but I would expect problems on 32 bits.
+ *
+ *   - Some 32 bits platforms such as 4xx can have physical space larger than
+ *     32 bits so we need to use 64 bits values for the parsing
+ */
+#if defined(CONFIG_PPC32) || defined(CONFIG_PPC64) || defined(CONFIG_MICROBLAZE)
+void pci_process_bridge_OF_ranges(struct pci_controller *hose,
+				  struct device_node *dev, int primary)
+{
+	const u32 *ranges;
+	int rlen;
+	int pna = of_n_addr_cells(dev);
+	int np = pna + 5;
+	int memno = 0, isa_hole = -1;
+	u32 pci_space;
+	unsigned long long pci_addr, cpu_addr, pci_next, cpu_next, size;
+	unsigned long long isa_mb = 0;
+	struct resource *res;
+
+	pr_info("PCI host bridge %s %s ranges:\n",
+	       dev->full_name, primary ? "(primary)" : "");
+
+	/* Get ranges property */
+	ranges = of_get_property(dev, "ranges", &rlen);
+	if (ranges == NULL)
+		return;
+
+	/* Parse it */
+	pr_debug("Parsing ranges property...\n");
+	while ((rlen -= np * 4) >= 0) {
+		/* Read next ranges element */
+		pci_space = ranges[0];
+		pci_addr = of_read_number(ranges + 1, 2);
+		cpu_addr = of_translate_address(dev, ranges + 3);
+		size = of_read_number(ranges + pna + 3, 2);
+
+		pr_debug("pci_space: 0x%08x pci_addr:0x%016llx ",
+				pci_space, pci_addr);
+		pr_debug("cpu_addr:0x%016llx size:0x%016llx\n",
+					cpu_addr, size);
+
+		ranges += np;
+
+		/* If we failed translation or got a zero-sized region
+		 * (some FW try to feed us with non sensical zero sized regions
+		 * such as power3 which look like some kind of attempt
+		 * at exposing the VGA memory hole)
+		 */
+		if (cpu_addr == OF_BAD_ADDR || size == 0)
+			continue;
+
+		/* Now consume following elements while they are contiguous */
+		for (; rlen >= np * sizeof(u32);
+		     ranges += np, rlen -= np * 4) {
+			if (ranges[0] != pci_space)
+				break;
+			pci_next = of_read_number(ranges + 1, 2);
+			cpu_next = of_translate_address(dev, ranges + 3);
+			if (pci_next != pci_addr + size ||
+			    cpu_next != cpu_addr + size)
+				break;
+			size += of_read_number(ranges + pna + 3, 2);
+		}
+
+		/* Act based on address space type */
+		res = NULL;
+		switch ((pci_space >> 24) & 0x3) {
+		case 1:		/* PCI IO space */
+			pr_info("  IO 0x%016llx..0x%016llx -> 0x%016llx\n",
+			       cpu_addr, cpu_addr + size - 1, pci_addr);
+
+			/* We support only one IO range */
+			if (hose->pci_io_size) {
+				pr_info(" \\--> Skipped (too many) !\n");
+				continue;
+			}
+#if (!IS_ENABLED(CONFIG_64BIT))
+			/* On 32 bits, limit I/O space to 16MB */
+			if (size > 0x01000000)
+				size = 0x01000000;
+
+			/* 32 bits needs to map IOs here */
+			hose->io_base_virt = ioremap(cpu_addr, size);
+
+			/* Expect trouble if pci_addr is not 0 */
+			if (primary)
+				isa_io_base =
+					(unsigned long)hose->io_base_virt;
+#endif /* !CONFIG_64BIT */
+			/* pci_io_size and io_base_phys always represent IO
+			 * space starting at 0 so we factor in pci_addr
+			 */
+			hose->pci_io_size = pci_addr + size;
+			hose->io_base_phys = cpu_addr - pci_addr;
+
+			/* Build resource */
+			res = &hose->io_resource;
+			res->flags = IORESOURCE_IO;
+			res->start = pci_addr;
+			break;
+		case 2:		/* PCI Memory space */
+		case 3:		/* PCI 64 bits Memory space */
+			pr_info(" MEM 0x%016llx..0x%016llx -> 0x%016llx %s\n",
+			       cpu_addr, cpu_addr + size - 1, pci_addr,
+			       (pci_space & 0x40000000) ? "Prefetch" : "");
+
+			/* We support only 3 memory ranges */
+			if (memno >= 3) {
+				pr_info(" \\--> Skipped (too many) !\n");
+				continue;
+			}
+			/* Handles ISA memory hole space here */
+			if (pci_addr == 0) {
+				isa_mb = cpu_addr;
+				isa_hole = memno;
+				if (primary || isa_mem_base == 0)
+					isa_mem_base = cpu_addr;
+				hose->isa_mem_phys = cpu_addr;
+				hose->isa_mem_size = size;
+			}
+
+			/* We get the PCI/Mem offset from the first range or
+			 * the, current one if the offset came from an ISA
+			 * hole. If they don't match, bugger.
+			 */
+			if (memno == 0 ||
+			    (isa_hole >= 0 && pci_addr != 0 &&
+			     hose->pci_mem_offset == isa_mb))
+				hose->pci_mem_offset = cpu_addr - pci_addr;
+			else if (pci_addr != 0 &&
+				 hose->pci_mem_offset != cpu_addr - pci_addr) {
+				pr_info(" \\--> Skipped (offset mismatch) !\n");
+				continue;
+			}
+
+			/* Build resource */
+			res = &hose->mem_resources[memno++];
+			res->flags = IORESOURCE_MEM;
+			if (pci_space & 0x40000000)
+				res->flags |= IORESOURCE_PREFETCH;
+			res->start = cpu_addr;
+			break;
+		}
+		if (res != NULL) {
+			res->name = dev->full_name;
+			res->end = res->start + size - 1;
+			res->parent = NULL;
+			res->sibling = NULL;
+			res->child = NULL;
+		}
+	}
+
+	/* If there's an ISA hole and the pci_mem_offset is -not- matching
+	 * the ISA hole offset, then we need to remove the ISA hole from
+	 * the resource list for that brige
+	 */
+	if (isa_hole >= 0 && hose->pci_mem_offset != isa_mb) {
+		unsigned int next = isa_hole + 1;
+		pr_info(" Removing ISA hole at 0x%016llx\n", isa_mb);
+		if (next < memno)
+			memmove(&hose->mem_resources[isa_hole],
+				&hose->mem_resources[next],
+				sizeof(struct resource) * (memno - next));
+		hose->mem_resources[--memno].flags = 0;
+	}
+}
+#endif
diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
index bb115de..33e8ead 100644
--- a/include/linux/of_pci.h
+++ b/include/linux/of_pci.h
@@ -11,4 +11,8 @@ struct device_node;
 struct device_node *of_pci_find_child_device(struct device_node *parent,
 					     unsigned int devfn);
 
+struct pci_controller;
+void pci_process_bridge_OF_ranges(struct pci_controller *hose,
+			struct device_node *dev, int primary);
+
 #endif
-- 
1.7.0.4



From sebastian.hesselbarth at gmail.com  Thu Apr 11 11:27:03 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Thu, 11 Apr 2013 17:27:03 +0200
Subject: [PATCH] net: mv643xx_eth: Add GRO support
In-Reply-To: <20130411150326.GA19978@1wt.eu>
References: <1365684023-9967-1-git-send-email-sebastian.hesselbarth@gmail.com>
 <20130411131333.GD1910@1wt.eu>
 <CABJ1b_TQDabT1J7ffo5cb1Th=71bcSduifMJaDpfVRiiHvtWDw@mail.gmail.com>
 <20130411150326.GA19978@1wt.eu>
Message-ID: <CABJ1b_TRxm97DKJLP_h0VwMJvcYmSpjoJvtg1KvBNGah=VzqMQ@mail.gmail.com>

On Thu, Apr 11, 2013 at 5:03 PM, Willy Tarreau <w at 1wt.eu> wrote:
> On Thu, Apr 11, 2013 at 04:47:49PM +0200, Sebastian Hesselbarth wrote:
>> I tried todays net-next on top of 3.9-rc6 without any gro patch, with
>> the initial
>> patch (Soeren) and your proposed patch (Willy). The results show that
>> both patches
>> allow a significant increase in throughput compared to
>> netif_receive_skb (!gro, !lro)
>> alone. Having gro with lro disabled gives some 2% more throughput
>> compared to lro only.
>
> Indeed this is consistent with my memories, since Eric improved the
> GRO path, it became faster than LRO on this chip.

I don't have a strong opinion on whether Soeren's or your proposal should
be submitted. But I insist on having one of them in, as GRO significantly
improves the common use case, is enabled by default, and not as
constrained as LRO.

Sebastian


From thomas.petazzoni at free-electrons.com  Thu Apr 11 11:28:54 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Thu, 11 Apr 2013 17:28:54 +0200
Subject: [PATCH v5 1/3] of/pci: Unify pci_process_bridge_OF_ranges from
 Microblaze and PowerPC
In-Reply-To: <20130411121242.GB28981@arm.com>
References: <1365578969-30966-1-git-send-email-Andrew.Murray@arm.com>
 <1365578969-30966-2-git-send-email-Andrew.Murray@arm.com>
 <20130410233330.4e9479b0@skate> <20130411121242.GB28981@arm.com>
Message-ID: <20130411172854.61f5728e@skate>

Dear Andrew Murray,

On Thu, 11 Apr 2013 13:12:42 +0100, Andrew Murray wrote:

> Thanks - I somehow missed this.
> 
> I've included this change in my next respin - but I've put
> 'struct pci_controller' immediately before
> 'pci_process_bridge_OF_ranges' rather than above of_irq_map_pci to be
> consistent with the rest of the file.

Right, sounds good.

Do we have some news from the PowerPC and Microblaze maintainers about
their acceptance of PATCH 1/3 ? This of/pci thing is the only last
remaining patch for which I need a Ack to get the Marvell PCIe merged.

Thanks!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From w at 1wt.eu  Thu Apr 11 11:32:56 2013
From: w at 1wt.eu (Willy Tarreau)
Date: Thu, 11 Apr 2013 17:32:56 +0200
Subject: [PATCH] net: mv643xx_eth: Add GRO support
In-Reply-To: <CABJ1b_TRxm97DKJLP_h0VwMJvcYmSpjoJvtg1KvBNGah=VzqMQ@mail.gmail.com>
References: <1365684023-9967-1-git-send-email-sebastian.hesselbarth@gmail.com>
 <20130411131333.GD1910@1wt.eu>
 <CABJ1b_TQDabT1J7ffo5cb1Th=71bcSduifMJaDpfVRiiHvtWDw@mail.gmail.com>
 <20130411150326.GA19978@1wt.eu>
 <CABJ1b_TRxm97DKJLP_h0VwMJvcYmSpjoJvtg1KvBNGah=VzqMQ@mail.gmail.com>
Message-ID: <20130411153256.GH1910@1wt.eu>

On Thu, Apr 11, 2013 at 05:27:03PM +0200, Sebastian Hesselbarth wrote:
> I don't have a strong opinion on whether Soeren's or your proposal should
> be submitted. But I insist on having one of them in, as GRO significantly
> improves the common use case, is enabled by default, and not as
> constrained as LRO.

I agree, use yours first, but we should keep an eye on this. Since you have
everything to run a test, please try to see if you can get netperf to run
over IPv6, I'm sure the NIC doesn't handle it.

Willy



From rklein at nvidia.com  Thu Apr 11 11:38:47 2013
From: rklein at nvidia.com (Rhyland Klein)
Date: Thu, 11 Apr 2013 11:38:47 -0400
Subject: [PATCH] ARM: tegra: Add charger subnode to tps65090 node
In-Reply-To: <5165E80D.7050106@wwwdotorg.org>
References: <1365623505-6309-1-git-send-email-rklein@nvidia.com>
 <5165E80D.7050106@wwwdotorg.org>
Message-ID: <5166D907.6060004@nvidia.com>

On 4/10/2013 6:30 PM, Stephen Warren wrote:
> On 04/10/2013 01:51 PM, Rhyland Klein wrote:
>> The charger is now represented by a distinct subnode of the tps65090
>> device. Add this node and enable low current charging with it.
> 
>> diff --git a/arch/arm/boot/dts/tegra114-dalmore.dts b/arch/arm/boot/dts/tegra114-dalmore.dts
> 
>> +			charger {
>> +				compatible = "ti,tps65090-charger";
>> +				ti,enable-low-current-chrg;
> 
> So does the TPS65090 driver scan all its sub-nodes like a bus an
> instantiate anything? That's a little odd since the regulators node is
> at the same level, yet doesn't represent a device on that same internal
> bus...
> 

It doesn't scan so much as have a list of subdev's it tries to register.
The charger node uses the of_compatible string defined (in the tps65090
driver and the charger driver) to match the subnode to the mfd_cell
device for the charger. The regulators are currently under a different
subdevice which is not using the of_compatible string. I was planning on
a follow up patch series to update the tps65090-regulator driver to use
the dt type approach with a subnode to be consistent.

-rhyland

-- 
nvpublic


From broonie at opensource.wolfsonmicro.com  Thu Apr 11 11:42:16 2013
From: broonie at opensource.wolfsonmicro.com (Mark Brown)
Date: Thu, 11 Apr 2013 16:42:16 +0100
Subject: [PATCH 20/30] ASoC: samsung: convert to dmaengine API
In-Reply-To: <201304111647.17796.arnd@arndb.de>
References: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
 <1365638712-1028578-21-git-send-email-arnd@arndb.de>
 <20130411142706.GB24971@opensource.wolfsonmicro.com>
 <201304111647.17796.arnd@arndb.de>
Message-ID: <20130411154216.GE9243@opensource.wolfsonmicro.com>

On Thu, Apr 11, 2013 at 04:47:17PM +0200, Arnd Bergmann wrote:

> Can you have a look at the other three ASoC patches in the series? I think
> it would still be useful to merge them.

Yeah, they looked fine - just waiting for me to do a patch run.  Should
get to it shortly.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130411/ebdf54ba/attachment.sig>

From tony at atomide.com  Thu Apr 11 11:48:07 2013
From: tony at atomide.com (Tony Lindgren)
Date: Thu, 11 Apr 2013 08:48:07 -0700
Subject: [PATCH 25/26] arm: Don't use create_proc_read_entry() [RFC]
In-Reply-To: <20130411133058.32763.5466.stgit@warthog.procyon.org.uk>
References: <20130411132739.32763.82609.stgit@warthog.procyon.org.uk>
 <20130411133058.32763.5466.stgit@warthog.procyon.org.uk>
Message-ID: <20130411154806.GU10155@atomide.com>

* David Howells <dhowells at redhat.com> [130411 06:35]:
> Don't use create_proc_read_entry() as that is deprecated, but rather use
> proc_create_data() and seq_file instead.
> 
> Signed-off-by: David Howells <dhowells at redhat.com>
> cc: Russell King <linux at arm.linux.org.uk>
> cc: Kevin Hilman <khilman at deeprootsystems.com>

Looks like the mach-omap1/pm.c part we can make into
a debugfs entry as it only contains PM debug data. But
that we can do after this patch.

Acked-by: Tony Lindgren <tony at atomide.com>

> cc: linux-arm-kernel at lists.infradead.org
> cc: linux-omap at vger.kernel.org
> ---
> 
>  arch/arm/kernel/swp_emulate.c |   42 +++++++++++++-----------------
>  arch/arm/mach-omap1/pm.c      |   58 +++++++++++++++++------------------------
>  2 files changed, 43 insertions(+), 57 deletions(-)
> 
> diff --git a/arch/arm/kernel/swp_emulate.c b/arch/arm/kernel/swp_emulate.c
> index 0bba47a..087fc32 100644
> --- a/arch/arm/kernel/swp_emulate.c
> +++ b/arch/arm/kernel/swp_emulate.c
> @@ -21,6 +21,7 @@
>  #include <linux/init.h>
>  #include <linux/kernel.h>
>  #include <linux/proc_fs.h>
> +#include <linux/seq_file.h>
>  #include <linux/sched.h>
>  #include <linux/syscalls.h>
>  #include <linux/perf_event.h>
> @@ -79,27 +80,27 @@ static unsigned long abtcounter;
>  static pid_t         previous_pid;
>  
>  #ifdef CONFIG_PROC_FS
> -static int proc_read_status(char *page, char **start, off_t off, int count,
> -			    int *eof, void *data)
> +static int proc_status_show(struct seq_file *m, void *v)
>  {
> -	char *p = page;
> -	int len;
> -
> -	p += sprintf(p, "Emulated SWP:\t\t%lu\n", swpcounter);
> -	p += sprintf(p, "Emulated SWPB:\t\t%lu\n", swpbcounter);
> -	p += sprintf(p, "Aborted SWP{B}:\t\t%lu\n", abtcounter);
> +	seq_printf(m, "Emulated SWP:\t\t%lu\n", swpcounter);
> +	seq_printf(m, "Emulated SWPB:\t\t%lu\n", swpbcounter);
> +	seq_printf(m, "Aborted SWP{B}:\t\t%lu\n", abtcounter);
>  	if (previous_pid != 0)
> -		p += sprintf(p, "Last process:\t\t%d\n", previous_pid);
> -
> -	len = (p - page) - off;
> -	if (len < 0)
> -		len = 0;
> -
> -	*eof = (len <= count) ? 1 : 0;
> -	*start = page + off;
> +		seq_printf(m, "Last process:\t\t%d\n", previous_pid);
> +	return 0;
> +}
>  
> -	return len;
> +static int proc_status_open(struct inode *inode, struct file *file)
> +{
> +	return single_open(file, proc_status_show, PDE_DATA(inode));
>  }
> +
> +static const struct file_operations proc_status_fops = {
> +	.open		= proc_status_open,
> +	.read		= seq_read,
> +	.llseek		= seq_lseek,
> +	.release	= seq_release,
> +};
>  #endif
>  
>  /*
> @@ -266,12 +267,7 @@ static struct undef_hook swp_hook = {
>  static int __init swp_emulation_init(void)
>  {
>  #ifdef CONFIG_PROC_FS
> -	struct proc_dir_entry *res;
> -
> -	res = create_proc_read_entry("cpu/swp_emulation", S_IRUGO, NULL,
> -					proc_read_status, NULL);
> -
> -	if (!res)
> +	if (!proc_create("cpu/swp_emulation", S_IRUGO, NULL, &proc_status_fops))
>  		return -ENOMEM;
>  #endif /* CONFIG_PROC_FS */
>  
> diff --git a/arch/arm/mach-omap1/pm.c b/arch/arm/mach-omap1/pm.c
> index 7a7690a..2645e37 100644
> --- a/arch/arm/mach-omap1/pm.c
> +++ b/arch/arm/mach-omap1/pm.c
> @@ -38,6 +38,7 @@
>  #include <linux/suspend.h>
>  #include <linux/sched.h>
>  #include <linux/proc_fs.h>
> +#include <linux/seq_file.h>
>  #include <linux/interrupt.h>
>  #include <linux/sysfs.h>
>  #include <linux/module.h>
> @@ -423,22 +424,11 @@ void omap1_pm_suspend(void)
>  }
>  
>  #if defined(DEBUG) && defined(CONFIG_PROC_FS)
> -static int g_read_completed;
> -
>  /*
>   * Read system PM registers for debugging
>   */
> -static int omap_pm_read_proc(
> -	char *page_buffer,
> -	char **my_first_byte,
> -	off_t virtual_start,
> -	int length,
> -	int *eof,
> -	void *data)
> +static int omap_pm_proc_show(struct seq_file *m, void *v)
>  {
> -	int my_buffer_offset = 0;
> -	char * const my_base = page_buffer;
> -
>  	ARM_SAVE(ARM_CKCTL);
>  	ARM_SAVE(ARM_IDLECT1);
>  	ARM_SAVE(ARM_IDLECT2);
> @@ -479,10 +469,7 @@ static int omap_pm_read_proc(
>  		MPUI1610_SAVE(EMIFS_CONFIG);
>  	}
>  
> -	if (virtual_start == 0) {
> -		g_read_completed = 0;
> -
> -		my_buffer_offset += sprintf(my_base + my_buffer_offset,
> +	seq_printf(m,
>  		   "ARM_CKCTL_REG:            0x%-8x     \n"
>  		   "ARM_IDLECT1_REG:          0x%-8x     \n"
>  		   "ARM_IDLECT2_REG:          0x%-8x     \n"
> @@ -512,8 +499,8 @@ static int omap_pm_read_proc(
>  		   ULPD_SHOW(ULPD_STATUS_REQ),
>  		   ULPD_SHOW(ULPD_POWER_CTRL));
>  
> -		if (cpu_is_omap7xx()) {
> -			my_buffer_offset += sprintf(my_base + my_buffer_offset,
> +	if (cpu_is_omap7xx()) {
> +		seq_printf(m,
>  			   "MPUI7XX_CTRL_REG	     0x%-8x \n"
>  			   "MPUI7XX_DSP_STATUS_REG:      0x%-8x \n"
>  			   "MPUI7XX_DSP_BOOT_CONFIG_REG: 0x%-8x \n"
> @@ -526,8 +513,8 @@ static int omap_pm_read_proc(
>  			   MPUI7XX_SHOW(MPUI_DSP_API_CONFIG),
>  			   MPUI7XX_SHOW(EMIFF_SDRAM_CONFIG),
>  			   MPUI7XX_SHOW(EMIFS_CONFIG));
> -		} else if (cpu_is_omap15xx()) {
> -			my_buffer_offset += sprintf(my_base + my_buffer_offset,
> +	} else if (cpu_is_omap15xx()) {
> +		seq_printf(m,
>  			   "MPUI1510_CTRL_REG             0x%-8x \n"
>  			   "MPUI1510_DSP_STATUS_REG:      0x%-8x \n"
>  			   "MPUI1510_DSP_BOOT_CONFIG_REG: 0x%-8x \n"
> @@ -540,8 +527,8 @@ static int omap_pm_read_proc(
>  			   MPUI1510_SHOW(MPUI_DSP_API_CONFIG),
>  			   MPUI1510_SHOW(EMIFF_SDRAM_CONFIG),
>  			   MPUI1510_SHOW(EMIFS_CONFIG));
> -		} else if (cpu_is_omap16xx()) {
> -			my_buffer_offset += sprintf(my_base + my_buffer_offset,
> +	} else if (cpu_is_omap16xx()) {
> +		seq_printf(m,
>  			   "MPUI1610_CTRL_REG             0x%-8x \n"
>  			   "MPUI1610_DSP_STATUS_REG:      0x%-8x \n"
>  			   "MPUI1610_DSP_BOOT_CONFIG_REG: 0x%-8x \n"
> @@ -554,25 +541,28 @@ static int omap_pm_read_proc(
>  			   MPUI1610_SHOW(MPUI_DSP_API_CONFIG),
>  			   MPUI1610_SHOW(EMIFF_SDRAM_CONFIG),
>  			   MPUI1610_SHOW(EMIFS_CONFIG));
> -		}
> -
> -		g_read_completed++;
> -	} else if (g_read_completed >= 1) {
> -		 *eof = 1;
> -		 return 0;
>  	}
> -	g_read_completed++;
>  
> -	*my_first_byte = page_buffer;
> -	return  my_buffer_offset;
> +	return 0;
> +}
> +
> +static int omap_pm_proc_open(struct inode *inode, struct file *file)
> +{
> +	return single_open(file, omap_pm_proc_show, PDE_DATA(inode));
>  }
>  
> +static const struct file_operations omap_pm_proc_fops = {
> +	.open		= omap_pm_proc_open,
> +	.read		= seq_read,
> +	.llseek		= seq_lseek,
> +	.release	= seq_release,
> +};
> +
>  static void omap_pm_init_proc(void)
>  {
>  	/* XXX Appears to leak memory */
> -	create_proc_read_entry("driver/omap_pm",
> -			       S_IWUSR | S_IRUGO, NULL,
> -			       omap_pm_read_proc, NULL);
> +	create_proc("driver/omap_pm", S_IWUSR | S_IRUGO, NULL,
> +		    &omap_pm_proc_fops);
>  }
>  
>  #endif /* DEBUG && CONFIG_PROC_FS */
> 


From lorenzo.pieralisi at arm.com  Thu Apr 11 11:50:54 2013
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Thu, 11 Apr 2013 16:50:54 +0100
Subject: [RFC PATCH 01/11] Documentation: DT: arm: define CPU topology
 bindings
In-Reply-To: <5166D01F.5070404@gmail.com>
References: <1365671562-2403-1-git-send-email-mark.rutland@arm.com>
 <1365671562-2403-2-git-send-email-mark.rutland@arm.com>
 <5166D01F.5070404@gmail.com>
Message-ID: <20130411155054.GA29509@e102568-lin.cambridge.arm.com>

On Thu, Apr 11, 2013 at 04:00:47PM +0100, Rob Herring wrote:
> On 04/11/2013 04:12 AM, Mark Rutland wrote:
> > From: Lorenzo Pieralisi <Lorenzo.Pieralisi at arm.com>
> > 
> > The advent of multi-cluster ARM systems requires a mechanism to describe
> > how in hierarchical terms CPUs are connected in ARM SoCs so that the kernel
> > can initialize and map resources like IRQs and memory space to specific
> > group(s) of CPUs.
> > 
> > The CPU topology is made up of multiple hierarchy levels whose bottom
> > layers (aka leaf nodes in device tree syntax) contain links to the HW
> > CPUs in the system.
> > 
> > The topology bindings are generic for both 32-bit and 64-bit systems and
> > lay the groundwork on top of which affinity schemes can be built.
> > 
> > This patch provides the documentation in the kernel required to define the
> > device tree bindings describing the CPU topology for ARM 32-bit and 64-bit
> > systems.
> 
> I'm now very weary of continued /cpu changes after the pain of making
> the reg property reflect the mpidr value in 3.8.

We won't change the reg property value, the code I am about to post
provides stricter bindings, stricter semantics and extends bindings to
cater for arm 64-bit systems.

> > Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
> > Signed-off-by: Mark Rutland <mark.rutland at arm.com>
> > ---
> >  Documentation/devicetree/bindings/arm/topology.txt | 524 +++++++++++++++++++++
> >  1 file changed, 524 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/arm/topology.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/arm/topology.txt b/Documentation/devicetree/bindings/arm/topology.txt
> > new file mode 100644
> > index 0000000..07c4961
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/arm/topology.txt
> > @@ -0,0 +1,524 @@
> > +===========================================
> > +ARM topology binding description
> > +===========================================
> > +
> > +===========================================
> > +1 - Introduction
> > +===========================================
> > +
> > +In an ARM system, the hierarchy of CPUs is defined through three entities that
> > +are used to describe the layout of physical CPUs in the system:
> > +
> > +- cluster
> > +- core
> > +- thread
> > +
> > +The cpu nodes (bindings defined in [1]) represent the devices that
> > +correspond to physical CPUs and are to be mapped to the hierarchy levels.
> > +
> > +The bottom hierarchy level sits at core or thread level depending on whether
> > +symmetric multi-threading (SMT) is supported or not.
> > +
> > +For instance in a system where CPUs support SMT, "cpu" nodes represent all
> > +threads existing in the system and map to the hierarchy level "thread" above.
> > +In systems where SMT is not supported "cpu" nodes represent all cores present
> > +in the system and map to the hierarchy level "core" above.
> > +
> > +ARM topology bindings allow one to associate cpu nodes with hierarchical groups
> > +corresponding to the system hierarchy; syntactically they are defined as device
> > +tree nodes.
> > +
> > +The remainder of this document provides the topology bindings for ARM, based
> > +on the ePAPR standard, available from:
> > +
> > +http://devicetree.org
> > +
> > +If not stated otherwise, whenever a reference to a cpu node phandle is made its
> > +value must point to a cpu node compliant with the cpu node bindings as
> > +documented in [1].
> > +A topology description containing phandles to cpu nodes that are not compliant
> > +with bindings standardized in [1] is therefore considered invalid.
> > +
> > +===========================================
> > +2 - cpu-map node
> > +===========================================
> > +
> > +The ARM CPU topology is defined within a container node, sitting at the top
> > +level of the device tree (/), the cpu-map node.
> > +
> > +- cpu-map node
> > +
> > +	Usage: Required to define ARM CPU topology
> > +
> > +	Description: The cpu-map node is just a container node where its
> > +		     subnodes describe the CPU topology
> > +
> > +	Node name must be "cpu-map".
> > +
> > +	A cpu-map node's child nodes can be:
> > +
> > +	- one or more cluster nodes
> > +
> > +	Any other configuration is considered invalid.
> > +
> > +The cpu-map node can only contain three types of child nodes:
> > +
> > +- cluster node
> > +- core node
> > +- thread node
> > +
> 
> Why not put the topology in the /cpus nodes? I don't really see the
> point of having a flat list of cpus and separate topology info. There is
> some compatibility issue, but adding optional levels for clusters can be
> handled.

I thought this would break all code relying on /cpu nodes being /cpus node's
children. Furthermore, I was told that the /cpus node can only have /cpu nodes
as children.

If you wish so, we can define the topology in the /cpus node, fine by me.

> > +whose bindings are described in paragraph 3.
> > +
> > +The nodes describing the CPU topology (cluster/core/thread) can only be
> > +defined within the cpu-map node.
> > +Any other configuration is consider invalid and therefore must be ignored.
> > +
> > +===========================================
> > +2.1 - cpu-map child nodes naming convention
> > +===========================================
> > +
> > +cpu-map child nodes must follow a naming convention where the node name
> > +must be "clusterN", "coreN", "threadN" depending on the node type (ie
> > +cluster/core/thread) (where N = {0, 1, ...} is the node number; nodes which
> > +are siblings within a single common parent node must be given a unique and
> > +sequential N value, starting from 0).
> > +cpu-map child nodes which do not share a common parent node can have the same
> > +name (ie same number N as other cpu-map child nodes at different device tree
> > +levels) since name uniqueness will be guaranteed by the device tree hierarchy.
> > +
> > +===========================================
> > +3 - cluster/core/thread node bindings
> > +===========================================
> > +
> > +Bindings for cluster/cpu/thread nodes are defined as follows:
> > +
> > +- cluster node
> > +
> > +	 Description: must be declared within a cpu-map node, one node
> > +		      per cluster. A system can contain several layers of
> > +		      clustering and cluster nodes can be contained in parent
> > +		      cluster nodes.
> > +
> > +	The cluster node name must be "clusterN" as described in 2.1 above.
> > +	A cluster node can not be a leaf node.
> 
> Follow standard conventions with "cluster at N" and a reg property with the
> number.

We are defining the topology to decouple the cluster/core/thread concept
from the MPIDR. Having a reg property in the cluster (and core) nodes
would complicate things if that reg property must correspond to an MPIDR
bitfield. If it is meant to be just an enumeration at a given device tree
level, I am ok with changing that.

> > +
> > +	A cluster node's child nodes must be:
> > +
> > +	- one or more cluster nodes; or
> > +	- one or more core nodes
> > +
> > +	Any other configuration is considered invalid.
> > +
> > +- core node
> > +
> > +	Description: must be declared in a cluster node, one node per core in
> > +		     the cluster. If the system does not support SMT, core
> > +		     nodes are leaf nodes, otherwise they become containers of
> > +		     thread nodes.
> > +
> > +	The core node name must be "coreN" as described in 2.1 above.
> > +
> > +	A core node must be a leaf node if SMT is not supported.
> > +
> > +	Properties for core nodes that are leaf nodes:
> > +
> > +	- cpu
> > +		Usage: required
> > +		Value type: <phandle>
> > +		Definition: a phandle to the cpu node that corresponds to the
> > +			    core node.
> > +
> > +	If a core node is not a leaf node (CPUs supporting SMT) a core node's
> > +	child nodes can be:
> > +
> > +	- one or more thread nodes
> > +
> > +	Any other configuration is considered invalid.
> > +
> > +- thread node
> > +
> > +	Description: must be declared in a core node, one node per thread
> > +		     in the core if the system supports SMT. Thread nodes are
> > +		     always leaf nodes in the device tree.
> > +
> > +	The thread node name must be "threadN" as described in 2.1 above.
> > +
> > +	A thread node must be a leaf node.
> > +
> > +	A thread node must contain the following property:
> > +
> > +	- cpu
> > +		Usage: required
> > +		Value type: <phandle>
> > +		Definition: a phandle to the cpu node that corresponds to
> > +			    the thread node.
> 
> 
> According to the ePAPR, threads are represented by an array of ids for
> reg property, not another cpu node. Why the deviation.

It is not a cpu node, it is a phandle property named cpu. Can you point
me to the ePAPR section where threads bindings are described please ? I have
not managed to find these details, I am reading version 1.0.

Thanks a lot for having a look !
Lorenzo



From dinguyen at altera.com  Thu Apr 11 11:55:24 2013
From: dinguyen at altera.com (dinguyen at altera.com)
Date: Thu, 11 Apr 2013 10:55:24 -0500
Subject: [PATCHv3 1/3] ARM: socfpga: Enable soft reset
Message-ID: <1365695726-26849-1-git-send-email-dinguyen@altera.com>

From: Dinh Nguyen <dinguyen at altera.com>

Enable a cold or warm reset to the HW from userspace.

Also fix a few sparse errors:

warning: symbol 'sys_manager_base_addr' was not declared. Should it be static?
warning: symbol 'rst_manager_base_addr' was not declared. Should it be static?

Signed-off-by: Dinh Nguyen <dinguyen at altera.com>

v3:
- Use regular readl/writel

v2:
- Remove hotplug support while investigating on how implement PSCI
---
 arch/arm/mach-socfpga/core.h    |   11 +++++++++++
 arch/arm/mach-socfpga/platsmp.c |    3 ---
 arch/arm/mach-socfpga/socfpga.c |   10 +++++++++-
 3 files changed, 20 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-socfpga/core.h b/arch/arm/mach-socfpga/core.h
index 315edff..572b8f7 100644
--- a/arch/arm/mach-socfpga/core.h
+++ b/arch/arm/mach-socfpga/core.h
@@ -20,12 +20,23 @@
 #ifndef __MACH_CORE_H
 #define __MACH_CORE_H
 
+#define SOCFPGA_RSTMGR_CTRL	0x04
+#define SOCFPGA_RSTMGR_MODPERRST	0x14
+#define SOCFPGA_RSTMGR_BRGMODRST	0x1c
+
+/* System Manager bits */
+#define RSTMGR_CTRL_SWCOLDRSTREQ	0x1	/* Cold Reset */
+#define RSTMGR_CTRL_SWWARMRSTREQ	0x2	/* Warm Reset */
+
 extern void socfpga_secondary_startup(void);
 extern void __iomem *socfpga_scu_base_addr;
 
 extern void socfpga_init_clocks(void);
 extern void socfpga_sysmgr_init(void);
 
+extern void __iomem *sys_manager_base_addr;
+extern void __iomem *rst_manager_base_addr;
+
 extern struct smp_operations socfpga_smp_ops;
 extern char secondary_trampoline, secondary_trampoline_end;
 
diff --git a/arch/arm/mach-socfpga/platsmp.c b/arch/arm/mach-socfpga/platsmp.c
index 84c60fa..b907fb9 100644
--- a/arch/arm/mach-socfpga/platsmp.c
+++ b/arch/arm/mach-socfpga/platsmp.c
@@ -30,9 +30,6 @@
 
 #include "core.h"
 
-extern void __iomem *sys_manager_base_addr;
-extern void __iomem *rst_manager_base_addr;
-
 static void __cpuinit socfpga_secondary_init(unsigned int cpu)
 {
 	/*
diff --git a/arch/arm/mach-socfpga/socfpga.c b/arch/arm/mach-socfpga/socfpga.c
index 1042c02..2cae16c 100644
--- a/arch/arm/mach-socfpga/socfpga.c
+++ b/arch/arm/mach-socfpga/socfpga.c
@@ -87,7 +87,15 @@ static void __init socfpga_init_irq(void)
 
 static void socfpga_cyclone5_restart(char mode, const char *cmd)
 {
-	/* TODO: */
+	u32 temp;
+
+	temp = readl(rst_manager_base_addr + SOCFPGA_RSTMGR_CTRL);
+
+	if (mode == 'h')
+		temp |= RSTMGR_CTRL_SWCOLDRSTREQ;
+	else
+		temp |= RSTMGR_CTRL_SWWARMRSTREQ;
+	writel(temp, rst_manager_base_addr + SOCFPGA_RSTMGR_CTRL);
 }
 
 static void __init socfpga_cyclone5_init(void)
-- 
1.7.9.5




From dinguyen at altera.com  Thu Apr 11 11:55:25 2013
From: dinguyen at altera.com (dinguyen at altera.com)
Date: Thu, 11 Apr 2013 10:55:25 -0500
Subject: [PATCHv3 2/3] ARM: socfpga: Add clock entries into device tree
In-Reply-To: <1365695726-26849-1-git-send-email-dinguyen@altera.com>
References: <1365695726-26849-1-git-send-email-dinguyen@altera.com>
Message-ID: <1365695726-26849-2-git-send-email-dinguyen@altera.com>

From: Dinh Nguyen <dinguyen at altera.com>

Adds the main PLL clock groups for SOCFPGA into device tree file
so that the clock framework to query the clock and clock rates
appropriately.

$cat /sys/kernel/debug/clk/clk_summary
   clock                        enable_cnt  prepare_cnt  rate
---------------------------------------------------------------------
 osc1                           2           2            25000000
    sdram_pll                   0           0            400000000
       s2f_usr2_clk             0           0            66666666
       ddr_dq_clk               0           0            200000000
       ddr_2x_dqs_clk           0           0            400000000
       ddr_dqs_clk              0           0            200000000
    periph_pll                  2           2            500000000
       s2f_usr1_clk             0           0            50000000
       per_base_clk             4           4            100000000
       per_nand_mmc_clk         0           0            25000000
       per_qsi_clk              0           0            250000000
       emac1_clk                1           1            125000000
       emac0_clk                0           0            125000000
    main_pll                    1           1            1600000000
       cfg_s2f_usr0_clk         0           0            100000000
       main_nand_sdmmc_clk      0           0            100000000
       main_qspi_clk            0           0            400000000
       dbg_base_clk             0           0            400000000
       mainclk                  0           0            400000000
       mpuclk                   1           1            800000000
          smp_twd               1           1            200000000

Signed-off-by: Dinh Nguyen <dinguyen at altera.com>

v3:
- Use basic clk_gate structure and reuse clk_gate_ops
- Split out patches between dts and source

v2:
- Add copyright from Calxeda for clk.c
- Add device tree "fixed-divider" for clocks with fixed dividers
- Fix space and tab issues
---
 .../bindings/arm/altera/socfpga-clk-manager.txt    |   11 ++
 .../devicetree/bindings/clock/altr_socfpga.txt     |   18 +++
 arch/arm/boot/dts/socfpga.dtsi                     |  157 ++++++++++++++++++++
 arch/arm/boot/dts/socfpga_cyclone5.dts             |    8 +
 arch/arm/boot/dts/socfpga_vt.dts                   |    8 +
 5 files changed, 202 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/altera/socfpga-clk-manager.txt
 create mode 100644 Documentation/devicetree/bindings/clock/altr_socfpga.txt

diff --git a/Documentation/devicetree/bindings/arm/altera/socfpga-clk-manager.txt b/Documentation/devicetree/bindings/arm/altera/socfpga-clk-manager.txt
new file mode 100644
index 0000000..2c28f1d
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/altera/socfpga-clk-manager.txt
@@ -0,0 +1,11 @@
+Altera SOCFPGA Clock Manager
+
+Required properties:
+- compatible : "altr,clk-mgr"
+- reg : Should contain base address and length for Clock Manager
+
+Example:
+	 clkmgr at ffd04000 {
+		compatible = "altr,clk-mgr";
+		reg = <0xffd04000 0x1000>;
+	};
diff --git a/Documentation/devicetree/bindings/clock/altr_socfpga.txt b/Documentation/devicetree/bindings/clock/altr_socfpga.txt
new file mode 100644
index 0000000..bd0c841
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/altr_socfpga.txt
@@ -0,0 +1,18 @@
+Device Tree Clock bindings for Altera's SoCFPGA platform
+
+This binding uses the common clock binding[1].
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties:
+- compatible : shall be one of the following:
+	"altr,socfpga-pll-clock" - for a PLL clock
+	"altr,socfpga-perip-clock" - The peripheral clock divided from the
+		PLL clock.
+- reg : shall be the control register offset from CLOCK_MANAGER's base for the clock.
+- clocks : shall be the input parent clock phandle for the clock. This is
+	either an oscillator or a pll output.
+- #clock-cells : from common clock binding, shall be set to 0.
+
+Optional properties:
+- fixed-divider : If clocks have a fixed divider value, use this property.
diff --git a/arch/arm/boot/dts/socfpga.dtsi b/arch/arm/boot/dts/socfpga.dtsi
index 7e8769b..16a6e13 100644
--- a/arch/arm/boot/dts/socfpga.dtsi
+++ b/arch/arm/boot/dts/socfpga.dtsi
@@ -81,6 +81,163 @@
 			};
 		};
 
+		clkmgr at ffd04000 {
+				compatible = "altr,clk-mgr";
+				reg = <0xffd04000 0x1000>;
+
+				clocks {
+					#address-cells = <1>;
+					#size-cells = <0>;
+
+					osc: osc1 {
+						#clock-cells = <0>;
+						compatible = "fixed-clock";
+					};
+
+					main_pll: main_pll {
+						#address-cells = <1>;
+						#size-cells = <0>;
+						#clock-cells = <0>;
+						compatible = "altr,socfpga-pll-clock";
+						clocks = <&osc>;
+						reg = <0x40>;
+
+						mpuclk: mpuclk {
+							#clock-cells = <0>;
+							compatible = "altr,socfpga-perip-clk";
+							clocks = <&main_pll>;
+							fixed-divider = <2>;
+							reg = <0x48>;
+						};
+
+						mainclk: mainclk {
+							#clock-cells = <0>;
+							compatible = "altr,socfpga-perip-clk";
+							clocks = <&main_pll>;
+							fixed-divider = <4>;
+							reg = <0x4C>;
+						};
+
+						dbg_base_clk: dbg_base_clk {
+							#clock-cells = <0>;
+							compatible = "altr,socfpga-perip-clk";
+							clocks = <&main_pll>;
+							fixed-divider = <4>;
+							reg = <0x50>;
+						};
+
+						main_qspi_clk: main_qspi_clk {
+							#clock-cells = <0>;
+							compatible = "altr,socfpga-perip-clk";
+							clocks = <&main_pll>;
+							reg = <0x54>;
+						};
+
+						main_nand_sdmmc_clk: main_nand_sdmmc_clk {
+							#clock-cells = <0>;
+							compatible = "altr,socfpga-perip-clk";
+							clocks = <&main_pll>;
+							reg = <0x58>;
+						};
+
+						cfg_s2f_usr0_clk: cfg_s2f_usr0_clk {
+							#clock-cells = <0>;
+							compatible = "altr,socfpga-perip-clk";
+							clocks = <&main_pll>;
+							reg = <0x5C>;
+						};
+					};
+
+					periph_pll: periph_pll {
+						#address-cells = <1>;
+						#size-cells = <0>;
+						#clock-cells = <0>;
+						compatible = "altr,socfpga-pll-clock";
+						clocks = <&osc>;
+						reg = <0x80>;
+
+						emac0_clk: emac0_clk {
+							#clock-cells = <0>;
+							compatible = "altr,socfpga-perip-clk";
+							clocks = <&periph_pll>;
+							reg = <0x88>;
+						};
+
+						emac1_clk: emac1_clk {
+							#clock-cells = <0>;
+							compatible = "altr,socfpga-perip-clk";
+							clocks = <&periph_pll>;
+							reg = <0x8C>;
+						};
+
+						per_qspi_clk: per_qsi_clk {
+							#clock-cells = <0>;
+							compatible = "altr,socfpga-perip-clk";
+							clocks = <&periph_pll>;
+							reg = <0x90>;
+						};
+
+						per_nand_mmc_clk: per_nand_mmc_clk {
+							#clock-cells = <0>;
+							compatible = "altr,socfpga-perip-clk";
+							clocks = <&periph_pll>;
+							reg = <0x94>;
+						};
+
+						per_base_clk: per_base_clk {
+							#clock-cells = <0>;
+							compatible = "altr,socfpga-perip-clk";
+							clocks = <&periph_pll>;
+							reg = <0x98>;
+						};
+
+						s2f_usr1_clk: s2f_usr1_clk {
+							#clock-cells = <0>;
+							compatible = "altr,socfpga-perip-clk";
+							clocks = <&periph_pll>;
+							reg = <0x9C>;
+						};
+					};
+
+					sdram_pll: sdram_pll {
+						#address-cells = <1>;
+						#size-cells = <0>;
+						#clock-cells = <0>;
+						compatible = "altr,socfpga-pll-clock";
+						clocks = <&osc>;
+						reg = <0xC0>;
+
+						ddr_dqs_clk: ddr_dqs_clk {
+							#clock-cells = <0>;
+							compatible = "altr,socfpga-perip-clk";
+							clocks = <&sdram_pll>;
+							reg = <0xC8>;
+						};
+
+						ddr_2x_dqs_clk: ddr_2x_dqs_clk {
+							#clock-cells = <0>;
+							compatible = "altr,socfpga-perip-clk";
+							clocks = <&sdram_pll>;
+							reg = <0xCC>;
+						};
+
+						ddr_dq_clk: ddr_dq_clk {
+							#clock-cells = <0>;
+							compatible = "altr,socfpga-perip-clk";
+							clocks = <&sdram_pll>;
+							reg = <0xD0>;
+						};
+
+						s2f_usr2_clk: s2f_usr2_clk {
+							#clock-cells = <0>;
+							compatible = "altr,socfpga-perip-clk";
+							clocks = <&sdram_pll>;
+							reg = <0xD4>;
+						};
+					};
+				};
+			};
+
 		gmac0: stmmac at ff700000 {
 			compatible = "altr,socfpga-stmmac", "snps,dwmac-3.70a", "snps,dwmac";
 			reg = <0xff700000 0x2000>;
diff --git a/arch/arm/boot/dts/socfpga_cyclone5.dts b/arch/arm/boot/dts/socfpga_cyclone5.dts
index 3ae8a83..2495958 100644
--- a/arch/arm/boot/dts/socfpga_cyclone5.dts
+++ b/arch/arm/boot/dts/socfpga_cyclone5.dts
@@ -33,6 +33,14 @@
 	};
 
 	soc {
+		clkmgr at ffd04000 {
+			clocks {
+				osc1 {
+					clock-frequency = <25000000>;
+				};
+			};
+		};
+
 		timer0 at ffc08000 {
 			clock-frequency = <100000000>;
 		};
diff --git a/arch/arm/boot/dts/socfpga_vt.dts b/arch/arm/boot/dts/socfpga_vt.dts
index 1036eba..0bf035d 100644
--- a/arch/arm/boot/dts/socfpga_vt.dts
+++ b/arch/arm/boot/dts/socfpga_vt.dts
@@ -33,6 +33,14 @@
 	};
 
 	soc {
+		clkmgr at ffd04000 {
+			clocks {
+				osc1 {
+					clock-frequency = <10000000>;
+				};
+			};
+		};
+
 		timer0 at ffc08000 {
 			clock-frequency = <7000000>;
 		};
-- 
1.7.9.5




From dinguyen at altera.com  Thu Apr 11 11:55:26 2013
From: dinguyen at altera.com (dinguyen at altera.com)
Date: Thu, 11 Apr 2013 10:55:26 -0500
Subject: [PATCHv3 3/3] ARM: socfpga: Upgrade clk driver for socfpga to make
 use of dts clock entries
In-Reply-To: <1365695726-26849-1-git-send-email-dinguyen@altera.com>
References: <1365695726-26849-1-git-send-email-dinguyen@altera.com>
Message-ID: <1365695726-26849-3-git-send-email-dinguyen@altera.com>

From: Dinh Nguyen <dinguyen at altera.com>

With this patch, the socfpga clk driver is able to query the clock and clock
rates appropriately.

Signed-off-by: Dinh Nguyen <dinguyen at altera.com>
---
 arch/arm/mach-socfpga/socfpga.c |    6 ++
 drivers/clk/socfpga/clk.c       |  163 ++++++++++++++++++++++++++++++++++-----
 2 files changed, 148 insertions(+), 21 deletions(-)

diff --git a/arch/arm/mach-socfpga/socfpga.c b/arch/arm/mach-socfpga/socfpga.c
index 2cae16c..46a0513 100644
--- a/arch/arm/mach-socfpga/socfpga.c
+++ b/arch/arm/mach-socfpga/socfpga.c
@@ -15,6 +15,7 @@
  * along with this program.  If not, see <http://www.gnu.org/licenses/>.
  */
 #include <linux/dw_apb_timer.h>
+#include <linux/clk-provider.h>
 #include <linux/irqchip.h>
 #include <linux/of_address.h>
 #include <linux/of_irq.h>
@@ -29,6 +30,7 @@
 void __iomem *socfpga_scu_base_addr = ((void __iomem *)(SOCFPGA_SCU_VIRT_BASE));
 void __iomem *sys_manager_base_addr;
 void __iomem *rst_manager_base_addr;
+void __iomem *clk_mgr_base_addr;
 unsigned long cpu1start_addr;
 
 static struct map_desc scu_io_desc __initdata = {
@@ -77,6 +79,9 @@ void __init socfpga_sysmgr_init(void)
 
 	np = of_find_compatible_node(NULL, NULL, "altr,rst-mgr");
 	rst_manager_base_addr = of_iomap(np, 0);
+
+	np = of_find_compatible_node(NULL, NULL, "altr,clk-mgr");
+	clk_mgr_base_addr = of_iomap(np, 0);
 }
 
 static void __init socfpga_init_irq(void)
@@ -102,6 +107,7 @@ static void __init socfpga_cyclone5_init(void)
 {
 	l2x0_of_init(0, ~0UL);
 	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
+	of_clk_init(NULL);
 	socfpga_init_clocks();
 }
 
diff --git a/drivers/clk/socfpga/clk.c b/drivers/clk/socfpga/clk.c
index 2c855a6..bd11315 100644
--- a/drivers/clk/socfpga/clk.c
+++ b/drivers/clk/socfpga/clk.c
@@ -1,5 +1,6 @@
 /*
- *  Copyright (C) 2012 Altera Corporation <www.altera.com>
+ *  Copyright 2011-2012 Calxeda, Inc.
+ *  Copyright (C) 2012-2013 Altera Corporation <www.altera.com>
  *
  * 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
@@ -11,41 +12,161 @@
  * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  * GNU General Public License for more details.
  *
+ * Based from clk-highbank.c
+ *
  * You should have received a copy of the GNU General Public License
  * along with this program.  If not, see <http://www.gnu.org/licenses/>.
  */
 #include <linux/clk.h>
 #include <linux/clkdev.h>
 #include <linux/clk-provider.h>
+#include <linux/io.h>
+#include <linux/of.h>
 
-#define SOCFPGA_OSC1_CLK	10000000
-#define SOCFPGA_MPU_CLK		800000000
-#define SOCFPGA_MAIN_QSPI_CLK		432000000
-#define SOCFPGA_MAIN_NAND_SDMMC_CLK	250000000
-#define SOCFPGA_S2F_USR_CLK		125000000
+/* Clock Manager offsets */
+#define CLKMGR_CTRL    0x0
+#define CLKMGR_BYPASS 0x4
 
-void __init socfpga_init_clocks(void)
+/* Clock bypass bits */
+#define MAINPLL_BYPASS (1<<0)
+#define SDRAMPLL_BYPASS (1<<1)
+#define SDRAMPLL_SRC_BYPASS (1<<2)
+#define PERPLL_BYPASS (1<<3)
+#define PERPLL_SRC_BYPASS (1<<4)
+
+#define SOCFPGA_PLL_BG_PWRDWN		0
+#define SOCFPGA_PLL_EXT_ENA		1
+#define SOCFPGA_PLL_PWR_DOWN		2
+#define SOCFPGA_PLL_DIVF_MASK		0x0000FFF8
+#define SOCFPGA_PLL_DIVF_SHIFT	3
+#define SOCFPGA_PLL_DIVQ_MASK		0x003F0000
+#define SOCFPGA_PLL_DIVQ_SHIFT	16
+
+extern void __iomem *clk_mgr_base_addr;
+
+struct socfpga_clk {
+	struct clk_gate hw;
+	char *parent_name;
+	char *clk_name;
+	u32 fixed_div;
+};
+#define to_socfpga_clk(p) container_of(p, struct socfpga_clk, hw.hw)
+
+static unsigned long clk_pll_recalc_rate(struct clk_hw *hwclk,
+					 unsigned long parent_rate)
 {
+	struct socfpga_clk *socfpgaclk = to_socfpga_clk(hwclk);
+	unsigned long divf, divq, vco_freq, reg;
+	unsigned long bypass;
+
+	reg = readl(socfpgaclk->hw.reg);
+	bypass = readl(clk_mgr_base_addr + CLKMGR_BYPASS);
+	if (bypass & MAINPLL_BYPASS)
+		return parent_rate;
+
+	divf = (reg & SOCFPGA_PLL_DIVF_MASK) >> SOCFPGA_PLL_DIVF_SHIFT;
+	divq = (reg & SOCFPGA_PLL_DIVQ_MASK) >> SOCFPGA_PLL_DIVQ_SHIFT;
+	vco_freq = parent_rate * (divf + 1);
+	return vco_freq / (1 + divq);
+}
+
+
+static struct clk_ops clk_pll_ops = {
+	.recalc_rate = clk_pll_recalc_rate,
+};
+
+static unsigned long clk_periclk_recalc_rate(struct clk_hw *hwclk,
+					     unsigned long parent_rate)
+{
+	struct socfpga_clk *socfpgaclk = to_socfpga_clk(hwclk);
+	u32 div;
+
+	if (socfpgaclk->fixed_div)
+		div = socfpgaclk->fixed_div;
+	else
+		div = ((readl(socfpgaclk->hw.reg) & 0x1ff) + 1);
+
+	return parent_rate / div;
+}
+
+static const struct clk_ops periclk_ops = {
+	.recalc_rate = clk_periclk_recalc_rate,
+};
+
+static __init struct clk *socfpga_clk_init(struct device_node *node,
+	const struct clk_ops *ops)
+{
+	u32 reg;
 	struct clk *clk;
+	struct socfpga_clk *socfpga_clk;
+	const char *clk_name = node->name;
+	const char *parent_name;
+	struct clk_init_data init;
+	int rc;
+	u32 fixed_div;
+
+	rc = of_property_read_u32(node, "reg", &reg);
+	if (WARN_ON(rc))
+		return NULL;
+
+	socfpga_clk = kzalloc(sizeof(*socfpga_clk), GFP_KERNEL);
+	if (WARN_ON(!socfpga_clk))
+		return NULL;
+
+	socfpga_clk->hw.reg = clk_mgr_base_addr + reg;
+
+	rc = of_property_read_u32(node, "fixed-divider", &fixed_div);
+	if (rc)
+		socfpga_clk->fixed_div = 0;
+	else
+		socfpga_clk->fixed_div = fixed_div;
+
+	of_property_read_string(node, "clock-output-names", &clk_name);
+
+	init.name = clk_name;
+	init.ops = ops;
+	init.flags = 0;
+	parent_name = of_clk_get_parent_name(node, 0);
+	init.parent_names = &parent_name;
+	init.num_parents = 1;
 
-	clk = clk_register_fixed_rate(NULL, "osc1_clk", NULL, CLK_IS_ROOT, SOCFPGA_OSC1_CLK);
-	clk_register_clkdev(clk, "osc1_clk", NULL);
+	socfpga_clk->hw.hw.init = &init;
 
-	clk = clk_register_fixed_rate(NULL, "mpu_clk", NULL, CLK_IS_ROOT, SOCFPGA_MPU_CLK);
-	clk_register_clkdev(clk, "mpu_clk", NULL);
+	if (strcmp(clk_name, "main_pll") || strcmp(clk_name, "periph_pll") ||
+			strcmp(clk_name, "sdram_pll")) {
+		socfpga_clk->hw.bit_idx = SOCFPGA_PLL_EXT_ENA;
+		clk_pll_ops.enable = clk_gate_ops.enable;
+		clk_pll_ops.disable = clk_gate_ops.disable;
+	}
 
-	clk = clk_register_fixed_rate(NULL, "main_clk", NULL, CLK_IS_ROOT, SOCFPGA_MPU_CLK/2);
-	clk_register_clkdev(clk, "main_clk", NULL);
+	clk = clk_register(NULL, &socfpga_clk->hw.hw);
+	if (WARN_ON(IS_ERR(clk))) {
+		kfree(socfpga_clk);
+		return NULL;
+	}
+	rc = of_clk_add_provider(node, of_clk_src_simple_get, clk);
+	return clk;
+}
 
-	clk = clk_register_fixed_rate(NULL, "dbg_base_clk", NULL, CLK_IS_ROOT, SOCFPGA_MPU_CLK/2);
-	clk_register_clkdev(clk, "dbg_base_clk", NULL);
+static void __init socfpga_pll_init(struct device_node *node)
+{
+	socfpga_clk_init(node, &clk_pll_ops);
+}
+CLK_OF_DECLARE(socfpga_pll, "altr,socfpga-pll-clock", socfpga_pll_init);
 
-	clk = clk_register_fixed_rate(NULL, "main_qspi_clk", NULL, CLK_IS_ROOT, SOCFPGA_MAIN_QSPI_CLK);
-	clk_register_clkdev(clk, "main_qspi_clk", NULL);
+static void __init socfpga_periph_init(struct device_node *node)
+{
+	socfpga_clk_init(node, &periclk_ops);
+}
+CLK_OF_DECLARE(socfpga_periph, "altr,socfpga-perip-clk", socfpga_periph_init);
 
-	clk = clk_register_fixed_rate(NULL, "main_nand_sdmmc_clk", NULL, CLK_IS_ROOT, SOCFPGA_MAIN_NAND_SDMMC_CLK);
-	clk_register_clkdev(clk, "main_nand_sdmmc_clk", NULL);
+void __init socfpga_init_clocks(void)
+{
+	struct clk *clk;
+	int ret;
 
-	clk = clk_register_fixed_rate(NULL, "s2f_usr_clk", NULL, CLK_IS_ROOT, SOCFPGA_S2F_USR_CLK);
-	clk_register_clkdev(clk, "s2f_usr_clk", NULL);
+	clk = clk_register_fixed_factor(NULL, "smp_twd", "mpuclk", 0, 1, 4);
+	ret = clk_register_clkdev(clk, NULL, "smp_twd");
+	if (ret)
+		pr_err("smp_twd alias not registered\n");
 }
-- 
1.7.9.5




From eric.dumazet at gmail.com  Thu Apr 11 11:54:35 2013
From: eric.dumazet at gmail.com (Eric Dumazet)
Date: Thu, 11 Apr 2013 08:54:35 -0700
Subject: [PATCH] net: mv643xx_eth: Add GRO support
In-Reply-To: <20130411153256.GH1910@1wt.eu>
References: <1365684023-9967-1-git-send-email-sebastian.hesselbarth@gmail.com>
 <20130411131333.GD1910@1wt.eu>
 <CABJ1b_TQDabT1J7ffo5cb1Th=71bcSduifMJaDpfVRiiHvtWDw@mail.gmail.com>
 <20130411150326.GA19978@1wt.eu>
 <CABJ1b_TRxm97DKJLP_h0VwMJvcYmSpjoJvtg1KvBNGah=VzqMQ@mail.gmail.com>
 <20130411153256.GH1910@1wt.eu>
Message-ID: <1365695675.3887.165.camel@edumazet-glaptop>

On Thu, 2013-04-11 at 17:32 +0200, Willy Tarreau wrote:
> On Thu, Apr 11, 2013 at 05:27:03PM +0200, Sebastian Hesselbarth wrote:
> > I don't have a strong opinion on whether Soeren's or your proposal should
> > be submitted. But I insist on having one of them in, as GRO significantly
> > improves the common use case, is enabled by default, and not as
> > constrained as LRO.
> 
> I agree, use yours first, but we should keep an eye on this. Since you have
> everything to run a test, please try to see if you can get netperf to run
> over IPv6, I'm sure the NIC doesn't handle it.

Willy, testing the checksum in the NIC driver itself prevents the stack
doing GRO even if the NIC could not checksum the packet, as in GRE
tunneling for example.

So Sebastien patch is better IMHO : Just call the napi gro handler and
let core stack handles the details ;)







From swarren at wwwdotorg.org  Thu Apr 11 11:54:44 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Thu, 11 Apr 2013 09:54:44 -0600
Subject: [PATCH v6 3/8] reset: Add driver for gpio-controlled reset pins
In-Reply-To: <CAOesGMgo61M=oxG6_6EEGu7kL3Wa+HsdEomCxUnvj-Rbdhujgg@mail.gmail.com>
References: <1364488523-20310-1-git-send-email-p.zabel@pengutronix.de>
 <1364488523-20310-4-git-send-email-p.zabel@pengutronix.de>
 <CAOesGMgo61M=oxG6_6EEGu7kL3Wa+HsdEomCxUnvj-Rbdhujgg@mail.gmail.com>
Message-ID: <5166DCC4.6050206@wwwdotorg.org>

On 04/11/2013 04:35 AM, Olof Johansson wrote:
> On Thu, Mar 28, 2013 at 9:35 AM, Philipp Zabel <p.zabel at pengutronix.de> wrote:
>> This driver implements a reset controller device that toggles gpios
>> connected to reset pins of peripheral ICs. The delay between assertion
>> and de-assertion of the reset signal can be configured.
...
> Since this is a platform driver and not just an OF driver, shouldn't
> you provide a way to specify the same configuration data through a
> platform_data structure as well?

I believe the only practical use-cases for this driver are /currently/
for device-tree platforms. Shouldn't we add the platform_data support
only when some platform actively uses it?

In the past when reviewing new drivers, I pushed for platform drivers to
always implement the platform_data structure up-front, and support using
that if present rather than "falling back" to DT. However, Grant then
shot that down saying that there was no point adding dead code...

(this will also feed into the discussion about simple-framebuffer, which
also only needs DT support right now, but could in theory be extended to
support platform_data in the future if somebody wants).



From eric.dumazet at gmail.com  Thu Apr 11 11:54:58 2013
From: eric.dumazet at gmail.com (Eric Dumazet)
Date: Thu, 11 Apr 2013 08:54:58 -0700
Subject: [PATCH] net: mv643xx_eth: Add GRO support
In-Reply-To: <1365684023-9967-1-git-send-email-sebastian.hesselbarth@gmail.com>
References: <1365684023-9967-1-git-send-email-sebastian.hesselbarth@gmail.com>
Message-ID: <1365695698.3887.166.camel@edumazet-glaptop>

On Thu, 2013-04-11 at 14:40 +0200, Sebastian Hesselbarth wrote:
> This patch adds GRO support to mv643xx_eth by making it invoke
> napi_gro_receive instead of netif_receive_skb.
> 
> Signed-off-by: Soeren Moch <smoch at web.de>
> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
> ---
> Cc: "David S. Miller" <davem at davemloft.net>
> Cc: Lennert Buytenhek <buytenh at wantstofly.org>
> Cc: Andrew Lunn <andrew at lunn.ch>
> Cc: Jason Cooper <jason at lakedaemon.net>
> Cc: Florian Fainelli <florian at openwrt.org>
> Cc: Benjamin Herrenschmidt <benh at kernel.crashing.org>
> Cc: Paul Mackerras <paulus at samba.org>
> Cc: Dale Farnsworth <dale at farnsworth.org>
> Cc: netdev at vger.kernel.org
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linuxppc-dev at lists.ozlabs.org
> Cc: linux-kernel at vger.kernel.org
> ---
>  drivers/net/ethernet/marvell/mv643xx_eth.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c b/drivers/net/ethernet/marvell/mv643xx_eth.c
> index 305038f..c850d04 100644
> --- a/drivers/net/ethernet/marvell/mv643xx_eth.c
> +++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
> @@ -604,7 +604,7 @@ static int rxq_process(struct rx_queue *rxq, int budget)
>  			lro_receive_skb(&rxq->lro_mgr, skb, (void *)cmd_sts);
>  			lro_flush_needed = 1;
>  		} else
> -			netif_receive_skb(skb);
> +			napi_gro_receive(&mp->napi, skb);
>  
>  		continue;
>  

Acked-by: Eric Dumazet <edumazet at google.com>




From jhovold at gmail.com  Thu Apr 11 11:55:05 2013
From: jhovold at gmail.com (Johan Hovold)
Date: Thu, 11 Apr 2013 17:55:05 +0200
Subject: [PATCH v2 0/5] ARM: at91: fix hanged boot
In-Reply-To: <1363025279-17615-1-git-send-email-jhovold@gmail.com>
References: <20130311180611.GF8797@localhost>
 <1363025279-17615-1-git-send-email-jhovold@gmail.com>
Message-ID: <20130411155505.GD21305@localhost>

On Mon, Mar 11, 2013 at 07:07:54PM +0100, Johan Hovold wrote:
> These patches fix a few severe issues affecting most AT91 SOCs where
> boot can hang after a non-general reset, and where the only way to get
> the system booting again is to do a general reset -- something which
> could require physically removing any backup battery.

Have you had time to look at these patches yet, Nicolas?

I don't think not having decided on the path forward for DT-support for
rtc-at91sam9 needs to be a blocker. The rtt-nodes will be needed in any
case.

I could respin the series on top of the DT-patch for rtc-at91rm9200, and
add interrupt and status-disabled properties to the DT-nodes as well.

Thanks,
Johan

> The problems stem from the fact that the RTC and RTT-peripherals are
> powered by backup power (VDDBU) and are not reset on wake-up, user,
> watchdog or software reset. Consequently, RTC and RTT-alarms and their
> interrupts may be enabled at boot, leading to a system lock-up when an
> interrupt arrives on the shared system-interrupt line before the
> appropriate handler (e.g. RTC-driver) has been installed.
> 
> The easiest way to trigger this is to simply wake up from an RTC-alarm
> on at91sam9g45. The RTC-driver currently does not disable interrupts at
> shutdown so even after a clean shut-down the system will always hang
> after waking up.
> 
> The first patch fixes this very general case of RTC-wake up after a
> clean shutdown in the RTC-driver and is marked for stable as it is
> perfectly straight-forward. [ Note that the other, RTT-based, AT91
> RTC-driver already disables its interrupts at shutdown. ]
> 
> The more general problem can be triggered, for example, by doing a
> user-reset while updating the RTC-time or if an RTC or RTT-alarm goes
> off after a non-clean shutdown.
> 
> To fix this I propose that arch-code should mask the relevant interrupts
> before enabling the system interrupt at early boot, and this is what
> the fifth patch does. To access the RTC-registers I choose to revert a
> recent patch that moved the register definitions to drivers/rtc.
> 
> Arguably, the relevant interrupts could also be disabled in bootloaders,
> but I suggest fixing it in the kernel once and for all.
> 
> The patches have been tested on at91sam9263 and at91sam9g45 (non-DT),
> and compile-tested for the other SOCs and DT.
> 
> Johan
> 
> 
> v2:
>  - add DT-support
>  - make sys_irq_mask non-mandatory
> 
> 
> Johan Hovold (5):
>   ARM: at91/rtc: fix boot after RTC wake-up
>   ARM: at91/dts: add RTC nodes
>   ARM: at91/dts: add RTT nodes
>   Revert "arm: at91: move at91rm9200 rtc header in drivers/rtc"
>   ARM: at91: fix hanged boot


From eduardo.valentin at ti.com  Thu Apr 11 12:00:48 2013
From: eduardo.valentin at ti.com (Eduardo Valentin)
Date: Thu, 11 Apr 2013 12:00:48 -0400
Subject: [v2,01/14] thermal: Rename driver 'kirkwood' -> 'mvebu'
In-Reply-To: <1363991114-4225-2-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1363991114-4225-2-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <5166DE30.3020001@ti.com>

Hello Ezequiel,

Two minor comments.

On 22-03-2013 18:25, Ezequiel Garcia wrote:
> This driver will support several Marvell SoC, so it is convenient
> to rename it to 'mvebu' to represent accurately the hardware it
> supports.
>
> Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
>
> ---
> .../bindings/thermal/kirkwood-thermal.txt          |   15 ---
>   .../devicetree/bindings/thermal/mvebu-thermal.txt  |   15 +++
>   drivers/thermal/Kconfig                            |   10 +-
>   drivers/thermal/Makefile                           |    2 +-
>   drivers/thermal/kirkwood_thermal.c                 |  134 --------------------
>   drivers/thermal/mvebu_thermal.c                    |  134 ++++++++++++++++++++
>   6 files changed, 155 insertions(+), 155 deletions(-)
>   delete mode 100644 Documentation/devicetree/bindings/thermal/kirkwood-thermal.txt
>   create mode 100644 Documentation/devicetree/bindings/thermal/mvebu-thermal.txt
>   delete mode 100644 drivers/thermal/kirkwood_thermal.c
>   create mode 100644 drivers/thermal/mvebu_thermal.c

When sending renames, use git format-patch --find-renames. The summary 
will be much descriptive on what you have done.

I tried applying this patch on top of linux-next, linus/master, 
ruis/thermal, on top of the your suggested dependencies, and all failed. 
What is your base?

>
> diff --git a/Documentation/devicetree/bindings/thermal/kirkwood-thermal.txt b/Documentation/devicetree/bindings/thermal/kirkwood-thermal.txt
> deleted file mode 100644
> index 8c0f5eb..0000000
> --- a/Documentation/devicetree/bindings/thermal/kirkwood-thermal.txt
> +++ /dev/null
> @@ -1,15 +0,0 @@
> -* Kirkwood Thermal
> -
> -This version is for Kirkwood 88F8262 & 88F6283 SoCs. Other kirkwoods
> -don't contain a thermal sensor.
> -
> -Required properties:
> -- compatible : "marvell,kirkwood-thermal"
> -- reg : Address range of the thermal registers
> -
> -Example:
> -
> -	thermal at 10078 {
> -		compatible = "marvell,kirkwood-thermal";
> -		reg = <0x10078 0x4>;
> -	};
> diff --git a/Documentation/devicetree/bindings/thermal/mvebu-thermal.txt b/Documentation/devicetree/bindings/thermal/mvebu-thermal.txt
> new file mode 100644
> index 0000000..8c0f5eb
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/thermal/mvebu-thermal.txt
> @@ -0,0 +1,15 @@
> +* Kirkwood Thermal
> +
> +This version is for Kirkwood 88F8262 & 88F6283 SoCs. Other kirkwoods
> +don't contain a thermal sensor.
> +
> +Required properties:
> +- compatible : "marvell,kirkwood-thermal"
> +- reg : Address range of the thermal registers
> +
> +Example:
> +
> +	thermal at 10078 {
> +		compatible = "marvell,kirkwood-thermal";
> +		reg = <0x10078 0x4>;
> +	};
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> index a764f16..74f6b97 100644
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -101,13 +101,13 @@ config RCAR_THERMAL
>   	  Enable this to plug the R-Car thermal sensor driver into the Linux
>   	  thermal framework
>
> -config KIRKWOOD_THERMAL
> -	tristate "Temperature sensor on Marvell Kirkwood SoCs"
> -	depends on ARCH_KIRKWOOD
> +config MVEBU_THERMAL
> +	tristate "Temperature sensor on Marvell EBU SoCs"
> +	depends on PLAT_ORION
>   	depends on OF
>   	help
> -	  Support for the Kirkwood thermal sensor driver into the Linux thermal
> -	  framework. Only kirkwood 88F6282 and 88F6283 have this sensor.
> +	  Support for the thermal controllers available in several Marvell
> +	  EBU SoCs in the thermal framework.
>
>   config EXYNOS_THERMAL
>   	tristate "Temperature sensor on Samsung EXYNOS"
> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
> index d3a2b38..40293a1 100644
> --- a/drivers/thermal/Makefile
> +++ b/drivers/thermal/Makefile
> @@ -15,7 +15,7 @@ obj-$(CONFIG_CPU_THERMAL)	+= cpu_cooling.o
>   # platform thermal drivers
>   obj-$(CONFIG_SPEAR_THERMAL)	+= spear_thermal.o
>   obj-$(CONFIG_RCAR_THERMAL)	+= rcar_thermal.o
> -obj-$(CONFIG_KIRKWOOD_THERMAL)  += kirkwood_thermal.o
> +obj-$(CONFIG_MVEBU_THERMAL)	+= mvebu_thermal.o
>   obj-$(CONFIG_EXYNOS_THERMAL)	+= exynos_thermal.o
>   obj-$(CONFIG_DOVE_THERMAL)  	+= dove_thermal.o
>   obj-$(CONFIG_DB8500_THERMAL)	+= db8500_thermal.o
> diff --git a/drivers/thermal/kirkwood_thermal.c b/drivers/thermal/kirkwood_thermal.c
> deleted file mode 100644
> index 19320dd..0000000
> --- a/drivers/thermal/kirkwood_thermal.c
> +++ /dev/null
> @@ -1,134 +0,0 @@
> -/*
> - * Kirkwood thermal sensor driver
> - *
> - * Copyright (C) 2012 Nobuhiro Iwamatsu <iwamatsu at nigauri.org>
> - *
> - * This software is licensed under the terms of the GNU General Public
> - * License version 2, as published by the Free Software Foundation, and
> - * may be copied, distributed, and modified under those terms.
> - *
> - * This program is distributed in the hope that it will be useful,
> - * but WITHOUT ANY WARRANTY; without even the implied warranty of
> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> - * GNU General Public License for more details.
> - *
> - */
> -#include <linux/device.h>
> -#include <linux/err.h>
> -#include <linux/io.h>
> -#include <linux/kernel.h>
> -#include <linux/of.h>
> -#include <linux/module.h>
> -#include <linux/platform_device.h>
> -#include <linux/thermal.h>
> -
> -#define KIRKWOOD_THERMAL_VALID_OFFSET	9
> -#define KIRKWOOD_THERMAL_VALID_MASK	0x1
> -#define KIRKWOOD_THERMAL_TEMP_OFFSET	10
> -#define KIRKWOOD_THERMAL_TEMP_MASK	0x1FF
> -
> -/* Kirkwood Thermal Sensor Dev Structure */
> -struct kirkwood_thermal_priv {
> -	void __iomem *sensor;
> -};
> -
> -static int kirkwood_get_temp(struct thermal_zone_device *thermal,
> -			  unsigned long *temp)
> -{
> -	unsigned long reg;
> -	struct kirkwood_thermal_priv *priv = thermal->devdata;
> -
> -	reg = readl_relaxed(priv->sensor);
> -
> -	/* Valid check */
> -	if (!((reg >> KIRKWOOD_THERMAL_VALID_OFFSET) &
> -	    KIRKWOOD_THERMAL_VALID_MASK)) {
> -		dev_err(&thermal->device,
> -			"Temperature sensor reading not valid\n");
> -		return -EIO;
> -	}
> -
> -	/*
> -	 * Calculate temperature. According to Marvell internal
> -	 * documentation the formula for this is:
> -	 * Celsius = (322-reg)/1.3625
> -	 */
> -	reg = (reg >> KIRKWOOD_THERMAL_TEMP_OFFSET) &
> -		KIRKWOOD_THERMAL_TEMP_MASK;
> -	*temp = ((3220000000UL - (10000000UL * reg)) / 13625);
> -
> -	return 0;
> -}
> -
> -static struct thermal_zone_device_ops ops = {
> -	.get_temp = kirkwood_get_temp,
> -};
> -
> -static const struct of_device_id kirkwood_thermal_id_table[] = {
> -	{ .compatible = "marvell,kirkwood-thermal" },
> -	{}
> -};
> -
> -static int kirkwood_thermal_probe(struct platform_device *pdev)
> -{
> -	struct thermal_zone_device *thermal = NULL;
> -	struct kirkwood_thermal_priv *priv;
> -	struct resource *res;
> -
> -	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> -	if (!res) {
> -		dev_err(&pdev->dev, "Failed to get platform resource\n");
> -		return -ENODEV;
> -	}
> -
> -	priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
> -	if (!priv)
> -		return -ENOMEM;
> -
> -	priv->sensor = devm_request_and_ioremap(&pdev->dev, res);
> -	if (!priv->sensor) {
> -		dev_err(&pdev->dev, "Failed to request_ioremap memory\n");
> -		return -EADDRNOTAVAIL;
> -	}
> -
> -	thermal = thermal_zone_device_register("kirkwood_thermal", 0, 0,
> -					       priv, &ops, NULL, 0, 0);
> -	if (IS_ERR(thermal)) {
> -		dev_err(&pdev->dev,
> -			"Failed to register thermal zone device\n");
> -		return PTR_ERR(thermal);
> -	}
> -
> -	platform_set_drvdata(pdev, thermal);
> -
> -	return 0;
> -}
> -
> -static int kirkwood_thermal_exit(struct platform_device *pdev)
> -{
> -	struct thermal_zone_device *kirkwood_thermal =
> -		platform_get_drvdata(pdev);
> -
> -	thermal_zone_device_unregister(kirkwood_thermal);
> -	platform_set_drvdata(pdev, NULL);
> -
> -	return 0;
> -}
> -
> -MODULE_DEVICE_TABLE(of, kirkwood_thermal_id_table);
> -
> -static struct platform_driver kirkwood_thermal_driver = {
> -	.probe = kirkwood_thermal_probe,
> -	.remove = kirkwood_thermal_exit,
> -	.driver = {
> -		.name = "kirkwood_thermal",
> -		.owner = THIS_MODULE,
> -		.of_match_table = of_match_ptr(kirkwood_thermal_id_table),
> -	},
> -};
> -
> -module_platform_driver(kirkwood_thermal_driver);
> -
> -MODULE_AUTHOR("Nobuhiro Iwamatsu <iwamatsu at nigauri.org>");
> -MODULE_DESCRIPTION("kirkwood thermal driver");
> -MODULE_LICENSE("GPL");
> diff --git a/drivers/thermal/mvebu_thermal.c b/drivers/thermal/mvebu_thermal.c
> new file mode 100644
> index 0000000..19320dd
> --- /dev/null
> +++ b/drivers/thermal/mvebu_thermal.c
> @@ -0,0 +1,134 @@
> +/*
> + * Kirkwood thermal sensor driver
> + *
> + * Copyright (C) 2012 Nobuhiro Iwamatsu <iwamatsu at nigauri.org>
> + *
> + * This software is licensed under the terms of the GNU General Public
> + * License version 2, as published by the Free Software Foundation, and
> + * may be copied, distributed, and modified under those terms.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + */
> +#include <linux/device.h>
> +#include <linux/err.h>
> +#include <linux/io.h>
> +#include <linux/kernel.h>
> +#include <linux/of.h>
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/thermal.h>
> +
> +#define KIRKWOOD_THERMAL_VALID_OFFSET	9
> +#define KIRKWOOD_THERMAL_VALID_MASK	0x1
> +#define KIRKWOOD_THERMAL_TEMP_OFFSET	10
> +#define KIRKWOOD_THERMAL_TEMP_MASK	0x1FF
> +
> +/* Kirkwood Thermal Sensor Dev Structure */
> +struct kirkwood_thermal_priv {
> +	void __iomem *sensor;
> +};
> +
> +static int kirkwood_get_temp(struct thermal_zone_device *thermal,
> +			  unsigned long *temp)
> +{
> +	unsigned long reg;
> +	struct kirkwood_thermal_priv *priv = thermal->devdata;
> +
> +	reg = readl_relaxed(priv->sensor);
> +
> +	/* Valid check */
> +	if (!((reg >> KIRKWOOD_THERMAL_VALID_OFFSET) &
> +	    KIRKWOOD_THERMAL_VALID_MASK)) {
> +		dev_err(&thermal->device,
> +			"Temperature sensor reading not valid\n");
> +		return -EIO;
> +	}
> +
> +	/*
> +	 * Calculate temperature. According to Marvell internal
> +	 * documentation the formula for this is:
> +	 * Celsius = (322-reg)/1.3625
> +	 */
> +	reg = (reg >> KIRKWOOD_THERMAL_TEMP_OFFSET) &
> +		KIRKWOOD_THERMAL_TEMP_MASK;
> +	*temp = ((3220000000UL - (10000000UL * reg)) / 13625);
> +
> +	return 0;
> +}
> +
> +static struct thermal_zone_device_ops ops = {
> +	.get_temp = kirkwood_get_temp,
> +};
> +
> +static const struct of_device_id kirkwood_thermal_id_table[] = {
> +	{ .compatible = "marvell,kirkwood-thermal" },
> +	{}
> +};
> +
> +static int kirkwood_thermal_probe(struct platform_device *pdev)
> +{
> +	struct thermal_zone_device *thermal = NULL;
> +	struct kirkwood_thermal_priv *priv;
> +	struct resource *res;
> +
> +	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +	if (!res) {
> +		dev_err(&pdev->dev, "Failed to get platform resource\n");
> +		return -ENODEV;
> +	}
> +
> +	priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
> +	if (!priv)
> +		return -ENOMEM;
> +
> +	priv->sensor = devm_request_and_ioremap(&pdev->dev, res);
> +	if (!priv->sensor) {
> +		dev_err(&pdev->dev, "Failed to request_ioremap memory\n");
> +		return -EADDRNOTAVAIL;
> +	}
> +
> +	thermal = thermal_zone_device_register("kirkwood_thermal", 0, 0,
> +					       priv, &ops, NULL, 0, 0);
> +	if (IS_ERR(thermal)) {
> +		dev_err(&pdev->dev,
> +			"Failed to register thermal zone device\n");
> +		return PTR_ERR(thermal);
> +	}
> +
> +	platform_set_drvdata(pdev, thermal);
> +
> +	return 0;
> +}
> +
> +static int kirkwood_thermal_exit(struct platform_device *pdev)
> +{
> +	struct thermal_zone_device *kirkwood_thermal =
> +		platform_get_drvdata(pdev);
> +
> +	thermal_zone_device_unregister(kirkwood_thermal);
> +	platform_set_drvdata(pdev, NULL);
> +
> +	return 0;
> +}
> +
> +MODULE_DEVICE_TABLE(of, kirkwood_thermal_id_table);
> +
> +static struct platform_driver kirkwood_thermal_driver = {
> +	.probe = kirkwood_thermal_probe,
> +	.remove = kirkwood_thermal_exit,
> +	.driver = {
> +		.name = "kirkwood_thermal",
> +		.owner = THIS_MODULE,
> +		.of_match_table = of_match_ptr(kirkwood_thermal_id_table),
> +	},
> +};
> +
> +module_platform_driver(kirkwood_thermal_driver);
> +
> +MODULE_AUTHOR("Nobuhiro Iwamatsu <iwamatsu at nigauri.org>");
> +MODULE_DESCRIPTION("kirkwood thermal driver");
> +MODULE_LICENSE("GPL");
>



From w at 1wt.eu  Thu Apr 11 12:02:58 2013
From: w at 1wt.eu (Willy Tarreau)
Date: Thu, 11 Apr 2013 18:02:58 +0200
Subject: [PATCH] net: mv643xx_eth: Add GRO support
In-Reply-To: <1365695675.3887.165.camel@edumazet-glaptop>
References: <1365684023-9967-1-git-send-email-sebastian.hesselbarth@gmail.com>
 <20130411131333.GD1910@1wt.eu>
 <CABJ1b_TQDabT1J7ffo5cb1Th=71bcSduifMJaDpfVRiiHvtWDw@mail.gmail.com>
 <20130411150326.GA19978@1wt.eu>
 <CABJ1b_TRxm97DKJLP_h0VwMJvcYmSpjoJvtg1KvBNGah=VzqMQ@mail.gmail.com>
 <20130411153256.GH1910@1wt.eu> <1365695675.3887.165.camel@edumazet-glaptop>
Message-ID: <20130411160258.GI1910@1wt.eu>

On Thu, Apr 11, 2013 at 08:54:35AM -0700, Eric Dumazet wrote:
> On Thu, 2013-04-11 at 17:32 +0200, Willy Tarreau wrote:
> > On Thu, Apr 11, 2013 at 05:27:03PM +0200, Sebastian Hesselbarth wrote:
> > > I don't have a strong opinion on whether Soeren's or your proposal should
> > > be submitted. But I insist on having one of them in, as GRO significantly
> > > improves the common use case, is enabled by default, and not as
> > > constrained as LRO.
> > 
> > I agree, use yours first, but we should keep an eye on this. Since you have
> > everything to run a test, please try to see if you can get netperf to run
> > over IPv6, I'm sure the NIC doesn't handle it.
> 
> Willy, testing the checksum in the NIC driver itself prevents the stack
> doing GRO even if the NIC could not checksum the packet, as in GRE
> tunneling for example.
> 
> So Sebastien patch is better IMHO : Just call the napi gro handler and
> let core stack handles the details ;)

OK, that makes sense indeed, I didn't think about this case. All
I remember was that the old call achieved a higher packet rate
than napi_gro_receive, but it was on an older kernel and I can't
be more specifics after several months :-/

Cheers,
Willy



From swarren at wwwdotorg.org  Thu Apr 11 12:06:49 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Thu, 11 Apr 2013 10:06:49 -0600
Subject: [PATCH V2] video: implement a simple framebuffer driver
In-Reply-To: <2569832.XQDrhUGNaI@avalon>
References: <1365043183-28905-1-git-send-email-swarren@wwwdotorg.org>
 <20130408171637.98b5ad1f867bcbda883af68b@linux-foundation.org>
 <2569832.XQDrhUGNaI@avalon>
Message-ID: <5166DF99.2000308@wwwdotorg.org>

On 04/11/2013 03:56 AM, Laurent Pinchart wrote:
> On Monday 08 April 2013 17:16:37 Andrew Morton wrote:
>> On Wed,  3 Apr 2013 20:39:43 -0600 Stephen Warren wrote:
>>> A simple frame-buffer describes a raw memory region that may be rendered
>>> to, with the assumption that the display hardware has already been set
>>> up to scan out from that buffer.
>>>
>>> This is useful in cases where a bootloader exists and has set up the
>>> display hardware, but a Linux driver doesn't yet exist for the display
>>> hardware.
>>>
>>> ...
>>>
>>> +config FB_SIMPLE
>>> +	bool "Simple framebuffer support"
>>> +	depends on (FB = y) && OF
>>
>> It's sad that this simple little thing requires Open Firmware.  Could
>> it be generalised in some way so that the small amount of setup info
>> could be provided by other means (eg, module_param) or does the
>> dependency go deeper than that?
> 
> I second that request. I like the idea of a simple framebuffer driver if it 
> helps deprecating fbdev in the long term, but I don't want it to offer an 
> excuse not to implement a DRM/KMS driver. In particular adding DT bindings 
> would force us to keep supporting the ABI for a (too) long time.

The platforms I intend to use this with only support device tree. Adding
support for platform data right now would just be dead code. If somebody
wants to use this driver with a board file based system rather than a DT
based system, it would be trivial do modify the driver to add a platform
data structure at that time.

Adding support for a platform data structure won't remove the need for
DT support in the driver; any platform that uses DT will always
configure this driver through the DT binding irrespective of whether
some other platform could configure it using platform_data.

I don't believe the DT bindings imply that they must be implemented by
an FB driver rather than a KMS driver. It's just that it's much simpler
to do so at present. If the whole FB subsystem goes away at some time,
it should be possible to implement a simplest-possible KMS driver that
supports the same DT binding. I didn't do it this way because supporting
a pre-allocated FB in DRM/KMS apparently means implementing a custom
memory allocator for this in the driver, which would be a lot of code
overhead when right now the driver can just use the FB subsystem and
simply return the address directly. The simplest possible FB driver
appears much simpler (less code size, less maintenance) than the
simplest possible KMS driver.

My inclination is that for many platforms, the bootloader support for
graphics output will appear first (before the kernel's), and this driver
will allow for the kernel to have a graphical console, allowing a more
complete/useful system to be available earlier. In many cases, that
window may be small; a DRM/KMS driver may appear soon after the basic
CPU/board/... support, and then people can switch to using it if they want.

That said, I also don't really see a problem not implementing a DRM/KMS
driver for a platform; a dumb frame-buffer works perfectly well for my
needs. Nobody would be forced to continue using it once a better
alternative existed.


From swarren at wwwdotorg.org  Thu Apr 11 12:10:09 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Thu, 11 Apr 2013 10:10:09 -0600
Subject: [PATCH V2] video: implement a simple framebuffer driver
In-Reply-To: <CAMuHMdWFVi=AFR8prins0mees4BFUUXirCC2swyQPwGs7Tt8uQ@mail.gmail.com>
References: <1365043183-28905-1-git-send-email-swarren@wwwdotorg.org>
 <CAMuHMdWFVi=AFR8prins0mees4BFUUXirCC2swyQPwGs7Tt8uQ@mail.gmail.com>
Message-ID: <5166E061.1050008@wwwdotorg.org>

On 04/11/2013 04:42 AM, Geert Uytterhoeven wrote:
> On Thu, Apr 4, 2013 at 4:39 AM, Stephen Warren <swarren at wwwdotorg.org> wrote:
>> +       { "r5g6b5", 16, {11, 5}, {5, 6}, {0, 5}, {0, 0} },
> 
> Why "r5g6b5" instead of "rgb565", which is what's commonly used?

Both representations appear commonly used.

I mentioned my rationale in response to V1: "r5g6b5" is a much more
well-defined structure. It's directly algorithmically parse-able if
required, whereas you'd need somewhat more complex heuristics to
determine exactly what rgb565 or argb2101010 mean, since all the numbers
are run together without delimiters.


From eric.dumazet at gmail.com  Thu Apr 11 12:10:44 2013
From: eric.dumazet at gmail.com (Eric Dumazet)
Date: Thu, 11 Apr 2013 09:10:44 -0700
Subject: [PATCH] net: mv643xx_eth: Add GRO support
In-Reply-To: <20130411160258.GI1910@1wt.eu>
References: <1365684023-9967-1-git-send-email-sebastian.hesselbarth@gmail.com>
 <20130411131333.GD1910@1wt.eu>
 <CABJ1b_TQDabT1J7ffo5cb1Th=71bcSduifMJaDpfVRiiHvtWDw@mail.gmail.com>
 <20130411150326.GA19978@1wt.eu>
 <CABJ1b_TRxm97DKJLP_h0VwMJvcYmSpjoJvtg1KvBNGah=VzqMQ@mail.gmail.com>
 <20130411153256.GH1910@1wt.eu> <1365695675.3887.165.camel@edumazet-glaptop>
 <20130411160258.GI1910@1wt.eu>
Message-ID: <1365696644.3887.172.camel@edumazet-glaptop>

On Thu, 2013-04-11 at 18:02 +0200, Willy Tarreau wrote:

> OK, that makes sense indeed, I didn't think about this case. All
> I remember was that the old call achieved a higher packet rate
> than napi_gro_receive, but it was on an older kernel and I can't
> be more specifics after several months :-/

Its probably true that the GRO handler consumes more cpu for packets
that cant be aggregated in the end.

Thats a trade off, and maybe we could add in the core stack a device
feature to instruct gro handler to do a short cut for packets with no
checksum. Or better a sysctl so that a static_branch can be used.





From swarren at wwwdotorg.org  Thu Apr 11 12:17:46 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Thu, 11 Apr 2013 10:17:46 -0600
Subject: [PATCH] ARM: tegra: Add charger subnode to tps65090 node
In-Reply-To: <5166D907.6060004@nvidia.com>
References: <1365623505-6309-1-git-send-email-rklein@nvidia.com>
 <5165E80D.7050106@wwwdotorg.org> <5166D907.6060004@nvidia.com>
Message-ID: <5166E22A.9010401@wwwdotorg.org>

On 04/11/2013 09:38 AM, Rhyland Klein wrote:
> On 4/10/2013 6:30 PM, Stephen Warren wrote:
>> On 04/10/2013 01:51 PM, Rhyland Klein wrote:
>>> The charger is now represented by a distinct subnode of the tps65090
>>> device. Add this node and enable low current charging with it.
>>
>>> diff --git a/arch/arm/boot/dts/tegra114-dalmore.dts b/arch/arm/boot/dts/tegra114-dalmore.dts
>>
>>> +			charger {
>>> +				compatible = "ti,tps65090-charger";
>>> +				ti,enable-low-current-chrg;
>>
>> So does the TPS65090 driver scan all its sub-nodes like a bus an
>> instantiate anything? That's a little odd since the regulators node is
>> at the same level, yet doesn't represent a device on that same internal
>> bus...
>>
> 
> It doesn't scan so much as have a list of subdev's it tries to register.
> The charger node uses the of_compatible string defined (in the tps65090
> driver and the charger driver) to match the subnode to the mfd_cell
> device for the charger.

That sounds very odd. If the main driver hard-codes the list of children
it expects, there's no point using compatible for the children. Using a
bus-structure and compatible values would only be appropriate when the
top-level driver is generic, and simply scans all its children as a
generic bus, without having any idea what's there.

> The regulators are currently under a different
> subdevice which is not using the of_compatible string. I was planning on
> a follow up patch series to update the tps65090-regulator driver to use
> the dt type approach with a subnode to be consistent.

But that's changing the DT bindings. That shouldn't be done.


From eduardo.valentin at ti.com  Thu Apr 11 12:18:35 2013
From: eduardo.valentin at ti.com (Eduardo Valentin)
Date: Thu, 11 Apr 2013 12:18:35 -0400
Subject: [v2,02/14] thermal: mvebu: Rename symbols 'kirkwood' -> 'mvebu'
In-Reply-To: <1363991114-4225-3-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1363991114-4225-3-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <5166E25B.7070307@ti.com>

On 22-03-2013 18:25, Ezequiel Garcia wrote:
> This driver will be used to support Marvell EBU SoC thermal
> sensors. Therefore, we change every symbol and comment
> accordingly, before we make any functionality change.
>
> Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>

Rui,

This patch looks fine to me. You can add my:

Acked-by: Eduardo Valentin <eduardo.valentin at ti.com>

>
> ---
> drivers/thermal/mvebu_thermal.c |   42 +++++++++++++++++++-------------------
>   1 files changed, 21 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/thermal/mvebu_thermal.c b/drivers/thermal/mvebu_thermal.c
> index 19320dd..9ba9e4d 100644
> --- a/drivers/thermal/mvebu_thermal.c
> +++ b/drivers/thermal/mvebu_thermal.c
> @@ -1,5 +1,5 @@
>   /*
> - * Kirkwood thermal sensor driver
> + * Marvell EBU thermal sensor driver
>    *
>    * Copyright (C) 2012 Nobuhiro Iwamatsu <iwamatsu at nigauri.org>
>    *
> @@ -27,16 +27,16 @@
>   #define KIRKWOOD_THERMAL_TEMP_OFFSET	10
>   #define KIRKWOOD_THERMAL_TEMP_MASK	0x1FF
>
> -/* Kirkwood Thermal Sensor Dev Structure */
> -struct kirkwood_thermal_priv {
> +/* Marvell EBU Thermal Sensor Dev Structure */
> +struct mvebu_thermal_priv {
>   	void __iomem *sensor;
>   };
>
> -static int kirkwood_get_temp(struct thermal_zone_device *thermal,
> +static int mvebu_get_temp(struct thermal_zone_device *thermal,
>   			  unsigned long *temp)
>   {
>   	unsigned long reg;
> -	struct kirkwood_thermal_priv *priv = thermal->devdata;
> +	struct mvebu_thermal_priv *priv = thermal->devdata;
>
>   	reg = readl_relaxed(priv->sensor);
>
> @@ -61,18 +61,18 @@ static int kirkwood_get_temp(struct thermal_zone_device *thermal,
>   }
>
>   static struct thermal_zone_device_ops ops = {
> -	.get_temp = kirkwood_get_temp,
> +	.get_temp = mvebu_get_temp,
>   };
>
> -static const struct of_device_id kirkwood_thermal_id_table[] = {
> +static const struct of_device_id mvebu_thermal_id_table[] = {
>   	{ .compatible = "marvell,kirkwood-thermal" },

The device tree node will still be kept kirkwood?

>   	{}
>   };
>
> -static int kirkwood_thermal_probe(struct platform_device *pdev)
> +static int mvebu_thermal_probe(struct platform_device *pdev)
>   {
>   	struct thermal_zone_device *thermal = NULL;
> -	struct kirkwood_thermal_priv *priv;
> +	struct mvebu_thermal_priv *priv;
>   	struct resource *res;
>
>   	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> @@ -91,7 +91,7 @@ static int kirkwood_thermal_probe(struct platform_device *pdev)
>   		return -EADDRNOTAVAIL;
>   	}
>
> -	thermal = thermal_zone_device_register("kirkwood_thermal", 0, 0,
> +	thermal = thermal_zone_device_register("mvebu_thermal", 0, 0,
>   					       priv, &ops, NULL, 0, 0);
>   	if (IS_ERR(thermal)) {
>   		dev_err(&pdev->dev,
> @@ -104,31 +104,31 @@ static int kirkwood_thermal_probe(struct platform_device *pdev)
>   	return 0;
>   }
>
> -static int kirkwood_thermal_exit(struct platform_device *pdev)
> +static int mvebu_thermal_exit(struct platform_device *pdev)
>   {
> -	struct thermal_zone_device *kirkwood_thermal =
> +	struct thermal_zone_device *mvebu_thermal =
>   		platform_get_drvdata(pdev);
>
> -	thermal_zone_device_unregister(kirkwood_thermal);
> +	thermal_zone_device_unregister(mvebu_thermal);
>   	platform_set_drvdata(pdev, NULL);
>
>   	return 0;
>   }
>
> -MODULE_DEVICE_TABLE(of, kirkwood_thermal_id_table);
> +MODULE_DEVICE_TABLE(of, mvebu_thermal_id_table);
>
> -static struct platform_driver kirkwood_thermal_driver = {
> -	.probe = kirkwood_thermal_probe,
> -	.remove = kirkwood_thermal_exit,
> +static struct platform_driver mvebu_thermal_driver = {
> +	.probe = mvebu_thermal_probe,
> +	.remove = mvebu_thermal_exit,
>   	.driver = {
> -		.name = "kirkwood_thermal",
> +		.name = "mvebu_thermal",
>   		.owner = THIS_MODULE,
> -		.of_match_table = of_match_ptr(kirkwood_thermal_id_table),
> +		.of_match_table = of_match_ptr(mvebu_thermal_id_table),
>   	},
>   };
>
> -module_platform_driver(kirkwood_thermal_driver);
> +module_platform_driver(mvebu_thermal_driver);
>
>   MODULE_AUTHOR("Nobuhiro Iwamatsu <iwamatsu at nigauri.org>");
> -MODULE_DESCRIPTION("kirkwood thermal driver");
> +MODULE_DESCRIPTION("mvebu thermal driver");
>   MODULE_LICENSE("GPL");
>



From swarren at wwwdotorg.org  Thu Apr 11 12:19:21 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Thu, 11 Apr 2013 10:19:21 -0600
Subject: Kexec couldn't reboot capture kernel on pandaboard ES with
 OMAP4460
In-Reply-To: <CAFNq8R6mRJRygfnYvZgwVWOqsrhrjNUYzyZGU0cVsnE30W_xGg@mail.gmail.com>
References: <CAFNq8R5FFUyH+JgjoGc5ctgEfiLvxzi7fzawM7+wFX5nEyTv-w@mail.gmail.com>
 <51658B1A.6090706@wwwdotorg.org>
 <CAFNq8R6mRJRygfnYvZgwVWOqsrhrjNUYzyZGU0cVsnE30W_xGg@mail.gmail.com>
Message-ID: <5166E289.8070104@wwwdotorg.org>

On 04/10/2013 10:46 PM, Li Haifeng wrote:
> 2013/4/10 Stephen Warren <swarren at wwwdotorg.org>:
>> On 04/10/2013 03:35 AM, Li Haifeng wrote:
>>> Hi, everyone.
>>>
>>> Recently, I try to run kdump on pandaboard ES with omap4460. After
>>> load capture kernel by "kexec -l" and execute "kexec -e", the serial
>>> port output "Starting new kernel" and "Bye", then the system hangs up.
>>>
>>> I have tried the upstream Linux Kernel v3.4 and v3.8. All are with this issue.
>>
>> This is a shot in the dark. I assume you have SMP enabled. Can you use
>> hotplug to remove all CPUs other than CPU0, so that the kexec happens on
>> the boot CPU? That is certainly necessary for kexec to work correctly on
>> Tegra.
> 
> Thanks for your attention.
> 
> I do disable SMP feature. And the .config file for v3.8 could be found here:
> http://pastehtml.com/view/cylyrfejt.txt
...
> The output:
> [   57.373687] Starting new kernel
> [   57.377044] Bye!
> 
> Then system hangs.

Oh well, you've exhausted my knowledge I'm afraid! I can only suggesting
trying to enable earlyprintk and/or uncompressor debug in the kernel
you're kexec'ing and see if that yields any clue. Either that, or JTAG!


From eduardo.valentin at ti.com  Thu Apr 11 12:21:50 2013
From: eduardo.valentin at ti.com (Eduardo Valentin)
Date: Thu, 11 Apr 2013 12:21:50 -0400
Subject: [v2,01/14] thermal: Rename driver 'kirkwood' -> 'mvebu'
In-Reply-To: <1363991114-4225-2-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1363991114-4225-2-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <5166E31E.9070305@ti.com>

Ezequiel,


On 22-03-2013 18:25, Ezequiel Garcia wrote:
> This driver will support several Marvell SoC, so it is convenient
> to rename it to 'mvebu' to represent accurately the hardware it
> supports.
>
> Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
>
> ---
> .../bindings/thermal/kirkwood-thermal.txt          |   15 ---
>   .../devicetree/bindings/thermal/mvebu-thermal.txt  |   15 +++
>   drivers/thermal/Kconfig                            |   10 +-
>   drivers/thermal/Makefile                           |    2 +-
>   drivers/thermal/kirkwood_thermal.c                 |  134 --------------------
>   drivers/thermal/mvebu_thermal.c                    |  134 ++++++++++++++++++++
>   6 files changed, 155 insertions(+), 155 deletions(-)
>   delete mode 100644 Documentation/devicetree/bindings/thermal/kirkwood-thermal.txt
>   create mode 100644 Documentation/devicetree/bindings/thermal/mvebu-thermal.txt
>   delete mode 100644 drivers/thermal/kirkwood_thermal.c
>   create mode 100644 drivers/thermal/mvebu_thermal.c
>
> diff --git a/Documentation/devicetree/bindings/thermal/kirkwood-thermal.txt b/Documentation/devicetree/bindings/thermal/kirkwood-thermal.txt
> deleted file mode 100644
> index 8c0f5eb..0000000
> --- a/Documentation/devicetree/bindings/thermal/kirkwood-thermal.txt
> +++ /dev/null
> @@ -1,15 +0,0 @@
> -* Kirkwood Thermal
> -
> -This version is for Kirkwood 88F8262 & 88F6283 SoCs. Other kirkwoods
> -don't contain a thermal sensor.
> -
> -Required properties:
> -- compatible : "marvell,kirkwood-thermal"
> -- reg : Address range of the thermal registers
> -
> -Example:
> -
> -	thermal at 10078 {
> -		compatible = "marvell,kirkwood-thermal";
> -		reg = <0x10078 0x4>;
> -	};
> diff --git a/Documentation/devicetree/bindings/thermal/mvebu-thermal.txt b/Documentation/devicetree/bindings/thermal/mvebu-thermal.txt
> new file mode 100644
> index 0000000..8c0f5eb
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/thermal/mvebu-thermal.txt
> @@ -0,0 +1,15 @@
> +* Kirkwood Thermal
> +
> +This version is for Kirkwood 88F8262 & 88F6283 SoCs. Other kirkwoods
> +don't contain a thermal sensor.
> +
> +Required properties:
> +- compatible : "marvell,kirkwood-thermal"
> +- reg : Address range of the thermal registers
> +
> +Example:
> +
> +	thermal at 10078 {
> +		compatible = "marvell,kirkwood-thermal";
> +		reg = <0x10078 0x4>;
> +	};
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> index a764f16..74f6b97 100644
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -101,13 +101,13 @@ config RCAR_THERMAL
>   	  Enable this to plug the R-Car thermal sensor driver into the Linux
>   	  thermal framework
>
> -config KIRKWOOD_THERMAL
> -	tristate "Temperature sensor on Marvell Kirkwood SoCs"
> -	depends on ARCH_KIRKWOOD
> +config MVEBU_THERMAL
> +	tristate "Temperature sensor on Marvell EBU SoCs"
> +	depends on PLAT_ORION
>   	depends on OF
>   	help
> -	  Support for the Kirkwood thermal sensor driver into the Linux thermal
> -	  framework. Only kirkwood 88F6282 and 88F6283 have this sensor.
> +	  Support for the thermal controllers available in several Marvell
> +	  EBU SoCs in the thermal framework.

While here, could you please be more descriptive?
WARNING: please write a paragraph that describes the config symbol fully
#90: FILE: drivers/thermal/Kconfig:104:
+config MVEBU_THERMAL

total: 0 errors, 1 warnings, 175 lines checked

v2-01-14-thermal-Rename-driver-kirkwood---mvebu.patch has style 
problems, please review.

If any of these errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.


>
>   config EXYNOS_THERMAL
>   	tristate "Temperature sensor on Samsung EXYNOS"
> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
> index d3a2b38..40293a1 100644
> --- a/drivers/thermal/Makefile
> +++ b/drivers/thermal/Makefile
> @@ -15,7 +15,7 @@ obj-$(CONFIG_CPU_THERMAL)	+= cpu_cooling.o
>   # platform thermal drivers
>   obj-$(CONFIG_SPEAR_THERMAL)	+= spear_thermal.o
>   obj-$(CONFIG_RCAR_THERMAL)	+= rcar_thermal.o
> -obj-$(CONFIG_KIRKWOOD_THERMAL)  += kirkwood_thermal.o
> +obj-$(CONFIG_MVEBU_THERMAL)	+= mvebu_thermal.o
>   obj-$(CONFIG_EXYNOS_THERMAL)	+= exynos_thermal.o
>   obj-$(CONFIG_DOVE_THERMAL)  	+= dove_thermal.o
>   obj-$(CONFIG_DB8500_THERMAL)	+= db8500_thermal.o
> diff --git a/drivers/thermal/kirkwood_thermal.c b/drivers/thermal/kirkwood_thermal.c
> deleted file mode 100644
> index 19320dd..0000000
> --- a/drivers/thermal/kirkwood_thermal.c
> +++ /dev/null
> @@ -1,134 +0,0 @@
> -/*
> - * Kirkwood thermal sensor driver
> - *
> - * Copyright (C) 2012 Nobuhiro Iwamatsu <iwamatsu at nigauri.org>
> - *
> - * This software is licensed under the terms of the GNU General Public
> - * License version 2, as published by the Free Software Foundation, and
> - * may be copied, distributed, and modified under those terms.
> - *
> - * This program is distributed in the hope that it will be useful,
> - * but WITHOUT ANY WARRANTY; without even the implied warranty of
> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> - * GNU General Public License for more details.
> - *
> - */
> -#include <linux/device.h>
> -#include <linux/err.h>
> -#include <linux/io.h>
> -#include <linux/kernel.h>
> -#include <linux/of.h>
> -#include <linux/module.h>
> -#include <linux/platform_device.h>
> -#include <linux/thermal.h>
> -
> -#define KIRKWOOD_THERMAL_VALID_OFFSET	9
> -#define KIRKWOOD_THERMAL_VALID_MASK	0x1
> -#define KIRKWOOD_THERMAL_TEMP_OFFSET	10
> -#define KIRKWOOD_THERMAL_TEMP_MASK	0x1FF
> -
> -/* Kirkwood Thermal Sensor Dev Structure */
> -struct kirkwood_thermal_priv {
> -	void __iomem *sensor;
> -};
> -
> -static int kirkwood_get_temp(struct thermal_zone_device *thermal,
> -			  unsigned long *temp)
> -{
> -	unsigned long reg;
> -	struct kirkwood_thermal_priv *priv = thermal->devdata;
> -
> -	reg = readl_relaxed(priv->sensor);
> -
> -	/* Valid check */
> -	if (!((reg >> KIRKWOOD_THERMAL_VALID_OFFSET) &
> -	    KIRKWOOD_THERMAL_VALID_MASK)) {
> -		dev_err(&thermal->device,
> -			"Temperature sensor reading not valid\n");
> -		return -EIO;
> -	}
> -
> -	/*
> -	 * Calculate temperature. According to Marvell internal
> -	 * documentation the formula for this is:
> -	 * Celsius = (322-reg)/1.3625
> -	 */
> -	reg = (reg >> KIRKWOOD_THERMAL_TEMP_OFFSET) &
> -		KIRKWOOD_THERMAL_TEMP_MASK;
> -	*temp = ((3220000000UL - (10000000UL * reg)) / 13625);
> -
> -	return 0;
> -}
> -
> -static struct thermal_zone_device_ops ops = {
> -	.get_temp = kirkwood_get_temp,
> -};
> -
> -static const struct of_device_id kirkwood_thermal_id_table[] = {
> -	{ .compatible = "marvell,kirkwood-thermal" },
> -	{}
> -};
> -
> -static int kirkwood_thermal_probe(struct platform_device *pdev)
> -{
> -	struct thermal_zone_device *thermal = NULL;
> -	struct kirkwood_thermal_priv *priv;
> -	struct resource *res;
> -
> -	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> -	if (!res) {
> -		dev_err(&pdev->dev, "Failed to get platform resource\n");
> -		return -ENODEV;
> -	}
> -
> -	priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
> -	if (!priv)
> -		return -ENOMEM;
> -
> -	priv->sensor = devm_request_and_ioremap(&pdev->dev, res);
> -	if (!priv->sensor) {
> -		dev_err(&pdev->dev, "Failed to request_ioremap memory\n");
> -		return -EADDRNOTAVAIL;
> -	}
> -
> -	thermal = thermal_zone_device_register("kirkwood_thermal", 0, 0,
> -					       priv, &ops, NULL, 0, 0);
> -	if (IS_ERR(thermal)) {
> -		dev_err(&pdev->dev,
> -			"Failed to register thermal zone device\n");
> -		return PTR_ERR(thermal);
> -	}
> -
> -	platform_set_drvdata(pdev, thermal);
> -
> -	return 0;
> -}
> -
> -static int kirkwood_thermal_exit(struct platform_device *pdev)
> -{
> -	struct thermal_zone_device *kirkwood_thermal =
> -		platform_get_drvdata(pdev);
> -
> -	thermal_zone_device_unregister(kirkwood_thermal);
> -	platform_set_drvdata(pdev, NULL);
> -
> -	return 0;
> -}
> -
> -MODULE_DEVICE_TABLE(of, kirkwood_thermal_id_table);
> -
> -static struct platform_driver kirkwood_thermal_driver = {
> -	.probe = kirkwood_thermal_probe,
> -	.remove = kirkwood_thermal_exit,
> -	.driver = {
> -		.name = "kirkwood_thermal",
> -		.owner = THIS_MODULE,
> -		.of_match_table = of_match_ptr(kirkwood_thermal_id_table),
> -	},
> -};
> -
> -module_platform_driver(kirkwood_thermal_driver);
> -
> -MODULE_AUTHOR("Nobuhiro Iwamatsu <iwamatsu at nigauri.org>");
> -MODULE_DESCRIPTION("kirkwood thermal driver");
> -MODULE_LICENSE("GPL");
> diff --git a/drivers/thermal/mvebu_thermal.c b/drivers/thermal/mvebu_thermal.c
> new file mode 100644
> index 0000000..19320dd
> --- /dev/null
> +++ b/drivers/thermal/mvebu_thermal.c
> @@ -0,0 +1,134 @@
> +/*
> + * Kirkwood thermal sensor driver
> + *
> + * Copyright (C) 2012 Nobuhiro Iwamatsu <iwamatsu at nigauri.org>
> + *
> + * This software is licensed under the terms of the GNU General Public
> + * License version 2, as published by the Free Software Foundation, and
> + * may be copied, distributed, and modified under those terms.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + */
> +#include <linux/device.h>
> +#include <linux/err.h>
> +#include <linux/io.h>
> +#include <linux/kernel.h>
> +#include <linux/of.h>
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/thermal.h>
> +
> +#define KIRKWOOD_THERMAL_VALID_OFFSET	9
> +#define KIRKWOOD_THERMAL_VALID_MASK	0x1
> +#define KIRKWOOD_THERMAL_TEMP_OFFSET	10
> +#define KIRKWOOD_THERMAL_TEMP_MASK	0x1FF
> +
> +/* Kirkwood Thermal Sensor Dev Structure */
> +struct kirkwood_thermal_priv {
> +	void __iomem *sensor;
> +};
> +
> +static int kirkwood_get_temp(struct thermal_zone_device *thermal,
> +			  unsigned long *temp)
> +{
> +	unsigned long reg;
> +	struct kirkwood_thermal_priv *priv = thermal->devdata;
> +
> +	reg = readl_relaxed(priv->sensor);
> +
> +	/* Valid check */
> +	if (!((reg >> KIRKWOOD_THERMAL_VALID_OFFSET) &
> +	    KIRKWOOD_THERMAL_VALID_MASK)) {
> +		dev_err(&thermal->device,
> +			"Temperature sensor reading not valid\n");
> +		return -EIO;
> +	}
> +
> +	/*
> +	 * Calculate temperature. According to Marvell internal
> +	 * documentation the formula for this is:
> +	 * Celsius = (322-reg)/1.3625
> +	 */
> +	reg = (reg >> KIRKWOOD_THERMAL_TEMP_OFFSET) &
> +		KIRKWOOD_THERMAL_TEMP_MASK;
> +	*temp = ((3220000000UL - (10000000UL * reg)) / 13625);
> +
> +	return 0;
> +}
> +
> +static struct thermal_zone_device_ops ops = {
> +	.get_temp = kirkwood_get_temp,
> +};
> +
> +static const struct of_device_id kirkwood_thermal_id_table[] = {
> +	{ .compatible = "marvell,kirkwood-thermal" },
> +	{}
> +};
> +
> +static int kirkwood_thermal_probe(struct platform_device *pdev)
> +{
> +	struct thermal_zone_device *thermal = NULL;
> +	struct kirkwood_thermal_priv *priv;
> +	struct resource *res;
> +
> +	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +	if (!res) {
> +		dev_err(&pdev->dev, "Failed to get platform resource\n");
> +		return -ENODEV;
> +	}
> +
> +	priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
> +	if (!priv)
> +		return -ENOMEM;
> +
> +	priv->sensor = devm_request_and_ioremap(&pdev->dev, res);
> +	if (!priv->sensor) {
> +		dev_err(&pdev->dev, "Failed to request_ioremap memory\n");
> +		return -EADDRNOTAVAIL;
> +	}
> +
> +	thermal = thermal_zone_device_register("kirkwood_thermal", 0, 0,
> +					       priv, &ops, NULL, 0, 0);
> +	if (IS_ERR(thermal)) {
> +		dev_err(&pdev->dev,
> +			"Failed to register thermal zone device\n");
> +		return PTR_ERR(thermal);
> +	}
> +
> +	platform_set_drvdata(pdev, thermal);
> +
> +	return 0;
> +}
> +
> +static int kirkwood_thermal_exit(struct platform_device *pdev)
> +{
> +	struct thermal_zone_device *kirkwood_thermal =
> +		platform_get_drvdata(pdev);
> +
> +	thermal_zone_device_unregister(kirkwood_thermal);
> +	platform_set_drvdata(pdev, NULL);
> +
> +	return 0;
> +}
> +
> +MODULE_DEVICE_TABLE(of, kirkwood_thermal_id_table);
> +
> +static struct platform_driver kirkwood_thermal_driver = {
> +	.probe = kirkwood_thermal_probe,
> +	.remove = kirkwood_thermal_exit,
> +	.driver = {
> +		.name = "kirkwood_thermal",
> +		.owner = THIS_MODULE,
> +		.of_match_table = of_match_ptr(kirkwood_thermal_id_table),
> +	},
> +};
> +
> +module_platform_driver(kirkwood_thermal_driver);
> +
> +MODULE_AUTHOR("Nobuhiro Iwamatsu <iwamatsu at nigauri.org>");
> +MODULE_DESCRIPTION("kirkwood thermal driver");
> +MODULE_LICENSE("GPL");
>



From gregory.clement at free-electrons.com  Thu Apr 11 12:26:07 2013
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Thu, 11 Apr 2013 18:26:07 +0200
Subject: [PATCH] clk: Add device tree binding to clk-fixed-factor
In-Reply-To: <20130411091952.GF8400@ab42.lan>
References: <1365608443-30350-1-git-send-email-christian.ruppert@abilis.com>
 <51658BA9.7030508@free-electrons.com> <20130410162747.GG32603@ab42.lan>
 <20130411091952.GF8400@ab42.lan>
Message-ID: <5166E41F.7060100@free-electrons.com>

On 04/11/2013 11:19 AM, Christian Ruppert wrote:
> Hi Gregory,
> 
> Since there doesn't seem to be anyone opposing this feature I just
> checked your patch and after adding the CLK_OF_DECLARE macro in the end
> it works well for us. Tell me if you would like to rebase and resubmit
> your patch or if I should follow up on our own.

I can rebase and resubmit my patch, it's pretty straightforward.
The problem was the lack of user in the kernel. And by user I mean
a driver using these functions. Usually a new function enter in the
kernel only if there are users for it inside the kernel so if you plan
to submit a driver using this piece of code, then I see no reason
to not get it.

> 
> Greetings,
>   Christian
> 
> On Wed, Apr 10, 2013 at 06:27:47PM +0200, christian ruppert wrote:
>> Hi Gregory,
>>
>> We use derived clocks with fixed ratios for our TB10x platform. I
>> originally had this in the platform code but Vineet (the platform
>> maintainer) rightly pointed out that the common clock framework would
>> be the correct place for it.
>> Is there any reason not to support this functionality? After all, the
>> generic fixed rate clock also has a device tree binding and I'd guess
>> we're not the only ones statically deriving one clock from another in
>> our SOCs.
>>
>> Greetings,
>>   Christian
>>
>> On Wed, Apr 10, 2013 at 05:56:25PM +0200, Gregory CLEMENT wrote:
>>> Hi Christian,
>>>
>>> On 04/10/2013 05:40 PM, Christian Ruppert wrote:
>>>> This patch adds a device tree binding for the simple fixed factor clock
>>>> divider/multiplier of the common clock tree binding.
>>>
>>> This patch remind me of something :
>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2012-August/116405.html
>>>
>>> Do you have a use case for it, this time?
>>>
>>> My version have been hold off waiting for an user for it.
>>> Will you need it for a driver?
>>>
>>> Regards,
>>>
>>>>
>>>> Signed-off-by: Christian Ruppert <christian.ruppert at abilis.com>
>>>> ---
>>>>  .../bindings/clock/fixed-factor-clkdiv.txt         |   24 +++++++++++++++
>>>>  drivers/clk/clk-fixed-factor.c                     |   32 ++++++++++++++++++++
>>>>  include/linux/clk-provider.h                       |    1 +
>>>>  3 files changed, 57 insertions(+), 0 deletions(-)
>>>>  create mode 100644 Documentation/devicetree/bindings/clock/fixed-factor-clkdiv.txt
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/clock/fixed-factor-clkdiv.txt b/Documentation/devicetree/bindings/clock/fixed-factor-clkdiv.txt
>>>> new file mode 100644
>>>> index 0000000..352bac4
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/clock/fixed-factor-clkdiv.txt
>>>> @@ -0,0 +1,24 @@
>>>> +Device Tree Clock bindings for plat-tb10x
>>>> +
>>>> +This binding uses the common clock binding[1].
>>>> +
>>>> +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
>>>> +
>>>> +Required properties:
>>>> +- compatible : shall be "fixed-factor-clkdiv"
>>>> +- #clock-cells: from common clock binding; shall be set to 0
>>>> +- clocks: shall be the input parent clock phandle for the clock.
>>>> +- clock-mult: defines the multiplication factor of the output clock frequency
>>>> +  wrt. the input clock frequency.
>>>> +- clock-div: defines the division factor of the output clock frequency wrt.
>>>> +  the input clock frequency.
>>>> +
>>>> +Example:
>>>> +cpu_clk: clkdiv_cpu {	/* CPU clock derived from pll0. 1/2 of pll frequency */
>>>> +	compatible = "fixed-factor-clkdiv";
>>>> +	#clock-cells = <0>;
>>>> +	clocks = <&pll0>;
>>>> +	clock-mult = <1>;
>>>> +	clock-div = <2>;
>>>> +	clock-output-names = "cpu_clk";
>>>> +};
>>>> diff --git a/drivers/clk/clk-fixed-factor.c b/drivers/clk/clk-fixed-factor.c
>>>> index 1ef271e..85e45f1 100644
>>>> --- a/drivers/clk/clk-fixed-factor.c
>>>> +++ b/drivers/clk/clk-fixed-factor.c
>>>> @@ -11,6 +11,7 @@
>>>>  #include <linux/clk-provider.h>
>>>>  #include <linux/slab.h>
>>>>  #include <linux/err.h>
>>>> +#include <linux/of.h>
>>>>  
>>>>  /*
>>>>   * DOC: basic fixed multiplier and divider clock that cannot gate
>>>> @@ -96,3 +97,34 @@ struct clk *clk_register_fixed_factor(struct device *dev, const char *name,
>>>>  
>>>>  	return clk;
>>>>  }
>>>> +
>>>> +#ifdef CONFIG_OF
>>>> +/**
>>>> + * of_fixed_factor_clkdiv_setup() - Set up simple fixed factor clock divider
>>>> + */
>>>> +void of_fixed_factor_clkdiv_setup(struct device_node *node)
>>>> +{
>>>> +	struct clk *clk;
>>>> +	const char *clk_name = node->name;
>>>> +	const char *parent_name;
>>>> +	u32 mult, div;
>>>> +
>>>> +	if (of_property_read_u32(node, "clock-mult", &mult))
>>>> +		return;
>>>> +
>>>> +	if (of_property_read_u32(node, "clock-div", &div))
>>>> +		return;
>>>> +
>>>> +	parent_name = of_clk_get_parent_name(node, 0);
>>>> +
>>>> +	of_property_read_string(node, "clock-output-names", &clk_name);
>>>> +
>>>> +	clk = clk_register_fixed_factor(NULL, clk_name, parent_name, 0,
>>>> +					mult, div);
>>>> +	if (!IS_ERR(clk))
>>>> +		of_clk_add_provider(node, of_clk_src_simple_get, clk);
>>>> +}
>>>> +EXPORT_SYMBOL_GPL(of_fixed_factor_clkdiv_setup);
>>>> +CLK_OF_DECLARE(fixed_clkdiv, "fixed-factor-clkdiv",
>>>> +		of_fixed_factor_clkdiv_setup);
>>>> +#endif
>>>> diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
>>>> index 7f197d7..d4937cf 100644
>>>> --- a/include/linux/clk-provider.h
>>>> +++ b/include/linux/clk-provider.h
>>>> @@ -184,6 +184,7 @@ struct clk *clk_register_fixed_rate(struct device *dev, const char *name,
>>>>  		unsigned long fixed_rate);
>>>>  
>>>>  void of_fixed_clk_setup(struct device_node *np);
>>>> +void of_fixed_factor_clkdiv_setup(struct device_node *node);
>>>>  
>>>>  /**
>>>>   * struct clk_gate - gating clock
>>>>
>>>
>>>
>>> -- 
>>> Gregory Clement, Free Electrons
>>> Kernel, drivers, real-time and embedded Linux
>>> development, consulting, training and support.
>>> http://free-electrons.com
>>
>> -- 
>>   Christian Ruppert              ,          <christian.ruppert at abilis.com>
>>                                 /|
>>   Tel: +41/(0)22 816 19-42     //|                 3, Chemin du Pr?-Fleuri
>>                              _// | bilis Systems   CH-1228 Plan-les-Ouates
> 


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From eduardo.valentin at ti.com  Thu Apr 11 12:25:47 2013
From: eduardo.valentin at ti.com (Eduardo Valentin)
Date: Thu, 11 Apr 2013 12:25:47 -0400
Subject: [v2,03/14] thermal: mvebu: Move MODULE_DEVICE_TABLE upwards
In-Reply-To: <1363991114-4225-4-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1363991114-4225-4-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <5166E40B.3060901@ti.com>

Rui,

On 22-03-2013 18:25, Ezequiel Garcia wrote:
> This table will be needed by mvebu_thermal_probe() so we move
> it just below the declaration of the compatible device table.
>
> Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
>

This patch looks fine to me.

Acked-by: Eduardo Valentin <eduardo.valentin at ti.com>

> ---
> drivers/thermal/mvebu_thermal.c |    3 +--
>   1 files changed, 1 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/thermal/mvebu_thermal.c b/drivers/thermal/mvebu_thermal.c
> index 9ba9e4d..031f94d 100644
> --- a/drivers/thermal/mvebu_thermal.c
> +++ b/drivers/thermal/mvebu_thermal.c
> @@ -68,6 +68,7 @@ static const struct of_device_id mvebu_thermal_id_table[] = {
>   	{ .compatible = "marvell,kirkwood-thermal" },
>   	{}
>   };
> +MODULE_DEVICE_TABLE(of, mvebu_thermal_id_table);
>
>   static int mvebu_thermal_probe(struct platform_device *pdev)
>   {
> @@ -115,8 +116,6 @@ static int mvebu_thermal_exit(struct platform_device *pdev)
>   	return 0;
>   }
>
> -MODULE_DEVICE_TABLE(of, mvebu_thermal_id_table);
> -
>   static struct platform_driver mvebu_thermal_driver = {
>   	.probe = mvebu_thermal_probe,
>   	.remove = mvebu_thermal_exit,
>



From rklein at nvidia.com  Thu Apr 11 12:27:35 2013
From: rklein at nvidia.com (Rhyland Klein)
Date: Thu, 11 Apr 2013 12:27:35 -0400
Subject: [PATCH] ARM: tegra: Add charger subnode to tps65090 node
In-Reply-To: <5166E22A.9010401@wwwdotorg.org>
References: <1365623505-6309-1-git-send-email-rklein@nvidia.com>
 <5165E80D.7050106@wwwdotorg.org> <5166D907.6060004@nvidia.com>
 <5166E22A.9010401@wwwdotorg.org>
Message-ID: <5166E477.2040905@nvidia.com>

On 4/11/2013 12:17 PM, Stephen Warren wrote:
> On 04/11/2013 09:38 AM, Rhyland Klein wrote:
>> On 4/10/2013 6:30 PM, Stephen Warren wrote:
>>> On 04/10/2013 01:51 PM, Rhyland Klein wrote:
>>>> The charger is now represented by a distinct subnode of the tps65090
>>>> device. Add this node and enable low current charging with it.
>>>
>>>> diff --git a/arch/arm/boot/dts/tegra114-dalmore.dts b/arch/arm/boot/dts/tegra114-dalmore.dts
>>>
>>>> +			charger {
>>>> +				compatible = "ti,tps65090-charger";
>>>> +				ti,enable-low-current-chrg;
>>>
>>> So does the TPS65090 driver scan all its sub-nodes like a bus an
>>> instantiate anything? That's a little odd since the regulators node is
>>> at the same level, yet doesn't represent a device on that same internal
>>> bus...
>>>
>>
>> It doesn't scan so much as have a list of subdev's it tries to register.
>> The charger node uses the of_compatible string defined (in the tps65090
>> driver and the charger driver) to match the subnode to the mfd_cell
>> device for the charger.
> 
> That sounds very odd. If the main driver hard-codes the list of children
> it expects, there's no point using compatible for the children. Using a
> bus-structure and compatible values would only be appropriate when the
> top-level driver is generic, and simply scans all its children as a
> generic bus, without having any idea what's there.

Agreed, but this seems to mfd children are handled right now, perhaps a
rework can be done for dt, but for non-dt routes, there is no bus to
scan for children.

> 
>> The regulators are currently under a different
>> subdevice which is not using the of_compatible string. I was planning on
>> a follow up patch series to update the tps65090-regulator driver to use
>> the dt type approach with a subnode to be consistent.
> 
> But that's changing the DT bindings. That shouldn't be done.
> 

We chose to the do the subnode structure partly to make the
Documentation layout more logical. This follows the design of the palmas
mfd and its sub-components. I can leave the regulators as is, but to me
the inconsistency between the two is more of a concern.

-rhyland

-- 
nvpublic


From broonie at opensource.wolfsonmicro.com  Thu Apr 11 12:28:27 2013
From: broonie at opensource.wolfsonmicro.com (Mark Brown)
Date: Thu, 11 Apr 2013 17:28:27 +0100
Subject: [PATCH v4 04/14] mfd: Add Samsung PWM/timer master driver
In-Reply-To: <201304110035.47776.arnd@arndb.de>
References: <1365093431-30621-1-git-send-email-t.figa@samsung.com>
 <2359597.ofbj7Kvioz@flatron> <5357756.gKmBOZlWcd@flatron>
 <201304110035.47776.arnd@arndb.de>
Message-ID: <20130411162826.GG9243@opensource.wolfsonmicro.com>

On Thu, Apr 11, 2013 at 12:35:47AM +0200, Arnd Bergmann wrote:

> Sorry for not replying earlier. My idea for the register level interface
> was to create a platform_device for each PWM, e.g. using the mfd_cell
> infrastructure. You can then pass a "struct regmap" as the platform
> data for each child of the timer node, and all the DT handling code
> can stay in the parent driver.

Dunno if it helps or not but there's also dev_get_regmap() if you're
passing the struct device around or can fish one out of thhe parent.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130411/f538ba40/attachment.sig>

From eduardo.valentin at ti.com  Thu Apr 11 12:29:22 2013
From: eduardo.valentin at ti.com (Eduardo Valentin)
Date: Thu, 11 Apr 2013 12:29:22 -0400
Subject: [v2,
 04/14] thermal: mvebu: Remove unneeded variable initialization
In-Reply-To: <1363991114-4225-5-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1363991114-4225-5-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <5166E4E2.1080606@ti.com>

Rui, Ezequiel,

On 22-03-2013 18:25, Ezequiel Garcia wrote:
> This variable is used only after it's properly initialized,
> so there's no need to set it to NULL in its declaration.
>
> Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
>

I am fine with this patch. Though it doesn t hurt to have this 
initialization, the code looks cleaner though.

Acked-by: Eduardo Valentin <eduardo.valentin at ti.com>


> ---
> drivers/thermal/mvebu_thermal.c |    2 +-
>   1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/thermal/mvebu_thermal.c b/drivers/thermal/mvebu_thermal.c
> index 031f94d..1f502ed 100644
> --- a/drivers/thermal/mvebu_thermal.c
> +++ b/drivers/thermal/mvebu_thermal.c
> @@ -72,7 +72,7 @@ MODULE_DEVICE_TABLE(of, mvebu_thermal_id_table);
>
>   static int mvebu_thermal_probe(struct platform_device *pdev)
>   {
> -	struct thermal_zone_device *thermal = NULL;
> +	struct thermal_zone_device *thermal;
>   	struct mvebu_thermal_priv *priv;
>   	struct resource *res;
>
>



From ezequiel.garcia at free-electrons.com  Thu Apr 11 12:31:58 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Thu, 11 Apr 2013 13:31:58 -0300
Subject: [v2,01/14] thermal: Rename driver 'kirkwood' -> 'mvebu'
In-Reply-To: <5166DE30.3020001@ti.com>
References: <1363991114-4225-2-git-send-email-ezequiel.garcia@free-electrons.com>
 <5166DE30.3020001@ti.com>
Message-ID: <20130411163156.GB2279@localhost>

Hi Eduardo,

Thanks for your testing.

On Thu, Apr 11, 2013 at 12:00:48PM -0400, Eduardo Valentin wrote:
> Hello Ezequiel,
> 
> Two minor comments.
> 
> On 22-03-2013 18:25, Ezequiel Garcia wrote:
> > This driver will support several Marvell SoC, so it is convenient
> > to rename it to 'mvebu' to represent accurately the hardware it
> > supports.
> >
> > Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
> >
> > ---
> > .../bindings/thermal/kirkwood-thermal.txt          |   15 ---
> >   .../devicetree/bindings/thermal/mvebu-thermal.txt  |   15 +++
> >   drivers/thermal/Kconfig                            |   10 +-
> >   drivers/thermal/Makefile                           |    2 +-
> >   drivers/thermal/kirkwood_thermal.c                 |  134 --------------------
> >   drivers/thermal/mvebu_thermal.c                    |  134 ++++++++++++++++++++
> >   6 files changed, 155 insertions(+), 155 deletions(-)
> >   delete mode 100644 Documentation/devicetree/bindings/thermal/kirkwood-thermal.txt
> >   create mode 100644 Documentation/devicetree/bindings/thermal/mvebu-thermal.txt
> >   delete mode 100644 drivers/thermal/kirkwood_thermal.c
> >   create mode 100644 drivers/thermal/mvebu_thermal.c
> 
> When sending renames, use git format-patch --find-renames. The summary 
> will be much descriptive on what you have done.
> 

Yes, you're right I forgot about this.

> I tried applying this patch on top of linux-next, linus/master, 
> ruis/thermal, on top of the your suggested dependencies, and all failed. 
> What is your base?
>

Well, first of all this patchset has been dropped entirely after some discussion.
If you're interested in this discussion you can read:

  http://www.spinics.net/lists/arm-kernel/msg231697.html

If you still want to try this series, the easiest way is to try

  https://github.com/MISL-EBU-System-SW/mainline-public/commits/mvebu-thermal-v2

That branch is based on v3.9-rc2, with a bunch of patches applied as
explained in the cover letter.

I appreciate your feedback a lot, but this are really ancient patches!
You came in a little late :)
-- 
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com


From tony at atomide.com  Thu Apr 11 12:34:29 2013
From: tony at atomide.com (Tony Lindgren)
Date: Thu, 11 Apr 2013 09:34:29 -0700
Subject: [GIT PULL 5/5] omap dt changes for v3.10 merge window
In-Reply-To: <20130411110645.GA8802@quad.lixom.net>
References: <pull-1365483063-475562>
 <51639e43.d294dc0a.2f07.03b4SMTPIN_ADDED_MISSING@mx.google.com>
 <20130411110645.GA8802@quad.lixom.net>
Message-ID: <20130411163428.GY10155@atomide.com>

* Olof Johansson <olof at lixom.net> [130411 04:11]:
> Hi,
> 
> On Mon, Apr 08, 2013 at 09:51:03PM -0700, Tony Lindgren wrote:
> > The following changes since commit 5852264f9d6139751796853fdfca9d5230cbfb97:
> > 
> >   Merge tag 'omap-devel-b-for-3.10' of git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending into for_3.10/dts_merged (2013-04-09 00:11:05 +0200)
> > 
> > are available in the git repository at:
> > 
> > 
> >   git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.10/dt-signed-v2
> > 
> > for you to fetch changes up to 161e89a689bb88004b757986eefda2402448eef7:
> > 
> >   ARM/dts: OMAP3: fix pinctrl-single configuration (2013-04-08 17:00:22 -0700)
> > 
> > ----------------------------------------------------------------
> > Device tree updates for omaps via Benoit Cousson <b-cousson at ti.com>.
> > 
> > Note that the branch has dependencies to two other branches:
> > 
> > - omap-devel-b-for-3.10 from Paul to get the AM33xx missing
> >   hwmod and thus avoid a regression with Santosh's hwmod
> >   cleanup including in this DT series [1]. It avoids breaking
> >   bisect if this series is merged before Paul's fixes.
> 
> Looks like this was part of omap/fixes-non-critical, the branch name from Paul
> just didn't percolate up. At least the topmost SHA from that merge in your
> history seems to be part of said branch. :)
> 
> 
> > - omap-for-v3.10/usb branch to avoid nasty merge conflict in
> >   omap3.dtsi and omap4.dtsi due to the DTS patches contained
> >   in the USB branch because of a screw up by the unnamed person
> >   typing this signed tag based on Benoit's comments.
> 
> 
> Ok, it looks like this one was merged in next/drivers as omap/usb.
> 
> 
> So based on the above, I've merged in omap/fixes-non-critical and omap/usb as
> a base, and merged this on top. All of this has gone into next/dt2.

OK thanks.

Tony


From eduardo.valentin at ti.com  Thu Apr 11 12:35:55 2013
From: eduardo.valentin at ti.com (Eduardo Valentin)
Date: Thu, 11 Apr 2013 12:35:55 -0400
Subject: [v2,05/14] thermal: mvebu: Convert to devm_ioremap_resource()
In-Reply-To: <1363991114-4225-6-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1363991114-4225-6-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <5166E66B.6080406@ti.com>

Rui,

On 22-03-2013 18:25, Ezequiel Garcia wrote:
> Convert devm_request_and_ioremap() to the newly introduced
> devm_ioremap_resource() which provides more consistent error handling.
>
> Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
>

This patch looks correct to me too.

Acked-by: Eduardo Valentin <eduardo.valentin at ti.com>

> ---
> drivers/thermal/mvebu_thermal.c |    8 +++-----
>   1 files changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/thermal/mvebu_thermal.c b/drivers/thermal/mvebu_thermal.c
> index 1f502ed..2aeaf75 100644
> --- a/drivers/thermal/mvebu_thermal.c
> +++ b/drivers/thermal/mvebu_thermal.c
> @@ -86,11 +86,9 @@ static int mvebu_thermal_probe(struct platform_device *pdev)
>   	if (!priv)
>   		return -ENOMEM;
>
> -	priv->sensor = devm_request_and_ioremap(&pdev->dev, res);
> -	if (!priv->sensor) {
> -		dev_err(&pdev->dev, "Failed to request_ioremap memory\n");
> -		return -EADDRNOTAVAIL;
> -	}
> +	priv->sensor = devm_ioremap_resource(&pdev->dev, res);
> +	if (IS_ERR(priv->sensor))
> +		return PTR_ERR(priv->sensor);
>
>   	thermal = thermal_zone_device_register("mvebu_thermal", 0, 0,
>   					       priv, &ops, NULL, 0, 0);
>



From eduardo.valentin at ti.com  Thu Apr 11 12:40:14 2013
From: eduardo.valentin at ti.com (Eduardo Valentin)
Date: Thu, 11 Apr 2013 12:40:14 -0400
Subject: [v2,06/14] thermal: mvebu: Fix license declaration
In-Reply-To: <1363991114-4225-7-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1363991114-4225-7-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <5166E76E.5020104@ti.com>

Hi Rui,

On 22-03-2013 18:25, Ezequiel Garcia wrote:
> The license text declared in the header explicit says GPL v2 only,
> but the MODULE_LICENSE macro says GPL, which means GPL v2 or later. Fix it.
>
> Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
>

This specific patch is fine to me.

Acked-by: Eduardo Valentin <eduardo.valentin at ti.com>

> ---
> drivers/thermal/mvebu_thermal.c |    2 +-
>   1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/thermal/mvebu_thermal.c b/drivers/thermal/mvebu_thermal.c
> index 2aeaf75..0c9344d 100644
> --- a/drivers/thermal/mvebu_thermal.c
> +++ b/drivers/thermal/mvebu_thermal.c
> @@ -128,4 +128,4 @@ module_platform_driver(mvebu_thermal_driver);
>
>   MODULE_AUTHOR("Nobuhiro Iwamatsu <iwamatsu at nigauri.org>");
>   MODULE_DESCRIPTION("mvebu thermal driver");
> -MODULE_LICENSE("GPL");
> +MODULE_LICENSE("GPL v2");
>

Side question, while here:
Ezequiel, does this driver need a MODULE_ALIAS



From eduardo.valentin at ti.com  Thu Apr 11 12:43:43 2013
From: eduardo.valentin at ti.com (Eduardo Valentin)
Date: Thu, 11 Apr 2013 12:43:43 -0400
Subject: [v2,07/14] thermal: mvebu: Rename kirkwood definitions to mvebu
In-Reply-To: <1363991114-4225-8-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1363991114-4225-8-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <5166E83F.4050800@ti.com>

On 22-03-2013 18:25, Ezequiel Garcia wrote:
> This definitions will be also valid for other SoC,
> such as Armada 370 and Armada XP. Therefore we rename them as 'mvebu'.
>

I believe it is appropriated to squash this one to your patch v2 02/14.

> Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
>
> ---
> drivers/thermal/mvebu_thermal.c |   16 ++++++++--------
>   1 files changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/thermal/mvebu_thermal.c b/drivers/thermal/mvebu_thermal.c
> index 0c9344d..39ddded 100644
> --- a/drivers/thermal/mvebu_thermal.c
> +++ b/drivers/thermal/mvebu_thermal.c
> @@ -22,10 +22,10 @@
>   #include <linux/platform_device.h>
>   #include <linux/thermal.h>
>
> -#define KIRKWOOD_THERMAL_VALID_OFFSET	9
> -#define KIRKWOOD_THERMAL_VALID_MASK	0x1
> -#define KIRKWOOD_THERMAL_TEMP_OFFSET	10
> -#define KIRKWOOD_THERMAL_TEMP_MASK	0x1FF
> +#define MVEBU_THERMAL_VALID_OFFSET	9
> +#define MVEBU_THERMAL_VALID_MASK	0x1
> +#define MVEBU_THERMAL_TEMP_OFFSET	10
> +#define MVEBU_THERMAL_TEMP_MASK		0x1FF
>
>   /* Marvell EBU Thermal Sensor Dev Structure */
>   struct mvebu_thermal_priv {
> @@ -41,8 +41,8 @@ static int mvebu_get_temp(struct thermal_zone_device *thermal,
>   	reg = readl_relaxed(priv->sensor);
>
>   	/* Valid check */
> -	if (!((reg >> KIRKWOOD_THERMAL_VALID_OFFSET) &
> -	    KIRKWOOD_THERMAL_VALID_MASK)) {
> +	if (!((reg >> MVEBU_THERMAL_VALID_OFFSET) &
> +	    MVEBU_THERMAL_VALID_MASK)) {
>   		dev_err(&thermal->device,
>   			"Temperature sensor reading not valid\n");
>   		return -EIO;
> @@ -53,8 +53,8 @@ static int mvebu_get_temp(struct thermal_zone_device *thermal,
>   	 * documentation the formula for this is:
>   	 * Celsius = (322-reg)/1.3625
>   	 */
> -	reg = (reg >> KIRKWOOD_THERMAL_TEMP_OFFSET) &
> -		KIRKWOOD_THERMAL_TEMP_MASK;
> +	reg = (reg >> MVEBU_THERMAL_TEMP_OFFSET) &
> +		MVEBU_THERMAL_TEMP_MASK;
>   	*temp = ((3220000000UL - (10000000UL * reg)) / 13625);
>
>   	return 0;
>



From t.figa at samsung.com  Thu Apr 11 12:44:33 2013
From: t.figa at samsung.com (Tomasz Figa)
Date: Thu, 11 Apr 2013 18:44:33 +0200
Subject: [PATCH v4 04/14] mfd: Add Samsung PWM/timer master driver
In-Reply-To: <201304110035.47776.arnd@arndb.de>
References: <1365093431-30621-1-git-send-email-t.figa@samsung.com>
 <5357756.gKmBOZlWcd@flatron> <201304110035.47776.arnd@arndb.de>
Message-ID: <1718887.H9vPuvORKd@amdc1227>

On Thursday 11 of April 2013 00:35:47 Arnd Bergmann wrote:
> On Monday 08 April 2013, Tomasz Figa wrote:
> > On Saturday 06 of April 2013 00:24:18 Tomasz Figa wrote:
> > > On Friday 05 of April 2013 21:54:21 Arnd Bergmann wrote:
> > > > On Friday 05 April 2013, Tomasz Figa wrote:
> > > I'm not sure what you mean by a register-level interface. Something like
> > > samsung_pwm_update_reg(reg, mask, val), which modifies bitfields
> > > according to the mask and value with appropriate synchronization? If
> > > yes, this solves only the problem of access to shared registers.
> > > 
> > > The other problems that remain:
> > > 
> > > - negotiation of PWM channels to use for clock source and clock events,
> > > 
> > >   because each board can use different channels for PWM outputs,
> > > 
> > > - code duplication caused by both of the drivers doing mostly the same
> > > 
> > >   things and or having to parse the same data from device tree,
> > > 
> > > - both non-DT and DT platforms must be supported,
> > > 
> > > - how to keep the ability to load PWM driver as a module (or not load it
> > > at all when PWM is not used on particular board), while retaining
> > > everything that is needed for the clocksource driver in kernel,
> > > 
> > > - some platforms can't use PWM timers as system clocksources, while on
> > > 
> > >   others this is the only timekeeping hardware available.
> > 
> > Hmm. Does anybody have an idea of a better way of implementing this PWM
> > timer support, which solves the above problems?
> > 
> > This series is a dependency for moving Universal C210 board to DT-based
> > description and it's already almost out of time to get this included for
> > 3.10...
> 
> Sorry for not replying earlier. My idea for the register level interface
> was to create a platform_device for each PWM, e.g. using the mfd_cell
> infrastructure. You can then pass a "struct regmap" as the platform
> data for each child of the timer node, and all the DT handling code
> can stay in the parent driver.

Hmm. As I said, I'm completely fine with using a regmap for sharing registers 
between subdrivers. However the clocksource can not be registered as an MFD 
cell, because it's needed very early.

I can imagine a solution alternative to my original one, where the MFD cells 
would be registered from the clocksource driver. This would mean that 
platforms that don't need (and can't use) the PWM clocksource would have to 
enable the driver anyway.

Another thing is that I don't see a need to create one cell per PWM channel. 
The PWM core is designed in a way that supports multiple channels per PWM 
controller and so is the generic PWM DT specifier (<&controller channel period 
flags>), so I'd rather see a single cell for all PWM channels.

So, to summarize this alternative concept:
 - two drivers:
   1) clocksource driver - registering clocksource and PWM MFD cell
   2) PWM driver - handling the PWM MFD cell
 - both drivers would share registers using a regmap with custom lock/unlock 
   callbacks (using spin_lock_irqsave/spin_unlock_irqrestore, because the 
   clocksource needs to access PWM registers in IRQ context)
 - the clocksource/master driver would have a samsung_time_init function which 
   would set up the driver early and initialize the clocksource
 - a platform driver would be registered by the clocksource/master driver
   which would register the PWM MFD cell in its probe
 - MFD cell platform data would contain struct regmap * and variant data
   (parsed from DT or received from platform code - as in my original version)

This should indeed work, assuming that I find a solution to make 
clocksource_of_init not initialize the PWM clocksource (from PWM DT node) on 
platforms that can't use it.

Best regards,
-- 
Tomasz Figa
Samsung Poland R&D Center
SW Solution Development, Kernel and System Framework



From dhowells at redhat.com  Thu Apr 11 12:45:25 2013
From: dhowells at redhat.com (David Howells)
Date: Thu, 11 Apr 2013 17:45:25 +0100
Subject: [PATCH 25/26] arm: Don't use create_proc_read_entry() [RFC]
In-Reply-To: <20130411154806.GU10155@atomide.com>
References: <20130411154806.GU10155@atomide.com>
 <20130411132739.32763.82609.stgit@warthog.procyon.org.uk>
 <20130411133058.32763.5466.stgit@warthog.procyon.org.uk>
Message-ID: <13448.1365698725@warthog.procyon.org.uk>

Tony Lindgren <tony at atomide.com> wrote:

> Looks like the mach-omap1/pm.c part we can make into
> a debugfs entry as it only contains PM debug data. But
> that we can do after this patch.

If you have a patch to do that, I can substitute it for this one.

David


From olof at lixom.net  Thu Apr 11 12:45:43 2013
From: olof at lixom.net (Olof Johansson)
Date: Thu, 11 Apr 2013 09:45:43 -0700
Subject: [PATCH v6 3/8] reset: Add driver for gpio-controlled reset pins
In-Reply-To: <5166DCC4.6050206@wwwdotorg.org>
References: <1364488523-20310-1-git-send-email-p.zabel@pengutronix.de>
 <1364488523-20310-4-git-send-email-p.zabel@pengutronix.de>
 <CAOesGMgo61M=oxG6_6EEGu7kL3Wa+HsdEomCxUnvj-Rbdhujgg@mail.gmail.com>
 <5166DCC4.6050206@wwwdotorg.org>
Message-ID: <CAOesGMg8JEntxcOeh667d84_UwS5M3XQpSKJsTiHrPaOkvtwHA@mail.gmail.com>

On Thu, Apr 11, 2013 at 8:54 AM, Stephen Warren <swarren at wwwdotorg.org> wrote:
> On 04/11/2013 04:35 AM, Olof Johansson wrote:
>> On Thu, Mar 28, 2013 at 9:35 AM, Philipp Zabel <p.zabel at pengutronix.de> wrote:
>>> This driver implements a reset controller device that toggles gpios
>>> connected to reset pins of peripheral ICs. The delay between assertion
>>> and de-assertion of the reset signal can be configured.
> ...
>> Since this is a platform driver and not just an OF driver, shouldn't
>> you provide a way to specify the same configuration data through a
>> platform_data structure as well?
>
> I believe the only practical use-cases for this driver are /currently/
> for device-tree platforms. Shouldn't we add the platform_data support
> only when some platform actively uses it?

Then the Kconfig needs to depend on OF in this case.

> In the past when reviewing new drivers, I pushed for platform drivers to
> always implement the platform_data structure up-front, and support using
> that if present rather than "falling back" to DT. However, Grant then
> shot that down saying that there was no point adding dead code...

Uh, ok. I don't care much either way but it somehow seems like it'll
be impopular to start adding a lot of new "depends on OF" drivers. I
might be wrong though.

> (this will also feed into the discussion about simple-framebuffer, which
> also only needs DT support right now, but could in theory be extended to
> support platform_data in the future if somebody wants).

Yeah, that's turning out to be a color preference discussion for
sheds, not very surprising.


-Olof


From broonie at opensource.wolfsonmicro.com  Thu Apr 11 12:47:51 2013
From: broonie at opensource.wolfsonmicro.com (Mark Brown)
Date: Thu, 11 Apr 2013 17:47:51 +0100
Subject: [PATCH 18/30] ASoC: samsung: move plat/ headers to local directory
In-Reply-To: <1365638712-1028578-19-git-send-email-arnd@arndb.de>
References: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
 <1365638712-1028578-19-git-send-email-arnd@arndb.de>
Message-ID: <20130411164751.GK9243@opensource.wolfsonmicro.com>

On Thu, Apr 11, 2013 at 02:05:00AM +0200, Arnd Bergmann wrote:
> The plat/iis.h and plat/ac97.h files in the samsung platform are
> only needed by the ASoC drivers, so they can be moved into the
> same directory, as one more step towards a multiplatform build.

This doesn't apply to my topic/samsung branch, can you please regenerate
it against that or let me know what to apply it against?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130411/712ec25b/attachment.sig>

From broonie at opensource.wolfsonmicro.com  Thu Apr 11 12:48:27 2013
From: broonie at opensource.wolfsonmicro.com (Mark Brown)
Date: Thu, 11 Apr 2013 17:48:27 +0100
Subject: [PATCH 19/30] ASoC: samsung: use irq resource for idma
In-Reply-To: <1365638712-1028578-20-git-send-email-arnd@arndb.de>
References: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
 <1365638712-1028578-20-git-send-email-arnd@arndb.de>
Message-ID: <20130411164827.GL9243@opensource.wolfsonmicro.com>

On Thu, Apr 11, 2013 at 02:05:01AM +0200, Arnd Bergmann wrote:
> With multiplatform kernels, we cannot use hardwired IRQ
> numbers in device drivers. This changes the idma driver
> to use a proper resource, like all other drivers do.

Applied, thanks.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130411/02c330bd/attachment.sig>

From broonie at opensource.wolfsonmicro.com  Thu Apr 11 12:48:44 2013
From: broonie at opensource.wolfsonmicro.com (Mark Brown)
Date: Thu, 11 Apr 2013 17:48:44 +0100
Subject: [PATCH 21/30] ASoC: samsung/i2s: fix module_device_table
In-Reply-To: <1365638712-1028578-22-git-send-email-arnd@arndb.de>
References: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
 <1365638712-1028578-22-git-send-email-arnd@arndb.de>
Message-ID: <20130411164844.GM9243@opensource.wolfsonmicro.com>

On Thu, Apr 11, 2013 at 02:05:03AM +0200, Arnd Bergmann wrote:
> The second argument to the module_device_table macro must be the
> name of the device id array. In the samsung i2s driver, there
> was a small typo, resulting in a build error when building it
> as a loadable module.

Applied, thanks.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130411/4ef8151e/attachment.sig>

From broonie at opensource.wolfsonmicro.com  Thu Apr 11 12:48:59 2013
From: broonie at opensource.wolfsonmicro.com (Mark Brown)
Date: Thu, 11 Apr 2013 17:48:59 +0100
Subject: [PATCH 22/30] ASoC: samsung/idma: export idma_reg_addr_init
In-Reply-To: <1365638712-1028578-23-git-send-email-arnd@arndb.de>
References: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
 <1365638712-1028578-23-git-send-email-arnd@arndb.de>
Message-ID: <20130411164858.GN9243@opensource.wolfsonmicro.com>

On Thu, Apr 11, 2013 at 02:05:04AM +0200, Arnd Bergmann wrote:
> The idma_reg_addr_init function is used by the samsung i2s driver,
> which can be a loadable module, so we have to export this function.

Applied, thanks.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130411/470f812c/attachment.sig>

From jgunthorpe at obsidianresearch.com  Thu Apr 11 12:51:58 2013
From: jgunthorpe at obsidianresearch.com (Jason Gunthorpe)
Date: Thu, 11 Apr 2013 10:51:58 -0600
Subject: [PATCHv2 08/10] arm: kirkwood: convert QNAP TS219 to use DT for
 the PCIe interface
In-Reply-To: <20130411052432.GP13524@lunn.ch>
References: <1365632436-25367-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1365632436-25367-9-git-send-email-thomas.petazzoni@free-electrons.com>
 <20130411003301.GH28693@titan.lakedaemon.net>
 <20130411052432.GP13524@lunn.ch>
Message-ID: <20130411165158.GA5865@obsidianresearch.com>

On Thu, Apr 11, 2013 at 07:24:32AM +0200, Andrew Lunn wrote:
 
> I've hacked around with PCI driver on my QNAP TS119P+, which does not
> have any PCI devices, and never had any problems with the driver
> enabled and finding two empty PCI busses. PCI does not share any pins
> with anything else. So i think it is safe to just enable it for all
> devices.

In the general case, this is probably only safe if the board has
configured the PEX to have the PHY clock. Marvell has guidelines for
unused PEX's that would result in the PHY clock being permanently
inactive.

Register 10030 tells what the strap for the PHY clock is. I expect in
many cases the PEX driver should not be loaded if the PHY clock is not
internally derived. Maybe checking this register will tell your QNAPs
apart?

Jason


From jason at lakedaemon.net  Thu Apr 11 12:53:03 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Thu, 11 Apr 2013 12:53:03 -0400
Subject: [PATCH 0/5 v2] mv643xx_eth: device tree bindings
In-Reply-To: <1365071235-11611-1-git-send-email-florian@openwrt.org>
References: <1365071235-11611-1-git-send-email-florian@openwrt.org>
Message-ID: <20130411165303.GI28693@titan.lakedaemon.net>

Florian,

On Thu, Apr 04, 2013 at 12:27:10PM +0200, Florian Fainelli wrote:
> Hi all,
> 
> This patch serie implements mv643xx_eth device tree bindings. I opted for
> the reuse of the bindings already defined in
> Documentation/devicetree/bindings/marvell.txt so that we do not create
> any confusion.
> 
> For reference, I have included the mv643xx-eth related nodes in the
> corresponding Kirkwood, Dove and Orion5x .dtsi files so you can more
> easily test on your own platforms.
> 
> I tested these on a custom 88F6181-based boards.
> 
> Florian Fainelli (5):
>   mv643xx_eth: add Device Tree bindings
>   mv643xx_eth: update Device Tree bindings documentation
>   ARM: kirkwood: add device node entries for the gigabit interfaces
>   ARM: orion5x: add gigabit ethernet device tree node
>   ARM: dove: add gigabit device tree nodes to dove.dtsi
> 
>  Documentation/devicetree/bindings/marvell.txt |   25 +++++-
>  arch/arm/boot/dts/dove.dtsi                   |   25 ++++++
>  arch/arm/boot/dts/kirkwood.dtsi               |   46 ++++++++++
>  arch/arm/boot/dts/orion5x.dtsi                |   23 +++++
>  drivers/net/ethernet/marvell/mv643xx_eth.c    |  120 ++++++++++++++++++++++++-
>  5 files changed, 234 insertions(+), 5 deletions(-)

How is the new version of this looking?  Do you think you'll be able to
get it up in time for DaveM to take it into v3.10?

With this and Thomas' pci series, we will have Kirkwood fully converted
to devicetree, can begin removing board files, and finally begin
migrating everything over to mach-mvebu/.  This will lead to the removal
of five directories under arch/arm/ (plat-orion, mach-kirkwood,
mach-orion5x, mach-dove, and mach-mv78xx0).

thx,

Jason.


From linus.walleij at linaro.org  Thu Apr 11 12:55:26 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 11 Apr 2013 18:55:26 +0200
Subject: [PATCH v6 0/3] of/pci: Provide common support for PCI DT parsing
In-Reply-To: <1365693969-23907-1-git-send-email-Andrew.Murray@arm.com>
References: <1365693969-23907-1-git-send-email-Andrew.Murray@arm.com>
Message-ID: <CACRpkda_LxhoS5eciuC7F3_zmfYLyNO2fALi=ABeqGJDpSpKWw@mail.gmail.com>

On Thu, Apr 11, 2013 at 5:26 PM, Andrew Murray <Andrew.Murray at arm.com> wrote:

> This patchset factors out duplicated code associated with parsing PCI
> DT "ranges" properties across the architectures and introduces a
> "ranges" parser. This parser "of_pci_range_parser" can be used directly
> by ARM host bridge drivers enabling them to obtain ranges from device
> trees.
>
> I've included the Reviewed-by and Tested-by's received from v5 in this
> patchset, earlier versions of this patchset (v3) have been tested-by:
>
> Thierry Reding <thierry.reding at avionic-design.de>
> Jingoo Han <jg1.han at samsung.com>
>
> I believe a version of this patchset has also been tested through its
> inclusion in Thomas Petazzoni's Armada 370 and Armada XP SoCs PCIe support by:
>
> Linus Walleij <linus.walleij at linaro.org>

Yes you can add my Tested-by tag.

Yours,
Linus Walleij


From broonie at opensource.wolfsonmicro.com  Thu Apr 11 12:55:36 2013
From: broonie at opensource.wolfsonmicro.com (Mark Brown)
Date: Thu, 11 Apr 2013 17:55:36 +0100
Subject: [PATCH 29/30] spi: s3c64xx: move to generic dmaengine API
In-Reply-To: <1365638712-1028578-30-git-send-email-arnd@arndb.de>
References: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
 <1365638712-1028578-30-git-send-email-arnd@arndb.de>
Message-ID: <20130411165536.GO9243@opensource.wolfsonmicro.com>

On Thu, Apr 11, 2013 at 02:05:11AM +0200, Arnd Bergmann wrote:
> The spi-s3c64xx uses a Samsung proprietary interface for
> talking to the DMA engine, which does not work with
> multiplatform kernels.

This doesn't apply against my spi-next, can you please check and resend?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130411/992e6ac6/attachment.sig>

From linus.walleij at linaro.org  Thu Apr 11 12:57:12 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 11 Apr 2013 18:57:12 +0200
Subject: [PATCH v5 1/3] of/pci: Unify pci_process_bridge_OF_ranges from
 Microblaze and PowerPC
In-Reply-To: <20130410233059.5cdcc119@skate>
References: <1365578969-30966-1-git-send-email-Andrew.Murray@arm.com>
 <1365578969-30966-2-git-send-email-Andrew.Murray@arm.com>
 <51656592.7070806@gmail.com> <20130410233059.5cdcc119@skate>
Message-ID: <CACRpkdY1PNLp7guzazCUvLCs8OqTopm40wg6L0DAC+2+Eu91og@mail.gmail.com>

On Wed, Apr 10, 2013 at 11:30 PM, Thomas Petazzoni
<thomas.petazzoni at free-electrons.com> wrote:

> Ben, Michal, could you review/test this patch from Andrew Murray? I
> need it as a dependency of "[PATCH v5 2/3] of/pci: Provide support for
> parsing PCI DT ranges property", which itself is used by the Marvell
> PCIe driver I'm hoping to get merged in 3.10.

Second this, I also have a patch series that depend on these patches.

Yours,
Linus Walleij


From tony at atomide.com  Thu Apr 11 12:57:03 2013
From: tony at atomide.com (Tony Lindgren)
Date: Thu, 11 Apr 2013 09:57:03 -0700
Subject: [PATCH 25/26] arm: Don't use create_proc_read_entry() [RFC]
In-Reply-To: <13448.1365698725@warthog.procyon.org.uk>
References: <20130411154806.GU10155@atomide.com>
 <20130411132739.32763.82609.stgit@warthog.procyon.org.uk>
 <20130411133058.32763.5466.stgit@warthog.procyon.org.uk>
 <13448.1365698725@warthog.procyon.org.uk>
Message-ID: <20130411165702.GZ10155@atomide.com>

* David Howells <dhowells at redhat.com> [130411 09:50]:
> Tony Lindgren <tony at atomide.com> wrote:
> 
> > Looks like the mach-omap1/pm.c part we can make into
> > a debugfs entry as it only contains PM debug data. But
> > that we can do after this patch.
> 
> If you have a patch to do that, I can substitute it for this one.

Sure will do.

Tony


From plagnioj at jcrosoft.com  Thu Apr 11 12:54:14 2013
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Thu, 11 Apr 2013 18:54:14 +0200
Subject: [rtc-linux] Re: [PATCH v2 0/5] ARM: at91: fix hanged boot
In-Reply-To: <20130411155505.GD21305@localhost>
References: <20130311180611.GF8797@localhost>
 <1363025279-17615-1-git-send-email-jhovold@gmail.com>
 <20130411155505.GD21305@localhost>
Message-ID: <20130411165414.GC25242@game.jcrosoft.org>

On 17:55 Thu 11 Apr     , Johan Hovold wrote:
> On Mon, Mar 11, 2013 at 07:07:54PM +0100, Johan Hovold wrote:
> > These patches fix a few severe issues affecting most AT91 SOCs where
> > boot can hang after a non-general reset, and where the only way to get
> > the system booting again is to do a general reset -- something which
> > could require physically removing any backup battery.
> 
> Have you had time to look at these patches yet, Nicolas?
> 
> I don't think not having decided on the path forward for DT-support for
> rtc-at91sam9 needs to be a blocker. The rtt-nodes will be needed in any
> case.
> 
> I could respin the series on top of the DT-patch for rtc-at91rm9200, and
> add interrupt and status-disabled properties to the DT-nodes as well.
for this this is still a no go

this way too much ugly

Best Regards,
J.
> 
> Thanks,
> Johan
> 
> > The problems stem from the fact that the RTC and RTT-peripherals are
> > powered by backup power (VDDBU) and are not reset on wake-up, user,
> > watchdog or software reset. Consequently, RTC and RTT-alarms and their
> > interrupts may be enabled at boot, leading to a system lock-up when an
> > interrupt arrives on the shared system-interrupt line before the
> > appropriate handler (e.g. RTC-driver) has been installed.
> > 
> > The easiest way to trigger this is to simply wake up from an RTC-alarm
> > on at91sam9g45. The RTC-driver currently does not disable interrupts at
> > shutdown so even after a clean shut-down the system will always hang
> > after waking up.
> > 
> > The first patch fixes this very general case of RTC-wake up after a
> > clean shutdown in the RTC-driver and is marked for stable as it is
> > perfectly straight-forward. [ Note that the other, RTT-based, AT91
> > RTC-driver already disables its interrupts at shutdown. ]
> > 
> > The more general problem can be triggered, for example, by doing a
> > user-reset while updating the RTC-time or if an RTC or RTT-alarm goes
> > off after a non-clean shutdown.
> > 
> > To fix this I propose that arch-code should mask the relevant interrupts
> > before enabling the system interrupt at early boot, and this is what
> > the fifth patch does. To access the RTC-registers I choose to revert a
> > recent patch that moved the register definitions to drivers/rtc.
> > 
> > Arguably, the relevant interrupts could also be disabled in bootloaders,
> > but I suggest fixing it in the kernel once and for all.
> > 
> > The patches have been tested on at91sam9263 and at91sam9g45 (non-DT),
> > and compile-tested for the other SOCs and DT.
> > 
> > Johan
> > 
> > 
> > v2:
> >  - add DT-support
> >  - make sys_irq_mask non-mandatory
> > 
> > 
> > Johan Hovold (5):
> >   ARM: at91/rtc: fix boot after RTC wake-up
> >   ARM: at91/dts: add RTC nodes
> >   ARM: at91/dts: add RTT nodes
> >   Revert "arm: at91: move at91rm9200 rtc header in drivers/rtc"
> >   ARM: at91: fix hanged boot
> 
> -- 
> -- 
> You received this message because you are subscribed to "rtc-linux".
> Membership options at http://groups.google.com/group/rtc-linux .
> Please read http://groups.google.com/group/rtc-linux/web/checklist
> before submitting a driver.
> --- 
> You received this message because you are subscribed to the Google Groups "rtc-linux" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
> 
> 


From sebastian.hesselbarth at gmail.com  Thu Apr 11 12:59:11 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Thu, 11 Apr 2013 18:59:11 +0200
Subject: [PATCH] net: mv643xx_eth: Add GRO support
In-Reply-To: <20130411153256.GH1910@1wt.eu>
References: <1365684023-9967-1-git-send-email-sebastian.hesselbarth@gmail.com>
 <20130411131333.GD1910@1wt.eu>
 <CABJ1b_TQDabT1J7ffo5cb1Th=71bcSduifMJaDpfVRiiHvtWDw@mail.gmail.com>
 <20130411150326.GA19978@1wt.eu>
 <CABJ1b_TRxm97DKJLP_h0VwMJvcYmSpjoJvtg1KvBNGah=VzqMQ@mail.gmail.com>
 <20130411153256.GH1910@1wt.eu>
Message-ID: <CABJ1b_QaEJbuBsqx+J1Pkc7o66S_Rboa7Trnko1mXSK6-UZhfg@mail.gmail.com>

On Thu, Apr 11, 2013 at 5:32 PM, Willy Tarreau <w at 1wt.eu> wrote:
> On Thu, Apr 11, 2013 at 05:27:03PM +0200, Sebastian Hesselbarth wrote:
>> I don't have a strong opinion on whether Soeren's or your proposal should
>> be submitted. But I insist on having one of them in, as GRO significantly
>> improves the common use case, is enabled by default, and not as
>> constrained as LRO.
>
> I agree, use yours first, but we should keep an eye on this. Since you have
> everything to run a test, please try to see if you can get netperf to run
> over IPv6, I'm sure the NIC doesn't handle it.

Willy,

out of curiosity I replayed all tests using netperf/netserver with -6 which
enables ipv6. The overall results remain quite the same here:
enabling support for GRO gives a huge improvement in achievable
throughput, and the difference between Soeren's and your patch is
neglectible.

Sebastian


From arnd at arndb.de  Thu Apr 11 13:08:42 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 11 Apr 2013 19:08:42 +0200
Subject: [PATCH 18/30] ASoC: samsung: move plat/ headers to local directory
In-Reply-To: <20130411164751.GK9243@opensource.wolfsonmicro.com>
References: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
 <1365638712-1028578-19-git-send-email-arnd@arndb.de>
 <20130411164751.GK9243@opensource.wolfsonmicro.com>
Message-ID: <201304111908.42532.arnd@arndb.de>

On Thursday 11 April 2013, Mark Brown wrote:
> On Thu, Apr 11, 2013 at 02:05:00AM +0200, Arnd Bergmann wrote:
> > The plat/iis.h and plat/ac97.h files in the samsung platform are
> > only needed by the ASoC drivers, so they can be moved into the
> > same directory, as one more step towards a multiplatform build.
> 
> This doesn't apply to my topic/samsung branch, can you please regenerate
> it against that or let me know what to apply it against?
> 

This one should work. Unfortunately I now found during testing that the
s3c24xx sound support has a few build errors at the moment, but this
patch should not add any new ones:

/git/arm-soc/sound/soc/samsung/idma.c: In function 'idma_close':
/git/arm-soc/sound/soc/samsung/idma.c:327:11: error: 'IRQ_I2S0' undeclared (first use in this function)
  free_irq(IRQ_I2S0, prtd);
           ^
make[5]: *** [sound/soc/samsung/idma.o] Error 1
make[5]: *** Waiting for unfinished jobs....

make[5]: *** [sound/soc/samsung/i2s.o] Error 1
/git/arm-soc/sound/soc/samsung/neo1973_wm8753.c:25:24: fatal error: mach/gta02.h: No such file or directory
 #include <mach/gta02.h>
                        ^


	Arnd

8<----
From 91cb290e665b10d094729a42f9e676e2de154996 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd at arndb.de>
Date: Sat, 16 Mar 2013 09:10:15 +0100
Subject: [PATCH] ASoC: samsung: move plat/ headers to local directory

The plat/regs-iis.h and plat/regs-ac97.h files in the samsung platform
are only needed by the ASoC drivers, so they can be moved into the same
directory, as one more step towards a multiplatform build.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Cc: alsa-devel at alsa-project.org
Cc: Mark Brown <broonie at opensource.wolfsonmicro.com>
Cc: Liam Girdwood <lgirdwood at gmail.com>

diff --git a/arch/arm/mach-s3c24xx/dma-s3c2410.c b/arch/arm/mach-s3c24xx/dma-s3c2410.c
index 25d085a..a4a13c9 100644
--- a/arch/arm/mach-s3c24xx/dma-s3c2410.c
+++ b/arch/arm/mach-s3c24xx/dma-s3c2410.c
@@ -25,11 +25,9 @@
 
 #include <plat/regs-serial.h>
 #include <mach/regs-gpio.h>
-#include <plat/regs-ac97.h>
 #include <plat/regs-dma.h>
 #include <mach/regs-lcd.h>
 #include <mach/regs-sdi.h>
-#include <plat/regs-iis.h>
 #include <plat/regs-spi.h>
 
 static struct s3c24xx_dma_map __initdata s3c2410_dma_mappings[] = {
diff --git a/arch/arm/mach-s3c24xx/dma-s3c2412.c b/arch/arm/mach-s3c24xx/dma-s3c2412.c
index d2408ba..6eaa7a4 100644
--- a/arch/arm/mach-s3c24xx/dma-s3c2412.c
+++ b/arch/arm/mach-s3c24xx/dma-s3c2412.c
@@ -25,11 +25,9 @@
 
 #include <plat/regs-serial.h>
 #include <mach/regs-gpio.h>
-#include <plat/regs-ac97.h>
 #include <plat/regs-dma.h>
 #include <mach/regs-lcd.h>
 #include <mach/regs-sdi.h>
-#include <plat/regs-iis.h>
 #include <plat/regs-spi.h>
 
 #define MAP(x) { (x)| DMA_CH_VALID, (x)| DMA_CH_VALID, (x)| DMA_CH_VALID, (x)| DMA_CH_VALID }
diff --git a/arch/arm/mach-s3c24xx/dma-s3c2440.c b/arch/arm/mach-s3c24xx/dma-s3c2440.c
index 0b86e74..477d450 100644
--- a/arch/arm/mach-s3c24xx/dma-s3c2440.c
+++ b/arch/arm/mach-s3c24xx/dma-s3c2440.c
@@ -25,11 +25,9 @@
 
 #include <plat/regs-serial.h>
 #include <mach/regs-gpio.h>
-#include <plat/regs-ac97.h>
 #include <plat/regs-dma.h>
 #include <mach/regs-lcd.h>
 #include <mach/regs-sdi.h>
-#include <plat/regs-iis.h>
 #include <plat/regs-spi.h>
 
 static struct s3c24xx_dma_map __initdata s3c2440_dma_mappings[] = {
diff --git a/arch/arm/mach-s3c24xx/dma-s3c2443.c b/arch/arm/mach-s3c24xx/dma-s3c2443.c
index 0553625..80a8d56 100644
--- a/arch/arm/mach-s3c24xx/dma-s3c2443.c
+++ b/arch/arm/mach-s3c24xx/dma-s3c2443.c
@@ -25,11 +25,9 @@
 
 #include <plat/regs-serial.h>
 #include <mach/regs-gpio.h>
-#include <plat/regs-ac97.h>
 #include <plat/regs-dma.h>
 #include <mach/regs-lcd.h>
 #include <mach/regs-sdi.h>
-#include <plat/regs-iis.h>
 #include <plat/regs-spi.h>
 
 #define MAP(x) { \
diff --git a/sound/soc/samsung/ac97.c b/sound/soc/samsung/ac97.c
index 0df3c56..c76abdf 100644
--- a/sound/soc/samsung/ac97.c
+++ b/sound/soc/samsung/ac97.c
@@ -20,7 +20,7 @@
 #include <sound/soc.h>
 
 #include <mach/dma.h>
-#include <plat/regs-ac97.h>
+#include "regs-ac97.h"
 #include <linux/platform_data/asoc-s3c.h>
 
 #include "dma.h"
diff --git a/sound/soc/samsung/h1940_uda1380.c b/sound/soc/samsung/h1940_uda1380.c
index 15a3817..fa91376 100644
--- a/sound/soc/samsung/h1940_uda1380.c
+++ b/sound/soc/samsung/h1940_uda1380.c
@@ -20,7 +20,7 @@
 #include <sound/soc.h>
 #include <sound/jack.h>
 
-#include <plat/regs-iis.h>
+#include "regs-iis.h"
 #include <asm/mach-types.h>
 
 #include "s3c24xx-i2s.h"
diff --git a/sound/soc/samsung/neo1973_wm8753.c b/sound/soc/samsung/neo1973_wm8753.c
index a301d8c..ccc601d 100644
--- a/sound/soc/samsung/neo1973_wm8753.c
+++ b/sound/soc/samsung/neo1973_wm8753.c
@@ -21,7 +21,7 @@
 #include <sound/soc.h>
 
 #include <asm/mach-types.h>
-#include <plat/regs-iis.h>
+#include "regs-iis.h"
 #include <mach/gta02.h>
 
 #include "../codecs/wm8753.h"
diff --git a/arch/arm/plat-samsung/include/plat/regs-ac97.h b/sound/soc/samsung/regs-ac97.h
similarity index 100%
rename from arch/arm/plat-samsung/include/plat/regs-ac97.h
rename to sound/soc/samsung/regs-ac97.h
diff --git a/arch/arm/plat-samsung/include/plat/regs-iis.h b/sound/soc/samsung/regs-iis.h
similarity index 100%
rename from arch/arm/plat-samsung/include/plat/regs-iis.h
rename to sound/soc/samsung/regs-iis.h
diff --git a/sound/soc/samsung/rx1950_uda1380.c b/sound/soc/samsung/rx1950_uda1380.c
index a5826ea..704460a 100644
--- a/sound/soc/samsung/rx1950_uda1380.c
+++ b/sound/soc/samsung/rx1950_uda1380.c
@@ -24,7 +24,7 @@
 #include <sound/soc.h>
 #include <sound/jack.h>
 
-#include <plat/regs-iis.h>
+#include "regs-iis.h"
 #include <asm/mach-types.h>
 
 #include "s3c24xx-i2s.h"
diff --git a/sound/soc/samsung/s3c24xx-i2s.c b/sound/soc/samsung/s3c24xx-i2s.c
index 13f6dd1..a7b17c1 100644
--- a/sound/soc/samsung/s3c24xx-i2s.c
+++ b/sound/soc/samsung/s3c24xx-i2s.c
@@ -24,7 +24,7 @@
 #include <sound/pcm_params.h>
 
 #include <mach/dma.h>
-#include <plat/regs-iis.h>
+#include "regs-iis.h"
 
 #include "dma.h"
 #include "s3c24xx-i2s.h"
diff --git a/sound/soc/samsung/s3c24xx_uda134x.c b/sound/soc/samsung/s3c24xx_uda134x.c
index 333e1b7..1b7b52b 100644
--- a/sound/soc/samsung/s3c24xx_uda134x.c
+++ b/sound/soc/samsung/s3c24xx_uda134x.c
@@ -18,7 +18,7 @@
 #include <sound/soc.h>
 #include <sound/s3c24xx_uda134x.h>
 
-#include <plat/regs-iis.h>
+#include "regs-iis.h"
 
 #include "s3c24xx-i2s.h"
 


From sebastian.hesselbarth at gmail.com  Thu Apr 11 13:09:54 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Thu, 11 Apr 2013 19:09:54 +0200
Subject: [PATCH 0/5 v2] mv643xx_eth: device tree bindings
In-Reply-To: <20130411165303.GI28693@titan.lakedaemon.net>
References: <1365071235-11611-1-git-send-email-florian@openwrt.org>
 <20130411165303.GI28693@titan.lakedaemon.net>
Message-ID: <CABJ1b_T0uvFgfnXbJH6ut-qj621vX5jhedWdWpHUz1wrs84krg@mail.gmail.com>

On Thu, Apr 11, 2013 at 6:53 PM, Jason Cooper <jason at lakedaemon.net> wrote:
> On Thu, Apr 04, 2013 at 12:27:10PM +0200, Florian Fainelli wrote:
>> This patch serie implements mv643xx_eth device tree bindings. I opted for
>> the reuse of the bindings already defined in
>> Documentation/devicetree/bindings/marvell.txt so that we do not create
>> any confusion.
>>
>
> How is the new version of this looking?  Do you think you'll be able to
> get it up in time for DaveM to take it into v3.10?
>
> With this and Thomas' pci series, we will have Kirkwood fully converted
> to devicetree, can begin removing board files, and finally begin
> migrating everything over to mach-mvebu/.  This will lead to the removal
> of five directories under arch/arm/ (plat-orion, mach-kirkwood,
> mach-orion5x, mach-dove, and mach-mv78xx0).

Jason,

I sent Florian an update of some of his patches earlier, based on
cleanup patches I submitted for mv643xx_eth while testing his patch set.
I think, the patch set will play nicely on ARM but without PPC guys involved
in testing it, I guess it will break something there.

Florian is reusing the DT bindings from PPC and they are compatible, but
there parsing is also done within arch/ppc/sysdev/mv64360-dev.c and
maybe somewhere else. The current DT patches for mv643xx_eth will
reparse some properties again (and may break eth on ppc platforms
using mv643xx_eth).

Sebastian


From dave.martin at linaro.org  Thu Apr 11 13:10:08 2013
From: dave.martin at linaro.org (Dave Martin)
Date: Thu, 11 Apr 2013 18:10:08 +0100
Subject: hypervisor/firmware calling conventions (Was: Re: [Xen-devel]
 [PATCH 1/4] xen/arm: basic PSCI support,	implement cpu_on)
In-Reply-To: <1365687148.8036.140.camel@zakaz.uk.xensource.com>
References: <alpine.DEB.2.02.1303211837140.5135@kaball.uk.xensource.com>
 <1363891353-13827-1-git-send-email-stefano.stabellini@eu.citrix.com>
 <1365515874.10725.33.camel@zakaz.uk.xensource.com>
 <1365687148.8036.140.camel@zakaz.uk.xensource.com>
Message-ID: <20130411170959.GA2239@linaro.org>

On Thu, Apr 11, 2013 at 02:32:28PM +0100, Ian Campbell wrote:
> Adding Charles and the l-a-k list which I hadn't noticed wasn't CC'd
> before. Are there other lists which would be useful to include?
> 
> On Tue, 2013-04-09 at 14:57 +0100, Ian Campbell wrote:
> > > +        if ( !hsr.iss )
> > > +            return do_trap_psci(regs);

Have you seen this work?

Reading the specs, I thought that the SMC immediate is not available in
the HSR in ARMv7, or when the caller is AArch32.  ARMv7 specifies these
bits as UNK/SBZP, and the A15 TRM doesn't seem seem to specify any
extra information.

Otherwise, you would need to go examine the trapped instruction in
guest memory.  This is even less easy than it sounds.

> > Ugh, using ISS==0 for this interface is a bit unfortunate, who
> > arbitrates this namespace?

Nobody, officially.  ARM is working to promulgate some standards in
this area, but there is plenty of pre-existing firmware and software
out there with non-standardised interfaces and it's hard to predict
adoption timescales.  I believe nothing is published relating to this
just yet.

> Xen chose to use a non-0 immediate for its hypercalls so we are lucky
> that we don't have to play tricks to distinguish PSCI calls from
> hypercalls but it seems to me that either there needs to be some
> semi-formal registry for smv/hvc immediates to avoid clashes or that
> interfaces need to pick a random non-zero number to try and minimise the
> chances of a clash.
> 
> Or maybe it gets pushed down a layer and the registry is of r0/x0
> function ids and the immediate argument is generally ignored?
> 
> But in general we need some way for interfaces provided by hypervisors
> and secure mode monitors to safely co-exist, I think, both for the case
> where the hypervisor is implementing a shim for a secure mode interface
> (i.e. implementing PSCI with hvc) and for the case where there are
> multiple interfaces at each layer (e.g. hypervisors sometimes want to
> implement foreign hypervisor interfaces and I can easily imagine other
> firmware level interfaces than PSCI coming into existence in the
> future).

For PSCI and similar firmware functionality, we envisage multiplexing
all interfaces based on a function number in r0, with arguments and
results constrained to r0-r7.  For PSCI, we specify SMC #0/HVC #0 as the
call mechanism.

For now, there is no global management of the r0 namespace, which
is why for PSCI we don't make static assumptions about the numbers
on the client side.  Instead, the function number for each PSCI function
is passed in the DT.  This means that the firmware or hypervisor can
allocate the numbers as appropriate to avoid clashes.

In general, this is likely to be the best approach for Linux until a
standard probing interface exists.

In theory we could define a Xen-specific call mechanism for PSCI, but
that should be avoided unless it is absolutely unavoidable.  It sounds
like the different SMC comment field means that we don't need to
worry for Xen/PSCI coexistence specifically, assuming that the hypervisor
can read it reliably.

> In the specific case of PSCI I couldn't actually find the calling
> convention (i.e. the specific registers to use). I suspect I'm just
> looking at an old version of the spec...

This is indeed vague in the existing draft.  An update should appear
soon -- Charles can comment on the current status.

Cheers
---Dave


From fweisbec at gmail.com  Thu Apr 11 13:10:50 2013
From: fweisbec at gmail.com (Frederic Weisbecker)
Date: Thu, 11 Apr 2013 19:10:50 +0200
Subject: [PATCH 1/3] cputime_nsecs: use math64.h for nsec resolution
 conversion helpers
In-Reply-To: <1363822467-6275-2-git-send-email-khilman@linaro.org>
References: <1363822467-6275-1-git-send-email-khilman@linaro.org>
 <1363822467-6275-2-git-send-email-khilman@linaro.org>
Message-ID: <20130411171047.GB17129@somewhere.redhat.com>

On Wed, Mar 20, 2013 at 04:34:25PM -0700, Kevin Hilman wrote:
> For the nsec resolution conversions to be useable on non 64-bit
> architectures, the helpers in <linux/math64.h> need to be used so the
> right arch-specific 64-bit math helpers can be used (e.g. do_div())
> 
> Cc: Frederic Weisbecker <fweisbec at gmail.com>
> Signed-off-by: Kevin Hilman <khilman at linaro.org>

Ok the patch is nice!

I'm queuing it.

Thanks.


From olof at lixom.net  Thu Apr 11 13:11:02 2013
From: olof at lixom.net (Olof Johansson)
Date: Thu, 11 Apr 2013 10:11:02 -0700
Subject: [PATCH] ARM: EXYNOS: no more support non-DT for EXYNOS SoCs
In-Reply-To: <2f3001ce3515$9a9ae1b0$cfd0a510$%kim@samsung.com>
References: <2f3001ce3515$9a9ae1b0$cfd0a510$%kim@samsung.com>
Message-ID: <20130411171102.GA31066@quad.lixom.net>

On Tue, Apr 09, 2013 at 08:30:14PM +0900, Kukjin Kim wrote:
> 
> As we discussed in mailing list, non-DT for EXYNOS SoCs will not be
> supported from v3.10. This patch removes regarding files for non-DT
> including board files.
> 
> Signed-off-by: Kukjin Kim <kgene.kim at samsung.com>
> ---
>  arch/arm/configs/exynos4_defconfig         |   68 --

I think you can just delete this and move the contents over to exynos_defconfig
instead.

The original argument for keeping exynos4_defconfig was to provide a defconfig
for non-DT platforms on exynos4. That's gone now, and you can just roll them
into exynos_defconfig instead.



-Olof


From w at 1wt.eu  Thu Apr 11 13:13:39 2013
From: w at 1wt.eu (Willy Tarreau)
Date: Thu, 11 Apr 2013 19:13:39 +0200
Subject: [PATCH] net: mv643xx_eth: Add GRO support
In-Reply-To: <CABJ1b_QaEJbuBsqx+J1Pkc7o66S_Rboa7Trnko1mXSK6-UZhfg@mail.gmail.com>
References: <1365684023-9967-1-git-send-email-sebastian.hesselbarth@gmail.com>
 <20130411131333.GD1910@1wt.eu>
 <CABJ1b_TQDabT1J7ffo5cb1Th=71bcSduifMJaDpfVRiiHvtWDw@mail.gmail.com>
 <20130411150326.GA19978@1wt.eu>
 <CABJ1b_TRxm97DKJLP_h0VwMJvcYmSpjoJvtg1KvBNGah=VzqMQ@mail.gmail.com>
 <20130411153256.GH1910@1wt.eu>
 <CABJ1b_QaEJbuBsqx+J1Pkc7o66S_Rboa7Trnko1mXSK6-UZhfg@mail.gmail.com>
Message-ID: <20130411171339.GL1910@1wt.eu>

On Thu, Apr 11, 2013 at 06:59:11PM +0200, Sebastian Hesselbarth wrote:
> On Thu, Apr 11, 2013 at 5:32 PM, Willy Tarreau <w at 1wt.eu> wrote:
> > On Thu, Apr 11, 2013 at 05:27:03PM +0200, Sebastian Hesselbarth wrote:
> >> I don't have a strong opinion on whether Soeren's or your proposal should
> >> be submitted. But I insist on having one of them in, as GRO significantly
> >> improves the common use case, is enabled by default, and not as
> >> constrained as LRO.
> >
> > I agree, use yours first, but we should keep an eye on this. Since you have
> > everything to run a test, please try to see if you can get netperf to run
> > over IPv6, I'm sure the NIC doesn't handle it.
> 
> Willy,
> 
> out of curiosity I replayed all tests using netperf/netserver with -6 which
> enables ipv6. The overall results remain quite the same here:
> enabling support for GRO gives a huge improvement in achievable
> throughput, and the difference between Soeren's and your patch is
> neglectible.

Perfect, thank you for testing this !

Best regards,
Willy



From jason at lakedaemon.net  Thu Apr 11 13:14:33 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Thu, 11 Apr 2013 13:14:33 -0400
Subject: [PATCHv2 02/10] bus: mvebu: fix mistake in PCIe window target
 attribute for Kirkwood
In-Reply-To: <1365632436-25367-3-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1365632436-25367-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1365632436-25367-3-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <20130411171433.GJ28693@titan.lakedaemon.net>

On Thu, Apr 11, 2013 at 12:20:28AM +0200, Thomas Petazzoni wrote:
> The target and attributes for the PCIe address decoding windows were
> not correct on Kirkwood for the second PCIe interface.
> 
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> ---
> Note: this patch should be merged with the existing mvebu-mbus driver.
> ---
>  drivers/bus/mvebu-mbus.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Applied to mvebu/drivers

thx,

Jason.


From olof at lixom.net  Thu Apr 11 13:14:43 2013
From: olof at lixom.net (Olof Johansson)
Date: Thu, 11 Apr 2013 10:14:43 -0700
Subject: [GIT PULL v2] Reset controller API
In-Reply-To: <1365683829.4388.52.camel@pizza.hi.pengutronix.de>
References: <1365495574.4023.32.camel@pizza.hi.pengutronix.de>
 <20130411102047.GA7437@quad.lixom.net>
 <CAOesGMidoasD35LL4VvCUPwTPrrRE9hxPGUVmuGQtuvH_nxs0g@mail.gmail.com>
 <1365683829.4388.52.camel@pizza.hi.pengutronix.de>
Message-ID: <20130411171443.GB31066@quad.lixom.net>

On Thu, Apr 11, 2013 at 02:37:09PM +0200, Philipp Zabel wrote:
> Hi Olof,
> 
> Am Donnerstag, den 11.04.2013, 03:25 -0700 schrieb Olof Johansson:
> > On Thu, Apr 11, 2013 at 3:20 AM, Olof Johansson <olof at lixom.net> wrote:
> > > On Tue, Apr 09, 2013 at 10:19:34AM +0200, Philipp Zabel wrote:
> > >> Hi Olof,
> > >>
> > >> I have added two fixes on top of the reset series at
> > >> git://git.pengutronix.de/git/pza/linux.git reset/for_v3.10.
> > >> Could you pull them in together with the rest?
> > >>
> > >> The following changes since commit 8bb9660418e05bb1845ac1a2428444d78e322cc7:
> > >>
> > >>   Linux 3.9-rc4 (2013-03-23 16:52:44 -0700)
> > >>
> > >> are available in the git repository at:
> > >>
> > >>   git://git.pengutronix.de/git/pza/linux.git reset/for_v3.10
> > >>
> > >> for you to fetch changes up to fbdb93ecb869f02a5f8f145fa06a0984c415a7d4:
> > >>
> > >>   Documentation: gpio-reset.txt: Fix 'initially-in-reset' example (2013-04-09 09:55:00 +0200)
> > >>
> > >> They add a simple API for devices to request being reset by separate
> > >> reset controller hardware and implement the reset signal device tree
> > >> bindings proposed by Stephen Warren.
> > >> The patches have been discussed on the linux-arm-kernel list under the topic
> > >> "Reset controller API to reset IP modules on i.MX5 and i.MX6".
> > >>
> > >> ----------------------------------------------------------------
> > >> Dan Carpenter (1):
> > >>       reset: NULL deref on allocation failure
> > >>
> > >> Fabio Estevam (1):
> > >>       Documentation: gpio-reset.txt: Fix 'initially-in-reset' example
> > >>
> > >> Philipp Zabel (2):
> > >>       reset: Add reset controller API
> > >>       reset: Add driver for gpio-controlled reset pins
> > >>
> > >> Stephen Warren (1):
> > >>       dt: describe base reset signal binding
> > >
> > > Hmm, I don't see an ack or reviewed-by on these subsystem bindings from
> > > neither Rob nor Grant.
> > >
> > > Since it's a brand new subsystem binding, I'd like to see them ack it
> > > before we pick it up.
> > 
> > Sigh. Ok, so I now stumbled across the Ack from Rob that you didn't
> > pick up. Don't do it like that again, please. If Shawn prematurely
> > bases his code on top of unacked patches, then that's his problem, not
> > yours.
> 
> Sorry I didn't notice that Rob's ack didn't have you in Cc. So shall I
> leave the dt binding patch untouched this time? I'll take note of this
> for the future.

See below.

> > The problem still remains though, since the gpio-reset binding hasn't
> > seen an ack on the list, as far as I can tell. And I'll have a comment
> > on that as well in a minute, see separate reply on that patch.
> 
> Ok. What would you have me do now? I could revert the gpio-reset patch
> (possibly asking Shawn to pull that, too), and have it do another round
> on the list instead. Or I could address your comments with a relative
> patch, and put that on top.

This is a case where rebase is fine, as far as I am concerned. Just tell
Shawn to also rebase his dependent code accordingly. That way you can
add Rob's ack too.

Once the bindings have been ironed out you can add it back, but that's looking
like 3.11 material now.


-Olof



From broonie at opensource.wolfsonmicro.com  Thu Apr 11 13:19:38 2013
From: broonie at opensource.wolfsonmicro.com (Mark Brown)
Date: Thu, 11 Apr 2013 18:19:38 +0100
Subject: [PATCH 18/30] ASoC: samsung: move plat/ headers to local directory
In-Reply-To: <201304111908.42532.arnd@arndb.de>
References: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
 <1365638712-1028578-19-git-send-email-arnd@arndb.de>
 <20130411164751.GK9243@opensource.wolfsonmicro.com>
 <201304111908.42532.arnd@arndb.de>
Message-ID: <20130411171938.GS9243@opensource.wolfsonmicro.com>

On Thu, Apr 11, 2013 at 07:08:42PM +0200, Arnd Bergmann wrote:
> On Thursday 11 April 2013, Mark Brown wrote:

> > This doesn't apply to my topic/samsung branch, can you please regenerate
> > it against that or let me know what to apply it against?

> This one should work. Unfortunately I now found during testing that the
> s3c24xx sound support has a few build errors at the moment, but this
> patch should not add any new ones:

Applied (after hand editing the commit message), thanks.

> make[5]: *** [sound/soc/samsung/i2s.o] Error 1
> /git/arm-soc/sound/soc/samsung/neo1973_wm8753.c:25:24: fatal error: mach/gta02.h: No such file or directory
>  #include <mach/gta02.h>

Hrm, someone killed GTA02 support?  That's sad...  if that's really the
case we could kill the machine driver but not tonight as I'm running
late...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130411/bfb89cc1/attachment.sig>

From shc_work at mail.ru  Thu Apr 11 13:23:22 2013
From: shc_work at mail.ru (Alexander Shiyan)
Date: Thu, 11 Apr 2013 21:23:22 +0400
Subject: [PATCH] GPIO: gpio-generic: Remove kfree() from bgpio_remove call
Message-ID: <1365701002-17292-1-git-send-email-shc_work@mail.ru>

Memory for basic-mmio-gpio driver is allocated by resource managed
function, so using kfree() call in bgpio_remove is wrong.
This patch eliminates this kfree() call.

Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
---
 drivers/gpio/gpio-generic.c | 6 +-----
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/gpio/gpio-generic.c b/drivers/gpio/gpio-generic.c
index 42d4706..d2196bf 100644
--- a/drivers/gpio/gpio-generic.c
+++ b/drivers/gpio/gpio-generic.c
@@ -390,11 +390,7 @@ static int bgpio_setup_direction(struct bgpio_chip *bgc,
 
 int bgpio_remove(struct bgpio_chip *bgc)
 {
-	int err = gpiochip_remove(&bgc->gc);
-
-	kfree(bgc);
-
-	return err;
+	return gpiochip_remove(&bgc->gc);
 }
 EXPORT_SYMBOL_GPL(bgpio_remove);
 
-- 
1.8.1.5



From jason at lakedaemon.net  Thu Apr 11 13:27:46 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Thu, 11 Apr 2013 13:27:46 -0400
Subject: [PATCH v7 1/5] drivers: memory: Introduce Marvell EBU Device
 Bus driver
In-Reply-To: <1365620644-15790-2-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1365620644-15790-1-git-send-email-ezequiel.garcia@free-electrons.com>
 <1365620644-15790-2-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <20130411172746.GK28693@titan.lakedaemon.net>

On Wed, Apr 10, 2013 at 04:04:00PM -0300, Ezequiel Garcia wrote:
> Marvell EBU SoCs such as Armada 370/XP, Orion5x (88f5xxx) and
> Discovery (mv78xx0) supports a Device Bus controller to access several
> kinds of memories and I/O devices (NOR, NAND, SRAM, FPGA).
> 
> This commit adds a driver to handle this controller. So far only
> Armada 370, Armada XP and Discovery SoCs are supported.
> 
> The driver must be registered through a device tree node;
> as explained in the binding document.
> 
> For each child node in the device tree, this driver will:
>   * set timing parameters
>   * register a child device
>   * setup an address decoding window, using the mbus driver
> 
> Keep in mind the address decoding window setup is only a temporary hack.
> This code will be removed from this devbus driver as soon as a proper device
> tree binding for the mbus driver is added.
> 
> Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
> Acked-by: Arnd Bergmann <arnd at arndb.de>
> ---
>  .../bindings/memory-controllers/mvebu-devbus.txt   | 156 ++++++++++
>  drivers/memory/Kconfig                             |  10 +
>  drivers/memory/Makefile                            |   1 +
>  drivers/memory/mvebu-devbus.c                      | 340 +++++++++++++++++++++
>  4 files changed, 507 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/memory-controllers/mvebu-devbus.txt
>  create mode 100644 drivers/memory/mvebu-devbus.c

Applied to mvebu/drivers with gregkh's ack.

thx,

Jason.


From olof at lixom.net  Thu Apr 11 13:31:22 2013
From: olof at lixom.net (Olof Johansson)
Date: Thu, 11 Apr 2013 10:31:22 -0700
Subject: [GIT PULL] Renesas ARM and SH based SoC pinmux fixes for v3.10
In-Reply-To: <1365569475-28721-1-git-send-email-horms+renesas@verge.net.au>
References: <1365569475-28721-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <20130411173122.GA373@quad.lixom.net>

On Wed, Apr 10, 2013 at 01:51:14PM +0900, Simon Horman wrote:
> Hi Arnd, Hi Olof,
> 
> The following changes since commit 202ac6a21a79500ef5aab4cd8665be2597e9345c:
> 
>   sh-pfc: r8a73a4: Remove unused GPIO bias data (2013-04-03 10:30:43 +0900)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas tags/renesas-pinmux-fixes-for-v3.10

Pulled in on top of previous pinmux branch, part of next/soc2.

Thanks!


-Olof


From davem at davemloft.net  Thu Apr 11 13:31:19 2013
From: davem at davemloft.net (David Miller)
Date: Thu, 11 Apr 2013 13:31:19 -0400 (EDT)
Subject: [PATCH] net: mv643xx_eth: Add GRO support
In-Reply-To: <CABJ1b_TRxm97DKJLP_h0VwMJvcYmSpjoJvtg1KvBNGah=VzqMQ@mail.gmail.com>
References: <CABJ1b_TQDabT1J7ffo5cb1Th=71bcSduifMJaDpfVRiiHvtWDw@mail.gmail.com>
 <20130411150326.GA19978@1wt.eu>
 <CABJ1b_TRxm97DKJLP_h0VwMJvcYmSpjoJvtg1KvBNGah=VzqMQ@mail.gmail.com>
Message-ID: <20130411.133119.913809939413807690.davem@davemloft.net>

From: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
Date: Thu, 11 Apr 2013 17:27:03 +0200

> On Thu, Apr 11, 2013 at 5:03 PM, Willy Tarreau <w at 1wt.eu> wrote:
>> On Thu, Apr 11, 2013 at 04:47:49PM +0200, Sebastian Hesselbarth wrote:
>>> I tried todays net-next on top of 3.9-rc6 without any gro patch, with
>>> the initial
>>> patch (Soeren) and your proposed patch (Willy). The results show that
>>> both patches
>>> allow a significant increase in throughput compared to
>>> netif_receive_skb (!gro, !lro)
>>> alone. Having gro with lro disabled gives some 2% more throughput
>>> compared to lro only.
>>
>> Indeed this is consistent with my memories, since Eric improved the
>> GRO path, it became faster than LRO on this chip.
> 
> I don't have a strong opinion on whether Soeren's or your proposal should
> be submitted. But I insist on having one of them in, as GRO significantly
> improves the common use case, is enabled by default, and not as
> constrained as LRO.

I think, as per other drivers, LRO should be eliminated completely from
all drivers, including this one, and GRO used exclusively instead.


From jason at lakedaemon.net  Thu Apr 11 13:33:34 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Thu, 11 Apr 2013 13:33:34 -0400
Subject: [PATCH v7 2/5] ARM: mvebu: Add Device Bus support for Armada
 370/XP SoC
In-Reply-To: <1365620644-15790-3-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1365620644-15790-1-git-send-email-ezequiel.garcia@free-electrons.com>
 <1365620644-15790-3-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <20130411173334.GL28693@titan.lakedaemon.net>

On Wed, Apr 10, 2013 at 04:04:01PM -0300, Ezequiel Garcia wrote:
> Armada 370 and Armada XP SoC have a Device Bus controller to
> handle NOR, NAND, SRAM and FPGA devices.
> This patch adds the device tree node to enable the controller.
> 
> Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
> Acked-by: Arnd Bergmann <arnd at arndb.de>
> ---
>  arch/arm/boot/dts/armada-370-xp.dtsi | 45 ++++++++++++++++++++++++++++++++++++
>  1 file changed, 45 insertions(+)

Patches 2 through 5 applied to mvebu/dt

thx,

Jason.


From olof at lixom.net  Thu Apr 11 13:34:52 2013
From: olof at lixom.net (Olof Johansson)
Date: Thu, 11 Apr 2013 10:34:52 -0700
Subject: [GIT PULL] Renesas ARM based r8a7790 SoC update for v3.10
In-Reply-To: <1365668101-21723-1-git-send-email-horms+renesas@verge.net.au>
References: <1365668101-21723-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <20130411173452.GB373@quad.lixom.net>

On Thu, Apr 11, 2013 at 05:14:59PM +0900, Simon Horman wrote:
> Hi Arnd, Hi Olof,
> 
> The following changes since commit 8585deb18580d04209a2986430aa0959ef38fce2:
> 
>   ARM: shmobile: r8a7790 SoC 64-bit DT support (2013-04-02 11:02:21 +0900)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-soc-r8a7790-for-v3.10

Pulled into next/soc2.


-Olof


From linus.walleij at linaro.org  Thu Apr 11 13:35:21 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 11 Apr 2013 19:35:21 +0200
Subject: [PATCH] GPIO: gpio-generic: Remove kfree() from bgpio_remove call
In-Reply-To: <1365701002-17292-1-git-send-email-shc_work@mail.ru>
References: <1365701002-17292-1-git-send-email-shc_work@mail.ru>
Message-ID: <CACRpkdZ8X1O7O+wVSYR6Q_e9QBV42707SO-Mx+dfUPjpO=mYvw@mail.gmail.com>

On Thu, Apr 11, 2013 at 7:23 PM, Alexander Shiyan <shc_work at mail.ru> wrote:

> Memory for basic-mmio-gpio driver is allocated by resource managed
> function, so using kfree() call in bgpio_remove is wrong.
> This patch eliminates this kfree() call.
>
> Signed-off-by: Alexander Shiyan <shc_work at mail.ru>

So I think the patch is correct but the commit message is wrong.

It is not certain at all that bgpio is resource managed, but the point
of the patch should be that it's up to the driver using it to allocate
and free its struct bgpio_chip, after calling this function.

A quick glance on the consumers gives at hand that this is the case
for all consumers, so I took the liberty to update the commit
message and apply it...

Yours,
Linus Walleij


From eric.dumazet at gmail.com  Thu Apr 11 13:35:25 2013
From: eric.dumazet at gmail.com (Eric Dumazet)
Date: Thu, 11 Apr 2013 10:35:25 -0700
Subject: [PATCH] net: mv643xx_eth: Add GRO support
In-Reply-To: <20130411.133119.913809939413807690.davem@davemloft.net>
References: <CABJ1b_TQDabT1J7ffo5cb1Th=71bcSduifMJaDpfVRiiHvtWDw@mail.gmail.com>
 <20130411150326.GA19978@1wt.eu>
 <CABJ1b_TRxm97DKJLP_h0VwMJvcYmSpjoJvtg1KvBNGah=VzqMQ@mail.gmail.com>
 <20130411.133119.913809939413807690.davem@davemloft.net>
Message-ID: <1365701725.3887.177.camel@edumazet-glaptop>

On Thu, 2013-04-11 at 13:31 -0400, David Miller wrote:

> I think, as per other drivers, LRO should be eliminated completely from
> all drivers, including this one, and GRO used exclusively instead.

This would be awesome.

AFAIK current LRO users are :

drivers/infiniband/hw/nes/nes_hw.c
drivers/net/ethernet/marvell/mv643xx_eth.c
drivers/net/ethernet/pasemi/pasemi_mac.c





From olof at lixom.net  Thu Apr 11 13:38:19 2013
From: olof at lixom.net (Olof Johansson)
Date: Thu, 11 Apr 2013 10:38:19 -0700
Subject: [GIT PULL] Renesas ARM based SoC lager board updates for v3.10
In-Reply-To: <1365668326-22518-1-git-send-email-horms+renesas@verge.net.au>
References: <1365668326-22518-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <20130411173819.GC373@quad.lixom.net>

On Thu, Apr 11, 2013 at 05:18:45PM +0900, Simon Horman wrote:
> Hi Arnd, Hi Olof,
> 
> Please note this is based on a merge with renesas-soc-r8a7790-for-v3.10
> which corresponds to the pull request I sent a few minutes ago:
> "[GIT PULL] Renesas ARM based r8a7790 SoC update for v3.10".
> 
> The following changes since commit ac119ccd80eb914185229c4c4086f3debdd4c764:
> 
>   Merge branch 'soc-r8a7790' into boards-lager (2013-04-09 21:40:20 +0900)
> 
> are available in the git repository at:
> 
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-boards-lager-for-v3.10
> 
> for you to fetch changes up to 65be2de17aae0fd94e55f7c4a474933cf4607ea2:
> 
>   ARM: shmobile: use r8a7790 timer setup code on Lager (2013-04-09 21:40:59 +0900)
> 
> ----------------------------------------------------------------
> Renesas ARM based SoC lager board updates for v3.10
> 
> * Use r8a7790 timer setup code to force the
>   arch timer to be enabled regardless of the bootloader setting
>   - This is necessary for the lager board to boot
> 
> This pull request is based on:
> git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git renesas-boards3-for-v3.10
> git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git renesas-soc-r8a7790-for-v3.10
> 
> The merge was made to provide the r8a7790 timer setup code

Pulled.

By the way, the dependencies above are probably better described in
the email than in the tag, since there's a good chance your branches
will be gone from kernel.org by the time someone reads the changelog;
i.e. it doesn't really provide useful information for the changelog. It's very
useful for us though so please continue to provide it.


-Olog


From shc_work at mail.ru  Thu Apr 11 13:38:53 2013
From: shc_work at mail.ru (=?UTF-8?B?QWxleGFuZGVyIFNoaXlhbg==?=)
Date: Thu, 11 Apr 2013 21:38:53 +0400
Subject: =?UTF-8?B?UmVbMl06IFtQQVRDSF0gR1BJTzogZ3Bpby1nZW5lcmljOiBSZW1vdmUga2Zy?=
 =?UTF-8?B?ZWUoKSBmcm9tIGJncGlvX3JlbW92ZSBjYWxs?=
References: <1365701002-17292-1-git-send-email-shc_work@mail.ru>
Message-ID: <1365701933.646047659@f77.mail.ru>

> On Thu, Apr 11, 2013 at 7:23 PM, Alexander Shiyan <shc_work at mail.ru> wrote:
> 
> > Memory for basic-mmio-gpio driver is allocated by resource managed
> > function, so using kfree() call in bgpio_remove is wrong.
> > This patch eliminates this kfree() call.
> >
> > Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
> 
> So I think the patch is correct but the commit message is wrong.
> 
> It is not certain at all that bgpio is resource managed, but the point
> of the patch should be that it's up to the driver using it to allocate
> and free its struct bgpio_chip, after calling this function.
> 
> A quick glance on the consumers gives at hand that this is the case
> for all consumers, so I took the liberty to update the commit
> message and apply it...

OK, no problem.

---

From w at 1wt.eu  Thu Apr 11 13:51:47 2013
From: w at 1wt.eu (Willy Tarreau)
Date: Thu, 11 Apr 2013 19:51:47 +0200
Subject: [PATCH] net: mv643xx_eth: Add GRO support
In-Reply-To: <20130411.133119.913809939413807690.davem@davemloft.net>
References: <CABJ1b_TQDabT1J7ffo5cb1Th=71bcSduifMJaDpfVRiiHvtWDw@mail.gmail.com>
 <20130411150326.GA19978@1wt.eu>
 <CABJ1b_TRxm97DKJLP_h0VwMJvcYmSpjoJvtg1KvBNGah=VzqMQ@mail.gmail.com>
 <20130411.133119.913809939413807690.davem@davemloft.net>
Message-ID: <20130411175147.GN1910@1wt.eu>

On Thu, Apr 11, 2013 at 01:31:19PM -0400, David Miller wrote:
> From: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
> Date: Thu, 11 Apr 2013 17:27:03 +0200
> 
> > On Thu, Apr 11, 2013 at 5:03 PM, Willy Tarreau <w at 1wt.eu> wrote:
> >> On Thu, Apr 11, 2013 at 04:47:49PM +0200, Sebastian Hesselbarth wrote:
> >>> I tried todays net-next on top of 3.9-rc6 without any gro patch, with
> >>> the initial
> >>> patch (Soeren) and your proposed patch (Willy). The results show that
> >>> both patches
> >>> allow a significant increase in throughput compared to
> >>> netif_receive_skb (!gro, !lro)
> >>> alone. Having gro with lro disabled gives some 2% more throughput
> >>> compared to lro only.
> >>
> >> Indeed this is consistent with my memories, since Eric improved the
> >> GRO path, it became faster than LRO on this chip.
> > 
> > I don't have a strong opinion on whether Soeren's or your proposal should
> > be submitted. But I insist on having one of them in, as GRO significantly
> > improves the common use case, is enabled by default, and not as
> > constrained as LRO.
> 
> I think, as per other drivers, LRO should be eliminated completely from
> all drivers, including this one, and GRO used exclusively instead.

Eric provided me with one such experimental patch in the past for this
driver. It worked for me but we never tried to clean it up to propose
it for inclusion.

If anyone is interested, I might still have it in experimental shape.

Willy



From olof at lixom.net  Thu Apr 11 13:53:19 2013
From: olof at lixom.net (Olof Johansson)
Date: Thu, 11 Apr 2013 10:53:19 -0700
Subject: [GIT PULL 8/8] ARM: tegra: defconfig changes
In-Reply-To: <201304091716.36058.arnd@arndb.de>
References: <1365181426-11547-1-git-send-email-swarren@wwwdotorg.org>
 <1365181426-11547-8-git-send-email-swarren@wwwdotorg.org>
 <201304091716.36058.arnd@arndb.de>
Message-ID: <20130411175319.GD373@quad.lixom.net>

On Tue, Apr 09, 2013 at 05:16:35PM +0200, Arnd Bergmann wrote:
> On Friday 05 April 2013, Stephen Warren wrote:
> > Various new features are enabled:
> > 
> > * Tegra114 support.
> > * Various PMICs and related options for Tegra114 platforms.
> > * KEYBOARD_GPIO, mainly as a suspend wakeup source.
> > * tegra_defconfig is rebuilt based on v3.9-rc1, which causes various
> >   layout changes.
> > 
> > This branch is based on v3.9-rc1.
> 
> Pulled into next/soc.
> 
> I'm currently thinking about creating a next/defconfig branch after all,
> since we have a couple of pull requests in next/soc that only do
> defconfig changes. Olof, any opinion?

Sorry, didn't see this until now. Either way is fine with me. Main reason
for not keeping it in a branch on its own is that defconfig churn is
usually frowned upon and it makes some sense to show that it's caused
by other development (soc/board/etc).  But if we have enough volume to
keep separate then that's fine too.

Also, if we keep it separate we can always merge it together with another
branch before sending it up if it's very small for a particular merge window.


-Olof


From robherring2 at gmail.com  Thu Apr 11 13:55:20 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Thu, 11 Apr 2013 12:55:20 -0500
Subject: [RFC PATCH 01/11] Documentation: DT: arm: define CPU topology
 bindings
In-Reply-To: <20130411155054.GA29509@e102568-lin.cambridge.arm.com>
References: <1365671562-2403-1-git-send-email-mark.rutland@arm.com>
 <1365671562-2403-2-git-send-email-mark.rutland@arm.com>
 <5166D01F.5070404@gmail.com>
 <20130411155054.GA29509@e102568-lin.cambridge.arm.com>
Message-ID: <5166F908.9050503@gmail.com>

On 04/11/2013 10:50 AM, Lorenzo Pieralisi wrote:
> On Thu, Apr 11, 2013 at 04:00:47PM +0100, Rob Herring wrote:
>> On 04/11/2013 04:12 AM, Mark Rutland wrote:
>>> From: Lorenzo Pieralisi <Lorenzo.Pieralisi at arm.com>
>>>
>>> The advent of multi-cluster ARM systems requires a mechanism to describe
>>> how in hierarchical terms CPUs are connected in ARM SoCs so that the kernel
>>> can initialize and map resources like IRQs and memory space to specific
>>> group(s) of CPUs.
>>>
>>> The CPU topology is made up of multiple hierarchy levels whose bottom
>>> layers (aka leaf nodes in device tree syntax) contain links to the HW
>>> CPUs in the system.
>>>
>>> The topology bindings are generic for both 32-bit and 64-bit systems and
>>> lay the groundwork on top of which affinity schemes can be built.
>>>
>>> This patch provides the documentation in the kernel required to define the
>>> device tree bindings describing the CPU topology for ARM 32-bit and 64-bit
>>> systems.
>>
>> I'm now very weary of continued /cpu changes after the pain of making
>> the reg property reflect the mpidr value in 3.8.
> 
> We won't change the reg property value, the code I am about to post
> provides stricter bindings, stricter semantics and extends bindings to
> cater for arm 64-bit systems.
> 
>>> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
>>> Signed-off-by: Mark Rutland <mark.rutland at arm.com>
>>> ---
>>>  Documentation/devicetree/bindings/arm/topology.txt | 524 +++++++++++++++++++++
>>>  1 file changed, 524 insertions(+)
>>>  create mode 100644 Documentation/devicetree/bindings/arm/topology.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/arm/topology.txt b/Documentation/devicetree/bindings/arm/topology.txt
>>> new file mode 100644
>>> index 0000000..07c4961
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/arm/topology.txt
>>> @@ -0,0 +1,524 @@
>>> +===========================================
>>> +ARM topology binding description
>>> +===========================================
>>> +
>>> +===========================================
>>> +1 - Introduction
>>> +===========================================
>>> +
>>> +In an ARM system, the hierarchy of CPUs is defined through three entities that
>>> +are used to describe the layout of physical CPUs in the system:
>>> +
>>> +- cluster
>>> +- core
>>> +- thread
>>> +
>>> +The cpu nodes (bindings defined in [1]) represent the devices that
>>> +correspond to physical CPUs and are to be mapped to the hierarchy levels.
>>> +
>>> +The bottom hierarchy level sits at core or thread level depending on whether
>>> +symmetric multi-threading (SMT) is supported or not.
>>> +
>>> +For instance in a system where CPUs support SMT, "cpu" nodes represent all
>>> +threads existing in the system and map to the hierarchy level "thread" above.
>>> +In systems where SMT is not supported "cpu" nodes represent all cores present
>>> +in the system and map to the hierarchy level "core" above.
>>> +
>>> +ARM topology bindings allow one to associate cpu nodes with hierarchical groups
>>> +corresponding to the system hierarchy; syntactically they are defined as device
>>> +tree nodes.
>>> +
>>> +The remainder of this document provides the topology bindings for ARM, based
>>> +on the ePAPR standard, available from:
>>> +
>>> +http://devicetree.org
>>> +
>>> +If not stated otherwise, whenever a reference to a cpu node phandle is made its
>>> +value must point to a cpu node compliant with the cpu node bindings as
>>> +documented in [1].
>>> +A topology description containing phandles to cpu nodes that are not compliant
>>> +with bindings standardized in [1] is therefore considered invalid.
>>> +
>>> +===========================================
>>> +2 - cpu-map node
>>> +===========================================
>>> +
>>> +The ARM CPU topology is defined within a container node, sitting at the top
>>> +level of the device tree (/), the cpu-map node.
>>> +
>>> +- cpu-map node
>>> +
>>> +	Usage: Required to define ARM CPU topology
>>> +
>>> +	Description: The cpu-map node is just a container node where its
>>> +		     subnodes describe the CPU topology
>>> +
>>> +	Node name must be "cpu-map".
>>> +
>>> +	A cpu-map node's child nodes can be:
>>> +
>>> +	- one or more cluster nodes
>>> +
>>> +	Any other configuration is considered invalid.
>>> +
>>> +The cpu-map node can only contain three types of child nodes:
>>> +
>>> +- cluster node
>>> +- core node
>>> +- thread node
>>> +
>>
>> Why not put the topology in the /cpus nodes? I don't really see the
>> point of having a flat list of cpus and separate topology info. There is
>> some compatibility issue, but adding optional levels for clusters can be
>> handled.
> 
> I thought this would break all code relying on /cpu nodes being /cpus node's
> children. Furthermore, I was told that the /cpus node can only have /cpu nodes
> as children.

IIRC the context, that was in regards to putting things like the PMUs
under the /cpus node. Or are you referring to something else? I think
this situation is a bit different.

You will have to support existing single cluster systems without the
hierarchy.

> 
> If you wish so, we can define the topology in the /cpus node, fine by me.
> 
>>> +whose bindings are described in paragraph 3.
>>> +
>>> +The nodes describing the CPU topology (cluster/core/thread) can only be
>>> +defined within the cpu-map node.
>>> +Any other configuration is consider invalid and therefore must be ignored.
>>> +
>>> +===========================================
>>> +2.1 - cpu-map child nodes naming convention
>>> +===========================================
>>> +
>>> +cpu-map child nodes must follow a naming convention where the node name
>>> +must be "clusterN", "coreN", "threadN" depending on the node type (ie
>>> +cluster/core/thread) (where N = {0, 1, ...} is the node number; nodes which
>>> +are siblings within a single common parent node must be given a unique and
>>> +sequential N value, starting from 0).
>>> +cpu-map child nodes which do not share a common parent node can have the same
>>> +name (ie same number N as other cpu-map child nodes at different device tree
>>> +levels) since name uniqueness will be guaranteed by the device tree hierarchy.
>>> +
>>> +===========================================
>>> +3 - cluster/core/thread node bindings
>>> +===========================================
>>> +
>>> +Bindings for cluster/cpu/thread nodes are defined as follows:
>>> +
>>> +- cluster node
>>> +
>>> +	 Description: must be declared within a cpu-map node, one node
>>> +		      per cluster. A system can contain several layers of
>>> +		      clustering and cluster nodes can be contained in parent
>>> +		      cluster nodes.
>>> +
>>> +	The cluster node name must be "clusterN" as described in 2.1 above.
>>> +	A cluster node can not be a leaf node.
>>
>> Follow standard conventions with "cluster at N" and a reg property with the
>> number.
> 
> We are defining the topology to decouple the cluster/core/thread concept
> from the MPIDR. Having a reg property in the cluster (and core) nodes
> would complicate things if that reg property must correspond to an MPIDR
> bitfield. If it is meant to be just an enumeration at a given device tree
> level, I am ok with changing that.

Because the cluster itself doesn't really have an id, I'm fine if its
not linked to the mpidr. Just don't change that later.

>>> +
>>> +	A cluster node's child nodes must be:
>>> +
>>> +	- one or more cluster nodes; or
>>> +	- one or more core nodes
>>> +
>>> +	Any other configuration is considered invalid.
>>> +
>>> +- core node
>>> +
>>> +	Description: must be declared in a cluster node, one node per core in
>>> +		     the cluster. If the system does not support SMT, core
>>> +		     nodes are leaf nodes, otherwise they become containers of
>>> +		     thread nodes.
>>> +
>>> +	The core node name must be "coreN" as described in 2.1 above.
>>> +
>>> +	A core node must be a leaf node if SMT is not supported.
>>> +
>>> +	Properties for core nodes that are leaf nodes:
>>> +
>>> +	- cpu
>>> +		Usage: required
>>> +		Value type: <phandle>
>>> +		Definition: a phandle to the cpu node that corresponds to the
>>> +			    core node.
>>> +
>>> +	If a core node is not a leaf node (CPUs supporting SMT) a core node's
>>> +	child nodes can be:
>>> +
>>> +	- one or more thread nodes
>>> +
>>> +	Any other configuration is considered invalid.
>>> +
>>> +- thread node
>>> +
>>> +	Description: must be declared in a core node, one node per thread
>>> +		     in the core if the system supports SMT. Thread nodes are
>>> +		     always leaf nodes in the device tree.
>>> +
>>> +	The thread node name must be "threadN" as described in 2.1 above.
>>> +
>>> +	A thread node must be a leaf node.
>>> +
>>> +	A thread node must contain the following property:
>>> +
>>> +	- cpu
>>> +		Usage: required
>>> +		Value type: <phandle>
>>> +		Definition: a phandle to the cpu node that corresponds to
>>> +			    the thread node.
>>
>>
>> According to the ePAPR, threads are represented by an array of ids for
>> reg property, not another cpu node. Why the deviation.
> 
> It is not a cpu node, it is a phandle property named cpu. Can you point
> me to the ePAPR section where threads bindings are described please ? I have
> not managed to find these details, I am reading version 1.0.
> 
You should get 1.1.

>From the reg prop description:

If a CPU supports more than one thread (i.e. multiple streams of
execution) the reg property is an array with 1 element per thread. The
#address-cells on the /cpus node specifies how many cells each element
of the array takes. Software can determine the number of threads by
dividing the size of reg by the parent node's #address-cells.
If a CPU/thread can be the target of an external interrupt the "reg"
property value must be a unique CPU/thread id that is addressable by
the interrupt controller.
If a CPU/thread cannot be the target of an external interrupt, then "reg"
must be unique and out of bounds of the range addressed by the
interrupt controller
If a CPU/thread's PIR is modifiable, a client program should modify
PIR to match the "reg" property value. If PIR cannot be modified and
the PIR value is distinct from the interrupt controller numberspace, the
CPUs binding may define a binding-specific representation of PIR
values if desired.


There is also this statement:

Hardware threads that share an MMU would generally be represented under
one cpu node. If other
more complex CPU topographies are designed, the binding for the CPU must
describe the topography
(e.g. threads that don't share an MMU).

Rob


From lauraa at codeaurora.org  Thu Apr 11 13:56:02 2013
From: lauraa at codeaurora.org (Laura Abbott)
Date: Thu, 11 Apr 2013 10:56:02 -0700
Subject: [RFC/PATCH v2 2/2] drivers: dma-contiguous: add initialization
 from device tree
In-Reply-To: <1365679330-2514-3-git-send-email-m.szyprowski@samsung.com>
References: <1365679330-2514-1-git-send-email-m.szyprowski@samsung.com>
 <1365679330-2514-3-git-send-email-m.szyprowski@samsung.com>
Message-ID: <5166F932.9000003@codeaurora.org>

Hi,

On 4/11/2013 4:22 AM, Marek Szyprowski wrote:
...
> +
> diff --git a/drivers/base/dma-contiguous.c b/drivers/base/dma-contiguous.c
> index 01fe743..6a8abab 100644
> --- a/drivers/base/dma-contiguous.c
> +++ b/drivers/base/dma-contiguous.c
> @@ -24,6 +24,9 @@
>
>   #include <linux/memblock.h>
>   #include <linux/err.h>
> +#include <linux/of.h>
> +#include <linux/of_fdt.h>
> +#include <linux/of_platform.h>
>   #include <linux/mm.h>
>   #include <linux/mutex.h>
>   #include <linux/page-isolation.h>
> @@ -37,6 +40,7 @@ struct cma {
>   	unsigned long	base_pfn;
>   	unsigned long	count;
>   	unsigned long	*bitmap;
> +	char		full_name[32];
>   };
>
>   static DEFINE_MUTEX(cma_mutex);
> @@ -133,6 +137,53 @@ static __init int cma_activate_area(struct cma *cma)
>   	return 0;
>   }
>
> +/*****************************************************************************/
> +
> +#ifdef CONFIG_OF
> +int __init cma_fdt_scan(unsigned long node, const char *uname,
> +				int depth, void *data)
> +{
> +	static int level;
> +	phys_addr_t base, size;
> +	unsigned long len;
> +	struct cma *cma;
> +	__be32 *prop;
> +
> +	if (depth == 1 && strcmp(uname, "chosen") == 0) {
> +		level = depth;
> +		return 0;
> +	}
> +
> +	if (depth == 2 && strcmp(uname, "contiguous-memory") == 0) {
> +		level = depth;
> +		return 0;
> +	}
> +
> +	if (level != 2 || depth != 3 || strncmp(uname, "region@", 7) != 0)
> +		return 0;
> +

Requiring the region@ label does not work if you want two dynamically 
placed regions (i.e. two region at 0). The devicetree will take the last 
region at 0 entry and ignore all the other ones

> +	prop = of_get_flat_dt_prop(node, "reg", &len);
> +	if (!prop || (len != 2 * sizeof(unsigned long)))
> +		return 0;
> +
> +	base = be32_to_cpu(prop[0]);
> +	size = be32_to_cpu(prop[1]);
> +
> +	pr_info("Found %s, memory base %lx, size %ld MiB\n", uname,
> +		(unsigned long)base, (unsigned long)size / SZ_1M);
> +
> +	dma_contiguous_reserve_area(size, base, 0, &cma);
> +

Need to check the return of dma_contiguous_reserve_area, else there is 
an abort when trying to access cma->name on an error

> +	strcpy(cma->full_name, uname);
> +
> +	if (of_get_flat_dt_prop(node, "linux,default-contiguous-region", NULL)) {
> +
> +		dma_contiguous_default_area = cma;
> +	}
> +	return 0;
> +}
> +#endif
> +
>   /**
>    * dma_contiguous_reserve() - reserve area(s) for contiguous memory handling
>    * @limit: End address of the reserved memory (optional, 0 for any).


if the contiguous region isn't set via devicetree, 
default_area->full_name needs to be set in dma_contiguous_reserve, else 
we get wrong associations in scan_cma_node.

> @@ -149,6 +200,10 @@ void __init dma_contiguous_reserve(phys_addr_t limit)
>
>   	pr_debug("%s(limit %08lx)\n", __func__, (unsigned long)limit);
>
> +#ifdef CONFIG_OF
> +	of_scan_flat_dt(cma_fdt_scan, NULL);
> +#endif
> +
>   	if (size_cmdline != -1) {
>   		sel_size = size_cmdline;
>   	} else {
> @@ -265,6 +320,71 @@ int __init dma_contiguous_add_device(struct device *dev, struct cma *cma)
>   	return 0;
>   }
>
> +#ifdef CONFIG_OF
> +static struct cma_map {
> +	struct cma *cma;
> +	struct device_node *node;
> +} cma_maps[MAX_CMA_AREAS];
> +static unsigned cma_map_count;
> +
> +static void cma_assign_device_from_dt(struct device *dev)
> +{
> +	int i;
> +	for (i=0; i<cma_map_count; i++) {
> +		if (cma_maps[i].node == dev->of_node) {
> +			dev_set_cma_area(dev, cma_maps[i].cma);
> +			pr_info("Assigned CMA %s to %s device\n",
> +				cma_maps[i].cma->full_name,
> +				dev_name(dev));
> +		}
> +	}
> +}
> +
> +static int cma_device_init_notifier_call(struct notifier_block *nb,
> +					 unsigned long event, void *data)
> +{
> +	struct device *dev = data;
> +	if (event == BUS_NOTIFY_ADD_DEVICE && dev->of_node)
> +		cma_assign_device_from_dt(dev);
> +	return NOTIFY_DONE;
> +}
> +
> +static struct notifier_block cma_dev_init_nb = {
> +	.notifier_call = cma_device_init_notifier_call,
> +};
> +
> +void scan_cma_nodes(void)
> +{
> +	struct device_node *parent = of_find_node_by_path("/chosen/contiguous-memory");
> +	struct device_node *child;
> +
> +	if (!parent)
> +		return;
> +
> +	for_each_child_of_node(parent, child) {
> +		struct cma *cma = NULL;
> +		int i;
> +
> +		for (i=0; i<cma_area_count; i++)
> +			if (strstr(child->full_name, cma_areas[i].full_name))
> +				cma = &cma_areas[i];

break out of the loop once the area is found?

Also, how will the code deal with region names that are substrings of 
each other e.g.

region at 1000000
region at 10000000

> +		if (!cma)
> +			continue;
> +
> +		for (i=0;; i++) {
> +			struct device_node *node;
> +			node = of_parse_phandle(child, "device", i);
> +			if (!node)
> +				break;
> +
> +			cma_maps[cma_map_count].cma = cma;
> +			cma_maps[cma_map_count].node = node;
> +			cma_map_count++;

Bounds check cma_map_count against MAX_CMA_AREAS?

> +		}
> +	}
> +}
> +#endif
> +
>   static int __init cma_init_reserved_areas(void)
>   {
>   	int i;
> @@ -275,6 +395,10 @@ static int __init cma_init_reserved_areas(void)
>   			return ret;
>   	}
>
> +#ifdef CONFIG_OF
> +	scan_cma_nodes();
> +	bus_register_notifier(&platform_bus_type, &cma_dev_init_nb);
> +#endif
>   	return 0;
>   }
>   core_initcall(cma_init_reserved_areas);
>

Thanks,
Laura

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation


From bhutchings at solarflare.com  Thu Apr 11 13:55:55 2013
From: bhutchings at solarflare.com (Ben Hutchings)
Date: Thu, 11 Apr 2013 18:55:55 +0100
Subject: [PATCH] net: mv643xx_eth: Add GRO support
In-Reply-To: <1365684023-9967-1-git-send-email-sebastian.hesselbarth@gmail.com>
References: <1365684023-9967-1-git-send-email-sebastian.hesselbarth@gmail.com>
Message-ID: <1365702955.7355.5.camel@bwh-desktop.uk.solarflarecom.com>

On Thu, 2013-04-11 at 14:40 +0200, Sebastian Hesselbarth wrote:
> This patch adds GRO support to mv643xx_eth by making it invoke
> napi_gro_receive instead of netif_receive_skb.

The inet_lro support should be removed at the same time; inet_lro is now
deprecated and there should be no need to keep both of them.

Ben.

> Signed-off-by: Soeren Moch <smoch at web.de>
> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
> ---
> Cc: "David S. Miller" <davem at davemloft.net>
> Cc: Lennert Buytenhek <buytenh at wantstofly.org>
> Cc: Andrew Lunn <andrew at lunn.ch>
> Cc: Jason Cooper <jason at lakedaemon.net>
> Cc: Florian Fainelli <florian at openwrt.org>
> Cc: Benjamin Herrenschmidt <benh at kernel.crashing.org>
> Cc: Paul Mackerras <paulus at samba.org>
> Cc: Dale Farnsworth <dale at farnsworth.org>
> Cc: netdev at vger.kernel.org
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linuxppc-dev at lists.ozlabs.org
> Cc: linux-kernel at vger.kernel.org
> ---
>  drivers/net/ethernet/marvell/mv643xx_eth.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c b/drivers/net/ethernet/marvell/mv643xx_eth.c
> index 305038f..c850d04 100644
> --- a/drivers/net/ethernet/marvell/mv643xx_eth.c
> +++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
> @@ -604,7 +604,7 @@ static int rxq_process(struct rx_queue *rxq, int budget)
>  			lro_receive_skb(&rxq->lro_mgr, skb, (void *)cmd_sts);
>  			lro_flush_needed = 1;
>  		} else
> -			netif_receive_skb(skb);
> +			napi_gro_receive(&mp->napi, skb);
>  
>  		continue;
>  

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.



From mturquette at linaro.org  Thu Apr 11 13:56:13 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Thu, 11 Apr 2013 10:56:13 -0700
Subject: [PATCH 2/3] clk: composite: allow fixed rates & fixed dividers
In-Reply-To: <5166A2E6.70907@nvidia.com>
References: <1365515284-32061-2-git-send-email-emilio@elopez.com.ar>
 <1365631378-16103-1-git-send-email-mturquette@linaro.org>
 <1365631378-16103-3-git-send-email-mturquette@linaro.org>
 <5166A2E6.70907@nvidia.com>
Message-ID: <20130411175613.7915.25443@quantum>

Quoting Prashant Gaikwad (2013-04-11 04:47:50)
> On Thursday 11 April 2013 03:32 AM, Mike Turquette wrote:
> > The composite clock assumes that any clock implementing the .recalc_rate
> > callback will also implement .round_rate and .set_rate.  This is not
> > always true; the basic fixed-rate clock will only implement .recalc_rate
> > and a fixed-divider clock may choose to implement .recalc_rate and
> > .round_rate but not .set_rate.
> >
> > Fix this by conditionally registering .round_rate and .set_rate
> > callbacks based on the rate_ops passed in to clk_composite_register.
> >
> > Signed-off-by: Mike Turquette <mturquette at linaro.org>
> > Cc: Prashant Gaikwad <pgaikwad at nvidia.com>
> > Cc: Emilio L?pez <emilio at elopez.com.ar>
> > Cc: Gregory CLEMENT <gregory.clement at free-electrons.com>
> > ---
> >   drivers/clk/clk-composite.c |   13 +++++++++----
> >   1 file changed, 9 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/clk/clk-composite.c b/drivers/clk/clk-composite.c
> > index 6f4728c..2779fb3 100644
> > --- a/drivers/clk/clk-composite.c
> > +++ b/drivers/clk/clk-composite.c
> > @@ -150,17 +150,22 @@ struct clk *clk_register_composite(struct device *dev, const char *name,
> >       }
> >   
> >       if (rate_hw && rate_ops) {
> > -             if (!rate_ops->recalc_rate || !rate_ops->round_rate ||
> > -                 !rate_ops->set_rate) {
> > +             if (!rate_ops->recalc_rate) {
> >                       clk = ERR_PTR(-EINVAL);
> >                       goto err;
> >               }
> >   
> > +             /* .round_rate is a prerequisite for .set_rate */
> > +             if (rate_ops->round_rate) {
> > +                     clk_composite_ops->round_rate = clk_composite_round_rate;
> > +                     if (rate_ops->set_rate) {
> > +                             clk_composite_ops->set_rate = clk_composite_set_rate;
> > +                     }
> > +             }
> > +
> 
> What if rate_ops has only recalc_rate and set_rate? clk_composite_ops 
> will have only recalc_rate and it will pass the sanity check in clk_init 
> and caller of clk_register_composite will expect set_rate to work.
> We should check here if rate_ops has set_rate but not round_rate then 
> return error.
> 

I think I will instead put a WARN here instead of completely bailing out
of the clock registration.

Thanks,
Mike

> >               composite->rate_hw = rate_hw;
> >               composite->rate_ops = rate_ops;
> >               clk_composite_ops->recalc_rate = clk_composite_recalc_rate;
> > -             clk_composite_ops->round_rate = clk_composite_round_rate;
> > -             clk_composite_ops->set_rate = clk_composite_set_rate;
> >       }
> >   
> >       if (gate_hw && gate_ops) {


From mturquette at linaro.org  Thu Apr 11 13:56:56 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Thu, 11 Apr 2013 10:56:56 -0700
Subject: [PATCH 1/3] clk: composite: rename 'div' references to 'rate'
In-Reply-To: <5166A147.1050505@nvidia.com>
References: <1365515284-32061-2-git-send-email-emilio@elopez.com.ar>
 <1365631378-16103-1-git-send-email-mturquette@linaro.org>
 <1365631378-16103-2-git-send-email-mturquette@linaro.org>
 <5166A147.1050505@nvidia.com>
Message-ID: <20130411175656.7915.24871@quantum>

Quoting Prashant Gaikwad (2013-04-11 04:40:55)
> On Thursday 11 April 2013 03:32 AM, Mike Turquette wrote:
> > Rename all div_hw and div_ops related variables and functions to use
> > rate_hw, rate_ops, etc.  This is to make the rate-change portion of the
> > composite clk implementation more generic.  A patch following this one
> > will allow for fixed-rate clocks to reuse this infrastructure.
> >
> > Signed-off-by: Mike Turquette <mturquette at linaro.org>
> > Cc: Prashant Gaikwad <pgaikwad at nvidia.com>
> > Cc: Emilio L?pez <emilio at elopez.com.ar>
> > Cc: Gregory CLEMENT <gregory.clement at free-electrons.com>
> > ---
> >   drivers/clk/clk-composite.c  |   40 ++++++++++++++++++++--------------------
> >   include/linux/clk-provider.h |   14 +++++++-------
> >   2 files changed, 27 insertions(+), 27 deletions(-)
> >
> <snip>
> 
> >   
> >       if (composite->gate_hw)
> >               composite->gate_hw->clk = clk;
> > diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
> > index 9fdfae7..f5ba8c5 100644
> > --- a/include/linux/clk-provider.h
> > +++ b/include/linux/clk-provider.h
> > @@ -352,11 +352,11 @@ struct clk *clk_register_fixed_factor(struct device *dev, const char *name,
> >    * struct clk_composite - aggregate clock of mux, divider and gate clocks
> >    *
> >    * @hw:             handle between common and hardware-specific interfaces
> > - * @mux_hw:  handle between composite and hardware-specifix mux clock
> > - * @div_hw:  handle between composite and hardware-specifix divider clock
> > - * @gate_hw: handle between composite and hardware-specifix gate clock
> > + * @mux_hw:  handle between composite and hardware-specific mux clock
> > + * @rate_hw: handle between composite and hardware-specific rateider clock
> 
> Small nitpick s/rateider/rate
> 
> Reviewed-by: Prashant Gaikwad <pgaikwad at nvidia.com>
> 

Good catch!

Thanks,
Mike

> > + * @gate_hw: handle between composite and hardware-specific gate clock
> >    * @mux_ops:        clock ops for mux
> > - * @div_ops: clock ops for divider
> > + * @rate_ops:        clock ops for rateider
> >    * @gate_ops:       clock ops for gate
> >    */
> >   struct clk_composite {
> > @@ -364,18 +364,18 @@ struct clk_composite {
> >       struct clk_ops  ops;
> >   
> >       struct clk_hw   *mux_hw;
> > -     struct clk_hw   *div_hw;
> > +     struct clk_hw   *rate_hw;
> >       struct clk_hw   *gate_hw;
> >   
> >       const struct clk_ops    *mux_ops;
> > -     const struct clk_ops    *div_ops;
> > +     const struct clk_ops    *rate_ops;
> >       const struct clk_ops    *gate_ops;
> >   };
> >   
> >   struct clk *clk_register_composite(struct device *dev, const char *name,
> >               const char **parent_names, int num_parents,
> >               struct clk_hw *mux_hw, const struct clk_ops *mux_ops,
> > -             struct clk_hw *div_hw, const struct clk_ops *div_ops,
> > +             struct clk_hw *rate_hw, const struct clk_ops *rate_ops,
> >               struct clk_hw *gate_hw, const struct clk_ops *gate_ops,
> >               unsigned long flags);
> >


From eric.dumazet at gmail.com  Thu Apr 11 13:59:15 2013
From: eric.dumazet at gmail.com (Eric Dumazet)
Date: Thu, 11 Apr 2013 10:59:15 -0700
Subject: [PATCH] net: mv643xx_eth: Add GRO support
In-Reply-To: <20130411175147.GN1910@1wt.eu>
References: <CABJ1b_TQDabT1J7ffo5cb1Th=71bcSduifMJaDpfVRiiHvtWDw@mail.gmail.com>
 <20130411150326.GA19978@1wt.eu>
 <CABJ1b_TRxm97DKJLP_h0VwMJvcYmSpjoJvtg1KvBNGah=VzqMQ@mail.gmail.com>
 <20130411.133119.913809939413807690.davem@davemloft.net>
 <20130411175147.GN1910@1wt.eu>
Message-ID: <1365703155.3887.184.camel@edumazet-glaptop>

On Thu, 2013-04-11 at 19:51 +0200, Willy Tarreau wrote:

> Eric provided me with one such experimental patch in the past for this
> driver. It worked for me but we never tried to clean it up to propose
> it for inclusion.
> 
> If anyone is interested, I might still have it in experimental shape.

We are interested a lot ;)

Thanks !




From dave.martin at linaro.org  Thu Apr 11 14:01:25 2013
From: dave.martin at linaro.org (Dave Martin)
Date: Thu, 11 Apr 2013 19:01:25 +0100
Subject: [RFC PATCH 01/11] Documentation: DT: arm: define CPU topology
 bindings
In-Reply-To: <20130411155054.GA29509@e102568-lin.cambridge.arm.com>
References: <1365671562-2403-1-git-send-email-mark.rutland@arm.com>
 <1365671562-2403-2-git-send-email-mark.rutland@arm.com>
 <5166D01F.5070404@gmail.com>
 <20130411155054.GA29509@e102568-lin.cambridge.arm.com>
Message-ID: <20130411180125.GB2239@linaro.org>

On Thu, Apr 11, 2013 at 04:50:54PM +0100, Lorenzo Pieralisi wrote:
> On Thu, Apr 11, 2013 at 04:00:47PM +0100, Rob Herring wrote:
> > On 04/11/2013 04:12 AM, Mark Rutland wrote:
> > > From: Lorenzo Pieralisi <Lorenzo.Pieralisi at arm.com>
> > > 
> > > The advent of multi-cluster ARM systems requires a mechanism to describe
> > > how in hierarchical terms CPUs are connected in ARM SoCs so that the kernel
> > > can initialize and map resources like IRQs and memory space to specific
> > > group(s) of CPUs.
> > > 
> > > The CPU topology is made up of multiple hierarchy levels whose bottom
> > > layers (aka leaf nodes in device tree syntax) contain links to the HW
> > > CPUs in the system.
> > > 
> > > The topology bindings are generic for both 32-bit and 64-bit systems and
> > > lay the groundwork on top of which affinity schemes can be built.
> > > 
> > > This patch provides the documentation in the kernel required to define the
> > > device tree bindings describing the CPU topology for ARM 32-bit and 64-bit
> > > systems.
> > 
> > I'm now very weary of continued /cpu changes after the pain of making
> > the reg property reflect the mpidr value in 3.8.
> 
> We won't change the reg property value, the code I am about to post
> provides stricter bindings, stricter semantics and extends bindings to
> cater for arm 64-bit systems.
> 
> > > Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
> > > Signed-off-by: Mark Rutland <mark.rutland at arm.com>
> > > ---
> > >  Documentation/devicetree/bindings/arm/topology.txt | 524 +++++++++++++++++++++
> > >  1 file changed, 524 insertions(+)
> > >  create mode 100644 Documentation/devicetree/bindings/arm/topology.txt
> > > 
> > > diff --git a/Documentation/devicetree/bindings/arm/topology.txt b/Documentation/devicetree/bindings/arm/topology.txt
> > > new file mode 100644
> > > index 0000000..07c4961
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/arm/topology.txt
> > > @@ -0,0 +1,524 @@
> > > +===========================================
> > > +ARM topology binding description
> > > +===========================================
> > > +
> > > +===========================================
> > > +1 - Introduction
> > > +===========================================
> > > +
> > > +In an ARM system, the hierarchy of CPUs is defined through three entities that
> > > +are used to describe the layout of physical CPUs in the system:
> > > +
> > > +- cluster
> > > +- core
> > > +- thread
> > > +
> > > +The cpu nodes (bindings defined in [1]) represent the devices that
> > > +correspond to physical CPUs and are to be mapped to the hierarchy levels.
> > > +
> > > +The bottom hierarchy level sits at core or thread level depending on whether
> > > +symmetric multi-threading (SMT) is supported or not.
> > > +
> > > +For instance in a system where CPUs support SMT, "cpu" nodes represent all
> > > +threads existing in the system and map to the hierarchy level "thread" above.
> > > +In systems where SMT is not supported "cpu" nodes represent all cores present
> > > +in the system and map to the hierarchy level "core" above.
> > > +
> > > +ARM topology bindings allow one to associate cpu nodes with hierarchical groups
> > > +corresponding to the system hierarchy; syntactically they are defined as device
> > > +tree nodes.
> > > +
> > > +The remainder of this document provides the topology bindings for ARM, based
> > > +on the ePAPR standard, available from:
> > > +
> > > +http://devicetree.org
> > > +
> > > +If not stated otherwise, whenever a reference to a cpu node phandle is made its
> > > +value must point to a cpu node compliant with the cpu node bindings as
> > > +documented in [1].
> > > +A topology description containing phandles to cpu nodes that are not compliant
> > > +with bindings standardized in [1] is therefore considered invalid.
> > > +
> > > +===========================================
> > > +2 - cpu-map node
> > > +===========================================
> > > +
> > > +The ARM CPU topology is defined within a container node, sitting at the top
> > > +level of the device tree (/), the cpu-map node.
> > > +
> > > +- cpu-map node
> > > +
> > > +	Usage: Required to define ARM CPU topology
> > > +
> > > +	Description: The cpu-map node is just a container node where its
> > > +		     subnodes describe the CPU topology
> > > +
> > > +	Node name must be "cpu-map".
> > > +
> > > +	A cpu-map node's child nodes can be:
> > > +
> > > +	- one or more cluster nodes
> > > +
> > > +	Any other configuration is considered invalid.
> > > +
> > > +The cpu-map node can only contain three types of child nodes:
> > > +
> > > +- cluster node
> > > +- core node
> > > +- thread node
> > > +
> > 
> > Why not put the topology in the /cpus nodes? I don't really see the
> > point of having a flat list of cpus and separate topology info. There is
> > some compatibility issue, but adding optional levels for clusters can be
> > handled.
> 
> I thought this would break all code relying on /cpu nodes being /cpus node's
> children. Furthermore, I was told that the /cpus node can only have /cpu nodes
> as children.
> 
> If you wish so, we can define the topology in the /cpus node, fine by me.

Can we make such extensive changes to the cpus node without violating
the ePAPR specification?

If we can, great, but I'm a but unclear on how this would be achieved.

> > > +whose bindings are described in paragraph 3.
> > > +
> > > +The nodes describing the CPU topology (cluster/core/thread) can only be
> > > +defined within the cpu-map node.
> > > +Any other configuration is consider invalid and therefore must be ignored.
> > > +
> > > +===========================================
> > > +2.1 - cpu-map child nodes naming convention
> > > +===========================================
> > > +
> > > +cpu-map child nodes must follow a naming convention where the node name
> > > +must be "clusterN", "coreN", "threadN" depending on the node type (ie
> > > +cluster/core/thread) (where N = {0, 1, ...} is the node number; nodes which
> > > +are siblings within a single common parent node must be given a unique and
> > > +sequential N value, starting from 0).
> > > +cpu-map child nodes which do not share a common parent node can have the same
> > > +name (ie same number N as other cpu-map child nodes at different device tree
> > > +levels) since name uniqueness will be guaranteed by the device tree hierarchy.
> > > +
> > > +===========================================
> > > +3 - cluster/core/thread node bindings
> > > +===========================================
> > > +
> > > +Bindings for cluster/cpu/thread nodes are defined as follows:
> > > +
> > > +- cluster node
> > > +
> > > +	 Description: must be declared within a cpu-map node, one node
> > > +		      per cluster. A system can contain several layers of
> > > +		      clustering and cluster nodes can be contained in parent
> > > +		      cluster nodes.
> > > +
> > > +	The cluster node name must be "clusterN" as described in 2.1 above.
> > > +	A cluster node can not be a leaf node.
> > 
> > Follow standard conventions with "cluster at N" and a reg property with the
> > number.
> 
> We are defining the topology to decouple the cluster/core/thread concept
> from the MPIDR. Having a reg property in the cluster (and core) nodes
> would complicate things if that reg property must correspond to an MPIDR
> bitfield. If it is meant to be just an enumeration at a given device tree
> level, I am ok with changing that.

As a pure enumeration, I think that works fine.  It's more verbose
but also more conformant to DT conventions.  I'm not sure there's
another difference.

The proposed support for C preprocessing of dts files might provide a
way to help debloat this to some extent in dts source, while still
following the DT convention of using unit addresses and reg properties.
This will significantly increase the size of the FDT blob if the 
number of CPUs is large.  I don't remember offhand if we have a limit
on the size of FDT we can cope with.  Finding ways to relax the limit
is a better solution than dodging round standards, though.  We can
cross that bridge when/if we come to it.

> 
> > > +
> > > +	A cluster node's child nodes must be:
> > > +
> > > +	- one or more cluster nodes; or
> > > +	- one or more core nodes
> > > +
> > > +	Any other configuration is considered invalid.
> > > +
> > > +- core node
> > > +
> > > +	Description: must be declared in a cluster node, one node per core in
> > > +		     the cluster. If the system does not support SMT, core
> > > +		     nodes are leaf nodes, otherwise they become containers of
> > > +		     thread nodes.
> > > +
> > > +	The core node name must be "coreN" as described in 2.1 above.
> > > +
> > > +	A core node must be a leaf node if SMT is not supported.
> > > +
> > > +	Properties for core nodes that are leaf nodes:
> > > +
> > > +	- cpu
> > > +		Usage: required
> > > +		Value type: <phandle>
> > > +		Definition: a phandle to the cpu node that corresponds to the
> > > +			    core node.
> > > +
> > > +	If a core node is not a leaf node (CPUs supporting SMT) a core node's
> > > +	child nodes can be:
> > > +
> > > +	- one or more thread nodes
> > > +
> > > +	Any other configuration is considered invalid.
> > > +
> > > +- thread node
> > > +
> > > +	Description: must be declared in a core node, one node per thread
> > > +		     in the core if the system supports SMT. Thread nodes are
> > > +		     always leaf nodes in the device tree.
> > > +
> > > +	The thread node name must be "threadN" as described in 2.1 above.
> > > +
> > > +	A thread node must be a leaf node.
> > > +
> > > +	A thread node must contain the following property:
> > > +
> > > +	- cpu
> > > +		Usage: required
> > > +		Value type: <phandle>
> > > +		Definition: a phandle to the cpu node that corresponds to
> > > +			    the thread node.
> > 
> > 
> > According to the ePAPR, threads are represented by an array of ids for
> > reg property, not another cpu node. Why the deviation.
> 
> It is not a cpu node, it is a phandle property named cpu. Can you point
> me to the ePAPR section where threads bindings are described please ? I have
> not managed to find these details, I am reading version 1.0.

For cpu/reg:

[1]     If a CPU supports more than one thread (i.e. multiple streams of
        execution) the reg property is an array with 1 element per
        thread. The #address-cells on the /cpus node specifies how many
        cells each element of the array takes. Software can determine
        the number of threads by dividing the size of reg by the parent
        node's #address-cells.

I had not previously been aware of this, but I see no reason not to
follow this convention.


Also:
[2]     If other more complex CPU topographies are designed, the binding
        for the CPU must describe the topography


That's rather less helpful, but the suggestion is clear enough in that
such information should be in the cpu node and specific to that CPU's
binding.  For ARM, we can have some global extensions to the CPU node.

The problems start when you want to refer to clusters and groups of
CPUs from other nodes.  Only individual cpu nodes can be places in
the cpus node, so there is no node for a phandle to point at.

If you want to describe how other things like power, clock and
coherency domains map to clusters and larger entities, things could
get pretty awkward.

Keeping the topology description separate allows all topological entities
to appear as addressable entities in the DT; otherwise, a cryptic
convention is needed.


Hybrid approaches might be possible, putting cpu nodes into /cpus, and
giving them a "parent" property where appropriate pointing at the
relevant cluster node, which we put elsewhere in the DT.

I'm not sure whether any of these approaches is an awful lot less ugly
or more easy to handle than what it currently proposed though.

The global binding for all ARM CPUs would specify that the topology
is described by /cpu-map and its associated binding.  For my
interpretation of [2], this is a compliant approach.  ePAPR does not
specify _how_ the cpu node binding achieves a description of the
topography, just that it must achieve it.  There's no statement to
say that it must not involve other nodes or bindings.

Cheers
---Dave


From w at 1wt.eu  Thu Apr 11 14:02:59 2013
From: w at 1wt.eu (Willy Tarreau)
Date: Thu, 11 Apr 2013 20:02:59 +0200
Subject: [PATCH] net: mv643xx_eth: Add GRO support
In-Reply-To: <1365703155.3887.184.camel@edumazet-glaptop>
References: <CABJ1b_TQDabT1J7ffo5cb1Th=71bcSduifMJaDpfVRiiHvtWDw@mail.gmail.com>
 <20130411150326.GA19978@1wt.eu>
 <CABJ1b_TRxm97DKJLP_h0VwMJvcYmSpjoJvtg1KvBNGah=VzqMQ@mail.gmail.com>
 <20130411.133119.913809939413807690.davem@davemloft.net>
 <20130411175147.GN1910@1wt.eu> <1365703155.3887.184.camel@edumazet-glaptop>
Message-ID: <20130411180259.GO1910@1wt.eu>

On Thu, Apr 11, 2013 at 10:59:15AM -0700, Eric Dumazet wrote:
> On Thu, 2013-04-11 at 19:51 +0200, Willy Tarreau wrote:
> 
> > Eric provided me with one such experimental patch in the past for this
> > driver. It worked for me but we never tried to clean it up to propose
> > it for inclusion.
> > 
> > If anyone is interested, I might still have it in experimental shape.
> 
> We are interested a lot ;)

Just found it in one of my local branches :-)

Here it is. It was experimental. At first glance, I'm seeing it does not
remove NETIF_F_LRO as we used it for experimentation only, but that's
a trivial thing to fix.

Original work by you Eric, tested by me on 3.6.


diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c b/drivers/net/ethernet/marvell/mv643xx_eth.c
index ea2cedc..81a6cb0 100644
--- a/drivers/net/ethernet/marvell/mv643xx_eth.c
+++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
@@ -55,9 +55,9 @@
 #include <linux/mv643xx_eth.h>
 #include <linux/io.h>
 #include <linux/types.h>
-#include <linux/inet_lro.h>
 #include <linux/slab.h>
 #include <linux/clk.h>
+#include <linux/interrupt.h>
 
 static char mv643xx_eth_driver_name[] = "mv643xx_eth";
 static char mv643xx_eth_driver_version[] = "1.4";
@@ -343,12 +343,6 @@ struct mib_counters {
 	u32 rx_overrun;
 };
 
-struct lro_counters {
-	u32 lro_aggregated;
-	u32 lro_flushed;
-	u32 lro_no_desc;
-};
-
 struct rx_queue {
 	int index;
 
@@ -363,8 +357,6 @@ struct rx_queue {
 	int rx_desc_area_size;
 	void		**rx_data;
 	unsigned int frag_size;
-	struct net_lro_mgr lro_mgr;
-	struct net_lro_desc lro_arr[8];
 };
 
 struct tx_queue {
@@ -400,8 +392,6 @@ struct mv643xx_eth_private {
 	spinlock_t mib_counters_lock;
 	struct mib_counters mib_counters;
 
-	struct lro_counters lro_counters;
-
 	struct work_struct tx_timeout_task;
 
 	struct napi_struct napi;
@@ -533,33 +523,6 @@ static void txq_maybe_wake(struct tx_queue *txq)
 }
 
 
-/* rx napi ******************************************************************/
-static int
-mv643xx_get_skb_header(struct sk_buff *skb, void **iphdr, void **tcph,
-		       u64 *hdr_flags, void *priv)
-{
-	unsigned long cmd_sts = (unsigned long)priv;
-
-	/*
-	 * Make sure that this packet is Ethernet II, is not VLAN
-	 * tagged, is IPv4, has a valid IP header, and is TCP.
-	 */
-	if ((cmd_sts & (RX_IP_HDR_OK | RX_PKT_IS_IPV4 |
-		       RX_PKT_IS_ETHERNETV2 | RX_PKT_LAYER4_TYPE_MASK |
-		       RX_PKT_IS_VLAN_TAGGED)) !=
-	    (RX_IP_HDR_OK | RX_PKT_IS_IPV4 |
-	     RX_PKT_IS_ETHERNETV2 | RX_PKT_LAYER4_TYPE_TCP_IPV4))
-		return -1;
-
-	skb_reset_network_header(skb);
-	skb_set_transport_header(skb, ip_hdrlen(skb));
-	*iphdr = ip_hdr(skb);
-	*tcph = tcp_hdr(skb);
-	*hdr_flags = LRO_IPV4 | LRO_TCP;
-
-	return 0;
-}
-
 static void mv_frag_free(const struct rx_queue *rxq, void *data)
 {
 	if (rxq->frag_size)
@@ -568,14 +531,12 @@ static void mv_frag_free(const struct rx_queue *rxq, void *data)
 		kfree(data);
 }
 
-static int rxq_process(struct rx_queue *rxq, int budget)
+static int rxq_process(struct napi_struct *napi, struct rx_queue *rxq, int budget)
 {
 	struct mv643xx_eth_private *mp = rxq_to_mp(rxq);
 	struct net_device_stats *stats = &mp->dev->stats;
-	int lro_flush_needed;
 	int rx;
 
-	lro_flush_needed = 0;
 	rx = 0;
 	while (rx < budget && rxq->rx_desc_count) {
 		struct rx_desc *rx_desc;
@@ -646,12 +607,7 @@ static int rxq_process(struct rx_queue *rxq, int budget)
 			skb->ip_summed = CHECKSUM_UNNECESSARY;
 		skb->protocol = eth_type_trans(skb, mp->dev);
 
-		if (skb->dev->features & NETIF_F_LRO &&
-		    skb->ip_summed == CHECKSUM_UNNECESSARY) {
-			lro_receive_skb(&rxq->lro_mgr, skb, (void *)cmd_sts);
-			lro_flush_needed = 1;
-		} else
-			netif_receive_skb(skb);
+		napi_gro_receive(napi, skb);
 
 		continue;
 
@@ -671,9 +627,6 @@ err:
 		dev_kfree_skb(skb);
 	}
 
-	if (lro_flush_needed)
-		lro_flush_all(&rxq->lro_mgr);
-
 	if (rx < budget)
 		mp->work_rx &= ~(1 << rxq->index);
 
@@ -723,7 +676,6 @@ static int rxq_refill(struct rx_queue *rxq, int budget)
 		rxq->rx_data[rx] = data;
 		wmb();
 		rx_desc->cmd_sts = BUFFER_OWNED_BY_DMA | RX_ENABLE_INTERRUPT;
-
 	}
 
 	if (refilled < budget)
@@ -1214,26 +1166,6 @@ static struct net_device_stats *mv643xx_eth_get_stats(struct net_device *dev)
 	return stats;
 }
 
-static void mv643xx_eth_grab_lro_stats(struct mv643xx_eth_private *mp)
-{
-	u32 lro_aggregated = 0;
-	u32 lro_flushed = 0;
-	u32 lro_no_desc = 0;
-	int i;
-
-	for (i = 0; i < mp->rxq_count; i++) {
-		struct rx_queue *rxq = mp->rxq + i;
-
-		lro_aggregated += rxq->lro_mgr.stats.aggregated;
-		lro_flushed += rxq->lro_mgr.stats.flushed;
-		lro_no_desc += rxq->lro_mgr.stats.no_desc;
-	}
-
-	mp->lro_counters.lro_aggregated = lro_aggregated;
-	mp->lro_counters.lro_flushed = lro_flushed;
-	mp->lro_counters.lro_no_desc = lro_no_desc;
-}
-
 static inline u32 mib_read(struct mv643xx_eth_private *mp, int offset)
 {
 	return rdl(mp, MIB_COUNTERS(mp->port_num) + offset);
@@ -1397,10 +1329,6 @@ struct mv643xx_eth_stats {
 	{ #m, FIELD_SIZEOF(struct mib_counters, m),		\
 	  -1, offsetof(struct mv643xx_eth_private, mib_counters.m) }
 
-#define LROSTAT(m)						\
-	{ #m, FIELD_SIZEOF(struct lro_counters, m),		\
-	  -1, offsetof(struct mv643xx_eth_private, lro_counters.m) }
-
 static const struct mv643xx_eth_stats mv643xx_eth_stats[] = {
 	SSTAT(rx_packets),
 	SSTAT(tx_packets),
@@ -1442,9 +1370,6 @@ static const struct mv643xx_eth_stats mv643xx_eth_stats[] = {
 	MIBSTAT(late_collision),
 	MIBSTAT(rx_discard),
 	MIBSTAT(rx_overrun),
-	LROSTAT(lro_aggregated),
-	LROSTAT(lro_flushed),
-	LROSTAT(lro_no_desc),
 };
 
 static int
@@ -1642,7 +1567,6 @@ static void mv643xx_eth_get_ethtool_stats(struct net_device *dev,
 
 	mv643xx_eth_get_stats(dev);
 	mib_counters_update(mp);
-	mv643xx_eth_grab_lro_stats(mp);
 
 	for (i = 0; i < ARRAY_SIZE(mv643xx_eth_stats); i++) {
 		const struct mv643xx_eth_stats *stat;
@@ -1915,19 +1839,6 @@ static int rxq_init(struct mv643xx_eth_private *mp, int index)
 					nexti * sizeof(struct rx_desc);
 	}
 
-	rxq->lro_mgr.dev = mp->dev;
-	memset(&rxq->lro_mgr.stats, 0, sizeof(rxq->lro_mgr.stats));
-	rxq->lro_mgr.features = LRO_F_NAPI;
-	rxq->lro_mgr.ip_summed = CHECKSUM_UNNECESSARY;
-	rxq->lro_mgr.ip_summed_aggr = CHECKSUM_UNNECESSARY;
-	rxq->lro_mgr.max_desc = ARRAY_SIZE(rxq->lro_arr);
-	rxq->lro_mgr.max_aggr = 32;
-	rxq->lro_mgr.frag_align_pad = 0;
-	rxq->lro_mgr.lro_arr = rxq->lro_arr;
-	rxq->lro_mgr.get_skb_header = mv643xx_get_skb_header;
-
-	memset(&rxq->lro_arr, 0, sizeof(rxq->lro_arr));
-
 	return 0;
 
 
@@ -2192,7 +2103,7 @@ static int mv643xx_eth_poll(struct napi_struct *napi, int budget)
 			work_done += txq_reclaim(mp->txq + queue, work_tbd, 0);
 			txq_maybe_wake(mp->txq + queue);
 		} else if (mp->work_rx & queue_mask) {
-			work_done += rxq_process(mp->rxq + queue, work_tbd);
+			work_done += rxq_process(napi, mp->rxq + queue, work_tbd);
 		} else if (!mp->oom && (mp->work_rx_refill & queue_mask)) {
 			work_done += rxq_refill(mp->rxq + queue, work_tbd);
 		} else {

Regards,
Willy



From tony at atomide.com  Thu Apr 11 14:03:41 2013
From: tony at atomide.com (Tony Lindgren)
Date: Thu, 11 Apr 2013 11:03:41 -0700
Subject: [PATCH 25/26] arm: Don't use create_proc_read_entry() [RFC]
In-Reply-To: <20130411165702.GZ10155@atomide.com>
References: <20130411154806.GU10155@atomide.com>
 <20130411132739.32763.82609.stgit@warthog.procyon.org.uk>
 <20130411133058.32763.5466.stgit@warthog.procyon.org.uk>
 <13448.1365698725@warthog.procyon.org.uk>
 <20130411165702.GZ10155@atomide.com>
Message-ID: <20130411180341.GA10155@atomide.com>

* Tony Lindgren <tony at atomide.com> [130411 10:01]:
> * David Howells <dhowells at redhat.com> [130411 09:50]:
> > Tony Lindgren <tony at atomide.com> wrote:
> > 
> > > Looks like the mach-omap1/pm.c part we can make into
> > > a debugfs entry as it only contains PM debug data. But
> > > that we can do after this patch.
> > 
> > If you have a patch to do that, I can substitute it for this one.
> 
> Sure will do.

Here's the updated patch to do it against current linux next.
Tested on osk5912. It should not conflict with anything else
currently queued, so please feel free to merge it along with
your other patches.

Note that the patch below does not contain the swp_emulate.c
changes.

Regards,

Tony


From: Tony Lindgren <tony at atomide.com>
Date: Thu, 11 Apr 2013 10:02:38 -0700
Subject: [PATCH] ARM: OMAP1: Replace PM debug create_proc_read_entry() with debugfs

There's no need to keep this entry in proc, it is PM
related debug only entry. Let's move it into debugfs.

Based on an earlier patch David Howells <dhowells at redhat.com>
to use seq_printf and to update to use create_proc_read_entry().

Signed-off-by: Tony Lindgren <tony at atomide.com>

diff --git a/arch/arm/mach-omap1/pm.c b/arch/arm/mach-omap1/pm.c
index db37f49..dd712f1 100644
--- a/arch/arm/mach-omap1/pm.c
+++ b/arch/arm/mach-omap1/pm.c
@@ -37,7 +37,8 @@
 
 #include <linux/suspend.h>
 #include <linux/sched.h>
-#include <linux/proc_fs.h>
+#include <linux/debugfs.h>
+#include <linux/seq_file.h>
 #include <linux/interrupt.h>
 #include <linux/sysfs.h>
 #include <linux/module.h>
@@ -423,23 +424,12 @@ void omap1_pm_suspend(void)
 		omap_rev());
 }
 
-#if defined(DEBUG) && defined(CONFIG_PROC_FS)
-static int g_read_completed;
-
+#ifdef CONFIG_DEBUG_FS
 /*
  * Read system PM registers for debugging
  */
-static int omap_pm_read_proc(
-	char *page_buffer,
-	char **my_first_byte,
-	off_t virtual_start,
-	int length,
-	int *eof,
-	void *data)
+static int omap_pm_debug_show(struct seq_file *m, void *v)
 {
-	int my_buffer_offset = 0;
-	char * const my_base = page_buffer;
-
 	ARM_SAVE(ARM_CKCTL);
 	ARM_SAVE(ARM_IDLECT1);
 	ARM_SAVE(ARM_IDLECT2);
@@ -480,10 +470,7 @@ static int omap_pm_read_proc(
 		MPUI1610_SAVE(EMIFS_CONFIG);
 	}
 
-	if (virtual_start == 0) {
-		g_read_completed = 0;
-
-		my_buffer_offset += sprintf(my_base + my_buffer_offset,
+	seq_printf(m,
 		   "ARM_CKCTL_REG:            0x%-8x     \n"
 		   "ARM_IDLECT1_REG:          0x%-8x     \n"
 		   "ARM_IDLECT2_REG:          0x%-8x     \n"
@@ -513,8 +500,8 @@ static int omap_pm_read_proc(
 		   ULPD_SHOW(ULPD_STATUS_REQ),
 		   ULPD_SHOW(ULPD_POWER_CTRL));
 
-		if (cpu_is_omap7xx()) {
-			my_buffer_offset += sprintf(my_base + my_buffer_offset,
+	if (cpu_is_omap7xx()) {
+		seq_printf(m,
 			   "MPUI7XX_CTRL_REG	     0x%-8x \n"
 			   "MPUI7XX_DSP_STATUS_REG:      0x%-8x \n"
 			   "MPUI7XX_DSP_BOOT_CONFIG_REG: 0x%-8x \n"
@@ -527,8 +514,8 @@ static int omap_pm_read_proc(
 			   MPUI7XX_SHOW(MPUI_DSP_API_CONFIG),
 			   MPUI7XX_SHOW(EMIFF_SDRAM_CONFIG),
 			   MPUI7XX_SHOW(EMIFS_CONFIG));
-		} else if (cpu_is_omap15xx()) {
-			my_buffer_offset += sprintf(my_base + my_buffer_offset,
+	} else if (cpu_is_omap15xx()) {
+		seq_printf(m,
 			   "MPUI1510_CTRL_REG             0x%-8x \n"
 			   "MPUI1510_DSP_STATUS_REG:      0x%-8x \n"
 			   "MPUI1510_DSP_BOOT_CONFIG_REG: 0x%-8x \n"
@@ -541,8 +528,8 @@ static int omap_pm_read_proc(
 			   MPUI1510_SHOW(MPUI_DSP_API_CONFIG),
 			   MPUI1510_SHOW(EMIFF_SDRAM_CONFIG),
 			   MPUI1510_SHOW(EMIFS_CONFIG));
-		} else if (cpu_is_omap16xx()) {
-			my_buffer_offset += sprintf(my_base + my_buffer_offset,
+	} else if (cpu_is_omap16xx()) {
+		seq_printf(m,
 			   "MPUI1610_CTRL_REG             0x%-8x \n"
 			   "MPUI1610_DSP_STATUS_REG:      0x%-8x \n"
 			   "MPUI1610_DSP_BOOT_CONFIG_REG: 0x%-8x \n"
@@ -555,28 +542,37 @@ static int omap_pm_read_proc(
 			   MPUI1610_SHOW(MPUI_DSP_API_CONFIG),
 			   MPUI1610_SHOW(EMIFF_SDRAM_CONFIG),
 			   MPUI1610_SHOW(EMIFS_CONFIG));
-		}
-
-		g_read_completed++;
-	} else if (g_read_completed >= 1) {
-		 *eof = 1;
-		 return 0;
 	}
-	g_read_completed++;
 
-	*my_first_byte = page_buffer;
-	return  my_buffer_offset;
+	return 0;
+}
+
+static int omap_pm_debug_open(struct inode *inode, struct file *file)
+{
+	return single_open(file, omap_pm_debug_show,
+				&inode->i_private);
 }
 
-static void omap_pm_init_proc(void)
+static const struct file_operations omap_pm_debug_fops = {
+	.open		= omap_pm_debug_open,
+	.read		= seq_read,
+	.llseek		= seq_lseek,
+	.release	= seq_release,
+};
+
+static void omap_pm_init_debugfs(void)
 {
-	/* XXX Appears to leak memory */
-	create_proc_read_entry("driver/omap_pm",
-			       S_IWUSR | S_IRUGO, NULL,
-			       omap_pm_read_proc, NULL);
+	struct dentry *d;
+
+	d = debugfs_create_dir("pm_debug", NULL);
+	if (!d)
+		return;
+
+	(void) debugfs_create_file("omap_pm", S_IWUSR | S_IRUGO,
+					d, NULL, &omap_pm_debug_fops);
 }
 
-#endif /* DEBUG && CONFIG_PROC_FS */
+#endif /* CONFIG_DEBUG_FS */
 
 /*
  *	omap_pm_prepare - Do preliminary suspend work.
@@ -701,8 +697,8 @@ static int __init omap_pm_init(void)
 
 	suspend_set_ops(&omap_pm_ops);
 
-#if defined(DEBUG) && defined(CONFIG_PROC_FS)
-	omap_pm_init_proc();
+#ifdef CONFIG_DEBUG_FS
+	omap_pm_init_debugfs();
 #endif
 
 #ifdef CONFIG_OMAP_32K_TIMER


From sebastian.hesselbarth at gmail.com  Thu Apr 11 14:07:16 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Thu, 11 Apr 2013 20:07:16 +0200
Subject: [PATCH] net: mv643xx_eth: Add GRO support
In-Reply-To: <1365702955.7355.5.camel@bwh-desktop.uk.solarflarecom.com>
References: <1365684023-9967-1-git-send-email-sebastian.hesselbarth@gmail.com>
 <1365702955.7355.5.camel@bwh-desktop.uk.solarflarecom.com>
Message-ID: <5166FBD4.5020508@gmail.com>

On 04/11/2013 07:55 PM, Ben Hutchings wrote:
> On Thu, 2013-04-11 at 14:40 +0200, Sebastian Hesselbarth wrote:
>> This patch adds GRO support to mv643xx_eth by making it invoke
>> napi_gro_receive instead of netif_receive_skb.
>
> The inet_lro support should be removed at the same time; inet_lro is now
> deprecated and there should be no need to keep both of them.

Ben,

I agree on removing it asap, but I also like to see GRO support
in. Maybe, we postpone lro removal just a little bit. I have just
started to look at mv643xx_eth and remember Marvell Orion SoCs are
not the only platform using it. I haven't heard a single word from
ppc guys, yet.

Willy just posted an experimental patch to remove lro. I'll have
a look at it and test it out on Dove.

Sebastian


From jason at lakedaemon.net  Thu Apr 11 14:07:36 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Thu, 11 Apr 2013 14:07:36 -0400
Subject: [PATCH v3 2/9] ARM: mvebu: Limit the DMA zone when LPAE is
 selected
In-Reply-To: <1365461538-30702-3-git-send-email-gregory.clement@free-electrons.com>
References: <1365461538-30702-1-git-send-email-gregory.clement@free-electrons.com>
 <1365461538-30702-3-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <20130411180736.GM28693@titan.lakedaemon.net>

On Tue, Apr 09, 2013 at 12:52:10AM +0200, Gregory CLEMENT wrote:
> When LPAE is activated on Armada XP, all registers and IOs are still
> 32bit, the 40bit extension is on the CPU to DRAM path (windows) only.
> That means that all the DMA transfer are restricted to the low 32 bits
> address space. This is limitation is achieved by selecting ZONE_DMA.
> 
> Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
> ---
>  arch/arm/mach-mvebu/Kconfig |    1 +
>  1 file changed, 1 insertion(+)

Applied to mvebu/soc

thx,

Jason.


From jason at lakedaemon.net  Thu Apr 11 14:08:10 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Thu, 11 Apr 2013 14:08:10 -0400
Subject: [PATCH v3 3/9] ARM: mvebu: Align the internal registers
 virtual base to support LPAE
In-Reply-To: <1365461538-30702-4-git-send-email-gregory.clement@free-electrons.com>
References: <1365461538-30702-1-git-send-email-gregory.clement@free-electrons.com>
 <1365461538-30702-4-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <20130411180810.GN28693@titan.lakedaemon.net>

On Tue, Apr 09, 2013 at 12:52:11AM +0200, Gregory CLEMENT wrote:
> From: Lior Amsalem <alior at marvell.com>
> 
> In order to be able to support the LPAE, the internal registers
> virtual base must be aligned to 2MB. In LPAE section size is 2MB, in
> earlyprintk we map the internal registers and it must be section
> aligned.
> 
> Signed-off-by: Lior Amsalem <alior at marvell.com>
> Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
> ---
>  arch/arm/include/debug/mvebu.S      |    2 +-
>  arch/arm/mach-mvebu/armada-370-xp.h |    2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)

Applied to mvebu/soc

thx,

Jason.


From jason at lakedaemon.net  Thu Apr 11 14:08:44 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Thu, 11 Apr 2013 14:08:44 -0400
Subject: [PATCH v3 4/9] ARM: mvebu: Enable pj4b on LPAE compilations
In-Reply-To: <1365461538-30702-5-git-send-email-gregory.clement@free-electrons.com>
References: <1365461538-30702-1-git-send-email-gregory.clement@free-electrons.com>
 <1365461538-30702-5-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <20130411180844.GO28693@titan.lakedaemon.net>

On Tue, Apr 09, 2013 at 12:52:12AM +0200, Gregory CLEMENT wrote:
> From: Lior Amsalem <alior at marvell.com>
> 
> pj4b cpus are LPAE capable so enable them on LPAE compilations
> 
> Signed-off-by: Lior Amsalem <alior at marvell.com>
> Tested-by: Franklin <flin at marvell.com>
> Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
> ---
>  arch/arm/mm/proc-v7.S |    3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)

Applied to mvebu/soc

thx,

Jason.


From tim.bird at am.sony.com  Thu Apr 11 14:18:51 2013
From: tim.bird at am.sony.com (Tim Bird)
Date: Thu, 11 Apr 2013 11:18:51 -0700
Subject: RFC: right way to conditional-ize some macros for LTO
In-Reply-To: <1364907037.3650.54.camel@linaro1.home>
References: <5155E28A.30509@am.sony.com>
 <1364907037.3650.54.camel@linaro1.home>
Message-ID: <5166FE8B.2070603@am.sony.com>

On 04/02/2013 05:50 AM, Jon Medhurst (Tixy) wrote:
> On Fri, 2013-03-29 at 11:50 -0700, Tim Bird wrote:
>> Hi all,
>>
>> A while ago I was working on supporting link-time optimization
>> for ARM, and I'm just now getting around to submitting some of
>> the patches from my work.  I'll explain more below, but the
>> executive summary is this: Andi Kleen's LTO patches for Linux
>> almost work on ARM.  I ran into one issue in
>> arch/arm/include/asm/unified.h where various 'it'-related
>> macros are expanding multiple times, in C context, and causing
>> build errors.
>>
>> As near as I can tell, these macros are not used except by
>> arch/arm/kernel/kprobes-test-thumb.c (and most are not used
>> at all).
>>
>> When compiling with CONFIG_LTO=y, in Andi's 3.7.0 tree with LTO
>> patches, I got the messages below:
>> -----------------------------------------------
>> ...
>>   LD      drivers/tty/built-in.o
>>   LD      drivers/built-in.o
>>   LINK    vmlinux
>>   GEN     .version
>>   CHK     include/generated/compile.h
>>   UPD     include/generated/compile.h
>>   CC      init/version.o
>>   LD      init/built-in.o
>>   LDFINAL vmlinux.o
>> [Leaving LTRANS /tmp/ccsIMbQT.args]
>> [Leaving LTRANS vmlinux.o.ltrans.out]
>> In file included from /a/home/tbird/work/auto-reduce/lto-work/linux-misc-andi-kleen/include/uapi/linux/swab.h:269:0,
>>                  from :872:
>> /a/home/tbird/work/auto-reduce/lto-work/linux-misc-andi-kleen/crypto/wp512.c: In function 'wp512_process_buffer':
>> /a/home/tbird/work/auto-reduce/lto-work/linux-misc-andi-kleen/crypto/wp512.c:987:1: warning: the frame size of 1160 bytes is larger than 1024 bytes [-Wframe-larger-than=]
>> vmlinux.o.ltrans0.s: Assembler messages:
>> vmlinux.o.ltrans0.s:408: Error: Macro `it' was already defined
>> vmlinux.o.ltrans0.s:410: Error: Macro `itt' was already defined
>> vmlinux.o.ltrans0.s:412: Error: Macro `ite' was already defined
>> vmlinux.o.ltrans0.s:414: Error: Macro `ittt' was already defined
>> vmlinux.o.ltrans0.s:416: Error: Macro `itte' was already defined
>> vmlinux.o.ltrans0.s:418: Error: Macro `itet' was already defined
>> vmlinux.o.ltrans0.s:420: Error: Macro `itee' was already defined
>> vmlinux.o.ltrans0.s:422: Error: Macro `itttt' was already defined
>> vmlinux.o.ltrans0.s:424: Error: Macro `ittte' was already defined
>> vmlinux.o.ltrans0.s:426: Error: Macro `ittet' was already defined
>> vmlinux.o.ltrans0.s:428: Error: Macro `ittee' was already defined
>> vmlinux.o.ltrans0.s:430: Error: Macro `itett' was already defined
>> vmlinux.o.ltrans0.s:432: Error: Macro `itete' was already defined
>> vmlinux.o.ltrans0.s:434: Error: Macro `iteet' was already defined
>> vmlinux.o.ltrans0.s:436: Error: Macro `iteee' was already defined
>> vmlinux.o.ltrans0.s:968: Error: Macro `it' was already defined
>> vmlinux.o.ltrans0.s:970: Error: Macro `itt' was already defined
>> vmlinux.o.ltrans0.s:972: Error: Macro `ite' was already defined
>> vmlinux.o.ltrans0.s:974: Error: Macro `ittt' was already defined
>> vmlinux.o.ltrans0.s:976: Error: Macro `itte' was already defined
>> ...
>> [Leaving LTRANS vmlinux.o.ltrans30.ltrans.o]
>> [Leaving LTRANS vmlinux.o.ltrans31.o]
>> [Leaving LTRANS vmlinux.o.ltrans31.ltrans.o]
>> /a/home/tbird/work/auto-reduce/sony-yocto/lto-build2/tmp/sysroots/x86_64-linux/usr/libexec/armv5te-sony-linux-gnueabi/gcc/arm-sony-linux-gnueabi/4.7.3/arm-sony-linux-gnueabi-ld: lto-wrapper failed
>> collect2: error: ld returned 1 exit status
>> make[1]: *** [vmlinux] Error 1
>> make: *** [sub-make] Error 2
>>
>> Error: Bad result 512, running "make -j 8 KALLSYMS_EXTRA_PASS=1 bzImage": (output follows)
>> Error:
>> ---------------------------------------------
>>
>> The messages are repeated thousands of times (I'm guessing for every object
>> file after the first that included arch/arm/include/asm/unified.h)
>>
>> Recognizing that LTO is currently incompatible with kprobes, and (so far)
>> finding that only kprobes appeared to use these macros, I did the following hack:
>>
>> diff --git a/arch/arm/include/asm/unified.h b/arch/arm/include/asm/unified.h
>> index f5989f4..5179c13 100644
>> --- a/arch/arm/include/asm/unified.h
>> +++ b/arch/arm/include/asm/unified.h
>> @@ -92,6 +92,7 @@
>>  	.macro	iteee, cond
>>  	.endm
>>  #else	/* !__ASSEMBLY__ */
>> +#ifndef CONFIG_LTO
>>  __asm__(
>>  "	.macro	it, cond\n"
>>  "	.endm\n"
>> @@ -123,6 +124,7 @@ __asm__(
>>  "	.endm\n"
>>  "	.macro	iteee, cond\n"
>>  "	.endm\n");
>> +#endif  /* ! CONFIG_LTO */
>>  #endif	/* __ASSEMBLY__ */
>>
>>  #endif	/* CONFIG_ARM_ASM_UNIFIED */
>>
>> This the macros thus removed, I had no problems building the kernel
>> and running it on target.
>>
>> While this works to remove the build error, it doesn't seem robust and I'd
>> like to either 1) find a better way to make these macro definitions conditional,
>> or 2) eliminate them completely.
>>
>> The macros themselves seem empty.  Can someone tell me what they do?
>> What is the status of these macros?  Are they even needed?
> 
> The names of the macros are for Thumb2 instructions which are redundant
> when building for the ARM instruction set. Newer toolchains which
> support the unified assembler syntax will effectively ignore them and I
> guess these empty macros are there so people can write assembler which
> will compile with older toolchains.
> 
>> Could they be
>> made conditional on something like NEED_IT_MACROS, and then have that set only
>> in the arch/arm/kernel/kprobes-test-thumb.c, before the unified.h is included?
> 
> That file needs the real Thumb2 instructions, not empty macros, and
> indeed it doesn't use them, because it is only compiled when
> CONFIG_THUMB2_KERNEL=y and that selects CONFIG_ARM_ASM_UNIFIED and those
> 'it' macro's are guarded by #ifndef CONFIG_ARM_ASM_UNIFIED.
> 
> Note, there are other files which use the 'it' instructions, e.g.
> arch/arm/include/asm/futex.h.
> 
>> I would like get this minor issue resolved in mainline, to make it easier for Andi
>> to get his LTO work upstream and have it work with ARM.
>>
>> Any suggestions are welcome.
> 
> If your toolchain supports the unified assembler syntax, you could try
> enabling CONFIG_ARM_ASM_UNIFIED in ARM builds.
> 

Well, I came up with the patch below, but it doesn't feel right.
There must be a better way to select an arch-specific config variable.
It seems goofy to add this to the general init/Kconfig LTO option.
Any better suggestions for how to do this?

When LTO is turned on for the ARM architecture, the macros in
arch/arm/include/asm/unified.h get included multiple times
in the global build, causing build errors.  Avoid this by
turning on CONFIG_ARM_ASM_UNIFIED.  Unfortunately, this causes
another set of errors from .S files about
'conditional infixes are deprecated'.  This commit also
avoids that warning, by turning off the warning in the
flags to the toolchain (when CONFIG_ARM_ASM_UNIFIED=y).
---
 arch/arm/Makefile |    5 ++++-
 init/Kconfig      |    1 +
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 5f914fc..ac3f9a8 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -110,7 +110,10 @@ ifeq ($(CONFIG_THUMB2_AVOID_R_ARM_THM_JUMP11),y)
 CFLAGS_MODULE	+=-fno-optimize-sibling-calls
 endif
 else
-CFLAGS_ISA	:=$(call cc-option,-marm,)
+ifeq ($(CONFIG_ARM_ASM_UNIFIED),y)
+AFLAGS_NOWARN	:=$(call as-option,-Wa$(comma)-mno-warn-deprecated,-Wa$(comma)-W)
+endif
+CFLAGS_ISA	:=$(call cc-option,-marm,) $(AFLAGS_NOWARN)
 AFLAGS_ISA	:=$(CFLAGS_ISA)
 endif

diff --git a/init/Kconfig b/init/Kconfig
index 33090d8..b586be9 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1164,6 +1164,7 @@ config LTO_DISABLE
 config LTO
 	bool
 	default y
+	select ARM_ASM_UNIFIED
 	depends on LTO_MENU && !LTO_DISABLE

 config LTO_DEBUG
-- 
1.7.9.5

=============================
Tim Bird
Architecture Group Chair, CE Workgroup of the Linux Foundation
Senior Staff Engineer, Sony Network Entertainment
=============================



From dave.martin at linaro.org  Thu Apr 11 14:17:10 2013
From: dave.martin at linaro.org (Dave Martin)
Date: Thu, 11 Apr 2013 19:17:10 +0100
Subject: [RFC PATCH 01/11] Documentation: DT: arm: define CPU topology
 bindings
In-Reply-To: <5166F908.9050503@gmail.com>
References: <1365671562-2403-1-git-send-email-mark.rutland@arm.com>
 <1365671562-2403-2-git-send-email-mark.rutland@arm.com>
 <5166D01F.5070404@gmail.com>
 <20130411155054.GA29509@e102568-lin.cambridge.arm.com>
 <5166F908.9050503@gmail.com>
Message-ID: <20130411181710.GC2239@linaro.org>

On Thu, Apr 11, 2013 at 12:55:20PM -0500, Rob Herring wrote:
> On 04/11/2013 10:50 AM, Lorenzo Pieralisi wrote:
> > On Thu, Apr 11, 2013 at 04:00:47PM +0100, Rob Herring wrote:
> >> On 04/11/2013 04:12 AM, Mark Rutland wrote:
> >>> From: Lorenzo Pieralisi <Lorenzo.Pieralisi at arm.com>

[...]

> >>> +===========================================
> >>> +3 - cluster/core/thread node bindings
> >>> +===========================================
> >>> +
> >>> +Bindings for cluster/cpu/thread nodes are defined as follows:
> >>> +
> >>> +- cluster node
> >>> +
> >>> +	 Description: must be declared within a cpu-map node, one node
> >>> +		      per cluster. A system can contain several layers of
> >>> +		      clustering and cluster nodes can be contained in parent
> >>> +		      cluster nodes.
> >>> +
> >>> +	The cluster node name must be "clusterN" as described in 2.1 above.
> >>> +	A cluster node can not be a leaf node.
> >>
> >> Follow standard conventions with "cluster at N" and a reg property with the
> >> number.
> > 
> > We are defining the topology to decouple the cluster/core/thread concept
> > from the MPIDR. Having a reg property in the cluster (and core) nodes
> > would complicate things if that reg property must correspond to an MPIDR
> > bitfield. If it is meant to be just an enumeration at a given device tree
> > level, I am ok with changing that.
> 
> Because the cluster itself doesn't really have an id, I'm fine if its
> not linked to the mpidr. Just don't change that later.

These enumerations can follow the MPIDR for convenience if the MPIDR
allocations are sane, but otherwise it would be abstract.  The Architecture
doesn't specify any kind of an ID for a cluster (indeed, it doesn't really
specify what a cluster is at all).


However, we could require a platform or SoC binding to specify the
enumeration and it how it maps to the actual hardware -- i.e., cluster at 1
on Tuesday should be the same physical cluster as cluster at 1 on Monday,
to the extent that cluster at 1 is present in the DT on both days and the
hardware hasn't been physically modified (i.e., cluster at 1 might refer
to a fixed physical socket on a hypothetical board with physically
pluggable CPU modules).

Correspondingly, on TC2, cluster at 0 would always be the A15 cluster;
cluster at 1 would always be the A7 cluster.  But if the firmware disables
one of them, that cluster and the relevant CPU nodes should be removed
from the DT before passing it to the kernel.

Does this make any sense, or is it overkill?


Cheers
---Dave


From mturquette at linaro.org  Thu Apr 11 14:31:36 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Thu, 11 Apr 2013 11:31:36 -0700
Subject: [PATCH v2 1/2] clk: composite: rename 'div' references to 'rate'
In-Reply-To: <1365631378-16103-1-git-send-email-mturquette@linaro.org>
References: <1365631378-16103-1-git-send-email-mturquette@linaro.org>
Message-ID: <1365705097-18899-1-git-send-email-mturquette@linaro.org>

Rename all div_hw and div_ops related variables and functions to use
rate_hw, rate_ops, etc.  This is to make the rate-change portion of the
composite clk implementation more generic.  A patch following this one
will allow for fixed-rate clocks to reuse this infrastructure.

Signed-off-by: Mike Turquette <mturquette at linaro.org>
Reviewed-by: Prashant Gaikwad <pgaikwad at nvidia.com>
Tested-by: Emilio L?pez <emilio at elopez.com.ar>
Cc: Gregory CLEMENT <gregory.clement at free-electrons.com>
---
Changes since v1:
* fixed regex typo in kerneldoc

 drivers/clk/clk-composite.c  |   40 ++++++++++++++++++++--------------------
 include/linux/clk-provider.h |   14 +++++++-------
 2 files changed, 27 insertions(+), 27 deletions(-)

diff --git a/drivers/clk/clk-composite.c b/drivers/clk/clk-composite.c
index 097dee4..6f4728c 100644
--- a/drivers/clk/clk-composite.c
+++ b/drivers/clk/clk-composite.c
@@ -47,36 +47,36 @@ static unsigned long clk_composite_recalc_rate(struct clk_hw *hw,
 					    unsigned long parent_rate)
 {
 	struct clk_composite *composite = to_clk_composite(hw);
-	const struct clk_ops *div_ops = composite->div_ops;
-	struct clk_hw *div_hw = composite->div_hw;
+	const struct clk_ops *rate_ops = composite->rate_ops;
+	struct clk_hw *rate_hw = composite->rate_hw;
 
-	div_hw->clk = hw->clk;
+	rate_hw->clk = hw->clk;
 
-	return div_ops->recalc_rate(div_hw, parent_rate);
+	return rate_ops->recalc_rate(rate_hw, parent_rate);
 }
 
 static long clk_composite_round_rate(struct clk_hw *hw, unsigned long rate,
 				  unsigned long *prate)
 {
 	struct clk_composite *composite = to_clk_composite(hw);
-	const struct clk_ops *div_ops = composite->div_ops;
-	struct clk_hw *div_hw = composite->div_hw;
+	const struct clk_ops *rate_ops = composite->rate_ops;
+	struct clk_hw *rate_hw = composite->rate_hw;
 
-	div_hw->clk = hw->clk;
+	rate_hw->clk = hw->clk;
 
-	return div_ops->round_rate(div_hw, rate, prate);
+	return rate_ops->round_rate(rate_hw, rate, prate);
 }
 
 static int clk_composite_set_rate(struct clk_hw *hw, unsigned long rate,
 			       unsigned long parent_rate)
 {
 	struct clk_composite *composite = to_clk_composite(hw);
-	const struct clk_ops *div_ops = composite->div_ops;
-	struct clk_hw *div_hw = composite->div_hw;
+	const struct clk_ops *rate_ops = composite->rate_ops;
+	struct clk_hw *rate_hw = composite->rate_hw;
 
-	div_hw->clk = hw->clk;
+	rate_hw->clk = hw->clk;
 
-	return div_ops->set_rate(div_hw, rate, parent_rate);
+	return rate_ops->set_rate(rate_hw, rate, parent_rate);
 }
 
 static int clk_composite_is_enabled(struct clk_hw *hw)
@@ -115,7 +115,7 @@ static void clk_composite_disable(struct clk_hw *hw)
 struct clk *clk_register_composite(struct device *dev, const char *name,
 			const char **parent_names, int num_parents,
 			struct clk_hw *mux_hw, const struct clk_ops *mux_ops,
-			struct clk_hw *div_hw, const struct clk_ops *div_ops,
+			struct clk_hw *rate_hw, const struct clk_ops *rate_ops,
 			struct clk_hw *gate_hw, const struct clk_ops *gate_ops,
 			unsigned long flags)
 {
@@ -149,15 +149,15 @@ struct clk *clk_register_composite(struct device *dev, const char *name,
 		clk_composite_ops->set_parent = clk_composite_set_parent;
 	}
 
-	if (div_hw && div_ops) {
-		if (!div_ops->recalc_rate || !div_ops->round_rate ||
-		    !div_ops->set_rate) {
+	if (rate_hw && rate_ops) {
+		if (!rate_ops->recalc_rate || !rate_ops->round_rate ||
+		    !rate_ops->set_rate) {
 			clk = ERR_PTR(-EINVAL);
 			goto err;
 		}
 
-		composite->div_hw = div_hw;
-		composite->div_ops = div_ops;
+		composite->rate_hw = rate_hw;
+		composite->rate_ops = rate_ops;
 		clk_composite_ops->recalc_rate = clk_composite_recalc_rate;
 		clk_composite_ops->round_rate = clk_composite_round_rate;
 		clk_composite_ops->set_rate = clk_composite_set_rate;
@@ -187,8 +187,8 @@ struct clk *clk_register_composite(struct device *dev, const char *name,
 	if (composite->mux_hw)
 		composite->mux_hw->clk = clk;
 
-	if (composite->div_hw)
-		composite->div_hw->clk = clk;
+	if (composite->rate_hw)
+		composite->rate_hw->clk = clk;
 
 	if (composite->gate_hw)
 		composite->gate_hw->clk = clk;
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 9fdfae7..766711a 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -352,11 +352,11 @@ struct clk *clk_register_fixed_factor(struct device *dev, const char *name,
  * struct clk_composite - aggregate clock of mux, divider and gate clocks
  *
  * @hw:		handle between common and hardware-specific interfaces
- * @mux_hw:	handle between composite and hardware-specifix mux clock
- * @div_hw:	handle between composite and hardware-specifix divider clock
- * @gate_hw:	handle between composite and hardware-specifix gate clock
+ * @mux_hw:	handle between composite and hardware-specific mux clock
+ * @rate_hw:	handle between composite and hardware-specific rate clock
+ * @gate_hw:	handle between composite and hardware-specific gate clock
  * @mux_ops:	clock ops for mux
- * @div_ops:	clock ops for divider
+ * @rate_ops:	clock ops for rate
  * @gate_ops:	clock ops for gate
  */
 struct clk_composite {
@@ -364,18 +364,18 @@ struct clk_composite {
 	struct clk_ops	ops;
 
 	struct clk_hw	*mux_hw;
-	struct clk_hw	*div_hw;
+	struct clk_hw	*rate_hw;
 	struct clk_hw	*gate_hw;
 
 	const struct clk_ops	*mux_ops;
-	const struct clk_ops	*div_ops;
+	const struct clk_ops	*rate_ops;
 	const struct clk_ops	*gate_ops;
 };
 
 struct clk *clk_register_composite(struct device *dev, const char *name,
 		const char **parent_names, int num_parents,
 		struct clk_hw *mux_hw, const struct clk_ops *mux_ops,
-		struct clk_hw *div_hw, const struct clk_ops *div_ops,
+		struct clk_hw *rate_hw, const struct clk_ops *rate_ops,
 		struct clk_hw *gate_hw, const struct clk_ops *gate_ops,
 		unsigned long flags);
 
-- 
1.7.10.4



From mturquette at linaro.org  Thu Apr 11 14:31:37 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Thu, 11 Apr 2013 11:31:37 -0700
Subject: [PATCH v2 2/2] clk: composite: allow fixed rates & fixed dividers
In-Reply-To: <1365705097-18899-1-git-send-email-mturquette@linaro.org>
References: <1365631378-16103-1-git-send-email-mturquette@linaro.org>
 <1365705097-18899-1-git-send-email-mturquette@linaro.org>
Message-ID: <1365705097-18899-2-git-send-email-mturquette@linaro.org>

The composite clock assumes that any clock implementing the .recalc_rate
callback will also implement .round_rate and .set_rate.  This is not
always true; the basic fixed-rate clock will only implement .recalc_rate
and a fixed-divider clock may choose to implement .recalc_rate and
.round_rate but not .set_rate.

Fix this by conditionally registering .round_rate and .set_rate
callbacks based on the rate_ops passed in to clk_composite_register.

Signed-off-by: Mike Turquette <mturquette at linaro.org>
Cc: Prashant Gaikwad <pgaikwad at nvidia.com>
Tested-by: Emilio L?pez <emilio at elopez.com.ar>
Cc: Gregory CLEMENT <gregory.clement at free-electrons.com>
---
Changes since v1:
* added WARN if set_rate is present without round_rate

 drivers/clk/clk-composite.c |   17 +++++++++++++----
 1 file changed, 13 insertions(+), 4 deletions(-)

diff --git a/drivers/clk/clk-composite.c b/drivers/clk/clk-composite.c
index 6f4728c..a33f46f 100644
--- a/drivers/clk/clk-composite.c
+++ b/drivers/clk/clk-composite.c
@@ -150,17 +150,26 @@ struct clk *clk_register_composite(struct device *dev, const char *name,
 	}
 
 	if (rate_hw && rate_ops) {
-		if (!rate_ops->recalc_rate || !rate_ops->round_rate ||
-		    !rate_ops->set_rate) {
+		if (!rate_ops->recalc_rate) {
 			clk = ERR_PTR(-EINVAL);
 			goto err;
 		}
 
+		/* .round_rate is a prerequisite for .set_rate */
+		if (rate_ops->round_rate) {
+			clk_composite_ops->round_rate = clk_composite_round_rate;
+			if (rate_ops->set_rate) {
+				clk_composite_ops->set_rate = clk_composite_set_rate;
+			}
+		} else {
+			WARN(rate_ops->set_rate,
+				"%s: missing round_rate op is required\n",
+				__func__);
+		}
+
 		composite->rate_hw = rate_hw;
 		composite->rate_ops = rate_ops;
 		clk_composite_ops->recalc_rate = clk_composite_recalc_rate;
-		clk_composite_ops->round_rate = clk_composite_round_rate;
-		clk_composite_ops->set_rate = clk_composite_set_rate;
 	}
 
 	if (gate_hw && gate_ops) {
-- 
1.7.10.4



From kaloz at openwrt.org  Thu Apr 11 14:37:00 2013
From: kaloz at openwrt.org (Imre Kaloz)
Date: Thu, 11 Apr 2013 20:37:00 +0200
Subject: Removal of NWFPE in its entirety, and VFP emulation code
In-Reply-To: <20130410190233.GK14496@n2100.arm.linux.org.uk>
References: <20130410104002.GF14496@n2100.arm.linux.org.uk>
 <alpine.LFD.2.03.1304101307280.17375@syhkavp.arg>
 <20130410185522.GJ14496@n2100.arm.linux.org.uk>
 <alpine.LFD.2.03.1304101457440.17375@syhkavp.arg>
 <20130410190233.GK14496@n2100.arm.linux.org.uk>
Message-ID: <op.wvd3byc02s3iss@ecaz>

On Wed, 10 Apr 2013 21:02:33 +0200, Russell King - ARM Linux <linux at arm.linux.org.uk> wrote:

> On Wed, Apr 10, 2013 at 02:58:57PM -0400, Nicolas Pitre wrote:
>> On Wed, 10 Apr 2013, Russell King - ARM Linux wrote:
>>
>> > On Wed, Apr 10, 2013 at 01:30:35PM -0400, Nicolas Pitre wrote:
>> > > On Wed, 10 Apr 2013, Russell King - ARM Linux wrote:
>> > >
>> > > > I have just committed a patch to remove the arch/arm/nwfpe code from
>> > > > the kernel, and the VFP code emulating the FP operations.
>> > > >
>> > > > This I have done after it has been brought to my attention by the OSADL's
>> > > > GPL-violations project that the license for the softfloat library is
>> > > > incompatible with GPLv2.  This is because the FSF have ruled that
>> > > > indemnification clauses consitute an "additional restriction" which is
>> > > > incompatible with the GPLv2 section 6.  NWFPE contains the softfloat
>> > > > library, and VFP's emulation code is a derivative of softfloat.
>> > > >
>> > > > This will be very disruptive for ARMv4 and ARMv5 CPUs, which will no
>> > > > longer be able to run userspace with NWFPE support removed.  A possible
>> > > > solution there is to resurrect FASTFPE support and merge that into
>> > > > mainline in place of NWFPE.  FASTFPE's hooks are all present in the
>> > > > kernel, and it should just be a case of adding the FASTFPE code.
>> > > > However, FASTFPE is probably lacking GDB and signal stack support.
>> > > > (FastFPE's per-thread workspace is different from NWFPE.)
>> > >
>> > > A point worth mentioning is the EABI availability since 2006 which moved
>> > > away from FPA completely. A soft-float library in user space is used in
>> > > that case.  Major ARM binary producers including all ARM distros moved
>> > > to EABI with user space soft-float since then as it is order of
>> > > magnitude faster than FPA emulation.  So 99.99% of ARMv4 and ARMv5 users
>> > > are unlikely to be affected.
>> > >
>> > > So another option here might imply deprecating OABI support entirely,
>> > > given that it is useless without FPA and people keeping current with the
>> > > latest kernel are very likely to already use EABI user space.
>> >
>> > Unfortunately, I _still_ can't move off OABI.
>>
>> How can this be helped?
>
> I don't think there is a solution - as StrongARM is ARMv4 without Thumb
> support, which means that it's incompatible with EABI which uses bx and
> blx instructions.

May I ask, if you do LFS or are you using some existing distro? Is patching [1] your toolchain a no-go?


Imre


[1]
https://dev.openwrt.org/browser/trunk/toolchain/gcc/patches/4.7-linaro/830-arm_unbreak_armv4t.patch
https://dev.openwrt.org/browser/trunk/toolchain/gcc/patches/4.7-linaro/840-armv4_pass_fix-v4bx_to_ld.patch


From mturquette at linaro.org  Thu Apr 11 14:46:48 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Thu, 11 Apr 2013 11:46:48 -0700
Subject: [RFC][PATCH 1/2] ARM: OMAP4: clock: Add device tree support for
 AUXCLKs
In-Reply-To: <20130410173921.GA31017@kahuna>
References: <515D2D30.3000306@ti.com> <515EA9E3.1010409@ti.com>
 <20130405155851.GA10155@atomide.com> <5163E589.1040809@ti.com>
 <20130409164928.GL10155@atomide.com> <20130409174319.GP10155@atomide.com>
 <20130409204900.GA8815@kahuna> <20130410080630.14359.68178@quantum>
 <5165453E.6090503@ti.com> <20130410173921.GA31017@kahuna>
Message-ID: <20130411184648.7915.17500@quantum>

Quoting Nishanth Menon (2013-04-10 10:39:21)
> diff --git a/drivers/clk/omap/clk.c b/drivers/clk/omap/clk.c
> new file mode 100644
> index 0000000..63a4cce
> --- /dev/null
> +++ b/drivers/clk/omap/clk.c
> @@ -0,0 +1,94 @@
> +/*
> + * Texas Instruments OMAP Clock driver
> + *
> + * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
> + *     Nishanth Menon
> + *     Tony Lindgren <tony at atomide.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.
> + *
> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
> + * kind, whether express or implied; without even the implied warranty
> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include <linux/clkdev.h>
> +#include <linux/clk-private.h>

Please use clk-provider.h.  Otherwise this looks like an OK transitional
solution.  Hopefully this will be replaced with a more legitimate clock
driver for 3.11.

Regards,
Mike


From eduardo.valentin at ti.com  Thu Apr 11 14:47:27 2013
From: eduardo.valentin at ti.com (Eduardo Valentin)
Date: Thu, 11 Apr 2013 14:47:27 -0400
Subject: [v2,01/14] thermal: Rename driver 'kirkwood' -> 'mvebu'
In-Reply-To: <20130411163156.GB2279@localhost>
References: <1363991114-4225-2-git-send-email-ezequiel.garcia@free-electrons.com>
 <5166DE30.3020001@ti.com> <20130411163156.GB2279@localhost>
Message-ID: <5167053F.70709@ti.com>

On 11-04-2013 12:31, Ezequiel Garcia wrote:
> Hi Eduardo,
>
> Thanks for your testing.
>
> On Thu, Apr 11, 2013 at 12:00:48PM -0400, Eduardo Valentin wrote:
>> Hello Ezequiel,
>>
>> Two minor comments.
>>
>> On 22-03-2013 18:25, Ezequiel Garcia wrote:
>>> This driver will support several Marvell SoC, so it is convenient
>>> to rename it to 'mvebu' to represent accurately the hardware it
>>> supports.
>>>
>>> Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
>>>
>>> ---
>>> .../bindings/thermal/kirkwood-thermal.txt          |   15 ---
>>>    .../devicetree/bindings/thermal/mvebu-thermal.txt  |   15 +++
>>>    drivers/thermal/Kconfig                            |   10 +-
>>>    drivers/thermal/Makefile                           |    2 +-
>>>    drivers/thermal/kirkwood_thermal.c                 |  134 --------------------
>>>    drivers/thermal/mvebu_thermal.c                    |  134 ++++++++++++++++++++
>>>    6 files changed, 155 insertions(+), 155 deletions(-)
>>>    delete mode 100644 Documentation/devicetree/bindings/thermal/kirkwood-thermal.txt
>>>    create mode 100644 Documentation/devicetree/bindings/thermal/mvebu-thermal.txt
>>>    delete mode 100644 drivers/thermal/kirkwood_thermal.c
>>>    create mode 100644 drivers/thermal/mvebu_thermal.c
>>
>> When sending renames, use git format-patch --find-renames. The summary
>> will be much descriptive on what you have done.
>>
>
> Yes, you're right I forgot about this.
>
>> I tried applying this patch on top of linux-next, linus/master,
>> ruis/thermal, on top of the your suggested dependencies, and all failed.
>> What is your base?
>>
>
> Well, first of all this patchset has been dropped entirely after some discussion.
> If you're interested in this discussion you can read:
>
>    http://www.spinics.net/lists/arm-kernel/msg231697.html
>
> If you still want to try this series, the easiest way is to try
>
>    https://github.com/MISL-EBU-System-SW/mainline-public/commits/mvebu-thermal-v2
>
> That branch is based on v3.9-rc2, with a bunch of patches applied as
> explained in the cover letter.
>
> I appreciate your feedback a lot, but this are really ancient patches!
> You came in a little late :)


OK. Thanks for updating me. On the other hand. Some of your patches are 
still applicable. Can you please resend them based on kirkwood file still?

>



From mturquette at linaro.org  Thu Apr 11 14:52:58 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Thu, 11 Apr 2013 11:52:58 -0700
Subject: [PATCH v8 1/7] media: V4L2: add temporary clock helpers
In-Reply-To: <CAGsJ_4yXE7SYLgPucW9kAEYgKg+z93j8yN3d+gvhqeLAn-sSOw@mail.gmail.com>
References: <CAGsJ_4zCRBvEX9xEDCr27JLK6wYp_2T_wk2hzVjqpKinbL=9pg@mail.gmail.com>
 <Pine.LNX.4.64.1304110921480.23859@axis700.grange>
 <CAGsJ_4xXRHDbpuqT3e5=0vz9_NxxCXfvrci+h567HP9=AhwRiQ@mail.gmail.com>
 <Pine.LNX.4.64.1304111028090.23859@axis700.grange>
 <CAGsJ_4yXE7SYLgPucW9kAEYgKg+z93j8yN3d+gvhqeLAn-sSOw@mail.gmail.com>
Message-ID: <20130411185258.7915.67263@quantum>

Quoting Barry Song (2013-04-11 01:59:28)
> 2013/4/11 Guennadi Liakhovetski <g.liakhovetski at gmx.de>:
> > On Thu, 11 Apr 2013, Barry Song wrote:
> >
> >> 2013/4/11 Guennadi Liakhovetski <g.liakhovetski at gmx.de>:
> >> > Hi Barry
> >> >
> >> > On Thu, 11 Apr 2013, Barry Song wrote:
> >> >
> >> >> Hi Guennadi,
> >> >>
> >> >> > Typical video devices like camera sensors require an external clock source.
> >> >> > Many such devices cannot even access their hardware registers without a
> >> >> > running clock. These clock sources should be controlled by their consumers.
> >> >> > This should be performed, using the generic clock framework. Unfortunately
> >> >> > so far only very few systems have been ported to that framework. This patch
> >> >> > adds a set of temporary helpers, mimicking the generic clock API, to V4L2.
> >> >> > Platforms, adopting the clock API, should switch to using it. Eventually
> >> >> > this temporary API should be removed.
> >> >>
> >> >> > Signed-off-by: Guennadi Liakhovetski <g.liakhovetski at xxxxxx>
> >> >> > ---
> >> >>
> >> >> for your patch 1/8 and 3/8, i think it makes a lot of senses to let
> >> >> the object manages its own clock by itself.
> >> >> is it possible for us to implement v4l2-clk.c directly as an instance
> >> >> of standard clk driver for those systems which don't have generic
> >> >> clock,  and remove the V4L2 clock APIs like v4l2_clk_get,
> >> >> v4l2_clk_enable from the first day? i mean v4l2-clk.c becomes a temp
> >> >> and fake clock controller driver. finally, after people have
> >> >> generically clk, remove it.
> >> >
> >> > I don't think you can force-enable the CFF on systems, that don't support
> >> > it, e.g. PXA.
> >>
> >> yes. we can. clock is only a framework, has it any limitation to
> >> implement a driver instance on any platform?
> >
> > So, you enable CFF, it provides its own clk_* implementation like
> > clk_get_rate() etc. Now, PXA already has it defined in
> > arch/arm/mach-pxa/clock.c. Don't think this is going to fly.
> 
> agree.
> 

Hi,

I came into this thread late and don't have the actual patches in my
inbox for review.  That said, I don't understand why V4L2 cares about
the clk framework *implementation*?  The clk.h api is the same for
platforms using the common struct clk and those still using the legacy
method of defining their own struct clk.  If drivers are only consumers
of the clk.h api then the implementation underneath should not matter.

Regards,
Mike

> >
> > Thanks
> > Guennadi
> >
> >> people have tried to move to common clk and generic framework for a
> >> long time, now you still try to provide a v4l2 specific clock APIs, it
> >> just makes v4l2 unacceptable and much complex.
> >>
> >> >
> >> > Thanks
> >> > Guennadi
> >> >
> >> >> > v8: Updated both (C) dates
> >> >>
> >> >> >  drivers/media/v4l2-core/Makefile   |    2 +-
> >> >> >  drivers/media/v4l2-core/v4l2-clk.c |  177 ++++++++++++++++++++++++++++++++++++
> >> >> >  include/media/v4l2-clk.h           |   54 +++++++++++
> >> >> >  3 files changed, 232 insertions(+), 1 deletions(-)
> >> >> >  create mode 100644 drivers/media/v4l2-core/v4l2-clk.c
> >> >> >  create mode 100644 include/media/v4l2-clk.h
> >> >>
> >> >> > diff --git a/drivers/media/v4l2-core/Makefile b/drivers/media/v4l2-core/Makefile
> >> >> > index aa50c46..628c630 100644
> >> >> > --- a/drivers/media/v4l2-core/Makefile
> >> >> > +++ b/drivers/media/v4l2-core/Makefile
> >> >> > @@ -5,7 +5,7 @@
> >> >> >  tuner-objs :=      tuner-core.o
> >> >>
> >> >> >  videodev-objs      :=      v4l2-dev.o v4l2-ioctl.o v4l2-device.o v4l2-fh.o \
> >> >> > -                   v4l2-event.o v4l2-ctrls.o v4l2-subdev.o
> >> >> > +                   v4l2-event.o v4l2-ctrls.o v4l2-subdev.o v4l2-clk.o
> >> >> > ifeq ($(CONFIG_COMPAT),y)
> >> >> >    videodev-objs += v4l2-compat-ioctl32.o
> >> >> >  endif
> >> >> > diff --git a/drivers/media/v4l2-core/v4l2-clk.c b/drivers/media/v4l2-core/v4l2-clk.c
> >> >> > new file mode 100644
> >> >> > index 0000000..d7cc13e
> >> >> > --- /dev/null
> >> >> > +++ b/drivers/media/v4l2-core/v4l2-clk.c
> >> >> > @@ -0,0 +1,177 @@
> >> >>
> >> >> -barry
> 
> -barry
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From eduardo.valentin at ti.com  Thu Apr 11 14:54:17 2013
From: eduardo.valentin at ti.com (Eduardo Valentin)
Date: Thu, 11 Apr 2013 14:54:17 -0400
Subject: [v2,
 04/14] thermal: mvebu: Remove unneeded variable initialization
In-Reply-To: <5166E4E2.1080606@ti.com>
References: <1363991114-4225-5-git-send-email-ezequiel.garcia@free-electrons.com>
 <5166E4E2.1080606@ti.com>
Message-ID: <516706D9.6000604@ti.com>

Ezequiel,


On 11-04-2013 12:29, Eduardo Valentin wrote:
> Rui, Ezequiel,
>
> On 22-03-2013 18:25, Ezequiel Garcia wrote:
>> This variable is used only after it's properly initialized,
>> so there's no need to set it to NULL in its declaration.
>>
>> Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
>>
>
> I am fine with this patch. Though it doesn t hurt to have this
> initialization, the code looks cleaner though.
>
> Acked-by: Eduardo Valentin <eduardo.valentin at ti.com>

I know you have discarded the idea of merging the driver into a single 
driver, but can you please resend this patch on top of 
drivers/thermal/kirkwood_thermal.c file. This change still applies.

>
>
>> ---
>> drivers/thermal/mvebu_thermal.c |    2 +-
>>   1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/thermal/mvebu_thermal.c
>> b/drivers/thermal/mvebu_thermal.c
>> index 031f94d..1f502ed 100644
>> --- a/drivers/thermal/mvebu_thermal.c
>> +++ b/drivers/thermal/mvebu_thermal.c
>> @@ -72,7 +72,7 @@ MODULE_DEVICE_TABLE(of, mvebu_thermal_id_table);
>>
>>   static int mvebu_thermal_probe(struct platform_device *pdev)
>>   {
>> -    struct thermal_zone_device *thermal = NULL;
>> +    struct thermal_zone_device *thermal;
>>       struct mvebu_thermal_priv *priv;
>>       struct resource *res;
>>
>>
>
>
>



From eduardo.valentin at ti.com  Thu Apr 11 14:55:06 2013
From: eduardo.valentin at ti.com (Eduardo Valentin)
Date: Thu, 11 Apr 2013 14:55:06 -0400
Subject: [v2,05/14] thermal: mvebu: Convert to devm_ioremap_resource()
In-Reply-To: <5166E66B.6080406@ti.com>
References: <1363991114-4225-6-git-send-email-ezequiel.garcia@free-electrons.com>
 <5166E66B.6080406@ti.com>
Message-ID: <5167070A.1070809@ti.com>

Ezequiel,

On 11-04-2013 12:35, Eduardo Valentin wrote:
> Rui,
>
> On 22-03-2013 18:25, Ezequiel Garcia wrote:
>> Convert devm_request_and_ioremap() to the newly introduced
>> devm_ioremap_resource() which provides more consistent error handling.
>>
>> Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
>>
>
> This patch looks correct to me too.
>
> Acked-by: Eduardo Valentin <eduardo.valentin at ti.com>
>


I know you have discarded the idea of merging the driver into a single 
driver, but can you please resend this patch on top of 
drivers/thermal/kirkwood_thermal.c file. This change still applies.

>> ---
>> drivers/thermal/mvebu_thermal.c |    8 +++-----
>>   1 files changed, 3 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/thermal/mvebu_thermal.c
>> b/drivers/thermal/mvebu_thermal.c
>> index 1f502ed..2aeaf75 100644
>> --- a/drivers/thermal/mvebu_thermal.c
>> +++ b/drivers/thermal/mvebu_thermal.c
>> @@ -86,11 +86,9 @@ static int mvebu_thermal_probe(struct
>> platform_device *pdev)
>>       if (!priv)
>>           return -ENOMEM;
>>
>> -    priv->sensor = devm_request_and_ioremap(&pdev->dev, res);
>> -    if (!priv->sensor) {
>> -        dev_err(&pdev->dev, "Failed to request_ioremap memory\n");
>> -        return -EADDRNOTAVAIL;
>> -    }
>> +    priv->sensor = devm_ioremap_resource(&pdev->dev, res);
>> +    if (IS_ERR(priv->sensor))
>> +        return PTR_ERR(priv->sensor);
>>
>>       thermal = thermal_zone_device_register("mvebu_thermal", 0, 0,
>>                              priv, &ops, NULL, 0, 0);
>>
>
>
>



From eduardo.valentin at ti.com  Thu Apr 11 14:55:57 2013
From: eduardo.valentin at ti.com (Eduardo Valentin)
Date: Thu, 11 Apr 2013 14:55:57 -0400
Subject: [v2,06/14] thermal: mvebu: Fix license declaration
In-Reply-To: <5166E76E.5020104@ti.com>
References: <1363991114-4225-7-git-send-email-ezequiel.garcia@free-electrons.com>
 <5166E76E.5020104@ti.com>
Message-ID: <5167073D.3030605@ti.com>

Ezequiel,

On 11-04-2013 12:40, Eduardo Valentin wrote:
> Hi Rui,
>
> On 22-03-2013 18:25, Ezequiel Garcia wrote:
>> The license text declared in the header explicit says GPL v2 only,
>> but the MODULE_LICENSE macro says GPL, which means GPL v2 or later.
>> Fix it.
>>
>> Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
>>
>
> This specific patch is fine to me.
>
> Acked-by: Eduardo Valentin <eduardo.valentin at ti.com>
>


I know you have discarded the idea of merging the driver into a single 
driver, but can you please resend this patch on top of 
drivers/thermal/kirkwood_thermal.c file. This change still applies.

>> ---
>> drivers/thermal/mvebu_thermal.c |    2 +-
>>   1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/thermal/mvebu_thermal.c
>> b/drivers/thermal/mvebu_thermal.c
>> index 2aeaf75..0c9344d 100644
>> --- a/drivers/thermal/mvebu_thermal.c
>> +++ b/drivers/thermal/mvebu_thermal.c
>> @@ -128,4 +128,4 @@ module_platform_driver(mvebu_thermal_driver);
>>
>>   MODULE_AUTHOR("Nobuhiro Iwamatsu <iwamatsu at nigauri.org>");
>>   MODULE_DESCRIPTION("mvebu thermal driver");
>> -MODULE_LICENSE("GPL");
>> +MODULE_LICENSE("GPL v2");
>>
>
> Side question, while here:
> Ezequiel, does this driver need a MODULE_ALIAS
>
>
>



From eduardo.valentin at ti.com  Thu Apr 11 14:57:17 2013
From: eduardo.valentin at ti.com (Eduardo Valentin)
Date: Thu, 11 Apr 2013 14:57:17 -0400
Subject: [v2,01/14] thermal: Rename driver 'kirkwood' -> 'mvebu'
In-Reply-To: <5167053F.70709@ti.com>
References: <1363991114-4225-2-git-send-email-ezequiel.garcia@free-electrons.com>
 <5166DE30.3020001@ti.com> <20130411163156.GB2279@localhost>
 <5167053F.70709@ti.com>
Message-ID: <5167078D.7010807@ti.com>

On 11-04-2013 14:47, Eduardo Valentin wrote:
> On 11-04-2013 12:31, Ezequiel Garcia wrote:
>> Hi Eduardo,
>>
>> Thanks for your testing.
>>
>> On Thu, Apr 11, 2013 at 12:00:48PM -0400, Eduardo Valentin wrote:
>>> Hello Ezequiel,
>>>
>>> Two minor comments.
>>>
>>> On 22-03-2013 18:25, Ezequiel Garcia wrote:
>>>> This driver will support several Marvell SoC, so it is convenient
>>>> to rename it to 'mvebu' to represent accurately the hardware it
>>>> supports.
>>>>
>>>> Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
>>>>
>>>> ---
>>>> .../bindings/thermal/kirkwood-thermal.txt          |   15 ---
>>>>    .../devicetree/bindings/thermal/mvebu-thermal.txt  |   15 +++
>>>>    drivers/thermal/Kconfig                            |   10 +-
>>>>    drivers/thermal/Makefile                           |    2 +-
>>>>    drivers/thermal/kirkwood_thermal.c                 |  134
>>>> --------------------
>>>>    drivers/thermal/mvebu_thermal.c                    |  134
>>>> ++++++++++++++++++++
>>>>    6 files changed, 155 insertions(+), 155 deletions(-)
>>>>    delete mode 100644
>>>> Documentation/devicetree/bindings/thermal/kirkwood-thermal.txt
>>>>    create mode 100644
>>>> Documentation/devicetree/bindings/thermal/mvebu-thermal.txt
>>>>    delete mode 100644 drivers/thermal/kirkwood_thermal.c
>>>>    create mode 100644 drivers/thermal/mvebu_thermal.c
>>>
>>> When sending renames, use git format-patch --find-renames. The summary
>>> will be much descriptive on what you have done.
>>>
>>
>> Yes, you're right I forgot about this.
>>
>>> I tried applying this patch on top of linux-next, linus/master,
>>> ruis/thermal, on top of the your suggested dependencies, and all failed.
>>> What is your base?
>>>
>>
>> Well, first of all this patchset has been dropped entirely after some
>> discussion.
>> If you're interested in this discussion you can read:
>>
>>    http://www.spinics.net/lists/arm-kernel/msg231697.html
>>
>> If you still want to try this series, the easiest way is to try
>>
>>
>> https://github.com/MISL-EBU-System-SW/mainline-public/commits/mvebu-thermal-v2
>>
>>
>> That branch is based on v3.9-rc2, with a bunch of patches applied as
>> explained in the cover letter.
>>
>> I appreciate your feedback a lot, but this are really ancient patches!
>> You came in a little late :)
>
>
> OK. Thanks for updating me. On the other hand. Some of your patches are
> still applicable. Can you please resend them based on kirkwood file still?
>

Specifically, patches 04/05/06 are still applicable to the kirkwood 
driver. Feel free to resend them with my Acked-by.

>>
>
>
>



From linux at prisktech.co.nz  Thu Apr 11 15:00:29 2013
From: linux at prisktech.co.nz (Tony Prisk)
Date: Fri, 12 Apr 2013 07:00:29 +1200
Subject: [PATCH] arm: vt8500: Add SDHC support to WM8505 DT
Message-ID: <1365706829-9626-1-git-send-email-linux@prisktech.co.nz>

This patch adds the required node for the SDHC controller on WM8505 SoCs.

Signed-off-by: Tony Prisk <linux at prisktech.co.nz>
---
Arnd,

Any chance you can apply this for 3.10

Regards
Ton yP
 arch/arm/boot/dts/wm8505.dtsi |   31 +++++++++++++++++++++++++++++++
 1 file changed, 31 insertions(+)

diff --git a/arch/arm/boot/dts/wm8505.dtsi b/arch/arm/boot/dts/wm8505.dtsi
index e74a1c0..388f26d 100644
--- a/arch/arm/boot/dts/wm8505.dtsi
+++ b/arch/arm/boot/dts/wm8505.dtsi
@@ -60,6 +60,19 @@
 					clock-frequency = <24000000>;
 				};
 
+				ref25: ref25M {
+					#clock-cells = <0>;
+					compatible = "fixed-clock";
+					clock-frequency = <25000000>;
+				};
+
+				pllb: pllb {
+					#clock-cells = <0>;
+					compatible = "via,vt8500-pll-clock";
+					clocks = <&ref25>;
+					reg = <0x204>;
+				};
+
 				clkuart0: uart0 {
 					#clock-cells = <0>;
 					compatible = "via,vt8500-device-clock";
@@ -107,6 +120,16 @@
 					enable-reg = <0x250>;
 					enable-bit = <23>;
 				};
+
+				clksdhc: sdhc {
+					#clock-cells = <0>;
+					compatible = "via,vt8500-device-clock";
+					clocks = <&pllb>;
+					divisor-reg = <0x328>;
+					divisor-mask = <0x3f>;
+					enable-reg = <0x254>;
+					enable-bit = <18>;
+				};
 			};
 		};
 
@@ -187,5 +210,13 @@
 			reg = <0xd8100000 0x10000>;
 			interrupts = <48>;
 		};
+
+		sdhc at d800a000 {
+			compatible = "wm,wm8505-sdhc";
+			reg = <0xd800a000 0x1000>;
+			interrupts = <20 21>;
+			clocks = <&clksdhc>;
+			bus-width = <4>;
+		};
 	};
 };
-- 
1.7.9.5



From heiko at sntech.de  Thu Apr 11 15:02:43 2013
From: heiko at sntech.de (Heiko =?iso-8859-15?q?St=FCbner?=)
Date: Thu, 11 Apr 2013 21:02:43 +0200
Subject: [PATCH] ASoC: samsung: fix neo1973-wm8753 compilation
In-Reply-To: <20130411171938.GS9243@opensource.wolfsonmicro.com>
References: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
 <201304111908.42532.arnd@arndb.de>
 <20130411171938.GS9243@opensource.wolfsonmicro.com>
Message-ID: <201304112102.43896.heiko@sntech.de>

Commit b2ca78717cea (ARM: S3C24XX: make gta02.h local) already replaced
the GTA02_GPIO_* constants in neo1973-wm8753.c but forgot to remove the
inclusion of mach/gta02.h before moving the file out of mach/.

Signed-off-by: Heiko Stuebner <heiko at sntech.de>
---
 sound/soc/samsung/neo1973_wm8753.c |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/sound/soc/samsung/neo1973_wm8753.c b/sound/soc/samsung/neo1973_wm8753.c
index a301d8c..68675dd 100644
--- a/sound/soc/samsung/neo1973_wm8753.c
+++ b/sound/soc/samsung/neo1973_wm8753.c
@@ -22,7 +22,6 @@
 
 #include <asm/mach-types.h>
 #include <plat/regs-iis.h>
-#include <mach/gta02.h>
 
 #include "../codecs/wm8753.h"
 #include "s3c24xx-i2s.h"
-- 
1.7.2.3



From ezequiel.garcia at free-electrons.com  Thu Apr 11 15:09:24 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Thu, 11 Apr 2013 16:09:24 -0300
Subject: [v2,01/14] thermal: Rename driver 'kirkwood' -> 'mvebu'
In-Reply-To: <5167053F.70709@ti.com>
References: <1363991114-4225-2-git-send-email-ezequiel.garcia@free-electrons.com>
 <5166DE30.3020001@ti.com> <20130411163156.GB2279@localhost>
 <5167053F.70709@ti.com>
Message-ID: <20130411190923.GC14229@localhost>

On Thu, Apr 11, 2013 at 02:47:27PM -0400, Eduardo Valentin wrote:
> >
> > I appreciate your feedback a lot, but this are really ancient patches!
> > You came in a little late :)
> 
> 
> OK. Thanks for updating me. On the other hand. Some of your patches are 
> still applicable. Can you please resend them based on kirkwood file still?
> 

Yes, that's the plan! (and thanks for remembering me)

I'll resubmit the appropriate patches, with your Acked-by.

Thanks for reviewing,
-- 
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com


From sebastian.hesselbarth at gmail.com  Thu Apr 11 15:11:28 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Thu, 11 Apr 2013 21:11:28 +0200
Subject: [PATCH] net: mv643xx_eth: remove deprecated inet_lro support
Message-ID: <1365707488-28819-1-git-send-email-sebastian.hesselbarth@gmail.com>

With recent support for GRO, there is no need to keep both LRO and
GRO. This patch therefore removes the deprecated inet_lro support
from mv643xx_eth. This is work is based on an experimental patch
provided by Eric Dumazet and Willy Tarreau.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
Based-on-patch-by: Eric Dumazet <eric.dumazet at gmail.com>
Based-on-patch-by: Willy Tarreau <w at 1wt.eu>
---
Note: This patch is based upon recent cleanup patches and GRO support
patch for mv643xx_eth.

Cc: "David S. Miller" <davem at davemloft.net>
Cc: Lennert Buytenhek <buytenh at wantstofly.org>
Cc: Andrew Lunn <andrew at lunn.ch>
Cc: Jason Cooper <jason at lakedaemon.net>
Cc: Florian Fainelli <florian at openwrt.org>
Cc: Benjamin Herrenschmidt <benh at kernel.crashing.org>
Cc: Paul Mackerras <paulus at samba.org>
Cc: Dale Farnsworth <dale at farnsworth.org>
Cc: Ben Hutchings <bhutchings at solarflare.com>
Cc: Soeren Moch <smoch at web.de>
Cc: Eric Dumazet <eric.dumazet at gmail.com>
Cc: Willy Tarreau <w at 1wt.eu>
Cc: netdev at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linuxppc-dev at lists.ozlabs.org
Cc: linux-kernel at vger.kernel.org
---
 drivers/net/ethernet/marvell/mv643xx_eth.c |   97 +---------------------------
 1 file changed, 3 insertions(+), 94 deletions(-)

diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c b/drivers/net/ethernet/marvell/mv643xx_eth.c
index c850d04..d0afeea 100644
--- a/drivers/net/ethernet/marvell/mv643xx_eth.c
+++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
@@ -56,8 +56,8 @@
 #include <linux/phy.h>
 #include <linux/mv643xx_eth.h>
 #include <linux/io.h>
+#include <linux/interrupt.h>
 #include <linux/types.h>
-#include <linux/inet_lro.h>
 #include <linux/slab.h>
 #include <linux/clk.h>
 
@@ -316,12 +316,6 @@ struct mib_counters {
 	u32 rx_overrun;
 };
 
-struct lro_counters {
-	u32 lro_aggregated;
-	u32 lro_flushed;
-	u32 lro_no_desc;
-};
-
 struct rx_queue {
 	int index;
 
@@ -335,9 +329,6 @@ struct rx_queue {
 	dma_addr_t rx_desc_dma;
 	int rx_desc_area_size;
 	struct sk_buff **rx_skb;
-
-	struct net_lro_mgr lro_mgr;
-	struct net_lro_desc lro_arr[8];
 };
 
 struct tx_queue {
@@ -373,8 +364,6 @@ struct mv643xx_eth_private {
 	spinlock_t mib_counters_lock;
 	struct mib_counters mib_counters;
 
-	struct lro_counters lro_counters;
-
 	struct work_struct tx_timeout_task;
 
 	struct napi_struct napi;
@@ -503,42 +492,12 @@ static void txq_maybe_wake(struct tx_queue *txq)
 	}
 }
 
-
-/* rx napi ******************************************************************/
-static int
-mv643xx_get_skb_header(struct sk_buff *skb, void **iphdr, void **tcph,
-		       u64 *hdr_flags, void *priv)
-{
-	unsigned long cmd_sts = (unsigned long)priv;
-
-	/*
-	 * Make sure that this packet is Ethernet II, is not VLAN
-	 * tagged, is IPv4, has a valid IP header, and is TCP.
-	 */
-	if ((cmd_sts & (RX_IP_HDR_OK | RX_PKT_IS_IPV4 |
-		       RX_PKT_IS_ETHERNETV2 | RX_PKT_LAYER4_TYPE_MASK |
-		       RX_PKT_IS_VLAN_TAGGED)) !=
-	    (RX_IP_HDR_OK | RX_PKT_IS_IPV4 |
-	     RX_PKT_IS_ETHERNETV2 | RX_PKT_LAYER4_TYPE_TCP_IPV4))
-		return -1;
-
-	skb_reset_network_header(skb);
-	skb_set_transport_header(skb, ip_hdrlen(skb));
-	*iphdr = ip_hdr(skb);
-	*tcph = tcp_hdr(skb);
-	*hdr_flags = LRO_IPV4 | LRO_TCP;
-
-	return 0;
-}
-
 static int rxq_process(struct rx_queue *rxq, int budget)
 {
 	struct mv643xx_eth_private *mp = rxq_to_mp(rxq);
 	struct net_device_stats *stats = &mp->dev->stats;
-	int lro_flush_needed;
 	int rx;
 
-	lro_flush_needed = 0;
 	rx = 0;
 	while (rx < budget && rxq->rx_desc_count) {
 		struct rx_desc *rx_desc;
@@ -599,12 +558,7 @@ static int rxq_process(struct rx_queue *rxq, int budget)
 			skb->ip_summed = CHECKSUM_UNNECESSARY;
 		skb->protocol = eth_type_trans(skb, mp->dev);
 
-		if (skb->dev->features & NETIF_F_LRO &&
-		    skb->ip_summed == CHECKSUM_UNNECESSARY) {
-			lro_receive_skb(&rxq->lro_mgr, skb, (void *)cmd_sts);
-			lro_flush_needed = 1;
-		} else
-			napi_gro_receive(&mp->napi, skb);
+		napi_gro_receive(&mp->napi, skb);
 
 		continue;
 
@@ -624,9 +578,6 @@ err:
 		dev_kfree_skb(skb);
 	}
 
-	if (lro_flush_needed)
-		lro_flush_all(&rxq->lro_mgr);
-
 	if (rx < budget)
 		mp->work_rx &= ~(1 << rxq->index);
 
@@ -1118,26 +1069,6 @@ static struct net_device_stats *mv643xx_eth_get_stats(struct net_device *dev)
 	return stats;
 }
 
-static void mv643xx_eth_grab_lro_stats(struct mv643xx_eth_private *mp)
-{
-	u32 lro_aggregated = 0;
-	u32 lro_flushed = 0;
-	u32 lro_no_desc = 0;
-	int i;
-
-	for (i = 0; i < mp->rxq_count; i++) {
-		struct rx_queue *rxq = mp->rxq + i;
-
-		lro_aggregated += rxq->lro_mgr.stats.aggregated;
-		lro_flushed += rxq->lro_mgr.stats.flushed;
-		lro_no_desc += rxq->lro_mgr.stats.no_desc;
-	}
-
-	mp->lro_counters.lro_aggregated = lro_aggregated;
-	mp->lro_counters.lro_flushed = lro_flushed;
-	mp->lro_counters.lro_no_desc = lro_no_desc;
-}
-
 static inline u32 mib_read(struct mv643xx_eth_private *mp, int offset)
 {
 	return rdl(mp, MIB_COUNTERS(mp->port_num) + offset);
@@ -1301,10 +1232,6 @@ struct mv643xx_eth_stats {
 	{ #m, FIELD_SIZEOF(struct mib_counters, m),		\
 	  -1, offsetof(struct mv643xx_eth_private, mib_counters.m) }
 
-#define LROSTAT(m)						\
-	{ #m, FIELD_SIZEOF(struct lro_counters, m),		\
-	  -1, offsetof(struct mv643xx_eth_private, lro_counters.m) }
-
 static const struct mv643xx_eth_stats mv643xx_eth_stats[] = {
 	SSTAT(rx_packets),
 	SSTAT(tx_packets),
@@ -1346,9 +1273,6 @@ static const struct mv643xx_eth_stats mv643xx_eth_stats[] = {
 	MIBSTAT(late_collision),
 	MIBSTAT(rx_discard),
 	MIBSTAT(rx_overrun),
-	LROSTAT(lro_aggregated),
-	LROSTAT(lro_flushed),
-	LROSTAT(lro_no_desc),
 };
 
 static int
@@ -1578,7 +1502,6 @@ static void mv643xx_eth_get_ethtool_stats(struct net_device *dev,
 
 	mv643xx_eth_get_stats(dev);
 	mib_counters_update(mp);
-	mv643xx_eth_grab_lro_stats(mp);
 
 	for (i = 0; i < ARRAY_SIZE(mv643xx_eth_stats); i++) {
 		const struct mv643xx_eth_stats *stat;
@@ -1851,19 +1774,6 @@ static int rxq_init(struct mv643xx_eth_private *mp, int index)
 					nexti * sizeof(struct rx_desc);
 	}
 
-	rxq->lro_mgr.dev = mp->dev;
-	memset(&rxq->lro_mgr.stats, 0, sizeof(rxq->lro_mgr.stats));
-	rxq->lro_mgr.features = LRO_F_NAPI;
-	rxq->lro_mgr.ip_summed = CHECKSUM_UNNECESSARY;
-	rxq->lro_mgr.ip_summed_aggr = CHECKSUM_UNNECESSARY;
-	rxq->lro_mgr.max_desc = ARRAY_SIZE(rxq->lro_arr);
-	rxq->lro_mgr.max_aggr = 32;
-	rxq->lro_mgr.frag_align_pad = 0;
-	rxq->lro_mgr.lro_arr = rxq->lro_arr;
-	rxq->lro_mgr.get_skb_header = mv643xx_get_skb_header;
-
-	memset(&rxq->lro_arr, 0, sizeof(rxq->lro_arr));
-
 	return 0;
 
 
@@ -2851,8 +2761,7 @@ static int mv643xx_eth_probe(struct platform_device *pdev)
 	dev->watchdog_timeo = 2 * HZ;
 	dev->base_addr = 0;
 
-	dev->hw_features = NETIF_F_SG | NETIF_F_IP_CSUM |
-		NETIF_F_RXCSUM | NETIF_F_LRO;
+	dev->hw_features = NETIF_F_SG | NETIF_F_IP_CSUM | NETIF_F_RXCSUM;
 	dev->features = NETIF_F_SG | NETIF_F_IP_CSUM | NETIF_F_RXCSUM;
 	dev->vlan_features = NETIF_F_SG | NETIF_F_IP_CSUM;
 
-- 
1.7.10.4



From andrew at lunn.ch  Thu Apr 11 15:33:49 2013
From: andrew at lunn.ch (Andrew Lunn)
Date: Thu, 11 Apr 2013 21:33:49 +0200
Subject: [PATCHv2 08/10] arm: kirkwood: convert QNAP TS219 to use DT for
 the PCIe interface
In-Reply-To: <1365632436-25367-9-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1365632436-25367-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1365632436-25367-9-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <20130411193349.GA5061@lunn.ch>

On Thu, Apr 11, 2013 at 12:20:34AM +0200, Thomas Petazzoni wrote:
> Now that the PCIe mvebu driver is usable on Kirkwood, use it instead
> of the legacy PCIe code, since it allows to describe the PCIe
> interfaces in the Device Tree.
> 
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> ---
>  arch/arm/boot/dts/kirkwood-ts219.dtsi |    7 +++++++
>  arch/arm/mach-kirkwood/board-ts219.c  |   10 ----------
>  2 files changed, 7 insertions(+), 10 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/kirkwood-ts219.dtsi b/arch/arm/boot/dts/kirkwood-ts219.dtsi
> index 64ea27c..341e1d8 100644
> --- a/arch/arm/boot/dts/kirkwood-ts219.dtsi
> +++ b/arch/arm/boot/dts/kirkwood-ts219.dtsi
> @@ -74,5 +74,12 @@
>  			status = "okay";
>  			nr-ports = <2>;
>  		};
> +		pcie-controller {
> +			status = "okay";
> +
> +			pcie at 1,0 {
> +				status = "okay";
> +			};
> +		};
>  	};
>  };

Hi Thomas

There is some DT weirdness going on here. With that you have above,
the .dtb file has both status="disabled" when i convert it back to dts
format.

In order to get it to work, i had to move this fragment into the
kirkwood-ts219-628[12].dtsi files.

Can some dtc guru comment if this is supposed to work with the
arrangement of includes we have?

    Thanks
	Andrew


From sebastian.hesselbarth at gmail.com  Thu Apr 11 15:42:29 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Thu, 11 Apr 2013 21:42:29 +0200
Subject: [PATCH v8] clk: add si5351 i2c common clock driver
In-Reply-To: <1365586810-6752-1-git-send-email-sebastian.hesselbarth@gmail.com>
References: <1365586810-6752-1-git-send-email-sebastian.hesselbarth@gmail.com>
Message-ID: <1365709350-8344-1-git-send-email-sebastian.hesselbarth@gmail.com>

This patch adds a common clock driver for Silicon Labs Si5351a/b/c
i2c programmable clock generators. Currently, the driver does not
support VXCO feature of si5351b. Passing platform_data or DT bindings
selectively allows to overwrite stored Si5351 configuration which is
very helpful for clock generators with empty eeprom configuration.
Corresponding device tree binding documentation is also added.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
Tested-by: Daniel Mack <zonque at gmail.com>
Acked-by: Guenter Roeck <linux at roeck-us.net>
---
Changes from v7:
- readd clk powerup on clkout set_rate (Suggested by Michal Bachraty)

Changes from v6:
- make invalid DT data parsing fatal (Suggested by Guenter Roeck)
- add more variant checks and return errors
- remove inline from _si5351_* functions
- remove pll reset/clkout powerdown for gapless tuning
  (Provided by Michal Backraty)

Changes from v5:
- removed __clk_set_flags
- remove CONFIG_OF dependency
- introduce si5351_platform_data (non-DT untested)
- parse DT into si5351_platform_data (tested)
- minor cleanups

Changes from v4:
- move from clk-private.h to clk-provider.h (Reported by Mike Turquette)
- use __clk_set_flags() helper

Changes from v3:
- add silabs prefix to custom DT properties (Reported by Lars-Peter Clausen)
- use sizeof(*foo) instead of sizeof(struct bar) (Reported by Lars-Peter Clausen)
- check return value of of_clk_add_provider (Reported by Lars-Peter Clausen)
- clean up i2c client init (Reported by Lars-Peter Clausen)
- silence successful probe (Suggested by Lars-Peter Clausen)
- make CONFIG_CLK_SI5351 depend on CONFIG_OF

Changes from v2:
- add curly brackets to if-else-statements (Reported by Daniel Mack)
- fix div-by-zero for clk6/clk7 (Reported by Daniel Mack)
- fix parameter address calculation for clk6/clk7

Changes from v1:
- remove .is_enabled functions as they read from i2c
  (Reported by Daniel Mack)
- add CLK_SET_RATE_PARENT on clkout reparent if clkout uses
  its own multisync

Cc: Grant Likely <grant.likely at secretlab.ca>
Cc: Rob Herring <rob.herring at calxeda.com>
Cc: Rob Landley <rob at landley.net>
Cc: Mike Turquette <mturquette at linaro.org>
Cc: Stephen Warren <swarren at nvidia.com>
Cc: Thierry Reding <thierry.reding at avionic-design.de>
Cc: Dom Cobley <popcornmix at gmail.com>
Cc: Linus Walleij <linus.walleij at linaro.org>
Cc: Arnd Bergmann <arnd at arndb.de>
Cc: Andrew Morton <akpm at linux-foundation.org>
Cc: Pawel Moll <pawel.moll at arm.com>
Cc: Mark Brown <broonie at opensource.wolfsonmicro.com>
Cc: Russell King - ARM Linux <linux at arm.linux.org.uk>
Cc: Rabeeh Khoury <rabeeh at solid-run.com>
Cc: Daniel Mack <zonque at gmail.com>
Cc: Jean-Francois Moine <moinejf at free.fr>
Cc: Lars-Peter Clausen <lars at metafoo.de>
Cc: Guenter Roeck <linux at roeck-us.net>
Cc: Michal Bachraty <michal.bachraty at streamunlimited.com>
Cc: devicetree-discuss at lists.ozlabs.org
Cc: linux-doc at vger.kernel.org
Cc: linux-kernel at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
---
 .../devicetree/bindings/clock/silabs,si5351.txt    |  114 ++
 .../devicetree/bindings/vendor-prefixes.txt        |    1 +
 drivers/clk/Kconfig                                |    9 +
 drivers/clk/Makefile                               |    1 +
 drivers/clk/clk-si5351.c                           | 1510 ++++++++++++++++++++
 drivers/clk/clk-si5351.h                           |  155 ++
 include/linux/platform_data/si5351.h               |  114 ++
 7 files changed, 1904 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/silabs,si5351.txt
 create mode 100644 drivers/clk/clk-si5351.c
 create mode 100644 drivers/clk/clk-si5351.h
 create mode 100644 include/linux/platform_data/si5351.h

diff --git a/Documentation/devicetree/bindings/clock/silabs,si5351.txt b/Documentation/devicetree/bindings/clock/silabs,si5351.txt
new file mode 100644
index 0000000..cc37465
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/silabs,si5351.txt
@@ -0,0 +1,114 @@
+Binding for Silicon Labs Si5351a/b/c programmable i2c clock generator.
+
+Reference
+[1] Si5351A/B/C Data Sheet
+    http://www.silabs.com/Support%20Documents/TechnicalDocs/Si5351.pdf
+
+The Si5351a/b/c are programmable i2c clock generators with upto 8 output
+clocks. Si5351a also has a reduced pin-count package (MSOP10) where only
+3 output clocks are accessible. The internal structure of the clock
+generators can be found in [1].
+
+==I2C device node==
+
+Required properties:
+- compatible: shall be one of "silabs,si5351{a,a-msop,b,c}".
+- reg: i2c device address, shall be 0x60 or 0x61.
+- #clock-cells: from common clock binding; shall be set to 1.
+- clocks: from common clock binding; list of parent clock
+  handles, shall be xtal reference clock or xtal and clkin for
+  si5351c only.
+- #address-cells: shall be set to 1.
+- #size-cells: shall be set to 0.
+
+Optional properties:
+- silabs,pll-source: pair of (number, source) for each pll. Allows
+  to overwrite clock source of pll A (number=0) or B (number=1).
+
+==Child nodes==
+
+Each of the clock outputs can be overwritten individually by
+using a child node to the I2C device node. If a child node for a clock
+output is not set, the eeprom configuration is not overwritten.
+
+Required child node properties:
+- reg: number of clock output.
+
+Optional child node properties:
+- silabs,clock-source: source clock of the output divider stage N, shall be
+  0 = multisynth N
+  1 = multisynth 0 for output clocks 0-3, else multisynth4
+  2 = xtal
+  3 = clkin (si5351c only)
+- silabs,drive-strength: output drive strength in mA, shall be one of {2,4,6,8}.
+- silabs,multisynth-source: source pll A(0) or B(1) of corresponding multisynth
+  divider.
+- silabs,pll-master: boolean, multisynth can change pll frequency.
+
+==Example==
+
+/* 25MHz reference crystal */
+ref25: ref25M {
+	compatible = "fixed-clock";
+	#clock-cells = <0>;
+	clock-frequency = <25000000>;
+};
+
+i2c-master-node {
+
+	/* Si5351a msop10 i2c clock generator */
+	si5351a: clock-generator at 60 {
+		compatible = "silabs,si5351a-msop";
+		reg = <0x60>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		#clock-cells = <1>;
+
+		/* connect xtal input to 25MHz reference */
+		clocks = <&ref25>;
+
+		/* connect xtal input as source of pll0 and pll1 */
+		silabs,pll-source = <0 0>, <1 0>;
+
+		/*
+		 * overwrite clkout0 configuration with:
+		 * - 8mA output drive strength
+		 * - pll0 as clock source of multisynth0
+		 * - multisynth0 as clock source of output divider
+		 * - multisynth0 can change pll0
+		 * - set initial clock frequency of 74.25MHz
+		 */
+		clkout0 {
+			reg = <0>;
+			silabs,drive-strength = <8>;
+			silabs,multisynth-source = <0>;
+			silabs,clock-source = <0>;
+			silabs,pll-master;
+			clock-frequency = <74250000>;
+		};
+
+		/*
+		 * overwrite clkout1 configuration with:
+		 * - 4mA output drive strength
+		 * - pll1 as clock source of multisynth1
+		 * - multisynth1 as clock source of output divider
+		 * - multisynth1 can change pll1
+		 */
+		clkout1 {
+			reg = <1>;
+			silabs,drive-strength = <4>;
+			silabs,multisynth-source = <1>;
+			silabs,clock-source = <0>;
+			pll-master;
+		};
+
+		/*
+		 * overwrite clkout2 configuration with:
+		 * - xtal as clock source of output divider
+		 */
+		clkout2 {
+			reg = <2>;
+			silabs,clock-source = <2>;
+		};
+	};
+};
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 19e1ef7..ca60849 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -48,6 +48,7 @@ samsung	Samsung Semiconductor
 sbs	Smart Battery System
 schindler	Schindler
 sil	Silicon Image
+silabs	Silicon Laboratories
 simtek
 sirf	SiRF Technology, Inc.
 snps 	Synopsys, Inc.
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index a47e6ee..5039e41 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -55,6 +55,15 @@ config COMMON_CLK_MAX77686
 	---help---
 	  This driver supports Maxim 77686 crystal oscillator clock. 
 
+config COMMON_CLK_SI5351
+	tristate "Clock driver for SiLabs 5351A/B/C"
+	depends on I2C
+	select REGMAP_I2C
+	select RATIONAL
+	---help---
+	  This driver supports Silicon Labs 5351A/B/C programmable clock
+	  generators.
+
 config CLK_TWL6040
 	tristate "External McPDM functional clock from twl6040"
 	depends on TWL6040_CORE
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 300d477..92ca698 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -33,4 +33,5 @@ obj-$(CONFIG_X86)		+= x86/
 # Chip specific
 obj-$(CONFIG_COMMON_CLK_WM831X) += clk-wm831x.o
 obj-$(CONFIG_COMMON_CLK_MAX77686) += clk-max77686.o
+obj-$(CONFIG_COMMON_CLK_SI5351) += clk-si5351.o
 obj-$(CONFIG_CLK_TWL6040)	+= clk-twl6040.o
diff --git a/drivers/clk/clk-si5351.c b/drivers/clk/clk-si5351.c
new file mode 100644
index 0000000..8927284
--- /dev/null
+++ b/drivers/clk/clk-si5351.c
@@ -0,0 +1,1510 @@
+/*
+ * clk-si5351.c: Silicon Laboratories Si5351A/B/C I2C Clock Generator
+ *
+ * Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
+ * Rabeeh Khoury <rabeeh at solid-run.com>
+ *
+ * References:
+ * [1] "Si5351A/B/C Data Sheet"
+ *     http://www.silabs.com/Support%20Documents/TechnicalDocs/Si5351.pdf
+ * [2] "Manually Generating an Si5351 Register Map"
+ *     http://www.silabs.com/Support%20Documents/TechnicalDocs/AN619.pdf
+ *
+ * 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.
+ */
+
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/clkdev.h>
+#include <linux/clk-provider.h>
+#include <linux/delay.h>
+#include <linux/err.h>
+#include <linux/errno.h>
+#include <linux/rational.h>
+#include <linux/i2c.h>
+#include <linux/of_platform.h>
+#include <linux/platform_data/si5351.h>
+#include <linux/regmap.h>
+#include <linux/slab.h>
+#include <linux/string.h>
+#include <asm/div64.h>
+
+#include "clk-si5351.h"
+
+struct si5351_driver_data;
+
+struct si5351_parameters {
+	unsigned long	p1;
+	unsigned long	p2;
+	unsigned long	p3;
+	int		valid;
+};
+
+struct si5351_hw_data {
+	struct clk_hw			hw;
+	struct si5351_driver_data	*drvdata;
+	struct si5351_parameters	params;
+	unsigned char			num;
+};
+
+struct si5351_driver_data {
+	enum si5351_variant	variant;
+	struct i2c_client	*client;
+	struct regmap		*regmap;
+	struct clk_onecell_data onecell;
+
+	struct clk		*pxtal;
+	const char		*pxtal_name;
+	struct clk_hw		xtal;
+	struct clk		*pclkin;
+	const char		*pclkin_name;
+	struct clk_hw		clkin;
+
+	struct si5351_hw_data	pll[2];
+	struct si5351_hw_data	*msynth;
+	struct si5351_hw_data	*clkout;
+};
+
+static const char const *si5351_input_names[] = {
+	"xtal", "clkin"
+};
+static const char const *si5351_pll_names[] = {
+	"plla", "pllb", "vxco"
+};
+static const char const *si5351_msynth_names[] = {
+	"ms0", "ms1", "ms2", "ms3", "ms4", "ms5", "ms6", "ms7"
+};
+static const char const *si5351_clkout_names[] = {
+	"clk0", "clk1", "clk2", "clk3", "clk4", "clk5", "clk6", "clk7"
+};
+
+/*
+ * Si5351 i2c regmap
+ */
+static inline u8 si5351_reg_read(struct si5351_driver_data *drvdata, u8 reg)
+{
+	u32 val;
+	int ret;
+
+	ret = regmap_read(drvdata->regmap, reg, &val);
+	if (ret) {
+		dev_err(&drvdata->client->dev,
+			"unable to read from reg%02x\n", reg);
+		return 0;
+	}
+
+	return (u8)val;
+}
+
+static inline int si5351_bulk_read(struct si5351_driver_data *drvdata,
+				   u8 reg, u8 count, u8 *buf)
+{
+	return regmap_bulk_read(drvdata->regmap, reg, buf, count);
+}
+
+static inline int si5351_reg_write(struct si5351_driver_data *drvdata,
+				   u8 reg, u8 val)
+{
+	return regmap_write(drvdata->regmap, reg, val);
+}
+
+static inline int si5351_bulk_write(struct si5351_driver_data *drvdata,
+				    u8 reg, u8 count, const u8 *buf)
+{
+	return regmap_raw_write(drvdata->regmap, reg, buf, count);
+}
+
+static inline int si5351_set_bits(struct si5351_driver_data *drvdata,
+				  u8 reg, u8 mask, u8 val)
+{
+	return regmap_update_bits(drvdata->regmap, reg, mask, val);
+}
+
+static inline u8 si5351_msynth_params_address(int num)
+{
+	if (num > 5)
+		return SI5351_CLK6_PARAMETERS + (num - 6);
+	return SI5351_CLK0_PARAMETERS + (SI5351_PARAMETERS_LENGTH * num);
+}
+
+static void si5351_read_parameters(struct si5351_driver_data *drvdata,
+				   u8 reg, struct si5351_parameters *params)
+{
+	u8 buf[SI5351_PARAMETERS_LENGTH];
+
+	switch (reg) {
+	case SI5351_CLK6_PARAMETERS:
+	case SI5351_CLK7_PARAMETERS:
+		buf[0] = si5351_reg_read(drvdata, reg);
+		params->p1 = buf[0];
+		params->p2 = 0;
+		params->p3 = 1;
+		break;
+	default:
+		si5351_bulk_read(drvdata, reg, SI5351_PARAMETERS_LENGTH, buf);
+		params->p1 = ((buf[2] & 0x03) << 16) | (buf[3] << 8) | buf[4];
+		params->p2 = ((buf[5] & 0x0f) << 16) | (buf[6] << 8) | buf[7];
+		params->p3 = ((buf[5] & 0xf0) << 12) | (buf[0] << 8) | buf[1];
+	}
+	params->valid = 1;
+}
+
+static void si5351_write_parameters(struct si5351_driver_data *drvdata,
+				    u8 reg, struct si5351_parameters *params)
+{
+	u8 buf[SI5351_PARAMETERS_LENGTH];
+
+	switch (reg) {
+	case SI5351_CLK6_PARAMETERS:
+	case SI5351_CLK7_PARAMETERS:
+		buf[0] = params->p1 & 0xff;
+		si5351_reg_write(drvdata, reg, buf[0]);
+		break;
+	default:
+		buf[0] = ((params->p3 & 0x0ff00) >> 8) & 0xff;
+		buf[1] = params->p3 & 0xff;
+		/* save rdiv and divby4 */
+		buf[2] = si5351_reg_read(drvdata, reg + 2) & ~0x03;
+		buf[2] |= ((params->p1 & 0x30000) >> 16) & 0x03;
+		buf[3] = ((params->p1 & 0x0ff00) >> 8) & 0xff;
+		buf[4] = params->p1 & 0xff;
+		buf[5] = ((params->p3 & 0xf0000) >> 12) |
+			((params->p2 & 0xf0000) >> 16);
+		buf[6] = ((params->p2 & 0x0ff00) >> 8) & 0xff;
+		buf[7] = params->p2 & 0xff;
+		si5351_bulk_write(drvdata, reg, SI5351_PARAMETERS_LENGTH, buf);
+	}
+}
+
+static bool si5351_regmap_is_volatile(struct device *dev, unsigned int reg)
+{
+	switch (reg) {
+	case SI5351_DEVICE_STATUS:
+	case SI5351_INTERRUPT_STATUS:
+	case SI5351_PLL_RESET:
+		return true;
+	}
+	return false;
+}
+
+static bool si5351_regmap_is_writeable(struct device *dev, unsigned int reg)
+{
+	/* reserved registers */
+	if (reg >= 4 && reg <= 8)
+		return false;
+	if (reg >= 10 && reg <= 14)
+		return false;
+	if (reg >= 173 && reg <= 176)
+		return false;
+	if (reg >= 178 && reg <= 182)
+		return false;
+	/* read-only */
+	if (reg == SI5351_DEVICE_STATUS)
+		return false;
+	return true;
+}
+
+static struct regmap_config si5351_regmap_config = {
+	.reg_bits = 8,
+	.val_bits = 8,
+	.cache_type = REGCACHE_RBTREE,
+	.max_register = 187,
+	.writeable_reg = si5351_regmap_is_writeable,
+	.volatile_reg = si5351_regmap_is_volatile,
+};
+
+/*
+ * Si5351 xtal clock input
+ */
+static int si5351_xtal_prepare(struct clk_hw *hw)
+{
+	struct si5351_driver_data *drvdata =
+		container_of(hw, struct si5351_driver_data, xtal);
+	si5351_set_bits(drvdata, SI5351_FANOUT_ENABLE,
+			SI5351_XTAL_ENABLE, SI5351_XTAL_ENABLE);
+	return 0;
+}
+
+static void si5351_xtal_unprepare(struct clk_hw *hw)
+{
+	struct si5351_driver_data *drvdata =
+		container_of(hw, struct si5351_driver_data, xtal);
+	si5351_set_bits(drvdata, SI5351_FANOUT_ENABLE,
+			SI5351_XTAL_ENABLE, 0);
+}
+
+static const struct clk_ops si5351_xtal_ops = {
+	.prepare = si5351_xtal_prepare,
+	.unprepare = si5351_xtal_unprepare,
+};
+
+/*
+ * Si5351 clkin clock input (Si5351C only)
+ */
+static int si5351_clkin_prepare(struct clk_hw *hw)
+{
+	struct si5351_driver_data *drvdata =
+		container_of(hw, struct si5351_driver_data, clkin);
+	si5351_set_bits(drvdata, SI5351_FANOUT_ENABLE,
+			SI5351_CLKIN_ENABLE, SI5351_CLKIN_ENABLE);
+	return 0;
+}
+
+static void si5351_clkin_unprepare(struct clk_hw *hw)
+{
+	struct si5351_driver_data *drvdata =
+		container_of(hw, struct si5351_driver_data, clkin);
+	si5351_set_bits(drvdata, SI5351_FANOUT_ENABLE,
+			SI5351_CLKIN_ENABLE, 0);
+}
+
+/*
+ * CMOS clock source constraints:
+ * The input frequency range of the PLL is 10Mhz to 40MHz.
+ * If CLKIN is >40MHz, the input divider must be used.
+ */
+static unsigned long si5351_clkin_recalc_rate(struct clk_hw *hw,
+					      unsigned long parent_rate)
+{
+	struct si5351_driver_data *drvdata =
+		container_of(hw, struct si5351_driver_data, clkin);
+	unsigned long rate;
+	unsigned char idiv;
+
+	rate = parent_rate;
+	if (parent_rate > 160000000) {
+		idiv = SI5351_CLKIN_DIV_8;
+		rate /= 8;
+	} else if (parent_rate > 80000000) {
+		idiv = SI5351_CLKIN_DIV_4;
+		rate /= 4;
+	} else if (parent_rate > 40000000) {
+		idiv = SI5351_CLKIN_DIV_2;
+		rate /= 2;
+	} else {
+		idiv = SI5351_CLKIN_DIV_1;
+	}
+
+	si5351_set_bits(drvdata, SI5351_PLL_INPUT_SOURCE,
+			SI5351_CLKIN_DIV_MASK, idiv);
+
+	dev_dbg(&drvdata->client->dev, "%s - clkin div = %d, rate = %lu\n",
+		__func__, (1 << (idiv >> 6)), rate);
+
+	return rate;
+}
+
+static const struct clk_ops si5351_clkin_ops = {
+	.prepare = si5351_clkin_prepare,
+	.unprepare = si5351_clkin_unprepare,
+	.recalc_rate = si5351_clkin_recalc_rate,
+};
+
+/*
+ * Si5351 vxco clock input (Si5351B only)
+ */
+
+static int si5351_vxco_prepare(struct clk_hw *hw)
+{
+	struct si5351_hw_data *hwdata =
+		container_of(hw, struct si5351_hw_data, hw);
+
+	dev_warn(&hwdata->drvdata->client->dev, "VXCO currently unsupported\n");
+
+	return 0;
+}
+
+static void si5351_vxco_unprepare(struct clk_hw *hw)
+{
+}
+
+static unsigned long si5351_vxco_recalc_rate(struct clk_hw *hw,
+					     unsigned long parent_rate)
+{
+	return 0;
+}
+
+static int si5351_vxco_set_rate(struct clk_hw *hw, unsigned long rate,
+				unsigned long parent)
+{
+	return 0;
+}
+
+static const struct clk_ops si5351_vxco_ops = {
+	.prepare = si5351_vxco_prepare,
+	.unprepare = si5351_vxco_unprepare,
+	.recalc_rate = si5351_vxco_recalc_rate,
+	.set_rate = si5351_vxco_set_rate,
+};
+
+/*
+ * Si5351 pll a/b
+ *
+ * Feedback Multisynth Divider Equations [2]
+ *
+ * fVCO = fIN * (a + b/c)
+ *
+ * with 15 + 0/1048575 <= (a + b/c) <= 90 + 0/1048575 and
+ * fIN = fXTAL or fIN = fCLKIN/CLKIN_DIV
+ *
+ * Feedback Multisynth Register Equations
+ *
+ * (1) MSNx_P1[17:0] = 128 * a + floor(128 * b/c) - 512
+ * (2) MSNx_P2[19:0] = 128 * b - c * floor(128 * b/c) = (128*b) mod c
+ * (3) MSNx_P3[19:0] = c
+ *
+ * Transposing (2) yields: (4) floor(128 * b/c) = (128 * b / MSNx_P2)/c
+ *
+ * Using (4) on (1) yields:
+ * MSNx_P1 = 128 * a + (128 * b/MSNx_P2)/c - 512
+ * MSNx_P1 + 512 + MSNx_P2/c = 128 * a + 128 * b/c
+ *
+ * a + b/c = (MSNx_P1 + MSNx_P2/MSNx_P3 + 512)/128
+ *         = (MSNx_P1*MSNx_P3 + MSNx_P2 + 512*MSNx_P3)/(128*MSNx_P3)
+ *
+ */
+static int _si5351_pll_reparent(struct si5351_driver_data *drvdata,
+				int num, enum si5351_pll_src parent)
+{
+	u8 mask = (num == 0) ? SI5351_PLLA_SOURCE : SI5351_PLLB_SOURCE;
+
+	if (parent == SI5351_PLL_SRC_DEFAULT)
+		return 0;
+
+	if (num > 2)
+		return -EINVAL;
+
+	if (drvdata->variant != SI5351_VARIANT_C &&
+	    parent != SI5351_PLL_SRC_XTAL)
+		return -EINVAL;
+
+	si5351_set_bits(drvdata, SI5351_PLL_INPUT_SOURCE, mask,
+			(parent == SI5351_PLL_SRC_XTAL) ? 0 : mask);
+	return 0;
+}
+
+static unsigned char si5351_pll_get_parent(struct clk_hw *hw)
+{
+	struct si5351_hw_data *hwdata =
+		container_of(hw, struct si5351_hw_data, hw);
+	u8 mask = (hwdata->num == 0) ? SI5351_PLLA_SOURCE : SI5351_PLLB_SOURCE;
+	u8 val;
+
+	val = si5351_reg_read(hwdata->drvdata, SI5351_PLL_INPUT_SOURCE);
+
+	return (val & mask) ? 1 : 0;
+}
+
+static int si5351_pll_set_parent(struct clk_hw *hw, u8 index)
+{
+	struct si5351_hw_data *hwdata =
+		container_of(hw, struct si5351_hw_data, hw);
+
+	if (hwdata->drvdata->variant != SI5351_VARIANT_C &&
+	    index > 0)
+		return -EPERM;
+
+	if (index > 1)
+		return -EINVAL;
+
+	return _si5351_pll_reparent(hwdata->drvdata, hwdata->num,
+			     (index == 0) ? SI5351_PLL_SRC_XTAL :
+			     SI5351_PLL_SRC_CLKIN);
+}
+
+static unsigned long si5351_pll_recalc_rate(struct clk_hw *hw,
+					    unsigned long parent_rate)
+{
+	struct si5351_hw_data *hwdata =
+		container_of(hw, struct si5351_hw_data, hw);
+	u8 reg = (hwdata->num == 0) ? SI5351_PLLA_PARAMETERS :
+		SI5351_PLLB_PARAMETERS;
+	unsigned long long rate;
+
+	if (!hwdata->params.valid)
+		si5351_read_parameters(hwdata->drvdata, reg, &hwdata->params);
+
+	if (hwdata->params.p3 == 0)
+		return parent_rate;
+
+	/* fVCO = fIN * (P1*P3 + 512*P3 + P2)/(128*P3) */
+	rate  = hwdata->params.p1 * hwdata->params.p3;
+	rate += 512 * hwdata->params.p3;
+	rate += hwdata->params.p2;
+	rate *= parent_rate;
+	do_div(rate, 128 * hwdata->params.p3);
+
+	dev_dbg(&hwdata->drvdata->client->dev,
+		"%s - %s: p1 = %lu, p2 = %lu, p3 = %lu, parent_rate = %lu, rate = %lu\n",
+		__func__, __clk_get_name(hwdata->hw.clk),
+		hwdata->params.p1, hwdata->params.p2, hwdata->params.p3,
+		parent_rate, (unsigned long)rate);
+
+	return (unsigned long)rate;
+}
+
+static long si5351_pll_round_rate(struct clk_hw *hw, unsigned long rate,
+				  unsigned long *parent_rate)
+{
+	struct si5351_hw_data *hwdata =
+		container_of(hw, struct si5351_hw_data, hw);
+	unsigned long rfrac, denom, a, b, c;
+	unsigned long long lltmp;
+
+	if (rate < SI5351_PLL_VCO_MIN)
+		rate = SI5351_PLL_VCO_MIN;
+	if (rate > SI5351_PLL_VCO_MAX)
+		rate = SI5351_PLL_VCO_MAX;
+
+	/* determine integer part of feedback equation */
+	a = rate / *parent_rate;
+
+	if (a < SI5351_PLL_A_MIN)
+		rate = *parent_rate * SI5351_PLL_A_MIN;
+	if (a > SI5351_PLL_A_MAX)
+		rate = *parent_rate * SI5351_PLL_A_MAX;
+
+	/* find best approximation for b/c = fVCO mod fIN */
+	denom = 1000 * 1000;
+	lltmp = rate % (*parent_rate);
+	lltmp *= denom;
+	do_div(lltmp, *parent_rate);
+	rfrac = (unsigned long)lltmp;
+
+	b = 0;
+	c = 1;
+	if (rfrac)
+		rational_best_approximation(rfrac, denom,
+				    SI5351_PLL_B_MAX, SI5351_PLL_C_MAX, &b, &c);
+
+	/* calculate parameters */
+	hwdata->params.p3  = c;
+	hwdata->params.p2  = (128 * b) % c;
+	hwdata->params.p1  = 128 * a;
+	hwdata->params.p1 += (128 * b / c);
+	hwdata->params.p1 -= 512;
+
+	/* recalculate rate by fIN * (a + b/c) */
+	lltmp  = *parent_rate;
+	lltmp *= b;
+	do_div(lltmp, c);
+
+	rate  = (unsigned long)lltmp;
+	rate += *parent_rate * a;
+
+	dev_dbg(&hwdata->drvdata->client->dev,
+		"%s - %s: a = %lu, b = %lu, c = %lu, parent_rate = %lu, rate = %lu\n",
+		__func__, __clk_get_name(hwdata->hw.clk), a, b, c,
+		*parent_rate, rate);
+
+	return rate;
+}
+
+static int si5351_pll_set_rate(struct clk_hw *hw, unsigned long rate,
+			       unsigned long parent_rate)
+{
+	struct si5351_hw_data *hwdata =
+		container_of(hw, struct si5351_hw_data, hw);
+	u8 reg = (hwdata->num == 0) ? SI5351_PLLA_PARAMETERS :
+		SI5351_PLLB_PARAMETERS;
+
+	/* write multisynth parameters */
+	si5351_write_parameters(hwdata->drvdata, reg, &hwdata->params);
+
+	/* plla/pllb ctrl is in clk6/clk7 ctrl registers */
+	si5351_set_bits(hwdata->drvdata, SI5351_CLK6_CTRL + hwdata->num,
+		SI5351_CLK_INTEGER_MODE,
+		(hwdata->params.p2 == 0) ? SI5351_CLK_INTEGER_MODE : 0);
+
+	dev_dbg(&hwdata->drvdata->client->dev,
+		"%s - %s: p1 = %lu, p2 = %lu, p3 = %lu, parent_rate = %lu, rate = %lu\n",
+		__func__, __clk_get_name(hwdata->hw.clk),
+		hwdata->params.p1, hwdata->params.p2, hwdata->params.p3,
+		parent_rate, rate);
+
+	return 0;
+}
+
+static const struct clk_ops si5351_pll_ops = {
+	.set_parent = si5351_pll_set_parent,
+	.get_parent = si5351_pll_get_parent,
+	.recalc_rate = si5351_pll_recalc_rate,
+	.round_rate = si5351_pll_round_rate,
+	.set_rate = si5351_pll_set_rate,
+};
+
+/*
+ * Si5351 multisync divider
+ *
+ * for fOUT <= 150 MHz:
+ *
+ * fOUT = (fIN * (a + b/c)) / CLKOUTDIV
+ *
+ * with 6 + 0/1048575 <= (a + b/c) <= 1800 + 0/1048575 and
+ * fIN = fVCO0, fVCO1
+ *
+ * Output Clock Multisynth Register Equations
+ *
+ * MSx_P1[17:0] = 128 * a + floor(128 * b/c) - 512
+ * MSx_P2[19:0] = 128 * b - c * floor(128 * b/c) = (128*b) mod c
+ * MSx_P3[19:0] = c
+ *
+ * MS[6,7] are integer (P1) divide only, P2 = 0, P3 = 0
+ *
+ * for 150MHz < fOUT <= 160MHz:
+ *
+ * MSx_P1 = 0, MSx_P2 = 0, MSx_P3 = 1, MSx_INT = 1, MSx_DIVBY4 = 11b
+ */
+static int _si5351_msynth_reparent(struct si5351_driver_data *drvdata,
+				   int num, enum si5351_multisynth_src parent)
+{
+	if (parent == SI5351_MULTISYNTH_SRC_DEFAULT)
+		return 0;
+
+	if (num > 8)
+		return -EINVAL;
+
+	si5351_set_bits(drvdata, SI5351_CLK0_CTRL + num, SI5351_CLK_PLL_SELECT,
+			(parent == SI5351_MULTISYNTH_SRC_VCO0) ? 0 :
+			SI5351_CLK_PLL_SELECT);
+	return 0;
+}
+
+static unsigned char si5351_msynth_get_parent(struct clk_hw *hw)
+{
+	struct si5351_hw_data *hwdata =
+		container_of(hw, struct si5351_hw_data, hw);
+	u8 val;
+
+	val = si5351_reg_read(hwdata->drvdata, SI5351_CLK0_CTRL + hwdata->num);
+
+	return (val & SI5351_CLK_PLL_SELECT) ? 1 : 0;
+}
+
+static int si5351_msynth_set_parent(struct clk_hw *hw, u8 index)
+{
+	struct si5351_hw_data *hwdata =
+		container_of(hw, struct si5351_hw_data, hw);
+
+	return _si5351_msynth_reparent(hwdata->drvdata, hwdata->num,
+			       (index == 0) ? SI5351_MULTISYNTH_SRC_VCO0 :
+			       SI5351_MULTISYNTH_SRC_VCO1);
+}
+
+static unsigned long si5351_msynth_recalc_rate(struct clk_hw *hw,
+					       unsigned long parent_rate)
+{
+	struct si5351_hw_data *hwdata =
+		container_of(hw, struct si5351_hw_data, hw);
+	u8 reg = si5351_msynth_params_address(hwdata->num);
+	unsigned long long rate;
+	unsigned long m;
+
+	if (!hwdata->params.valid)
+		si5351_read_parameters(hwdata->drvdata, reg, &hwdata->params);
+
+	if (hwdata->params.p3 == 0)
+		return parent_rate;
+
+	/*
+	 * multisync0-5: fOUT = (128 * P3 * fIN) / (P1*P3 + P2 + 512*P3)
+	 * multisync6-7: fOUT = fIN / P1
+	 */
+	rate = parent_rate;
+	if (hwdata->num > 5) {
+		m = hwdata->params.p1;
+	} else if ((si5351_reg_read(hwdata->drvdata, reg + 2) &
+		    SI5351_OUTPUT_CLK_DIVBY4) == SI5351_OUTPUT_CLK_DIVBY4) {
+		m = 4;
+	} else {
+		rate *= 128 * hwdata->params.p3;
+		m = hwdata->params.p1 * hwdata->params.p3;
+		m += hwdata->params.p2;
+		m += 512 * hwdata->params.p3;
+	}
+
+	if (m == 0)
+		return 0;
+	do_div(rate, m);
+
+	dev_dbg(&hwdata->drvdata->client->dev,
+		"%s - %s: p1 = %lu, p2 = %lu, p3 = %lu, m = %lu, parent_rate = %lu, rate = %lu\n",
+		__func__, __clk_get_name(hwdata->hw.clk),
+		hwdata->params.p1, hwdata->params.p2, hwdata->params.p3,
+		m, parent_rate, (unsigned long)rate);
+
+	return (unsigned long)rate;
+}
+
+static long si5351_msynth_round_rate(struct clk_hw *hw, unsigned long rate,
+				     unsigned long *parent_rate)
+{
+	struct si5351_hw_data *hwdata =
+		container_of(hw, struct si5351_hw_data, hw);
+	unsigned long long lltmp;
+	unsigned long a, b, c;
+	int divby4;
+
+	/* multisync6-7 can only handle freqencies < 150MHz */
+	if (hwdata->num >= 6 && rate > SI5351_MULTISYNTH67_MAX_FREQ)
+		rate = SI5351_MULTISYNTH67_MAX_FREQ;
+
+	/* multisync frequency is 1MHz .. 160MHz */
+	if (rate > SI5351_MULTISYNTH_MAX_FREQ)
+		rate = SI5351_MULTISYNTH_MAX_FREQ;
+	if (rate < SI5351_MULTISYNTH_MIN_FREQ)
+		rate = SI5351_MULTISYNTH_MIN_FREQ;
+
+	divby4 = 0;
+	if (rate > SI5351_MULTISYNTH_DIVBY4_FREQ)
+		divby4 = 1;
+
+	/* multisync can set pll */
+	if (__clk_get_flags(hwdata->hw.clk) & CLK_SET_RATE_PARENT) {
+		/*
+		 * find largest integer divider for max
+		 * vco frequency and given target rate
+		 */
+		if (divby4 == 0) {
+			lltmp = SI5351_PLL_VCO_MAX;
+			do_div(lltmp, rate);
+			a = (unsigned long)lltmp;
+		} else
+			a = 4;
+
+		b = 0;
+		c = 1;
+
+		*parent_rate = a * rate;
+	} else {
+		unsigned long rfrac, denom;
+
+		/* disable divby4 */
+		if (divby4) {
+			rate = SI5351_MULTISYNTH_DIVBY4_FREQ;
+			divby4 = 0;
+		}
+
+		/* determine integer part of divider equation */
+		a = *parent_rate / rate;
+		if (a < SI5351_MULTISYNTH_A_MIN)
+			a = SI5351_MULTISYNTH_A_MIN;
+		if (hwdata->num >= 6 && a > SI5351_MULTISYNTH67_A_MAX)
+			a = SI5351_MULTISYNTH67_A_MAX;
+		else if (a > SI5351_MULTISYNTH_A_MAX)
+			a = SI5351_MULTISYNTH_A_MAX;
+
+		/* find best approximation for b/c = fVCO mod fOUT */
+		denom = 1000 * 1000;
+		lltmp = (*parent_rate) % rate;
+		lltmp *= denom;
+		do_div(lltmp, rate);
+		rfrac = (unsigned long)lltmp;
+
+		b = 0;
+		c = 1;
+		if (rfrac)
+			rational_best_approximation(rfrac, denom,
+			    SI5351_MULTISYNTH_B_MAX, SI5351_MULTISYNTH_C_MAX,
+			    &b, &c);
+	}
+
+	/* recalculate rate by fOUT = fIN / (a + b/c) */
+	lltmp  = *parent_rate;
+	lltmp *= c;
+	do_div(lltmp, a * c + b);
+	rate  = (unsigned long)lltmp;
+
+	/* calculate parameters */
+	if (divby4) {
+		hwdata->params.p3 = 1;
+		hwdata->params.p2 = 0;
+		hwdata->params.p1 = 0;
+	} else {
+		hwdata->params.p3  = c;
+		hwdata->params.p2  = (128 * b) % c;
+		hwdata->params.p1  = 128 * a;
+		hwdata->params.p1 += (128 * b / c);
+		hwdata->params.p1 -= 512;
+	}
+
+	dev_dbg(&hwdata->drvdata->client->dev,
+		"%s - %s: a = %lu, b = %lu, c = %lu, divby4 = %d, parent_rate = %lu, rate = %lu\n",
+		__func__, __clk_get_name(hwdata->hw.clk), a, b, c, divby4,
+		*parent_rate, rate);
+
+	return rate;
+}
+
+static int si5351_msynth_set_rate(struct clk_hw *hw, unsigned long rate,
+				  unsigned long parent_rate)
+{
+	struct si5351_hw_data *hwdata =
+		container_of(hw, struct si5351_hw_data, hw);
+	u8 reg = si5351_msynth_params_address(hwdata->num);
+	int divby4 = 0;
+
+	/* write multisynth parameters */
+	si5351_write_parameters(hwdata->drvdata, reg, &hwdata->params);
+
+	if (rate > SI5351_MULTISYNTH_DIVBY4_FREQ)
+		divby4 = 1;
+
+	/* enable/disable integer mode and divby4 on multisynth0-5 */
+	if (hwdata->num < 6) {
+		si5351_set_bits(hwdata->drvdata, reg + 2,
+				SI5351_OUTPUT_CLK_DIVBY4,
+				(divby4) ? SI5351_OUTPUT_CLK_DIVBY4 : 0);
+		si5351_set_bits(hwdata->drvdata, SI5351_CLK0_CTRL + hwdata->num,
+			SI5351_CLK_INTEGER_MODE,
+			(hwdata->params.p2 == 0) ? SI5351_CLK_INTEGER_MODE : 0);
+	}
+
+	dev_dbg(&hwdata->drvdata->client->dev,
+		"%s - %s: p1 = %lu, p2 = %lu, p3 = %lu, divby4 = %d, parent_rate = %lu, rate = %lu\n",
+		__func__, __clk_get_name(hwdata->hw.clk),
+		hwdata->params.p1, hwdata->params.p2, hwdata->params.p3,
+		divby4, parent_rate, rate);
+
+	return 0;
+}
+
+static const struct clk_ops si5351_msynth_ops = {
+	.set_parent = si5351_msynth_set_parent,
+	.get_parent = si5351_msynth_get_parent,
+	.recalc_rate = si5351_msynth_recalc_rate,
+	.round_rate = si5351_msynth_round_rate,
+	.set_rate = si5351_msynth_set_rate,
+};
+
+/*
+ * Si5351 clkout divider
+ */
+static int _si5351_clkout_reparent(struct si5351_driver_data *drvdata,
+				   int num, enum si5351_clkout_src parent)
+{
+	u8 val;
+
+	if (num > 8)
+		return -EINVAL;
+
+	switch (parent) {
+	case SI5351_CLKOUT_SRC_MSYNTH_N:
+		val = SI5351_CLK_INPUT_MULTISYNTH_N;
+		break;
+	case SI5351_CLKOUT_SRC_MSYNTH_0_4:
+		/* clk0/clk4 can only connect to its own multisync */
+		if (num == 0 || num == 4)
+			val = SI5351_CLK_INPUT_MULTISYNTH_N;
+		else
+			val = SI5351_CLK_INPUT_MULTISYNTH_0_4;
+		break;
+	case SI5351_CLKOUT_SRC_XTAL:
+		val = SI5351_CLK_INPUT_XTAL;
+		break;
+	case SI5351_CLKOUT_SRC_CLKIN:
+		if (drvdata->variant != SI5351_VARIANT_C)
+			return -EINVAL;
+
+		val = SI5351_CLK_INPUT_CLKIN;
+		break;
+	default:
+		return 0;
+	}
+
+	si5351_set_bits(drvdata, SI5351_CLK0_CTRL + num,
+			SI5351_CLK_INPUT_MASK, val);
+	return 0;
+}
+
+static int _si5351_clkout_set_drive_strength(
+	struct si5351_driver_data *drvdata, int num,
+	enum si5351_drive_strength drive)
+{
+	u8 mask;
+
+	if (num > 8)
+		return -EINVAL;
+
+	switch (drive) {
+	case SI5351_DRIVE_2MA:
+		mask = SI5351_CLK_DRIVE_STRENGTH_2MA;
+		break;
+	case SI5351_DRIVE_4MA:
+		mask = SI5351_CLK_DRIVE_STRENGTH_4MA;
+		break;
+	case SI5351_DRIVE_6MA:
+		mask = SI5351_CLK_DRIVE_STRENGTH_6MA;
+		break;
+	case SI5351_DRIVE_8MA:
+		mask = SI5351_CLK_DRIVE_STRENGTH_8MA;
+		break;
+	default:
+		return 0;
+	}
+
+	si5351_set_bits(drvdata, SI5351_CLK0_CTRL + num,
+			SI5351_CLK_DRIVE_STRENGTH_MASK, mask);
+	return 0;
+}
+
+static int si5351_clkout_prepare(struct clk_hw *hw)
+{
+	struct si5351_hw_data *hwdata =
+		container_of(hw, struct si5351_hw_data, hw);
+
+	si5351_set_bits(hwdata->drvdata, SI5351_CLK0_CTRL + hwdata->num,
+			SI5351_CLK_POWERDOWN, 0);
+	si5351_set_bits(hwdata->drvdata, SI5351_OUTPUT_ENABLE_CTRL,
+			(1 << hwdata->num), 0);
+	return 0;
+}
+
+static void si5351_clkout_unprepare(struct clk_hw *hw)
+{
+	struct si5351_hw_data *hwdata =
+		container_of(hw, struct si5351_hw_data, hw);
+
+	si5351_set_bits(hwdata->drvdata, SI5351_CLK0_CTRL + hwdata->num,
+			SI5351_CLK_POWERDOWN, SI5351_CLK_POWERDOWN);
+	si5351_set_bits(hwdata->drvdata, SI5351_OUTPUT_ENABLE_CTRL,
+			(1 << hwdata->num), (1 << hwdata->num));
+}
+
+static u8 si5351_clkout_get_parent(struct clk_hw *hw)
+{
+	struct si5351_hw_data *hwdata =
+		container_of(hw, struct si5351_hw_data, hw);
+	int index = 0;
+	unsigned char val;
+
+	val = si5351_reg_read(hwdata->drvdata, SI5351_CLK0_CTRL + hwdata->num);
+	switch (val & SI5351_CLK_INPUT_MASK) {
+	case SI5351_CLK_INPUT_MULTISYNTH_N:
+		index = 0;
+		break;
+	case SI5351_CLK_INPUT_MULTISYNTH_0_4:
+		index = 1;
+		break;
+	case SI5351_CLK_INPUT_XTAL:
+		index = 2;
+		break;
+	case SI5351_CLK_INPUT_CLKIN:
+		index = 3;
+		break;
+	}
+
+	return index;
+}
+
+static int si5351_clkout_set_parent(struct clk_hw *hw, u8 index)
+{
+	struct si5351_hw_data *hwdata =
+		container_of(hw, struct si5351_hw_data, hw);
+	enum si5351_clkout_src parent = SI5351_CLKOUT_SRC_DEFAULT;
+
+	switch (index) {
+	case 0:
+		parent = SI5351_CLKOUT_SRC_MSYNTH_N;
+		break;
+	case 1:
+		parent = SI5351_CLKOUT_SRC_MSYNTH_0_4;
+		break;
+	case 2:
+		parent = SI5351_CLKOUT_SRC_XTAL;
+		break;
+	case 3:
+		parent = SI5351_CLKOUT_SRC_CLKIN;
+		break;
+	}
+
+	return _si5351_clkout_reparent(hwdata->drvdata, hwdata->num, parent);
+}
+
+static unsigned long si5351_clkout_recalc_rate(struct clk_hw *hw,
+					       unsigned long parent_rate)
+{
+	struct si5351_hw_data *hwdata =
+		container_of(hw, struct si5351_hw_data, hw);
+	unsigned char reg;
+	unsigned char rdiv;
+
+	if (hwdata->num > 5)
+		reg = si5351_msynth_params_address(hwdata->num) + 2;
+	else
+		reg = SI5351_CLK6_7_OUTPUT_DIVIDER;
+
+	rdiv = si5351_reg_read(hwdata->drvdata, reg);
+	if (hwdata->num == 6) {
+		rdiv &= SI5351_OUTPUT_CLK6_DIV_MASK;
+	} else {
+		rdiv &= SI5351_OUTPUT_CLK_DIV_MASK;
+		rdiv >>= SI5351_OUTPUT_CLK_DIV_SHIFT;
+	}
+
+	return parent_rate >> rdiv;
+}
+
+static long si5351_clkout_round_rate(struct clk_hw *hw, unsigned long rate,
+				     unsigned long *parent_rate)
+{
+	struct si5351_hw_data *hwdata =
+		container_of(hw, struct si5351_hw_data, hw);
+	unsigned char rdiv;
+
+	/* clkout6/7 can only handle output freqencies < 150MHz */
+	if (hwdata->num >= 6 && rate > SI5351_CLKOUT67_MAX_FREQ)
+		rate = SI5351_CLKOUT67_MAX_FREQ;
+
+	/* clkout freqency is 8kHz - 160MHz */
+	if (rate > SI5351_CLKOUT_MAX_FREQ)
+		rate = SI5351_CLKOUT_MAX_FREQ;
+	if (rate < SI5351_CLKOUT_MIN_FREQ)
+		rate = SI5351_CLKOUT_MIN_FREQ;
+
+	/* request frequency if multisync master */
+	if (__clk_get_flags(hwdata->hw.clk) & CLK_SET_RATE_PARENT) {
+		/* use r divider for frequencies below 1MHz */
+		rdiv = SI5351_OUTPUT_CLK_DIV_1;
+		while (rate < SI5351_MULTISYNTH_MIN_FREQ &&
+		       rdiv < SI5351_OUTPUT_CLK_DIV_128) {
+			rdiv += 1;
+			rate *= 2;
+		}
+		*parent_rate = rate;
+	} else {
+		unsigned long new_rate, new_err, err;
+
+		/* round to closed rdiv */
+		rdiv = SI5351_OUTPUT_CLK_DIV_1;
+		new_rate = *parent_rate;
+		err = abs(new_rate - rate);
+		do {
+			new_rate >>= 1;
+			new_err = abs(new_rate - rate);
+			if (new_err > err || rdiv == SI5351_OUTPUT_CLK_DIV_128)
+				break;
+			rdiv++;
+			err = new_err;
+		} while (1);
+	}
+	rate = *parent_rate >> rdiv;
+
+	dev_dbg(&hwdata->drvdata->client->dev,
+		"%s - %s: rdiv = %u, parent_rate = %lu, rate = %lu\n",
+		__func__, __clk_get_name(hwdata->hw.clk), (1 << rdiv),
+		*parent_rate, rate);
+
+	return rate;
+}
+
+static int si5351_clkout_set_rate(struct clk_hw *hw, unsigned long rate,
+				  unsigned long parent_rate)
+{
+	struct si5351_hw_data *hwdata =
+		container_of(hw, struct si5351_hw_data, hw);
+	unsigned long new_rate, new_err, err;
+	unsigned char rdiv;
+
+	/* round to closed rdiv */
+	rdiv = SI5351_OUTPUT_CLK_DIV_1;
+	new_rate = parent_rate;
+	err = abs(new_rate - rate);
+	do {
+		new_rate >>= 1;
+		new_err = abs(new_rate - rate);
+		if (new_err > err || rdiv == SI5351_OUTPUT_CLK_DIV_128)
+			break;
+		rdiv++;
+		err = new_err;
+	} while (1);
+
+	/* write output divider */
+	switch (hwdata->num) {
+	case 6:
+		si5351_set_bits(hwdata->drvdata, SI5351_CLK6_7_OUTPUT_DIVIDER,
+				SI5351_OUTPUT_CLK6_DIV_MASK, rdiv);
+		break;
+	case 7:
+		si5351_set_bits(hwdata->drvdata, SI5351_CLK6_7_OUTPUT_DIVIDER,
+				SI5351_OUTPUT_CLK_DIV_MASK,
+				rdiv << SI5351_OUTPUT_CLK_DIV_SHIFT);
+		break;
+	default:
+		si5351_set_bits(hwdata->drvdata,
+				si5351_msynth_params_address(hwdata->num) + 2,
+				SI5351_OUTPUT_CLK_DIV_MASK,
+				rdiv << SI5351_OUTPUT_CLK_DIV_SHIFT);
+	}
+
+	/* powerup clkout */
+	si5351_set_bits(hwdata->drvdata, SI5351_CLK0_CTRL + hwdata->num,
+			SI5351_CLK_POWERDOWN, 0);
+
+	dev_dbg(&hwdata->drvdata->client->dev,
+		"%s - %s: rdiv = %u, parent_rate = %lu, rate = %lu\n",
+		__func__, __clk_get_name(hwdata->hw.clk), (1 << rdiv),
+		parent_rate, rate);
+
+	return 0;
+}
+
+static const struct clk_ops si5351_clkout_ops = {
+	.prepare = si5351_clkout_prepare,
+	.unprepare = si5351_clkout_unprepare,
+	.set_parent = si5351_clkout_set_parent,
+	.get_parent = si5351_clkout_get_parent,
+	.recalc_rate = si5351_clkout_recalc_rate,
+	.round_rate = si5351_clkout_round_rate,
+	.set_rate = si5351_clkout_set_rate,
+};
+
+/*
+ * Si5351 i2c probe and DT
+ */
+#ifdef CONFIG_OF
+static const struct of_device_id si5351_dt_ids[] = {
+	{ .compatible = "silabs,si5351a", .data = (void *)SI5351_VARIANT_A, },
+	{ .compatible = "silabs,si5351a-msop",
+					 .data = (void *)SI5351_VARIANT_A3, },
+	{ .compatible = "silabs,si5351b", .data = (void *)SI5351_VARIANT_B, },
+	{ .compatible = "silabs,si5351c", .data = (void *)SI5351_VARIANT_C, },
+	{ }
+};
+MODULE_DEVICE_TABLE(of, si5351_dt_ids);
+
+static int si5351_dt_parse(struct i2c_client *client)
+{
+	struct device_node *child, *np = client->dev.of_node;
+	struct si5351_platform_data *pdata;
+	const struct of_device_id *match;
+	struct property *prop;
+	const __be32 *p;
+	int num = 0;
+	u32 val;
+
+	if (np == NULL)
+		return 0;
+
+	match = of_match_node(si5351_dt_ids, np);
+	if (match == NULL)
+		return -EINVAL;
+
+	pdata = devm_kzalloc(&client->dev, sizeof(*pdata), GFP_KERNEL);
+	if (!pdata)
+		return -ENOMEM;
+
+	pdata->variant = (enum si5351_variant)match->data;
+	pdata->clk_xtal = of_clk_get(np, 0);
+	if (!IS_ERR(pdata->clk_xtal))
+		clk_put(pdata->clk_xtal);
+	pdata->clk_clkin = of_clk_get(np, 1);
+	if (!IS_ERR(pdata->clk_clkin))
+		clk_put(pdata->clk_clkin);
+
+	/*
+	 * property silabs,pll-source : <num src>, [<..>]
+	 * allow to selectively set pll source
+	 */
+	of_property_for_each_u32(np, "silabs,pll-source", prop, p, num) {
+		if (num >= 2) {
+			dev_err(&client->dev,
+				"invalid pll %d on pll-source prop\n", num);
+			return -EINVAL;
+		}
+
+		p = of_prop_next_u32(prop, p, &val);
+		if (!p) {
+			dev_err(&client->dev,
+				"missing pll-source for pll %d\n", num);
+			return -EINVAL;
+		}
+
+		switch (val) {
+		case 0:
+			pdata->pll_src[num] = SI5351_PLL_SRC_XTAL;
+			break;
+		case 1:
+			if (pdata->variant != SI5351_VARIANT_C) {
+				dev_err(&client->dev,
+					"invalid parent %d for pll %d\n",
+					val, num);
+				return -EINVAL;
+			}
+			pdata->pll_src[num] = SI5351_PLL_SRC_CLKIN;
+			break;
+		default:
+			dev_err(&client->dev,
+				 "invalid parent %d for pll %d\n", val, num);
+			return -EINVAL;
+		}
+	}
+
+	/* per clkout properties */
+	for_each_child_of_node(np, child) {
+		if (of_property_read_u32(child, "reg", &num)) {
+			dev_err(&client->dev, "missing reg property of %s\n",
+				child->name);
+			return -EINVAL;
+		}
+
+		if (num >= 8 ||
+		    (pdata->variant == SI5351_VARIANT_A3 && num >= 3)) {
+			dev_err(&client->dev, "invalid clkout %d\n", num);
+			return -EINVAL;
+		}
+
+		if (!of_property_read_u32(child, "silabs,multisynth-source",
+					  &val)) {
+			switch (val) {
+			case 0:
+				pdata->clkout[num].multisynth_src =
+					SI5351_MULTISYNTH_SRC_VCO0;
+				break;
+			case 1:
+				pdata->clkout[num].multisynth_src =
+					SI5351_MULTISYNTH_SRC_VCO1;
+				break;
+			default:
+				dev_err(&client->dev,
+					"invalid parent %d for multisynth %d\n",
+					val, num);
+				return -EINVAL;
+			}
+		}
+
+		if (!of_property_read_u32(child, "silabs,clock-source", &val)) {
+			switch (val) {
+			case 0:
+				pdata->clkout[num].clkout_src =
+					SI5351_CLKOUT_SRC_MSYNTH_N;
+				break;
+			case 1:
+				pdata->clkout[num].clkout_src =
+					SI5351_CLKOUT_SRC_MSYNTH_0_4;
+				break;
+			case 2:
+				pdata->clkout[num].clkout_src =
+					SI5351_CLKOUT_SRC_XTAL;
+				break;
+			case 3:
+				if (pdata->variant != SI5351_VARIANT_C) {
+					dev_err(&client->dev,
+						"invalid parent %d for clkout %d\n",
+						val, num);
+					return -EINVAL;
+				}
+				pdata->clkout[num].clkout_src =
+					SI5351_CLKOUT_SRC_CLKIN;
+				break;
+			default:
+				dev_err(&client->dev,
+					"invalid parent %d for clkout %d\n",
+					val, num);
+				return -EINVAL;
+			}
+		}
+
+		if (!of_property_read_u32(child, "silabs,drive-strength",
+					  &val)) {
+			switch (val) {
+			case SI5351_DRIVE_2MA:
+			case SI5351_DRIVE_4MA:
+			case SI5351_DRIVE_6MA:
+			case SI5351_DRIVE_8MA:
+				pdata->clkout[num].drive = val;
+				break;
+			default:
+				dev_err(&client->dev,
+					"invalid drive strength %d for clkout %d\n",
+					val, num);
+				return -EINVAL;
+			}
+		}
+
+		if (!of_property_read_u32(child, "clock-frequency", &val))
+			pdata->clkout[num].rate = val;
+
+		pdata->clkout[num].pll_master =
+			of_property_read_bool(child, "silabs,pll-master");
+	}
+	client->dev.platform_data = pdata;
+
+	return 0;
+}
+#else
+static int si5351_dt_parse(struct i2c_client *client)
+{
+	return 0;
+}
+#endif /* CONFIG_OF */
+
+static int si5351_i2c_probe(struct i2c_client *client,
+			    const struct i2c_device_id *id)
+{
+	struct si5351_platform_data *pdata;
+	struct si5351_driver_data *drvdata;
+	struct clk_init_data init;
+	struct clk *clk;
+	const char *parent_names[4];
+	u8 num_parents, num_clocks;
+	int ret, n;
+
+	ret = si5351_dt_parse(client);
+	if (ret)
+		return ret;
+
+	pdata = client->dev.platform_data;
+	if (!pdata)
+		return -EINVAL;
+
+	drvdata = devm_kzalloc(&client->dev, sizeof(*drvdata), GFP_KERNEL);
+	if (drvdata == NULL) {
+		dev_err(&client->dev, "unable to allocate driver data\n");
+		return -ENOMEM;
+	}
+
+	i2c_set_clientdata(client, drvdata);
+	drvdata->client = client;
+	drvdata->variant = pdata->variant;
+	drvdata->pxtal = pdata->clk_xtal;
+	drvdata->pclkin = pdata->clk_clkin;
+
+	drvdata->regmap = devm_regmap_init_i2c(client, &si5351_regmap_config);
+	if (IS_ERR(drvdata->regmap)) {
+		dev_err(&client->dev, "failed to allocate register map\n");
+		return PTR_ERR(drvdata->regmap);
+	}
+
+	/* Disable interrupts */
+	si5351_reg_write(drvdata, SI5351_INTERRUPT_MASK, 0xf0);
+	/* Set disabled output drivers to drive low */
+	si5351_reg_write(drvdata, SI5351_CLK3_0_DISABLE_STATE, 0x00);
+	si5351_reg_write(drvdata, SI5351_CLK7_4_DISABLE_STATE, 0x00);
+	/* Ensure pll select is on XTAL for Si5351A/B */
+	if (drvdata->variant != SI5351_VARIANT_C)
+		si5351_set_bits(drvdata, SI5351_PLL_INPUT_SOURCE,
+				SI5351_PLLA_SOURCE | SI5351_PLLB_SOURCE, 0);
+
+	/* setup clock configuration */
+	for (n = 0; n < 2; n++) {
+		ret = _si5351_pll_reparent(drvdata, n, pdata->pll_src[n]);
+		if (ret) {
+			dev_err(&client->dev,
+				"failed to reparent pll %d to %d\n",
+				n, pdata->pll_src[n]);
+			return ret;
+		}
+	}
+
+	for (n = 0; n < 8; n++) {
+		ret = _si5351_msynth_reparent(drvdata, n,
+					      pdata->clkout[n].multisynth_src);
+		if (ret) {
+			dev_err(&client->dev,
+				"failed to reparent multisynth %d to %d\n",
+				n, pdata->clkout[n].multisynth_src);
+			return ret;
+		}
+
+		ret = _si5351_clkout_reparent(drvdata, n,
+					      pdata->clkout[n].clkout_src);
+		if (ret) {
+			dev_err(&client->dev,
+				"failed to reparent clkout %d to %d\n",
+				n, pdata->clkout[n].clkout_src);
+			return ret;
+		}
+
+		ret = _si5351_clkout_set_drive_strength(drvdata, n,
+							pdata->clkout[n].drive);
+		if (ret) {
+			dev_err(&client->dev,
+				"failed set drive strength of clkout%d to %d\n",
+				n, pdata->clkout[n].drive);
+			return ret;
+		}
+	}
+
+	/* register xtal input clock gate */
+	memset(&init, 0, sizeof(init));
+	init.name = si5351_input_names[0];
+	init.ops = &si5351_xtal_ops;
+	init.flags = 0;
+	if (!IS_ERR(drvdata->pxtal)) {
+		drvdata->pxtal_name = __clk_get_name(drvdata->pxtal);
+		init.parent_names = &drvdata->pxtal_name;
+		init.num_parents = 1;
+	}
+	drvdata->xtal.init = &init;
+	clk = devm_clk_register(&client->dev, &drvdata->xtal);
+	if (IS_ERR(clk)) {
+		dev_err(&client->dev, "unable to register %s\n", init.name);
+		return PTR_ERR(clk);
+	}
+
+	/* register clkin input clock gate */
+	if (drvdata->variant == SI5351_VARIANT_C) {
+		memset(&init, 0, sizeof(init));
+		init.name = si5351_input_names[1];
+		init.ops = &si5351_clkin_ops;
+		if (!IS_ERR(drvdata->pclkin)) {
+			drvdata->pclkin_name = __clk_get_name(drvdata->pclkin);
+			init.parent_names = &drvdata->pclkin_name;
+			init.num_parents = 1;
+		}
+		drvdata->clkin.init = &init;
+		clk = devm_clk_register(&client->dev, &drvdata->clkin);
+		if (IS_ERR(clk)) {
+			dev_err(&client->dev, "unable to register %s\n",
+				init.name);
+			return PTR_ERR(clk);
+		}
+	}
+
+	/* Si5351C allows to mux either xtal or clkin to PLL input */
+	num_parents = (drvdata->variant == SI5351_VARIANT_C) ? 2 : 1;
+	parent_names[0] = si5351_input_names[0];
+	parent_names[1] = si5351_input_names[1];
+
+	/* register PLLA */
+	drvdata->pll[0].num = 0;
+	drvdata->pll[0].drvdata = drvdata;
+	drvdata->pll[0].hw.init = &init;
+	memset(&init, 0, sizeof(init));
+	init.name = si5351_pll_names[0];
+	init.ops = &si5351_pll_ops;
+	init.flags = 0;
+	init.parent_names = parent_names;
+	init.num_parents = num_parents;
+	clk = devm_clk_register(&client->dev, &drvdata->pll[0].hw);
+	if (IS_ERR(clk)) {
+		dev_err(&client->dev, "unable to register %s\n", init.name);
+		return -EINVAL;
+	}
+
+	/* register PLLB or VXCO (Si5351B) */
+	drvdata->pll[1].num = 1;
+	drvdata->pll[1].drvdata = drvdata;
+	drvdata->pll[1].hw.init = &init;
+	memset(&init, 0, sizeof(init));
+	if (drvdata->variant == SI5351_VARIANT_B) {
+		init.name = si5351_pll_names[2];
+		init.ops = &si5351_vxco_ops;
+		init.flags = CLK_IS_ROOT;
+		init.parent_names = NULL;
+		init.num_parents = 0;
+	} else {
+		init.name = si5351_pll_names[1];
+		init.ops = &si5351_pll_ops;
+		init.flags = 0;
+		init.parent_names = parent_names;
+		init.num_parents = num_parents;
+	}
+	clk = devm_clk_register(&client->dev, &drvdata->pll[1].hw);
+	if (IS_ERR(clk)) {
+		dev_err(&client->dev, "unable to register %s\n", init.name);
+		return -EINVAL;
+	}
+
+	/* register clk multisync and clk out divider */
+	num_clocks = (drvdata->variant == SI5351_VARIANT_A3) ? 3 : 8;
+	parent_names[0] = si5351_pll_names[0];
+	if (drvdata->variant == SI5351_VARIANT_B)
+		parent_names[1] = si5351_pll_names[2];
+	else
+		parent_names[1] = si5351_pll_names[1];
+
+	drvdata->msynth = devm_kzalloc(&client->dev, num_clocks *
+				       sizeof(*drvdata->msynth), GFP_KERNEL);
+	drvdata->clkout = devm_kzalloc(&client->dev, num_clocks *
+				       sizeof(*drvdata->clkout), GFP_KERNEL);
+
+	drvdata->onecell.clk_num = num_clocks;
+	drvdata->onecell.clks = devm_kzalloc(&client->dev,
+		num_clocks * sizeof(*drvdata->onecell.clks), GFP_KERNEL);
+
+	if (WARN_ON(!drvdata->msynth || !drvdata->clkout ||
+		    !drvdata->onecell.clks))
+		return -ENOMEM;
+
+	for (n = 0; n < num_clocks; n++) {
+		drvdata->msynth[n].num = n;
+		drvdata->msynth[n].drvdata = drvdata;
+		drvdata->msynth[n].hw.init = &init;
+		memset(&init, 0, sizeof(init));
+		init.name = si5351_msynth_names[n];
+		init.ops = &si5351_msynth_ops;
+		init.flags = 0;
+		if (pdata->clkout[n].pll_master)
+			init.flags |= CLK_SET_RATE_PARENT;
+		init.parent_names = parent_names;
+		init.num_parents = 2;
+		clk = devm_clk_register(&client->dev, &drvdata->msynth[n].hw);
+		if (IS_ERR(clk)) {
+			dev_err(&client->dev, "unable to register %s\n",
+				init.name);
+			return -EINVAL;
+		}
+	}
+
+	num_parents = (drvdata->variant == SI5351_VARIANT_C) ? 4 : 3;
+	parent_names[2] = si5351_input_names[0];
+	parent_names[3] = si5351_input_names[1];
+	for (n = 0; n < num_clocks; n++) {
+		parent_names[0] = si5351_msynth_names[n];
+		parent_names[1] = (n < 4) ? si5351_msynth_names[0] :
+			si5351_msynth_names[4];
+
+		drvdata->clkout[n].num = n;
+		drvdata->clkout[n].drvdata = drvdata;
+		drvdata->clkout[n].hw.init = &init;
+		memset(&init, 0, sizeof(init));
+		init.name = si5351_clkout_names[n];
+		init.ops = &si5351_clkout_ops;
+		init.flags = 0;
+		if (pdata->clkout[n].clkout_src == SI5351_CLKOUT_SRC_MSYNTH_N)
+			init.flags |= CLK_SET_RATE_PARENT;
+		init.parent_names = parent_names;
+		init.num_parents = num_parents;
+		clk = devm_clk_register(&client->dev, &drvdata->clkout[n].hw);
+		if (IS_ERR(clk)) {
+			dev_err(&client->dev, "unable to register %s\n",
+				init.name);
+			return -EINVAL;
+		}
+		drvdata->onecell.clks[n] = clk;
+	}
+
+	ret = of_clk_add_provider(client->dev.of_node, of_clk_src_onecell_get,
+				  &drvdata->onecell);
+	if (ret) {
+		dev_err(&client->dev, "unable to add clk provider\n");
+		return ret;
+	}
+
+	return 0;
+}
+
+static const struct i2c_device_id si5351_i2c_ids[] = {
+	{ "silabs,si5351", 0 },
+	{ }
+};
+MODULE_DEVICE_TABLE(i2c, si5351_i2c_ids);
+
+static struct i2c_driver si5351_driver = {
+	.driver = {
+		.name = "si5351",
+		.of_match_table = of_match_ptr(si5351_dt_ids),
+	},
+	.probe = si5351_i2c_probe,
+	.id_table = si5351_i2c_ids,
+};
+module_i2c_driver(si5351_driver);
+
+MODULE_AUTHOR("Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com");
+MODULE_DESCRIPTION("Silicon Labs Si5351A/B/C clock generator driver");
+MODULE_LICENSE("GPL");
diff --git a/drivers/clk/clk-si5351.h b/drivers/clk/clk-si5351.h
new file mode 100644
index 0000000..af41b50
--- /dev/null
+++ b/drivers/clk/clk-si5351.h
@@ -0,0 +1,155 @@
+/*
+ * clk-si5351.h: Silicon Laboratories Si5351A/B/C I2C Clock Generator
+ *
+ * Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
+ * Rabeeh Khoury <rabeeh at solid-run.com>
+ *
+ * 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.
+ */
+
+#ifndef _CLK_SI5351_H_
+#define _CLK_SI5351_H_
+
+#define SI5351_BUS_BASE_ADDR			0x60
+
+#define SI5351_PLL_VCO_MIN			600000000
+#define SI5351_PLL_VCO_MAX			900000000
+#define SI5351_MULTISYNTH_MIN_FREQ		1000000
+#define SI5351_MULTISYNTH_DIVBY4_FREQ		150000000
+#define SI5351_MULTISYNTH_MAX_FREQ		160000000
+#define SI5351_MULTISYNTH67_MAX_FREQ		SI5351_MULTISYNTH_DIVBY4_FREQ
+#define SI5351_CLKOUT_MIN_FREQ			8000
+#define SI5351_CLKOUT_MAX_FREQ			SI5351_MULTISYNTH_MAX_FREQ
+#define SI5351_CLKOUT67_MAX_FREQ		SI5351_MULTISYNTH67_MAX_FREQ
+
+#define SI5351_PLL_A_MIN			15
+#define SI5351_PLL_A_MAX			90
+#define SI5351_PLL_B_MAX			(SI5351_PLL_C_MAX-1)
+#define SI5351_PLL_C_MAX			1048575
+#define SI5351_MULTISYNTH_A_MIN			6
+#define SI5351_MULTISYNTH_A_MAX			1800
+#define SI5351_MULTISYNTH67_A_MAX		254
+#define SI5351_MULTISYNTH_B_MAX			(SI5351_MULTISYNTH_C_MAX-1)
+#define SI5351_MULTISYNTH_C_MAX			1048575
+#define SI5351_MULTISYNTH_P1_MAX		((1<<18)-1)
+#define SI5351_MULTISYNTH_P2_MAX		((1<<20)-1)
+#define SI5351_MULTISYNTH_P3_MAX		((1<<20)-1)
+
+#define SI5351_DEVICE_STATUS			0
+#define SI5351_INTERRUPT_STATUS			1
+#define SI5351_INTERRUPT_MASK			2
+#define  SI5351_STATUS_SYS_INIT			(1<<7)
+#define  SI5351_STATUS_LOL_B			(1<<6)
+#define  SI5351_STATUS_LOL_A			(1<<5)
+#define  SI5351_STATUS_LOS			(1<<4)
+#define SI5351_OUTPUT_ENABLE_CTRL		3
+#define SI5351_OEB_PIN_ENABLE_CTRL		9
+#define SI5351_PLL_INPUT_SOURCE			15
+#define  SI5351_CLKIN_DIV_MASK			(3<<6)
+#define  SI5351_CLKIN_DIV_1			(0<<6)
+#define  SI5351_CLKIN_DIV_2			(1<<6)
+#define  SI5351_CLKIN_DIV_4			(2<<6)
+#define  SI5351_CLKIN_DIV_8			(3<<6)
+#define  SI5351_PLLB_SOURCE			(1<<3)
+#define  SI5351_PLLA_SOURCE			(1<<2)
+
+#define SI5351_CLK0_CTRL			16
+#define SI5351_CLK1_CTRL			17
+#define SI5351_CLK2_CTRL			18
+#define SI5351_CLK3_CTRL			19
+#define SI5351_CLK4_CTRL			20
+#define SI5351_CLK5_CTRL			21
+#define SI5351_CLK6_CTRL			22
+#define SI5351_CLK7_CTRL			23
+#define  SI5351_CLK_POWERDOWN			(1<<7)
+#define  SI5351_CLK_INTEGER_MODE		(1<<6)
+#define  SI5351_CLK_PLL_SELECT			(1<<5)
+#define  SI5351_CLK_INVERT			(1<<4)
+#define  SI5351_CLK_INPUT_MASK			(3<<2)
+#define  SI5351_CLK_INPUT_XTAL			(0<<2)
+#define  SI5351_CLK_INPUT_CLKIN			(1<<2)
+#define  SI5351_CLK_INPUT_MULTISYNTH_0_4	(2<<2)
+#define  SI5351_CLK_INPUT_MULTISYNTH_N		(3<<2)
+#define  SI5351_CLK_DRIVE_STRENGTH_MASK		(3<<0)
+#define  SI5351_CLK_DRIVE_STRENGTH_2MA		(0<<0)
+#define  SI5351_CLK_DRIVE_STRENGTH_4MA		(1<<0)
+#define  SI5351_CLK_DRIVE_STRENGTH_6MA		(2<<0)
+#define  SI5351_CLK_DRIVE_STRENGTH_8MA		(3<<0)
+
+#define SI5351_CLK3_0_DISABLE_STATE		24
+#define SI5351_CLK7_4_DISABLE_STATE		25
+#define  SI5351_CLK_DISABLE_STATE_LOW		0
+#define  SI5351_CLK_DISABLE_STATE_HIGH		1
+#define  SI5351_CLK_DISABLE_STATE_FLOAT		2
+#define  SI5351_CLK_DISABLE_STATE_NEVER		3
+
+#define SI5351_PARAMETERS_LENGTH		8
+#define SI5351_PLLA_PARAMETERS			26
+#define SI5351_PLLB_PARAMETERS			34
+#define SI5351_CLK0_PARAMETERS			42
+#define SI5351_CLK1_PARAMETERS			50
+#define SI5351_CLK2_PARAMETERS			58
+#define SI5351_CLK3_PARAMETERS			66
+#define SI5351_CLK4_PARAMETERS			74
+#define SI5351_CLK5_PARAMETERS			82
+#define SI5351_CLK6_PARAMETERS			90
+#define SI5351_CLK7_PARAMETERS			91
+#define SI5351_CLK6_7_OUTPUT_DIVIDER		92
+#define  SI5351_OUTPUT_CLK_DIV_MASK		(7 << 4)
+#define  SI5351_OUTPUT_CLK6_DIV_MASK		(7 << 0)
+#define  SI5351_OUTPUT_CLK_DIV_SHIFT		4
+#define  SI5351_OUTPUT_CLK_DIV6_SHIFT		0
+#define  SI5351_OUTPUT_CLK_DIV_1		0
+#define  SI5351_OUTPUT_CLK_DIV_2		1
+#define  SI5351_OUTPUT_CLK_DIV_4		2
+#define  SI5351_OUTPUT_CLK_DIV_8		3
+#define  SI5351_OUTPUT_CLK_DIV_16		4
+#define  SI5351_OUTPUT_CLK_DIV_32		5
+#define  SI5351_OUTPUT_CLK_DIV_64		6
+#define  SI5351_OUTPUT_CLK_DIV_128		7
+#define  SI5351_OUTPUT_CLK_DIVBY4		(3<<2)
+
+#define SI5351_SSC_PARAM0			149
+#define SI5351_SSC_PARAM1			150
+#define SI5351_SSC_PARAM2			151
+#define SI5351_SSC_PARAM3			152
+#define SI5351_SSC_PARAM4			153
+#define SI5351_SSC_PARAM5			154
+#define SI5351_SSC_PARAM6			155
+#define SI5351_SSC_PARAM7			156
+#define SI5351_SSC_PARAM8			157
+#define SI5351_SSC_PARAM9			158
+#define SI5351_SSC_PARAM10			159
+#define SI5351_SSC_PARAM11			160
+#define SI5351_SSC_PARAM12			161
+
+#define SI5351_VXCO_PARAMETERS_LOW		162
+#define SI5351_VXCO_PARAMETERS_MID		163
+#define SI5351_VXCO_PARAMETERS_HIGH		164
+
+#define SI5351_CLK0_PHASE_OFFSET		165
+#define SI5351_CLK1_PHASE_OFFSET		166
+#define SI5351_CLK2_PHASE_OFFSET		167
+#define SI5351_CLK3_PHASE_OFFSET		168
+#define SI5351_CLK4_PHASE_OFFSET		169
+#define SI5351_CLK5_PHASE_OFFSET		170
+
+#define SI5351_PLL_RESET			177
+#define  SI5351_PLL_RESET_B			(1<<7)
+#define  SI5351_PLL_RESET_A			(1<<5)
+
+#define SI5351_CRYSTAL_LOAD			183
+#define  SI5351_CRYSTAL_LOAD_MASK		(3<<6)
+#define  SI5351_CRYSTAL_LOAD_6PF		(1<<6)
+#define  SI5351_CRYSTAL_LOAD_8PF		(2<<6)
+#define  SI5351_CRYSTAL_LOAD_10PF		(3<<6)
+
+#define SI5351_FANOUT_ENABLE			187
+#define  SI5351_CLKIN_ENABLE			(1<<7)
+#define  SI5351_XTAL_ENABLE			(1<<6)
+#define  SI5351_MULTISYNTH_ENABLE		(1<<4)
+
+#endif
diff --git a/include/linux/platform_data/si5351.h b/include/linux/platform_data/si5351.h
new file mode 100644
index 0000000..92dabca
--- /dev/null
+++ b/include/linux/platform_data/si5351.h
@@ -0,0 +1,114 @@
+/*
+ * Si5351A/B/C programmable clock generator platform_data.
+ */
+
+#ifndef __LINUX_PLATFORM_DATA_SI5351_H__
+#define __LINUX_PLATFORM_DATA_SI5351_H__
+
+struct clk;
+
+/**
+ * enum si5351_variant - SiLabs Si5351 chip variant
+ * @SI5351_VARIANT_A: Si5351A (8 output clocks, XTAL input)
+ * @SI5351_VARIANT_A3: Si5351A MSOP10 (3 output clocks, XTAL input)
+ * @SI5351_VARIANT_B: Si5351B (8 output clocks, XTAL/VXCO input)
+ * @SI5351_VARIANT_C: Si5351C (8 output clocks, XTAL/CLKIN input)
+ */
+enum si5351_variant {
+	SI5351_VARIANT_A = 1,
+	SI5351_VARIANT_A3 = 2,
+	SI5351_VARIANT_B = 3,
+	SI5351_VARIANT_C = 4,
+};
+
+/**
+ * enum si5351_pll_src - Si5351 pll clock source
+ * @SI5351_PLL_SRC_DEFAULT: default, do not change eeprom config
+ * @SI5351_PLL_SRC_XTAL: pll source clock is XTAL input
+ * @SI5351_PLL_SRC_CLKIN: pll source clock is CLKIN input (Si5351C only)
+ */
+enum si5351_pll_src {
+	SI5351_PLL_SRC_DEFAULT = 0,
+	SI5351_PLL_SRC_XTAL = 1,
+	SI5351_PLL_SRC_CLKIN = 2,
+};
+
+/**
+ * enum si5351_multisynth_src - Si5351 multisynth clock source
+ * @SI5351_MULTISYNTH_SRC_DEFAULT: default, do not change eeprom config
+ * @SI5351_MULTISYNTH_SRC_VCO0: multisynth source clock is VCO0
+ * @SI5351_MULTISYNTH_SRC_VCO1: multisynth source clock is VCO1/VXCO
+ */
+enum si5351_multisynth_src {
+	SI5351_MULTISYNTH_SRC_DEFAULT = 0,
+	SI5351_MULTISYNTH_SRC_VCO0 = 1,
+	SI5351_MULTISYNTH_SRC_VCO1 = 2,
+};
+
+/**
+ * enum si5351_clkout_src - Si5351 clock output clock source
+ * @SI5351_CLKOUT_SRC_DEFAULT: default, do not change eeprom config
+ * @SI5351_CLKOUT_SRC_MSYNTH_N: clkout N source clock is multisynth N
+ * @SI5351_CLKOUT_SRC_MSYNTH_0_4: clkout N source clock is multisynth 0 (N<4)
+ *                                or 4 (N>=4)
+ * @SI5351_CLKOUT_SRC_XTAL: clkout N source clock is XTAL
+ * @SI5351_CLKOUT_SRC_CLKIN: clkout N source clock is CLKIN (Si5351C only)
+ */
+enum si5351_clkout_src {
+	SI5351_CLKOUT_SRC_DEFAULT = 0,
+	SI5351_CLKOUT_SRC_MSYNTH_N = 1,
+	SI5351_CLKOUT_SRC_MSYNTH_0_4 = 2,
+	SI5351_CLKOUT_SRC_XTAL = 3,
+	SI5351_CLKOUT_SRC_CLKIN = 4,
+};
+
+/**
+ * enum si5351_drive_strength - Si5351 clock output drive strength
+ * @SI5351_DRIVE_DEFAULT: default, do not change eeprom config
+ * @SI5351_DRIVE_2MA: 2mA clock output drive strength
+ * @SI5351_DRIVE_4MA: 4mA clock output drive strength
+ * @SI5351_DRIVE_6MA: 6mA clock output drive strength
+ * @SI5351_DRIVE_8MA: 8mA clock output drive strength
+ */
+enum si5351_drive_strength {
+	SI5351_DRIVE_DEFAULT = 0,
+	SI5351_DRIVE_2MA = 2,
+	SI5351_DRIVE_4MA = 4,
+	SI5351_DRIVE_6MA = 6,
+	SI5351_DRIVE_8MA = 8,
+};
+
+/**
+ * struct si5351_clkout_config - Si5351 clock output configuration
+ * @clkout: clkout number
+ * @multisynth_src: multisynth source clock
+ * @clkout_src: clkout source clock
+ * @pll_master: if true, clkout can also change pll rate
+ * @drive: output drive strength
+ * @rate: initial clkout rate, or default if 0
+ */
+struct si5351_clkout_config {
+	enum si5351_multisynth_src multisynth_src;
+	enum si5351_clkout_src clkout_src;
+	enum si5351_drive_strength drive;
+	bool pll_master;
+	unsigned long rate;
+};
+
+/**
+ * struct si5351_platform_data - Platform data for the Si5351 clock driver
+ * @variant: Si5351 chip variant
+ * @clk_xtal: xtal input clock
+ * @clk_clkin: clkin input clock
+ * @pll_src: array of pll source clock setting
+ * @clkout: array of clkout configuration
+ */
+struct si5351_platform_data {
+	enum si5351_variant variant;
+	struct clk *clk_xtal;
+	struct clk *clk_clkin;
+	enum si5351_pll_src pll_src[2];
+	struct si5351_clkout_config clkout[8];
+};
+
+#endif
-- 
1.7.10.4



From andrew at lunn.ch  Thu Apr 11 15:45:56 2013
From: andrew at lunn.ch (Andrew Lunn)
Date: Thu, 11 Apr 2013 21:45:56 +0200
Subject: [PATCHv2 08/10] arm: kirkwood: convert QNAP TS219 to use DT for
 the PCIe interface
In-Reply-To: <20130411052432.GP13524@lunn.ch>
References: <1365632436-25367-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1365632436-25367-9-git-send-email-thomas.petazzoni@free-electrons.com>
 <20130411003301.GH28693@titan.lakedaemon.net>
 <20130411052432.GP13524@lunn.ch>
Message-ID: <20130411194556.GB5061@lunn.ch>

> Hi Jason
> 
> It has been broken for a while, hence the FIXME!
> 
> Looking at the old style code, only a machine whos bootloader passed
> the machine ID ts219 has PCI. This is the only difference between
> ts219 and all other similar devices that use this DT description.
> 
> The FIXME comment is referring to a comment in the code:
> 
>         MPP44_GPIO,             /* Board ID: 0: TS-11x, 1: TS-21x */
> 
> so it seems like you can read this gpio line but strictly, this tells
> you how many disks bays the box has, and not if its a ts219.
> 
> I've hacked around with PCI driver on my QNAP TS119P+, which does not
> have any PCI devices, and never had any problems with the driver
> enabled and finding two empty PCI busses. PCI does not share any pins
> with anything else. So i think it is safe to just enable it for all
> devices.
> 
> I will test it out on my device and report back.

Hi Jason

Once i hacked around the DT issue, i have it booting and detecting the
PCI:

root at qnap:~# lspci -v
00:01.0 PCI bridge: Marvell Technology Group Ltd. Device 7846 (prog-if 00 [Norm)
        Flags: bus master, 66MHz, user-definable features, ?? devsel, latency 0
        Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
        Capabilities: [fc] <chain broken>

As expected, nothing on the bus.

In the kernel log is:

mvebu-pcie pcie-controller.1: PCIe0.0: link up
mvebu-pcie pcie-controller.1: PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [io  0x1000-0xfffff]
pci_bus 0000:00: root bus resource [mem 0xe0000000-0xe7ffffff]
pci_bus 0000:00: root bus resource [bus 00-ff]
pci 0000:00:01.0: [11ab:7846] type 01 class 0x060400
PCI: bus0: Fast back to back transfers disabled
pci 0000:00:01.0: bridge configuration invalid ([bus 00-00]), reconfiguring
PCI: bus1: Fast back to back transfers enabled
pci_bus 0000:01: busn_res: [bus 01-ff] end is updated to 01
pci 0000:00:01.0: PCI bridge to [bus 01]
PCI: enabling device 0000:00:01.0 (0140 -> 0143)
 
root at qnap:/debug/mvebu-mbus# cat devices 
[00] disabled
[01] disabled
[02] disabled
[03] disabled
[04] 00000000f4000000 - 00000000f4010000 : nand
[05] 00000000f5000000 - 00000000f5010000 : sram
[06] disabled
[07] disabled

So i guess that means its not allocated any windows either.

I will go investigate the PEX clock strapping as suggested by Jason.

  Andrew


From eric.dumazet at gmail.com  Thu Apr 11 15:46:57 2013
From: eric.dumazet at gmail.com (Eric Dumazet)
Date: Thu, 11 Apr 2013 12:46:57 -0700
Subject: [PATCH] net: mv643xx_eth: remove deprecated inet_lro support
In-Reply-To: <1365707488-28819-1-git-send-email-sebastian.hesselbarth@gmail.com>
References: <1365707488-28819-1-git-send-email-sebastian.hesselbarth@gmail.com>
Message-ID: <1365709617.3887.185.camel@edumazet-glaptop>

On Thu, 2013-04-11 at 21:11 +0200, Sebastian Hesselbarth wrote:
> With recent support for GRO, there is no need to keep both LRO and
> GRO. This patch therefore removes the deprecated inet_lro support
> from mv643xx_eth. This is work is based on an experimental patch
> provided by Eric Dumazet and Willy Tarreau.
> 
> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
> Based-on-patch-by: Eric Dumazet <eric.dumazet at gmail.com>
> Based-on-patch-by: Willy Tarreau <w at 1wt.eu>
> ---
> Note: This patch is based upon recent cleanup patches and GRO support
> patch for mv643xx_eth.
> 
> Cc: "David S. Miller" <davem at davemloft.net>
> Cc: Lennert Buytenhek <buytenh at wantstofly.org>
> Cc: Andrew Lunn <andrew at lunn.ch>
> Cc: Jason Cooper <jason at lakedaemon.net>
> Cc: Florian Fainelli <florian at openwrt.org>
> Cc: Benjamin Herrenschmidt <benh at kernel.crashing.org>
> Cc: Paul Mackerras <paulus at samba.org>
> Cc: Dale Farnsworth <dale at farnsworth.org>
> Cc: Ben Hutchings <bhutchings at solarflare.com>
> Cc: Soeren Moch <smoch at web.de>
> Cc: Eric Dumazet <eric.dumazet at gmail.com>
> Cc: Willy Tarreau <w at 1wt.eu>
> Cc: netdev at vger.kernel.org
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linuxppc-dev at lists.ozlabs.org
> Cc: linux-kernel at vger.kernel.org
> ---
>  drivers/net/ethernet/marvell/mv643xx_eth.c |   97 +---------------------------
>  1 file changed, 3 insertions(+), 94 deletions(-)

Seems fine to me, but you also could remove "select INET_LRO"
from drivers/net/ethernet/marvell/Kconfig




From sebastian.hesselbarth at gmail.com  Thu Apr 11 15:52:52 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Thu, 11 Apr 2013 21:52:52 +0200
Subject: [PATCH] net: mv643xx_eth: remove deprecated inet_lro support
In-Reply-To: <1365709617.3887.185.camel@edumazet-glaptop>
References: <1365707488-28819-1-git-send-email-sebastian.hesselbarth@gmail.com>
 <1365709617.3887.185.camel@edumazet-glaptop>
Message-ID: <51671494.6000803@gmail.com>

On 04/11/2013 09:46 PM, Eric Dumazet wrote:
> On Thu, 2013-04-11 at 21:11 +0200, Sebastian Hesselbarth wrote:
>> With recent support for GRO, there is no need to keep both LRO and
>> GRO. This patch therefore removes the deprecated inet_lro support
>> from mv643xx_eth. This is work is based on an experimental patch
>> provided by Eric Dumazet and Willy Tarreau.
>>
>> Signed-off-by: Sebastian Hesselbarth<sebastian.hesselbarth at gmail.com>
>> Based-on-patch-by: Eric Dumazet<eric.dumazet at gmail.com>
>> Based-on-patch-by: Willy Tarreau<w at 1wt.eu>
>> ---
>> Note: This patch is based upon recent cleanup patches and GRO support
>> patch for mv643xx_eth.
>>
>> Cc: "David S. Miller"<davem at davemloft.net>
>> Cc: Lennert Buytenhek<buytenh at wantstofly.org>
>> Cc: Andrew Lunn<andrew at lunn.ch>
>> Cc: Jason Cooper<jason at lakedaemon.net>
>> Cc: Florian Fainelli<florian at openwrt.org>
>> Cc: Benjamin Herrenschmidt<benh at kernel.crashing.org>
>> Cc: Paul Mackerras<paulus at samba.org>
>> Cc: Dale Farnsworth<dale at farnsworth.org>
>> Cc: Ben Hutchings<bhutchings at solarflare.com>
>> Cc: Soeren Moch<smoch at web.de>
>> Cc: Eric Dumazet<eric.dumazet at gmail.com>
>> Cc: Willy Tarreau<w at 1wt.eu>
>> Cc: netdev at vger.kernel.org
>> Cc: linux-arm-kernel at lists.infradead.org
>> Cc: linuxppc-dev at lists.ozlabs.org
>> Cc: linux-kernel at vger.kernel.org
>> ---
>>   drivers/net/ethernet/marvell/mv643xx_eth.c |   97 +---------------------------
>>   1 file changed, 3 insertions(+), 94 deletions(-)
>
> Seems fine to me, but you also could remove "select INET_LRO"
> from drivers/net/ethernet/marvell/Kconfig

Ok, I will wait for tomorrow to see if there are more objections and
respin a v2.

Sebastian


From laurent.pinchart at ideasonboard.com  Thu Apr 11 16:06:47 2013
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Thu, 11 Apr 2013 22:06:47 +0200
Subject: [PATCH V2] video: implement a simple framebuffer driver
In-Reply-To: <5166DF99.2000308@wwwdotorg.org>
References: <1365043183-28905-1-git-send-email-swarren@wwwdotorg.org>
 <2569832.XQDrhUGNaI@avalon> <5166DF99.2000308@wwwdotorg.org>
Message-ID: <1828875.4dYa7WRt67@avalon>

Hi Stephen,

On Thursday 11 April 2013 10:06:49 Stephen Warren wrote:
> On 04/11/2013 03:56 AM, Laurent Pinchart wrote:
> > On Monday 08 April 2013 17:16:37 Andrew Morton wrote:
> >> On Wed,  3 Apr 2013 20:39:43 -0600 Stephen Warren wrote:
> >>> A simple frame-buffer describes a raw memory region that may be rendered
> >>> to, with the assumption that the display hardware has already been set
> >>> up to scan out from that buffer.
> >>> 
> >>> This is useful in cases where a bootloader exists and has set up the
> >>> display hardware, but a Linux driver doesn't yet exist for the display
> >>> hardware.
> >>> 
> >>> ...
> >>> 
> >>> +config FB_SIMPLE
> >>> +	bool "Simple framebuffer support"
> >>> +	depends on (FB = y) && OF
> >> 
> >> It's sad that this simple little thing requires Open Firmware.  Could
> >> it be generalised in some way so that the small amount of setup info
> >> could be provided by other means (eg, module_param) or does the
> >> dependency go deeper than that?
> > 
> > I second that request. I like the idea of a simple framebuffer driver if
> > it helps deprecating fbdev in the long term, but I don't want it to offer
> > an excuse not to implement a DRM/KMS driver. In particular adding DT
> > bindings would force us to keep supporting the ABI for a (too) long time.
> 
> The platforms I intend to use this with only support device tree. Adding
> support for platform data right now would just be dead code. If somebody
> wants to use this driver with a board file based system rather than a DT
> based system, it would be trivial do modify the driver to add a platform
> data structure at that time.

What about using module parameters instead of DT bindings and platform data ? 
As this is a hack designed to work around the lack of a proper display driver 
the frame buffer address and size could just be passed by the boot loader 
through the kernel command line, and the device would then be instantiated by 
the driver.

> Adding support for a platform data structure won't remove the need for
> DT support in the driver; any platform that uses DT will always
> configure this driver through the DT binding irrespective of whether
> some other platform could configure it using platform_data.
> 
> I don't believe the DT bindings imply that they must be implemented by
> an FB driver rather than a KMS driver. It's just that it's much simpler
> to do so at present. If the whole FB subsystem goes away at some time,
> it should be possible to implement a simplest-possible KMS driver that
> supports the same DT binding. I didn't do it this way because supporting
> a pre-allocated FB in DRM/KMS apparently means implementing a custom
> memory allocator for this in the driver, which would be a lot of code
> overhead when right now the driver can just use the FB subsystem and
> simply return the address directly. The simplest possible FB driver
> appears much simpler (less code size, less maintenance) than the
> simplest possible KMS driver.
> 
> My inclination is that for many platforms, the bootloader support for
> graphics output will appear first (before the kernel's), and this driver
> will allow for the kernel to have a graphical console, allowing a more
> complete/useful system to be available earlier. In many cases, that
> window may be small; a DRM/KMS driver may appear soon after the basic
> CPU/board/... support, and then people can switch to using it if they want.
> 
> That said, I also don't really see a problem not implementing a DRM/KMS
> driver for a platform; a dumb frame-buffer works perfectly well for my
> needs. Nobody would be forced to continue using it once a better
> alternative existed.

-- 
Regards,

Laurent Pinchart



From mturquette at linaro.org  Thu Apr 11 16:09:09 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Thu, 11 Apr 2013 13:09:09 -0700
Subject: [PATCH] clk: tegra: Fix cdev1 and cdev2 IDs
In-Reply-To: <1365118019-5748-1-git-send-email-swarren@wwwdotorg.org>
References: <1365118019-5748-1-git-send-email-swarren@wwwdotorg.org>
Message-ID: <20130411200909.7915.45809@quantum>

Quoting Stephen Warren (2013-04-04 16:26:58)
> From: Prashant Gaikwad <pgaikwad at nvidia.com>
> 
> Correct IDs for cdev1 and cdev2 are 94 and 93 respectively.
> 
> Signed-off-by: Prashant Gaikwad <pgaikwad at nvidia.com>
> [swarren: split into separate driver and device-tree patches]
> Signed-off-by: Stephen Warren <swarren at nvidia.com>

Acked-by: Mike Turquette <mturquette at linaro.org>

> ---
> I split this patch in two when applying it. Reposting just so everyone
> can see exactly what I applied. This is the patch from Tegra's
> for-3.10/clk branch.
> 
>  Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt |    4 ++--
>  drivers/clk/tegra/clk-tegra20.c                                |    2 +-
>  drivers/clk/tegra/clk-tegra30.c                                |    2 +-
>  3 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt b/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt
> index 0921fac..e885680 100644
> --- a/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt
> +++ b/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt
> @@ -120,8 +120,8 @@ Required properties :
>    90   clk_d
>    91   unassigned
>    92   sus
> -  93   cdev1
> -  94   cdev2
> +  93   cdev2
> +  94   cdev1
>    95   unassigned
>  
>    96   uart2
> diff --git a/drivers/clk/tegra/clk-tegra20.c b/drivers/clk/tegra/clk-tegra20.c
> index f87bd4a..a7dc0a9 100644
> --- a/drivers/clk/tegra/clk-tegra20.c
> +++ b/drivers/clk/tegra/clk-tegra20.c
> @@ -236,7 +236,7 @@ enum tegra20_clk {
>         dvc, dsi, mipi = 50, hdmi, csi, tvdac, i2c2, uartc, emc = 57, usb2,
>         usb3, mpe, vde, bsea, bsev, speedo, uartd, uarte, i2c3, sbc4, sdmmc3,
>         pex, owr, afi, csite, pcie_xclk, avpucq = 75, la, irama = 84, iramb,
> -       iramc, iramd, cram2, audio_2x, clk_d, csus = 92, cdev1, cdev2,
> +       iramc, iramd, cram2, audio_2x, clk_d, csus = 92, cdev2, cdev1,
>         uartb = 96, vfir, spdif_in, spdif_out, vi, vi_sensor, tvo, cve,
>         osc, clk_32k, clk_m, sclk, cclk, hclk, pclk, blink, pll_a, pll_a_out0,
>         pll_c, pll_c_out1, pll_d, pll_d_out0, pll_e, pll_m, pll_m_out1,
> diff --git a/drivers/clk/tegra/clk-tegra30.c b/drivers/clk/tegra/clk-tegra30.c
> index b8b241d..181a6ee 100644
> --- a/drivers/clk/tegra/clk-tegra30.c
> +++ b/drivers/clk/tegra/clk-tegra30.c
> @@ -330,7 +330,7 @@ enum tegra30_clk {
>         usb3, mpe, vde, bsea, bsev, speedo, uartd, uarte, i2c3, sbc4, sdmmc3,
>         pcie, owr, afi, csite, pciex, avpucq, la, dtv = 79, ndspeed, i2cslow,
>         dsib, irama = 84, iramb, iramc, iramd, cram2, audio_2x = 90, csus = 92,
> -       cdev1, cdev2, cpu_g = 96, cpu_lp, gr3d2, mselect, tsensor, i2s3, i2s4,
> +       cdev2, cdev1, cpu_g = 96, cpu_lp, gr3d2, mselect, tsensor, i2s3, i2s4,
>         i2c4, sbc5, sbc6, d_audio, apbif, dam0, dam1, dam2, hda2codec_2x,
>         atomics, audio0_2x, audio1_2x, audio2_2x, audio3_2x, audio4_2x,
>         spdif_2x, actmon, extern1, extern2, extern3, sata_oob, sata, hda,
> -- 
> 1.7.10.4


From mturquette at linaro.org  Thu Apr 11 16:09:22 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Thu, 11 Apr 2013 13:09:22 -0700
Subject: [PATCH] clk: tegra: fix enum tegra114_clk to match binding
In-Reply-To: <1365118274-5823-1-git-send-email-swarren@wwwdotorg.org>
References: <1365118274-5823-1-git-send-email-swarren@wwwdotorg.org>
Message-ID: <20130411200922.7915.95842@quantum>

Quoting Stephen Warren (2013-04-04 16:31:13)
> From: Stephen Warren <swarren at nvidia.com>
> 
> A gap exists in the binding's clock ID definitions. Fix the clock driver
> to be consistent. This allows pclk to be looked up through device tree
> and prevents:
> 
> ERROR: could not get clock /pmc:pclk(0)
> 
> Signed-off-by: Stephen Warren <swarren at nvidia.com>

Acked-by: Mike Turquette <mturquette at linaro.org>

> ---
> I have already applied this to Tegra's for-3.10/clk branch, since it's
> such a trivial fix.
> 
>  drivers/clk/tegra/clk-tegra114.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/clk/tegra/clk-tegra114.c b/drivers/clk/tegra/clk-tegra114.c
> index 0db81dd..d78e16e 100644
> --- a/drivers/clk/tegra/clk-tegra114.c
> +++ b/drivers/clk/tegra/clk-tegra114.c
> @@ -760,7 +760,7 @@ enum tegra114_clk {
>         pll_re_vco, pll_re_out, pll_e_out0, spdif_in_sync, i2s0_sync,
>         i2s1_sync, i2s2_sync, i2s3_sync, i2s4_sync, vimclk_sync, audio0,
>         audio1, audio2, audio3, audio4, spdif, clk_out_1, clk_out_2, clk_out_3,
> -       blink, xusb_host_src, xusb_falcon_src, xusb_fs_src, xusb_ss_src,
> +       blink, xusb_host_src = 252, xusb_falcon_src, xusb_fs_src, xusb_ss_src,
>         xusb_dev_src, xusb_dev, xusb_hs_src, sclk, hclk, pclk, cclk_g, cclk_lp,
>  
>         /* Mux clocks */
> -- 
> 1.7.10.4


From sylvester.nawrocki at gmail.com  Thu Apr 11 16:14:43 2013
From: sylvester.nawrocki at gmail.com (Sylwester Nawrocki)
Date: Thu, 11 Apr 2013 22:14:43 +0200
Subject: [PATCH v8 1/7] media: V4L2: add temporary clock helpers
In-Reply-To: <20130411185258.7915.67263@quantum>
References: <CAGsJ_4zCRBvEX9xEDCr27JLK6wYp_2T_wk2hzVjqpKinbL=9pg@mail.gmail.com>
 <Pine.LNX.4.64.1304110921480.23859@axis700.grange>
 <CAGsJ_4xXRHDbpuqT3e5=0vz9_NxxCXfvrci+h567HP9=AhwRiQ@mail.gmail.com>
 <Pine.LNX.4.64.1304111028090.23859@axis700.grange>
 <CAGsJ_4yXE7SYLgPucW9kAEYgKg+z93j8yN3d+gvhqeLAn-sSOw@mail.gmail.com>
 <20130411185258.7915.67263@quantum>
Message-ID: <516719B3.8060502@gmail.com>

Hi,

On 04/11/2013 08:52 PM, Mike Turquette wrote:
[...]
>>> So, you enable CFF, it provides its own clk_* implementation like
>>> clk_get_rate() etc. Now, PXA already has it defined in
>>> arch/arm/mach-pxa/clock.c. Don't think this is going to fly.
>>
>> agree.
>
> Hi,
>
> I came into this thread late and don't have the actual patches in my
> inbox for review.  That said, I don't understand why V4L2 cares about
> the clk framework *implementation*?  The clk.h api is the same for
> platforms using the common struct clk and those still using the legacy
> method of defining their own struct clk.  If drivers are only consumers
> of the clk.h api then the implementation underneath should not matter.

I came to similar conclusions previously, but in case when one of the two
drivers is the clock provider I think there is still an issue there.

The drivers are supposed to be platform agnostic, but the clock provider
would have to include mach specific declarations of struct clk, wouldn't
it ?

Regards,
Sylwester


From robherring2 at gmail.com  Thu Apr 11 16:16:57 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Thu, 11 Apr 2013 15:16:57 -0500
Subject: [PATCH 0/4 v6] arm: introduce psci_smp_ops and use them on Xen
In-Reply-To: <20130411082519.GD31465@quad.lixom.net>
References: <alpine.DEB.2.02.1304031239550.5078@kaball.uk.xensource.com>
 <alpine.DEB.2.02.1304081102500.5353@kaball.uk.xensource.com>
 <20130411082519.GD31465@quad.lixom.net>
Message-ID: <51671A39.6090105@gmail.com>

On 04/11/2013 03:25 AM, Olof Johansson wrote:
> On Mon, Apr 08, 2013 at 12:05:17PM +0100, Stefano Stabellini wrote:
>> Arnd, Olof,
>> do you have any thoughts on this series?
>> Would you be happy to carry it in the arm-soc tree?
>>
>> The last patch, "xen/arm: introduce xen_early_init, use PSCI on xen" has
>> a (small) dependency on this series:
>>
>> http://marc.info/?l=linux-kernel&m=136430893610688&w=2
>>
>> would you be OK with taking that one too, or should that go through the
>> Xen tree?
> 
> I think it'd make sense to get Russell to ack the changes to the core ARM code.
> We can merge the series through arm-soc, or he can take them, whatever is
> easiest for everybody.
> 
> Given the dependencies on the second branch it might be easier to merge
> through Russell's tree.

I'm also dependent on the 1st patch for converting highbank to use PSCI
and am just waiting on a stable branch to base it on. I believe Russell
said he is offline for the next week.

Rob




From davem at davemloft.net  Thu Apr 11 16:22:45 2013
From: davem at davemloft.net (David Miller)
Date: Thu, 11 Apr 2013 16:22:45 -0400 (EDT)
Subject: [PATCH] net: mv643xx_eth: Add GRO support
In-Reply-To: <1365684023-9967-1-git-send-email-sebastian.hesselbarth@gmail.com>
References: <1365684023-9967-1-git-send-email-sebastian.hesselbarth@gmail.com>
Message-ID: <20130411.162245.954727103094202894.davem@davemloft.net>

From: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
Date: Thu, 11 Apr 2013 14:40:23 +0200

> This patch adds GRO support to mv643xx_eth by making it invoke
> napi_gro_receive instead of netif_receive_skb.
> 
> Signed-off-by: Soeren Moch <smoch at web.de>
> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>

Applied.


From gregkh at linuxfoundation.org  Thu Apr 11 16:25:40 2013
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Thu, 11 Apr 2013 13:25:40 -0700
Subject: [PATCH 10/30] usb: exynos: do not include plat/usb-phy.h
In-Reply-To: <1365638712-1028578-11-git-send-email-arnd@arndb.de>
References: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
 <1365638712-1028578-11-git-send-email-arnd@arndb.de>
Message-ID: <20130411202540.GA32047@kroah.com>

On Thu, Apr 11, 2013 at 02:04:52AM +0200, Arnd Bergmann wrote:
> The definitions have moved to include/linux/usb/samsung-usb-phy.h,
> and plat/usb-phy.h is unavailable from drivers in a multiplatform
> configuration.
> 
> Also fix up the plat/usb-phy.h header file to use the definitions
> from the new header instead of providing a separate copy.
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Cc: linux-usb at vger.kernel.org
> Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
> Cc: Alan Stern <stern at rowland.harvard.edu>
> ---
>  arch/arm/mach-exynos/setup-usb-phy.c         | 8 ++++----
>  arch/arm/mach-s3c64xx/setup-usb-phy.c        | 4 ++--
>  arch/arm/mach-s5pv210/setup-usb-phy.c        | 4 ++--
>  arch/arm/plat-samsung/include/plat/usb-phy.h | 5 +----
>  drivers/usb/host/ehci-s5p.c                  | 1 -
>  drivers/usb/host/ohci-exynos.c               | 1 -
>  6 files changed, 9 insertions(+), 14 deletions(-)

This patch doesn't apply to my usb-next tree due to the other changes in
these files.

Care to refresh it and resend it?  I'll be glad to apply it then.

thanks,

greg k-h


From linus.walleij at linaro.org  Thu Apr 11 16:27:53 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 11 Apr 2013 22:27:53 +0200
Subject: [PATCH 11/11] RFC: ARM: get PCI device IRQs from device tree
In-Reply-To: <1365087696-9548-12-git-send-email-linus.walleij@linaro.org>
References: <1365087696-9548-1-git-send-email-linus.walleij@linaro.org>
 <1365087696-9548-2-git-send-email-linus.walleij@linaro.org>
 <1365087696-9548-3-git-send-email-linus.walleij@linaro.org>
 <1365087696-9548-4-git-send-email-linus.walleij@linaro.org>
 <1365087696-9548-5-git-send-email-linus.walleij@linaro.org>
 <1365087696-9548-6-git-send-email-linus.walleij@linaro.org>
 <1365087696-9548-7-git-send-email-linus.walleij@linaro.org>
 <1365087696-9548-8-git-send-email-linus.walleij@linaro.org>
 <1365087696-9548-9-git-send-email-linus.walleij@linaro.org>
 <1365087696-9548-10-git-send-email-linus.walleij@linaro.org>
 <1365087696-9548-11-git-send-email-linus.walleij@linaro.org>
 <1365087696-9548-12-git-send-email-linus.walleij@linaro.org>
Message-ID: <CACRpkdZhPYqxgUuffTabN+RZkTBY2w0t-OmJ8Wsew8qOWTRQ7A@mail.gmail.com>

On Thu, Apr 4, 2013 at 5:01 PM, Linus Walleij <linus.walleij at linaro.org> wrote:

> This currently bugs out - when trying to get the IRQs for
> devices of_irq_map_pci() reads the IRQ pin from the PCI config
> space successfully, then comes to trying to look up the parent
> PCI device by checking pdev->bus->self, which is NULL, then
> tries to treat it as a bridge doing pci_bus_to_OF_node(pdev->bus)
> which also results in NULL and it bails out.
>
> No clue why this is so - some problem with the parent of this
> bus not being a PCI device in itself? Help.

Tracked this down to a point where in drivers/pci/of.c
pci_set_bus_of_node() is called on the root bus, at which
point it calls pcibios_get_phb_of_node() which has no clue
on how to obtain the DT node for the root hub. (Only bridges.)

Inserting this na?ve fragment into the PCI driver makes things
tick:

+struct device_node *static_root;
+
+struct device_node *pcibios_get_phb_of_node(struct pci_bus *bus)
+{
+       return static_root;
+}
+

In probe():
+       static_root = np;

It'll override the weak symbol and make things work.

I guess this is something for kernel/bios32.c to implement
if we want to support DT on these PCI adapters, so looking
into that next...

But how do others get their things to work? Not using bios32?
I wonder...

Yours,
Linus Walleij


From swarren at wwwdotorg.org  Thu Apr 11 16:30:51 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Thu, 11 Apr 2013 14:30:51 -0600
Subject: [PATCH 3/5] gpio/omap: Add DT support to GPIO driver
In-Reply-To: <CACRpkdYirFNqmGhA4K9CL4ve4NYhs8Rd3SFt1iwW9vHBkrcz8g@mail.gmail.com>
References: <1329321854-24490-1-git-send-email-b-cousson@ti.com>
 <4F452484.5080503@gmail.com>
 <74CDBE0F657A3D45AFBB94109FB122FF17BD8BC6C1@HQMAIL01.nvidia.com>
 <4F47AD08.4030504@ti.com>
 <CAAwP0s0cB368R2mtbJpTZJreR-5GSRLfxC+8DJLo5nw3_OwBuA@mail.gmail.com>
 <512D39DA.7020306@ti.com> <512D3AB1.1080202@wwwdotorg.org>
 <512D3EC2.6050408@ti.com> <20130302200524.D230F3E1571@localhost>
 <51391F41.5000303@ti.com>
 <CAAwP0s1CFRO-rf==p5sYs1n0gigMif7wuT8Yv0N_iLUDMrtcOg@mail.gmail.com>
 <CACRpkdYHj-rEF3Rk_CWnmmMw_Amr7m8SgQ=-2zsDYuLeuu3azw@mail.gmail.com>
 <514C79E1.4090106@wwwdotorg.org> <514CE0AB.6060207@ti.com>
 <CACRpkdZmv-rAoKSQYpkHHSMzKJOn5TixVW_P3=m7ZNagBYCUPw@mail.gmail.com>
 <515319D5.20105@wwwdotorg.org>
 <CACRpkdYXVLgCz1Tyu-Ls2V2OTc4R3cGNJhfQJB6Hiz_K9dkZYQ@mail.gmail.com>
 <5155C902.7080207@wwwdotorg.org>
 <CACRpkdYbs4-uudpRUY8e+7icYYkZrfM0kReP3pLL5DMiURJ4dg@mail.gmail.com>
 <5165CB9D.1090202@wwwdotorg.org>
 <CACRpkdYirFNqmGhA4K9CL4ve4NYhs8Rd3SFt1iwW9vHBkrcz8g@mail.gmail.com>
Message-ID: <51671D7B.5060303@wwwdotorg.org>

On 04/10/2013 03:28 PM, Linus Walleij wrote:
> On Wed, Apr 10, 2013 at 10:29 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
>> On 04/10/2013 12:12 PM, Linus Walleij wrote:
> 
>>> If the information is there, whether to convert from IRQ to GPIO
>>> or from GPIO to IRQ is a technicality and any order should be
>>> feasible in some way?
>>
>> There isn't always a unique 1:1 mapping between GPIOs and IRQs. Put
>> another way, a single GPIO would likely only ever trigger a single IRQ,
>> but a single IRQ might easily be triggered by any number of GPIOs. This
>> is exactly why the function irq_to_gpio() isn't something one should use
>> any more. I think there was an effort to outright remove the API,
>> although it doesn't look like that's entirely complete yet. I guess you
>> know this given your mentions of problem with gpio_to_irq() later on, so
>> I'm not quite sure what your paragraph above was supposed to mean.
> 
> So the only reason I'm rambing on about this is that it breaks the

I'm not sure I understand this paragraph; what is "it" in the line above.

If "it" is this patch, then should "breaks" be re-establishes?

> connection between GPIOs and their IRQs and at one point
> I percieved it as there was going to be some IRQ -> GPIO lookup,
> and it would sneak back in. But now I realize that may have been
> supposed to be something local to the driver, in it's irqchip portions
> and then it's actually no problem for the kernel at large.

Yes, I believe the intention was for their to be a correlation between
GPIOs and IRQs only with the individual gpio_chip/irq_chip drivers for
those GPIOs/IRQs, and not exposed anywhere outside it.

> Let's restate: I'm also after something fragile here.

I assume you mean the opposite of that?

> IIUC, it will be possible for a GPIO to be set up as input and used
> as an IRQ without the GPIO subsystem knowing it. And it will be
> possible for the GPIO subsystem to go in and request the same pin
> and set it as output and e.g. bit-bang it. I wonder what happens then.

Yes, I think that's possible now.

If I recall the patch I'm replying to correctly, the idea was to add an
"IRQ request" operation that would (internally to the GPIO/IRQ driver
itself) map IRQ->GPIO, and call gpio_request(). That would then prevent
exactly the situation you mention above.


From linus.walleij at linaro.org  Thu Apr 11 16:33:07 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 11 Apr 2013 22:33:07 +0200
Subject: [PATCH] cpufreq: dbx500: Round to closest available freq
In-Reply-To: <1365599175-22361-1-git-send-email-ulf.hansson@stericsson.com>
References: <1365599175-22361-1-git-send-email-ulf.hansson@stericsson.com>
Message-ID: <CACRpkdb75wPjXEYdkqE6BOCsuFA_ZBc6GAz1m-5vHWSrSGKyUA@mail.gmail.com>

On Wed, Apr 10, 2013 at 3:06 PM, Ulf Hansson <ulf.hansson at stericsson.com> wrote:

> From: Mats Fagerstrom <mats.fagerstrom at stericsson.com>
>
> When reading the cpu speed, round it to the closest available
> frequency from the table.
>
> Signed-off-by: Ulf Hansson <ulf.hansson at linaro.org>
> Signed-off-by: Mats Fagerstrom <mats.fagerstrom at stericsson.com>

(...)
> +       /* The value is rounded to closest frequency in the defined table. */
> +       while (freq_table[i + 1].frequency != CPUFREQ_TABLE_END) {
> +               if (freq < freq_table[i].frequency +
> +                  (freq_table[i + 1].frequency - freq_table[i].frequency) / 2)
>                         return freq_table[i].frequency;

Oh that works, clever.

Acked-by: Linus Walleij <linus.walleij at linaro.org>

Yours,
Linus Walleij


From swarren at wwwdotorg.org  Thu Apr 11 16:38:21 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Thu, 11 Apr 2013 14:38:21 -0600
Subject: [PATCH V2] video: implement a simple framebuffer driver
In-Reply-To: <1828875.4dYa7WRt67@avalon>
References: <1365043183-28905-1-git-send-email-swarren@wwwdotorg.org>
 <2569832.XQDrhUGNaI@avalon> <5166DF99.2000308@wwwdotorg.org>
 <1828875.4dYa7WRt67@avalon>
Message-ID: <51671F3D.5040501@wwwdotorg.org>

On 04/11/2013 02:06 PM, Laurent Pinchart wrote:
> Hi Stephen,
> 
> On Thursday 11 April 2013 10:06:49 Stephen Warren wrote:
>> On 04/11/2013 03:56 AM, Laurent Pinchart wrote:
>>> On Monday 08 April 2013 17:16:37 Andrew Morton wrote:
>>>> On Wed,  3 Apr 2013 20:39:43 -0600 Stephen Warren wrote:
>>>>> A simple frame-buffer describes a raw memory region that may be rendered
>>>>> to, with the assumption that the display hardware has already been set
>>>>> up to scan out from that buffer.
>>>>>
>>>>> This is useful in cases where a bootloader exists and has set up the
>>>>> display hardware, but a Linux driver doesn't yet exist for the display
>>>>> hardware.
>>>>>
>>>>> ...
>>>>>
>>>>> +config FB_SIMPLE
>>>>> +	bool "Simple framebuffer support"
>>>>> +	depends on (FB = y) && OF
>>>>
>>>> It's sad that this simple little thing requires Open Firmware.  Could
>>>> it be generalised in some way so that the small amount of setup info
>>>> could be provided by other means (eg, module_param) or does the
>>>> dependency go deeper than that?
>>>
>>> I second that request. I like the idea of a simple framebuffer driver if
>>> it helps deprecating fbdev in the long term, but I don't want it to offer
>>> an excuse not to implement a DRM/KMS driver. In particular adding DT
>>> bindings would force us to keep supporting the ABI for a (too) long time.
>>
>> The platforms I intend to use this with only support device tree. Adding
>> support for platform data right now would just be dead code. If somebody
>> wants to use this driver with a board file based system rather than a DT
>> based system, it would be trivial do modify the driver to add a platform
>> data structure at that time.
> 
> What about using module parameters instead of DT bindings and platform data ? 
> As this is a hack designed to work around the lack of a proper display driver 
> the frame buffer address and size could just be passed by the boot loader 
> through the kernel command line, and the device would then be instantiated by 
> the driver.

I'm afraid I strongly dislike the idea of using module parameters. One
of the things that I dislike the most about NVIDIA's downstream Android
kernels is the huge number of random parameters that are required on the
kernel command-line just to get it to boot.

I'd specifically prefer the configuration for this driver to be a device
tree binding so that it /is/ an ABI. That way, arbitrary software that
boots the Linux kernel will be able to target a common standard for how
to pass this information to the kernel. If we move to module parameters
instead, especially with the specific intent that the format of those
parameters is no longer an ABI, we run in to issues where a new kernel
requires a bootloader update in order to generate the new set of module
parameters that are required by the driver. If we say the module
parameters will never change except in a backwards-compatible fashion,
and hence that issue won't arise, then why not just make it a DT binding?

Do module parameters handle the case of multiple device instances?

Also, I really don't see this driver as a hack. It's a perfectly
reasonable situation to have some other SW set up the frame-buffer, and
Linux simply continue to use it. Perhaps that other SW even ran on a
difference CPU, or the parameters are hard-coded in HW design, and so
there's no HW that Linux ever could drive, so it just isn't possible to
create any more advanced driver.


From gregory.clement at free-electrons.com  Thu Apr 11 16:41:34 2013
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Thu, 11 Apr 2013 22:41:34 +0200
Subject: [PATCH v3 4/9] ARM: mvebu: Enable pj4b on LPAE compilations
In-Reply-To: <20130411180844.GO28693@titan.lakedaemon.net>
References: <1365461538-30702-1-git-send-email-gregory.clement@free-electrons.com>
 <1365461538-30702-5-git-send-email-gregory.clement@free-electrons.com>
 <20130411180844.GO28693@titan.lakedaemon.net>
Message-ID: <51671FFE.1010909@free-electrons.com>

Hi Jason,

On 04/11/2013 08:08 PM, Jason Cooper wrote:
> On Tue, Apr 09, 2013 at 12:52:12AM +0200, Gregory CLEMENT wrote:
>> From: Lior Amsalem <alior at marvell.com>
>>
>> pj4b cpus are LPAE capable so enable them on LPAE compilations
>>
>> Signed-off-by: Lior Amsalem <alior at marvell.com>
>> Tested-by: Franklin <flin at marvell.com>
>> Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
>> ---
>>  arch/arm/mm/proc-v7.S |    3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> Applied to mvebu/soc
> 
> thx,
> 
> Jason.
> 

First thanks for pulling all these patches.

However, this one should go through Russell's git tree.  Or at least
you need his acked-by. I have already submit this patch on Russell
patch system. Unfortunately Russell told that he will be away for
around one week.

This patch is needed to have LPAE support, but all the other patches
don't depend on it. That means that if you applied all the other
patches it won't break anything even if at the end this patch is not
merged. But I really hope that Russell will be able to apply this
patch to his git tree.

Thanks

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From arnd at arndb.de  Thu Apr 11 16:42:03 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 11 Apr 2013 22:42:03 +0200
Subject: [PATCH v2] spi: s3c64xx: move to generic dmaengine API
In-Reply-To: <20130411165536.GO9243@opensource.wolfsonmicro.com>
References: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
 <1365638712-1028578-30-git-send-email-arnd@arndb.de>
 <20130411165536.GO9243@opensource.wolfsonmicro.com>
Message-ID: <201304112242.03252.arnd@arndb.de>

The spi-s3c64xx uses a Samsung proprietary interface for
talking to the DMA engine, which does not work with
multiplatform kernels.

This version of the patch leaves the old code in place,
behind an #ifdef. This can be removed in the future,
after the s3c64xx platform start supporting the regular
dmaengine interface. An earlier version of this patch was
tested successfully on exynos5250 by Padma Venkat.

The conversion was rather mechanical, since the samsung
interface is just a shallow wrapper around the dmaengine
interface.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Cc: spi-devel-general at lists.sourceforge.net
Cc: Mark Brown <broonie at opensource.wolfsonmicro.com>
Cc: Grant Likely <grant.likely at secretlab.ca>
Cc: Padma Venkat <padma.kvr at gmail.com>
----

v2: rebased to git://git.kernel.org/pub/scm/linux/kernel/git/broonie/misc.git spi-next

diff --git a/arch/arm/plat-samsung/devs.c b/arch/arm/plat-samsung/devs.c
index 51afedd..03db14d 100644
--- a/arch/arm/plat-samsung/devs.c
+++ b/arch/arm/plat-samsung/devs.c
@@ -10,6 +10,7 @@
  * published by the Free Software Foundation.
 */
 
+#include <linux/amba/pl330.h>
 #include <linux/kernel.h>
 #include <linux/types.h>
 #include <linux/interrupt.h>
@@ -1552,6 +1553,9 @@ void __init s3c64xx_spi0_set_platdata(int (*cfg_gpio)(void), int src_clk_nr,
 	pd.num_cs = num_cs;
 	pd.src_clk_nr = src_clk_nr;
 	pd.cfg_gpio = (cfg_gpio) ? cfg_gpio : s3c64xx_spi0_cfg_gpio;
+#ifdef CONFIG_PL330_DMA
+	pd.filter = pl330_filter;
+#endif
 
 	s3c_set_platdata(&pd, sizeof(pd), &s3c64xx_device_spi0);
 }
@@ -1590,6 +1594,9 @@ void __init s3c64xx_spi1_set_platdata(int (*cfg_gpio)(void), int src_clk_nr,
 	pd.num_cs = num_cs;
 	pd.src_clk_nr = src_clk_nr;
 	pd.cfg_gpio = (cfg_gpio) ? cfg_gpio : s3c64xx_spi1_cfg_gpio;
+#ifdef CONFIG_PL330_DMA
+	pd.filter = pl330_filter;
+#endif
 
 	s3c_set_platdata(&pd, sizeof(pd), &s3c64xx_device_spi1);
 }
@@ -1628,6 +1635,9 @@ void __init s3c64xx_spi2_set_platdata(int (*cfg_gpio)(void), int src_clk_nr,
 	pd.num_cs = num_cs;
 	pd.src_clk_nr = src_clk_nr;
 	pd.cfg_gpio = (cfg_gpio) ? cfg_gpio : s3c64xx_spi2_cfg_gpio;
+#ifdef CONFIG_PL330_DMA
+	pd.filter = pl330_filter;
+#endif
 
 	s3c_set_platdata(&pd, sizeof(pd), &s3c64xx_device_spi2);
 }
diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index 682b1e7..4989aeb 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -24,6 +24,7 @@
 #include <linux/delay.h>
 #include <linux/clk.h>
 #include <linux/dma-mapping.h>
+#include <linux/dmaengine.h>
 #include <linux/platform_device.h>
 #include <linux/pm_runtime.h>
 #include <linux/spi/spi.h>
@@ -31,9 +32,12 @@
 #include <linux/of.h>
 #include <linux/of_gpio.h>
 
-#include <mach/dma.h>
 #include <linux/platform_data/spi-s3c64xx.h>
 
+#ifdef CONFIG_SAMSUNG_DMADEV
+#include <mach/dma.h>
+#endif
+
 #define MAX_SPI_PORTS		3
 
 /* Registers and bit-fields */
@@ -131,9 +135,9 @@
 #define TXBUSY    (1<<3)
 
 struct s3c64xx_spi_dma_data {
-	unsigned		ch;
+	struct dma_chan *ch;
 	enum dma_transfer_direction direction;
-	enum dma_ch	dmach;
+	unsigned int dmach;
 };
 
 /**
@@ -195,16 +199,14 @@ struct s3c64xx_spi_driver_data {
 	unsigned                        cur_speed;
 	struct s3c64xx_spi_dma_data	rx_dma;
 	struct s3c64xx_spi_dma_data	tx_dma;
+#ifdef CONFIG_SAMSUNG_DMADEV
 	struct samsung_dma_ops		*ops;
+#endif
 	struct s3c64xx_spi_port_config	*port_conf;
 	unsigned int			port_id;
 	unsigned long			gpios[4];
 };
 
-static struct s3c2410_dma_client s3c64xx_spi_dma_client = {
-	.name = "samsung-spi-dma",
-};
-
 static void flush_fifo(struct s3c64xx_spi_driver_data *sdd)
 {
 	void __iomem *regs = sdd->regs;
@@ -281,6 +283,13 @@ static void s3c64xx_spi_dmacb(void *data)
 	spin_unlock_irqrestore(&sdd->lock, flags);
 }
 
+#ifdef CONFIG_SAMSUNG_DMADEV
+/* FIXME: remove this section once arch/arm/mach-s3c64xx uses dmaengine */
+
+static struct s3c2410_dma_client s3c64xx_spi_dma_client = {
+	.name = "samsung-spi-dma",
+};
+
 static void prepare_dma(struct s3c64xx_spi_dma_data *dma,
 					unsigned len, dma_addr_t buf)
 {
@@ -294,14 +303,14 @@ static void prepare_dma(struct s3c64xx_spi_dma_data *dma,
 		config.direction = sdd->rx_dma.direction;
 		config.fifo = sdd->sfr_start + S3C64XX_SPI_RX_DATA;
 		config.width = sdd->cur_bpw / 8;
-		sdd->ops->config(sdd->rx_dma.ch, &config);
+		sdd->ops->config((enum dma_ch)sdd->rx_dma.ch, &config);
 	} else {
 		sdd = container_of((void *)dma,
 			struct s3c64xx_spi_driver_data, tx_dma);
 		config.direction =  sdd->tx_dma.direction;
 		config.fifo = sdd->sfr_start + S3C64XX_SPI_TX_DATA;
 		config.width = sdd->cur_bpw / 8;
-		sdd->ops->config(sdd->tx_dma.ch, &config);
+		sdd->ops->config((enum dma_ch)sdd->tx_dma.ch, &config);
 	}
 
 	info.cap = DMA_SLAVE;
@@ -311,8 +320,8 @@ static void prepare_dma(struct s3c64xx_spi_dma_data *dma,
 	info.direction = dma->direction;
 	info.buf = buf;
 
-	sdd->ops->prepare(dma->ch, &info);
-	sdd->ops->trigger(dma->ch);
+	sdd->ops->prepare((enum dma_ch)dma->ch, &info);
+	sdd->ops->trigger((enum dma_ch)dma->ch);
 }
 
 static int acquire_dma(struct s3c64xx_spi_driver_data *sdd)
@@ -325,12 +334,126 @@ static int acquire_dma(struct s3c64xx_spi_driver_data *sdd)
 	req.cap = DMA_SLAVE;
 	req.client = &s3c64xx_spi_dma_client;
 
-	sdd->rx_dma.ch = sdd->ops->request(sdd->rx_dma.dmach, &req, dev, "rx");
-	sdd->tx_dma.ch = sdd->ops->request(sdd->tx_dma.dmach, &req, dev, "tx");
+	sdd->rx_dma.ch = (void *)sdd->ops->request(sdd->rx_dma.dmach, &req, dev, "rx");
+	sdd->tx_dma.ch = (void *)sdd->ops->request(sdd->tx_dma.dmach, &req, dev, "tx");
 
 	return 1;
 }
 
+static int s3c64xx_spi_prepare_transfer(struct spi_master *spi)
+{
+	struct s3c64xx_spi_driver_data *sdd = spi_master_get_devdata(spi);
+
+	/* Acquire DMA channels */
+	while (!acquire_dma(sdd))
+		usleep_range(10000, 11000);
+
+	pm_runtime_get_sync(&sdd->pdev->dev);
+
+	return 0;
+}
+
+static int s3c64xx_spi_unprepare_transfer(struct spi_master *spi)
+{
+	struct s3c64xx_spi_driver_data *sdd = spi_master_get_devdata(spi);
+
+	/* Free DMA channels */
+	sdd->ops->release((enum dma_ch)sdd->rx_dma.ch, &s3c64xx_spi_dma_client);
+	sdd->ops->release((enum dma_ch)sdd->tx_dma.ch, &s3c64xx_spi_dma_client);
+
+	pm_runtime_put(&sdd->pdev->dev);
+
+	return 0;
+}
+
+static void s3c64xx_spi_dma_stop(struct s3c64xx_spi_driver_data *sdd,
+				 struct s3c64xx_spi_dma_data *dma)
+{
+	sdd->ops->stop((enum dma_ch)dma->ch);
+}
+#else
+
+static void prepare_dma(struct s3c64xx_spi_dma_data *dma,
+					unsigned len, dma_addr_t buf)
+{
+	struct s3c64xx_spi_driver_data *sdd;
+	struct dma_slave_config config;
+	struct scatterlist sg;
+	struct dma_async_tx_descriptor *desc;
+
+	if (dma->direction == DMA_DEV_TO_MEM) {
+		sdd = container_of((void *)dma,
+			struct s3c64xx_spi_driver_data, rx_dma);
+		config.direction = dma->direction;
+		config.src_addr = sdd->sfr_start + S3C64XX_SPI_RX_DATA;
+		config.src_addr_width = sdd->cur_bpw / 8;
+		config.src_maxburst = 1;
+		dmaengine_slave_config(dma->ch, &config);
+	} else {
+		sdd = container_of((void *)dma,
+			struct s3c64xx_spi_driver_data, tx_dma);
+		config.direction = dma->direction;
+		config.dst_addr = sdd->sfr_start + S3C64XX_SPI_TX_DATA;
+		config.dst_addr_width = sdd->cur_bpw / 8;
+		config.dst_maxburst = 1;
+		dmaengine_slave_config(dma->ch, &config);
+	}
+
+	sg_init_table(&sg, 1);
+	sg_dma_len(&sg) = len;
+	sg_set_page(&sg, pfn_to_page(PFN_DOWN(buf)),
+		    len, offset_in_page(buf));
+	sg_dma_address(&sg) = buf;
+
+	desc = dmaengine_prep_slave_sg(dma->ch,
+		&sg, 1, dma->direction, DMA_PREP_INTERRUPT);
+
+	desc->callback = s3c64xx_spi_dmacb;
+	desc->callback_param = dma;
+
+	dmaengine_submit(desc);
+	dma_async_issue_pending(dma->ch);
+}
+
+static int s3c64xx_spi_prepare_transfer(struct spi_master *spi)
+{
+	struct s3c64xx_spi_driver_data *sdd = spi_master_get_devdata(spi);
+	dma_filter_fn filter = sdd->cntrlr_info->filter;
+	struct device *dev = &sdd->pdev->dev;
+	dma_cap_mask_t mask;
+
+	dma_cap_zero(mask);
+	dma_cap_set(DMA_SLAVE, mask);
+
+	/* Acquire DMA channels */
+	sdd->rx_dma.ch = dma_request_slave_channel_compat(mask, filter,
+				(void*)sdd->rx_dma.dmach, dev, "rx");
+	sdd->tx_dma.ch = dma_request_slave_channel_compat(mask, filter,
+				(void*)sdd->tx_dma.dmach, dev, "tx");
+	pm_runtime_get_sync(&sdd->pdev->dev);
+
+	return 0;
+}
+
+static int s3c64xx_spi_unprepare_transfer(struct spi_master *spi)
+{
+	struct s3c64xx_spi_driver_data *sdd = spi_master_get_devdata(spi);
+
+	/* Free DMA channels */
+	dma_release_channel(sdd->rx_dma.ch);
+	dma_release_channel(sdd->tx_dma.ch);
+
+	pm_runtime_put(&sdd->pdev->dev);
+	return 0;
+}
+
+static void s3c64xx_spi_dma_stop(struct s3c64xx_spi_driver_data *sdd,
+				 struct s3c64xx_spi_dma_data *dma)
+{
+	dmaengine_terminate_all(dma->ch);
+}
+#endif
+
 static void enable_datapath(struct s3c64xx_spi_driver_data *sdd,
 				struct spi_device *spi,
 				struct spi_transfer *xfer, int dma_mode)
@@ -713,9 +836,9 @@ static int s3c64xx_spi_transfer_one_message(struct spi_master *master,
 		}
 
 		/* Polling method for xfers not bigger than FIFO capacity */
-		if (xfer->len <= ((FIFO_LVL_MASK(sdd) >> 1) + 1))
-			use_dma = 0;
-		else
+		use_dma = 0;
+		if (sdd->rx_dma.ch && sdd->tx_dma.ch &&
+		    (xfer->len > ((FIFO_LVL_MASK(sdd) >> 1) + 1)))
 			use_dma = 1;
 
 		spin_lock_irqsave(&sdd->lock, flags);
@@ -750,10 +873,10 @@ static int s3c64xx_spi_transfer_one_message(struct spi_master *master,
 			if (use_dma) {
 				if (xfer->tx_buf != NULL
 						&& (sdd->state & TXBUSY))
-					sdd->ops->stop(sdd->tx_dma.ch);
+					s3c64xx_spi_dma_stop(sdd, &sdd->tx_dma);
 				if (xfer->rx_buf != NULL
 						&& (sdd->state & RXBUSY))
-					sdd->ops->stop(sdd->rx_dma.ch);
+					s3c64xx_spi_dma_stop(sdd, &sdd->rx_dma);
 			}
 
 			goto out;
@@ -790,32 +913,6 @@ out:
 	return 0;
 }
 
-static int s3c64xx_spi_prepare_transfer(struct spi_master *spi)
-{
-	struct s3c64xx_spi_driver_data *sdd = spi_master_get_devdata(spi);
-
-	/* Acquire DMA channels */
-	while (!acquire_dma(sdd))
-		usleep_range(10000, 11000);
-
-	pm_runtime_get_sync(&sdd->pdev->dev);
-
-	return 0;
-}
-
-static int s3c64xx_spi_unprepare_transfer(struct spi_master *spi)
-{
-	struct s3c64xx_spi_driver_data *sdd = spi_master_get_devdata(spi);
-
-	/* Free DMA channels */
-	sdd->ops->release(sdd->rx_dma.ch, &s3c64xx_spi_dma_client);
-	sdd->ops->release(sdd->tx_dma.ch, &s3c64xx_spi_dma_client);
-
-	pm_runtime_put(&sdd->pdev->dev);
-
-	return 0;
-}
-
 static struct s3c64xx_spi_csinfo *s3c64xx_get_slave_ctrldata(
 				struct spi_device *spi)
 {
diff --git a/include/linux/platform_data/spi-s3c64xx.h b/include/linux/platform_data/spi-s3c64xx.h
index ceba18d..8447f63 100644
--- a/include/linux/platform_data/spi-s3c64xx.h
+++ b/include/linux/platform_data/spi-s3c64xx.h
@@ -11,6 +11,8 @@
 #ifndef __S3C64XX_PLAT_SPI_H
 #define __S3C64XX_PLAT_SPI_H
 
+#include <linux/dmaengine.h>
+
 struct platform_device;
 
 /**
@@ -38,6 +40,7 @@ struct s3c64xx_spi_info {
 	int src_clk_nr;
 	int num_cs;
 	int (*cfg_gpio)(void);
+	dma_filter_fn filter;
 };
 
 /**


From daniel.lezcano at linaro.org  Thu Apr 11 16:42:30 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Thu, 11 Apr 2013 22:42:30 +0200
Subject: [V2 patch 00/19] cpuidle: code consolidation
Message-ID: <1365712969-7541-1-git-send-email-daniel.lezcano@linaro.org>

This patchset series provide some code consolidation across the different
cpuidle drivers. It contains two parts, the first one is the removal of
the time keeping flag and the second one, is a common initialization routine.

All the drivers use the en_core_tk_irqen flag, which means it is not necessary
to make the time computation optional. We can remove this flag and assume the
cpuidle framework always manage this operation.

The cpuidle code initialization is duplicated across the different drivers in
the same manner.

The repeating pattern is:

SMP:

cpuidle_register_driver(drv);
for_each_possible_cpu(cpu) {
        dev = per_cpu(cpuidle_device, cpu);
        cpuidle_register_device(dev);
}

UP:

cpuidle_register_driver(drv);
cpuidle_register_device(dev);

As on a UP machine the macro 'for_each_cpu' is a one iteration loop, using the
initialization loop from SMP to UP works.

The patchset does some cleanup for different drivers in order to make the init
code the same. Then it introduces a generic function:

  cpuidle_register(struct cpuidle_driver *drv, struct cpumask *cpumask)

The cpumask is for the coupled idle states.

The drivers are then modified to take into account this new function and
to remove the duplicated code.

The benefit is observable in the diffstat: 332 lines of code removed.

Tested-on: u8500
Tested-on: at91
Tested-on: intel i5
Tested-on: OMAP4

Compiled with and without CPU_IDLE for:
 u8500, at91, davinci, exynos, imx5, imx6, kirkwood, multi_v7 (for calxeda),
 omap2plus, s3c64, tegra1, tegra2, tegra3

Daniel Lezcano (19):
  ARM: shmobile: cpuidle: remove shmobile_enter_wfi function
  ARM: OMAP3: remove cpuidle_wrap_enter
  cpuidle: remove en_core_tk_irqen flag
  ARM: ux500: cpuidle: replace for_each_online_cpu by
    for_each_possible_cpu
  ARM: imx: cpuidle: create separate drivers for imx5/imx6
  cpuidle: make a single register function for all
  ARM: ux500: cpuidle: use init/exit common routine
  ARM: at91: cpuidle: use init/exit common routine
  ARM: OMAP3: cpuidle: use init/exit common routine
  ARM: s3c64xx: cpuidle: use init/exit common routine
  ARM: tegra: cpuidle: use init/exit common routine
  ARM: shmobile: cpuidle: use init/exit common routine
  ARM: OMAP4: cpuidle: use init/exit common routine
  ARM: tegra: cpuidle: use init/exit common routine for tegra2
  ARM: tegra: cpuidle: use init/exit common routine for tegra3
  ARM: calxeda: cpuidle: use init/exit common routine
  ARM: kirkwood: cpuidle: use init/exit common routine
  ARM: davinci: cpuidle: use init/exit common routine
  ARM: imx: cpuidle: use init/exit common routine

 Documentation/cpuidle/driver.txt                |    6 +
 arch/arm/mach-at91/cpuidle.c                    |   18 +--
 arch/arm/mach-davinci/cpuidle.c                 |   21 +---
 arch/arm/mach-exynos/cpuidle.c                  |    1 -
 arch/arm/mach-imx/Makefile                      |    1 +
 arch/arm/mach-imx/cpuidle-imx5.c                |   40 +++++++
 arch/arm/mach-imx/cpuidle-imx6q.c               |    3 +-
 arch/arm/mach-imx/cpuidle.c                     |   80 -------------
 arch/arm/mach-imx/cpuidle.h                     |   10 +-
 arch/arm/mach-imx/pm-imx5.c                     |   30 +----
 arch/arm/mach-omap2/cpuidle34xx.c               |   49 ++------
 arch/arm/mach-omap2/cpuidle44xx.c               |   23 +---
 arch/arm/mach-s3c64xx/cpuidle.c                 |   15 +--
 arch/arm/mach-shmobile/cpuidle.c                |   11 +-
 arch/arm/mach-shmobile/include/mach/common.h    |    3 -
 arch/arm/mach-shmobile/pm-sh7372.c              |    2 -
 arch/arm/mach-tegra/cpuidle-tegra114.c          |   27 +----
 arch/arm/mach-tegra/cpuidle-tegra20.c           |   31 +----
 arch/arm/mach-tegra/cpuidle-tegra30.c           |   28 +----
 arch/arm/mach-ux500/cpuidle.c                   |   33 +-----
 arch/powerpc/platforms/pseries/processor_idle.c |    1 -
 arch/sh/kernel/cpu/shmobile/cpuidle.c           |    1 -
 arch/x86/kernel/apm_32.c                        |    1 -
 drivers/acpi/processor_idle.c                   |    1 -
 drivers/cpuidle/cpuidle-calxeda.c               |   53 +--------
 drivers/cpuidle/cpuidle-kirkwood.c              |   18 +--
 drivers/cpuidle/cpuidle.c                       |  144 ++++++++++++++---------
 drivers/idle/intel_idle.c                       |    1 -
 include/linux/cpuidle.h                         |   20 ++--
 29 files changed, 175 insertions(+), 497 deletions(-)
 create mode 100644 arch/arm/mach-imx/cpuidle-imx5.c
 delete mode 100644 arch/arm/mach-imx/cpuidle.c

-- 
1.7.9.5



From daniel.lezcano at linaro.org  Thu Apr 11 16:42:32 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Thu, 11 Apr 2013 22:42:32 +0200
Subject: [V2 patch 02/19] ARM: OMAP3: remove cpuidle_wrap_enter
In-Reply-To: <1365712969-7541-1-git-send-email-daniel.lezcano@linaro.org>
References: <1365712969-7541-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1365712969-7541-3-git-send-email-daniel.lezcano@linaro.org>

In a previous commit the en_core_tk_irqen flag has been added but we missed
the cpuidle_wrap_enter which was doing the job to measure the time for the
'omap3_enter_idle' function.

Actually, I don't see any reason to use this wrapper in the code. In the better
case, the time computation is not correctly done because of the different
operations done in omap3_enter_idle_bm which were not taken into account
before the en_core_tk_irqen flag was set.

As the time is reflected for the state overridden by the omap3_enter_idle_bm,
using the wrapper is pointless now, so removing it.

Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
---
 arch/arm/mach-omap2/cpuidle34xx.c |   30 +++++++++---------------------
 1 file changed, 9 insertions(+), 21 deletions(-)

diff --git a/arch/arm/mach-omap2/cpuidle34xx.c b/arch/arm/mach-omap2/cpuidle34xx.c
index 4f67a5b..a56310a 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -99,11 +99,15 @@ static struct omap3_idle_statedata omap3_idle_data[] = {
 	},
 };
 
-/* Private functions */
-
-static int __omap3_enter_idle(struct cpuidle_device *dev,
-				struct cpuidle_driver *drv,
-				int index)
+/**
+ * omap3_enter_idle - Programs OMAP3 to enter the specified state
+ * @dev: cpuidle device
+ * @drv: cpuidle driver
+ * @index: the index of state to be entered
+ */
+static int omap3_enter_idle(struct cpuidle_device *dev,
+			    struct cpuidle_driver *drv,
+			    int index)
 {
 	struct omap3_idle_statedata *cx = &omap3_idle_data[index];
 
@@ -149,22 +153,6 @@ return_sleep_time:
 }
 
 /**
- * omap3_enter_idle - Programs OMAP3 to enter the specified state
- * @dev: cpuidle device
- * @drv: cpuidle driver
- * @index: the index of state to be entered
- *
- * Called from the CPUidle framework to program the device to the
- * specified target state selected by the governor.
- */
-static inline int omap3_enter_idle(struct cpuidle_device *dev,
-				struct cpuidle_driver *drv,
-				int index)
-{
-	return cpuidle_wrap_enter(dev, drv, index, __omap3_enter_idle);
-}
-
-/**
  * next_valid_state - Find next valid C-state
  * @dev: cpuidle device
  * @drv: cpuidle driver
-- 
1.7.9.5



From daniel.lezcano at linaro.org  Thu Apr 11 16:42:34 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Thu, 11 Apr 2013 22:42:34 +0200
Subject: [V2 patch 04/19] ARM: ux500: cpuidle: replace for_each_online_cpu by
 for_each_possible_cpu
In-Reply-To: <1365712969-7541-1-git-send-email-daniel.lezcano@linaro.org>
References: <1365712969-7541-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1365712969-7541-5-git-send-email-daniel.lezcano@linaro.org>

All the drivers are using, in their initialization function, the
for_each_possible_cpu macro.

Using for_each_online_cpu means the driver must handle the initialization
of the cpuidle device when a cpu is up which is not the case here.

Change the macro to for_each_possible_cpu as that fix the hotplug
initialization and make the initialization routine consistent with the
rest of the code in the different drivers.

Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
---
 arch/arm/mach-ux500/cpuidle.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-ux500/cpuidle.c b/arch/arm/mach-ux500/cpuidle.c
index c29c1bf..5657d4a 100644
--- a/arch/arm/mach-ux500/cpuidle.c
+++ b/arch/arm/mach-ux500/cpuidle.c
@@ -125,7 +125,7 @@ int __init ux500_idle_init(void)
 		return ret;
 	}
 
-	for_each_online_cpu(cpu) {
+	for_each_possible(cpu) {
 		device = &per_cpu(ux500_cpuidle_device, cpu);
 		device->cpu = cpu;
 		ret = cpuidle_register_device(device);
@@ -139,7 +139,7 @@ out:
 	return ret;
 
 out_unregister:
-	for_each_online_cpu(cpu) {
+	for_each_possible_cpu(cpu) {
 		device = &per_cpu(ux500_cpuidle_device, cpu);
 		cpuidle_unregister_device(device);
 	}
-- 
1.7.9.5



From daniel.lezcano at linaro.org  Thu Apr 11 16:42:33 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Thu, 11 Apr 2013 22:42:33 +0200
Subject: [V2 patch 03/19] cpuidle: remove en_core_tk_irqen flag
In-Reply-To: <1365712969-7541-1-git-send-email-daniel.lezcano@linaro.org>
References: <1365712969-7541-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1365712969-7541-4-git-send-email-daniel.lezcano@linaro.org>

The en_core_tk_irqen flag is set in all the cpuidle driver which
means it is not necessary to specify this flag.

Remove the flag and the code related to it.

Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
---
 arch/arm/mach-at91/cpuidle.c                    |    1 -
 arch/arm/mach-davinci/cpuidle.c                 |    1 -
 arch/arm/mach-exynos/cpuidle.c                  |    1 -
 arch/arm/mach-imx/cpuidle-imx6q.c               |    1 -
 arch/arm/mach-imx/pm-imx5.c                     |    1 -
 arch/arm/mach-omap2/cpuidle34xx.c               |    1 -
 arch/arm/mach-omap2/cpuidle44xx.c               |    1 -
 arch/arm/mach-s3c64xx/cpuidle.c                 |    1 -
 arch/arm/mach-shmobile/cpuidle.c                |    1 -
 arch/arm/mach-shmobile/pm-sh7372.c              |    1 -
 arch/arm/mach-tegra/cpuidle-tegra114.c          |    1 -
 arch/arm/mach-tegra/cpuidle-tegra20.c           |    1 -
 arch/arm/mach-tegra/cpuidle-tegra30.c           |    1 -
 arch/arm/mach-ux500/cpuidle.c                   |    1 -
 arch/powerpc/platforms/pseries/processor_idle.c |    1 -
 arch/sh/kernel/cpu/shmobile/cpuidle.c           |    1 -
 arch/x86/kernel/apm_32.c                        |    1 -
 drivers/acpi/processor_idle.c                   |    1 -
 drivers/cpuidle/cpuidle-calxeda.c               |    1 -
 drivers/cpuidle/cpuidle-kirkwood.c              |    1 -
 drivers/cpuidle/cpuidle.c                       |   72 ++++++-----------------
 drivers/idle/intel_idle.c                       |    1 -
 include/linux/cpuidle.h                         |   11 ----
 23 files changed, 18 insertions(+), 86 deletions(-)

diff --git a/arch/arm/mach-at91/cpuidle.c b/arch/arm/mach-at91/cpuidle.c
index 0c63815..0130df7 100644
--- a/arch/arm/mach-at91/cpuidle.c
+++ b/arch/arm/mach-at91/cpuidle.c
@@ -47,7 +47,6 @@ static int at91_enter_idle(struct cpuidle_device *dev,
 static struct cpuidle_driver at91_idle_driver = {
 	.name			= "at91_idle",
 	.owner			= THIS_MODULE,
-	.en_core_tk_irqen	= 1,
 	.states[0]		= ARM_CPUIDLE_WFI_STATE,
 	.states[1]		= {
 		.enter			= at91_enter_idle,
diff --git a/arch/arm/mach-davinci/cpuidle.c b/arch/arm/mach-davinci/cpuidle.c
index 22d6d4a..c2887c5 100644
--- a/arch/arm/mach-davinci/cpuidle.c
+++ b/arch/arm/mach-davinci/cpuidle.c
@@ -62,7 +62,6 @@ static int davinci_enter_idle(struct cpuidle_device *dev,
 static struct cpuidle_driver davinci_idle_driver = {
 	.name			= "cpuidle-davinci",
 	.owner			= THIS_MODULE,
-	.en_core_tk_irqen	= 1,
 	.states[0]		= ARM_CPUIDLE_WFI_STATE,
 	.states[1]		= {
 		.enter			= davinci_enter_idle,
diff --git a/arch/arm/mach-exynos/cpuidle.c b/arch/arm/mach-exynos/cpuidle.c
index fcfe025..498a7a2 100644
--- a/arch/arm/mach-exynos/cpuidle.c
+++ b/arch/arm/mach-exynos/cpuidle.c
@@ -58,7 +58,6 @@ static DEFINE_PER_CPU(struct cpuidle_device, exynos4_cpuidle_device);
 static struct cpuidle_driver exynos4_idle_driver = {
 	.name			= "exynos4_idle",
 	.owner			= THIS_MODULE,
-	.en_core_tk_irqen	= 1,
 };
 
 /* Ext-GIC nIRQ/nFIQ is the only wakeup source in AFTR */
diff --git a/arch/arm/mach-imx/cpuidle-imx6q.c b/arch/arm/mach-imx/cpuidle-imx6q.c
index a783a63..e2739ad 100644
--- a/arch/arm/mach-imx/cpuidle-imx6q.c
+++ b/arch/arm/mach-imx/cpuidle-imx6q.c
@@ -45,7 +45,6 @@ done:
 static struct cpuidle_driver imx6q_cpuidle_driver = {
 	.name = "imx6q_cpuidle",
 	.owner = THIS_MODULE,
-	.en_core_tk_irqen = 1,
 	.states = {
 		/* WFI */
 		ARM_CPUIDLE_WFI_STATE,
diff --git a/arch/arm/mach-imx/pm-imx5.c b/arch/arm/mach-imx/pm-imx5.c
index f67fd7e..4b52b3e 100644
--- a/arch/arm/mach-imx/pm-imx5.c
+++ b/arch/arm/mach-imx/pm-imx5.c
@@ -164,7 +164,6 @@ static int imx5_cpuidle_enter(struct cpuidle_device *dev,
 static struct cpuidle_driver imx5_cpuidle_driver = {
 	.name			= "imx5_cpuidle",
 	.owner			= THIS_MODULE,
-	.en_core_tk_irqen	= 1,
 	.states[0]	= {
 		.enter			= imx5_cpuidle_enter,
 		.exit_latency		= 2,
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c b/arch/arm/mach-omap2/cpuidle34xx.c
index a56310a..027a787 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -264,7 +264,6 @@ static DEFINE_PER_CPU(struct cpuidle_device, omap3_idle_dev);
 static struct cpuidle_driver omap3_idle_driver = {
 	.name             = "omap3_idle",
 	.owner            = THIS_MODULE,
-	.en_core_tk_irqen = 1,
 	.states = {
 		{
 			.enter		  = omap3_enter_idle_bm,
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c b/arch/arm/mach-omap2/cpuidle44xx.c
index f4b1b23..cd188de 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -162,7 +162,6 @@ static DEFINE_PER_CPU(struct cpuidle_device, omap4_idle_dev);
 static struct cpuidle_driver omap4_idle_driver = {
 	.name				= "omap4_idle",
 	.owner				= THIS_MODULE,
-	.en_core_tk_irqen		= 1,
 	.states = {
 		{
 			/* C1 - CPU0 ON + CPU1 ON + MPU ON */
diff --git a/arch/arm/mach-s3c64xx/cpuidle.c b/arch/arm/mach-s3c64xx/cpuidle.c
index ead5fab..852ff16 100644
--- a/arch/arm/mach-s3c64xx/cpuidle.c
+++ b/arch/arm/mach-s3c64xx/cpuidle.c
@@ -45,7 +45,6 @@ static DEFINE_PER_CPU(struct cpuidle_device, s3c64xx_cpuidle_device);
 static struct cpuidle_driver s3c64xx_cpuidle_driver = {
 	.name	= "s3c64xx_cpuidle",
 	.owner  = THIS_MODULE,
-	.en_core_tk_irqen = 1,
 	.states = {
 		{
 			.enter            = s3c64xx_enter_idle,
diff --git a/arch/arm/mach-shmobile/cpuidle.c b/arch/arm/mach-shmobile/cpuidle.c
index c872ae8..d671ae9 100644
--- a/arch/arm/mach-shmobile/cpuidle.c
+++ b/arch/arm/mach-shmobile/cpuidle.c
@@ -20,7 +20,6 @@ static struct cpuidle_device shmobile_cpuidle_dev;
 static struct cpuidle_driver shmobile_cpuidle_default_driver = {
 	.name			= "shmobile_cpuidle",
 	.owner			= THIS_MODULE,
-	.en_core_tk_irqen	= 1,
 	.states[0]		= ARM_CPUIDLE_WFI_STATE,
 	.safe_state_index	= 0, /* C1 */
 	.state_count		= 1,
diff --git a/arch/arm/mach-shmobile/pm-sh7372.c b/arch/arm/mach-shmobile/pm-sh7372.c
index fbef7b9..dec9293 100644
--- a/arch/arm/mach-shmobile/pm-sh7372.c
+++ b/arch/arm/mach-shmobile/pm-sh7372.c
@@ -410,7 +410,6 @@ static int sh7372_enter_a4s(struct cpuidle_device *dev,
 static struct cpuidle_driver sh7372_cpuidle_driver = {
 	.name			= "sh7372_cpuidle",
 	.owner			= THIS_MODULE,
-	.en_core_tk_irqen	= 1,
 	.state_count		= 5,
 	.safe_state_index	= 0, /* C1 */
 	.states[0] = ARM_CPUIDLE_WFI_STATE,
diff --git a/arch/arm/mach-tegra/cpuidle-tegra114.c b/arch/arm/mach-tegra/cpuidle-tegra114.c
index c527cff..c5fadf9 100644
--- a/arch/arm/mach-tegra/cpuidle-tegra114.c
+++ b/arch/arm/mach-tegra/cpuidle-tegra114.c
@@ -23,7 +23,6 @@
 static struct cpuidle_driver tegra_idle_driver = {
 	.name = "tegra_idle",
 	.owner = THIS_MODULE,
-	.en_core_tk_irqen = 1,
 	.state_count = 1,
 	.states = {
 		[0] = ARM_CPUIDLE_WFI_STATE_PWR(600),
diff --git a/arch/arm/mach-tegra/cpuidle-tegra20.c b/arch/arm/mach-tegra/cpuidle-tegra20.c
index b94d76a..f1f6ac4 100644
--- a/arch/arm/mach-tegra/cpuidle-tegra20.c
+++ b/arch/arm/mach-tegra/cpuidle-tegra20.c
@@ -51,7 +51,6 @@ static int tegra20_idle_lp2_coupled(struct cpuidle_device *dev,
 static struct cpuidle_driver tegra_idle_driver = {
 	.name = "tegra_idle",
 	.owner = THIS_MODULE,
-	.en_core_tk_irqen = 1,
 	.states = {
 		ARM_CPUIDLE_WFI_STATE_PWR(600),
 #ifdef CONFIG_PM_SLEEP
diff --git a/arch/arm/mach-tegra/cpuidle-tegra30.c b/arch/arm/mach-tegra/cpuidle-tegra30.c
index c4e01fe..f6a0c72 100644
--- a/arch/arm/mach-tegra/cpuidle-tegra30.c
+++ b/arch/arm/mach-tegra/cpuidle-tegra30.c
@@ -43,7 +43,6 @@ static int tegra30_idle_lp2(struct cpuidle_device *dev,
 static struct cpuidle_driver tegra_idle_driver = {
 	.name = "tegra_idle",
 	.owner = THIS_MODULE,
-	.en_core_tk_irqen = 1,
 #ifdef CONFIG_PM_SLEEP
 	.state_count = 2,
 #else
diff --git a/arch/arm/mach-ux500/cpuidle.c b/arch/arm/mach-ux500/cpuidle.c
index 1b16d9e..c29c1bf 100644
--- a/arch/arm/mach-ux500/cpuidle.c
+++ b/arch/arm/mach-ux500/cpuidle.c
@@ -94,7 +94,6 @@ out:
 static struct cpuidle_driver ux500_idle_driver = {
 	.name = "ux500_idle",
 	.owner = THIS_MODULE,
-	.en_core_tk_irqen = 1,
 	.states = {
 		ARM_CPUIDLE_WFI_STATE,
 		{
diff --git a/arch/powerpc/platforms/pseries/processor_idle.c b/arch/powerpc/platforms/pseries/processor_idle.c
index a197120..4644efa0 100644
--- a/arch/powerpc/platforms/pseries/processor_idle.c
+++ b/arch/powerpc/platforms/pseries/processor_idle.c
@@ -25,7 +25,6 @@
 struct cpuidle_driver pseries_idle_driver = {
 	.name             = "pseries_idle",
 	.owner            = THIS_MODULE,
-	.en_core_tk_irqen = 1,
 };
 
 #define MAX_IDLE_STATE_COUNT	2
diff --git a/arch/sh/kernel/cpu/shmobile/cpuidle.c b/arch/sh/kernel/cpu/shmobile/cpuidle.c
index 1ddc876..0986f21 100644
--- a/arch/sh/kernel/cpu/shmobile/cpuidle.c
+++ b/arch/sh/kernel/cpu/shmobile/cpuidle.c
@@ -55,7 +55,6 @@ static struct cpuidle_device cpuidle_dev;
 static struct cpuidle_driver cpuidle_driver = {
 	.name			= "sh_idle",
 	.owner			= THIS_MODULE,
-	.en_core_tk_irqen	= 1,
 };
 
 void sh_mobile_setup_cpuidle(void)
diff --git a/arch/x86/kernel/apm_32.c b/arch/x86/kernel/apm_32.c
index 66b5faf..53a4e27 100644
--- a/arch/x86/kernel/apm_32.c
+++ b/arch/x86/kernel/apm_32.c
@@ -373,7 +373,6 @@ static int apm_cpu_idle(struct cpuidle_device *dev,
 static struct cpuidle_driver apm_idle_driver = {
 	.name = "apm_idle",
 	.owner = THIS_MODULE,
-	.en_core_tk_irqen = 1,
 	.states = {
 		{ /* entry 0 is for polling */ },
 		{ /* entry 1 is for APM idle */
diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c
index ee255c6..f0df2c9 100644
--- a/drivers/acpi/processor_idle.c
+++ b/drivers/acpi/processor_idle.c
@@ -918,7 +918,6 @@ static int acpi_idle_enter_bm(struct cpuidle_device *dev,
 struct cpuidle_driver acpi_idle_driver = {
 	.name =		"acpi_idle",
 	.owner =	THIS_MODULE,
-	.en_core_tk_irqen = 1,
 };
 
 /**
diff --git a/drivers/cpuidle/cpuidle-calxeda.c b/drivers/cpuidle/cpuidle-calxeda.c
index e1aab38..a3b56f5 100644
--- a/drivers/cpuidle/cpuidle-calxeda.c
+++ b/drivers/cpuidle/cpuidle-calxeda.c
@@ -100,7 +100,6 @@ static void calxeda_idle_cpuidle_devices_uninit(void)
 
 static struct cpuidle_driver calxeda_idle_driver = {
 	.name = "calxeda_idle",
-	.en_core_tk_irqen = 1,
 	.states = {
 		ARM_CPUIDLE_WFI_STATE,
 		{
diff --git a/drivers/cpuidle/cpuidle-kirkwood.c b/drivers/cpuidle/cpuidle-kirkwood.c
index 53aad73..6f31524 100644
--- a/drivers/cpuidle/cpuidle-kirkwood.c
+++ b/drivers/cpuidle/cpuidle-kirkwood.c
@@ -41,7 +41,6 @@ static int kirkwood_enter_idle(struct cpuidle_device *dev,
 static struct cpuidle_driver kirkwood_idle_driver = {
 	.name			= "kirkwood_idle",
 	.owner			= THIS_MODULE,
-	.en_core_tk_irqen	= 1,
 	.states[0]		= ARM_CPUIDLE_WFI_STATE,
 	.states[1]		= {
 		.enter			= kirkwood_enter_idle,
diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
index c500370..0da795b 100644
--- a/drivers/cpuidle/cpuidle.c
+++ b/drivers/cpuidle/cpuidle.c
@@ -43,24 +43,6 @@ void disable_cpuidle(void)
 
 static int __cpuidle_register_device(struct cpuidle_device *dev);
 
-static inline int cpuidle_enter(struct cpuidle_device *dev,
-				struct cpuidle_driver *drv, int index)
-{
-	struct cpuidle_state *target_state = &drv->states[index];
-	return target_state->enter(dev, drv, index);
-}
-
-static inline int cpuidle_enter_tk(struct cpuidle_device *dev,
-			       struct cpuidle_driver *drv, int index)
-{
-	return cpuidle_wrap_enter(dev, drv, index, cpuidle_enter);
-}
-
-typedef int (*cpuidle_enter_t)(struct cpuidle_device *dev,
-			       struct cpuidle_driver *drv, int index);
-
-static cpuidle_enter_t cpuidle_enter_ops;
-
 /**
  * cpuidle_play_dead - cpu off-lining
  *
@@ -90,11 +72,27 @@ int cpuidle_play_dead(void)
  * @next_state: index into drv->states of the state to enter
  */
 int cpuidle_enter_state(struct cpuidle_device *dev, struct cpuidle_driver *drv,
-		int next_state)
+			int index)
 {
 	int entered_state;
 
-	entered_state = cpuidle_enter_ops(dev, drv, next_state);
+	struct cpuidle_state *target_state = &drv->states[index];
+	ktime_t time_start, time_end;
+	s64 diff;
+
+	time_start = ktime_get();
+
+	entered_state = target_state->enter(dev, drv, index);
+
+	time_end = ktime_get();
+
+	local_irq_enable();
+
+	diff = ktime_to_us(ktime_sub(time_end, time_start));
+	if (diff > INT_MAX)
+		diff = INT_MAX;
+
+	dev->last_residency = (int) diff;
 
 	if (entered_state >= 0) {
 		/* Update cpuidle counters */
@@ -231,37 +229,6 @@ void cpuidle_resume(void)
 	mutex_unlock(&cpuidle_lock);
 }
 
-/**
- * cpuidle_wrap_enter - performs timekeeping and irqen around enter function
- * @dev: pointer to a valid cpuidle_device object
- * @drv: pointer to a valid cpuidle_driver object
- * @index: index of the target cpuidle state.
- */
-int cpuidle_wrap_enter(struct cpuidle_device *dev,
-				struct cpuidle_driver *drv, int index,
-				int (*enter)(struct cpuidle_device *dev,
-					struct cpuidle_driver *drv, int index))
-{
-	ktime_t time_start, time_end;
-	s64 diff;
-
-	time_start = ktime_get();
-
-	index = enter(dev, drv, index);
-
-	time_end = ktime_get();
-
-	local_irq_enable();
-
-	diff = ktime_to_us(ktime_sub(time_end, time_start));
-	if (diff > INT_MAX)
-		diff = INT_MAX;
-
-	dev->last_residency = (int) diff;
-
-	return index;
-}
-
 #ifdef CONFIG_ARCH_HAS_CPU_RELAX
 static int poll_idle(struct cpuidle_device *dev,
 		struct cpuidle_driver *drv, int index)
@@ -333,9 +300,6 @@ int cpuidle_enable_device(struct cpuidle_device *dev)
 			return ret;
 	}
 
-	cpuidle_enter_ops = drv->en_core_tk_irqen ?
-		cpuidle_enter_tk : cpuidle_enter;
-
 	poll_idle_init(drv);
 
 	ret = cpuidle_add_device_sysfs(dev);
diff --git a/drivers/idle/intel_idle.c b/drivers/idle/intel_idle.c
index 5d66750..48d7584 100644
--- a/drivers/idle/intel_idle.c
+++ b/drivers/idle/intel_idle.c
@@ -71,7 +71,6 @@
 static struct cpuidle_driver intel_idle_driver = {
 	.name = "intel_idle",
 	.owner = THIS_MODULE,
-	.en_core_tk_irqen = 1,
 };
 /* intel_idle.max_cstate=0 disables driver */
 static int max_cstate = CPUIDLE_STATE_MAX - 1;
diff --git a/include/linux/cpuidle.h b/include/linux/cpuidle.h
index fc3e580..79e3811 100644
--- a/include/linux/cpuidle.h
+++ b/include/linux/cpuidle.h
@@ -105,8 +105,6 @@ struct cpuidle_driver {
 	struct module 		*owner;
 	int                     refcnt;
 
-	/* set to 1 to use the core cpuidle time keeping (for all states). */
-	unsigned int		en_core_tk_irqen:1;
         /* used by the cpuidle framework to setup the broadcast timer */
 	unsigned int            bctimer:1;
 	/* states array must be ordered in decreasing power consumption */
@@ -132,10 +130,6 @@ extern void cpuidle_pause(void);
 extern void cpuidle_resume(void);
 extern int cpuidle_enable_device(struct cpuidle_device *dev);
 extern void cpuidle_disable_device(struct cpuidle_device *dev);
-extern int cpuidle_wrap_enter(struct cpuidle_device *dev,
-				struct cpuidle_driver *drv, int index,
-				int (*enter)(struct cpuidle_device *dev,
-					struct cpuidle_driver *drv, int index));
 extern int cpuidle_play_dead(void);
 
 extern struct cpuidle_driver *cpuidle_get_cpu_driver(struct cpuidle_device *dev);
@@ -162,11 +156,6 @@ static inline void cpuidle_resume(void) { }
 static inline int cpuidle_enable_device(struct cpuidle_device *dev)
 {return -ENODEV; }
 static inline void cpuidle_disable_device(struct cpuidle_device *dev) { }
-static inline int cpuidle_wrap_enter(struct cpuidle_device *dev,
-				struct cpuidle_driver *drv, int index,
-				int (*enter)(struct cpuidle_device *dev,
-					struct cpuidle_driver *drv, int index))
-{ return -ENODEV; }
 static inline int cpuidle_play_dead(void) {return -ENODEV; }
 #endif
 
-- 
1.7.9.5



From daniel.lezcano at linaro.org  Thu Apr 11 16:42:35 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Thu, 11 Apr 2013 22:42:35 +0200
Subject: [V2 patch 05/19] ARM: imx: cpuidle: create separate drivers for
 imx5/imx6
In-Reply-To: <1365712969-7541-1-git-send-email-daniel.lezcano@linaro.org>
References: <1365712969-7541-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1365712969-7541-6-git-send-email-daniel.lezcano@linaro.org>

The code intializes the cpuidle driver at different places.
The cpuidle driver for :
  * imx5 : is in the pm-imx5.c, the init function is in cpuidle.c
  * imx6 : is in cpuidle-imx6q.c, the init function is in cpuidle.c
           and cpuidle-imx6q.c

Instead of having the cpuidle code spread across different files,
let's write a driver for each SoC and make the code similar.

That implies some code duplication but that will be fixed with the
next patches which consolidate the initialization for all the drivers.

Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
---
 arch/arm/mach-imx/Makefile        |    1 +
 arch/arm/mach-imx/cpuidle-imx5.c  |   74 ++++++++++++++++++++++++++++++++++
 arch/arm/mach-imx/cpuidle-imx6q.c |   36 ++++++++++++++++-
 arch/arm/mach-imx/cpuidle.c       |   80 -------------------------------------
 arch/arm/mach-imx/cpuidle.h       |   10 ++---
 arch/arm/mach-imx/pm-imx5.c       |   29 +-------------
 6 files changed, 115 insertions(+), 115 deletions(-)
 create mode 100644 arch/arm/mach-imx/cpuidle-imx5.c
 delete mode 100644 arch/arm/mach-imx/cpuidle.c

diff --git a/arch/arm/mach-imx/Makefile b/arch/arm/mach-imx/Makefile
index c4ce090..bfd5f5b 100644
--- a/arch/arm/mach-imx/Makefile
+++ b/arch/arm/mach-imx/Makefile
@@ -31,6 +31,7 @@ obj-$(CONFIG_CPU_FREQ_IMX)    += cpufreq.o
 
 ifeq ($(CONFIG_CPU_IDLE),y)
 obj-y += cpuidle.o
+obj-$(CONFIG_SOC_IMX5) += cpuidle-imx5.o
 obj-$(CONFIG_SOC_IMX6Q) += cpuidle-imx6q.o
 endif
 
diff --git a/arch/arm/mach-imx/cpuidle-imx5.c b/arch/arm/mach-imx/cpuidle-imx5.c
new file mode 100644
index 0000000..3d9f0c9
--- /dev/null
+++ b/arch/arm/mach-imx/cpuidle-imx5.c
@@ -0,0 +1,74 @@
+/*
+ * Copyright (C) 2012 Freescale Semiconductor, Inc.
+ *
+ * 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/cpuidle.h>
+#include <linux/module.h>
+#include <asm/system_misc.h>
+#include <asm/proc-fns.h>
+
+#include "hardware.h"
+
+static DEFINE_PER_CPU(struct cpuidle_device, devices);
+
+static int imx5_cpuidle_enter(struct cpuidle_device *dev,
+			      struct cpuidle_driver *drv, int index)
+{
+	arm_pm_idle();
+	return index;
+}
+
+static struct cpuidle_driver imx5_cpuidle_driver = {
+	.name             = "imx5_cpuidle",
+	.owner            = THIS_MODULE,
+	.states[0] = {
+		.enter            = imx5_cpuidle_enter,
+		.exit_latency     = 2,
+		.target_residency = 1,
+		.flags            = CPUIDLE_FLAG_TIME_VALID,
+		.name             = "IMX5 SRPG",
+		.desc             = "CPU state retained,powered off",
+	},
+	.state_count = 1,
+};
+
+int __init imx5_cpuidle_init(void)
+{
+	struct cpuidle_device *dev;
+	int cpu, ret;
+
+	ret = cpuidle_register_driver(&imx5_cpuidle_driver);
+	if (ret) {
+		pr_err("%s: Failed to register cpuidle driver with error: %d\n",
+			 __func__, ret);
+		return ret;
+	}
+
+	/* initialize state data for each cpuidle_device */
+	for_each_possible_cpu(cpu) {
+		dev = &per_cpu(devices, cpu);
+		dev->cpu = cpu;
+
+		ret = cpuidle_register_device(dev);
+		if (ret) {
+			pr_err("%s: Failed to register cpu %u, error: %d\n",
+				__func__, cpu, ret);
+			goto out_unregister;
+		}
+	}
+
+	return 0;
+
+out_unregister:
+	for_each_possible_cpu(cpu) {
+		dev = &per_cpu(devices, cpu);
+		cpuidle_unregister_device(dev);
+	}
+
+	cpuidle_unregister_driver(&imx5_cpuidle_driver);
+	return ret;
+}
diff --git a/arch/arm/mach-imx/cpuidle-imx6q.c b/arch/arm/mach-imx/cpuidle-imx6q.c
index e2739ad..c066b74faa 100644
--- a/arch/arm/mach-imx/cpuidle-imx6q.c
+++ b/arch/arm/mach-imx/cpuidle-imx6q.c
@@ -14,6 +14,8 @@
 #include "common.h"
 #include "cpuidle.h"
 
+static DEFINE_PER_CPU(struct cpuidle_device, devices);
+
 static atomic_t master = ATOMIC_INIT(0);
 static DEFINE_SPINLOCK(master_lock);
 
@@ -65,11 +67,43 @@ static struct cpuidle_driver imx6q_cpuidle_driver = {
 
 int __init imx6q_cpuidle_init(void)
 {
+	struct cpuidle_device *dev;
+	int cpu, ret;
+
 	/* Need to enable SCU standby for entering WAIT modes */
 	imx_scu_standby_enable();
 
 	/* Set chicken bit to get a reliable WAIT mode support */
 	imx6q_set_chicken_bit();
 
-	return imx_cpuidle_init(&imx6q_cpuidle_driver);
+	ret = cpuidle_register_driver(&imx6q_cpuidle_driver);
+	if (ret) {
+		pr_err("%s: Failed to register cpuidle driver with error: %d\n",
+			 __func__, ret);
+		return ret;
+	}
+
+	/* initialize state data for each cpuidle_device */
+	for_each_possible_cpu(cpu) {
+		dev = &per_cpu(devices, cpu);
+		dev->cpu = cpu;
+
+		ret = cpuidle_register_device(dev);
+		if (ret) {
+			pr_err("%s: Failed to register cpu %u, error: %d\n",
+				__func__, cpu, ret);
+			goto out_unregister;
+		}
+	}
+
+	return 0;
+
+out_unregister:
+	for_each_possible_cpu(cpu) {
+		dev = &per_cpu(devices, cpu);
+		cpuidle_unregister_device(dev);
+	}
+
+	cpuidle_unregister_driver(&imx6q_cpuidle_driver);
+	return ret;
 }
diff --git a/arch/arm/mach-imx/cpuidle.c b/arch/arm/mach-imx/cpuidle.c
deleted file mode 100644
index d4cb511..0000000
--- a/arch/arm/mach-imx/cpuidle.c
+++ /dev/null
@@ -1,80 +0,0 @@
-/*
- * Copyright 2012 Freescale Semiconductor, Inc.
- * Copyright 2012 Linaro Ltd.
- *
- * The code contained herein is licensed under the GNU General Public
- * License. You may obtain a copy of the GNU General Public License
- * Version 2 or later at the following locations:
- *
- * http://www.opensource.org/licenses/gpl-license.html
- * http://www.gnu.org/copyleft/gpl.html
- */
-
-#include <linux/cpuidle.h>
-#include <linux/err.h>
-#include <linux/hrtimer.h>
-#include <linux/io.h>
-#include <linux/kernel.h>
-#include <linux/slab.h>
-
-static struct cpuidle_device __percpu * imx_cpuidle_devices;
-
-static void __init imx_cpuidle_devices_uninit(void)
-{
-	int cpu_id;
-	struct cpuidle_device *dev;
-
-	for_each_possible_cpu(cpu_id) {
-		dev = per_cpu_ptr(imx_cpuidle_devices, cpu_id);
-		cpuidle_unregister_device(dev);
-	}
-
-	free_percpu(imx_cpuidle_devices);
-}
-
-int __init imx_cpuidle_init(struct cpuidle_driver *drv)
-{
-	struct cpuidle_device *dev;
-	int cpu_id, ret;
-
-	if (drv->state_count > CPUIDLE_STATE_MAX) {
-		pr_err("%s: state_count exceeds maximum\n", __func__);
-		return -EINVAL;
-	}
-
-	ret = cpuidle_register_driver(drv);
-	if (ret) {
-		pr_err("%s: Failed to register cpuidle driver with error: %d\n",
-			 __func__, ret);
-		return ret;
-	}
-
-	imx_cpuidle_devices = alloc_percpu(struct cpuidle_device);
-	if (imx_cpuidle_devices == NULL) {
-		ret = -ENOMEM;
-		goto unregister_drv;
-	}
-
-	/* initialize state data for each cpuidle_device */
-	for_each_possible_cpu(cpu_id) {
-		dev = per_cpu_ptr(imx_cpuidle_devices, cpu_id);
-		dev->cpu = cpu_id;
-		dev->state_count = drv->state_count;
-
-		ret = cpuidle_register_device(dev);
-		if (ret) {
-			pr_err("%s: Failed to register cpu %u, error: %d\n",
-				__func__, cpu_id, ret);
-			goto uninit;
-		}
-	}
-
-	return 0;
-
-uninit:
-	imx_cpuidle_devices_uninit();
-
-unregister_drv:
-	cpuidle_unregister_driver(drv);
-	return ret;
-}
diff --git a/arch/arm/mach-imx/cpuidle.h b/arch/arm/mach-imx/cpuidle.h
index e092d13..786f98e 100644
--- a/arch/arm/mach-imx/cpuidle.h
+++ b/arch/arm/mach-imx/cpuidle.h
@@ -10,18 +10,16 @@
  * http://www.gnu.org/copyleft/gpl.html
  */
 
-#include <linux/cpuidle.h>
-
 #ifdef CONFIG_CPU_IDLE
-extern int imx_cpuidle_init(struct cpuidle_driver *drv);
+extern int imx5_cpuidle_init(void);
 extern int imx6q_cpuidle_init(void);
 #else
-static inline int imx_cpuidle_init(struct cpuidle_driver *drv)
+static inline int imx5_cpuidle_init(void)
 {
-	return -ENODEV;
+	return 0;
 }
 static inline int imx6q_cpuidle_init(void)
 {
-	return -ENODEV;
+	return 0;
 }
 #endif
diff --git a/arch/arm/mach-imx/pm-imx5.c b/arch/arm/mach-imx/pm-imx5.c
index 4b52b3e..82e79c6 100644
--- a/arch/arm/mach-imx/pm-imx5.c
+++ b/arch/arm/mach-imx/pm-imx5.c
@@ -149,32 +149,6 @@ static void imx5_pm_idle(void)
 	imx5_cpu_do_idle();
 }
 
-static int imx5_cpuidle_enter(struct cpuidle_device *dev,
-				struct cpuidle_driver *drv, int idx)
-{
-	int ret;
-
-	ret = imx5_cpu_do_idle();
-	if (ret < 0)
-		return ret;
-
-	return idx;
-}
-
-static struct cpuidle_driver imx5_cpuidle_driver = {
-	.name			= "imx5_cpuidle",
-	.owner			= THIS_MODULE,
-	.states[0]	= {
-		.enter			= imx5_cpuidle_enter,
-		.exit_latency		= 2,
-		.target_residency	= 1,
-		.flags			= CPUIDLE_FLAG_TIME_VALID,
-		.name			= "IMX5 SRPG",
-		.desc			= "CPU state retained,powered off",
-	},
-	.state_count		= 1,
-};
-
 static int __init imx5_pm_common_init(void)
 {
 	int ret;
@@ -192,8 +166,7 @@ static int __init imx5_pm_common_init(void)
 	/* Set the registers to the default cpu idle state. */
 	mx5_cpu_lp_set(IMX5_DEFAULT_CPU_IDLE_STATE);
 
-	imx_cpuidle_init(&imx5_cpuidle_driver);
-	return 0;
+	return imx5_cpuidle_init();
 }
 
 void __init imx51_pm_init(void)
-- 
1.7.9.5



From daniel.lezcano at linaro.org  Thu Apr 11 16:42:37 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Thu, 11 Apr 2013 22:42:37 +0200
Subject: [V2 patch 07/19] ARM: ux500: cpuidle: use init/exit common routine
In-Reply-To: <1365712969-7541-1-git-send-email-daniel.lezcano@linaro.org>
References: <1365712969-7541-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1365712969-7541-8-git-send-email-daniel.lezcano@linaro.org>

Remove the duplicate code and use the cpuidle common code for initialization.

Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
---
 arch/arm/mach-ux500/cpuidle.c |   32 +-------------------------------
 1 file changed, 1 insertion(+), 31 deletions(-)

diff --git a/arch/arm/mach-ux500/cpuidle.c b/arch/arm/mach-ux500/cpuidle.c
index 5657d4a..488e074 100644
--- a/arch/arm/mach-ux500/cpuidle.c
+++ b/arch/arm/mach-ux500/cpuidle.c
@@ -21,7 +21,6 @@
 
 static atomic_t master = ATOMIC_INIT(0);
 static DEFINE_SPINLOCK(master_lock);
-static DEFINE_PER_CPU(struct cpuidle_device, ux500_cpuidle_device);
 
 static inline int ux500_enter_idle(struct cpuidle_device *dev,
 				   struct cpuidle_driver *drv, int index)
@@ -112,40 +111,11 @@ static struct cpuidle_driver ux500_idle_driver = {
 
 int __init ux500_idle_init(void)
 {
-	int ret, cpu;
-	struct cpuidle_device *device;
-
         /* Configure wake up reasons */
 	prcmu_enable_wakeups(PRCMU_WAKEUP(ARM) | PRCMU_WAKEUP(RTC) |
 			     PRCMU_WAKEUP(ABB));
 
-	ret = cpuidle_register_driver(&ux500_idle_driver);
-	if (ret) {
-		printk(KERN_ERR "failed to register ux500 idle driver\n");
-		return ret;
-	}
-
-	for_each_possible(cpu) {
-		device = &per_cpu(ux500_cpuidle_device, cpu);
-		device->cpu = cpu;
-		ret = cpuidle_register_device(device);
-		if (ret) {
-			printk(KERN_ERR "Failed to register cpuidle "
-			       "device for cpu%d\n", cpu);
-			goto out_unregister;
-		}
-	}
-out:
-	return ret;
-
-out_unregister:
-	for_each_possible_cpu(cpu) {
-		device = &per_cpu(ux500_cpuidle_device, cpu);
-		cpuidle_unregister_device(device);
-	}
-
-	cpuidle_unregister_driver(&ux500_idle_driver);
-	goto out;
+	return cpuidle_register(&ux500_idle_driver, NULL);
 }
 
 device_initcall(ux500_idle_init);
-- 
1.7.9.5



From daniel.lezcano at linaro.org  Thu Apr 11 16:42:36 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Thu, 11 Apr 2013 22:42:36 +0200
Subject: [V2 patch 06/19] cpuidle: make a single register function for all
In-Reply-To: <1365712969-7541-1-git-send-email-daniel.lezcano@linaro.org>
References: <1365712969-7541-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1365712969-7541-7-git-send-email-daniel.lezcano@linaro.org>

The usual scheme to initialize a cpuidle driver on a SMP is:

	cpuidle_register_driver(drv);
	for_each_possible_cpu(cpu) {
		device = &per_cpu(cpuidle_dev, cpu);
		cpuidle_register_device(device);
	}

This code is duplicated in each cpuidle driver.

On UP systems, it is done this way:

	cpuidle_register_driver(drv);
	device = &per_cpu(cpuidle_dev, cpu);
	cpuidle_register_device(device);

On UP, the macro 'for_each_cpu' does one iteration:

#define for_each_cpu(cpu, mask)                 \
        for ((cpu) = 0; (cpu) < 1; (cpu)++, (void)mask)

Hence, the initialization loop is the same for UP than SMP.

Beside, we saw different bugs / mis-initialization / return code unchecked in
the different drivers, the code is duplicated including bugs. After fixing all
these ones, it appears the initialization pattern is the same for everyone.

Please note, some drivers are doing dev->state_count = drv->state_count. This is
not necessary because it is done by the cpuidle_enable_device function in the
cpuidle framework. This is true, until you have the same states for all your
devices. Otherwise, the 'low level' API should be used instead with the specific
initialization for the driver.

Let's add a wrapper function doing this initialization with a cpumask parameter
for the coupled idle states and use it for all the drivers.

That will save a lot of LOC, consolidate the code, and the modifications in the
future could be done in a single place. Another benefit is the consolidation of
the cpuidle_device variable which is now in the cpuidle framework and no longer
spread accross the different arch specific drivers.

Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
---
 Documentation/cpuidle/driver.txt |    6 ++++
 drivers/cpuidle/cpuidle.c        |   72 ++++++++++++++++++++++++++++++++++++++
 include/linux/cpuidle.h          |    9 +++--
 3 files changed, 85 insertions(+), 2 deletions(-)

diff --git a/Documentation/cpuidle/driver.txt b/Documentation/cpuidle/driver.txt
index 7a9e09e..1b0d81d 100644
--- a/Documentation/cpuidle/driver.txt
+++ b/Documentation/cpuidle/driver.txt
@@ -15,11 +15,17 @@ has mechanisms in place to support actual entry-exit into CPU idle states.
 cpuidle driver initializes the cpuidle_device structure for each CPU device
 and registers with cpuidle using cpuidle_register_device.
 
+If all the idle states are the same, the wrapper function cpuidle_register
+could be used instead.
+
 It can also support the dynamic changes (like battery <-> AC), by using
 cpuidle_pause_and_lock, cpuidle_disable_device and cpuidle_enable_device,
 cpuidle_resume_and_unlock.
 
 Interfaces:
+extern int cpuidle_register(struct cpuidle_driver *drv,
+                            const struct cpumask *const coupled_cpus);
+extern int cpuidle_unregister(struct cpuidle_driver *drv);
 extern int cpuidle_register_driver(struct cpuidle_driver *drv);
 extern void cpuidle_unregister_driver(struct cpuidle_driver *drv);
 extern int cpuidle_register_device(struct cpuidle_device *dev);
diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
index 0da795b..49e8d30 100644
--- a/drivers/cpuidle/cpuidle.c
+++ b/drivers/cpuidle/cpuidle.c
@@ -24,6 +24,7 @@
 #include "cpuidle.h"
 
 DEFINE_PER_CPU(struct cpuidle_device *, cpuidle_devices);
+DEFINE_PER_CPU(struct cpuidle_device, cpuidle_dev);
 
 DEFINE_MUTEX(cpuidle_lock);
 LIST_HEAD(cpuidle_detected_devices);
@@ -453,6 +454,77 @@ void cpuidle_unregister_device(struct cpuidle_device *dev)
 
 EXPORT_SYMBOL_GPL(cpuidle_unregister_device);
 
+/*
+ * cpuidle_unregister: unregister a driver and the devices. This function
+ * can be used only if the driver has been previously registered through
+ * the cpuidle_register function.
+ *
+ * @drv: a valid pointer to a struct cpuidle_driver
+ */
+void cpuidle_unregister(struct cpuidle_driver *drv)
+{
+	int cpu;
+	struct cpuidle_device *device;
+
+	for_each_possible_cpu(cpu) {
+		device = &per_cpu(cpuidle_dev, cpu);
+		cpuidle_unregister_device(device);
+	}
+
+	cpuidle_unregister_driver(drv);
+}
+EXPORT_SYMBOL_GPL(cpuidle_unregister);
+
+/**
+ * cpuidle_register: registers the driver and the cpu devices with the
+ * coupled_cpus passed as parameter. This function is used for all common
+ * initialization pattern there are in the arch specific drivers. The
+ * devices is globally defined in this file.
+ *
+ * @drv         : a valid pointer to a struct cpuidle_driver
+ * @coupled_cpus: a cpumask for the coupled states
+ *
+ * Returns 0 on success, < 0 otherwise
+ */
+int cpuidle_register(struct cpuidle_driver *drv,
+		     const struct cpumask *const coupled_cpus)
+{
+	int ret, cpu;
+	struct cpuidle_device *device;
+
+	ret = cpuidle_register_driver(drv);
+	if (ret) {
+		pr_err("failed to register cpuidle driver\n");
+		return ret;
+	}
+
+	for_each_possible_cpu(cpu) {
+		device = &per_cpu(cpuidle_dev, cpu);
+		device->cpu = cpu;
+
+#ifdef CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED
+		/*
+		 * On multiplatform for ARM, the coupled idle states could
+		 * enabled in the kernel even if the cpuidle driver does not
+		 * use it. Note, coupled_cpus is a struct copy.
+		 */
+		if (coupled_cpus)
+			device->coupled_cpus = *coupled_cpus;
+#endif
+		ret = cpuidle_register_device(device);
+		if (!ret)
+			continue;
+
+		pr_err("Failed to register cpuidle device for cpu%d\n", cpu);
+
+		cpuidle_unregister(drv);
+		break;
+	}
+
+	return ret;
+}
+EXPORT_SYMBOL_GPL(cpuidle_register);
+
 #ifdef CONFIG_SMP
 
 static void smp_callback(void *v)
diff --git a/include/linux/cpuidle.h b/include/linux/cpuidle.h
index 79e3811..3c86faa 100644
--- a/include/linux/cpuidle.h
+++ b/include/linux/cpuidle.h
@@ -123,7 +123,9 @@ extern void cpuidle_driver_unref(void);
 extern void cpuidle_unregister_driver(struct cpuidle_driver *drv);
 extern int cpuidle_register_device(struct cpuidle_device *dev);
 extern void cpuidle_unregister_device(struct cpuidle_device *dev);
-
+extern int cpuidle_register(struct cpuidle_driver *drv,
+			    const struct cpumask *const coupled_cpus);
+extern void cpuidle_unregister(struct cpuidle_driver *drv);
 extern void cpuidle_pause_and_lock(void);
 extern void cpuidle_resume_and_unlock(void);
 extern void cpuidle_pause(void);
@@ -148,7 +150,10 @@ static inline void cpuidle_unregister_driver(struct cpuidle_driver *drv) { }
 static inline int cpuidle_register_device(struct cpuidle_device *dev)
 {return -ENODEV; }
 static inline void cpuidle_unregister_device(struct cpuidle_device *dev) { }
-
+static inline int cpuidle_register(struct cpuidle_driver *drv,
+				   const struct cpumask *const coupled_cpus)
+{return -ENODEV; }
+static inline void cpuidle_unregister(struct cpuidle_driver *drv) { }
 static inline void cpuidle_pause_and_lock(void) { }
 static inline void cpuidle_resume_and_unlock(void) { }
 static inline void cpuidle_pause(void) { }
-- 
1.7.9.5



From daniel.lezcano at linaro.org  Thu Apr 11 16:42:39 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Thu, 11 Apr 2013 22:42:39 +0200
Subject: [V2 patch 09/19] ARM: OMAP3: cpuidle: use init/exit common routine
In-Reply-To: <1365712969-7541-1-git-send-email-daniel.lezcano@linaro.org>
References: <1365712969-7541-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1365712969-7541-10-git-send-email-daniel.lezcano@linaro.org>

Remove the duplicated code and use the cpuidle common code for initialization.

Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
---
 arch/arm/mach-omap2/cpuidle34xx.c |   18 ++----------------
 1 file changed, 2 insertions(+), 16 deletions(-)

diff --git a/arch/arm/mach-omap2/cpuidle34xx.c b/arch/arm/mach-omap2/cpuidle34xx.c
index 027a787..cca045c 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -26,6 +26,7 @@
 #include <linux/cpuidle.h>
 #include <linux/export.h>
 #include <linux/cpu_pm.h>
+#include <asm/cpuidle.h>
 
 #include "powerdomain.h"
 #include "clockdomain.h"
@@ -259,8 +260,6 @@ static int omap3_enter_idle_bm(struct cpuidle_device *dev,
 	return ret;
 }
 
-static DEFINE_PER_CPU(struct cpuidle_device, omap3_idle_dev);
-
 static struct cpuidle_driver omap3_idle_driver = {
 	.name             = "omap3_idle",
 	.owner            = THIS_MODULE,
@@ -336,8 +335,6 @@ static struct cpuidle_driver omap3_idle_driver = {
  */
 int __init omap3_idle_init(void)
 {
-	struct cpuidle_device *dev;
-
 	mpu_pd = pwrdm_lookup("mpu_pwrdm");
 	core_pd = pwrdm_lookup("core_pwrdm");
 	per_pd = pwrdm_lookup("per_pwrdm");
@@ -346,16 +343,5 @@ int __init omap3_idle_init(void)
 	if (!mpu_pd || !core_pd || !per_pd || !cam_pd)
 		return -ENODEV;
 
-	cpuidle_register_driver(&omap3_idle_driver);
-
-	dev = &per_cpu(omap3_idle_dev, smp_processor_id());
-	dev->cpu = 0;
-
-	if (cpuidle_register_device(dev)) {
-		printk(KERN_ERR "%s: CPUidle register device failed\n",
-		       __func__);
-		return -EIO;
-	}
-
-	return 0;
+	return cpuidle_register(&omap3_idle_driver, NULL);
 }
-- 
1.7.9.5



From daniel.lezcano at linaro.org  Thu Apr 11 16:42:38 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Thu, 11 Apr 2013 22:42:38 +0200
Subject: [V2 patch 08/19] ARM: at91: cpuidle: use init/exit common routine
In-Reply-To: <1365712969-7541-1-git-send-email-daniel.lezcano@linaro.org>
References: <1365712969-7541-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1365712969-7541-9-git-send-email-daniel.lezcano@linaro.org>

Remove the duplicate code and use the arm cpuidle driver's common code
for initialization.

Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
Acked-by: Nicolas Ferre <nicolas.ferre at atmel.com>
---
 arch/arm/mach-at91/cpuidle.c |   17 ++---------------
 1 file changed, 2 insertions(+), 15 deletions(-)

diff --git a/arch/arm/mach-at91/cpuidle.c b/arch/arm/mach-at91/cpuidle.c
index 0130df7..48f1228 100644
--- a/arch/arm/mach-at91/cpuidle.c
+++ b/arch/arm/mach-at91/cpuidle.c
@@ -27,8 +27,6 @@
 
 #define AT91_MAX_STATES	2
 
-static DEFINE_PER_CPU(struct cpuidle_device, at91_cpuidle_device);
-
 /* Actual code that puts the SoC in different idle states */
 static int at91_enter_idle(struct cpuidle_device *dev,
 			struct cpuidle_driver *drv,
@@ -60,20 +58,9 @@ static struct cpuidle_driver at91_idle_driver = {
 };
 
 /* Initialize CPU idle by registering the idle states */
-static int at91_init_cpuidle(void)
+static int __init at91_init_cpuidle(void)
 {
-	struct cpuidle_device *device;
-
-	device = &per_cpu(at91_cpuidle_device, smp_processor_id());
-	device->state_count = AT91_MAX_STATES;
-
-	cpuidle_register_driver(&at91_idle_driver);
-
-	if (cpuidle_register_device(device)) {
-		printk(KERN_ERR "at91_init_cpuidle: Failed registering\n");
-		return -EIO;
-	}
-	return 0;
+	return cpuidle_register(&at91_idle_driver, NULL);
 }
 
 device_initcall(at91_init_cpuidle);
-- 
1.7.9.5



From daniel.lezcano at linaro.org  Thu Apr 11 16:42:40 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Thu, 11 Apr 2013 22:42:40 +0200
Subject: [V2 patch 10/19] ARM: s3c64xx: cpuidle: use init/exit common routine
In-Reply-To: <1365712969-7541-1-git-send-email-daniel.lezcano@linaro.org>
References: <1365712969-7541-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1365712969-7541-11-git-send-email-daniel.lezcano@linaro.org>

Remove the duplicated code and use the cpuidle common code for initialization.

Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
---
 arch/arm/mach-s3c64xx/cpuidle.c |   14 +-------------
 1 file changed, 1 insertion(+), 13 deletions(-)

diff --git a/arch/arm/mach-s3c64xx/cpuidle.c b/arch/arm/mach-s3c64xx/cpuidle.c
index 852ff16..3c8ab07 100644
--- a/arch/arm/mach-s3c64xx/cpuidle.c
+++ b/arch/arm/mach-s3c64xx/cpuidle.c
@@ -40,8 +40,6 @@ static int s3c64xx_enter_idle(struct cpuidle_device *dev,
 	return index;
 }
 
-static DEFINE_PER_CPU(struct cpuidle_device, s3c64xx_cpuidle_device);
-
 static struct cpuidle_driver s3c64xx_cpuidle_driver = {
 	.name	= "s3c64xx_cpuidle",
 	.owner  = THIS_MODULE,
@@ -60,16 +58,6 @@ static struct cpuidle_driver s3c64xx_cpuidle_driver = {
 
 static int __init s3c64xx_init_cpuidle(void)
 {
-	int ret;
-
-	cpuidle_register_driver(&s3c64xx_cpuidle_driver);
-
-	ret = cpuidle_register_device(&s3c64xx_cpuidle_device);
-	if (ret) {
-		pr_err("Failed to register cpuidle device: %d\n", ret);
-		return ret;
-	}
-
-	return 0;
+	return cpuidle_register(&s3c64xx_cpuidle_driver, NULL);
 }
 device_initcall(s3c64xx_init_cpuidle);
-- 
1.7.9.5



From daniel.lezcano at linaro.org  Thu Apr 11 16:42:41 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Thu, 11 Apr 2013 22:42:41 +0200
Subject: [V2 patch 11/19] ARM: tegra: cpuidle: use init/exit common routine
In-Reply-To: <1365712969-7541-1-git-send-email-daniel.lezcano@linaro.org>
References: <1365712969-7541-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1365712969-7541-12-git-send-email-daniel.lezcano@linaro.org>

Remove the duplicated code and use the cpuidle common code for initialization.

Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
Acked-by: Stephen Warren <swarren at nvidia.com>
---
 arch/arm/mach-tegra/cpuidle-tegra114.c |   26 +-------------------------
 1 file changed, 1 insertion(+), 25 deletions(-)

diff --git a/arch/arm/mach-tegra/cpuidle-tegra114.c b/arch/arm/mach-tegra/cpuidle-tegra114.c
index c5fadf9..1d1c602 100644
--- a/arch/arm/mach-tegra/cpuidle-tegra114.c
+++ b/arch/arm/mach-tegra/cpuidle-tegra114.c
@@ -29,31 +29,7 @@ static struct cpuidle_driver tegra_idle_driver = {
 	},
 };
 
-static DEFINE_PER_CPU(struct cpuidle_device, tegra_idle_device);
-
 int __init tegra114_cpuidle_init(void)
 {
-	int ret;
-	unsigned int cpu;
-	struct cpuidle_device *dev;
-	struct cpuidle_driver *drv = &tegra_idle_driver;
-
-	ret = cpuidle_register_driver(&tegra_idle_driver);
-	if (ret) {
-		pr_err("CPUidle driver registration failed\n");
-		return ret;
-	}
-
-	for_each_possible_cpu(cpu) {
-		dev = &per_cpu(tegra_idle_device, cpu);
-		dev->cpu = cpu;
-
-		ret = cpuidle_register_device(dev);
-		if (ret) {
-			pr_err("CPU%u: CPUidle device registration failed\n",
-				cpu);
-			return ret;
-		}
-	}
-	return 0;
+	return cpuidle_register(&tegra_idle_driver, NULL);
 }
-- 
1.7.9.5



From daniel.lezcano at linaro.org  Thu Apr 11 16:42:42 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Thu, 11 Apr 2013 22:42:42 +0200
Subject: [V2 patch 12/19] ARM: shmobile: cpuidle: use init/exit common routine
In-Reply-To: <1365712969-7541-1-git-send-email-daniel.lezcano@linaro.org>
References: <1365712969-7541-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1365712969-7541-13-git-send-email-daniel.lezcano@linaro.org>

Remove the duplicated code and use the cpuidle common code for initialization.

Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
Acked-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/cpuidle.c |   10 +---------
 1 file changed, 1 insertion(+), 9 deletions(-)

diff --git a/arch/arm/mach-shmobile/cpuidle.c b/arch/arm/mach-shmobile/cpuidle.c
index d671ae9..0afeb5c 100644
--- a/arch/arm/mach-shmobile/cpuidle.c
+++ b/arch/arm/mach-shmobile/cpuidle.c
@@ -16,7 +16,6 @@
 #include <asm/cpuidle.h>
 #include <asm/io.h>
 
-static struct cpuidle_device shmobile_cpuidle_dev;
 static struct cpuidle_driver shmobile_cpuidle_default_driver = {
 	.name			= "shmobile_cpuidle",
 	.owner			= THIS_MODULE,
@@ -34,12 +33,5 @@ void __init shmobile_cpuidle_set_driver(struct cpuidle_driver *drv)
 
 int __init shmobile_cpuidle_init(void)
 {
-	struct cpuidle_device *dev = &shmobile_cpuidle_dev;
-
-	cpuidle_register_driver(cpuidle_drv);
-
-	dev->state_count = cpuidle_drv->state_count;
-	cpuidle_register_device(dev);
-
-	return 0;
+	return cpuidle_register(cpuidle_drv, NULL);
 }
-- 
1.7.9.5



From daniel.lezcano at linaro.org  Thu Apr 11 16:42:43 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Thu, 11 Apr 2013 22:42:43 +0200
Subject: [V2 patch 13/19] ARM: OMAP4: cpuidle: use init/exit common routine
In-Reply-To: <1365712969-7541-1-git-send-email-daniel.lezcano@linaro.org>
References: <1365712969-7541-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1365712969-7541-14-git-send-email-daniel.lezcano@linaro.org>

Remove the duplicated code and use the cpuidle common code for initialization.

Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
---
 arch/arm/mach-omap2/cpuidle44xx.c |   22 ++--------------------
 1 file changed, 2 insertions(+), 20 deletions(-)

diff --git a/arch/arm/mach-omap2/cpuidle44xx.c b/arch/arm/mach-omap2/cpuidle44xx.c
index cd188de..861dd90 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -15,6 +15,7 @@
 #include <linux/cpu_pm.h>
 #include <linux/export.h>
 
+#include <asm/cpuidle.h>
 #include <asm/proc-fns.h>
 
 #include "common.h"
@@ -157,8 +158,6 @@ fail:
 	return index;
 }
 
-static DEFINE_PER_CPU(struct cpuidle_device, omap4_idle_dev);
-
 static struct cpuidle_driver omap4_idle_driver = {
 	.name				= "omap4_idle",
 	.owner				= THIS_MODULE,
@@ -207,9 +206,6 @@ static struct cpuidle_driver omap4_idle_driver = {
  */
 int __init omap4_idle_init(void)
 {
-	struct cpuidle_device *dev;
-	unsigned int cpu_id = 0;
-
 	mpu_pd = pwrdm_lookup("mpu_pwrdm");
 	cpu_pd[0] = pwrdm_lookup("cpu0_pwrdm");
 	cpu_pd[1] = pwrdm_lookup("cpu1_pwrdm");
@@ -221,19 +217,5 @@ int __init omap4_idle_init(void)
 	if (!cpu_clkdm[0] || !cpu_clkdm[1])
 		return -ENODEV;
 
-	for_each_cpu(cpu_id, cpu_online_mask) {
-		dev = &per_cpu(omap4_idle_dev, cpu_id);
-		dev->cpu = cpu_id;
-#ifdef CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED
-		dev->coupled_cpus = *cpu_online_mask;
-#endif
-		cpuidle_register_driver(&omap4_idle_driver);
-
-		if (cpuidle_register_device(dev)) {
-			pr_err("%s: CPUidle register failed\n", __func__);
-			return -EIO;
-		}
-	}
-
-	return 0;
+	return cpuidle_register(&omap4_idle_driver, cpu_online_mask);
 }
-- 
1.7.9.5



From daniel.lezcano at linaro.org  Thu Apr 11 16:42:44 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Thu, 11 Apr 2013 22:42:44 +0200
Subject: [V2 patch 14/19] ARM: tegra: cpuidle: use init/exit common routine
 for tegra2
In-Reply-To: <1365712969-7541-1-git-send-email-daniel.lezcano@linaro.org>
References: <1365712969-7541-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1365712969-7541-15-git-send-email-daniel.lezcano@linaro.org>

Remove the duplicated code and use the cpuidle common code for initialization.

Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
Acked-by: Stephen Warren <swarren at nvidia.com>
---
 arch/arm/mach-tegra/cpuidle-tegra20.c |   30 +-----------------------------
 1 file changed, 1 insertion(+), 29 deletions(-)

diff --git a/arch/arm/mach-tegra/cpuidle-tegra20.c b/arch/arm/mach-tegra/cpuidle-tegra20.c
index f1f6ac4..590ec25 100644
--- a/arch/arm/mach-tegra/cpuidle-tegra20.c
+++ b/arch/arm/mach-tegra/cpuidle-tegra20.c
@@ -70,8 +70,6 @@ static struct cpuidle_driver tegra_idle_driver = {
 	.safe_state_index = 0,
 };
 
-static DEFINE_PER_CPU(struct cpuidle_device, tegra_idle_device);
-
 #ifdef CONFIG_PM_SLEEP
 #ifdef CONFIG_SMP
 static void __iomem *pmc = IO_ADDRESS(TEGRA_PMC_BASE);
@@ -220,34 +218,8 @@ static int tegra20_idle_lp2_coupled(struct cpuidle_device *dev,
 
 int __init tegra20_cpuidle_init(void)
 {
-	int ret;
-	unsigned int cpu;
-	struct cpuidle_device *dev;
-	struct cpuidle_driver *drv = &tegra_idle_driver;
-
 #ifdef CONFIG_PM_SLEEP
 	tegra_tear_down_cpu = tegra20_tear_down_cpu;
 #endif
-
-	ret = cpuidle_register_driver(&tegra_idle_driver);
-	if (ret) {
-		pr_err("CPUidle driver registration failed\n");
-		return ret;
-	}
-
-	for_each_possible_cpu(cpu) {
-		dev = &per_cpu(tegra_idle_device, cpu);
-		dev->cpu = cpu;
-#ifdef CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED
-		dev->coupled_cpus = *cpu_possible_mask;
-#endif
-
-		ret = cpuidle_register_device(dev);
-		if (ret) {
-			pr_err("CPU%u: CPUidle device registration failed\n",
-				cpu);
-			return ret;
-		}
-	}
-	return 0;
+	return cpuidle_register(&tegra_idle_driver, cpu_possible_mask);
 }
-- 
1.7.9.5



From daniel.lezcano at linaro.org  Thu Apr 11 16:42:45 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Thu, 11 Apr 2013 22:42:45 +0200
Subject: [V2 patch 15/19] ARM: tegra: cpuidle: use init/exit common routine
 for tegra3
In-Reply-To: <1365712969-7541-1-git-send-email-daniel.lezcano@linaro.org>
References: <1365712969-7541-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1365712969-7541-16-git-send-email-daniel.lezcano@linaro.org>

Remove the duplicated code and use the cpuidle common code for initialization.

Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
Acked-by: Stephen Warren <swarren at nvidia.com>
---
 arch/arm/mach-tegra/cpuidle-tegra30.c |   27 +--------------------------
 1 file changed, 1 insertion(+), 26 deletions(-)

diff --git a/arch/arm/mach-tegra/cpuidle-tegra30.c b/arch/arm/mach-tegra/cpuidle-tegra30.c
index f6a0c72..36dc2be 100644
--- a/arch/arm/mach-tegra/cpuidle-tegra30.c
+++ b/arch/arm/mach-tegra/cpuidle-tegra30.c
@@ -64,8 +64,6 @@ static struct cpuidle_driver tegra_idle_driver = {
 	},
 };
 
-static DEFINE_PER_CPU(struct cpuidle_device, tegra_idle_device);
-
 #ifdef CONFIG_PM_SLEEP
 static bool tegra30_cpu_cluster_power_down(struct cpuidle_device *dev,
 					   struct cpuidle_driver *drv,
@@ -156,31 +154,8 @@ static int tegra30_idle_lp2(struct cpuidle_device *dev,
 
 int __init tegra30_cpuidle_init(void)
 {
-	int ret;
-	unsigned int cpu;
-	struct cpuidle_device *dev;
-	struct cpuidle_driver *drv = &tegra_idle_driver;
-
 #ifdef CONFIG_PM_SLEEP
 	tegra_tear_down_cpu = tegra30_tear_down_cpu;
 #endif
-
-	ret = cpuidle_register_driver(&tegra_idle_driver);
-	if (ret) {
-		pr_err("CPUidle driver registration failed\n");
-		return ret;
-	}
-
-	for_each_possible_cpu(cpu) {
-		dev = &per_cpu(tegra_idle_device, cpu);
-		dev->cpu = cpu;
-
-		ret = cpuidle_register_device(dev);
-		if (ret) {
-			pr_err("CPU%u: CPUidle device registration failed\n",
-				cpu);
-			return ret;
-		}
-	}
-	return 0;
+	return cpuidle_register(&tegra_idle_driver, NULL);
 }
-- 
1.7.9.5



From daniel.lezcano at linaro.org  Thu Apr 11 16:42:47 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Thu, 11 Apr 2013 22:42:47 +0200
Subject: [V2 patch 17/19] ARM: kirkwood: cpuidle: use init/exit common routine
In-Reply-To: <1365712969-7541-1-git-send-email-daniel.lezcano@linaro.org>
References: <1365712969-7541-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1365712969-7541-18-git-send-email-daniel.lezcano@linaro.org>

Remove the duplicated code and use the cpuidle common code for initialization.

Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
---
 drivers/cpuidle/cpuidle-kirkwood.c |   17 ++---------------
 1 file changed, 2 insertions(+), 15 deletions(-)

diff --git a/drivers/cpuidle/cpuidle-kirkwood.c b/drivers/cpuidle/cpuidle-kirkwood.c
index 6f31524..53290e1 100644
--- a/drivers/cpuidle/cpuidle-kirkwood.c
+++ b/drivers/cpuidle/cpuidle-kirkwood.c
@@ -52,9 +52,6 @@ static struct cpuidle_driver kirkwood_idle_driver = {
 	},
 	.state_count = KIRKWOOD_MAX_STATES,
 };
-static struct cpuidle_device *device;
-
-static DEFINE_PER_CPU(struct cpuidle_device, kirkwood_cpuidle_device);
 
 /* Initialize CPU idle by registering the idle states */
 static int kirkwood_cpuidle_probe(struct platform_device *pdev)
@@ -69,22 +66,12 @@ static int kirkwood_cpuidle_probe(struct platform_device *pdev)
 	if (IS_ERR(ddr_operation_base))
 		return PTR_ERR(ddr_operation_base);
 
-	device = &per_cpu(kirkwood_cpuidle_device, smp_processor_id());
-	device->state_count = KIRKWOOD_MAX_STATES;
-
-	cpuidle_register_driver(&kirkwood_idle_driver);
-	if (cpuidle_register_device(device)) {
-		pr_err("kirkwood_init_cpuidle: Failed registering\n");
-		return -EIO;
-	}
-	return 0;
+	return cpuidle_register(&kirkwood_idle_driver, NULL);
 }
 
 int kirkwood_cpuidle_remove(struct platform_device *pdev)
 {
-	cpuidle_unregister_device(device);
-	cpuidle_unregister_driver(&kirkwood_idle_driver);
-
+	cpuidle_unregister(&kirkwood_idle_driver);
 	return 0;
 }
 
-- 
1.7.9.5



From daniel.lezcano at linaro.org  Thu Apr 11 16:42:46 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Thu, 11 Apr 2013 22:42:46 +0200
Subject: [V2 patch 16/19] ARM: calxeda: cpuidle: use init/exit common routine
In-Reply-To: <1365712969-7541-1-git-send-email-daniel.lezcano@linaro.org>
References: <1365712969-7541-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1365712969-7541-17-git-send-email-daniel.lezcano@linaro.org>

Remove the duplicated code and use the cpuidle common code for initialization.

Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
Acked-by: Rob Herring <rob.herring at calxeda.com>
---
 drivers/cpuidle/cpuidle-calxeda.c |   52 +------------------------------------
 1 file changed, 1 insertion(+), 51 deletions(-)

diff --git a/drivers/cpuidle/cpuidle-calxeda.c b/drivers/cpuidle/cpuidle-calxeda.c
index a3b56f5..e344b56 100644
--- a/drivers/cpuidle/cpuidle-calxeda.c
+++ b/drivers/cpuidle/cpuidle-calxeda.c
@@ -35,8 +35,6 @@
 extern void highbank_set_cpu_jump(int cpu, void *jump_addr);
 extern void *scu_base_addr;
 
-static struct cpuidle_device __percpu *calxeda_idle_cpuidle_devices;
-
 static inline unsigned int get_auxcr(void)
 {
 	unsigned int val;
@@ -85,19 +83,6 @@ static int calxeda_pwrdown_idle(struct cpuidle_device *dev,
 	return index;
 }
 
-static void calxeda_idle_cpuidle_devices_uninit(void)
-{
-	int i;
-	struct cpuidle_device *dev;
-
-	for_each_possible_cpu(i) {
-		dev = per_cpu_ptr(calxeda_idle_cpuidle_devices, i);
-		cpuidle_unregister_device(dev);
-	}
-
-	free_percpu(calxeda_idle_cpuidle_devices);
-}
-
 static struct cpuidle_driver calxeda_idle_driver = {
 	.name = "calxeda_idle",
 	.states = {
@@ -117,44 +102,9 @@ static struct cpuidle_driver calxeda_idle_driver = {
 
 static int __init calxeda_cpuidle_init(void)
 {
-	int cpu_id;
-	int ret;
-	struct cpuidle_device *dev;
-	struct cpuidle_driver *drv = &calxeda_idle_driver;
-
 	if (!of_machine_is_compatible("calxeda,highbank"))
 		return -ENODEV;
 
-	ret = cpuidle_register_driver(drv);
-	if (ret)
-		return ret;
-
-	calxeda_idle_cpuidle_devices = alloc_percpu(struct cpuidle_device);
-	if (calxeda_idle_cpuidle_devices == NULL) {
-		ret = -ENOMEM;
-		goto unregister_drv;
-	}
-
-	/* initialize state data for each cpuidle_device */
-	for_each_possible_cpu(cpu_id) {
-		dev = per_cpu_ptr(calxeda_idle_cpuidle_devices, cpu_id);
-		dev->cpu = cpu_id;
-		dev->state_count = drv->state_count;
-
-		ret = cpuidle_register_device(dev);
-		if (ret) {
-			pr_err("Failed to register cpu %u, error: %d\n",
-			       cpu_id, ret);
-			goto uninit;
-		}
-	}
-
-	return 0;
-
-uninit:
-	calxeda_idle_cpuidle_devices_uninit();
-unregister_drv:
-	cpuidle_unregister_driver(drv);
-	return ret;
+	return cpuidle_register(&calxeda_idle_driver, NULL);
 }
 module_init(calxeda_cpuidle_init);
-- 
1.7.9.5



From daniel.lezcano at linaro.org  Thu Apr 11 16:42:48 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Thu, 11 Apr 2013 22:42:48 +0200
Subject: [V2 patch 18/19] ARM: davinci: cpuidle: use init/exit common routine
In-Reply-To: <1365712969-7541-1-git-send-email-daniel.lezcano@linaro.org>
References: <1365712969-7541-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1365712969-7541-19-git-send-email-daniel.lezcano@linaro.org>

Remove the duplicated code and use the cpuidle common code for initialization.

Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
---
 arch/arm/mach-davinci/cpuidle.c |   20 +-------------------
 1 file changed, 1 insertion(+), 19 deletions(-)

diff --git a/arch/arm/mach-davinci/cpuidle.c b/arch/arm/mach-davinci/cpuidle.c
index c2887c5..36aef3a 100644
--- a/arch/arm/mach-davinci/cpuidle.c
+++ b/arch/arm/mach-davinci/cpuidle.c
@@ -25,7 +25,6 @@
 
 #define DAVINCI_CPUIDLE_MAX_STATES	2
 
-static DEFINE_PER_CPU(struct cpuidle_device, davinci_cpuidle_device);
 static void __iomem *ddr2_reg_base;
 static bool ddr2_pdown;
 
@@ -76,12 +75,8 @@ static struct cpuidle_driver davinci_idle_driver = {
 
 static int __init davinci_cpuidle_probe(struct platform_device *pdev)
 {
-	int ret;
-	struct cpuidle_device *device;
 	struct davinci_cpuidle_config *pdata = pdev->dev.platform_data;
 
-	device = &per_cpu(davinci_cpuidle_device, smp_processor_id());
-
 	if (!pdata) {
 		dev_err(&pdev->dev, "cannot get platform data\n");
 		return -ENOENT;
@@ -91,20 +86,7 @@ static int __init davinci_cpuidle_probe(struct platform_device *pdev)
 
 	ddr2_pdown = pdata->ddr2_pdown;
 
-	ret = cpuidle_register_driver(&davinci_idle_driver);
-	if (ret) {
-		dev_err(&pdev->dev, "failed to register driver\n");
-		return ret;
-	}
-
-	ret = cpuidle_register_device(device);
-	if (ret) {
-		dev_err(&pdev->dev, "failed to register device\n");
-		cpuidle_unregister_driver(&davinci_idle_driver);
-		return ret;
-	}
-
-	return 0;
+	return cpuidle_register(&davinci_idle_driver, NULL);
 }
 
 static struct platform_driver davinci_cpuidle_driver = {
-- 
1.7.9.5



From daniel.lezcano at linaro.org  Thu Apr 11 16:42:49 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Thu, 11 Apr 2013 22:42:49 +0200
Subject: [V2 patch 19/19] ARM: imx: cpuidle: use init/exit common routine
In-Reply-To: <1365712969-7541-1-git-send-email-daniel.lezcano@linaro.org>
References: <1365712969-7541-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1365712969-7541-20-git-send-email-daniel.lezcano@linaro.org>

Remove the duplicated code and use the cpuidle common code for initialization.

Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
---
 arch/arm/mach-imx/cpuidle-imx5.c  |   36 +-----------------------------------
 arch/arm/mach-imx/cpuidle-imx6q.c |   36 +-----------------------------------
 2 files changed, 2 insertions(+), 70 deletions(-)

diff --git a/arch/arm/mach-imx/cpuidle-imx5.c b/arch/arm/mach-imx/cpuidle-imx5.c
index 3d9f0c9..ba4565f 100644
--- a/arch/arm/mach-imx/cpuidle-imx5.c
+++ b/arch/arm/mach-imx/cpuidle-imx5.c
@@ -13,8 +13,6 @@
 
 #include "hardware.h"
 
-static DEFINE_PER_CPU(struct cpuidle_device, devices);
-
 static int imx5_cpuidle_enter(struct cpuidle_device *dev,
 			      struct cpuidle_driver *drv, int index)
 {
@@ -38,37 +36,5 @@ static struct cpuidle_driver imx5_cpuidle_driver = {
 
 int __init imx5_cpuidle_init(void)
 {
-	struct cpuidle_device *dev;
-	int cpu, ret;
-
-	ret = cpuidle_register_driver(&imx5_cpuidle_driver);
-	if (ret) {
-		pr_err("%s: Failed to register cpuidle driver with error: %d\n",
-			 __func__, ret);
-		return ret;
-	}
-
-	/* initialize state data for each cpuidle_device */
-	for_each_possible_cpu(cpu) {
-		dev = &per_cpu(devices, cpu);
-		dev->cpu = cpu;
-
-		ret = cpuidle_register_device(dev);
-		if (ret) {
-			pr_err("%s: Failed to register cpu %u, error: %d\n",
-				__func__, cpu, ret);
-			goto out_unregister;
-		}
-	}
-
-	return 0;
-
-out_unregister:
-	for_each_possible_cpu(cpu) {
-		dev = &per_cpu(devices, cpu);
-		cpuidle_unregister_device(dev);
-	}
-
-	cpuidle_unregister_driver(&imx5_cpuidle_driver);
-	return ret;
+	return cpuidle_register(&imx5_cpuidle_driver, NULL);
 }
diff --git a/arch/arm/mach-imx/cpuidle-imx6q.c b/arch/arm/mach-imx/cpuidle-imx6q.c
index c066b74faa..23ddfb6 100644
--- a/arch/arm/mach-imx/cpuidle-imx6q.c
+++ b/arch/arm/mach-imx/cpuidle-imx6q.c
@@ -14,8 +14,6 @@
 #include "common.h"
 #include "cpuidle.h"
 
-static DEFINE_PER_CPU(struct cpuidle_device, devices);
-
 static atomic_t master = ATOMIC_INIT(0);
 static DEFINE_SPINLOCK(master_lock);
 
@@ -67,43 +65,11 @@ static struct cpuidle_driver imx6q_cpuidle_driver = {
 
 int __init imx6q_cpuidle_init(void)
 {
-	struct cpuidle_device *dev;
-	int cpu, ret;
-
 	/* Need to enable SCU standby for entering WAIT modes */
 	imx_scu_standby_enable();
 
 	/* Set chicken bit to get a reliable WAIT mode support */
 	imx6q_set_chicken_bit();
 
-	ret = cpuidle_register_driver(&imx6q_cpuidle_driver);
-	if (ret) {
-		pr_err("%s: Failed to register cpuidle driver with error: %d\n",
-			 __func__, ret);
-		return ret;
-	}
-
-	/* initialize state data for each cpuidle_device */
-	for_each_possible_cpu(cpu) {
-		dev = &per_cpu(devices, cpu);
-		dev->cpu = cpu;
-
-		ret = cpuidle_register_device(dev);
-		if (ret) {
-			pr_err("%s: Failed to register cpu %u, error: %d\n",
-				__func__, cpu, ret);
-			goto out_unregister;
-		}
-	}
-
-	return 0;
-
-out_unregister:
-	for_each_possible_cpu(cpu) {
-		dev = &per_cpu(devices, cpu);
-		cpuidle_unregister_device(dev);
-	}
-
-	cpuidle_unregister_driver(&imx6q_cpuidle_driver);
-	return ret;
+	return cpuidle_register(&imx6q_cpuidle_driver, NULL);
 }
-- 
1.7.9.5



From daniel.lezcano at linaro.org  Thu Apr 11 16:42:40 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Thu, 11 Apr 2013 22:42:40 +0200
Subject: [V2 patch 10/19] ARM: s3c64xx: cpuidle: use init/exit common routine
In-Reply-To: <1365712969-7541-1-git-send-email-daniel.lezcano@linaro.org>
References: <1365712969-7541-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1365712969-7541-11-git-send-email-daniel.lezcano@linaro.org>

Remove the duplicated code and use the cpuidle common code for initialization.

Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
---
 arch/arm/mach-s3c64xx/cpuidle.c |   14 +-------------
 1 file changed, 1 insertion(+), 13 deletions(-)

diff --git a/arch/arm/mach-s3c64xx/cpuidle.c b/arch/arm/mach-s3c64xx/cpuidle.c
index 852ff16..3c8ab07 100644
--- a/arch/arm/mach-s3c64xx/cpuidle.c
+++ b/arch/arm/mach-s3c64xx/cpuidle.c
@@ -40,8 +40,6 @@ static int s3c64xx_enter_idle(struct cpuidle_device *dev,
 	return index;
 }
 
-static DEFINE_PER_CPU(struct cpuidle_device, s3c64xx_cpuidle_device);
-
 static struct cpuidle_driver s3c64xx_cpuidle_driver = {
 	.name	= "s3c64xx_cpuidle",
 	.owner  = THIS_MODULE,
@@ -60,16 +58,6 @@ static struct cpuidle_driver s3c64xx_cpuidle_driver = {
 
 static int __init s3c64xx_init_cpuidle(void)
 {
-	int ret;
-
-	cpuidle_register_driver(&s3c64xx_cpuidle_driver);
-
-	ret = cpuidle_register_device(&s3c64xx_cpuidle_device);
-	if (ret) {
-		pr_err("Failed to register cpuidle device: %d\n", ret);
-		return ret;
-	}
-
-	return 0;
+	return cpuidle_register(&s3c64xx_cpuidle_driver, NULL);
 }
 device_initcall(s3c64xx_init_cpuidle);
-- 
1.7.9.5



From robherring2 at gmail.com  Thu Apr 11 16:44:36 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Thu, 11 Apr 2013 15:44:36 -0500
Subject: [GIT PULL] Timer clean-ups for 3.10, Part 2
Message-ID: <516720B4.3000703@gmail.com>

Olof, Arnd,

Please pull timer clean-ups for arch timer, sp804, and integrator-cp timers.

I've dropped the final patch which moved the sp804 and integrator timers
code to drivers/clocksource until the desired structure is worked out.

Simon, the fixes for shmobile were trivial. Please comment if you see
any issues.

Rob

The following changes since commit 3d5a96582303e28c48699f3faaf920ef7d43e6f2:

  clocksource: make CLOCKSOURCE_OF_DECLARE type safe (2013-03-28
12:01:06 +0100)

are available in the git repository at:

  git://sources.calxeda.com/kernel/linux.git
tags/clksrc-cleanup-for-3.10-part2

for you to fetch changes up to 69a517b2471bcd1c5a175aad82647c1e2c24f08b:

  devtree: add binding documentation for sp804 (2013-04-11 15:11:22 -0500)

----------------------------------------------------------------
This is the 2nd part of ARM timer clean-ups for 3.10. This series has
the following changes:

- Add sched_clock selection logic to select the highest frequency clock
- Use full 64-bit arch timer counter for sched_clock
- Convert arch timer, sp804 and integrator-cp timers to CLKSRC_OF and
adapt all users to use clocksource_of_init

----------------------------------------------------------------
Arnd Bergmann (1):
      ARM: make machine_desc->init_time default to clocksource_of_init

Haojian Zhuang (1):
      devtree: add binding documentation for sp804

Rob Herring (13):
      ARM: sched_clock: allow changing to higher frequency counter
      ARM: make sched_clock just call a function pointer
      ARM: arch_timer: use full 64-bit counter for sched_clock
      ARM: convert arm/arm64 arch timer to use CLKSRC_OF init
      OF: add empty of_device_is_available for !OF
      ARM: timer-sp: convert to use CLKSRC_OF init
      ARM: highbank: use OF init for sp804 timer
      ARM: vexpress: remove sp804 OF init
      ARM: dts: vexpress: disable CA9 core tile sp804 timer
      ARM: vexpress: remove extra timer-sp control register clearing
      ARM: versatile: add versatile dtbs to dtbs target
      ARM: versatile: use OF init for sp804 timer
      ARM: integrator-cp: convert use CLKSRC_OF for timer init

 .../devicetree/bindings/timer/arm,sp804.txt        |   29 ++++
 arch/arm/Kconfig                                   |    1 +
 arch/arm/boot/dts/Makefile                         |    2 +
 arch/arm/boot/dts/integratorcp.dts                 |    6 +-
 arch/arm/boot/dts/versatile-ab.dts                 |   12 ++
 arch/arm/boot/dts/vexpress-v2p-ca9.dts             |    1 +
 arch/arm/common/timer-sp.c                         |  140
+++++++++++++++++---
 arch/arm/include/asm/arch_timer.h                  |   13 +-
 arch/arm/include/asm/hardware/timer-sp.h           |   16 ++-
 arch/arm/include/asm/sched_clock.h                 |    2 +
 arch/arm/kernel/arch_timer.c                       |   29 ++--
 arch/arm/kernel/sched_clock.c                      |   15 ++-
 arch/arm/kernel/time.c                             |    7 +-
 arch/arm/mach-exynos/mach-exynos5-dt.c             |    1 -
 arch/arm/mach-exynos/mct.c                         |    6 -
 arch/arm/mach-highbank/highbank.c                  |   24 +---
 arch/arm/mach-integrator/integrator_cp.c           |   34 -----
 arch/arm/mach-omap2/timer.c                        |    5 +-
 arch/arm/mach-shmobile/board-kzm9d.c               |    1 -
 arch/arm/mach-shmobile/setup-emev2.c               |    1 -
 arch/arm/mach-shmobile/setup-r8a7740.c             |    1 -
 arch/arm/mach-shmobile/setup-sh7372.c              |    1 -
 arch/arm/mach-shmobile/setup-sh73a0.c              |    1 -
 arch/arm/mach-shmobile/timer.c                     |    7 +-
 arch/arm/mach-versatile/core.c                     |   26 ++--
 arch/arm/mach-versatile/versatile_dt.c             |    1 -
 arch/arm/mach-vexpress/v2m.c                       |   21 +--
 arch/arm/mach-virt/virt.c                          |    9 --
 arch/arm64/include/asm/arch_timer.h                |    5 +
 arch/arm64/kernel/time.c                           |    6 +-
 drivers/clocksource/Kconfig                        |    1 +
 drivers/clocksource/arm_arch_timer.c               |   23 ++--
 include/clocksource/arm_arch_timer.h               |    6 -
 include/linux/of.h                                 |    5 +
 34 files changed, 262 insertions(+), 196 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/timer/arm,sp804.txt


From gregory.clement at free-electrons.com  Thu Apr 11 16:48:27 2013
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Thu, 11 Apr 2013 22:48:27 +0200
Subject: [PATCH v3 5/9] ARM: dts: Add a 64 bits version of the skeleton
 device tree
In-Reply-To: <20130411181200.GP28693@titan.lakedaemon.net>
References: <1365461538-30702-1-git-send-email-gregory.clement@free-electrons.com>
 <1365461538-30702-6-git-send-email-gregory.clement@free-electrons.com>
 <20130411181200.GP28693@titan.lakedaemon.net>
Message-ID: <5167219B.8070404@free-electrons.com>

Hi Jason,

On 04/11/2013 08:12 PM, Jason Cooper wrote:
> On Tue, Apr 09, 2013 at 12:52:13AM +0200, Gregory CLEMENT wrote:
>> From: Lior Amsalem <alior at marvell.com>
>>
>> In order to be able to use more than 4GB address-cells and size-cells
>> have to be set to 2
>>
>> Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
>> Signed-off-by: Lior Amsalem <alior at marvell.com>
>> ---
>>  arch/arm/boot/dts/skeleton64.dtsi |   13 +++++++++++++
>>  1 file changed, 13 insertions(+)
>>  create mode 100644 arch/arm/boot/dts/skeleton64.dtsi
> 
> Applied to mvebu/dt
> 
> Gregory,
> 
> Once I can pull in Thomas' pci work, you'll just need to rebase patches
> 1, and 6 - 9 against mvebu/dt.
> 

Yes sure! When did you plan to pull the dts part of Thomas' pci work?
Is there still anything left to prevent to pull this part?

Thanks,
-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From arnd at arndb.de  Thu Apr 11 16:49:39 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 11 Apr 2013 22:49:39 +0200
Subject: [PATCH v3] usb: exynos: do not include plat/usb-phy.h
In-Reply-To: <20130411202540.GA32047@kroah.com>
References: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
 <1365638712-1028578-11-git-send-email-arnd@arndb.de>
 <20130411202540.GA32047@kroah.com>
Message-ID: <201304112249.39549.arnd@arndb.de>

The definitions have moved to include/linux/usb/samsung-usb-phy.h,
and plat/usb-phy.h is unavailable from drivers in a multiplatform
configuration.

Also fix up the plat/usb-phy.h header file to use the definitions
from the new header instead of providing a separate copy.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Cc: linux-usb at vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
Cc: Alan Stern <stern at rowland.harvard.edu>
---
v3: rebase to usb-next (2871782ae1)

v2: rebase whole series on top of arm-soc for testing

diff --git a/arch/arm/mach-exynos/setup-usb-phy.c b/arch/arm/mach-exynos/setup-usb-phy.c
index b81cc56..6af4066 100644
--- a/arch/arm/mach-exynos/setup-usb-phy.c
+++ b/arch/arm/mach-exynos/setup-usb-phy.c
@@ -204,9 +204,9 @@ static int exynos4210_usb_phy1_exit(struct platform_device *pdev)
 
 int s5p_usb_phy_init(struct platform_device *pdev, int type)
 {
-	if (type == S5P_USB_PHY_DEVICE)
+	if (type == USB_PHY_TYPE_DEVICE)
 		return exynos4210_usb_phy0_init(pdev);
-	else if (type == S5P_USB_PHY_HOST)
+	else if (type == USB_PHY_TYPE_HOST)
 		return exynos4210_usb_phy1_init(pdev);
 
 	return -EINVAL;
@@ -214,9 +214,9 @@ int s5p_usb_phy_init(struct platform_device *pdev, int type)
 
 int s5p_usb_phy_exit(struct platform_device *pdev, int type)
 {
-	if (type == S5P_USB_PHY_DEVICE)
+	if (type == USB_PHY_TYPE_DEVICE)
 		return exynos4210_usb_phy0_exit(pdev);
-	else if (type == S5P_USB_PHY_HOST)
+	else if (type == USB_PHY_TYPE_HOST)
 		return exynos4210_usb_phy1_exit(pdev);
 
 	return -EINVAL;
diff --git a/arch/arm/mach-s3c64xx/setup-usb-phy.c b/arch/arm/mach-s3c64xx/setup-usb-phy.c
index c8174d9..ca960bd 100644
--- a/arch/arm/mach-s3c64xx/setup-usb-phy.c
+++ b/arch/arm/mach-s3c64xx/setup-usb-phy.c
@@ -76,7 +76,7 @@ static int s3c_usb_otgphy_exit(struct platform_device *pdev)
 
 int s5p_usb_phy_init(struct platform_device *pdev, int type)
 {
-	if (type == S5P_USB_PHY_DEVICE)
+	if (type == USB_PHY_TYPE_DEVICE)
 		return s3c_usb_otgphy_init(pdev);
 
 	return -EINVAL;
@@ -84,7 +84,7 @@ int s5p_usb_phy_init(struct platform_device *pdev, int type)
 
 int s5p_usb_phy_exit(struct platform_device *pdev, int type)
 {
-	if (type == S5P_USB_PHY_DEVICE)
+	if (type == USB_PHY_TYPE_DEVICE)
 		return s3c_usb_otgphy_exit(pdev);
 
 	return -EINVAL;
diff --git a/arch/arm/mach-s5pv210/setup-usb-phy.c b/arch/arm/mach-s5pv210/setup-usb-phy.c
index 356a090..b2ee533 100644
--- a/arch/arm/mach-s5pv210/setup-usb-phy.c
+++ b/arch/arm/mach-s5pv210/setup-usb-phy.c
@@ -80,7 +80,7 @@ static int s5pv210_usb_otgphy_exit(struct platform_device *pdev)
 
 int s5p_usb_phy_init(struct platform_device *pdev, int type)
 {
-	if (type == S5P_USB_PHY_DEVICE)
+	if (type == USB_PHY_TYPE_DEVICE)
 		return s5pv210_usb_otgphy_init(pdev);
 
 	return -EINVAL;
@@ -88,7 +88,7 @@ int s5p_usb_phy_init(struct platform_device *pdev, int type)
 
 int s5p_usb_phy_exit(struct platform_device *pdev, int type)
 {
-	if (type == S5P_USB_PHY_DEVICE)
+	if (type == USB_PHY_TYPE_DEVICE)
 		return s5pv210_usb_otgphy_exit(pdev);
 
 	return -EINVAL;
diff --git a/arch/arm/plat-samsung/include/plat/usb-phy.h b/arch/arm/plat-samsung/include/plat/usb-phy.h
index 959bcdb..ab34dfa 100644
--- a/arch/arm/plat-samsung/include/plat/usb-phy.h
+++ b/arch/arm/plat-samsung/include/plat/usb-phy.h
@@ -11,10 +11,7 @@
 #ifndef __PLAT_SAMSUNG_USB_PHY_H
 #define __PLAT_SAMSUNG_USB_PHY_H __FILE__
 
-enum s5p_usb_phy_type {
-	S5P_USB_PHY_DEVICE,
-	S5P_USB_PHY_HOST,
-};
+#include <linux/usb/samsung_usb_phy.h>
 
 extern int s5p_usb_phy_init(struct platform_device *pdev, int type);
 extern int s5p_usb_phy_exit(struct platform_device *pdev, int type);
diff --git a/drivers/usb/host/ehci-s5p.c b/drivers/usb/host/ehci-s5p.c
index 580548a..6357752 100644
--- a/drivers/usb/host/ehci-s5p.c
+++ b/drivers/usb/host/ehci-s5p.c
@@ -23,7 +23,6 @@
 #include <linux/platform_data/usb-ehci-s5p.h>
 #include <linux/usb/phy.h>
 #include <linux/usb/samsung_usb_phy.h>
-#include <plat/usb-phy.h>
 #include <linux/usb.h>
 #include <linux/usb/hcd.h>
 #include <linux/usb/otg.h>
diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
index 509fa51..114583a 100644
--- a/drivers/usb/host/ohci-exynos.c
+++ b/drivers/usb/host/ohci-exynos.c
@@ -17,7 +17,6 @@
 #include <linux/platform_data/usb-exynos.h>
 #include <linux/usb/phy.h>
 #include <linux/usb/samsung_usb_phy.h>
-#include <plat/usb-phy.h>
 
 struct exynos_ohci_hcd {
 	struct device *dev;


From daniel.lezcano at linaro.org  Thu Apr 11 16:42:31 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Thu, 11 Apr 2013 22:42:31 +0200
Subject: [V2 patch 01/19] ARM: shmobile: cpuidle: remove shmobile_enter_wfi
 function
In-Reply-To: <1365712969-7541-1-git-send-email-daniel.lezcano@linaro.org>
References: <1365712969-7541-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1365712969-7541-2-git-send-email-daniel.lezcano@linaro.org>

Remove the shmobile_enter_wfi function which is the same as the
common WFI enter function from the arm cpuidle driver defined
with the ARM_CPUIDLE_WFI_STATE macro.

Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
---
 arch/arm/mach-shmobile/include/mach/common.h |    3 ---
 arch/arm/mach-shmobile/pm-sh7372.c           |    1 -
 2 files changed, 4 deletions(-)

diff --git a/arch/arm/mach-shmobile/include/mach/common.h b/arch/arm/mach-shmobile/include/mach/common.h
index e48606d..362f9b2 100644
--- a/arch/arm/mach-shmobile/include/mach/common.h
+++ b/arch/arm/mach-shmobile/include/mach/common.h
@@ -13,9 +13,6 @@ extern int shmobile_clk_init(void);
 extern void shmobile_handle_irq_intc(struct pt_regs *);
 extern struct platform_suspend_ops shmobile_suspend_ops;
 struct cpuidle_driver;
-struct cpuidle_device;
-extern int shmobile_enter_wfi(struct cpuidle_device *dev,
-			      struct cpuidle_driver *drv, int index);
 extern void shmobile_cpuidle_set_driver(struct cpuidle_driver *drv);
 
 extern void sh7372_init_irq(void);
diff --git a/arch/arm/mach-shmobile/pm-sh7372.c b/arch/arm/mach-shmobile/pm-sh7372.c
index f6b14ca..fbef7b9 100644
--- a/arch/arm/mach-shmobile/pm-sh7372.c
+++ b/arch/arm/mach-shmobile/pm-sh7372.c
@@ -414,7 +414,6 @@ static struct cpuidle_driver sh7372_cpuidle_driver = {
 	.state_count		= 5,
 	.safe_state_index	= 0, /* C1 */
 	.states[0] = ARM_CPUIDLE_WFI_STATE,
-	.states[0].enter = shmobile_enter_wfi,
 	.states[1] = {
 		.name = "C2",
 		.desc = "Core Standby Mode",
-- 
1.7.9.5



From arnd at arndb.de  Thu Apr 11 16:57:07 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 11 Apr 2013 22:57:07 +0200
Subject: [GIT PULL] Timer clean-ups for 3.10, Part 2
In-Reply-To: <516720B4.3000703@gmail.com>
References: <516720B4.3000703@gmail.com>
Message-ID: <201304112257.07645.arnd@arndb.de>

On Thursday 11 April 2013, Rob Herring wrote:
> Olof, Arnd,
> 
> Please pull timer clean-ups for arch timer, sp804, and integrator-cp timers.
> 
> I've dropped the final patch which moved the sp804 and integrator timers
> code to drivers/clocksource until the desired structure is worked out.
> 
> Simon, the fixes for shmobile were trivial. Please comment if you see
> any issues.

Ok, nice!

There are various bits for which I'd like to see Russell's ACK before
we send them Linuswards, but it all looks good to me.

I would put it into arm-soc tomorrow, and hopefully Haojian Zhuang is
able to send an updated version of his hisilicon platform code based
on top of this in time for the merge window. The patches are all
reviewed but just waiting for the sp804 changes now, and since
it's a new platform, I'm not worried about regressions.

	Arnd


From arnd at arndb.de  Thu Apr 11 17:08:13 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 11 Apr 2013 23:08:13 +0200
Subject: [PATCH v4 04/14] mfd: Add Samsung PWM/timer master driver
In-Reply-To: <1718887.H9vPuvORKd@amdc1227>
References: <1365093431-30621-1-git-send-email-t.figa@samsung.com>
 <201304110035.47776.arnd@arndb.de> <1718887.H9vPuvORKd@amdc1227>
Message-ID: <201304112308.14181.arnd@arndb.de>

On Thursday 11 April 2013, Tomasz Figa wrote:
> On Thursday 11 of April 2013 00:35:47 Arnd Bergmann wrote:
> > On Monday 08 April 2013, Tomasz Figa wrote:
> > > On Saturday 06 of April 2013 00:24:18 Tomasz Figa wrote:
> > > > On Friday 05 of April 2013 21:54:21 Arnd Bergmann wrote:
> > > > > On Friday 05 April 2013, Tomasz Figa wrote:
> > 
> > Sorry for not replying earlier. My idea for the register level interface
> > was to create a platform_device for each PWM, e.g. using the mfd_cell
> > infrastructure. You can then pass a "struct regmap" as the platform
> > data for each child of the timer node, and all the DT handling code
> > can stay in the parent driver.
> 
> Hmm. As I said, I'm completely fine with using a regmap for sharing registers 
> between subdrivers. However the clocksource can not be registered as an MFD 
> cell, because it's needed very early.
> 
> I can imagine a solution alternative to my original one, where the MFD cells 
> would be registered from the clocksource driver. This would mean that 
> platforms that don't need (and can't use) the PWM clocksource would have to 
> enable the driver anyway.

Sounds ok to me. The main part I want to avoid is having two separate device
nodes in the DT for one physical device, but there are multiple ways to get
there.

> Another thing is that I don't see a need to create one cell per PWM channel. 
> The PWM core is designed in a way that supports multiple channels per PWM 
> controller and so is the generic PWM DT specifier (<&controller channel period 
> flags>), so I'd rather see a single cell for all PWM channels.

Sure, no problem with that.

> So, to summarize this alternative concept:
>  - two drivers:
>    1) clocksource driver - registering clocksource and PWM MFD cell
>    2) PWM driver - handling the PWM MFD cell

Ok. Don't be too tied to the MFD concept though if it causes problems.
In many cases calling platform_device_register_resndata or similar is
actually easier than MFD, especially if you only want a single child
device. Either way is fine though.

>  - both drivers would share registers using a regmap with custom lock/unlock 
>    callbacks (using spin_lock_irqsave/spin_unlock_irqrestore, because the 
>    clocksource needs to access PWM registers in IRQ context)

Ok.

>  - the clocksource/master driver would have a samsung_time_init function which 
>    would set up the driver early and initialize the clocksource

Right. If you want to use the clocksource_of_init() infratstructure for this
(which is probably a good idea), please base your series on top of the
clksrc/cleanup branch in arm-soc.

>  - a platform driver would be registered by the clocksource/master driver
>    which would register the PWM MFD cell in its probe.

This seems unnecessary, if the only purpose of the platform driver is to
export the MFD cell. In that case, I would actually suggest a simpler model
where the PWM driver registers the main platform driver directly and
calls a function exported by the clocksource driver to get the regmap
structure and anything else it may need (possibly initializing the driver
in the case where it is not used as the clocksource but only provides
the registers for PWM).

>  - MFD cell platform data would contain struct regmap * and variant data
>    (parsed from DT or received from platform code - as in my original version)

Yes, either the MFD cell, or the exported symbol, whichever ends up easier.

> This should indeed work, assuming that I find a solution to make 
> clocksource_of_init not initialize the PWM clocksource (from PWM DT node) on 
> platforms that can't use it.

Right. If anything else comes up, I'd suggest we discuss it on IRC (#armlinux
on irc.freenode.net) tomorrow for faster round-trip, or I can call you on
the phone if you like. I'm available all day tomorrow, just send me your
(landline) phone number by private email.

	Arnd.


From rjw at sisk.pl  Thu Apr 11 17:33:31 2013
From: rjw at sisk.pl (Rafael J. Wysocki)
Date: Thu, 11 Apr 2013 23:33:31 +0200
Subject: [PATCH] cpufreq: dbx500: Round to closest available freq
In-Reply-To: <CACRpkdb75wPjXEYdkqE6BOCsuFA_ZBc6GAz1m-5vHWSrSGKyUA@mail.gmail.com>
References: <1365599175-22361-1-git-send-email-ulf.hansson@stericsson.com>
 <CACRpkdb75wPjXEYdkqE6BOCsuFA_ZBc6GAz1m-5vHWSrSGKyUA@mail.gmail.com>
Message-ID: <1512269.3ZuqNVLx3s@vostro.rjw.lan>

On Thursday, April 11, 2013 10:33:07 PM Linus Walleij wrote:
> On Wed, Apr 10, 2013 at 3:06 PM, Ulf Hansson <ulf.hansson at stericsson.com> wrote:
> 
> > From: Mats Fagerstrom <mats.fagerstrom at stericsson.com>
> >
> > When reading the cpu speed, round it to the closest available
> > frequency from the table.
> >
> > Signed-off-by: Ulf Hansson <ulf.hansson at linaro.org>
> > Signed-off-by: Mats Fagerstrom <mats.fagerstrom at stericsson.com>
> 
> (...)
> > +       /* The value is rounded to closest frequency in the defined table. */
> > +       while (freq_table[i + 1].frequency != CPUFREQ_TABLE_END) {
> > +               if (freq < freq_table[i].frequency +
> > +                  (freq_table[i + 1].frequency - freq_table[i].frequency) / 2)
> >                         return freq_table[i].frequency;
> 
> Oh that works, clever.
> 
> Acked-by: Linus Walleij <linus.walleij at linaro.org>

Thanks, applied.

Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.


From arnd at arndb.de  Thu Apr 11 17:37:16 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 11 Apr 2013 23:37:16 +0200
Subject: [PATCH v3 01/10] ARM: exynos: introduce EXYNOS_ATAGS symbol
In-Reply-To: <1365716245-99231-1-git-send-email-arnd@arndb.de>
References: <1365716245-99231-1-git-send-email-arnd@arndb.de>
Message-ID: <1365716245-99231-2-git-send-email-arnd@arndb.de>

As a preparation for multiplatform support, this introduces
a new Kconfig symbol to split the ATAGS based EXYNOS platforms
from the DT based ones. Turning off CONFIG_EXYNOS_ATAGS disables
all platforms that are not yet converted to DT, and we can
have code that relies on DT checking for this symbol being
disabled.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 arch/arm/mach-exynos/Kconfig | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index 70f94c8..33e2336 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -85,6 +85,19 @@ config EXYNOS4_MCT
 	help
 	  Use MCT (Multi Core Timer) as kernel timers
 
+config EXYNOS_ATAGS
+	bool "ATAGS based boot for EXYNOS (deprecated)"
+	depends on ARCH_EXYNOS_SINGLE
+	depends on ATAGS
+	default y
+	help
+	  The EXYNOS platform is moving towards being completely probed
+	  through device tree. This enables support for board files using
+	  the traditional ATAGS boot format.
+	  Note that this option is not available for multiplatform builds.
+
+if EXYNOS_ATAGS
+
 config EXYNOS_DEV_DMA
 	bool
 	help
@@ -400,6 +413,8 @@ config MACH_SMDK4412
 	  Machine support for Samsung SMDK4412
 endif
 
+endif
+
 comment "Flattened Device Tree based board for EXYNOS SoCs"
 
 config MACH_EXYNOS4_DT
-- 
1.8.1.2



From arnd at arndb.de  Thu Apr 11 17:37:18 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 11 Apr 2013 23:37:18 +0200
Subject: [PATCH v3 03/10] ARM: exynos: move debug-macro.S to include/debug/
In-Reply-To: <1365716245-99231-1-git-send-email-arnd@arndb.de>
References: <1365716245-99231-1-git-send-email-arnd@arndb.de>
Message-ID: <1365716245-99231-4-git-send-email-arnd@arndb.de>

The move is necessary to support early debug output on exynos
with multiplatform configurations. This implies also moving the
plat/debug-macro.S file, but we are leaving the remaining users of that
file in place, to avoid adding large numbers of extra configuration
options to Kconfig.debug

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 arch/arm/Kconfig.debug                                       |  8 ++++++++
 .../include/mach/debug-macro.S => include/debug/exynos.S}    | 12 ++++++------
 .../include/plat/debug-macro.S => include/debug/samsung.S}   |  2 +-
 arch/arm/mach-s3c24xx/include/mach/debug-macro.S             |  2 +-
 arch/arm/mach-s3c64xx/include/mach/debug-macro.S             |  2 +-
 arch/arm/mach-s5p64x0/include/mach/debug-macro.S             |  2 +-
 arch/arm/mach-s5pc100/include/mach/debug-macro.S             |  2 +-
 arch/arm/mach-s5pv210/include/mach/debug-macro.S             |  2 +-
 8 files changed, 20 insertions(+), 12 deletions(-)
 rename arch/arm/{mach-exynos/include/mach/debug-macro.S => include/debug/exynos.S} (84%)
 rename arch/arm/{plat-samsung/include/plat/debug-macro.S => include/debug/samsung.S} (98%)

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 9b31f43..59ce26a 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -330,6 +330,7 @@ choice
 
 	config DEBUG_S3C_UART0
 		depends on PLAT_SAMSUNG
+		select DEBUG_EXYNOS_UART if ARCH_EXYNOS
 		bool "Use S3C UART 0 for low-level debug"
 		help
 		  Say Y here if you want the debug print routines to direct
@@ -341,6 +342,7 @@ choice
 
 	config DEBUG_S3C_UART1
 		depends on PLAT_SAMSUNG
+		select DEBUG_EXYNOS_UART if ARCH_EXYNOS
 		bool "Use S3C UART 1 for low-level debug"
 		help
 		  Say Y here if you want the debug print routines to direct
@@ -352,6 +354,7 @@ choice
 
 	config DEBUG_S3C_UART2
 		depends on PLAT_SAMSUNG
+		select DEBUG_EXYNOS_UART if ARCH_EXYNOS
 		bool "Use S3C UART 2 for low-level debug"
 		help
 		  Say Y here if you want the debug print routines to direct
@@ -363,6 +366,7 @@ choice
 
 	config DEBUG_S3C_UART3
 		depends on PLAT_SAMSUNG && ARCH_EXYNOS
+		select DEBUG_EXYNOS_UART
 		bool "Use S3C UART 3 for low-level debug"
 		help
 		  Say Y here if you want the debug print routines to direct
@@ -485,6 +489,9 @@ choice
 
 endchoice
 
+config DEBUG_EXYNOS_UART
+	bool
+
 config DEBUG_IMX_UART_PORT
 	int "i.MX Debug UART Port Selection" if DEBUG_IMX1_UART || \
 						DEBUG_IMX25_UART || \
@@ -580,6 +587,7 @@ endchoice
 
 config DEBUG_LL_INCLUDE
 	string
+	default "debug/exynos.S" if DEBUG_EXYNOS_UART
 	default "debug/icedcc.S" if DEBUG_ICEDCC
 	default "debug/imx.S" if DEBUG_IMX1_UART || \
 				 DEBUG_IMX25_UART || \
diff --git a/arch/arm/mach-exynos/include/mach/debug-macro.S b/arch/arm/include/debug/exynos.S
similarity index 84%
rename from arch/arm/mach-exynos/include/mach/debug-macro.S
rename to arch/arm/include/debug/exynos.S
index e0c86ea..b17fdb7 100644
--- a/arch/arm/mach-exynos/include/mach/debug-macro.S
+++ b/arch/arm/include/debug/exynos.S
@@ -1,10 +1,7 @@
-/* linux/arch/arm/mach-exynos4/include/mach/debug-macro.S
- *
+/*
  * Copyright (c) 2010-2011 Samsung Electronics Co., Ltd.
  *		http://www.samsung.com
  *
- * Based on arch/arm/mach-s3c6400/include/mach/debug-macro.S
- *
  * 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.
@@ -12,7 +9,10 @@
 
 /* pull in the relevant register and map files. */
 
-#include <mach/map.h>
+#define S3C_ADDR_BASE   0xF6000000
+#define S3C_VA_UART	S3C_ADDR_BASE + 0x01000000
+#define EXYNOS4_PA_UART	0x13800000
+#define EXYNOS5_PA_UART	0x12C00000
 
 	/* note, for the boot process to work we have to keep the UART
 	 * virtual address aligned to an 1MiB boundary for the L1
@@ -36,4 +36,4 @@
 #define fifo_full fifo_full_s5pv210
 #define fifo_level fifo_level_s5pv210
 
-#include <plat/debug-macro.S>
+#include <debug/samsung.S>
diff --git a/arch/arm/plat-samsung/include/plat/debug-macro.S b/arch/arm/include/debug/samsung.S
similarity index 98%
rename from arch/arm/plat-samsung/include/plat/debug-macro.S
rename to arch/arm/include/debug/samsung.S
index f3a9cff..8d8d922 100644
--- a/arch/arm/plat-samsung/include/plat/debug-macro.S
+++ b/arch/arm/include/debug/samsung.S
@@ -9,7 +9,7 @@
  * published by the Free Software Foundation.
 */
 
-#include <plat/regs-serial.h>
+#include <linux/serial_s3c.h>
 
 /* The S5PV210/S5PC110 implementations are as belows. */
 
diff --git a/arch/arm/mach-s3c24xx/include/mach/debug-macro.S b/arch/arm/mach-s3c24xx/include/mach/debug-macro.S
index 13ed33c..2558952 100644
--- a/arch/arm/mach-s3c24xx/include/mach/debug-macro.S
+++ b/arch/arm/mach-s3c24xx/include/mach/debug-macro.S
@@ -98,4 +98,4 @@
 
 /* include the reset of the code which will do the work */
 
-#include <plat/debug-macro.S>
+#include <debug/samsung.S>
diff --git a/arch/arm/mach-s3c64xx/include/mach/debug-macro.S b/arch/arm/mach-s3c64xx/include/mach/debug-macro.S
index c0c076a..dd9ccca 100644
--- a/arch/arm/mach-s3c64xx/include/mach/debug-macro.S
+++ b/arch/arm/mach-s3c64xx/include/mach/debug-macro.S
@@ -35,4 +35,4 @@
  * will be fine with us.
  */
 
-#include <plat/debug-macro.S>
+#include <debug/samsung.S>
diff --git a/arch/arm/mach-s5p64x0/include/mach/debug-macro.S b/arch/arm/mach-s5p64x0/include/mach/debug-macro.S
index e80ba3c..5e2916f 100644
--- a/arch/arm/mach-s5p64x0/include/mach/debug-macro.S
+++ b/arch/arm/mach-s5p64x0/include/mach/debug-macro.S
@@ -30,4 +30,4 @@
 #endif
 	.endm
 
-#include <plat/debug-macro.S>
+#include <debug/samsung.S>
diff --git a/arch/arm/mach-s5pc100/include/mach/debug-macro.S b/arch/arm/mach-s5pc100/include/mach/debug-macro.S
index 694f759..66cb7f1 100644
--- a/arch/arm/mach-s5pc100/include/mach/debug-macro.S
+++ b/arch/arm/mach-s5pc100/include/mach/debug-macro.S
@@ -36,4 +36,4 @@
  * will be fine with us.
  */
 
-#include <plat/debug-macro.S>
+#include <debug/samsung.S>
diff --git a/arch/arm/mach-s5pv210/include/mach/debug-macro.S b/arch/arm/mach-s5pv210/include/mach/debug-macro.S
index 79e5559..80c2199 100644
--- a/arch/arm/mach-s5pv210/include/mach/debug-macro.S
+++ b/arch/arm/mach-s5pv210/include/mach/debug-macro.S
@@ -38,4 +38,4 @@
  * will be fine with us.
  */
 
-#include <plat/debug-macro.S>
+#include <debug/samsung.S>
-- 
1.8.1.2



From arnd at arndb.de  Thu Apr 11 17:37:21 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 11 Apr 2013 23:37:21 +0200
Subject: [PATCH v3 06/10] mmc: sdhci-s3c: remove platform dependencies
In-Reply-To: <1365716245-99231-1-git-send-email-arnd@arndb.de>
References: <1365716245-99231-1-git-send-email-arnd@arndb.de>
Message-ID: <1365716245-99231-7-git-send-email-arnd@arndb.de>

plat/regs-sdhci.h is not used anywhere but in the sdhci-s3c
driver, so it can become a local file there and all other
inclusions removed.

plat/sdhci.h is used only to define the platform devices,
and with the exception of the platform_data structure not
needed by the driver, so we can split out the platform_data
definition instead and leave the rest to platform code.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Acked-by: Chris Ball <cjb at laptop.org>
---
 arch/arm/mach-exynos/setup-sdhci-gpio.c            |  2 +-
 arch/arm/mach-s5pc100/setup-sdhci-gpio.c           |  1 -
 arch/arm/mach-s5pv210/setup-sdhci-gpio.c           |  1 -
 arch/arm/plat-samsung/include/plat/sdhci.h         | 56 +---------------------
 drivers/mmc/host/Kconfig                           |  2 +-
 .../mmc/host/sdhci-s3c-regs.h                      |  0
 drivers/mmc/host/sdhci-s3c.c                       |  5 +-
 include/linux/platform_data/mmc-sdhci-s3c.h        | 56 ++++++++++++++++++++++
 8 files changed, 61 insertions(+), 62 deletions(-)
 rename arch/arm/plat-samsung/include/plat/regs-sdhci.h => drivers/mmc/host/sdhci-s3c-regs.h (100%)
 create mode 100644 include/linux/platform_data/mmc-sdhci-s3c.h

diff --git a/arch/arm/mach-exynos/setup-sdhci-gpio.c b/arch/arm/mach-exynos/setup-sdhci-gpio.c
index e8d08bf..d5b98c8 100644
--- a/arch/arm/mach-exynos/setup-sdhci-gpio.c
+++ b/arch/arm/mach-exynos/setup-sdhci-gpio.c
@@ -19,8 +19,8 @@
 #include <linux/mmc/host.h>
 #include <linux/mmc/card.h>
 
+#include <mach/gpio.h>
 #include <plat/gpio-cfg.h>
-#include <plat/regs-sdhci.h>
 #include <plat/sdhci.h>
 
 void exynos4_setup_sdhci0_cfg_gpio(struct platform_device *dev, int width)
diff --git a/arch/arm/mach-s5pc100/setup-sdhci-gpio.c b/arch/arm/mach-s5pc100/setup-sdhci-gpio.c
index 03c02d0..6010c03 100644
--- a/arch/arm/mach-s5pc100/setup-sdhci-gpio.c
+++ b/arch/arm/mach-s5pc100/setup-sdhci-gpio.c
@@ -19,7 +19,6 @@
 #include <linux/mmc/card.h>
 
 #include <plat/gpio-cfg.h>
-#include <plat/regs-sdhci.h>
 #include <plat/sdhci.h>
 
 void s5pc100_setup_sdhci0_cfg_gpio(struct platform_device *dev, int width)
diff --git a/arch/arm/mach-s5pv210/setup-sdhci-gpio.c b/arch/arm/mach-s5pv210/setup-sdhci-gpio.c
index 3e3ac05..0512ada 100644
--- a/arch/arm/mach-s5pv210/setup-sdhci-gpio.c
+++ b/arch/arm/mach-s5pv210/setup-sdhci-gpio.c
@@ -20,7 +20,6 @@
 #include <linux/mmc/card.h>
 
 #include <plat/gpio-cfg.h>
-#include <plat/regs-sdhci.h>
 #include <plat/sdhci.h>
 
 void s5pv210_setup_sdhci0_cfg_gpio(struct platform_device *dev, int width)
diff --git a/arch/arm/plat-samsung/include/plat/sdhci.h b/arch/arm/plat-samsung/include/plat/sdhci.h
index 9b87f38..1e0aab0 100644
--- a/arch/arm/plat-samsung/include/plat/sdhci.h
+++ b/arch/arm/plat-samsung/include/plat/sdhci.h
@@ -18,62 +18,9 @@
 #ifndef __PLAT_S3C_SDHCI_H
 #define __PLAT_S3C_SDHCI_H __FILE__
 
+#include <linux/platform_data/mmc-sdhci-s3c.h>
 #include <plat/devs.h>
 
-struct platform_device;
-struct mmc_host;
-struct mmc_card;
-struct mmc_ios;
-
-enum cd_types {
-	S3C_SDHCI_CD_INTERNAL,	/* use mmc internal CD line */
-	S3C_SDHCI_CD_EXTERNAL,	/* use external callback */
-	S3C_SDHCI_CD_GPIO,	/* use external gpio pin for CD line */
-	S3C_SDHCI_CD_NONE,	/* no CD line, use polling to detect card */
-	S3C_SDHCI_CD_PERMANENT,	/* no CD line, card permanently wired to host */
-};
-
-/**
- * struct s3c_sdhci_platdata() - Platform device data for Samsung SDHCI
- * @max_width: The maximum number of data bits supported.
- * @host_caps: Standard MMC host capabilities bit field.
- * @host_caps2: The second standard MMC host capabilities bit field.
- * @cd_type: Type of Card Detection method (see cd_types enum above)
- * @ext_cd_init: Initialize external card detect subsystem. Called on
- *		 sdhci-s3c driver probe when cd_type == S3C_SDHCI_CD_EXTERNAL.
- *		 notify_func argument is a callback to the sdhci-s3c driver
- *		 that triggers the card detection event. Callback arguments:
- *		 dev is pointer to platform device of the host controller,
- *		 state is new state of the card (0 - removed, 1 - inserted).
- * @ext_cd_cleanup: Cleanup external card detect subsystem. Called on
- *		 sdhci-s3c driver remove when cd_type == S3C_SDHCI_CD_EXTERNAL.
- *		 notify_func argument is the same callback as for ext_cd_init.
- * @ext_cd_gpio: gpio pin used for external CD line, valid only if
- *		 cd_type == S3C_SDHCI_CD_GPIO
- * @ext_cd_gpio_invert: invert values for external CD gpio line
- * @cfg_gpio: Configure the GPIO for a specific card bit-width
- *
- * Initialisation data specific to either the machine or the platform
- * for the device driver to use or call-back when configuring gpio or
- * card speed information.
-*/
-struct s3c_sdhci_platdata {
-	unsigned int	max_width;
-	unsigned int	host_caps;
-	unsigned int	host_caps2;
-	unsigned int	pm_caps;
-	enum cd_types	cd_type;
-
-	int		ext_cd_gpio;
-	bool		ext_cd_gpio_invert;
-	int	(*ext_cd_init)(void (*notify_func)(struct platform_device *,
-						   int state));
-	int	(*ext_cd_cleanup)(void (*notify_func)(struct platform_device *,
-						      int state));
-
-	void	(*cfg_gpio)(struct platform_device *dev, int width);
-};
-
 /* s3c_sdhci_set_platdata() - common helper for setting SDHCI platform data
  * @pd: The default platform data for this device.
  * @set: Pointer to the platform data to fill in.
@@ -378,5 +325,4 @@ static inline void s3c_sdhci_setname(int id, char *name)
 		break;
 	}
 }
-
 #endif /* __PLAT_S3C_SDHCI_H */
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index d88219e..d054744 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -180,7 +180,7 @@ config MMC_SDHCI_TEGRA
 
 config MMC_SDHCI_S3C
 	tristate "SDHCI support on Samsung S3C SoC"
-	depends on MMC_SDHCI && PLAT_SAMSUNG
+	depends on MMC_SDHCI && PLAT_SAMSUNG_SINGLE
 	help
 	  This selects the Secure Digital Host Controller Interface (SDHCI)
 	  often referrered to as the HSMMC block in some of the Samsung S3C
diff --git a/arch/arm/plat-samsung/include/plat/regs-sdhci.h b/drivers/mmc/host/sdhci-s3c-regs.h
similarity index 100%
rename from arch/arm/plat-samsung/include/plat/regs-sdhci.h
rename to drivers/mmc/host/sdhci-s3c-regs.h
diff --git a/drivers/mmc/host/sdhci-s3c.c b/drivers/mmc/host/sdhci-s3c.c
index 7363efe..e4f52b5 100644
--- a/drivers/mmc/host/sdhci-s3c.c
+++ b/drivers/mmc/host/sdhci-s3c.c
@@ -15,6 +15,7 @@
 #include <linux/delay.h>
 #include <linux/dma-mapping.h>
 #include <linux/platform_device.h>
+#include <linux/platform_data/mmc-sdhci-s3c.h>
 #include <linux/slab.h>
 #include <linux/clk.h>
 #include <linux/io.h>
@@ -28,9 +29,7 @@
 
 #include <linux/mmc/host.h>
 
-#include <plat/sdhci.h>
-#include <plat/regs-sdhci.h>
-
+#include "sdhci-s3c-regs.h"
 #include "sdhci.h"
 
 #define MAX_BUS_CLK	(4)
diff --git a/include/linux/platform_data/mmc-sdhci-s3c.h b/include/linux/platform_data/mmc-sdhci-s3c.h
new file mode 100644
index 0000000..249f023
--- /dev/null
+++ b/include/linux/platform_data/mmc-sdhci-s3c.h
@@ -0,0 +1,56 @@
+#ifndef __PLATFORM_DATA_SDHCI_S3C_H
+#define __PLATFORM_DATA_SDHCI_S3C_H
+
+struct platform_device;
+
+enum cd_types {
+	S3C_SDHCI_CD_INTERNAL,	/* use mmc internal CD line */
+	S3C_SDHCI_CD_EXTERNAL,	/* use external callback */
+	S3C_SDHCI_CD_GPIO,	/* use external gpio pin for CD line */
+	S3C_SDHCI_CD_NONE,	/* no CD line, use polling to detect card */
+	S3C_SDHCI_CD_PERMANENT,	/* no CD line, card permanently wired to host */
+};
+
+/**
+ * struct s3c_sdhci_platdata() - Platform device data for Samsung SDHCI
+ * @max_width: The maximum number of data bits supported.
+ * @host_caps: Standard MMC host capabilities bit field.
+ * @host_caps2: The second standard MMC host capabilities bit field.
+ * @cd_type: Type of Card Detection method (see cd_types enum above)
+ * @ext_cd_init: Initialize external card detect subsystem. Called on
+ *		 sdhci-s3c driver probe when cd_type == S3C_SDHCI_CD_EXTERNAL.
+ *		 notify_func argument is a callback to the sdhci-s3c driver
+ *		 that triggers the card detection event. Callback arguments:
+ *		 dev is pointer to platform device of the host controller,
+ *		 state is new state of the card (0 - removed, 1 - inserted).
+ * @ext_cd_cleanup: Cleanup external card detect subsystem. Called on
+ *		 sdhci-s3c driver remove when cd_type == S3C_SDHCI_CD_EXTERNAL.
+ *		 notify_func argument is the same callback as for ext_cd_init.
+ * @ext_cd_gpio: gpio pin used for external CD line, valid only if
+ *		 cd_type == S3C_SDHCI_CD_GPIO
+ * @ext_cd_gpio_invert: invert values for external CD gpio line
+ * @cfg_gpio: Configure the GPIO for a specific card bit-width
+ *
+ * Initialisation data specific to either the machine or the platform
+ * for the device driver to use or call-back when configuring gpio or
+ * card speed information.
+*/
+struct s3c_sdhci_platdata {
+	unsigned int	max_width;
+	unsigned int	host_caps;
+	unsigned int	host_caps2;
+	unsigned int	pm_caps;
+	enum cd_types	cd_type;
+
+	int		ext_cd_gpio;
+	bool		ext_cd_gpio_invert;
+	int	(*ext_cd_init)(void (*notify_func)(struct platform_device *,
+						   int state));
+	int	(*ext_cd_cleanup)(void (*notify_func)(struct platform_device *,
+						      int state));
+
+	void	(*cfg_gpio)(struct platform_device *dev, int width);
+};
+
+
+#endif /* __PLATFORM_DATA_SDHCI_S3C_H */
-- 
1.8.1.2



From arnd at arndb.de  Thu Apr 11 17:37:23 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 11 Apr 2013 23:37:23 +0200
Subject: [PATCH v3 08/10] mtd: onenand/samsung: make regs-onenand.h file local
In-Reply-To: <1365716245-99231-1-git-send-email-arnd@arndb.de>
References: <1365716245-99231-1-git-send-email-arnd@arndb.de>
Message-ID: <1365716245-99231-9-git-send-email-arnd@arndb.de>

Nothing uses the NAND register definitions other than the
actual driver, so we can move the header file into the
same local directory, which lets us build it in a multiplatform
configuration.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Acked-by: Kyungmin Park <kyungmin.park at samsung.com>
Cc: linux-mtd at lists.infradead.org
Cc: David Woodhouse <dwmw2 at infradead.org>
---
 drivers/mtd/onenand/samsung.c                                         | 4 ++--
 .../include/plat/regs-onenand.h => drivers/mtd/onenand/samsung.h      | 2 --
 2 files changed, 2 insertions(+), 4 deletions(-)
 rename arch/arm/plat-samsung/include/plat/regs-onenand.h => drivers/mtd/onenand/samsung.h (98%)

diff --git a/drivers/mtd/onenand/samsung.c b/drivers/mtd/onenand/samsung.c
index 33f2a8f..2cf7408 100644
--- a/drivers/mtd/onenand/samsung.c
+++ b/drivers/mtd/onenand/samsung.c
@@ -23,11 +23,11 @@
 #include <linux/mtd/partitions.h>
 #include <linux/dma-mapping.h>
 #include <linux/interrupt.h>
+#include <linux/io.h>
 
 #include <asm/mach/flash.h>
-#include <plat/regs-onenand.h>
 
-#include <linux/io.h>
+#include "samsung.h"
 
 enum soc_type {
 	TYPE_S3C6400,
diff --git a/arch/arm/plat-samsung/include/plat/regs-onenand.h b/drivers/mtd/onenand/samsung.h
similarity index 98%
rename from arch/arm/plat-samsung/include/plat/regs-onenand.h
rename to drivers/mtd/onenand/samsung.h
index 930ea8b..c4a80e6 100644
--- a/arch/arm/plat-samsung/include/plat/regs-onenand.h
+++ b/drivers/mtd/onenand/samsung.h
@@ -11,8 +11,6 @@
 #ifndef __SAMSUNG_ONENAND_H__
 #define __SAMSUNG_ONENAND_H__
 
-#include <mach/hardware.h>
-
 /*
  * OneNAND Controller
  */
-- 
1.8.1.2



From arnd at arndb.de  Thu Apr 11 17:37:22 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 11 Apr 2013 23:37:22 +0200
Subject: [PATCH v3 07/10] thermal/exynos: remove unnecessary header inclusions
In-Reply-To: <1365716245-99231-1-git-send-email-arnd@arndb.de>
References: <1365716245-99231-1-git-send-email-arnd@arndb.de>
Message-ID: <1365716245-99231-8-git-send-email-arnd@arndb.de>

In multiplatform configurations, we cannot include headers
provided by only the exynos platform. Fortunately a number
of drivers that include those headers do not actually need
them, so we can just remove the inclusions.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Acked-by: Eduardo Valentin <eduardo.valentin at ti.com>
Cc: Zhang Rui <rui.zhang at intel.com>
---
 drivers/thermal/exynos_thermal.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/thermal/exynos_thermal.c b/drivers/thermal/exynos_thermal.c
index 46568c0..b777ae6 100644
--- a/drivers/thermal/exynos_thermal.c
+++ b/drivers/thermal/exynos_thermal.c
@@ -39,8 +39,6 @@
 #include <linux/cpu_cooling.h>
 #include <linux/of.h>
 
-#include <plat/cpu.h>
-
 /* Exynos generic registers */
 #define EXYNOS_TMU_REG_TRIMINFO		0x0
 #define EXYNOS_TMU_REG_CONTROL		0x20
-- 
1.8.1.2



From arnd at arndb.de  Thu Apr 11 17:37:20 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 11 Apr 2013 23:37:20 +0200
Subject: [PATCH v3 05/10] i2c: s3c2410: make header file local
In-Reply-To: <1365716245-99231-1-git-send-email-arnd@arndb.de>
References: <1365716245-99231-1-git-send-email-arnd@arndb.de>
Message-ID: <1365716245-99231-6-git-send-email-arnd@arndb.de>

No other file in the kernel besides i2c-s3c2410.c uses the current
plat/regs-iic.h, so we can simply move the header file to live in the
same directory as the driver, as a preparation to multiplatform builds.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Cc: linux-i2c at vger.kernel.org
Cc: Wolfram Sang <wsa at the-dreams.de>
Cc: Ben Dooks <ben-linux at fluff.org>
---
 arch/arm/mach-s3c24xx/mach-rx1950.c                                    | 1 -
 arch/arm/plat-samsung/devs.c                                           | 1 -
 drivers/i2c/busses/i2c-s3c2410.c                                       | 3 ++-
 .../include/plat/regs-iic.h => drivers/i2c/busses/i2c-s3c2410.h        | 0
 4 files changed, 2 insertions(+), 3 deletions(-)
 rename arch/arm/plat-samsung/include/plat/regs-iic.h => drivers/i2c/busses/i2c-s3c2410.h (100%)

diff --git a/arch/arm/mach-s3c24xx/mach-rx1950.c b/arch/arm/mach-s3c24xx/mach-rx1950.c
index 1f9ba2a..43f3ac5 100644
--- a/arch/arm/mach-s3c24xx/mach-rx1950.c
+++ b/arch/arm/mach-s3c24xx/mach-rx1950.c
@@ -56,7 +56,6 @@
 #include <plat/cpu.h>
 #include <plat/devs.h>
 #include <plat/pm.h>
-#include <plat/regs-iic.h>
 #include <plat/regs-serial.h>
 
 #include "common.h"
diff --git a/arch/arm/plat-samsung/devs.c b/arch/arm/plat-samsung/devs.c
index de9ad27..5e37051 100644
--- a/arch/arm/plat-samsung/devs.c
+++ b/arch/arm/plat-samsung/devs.c
@@ -62,7 +62,6 @@
 #include <linux/platform_data/usb-s3c2410_udc.h>
 #include <linux/platform_data/usb-ohci-s3c2410.h>
 #include <plat/usb-phy.h>
-#include <plat/regs-iic.h>
 #include <plat/regs-serial.h>
 #include <plat/regs-spi.h>
 #include <linux/platform_data/spi-s3c64xx.h>
diff --git a/drivers/i2c/busses/i2c-s3c2410.c b/drivers/i2c/busses/i2c-s3c2410.c
index f6b880b..d042ad0 100644
--- a/drivers/i2c/busses/i2c-s3c2410.c
+++ b/drivers/i2c/busses/i2c-s3c2410.c
@@ -42,9 +42,10 @@
 
 #include <asm/irq.h>
 
-#include <plat/regs-iic.h>
 #include <linux/platform_data/i2c-s3c2410.h>
 
+#include "i2c-s3c2410.h"
+
 /* Treat S3C2410 as baseline hardware, anything else is supported via quirks */
 #define QUIRK_S3C2440		(1 << 0)
 #define QUIRK_HDMIPHY		(1 << 1)
diff --git a/arch/arm/plat-samsung/include/plat/regs-iic.h b/drivers/i2c/busses/i2c-s3c2410.h
similarity index 100%
rename from arch/arm/plat-samsung/include/plat/regs-iic.h
rename to drivers/i2c/busses/i2c-s3c2410.h
-- 
1.8.1.2



From arnd at arndb.de  Thu Apr 11 17:37:15 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 11 Apr 2013 23:37:15 +0200
Subject: [PATCH v3 00/10] ARM: exynos multiplatform series, part 1
Message-ID: <1365716245-99231-1-git-send-email-arnd@arndb.de>

Hi Kukjin,

These are the patches that I would like to apply directly to
the arm-soc next/multiplatform branch, unless you have any
objections. This would get all the simple stuff out of the
way, and I don't think there is a big risk of introducing
regressions with these.

A lot of the other patches have already been merged into
subsystem trees. After this series in in arm-soc, what is
left comes down to

* The ASoC conversion to dmaengine won't make it unless someone
  who knows that code better steps up to do it right away. This
  means that we won't have audio in a 3.10 multiplatform kernel
  on Exynos, but it will still work for users that don't enable
  multiplatform.

* The irqchip (combiner), clk and clksource patches are all based
  on top   of other changesets we pulled in from your trees, so I
  would not make them part of the next/multiplatform branch. We can
  apply them on top of the next/drivers branch once they are
  tested successfully.

* A trivial patch is needed in the end to actually make
  CONFIG_ARCH_EXYNOS visible in multiplatform configurations.
  We will do that as a separate patch once everything else is
  there.

Please provide an ACK so I can put this into arm-soc, or let
me know if I screwed up somewhere.

	Arnd

Arnd Bergmann (10):
  ARM: exynos: introduce EXYNOS_ATAGS symbol
  ARM: exynos: prepare for sparse IRQ
  ARM: exynos: move debug-macro.S to include/debug/
  ARM: samsung: move mfc device definition to s5p-dev-mfc.c
  i2c: s3c2410: make header file local
  mmc: sdhci-s3c: remove platform dependencies
  thermal/exynos: remove unnecessary header inclusions
  mtd: onenand/samsung: make regs-onenand.h file local
  rtc: s3c: make header file local
  ARM: exynos: enable multiplatform support

 arch/arm/Kconfig                                   |  9 +---
 arch/arm/Kconfig.debug                             |  8 ++++
 arch/arm/configs/exynos4_defconfig                 |  2 +-
 .../mach/debug-macro.S => include/debug/exynos.S}  | 12 ++---
 .../plat/debug-macro.S => include/debug/samsung.S} |  2 +-
 arch/arm/mach-exynos/Kconfig                       | 41 ++++++++++++++--
 arch/arm/mach-exynos/Makefile                      |  5 +-
 arch/arm/mach-exynos/common.c                      |  6 +++
 arch/arm/mach-exynos/dev-uart.c                    |  1 +
 arch/arm/mach-exynos/include/mach/irqs.h           |  5 +-
 arch/arm/mach-exynos/mach-armlex4210.c             |  2 +
 arch/arm/mach-exynos/mach-exynos4-dt.c             |  2 +
 arch/arm/mach-exynos/mach-exynos5-dt.c             |  2 +
 arch/arm/mach-exynos/mach-nuri.c                   |  2 +
 arch/arm/mach-exynos/mach-origen.c                 |  2 +
 arch/arm/mach-exynos/mach-smdk4x12.c               |  2 +
 arch/arm/mach-exynos/mach-smdkv310.c               |  3 ++
 arch/arm/mach-exynos/setup-sdhci-gpio.c            |  2 +-
 arch/arm/mach-s3c24xx/include/mach/debug-macro.S   |  2 +-
 arch/arm/mach-s3c24xx/mach-rx1950.c                |  1 -
 arch/arm/mach-s3c64xx/include/mach/debug-macro.S   |  2 +-
 arch/arm/mach-s5p64x0/include/mach/debug-macro.S   |  2 +-
 arch/arm/mach-s5pc100/include/mach/debug-macro.S   |  2 +-
 arch/arm/mach-s5pc100/setup-sdhci-gpio.c           |  1 -
 arch/arm/mach-s5pv210/include/mach/debug-macro.S   |  2 +-
 arch/arm/mach-s5pv210/setup-sdhci-gpio.c           |  1 -
 arch/arm/plat-samsung/Kconfig                      |  7 ++-
 arch/arm/plat-samsung/Makefile                     |  8 +++-
 arch/arm/plat-samsung/devs.c                       | 46 ------------------
 arch/arm/plat-samsung/include/plat/pm.h            |  5 ++
 arch/arm/plat-samsung/include/plat/sdhci.h         | 56 +---------------------
 arch/arm/plat-samsung/irq-vic-timer.c              |  1 +
 arch/arm/plat-samsung/pm.c                         |  1 +
 arch/arm/plat-samsung/s5p-dev-mfc.c                | 42 +++++++++++++++-
 arch/arm/plat-samsung/s5p-irq.c                    |  1 +
 drivers/gpio/Makefile                              |  2 +-
 drivers/i2c/busses/i2c-s3c2410.c                   |  3 +-
 .../regs-iic.h => drivers/i2c/busses/i2c-s3c2410.h |  0
 drivers/mmc/host/Kconfig                           |  2 +-
 .../mmc/host/sdhci-s3c-regs.h                      |  0
 drivers/mmc/host/sdhci-s3c.c                       |  5 +-
 drivers/mtd/onenand/samsung.c                      |  4 +-
 .../mtd/onenand/samsung.h                          |  2 -
 drivers/rtc/rtc-s3c.c                              |  3 +-
 .../plat/regs-rtc.h => drivers/rtc/rtc-s3c.h       |  3 +-
 drivers/thermal/exynos_thermal.c                   |  2 -
 include/linux/platform_data/mmc-sdhci-s3c.h        | 56 ++++++++++++++++++++++
 47 files changed, 217 insertions(+), 153 deletions(-)
 rename arch/arm/{mach-exynos/include/mach/debug-macro.S => include/debug/exynos.S} (84%)
 rename arch/arm/{plat-samsung/include/plat/debug-macro.S => include/debug/samsung.S} (98%)
 rename arch/arm/plat-samsung/include/plat/regs-iic.h => drivers/i2c/busses/i2c-s3c2410.h (100%)
 rename arch/arm/plat-samsung/include/plat/regs-sdhci.h => drivers/mmc/host/sdhci-s3c-regs.h (100%)
 rename arch/arm/plat-samsung/include/plat/regs-onenand.h => drivers/mtd/onenand/samsung.h (98%)
 rename arch/arm/plat-samsung/include/plat/regs-rtc.h => drivers/rtc/rtc-s3c.h (97%)
 create mode 100644 include/linux/platform_data/mmc-sdhci-s3c.h

-- 
1.8.1.2



From arnd at arndb.de  Thu Apr 11 17:37:19 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 11 Apr 2013 23:37:19 +0200
Subject: [PATCH v3 04/10] ARM: samsung: move mfc device definition to
 s5p-dev-mfc.c
In-Reply-To: <1365716245-99231-1-git-send-email-arnd@arndb.de>
References: <1365716245-99231-1-git-send-email-arnd@arndb.de>
Message-ID: <1365716245-99231-5-git-send-email-arnd@arndb.de>

For a DT-only build we don't want to compile devs.c, but we do need
the mfc device, which is also referenced by the DT based platforms,
so move it all into one place.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 arch/arm/plat-samsung/devs.c        | 45 -------------------------------------
 arch/arm/plat-samsung/s5p-dev-mfc.c | 42 +++++++++++++++++++++++++++++++++-
 2 files changed, 41 insertions(+), 46 deletions(-)

diff --git a/arch/arm/plat-samsung/devs.c b/arch/arm/plat-samsung/devs.c
index 51afedd..de9ad27 100644
--- a/arch/arm/plat-samsung/devs.c
+++ b/arch/arm/plat-samsung/devs.c
@@ -878,51 +878,6 @@ void __init s3c24xx_fb_set_platdata(struct s3c2410fb_mach_info *pd)
 }
 #endif /* CONFIG_PLAT_S3C24XX */
 
-/* MFC */
-
-#ifdef CONFIG_S5P_DEV_MFC
-static struct resource s5p_mfc_resource[] = {
-	[0] = DEFINE_RES_MEM(S5P_PA_MFC, SZ_64K),
-	[1] = DEFINE_RES_IRQ(IRQ_MFC),
-};
-
-struct platform_device s5p_device_mfc = {
-	.name		= "s5p-mfc",
-	.id		= -1,
-	.num_resources	= ARRAY_SIZE(s5p_mfc_resource),
-	.resource	= s5p_mfc_resource,
-};
-
-/*
- * MFC hardware has 2 memory interfaces which are modelled as two separate
- * platform devices to let dma-mapping distinguish between them.
- *
- * MFC parent device (s5p_device_mfc) must be registered before memory
- * interface specific devices (s5p_device_mfc_l and s5p_device_mfc_r).
- */
-
-struct platform_device s5p_device_mfc_l = {
-	.name		= "s5p-mfc-l",
-	.id		= -1,
-	.dev		= {
-		.parent			= &s5p_device_mfc.dev,
-		.dma_mask		= &samsung_device_dma_mask,
-		.coherent_dma_mask	= DMA_BIT_MASK(32),
-	},
-};
-
-struct platform_device s5p_device_mfc_r = {
-	.name		= "s5p-mfc-r",
-	.id		= -1,
-	.dev		= {
-		.parent			= &s5p_device_mfc.dev,
-		.dma_mask		= &samsung_device_dma_mask,
-		.coherent_dma_mask	= DMA_BIT_MASK(32),
-	},
-};
-
-#endif /* CONFIG_S5P_DEV_MFC */
-
 /* MIPI CSIS */
 
 #ifdef CONFIG_S5P_DEV_CSIS0
diff --git a/arch/arm/plat-samsung/s5p-dev-mfc.c b/arch/arm/plat-samsung/s5p-dev-mfc.c
index 5ec104b..a93fb6f 100644
--- a/arch/arm/plat-samsung/s5p-dev-mfc.c
+++ b/arch/arm/plat-samsung/s5p-dev-mfc.c
@@ -18,10 +18,50 @@
 #include <linux/of.h>
 
 #include <mach/map.h>
+#include <mach/irqs.h>
 #include <plat/devs.h>
-#include <plat/irqs.h>
 #include <plat/mfc.h>
 
+static struct resource s5p_mfc_resource[] = {
+	[0] = DEFINE_RES_MEM(S5P_PA_MFC, SZ_64K),
+	[1] = DEFINE_RES_IRQ(IRQ_MFC),
+};
+
+struct platform_device s5p_device_mfc = {
+	.name		= "s5p-mfc",
+	.id		= -1,
+	.num_resources	= ARRAY_SIZE(s5p_mfc_resource),
+	.resource	= s5p_mfc_resource,
+};
+
+/*
+ * MFC hardware has 2 memory interfaces which are modelled as two separate
+ * platform devices to let dma-mapping distinguish between them.
+ *
+ * MFC parent device (s5p_device_mfc) must be registered before memory
+ * interface specific devices (s5p_device_mfc_l and s5p_device_mfc_r).
+ */
+
+struct platform_device s5p_device_mfc_l = {
+	.name		= "s5p-mfc-l",
+	.id		= -1,
+	.dev		= {
+		.parent			= &s5p_device_mfc.dev,
+		.dma_mask		= &s5p_device_mfc_l.dev.coherent_dma_mask,
+		.coherent_dma_mask	= DMA_BIT_MASK(32),
+	},
+};
+
+struct platform_device s5p_device_mfc_r = {
+	.name		= "s5p-mfc-r",
+	.id		= -1,
+	.dev		= {
+		.parent			= &s5p_device_mfc.dev,
+		.dma_mask		= &s5p_device_mfc_r.dev.coherent_dma_mask,
+		.coherent_dma_mask	= DMA_BIT_MASK(32),
+	},
+};
+
 struct s5p_mfc_reserved_mem {
 	phys_addr_t	base;
 	unsigned long	size;
-- 
1.8.1.2



From arnd at arndb.de  Thu Apr 11 17:37:17 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 11 Apr 2013 23:37:17 +0200
Subject: [PATCH v3 02/10] ARM: exynos: prepare for sparse IRQ
In-Reply-To: <1365716245-99231-1-git-send-email-arnd@arndb.de>
References: <1365716245-99231-1-git-send-email-arnd@arndb.de>
Message-ID: <1365716245-99231-3-git-send-email-arnd@arndb.de>

When we enable CONFIG_SPARSE_IRQ, we have to set the value of NR_IRQS in
the machine_desc for legacy IRQ domains, and any file referring to the
number of interrupts or a specific number must include the mach/irqs.h
header file explicitly.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 arch/arm/mach-exynos/dev-uart.c          | 1 +
 arch/arm/mach-exynos/include/mach/irqs.h | 5 ++++-
 arch/arm/mach-exynos/mach-armlex4210.c   | 2 ++
 arch/arm/mach-exynos/mach-exynos4-dt.c   | 2 ++
 arch/arm/mach-exynos/mach-exynos5-dt.c   | 2 ++
 arch/arm/mach-exynos/mach-nuri.c         | 2 ++
 arch/arm/mach-exynos/mach-origen.c       | 2 ++
 arch/arm/mach-exynos/mach-smdk4x12.c     | 2 ++
 arch/arm/mach-exynos/mach-smdkv310.c     | 3 +++
 arch/arm/plat-samsung/irq-vic-timer.c    | 1 +
 arch/arm/plat-samsung/pm.c               | 1 +
 arch/arm/plat-samsung/s5p-irq.c          | 1 +
 12 files changed, 23 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-exynos/dev-uart.c b/arch/arm/mach-exynos/dev-uart.c
index 7c42f4b..c48aff0 100644
--- a/arch/arm/mach-exynos/dev-uart.c
+++ b/arch/arm/mach-exynos/dev-uart.c
@@ -20,6 +20,7 @@
 #include <asm/mach/irq.h>
 #include <mach/hardware.h>
 #include <mach/map.h>
+#include <mach/irqs.h>
 
 #include <plat/devs.h>
 
diff --git a/arch/arm/mach-exynos/include/mach/irqs.h b/arch/arm/mach-exynos/include/mach/irqs.h
index 1f4dc35..8bd5dde 100644
--- a/arch/arm/mach-exynos/include/mach/irqs.h
+++ b/arch/arm/mach-exynos/include/mach/irqs.h
@@ -466,7 +466,10 @@
 #define IRQ_TIMER_BASE			(IRQ_GPIO_END + 64)
 
 /* Set the default NR_IRQS */
+#define EXYNOS_NR_IRQS			(IRQ_TIMER_BASE + IRQ_TIMER_COUNT)
 
-#define NR_IRQS				(IRQ_TIMER_BASE + IRQ_TIMER_COUNT)
+#ifndef CONFIG_SPARSE_IRQ
+#define NR_IRQS				EXYNOS_NR_IRQS
+#endif
 
 #endif /* __ASM_ARCH_IRQS_H */
diff --git a/arch/arm/mach-exynos/mach-armlex4210.c b/arch/arm/mach-exynos/mach-armlex4210.c
index 685f291..cb95992 100644
--- a/arch/arm/mach-exynos/mach-armlex4210.c
+++ b/arch/arm/mach-exynos/mach-armlex4210.c
@@ -25,6 +25,7 @@
 #include <plat/regs-srom.h>
 #include <plat/sdhci.h>
 
+#include <mach/irqs.h>
 #include <mach/map.h>
 
 #include "common.h"
@@ -197,6 +198,7 @@ static void __init armlex4210_machine_init(void)
 MACHINE_START(ARMLEX4210, "ARMLEX4210")
 	/* Maintainer: Alim Akhtar <alim.akhtar at samsung.com> */
 	.atag_offset	= 0x100,
+	.nr_irqs	= EXYNOS_NR_IRQS,
 	.smp		= smp_ops(exynos_smp_ops),
 	.init_irq	= exynos4_init_irq,
 	.map_io		= armlex4210_map_io,
diff --git a/arch/arm/mach-exynos/mach-exynos4-dt.c b/arch/arm/mach-exynos/mach-exynos4-dt.c
index 3358088..55aa611 100644
--- a/arch/arm/mach-exynos/mach-exynos4-dt.c
+++ b/arch/arm/mach-exynos/mach-exynos4-dt.c
@@ -16,6 +16,7 @@
 
 #include <asm/mach/arch.h>
 #include <mach/map.h>
+#include <mach/irqs.h>
 
 #include <plat/cpu.h>
 #include <plat/regs-serial.h>
@@ -137,6 +138,7 @@ static char const *exynos4_dt_compat[] __initdata = {
 
 DT_MACHINE_START(EXYNOS4210_DT, "Samsung Exynos4 (Flattened Device Tree)")
 	/* Maintainer: Thomas Abraham <thomas.abraham at linaro.org> */
+	.nr_irqs	= EXYNOS_NR_IRQS,
 	.smp		= smp_ops(exynos_smp_ops),
 	.init_irq	= exynos4_init_irq,
 	.map_io		= exynos4_dt_map_io,
diff --git a/arch/arm/mach-exynos/mach-exynos5-dt.c b/arch/arm/mach-exynos/mach-exynos5-dt.c
index acaeb14..c674e7f 100644
--- a/arch/arm/mach-exynos/mach-exynos5-dt.c
+++ b/arch/arm/mach-exynos/mach-exynos5-dt.c
@@ -17,6 +17,7 @@
 
 #include <asm/mach/arch.h>
 #include <mach/map.h>
+#include <mach/irqs.h>
 #include <mach/regs-pmu.h>
 
 #include <plat/cpu.h>
@@ -211,6 +212,7 @@ static void __init exynos5_reserve(void)
 
 DT_MACHINE_START(EXYNOS5_DT, "SAMSUNG EXYNOS5 (Flattened Device Tree)")
 	/* Maintainer: Kukjin Kim <kgene.kim at samsung.com> */
+	.nr_irqs	= EXYNOS_NR_IRQS,
 	.init_irq	= exynos5_init_irq,
 	.smp		= smp_ops(exynos_smp_ops),
 	.map_io		= exynos5_dt_map_io,
diff --git a/arch/arm/mach-exynos/mach-nuri.c b/arch/arm/mach-exynos/mach-nuri.c
index 1ea7973..fee0885 100644
--- a/arch/arm/mach-exynos/mach-nuri.c
+++ b/arch/arm/mach-exynos/mach-nuri.c
@@ -53,6 +53,7 @@
 #include <plat/fimc-core.h>
 #include <plat/camport.h>
 
+#include <mach/irqs.h>
 #include <mach/map.h>
 
 #include "common.h"
@@ -1375,6 +1376,7 @@ static void __init nuri_machine_init(void)
 MACHINE_START(NURI, "NURI")
 	/* Maintainer: Kyungmin Park <kyungmin.park at samsung.com> */
 	.atag_offset	= 0x100,
+	.nr_irqs	= EXYNOS_NR_IRQS,
 	.smp		= smp_ops(exynos_smp_ops),
 	.init_irq	= exynos4_init_irq,
 	.map_io		= nuri_map_io,
diff --git a/arch/arm/mach-exynos/mach-origen.c b/arch/arm/mach-exynos/mach-origen.c
index 579d2d1..d1849d1 100644
--- a/arch/arm/mach-exynos/mach-origen.c
+++ b/arch/arm/mach-exynos/mach-origen.c
@@ -46,6 +46,7 @@
 #include <plat/hdmi.h>
 
 #include <mach/map.h>
+#include <mach/irqs.h>
 
 #include <drm/exynos_drm.h>
 #include "common.h"
@@ -810,6 +811,7 @@ static void __init origen_machine_init(void)
 MACHINE_START(ORIGEN, "ORIGEN")
 	/* Maintainer: JeongHyeon Kim <jhkim at insignal.co.kr> */
 	.atag_offset	= 0x100,
+	.nr_irqs	= EXYNOS_NR_IRQS,
 	.smp		= smp_ops(exynos_smp_ops),
 	.init_irq	= exynos4_init_irq,
 	.map_io		= origen_map_io,
diff --git a/arch/arm/mach-exynos/mach-smdk4x12.c b/arch/arm/mach-exynos/mach-smdk4x12.c
index fe61496..46c7fc7 100644
--- a/arch/arm/mach-exynos/mach-smdk4x12.c
+++ b/arch/arm/mach-exynos/mach-smdk4x12.c
@@ -39,6 +39,7 @@
 #include <plat/regs-serial.h>
 #include <plat/sdhci.h>
 
+#include <mach/irqs.h>
 #include <mach/map.h>
 
 #include <drm/exynos_drm.h>
@@ -385,6 +386,7 @@ MACHINE_START(SMDK4412, "SMDK4412")
 	/* Maintainer: Kukjin Kim <kgene.kim at samsung.com> */
 	/* Maintainer: Changhwan Youn <chaos.youn at samsung.com> */
 	.atag_offset	= 0x100,
+	.nr_irqs	= EXYNOS_NR_IRQS,
 	.smp		= smp_ops(exynos_smp_ops),
 	.init_irq	= exynos4_init_irq,
 	.map_io		= smdk4x12_map_io,
diff --git a/arch/arm/mach-exynos/mach-smdkv310.c b/arch/arm/mach-exynos/mach-smdkv310.c
index d716729..5187687 100644
--- a/arch/arm/mach-exynos/mach-smdkv310.c
+++ b/arch/arm/mach-exynos/mach-smdkv310.c
@@ -43,6 +43,7 @@
 #include <plat/clock.h>
 #include <plat/hdmi.h>
 
+#include <mach/irqs.h>
 #include <mach/map.h>
 
 #include <drm/exynos_drm.h>
@@ -419,6 +420,7 @@ MACHINE_START(SMDKV310, "SMDKV310")
 	/* Maintainer: Kukjin Kim <kgene.kim at samsung.com> */
 	/* Maintainer: Changhwan Youn <chaos.youn at samsung.com> */
 	.atag_offset	= 0x100,
+	.nr_irqs	= EXYNOS_NR_IRQS,
 	.smp		= smp_ops(exynos_smp_ops),
 	.init_irq	= exynos4_init_irq,
 	.map_io		= smdkv310_map_io,
@@ -431,6 +433,7 @@ MACHINE_END
 MACHINE_START(SMDKC210, "SMDKC210")
 	/* Maintainer: Kukjin Kim <kgene.kim at samsung.com> */
 	.atag_offset	= 0x100,
+	.nr_irqs	= EXYNOS_NR_IRQS,
 	.smp		= smp_ops(exynos_smp_ops),
 	.init_irq	= exynos4_init_irq,
 	.map_io		= smdkv310_map_io,
diff --git a/arch/arm/plat-samsung/irq-vic-timer.c b/arch/arm/plat-samsung/irq-vic-timer.c
index f980cf3..1113066 100644
--- a/arch/arm/plat-samsung/irq-vic-timer.c
+++ b/arch/arm/plat-samsung/irq-vic-timer.c
@@ -19,6 +19,7 @@
 #include <linux/io.h>
 
 #include <mach/map.h>
+#include <mach/irqs.h>
 #include <plat/cpu.h>
 #include <plat/irq-vic-timer.h>
 #include <plat/regs-timer.h>
diff --git a/arch/arm/plat-samsung/pm.c b/arch/arm/plat-samsung/pm.c
index 002b147..53210ec 100644
--- a/arch/arm/plat-samsung/pm.c
+++ b/arch/arm/plat-samsung/pm.c
@@ -27,6 +27,7 @@
 #include <plat/regs-serial.h>
 #include <mach/regs-clock.h>
 #include <mach/regs-irq.h>
+#include <mach/irqs.h>
 #include <asm/irq.h>
 
 #include <plat/pm.h>
diff --git a/arch/arm/plat-samsung/s5p-irq.c b/arch/arm/plat-samsung/s5p-irq.c
index 103e371..ff1a760 100644
--- a/arch/arm/plat-samsung/s5p-irq.c
+++ b/arch/arm/plat-samsung/s5p-irq.c
@@ -15,6 +15,7 @@
 #include <linux/io.h>
 #include <linux/irqchip/arm-vic.h>
 
+#include <mach/irqs.h>
 #include <mach/map.h>
 #include <plat/regs-timer.h>
 #include <plat/cpu.h>
-- 
1.8.1.2



From arnd at arndb.de  Thu Apr 11 17:37:25 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 11 Apr 2013 23:37:25 +0200
Subject: [PATCH v3 10/10] ARM: exynos: enable multiplatform support
In-Reply-To: <1365716245-99231-1-git-send-email-arnd@arndb.de>
References: <1365716245-99231-1-git-send-email-arnd@arndb.de>
Message-ID: <1365716245-99231-11-git-send-email-arnd@arndb.de>

This makes it possible to enable the exynos platform as part of a
multiplatform kernel, in addition to keeping the single-platform
exynos support.

The multiplatform variant has a number of limitations at the moment:

* It only supports DT-enabled machines. This is not a problem in
  the long run, as non-DT machines for exynos are going away.
  The main problem here is that the gpio code and the exynos_eint
  irqchip are not multiplatform capable but still required for
  ATAGS based boot.
* The watchdog driver is still missing a conversion.
* sparsemem and memory_holes are currently not supported in
  multiplatform.

The the multiplatform aware ARCH_EXYNOS Kconfig symbol is disabled
for now, as dependent patches are still pending in other
subsystem trees. We will enable it once everything comes together.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 arch/arm/Kconfig                        |  9 +--------
 arch/arm/configs/exynos4_defconfig      |  2 +-
 arch/arm/mach-exynos/Kconfig            | 26 ++++++++++++++++++++++----
 arch/arm/mach-exynos/Makefile           |  5 +++--
 arch/arm/mach-exynos/common.c           |  6 ++++++
 arch/arm/plat-samsung/Kconfig           |  7 ++++++-
 arch/arm/plat-samsung/Makefile          |  8 ++++++--
 arch/arm/plat-samsung/include/plat/pm.h |  5 +++++
 drivers/gpio/Makefile                   |  2 +-
 9 files changed, 51 insertions(+), 19 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 13b7394..b375a94 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -853,18 +853,11 @@ config ARCH_S5PV210
 	help
 	  Samsung S5PV210/S5PC110 series based systems
 
-config ARCH_EXYNOS
+config ARCH_EXYNOS_SINGLE
 	bool "Samsung EXYNOS"
-	select ARCH_HAS_CPUFREQ
 	select ARCH_HAS_HOLES_MEMORYMODEL
 	select ARCH_SPARSEMEM_ENABLE
-	select CLKDEV_LOOKUP
-	select CPU_V7
-	select GENERIC_CLOCKEVENTS
-	select HAVE_CLK
-	select HAVE_S3C2410_I2C if I2C
 	select HAVE_S3C2410_WATCHDOG if WATCHDOG
-	select HAVE_S3C_RTC if RTC_CLASS
 	select NEED_MACH_GPIO_H
 	select NEED_MACH_MEMORY_H
 	help
diff --git a/arch/arm/configs/exynos4_defconfig b/arch/arm/configs/exynos4_defconfig
index bffe68e..ae90a0f 100644
--- a/arch/arm/configs/exynos4_defconfig
+++ b/arch/arm/configs/exynos4_defconfig
@@ -4,7 +4,7 @@ CONFIG_KALLSYMS_ALL=y
 CONFIG_MODULES=y
 CONFIG_MODULE_UNLOAD=y
 # CONFIG_BLK_DEV_BSG is not set
-CONFIG_ARCH_EXYNOS=y
+CONFIG_ARCH_EXYNOS_SINGLE=y
 CONFIG_S3C_LOWLEVEL_UART_PORT=1
 CONFIG_MACH_SMDKC210=y
 CONFIG_MACH_ARMLEX4210=y
diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index 33e2336..e4ee875 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -7,6 +7,21 @@
 
 # Configuration options for the EXYNOS4
 
+config ARCH_EXYNOS
+	# TODO: make this visible after all drivers are converted
+	bool "Samsung EXYNOS" if ARCH_MULTI_V7 && BROKEN
+	default ARCH_EXYNOS_SINGLE
+	select ARCH_HAS_CPUFREQ
+	select CLKDEV_LOOKUP
+	select COMMON_CLK
+	select CPU_V7
+	select GENERIC_CLOCKEVENTS
+	select HAVE_CLK
+	select HAVE_S3C2410_I2C if I2C
+	select HAVE_S3C_RTC if RTC_CLASS
+	help
+	  Support for SAMSUNG's EXYNOS SoCs (EXYNOS4/5)
+
 if ARCH_EXYNOS
 
 menu "SAMSUNG EXYNOS SoCs Support"
@@ -19,6 +34,9 @@ config ARCH_EXYNOS4
 	help
 	  Samsung EXYNOS4 SoCs based systems
 
+config ARCH_EXYNOS4_SINGLE
+	def_bool ARCH_EXYNOS4 && ARCH_EXYNOS_SINGLE
+
 config ARCH_EXYNOS5
 	bool "SAMSUNG EXYNOS5"
 	select HAVE_SMP
@@ -35,7 +53,7 @@ config CPU_EXYNOS4210
 	select PM_GENERIC_DOMAINS
 	select S5P_PM if PM
 	select S5P_SLEEP if PM
-	select SAMSUNG_DMADEV
+	select SAMSUNG_DMADEV if ARCH_EXYNOS_SINGLE
 	help
 	  Enable EXYNOS4210 CPU support
 
@@ -45,7 +63,7 @@ config SOC_EXYNOS4212
 	depends on ARCH_EXYNOS4
 	select S5P_PM if PM
 	select S5P_SLEEP if PM
-	select SAMSUNG_DMADEV
+	select SAMSUNG_DMADEV if ARCH_EXYNOS_SINGLE
 	help
 	  Enable EXYNOS4212 SoC support
 
@@ -53,7 +71,7 @@ config SOC_EXYNOS4412
 	bool "SAMSUNG EXYNOS4412"
 	default y
 	depends on ARCH_EXYNOS4
-	select SAMSUNG_DMADEV
+	select SAMSUNG_DMADEV if ARCH_EXYNOS_SINGLE
 	help
 	  Enable EXYNOS4412 SoC support
 
@@ -64,7 +82,7 @@ config SOC_EXYNOS5250
 	select S5P_PM if PM
 	select S5P_SLEEP if PM
 	select S5P_DEV_MFC
-	select SAMSUNG_DMADEV
+	select SAMSUNG_DMADEV if ARCH_EXYNOS_SINGLE
 	help
 	  Enable EXYNOS5250 SoC support
 
diff --git a/arch/arm/mach-exynos/Makefile b/arch/arm/mach-exynos/Makefile
index 435757e..57e9124 100644
--- a/arch/arm/mach-exynos/Makefile
+++ b/arch/arm/mach-exynos/Makefile
@@ -4,6 +4,7 @@
 #		http://www.samsung.com/
 #
 # Licensed under GPLv2
+ccflags-$(CONFIG_ARCH_MULTIPLATFORM) += -I$(srctree)/$(src)/include -I$(srctree)/arch/arm/plat-samsung/include
 
 obj-y				:=
 obj-m				:=
@@ -48,12 +49,12 @@ obj-$(CONFIG_MACH_EXYNOS5_DT)		+= mach-exynos5-dt.o
 # device support
 
 obj-y					+= dev-uart.o
-obj-$(CONFIG_ARCH_EXYNOS4)		+= dev-audio.o
+obj-$(CONFIG_ARCH_EXYNOS4_SINGLE)	+= dev-audio.o
 obj-$(CONFIG_EXYNOS4_DEV_AHCI)		+= dev-ahci.o
 obj-$(CONFIG_EXYNOS_DEV_DMA)		+= dma.o
 obj-$(CONFIG_EXYNOS4_DEV_USB_OHCI)	+= dev-ohci.o
 
-obj-$(CONFIG_ARCH_EXYNOS)		+= setup-i2c0.o
+obj-$(CONFIG_ARCH_EXYNOS_SINGLE)	+= setup-i2c0.o
 obj-$(CONFIG_EXYNOS4_SETUP_FIMC)	+= setup-fimc.o
 obj-$(CONFIG_EXYNOS4_SETUP_FIMD0)	+= setup-fimd0.o
 obj-$(CONFIG_EXYNOS4_SETUP_I2C1)	+= setup-i2c1.o
diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
index d63d399..83bd3f0 100644
--- a/arch/arm/mach-exynos/common.c
+++ b/arch/arm/mach-exynos/common.c
@@ -368,6 +368,9 @@ static void __init exynos4_map_io(void)
 	else
 		iotable_init(exynos4_iodesc1, ARRAY_SIZE(exynos4_iodesc1));
 
+	if (!IS_ENABLED(CONFIG_EXYNOS_ATAGS))
+		return
+
 	/* initialize device information early */
 	exynos4_default_sdhci0();
 	exynos4_default_sdhci1();
@@ -570,6 +573,8 @@ static void __init exynos4_init_uarts(struct s3c2410_uartcfg *cfg, int no)
 	s3c24xx_init_uartdevs("exynos4210-uart", exynos4_uart_resources, cfg, no);
 }
 
+
+#ifdef CONFIG_EXYNOS_ATAGS
 static void __iomem *exynos_eint_base;
 
 static DEFINE_SPINLOCK(eint_lock);
@@ -875,3 +880,4 @@ static int __init exynos_init_irq_eint(void)
 	return 0;
 }
 arch_initcall(exynos_init_irq_eint);
+#endif
diff --git a/arch/arm/plat-samsung/Kconfig b/arch/arm/plat-samsung/Kconfig
index a9d5216..8aae681 100644
--- a/arch/arm/plat-samsung/Kconfig
+++ b/arch/arm/plat-samsung/Kconfig
@@ -13,6 +13,10 @@ config PLAT_SAMSUNG
 	help
 	  Base platform code for all Samsung SoC based systems
 
+config PLAT_SAMSUNG_SINGLE
+	def_bool PLAT_SAMSUNG && !ARCH_MULTIPLATFORM
+	
+
 config PLAT_S5P
 	bool
 	depends on (ARCH_S5P64X0 || ARCH_S5PC100 || ARCH_S5PV210 || ARCH_EXYNOS)
@@ -23,7 +27,7 @@ config PLAT_S5P
 	select GIC_NON_BANKED if ARCH_EXYNOS4
 	select NO_IOPORT
 	select PLAT_SAMSUNG
-	select S3C_GPIO_TRACK
+	select S3C_GPIO_TRACK if PLAT_SAMSUNG_SINGLE
 	select S5P_GPIO_DRVSTR
 	select SAMSUNG_CLKSRC
 	select SAMSUNG_GPIOLIB_4BIT
@@ -178,6 +182,7 @@ config S5P_DEV_UART
 
 config S3C_ADC
 	bool "ADC common driver support"
+	depends on PLAT_SAMSUNG_SINGLE
 	help
 	  Core support for the ADC block found in the Samsung SoC systems
 	  for drivers such as the touchscreen and hwmon to use to share
diff --git a/arch/arm/plat-samsung/Makefile b/arch/arm/plat-samsung/Makefile
index 3a7c64d..cf684b2 100644
--- a/arch/arm/plat-samsung/Makefile
+++ b/arch/arm/plat-samsung/Makefile
@@ -4,6 +4,9 @@
 #
 # Licensed under GPLv2
 
+ccflags-$(CONFIG_ARCH_MULTI_V7) += -I$(srctree)/$(src)/include
+ccflags-$(CONFIG_ARCH_EXYNOS)	+= -I$(srctree)/arch/arm/mach-exynos/include
+
 obj-y				:=
 obj-m				:=
 obj-n				:= dummy.o
@@ -34,7 +37,7 @@ obj-$(CONFIG_S3C_ADC)	+= adc.o
 
 obj-y				+= platformdata.o
 
-obj-y				+= devs.o
+obj-$(CONFIG_PLAT_SAMSUNG_SINGLE)	+= devs.o
 obj-y				+= dev-uart.o
 obj-$(CONFIG_S5P_DEV_MFC)	+= s5p-dev-mfc.o
 obj-$(CONFIG_S5P_DEV_UART)	+= s5p-dev-uart.o
@@ -51,9 +54,10 @@ obj-$(CONFIG_S3C_DMA)		+= dma.o s3c-dma-ops.o
 obj-$(CONFIG_SAMSUNG_DMADEV)	+= dma-ops.o
 
 # PM support
-
 obj-$(CONFIG_PM)		+= pm.o
+ifdef CONFIG_PLAT_SAMSUNG_SINGLE
 obj-$(CONFIG_PM)		+= pm-gpio.o
+endif
 obj-$(CONFIG_SAMSUNG_PM_CHECK)	+= pm-check.o
 
 obj-$(CONFIG_SAMSUNG_WAKEMASK)	+= wakeup-mask.o
diff --git a/arch/arm/plat-samsung/include/plat/pm.h b/arch/arm/plat-samsung/include/plat/pm.h
index f6fcade..266a4e3 100644
--- a/arch/arm/plat-samsung/include/plat/pm.h
+++ b/arch/arm/plat-samsung/include/plat/pm.h
@@ -166,6 +166,7 @@ extern void s3c_pm_check_store(void);
  */
 extern void s3c_pm_configure_extint(void);
 
+#ifdef CONFIG_PLAT_SAMSUNG_SINGLE
 /**
  * samsung_pm_restore_gpios() - restore the state of the gpios after sleep.
  *
@@ -181,6 +182,10 @@ extern void samsung_pm_restore_gpios(void);
  * Save the GPIO states for resotration on resume. See samsung_pm_restore_gpios().
  */
 extern void samsung_pm_save_gpios(void);
+#else
+#define samsung_pm_restore_gpios()	do { } while(0)
+#define samsung_pm_save_gpios()		do { } while(0)
+#endif
 
 extern void s3c_pm_save_core(void);
 extern void s3c_pm_restore_core(void);
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 22e07bc..6c16050 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -57,7 +57,7 @@ obj-$(CONFIG_GPIO_PL061)	+= gpio-pl061.o
 obj-$(CONFIG_GPIO_PXA)		+= gpio-pxa.o
 obj-$(CONFIG_GPIO_RC5T583)	+= gpio-rc5t583.o
 obj-$(CONFIG_GPIO_RDC321X)	+= gpio-rdc321x.o
-obj-$(CONFIG_PLAT_SAMSUNG)	+= gpio-samsung.o
+obj-$(CONFIG_PLAT_SAMSUNG_SINGLE)	+= gpio-samsung.o
 obj-$(CONFIG_ARCH_SA1100)	+= gpio-sa1100.o
 obj-$(CONFIG_GPIO_SCH)		+= gpio-sch.o
 obj-$(CONFIG_GPIO_SODAVILLE)	+= gpio-sodaville.o
-- 
1.8.1.2



From arnd at arndb.de  Thu Apr 11 17:37:24 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 11 Apr 2013 23:37:24 +0200
Subject: [PATCH v3 09/10] rtc: s3c: make header file local
In-Reply-To: <1365716245-99231-1-git-send-email-arnd@arndb.de>
References: <1365716245-99231-1-git-send-email-arnd@arndb.de>
Message-ID: <1365716245-99231-10-git-send-email-arnd@arndb.de>

Nothing outside of the rtc driver includes plat/regs-rtc.h,
so we can simply move the file into the same directory,
which allows us to build the file as platform-independent
code.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Cc: rtc-linux at googlegroups.com
Cc: Alessandro Zummo <a.zummo at towertech.it>
---
 drivers/rtc/rtc-s3c.c                                                  | 3 +--
 arch/arm/plat-samsung/include/plat/regs-rtc.h => drivers/rtc/rtc-s3c.h | 3 +--
 2 files changed, 2 insertions(+), 4 deletions(-)
 rename arch/arm/plat-samsung/include/plat/regs-rtc.h => drivers/rtc/rtc-s3c.h (97%)

diff --git a/drivers/rtc/rtc-s3c.c b/drivers/rtc/rtc-s3c.c
index fb994e9..7995f79 100644
--- a/drivers/rtc/rtc-s3c.c
+++ b/drivers/rtc/rtc-s3c.c
@@ -29,9 +29,8 @@
 #include <linux/uaccess.h>
 #include <linux/io.h>
 
-#include <mach/hardware.h>
 #include <asm/irq.h>
-#include <plat/regs-rtc.h>
+#include "rtc-s3c.h"
 
 enum s3c_cpu_type {
 	TYPE_S3C2410,
diff --git a/arch/arm/plat-samsung/include/plat/regs-rtc.h b/drivers/rtc/rtc-s3c.h
similarity index 97%
rename from arch/arm/plat-samsung/include/plat/regs-rtc.h
rename to drivers/rtc/rtc-s3c.h
index 0f8263e..004b61a 100644
--- a/arch/arm/plat-samsung/include/plat/regs-rtc.h
+++ b/drivers/rtc/rtc-s3c.h
@@ -1,5 +1,4 @@
-/* arch/arm/mach-s3c2410/include/mach/regs-rtc.h
- *
+/*
  * Copyright (c) 2003 Simtec Electronics <linux at simtec.co.uk>
  *		      http://www.simtec.co.uk/products/SWLINUX/
  *
-- 
1.8.1.2



From heiko at sntech.de  Thu Apr 11 17:43:34 2013
From: heiko at sntech.de (Heiko =?iso-8859-15?q?St=FCbner?=)
Date: Thu, 11 Apr 2013 23:43:34 +0200
Subject: [PATCH v3 05/10] i2c: s3c2410: make header file local
In-Reply-To: <1365716245-99231-6-git-send-email-arnd@arndb.de>
References: <1365716245-99231-1-git-send-email-arnd@arndb.de>
 <1365716245-99231-6-git-send-email-arnd@arndb.de>
Message-ID: <201304112343.34534.heiko@sntech.de>

Hi Arnd,

Am Donnerstag, 11. April 2013, 23:37:20 schrieb Arnd Bergmann:
> No other file in the kernel besides i2c-s3c2410.c uses the current
> plat/regs-iic.h, so we can simply move the header file to live in the
> same directory as the driver, as a preparation to multiplatform builds.

There is already a patch doing similar changes [0] in the i2c tree for 3.10


Heiko


[0] 
https://git.kernel.org/cgit/linux/kernel/git/wsa/linux.git/commit/?h=i2c/for-
next&id=e636602ac2613da8c1777cb42443223994be4107

> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Cc: linux-i2c at vger.kernel.org
> Cc: Wolfram Sang <wsa at the-dreams.de>
> Cc: Ben Dooks <ben-linux at fluff.org>
> ---
>  arch/arm/mach-s3c24xx/mach-rx1950.c                                    | 1
> - arch/arm/plat-samsung/devs.c                                           |
> 1 - drivers/i2c/busses/i2c-s3c2410.c                                      
> | 3 ++- .../include/plat/regs-iic.h => drivers/i2c/busses/i2c-s3c2410.h   
>     | 0 4 files changed, 2 insertions(+), 3 deletions(-)
>  rename arch/arm/plat-samsung/include/plat/regs-iic.h =>
> drivers/i2c/busses/i2c-s3c2410.h (100%)
> 
> diff --git a/arch/arm/mach-s3c24xx/mach-rx1950.c
> b/arch/arm/mach-s3c24xx/mach-rx1950.c index 1f9ba2a..43f3ac5 100644
> --- a/arch/arm/mach-s3c24xx/mach-rx1950.c
> +++ b/arch/arm/mach-s3c24xx/mach-rx1950.c
> @@ -56,7 +56,6 @@
>  #include <plat/cpu.h>
>  #include <plat/devs.h>
>  #include <plat/pm.h>
> -#include <plat/regs-iic.h>
>  #include <plat/regs-serial.h>
> 
>  #include "common.h"
> diff --git a/arch/arm/plat-samsung/devs.c b/arch/arm/plat-samsung/devs.c
> index de9ad27..5e37051 100644
> --- a/arch/arm/plat-samsung/devs.c
> +++ b/arch/arm/plat-samsung/devs.c
> @@ -62,7 +62,6 @@
>  #include <linux/platform_data/usb-s3c2410_udc.h>
>  #include <linux/platform_data/usb-ohci-s3c2410.h>
>  #include <plat/usb-phy.h>
> -#include <plat/regs-iic.h>
>  #include <plat/regs-serial.h>
>  #include <plat/regs-spi.h>
>  #include <linux/platform_data/spi-s3c64xx.h>
> diff --git a/drivers/i2c/busses/i2c-s3c2410.c
> b/drivers/i2c/busses/i2c-s3c2410.c index f6b880b..d042ad0 100644
> --- a/drivers/i2c/busses/i2c-s3c2410.c
> +++ b/drivers/i2c/busses/i2c-s3c2410.c
> @@ -42,9 +42,10 @@
> 
>  #include <asm/irq.h>
> 
> -#include <plat/regs-iic.h>
>  #include <linux/platform_data/i2c-s3c2410.h>
> 
> +#include "i2c-s3c2410.h"
> +
>  /* Treat S3C2410 as baseline hardware, anything else is supported via
> quirks */ #define QUIRK_S3C2440		(1 << 0)
>  #define QUIRK_HDMIPHY		(1 << 1)
> diff --git a/arch/arm/plat-samsung/include/plat/regs-iic.h
> b/drivers/i2c/busses/i2c-s3c2410.h similarity index 100%
> rename from arch/arm/plat-samsung/include/plat/regs-iic.h
> rename to drivers/i2c/busses/i2c-s3c2410.h



From sboyd at codeaurora.org  Thu Apr 11 17:48:03 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Thu, 11 Apr 2013 14:48:03 -0700
Subject: [PATCH 1/4] Documentation: Add memory mapped ARM architected
 timer binding
In-Reply-To: <20130411112407.GD8259@e106331-lin.cambridge.arm.com>
References: <1365474623-29181-1-git-send-email-sboyd@codeaurora.org>
 <1365474623-29181-2-git-send-email-sboyd@codeaurora.org>
 <20130409090843.GS23725@e106331-lin.cambridge.arm.com>
 <516444FE.2080200@codeaurora.org>
 <20130410101336.GB8799@e106331-lin.cambridge.arm.com>
 <51662584.6070906@codeaurora.org>
 <20130411112407.GD8259@e106331-lin.cambridge.arm.com>
Message-ID: <51672F93.7080109@codeaurora.org>

On 04/11/13 04:24, Mark Rutland wrote:
> Could we say the reg for the second view is optional?
>

Yes, that's already covered in the binding.

> Might we have a hardware / firmware configuration where the kernel can only access
> the secondary view?
>

I don't see how this is possible. The CNTACRn register controls secure
vs. non-secure access for particular registers in a frame regardless of
which view is used. The CNTPL0ACRn is not a security restricted register
and it can only restrict access to certain registers in the second view.
No combination of settings in these registers can restrict access to
only the second view in a frame with two views.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation



From troy.kisky at boundarydevices.com  Thu Apr 11 17:52:39 2013
From: troy.kisky at boundarydevices.com (Troy Kisky)
Date: Thu, 11 Apr 2013 14:52:39 -0700
Subject: [PATCH] cpufreq: dbx500: Round to closest available freq
In-Reply-To: <1512269.3ZuqNVLx3s@vostro.rjw.lan>
References: <1365599175-22361-1-git-send-email-ulf.hansson@stericsson.com>
 <CACRpkdb75wPjXEYdkqE6BOCsuFA_ZBc6GAz1m-5vHWSrSGKyUA@mail.gmail.com>
 <1512269.3ZuqNVLx3s@vostro.rjw.lan>
Message-ID: <516730A7.60206@boundarydevices.com>

On 4/11/2013 2:33 PM, Rafael J. Wysocki wrote:
> On Thursday, April 11, 2013 10:33:07 PM Linus Walleij wrote:
>> On Wed, Apr 10, 2013 at 3:06 PM, Ulf Hansson <ulf.hansson at stericsson.com> wrote:
>>
>>> From: Mats Fagerstrom <mats.fagerstrom at stericsson.com>
>>>
>>> When reading the cpu speed, round it to the closest available
>>> frequency from the table.
>>>
>>> Signed-off-by: Ulf Hansson <ulf.hansson at linaro.org>
>>> Signed-off-by: Mats Fagerstrom <mats.fagerstrom at stericsson.com>
>> (...)
>>> +       /* The value is rounded to closest frequency in the defined table. */
>>> +       while (freq_table[i + 1].frequency != CPUFREQ_TABLE_END) {
>>> +               if (freq < freq_table[i].frequency +
>>> +                  (freq_table[i + 1].frequency - freq_table[i].frequency) / 2)

if (freq < (freq_table[i].frequency + freq_table[i + 1].frequency) / 2)

is easier to read.



>>>                          return freq_table[i].frequency;
>> Oh that works, clever.
>>
>> Acked-by: Linus Walleij <linus.walleij at linaro.org>
> Thanks, applied.
>
> Rafael
>
>



From festevam at gmail.com  Thu Apr 11 18:03:56 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Thu, 11 Apr 2013 19:03:56 -0300
Subject: [PATCH] ARM: imx: Select IRAM_ALLOC
Message-ID: <1365717837-20488-1-git-send-email-festevam@gmail.com>

From: Fabio Estevam <fabio.estevam at freescale.com>

Since commit 391630c5bf11 (media: coda: use genalloc API) the following build
error happens with imx_v4_v5_defconfig:

drivers/built-in.o: In function 'coda_remove':
clk-composite.c:(.text+0x112180): undefined reference to 'gen_pool_free'
drivers/built-in.o: In function 'coda_probe':
clk-composite.c:(.text+0x112310): undefined reference to 'of_get_named_gen_pool'
clk-composite.c:(.text+0x1123f4): undefined reference to 'gen_pool_alloc'
clk-composite.c:(.text+0x11240c): undefined reference to 'gen_pool_virt_to_phys'
clk-composite.c:(.text+0x112458): undefined reference to 'dev_get_gen_pool'

Select IRAM_ALLOC on all SoCs that are possible users of the coda driver.

Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
---
 arch/arm/mach-imx/Kconfig |    3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index 78f795d..a025cf8 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -124,6 +124,7 @@ config SOC_IMX27
 	select COMMON_CLK
 	select CPU_ARM926T
 	select IMX_HAVE_IOMUX_V1
+	select IRAM_ALLOC
 	select MACH_MX27
 	select MXC_AVIC
 
@@ -152,6 +153,7 @@ config SOC_IMX5
 	select ARCH_MXC_IOMUX_V3
 	select COMMON_CLK
 	select CPU_V7
+	select IRAM_ALLOC
 	select MXC_TZIC
 
 config	SOC_IMX51
@@ -808,6 +810,7 @@ config SOC_IMX6Q
 	select HAVE_IMX_MMDC
 	select HAVE_IMX_SRC
 	select HAVE_SMP
+	select IRAM_ALLOC
 	select MFD_SYSCON
 	select PINCTRL
 	select PINCTRL_IMX6Q
-- 
1.7.9.5



From festevam at gmail.com  Thu Apr 11 18:08:35 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Thu, 11 Apr 2013 19:08:35 -0300
Subject: [PATCH] ARM: imx: Select IRAM_ALLOC
In-Reply-To: <1365717837-20488-1-git-send-email-festevam@gmail.com>
References: <1365717837-20488-1-git-send-email-festevam@gmail.com>
Message-ID: <CAOMZO5DR8VY1DkcMBH1oJucYpjhV44QT55LGEO9=KEC=_S5CvA@mail.gmail.com>

On Thu, Apr 11, 2013 at 7:03 PM, Fabio Estevam <festevam at gmail.com> wrote:
> From: Fabio Estevam <fabio.estevam at freescale.com>
>
> Since commit 391630c5bf11 (media: coda: use genalloc API) the following build
> error happens with imx_v4_v5_defconfig:
>
> drivers/built-in.o: In function 'coda_remove':
> clk-composite.c:(.text+0x112180): undefined reference to 'gen_pool_free'
> drivers/built-in.o: In function 'coda_probe':
> clk-composite.c:(.text+0x112310): undefined reference to 'of_get_named_gen_pool'
> clk-composite.c:(.text+0x1123f4): undefined reference to 'gen_pool_alloc'
> clk-composite.c:(.text+0x11240c): undefined reference to 'gen_pool_virt_to_phys'
> clk-composite.c:(.text+0x112458): undefined reference to 'dev_get_gen_pool'
>
> Select IRAM_ALLOC on all SoCs that are possible users of the coda driver.
>
> Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
> ---
>  arch/arm/mach-imx/Kconfig |    3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
> index 78f795d..a025cf8 100644
> --- a/arch/arm/mach-imx/Kconfig
> +++ b/arch/arm/mach-imx/Kconfig
> @@ -124,6 +124,7 @@ config SOC_IMX27
>         select COMMON_CLK
>         select CPU_ARM926T
>         select IMX_HAVE_IOMUX_V1
> +       select IRAM_ALLOC

Actually I think we can remove IRAM_ALLOC completely now in favor of
GENERIC_ALLOCATOR.

Will send a new version of the patch.


From linus.walleij at linaro.org  Thu Apr 11 18:16:55 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Fri, 12 Apr 2013 00:16:55 +0200
Subject: [PATCH 3/5] gpio/omap: Add DT support to GPIO driver
In-Reply-To: <51671D7B.5060303@wwwdotorg.org>
References: <1329321854-24490-1-git-send-email-b-cousson@ti.com>
 <4F452484.5080503@gmail.com>
 <74CDBE0F657A3D45AFBB94109FB122FF17BD8BC6C1@HQMAIL01.nvidia.com>
 <4F47AD08.4030504@ti.com>
 <CAAwP0s0cB368R2mtbJpTZJreR-5GSRLfxC+8DJLo5nw3_OwBuA@mail.gmail.com>
 <512D39DA.7020306@ti.com> <512D3AB1.1080202@wwwdotorg.org>
 <512D3EC2.6050408@ti.com> <20130302200524.D230F3E1571@localhost>
 <51391F41.5000303@ti.com>
 <CAAwP0s1CFRO-rf==p5sYs1n0gigMif7wuT8Yv0N_iLUDMrtcOg@mail.gmail.com>
 <CACRpkdYHj-rEF3Rk_CWnmmMw_Amr7m8SgQ=-2zsDYuLeuu3azw@mail.gmail.com>
 <514C79E1.4090106@wwwdotorg.org> <514CE0AB.6060207@ti.com>
 <CACRpkdZmv-rAoKSQYpkHHSMzKJOn5TixVW_P3=m7ZNagBYCUPw@mail.gmail.com>
 <515319D5.20105@wwwdotorg.org>
 <CACRpkdYXVLgCz1Tyu-Ls2V2OTc4R3cGNJhfQJB6Hiz_K9dkZYQ@mail.gmail.com>
 <5155C902.7080207@wwwdotorg.org>
 <CACRpkdYbs4-uudpRUY8e+7icYYkZrfM0kReP3pLL5DMiURJ4dg@mail.gmail.com>
 <5165CB9D.1090202@wwwdotorg.org>
 <CACRpkdYirFNqmGhA4K9CL4ve4NYhs8Rd3SFt1iwW9vHBkrcz8g@mail.gmail.com>
 <51671D7B.5060303@wwwdotorg.org>
Message-ID: <CACRpkdbf32Ef77GmXk9id9+RRjcDRTr7S+F4nznoeZU8y=BT_Q@mail.gmail.com>

On Thu, Apr 11, 2013 at 10:30 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
> On 04/10/2013 03:28 PM, Linus Walleij wrote:

>> So the only reason I'm rambing on about this is that it breaks the
>
> I'm not sure I understand this paragraph; what is "it" in the line above.
>
> If "it" is this patch, then should "breaks" be re-establishes?

No I'm replying to Javier Martinez Canillas mail in this thread:
http://marc.info/?l=linux-arm-kernel&m=136334655902407&w=2
which is stating a question to grand, and contains the below
hunk:

> +static int gpio_irq_request(struct irq_data *d)
> +{
> +       struct gpio_bank *bank = irq_data_get_irq_chip_data(d);
> +
> +       return gpio_request(irq_to_gpio(bank, d->irq), "gpio-irq");
> +}

irq_to_gpio(). Notice that. not my_funny_driver_irq_to_gpio().

It's the same thing you mention below:

> If I recall the patch I'm replying to correctly, the idea was to add an
> "IRQ request" operation that would (internally to the GPIO/IRQ driver
> itself) map IRQ->GPIO, and call gpio_request(). That would then prevent
> exactly the situation you mention above.

So the above does not look like it's internal to the driver does it?

I think this is irq_to_gpio sneaking back in, and requiring that every
driver of this sort follow the same design pattern. And then maybe
you see my persistance ... are we talking about different things?

So I'd be happy with something local to the driver, foo_irq_to_gpio()
and that we also back out a bit and see what the subsystem can do
to avoid this kind of code having to be duplicated everywhere, that's
all.

Yours,
Linus Walleij


From festevam at gmail.com  Thu Apr 11 18:20:03 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Thu, 11 Apr 2013 19:20:03 -0300
Subject: [PATCH v2] ARM: imx: Select GENERIC_ALLOCATOR
Message-ID: <1365718803-28274-1-git-send-email-festevam@gmail.com>

From: Fabio Estevam <fabio.estevam at freescale.com>

Since commit 391630c5bf11 (media: coda: use genalloc API) the following build
error happens with imx_v4_v5_defconfig:

drivers/built-in.o: In function 'coda_remove':
clk-composite.c:(.text+0x112180): undefined reference to 'gen_pool_free'
drivers/built-in.o: In function 'coda_probe':
clk-composite.c:(.text+0x112310): undefined reference to 'of_get_named_gen_pool'
clk-composite.c:(.text+0x1123f4): undefined reference to 'gen_pool_alloc'
clk-composite.c:(.text+0x11240c): undefined reference to 'gen_pool_virt_to_phys'
clk-composite.c:(.text+0x112458): undefined reference to 'dev_get_gen_pool'

Select GENERIC_ALLOCATOR and get rid of the custom IRAM_ALLOC.

Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
---
 arch/arm/mach-imx/Kconfig              |    5 +--
 arch/arm/mach-imx/Makefile             |    1 -
 arch/arm/mach-imx/iram_alloc.c         |   73 --------------------------------
 include/linux/platform_data/imx-iram.h |   41 ------------------
 4 files changed, 1 insertion(+), 119 deletions(-)
 delete mode 100644 arch/arm/mach-imx/iram_alloc.c
 delete mode 100644 include/linux/platform_data/imx-iram.h

diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index 78f795d..ba44328 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -5,6 +5,7 @@ config ARCH_MXC
 	select AUTO_ZRELADDR if !ZBOOT_ROM
 	select CLKDEV_LOOKUP
 	select CLKSRC_MMIO
+	select GENERIC_ALLOCATOR
 	select GENERIC_CLOCKEVENTS
 	select GENERIC_IRQ_CHIP
 	select MULTI_IRQ_HANDLER
@@ -61,10 +62,6 @@ config MXC_ULPI
 config ARCH_HAS_RNGA
 	bool
 
-config IRAM_ALLOC
-	bool
-	select GENERIC_ALLOCATOR
-
 config HAVE_IMX_ANATOP
 	bool
 
diff --git a/arch/arm/mach-imx/Makefile b/arch/arm/mach-imx/Makefile
index b16eb39..dfde0fb 100644
--- a/arch/arm/mach-imx/Makefile
+++ b/arch/arm/mach-imx/Makefile
@@ -23,7 +23,6 @@ obj-$(CONFIG_ARCH_MXC_IOMUX_V3) += iomux-v3.o
 obj-$(CONFIG_MXC_TZIC) += tzic.o
 obj-$(CONFIG_MXC_AVIC) += avic.o
 
-obj-$(CONFIG_IRAM_ALLOC) += iram_alloc.o
 obj-$(CONFIG_MXC_ULPI) += ulpi.o
 obj-$(CONFIG_MXC_USE_EPIT) += epit.o
 obj-$(CONFIG_MXC_DEBUG_BOARD) += 3ds_debugboard.o
diff --git a/arch/arm/mach-imx/iram_alloc.c b/arch/arm/mach-imx/iram_alloc.c
deleted file mode 100644
index e05cf40..0000000
--- a/arch/arm/mach-imx/iram_alloc.c
+++ /dev/null
@@ -1,73 +0,0 @@
-/*
- * Copyright (C) 2010 Freescale Semiconductor, Inc. All Rights Reserved.
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * as published by the Free Software Foundation; either version 2
- * of the License, or (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
- * MA 02110-1301, USA.
- */
-
-#include <linux/kernel.h>
-#include <linux/io.h>
-#include <linux/module.h>
-#include <linux/spinlock.h>
-#include <linux/genalloc.h>
-#include "linux/platform_data/imx-iram.h"
-
-static unsigned long iram_phys_base;
-static void __iomem *iram_virt_base;
-static struct gen_pool *iram_pool;
-
-static inline void __iomem *iram_phys_to_virt(unsigned long p)
-{
-	return iram_virt_base + (p - iram_phys_base);
-}
-
-void __iomem *iram_alloc(unsigned int size, unsigned long *dma_addr)
-{
-	if (!iram_pool)
-		return NULL;
-
-	*dma_addr = gen_pool_alloc(iram_pool, size);
-	pr_debug("iram alloc - %dB at 0x%lX\n", size, *dma_addr);
-	if (!*dma_addr)
-		return NULL;
-	return iram_phys_to_virt(*dma_addr);
-}
-EXPORT_SYMBOL(iram_alloc);
-
-void iram_free(unsigned long addr, unsigned int size)
-{
-	if (!iram_pool)
-		return;
-
-	gen_pool_free(iram_pool, addr, size);
-}
-EXPORT_SYMBOL(iram_free);
-
-int __init iram_init(unsigned long base, unsigned long size)
-{
-	iram_phys_base = base;
-
-	iram_pool = gen_pool_create(PAGE_SHIFT, -1);
-	if (!iram_pool)
-		return -ENOMEM;
-
-	gen_pool_add(iram_pool, base, size, -1);
-	iram_virt_base = ioremap(iram_phys_base, size);
-	if (!iram_virt_base)
-		return -EIO;
-
-	pr_debug("i.MX IRAM pool: %ld KB at 0x%p\n", size / 1024, iram_virt_base);
-	return 0;
-}
diff --git a/include/linux/platform_data/imx-iram.h b/include/linux/platform_data/imx-iram.h
deleted file mode 100644
index 022690c..0000000
--- a/include/linux/platform_data/imx-iram.h
+++ /dev/null
@@ -1,41 +0,0 @@
-/*
- * Copyright (C) 2010 Freescale Semiconductor, Inc. All Rights Reserved.
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * as published by the Free Software Foundation; either version 2
- * of the License, or (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
- * MA 02110-1301, USA.
- */
-#include <linux/errno.h>
-
-#ifdef CONFIG_IRAM_ALLOC
-
-int __init iram_init(unsigned long base, unsigned long size);
-void __iomem *iram_alloc(unsigned int size, unsigned long *dma_addr);
-void iram_free(unsigned long dma_addr, unsigned int size);
-
-#else
-
-static inline int __init iram_init(unsigned long base, unsigned long size)
-{
-	return -ENOMEM;
-}
-
-static inline void __iomem *iram_alloc(unsigned int size, unsigned long *dma_addr)
-{
-	return NULL;
-}
-
-static inline void iram_free(unsigned long base, unsigned long size) {}
-
-#endif
-- 
1.7.9.5



From laurent.pinchart at ideasonboard.com  Thu Apr 11 18:35:38 2013
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Fri, 12 Apr 2013 00:35:38 +0200
Subject: [PATCH v8 1/7] media: V4L2: add temporary clock helpers
In-Reply-To: <20130411185258.7915.67263@quantum>
References: <CAGsJ_4zCRBvEX9xEDCr27JLK6wYp_2T_wk2hzVjqpKinbL=9pg@mail.gmail.com>
 <CAGsJ_4yXE7SYLgPucW9kAEYgKg+z93j8yN3d+gvhqeLAn-sSOw@mail.gmail.com>
 <20130411185258.7915.67263@quantum>
Message-ID: <13951098.tvATHWRRmI@avalon>

Hi Mike,

On Thursday 11 April 2013 11:52:58 Mike Turquette wrote:
> Quoting Barry Song (2013-04-11 01:59:28)
> > 2013/4/11 Guennadi Liakhovetski <g.liakhovetski at gmx.de>:
> > > On Thu, 11 Apr 2013, Barry Song wrote:
> > >> 2013/4/11 Guennadi Liakhovetski <g.liakhovetski at gmx.de>:
> > >> > On Thu, 11 Apr 2013, Barry Song wrote:
> > >> >> Hi Guennadi,
> > >> >> 
> > >> >> > Typical video devices like camera sensors require an external
> > >> >> > clock source. Many such devices cannot even access their hardware
> > >> >> > registers without a running clock. These clock sources should be
> > >> >> > controlled by their consumers. This should be performed, using the
> > >> >> > generic clock framework. Unfortunately so far only very few
> > >> >> > systems have been ported to that framework. This patch adds a set
> > >> >> > of temporary helpers, mimicking the generic clock API, to V4L2.
> > >> >> > Platforms, adopting the clock API, should switch to using it.
> > >> >> > Eventually this temporary API should be removed.
> > >> >> > 
> > >> >> > Signed-off-by: Guennadi Liakhovetski <g.liakhovetski at xxxxxx>
> > >> >> > ---
> > >> >> 
> > >> >> for your patch 1/8 and 3/8, i think it makes a lot of senses to let
> > >> >> the object manages its own clock by itself.
> > >> >> is it possible for us to implement v4l2-clk.c directly as an
> > >> >> instance of standard clk driver for those systems which don't have
> > >> >> generic clock,  and remove the V4L2 clock APIs like v4l2_clk_get,
> > >> >> v4l2_clk_enable from the first day? i mean v4l2-clk.c becomes a temp
> > >> >> and fake clock controller driver. finally, after people have
> > >> >> generically clk, remove it.
> > >> > 
> > >> > I don't think you can force-enable the CFF on systems, that don't
> > >> > support it, e.g. PXA.
> > >> 
> > >> yes. we can. clock is only a framework, has it any limitation to
> > >> implement a driver instance on any platform?
> > > 
> > > So, you enable CFF, it provides its own clk_* implementation like
> > > clk_get_rate() etc. Now, PXA already has it defined in
> > > arch/arm/mach-pxa/clock.c. Don't think this is going to fly.
> > 
> > agree.
> 
> I came into this thread late and don't have the actual patches in my inbox
> for review.  That said, I don't understand why V4L2 cares about the clk
> framework *implementation*?  The clk.h api is the same for platforms using
> the common struct clk and those still using the legacy method of defining
> their own struct clk.  If drivers are only consumers of the clk.h api then
> the implementation underneath should not matter.

The issue on non-CCF systems is that devices usually can't register clocks 
dynamically. (Most of) those systems provide system clocks only through their 
clock API, without a way for the camera IP core to hook up the clock(s) it can 
provide to the camera sensor. On the consumer side we don't care much about 
the clock framework implementation, but on the provider side we need a 
framework that allows registering non-system clocks at runtime.

-- 
Regards,

Laurent Pinchart



From nm at ti.com  Thu Apr 11 18:40:57 2013
From: nm at ti.com (Nishanth Menon)
Date: Thu, 11 Apr 2013 17:40:57 -0500
Subject: [RFC][PATCH 1/2] ARM: OMAP4: clock: Add device tree support for
 AUXCLKs
In-Reply-To: <20130411184648.7915.17500@quantum>
References: <515D2D30.3000306@ti.com> <515EA9E3.1010409@ti.com>
 <20130405155851.GA10155@atomide.com> <5163E589.1040809@ti.com>
 <20130409164928.GL10155@atomide.com>
 <20130409174319.GP10155@atomide.com> <20130409204900.GA8815@kahuna>
 <20130410080630.14359.68178@quantum> <5165453E.6090503@ti.com>
 <20130410173921.GA31017@kahuna> <20130411184648.7915.17500@quantum>
Message-ID: <CAGo_u6qTuPsGWz0LYxoTVKeMY2TAvfbH_WR9NDS9XoTvSUOxfw@mail.gmail.com>

On Thu, Apr 11, 2013 at 1:46 PM, Mike Turquette <mturquette at linaro.org> wrote:
> Quoting Nishanth Menon (2013-04-10 10:39:21)
>> diff --git a/drivers/clk/omap/clk.c b/drivers/clk/omap/clk.c
>> new file mode 100644
>> index 0000000..63a4cce
>> --- /dev/null
>> +++ b/drivers/clk/omap/clk.c
>> @@ -0,0 +1,94 @@
>> +/*
>> + * Texas Instruments OMAP Clock driver
>> + *
>> + * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
>> + *     Nishanth Menon
>> + *     Tony Lindgren <tony at atomide.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.
>> + *
>> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
>> + * kind, whether express or implied; without even the implied warranty
>> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + */
>> +
>> +#include <linux/clkdev.h>
>> +#include <linux/clk-private.h>
>
> Please use clk-provider.h.  Otherwise this looks like an OK transitional
k. thanks for checking up on this. will update.
> solution.  Hopefully this will be replaced with a more legitimate clock
> driver for 3.11.
I hope so too. At least we should start debate with the direction we'd
like to take and start migrating towards that purpose.

Regards,
Nishanth Menon


From nm at ti.com  Thu Apr 11 18:45:08 2013
From: nm at ti.com (Nishanth Menon)
Date: Thu, 11 Apr 2013 17:45:08 -0500
Subject: [RFC][PATCH 1/2] ARM: OMAP4: clock: Add device tree support for
 AUXCLKs
In-Reply-To: <51666AE8.9060602@ti.com>
References: <515D2D30.3000306@ti.com> <20130404164137.GH10155@atomide.com>
 <515EA9E3.1010409@ti.com> <20130405155851.GA10155@atomide.com>
 <5163E589.1040809@ti.com> <20130409164928.GL10155@atomide.com>
 <20130409174319.GP10155@atomide.com> <20130409204900.GA8815@kahuna>
 <20130410080630.14359.68178@quantum> <5165453E.6090503@ti.com>
 <20130410173921.GA31017@kahuna> <51666AE8.9060602@ti.com>
Message-ID: <CAGo_u6ooB3W6kN6mP7qnrRDPLo-+oasTrg6F=BRdiW2bVVGcZw@mail.gmail.com>

On Thu, Apr 11, 2013 at 2:48 AM, Roger Quadros <rogerq at ti.com> wrote:
> On 04/10/2013 08:39 PM, Nishanth Menon wrote:
>> On 13:55-20130410, Roger Quadros wrote:
>>> On 04/10/2013 11:06 AM, Mike Turquette wrote:
>>>> Quoting Nishanth Menon (2013-04-09 13:49:00)
>> Folks, this does seem to be the best compromise we can achieve at this
>> point in time. feedback on this approach is much appreciated - if folks
>> are ok, I can post this as an formal patch series.
>
> This looks fine to me. Minor comments below.
Thanks on the review. will fix in my next post
Regards,
Nishanth Menon


From martinez.javier at gmail.com  Thu Apr 11 18:49:48 2013
From: martinez.javier at gmail.com (Javier Martinez Canillas)
Date: Fri, 12 Apr 2013 00:49:48 +0200
Subject: [PATCH 3/5] gpio/omap: Add DT support to GPIO driver
In-Reply-To: <CACRpkdbf32Ef77GmXk9id9+RRjcDRTr7S+F4nznoeZU8y=BT_Q@mail.gmail.com>
References: <1329321854-24490-1-git-send-email-b-cousson@ti.com>
 <4F452484.5080503@gmail.com>
 <74CDBE0F657A3D45AFBB94109FB122FF17BD8BC6C1@HQMAIL01.nvidia.com>
 <4F47AD08.4030504@ti.com>
 <CAAwP0s0cB368R2mtbJpTZJreR-5GSRLfxC+8DJLo5nw3_OwBuA@mail.gmail.com>
 <512D39DA.7020306@ti.com> <512D3AB1.1080202@wwwdotorg.org>
 <512D3EC2.6050408@ti.com> <20130302200524.D230F3E1571@localhost>
 <51391F41.5000303@ti.com>
 <CAAwP0s1CFRO-rf==p5sYs1n0gigMif7wuT8Yv0N_iLUDMrtcOg@mail.gmail.com>
 <CACRpkdYHj-rEF3Rk_CWnmmMw_Amr7m8SgQ=-2zsDYuLeuu3azw@mail.gmail.com>
 <514C79E1.4090106@wwwdotorg.org> <514CE0AB.6060207@ti.com>
 <CACRpkdZmv-rAoKSQYpkHHSMzKJOn5TixVW_P3=m7ZNagBYCUPw@mail.gmail.com>
 <515319D5.20105@wwwdotorg.org>
 <CACRpkdYXVLgCz1Tyu-Ls2V2OTc4R3cGNJhfQJB6Hiz_K9dkZYQ@mail.gmail.com>
 <5155C902.7080207@wwwdotorg.org>
 <CACRpkdYbs4-uudpRUY8e+7icYYkZrfM0kReP3pLL5DMiURJ4dg@mail.gmail.com>
 <5165CB9D.1090202@wwwdotorg.org>
 <CACRpkdYirFNqmGhA4K9CL4ve4NYhs8Rd3SFt1iwW9vHBkrcz8g@mail.gmail.com>
 <51671D7B.5060303@wwwdotorg.org>
 <CACRpkdbf32Ef77GmXk9id9+RRjcDRTr7S+F4nznoeZU8y=BT_Q@mail.gmail.com>
Message-ID: <CAAwP0s2GJctkKszq0AaFYkoWw8QUao-UmFN6dhsh15bXD9TZ8g@mail.gmail.com>

On Fri, Apr 12, 2013 at 12:16 AM, Linus Walleij
<linus.walleij at linaro.org> wrote:
> On Thu, Apr 11, 2013 at 10:30 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
>> On 04/10/2013 03:28 PM, Linus Walleij wrote:
>
>>> So the only reason I'm rambing on about this is that it breaks the
>>
>> I'm not sure I understand this paragraph; what is "it" in the line above.
>>
>> If "it" is this patch, then should "breaks" be re-establishes?
>
> No I'm replying to Javier Martinez Canillas mail in this thread:
> http://marc.info/?l=linux-arm-kernel&m=136334655902407&w=2
> which is stating a question to grand, and contains the below
> hunk:
>
>> +static int gpio_irq_request(struct irq_data *d)
>> +{
>> +       struct gpio_bank *bank = irq_data_get_irq_chip_data(d);
>> +
>> +       return gpio_request(irq_to_gpio(bank, d->irq), "gpio-irq");
>> +}
>
> irq_to_gpio(). Notice that. not my_funny_driver_irq_to_gpio().
>
> It's the same thing you mention below:
>
>> If I recall the patch I'm replying to correctly, the idea was to add an
>> "IRQ request" operation that would (internally to the GPIO/IRQ driver
>> itself) map IRQ->GPIO, and call gpio_request(). That would then prevent
>> exactly the situation you mention above.
>
> So the above does not look like it's internal to the driver does it?
>
> I think this is irq_to_gpio sneaking back in, and requiring that every
> driver of this sort follow the same design pattern. And then maybe
> you see my persistance ... are we talking about different things?
>
> So I'd be happy with something local to the driver, foo_irq_to_gpio()
> and that we also back out a bit and see what the subsystem can do
> to avoid this kind of code having to be duplicated everywhere, that's
> all.
>

Hi Linus,

Thanks a lot for your explanation. I didn't know that irq_to_gpio()
was being deprecated and we shouldn't use anymore. Now from this
thread discussion I understand the reasons for this decision.

I'll read the whole thread again and try to implement something that
is local to the gpio-omap driver instead using irq_to_gpio().

Besides using a controller specific mapping instead of irq_to_gpio(),
do you think that is a good idea to add a new "irq_request" function
pointer to struct irq_chip?

The idea is that GPIO controller drivers can call gpio_request() and
enabling the GPIO bank module before a call to request_irq() is made.
Or do you think that is better to implement the DT gpio hogs that you
were suggesting?

I really want to find a solution to this since currently we can't use
any device that uses an GPIO line as an IRQ on OMAP based boards.

> Yours,
> Linus Walleij

Best regards,
Javier


From swarren at wwwdotorg.org  Thu Apr 11 18:51:42 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Thu, 11 Apr 2013 16:51:42 -0600
Subject: [PATCH 3/5] gpio/omap: Add DT support to GPIO driver
In-Reply-To: <CACRpkdbf32Ef77GmXk9id9+RRjcDRTr7S+F4nznoeZU8y=BT_Q@mail.gmail.com>
References: <1329321854-24490-1-git-send-email-b-cousson@ti.com>
 <4F47AD08.4030504@ti.com>
 <CAAwP0s0cB368R2mtbJpTZJreR-5GSRLfxC+8DJLo5nw3_OwBuA@mail.gmail.com>
 <512D39DA.7020306@ti.com> <512D3AB1.1080202@wwwdotorg.org>
 <512D3EC2.6050408@ti.com> <20130302200524.D230F3E1571@localhost>
 <51391F41.5000303@ti.com>
 <CAAwP0s1CFRO-rf==p5sYs1n0gigMif7wuT8Yv0N_iLUDMrtcOg@mail.gmail.com>
 <CACRpkdYHj-rEF3Rk_CWnmmMw_Amr7m8SgQ=-2zsDYuLeuu3azw@mail.gmail.com>
 <514C79E1.4090106@wwwdotorg.org> <514CE0AB.6060207@ti.com>
 <CACRpkdZmv-rAoKSQYpkHHSMzKJOn5TixVW_P3=m7ZNagBYCUPw@mail.gmail.com>
 <515319D5.20105@wwwdotorg.org>
 <CACRpkdYXVLgCz1Tyu-Ls2V2OTc4R3cGNJhfQJB6Hiz_K9dkZYQ@mail.gmail.com>
 <5155C902.7080207@wwwdotorg.org>
 <CACRpkdYbs4-uudpRUY8e+7icYYkZrfM0kReP3pLL5DMiURJ4dg@mail.gmail.com>
 <5165CB9D.1090202@wwwdotorg.org>
 <CACRpkdYirFNqmGhA4K9CL4ve4NYhs8Rd3SFt1iwW9vHBkrcz8g@mail.gmail.com>
 <51671D7B.5060303@wwwdotorg.org>
 <CACRpkdbf32Ef77GmXk9id9+RRjcDRTr7S+F4nznoeZU8y=BT_Q@mail.gmail.com>
Message-ID: <51673E7E.6020807@wwwdotorg.org>

On 04/11/2013 04:16 PM, Linus Walleij wrote:
> On Thu, Apr 11, 2013 at 10:30 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
>> On 04/10/2013 03:28 PM, Linus Walleij wrote:
> 
>>> So the only reason I'm rambing on about this is that it breaks the
>>
>> I'm not sure I understand this paragraph; what is "it" in the line above.
>>
>> If "it" is this patch, then should "breaks" be re-establishes?
> 
> No I'm replying to Javier Martinez Canillas mail in this thread:
> http://marc.info/?l=linux-arm-kernel&m=136334655902407&w=2
> which is stating a question to grand, and contains the below
> hunk:
> 
>> +static int gpio_irq_request(struct irq_data *d)
>> +{
>> +       struct gpio_bank *bank = irq_data_get_irq_chip_data(d);
>> +
>> +       return gpio_request(irq_to_gpio(bank, d->irq), "gpio-irq");
>> +}
> 
> irq_to_gpio(). Notice that. not my_funny_driver_irq_to_gpio().
> 
> It's the same thing you mention below:
> 
>> If I recall the patch I'm replying to correctly, the idea was to add an
>> "IRQ request" operation that would (internally to the GPIO/IRQ driver
>> itself) map IRQ->GPIO, and call gpio_request(). That would then prevent
>> exactly the situation you mention above.

OK, right. sorry for being so confused/confusing.

Yes, that code should certainly call e.g. omap_gpio__irq_to_gpio() not
irq_to_gpio(). Probably gpio_irq_request() wants renaming to something
more like omap_gpio__irq_request() too, so the names don't look like
they'd clash with global functions. (__ added for clarity but probably
only one _ at a time)



From swarren at wwwdotorg.org  Thu Apr 11 18:47:12 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Thu, 11 Apr 2013 16:47:12 -0600
Subject: [PATCH 3/5] gpio/omap: Add DT support to GPIO driver
In-Reply-To: <CACRpkdbf32Ef77GmXk9id9+RRjcDRTr7S+F4nznoeZU8y=BT_Q@mail.gmail.com>
References: <1329321854-24490-1-git-send-email-b-cousson@ti.com>
 <4F47AD08.4030504@ti.com>
 <CAAwP0s0cB368R2mtbJpTZJreR-5GSRLfxC+8DJLo5nw3_OwBuA@mail.gmail.com>
 <512D39DA.7020306@ti.com> <512D3AB1.1080202@wwwdotorg.org>
 <512D3EC2.6050408@ti.com> <20130302200524.D230F3E1571@localhost>
 <51391F41.5000303@ti.com>
 <CAAwP0s1CFRO-rf==p5sYs1n0gigMif7wuT8Yv0N_iLUDMrtcOg@mail.gmail.com>
 <CACRpkdYHj-rEF3Rk_CWnmmMw_Amr7m8SgQ=-2zsDYuLeuu3azw@mail.gmail.com>
 <514C79E1.4090106@wwwdotorg.org> <514CE0AB.6060207@ti.com>
 <CACRpkdZmv-rAoKSQYpkHHSMzKJOn5TixVW_P3=m7ZNagBYCUPw@mail.gmail.com>
 <515319D5.20105@wwwdotorg.org>
 <CACRpkdYXVLgCz1Tyu-Ls2V2OTc4R3cGNJhfQJB6Hiz_K9dkZYQ@mail.gmail.com>
 <5155C902.7080207@wwwdotorg.org>
 <CACRpkdYbs4-uudpRUY8e+7icYYkZrfM0kReP3pLL5DMiURJ4dg@mail.gmail.com>
 <5165CB9D.1090202@wwwdotorg.org>
 <CACRpkdYirFNqmGhA4K9CL4ve4NYhs8Rd3SFt1iwW9vHBkrcz8g@mail.gmail.com>
 <51671D7B.5060303@wwwdotorg.org>
 <CACRpkdbf32Ef77GmXk9id9+RRjcDRTr7S+F4nznoeZU8y=BT_Q@mail.gmail.com>
Message-ID: <51673D70.3010503@wwwdotorg.org>

On 04/11/2013 04:16 PM, Linus Walleij wrote:
> On Thu, Apr 11, 2013 at 10:30 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
>> On 04/10/2013 03:28 PM, Linus Walleij wrote:
> 
>>> So the only reason I'm rambing on about this is that it breaks the
>>
>> I'm not sure I understand this paragraph; what is "it" in the line above.
>>
>> If "it" is this patch, then should "breaks" be re-establishes?
> 
> No I'm replying to Javier Martinez Canillas mail in this thread:
> http://marc.info/?l=linux-arm-kernel&m=136334655902407&w=2
> which is stating a question to grand, and contains the below
> hunk:
> 
>> +static int gpio_irq_request(struct irq_data *d)
>> +{
>> +       struct gpio_bank *bank = irq_data_get_irq_chip_data(d);
>> +
>> +       return gpio_request(irq_to_gpio(bank, d->irq), "gpio-irq");
>> +}
> 
> irq_to_gpio(). Notice that. not my_funny_driver_irq_to_gpio().

OK, right. sorry for being so confused/confusing.

Yes, that code should certainly call e.g. omap_gpio__irq_to_gpio() not
irq_to_gpio(). Probably gpio_irq_request() wants renaming to something
more like omap_gpio__irq_request() too, so the names don't look like
they'd clash with global functions. (__ added for clarity but probably
only one _ at a time)


From mturquette at linaro.org  Thu Apr 11 19:19:23 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Thu, 11 Apr 2013 16:19:23 -0700
Subject: [PATCH v8 1/7] media: V4L2: add temporary clock helpers
In-Reply-To: <13951098.tvATHWRRmI@avalon>
References: <CAGsJ_4zCRBvEX9xEDCr27JLK6wYp_2T_wk2hzVjqpKinbL=9pg@mail.gmail.com>
 <CAGsJ_4yXE7SYLgPucW9kAEYgKg+z93j8yN3d+gvhqeLAn-sSOw@mail.gmail.com>
 <20130411185258.7915.67263@quantum> <13951098.tvATHWRRmI@avalon>
Message-ID: <20130411231923.7915.17215@quantum>

Quoting Laurent Pinchart (2013-04-11 15:35:38)
> Hi Mike,
> 
> On Thursday 11 April 2013 11:52:58 Mike Turquette wrote:
> > Quoting Barry Song (2013-04-11 01:59:28)
> > > 2013/4/11 Guennadi Liakhovetski <g.liakhovetski at gmx.de>:
> > > > On Thu, 11 Apr 2013, Barry Song wrote:
> > > >> 2013/4/11 Guennadi Liakhovetski <g.liakhovetski at gmx.de>:
> > > >> > On Thu, 11 Apr 2013, Barry Song wrote:
> > > >> >> Hi Guennadi,
> > > >> >> 
> > > >> >> > Typical video devices like camera sensors require an external
> > > >> >> > clock source. Many such devices cannot even access their hardware
> > > >> >> > registers without a running clock. These clock sources should be
> > > >> >> > controlled by their consumers. This should be performed, using the
> > > >> >> > generic clock framework. Unfortunately so far only very few
> > > >> >> > systems have been ported to that framework. This patch adds a set
> > > >> >> > of temporary helpers, mimicking the generic clock API, to V4L2.
> > > >> >> > Platforms, adopting the clock API, should switch to using it.
> > > >> >> > Eventually this temporary API should be removed.
> > > >> >> > 
> > > >> >> > Signed-off-by: Guennadi Liakhovetski <g.liakhovetski at xxxxxx>
> > > >> >> > ---
> > > >> >> 
> > > >> >> for your patch 1/8 and 3/8, i think it makes a lot of senses to let
> > > >> >> the object manages its own clock by itself.
> > > >> >> is it possible for us to implement v4l2-clk.c directly as an
> > > >> >> instance of standard clk driver for those systems which don't have
> > > >> >> generic clock,  and remove the V4L2 clock APIs like v4l2_clk_get,
> > > >> >> v4l2_clk_enable from the first day? i mean v4l2-clk.c becomes a temp
> > > >> >> and fake clock controller driver. finally, after people have
> > > >> >> generically clk, remove it.
> > > >> > 
> > > >> > I don't think you can force-enable the CFF on systems, that don't
> > > >> > support it, e.g. PXA.
> > > >> 
> > > >> yes. we can. clock is only a framework, has it any limitation to
> > > >> implement a driver instance on any platform?
> > > > 
> > > > So, you enable CFF, it provides its own clk_* implementation like
> > > > clk_get_rate() etc. Now, PXA already has it defined in
> > > > arch/arm/mach-pxa/clock.c. Don't think this is going to fly.
> > > 
> > > agree.
> > 
> > I came into this thread late and don't have the actual patches in my inbox
> > for review.  That said, I don't understand why V4L2 cares about the clk
> > framework *implementation*?  The clk.h api is the same for platforms using
> > the common struct clk and those still using the legacy method of defining
> > their own struct clk.  If drivers are only consumers of the clk.h api then
> > the implementation underneath should not matter.
> 
> The issue on non-CCF systems is that devices usually can't register clocks 
> dynamically. (Most of) those systems provide system clocks only through their 
> clock API, without a way for the camera IP core to hook up the clock(s) it can 
> provide to the camera sensor. On the consumer side we don't care much about 
> the clock framework implementation, but on the provider side we need a 
> framework that allows registering non-system clocks at runtime.
> 

Yes, you do care about the clock framework implementation if you are a
clock provider.  I still haven't gone through the archives to find these
patches but I hope that any dependency on CONFIG_COMMON_CLK is
conditionalized to have the smallest impact possible.  Making v4l2 as a
whole depend on COMMON_CLK might be a bit overkill compared to just
making individual camera drivers depend on it.

Regards,
Mike

> -- 
> Regards,
> 
> Laurent Pinchart


From nm at ti.com  Thu Apr 11 19:23:52 2013
From: nm at ti.com (Nishanth Menon)
Date: Thu, 11 Apr 2013 18:23:52 -0500
Subject: [RESEND PATCH V6 1/4] cpufreq: exynos: Add cpufreq driver for
 exynos5440
In-Reply-To: <1365415054-30771-1-git-send-email-amit.daniel@samsung.com>
References: <CAKohpo=t_YTCTRCfnwQ+GPF=frsTGDigT3RZHJuVQ+R+YZU7Hg@mail.gmail.com>
 <1365415054-30771-1-git-send-email-amit.daniel@samsung.com>
Message-ID: <CAGo_u6oZM0K8XDMtmXKFyoGy2qf+-HSPvU0EMangM5Jj_prKsA@mail.gmail.com>

Hi,
On Mon, Apr 8, 2013 at 4:57 AM, Amit Daniel Kachhap
<amit.daniel at samsung.com> wrote:
> +
> +static int init_div_table(void)
> +{
> +       struct cpufreq_frequency_table *freq_tbl = dvfs_info->freq_table;
> +       unsigned int tmp, clk_div, ema_div, freq, volt_id;
> +       int i = 0;
> +       struct opp *opp;
> +
> +       for (i = 0; freq_tbl[i].frequency != CPUFREQ_TABLE_END; i++) {
> +
> +               opp = opp_find_freq_exact(dvfs_info->dev,
> +                                       freq_tbl[i].frequency * 1000, true);
> +               if (IS_ERR(opp)) {
> +                       dev_err(dvfs_info->dev,
> +                               "failed to find valid OPP for %u KHZ\n",
> +                               freq_tbl[i].frequency);
> +                       return PTR_ERR(opp);
> +               }
please use RCU read locks.

> +
> +               freq = freq_tbl[i].frequency / 1000; /* In MHZ */
> +               clk_div = ((freq / CPU_DIV_FREQ_MAX) & P0_7_CPUCLKDEV_MASK)
> +                                       << P0_7_CPUCLKDEV_SHIFT;
> +               clk_div |= ((freq / CPU_ATB_FREQ_MAX) & P0_7_ATBCLKDEV_MASK)
> +                                       << P0_7_ATBCLKDEV_SHIFT;
> +               clk_div |= ((freq / CPU_DBG_FREQ_MAX) & P0_7_CSCLKDEV_MASK)
> +                                       << P0_7_CSCLKDEV_SHIFT;
> +
> +               /* Calculate EMA */
> +               volt_id = opp_get_voltage(opp);
Please use RCU read locks as documented for OPP library.

Regards,
Nishanth Menon


From rui.zhang at intel.com  Thu Apr 11 19:26:01 2013
From: rui.zhang at intel.com (Zhang Rui)
Date: Fri, 12 Apr 2013 07:26:01 +0800
Subject: [PATCH 14/30] thermal/exynos: remove unnecessary header inclusions
In-Reply-To: <51660F85.4000105@ti.com>
References: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
 <1365638712-1028578-15-git-send-email-arnd@arndb.de>
 <51660F85.4000105@ti.com>
Message-ID: <1365722761.2183.7.camel@rzhang1-mobl4>

On Wed, 2013-04-10 at 21:19 -0400, Eduardo Valentin wrote:
> Rui, Arnd,
> 
> As agreed in [1], I will be helping on the thermal maintenance.
> 
> On 10-04-2013 20:04, Arnd Bergmann wrote:
> > In multiplatform configurations, we cannot include headers
> > provided by only the exynos platform. Fortunately a number
> > of drivers that include those headers do not actually need
> > them, so we can just remove the inclusions.
> >
> > Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> > Cc: linux-pm at vger.kernel.org
> > Cc: Zhang Rui <rui.zhang at intel.com>
> 
> This patch looks good to me.
> 
> You can add my:
> Acked-by: Eduardo Valentin <eduardo.valentin at ti.com>
> 
applied to thermal thermal branch.

thanks,
rui
> 
> [1] - http://marc.info/?l=linux-pm&m=136560509922173&w=2




From jgarzik at pobox.com  Thu Apr 11 19:38:25 2013
From: jgarzik at pobox.com (Jeff Garzik)
Date: Thu, 11 Apr 2013 19:38:25 -0400
Subject: [PATCH 4/6] ata: i.MX PATA: add devicetree support
In-Reply-To: <1365067509-10186-5-git-send-email-s.hauer@pengutronix.de>
References: <1365067509-10186-1-git-send-email-s.hauer@pengutronix.de>
 <1365067509-10186-5-git-send-email-s.hauer@pengutronix.de>
Message-ID: <51674971.6010005@pobox.com>

On 04/04/2013 05:25 AM, Sascha Hauer wrote:
> Not much to do here, only the compatible entries have to be added.
>
> Signed-off-by: Sascha Hauer <s.hauer at pengutronix.de>
> ---
>   Documentation/devicetree/bindings/ata/imx-pata.txt | 17 +++++++++++++++++
>   drivers/ata/pata_imx.c                             |  9 +++++++++
>   2 files changed, 26 insertions(+)
>   create mode 100644 Documentation/devicetree/bindings/ata/imx-pata.txt

applied 1-4





From shawn.guo at linaro.org  Thu Apr 11 20:03:43 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Fri, 12 Apr 2013 08:03:43 +0800
Subject: [GIT PULL v2] Reset controller API
In-Reply-To: <20130411171443.GB31066@quad.lixom.net>
References: <1365495574.4023.32.camel@pizza.hi.pengutronix.de>
 <20130411102047.GA7437@quad.lixom.net>
 <CAOesGMidoasD35LL4VvCUPwTPrrRE9hxPGUVmuGQtuvH_nxs0g@mail.gmail.com>
 <1365683829.4388.52.camel@pizza.hi.pengutronix.de>
 <20130411171443.GB31066@quad.lixom.net>
Message-ID: <20130412000340.GA16970@S2101-09.ap.freescale.net>

On Thu, Apr 11, 2013 at 10:14:43AM -0700, Olof Johansson wrote:
> On Thu, Apr 11, 2013 at 02:37:09PM +0200, Philipp Zabel wrote:
> > Hi Olof,
> > 
> > Am Donnerstag, den 11.04.2013, 03:25 -0700 schrieb Olof Johansson:
> > > On Thu, Apr 11, 2013 at 3:20 AM, Olof Johansson <olof at lixom.net> wrote:
> > > > On Tue, Apr 09, 2013 at 10:19:34AM +0200, Philipp Zabel wrote:
> > > >> Hi Olof,
> > > >>
> > > >> I have added two fixes on top of the reset series at
> > > >> git://git.pengutronix.de/git/pza/linux.git reset/for_v3.10.
> > > >> Could you pull them in together with the rest?
> > > >>
> > > >> The following changes since commit 8bb9660418e05bb1845ac1a2428444d78e322cc7:
> > > >>
> > > >>   Linux 3.9-rc4 (2013-03-23 16:52:44 -0700)
> > > >>
> > > >> are available in the git repository at:
> > > >>
> > > >>   git://git.pengutronix.de/git/pza/linux.git reset/for_v3.10
> > > >>
> > > >> for you to fetch changes up to fbdb93ecb869f02a5f8f145fa06a0984c415a7d4:
> > > >>
> > > >>   Documentation: gpio-reset.txt: Fix 'initially-in-reset' example (2013-04-09 09:55:00 +0200)
> > > >>
> > > >> They add a simple API for devices to request being reset by separate
> > > >> reset controller hardware and implement the reset signal device tree
> > > >> bindings proposed by Stephen Warren.
> > > >> The patches have been discussed on the linux-arm-kernel list under the topic
> > > >> "Reset controller API to reset IP modules on i.MX5 and i.MX6".
> > > >>
> > > >> ----------------------------------------------------------------
> > > >> Dan Carpenter (1):
> > > >>       reset: NULL deref on allocation failure
> > > >>
> > > >> Fabio Estevam (1):
> > > >>       Documentation: gpio-reset.txt: Fix 'initially-in-reset' example
> > > >>
> > > >> Philipp Zabel (2):
> > > >>       reset: Add reset controller API
> > > >>       reset: Add driver for gpio-controlled reset pins
> > > >>
> > > >> Stephen Warren (1):
> > > >>       dt: describe base reset signal binding
> > > >
> > > > Hmm, I don't see an ack or reviewed-by on these subsystem bindings from
> > > > neither Rob nor Grant.
> > > >
> > > > Since it's a brand new subsystem binding, I'd like to see them ack it
> > > > before we pick it up.
> > > 
> > > Sigh. Ok, so I now stumbled across the Ack from Rob that you didn't
> > > pick up. Don't do it like that again, please. If Shawn prematurely
> > > bases his code on top of unacked patches, then that's his problem, not
> > > yours.
> > 
> > Sorry I didn't notice that Rob's ack didn't have you in Cc. So shall I
> > leave the dt binding patch untouched this time? I'll take note of this
> > for the future.
> 
> See below.
> 
> > > The problem still remains though, since the gpio-reset binding hasn't
> > > seen an ack on the list, as far as I can tell. And I'll have a comment
> > > on that as well in a minute, see separate reply on that patch.
> > 
> > Ok. What would you have me do now? I could revert the gpio-reset patch
> > (possibly asking Shawn to pull that, too), and have it do another round
> > on the list instead. Or I could address your comments with a relative
> > patch, and put that on top.
> 
> This is a case where rebase is fine, as far as I am concerned. Just tell
> Shawn to also rebase his dependent code accordingly. That way you can
> add Rob's ack too.
> 
> Once the bindings have been ironed out you can add it back, but that's looking
> like 3.11 material now.

Just to be clear, you are asking Philipp to move patch "reset: Add
driver for gpio-controlled reset pins" out (leave it for 3.11), and add
Rob's ACK on patch "dt: describe base reset signal binding", and then
resend the pull request. Is it correct?

Shawn



From jason at lakedaemon.net  Thu Apr 11 19:29:30 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Thu, 11 Apr 2013 19:29:30 -0400
Subject: [PATCH v3 4/9] ARM: mvebu: Enable pj4b on LPAE compilations
In-Reply-To: <51671FFE.1010909@free-electrons.com>
References: <1365461538-30702-1-git-send-email-gregory.clement@free-electrons.com>
 <1365461538-30702-5-git-send-email-gregory.clement@free-electrons.com>
 <20130411180844.GO28693@titan.lakedaemon.net>
 <51671FFE.1010909@free-electrons.com>
Message-ID: <20130411232930.GQ28693@titan.lakedaemon.net>

On Thu, Apr 11, 2013 at 10:41:34PM +0200, Gregory CLEMENT wrote:
> Hi Jason,
> 
> On 04/11/2013 08:08 PM, Jason Cooper wrote:
> > On Tue, Apr 09, 2013 at 12:52:12AM +0200, Gregory CLEMENT wrote:
> >> From: Lior Amsalem <alior at marvell.com>
> >>
> >> pj4b cpus are LPAE capable so enable them on LPAE compilations
> >>
> >> Signed-off-by: Lior Amsalem <alior at marvell.com>
> >> Tested-by: Franklin <flin at marvell.com>
> >> Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
> >> ---
> >>  arch/arm/mm/proc-v7.S |    3 ++-
> >>  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > Applied to mvebu/soc
> > 
...
> 
> However, this one should go through Russell's git tree.  Or at least
> you need his acked-by. I have already submit this patch on Russell
> patch system. Unfortunately Russell told that he will be away for
> around one week.
> 
> This patch is needed to have LPAE support, but all the other patches
> don't depend on it. That means that if you applied all the other
> patches it won't break anything even if at the end this patch is not
> merged. But I really hope that Russell will be able to apply this
> patch to his git tree.

ok, thanks for catching this before I sent the PR.  I'll drop it.

thx,

Jason.


From jason at lakedaemon.net  Thu Apr 11 14:12:00 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Thu, 11 Apr 2013 14:12:00 -0400
Subject: [PATCH v3 5/9] ARM: dts: Add a 64 bits version of the skeleton
 device tree
In-Reply-To: <1365461538-30702-6-git-send-email-gregory.clement@free-electrons.com>
References: <1365461538-30702-1-git-send-email-gregory.clement@free-electrons.com>
 <1365461538-30702-6-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <20130411181200.GP28693@titan.lakedaemon.net>

On Tue, Apr 09, 2013 at 12:52:13AM +0200, Gregory CLEMENT wrote:
> From: Lior Amsalem <alior at marvell.com>
> 
> In order to be able to use more than 4GB address-cells and size-cells
> have to be set to 2
> 
> Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
> Signed-off-by: Lior Amsalem <alior at marvell.com>
> ---
>  arch/arm/boot/dts/skeleton64.dtsi |   13 +++++++++++++
>  1 file changed, 13 insertions(+)
>  create mode 100644 arch/arm/boot/dts/skeleton64.dtsi

Applied to mvebu/dt

Gregory,

Once I can pull in Thomas' pci work, you'll just need to rebase patches
1, and 6 - 9 against mvebu/dt.

thx,

Jason.


From jason at lakedaemon.net  Thu Apr 11 19:35:05 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Thu, 11 Apr 2013 19:35:05 -0400
Subject: [PATCH v3 5/9] ARM: dts: Add a 64 bits version of the skeleton
 device tree
In-Reply-To: <5167219B.8070404@free-electrons.com>
References: <1365461538-30702-1-git-send-email-gregory.clement@free-electrons.com>
 <1365461538-30702-6-git-send-email-gregory.clement@free-electrons.com>
 <20130411181200.GP28693@titan.lakedaemon.net>
 <5167219B.8070404@free-electrons.com>
Message-ID: <20130411233505.GR28693@titan.lakedaemon.net>

On Thu, Apr 11, 2013 at 10:48:27PM +0200, Gregory CLEMENT wrote:
> Hi Jason,
> 
> On 04/11/2013 08:12 PM, Jason Cooper wrote:
> > On Tue, Apr 09, 2013 at 12:52:13AM +0200, Gregory CLEMENT wrote:
> >> From: Lior Amsalem <alior at marvell.com>
> >>
> >> In order to be able to use more than 4GB address-cells and size-cells
> >> have to be set to 2
> >>
> >> Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
> >> Signed-off-by: Lior Amsalem <alior at marvell.com>
> >> ---
> >>  arch/arm/boot/dts/skeleton64.dtsi |   13 +++++++++++++
> >>  1 file changed, 13 insertions(+)
> >>  create mode 100644 arch/arm/boot/dts/skeleton64.dtsi
> > 
> > Applied to mvebu/dt
> > 
> > Gregory,
> > 
> > Once I can pull in Thomas' pci work, you'll just need to rebase patches
> > 1, and 6 - 9 against mvebu/dt.
> > 
> 
> Yes sure! When did you plan to pull the dts part of Thomas' pci work?
> Is there still anything left to prevent to pull this part?

Good call, I'm just waiting for the last Ack Thomas said he needs on the
first of/pci patch.  My head has been fuzzy with hay fever for the past
three days.  Obviously, I can pull in the dts portion.

thx,

Jason.


From olof at lixom.net  Thu Apr 11 20:15:25 2013
From: olof at lixom.net (Olof Johansson)
Date: Thu, 11 Apr 2013 17:15:25 -0700
Subject: [GIT PULL v2] Reset controller API
In-Reply-To: <20130412000340.GA16970@S2101-09.ap.freescale.net>
References: <1365495574.4023.32.camel@pizza.hi.pengutronix.de>
 <20130411102047.GA7437@quad.lixom.net>
 <CAOesGMidoasD35LL4VvCUPwTPrrRE9hxPGUVmuGQtuvH_nxs0g@mail.gmail.com>
 <1365683829.4388.52.camel@pizza.hi.pengutronix.de>
 <20130411171443.GB31066@quad.lixom.net>
 <20130412000340.GA16970@S2101-09.ap.freescale.net>
Message-ID: <CAOesGMiyDvC7GXetEZY1Tp=s2jqvU_4gJhvgdYe5TUmdRaogsg@mail.gmail.com>

On Thu, Apr 11, 2013 at 5:03 PM, Shawn Guo <shawn.guo at linaro.org> wrote:
> On Thu, Apr 11, 2013 at 10:14:43AM -0700, Olof Johansson wrote:
>> On Thu, Apr 11, 2013 at 02:37:09PM +0200, Philipp Zabel wrote:
>> > Hi Olof,
>> >
>> > Am Donnerstag, den 11.04.2013, 03:25 -0700 schrieb Olof Johansson:
>> > > On Thu, Apr 11, 2013 at 3:20 AM, Olof Johansson <olof at lixom.net> wrote:
>> > > > On Tue, Apr 09, 2013 at 10:19:34AM +0200, Philipp Zabel wrote:
>> > > >> Hi Olof,
>> > > >>
>> > > >> I have added two fixes on top of the reset series at
>> > > >> git://git.pengutronix.de/git/pza/linux.git reset/for_v3.10.
>> > > >> Could you pull them in together with the rest?
>> > > >>
>> > > >> The following changes since commit 8bb9660418e05bb1845ac1a2428444d78e322cc7:
>> > > >>
>> > > >>   Linux 3.9-rc4 (2013-03-23 16:52:44 -0700)
>> > > >>
>> > > >> are available in the git repository at:
>> > > >>
>> > > >>   git://git.pengutronix.de/git/pza/linux.git reset/for_v3.10
>> > > >>
>> > > >> for you to fetch changes up to fbdb93ecb869f02a5f8f145fa06a0984c415a7d4:
>> > > >>
>> > > >>   Documentation: gpio-reset.txt: Fix 'initially-in-reset' example (2013-04-09 09:55:00 +0200)
>> > > >>
>> > > >> They add a simple API for devices to request being reset by separate
>> > > >> reset controller hardware and implement the reset signal device tree
>> > > >> bindings proposed by Stephen Warren.
>> > > >> The patches have been discussed on the linux-arm-kernel list under the topic
>> > > >> "Reset controller API to reset IP modules on i.MX5 and i.MX6".
>> > > >>
>> > > >> ----------------------------------------------------------------
>> > > >> Dan Carpenter (1):
>> > > >>       reset: NULL deref on allocation failure
>> > > >>
>> > > >> Fabio Estevam (1):
>> > > >>       Documentation: gpio-reset.txt: Fix 'initially-in-reset' example
>> > > >>
>> > > >> Philipp Zabel (2):
>> > > >>       reset: Add reset controller API
>> > > >>       reset: Add driver for gpio-controlled reset pins
>> > > >>
>> > > >> Stephen Warren (1):
>> > > >>       dt: describe base reset signal binding
>> > > >
>> > > > Hmm, I don't see an ack or reviewed-by on these subsystem bindings from
>> > > > neither Rob nor Grant.
>> > > >
>> > > > Since it's a brand new subsystem binding, I'd like to see them ack it
>> > > > before we pick it up.
>> > >
>> > > Sigh. Ok, so I now stumbled across the Ack from Rob that you didn't
>> > > pick up. Don't do it like that again, please. If Shawn prematurely
>> > > bases his code on top of unacked patches, then that's his problem, not
>> > > yours.
>> >
>> > Sorry I didn't notice that Rob's ack didn't have you in Cc. So shall I
>> > leave the dt binding patch untouched this time? I'll take note of this
>> > for the future.
>>
>> See below.
>>
>> > > The problem still remains though, since the gpio-reset binding hasn't
>> > > seen an ack on the list, as far as I can tell. And I'll have a comment
>> > > on that as well in a minute, see separate reply on that patch.
>> >
>> > Ok. What would you have me do now? I could revert the gpio-reset patch
>> > (possibly asking Shawn to pull that, too), and have it do another round
>> > on the list instead. Or I could address your comments with a relative
>> > patch, and put that on top.
>>
>> This is a case where rebase is fine, as far as I am concerned. Just tell
>> Shawn to also rebase his dependent code accordingly. That way you can
>> add Rob's ack too.
>>
>> Once the bindings have been ironed out you can add it back, but that's looking
>> like 3.11 material now.
>
> Just to be clear, you are asking Philipp to move patch "reset: Add
> driver for gpio-controlled reset pins" out (leave it for 3.11), and add
> Rob's ACK on patch "dt: describe base reset signal binding", and then
> resend the pull request. Is it correct?

Yep! We'll stage it as a late branch.



-Olof


From horms at verge.net.au  Thu Apr 11 20:21:37 2013
From: horms at verge.net.au (Simon Horman)
Date: Fri, 12 Apr 2013 09:21:37 +0900
Subject: [GIT PULL] Renesas ARM based SoC lager board updates for v3.10
In-Reply-To: <20130411173819.GC373@quad.lixom.net>
References: <1365668326-22518-1-git-send-email-horms+renesas@verge.net.au>
 <20130411173819.GC373@quad.lixom.net>
Message-ID: <20130412002134.GA24461@verge.net.au>

On Thu, Apr 11, 2013 at 10:38:19AM -0700, Olof Johansson wrote:
> On Thu, Apr 11, 2013 at 05:18:45PM +0900, Simon Horman wrote:
> > Hi Arnd, Hi Olof,
> > 
> > Please note this is based on a merge with renesas-soc-r8a7790-for-v3.10
> > which corresponds to the pull request I sent a few minutes ago:
> > "[GIT PULL] Renesas ARM based r8a7790 SoC update for v3.10".
> > 
> > The following changes since commit ac119ccd80eb914185229c4c4086f3debdd4c764:
> > 
> >   Merge branch 'soc-r8a7790' into boards-lager (2013-04-09 21:40:20 +0900)
> > 
> > are available in the git repository at:
> > 
> > 
> >   git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-boards-lager-for-v3.10
> > 
> > for you to fetch changes up to 65be2de17aae0fd94e55f7c4a474933cf4607ea2:
> > 
> >   ARM: shmobile: use r8a7790 timer setup code on Lager (2013-04-09 21:40:59 +0900)
> > 
> > ----------------------------------------------------------------
> > Renesas ARM based SoC lager board updates for v3.10
> > 
> > * Use r8a7790 timer setup code to force the
> >   arch timer to be enabled regardless of the bootloader setting
> >   - This is necessary for the lager board to boot
> > 
> > This pull request is based on:
> > git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git renesas-boards3-for-v3.10
> > git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git renesas-soc-r8a7790-for-v3.10
> > 
> > The merge was made to provide the r8a7790 timer setup code
> 
> Pulled.
> 
> By the way, the dependencies above are probably better described in
> the email than in the tag, since there's a good chance your branches
> will be gone from kernel.org by the time someone reads the changelog;
> i.e. it doesn't really provide useful information for the changelog. It's very
> useful for us though so please continue to provide it.

Thanks. In general the merges refer to tags which I intend to keep around.
But I take your point and I will move the merge information out of the
tag and thus the change log and into the email.


From horms at verge.net.au  Thu Apr 11 20:25:35 2013
From: horms at verge.net.au (Simon Horman)
Date: Fri, 12 Apr 2013 09:25:35 +0900
Subject: [PATCH] ARM: shmobile: r8a7740: Add Suspend-To-RAM modes and
 CPUIdle
In-Reply-To: <51667D68.7070804@linaro.org>
References: <1365609107-14290-1-git-send-email-hechtb+renesas@gmail.com>
 <5165E929.9030309@linaro.org>
 <CABYn4sxEOvQhZP7GnS5-AgNjkvJJXyv4n1UjVGBjXbVq0N+9_A@mail.gmail.com>
 <51667D68.7070804@linaro.org>
Message-ID: <20130412002535.GB24461@verge.net.au>

On Thu, Apr 11, 2013 at 11:07:52AM +0200, Daniel Lezcano wrote:
> On 04/11/2013 09:07 AM, Bastian Hecht wrote:
> > Hello Daniel,
> > 
> > thanks for the consolidation efforts.
> > 
> > 2013/4/11 Daniel Lezcano <daniel.lezcano at linaro.org>:
> >> On 04/10/2013 05:51 PM, Bastian Hecht wrote:
> >>> We add 2 sleep modes and register a CPUIdle driver that uses them.
> >>>
> >>> - A3SM PLL0 on/off:     Power domain A3SM that contains the ARM core
> >>>                         and the 2nd level cache with either PLL0 on
> >>>                       or off
> >>>
> >>> As the suspend to memory mechanism we use A3SM PLL off.
> >>>
> >>> The setup of the SYSC regarding the external IRQs is taken from
> >>> pm-sh7372.c from Magnus Damm.
> >>>
> >>> Signed-off-by: Bastian Hecht <hechtb+renesas at gmail.com>
> >>> ---
> >>> Ok I need to add some remarks here:
> >>>
> >>> First this patch relies on a fix I've sent out today:
> >>> "ARM: hw_breakpoint: Do not use __cpuinitdata for dbg_cpu_pm_nb"
> >>> Without it we can't use suspend at all without a kernel panic.
> >>>
> >>> Next you can test this in two ways:
> >>> Either add IRQF_NO_SUSPEND to the touchscreen driver st1232 at IRQ registration
> >>> (hack) or extend the irqpin driver to support wakeup devices properly, meaning
> >>> adding suspend and resume callbacks that handle it (proper way). Or you can add
> >>> no_console_suspend to the boot options in r8a7740-armadillo800eva.dts. This way
> >>> you can use the serial console as wakeup device.
> >>>
> >>>
> >>>  arch/arm/mach-shmobile/Makefile               |    2 +-
> >>>  arch/arm/mach-shmobile/include/mach/r8a7740.h |    2 +
> >>>  arch/arm/mach-shmobile/pm-r8a7740.c           |  220 ++++++++++++++++++++++++-
> >>>  arch/arm/mach-shmobile/sleep-r8a7740.S        |   68 ++++++++
> >>>  4 files changed, 289 insertions(+), 3 deletions(-)
> >>>  create mode 100644 arch/arm/mach-shmobile/sleep-r8a7740.S
> >>>
> >>> diff --git a/arch/arm/mach-shmobile/Makefile b/arch/arm/mach-shmobile/Makefile
> >>> index 068f1da..0568894 100644
> >>> --- a/arch/arm/mach-shmobile/Makefile
> >>> +++ b/arch/arm/mach-shmobile/Makefile
> >>> @@ -30,7 +30,7 @@ obj-$(CONFIG_SUSPEND)               += suspend.o
> >>>  obj-$(CONFIG_CPU_IDLE)               += cpuidle.o
> >>>  obj-$(CONFIG_ARCH_SHMOBILE)  += pm-rmobile.o
> >>>  obj-$(CONFIG_ARCH_SH7372)    += pm-sh7372.o sleep-sh7372.o
> >>> -obj-$(CONFIG_ARCH_R8A7740)   += pm-r8a7740.o
> >>> +obj-$(CONFIG_ARCH_R8A7740)   += pm-r8a7740.o sleep-r8a7740.o
> >>>  obj-$(CONFIG_ARCH_R8A7779)   += pm-r8a7779.o
> >>>  obj-$(CONFIG_ARCH_SH73A0)    += pm-sh73a0.o
> >>>
> >>> diff --git a/arch/arm/mach-shmobile/include/mach/r8a7740.h b/arch/arm/mach-shmobile/include/mach/r8a7740.h
> >>> index abdc4d4..ba4707b 100644
> >>> --- a/arch/arm/mach-shmobile/include/mach/r8a7740.h
> >>> +++ b/arch/arm/mach-shmobile/include/mach/r8a7740.h
> >>> @@ -540,6 +540,8 @@ extern void r8a7740_add_standard_devices(void);
> >>>  extern void r8a7740_clock_init(u8 md_ck);
> >>>  extern void r8a7740_pinmux_init(void);
> >>>  extern void r8a7740_pm_init(void);
> >>> +extern void r8a7740_resume(void);
> >>> +extern void r8a7740_shutdown(void);
> >>>
> >>>  #ifdef CONFIG_PM
> >>>  extern void __init r8a7740_init_pm_domains(void);
> >>> diff --git a/arch/arm/mach-shmobile/pm-r8a7740.c b/arch/arm/mach-shmobile/pm-r8a7740.c
> >>> index 40b87aa..d4613f0 100644
> >>> --- a/arch/arm/mach-shmobile/pm-r8a7740.c
> >>> +++ b/arch/arm/mach-shmobile/pm-r8a7740.c
> >>> @@ -8,10 +8,54 @@
> >>>   * License.  See the file "COPYING" in the main directory of this archive
> >>>   * for more details.
> >>>   */
> >>> +#include <linux/bitrev.h>
> >>>  #include <linux/console.h>
> >>> +#include <linux/cpuidle.h>
> >>> +#include <linux/module.h>
> >>>  #include <linux/suspend.h>
> >>> +#include <linux/io.h>
> >>> +#include <asm/suspend.h>
> >>> +#include <asm/cacheflush.h>
> >>> +#include <asm/cpuidle.h>
> >>> +#include <asm/hardware/cache-l2x0.h>
> >>>  #include <mach/pm-rmobile.h>
> >>>  #include <mach/common.h>
> >>> +#include <mach/r8a7740.h>
> >>> +
> >>> +/* CPGA */
> >>> +#define PLLC01STPCR  IOMEM(0xe61500c8)
> >>> +#define SYSTBCR              IOMEM(0xe6150024)
> >>> +
> >>> +/* SYSC */
> >>> +#define STBCHR               IOMEM(0xe6180000)
> >>> +#define STBCHRB              IOMEM(0xe6180040)
> >>> +#define SPDCR                IOMEM(0xe6180008)
> >>> +#define SBAR         IOMEM(0xe6180020)
> >>> +#define SRSTFR               IOMEM(0xe61800B4)
> >>> +#define WUPSMSK              IOMEM(0xe618002c)
> >>> +#define WUPSMSK2     IOMEM(0xe6180048)
> >>> +#define WUPSFAC              IOMEM(0xe6180098)
> >>> +#define IRQCR                IOMEM(0xe618022c)
> >>> +#define IRQCR2               IOMEM(0xe6180238)
> >>> +#define IRQCR3               IOMEM(0xe6180244)
> >>> +#define IRQCR4               IOMEM(0xe6180248)
> >>> +
> >>> +/* SRSTFR flags */
> >>> +#define RAMST                (1 << 19)
> >>> +#define RCLNKA               (1 << 7)
> >>> +#define RCPRES               (1 << 5)
> >>> +#define RCWD1                (1 << 4)
> >>> +#define RPF          (1 << 0)
> >>> +
> >>> +/* INTC */
> >>> +#define ICR1A                IOMEM(0xe6900000)
> >>> +#define ICR2A                IOMEM(0xe6900004)
> >>> +#define ICR3A                IOMEM(0xe6900008)
> >>> +#define ICR4A                IOMEM(0xe690000c)
> >>> +#define INTMSK00A    IOMEM(0xe6900040)
> >>> +#define INTMSK10A    IOMEM(0xe6900044)
> >>> +#define INTMSK20A    IOMEM(0xe6900048)
> >>> +#define INTMSK30A    IOMEM(0xe690004c)
> >>>
> >>>  #ifdef CONFIG_PM
> >>>  static int r8a7740_pd_a4s_suspend(void)
> >>> @@ -58,12 +102,183 @@ void __init r8a7740_init_pm_domains(void)
> >>>       rmobile_init_domains(r8a7740_pm_domains, ARRAY_SIZE(r8a7740_pm_domains));
> >>>       pm_genpd_add_subdomain_names("A4S", "A3SP");
> >>>  }
> >>> -
> >>>  #endif /* CONFIG_PM */
> >>>
> >>> +#if defined(CONFIG_SUSPEND) || defined(CONFIG_CPU_IDLE)
> >>> +static void r8a7740_set_reset_vector(unsigned long address)
> >>> +{
> >>> +     __raw_writel(address, SBAR);
> >>> +}
> >>> +
> >>> +static void r8a7740_icr_to_irqcr(unsigned long icr, u16 *irqcr1p, u16 *irqcr2p)
> >>> +{
> >>> +     u16 tmp, irqcr1, irqcr2;
> >>> +     int k;
> >>> +
> >>> +     irqcr1 = 0;
> >>> +     irqcr2 = 0;
> >>> +
> >>> +     /* convert INTCA ICR register layout to SYSC IRQCR+IRQCR2 */
> >>> +     for (k = 0; k <= 7; k++) {
> >>> +             tmp = (icr >> ((7 - k) * 4)) & 0xf;
> >>> +             irqcr1 |= (tmp & 0x03) << (k * 2);
> >>> +             irqcr2 |= (tmp >> 2) << (k * 2);
> >>> +     }
> >>> +
> >>> +     *irqcr1p = irqcr1;
> >>> +     *irqcr2p = irqcr2;
> >>> +}
> >>> +
> >>> +static void r8a7740_setup_sysc(unsigned long msk, unsigned long msk2)
> >>> +{
> >>> +     u16 irqcrx_low, irqcrx_high, irqcry_low, irqcry_high;
> >>> +     unsigned long tmp;
> >>> +
> >>> +     /* read IRQ0A -> IRQ15A mask */
> >>> +     tmp = bitrev8(__raw_readb(INTMSK00A));
> >>> +     tmp |= bitrev8(__raw_readb(INTMSK10A)) << 8;
> >>> +
> >>> +     /* setup WUPSMSK from clocks and external IRQ mask */
> >>> +     msk = (~msk & 0xc030000f) | (tmp << 4);
> >>> +     __raw_writel(msk, WUPSMSK);
> >>> +
> >>> +     /* propage level/edge trigger for external IRQ 0->15 */
> >>> +     r8a7740_icr_to_irqcr(__raw_readl(ICR1A), &irqcrx_low, &irqcry_low);
> >>> +     r8a7740_icr_to_irqcr(__raw_readl(ICR2A), &irqcrx_high, &irqcry_high);
> >>> +     __raw_writel((irqcrx_high << 16) | irqcrx_low, IRQCR);
> >>> +     __raw_writel((irqcry_high << 16) | irqcry_low, IRQCR2);
> >>> +
> >>> +     /* read IRQ16A -> IRQ31A mask */
> >>> +     tmp = bitrev8(__raw_readb(INTMSK20A));
> >>> +     tmp |= bitrev8(__raw_readb(INTMSK30A)) << 8;
> >>> +
> >>> +     /* setup WUPSMSK2 from clocks and external IRQ mask */
> >>> +     msk2 = (~msk2 & 0x00030000) | tmp;
> >>> +     __raw_writel(msk2, WUPSMSK2);
> >>> +
> >>> +     /* propage level/edge trigger for external IRQ 16->31 */
> >>> +     r8a7740_icr_to_irqcr(__raw_readl(ICR3A), &irqcrx_low, &irqcry_low);
> >>> +     r8a7740_icr_to_irqcr(__raw_readl(ICR4A), &irqcrx_high, &irqcry_high);
> >>> +     __raw_writel((irqcrx_high << 16) | irqcrx_low, IRQCR3);
> >>> +     __raw_writel((irqcry_high << 16) | irqcry_low, IRQCR4);
> >>> +}
> >>> +
> >>> +static void r8a7740_prepare_wakeup(void)
> >>> +{
> >>> +     /* clear all flags that lead to a cold boot */
> >>> +     __raw_writel(~(RAMST | RCLNKA | RCPRES | RCWD1 | RPF), SRSTFR);
> >>> +     /* indicate warm boot */
> >>> +     __raw_writel(0x80000000, STBCHRB);
> >>> +     /* clear other flags checked by internal ROM boot loader */
> >>> +     __raw_writel(0x00000000, STBCHR);
> >>> +}
> >>> +
> >>> +static int r8a7740_do_suspend(unsigned long unused)
> >>> +{
> >>> +     /*
> >>> +      * cpu_suspend() guarantees that all data made it to the L2.
> >>> +      * Flush it out now and disable the cache controller.
> >>> +      */
> >>> +     outer_flush_all();
> >>> +     outer_disable();
> >>> +
> >>> +     r8a7740_shutdown();
> >>> +
> >>> +     /* in case WFI fails to enter the low power state, restore things */
> >>> +     outer_resume();
> >>> +
> >>> +     return 0;
> >>> +}
> >>> +
> >>> +static void r8a7740_enter_a3sm_common(int pllc0_on)
> >>> +{
> >>> +     u32 reg32;
> >>> +
> >>> +     if (pllc0_on)
> >>> +             __raw_writel(0, PLLC01STPCR);
> >>> +     else
> >>> +             __raw_writel(1 << 28, PLLC01STPCR);
> >>> +
> >>> +     r8a7740_set_reset_vector(__pa(r8a7740_resume));
> >>> +     r8a7740_prepare_wakeup();
> >>> +     r8a7740_setup_sysc(1 << 0, 0);
> >>> +
> >>> +     /* Activate delayed shutdown of A3SM */
> >>> +     reg32 = __raw_readl(SPDCR);
> >>> +     reg32 |= (1 << 31) | (1 << 12);
> >>> +     __raw_writel(reg32, SPDCR);
> >>> +
> >>> +     /* We activate CPU Core Standby as well here */
> >>> +     reg32 = __raw_readl(SYSTBCR);
> >>> +     reg32 |= (1 << 4);
> >>> +     __raw_writel(reg32, SYSTBCR);
> >>> +
> >>> +     /* Clear Wakeup Factors and do suspend */
> >>> +     reg32 = __raw_readl(WUPSFAC);
> >>> +     cpu_suspend(0, r8a7740_do_suspend);
> >>> +     outer_resume();
> >>> +     reg32 = __raw_readl(WUPSFAC);
> >>> +
> >>> +     /* Clear CPU Core Standby flag for other WFI instructions */
> >>> +     reg32 &= ~(1 << 4);
> >>> +     __raw_writel(reg32, SYSTBCR);
> >>> +
> >>> +}
> >>> +#endif /* CONFIG_SUSPEND || CONFIG_CPU_IDLE */
> >>> +
> >>> +#ifdef CONFIG_CPU_IDLE
> >>> +static int r8a7740_enter_a3sm_pll_on(struct cpuidle_device *dev,
> >>> +                                     struct cpuidle_driver *drv, int index)
> >>> +{
> >>> +     r8a7740_enter_a3sm_common(1);
> >>> +     return 1;
> >>> +}
> >>> +
> >>> +static int r8a7740_enter_a3sm_pll_off(struct cpuidle_device *dev,
> >>> +                                     struct cpuidle_driver *drv, int index)
> >>> +{
> >>> +     r8a7740_enter_a3sm_common(0);
> >>> +     return 2;
> >>> +}
> >>> +
> >>> +static struct cpuidle_driver r8a7740_cpuidle_driver = {
> >>> +     .name                   = "r8a7740_cpuidle",
> >>> +     .owner                  = THIS_MODULE,
> >>> +     .en_core_tk_irqen       = 1,
> >>> +     .state_count            = 3,
> >>> +     .safe_state_index       = 0, /* C1 */
> >>> +     .states[0] = ARM_CPUIDLE_WFI_STATE,
> >>> +     .states[0].enter = shmobile_enter_wfi,
> >>
> >> The WFI macro already set a simple enter function doing cpu_do_idle.
> > 
> > Oh yes, I'll remove it.
> > 
> >> We are trying to consolidate the cpuidle drivers across the different
> >> platforms [1]. One of the objective is to move the cpuidle drivers to
> >> drivers/cpuidle, a place where they belong to.
> >>
> >> Do you think it is possible you split your code to have one part with
> >> the cpuidle driver and another part with the PM code ?
> > 
> > Hmm. The CPUIdle part is enclosed in the #ifdef CONFIG_CPU_IDLE part anyway.
> > The other part (CONFIG_SUSPEND | CONFIG_CPU_IDLE) contains the part
> > that actually does drive down the hardware and is needed as soon as
> > SUSPEND or CPUIdle is used.
> > 
> > So is it split well enough already or does it help if I split my patch
> > into 2, first adding suspend and then CPUIdle to the same file? But
> > the outcome will be the same I think.
> 
> 
> Well, if you can convert the pm functions into ops used in the cpuidle
> driver and then create a file eg. cpuidle-r8a7740.c with the cpuidle
> code calling the ops that will separate clearly the cpuidle code from
> the pm code and make easier to move the cpuidle driver to the
> drivers/cpuidle directory. Also, I think that will help to consolidate
> the other shmobile cpuidle drivers, maybe into a single one.

I wonder if that is an appropriate pre-requisite for adding
r8a7940 cpuidle support. My preference, which may well be compatible
with your comments, is to bring support for that SoC up to the same level
as support for other shmobile SoCs and to treat consolidation as a
an area of work that is undertaken in parallel.


From jason at lakedaemon.net  Thu Apr 11 20:28:11 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Thu, 11 Apr 2013 20:28:11 -0400
Subject: [PATCHv8 12/19] arm: mvebu: add PCIe Device Tree informations
 for Armada 370
In-Reply-To: <1365541601-14095-13-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1365541601-14095-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1365541601-14095-13-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <20130412002811.GS28693@titan.lakedaemon.net>

On Tue, Apr 09, 2013 at 11:06:33PM +0200, Thomas Petazzoni wrote:
> The Armada 370 SoC has two 1x PCIe 2.0 interfaces, so we add the
> necessary Device Tree informations to make these interfaces availabel.
> 
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> ---
>  arch/arm/boot/dts/armada-370.dtsi |   51 +++++++++++++++++++++++++++++++++++++
>  1 file changed, 51 insertions(+)

Patches 12 through 18 applied to mvebu/dt.  Now Gregory can rebase LPAE
:)

thx,

Jason.


From horms at verge.net.au  Thu Apr 11 20:34:57 2013
From: horms at verge.net.au (Simon Horman)
Date: Fri, 12 Apr 2013 09:34:57 +0900
Subject: [PATCH v3 0/9] Reorganize R8A7779/Marzen USB code
In-Reply-To: <5166A659.6060405@cogentembedded.com>
References: <201304100226.08967.sergei.shtylyov@cogentembedded.com>
 <20130410044923.GD10044@verge.net.au>
 <20130410085033.GL7983@arwen.pp.htv.fi>
 <20130410090543.GB25890@verge.net.au>
 <20130411005155.GA18530@verge.net.au>
 <5166A659.6060405@cogentembedded.com>
Message-ID: <20130412003457.GC24461@verge.net.au>

On Thu, Apr 11, 2013 at 04:02:33PM +0400, Sergei Shtylyov wrote:
> Hello.
> 
> On 11-04-2013 4:51, Simon Horman wrote:
> 
> >>>>>    Here's the set of 9 patches against the Simon Horman's 'renesas.git' repo,
> >>>>>'renesas-next-20130410' tag.  It was created to fix the shortcomings in the
> >>>>>R8A7779/Marzen USB platform code and R8A7779 USB common PHY driver, and so
> >>>>>spans both arch/arm/mach-shmobile/ and drivers/usb/ subtrees (some patches have
> >>>>>to touch both subtrees). The patches were conceived with the complete
> >>>>>bisectability goal in mind.
> 
> >>>>>[1/9] ARM: shmobile: Marzen: move USB EHCI, OHCI, and PHY devices to R8A7779 code
> >>>>>[2/9] ehci-platform: add pre_setup() method to platform data
> >>>>>[3/9] ARM: shmobile: R8A7779: setup EHCI internal buffer
> >>>>>[4/9] rcar-phy: remove EHCI internal buffer setup
> >>>>>[5/9] ARM: shmobile: R8A7779: remove USB PHY 2nd memory resource
> >>>>>[6/9] rcar-phy: correct base address
> >>>>>[7/9] rcar-phy: add platform data
> >>>>>[8/9] ARM: shmobile: Marzen: pass platform data to USB PHY device
> >>>>>[9/9] rcar-phy: handle platform data
> 
> >>>>>    I'm not sure thru which tree this patchset should be merged, however it turns
> >>>>>out that it's too late now to push it thru Felipe Balbi's USB tree for 3.10
> >>>>>(which would have been most convenient probably), and it's probably too late to
> >>>>>merge thru Simon's tree for 3.10 too. So it now have to be postponed to 3.11,
> >>>>>unfortunately...
> 
> >>>>Felipe, how would you prefer to handle this?
> >>>>I'm happy for you to take it or to take it myself.
> 
> >>>please take it yourself, just keep in mind there will be conflicts, I
> >>>will go over the patches now and give my Acked-by so you can queue them
> >>>up.
> 
> >>Thanks
> 
> >Sergei, it looks like patches 1-7 are clear.
> 
>    #7 & #9 have been refused by Felipe (hence #8 isn't good too).
> 
> >Do you want me to start queueing them up.
> 
>    I was going to repost the whole series soon, adding ACK from Alan
> to the patch #2 and resolving issues with patches #7..#9. It's worth
> waiting for that to happen I think.

I am quite happy to wait.

One minor comment - there is no need to repost just to fix this -
could you consider using lower-case for the socs for consistency
with the common practice in patch subject lines.

e.g.: ARM: shmobile: r8a7779: setup EHCI

> >Or would you rather wait for the issue with patch 6 to be resolved?
> 
>    There's no special issue with patch #6 other than the PHY driver
> files being renamed in Felipe's tree -- but that concerns all
> patches touching drivers/usb/phy/rcar-phy.c (some of which precede
> #6).

Sorry, I made an error. I meant #8 and in turn #9.

>    I don't know how the rename conflict will be handled (this is
> really bad coincidence), perhaps I still should have done this
> patchset against Felipe's 'next' branch and pushed it thru his tree.
> If the patches will be queued for 3.11 anyway, maybe it's worth
> doing that -- I'm still of the opinion that his tree would be the
> one most fitting for this patchset.

It seems that git will handle it :)


From horms at verge.net.au  Thu Apr 11 20:44:25 2013
From: horms at verge.net.au (Simon Horman)
Date: Fri, 12 Apr 2013 09:44:25 +0900
Subject: [V2 patch 01/19] ARM: shmobile: cpuidle: remove
 shmobile_enter_wfi function
In-Reply-To: <1365712969-7541-2-git-send-email-daniel.lezcano@linaro.org>
References: <1365712969-7541-1-git-send-email-daniel.lezcano@linaro.org>
 <1365712969-7541-2-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <20130412004425.GD24461@verge.net.au>

On Thu, Apr 11, 2013 at 10:42:31PM +0200, Daniel Lezcano wrote:
> Remove the shmobile_enter_wfi function which is the same as the
> common WFI enter function from the arm cpuidle driver defined
> with the ARM_CPUIDLE_WFI_STATE macro.

Should this patch also make shmobile_enter_wfi static in
arch/arm/mach-shmobile/cpuidle.c ?

Also, I have a slight preference for the patch to be split into two.
1. A patch to remove usage of shmobile_enter_wfi from the sh7372 SoC.
2. A patch to remove shmobile_enter_wfi. from common.h
   (and make it static?).

> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
> ---
>  arch/arm/mach-shmobile/include/mach/common.h |    3 ---
>  arch/arm/mach-shmobile/pm-sh7372.c           |    1 -
>  2 files changed, 4 deletions(-)
> 
> diff --git a/arch/arm/mach-shmobile/include/mach/common.h b/arch/arm/mach-shmobile/include/mach/common.h
> index e48606d..362f9b2 100644
> --- a/arch/arm/mach-shmobile/include/mach/common.h
> +++ b/arch/arm/mach-shmobile/include/mach/common.h
> @@ -13,9 +13,6 @@ extern int shmobile_clk_init(void);
>  extern void shmobile_handle_irq_intc(struct pt_regs *);
>  extern struct platform_suspend_ops shmobile_suspend_ops;
>  struct cpuidle_driver;
> -struct cpuidle_device;
> -extern int shmobile_enter_wfi(struct cpuidle_device *dev,
> -			      struct cpuidle_driver *drv, int index);
>  extern void shmobile_cpuidle_set_driver(struct cpuidle_driver *drv);
>  
>  extern void sh7372_init_irq(void);
> diff --git a/arch/arm/mach-shmobile/pm-sh7372.c b/arch/arm/mach-shmobile/pm-sh7372.c
> index f6b14ca..fbef7b9 100644
> --- a/arch/arm/mach-shmobile/pm-sh7372.c
> +++ b/arch/arm/mach-shmobile/pm-sh7372.c
> @@ -414,7 +414,6 @@ static struct cpuidle_driver sh7372_cpuidle_driver = {
>  	.state_count		= 5,
>  	.safe_state_index	= 0, /* C1 */
>  	.states[0] = ARM_CPUIDLE_WFI_STATE,
> -	.states[0].enter = shmobile_enter_wfi,
>  	.states[1] = {
>  		.name = "C2",
>  		.desc = "Core Standby Mode",
> -- 
> 1.7.9.5
> 


From jason at lakedaemon.net  Thu Apr 11 20:48:21 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Thu, 11 Apr 2013 20:48:21 -0400
Subject: [PATCHv8 12/19] arm: mvebu: add PCIe Device Tree informations
 for Armada 370
In-Reply-To: <20130412002811.GS28693@titan.lakedaemon.net>
References: <1365541601-14095-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1365541601-14095-13-git-send-email-thomas.petazzoni@free-electrons.com>
 <20130412002811.GS28693@titan.lakedaemon.net>
Message-ID: <20130412004821.GT28693@titan.lakedaemon.net>

On Thu, Apr 11, 2013 at 08:28:11PM -0400, Jason Cooper wrote:
> On Tue, Apr 09, 2013 at 11:06:33PM +0200, Thomas Petazzoni wrote:
> > The Armada 370 SoC has two 1x PCIe 2.0 interfaces, so we add the
> > necessary Device Tree informations to make these interfaces availabel.
> > 
> > Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> > ---
> >  arch/arm/boot/dts/armada-370.dtsi |   51 +++++++++++++++++++++++++++++++++++++
> >  1 file changed, 51 insertions(+)
> 
> Patches 12 through 18 applied to mvebu/dt.  Now Gregory can rebase LPAE
> :)

Gregory,

Hold off for an hour or so.  I just realized that mvebu/fixes contains a
few more relevant dts changes than I had pulled in to mvebu/dt.  I'll
let you know once I push an updated branch.

thx,

Jason.


From festevam at gmail.com  Thu Apr 11 20:48:45 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Thu, 11 Apr 2013 21:48:45 -0300
Subject: [PATCH 1/2] ARM: imx_v6_v7_defconfig: add CONFIG_USB_PHY
In-Reply-To: <20130402141909.GH24039@S2101-09.ap.freescale.net>
References: <1364133966-22373-1-git-send-email-shawn.guo@linaro.org>
 <20130402080706.GC30286@arwen.pp.htv.fi>
 <20130402111245.GC24039@S2101-09.ap.freescale.net>
 <20130402124407.GE9488@arwen.pp.htv.fi>
 <20130402141909.GH24039@S2101-09.ap.freescale.net>
Message-ID: <CAOMZO5DqH3v4CaPaxgheLKUk6Nc_MtQQnx1Yh1sE07a20X==oA@mail.gmail.com>

Hi Felipe,

On Tue, Apr 2, 2013 at 11:19 AM, Shawn Guo <shawn.guo at linaro.org> wrote:
> On Tue, Apr 02, 2013 at 03:44:07PM +0300, Felipe Balbi wrote:
>> alright, in that case can you rebase on next branch ? patch 2 didn't
>> apply.
>
> Have you tried "git am -3"?

Please let us know if you still face issues applying this one.

Booting a linux-next kernel without this fix is hanging the system.

Thanks,

Fabio Estevam


From horms at verge.net.au  Thu Apr 11 20:56:35 2013
From: horms at verge.net.au (Simon Horman)
Date: Fri, 12 Apr 2013 09:56:35 +0900
Subject: [PATCH v2 1/2] ARM: shmobile: r8a7740: Add Suspend-To-RAM A3SM
In-Reply-To: <1365689264-14410-1-git-send-email-hechtb+renesas@gmail.com>
References: <1365689264-14410-1-git-send-email-hechtb+renesas@gmail.com>
Message-ID: <20130412005635.GG24461@verge.net.au>

On Thu, Apr 11, 2013 at 04:07:43PM +0200, Bastian Hecht wrote:
> We add 2 Suspend to RAM modes:
> - A3SM PLL0 on/off:     Power domain A3SM that contains the ARM core
>                         and the 2nd level cache with either PLL0 on
>                         or off
> 
> As the suspend to memory mechanism we use A3SM PLL off. A3SM PLL on
> is included here too, so CPUIdle can use both power down modes (not
> included in this patch).
> 
> The setup of the SYSC regarding the external IRQs is taken from
> pm-sh7372.c from Magnus Damm.
> 
> Signed-off-by: Bastian Hecht <hechtb+renesas at gmail.com>
> ---
> This patch relies on
> ARM: hw_breakpoint: Do not use __cpuinitdata for dbg_cpu_pm_nb
> 
> v2: successor to [PATCH] ARM: shmobile: r8a7740: Add Suspend-To-RAM modes and CPUIdle
> 
> - Removed the 2nd L1 flush in the asm shutdown code. See comment in code for explanation.
> - Reworked the ifdefs: We can only use CPUIdle if SUSPEND is set as well.
> - Removed cpu_do_idle() in r8a7740_enter_suspend: We don't want to sleep twice...
> 
> If you want to test this use this workaround in the st1232 driver in
> drivers/input/touchscreen/st1232.c:
> 
>         error = request_threaded_irq(client->irq, NULL, st1232_ts_irq_handler,
> -                                    IRQF_ONESHOT, client->name, ts);
> +                                    IRQF_NO_SUSPEND | IRQF_ONESHOT, client->name, ts);
> 
> You need it as the current irqpin driver doesn't handle wakeup devices properly yet.
> 
> Tested with the 4 possiblities 	L2 on - Suspend on/off - CPUIdle on/off
> and with the additional test	L2 off - Suspend on - CPUIdle on

Hi Bastian,

are the pre-requisites listed above likely to be in v3.11-rc1 or rc2?

>  arch/arm/mach-shmobile/Makefile               |    2 +-
>  arch/arm/mach-shmobile/include/mach/r8a7740.h |    3 +
>  arch/arm/mach-shmobile/pm-r8a7740.c           |  167 ++++++++++++++++++++++++-
>  arch/arm/mach-shmobile/sleep-r8a7740.S        |   72 +++++++++++
>  4 files changed, 240 insertions(+), 4 deletions(-)
>  create mode 100644 arch/arm/mach-shmobile/sleep-r8a7740.S
> 
> diff --git a/arch/arm/mach-shmobile/Makefile b/arch/arm/mach-shmobile/Makefile
> index 068f1da..0568894 100644
> --- a/arch/arm/mach-shmobile/Makefile
> +++ b/arch/arm/mach-shmobile/Makefile
> @@ -30,7 +30,7 @@ obj-$(CONFIG_SUSPEND)		+= suspend.o
>  obj-$(CONFIG_CPU_IDLE)		+= cpuidle.o
>  obj-$(CONFIG_ARCH_SHMOBILE)	+= pm-rmobile.o
>  obj-$(CONFIG_ARCH_SH7372)	+= pm-sh7372.o sleep-sh7372.o
> -obj-$(CONFIG_ARCH_R8A7740)	+= pm-r8a7740.o
> +obj-$(CONFIG_ARCH_R8A7740)	+= pm-r8a7740.o sleep-r8a7740.o
>  obj-$(CONFIG_ARCH_R8A7779)	+= pm-r8a7779.o
>  obj-$(CONFIG_ARCH_SH73A0)	+= pm-sh73a0.o
>  
> diff --git a/arch/arm/mach-shmobile/include/mach/r8a7740.h b/arch/arm/mach-shmobile/include/mach/r8a7740.h
> index abdc4d4..05551ee 100644
> --- a/arch/arm/mach-shmobile/include/mach/r8a7740.h
> +++ b/arch/arm/mach-shmobile/include/mach/r8a7740.h
> @@ -540,6 +540,9 @@ extern void r8a7740_add_standard_devices(void);
>  extern void r8a7740_clock_init(u8 md_ck);
>  extern void r8a7740_pinmux_init(void);
>  extern void r8a7740_pm_init(void);
> +extern void r8a7740_resume(void);
> +extern void r8a7740_shutdown(void);
> +extern void r8a7740_enter_a3sm_common(int);
>  
>  #ifdef CONFIG_PM
>  extern void __init r8a7740_init_pm_domains(void);
> diff --git a/arch/arm/mach-shmobile/pm-r8a7740.c b/arch/arm/mach-shmobile/pm-r8a7740.c
> index 40b87aa..adadac4 100644
> --- a/arch/arm/mach-shmobile/pm-r8a7740.c
> +++ b/arch/arm/mach-shmobile/pm-r8a7740.c
> @@ -8,10 +8,52 @@
>   * License.  See the file "COPYING" in the main directory of this archive
>   * for more details.
>   */
> +#include <linux/bitrev.h>
>  #include <linux/console.h>
> +#include <linux/module.h>
>  #include <linux/suspend.h>
> +#include <linux/io.h>
> +#include <asm/suspend.h>
> +#include <asm/cacheflush.h>
> +#include <asm/hardware/cache-l2x0.h>
>  #include <mach/pm-rmobile.h>
>  #include <mach/common.h>
> +#include <mach/r8a7740.h>
> +
> +/* CPGA */
> +#define PLLC01STPCR 	IOMEM(0xe61500c8)
> +#define SYSTBCR		IOMEM(0xe6150024)
> +
> +/* SYSC */
> +#define STBCHR		IOMEM(0xe6180000)
> +#define STBCHRB		IOMEM(0xe6180040)
> +#define SPDCR		IOMEM(0xe6180008)
> +#define SBAR		IOMEM(0xe6180020)
> +#define SRSTFR		IOMEM(0xe61800B4)
> +#define WUPSMSK		IOMEM(0xe618002c)
> +#define WUPSMSK2	IOMEM(0xe6180048)
> +#define WUPSFAC		IOMEM(0xe6180098)
> +#define IRQCR 		IOMEM(0xe618022c)
> +#define IRQCR2 		IOMEM(0xe6180238)
> +#define IRQCR3		IOMEM(0xe6180244)
> +#define IRQCR4		IOMEM(0xe6180248)
> +
> +/* SRSTFR flags */
> +#define RAMST		(1 << 19)
> +#define RCLNKA		(1 << 7)
> +#define RCPRES		(1 << 5)
> +#define RCWD1		(1 << 4)
> +#define RPF		(1 << 0)
> +
> +/* INTC */
> +#define ICR1A		IOMEM(0xe6900000)
> +#define ICR2A		IOMEM(0xe6900004)
> +#define ICR3A		IOMEM(0xe6900008)
> +#define ICR4A		IOMEM(0xe690000c)
> +#define INTMSK00A	IOMEM(0xe6900040)
> +#define INTMSK10A	IOMEM(0xe6900044)
> +#define INTMSK20A	IOMEM(0xe6900048)
> +#define INTMSK30A	IOMEM(0xe690004c)
>  
>  #ifdef CONFIG_PM
>  static int r8a7740_pd_a4s_suspend(void)
> @@ -58,13 +100,132 @@ void __init r8a7740_init_pm_domains(void)
>  	rmobile_init_domains(r8a7740_pm_domains, ARRAY_SIZE(r8a7740_pm_domains));
>  	pm_genpd_add_subdomain_names("A4S", "A3SP");
>  }
> -
>  #endif /* CONFIG_PM */
>  
>  #ifdef CONFIG_SUSPEND
> +static void r8a7740_set_reset_vector(unsigned long address)
> +{
> +	__raw_writel(address, SBAR);
> +}
> +
> +static void r8a7740_icr_to_irqcr(unsigned long icr, u16 *irqcr1p, u16 *irqcr2p)
> +{
> +	u16 tmp, irqcr1, irqcr2;
> +	int k;
> +
> +	irqcr1 = 0;
> +	irqcr2 = 0;
> +
> +	/* convert INTCA ICR register layout to SYSC IRQCR+IRQCR2 */
> +	for (k = 0; k <= 7; k++) {
> +		tmp = (icr >> ((7 - k) * 4)) & 0xf;
> +		irqcr1 |= (tmp & 0x03) << (k * 2);
> +		irqcr2 |= (tmp >> 2) << (k * 2);
> +	}
> +
> +	*irqcr1p = irqcr1;
> +	*irqcr2p = irqcr2;
> +}
> +
> +static void r8a7740_setup_sysc(unsigned long msk, unsigned long msk2)
> +{
> +	u16 irqcrx_low, irqcrx_high, irqcry_low, irqcry_high;
> +	unsigned long tmp;
> +
> +	/* read IRQ0A -> IRQ15A mask */
> +	tmp = bitrev8(__raw_readb(INTMSK00A));
> +	tmp |= bitrev8(__raw_readb(INTMSK10A)) << 8;
> +
> +	/* setup WUPSMSK from clocks and external IRQ mask */
> +	msk = (~msk & 0xc030000f) | (tmp << 4);
> +	__raw_writel(msk, WUPSMSK);
> +
> +	/* propage level/edge trigger for external IRQ 0->15 */
> +	r8a7740_icr_to_irqcr(__raw_readl(ICR1A), &irqcrx_low, &irqcry_low);
> +	r8a7740_icr_to_irqcr(__raw_readl(ICR2A), &irqcrx_high, &irqcry_high);
> +	__raw_writel((irqcrx_high << 16) | irqcrx_low, IRQCR);
> +	__raw_writel((irqcry_high << 16) | irqcry_low, IRQCR2);
> +
> +	/* read IRQ16A -> IRQ31A mask */
> +	tmp = bitrev8(__raw_readb(INTMSK20A));
> +	tmp |= bitrev8(__raw_readb(INTMSK30A)) << 8;
> +
> +	/* setup WUPSMSK2 from clocks and external IRQ mask */
> +	msk2 = (~msk2 & 0x00030000) | tmp;
> +	__raw_writel(msk2, WUPSMSK2);
> +
> +	/* propage level/edge trigger for external IRQ 16->31 */
> +	r8a7740_icr_to_irqcr(__raw_readl(ICR3A), &irqcrx_low, &irqcry_low);
> +	r8a7740_icr_to_irqcr(__raw_readl(ICR4A), &irqcrx_high, &irqcry_high);
> +	__raw_writel((irqcrx_high << 16) | irqcrx_low, IRQCR3);
> +	__raw_writel((irqcry_high << 16) | irqcry_low, IRQCR4);
> +}
> +
> +static void r8a7740_prepare_wakeup(void)
> +{
> +	/* clear all flags that lead to a cold boot */
> +	__raw_writel(~(RAMST | RCLNKA | RCPRES | RCWD1 | RPF), SRSTFR);
> +	/* indicate warm boot */
> +	__raw_writel(0x80000000, STBCHRB);
> +	/* clear other flags checked by internal ROM boot loader */
> +	__raw_writel(0x00000000, STBCHR);
> +}
> +
> +static int r8a7740_do_suspend(unsigned long unused)
> +{
> +	/*
> +	 * cpu_suspend() guarantees that all data made it to the L2.
> +	 * Flush it out now and disable the cache controller.
> +	 */
> +	outer_flush_all();
> +	outer_disable();
> +
> +	r8a7740_shutdown();
> +
> +	/* in case WFI fails to enter the low power state, restore things */
> +	outer_resume();
> +
> +	return 0;
> +}
> +
> +void r8a7740_enter_a3sm_common(int pllc0_on)
> +{
> +	u32 reg32;
> +
> +	if (pllc0_on)
> +		__raw_writel(0, PLLC01STPCR);
> +	else
> +		__raw_writel(1 << 28, PLLC01STPCR);
> +
> +	r8a7740_set_reset_vector(__pa(r8a7740_resume));
> +	r8a7740_prepare_wakeup();
> +	r8a7740_setup_sysc(1 << 0, 0);
> +
> +	/* Activate delayed shutdown of A3SM */
> +	reg32 = __raw_readl(SPDCR);
> +	reg32 |= (1 << 31) | (1 << 12);
> +	__raw_writel(reg32, SPDCR);
> +
> +	/* We activate CPU Core Standby as well here */
> +	reg32 = __raw_readl(SYSTBCR);
> +	reg32 |= (1 << 4);
> +	__raw_writel(reg32, SYSTBCR);
> +
> +	/* Clear Wakeup Factors and do suspend */
> +	reg32 = __raw_readl(WUPSFAC);
> +	cpu_suspend(0, r8a7740_do_suspend);
> +	outer_resume();
> +	reg32 = __raw_readl(WUPSFAC);
> +
> +	/* Clear CPU Core Standby flag for other WFI instructions */
> +	reg32 &= ~(1 << 4);
> +	__raw_writel(reg32, SYSTBCR);
> +
> +}
> +
>  static int r8a7740_enter_suspend(suspend_state_t suspend_state)
>  {
> -	cpu_do_idle();
> +	r8a7740_enter_a3sm_common(0);
>  	return 0;
>  }
>  
> @@ -74,7 +235,7 @@ static void r8a7740_suspend_init(void)
>  }
>  #else
>  static void r8a7740_suspend_init(void) {}
> -#endif
> +#endif /* CONFIG_SUSPEND */
>  
>  void __init r8a7740_pm_init(void)
>  {
> diff --git a/arch/arm/mach-shmobile/sleep-r8a7740.S b/arch/arm/mach-shmobile/sleep-r8a7740.S
> new file mode 100644
> index 0000000..762f978
> --- /dev/null
> +++ b/arch/arm/mach-shmobile/sleep-r8a7740.S
> @@ -0,0 +1,72 @@
> +/*
> + * Low level sleep code for the SoC r8a7740
> + *
> + * Copyright (C) 2013 Bastian Hecht
> + *
> + * This file is subject to the terms and conditions of the GNU General Public
> + * License.  See the file "COPYING" in the main directory of this archive
> + * for more details.
> + */
> +
> +#include <linux/linkage.h>
> +#include <linux/init.h>
> +#include <asm/memory.h>
> +
> +#ifdef CONFIG_SUSPEND
> +
> +/* r8a7740_shutdown expects L2 to be flushed */
> +	.text
> +ENTRY(r8a7740_shutdown)
> +	stmfd   sp!, {r4-r12, lr}
> +
> +	/* make sure the stack stays intact */
> +	bl      v7_flush_dcache_all
> +
> +	/*
> +	 * Clear the SCTLR.C bit to prevent further data cache
> +	 * allocation. Clearing SCTLR.C would make all the data accesses
> +	 * strongly ordered and would not hit the cache.
> +	 */
> +	mrc	p15, 0, r0, c1, c0, 0
> +	bic	r0, r0, #(1 << 2)		@ Disable the C bit
> +	mcr	p15, 0, r0, c1, c0, 0
> +	isb
> +
> +	/*
> +	 * We don't issue another v7_flush_dcache_all here as seen in many
> +	 * other places as we have a UP core and the L1 could not soak up
> +	 * data from other L1 caches in the meantime.
> +	 */
> +
> +	bl	cpu_v7_do_idle
> +
> +	/* in rare cases when WFI fails we end up here and restore things */
> +	mrc	p15, 0, r0, c1, c0, 0
> +	orr	r0, r0, #(1 << 2)		@ Enable the C bit
> +	mcr	p15, 0, r0, c1, c0, 0
> +	isb
> +
> +	ldmfd   sp!, {r4-r12, pc}
> +ENDPROC(r8a7740)
> +
> +	.text
> +ENTRY(v7_cpu_resume)
> +	bl	v7_invalidate_l1
> +	b	cpu_resume
> +ENDPROC(v7_cpu_resume)
> +
> +/*
> + * The entry point of a warm reboot, used by wakeup scenarios
> + *
> + * The CPU jumps in this case to (0xfffff000 & SBAR), so we need
> + * to align this function properly.
> + * We use a long jump into the text segment and use the physical
> + * address as the MMU is still turned off.
> + */
> +	.align	12
> +	.text
> +ENTRY(r8a7740_resume)
> +	ldr	pc, 1f
> +1:	.long	v7_cpu_resume - PAGE_OFFSET + PLAT_PHYS_OFFSET
> +ENDPROC(r8a7740_resume_core_standby)
> +#endif
> -- 
> 1.7.9.5
> 


From tangchen at cn.fujitsu.com  Thu Apr 11 21:13:05 2013
From: tangchen at cn.fujitsu.com (Tang Chen)
Date: Fri, 12 Apr 2013 09:13:05 +0800
Subject: [PATCH 0/2] mm: vmemmap: add vmemmap_verify check for hot-add
 node/memory case
In-Reply-To: <CAE9FiQU-zqFdSz-7yq5EgV1YCzyNH_BY36Ym3tdHVEHHY6cdNg@mail.gmail.com>
References: <1365415000-10389-1-git-send-email-linfeng@cn.fujitsu.com>
 <CAE9FiQVaByGOTjLVthRkEze_ekXm5LAKgKdHzrD+q1iYmjgZFQ@mail.gmail.com>
 <51666930.6090702@cn.fujitsu.com>
 <CAE9FiQU-zqFdSz-7yq5EgV1YCzyNH_BY36Ym3tdHVEHHY6cdNg@mail.gmail.com>
Message-ID: <51675FA1.9000203@cn.fujitsu.com>

On 04/11/2013 11:10 PM, Yinghai Lu wrote:
> On Thu, Apr 11, 2013 at 12:41 AM, Tang Chen<tangchen at cn.fujitsu.com>  wrote:
>>
>> 3. If we add flag to memblock, we can mark different memory. And I remember
>>     you mentioned before that we can use memblock to reserve local node data
>>     for node-life-cycle data, like vmemmap, pagetable.
>>
>>     So are you doing the similar work now ?
>
> No, i did not start it yet.
>
>>
>>     If not, I think I can merge it into mine, and push a new patch-set with
>>     hot-add, hot-remove code modified to support putting vmemmap, pagetable,
>>     pgdat, page_cgroup, ..., on local node.
>
> Need to have it separated with moving_zone.
>
> 1. rework memblock to keep alive all the way for hotplug usage.
> 2. put pagetable and vmemap on the local node range with help of memblock.
>

OK?thanks for the comments. I'll merge it into my work and post an RFC 
patch-set soon.

Thanks. :)


From horms at verge.net.au  Thu Apr 11 21:23:50 2013
From: horms at verge.net.au (Simon Horman)
Date: Fri, 12 Apr 2013 10:23:50 +0900
Subject: [PATCH v4 7/7] ARM: mach-shmobile: r8a7740: Setup the timer
 CMT10 using DT
In-Reply-To: <1365679443-25456-7-git-send-email-hechtb+renesas@gmail.com>
References: <1365679443-25456-1-git-send-email-hechtb+renesas@gmail.com>
 <1365679443-25456-7-git-send-email-hechtb+renesas@gmail.com>
Message-ID: <20130412012350.GA25941@verge.net.au>

On Thu, Apr 11, 2013 at 01:24:03PM +0200, Bastian Hecht wrote:
> We can now use the Device Tree for bringing up our timer device CMT10 on
> the SoC r8a7740.

Hi Bastian,

unfortunately with this patch the armaillo800eva no longer boots.

I am testing  against renesas-next-20130411v2 with the other
6 patches in this series applied. I am using the armadillo800eva defconfig.
The boot log is below.

I have also tested kzm9g an kzm9g-reference, they seem fine.


hermit> tftpboot 10.3.5.147 10.3.5.146 --kernel=armadillo/zImage
initializing net-device...OK

Client: 10.3.5.147
Server: 10.3.5.146
Region(kernel): armadillo/zImage

Filename : armadillo/zImage
......................................................................................................................................................................................................................................................................................................................................................................................................................................................
Filesize : 2240001

Copying kernel:net.........done.
Doing console=tty0
Doing console=ttySC1,115200
Doing earlyprintk=sh-sci.1,115200
Doing ignore_loglevel
Doing root=/dev/nfs
Doing ip=dhcp
Doing nfsroot=,rsize=4096,wsize=4096
Doing rw
Booting Linux on physical CPU 0x0
Linux version 3.9.0-rc2-00007-g92bd9f5 (horms at ayumi.isobedori.kobe.vergenet.net) (gcc version 4.4.5 (Debian 4.4.5-8) ) #1698 Fri Apr 12 10:21:28 JST 2013
CPU: ARMv7 Processor [412fc093] revision 3 (ARMv7), cr=10c53c7d
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
Machine: armadillo800eva, model: armadillo 800 eva
debug: ignoring loglevel setting.
Memory policy: ECC disabled, Data cache writeback
On node 0 totalpages: 131072
free_area_init_node: node 0, pgdat c0459e1c, node_mem_map c067e000
  Normal zone: 1024 pages used for memmap
  Normal zone: 0 pages reserved
  Normal zone: 131072 pages, LIFO batch:31
CPU: All CPU(s) started in SVC mode.
bootconsole [early_ttySC1] enabled
pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
pcpu-alloc: [0] 0 
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 130048
Kernel command line: console=tty0 console=ttySC1,115200 earlyprintk=sh-sci.1,115200 ignore_loglevel root=/dev/nfs ip=dhcp nfsroot=,rsize=4096,wsize=4096 rw
PID hash table entries: 2048 (order: 1, 8192 bytes)
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
__ex_table already sorted, skipping sort
Memory: 512MB = 512MB total
Memory: 515124k/515124k available, 9164k reserved, 0K highmem
Virtual kernel memory layout:
    vector  : 0xffff0000 - 0xffff1000   (   4 kB)
    fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
    vmalloc : 0xe0800000 - 0xff000000   ( 488 MB)
    lowmem  : 0xc0000000 - 0xe0000000   ( 512 MB)
    modules : 0xbf000000 - 0xc0000000   (  16 MB)
      .text : 0xc0008000 - 0xc040702c   (4093 kB)
      .init : 0xc0408000 - 0xc042b468   ( 142 kB)
      .data : 0xc042c000 - 0xc045a600   ( 186 kB)
       .bss : 0xc045a600 - 0xc0482624   ( 161 kB)
NR_IRQS:16 nr_irqs:16 16
GIC CPU mask not found - kernel will fail to boot.
GIC CPU mask not found - kernel will fail to boot.
sched_clock: 32 bits at 128 Hz, resolution 7812500ns, wraps every 3489660920ms
Console: colour dummy device 80x30
console [tty0] enabled
Calibrating delay loop... 


From haojian.zhuang at gmail.com  Thu Apr 11 21:33:15 2013
From: haojian.zhuang at gmail.com (Haojian Zhuang)
Date: Fri, 12 Apr 2013 09:33:15 +0800
Subject: [GIT PULL] Timer clean-ups for 3.10, Part 2
In-Reply-To: <201304112257.07645.arnd@arndb.de>
References: <516720B4.3000703@gmail.com>
	<201304112257.07645.arnd@arndb.de>
Message-ID: <CAN1soZxJpK1amFaqYuqtMhF3Oeq9rxVgN1aWidaJe49tVTWRgg@mail.gmail.com>

On Fri, Apr 12, 2013 at 4:57 AM, Arnd Bergmann <arnd at arndb.de> wrote:
> On Thursday 11 April 2013, Rob Herring wrote:
>> Olof, Arnd,
>>
>> Please pull timer clean-ups for arch timer, sp804, and integrator-cp timers.
>>
>> I've dropped the final patch which moved the sp804 and integrator timers
>> code to drivers/clocksource until the desired structure is worked out.
>>
>> Simon, the fixes for shmobile were trivial. Please comment if you see
>> any issues.
>
> Ok, nice!
>
> There are various bits for which I'd like to see Russell's ACK before
> we send them Linuswards, but it all looks good to me.
>
> I would put it into arm-soc tomorrow, and hopefully Haojian Zhuang is
> able to send an updated version of his hisilicon platform code based
> on top of this in time for the merge window. The patches are all
> reviewed but just waiting for the sp804 changes now, and since
> it's a new platform, I'm not worried about regressions.
>
>         Arnd

I'll rebase code after it's merged into arm-soc git tree.

Regards
Haojian


From josephl at nvidia.com  Thu Apr 11 21:38:52 2013
From: josephl at nvidia.com (Joseph Lo)
Date: Fri, 12 Apr 2013 09:38:52 +0800
Subject: [PATCH] ARM: tegra: pm: fix build error w/o PM_SLEEP
Message-ID: <1365730733-22701-1-git-send-email-josephl@nvidia.com>

This fixes the building error when the PM_SLEEP is disabled. The fucntional
defintion of "tegra_pm_validate_suspend_mode" without "static inline"
would become a multiple definition error.

Reported-by: Rhyland Klein <rklein at nvidia.com>
Signed-off-by: Joseph Lo <josephl at nvidia.com>
---
 arch/arm/mach-tegra/pm.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-tegra/pm.h b/arch/arm/mach-tegra/pm.h
index 9d2d038..778a4aa 100644
--- a/arch/arm/mach-tegra/pm.h
+++ b/arch/arm/mach-tegra/pm.h
@@ -39,7 +39,7 @@ enum tegra_suspend_mode tegra_pm_validate_suspend_mode(
 				enum tegra_suspend_mode mode);
 void tegra_init_suspend(void);
 #else
-enum tegra_suspend_mode tegra_pm_validate_suspend_mode(
+static inline enum tegra_suspend_mode tegra_pm_validate_suspend_mode(
 				enum tegra_suspend_mode mode)
 {
 	return TEGRA_SUSPEND_NONE;
-- 
1.8.2



From shawn.guo at linaro.org  Thu Apr 11 22:02:04 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Fri, 12 Apr 2013 10:02:04 +0800
Subject: [PATCH] video: mxsfb: Adapt to new videomode API
In-Reply-To: <CAOMZO5BY0mpYC1sjkRsnX-jnj8X4u9ZH15GCQ=MqMYeQ-LAfuQ@mail.gmail.com>
References: <1365516978-29888-1-git-send-email-fabio.estevam@freescale.com>
 <5165228F.1020805@ti.com>
 <CAOMZO5BY0mpYC1sjkRsnX-jnj8X4u9ZH15GCQ=MqMYeQ-LAfuQ@mail.gmail.com>
Message-ID: <20130412020202.GC16970@S2101-09.ap.freescale.net>

On Wed, Apr 10, 2013 at 09:36:31AM -0300, Fabio Estevam wrote:
> On Wed, Apr 10, 2013 at 5:27 AM, Tomi Valkeinen <tomi.valkeinen at ti.com> wrote:
> 
> > The mxsfb.c driver in my tree does not contain such code. Where is this
> > patch meant to be applied?
> 
> linux-next 20130408 is broken for mxs without this fix. Maybe Shawn can take it?

I will take it and send it during -rc when Tomi's patches hit mainline.
But I have a couple trivial comments on the patch.  I'm replying to the
patch.

Shawn



From shawn.guo at linaro.org  Thu Apr 11 22:11:13 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Fri, 12 Apr 2013 10:11:13 +0800
Subject: [PATCH] video: mxsfb: Adapt to new videomode API
In-Reply-To: <1365516978-29888-1-git-send-email-fabio.estevam@freescale.com>
References: <1365516978-29888-1-git-send-email-fabio.estevam@freescale.com>
Message-ID: <20130412021111.GD16970@S2101-09.ap.freescale.net>

On Tue, Apr 09, 2013 at 11:16:18AM -0300, Fabio Estevam wrote:
> commit 6cd2c7db4 (videomode: videomode_from_timing work) changed the name of 
> the function from videomode_from_timing() to videomode_from_timings().
> 
> commit 32ed6ef1 (videomode: create enum for videomode's display flags) changed
> the 'data_flags' field in videomode structure to 'flags'
> 
> Adapt to these changes in order to fix the following errors:
> 
> drivers/video/mxsfb.c:761:3: error: too many arguments to function 'videomode_from_timing'
> drivers/video/mxsfb.c:761:7: error: void value not ignored as it ought to be
> drivers/video/mxsfb.c:768:9: error: 'struct videomode' has no member named 'data_flags'
> drivers/video/mxsfb.c:770:9: error: 'struct videomode' has no member named 'data_flags'
> 
> Also select VIDEOMODE_HELPER in Kconfig to avoid linker errors.
> 
> Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
> ---
>  drivers/video/Kconfig |    1 +
>  drivers/video/mxsfb.c |    7 ++++---
>  2 files changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> index d90e3f5..240f863 100644
> --- a/drivers/video/Kconfig
> +++ b/drivers/video/Kconfig
> @@ -2428,6 +2428,7 @@ config FB_MXS
>  	select FB_CFB_IMAGEBLIT
>  	select FB_MODE_HELPERS
>  	select OF_VIDEOMODE

OF_VIDEOMODE is dead now, and should be removed.

> +	select VIDEOMODE_HELPERS
>  	help
>  	  Framebuffer support for the MXS SoC.
>  
> diff --git a/drivers/video/mxsfb.c b/drivers/video/mxsfb.c
> index eac7c1a..fb559f3 100644
> --- a/drivers/video/mxsfb.c
> +++ b/drivers/video/mxsfb.c
> @@ -43,6 +43,7 @@
>  #include <linux/kernel.h>
>  #include <linux/of_device.h>
>  #include <linux/of_gpio.h>
> +#include <video/display_timing.h>
>  #include <video/of_display_timing.h>

I messed it up from the beginning.  All these <video/*> should be sorted
after <linux/*>.

Shawn

>  #include <linux/platform_device.h>
>  #include <linux/clk.h>
> @@ -758,16 +759,16 @@ static int mxsfb_init_fbinfo_dt(struct mxsfb_info *host)
>  		struct videomode vm;
>  		struct fb_videomode fb_vm;
>  
> -		ret = videomode_from_timing(timings, &vm, i);
> +		ret = videomode_from_timings(timings, &vm, i);
>  		if (ret < 0)
>  			goto put_timings_node;
>  		ret = fb_videomode_from_videomode(&vm, &fb_vm);
>  		if (ret < 0)
>  			goto put_timings_node;
>  
> -		if (vm.data_flags & DISPLAY_FLAGS_DE_HIGH)
> +		if (vm.flags & DISPLAY_FLAGS_DE_HIGH)
>  			host->sync |= MXSFB_SYNC_DATA_ENABLE_HIGH_ACT;
> -		if (vm.data_flags & DISPLAY_FLAGS_PIXDATA_NEGEDGE)
> +		if (vm.flags & DISPLAY_FLAGS_PIXDATA_NEGEDGE)
>  			host->sync |= MXSFB_SYNC_DOTCLK_FALLING_ACT;
>  		fb_add_videomode(&fb_vm, &fb_info->modelist);
>  	}
> -- 
> 1.7.9.5
> 
> 



From festevam at gmail.com  Thu Apr 11 22:24:19 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Thu, 11 Apr 2013 23:24:19 -0300
Subject: [PATCH] video: mxsfb: Adapt to new videomode API
In-Reply-To: <20130412021111.GD16970@S2101-09.ap.freescale.net>
References: <1365516978-29888-1-git-send-email-fabio.estevam@freescale.com>
 <20130412021111.GD16970@S2101-09.ap.freescale.net>
Message-ID: <CAOMZO5BrkRx6zYraea1Bnqppf0WAO8rztUyA0ewm9Qw0wFbo_A@mail.gmail.com>

On Thu, Apr 11, 2013 at 11:11 PM, Shawn Guo <shawn.guo at linaro.org> wrote:

>> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
>> index d90e3f5..240f863 100644
>> --- a/drivers/video/Kconfig
>> +++ b/drivers/video/Kconfig
>> @@ -2428,6 +2428,7 @@ config FB_MXS
>>       select FB_CFB_IMAGEBLIT
>>       select FB_MODE_HELPERS
>>       select OF_VIDEOMODE
>
> OF_VIDEOMODE is dead now, and should be removed.

Ok, but should I remove this on a separate patch?


From shawn.guo at linaro.org  Thu Apr 11 22:55:38 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Fri, 12 Apr 2013 10:55:38 +0800
Subject: [PATCH] video: mxsfb: Adapt to new videomode API
In-Reply-To: <CAOMZO5BrkRx6zYraea1Bnqppf0WAO8rztUyA0ewm9Qw0wFbo_A@mail.gmail.com>
References: <1365516978-29888-1-git-send-email-fabio.estevam@freescale.com>
 <20130412021111.GD16970@S2101-09.ap.freescale.net>
 <CAOMZO5BrkRx6zYraea1Bnqppf0WAO8rztUyA0ewm9Qw0wFbo_A@mail.gmail.com>
Message-ID: <20130412025536.GE16970@S2101-09.ap.freescale.net>

On Thu, Apr 11, 2013 at 11:24:19PM -0300, Fabio Estevam wrote:
> On Thu, Apr 11, 2013 at 11:11 PM, Shawn Guo <shawn.guo at linaro.org> wrote:
> 
> >> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> >> index d90e3f5..240f863 100644
> >> --- a/drivers/video/Kconfig
> >> +++ b/drivers/video/Kconfig
> >> @@ -2428,6 +2428,7 @@ config FB_MXS
> >>       select FB_CFB_IMAGEBLIT
> >>       select FB_MODE_HELPERS
> >>       select OF_VIDEOMODE
> >
> > OF_VIDEOMODE is dead now, and should be removed.
> 
> Ok, but should I remove this on a separate patch?

I do not think so, as VIDEOMODE_HELPER is introduced to just replace
OF_VIDEOMODE and a couple of other symbols.

Shawn



From shawn.guo at linaro.org  Thu Apr 11 23:02:31 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Fri, 12 Apr 2013 11:02:31 +0800
Subject: [PATCH] ARM i.MX6q: Fix periph_clk2_sel and periph2_clk2_sel
 clocks
In-Reply-To: <1365675812-21600-1-git-send-email-p.zabel@pengutronix.de>
References: <1365675812-21600-1-git-send-email-p.zabel@pengutronix.de>
Message-ID: <20130412030228.GF16970@S2101-09.ap.freescale.net>

On Thu, Apr 11, 2013 at 12:23:32PM +0200, Philipp Zabel wrote:
> The periph_clk2_sel mux can be set to pll3, pll1, or
> osc/pll2-bypass/pll2_burn_in_clk.

Looking at IMX6DQRM Rev. 0, 11/2012, I see

13?12 periph_clk2_sel: Selector for peripheral clk2 clock multiplexer

	00 derive clock from pll3_sw_clk
	01 derive clock from pll1_ref_clk
	10 derive clock from pll2_burn_in_clk (default)
	11 reserved

Are you sure pll1_ref_clk actually means pll1_sys?  I searched the
document and word "pll1_ref_clk" occurs only once.  But Figure 18-5. BUS
clock generation on page 819 suggests it's OSC_CLK (24M).

Shawn

> The periph2_clk2_sel
> mux can be set to pll3 or pll2.
> 
> Signed-off-by: Philipp Zabel <p.zabel at pengutronix.de>
> ---
>  arch/arm/mach-imx/clk-imx6q.c | 7 ++++---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/mach-imx/clk-imx6q.c b/arch/arm/mach-imx/clk-imx6q.c
> index 65319d5..bdeddf3 100644
> --- a/arch/arm/mach-imx/clk-imx6q.c
> +++ b/arch/arm/mach-imx/clk-imx6q.c
> @@ -177,7 +177,8 @@ int imx6q_set_lpm(enum mxc_cpu_pwr_mode mode)
>  static const char *step_sels[]	= { "osc", "pll2_pfd2_396m", };
>  static const char *pll1_sw_sels[]	= { "pll1_sys", "step", };
>  static const char *periph_pre_sels[]	= { "pll2_bus", "pll2_pfd2_396m", "pll2_pfd0_352m", "pll2_198m", };
> -static const char *periph_clk2_sels[]	= { "pll3_usb_otg", "osc", };
> +static const char *periph_clk2_sels[]	= { "pll3_usb_otg", "pll1_sys", "osc", "dummy", };
> +static const char *periph2_clk2_sels[]	= { "pll3_usb_otg", "pll2_bus", };
>  static const char *periph_sels[]	= { "periph_pre", "periph_clk2", };
>  static const char *periph2_sels[]	= { "periph2_pre", "periph2_clk2", };
>  static const char *axi_sels[]		= { "periph", "pll2_pfd2_396m", "pll3_pfd1_540m", };
> @@ -369,8 +370,8 @@ int __init mx6q_clocks_init(void)
>  	clk[pll1_sw]          = imx_clk_mux("pll1_sw",	        base + 0xc,  2,  1, pll1_sw_sels,      ARRAY_SIZE(pll1_sw_sels));
>  	clk[periph_pre]       = imx_clk_mux("periph_pre",       base + 0x18, 18, 2, periph_pre_sels,   ARRAY_SIZE(periph_pre_sels));
>  	clk[periph2_pre]      = imx_clk_mux("periph2_pre",      base + 0x18, 21, 2, periph_pre_sels,   ARRAY_SIZE(periph_pre_sels));
> -	clk[periph_clk2_sel]  = imx_clk_mux("periph_clk2_sel",  base + 0x18, 12, 1, periph_clk2_sels,  ARRAY_SIZE(periph_clk2_sels));
> -	clk[periph2_clk2_sel] = imx_clk_mux("periph2_clk2_sel", base + 0x18, 20, 1, periph_clk2_sels,  ARRAY_SIZE(periph_clk2_sels));
> +	clk[periph_clk2_sel]  = imx_clk_mux("periph_clk2_sel",  base + 0x18, 12, 2, periph_clk2_sels,  ARRAY_SIZE(periph_clk2_sels));
> +	clk[periph2_clk2_sel] = imx_clk_mux("periph2_clk2_sel", base + 0x18, 20, 1, periph2_clk2_sels, ARRAY_SIZE(periph2_clk2_sels));
>  	clk[axi_sel]          = imx_clk_mux("axi_sel",          base + 0x14, 6,  2, axi_sels,          ARRAY_SIZE(axi_sels));
>  	clk[esai_sel]         = imx_clk_mux("esai_sel",         base + 0x20, 19, 2, audio_sels,        ARRAY_SIZE(audio_sels));
>  	clk[asrc_sel]         = imx_clk_mux("asrc_sel",         base + 0x30, 7,  2, audio_sels,        ARRAY_SIZE(audio_sels));
> -- 
> 1.8.2.rc2
> 



From festevam at gmail.com  Thu Apr 11 23:09:26 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Fri, 12 Apr 2013 00:09:26 -0300
Subject: [PATCH v2] video: mxsfb: Adapt to new videomode API
Message-ID: <1365736166-9840-1-git-send-email-festevam@gmail.com>

From: Fabio Estevam <fabio.estevam at freescale.com>

commit 6cd2c7db4 (videomode: videomode_from_timing work) changed the name of 
the function from videomode_from_timing() to videomode_from_timings().

commit 32ed6ef1 (videomode: create enum for videomode's display flags) changed
the 'data_flags' field in videomode structure to 'flags'

Adapt to these changes in order to fix the following errors:

drivers/video/mxsfb.c:761:3: error: too many arguments to function 'videomode_from_timing'
drivers/video/mxsfb.c:761:7: error: void value not ignored as it ought to be
drivers/video/mxsfb.c:768:9: error: 'struct videomode' has no member named 'data_flags'
drivers/video/mxsfb.c:770:9: error: 'struct videomode' has no member named 'data_flags'

Also, select VIDEOMODE_HELPER instead of OF_VIDEOMODE, as this one is 
deprecated.

Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
---
Changes since v1:
- Rebased against 20130411
- Remove OF_VIDEOMODE
- Sort the include headers

 drivers/video/Kconfig |    2 +-
 drivers/video/mxsfb.c |    8 ++++----
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 5053a4a..d52f847b 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -2427,7 +2427,7 @@ config FB_MXS
 	select FB_CFB_COPYAREA
 	select FB_CFB_IMAGEBLIT
 	select FB_MODE_HELPERS
-	select OF_VIDEOMODE
+	select VIDEOMODE_HELPERS
 	help
 	  Framebuffer support for the MXS SoC.
 
diff --git a/drivers/video/mxsfb.c b/drivers/video/mxsfb.c
index 1b2c26d..21223d4 100644
--- a/drivers/video/mxsfb.c
+++ b/drivers/video/mxsfb.c
@@ -42,7 +42,6 @@
 #include <linux/module.h>
 #include <linux/kernel.h>
 #include <linux/of_device.h>
-#include <video/of_display_timing.h>
 #include <linux/platform_device.h>
 #include <linux/clk.h>
 #include <linux/dma-mapping.h>
@@ -50,6 +49,7 @@
 #include <linux/pinctrl/consumer.h>
 #include <linux/fb.h>
 #include <linux/regulator/consumer.h>
+#include <video/of_display_timing.h>
 #include <video/videomode.h>
 
 #define REG_SET	4
@@ -777,16 +777,16 @@ static int mxsfb_init_fbinfo_dt(struct mxsfb_info *host)
 		struct videomode vm;
 		struct fb_videomode fb_vm;
 
-		ret = videomode_from_timing(timings, &vm, i);
+		ret = videomode_from_timings(timings, &vm, i);
 		if (ret < 0)
 			goto put_timings_node;
 		ret = fb_videomode_from_videomode(&vm, &fb_vm);
 		if (ret < 0)
 			goto put_timings_node;
 
-		if (vm.data_flags & DISPLAY_FLAGS_DE_HIGH)
+		if (vm.flags & DISPLAY_FLAGS_DE_HIGH)
 			host->sync |= MXSFB_SYNC_DATA_ENABLE_HIGH_ACT;
-		if (vm.data_flags & DISPLAY_FLAGS_PIXDATA_NEGEDGE)
+		if (vm.flags & DISPLAY_FLAGS_PIXDATA_NEGEDGE)
 			host->sync |= MXSFB_SYNC_DOTCLK_FALLING_ACT;
 		fb_add_videomode(&fb_vm, &fb_info->modelist);
 	}
-- 
1.7.9.5



From shawn.guo at linaro.org  Thu Apr 11 23:30:00 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Fri, 12 Apr 2013 11:30:00 +0800
Subject: [PATCH v2] video: mxsfb: Adapt to new videomode API
In-Reply-To: <1365736166-9840-1-git-send-email-festevam@gmail.com>
References: <1365736166-9840-1-git-send-email-festevam@gmail.com>
Message-ID: <20130412032958.GG16970@S2101-09.ap.freescale.net>

On Fri, Apr 12, 2013 at 12:09:26AM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam at freescale.com>
> 
> commit 6cd2c7db4 (videomode: videomode_from_timing work) changed the name of 
> the function from videomode_from_timing() to videomode_from_timings().
> 
> commit 32ed6ef1 (videomode: create enum for videomode's display flags) changed
> the 'data_flags' field in videomode structure to 'flags'
> 
> Adapt to these changes in order to fix the following errors:
> 
> drivers/video/mxsfb.c:761:3: error: too many arguments to function 'videomode_from_timing'
> drivers/video/mxsfb.c:761:7: error: void value not ignored as it ought to be
> drivers/video/mxsfb.c:768:9: error: 'struct videomode' has no member named 'data_flags'
> drivers/video/mxsfb.c:770:9: error: 'struct videomode' has no member named 'data_flags'
> 
> Also, select VIDEOMODE_HELPER instead of OF_VIDEOMODE, as this one is 
> deprecated.
> 
> Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>

Queued for 3.10-rc, thanks.



From shawn.guo at linaro.org  Thu Apr 11 23:30:39 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Fri, 12 Apr 2013 11:30:39 +0800
Subject: [PATCH v2] ARM: imx: Select GENERIC_ALLOCATOR
In-Reply-To: <1365718803-28274-1-git-send-email-festevam@gmail.com>
References: <1365718803-28274-1-git-send-email-festevam@gmail.com>
Message-ID: <20130412033037.GH16970@S2101-09.ap.freescale.net>

On Thu, Apr 11, 2013 at 07:20:03PM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam at freescale.com>
> 
> Since commit 391630c5bf11 (media: coda: use genalloc API) the following build
> error happens with imx_v4_v5_defconfig:
> 
> drivers/built-in.o: In function 'coda_remove':
> clk-composite.c:(.text+0x112180): undefined reference to 'gen_pool_free'
> drivers/built-in.o: In function 'coda_probe':
> clk-composite.c:(.text+0x112310): undefined reference to 'of_get_named_gen_pool'
> clk-composite.c:(.text+0x1123f4): undefined reference to 'gen_pool_alloc'
> clk-composite.c:(.text+0x11240c): undefined reference to 'gen_pool_virt_to_phys'
> clk-composite.c:(.text+0x112458): undefined reference to 'dev_get_gen_pool'
> 
> Select GENERIC_ALLOCATOR and get rid of the custom IRAM_ALLOC.
> 
> Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>

Queued for 3.10-rc, thanks.



From shawn.guo at linaro.org  Thu Apr 11 23:58:54 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Fri, 12 Apr 2013 11:58:54 +0800
Subject: [PATCH 0/4] ARM: dts: imx: basic dts for mx5x
In-Reply-To: <1365675197-9687-1-git-send-email-m.grzeschik@pengutronix.de>
References: <1365675197-9687-1-git-send-email-m.grzeschik@pengutronix.de>
Message-ID: <20130412035852.GI16970@S2101-09.ap.freescale.net>

On Thu, Apr 11, 2013 at 12:13:13PM +0200, Michael Grzeschik wrote:
> This patchset adds basic usb support for the qsb.
> 
> Michael Grzeschik (4):
>   ARM: dts: imx: add imx5x usbmisc entries
>   ARM: dts: imx: add imx5x usb clock DT lookups
>   ARM: dts: imx: use usb-nop-xceiv usbphy entries for imx5x
>   ARM: dts: imx: imx53-qsb.dts: enable usbotg and usbh1

All applied, with one small change on the last one though.  See reply to
it.  Thanks.

Shawn



From shawn.guo at linaro.org  Fri Apr 12 00:02:08 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Fri, 12 Apr 2013 12:02:08 +0800
Subject: [PATCH 4/4] ARM: dts: imx: imx53-qsb.dts: enable usbotg and usbh1
In-Reply-To: <1365675197-9687-5-git-send-email-m.grzeschik@pengutronix.de>
References: <1365675197-9687-1-git-send-email-m.grzeschik@pengutronix.de>
 <1365675197-9687-5-git-send-email-m.grzeschik@pengutronix.de>
Message-ID: <20130412040206.GJ16970@S2101-09.ap.freescale.net>

On Thu, Apr 11, 2013 at 12:13:17PM +0200, Michael Grzeschik wrote:
> Signed-off-by: Michael Grzeschik <m.grzeschik at pengutronix.de>
> ---
>  arch/arm/boot/dts/imx53-qsb.dts | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/imx53-qsb.dts b/arch/arm/boot/dts/imx53-qsb.dts
> index 05cc562..953b2d4 100644
> --- a/arch/arm/boot/dts/imx53-qsb.dts
> +++ b/arch/arm/boot/dts/imx53-qsb.dts
> @@ -83,6 +83,14 @@
>  	};
>  };
>  
> +&usbotg {
> +       status = "okay";
> +};
> +
> +&usbh1 {
> +       status = "okay";
> +};
> +

It's my fault that those existing nodes did not get sorted well from day
one.  But let's do for new added ones.

I just put these two at the end of the file in the following order.

 &usbh1
 &usbotg

Shawn



From shawn.guo at linaro.org  Fri Apr 12 02:05:30 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Fri, 12 Apr 2013 14:05:30 +0800
Subject: [PATCH 04/18] ARM: imx: cpuidle: create separate drivers for
 imx5/imx6
In-Reply-To: <1365603743-5618-5-git-send-email-daniel.lezcano@linaro.org>
References: <1365603743-5618-1-git-send-email-daniel.lezcano@linaro.org>
 <1365603743-5618-5-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <20130412060527.GA16494@S2101-09.ap.freescale.net>

On Wed, Apr 10, 2013 at 04:22:09PM +0200, Daniel Lezcano wrote:
> The code intializes the cpuidle driver at different places.
> The cpuidle driver for :
>   * imx5 : is in the pm-imx5.c, the init function is in cpuidle.c
>   * imx6 : is in cpuidle-imx6q.c, the init function is in cpuidle.c
>            and cpuidle-imx6q.c
> 
> Instead of having the cpuidle code spread across different files,
> let's write a driver for each SoC and make the code similar.
> 
> That implies some code duplication but that will be fixed with the
> next patches which consolidate the initialization for all the drivers.
> 
IMO, this is unnecessary churn.  I agree that we can have cpuidle-imx5.c
instead of carrying imx5 cpuidle code in pm-imx5.c.  But removing
cpuidle.c and duplicating what imx_cpuidle_init() does into imx5 and
imx6q driver is a step backward to me.

I suggest simply merging this patch into "[PATCH 18/18] ARM: imx:
cpuidle: use init/exit common routine"

> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
> ---
>  arch/arm/mach-imx/Makefile        |    1 +
>  arch/arm/mach-imx/cpuidle-imx5.c  |   74 ++++++++++++++++++++++++++++++++++
>  arch/arm/mach-imx/cpuidle-imx6q.c |   36 ++++++++++++++++-
>  arch/arm/mach-imx/cpuidle.c       |   80 -------------------------------------
>  arch/arm/mach-imx/cpuidle.h       |   10 ++---
>  arch/arm/mach-imx/pm-imx5.c       |   29 +-------------
>  6 files changed, 115 insertions(+), 115 deletions(-)
>  create mode 100644 arch/arm/mach-imx/cpuidle-imx5.c
>  delete mode 100644 arch/arm/mach-imx/cpuidle.c
> 
> diff --git a/arch/arm/mach-imx/Makefile b/arch/arm/mach-imx/Makefile
> index c4ce090..bfd5f5b 100644
> --- a/arch/arm/mach-imx/Makefile
> +++ b/arch/arm/mach-imx/Makefile
> @@ -31,6 +31,7 @@ obj-$(CONFIG_CPU_FREQ_IMX)    += cpufreq.o
>  
>  ifeq ($(CONFIG_CPU_IDLE),y)
>  obj-y += cpuidle.o

This target should be removed, since arch/arm/mach-imx/cpuidle.c goes
away.

Shawn

> +obj-$(CONFIG_SOC_IMX5) += cpuidle-imx5.o
>  obj-$(CONFIG_SOC_IMX6Q) += cpuidle-imx6q.o
>  endif



From hvaibhav at ti.com  Fri Apr 12 02:18:04 2013
From: hvaibhav at ti.com (Hiremath, Vaibhav)
Date: Fri, 12 Apr 2013 06:18:04 +0000
Subject: [PATCH v2 11/11] ARM: OMAP2+: omap_hwmod: Don't call
 _init_mpu_rt_base if no sysc
In-Reply-To: <51661613.4070405@ti.com>
References: <1363699857-5505-1-git-send-email-santosh.shilimkar@ti.com>
 <1363699857-5505-12-git-send-email-santosh.shilimkar@ti.com>
 <51661613.4070405@ti.com>
Message-ID: <79CD15C6BA57404B839C016229A409A83EC4EC9F@DBDE01.ent.ti.com>

> -----Original Message-----
> From: Hunter, Jon
> Sent: Thursday, April 11, 2013 7:17 AM
> To: Shilimkar, Santosh
> Cc: Cousson, Benoit; linux-omap at vger.kernel.org; linux-arm-
> kernel at lists.infradead.org; tony at atomide.com; Hiremath, Vaibhav
> Subject: Re: [PATCH v2 11/11] ARM: OMAP2+: omap_hwmod: Don't call
> _init_mpu_rt_base if no sysc
> 
> 
> On 03/19/2013 08:30 AM, Santosh Shilimkar wrote:
> > OMAP hwmod layer does the reset of the IPs in early code so that
> > we have SOC in sane state. To do the soft-reset, it needs to
> ioremap()
> > the ip address space to be able to write to sysconfig registers.
> >
> > But there are few hwmod which doesn't have sysconfig registers and
> hence
> > no need to ioremap() them in early init code.
> >
> > So this patch makes prevet calling the _init_mpu_rt_base()
> conditional
> > based on sysc availability.
> >
> > Cc: Benoit Cousson <b-cousson at ti.com>
> >
> > Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
> > ---
> >  arch/arm/mach-omap2/omap_hwmod.c |    3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-
> omap2/omap_hwmod.c
> > index 4501038..1a1f0a4 100644
> > --- a/arch/arm/mach-omap2/omap_hwmod.c
> > +++ b/arch/arm/mach-omap2/omap_hwmod.c
> > @@ -2449,7 +2449,8 @@ static int __init _init(struct omap_hwmod *oh,
> void *data)
> >  	if (oh->_state != _HWMOD_STATE_REGISTERED)
> >  		return 0;
> >
> > -	_init_mpu_rt_base(oh, NULL);
> > +	if (oh->class->sysc)
> > +		_init_mpu_rt_base(oh, NULL);
> >
> >  	r = _init_clocks(oh, NULL);
> >  	if (IS_ERR_VALUE(r)) {
> 
> I have not looked into why, but this commit is triggering the following
> panic on am335x-evm. I don't see this on the omap platforms only
> am335x.
> 
> Adding Vaibhav ...
> 
I think I have already fixed this, can you try applying below patches

http://www.mail-archive.com/linux-omap at vger.kernel.org/msg87524.html


Thanks,
Vaibhav



Thanks,
Vaibhav


From tomi.valkeinen at ti.com  Fri Apr 12 02:25:39 2013
From: tomi.valkeinen at ti.com (Tomi Valkeinen)
Date: Fri, 12 Apr 2013 09:25:39 +0300
Subject: [PATCH] video: mxsfb: Adapt to new videomode API
In-Reply-To: <20130412020202.GC16970@S2101-09.ap.freescale.net>
References: <1365516978-29888-1-git-send-email-fabio.estevam@freescale.com>
 <5165228F.1020805@ti.com>
 <CAOMZO5BY0mpYC1sjkRsnX-jnj8X4u9ZH15GCQ=MqMYeQ-LAfuQ@mail.gmail.com>
 <20130412020202.GC16970@S2101-09.ap.freescale.net>
Message-ID: <5167A8E3.7070109@ti.com>

On 2013-04-12 05:02, Shawn Guo wrote:
> On Wed, Apr 10, 2013 at 09:36:31AM -0300, Fabio Estevam wrote:
>> On Wed, Apr 10, 2013 at 5:27 AM, Tomi Valkeinen <tomi.valkeinen at ti.com> wrote:
>>
>>> The mxsfb.c driver in my tree does not contain such code. Where is this
>>> patch meant to be applied?
>>
>> linux-next 20130408 is broken for mxs without this fix. Maybe Shawn can take it?
> 
> I will take it and send it during -rc when Tomi's patches hit mainline.
> But I have a couple trivial comments on the patch.  I'm replying to the
> patch.

Fine by me, but wouldn't it be easier to get the mxsfb driver changes
along with other fbdev changes via my tree? Or do you have dependencies
to arch changes or such in the mxsfb changes?

 Tomi


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130412/1a249917/attachment.sig>

From shawn.guo at linaro.org  Fri Apr 12 02:30:47 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Fri, 12 Apr 2013 14:30:47 +0800
Subject: [PATCH] video: mxsfb: Adapt to new videomode API
In-Reply-To: <5167A8E3.7070109@ti.com>
References: <1365516978-29888-1-git-send-email-fabio.estevam@freescale.com>
 <5165228F.1020805@ti.com>
 <CAOMZO5BY0mpYC1sjkRsnX-jnj8X4u9ZH15GCQ=MqMYeQ-LAfuQ@mail.gmail.com>
 <20130412020202.GC16970@S2101-09.ap.freescale.net>
 <5167A8E3.7070109@ti.com>
Message-ID: <20130412063045.GK16970@S2101-09.ap.freescale.net>

On Fri, Apr 12, 2013 at 09:25:39AM +0300, Tomi Valkeinen wrote:
> Fine by me, but wouldn't it be easier to get the mxsfb driver changes
> along with other fbdev changes via my tree? Or do you have dependencies
> to arch changes or such in the mxsfb changes?

I have mach-mxs patches removing auxdata depending on the mxsfb changes.

Shawn



From tomi.valkeinen at ti.com  Fri Apr 12 02:32:56 2013
From: tomi.valkeinen at ti.com (Tomi Valkeinen)
Date: Fri, 12 Apr 2013 09:32:56 +0300
Subject: [PATCH] video: mxsfb: Adapt to new videomode API
In-Reply-To: <20130412063045.GK16970@S2101-09.ap.freescale.net>
References: <1365516978-29888-1-git-send-email-fabio.estevam@freescale.com>
 <5165228F.1020805@ti.com>
 <CAOMZO5BY0mpYC1sjkRsnX-jnj8X4u9ZH15GCQ=MqMYeQ-LAfuQ@mail.gmail.com>
 <20130412020202.GC16970@S2101-09.ap.freescale.net> <5167A8E3.7070109@ti.com>
 <20130412063045.GK16970@S2101-09.ap.freescale.net>
Message-ID: <5167AA98.9010405@ti.com>

On 2013-04-12 09:30, Shawn Guo wrote:
> On Fri, Apr 12, 2013 at 09:25:39AM +0300, Tomi Valkeinen wrote:
>> Fine by me, but wouldn't it be easier to get the mxsfb driver changes
>> along with other fbdev changes via my tree? Or do you have dependencies
>> to arch changes or such in the mxsfb changes?
> 
> I have mach-mxs patches removing auxdata depending on the mxsfb changes.

Ok.

Acked-by: Tomi Valkeinen <tomi.valkeinen at ti.com>

 Tomi


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130412/5157dbf5/attachment-0001.sig>

From daniel.lezcano at linaro.org  Fri Apr 12 02:47:13 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Fri, 12 Apr 2013 08:47:13 +0200
Subject: [V2 patch 01/19] ARM: shmobile: cpuidle: remove shmobile_enter_wfi
 function
In-Reply-To: <20130412004425.GD24461@verge.net.au>
References: <1365712969-7541-1-git-send-email-daniel.lezcano@linaro.org>
 <1365712969-7541-2-git-send-email-daniel.lezcano@linaro.org>
 <20130412004425.GD24461@verge.net.au>
Message-ID: <5167ADF1.50401@linaro.org>

On 04/12/2013 02:44 AM, Simon Horman wrote:
> On Thu, Apr 11, 2013 at 10:42:31PM +0200, Daniel Lezcano wrote:
>> Remove the shmobile_enter_wfi function which is the same as the
>> common WFI enter function from the arm cpuidle driver defined
>> with the ARM_CPUIDLE_WFI_STATE macro.
> Should this patch also make shmobile_enter_wfi static in
> arch/arm/mach-shmobile/cpuidle.c ?

Hum, no :)

Actually, the function was removed because it was expected to be not
longer used. I missed the cpuidle driver in the pm-sh7372.c file and the
function declaration in the header file.
> Also, I have a slight preference for the patch to be split into two.
> 1. A patch to remove usage of shmobile_enter_wfi from the sh7372 SoC.
> 2. A patch to remove shmobile_enter_wfi. from common.h
>    (and make it static?).

Ok, regarding my answer above, do you still want two patches for this ?

Thanks
-- Daniel

-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From manishv.b at ti.com  Fri Apr 12 02:49:32 2013
From: manishv.b at ti.com (Vishwanathrao Badarkhe, Manish)
Date: Fri, 12 Apr 2013 06:49:32 +0000
Subject: [PATCH] ARM: dts: omap2plus: remove interrupt-parent property
In-Reply-To: <1362996002-15552-1-git-send-email-manishv.b@ti.com>
References: <1362996002-15552-1-git-send-email-manishv.b@ti.com>
Message-ID: <A4887BF146CD57468F700B415D2F470158738C@DBDE01.ent.ti.com>

Hi Benoit,
Are there any review comments on this patch? 
Could you please accept this patch if there are not any review comments?

Thanks
Manish Badarkhe

-----Original Message-----
From: Vishwanathrao Badarkhe, Manish 
Sent: Monday, March 11, 2013 3:30 PM
To: devicetree-discuss at lists.ozlabs.org; linux-arm-kernel at lists.infradead.org; linux-kernel at vger.kernel.org; linux-omap at vger.kernel.org
Cc: tony at atomide.com; Cousson, Benoit; linux at arm.linux.org.uk; Vishwanathrao Badarkhe, Manish
Subject: [PATCH] ARM: dts: omap2plus: remove interrupt-parent property

Removed interrupt-parent property from dts file as it is already
with root node in dtsi file.

Signed-off-by: Vishwanathrao Badarkhe, Manish <manishv.b at ti.com>
---
:100644 100644 f624dc8... 36e839a... M	arch/arm/boot/dts/omap3-beagle.dts
:100644 100644 e8ba1c2... a5375fd... M	arch/arm/boot/dts/omap3-evm.dts
:100644 100644 4122efe... 389c9c7... M	arch/arm/boot/dts/omap4-panda.dts
:100644 100644 43e5258... cdf5dfd... M	arch/arm/boot/dts/omap4-sdp.dts
:100644 100644 6601e6a... 1d4a9d4... M	arch/arm/boot/dts/omap4-var-som.dts
 arch/arm/boot/dts/omap3-beagle.dts  |    1 -
 arch/arm/boot/dts/omap3-evm.dts     |    1 -
 arch/arm/boot/dts/omap4-panda.dts   |    2 --
 arch/arm/boot/dts/omap4-sdp.dts     |    2 --
 arch/arm/boot/dts/omap4-var-som.dts |    1 -
 5 files changed, 0 insertions(+), 7 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-beagle.dts b/arch/arm/boot/dts/omap3-beagle.dts
index f624dc8..36e839a 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -46,7 +46,6 @@
 	twl: twl at 48 {
 		reg = <0x48>;
 		interrupts = <7>; /* SYS_NIRQ cascaded to intc */
-		interrupt-parent = <&intc>;
 	};
 };
 
diff --git a/arch/arm/boot/dts/omap3-evm.dts b/arch/arm/boot/dts/omap3-evm.dts
index e8ba1c2..a5375fd 100644
--- a/arch/arm/boot/dts/omap3-evm.dts
+++ b/arch/arm/boot/dts/omap3-evm.dts
@@ -34,7 +34,6 @@
 	twl: twl at 48 {
 		reg = <0x48>;
 		interrupts = <7>; /* SYS_NIRQ cascaded to intc */
-		interrupt-parent = <&intc>;
 	};
 };
 
diff --git a/arch/arm/boot/dts/omap4-panda.dts b/arch/arm/boot/dts/omap4-panda.dts
index 4122efe..389c9c7 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -119,7 +119,6 @@
 		reg = <0x48>;
 		/* SPI = 0, IRQ# = 7, 4 = active high level-sensitive */
 		interrupts = <0 7 4>; /* IRQ_SYS_1N cascaded to gic */
-		interrupt-parent = <&gic>;
 	};
 
 	twl6040: twl at 4b {
@@ -127,7 +126,6 @@
 		reg = <0x4b>;
 		/* SPI = 0, IRQ# = 119, 4 = active high level-sensitive */
 		interrupts = <0 119 4>; /* IRQ_SYS_2N cascaded to gic */
-		interrupt-parent = <&gic>;
 		ti,audpwron-gpio = <&gpio4 31 0>;  /* gpio line 127 */
 
 		vio-supply = <&v1v8>;
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 43e5258..cdf5dfd 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -221,7 +221,6 @@
 		reg = <0x48>;
 		/* SPI = 0, IRQ# = 7, 4 = active high level-sensitive */
 		interrupts = <0 7 4>; /* IRQ_SYS_1N cascaded to gic */
-		interrupt-parent = <&gic>;
 	};
 
 	twl6040: twl at 4b {
@@ -229,7 +228,6 @@
 		reg = <0x4b>;
 		/* SPI = 0, IRQ# = 119, 4 = active high level-sensitive */
 		interrupts = <0 119 4>; /* IRQ_SYS_2N cascaded to gic */
-		interrupt-parent = <&gic>;
 		ti,audpwron-gpio = <&gpio4 31 0>;  /* gpio line 127 */
 
 		vio-supply = <&v1v8>;
diff --git a/arch/arm/boot/dts/omap4-var-som.dts b/arch/arm/boot/dts/omap4-var-som.dts
index 6601e6a..1d4a9d4 100644
--- a/arch/arm/boot/dts/omap4-var-som.dts
+++ b/arch/arm/boot/dts/omap4-var-som.dts
@@ -35,7 +35,6 @@
 		reg = <0x48>;
 		/* SPI = 0, IRQ# = 7, 4 = active high level-sensitive */
 		interrupts = <0 7 4>; /* IRQ_SYS_1N cascaded to gic */
-		interrupt-parent = <&gic>;
 	};
 };
 
-- 
1.7.4.1



From christian.ruppert at abilis.com  Fri Apr 12 02:54:19 2013
From: christian.ruppert at abilis.com (Christian Ruppert)
Date: Fri, 12 Apr 2013 08:54:19 +0200
Subject: [PATCH] clk: Add device tree binding to clk-fixed-factor
In-Reply-To: <5166E41F.7060100@free-electrons.com>
References: <1365608443-30350-1-git-send-email-christian.ruppert@abilis.com>
 <51658BA9.7030508@free-electrons.com>
 <20130410162747.GG32603@ab42.lan> <20130411091952.GF8400@ab42.lan>
 <5166E41F.7060100@free-electrons.com>
Message-ID: <20130412065417.GA29291@ab42.lan>

On Thu, Apr 11, 2013 at 06:26:07PM +0200, Gregory CLEMENT wrote:
> On 04/11/2013 11:19 AM, Christian Ruppert wrote:
> > Hi Gregory,
> > 
> > Since there doesn't seem to be anyone opposing this feature I just
> > checked your patch and after adding the CLK_OF_DECLARE macro in the end
> > it works well for us. Tell me if you would like to rebase and resubmit
> > your patch or if I should follow up on our own.
> 
> I can rebase and resubmit my patch, it's pretty straightforward.
> The problem was the lack of user in the kernel. And by user I mean
> a driver using these functions. Usually a new function enter in the
> kernel only if there are users for it inside the kernel so if you plan
> to submit a driver using this piece of code, then I see no reason
> to not get it.

If you add the line

CLK_OF_DECLARE(fixed_factor_clk, "fixed-factor-clkdiv", 

in the end of drivers/clk/clk-fixed-factor.c, the new function will be
automatically used by of_clk_init(NULL) which itself is used in numerous
platform ports, in particular arch/arc/plat-tb10x. plat-tb10x is currently
being integrated in the ARC architecture tree. The device tree file
requiring this patch is already in linux-next (see
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/arch/arc/boot/dts/abilis_*.dtsi).

We didn't know if you wanted to resubmit your patch or if I should
pursue mine at the time, and today it uses the naming scheme from mine.
It would be nice if you could either adapt your patch to that naming
scheme.

Greetings,
  Christian

> > Greetings,
> >   Christian
> > 
> > On Wed, Apr 10, 2013 at 06:27:47PM +0200, christian ruppert wrote:
> >> Hi Gregory,
> >>
> >> We use derived clocks with fixed ratios for our TB10x platform. I
> >> originally had this in the platform code but Vineet (the platform
> >> maintainer) rightly pointed out that the common clock framework would
> >> be the correct place for it.
> >> Is there any reason not to support this functionality? After all, the
> >> generic fixed rate clock also has a device tree binding and I'd guess
> >> we're not the only ones statically deriving one clock from another in
> >> our SOCs.
> >>
> >> Greetings,
> >>   Christian
> >>
> >> On Wed, Apr 10, 2013 at 05:56:25PM +0200, Gregory CLEMENT wrote:
> >>> Hi Christian,
> >>>
> >>> On 04/10/2013 05:40 PM, Christian Ruppert wrote:
> >>>> This patch adds a device tree binding for the simple fixed factor clock
> >>>> divider/multiplier of the common clock tree binding.
> >>>
> >>> This patch remind me of something :
> >>> http://lists.infradead.org/pipermail/linux-arm-kernel/2012-August/116405.html
> >>>
> >>> Do you have a use case for it, this time?
> >>>
> >>> My version have been hold off waiting for an user for it.
> >>> Will you need it for a driver?
> >>>
> >>> Regards,
> >>>
> >>>>
> >>>> Signed-off-by: Christian Ruppert <christian.ruppert at abilis.com>
> >>>> ---
> >>>>  .../bindings/clock/fixed-factor-clkdiv.txt         |   24 +++++++++++++++
> >>>>  drivers/clk/clk-fixed-factor.c                     |   32 ++++++++++++++++++++
> >>>>  include/linux/clk-provider.h                       |    1 +
> >>>>  3 files changed, 57 insertions(+), 0 deletions(-)
> >>>>  create mode 100644 Documentation/devicetree/bindings/clock/fixed-factor-clkdiv.txt
> >>>>
> >>>> diff --git a/Documentation/devicetree/bindings/clock/fixed-factor-clkdiv.txt b/Documentation/devicetree/bindings/clock/fixed-factor-clkdiv.txt
> >>>> new file mode 100644
> >>>> index 0000000..352bac4
> >>>> --- /dev/null
> >>>> +++ b/Documentation/devicetree/bindings/clock/fixed-factor-clkdiv.txt
> >>>> @@ -0,0 +1,24 @@
> >>>> +Device Tree Clock bindings for plat-tb10x
> >>>> +
> >>>> +This binding uses the common clock binding[1].
> >>>> +
> >>>> +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
> >>>> +
> >>>> +Required properties:
> >>>> +- compatible : shall be "fixed-factor-clkdiv"
> >>>> +- #clock-cells: from common clock binding; shall be set to 0
> >>>> +- clocks: shall be the input parent clock phandle for the clock.
> >>>> +- clock-mult: defines the multiplication factor of the output clock frequency
> >>>> +  wrt. the input clock frequency.
> >>>> +- clock-div: defines the division factor of the output clock frequency wrt.
> >>>> +  the input clock frequency.
> >>>> +
> >>>> +Example:
> >>>> +cpu_clk: clkdiv_cpu {	/* CPU clock derived from pll0. 1/2 of pll frequency */
> >>>> +	compatible = "fixed-factor-clkdiv";
> >>>> +	#clock-cells = <0>;
> >>>> +	clocks = <&pll0>;
> >>>> +	clock-mult = <1>;
> >>>> +	clock-div = <2>;
> >>>> +	clock-output-names = "cpu_clk";
> >>>> +};
> >>>> diff --git a/drivers/clk/clk-fixed-factor.c b/drivers/clk/clk-fixed-factor.c
> >>>> index 1ef271e..85e45f1 100644
> >>>> --- a/drivers/clk/clk-fixed-factor.c
> >>>> +++ b/drivers/clk/clk-fixed-factor.c
> >>>> @@ -11,6 +11,7 @@
> >>>>  #include <linux/clk-provider.h>
> >>>>  #include <linux/slab.h>
> >>>>  #include <linux/err.h>
> >>>> +#include <linux/of.h>
> >>>>  
> >>>>  /*
> >>>>   * DOC: basic fixed multiplier and divider clock that cannot gate
> >>>> @@ -96,3 +97,34 @@ struct clk *clk_register_fixed_factor(struct device *dev, const char *name,
> >>>>  
> >>>>  	return clk;
> >>>>  }
> >>>> +
> >>>> +#ifdef CONFIG_OF
> >>>> +/**
> >>>> + * of_fixed_factor_clkdiv_setup() - Set up simple fixed factor clock divider
> >>>> + */
> >>>> +void of_fixed_factor_clkdiv_setup(struct device_node *node)
> >>>> +{
> >>>> +	struct clk *clk;
> >>>> +	const char *clk_name = node->name;
> >>>> +	const char *parent_name;
> >>>> +	u32 mult, div;
> >>>> +
> >>>> +	if (of_property_read_u32(node, "clock-mult", &mult))
> >>>> +		return;
> >>>> +
> >>>> +	if (of_property_read_u32(node, "clock-div", &div))
> >>>> +		return;
> >>>> +
> >>>> +	parent_name = of_clk_get_parent_name(node, 0);
> >>>> +
> >>>> +	of_property_read_string(node, "clock-output-names", &clk_name);
> >>>> +
> >>>> +	clk = clk_register_fixed_factor(NULL, clk_name, parent_name, 0,
> >>>> +					mult, div);
> >>>> +	if (!IS_ERR(clk))
> >>>> +		of_clk_add_provider(node, of_clk_src_simple_get, clk);
> >>>> +}
> >>>> +EXPORT_SYMBOL_GPL(of_fixed_factor_clkdiv_setup);
> >>>> +CLK_OF_DECLARE(fixed_clkdiv, "fixed-factor-clkdiv",
> >>>> +		of_fixed_factor_clkdiv_setup);
> >>>> +#endif
> >>>> diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
> >>>> index 7f197d7..d4937cf 100644
> >>>> --- a/include/linux/clk-provider.h
> >>>> +++ b/include/linux/clk-provider.h
> >>>> @@ -184,6 +184,7 @@ struct clk *clk_register_fixed_rate(struct device *dev, const char *name,
> >>>>  		unsigned long fixed_rate);
> >>>>  
> >>>>  void of_fixed_clk_setup(struct device_node *np);
> >>>> +void of_fixed_factor_clkdiv_setup(struct device_node *node);
> >>>>  
> >>>>  /**
> >>>>   * struct clk_gate - gating clock
> >>>>
> >>>
> >>>
> >>> -- 
> >>> Gregory Clement, Free Electrons
> >>> Kernel, drivers, real-time and embedded Linux
> >>> development, consulting, training and support.
> >>> http://free-electrons.com
> >>
> >> -- 
> >>   Christian Ruppert              ,          <christian.ruppert at abilis.com>
> >>                                 /|
> >>   Tel: +41/(0)22 816 19-42     //|                 3, Chemin du Pr?-Fleuri
> >>                              _// | bilis Systems   CH-1228 Plan-les-Ouates
> > 
> 
> 
> -- 
> Gregory Clement, Free Electrons
> Kernel, drivers, real-time and embedded Linux
> development, consulting, training and support.
> http://free-electrons.com

-- 
  Christian Ruppert              ,          <christian.ruppert at abilis.com>
                                /|
  Tel: +41/(0)22 816 19-42     //|                 3, Chemin du Pr?-Fleuri
                             _// | bilis Systems   CH-1228 Plan-les-Ouates


From daniel.lezcano at linaro.org  Fri Apr 12 02:58:52 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Fri, 12 Apr 2013 08:58:52 +0200
Subject: [PATCH 04/18] ARM: imx: cpuidle: create separate drivers for
 imx5/imx6
In-Reply-To: <20130412060527.GA16494@S2101-09.ap.freescale.net>
References: <1365603743-5618-1-git-send-email-daniel.lezcano@linaro.org>
 <1365603743-5618-5-git-send-email-daniel.lezcano@linaro.org>
 <20130412060527.GA16494@S2101-09.ap.freescale.net>
Message-ID: <5167B0AC.2000308@linaro.org>

On 04/12/2013 08:05 AM, Shawn Guo wrote:
> On Wed, Apr 10, 2013 at 04:22:09PM +0200, Daniel Lezcano wrote:
>> The code intializes the cpuidle driver at different places.
>> The cpuidle driver for :
>>   * imx5 : is in the pm-imx5.c, the init function is in cpuidle.c
>>   * imx6 : is in cpuidle-imx6q.c, the init function is in cpuidle.c
>>            and cpuidle-imx6q.c
>>
>> Instead of having the cpuidle code spread across different files,
>> let's write a driver for each SoC and make the code similar.
>>
>> That implies some code duplication but that will be fixed with the
>> next patches which consolidate the initialization for all the drivers.
>>
> IMO, this is unnecessary churn.  I agree that we can have cpuidle-imx5.c
> instead of carrying imx5 cpuidle code in pm-imx5.c.  But removing
> cpuidle.c and duplicating what imx_cpuidle_init() does into imx5 and
> imx6q driver is a step backward to me.
> I suggest simply merging this patch into "[PATCH 18/18] ARM: imx:
> cpuidle: use init/exit common routine"

Yes, I am aware that can can look weird but that was to have the
different steps to reach the common register function.
If I merge this patch with the patch 18, I am afraid the modification
won't be obvious to the one who will read the patch later (eg. for a git
bisect).

It is quite easy to fold the patches, but with the comment above do you
still want me to do that ?

Thanks
  -- Daniel


>> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
>> ---
>>  arch/arm/mach-imx/Makefile        |    1 +
>>  arch/arm/mach-imx/cpuidle-imx5.c  |   74 ++++++++++++++++++++++++++++++++++
>>  arch/arm/mach-imx/cpuidle-imx6q.c |   36 ++++++++++++++++-
>>  arch/arm/mach-imx/cpuidle.c       |   80 -------------------------------------
>>  arch/arm/mach-imx/cpuidle.h       |   10 ++---
>>  arch/arm/mach-imx/pm-imx5.c       |   29 +-------------
>>  6 files changed, 115 insertions(+), 115 deletions(-)
>>  create mode 100644 arch/arm/mach-imx/cpuidle-imx5.c
>>  delete mode 100644 arch/arm/mach-imx/cpuidle.c
>>
>> diff --git a/arch/arm/mach-imx/Makefile b/arch/arm/mach-imx/Makefile
>> index c4ce090..bfd5f5b 100644
>> --- a/arch/arm/mach-imx/Makefile
>> +++ b/arch/arm/mach-imx/Makefile
>> @@ -31,6 +31,7 @@ obj-$(CONFIG_CPU_FREQ_IMX)    += cpufreq.o
>>  
>>  ifeq ($(CONFIG_CPU_IDLE),y)
>>  obj-y += cpuidle.o
> This target should be removed, since arch/arm/mach-imx/cpuidle.c goes
> away.
>
> Shawn
>
>> +obj-$(CONFIG_SOC_IMX5) += cpuidle-imx5.o
>>  obj-$(CONFIG_SOC_IMX6Q) += cpuidle-imx6q.o
>>  endif
>
> _______________________________________________
> linaro-kernel mailing list
> linaro-kernel at lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/linaro-kernel
>



From gregory.clement at free-electrons.com  Fri Apr 12 03:05:37 2013
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Fri, 12 Apr 2013 09:05:37 +0200
Subject: [PATCH] clk: Add device tree binding to clk-fixed-factor
In-Reply-To: <20130412065417.GA29291@ab42.lan>
References: <1365608443-30350-1-git-send-email-christian.ruppert@abilis.com>
 <51658BA9.7030508@free-electrons.com> <20130410162747.GG32603@ab42.lan>
 <20130411091952.GF8400@ab42.lan> <5166E41F.7060100@free-electrons.com>
 <20130412065417.GA29291@ab42.lan>
Message-ID: <5167B241.5090807@free-electrons.com>

On 04/12/2013 08:54 AM, Christian Ruppert wrote:
> On Thu, Apr 11, 2013 at 06:26:07PM +0200, Gregory CLEMENT wrote:
>> On 04/11/2013 11:19 AM, Christian Ruppert wrote:
>>> Hi Gregory,
>>>
>>> Since there doesn't seem to be anyone opposing this feature I just
>>> checked your patch and after adding the CLK_OF_DECLARE macro in the end
>>> it works well for us. Tell me if you would like to rebase and resubmit
>>> your patch or if I should follow up on our own.
>>
>> I can rebase and resubmit my patch, it's pretty straightforward.
>> The problem was the lack of user in the kernel. And by user I mean
>> a driver using these functions. Usually a new function enter in the
>> kernel only if there are users for it inside the kernel so if you plan
>> to submit a driver using this piece of code, then I see no reason
>> to not get it.
> 
> If you add the line
> 
> CLK_OF_DECLARE(fixed_factor_clk, "fixed-factor-clkdiv", 
> 
> in the end of drivers/clk/clk-fixed-factor.c, the new function will be
> automatically used by of_clk_init(NULL) which itself is used in numerous
> platform ports, in particular arch/arc/plat-tb10x. plat-tb10x is currently
> being integrated in the ARC architecture tree. The device tree file
> requiring this patch is already in linux-next (see
> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/arch/arc/boot/dts/abilis_*.dtsi).
> 

great it is good to know there are "user" for this function.

> We didn't know if you wanted to resubmit your patch or if I should
> pursue mine at the time, and today it uses the naming scheme from mine.
> It would be nice if you could either adapt your patch to that naming
> scheme.

I am going to resubmit my patch this morning and adapt it to your naming
scheme.

Regards,


> 
> Greetings,
>   Christian
> 
>>> Greetings,
>>>   Christian
>>>
>>> On Wed, Apr 10, 2013 at 06:27:47PM +0200, christian ruppert wrote:
>>>> Hi Gregory,
>>>>
>>>> We use derived clocks with fixed ratios for our TB10x platform. I
>>>> originally had this in the platform code but Vineet (the platform
>>>> maintainer) rightly pointed out that the common clock framework would
>>>> be the correct place for it.
>>>> Is there any reason not to support this functionality? After all, the
>>>> generic fixed rate clock also has a device tree binding and I'd guess
>>>> we're not the only ones statically deriving one clock from another in
>>>> our SOCs.
>>>>
>>>> Greetings,
>>>>   Christian
>>>>
>>>> On Wed, Apr 10, 2013 at 05:56:25PM +0200, Gregory CLEMENT wrote:
>>>>> Hi Christian,
>>>>>
>>>>> On 04/10/2013 05:40 PM, Christian Ruppert wrote:
>>>>>> This patch adds a device tree binding for the simple fixed factor clock
>>>>>> divider/multiplier of the common clock tree binding.
>>>>>
>>>>> This patch remind me of something :
>>>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2012-August/116405.html
>>>>>
>>>>> Do you have a use case for it, this time?
>>>>>
>>>>> My version have been hold off waiting for an user for it.
>>>>> Will you need it for a driver?
>>>>>
>>>>> Regards,
>>>>>
>>>>>>
>>>>>> Signed-off-by: Christian Ruppert <christian.ruppert at abilis.com>
>>>>>> ---
>>>>>>  .../bindings/clock/fixed-factor-clkdiv.txt         |   24 +++++++++++++++
>>>>>>  drivers/clk/clk-fixed-factor.c                     |   32 ++++++++++++++++++++
>>>>>>  include/linux/clk-provider.h                       |    1 +
>>>>>>  3 files changed, 57 insertions(+), 0 deletions(-)
>>>>>>  create mode 100644 Documentation/devicetree/bindings/clock/fixed-factor-clkdiv.txt
>>>>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/clock/fixed-factor-clkdiv.txt b/Documentation/devicetree/bindings/clock/fixed-factor-clkdiv.txt
>>>>>> new file mode 100644
>>>>>> index 0000000..352bac4
>>>>>> --- /dev/null
>>>>>> +++ b/Documentation/devicetree/bindings/clock/fixed-factor-clkdiv.txt
>>>>>> @@ -0,0 +1,24 @@
>>>>>> +Device Tree Clock bindings for plat-tb10x
>>>>>> +
>>>>>> +This binding uses the common clock binding[1].
>>>>>> +
>>>>>> +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
>>>>>> +
>>>>>> +Required properties:
>>>>>> +- compatible : shall be "fixed-factor-clkdiv"
>>>>>> +- #clock-cells: from common clock binding; shall be set to 0
>>>>>> +- clocks: shall be the input parent clock phandle for the clock.
>>>>>> +- clock-mult: defines the multiplication factor of the output clock frequency
>>>>>> +  wrt. the input clock frequency.
>>>>>> +- clock-div: defines the division factor of the output clock frequency wrt.
>>>>>> +  the input clock frequency.
>>>>>> +
>>>>>> +Example:
>>>>>> +cpu_clk: clkdiv_cpu {	/* CPU clock derived from pll0. 1/2 of pll frequency */
>>>>>> +	compatible = "fixed-factor-clkdiv";
>>>>>> +	#clock-cells = <0>;
>>>>>> +	clocks = <&pll0>;
>>>>>> +	clock-mult = <1>;
>>>>>> +	clock-div = <2>;
>>>>>> +	clock-output-names = "cpu_clk";
>>>>>> +};
>>>>>> diff --git a/drivers/clk/clk-fixed-factor.c b/drivers/clk/clk-fixed-factor.c
>>>>>> index 1ef271e..85e45f1 100644
>>>>>> --- a/drivers/clk/clk-fixed-factor.c
>>>>>> +++ b/drivers/clk/clk-fixed-factor.c
>>>>>> @@ -11,6 +11,7 @@
>>>>>>  #include <linux/clk-provider.h>
>>>>>>  #include <linux/slab.h>
>>>>>>  #include <linux/err.h>
>>>>>> +#include <linux/of.h>
>>>>>>  
>>>>>>  /*
>>>>>>   * DOC: basic fixed multiplier and divider clock that cannot gate
>>>>>> @@ -96,3 +97,34 @@ struct clk *clk_register_fixed_factor(struct device *dev, const char *name,
>>>>>>  
>>>>>>  	return clk;
>>>>>>  }
>>>>>> +
>>>>>> +#ifdef CONFIG_OF
>>>>>> +/**
>>>>>> + * of_fixed_factor_clkdiv_setup() - Set up simple fixed factor clock divider
>>>>>> + */
>>>>>> +void of_fixed_factor_clkdiv_setup(struct device_node *node)
>>>>>> +{
>>>>>> +	struct clk *clk;
>>>>>> +	const char *clk_name = node->name;
>>>>>> +	const char *parent_name;
>>>>>> +	u32 mult, div;
>>>>>> +
>>>>>> +	if (of_property_read_u32(node, "clock-mult", &mult))
>>>>>> +		return;
>>>>>> +
>>>>>> +	if (of_property_read_u32(node, "clock-div", &div))
>>>>>> +		return;
>>>>>> +
>>>>>> +	parent_name = of_clk_get_parent_name(node, 0);
>>>>>> +
>>>>>> +	of_property_read_string(node, "clock-output-names", &clk_name);
>>>>>> +
>>>>>> +	clk = clk_register_fixed_factor(NULL, clk_name, parent_name, 0,
>>>>>> +					mult, div);
>>>>>> +	if (!IS_ERR(clk))
>>>>>> +		of_clk_add_provider(node, of_clk_src_simple_get, clk);
>>>>>> +}
>>>>>> +EXPORT_SYMBOL_GPL(of_fixed_factor_clkdiv_setup);
>>>>>> +CLK_OF_DECLARE(fixed_clkdiv, "fixed-factor-clkdiv",
>>>>>> +		of_fixed_factor_clkdiv_setup);
>>>>>> +#endif
>>>>>> diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
>>>>>> index 7f197d7..d4937cf 100644
>>>>>> --- a/include/linux/clk-provider.h
>>>>>> +++ b/include/linux/clk-provider.h
>>>>>> @@ -184,6 +184,7 @@ struct clk *clk_register_fixed_rate(struct device *dev, const char *name,
>>>>>>  		unsigned long fixed_rate);
>>>>>>  
>>>>>>  void of_fixed_clk_setup(struct device_node *np);
>>>>>> +void of_fixed_factor_clkdiv_setup(struct device_node *node);
>>>>>>  
>>>>>>  /**
>>>>>>   * struct clk_gate - gating clock
>>>>>>
>>>>>
>>>>>
>>>>> -- 
>>>>> Gregory Clement, Free Electrons
>>>>> Kernel, drivers, real-time and embedded Linux
>>>>> development, consulting, training and support.
>>>>> http://free-electrons.com
>>>>
>>>> -- 
>>>>   Christian Ruppert              ,          <christian.ruppert at abilis.com>
>>>>                                 /|
>>>>   Tel: +41/(0)22 816 19-42     //|                 3, Chemin du Pr?-Fleuri
>>>>                              _// | bilis Systems   CH-1228 Plan-les-Ouates
>>>
>>
>>
>> -- 
>> Gregory Clement, Free Electrons
>> Kernel, drivers, real-time and embedded Linux
>> development, consulting, training and support.
>> http://free-electrons.com
> 


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From horms at verge.net.au  Fri Apr 12 03:06:21 2013
From: horms at verge.net.au (Simon Horman)
Date: Fri, 12 Apr 2013 16:06:21 +0900
Subject: [V2 patch 01/19] ARM: shmobile: cpuidle: remove
 shmobile_enter_wfi function
In-Reply-To: <5167ADF1.50401@linaro.org>
References: <1365712969-7541-1-git-send-email-daniel.lezcano@linaro.org>
 <1365712969-7541-2-git-send-email-daniel.lezcano@linaro.org>
 <20130412004425.GD24461@verge.net.au> <5167ADF1.50401@linaro.org>
Message-ID: <20130412070619.GA21350@verge.net.au>

On ?,  4? 12, 2013 at 08:47:13?? +0200, Daniel Lezcano wrote:
> On 04/12/2013 02:44 AM, Simon Horman wrote:
> > On Thu, Apr 11, 2013 at 10:42:31PM +0200, Daniel Lezcano wrote:
> >> Remove the shmobile_enter_wfi function which is the same as the
> >> common WFI enter function from the arm cpuidle driver defined
> >> with the ARM_CPUIDLE_WFI_STATE macro.
> > Should this patch also make shmobile_enter_wfi static in
> > arch/arm/mach-shmobile/cpuidle.c ?
> 
> Hum, no :)

Ok, that was my other idea :^)

> Actually, the function was removed because it was expected to be not
> longer used. I missed the cpuidle driver in the pm-sh7372.c file and the
> function declaration in the header file.
> > Also, I have a slight preference for the patch to be split into two.
> > 1. A patch to remove usage of shmobile_enter_wfi from the sh7372 SoC.
> > 2. A patch to remove shmobile_enter_wfi. from common.h
> >    (and make it static?).
> 
> Ok, regarding my answer above, do you still want two patches for this ?

Yes please.


From thierry.reding at avionic-design.de  Fri Apr 12 03:06:35 2013
From: thierry.reding at avionic-design.de (Thierry Reding)
Date: Fri, 12 Apr 2013 09:06:35 +0200
Subject: [PATCH 17/30] pwm: samsung: repair the worst MMIO abuses
In-Reply-To: <1365638712-1028578-18-git-send-email-arnd@arndb.de>
References: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
 <1365638712-1028578-18-git-send-email-arnd@arndb.de>
Message-ID: <20130412070635.GA16956@avionic-0098.mockup.avionic-design.de>

On Thu, Apr 11, 2013 at 02:04:59AM +0200, Arnd Bergmann wrote:
> The Samsung PWM driver uses "magic" pointers that are mapped
> at boot time to point its MMIO registers. This fails horribly
> with a multiplatform kernel, which can not rely on platform
> specific header files to contain the right values, aside from
> this being a really bad idea in general.
> 
> This changes the driver to at least pass an __iomem token
> around in the device structure to dereference that. Fixing
> the platform code is much harder, so we'll leave that
> until we have a DT binding for pwm-samsung, which may require
> other changes in this area. Since we are already touching
> every MMIO accessor in this driver, let's also use the
> proper readl_relaxed variant rather than __raw_readl.
> 
> Tomasz Figa has a set of patches to clean this up in a proper
> way, but that might be too late for 3.10.

Joonyoung Shim (Cc'ed) posted a driver for Exynos back in December. I
had a few comments on it but never saw an updated version. Is Tomasz'
work based on that patch?

Given that this patch solves a real problem and doesn't make things any
worse, I think it's okay to use it temporarily until Tomasz has had time
to finish up the proper driver, so:

Acked-by: Thierry Reding <thierry.reding at avionic-design.de>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130412/30629483/attachment.sig>

From shawn.guo at linaro.org  Fri Apr 12 03:11:26 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Fri, 12 Apr 2013 15:11:26 +0800
Subject: [PATCH 04/18] ARM: imx: cpuidle: create separate drivers for
 imx5/imx6
In-Reply-To: <5167B0AC.2000308@linaro.org>
References: <1365603743-5618-1-git-send-email-daniel.lezcano@linaro.org>
 <1365603743-5618-5-git-send-email-daniel.lezcano@linaro.org>
 <20130412060527.GA16494@S2101-09.ap.freescale.net>
 <5167B0AC.2000308@linaro.org>
Message-ID: <20130412071124.GL16970@S2101-09.ap.freescale.net>

On Fri, Apr 12, 2013 at 08:58:52AM +0200, Daniel Lezcano wrote:
> On 04/12/2013 08:05 AM, Shawn Guo wrote:
> > On Wed, Apr 10, 2013 at 04:22:09PM +0200, Daniel Lezcano wrote:
> >> The code intializes the cpuidle driver at different places.
> >> The cpuidle driver for :
> >>   * imx5 : is in the pm-imx5.c, the init function is in cpuidle.c
> >>   * imx6 : is in cpuidle-imx6q.c, the init function is in cpuidle.c
> >>            and cpuidle-imx6q.c
> >>
> >> Instead of having the cpuidle code spread across different files,
> >> let's write a driver for each SoC and make the code similar.
> >>
> >> That implies some code duplication but that will be fixed with the
> >> next patches which consolidate the initialization for all the drivers.
> >>
> > IMO, this is unnecessary churn.  I agree that we can have cpuidle-imx5.c
> > instead of carrying imx5 cpuidle code in pm-imx5.c.  But removing
> > cpuidle.c and duplicating what imx_cpuidle_init() does into imx5 and
> > imx6q driver is a step backward to me.
> > I suggest simply merging this patch into "[PATCH 18/18] ARM: imx:
> > cpuidle: use init/exit common routine"
> 
> Yes, I am aware that can can look weird but that was to have the
> different steps to reach the common register function.
> If I merge this patch with the patch 18, I am afraid the modification
> won't be obvious to the one who will read the patch later (eg. for a git
> bisect).
> 
> It is quite easy to fold the patches, but with the comment above do you
> still want me to do that ?

You can have a separate patch introducing cpuidle-imx5.c, but please do
not duplicate what imx_cpuidle_init() does into cpuidle-imx5.c and
cpuidle-imx6q.c.

Shawn



From daniel.lezcano at linaro.org  Fri Apr 12 03:11:33 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Fri, 12 Apr 2013 09:11:33 +0200
Subject: [V2 patch 01/19] ARM: shmobile: cpuidle: remove shmobile_enter_wfi
 function
In-Reply-To: <20130412070619.GA21350@verge.net.au>
References: <1365712969-7541-1-git-send-email-daniel.lezcano@linaro.org>
 <1365712969-7541-2-git-send-email-daniel.lezcano@linaro.org>
 <20130412004425.GD24461@verge.net.au> <5167ADF1.50401@linaro.org>
 <20130412070619.GA21350@verge.net.au>
Message-ID: <5167B3A5.60408@linaro.org>

On 04/12/2013 09:06 AM, Simon Horman wrote:
> On ?,  4? 12, 2013 at 08:47:13?? +0200, Daniel Lezcano wrote:
>> On 04/12/2013 02:44 AM, Simon Horman wrote:
>>> On Thu, Apr 11, 2013 at 10:42:31PM +0200, Daniel Lezcano wrote:
>>>> Remove the shmobile_enter_wfi function which is the same as the
>>>> common WFI enter function from the arm cpuidle driver defined
>>>> with the ARM_CPUIDLE_WFI_STATE macro.
>>> Should this patch also make shmobile_enter_wfi static in
>>> arch/arm/mach-shmobile/cpuidle.c ?
>>
>> Hum, no :)
> 
> Ok, that was my other idea :^)
> 
>> Actually, the function was removed because it was expected to be not
>> longer used. I missed the cpuidle driver in the pm-sh7372.c file and the
>> function declaration in the header file.
>>> Also, I have a slight preference for the patch to be split into two.
>>> 1. A patch to remove usage of shmobile_enter_wfi from the sh7372 SoC.
>>> 2. A patch to remove shmobile_enter_wfi. from common.h
>>>    (and make it static?).
>>
>> Ok, regarding my answer above, do you still want two patches for this ?
> 
> Yes please.

Ok, thanks for the review.

  -- Daniel

> --
> To unsubscribe from this list: send the line "unsubscribe linux-pm" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From daniel.lezcano at linaro.org  Fri Apr 12 03:12:40 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Fri, 12 Apr 2013 09:12:40 +0200
Subject: [PATCH 04/18] ARM: imx: cpuidle: create separate drivers for
 imx5/imx6
In-Reply-To: <20130412071124.GL16970@S2101-09.ap.freescale.net>
References: <1365603743-5618-1-git-send-email-daniel.lezcano@linaro.org>
 <1365603743-5618-5-git-send-email-daniel.lezcano@linaro.org>
 <20130412060527.GA16494@S2101-09.ap.freescale.net>
 <5167B0AC.2000308@linaro.org>
 <20130412071124.GL16970@S2101-09.ap.freescale.net>
Message-ID: <5167B3E8.2020007@linaro.org>

On 04/12/2013 09:11 AM, Shawn Guo wrote:
> On Fri, Apr 12, 2013 at 08:58:52AM +0200, Daniel Lezcano wrote:
>> On 04/12/2013 08:05 AM, Shawn Guo wrote:
>>> On Wed, Apr 10, 2013 at 04:22:09PM +0200, Daniel Lezcano wrote:
>>>> The code intializes the cpuidle driver at different places.
>>>> The cpuidle driver for :
>>>>   * imx5 : is in the pm-imx5.c, the init function is in cpuidle.c
>>>>   * imx6 : is in cpuidle-imx6q.c, the init function is in cpuidle.c
>>>>            and cpuidle-imx6q.c
>>>>
>>>> Instead of having the cpuidle code spread across different files,
>>>> let's write a driver for each SoC and make the code similar.
>>>>
>>>> That implies some code duplication but that will be fixed with the
>>>> next patches which consolidate the initialization for all the drivers.
>>>>
>>> IMO, this is unnecessary churn.  I agree that we can have cpuidle-imx5.c
>>> instead of carrying imx5 cpuidle code in pm-imx5.c.  But removing
>>> cpuidle.c and duplicating what imx_cpuidle_init() does into imx5 and
>>> imx6q driver is a step backward to me.
>>> I suggest simply merging this patch into "[PATCH 18/18] ARM: imx:
>>> cpuidle: use init/exit common routine"
>>
>> Yes, I am aware that can can look weird but that was to have the
>> different steps to reach the common register function.
>> If I merge this patch with the patch 18, I am afraid the modification
>> won't be obvious to the one who will read the patch later (eg. for a git
>> bisect).
>>
>> It is quite easy to fold the patches, but with the comment above do you
>> still want me to do that ?
> 
> You can have a separate patch introducing cpuidle-imx5.c, but please do
> not duplicate what imx_cpuidle_init() does into cpuidle-imx5.c and
> cpuidle-imx6q.c.

Sure.

Thanks !

  -- Daniel


-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From b35083 at freescale.com  Fri Apr 12 02:57:02 2013
From: b35083 at freescale.com (Jingchang Lu)
Date: Fri, 12 Apr 2013 14:57:02 +0800
Subject: [PATCH 0/3] ARM: add Freescale Vybrid family platform and development
 board support
Message-ID: <1365749825-20601-1-git-send-email-b35083@freescale.com>

Freescale Vybrid family microprocessors are built on
an asymmetrical-multiprocessing architecture using ARM Cortex-A5
and Cortex-M4. These series contain the support for MVF600 Soc and
Vybrid Tower development board.

----------------------------------------------------------------
Jingchang Lu (3):
	ARM/MVF600: add Vybrid Family platform support
	ARM:DTS:MVF600: add basic device tree source
	pinctrl: add MVF pinctrl driver

 Documentation/devicetree/bindings/pinctrl/fsl,mvf-pinctrl.txt |  825 ++++++++++++
 arch/arm/boot/dts/imx-mvf600.dtsi                             |  442 +++++++
 arch/arm/boot/dts/imx-mvf600twr.dts                           |   82 ++
 arch/arm/mach-imx/Kconfig                                     |   39 +
 arch/arm/mach-imx/Makefile                                    |    4 +
 arch/arm/mach-imx/Makefile.boot                               |    4 +
 arch/arm/mach-imx/clk-mvf.c                                   |  320 +++++
 arch/arm/mach-imx/common.h                                    |    3 +
 arch/arm/mach-imx/mach-mvf600.c                               |  121 ++
 arch/arm/mach-imx/pit.c                                       |  254 ++++
 drivers/pinctrl/Kconfig                                       |    8 +
 drivers/pinctrl/Makefile                                      |    1 +
 drivers/pinctrl/pinctrl-mvf.c                                 | 2042 +++++++++++++++++++++++++++++
 13 files changed, 4145 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pinctrl/fsl,mvf-pinctrl.txt
 create mode 100644 arch/arm/boot/dts/imx-mvf600.dtsi
 create mode 100644 arch/arm/boot/dts/imx-mvf600twr.dts
 create mode 100644 arch/arm/mach-imx/clk-mvf.c
 create mode 100644 arch/arm/mach-imx/mach-mvf600.c
 create mode 100644 arch/arm/mach-imx/pit.c
 create mode 100644 drivers/pinctrl/pinctrl-mvf.c




From b35083 at freescale.com  Fri Apr 12 02:57:04 2013
From: b35083 at freescale.com (Jingchang Lu)
Date: Fri, 12 Apr 2013 14:57:04 +0800
Subject: [PATCH 2/3] ARM:DTS:MVF600: add basic device tree source
In-Reply-To: <1365749825-20601-1-git-send-email-b35083@freescale.com>
References: <1365749825-20601-1-git-send-email-b35083@freescale.com>
Message-ID: <1365749825-20601-3-git-send-email-b35083@freescale.com>

This patch adds basic device tree source for Freescale
Vybrid Family platform and Tower development board.

Signed-off-by: Xiaochun Li <b41219 at freescale.com>
Signed-off-by: Jingchang Lu <b35083 at freescale.com>
---
 arch/arm/boot/dts/imx-mvf600.dtsi   | 442 ++++++++++++++++++++++++++++++++++++
 arch/arm/boot/dts/imx-mvf600twr.dts |  82 +++++++
 2 files changed, 524 insertions(+)
 create mode 100644 arch/arm/boot/dts/imx-mvf600.dtsi
 create mode 100644 arch/arm/boot/dts/imx-mvf600twr.dts

diff --git a/arch/arm/boot/dts/imx-mvf600.dtsi b/arch/arm/boot/dts/imx-mvf600.dtsi
new file mode 100644
index 0000000..3a534c6
--- /dev/null
+++ b/arch/arm/boot/dts/imx-mvf600.dtsi
@@ -0,0 +1,442 @@
+/*
+ * Copyright 2013 Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+ */
+
+/include/ "skeleton.dtsi"
+
+/ {
+	aliases {
+		serial0 = &uart1;
+		serial1 = &uart2;
+		serial2 = &uart3;
+		serial3 = &uart4;
+		serial4 = &uart5;
+		serial5 = &uart6;
+		gpio0 = &gpio1;
+		gpio1 = &gpio2;
+		gpio2 = &gpio3;
+		gpio3 = &gpio4;
+		gpio4 = &gpio5;
+	};
+
+
+	clocks {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		ckil {
+			compatible = "fsl,mvf-ckil", "fixed-clock";
+			clock-frequency = <32768>;
+		};
+
+		ckih1 {
+			compatible = "fsl,mvf-ckih1", "fixed-clock";
+			clock-frequency = <0>;
+		};
+
+		osc {
+			compatible = "fsl,mvf-osc", "fixed-clock";
+			clock-frequency = <24000000>;
+		};
+	};
+
+
+	soc {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		compatible = "simple-bus";
+		interrupt-parent = <&intc>;
+		ranges;
+
+		aips0: aips-bus at 40000000 { /* AIPS0 */
+			compatible = "fsl,aips-bus", "simple-bus";
+			#address-cells = <1>;
+			#size-cells = <1>;
+			interrupt-parent = <&intc>;
+			reg = <0x40000000 0x70000>;
+			ranges;
+
+			mscm: mscm at 40001000 {
+				compatible = "fsl,mvf-mscm";
+				reg = <0x40001000 0x1000>;
+			};
+
+			intc: interrupt-controller at 40002000 {
+				compatible = "arm,cortex-a9-gic";
+				#interrupt-cells = <3>;
+				#address-cells = <1>;
+				#size-cells = <1>;
+				interrupt-controller;
+				reg = <0x40003000 0x1000>,
+				      <0x40002100 0x100>;
+			};
+
+			L2: l2-cache at 40006000 {
+				compatible = "arm,pl310-cache";
+				reg = <0x40006000 0x1000>;
+				interrupts = <0 6 0x04>;
+				cache-unified;
+				cache-level = <2>;
+			};
+
+			uart1: serial at 40027000 { /* UART0 */
+				compatible = "fsl,mvf-uart";
+				reg = <0x40027000 0x1000>;
+				interrupts = <0 61 0x00>;
+				clocks = <&clks 34>;
+				clock-names = "ipg";
+				status = "disabled";
+			};
+
+			uart2: serial at 40028000 { /* UART1 */
+				compatible = "fsl,mvf-uart";
+				reg = <0x40028000 0x1000>;
+				interrupts = <0 62 0x04>;
+				clocks = <&clks 34>;
+				clock-names = "ipg";
+				status = "disabled";
+			};
+
+			uart3: serial at 40029000 { /* UART2 */
+				compatible = "fsl,mvf-uart";
+				reg = <0x40029000 0x1000>;
+				interrupts = <0 63 0x04>;
+				clocks = <&clks 34>;
+				clock-names = "ipg";
+				status = "disabled";
+			};
+
+			uart4: serial at 4002a000 { /* UART3 */
+				compatible = "fsl,mvf-uart";
+				reg = <0x4002a000 0x1000>;
+				interrupts = <0 64 0x04>;
+				clocks = <&clks 34>;
+				clock-names = "ipg";
+				status = "disabled";
+			};
+
+			pit:pit at 40037000 {
+				compatible = "fsl,mvf-pit";
+				reg = <0x40037000 0x1000>;
+				interrupts = <0 39 0x04>;
+			};
+
+			wdog at 4003e000 {
+				compatible = "fsl,mvf-wdt";
+				reg = <0x4003e000 0x1000>;
+			};
+
+			qspi0: quadspi at 40044000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "fsl,mvf-qspi";
+				reg = <0x40044000 0x1000>;
+				interrupts = <0 24 0x04>;
+				status = "disabled";
+			};
+
+			pinctrl1: iomuxc at 40047000 {
+				compatible = "fsl,mvf-iomuxc";
+				reg = <0x40047000 0x2000>;
+				#gpio-range-cells = <2>;
+
+				/* iomux setting */
+				esdhc1 {
+					pinctrl_esdhc1_1: esdhc1grp_1 {
+						fsl,pins = <
+						85 0x5031ef /* PTA24__SDHC1_CLK */
+						91 0x5031ef /* PTA25__SDHC1_CMD */
+						96 0x5031ef /* PTA26__SDHC1_DAT0 */
+						101 0x5031ef /* PTA27__SDHC1_DAT1 */
+						108 0x5031ef /* PTA28__SDHC1_DAT2 */
+						115 0x5031ef /* PTA29__SDHC1_DAT3 */
+						776 0x219d /* PTA7__SDHC1_SW_CD */
+					>;
+					};
+				};
+				i2c0 {
+					pinctrl_i2c0_1: i2c0grp_1 {
+						fsl,pins = <
+						226 0x2030d3 /* PTB14__I2C0_SCL */
+						231 0x2030d3 /* PTB15__I2C0_SDA */
+						>;
+					};
+				};
+				dspi0 {
+					pinctrl_dspi0_1: dspi0grp_1 {
+						fsl,pins = <
+						247 0x101182 /* PTB19__DSPI0_PCS0 */
+						250 0x101181 /* PTB20__DSPI0_SIN */
+						254 0x101182 /* PTB21__DSPI0_SOUT */
+						259 0x101182 /* PTB22__DSPI0_SCK */
+						>;
+					};
+				};
+				fec0 {
+					pinctrl_fec0_1: fec0grp_1 {
+						fsl,pins = <
+						2 0x2030d1 /* PTA6__RMII_CLKIN */
+						262 0x1030d2 /* PTC0__RMII0_MDC */
+						270 0x1030d3 /* PTC1__RMII0_MDIO */
+						278 0x1030d1 /* PTC2__RMII0_CRS_DV */
+						285 0x1030d1 /* PTC3__RMII0_RXD1 */
+						292 0x1030d1 /* PTC4__RMII0_RXD0 */
+						300 0x1030d1 /* PTC5__RMII0_RXER */
+						308 0x1030d2 /* PTC6__RMII0_TXD1 */
+						315 0x1030d2 /* PTC7__RMII0_TXD0 */
+						321 0x1030d2 /* PTC8__RMII0_TXEN */
+						>;
+					};
+				};
+				fec1 {
+					pinctrl_fec1_1: fec1grp_1 {
+						fsl,pins = <
+						326 0x1030d2 /* PTC9__RMII1_MDC */
+						331 0x1030d3 /* PTC10__RMII1_MDIO */
+						336 0x1030d1 /* PTC11__RMII1_CRS_DV */
+						341 0x1030d1 /* PTC12__RMII1_RXD1 */
+						346 0x1030d1 /* PTC13__RMII1_RXD0 */
+						351 0x1030d1 /* PTC14__RMII1_RXER */
+						358 0x1030d2 /* PTC15__RMII1_TXD1 */
+						365 0x1030d2/* PTC16__RMII1_TXD0 */
+						372 0x1030d2/* PTC17__RMII1_TXEN */
+						>;
+					};
+				};
+				sai2 {
+					pinctrl_sai2_1: sai2grp_1 {
+						fsl,pins = <
+						35 0x5002ed /* PTA16_SAI2_TX_BCLK */
+						51 0x5002ee /* PTA18_SAI2_TX_DATA */
+						59 0x5002ed /* PTA19_SAI2_TX_SYNC */
+						69 0x5002ed /* PTA21_SAI2_RX_BCLK */
+						74 0x5002ed /* PTA22_SAI2_RX_DATA */
+						79 0x5002ed /* PTA23_SAI2_RX_SYNC */
+						244 0x2002ed /* PTB18_EXT_AUDIO_MCLK */
+						>;
+					};
+				};
+				dcu0 {
+					pinctrl_dcu0_1: dcu0grp_1 {
+						fsl,pins = <
+						191 0x42 /* PTB8_LCD_ENABLE */
+						647 0x100042 /* PTE0_DCU0_HSYNC */
+						652 0x100042 /* PTE1_DCU0_VSYNC */
+						657 0x100042 /* PTE2_DCU0_PCLK */
+						665 0x100042 /* PTE4_DCU0_DE */
+						669 0x100042 /* PTE5_DCU0_R0 */
+						673 0x100042 /* PTE6_DCU0_R1 */
+						677 0x100042 /* PTE7_DCU0_R2 */
+						682 0x100042 /* PTE8_DCU0_R3 */
+						687 0x100042 /* PTE9_DCU0_R4 */
+						692 0x100042 /* PTE10_DCU0_R5 */
+						697 0x100042 /* PTE11_DCU0_R6 */
+						702 0x100042 /* PTE12_DCU0_R7 */
+						708 0x100042 /* PTE13_DCU0_G0 */
+						712 0x100042 /* PTE14_DCU0_G1 */
+						716 0x100042 /* PTE15_DCU0_G2 */
+						721 0x100042 /* PTE16_DCU0_G3 */
+						725 0x100042 /* PTE17_DCU0_G4 */
+						729 0x100042 /* PTE18_DCU0_G5 */
+						733 0x100042 /* PTE19_DCU0_G6 */
+						738 0x100042 /* PTE20_DCU0_G7 */
+						744 0x100042 /* PTE21_DCU0_B0 */
+						747 0x100042 /* PTE22_DCU0_B1 */
+						750 0x100042 /* PTE23_DCU0_B2 */
+						754 0x100042 /* PTE24_DCU0_B3 */
+						758 0x100042 /* PTE25_DCU0_B4 */
+						762 0x100042 /* PTE26_DCU0_B5 */
+						766 0x100042 /* PTE27_DCU0_B6 */
+						771 0x100042 /* PTE28_DCU0_B7 */
+						>;
+					};
+				};
+				uart1 {
+					pinctrl_uart1_1: uart1grp_1 {
+						fsl,pins = <
+						163 0x2021a2 /* PTB4_UART1_TX */
+						171 0x2021a1 /* PTB5_UART1_RX */
+						>;
+					};
+				};
+				usbvbus {
+					pinctrl_usbvbus_1: usbvbusgrp_1 {
+						fsl,pins = <
+						32 0x20219c /* PTA24__USB0_VBUS_EN */
+						84 0x20219c /* PTA17__USB1_VBUS_EN */
+						>;
+					};
+				};
+				pwm0 {
+					pinctrl_pwm0_1: pwm0grp_1 {
+						fsl,pins = <
+						131 0x101582 /* PTB0_FTM0CH0 */
+						139 0x101582 /* PTB1_FTM0CH1 */
+						147 0x101582 /* PTB2_FTM0CH2 */
+						155 0x101582 /* PTB3_FTM0CH3 */
+						177 0x101582 /* PTB6_FTM0CH6 */
+						185 0x101582 /* PTB7_FTM0CH7 */
+						>;
+					};
+				};
+				pwm1 {
+					pinctrl_pwm1_1: pwm1grp_1 {
+						fsl,pins = <
+						197 0x101182 /* PTB9_FTM1CH1 */
+						>;
+					};
+				};
+				touchscreen0 {
+					pinctrl_ts0_1: ts0grp_1 {
+						fsl,pins = <
+						124 0x219d /* PTA31_TS_IRQ */
+						>;
+					};
+				};
+				qspi0 {
+					pinctrl_qspi0_1: qspi0grp_1 {
+						fsl,pins = <
+						483 0x10307b /* PTD0_QSPI0_A_SCK */
+						489 0x10307f /* PTD1_QSPI0_A_CS0 */
+						495 0x103073 /* PTD2_QSPI0_A_D3 */
+						502 0x103073 /* PTD3_QSPI0_A_D2 */
+						509 0x103073 /* PTD4_QSPI0_A_D1 */
+						515 0x10307b /* PTD5_QSPI0_A_D0 */
+						525 0x10307b /* PTD7_QSPI0_B_SCK */
+						530 0x10307f /* PTD8_QSPI0_B_CS0 */
+						536 0x103073 /* PTD9_QSPI0_B_D3 */
+						542 0x103073 /* PTD10_QSPI0_B_D2 */
+						547 0x103073 /* PTD11_QSPI0_B_D1 */
+						552 0x10307b /* PTD12_QSPI0_B_D0 */
+						>;
+					};
+				};
+
+			};
+
+			gpio1: gpio at 40049000 {
+				compatible = "fsl,mvf-gpio";
+				reg = <0x40049000 0x1000 0x400ff000 0x40>;
+				interrupts = <0 107 0x04>;
+				gpio-controller;
+				#gpio-cells = <2>;
+				interrupt-controller;
+				#interrupt-cells = <2>;
+				gpio-ranges = <&pinctrl1 0 32>;
+			};
+
+			gpio2: gpio at 4004a000 {
+				compatible = "fsl,mvf-gpio";
+				reg = <0x4004a000 0x1000 0x400ff040 0x40>;
+				interrupts = <0 108 0x04>;
+				gpio-controller;
+				#gpio-cells = <2>;
+				interrupt-controller;
+				#interrupt-cells = <2>;
+				gpio-ranges = <&pinctrl1 32 32>;
+			};
+
+			gpio3: gpio at 4004b000 {
+				compatible = "fsl,mvf-gpio";
+				reg = <0x4004b000 0x1000 0x400ff080 0x40>;
+				interrupts = <0 109 0x04>;
+				gpio-controller;
+				#gpio-cells = <2>;
+				interrupt-controller;
+				#interrupt-cells = <2>;
+				gpio-ranges = <&pinctrl1 64 32>;
+			};
+
+			gpio4: gpio at 4004c000 {
+				compatible = "fsl,mvf-gpio";
+				reg = <0x4004c000 0x1000 0x400ff0c0 0x40>;
+				interrupts = <0 110 0x04>;
+				gpio-controller;
+				#gpio-cells = <2>;
+				interrupt-controller;
+				#interrupt-cells = <2>;
+				gpio-ranges = <&pinctrl1 96 32>;
+			};
+
+			gpio5: gpio at 4004d000 {
+				compatible = "fsl,mvf-gpio";
+				reg = <0x4004d000 0x1000 0x400ff100 0x40>;
+				interrupts = <0 111 0x04>;
+				gpio-controller;
+				#gpio-cells = <2>;
+				interrupt-controller;
+				#interrupt-cells = <2>;
+				gpio-ranges = <&pinctrl1 128 7>;
+			};
+
+			anatop at 40050000 {
+				compatible = "fsl,mvf-anatop";
+				reg = <0x40050000 0x1000>;
+			};
+
+			clks: ccm at 4006b000 {
+				compatible = "fsl,mvf-ccm";
+				reg = <0x4006b000 0x1000>;
+				#clock-cells = <1>;
+			};
+
+		};
+
+		aips1: aips-bus at 40080000 { /* AIPS1 */
+			compatible = "fsl,aips-bus", "simple-bus";
+			#address-cells = <1>;
+			#size-cells = <1>;
+			reg = <0x40080000 0x80000>;
+			ranges;
+
+			uart5: serial at 400a9000 { /* UART4 */
+				compatible = "fsl,mvf-uart";
+				reg = <0x400a9000 0x1000>;
+				interrupts = <0 65 0x04>;
+				clocks = <&clks 34>;
+				clock-names = "ipg";
+				status = "disabled";
+			};
+
+			uart6: serial at 400aa000 { /* UART5 */
+				compatible = "fsl,mvf-uart";
+				reg = <0x400aa000 0x1000>;
+				interrupts = <0 66 0x04>;
+				clocks = <&clks 34>;
+				clock-names = "ipg";
+				status = "disabled";
+			};
+
+			fec0: ethernet at 400d0000 {
+				compatible = "fsl,mvf-fec";
+				reg = <0x400d0000 0x1000>;
+				interrupts = <0 78 0x04>;
+				clocks = <&clks 52>, <&clks 52>, <&clks 52>;
+				clock-names = "ipg", "ahb", "ptp";
+			};
+
+			fec1: ethernet at 400d1000 {
+				compatible = "fsl,mvf-fec";
+				reg = <0x400d1000 0x1000>;
+				interrupts = <0 79 0x04>;
+				clocks = <&clks 52>, <&clks 52>, <&clks 52>;
+				clock-names = "ipg", "ahb", "ptp";
+			};
+
+		};
+	};
+};
diff --git a/arch/arm/boot/dts/imx-mvf600twr.dts b/arch/arm/boot/dts/imx-mvf600twr.dts
new file mode 100644
index 0000000..1a6b4a9
--- /dev/null
+++ b/arch/arm/boot/dts/imx-mvf600twr.dts
@@ -0,0 +1,82 @@
+/*
+ * Copyright 2013 Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+ */
+
+/dts-v1/;
+/include/ "imx-mvf600.dtsi"
+
+/ {
+	model = "MVF600 Tower Board";
+	compatible = "fsl,imx-mvf600-twr", "fsl,imx-mvf600";
+
+	chosen {
+		bootargs = "console=ttymxc1,115200";
+	};
+
+	memory {
+		reg = <0x80000000 0x8000000>;
+	};
+
+	clocks {
+		audio_clk {
+			compatible = "fsl,mvf-audio-ext-clk", "fixed-clock";
+			clock-frequency = <24576000>;
+		};
+		enet_clk {
+			compatible = "fsl,mvf-enet-ext-clk", "fixed-clock";
+			clock-frequency = <50000000>;
+		};
+	};
+};
+
+&uart2 { /* UART1 */
+	fsl,uart-fifo-mode;
+	status = "okay";
+};
+
+&fec0 {
+	phy-mode = "rmii";
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_fec0_1>;
+};
+
+&fec1 {
+	phy-mode = "rmii";
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_fec1_1>;
+};
+
+
+&qspi0 { /* QuadSPI0 */
+	fsl,spi-num-chipselects = <1>;
+	fsl,spi-flash-chipselects = <0>;
+	status = "okay";
+
+	flash: s25fl128s at 0 {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		compatible = "spansion,s25fl128s";
+		spi-max-frequency = <20000000>;
+		reg = <0>;
+		linux,modalias = "m25p80";
+		modal = "s25fl128s";
+		partition at 0 {
+			label = "s25fl128s";
+			reg = <0x0 0x1000000>;
+		};
+	};
+};
-- 
1.8.0




From b35083 at freescale.com  Fri Apr 12 02:57:03 2013
From: b35083 at freescale.com (Jingchang Lu)
Date: Fri, 12 Apr 2013 14:57:03 +0800
Subject: [PATCH 1/3] ARM/MVF600: add Vybrid Family platform support
In-Reply-To: <1365749825-20601-1-git-send-email-b35083@freescale.com>
References: <1365749825-20601-1-git-send-email-b35083@freescale.com>
Message-ID: <1365749825-20601-2-git-send-email-b35083@freescale.com>

This patch adds Freescale Vybrid Family platform core definitions,
core drivers including clock, period interrupt timer(PIT),
and DTS based machine support with MVF600 Tower development board.

Signed-off-by: Jingchang Lu <b35083 at freescale.com>
---
 arch/arm/mach-imx/Kconfig       |  39 +++++
 arch/arm/mach-imx/Makefile      |   4 +
 arch/arm/mach-imx/Makefile.boot |   4 +
 arch/arm/mach-imx/clk-mvf.c     | 320 ++++++++++++++++++++++++++++++++++++++++
 arch/arm/mach-imx/common.h      |   3 +
 arch/arm/mach-imx/mach-mvf600.c | 121 +++++++++++++++
 arch/arm/mach-imx/pit.c         | 254 +++++++++++++++++++++++++++++++
 7 files changed, 745 insertions(+)
 create mode 100644 arch/arm/mach-imx/clk-mvf.c
 create mode 100644 arch/arm/mach-imx/mach-mvf600.c
 create mode 100644 arch/arm/mach-imx/pit.c

diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index 4c9c6f9..173258b 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -55,6 +55,16 @@ config MXC_USE_EPIT
 	  uses the same clocks as the GPT. Anyway, on some systems the GPT
 	  may be in use for other purposes.
 
+config HAVE_PIT
+	bool
+
+config MXC_USE_PIT
+	bool "Use PIT"
+	depends on HAVE_PIT
+	help
+          Use PIT as the system timer on systems that have it
+	  such as Vybrid platform.
+
 config MXC_ULPI
 	bool
 
@@ -101,6 +111,9 @@ config ARCH_MX51
 config ARCH_MX53
 	bool
 
+config ARCH_MVF
+	bool
+
 config SOC_IMX1
 	bool
 	select ARCH_MX1
@@ -169,6 +182,24 @@ config	SOC_IMX51
 	select PINCTRL_IMX51
 	select SOC_IMX5
 
+config SOC_MVF
+	bool
+
+config SOC_MVF600
+	bool
+	select CPU_V7
+	select ARM_GIC
+	select COMMON_CLK
+	select ARCH_MVF
+	select SOC_MVF
+	select HAVE_PIT
+	select MXC_USE_PIT
+	select PINCTRL
+	select PINCTRL_MVF
+	select PL310_ERRATA_588369 if CACHE_PL310
+	select PL310_ERRATA_727915 if CACHE_PL310
+	select PL310_ERRATA_769419 if CACHE_PL310
+
 if ARCH_MULTI_V4T
 
 comment "MX1 platforms:"
@@ -828,6 +859,14 @@ config SOC_IMX6Q
 	help
 	  This enables support for Freescale i.MX6 Quad processor.
 
+config MACH_MVF600_TWR
+	bool "Vybrid MVF600 Tower support"
+	select SOC_MVF600
+
+	help
+          Include support for Freescale Vybrid Family Tower Board
+	  based on MVF600 SOC.
+
 endif
 
 source "arch/arm/mach-imx/devices/Kconfig"
diff --git a/arch/arm/mach-imx/Makefile b/arch/arm/mach-imx/Makefile
index c4ce090..e8502f1 100644
--- a/arch/arm/mach-imx/Makefile
+++ b/arch/arm/mach-imx/Makefile
@@ -26,6 +26,7 @@ obj-$(CONFIG_MXC_AVIC) += avic.o
 obj-$(CONFIG_IRAM_ALLOC) += iram_alloc.o
 obj-$(CONFIG_MXC_ULPI) += ulpi.o
 obj-$(CONFIG_MXC_USE_EPIT) += epit.o
+obj-$(CONFIG_MXC_USE_PIT) += pit.o
 obj-$(CONFIG_MXC_DEBUG_BOARD) += 3ds_debugboard.o
 obj-$(CONFIG_CPU_FREQ_IMX)    += cpufreq.o
 
@@ -112,4 +113,7 @@ obj-$(CONFIG_MACH_EUKREA_MBIMXSD51_BASEBOARD) += eukrea_mbimxsd51-baseboard.o
 obj-$(CONFIG_MACH_IMX51_DT) += imx51-dt.o
 obj-$(CONFIG_SOC_IMX53) += mach-imx53.o
 
+# Vybrid based machines
+obj-$(CONFIG_SOC_MVF600) += clk-mvf.o mach-mvf600.o
+
 obj-y += devices/
diff --git a/arch/arm/mach-imx/Makefile.boot b/arch/arm/mach-imx/Makefile.boot
index 41ba1bb..5551acf 100644
--- a/arch/arm/mach-imx/Makefile.boot
+++ b/arch/arm/mach-imx/Makefile.boot
@@ -33,3 +33,7 @@ initrd_phys-$(CONFIG_SOC_IMX53)	:= 0x70800000
 zreladdr-$(CONFIG_SOC_IMX6Q)	+= 0x10008000
 params_phys-$(CONFIG_SOC_IMX6Q)	:= 0x10000100
 initrd_phys-$(CONFIG_SOC_IMX6Q)	:= 0x10800000
+
+zreladdr-$(CONFIG_SOC_MVF)	:= 0x80008000
+params_phys-$(CONFIG_SOC_MVF)	:= 0x80000100
+initrd_phys-$(CONFIG_SOC_MVF)	:= 0x80800000
diff --git a/arch/arm/mach-imx/clk-mvf.c b/arch/arm/mach-imx/clk-mvf.c
new file mode 100644
index 0000000..fa2eca3
--- /dev/null
+++ b/arch/arm/mach-imx/clk-mvf.c
@@ -0,0 +1,320 @@
+/*
+ * Copyright 2012-2013 Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+ */
+
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/types.h>
+#include <linux/time.h>
+#include <linux/hrtimer.h>
+#include <linux/mm.h>
+#include <linux/errno.h>
+#include <linux/delay.h>
+#include <linux/clk.h>
+#include <linux/device.h>
+#include <linux/io.h>
+#include <linux/ioport.h>
+#include <linux/clkdev.h>
+#include <linux/regulator/consumer.h>
+#include <asm/div64.h>
+#include <linux/clk-provider.h>
+#include <linux/clk-private.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+
+#include "hardware.h"
+#include "common.h"
+#include "clk.h"
+
+
+#define CCM_CCR		(ccm_base + 0x00)
+#define CCM_CSR		(ccm_base + 0x04)
+#define CCM_CCSR		(ccm_base + 0x08)
+#define CCM_CACRR		(ccm_base + 0x0c)
+#define CCM_CSCMR1		(ccm_base + 0x10)
+#define CCM_CSCDR1		(ccm_base + 0x14)
+#define CCM_CSCDR2		(ccm_base + 0x18)
+#define CCM_CSCDR3		(ccm_base + 0x1c)
+#define CCM_CSCMR2		(ccm_base + 0x20)
+#define CCM_CSCDR4		(ccm_base + 0x24)
+#define CCM_CLPCR		(ccm_base + 0x2c)
+#define CCM_CISR		(ccm_base + 0x30)
+#define CCM_CIMR		(ccm_base + 0x34)
+#define CCM_CGPR		(ccm_base + 0x3c)
+#define CCM_CCGR0		(ccm_base + 0x40)
+#define CCM_CCGR1		(ccm_base + 0x44)
+#define CCM_CCGR2		(ccm_base + 0x48)
+#define CCM_CCGR3		(ccm_base + 0x4c)
+#define CCM_CCGR4		(ccm_base + 0x50)
+#define CCM_CCGR5		(ccm_base + 0x54)
+#define CCM_CCGR6		(ccm_base + 0x58)
+#define CCM_CCGR7		(ccm_base + 0x5c)
+#define CCM_CCGR8		(ccm_base + 0x60)
+#define CCM_CCGR9		(ccm_base + 0x64)
+#define CCM_CCGR10		(ccm_base + 0x68)
+#define CCM_CCGR11		(ccm_base + 0x6C)
+#define CCM_CMEOR0		(ccm_base + 0x70)
+#define CCM_CMEOR1		(ccm_base + 0x74)
+#define CCM_CMEOR2		(ccm_base + 0x78)
+#define CCM_CMEOR3		(ccm_base + 0x7C)
+#define CCM_CMEOR4		(ccm_base + 0x80)
+#define CCM_CMEOR5		(ccm_base + 0x84)
+#define CCM_CPPDSR		(ccm_base + 0x88)
+#define CCM_CCOWR		(ccm_base + 0x8C)
+#define CCM_CCPGR0		(ccm_base + 0x90)
+#define CCM_CCPGR1		(ccm_base + 0x94)
+#define CCM_CCPGR2		(ccm_base + 0x98)
+#define CCM_CCPGR3		(ccm_base + 0x9C)
+
+#define CCM_CCGRx_CGn_OFFSET(n)		(n * 2)
+
+#define PFD_528SYS_BASE		(anatop_base + 0x2B0)
+#define PFD_528_BASE		(anatop_base + 0x100)
+#define PFD_USB_BASE            (anatop_base + 0xF0) /* pll3 pfd definition */
+
+
+static void __iomem *anatop_base;
+static void __iomem *ccm_base;
+
+/* This is used multiple times */
+static const char const *fast_clk_sel[] = { "firc", "fxosc", };
+static const char const *slow_clk_sel[] = { "sirc", "sxosc", };
+static const char const *pll1_pfd_sel[] = {
+	"pll1_main", "pll1_pfd1", "pll1_pfd2", "pll1_pfd3", "pll1_pfd4",
+};
+static const char const *pll2_pfd_sel[] = {
+	"pll2_main", "pll2_pfd1", "pll2_pfd2", "pll2_pfd3", "pll2_pfd4",
+};
+static const char const *sys_clk_sel[] = {
+	"fast_clk", "slow_clk", "pll2_sw", "pll2_main", "pll1_sw", "pll3_main",
+};
+static const char const *ddr_clk_sel[] = { "pll2_pfd2", "sys_clk", };
+static const char const *rmii_clk_sel[] = {
+	"enet_ext", "audio_ext_clk", "enet_50m", "enet_25m",
+};
+static const char const *enet_ts_clk_sel[] = {
+	"enet_ext", "fxosc", "audio_ext_clk", "usb_clk", "enet_ts_clk",
+	"enet_25m", "enet_50m",
+};
+static const char const *esai_clk_sel[] = {
+	"audio_ext_clk", "mlb_clk", "spdif_rx_clk", "pll4_main_div",
+};
+static const char const *sai_clk_sel[] = {
+	"audio_ext_clk", "mlb_clk", "spdif_rx_clk", "pll4_main_div",
+};
+static const char const *nfc_clk_sel[] = {
+	"platform_bus", "pll1_pfd1", "pll3_pfd1", "pll3_pfd3",
+};
+static const char const *qspi_clk_sel[] = {
+	"pll3_main", "pll3_pfd4", "pll2_pfd4", "pll1_pfd4",
+};
+static const char const *esdhc_clk_sel[] = {
+	"pll3_main", "pll3_pfd3", "pll1_pfd3", "platform_bus",
+};
+static const char const *dcu_clk_sel[] = {
+	"pll1_pfd2", "pll3_main",
+};
+static const char const *gpu_clk_sel[] = { "pll2_pfd2", "pll3_pfd2", };
+static const char const *vadc_lk_sel[] = {
+	"pll6_main_div", "pll3_main_div", "pll3_main",
+};
+
+enum mvf_clks {
+	dummy, sirc, firc, sxosc, fxosc, slow_clk, fast_clk, audio_ext_clk,
+	enet_ext_clk, pll1_main_528m, pll1_pfd1_500m, pll1_pfd2_452m,
+	pll1_pfd3_396m, pll1_pfd4_528m, pll2_main_528m, pll2_pfd1_500m,
+	pll2_pfd2_396m, pll2_pfd3_339m, pll2_pfd4_413m, pll3_main_480m,
+	pll3_pfd1_308m, pll3_pfd2_332m, pll3_pfd3_298m, pll3_pfd4_320m,
+	pll4_main, pll5_main, pll6_main,
+	pll1_pfd_sw, pll2_pfd_sw, sys_clk_sw, ddr_clk_sw,
+	sys_bus_clk, platform_bus_clk, ipg_bus_clk,
+	uart0_clk_gate, uart1_clk_gate, uart2_clk_gate, uart3_clk_gate,
+	uart4_clk_gate, uart5_clk_gate, pit_clk_gate,
+	i2c0_clk_gate, i2c1_clk_gate, i2c2_clk_gate, i2c3_clk_gate,
+	ftm0_clk_gate, ftm1_clk_gate, ftm2_clk_gate, ftm3_clk_gate,
+	enet_50m, enet_25m, enet_clk_sw, enet_clk_gate, enet_ts_sw,
+	enet_ts_gate,
+	audio_ext_clk_gate, dspi_clk_gate, wdt_clk_gate,
+	esdhc0_clk_gate, esdhc1_clk_gate,
+	dcu0_clk_gate, dcu1_clk_gate,
+	sai0_clk_gate, sai1_clk_gate, sai2_clk_gate, sai3_clk_gate,
+	usbc0_clk_gate, usbc1_clk_gate,
+	qspi0_clk_sw, qspi0_clk_gate, qspi0_x4_div, qspi0_x2_div, qspi0_x1_div,
+	asrc_clk_gate,
+	caam_clk_gate,
+	gpu2d_clk_gate,
+	openvg_clk_gate,
+	clk_max
+};
+
+static struct clk *clk[clk_max];
+static struct clk_onecell_data clk_data;
+
+int __init mvf_clocks_init(void)
+{
+	struct device_node *np;
+	__iomem void *base;
+	int irq;
+
+	clk[dummy] = imx_clk_fixed("dummy", 0);
+	clk[sirc] = imx_clk_fixed("sirc", 32000); /* slow internal IRC */
+	clk[firc] = imx_clk_fixed("firc", 24000000);/* fast internal IRC */
+
+	for_each_compatible_node(np, NULL, "fixed-clock") {
+		u32 rate;
+
+		if (of_property_read_u32(np, "clock-frequency", &rate))
+			continue;
+		if (of_device_is_compatible(np, "fsl,mvf-ckil"))
+			clk[sxosc] = imx_clk_fixed("sxosc", rate);
+		else if (of_device_is_compatible(np, "fsl,mvf-osc"))
+			clk[fxosc] = imx_clk_fixed("fxosc", rate);
+		else if (of_device_is_compatible(np, "fsl,mvf-audio-ext-clk"))
+			clk[audio_ext_clk] =
+					imx_clk_fixed("audio_ext_clk", rate);
+		else if (of_device_is_compatible(np, "fsl,mvf-enet-ext-clk"))
+			clk[enet_ext_clk] = imx_clk_fixed("enet_ext", rate);
+	}
+
+	np = of_find_compatible_node(NULL, NULL, "fsl,mvf-anatop");
+	anatop_base = of_iomap(np, 0);
+	WARN_ON(!anatop_base);
+
+	np = of_find_compatible_node(NULL, NULL, "fsl,mvf-ccm");
+	ccm_base = of_iomap(np, 0);
+	WARN_ON(!ccm_base);
+
+	clk[slow_clk] = imx_clk_mux("slow_clk", CCM_CCSR, 4, 1,
+			slow_clk_sel, ARRAY_SIZE(slow_clk_sel));
+	clk[fast_clk] = imx_clk_mux("fast_clk", CCM_CCSR, 5, 1,
+			fast_clk_sel, ARRAY_SIZE(fast_clk_sel));
+
+	clk[pll1_main_528m] = imx_clk_fixed_factor("pll1_main",
+						"fast_clk", 22, 1);
+	clk[pll1_pfd1_500m] = imx_clk_pfd("pll1_pfd1", "pll1_main",
+						PFD_528SYS_BASE, 0);
+	clk[pll1_pfd2_452m] = imx_clk_pfd("pll1_pfd2", "pll1_main",
+						PFD_528SYS_BASE, 1);
+	clk[pll1_pfd3_396m] = imx_clk_pfd("pll1_pfd3", "pll1_main",
+						PFD_528SYS_BASE, 2);
+	clk[pll1_pfd4_528m] = imx_clk_pfd("pll1_pfd4", "pll1_main",
+						PFD_528SYS_BASE, 3);
+
+	clk[pll2_main_528m] = imx_clk_fixed_factor("pll2_main",
+						"fast_clk", 22, 1);
+	clk[pll2_pfd1_500m] = imx_clk_pfd("pll2_pfd1", "pll2_main",
+						PFD_528_BASE, 0);
+	clk[pll2_pfd2_396m] = imx_clk_pfd("pll2_pfd2", "pll2_main",
+						PFD_528_BASE, 1);
+	clk[pll2_pfd3_339m] = imx_clk_pfd("pll2_pfd3", "pll2_main",
+						PFD_528_BASE, 2);
+	clk[pll2_pfd4_413m] = imx_clk_pfd("pll2_pfd4", "pll2_main",
+						PFD_528_BASE, 3);
+
+	/* USB pll, 480Mhz */
+	clk[pll3_main_480m] = imx_clk_fixed_factor("usb_main",
+						"fast_clk", 20, 1);
+	/* Audio pll */
+	clk[pll4_main] = imx_clk_fixed_factor("audio_main", "fast_clk", 25, 1);
+	/* Enet pll, fixed to 50Mhz on Vybrid */
+	clk[pll5_main] = imx_clk_fixed_factor("pll5_main", "fast_clk", 125, 6);
+	clk[enet_50m] = imx_clk_fixed_factor("enet_50m", "pll5_main", 1, 10);
+	clk[enet_25m] = imx_clk_fixed_factor("enet_25m", "pll5_main", 1, 20);
+	/* Video pll: default 960Mhz */
+	clk[pll6_main] = imx_clk_fixed_factor("video_main", "fast_clk", 40, 1);
+
+	clk[pll1_pfd_sw] = imx_clk_mux("pll1_sw", CCM_CCSR, 16, 3,
+			pll1_pfd_sel, ARRAY_SIZE(pll1_pfd_sel));
+
+	clk[pll2_pfd_sw] = imx_clk_mux("pll2_sw", CCM_CCSR, 19, 3,
+			pll2_pfd_sel, ARRAY_SIZE(pll2_pfd_sel));
+
+	clk[sys_clk_sw] = imx_clk_mux("sys_sw", CCM_CCSR, 0, 3,
+			sys_clk_sel, ARRAY_SIZE(sys_clk_sel));
+
+	clk[ddr_clk_sw] = imx_clk_mux("ddr_sw", CCM_CCSR, 6, 1,
+			ddr_clk_sel, ARRAY_SIZE(ddr_clk_sel));
+
+	clk[sys_bus_clk] = imx_clk_divider("sys_bus", "sys_sw",
+						CCM_CACRR, 0, 3);
+	clk[platform_bus_clk] = imx_clk_divider("platform_bus", "sys_bus",
+						CCM_CACRR, 3, 3);
+	clk[ipg_bus_clk] = imx_clk_divider("ipg_bus", "platform_bus",
+						CCM_CACRR, 11, 2);
+
+	clk[qspi0_clk_sw] = imx_clk_mux("qspi0_sw", CCM_CSCMR1, 22, 2,
+					qspi_clk_sel, ARRAY_SIZE(qspi_clk_sel));
+	clk[qspi0_x4_div] = imx_clk_divider("qspi0_x4", "qspi0_sw",
+						CCM_CSCDR3, 0, 2);
+	clk[qspi0_x2_div] = imx_clk_divider("qspi0_x2", "qspi0_x4",
+						CCM_CSCDR3, 2, 1);
+	clk[qspi0_x1_div] = imx_clk_divider("qspi0_x1", "qspi0_x2",
+					CCM_CSCDR3, 3, 1);
+	clk[qspi0_clk_gate] = imx_clk_gate("qspi0_clk", "qspi0_x1",
+					CCM_CSCDR3, 4);
+
+	clk[enet_clk_sw] = imx_clk_mux("enet_sw", CCM_CSCMR2, 4, 2,
+				rmii_clk_sel, ARRAY_SIZE(rmii_clk_sel));
+	clk[enet_clk_gate] = imx_clk_gate("enet_clk", "enet_sw",
+				CCM_CSCDR1, 24);
+	clk[enet_ts_sw] = imx_clk_mux("enet_ts_sw", CCM_CSCMR2, 0, 3,
+				enet_ts_clk_sel, ARRAY_SIZE(enet_ts_clk_sel));
+	clk[enet_ts_gate] = imx_clk_gate("enet_ts_clk", "enet_ts_sw",
+				CCM_CSCDR1, 23);
+
+	clk[pit_clk_gate] = imx_clk_gate2("pit_clk", "ipg_bus", CCM_CCGR1,
+						CCM_CCGRx_CGn_OFFSET(7));
+	clk[uart0_clk_gate] = imx_clk_gate2("uart0_clk", "ipg_bus", CCM_CCGR0,
+						CCM_CCGRx_CGn_OFFSET(7));
+
+	/* Add the clocks to provider list */
+	clk_data.clks = clk;
+	clk_data.clk_num = ARRAY_SIZE(clk);
+	of_clk_add_provider(np, of_clk_src_onecell_get, &clk_data);
+
+	clk_register_clkdev(clk[pit_clk_gate], "mvf-pit", NULL);
+	clk_register_clkdev(clk[uart0_clk_gate], "mvf-uart", NULL);
+	clk_register_clkdev(clk[uart0_clk_gate], "mvf_uart.0", NULL);
+	clk_register_clkdev(clk[uart0_clk_gate], "mvf_uart.1", NULL);
+	clk_register_clkdev(clk[enet_clk_gate], "fec.0", NULL);
+	clk_register_clkdev(clk[enet_clk_gate], "fec.1", NULL);
+	clk_register_clkdev(clk[enet_clk_gate], "switch.0", NULL);
+	clk_register_clkdev(clk[qspi0_clk_gate], "qspi.0", NULL);
+
+	clk_set_parent(clk[qspi0_x4_div], clk[pll1_pfd4_528m]);
+	clk_set_rate(clk[qspi0_x4_div],
+			clk_get_rate(clk[qspi0_x4_div]->parent) / 2);
+	clk_set_rate(clk[qspi0_x2_div],
+			clk_get_rate(clk[qspi0_x2_div]->parent) / 2);
+	clk_set_rate(clk[qspi0_x1_div],
+			clk_get_rate(clk[qspi0_x1_div]->parent) / 2);
+
+
+	clk_prepare(clk[pit_clk_gate]);
+	clk_prepare(clk[uart0_clk_gate]);
+	clk_prepare(clk[enet_clk_gate]);
+
+	/* init system timer */
+	np = of_find_compatible_node(NULL, NULL, "fsl,mvf-pit");
+	base = of_iomap(np, 0);
+	WARN_ON(!base);
+	irq = irq_of_parse_and_map(np, 0);
+	pit_timer_init(base, irq);
+
+	return 0;
+}
diff --git a/arch/arm/mach-imx/common.h b/arch/arm/mach-imx/common.h
index 5bf4a97..dba5b10 100644
--- a/arch/arm/mach-imx/common.h
+++ b/arch/arm/mach-imx/common.h
@@ -41,6 +41,7 @@ extern void mx31_init_irq(void);
 extern void mx35_init_irq(void);
 extern void mx51_init_irq(void);
 extern void mx53_init_irq(void);
+extern void mvf_init_irq(void);
 extern void imx1_soc_init(void);
 extern void imx21_soc_init(void);
 extern void imx25_soc_init(void);
@@ -51,6 +52,7 @@ extern void imx51_soc_init(void);
 extern void imx51_init_late(void);
 extern void imx53_init_late(void);
 extern void epit_timer_init(void __iomem *base, int irq);
+extern void pit_timer_init(void __iomem *base, int irq);
 extern void mxc_timer_init(void __iomem *, int);
 extern int mx1_clocks_init(unsigned long fref);
 extern int mx21_clocks_init(unsigned long lref, unsigned long fref);
@@ -68,6 +70,7 @@ extern int mx31_clocks_init_dt(void);
 extern int mx51_clocks_init_dt(void);
 extern int mx53_clocks_init_dt(void);
 extern int mx6q_clocks_init(void);
+extern int mvf_clocks_init(void);
 extern struct platform_device *mxc_register_gpio(char *name, int id,
 	resource_size_t iobase, resource_size_t iosize, int irq, int irq_high);
 extern void mxc_set_cpu_type(unsigned int type);
diff --git a/arch/arm/mach-imx/mach-mvf600.c b/arch/arm/mach-imx/mach-mvf600.c
new file mode 100644
index 0000000..fa3b34c
--- /dev/null
+++ b/arch/arm/mach-imx/mach-mvf600.c
@@ -0,0 +1,121 @@
+/*
+ * Copyright 2012-2013 Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+ */
+
+#include <linux/types.h>
+#include <linux/sched.h>
+#include <linux/delay.h>
+#include <linux/pm.h>
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/irq.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+#include <linux/of_platform.h>
+#include <linux/init.h>
+#include <linux/clk.h>
+#include <linux/clkdev.h>
+#include <linux/platform_device.h>
+#include <linux/irqchip.h>
+#include <linux/irqchip/arm-gic.h>
+#include <asm/memory.h>
+#include <asm/irq.h>
+#include <asm/setup.h>
+#include <asm/mach-types.h>
+#include <asm/mach/arch.h>
+#include <asm/mach/time.h>
+#include <asm/hardware/cache-l2x0.h>
+#include <asm/system_misc.h>
+
+#include "common.h"
+#include "hardware.h"
+#include "mxc.h"
+
+
+void mvf_restart(char mode, const char *cmd)
+{
+	struct device_node *np;
+	void __iomem *wdog_base;
+
+	np = of_find_compatible_node(NULL, NULL, "fsl,mvf-wdt");
+	wdog_base = of_iomap(np, 0);
+	if (!wdog_base)
+		goto soft;
+
+	/* enable wdog */
+	writew_relaxed(1 << 2, wdog_base);
+
+	/* wait for reset to assert ... */
+	mdelay(500);
+
+	pr_err("Watchdog reset failed to assert reset\n");
+
+	/* delay to allow the serial port to show the message */
+	mdelay(50);
+
+soft:
+	/* we'll take a jump through zero as a poor second */
+	soft_restart(0);
+}
+
+static void __init mvf_init_machine(void)
+{
+	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
+}
+
+static void __init mvf_of_init_irq(void)
+{
+	struct device_node *np;
+	void __iomem *mscm_base;
+	int i;
+
+	l2x0_of_init(0, ~0UL);
+
+	np = of_find_compatible_node(NULL, NULL, "fsl,mvf-mscm");
+	mscm_base = of_iomap(np, 0);
+	if (!mscm_base)
+		return;
+
+	for (i = 0; i < 128; i++)
+		__raw_writew(1, mscm_base + 0x880 + 2 * i);
+
+	iounmap(mscm_base);
+
+	irqchip_init();
+}
+
+static void __init mvf_timer_init(void)
+{
+	mvf_clocks_init();
+}
+
+/*
+ * initialize __mach_desc_ data structure.
+ */
+static const char *mvf_dt_compat[] __initdata = {
+	"fsl,imx-mvf600",
+	NULL,
+};
+
+DT_MACHINE_START(VYBRID_VF6XX, "Freescale Vybrid Family (Device Tree)")
+	.init_irq	= mvf_of_init_irq,
+	.init_machine	= mvf_init_machine,
+	.init_time	= mvf_timer_init,
+	.dt_compat	= mvf_dt_compat,
+	.restart	= mvf_restart,
+MACHINE_END
diff --git a/arch/arm/mach-imx/pit.c b/arch/arm/mach-imx/pit.c
new file mode 100644
index 0000000..03f0037
--- /dev/null
+++ b/arch/arm/mach-imx/pit.c
@@ -0,0 +1,254 @@
+/*
+ *  Copyright 2012-2013 Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
+ * MA 02110-1301, USA.
+ */
+
+#include <linux/interrupt.h>
+#include <linux/irq.h>
+#include <linux/clockchips.h>
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <asm/mach/time.h>
+#include <asm/sched_clock.h>
+
+#include "hardware.h"
+#include "common.h"
+
+#define PITMCR		0x00
+#define PITLTMR64H	0xE0
+#define PITLTMR64L	0xE4
+
+#define PITOFFSET	0x120
+#define PITLDVAL	0x00
+#define PITCVAL		0x04
+#define PITTCTRL	0x08
+#define PITTFLG		0x0C
+
+/*
+ * Total 8 pit timers, each memory map occupy 0x10 Bytes
+ * get base offset for pit(n)
+ */
+#define PITOFFSETx(n)	(PITOFFSET + 0x10 * n)
+
+/* bit definitation */
+#define PITMCR_MDIS		(1 << 1)
+#define PITMCR_FRZ		(1 << 0)
+
+#define PITTCTRL_TEN		(1 << 0)
+#define PITTCTRL_TIE		(1 << 1)
+#define	PITCTRL_CHN		(1 << 2)
+
+#define PITTFLG_TIF		(1 << 0)
+
+static cycle_t pit_cnt;
+static struct clock_event_device clockevent_pit;
+static enum clock_event_mode clockevent_mode = CLOCK_EVT_MODE_UNUSED;
+
+static void __iomem *timer_base;
+static unsigned long pit_cycle_per_jiffy;
+
+static inline void pit_irq_disable(void)
+{
+	unsigned long val;
+
+	val = __raw_readl(timer_base + PITOFFSET + PITTCTRL);
+	val &= ~PITTCTRL_TIE;
+	__raw_writel(val, timer_base + PITOFFSET + PITTCTRL);
+}
+
+static inline void pit_irq_enable(void)
+{
+	unsigned long val;
+
+	val = __raw_readl(timer_base + PITOFFSET + PITTCTRL);
+	val |= PITTCTRL_TIE;
+	__raw_writel(val, timer_base + PITOFFSET + PITTCTRL);
+}
+
+static void pit_irq_acknowledge(void)
+{
+	__raw_writel(PITTFLG_TIF, timer_base + PITOFFSET + PITTFLG);
+}
+
+static cycle_t pit_read_clk(struct clocksource *cs);
+
+static void __iomem *sched_clock_reg;
+
+static unsigned int mvf_read_sched_clock(void)
+{
+	return __raw_readl(sched_clock_reg);
+}
+
+static int __init pit_clocksource_init(struct clk *pit_clk)
+{
+	unsigned int c = clk_get_rate(pit_clk);
+	void __iomem *reg = timer_base + PITOFFSET + PITCVAL;
+
+	sched_clock_reg = reg;
+
+	setup_sched_clock(mvf_read_sched_clock, 32, c);
+	return clocksource_mmio_init(timer_base + PITOFFSET + PITCVAL,
+					"pit", c, 200, 32, pit_read_clk);
+}
+
+/* clock event */
+
+static int pit_set_next_event(unsigned long evt,
+			      struct clock_event_device *unused)
+{
+	return 0;
+}
+
+static void pit_set_mode(enum clock_event_mode mode,
+				struct clock_event_device *evt)
+{
+	unsigned long flags;
+
+	local_irq_save(flags);
+
+	/* Disable interrupt in PIT module */
+	pit_irq_disable();
+
+	if (mode != clockevent_mode) {
+		/* Clear pending interrupt */
+		pit_irq_acknowledge();
+	}
+
+	/* Remember timer mode */
+	clockevent_mode = mode;
+	local_irq_restore(flags);
+
+	switch (mode) {
+	case CLOCK_EVT_MODE_PERIODIC:
+
+		__raw_writel(0, timer_base + PITOFFSET + PITTCTRL);
+		__raw_writel(pit_cycle_per_jiffy,
+				timer_base + PITOFFSET + PITLDVAL);
+		__raw_writel(PITTCTRL_TEN, timer_base + PITOFFSET + PITTCTRL);
+
+		pit_irq_enable();
+
+		break;
+	case CLOCK_EVT_MODE_ONESHOT:
+
+		local_irq_save(flags);
+		pit_irq_enable();
+		local_irq_restore(flags);
+		break;
+	case CLOCK_EVT_MODE_SHUTDOWN:
+	case CLOCK_EVT_MODE_UNUSED:
+	case CLOCK_EVT_MODE_RESUME:
+		/* Left event sources disabled, no more interrupts appear */
+		break;
+	}
+}
+
+/*
+ * IRQ handler for the timer
+ */
+static irqreturn_t pit_timer_interrupt(int irq, void *dev_id)
+{
+	struct clock_event_device *evt = &clockevent_pit;
+
+	pit_irq_acknowledge();
+
+	pit_cnt += pit_cycle_per_jiffy;
+
+	evt->event_handler(evt);
+
+	return IRQ_HANDLED;
+}
+
+static cycle_t pit_read_clk(struct clocksource *cs)
+{
+	unsigned long flags;
+	cycle_t cycles;
+	unsigned long pcntr;
+
+	local_irq_save(flags);
+	pcntr = __raw_readl(timer_base + PITOFFSET + PITCVAL);
+	cycles = pit_cnt;
+	local_irq_restore(flags);
+
+	return cycles + pit_cycle_per_jiffy - pcntr;
+}
+
+
+static struct irqaction pit_timer_irq = {
+	.name		= "MVF PIT Timer Tick",
+	.flags		= IRQF_DISABLED | IRQF_TIMER | IRQF_IRQPOLL,
+	.handler	= pit_timer_interrupt,
+};
+
+static struct clock_event_device clockevent_pit = {
+	.name		= "pit",
+	.features	= CLOCK_EVT_FEAT_PERIODIC,
+	.shift		= 32,
+	.set_mode	= pit_set_mode,
+	.set_next_event	= pit_set_next_event,
+	.rating		= 100,
+};
+
+static int __init pit_clockevent_init(struct clk *pit_clk)
+{
+	unsigned int c = clk_get_rate(pit_clk);
+
+	clockevent_pit.mult = div_sc(c, NSEC_PER_SEC,
+					clockevent_pit.shift);
+	clockevent_pit.max_delta_ns =
+			clockevent_delta2ns(0xfffffffe, &clockevent_pit);
+	clockevent_pit.min_delta_ns =
+			clockevent_delta2ns(0x800, &clockevent_pit);
+	clockevent_pit.cpumask = cpumask_of(0);
+	clockevents_register_device(&clockevent_pit);
+
+	return 0;
+}
+
+void __init pit_timer_init(void __iomem *base, int irq)
+{
+	struct clk *pit_clk;
+
+	pit_clk = clk_get_sys(NULL, "mvf-pit");
+	if (IS_ERR(pit_clk)) {
+		pr_err("Vybrid PIT timer: unable to get clk\n");
+		return;
+	}
+
+	clk_prepare_enable(pit_clk);
+
+	timer_base = base;
+
+	pit_cycle_per_jiffy = clk_get_rate(pit_clk)/(HZ);
+
+	/*
+	 * Initialise to a known state (all timers off, and timing reset)
+	 */
+	__raw_writel(0x0, timer_base + PITMCR);
+
+	__raw_writel(0, timer_base + PITOFFSET + PITTCTRL);
+	__raw_writel(0xffffffff, timer_base + PITOFFSET + PITLDVAL);
+	__raw_writel(PITTCTRL_TEN, timer_base + PITOFFSET + PITTCTRL);
+
+	/* init and register the timer to the framework */
+	pit_clocksource_init(pit_clk);
+
+	pit_clockevent_init(pit_clk);
+
+	/* Make irqs happen */
+	setup_irq(irq, &pit_timer_irq);
+}
-- 
1.8.0




From tomasz.figa at gmail.com  Fri Apr 12 03:46:00 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Fri, 12 Apr 2013 00:46:00 -0700 (PDT)
Subject: [PATCH 17/30] pwm: samsung: repair the worst MMIO abuses
In-Reply-To: <20130412070635.GA16956@avionic-0098.mockup.avionic-design.de>
References: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
 <1365638712-1028578-18-git-send-email-arnd@arndb.de>
 <20130412070635.GA16956@avionic-0098.mockup.avionic-design.de>
Message-ID: <1469653.nxt3obZ5EV@flatron>

On Friday 12 of April 2013 09:06:35 Thierry Reding wrote:
> On Thu, Apr 11, 2013 at 02:04:59AM +0200, Arnd Bergmann wrote:
> > The Samsung PWM driver uses "magic" pointers that are mapped
> > at boot time to point its MMIO registers. This fails horribly
> > with a multiplatform kernel, which can not rely on platform
> > specific header files to contain the right values, aside from
> > this being a really bad idea in general.
> > 
> > This changes the driver to at least pass an __iomem token
> > around in the device structure to dereference that. Fixing
> > the platform code is much harder, so we'll leave that
> > until we have a DT binding for pwm-samsung, which may require
> > other changes in this area. Since we are already touching
> > every MMIO accessor in this driver, let's also use the
> > proper readl_relaxed variant rather than __raw_readl.
> > 
> > Tomasz Figa has a set of patches to clean this up in a proper
> > way, but that might be too late for 3.10.
> 
> Joonyoung Shim (Cc'ed) posted a driver for Exynos back in December. I
> had a few comments on it but never saw an updated version. Is Tomasz'
> work based on that patch?

Is this the patch you are talking about?

https://lkml.org/lkml/2012/12/13/84

If yes, it solves the problems only for Exynos SoCs (excluding Exynos 4210 
rev0), which don't need to share the PWM hardware between two drivers.

On older platforms (S3C24xx, S3C64xx, S5P64x0, S5PC100, S5PV210 and Exynos 
4210 rev0) the same hardware block is used for two drivers - clocksource 
driver and PWM driver.

You can get more information from these two threads:

- http://thread.gmane.org/gmane.linux.kernel.samsung-soc/16480/focus=16510
(starting from the linked post)

- http://thread.gmane.org/gmane.linux.kernel.samsung-soc/17464
 

> Given that this patch solves a real problem and doesn't make things any
> worse, I think it's okay to use it temporarily until Tomasz has had time
> to finish up the proper driver, so:

Well, from what I've seen, the PWM might have been already broken on non-
DT platforms using channels higher than 0, because the driver registers 
each channel passing -1 as base, which makes the id being assigned 
dynamically (usually to 0, since it's the only PWM channel used), while in 
all platform data, the real (hardware) PWM channel id is used and no PWM 
lookup is registered.

You can use the following grep to find all platforms with broken PWM:
git grep pwm_id arch/arm/mach-s[35]* | grep -v "= 0"

I have a set of patches to fix everything up in the PWM driver, but they 
depend on my patches providing the infrastructure to share the PWM 
hardware, on next version of which I'm currently working.

So, for now, Arnd's patch is fine to me as well.

Best regards,
Tomasz



From b35083 at freescale.com  Fri Apr 12 03:10:55 2013
From: b35083 at freescale.com (Jingchang Lu)
Date: Fri, 12 Apr 2013 15:10:55 +0800
Subject: [PATCH] tty/serial: add MVF uart driver support
Message-ID: <1365750655-3530-1-git-send-email-b35083@freescale.com>

It adds Freescale Vybrid Family uart driver support

Signed-off-by: Jingchang Lu <b35083 at freescale.com>
---
 drivers/tty/serial/Kconfig       |   17 +
 drivers/tty/serial/Makefile      |    1 +
 drivers/tty/serial/mvf.c         | 1246 ++++++++++++++++++++++++++++++++++++++
 include/uapi/linux/serial_core.h |    3 +
 4 files changed, 1267 insertions(+)
 create mode 100644 drivers/tty/serial/mvf.c

diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index 7e7006f..ab6dc27 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -574,6 +574,23 @@ config SERIAL_IMX_CONSOLE
 	  your boot loader (lilo or loadlin) about how to pass options to the
 	  kernel at boot time.)
 
+config SERIAL_MVF
+	bool "Freescale Vybrid serial port support"
+	depends on ARCH_MVF
+	select SERIAL_CORE
+	select RATIONAL
+	help
+	  If you have a machine based on a Freescale Vybrid CPU you
+	  can enable its onboard serial port by enabling this option.
+
+config SERIAL_MVF_CONSOLE
+	bool "Console on Vybrid serial port"
+	depends on SERIAL_MVF
+	select SERIAL_CORE_CONSOLE
+	help
+	  If you have enabled the serial port on the Freescale Vybrid family
+	  CPU you can make it the console by answering Y to this option.
+
 config SERIAL_UARTLITE
 	tristate "Xilinx uartlite serial port support"
 	depends on PPC32 || MICROBLAZE || MFD_TIMBERDALE
diff --git a/drivers/tty/serial/Makefile b/drivers/tty/serial/Makefile
index eedfec4..be2ed68 100644
--- a/drivers/tty/serial/Makefile
+++ b/drivers/tty/serial/Makefile
@@ -41,6 +41,7 @@ obj-$(CONFIG_SERIAL_SH_SCI) += sh-sci.o
 obj-$(CONFIG_SERIAL_SGI_L1_CONSOLE) += sn_console.o
 obj-$(CONFIG_SERIAL_CPM) += cpm_uart/
 obj-$(CONFIG_SERIAL_IMX) += imx.o
+obj-$(CONFIG_SERIAL_MVF) += mvf.o
 obj-$(CONFIG_SERIAL_MPC52xx) += mpc52xx_uart.o
 obj-$(CONFIG_SERIAL_ICOM) += icom.o
 obj-$(CONFIG_SERIAL_M32R_SIO) += m32r_sio.o
diff --git a/drivers/tty/serial/mvf.c b/drivers/tty/serial/mvf.c
new file mode 100644
index 0000000..b3b7ffd
--- /dev/null
+++ b/drivers/tty/serial/mvf.c
@@ -0,0 +1,1246 @@
+/*
+ *  Driver for Freescale Vybrid Family serial ports
+ *
+ *  Based on drivers/tty/serial/imx.c
+ *
+ *  Copyright 2012-2013 Freescale Semiconductor, Inc.
+ *
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ *
+ */
+
+#if defined(CONFIG_SERIAL_MVF_CONSOLE) && defined(CONFIG_MAGIC_SYSRQ)
+#define SUPPORT_SYSRQ
+#endif
+
+#include <linux/module.h>
+#include <linux/ioport.h>
+#include <linux/init.h>
+#include <linux/console.h>
+#include <linux/sysrq.h>
+#include <linux/platform_device.h>
+#include <linux/tty.h>
+#include <linux/tty_flip.h>
+#include <linux/serial_core.h>
+#include <linux/serial.h>
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/rational.h>
+#include <linux/slab.h>
+#include <linux/dma-mapping.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/pinctrl/consumer.h>
+#include <linux/io.h>
+#include <asm/irq.h>
+#include <linux/platform_data/serial-imx.h>
+#include <linux/platform_data/dma-imx.h>
+
+/* All uart module registers for MVF is 8-bit width */
+#define MXC_UARTBDH		0x00 /* Baud rate reg: high */
+#define MXC_UARTBDL		0x01 /* Baud rate reg: low */
+#define MXC_UARTCR1		0x02 /* Control reg 1 */
+#define MXC_UARTCR2		0x03 /* Control reg 2 */
+#define MXC_UARTSR1		0x04 /* Status reg 1 */
+#define MXC_UARTSR2		0x05 /* Status reg 2 */
+#define MXC_UARTCR3		0x06 /* Control reg 3 */
+#define MXC_UARTDR		0x07 /* Data reg */
+#define MXC_UARTMAR1		0x08 /* Match address reg 1 */
+#define MXC_UARTMAR2		0x09 /* Match address reg 2 */
+#define MXC_UARTCR4		0x0A /* Control reg 4 */
+#define MXC_UARTCR5		0x0B /* Control reg 5 */
+#define MXC_UARTEDR		0x0C /* Extended data reg */
+#define MXC_UARTMODEM		0x0D /* Modem reg */
+#define MXC_UARTIR		0x0E /* Infrared reg */
+#define MXC_UARTPFIFO		0x10 /* FIFO parameter reg */
+#define MXC_UARTCFIFO		0x11 /* FIFO control reg */
+#define MXC_UARTSFIFO		0x12 /* FIFO status reg */
+#define MXC_UARTTWFIFO		0x13 /* FIFO transmit watermark reg */
+#define MXC_UARTTCFIFO		0x14 /* FIFO transmit count reg */
+#define MXC_UARTRWFIFO		0x15 /* FIFO receive watermark reg */
+#define MXC_UARTRCFIFO		0x16 /* FIFO receive count reg */
+#define MXC_UARTC7816		0x18 /* 7816 control reg */
+#define MXC_UARTIE7816		0x19 /* 7816 interrupt enable reg */
+#define MXC_UARTIS7816		0x1A /* 7816 interrupt status reg */
+#define MXC_UARTWP7816T0	0x1B /* 7816 wait parameter reg */
+#define MXC_UARTWP7816T1	0x1B /* 7816 wait parameter reg */
+#define MXC_UARTWN7816		0x1C /* 7816 wait N reg */
+#define MXC_UARTWF7816		0x1D /* 7816 wait FD reg */
+#define MXC_UARTET7816		0x1E /* 7816 error threshold reg */
+#define MXC_UARTTL7816		0x1F /* 7816 transmit length reg */
+#define MXC_UARTCR6		0x21 /* CEA709.1-B contrl reg */
+#define MXC_UARTPCTH		0x22 /* CEA709.1-B packet cycle counter high */
+#define MXC_UARTPCTL		0x23 /* CEA709.1-B packet cycle counter low */
+#define MXC_UARTB1T		0x24 /* CEA709.1-B beta 1 time */
+#define MXC_UARTSDTH		0x25 /* CEA709.1-B secondary delay timer high */
+#define MXC_UARTSDTL		0x26 /* CEA709.1-B secondary delay timer low */
+#define MXC_UARTPRE		0x27 /* CEA709.1-B preamble */
+#define MXC_UARTTPL		0x28 /* CEA709.1-B transmit packet length */
+#define MXC_UARTIE		0x29 /* CEA709.1-B transmit interrupt enable */
+#define MXC_UARTSR3		0x2B /* CEA709.1-B status reg */
+#define MXC_UARTSR4		0x2C /* CEA709.1-B status reg */
+#define MXC_UARTRPL		0x2D /* CEA709.1-B received packet length */
+#define MXC_UARTRPREL		0x2E /* CEA709.1-B received preamble length */
+#define MXC_UARTCPW		0x2F /* CEA709.1-B collision pulse width */
+#define MXC_UARTRIDT		0x30 /* CEA709.1-B receive indeterminate time */
+#define MXC_UARTTIDT		0x31 /* CEA709.1-B transmit indeterminate time*/
+
+/* Bit definations of BDH */
+#define MXC_UARTBDH_LBKDIE	0x80 /* LIN break detect interrupt enable */
+#define MXC_UARTBDH_RXEDGIE	0x40 /* RxD input Active edge interrupt enable*/
+#define MXC_UARTBDH_SBR_MASK	0x1f /* Uart baud rate high 5-bits */
+/* Bit definations of CR1 */
+#define MXC_UARTCR1_LOOPS	0x80 /* Loop mode select */
+#define MXC_UARTCR1_RSRC	0x20 /* Receiver source select */
+#define MXC_UARTCR1_M		0x10 /* 9-bit 8-bit mode select */
+#define MXC_UARTCR1_WAKE	0x08 /* Receiver wakeup method */
+#define MXC_UARTCR1_ILT		0x04 /* Idle line type */
+#define MXC_UARTCR1_PE		0x02 /* Parity enable */
+#define MXC_UARTCR1_PT		0x01 /* Parity type */
+/* Bit definations of CR2 */
+#define MXC_UARTCR2_TIE		0x80 /* Tx interrupt or DMA request enable */
+#define MXC_UARTCR2_TCIE	0x40 /* Transmission complete int enable */
+#define MXC_UARTCR2_RIE		0x20 /* Rx full int or DMA request enable */
+#define MXC_UARTCR2_ILIE	0x10 /* Idle line interrupt enable */
+#define MXC_UARTCR2_TE		0x08 /* Transmitter enable */
+#define MXC_UARTCR2_RE		0x04 /* Receiver enable */
+#define MXC_UARTCR2_RWU		0x02 /* Receiver wakeup control */
+#define MXC_UARTCR2_SBK		0x01 /* Send break */
+/* Bit definations of SR1 */
+#define MXC_UARTSR1_TDRE	0x80 /* Tx data reg empty */
+#define MXC_UARTSR1_TC		0x40 /* Transmit complete */
+#define MXC_UARTSR1_RDRF	0x20 /* Rx data reg full */
+#define MXC_UARTSR1_IDLE	0x10 /* Idle line flag */
+#define MXC_UARTSR1_OR		0x08 /* Receiver overrun */
+#define MXC_UARTSR1_NF		0x04 /* Noise flag */
+#define MXC_UARTSR1_FE		0x02 /* Frame error */
+#define MXC_UARTSR1_PE		0x01 /* Parity error */
+/* Bit definations of SR2 */
+#define MXC_UARTSR2_LBKDIF	0x80 /* LIN brk detect interrupt flag */
+#define MXC_UARTSR2_RXEDGIF	0x40 /* RxD pin active edge interrupt flag */
+#define MXC_UARTSR2_MSBF	0x20 /* MSB first */
+#define MXC_UARTSR2_RXINV	0x10 /* Receive data inverted */
+#define MXC_UARTSR2_RWUID	0x08 /* Receive wakeup idle detect */
+#define MXC_UARTSR2_BRK13	0x04 /* Break transmit character length */
+#define MXC_UARTSR2_LBKDE	0x02 /* LIN break detection enable */
+#define MXC_UARTSR2_RAF		0x01 /* Receiver active flag */
+/* Bit definations of CR3 */
+#define MXC_UARTCR3_R8		0x80 /* Received bit8, for 9-bit data format */
+#define MXC_UARTCR3_T8		0x40 /* transmit bit8, for 9-bit data format */
+#define MXC_UARTCR3_TXDIR	0x20 /* Tx pin direction in single-wire mode */
+#define MXC_UARTCR3_TXINV	0x10 /* Transmit data inversion */
+#define MXC_UARTCR3_ORIE	0x08 /* Overrun error interrupt enable */
+#define MXC_UARTCR3_NEIE	0x04 /* Noise error interrupt enable */
+#define MXC_UARTCR3_FEIE	0x02 /* Framing error interrupt enable */
+#define MXC_UARTCR3_PEIE	0x01 /* Parity errror interrupt enable */
+/* Bit definations of CR4 */
+#define MXC_UARTCR4_MAEN1	0x80 /* Match address mode enable 1 */
+#define MXC_UARTCR4_MAEN2	0x40 /* Match address mode enable 2 */
+#define MXC_UARTCR4_M10		0x20 /* 10-bit mode select */
+#define MXC_UARTCR4_BRFA_MASK	0x1F /* Baud rate fine adjust */
+#define MXC_UARTCR4_BRFA_OFF	0
+/* Bit definations of CR5 */
+#define MXC_UARTCR5_TDMAS	0x80 /* Transmitter DMA select */
+#define MXC_UARTCR5_RDMAS	0x20 /* Receiver DMA select */
+/* Bit definations of Modem */
+#define MXC_UARTMODEM_RXRTSE	0x08 /* Enable receiver request-to-send */
+#define MXC_UARTMODEM_TXRTSPOL	0x04 /* Select transmitter RTS polarity */
+#define MXC_UARTMODEM_TXRTSE	0x02 /* Enable transmitter request-to-send */
+#define MXC_UARTMODEM_TXCTSE	0x01 /* Enable transmitter CTS clear-to-send */
+/* Bit definations of EDR */
+#define MXC_UARTEDR_NOISY	0x80 /* Current dataword received with noise */
+#define MXC_UARTEDR_PARITYE	0x40 /* Dataword received with parity error */
+/* Bit definations of Infrared reg(IR) */
+#define MXC_UARTIR_IREN		0x04 /* Infrared enable */
+#define MXC_UARTIR_TNP_MASK	0x03 /* Transmitter narrow pluse */
+#define MXC_UARTIR_TNP_OFF	0
+/* Bit definations of FIFO parameter reg */
+#define MXC_UARTPFIFO_TXFE	0x80 /* Transmit fifo enable */
+#define MXC_UARTPFIFO_TXFIFOSIZE_MASK	0x7
+#define MXC_UARTPFIFO_TXFIFOSIZE_OFF	4
+#define MXC_UARTPFIFO_RXFE	0x08 /* Receiver fifo enable */
+#define MXC_UARTPFIFO_RXFIFOSIZE_MASK	0x7
+#define MXC_UARTPFIFO_RXFIFOSIZE_OFF	0
+/* Bit definations of FIFO control reg */
+#define MXC_UARTCFIFO_TXFLUSH	0x80 /* Transmit FIFO/buffer flush */
+#define MXC_UARTCFIFO_RXFLUSH	0x40 /* Receive FIFO/buffer flush */
+#define MXC_UARTCFIFO_RXOFE	0x04 /* Receive fifo overflow INT enable */
+#define MXC_UARTCFIFO_TXOFE	0x02 /* Transmit fifo overflow INT enable */
+#define MXC_UARTCFIFO_RXUFE	0x01 /* Receive fifo underflow INT enable */
+/* Bit definations of FIFO status reg */
+#define MXC_UARTSFIFO_TXEMPT	0x80 /* Transmit fifo/buffer empty */
+#define MXC_UARTSFIFO_RXEMPT	0x40 /* Receive fifo/buffer empty */
+#define MXC_UARTSFIFO_RXOF	0x04 /* Rx buffer overflow flag */
+#define MXC_UARTSFIFO_TXOF	0x02 /* Tx buffer overflow flag */
+#define MXC_UARTSFIFO_RXUF	0x01 /* Rx buffer underflow flag */
+
+
+
+#undef CONFIG_MVF_SERIAL_DMA
+/* follow IMX dev node number */
+#define SERIAL_IMX_MAJOR	207
+#define MINOR_START		24
+#define DEV_NAME	"ttymxc"
+#define MAX_INTERNAL_IRQ	MXC_INTERNAL_IRQS
+
+/*
+ * This determines how often we check the modem status signals
+ * for any change.  They generally aren't connected to an IRQ
+ * so we have to poll them.  We also check immediately before
+ * filling the TX fifo incase CTS has been dropped.
+ */
+#define MCTRL_TIMEOUT	(250*HZ/1000)
+
+#define DRIVER_NAME "MVF-uart"
+
+#define UART_NR 6
+
+struct mvf_port {
+	struct uart_port	port;
+	unsigned int		old_status;
+	int			txirq, rxirq, rtsirq;
+	unsigned int		have_rtscts:1;
+	unsigned int		use_dcedte:1;
+	unsigned int		use_irda:1;
+	unsigned int		irda_inv_rx:1;
+	unsigned int		irda_inv_tx:1;
+	unsigned int		fifo_en:1; /* enable FIFO mode */
+	unsigned int		mark_en:1; /* enable Mark address match */
+	unsigned int		format_9bits:1; /* 9bits data format */
+	unsigned short		trcv_delay; /* transceiver delay */
+	unsigned char		ma_addr; /* Match address */
+	struct clk		*clk;
+
+	unsigned int		tx_fifo_size, rx_fifo_size;
+
+	/* DMA fields */
+	int			enable_dma;
+	unsigned long		dma_tx_ch; /* configured eDMA channel */
+	struct imx_dma_data	dma_data;
+	struct dma_chan		*dma_chan_rx, *dma_chan_tx;
+	struct scatterlist	rx_sgl, tx_sgl;
+	void			*rx_buf;
+	unsigned char		*tx_buf;
+	unsigned int		rx_bytes, tx_bytes;
+	struct work_struct	tsk_dma_rx, tsk_dma_tx;
+	unsigned int		dma_tx_nents;
+	bool			dma_is_rxing, dma_is_txing;
+	wait_queue_head_t	dma_wait;
+};
+
+#ifdef CONFIG_IRDA
+#define USE_IRDA(sport)	((sport)->use_irda)
+#else
+#define USE_IRDA(sport)	(0)
+#endif
+enum mvf_uart_type {
+	MVF600_UART,
+};
+
+struct mvf_uart_data {
+	unsigned uts_reg;
+	enum mvf_uart_type devtype;
+};
+
+static struct mvf_uart_data mvf_uart_devdata[] = {
+	[MVF600_UART] = {
+		.devtype = MVF600_UART,
+	},
+};
+
+static struct platform_device_id mvf_uart_devtype[] = {
+	{
+		.name = "mvf600-uart",
+		.driver_data = (kernel_ulong_t) &mvf_uart_devdata[MVF600_UART],
+	}, {
+		/* sentinel */
+	}
+};
+MODULE_DEVICE_TABLE(platform, mvf_uart_devtype);
+
+static struct of_device_id mvf_uart_dt_ids[] = {
+	{
+		.compatible = "fsl,mvf-uart",
+		.data = &mvf_uart_devdata[MVF600_UART],
+	},
+	{ /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, mvf_uart_dt_ids);
+
+/*
+ * interrupts disabled on entry
+ */
+static void mvf_stop_tx(struct uart_port *port)
+{
+	struct mvf_port *sport = (struct mvf_port *)port;
+	unsigned char temp;
+
+	temp = readb(sport->port.membase + MXC_UARTCR2);
+	writeb(temp & ~(MXC_UARTCR2_TIE | MXC_UARTCR2_TCIE),
+			sport->port.membase + MXC_UARTCR2);
+}
+
+/*
+ * interrupts disabled on entry
+ */
+static void mvf_stop_rx(struct uart_port *port)
+{
+	struct mvf_port *sport = (struct mvf_port *)port;
+	unsigned char temp;
+
+	/* if the DMA RX thread is running, wait for it to finish. */
+	if (sport->enable_dma && sport->dma_is_rxing)
+		return;
+
+	temp = readb(sport->port.membase + MXC_UARTCR2);
+	writeb(temp & ~MXC_UARTCR2_RE, sport->port.membase + MXC_UARTCR2);
+}
+
+ /* modem status update function */
+static void mvf_enable_ms(struct uart_port *port)
+{
+}
+
+static inline void mvf_transmit_buffer(struct mvf_port *sport)
+{
+	struct circ_buf *xmit = &sport->port.state->xmit;
+
+	while (!uart_circ_empty(xmit) && (sport->fifo_en == 1 ?
+	(readb(sport->port.membase + MXC_UARTTCFIFO) < sport->tx_fifo_size) :
+		(readb(sport->port.membase + MXC_UARTSR1) & MXC_UARTSR1_TDRE)
+		)) {
+		/* send out xmit->buf[xmit->tail] */
+		writeb(xmit->buf[xmit->tail], sport->port.membase + MXC_UARTDR);
+		xmit->tail = (xmit->tail + 1) & (UART_XMIT_SIZE - 1);
+		sport->port.icount.tx++;
+	}
+
+	if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS)
+		uart_write_wakeup(&sport->port);
+
+	if (uart_circ_empty(xmit))
+		mvf_stop_tx(&sport->port);
+}
+
+/*
+ * interrupts disabled on entry
+ */
+static void mvf_start_tx(struct uart_port *port)
+{
+	struct mvf_port *sport = (struct mvf_port *)port;
+	unsigned char temp;
+
+	if (!sport->enable_dma) {
+		temp = readb(sport->port.membase + MXC_UARTCR2);
+		writeb(temp | MXC_UARTCR2_TIE,
+				sport->port.membase + MXC_UARTCR2);
+	}
+
+	if (sport->enable_dma) {
+		schedule_work(&sport->tsk_dma_tx);
+		return;
+	}
+
+	if (readb(sport->port.membase + MXC_UARTSR1) & MXC_UARTSR1_TDRE)
+		mvf_transmit_buffer(sport);
+}
+
+
+static irqreturn_t mvf_txint(int irq, void *dev_id)
+{
+	struct mvf_port *sport = dev_id;
+	struct circ_buf *xmit = &sport->port.state->xmit;
+	unsigned long flags;
+
+	spin_lock_irqsave(&sport->port.lock, flags);
+	if (sport->port.x_char) {
+		/* Send next char */
+		writeb(sport->port.x_char, sport->port.membase + MXC_UARTDR);
+		goto out;
+	}
+
+	if (uart_circ_empty(xmit) || uart_tx_stopped(&sport->port)) {
+		mvf_stop_tx(&sport->port);
+		goto out;
+	}
+
+	mvf_transmit_buffer(sport);
+
+	if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS)
+		uart_write_wakeup(&sport->port);
+
+out:
+	spin_unlock_irqrestore(&sport->port.lock, flags);
+	return IRQ_HANDLED;
+}
+
+static irqreturn_t mvf_rxint(int irq, void *dev_id)
+{
+	struct mvf_port *sport = dev_id;
+	unsigned int flg, ignored = 0;
+	struct tty_port *port = &sport->port.state->port;
+	unsigned long flags;
+	unsigned char r8, rx, sr;
+
+	spin_lock_irqsave(&sport->port.lock, flags);
+
+	while (!(readb(sport->port.membase + MXC_UARTSFIFO) &
+				MXC_UARTSFIFO_RXEMPT)) {
+		flg = TTY_NORMAL;
+		sport->port.icount.rx++;
+
+		/*  To clear the FE, OR, NF, FE, PE flags when set,
+		 *  read SR1 then read DR
+		 */
+		sr = readb(sport->port.membase + MXC_UARTSR1);
+
+		r8 = readb(sport->port.membase + MXC_UARTCR3) & MXC_UARTCR3_R8;
+		rx = readb(sport->port.membase + MXC_UARTDR);
+
+		if (sport->mark_en &&
+			(sport->format_9bits ? r8 : (rx == sport->ma_addr)))
+				continue;
+
+		if (uart_handle_sysrq_char(&sport->port, (unsigned char)rx))
+			continue;
+		if (sr & (MXC_UARTSR1_PE | MXC_UARTSR1_OR | MXC_UARTSR1_FE)) {
+			if (sr & MXC_UARTSR1_PE)
+				sport->port.icount.parity++;
+			else if (sr & MXC_UARTSR1_FE)
+				sport->port.icount.frame++;
+			if (sr & MXC_UARTSR1_OR)
+				sport->port.icount.overrun++;
+
+			if (sr & sport->port.ignore_status_mask) {
+				if (++ignored > 100)
+					goto out;
+				continue;
+			}
+
+			sr &= sport->port.read_status_mask;
+
+			if (sr & MXC_UARTSR1_PE)
+				flg = TTY_PARITY;
+			else if (sr & MXC_UARTSR1_FE)
+				flg = TTY_FRAME;
+			if (sr & MXC_UARTSR1_OR)
+				flg = TTY_OVERRUN;
+
+#ifdef SUPPORT_SYSRQ
+			sport->port.sysrq = 0;
+#endif
+		}
+
+		tty_insert_flip_char(port, rx, flg);
+	}
+
+out:
+	spin_unlock_irqrestore(&sport->port.lock, flags);
+
+	tty_flip_buffer_push(port);
+	return IRQ_HANDLED;
+}
+
+static irqreturn_t mvf_int(int irq, void *dev_id)
+{
+	struct mvf_port *sport = dev_id;
+	unsigned int sts;
+
+	sts = readb(sport->port.membase + MXC_UARTSR1);
+
+	if (sts & MXC_UARTSR1_RDRF)
+			mvf_rxint(irq, dev_id);
+
+	if (sts & MXC_UARTSR1_TDRE &&
+		!(readb(sport->port.membase + MXC_UARTCR5) &
+			MXC_UARTCR5_TDMAS))
+		mvf_txint(irq, dev_id);
+
+	return IRQ_HANDLED;
+}
+
+/*
+ * Return TIOCSER_TEMT when transmitter is not busy.
+ */
+static unsigned int mvf_tx_empty(struct uart_port *port)
+{
+	struct mvf_port *sport = (struct mvf_port *)port;
+
+	return (readb(sport->port.membase + MXC_UARTSR1) & MXC_UARTSR1_TC) ?
+		TIOCSER_TEMT : 0;
+}
+
+static unsigned int mvf_get_mctrl(struct uart_port *port)
+{
+	struct mvf_port *sport = (struct mvf_port *)port;
+	unsigned int tmp = 0;
+	unsigned char reg;
+
+	reg = readb(sport->port.membase + MXC_UARTMODEM);
+	if (reg & MXC_UARTMODEM_TXCTSE)
+		tmp |= TIOCM_CTS;
+
+	if (reg & MXC_UARTMODEM_RXRTSE)
+		tmp |= TIOCM_RTS;
+
+	return tmp;
+}
+
+static void mvf_set_mctrl(struct uart_port *port, unsigned int mctrl)
+{
+	struct mvf_port *sport = (struct mvf_port *)port;
+	unsigned long temp;
+
+	temp = readb(sport->port.membase + MXC_UARTMODEM) &
+			~(MXC_UARTMODEM_RXRTSE | MXC_UARTMODEM_TXCTSE);
+
+	if (mctrl & TIOCM_RTS)
+		temp |= MXC_UARTMODEM_RXRTSE;
+	if (mctrl & TIOCM_CTS)
+		temp |= MXC_UARTMODEM_TXCTSE;
+
+	writeb(temp, sport->port.membase + MXC_UARTMODEM);
+}
+
+/*
+ * Interrupts always disabled.
+ */
+static void mvf_break_ctl(struct uart_port *port, int break_state)
+{
+	struct mvf_port *sport = (struct mvf_port *)port;
+	unsigned long flags;
+	unsigned char temp;
+
+	spin_lock_irqsave(&sport->port.lock, flags);
+
+	temp = readb(sport->port.membase + MXC_UARTCR2) & ~MXC_UARTCR2_SBK;
+
+	if (break_state != 0)
+		temp |= MXC_UARTCR2_SBK;
+
+	writeb(temp, sport->port.membase + MXC_UARTCR2);
+
+	spin_unlock_irqrestore(&sport->port.lock, flags);
+}
+
+#define TXTL 2
+#define RXTL 1
+
+static int mvf_setup_watermark(struct mvf_port *sport, unsigned int mode)
+{
+	unsigned char val, old_cr2, cr2;
+
+	/* set receiver/transmitter trigger level. */
+	old_cr2 = cr2 = readb(sport->port.membase + MXC_UARTCR2);
+	cr2 &= ~(MXC_UARTCR2_TIE | MXC_UARTCR2_TCIE | MXC_UARTCR2_TE |
+			MXC_UARTCR2_RIE | MXC_UARTCR2_RE);
+	writeb(cr2, sport->port.membase + MXC_UARTCR2);
+
+	val = TXTL;
+	writeb(val, sport->port.membase + MXC_UARTTWFIFO);
+	val = RXTL;
+	writeb(val, sport->port.membase + MXC_UARTRWFIFO);
+
+	/* Enable Tx and Rx FIFO */
+	val = readb(sport->port.membase + MXC_UARTPFIFO);
+	sport->tx_fifo_size = 0x1 << (((val >> MXC_UARTPFIFO_TXFIFOSIZE_OFF) &
+		MXC_UARTPFIFO_TXFIFOSIZE_MASK) + 1);
+	sport->rx_fifo_size = 0x1 << (((val >> MXC_UARTPFIFO_RXFIFOSIZE_OFF) &
+		MXC_UARTPFIFO_RXFIFOSIZE_MASK) + 1);
+	writeb(val | MXC_UARTPFIFO_TXFE | MXC_UARTPFIFO_RXFE,
+			sport->port.membase + MXC_UARTPFIFO);
+
+	/* Flush the Tx and Rx FIFO to a known state */
+	writeb(MXC_UARTCFIFO_TXFLUSH | MXC_UARTCFIFO_RXFLUSH,
+			sport->port.membase + MXC_UARTCFIFO);
+
+	/* restore CR2 */
+	writeb(old_cr2, sport->port.membase + MXC_UARTCR2);
+
+	return 0;
+}
+
+
+static int mvf_startup(struct uart_port *port)
+{
+	struct mvf_port *sport = (struct mvf_port *)port;
+	int retval;
+	unsigned long flags, temp;
+
+	if (sport->fifo_en)
+		mvf_setup_watermark(sport, 0);
+
+	temp = readb(sport->port.membase + MXC_UARTCR2);
+
+	writeb(temp & ~MXC_UARTCR2_RIE, sport->port.membase + MXC_UARTCR2);
+
+	/*
+	 * Allocate the IRQ(s)
+	 * Vybrid chips only have one interrupt.
+	 */
+	retval = request_irq(sport->port.irq, mvf_int, 0,
+				DRIVER_NAME, sport);
+	if (retval)
+		goto error_out1;
+
+	/* Enable the DMA ops for uart. */
+	if (sport->enable_dma) {
+		sport->dma_is_txing = 0;
+
+		/* enable DMA request generation */
+		temp = readb(sport->port.membase + MXC_UARTCR5);
+		temp |= MXC_UARTCR5_TDMAS;
+		writeb(temp, sport->port.membase + MXC_UARTCR5);
+
+		init_waitqueue_head(&sport->dma_wait);
+	}
+
+	spin_lock_irqsave(&sport->port.lock, flags);
+
+	/* Finally, clear and enable interrupts */
+	temp = readb(sport->port.membase + MXC_UARTCR2);
+	temp |= MXC_UARTCR2_RIE | MXC_UARTCR2_TIE;
+	writeb(temp, sport->port.membase + MXC_UARTCR2);
+
+	spin_unlock_irqrestore(&sport->port.lock, flags);
+
+	return 0;
+
+error_out1:
+	return retval;
+}
+
+static void mvf_shutdown(struct uart_port *port)
+{
+	struct mvf_port *sport = (struct mvf_port *)port;
+	unsigned char temp;
+	unsigned long flags;
+
+	spin_lock_irqsave(&sport->port.lock, flags);
+	temp = readb(sport->port.membase + MXC_UARTCR2);
+	temp &= ~(MXC_UARTCR2_TE | MXC_UARTCR2_RE);
+	writeb(temp, sport->port.membase + MXC_UARTCR2);
+	spin_unlock_irqrestore(&sport->port.lock, flags);
+
+	/*
+	 * Free the interrupts
+	 */
+	if (sport->txirq > 0) {
+		if (!USE_IRDA(sport))
+			free_irq(sport->rtsirq, sport);
+		free_irq(sport->txirq, sport);
+		free_irq(sport->rxirq, sport);
+	} else
+		free_irq(sport->port.irq, sport);
+
+	/*
+	 * Disable all interrupts, port and break condition.
+	 */
+
+	spin_lock_irqsave(&sport->port.lock, flags);
+	temp = readb(sport->port.membase + MXC_UARTCR2);
+	temp &= ~(MXC_UARTCR2_TIE | MXC_UARTCR2_TCIE | MXC_UARTCR2_RIE);
+	writeb(temp, sport->port.membase + MXC_UARTCR2);
+
+	spin_unlock_irqrestore(&sport->port.lock, flags);
+}
+
+static void
+mvf_set_termios(struct uart_port *port, struct ktermios *termios,
+		   struct ktermios *old)
+{
+	struct mvf_port *sport = (struct mvf_port *)port;
+	unsigned long flags;
+	unsigned char cr1, old_cr1, old_cr2, cr4, bdh, modem;
+	unsigned int  baud;
+	unsigned int old_csize = old ? old->c_cflag & CSIZE : CS8;
+	unsigned int sbr, brfa;
+
+	cr1 = old_cr1 = readb(sport->port.membase + MXC_UARTCR1);
+	old_cr2 = readb(sport->port.membase + MXC_UARTCR2);
+	cr4 = readb(sport->port.membase + MXC_UARTCR4);
+	bdh = readb(sport->port.membase + MXC_UARTBDH);
+	modem = readb(sport->port.membase + MXC_UARTMODEM);
+	/*
+	 * If we don't support modem control lines, don't allow
+	 * these to be set.
+	 */
+	if (0) {
+		termios->c_cflag &= ~(HUPCL | CRTSCTS | CMSPAR);
+		termios->c_cflag |= CLOCAL;
+	}
+
+	/*
+	 * We only support CS8 and CS7,but CS7 must enable PE.
+	 * supported mode:
+	 *  - (7,e/o,1)
+	 *  - (8,n,1)
+	 *  - (8,m/s,1)
+	 *  - (8,e/o,1)
+	 */
+	while ((termios->c_cflag & CSIZE) != CS8 &&
+		(termios->c_cflag & CSIZE) != CS7) {
+		termios->c_cflag &= ~CSIZE;
+		termios->c_cflag |= old_csize;
+		old_csize = CS8;
+	}
+
+	if ((termios->c_cflag & CSIZE) == CS8 ||
+		(termios->c_cflag & CSIZE) == CS7)
+		cr1 = old_cr1 & ~MXC_UARTCR1_M;
+
+	if (termios->c_cflag & CMSPAR) {
+		if ((termios->c_cflag & CSIZE) != CS8) {
+			termios->c_cflag &= ~CSIZE;
+			termios->c_cflag |= CS8;
+		}
+		cr1 |= MXC_UARTCR1_M;
+	}
+
+	if (termios->c_cflag & CRTSCTS) {
+		if (sport->have_rtscts)
+			modem |= (MXC_UARTMODEM_RXRTSE | MXC_UARTMODEM_TXCTSE);
+
+	} else {
+		termios->c_cflag &= ~CRTSCTS;
+		modem &= ~(MXC_UARTMODEM_RXRTSE | MXC_UARTMODEM_TXCTSE);
+	}
+
+	if (termios->c_cflag & CSTOPB)
+		termios->c_cflag &= ~CSTOPB;
+
+	/* parity must enable when CS7 to match 8-bits format */
+	if ((termios->c_cflag & CSIZE) == CS7)
+		termios->c_cflag |= PARENB;
+
+	if ((termios->c_cflag & PARENB)) {
+		if (termios->c_cflag & CMSPAR) {
+			cr1 &= ~MXC_UARTCR1_PE;
+			cr1 |= MXC_UARTCR1_M;
+			sport->format_9bits = 1;
+		} else {
+			cr1 |= MXC_UARTCR1_PE;
+			if ((termios->c_cflag & CSIZE) == CS8)
+				cr1 |= MXC_UARTCR1_M;
+			if (termios->c_cflag & PARODD)
+				cr1 |= MXC_UARTCR1_PT;
+			else
+				cr1 &= ~MXC_UARTCR1_PT;
+		}
+	}
+
+	/*
+	 * Ask the core to calculate the divisor for us.
+	 */
+	baud = uart_get_baud_rate(port, termios, old, 50, port->uartclk / 16);
+
+	spin_lock_irqsave(&sport->port.lock, flags);
+
+	sport->port.read_status_mask = 0;
+	if (termios->c_iflag & INPCK)
+		sport->port.read_status_mask |=
+					(MXC_UARTSR1_FE | MXC_UARTSR1_PE);
+	if (termios->c_iflag & (BRKINT | PARMRK))
+		sport->port.read_status_mask |= MXC_UARTSR1_FE;
+
+	/*
+	 * Characters to ignore
+	 */
+	sport->port.ignore_status_mask = 0;
+	if (termios->c_iflag & IGNPAR)
+		sport->port.ignore_status_mask |= MXC_UARTSR1_PE;
+	if (termios->c_iflag & IGNBRK) {
+		sport->port.ignore_status_mask |= MXC_UARTSR1_FE;
+		/*
+		 * If we're ignoring parity and break indicators,
+		 * ignore overruns too (for real raw support).
+		 */
+		if (termios->c_iflag & IGNPAR)
+			sport->port.ignore_status_mask |= MXC_UARTSR1_OR;
+	}
+
+	/*
+	 * Update the per-port timeout.
+	 */
+	uart_update_timeout(port, termios->c_cflag, baud);
+
+	/* wait transmit engin complete */
+	while (!(readb(sport->port.membase + MXC_UARTSR1) & MXC_UARTSR1_TC))
+		barrier();
+
+	writeb(old_cr2 & ~(MXC_UARTCR2_TE | MXC_UARTCR2_RE),
+			sport->port.membase + MXC_UARTCR2);
+
+	/* disable transmit and receive */
+	sbr = sport->port.uartclk / (16 * baud);
+	brfa = ((sport->port.uartclk - (16 * sbr * baud)) * 2)/baud;
+
+	bdh &= ~MXC_UARTBDH_SBR_MASK;
+	bdh |= (sbr >> 8) & 0x1F;
+
+	cr4 &= ~MXC_UARTCR4_BRFA_MASK;
+	brfa &= MXC_UARTCR4_BRFA_MASK;
+	writeb(cr4 | brfa, sport->port.membase + MXC_UARTCR4);
+	writeb(bdh, sport->port.membase + MXC_UARTBDH);
+	writeb(sbr & 0xFF, sport->port.membase + MXC_UARTBDL);
+	writeb(cr1, sport->port.membase + MXC_UARTCR1);
+	writeb(modem, sport->port.membase + MXC_UARTMODEM);
+
+	/* restore control register */
+	writeb(old_cr2, sport->port.membase + MXC_UARTCR2);
+
+	spin_unlock_irqrestore(&sport->port.lock, flags);
+}
+
+static const char *mvf_type(struct uart_port *port)
+{
+	struct mvf_port *sport = (struct mvf_port *)port;
+
+	return sport->port.type == PORT_MVF ? "MVF" : NULL;
+}
+
+/*
+ * Release the memory region(s) being used by 'port'.
+ */
+static void mvf_release_port(struct uart_port *port)
+{
+	struct platform_device *pdev = to_platform_device(port->dev);
+	struct resource *mmres;
+
+	mmres = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	release_mem_region(mmres->start, mmres->end - mmres->start + 1);
+}
+
+/*
+ * Request the memory region(s) being used by 'port'.
+ */
+static int mvf_request_port(struct uart_port *port)
+{
+	struct platform_device *pdev = to_platform_device(port->dev);
+	struct resource *mmres;
+	void *ret;
+
+	mmres = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	if (!mmres)
+		return -ENODEV;
+
+	ret = request_mem_region(mmres->start, mmres->end - mmres->start + 1,
+			"imx-uart");
+
+	return  ret ? 0 : -EBUSY;
+}
+
+/*
+ * Configure/autoconfigure the port.
+ */
+static void mvf_config_port(struct uart_port *port, int flags)
+{
+	struct mvf_port *sport = (struct mvf_port *)port;
+
+	if (flags & UART_CONFIG_TYPE &&
+	    mvf_request_port(&sport->port) == 0)
+		sport->port.type = PORT_MVF;
+}
+
+/*
+ * Verify the new serial_struct (for TIOCSSERIAL).
+ * The only change we allow are to the flags and type, and
+ * even then only between PORT_MVF and PORT_UNKNOWN
+ */
+static int
+mvf_verify_port(struct uart_port *port, struct serial_struct *ser)
+{
+	struct mvf_port *sport = (struct mvf_port *)port;
+	int ret = 0;
+
+	if (ser->type != PORT_UNKNOWN && ser->type != PORT_MVF)
+		ret = -EINVAL;
+	if (sport->port.irq != ser->irq)
+		ret = -EINVAL;
+	if (ser->io_type != UPIO_MEM)
+		ret = -EINVAL;
+	if (sport->port.uartclk / 16 != ser->baud_base)
+		ret = -EINVAL;
+	if (sport->port.iobase != ser->port)
+		ret = -EINVAL;
+	if (ser->hub6 != 0)
+		ret = -EINVAL;
+	return ret;
+}
+
+
+static struct uart_ops mvf_pops = {
+	.tx_empty	= mvf_tx_empty,
+	.set_mctrl	= mvf_set_mctrl,
+	.get_mctrl	= mvf_get_mctrl,
+	.stop_tx	= mvf_stop_tx,
+	.start_tx	= mvf_start_tx,
+	.stop_rx	= mvf_stop_rx,
+	.enable_ms	= mvf_enable_ms,
+	.break_ctl	= mvf_break_ctl,
+	.startup	= mvf_startup,
+	.shutdown	= mvf_shutdown,
+	.set_termios	= mvf_set_termios,
+	.type		= mvf_type,
+	.release_port	= mvf_release_port,
+	.request_port	= mvf_request_port,
+	.config_port	= mvf_config_port,
+	.verify_port	= mvf_verify_port,
+};
+
+static struct mvf_port *mvf_ports[UART_NR];
+
+#ifdef CONFIG_SERIAL_MVF_CONSOLE
+static void mvf_console_putchar(struct uart_port *port, int ch)
+{
+	struct mvf_port *sport = (struct mvf_port *)port;
+
+	while (!(readb(sport->port.membase + MXC_UARTSR1) & MXC_UARTSR1_TDRE))
+		barrier();
+
+	writeb(ch, sport->port.membase + MXC_UARTDR);
+}
+
+/*
+ * Interrupts are disabled on entering
+ */
+static void
+mvf_console_write(struct console *co, const char *s, unsigned int count)
+{
+	struct mvf_port *sport = mvf_ports[co->index];
+	unsigned int  old_cr2, cr2;
+	unsigned long flags;
+
+	spin_lock_irqsave(&sport->port.lock, flags);
+	/*
+	 * First, save UCR1/2 and then disable interrupts
+	 */
+	cr2 = old_cr2 = readb(sport->port.membase + MXC_UARTCR2);
+
+	cr2 |= (MXC_UARTCR2_TE |  MXC_UARTCR2_RE);
+	cr2 &= ~(MXC_UARTCR2_TIE | MXC_UARTCR2_TCIE | MXC_UARTCR2_RIE);
+
+	writeb(cr2, sport->port.membase + MXC_UARTCR2);
+
+	uart_console_write(&sport->port, s, count, mvf_console_putchar);
+
+	/*
+	 * wait for transmitter finish complete and restore CR2
+	 */
+	while (!(readb(sport->port.membase + MXC_UARTSR1) & MXC_UARTSR1_TC))
+		;
+
+	writeb(old_cr2, sport->port.membase + MXC_UARTCR2);
+	spin_unlock_irqrestore(&sport->port.lock, flags);
+}
+
+/*
+ * If the port was already initialised (eg, by a boot loader),
+ * try to determine the current setup.
+ */
+static void __init
+mvf_console_get_options(struct mvf_port *sport, int *baud,
+			   int *parity, int *bits)
+{
+
+	if (readb(sport->port.membase + MXC_UARTCR2) &
+			(MXC_UARTCR2_TE | MXC_UARTCR2)) {
+		/* ok, the port was enabled */
+		unsigned char cr1, bdh, bdl, brfa;
+		unsigned int sbr, uartclk;
+		unsigned int baud_raw;
+
+		cr1 = readb(sport->port.membase + MXC_UARTCR1);
+
+		*parity = 'n';
+		if (cr1 & MXC_UARTCR1_PE) {
+			if (cr1 & MXC_UARTCR1_PT)
+				*parity = 'o';
+			else
+				*parity = 'e';
+		}
+
+		if (cr1 & MXC_UARTCR1_M)
+			*bits = 9;
+		else
+			*bits = 8;
+
+		bdh = readb(sport->port.membase + MXC_UARTBDH) &
+						MXC_UARTBDH_SBR_MASK;
+		bdl = readb(sport->port.membase + MXC_UARTBDL);
+		sbr = bdh;
+		sbr <<= 8;
+		sbr |= bdl;
+		brfa = readb(sport->port.membase + MXC_UARTCR4) &
+						MXC_UARTCR4_BRFA_MASK;
+		uartclk = clk_get_rate(sport->clk);
+		/*
+		 * Baud = mod_clk/(16*(sbr[13]+(brfa)/32)
+		 */
+		baud_raw = uartclk/(16 * (sbr + brfa/32));
+
+		if (*baud != baud_raw)
+			printk(KERN_INFO "Serial: Console IMX "
+					"rounded baud rate from %d to %d\n",
+				baud_raw, *baud);
+	}
+}
+
+static int __init
+mvf_console_setup(struct console *co, char *options)
+{
+	struct mvf_port *sport;
+	int baud = 115200;
+	int bits = 8;
+	int parity = 'n';
+	int flow = 'n';
+
+	/*
+	 * Check whether an invalid uart number has been specified, and
+	 * if so, search for the first available port that does have
+	 * console support.
+	 */
+	if (co->index == -1 || co->index >= ARRAY_SIZE(mvf_ports))
+		co->index = 0;
+	sport = mvf_ports[co->index];
+
+	if (sport == NULL)
+		return -ENODEV;
+
+	if (options)
+		uart_parse_options(options, &baud, &parity, &bits, &flow);
+	else
+		mvf_console_get_options(sport, &baud, &parity, &bits);
+
+	if (sport->fifo_en == 1)
+		mvf_setup_watermark(sport, 0);
+
+	return uart_set_options(&sport->port, co, baud, parity, bits, flow);
+}
+
+static struct uart_driver mvf_reg;
+static struct console mvf_console = {
+	.name		= DEV_NAME,
+	.write		= mvf_console_write,
+	.device		= uart_console_device,
+	.setup		= mvf_console_setup,
+	.flags		= CON_PRINTBUFFER,
+	.index		= -1,
+	.data		= &mvf_reg,
+};
+
+#define MVF_CONSOLE	(&mvf_console)
+#else
+#define MVF_CONSOLE	NULL
+#endif
+
+static struct uart_driver mvf_reg = {
+	.owner          = THIS_MODULE,
+	.driver_name    = DRIVER_NAME,
+	.dev_name       = DEV_NAME,
+	.major          = SERIAL_IMX_MAJOR,
+	.minor          = MINOR_START,
+	.nr             = ARRAY_SIZE(mvf_ports),
+	.cons           = MVF_CONSOLE,
+};
+
+static int serial_mvf_suspend(struct platform_device *dev, pm_message_t state)
+{
+	struct mvf_port *sport = platform_get_drvdata(dev);
+
+	/* Enable UART wakeup */
+
+	if (sport)
+		uart_suspend_port(&mvf_reg, &sport->port);
+
+	return 0;
+}
+
+static int serial_mvf_resume(struct platform_device *dev)
+{
+	struct mvf_port *sport = platform_get_drvdata(dev);
+
+	if (sport)
+		uart_resume_port(&mvf_reg, &sport->port);
+
+	/* Disable UART wakeup */
+
+	return 0;
+}
+
+static int serial_mvf_probe_dt(struct mvf_port *sport,
+		struct platform_device *pdev)
+{
+	struct device_node *np = pdev->dev.of_node;
+	int ret;
+
+	if (!np)
+		/* no device tree device */
+		return 1;
+
+	ret = of_alias_get_id(np, "serial");
+	if (ret < 0) {
+		dev_err(&pdev->dev, "failed to get alias id, errno %d\n", ret);
+		return ret;
+	}
+	sport->port.line = ret;
+
+	if (of_get_property(np, "fsl,uart-fifo-mode", NULL))
+		sport->fifo_en = 1;
+
+	return 0;
+}
+
+static int serial_mvf_probe(struct platform_device *pdev)
+{
+	struct mvf_port *sport;
+	struct imxuart_platform_data *pdata;
+	void __iomem *base;
+	int ret = 0;
+	struct resource *res;
+
+	sport = devm_kzalloc(&pdev->dev, sizeof(*sport), GFP_KERNEL);
+	if (!sport)
+		return -ENOMEM;
+
+	pdev->dev.coherent_dma_mask = 0;
+
+	ret = serial_mvf_probe_dt(sport, pdev);
+	if (ret < 0)
+		return ret ;
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	if (!res)
+		return -ENODEV;
+
+	base = devm_ioremap(&pdev->dev, res->start, PAGE_SIZE);
+	if (!base)
+		return -ENOMEM;
+
+	sport->port.dev = &pdev->dev;
+	sport->port.mapbase = res->start;
+	sport->port.membase = base;
+	sport->port.type = PORT_MVF,
+	sport->port.iotype = UPIO_MEM;
+	sport->port.irq = platform_get_irq(pdev, 0);
+	sport->port.fifosize = 32;
+	sport->port.ops = &mvf_pops;
+	sport->port.flags = UPF_BOOT_AUTOCONF;
+	if (pdev->id >= 0)
+		sport->port.line = pdev->id;
+
+	sport->clk = devm_clk_get(&pdev->dev, "ipg");
+	if (IS_ERR(sport->clk)) {
+		ret = PTR_ERR(sport->clk);
+		dev_err(&pdev->dev, "failed to uart clk: %d\n", ret);
+		return ret;
+	}
+
+	clk_prepare_enable(sport->clk);
+
+	sport->port.uartclk = clk_get_rate(sport->clk);
+
+	mvf_ports[sport->port.line] = sport;
+
+	pdata = pdev->dev.platform_data;
+
+	/* all uarts support hardware RTS/CTS */
+	sport->have_rtscts = 1;
+
+	if (pdata && pdata->init) {
+		ret = pdata->init(pdev);
+		if (ret)
+			goto clkput;
+	}
+
+	ret = uart_add_one_port(&mvf_reg, &sport->port);
+
+	if (ret)
+		goto deinit;
+	platform_set_drvdata(pdev, &sport->port);
+
+	return 0;
+deinit:
+	if (pdata && pdata->exit)
+		pdata->exit(pdev);
+clkput:
+	clk_disable_unprepare(sport->clk);
+
+	return ret;
+}
+
+static int serial_mvf_remove(struct platform_device *pdev)
+{
+	struct imxuart_platform_data *pdata;
+	struct mvf_port *sport = platform_get_drvdata(pdev);
+
+	pdata = pdev->dev.platform_data;
+
+	platform_set_drvdata(pdev, NULL);
+
+	if (sport)
+		uart_remove_one_port(&mvf_reg, &sport->port);
+
+	clk_disable_unprepare(sport->clk);
+
+	if (pdata && pdata->exit)
+		pdata->exit(pdev);
+
+	return 0;
+}
+
+static struct platform_driver serial_mvf_driver = {
+	.probe		= serial_mvf_probe,
+	.remove		= serial_mvf_remove,
+
+	.suspend	= serial_mvf_suspend,
+	.resume		= serial_mvf_resume,
+	.id_table       = mvf_uart_devtype,
+	.driver		= {
+		.name	= "mvf-uart",
+		.owner	= THIS_MODULE,
+		.of_match_table = mvf_uart_dt_ids,
+	},
+};
+
+static int __init mvf_serial_init(void)
+{
+	int ret;
+
+	pr_info("Serial: Vybrid Family driver\n");
+
+	ret = uart_register_driver(&mvf_reg);
+	if (ret)
+		return ret;
+
+	ret = platform_driver_register(&serial_mvf_driver);
+	if (ret != 0)
+		uart_unregister_driver(&mvf_reg);
+
+	return 0;
+}
+
+static void __exit mvf_serial_exit(void)
+{
+	platform_driver_unregister(&serial_mvf_driver);
+	uart_unregister_driver(&mvf_reg);
+}
+
+module_init(mvf_serial_init);
+module_exit(mvf_serial_exit);
+
+MODULE_DESCRIPTION("Vybrid Family serial port driver");
+MODULE_LICENSE("GPL");
diff --git a/include/uapi/linux/serial_core.h b/include/uapi/linux/serial_core.h
index 74c2bf7..ffb7192 100644
--- a/include/uapi/linux/serial_core.h
+++ b/include/uapi/linux/serial_core.h
@@ -226,4 +226,7 @@
 /* Rocketport EXPRESS/INFINITY */
 #define PORT_RP2	102
 
+/* Freescale Vybrid uart */
+#define PORT_MVF	103
+
 #endif /* _UAPILINUX_SERIAL_CORE_H */
-- 
1.8.0




From b35083 at freescale.com  Fri Apr 12 03:12:45 2013
From: b35083 at freescale.com (Jingchang Lu)
Date: Fri, 12 Apr 2013 15:12:45 +0800
Subject: [PATCH] ethernet/fec: Add Vybrid family fec support
Message-ID: <1365750765-3615-1-git-send-email-b35083@freescale.com>

Freescale Vybrid platform implentments MAC-ENET core
providing compatibility with half- or full-duplex
10/100 Mbit/s Ethernet LANs.

Signed-off-by: Jingchang Lu <b35083 at freescale.com>
---
 drivers/net/ethernet/freescale/fec.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/drivers/net/ethernet/freescale/fec.c b/drivers/net/ethernet/freescale/fec.c
index f292c3a..c27d748 100644
--- a/drivers/net/ethernet/freescale/fec.c
+++ b/drivers/net/ethernet/freescale/fec.c
@@ -107,6 +107,9 @@ static struct platform_device_id fec_devtype[] = {
 		.driver_data = FEC_QUIRK_ENET_MAC | FEC_QUIRK_HAS_GBIT |
 				FEC_QUIRK_HAS_BUFDESC_EX,
 	}, {
+		.name = "mvf-fec",
+		.driver_data = FEC_QUIRK_ENET_MAC,
+	}, {
 		/* sentinel */
 	}
 };
@@ -117,6 +120,7 @@ enum imx_fec_type {
 	IMX27_FEC,	/* runs on i.mx27/35/51 */
 	IMX28_FEC,
 	IMX6Q_FEC,
+	MVF_FEC,
 };
 
 static const struct of_device_id fec_dt_ids[] = {
@@ -124,6 +128,7 @@ static const struct of_device_id fec_dt_ids[] = {
 	{ .compatible = "fsl,imx27-fec", .data = &fec_devtype[IMX27_FEC], },
 	{ .compatible = "fsl,imx28-fec", .data = &fec_devtype[IMX28_FEC], },
 	{ .compatible = "fsl,imx6q-fec", .data = &fec_devtype[IMX6Q_FEC], },
+	{ .compatible = "fsl,mvf-fec", .data = &fec_devtype[MVF_FEC], },
 	{ /* sentinel */ }
 };
 MODULE_DEVICE_TABLE(of, fec_dt_ids);
-- 
1.8.0




From maxime.ripard at free-electrons.com  Fri Apr 12 04:00:01 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Fri, 12 Apr 2013 10:00:01 +0200
Subject: [PATCH RESEND 0/2] Add support for the Solomon SSD1306 OLED Controller
Message-ID: <1365753603-4438-1-git-send-email-maxime.ripard@free-electrons.com>

Hi,

This patchset adds the needed bits to the ssd1307fb driver to support the
very similar Solomon SSD1306 controller.

Since the SSD1307 has been replaced by the SSD1306 in the latest CFA-10036
production samples, we also need to change the device tree accordingly.

Thanks,
Maxime

Maxime Ripard (2):
  video: ssd1307fb: Add support for SSD1306 OLED controller
  ARM: dts: cfa10036: Change the OLED display to SSD1306

 .../devicetree/bindings/video/ssd1307fb.txt        |   10 +-
 arch/arm/boot/dts/imx28-cfa10036.dts               |   14 +-
 arch/arm/boot/dts/imx28-cfa10049.dts               |    4 +-
 drivers/video/ssd1307fb.c                          |  267 ++++++++++++++------
 4 files changed, 210 insertions(+), 85 deletions(-)

-- 
1.7.10.4



From maxime.ripard at free-electrons.com  Fri Apr 12 04:00:03 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Fri, 12 Apr 2013 10:00:03 +0200
Subject: [PATCH 2/2] ARM: dts: cfa10036: Change the OLED display to SSD1306
In-Reply-To: <1365753603-4438-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1365753603-4438-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1365753603-4438-3-git-send-email-maxime.ripard@free-electrons.com>

The SSD1307 was used in an early prototype that will never get
distributed. The final board now has a SSD1306 instead, that has its own
power generation unit and thus doesn't need any PWM. The panel attached
to it also changed.

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 arch/arm/boot/dts/imx28-cfa10036.dts |   14 +++++---------
 arch/arm/boot/dts/imx28-cfa10049.dts |    4 ++--
 2 files changed, 7 insertions(+), 11 deletions(-)

diff --git a/arch/arm/boot/dts/imx28-cfa10036.dts b/arch/arm/boot/dts/imx28-cfa10036.dts
index 1594694..40488f5a8 100644
--- a/arch/arm/boot/dts/imx28-cfa10036.dts
+++ b/arch/arm/boot/dts/imx28-cfa10036.dts
@@ -58,12 +58,6 @@
 		};
 
 		apbx at 80040000 {
-			pwm: pwm at 80064000 {
-				pinctrl-names = "default";
-				pinctrl-0 = <&pwm4_pins_a>;
-				status = "okay";
-			};
-
 			duart: serial at 80074000 {
 				pinctrl-names = "default";
 				pinctrl-0 = <&duart_pins_b>;
@@ -75,11 +69,13 @@
 				pinctrl-0 = <&i2c0_pins_b>;
 				status = "okay";
 
-				ssd1307: oled at 3c {
-					compatible = "solomon,ssd1307fb-i2c";
+				ssd1306: oled at 3c {
+					compatible = "solomon,ssd1306fb-i2c";
 					reg = <0x3c>;
-					pwms = <&pwm 4 3000>;
 					reset-gpios = <&gpio2 7 0>;
+					solomon,height = <32>;
+					solomon,width = <128>;
+					solomon,page-offset = <0>;
 				};
 			};
 		};
diff --git a/arch/arm/boot/dts/imx28-cfa10049.dts b/arch/arm/boot/dts/imx28-cfa10049.dts
index a0d3e9f..ded7784 100644
--- a/arch/arm/boot/dts/imx28-cfa10049.dts
+++ b/arch/arm/boot/dts/imx28-cfa10049.dts
@@ -132,8 +132,8 @@
 
 		apbx at 80040000 {
 			pwm: pwm at 80064000 {
-				pinctrl-names = "default", "default";
-				pinctrl-1 = <&pwm3_pins_b>;
+				pinctrl-names = "default";
+				pinctrl-0 = <&pwm3_pins_b>;
 				status = "okay";
 			};
 
-- 
1.7.10.4



From maxime.ripard at free-electrons.com  Fri Apr 12 04:00:02 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Fri, 12 Apr 2013 10:00:02 +0200
Subject: [PATCH 1/2] video: ssd1307fb: Add support for SSD1306 OLED controller
In-Reply-To: <1365753603-4438-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1365753603-4438-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1365753603-4438-2-git-send-email-maxime.ripard@free-electrons.com>

The Solomon SSD1306 OLED controller is very similar to the SSD1307,
except for the fact that the power is given through an external PWM for
the 1307, and while the 1306 can generate its own power without any PWM.

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 .../devicetree/bindings/video/ssd1307fb.txt        |   10 +-
 drivers/video/ssd1307fb.c                          |  267 ++++++++++++++------
 2 files changed, 203 insertions(+), 74 deletions(-)

diff --git a/Documentation/devicetree/bindings/video/ssd1307fb.txt b/Documentation/devicetree/bindings/video/ssd1307fb.txt
index 3d0060c..7a12542 100644
--- a/Documentation/devicetree/bindings/video/ssd1307fb.txt
+++ b/Documentation/devicetree/bindings/video/ssd1307fb.txt
@@ -1,13 +1,17 @@
 * Solomon SSD1307 Framebuffer Driver
 
 Required properties:
-  - compatible: Should be "solomon,ssd1307fb-<bus>". The only supported bus for
-    now is i2c.
+  - compatible: Should be "solomon,<chip>fb-<bus>". The only supported bus for
+    now is i2c, and the supported chips are ssd1306 and ssd1307.
   - reg: Should contain address of the controller on the I2C bus. Most likely
          0x3c or 0x3d
   - pwm: Should contain the pwm to use according to the OF device tree PWM
-         specification [0]
+         specification [0]. Only required for the ssd1307.
   - reset-gpios: Should contain the GPIO used to reset the OLED display
+  - solomon,height: Height in pixel of the screen driven by the controller
+  - solomon,width: Width in pixel of the screen driven by the controller
+  - solomon,page-offset: Offset of pages (band of 8 pixels) that the screen is
+    mapped to.
 
 Optional properties:
   - reset-active-low: Is the reset gpio is active on physical low?
diff --git a/drivers/video/ssd1307fb.c b/drivers/video/ssd1307fb.c
index 395cb6a..95f76e2 100644
--- a/drivers/video/ssd1307fb.c
+++ b/drivers/video/ssd1307fb.c
@@ -16,24 +16,39 @@
 #include <linux/pwm.h>
 #include <linux/delay.h>
 
-#define SSD1307FB_WIDTH			96
-#define SSD1307FB_HEIGHT		16
-
 #define SSD1307FB_DATA			0x40
 #define SSD1307FB_COMMAND		0x80
 
 #define SSD1307FB_CONTRAST		0x81
+#define	SSD1307FB_CHARGE_PUMP		0x8d
 #define SSD1307FB_SEG_REMAP_ON		0xa1
 #define SSD1307FB_DISPLAY_OFF		0xae
+#define SSD1307FB_SET_MULTIPLEX_RATIO	0xa8
 #define SSD1307FB_DISPLAY_ON		0xaf
 #define SSD1307FB_START_PAGE_ADDRESS	0xb0
+#define SSD1307FB_SET_DISPLAY_OFFSET	0xd3
+#define	SSD1307FB_SET_CLOCK_FREQ	0xd5
+#define	SSD1307FB_SET_PRECHARGE_PERIOD	0xd9
+#define	SSD1307FB_SET_COM_PINS_CONFIG	0xda
+#define	SSD1307FB_SET_VCOMH		0xdb
+
+struct ssd1307fb_par;
+
+struct ssd1307fb_ops {
+	int (*init)(struct ssd1307fb_par *);
+	int (*remove)(struct ssd1307fb_par *);
+};
 
 struct ssd1307fb_par {
 	struct i2c_client *client;
+	u32 height;
 	struct fb_info *info;
+	struct ssd1307fb_ops *ops;
+	u32 page_offset;
 	struct pwm_device *pwm;
 	u32 pwm_period;
 	int reset;
+	u32 width;
 };
 
 static struct fb_fix_screeninfo ssd1307fb_fix = {
@@ -43,15 +58,10 @@ static struct fb_fix_screeninfo ssd1307fb_fix = {
 	.xpanstep	= 0,
 	.ypanstep	= 0,
 	.ywrapstep	= 0,
-	.line_length	= SSD1307FB_WIDTH / 8,
 	.accel		= FB_ACCEL_NONE,
 };
 
 static struct fb_var_screeninfo ssd1307fb_var = {
-	.xres		= SSD1307FB_WIDTH,
-	.yres		= SSD1307FB_HEIGHT,
-	.xres_virtual	= SSD1307FB_WIDTH,
-	.yres_virtual	= SSD1307FB_HEIGHT,
 	.bits_per_pixel	= 1,
 };
 
@@ -134,16 +144,16 @@ static void ssd1307fb_update_display(struct ssd1307fb_par *par)
 	 *  (5) A4 B4 C4 D4 E4 F4 G4 H4
 	 */
 
-	for (i = 0; i < (SSD1307FB_HEIGHT / 8); i++) {
-		ssd1307fb_write_cmd(par->client, SSD1307FB_START_PAGE_ADDRESS + (i + 1));
+	for (i = 0; i < (par->height / 8); i++) {
+		ssd1307fb_write_cmd(par->client, SSD1307FB_START_PAGE_ADDRESS + i + par->page_offset);
 		ssd1307fb_write_cmd(par->client, 0x00);
 		ssd1307fb_write_cmd(par->client, 0x10);
 
-		for (j = 0; j < SSD1307FB_WIDTH; j++) {
+		for (j = 0; j < par->width; j++) {
 			u8 buf = 0;
 			for (k = 0; k < 8; k++) {
-				u32 page_length = SSD1307FB_WIDTH * i;
-				u32 index = page_length + (SSD1307FB_WIDTH * k + j) / 8;
+				u32 page_length = par->width * i;
+				u32 index = page_length + (par->width * k + j) / 8;
 				u8 byte = *(vmem + index);
 				u8 bit = byte & (1 << (j % 8));
 				bit = bit >> (j % 8);
@@ -227,16 +237,137 @@ static struct fb_deferred_io ssd1307fb_defio = {
 	.deferred_io	= ssd1307fb_deferred_io,
 };
 
+static int ssd1307fb_ssd1307_init(struct ssd1307fb_par *par) {
+	int ret;
+
+	par->pwm = pwm_get(&par->client->dev, NULL);
+	if (IS_ERR(par->pwm)) {
+		dev_err(&par->client->dev, "Could not get PWM from device tree!\n");
+		return PTR_ERR(par->pwm);
+	}
+
+	par->pwm_period = pwm_get_period(par->pwm);
+	/* Enable the PWM */
+	pwm_config(par->pwm, par->pwm_period / 2, par->pwm_period);
+	pwm_enable(par->pwm);
+
+	dev_dbg(&par->client->dev, "Using PWM%d with a %dns period.\n", par->pwm->pwm, par->pwm_period);
+
+	/* Map column 127 of the OLED to segment 0 */
+	ret = ssd1307fb_write_cmd(par->client, SSD1307FB_SEG_REMAP_ON);
+	if (ret < 0)
+		return ret;
+
+	/* Turn on the display */
+	ret = ssd1307fb_write_cmd(par->client, SSD1307FB_DISPLAY_ON);
+	if (ret < 0)
+		return ret;
+
+	return 0;
+}
+
+static int ssd1307fb_ssd1307_remove(struct ssd1307fb_par *par) {
+	pwm_disable(par->pwm);
+	pwm_put(par->pwm);
+	return 0;
+}
+
+static struct ssd1307fb_ops ssd1307fb_ssd1307_ops = {
+	.init	= ssd1307fb_ssd1307_init,
+	.remove	= ssd1307fb_ssd1307_remove,
+};
+
+static int ssd1307fb_ssd1306_init(struct ssd1307fb_par *par) {
+	int ret;
+
+	/* Set initial contrast */
+	ret = ssd1307fb_write_cmd(par->client, SSD1307FB_CONTRAST);
+	ret = ret & ssd1307fb_write_cmd(par->client, 0x7f);
+	if (ret < 0)
+		return ret;
+
+	/* Set COM direction */
+	ret = ssd1307fb_write_cmd(par->client, 0xc8);
+	if (ret < 0)
+		return ret;
+
+	/* Set segment re-map */
+	ret = ssd1307fb_write_cmd(par->client, SSD1307FB_SEG_REMAP_ON);
+	if (ret < 0)
+		return ret;
+
+	/* Set multiplex ratio value */
+	ret = ssd1307fb_write_cmd(par->client, SSD1307FB_SET_MULTIPLEX_RATIO);
+	ret = ret & ssd1307fb_write_cmd(par->client, par->height - 1);
+	if (ret < 0)
+		return ret;
+
+	/* set display offset value */
+	ret = ssd1307fb_write_cmd(par->client, SSD1307FB_SET_DISPLAY_OFFSET);
+	ret = ssd1307fb_write_cmd(par->client, 0x20);
+	if (ret < 0)
+		return ret;
+
+	/* Set clock frequency */
+	ret = ssd1307fb_write_cmd(par->client, SSD1307FB_SET_CLOCK_FREQ);
+	ret = ret & ssd1307fb_write_cmd(par->client, 0xf0);
+	if (ret < 0)
+		return ret;
+
+	/* Set precharge period in number of ticks from the internal clock */
+	ret = ssd1307fb_write_cmd(par->client, SSD1307FB_SET_PRECHARGE_PERIOD);
+	ret = ret & ssd1307fb_write_cmd(par->client, 0x22);
+	if (ret < 0)
+		return ret;
+
+	/* Set COM pins configuration */
+	ret = ssd1307fb_write_cmd(par->client, SSD1307FB_SET_COM_PINS_CONFIG);
+	ret = ret & ssd1307fb_write_cmd(par->client, 0x22);
+	if (ret < 0)
+		return ret;
+
+	/* Set VCOMH */
+	ret = ssd1307fb_write_cmd(par->client, SSD1307FB_SET_VCOMH);
+	ret = ret & ssd1307fb_write_cmd(par->client, 0x49);
+	if (ret < 0)
+		return ret;
+
+	/* Turn on the DC-DC Charge Pump */
+	ret = ssd1307fb_write_cmd(par->client, SSD1307FB_CHARGE_PUMP);
+	ret = ret & ssd1307fb_write_cmd(par->client, 0x14);
+	if (ret < 0)
+		return ret;
+
+	/* Turn on the display */
+	ret = ssd1307fb_write_cmd(par->client, SSD1307FB_DISPLAY_ON);
+	if (ret < 0)
+		return ret;
+
+	return 0;
+}
+
+static struct ssd1307fb_ops ssd1307fb_ssd1306_ops = {
+	.init	= ssd1307fb_ssd1306_init,
+};
+
+static const struct of_device_id ssd1307fb_of_match[] = {
+	{ .compatible = "solomon,ssd1306fb-i2c", .data = (void*)&ssd1307fb_ssd1306_ops },
+	{ .compatible = "solomon,ssd1307fb-i2c", .data = (void*)&ssd1307fb_ssd1307_ops },
+	{},
+};
+MODULE_DEVICE_TABLE(of, ssd1307fb_of_match);
+
 static int ssd1307fb_probe(struct i2c_client *client,
 			   const struct i2c_device_id *id)
 {
 	struct fb_info *info;
-	u32 vmem_size = SSD1307FB_WIDTH * SSD1307FB_HEIGHT / 8;
+	struct device_node *node = client->dev.of_node;
+	u32 vmem_size;
 	struct ssd1307fb_par *par;
 	u8 *vmem;
 	int ret;
 
-	if (!client->dev.of_node) {
+	if (!node) {
 		dev_err(&client->dev, "No device tree data found!\n");
 		return -EINVAL;
 	}
@@ -247,6 +378,36 @@ static int ssd1307fb_probe(struct i2c_client *client,
 		return -ENOMEM;
 	}
 
+	par = info->par;
+	par->info = info;
+	par->client = client;
+
+	par->ops = (struct ssd1307fb_ops*)of_match_device(ssd1307fb_of_match, &client->dev)->data;
+
+	par->reset = of_get_named_gpio(client->dev.of_node,
+					 "reset-gpios", 0);
+	if (!gpio_is_valid(par->reset)) {
+		ret = -EINVAL;
+		goto fb_alloc_error;
+	}
+
+	if (of_property_read_u32(node, "solomon,width", &par->width))
+		par->width = 96;
+
+	printk("Width\t%u\n", par->width);
+
+	if (of_property_read_u32(node, "solomon,height", &par->height))
+		par->width = 16;
+
+	printk("Height\t%u\n", par->height);
+
+	if (of_property_read_u32(node, "solomon,page-offset", &par->page_offset))
+		par->page_offset = 1;
+
+	printk("Offset\t%u\n", par->page_offset);
+
+	vmem_size = par->width * par->height / 8;
+
 	vmem = devm_kzalloc(&client->dev, vmem_size, GFP_KERNEL);
 	if (!vmem) {
 		dev_err(&client->dev, "Couldn't allocate graphical memory.\n");
@@ -256,9 +417,15 @@ static int ssd1307fb_probe(struct i2c_client *client,
 
 	info->fbops = &ssd1307fb_ops;
 	info->fix = ssd1307fb_fix;
+	info->fix.line_length = par->width / 8;
 	info->fbdefio = &ssd1307fb_defio;
 
 	info->var = ssd1307fb_var;
+	info->var.xres = par->width;
+	info->var.xres_virtual = par->width;
+	info->var.yres = par->height;
+	info->var.yres_virtual = par->height;
+
 	info->var.red.length = 1;
 	info->var.red.offset = 0;
 	info->var.green.length = 1;
@@ -272,17 +439,6 @@ static int ssd1307fb_probe(struct i2c_client *client,
 
 	fb_deferred_io_init(info);
 
-	par = info->par;
-	par->info = info;
-	par->client = client;
-
-	par->reset = of_get_named_gpio(client->dev.of_node,
-					 "reset-gpios", 0);
-	if (!gpio_is_valid(par->reset)) {
-		ret = -EINVAL;
-		goto reset_oled_error;
-	}
-
 	ret = devm_gpio_request_one(&client->dev, par->reset,
 				    GPIOF_OUT_INIT_HIGH,
 				    "oled-reset");
@@ -293,23 +449,6 @@ static int ssd1307fb_probe(struct i2c_client *client,
 		goto reset_oled_error;
 	}
 
-	par->pwm = pwm_get(&client->dev, NULL);
-	if (IS_ERR(par->pwm)) {
-		dev_err(&client->dev, "Could not get PWM from device tree!\n");
-		ret = PTR_ERR(par->pwm);
-		goto pwm_error;
-	}
-
-	par->pwm_period = pwm_get_period(par->pwm);
-
-	dev_dbg(&client->dev, "Using PWM%d with a %dns period.\n", par->pwm->pwm, par->pwm_period);
-
-	ret = register_framebuffer(info);
-	if (ret) {
-		dev_err(&client->dev, "Couldn't register the framebuffer\n");
-		goto fbreg_error;
-	}
-
 	i2c_set_clientdata(client, info);
 
 	/* Reset the screen */
@@ -318,34 +457,25 @@ static int ssd1307fb_probe(struct i2c_client *client,
 	gpio_set_value(par->reset, 1);
 	udelay(4);
 
-	/* Enable the PWM */
-	pwm_config(par->pwm, par->pwm_period / 2, par->pwm_period);
-	pwm_enable(par->pwm);
-
-	/* Map column 127 of the OLED to segment 0 */
-	ret = ssd1307fb_write_cmd(client, SSD1307FB_SEG_REMAP_ON);
-	if (ret < 0) {
-		dev_err(&client->dev, "Couldn't remap the screen.\n");
-		goto remap_error;
+	if (par->ops->init) {
+		ret = par->ops->init(par);
+		if (ret)
+			goto reset_oled_error;
 	}
 
-	/* Turn on the display */
-	ret = ssd1307fb_write_cmd(client, SSD1307FB_DISPLAY_ON);
-	if (ret < 0) {
-		dev_err(&client->dev, "Couldn't turn the display on.\n");
-		goto remap_error;
+	ret = register_framebuffer(info);
+	if (ret) {
+		dev_err(&client->dev, "Couldn't register the framebuffer\n");
+		goto panel_init_error;
 	}
 
 	dev_info(&client->dev, "fb%d: %s framebuffer device registered, using %d bytes of video memory\n", info->node, info->fix.id, vmem_size);
 
 	return 0;
 
-remap_error:
-	unregister_framebuffer(info);
-	pwm_disable(par->pwm);
-fbreg_error:
-	pwm_put(par->pwm);
-pwm_error:
+panel_init_error:
+	if (par->ops->remove)
+		par->ops->remove(par);
 reset_oled_error:
 	fb_deferred_io_cleanup(info);
 fb_alloc_error:
@@ -359,8 +489,8 @@ static int ssd1307fb_remove(struct i2c_client *client)
 	struct ssd1307fb_par *par = info->par;
 
 	unregister_framebuffer(info);
-	pwm_disable(par->pwm);
-	pwm_put(par->pwm);
+	if (par->ops->remove)
+		par->ops->remove(par);
 	fb_deferred_io_cleanup(info);
 	framebuffer_release(info);
 
@@ -368,17 +498,12 @@ static int ssd1307fb_remove(struct i2c_client *client)
 }
 
 static const struct i2c_device_id ssd1307fb_i2c_id[] = {
+	{ "ssd1306fb", 0 },
 	{ "ssd1307fb", 0 },
 	{ }
 };
 MODULE_DEVICE_TABLE(i2c, ssd1307fb_i2c_id);
 
-static const struct of_device_id ssd1307fb_of_match[] = {
-	{ .compatible = "solomon,ssd1307fb-i2c" },
-	{},
-};
-MODULE_DEVICE_TABLE(of, ssd1307fb_of_match);
-
 static struct i2c_driver ssd1307fb_driver = {
 	.probe = ssd1307fb_probe,
 	.remove = ssd1307fb_remove,
-- 
1.7.10.4



From arnd at arndb.de  Fri Apr 12 04:11:12 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 12 Apr 2013 10:11:12 +0200
Subject: [PATCH v3 05/10] i2c: s3c2410: make header file local
In-Reply-To: <201304112343.34534.heiko@sntech.de>
References: <1365716245-99231-1-git-send-email-arnd@arndb.de>
 <1365716245-99231-6-git-send-email-arnd@arndb.de>
 <201304112343.34534.heiko@sntech.de>
Message-ID: <201304121011.13028.arnd@arndb.de>

On Thursday 11 April 2013, Heiko St?bner wrote:
> Am Donnerstag, 11. April 2013, 23:37:20 schrieb Arnd Bergmann:
> > No other file in the kernel besides i2c-s3c2410.c uses the current
> > plat/regs-iic.h, so we can simply move the header file to live in the
> > same directory as the driver, as a preparation to multiplatform builds.
> 
> There is already a patch doing similar changes [0] in the i2c tree for 3.10
> 

Excellent, that patch is actually nicer than my version, thanks for taking
care of this! I'll drop my patch from the series then.

	Arnd


From laurent.pinchart at ideasonboard.com  Fri Apr 12 04:22:41 2013
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Fri, 12 Apr 2013 10:22:41 +0200
Subject: [PATCH v8 1/7] media: V4L2: add temporary clock helpers
In-Reply-To: <20130411231923.7915.17215@quantum>
References: <CAGsJ_4zCRBvEX9xEDCr27JLK6wYp_2T_wk2hzVjqpKinbL=9pg@mail.gmail.com>
 <13951098.tvATHWRRmI@avalon> <20130411231923.7915.17215@quantum>
Message-ID: <1682270.VnHBnRB9ZY@avalon>

Hi Mike,

On Thursday 11 April 2013 16:19:23 Mike Turquette wrote:
> Quoting Laurent Pinchart (2013-04-11 15:35:38)
> > On Thursday 11 April 2013 11:52:58 Mike Turquette wrote:

[snip]

> > > I came into this thread late and don't have the actual patches in my
> > > inbox for review.  That said, I don't understand why V4L2 cares about
> > > the clk framework *implementation*?  The clk.h api is the same for
> > > platforms using the common struct clk and those still using the legacy
> > > method of defining their own struct clk.  If drivers are only consumers
> > > of the clk.h api then the implementation underneath should not matter.
> > 
> > The issue on non-CCF systems is that devices usually can't register clocks
> > dynamically. (Most of) those systems provide system clocks only through
> > their clock API, without a way for the camera IP core to hook up the
> > clock(s) it can provide to the camera sensor. On the consumer side we
> > don't care much about the clock framework implementation, but on the
> > provider side we need a framework that allows registering non-system
> > clocks at runtime.
> 
> Yes, you do care about the clock framework implementation if you are a clock
> provider.  I still haven't gone through the archives to find these patches
> but I hope that any dependency on CONFIG_COMMON_CLK is conditionalized to
> have the smallest impact possible. Making v4l2 as a whole depend on
> COMMON_CLK might be a bit overkill compared to just making individual camera
> drivers depend on it.

The basic idea is to push the dependency on CONFIG_COMMON_CLK to individual 
drivers, and provide a V4L2-specific clock framework (that looks like a 
stripped-down version of CCF) for platforms that don't implement CCF yet.

-- 
Regards,

Laurent Pinchart



From andrew.murray at arm.com  Fri Apr 12 04:22:29 2013
From: andrew.murray at arm.com (Andrew Murray)
Date: Fri, 12 Apr 2013 09:22:29 +0100
Subject: [PATCH 11/11] RFC: ARM: get PCI device IRQs from device tree
In-Reply-To: <CACRpkdZhPYqxgUuffTabN+RZkTBY2w0t-OmJ8Wsew8qOWTRQ7A@mail.gmail.com>
References: <1365087696-9548-4-git-send-email-linus.walleij@linaro.org>
 <1365087696-9548-5-git-send-email-linus.walleij@linaro.org>
 <1365087696-9548-6-git-send-email-linus.walleij@linaro.org>
 <1365087696-9548-7-git-send-email-linus.walleij@linaro.org>
 <1365087696-9548-8-git-send-email-linus.walleij@linaro.org>
 <1365087696-9548-9-git-send-email-linus.walleij@linaro.org>
 <1365087696-9548-10-git-send-email-linus.walleij@linaro.org>
 <1365087696-9548-11-git-send-email-linus.walleij@linaro.org>
 <1365087696-9548-12-git-send-email-linus.walleij@linaro.org>
 <CACRpkdZhPYqxgUuffTabN+RZkTBY2w0t-OmJ8Wsew8qOWTRQ7A@mail.gmail.com>
Message-ID: <20130412082229.GA30593@arm.com>

On Thu, Apr 11, 2013 at 09:27:53PM +0100, Linus Walleij wrote:
> On Thu, Apr 4, 2013 at 5:01 PM, Linus Walleij <linus.walleij at linaro.org> wrote:
> 
> > This currently bugs out - when trying to get the IRQs for
> > devices of_irq_map_pci() reads the IRQ pin from the PCI config
> > space successfully, then comes to trying to look up the parent
> > PCI device by checking pdev->bus->self, which is NULL, then
> > tries to treat it as a bridge doing pci_bus_to_OF_node(pdev->bus)
> > which also results in NULL and it bails out.
> >
> > No clue why this is so - some problem with the parent of this
> > bus not being a PCI device in itself? Help.
> 
> Tracked this down to a point where in drivers/pci/of.c
> pci_set_bus_of_node() is called on the root bus, at which
> point it calls pcibios_get_phb_of_node() which has no clue
> on how to obtain the DT node for the root hub. (Only bridges.)
> 
> Inserting this na?ve fragment into the PCI driver makes things
> tick:
> 
> +struct device_node *static_root;
> +
> +struct device_node *pcibios_get_phb_of_node(struct pci_bus *bus)
> +{
> +       return static_root;
> +}
> +
> 
> In probe():
> +       static_root = np;
> 
> It'll override the weak symbol and make things work.
> 
> I guess this is something for kernel/bios32.c to implement
> if we want to support DT on these PCI adapters, so looking
> into that next...
> 
> But how do others get their things to work? Not using bios32?
> I wonder...

I think there are a mix of solutions out here, let me try and remember...

* I originally [1] implemented a pcibios_get_phb_of_node function
  in arch/arm/bios32.c this used a new .of_node field from sysdata.
  The idea being that pcibios_init_hw populates .of_node from a field
  of the same name provided by the driver in hw_pci.

* I believe Thierry's approach was to reuse the existing pcibios_get_phb_of_node
  function [2], to do this some changes were needed elsewhere I'm not sure the
  full details of this, I never got around to testing it. But I understand it's
  an approach that Thomas also used. It believe it requries a custom
  implementation of hw->scan such that instead of using pcibios_init_hw's default
  implementation of pci_scan_root_bus (which passes a NULL) your custom
  implementation calls pci_create_root_bus instead and passes a suitable struct
  device.

* I recall having some issues with weak symbols when playing around with
  pcibios_get_phb_of_node - there seems to be some changes in this area [3].

I don't think any of these solutions are ideal - perhaps pcibios_init_hw needs
to be changed... there are patches around which involve passing additional
private data in sys_data/hw_pci see [1] and [4] if this additional data
contains struct device or struct device_node then perhaps they can be plumbed
into the default call to pci_scan_root_bus in bios32? If every ARM DT host
bridge driver needs to implement their own scan function then something isn't
quite right.

I hope that helps.

Andrew Murray

[1] http://patchwork.ozlabs.org/patch/213570
[2] http://www.spinics.net/lists/linux-pci/msg19917.html
[3] http://patchwork1.kernel.org/patch/2394451
[4] http://patchwork.kernel.org/patch/2129431


From prabhakar.csengg at gmail.com  Fri Apr 12 04:26:29 2013
From: prabhakar.csengg at gmail.com (Prabhakar Lad)
Date: Fri, 12 Apr 2013 13:56:29 +0530
Subject: [GIT PULL FOR v3.10] DaVinci media cleanups + Updates
Message-ID: <CA+V-a8sko61y73odE5efJWwqYyMkBqM7_FPrs7Uvh7sdtBsGvA@mail.gmail.com>

Hi Hans/Mauro,

Please pull the following patches for Davinci media. Few patches
contain platform changes for ARM which have been Acked by its maintainer.

Regards,
--Prabhakar Lad

The following changes since commit 81e096c8ac6a064854c2157e0bf802dc4906678c:

  [media] budget: Add support for Philips Semi Sylt PCI ref. design
(2013-04-08 07:28:01 -0300)

are available in the git repository at:
  git://linuxtv.org/mhadli/v4l-dvb-davinci_devices.git for_v3.10

Lad, Prabhakar (6):
      davinci: vpif: add pm_runtime support
      media: davinci: vpss: enable vpss clocks
      media: davinci: vpbe: venc: move the enabling of vpss clocks to driver
      davinic: vpss: trivial cleanup
      ARM: davinci: dm365: add support for v4l2 video display
      ARM: davinci: dm365 EVM: add support for VPBE display

Sekhar Nori (1):
      media: davinci: kconfig: fix incorrect selects

 arch/arm/mach-davinci/board-dm365-evm.c      |  166 ++++++++++++++++++++++-
 arch/arm/mach-davinci/davinci.h              |    8 +-
 arch/arm/mach-davinci/dm355.c                |    7 +-
 arch/arm/mach-davinci/dm365.c                |  195 +++++++++++++++++++++++---
 arch/arm/mach-davinci/dm644x.c               |    9 +-
 arch/arm/mach-davinci/pm_domain.c            |    2 +-
 drivers/media/platform/davinci/Kconfig       |  103 +++++---------
 drivers/media/platform/davinci/Makefile      |   17 +--
 drivers/media/platform/davinci/dm355_ccdc.c  |   39 +-----
 drivers/media/platform/davinci/dm644x_ccdc.c |   44 ------
 drivers/media/platform/davinci/isif.c        |   28 +---
 drivers/media/platform/davinci/vpbe_venc.c   |   25 ++++
 drivers/media/platform/davinci/vpif.c        |   24 +---
 drivers/media/platform/davinci/vpss.c        |   36 ++++-
 14 files changed, 459 insertions(+), 244 deletions(-)


From nsekhar at ti.com  Fri Apr 12 04:28:40 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Fri, 12 Apr 2013 13:58:40 +0530
Subject: [PATCH v8 1/2] ARM: davinci: dm355: add support for v4l2 video
 display
In-Reply-To: <1365413215-3632-2-git-send-email-prabhakar.csengg@gmail.com>
References: <1365413215-3632-1-git-send-email-prabhakar.csengg@gmail.com>
 <1365413215-3632-2-git-send-email-prabhakar.csengg@gmail.com>
Message-ID: <5167C5B8.1070509@ti.com>

On 4/8/2013 2:56 PM, Prabhakar lad wrote:
> From: Lad, Prabhakar <prabhakar.csengg at gmail.com>
> 
> Create platform devices for various video modules like venc,osd,
> vpbe and v4l2 driver for dm355.
> 
> Signed-off-by: Lad, Prabhakar <prabhakar.csengg at gmail.com>

For patches 1/2 and 2/2:

Acked-by: Sekhar Nori <nsekhar at ti.com>

Thanks,
Sekhar


From kishon at ti.com  Fri Apr 12 04:39:36 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Fri, 12 Apr 2013 14:09:36 +0530
Subject: [PATCH v2] ARM: OMAP4: hwmod data: make 'ocp2scp_usb_phy_phy_48m"
 as the main clock
In-Reply-To: <alpine.DEB.2.00.1304101935450.25123@utopia.booyaka.com>
References: <1365496101-7829-1-git-send-email-kishon@ti.com>
 <alpine.DEB.2.00.1304092058450.26840@utopia.booyaka.com>
 <alpine.DEB.2.00.1304101935450.25123@utopia.booyaka.com>
Message-ID: <5167C848.4010203@ti.com>

Hi,

On Thursday 11 April 2013 01:11 AM, Paul Walmsley wrote:
> From: Kishon Vijay Abraham I <kishon at ti.com>
>
> Commit 92702df3570e ("ARM: OMAP4: PM: fix PM regression introduced by recent
> clock cleanup") makes the 'ocp2scp_usb_phy_phy_48m' as optional
> functional clock causing regression in MUSB. But this 48MHz clock is a
> mandatory clock for usb phy attached to ocp2scp and hence made as the main
> clock for ocp2scp.
>
> Cc: Keerthy <j-keerthy at ti.com>
> Cc: Beno?t Cousson <b-cousson at ti.com>
> Cc: Paul Walmsley <paul at pwsan.com>
> Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
> [paul at pwsan.com: add comment to the hwmod data to try to prevent any
>   future mistakes here]
> Signed-off-by: Paul Walmsley <paul at pwsan.com>
> ---
>
> Nothing further received from Kishon per the request:
>
> http://marc.info/?l=linux-omap&m=136554118302342&w=2

Sorry. Missed reading this mail.

Thanks
Kishon


From p.zabel at pengutronix.de  Fri Apr 12 04:42:04 2013
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Fri, 12 Apr 2013 10:42:04 +0200
Subject: [GIT PULL v2] Reset controller API
In-Reply-To: <CAOesGMiyDvC7GXetEZY1Tp=s2jqvU_4gJhvgdYe5TUmdRaogsg@mail.gmail.com>
References: <1365495574.4023.32.camel@pizza.hi.pengutronix.de>
 <20130411102047.GA7437@quad.lixom.net>
 <CAOesGMidoasD35LL4VvCUPwTPrrRE9hxPGUVmuGQtuvH_nxs0g@mail.gmail.com>
 <1365683829.4388.52.camel@pizza.hi.pengutronix.de>
 <20130411171443.GB31066@quad.lixom.net>
 <20130412000340.GA16970@S2101-09.ap.freescale.net>
 <CAOesGMiyDvC7GXetEZY1Tp=s2jqvU_4gJhvgdYe5TUmdRaogsg@mail.gmail.com>
Message-ID: <1365756124.5330.9.camel@pizza.hi.pengutronix.de>

Am Donnerstag, den 11.04.2013, 17:15 -0700 schrieb Olof Johansson:
> On Thu, Apr 11, 2013 at 5:03 PM, Shawn Guo <shawn.guo at linaro.org> wrote:
> > On Thu, Apr 11, 2013 at 10:14:43AM -0700, Olof Johansson wrote:
> >> On Thu, Apr 11, 2013 at 02:37:09PM +0200, Philipp Zabel wrote:
> >> > Hi Olof,
> >> >
> >> > Am Donnerstag, den 11.04.2013, 03:25 -0700 schrieb Olof Johansson:
> >> > > On Thu, Apr 11, 2013 at 3:20 AM, Olof Johansson <olof at lixom.net> wrote:
> >> > > > On Tue, Apr 09, 2013 at 10:19:34AM +0200, Philipp Zabel wrote:
> >> > > >> Hi Olof,
> >> > > >>
> >> > > >> I have added two fixes on top of the reset series at
> >> > > >> git://git.pengutronix.de/git/pza/linux.git reset/for_v3.10.
> >> > > >> Could you pull them in together with the rest?
> >> > > >>
> >> > > >> The following changes since commit 8bb9660418e05bb1845ac1a2428444d78e322cc7:
> >> > > >>
> >> > > >>   Linux 3.9-rc4 (2013-03-23 16:52:44 -0700)
> >> > > >>
> >> > > >> are available in the git repository at:
> >> > > >>
> >> > > >>   git://git.pengutronix.de/git/pza/linux.git reset/for_v3.10
> >> > > >>
> >> > > >> for you to fetch changes up to fbdb93ecb869f02a5f8f145fa06a0984c415a7d4:
> >> > > >>
> >> > > >>   Documentation: gpio-reset.txt: Fix 'initially-in-reset' example (2013-04-09 09:55:00 +0200)
> >> > > >>
> >> > > >> They add a simple API for devices to request being reset by separate
> >> > > >> reset controller hardware and implement the reset signal device tree
> >> > > >> bindings proposed by Stephen Warren.
> >> > > >> The patches have been discussed on the linux-arm-kernel list under the topic
> >> > > >> "Reset controller API to reset IP modules on i.MX5 and i.MX6".
> >> > > >>
> >> > > >> ----------------------------------------------------------------
> >> > > >> Dan Carpenter (1):
> >> > > >>       reset: NULL deref on allocation failure
> >> > > >>
> >> > > >> Fabio Estevam (1):
> >> > > >>       Documentation: gpio-reset.txt: Fix 'initially-in-reset' example
> >> > > >>
> >> > > >> Philipp Zabel (2):
> >> > > >>       reset: Add reset controller API
> >> > > >>       reset: Add driver for gpio-controlled reset pins
> >> > > >>
> >> > > >> Stephen Warren (1):
> >> > > >>       dt: describe base reset signal binding
> >> > > >
> >> > > > Hmm, I don't see an ack or reviewed-by on these subsystem bindings from
> >> > > > neither Rob nor Grant.
> >> > > >
> >> > > > Since it's a brand new subsystem binding, I'd like to see them ack it
> >> > > > before we pick it up.
> >> > >
> >> > > Sigh. Ok, so I now stumbled across the Ack from Rob that you didn't
> >> > > pick up. Don't do it like that again, please. If Shawn prematurely
> >> > > bases his code on top of unacked patches, then that's his problem, not
> >> > > yours.
> >> >
> >> > Sorry I didn't notice that Rob's ack didn't have you in Cc. So shall I
> >> > leave the dt binding patch untouched this time? I'll take note of this
> >> > for the future.
> >>
> >> See below.
> >>
> >> > > The problem still remains though, since the gpio-reset binding hasn't
> >> > > seen an ack on the list, as far as I can tell. And I'll have a comment
> >> > > on that as well in a minute, see separate reply on that patch.
> >> >
> >> > Ok. What would you have me do now? I could revert the gpio-reset patch
> >> > (possibly asking Shawn to pull that, too), and have it do another round
> >> > on the list instead. Or I could address your comments with a relative
> >> > patch, and put that on top.
> >>
> >> This is a case where rebase is fine, as far as I am concerned. Just tell
> >> Shawn to also rebase his dependent code accordingly. That way you can
> >> add Rob's ack too.
> >>
> >> Once the bindings have been ironed out you can add it back, but that's looking
> >> like 3.11 material now.
> >
> > Just to be clear, you are asking Philipp to move patch "reset: Add
> > driver for gpio-controlled reset pins" out (leave it for 3.11), and add
> > Rob's ACK on patch "dt: describe base reset signal binding", and then
> > resend the pull request. Is it correct?
> 
> Yep! We'll stage it as a late branch.

Ok, I've rebased the branch at
    git://git.pengutronix.de/git/pza/linux.git reset/for_v3.10

These gpio-reset patches are dropped:
    reset: Add driver for gpio-controlled reset pins
    Documentation: gpio-reset.txt: Fix 'initially-in-reset' example

And the binding patch
    dt: describe base reset signal binding
now contains Rob's ack.

regards
Philipp



From p.zabel at pengutronix.de  Fri Apr 12 04:42:11 2013
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Fri, 12 Apr 2013 10:42:11 +0200
Subject: [GIT PULL v3] Reset controller API
Message-ID: <1365756131.5330.10.camel@pizza.hi.pengutronix.de>

Hi Olof,

the following changes since commit 8bb9660418e05bb1845ac1a2428444d78e322cc7:

  Linux 3.9-rc4 (2013-03-23 16:52:44 -0700)

are available in the git repository at:

  git://git.pengutronix.de/git/pza/linux.git reset/for_v3.10

for you to fetch changes up to 6034bb22d8387708075c083385e5d2e1072a4f33:

  reset: NULL deref on allocation failure (2013-04-12 10:26:24 +0200)

----------------------------------------------------------------
Dan Carpenter (1):
      reset: NULL deref on allocation failure

Philipp Zabel (1):
      reset: Add reset controller API

Stephen Warren (1):
      dt: describe base reset signal binding

 Documentation/devicetree/bindings/reset/reset.txt |  75 ++++++
 drivers/Kconfig                                   |   2 +
 drivers/Makefile                                  |   3 +
 drivers/reset/Kconfig                             |  13 +
 drivers/reset/Makefile                            |   1 +
 drivers/reset/core.c                              | 297 ++++++++++++++++++++++
 include/linux/reset-controller.h                  |  51 ++++
 include/linux/reset.h                             |  17 ++
 8 files changed, 459 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/reset/reset.txt
 create mode 100644 drivers/reset/Kconfig
 create mode 100644 drivers/reset/Makefile
 create mode 100644 drivers/reset/core.c
 create mode 100644 include/linux/reset-controller.h
 create mode 100644 include/linux/reset.h




From prabhakar.csengg at gmail.com  Fri Apr 12 04:50:06 2013
From: prabhakar.csengg at gmail.com (Prabhakar Lad)
Date: Fri, 12 Apr 2013 14:20:06 +0530
Subject: [GIT PULL FOR v3.10] DaVinci media cleanups + Updates
In-Reply-To: <CA+V-a8sko61y73odE5efJWwqYyMkBqM7_FPrs7Uvh7sdtBsGvA@mail.gmail.com>
References: <CA+V-a8sko61y73odE5efJWwqYyMkBqM7_FPrs7Uvh7sdtBsGvA@mail.gmail.com>
Message-ID: <CA+V-a8u+jNizu8EFfmwwh6kSr913n1JAFkx7r3_MfXrCyWnG0g@mail.gmail.com>

Hi Hans/Mauro,

I have included two more patches in the pull, following is the fresh
pull request.

Regards,
--Prabhakar

The following changes since commit 81e096c8ac6a064854c2157e0bf802dc4906678c:

  [media] budget: Add support for Philips Semi Sylt PCI ref. design
(2013-04-08 07:28:01 -0300)

are available in the git repository at:
  git://linuxtv.org/mhadli/v4l-dvb-davinci_devices.git for_v3.10

Lad, Prabhakar (8):
      davinci: vpif: add pm_runtime support
      media: davinci: vpss: enable vpss clocks
      media: davinci: vpbe: venc: move the enabling of vpss clocks to driver
      davinic: vpss: trivial cleanup
      ARM: davinci: dm365: add support for v4l2 video display
      ARM: davinci: dm365 EVM: add support for VPBE display
      ARM: davinci: dm355: add support for v4l2 video display
      ARM: davinci: dm355 EVM: add support for VPBE display

Sekhar Nori (1):
      media: davinci: kconfig: fix incorrect selects

 arch/arm/mach-davinci/board-dm355-evm.c      |   71 +++++++++-
 arch/arm/mach-davinci/board-dm365-evm.c      |  166 ++++++++++++++++++++++-
 arch/arm/mach-davinci/davinci.h              |   11 ++-
 arch/arm/mach-davinci/dm355.c                |  174 ++++++++++++++++++++++--
 arch/arm/mach-davinci/dm365.c                |  195 +++++++++++++++++++++++---
 arch/arm/mach-davinci/dm644x.c               |    9 +-
 arch/arm/mach-davinci/pm_domain.c            |    2 +-
 drivers/media/platform/davinci/Kconfig       |  103 +++++---------
 drivers/media/platform/davinci/Makefile      |   17 +--
 drivers/media/platform/davinci/dm355_ccdc.c  |   39 +-----
 drivers/media/platform/davinci/dm644x_ccdc.c |   44 ------
 drivers/media/platform/davinci/isif.c        |   28 +---
 drivers/media/platform/davinci/vpbe_venc.c   |   25 ++++
 drivers/media/platform/davinci/vpif.c        |   24 +---
 drivers/media/platform/davinci/vpss.c        |   36 ++++-
 15 files changed, 692 insertions(+), 252 deletions(-)


From linus.walleij at linaro.org  Fri Apr 12 04:51:13 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Fri, 12 Apr 2013 10:51:13 +0200
Subject: [PATCH 11/11] RFC: ARM: get PCI device IRQs from device tree
In-Reply-To: <20130412082229.GA30593@arm.com>
References: <1365087696-9548-4-git-send-email-linus.walleij@linaro.org>
 <1365087696-9548-5-git-send-email-linus.walleij@linaro.org>
 <1365087696-9548-6-git-send-email-linus.walleij@linaro.org>
 <1365087696-9548-7-git-send-email-linus.walleij@linaro.org>
 <1365087696-9548-8-git-send-email-linus.walleij@linaro.org>
 <1365087696-9548-9-git-send-email-linus.walleij@linaro.org>
 <1365087696-9548-10-git-send-email-linus.walleij@linaro.org>
 <1365087696-9548-11-git-send-email-linus.walleij@linaro.org>
 <1365087696-9548-12-git-send-email-linus.walleij@linaro.org>
 <CACRpkdZhPYqxgUuffTabN+RZkTBY2w0t-OmJ8Wsew8qOWTRQ7A@mail.gmail.com>
 <20130412082229.GA30593@arm.com>
Message-ID: <CACRpkdbTKoVMx6mH0sgjJLEFFbDC6u0_HH+79PK2D+=H_FPXfw@mail.gmail.com>

On Fri, Apr 12, 2013 at 10:22 AM, Andrew Murray <andrew.murray at arm.com> wrote:

Thanks for your prompt reply Andrew!

> I don't think any of these solutions are ideal - perhaps pcibios_init_hw needs
> to be changed... there are patches around which involve passing additional
> private data in sys_data/hw_pci see [1] and [4] if this additional data
> contains struct device or struct device_node then perhaps they can be plumbed
> into the default call to pci_scan_root_bus in bios32? If every ARM DT host
> bridge driver needs to implement their own scan function then something isn't
> quite right.

So yesterday I came up with the scheme of augmenting the
pci_common_init() call in bios32.c to take an additional struct device *parent
argument, then pass that to the pci_create_root_bus() call, as it is hard-coded
to NULL in bios32.c today. Current users were patched to pass NULL
as parent.

When you assign that from a struct device* instatiated from the device tree the
node gets properly resolved and the mappings start to work.

However I might have been too sleepy last night and misfired the patch since
it seems it has not yet made it onto the mailing list ... will resend.

Yours,
Linus Walleij


From will.deacon at arm.com  Fri Apr 12 04:57:48 2013
From: will.deacon at arm.com (Will Deacon)
Date: Fri, 12 Apr 2013 09:57:48 +0100
Subject: [PATCH 0/4 v6] arm: introduce psci_smp_ops and use them on Xen
In-Reply-To: <51671A39.6090105@gmail.com>
References: <alpine.DEB.2.02.1304031239550.5078@kaball.uk.xensource.com>
 <alpine.DEB.2.02.1304081102500.5353@kaball.uk.xensource.com>
 <20130411082519.GD31465@quad.lixom.net>
 <51671A39.6090105@gmail.com>
Message-ID: <20130412085748.GC12363@mudshark.cambridge.arm.com>

On Thu, Apr 11, 2013 at 09:16:57PM +0100, Rob Herring wrote:
> On 04/11/2013 03:25 AM, Olof Johansson wrote:
> > On Mon, Apr 08, 2013 at 12:05:17PM +0100, Stefano Stabellini wrote:
> >> Arnd, Olof,
> >> do you have any thoughts on this series?
> >> Would you be happy to carry it in the arm-soc tree?
> >>
> >> The last patch, "xen/arm: introduce xen_early_init, use PSCI on xen" has
> >> a (small) dependency on this series:
> >>
> >> http://marc.info/?l=linux-kernel&m=136430893610688&w=2
> >>
> >> would you be OK with taking that one too, or should that go through the
> >> Xen tree?
> > 
> > I think it'd make sense to get Russell to ack the changes to the core ARM code.
> > We can merge the series through arm-soc, or he can take them, whatever is
> > easiest for everybody.
> > 
> > Given the dependencies on the second branch it might be easier to merge
> > through Russell's tree.
> 
> I'm also dependent on the 1st patch for converting highbank to use PSCI
> and am just waiting on a stable branch to base it on. I believe Russell
> said he is offline for the next week.

By the first patch, do you just mean 6/6 in that series ("[RFC] arm: use PSCI if
available"), or do you have dependencies on others in that series too?

Will


From p.zabel at pengutronix.de  Fri Apr 12 05:03:39 2013
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Fri, 12 Apr 2013 11:03:39 +0200
Subject: [PATCH] ARM i.MX6q: Fix periph_clk2_sel and periph2_clk2_sel
 clocks
In-Reply-To: <20130412030228.GF16970@S2101-09.ap.freescale.net>
References: <1365675812-21600-1-git-send-email-p.zabel@pengutronix.de>
 <20130412030228.GF16970@S2101-09.ap.freescale.net>
Message-ID: <1365757419.5330.17.camel@pizza.hi.pengutronix.de>

Am Freitag, den 12.04.2013, 11:02 +0800 schrieb Shawn Guo:
> On Thu, Apr 11, 2013 at 12:23:32PM +0200, Philipp Zabel wrote:
> > The periph_clk2_sel mux can be set to pll3, pll1, or
> > osc/pll2-bypass/pll2_burn_in_clk.
> 
> Looking at IMX6DQRM Rev. 0, 11/2012, I see
> 
> 13?12 periph_clk2_sel: Selector for peripheral clk2 clock multiplexer
> 
> 	00 derive clock from pll3_sw_clk
> 	01 derive clock from pll1_ref_clk
> 	10 derive clock from pll2_burn_in_clk (default)
> 	11 reserved
> 
> Are you sure pll1_ref_clk actually means pll1_sys?

No, pll1_sys indeed is pll1_sw_clk, not pll1_ref_clk.

> I searched the
> document and word "pll1_ref_clk" occurs only once.  But Figure 18-5. BUS
> clock generation on page 819 suggests it's OSC_CLK (24M).

This is consistent (24 MHz osc is the pll1 reference), and thus might be
correct. I'll fix the patch to keep periph_clk2_sels[1] = "osc".

regards
Philipp

> > The periph2_clk2_sel
> > mux can be set to pll3 or pll2.
> > 
> > Signed-off-by: Philipp Zabel <p.zabel at pengutronix.de>
> > ---
> >  arch/arm/mach-imx/clk-imx6q.c | 7 ++++---
> >  1 file changed, 4 insertions(+), 3 deletions(-)
> > 
> > diff --git a/arch/arm/mach-imx/clk-imx6q.c b/arch/arm/mach-imx/clk-imx6q.c
> > index 65319d5..bdeddf3 100644
> > --- a/arch/arm/mach-imx/clk-imx6q.c
> > +++ b/arch/arm/mach-imx/clk-imx6q.c
> > @@ -177,7 +177,8 @@ int imx6q_set_lpm(enum mxc_cpu_pwr_mode mode)
> >  static const char *step_sels[]	= { "osc", "pll2_pfd2_396m", };
> >  static const char *pll1_sw_sels[]	= { "pll1_sys", "step", };
> >  static const char *periph_pre_sels[]	= { "pll2_bus", "pll2_pfd2_396m", "pll2_pfd0_352m", "pll2_198m", };
> > -static const char *periph_clk2_sels[]	= { "pll3_usb_otg", "osc", };
> > +static const char *periph_clk2_sels[]	= { "pll3_usb_otg", "pll1_sys", "osc", "dummy", };
> > +static const char *periph2_clk2_sels[]	= { "pll3_usb_otg", "pll2_bus", };
> >  static const char *periph_sels[]	= { "periph_pre", "periph_clk2", };
> >  static const char *periph2_sels[]	= { "periph2_pre", "periph2_clk2", };
> >  static const char *axi_sels[]		= { "periph", "pll2_pfd2_396m", "pll3_pfd1_540m", };
> > @@ -369,8 +370,8 @@ int __init mx6q_clocks_init(void)
> >  	clk[pll1_sw]          = imx_clk_mux("pll1_sw",	        base + 0xc,  2,  1, pll1_sw_sels,      ARRAY_SIZE(pll1_sw_sels));
> >  	clk[periph_pre]       = imx_clk_mux("periph_pre",       base + 0x18, 18, 2, periph_pre_sels,   ARRAY_SIZE(periph_pre_sels));
> >  	clk[periph2_pre]      = imx_clk_mux("periph2_pre",      base + 0x18, 21, 2, periph_pre_sels,   ARRAY_SIZE(periph_pre_sels));
> > -	clk[periph_clk2_sel]  = imx_clk_mux("periph_clk2_sel",  base + 0x18, 12, 1, periph_clk2_sels,  ARRAY_SIZE(periph_clk2_sels));
> > -	clk[periph2_clk2_sel] = imx_clk_mux("periph2_clk2_sel", base + 0x18, 20, 1, periph_clk2_sels,  ARRAY_SIZE(periph_clk2_sels));
> > +	clk[periph_clk2_sel]  = imx_clk_mux("periph_clk2_sel",  base + 0x18, 12, 2, periph_clk2_sels,  ARRAY_SIZE(periph_clk2_sels));
> > +	clk[periph2_clk2_sel] = imx_clk_mux("periph2_clk2_sel", base + 0x18, 20, 1, periph2_clk2_sels, ARRAY_SIZE(periph2_clk2_sels));
> >  	clk[axi_sel]          = imx_clk_mux("axi_sel",          base + 0x14, 6,  2, axi_sels,          ARRAY_SIZE(axi_sels));
> >  	clk[esai_sel]         = imx_clk_mux("esai_sel",         base + 0x20, 19, 2, audio_sels,        ARRAY_SIZE(audio_sels));
> >  	clk[asrc_sel]         = imx_clk_mux("asrc_sel",         base + 0x30, 7,  2, audio_sels,        ARRAY_SIZE(audio_sels));
> > -- 
> > 1.8.2.rc2
> > 
> 
> 




From gregory.clement at free-electrons.com  Fri Apr 12 05:04:51 2013
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Fri, 12 Apr 2013 11:04:51 +0200
Subject: [PATCH] clk: Add device tree binding to clk-fixed-factor
In-Reply-To: <20130412065417.GA29291@ab42.lan>
References: <1365608443-30350-1-git-send-email-christian.ruppert@abilis.com>
 <51658BA9.7030508@free-electrons.com> <20130410162747.GG32603@ab42.lan>
 <20130411091952.GF8400@ab42.lan> <5166E41F.7060100@free-electrons.com>
 <20130412065417.GA29291@ab42.lan>
Message-ID: <5167CE33.9010403@free-electrons.com>

On 04/12/2013 08:54 AM, Christian Ruppert wrote:
> On Thu, Apr 11, 2013 at 06:26:07PM +0200, Gregory CLEMENT wrote:
>> On 04/11/2013 11:19 AM, Christian Ruppert wrote:
>>> Hi Gregory,
>>>
>>> Since there doesn't seem to be anyone opposing this feature I just
>>> checked your patch and after adding the CLK_OF_DECLARE macro in the end
>>> it works well for us. Tell me if you would like to rebase and resubmit
>>> your patch or if I should follow up on our own.
>>
>> I can rebase and resubmit my patch, it's pretty straightforward.
>> The problem was the lack of user in the kernel. And by user I mean
>> a driver using these functions. Usually a new function enter in the
>> kernel only if there are users for it inside the kernel so if you plan
>> to submit a driver using this piece of code, then I see no reason
>> to not get it.
> 
> If you add the line
> 
> CLK_OF_DECLARE(fixed_factor_clk, "fixed-factor-clkdiv", 

Why did you add the div suffix?

There is nothing in the function which prevent to have "mul" greater than
"div" and hence having a multiplicative factor.

I think that this suffix is misleading.

> 
> in the end of drivers/clk/clk-fixed-factor.c, the new function will be
> automatically used by of_clk_init(NULL) which itself is used in numerous
> platform ports, in particular arch/arc/plat-tb10x. plat-tb10x is currently
> being integrated in the ARC architecture tree. The device tree file
> requiring this patch is already in linux-next (see
> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/arch/arc/boot/dts/abilis_*.dtsi).
> 
> We didn't know if you wanted to resubmit your patch or if I should
> pursue mine at the time, and today it uses the naming scheme from mine.
> It would be nice if you could either adapt your patch to that naming
> scheme.
> 
> Greetings,
>   Christian
> 
>>> Greetings,
>>>   Christian
>>>
>>> On Wed, Apr 10, 2013 at 06:27:47PM +0200, christian ruppert wrote:
>>>> Hi Gregory,
>>>>
>>>> We use derived clocks with fixed ratios for our TB10x platform. I
>>>> originally had this in the platform code but Vineet (the platform
>>>> maintainer) rightly pointed out that the common clock framework would
>>>> be the correct place for it.
>>>> Is there any reason not to support this functionality? After all, the
>>>> generic fixed rate clock also has a device tree binding and I'd guess
>>>> we're not the only ones statically deriving one clock from another in
>>>> our SOCs.
>>>>
>>>> Greetings,
>>>>   Christian
>>>>
>>>> On Wed, Apr 10, 2013 at 05:56:25PM +0200, Gregory CLEMENT wrote:
>>>>> Hi Christian,
>>>>>
>>>>> On 04/10/2013 05:40 PM, Christian Ruppert wrote:
>>>>>> This patch adds a device tree binding for the simple fixed factor clock
>>>>>> divider/multiplier of the common clock tree binding.
>>>>>
>>>>> This patch remind me of something :
>>>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2012-August/116405.html
>>>>>
>>>>> Do you have a use case for it, this time?
>>>>>
>>>>> My version have been hold off waiting for an user for it.
>>>>> Will you need it for a driver?
>>>>>
>>>>> Regards,
>>>>>
>>>>>>
>>>>>> Signed-off-by: Christian Ruppert <christian.ruppert at abilis.com>
>>>>>> ---
>>>>>>  .../bindings/clock/fixed-factor-clkdiv.txt         |   24 +++++++++++++++
>>>>>>  drivers/clk/clk-fixed-factor.c                     |   32 ++++++++++++++++++++
>>>>>>  include/linux/clk-provider.h                       |    1 +
>>>>>>  3 files changed, 57 insertions(+), 0 deletions(-)
>>>>>>  create mode 100644 Documentation/devicetree/bindings/clock/fixed-factor-clkdiv.txt
>>>>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/clock/fixed-factor-clkdiv.txt b/Documentation/devicetree/bindings/clock/fixed-factor-clkdiv.txt
>>>>>> new file mode 100644
>>>>>> index 0000000..352bac4
>>>>>> --- /dev/null
>>>>>> +++ b/Documentation/devicetree/bindings/clock/fixed-factor-clkdiv.txt
>>>>>> @@ -0,0 +1,24 @@
>>>>>> +Device Tree Clock bindings for plat-tb10x
>>>>>> +
>>>>>> +This binding uses the common clock binding[1].
>>>>>> +
>>>>>> +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
>>>>>> +
>>>>>> +Required properties:
>>>>>> +- compatible : shall be "fixed-factor-clkdiv"
>>>>>> +- #clock-cells: from common clock binding; shall be set to 0
>>>>>> +- clocks: shall be the input parent clock phandle for the clock.
>>>>>> +- clock-mult: defines the multiplication factor of the output clock frequency
>>>>>> +  wrt. the input clock frequency.
>>>>>> +- clock-div: defines the division factor of the output clock frequency wrt.
>>>>>> +  the input clock frequency.
>>>>>> +
>>>>>> +Example:
>>>>>> +cpu_clk: clkdiv_cpu {	/* CPU clock derived from pll0. 1/2 of pll frequency */
>>>>>> +	compatible = "fixed-factor-clkdiv";
>>>>>> +	#clock-cells = <0>;
>>>>>> +	clocks = <&pll0>;
>>>>>> +	clock-mult = <1>;
>>>>>> +	clock-div = <2>;
>>>>>> +	clock-output-names = "cpu_clk";
>>>>>> +};
>>>>>> diff --git a/drivers/clk/clk-fixed-factor.c b/drivers/clk/clk-fixed-factor.c
>>>>>> index 1ef271e..85e45f1 100644
>>>>>> --- a/drivers/clk/clk-fixed-factor.c
>>>>>> +++ b/drivers/clk/clk-fixed-factor.c
>>>>>> @@ -11,6 +11,7 @@
>>>>>>  #include <linux/clk-provider.h>
>>>>>>  #include <linux/slab.h>
>>>>>>  #include <linux/err.h>
>>>>>> +#include <linux/of.h>
>>>>>>  
>>>>>>  /*
>>>>>>   * DOC: basic fixed multiplier and divider clock that cannot gate
>>>>>> @@ -96,3 +97,34 @@ struct clk *clk_register_fixed_factor(struct device *dev, const char *name,
>>>>>>  
>>>>>>  	return clk;
>>>>>>  }
>>>>>> +
>>>>>> +#ifdef CONFIG_OF
>>>>>> +/**
>>>>>> + * of_fixed_factor_clkdiv_setup() - Set up simple fixed factor clock divider
>>>>>> + */
>>>>>> +void of_fixed_factor_clkdiv_setup(struct device_node *node)
>>>>>> +{
>>>>>> +	struct clk *clk;
>>>>>> +	const char *clk_name = node->name;
>>>>>> +	const char *parent_name;
>>>>>> +	u32 mult, div;
>>>>>> +
>>>>>> +	if (of_property_read_u32(node, "clock-mult", &mult))
>>>>>> +		return;
>>>>>> +
>>>>>> +	if (of_property_read_u32(node, "clock-div", &div))
>>>>>> +		return;
>>>>>> +
>>>>>> +	parent_name = of_clk_get_parent_name(node, 0);
>>>>>> +
>>>>>> +	of_property_read_string(node, "clock-output-names", &clk_name);
>>>>>> +
>>>>>> +	clk = clk_register_fixed_factor(NULL, clk_name, parent_name, 0,
>>>>>> +					mult, div);
>>>>>> +	if (!IS_ERR(clk))
>>>>>> +		of_clk_add_provider(node, of_clk_src_simple_get, clk);
>>>>>> +}
>>>>>> +EXPORT_SYMBOL_GPL(of_fixed_factor_clkdiv_setup);
>>>>>> +CLK_OF_DECLARE(fixed_clkdiv, "fixed-factor-clkdiv",
>>>>>> +		of_fixed_factor_clkdiv_setup);
>>>>>> +#endif
>>>>>> diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
>>>>>> index 7f197d7..d4937cf 100644
>>>>>> --- a/include/linux/clk-provider.h
>>>>>> +++ b/include/linux/clk-provider.h
>>>>>> @@ -184,6 +184,7 @@ struct clk *clk_register_fixed_rate(struct device *dev, const char *name,
>>>>>>  		unsigned long fixed_rate);
>>>>>>  
>>>>>>  void of_fixed_clk_setup(struct device_node *np);
>>>>>> +void of_fixed_factor_clkdiv_setup(struct device_node *node);
>>>>>>  
>>>>>>  /**
>>>>>>   * struct clk_gate - gating clock
>>>>>>
>>>>>
>>>>>
>>>>> -- 
>>>>> Gregory Clement, Free Electrons
>>>>> Kernel, drivers, real-time and embedded Linux
>>>>> development, consulting, training and support.
>>>>> http://free-electrons.com
>>>>
>>>> -- 
>>>>   Christian Ruppert              ,          <christian.ruppert at abilis.com>
>>>>                                 /|
>>>>   Tel: +41/(0)22 816 19-42     //|                 3, Chemin du Pr?-Fleuri
>>>>                              _// | bilis Systems   CH-1228 Plan-les-Ouates
>>>
>>
>>
>> -- 
>> Gregory Clement, Free Electrons
>> Kernel, drivers, real-time and embedded Linux
>> development, consulting, training and support.
>> http://free-electrons.com
> 


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From christian.ruppert at abilis.com  Fri Apr 12 05:12:35 2013
From: christian.ruppert at abilis.com (Christian Ruppert)
Date: Fri, 12 Apr 2013 11:12:35 +0200
Subject: [PATCH] clk: Add device tree binding to clk-fixed-factor
In-Reply-To: <5167CE33.9010403@free-electrons.com>
References: <1365608443-30350-1-git-send-email-christian.ruppert@abilis.com>
 <51658BA9.7030508@free-electrons.com>
 <20130410162747.GG32603@ab42.lan> <20130411091952.GF8400@ab42.lan>
 <5166E41F.7060100@free-electrons.com>
 <20130412065417.GA29291@ab42.lan>
 <5167CE33.9010403@free-electrons.com>
Message-ID: <20130412091234.GC29291@ab42.lan>

On Fri, Apr 12, 2013 at 11:04:51AM +0200, Gregory CLEMENT wrote:
> On 04/12/2013 08:54 AM, Christian Ruppert wrote:
> > On Thu, Apr 11, 2013 at 06:26:07PM +0200, Gregory CLEMENT wrote:
> >> On 04/11/2013 11:19 AM, Christian Ruppert wrote:
> >>> Hi Gregory,
> >>>
> >>> Since there doesn't seem to be anyone opposing this feature I just
> >>> checked your patch and after adding the CLK_OF_DECLARE macro in the end
> >>> it works well for us. Tell me if you would like to rebase and resubmit
> >>> your patch or if I should follow up on our own.
> >>
> >> I can rebase and resubmit my patch, it's pretty straightforward.
> >> The problem was the lack of user in the kernel. And by user I mean
> >> a driver using these functions. Usually a new function enter in the
> >> kernel only if there are users for it inside the kernel so if you plan
> >> to submit a driver using this piece of code, then I see no reason
> >> to not get it.
> > 
> > If you add the line
> > 
> > CLK_OF_DECLARE(fixed_factor_clk, "fixed-factor-clkdiv", 
> 
> Why did you add the div suffix?
> 
> There is nothing in the function which prevent to have "mul" greater than
> "div" and hence having a multiplicative factor.
> 
> I think that this suffix is misleading.

You are right, let's remove it.

> [...]

-- 
  Christian Ruppert              ,          <christian.ruppert at abilis.com>
                                /|
  Tel: +41/(0)22 816 19-42     //|                 3, Chemin du Pr?-Fleuri
                             _// | bilis Systems   CH-1228 Plan-les-Ouates


From mpfj-list at mimc.co.uk  Fri Apr 12 05:14:49 2013
From: mpfj-list at mimc.co.uk (Mark Jackson)
Date: Fri, 12 Apr 2013 10:14:49 +0100
Subject: [PATCH 0/3] Dual EMAC mode implementation of CPSW
In-Reply-To: <20130212.161538.1899836892271837177.davem@davemloft.net>
References: <1360612340-9266-1-git-send-email-mugunthanvnm@ti.com>
 <20130212.161538.1899836892271837177.davem@davemloft.net>
Message-ID: <5167D089.3000105@mimc.co.uk>

On 12/02/13 21:15, David Miller wrote:
> From: Mugunthan V N <mugunthanvnm at ti.com>
> Date: Tue, 12 Feb 2013 01:22:17 +0530
> 
>> This patch series implements Dual EMAC mode implementation of CPSW
>> which acts as two standalone EMAC by segregating the switch using VIDs
>> and port VLAN
>>
>> Mugunthan V N (3):
>>   driver: net: ethernet: davinci_cpdma: add support for directed packet
>>     and source port detection
>>   driver: net: ethernet: cpsw: make cpts as pointer
>>   driver: net: ethernet: cpsw: dual emac interface implementation
> 
> Series applied.

I can see that this series is now in the mainline kernel, but can anyone
give me some pointers on how to use it ?

First, I'd like to check that it's achieving what I think it does ...
namely to be able to access both eth0 and eth1 as separate Ethernet ports ?

If this assumption is correct, can anyone guide me as to how to setup my
dts file to allow the kernel to see both ports ?

If have been trying to get it going (see my posting [1]), but to no avail.

Any help would be greatly appreciated !!

[1] http://www.spinics.net/lists/linux-omap/msg89920.html

Regards
Mark JACKSON


From sebastian.hesselbarth at gmail.com  Fri Apr 12 05:20:00 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Fri, 12 Apr 2013 11:20:00 +0200
Subject: [PATCH v2] net: mv643xx_eth: remove deprecated inet_lro support
In-Reply-To: <1365707488-28819-1-git-send-email-sebastian.hesselbarth@gmail.com>
References: <1365707488-28819-1-git-send-email-sebastian.hesselbarth@gmail.com>
Message-ID: <1365758400-12565-1-git-send-email-sebastian.hesselbarth@gmail.com>

With recent support for GRO, there is no need to keep both LRO and
GRO. This patch therefore removes the deprecated inet_lro support
from mv643xx_eth. This is work is based on an experimental patch
provided by Eric Dumazet and Willy Tarreau.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
Based-on-patch-by: Eric Dumazet <eric.dumazet at gmail.com>
Based-on-patch-by: Willy Tarreau <w at 1wt.eu>
---
Changes from v1:
- also remove INET_LRO from Kconfig (Reported by Eric Dumazet)

Cc: "David S. Miller" <davem at davemloft.net>
Cc: Lennert Buytenhek <buytenh at wantstofly.org>
Cc: Andrew Lunn <andrew at lunn.ch>
Cc: Jason Cooper <jason at lakedaemon.net>
Cc: Florian Fainelli <florian at openwrt.org>
Cc: Benjamin Herrenschmidt <benh at kernel.crashing.org>
Cc: Paul Mackerras <paulus at samba.org>
Cc: Dale Farnsworth <dale at farnsworth.org>
Cc: Ben Hutchings <bhutchings at solarflare.com>
Cc: Soeren Moch <smoch at web.de>
Cc: Eric Dumazet <eric.dumazet at gmail.com>
Cc: Willy Tarreau <w at 1wt.eu>
Cc: netdev at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linuxppc-dev at lists.ozlabs.org
Cc: linux-kernel at vger.kernel.org
---
 drivers/net/ethernet/marvell/Kconfig       |    1 -
 drivers/net/ethernet/marvell/mv643xx_eth.c |   97 +---------------------------
 2 files changed, 3 insertions(+), 95 deletions(-)

diff --git a/drivers/net/ethernet/marvell/Kconfig b/drivers/net/ethernet/marvell/Kconfig
index 5170ecb..0051f0e 100644
--- a/drivers/net/ethernet/marvell/Kconfig
+++ b/drivers/net/ethernet/marvell/Kconfig
@@ -21,7 +21,6 @@ if NET_VENDOR_MARVELL
 config MV643XX_ETH
 	tristate "Marvell Discovery (643XX) and Orion ethernet support"
 	depends on (MV64X60 || PPC32 || PLAT_ORION) && INET
-	select INET_LRO
 	select PHYLIB
 	select MVMDIO
 	---help---
diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c b/drivers/net/ethernet/marvell/mv643xx_eth.c
index c850d04..d0afeea 100644
--- a/drivers/net/ethernet/marvell/mv643xx_eth.c
+++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
@@ -56,8 +56,8 @@
 #include <linux/phy.h>
 #include <linux/mv643xx_eth.h>
 #include <linux/io.h>
+#include <linux/interrupt.h>
 #include <linux/types.h>
-#include <linux/inet_lro.h>
 #include <linux/slab.h>
 #include <linux/clk.h>
 
@@ -316,12 +316,6 @@ struct mib_counters {
 	u32 rx_overrun;
 };
 
-struct lro_counters {
-	u32 lro_aggregated;
-	u32 lro_flushed;
-	u32 lro_no_desc;
-};
-
 struct rx_queue {
 	int index;
 
@@ -335,9 +329,6 @@ struct rx_queue {
 	dma_addr_t rx_desc_dma;
 	int rx_desc_area_size;
 	struct sk_buff **rx_skb;
-
-	struct net_lro_mgr lro_mgr;
-	struct net_lro_desc lro_arr[8];
 };
 
 struct tx_queue {
@@ -373,8 +364,6 @@ struct mv643xx_eth_private {
 	spinlock_t mib_counters_lock;
 	struct mib_counters mib_counters;
 
-	struct lro_counters lro_counters;
-
 	struct work_struct tx_timeout_task;
 
 	struct napi_struct napi;
@@ -503,42 +492,12 @@ static void txq_maybe_wake(struct tx_queue *txq)
 	}
 }
 
-
-/* rx napi ******************************************************************/
-static int
-mv643xx_get_skb_header(struct sk_buff *skb, void **iphdr, void **tcph,
-		       u64 *hdr_flags, void *priv)
-{
-	unsigned long cmd_sts = (unsigned long)priv;
-
-	/*
-	 * Make sure that this packet is Ethernet II, is not VLAN
-	 * tagged, is IPv4, has a valid IP header, and is TCP.
-	 */
-	if ((cmd_sts & (RX_IP_HDR_OK | RX_PKT_IS_IPV4 |
-		       RX_PKT_IS_ETHERNETV2 | RX_PKT_LAYER4_TYPE_MASK |
-		       RX_PKT_IS_VLAN_TAGGED)) !=
-	    (RX_IP_HDR_OK | RX_PKT_IS_IPV4 |
-	     RX_PKT_IS_ETHERNETV2 | RX_PKT_LAYER4_TYPE_TCP_IPV4))
-		return -1;
-
-	skb_reset_network_header(skb);
-	skb_set_transport_header(skb, ip_hdrlen(skb));
-	*iphdr = ip_hdr(skb);
-	*tcph = tcp_hdr(skb);
-	*hdr_flags = LRO_IPV4 | LRO_TCP;
-
-	return 0;
-}
-
 static int rxq_process(struct rx_queue *rxq, int budget)
 {
 	struct mv643xx_eth_private *mp = rxq_to_mp(rxq);
 	struct net_device_stats *stats = &mp->dev->stats;
-	int lro_flush_needed;
 	int rx;
 
-	lro_flush_needed = 0;
 	rx = 0;
 	while (rx < budget && rxq->rx_desc_count) {
 		struct rx_desc *rx_desc;
@@ -599,12 +558,7 @@ static int rxq_process(struct rx_queue *rxq, int budget)
 			skb->ip_summed = CHECKSUM_UNNECESSARY;
 		skb->protocol = eth_type_trans(skb, mp->dev);
 
-		if (skb->dev->features & NETIF_F_LRO &&
-		    skb->ip_summed == CHECKSUM_UNNECESSARY) {
-			lro_receive_skb(&rxq->lro_mgr, skb, (void *)cmd_sts);
-			lro_flush_needed = 1;
-		} else
-			napi_gro_receive(&mp->napi, skb);
+		napi_gro_receive(&mp->napi, skb);
 
 		continue;
 
@@ -624,9 +578,6 @@ err:
 		dev_kfree_skb(skb);
 	}
 
-	if (lro_flush_needed)
-		lro_flush_all(&rxq->lro_mgr);
-
 	if (rx < budget)
 		mp->work_rx &= ~(1 << rxq->index);
 
@@ -1118,26 +1069,6 @@ static struct net_device_stats *mv643xx_eth_get_stats(struct net_device *dev)
 	return stats;
 }
 
-static void mv643xx_eth_grab_lro_stats(struct mv643xx_eth_private *mp)
-{
-	u32 lro_aggregated = 0;
-	u32 lro_flushed = 0;
-	u32 lro_no_desc = 0;
-	int i;
-
-	for (i = 0; i < mp->rxq_count; i++) {
-		struct rx_queue *rxq = mp->rxq + i;
-
-		lro_aggregated += rxq->lro_mgr.stats.aggregated;
-		lro_flushed += rxq->lro_mgr.stats.flushed;
-		lro_no_desc += rxq->lro_mgr.stats.no_desc;
-	}
-
-	mp->lro_counters.lro_aggregated = lro_aggregated;
-	mp->lro_counters.lro_flushed = lro_flushed;
-	mp->lro_counters.lro_no_desc = lro_no_desc;
-}
-
 static inline u32 mib_read(struct mv643xx_eth_private *mp, int offset)
 {
 	return rdl(mp, MIB_COUNTERS(mp->port_num) + offset);
@@ -1301,10 +1232,6 @@ struct mv643xx_eth_stats {
 	{ #m, FIELD_SIZEOF(struct mib_counters, m),		\
 	  -1, offsetof(struct mv643xx_eth_private, mib_counters.m) }
 
-#define LROSTAT(m)						\
-	{ #m, FIELD_SIZEOF(struct lro_counters, m),		\
-	  -1, offsetof(struct mv643xx_eth_private, lro_counters.m) }
-
 static const struct mv643xx_eth_stats mv643xx_eth_stats[] = {
 	SSTAT(rx_packets),
 	SSTAT(tx_packets),
@@ -1346,9 +1273,6 @@ static const struct mv643xx_eth_stats mv643xx_eth_stats[] = {
 	MIBSTAT(late_collision),
 	MIBSTAT(rx_discard),
 	MIBSTAT(rx_overrun),
-	LROSTAT(lro_aggregated),
-	LROSTAT(lro_flushed),
-	LROSTAT(lro_no_desc),
 };
 
 static int
@@ -1578,7 +1502,6 @@ static void mv643xx_eth_get_ethtool_stats(struct net_device *dev,
 
 	mv643xx_eth_get_stats(dev);
 	mib_counters_update(mp);
-	mv643xx_eth_grab_lro_stats(mp);
 
 	for (i = 0; i < ARRAY_SIZE(mv643xx_eth_stats); i++) {
 		const struct mv643xx_eth_stats *stat;
@@ -1851,19 +1774,6 @@ static int rxq_init(struct mv643xx_eth_private *mp, int index)
 					nexti * sizeof(struct rx_desc);
 	}
 
-	rxq->lro_mgr.dev = mp->dev;
-	memset(&rxq->lro_mgr.stats, 0, sizeof(rxq->lro_mgr.stats));
-	rxq->lro_mgr.features = LRO_F_NAPI;
-	rxq->lro_mgr.ip_summed = CHECKSUM_UNNECESSARY;
-	rxq->lro_mgr.ip_summed_aggr = CHECKSUM_UNNECESSARY;
-	rxq->lro_mgr.max_desc = ARRAY_SIZE(rxq->lro_arr);
-	rxq->lro_mgr.max_aggr = 32;
-	rxq->lro_mgr.frag_align_pad = 0;
-	rxq->lro_mgr.lro_arr = rxq->lro_arr;
-	rxq->lro_mgr.get_skb_header = mv643xx_get_skb_header;
-
-	memset(&rxq->lro_arr, 0, sizeof(rxq->lro_arr));
-
 	return 0;
 
 
@@ -2851,8 +2761,7 @@ static int mv643xx_eth_probe(struct platform_device *pdev)
 	dev->watchdog_timeo = 2 * HZ;
 	dev->base_addr = 0;
 
-	dev->hw_features = NETIF_F_SG | NETIF_F_IP_CSUM |
-		NETIF_F_RXCSUM | NETIF_F_LRO;
+	dev->hw_features = NETIF_F_SG | NETIF_F_IP_CSUM | NETIF_F_RXCSUM;
 	dev->features = NETIF_F_SG | NETIF_F_IP_CSUM | NETIF_F_RXCSUM;
 	dev->vlan_features = NETIF_F_SG | NETIF_F_IP_CSUM;
 
-- 
1.7.10.4



From jhovold at gmail.com  Fri Apr 12 05:33:33 2013
From: jhovold at gmail.com (Johan Hovold)
Date: Fri, 12 Apr 2013 11:33:33 +0200
Subject: [rtc-linux] Re: [PATCH v2 0/5] ARM: at91: fix hanged boot
In-Reply-To: <20130411165414.GC25242@game.jcrosoft.org>
References: <20130311180611.GF8797@localhost>
 <1363025279-17615-1-git-send-email-jhovold@gmail.com>
 <20130411155505.GD21305@localhost>
 <20130411165414.GC25242@game.jcrosoft.org>
Message-ID: <20130412093333.GF21305@localhost>

On Thu, Apr 11, 2013 at 06:54:14PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 17:55 Thu 11 Apr     , Johan Hovold wrote:
> > On Mon, Mar 11, 2013 at 07:07:54PM +0100, Johan Hovold wrote:
> > > These patches fix a few severe issues affecting most AT91 SOCs where
> > > boot can hang after a non-general reset, and where the only way to get
> > > the system booting again is to do a general reset -- something which
> > > could require physically removing any backup battery.
> > 
> > Have you had time to look at these patches yet, Nicolas?
> > 
> > I don't think not having decided on the path forward for DT-support for
> > rtc-at91sam9 needs to be a blocker. The rtt-nodes will be needed in any
> > case.
> > 
> > I could respin the series on top of the DT-patch for rtc-at91rm9200, and
> > add interrupt and status-disabled properties to the DT-nodes as well.
> for this this is still a no go
> 
> this way too much ugly

I understand that you prefer fixing every bootloader. I was just making
sure everyone agrees that that is the best solution.

The two interrupt masks has to be cleared before the kernel enables the
system interrupt; either it needs to be done by the bootloader or by the
at91 arch code.

The various bootloaders may not know anything about RTT or RTC, but
have all made sure interrupts are disabled before executing the kernel.
That is, they have fulfilled the requirement that interrupts must be
disabled.

So the trade-off seems to be: Either we fix this once and for all using
the infrastructure already in place in the kernel (DT), or risk further
(apparently) bricked systems as there are bound to be bootloaders that
won't get updated.

[...]

> > > The problems stem from the fact that the RTC and RTT-peripherals are
> > > powered by backup power (VDDBU) and are not reset on wake-up, user,
> > > watchdog or software reset. Consequently, RTC and RTT-alarms and their
> > > interrupts may be enabled at boot, leading to a system lock-up when an
> > > interrupt arrives on the shared system-interrupt line before the
> > > appropriate handler (e.g. RTC-driver) has been installed.
> > > 
> > > The easiest way to trigger this is to simply wake up from an RTC-alarm
> > > on at91sam9g45. The RTC-driver currently does not disable interrupts at
> > > shutdown so even after a clean shut-down the system will always hang
> > > after waking up.
> > > 
> > > The first patch fixes this very general case of RTC-wake up after a
> > > clean shutdown in the RTC-driver and is marked for stable as it is
> > > perfectly straight-forward. [ Note that the other, RTT-based, AT91
> > > RTC-driver already disables its interrupts at shutdown. ]

And what about this patch? If it's decided that every bootloader needs
to be updated, then perhaps it's better to risk bricked systems also
after a clean shutdown to enforce those updates? Should we then remove
the corresponding disable of interrupts at shutdown from the rtc-at91sam9
driver by the same logic?

> > > The more general problem can be triggered, for example, by doing a
> > > user-reset while updating the RTC-time or if an RTC or RTT-alarm goes
> > > off after a non-clean shutdown.
> > > 
> > > To fix this I propose that arch-code should mask the relevant interrupts
> > > before enabling the system interrupt at early boot, and this is what
> > > the fifth patch does. To access the RTC-registers I choose to revert a
> > > recent patch that moved the register definitions to drivers/rtc.
> > > 
> > > Arguably, the relevant interrupts could also be disabled in bootloaders,
> > > but I suggest fixing it in the kernel once and for all.

Thanks,
Johan


From ulf.hansson at stericsson.com  Fri Apr 12 05:41:30 2013
From: ulf.hansson at stericsson.com (Ulf Hansson)
Date: Fri, 12 Apr 2013 11:41:30 +0200
Subject: [PATCH] PM / Runtime: Asyncronous idle|suspend parent devices at
 removal
Message-ID: <1365759690-23687-1-git-send-email-ulf.hansson@stericsson.com>

From: Ulf Hansson <ulf.hansson at linaro.org>

For irq safe devices return the runtime reference for the parent
by using the asyncronous runtime PM API. Thus we don't have to
wait for it to become idle|suspended. Instead we can move on and
handle the next device in queue.

Signed-off-by: Ulf Hansson <ulf.hansson at linaro.org>
Cc: Kevin Hilman <khilman at linaro.org>
Cc: Alan Stern <stern at rowland.harvard.edu>
---
 drivers/base/power/runtime.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c
index 1244930..ef13ad08 100644
--- a/drivers/base/power/runtime.c
+++ b/drivers/base/power/runtime.c
@@ -1400,5 +1400,5 @@ void pm_runtime_remove(struct device *dev)
 	if (dev->power.runtime_status == RPM_ACTIVE)
 		pm_runtime_set_suspended(dev);
 	if (dev->power.irq_safe && dev->parent)
-		pm_runtime_put_sync(dev->parent);
+		pm_runtime_put(dev->parent);
 }
-- 
1.7.10



From ulf.hansson at stericsson.com  Fri Apr 12 05:41:44 2013
From: ulf.hansson at stericsson.com (Ulf Hansson)
Date: Fri, 12 Apr 2013 11:41:44 +0200
Subject: [PATCH] PM / Runtime: Improve prepare handling at system suspend for
 genpd
Message-ID: <1365759704-23722-1-git-send-email-ulf.hansson@stericsson.com>

From: Ulf Hansson <ulf.hansson at linaro.org>

When genpd prepares for a system suspend it will fetch a runtime
reference for the device. When returning it we now use the
asyncronous runtime PM API. Thus we don't have to wait for the
device to become idle|suspended before we move on and handle the
next device in queue.

Signed-off-by: Ulf Hansson <ulf.hansson at linaro.org>
Cc: Kevin Hilman <khilman at linaro.org>
Cc: Alan Stern <stern at rowland.harvard.edu>
---
 drivers/base/power/domain.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index 9a6b05a..e6ec4a7 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -920,7 +920,7 @@ static int pm_genpd_prepare(struct device *dev)
 		pm_wakeup_event(dev, 0);
 
 	if (pm_wakeup_pending()) {
-		pm_runtime_put_sync(dev);
+		pm_runtime_put(dev);
 		return -EBUSY;
 	}
 
@@ -961,7 +961,7 @@ static int pm_genpd_prepare(struct device *dev)
 		pm_runtime_enable(dev);
 	}
 
-	pm_runtime_put_sync(dev);
+	pm_runtime_put(dev);
 	return ret;
 }
 
-- 
1.7.10



From ulf.hansson at stericsson.com  Fri Apr 12 05:41:06 2013
From: ulf.hansson at stericsson.com (Ulf Hansson)
Date: Fri, 12 Apr 2013 11:41:06 +0200
Subject: [PATCH] PM / Runtime: Asyncronous idle|suspend devices at system
 resume
Message-ID: <1365759666-23652-1-git-send-email-ulf.hansson@stericsson.com>

From: Ulf Hansson <ulf.hansson at linaro.org>

Use the asyncronous runtime PM API when returning the runtime
reference for the device after the system resume is completed.

By using the asyncronous runtime PM API we don't have to wait
for each an every device to become idle|suspended. Instead we
can move on and handle the next device in queue.

Signed-off-by: Ulf Hansson <ulf.hansson at linaro.org>
Cc: Kevin Hilman <khilman at linaro.org>
Cc: Alan Stern <stern at rowland.harvard.edu>
---
 drivers/base/power/domain.c      |    2 +-
 drivers/base/power/generic_ops.c |    2 +-
 drivers/base/power/main.c        |    2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index 9a6b05a..bba5758 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -1327,7 +1327,7 @@ static void pm_genpd_complete(struct device *dev)
 		pm_generic_complete(dev);
 		pm_runtime_set_active(dev);
 		pm_runtime_enable(dev);
-		pm_runtime_idle(dev);
+		pm_request_idle(dev);
 	}
 }
 
diff --git a/drivers/base/power/generic_ops.c b/drivers/base/power/generic_ops.c
index d03d290..bfd898b 100644
--- a/drivers/base/power/generic_ops.c
+++ b/drivers/base/power/generic_ops.c
@@ -324,6 +324,6 @@ void pm_generic_complete(struct device *dev)
 	 * Let runtime PM try to suspend devices that haven't been in use before
 	 * going into the system-wide sleep state we're resuming from.
 	 */
-	pm_runtime_idle(dev);
+	pm_request_idle(dev);
 }
 #endif /* CONFIG_PM_SLEEP */
diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
index 15beb50..5a9b656 100644
--- a/drivers/base/power/main.c
+++ b/drivers/base/power/main.c
@@ -756,7 +756,7 @@ static void device_complete(struct device *dev, pm_message_t state)
 
 	device_unlock(dev);
 
-	pm_runtime_put_sync(dev);
+	pm_runtime_put(dev);
 }
 
 /**
-- 
1.7.10



From gregory.clement at free-electrons.com  Fri Apr 12 05:46:12 2013
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Fri, 12 Apr 2013 11:46:12 +0200
Subject: [PATCH] clk: Add device tree binding to clk-fixed-factor
In-Reply-To: <20130412091234.GC29291@ab42.lan>
References: <1365608443-30350-1-git-send-email-christian.ruppert@abilis.com>
 <51658BA9.7030508@free-electrons.com> <20130410162747.GG32603@ab42.lan>
 <20130411091952.GF8400@ab42.lan> <5166E41F.7060100@free-electrons.com>
 <20130412065417.GA29291@ab42.lan> <5167CE33.9010403@free-electrons.com>
 <20130412091234.GC29291@ab42.lan>
Message-ID: <5167D7E4.9030206@free-electrons.com>

On 04/12/2013 11:12 AM, Christian Ruppert wrote:
> On Fri, Apr 12, 2013 at 11:04:51AM +0200, Gregory CLEMENT wrote:
>> On 04/12/2013 08:54 AM, Christian Ruppert wrote:
>>> On Thu, Apr 11, 2013 at 06:26:07PM +0200, Gregory CLEMENT wrote:
>>>> On 04/11/2013 11:19 AM, Christian Ruppert wrote:
>>>>> Hi Gregory,
>>>>>
>>>>> Since there doesn't seem to be anyone opposing this feature I just
>>>>> checked your patch and after adding the CLK_OF_DECLARE macro in the end
>>>>> it works well for us. Tell me if you would like to rebase and resubmit
>>>>> your patch or if I should follow up on our own.
>>>>
>>>> I can rebase and resubmit my patch, it's pretty straightforward.
>>>> The problem was the lack of user in the kernel. And by user I mean
>>>> a driver using these functions. Usually a new function enter in the
>>>> kernel only if there are users for it inside the kernel so if you plan
>>>> to submit a driver using this piece of code, then I see no reason
>>>> to not get it.
>>>
>>> If you add the line
>>>
>>> CLK_OF_DECLARE(fixed_factor_clk, "fixed-factor-clkdiv", 
>>
>> Why did you add the div suffix?
>>
>> There is nothing in the function which prevent to have "mul" greater than
>> "div" and hence having a multiplicative factor.
>>
>> I think that this suffix is misleading.
> 
> You are right, let's remove it.

Great, I am going to send the patch in a couple of minutes.
That means that you will have to ammend your file
arch/arc/boot/dts/abilis_tb10x.dtsi

and for the clock named cpu_clk and ahb_clk you will have to rename
fixed-factor-clkdiv to fixed-factor-clock

Thanks,

> 
>> [...]
> 


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From egtvedt at samfundet.no  Fri Apr 12 05:52:26 2013
From: egtvedt at samfundet.no (Hans-Christian Egtvedt)
Date: Fri, 12 Apr 2013 11:52:26 +0200
Subject: [PATCH 1/8] video: atmel_lcdfb: fix platform data struct
In-Reply-To: <1365692422-9565-1-git-send-email-plagnioj@jcrosoft.com>
References: <20130411145741.GB25242@game.jcrosoft.org>
 <1365692422-9565-1-git-send-email-plagnioj@jcrosoft.com>
Message-ID: <20130412095226.GA10028@samfundet.no>

Around Thu 11 Apr 2013 17:00:15 +0200 or thereabout, Jean-Christophe PLAGNIOL-VILLARD wrote:
> Today we mix pdata and drivers data in the struct atmel_lcdfb_info
> Fix it and introduce a new struct atmel_lcdfb_pdata for platform data only
> 
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
> Cc: linux-fbdev at vger.kernel.org
> Cc: Nicolas Ferre <nicolas.ferre at atmel.com>
> Cc: Andrew Morton <akpm at linux-foundation.org>
> Cc: Hans-Christian Egtvedt <egtvedt at samfundet.no>

For the AVR32 bits

Acked-by: Hans-Christian Egtvedt <egtvedt at samfundet.no>

> ---
>  arch/arm/mach-at91/at91sam9261_devices.c    |    6 +-
>  arch/arm/mach-at91/at91sam9263_devices.c    |    6 +-
>  arch/arm/mach-at91/at91sam9g45_devices.c    |    6 +-
>  arch/arm/mach-at91/at91sam9rl_devices.c     |    6 +-
>  arch/arm/mach-at91/board-sam9261ek.c        |    6 +-
>  arch/arm/mach-at91/board-sam9263ek.c        |    4 +-
>  arch/arm/mach-at91/board-sam9m10g45ek.c     |    4 +-
>  arch/arm/mach-at91/board-sam9rlek.c         |    4 +-
>  arch/arm/mach-at91/board.h                  |    4 +-
>  arch/avr32/boards/atngw100/evklcd10x.c      |    6 +-
>  arch/avr32/boards/atngw100/mrmt.c           |    4 +-
>  arch/avr32/boards/atstk1000/atstk1000.h     |    2 +-
>  arch/avr32/boards/atstk1000/setup.c         |    2 +-
>  arch/avr32/boards/favr-32/setup.c           |    2 +-
>  arch/avr32/boards/hammerhead/setup.c        |    2 +-
>  arch/avr32/boards/merisc/display.c          |    2 +-
>  arch/avr32/boards/mimc200/setup.c           |    4 +-
>  arch/avr32/mach-at32ap/at32ap700x.c         |    8 +--
>  arch/avr32/mach-at32ap/include/mach/board.h |    4 +-
>  drivers/video/atmel_lcdfb.c                 |  104 +++++++++++++++++----------
>  include/video/atmel_lcdc.h                  |   24 +------
>  21 files changed, 109 insertions(+), 101 deletions(-)

<snipp diff>

-- 
HcE


From gregory.clement at free-electrons.com  Fri Apr 12 05:58:27 2013
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Fri, 12 Apr 2013 11:58:27 +0200
Subject: [PATCH v2] clk: add device tree fixed-factor-clock binding support
Message-ID: <1365760708-4763-1-git-send-email-gregory.clement@free-electrons.com>

Hi,

[I resend it because I forgot to add the mainling lists!]

Since august this patch finally find a user:
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/arch/arc/boot/dts/abilis_*.dtsi.
So I resusrected this patch with small changed suggested by Christian
Ruppert.

- Adding CLK_OF_DECLARE
- Using IS_ERR to test the clk value

Thanks,

Gregory CLEMENT (1):
  clk: add device tree fixed-factor-clock binding support

 .../bindings/clock/fixed-factor-clock.txt          |   24 +++++++++++++
 drivers/clk/clk-fixed-factor.c                     |   36 ++++++++++++++++++++
 include/linux/clk-provider.h                       |    2 ++
 3 files changed, 62 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/fixed-factor-clock.txt

-- 
1.7.9.5



From gregory.clement at free-electrons.com  Fri Apr 12 05:58:28 2013
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Fri, 12 Apr 2013 11:58:28 +0200
Subject: [PATCH v2] clk: add device tree fixed-factor-clock binding support
In-Reply-To: <1365760708-4763-1-git-send-email-gregory.clement@free-electrons.com>
References: <1365760708-4763-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1365760708-4763-2-git-send-email-gregory.clement@free-electrons.com>

Add support for DT "fixed-factor-clock" binding to the common fixed
factor clock support.

Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
---
 .../bindings/clock/fixed-factor-clock.txt          |   24 +++++++++++++
 drivers/clk/clk-fixed-factor.c                     |   36 ++++++++++++++++++++
 include/linux/clk-provider.h                       |    2 ++
 3 files changed, 62 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/fixed-factor-clock.txt

diff --git a/Documentation/devicetree/bindings/clock/fixed-factor-clock.txt b/Documentation/devicetree/bindings/clock/fixed-factor-clock.txt
new file mode 100644
index 0000000..7ed236f
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/fixed-factor-clock.txt
@@ -0,0 +1,24 @@
+Binding for simple fixed factor rate clock sources.
+
+This binding uses the common clock binding[1].
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties:
+- compatible : shall be "fixed-factor-clock".
+- #clock-cells : from common clock binding; shall be set to 0.
+- div: fixed divider.
+- mult: fixed multiplier.
+- clocks: parent clock.
+
+Optional properties:
+- clock-output-names : From common clock binding.
+
+Example:
+	clock {
+		compatible = "fixed-factor-clock";
+		clocks = <&parentclk>;
+		#clock-cells = <0>;
+		div = <2>;
+		mult = <1>;
+	};
diff --git a/drivers/clk/clk-fixed-factor.c b/drivers/clk/clk-fixed-factor.c
index 1ef271e..9ff7d51 100644
--- a/drivers/clk/clk-fixed-factor.c
+++ b/drivers/clk/clk-fixed-factor.c
@@ -11,6 +11,7 @@
 #include <linux/clk-provider.h>
 #include <linux/slab.h>
 #include <linux/err.h>
+#include <linux/of.h>
 
 /*
  * DOC: basic fixed multiplier and divider clock that cannot gate
@@ -96,3 +97,38 @@ struct clk *clk_register_fixed_factor(struct device *dev, const char *name,
 
 	return clk;
 }
+#ifdef CONFIG_OF
+/**
+ * of_fixed_factor_clk_setup() - Setup function for simple fixed factor clock
+ */
+void __init of_fixed_factor_clk_setup(struct device_node *node)
+{
+	struct clk *clk;
+	const char *clk_name = node->name;
+	const char *parent_name;
+	u32 div, mult;
+
+	if (of_property_read_u32(node, "clock-div", &div)) {
+		pr_err("%s Fixed factor clock <%s> must have a clock-div property\n",
+			__func__, node->name);
+		return;
+	}
+
+	if (of_property_read_u32(node, "clock-mult", &mult)) {
+		pr_err("%s Fixed factor clock <%s> must have a clokc-mult property\n",
+			__func__, node->name);
+		return;
+	}
+
+	of_property_read_string(node, "clock-output-names", &clk_name);
+	parent_name = of_clk_get_parent_name(node, 0);
+
+	clk = clk_register_fixed_factor(NULL, clk_name, parent_name, 0,
+					mult, div);
+	if (!IS_ERR(clk))
+		of_clk_add_provider(node, of_clk_src_simple_get, clk);
+}
+EXPORT_SYMBOL_GPL(of_fixed_factor_clk_setup);
+CLK_OF_DECLARE(fixed_factor_clk, "fixed-factor-clock",
+		of_fixed_factor_clk_setup);
+#endif
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 7f197d7..7ea501b 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -325,6 +325,8 @@ struct clk *clk_register_fixed_factor(struct device *dev, const char *name,
 		const char *parent_name, unsigned long flags,
 		unsigned int mult, unsigned int div);
 
+void of_fixed_factor_clk_setup(struct device_node *node);
+
 /**
  * clk_register - allocate a new clock, register it and return an opaque cookie
  * @dev: device that is registering this clock
-- 
1.7.9.5



From christian.ruppert at abilis.com  Fri Apr 12 06:30:10 2013
From: christian.ruppert at abilis.com (Christian Ruppert)
Date: Fri, 12 Apr 2013 12:30:10 +0200
Subject: [PATCH v2] clk: add device tree fixed-factor-clock binding support
In-Reply-To: <1365760708-4763-2-git-send-email-gregory.clement@free-electrons.com>
References: <1365760708-4763-1-git-send-email-gregory.clement@free-electrons.com>
 <1365760708-4763-2-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <20130412103007.GE29291@ab42.lan>

Hi Gregory,

Just tested the patch and it works perfectly. Did you forget to update
Documentation/devicetree/bindings/clock/fixed-factor-clock.txt, however?

Greetings,
  Christian

On Fri, Apr 12, 2013 at 11:58:28AM +0200, Gregory CLEMENT wrote:
> Add support for DT "fixed-factor-clock" binding to the common fixed
> factor clock support.
> 
> Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
> ---
>  .../bindings/clock/fixed-factor-clock.txt          |   24 +++++++++++++
>  drivers/clk/clk-fixed-factor.c                     |   36 ++++++++++++++++++++
>  include/linux/clk-provider.h                       |    2 ++
>  3 files changed, 62 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/clock/fixed-factor-clock.txt
> 
> diff --git a/Documentation/devicetree/bindings/clock/fixed-factor-clock.txt b/Documentation/devicetree/bindings/clock/fixed-factor-clock.txt
> new file mode 100644
> index 0000000..7ed236f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/fixed-factor-clock.txt
> @@ -0,0 +1,24 @@
> +Binding for simple fixed factor rate clock sources.
> +
> +This binding uses the common clock binding[1].
> +
> +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
> +
> +Required properties:
> +- compatible : shall be "fixed-factor-clock".
> +- #clock-cells : from common clock binding; shall be set to 0.
> +- div: fixed divider.
> +- mult: fixed multiplier.
> +- clocks: parent clock.
> +
> +Optional properties:
> +- clock-output-names : From common clock binding.
> +
> +Example:
> +	clock {
> +		compatible = "fixed-factor-clock";
> +		clocks = <&parentclk>;
> +		#clock-cells = <0>;
> +		div = <2>;
> +		mult = <1>;
> +	};
> diff --git a/drivers/clk/clk-fixed-factor.c b/drivers/clk/clk-fixed-factor.c
> index 1ef271e..9ff7d51 100644
> --- a/drivers/clk/clk-fixed-factor.c
> +++ b/drivers/clk/clk-fixed-factor.c
> @@ -11,6 +11,7 @@
>  #include <linux/clk-provider.h>
>  #include <linux/slab.h>
>  #include <linux/err.h>
> +#include <linux/of.h>
>  
>  /*
>   * DOC: basic fixed multiplier and divider clock that cannot gate
> @@ -96,3 +97,38 @@ struct clk *clk_register_fixed_factor(struct device *dev, const char *name,
>  
>  	return clk;
>  }
> +#ifdef CONFIG_OF
> +/**
> + * of_fixed_factor_clk_setup() - Setup function for simple fixed factor clock
> + */
> +void __init of_fixed_factor_clk_setup(struct device_node *node)
> +{
> +	struct clk *clk;
> +	const char *clk_name = node->name;
> +	const char *parent_name;
> +	u32 div, mult;
> +
> +	if (of_property_read_u32(node, "clock-div", &div)) {
> +		pr_err("%s Fixed factor clock <%s> must have a clock-div property\n",
> +			__func__, node->name);
> +		return;
> +	}
> +
> +	if (of_property_read_u32(node, "clock-mult", &mult)) {
> +		pr_err("%s Fixed factor clock <%s> must have a clokc-mult property\n",
> +			__func__, node->name);
> +		return;
> +	}
> +
> +	of_property_read_string(node, "clock-output-names", &clk_name);
> +	parent_name = of_clk_get_parent_name(node, 0);
> +
> +	clk = clk_register_fixed_factor(NULL, clk_name, parent_name, 0,
> +					mult, div);
> +	if (!IS_ERR(clk))
> +		of_clk_add_provider(node, of_clk_src_simple_get, clk);
> +}
> +EXPORT_SYMBOL_GPL(of_fixed_factor_clk_setup);
> +CLK_OF_DECLARE(fixed_factor_clk, "fixed-factor-clock",
> +		of_fixed_factor_clk_setup);
> +#endif
> diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
> index 7f197d7..7ea501b 100644
> --- a/include/linux/clk-provider.h
> +++ b/include/linux/clk-provider.h
> @@ -325,6 +325,8 @@ struct clk *clk_register_fixed_factor(struct device *dev, const char *name,
>  		const char *parent_name, unsigned long flags,
>  		unsigned int mult, unsigned int div);
>  
> +void of_fixed_factor_clk_setup(struct device_node *node);
> +
>  /**
>   * clk_register - allocate a new clock, register it and return an opaque cookie
>   * @dev: device that is registering this clock
> -- 
> 1.7.9.5
> 

-- 
  Christian Ruppert              ,          <christian.ruppert at abilis.com>
                                /|
  Tel: +41/(0)22 816 19-42     //|                 3, Chemin du Pr?-Fleuri
                             _// | bilis Systems   CH-1228 Plan-les-Ouates


From christian.ruppert at abilis.com  Fri Apr 12 06:36:29 2013
From: christian.ruppert at abilis.com (Christian Ruppert)
Date: Fri, 12 Apr 2013 12:36:29 +0200
Subject: [PATCH] ARC: [TB10x] Adapt device tree to new compatible string
In-Reply-To: <5167D7E4.9030206@free-electrons.com>
References: <5167D7E4.9030206@free-electrons.com>
Message-ID: <1365762989-31638-1-git-send-email-christian.ruppert@abilis.com>

The original device tree was written using a slightly different
implementation of the fixed-factor-clock device tree binding. The
compatible string must be modified in order to be compatible with the
new implementation.

Signed-off-by: Christian Ruppert <christian.ruppert at abilis.com>
---
 arch/arc/boot/dts/abilis_tb10x.dtsi |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arc/boot/dts/abilis_tb10x.dtsi b/arch/arc/boot/dts/abilis_tb10x.dtsi
index 6d80d9c..a6139fc 100644
--- a/arch/arc/boot/dts/abilis_tb10x.dtsi
+++ b/arch/arc/boot/dts/abilis_tb10x.dtsi
@@ -53,13 +53,13 @@
 			clock-output-names = "pll0";
 		};
 		cpu_clk: clkdiv_cpu {
-			compatible = "fixed-factor-clkdiv";
+			compatible = "fixed-factor-clock";
 			#clock-cells = <0>;
 			clocks = <&pll0>;
 			clock-output-names = "cpu_clk";
 		};
 		ahb_clk: clkdiv_ahb {
-			compatible = "fixed-factor-clkdiv";
+			compatible = "fixed-factor-clock";
 			#clock-cells = <0>;
 			clocks = <&pll0>;
 			clock-output-names = "ahb_clk";
-- 
1.7.1



From Vineet.Gupta1 at synopsys.com  Fri Apr 12 06:38:56 2013
From: Vineet.Gupta1 at synopsys.com (Vineet Gupta)
Date: Fri, 12 Apr 2013 16:08:56 +0530
Subject: [PATCH] ARC: [TB10x] Adapt device tree to new compatible string
In-Reply-To: <1365762989-31638-1-git-send-email-christian.ruppert@abilis.com>
References: <5167D7E4.9030206@free-electrons.com>
 <1365762989-31638-1-git-send-email-christian.ruppert@abilis.com>
Message-ID: <5167E440.6070606@synopsys.com>

On 04/12/2013 04:06 PM, Christian Ruppert wrote:
> The original device tree was written using a slightly different
> implementation of the fixed-factor-clock device tree binding. The
> compatible string must be modified in order to be compatible with the
> new implementation.
>
> Signed-off-by: Christian Ruppert <christian.ruppert at abilis.com>

Applied !

Thx,
-Vineet


From will.deacon at arm.com  Fri Apr 12 06:45:28 2013
From: will.deacon at arm.com (Will Deacon)
Date: Fri, 12 Apr 2013 11:45:28 +0100
Subject: Kexec couldn't reboot capture kernel on pandaboard ES with
 OMAP4460
In-Reply-To: <5166E289.8070104@wwwdotorg.org>
References: <CAFNq8R5FFUyH+JgjoGc5ctgEfiLvxzi7fzawM7+wFX5nEyTv-w@mail.gmail.com>
 <51658B1A.6090706@wwwdotorg.org>
 <CAFNq8R6mRJRygfnYvZgwVWOqsrhrjNUYzyZGU0cVsnE30W_xGg@mail.gmail.com>
 <5166E289.8070104@wwwdotorg.org>
Message-ID: <20130412104528.GE12363@mudshark.cambridge.arm.com>

On Thu, Apr 11, 2013 at 05:19:21PM +0100, Stephen Warren wrote:
> On 04/10/2013 10:46 PM, Li Haifeng wrote:
> > 2013/4/10 Stephen Warren <swarren at wwwdotorg.org>:
> >> On 04/10/2013 03:35 AM, Li Haifeng wrote:
> >>> Hi, everyone.
> >>>
> >>> Recently, I try to run kdump on pandaboard ES with omap4460. After
> >>> load capture kernel by "kexec -l" and execute "kexec -e", the serial
> >>> port output "Starting new kernel" and "Bye", then the system hangs up.
> >>>
> >>> I have tried the upstream Linux Kernel v3.4 and v3.8. All are with this issue.
> >>
> >> This is a shot in the dark. I assume you have SMP enabled. Can you use
> >> hotplug to remove all CPUs other than CPU0, so that the kexec happens on
> >> the boot CPU? That is certainly necessary for kexec to work correctly on
> >> Tegra.
> > 
> > Thanks for your attention.
> > 
> > I do disable SMP feature. And the .config file for v3.8 could be found here:
> > http://pastehtml.com/view/cylyrfejt.txt
> ...
> > The output:
> > [   57.373687] Starting new kernel
> > [   57.377044] Bye!
> > 
> > Then system hangs.
> 
> Oh well, you've exhausted my knowledge I'm afraid! I can only suggesting
> trying to enable earlyprintk and/or uncompressor debug in the kernel
> you're kexec'ing and see if that yields any clue. Either that, or JTAG!

Also worth using the bleeding edge kexec-tools (i.e. build from source),
especially if you want to anything device-tree related.

Back to the SMP point: Stephen, did you ever get anywhere with that
disable_nonboot_cpus thread from a few months back? I'm still keen to get
that working, and I *thought* we had a potential solution...

Will


From lars at metafoo.de  Fri Apr 12 07:04:22 2013
From: lars at metafoo.de (Lars-Peter Clausen)
Date: Fri, 12 Apr 2013 13:04:22 +0200
Subject: [alsa-devel] [PATCH 18/30] ASoC: samsung: move plat/ headers
 to local directory
In-Reply-To: <20130411171938.GS9243@opensource.wolfsonmicro.com>
References: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
 <1365638712-1028578-19-git-send-email-arnd@arndb.de>
 <20130411164751.GK9243@opensource.wolfsonmicro.com>
 <201304111908.42532.arnd@arndb.de>
 <20130411171938.GS9243@opensource.wolfsonmicro.com>
Message-ID: <5167EA36.5080505@metafoo.de>

On 04/11/2013 07:19 PM, Mark Brown wrote:
> On Thu, Apr 11, 2013 at 07:08:42PM +0200, Arnd Bergmann wrote:
>> On Thursday 11 April 2013, Mark Brown wrote:
> 
>>> This doesn't apply to my topic/samsung branch, can you please regenerate
>>> it against that or let me know what to apply it against?
> 
>> This one should work. Unfortunately I now found during testing that the
>> s3c24xx sound support has a few build errors at the moment, but this
>> patch should not add any new ones:
> 
> Applied (after hand editing the commit message), thanks.
> 
>> make[5]: *** [sound/soc/samsung/i2s.o] Error 1
>> /git/arm-soc/sound/soc/samsung/neo1973_wm8753.c:25:24: fatal error: mach/gta02.h: No such file or directory
>>  #include <mach/gta02.h>
> 
> Hrm, someone killed GTA02 support?  That's sad...  if that's really the
> case we could kill the machine driver but not tonight as I'm running
> late...

I think the file was moved, we should pull over the audio relevant GPIO
definitions into the ASoC board driver.

- Lars


From prabhakar.csengg at gmail.com  Fri Apr 12 07:05:34 2013
From: prabhakar.csengg at gmail.com (Prabhakar lad)
Date: Fri, 12 Apr 2013 16:35:34 +0530
Subject: [PATCH] ARM: daVinci: dm644x/dm355/dm365: replace
 V4L2_STD_525_60/625_50 with V4L2_STD_NTSC/PAL
Message-ID: <1365764734-16515-1-git-send-email-prabhakar.csengg@gmail.com>

From: Lad, Prabhakar <prabhakar.csengg at gmail.com>

This patch replaces V4L2_STD_525_60/625_50 with V4L2_STD_NTSC/PAL
respectively as this are the proper video standards.

Signed-off-by: Lad, Prabhakar <prabhakar.csengg at gmail.com>
Reported-by: Hans Verkuil <hans.verkuil at cisco.com>
Cc: Sekhar Nori <nsekhar at ti.com>
---
 Note:- This patch is on top of following pull
  https://patchwork.linuxtv.org/patch/17888/

 arch/arm/mach-davinci/board-dm355-evm.c  |    4 ++--
 arch/arm/mach-davinci/board-dm365-evm.c  |    4 ++--
 arch/arm/mach-davinci/board-dm644x-evm.c |    4 ++--
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-davinci/board-dm355-evm.c b/arch/arm/mach-davinci/board-dm355-evm.c
index 1043506..886481c 100644
--- a/arch/arm/mach-davinci/board-dm355-evm.c
+++ b/arch/arm/mach-davinci/board-dm355-evm.c
@@ -247,7 +247,7 @@ static struct vpbe_enc_mode_info dm355evm_enc_preset_timing[] = {
 	{
 		.name		= "ntsc",
 		.timings_type	= VPBE_ENC_STD,
-		.std_id		= V4L2_STD_525_60,
+		.std_id		= V4L2_STD_NTSC,
 		.interlaced	= 1,
 		.xres		= 720,
 		.yres		= 480,
@@ -259,7 +259,7 @@ static struct vpbe_enc_mode_info dm355evm_enc_preset_timing[] = {
 	{
 		.name		= "pal",
 		.timings_type	= VPBE_ENC_STD,
-		.std_id		= V4L2_STD_625_50,
+		.std_id		= V4L2_STD_PAL,
 		.interlaced	= 1,
 		.xres		= 720,
 		.yres		= 576,
diff --git a/arch/arm/mach-davinci/board-dm365-evm.c b/arch/arm/mach-davinci/board-dm365-evm.c
index 0518ce5..2a66743 100644
--- a/arch/arm/mach-davinci/board-dm365-evm.c
+++ b/arch/arm/mach-davinci/board-dm365-evm.c
@@ -381,7 +381,7 @@ static struct vpbe_enc_mode_info dm365evm_enc_std_timing[] = {
 	{
 		.name		= "ntsc",
 		.timings_type	= VPBE_ENC_STD,
-		.std_id		= V4L2_STD_525_60,
+		.std_id		= V4L2_STD_NTSC,
 		.interlaced	= 1,
 		.xres		= 720,
 		.yres		= 480,
@@ -393,7 +393,7 @@ static struct vpbe_enc_mode_info dm365evm_enc_std_timing[] = {
 	{
 		.name		= "pal",
 		.timings_type	= VPBE_ENC_STD,
-		.std_id		= V4L2_STD_625_50,
+		.std_id		= V4L2_STD_PAL,
 		.interlaced	= 1,
 		.xres		= 720,
 		.yres		= 576,
diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c b/arch/arm/mach-davinci/board-dm644x-evm.c
index a021800..745280d 100644
--- a/arch/arm/mach-davinci/board-dm644x-evm.c
+++ b/arch/arm/mach-davinci/board-dm644x-evm.c
@@ -622,7 +622,7 @@ static struct vpbe_enc_mode_info dm644xevm_enc_std_timing[] = {
 	{
 		.name		= "ntsc",
 		.timings_type	= VPBE_ENC_STD,
-		.std_id		= V4L2_STD_525_60,
+		.std_id		= V4L2_STD_NTSC,
 		.interlaced	= 1,
 		.xres		= 720,
 		.yres		= 480,
@@ -634,7 +634,7 @@ static struct vpbe_enc_mode_info dm644xevm_enc_std_timing[] = {
 	{
 		.name		= "pal",
 		.timings_type	= VPBE_ENC_STD,
-		.std_id		= V4L2_STD_625_50,
+		.std_id		= V4L2_STD_PAL,
 		.interlaced	= 1,
 		.xres		= 720,
 		.yres		= 576,
-- 
1.7.4.1



From stefano.stabellini at eu.citrix.com  Fri Apr 12 06:58:21 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Fri, 12 Apr 2013 11:58:21 +0100
Subject: [PATCH 0/4 v6] arm: introduce psci_smp_ops and use them on Xen
In-Reply-To: <20130412085748.GC12363@mudshark.cambridge.arm.com>
References: <alpine.DEB.2.02.1304031239550.5078@kaball.uk.xensource.com>
 <alpine.DEB.2.02.1304081102500.5353@kaball.uk.xensource.com>
 <20130411082519.GD31465@quad.lixom.net> <51671A39.6090105@gmail.com>
 <20130412085748.GC12363@mudshark.cambridge.arm.com>
Message-ID: <alpine.DEB.2.02.1304121152310.7254@kaball.uk.xensource.com>

On Fri, 12 Apr 2013, Will Deacon wrote:
> On Thu, Apr 11, 2013 at 09:16:57PM +0100, Rob Herring wrote:
> > On 04/11/2013 03:25 AM, Olof Johansson wrote:
> > > On Mon, Apr 08, 2013 at 12:05:17PM +0100, Stefano Stabellini wrote:
> > >> Arnd, Olof,
> > >> do you have any thoughts on this series?
> > >> Would you be happy to carry it in the arm-soc tree?
> > >>
> > >> The last patch, "xen/arm: introduce xen_early_init, use PSCI on xen" has
> > >> a (small) dependency on this series:
> > >>
> > >> http://marc.info/?l=linux-kernel&m=136430893610688&w=2
> > >>
> > >> would you be OK with taking that one too, or should that go through the
> > >> Xen tree?
> > > 
> > > I think it'd make sense to get Russell to ack the changes to the core ARM code.
> > > We can merge the series through arm-soc, or he can take them, whatever is
> > > easiest for everybody.
> > > 
> > > Given the dependencies on the second branch it might be easier to merge
> > > through Russell's tree.
> > 
> > I'm also dependent on the 1st patch for converting highbank to use PSCI
> > and am just waiting on a stable branch to base it on. I believe Russell
> > said he is offline for the next week.
> 
> By the first patch, do you just mean 6/6 in that series ("[RFC] arm: use PSCI if
> available"), or do you have dependencies on others in that series too?
 
FYI in few days, as soon as I am back from vacation, I am planning on
sending out a single patch series to avoid further confusions. I'll also
include the new version of the smp_init patch, as requested by Nicolas.

Of course we'll still need all the acks from Russell.


From rjw at sisk.pl  Fri Apr 12 07:19:28 2013
From: rjw at sisk.pl (Rafael J. Wysocki)
Date: Fri, 12 Apr 2013 13:19:28 +0200
Subject: [RESEND PATCH V6 1/4] cpufreq: exynos: Add cpufreq driver for
 exynos5440
In-Reply-To: <CAGo_u6oZM0K8XDMtmXKFyoGy2qf+-HSPvU0EMangM5Jj_prKsA@mail.gmail.com>
References: <CAKohpo=t_YTCTRCfnwQ+GPF=frsTGDigT3RZHJuVQ+R+YZU7Hg@mail.gmail.com>
 <1365415054-30771-1-git-send-email-amit.daniel@samsung.com>
 <CAGo_u6oZM0K8XDMtmXKFyoGy2qf+-HSPvU0EMangM5Jj_prKsA@mail.gmail.com>
Message-ID: <1586707.acL064pYmb@vostro.rjw.lan>

On Thursday, April 11, 2013 06:23:52 PM Nishanth Menon wrote:
> Hi,
> On Mon, Apr 8, 2013 at 4:57 AM, Amit Daniel Kachhap
> <amit.daniel at samsung.com> wrote:
> > +
> > +static int init_div_table(void)
> > +{
> > +       struct cpufreq_frequency_table *freq_tbl = dvfs_info->freq_table;
> > +       unsigned int tmp, clk_div, ema_div, freq, volt_id;
> > +       int i = 0;
> > +       struct opp *opp;
> > +
> > +       for (i = 0; freq_tbl[i].frequency != CPUFREQ_TABLE_END; i++) {
> > +
> > +               opp = opp_find_freq_exact(dvfs_info->dev,
> > +                                       freq_tbl[i].frequency * 1000, true);
> > +               if (IS_ERR(opp)) {
> > +                       dev_err(dvfs_info->dev,
> > +                               "failed to find valid OPP for %u KHZ\n",
> > +                               freq_tbl[i].frequency);
> > +                       return PTR_ERR(opp);
> > +               }
> please use RCU read locks.
> 
> > +
> > +               freq = freq_tbl[i].frequency / 1000; /* In MHZ */
> > +               clk_div = ((freq / CPU_DIV_FREQ_MAX) & P0_7_CPUCLKDEV_MASK)
> > +                                       << P0_7_CPUCLKDEV_SHIFT;
> > +               clk_div |= ((freq / CPU_ATB_FREQ_MAX) & P0_7_ATBCLKDEV_MASK)
> > +                                       << P0_7_ATBCLKDEV_SHIFT;
> > +               clk_div |= ((freq / CPU_DBG_FREQ_MAX) & P0_7_CSCLKDEV_MASK)
> > +                                       << P0_7_CSCLKDEV_SHIFT;
> > +
> > +               /* Calculate EMA */
> > +               volt_id = opp_get_voltage(opp);
> Please use RCU read locks as documented for OPP library.

Argh.  I overlooked that and the series has been applied already.  Care to send
a fix against linux-pm.git/linux-next?

Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.


From Ian.Campbell at citrix.com  Fri Apr 12 07:16:18 2013
From: Ian.Campbell at citrix.com (Ian Campbell)
Date: Fri, 12 Apr 2013 12:16:18 +0100
Subject: hypervisor/firmware calling conventions (Was: Re: [Xen-devel]
 [PATCH 1/4] xen/arm: basic PSCI support,	implement cpu_on)
In-Reply-To: <20130411170959.GA2239@linaro.org>
References: <alpine.DEB.2.02.1303211837140.5135@kaball.uk.xensource.com>
 <1363891353-13827-1-git-send-email-stefano.stabellini@eu.citrix.com>
 <1365515874.10725.33.camel@zakaz.uk.xensource.com>
 <1365687148.8036.140.camel@zakaz.uk.xensource.com>
 <20130411170959.GA2239@linaro.org>
Message-ID: <1365765378.15783.23.camel@zakaz.uk.xensource.com>

On Thu, 2013-04-11 at 18:10 +0100, Dave Martin wrote:
> On Thu, Apr 11, 2013 at 02:32:28PM +0100, Ian Campbell wrote:
> > Adding Charles and the l-a-k list which I hadn't noticed wasn't CC'd
> > before. Are there other lists which would be useful to include?
> > 
> > On Tue, 2013-04-09 at 14:57 +0100, Ian Campbell wrote:
> > > > +        if ( !hsr.iss )
> > > > +            return do_trap_psci(regs);
> 
> Have you seen this work?

I presume Stefano has.

> Reading the specs, I thought that the SMC immediate is not available in
> the HSR in ARMv7, or when the caller is AArch32.  ARMv7 specifies these
> bits as UNK/SBZP, and the A15 TRM doesn't seem seem to specify any
> extra information.

I trimmed the context so you probably don't know but this is handling
PSCI via an HVC call not SMC, Linux lets you specify which to use in the
DTB.

I didn't know that about SMC though -- think my eye confused it with
SVC when I scanned the docs. Kind of a lame limitation...

> Otherwise, you would need to go examine the trapped instruction in
> guest memory.  This is even less easy than it sounds.

Right, luckily we avoid it by using hvc.

> > > Ugh, using ISS==0 for this interface is a bit unfortunate, who
> > > arbitrates this namespace?
> 
> Nobody, officially.  ARM is working to promulgate some standards in
> this area, but there is plenty of pre-existing firmware and software
> out there with non-standardised interfaces and it's hard to predict
> adoption timescales.  I believe nothing is published relating to this
> just yet.
> 
> > Xen chose to use a non-0 immediate for its hypercalls so we are lucky
> > that we don't have to play tricks to distinguish PSCI calls from
> > hypercalls but it seems to me that either there needs to be some
> > semi-formal registry for smv/hvc immediates to avoid clashes or that
> > interfaces need to pick a random non-zero number to try and minimise the
> > chances of a clash.
> > 
> > Or maybe it gets pushed down a layer and the registry is of r0/x0
> > function ids and the immediate argument is generally ignored?
> > 
> > But in general we need some way for interfaces provided by hypervisors
> > and secure mode monitors to safely co-exist, I think, both for the case
> > where the hypervisor is implementing a shim for a secure mode interface
> > (i.e. implementing PSCI with hvc) and for the case where there are
> > multiple interfaces at each layer (e.g. hypervisors sometimes want to
> > implement foreign hypervisor interfaces and I can easily imagine other
> > firmware level interfaces than PSCI coming into existence in the
> > future).
> 
> For PSCI and similar firmware functionality, we envisage multiplexing
> all interfaces based on a function number in r0, with arguments and
> results constrained to r0-r7.  For PSCI, we specify SMC #0/HVC #0 as the
> call mechanism.
> 
> For now, there is no global management of the r0 namespace, which
> is why for PSCI we don't make static assumptions about the numbers
> on the client side.  Instead, the function number for each PSCI function
> is passed in the DT.  This means that the firmware or hypervisor can
> allocate the numbers as appropriate to avoid clashes.
> 
> In general, this is likely to be the best approach for Linux until a
> standard probing interface exists.

Yes, this is as good a scheme as we can hope for right now I think.
 
> In theory we could define a Xen-specific call mechanism for PSCI, but
> that should be avoided unless it is absolutely unavoidable.  It sounds
> like the different SMC comment field means that we don't need to
> worry for Xen/PSCI coexistence specifically, assuming that the hypervisor
> can read it reliably.

I think we've got the Xen side in hand, I was more bringing it up as a
general issue.

> > In the specific case of PSCI I couldn't actually find the calling
> > convention (i.e. the specific registers to use). I suspect I'm just
> > looking at an old version of the spec...
> 
> This is indeed vague in the existing draft.  An update should appear
> soon -- Charles can comment on the current status.
> 
> Cheers
> ---Dave





From lorenzo.pieralisi at arm.com  Fri Apr 12 07:16:49 2013
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Fri, 12 Apr 2013 12:16:49 +0100
Subject: [RFC PATCH 01/11] Documentation: DT: arm: define CPU topology
 bindings
In-Reply-To: <5166F908.9050503@gmail.com>
References: <1365671562-2403-1-git-send-email-mark.rutland@arm.com>
 <1365671562-2403-2-git-send-email-mark.rutland@arm.com>
 <5166D01F.5070404@gmail.com>
 <20130411155054.GA29509@e102568-lin.cambridge.arm.com>
 <5166F908.9050503@gmail.com>
Message-ID: <20130412111648.GA6637@e102568-lin.cambridge.arm.com>

On Thu, Apr 11, 2013 at 06:55:20PM +0100, Rob Herring wrote:

[...]

> >>> +The cpu-map node can only contain three types of child nodes:
> >>> +
> >>> +- cluster node
> >>> +- core node
> >>> +- thread node
> >>> +
> >>
> >> Why not put the topology in the /cpus nodes? I don't really see the
> >> point of having a flat list of cpus and separate topology info. There is
> >> some compatibility issue, but adding optional levels for clusters can be
> >> handled.
> >
> > I thought this would break all code relying on /cpu nodes being /cpus node's
> > children. Furthermore, I was told that the /cpus node can only have /cpu nodes
> > as children.
> 
> IIRC the context, that was in regards to putting things like the PMUs
> under the /cpus node. Or are you referring to something else? I think
> this situation is a bit different.

No I am referring to:

(a) PowerPC code relying on cpu nodes to be cpus node's children
(b) code that parses the DT cpus/cpu node for ARM that does require cpu
    nodes to be cpus node's children (but that has nothing to do with
    the bindings, code can be changed)

I think that our definition of cpu nodes does not comply with ePAPR 3.7,
since an MPIDR corresponding to an SMT thread cannot be represented with
one CPU node "A cpu node represents a hardware execution block that is
sufficiently independent that it is capable of running an operating
system without interfering with other CPUs possibly running other
operating systems".

This also has consequences on the cpu node bindings I am about to post
since if we go by the definition above a cpu node representing an SMT
core should contain a list of MPIDRs.

> You will have to support existing single cluster systems without the
> hierarchy.

Well yes, that's why we used another (optional) node to define the topology.

> > If you wish so, we can define the topology in the /cpus node, fine by me.
> >
> >>> +whose bindings are described in paragraph 3.
> >>> +
> >>> +The nodes describing the CPU topology (cluster/core/thread) can only be
> >>> +defined within the cpu-map node.
> >>> +Any other configuration is consider invalid and therefore must be ignored.
> >>> +
> >>> +===========================================
> >>> +2.1 - cpu-map child nodes naming convention
> >>> +===========================================
> >>> +
> >>> +cpu-map child nodes must follow a naming convention where the node name
> >>> +must be "clusterN", "coreN", "threadN" depending on the node type (ie
> >>> +cluster/core/thread) (where N = {0, 1, ...} is the node number; nodes which
> >>> +are siblings within a single common parent node must be given a unique and
> >>> +sequential N value, starting from 0).
> >>> +cpu-map child nodes which do not share a common parent node can have the same
> >>> +name (ie same number N as other cpu-map child nodes at different device tree
> >>> +levels) since name uniqueness will be guaranteed by the device tree hierarchy.
> >>> +
> >>> +===========================================
> >>> +3 - cluster/core/thread node bindings
> >>> +===========================================
> >>> +
> >>> +Bindings for cluster/cpu/thread nodes are defined as follows:
> >>> +
> >>> +- cluster node
> >>> +
> >>> +    Description: must be declared within a cpu-map node, one node
> >>> +                 per cluster. A system can contain several layers of
> >>> +                 clustering and cluster nodes can be contained in parent
> >>> +                 cluster nodes.
> >>> +
> >>> +   The cluster node name must be "clusterN" as described in 2.1 above.
> >>> +   A cluster node can not be a leaf node.
> >>
> >> Follow standard conventions with "cluster at N" and a reg property with the
> >> number.
> >
> > We are defining the topology to decouple the cluster/core/thread concept
> > from the MPIDR. Having a reg property in the cluster (and core) nodes
> > would complicate things if that reg property must correspond to an MPIDR
> > bitfield. If it is meant to be just an enumeration at a given device tree
> > level, I am ok with changing that.
> 
> Because the cluster itself doesn't really have an id, I'm fine if its
> not linked to the mpidr. Just don't change that later.

Eh, the cluster does have an id, that depends on the MPIDR du jour.
I will give it more thought.

> >>> +
> >>> +   A cluster node's child nodes must be:
> >>> +
> >>> +   - one or more cluster nodes; or
> >>> +   - one or more core nodes
> >>> +
> >>> +   Any other configuration is considered invalid.
> >>> +
> >>> +- core node
> >>> +
> >>> +   Description: must be declared in a cluster node, one node per core in
> >>> +                the cluster. If the system does not support SMT, core
> >>> +                nodes are leaf nodes, otherwise they become containers of
> >>> +                thread nodes.
> >>> +
> >>> +   The core node name must be "coreN" as described in 2.1 above.
> >>> +
> >>> +   A core node must be a leaf node if SMT is not supported.
> >>> +
> >>> +   Properties for core nodes that are leaf nodes:
> >>> +
> >>> +   - cpu
> >>> +           Usage: required
> >>> +           Value type: <phandle>
> >>> +           Definition: a phandle to the cpu node that corresponds to the
> >>> +                       core node.
> >>> +
> >>> +   If a core node is not a leaf node (CPUs supporting SMT) a core node's
> >>> +   child nodes can be:
> >>> +
> >>> +   - one or more thread nodes
> >>> +
> >>> +   Any other configuration is considered invalid.
> >>> +
> >>> +- thread node
> >>> +
> >>> +   Description: must be declared in a core node, one node per thread
> >>> +                in the core if the system supports SMT. Thread nodes are
> >>> +                always leaf nodes in the device tree.
> >>> +
> >>> +   The thread node name must be "threadN" as described in 2.1 above.
> >>> +
> >>> +   A thread node must be a leaf node.
> >>> +
> >>> +   A thread node must contain the following property:
> >>> +
> >>> +   - cpu
> >>> +           Usage: required
> >>> +           Value type: <phandle>
> >>> +           Definition: a phandle to the cpu node that corresponds to
> >>> +                       the thread node.
> >>
> >>
> >> According to the ePAPR, threads are represented by an array of ids for
> >> reg property, not another cpu node. Why the deviation.
> >
> > It is not a cpu node, it is a phandle property named cpu. Can you point
> > me to the ePAPR section where threads bindings are described please ? I have
> > not managed to find these details, I am reading version 1.0.
> >
> You should get 1.1.
> 
> From the reg prop description:
> 
> If a CPU supports more than one thread (i.e. multiple streams of
> execution) the reg property is an array with 1 element per thread. The
> #address-cells on the /cpus node specifies how many cells each element
> of the array takes. Software can determine the number of threads by
> dividing the size of reg by the parent node's #address-cells.

See above, I need to investigate what this implies.

> If a CPU/thread can be the target of an external interrupt the "reg"
> property value must be a unique CPU/thread id that is addressable by
> the interrupt controller.

I am not sure what "external" means here, but basically it looks like
our DT cpu bindings are non-compliant, the interrupt controller cannot
address a cpu by using an MPIDR (yet).

> If a CPU/thread cannot be the target of an external interrupt, then "reg"
> must be unique and out of bounds of the range addressed by the
> interrupt controller
> If a CPU/thread's PIR is modifiable, a client program should modify
> PIR to match the "reg" property value. If PIR cannot be modified and
> the PIR value is distinct from the interrupt controller numberspace, the
> CPUs binding may define a binding-specific representation of PIR
> values if desired.
> 
> 
> There is also this statement:
> 
> Hardware threads that share an MMU would generally be represented under
> one cpu node. If other
> more complex CPU topographies are designed, the binding for the CPU must
> describe the topography
> (e.g. threads that don't share an MMU).

Again, see above, HW threads do share an MMU so we have to make a
decision here, either we make ARM comply with ePAPR or change the
bindings for ARM.

Lorenzo



From gregory.clement at free-electrons.com  Fri Apr 12 07:18:28 2013
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Fri, 12 Apr 2013 13:18:28 +0200
Subject: [PATCH v2] clk: add device tree fixed-factor-clock binding support
In-Reply-To: <20130412103007.GE29291@ab42.lan>
References: <1365760708-4763-1-git-send-email-gregory.clement@free-electrons.com>
 <1365760708-4763-2-git-send-email-gregory.clement@free-electrons.com>
 <20130412103007.GE29291@ab42.lan>
Message-ID: <5167ED84.4020000@free-electrons.com>

On 04/12/2013 12:30 PM, Christian Ruppert wrote:
> Hi Gregory,
> 
> Just tested the patch and it works perfectly. Did you forget to update
> Documentation/devicetree/bindings/clock/fixed-factor-clock.txt, however?

Oh yes you're right. I will send a v3 with this modification.
Can I also add your tested-by flag?

Thanks,


> 
> Greetings,
>   Christian
> 
> On Fri, Apr 12, 2013 at 11:58:28AM +0200, Gregory CLEMENT wrote:
>> Add support for DT "fixed-factor-clock" binding to the common fixed
>> factor clock support.
>>
>> Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
>> ---
>>  .../bindings/clock/fixed-factor-clock.txt          |   24 +++++++++++++
>>  drivers/clk/clk-fixed-factor.c                     |   36 ++++++++++++++++++++
>>  include/linux/clk-provider.h                       |    2 ++
>>  3 files changed, 62 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/clock/fixed-factor-clock.txt
>>
>> diff --git a/Documentation/devicetree/bindings/clock/fixed-factor-clock.txt b/Documentation/devicetree/bindings/clock/fixed-factor-clock.txt
>> new file mode 100644
>> index 0000000..7ed236f
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/clock/fixed-factor-clock.txt
>> @@ -0,0 +1,24 @@
>> +Binding for simple fixed factor rate clock sources.
>> +
>> +This binding uses the common clock binding[1].
>> +
>> +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
>> +
>> +Required properties:
>> +- compatible : shall be "fixed-factor-clock".
>> +- #clock-cells : from common clock binding; shall be set to 0.
>> +- div: fixed divider.
>> +- mult: fixed multiplier.
>> +- clocks: parent clock.
>> +
>> +Optional properties:
>> +- clock-output-names : From common clock binding.
>> +
>> +Example:
>> +	clock {
>> +		compatible = "fixed-factor-clock";
>> +		clocks = <&parentclk>;
>> +		#clock-cells = <0>;
>> +		div = <2>;
>> +		mult = <1>;
>> +	};
>> diff --git a/drivers/clk/clk-fixed-factor.c b/drivers/clk/clk-fixed-factor.c
>> index 1ef271e..9ff7d51 100644
>> --- a/drivers/clk/clk-fixed-factor.c
>> +++ b/drivers/clk/clk-fixed-factor.c
>> @@ -11,6 +11,7 @@
>>  #include <linux/clk-provider.h>
>>  #include <linux/slab.h>
>>  #include <linux/err.h>
>> +#include <linux/of.h>
>>  
>>  /*
>>   * DOC: basic fixed multiplier and divider clock that cannot gate
>> @@ -96,3 +97,38 @@ struct clk *clk_register_fixed_factor(struct device *dev, const char *name,
>>  
>>  	return clk;
>>  }
>> +#ifdef CONFIG_OF
>> +/**
>> + * of_fixed_factor_clk_setup() - Setup function for simple fixed factor clock
>> + */
>> +void __init of_fixed_factor_clk_setup(struct device_node *node)
>> +{
>> +	struct clk *clk;
>> +	const char *clk_name = node->name;
>> +	const char *parent_name;
>> +	u32 div, mult;
>> +
>> +	if (of_property_read_u32(node, "clock-div", &div)) {
>> +		pr_err("%s Fixed factor clock <%s> must have a clock-div property\n",
>> +			__func__, node->name);
>> +		return;
>> +	}
>> +
>> +	if (of_property_read_u32(node, "clock-mult", &mult)) {
>> +		pr_err("%s Fixed factor clock <%s> must have a clokc-mult property\n",
>> +			__func__, node->name);
>> +		return;
>> +	}
>> +
>> +	of_property_read_string(node, "clock-output-names", &clk_name);
>> +	parent_name = of_clk_get_parent_name(node, 0);
>> +
>> +	clk = clk_register_fixed_factor(NULL, clk_name, parent_name, 0,
>> +					mult, div);
>> +	if (!IS_ERR(clk))
>> +		of_clk_add_provider(node, of_clk_src_simple_get, clk);
>> +}
>> +EXPORT_SYMBOL_GPL(of_fixed_factor_clk_setup);
>> +CLK_OF_DECLARE(fixed_factor_clk, "fixed-factor-clock",
>> +		of_fixed_factor_clk_setup);
>> +#endif
>> diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
>> index 7f197d7..7ea501b 100644
>> --- a/include/linux/clk-provider.h
>> +++ b/include/linux/clk-provider.h
>> @@ -325,6 +325,8 @@ struct clk *clk_register_fixed_factor(struct device *dev, const char *name,
>>  		const char *parent_name, unsigned long flags,
>>  		unsigned int mult, unsigned int div);
>>  
>> +void of_fixed_factor_clk_setup(struct device_node *node);
>> +
>>  /**
>>   * clk_register - allocate a new clock, register it and return an opaque cookie
>>   * @dev: device that is registering this clock
>> -- 
>> 1.7.9.5
>>
> 


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From nsekhar at ti.com  Fri Apr 12 07:20:25 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Fri, 12 Apr 2013 16:50:25 +0530
Subject: [PATCH] ARM: daVinci: dm644x/dm355/dm365: replace
 V4L2_STD_525_60/625_50 with V4L2_STD_NTSC/PAL
In-Reply-To: <1365764734-16515-1-git-send-email-prabhakar.csengg@gmail.com>
References: <1365764734-16515-1-git-send-email-prabhakar.csengg@gmail.com>
Message-ID: <5167EDF9.5070009@ti.com>



On 4/12/2013 4:35 PM, Prabhakar lad wrote:
> From: Lad, Prabhakar <prabhakar.csengg at gmail.com>
> 
> This patch replaces V4L2_STD_525_60/625_50 with V4L2_STD_NTSC/PAL
> respectively as this are the proper video standards.
> 
> Signed-off-by: Lad, Prabhakar <prabhakar.csengg at gmail.com>
> Reported-by: Hans Verkuil <hans.verkuil at cisco.com>
> Cc: Sekhar Nori <nsekhar at ti.com>

I assume you have tested it, some testing information would have been
good. The patch as such is OK with me. I assume this will go through
media tree for sake of dependencies.

Acked-by: Sekhar Nori <nsekhar at ti.com>

Thanks,
Sekhar

> ---
>  Note:- This patch is on top of following pull
>   https://patchwork.linuxtv.org/patch/17888/
> 
>  arch/arm/mach-davinci/board-dm355-evm.c  |    4 ++--
>  arch/arm/mach-davinci/board-dm365-evm.c  |    4 ++--
>  arch/arm/mach-davinci/board-dm644x-evm.c |    4 ++--
>  3 files changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/arm/mach-davinci/board-dm355-evm.c b/arch/arm/mach-davinci/board-dm355-evm.c
> index 1043506..886481c 100644
> --- a/arch/arm/mach-davinci/board-dm355-evm.c
> +++ b/arch/arm/mach-davinci/board-dm355-evm.c
> @@ -247,7 +247,7 @@ static struct vpbe_enc_mode_info dm355evm_enc_preset_timing[] = {
>  	{
>  		.name		= "ntsc",
>  		.timings_type	= VPBE_ENC_STD,
> -		.std_id		= V4L2_STD_525_60,
> +		.std_id		= V4L2_STD_NTSC,
>  		.interlaced	= 1,
>  		.xres		= 720,
>  		.yres		= 480,
> @@ -259,7 +259,7 @@ static struct vpbe_enc_mode_info dm355evm_enc_preset_timing[] = {
>  	{
>  		.name		= "pal",
>  		.timings_type	= VPBE_ENC_STD,
> -		.std_id		= V4L2_STD_625_50,
> +		.std_id		= V4L2_STD_PAL,
>  		.interlaced	= 1,
>  		.xres		= 720,
>  		.yres		= 576,
> diff --git a/arch/arm/mach-davinci/board-dm365-evm.c b/arch/arm/mach-davinci/board-dm365-evm.c
> index 0518ce5..2a66743 100644
> --- a/arch/arm/mach-davinci/board-dm365-evm.c
> +++ b/arch/arm/mach-davinci/board-dm365-evm.c
> @@ -381,7 +381,7 @@ static struct vpbe_enc_mode_info dm365evm_enc_std_timing[] = {
>  	{
>  		.name		= "ntsc",
>  		.timings_type	= VPBE_ENC_STD,
> -		.std_id		= V4L2_STD_525_60,
> +		.std_id		= V4L2_STD_NTSC,
>  		.interlaced	= 1,
>  		.xres		= 720,
>  		.yres		= 480,
> @@ -393,7 +393,7 @@ static struct vpbe_enc_mode_info dm365evm_enc_std_timing[] = {
>  	{
>  		.name		= "pal",
>  		.timings_type	= VPBE_ENC_STD,
> -		.std_id		= V4L2_STD_625_50,
> +		.std_id		= V4L2_STD_PAL,
>  		.interlaced	= 1,
>  		.xres		= 720,
>  		.yres		= 576,
> diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c b/arch/arm/mach-davinci/board-dm644x-evm.c
> index a021800..745280d 100644
> --- a/arch/arm/mach-davinci/board-dm644x-evm.c
> +++ b/arch/arm/mach-davinci/board-dm644x-evm.c
> @@ -622,7 +622,7 @@ static struct vpbe_enc_mode_info dm644xevm_enc_std_timing[] = {
>  	{
>  		.name		= "ntsc",
>  		.timings_type	= VPBE_ENC_STD,
> -		.std_id		= V4L2_STD_525_60,
> +		.std_id		= V4L2_STD_NTSC,
>  		.interlaced	= 1,
>  		.xres		= 720,
>  		.yres		= 480,
> @@ -634,7 +634,7 @@ static struct vpbe_enc_mode_info dm644xevm_enc_std_timing[] = {
>  	{
>  		.name		= "pal",
>  		.timings_type	= VPBE_ENC_STD,
> -		.std_id		= V4L2_STD_625_50,
> +		.std_id		= V4L2_STD_PAL,
>  		.interlaced	= 1,
>  		.xres		= 720,
>  		.yres		= 576,
> 


From broonie at opensource.wolfsonmicro.com  Fri Apr 12 07:26:18 2013
From: broonie at opensource.wolfsonmicro.com (Mark Brown)
Date: Fri, 12 Apr 2013 12:26:18 +0100
Subject: [alsa-devel] [PATCH 18/30] ASoC: samsung: move plat/ headers to
 local directory
In-Reply-To: <5167EA36.5080505@metafoo.de>
References: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
 <1365638712-1028578-19-git-send-email-arnd@arndb.de>
 <20130411164751.GK9243@opensource.wolfsonmicro.com>
 <201304111908.42532.arnd@arndb.de>
 <20130411171938.GS9243@opensource.wolfsonmicro.com>
 <5167EA36.5080505@metafoo.de>
Message-ID: <20130412112618.GW9243@opensource.wolfsonmicro.com>

On Fri, Apr 12, 2013 at 01:04:22PM +0200, Lars-Peter Clausen wrote:
> On 04/11/2013 07:19 PM, Mark Brown wrote:

> > Hrm, someone killed GTA02 support?  That's sad...  if that's really the
> > case we could kill the machine driver but not tonight as I'm running
> > late...

> I think the file was moved, we should pull over the audio relevant GPIO
> definitions into the ASoC board driver.

Yeah, so I see - Heiko sent a patch fixing this.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130412/1aa1c9e9/attachment.sig>

From prabhakar.csengg at gmail.com  Fri Apr 12 07:26:37 2013
From: prabhakar.csengg at gmail.com (Prabhakar Lad)
Date: Fri, 12 Apr 2013 16:56:37 +0530
Subject: [PATCH] ARM: daVinci: dm644x/dm355/dm365: replace
 V4L2_STD_525_60/625_50 with V4L2_STD_NTSC/PAL
In-Reply-To: <5167EDF9.5070009@ti.com>
References: <1365764734-16515-1-git-send-email-prabhakar.csengg@gmail.com>
 <5167EDF9.5070009@ti.com>
Message-ID: <CA+V-a8vKaHOX2FL5nP-0Tq2RBrRRHg0fhY3kT+tgVTOKdcyE5A@mail.gmail.com>

Sekhar,

On Fri, Apr 12, 2013 at 4:50 PM, Sekhar Nori <nsekhar at ti.com> wrote:
>
>
> On 4/12/2013 4:35 PM, Prabhakar lad wrote:
>> From: Lad, Prabhakar <prabhakar.csengg at gmail.com>
>>
>> This patch replaces V4L2_STD_525_60/625_50 with V4L2_STD_NTSC/PAL
>> respectively as this are the proper video standards.
>>
>> Signed-off-by: Lad, Prabhakar <prabhakar.csengg at gmail.com>
>> Reported-by: Hans Verkuil <hans.verkuil at cisco.com>
>> Cc: Sekhar Nori <nsekhar at ti.com>
>
> I assume you have tested it, some testing information would have been
> good. The patch as such is OK with me. I assume this will go through
> media tree for sake of dependencies.
>
> Acked-by: Sekhar Nori <nsekhar at ti.com>
>
Thanks for the ACK, Yes I have tested the patch. missed to add the tested info.
And yes this patch will go via media tree.

Regards,
--Prabhakar

> Thanks,
> Sekhar
>
>> ---
>>  Note:- This patch is on top of following pull
>>   https://patchwork.linuxtv.org/patch/17888/
>>
>>  arch/arm/mach-davinci/board-dm355-evm.c  |    4 ++--
>>  arch/arm/mach-davinci/board-dm365-evm.c  |    4 ++--
>>  arch/arm/mach-davinci/board-dm644x-evm.c |    4 ++--
>>  3 files changed, 6 insertions(+), 6 deletions(-)
>>
>> diff --git a/arch/arm/mach-davinci/board-dm355-evm.c b/arch/arm/mach-davinci/board-dm355-evm.c
>> index 1043506..886481c 100644
>> --- a/arch/arm/mach-davinci/board-dm355-evm.c
>> +++ b/arch/arm/mach-davinci/board-dm355-evm.c
>> @@ -247,7 +247,7 @@ static struct vpbe_enc_mode_info dm355evm_enc_preset_timing[] = {
>>       {
>>               .name           = "ntsc",
>>               .timings_type   = VPBE_ENC_STD,
>> -             .std_id         = V4L2_STD_525_60,
>> +             .std_id         = V4L2_STD_NTSC,
>>               .interlaced     = 1,
>>               .xres           = 720,
>>               .yres           = 480,
>> @@ -259,7 +259,7 @@ static struct vpbe_enc_mode_info dm355evm_enc_preset_timing[] = {
>>       {
>>               .name           = "pal",
>>               .timings_type   = VPBE_ENC_STD,
>> -             .std_id         = V4L2_STD_625_50,
>> +             .std_id         = V4L2_STD_PAL,
>>               .interlaced     = 1,
>>               .xres           = 720,
>>               .yres           = 576,
>> diff --git a/arch/arm/mach-davinci/board-dm365-evm.c b/arch/arm/mach-davinci/board-dm365-evm.c
>> index 0518ce5..2a66743 100644
>> --- a/arch/arm/mach-davinci/board-dm365-evm.c
>> +++ b/arch/arm/mach-davinci/board-dm365-evm.c
>> @@ -381,7 +381,7 @@ static struct vpbe_enc_mode_info dm365evm_enc_std_timing[] = {
>>       {
>>               .name           = "ntsc",
>>               .timings_type   = VPBE_ENC_STD,
>> -             .std_id         = V4L2_STD_525_60,
>> +             .std_id         = V4L2_STD_NTSC,
>>               .interlaced     = 1,
>>               .xres           = 720,
>>               .yres           = 480,
>> @@ -393,7 +393,7 @@ static struct vpbe_enc_mode_info dm365evm_enc_std_timing[] = {
>>       {
>>               .name           = "pal",
>>               .timings_type   = VPBE_ENC_STD,
>> -             .std_id         = V4L2_STD_625_50,
>> +             .std_id         = V4L2_STD_PAL,
>>               .interlaced     = 1,
>>               .xres           = 720,
>>               .yres           = 576,
>> diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c b/arch/arm/mach-davinci/board-dm644x-evm.c
>> index a021800..745280d 100644
>> --- a/arch/arm/mach-davinci/board-dm644x-evm.c
>> +++ b/arch/arm/mach-davinci/board-dm644x-evm.c
>> @@ -622,7 +622,7 @@ static struct vpbe_enc_mode_info dm644xevm_enc_std_timing[] = {
>>       {
>>               .name           = "ntsc",
>>               .timings_type   = VPBE_ENC_STD,
>> -             .std_id         = V4L2_STD_525_60,
>> +             .std_id         = V4L2_STD_NTSC,
>>               .interlaced     = 1,
>>               .xres           = 720,
>>               .yres           = 480,
>> @@ -634,7 +634,7 @@ static struct vpbe_enc_mode_info dm644xevm_enc_std_timing[] = {
>>       {
>>               .name           = "pal",
>>               .timings_type   = VPBE_ENC_STD,
>> -             .std_id         = V4L2_STD_625_50,
>> +             .std_id         = V4L2_STD_PAL,
>>               .interlaced     = 1,
>>               .xres           = 720,
>>               .yres           = 576,
>>


From arnd at arndb.de  Fri Apr 12 07:26:55 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 12 Apr 2013 13:26:55 +0200
Subject: [PATCH] ARM: pci: pass a parent to pci_common_init()
In-Reply-To: <1365719096-11639-1-git-send-email-linus.walleij@linaro.org>
References: <1365719096-11639-1-git-send-email-linus.walleij@linaro.org>
Message-ID: <201304121326.56030.arnd@arndb.de>

On Friday 12 April 2013, Linus Walleij wrote:
> When working with device tree support for PCI on ARM you run
> into a problem when mapping IRQs from the device tree irqmaps:
> doing this the code in drivers/of/of_pci_irq.c will try to
> find the OF node on the root bridge and this fails, because
> bus->dev.of_node is NULL, and that in turn boils down to
> the fact that pci_set_bus_of_node() has called
> pcibios_get_phb_of_node() from drivers/pci/of.c to obtain
> the OF node of the bridge or its parent and none is set
> and thus NULL is returned.
> 
> Fix this by adding an additional parent argument when
> registering PCI bridges on the ARM architecture using the
> pci_common_init() call, and pass along this parent to
> pci_scan_root_bus() called from pcibios_init_hw() in
> bios32.c and voila: the IRQ mappings start working:
> the OF node can be retrieved from the parent.
> 
> Currently all users are set to use NULL as argument to this
> call, but subsequent patches to the Integrator/AP make use
> of this facility to pass a parent.

Could you try making it a less invasive patch by renaming
pci_common_init to something else and providing a wrapper
like this?

static inline void pci_common_init(struct hw_pci *hw)
{
	pci_common_init_dev(NULL, hw);
}

That would avoid most of the churn and get the same result.

	Arnd


From lorenzo.pieralisi at arm.com  Fri Apr 12 07:27:08 2013
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Fri, 12 Apr 2013 12:27:08 +0100
Subject: [RFC PATCH 01/11] Documentation: DT: arm: define CPU topology
 bindings
In-Reply-To: <20130411181710.GC2239@linaro.org>
References: <1365671562-2403-1-git-send-email-mark.rutland@arm.com>
 <1365671562-2403-2-git-send-email-mark.rutland@arm.com>
 <5166D01F.5070404@gmail.com>
 <20130411155054.GA29509@e102568-lin.cambridge.arm.com>
 <5166F908.9050503@gmail.com> <20130411181710.GC2239@linaro.org>
Message-ID: <20130412112707.GB6637@e102568-lin.cambridge.arm.com>

On Thu, Apr 11, 2013 at 07:17:10PM +0100, Dave Martin wrote:
> On Thu, Apr 11, 2013 at 12:55:20PM -0500, Rob Herring wrote:
> > On 04/11/2013 10:50 AM, Lorenzo Pieralisi wrote:
> > > On Thu, Apr 11, 2013 at 04:00:47PM +0100, Rob Herring wrote:
> > >> On 04/11/2013 04:12 AM, Mark Rutland wrote:
> > >>> From: Lorenzo Pieralisi <Lorenzo.Pieralisi at arm.com>
> 
> [...]
> 
> > >>> +===========================================
> > >>> +3 - cluster/core/thread node bindings
> > >>> +===========================================
> > >>> +
> > >>> +Bindings for cluster/cpu/thread nodes are defined as follows:
> > >>> +
> > >>> +- cluster node
> > >>> +
> > >>> +	 Description: must be declared within a cpu-map node, one node
> > >>> +		      per cluster. A system can contain several layers of
> > >>> +		      clustering and cluster nodes can be contained in parent
> > >>> +		      cluster nodes.
> > >>> +
> > >>> +	The cluster node name must be "clusterN" as described in 2.1 above.
> > >>> +	A cluster node can not be a leaf node.
> > >>
> > >> Follow standard conventions with "cluster at N" and a reg property with the
> > >> number.
> > > 
> > > We are defining the topology to decouple the cluster/core/thread concept
> > > from the MPIDR. Having a reg property in the cluster (and core) nodes
> > > would complicate things if that reg property must correspond to an MPIDR
> > > bitfield. If it is meant to be just an enumeration at a given device tree
> > > level, I am ok with changing that.
> > 
> > Because the cluster itself doesn't really have an id, I'm fine if its
> > not linked to the mpidr. Just don't change that later.
> 
> These enumerations can follow the MPIDR for convenience if the MPIDR
> allocations are sane, but otherwise it would be abstract.  The Architecture
> doesn't specify any kind of an ID for a cluster (indeed, it doesn't really
> specify what a cluster is at all).
> 
> 
> However, we could require a platform or SoC binding to specify the
> enumeration and it how it maps to the actual hardware -- i.e., cluster at 1
> on Tuesday should be the same physical cluster as cluster at 1 on Monday,
> to the extent that cluster at 1 is present in the DT on both days and the
> hardware hasn't been physically modified (i.e., cluster at 1 might refer
> to a fixed physical socket on a hypothetical board with physically
> pluggable CPU modules).
> 
> Correspondingly, on TC2, cluster at 0 would always be the A15 cluster;
> cluster at 1 would always be the A7 cluster.  But if the firmware disables
> one of them, that cluster and the relevant CPU nodes should be removed
> from the DT before passing it to the kernel.
> 
> Does this make any sense, or is it overkill?

I think we can say that the reg property must correspond to a cluster
id, irrespective of the MPIDR. Whatever it is, as you said, a platform
has to have a cluster numbering scheme. How it is mapped to the MPIDR
that's platform specific. So I am happy to add a reg property but
linking it to the MPIDR goes against what we are doing here hence I
would not do it, simply because we can't say "cluster reg property must
be MPIDR[15:8]", that's wrong and there is precious little we can do
about that.

Lorenzo



From s.hauer at pengutronix.de  Fri Apr 12 07:29:48 2013
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Fri, 12 Apr 2013 13:29:48 +0200
Subject: [PATCH 1/3] ARM/MVF600: add Vybrid Family platform support
In-Reply-To: <1365749825-20601-2-git-send-email-b35083@freescale.com>
References: <1365749825-20601-1-git-send-email-b35083@freescale.com>
 <1365749825-20601-2-git-send-email-b35083@freescale.com>
Message-ID: <20130412112948.GC10373@pengutronix.de>

Hi,

Some comments inline.

On Fri, Apr 12, 2013 at 02:57:03PM +0800, Jingchang Lu wrote:
> This patch adds Freescale Vybrid Family platform core definitions,
> core drivers including clock, period interrupt timer(PIT),
> and DTS based machine support with MVF600 Tower development board.
> 
> Signed-off-by: Jingchang Lu <b35083 at freescale.com>
> ---
>  arch/arm/mach-imx/Kconfig       |  39 +++++
>  arch/arm/mach-imx/Makefile      |   4 +
>  arch/arm/mach-imx/Makefile.boot |   4 +
>  arch/arm/mach-imx/clk-mvf.c     | 320 ++++++++++++++++++++++++++++++++++++++++
>  arch/arm/mach-imx/common.h      |   3 +
>  arch/arm/mach-imx/mach-mvf600.c | 121 +++++++++++++++
>  arch/arm/mach-imx/pit.c         | 254 +++++++++++++++++++++++++++++++
>  7 files changed, 745 insertions(+)
>  create mode 100644 arch/arm/mach-imx/clk-mvf.c
>  create mode 100644 arch/arm/mach-imx/mach-mvf600.c
>  create mode 100644 arch/arm/mach-imx/pit.c
> 
> diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
> index 4c9c6f9..173258b 100644
> --- a/arch/arm/mach-imx/Kconfig
> +++ b/arch/arm/mach-imx/Kconfig
> @@ -55,6 +55,16 @@ config MXC_USE_EPIT
>  	  uses the same clocks as the GPT. Anyway, on some systems the GPT
>  	  may be in use for other purposes.
>  
> +config HAVE_PIT
> +	bool
> +
> +config MXC_USE_PIT
> +	bool "Use PIT"
> +	depends on HAVE_PIT
> +	help
> +          Use PIT as the system timer on systems that have it
> +	  such as Vybrid platform.

Indention broken here.

> +config MACH_MVF600_TWR
> +	bool "Vybrid MVF600 Tower support"
> +	select SOC_MVF600
> +
> +	help
> +          Include support for Freescale Vybrid Family Tower Board
> +	  based on MVF600 SOC.

and here.

> +
>  endif
>  
>  source "arch/arm/mach-imx/devices/Kconfig"

[...]

> +++ b/arch/arm/mach-imx/clk-mvf.c
> @@ -0,0 +1,320 @@
> +/*
> + * Copyright 2012-2013 Freescale Semiconductor, Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License along
> + * with this program; if not, write to the Free Software Foundation, Inc.,
> + * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.

Please remove the FSF address. It's wrong and we don't want to keep it
up to date in the kernel.

> +int __init mvf_clocks_init(void)
> +{
> +	struct device_node *np;
> +	__iomem void *base;
> +	int irq;
> +
> +	clk[dummy] = imx_clk_fixed("dummy", 0);
> +	clk[sirc] = imx_clk_fixed("sirc", 32000); /* slow internal IRC */
> +	clk[firc] = imx_clk_fixed("firc", 24000000);/* fast internal IRC */
> +
> +	for_each_compatible_node(np, NULL, "fixed-clock") {
> +		u32 rate;
> +
> +		if (of_property_read_u32(np, "clock-frequency", &rate))
> +			continue;
> +		if (of_device_is_compatible(np, "fsl,mvf-ckil"))
> +			clk[sxosc] = imx_clk_fixed("sxosc", rate);
> +		else if (of_device_is_compatible(np, "fsl,mvf-osc"))
> +			clk[fxosc] = imx_clk_fixed("fxosc", rate);
> +		else if (of_device_is_compatible(np, "fsl,mvf-audio-ext-clk"))
> +			clk[audio_ext_clk] =
> +					imx_clk_fixed("audio_ext_clk", rate);
> +		else if (of_device_is_compatible(np, "fsl,mvf-enet-ext-clk"))
> +			clk[enet_ext_clk] = imx_clk_fixed("enet_ext", rate);
> +	}

Rather than doing it this way you should use some variables which you
initialize to sane defaults and overwrite them as necessary in the
for_each_compatible_node loop. This way you won't end up with
unitialized clocks when some clock is missing in the devicetree.

> +
> +	np = of_find_compatible_node(NULL, NULL, "fsl,mvf-anatop");
> +	anatop_base = of_iomap(np, 0);
> +	WARN_ON(!anatop_base);
> +
> +	np = of_find_compatible_node(NULL, NULL, "fsl,mvf-ccm");
> +	ccm_base = of_iomap(np, 0);
> +	WARN_ON(!ccm_base);
> +
> +	clk[slow_clk] = imx_clk_mux("slow_clk", CCM_CCSR, 4, 1,
> +			slow_clk_sel, ARRAY_SIZE(slow_clk_sel));
> +	clk[fast_clk] = imx_clk_mux("fast_clk", CCM_CCSR, 5, 1,
> +			fast_clk_sel, ARRAY_SIZE(fast_clk_sel));
> +
> +	clk[pll1_main_528m] = imx_clk_fixed_factor("pll1_main",
> +						"fast_clk", 22, 1);
> +	clk[pll1_pfd1_500m] = imx_clk_pfd("pll1_pfd1", "pll1_main",
> +						PFD_528SYS_BASE, 0);
> +	clk[pll1_pfd2_452m] = imx_clk_pfd("pll1_pfd2", "pll1_main",
> +						PFD_528SYS_BASE, 1);
> +	clk[pll1_pfd3_396m] = imx_clk_pfd("pll1_pfd3", "pll1_main",
> +						PFD_528SYS_BASE, 2);
> +	clk[pll1_pfd4_528m] = imx_clk_pfd("pll1_pfd4", "pll1_main",
> +						PFD_528SYS_BASE, 3);
> +
> +	clk[pll2_main_528m] = imx_clk_fixed_factor("pll2_main",
> +						"fast_clk", 22, 1);
> +	clk[pll2_pfd1_500m] = imx_clk_pfd("pll2_pfd1", "pll2_main",
> +						PFD_528_BASE, 0);
> +	clk[pll2_pfd2_396m] = imx_clk_pfd("pll2_pfd2", "pll2_main",
> +						PFD_528_BASE, 1);
> +	clk[pll2_pfd3_339m] = imx_clk_pfd("pll2_pfd3", "pll2_main",
> +						PFD_528_BASE, 2);
> +	clk[pll2_pfd4_413m] = imx_clk_pfd("pll2_pfd4", "pll2_main",
> +						PFD_528_BASE, 3);

I suggest ignoring the 80 character limit for most of this file. It will
make for better readability.

> +
> +	/* USB pll, 480Mhz */
> +	clk[pll3_main_480m] = imx_clk_fixed_factor("usb_main",
> +						"fast_clk", 20, 1);
> +	/* Audio pll */
> +	clk[pll4_main] = imx_clk_fixed_factor("audio_main", "fast_clk", 25, 1);
> +	/* Enet pll, fixed to 50Mhz on Vybrid */
> +	clk[pll5_main] = imx_clk_fixed_factor("pll5_main", "fast_clk", 125, 6);
> +	clk[enet_50m] = imx_clk_fixed_factor("enet_50m", "pll5_main", 1, 10);
> +	clk[enet_25m] = imx_clk_fixed_factor("enet_25m", "pll5_main", 1, 20);
> +	/* Video pll: default 960Mhz */
> +	clk[pll6_main] = imx_clk_fixed_factor("video_main", "fast_clk", 40, 1);
> +
> +	clk[pll1_pfd_sw] = imx_clk_mux("pll1_sw", CCM_CCSR, 16, 3,
> +			pll1_pfd_sel, ARRAY_SIZE(pll1_pfd_sel));
> +
> +	clk[pll2_pfd_sw] = imx_clk_mux("pll2_sw", CCM_CCSR, 19, 3,
> +			pll2_pfd_sel, ARRAY_SIZE(pll2_pfd_sel));
> +
> +	clk[sys_clk_sw] = imx_clk_mux("sys_sw", CCM_CCSR, 0, 3,
> +			sys_clk_sel, ARRAY_SIZE(sys_clk_sel));
> +
> +	clk[ddr_clk_sw] = imx_clk_mux("ddr_sw", CCM_CCSR, 6, 1,
> +			ddr_clk_sel, ARRAY_SIZE(ddr_clk_sel));
> +
> +	clk[sys_bus_clk] = imx_clk_divider("sys_bus", "sys_sw",
> +						CCM_CACRR, 0, 3);
> +	clk[platform_bus_clk] = imx_clk_divider("platform_bus", "sys_bus",
> +						CCM_CACRR, 3, 3);
> +	clk[ipg_bus_clk] = imx_clk_divider("ipg_bus", "platform_bus",
> +						CCM_CACRR, 11, 2);
> +
> +	clk[qspi0_clk_sw] = imx_clk_mux("qspi0_sw", CCM_CSCMR1, 22, 2,
> +					qspi_clk_sel, ARRAY_SIZE(qspi_clk_sel));
> +	clk[qspi0_x4_div] = imx_clk_divider("qspi0_x4", "qspi0_sw",
> +						CCM_CSCDR3, 0, 2);
> +	clk[qspi0_x2_div] = imx_clk_divider("qspi0_x2", "qspi0_x4",
> +						CCM_CSCDR3, 2, 1);
> +	clk[qspi0_x1_div] = imx_clk_divider("qspi0_x1", "qspi0_x2",
> +					CCM_CSCDR3, 3, 1);
> +	clk[qspi0_clk_gate] = imx_clk_gate("qspi0_clk", "qspi0_x1",
> +					CCM_CSCDR3, 4);
> +
> +	clk[enet_clk_sw] = imx_clk_mux("enet_sw", CCM_CSCMR2, 4, 2,
> +				rmii_clk_sel, ARRAY_SIZE(rmii_clk_sel));
> +	clk[enet_clk_gate] = imx_clk_gate("enet_clk", "enet_sw",
> +				CCM_CSCDR1, 24);
> +	clk[enet_ts_sw] = imx_clk_mux("enet_ts_sw", CCM_CSCMR2, 0, 3,
> +				enet_ts_clk_sel, ARRAY_SIZE(enet_ts_clk_sel));
> +	clk[enet_ts_gate] = imx_clk_gate("enet_ts_clk", "enet_ts_sw",
> +				CCM_CSCDR1, 23);
> +
> +	clk[pit_clk_gate] = imx_clk_gate2("pit_clk", "ipg_bus", CCM_CCGR1,
> +						CCM_CCGRx_CGn_OFFSET(7));
> +	clk[uart0_clk_gate] = imx_clk_gate2("uart0_clk", "ipg_bus", CCM_CCGR0,
> +						CCM_CCGRx_CGn_OFFSET(7));
> +
> +	/* Add the clocks to provider list */
> +	clk_data.clks = clk;
> +	clk_data.clk_num = ARRAY_SIZE(clk);
> +	of_clk_add_provider(np, of_clk_src_onecell_get, &clk_data);
> +
> +	clk_register_clkdev(clk[pit_clk_gate], "mvf-pit", NULL);
> +	clk_register_clkdev(clk[uart0_clk_gate], "mvf-uart", NULL);
> +	clk_register_clkdev(clk[uart0_clk_gate], "mvf_uart.0", NULL);
> +	clk_register_clkdev(clk[uart0_clk_gate], "mvf_uart.1", NULL);
> +	clk_register_clkdev(clk[enet_clk_gate], "fec.0", NULL);
> +	clk_register_clkdev(clk[enet_clk_gate], "fec.1", NULL);
> +	clk_register_clkdev(clk[enet_clk_gate], "switch.0", NULL);
> +	clk_register_clkdev(clk[qspi0_clk_gate], "qspi.0", NULL);

These shouldn't be here. You have the lookups in the devicetree anyway.

> +
> +	clk_set_parent(clk[qspi0_x4_div], clk[pll1_pfd4_528m]);
> +	clk_set_rate(clk[qspi0_x4_div],
> +			clk_get_rate(clk[qspi0_x4_div]->parent) / 2);
> +	clk_set_rate(clk[qspi0_x2_div],
> +			clk_get_rate(clk[qspi0_x2_div]->parent) / 2);
> +	clk_set_rate(clk[qspi0_x1_div],
> +			clk_get_rate(clk[qspi0_x1_div]->parent) / 2);
> +
> +
> +	clk_prepare(clk[pit_clk_gate]);
> +	clk_prepare(clk[uart0_clk_gate]);

No. Do not enable driver clocks here.

> +	clk_prepare(clk[enet_clk_gate]);
> +
> +	/* init system timer */
> +	np = of_find_compatible_node(NULL, NULL, "fsl,mvf-pit");
> +	base = of_iomap(np, 0);
> +	WARN_ON(!base);
> +	irq = irq_of_parse_and_map(np, 0);
> +	pit_timer_init(base, irq);

This should be switched to CLOCKSOURCE_OF_DECLARE.

> +
> +	return 0;
> +}

[...]

> +
> +static struct clock_event_device clockevent_pit = {
> +	.name		= "pit",
> +	.features	= CLOCK_EVT_FEAT_PERIODIC,

Only periodic support? That's really boring. Why isn't oneshot mode
supported?

> +	.shift		= 32,
> +	.set_mode	= pit_set_mode,
> +	.set_next_event	= pit_set_next_event,
> +	.rating		= 100,
> +};
> +
> +static int __init pit_clockevent_init(struct clk *pit_clk)
> +{
> +	unsigned int c = clk_get_rate(pit_clk);
> +
> +	clockevent_pit.mult = div_sc(c, NSEC_PER_SEC,
> +					clockevent_pit.shift);
> +	clockevent_pit.max_delta_ns =
> +			clockevent_delta2ns(0xfffffffe, &clockevent_pit);
> +	clockevent_pit.min_delta_ns =
> +			clockevent_delta2ns(0x800, &clockevent_pit);
> +	clockevent_pit.cpumask = cpumask_of(0);
> +	clockevents_register_device(&clockevent_pit);
> +
> +	return 0;
> +}
> +
> +void __init pit_timer_init(void __iomem *base, int irq)
> +{
> +	struct clk *pit_clk;
> +
> +	pit_clk = clk_get_sys(NULL, "mvf-pit");
> +	if (IS_ERR(pit_clk)) {
> +		pr_err("Vybrid PIT timer: unable to get clk\n");
> +		return;
> +	}

base, irq and clk should really be taken from the devicetree. We have
all necessary stuff in the kernel (only the i.MX template you copied
from doesn't use it yet).

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From s.hauer at pengutronix.de  Fri Apr 12 07:39:55 2013
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Fri, 12 Apr 2013 13:39:55 +0200
Subject: [PATCH 2/3] ARM:DTS:MVF600: add basic device tree source
In-Reply-To: <1365749825-20601-3-git-send-email-b35083@freescale.com>
References: <1365749825-20601-1-git-send-email-b35083@freescale.com>
 <1365749825-20601-3-git-send-email-b35083@freescale.com>
Message-ID: <20130412113955.GD10373@pengutronix.de>

On Fri, Apr 12, 2013 at 02:57:04PM +0800, Jingchang Lu wrote:
> This patch adds basic device tree source for Freescale
> Vybrid Family platform and Tower development board.
> 
> Signed-off-by: Xiaochun Li <b41219 at freescale.com>
> Signed-off-by: Jingchang Lu <b35083 at freescale.com>
> ---
>  arch/arm/boot/dts/imx-mvf600.dtsi   | 442 ++++++++++++++++++++++++++++++++++++
>  arch/arm/boot/dts/imx-mvf600twr.dts |  82 +++++++
>  2 files changed, 524 insertions(+)
>  create mode 100644 arch/arm/boot/dts/imx-mvf600.dtsi
>  create mode 100644 arch/arm/boot/dts/imx-mvf600twr.dts
> 
> diff --git a/arch/arm/boot/dts/imx-mvf600.dtsi b/arch/arm/boot/dts/imx-mvf600.dtsi
> new file mode 100644
> index 0000000..3a534c6
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx-mvf600.dtsi
> @@ -0,0 +1,442 @@
> +/*
> + * Copyright 2013 Freescale Semiconductor, Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License along
> + * with this program; if not, write to the Free Software Foundation, Inc.,
> + * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
> + */
> +
> +/include/ "skeleton.dtsi"
> +
> +/ {
> +	aliases {
> +		serial0 = &uart1;
> +		serial1 = &uart2;
> +		serial2 = &uart3;
> +		serial3 = &uart4;
> +		serial4 = &uart5;
> +		serial5 = &uart6;
> +		gpio0 = &gpio1;
> +		gpio1 = &gpio2;
> +		gpio2 = &gpio3;
> +		gpio3 = &gpio4;
> +		gpio4 = &gpio5;
> +	};
> +
> +
> +	clocks {
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
> +		ckil {
> +			compatible = "fsl,mvf-ckil", "fixed-clock";
> +			clock-frequency = <32768>;
> +		};
> +
> +		ckih1 {
> +			compatible = "fsl,mvf-ckih1", "fixed-clock";
> +			clock-frequency = <0>;
> +		};
> +
> +		osc {
> +			compatible = "fsl,mvf-osc", "fixed-clock";
> +			clock-frequency = <24000000>;
> +		};
> +	};
> +
> +
> +	soc {
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +		compatible = "simple-bus";
> +		interrupt-parent = <&intc>;
> +		ranges;
> +
> +		aips0: aips-bus at 40000000 { /* AIPS0 */
> +			compatible = "fsl,aips-bus", "simple-bus";
> +			#address-cells = <1>;
> +			#size-cells = <1>;
> +			interrupt-parent = <&intc>;
> +			reg = <0x40000000 0x70000>;
> +			ranges;
> +
> +			mscm: mscm at 40001000 {
> +				compatible = "fsl,mvf-mscm";
> +				reg = <0x40001000 0x1000>;
> +			};
> +
> +			intc: interrupt-controller at 40002000 {
> +				compatible = "arm,cortex-a9-gic";
> +				#interrupt-cells = <3>;
> +				#address-cells = <1>;
> +				#size-cells = <1>;
> +				interrupt-controller;
> +				reg = <0x40003000 0x1000>,
> +				      <0x40002100 0x100>;
> +			};
> +
> +			L2: l2-cache at 40006000 {
> +				compatible = "arm,pl310-cache";
> +				reg = <0x40006000 0x1000>;
> +				interrupts = <0 6 0x04>;
> +				cache-unified;
> +				cache-level = <2>;
> +			};
> +
> +			uart1: serial at 40027000 { /* UART0 */

That's the first time Freescale actually starts counting at zero. Let's
be grateful for that and just use it instead of renumbering it.

> +
> +			pinctrl1: iomuxc at 40047000 {
> +				compatible = "fsl,mvf-iomuxc";
> +				reg = <0x40047000 0x2000>;
> +				#gpio-range-cells = <2>;
> +
> +				/* iomux setting */
> +				esdhc1 {
> +					pinctrl_esdhc1_1: esdhc1grp_1 {
> +						fsl,pins = <
> +						85 0x5031ef /* PTA24__SDHC1_CLK */
> +						91 0x5031ef /* PTA25__SDHC1_CMD */
> +						96 0x5031ef /* PTA26__SDHC1_DAT0 */
> +						101 0x5031ef /* PTA27__SDHC1_DAT1 */
> +						108 0x5031ef /* PTA28__SDHC1_DAT2 */
> +						115 0x5031ef /* PTA29__SDHC1_DAT3 */
> +						776 0x219d /* PTA7__SDHC1_SW_CD */
> +					>;
> +					};

I have no idea how the iomux works on vybrid, but Shawn just eliminated
the magic numbers for the pins. Let's not reintroduce them for vybrid if
possible.


-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From rjw at sisk.pl  Fri Apr 12 07:50:36 2013
From: rjw at sisk.pl (Rafael J. Wysocki)
Date: Fri, 12 Apr 2013 13:50:36 +0200
Subject: [PATCH] PM / Runtime: Improve prepare handling at system suspend
 for genpd
In-Reply-To: <1365759704-23722-1-git-send-email-ulf.hansson@stericsson.com>
References: <1365759704-23722-1-git-send-email-ulf.hansson@stericsson.com>
Message-ID: <1844674.ZBv3XGts1U@vostro.rjw.lan>

On Friday, April 12, 2013 11:41:44 AM Ulf Hansson wrote:
> From: Ulf Hansson <ulf.hansson at linaro.org>
> 
> When genpd prepares for a system suspend it will fetch a runtime
> reference for the device. When returning it we now use the
> asyncronous runtime PM API. Thus we don't have to wait for the
> device to become idle|suspended before we move on and handle the
> next device in queue.
> 
> Signed-off-by: Ulf Hansson <ulf.hansson at linaro.org>
> Cc: Kevin Hilman <khilman at linaro.org>
> Cc: Alan Stern <stern at rowland.harvard.edu>

All three patches applied to linux-pm.git/linux-next.

Thanks,
Rafael


> ---
>  drivers/base/power/domain.c |    4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
> index 9a6b05a..e6ec4a7 100644
> --- a/drivers/base/power/domain.c
> +++ b/drivers/base/power/domain.c
> @@ -920,7 +920,7 @@ static int pm_genpd_prepare(struct device *dev)
>  		pm_wakeup_event(dev, 0);
>  
>  	if (pm_wakeup_pending()) {
> -		pm_runtime_put_sync(dev);
> +		pm_runtime_put(dev);
>  		return -EBUSY;
>  	}
>  
> @@ -961,7 +961,7 @@ static int pm_genpd_prepare(struct device *dev)
>  		pm_runtime_enable(dev);
>  	}
>  
> -	pm_runtime_put_sync(dev);
> +	pm_runtime_put(dev);
>  	return ret;
>  }
>  
> 
-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.


From christian.ruppert at abilis.com  Fri Apr 12 07:42:40 2013
From: christian.ruppert at abilis.com (Christian Ruppert)
Date: Fri, 12 Apr 2013 13:42:40 +0200
Subject: [PATCH v2] clk: add device tree fixed-factor-clock binding support
In-Reply-To: <5167ED84.4020000@free-electrons.com>
References: <1365760708-4763-1-git-send-email-gregory.clement@free-electrons.com>
 <1365760708-4763-2-git-send-email-gregory.clement@free-electrons.com>
 <20130412103007.GE29291@ab42.lan>
 <5167ED84.4020000@free-electrons.com>
Message-ID: <20130412114240.GA26039@ab42.lan>

On Fri, Apr 12, 2013 at 01:18:28PM +0200, Gregory CLEMENT wrote:
> On 04/12/2013 12:30 PM, Christian Ruppert wrote:
> > Hi Gregory,
> > 
> > Just tested the patch and it works perfectly. Did you forget to update
> > Documentation/devicetree/bindings/clock/fixed-factor-clock.txt, however?
> 
> Oh yes you're right. I will send a v3 with this modification.
> Can I also add your tested-by flag?

definitely.

> > 
> > Greetings,
> >   Christian
> > 
> > On Fri, Apr 12, 2013 at 11:58:28AM +0200, Gregory CLEMENT wrote:
> >> Add support for DT "fixed-factor-clock" binding to the common fixed
> >> factor clock support.
> >>
> >> Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
> >> ---
> >>  .../bindings/clock/fixed-factor-clock.txt          |   24 +++++++++++++
> >>  drivers/clk/clk-fixed-factor.c                     |   36 ++++++++++++++++++++
> >>  include/linux/clk-provider.h                       |    2 ++
> >>  3 files changed, 62 insertions(+)
> >>  create mode 100644 Documentation/devicetree/bindings/clock/fixed-factor-clock.txt
> >>
> >> diff --git a/Documentation/devicetree/bindings/clock/fixed-factor-clock.txt b/Documentation/devicetree/bindings/clock/fixed-factor-clock.txt
> >> new file mode 100644
> >> index 0000000..7ed236f
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/clock/fixed-factor-clock.txt
> >> @@ -0,0 +1,24 @@
> >> +Binding for simple fixed factor rate clock sources.
> >> +
> >> +This binding uses the common clock binding[1].
> >> +
> >> +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
> >> +
> >> +Required properties:
> >> +- compatible : shall be "fixed-factor-clock".
> >> +- #clock-cells : from common clock binding; shall be set to 0.
> >> +- div: fixed divider.
> >> +- mult: fixed multiplier.
> >> +- clocks: parent clock.
> >> +
> >> +Optional properties:
> >> +- clock-output-names : From common clock binding.
> >> +
> >> +Example:
> >> +	clock {
> >> +		compatible = "fixed-factor-clock";
> >> +		clocks = <&parentclk>;
> >> +		#clock-cells = <0>;
> >> +		div = <2>;
> >> +		mult = <1>;
> >> +	};
> >> diff --git a/drivers/clk/clk-fixed-factor.c b/drivers/clk/clk-fixed-factor.c
> >> index 1ef271e..9ff7d51 100644
> >> --- a/drivers/clk/clk-fixed-factor.c
> >> +++ b/drivers/clk/clk-fixed-factor.c
> >> @@ -11,6 +11,7 @@
> >>  #include <linux/clk-provider.h>
> >>  #include <linux/slab.h>
> >>  #include <linux/err.h>
> >> +#include <linux/of.h>
> >>  
> >>  /*
> >>   * DOC: basic fixed multiplier and divider clock that cannot gate
> >> @@ -96,3 +97,38 @@ struct clk *clk_register_fixed_factor(struct device *dev, const char *name,
> >>  
> >>  	return clk;
> >>  }
> >> +#ifdef CONFIG_OF
> >> +/**
> >> + * of_fixed_factor_clk_setup() - Setup function for simple fixed factor clock
> >> + */
> >> +void __init of_fixed_factor_clk_setup(struct device_node *node)
> >> +{
> >> +	struct clk *clk;
> >> +	const char *clk_name = node->name;
> >> +	const char *parent_name;
> >> +	u32 div, mult;
> >> +
> >> +	if (of_property_read_u32(node, "clock-div", &div)) {
> >> +		pr_err("%s Fixed factor clock <%s> must have a clock-div property\n",
> >> +			__func__, node->name);
> >> +		return;
> >> +	}
> >> +
> >> +	if (of_property_read_u32(node, "clock-mult", &mult)) {
> >> +		pr_err("%s Fixed factor clock <%s> must have a clokc-mult property\n",
> >> +			__func__, node->name);
> >> +		return;
> >> +	}
> >> +
> >> +	of_property_read_string(node, "clock-output-names", &clk_name);
> >> +	parent_name = of_clk_get_parent_name(node, 0);
> >> +
> >> +	clk = clk_register_fixed_factor(NULL, clk_name, parent_name, 0,
> >> +					mult, div);
> >> +	if (!IS_ERR(clk))
> >> +		of_clk_add_provider(node, of_clk_src_simple_get, clk);
> >> +}
> >> +EXPORT_SYMBOL_GPL(of_fixed_factor_clk_setup);
> >> +CLK_OF_DECLARE(fixed_factor_clk, "fixed-factor-clock",
> >> +		of_fixed_factor_clk_setup);
> >> +#endif
> >> diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
> >> index 7f197d7..7ea501b 100644
> >> --- a/include/linux/clk-provider.h
> >> +++ b/include/linux/clk-provider.h
> >> @@ -325,6 +325,8 @@ struct clk *clk_register_fixed_factor(struct device *dev, const char *name,
> >>  		const char *parent_name, unsigned long flags,
> >>  		unsigned int mult, unsigned int div);
> >>  
> >> +void of_fixed_factor_clk_setup(struct device_node *node);
> >> +
> >>  /**
> >>   * clk_register - allocate a new clock, register it and return an opaque cookie
> >>   * @dev: device that is registering this clock
> >> -- 
> >> 1.7.9.5
> >>
> > 
> 
> 
> -- 
> Gregory Clement, Free Electrons
> Kernel, drivers, real-time and embedded Linux
> development, consulting, training and support.
> http://free-electrons.com

-- 
  Christian Ruppert              ,          <christian.ruppert at abilis.com>
                                /|
  Tel: +41/(0)22 816 19-42     //|                 3, Chemin du Pr?-Fleuri
                             _// | bilis Systems   CH-1228 Plan-les-Ouates


From michal.bachraty at streamunlimited.com  Fri Apr 12 07:43:13 2013
From: michal.bachraty at streamunlimited.com (Michal Bachraty)
Date: Fri, 12 Apr 2013 13:43:13 +0200
Subject: [PATCH v8] clk: add si5351 i2c common clock driver
In-Reply-To: <1365709350-8344-1-git-send-email-sebastian.hesselbarth@gmail.com>
References: <1365586810-6752-1-git-send-email-sebastian.hesselbarth@gmail.com>
 <1365709350-8344-1-git-send-email-sebastian.hesselbarth@gmail.com>
Message-ID: <97565825.iXrVtcy705@ganymedes>

On Thursday, April 11, 2013 21:42:29 Sebastian Hesselbarth wrote:
> This patch adds a common clock driver for Silicon Labs Si5351a/b/c
> i2c programmable clock generators. Currently, the driver does not
> support VXCO feature of si5351b. Passing platform_data or DT bindings
> selectively allows to overwrite stored Si5351 configuration which is
> very helpful for clock generators with empty eeprom configuration.
> Corresponding device tree binding documentation is also added.

Tested-by: Michal Bachraty <michal.bachraty at streamunlimited.com>

Many thanks,

Michal

> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
> Tested-by: Daniel Mack <zonque at gmail.com>
> Acked-by: Guenter Roeck <linux at roeck-us.net>
> ---
> Changes from v7:
> - readd clk powerup on clkout set_rate (Suggested by Michal Bachraty)
> 
> Changes from v6:
> - make invalid DT data parsing fatal (Suggested by Guenter Roeck)
> - add more variant checks and return errors
> - remove inline from _si5351_* functions
> - remove pll reset/clkout powerdown for gapless tuning
>   (Provided by Michal Backraty)
> 
> Changes from v5:
> - removed __clk_set_flags
> - remove CONFIG_OF dependency
> - introduce si5351_platform_data (non-DT untested)
> - parse DT into si5351_platform_data (tested)
> - minor cleanups
> 
> Changes from v4:
> - move from clk-private.h to clk-provider.h (Reported by Mike Turquette)
> - use __clk_set_flags() helper
> 
> Changes from v3:
> - add silabs prefix to custom DT properties (Reported by Lars-Peter Clausen)
> - use sizeof(*foo) instead of sizeof(struct bar) (Reported by Lars-Peter
> Clausen) - check return value of of_clk_add_provider (Reported by
> Lars-Peter Clausen) - clean up i2c client init (Reported by Lars-Peter
> Clausen)
> - silence successful probe (Suggested by Lars-Peter Clausen)
> - make CONFIG_CLK_SI5351 depend on CONFIG_OF
> 
> Changes from v2:
> - add curly brackets to if-else-statements (Reported by Daniel Mack)
> - fix div-by-zero for clk6/clk7 (Reported by Daniel Mack)
> - fix parameter address calculation for clk6/clk7
> 
> Changes from v1:
> - remove .is_enabled functions as they read from i2c
>   (Reported by Daniel Mack)
> - add CLK_SET_RATE_PARENT on clkout reparent if clkout uses
>   its own multisync
> 
> Cc: Grant Likely <grant.likely at secretlab.ca>
> Cc: Rob Herring <rob.herring at calxeda.com>
> Cc: Rob Landley <rob at landley.net>
> Cc: Mike Turquette <mturquette at linaro.org>
> Cc: Stephen Warren <swarren at nvidia.com>
> Cc: Thierry Reding <thierry.reding at avionic-design.de>
> Cc: Dom Cobley <popcornmix at gmail.com>
> Cc: Linus Walleij <linus.walleij at linaro.org>
> Cc: Arnd Bergmann <arnd at arndb.de>
> Cc: Andrew Morton <akpm at linux-foundation.org>
> Cc: Pawel Moll <pawel.moll at arm.com>
> Cc: Mark Brown <broonie at opensource.wolfsonmicro.com>
> Cc: Russell King - ARM Linux <linux at arm.linux.org.uk>
> Cc: Rabeeh Khoury <rabeeh at solid-run.com>
> Cc: Daniel Mack <zonque at gmail.com>
> Cc: Jean-Francois Moine <moinejf at free.fr>
> Cc: Lars-Peter Clausen <lars at metafoo.de>
> Cc: Guenter Roeck <linux at roeck-us.net>
> Cc: Michal Bachraty <michal.bachraty at streamunlimited.com>
> Cc: devicetree-discuss at lists.ozlabs.org
> Cc: linux-doc at vger.kernel.org
> Cc: linux-kernel at vger.kernel.org
> Cc: linux-arm-kernel at lists.infradead.org
> ---
>  .../devicetree/bindings/clock/silabs,si5351.txt    |  114 ++
>  .../devicetree/bindings/vendor-prefixes.txt        |    1 +
>  drivers/clk/Kconfig                                |    9 +
>  drivers/clk/Makefile                               |    1 +
>  drivers/clk/clk-si5351.c                           | 1510
> ++++++++++++++++++++ drivers/clk/clk-si5351.h                           | 
> 155 ++
>  include/linux/platform_data/si5351.h               |  114 ++
>  7 files changed, 1904 insertions(+)
>  create mode 100644
> Documentation/devicetree/bindings/clock/silabs,si5351.txt create mode
> 100644 drivers/clk/clk-si5351.c
>  create mode 100644 drivers/clk/clk-si5351.h
>  create mode 100644 include/linux/platform_data/si5351.h
> 
> diff --git a/Documentation/devicetree/bindings/clock/silabs,si5351.txt
> b/Documentation/devicetree/bindings/clock/silabs,si5351.txt new file mode
> 100644
> index 0000000..cc37465
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/silabs,si5351.txt
> @@ -0,0 +1,114 @@
> +Binding for Silicon Labs Si5351a/b/c programmable i2c clock generator.
> +
> +Reference
> +[1] Si5351A/B/C Data Sheet
> +    http://www.silabs.com/Support%20Documents/TechnicalDocs/Si5351.pdf
> +
> +The Si5351a/b/c are programmable i2c clock generators with upto 8 output
> +clocks. Si5351a also has a reduced pin-count package (MSOP10) where only
> +3 output clocks are accessible. The internal structure of the clock
> +generators can be found in [1].
> +
> +==I2C device node==
> +
> +Required properties:
> +- compatible: shall be one of "silabs,si5351{a,a-msop,b,c}".
> +- reg: i2c device address, shall be 0x60 or 0x61.
> +- #clock-cells: from common clock binding; shall be set to 1.
> +- clocks: from common clock binding; list of parent clock
> +  handles, shall be xtal reference clock or xtal and clkin for
> +  si5351c only.
> +- #address-cells: shall be set to 1.
> +- #size-cells: shall be set to 0.
> +
> +Optional properties:
> +- silabs,pll-source: pair of (number, source) for each pll. Allows
> +  to overwrite clock source of pll A (number=0) or B (number=1).
> +
> +==Child nodes==
> +
> +Each of the clock outputs can be overwritten individually by
> +using a child node to the I2C device node. If a child node for a clock
> +output is not set, the eeprom configuration is not overwritten.
> +
> +Required child node properties:
> +- reg: number of clock output.
> +
> +Optional child node properties:
> +- silabs,clock-source: source clock of the output divider stage N, shall be
> +  0 = multisynth N
> +  1 = multisynth 0 for output clocks 0-3, else multisynth4
> +  2 = xtal
> +  3 = clkin (si5351c only)
> +- silabs,drive-strength: output drive strength in mA, shall be one of
> {2,4,6,8}. +- silabs,multisynth-source: source pll A(0) or B(1) of
> corresponding multisynth +  divider.
> +- silabs,pll-master: boolean, multisynth can change pll frequency.
> +
> +==Example==
> +
> +/* 25MHz reference crystal */
> +ref25: ref25M {
> +	compatible = "fixed-clock";
> +	#clock-cells = <0>;
> +	clock-frequency = <25000000>;
> +};
> +
> +i2c-master-node {
> +
> +	/* Si5351a msop10 i2c clock generator */
> +	si5351a: clock-generator at 60 {
> +		compatible = "silabs,si5351a-msop";
> +		reg = <0x60>;
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +		#clock-cells = <1>;
> +
> +		/* connect xtal input to 25MHz reference */
> +		clocks = <&ref25>;
> +
> +		/* connect xtal input as source of pll0 and pll1 */
> +		silabs,pll-source = <0 0>, <1 0>;
> +
> +		/*
> +		 * overwrite clkout0 configuration with:
> +		 * - 8mA output drive strength
> +		 * - pll0 as clock source of multisynth0
> +		 * - multisynth0 as clock source of output divider
> +		 * - multisynth0 can change pll0
> +		 * - set initial clock frequency of 74.25MHz
> +		 */
> +		clkout0 {
> +			reg = <0>;
> +			silabs,drive-strength = <8>;
> +			silabs,multisynth-source = <0>;
> +			silabs,clock-source = <0>;
> +			silabs,pll-master;
> +			clock-frequency = <74250000>;
> +		};
> +
> +		/*
> +		 * overwrite clkout1 configuration with:
> +		 * - 4mA output drive strength
> +		 * - pll1 as clock source of multisynth1
> +		 * - multisynth1 as clock source of output divider
> +		 * - multisynth1 can change pll1
> +		 */
> +		clkout1 {
> +			reg = <1>;
> +			silabs,drive-strength = <4>;
> +			silabs,multisynth-source = <1>;
> +			silabs,clock-source = <0>;
> +			pll-master;
> +		};
> +
> +		/*
> +		 * overwrite clkout2 configuration with:
> +		 * - xtal as clock source of output divider
> +		 */
> +		clkout2 {
> +			reg = <2>;
> +			silabs,clock-source = <2>;
> +		};
> +	};
> +};
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
> b/Documentation/devicetree/bindings/vendor-prefixes.txt index
> 19e1ef7..ca60849 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> @@ -48,6 +48,7 @@ samsung	Samsung Semiconductor
>  sbs	Smart Battery System
>  schindler	Schindler
>  sil	Silicon Image
> +silabs	Silicon Laboratories
>  simtek
>  sirf	SiRF Technology, Inc.
>  snps 	Synopsys, Inc.
> diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
> index a47e6ee..5039e41 100644
> --- a/drivers/clk/Kconfig
> +++ b/drivers/clk/Kconfig
> @@ -55,6 +55,15 @@ config COMMON_CLK_MAX77686
>  	---help---
>  	  This driver supports Maxim 77686 crystal oscillator clock.
> 
> +config COMMON_CLK_SI5351
> +	tristate "Clock driver for SiLabs 5351A/B/C"
> +	depends on I2C
> +	select REGMAP_I2C
> +	select RATIONAL
> +	---help---
> +	  This driver supports Silicon Labs 5351A/B/C programmable clock
> +	  generators.
> +
>  config CLK_TWL6040
>  	tristate "External McPDM functional clock from twl6040"
>  	depends on TWL6040_CORE
> diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
> index 300d477..92ca698 100644
> --- a/drivers/clk/Makefile
> +++ b/drivers/clk/Makefile
> @@ -33,4 +33,5 @@ obj-$(CONFIG_X86)		+= x86/
>  # Chip specific
>  obj-$(CONFIG_COMMON_CLK_WM831X) += clk-wm831x.o
>  obj-$(CONFIG_COMMON_CLK_MAX77686) += clk-max77686.o
> +obj-$(CONFIG_COMMON_CLK_SI5351) += clk-si5351.o
>  obj-$(CONFIG_CLK_TWL6040)	+= clk-twl6040.o
> diff --git a/drivers/clk/clk-si5351.c b/drivers/clk/clk-si5351.c
> new file mode 100644
> index 0000000..8927284
> --- /dev/null
> +++ b/drivers/clk/clk-si5351.c
> @@ -0,0 +1,1510 @@
> +/*
> + * clk-si5351.c: Silicon Laboratories Si5351A/B/C I2C Clock Generator
> + *
> + * Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
> + * Rabeeh Khoury <rabeeh at solid-run.com>
> + *
> + * References:
> + * [1] "Si5351A/B/C Data Sheet"
> + *     http://www.silabs.com/Support%20Documents/TechnicalDocs/Si5351.pdf
> + * [2] "Manually Generating an Si5351 Register Map"
> + *     http://www.silabs.com/Support%20Documents/TechnicalDocs/AN619.pdf
> + *
> + * 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.
> + */
> +
> +#include <linux/module.h>
> +#include <linux/kernel.h>
> +#include <linux/clkdev.h>
> +#include <linux/clk-provider.h>
> +#include <linux/delay.h>
> +#include <linux/err.h>
> +#include <linux/errno.h>
> +#include <linux/rational.h>
> +#include <linux/i2c.h>
> +#include <linux/of_platform.h>
> +#include <linux/platform_data/si5351.h>
> +#include <linux/regmap.h>
> +#include <linux/slab.h>
> +#include <linux/string.h>
> +#include <asm/div64.h>
> +
> +#include "clk-si5351.h"
> +
> +struct si5351_driver_data;
> +
> +struct si5351_parameters {
> +	unsigned long	p1;
> +	unsigned long	p2;
> +	unsigned long	p3;
> +	int		valid;
> +};
> +
> +struct si5351_hw_data {
> +	struct clk_hw			hw;
> +	struct si5351_driver_data	*drvdata;
> +	struct si5351_parameters	params;
> +	unsigned char			num;
> +};
> +
> +struct si5351_driver_data {
> +	enum si5351_variant	variant;
> +	struct i2c_client	*client;
> +	struct regmap		*regmap;
> +	struct clk_onecell_data onecell;
> +
> +	struct clk		*pxtal;
> +	const char		*pxtal_name;
> +	struct clk_hw		xtal;
> +	struct clk		*pclkin;
> +	const char		*pclkin_name;
> +	struct clk_hw		clkin;
> +
> +	struct si5351_hw_data	pll[2];
> +	struct si5351_hw_data	*msynth;
> +	struct si5351_hw_data	*clkout;
> +};
> +
> +static const char const *si5351_input_names[] = {
> +	"xtal", "clkin"
> +};
> +static const char const *si5351_pll_names[] = {
> +	"plla", "pllb", "vxco"
> +};
> +static const char const *si5351_msynth_names[] = {
> +	"ms0", "ms1", "ms2", "ms3", "ms4", "ms5", "ms6", "ms7"
> +};
> +static const char const *si5351_clkout_names[] = {
> +	"clk0", "clk1", "clk2", "clk3", "clk4", "clk5", "clk6", "clk7"
> +};
> +
> +/*
> + * Si5351 i2c regmap
> + */
> +static inline u8 si5351_reg_read(struct si5351_driver_data *drvdata, u8
> reg) +{
> +	u32 val;
> +	int ret;
> +
> +	ret = regmap_read(drvdata->regmap, reg, &val);
> +	if (ret) {
> +		dev_err(&drvdata->client->dev,
> +			"unable to read from reg%02x\n", reg);
> +		return 0;
> +	}
> +
> +	return (u8)val;
> +}
> +
> +static inline int si5351_bulk_read(struct si5351_driver_data *drvdata,
> +				   u8 reg, u8 count, u8 *buf)
> +{
> +	return regmap_bulk_read(drvdata->regmap, reg, buf, count);
> +}
> +
> +static inline int si5351_reg_write(struct si5351_driver_data *drvdata,
> +				   u8 reg, u8 val)
> +{
> +	return regmap_write(drvdata->regmap, reg, val);
> +}
> +
> +static inline int si5351_bulk_write(struct si5351_driver_data *drvdata,
> +				    u8 reg, u8 count, const u8 *buf)
> +{
> +	return regmap_raw_write(drvdata->regmap, reg, buf, count);
> +}
> +
> +static inline int si5351_set_bits(struct si5351_driver_data *drvdata,
> +				  u8 reg, u8 mask, u8 val)
> +{
> +	return regmap_update_bits(drvdata->regmap, reg, mask, val);
> +}
> +
> +static inline u8 si5351_msynth_params_address(int num)
> +{
> +	if (num > 5)
> +		return SI5351_CLK6_PARAMETERS + (num - 6);
> +	return SI5351_CLK0_PARAMETERS + (SI5351_PARAMETERS_LENGTH * num);
> +}
> +
> +static void si5351_read_parameters(struct si5351_driver_data *drvdata,
> +				   u8 reg, struct si5351_parameters *params)
> +{
> +	u8 buf[SI5351_PARAMETERS_LENGTH];
> +
> +	switch (reg) {
> +	case SI5351_CLK6_PARAMETERS:
> +	case SI5351_CLK7_PARAMETERS:
> +		buf[0] = si5351_reg_read(drvdata, reg);
> +		params->p1 = buf[0];
> +		params->p2 = 0;
> +		params->p3 = 1;
> +		break;
> +	default:
> +		si5351_bulk_read(drvdata, reg, SI5351_PARAMETERS_LENGTH, buf);
> +		params->p1 = ((buf[2] & 0x03) << 16) | (buf[3] << 8) | buf[4];
> +		params->p2 = ((buf[5] & 0x0f) << 16) | (buf[6] << 8) | buf[7];
> +		params->p3 = ((buf[5] & 0xf0) << 12) | (buf[0] << 8) | buf[1];
> +	}
> +	params->valid = 1;
> +}
> +
> +static void si5351_write_parameters(struct si5351_driver_data *drvdata,
> +				    u8 reg, struct si5351_parameters *params)
> +{
> +	u8 buf[SI5351_PARAMETERS_LENGTH];
> +
> +	switch (reg) {
> +	case SI5351_CLK6_PARAMETERS:
> +	case SI5351_CLK7_PARAMETERS:
> +		buf[0] = params->p1 & 0xff;
> +		si5351_reg_write(drvdata, reg, buf[0]);
> +		break;
> +	default:
> +		buf[0] = ((params->p3 & 0x0ff00) >> 8) & 0xff;
> +		buf[1] = params->p3 & 0xff;
> +		/* save rdiv and divby4 */
> +		buf[2] = si5351_reg_read(drvdata, reg + 2) & ~0x03;
> +		buf[2] |= ((params->p1 & 0x30000) >> 16) & 0x03;
> +		buf[3] = ((params->p1 & 0x0ff00) >> 8) & 0xff;
> +		buf[4] = params->p1 & 0xff;
> +		buf[5] = ((params->p3 & 0xf0000) >> 12) |
> +			((params->p2 & 0xf0000) >> 16);
> +		buf[6] = ((params->p2 & 0x0ff00) >> 8) & 0xff;
> +		buf[7] = params->p2 & 0xff;
> +		si5351_bulk_write(drvdata, reg, SI5351_PARAMETERS_LENGTH, buf);
> +	}
> +}
> +
> +static bool si5351_regmap_is_volatile(struct device *dev, unsigned int reg)
> +{
> +	switch (reg) {
> +	case SI5351_DEVICE_STATUS:
> +	case SI5351_INTERRUPT_STATUS:
> +	case SI5351_PLL_RESET:
> +		return true;
> +	}
> +	return false;
> +}
> +
> +static bool si5351_regmap_is_writeable(struct device *dev, unsigned int
> reg) +{
> +	/* reserved registers */
> +	if (reg >= 4 && reg <= 8)
> +		return false;
> +	if (reg >= 10 && reg <= 14)
> +		return false;
> +	if (reg >= 173 && reg <= 176)
> +		return false;
> +	if (reg >= 178 && reg <= 182)
> +		return false;
> +	/* read-only */
> +	if (reg == SI5351_DEVICE_STATUS)
> +		return false;
> +	return true;
> +}
> +
> +static struct regmap_config si5351_regmap_config = {
> +	.reg_bits = 8,
> +	.val_bits = 8,
> +	.cache_type = REGCACHE_RBTREE,
> +	.max_register = 187,
> +	.writeable_reg = si5351_regmap_is_writeable,
> +	.volatile_reg = si5351_regmap_is_volatile,
> +};
> +
> +/*
> + * Si5351 xtal clock input
> + */
> +static int si5351_xtal_prepare(struct clk_hw *hw)
> +{
> +	struct si5351_driver_data *drvdata =
> +		container_of(hw, struct si5351_driver_data, xtal);
> +	si5351_set_bits(drvdata, SI5351_FANOUT_ENABLE,
> +			SI5351_XTAL_ENABLE, SI5351_XTAL_ENABLE);
> +	return 0;
> +}
> +
> +static void si5351_xtal_unprepare(struct clk_hw *hw)
> +{
> +	struct si5351_driver_data *drvdata =
> +		container_of(hw, struct si5351_driver_data, xtal);
> +	si5351_set_bits(drvdata, SI5351_FANOUT_ENABLE,
> +			SI5351_XTAL_ENABLE, 0);
> +}
> +
> +static const struct clk_ops si5351_xtal_ops = {
> +	.prepare = si5351_xtal_prepare,
> +	.unprepare = si5351_xtal_unprepare,
> +};
> +
> +/*
> + * Si5351 clkin clock input (Si5351C only)
> + */
> +static int si5351_clkin_prepare(struct clk_hw *hw)
> +{
> +	struct si5351_driver_data *drvdata =
> +		container_of(hw, struct si5351_driver_data, clkin);
> +	si5351_set_bits(drvdata, SI5351_FANOUT_ENABLE,
> +			SI5351_CLKIN_ENABLE, SI5351_CLKIN_ENABLE);
> +	return 0;
> +}
> +
> +static void si5351_clkin_unprepare(struct clk_hw *hw)
> +{
> +	struct si5351_driver_data *drvdata =
> +		container_of(hw, struct si5351_driver_data, clkin);
> +	si5351_set_bits(drvdata, SI5351_FANOUT_ENABLE,
> +			SI5351_CLKIN_ENABLE, 0);
> +}
> +
> +/*
> + * CMOS clock source constraints:
> + * The input frequency range of the PLL is 10Mhz to 40MHz.
> + * If CLKIN is >40MHz, the input divider must be used.
> + */
> +static unsigned long si5351_clkin_recalc_rate(struct clk_hw *hw,
> +					      unsigned long parent_rate)
> +{
> +	struct si5351_driver_data *drvdata =
> +		container_of(hw, struct si5351_driver_data, clkin);
> +	unsigned long rate;
> +	unsigned char idiv;
> +
> +	rate = parent_rate;
> +	if (parent_rate > 160000000) {
> +		idiv = SI5351_CLKIN_DIV_8;
> +		rate /= 8;
> +	} else if (parent_rate > 80000000) {
> +		idiv = SI5351_CLKIN_DIV_4;
> +		rate /= 4;
> +	} else if (parent_rate > 40000000) {
> +		idiv = SI5351_CLKIN_DIV_2;
> +		rate /= 2;
> +	} else {
> +		idiv = SI5351_CLKIN_DIV_1;
> +	}
> +
> +	si5351_set_bits(drvdata, SI5351_PLL_INPUT_SOURCE,
> +			SI5351_CLKIN_DIV_MASK, idiv);
> +
> +	dev_dbg(&drvdata->client->dev, "%s - clkin div = %d, rate = %lu\n",
> +		__func__, (1 << (idiv >> 6)), rate);
> +
> +	return rate;
> +}
> +
> +static const struct clk_ops si5351_clkin_ops = {
> +	.prepare = si5351_clkin_prepare,
> +	.unprepare = si5351_clkin_unprepare,
> +	.recalc_rate = si5351_clkin_recalc_rate,
> +};
> +
> +/*
> + * Si5351 vxco clock input (Si5351B only)
> + */
> +
> +static int si5351_vxco_prepare(struct clk_hw *hw)
> +{
> +	struct si5351_hw_data *hwdata =
> +		container_of(hw, struct si5351_hw_data, hw);
> +
> +	dev_warn(&hwdata->drvdata->client->dev, "VXCO currently unsupported\n");
> +
> +	return 0;
> +}
> +
> +static void si5351_vxco_unprepare(struct clk_hw *hw)
> +{
> +}
> +
> +static unsigned long si5351_vxco_recalc_rate(struct clk_hw *hw,
> +					     unsigned long parent_rate)
> +{
> +	return 0;
> +}
> +
> +static int si5351_vxco_set_rate(struct clk_hw *hw, unsigned long rate,
> +				unsigned long parent)
> +{
> +	return 0;
> +}
> +
> +static const struct clk_ops si5351_vxco_ops = {
> +	.prepare = si5351_vxco_prepare,
> +	.unprepare = si5351_vxco_unprepare,
> +	.recalc_rate = si5351_vxco_recalc_rate,
> +	.set_rate = si5351_vxco_set_rate,
> +};
> +
> +/*
> + * Si5351 pll a/b
> + *
> + * Feedback Multisynth Divider Equations [2]
> + *
> + * fVCO = fIN * (a + b/c)
> + *
> + * with 15 + 0/1048575 <= (a + b/c) <= 90 + 0/1048575 and
> + * fIN = fXTAL or fIN = fCLKIN/CLKIN_DIV
> + *
> + * Feedback Multisynth Register Equations
> + *
> + * (1) MSNx_P1[17:0] = 128 * a + floor(128 * b/c) - 512
> + * (2) MSNx_P2[19:0] = 128 * b - c * floor(128 * b/c) = (128*b) mod c
> + * (3) MSNx_P3[19:0] = c
> + *
> + * Transposing (2) yields: (4) floor(128 * b/c) = (128 * b / MSNx_P2)/c
> + *
> + * Using (4) on (1) yields:
> + * MSNx_P1 = 128 * a + (128 * b/MSNx_P2)/c - 512
> + * MSNx_P1 + 512 + MSNx_P2/c = 128 * a + 128 * b/c
> + *
> + * a + b/c = (MSNx_P1 + MSNx_P2/MSNx_P3 + 512)/128
> + *         = (MSNx_P1*MSNx_P3 + MSNx_P2 + 512*MSNx_P3)/(128*MSNx_P3)
> + *
> + */
> +static int _si5351_pll_reparent(struct si5351_driver_data *drvdata,
> +				int num, enum si5351_pll_src parent)
> +{
> +	u8 mask = (num == 0) ? SI5351_PLLA_SOURCE : SI5351_PLLB_SOURCE;
> +
> +	if (parent == SI5351_PLL_SRC_DEFAULT)
> +		return 0;
> +
> +	if (num > 2)
> +		return -EINVAL;
> +
> +	if (drvdata->variant != SI5351_VARIANT_C &&
> +	    parent != SI5351_PLL_SRC_XTAL)
> +		return -EINVAL;
> +
> +	si5351_set_bits(drvdata, SI5351_PLL_INPUT_SOURCE, mask,
> +			(parent == SI5351_PLL_SRC_XTAL) ? 0 : mask);
> +	return 0;
> +}
> +
> +static unsigned char si5351_pll_get_parent(struct clk_hw *hw)
> +{
> +	struct si5351_hw_data *hwdata =
> +		container_of(hw, struct si5351_hw_data, hw);
> +	u8 mask = (hwdata->num == 0) ? SI5351_PLLA_SOURCE : SI5351_PLLB_SOURCE;
> +	u8 val;
> +
> +	val = si5351_reg_read(hwdata->drvdata, SI5351_PLL_INPUT_SOURCE);
> +
> +	return (val & mask) ? 1 : 0;
> +}
> +
> +static int si5351_pll_set_parent(struct clk_hw *hw, u8 index)
> +{
> +	struct si5351_hw_data *hwdata =
> +		container_of(hw, struct si5351_hw_data, hw);
> +
> +	if (hwdata->drvdata->variant != SI5351_VARIANT_C &&
> +	    index > 0)
> +		return -EPERM;
> +
> +	if (index > 1)
> +		return -EINVAL;
> +
> +	return _si5351_pll_reparent(hwdata->drvdata, hwdata->num,
> +			     (index == 0) ? SI5351_PLL_SRC_XTAL :
> +			     SI5351_PLL_SRC_CLKIN);
> +}
> +
> +static unsigned long si5351_pll_recalc_rate(struct clk_hw *hw,
> +					    unsigned long parent_rate)
> +{
> +	struct si5351_hw_data *hwdata =
> +		container_of(hw, struct si5351_hw_data, hw);
> +	u8 reg = (hwdata->num == 0) ? SI5351_PLLA_PARAMETERS :
> +		SI5351_PLLB_PARAMETERS;
> +	unsigned long long rate;
> +
> +	if (!hwdata->params.valid)
> +		si5351_read_parameters(hwdata->drvdata, reg, &hwdata->params);
> +
> +	if (hwdata->params.p3 == 0)
> +		return parent_rate;
> +
> +	/* fVCO = fIN * (P1*P3 + 512*P3 + P2)/(128*P3) */
> +	rate  = hwdata->params.p1 * hwdata->params.p3;
> +	rate += 512 * hwdata->params.p3;
> +	rate += hwdata->params.p2;
> +	rate *= parent_rate;
> +	do_div(rate, 128 * hwdata->params.p3);
> +
> +	dev_dbg(&hwdata->drvdata->client->dev,
> +		"%s - %s: p1 = %lu, p2 = %lu, p3 = %lu, parent_rate = %lu, rate = 
%lu\n",
> +		__func__, __clk_get_name(hwdata->hw.clk),
> +		hwdata->params.p1, hwdata->params.p2, hwdata->params.p3,
> +		parent_rate, (unsigned long)rate);
> +
> +	return (unsigned long)rate;
> +}
> +
> +static long si5351_pll_round_rate(struct clk_hw *hw, unsigned long rate,
> +				  unsigned long *parent_rate)
> +{
> +	struct si5351_hw_data *hwdata =
> +		container_of(hw, struct si5351_hw_data, hw);
> +	unsigned long rfrac, denom, a, b, c;
> +	unsigned long long lltmp;
> +
> +	if (rate < SI5351_PLL_VCO_MIN)
> +		rate = SI5351_PLL_VCO_MIN;
> +	if (rate > SI5351_PLL_VCO_MAX)
> +		rate = SI5351_PLL_VCO_MAX;
> +
> +	/* determine integer part of feedback equation */
> +	a = rate / *parent_rate;
> +
> +	if (a < SI5351_PLL_A_MIN)
> +		rate = *parent_rate * SI5351_PLL_A_MIN;
> +	if (a > SI5351_PLL_A_MAX)
> +		rate = *parent_rate * SI5351_PLL_A_MAX;
> +
> +	/* find best approximation for b/c = fVCO mod fIN */
> +	denom = 1000 * 1000;
> +	lltmp = rate % (*parent_rate);
> +	lltmp *= denom;
> +	do_div(lltmp, *parent_rate);
> +	rfrac = (unsigned long)lltmp;
> +
> +	b = 0;
> +	c = 1;
> +	if (rfrac)
> +		rational_best_approximation(rfrac, denom,
> +				    SI5351_PLL_B_MAX, SI5351_PLL_C_MAX, &b, &c);
> +
> +	/* calculate parameters */
> +	hwdata->params.p3  = c;
> +	hwdata->params.p2  = (128 * b) % c;
> +	hwdata->params.p1  = 128 * a;
> +	hwdata->params.p1 += (128 * b / c);
> +	hwdata->params.p1 -= 512;
> +
> +	/* recalculate rate by fIN * (a + b/c) */
> +	lltmp  = *parent_rate;
> +	lltmp *= b;
> +	do_div(lltmp, c);
> +
> +	rate  = (unsigned long)lltmp;
> +	rate += *parent_rate * a;
> +
> +	dev_dbg(&hwdata->drvdata->client->dev,
> +		"%s - %s: a = %lu, b = %lu, c = %lu, parent_rate = %lu, rate = %lu\n",
> +		__func__, __clk_get_name(hwdata->hw.clk), a, b, c,
> +		*parent_rate, rate);
> +
> +	return rate;
> +}
> +
> +static int si5351_pll_set_rate(struct clk_hw *hw, unsigned long rate,
> +			       unsigned long parent_rate)
> +{
> +	struct si5351_hw_data *hwdata =
> +		container_of(hw, struct si5351_hw_data, hw);
> +	u8 reg = (hwdata->num == 0) ? SI5351_PLLA_PARAMETERS :
> +		SI5351_PLLB_PARAMETERS;
> +
> +	/* write multisynth parameters */
> +	si5351_write_parameters(hwdata->drvdata, reg, &hwdata->params);
> +
> +	/* plla/pllb ctrl is in clk6/clk7 ctrl registers */
> +	si5351_set_bits(hwdata->drvdata, SI5351_CLK6_CTRL + hwdata->num,
> +		SI5351_CLK_INTEGER_MODE,
> +		(hwdata->params.p2 == 0) ? SI5351_CLK_INTEGER_MODE : 0);
> +
> +	dev_dbg(&hwdata->drvdata->client->dev,
> +		"%s - %s: p1 = %lu, p2 = %lu, p3 = %lu, parent_rate = %lu, rate = 
%lu\n",
> +		__func__, __clk_get_name(hwdata->hw.clk),
> +		hwdata->params.p1, hwdata->params.p2, hwdata->params.p3,
> +		parent_rate, rate);
> +
> +	return 0;
> +}
> +
> +static const struct clk_ops si5351_pll_ops = {
> +	.set_parent = si5351_pll_set_parent,
> +	.get_parent = si5351_pll_get_parent,
> +	.recalc_rate = si5351_pll_recalc_rate,
> +	.round_rate = si5351_pll_round_rate,
> +	.set_rate = si5351_pll_set_rate,
> +};
> +
> +/*
> + * Si5351 multisync divider
> + *
> + * for fOUT <= 150 MHz:
> + *
> + * fOUT = (fIN * (a + b/c)) / CLKOUTDIV
> + *
> + * with 6 + 0/1048575 <= (a + b/c) <= 1800 + 0/1048575 and
> + * fIN = fVCO0, fVCO1
> + *
> + * Output Clock Multisynth Register Equations
> + *
> + * MSx_P1[17:0] = 128 * a + floor(128 * b/c) - 512
> + * MSx_P2[19:0] = 128 * b - c * floor(128 * b/c) = (128*b) mod c
> + * MSx_P3[19:0] = c
> + *
> + * MS[6,7] are integer (P1) divide only, P2 = 0, P3 = 0
> + *
> + * for 150MHz < fOUT <= 160MHz:
> + *
> + * MSx_P1 = 0, MSx_P2 = 0, MSx_P3 = 1, MSx_INT = 1, MSx_DIVBY4 = 11b
> + */
> +static int _si5351_msynth_reparent(struct si5351_driver_data *drvdata,
> +				   int num, enum si5351_multisynth_src parent)
> +{
> +	if (parent == SI5351_MULTISYNTH_SRC_DEFAULT)
> +		return 0;
> +
> +	if (num > 8)
> +		return -EINVAL;
> +
> +	si5351_set_bits(drvdata, SI5351_CLK0_CTRL + num, SI5351_CLK_PLL_SELECT,
> +			(parent == SI5351_MULTISYNTH_SRC_VCO0) ? 0 :
> +			SI5351_CLK_PLL_SELECT);
> +	return 0;
> +}
> +
> +static unsigned char si5351_msynth_get_parent(struct clk_hw *hw)
> +{
> +	struct si5351_hw_data *hwdata =
> +		container_of(hw, struct si5351_hw_data, hw);
> +	u8 val;
> +
> +	val = si5351_reg_read(hwdata->drvdata, SI5351_CLK0_CTRL + hwdata->num);
> +
> +	return (val & SI5351_CLK_PLL_SELECT) ? 1 : 0;
> +}
> +
> +static int si5351_msynth_set_parent(struct clk_hw *hw, u8 index)
> +{
> +	struct si5351_hw_data *hwdata =
> +		container_of(hw, struct si5351_hw_data, hw);
> +
> +	return _si5351_msynth_reparent(hwdata->drvdata, hwdata->num,
> +			       (index == 0) ? SI5351_MULTISYNTH_SRC_VCO0 :
> +			       SI5351_MULTISYNTH_SRC_VCO1);
> +}
> +
> +static unsigned long si5351_msynth_recalc_rate(struct clk_hw *hw,
> +					       unsigned long parent_rate)
> +{
> +	struct si5351_hw_data *hwdata =
> +		container_of(hw, struct si5351_hw_data, hw);
> +	u8 reg = si5351_msynth_params_address(hwdata->num);
> +	unsigned long long rate;
> +	unsigned long m;
> +
> +	if (!hwdata->params.valid)
> +		si5351_read_parameters(hwdata->drvdata, reg, &hwdata->params);
> +
> +	if (hwdata->params.p3 == 0)
> +		return parent_rate;
> +
> +	/*
> +	 * multisync0-5: fOUT = (128 * P3 * fIN) / (P1*P3 + P2 + 512*P3)
> +	 * multisync6-7: fOUT = fIN / P1
> +	 */
> +	rate = parent_rate;
> +	if (hwdata->num > 5) {
> +		m = hwdata->params.p1;
> +	} else if ((si5351_reg_read(hwdata->drvdata, reg + 2) &
> +		    SI5351_OUTPUT_CLK_DIVBY4) == SI5351_OUTPUT_CLK_DIVBY4) {
> +		m = 4;
> +	} else {
> +		rate *= 128 * hwdata->params.p3;
> +		m = hwdata->params.p1 * hwdata->params.p3;
> +		m += hwdata->params.p2;
> +		m += 512 * hwdata->params.p3;
> +	}
> +
> +	if (m == 0)
> +		return 0;
> +	do_div(rate, m);
> +
> +	dev_dbg(&hwdata->drvdata->client->dev,
> +		"%s - %s: p1 = %lu, p2 = %lu, p3 = %lu, m = %lu, parent_rate = %lu, 
rate
> = %lu\n", +		__func__, __clk_get_name(hwdata->hw.clk),
> +		hwdata->params.p1, hwdata->params.p2, hwdata->params.p3,
> +		m, parent_rate, (unsigned long)rate);
> +
> +	return (unsigned long)rate;
> +}
> +
> +static long si5351_msynth_round_rate(struct clk_hw *hw, unsigned long rate,
> +				     unsigned long *parent_rate)
> +{
> +	struct si5351_hw_data *hwdata =
> +		container_of(hw, struct si5351_hw_data, hw);
> +	unsigned long long lltmp;
> +	unsigned long a, b, c;
> +	int divby4;
> +
> +	/* multisync6-7 can only handle freqencies < 150MHz */
> +	if (hwdata->num >= 6 && rate > SI5351_MULTISYNTH67_MAX_FREQ)
> +		rate = SI5351_MULTISYNTH67_MAX_FREQ;
> +
> +	/* multisync frequency is 1MHz .. 160MHz */
> +	if (rate > SI5351_MULTISYNTH_MAX_FREQ)
> +		rate = SI5351_MULTISYNTH_MAX_FREQ;
> +	if (rate < SI5351_MULTISYNTH_MIN_FREQ)
> +		rate = SI5351_MULTISYNTH_MIN_FREQ;
> +
> +	divby4 = 0;
> +	if (rate > SI5351_MULTISYNTH_DIVBY4_FREQ)
> +		divby4 = 1;
> +
> +	/* multisync can set pll */
> +	if (__clk_get_flags(hwdata->hw.clk) & CLK_SET_RATE_PARENT) {
> +		/*
> +		 * find largest integer divider for max
> +		 * vco frequency and given target rate
> +		 */
> +		if (divby4 == 0) {
> +			lltmp = SI5351_PLL_VCO_MAX;
> +			do_div(lltmp, rate);
> +			a = (unsigned long)lltmp;
> +		} else
> +			a = 4;
> +
> +		b = 0;
> +		c = 1;
> +
> +		*parent_rate = a * rate;
> +	} else {
> +		unsigned long rfrac, denom;
> +
> +		/* disable divby4 */
> +		if (divby4) {
> +			rate = SI5351_MULTISYNTH_DIVBY4_FREQ;
> +			divby4 = 0;
> +		}
> +
> +		/* determine integer part of divider equation */
> +		a = *parent_rate / rate;
> +		if (a < SI5351_MULTISYNTH_A_MIN)
> +			a = SI5351_MULTISYNTH_A_MIN;
> +		if (hwdata->num >= 6 && a > SI5351_MULTISYNTH67_A_MAX)
> +			a = SI5351_MULTISYNTH67_A_MAX;
> +		else if (a > SI5351_MULTISYNTH_A_MAX)
> +			a = SI5351_MULTISYNTH_A_MAX;
> +
> +		/* find best approximation for b/c = fVCO mod fOUT */
> +		denom = 1000 * 1000;
> +		lltmp = (*parent_rate) % rate;
> +		lltmp *= denom;
> +		do_div(lltmp, rate);
> +		rfrac = (unsigned long)lltmp;
> +
> +		b = 0;
> +		c = 1;
> +		if (rfrac)
> +			rational_best_approximation(rfrac, denom,
> +			    SI5351_MULTISYNTH_B_MAX, SI5351_MULTISYNTH_C_MAX,
> +			    &b, &c);
> +	}
> +
> +	/* recalculate rate by fOUT = fIN / (a + b/c) */
> +	lltmp  = *parent_rate;
> +	lltmp *= c;
> +	do_div(lltmp, a * c + b);
> +	rate  = (unsigned long)lltmp;
> +
> +	/* calculate parameters */
> +	if (divby4) {
> +		hwdata->params.p3 = 1;
> +		hwdata->params.p2 = 0;
> +		hwdata->params.p1 = 0;
> +	} else {
> +		hwdata->params.p3  = c;
> +		hwdata->params.p2  = (128 * b) % c;
> +		hwdata->params.p1  = 128 * a;
> +		hwdata->params.p1 += (128 * b / c);
> +		hwdata->params.p1 -= 512;
> +	}
> +
> +	dev_dbg(&hwdata->drvdata->client->dev,
> +		"%s - %s: a = %lu, b = %lu, c = %lu, divby4 = %d, parent_rate = %lu, 
rate
> = %lu\n", +		__func__, __clk_get_name(hwdata->hw.clk), a, b, c, divby4,
> +		*parent_rate, rate);
> +
> +	return rate;
> +}
> +
> +static int si5351_msynth_set_rate(struct clk_hw *hw, unsigned long rate,
> +				  unsigned long parent_rate)
> +{
> +	struct si5351_hw_data *hwdata =
> +		container_of(hw, struct si5351_hw_data, hw);
> +	u8 reg = si5351_msynth_params_address(hwdata->num);
> +	int divby4 = 0;
> +
> +	/* write multisynth parameters */
> +	si5351_write_parameters(hwdata->drvdata, reg, &hwdata->params);
> +
> +	if (rate > SI5351_MULTISYNTH_DIVBY4_FREQ)
> +		divby4 = 1;
> +
> +	/* enable/disable integer mode and divby4 on multisynth0-5 */
> +	if (hwdata->num < 6) {
> +		si5351_set_bits(hwdata->drvdata, reg + 2,
> +				SI5351_OUTPUT_CLK_DIVBY4,
> +				(divby4) ? SI5351_OUTPUT_CLK_DIVBY4 : 0);
> +		si5351_set_bits(hwdata->drvdata, SI5351_CLK0_CTRL + hwdata->num,
> +			SI5351_CLK_INTEGER_MODE,
> +			(hwdata->params.p2 == 0) ? SI5351_CLK_INTEGER_MODE : 0);
> +	}
> +
> +	dev_dbg(&hwdata->drvdata->client->dev,
> +		"%s - %s: p1 = %lu, p2 = %lu, p3 = %lu, divby4 = %d, parent_rate = %lu,
> rate = %lu\n", +		__func__, __clk_get_name(hwdata->hw.clk),
> +		hwdata->params.p1, hwdata->params.p2, hwdata->params.p3,
> +		divby4, parent_rate, rate);
> +
> +	return 0;
> +}
> +
> +static const struct clk_ops si5351_msynth_ops = {
> +	.set_parent = si5351_msynth_set_parent,
> +	.get_parent = si5351_msynth_get_parent,
> +	.recalc_rate = si5351_msynth_recalc_rate,
> +	.round_rate = si5351_msynth_round_rate,
> +	.set_rate = si5351_msynth_set_rate,
> +};
> +
> +/*
> + * Si5351 clkout divider
> + */
> +static int _si5351_clkout_reparent(struct si5351_driver_data *drvdata,
> +				   int num, enum si5351_clkout_src parent)
> +{
> +	u8 val;
> +
> +	if (num > 8)
> +		return -EINVAL;
> +
> +	switch (parent) {
> +	case SI5351_CLKOUT_SRC_MSYNTH_N:
> +		val = SI5351_CLK_INPUT_MULTISYNTH_N;
> +		break;
> +	case SI5351_CLKOUT_SRC_MSYNTH_0_4:
> +		/* clk0/clk4 can only connect to its own multisync */
> +		if (num == 0 || num == 4)
> +			val = SI5351_CLK_INPUT_MULTISYNTH_N;
> +		else
> +			val = SI5351_CLK_INPUT_MULTISYNTH_0_4;
> +		break;
> +	case SI5351_CLKOUT_SRC_XTAL:
> +		val = SI5351_CLK_INPUT_XTAL;
> +		break;
> +	case SI5351_CLKOUT_SRC_CLKIN:
> +		if (drvdata->variant != SI5351_VARIANT_C)
> +			return -EINVAL;
> +
> +		val = SI5351_CLK_INPUT_CLKIN;
> +		break;
> +	default:
> +		return 0;
> +	}
> +
> +	si5351_set_bits(drvdata, SI5351_CLK0_CTRL + num,
> +			SI5351_CLK_INPUT_MASK, val);
> +	return 0;
> +}
> +
> +static int _si5351_clkout_set_drive_strength(
> +	struct si5351_driver_data *drvdata, int num,
> +	enum si5351_drive_strength drive)
> +{
> +	u8 mask;
> +
> +	if (num > 8)
> +		return -EINVAL;
> +
> +	switch (drive) {
> +	case SI5351_DRIVE_2MA:
> +		mask = SI5351_CLK_DRIVE_STRENGTH_2MA;
> +		break;
> +	case SI5351_DRIVE_4MA:
> +		mask = SI5351_CLK_DRIVE_STRENGTH_4MA;
> +		break;
> +	case SI5351_DRIVE_6MA:
> +		mask = SI5351_CLK_DRIVE_STRENGTH_6MA;
> +		break;
> +	case SI5351_DRIVE_8MA:
> +		mask = SI5351_CLK_DRIVE_STRENGTH_8MA;
> +		break;
> +	default:
> +		return 0;
> +	}
> +
> +	si5351_set_bits(drvdata, SI5351_CLK0_CTRL + num,
> +			SI5351_CLK_DRIVE_STRENGTH_MASK, mask);
> +	return 0;
> +}
> +
> +static int si5351_clkout_prepare(struct clk_hw *hw)
> +{
> +	struct si5351_hw_data *hwdata =
> +		container_of(hw, struct si5351_hw_data, hw);
> +
> +	si5351_set_bits(hwdata->drvdata, SI5351_CLK0_CTRL + hwdata->num,
> +			SI5351_CLK_POWERDOWN, 0);
> +	si5351_set_bits(hwdata->drvdata, SI5351_OUTPUT_ENABLE_CTRL,
> +			(1 << hwdata->num), 0);
> +	return 0;
> +}
> +
> +static void si5351_clkout_unprepare(struct clk_hw *hw)
> +{
> +	struct si5351_hw_data *hwdata =
> +		container_of(hw, struct si5351_hw_data, hw);
> +
> +	si5351_set_bits(hwdata->drvdata, SI5351_CLK0_CTRL + hwdata->num,
> +			SI5351_CLK_POWERDOWN, SI5351_CLK_POWERDOWN);
> +	si5351_set_bits(hwdata->drvdata, SI5351_OUTPUT_ENABLE_CTRL,
> +			(1 << hwdata->num), (1 << hwdata->num));
> +}
> +
> +static u8 si5351_clkout_get_parent(struct clk_hw *hw)
> +{
> +	struct si5351_hw_data *hwdata =
> +		container_of(hw, struct si5351_hw_data, hw);
> +	int index = 0;
> +	unsigned char val;
> +
> +	val = si5351_reg_read(hwdata->drvdata, SI5351_CLK0_CTRL + hwdata->num);
> +	switch (val & SI5351_CLK_INPUT_MASK) {
> +	case SI5351_CLK_INPUT_MULTISYNTH_N:
> +		index = 0;
> +		break;
> +	case SI5351_CLK_INPUT_MULTISYNTH_0_4:
> +		index = 1;
> +		break;
> +	case SI5351_CLK_INPUT_XTAL:
> +		index = 2;
> +		break;
> +	case SI5351_CLK_INPUT_CLKIN:
> +		index = 3;
> +		break;
> +	}
> +
> +	return index;
> +}
> +
> +static int si5351_clkout_set_parent(struct clk_hw *hw, u8 index)
> +{
> +	struct si5351_hw_data *hwdata =
> +		container_of(hw, struct si5351_hw_data, hw);
> +	enum si5351_clkout_src parent = SI5351_CLKOUT_SRC_DEFAULT;
> +
> +	switch (index) {
> +	case 0:
> +		parent = SI5351_CLKOUT_SRC_MSYNTH_N;
> +		break;
> +	case 1:
> +		parent = SI5351_CLKOUT_SRC_MSYNTH_0_4;
> +		break;
> +	case 2:
> +		parent = SI5351_CLKOUT_SRC_XTAL;
> +		break;
> +	case 3:
> +		parent = SI5351_CLKOUT_SRC_CLKIN;
> +		break;
> +	}
> +
> +	return _si5351_clkout_reparent(hwdata->drvdata, hwdata->num, parent);
> +}
> +
> +static unsigned long si5351_clkout_recalc_rate(struct clk_hw *hw,
> +					       unsigned long parent_rate)
> +{
> +	struct si5351_hw_data *hwdata =
> +		container_of(hw, struct si5351_hw_data, hw);
> +	unsigned char reg;
> +	unsigned char rdiv;
> +
> +	if (hwdata->num > 5)
> +		reg = si5351_msynth_params_address(hwdata->num) + 2;
> +	else
> +		reg = SI5351_CLK6_7_OUTPUT_DIVIDER;
> +
> +	rdiv = si5351_reg_read(hwdata->drvdata, reg);
> +	if (hwdata->num == 6) {
> +		rdiv &= SI5351_OUTPUT_CLK6_DIV_MASK;
> +	} else {
> +		rdiv &= SI5351_OUTPUT_CLK_DIV_MASK;
> +		rdiv >>= SI5351_OUTPUT_CLK_DIV_SHIFT;
> +	}
> +
> +	return parent_rate >> rdiv;
> +}
> +
> +static long si5351_clkout_round_rate(struct clk_hw *hw, unsigned long rate,
> +				     unsigned long *parent_rate)
> +{
> +	struct si5351_hw_data *hwdata =
> +		container_of(hw, struct si5351_hw_data, hw);
> +	unsigned char rdiv;
> +
> +	/* clkout6/7 can only handle output freqencies < 150MHz */
> +	if (hwdata->num >= 6 && rate > SI5351_CLKOUT67_MAX_FREQ)
> +		rate = SI5351_CLKOUT67_MAX_FREQ;
> +
> +	/* clkout freqency is 8kHz - 160MHz */
> +	if (rate > SI5351_CLKOUT_MAX_FREQ)
> +		rate = SI5351_CLKOUT_MAX_FREQ;
> +	if (rate < SI5351_CLKOUT_MIN_FREQ)
> +		rate = SI5351_CLKOUT_MIN_FREQ;
> +
> +	/* request frequency if multisync master */
> +	if (__clk_get_flags(hwdata->hw.clk) & CLK_SET_RATE_PARENT) {
> +		/* use r divider for frequencies below 1MHz */
> +		rdiv = SI5351_OUTPUT_CLK_DIV_1;
> +		while (rate < SI5351_MULTISYNTH_MIN_FREQ &&
> +		       rdiv < SI5351_OUTPUT_CLK_DIV_128) {
> +			rdiv += 1;
> +			rate *= 2;
> +		}
> +		*parent_rate = rate;
> +	} else {
> +		unsigned long new_rate, new_err, err;
> +
> +		/* round to closed rdiv */
> +		rdiv = SI5351_OUTPUT_CLK_DIV_1;
> +		new_rate = *parent_rate;
> +		err = abs(new_rate - rate);
> +		do {
> +			new_rate >>= 1;
> +			new_err = abs(new_rate - rate);
> +			if (new_err > err || rdiv == SI5351_OUTPUT_CLK_DIV_128)
> +				break;
> +			rdiv++;
> +			err = new_err;
> +		} while (1);
> +	}
> +	rate = *parent_rate >> rdiv;
> +
> +	dev_dbg(&hwdata->drvdata->client->dev,
> +		"%s - %s: rdiv = %u, parent_rate = %lu, rate = %lu\n",
> +		__func__, __clk_get_name(hwdata->hw.clk), (1 << rdiv),
> +		*parent_rate, rate);
> +
> +	return rate;
> +}
> +
> +static int si5351_clkout_set_rate(struct clk_hw *hw, unsigned long rate,
> +				  unsigned long parent_rate)
> +{
> +	struct si5351_hw_data *hwdata =
> +		container_of(hw, struct si5351_hw_data, hw);
> +	unsigned long new_rate, new_err, err;
> +	unsigned char rdiv;
> +
> +	/* round to closed rdiv */
> +	rdiv = SI5351_OUTPUT_CLK_DIV_1;
> +	new_rate = parent_rate;
> +	err = abs(new_rate - rate);
> +	do {
> +		new_rate >>= 1;
> +		new_err = abs(new_rate - rate);
> +		if (new_err > err || rdiv == SI5351_OUTPUT_CLK_DIV_128)
> +			break;
> +		rdiv++;
> +		err = new_err;
> +	} while (1);
> +
> +	/* write output divider */
> +	switch (hwdata->num) {
> +	case 6:
> +		si5351_set_bits(hwdata->drvdata, SI5351_CLK6_7_OUTPUT_DIVIDER,
> +				SI5351_OUTPUT_CLK6_DIV_MASK, rdiv);
> +		break;
> +	case 7:
> +		si5351_set_bits(hwdata->drvdata, SI5351_CLK6_7_OUTPUT_DIVIDER,
> +				SI5351_OUTPUT_CLK_DIV_MASK,
> +				rdiv << SI5351_OUTPUT_CLK_DIV_SHIFT);
> +		break;
> +	default:
> +		si5351_set_bits(hwdata->drvdata,
> +				si5351_msynth_params_address(hwdata->num) + 2,
> +				SI5351_OUTPUT_CLK_DIV_MASK,
> +				rdiv << SI5351_OUTPUT_CLK_DIV_SHIFT);
> +	}
> +
> +	/* powerup clkout */
> +	si5351_set_bits(hwdata->drvdata, SI5351_CLK0_CTRL + hwdata->num,
> +			SI5351_CLK_POWERDOWN, 0);
> +
> +	dev_dbg(&hwdata->drvdata->client->dev,
> +		"%s - %s: rdiv = %u, parent_rate = %lu, rate = %lu\n",
> +		__func__, __clk_get_name(hwdata->hw.clk), (1 << rdiv),
> +		parent_rate, rate);
> +
> +	return 0;
> +}
> +
> +static const struct clk_ops si5351_clkout_ops = {
> +	.prepare = si5351_clkout_prepare,
> +	.unprepare = si5351_clkout_unprepare,
> +	.set_parent = si5351_clkout_set_parent,
> +	.get_parent = si5351_clkout_get_parent,
> +	.recalc_rate = si5351_clkout_recalc_rate,
> +	.round_rate = si5351_clkout_round_rate,
> +	.set_rate = si5351_clkout_set_rate,
> +};
> +
> +/*
> + * Si5351 i2c probe and DT
> + */
> +#ifdef CONFIG_OF
> +static const struct of_device_id si5351_dt_ids[] = {
> +	{ .compatible = "silabs,si5351a", .data = (void *)SI5351_VARIANT_A, },
> +	{ .compatible = "silabs,si5351a-msop",
> +					 .data = (void *)SI5351_VARIANT_A3, },
> +	{ .compatible = "silabs,si5351b", .data = (void *)SI5351_VARIANT_B, },
> +	{ .compatible = "silabs,si5351c", .data = (void *)SI5351_VARIANT_C, },
> +	{ }
> +};
> +MODULE_DEVICE_TABLE(of, si5351_dt_ids);
> +
> +static int si5351_dt_parse(struct i2c_client *client)
> +{
> +	struct device_node *child, *np = client->dev.of_node;
> +	struct si5351_platform_data *pdata;
> +	const struct of_device_id *match;
> +	struct property *prop;
> +	const __be32 *p;
> +	int num = 0;
> +	u32 val;
> +
> +	if (np == NULL)
> +		return 0;
> +
> +	match = of_match_node(si5351_dt_ids, np);
> +	if (match == NULL)
> +		return -EINVAL;
> +
> +	pdata = devm_kzalloc(&client->dev, sizeof(*pdata), GFP_KERNEL);
> +	if (!pdata)
> +		return -ENOMEM;
> +
> +	pdata->variant = (enum si5351_variant)match->data;
> +	pdata->clk_xtal = of_clk_get(np, 0);
> +	if (!IS_ERR(pdata->clk_xtal))
> +		clk_put(pdata->clk_xtal);
> +	pdata->clk_clkin = of_clk_get(np, 1);
> +	if (!IS_ERR(pdata->clk_clkin))
> +		clk_put(pdata->clk_clkin);
> +
> +	/*
> +	 * property silabs,pll-source : <num src>, [<..>]
> +	 * allow to selectively set pll source
> +	 */
> +	of_property_for_each_u32(np, "silabs,pll-source", prop, p, num) {
> +		if (num >= 2) {
> +			dev_err(&client->dev,
> +				"invalid pll %d on pll-source prop\n", num);
> +			return -EINVAL;
> +		}
> +
> +		p = of_prop_next_u32(prop, p, &val);
> +		if (!p) {
> +			dev_err(&client->dev,
> +				"missing pll-source for pll %d\n", num);
> +			return -EINVAL;
> +		}
> +
> +		switch (val) {
> +		case 0:
> +			pdata->pll_src[num] = SI5351_PLL_SRC_XTAL;
> +			break;
> +		case 1:
> +			if (pdata->variant != SI5351_VARIANT_C) {
> +				dev_err(&client->dev,
> +					"invalid parent %d for pll %d\n",
> +					val, num);
> +				return -EINVAL;
> +			}
> +			pdata->pll_src[num] = SI5351_PLL_SRC_CLKIN;
> +			break;
> +		default:
> +			dev_err(&client->dev,
> +				 "invalid parent %d for pll %d\n", val, num);
> +			return -EINVAL;
> +		}
> +	}
> +
> +	/* per clkout properties */
> +	for_each_child_of_node(np, child) {
> +		if (of_property_read_u32(child, "reg", &num)) {
> +			dev_err(&client->dev, "missing reg property of %s\n",
> +				child->name);
> +			return -EINVAL;
> +		}
> +
> +		if (num >= 8 ||
> +		    (pdata->variant == SI5351_VARIANT_A3 && num >= 3)) {
> +			dev_err(&client->dev, "invalid clkout %d\n", num);
> +			return -EINVAL;
> +		}
> +
> +		if (!of_property_read_u32(child, "silabs,multisynth-source",
> +					  &val)) {
> +			switch (val) {
> +			case 0:
> +				pdata->clkout[num].multisynth_src =
> +					SI5351_MULTISYNTH_SRC_VCO0;
> +				break;
> +			case 1:
> +				pdata->clkout[num].multisynth_src =
> +					SI5351_MULTISYNTH_SRC_VCO1;
> +				break;
> +			default:
> +				dev_err(&client->dev,
> +					"invalid parent %d for multisynth %d\n",
> +					val, num);
> +				return -EINVAL;
> +			}
> +		}
> +
> +		if (!of_property_read_u32(child, "silabs,clock-source", &val)) {
> +			switch (val) {
> +			case 0:
> +				pdata->clkout[num].clkout_src =
> +					SI5351_CLKOUT_SRC_MSYNTH_N;
> +				break;
> +			case 1:
> +				pdata->clkout[num].clkout_src =
> +					SI5351_CLKOUT_SRC_MSYNTH_0_4;
> +				break;
> +			case 2:
> +				pdata->clkout[num].clkout_src =
> +					SI5351_CLKOUT_SRC_XTAL;
> +				break;
> +			case 3:
> +				if (pdata->variant != SI5351_VARIANT_C) {
> +					dev_err(&client->dev,
> +						"invalid parent %d for clkout %d\n",
> +						val, num);
> +					return -EINVAL;
> +				}
> +				pdata->clkout[num].clkout_src =
> +					SI5351_CLKOUT_SRC_CLKIN;
> +				break;
> +			default:
> +				dev_err(&client->dev,
> +					"invalid parent %d for clkout %d\n",
> +					val, num);
> +				return -EINVAL;
> +			}
> +		}
> +
> +		if (!of_property_read_u32(child, "silabs,drive-strength",
> +					  &val)) {
> +			switch (val) {
> +			case SI5351_DRIVE_2MA:
> +			case SI5351_DRIVE_4MA:
> +			case SI5351_DRIVE_6MA:
> +			case SI5351_DRIVE_8MA:
> +				pdata->clkout[num].drive = val;
> +				break;
> +			default:
> +				dev_err(&client->dev,
> +					"invalid drive strength %d for clkout %d\n",
> +					val, num);
> +				return -EINVAL;
> +			}
> +		}
> +
> +		if (!of_property_read_u32(child, "clock-frequency", &val))
> +			pdata->clkout[num].rate = val;
> +
> +		pdata->clkout[num].pll_master =
> +			of_property_read_bool(child, "silabs,pll-master");
> +	}
> +	client->dev.platform_data = pdata;
> +
> +	return 0;
> +}
> +#else
> +static int si5351_dt_parse(struct i2c_client *client)
> +{
> +	return 0;
> +}
> +#endif /* CONFIG_OF */
> +
> +static int si5351_i2c_probe(struct i2c_client *client,
> +			    const struct i2c_device_id *id)
> +{
> +	struct si5351_platform_data *pdata;
> +	struct si5351_driver_data *drvdata;
> +	struct clk_init_data init;
> +	struct clk *clk;
> +	const char *parent_names[4];
> +	u8 num_parents, num_clocks;
> +	int ret, n;
> +
> +	ret = si5351_dt_parse(client);
> +	if (ret)
> +		return ret;
> +
> +	pdata = client->dev.platform_data;
> +	if (!pdata)
> +		return -EINVAL;
> +
> +	drvdata = devm_kzalloc(&client->dev, sizeof(*drvdata), GFP_KERNEL);
> +	if (drvdata == NULL) {
> +		dev_err(&client->dev, "unable to allocate driver data\n");
> +		return -ENOMEM;
> +	}
> +
> +	i2c_set_clientdata(client, drvdata);
> +	drvdata->client = client;
> +	drvdata->variant = pdata->variant;
> +	drvdata->pxtal = pdata->clk_xtal;
> +	drvdata->pclkin = pdata->clk_clkin;
> +
> +	drvdata->regmap = devm_regmap_init_i2c(client, &si5351_regmap_config);
> +	if (IS_ERR(drvdata->regmap)) {
> +		dev_err(&client->dev, "failed to allocate register map\n");
> +		return PTR_ERR(drvdata->regmap);
> +	}
> +
> +	/* Disable interrupts */
> +	si5351_reg_write(drvdata, SI5351_INTERRUPT_MASK, 0xf0);
> +	/* Set disabled output drivers to drive low */
> +	si5351_reg_write(drvdata, SI5351_CLK3_0_DISABLE_STATE, 0x00);
> +	si5351_reg_write(drvdata, SI5351_CLK7_4_DISABLE_STATE, 0x00);
> +	/* Ensure pll select is on XTAL for Si5351A/B */
> +	if (drvdata->variant != SI5351_VARIANT_C)
> +		si5351_set_bits(drvdata, SI5351_PLL_INPUT_SOURCE,
> +				SI5351_PLLA_SOURCE | SI5351_PLLB_SOURCE, 0);
> +
> +	/* setup clock configuration */
> +	for (n = 0; n < 2; n++) {
> +		ret = _si5351_pll_reparent(drvdata, n, pdata->pll_src[n]);
> +		if (ret) {
> +			dev_err(&client->dev,
> +				"failed to reparent pll %d to %d\n",
> +				n, pdata->pll_src[n]);
> +			return ret;
> +		}
> +	}
> +
> +	for (n = 0; n < 8; n++) {
> +		ret = _si5351_msynth_reparent(drvdata, n,
> +					      pdata->clkout[n].multisynth_src);
> +		if (ret) {
> +			dev_err(&client->dev,
> +				"failed to reparent multisynth %d to %d\n",
> +				n, pdata->clkout[n].multisynth_src);
> +			return ret;
> +		}
> +
> +		ret = _si5351_clkout_reparent(drvdata, n,
> +					      pdata->clkout[n].clkout_src);
> +		if (ret) {
> +			dev_err(&client->dev,
> +				"failed to reparent clkout %d to %d\n",
> +				n, pdata->clkout[n].clkout_src);
> +			return ret;
> +		}
> +
> +		ret = _si5351_clkout_set_drive_strength(drvdata, n,
> +							pdata->clkout[n].drive);
> +		if (ret) {
> +			dev_err(&client->dev,
> +				"failed set drive strength of clkout%d to %d\n",
> +				n, pdata->clkout[n].drive);
> +			return ret;
> +		}
> +	}
> +
> +	/* register xtal input clock gate */
> +	memset(&init, 0, sizeof(init));
> +	init.name = si5351_input_names[0];
> +	init.ops = &si5351_xtal_ops;
> +	init.flags = 0;
> +	if (!IS_ERR(drvdata->pxtal)) {
> +		drvdata->pxtal_name = __clk_get_name(drvdata->pxtal);
> +		init.parent_names = &drvdata->pxtal_name;
> +		init.num_parents = 1;
> +	}
> +	drvdata->xtal.init = &init;
> +	clk = devm_clk_register(&client->dev, &drvdata->xtal);
> +	if (IS_ERR(clk)) {
> +		dev_err(&client->dev, "unable to register %s\n", init.name);
> +		return PTR_ERR(clk);
> +	}
> +
> +	/* register clkin input clock gate */
> +	if (drvdata->variant == SI5351_VARIANT_C) {
> +		memset(&init, 0, sizeof(init));
> +		init.name = si5351_input_names[1];
> +		init.ops = &si5351_clkin_ops;
> +		if (!IS_ERR(drvdata->pclkin)) {
> +			drvdata->pclkin_name = __clk_get_name(drvdata->pclkin);
> +			init.parent_names = &drvdata->pclkin_name;
> +			init.num_parents = 1;
> +		}
> +		drvdata->clkin.init = &init;
> +		clk = devm_clk_register(&client->dev, &drvdata->clkin);
> +		if (IS_ERR(clk)) {
> +			dev_err(&client->dev, "unable to register %s\n",
> +				init.name);
> +			return PTR_ERR(clk);
> +		}
> +	}
> +
> +	/* Si5351C allows to mux either xtal or clkin to PLL input */
> +	num_parents = (drvdata->variant == SI5351_VARIANT_C) ? 2 : 1;
> +	parent_names[0] = si5351_input_names[0];
> +	parent_names[1] = si5351_input_names[1];
> +
> +	/* register PLLA */
> +	drvdata->pll[0].num = 0;
> +	drvdata->pll[0].drvdata = drvdata;
> +	drvdata->pll[0].hw.init = &init;
> +	memset(&init, 0, sizeof(init));
> +	init.name = si5351_pll_names[0];
> +	init.ops = &si5351_pll_ops;
> +	init.flags = 0;
> +	init.parent_names = parent_names;
> +	init.num_parents = num_parents;
> +	clk = devm_clk_register(&client->dev, &drvdata->pll[0].hw);
> +	if (IS_ERR(clk)) {
> +		dev_err(&client->dev, "unable to register %s\n", init.name);
> +		return -EINVAL;
> +	}
> +
> +	/* register PLLB or VXCO (Si5351B) */
> +	drvdata->pll[1].num = 1;
> +	drvdata->pll[1].drvdata = drvdata;
> +	drvdata->pll[1].hw.init = &init;
> +	memset(&init, 0, sizeof(init));
> +	if (drvdata->variant == SI5351_VARIANT_B) {
> +		init.name = si5351_pll_names[2];
> +		init.ops = &si5351_vxco_ops;
> +		init.flags = CLK_IS_ROOT;
> +		init.parent_names = NULL;
> +		init.num_parents = 0;
> +	} else {
> +		init.name = si5351_pll_names[1];
> +		init.ops = &si5351_pll_ops;
> +		init.flags = 0;
> +		init.parent_names = parent_names;
> +		init.num_parents = num_parents;
> +	}
> +	clk = devm_clk_register(&client->dev, &drvdata->pll[1].hw);
> +	if (IS_ERR(clk)) {
> +		dev_err(&client->dev, "unable to register %s\n", init.name);
> +		return -EINVAL;
> +	}
> +
> +	/* register clk multisync and clk out divider */
> +	num_clocks = (drvdata->variant == SI5351_VARIANT_A3) ? 3 : 8;
> +	parent_names[0] = si5351_pll_names[0];
> +	if (drvdata->variant == SI5351_VARIANT_B)
> +		parent_names[1] = si5351_pll_names[2];
> +	else
> +		parent_names[1] = si5351_pll_names[1];
> +
> +	drvdata->msynth = devm_kzalloc(&client->dev, num_clocks *
> +				       sizeof(*drvdata->msynth), GFP_KERNEL);
> +	drvdata->clkout = devm_kzalloc(&client->dev, num_clocks *
> +				       sizeof(*drvdata->clkout), GFP_KERNEL);
> +
> +	drvdata->onecell.clk_num = num_clocks;
> +	drvdata->onecell.clks = devm_kzalloc(&client->dev,
> +		num_clocks * sizeof(*drvdata->onecell.clks), GFP_KERNEL);
> +
> +	if (WARN_ON(!drvdata->msynth || !drvdata->clkout ||
> +		    !drvdata->onecell.clks))
> +		return -ENOMEM;
> +
> +	for (n = 0; n < num_clocks; n++) {
> +		drvdata->msynth[n].num = n;
> +		drvdata->msynth[n].drvdata = drvdata;
> +		drvdata->msynth[n].hw.init = &init;
> +		memset(&init, 0, sizeof(init));
> +		init.name = si5351_msynth_names[n];
> +		init.ops = &si5351_msynth_ops;
> +		init.flags = 0;
> +		if (pdata->clkout[n].pll_master)
> +			init.flags |= CLK_SET_RATE_PARENT;
> +		init.parent_names = parent_names;
> +		init.num_parents = 2;
> +		clk = devm_clk_register(&client->dev, &drvdata->msynth[n].hw);
> +		if (IS_ERR(clk)) {
> +			dev_err(&client->dev, "unable to register %s\n",
> +				init.name);
> +			return -EINVAL;
> +		}
> +	}
> +
> +	num_parents = (drvdata->variant == SI5351_VARIANT_C) ? 4 : 3;
> +	parent_names[2] = si5351_input_names[0];
> +	parent_names[3] = si5351_input_names[1];
> +	for (n = 0; n < num_clocks; n++) {
> +		parent_names[0] = si5351_msynth_names[n];
> +		parent_names[1] = (n < 4) ? si5351_msynth_names[0] :
> +			si5351_msynth_names[4];
> +
> +		drvdata->clkout[n].num = n;
> +		drvdata->clkout[n].drvdata = drvdata;
> +		drvdata->clkout[n].hw.init = &init;
> +		memset(&init, 0, sizeof(init));
> +		init.name = si5351_clkout_names[n];
> +		init.ops = &si5351_clkout_ops;
> +		init.flags = 0;
> +		if (pdata->clkout[n].clkout_src == SI5351_CLKOUT_SRC_MSYNTH_N)
> +			init.flags |= CLK_SET_RATE_PARENT;
> +		init.parent_names = parent_names;
> +		init.num_parents = num_parents;
> +		clk = devm_clk_register(&client->dev, &drvdata->clkout[n].hw);
> +		if (IS_ERR(clk)) {
> +			dev_err(&client->dev, "unable to register %s\n",
> +				init.name);
> +			return -EINVAL;
> +		}
> +		drvdata->onecell.clks[n] = clk;
> +	}
> +
> +	ret = of_clk_add_provider(client->dev.of_node, of_clk_src_onecell_get,
> +				  &drvdata->onecell);
> +	if (ret) {
> +		dev_err(&client->dev, "unable to add clk provider\n");
> +		return ret;
> +	}
> +
> +	return 0;
> +}
> +
> +static const struct i2c_device_id si5351_i2c_ids[] = {
> +	{ "silabs,si5351", 0 },
> +	{ }
> +};
> +MODULE_DEVICE_TABLE(i2c, si5351_i2c_ids);
> +
> +static struct i2c_driver si5351_driver = {
> +	.driver = {
> +		.name = "si5351",
> +		.of_match_table = of_match_ptr(si5351_dt_ids),
> +	},
> +	.probe = si5351_i2c_probe,
> +	.id_table = si5351_i2c_ids,
> +};
> +module_i2c_driver(si5351_driver);
> +
> +MODULE_AUTHOR("Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com");
> +MODULE_DESCRIPTION("Silicon Labs Si5351A/B/C clock generator driver");
> +MODULE_LICENSE("GPL");
> diff --git a/drivers/clk/clk-si5351.h b/drivers/clk/clk-si5351.h
> new file mode 100644
> index 0000000..af41b50
> --- /dev/null
> +++ b/drivers/clk/clk-si5351.h
> @@ -0,0 +1,155 @@
> +/*
> + * clk-si5351.h: Silicon Laboratories Si5351A/B/C I2C Clock Generator
> + *
> + * Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
> + * Rabeeh Khoury <rabeeh at solid-run.com>
> + *
> + * 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.
> + */
> +
> +#ifndef _CLK_SI5351_H_
> +#define _CLK_SI5351_H_
> +
> +#define SI5351_BUS_BASE_ADDR			0x60
> +
> +#define SI5351_PLL_VCO_MIN			600000000
> +#define SI5351_PLL_VCO_MAX			900000000
> +#define SI5351_MULTISYNTH_MIN_FREQ		1000000
> +#define SI5351_MULTISYNTH_DIVBY4_FREQ		150000000
> +#define SI5351_MULTISYNTH_MAX_FREQ		160000000
> +#define SI5351_MULTISYNTH67_MAX_FREQ		SI5351_MULTISYNTH_DIVBY4_FREQ
> +#define SI5351_CLKOUT_MIN_FREQ			8000
> +#define SI5351_CLKOUT_MAX_FREQ			SI5351_MULTISYNTH_MAX_FREQ
> +#define SI5351_CLKOUT67_MAX_FREQ		SI5351_MULTISYNTH67_MAX_FREQ
> +
> +#define SI5351_PLL_A_MIN			15
> +#define SI5351_PLL_A_MAX			90
> +#define SI5351_PLL_B_MAX			(SI5351_PLL_C_MAX-1)
> +#define SI5351_PLL_C_MAX			1048575
> +#define SI5351_MULTISYNTH_A_MIN			6
> +#define SI5351_MULTISYNTH_A_MAX			1800
> +#define SI5351_MULTISYNTH67_A_MAX		254
> +#define SI5351_MULTISYNTH_B_MAX			(SI5351_MULTISYNTH_C_MAX-1)
> +#define SI5351_MULTISYNTH_C_MAX			1048575
> +#define SI5351_MULTISYNTH_P1_MAX		((1<<18)-1)
> +#define SI5351_MULTISYNTH_P2_MAX		((1<<20)-1)
> +#define SI5351_MULTISYNTH_P3_MAX		((1<<20)-1)
> +
> +#define SI5351_DEVICE_STATUS			0
> +#define SI5351_INTERRUPT_STATUS			1
> +#define SI5351_INTERRUPT_MASK			2
> +#define  SI5351_STATUS_SYS_INIT			(1<<7)
> +#define  SI5351_STATUS_LOL_B			(1<<6)
> +#define  SI5351_STATUS_LOL_A			(1<<5)
> +#define  SI5351_STATUS_LOS			(1<<4)
> +#define SI5351_OUTPUT_ENABLE_CTRL		3
> +#define SI5351_OEB_PIN_ENABLE_CTRL		9
> +#define SI5351_PLL_INPUT_SOURCE			15
> +#define  SI5351_CLKIN_DIV_MASK			(3<<6)
> +#define  SI5351_CLKIN_DIV_1			(0<<6)
> +#define  SI5351_CLKIN_DIV_2			(1<<6)
> +#define  SI5351_CLKIN_DIV_4			(2<<6)
> +#define  SI5351_CLKIN_DIV_8			(3<<6)
> +#define  SI5351_PLLB_SOURCE			(1<<3)
> +#define  SI5351_PLLA_SOURCE			(1<<2)
> +
> +#define SI5351_CLK0_CTRL			16
> +#define SI5351_CLK1_CTRL			17
> +#define SI5351_CLK2_CTRL			18
> +#define SI5351_CLK3_CTRL			19
> +#define SI5351_CLK4_CTRL			20
> +#define SI5351_CLK5_CTRL			21
> +#define SI5351_CLK6_CTRL			22
> +#define SI5351_CLK7_CTRL			23
> +#define  SI5351_CLK_POWERDOWN			(1<<7)
> +#define  SI5351_CLK_INTEGER_MODE		(1<<6)
> +#define  SI5351_CLK_PLL_SELECT			(1<<5)
> +#define  SI5351_CLK_INVERT			(1<<4)
> +#define  SI5351_CLK_INPUT_MASK			(3<<2)
> +#define  SI5351_CLK_INPUT_XTAL			(0<<2)
> +#define  SI5351_CLK_INPUT_CLKIN			(1<<2)
> +#define  SI5351_CLK_INPUT_MULTISYNTH_0_4	(2<<2)
> +#define  SI5351_CLK_INPUT_MULTISYNTH_N		(3<<2)
> +#define  SI5351_CLK_DRIVE_STRENGTH_MASK		(3<<0)
> +#define  SI5351_CLK_DRIVE_STRENGTH_2MA		(0<<0)
> +#define  SI5351_CLK_DRIVE_STRENGTH_4MA		(1<<0)
> +#define  SI5351_CLK_DRIVE_STRENGTH_6MA		(2<<0)
> +#define  SI5351_CLK_DRIVE_STRENGTH_8MA		(3<<0)
> +
> +#define SI5351_CLK3_0_DISABLE_STATE		24
> +#define SI5351_CLK7_4_DISABLE_STATE		25
> +#define  SI5351_CLK_DISABLE_STATE_LOW		0
> +#define  SI5351_CLK_DISABLE_STATE_HIGH		1
> +#define  SI5351_CLK_DISABLE_STATE_FLOAT		2
> +#define  SI5351_CLK_DISABLE_STATE_NEVER		3
> +
> +#define SI5351_PARAMETERS_LENGTH		8
> +#define SI5351_PLLA_PARAMETERS			26
> +#define SI5351_PLLB_PARAMETERS			34
> +#define SI5351_CLK0_PARAMETERS			42
> +#define SI5351_CLK1_PARAMETERS			50
> +#define SI5351_CLK2_PARAMETERS			58
> +#define SI5351_CLK3_PARAMETERS			66
> +#define SI5351_CLK4_PARAMETERS			74
> +#define SI5351_CLK5_PARAMETERS			82
> +#define SI5351_CLK6_PARAMETERS			90
> +#define SI5351_CLK7_PARAMETERS			91
> +#define SI5351_CLK6_7_OUTPUT_DIVIDER		92
> +#define  SI5351_OUTPUT_CLK_DIV_MASK		(7 << 4)
> +#define  SI5351_OUTPUT_CLK6_DIV_MASK		(7 << 0)
> +#define  SI5351_OUTPUT_CLK_DIV_SHIFT		4
> +#define  SI5351_OUTPUT_CLK_DIV6_SHIFT		0
> +#define  SI5351_OUTPUT_CLK_DIV_1		0
> +#define  SI5351_OUTPUT_CLK_DIV_2		1
> +#define  SI5351_OUTPUT_CLK_DIV_4		2
> +#define  SI5351_OUTPUT_CLK_DIV_8		3
> +#define  SI5351_OUTPUT_CLK_DIV_16		4
> +#define  SI5351_OUTPUT_CLK_DIV_32		5
> +#define  SI5351_OUTPUT_CLK_DIV_64		6
> +#define  SI5351_OUTPUT_CLK_DIV_128		7
> +#define  SI5351_OUTPUT_CLK_DIVBY4		(3<<2)
> +
> +#define SI5351_SSC_PARAM0			149
> +#define SI5351_SSC_PARAM1			150
> +#define SI5351_SSC_PARAM2			151
> +#define SI5351_SSC_PARAM3			152
> +#define SI5351_SSC_PARAM4			153
> +#define SI5351_SSC_PARAM5			154
> +#define SI5351_SSC_PARAM6			155
> +#define SI5351_SSC_PARAM7			156
> +#define SI5351_SSC_PARAM8			157
> +#define SI5351_SSC_PARAM9			158
> +#define SI5351_SSC_PARAM10			159
> +#define SI5351_SSC_PARAM11			160
> +#define SI5351_SSC_PARAM12			161
> +
> +#define SI5351_VXCO_PARAMETERS_LOW		162
> +#define SI5351_VXCO_PARAMETERS_MID		163
> +#define SI5351_VXCO_PARAMETERS_HIGH		164
> +
> +#define SI5351_CLK0_PHASE_OFFSET		165
> +#define SI5351_CLK1_PHASE_OFFSET		166
> +#define SI5351_CLK2_PHASE_OFFSET		167
> +#define SI5351_CLK3_PHASE_OFFSET		168
> +#define SI5351_CLK4_PHASE_OFFSET		169
> +#define SI5351_CLK5_PHASE_OFFSET		170
> +
> +#define SI5351_PLL_RESET			177
> +#define  SI5351_PLL_RESET_B			(1<<7)
> +#define  SI5351_PLL_RESET_A			(1<<5)
> +
> +#define SI5351_CRYSTAL_LOAD			183
> +#define  SI5351_CRYSTAL_LOAD_MASK		(3<<6)
> +#define  SI5351_CRYSTAL_LOAD_6PF		(1<<6)
> +#define  SI5351_CRYSTAL_LOAD_8PF		(2<<6)
> +#define  SI5351_CRYSTAL_LOAD_10PF		(3<<6)
> +
> +#define SI5351_FANOUT_ENABLE			187
> +#define  SI5351_CLKIN_ENABLE			(1<<7)
> +#define  SI5351_XTAL_ENABLE			(1<<6)
> +#define  SI5351_MULTISYNTH_ENABLE		(1<<4)
> +
> +#endif
> diff --git a/include/linux/platform_data/si5351.h
> b/include/linux/platform_data/si5351.h new file mode 100644
> index 0000000..92dabca
> --- /dev/null
> +++ b/include/linux/platform_data/si5351.h
> @@ -0,0 +1,114 @@
> +/*
> + * Si5351A/B/C programmable clock generator platform_data.
> + */
> +
> +#ifndef __LINUX_PLATFORM_DATA_SI5351_H__
> +#define __LINUX_PLATFORM_DATA_SI5351_H__
> +
> +struct clk;
> +
> +/**
> + * enum si5351_variant - SiLabs Si5351 chip variant
> + * @SI5351_VARIANT_A: Si5351A (8 output clocks, XTAL input)
> + * @SI5351_VARIANT_A3: Si5351A MSOP10 (3 output clocks, XTAL input)
> + * @SI5351_VARIANT_B: Si5351B (8 output clocks, XTAL/VXCO input)
> + * @SI5351_VARIANT_C: Si5351C (8 output clocks, XTAL/CLKIN input)
> + */
> +enum si5351_variant {
> +	SI5351_VARIANT_A = 1,
> +	SI5351_VARIANT_A3 = 2,
> +	SI5351_VARIANT_B = 3,
> +	SI5351_VARIANT_C = 4,
> +};
> +
> +/**
> + * enum si5351_pll_src - Si5351 pll clock source
> + * @SI5351_PLL_SRC_DEFAULT: default, do not change eeprom config
> + * @SI5351_PLL_SRC_XTAL: pll source clock is XTAL input
> + * @SI5351_PLL_SRC_CLKIN: pll source clock is CLKIN input (Si5351C only)
> + */
> +enum si5351_pll_src {
> +	SI5351_PLL_SRC_DEFAULT = 0,
> +	SI5351_PLL_SRC_XTAL = 1,
> +	SI5351_PLL_SRC_CLKIN = 2,
> +};
> +
> +/**
> + * enum si5351_multisynth_src - Si5351 multisynth clock source
> + * @SI5351_MULTISYNTH_SRC_DEFAULT: default, do not change eeprom config
> + * @SI5351_MULTISYNTH_SRC_VCO0: multisynth source clock is VCO0
> + * @SI5351_MULTISYNTH_SRC_VCO1: multisynth source clock is VCO1/VXCO
> + */
> +enum si5351_multisynth_src {
> +	SI5351_MULTISYNTH_SRC_DEFAULT = 0,
> +	SI5351_MULTISYNTH_SRC_VCO0 = 1,
> +	SI5351_MULTISYNTH_SRC_VCO1 = 2,
> +};
> +
> +/**
> + * enum si5351_clkout_src - Si5351 clock output clock source
> + * @SI5351_CLKOUT_SRC_DEFAULT: default, do not change eeprom config
> + * @SI5351_CLKOUT_SRC_MSYNTH_N: clkout N source clock is multisynth N
> + * @SI5351_CLKOUT_SRC_MSYNTH_0_4: clkout N source clock is multisynth 0
> (N<4) + *                                or 4 (N>=4)
> + * @SI5351_CLKOUT_SRC_XTAL: clkout N source clock is XTAL
> + * @SI5351_CLKOUT_SRC_CLKIN: clkout N source clock is CLKIN (Si5351C only)
> + */
> +enum si5351_clkout_src {
> +	SI5351_CLKOUT_SRC_DEFAULT = 0,
> +	SI5351_CLKOUT_SRC_MSYNTH_N = 1,
> +	SI5351_CLKOUT_SRC_MSYNTH_0_4 = 2,
> +	SI5351_CLKOUT_SRC_XTAL = 3,
> +	SI5351_CLKOUT_SRC_CLKIN = 4,
> +};
> +
> +/**
> + * enum si5351_drive_strength - Si5351 clock output drive strength
> + * @SI5351_DRIVE_DEFAULT: default, do not change eeprom config
> + * @SI5351_DRIVE_2MA: 2mA clock output drive strength
> + * @SI5351_DRIVE_4MA: 4mA clock output drive strength
> + * @SI5351_DRIVE_6MA: 6mA clock output drive strength
> + * @SI5351_DRIVE_8MA: 8mA clock output drive strength
> + */
> +enum si5351_drive_strength {
> +	SI5351_DRIVE_DEFAULT = 0,
> +	SI5351_DRIVE_2MA = 2,
> +	SI5351_DRIVE_4MA = 4,
> +	SI5351_DRIVE_6MA = 6,
> +	SI5351_DRIVE_8MA = 8,
> +};
> +
> +/**
> + * struct si5351_clkout_config - Si5351 clock output configuration
> + * @clkout: clkout number
> + * @multisynth_src: multisynth source clock
> + * @clkout_src: clkout source clock
> + * @pll_master: if true, clkout can also change pll rate
> + * @drive: output drive strength
> + * @rate: initial clkout rate, or default if 0
> + */
> +struct si5351_clkout_config {
> +	enum si5351_multisynth_src multisynth_src;
> +	enum si5351_clkout_src clkout_src;
> +	enum si5351_drive_strength drive;
> +	bool pll_master;
> +	unsigned long rate;
> +};
> +
> +/**
> + * struct si5351_platform_data - Platform data for the Si5351 clock driver
> + * @variant: Si5351 chip variant
> + * @clk_xtal: xtal input clock
> + * @clk_clkin: clkin input clock
> + * @pll_src: array of pll source clock setting
> + * @clkout: array of clkout configuration
> + */
> +struct si5351_platform_data {
> +	enum si5351_variant variant;
> +	struct clk *clk_xtal;
> +	struct clk *clk_clkin;
> +	enum si5351_pll_src pll_src[2];
> +	struct si5351_clkout_config clkout[8];
> +};
> +
> +#endif


From lorenzo.pieralisi at arm.com  Fri Apr 12 07:44:58 2013
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Fri, 12 Apr 2013 12:44:58 +0100
Subject: [RFC PATCH 01/11] Documentation: DT: arm: define CPU topology
 bindings
In-Reply-To: <20130411180125.GB2239@linaro.org>
References: <1365671562-2403-1-git-send-email-mark.rutland@arm.com>
 <1365671562-2403-2-git-send-email-mark.rutland@arm.com>
 <5166D01F.5070404@gmail.com>
 <20130411155054.GA29509@e102568-lin.cambridge.arm.com>
 <20130411180125.GB2239@linaro.org>
Message-ID: <20130412114457.GC6637@e102568-lin.cambridge.arm.com>

On Thu, Apr 11, 2013 at 07:01:25PM +0100, Dave Martin wrote:

[...]

> > > > +===========================================
> > > > +2 - cpu-map node
> > > > +===========================================
> > > > +
> > > > +The ARM CPU topology is defined within a container node, sitting at the top
> > > > +level of the device tree (/), the cpu-map node.
> > > > +
> > > > +- cpu-map node
> > > > +
> > > > + Usage: Required to define ARM CPU topology
> > > > +
> > > > + Description: The cpu-map node is just a container node where its
> > > > +              subnodes describe the CPU topology
> > > > +
> > > > + Node name must be "cpu-map".
> > > > +
> > > > + A cpu-map node's child nodes can be:
> > > > +
> > > > + - one or more cluster nodes
> > > > +
> > > > + Any other configuration is considered invalid.
> > > > +
> > > > +The cpu-map node can only contain three types of child nodes:
> > > > +
> > > > +- cluster node
> > > > +- core node
> > > > +- thread node
> > > > +
> > >
> > > Why not put the topology in the /cpus nodes? I don't really see the
> > > point of having a flat list of cpus and separate topology info. There is
> > > some compatibility issue, but adding optional levels for clusters can be
> > > handled.
> >
> > I thought this would break all code relying on /cpu nodes being /cpus node's
> > children. Furthermore, I was told that the /cpus node can only have /cpu nodes
> > as children.
> >
> > If you wish so, we can define the topology in the /cpus node, fine by me.
> 
> Can we make such extensive changes to the cpus node without violating
> the ePAPR specification?
> 
> If we can, great, but I'm a but unclear on how this would be achieved.

+1

> > > > +whose bindings are described in paragraph 3.
> > > > +
> > > > +The nodes describing the CPU topology (cluster/core/thread) can only be
> > > > +defined within the cpu-map node.
> > > > +Any other configuration is consider invalid and therefore must be ignored.
> > > > +
> > > > +===========================================
> > > > +2.1 - cpu-map child nodes naming convention
> > > > +===========================================
> > > > +
> > > > +cpu-map child nodes must follow a naming convention where the node name
> > > > +must be "clusterN", "coreN", "threadN" depending on the node type (ie
> > > > +cluster/core/thread) (where N = {0, 1, ...} is the node number; nodes which
> > > > +are siblings within a single common parent node must be given a unique and
> > > > +sequential N value, starting from 0).
> > > > +cpu-map child nodes which do not share a common parent node can have the same
> > > > +name (ie same number N as other cpu-map child nodes at different device tree
> > > > +levels) since name uniqueness will be guaranteed by the device tree hierarchy.
> > > > +
> > > > +===========================================
> > > > +3 - cluster/core/thread node bindings
> > > > +===========================================
> > > > +
> > > > +Bindings for cluster/cpu/thread nodes are defined as follows:
> > > > +
> > > > +- cluster node
> > > > +
> > > > +  Description: must be declared within a cpu-map node, one node
> > > > +               per cluster. A system can contain several layers of
> > > > +               clustering and cluster nodes can be contained in parent
> > > > +               cluster nodes.
> > > > +
> > > > + The cluster node name must be "clusterN" as described in 2.1 above.
> > > > + A cluster node can not be a leaf node.
> > >
> > > Follow standard conventions with "cluster at N" and a reg property with the
> > > number.
> >
> > We are defining the topology to decouple the cluster/core/thread concept
> > from the MPIDR. Having a reg property in the cluster (and core) nodes
> > would complicate things if that reg property must correspond to an MPIDR
> > bitfield. If it is meant to be just an enumeration at a given device tree
> > level, I am ok with changing that.
> 
> As a pure enumeration, I think that works fine.  It's more verbose
> but also more conformant to DT conventions.  I'm not sure there's
> another difference.
> 
> The proposed support for C preprocessing of dts files might provide a
> way to help debloat this to some extent in dts source, while still
> following the DT convention of using unit addresses and reg properties.
> This will significantly increase the size of the FDT blob if the
> number of CPUs is large.  I don't remember offhand if we have a limit
> on the size of FDT we can cope with.  Finding ways to relax the limit
> is a better solution than dodging round standards, though.  We can
> cross that bridge when/if we come to it.

Well, that's a problem by itself, certainly adding a reg property to
the cluster nodes will make it worse, but as you said still better that
than dodging standards.

> >
> > > > +
> > > > + A cluster node's child nodes must be:
> > > > +
> > > > + - one or more cluster nodes; or
> > > > + - one or more core nodes
> > > > +
> > > > + Any other configuration is considered invalid.
> > > > +
> > > > +- core node
> > > > +
> > > > + Description: must be declared in a cluster node, one node per core in
> > > > +              the cluster. If the system does not support SMT, core
> > > > +              nodes are leaf nodes, otherwise they become containers of
> > > > +              thread nodes.
> > > > +
> > > > + The core node name must be "coreN" as described in 2.1 above.
> > > > +
> > > > + A core node must be a leaf node if SMT is not supported.
> > > > +
> > > > + Properties for core nodes that are leaf nodes:
> > > > +
> > > > + - cpu
> > > > +         Usage: required
> > > > +         Value type: <phandle>
> > > > +         Definition: a phandle to the cpu node that corresponds to the
> > > > +                     core node.
> > > > +
> > > > + If a core node is not a leaf node (CPUs supporting SMT) a core node's
> > > > + child nodes can be:
> > > > +
> > > > + - one or more thread nodes
> > > > +
> > > > + Any other configuration is considered invalid.
> > > > +
> > > > +- thread node
> > > > +
> > > > + Description: must be declared in a core node, one node per thread
> > > > +              in the core if the system supports SMT. Thread nodes are
> > > > +              always leaf nodes in the device tree.
> > > > +
> > > > + The thread node name must be "threadN" as described in 2.1 above.
> > > > +
> > > > + A thread node must be a leaf node.
> > > > +
> > > > + A thread node must contain the following property:
> > > > +
> > > > + - cpu
> > > > +         Usage: required
> > > > +         Value type: <phandle>
> > > > +         Definition: a phandle to the cpu node that corresponds to
> > > > +                     the thread node.
> > >
> > >
> > > According to the ePAPR, threads are represented by an array of ids for
> > > reg property, not another cpu node. Why the deviation.
> >
> > It is not a cpu node, it is a phandle property named cpu. Can you point
> > me to the ePAPR section where threads bindings are described please ? I have
> > not managed to find these details, I am reading version 1.0.
> 
> For cpu/reg:
> 
> [1]     If a CPU supports more than one thread (i.e. multiple streams of
>         execution) the reg property is an array with 1 element per
>         thread. The #address-cells on the /cpus node specifies how many
>         cells each element of the array takes. Software can determine
>         the number of threads by dividing the size of reg by the parent
>         node's #address-cells.
> 
> I had not previously been aware of this, but I see no reason not to
> follow this convention.

I don't see a reason either, but this changes the current cpu node bindings
for ARM. On the upside there are no SMT ARM platforms out there, so no
backward compatibility to worry about.

This would reduce the topology problem to where cluster nodes should be
defined, either in the cpus node or a separate node (ie cpu-map :-)).

> Also:
> [2]     If other more complex CPU topographies are designed, the binding
>         for the CPU must describe the topography
> 
> 
> That's rather less helpful, but the suggestion is clear enough in that
> such information should be in the cpu node and specific to that CPU's
> binding.  For ARM, we can have some global extensions to the CPU node.
> 
> The problems start when you want to refer to clusters and groups of
> CPUs from other nodes.  Only individual cpu nodes can be places in
> the cpus node, so there is no node for a phandle to point at.
> 
> If you want to describe how other things like power, clock and
> coherency domains map to clusters and larger entities, things could
> get pretty awkward.
> 
> Keeping the topology description separate allows all topological entities
> to appear as addressable entities in the DT; otherwise, a cryptic
> convention is needed.
> 
> 
> Hybrid approaches might be possible, putting cpu nodes into /cpus, and
> giving them a "parent" property where appropriate pointing at the
> relevant cluster node, which we put elsewhere in the DT.

That's what I did, with a couple of twists:

http://lists.infradead.org/pipermail/linux-arm-kernel/2012-January/080873.html

I have no preference, time to make a decision though.

> I'm not sure whether any of these approaches is an awful lot less ugly
> or more easy to handle than what it currently proposed though.

+1

> The global binding for all ARM CPUs would specify that the topology
> is described by /cpu-map and its associated binding.  For my
> interpretation of [2], this is a compliant approach.  ePAPR does not
> specify _how_ the cpu node binding achieves a description of the
> topography, just that it must achieve it.  There's no statement to
> say that it must not involve other nodes or bindings.

Again, I think it all boils down to deciding where cluster nodes should
live.

More opinions ?

Thx,
Lorenzo



From festevam at gmail.com  Fri Apr 12 07:48:12 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Fri, 12 Apr 2013 08:48:12 -0300
Subject: [PATCH 2/3] ARM:DTS:MVF600: add basic device tree source
In-Reply-To: <1365749825-20601-3-git-send-email-b35083@freescale.com>
References: <1365749825-20601-1-git-send-email-b35083@freescale.com>
 <1365749825-20601-3-git-send-email-b35083@freescale.com>
Message-ID: <CAOMZO5AwBXqBy8jAwLFEpbGh8FSVUKi_r-fZyY=ASwp=ZFb8MQ@mail.gmail.com>

On Fri, Apr 12, 2013 at 3:57 AM, Jingchang Lu <b35083 at freescale.com> wrote:
> This patch adds basic device tree source for Freescale
> Vybrid Family platform and Tower development board.
>
> Signed-off-by: Xiaochun Li <b41219 at freescale.com>
> Signed-off-by: Jingchang Lu <b35083 at freescale.com>
> ---
>  arch/arm/boot/dts/imx-mvf600.dtsi   | 442 ++++++++++++++++++++++++++++++++++++
>  arch/arm/boot/dts/imx-mvf600twr.dts |  82 +++++++
>  2 files changed, 524 insertions(+)
>  create mode 100644 arch/arm/boot/dts/imx-mvf600.dtsi
>  create mode 100644 arch/arm/boot/dts/imx-mvf600twr.dts

Why add the 'imx' prefix here?

Wouldn't 'vybrid' makes more sense?


From prabhakar.csengg at gmail.com  Fri Apr 12 07:50:17 2013
From: prabhakar.csengg at gmail.com (Prabhakar Lad)
Date: Fri, 12 Apr 2013 17:20:17 +0530
Subject: [GIT PULL FOR v3.10] DaVinci media cleanups + Updates
In-Reply-To: <CA+V-a8u+jNizu8EFfmwwh6kSr913n1JAFkx7r3_MfXrCyWnG0g@mail.gmail.com>
References: <CA+V-a8sko61y73odE5efJWwqYyMkBqM7_FPrs7Uvh7sdtBsGvA@mail.gmail.com>
 <CA+V-a8u+jNizu8EFfmwwh6kSr913n1JAFkx7r3_MfXrCyWnG0g@mail.gmail.com>
Message-ID: <CA+V-a8vW50McasFWQJRquvBj=vf5oQeOnHC8eSFjBFUYm_M2eA@mail.gmail.com>

Hi Hans/Mauro,

Ahh here is the final pull request hopefully I wont add anymore :)
sorry for inconvenience,
had to add on more patch at the final moment. Following is the fresh
pull request.
Let me know if replying on top if it is OK or if if you want a fresh mail.

Note: All the ARM platform changes have been acked by its maintainer.

Regards,
--Prabhakar

The following changes since commit 81e096c8ac6a064854c2157e0bf802dc4906678c:

  [media] budget: Add support for Philips Semi Sylt PCI ref. design
(2013-04-08 07:28:01 -0300)

are available in the git repository at:
  git://linuxtv.org/mhadli/v4l-dvb-davinci_devices.git for_v3.10

Lad, Prabhakar (9):
      davinci: vpif: add pm_runtime support
      media: davinci: vpss: enable vpss clocks
      media: davinci: vpbe: venc: move the enabling of vpss clocks to driver
      davinic: vpss: trivial cleanup
      ARM: davinci: dm365: add support for v4l2 video display
      ARM: davinci: dm365 EVM: add support for VPBE display
      ARM: davinci: dm355: add support for v4l2 video display
      ARM: davinci: dm355 EVM: add support for VPBE display
      ARM: daVinci: dm644x/dm355/dm365: replace V4L2_STD_525_60/625_50
with V4L2_STD_NTSC/PAL

Sekhar Nori (1):
      media: davinci: kconfig: fix incorrect selects

 arch/arm/mach-davinci/board-dm355-evm.c      |   71 +++++++++-
 arch/arm/mach-davinci/board-dm365-evm.c      |  166 ++++++++++++++++++++++-
 arch/arm/mach-davinci/board-dm644x-evm.c     |    4 +-
 arch/arm/mach-davinci/davinci.h              |   11 ++-
 arch/arm/mach-davinci/dm355.c                |  174 ++++++++++++++++++++++--
 arch/arm/mach-davinci/dm365.c                |  195 +++++++++++++++++++++++---
 arch/arm/mach-davinci/dm644x.c               |    9 +-
 arch/arm/mach-davinci/pm_domain.c            |    2 +-
 drivers/media/platform/davinci/Kconfig       |  103 +++++---------
 drivers/media/platform/davinci/Makefile      |   17 +--
 drivers/media/platform/davinci/dm355_ccdc.c  |   39 +-----
 drivers/media/platform/davinci/dm644x_ccdc.c |   44 ------
 drivers/media/platform/davinci/isif.c        |   28 +---
 drivers/media/platform/davinci/vpbe_venc.c   |   25 ++++
 drivers/media/platform/davinci/vpif.c        |   24 +---
 drivers/media/platform/davinci/vpss.c        |   36 ++++-
 16 files changed, 694 insertions(+), 254 deletions(-)


From amit.daniel at samsung.com  Fri Apr 12 07:51:40 2013
From: amit.daniel at samsung.com (amit daniel kachhap)
Date: Fri, 12 Apr 2013 17:21:40 +0530
Subject: [RESEND PATCH V6 1/4] cpufreq: exynos: Add cpufreq driver for
 exynos5440
In-Reply-To: <1586707.acL064pYmb@vostro.rjw.lan>
References: <CAKohpo=t_YTCTRCfnwQ+GPF=frsTGDigT3RZHJuVQ+R+YZU7Hg@mail.gmail.com>
 <1365415054-30771-1-git-send-email-amit.daniel@samsung.com>
 <CAGo_u6oZM0K8XDMtmXKFyoGy2qf+-HSPvU0EMangM5Jj_prKsA@mail.gmail.com>
 <1586707.acL064pYmb@vostro.rjw.lan>
Message-ID: <CADGdYn4qJRuLz8=PoXNRRwaNpKO92UshuiQTaK6W6Jj4p79T1A@mail.gmail.com>

Hi Rafael,

On Fri, Apr 12, 2013 at 4:49 PM, Rafael J. Wysocki <rjw at sisk.pl> wrote:
> On Thursday, April 11, 2013 06:23:52 PM Nishanth Menon wrote:
>> Hi,
>> On Mon, Apr 8, 2013 at 4:57 AM, Amit Daniel Kachhap
>> <amit.daniel at samsung.com> wrote:
>> > +
>> > +static int init_div_table(void)
>> > +{
>> > +       struct cpufreq_frequency_table *freq_tbl = dvfs_info->freq_table;
>> > +       unsigned int tmp, clk_div, ema_div, freq, volt_id;
>> > +       int i = 0;
>> > +       struct opp *opp;
>> > +
>> > +       for (i = 0; freq_tbl[i].frequency != CPUFREQ_TABLE_END; i++) {
>> > +
>> > +               opp = opp_find_freq_exact(dvfs_info->dev,
>> > +                                       freq_tbl[i].frequency * 1000, true);
>> > +               if (IS_ERR(opp)) {
>> > +                       dev_err(dvfs_info->dev,
>> > +                               "failed to find valid OPP for %u KHZ\n",
>> > +                               freq_tbl[i].frequency);
>> > +                       return PTR_ERR(opp);
>> > +               }
>> please use RCU read locks.
>>
>> > +
>> > +               freq = freq_tbl[i].frequency / 1000; /* In MHZ */
>> > +               clk_div = ((freq / CPU_DIV_FREQ_MAX) & P0_7_CPUCLKDEV_MASK)
>> > +                                       << P0_7_CPUCLKDEV_SHIFT;
>> > +               clk_div |= ((freq / CPU_ATB_FREQ_MAX) & P0_7_ATBCLKDEV_MASK)
>> > +                                       << P0_7_ATBCLKDEV_SHIFT;
>> > +               clk_div |= ((freq / CPU_DBG_FREQ_MAX) & P0_7_CSCLKDEV_MASK)
>> > +                                       << P0_7_CSCLKDEV_SHIFT;
>> > +
>> > +               /* Calculate EMA */
>> > +               volt_id = opp_get_voltage(opp);
>> Please use RCU read locks as documented for OPP library.
>
> Argh.  I overlooked that and the series has been applied already.  Care to send
> a fix against linux-pm.git/linux-next?

Will submit a patch with RCU lock changes.

Thanks,
Amit Daniel
>
> Rafael
>
>
> --
> I speak only for myself.
> Rafael J. Wysocki, Intel Open Source Technology Center.
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From gregory.clement at free-electrons.com  Fri Apr 12 07:57:43 2013
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Fri, 12 Apr 2013 13:57:43 +0200
Subject: [PATCH v3] clk: add device tree fixed-factor-clock binding support
Message-ID: <1365767864-7829-1-git-send-email-gregory.clement@free-electrons.com>

Hi,

Since august this patch finally find a user:
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/arch/arc/boot/dts/abilis_*.dtsi.
So I resusrected this patch with small changed suggested by Christian
Ruppert.

Mike,
if you still agree with this patch, you can apply it.
It was based on 3.9-rc6 but it can also be applied on clk-next
without any conflict.

Changelog:
v2 -> v3

- Updating the binding documentation bu using clock-div and clock-mul
  instead of div and mul
- Adding the tested-by tag from by Christian Ruppert

v1 -> v2
- Adding CLK_OF_DECLARE
- Using IS_ERR to test the clk value

Thanks,

Gregory CLEMENT (1):
  clk: add device tree fixed-factor-clock binding support

 .../bindings/clock/fixed-factor-clock.txt          |   24 +++++++++++++
 drivers/clk/clk-fixed-factor.c                     |   36 ++++++++++++++++++++
 include/linux/clk-provider.h                       |    2 ++
 3 files changed, 62 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/fixed-factor-clock.txt

-- 
1.7.9.5



From gregory.clement at free-electrons.com  Fri Apr 12 07:57:44 2013
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Fri, 12 Apr 2013 13:57:44 +0200
Subject: [PATCH v3] clk: add device tree fixed-factor-clock binding support
In-Reply-To: <1365767864-7829-1-git-send-email-gregory.clement@free-electrons.com>
References: <1365767864-7829-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1365767864-7829-2-git-send-email-gregory.clement@free-electrons.com>

Add support for DT "fixed-factor-clock" binding to the common fixed
factor clock support.

Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
Tested-by: Christian Ruppert <christian.ruppert at abilis.com>
---
 .../bindings/clock/fixed-factor-clock.txt          |   24 +++++++++++++
 drivers/clk/clk-fixed-factor.c                     |   36 ++++++++++++++++++++
 include/linux/clk-provider.h                       |    2 ++
 3 files changed, 62 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/fixed-factor-clock.txt

diff --git a/Documentation/devicetree/bindings/clock/fixed-factor-clock.txt b/Documentation/devicetree/bindings/clock/fixed-factor-clock.txt
new file mode 100644
index 0000000..5757f9a
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/fixed-factor-clock.txt
@@ -0,0 +1,24 @@
+Binding for simple fixed factor rate clock sources.
+
+This binding uses the common clock binding[1].
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties:
+- compatible : shall be "fixed-factor-clock".
+- #clock-cells : from common clock binding; shall be set to 0.
+- clock-div: fixed divider.
+- clock-mult: fixed multiplier.
+- clocks: parent clock.
+
+Optional properties:
+- clock-output-names : From common clock binding.
+
+Example:
+	clock {
+		compatible = "fixed-factor-clock";
+		clocks = <&parentclk>;
+		#clock-cells = <0>;
+		div = <2>;
+		mult = <1>;
+	};
diff --git a/drivers/clk/clk-fixed-factor.c b/drivers/clk/clk-fixed-factor.c
index 1ef271e..9ff7d51 100644
--- a/drivers/clk/clk-fixed-factor.c
+++ b/drivers/clk/clk-fixed-factor.c
@@ -11,6 +11,7 @@
 #include <linux/clk-provider.h>
 #include <linux/slab.h>
 #include <linux/err.h>
+#include <linux/of.h>
 
 /*
  * DOC: basic fixed multiplier and divider clock that cannot gate
@@ -96,3 +97,38 @@ struct clk *clk_register_fixed_factor(struct device *dev, const char *name,
 
 	return clk;
 }
+#ifdef CONFIG_OF
+/**
+ * of_fixed_factor_clk_setup() - Setup function for simple fixed factor clock
+ */
+void __init of_fixed_factor_clk_setup(struct device_node *node)
+{
+	struct clk *clk;
+	const char *clk_name = node->name;
+	const char *parent_name;
+	u32 div, mult;
+
+	if (of_property_read_u32(node, "clock-div", &div)) {
+		pr_err("%s Fixed factor clock <%s> must have a clock-div property\n",
+			__func__, node->name);
+		return;
+	}
+
+	if (of_property_read_u32(node, "clock-mult", &mult)) {
+		pr_err("%s Fixed factor clock <%s> must have a clokc-mult property\n",
+			__func__, node->name);
+		return;
+	}
+
+	of_property_read_string(node, "clock-output-names", &clk_name);
+	parent_name = of_clk_get_parent_name(node, 0);
+
+	clk = clk_register_fixed_factor(NULL, clk_name, parent_name, 0,
+					mult, div);
+	if (!IS_ERR(clk))
+		of_clk_add_provider(node, of_clk_src_simple_get, clk);
+}
+EXPORT_SYMBOL_GPL(of_fixed_factor_clk_setup);
+CLK_OF_DECLARE(fixed_factor_clk, "fixed-factor-clock",
+		of_fixed_factor_clk_setup);
+#endif
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 7f197d7..7ea501b 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -325,6 +325,8 @@ struct clk *clk_register_fixed_factor(struct device *dev, const char *name,
 		const char *parent_name, unsigned long flags,
 		unsigned int mult, unsigned int div);
 
+void of_fixed_factor_clk_setup(struct device_node *node);
+
 /**
  * clk_register - allocate a new clock, register it and return an opaque cookie
  * @dev: device that is registering this clock
-- 
1.7.9.5



From andrew.murray at arm.com  Fri Apr 12 08:05:38 2013
From: andrew.murray at arm.com (Andrew Murray)
Date: Fri, 12 Apr 2013 13:05:38 +0100
Subject: [PATCH] ARM: pci: pass a parent to pci_common_init()
In-Reply-To: <201304121326.56030.arnd@arndb.de>
References: <1365719096-11639-1-git-send-email-linus.walleij@linaro.org>
 <201304121326.56030.arnd@arndb.de>
Message-ID: <20130412120538.GA32488@arm.com>

On Fri, Apr 12, 2013 at 12:26:55PM +0100, Arnd Bergmann wrote:
> On Friday 12 April 2013, Linus Walleij wrote:
> > When working with device tree support for PCI on ARM you run
> > into a problem when mapping IRQs from the device tree irqmaps:
> > doing this the code in drivers/of/of_pci_irq.c will try to
> > find the OF node on the root bridge and this fails, because
> > bus->dev.of_node is NULL, and that in turn boils down to
> > the fact that pci_set_bus_of_node() has called
> > pcibios_get_phb_of_node() from drivers/pci/of.c to obtain
> > the OF node of the bridge or its parent and none is set
> > and thus NULL is returned.
> > 
> > Fix this by adding an additional parent argument when
> > registering PCI bridges on the ARM architecture using the
> > pci_common_init() call, and pass along this parent to
> > pci_scan_root_bus() called from pcibios_init_hw() in
> > bios32.c and voila: the IRQ mappings start working:
> > the OF node can be retrieved from the parent.
> > 
> > Currently all users are set to use NULL as argument to this
> > call, but subsequent patches to the Integrator/AP make use
> > of this facility to pass a parent.
> 
> Could you try making it a less invasive patch by renaming
> pci_common_init to something else and providing a wrapper
> like this?
> 
> static inline void pci_common_init(struct hw_pci *hw)
> {
> 	pci_common_init_dev(NULL, hw);
> }
> 
> That would avoid most of the churn and get the same result.
> 
> 	Arnd
>

I would also be happy with this. Though alternatively could you
not just add a struct device to hw_pci? Then change pcibios_init_hw
to use hw->device instead of NULL?

Andrew Murray


From nicolas.ferre at atmel.com  Fri Apr 12 08:09:22 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Fri, 12 Apr 2013 14:09:22 +0200
Subject: [rtc-linux] Re: [PATCH v2 0/5] ARM: at91: fix hanged boot
In-Reply-To: <20130412093333.GF21305@localhost>
References: <20130311180611.GF8797@localhost>
 <1363025279-17615-1-git-send-email-jhovold@gmail.com>
 <20130411155505.GD21305@localhost> <20130411165414.GC25242@game.jcrosoft.org>
 <20130412093333.GF21305@localhost>
Message-ID: <5167F972.2000707@atmel.com>

On 04/12/2013 11:33 AM, Johan Hovold :
> On Thu, Apr 11, 2013 at 06:54:14PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
>> On 17:55 Thu 11 Apr     , Johan Hovold wrote:
>>> On Mon, Mar 11, 2013 at 07:07:54PM +0100, Johan Hovold wrote:
>>>> These patches fix a few severe issues affecting most AT91 SOCs where
>>>> boot can hang after a non-general reset, and where the only way to get
>>>> the system booting again is to do a general reset -- something which
>>>> could require physically removing any backup battery.
>>>
>>> Have you had time to look at these patches yet, Nicolas?
>>>
>>> I don't think not having decided on the path forward for DT-support for
>>> rtc-at91sam9 needs to be a blocker. The rtt-nodes will be needed in any
>>> case.
>>>
>>> I could respin the series on top of the DT-patch for rtc-at91rm9200, and
>>> add interrupt and status-disabled properties to the DT-nodes as well.
>> for this this is still a no go
>>
>> this way too much ugly
> 
> I understand that you prefer fixing every bootloader. I was just making
> sure everyone agrees that that is the best solution.
> 
> The two interrupt masks has to be cleared before the kernel enables the
> system interrupt; either it needs to be done by the bootloader or by the
> at91 arch code.
> 
> The various bootloaders may not know anything about RTT or RTC, but
> have all made sure interrupts are disabled before executing the kernel.
> That is, they have fulfilled the requirement that interrupts must be
> disabled.
> 
> So the trade-off seems to be: Either we fix this once and for all using
> the infrastructure already in place in the kernel (DT), or risk further
> (apparently) bricked systems as there are bound to be bootloaders that
> won't get updated.

Note that I didn't read your patch series yet, so I am not commenting on
the implementation.

BUT, from my experience with customers facing this issue, I do thing
that we must provide a solution (even in Linux kernel itself).


> [...]
> 
>>>> The problems stem from the fact that the RTC and RTT-peripherals are
>>>> powered by backup power (VDDBU) and are not reset on wake-up, user,
>>>> watchdog or software reset. Consequently, RTC and RTT-alarms and their
>>>> interrupts may be enabled at boot, leading to a system lock-up when an
>>>> interrupt arrives on the shared system-interrupt line before the
>>>> appropriate handler (e.g. RTC-driver) has been installed.
>>>>
>>>> The easiest way to trigger this is to simply wake up from an RTC-alarm
>>>> on at91sam9g45. The RTC-driver currently does not disable interrupts at
>>>> shutdown so even after a clean shut-down the system will always hang
>>>> after waking up.
>>>>
>>>> The first patch fixes this very general case of RTC-wake up after a
>>>> clean shutdown in the RTC-driver and is marked for stable as it is
>>>> perfectly straight-forward. [ Note that the other, RTT-based, AT91
>>>> RTC-driver already disables its interrupts at shutdown. ]
> 
> And what about this patch? If it's decided that every bootloader needs
> to be updated, then perhaps it's better to risk bricked systems also
> after a clean shutdown to enforce those updates? Should we then remove
> the corresponding disable of interrupts at shutdown from the rtc-at91sam9
> driver by the same logic?
> 
>>>> The more general problem can be triggered, for example, by doing a
>>>> user-reset while updating the RTC-time or if an RTC or RTT-alarm goes
>>>> off after a non-clean shutdown.
>>>>
>>>> To fix this I propose that arch-code should mask the relevant interrupts
>>>> before enabling the system interrupt at early boot, and this is what
>>>> the fifth patch does. To access the RTC-registers I choose to revert a
>>>> recent patch that moved the register definitions to drivers/rtc.
>>>>
>>>> Arguably, the relevant interrupts could also be disabled in bootloaders,
>>>> but I suggest fixing it in the kernel once and for all.
> 
> Thanks,
> Johan
> 
> 


-- 
Nicolas Ferre


From mfuzzey at parkeon.com  Fri Apr 12 08:13:29 2013
From: mfuzzey at parkeon.com (Martin Fuzzey)
Date: Fri, 12 Apr 2013 14:13:29 +0200
Subject: [PATCH] ARM: i.MX5 Allow DT clock providers
Message-ID: <20130412121329.3965.30768.stgit@localhost>

Currently clock providers defined in the DT are not registered
on i.MX5 platforms since of_clk_init() is not called.

This is not a problem for the SOC's own clocks, which are registered
in code,  but prevents the DT being used to define clocks for external
hardware.

Fix this by calling of_clk_init() and actually using the DT to obtain
the 4 SOC fixed clocks.
These are already defined in the DT but were previously just used to
manually obtain the rate.

Fall back to the old scheme for non DT platforms.

Signed-off-by: Martin Fuzzey <mfuzzey at parkeon.com>
---
 arch/arm/mach-imx/clk-imx51-imx53.c |   75 +++++++++++++++++++----------------
 1 files changed, 41 insertions(+), 34 deletions(-)

diff --git a/arch/arm/mach-imx/clk-imx51-imx53.c b/arch/arm/mach-imx/clk-imx51-imx53.c
index 3228b4e..342c8b3 100644
--- a/arch/arm/mach-imx/clk-imx51-imx53.c
+++ b/arch/arm/mach-imx/clk-imx51-imx53.c
@@ -117,17 +117,52 @@ enum imx5_clks {
 static struct clk *clk[clk_max];
 static struct clk_onecell_data clk_data;
 
+
+static struct clk * __init mx5_obtain_fixed_clock_from_dt(const char *name)
+{
+#ifdef CONFIG_OF
+	char compatible[20];
+	struct of_phandle_args phandle = {0};
+	struct clk *clk = NULL;
+
+	scnprintf(compatible, sizeof(compatible), "fsl,imx-%s", name);
+	phandle.np = of_find_compatible_node(NULL, NULL, compatible);
+	if (phandle.np) {
+		clk = of_clk_get_from_provider(&phandle);
+		of_node_put(phandle.np);
+	}
+	return clk;
+#else
+	return NULL;
+#endif
+}
+
+static struct clk * __init mx5_obtain_fixed_clock(
+			const char *name, unsigned long rate)
+{
+	struct clk *clk;
+
+	clk = mx5_obtain_fixed_clock_from_dt(name);
+	if (IS_ERR_OR_NULL(clk))
+		clk = imx_clk_fixed(name, rate);
+	return clk;
+}
+
 static void __init mx5_clocks_common_init(unsigned long rate_ckil,
 		unsigned long rate_osc, unsigned long rate_ckih1,
 		unsigned long rate_ckih2)
 {
 	int i;
 
+#ifdef CONFIG_OF
+	of_clk_init(NULL);
+#endif
+
 	clk[dummy] = imx_clk_fixed("dummy", 0);
-	clk[ckil] = imx_clk_fixed("ckil", rate_ckil);
-	clk[osc] = imx_clk_fixed("osc", rate_osc);
-	clk[ckih1] = imx_clk_fixed("ckih1", rate_ckih1);
-	clk[ckih2] = imx_clk_fixed("ckih2", rate_ckih2);
+	clk[ckil] = mx5_obtain_fixed_clock("ckil", rate_ckil);
+	clk[osc] = mx5_obtain_fixed_clock("osc", rate_osc);
+	clk[ckih1] = mx5_obtain_fixed_clock("ckih1", rate_ckih1);
+	clk[ckih2] = mx5_obtain_fixed_clock("ckih2", rate_ckih2);
 
 	clk[lp_apm] = imx_clk_mux("lp_apm", MXC_CCM_CCSR, 9, 1,
 				lp_apm_sel, ARRAY_SIZE(lp_apm_sel));
@@ -540,41 +575,13 @@ int __init mx53_clocks_init(unsigned long rate_ckil, unsigned long rate_osc,
 }
 
 #ifdef CONFIG_OF
-static void __init clk_get_freq_dt(unsigned long *ckil, unsigned long *osc,
-				   unsigned long *ckih1, unsigned long *ckih2)
-{
-	struct device_node *np;
-
-	/* retrieve the freqency of fixed clocks from device tree */
-	for_each_compatible_node(np, NULL, "fixed-clock") {
-		u32 rate;
-		if (of_property_read_u32(np, "clock-frequency", &rate))
-			continue;
-
-		if (of_device_is_compatible(np, "fsl,imx-ckil"))
-			*ckil = rate;
-		else if (of_device_is_compatible(np, "fsl,imx-osc"))
-			*osc = rate;
-		else if (of_device_is_compatible(np, "fsl,imx-ckih1"))
-			*ckih1 = rate;
-		else if (of_device_is_compatible(np, "fsl,imx-ckih2"))
-			*ckih2 = rate;
-	}
-}
-
 int __init mx51_clocks_init_dt(void)
 {
-	unsigned long ckil, osc, ckih1, ckih2;
-
-	clk_get_freq_dt(&ckil, &osc, &ckih1, &ckih2);
-	return mx51_clocks_init(ckil, osc, ckih1, ckih2);
+	return mx51_clocks_init(0, 0, 0, 0);
 }
 
 int __init mx53_clocks_init_dt(void)
 {
-	unsigned long ckil, osc, ckih1, ckih2;
-
-	clk_get_freq_dt(&ckil, &osc, &ckih1, &ckih2);
-	return mx53_clocks_init(ckil, osc, ckih1, ckih2);
+	return mx53_clocks_init(0, 0, 0, 0);
 }
 #endif



From broonie at opensource.wolfsonmicro.com  Fri Apr 12 08:13:36 2013
From: broonie at opensource.wolfsonmicro.com (Mark Brown)
Date: Fri, 12 Apr 2013 13:13:36 +0100
Subject: [PATCH] ASoC: samsung: fix neo1973-wm8753 compilation
In-Reply-To: <201304112102.43896.heiko@sntech.de>
References: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
 <201304111908.42532.arnd@arndb.de>
 <20130411171938.GS9243@opensource.wolfsonmicro.com>
 <201304112102.43896.heiko@sntech.de>
Message-ID: <20130412121320.GX9243@opensource.wolfsonmicro.com>

On Thu, Apr 11, 2013 at 09:02:43PM +0200, Heiko St?bner wrote:
> Commit b2ca78717cea (ARM: S3C24XX: make gta02.h local) already replaced
> the GTA02_GPIO_* constants in neo1973-wm8753.c but forgot to remove the
> inclusion of mach/gta02.h before moving the file out of mach/.

Applied, thanks.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130412/6758b9e0/attachment.sig>

From oku at iki.fi  Fri Apr 12 08:14:44 2013
From: oku at iki.fi (Jyri Sarha)
Date: Fri, 12 Apr 2013 15:14:44 +0300
Subject: [PATCH] ARM: OMAP4+:
 =?UTF-8?Q?omap=32plus=5Fdefconfig=3A=20Enable=20?=
 =?UTF-8?Q?audio=20via=20TWL=36=30=34=30=20as=20module?=
In-Reply-To: <1365584880-25810-1-git-send-email-peter.ujfalusi@ti.com>
References: <1365584880-25810-1-git-send-email-peter.ujfalusi@ti.com>
Message-ID: <acf32629312b1315da0d04598a757673@mail.kapsi.fi>

On Wed, 10 Apr 2013 11:08:00 +0200, Peter Ujfalusi <peter.ujfalusi at ti.com>
wrote:
> Boards supported upstream all use TWL6040 as audio codec, enable the
common
> ASoC machine driver by default for them.
> 
> Signed-off-by: Peter Ujfalusi <peter.ujfalusi at ti.com>
Tested-by: Jyri Sarha <jsarha at ti.com>

Brings a working PCM for TWL6040 trough McPDM legacy port on top of
8.3-rc3 for my Blaze and Panda.
> ---
>  arch/arm/configs/omap2plus_defconfig | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/arch/arm/configs/omap2plus_defconfig
> b/arch/arm/configs/omap2plus_defconfig
> index bd07864..eea501c 100644
> --- a/arch/arm/configs/omap2plus_defconfig
> +++ b/arch/arm/configs/omap2plus_defconfig
> @@ -152,6 +152,7 @@ CONFIG_OMAP_WATCHDOG=y
>  CONFIG_TWL4030_WATCHDOG=y
>  CONFIG_MFD_TPS65217=y
>  CONFIG_MFD_TPS65910=y
> +CONFIG_TWL6040_CORE=y
>  CONFIG_REGULATOR_TWL4030=y
>  CONFIG_REGULATOR_TPS65023=y
>  CONFIG_REGULATOR_TPS6507X=y
> @@ -194,6 +195,7 @@ CONFIG_SND_USB_AUDIO=m
>  CONFIG_SND_SOC=m
>  CONFIG_SND_OMAP_SOC=m
>  CONFIG_SND_OMAP_SOC_OMAP_TWL4030=m
> +CONFIG_SND_OMAP_SOC_OMAP_ABE_TWL6040=m
>  CONFIG_SND_OMAP_SOC_OMAP3_PANDORA=m
>  CONFIG_USB=y
>  CONFIG_USB_DEBUG=y


From m.szyprowski at samsung.com  Fri Apr 12 08:28:59 2013
From: m.szyprowski at samsung.com (Marek Szyprowski)
Date: Fri, 12 Apr 2013 14:28:59 +0200
Subject: [RFC/PATCH v2 2/2] drivers: dma-contiguous: add initialization
 from device tree
In-Reply-To: <5166F932.9000003@codeaurora.org>
References: <1365679330-2514-1-git-send-email-m.szyprowski@samsung.com>
 <1365679330-2514-3-git-send-email-m.szyprowski@samsung.com>
 <5166F932.9000003@codeaurora.org>
Message-ID: <5167FE0B.80605@samsung.com>

Hi Laura,

Thanks for your thorough review! I will fix all the pointed issues once the
main point of this patch set (using /chosen/contiguous-memory for CMA DT
bindings) will be agreed and accepted.

On 4/11/2013 7:56 PM, Laura Abbott wrote:
> Hi,
>
> On 4/11/2013 4:22 AM, Marek Szyprowski wrote:
> ...
>> +
>> diff --git a/drivers/base/dma-contiguous.c 
>> b/drivers/base/dma-contiguous.c
>> index 01fe743..6a8abab 100644
>> --- a/drivers/base/dma-contiguous.c
>> +++ b/drivers/base/dma-contiguous.c
>> @@ -24,6 +24,9 @@
>>
>>   #include <linux/memblock.h>
>>   #include <linux/err.h>
>> +#include <linux/of.h>
>> +#include <linux/of_fdt.h>
>> +#include <linux/of_platform.h>
>>   #include <linux/mm.h>
>>   #include <linux/mutex.h>
>>   #include <linux/page-isolation.h>
>> @@ -37,6 +40,7 @@ struct cma {
>>       unsigned long    base_pfn;
>>       unsigned long    count;
>>       unsigned long    *bitmap;
>> +    char        full_name[32];
>>   };
>>
>>   static DEFINE_MUTEX(cma_mutex);
>> @@ -133,6 +137,53 @@ static __init int cma_activate_area(struct cma 
>> *cma)
>>       return 0;
>>   }
>>
>> +/*****************************************************************************/ 
>>
>> +
>> +#ifdef CONFIG_OF
>> +int __init cma_fdt_scan(unsigned long node, const char *uname,
>> +                int depth, void *data)
>> +{
>> +    static int level;
>> +    phys_addr_t base, size;
>> +    unsigned long len;
>> +    struct cma *cma;
>> +    __be32 *prop;
>> +
>> +    if (depth == 1 && strcmp(uname, "chosen") == 0) {
>> +        level = depth;
>> +        return 0;
>> +    }
>> +
>> +    if (depth == 2 && strcmp(uname, "contiguous-memory") == 0) {
>> +        level = depth;
>> +        return 0;
>> +    }
>> +
>> +    if (level != 2 || depth != 3 || strncmp(uname, "region@", 7) != 0)
>> +        return 0;
>> +
>
> Requiring the region@ label does not work if you want two dynamically 
> placed regions (i.e. two region at 0). The devicetree will take the last 
> region at 0 entry and ignore all the other ones


Hmm. You are right, I need different solution here to get it working 
with autoconfigured base address.

>> +    prop = of_get_flat_dt_prop(node, "reg", &len);
>> +    if (!prop || (len != 2 * sizeof(unsigned long)))
>> +        return 0;
>> +
>> +    base = be32_to_cpu(prop[0]);
>> +    size = be32_to_cpu(prop[1]);
>> +
>> +    pr_info("Found %s, memory base %lx, size %ld MiB\n", uname,
>> +        (unsigned long)base, (unsigned long)size / SZ_1M);
>> +
>> +    dma_contiguous_reserve_area(size, base, 0, &cma);
>> +
>
> Need to check the return of dma_contiguous_reserve_area, else there is 
> an abort when trying to access cma->name on an error
>
>> +    strcpy(cma->full_name, uname);
>> +
>> +    if (of_get_flat_dt_prop(node, "linux,default-contiguous-region", 
>> NULL)) {
>> +
>> +        dma_contiguous_default_area = cma;
>> +    }
>> +    return 0;
>> +}
>> +#endif
>> +
>>   /**
>>    * dma_contiguous_reserve() - reserve area(s) for contiguous memory 
>> handling
>>    * @limit: End address of the reserved memory (optional, 0 for any).
>
>
> if the contiguous region isn't set via devicetree, 
> default_area->full_name needs to be set in dma_contiguous_reserve, 
> else we get wrong associations in scan_cma_node.
>
>> @@ -149,6 +200,10 @@ void __init dma_contiguous_reserve(phys_addr_t 
>> limit)
>>
>>       pr_debug("%s(limit %08lx)\n", __func__, (unsigned long)limit);
>>
>> +#ifdef CONFIG_OF
>> +    of_scan_flat_dt(cma_fdt_scan, NULL);
>> +#endif
>> +
>>       if (size_cmdline != -1) {
>>           sel_size = size_cmdline;
>>       } else {
>> @@ -265,6 +320,71 @@ int __init dma_contiguous_add_device(struct 
>> device *dev, struct cma *cma)
>>       return 0;
>>   }
>>
>> +#ifdef CONFIG_OF
>> +static struct cma_map {
>> +    struct cma *cma;
>> +    struct device_node *node;
>> +} cma_maps[MAX_CMA_AREAS];
>> +static unsigned cma_map_count;
>> +
>> +static void cma_assign_device_from_dt(struct device *dev)
>> +{
>> +    int i;
>> +    for (i=0; i<cma_map_count; i++) {
>> +        if (cma_maps[i].node == dev->of_node) {
>> +            dev_set_cma_area(dev, cma_maps[i].cma);
>> +            pr_info("Assigned CMA %s to %s device\n",
>> +                cma_maps[i].cma->full_name,
>> +                dev_name(dev));
>> +        }
>> +    }
>> +}
>> +
>> +static int cma_device_init_notifier_call(struct notifier_block *nb,
>> +                     unsigned long event, void *data)
>> +{
>> +    struct device *dev = data;
>> +    if (event == BUS_NOTIFY_ADD_DEVICE && dev->of_node)
>> +        cma_assign_device_from_dt(dev);
>> +    return NOTIFY_DONE;
>> +}
>> +
>> +static struct notifier_block cma_dev_init_nb = {
>> +    .notifier_call = cma_device_init_notifier_call,
>> +};
>> +
>> +void scan_cma_nodes(void)
>> +{
>> +    struct device_node *parent = 
>> of_find_node_by_path("/chosen/contiguous-memory");
>> +    struct device_node *child;
>> +
>> +    if (!parent)
>> +        return;
>> +
>> +    for_each_child_of_node(parent, child) {
>> +        struct cma *cma = NULL;
>> +        int i;
>> +
>> +        for (i=0; i<cma_area_count; i++)
>> +            if (strstr(child->full_name, cma_areas[i].full_name))
>> +                cma = &cma_areas[i];
>
> break out of the loop once the area is found?
>
> Also, how will the code deal with region names that are substrings of 
> each other e.g.
>
> region at 1000000
> region at 10000000
>

Thanks for pointing this.

>> +        if (!cma)
>> +            continue;
>> +
>> +        for (i=0;; i++) {
>> +            struct device_node *node;
>> +            node = of_parse_phandle(child, "device", i);
>> +            if (!node)
>> +                break;
>> +
>> +            cma_maps[cma_map_count].cma = cma;
>> +            cma_maps[cma_map_count].node = node;
>> +            cma_map_count++;
>
> Bounds check cma_map_count against MAX_CMA_AREAS?
>
>> +        }
>> +    }
>> +}
>> +#endif
>> +
>>   static int __init cma_init_reserved_areas(void)
>>   {
>>       int i;
>> @@ -275,6 +395,10 @@ static int __init cma_init_reserved_areas(void)
>>               return ret;
>>       }
>>
>> +#ifdef CONFIG_OF
>> +    scan_cma_nodes();
>> +    bus_register_notifier(&platform_bus_type, &cma_dev_init_nb);
>> +#endif
>>       return 0;
>>   }
>>   core_initcall(cma_init_reserved_areas);
>>
>
> Thanks,
> Laura
>

Best regards
-- 
Marek Szyprowski
Samsung Poland R&D Center




From s.hauer at pengutronix.de  Fri Apr 12 08:30:54 2013
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Fri, 12 Apr 2013 14:30:54 +0200
Subject: [PATCH] tty/serial: add MVF uart driver support
In-Reply-To: <1365750655-3530-1-git-send-email-b35083@freescale.com>
References: <1365750655-3530-1-git-send-email-b35083@freescale.com>
Message-ID: <20130412123054.GE10373@pengutronix.de>

On Fri, Apr 12, 2013 at 03:10:55PM +0800, Jingchang Lu wrote:
> It adds Freescale Vybrid Family uart driver support
> 
> Signed-off-by: Jingchang Lu <b35083 at freescale.com>
> ---
> +++ b/drivers/tty/serial/mvf.c
> @@ -0,0 +1,1246 @@
> +/*
> + *  Driver for Freescale Vybrid Family serial ports
> + *
> + *  Based on drivers/tty/serial/imx.c
> + *
> + *  Copyright 2012-2013 Freescale Semiconductor, Inc.
> + *
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA

Another FSF address. Please remove.

> + *
> + */
> +
> +#if defined(CONFIG_SERIAL_MVF_CONSOLE) && defined(CONFIG_MAGIC_SYSRQ)
> +#define SUPPORT_SYSRQ
> +#endif
> +
> +#include <linux/module.h>
> +#include <linux/ioport.h>
> +#include <linux/init.h>
> +#include <linux/console.h>
> +#include <linux/sysrq.h>
> +#include <linux/platform_device.h>
> +#include <linux/tty.h>
> +#include <linux/tty_flip.h>
> +#include <linux/serial_core.h>
> +#include <linux/serial.h>
> +#include <linux/clk.h>
> +#include <linux/delay.h>
> +#include <linux/rational.h>
> +#include <linux/slab.h>
> +#include <linux/dma-mapping.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>
> +#include <linux/pinctrl/consumer.h>
> +#include <linux/io.h>
> +#include <asm/irq.h>
> +#include <linux/platform_data/serial-imx.h>
> +#include <linux/platform_data/dma-imx.h>
> +
> +/* All uart module registers for MVF is 8-bit width */
> +#define MXC_UARTBDH		0x00 /* Baud rate reg: high */
> +#define MXC_UARTBDL		0x01 /* Baud rate reg: low */
> +#define MXC_UARTCR1		0x02 /* Control reg 1 */
> +#define MXC_UARTCR2		0x03 /* Control reg 2 */
> +#define MXC_UARTSR1		0x04 /* Status reg 1 */
> +#define MXC_UARTSR2		0x05 /* Status reg 2 */
> +#define MXC_UARTCR3		0x06 /* Control reg 3 */
> +#define MXC_UARTDR		0x07 /* Data reg */
> +#define MXC_UARTMAR1		0x08 /* Match address reg 1 */
> +#define MXC_UARTMAR2		0x09 /* Match address reg 2 */
> +#define MXC_UARTCR4		0x0A /* Control reg 4 */
> +#define MXC_UARTCR5		0x0B /* Control reg 5 */
> +#define MXC_UARTEDR		0x0C /* Extended data reg */
> +#define MXC_UARTMODEM		0x0D /* Modem reg */
> +#define MXC_UARTIR		0x0E /* Infrared reg */
> +#define MXC_UARTPFIFO		0x10 /* FIFO parameter reg */
> +#define MXC_UARTCFIFO		0x11 /* FIFO control reg */
> +#define MXC_UARTSFIFO		0x12 /* FIFO status reg */
> +#define MXC_UARTTWFIFO		0x13 /* FIFO transmit watermark reg */
> +#define MXC_UARTTCFIFO		0x14 /* FIFO transmit count reg */
> +#define MXC_UARTRWFIFO		0x15 /* FIFO receive watermark reg */
> +#define MXC_UARTRCFIFO		0x16 /* FIFO receive count reg */
> +#define MXC_UARTC7816		0x18 /* 7816 control reg */
> +#define MXC_UARTIE7816		0x19 /* 7816 interrupt enable reg */
> +#define MXC_UARTIS7816		0x1A /* 7816 interrupt status reg */
> +#define MXC_UARTWP7816T0	0x1B /* 7816 wait parameter reg */
> +#define MXC_UARTWP7816T1	0x1B /* 7816 wait parameter reg */
> +#define MXC_UARTWN7816		0x1C /* 7816 wait N reg */
> +#define MXC_UARTWF7816		0x1D /* 7816 wait FD reg */
> +#define MXC_UARTET7816		0x1E /* 7816 error threshold reg */
> +#define MXC_UARTTL7816		0x1F /* 7816 transmit length reg */
> +#define MXC_UARTCR6		0x21 /* CEA709.1-B contrl reg */
> +#define MXC_UARTPCTH		0x22 /* CEA709.1-B packet cycle counter high */
> +#define MXC_UARTPCTL		0x23 /* CEA709.1-B packet cycle counter low */
> +#define MXC_UARTB1T		0x24 /* CEA709.1-B beta 1 time */
> +#define MXC_UARTSDTH		0x25 /* CEA709.1-B secondary delay timer high */
> +#define MXC_UARTSDTL		0x26 /* CEA709.1-B secondary delay timer low */
> +#define MXC_UARTPRE		0x27 /* CEA709.1-B preamble */
> +#define MXC_UARTTPL		0x28 /* CEA709.1-B transmit packet length */
> +#define MXC_UARTIE		0x29 /* CEA709.1-B transmit interrupt enable */
> +#define MXC_UARTSR3		0x2B /* CEA709.1-B status reg */
> +#define MXC_UARTSR4		0x2C /* CEA709.1-B status reg */
> +#define MXC_UARTRPL		0x2D /* CEA709.1-B received packet length */
> +#define MXC_UARTRPREL		0x2E /* CEA709.1-B received preamble length */
> +#define MXC_UARTCPW		0x2F /* CEA709.1-B collision pulse width */
> +#define MXC_UARTRIDT		0x30 /* CEA709.1-B receive indeterminate time */
> +#define MXC_UARTTIDT		0x31 /* CEA709.1-B transmit indeterminate time*/
> +
> +/* Bit definations of BDH */
> +#define MXC_UARTBDH_LBKDIE	0x80 /* LIN break detect interrupt enable */
> +#define MXC_UARTBDH_RXEDGIE	0x40 /* RxD input Active edge interrupt enable*/
> +#define MXC_UARTBDH_SBR_MASK	0x1f /* Uart baud rate high 5-bits */
> +/* Bit definations of CR1 */
> +#define MXC_UARTCR1_LOOPS	0x80 /* Loop mode select */
> +#define MXC_UARTCR1_RSRC	0x20 /* Receiver source select */
> +#define MXC_UARTCR1_M		0x10 /* 9-bit 8-bit mode select */
> +#define MXC_UARTCR1_WAKE	0x08 /* Receiver wakeup method */
> +#define MXC_UARTCR1_ILT		0x04 /* Idle line type */
> +#define MXC_UARTCR1_PE		0x02 /* Parity enable */
> +#define MXC_UARTCR1_PT		0x01 /* Parity type */
> +/* Bit definations of CR2 */
> +#define MXC_UARTCR2_TIE		0x80 /* Tx interrupt or DMA request enable */
> +#define MXC_UARTCR2_TCIE	0x40 /* Transmission complete int enable */
> +#define MXC_UARTCR2_RIE		0x20 /* Rx full int or DMA request enable */
> +#define MXC_UARTCR2_ILIE	0x10 /* Idle line interrupt enable */
> +#define MXC_UARTCR2_TE		0x08 /* Transmitter enable */
> +#define MXC_UARTCR2_RE		0x04 /* Receiver enable */
> +#define MXC_UARTCR2_RWU		0x02 /* Receiver wakeup control */
> +#define MXC_UARTCR2_SBK		0x01 /* Send break */
> +/* Bit definations of SR1 */
> +#define MXC_UARTSR1_TDRE	0x80 /* Tx data reg empty */
> +#define MXC_UARTSR1_TC		0x40 /* Transmit complete */
> +#define MXC_UARTSR1_RDRF	0x20 /* Rx data reg full */
> +#define MXC_UARTSR1_IDLE	0x10 /* Idle line flag */
> +#define MXC_UARTSR1_OR		0x08 /* Receiver overrun */
> +#define MXC_UARTSR1_NF		0x04 /* Noise flag */
> +#define MXC_UARTSR1_FE		0x02 /* Frame error */
> +#define MXC_UARTSR1_PE		0x01 /* Parity error */
> +/* Bit definations of SR2 */
> +#define MXC_UARTSR2_LBKDIF	0x80 /* LIN brk detect interrupt flag */
> +#define MXC_UARTSR2_RXEDGIF	0x40 /* RxD pin active edge interrupt flag */
> +#define MXC_UARTSR2_MSBF	0x20 /* MSB first */
> +#define MXC_UARTSR2_RXINV	0x10 /* Receive data inverted */
> +#define MXC_UARTSR2_RWUID	0x08 /* Receive wakeup idle detect */
> +#define MXC_UARTSR2_BRK13	0x04 /* Break transmit character length */
> +#define MXC_UARTSR2_LBKDE	0x02 /* LIN break detection enable */
> +#define MXC_UARTSR2_RAF		0x01 /* Receiver active flag */
> +/* Bit definations of CR3 */
> +#define MXC_UARTCR3_R8		0x80 /* Received bit8, for 9-bit data format */
> +#define MXC_UARTCR3_T8		0x40 /* transmit bit8, for 9-bit data format */
> +#define MXC_UARTCR3_TXDIR	0x20 /* Tx pin direction in single-wire mode */
> +#define MXC_UARTCR3_TXINV	0x10 /* Transmit data inversion */
> +#define MXC_UARTCR3_ORIE	0x08 /* Overrun error interrupt enable */
> +#define MXC_UARTCR3_NEIE	0x04 /* Noise error interrupt enable */
> +#define MXC_UARTCR3_FEIE	0x02 /* Framing error interrupt enable */
> +#define MXC_UARTCR3_PEIE	0x01 /* Parity errror interrupt enable */
> +/* Bit definations of CR4 */
> +#define MXC_UARTCR4_MAEN1	0x80 /* Match address mode enable 1 */
> +#define MXC_UARTCR4_MAEN2	0x40 /* Match address mode enable 2 */
> +#define MXC_UARTCR4_M10		0x20 /* 10-bit mode select */
> +#define MXC_UARTCR4_BRFA_MASK	0x1F /* Baud rate fine adjust */
> +#define MXC_UARTCR4_BRFA_OFF	0
> +/* Bit definations of CR5 */
> +#define MXC_UARTCR5_TDMAS	0x80 /* Transmitter DMA select */
> +#define MXC_UARTCR5_RDMAS	0x20 /* Receiver DMA select */
> +/* Bit definations of Modem */
> +#define MXC_UARTMODEM_RXRTSE	0x08 /* Enable receiver request-to-send */
> +#define MXC_UARTMODEM_TXRTSPOL	0x04 /* Select transmitter RTS polarity */
> +#define MXC_UARTMODEM_TXRTSE	0x02 /* Enable transmitter request-to-send */
> +#define MXC_UARTMODEM_TXCTSE	0x01 /* Enable transmitter CTS clear-to-send */
> +/* Bit definations of EDR */
> +#define MXC_UARTEDR_NOISY	0x80 /* Current dataword received with noise */
> +#define MXC_UARTEDR_PARITYE	0x40 /* Dataword received with parity error */
> +/* Bit definations of Infrared reg(IR) */
> +#define MXC_UARTIR_IREN		0x04 /* Infrared enable */
> +#define MXC_UARTIR_TNP_MASK	0x03 /* Transmitter narrow pluse */
> +#define MXC_UARTIR_TNP_OFF	0
> +/* Bit definations of FIFO parameter reg */
> +#define MXC_UARTPFIFO_TXFE	0x80 /* Transmit fifo enable */
> +#define MXC_UARTPFIFO_TXFIFOSIZE_MASK	0x7
> +#define MXC_UARTPFIFO_TXFIFOSIZE_OFF	4
> +#define MXC_UARTPFIFO_RXFE	0x08 /* Receiver fifo enable */
> +#define MXC_UARTPFIFO_RXFIFOSIZE_MASK	0x7
> +#define MXC_UARTPFIFO_RXFIFOSIZE_OFF	0
> +/* Bit definations of FIFO control reg */
> +#define MXC_UARTCFIFO_TXFLUSH	0x80 /* Transmit FIFO/buffer flush */
> +#define MXC_UARTCFIFO_RXFLUSH	0x40 /* Receive FIFO/buffer flush */
> +#define MXC_UARTCFIFO_RXOFE	0x04 /* Receive fifo overflow INT enable */
> +#define MXC_UARTCFIFO_TXOFE	0x02 /* Transmit fifo overflow INT enable */
> +#define MXC_UARTCFIFO_RXUFE	0x01 /* Receive fifo underflow INT enable */
> +/* Bit definations of FIFO status reg */
> +#define MXC_UARTSFIFO_TXEMPT	0x80 /* Transmit fifo/buffer empty */
> +#define MXC_UARTSFIFO_RXEMPT	0x40 /* Receive fifo/buffer empty */
> +#define MXC_UARTSFIFO_RXOF	0x04 /* Rx buffer overflow flag */
> +#define MXC_UARTSFIFO_TXOF	0x02 /* Tx buffer overflow flag */
> +#define MXC_UARTSFIFO_RXUF	0x01 /* Rx buffer underflow flag */
> +
> +
> +
> +#undef CONFIG_MVF_SERIAL_DMA

Please remove.

> +/* follow IMX dev node number */
> +#define SERIAL_IMX_MAJOR	207
> +#define MINOR_START		24
> +#define DEV_NAME	"ttymxc"
> +#define MAX_INTERNAL_IRQ	MXC_INTERNAL_IRQS
> +
> +/*
> + * This determines how often we check the modem status signals
> + * for any change.  They generally aren't connected to an IRQ
> + * so we have to poll them.  We also check immediately before
> + * filling the TX fifo incase CTS has been dropped.
> + */
> +#define MCTRL_TIMEOUT	(250*HZ/1000)

Add whitespaces left and right to operators:

	(250 * HZ / 1000)

> +
> +#define DRIVER_NAME "MVF-uart"
> +
> +#define UART_NR 6
> +
> +struct mvf_port {
> +	struct uart_port	port;
> +	unsigned int		old_status;
> +	int			txirq, rxirq, rtsirq;
> +	unsigned int		have_rtscts:1;
> +	unsigned int		use_dcedte:1;
> +	unsigned int		use_irda:1;
> +	unsigned int		irda_inv_rx:1;
> +	unsigned int		irda_inv_tx:1;
> +	unsigned int		fifo_en:1; /* enable FIFO mode */
> +	unsigned int		mark_en:1; /* enable Mark address match */
> +	unsigned int		format_9bits:1; /* 9bits data format */
> +	unsigned short		trcv_delay; /* transceiver delay */
> +	unsigned char		ma_addr; /* Match address */
> +	struct clk		*clk;
> +
> +	unsigned int		tx_fifo_size, rx_fifo_size;
> +
> +	/* DMA fields */
> +	int			enable_dma;

enable_dma is unused. Either implement it or remove it.

> +	unsigned long		dma_tx_ch; /* configured eDMA channel */
> +	struct imx_dma_data	dma_data;
> +	struct dma_chan		*dma_chan_rx, *dma_chan_tx;
> +	struct scatterlist	rx_sgl, tx_sgl;
> +	void			*rx_buf;
> +	unsigned char		*tx_buf;
> +	unsigned int		rx_bytes, tx_bytes;
> +	struct work_struct	tsk_dma_rx, tsk_dma_tx;
> +	unsigned int		dma_tx_nents;
> +	bool			dma_is_rxing, dma_is_txing;
> +	wait_queue_head_t	dma_wait;
> +};
> +
> +#ifdef CONFIG_IRDA
> +#define USE_IRDA(sport)	((sport)->use_irda)
> +#else
> +#define USE_IRDA(sport)	(0)
> +#endif

This is unused. Remove. also rtsirq and use_irda

> +enum mvf_uart_type {
> +	MVF600_UART,
> +};
> +
> +struct mvf_uart_data {
> +	unsigned uts_reg;
> +	enum mvf_uart_type devtype;
> +};
> +
> +static struct mvf_uart_data mvf_uart_devdata[] = {
> +	[MVF600_UART] = {
> +		.devtype = MVF600_UART,
> +	},
> +};
> +
> +static struct platform_device_id mvf_uart_devtype[] = {
> +	{
> +		.name = "mvf600-uart",
> +		.driver_data = (kernel_ulong_t) &mvf_uart_devdata[MVF600_UART],
> +	}, {
> +		/* sentinel */
> +	}
> +};
> +MODULE_DEVICE_TABLE(platform, mvf_uart_devtype);
> +
> +static struct of_device_id mvf_uart_dt_ids[] = {
> +	{
> +		.compatible = "fsl,mvf-uart",
> +		.data = &mvf_uart_devdata[MVF600_UART],
> +	},
> +	{ /* sentinel */ }
> +};
> +MODULE_DEVICE_TABLE(of, mvf_uart_dt_ids);
> +
> +/*
> + * interrupts disabled on entry
> + */
> +static void mvf_stop_tx(struct uart_port *port)
> +{
> +	struct mvf_port *sport = (struct mvf_port *)port;
> +	unsigned char temp;
> +
> +	temp = readb(sport->port.membase + MXC_UARTCR2);
> +	writeb(temp & ~(MXC_UARTCR2_TIE | MXC_UARTCR2_TCIE),
> +			sport->port.membase + MXC_UARTCR2);

I find it more readable to do a:

	temp = readl(adr);
	temp &= ~(bla);
	writel(temp, adr);

But that's just my 2 cents.

> +}
> +
> +/*
> + * interrupts disabled on entry
> + */
> +static void mvf_stop_rx(struct uart_port *port)
> +{
> +	struct mvf_port *sport = (struct mvf_port *)port;
> +	unsigned char temp;
> +
> +	/* if the DMA RX thread is running, wait for it to finish. */
> +	if (sport->enable_dma && sport->dma_is_rxing)
> +		return;
> +
> +	temp = readb(sport->port.membase + MXC_UARTCR2);
> +	writeb(temp & ~MXC_UARTCR2_RE, sport->port.membase + MXC_UARTCR2);
> +}
> +
> + /* modem status update function */
> +static void mvf_enable_ms(struct uart_port *port)
> +{
> +}
> +
> +static inline void mvf_transmit_buffer(struct mvf_port *sport)
> +{
> +	struct circ_buf *xmit = &sport->port.state->xmit;
> +
> +	while (!uart_circ_empty(xmit) && (sport->fifo_en == 1 ?
> +	(readb(sport->port.membase + MXC_UARTTCFIFO) < sport->tx_fifo_size) :
> +		(readb(sport->port.membase + MXC_UARTSR1) & MXC_UARTSR1_TDRE)
> +		)) {

Can you make this more readable?

> +		/* send out xmit->buf[xmit->tail] */
> +		writeb(xmit->buf[xmit->tail], sport->port.membase + MXC_UARTDR);
> +		xmit->tail = (xmit->tail + 1) & (UART_XMIT_SIZE - 1);
> +		sport->port.icount.tx++;
> +	}
> +
> +	if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS)
> +		uart_write_wakeup(&sport->port);
> +
> +	if (uart_circ_empty(xmit))
> +		mvf_stop_tx(&sport->port);
> +}
> +
> +/*
> + * interrupts disabled on entry
> + */
> +static void mvf_start_tx(struct uart_port *port)
> +{
> +	struct mvf_port *sport = (struct mvf_port *)port;
> +	unsigned char temp;
> +
> +	if (!sport->enable_dma) {
> +		temp = readb(sport->port.membase + MXC_UARTCR2);
> +		writeb(temp | MXC_UARTCR2_TIE,
> +				sport->port.membase + MXC_UARTCR2);
> +	}
> +
> +	if (sport->enable_dma) {
> +		schedule_work(&sport->tsk_dma_tx);
> +		return;
> +	}
> +
> +	if (readb(sport->port.membase + MXC_UARTSR1) & MXC_UARTSR1_TDRE)
> +		mvf_transmit_buffer(sport);
> +}
> +
> +
> +static irqreturn_t mvf_txint(int irq, void *dev_id)
> +{
> +	struct mvf_port *sport = dev_id;
> +	struct circ_buf *xmit = &sport->port.state->xmit;
> +	unsigned long flags;
> +
> +	spin_lock_irqsave(&sport->port.lock, flags);
> +	if (sport->port.x_char) {
> +		/* Send next char */
> +		writeb(sport->port.x_char, sport->port.membase + MXC_UARTDR);
> +		goto out;
> +	}
> +
> +	if (uart_circ_empty(xmit) || uart_tx_stopped(&sport->port)) {
> +		mvf_stop_tx(&sport->port);
> +		goto out;
> +	}
> +
> +	mvf_transmit_buffer(sport);
> +
> +	if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS)
> +		uart_write_wakeup(&sport->port);
> +
> +out:
> +	spin_unlock_irqrestore(&sport->port.lock, flags);
> +	return IRQ_HANDLED;
> +}
> +
> +static irqreturn_t mvf_rxint(int irq, void *dev_id)
> +{
> +	struct mvf_port *sport = dev_id;
> +	unsigned int flg, ignored = 0;
> +	struct tty_port *port = &sport->port.state->port;
> +	unsigned long flags;
> +	unsigned char r8, rx, sr;
> +
> +	spin_lock_irqsave(&sport->port.lock, flags);
> +
> +	while (!(readb(sport->port.membase + MXC_UARTSFIFO) &
> +				MXC_UARTSFIFO_RXEMPT)) {
> +		flg = TTY_NORMAL;
> +		sport->port.icount.rx++;
> +
> +		/*  To clear the FE, OR, NF, FE, PE flags when set,
> +		 *  read SR1 then read DR
> +		 */
> +		sr = readb(sport->port.membase + MXC_UARTSR1);
> +
> +		r8 = readb(sport->port.membase + MXC_UARTCR3) & MXC_UARTCR3_R8;
> +		rx = readb(sport->port.membase + MXC_UARTDR);
> +
> +		if (sport->mark_en &&
> +			(sport->format_9bits ? r8 : (rx == sport->ma_addr)))
> +				continue;
> +
> +		if (uart_handle_sysrq_char(&sport->port, (unsigned char)rx))
> +			continue;
> +		if (sr & (MXC_UARTSR1_PE | MXC_UARTSR1_OR | MXC_UARTSR1_FE)) {
> +			if (sr & MXC_UARTSR1_PE)
> +				sport->port.icount.parity++;
> +			else if (sr & MXC_UARTSR1_FE)
> +				sport->port.icount.frame++;
> +			if (sr & MXC_UARTSR1_OR)
> +				sport->port.icount.overrun++;
> +
> +			if (sr & sport->port.ignore_status_mask) {
> +				if (++ignored > 100)
> +					goto out;
> +				continue;
> +			}
> +
> +			sr &= sport->port.read_status_mask;
> +
> +			if (sr & MXC_UARTSR1_PE)
> +				flg = TTY_PARITY;
> +			else if (sr & MXC_UARTSR1_FE)
> +				flg = TTY_FRAME;
> +			if (sr & MXC_UARTSR1_OR)
> +				flg = TTY_OVERRUN;
> +
> +#ifdef SUPPORT_SYSRQ
> +			sport->port.sysrq = 0;
> +#endif
> +		}
> +
> +		tty_insert_flip_char(port, rx, flg);
> +	}
> +
> +out:
> +	spin_unlock_irqrestore(&sport->port.lock, flags);
> +
> +	tty_flip_buffer_push(port);
> +	return IRQ_HANDLED;
> +}
> +
> +static irqreturn_t mvf_int(int irq, void *dev_id)
> +{
> +	struct mvf_port *sport = dev_id;
> +	unsigned int sts;
> +
> +	sts = readb(sport->port.membase + MXC_UARTSR1);
> +
> +	if (sts & MXC_UARTSR1_RDRF)
> +			mvf_rxint(irq, dev_id);

Wrong indention.

> +
> +	if (sts & MXC_UARTSR1_TDRE &&
> +		!(readb(sport->port.membase + MXC_UARTCR5) &
> +			MXC_UARTCR5_TDMAS))
> +		mvf_txint(irq, dev_id);
> +
> +	return IRQ_HANDLED;
> +}
> +
> +/*
> + * Return TIOCSER_TEMT when transmitter is not busy.
> + */
> +static unsigned int mvf_tx_empty(struct uart_port *port)
> +{
> +	struct mvf_port *sport = (struct mvf_port *)port;
> +
> +	return (readb(sport->port.membase + MXC_UARTSR1) & MXC_UARTSR1_TC) ?
> +		TIOCSER_TEMT : 0;
> +}
> +
> +static unsigned int mvf_get_mctrl(struct uart_port *port)
> +{
> +	struct mvf_port *sport = (struct mvf_port *)port;
> +	unsigned int tmp = 0;
> +	unsigned char reg;
> +
> +	reg = readb(sport->port.membase + MXC_UARTMODEM);
> +	if (reg & MXC_UARTMODEM_TXCTSE)
> +		tmp |= TIOCM_CTS;
> +
> +	if (reg & MXC_UARTMODEM_RXRTSE)
> +		tmp |= TIOCM_RTS;
> +
> +	return tmp;
> +}
> +
> +static void mvf_set_mctrl(struct uart_port *port, unsigned int mctrl)
> +{
> +	struct mvf_port *sport = (struct mvf_port *)port;

Do not cast to different struct typed. Use container_of instead.

> +	unsigned long temp;
> +
> +	temp = readb(sport->port.membase + MXC_UARTMODEM) &
> +			~(MXC_UARTMODEM_RXRTSE | MXC_UARTMODEM_TXCTSE);
> +
> +	if (mctrl & TIOCM_RTS)
> +		temp |= MXC_UARTMODEM_RXRTSE;
> +	if (mctrl & TIOCM_CTS)
> +		temp |= MXC_UARTMODEM_TXCTSE;
> +
> +	writeb(temp, sport->port.membase + MXC_UARTMODEM);
> +}
> +
> +/*
> + * Interrupts always disabled.
> + */
> +static void mvf_break_ctl(struct uart_port *port, int break_state)
> +{
> +	struct mvf_port *sport = (struct mvf_port *)port;
> +	unsigned long flags;
> +	unsigned char temp;
> +
> +	spin_lock_irqsave(&sport->port.lock, flags);
> +
> +	temp = readb(sport->port.membase + MXC_UARTCR2) & ~MXC_UARTCR2_SBK;
> +
> +	if (break_state != 0)
> +		temp |= MXC_UARTCR2_SBK;
> +
> +	writeb(temp, sport->port.membase + MXC_UARTCR2);
> +
> +	spin_unlock_irqrestore(&sport->port.lock, flags);
> +}
> +
> +#define TXTL 2
> +#define RXTL 1
> +
> +static int mvf_setup_watermark(struct mvf_port *sport, unsigned int mode)

The mode argument is unused.

> +{
> +	unsigned char val, old_cr2, cr2;
> +
> +	/* set receiver/transmitter trigger level. */
> +	old_cr2 = cr2 = readb(sport->port.membase + MXC_UARTCR2);
> +	cr2 &= ~(MXC_UARTCR2_TIE | MXC_UARTCR2_TCIE | MXC_UARTCR2_TE |
> +			MXC_UARTCR2_RIE | MXC_UARTCR2_RE);
> +	writeb(cr2, sport->port.membase + MXC_UARTCR2);
> +
> +	val = TXTL;
> +	writeb(val, sport->port.membase + MXC_UARTTWFIFO);
> +	val = RXTL;
> +	writeb(val, sport->port.membase + MXC_UARTRWFIFO);

Please drop this additional 'val =' hoop.

> +
> +	/* Enable Tx and Rx FIFO */
> +	val = readb(sport->port.membase + MXC_UARTPFIFO);
> +	sport->tx_fifo_size = 0x1 << (((val >> MXC_UARTPFIFO_TXFIFOSIZE_OFF) &
> +		MXC_UARTPFIFO_TXFIFOSIZE_MASK) + 1);
> +	sport->rx_fifo_size = 0x1 << (((val >> MXC_UARTPFIFO_RXFIFOSIZE_OFF) &
> +		MXC_UARTPFIFO_RXFIFOSIZE_MASK) + 1);

During init you hardcode the FIFO size to 32 byte. Can't you use these
values instead?

> +	writeb(val | MXC_UARTPFIFO_TXFE | MXC_UARTPFIFO_RXFE,
> +			sport->port.membase + MXC_UARTPFIFO);
> +
> +	/* Flush the Tx and Rx FIFO to a known state */
> +	writeb(MXC_UARTCFIFO_TXFLUSH | MXC_UARTCFIFO_RXFLUSH,
> +			sport->port.membase + MXC_UARTCFIFO);
> +
> +	/* restore CR2 */
> +	writeb(old_cr2, sport->port.membase + MXC_UARTCR2);
> +
> +	return 0;
> +}

The function always returns 0 and the return value is never checked, so
make it return void.

> +
> +
> +static int mvf_startup(struct uart_port *port)
> +{
> +	struct mvf_port *sport = (struct mvf_port *)port;
> +	int retval;
> +	unsigned long flags, temp;
> +
> +	if (sport->fifo_en)
> +		mvf_setup_watermark(sport, 0);
> +
> +	temp = readb(sport->port.membase + MXC_UARTCR2);
> +
> +	writeb(temp & ~MXC_UARTCR2_RIE, sport->port.membase + MXC_UARTCR2);
> +
> +	/*
> +	 * Allocate the IRQ(s)
> +	 * Vybrid chips only have one interrupt.
> +	 */
> +	retval = request_irq(sport->port.irq, mvf_int, 0,
> +				DRIVER_NAME, sport);

Request you interrupt in the probe function so that you can use a devm_*
function.

> +	if (retval)
> +		goto error_out1;
> +
> +	/* Enable the DMA ops for uart. */
> +	if (sport->enable_dma) {
> +		sport->dma_is_txing = 0;
> +
> +		/* enable DMA request generation */
> +		temp = readb(sport->port.membase + MXC_UARTCR5);
> +		temp |= MXC_UARTCR5_TDMAS;
> +		writeb(temp, sport->port.membase + MXC_UARTCR5);
> +
> +		init_waitqueue_head(&sport->dma_wait);
> +	}
> +
> +	spin_lock_irqsave(&sport->port.lock, flags);
> +
> +	/* Finally, clear and enable interrupts */
> +	temp = readb(sport->port.membase + MXC_UARTCR2);
> +	temp |= MXC_UARTCR2_RIE | MXC_UARTCR2_TIE;
> +	writeb(temp, sport->port.membase + MXC_UARTCR2);
> +
> +	spin_unlock_irqrestore(&sport->port.lock, flags);
> +
> +	return 0;
> +
> +error_out1:
> +	return retval;
> +}
> +
> +static void mvf_shutdown(struct uart_port *port)
> +{
> +	struct mvf_port *sport = (struct mvf_port *)port;
> +	unsigned char temp;
> +	unsigned long flags;
> +
> +	spin_lock_irqsave(&sport->port.lock, flags);
> +	temp = readb(sport->port.membase + MXC_UARTCR2);
> +	temp &= ~(MXC_UARTCR2_TE | MXC_UARTCR2_RE);
> +	writeb(temp, sport->port.membase + MXC_UARTCR2);
> +	spin_unlock_irqrestore(&sport->port.lock, flags);
> +
> +	/*
> +	 * Free the interrupts
> +	 */
> +	if (sport->txirq > 0) {
> +		if (!USE_IRDA(sport))
> +			free_irq(sport->rtsirq, sport);
> +		free_irq(sport->txirq, sport);
> +		free_irq(sport->rxirq, sport);
> +	} else
> +		free_irq(sport->port.irq, sport);

If one branch of a conditional statement needs braces add them to the
other aswell.

> +
> +	/*
> +	 * Disable all interrupts, port and break condition.
> +	 */
> +
> +	spin_lock_irqsave(&sport->port.lock, flags);
> +	temp = readb(sport->port.membase + MXC_UARTCR2);
> +	temp &= ~(MXC_UARTCR2_TIE | MXC_UARTCR2_TCIE | MXC_UARTCR2_RIE);
> +	writeb(temp, sport->port.membase + MXC_UARTCR2);
> +
> +	spin_unlock_irqrestore(&sport->port.lock, flags);
> +}
> +
> +static void
> +mvf_set_termios(struct uart_port *port, struct ktermios *termios,
> +		   struct ktermios *old)
> +{
> +	struct mvf_port *sport = (struct mvf_port *)port;
> +	unsigned long flags;
> +	unsigned char cr1, old_cr1, old_cr2, cr4, bdh, modem;
> +	unsigned int  baud;
> +	unsigned int old_csize = old ? old->c_cflag & CSIZE : CS8;
> +	unsigned int sbr, brfa;
> +
> +	cr1 = old_cr1 = readb(sport->port.membase + MXC_UARTCR1);
> +	old_cr2 = readb(sport->port.membase + MXC_UARTCR2);
> +	cr4 = readb(sport->port.membase + MXC_UARTCR4);
> +	bdh = readb(sport->port.membase + MXC_UARTBDH);
> +	modem = readb(sport->port.membase + MXC_UARTMODEM);
> +	/*
> +	 * If we don't support modem control lines, don't allow
> +	 * these to be set.
> +	 */
> +	if (0) {
> +		termios->c_cflag &= ~(HUPCL | CRTSCTS | CMSPAR);
> +		termios->c_cflag |= CLOCAL;
> +	}

Dead code. Please remove.

> +
> +	/*
> +	 * We only support CS8 and CS7,but CS7 must enable PE.
> +	 * supported mode:
> +	 *  - (7,e/o,1)
> +	 *  - (8,n,1)
> +	 *  - (8,m/s,1)
> +	 *  - (8,e/o,1)
> +	 */
> +	while ((termios->c_cflag & CSIZE) != CS8 &&
> +		(termios->c_cflag & CSIZE) != CS7) {
> +		termios->c_cflag &= ~CSIZE;
> +		termios->c_cflag |= old_csize;
> +		old_csize = CS8;
> +	}
> +
> +	if ((termios->c_cflag & CSIZE) == CS8 ||
> +		(termios->c_cflag & CSIZE) == CS7)
> +		cr1 = old_cr1 & ~MXC_UARTCR1_M;
> +
> +	if (termios->c_cflag & CMSPAR) {
> +		if ((termios->c_cflag & CSIZE) != CS8) {
> +			termios->c_cflag &= ~CSIZE;
> +			termios->c_cflag |= CS8;
> +		}
> +		cr1 |= MXC_UARTCR1_M;
> +	}
> +
> +	if (termios->c_cflag & CRTSCTS) {
> +		if (sport->have_rtscts)
> +			modem |= (MXC_UARTMODEM_RXRTSE | MXC_UARTMODEM_TXCTSE);
> +
> +	} else {
> +		termios->c_cflag &= ~CRTSCTS;
> +		modem &= ~(MXC_UARTMODEM_RXRTSE | MXC_UARTMODEM_TXCTSE);
> +	}
> +
> +	if (termios->c_cflag & CSTOPB)
> +		termios->c_cflag &= ~CSTOPB;
> +
> +	/* parity must enable when CS7 to match 8-bits format */
> +	if ((termios->c_cflag & CSIZE) == CS7)
> +		termios->c_cflag |= PARENB;
> +
> +	if ((termios->c_cflag & PARENB)) {
> +		if (termios->c_cflag & CMSPAR) {
> +			cr1 &= ~MXC_UARTCR1_PE;
> +			cr1 |= MXC_UARTCR1_M;
> +			sport->format_9bits = 1;
> +		} else {
> +			cr1 |= MXC_UARTCR1_PE;
> +			if ((termios->c_cflag & CSIZE) == CS8)
> +				cr1 |= MXC_UARTCR1_M;
> +			if (termios->c_cflag & PARODD)
> +				cr1 |= MXC_UARTCR1_PT;
> +			else
> +				cr1 &= ~MXC_UARTCR1_PT;
> +		}
> +	}
> +
> +	/*
> +	 * Ask the core to calculate the divisor for us.
> +	 */
> +	baud = uart_get_baud_rate(port, termios, old, 50, port->uartclk / 16);
> +
> +	spin_lock_irqsave(&sport->port.lock, flags);
> +
> +	sport->port.read_status_mask = 0;
> +	if (termios->c_iflag & INPCK)
> +		sport->port.read_status_mask |=
> +					(MXC_UARTSR1_FE | MXC_UARTSR1_PE);
> +	if (termios->c_iflag & (BRKINT | PARMRK))
> +		sport->port.read_status_mask |= MXC_UARTSR1_FE;
> +
> +	/*
> +	 * Characters to ignore
> +	 */
> +	sport->port.ignore_status_mask = 0;
> +	if (termios->c_iflag & IGNPAR)
> +		sport->port.ignore_status_mask |= MXC_UARTSR1_PE;
> +	if (termios->c_iflag & IGNBRK) {
> +		sport->port.ignore_status_mask |= MXC_UARTSR1_FE;
> +		/*
> +		 * If we're ignoring parity and break indicators,
> +		 * ignore overruns too (for real raw support).
> +		 */
> +		if (termios->c_iflag & IGNPAR)
> +			sport->port.ignore_status_mask |= MXC_UARTSR1_OR;
> +	}
> +
> +	/*
> +	 * Update the per-port timeout.
> +	 */
> +	uart_update_timeout(port, termios->c_cflag, baud);
> +
> +	/* wait transmit engin complete */
> +	while (!(readb(sport->port.membase + MXC_UARTSR1) & MXC_UARTSR1_TC))
> +		barrier();
> +
> +	writeb(old_cr2 & ~(MXC_UARTCR2_TE | MXC_UARTCR2_RE),
> +			sport->port.membase + MXC_UARTCR2);
> +
> +	/* disable transmit and receive */
> +	sbr = sport->port.uartclk / (16 * baud);
> +	brfa = ((sport->port.uartclk - (16 * sbr * baud)) * 2)/baud;
> +
> +	bdh &= ~MXC_UARTBDH_SBR_MASK;
> +	bdh |= (sbr >> 8) & 0x1F;
> +
> +	cr4 &= ~MXC_UARTCR4_BRFA_MASK;
> +	brfa &= MXC_UARTCR4_BRFA_MASK;
> +	writeb(cr4 | brfa, sport->port.membase + MXC_UARTCR4);
> +	writeb(bdh, sport->port.membase + MXC_UARTBDH);
> +	writeb(sbr & 0xFF, sport->port.membase + MXC_UARTBDL);
> +	writeb(cr1, sport->port.membase + MXC_UARTCR1);
> +	writeb(modem, sport->port.membase + MXC_UARTMODEM);
> +
> +	/* restore control register */
> +	writeb(old_cr2, sport->port.membase + MXC_UARTCR2);
> +
> +	spin_unlock_irqrestore(&sport->port.lock, flags);
> +}
> +
> +static const char *mvf_type(struct uart_port *port)
> +{
> +	struct mvf_port *sport = (struct mvf_port *)port;
> +
> +	return sport->port.type == PORT_MVF ? "MVF" : NULL;
> +}
> +
> +/*
> + * Release the memory region(s) being used by 'port'.
> + */
> +static void mvf_release_port(struct uart_port *port)
> +{
> +	struct platform_device *pdev = to_platform_device(port->dev);
> +	struct resource *mmres;
> +
> +	mmres = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +	release_mem_region(mmres->start, mmres->end - mmres->start + 1);
> +}
> +
> +/*
> + * Request the memory region(s) being used by 'port'.
> + */
> +static int mvf_request_port(struct uart_port *port)
> +{
> +	struct platform_device *pdev = to_platform_device(port->dev);
> +	struct resource *mmres;
> +	void *ret;
> +
> +	mmres = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +	if (!mmres)
> +		return -ENODEV;
> +
> +	ret = request_mem_region(mmres->start, mmres->end - mmres->start + 1,
> +			"imx-uart");

Use resource_size()

> +
> +	return  ret ? 0 : -EBUSY;
> +}
> +
> +/*
> + * Configure/autoconfigure the port.
> + */
> +static void mvf_config_port(struct uart_port *port, int flags)
> +{
> +	struct mvf_port *sport = (struct mvf_port *)port;
> +
> +	if (flags & UART_CONFIG_TYPE &&
> +	    mvf_request_port(&sport->port) == 0)
> +		sport->port.type = PORT_MVF;
> +}
> +
> +/*
> + * Verify the new serial_struct (for TIOCSSERIAL).
> + * The only change we allow are to the flags and type, and
> + * even then only between PORT_MVF and PORT_UNKNOWN
> + */
> +static int
> +mvf_verify_port(struct uart_port *port, struct serial_struct *ser)
> +{
> +	struct mvf_port *sport = (struct mvf_port *)port;
> +	int ret = 0;
> +
> +	if (ser->type != PORT_UNKNOWN && ser->type != PORT_MVF)
> +		ret = -EINVAL;
> +	if (sport->port.irq != ser->irq)
> +		ret = -EINVAL;
> +	if (ser->io_type != UPIO_MEM)
> +		ret = -EINVAL;
> +	if (sport->port.uartclk / 16 != ser->baud_base)
> +		ret = -EINVAL;
> +	if (sport->port.iobase != ser->port)
> +		ret = -EINVAL;
> +	if (ser->hub6 != 0)
> +		ret = -EINVAL;
> +	return ret;
> +}
> +
> +
> +static struct uart_ops mvf_pops = {
> +	.tx_empty	= mvf_tx_empty,
> +	.set_mctrl	= mvf_set_mctrl,
> +	.get_mctrl	= mvf_get_mctrl,
> +	.stop_tx	= mvf_stop_tx,
> +	.start_tx	= mvf_start_tx,
> +	.stop_rx	= mvf_stop_rx,
> +	.enable_ms	= mvf_enable_ms,
> +	.break_ctl	= mvf_break_ctl,
> +	.startup	= mvf_startup,
> +	.shutdown	= mvf_shutdown,
> +	.set_termios	= mvf_set_termios,
> +	.type		= mvf_type,
> +	.release_port	= mvf_release_port,
> +	.request_port	= mvf_request_port,
> +	.config_port	= mvf_config_port,
> +	.verify_port	= mvf_verify_port,
> +};
> +
> +static struct mvf_port *mvf_ports[UART_NR];
> +
> +#ifdef CONFIG_SERIAL_MVF_CONSOLE
> +static void mvf_console_putchar(struct uart_port *port, int ch)
> +{
> +	struct mvf_port *sport = (struct mvf_port *)port;
> +
> +	while (!(readb(sport->port.membase + MXC_UARTSR1) & MXC_UARTSR1_TDRE))
> +		barrier();
> +
> +	writeb(ch, sport->port.membase + MXC_UARTDR);
> +}
> +
> +/*
> + * Interrupts are disabled on entering
> + */

You don't care since you are locking the device anyway.

> +static void
> +mvf_console_write(struct console *co, const char *s, unsigned int count)
> +{
> +	struct mvf_port *sport = mvf_ports[co->index];
> +	unsigned int  old_cr2, cr2;
> +	unsigned long flags;
> +
> +	spin_lock_irqsave(&sport->port.lock, flags);
> +	/*
> +	 * First, save UCR1/2 and then disable interrupts
> +	 */

The comment seems wrong.

> +	cr2 = old_cr2 = readb(sport->port.membase + MXC_UARTCR2);
> +
> +	cr2 |= (MXC_UARTCR2_TE |  MXC_UARTCR2_RE);
> +	cr2 &= ~(MXC_UARTCR2_TIE | MXC_UARTCR2_TCIE | MXC_UARTCR2_RIE);
> +
> +	writeb(cr2, sport->port.membase + MXC_UARTCR2);
> +
> +	uart_console_write(&sport->port, s, count, mvf_console_putchar);
> +
> +	/*
> +	 * wait for transmitter finish complete and restore CR2
> +	 */
> +	while (!(readb(sport->port.membase + MXC_UARTSR1) & MXC_UARTSR1_TC))
> +		;
> +
> +	writeb(old_cr2, sport->port.membase + MXC_UARTCR2);
> +	spin_unlock_irqrestore(&sport->port.lock, flags);
> +}
> +
> +/*
> + * If the port was already initialised (eg, by a boot loader),
> + * try to determine the current setup.
> + */
> +static void __init
> +mvf_console_get_options(struct mvf_port *sport, int *baud,
> +			   int *parity, int *bits)
> +{
> +
> +	if (readb(sport->port.membase + MXC_UARTCR2) &
> +			(MXC_UARTCR2_TE | MXC_UARTCR2)) {

Bail out early here by testing for the opposite. You'll save an
indention level below.

> +		/* ok, the port was enabled */
> +		unsigned char cr1, bdh, bdl, brfa;
> +		unsigned int sbr, uartclk;
> +		unsigned int baud_raw;
> +
> +		cr1 = readb(sport->port.membase + MXC_UARTCR1);
> +
> +		*parity = 'n';
> +		if (cr1 & MXC_UARTCR1_PE) {
> +			if (cr1 & MXC_UARTCR1_PT)
> +				*parity = 'o';
> +			else
> +				*parity = 'e';
> +		}
> +
> +		if (cr1 & MXC_UARTCR1_M)
> +			*bits = 9;
> +		else
> +			*bits = 8;
> +
> +		bdh = readb(sport->port.membase + MXC_UARTBDH) &
> +						MXC_UARTBDH_SBR_MASK;
> +		bdl = readb(sport->port.membase + MXC_UARTBDL);
> +		sbr = bdh;
> +		sbr <<= 8;
> +		sbr |= bdl;
> +		brfa = readb(sport->port.membase + MXC_UARTCR4) &
> +						MXC_UARTCR4_BRFA_MASK;
> +		uartclk = clk_get_rate(sport->clk);
> +		/*
> +		 * Baud = mod_clk/(16*(sbr[13]+(brfa)/32)
> +		 */
> +		baud_raw = uartclk/(16 * (sbr + brfa/32));

Add whitespaces left and right to operators.

> +
> +		if (*baud != baud_raw)
> +			printk(KERN_INFO "Serial: Console IMX "
> +					"rounded baud rate from %d to %d\n",

IMX?

> +				baud_raw, *baud);
> +	}
> +}
> +
> +static int __init
> +mvf_console_setup(struct console *co, char *options)
> +{
> +	struct mvf_port *sport;
> +	int baud = 115200;
> +	int bits = 8;
> +	int parity = 'n';
> +	int flow = 'n';
> +
> +	/*
> +	 * Check whether an invalid uart number has been specified, and
> +	 * if so, search for the first available port that does have
> +	 * console support.
> +	 */
> +	if (co->index == -1 || co->index >= ARRAY_SIZE(mvf_ports))
> +		co->index = 0;
> +	sport = mvf_ports[co->index];
> +
> +	if (sport == NULL)
> +		return -ENODEV;
> +
> +	if (options)
> +		uart_parse_options(options, &baud, &parity, &bits, &flow);
> +	else
> +		mvf_console_get_options(sport, &baud, &parity, &bits);
> +
> +	if (sport->fifo_en == 1)
> +		mvf_setup_watermark(sport, 0);
> +
> +	return uart_set_options(&sport->port, co, baud, parity, bits, flow);
> +}
> +
> +static struct uart_driver mvf_reg;
> +static struct console mvf_console = {
> +	.name		= DEV_NAME,
> +	.write		= mvf_console_write,
> +	.device		= uart_console_device,
> +	.setup		= mvf_console_setup,
> +	.flags		= CON_PRINTBUFFER,
> +	.index		= -1,
> +	.data		= &mvf_reg,
> +};
> +
> +#define MVF_CONSOLE	(&mvf_console)
> +#else
> +#define MVF_CONSOLE	NULL
> +#endif
> +
> +static struct uart_driver mvf_reg = {
> +	.owner          = THIS_MODULE,
> +	.driver_name    = DRIVER_NAME,
> +	.dev_name       = DEV_NAME,
> +	.major          = SERIAL_IMX_MAJOR,
> +	.minor          = MINOR_START,
> +	.nr             = ARRAY_SIZE(mvf_ports),
> +	.cons           = MVF_CONSOLE,
> +};
> +
> +static int serial_mvf_suspend(struct platform_device *dev, pm_message_t state)
> +{
> +	struct mvf_port *sport = platform_get_drvdata(dev);
> +
> +	/* Enable UART wakeup */
> +
> +	if (sport)
> +		uart_suspend_port(&mvf_reg, &sport->port);

unnecessary test.

> +
> +	return 0;
> +}
> +
> +static int serial_mvf_resume(struct platform_device *dev)
> +{
> +	struct mvf_port *sport = platform_get_drvdata(dev);
> +
> +	if (sport)
> +		uart_resume_port(&mvf_reg, &sport->port);

ditto.

> +
> +	/* Disable UART wakeup */
> +
> +	return 0;
> +}
> +
> +static int serial_mvf_probe_dt(struct mvf_port *sport,
> +		struct platform_device *pdev)
> +{
> +	struct device_node *np = pdev->dev.of_node;
> +	int ret;
> +
> +	if (!np)
> +		/* no device tree device */
> +		return 1;
> +
> +	ret = of_alias_get_id(np, "serial");
> +	if (ret < 0) {
> +		dev_err(&pdev->dev, "failed to get alias id, errno %d\n", ret);
> +		return ret;
> +	}
> +	sport->port.line = ret;
> +
> +	if (of_get_property(np, "fsl,uart-fifo-mode", NULL))
> +		sport->fifo_en = 1;

Why is this configurable? Everybody wants FIFO support, right?

> +
> +	return 0;
> +}
> +
> +static int serial_mvf_probe(struct platform_device *pdev)
> +{
> +	struct mvf_port *sport;
> +	struct imxuart_platform_data *pdata;
> +	void __iomem *base;
> +	int ret = 0;
> +	struct resource *res;
> +
> +	sport = devm_kzalloc(&pdev->dev, sizeof(*sport), GFP_KERNEL);
> +	if (!sport)
> +		return -ENOMEM;
> +
> +	pdev->dev.coherent_dma_mask = 0;
> +
> +	ret = serial_mvf_probe_dt(sport, pdev);
> +	if (ret < 0)
> +		return ret ;
> +
> +	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +	if (!res)
> +		return -ENODEV;
> +
> +	base = devm_ioremap(&pdev->dev, res->start, PAGE_SIZE);
> +	if (!base)
> +		return -ENOMEM;

devm_request_and_ioremap?

> +
> +	sport->port.dev = &pdev->dev;
> +	sport->port.mapbase = res->start;
> +	sport->port.membase = base;
> +	sport->port.type = PORT_MVF,
> +	sport->port.iotype = UPIO_MEM;
> +	sport->port.irq = platform_get_irq(pdev, 0);
> +	sport->port.fifosize = 32;
> +	sport->port.ops = &mvf_pops;
> +	sport->port.flags = UPF_BOOT_AUTOCONF;
> +	if (pdev->id >= 0)
> +		sport->port.line = pdev->id;
> +
> +	sport->clk = devm_clk_get(&pdev->dev, "ipg");
> +	if (IS_ERR(sport->clk)) {
> +		ret = PTR_ERR(sport->clk);
> +		dev_err(&pdev->dev, "failed to uart clk: %d\n", ret);
> +		return ret;
> +	}
> +
> +	clk_prepare_enable(sport->clk);
> +
> +	sport->port.uartclk = clk_get_rate(sport->clk);
> +
> +	mvf_ports[sport->port.line] = sport;
> +
> +	pdata = pdev->dev.platform_data;
> +
> +	/* all uarts support hardware RTS/CTS */
> +	sport->have_rtscts = 1;

This should either be configurable from the devicetree since not all
UARTs on all boards have routed the rts/cts pins out, or you should
not even have this variable.

> +
> +	if (pdata && pdata->init) {
> +		ret = pdata->init(pdev);
> +		if (ret)
> +			goto clkput;
> +	}

No. Drop this.

> +
> +	ret = uart_add_one_port(&mvf_reg, &sport->port);
> +
> +	if (ret)
> +		goto deinit;
> +	platform_set_drvdata(pdev, &sport->port);

This should be done *before* registering the device.

> +
> +	return 0;
> +deinit:
> +	if (pdata && pdata->exit)
> +		pdata->exit(pdev);
> +clkput:
> +	clk_disable_unprepare(sport->clk);
> +
> +	return ret;
> +}
> +
> +static int serial_mvf_remove(struct platform_device *pdev)
> +{
> +	struct imxuart_platform_data *pdata;
> +	struct mvf_port *sport = platform_get_drvdata(pdev);
> +
> +	pdata = pdev->dev.platform_data;
> +
> +	platform_set_drvdata(pdev, NULL);
> +
> +	if (sport)
> +		uart_remove_one_port(&mvf_reg, &sport->port);
> +
> +	clk_disable_unprepare(sport->clk);
> +
> +	if (pdata && pdata->exit)
> +		pdata->exit(pdev);
> +
> +	return 0;
> +}
> +
> +static struct platform_driver serial_mvf_driver = {
> +	.probe		= serial_mvf_probe,
> +	.remove		= serial_mvf_remove,
> +
> +	.suspend	= serial_mvf_suspend,
> +	.resume		= serial_mvf_resume,
> +	.id_table       = mvf_uart_devtype,
> +	.driver		= {
> +		.name	= "mvf-uart",
> +		.owner	= THIS_MODULE,
> +		.of_match_table = mvf_uart_dt_ids,
> +	},
> +};
> +
> +static int __init mvf_serial_init(void)
> +{
> +	int ret;
> +
> +	pr_info("Serial: Vybrid Family driver\n");
> +
> +	ret = uart_register_driver(&mvf_reg);
> +	if (ret)
> +		return ret;
> +
> +	ret = platform_driver_register(&serial_mvf_driver);
> +	if (ret != 0)
> +		uart_unregister_driver(&mvf_reg);
> +
> +	return 0;
> +}
> +
> +static void __exit mvf_serial_exit(void)
> +{
> +	platform_driver_unregister(&serial_mvf_driver);
> +	uart_unregister_driver(&mvf_reg);
> +}
> +
> +module_init(mvf_serial_init);
> +module_exit(mvf_serial_exit);
> +
> +MODULE_DESCRIPTION("Vybrid Family serial port driver");
> +MODULE_LICENSE("GPL");
> diff --git a/include/uapi/linux/serial_core.h b/include/uapi/linux/serial_core.h
> index 74c2bf7..ffb7192 100644
> --- a/include/uapi/linux/serial_core.h
> +++ b/include/uapi/linux/serial_core.h
> @@ -226,4 +226,7 @@
>  /* Rocketport EXPRESS/INFINITY */
>  #define PORT_RP2	102
>  
> +/* Freescale Vybrid uart */
> +#define PORT_MVF	103
> +
>  #endif /* _UAPILINUX_SERIAL_CORE_H */
> -- 
> 1.8.0
> 
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From shawn.guo at linaro.org  Fri Apr 12 08:32:22 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Fri, 12 Apr 2013 20:32:22 +0800
Subject: [GIT PULL v2 3/4] ARM: imx: soc changes for 3.10
Message-ID: <20130412123220.GB16494@S2101-09.ap.freescale.net>

Hi Arnd, Olof,

It merges imx-fixes-3.9-5, imx-cleanup-3.10 and "[GIT PULL v3] Reset
controller API" as the base to resolve dependency and conflicts.

Changes since v1:
* Rebase to Philipp Zabel's new pull request.
* Merge imx-fixes-3.9-5 into the base to resolve one more conflict.

Shawn

The following changes since commit cb872cacb2ef57ade6bb0ff41e18b9508a0e073e:

  Merge remote-tracking branch 'pza/reset/for_v3.10' into imx/soc (2013-04-12 19:00:44 +0800)

are available in the git repository at:


  git://git.linaro.org/people/shawnguo/linux-2.6.git tags/imx-soc-3.10

for you to fetch changes up to 80f72d2d33263429ac6a50b84b2ec5fa681a5e84:

  ARM i.MX53: set CLK_SET_RATE_PARENT flag on the tve_ext_sel clock (2013-04-12 19:28:17 +0800)

----------------------------------------------------------------
The imx soc changes for 3.10:

* Enable anatop, well bisa and RBC for suspend to optimize the power
  consumption a little bit
* Clock changes for TVE, LDB, PATA, SRTC support
* Add System Reset Controller (SRC) support for imx5 and imx6
* Add initial imx6dl support based on imx6q code
* Kconfig for cpufreq-cpu0, defconfig updates and few other changes

----------------------------------------------------------------
Anson Huang (3):
      ARM: imx: enable anatop suspend/resume
      ARM: imx: enable periphery well bias for suspend
      ARM: imx: enable RBC to support anatop LPM mode

Fabio Estevam (3):
      ARM: mach-imx: anatop: Include "common.h"
      ARM: imx_v6_v7_defconfig: Select CONFIG_PERF_EVENTS
      ARM: imx_v4_v5_defconfig: Add CONFIG_GPIO_SYSFS

Gwenhael Goavec-Merou (1):
      ARM: imx1: mm: add call to mxc_device_init

Markus Pargmann (1):
      ARM: imx27, imx5: Add kconfig selects for cpufreq-cpu0

Martin Fuzzey (1):
      ARM: i.MX53 Add the cko1, cko2 clock outputs.

Philipp Zabel (14):
      ARM i.MX53: Add GPU clocks to clock tree
      ARM i.MX6q: export imx6q_revision
      ARM i.MX: Add imx_clk_divider_flags and imx_clk_mux_flags
      ARM i.MX53: fix ldb di divider and selector clocks
      ARM i.MX6q: fix ldb di divider and selector clocks
      ARM i.MX6q: Add audio/video PLL post dividers for i.MX6q rev 1.1
      ARM i.MX6q: set the LDB serial clock parent to the video PLL
      ARM i.MX6q: Add GPU, VPU, IPU, and OpenVG resets to System Reset Controller (SRC)
      staging: drm/imx: Use SRC to reset IPU
      ARM i.MX5: Remove tve_sel clock from i.MX53 clock tree
      ARM i.MX53: Remove unused tve_gate clkdev entry
      ARM i.MX53: make tve_ext_sel propagate rate change to PLL
      ARM i.MX53: tve_di clock is not part of the CCM, but of TVE
      ARM i.MX53: set CLK_SET_RATE_PARENT flag on the tve_ext_sel clock

Sascha Hauer (1):
      ARM: i.MX5: Add PATA and SRTC clocks

Shawn Guo (3):
      ARM: imx: do not use regmap_read for ANADIG_DIGPROG
      ARM: imx: add initial imx6dl support
      ARM: imx: do not bring up unavailable cores

 .../devicetree/bindings/clock/imx5-clock.txt       |   14 ++-
 .../devicetree/bindings/clock/imx6q-clock.txt      |    3 +
 .../devicetree/bindings/reset/fsl,imx-src.txt      |   49 ++++++++
 .../bindings/staging/imx-drm/fsl-imx-drm.txt       |    3 +
 arch/arm/Kconfig.debug                             |    4 +-
 arch/arm/configs/imx_v4_v5_defconfig               |    1 +
 arch/arm/configs/imx_v6_v7_defconfig               |    1 +
 arch/arm/mach-imx/Kconfig                          |   10 +-
 arch/arm/mach-imx/Makefile                         |    1 +
 arch/arm/mach-imx/anatop.c                         |  103 ++++++++++++++++
 arch/arm/mach-imx/clk-imx51-imx53.c                |   75 +++++++++---
 arch/arm/mach-imx/clk-imx6q.c                      |  126 ++++++++++++++++++--
 arch/arm/mach-imx/clk.h                            |   17 +++
 arch/arm/mach-imx/common.h                         |   10 +-
 arch/arm/mach-imx/gpc.c                            |   23 +++-
 arch/arm/mach-imx/mach-imx6q.c                     |   74 ++++--------
 arch/arm/mach-imx/mm-imx1.c                        |    2 +
 arch/arm/mach-imx/mxc.h                            |   11 ++
 arch/arm/mach-imx/platsmp.c                        |    4 +-
 arch/arm/mach-imx/pm-imx6q.c                       |    4 +-
 arch/arm/mach-imx/src.c                            |   65 ++++++++++
 drivers/staging/imx-drm/ipu-v3/ipu-common.c        |   12 +-
 22 files changed, 524 insertions(+), 88 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/reset/fsl,imx-src.txt
 create mode 100644 arch/arm/mach-imx/anatop.c



From daniel.lezcano at linaro.org  Fri Apr 12 08:35:47 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Fri, 12 Apr 2013 14:35:47 +0200
Subject: [V3 patch 01/19] ARM: shmobile: cpuidle: remove shmobile_enter_wfi
 function
In-Reply-To: <1365770165-27096-1-git-send-email-daniel.lezcano@linaro.org>
References: <1365770165-27096-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1365770165-27096-2-git-send-email-daniel.lezcano@linaro.org>

Remove the shmobile_enter_wfi function which is the same as the
common WFI enter function from the arm cpuidle driver defined
with the ARM_CPUIDLE_WFI_STATE macro.

Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
---
 arch/arm/mach-shmobile/pm-sh7372.c |    1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/mach-shmobile/pm-sh7372.c b/arch/arm/mach-shmobile/pm-sh7372.c
index f6b14ca..fbef7b9 100644
--- a/arch/arm/mach-shmobile/pm-sh7372.c
+++ b/arch/arm/mach-shmobile/pm-sh7372.c
@@ -414,7 +414,6 @@ static struct cpuidle_driver sh7372_cpuidle_driver = {
 	.state_count		= 5,
 	.safe_state_index	= 0, /* C1 */
 	.states[0] = ARM_CPUIDLE_WFI_STATE,
-	.states[0].enter = shmobile_enter_wfi,
 	.states[1] = {
 		.name = "C2",
 		.desc = "Core Standby Mode",
-- 
1.7.9.5



From daniel.lezcano at linaro.org  Fri Apr 12 08:35:46 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Fri, 12 Apr 2013 14:35:46 +0200
Subject: [V3 patch 00/19] cpuidle: code consolidation
Message-ID: <1365770165-27096-1-git-send-email-daniel.lezcano@linaro.org>

This patchset series provide some code consolidation across the different
cpuidle drivers. It contains two parts, the first one is the removal of
the time keeping flag and the second one, is a common initialization routine.

All the drivers use the en_core_tk_irqen flag, which means it is not necessary
to make the time computation optional. We can remove this flag and assume the
cpuidle framework always manage this operation.

The cpuidle code initialization is duplicated across the different drivers in
the same manner.

The repeating pattern is:

SMP:

cpuidle_register_driver(drv);
for_each_possible_cpu(cpu) {
        dev = per_cpu(cpuidle_device, cpu);
        cpuidle_register_device(dev);
}

UP:

cpuidle_register_driver(drv);
cpuidle_register_device(dev);

As on a UP machine the macro 'for_each_cpu' is a one iteration loop, using the
initialization loop from SMP to UP works.

The patchset does some cleanup for different drivers in order to make the init
code the same. Then it introduces a generic function:

  cpuidle_register(struct cpuidle_driver *drv, struct cpumask *cpumask)

The cpumask is for the coupled idle states.

The drivers are then modified to take into account this new function and
to remove the duplicated code.

The benefit is observable in the diffstat: 332 lines of code removed.

Changelog:

 - V3:
   * folded patch 5/19 into 19/19, they were:
     * ARM: imx: cpuidle: use init/exit common routine
     * ARM: imx: cpuidle: create separate drivers for imx5/imx6
   * removed rule to make cpuidle.o in the imx's Makefile
   * splitted patch 1/19 into two, they are:
     * [V3 patch 01/19] ARM: shmobile: cpuidle: remove shmobile_enter_wfi
     * [V3 patch 02/19] ARM: shmobile: cpuidle: remove shmobile_enter_wfi prototype

 - V2:
   * fixed cpumask NULL test for coupled state in cpuidle_register 
   * added comment about structure copy
   * changed printk by pr_err
   * folded splitted message
   * fixed return code in cpuidle_register
   * updated Documentation/cpuidle/drivers.txt
   * added in the changelog dev->state_count is filled by cpuidle_enable_device
   * fixed tag for tegra in the first line patch description
   * fixed tegra2 removed tegra_tear_down_cpu = tegra20_tear_down_cpu;

 - V1: Initial post

Tested-on: u8500
Tested-on: at91
Tested-on: intel i5
Tested-on: OMAP4

Compiled with and without CPU_IDLE for:
 u8500, at91, davinci, exynos, imx5, imx6, kirkwood, multi_v7 (for calxeda),
 omap2plus, s3c64, tegra1, tegra2, tegra3

Daniel Lezcano (19):
  ARM: shmobile: cpuidle: remove shmobile_enter_wfi function
  ARM: shmobile: cpuidle: remove shmobile_enter_wfi prototype
  ARM: OMAP3: remove cpuidle_wrap_enter
  cpuidle: remove en_core_tk_irqen flag
  ARM: ux500: cpuidle: replace for_each_online_cpu by
    for_each_possible_cpu
  cpuidle: make a single register function for all
  ARM: ux500: cpuidle: use init/exit common routine
  ARM: at91: cpuidle: use init/exit common routine
  ARM: OMAP3: cpuidle: use init/exit common routine
  ARM: s3c64xx: cpuidle: use init/exit common routine
  ARM: tegra: cpuidle: use init/exit common routine
  ARM: shmobile: cpuidle: use init/exit common routine
  ARM: OMAP4: cpuidle: use init/exit common routine
  ARM: tegra: cpuidle: use init/exit common routine for tegra2
  ARM: tegra: cpuidle: use init/exit common routine for tegra3
  ARM: calxeda: cpuidle: use init/exit common routine
  ARM: kirkwood: cpuidle: use init/exit common routine
  ARM: davinci: cpuidle: use init/exit common routine
  ARM: imx: cpuidle: use init/exit common routine

 Documentation/cpuidle/driver.txt                |    6 +
 arch/arm/mach-at91/cpuidle.c                    |   18 +--
 arch/arm/mach-davinci/cpuidle.c                 |   21 +---
 arch/arm/mach-exynos/cpuidle.c                  |    1 -
 arch/arm/mach-imx/Makefile                      |    2 +-
 arch/arm/mach-imx/cpuidle-imx5.c                |   40 +++++++
 arch/arm/mach-imx/cpuidle-imx6q.c               |    3 +-
 arch/arm/mach-imx/cpuidle.c                     |   80 -------------
 arch/arm/mach-imx/cpuidle.h                     |   10 +-
 arch/arm/mach-imx/pm-imx5.c                     |   30 +----
 arch/arm/mach-omap2/cpuidle34xx.c               |   49 ++------
 arch/arm/mach-omap2/cpuidle44xx.c               |   23 +---
 arch/arm/mach-s3c64xx/cpuidle.c                 |   15 +--
 arch/arm/mach-shmobile/cpuidle.c                |   11 +-
 arch/arm/mach-shmobile/include/mach/common.h    |    3 -
 arch/arm/mach-shmobile/pm-sh7372.c              |    2 -
 arch/arm/mach-tegra/cpuidle-tegra114.c          |   27 +----
 arch/arm/mach-tegra/cpuidle-tegra20.c           |   31 +----
 arch/arm/mach-tegra/cpuidle-tegra30.c           |   28 +----
 arch/arm/mach-ux500/cpuidle.c                   |   33 +-----
 arch/powerpc/platforms/pseries/processor_idle.c |    1 -
 arch/sh/kernel/cpu/shmobile/cpuidle.c           |    1 -
 arch/x86/kernel/apm_32.c                        |    1 -
 drivers/acpi/processor_idle.c                   |    1 -
 drivers/cpuidle/cpuidle-calxeda.c               |   53 +--------
 drivers/cpuidle/cpuidle-kirkwood.c              |   18 +--
 drivers/cpuidle/cpuidle.c                       |  144 ++++++++++++++---------
 drivers/idle/intel_idle.c                       |    1 -
 include/linux/cpuidle.h                         |   20 ++--
 29 files changed, 175 insertions(+), 498 deletions(-)
 create mode 100644 arch/arm/mach-imx/cpuidle-imx5.c
 delete mode 100644 arch/arm/mach-imx/cpuidle.c

-- 
1.7.9.5



From daniel.lezcano at linaro.org  Fri Apr 12 08:35:48 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Fri, 12 Apr 2013 14:35:48 +0200
Subject: [V3 patch 02/19] ARM: shmobile: cpuidle: remove shmobile_enter_wfi
 prototype
In-Reply-To: <1365770165-27096-1-git-send-email-daniel.lezcano@linaro.org>
References: <1365770165-27096-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1365770165-27096-3-git-send-email-daniel.lezcano@linaro.org>

Commit 688036b538974de32ce55be8b0e013b003992abc removed the function
'shmobile_enter_wfi' but we forgot to remove the definition in the header file.

Note this function is just an alias to 'cpu_do_idle()' wrapped into a cpuidle
function callback prototype which already exists with the default WFI state
and the arm_simple_enter function.

Remove the function prototype.

Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
---
 arch/arm/mach-shmobile/include/mach/common.h |    3 ---
 1 file changed, 3 deletions(-)

diff --git a/arch/arm/mach-shmobile/include/mach/common.h b/arch/arm/mach-shmobile/include/mach/common.h
index e48606d..362f9b2 100644
--- a/arch/arm/mach-shmobile/include/mach/common.h
+++ b/arch/arm/mach-shmobile/include/mach/common.h
@@ -13,9 +13,6 @@ extern int shmobile_clk_init(void);
 extern void shmobile_handle_irq_intc(struct pt_regs *);
 extern struct platform_suspend_ops shmobile_suspend_ops;
 struct cpuidle_driver;
-struct cpuidle_device;
-extern int shmobile_enter_wfi(struct cpuidle_device *dev,
-			      struct cpuidle_driver *drv, int index);
 extern void shmobile_cpuidle_set_driver(struct cpuidle_driver *drv);
 
 extern void sh7372_init_irq(void);
-- 
1.7.9.5



From daniel.lezcano at linaro.org  Fri Apr 12 08:35:49 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Fri, 12 Apr 2013 14:35:49 +0200
Subject: [V3 patch 03/19] ARM: OMAP3: remove cpuidle_wrap_enter
In-Reply-To: <1365770165-27096-1-git-send-email-daniel.lezcano@linaro.org>
References: <1365770165-27096-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1365770165-27096-4-git-send-email-daniel.lezcano@linaro.org>

In a previous commit the en_core_tk_irqen flag has been added but we missed
the cpuidle_wrap_enter which was doing the job to measure the time for the
'omap3_enter_idle' function.

Actually, I don't see any reason to use this wrapper in the code. In the better
case, the time computation is not correctly done because of the different
operations done in omap3_enter_idle_bm which were not taken into account
before the en_core_tk_irqen flag was set.

As the time is reflected for the state overridden by the omap3_enter_idle_bm,
using the wrapper is pointless now, so removing it.

Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
---
 arch/arm/mach-omap2/cpuidle34xx.c |   30 +++++++++---------------------
 1 file changed, 9 insertions(+), 21 deletions(-)

diff --git a/arch/arm/mach-omap2/cpuidle34xx.c b/arch/arm/mach-omap2/cpuidle34xx.c
index 4f67a5b..a56310a 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -99,11 +99,15 @@ static struct omap3_idle_statedata omap3_idle_data[] = {
 	},
 };
 
-/* Private functions */
-
-static int __omap3_enter_idle(struct cpuidle_device *dev,
-				struct cpuidle_driver *drv,
-				int index)
+/**
+ * omap3_enter_idle - Programs OMAP3 to enter the specified state
+ * @dev: cpuidle device
+ * @drv: cpuidle driver
+ * @index: the index of state to be entered
+ */
+static int omap3_enter_idle(struct cpuidle_device *dev,
+			    struct cpuidle_driver *drv,
+			    int index)
 {
 	struct omap3_idle_statedata *cx = &omap3_idle_data[index];
 
@@ -149,22 +153,6 @@ return_sleep_time:
 }
 
 /**
- * omap3_enter_idle - Programs OMAP3 to enter the specified state
- * @dev: cpuidle device
- * @drv: cpuidle driver
- * @index: the index of state to be entered
- *
- * Called from the CPUidle framework to program the device to the
- * specified target state selected by the governor.
- */
-static inline int omap3_enter_idle(struct cpuidle_device *dev,
-				struct cpuidle_driver *drv,
-				int index)
-{
-	return cpuidle_wrap_enter(dev, drv, index, __omap3_enter_idle);
-}
-
-/**
  * next_valid_state - Find next valid C-state
  * @dev: cpuidle device
  * @drv: cpuidle driver
-- 
1.7.9.5



From daniel.lezcano at linaro.org  Fri Apr 12 08:35:51 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Fri, 12 Apr 2013 14:35:51 +0200
Subject: [V3 patch 05/19] ARM: ux500: cpuidle: replace for_each_online_cpu by
 for_each_possible_cpu
In-Reply-To: <1365770165-27096-1-git-send-email-daniel.lezcano@linaro.org>
References: <1365770165-27096-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1365770165-27096-6-git-send-email-daniel.lezcano@linaro.org>

All the drivers are using, in their initialization function, the
for_each_possible_cpu macro.

Using for_each_online_cpu means the driver must handle the initialization
of the cpuidle device when a cpu is up which is not the case here.

Change the macro to for_each_possible_cpu as that fix the hotplug
initialization and make the initialization routine consistent with the
rest of the code in the different drivers.

Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
---
 arch/arm/mach-ux500/cpuidle.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-ux500/cpuidle.c b/arch/arm/mach-ux500/cpuidle.c
index c29c1bf..5657d4a 100644
--- a/arch/arm/mach-ux500/cpuidle.c
+++ b/arch/arm/mach-ux500/cpuidle.c
@@ -125,7 +125,7 @@ int __init ux500_idle_init(void)
 		return ret;
 	}
 
-	for_each_online_cpu(cpu) {
+	for_each_possible(cpu) {
 		device = &per_cpu(ux500_cpuidle_device, cpu);
 		device->cpu = cpu;
 		ret = cpuidle_register_device(device);
@@ -139,7 +139,7 @@ out:
 	return ret;
 
 out_unregister:
-	for_each_online_cpu(cpu) {
+	for_each_possible_cpu(cpu) {
 		device = &per_cpu(ux500_cpuidle_device, cpu);
 		cpuidle_unregister_device(device);
 	}
-- 
1.7.9.5



From daniel.lezcano at linaro.org  Fri Apr 12 08:35:53 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Fri, 12 Apr 2013 14:35:53 +0200
Subject: [V3 patch 07/19] ARM: ux500: cpuidle: use init/exit common routine
In-Reply-To: <1365770165-27096-1-git-send-email-daniel.lezcano@linaro.org>
References: <1365770165-27096-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1365770165-27096-8-git-send-email-daniel.lezcano@linaro.org>

Remove the duplicate code and use the cpuidle common code for initialization.

Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
---
 arch/arm/mach-ux500/cpuidle.c |   32 +-------------------------------
 1 file changed, 1 insertion(+), 31 deletions(-)

diff --git a/arch/arm/mach-ux500/cpuidle.c b/arch/arm/mach-ux500/cpuidle.c
index 5657d4a..488e074 100644
--- a/arch/arm/mach-ux500/cpuidle.c
+++ b/arch/arm/mach-ux500/cpuidle.c
@@ -21,7 +21,6 @@
 
 static atomic_t master = ATOMIC_INIT(0);
 static DEFINE_SPINLOCK(master_lock);
-static DEFINE_PER_CPU(struct cpuidle_device, ux500_cpuidle_device);
 
 static inline int ux500_enter_idle(struct cpuidle_device *dev,
 				   struct cpuidle_driver *drv, int index)
@@ -112,40 +111,11 @@ static struct cpuidle_driver ux500_idle_driver = {
 
 int __init ux500_idle_init(void)
 {
-	int ret, cpu;
-	struct cpuidle_device *device;
-
         /* Configure wake up reasons */
 	prcmu_enable_wakeups(PRCMU_WAKEUP(ARM) | PRCMU_WAKEUP(RTC) |
 			     PRCMU_WAKEUP(ABB));
 
-	ret = cpuidle_register_driver(&ux500_idle_driver);
-	if (ret) {
-		printk(KERN_ERR "failed to register ux500 idle driver\n");
-		return ret;
-	}
-
-	for_each_possible(cpu) {
-		device = &per_cpu(ux500_cpuidle_device, cpu);
-		device->cpu = cpu;
-		ret = cpuidle_register_device(device);
-		if (ret) {
-			printk(KERN_ERR "Failed to register cpuidle "
-			       "device for cpu%d\n", cpu);
-			goto out_unregister;
-		}
-	}
-out:
-	return ret;
-
-out_unregister:
-	for_each_possible_cpu(cpu) {
-		device = &per_cpu(ux500_cpuidle_device, cpu);
-		cpuidle_unregister_device(device);
-	}
-
-	cpuidle_unregister_driver(&ux500_idle_driver);
-	goto out;
+	return cpuidle_register(&ux500_idle_driver, NULL);
 }
 
 device_initcall(ux500_idle_init);
-- 
1.7.9.5



From daniel.lezcano at linaro.org  Fri Apr 12 08:35:52 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Fri, 12 Apr 2013 14:35:52 +0200
Subject: [V3 patch 06/19] cpuidle: make a single register function for all
In-Reply-To: <1365770165-27096-1-git-send-email-daniel.lezcano@linaro.org>
References: <1365770165-27096-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1365770165-27096-7-git-send-email-daniel.lezcano@linaro.org>

The usual scheme to initialize a cpuidle driver on a SMP is:

	cpuidle_register_driver(drv);
	for_each_possible_cpu(cpu) {
		device = &per_cpu(cpuidle_dev, cpu);
		cpuidle_register_device(device);
	}

This code is duplicated in each cpuidle driver.

On UP systems, it is done this way:

	cpuidle_register_driver(drv);
	device = &per_cpu(cpuidle_dev, cpu);
	cpuidle_register_device(device);

On UP, the macro 'for_each_cpu' does one iteration:

#define for_each_cpu(cpu, mask)                 \
        for ((cpu) = 0; (cpu) < 1; (cpu)++, (void)mask)

Hence, the initialization loop is the same for UP than SMP.

Beside, we saw different bugs / mis-initialization / return code unchecked in
the different drivers, the code is duplicated including bugs. After fixing all
these ones, it appears the initialization pattern is the same for everyone.

Please note, some drivers are doing dev->state_count = drv->state_count. This is
not necessary because it is done by the cpuidle_enable_device function in the
cpuidle framework. This is true, until you have the same states for all your
devices. Otherwise, the 'low level' API should be used instead with the specific
initialization for the driver.

Let's add a wrapper function doing this initialization with a cpumask parameter
for the coupled idle states and use it for all the drivers.

That will save a lot of LOC, consolidate the code, and the modifications in the
future could be done in a single place. Another benefit is the consolidation of
the cpuidle_device variable which is now in the cpuidle framework and no longer
spread accross the different arch specific drivers.

Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
---
 Documentation/cpuidle/driver.txt |    6 ++++
 drivers/cpuidle/cpuidle.c        |   72 ++++++++++++++++++++++++++++++++++++++
 include/linux/cpuidle.h          |    9 +++--
 3 files changed, 85 insertions(+), 2 deletions(-)

diff --git a/Documentation/cpuidle/driver.txt b/Documentation/cpuidle/driver.txt
index 7a9e09e..1b0d81d 100644
--- a/Documentation/cpuidle/driver.txt
+++ b/Documentation/cpuidle/driver.txt
@@ -15,11 +15,17 @@ has mechanisms in place to support actual entry-exit into CPU idle states.
 cpuidle driver initializes the cpuidle_device structure for each CPU device
 and registers with cpuidle using cpuidle_register_device.
 
+If all the idle states are the same, the wrapper function cpuidle_register
+could be used instead.
+
 It can also support the dynamic changes (like battery <-> AC), by using
 cpuidle_pause_and_lock, cpuidle_disable_device and cpuidle_enable_device,
 cpuidle_resume_and_unlock.
 
 Interfaces:
+extern int cpuidle_register(struct cpuidle_driver *drv,
+                            const struct cpumask *const coupled_cpus);
+extern int cpuidle_unregister(struct cpuidle_driver *drv);
 extern int cpuidle_register_driver(struct cpuidle_driver *drv);
 extern void cpuidle_unregister_driver(struct cpuidle_driver *drv);
 extern int cpuidle_register_device(struct cpuidle_device *dev);
diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
index 0da795b..49e8d30 100644
--- a/drivers/cpuidle/cpuidle.c
+++ b/drivers/cpuidle/cpuidle.c
@@ -24,6 +24,7 @@
 #include "cpuidle.h"
 
 DEFINE_PER_CPU(struct cpuidle_device *, cpuidle_devices);
+DEFINE_PER_CPU(struct cpuidle_device, cpuidle_dev);
 
 DEFINE_MUTEX(cpuidle_lock);
 LIST_HEAD(cpuidle_detected_devices);
@@ -453,6 +454,77 @@ void cpuidle_unregister_device(struct cpuidle_device *dev)
 
 EXPORT_SYMBOL_GPL(cpuidle_unregister_device);
 
+/*
+ * cpuidle_unregister: unregister a driver and the devices. This function
+ * can be used only if the driver has been previously registered through
+ * the cpuidle_register function.
+ *
+ * @drv: a valid pointer to a struct cpuidle_driver
+ */
+void cpuidle_unregister(struct cpuidle_driver *drv)
+{
+	int cpu;
+	struct cpuidle_device *device;
+
+	for_each_possible_cpu(cpu) {
+		device = &per_cpu(cpuidle_dev, cpu);
+		cpuidle_unregister_device(device);
+	}
+
+	cpuidle_unregister_driver(drv);
+}
+EXPORT_SYMBOL_GPL(cpuidle_unregister);
+
+/**
+ * cpuidle_register: registers the driver and the cpu devices with the
+ * coupled_cpus passed as parameter. This function is used for all common
+ * initialization pattern there are in the arch specific drivers. The
+ * devices is globally defined in this file.
+ *
+ * @drv         : a valid pointer to a struct cpuidle_driver
+ * @coupled_cpus: a cpumask for the coupled states
+ *
+ * Returns 0 on success, < 0 otherwise
+ */
+int cpuidle_register(struct cpuidle_driver *drv,
+		     const struct cpumask *const coupled_cpus)
+{
+	int ret, cpu;
+	struct cpuidle_device *device;
+
+	ret = cpuidle_register_driver(drv);
+	if (ret) {
+		pr_err("failed to register cpuidle driver\n");
+		return ret;
+	}
+
+	for_each_possible_cpu(cpu) {
+		device = &per_cpu(cpuidle_dev, cpu);
+		device->cpu = cpu;
+
+#ifdef CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED
+		/*
+		 * On multiplatform for ARM, the coupled idle states could
+		 * enabled in the kernel even if the cpuidle driver does not
+		 * use it. Note, coupled_cpus is a struct copy.
+		 */
+		if (coupled_cpus)
+			device->coupled_cpus = *coupled_cpus;
+#endif
+		ret = cpuidle_register_device(device);
+		if (!ret)
+			continue;
+
+		pr_err("Failed to register cpuidle device for cpu%d\n", cpu);
+
+		cpuidle_unregister(drv);
+		break;
+	}
+
+	return ret;
+}
+EXPORT_SYMBOL_GPL(cpuidle_register);
+
 #ifdef CONFIG_SMP
 
 static void smp_callback(void *v)
diff --git a/include/linux/cpuidle.h b/include/linux/cpuidle.h
index 79e3811..3c86faa 100644
--- a/include/linux/cpuidle.h
+++ b/include/linux/cpuidle.h
@@ -123,7 +123,9 @@ extern void cpuidle_driver_unref(void);
 extern void cpuidle_unregister_driver(struct cpuidle_driver *drv);
 extern int cpuidle_register_device(struct cpuidle_device *dev);
 extern void cpuidle_unregister_device(struct cpuidle_device *dev);
-
+extern int cpuidle_register(struct cpuidle_driver *drv,
+			    const struct cpumask *const coupled_cpus);
+extern void cpuidle_unregister(struct cpuidle_driver *drv);
 extern void cpuidle_pause_and_lock(void);
 extern void cpuidle_resume_and_unlock(void);
 extern void cpuidle_pause(void);
@@ -148,7 +150,10 @@ static inline void cpuidle_unregister_driver(struct cpuidle_driver *drv) { }
 static inline int cpuidle_register_device(struct cpuidle_device *dev)
 {return -ENODEV; }
 static inline void cpuidle_unregister_device(struct cpuidle_device *dev) { }
-
+static inline int cpuidle_register(struct cpuidle_driver *drv,
+				   const struct cpumask *const coupled_cpus)
+{return -ENODEV; }
+static inline void cpuidle_unregister(struct cpuidle_driver *drv) { }
 static inline void cpuidle_pause_and_lock(void) { }
 static inline void cpuidle_resume_and_unlock(void) { }
 static inline void cpuidle_pause(void) { }
-- 
1.7.9.5



From daniel.lezcano at linaro.org  Fri Apr 12 08:35:54 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Fri, 12 Apr 2013 14:35:54 +0200
Subject: [V3 patch 08/19] ARM: at91: cpuidle: use init/exit common routine
In-Reply-To: <1365770165-27096-1-git-send-email-daniel.lezcano@linaro.org>
References: <1365770165-27096-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1365770165-27096-9-git-send-email-daniel.lezcano@linaro.org>

Remove the duplicate code and use the arm cpuidle driver's common code
for initialization.

Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
Acked-by: Nicolas Ferre <nicolas.ferre at atmel.com>
---
 arch/arm/mach-at91/cpuidle.c |   17 ++---------------
 1 file changed, 2 insertions(+), 15 deletions(-)

diff --git a/arch/arm/mach-at91/cpuidle.c b/arch/arm/mach-at91/cpuidle.c
index 0130df7..48f1228 100644
--- a/arch/arm/mach-at91/cpuidle.c
+++ b/arch/arm/mach-at91/cpuidle.c
@@ -27,8 +27,6 @@
 
 #define AT91_MAX_STATES	2
 
-static DEFINE_PER_CPU(struct cpuidle_device, at91_cpuidle_device);
-
 /* Actual code that puts the SoC in different idle states */
 static int at91_enter_idle(struct cpuidle_device *dev,
 			struct cpuidle_driver *drv,
@@ -60,20 +58,9 @@ static struct cpuidle_driver at91_idle_driver = {
 };
 
 /* Initialize CPU idle by registering the idle states */
-static int at91_init_cpuidle(void)
+static int __init at91_init_cpuidle(void)
 {
-	struct cpuidle_device *device;
-
-	device = &per_cpu(at91_cpuidle_device, smp_processor_id());
-	device->state_count = AT91_MAX_STATES;
-
-	cpuidle_register_driver(&at91_idle_driver);
-
-	if (cpuidle_register_device(device)) {
-		printk(KERN_ERR "at91_init_cpuidle: Failed registering\n");
-		return -EIO;
-	}
-	return 0;
+	return cpuidle_register(&at91_idle_driver, NULL);
 }
 
 device_initcall(at91_init_cpuidle);
-- 
1.7.9.5



From daniel.lezcano at linaro.org  Fri Apr 12 08:35:55 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Fri, 12 Apr 2013 14:35:55 +0200
Subject: [V3 patch 09/19] ARM: OMAP3: cpuidle: use init/exit common routine
In-Reply-To: <1365770165-27096-1-git-send-email-daniel.lezcano@linaro.org>
References: <1365770165-27096-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1365770165-27096-10-git-send-email-daniel.lezcano@linaro.org>

Remove the duplicated code and use the cpuidle common code for initialization.

Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
---
 arch/arm/mach-omap2/cpuidle34xx.c |   18 ++----------------
 1 file changed, 2 insertions(+), 16 deletions(-)

diff --git a/arch/arm/mach-omap2/cpuidle34xx.c b/arch/arm/mach-omap2/cpuidle34xx.c
index 027a787..cca045c 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -26,6 +26,7 @@
 #include <linux/cpuidle.h>
 #include <linux/export.h>
 #include <linux/cpu_pm.h>
+#include <asm/cpuidle.h>
 
 #include "powerdomain.h"
 #include "clockdomain.h"
@@ -259,8 +260,6 @@ static int omap3_enter_idle_bm(struct cpuidle_device *dev,
 	return ret;
 }
 
-static DEFINE_PER_CPU(struct cpuidle_device, omap3_idle_dev);
-
 static struct cpuidle_driver omap3_idle_driver = {
 	.name             = "omap3_idle",
 	.owner            = THIS_MODULE,
@@ -336,8 +335,6 @@ static struct cpuidle_driver omap3_idle_driver = {
  */
 int __init omap3_idle_init(void)
 {
-	struct cpuidle_device *dev;
-
 	mpu_pd = pwrdm_lookup("mpu_pwrdm");
 	core_pd = pwrdm_lookup("core_pwrdm");
 	per_pd = pwrdm_lookup("per_pwrdm");
@@ -346,16 +343,5 @@ int __init omap3_idle_init(void)
 	if (!mpu_pd || !core_pd || !per_pd || !cam_pd)
 		return -ENODEV;
 
-	cpuidle_register_driver(&omap3_idle_driver);
-
-	dev = &per_cpu(omap3_idle_dev, smp_processor_id());
-	dev->cpu = 0;
-
-	if (cpuidle_register_device(dev)) {
-		printk(KERN_ERR "%s: CPUidle register device failed\n",
-		       __func__);
-		return -EIO;
-	}
-
-	return 0;
+	return cpuidle_register(&omap3_idle_driver, NULL);
 }
-- 
1.7.9.5



From daniel.lezcano at linaro.org  Fri Apr 12 08:35:56 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Fri, 12 Apr 2013 14:35:56 +0200
Subject: [V3 patch 10/19] ARM: s3c64xx: cpuidle: use init/exit common routine
In-Reply-To: <1365770165-27096-1-git-send-email-daniel.lezcano@linaro.org>
References: <1365770165-27096-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1365770165-27096-11-git-send-email-daniel.lezcano@linaro.org>

Remove the duplicated code and use the cpuidle common code for initialization.

Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
---
 arch/arm/mach-s3c64xx/cpuidle.c |   14 +-------------
 1 file changed, 1 insertion(+), 13 deletions(-)

diff --git a/arch/arm/mach-s3c64xx/cpuidle.c b/arch/arm/mach-s3c64xx/cpuidle.c
index 852ff16..3c8ab07 100644
--- a/arch/arm/mach-s3c64xx/cpuidle.c
+++ b/arch/arm/mach-s3c64xx/cpuidle.c
@@ -40,8 +40,6 @@ static int s3c64xx_enter_idle(struct cpuidle_device *dev,
 	return index;
 }
 
-static DEFINE_PER_CPU(struct cpuidle_device, s3c64xx_cpuidle_device);
-
 static struct cpuidle_driver s3c64xx_cpuidle_driver = {
 	.name	= "s3c64xx_cpuidle",
 	.owner  = THIS_MODULE,
@@ -60,16 +58,6 @@ static struct cpuidle_driver s3c64xx_cpuidle_driver = {
 
 static int __init s3c64xx_init_cpuidle(void)
 {
-	int ret;
-
-	cpuidle_register_driver(&s3c64xx_cpuidle_driver);
-
-	ret = cpuidle_register_device(&s3c64xx_cpuidle_device);
-	if (ret) {
-		pr_err("Failed to register cpuidle device: %d\n", ret);
-		return ret;
-	}
-
-	return 0;
+	return cpuidle_register(&s3c64xx_cpuidle_driver, NULL);
 }
 device_initcall(s3c64xx_init_cpuidle);
-- 
1.7.9.5



From daniel.lezcano at linaro.org  Fri Apr 12 08:35:57 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Fri, 12 Apr 2013 14:35:57 +0200
Subject: [V3 patch 11/19] ARM: tegra: cpuidle: use init/exit common routine
In-Reply-To: <1365770165-27096-1-git-send-email-daniel.lezcano@linaro.org>
References: <1365770165-27096-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1365770165-27096-12-git-send-email-daniel.lezcano@linaro.org>

Remove the duplicated code and use the cpuidle common code for initialization.

Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
Acked-by: Stephen Warren <swarren at nvidia.com>
---
 arch/arm/mach-tegra/cpuidle-tegra114.c |   26 +-------------------------
 1 file changed, 1 insertion(+), 25 deletions(-)

diff --git a/arch/arm/mach-tegra/cpuidle-tegra114.c b/arch/arm/mach-tegra/cpuidle-tegra114.c
index c5fadf9..1d1c602 100644
--- a/arch/arm/mach-tegra/cpuidle-tegra114.c
+++ b/arch/arm/mach-tegra/cpuidle-tegra114.c
@@ -29,31 +29,7 @@ static struct cpuidle_driver tegra_idle_driver = {
 	},
 };
 
-static DEFINE_PER_CPU(struct cpuidle_device, tegra_idle_device);
-
 int __init tegra114_cpuidle_init(void)
 {
-	int ret;
-	unsigned int cpu;
-	struct cpuidle_device *dev;
-	struct cpuidle_driver *drv = &tegra_idle_driver;
-
-	ret = cpuidle_register_driver(&tegra_idle_driver);
-	if (ret) {
-		pr_err("CPUidle driver registration failed\n");
-		return ret;
-	}
-
-	for_each_possible_cpu(cpu) {
-		dev = &per_cpu(tegra_idle_device, cpu);
-		dev->cpu = cpu;
-
-		ret = cpuidle_register_device(dev);
-		if (ret) {
-			pr_err("CPU%u: CPUidle device registration failed\n",
-				cpu);
-			return ret;
-		}
-	}
-	return 0;
+	return cpuidle_register(&tegra_idle_driver, NULL);
 }
-- 
1.7.9.5



From daniel.lezcano at linaro.org  Fri Apr 12 08:35:58 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Fri, 12 Apr 2013 14:35:58 +0200
Subject: [V3 patch 12/19] ARM: shmobile: cpuidle: use init/exit common routine
In-Reply-To: <1365770165-27096-1-git-send-email-daniel.lezcano@linaro.org>
References: <1365770165-27096-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1365770165-27096-13-git-send-email-daniel.lezcano@linaro.org>

Remove the duplicated code and use the cpuidle common code for initialization.

Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
Acked-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/cpuidle.c |   10 +---------
 1 file changed, 1 insertion(+), 9 deletions(-)

diff --git a/arch/arm/mach-shmobile/cpuidle.c b/arch/arm/mach-shmobile/cpuidle.c
index d671ae9..0afeb5c 100644
--- a/arch/arm/mach-shmobile/cpuidle.c
+++ b/arch/arm/mach-shmobile/cpuidle.c
@@ -16,7 +16,6 @@
 #include <asm/cpuidle.h>
 #include <asm/io.h>
 
-static struct cpuidle_device shmobile_cpuidle_dev;
 static struct cpuidle_driver shmobile_cpuidle_default_driver = {
 	.name			= "shmobile_cpuidle",
 	.owner			= THIS_MODULE,
@@ -34,12 +33,5 @@ void __init shmobile_cpuidle_set_driver(struct cpuidle_driver *drv)
 
 int __init shmobile_cpuidle_init(void)
 {
-	struct cpuidle_device *dev = &shmobile_cpuidle_dev;
-
-	cpuidle_register_driver(cpuidle_drv);
-
-	dev->state_count = cpuidle_drv->state_count;
-	cpuidle_register_device(dev);
-
-	return 0;
+	return cpuidle_register(cpuidle_drv, NULL);
 }
-- 
1.7.9.5



From daniel.lezcano at linaro.org  Fri Apr 12 08:35:59 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Fri, 12 Apr 2013 14:35:59 +0200
Subject: [V3 patch 13/19] ARM: OMAP4: cpuidle: use init/exit common routine
In-Reply-To: <1365770165-27096-1-git-send-email-daniel.lezcano@linaro.org>
References: <1365770165-27096-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1365770165-27096-14-git-send-email-daniel.lezcano@linaro.org>

Remove the duplicated code and use the cpuidle common code for initialization.

Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
---
 arch/arm/mach-omap2/cpuidle44xx.c |   22 ++--------------------
 1 file changed, 2 insertions(+), 20 deletions(-)

diff --git a/arch/arm/mach-omap2/cpuidle44xx.c b/arch/arm/mach-omap2/cpuidle44xx.c
index cd188de..861dd90 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -15,6 +15,7 @@
 #include <linux/cpu_pm.h>
 #include <linux/export.h>
 
+#include <asm/cpuidle.h>
 #include <asm/proc-fns.h>
 
 #include "common.h"
@@ -157,8 +158,6 @@ fail:
 	return index;
 }
 
-static DEFINE_PER_CPU(struct cpuidle_device, omap4_idle_dev);
-
 static struct cpuidle_driver omap4_idle_driver = {
 	.name				= "omap4_idle",
 	.owner				= THIS_MODULE,
@@ -207,9 +206,6 @@ static struct cpuidle_driver omap4_idle_driver = {
  */
 int __init omap4_idle_init(void)
 {
-	struct cpuidle_device *dev;
-	unsigned int cpu_id = 0;
-
 	mpu_pd = pwrdm_lookup("mpu_pwrdm");
 	cpu_pd[0] = pwrdm_lookup("cpu0_pwrdm");
 	cpu_pd[1] = pwrdm_lookup("cpu1_pwrdm");
@@ -221,19 +217,5 @@ int __init omap4_idle_init(void)
 	if (!cpu_clkdm[0] || !cpu_clkdm[1])
 		return -ENODEV;
 
-	for_each_cpu(cpu_id, cpu_online_mask) {
-		dev = &per_cpu(omap4_idle_dev, cpu_id);
-		dev->cpu = cpu_id;
-#ifdef CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED
-		dev->coupled_cpus = *cpu_online_mask;
-#endif
-		cpuidle_register_driver(&omap4_idle_driver);
-
-		if (cpuidle_register_device(dev)) {
-			pr_err("%s: CPUidle register failed\n", __func__);
-			return -EIO;
-		}
-	}
-
-	return 0;
+	return cpuidle_register(&omap4_idle_driver, cpu_online_mask);
 }
-- 
1.7.9.5



From daniel.lezcano at linaro.org  Fri Apr 12 08:36:02 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Fri, 12 Apr 2013 14:36:02 +0200
Subject: [V3 patch 16/19] ARM: calxeda: cpuidle: use init/exit common routine
In-Reply-To: <1365770165-27096-1-git-send-email-daniel.lezcano@linaro.org>
References: <1365770165-27096-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1365770165-27096-17-git-send-email-daniel.lezcano@linaro.org>

Remove the duplicated code and use the cpuidle common code for initialization.

Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
Acked-by: Rob Herring <rob.herring at calxeda.com>
---
 drivers/cpuidle/cpuidle-calxeda.c |   52 +------------------------------------
 1 file changed, 1 insertion(+), 51 deletions(-)

diff --git a/drivers/cpuidle/cpuidle-calxeda.c b/drivers/cpuidle/cpuidle-calxeda.c
index a3b56f5..e344b56 100644
--- a/drivers/cpuidle/cpuidle-calxeda.c
+++ b/drivers/cpuidle/cpuidle-calxeda.c
@@ -35,8 +35,6 @@
 extern void highbank_set_cpu_jump(int cpu, void *jump_addr);
 extern void *scu_base_addr;
 
-static struct cpuidle_device __percpu *calxeda_idle_cpuidle_devices;
-
 static inline unsigned int get_auxcr(void)
 {
 	unsigned int val;
@@ -85,19 +83,6 @@ static int calxeda_pwrdown_idle(struct cpuidle_device *dev,
 	return index;
 }
 
-static void calxeda_idle_cpuidle_devices_uninit(void)
-{
-	int i;
-	struct cpuidle_device *dev;
-
-	for_each_possible_cpu(i) {
-		dev = per_cpu_ptr(calxeda_idle_cpuidle_devices, i);
-		cpuidle_unregister_device(dev);
-	}
-
-	free_percpu(calxeda_idle_cpuidle_devices);
-}
-
 static struct cpuidle_driver calxeda_idle_driver = {
 	.name = "calxeda_idle",
 	.states = {
@@ -117,44 +102,9 @@ static struct cpuidle_driver calxeda_idle_driver = {
 
 static int __init calxeda_cpuidle_init(void)
 {
-	int cpu_id;
-	int ret;
-	struct cpuidle_device *dev;
-	struct cpuidle_driver *drv = &calxeda_idle_driver;
-
 	if (!of_machine_is_compatible("calxeda,highbank"))
 		return -ENODEV;
 
-	ret = cpuidle_register_driver(drv);
-	if (ret)
-		return ret;
-
-	calxeda_idle_cpuidle_devices = alloc_percpu(struct cpuidle_device);
-	if (calxeda_idle_cpuidle_devices == NULL) {
-		ret = -ENOMEM;
-		goto unregister_drv;
-	}
-
-	/* initialize state data for each cpuidle_device */
-	for_each_possible_cpu(cpu_id) {
-		dev = per_cpu_ptr(calxeda_idle_cpuidle_devices, cpu_id);
-		dev->cpu = cpu_id;
-		dev->state_count = drv->state_count;
-
-		ret = cpuidle_register_device(dev);
-		if (ret) {
-			pr_err("Failed to register cpu %u, error: %d\n",
-			       cpu_id, ret);
-			goto uninit;
-		}
-	}
-
-	return 0;
-
-uninit:
-	calxeda_idle_cpuidle_devices_uninit();
-unregister_drv:
-	cpuidle_unregister_driver(drv);
-	return ret;
+	return cpuidle_register(&calxeda_idle_driver, NULL);
 }
 module_init(calxeda_cpuidle_init);
-- 
1.7.9.5



From daniel.lezcano at linaro.org  Fri Apr 12 08:36:00 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Fri, 12 Apr 2013 14:36:00 +0200
Subject: [V3 patch 14/19] ARM: tegra: cpuidle: use init/exit common routine
 for tegra2
In-Reply-To: <1365770165-27096-1-git-send-email-daniel.lezcano@linaro.org>
References: <1365770165-27096-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1365770165-27096-15-git-send-email-daniel.lezcano@linaro.org>

Remove the duplicated code and use the cpuidle common code for initialization.

Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
Acked-by: Stephen Warren <swarren at nvidia.com>
---
 arch/arm/mach-tegra/cpuidle-tegra20.c |   30 +-----------------------------
 1 file changed, 1 insertion(+), 29 deletions(-)

diff --git a/arch/arm/mach-tegra/cpuidle-tegra20.c b/arch/arm/mach-tegra/cpuidle-tegra20.c
index f1f6ac4..590ec25 100644
--- a/arch/arm/mach-tegra/cpuidle-tegra20.c
+++ b/arch/arm/mach-tegra/cpuidle-tegra20.c
@@ -70,8 +70,6 @@ static struct cpuidle_driver tegra_idle_driver = {
 	.safe_state_index = 0,
 };
 
-static DEFINE_PER_CPU(struct cpuidle_device, tegra_idle_device);
-
 #ifdef CONFIG_PM_SLEEP
 #ifdef CONFIG_SMP
 static void __iomem *pmc = IO_ADDRESS(TEGRA_PMC_BASE);
@@ -220,34 +218,8 @@ static int tegra20_idle_lp2_coupled(struct cpuidle_device *dev,
 
 int __init tegra20_cpuidle_init(void)
 {
-	int ret;
-	unsigned int cpu;
-	struct cpuidle_device *dev;
-	struct cpuidle_driver *drv = &tegra_idle_driver;
-
 #ifdef CONFIG_PM_SLEEP
 	tegra_tear_down_cpu = tegra20_tear_down_cpu;
 #endif
-
-	ret = cpuidle_register_driver(&tegra_idle_driver);
-	if (ret) {
-		pr_err("CPUidle driver registration failed\n");
-		return ret;
-	}
-
-	for_each_possible_cpu(cpu) {
-		dev = &per_cpu(tegra_idle_device, cpu);
-		dev->cpu = cpu;
-#ifdef CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED
-		dev->coupled_cpus = *cpu_possible_mask;
-#endif
-
-		ret = cpuidle_register_device(dev);
-		if (ret) {
-			pr_err("CPU%u: CPUidle device registration failed\n",
-				cpu);
-			return ret;
-		}
-	}
-	return 0;
+	return cpuidle_register(&tegra_idle_driver, cpu_possible_mask);
 }
-- 
1.7.9.5



From daniel.lezcano at linaro.org  Fri Apr 12 08:36:01 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Fri, 12 Apr 2013 14:36:01 +0200
Subject: [V3 patch 15/19] ARM: tegra: cpuidle: use init/exit common routine
 for tegra3
In-Reply-To: <1365770165-27096-1-git-send-email-daniel.lezcano@linaro.org>
References: <1365770165-27096-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1365770165-27096-16-git-send-email-daniel.lezcano@linaro.org>

Remove the duplicated code and use the cpuidle common code for initialization.

Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
Acked-by: Stephen Warren <swarren at nvidia.com>
---
 arch/arm/mach-tegra/cpuidle-tegra30.c |   27 +--------------------------
 1 file changed, 1 insertion(+), 26 deletions(-)

diff --git a/arch/arm/mach-tegra/cpuidle-tegra30.c b/arch/arm/mach-tegra/cpuidle-tegra30.c
index f6a0c72..36dc2be 100644
--- a/arch/arm/mach-tegra/cpuidle-tegra30.c
+++ b/arch/arm/mach-tegra/cpuidle-tegra30.c
@@ -64,8 +64,6 @@ static struct cpuidle_driver tegra_idle_driver = {
 	},
 };
 
-static DEFINE_PER_CPU(struct cpuidle_device, tegra_idle_device);
-
 #ifdef CONFIG_PM_SLEEP
 static bool tegra30_cpu_cluster_power_down(struct cpuidle_device *dev,
 					   struct cpuidle_driver *drv,
@@ -156,31 +154,8 @@ static int tegra30_idle_lp2(struct cpuidle_device *dev,
 
 int __init tegra30_cpuidle_init(void)
 {
-	int ret;
-	unsigned int cpu;
-	struct cpuidle_device *dev;
-	struct cpuidle_driver *drv = &tegra_idle_driver;
-
 #ifdef CONFIG_PM_SLEEP
 	tegra_tear_down_cpu = tegra30_tear_down_cpu;
 #endif
-
-	ret = cpuidle_register_driver(&tegra_idle_driver);
-	if (ret) {
-		pr_err("CPUidle driver registration failed\n");
-		return ret;
-	}
-
-	for_each_possible_cpu(cpu) {
-		dev = &per_cpu(tegra_idle_device, cpu);
-		dev->cpu = cpu;
-
-		ret = cpuidle_register_device(dev);
-		if (ret) {
-			pr_err("CPU%u: CPUidle device registration failed\n",
-				cpu);
-			return ret;
-		}
-	}
-	return 0;
+	return cpuidle_register(&tegra_idle_driver, NULL);
 }
-- 
1.7.9.5



From daniel.lezcano at linaro.org  Fri Apr 12 08:36:03 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Fri, 12 Apr 2013 14:36:03 +0200
Subject: [V3 patch 17/19] ARM: kirkwood: cpuidle: use init/exit common routine
In-Reply-To: <1365770165-27096-1-git-send-email-daniel.lezcano@linaro.org>
References: <1365770165-27096-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1365770165-27096-18-git-send-email-daniel.lezcano@linaro.org>

Remove the duplicated code and use the cpuidle common code for initialization.

Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
---
 drivers/cpuidle/cpuidle-kirkwood.c |   17 ++---------------
 1 file changed, 2 insertions(+), 15 deletions(-)

diff --git a/drivers/cpuidle/cpuidle-kirkwood.c b/drivers/cpuidle/cpuidle-kirkwood.c
index 6f31524..53290e1 100644
--- a/drivers/cpuidle/cpuidle-kirkwood.c
+++ b/drivers/cpuidle/cpuidle-kirkwood.c
@@ -52,9 +52,6 @@ static struct cpuidle_driver kirkwood_idle_driver = {
 	},
 	.state_count = KIRKWOOD_MAX_STATES,
 };
-static struct cpuidle_device *device;
-
-static DEFINE_PER_CPU(struct cpuidle_device, kirkwood_cpuidle_device);
 
 /* Initialize CPU idle by registering the idle states */
 static int kirkwood_cpuidle_probe(struct platform_device *pdev)
@@ -69,22 +66,12 @@ static int kirkwood_cpuidle_probe(struct platform_device *pdev)
 	if (IS_ERR(ddr_operation_base))
 		return PTR_ERR(ddr_operation_base);
 
-	device = &per_cpu(kirkwood_cpuidle_device, smp_processor_id());
-	device->state_count = KIRKWOOD_MAX_STATES;
-
-	cpuidle_register_driver(&kirkwood_idle_driver);
-	if (cpuidle_register_device(device)) {
-		pr_err("kirkwood_init_cpuidle: Failed registering\n");
-		return -EIO;
-	}
-	return 0;
+	return cpuidle_register(&kirkwood_idle_driver, NULL);
 }
 
 int kirkwood_cpuidle_remove(struct platform_device *pdev)
 {
-	cpuidle_unregister_device(device);
-	cpuidle_unregister_driver(&kirkwood_idle_driver);
-
+	cpuidle_unregister(&kirkwood_idle_driver);
 	return 0;
 }
 
-- 
1.7.9.5



From daniel.lezcano at linaro.org  Fri Apr 12 08:35:50 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Fri, 12 Apr 2013 14:35:50 +0200
Subject: [V3 patch 04/19] cpuidle: remove en_core_tk_irqen flag
In-Reply-To: <1365770165-27096-1-git-send-email-daniel.lezcano@linaro.org>
References: <1365770165-27096-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1365770165-27096-5-git-send-email-daniel.lezcano@linaro.org>

The en_core_tk_irqen flag is set in all the cpuidle driver which
means it is not necessary to specify this flag.

Remove the flag and the code related to it.

Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
---
 arch/arm/mach-at91/cpuidle.c                    |    1 -
 arch/arm/mach-davinci/cpuidle.c                 |    1 -
 arch/arm/mach-exynos/cpuidle.c                  |    1 -
 arch/arm/mach-imx/cpuidle-imx6q.c               |    1 -
 arch/arm/mach-imx/pm-imx5.c                     |    1 -
 arch/arm/mach-omap2/cpuidle34xx.c               |    1 -
 arch/arm/mach-omap2/cpuidle44xx.c               |    1 -
 arch/arm/mach-s3c64xx/cpuidle.c                 |    1 -
 arch/arm/mach-shmobile/cpuidle.c                |    1 -
 arch/arm/mach-shmobile/pm-sh7372.c              |    1 -
 arch/arm/mach-tegra/cpuidle-tegra114.c          |    1 -
 arch/arm/mach-tegra/cpuidle-tegra20.c           |    1 -
 arch/arm/mach-tegra/cpuidle-tegra30.c           |    1 -
 arch/arm/mach-ux500/cpuidle.c                   |    1 -
 arch/powerpc/platforms/pseries/processor_idle.c |    1 -
 arch/sh/kernel/cpu/shmobile/cpuidle.c           |    1 -
 arch/x86/kernel/apm_32.c                        |    1 -
 drivers/acpi/processor_idle.c                   |    1 -
 drivers/cpuidle/cpuidle-calxeda.c               |    1 -
 drivers/cpuidle/cpuidle-kirkwood.c              |    1 -
 drivers/cpuidle/cpuidle.c                       |   72 ++++++-----------------
 drivers/idle/intel_idle.c                       |    1 -
 include/linux/cpuidle.h                         |   11 ----
 23 files changed, 18 insertions(+), 86 deletions(-)

diff --git a/arch/arm/mach-at91/cpuidle.c b/arch/arm/mach-at91/cpuidle.c
index 0c63815..0130df7 100644
--- a/arch/arm/mach-at91/cpuidle.c
+++ b/arch/arm/mach-at91/cpuidle.c
@@ -47,7 +47,6 @@ static int at91_enter_idle(struct cpuidle_device *dev,
 static struct cpuidle_driver at91_idle_driver = {
 	.name			= "at91_idle",
 	.owner			= THIS_MODULE,
-	.en_core_tk_irqen	= 1,
 	.states[0]		= ARM_CPUIDLE_WFI_STATE,
 	.states[1]		= {
 		.enter			= at91_enter_idle,
diff --git a/arch/arm/mach-davinci/cpuidle.c b/arch/arm/mach-davinci/cpuidle.c
index 22d6d4a..c2887c5 100644
--- a/arch/arm/mach-davinci/cpuidle.c
+++ b/arch/arm/mach-davinci/cpuidle.c
@@ -62,7 +62,6 @@ static int davinci_enter_idle(struct cpuidle_device *dev,
 static struct cpuidle_driver davinci_idle_driver = {
 	.name			= "cpuidle-davinci",
 	.owner			= THIS_MODULE,
-	.en_core_tk_irqen	= 1,
 	.states[0]		= ARM_CPUIDLE_WFI_STATE,
 	.states[1]		= {
 		.enter			= davinci_enter_idle,
diff --git a/arch/arm/mach-exynos/cpuidle.c b/arch/arm/mach-exynos/cpuidle.c
index fcfe025..498a7a2 100644
--- a/arch/arm/mach-exynos/cpuidle.c
+++ b/arch/arm/mach-exynos/cpuidle.c
@@ -58,7 +58,6 @@ static DEFINE_PER_CPU(struct cpuidle_device, exynos4_cpuidle_device);
 static struct cpuidle_driver exynos4_idle_driver = {
 	.name			= "exynos4_idle",
 	.owner			= THIS_MODULE,
-	.en_core_tk_irqen	= 1,
 };
 
 /* Ext-GIC nIRQ/nFIQ is the only wakeup source in AFTR */
diff --git a/arch/arm/mach-imx/cpuidle-imx6q.c b/arch/arm/mach-imx/cpuidle-imx6q.c
index a783a63..e2739ad 100644
--- a/arch/arm/mach-imx/cpuidle-imx6q.c
+++ b/arch/arm/mach-imx/cpuidle-imx6q.c
@@ -45,7 +45,6 @@ done:
 static struct cpuidle_driver imx6q_cpuidle_driver = {
 	.name = "imx6q_cpuidle",
 	.owner = THIS_MODULE,
-	.en_core_tk_irqen = 1,
 	.states = {
 		/* WFI */
 		ARM_CPUIDLE_WFI_STATE,
diff --git a/arch/arm/mach-imx/pm-imx5.c b/arch/arm/mach-imx/pm-imx5.c
index f67fd7e..4b52b3e 100644
--- a/arch/arm/mach-imx/pm-imx5.c
+++ b/arch/arm/mach-imx/pm-imx5.c
@@ -164,7 +164,6 @@ static int imx5_cpuidle_enter(struct cpuidle_device *dev,
 static struct cpuidle_driver imx5_cpuidle_driver = {
 	.name			= "imx5_cpuidle",
 	.owner			= THIS_MODULE,
-	.en_core_tk_irqen	= 1,
 	.states[0]	= {
 		.enter			= imx5_cpuidle_enter,
 		.exit_latency		= 2,
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c b/arch/arm/mach-omap2/cpuidle34xx.c
index a56310a..027a787 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -264,7 +264,6 @@ static DEFINE_PER_CPU(struct cpuidle_device, omap3_idle_dev);
 static struct cpuidle_driver omap3_idle_driver = {
 	.name             = "omap3_idle",
 	.owner            = THIS_MODULE,
-	.en_core_tk_irqen = 1,
 	.states = {
 		{
 			.enter		  = omap3_enter_idle_bm,
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c b/arch/arm/mach-omap2/cpuidle44xx.c
index f4b1b23..cd188de 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -162,7 +162,6 @@ static DEFINE_PER_CPU(struct cpuidle_device, omap4_idle_dev);
 static struct cpuidle_driver omap4_idle_driver = {
 	.name				= "omap4_idle",
 	.owner				= THIS_MODULE,
-	.en_core_tk_irqen		= 1,
 	.states = {
 		{
 			/* C1 - CPU0 ON + CPU1 ON + MPU ON */
diff --git a/arch/arm/mach-s3c64xx/cpuidle.c b/arch/arm/mach-s3c64xx/cpuidle.c
index ead5fab..852ff16 100644
--- a/arch/arm/mach-s3c64xx/cpuidle.c
+++ b/arch/arm/mach-s3c64xx/cpuidle.c
@@ -45,7 +45,6 @@ static DEFINE_PER_CPU(struct cpuidle_device, s3c64xx_cpuidle_device);
 static struct cpuidle_driver s3c64xx_cpuidle_driver = {
 	.name	= "s3c64xx_cpuidle",
 	.owner  = THIS_MODULE,
-	.en_core_tk_irqen = 1,
 	.states = {
 		{
 			.enter            = s3c64xx_enter_idle,
diff --git a/arch/arm/mach-shmobile/cpuidle.c b/arch/arm/mach-shmobile/cpuidle.c
index c872ae8..d671ae9 100644
--- a/arch/arm/mach-shmobile/cpuidle.c
+++ b/arch/arm/mach-shmobile/cpuidle.c
@@ -20,7 +20,6 @@ static struct cpuidle_device shmobile_cpuidle_dev;
 static struct cpuidle_driver shmobile_cpuidle_default_driver = {
 	.name			= "shmobile_cpuidle",
 	.owner			= THIS_MODULE,
-	.en_core_tk_irqen	= 1,
 	.states[0]		= ARM_CPUIDLE_WFI_STATE,
 	.safe_state_index	= 0, /* C1 */
 	.state_count		= 1,
diff --git a/arch/arm/mach-shmobile/pm-sh7372.c b/arch/arm/mach-shmobile/pm-sh7372.c
index fbef7b9..dec9293 100644
--- a/arch/arm/mach-shmobile/pm-sh7372.c
+++ b/arch/arm/mach-shmobile/pm-sh7372.c
@@ -410,7 +410,6 @@ static int sh7372_enter_a4s(struct cpuidle_device *dev,
 static struct cpuidle_driver sh7372_cpuidle_driver = {
 	.name			= "sh7372_cpuidle",
 	.owner			= THIS_MODULE,
-	.en_core_tk_irqen	= 1,
 	.state_count		= 5,
 	.safe_state_index	= 0, /* C1 */
 	.states[0] = ARM_CPUIDLE_WFI_STATE,
diff --git a/arch/arm/mach-tegra/cpuidle-tegra114.c b/arch/arm/mach-tegra/cpuidle-tegra114.c
index c527cff..c5fadf9 100644
--- a/arch/arm/mach-tegra/cpuidle-tegra114.c
+++ b/arch/arm/mach-tegra/cpuidle-tegra114.c
@@ -23,7 +23,6 @@
 static struct cpuidle_driver tegra_idle_driver = {
 	.name = "tegra_idle",
 	.owner = THIS_MODULE,
-	.en_core_tk_irqen = 1,
 	.state_count = 1,
 	.states = {
 		[0] = ARM_CPUIDLE_WFI_STATE_PWR(600),
diff --git a/arch/arm/mach-tegra/cpuidle-tegra20.c b/arch/arm/mach-tegra/cpuidle-tegra20.c
index b94d76a..f1f6ac4 100644
--- a/arch/arm/mach-tegra/cpuidle-tegra20.c
+++ b/arch/arm/mach-tegra/cpuidle-tegra20.c
@@ -51,7 +51,6 @@ static int tegra20_idle_lp2_coupled(struct cpuidle_device *dev,
 static struct cpuidle_driver tegra_idle_driver = {
 	.name = "tegra_idle",
 	.owner = THIS_MODULE,
-	.en_core_tk_irqen = 1,
 	.states = {
 		ARM_CPUIDLE_WFI_STATE_PWR(600),
 #ifdef CONFIG_PM_SLEEP
diff --git a/arch/arm/mach-tegra/cpuidle-tegra30.c b/arch/arm/mach-tegra/cpuidle-tegra30.c
index c4e01fe..f6a0c72 100644
--- a/arch/arm/mach-tegra/cpuidle-tegra30.c
+++ b/arch/arm/mach-tegra/cpuidle-tegra30.c
@@ -43,7 +43,6 @@ static int tegra30_idle_lp2(struct cpuidle_device *dev,
 static struct cpuidle_driver tegra_idle_driver = {
 	.name = "tegra_idle",
 	.owner = THIS_MODULE,
-	.en_core_tk_irqen = 1,
 #ifdef CONFIG_PM_SLEEP
 	.state_count = 2,
 #else
diff --git a/arch/arm/mach-ux500/cpuidle.c b/arch/arm/mach-ux500/cpuidle.c
index 1b16d9e..c29c1bf 100644
--- a/arch/arm/mach-ux500/cpuidle.c
+++ b/arch/arm/mach-ux500/cpuidle.c
@@ -94,7 +94,6 @@ out:
 static struct cpuidle_driver ux500_idle_driver = {
 	.name = "ux500_idle",
 	.owner = THIS_MODULE,
-	.en_core_tk_irqen = 1,
 	.states = {
 		ARM_CPUIDLE_WFI_STATE,
 		{
diff --git a/arch/powerpc/platforms/pseries/processor_idle.c b/arch/powerpc/platforms/pseries/processor_idle.c
index a197120..4644efa0 100644
--- a/arch/powerpc/platforms/pseries/processor_idle.c
+++ b/arch/powerpc/platforms/pseries/processor_idle.c
@@ -25,7 +25,6 @@
 struct cpuidle_driver pseries_idle_driver = {
 	.name             = "pseries_idle",
 	.owner            = THIS_MODULE,
-	.en_core_tk_irqen = 1,
 };
 
 #define MAX_IDLE_STATE_COUNT	2
diff --git a/arch/sh/kernel/cpu/shmobile/cpuidle.c b/arch/sh/kernel/cpu/shmobile/cpuidle.c
index 1ddc876..0986f21 100644
--- a/arch/sh/kernel/cpu/shmobile/cpuidle.c
+++ b/arch/sh/kernel/cpu/shmobile/cpuidle.c
@@ -55,7 +55,6 @@ static struct cpuidle_device cpuidle_dev;
 static struct cpuidle_driver cpuidle_driver = {
 	.name			= "sh_idle",
 	.owner			= THIS_MODULE,
-	.en_core_tk_irqen	= 1,
 };
 
 void sh_mobile_setup_cpuidle(void)
diff --git a/arch/x86/kernel/apm_32.c b/arch/x86/kernel/apm_32.c
index 66b5faf..53a4e27 100644
--- a/arch/x86/kernel/apm_32.c
+++ b/arch/x86/kernel/apm_32.c
@@ -373,7 +373,6 @@ static int apm_cpu_idle(struct cpuidle_device *dev,
 static struct cpuidle_driver apm_idle_driver = {
 	.name = "apm_idle",
 	.owner = THIS_MODULE,
-	.en_core_tk_irqen = 1,
 	.states = {
 		{ /* entry 0 is for polling */ },
 		{ /* entry 1 is for APM idle */
diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c
index ee255c6..f0df2c9 100644
--- a/drivers/acpi/processor_idle.c
+++ b/drivers/acpi/processor_idle.c
@@ -918,7 +918,6 @@ static int acpi_idle_enter_bm(struct cpuidle_device *dev,
 struct cpuidle_driver acpi_idle_driver = {
 	.name =		"acpi_idle",
 	.owner =	THIS_MODULE,
-	.en_core_tk_irqen = 1,
 };
 
 /**
diff --git a/drivers/cpuidle/cpuidle-calxeda.c b/drivers/cpuidle/cpuidle-calxeda.c
index e1aab38..a3b56f5 100644
--- a/drivers/cpuidle/cpuidle-calxeda.c
+++ b/drivers/cpuidle/cpuidle-calxeda.c
@@ -100,7 +100,6 @@ static void calxeda_idle_cpuidle_devices_uninit(void)
 
 static struct cpuidle_driver calxeda_idle_driver = {
 	.name = "calxeda_idle",
-	.en_core_tk_irqen = 1,
 	.states = {
 		ARM_CPUIDLE_WFI_STATE,
 		{
diff --git a/drivers/cpuidle/cpuidle-kirkwood.c b/drivers/cpuidle/cpuidle-kirkwood.c
index 53aad73..6f31524 100644
--- a/drivers/cpuidle/cpuidle-kirkwood.c
+++ b/drivers/cpuidle/cpuidle-kirkwood.c
@@ -41,7 +41,6 @@ static int kirkwood_enter_idle(struct cpuidle_device *dev,
 static struct cpuidle_driver kirkwood_idle_driver = {
 	.name			= "kirkwood_idle",
 	.owner			= THIS_MODULE,
-	.en_core_tk_irqen	= 1,
 	.states[0]		= ARM_CPUIDLE_WFI_STATE,
 	.states[1]		= {
 		.enter			= kirkwood_enter_idle,
diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
index c500370..0da795b 100644
--- a/drivers/cpuidle/cpuidle.c
+++ b/drivers/cpuidle/cpuidle.c
@@ -43,24 +43,6 @@ void disable_cpuidle(void)
 
 static int __cpuidle_register_device(struct cpuidle_device *dev);
 
-static inline int cpuidle_enter(struct cpuidle_device *dev,
-				struct cpuidle_driver *drv, int index)
-{
-	struct cpuidle_state *target_state = &drv->states[index];
-	return target_state->enter(dev, drv, index);
-}
-
-static inline int cpuidle_enter_tk(struct cpuidle_device *dev,
-			       struct cpuidle_driver *drv, int index)
-{
-	return cpuidle_wrap_enter(dev, drv, index, cpuidle_enter);
-}
-
-typedef int (*cpuidle_enter_t)(struct cpuidle_device *dev,
-			       struct cpuidle_driver *drv, int index);
-
-static cpuidle_enter_t cpuidle_enter_ops;
-
 /**
  * cpuidle_play_dead - cpu off-lining
  *
@@ -90,11 +72,27 @@ int cpuidle_play_dead(void)
  * @next_state: index into drv->states of the state to enter
  */
 int cpuidle_enter_state(struct cpuidle_device *dev, struct cpuidle_driver *drv,
-		int next_state)
+			int index)
 {
 	int entered_state;
 
-	entered_state = cpuidle_enter_ops(dev, drv, next_state);
+	struct cpuidle_state *target_state = &drv->states[index];
+	ktime_t time_start, time_end;
+	s64 diff;
+
+	time_start = ktime_get();
+
+	entered_state = target_state->enter(dev, drv, index);
+
+	time_end = ktime_get();
+
+	local_irq_enable();
+
+	diff = ktime_to_us(ktime_sub(time_end, time_start));
+	if (diff > INT_MAX)
+		diff = INT_MAX;
+
+	dev->last_residency = (int) diff;
 
 	if (entered_state >= 0) {
 		/* Update cpuidle counters */
@@ -231,37 +229,6 @@ void cpuidle_resume(void)
 	mutex_unlock(&cpuidle_lock);
 }
 
-/**
- * cpuidle_wrap_enter - performs timekeeping and irqen around enter function
- * @dev: pointer to a valid cpuidle_device object
- * @drv: pointer to a valid cpuidle_driver object
- * @index: index of the target cpuidle state.
- */
-int cpuidle_wrap_enter(struct cpuidle_device *dev,
-				struct cpuidle_driver *drv, int index,
-				int (*enter)(struct cpuidle_device *dev,
-					struct cpuidle_driver *drv, int index))
-{
-	ktime_t time_start, time_end;
-	s64 diff;
-
-	time_start = ktime_get();
-
-	index = enter(dev, drv, index);
-
-	time_end = ktime_get();
-
-	local_irq_enable();
-
-	diff = ktime_to_us(ktime_sub(time_end, time_start));
-	if (diff > INT_MAX)
-		diff = INT_MAX;
-
-	dev->last_residency = (int) diff;
-
-	return index;
-}
-
 #ifdef CONFIG_ARCH_HAS_CPU_RELAX
 static int poll_idle(struct cpuidle_device *dev,
 		struct cpuidle_driver *drv, int index)
@@ -333,9 +300,6 @@ int cpuidle_enable_device(struct cpuidle_device *dev)
 			return ret;
 	}
 
-	cpuidle_enter_ops = drv->en_core_tk_irqen ?
-		cpuidle_enter_tk : cpuidle_enter;
-
 	poll_idle_init(drv);
 
 	ret = cpuidle_add_device_sysfs(dev);
diff --git a/drivers/idle/intel_idle.c b/drivers/idle/intel_idle.c
index 5d66750..48d7584 100644
--- a/drivers/idle/intel_idle.c
+++ b/drivers/idle/intel_idle.c
@@ -71,7 +71,6 @@
 static struct cpuidle_driver intel_idle_driver = {
 	.name = "intel_idle",
 	.owner = THIS_MODULE,
-	.en_core_tk_irqen = 1,
 };
 /* intel_idle.max_cstate=0 disables driver */
 static int max_cstate = CPUIDLE_STATE_MAX - 1;
diff --git a/include/linux/cpuidle.h b/include/linux/cpuidle.h
index fc3e580..79e3811 100644
--- a/include/linux/cpuidle.h
+++ b/include/linux/cpuidle.h
@@ -105,8 +105,6 @@ struct cpuidle_driver {
 	struct module 		*owner;
 	int                     refcnt;
 
-	/* set to 1 to use the core cpuidle time keeping (for all states). */
-	unsigned int		en_core_tk_irqen:1;
         /* used by the cpuidle framework to setup the broadcast timer */
 	unsigned int            bctimer:1;
 	/* states array must be ordered in decreasing power consumption */
@@ -132,10 +130,6 @@ extern void cpuidle_pause(void);
 extern void cpuidle_resume(void);
 extern int cpuidle_enable_device(struct cpuidle_device *dev);
 extern void cpuidle_disable_device(struct cpuidle_device *dev);
-extern int cpuidle_wrap_enter(struct cpuidle_device *dev,
-				struct cpuidle_driver *drv, int index,
-				int (*enter)(struct cpuidle_device *dev,
-					struct cpuidle_driver *drv, int index));
 extern int cpuidle_play_dead(void);
 
 extern struct cpuidle_driver *cpuidle_get_cpu_driver(struct cpuidle_device *dev);
@@ -162,11 +156,6 @@ static inline void cpuidle_resume(void) { }
 static inline int cpuidle_enable_device(struct cpuidle_device *dev)
 {return -ENODEV; }
 static inline void cpuidle_disable_device(struct cpuidle_device *dev) { }
-static inline int cpuidle_wrap_enter(struct cpuidle_device *dev,
-				struct cpuidle_driver *drv, int index,
-				int (*enter)(struct cpuidle_device *dev,
-					struct cpuidle_driver *drv, int index))
-{ return -ENODEV; }
 static inline int cpuidle_play_dead(void) {return -ENODEV; }
 #endif
 
-- 
1.7.9.5



From daniel.lezcano at linaro.org  Fri Apr 12 08:36:04 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Fri, 12 Apr 2013 14:36:04 +0200
Subject: [V3 patch 18/19] ARM: davinci: cpuidle: use init/exit common routine
In-Reply-To: <1365770165-27096-1-git-send-email-daniel.lezcano@linaro.org>
References: <1365770165-27096-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1365770165-27096-19-git-send-email-daniel.lezcano@linaro.org>

Remove the duplicated code and use the cpuidle common code for initialization.

Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
---
 arch/arm/mach-davinci/cpuidle.c |   20 +-------------------
 1 file changed, 1 insertion(+), 19 deletions(-)

diff --git a/arch/arm/mach-davinci/cpuidle.c b/arch/arm/mach-davinci/cpuidle.c
index c2887c5..36aef3a 100644
--- a/arch/arm/mach-davinci/cpuidle.c
+++ b/arch/arm/mach-davinci/cpuidle.c
@@ -25,7 +25,6 @@
 
 #define DAVINCI_CPUIDLE_MAX_STATES	2
 
-static DEFINE_PER_CPU(struct cpuidle_device, davinci_cpuidle_device);
 static void __iomem *ddr2_reg_base;
 static bool ddr2_pdown;
 
@@ -76,12 +75,8 @@ static struct cpuidle_driver davinci_idle_driver = {
 
 static int __init davinci_cpuidle_probe(struct platform_device *pdev)
 {
-	int ret;
-	struct cpuidle_device *device;
 	struct davinci_cpuidle_config *pdata = pdev->dev.platform_data;
 
-	device = &per_cpu(davinci_cpuidle_device, smp_processor_id());
-
 	if (!pdata) {
 		dev_err(&pdev->dev, "cannot get platform data\n");
 		return -ENOENT;
@@ -91,20 +86,7 @@ static int __init davinci_cpuidle_probe(struct platform_device *pdev)
 
 	ddr2_pdown = pdata->ddr2_pdown;
 
-	ret = cpuidle_register_driver(&davinci_idle_driver);
-	if (ret) {
-		dev_err(&pdev->dev, "failed to register driver\n");
-		return ret;
-	}
-
-	ret = cpuidle_register_device(device);
-	if (ret) {
-		dev_err(&pdev->dev, "failed to register device\n");
-		cpuidle_unregister_driver(&davinci_idle_driver);
-		return ret;
-	}
-
-	return 0;
+	return cpuidle_register(&davinci_idle_driver, NULL);
 }
 
 static struct platform_driver davinci_cpuidle_driver = {
-- 
1.7.9.5



From daniel.lezcano at linaro.org  Fri Apr 12 08:36:05 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Fri, 12 Apr 2013 14:36:05 +0200
Subject: [V3 patch 19/19] ARM: imx: cpuidle: use init/exit common routine
In-Reply-To: <1365770165-27096-1-git-send-email-daniel.lezcano@linaro.org>
References: <1365770165-27096-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1365770165-27096-20-git-send-email-daniel.lezcano@linaro.org>

The code intializes the cpuidle driver at different places.
The cpuidle driver for :
  * imx5 : is in the pm-imx5.c, the init function is in cpuidle.c
  * imx6 : is in cpuidle-imx6q.c, the init function is in cpuidle.c
           and cpuidle-imx6q.c

Instead of having the cpuidle code spread across different files,
let's create a driver for each SoC and use the common register function.

Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
---
 arch/arm/mach-imx/Makefile        |    2 +-
 arch/arm/mach-imx/cpuidle-imx5.c  |   40 +++++++++++++++++++
 arch/arm/mach-imx/cpuidle-imx6q.c |    2 +-
 arch/arm/mach-imx/cpuidle.c       |   80 -------------------------------------
 arch/arm/mach-imx/cpuidle.h       |   10 ++---
 arch/arm/mach-imx/pm-imx5.c       |   29 +-------------
 6 files changed, 47 insertions(+), 116 deletions(-)
 create mode 100644 arch/arm/mach-imx/cpuidle-imx5.c
 delete mode 100644 arch/arm/mach-imx/cpuidle.c

diff --git a/arch/arm/mach-imx/Makefile b/arch/arm/mach-imx/Makefile
index c4ce090..cb70961 100644
--- a/arch/arm/mach-imx/Makefile
+++ b/arch/arm/mach-imx/Makefile
@@ -30,7 +30,7 @@ obj-$(CONFIG_MXC_DEBUG_BOARD) += 3ds_debugboard.o
 obj-$(CONFIG_CPU_FREQ_IMX)    += cpufreq.o
 
 ifeq ($(CONFIG_CPU_IDLE),y)
-obj-y += cpuidle.o
+obj-$(CONFIG_SOC_IMX5) += cpuidle-imx5.o
 obj-$(CONFIG_SOC_IMX6Q) += cpuidle-imx6q.o
 endif
 
diff --git a/arch/arm/mach-imx/cpuidle-imx5.c b/arch/arm/mach-imx/cpuidle-imx5.c
new file mode 100644
index 0000000..ba4565f
--- /dev/null
+++ b/arch/arm/mach-imx/cpuidle-imx5.c
@@ -0,0 +1,40 @@
+/*
+ * Copyright (C) 2012 Freescale Semiconductor, Inc.
+ *
+ * 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/cpuidle.h>
+#include <linux/module.h>
+#include <asm/system_misc.h>
+#include <asm/proc-fns.h>
+
+#include "hardware.h"
+
+static int imx5_cpuidle_enter(struct cpuidle_device *dev,
+			      struct cpuidle_driver *drv, int index)
+{
+	arm_pm_idle();
+	return index;
+}
+
+static struct cpuidle_driver imx5_cpuidle_driver = {
+	.name             = "imx5_cpuidle",
+	.owner            = THIS_MODULE,
+	.states[0] = {
+		.enter            = imx5_cpuidle_enter,
+		.exit_latency     = 2,
+		.target_residency = 1,
+		.flags            = CPUIDLE_FLAG_TIME_VALID,
+		.name             = "IMX5 SRPG",
+		.desc             = "CPU state retained,powered off",
+	},
+	.state_count = 1,
+};
+
+int __init imx5_cpuidle_init(void)
+{
+	return cpuidle_register(&imx5_cpuidle_driver, NULL);
+}
diff --git a/arch/arm/mach-imx/cpuidle-imx6q.c b/arch/arm/mach-imx/cpuidle-imx6q.c
index e2739ad..23ddfb6 100644
--- a/arch/arm/mach-imx/cpuidle-imx6q.c
+++ b/arch/arm/mach-imx/cpuidle-imx6q.c
@@ -71,5 +71,5 @@ int __init imx6q_cpuidle_init(void)
 	/* Set chicken bit to get a reliable WAIT mode support */
 	imx6q_set_chicken_bit();
 
-	return imx_cpuidle_init(&imx6q_cpuidle_driver);
+	return cpuidle_register(&imx6q_cpuidle_driver, NULL);
 }
diff --git a/arch/arm/mach-imx/cpuidle.c b/arch/arm/mach-imx/cpuidle.c
deleted file mode 100644
index d4cb511..0000000
--- a/arch/arm/mach-imx/cpuidle.c
+++ /dev/null
@@ -1,80 +0,0 @@
-/*
- * Copyright 2012 Freescale Semiconductor, Inc.
- * Copyright 2012 Linaro Ltd.
- *
- * The code contained herein is licensed under the GNU General Public
- * License. You may obtain a copy of the GNU General Public License
- * Version 2 or later at the following locations:
- *
- * http://www.opensource.org/licenses/gpl-license.html
- * http://www.gnu.org/copyleft/gpl.html
- */
-
-#include <linux/cpuidle.h>
-#include <linux/err.h>
-#include <linux/hrtimer.h>
-#include <linux/io.h>
-#include <linux/kernel.h>
-#include <linux/slab.h>
-
-static struct cpuidle_device __percpu * imx_cpuidle_devices;
-
-static void __init imx_cpuidle_devices_uninit(void)
-{
-	int cpu_id;
-	struct cpuidle_device *dev;
-
-	for_each_possible_cpu(cpu_id) {
-		dev = per_cpu_ptr(imx_cpuidle_devices, cpu_id);
-		cpuidle_unregister_device(dev);
-	}
-
-	free_percpu(imx_cpuidle_devices);
-}
-
-int __init imx_cpuidle_init(struct cpuidle_driver *drv)
-{
-	struct cpuidle_device *dev;
-	int cpu_id, ret;
-
-	if (drv->state_count > CPUIDLE_STATE_MAX) {
-		pr_err("%s: state_count exceeds maximum\n", __func__);
-		return -EINVAL;
-	}
-
-	ret = cpuidle_register_driver(drv);
-	if (ret) {
-		pr_err("%s: Failed to register cpuidle driver with error: %d\n",
-			 __func__, ret);
-		return ret;
-	}
-
-	imx_cpuidle_devices = alloc_percpu(struct cpuidle_device);
-	if (imx_cpuidle_devices == NULL) {
-		ret = -ENOMEM;
-		goto unregister_drv;
-	}
-
-	/* initialize state data for each cpuidle_device */
-	for_each_possible_cpu(cpu_id) {
-		dev = per_cpu_ptr(imx_cpuidle_devices, cpu_id);
-		dev->cpu = cpu_id;
-		dev->state_count = drv->state_count;
-
-		ret = cpuidle_register_device(dev);
-		if (ret) {
-			pr_err("%s: Failed to register cpu %u, error: %d\n",
-				__func__, cpu_id, ret);
-			goto uninit;
-		}
-	}
-
-	return 0;
-
-uninit:
-	imx_cpuidle_devices_uninit();
-
-unregister_drv:
-	cpuidle_unregister_driver(drv);
-	return ret;
-}
diff --git a/arch/arm/mach-imx/cpuidle.h b/arch/arm/mach-imx/cpuidle.h
index e092d13..786f98e 100644
--- a/arch/arm/mach-imx/cpuidle.h
+++ b/arch/arm/mach-imx/cpuidle.h
@@ -10,18 +10,16 @@
  * http://www.gnu.org/copyleft/gpl.html
  */
 
-#include <linux/cpuidle.h>
-
 #ifdef CONFIG_CPU_IDLE
-extern int imx_cpuidle_init(struct cpuidle_driver *drv);
+extern int imx5_cpuidle_init(void);
 extern int imx6q_cpuidle_init(void);
 #else
-static inline int imx_cpuidle_init(struct cpuidle_driver *drv)
+static inline int imx5_cpuidle_init(void)
 {
-	return -ENODEV;
+	return 0;
 }
 static inline int imx6q_cpuidle_init(void)
 {
-	return -ENODEV;
+	return 0;
 }
 #endif
diff --git a/arch/arm/mach-imx/pm-imx5.c b/arch/arm/mach-imx/pm-imx5.c
index 4b52b3e..82e79c6 100644
--- a/arch/arm/mach-imx/pm-imx5.c
+++ b/arch/arm/mach-imx/pm-imx5.c
@@ -149,32 +149,6 @@ static void imx5_pm_idle(void)
 	imx5_cpu_do_idle();
 }
 
-static int imx5_cpuidle_enter(struct cpuidle_device *dev,
-				struct cpuidle_driver *drv, int idx)
-{
-	int ret;
-
-	ret = imx5_cpu_do_idle();
-	if (ret < 0)
-		return ret;
-
-	return idx;
-}
-
-static struct cpuidle_driver imx5_cpuidle_driver = {
-	.name			= "imx5_cpuidle",
-	.owner			= THIS_MODULE,
-	.states[0]	= {
-		.enter			= imx5_cpuidle_enter,
-		.exit_latency		= 2,
-		.target_residency	= 1,
-		.flags			= CPUIDLE_FLAG_TIME_VALID,
-		.name			= "IMX5 SRPG",
-		.desc			= "CPU state retained,powered off",
-	},
-	.state_count		= 1,
-};
-
 static int __init imx5_pm_common_init(void)
 {
 	int ret;
@@ -192,8 +166,7 @@ static int __init imx5_pm_common_init(void)
 	/* Set the registers to the default cpu idle state. */
 	mx5_cpu_lp_set(IMX5_DEFAULT_CPU_IDLE_STATE);
 
-	imx_cpuidle_init(&imx5_cpuidle_driver);
-	return 0;
+	return imx5_cpuidle_init();
 }
 
 void __init imx51_pm_init(void)
-- 
1.7.9.5



From hechtb at gmail.com  Fri Apr 12 08:46:15 2013
From: hechtb at gmail.com (Bastian Hecht)
Date: Fri, 12 Apr 2013 14:46:15 +0200
Subject: [PATCH v4 7/7] ARM: mach-shmobile: r8a7740: Setup the timer CMT10
 using DT
In-Reply-To: <20130412012350.GA25941@verge.net.au>
References: <1365679443-25456-1-git-send-email-hechtb+renesas@gmail.com>
 <1365679443-25456-7-git-send-email-hechtb+renesas@gmail.com>
 <20130412012350.GA25941@verge.net.au>
Message-ID: <CABYn4szS=dLwQbnWe4rY==yomeefoLc7NNCR+KfM8pO3L5ihmQ@mail.gmail.com>

Hello Simon,

2013/4/12 Simon Horman <horms at verge.net.au>:
> On Thu, Apr 11, 2013 at 01:24:03PM +0200, Bastian Hecht wrote:
>> We can now use the Device Tree for bringing up our timer device CMT10 on
>> the SoC r8a7740.
>
> Hi Bastian,
>
> unfortunately with this patch the armaillo800eva no longer boots.
>
> I am testing  against renesas-next-20130411v2 with the other
> 6 patches in this series applied. I am using the armadillo800eva defconfig.
> The boot log is below.

Ouch, sorry! I checked the patches and somehow I missed a chunk in
0007-... when I rebased the series to next. The part that actually
adds the DT info to r8a7740.dtsi. Further we need the GIC to be
present in the DT to make things work here (my old patch used the
INTCA as interrupt controller reference, but that has gone in the
meantime).
I want to repost my A1 reference code soon and in there I add the way
to set up the GIC via DT.

To accelerate things maybe we take 0001-0006 now and postpone 0007
until the GIC is in the DT?
I diffed the new patches against the v3 series, and the .dtsi chunk is
the only one that didn't make it, so I strongly believe the series is
fine now.

Thanks,

 Bastian


From hechtb at gmail.com  Fri Apr 12 08:54:46 2013
From: hechtb at gmail.com (Bastian Hecht)
Date: Fri, 12 Apr 2013 14:54:46 +0200
Subject: [PATCH v2 1/2] ARM: shmobile: r8a7740: Add Suspend-To-RAM A3SM
In-Reply-To: <20130412005635.GG24461@verge.net.au>
References: <1365689264-14410-1-git-send-email-hechtb+renesas@gmail.com>
 <20130412005635.GG24461@verge.net.au>
Message-ID: <CABYn4sx6czjsCqF0UQf3qD1h4sj9Si1AmtMSogEjjdbTuy7zzQ@mail.gmail.com>

Hi Simon,

2013/4/12 Simon Horman <horms at verge.net.au>:
> On Thu, Apr 11, 2013 at 04:07:43PM +0200, Bastian Hecht wrote:
>> We add 2 Suspend to RAM modes:
>> - A3SM PLL0 on/off:     Power domain A3SM that contains the ARM core
>>                         and the 2nd level cache with either PLL0 on
>>                         or off
>>
>> As the suspend to memory mechanism we use A3SM PLL off. A3SM PLL on
>> is included here too, so CPUIdle can use both power down modes (not
>> included in this patch).
>>
>> The setup of the SYSC regarding the external IRQs is taken from
>> pm-sh7372.c from Magnus Damm.
>>
>> Signed-off-by: Bastian Hecht <hechtb+renesas at gmail.com>
>> ---
>> This patch relies on
>> ARM: hw_breakpoint: Do not use __cpuinitdata for dbg_cpu_pm_nb
>>
>> v2: successor to [PATCH] ARM: shmobile: r8a7740: Add Suspend-To-RAM modes and CPUIdle
>>
>> - Removed the 2nd L1 flush in the asm shutdown code. See comment in code for explanation.
>> - Reworked the ifdefs: We can only use CPUIdle if SUSPEND is set as well.
>> - Removed cpu_do_idle() in r8a7740_enter_suspend: We don't want to sleep twice...
>>
>> If you want to test this use this workaround in the st1232 driver in
>> drivers/input/touchscreen/st1232.c:
>>
>>         error = request_threaded_irq(client->irq, NULL, st1232_ts_irq_handler,
>> -                                    IRQF_ONESHOT, client->name, ts);
>> +                                    IRQF_NO_SUSPEND | IRQF_ONESHOT, client->name, ts);
>>
>> You need it as the current irqpin driver doesn't handle wakeup devices properly yet.
>>
>> Tested with the 4 possiblities        L2 on - Suspend on/off - CPUIdle on/off
>> and with the additional test  L2 off - Suspend on - CPUIdle on
>
> Hi Bastian,
>
> are the pre-requisites listed above likely to be in v3.11-rc1 or rc2?

I probably was a bit incorrect by saying "relies on". Right now the
complete suspend system is broken on ARM UP systems. So I think we can
use this patch without coordination regarding the other patch. It's
just when you want to test this here, then you need the above
mentioned patch to fix the system first before you can do anything.

Cheers,

 Bastian


From broonie at kernel.org  Fri Apr 12 08:55:21 2013
From: broonie at kernel.org (Mark Brown)
Date: Fri, 12 Apr 2013 13:55:21 +0100
Subject: [PATCH v2] spi: s3c64xx: move to generic dmaengine API
In-Reply-To: <201304112242.03252.arnd@arndb.de>
References: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
 <1365638712-1028578-30-git-send-email-arnd@arndb.de>
 <20130411165536.GO9243@opensource.wolfsonmicro.com>
 <201304112242.03252.arnd@arndb.de>
Message-ID: <20130412125521.GA12534@opensource.wolfsonmicro.com>

On Thu, Apr 11, 2013 at 10:42:03PM +0200, Arnd Bergmann wrote:
> The spi-s3c64xx uses a Samsung proprietary interface for
> talking to the DMA engine, which does not work with
> multiplatform kernels.

Applied, thanks.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130412/88450ddb/attachment.sig>

From eric.dumazet at gmail.com  Fri Apr 12 08:55:39 2013
From: eric.dumazet at gmail.com (Eric Dumazet)
Date: Fri, 12 Apr 2013 05:55:39 -0700
Subject: [PATCH v2] net: mv643xx_eth: remove deprecated inet_lro support
In-Reply-To: <1365758400-12565-1-git-send-email-sebastian.hesselbarth@gmail.com>
References: <1365707488-28819-1-git-send-email-sebastian.hesselbarth@gmail.com>
 <1365758400-12565-1-git-send-email-sebastian.hesselbarth@gmail.com>
Message-ID: <1365771339.4459.0.camel@edumazet-glaptop>

On Fri, 2013-04-12 at 11:20 +0200, Sebastian Hesselbarth wrote:
> With recent support for GRO, there is no need to keep both LRO and
> GRO. This patch therefore removes the deprecated inet_lro support
> from mv643xx_eth. This is work is based on an experimental patch
> provided by Eric Dumazet and Willy Tarreau.
> 
> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
> Based-on-patch-by: Eric Dumazet <eric.dumazet at gmail.com>
> Based-on-patch-by: Willy Tarreau <w at 1wt.eu>
> ---
> Changes from v1:
> - also remove INET_LRO from Kconfig (Reported by Eric Dumazet)

Thanks for finishing this patch

Signed-off-by: Eric Dumazet <edumazet at google.com>




From mfuzzey at parkeon.com  Fri Apr 12 08:56:21 2013
From: mfuzzey at parkeon.com (Martin Fuzzey)
Date: Fri, 12 Apr 2013 14:56:21 +0200
Subject: [PATCH] SPI: spidev: Add DT compatible string for spidev driver.
Message-ID: <20130412125621.9645.78102.stgit@localhost>

The spidev driver is useful to allow userspace access
to SPI devices that have no kernel SPI driver.

However DT requires a compatible tree to allow the driver
to be probed.

To avoid having to modify the driver for every extra device
add a generic "linux,spidev" compatible string that may be
used in the DT to match such devices.

Signed-off-by: Martin Fuzzey <mfuzzey at parkeon.com>
---
 Documentation/devicetree/bindings/spi/spi-bus.txt |    3 +++
 drivers/spi/spidev.c                              |    1 +
 2 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/Documentation/devicetree/bindings/spi/spi-bus.txt b/Documentation/devicetree/bindings/spi/spi-bus.txt
index 296015e..3176587 100644
--- a/Documentation/devicetree/bindings/spi/spi-bus.txt
+++ b/Documentation/devicetree/bindings/spi/spi-bus.txt
@@ -59,6 +59,9 @@ contain the following properties.
 If a gpio chipselect is used for the SPI slave the gpio number will be passed
 via the cs_gpio
 
+For slave devices having no kernel driver the compatible string "linux,spidev"
+may be used to enable access from userspace via the spidev driver.
+
 SPI example for an MPC5200 SPI bus:
 	spi at f00 {
 		#address-cells = <1>;
diff --git a/drivers/spi/spidev.c b/drivers/spi/spidev.c
index 2e0655d..c2447a8 100644
--- a/drivers/spi/spidev.c
+++ b/drivers/spi/spidev.c
@@ -646,6 +646,7 @@ static int spidev_remove(struct spi_device *spi)
 
 static const struct of_device_id spidev_dt_ids[] = {
 	{ .compatible = "rohm,dh2228fv" },
+	{ .compatible = "linux,spidev" },
 	{},
 };
 



From marc.zyngier at arm.com  Fri Apr 12 09:00:16 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Fri, 12 Apr 2013 14:00:16 +0100
Subject: [PATCH] ARM: KVM: fix L_PTE_S2_RDWR to actually be Read/Write
Message-ID: <1365771616-7380-1-git-send-email-marc.zyngier@arm.com>

Looks like our L_PTE_S2_RDWR definition is slightly wrong,
and is actually write only (see ARM ARM Table B3-9, Stage 2 control
of access permissions). Didn't make a difference for normal pages,
as we OR the flags together, but I'm still wondering how it worked
for Stage-2 mapped devices, such as the GIC.

Brown paper bag time, again.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm/include/asm/pgtable-3level.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/pgtable-3level.h b/arch/arm/include/asm/pgtable-3level.h
index 6ef8afd..86b8fe3 100644
--- a/arch/arm/include/asm/pgtable-3level.h
+++ b/arch/arm/include/asm/pgtable-3level.h
@@ -111,7 +111,7 @@
 #define L_PTE_S2_MT_WRITETHROUGH (_AT(pteval_t, 0xa) << 2) /* MemAttr[3:0] */
 #define L_PTE_S2_MT_WRITEBACK	 (_AT(pteval_t, 0xf) << 2) /* MemAttr[3:0] */
 #define L_PTE_S2_RDONLY		 (_AT(pteval_t, 1) << 6)   /* HAP[1]   */
-#define L_PTE_S2_RDWR		 (_AT(pteval_t, 2) << 6)   /* HAP[2:1] */
+#define L_PTE_S2_RDWR		 (_AT(pteval_t, 3) << 6)   /* HAP[2:1] */
 
 /*
  * Hyp-mode PL2 PTE definitions for LPAE.
-- 
1.8.1.4




From arnd at arndb.de  Fri Apr 12 09:01:48 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 12 Apr 2013 15:01:48 +0200
Subject: [PATCH] ARM: pci: pass a parent to pci_common_init()
In-Reply-To: <20130412120538.GA32488@arm.com>
References: <1365719096-11639-1-git-send-email-linus.walleij@linaro.org>
 <201304121326.56030.arnd@arndb.de> <20130412120538.GA32488@arm.com>
Message-ID: <201304121501.48866.arnd@arndb.de>

On Friday 12 April 2013, Andrew Murray wrote:
> I would also be happy with this. Though alternatively could you
> not just add a struct device to hw_pci? Then change pcibios_init_hw
> to use hw->device instead of NULL?
> 

I think struct hw_pci is meant to be statically defined, so that would
not work if you need the same hw_pci for two host bridge devices.

	Arnd


From andre.przywara at linaro.org  Fri Apr 12 09:04:35 2013
From: andre.przywara at linaro.org (Andre Przywara)
Date: Fri, 12 Apr 2013 15:04:35 +0200
Subject: [PATCH] ARM: KVM: iterate over all CPUs for CPU compatibility check
Message-ID: <1365771875-5788-1-git-send-email-andre.przywara@linaro.org>

kvm_target_cpus() checks the compatibility of the used CPU with
KVM, which is currently limited to ARM Cortex-A15 cores.
However by calling it only once on any random CPU it assumes that
all cores are the same, which is not true for big.LITTLE parts.

After doing about 40 boots on a TC-2 core tile, I found it running
in all but one case on one of the A7 cores (which correctly denied
KVM initialization). On the 39th boot however the code ran on
an A15, leading to a hang after returning success:

...
TCP: reno registered
UDP hash table entries: 512 (order: 2, 16384 bytes)
UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
NET: Registered protocol family 1
kvm_target_cpu() on CPU #1, part is c0f0
 ... (pause for a while) ...
INFO: rcu_sched self-detected stall on CPUINFO: rcu_sched detected stalls on CPU
s/tasks: { 1} (detected by 0, t=6002 jiffies, g=4294966999, c=4294966998, q=15)
Task dump for CPU 1:
swapper/0       R running      0     1      0 0x00000002

So iterate over every CPU to correctly determine the capability of
the system to run the current KVM implementation.
In case a big.LITTLE configuration is the reason for denial, give
the user a hint how to get it running anyway (maxcpus= on the kernel
command line).

Please push this still into 3.9.

Signed-off-by: Andre Przywara <andre.przywara at linaro.org>
---
 arch/arm/kvm/arm.c | 19 +++++++++++++++++--
 1 file changed, 17 insertions(+), 2 deletions(-)

diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index 5a93698..9b53cdd 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -1128,20 +1128,35 @@ out_err:
 	return err;
 }
 
+static void check_kvm_target_cpu(void *ret)
+{
+	*(int*)ret = kvm_target_cpu();
+}
+
 /**
  * Initialize Hyp-mode and memory mappings on all CPUs.
  */
 int kvm_arch_init(void *opaque)
 {
 	int err;
+	int count = 0, ret, cpu;
 
 	if (!is_hyp_mode_available()) {
 		kvm_err("HYP mode not available\n");
 		return -ENODEV;
 	}
 
-	if (kvm_target_cpu() < 0) {
-		kvm_err("Target CPU not supported!\n");
+	for_each_online_cpu(cpu) {
+		smp_call_function_single(cpu, check_kvm_target_cpu, &ret, 1);
+		if (ret >= 0) {
+			count++;
+			continue;
+		}
+		if (count)
+			kvm_err("big.LITTLE not supported, limit to A15 CPUs with maxcpus= to use KVM\n");
+		else
+			kvm_err("Target CPU not supported!\n");
+
 		return -ENODEV;
 	}
 
-- 
1.7.12.1



From festevam at gmail.com  Fri Apr 12 09:23:56 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Fri, 12 Apr 2013 10:23:56 -0300
Subject: [PATCH v2 1/1 net] enet: fec: fix fail resume from suspend state
In-Reply-To: <1364350323-2488-1-git-send-email-Frank.Li@freescale.com>
References: <1364350323-2488-1-git-send-email-Frank.Li@freescale.com>
Message-ID: <CAOMZO5A9Tc_n8OGgxxw0ZE9xGOPjsYvyqVZtjWwTRn9as3eKCw@mail.gmail.com>

Hi Frank,

On Tue, Mar 26, 2013 at 11:12 PM, Frank Li <Frank.Li at freescale.com> wrote:
> Without this patch
> 1. boot with nfs (no_console_suspend)
> 2. echo mem >/sys/power/state
> 3. wakeup by wakesource
> 4. print "eth0: tx queue full"

I still have issues with suspend/resume with your patch applied:

$ echo enabled >
/sys/devices/80000000.apb/80040000.apbx/80074000.serial/tty/ttyAMA0/power/wakeup
$ echo mem > /sys/power/state

[   31.577857] PM: Syncing filesystems ... done.
[   31.604332] Freezing user space processes ... (elapsed 0.01 seconds) done.
[   31.622160] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) do.
[   31.642018] Suspending console(s) (use no_console_suspend to debug)
[   31.666914] PM: suspend of devices complete after 12.672 msecs
[   31.671975] PM: late suspend of devices complete after 5.007 msecs
[   31.678542] PM: noirq suspend of devices complete after 6.521 msecs
[   31.682147] PM: noirq resume of devices complete after 3.186 msecs
[   31.687396] PM: early resume of devices complete after 3.464 msecs
[   31.759982] PM: resume of devices complete after 2432.562 msecs

(Then send any char via DUART to wakeup the system)

[   31.802673] Restarting tasks ... done.
[   33.829493] libphy: 800f0000.etherne:00 - Link is Down
[   36.859102] FEC: MDIO read timeout
[   38.889180] FEC: MDIO read timeout

It does not fail 100%: there are times that suspend works just fine.


From marc.zyngier at arm.com  Fri Apr 12 09:24:09 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Fri, 12 Apr 2013 14:24:09 +0100
Subject: [PATCH] ARM: KVM: iterate over all CPUs for CPU compatibility
 check
In-Reply-To: <1365771875-5788-1-git-send-email-andre.przywara@linaro.org>
References: <1365771875-5788-1-git-send-email-andre.przywara@linaro.org>
Message-ID: <51680AF9.7040109@arm.com>

On 12/04/13 14:04, Andre Przywara wrote:
> kvm_target_cpus() checks the compatibility of the used CPU with
> KVM, which is currently limited to ARM Cortex-A15 cores.
> However by calling it only once on any random CPU it assumes that
> all cores are the same, which is not true for big.LITTLE parts.
> 
> After doing about 40 boots on a TC-2 core tile, I found it running
> in all but one case on one of the A7 cores (which correctly denied
> KVM initialization). On the 39th boot however the code ran on
> an A15, leading to a hang after returning success:
> 
> ...
> TCP: reno registered
> UDP hash table entries: 512 (order: 2, 16384 bytes)
> UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
> NET: Registered protocol family 1
> kvm_target_cpu() on CPU #1, part is c0f0
>  ... (pause for a while) ...
> INFO: rcu_sched self-detected stall on CPUINFO: rcu_sched detected stalls on CPU
> s/tasks: { 1} (detected by 0, t=6002 jiffies, g=4294966999, c=4294966998, q=15)
> Task dump for CPU 1:
> swapper/0       R running      0     1      0 0x00000002
> 
> So iterate over every CPU to correctly determine the capability of
> the system to run the current KVM implementation.
> In case a big.LITTLE configuration is the reason for denial, give
> the user a hint how to get it running anyway (maxcpus= on the kernel
> command line).
> 
> Please push this still into 3.9.
> 
> Signed-off-by: Andre Przywara <andre.przywara at linaro.org>

[...]

Nak. The fact that one of the CPUs seem to hang is a sure sign that
something is severely broken, and you definitely want to fix that issue,
instead of blindly ignoring it.

Additionally, it seems you're just papering over the issue. You should
be able to exclude the A7 processors, but not completely deny KVM from
running on the hardware.

	M.
-- 
Jazz is not dead. It just smells funny...



From agraf at suse.de  Fri Apr 12 09:26:54 2013
From: agraf at suse.de (Alexander Graf)
Date: Fri, 12 Apr 2013 15:26:54 +0200
Subject: [PATCH] ARM: KVM: fix L_PTE_S2_RDWR to actually be Read/Write
In-Reply-To: <1365771616-7380-1-git-send-email-marc.zyngier@arm.com>
References: <1365771616-7380-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <69741C13-FAA5-45D3-87D5-FF082E87192A@suse.de>


On 12.04.2013, at 15:00, Marc Zyngier wrote:

> Looks like our L_PTE_S2_RDWR definition is slightly wrong,
> and is actually write only (see ARM ARM Table B3-9, Stage 2 control
> of access permissions). Didn't make a difference for normal pages,
> as we OR the flags together, but I'm still wondering how it worked
> for Stage-2 mapped devices, such as the GIC.
> 
> Brown paper bag time, again.
> 
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>

CC stable?


Alex

> ---
> arch/arm/include/asm/pgtable-3level.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/include/asm/pgtable-3level.h b/arch/arm/include/asm/pgtable-3level.h
> index 6ef8afd..86b8fe3 100644
> --- a/arch/arm/include/asm/pgtable-3level.h
> +++ b/arch/arm/include/asm/pgtable-3level.h
> @@ -111,7 +111,7 @@
> #define L_PTE_S2_MT_WRITETHROUGH (_AT(pteval_t, 0xa) << 2) /* MemAttr[3:0] */
> #define L_PTE_S2_MT_WRITEBACK	 (_AT(pteval_t, 0xf) << 2) /* MemAttr[3:0] */
> #define L_PTE_S2_RDONLY		 (_AT(pteval_t, 1) << 6)   /* HAP[1]   */
> -#define L_PTE_S2_RDWR		 (_AT(pteval_t, 2) << 6)   /* HAP[2:1] */
> +#define L_PTE_S2_RDWR		 (_AT(pteval_t, 3) << 6)   /* HAP[2:1] */
> 
> /*
>  * Hyp-mode PL2 PTE definitions for LPAE.
> -- 
> 1.8.1.4
> 
> 
> 
> _______________________________________________
> kvmarm mailing list
> kvmarm at lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm



From maxime.ripard at free-electrons.com  Fri Apr 12 09:30:57 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Fri, 12 Apr 2013 15:30:57 +0200
Subject: [PATCH] SPI: spidev: Add DT compatible string for spidev driver.
In-Reply-To: <20130412125621.9645.78102.stgit@localhost>
References: <20130412125621.9645.78102.stgit@localhost>
Message-ID: <51680C91.6030005@free-electrons.com>

Hi Martin,

Le 12/04/2013 14:56, Martin Fuzzey a ?crit :
> The spidev driver is useful to allow userspace access
> to SPI devices that have no kernel SPI driver.
> 
> However DT requires a compatible tree to allow the driver
> to be probed.
> 
> To avoid having to modify the driver for every extra device
> add a generic "linux,spidev" compatible string that may be
> used in the DT to match such devices.

I submitted a similar patch quite some time ago [1], and at the time,
this patch was found inadequate, and we decided to add the compatible of
the particular device that we drive through spidev.

The rationale behind that is that the device tree is a hardware
description, so it's only interested about which device there is on the
SPI bus, and not the driver that will eventually handle it. That allows
both to have a meaningful devicetree, but also to easily handle the case
where a driver for that particular device is finally implemented, since
we won't have to change the device tree in itself to reflect this.

So I suggest you only add to the "real" compatible string instead of a
generic one.

Maxime

[1] http://comments.gmane.org/gmane.linux.kernel.spi.devel/11734

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


From marc.zyngier at arm.com  Fri Apr 12 09:33:48 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Fri, 12 Apr 2013 14:33:48 +0100
Subject: [PATCH] ARM: KVM: fix L_PTE_S2_RDWR to actually be Read/Write
In-Reply-To: <69741C13-FAA5-45D3-87D5-FF082E87192A@suse.de>
References: <1365771616-7380-1-git-send-email-marc.zyngier@arm.com>
 <69741C13-FAA5-45D3-87D5-FF082E87192A@suse.de>
Message-ID: <51680D3C.9090602@arm.com>

On 12/04/13 14:26, Alexander Graf wrote:
> 
> On 12.04.2013, at 15:00, Marc Zyngier wrote:
> 
>> Looks like our L_PTE_S2_RDWR definition is slightly wrong,
>> and is actually write only (see ARM ARM Table B3-9, Stage 2 control
>> of access permissions). Didn't make a difference for normal pages,
>> as we OR the flags together, but I'm still wondering how it worked
>> for Stage-2 mapped devices, such as the GIC.
>>
>> Brown paper bag time, again.
>>
>> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> 
> CC stable?

Only if this doesn't make it into the final 3.9, which will be the first
version with KVM/arm.

	M.
-- 
Jazz is not dead. It just smells funny...



From agraf at suse.de  Fri Apr 12 09:35:38 2013
From: agraf at suse.de (Alexander Graf)
Date: Fri, 12 Apr 2013 15:35:38 +0200
Subject: [PATCH] ARM: KVM: fix L_PTE_S2_RDWR to actually be Read/Write
In-Reply-To: <51680D3C.9090602@arm.com>
References: <1365771616-7380-1-git-send-email-marc.zyngier@arm.com>
 <69741C13-FAA5-45D3-87D5-FF082E87192A@suse.de> <51680D3C.9090602@arm.com>
Message-ID: <0F293D19-E658-48A2-B0D0-47A728CE8785@suse.de>


On 12.04.2013, at 15:33, Marc Zyngier wrote:

> On 12/04/13 14:26, Alexander Graf wrote:
>> 
>> On 12.04.2013, at 15:00, Marc Zyngier wrote:
>> 
>>> Looks like our L_PTE_S2_RDWR definition is slightly wrong,
>>> and is actually write only (see ARM ARM Table B3-9, Stage 2 control
>>> of access permissions). Didn't make a difference for normal pages,
>>> as we OR the flags together, but I'm still wondering how it worked
>>> for Stage-2 mapped devices, such as the GIC.
>>> 
>>> Brown paper bag time, again.
>>> 
>>> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
>> 
>> CC stable?
> 
> Only if this doesn't make it into the final 3.9, which will be the first
> version with KVM/arm.

Given that we're at rc6, I'd presume that's rather likely if you don't make a fuss about it :)


Alex



From festevam at gmail.com  Fri Apr 12 09:38:24 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Fri, 12 Apr 2013 10:38:24 -0300
Subject: [PATCH v3 1/1 net-next] net: fec: put tx to napi poll function to
 fix dead lock
In-Reply-To: <20130324143525.GI6281@S2101-09.ap.freescale.net>
References: <1362368065-5809-1-git-send-email-Frank.Li@freescale.com>
 <20130320114824.GA6088@S2101-09.ap.freescale.net>
 <CAOMZO5B-ipzyb2uiLW12fFd3PD3JfLS8R0YLM5vtLgFNz8abUw@mail.gmail.com>
 <20130324143525.GI6281@S2101-09.ap.freescale.net>
Message-ID: <CAOMZO5C9ZX_SygEdMdcGXbH8=gLKn0igOMkZ8vGP3HNzD+fvxA@mail.gmail.com>

On Sun, Mar 24, 2013 at 11:35 AM, Shawn Guo <shawn.guo at linaro.org> wrote:

> Are you sure?  After reverting the patch on next-20130322, I can get
> imx28 resume back to console as below.

Yes, please try 20130412, which has Frank's fix applied and try
suspend/resume sequence several times.

Does it work always for you?

On my mx28evk it usually fails.


From peter.maydell at linaro.org  Fri Apr 12 09:40:39 2013
From: peter.maydell at linaro.org (Peter Maydell)
Date: Fri, 12 Apr 2013 14:40:39 +0100
Subject: [PATCH] ARM: KVM: iterate over all CPUs for CPU compatibility
 check
In-Reply-To: <51680AF9.7040109@arm.com>
References: <1365771875-5788-1-git-send-email-andre.przywara@linaro.org>
 <51680AF9.7040109@arm.com>
Message-ID: <CAFEAcA-1HAG0pY-j-rqU=QmSoep3Di-KNPATvuou8ghRn3SaqA@mail.gmail.com>

On 12 April 2013 14:24, Marc Zyngier <marc.zyngier at arm.com> wrote:
> Nak. The fact that one of the CPUs seem to hang is a sure sign that
> something is severely broken, and you definitely want to fix that issue,
> instead of blindly ignoring it.
>
> Additionally, it seems you're just papering over the issue. You should
> be able to exclude the A7 processors, but not completely deny KVM from
> running on the hardware.

Well that might be nice, as would fully supporting big.LITTLE
systems. But until somebody actually does that work it seems
like a better idea to fail gracefully rather than having a 50%
chance of failing gracefully and a 50% chance of going weird.

-- PMM


From andrew.murray at arm.com  Fri Apr 12 09:48:11 2013
From: andrew.murray at arm.com (Andrew Murray)
Date: Fri, 12 Apr 2013 14:48:11 +0100
Subject: [PATCH] ARM: pci: pass a parent to pci_common_init()
In-Reply-To: <201304121501.48866.arnd@arndb.de>
References: <1365719096-11639-1-git-send-email-linus.walleij@linaro.org>
 <201304121326.56030.arnd@arndb.de> <20130412120538.GA32488@arm.com>
 <201304121501.48866.arnd@arndb.de>
Message-ID: <20130412134811.GA26188@arm.com>

On Fri, Apr 12, 2013 at 02:01:48PM +0100, Arnd Bergmann wrote:
> On Friday 12 April 2013, Andrew Murray wrote:
> > I would also be happy with this. Though alternatively could you
> > not just add a struct device to hw_pci? Then change pcibios_init_hw
> > to use hw->device instead of NULL?
> > 
> 
> I think struct hw_pci is meant to be statically defined, so that would
> not work if you need the same hw_pci for two host bridge devices.
> 
> 	Arnd
> 

Yes, though the new PCIe host/bridge drivers with DT support all seem to call
pci_common_init at probe with a non-statically defined hw_pci with the
nr_controllers always set to 1 (meaning that pci_common_init can be called
multiple times). Also hw_pci now has a field for private_data anyway which
breaks this assumption...

Is there an argument for removing hw_pci or at least .nr_controllers and call
pci_common_init multiple times (as is potential current use case for DT PCI
drivers)?

Andrew Murray


From marc.zyngier at arm.com  Fri Apr 12 09:49:43 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Fri, 12 Apr 2013 14:49:43 +0100
Subject: [PATCH] ARM: KVM: iterate over all CPUs for CPU compatibility
 check
In-Reply-To: <CAFEAcA-1HAG0pY-j-rqU=QmSoep3Di-KNPATvuou8ghRn3SaqA@mail.gmail.com>
References: <1365771875-5788-1-git-send-email-andre.przywara@linaro.org>
 <51680AF9.7040109@arm.com>
 <CAFEAcA-1HAG0pY-j-rqU=QmSoep3Di-KNPATvuou8ghRn3SaqA@mail.gmail.com>
Message-ID: <516810F7.7040601@arm.com>

On 12/04/13 14:40, Peter Maydell wrote:
> On 12 April 2013 14:24, Marc Zyngier <marc.zyngier at arm.com> wrote:
>> Nak. The fact that one of the CPUs seem to hang is a sure sign that
>> something is severely broken, and you definitely want to fix that issue,
>> instead of blindly ignoring it.
>>
>> Additionally, it seems you're just papering over the issue. You should
>> be able to exclude the A7 processors, but not completely deny KVM from
>> running on the hardware.
> 
> Well that might be nice, as would fully supporting big.LITTLE
> systems. But until somebody actually does that work it seems
> like a better idea to fail gracefully rather than having a 50%
> chance of failing gracefully and a 50% chance of going weird.

Nothing prevents the kernel (or even the user) from forcing the affinity
of the CPU threads to the A15s. I'm not saying we should ignore the
problem either. Just that the proposed approach is wrong.

	M.
-- 
Jazz is not dead. It just smells funny...



From rabin at rab.in  Fri Apr 12 09:49:31 2013
From: rabin at rab.in (Rabin Vincent)
Date: Fri, 12 Apr 2013 15:49:31 +0200
Subject: [PATCH 3/8] dmaengine: ste_dma40: Actually write the runtime
 configuration to registers
In-Reply-To: <1365532783-27425-3-git-send-email-lee.jones@linaro.org>
References: <1365532783-27425-1-git-send-email-lee.jones@linaro.org>
 <1365532783-27425-3-git-send-email-lee.jones@linaro.org>
Message-ID: <CAH+eYFB_fYmCjvh5PXKRhd-FnaWfeu+LtH+q3VywhCk-PYhHVQ@mail.gmail.com>

2013/4/9 Lee Jones <lee.jones at linaro.org>:
> Someone has spent a fair amount of effort writing a runtime configuration
> changing algorithm for DMA clients. However, the config appears to never
> actually make it to hardware. In order for the configuration to take hold
> we need to issue a d40_config_write(), as this is the routine which writes
> it into the hardware's registers.

No, it's not.  This function is only for initial configuration which
should only be written when the channel is allocated.  In fact, by
calling it here in runtime_config, you are introducing a serious bug:
other logical channels on the same physical channel will stop because of
the SSLNK/SDLNK of the physical channel being zeroed.

The runtime config already makes it the hardware in the existing code,
via d40_*_cfg().


From andre.przywara at linaro.org  Fri Apr 12 09:58:00 2013
From: andre.przywara at linaro.org (Andre Przywara)
Date: Fri, 12 Apr 2013 15:58:00 +0200
Subject: [PATCH] ARM: KVM: iterate over all CPUs for CPU compatibility
 check
In-Reply-To: <51680AF9.7040109@arm.com>
References: <1365771875-5788-1-git-send-email-andre.przywara@linaro.org>
 <51680AF9.7040109@arm.com>
Message-ID: <516812E8.6040103@linaro.org>

On 04/12/2013 03:24 PM, Marc Zyngier wrote:
> On 12/04/13 14:04, Andre Przywara wrote:
>> kvm_target_cpus() checks the compatibility of the used CPU with
>> KVM, which is currently limited to ARM Cortex-A15 cores.
>> However by calling it only once on any random CPU it assumes that
>> all cores are the same, which is not true for big.LITTLE parts.
>>
>> After doing about 40 boots on a TC-2 core tile, I found it running
>> in all but one case on one of the A7 cores (which correctly denied
>> KVM initialization). On the 39th boot however the code ran on
>> an A15, leading to a hang after returning success:
>>
>> ...
>> TCP: reno registered
>> UDP hash table entries: 512 (order: 2, 16384 bytes)
>> UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
>> NET: Registered protocol family 1
>> kvm_target_cpu() on CPU #1, part is c0f0
>>   ... (pause for a while) ...
>> INFO: rcu_sched self-detected stall on CPUINFO: rcu_sched detected stalls on CPU
>> s/tasks: { 1} (detected by 0, t=6002 jiffies, g=4294966999, c=4294966998, q=15)
>> Task dump for CPU 1:
>> swapper/0       R running      0     1      0 0x00000002
>>
>> So iterate over every CPU to correctly determine the capability of
>> the system to run the current KVM implementation.
>> In case a big.LITTLE configuration is the reason for denial, give
>> the user a hint how to get it running anyway (maxcpus= on the kernel
>> command line).
>>
>> Please push this still into 3.9.
>>
>> Signed-off-by: Andre Przywara <andre.przywara at linaro.org>
>
> [...]
>
> Nak. The fact that one of the CPUs seem to hang is a sure sign that
> something is severely broken, and you definitely want to fix that issue,
> instead of blindly ignoring it.

In general I agree, but we should fix it quickly for 3.9, as it can 
cause a kernel hang.

> Additionally, it seems you're just papering over the issue. You should
> be able to exclude the A7 processors, but not completely deny KVM from
> running on the hardware.

Is there an easy way to prevent VCPUs from running on not-supported 
cores? Something like an kvm_cpu_mask?
What would be the wisest hook to utilize for this?
It looks like much of the CPU selection code is generic, so this would 
be non-trivial, right?

Regards,
Andre.



From rabin at rab.in  Fri Apr 12 09:54:28 2013
From: rabin at rab.in (Rabin Vincent)
Date: Fri, 12 Apr 2013 15:54:28 +0200
Subject: [PATCH 4/8] dmaengine: ste_dma40: Do not configure channels
 during an channel allocation
In-Reply-To: <1365532783-27425-4-git-send-email-lee.jones@linaro.org>
References: <1365532783-27425-1-git-send-email-lee.jones@linaro.org>
 <1365532783-27425-4-git-send-email-lee.jones@linaro.org>
Message-ID: <CAH+eYFBk8y28e+NwOBpvpdFa29JRXbNpFgjwNumC8GRtB-e7VQ@mail.gmail.com>

2013/4/9 Lee Jones <lee.jones at linaro.org>:
> diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
> index 2a0a9d4..9e423ad 100644
> --- a/drivers/dma/ste_dma40.c
> +++ b/drivers/dma/ste_dma40.c
> @@ -2463,16 +2463,10 @@ static int d40_alloc_chan_resources(struct dma_chan *chan)
>         }
>
>         pm_runtime_get_sync(d40c->base->dev);
> -       /* Fill in basic CFG register values */
> -       d40_phy_cfg(&d40c->dma_cfg, &d40c->src_def_cfg,
> -                   &d40c->dst_def_cfg, chan_is_logical(d40c));
>
>         d40_set_prio_realtime(d40c);
>
>         if (chan_is_logical(d40c)) {
> -               d40_log_cfg(&d40c->dma_cfg,
> -                           &d40c->log_def.lcsp1, &d40c->log_def.lcsp3);
> -
>                 if (d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_MEM)
>                         d40c->lcpa = d40c->base->lcpa_base +
>                                 d40c->dma_cfg.src_dev_type * D40_LCPA_CHAN_SIZE;
> @@ -2487,14 +2481,6 @@ static int d40_alloc_chan_resources(struct dma_chan *chan)
>                  d40c->phy_chan->num,
>                  d40c->dma_cfg.use_fixed_channel ? ", fixed" : "");
>
> -
> -       /*
> -        * Only write channel configuration to the DMA if the physical
> -        * resource is free. In case of multiple logical channels
> -        * on the same physical resource, only the first write is necessary.
> -        */
> -       if (is_free_phy)
> -               d40_config_write(d40c);

This function does basic initial configuration which is linked to
whether the channel is pysical or logical -- something that is not being
allowed to be runtime configured, so the place to call this function is
here.  Furthermore, it clears the SSLNK/SDLNK which has to be done here,
when the phy channel is first allocated.


From rabin at rab.in  Fri Apr 12 10:02:21 2013
From: rabin at rab.in (Rabin Vincent)
Date: Fri, 12 Apr 2013 16:02:21 +0200
Subject: [PATCH 5/8] dmaengine: ste_dma40: Ensure src and dst registers
 are configured correctly
In-Reply-To: <1365532783-27425-5-git-send-email-lee.jones@linaro.org>
References: <1365532783-27425-1-git-send-email-lee.jones@linaro.org>
 <1365532783-27425-5-git-send-email-lee.jones@linaro.org>
Message-ID: <CAH+eYFCuYg5cyqs8-jWq+9-qjG=Q1s5q+fz+5pu-BxHXtFe2Hw@mail.gmail.com>

2013/4/9 Lee Jones <lee.jones at linaro.org>:
> diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
> index 9e423ad..49d8c9d 100644
> --- a/drivers/dma/ste_dma40.c
> +++ b/drivers/dma/ste_dma40.c
> @@ -2810,9 +2810,9 @@ static int d40_set_runtime_config(struct dma_chan *chan,
>         /* Fill in register values */
>         if (chan_is_logical(d40c))
>                 d40_log_cfg(cfg, &d40c->log_def.lcsp1, &d40c->log_def.lcsp3);
> -       else
> -               d40_phy_cfg(cfg, &d40c->src_def_cfg,
> -                           &d40c->dst_def_cfg, false);
> +
> +       d40_phy_cfg(cfg, &d40c->src_def_cfg, &d40c->dst_def_cfg,
> +                   chan_is_logical(d40c));
>
>         /* These settings will take precedence later */
>         d40c->runtime_addr = config_addr;

There is no need to call this function there.  For a logical channel,
the underlying physical channel's SSCFG/SDCFG should only be written
once in the beginning (via d40_config_write()) so there is no need to
change this src_def_cfg and dst_def_cfg again without using them.  For a
logical channel, d40_phy_cfg() does nothing else which is
runtime_config()able.


From arnd at arndb.de  Fri Apr 12 10:03:19 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 12 Apr 2013 16:03:19 +0200
Subject: [PATCH 1/7] clk: exynos: prepare for multiplatform
In-Reply-To: <1365775405-115297-1-git-send-email-arnd@arndb.de>
References: <1365775405-115297-1-git-send-email-arnd@arndb.de>
Message-ID: <1365775405-115297-2-git-send-email-arnd@arndb.de>

The new common clock drivers for exynos are using compile
time constants and soc_is_exynos* macros to provide backwards
compatibility for pre-DT systems, which is not possible with
multiplatform kernels. This moves all the necessary
information back into platform code and removes the mach/*
header inclusions.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Cc: Mike Turquette <mturquette at linaro.org>
---
 arch/arm/mach-exynos/common.c        |  2 +-
 arch/arm/mach-exynos/common.h        |  2 +-
 drivers/clk/samsung/clk-exynos4.c    | 93 ++++++++++++++++--------------------
 drivers/clk/samsung/clk-exynos5250.c |  1 -
 drivers/clk/samsung/clk-exynos5440.c |  1 -
 drivers/clk/samsung/clk.h            |  2 -
 6 files changed, 44 insertions(+), 57 deletions(-)

diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
index 939bda7..42f399a 100644
--- a/arch/arm/mach-exynos/common.c
+++ b/arch/arm/mach-exynos/common.c
@@ -410,7 +410,7 @@ void __init exynos_init_time(void)
 	} else {
 		/* todo: remove after migrating legacy E4 platforms to dt */
 #ifdef CONFIG_ARCH_EXYNOS4
-		exynos4_clk_init(NULL);
+		exynos4_clk_init(NULL, !soc_is_exynos4210(), S5P_VA_CMU, readl(S5P_VA_CHIPID + 8) & 1);
 		exynos4_clk_register_fixed_ext(xxti_f, xusbxti_f);
 #endif
 		mct_init();
diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
index cb89ab8..4ed8eef 100644
--- a/arch/arm/mach-exynos/common.h
+++ b/arch/arm/mach-exynos/common.h
@@ -27,7 +27,7 @@ void exynos5_restart(char mode, const char *cmd);
 void exynos_init_late(void);
 
 /* ToDo: remove these after migrating legacy exynos4 platforms to dt */
-void exynos4_clk_init(struct device_node *np);
+void exynos4_clk_init(struct device_node *np, int is_exynos4210, void __iomem *reg_base, unsigned long xom);
 void exynos4_clk_register_fixed_ext(unsigned long, unsigned long);
 
 #ifdef CONFIG_PM_GENERIC_DOMAINS
diff --git a/drivers/clk/samsung/clk-exynos4.c b/drivers/clk/samsung/clk-exynos4.c
index 7104669..d0940e6 100644
--- a/drivers/clk/samsung/clk-exynos4.c
+++ b/drivers/clk/samsung/clk-exynos4.c
@@ -16,7 +16,6 @@
 #include <linux/of.h>
 #include <linux/of_address.h>
 
-#include <plat/cpu.h>
 #include "clk.h"
 #include "clk-pll.h"
 
@@ -910,16 +909,6 @@ struct samsung_gate_clock exynos4x12_gate_clks[] __initdata = {
 			CLK_IGNORE_UNUSED, 0),
 };
 
-#ifdef CONFIG_OF
-static struct of_device_id exynos4_clk_ids[] __initdata = {
-	{ .compatible = "samsung,exynos4210-clock",
-			.data = (void *)EXYNOS4210, },
-	{ .compatible = "samsung,exynos4412-clock",
-			.data = (void *)EXYNOS4X12, },
-	{ },
-};
-#endif
-
 /*
  * The parent of the fin_pll clock is selected by the XOM[0] bit. This bit
  * resides in chipid register space, outside of the clock controller memory
@@ -927,33 +916,40 @@ static struct of_device_id exynos4_clk_ids[] __initdata = {
  * controller is first remapped and the value of XOM[0] bit is read to
  * determine the parent clock.
  */
-static void __init exynos4_clk_register_finpll(void)
+static unsigned long exynos4_get_xom(void)
 {
-	struct samsung_fixed_rate_clock fclk;
+	unsigned long xom = 0;
+	void __iomem *chipid_base;
 	struct device_node *np;
-	struct clk *clk;
-	void __iomem *chipid_base = S5P_VA_CHIPID;
-	unsigned long xom, finpll_f = 24000000;
-	char *parent_name;
 
 	np = of_find_compatible_node(NULL, NULL, "samsung,exynos4210-chipid");
-	if (np)
+	if (np) {
 		chipid_base = of_iomap(np, 0);
 
-	if (chipid_base) {
-		xom = readl(chipid_base + 8);
-		parent_name = xom & 1 ? "xusbxti" : "xxti";
-		clk = clk_get(NULL, parent_name);
-		if (IS_ERR(clk)) {
-			pr_err("%s: failed to lookup parent clock %s, assuming "
-				"fin_pll clock frequency is 24MHz\n", __func__,
-				parent_name);
-		} else {
-			finpll_f = clk_get_rate(clk);
-		}
+		if (chipid_base)
+			xom = readl(chipid_base + 8);
+
+		iounmap(chipid_base);
+	}
+
+	return xom;
+}
+
+static void __init exynos4_clk_register_finpll(unsigned long xom)
+{
+	struct samsung_fixed_rate_clock fclk;
+	struct clk *clk;
+	unsigned long finpll_f = 24000000;
+	char *parent_name;
+
+	parent_name = xom & 1 ? "xusbxti" : "xxti";
+	clk = clk_get(NULL, parent_name);
+	if (IS_ERR(clk)) {
+		pr_err("%s: failed to lookup parent clock %s, assuming "
+			"fin_pll clock frequency is 24MHz\n", __func__,
+			parent_name);
 	} else {
-		pr_err("%s: failed to map chipid registers, assuming "
-			"fin_pll clock frequency is 24MHz\n", __func__);
+		finpll_f = clk_get_rate(clk);
 	}
 
 	fclk.id = fin_pll;
@@ -963,8 +959,6 @@ static void __init exynos4_clk_register_finpll(void)
 	fclk.fixed_rate = finpll_f;
 	samsung_clk_register_fixed_rate(&fclk, 1);
 
-	if (np)
-		iounmap(chipid_base);
 }
 
 /*
@@ -988,28 +982,14 @@ static __initdata struct of_device_id ext_clk_match[] = {
 };
 
 /* register exynos4 clocks */
-void __init exynos4_clk_init(struct device_node *np)
+void __init exynos4_clk_init(struct device_node *np, enum exynos4_soc exynos4_soc, void __iomem *reg_base, unsigned long xom)
 {
-	void __iomem *reg_base;
 	struct clk *apll, *mpll, *epll, *vpll;
-	u32 exynos4_soc;
 
 	if (np) {
-		const struct of_device_id *match;
-		match = of_match_node(exynos4_clk_ids, np);
-		exynos4_soc = (u32)match->data;
-
 		reg_base = of_iomap(np, 0);
 		if (!reg_base)
 			panic("%s: failed to map registers\n", __func__);
-	} else {
-		reg_base = S5P_VA_CMU;
-		if (soc_is_exynos4210())
-			exynos4_soc = EXYNOS4210;
-		else if (soc_is_exynos4212() || soc_is_exynos4412())
-			exynos4_soc = EXYNOS4X12;
-		else
-			panic("%s: unable to determine soc\n", __func__);
 	}
 
 	if (exynos4_soc == EXYNOS4210)
@@ -1026,7 +1006,7 @@ void __init exynos4_clk_init(struct device_node *np)
 			ARRAY_SIZE(exynos4_fixed_rate_ext_clks),
 			ext_clk_match);
 
-	exynos4_clk_register_finpll();
+	exynos4_clk_register_finpll(xom);
 
 	if (exynos4_soc == EXYNOS4210) {
 		apll = samsung_clk_register_pll45xx("fout_apll", "fin_pll",
@@ -1087,5 +1067,16 @@ void __init exynos4_clk_init(struct device_node *np)
 		_get_rate("sclk_epll"), _get_rate("sclk_vpll"),
 		_get_rate("arm_clk"));
 }
-CLK_OF_DECLARE(exynos4210_clk, "samsung,exynos4210-clock", exynos4_clk_init);
-CLK_OF_DECLARE(exynos4412_clk, "samsung,exynos4412-clock", exynos4_clk_init);
+
+
+static void __init exynos4210_clk_init(struct device_node *np)
+{
+	exynos4_clk_init(np, EXYNOS4210, NULL, exynos4_get_xom());
+}
+CLK_OF_DECLARE(exynos4210_clk, "samsung,exynos4210-clock", exynos4210_clk_init);
+
+static void __init exynos4412_clk_init(struct device_node *np)
+{
+	exynos4_clk_init(np, EXYNOS4X12, NULL, exynos4_get_xom());
+}
+CLK_OF_DECLARE(exynos4412_clk, "samsung,exynos4412-clock", exynos4412_clk_init);
diff --git a/drivers/clk/samsung/clk-exynos5250.c b/drivers/clk/samsung/clk-exynos5250.c
index 7290faa..61068cd 100644
--- a/drivers/clk/samsung/clk-exynos5250.c
+++ b/drivers/clk/samsung/clk-exynos5250.c
@@ -16,7 +16,6 @@
 #include <linux/of.h>
 #include <linux/of_address.h>
 
-#include <plat/cpu.h>
 #include "clk.h"
 #include "clk-pll.h"
 
diff --git a/drivers/clk/samsung/clk-exynos5440.c b/drivers/clk/samsung/clk-exynos5440.c
index a0a094c..7d54341 100644
--- a/drivers/clk/samsung/clk-exynos5440.c
+++ b/drivers/clk/samsung/clk-exynos5440.c
@@ -15,7 +15,6 @@
 #include <linux/of.h>
 #include <linux/of_address.h>
 
-#include <plat/cpu.h>
 #include "clk.h"
 #include "clk-pll.h"
 
diff --git a/drivers/clk/samsung/clk.h b/drivers/clk/samsung/clk.h
index 10b2111..e4ad6ea 100644
--- a/drivers/clk/samsung/clk.h
+++ b/drivers/clk/samsung/clk.h
@@ -20,8 +20,6 @@
 #include <linux/of.h>
 #include <linux/of_address.h>
 
-#include <mach/map.h>
-
 /**
  * struct samsung_clock_alias: information about mux clock
  * @id: platform specific id of the clock.
-- 
1.8.1.2



From arnd at arndb.de  Fri Apr 12 10:03:18 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 12 Apr 2013 16:03:18 +0200
Subject: [PATCH 0/7] exynos multiplatform support, part 2
Message-ID: <1365775405-115297-1-git-send-email-arnd@arndb.de>

These are the patches required for exynos multiplatform support that
depend on other patches that are already merged in the arm-soc next/drivers
branch. The series applies cleanly on top of the next/drivers branch
at the moment, and in combination with various patches that were
accepted by subsystem maintainers and part 1 of the series (which
applies on top of 3.9-rc5) brings full support for ARCH_MULTIPLATFORM
to device tree based exynos systems.

	Arnd

Arnd Bergmann (7):
  clk: exynos: prepare for multiplatform
  clocksource: exynos_mct: remove platform header dependency
  ARM: exynos: add missing properties for combiner IRQs
  irqchip: exynos: pass max combiner number to combiner_init
  irqchip: exynos: allocate combiner_data dynamically
  irqchip: exynos: localize irq lookup for ATAGS
  irqchip: exynos: pass irq_base from platform

 arch/arm/boot/dts/exynos4210.dtsi    |   1 +
 arch/arm/boot/dts/exynos4212.dtsi    |   9 +++
 arch/arm/boot/dts/exynos4412.dtsi    |   9 +++
 arch/arm/mach-exynos/common.c        |  20 +++++-
 arch/arm/mach-exynos/common.h        |   7 ++-
 drivers/clk/samsung/clk-exynos4.c    |  93 +++++++++++++---------------
 drivers/clk/samsung/clk-exynos5250.c |   1 -
 drivers/clk/samsung/clk-exynos5440.c |   1 -
 drivers/clk/samsung/clk.h            |   2 -
 drivers/clocksource/exynos_mct.c     |  21 ++-----
 drivers/irqchip/exynos-combiner.c    | 116 ++++++++++++++++++-----------------
 11 files changed, 148 insertions(+), 132 deletions(-)

-- 
1.8.1.2



From arnd at arndb.de  Fri Apr 12 10:03:23 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 12 Apr 2013 16:03:23 +0200
Subject: [PATCH 5/7] irqchip: exynos: allocate combiner_data dynamically
In-Reply-To: <1365775405-115297-1-git-send-email-arnd@arndb.de>
References: <1365775405-115297-1-git-send-email-arnd@arndb.de>
Message-ID: <1365775405-115297-6-git-send-email-arnd@arndb.de>

The number of combiners on a given SoC is a platform specific
constant, and we cannot encode this number on a multiplatform
kernel since the header file defining it is not available.

Allocating the structure dynamically ends up cleaner anyway
since we keep all the data local.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Cc: Thomas Gleixner <tglx at linutronix.de>
---
 drivers/irqchip/exynos-combiner.c | 36 +++++++++++++++++++++++-------------
 1 file changed, 23 insertions(+), 13 deletions(-)

diff --git a/drivers/irqchip/exynos-combiner.c b/drivers/irqchip/exynos-combiner.c
index d868383..7fcdeee 100644
--- a/drivers/irqchip/exynos-combiner.c
+++ b/drivers/irqchip/exynos-combiner.c
@@ -12,6 +12,7 @@
 #include <linux/export.h>
 #include <linux/init.h>
 #include <linux/io.h>
+#include <linux/slab.h>
 #include <linux/irqdomain.h>
 #include <linux/of_address.h>
 #include <linux/of_irq.h>
@@ -37,7 +38,6 @@ struct combiner_chip_data {
 };
 
 static struct irq_domain *combiner_irq_domain;
-static struct combiner_chip_data combiner_data[MAX_COMBINER_NR];
 
 static inline void __iomem *combiner_base(struct irq_data *data)
 {
@@ -114,26 +114,26 @@ static struct irq_chip combiner_chip = {
 #endif
 };
 
-static void __init combiner_cascade_irq(unsigned int combiner_nr,
+static void __init combiner_cascade_irq(struct combiner_chip_data *combiner_data,
 					unsigned int irq)
 {
-	if (irq_set_handler_data(irq, &combiner_data[combiner_nr]) != 0)
+	if (irq_set_handler_data(irq, combiner_data) != 0)
 		BUG();
 	irq_set_chained_handler(irq, combiner_handle_cascade_irq);
 }
 
-static void __init combiner_init_one(unsigned int combiner_nr,
+static void __init combiner_init_one(struct combiner_chip_data *combiner_data,
+				     unsigned int combiner_nr,
 				     void __iomem *base, unsigned int irq)
 {
-	combiner_data[combiner_nr].base = base;
-	combiner_data[combiner_nr].irq_offset = irq_find_mapping(
+	combiner_data->base = base;
+	combiner_data->irq_offset = irq_find_mapping(
 		combiner_irq_domain, combiner_nr * IRQ_IN_COMBINER);
-	combiner_data[combiner_nr].irq_mask = 0xff << ((combiner_nr % 4) << 3);
-	combiner_data[combiner_nr].parent_irq = irq;
+	combiner_data->irq_mask = 0xff << ((combiner_nr % 4) << 3);
+	combiner_data->parent_irq = irq;
 
 	/* Disable all interrupts */
-	__raw_writel(combiner_data[combiner_nr].irq_mask,
-		     base + COMBINER_ENABLE_CLEAR);
+	__raw_writel(combiner_data->irq_mask, base + COMBINER_ENABLE_CLEAR);
 }
 
 #ifdef CONFIG_OF
@@ -168,6 +168,8 @@ static int combiner_irq_domain_xlate(struct irq_domain *d,
 static int combiner_irq_domain_map(struct irq_domain *d, unsigned int irq,
 				   irq_hw_number_t hw)
 {
+	struct combiner_chip_data *combiner_data = d->host_data;
+
 	irq_set_chip_and_handler(irq, &combiner_chip, handle_level_irq);
 	irq_set_chip_data(irq, &combiner_data[hw >> 3]);
 	set_irq_flags(irq, IRQF_VALID | IRQF_PROBE);
@@ -202,6 +204,7 @@ void __init combiner_init(void __iomem *combiner_base,
 {
 	int i, irq, irq_base;
 	unsigned int nr_irq;
+	struct combiner_chip_data *combiner_data;
 
 	nr_irq = max_nr * IRQ_IN_COMBINER;
 
@@ -211,8 +214,14 @@ void __init combiner_init(void __iomem *combiner_base,
 		pr_warning("%s: irq desc alloc failed. Continuing with %d as linux irq base\n", __func__, irq_base);
 	}
 
+	combiner_data = kcalloc(max_nr, sizeof (*combiner_data), GFP_KERNEL);
+	if (!combiner_data) {
+		pr_warning("%s: could not allocate combiner data\n", __func__);
+		return;
+	}
+
 	combiner_irq_domain = irq_domain_add_legacy(np, nr_irq, irq_base, 0,
-				&combiner_irq_domain_ops, &combiner_data);
+				&combiner_irq_domain_ops, combiner_data);
 	if (WARN_ON(!combiner_irq_domain)) {
 		pr_warning("%s: irq domain init failed\n", __func__);
 		return;
@@ -227,8 +236,9 @@ void __init combiner_init(void __iomem *combiner_base,
 		if (np)
 			irq = irq_of_parse_and_map(np, i);
 #endif
-		combiner_init_one(i, combiner_base + (i >> 2) * 0x10, irq);
-		combiner_cascade_irq(i, irq);
+		combiner_init_one(&combiner_data[i], i,
+				  combiner_base + (i >> 2) * 0x10, irq);
+		combiner_cascade_irq(&combiner_data[i], irq);
 	}
 }
 
-- 
1.8.1.2



From arnd at arndb.de  Fri Apr 12 10:03:21 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 12 Apr 2013 16:03:21 +0200
Subject: [PATCH 3/7] ARM: exynos: add missing properties for combiner IRQs
In-Reply-To: <1365775405-115297-1-git-send-email-arnd@arndb.de>
References: <1365775405-115297-1-git-send-email-arnd@arndb.de>
Message-ID: <1365775405-115297-4-git-send-email-arnd@arndb.de>

The exynos combiner irqchip needs to find the parent interrupts
and needs to know their number, so add the missing properties
for exynos4 as they were already present for exynos5.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 arch/arm/boot/dts/exynos4210.dtsi | 1 +
 arch/arm/boot/dts/exynos4212.dtsi | 9 +++++++++
 arch/arm/boot/dts/exynos4412.dtsi | 9 +++++++++
 3 files changed, 19 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4210.dtsi b/arch/arm/boot/dts/exynos4210.dtsi
index 15143bd..c102869 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -41,6 +41,7 @@
 	};
 
 	combiner:interrupt-controller at 10440000 {
+		combiner-nr = <16>;
 		interrupts = <0 0 0>, <0 1 0>, <0 2 0>, <0 3 0>,
 			     <0 4 0>, <0 5 0>, <0 6 0>, <0 7 0>,
 			     <0 8 0>, <0 9 0>, <0 10 0>, <0 11 0>,
diff --git a/arch/arm/boot/dts/exynos4212.dtsi b/arch/arm/boot/dts/exynos4212.dtsi
index 36d4299..f83c3c1 100644
--- a/arch/arm/boot/dts/exynos4212.dtsi
+++ b/arch/arm/boot/dts/exynos4212.dtsi
@@ -26,6 +26,15 @@
 		cpu-offset = <0x8000>;
 	};
 
+	interrupt-controller at 10440000 {
+                combiner-nr = <18>;
+		interrupts = <0 0 0>, <0 1 0>, <0 2 0>, <0 3 0>,
+			     <0 4 0>, <0 5 0>, <0 6 0>, <0 7 0>,
+			     <0 8 0>, <0 9 0>, <0 10 0>, <0 11 0>,
+			     <0 12 0>, <0 13 0>, <0 14 0>, <0 15 0>,
+			     <0 107 0>, <0 108 0>;
+	};
+
 	mct at 10050000 {
 		compatible = "samsung,exynos4412-mct";
 		reg = <0x10050000 0x800>;
diff --git a/arch/arm/boot/dts/exynos4412.dtsi b/arch/arm/boot/dts/exynos4412.dtsi
index d75c047..4cb657e 100644
--- a/arch/arm/boot/dts/exynos4412.dtsi
+++ b/arch/arm/boot/dts/exynos4412.dtsi
@@ -26,6 +26,15 @@
 		cpu-offset = <0x4000>;
 	};
 
+	interrupt-controller at 10440000 {
+		combiner-nr = <20>;
+		interrupts = <0 0 0>, <0 1 0>, <0 2 0>, <0 3 0>,
+			     <0 4 0>, <0 5 0>, <0 6 0>, <0 7 0>,
+			     <0 8 0>, <0 9 0>, <0 10 0>, <0 11 0>,
+			     <0 12 0>, <0 13 0>, <0 14 0>, <0 15 0>,
+			     <0 107 0>, <0 108 0>>, <0 48 0>, <0 42 0>;
+	};
+
 	mct at 10050000 {
 		compatible = "samsung,exynos4412-mct";
 		reg = <0x10050000 0x800>;
-- 
1.8.1.2



From arnd at arndb.de  Fri Apr 12 10:03:25 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 12 Apr 2013 16:03:25 +0200
Subject: [PATCH 7/7] irqchip: exynos: pass irq_base from platform
In-Reply-To: <1365775405-115297-1-git-send-email-arnd@arndb.de>
References: <1365775405-115297-1-git-send-email-arnd@arndb.de>
Message-ID: <1365775405-115297-8-git-send-email-arnd@arndb.de>

The platform code knows the IRQ base, while the irqchip driver
should really not. This is a littly hacky because we still
hardwire the IRQ base to 160 for the combiner in the DT case,
when we should really use -1. Removing that line will cause
a linear IRQ domain to be use, as we should.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Cc: Thomas Gleixner <tglx at linutronix.de>
---
 arch/arm/mach-exynos/common.c     |  3 ++-
 arch/arm/mach-exynos/common.h     |  2 +-
 drivers/irqchip/exynos-combiner.c | 23 +++++++++++++----------
 3 files changed, 16 insertions(+), 12 deletions(-)

diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
index ecdd212..12f43fc 100644
--- a/arch/arm/mach-exynos/common.c
+++ b/arch/arm/mach-exynos/common.c
@@ -444,7 +444,8 @@ void __init exynos4_init_irq(void)
 #endif
 
 	if (!of_have_populated_dt())
-		combiner_init(S5P_VA_COMBINER_BASE, NULL, max_combiner_nr());
+		combiner_init(S5P_VA_COMBINER_BASE, NULL,
+			      max_combiner_nr(), COMBINER_IRQ(0, 0));
 
 	/*
 	 * The parameters of s5p_init_irq() are for VIC init.
diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
index 4ba8cbe..3e72d03 100644
--- a/arch/arm/mach-exynos/common.h
+++ b/arch/arm/mach-exynos/common.h
@@ -70,7 +70,7 @@ void exynos4212_register_clocks(void);
 
 struct device_node;
 void combiner_init(void __iomem *combiner_base, struct device_node *np,
-			unsigned int max_nr);
+			unsigned int max_nr, int irq_base);
 
 extern struct smp_operations exynos_smp_ops;
 
diff --git a/drivers/irqchip/exynos-combiner.c b/drivers/irqchip/exynos-combiner.c
index acb9c74..6855c92 100644
--- a/drivers/irqchip/exynos-combiner.c
+++ b/drivers/irqchip/exynos-combiner.c
@@ -206,27 +206,22 @@ static unsigned int combiner_lookup_irq(int group)
 
 void __init combiner_init(void __iomem *combiner_base,
 			  struct device_node *np,
-			  unsigned int max_nr)
+			  unsigned int max_nr,
+			  int irq_base)
 {
-	int i, irq, irq_base;
+	int i, irq;
 	unsigned int nr_irq;
 	struct combiner_chip_data *combiner_data;
 
 	nr_irq = max_nr * IRQ_IN_COMBINER;
 
-	irq_base = irq_alloc_descs(COMBINER_IRQ(0, 0), 1, nr_irq, 0);
-	if (IS_ERR_VALUE(irq_base)) {
-		irq_base = COMBINER_IRQ(0, 0);
-		pr_warning("%s: irq desc alloc failed. Continuing with %d as linux irq base\n", __func__, irq_base);
-	}
-
 	combiner_data = kcalloc(max_nr, sizeof (*combiner_data), GFP_KERNEL);
 	if (!combiner_data) {
 		pr_warning("%s: could not allocate combiner data\n", __func__);
 		return;
 	}
 
-	combiner_irq_domain = irq_domain_add_legacy(np, nr_irq, irq_base, 0,
+	combiner_irq_domain = irq_domain_add_simple(np, nr_irq, irq_base,
 				&combiner_irq_domain_ops, combiner_data);
 	if (WARN_ON(!combiner_irq_domain)) {
 		pr_warning("%s: irq domain init failed\n", __func__);
@@ -253,6 +248,7 @@ static int __init combiner_of_init(struct device_node *np,
 {
 	void __iomem *combiner_base;
 	unsigned int max_nr = 20;
+	int irq_base = -1;
 
 	combiner_base = of_iomap(np, 0);
 	if (!combiner_base) {
@@ -266,7 +262,14 @@ static int __init combiner_of_init(struct device_node *np,
 			__func__, max_nr);
 	}
 
-	combiner_init(combiner_base, np, max_nr);
+	/* 
+	 * FIXME: This is a hardwired COMBINER_IRQ(0,0). Once all devices
+	 * get their IRQ from DT, remove this in order to get dynamic
+	 * allocation.
+	 */
+	irq_base = 160;
+
+	combiner_init(combiner_base, np, max_nr, irq_base);
 
 	return 0;
 }
-- 
1.8.1.2



From arnd at arndb.de  Fri Apr 12 10:03:20 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 12 Apr 2013 16:03:20 +0200
Subject: [PATCH 2/7] clocksource: exynos_mct: remove platform header dependency
In-Reply-To: <1365775405-115297-1-git-send-email-arnd@arndb.de>
References: <1365775405-115297-1-git-send-email-arnd@arndb.de>
Message-ID: <1365775405-115297-3-git-send-email-arnd@arndb.de>

For the non-DT case, the mct_init() function requires access
to a couple of platform specific constants, but cannot include
the header files in case we are building for multiplatform.

This changes the interface to the platform so we pass all
the necessary data as arguments to mct_init.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Cc: Thomas Gleixner <tglx at linutronix.de>
Cc: John Stultz <john.stultz at linaro.org>
---
 arch/arm/mach-exynos/common.c    |  2 +-
 arch/arm/mach-exynos/common.h    |  2 +-
 drivers/clocksource/exynos_mct.c | 21 ++++++---------------
 3 files changed, 8 insertions(+), 17 deletions(-)

diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
index 42f399a..59cb8fe 100644
--- a/arch/arm/mach-exynos/common.c
+++ b/arch/arm/mach-exynos/common.c
@@ -413,7 +413,7 @@ void __init exynos_init_time(void)
 		exynos4_clk_init(NULL, !soc_is_exynos4210(), S5P_VA_CMU, readl(S5P_VA_CHIPID + 8) & 1);
 		exynos4_clk_register_fixed_ext(xxti_f, xusbxti_f);
 #endif
-		mct_init();
+		mct_init(S5P_VA_SYSTIMER, EXYNOS4_IRQ_MCT_G0, EXYNOS4_IRQ_MCT_L0, EXYNOS4_IRQ_MCT_L1);
 	}
 }
 
diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
index 4ed8eef..9717d0f 100644
--- a/arch/arm/mach-exynos/common.h
+++ b/arch/arm/mach-exynos/common.h
@@ -14,7 +14,7 @@
 
 #include <linux/of.h>
 
-extern void mct_init(void);
+void mct_init(void __iomem *base, int irq_g0, int irq_l0, int irq_l1);
 void exynos_init_time(void);
 extern unsigned long xxti_f, xusbxti_f;
 
diff --git a/drivers/clocksource/exynos_mct.c b/drivers/clocksource/exynos_mct.c
index 509a601..2292452 100644
--- a/drivers/clocksource/exynos_mct.c
+++ b/drivers/clocksource/exynos_mct.c
@@ -26,11 +26,6 @@
 
 #include <asm/arch_timer.h>
 #include <asm/localtimer.h>
-
-#include <plat/cpu.h>
-
-#include <mach/map.h>
-#include <mach/irqs.h>
 #include <asm/mach/time.h>
 
 #define EXYNOS4_MCTREG(x)		(x)
@@ -511,18 +506,14 @@ static void __init exynos4_timer_resources(struct device_node *np, void __iomem
 #endif /* CONFIG_LOCAL_TIMERS */
 }
 
-void __init mct_init(void)
+void __init mct_init(void __iomem *base, int irq_g0, int irq_l0, int irq_l1)
 {
-	if (soc_is_exynos4210()) {
-		mct_irqs[MCT_G0_IRQ] = EXYNOS4_IRQ_MCT_G0;
-		mct_irqs[MCT_L0_IRQ] = EXYNOS4_IRQ_MCT_L0;
-		mct_irqs[MCT_L1_IRQ] = EXYNOS4_IRQ_MCT_L1;
-		mct_int_type = MCT_INT_SPI;
-	} else {
-		panic("unable to determine mct controller type\n");
-	}
+	mct_irqs[MCT_G0_IRQ] = irq_g0;
+	mct_irqs[MCT_L0_IRQ] = irq_l0;
+	mct_irqs[MCT_L1_IRQ] = irq_l1;
+	mct_int_type = MCT_INT_SPI;
 
-	exynos4_timer_resources(NULL, S5P_VA_SYSTIMER);
+	exynos4_timer_resources(NULL, base);
 	exynos4_clocksource_init();
 	exynos4_clockevent_init();
 }
-- 
1.8.1.2



From arnd at arndb.de  Fri Apr 12 10:03:22 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 12 Apr 2013 16:03:22 +0200
Subject: [PATCH 4/7] irqchip: exynos: pass max combiner number to combiner_init
In-Reply-To: <1365775405-115297-1-git-send-email-arnd@arndb.de>
References: <1365775405-115297-1-git-send-email-arnd@arndb.de>
Message-ID: <1365775405-115297-5-git-send-email-arnd@arndb.de>

We can find out the number of combined IRQs from the device
tree, but in case of ATAGS boot, the driver currently uses
hardcoded values based on the SoC type. We can't do that
in general for a multiplatform kernel, so let's instead pass
this information from platform code directly in case of
ATAGS boot.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Cc: Thomas Gleixner <tglx at linutronix.de>
---
 arch/arm/mach-exynos/common.c     | 15 ++++++++++++-
 arch/arm/mach-exynos/common.h     |  3 ++-
 drivers/irqchip/exynos-combiner.c | 46 ++++++++++++++-------------------------
 3 files changed, 32 insertions(+), 32 deletions(-)

diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
index 59cb8fe..ecdd212 100644
--- a/arch/arm/mach-exynos/common.c
+++ b/arch/arm/mach-exynos/common.c
@@ -417,6 +417,19 @@ void __init exynos_init_time(void)
 	}
 }
 
+static unsigned int max_combiner_nr(void)
+{
+	if (soc_is_exynos5250())
+		return EXYNOS5_MAX_COMBINER_NR;
+	else if (soc_is_exynos4412())
+		return EXYNOS4412_MAX_COMBINER_NR;
+	else if (soc_is_exynos4212())
+		return EXYNOS4212_MAX_COMBINER_NR;
+	else
+		return EXYNOS4210_MAX_COMBINER_NR;
+}
+
+
 void __init exynos4_init_irq(void)
 {
 	unsigned int gic_bank_offset;
@@ -431,7 +444,7 @@ void __init exynos4_init_irq(void)
 #endif
 
 	if (!of_have_populated_dt())
-		combiner_init(S5P_VA_COMBINER_BASE, NULL);
+		combiner_init(S5P_VA_COMBINER_BASE, NULL, max_combiner_nr());
 
 	/*
 	 * The parameters of s5p_init_irq() are for VIC init.
diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
index 9717d0f..4ba8cbe 100644
--- a/arch/arm/mach-exynos/common.h
+++ b/arch/arm/mach-exynos/common.h
@@ -69,7 +69,8 @@ void exynos4212_register_clocks(void);
 #endif
 
 struct device_node;
-void combiner_init(void __iomem *combiner_base, struct device_node *np);
+void combiner_init(void __iomem *combiner_base, struct device_node *np,
+			unsigned int max_nr);
 
 extern struct smp_operations exynos_smp_ops;
 
diff --git a/drivers/irqchip/exynos-combiner.c b/drivers/irqchip/exynos-combiner.c
index e8501db..d868383 100644
--- a/drivers/irqchip/exynos-combiner.c
+++ b/drivers/irqchip/exynos-combiner.c
@@ -25,6 +25,8 @@
 #define COMBINER_ENABLE_CLEAR	0x4
 #define COMBINER_INT_STATUS	0xC
 
+#define IRQ_IN_COMBINER		8
+
 static DEFINE_SPINLOCK(irq_controller_lock);
 
 struct combiner_chip_data {
@@ -112,23 +114,9 @@ static struct irq_chip combiner_chip = {
 #endif
 };
 
-static unsigned int max_combiner_nr(void)
-{
-	if (soc_is_exynos5250())
-		return EXYNOS5_MAX_COMBINER_NR;
-	else if (soc_is_exynos4412())
-		return EXYNOS4412_MAX_COMBINER_NR;
-	else if (soc_is_exynos4212())
-		return EXYNOS4212_MAX_COMBINER_NR;
-	else
-		return EXYNOS4210_MAX_COMBINER_NR;
-}
-
 static void __init combiner_cascade_irq(unsigned int combiner_nr,
 					unsigned int irq)
 {
-	if (combiner_nr >= max_combiner_nr())
-		BUG();
 	if (irq_set_handler_data(irq, &combiner_data[combiner_nr]) != 0)
 		BUG();
 	irq_set_chained_handler(irq, combiner_handle_cascade_irq);
@@ -139,7 +127,7 @@ static void __init combiner_init_one(unsigned int combiner_nr,
 {
 	combiner_data[combiner_nr].base = base;
 	combiner_data[combiner_nr].irq_offset = irq_find_mapping(
-		combiner_irq_domain, combiner_nr * MAX_IRQ_IN_COMBINER);
+		combiner_irq_domain, combiner_nr * IRQ_IN_COMBINER);
 	combiner_data[combiner_nr].irq_mask = 0xff << ((combiner_nr % 4) << 3);
 	combiner_data[combiner_nr].parent_irq = irq;
 
@@ -161,7 +149,7 @@ static int combiner_irq_domain_xlate(struct irq_domain *d,
 	if (intsize < 2)
 		return -EINVAL;
 
-	*out_hwirq = intspec[0] * MAX_IRQ_IN_COMBINER + intspec[1];
+	*out_hwirq = intspec[0] * IRQ_IN_COMBINER + intspec[1];
 	*out_type = 0;
 
 	return 0;
@@ -209,22 +197,13 @@ static unsigned int exynos4x12_combiner_extra_irq(int group)
 }
 
 void __init combiner_init(void __iomem *combiner_base,
-			  struct device_node *np)
+			  struct device_node *np,
+			  unsigned int max_nr)
 {
 	int i, irq, irq_base;
-	unsigned int max_nr, nr_irq;
+	unsigned int nr_irq;
 
-	max_nr = max_combiner_nr();
-
-	if (np) {
-		if (of_property_read_u32(np, "samsung,combiner-nr", &max_nr)) {
-			pr_info("%s: number of combiners not specified, "
-				"setting default as %d.\n",
-				__func__, max_nr);
-		}
-	}
-
-	nr_irq = max_nr * MAX_IRQ_IN_COMBINER;
+	nr_irq = max_nr * IRQ_IN_COMBINER;
 
 	irq_base = irq_alloc_descs(COMBINER_IRQ(0, 0), 1, nr_irq, 0);
 	if (IS_ERR_VALUE(irq_base)) {
@@ -258,6 +237,7 @@ static int __init combiner_of_init(struct device_node *np,
 				   struct device_node *parent)
 {
 	void __iomem *combiner_base;
+	unsigned int max_nr = 20;
 
 	combiner_base = of_iomap(np, 0);
 	if (!combiner_base) {
@@ -265,7 +245,13 @@ static int __init combiner_of_init(struct device_node *np,
 		return -ENXIO;
 	}
 
-	combiner_init(combiner_base, np);
+	if (of_property_read_u32(np, "samsung,combiner-nr", &max_nr)) {
+		pr_info("%s: number of combiners not specified, "
+			"setting default as %d.\n",
+			__func__, max_nr);
+	}
+
+	combiner_init(combiner_base, np, max_nr);
 
 	return 0;
 }
-- 
1.8.1.2



From arnd at arndb.de  Fri Apr 12 10:03:24 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 12 Apr 2013 16:03:24 +0200
Subject: [PATCH 6/7] irqchip: exynos: localize irq lookup for ATAGS
In-Reply-To: <1365775405-115297-1-git-send-email-arnd@arndb.de>
References: <1365775405-115297-1-git-send-email-arnd@arndb.de>
Message-ID: <1365775405-115297-7-git-send-email-arnd@arndb.de>

The IRQ_SPI() macro is not available in the driver when building with sparse
IRQs or multiplatform, so let's move all users of this into one function
that we can leave out when building DT-only.

Signed-off-by: Arnd Bergmann <arnd at arnd.de>
Cc: Thomas Gleixner <tglx at linutronix.de>
---
 drivers/irqchip/exynos-combiner.c | 19 ++++++++++++-------
 1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/drivers/irqchip/exynos-combiner.c b/drivers/irqchip/exynos-combiner.c
index 7fcdeee..acb9c74 100644
--- a/drivers/irqchip/exynos-combiner.c
+++ b/drivers/irqchip/exynos-combiner.c
@@ -18,7 +18,9 @@
 #include <linux/of_irq.h>
 #include <asm/mach/irq.h>
 
+#ifdef CONFIG_EXYNOS_ATAGS
 #include <plat/cpu.h>
+#endif
 
 #include "irqchip.h"
 
@@ -182,8 +184,12 @@ static struct irq_domain_ops combiner_irq_domain_ops = {
 	.map	= combiner_irq_domain_map,
 };
 
-static unsigned int exynos4x12_combiner_extra_irq(int group)
+static unsigned int combiner_lookup_irq(int group)
 {
+#ifdef CONFIG_EXYNOS_ATAGS
+	if (group < EXYNOS4210_MAX_COMBINER_NR || soc_is_exynos5250())
+		return IRQ_SPI(group);
+
 	switch (group) {
 	case 16:
 		return IRQ_SPI(107);
@@ -193,9 +199,9 @@ static unsigned int exynos4x12_combiner_extra_irq(int group)
 		return IRQ_SPI(48);
 	case 19:
 		return IRQ_SPI(42);
-	default:
-		return 0;
 	}
+#endif
+	return 0;
 }
 
 void __init combiner_init(void __iomem *combiner_base,
@@ -228,14 +234,13 @@ void __init combiner_init(void __iomem *combiner_base,
 	}
 
 	for (i = 0; i < max_nr; i++) {
-		if (i < EXYNOS4210_MAX_COMBINER_NR || soc_is_exynos5250())
-			irq = IRQ_SPI(i);
-		else
-			irq = exynos4x12_combiner_extra_irq(i);
 #ifdef CONFIG_OF
 		if (np)
 			irq = irq_of_parse_and_map(np, i);
+		else
 #endif
+			irq = combiner_lookup_irq(i);
+
 		combiner_init_one(&combiner_data[i], i,
 				  combiner_base + (i >> 2) * 0x10, irq);
 		combiner_cascade_irq(&combiner_data[i], irq);
-- 
1.8.1.2



From dave.martin at linaro.org  Fri Apr 12 10:11:45 2013
From: dave.martin at linaro.org (Dave Martin)
Date: Fri, 12 Apr 2013 15:11:45 +0100
Subject: [RFC PATCH] ARM: Remove backwards-compatibility IT macros for
 CONFIG_LTO
Message-ID: <1365775905-13173-1-git-send-email-dave.martin@linaro.org>

Old assemblers which don't support Thumb-2 also don't accept the IT
instructions.  Currently, dummy macros are defined when
CONFIG_ARM_ASM_UNIFIED=n, to allow assembly to annotate code with
IT instructions even if the tools being used are too old to support
them.

These macro definitions interfere with link-time-optimisation (LTO)
because LTO may optimise and wedge multiple compilation units
together into huge, combined source files passed to the assembler.
LTO may in general reorder compilation units at the top level,
which may also cause the macro definitions to move after the point
where they are needed.

Since LTO depends on tools far too new to lack Thumb-2 support,
this patch gets rid of the dummy macros when building .c files.
Any IT instructions should be understood natively by the assembler
and accepted [*] The macros are not strictly needed for .S files in
this case either, but they are harmless and so retained for now.

[*] Some GCC versions between 4.6 and 4.7 erroneously generate some
IT instructions in the compiler output even with -marm.  This
doesn't seem to have been causing a lot of problems for people, so
it looks like recent assemblers don't barf on those instructions.

Signed-off-by: Dave Martin <dave.martin at linaro.org>
---
If this works, I believe it can supersede other currently proposed
patches for working around this issue.

I've done dome trivial build-testing, but haven't tried this with
LTO yet and don't have a wide variety of older tools to play with.

Testing/comments would be gratefully appreciated.

 arch/arm/include/asm/unified.h |   14 ++++++++++----
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/arch/arm/include/asm/unified.h b/arch/arm/include/asm/unified.h
index f5989f4..2fafbe9 100644
--- a/arch/arm/include/asm/unified.h
+++ b/arch/arm/include/asm/unified.h
@@ -54,12 +54,18 @@
 
 #endif	/* CONFIG_THUMB2_KERNEL */
 
-#ifndef CONFIG_ARM_ASM_UNIFIED
-
+#if !defined(CONFIG_ARM_ASM_UNIFIED) && !defined(CONFIG_LTO)
 /*
  * If the unified assembly syntax isn't used (in ARM mode), these
- * macros expand to an empty string
+ * macros expand to an empty string.
+ *
+ * These macro definitions can leak between compilation units if LTO
+ * is enabled, causing post-LTO assembly failures.  Newer versions of
+ * gas will silently accept IT instructions even in non-unified mode.
+ * So we'll assume the tools are new enough in that case and skip the
+ * macro definitions.
  */
+
 #ifdef __ASSEMBLY__
 	.macro	it, cond
 	.endm
@@ -125,6 +131,6 @@ __asm__(
 "	.endm\n");
 #endif	/* __ASSEMBLY__ */
 
-#endif	/* CONFIG_ARM_ASM_UNIFIED */
+#endif	/* CONFIG_ARM_ASM_UNIFIED || CONFIG_LTO */
 
 #endif	/* !__ASM_UNIFIED_H */
-- 
1.7.9.5



From robherring2 at gmail.com  Fri Apr 12 10:13:41 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Fri, 12 Apr 2013 09:13:41 -0500
Subject: [PATCH 0/4 v6] arm: introduce psci_smp_ops and use them on Xen
In-Reply-To: <20130412085748.GC12363@mudshark.cambridge.arm.com>
References: <alpine.DEB.2.02.1304031239550.5078@kaball.uk.xensource.com>
 <alpine.DEB.2.02.1304081102500.5353@kaball.uk.xensource.com>
 <20130411082519.GD31465@quad.lixom.net> <51671A39.6090105@gmail.com>
 <20130412085748.GC12363@mudshark.cambridge.arm.com>
Message-ID: <51681695.9070400@gmail.com>

On 04/12/2013 03:57 AM, Will Deacon wrote:
> On Thu, Apr 11, 2013 at 09:16:57PM +0100, Rob Herring wrote:
>> On 04/11/2013 03:25 AM, Olof Johansson wrote:
>>> On Mon, Apr 08, 2013 at 12:05:17PM +0100, Stefano Stabellini wrote:
>>>> Arnd, Olof,
>>>> do you have any thoughts on this series?
>>>> Would you be happy to carry it in the arm-soc tree?
>>>>
>>>> The last patch, "xen/arm: introduce xen_early_init, use PSCI on xen" has
>>>> a (small) dependency on this series:
>>>>
>>>> http://marc.info/?l=linux-kernel&m=136430893610688&w=2
>>>>
>>>> would you be OK with taking that one too, or should that go through the
>>>> Xen tree?
>>>
>>> I think it'd make sense to get Russell to ack the changes to the core ARM code.
>>> We can merge the series through arm-soc, or he can take them, whatever is
>>> easiest for everybody.
>>>
>>> Given the dependencies on the second branch it might be easier to merge
>>> through Russell's tree.
>>
>> I'm also dependent on the 1st patch for converting highbank to use PSCI
>> and am just waiting on a stable branch to base it on. I believe Russell
>> said he is offline for the next week.
> 
> By the first patch, do you just mean 6/6 in that series ("[RFC] arm: use PSCI if
> available"), or do you have dependencies on others in that series too?

No, just the 1st patch in this thread: "arm: introduce psci_smp_ops"

Rob




From marc.zyngier at arm.com  Fri Apr 12 10:14:54 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Fri, 12 Apr 2013 15:14:54 +0100
Subject: [PATCH] ARM: KVM: iterate over all CPUs for CPU compatibility
 check
In-Reply-To: <516812E8.6040103@linaro.org>
References: <1365771875-5788-1-git-send-email-andre.przywara@linaro.org>
 <51680AF9.7040109@arm.com> <516812E8.6040103@linaro.org>
Message-ID: <516816DE.20501@arm.com>

On 12/04/13 14:58, Andre Przywara wrote:
> On 04/12/2013 03:24 PM, Marc Zyngier wrote:
>> On 12/04/13 14:04, Andre Przywara wrote:
>>> kvm_target_cpus() checks the compatibility of the used CPU with
>>> KVM, which is currently limited to ARM Cortex-A15 cores.
>>> However by calling it only once on any random CPU it assumes that
>>> all cores are the same, which is not true for big.LITTLE parts.
>>>
>>> After doing about 40 boots on a TC-2 core tile, I found it running
>>> in all but one case on one of the A7 cores (which correctly denied
>>> KVM initialization). On the 39th boot however the code ran on
>>> an A15, leading to a hang after returning success:
>>>
>>> ...
>>> TCP: reno registered
>>> UDP hash table entries: 512 (order: 2, 16384 bytes)
>>> UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
>>> NET: Registered protocol family 1
>>> kvm_target_cpu() on CPU #1, part is c0f0
>>>   ... (pause for a while) ...
>>> INFO: rcu_sched self-detected stall on CPUINFO: rcu_sched detected stalls on CPU
>>> s/tasks: { 1} (detected by 0, t=6002 jiffies, g=4294966999, c=4294966998, q=15)
>>> Task dump for CPU 1:
>>> swapper/0       R running      0     1      0 0x00000002
>>>
>>> So iterate over every CPU to correctly determine the capability of
>>> the system to run the current KVM implementation.
>>> In case a big.LITTLE configuration is the reason for denial, give
>>> the user a hint how to get it running anyway (maxcpus= on the kernel
>>> command line).
>>>
>>> Please push this still into 3.9.
>>>
>>> Signed-off-by: Andre Przywara <andre.przywara at linaro.org>
>>
>> [...]
>>
>> Nak. The fact that one of the CPUs seem to hang is a sure sign that
>> something is severely broken, and you definitely want to fix that issue,
>> instead of blindly ignoring it.
> 
> In general I agree, but we should fix it quickly for 3.9, as it can 
> cause a kernel hang.

Fixing it, certainly. As you have a BL system up and running, maybe you
could start by finding out what is this CPU doing, and how it ended up
there?

>> Additionally, it seems you're just papering over the issue. You should
>> be able to exclude the A7 processors, but not completely deny KVM from
>> running on the hardware.
> 
> Is there an easy way to prevent VCPUs from running on not-supported 
> cores? Something like an kvm_cpu_mask?

Probably.

> What would be the wisest hook to utilize for this?

The scheduler has sched_[gs]etaffinity(). if you're allowed to call
these though...

	M.
-- 
Jazz is not dead. It just smells funny...



From mfuzzey at parkeon.com  Fri Apr 12 10:16:35 2013
From: mfuzzey at parkeon.com (Martin Fuzzey)
Date: Fri, 12 Apr 2013 16:16:35 +0200
Subject: [PATCH] SPI: spidev: Add DT compatible string for spidev driver.
In-Reply-To: <51680C91.6030005@free-electrons.com>
References: <20130412125621.9645.78102.stgit@localhost>
 <51680C91.6030005@free-electrons.com>
Message-ID: <51681743.4020001@parkeon.com>

Hi Maxime,

On 12/04/13 15:30, Maxime Ripard wrote:
> I submitted a similar patch quite some time ago [1], and at the time, 
> this patch was found inadequate, and we decided to add the compatible 
> of the particular device that we drive through spidev. 

Thanks for pointing this out.

> The rationale behind that is that the device tree is a hardware 
> description, so it's only interested about which device there is on 
> the SPI bus, and not the driver that will eventually handle it. That 
> allows both to have a meaningful devicetree, but also to easily handle 
> the case where a driver for that particular device is finally 
> implemented, since we won't have to change the device tree in itself 
> to reflect this. 

I'm not sure this is really an advantage of using a "real" compatible 
string.

When a kernel driver is finally implemented it will not have the same 
userspace interface as spidev.

This means that the switch from spidev to the kernel driver will not be 
transparent to userspace.

So, if a "real" compatible string is used, upon upgrading to a new 
version of the kernel that adds support for that device userspace will 
break.

Using a generic compatible string allows the board maintainer to decide 
when to switch by updating the DT.

Of course, when a custom kernel is being configured and compiled, the 
problem can also be solved by not enabling the new driver but I thought 
one of the goals of DT was to enable using a single distribution style 
binary kernel images on multiple boards.

Note that my patch only changes the driver, not any DTS.
Indeed I agree that _using_ a generic compatible string in an _in 
kernel_ DTS would be a mistake for the reasons you point out.

The use case I'm talking about is where a mainline kernel is used but 
with a custom out of tree DTS - why force people to patch the driver for 
this use case?

Best regards,

Martin


From dave.martin at linaro.org  Fri Apr 12 10:22:31 2013
From: dave.martin at linaro.org (Dave Martin)
Date: Fri, 12 Apr 2013 15:22:31 +0100
Subject: hypervisor/firmware calling conventions (Was: Re: [Xen-devel]
 [PATCH 1/4] xen/arm: basic PSCI support,	implement cpu_on)
In-Reply-To: <1365765378.15783.23.camel@zakaz.uk.xensource.com>
References: <alpine.DEB.2.02.1303211837140.5135@kaball.uk.xensource.com>
 <1363891353-13827-1-git-send-email-stefano.stabellini@eu.citrix.com>
 <1365515874.10725.33.camel@zakaz.uk.xensource.com>
 <1365687148.8036.140.camel@zakaz.uk.xensource.com>
 <20130411170959.GA2239@linaro.org>
 <1365765378.15783.23.camel@zakaz.uk.xensource.com>
Message-ID: <20130412142231.GA2992@linaro.org>

On Fri, Apr 12, 2013 at 12:16:18PM +0100, Ian Campbell wrote:
> On Thu, 2013-04-11 at 18:10 +0100, Dave Martin wrote:
> > On Thu, Apr 11, 2013 at 02:32:28PM +0100, Ian Campbell wrote:
> > > Adding Charles and the l-a-k list which I hadn't noticed wasn't CC'd
> > > before. Are there other lists which would be useful to include?
> > > 
> > > On Tue, 2013-04-09 at 14:57 +0100, Ian Campbell wrote:
> > > > > +        if ( !hsr.iss )
> > > > > +            return do_trap_psci(regs);
> > 
> > Have you seen this work?
> 
> I presume Stefano has.
> 
> > Reading the specs, I thought that the SMC immediate is not available in
> > the HSR in ARMv7, or when the caller is AArch32.  ARMv7 specifies these
> > bits as UNK/SBZP, and the A15 TRM doesn't seem seem to specify any
> > extra information.
> 
> I trimmed the context so you probably don't know but this is handling
> PSCI via an HVC call not SMC, Linux lets you specify which to use in the
> DTB.
> 
> I didn't know that about SMC though -- think my eye confused it with
> SVC when I scanned the docs. Kind of a lame limitation...

Ah, OK (I'm remembering previous threads now).  Yes, I think the comment
field is guaranteed to appear in HSR.ISS for HVCs.


SMC pre-dates the existence of exception syndrome registers, so software
should in general not have been relying on the immediate for that anyway
(but what software should do and what it actually does do are of course not
always the same).


> > Otherwise, you would need to go examine the trapped instruction in
> > guest memory.  This is even less easy than it sounds.
> 
> Right, luckily we avoid it by using hvc.
> 
> > > > Ugh, using ISS==0 for this interface is a bit unfortunate, who
> > > > arbitrates this namespace?
> > 
> > Nobody, officially.  ARM is working to promulgate some standards in
> > this area, but there is plenty of pre-existing firmware and software
> > out there with non-standardised interfaces and it's hard to predict
> > adoption timescales.  I believe nothing is published relating to this
> > just yet.
> > 
> > > Xen chose to use a non-0 immediate for its hypercalls so we are lucky
> > > that we don't have to play tricks to distinguish PSCI calls from
> > > hypercalls but it seems to me that either there needs to be some
> > > semi-formal registry for smv/hvc immediates to avoid clashes or that
> > > interfaces need to pick a random non-zero number to try and minimise the
> > > chances of a clash.
> > > 
> > > Or maybe it gets pushed down a layer and the registry is of r0/x0
> > > function ids and the immediate argument is generally ignored?
> > > 
> > > But in general we need some way for interfaces provided by hypervisors
> > > and secure mode monitors to safely co-exist, I think, both for the case
> > > where the hypervisor is implementing a shim for a secure mode interface
> > > (i.e. implementing PSCI with hvc) and for the case where there are
> > > multiple interfaces at each layer (e.g. hypervisors sometimes want to
> > > implement foreign hypervisor interfaces and I can easily imagine other
> > > firmware level interfaces than PSCI coming into existence in the
> > > future).
> > 
> > For PSCI and similar firmware functionality, we envisage multiplexing
> > all interfaces based on a function number in r0, with arguments and
> > results constrained to r0-r7.  For PSCI, we specify SMC #0/HVC #0 as the
> > call mechanism.
> > 
> > For now, there is no global management of the r0 namespace, which
> > is why for PSCI we don't make static assumptions about the numbers
> > on the client side.  Instead, the function number for each PSCI function
> > is passed in the DT.  This means that the firmware or hypervisor can
> > allocate the numbers as appropriate to avoid clashes.
> > 
> > In general, this is likely to be the best approach for Linux until a
> > standard probing interface exists.
> 
> Yes, this is as good a scheme as we can hope for right now I think.
>  
> > In theory we could define a Xen-specific call mechanism for PSCI, but
> > that should be avoided unless it is absolutely unavoidable.  It sounds
> > like the different SMC comment field means that we don't need to
> > worry for Xen/PSCI coexistence specifically, assuming that the hypervisor
> > can read it reliably.
> 
> I think we've got the Xen side in hand, I was more bringing it up as a
> general issue.

OK, sounds good.

The PSCI bindings make it possible for the firmware or hypervisor to
manage the function ID namespace, so we should encourage people to
follow a similar approach for anything new, at least until there is
a better standard.

> > > In the specific case of PSCI I couldn't actually find the calling
> > > convention (i.e. the specific registers to use). I suspect I'm just
> > > looking at an old version of the spec...
> > 
> > This is indeed vague in the existing draft.  An update should appear
> > soon -- Charles can comment on the current status.
 
Cheers
---Dave


From lorenzo.pieralisi at arm.com  Fri Apr 12 10:26:50 2013
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Fri, 12 Apr 2013 15:26:50 +0100
Subject: [PATCH v2 1/2] ARM: shmobile: r8a7740: Add Suspend-To-RAM A3SM
In-Reply-To: <1365689264-14410-1-git-send-email-hechtb+renesas@gmail.com>
References: <1365689264-14410-1-git-send-email-hechtb+renesas@gmail.com>
Message-ID: <20130412142649.GE6637@e102568-lin.cambridge.arm.com>

On Thu, Apr 11, 2013 at 03:07:43PM +0100, Bastian Hecht wrote:

[...]

> diff --git a/arch/arm/mach-shmobile/sleep-r8a7740.S b/arch/arm/mach-shmobile/sleep-r8a7740.S
> new file mode 100644
> index 0000000..762f978
> --- /dev/null
> +++ b/arch/arm/mach-shmobile/sleep-r8a7740.S
> @@ -0,0 +1,72 @@
> +/*
> + * Low level sleep code for the SoC r8a7740
> + *
> + * Copyright (C) 2013 Bastian Hecht
> + *
> + * This file is subject to the terms and conditions of the GNU General Public
> + * License.  See the file "COPYING" in the main directory of this archive
> + * for more details.
> + */
> +
> +#include <linux/linkage.h>
> +#include <linux/init.h>
> +#include <asm/memory.h>
> +
> +#ifdef CONFIG_SUSPEND
> +
> +/* r8a7740_shutdown expects L2 to be flushed */
> +	.text
> +ENTRY(r8a7740_shutdown)
> +	stmfd   sp!, {r4-r12, lr}
> +
> +	/* make sure the stack stays intact */
> +	bl      v7_flush_dcache_all
> +

Why do not you move the cache flush above after clearing the C bit ?
You must not push on the stack _after_ clearing the C bit and before
cleaning the cache, that's the only requirement (well basically you
should not write any data and do not rely on any dirty data sitting
in the cache, since with the C bit cleared as I already said A9 L1
D-cache is not searched).

AS long as, with C bit cleared, you do NOT push on the stack before
cleaning the cache, your cache flushing routine will clean data to DRAM,
so you are fine. v7_flush_dcache_all does not use the stack.

	mrc	p15, 0, r0, c1, c0, 0
	bic	r0, r0, #(1 << 2)		@ Disable the C bit
	mcr	p15, 0, r0, c1, c0, 0
	isb
	bl      v7_flush_dcache_all

This code snippet will do and it is compliant with the SMP procedure,
I do not want people to copy'n'paste code that does not work on SMP,
I know this code runs on UP so the sequence above is safe, but why not make
the sequence identical for both UP/SMP ?

> +	/*
> +	 * Clear the SCTLR.C bit to prevent further data cache
> +	 * allocation. Clearing SCTLR.C would make all the data accesses
> +	 * strongly ordered and would not hit the cache.
> +	 */
> +	mrc	p15, 0, r0, c1, c0, 0
> +	bic	r0, r0, #(1 << 2)		@ Disable the C bit
> +	mcr	p15, 0, r0, c1, c0, 0
> +	isb
> +
> +	/*
> +	 * We don't issue another v7_flush_dcache_all here as seen in many
> +	 * other places as we have a UP core and the L1 could not soak up
> +	 * data from other L1 caches in the meantime.
> +	 */
> +
> +	bl	cpu_v7_do_idle
> +
> +	/* in rare cases when WFI fails we end up here and restore things */

I am still baffled by this "wfi failures" and how hardware can manage
this situation _properly_, if you can explain to me how this works
that would be grand. This code is also called by CPUidle right ? So,
IRQs can still cause wfi completion, there has to be a handshake between
the core and power controller to prevent the CPU from being shutdown
while executing code (power down command sent, standbywfi asserted and
then released following wfi completion).

Anyway, I do not like the code sequence (and I know that eg OMAP4 executes
the same code) above because again, it works on UP, but people might be
tempted to copy'n'paste it to their SMP implementation (with the addition
of SMP bit restore in ACTLR).

OMAP4 sequence is missing TLB flush since the core runs for a time window with
incoherent TLBs (out of SMP). It works because other cores can't update
their page tables while the core exiting wfi is running out of coherency
(ie coupled idle C-states, either all CPUs down or no CPU down), but
again, that code should not be copied verbatim since it fails to flush
TLBs, AFAIK.

Again, you are running a UP kernel so this code does not suffer from
the same problem, but if this code is copied and used on SMP platforms then
we do have problem and that has to be prevented.

Why do not you turn MMU off (cpu_reset) and jump to the reset vector if
wfi fails (code in arch/arm/kernel/process.c __soft_restart(), minus the
cache flushing ?

	phys_reset_t phys_reset;

	/* Take out a flat memory mapping. */
	setup_mm_for_reboot();

	phys_reset = (phys_reset_t)(unsigned long)virt_to_phys(cpu_reset);
	phys_reset((unsigned long)addr);

	BUG();

where addr == virt_to_phys(cpu_resume);

from what I gather from the code below.

There is just a tiny performance hit owing to a couple of fetches from
DRAM (MMU off), then cpu_resume restores the C bit and the MMU (and flushes
the TLBs) so the virtual address space and caches are back on. By the time wfi
fails, caches are invalid anyway so in both cases they have to be refilled.

On top of that, this code is not really SH specific, it is plain v7 code
that can be standardised.

For now it is just a, hopefully useful, rant.

Lorenzo

> +	mrc	p15, 0, r0, c1, c0, 0
> +	orr	r0, r0, #(1 << 2)		@ Enable the C bit
> +	mcr	p15, 0, r0, c1, c0, 0
> +	isb
> +
> +	ldmfd   sp!, {r4-r12, pc}
> +ENDPROC(r8a7740)
> +
> +	.text
> +ENTRY(v7_cpu_resume)
> +	bl	v7_invalidate_l1
> +	b	cpu_resume
> +ENDPROC(v7_cpu_resume)
> +
> +/*
> + * The entry point of a warm reboot, used by wakeup scenarios
> + *
> + * The CPU jumps in this case to (0xfffff000 & SBAR), so we need
> + * to align this function properly.
> + * We use a long jump into the text segment and use the physical
> + * address as the MMU is still turned off.
> + */
> +	.align	12
> +	.text
> +ENTRY(r8a7740_resume)
> +	ldr	pc, 1f
> +1:	.long	v7_cpu_resume - PAGE_OFFSET + PLAT_PHYS_OFFSET
> +ENDPROC(r8a7740_resume_core_standby)
> +#endif
> -- 



From gregory.clement at free-electrons.com  Fri Apr 12 10:29:05 2013
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Fri, 12 Apr 2013 16:29:05 +0200
Subject: [PATCH v4 0/5]  LPAE remaining device tree file
Message-ID: <1365776950-30094-1-git-send-email-gregory.clement@free-electrons.com>

Hi Jason,

I have just rebased the commits that you haven't applied yet. They are
rebased on mvebu/dt. I check that all the dtb can be built.

Thanks,

Gregory CLEMENT (3):
  ARM: dts: mvebu: Convert all the mvebu files to use the range
    property
  ARM: dts: mvebu: introduce internal-regs node
  ARM: dts: mvebu: Convert mvebu device tree files to 64 bits

Thomas Petazzoni (2):
  ARM: dts: mvebu: fix cpus section indentation
  ARM: dts: mvebu: move all peripherals inside soc

 arch/arm/boot/dts/armada-370-db.dts              |  134 +++---
 arch/arm/boot/dts/armada-370-mirabox.dts         |  176 ++++----
 arch/arm/boot/dts/armada-370-rd.dts              |   96 ++---
 arch/arm/boot/dts/armada-370-xp.dtsi             |  336 +++++++--------
 arch/arm/boot/dts/armada-370.dtsi                |  330 +++++++--------
 arch/arm/boot/dts/armada-xp-db.dts               |  202 ++++-----
 arch/arm/boot/dts/armada-xp-gp.dts               |  222 +++++-----
 arch/arm/boot/dts/armada-xp-mv78230.dtsi         |  284 ++++++-------
 arch/arm/boot/dts/armada-xp-mv78260.dtsi         |  342 +++++++--------
 arch/arm/boot/dts/armada-xp-mv78460.dtsi         |  484 +++++++++++-----------
 arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts |  262 ++++++------
 arch/arm/boot/dts/armada-xp.dtsi                 |  202 ++++-----
 12 files changed, 1549 insertions(+), 1521 deletions(-)

-- 
1.7.9.5



From gregory.clement at free-electrons.com  Fri Apr 12 10:29:06 2013
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Fri, 12 Apr 2013 16:29:06 +0200
Subject: [PATCH v4 1/5] ARM: dts: mvebu: fix cpus section indentation
In-Reply-To: <1365776950-30094-1-git-send-email-gregory.clement@free-electrons.com>
References: <1365776950-30094-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1365776950-30094-2-git-send-email-gregory.clement@free-electrons.com>

From: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>

Align the cpu node indentation with the rest of the file

[gc]: added a commit description
Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 arch/arm/boot/dts/armada-xp-mv78230.dtsi |   32 +++++++++---------
 arch/arm/boot/dts/armada-xp-mv78260.dtsi |   32 +++++++++---------
 arch/arm/boot/dts/armada-xp-mv78460.dtsi |   54 +++++++++++++++---------------
 3 files changed, 59 insertions(+), 59 deletions(-)

diff --git a/arch/arm/boot/dts/armada-xp-mv78230.dtsi b/arch/arm/boot/dts/armada-xp-mv78230.dtsi
index c2c7845..e072a53 100644
--- a/arch/arm/boot/dts/armada-xp-mv78230.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78230.dtsi
@@ -25,22 +25,22 @@
 	};
 
 	cpus {
-	    #address-cells = <1>;
-	    #size-cells = <0>;
-
-	    cpu at 0 {
-		device_type = "cpu";
-		compatible = "marvell,sheeva-v7";
-		reg = <0>;
-		clocks = <&cpuclk 0>;
-	    };
-
-	    cpu at 1 {
-		device_type = "cpu";
-		compatible = "marvell,sheeva-v7";
-		reg = <1>;
-		clocks = <&cpuclk 1>;
-	    };
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		cpu at 0 {
+			device_type = "cpu";
+			compatible = "marvell,sheeva-v7";
+			reg = <0>;
+			clocks = <&cpuclk 0>;
+		};
+
+		cpu at 1 {
+			device_type = "cpu";
+			compatible = "marvell,sheeva-v7";
+			reg = <1>;
+			clocks = <&cpuclk 1>;
+		};
 	};
 
 	soc {
diff --git a/arch/arm/boot/dts/armada-xp-mv78260.dtsi b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
index 885bf22..6dae1bc 100644
--- a/arch/arm/boot/dts/armada-xp-mv78260.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
@@ -26,22 +26,22 @@
 	};
 
 	cpus {
-	    #address-cells = <1>;
-	    #size-cells = <0>;
-
-	    cpu at 0 {
-		device_type = "cpu";
-		compatible = "marvell,sheeva-v7";
-		reg = <0>;
-		clocks = <&cpuclk 0>;
-	    };
-
-	    cpu at 1 {
-		device_type = "cpu";
-		compatible = "marvell,sheeva-v7";
-		reg = <1>;
-		clocks = <&cpuclk 1>;
-	    };
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		cpu at 0 {
+			device_type = "cpu";
+			compatible = "marvell,sheeva-v7";
+			reg = <0>;
+			clocks = <&cpuclk 0>;
+		};
+
+		cpu at 1 {
+			device_type = "cpu";
+			compatible = "marvell,sheeva-v7";
+			reg = <1>;
+			clocks = <&cpuclk 1>;
+		};
 	};
 
 	soc {
diff --git a/arch/arm/boot/dts/armada-xp-mv78460.dtsi b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
index 23a5ac4..b9da5b8 100644
--- a/arch/arm/boot/dts/armada-xp-mv78460.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
@@ -27,36 +27,36 @@
 
 
 	cpus {
-	    #address-cells = <1>;
-	    #size-cells = <0>;
+		#address-cells = <1>;
+		#size-cells = <0>;
 
-	    cpu at 0 {
-		device_type = "cpu";
-		compatible = "marvell,sheeva-v7";
-		reg = <0>;
-		clocks = <&cpuclk 0>;
-	    };
+		cpu at 0 {
+			device_type = "cpu";
+			compatible = "marvell,sheeva-v7";
+			reg = <0>;
+			clocks = <&cpuclk 0>;
+		};
 
-	    cpu at 1 {
-		device_type = "cpu";
-		compatible = "marvell,sheeva-v7";
-		reg = <1>;
-		clocks = <&cpuclk 1>;
-	    };
+		cpu at 1 {
+			device_type = "cpu";
+			compatible = "marvell,sheeva-v7";
+			reg = <1>;
+			clocks = <&cpuclk 1>;
+		};
 
-	    cpu at 2 {
-		device_type = "cpu";
-		compatible = "marvell,sheeva-v7";
-		reg = <2>;
-		clocks = <&cpuclk 2>;
-	    };
+		cpu at 2 {
+			device_type = "cpu";
+			compatible = "marvell,sheeva-v7";
+			reg = <2>;
+			clocks = <&cpuclk 2>;
+		};
 
-	    cpu at 3 {
-		device_type = "cpu";
-		compatible = "marvell,sheeva-v7";
-		reg = <3>;
-		clocks = <&cpuclk 3>;
-	    };
+		cpu at 3 {
+			device_type = "cpu";
+			compatible = "marvell,sheeva-v7";
+			reg = <3>;
+			clocks = <&cpuclk 3>;
+		};
 	};
 
 	soc {
@@ -300,4 +300,4 @@
 			};
 		};
 	};
- };
+};
-- 
1.7.9.5



From gregory.clement at free-electrons.com  Fri Apr 12 10:29:07 2013
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Fri, 12 Apr 2013 16:29:07 +0200
Subject: [PATCH v4 2/5] ARM: dts: mvebu: move all peripherals inside soc
In-Reply-To: <1365776950-30094-1-git-send-email-gregory.clement@free-electrons.com>
References: <1365776950-30094-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1365776950-30094-3-git-send-email-gregory.clement@free-electrons.com>

From: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>

reorganize the .dts and .dtsi files so that all devices are under the
soc { } node (currently some devices such as the interrupt controller,
the L2 cache and a few others are outside).

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 arch/arm/boot/dts/armada-370-xp.dtsi |   26 +++++++++++++-------------
 arch/arm/boot/dts/armada-370.dtsi    |   23 ++++++++++++-----------
 arch/arm/boot/dts/armada-xp.dtsi     |   32 ++++++++++++++++----------------
 3 files changed, 41 insertions(+), 40 deletions(-)

diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi b/arch/arm/boot/dts/armada-370-xp.dtsi
index 9693f79..972448c 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -28,19 +28,6 @@
 		};
 	};
 
-	mpic: interrupt-controller at d0020000 {
-	      compatible = "marvell,mpic";
-	      #interrupt-cells = <1>;
-	      #size-cells = <1>;
-	      interrupt-controller;
-	};
-
-	coherency-fabric at d0020200 {
-		compatible = "marvell,coherency-fabric";
-		reg = <0xd0020200 0xb0>,
-		      <0xd0021810 0x1c>;
-	};
-
 	soc {
 		#address-cells = <1>;
 		#size-cells = <1>;
@@ -48,6 +35,19 @@
 		interrupt-parent = <&mpic>;
 		ranges;
 
+		mpic: interrupt-controller at d0020000 {
+			compatible = "marvell,mpic";
+			#interrupt-cells = <1>;
+			#size-cells = <1>;
+			interrupt-controller;
+		};
+
+		coherency-fabric at d0020200 {
+			compatible = "marvell,coherency-fabric";
+			reg = <0xd0020200 0xb0>,
+			      <0xd0021810 0x1c>;
+		};
+
 		serial at d0012000 {
 				compatible = "snps,dw-apb-uart";
 				reg = <0xd0012000 0x100>;
diff --git a/arch/arm/boot/dts/armada-370.dtsi b/arch/arm/boot/dts/armada-370.dtsi
index 18f6eb4..209caeb 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -20,12 +20,6 @@
 / {
 	model = "Marvell Armada 370 family SoC";
 	compatible = "marvell,armada370", "marvell,armada-370-xp";
-	L2: l2-cache {
-		compatible = "marvell,aurora-outer-cache";
-		reg = <0xd0008000 0x1000>;
-		cache-id-part = <0x100>;
-		wt-override;
-	};
 
 	aliases {
 		gpio0 = &gpio0;
@@ -33,17 +27,24 @@
 		gpio2 = &gpio2;
 	};
 
-	mpic: interrupt-controller at d0020000 {
-	      reg = <0xd0020a00 0x1d0>,
-		    <0xd0021870 0x58>;
-	};
-
 	soc {
+		mpic: interrupt-controller at d0020000 {
+			reg = <0xd0020a00 0x1d0>,
+			      <0xd0021870 0x58>;
+		};
+
 		system-controller at d0018200 {
 				compatible = "marvell,armada-370-xp-system-controller";
 				reg = <0xd0018200 0x100>;
 		};
 
+		L2: l2-cache {
+			compatible = "marvell,aurora-outer-cache";
+			reg = <0xd0008000 0x1000>;
+			cache-id-part = <0x100>;
+			wt-override;
+		};
+
 		pinctrl {
 			compatible = "marvell,mv88f6710-pinctrl";
 			reg = <0xd0018000 0x38>;
diff --git a/arch/arm/boot/dts/armada-xp.dtsi b/arch/arm/boot/dts/armada-xp.dtsi
index 29dfeb6..ef3d413 100644
--- a/arch/arm/boot/dts/armada-xp.dtsi
+++ b/arch/arm/boot/dts/armada-xp.dtsi
@@ -22,25 +22,25 @@
 	model = "Marvell Armada XP family SoC";
 	compatible = "marvell,armadaxp", "marvell,armada-370-xp";
 
-	L2: l2-cache {
-		compatible = "marvell,aurora-system-cache";
-		reg = <0xd0008000 0x1000>;
-		cache-id-part = <0x100>;
-		wt-override;
-	};
+	soc {
+		L2: l2-cache {
+			compatible = "marvell,aurora-system-cache";
+			reg = <0xd0008000 0x1000>;
+			cache-id-part = <0x100>;
+			wt-override;
+		};
 
-	mpic: interrupt-controller at d0020000 {
-	      reg = <0xd0020a00 0x2d0>,
-		    <0xd0021070 0x58>;
-	};
+		mpic: interrupt-controller at d0020000 {
+		      reg = <0xd0020a00 0x2d0>,
+			    <0xd0021070 0x58>;
+		};
 
-	armada-370-xp-pmsu at d0022000 {
-		compatible = "marvell,armada-370-xp-pmsu";
-		reg = <0xd0022100 0x430>,
-		      <0xd0020800 0x20>;
-	};
+		armada-370-xp-pmsu at d0022000 {
+			compatible = "marvell,armada-370-xp-pmsu";
+			reg = <0xd0022100 0x430>,
+			      <0xd0020800 0x20>;
+		};
 
-	soc {
 		serial at d0012200 {
 				compatible = "snps,dw-apb-uart";
 				reg = <0xd0012200 0x100>;
-- 
1.7.9.5



From gregory.clement at free-electrons.com  Fri Apr 12 10:29:08 2013
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Fri, 12 Apr 2013 16:29:08 +0200
Subject: [PATCH v4 3/5] ARM: dts: mvebu: Convert all the mvebu files to use
 the range property
In-Reply-To: <1365776950-30094-1-git-send-email-gregory.clement@free-electrons.com>
References: <1365776950-30094-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1365776950-30094-4-git-send-email-gregory.clement@free-electrons.com>

This conversion will allow to keep 32 bits addresses for the internal
registers whereas the memory of the system will be 64 bits.
Later it will also ease the move of the mvebu-mbus driver to the
device tree support.

Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
---
 arch/arm/boot/dts/armada-370-db.dts              |   16 ++--
 arch/arm/boot/dts/armada-370-mirabox.dts         |   16 ++--
 arch/arm/boot/dts/armada-370-rd.dts              |   14 +--
 arch/arm/boot/dts/armada-370-xp.dtsi             |   99 +++++++++++-----------
 arch/arm/boot/dts/armada-370.dtsi                |   65 +++++++-------
 arch/arm/boot/dts/armada-xp-db.dts               |   28 +++---
 arch/arm/boot/dts/armada-xp-gp.dts               |   22 ++---
 arch/arm/boot/dts/armada-xp-mv78230.dtsi         |   30 +++----
 arch/arm/boot/dts/armada-xp-mv78260.dtsi         |   44 +++++-----
 arch/arm/boot/dts/armada-xp-mv78460.dtsi         |   58 ++++++-------
 arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts |   24 +++---
 arch/arm/boot/dts/armada-xp.dtsi                 |   71 ++++++++--------
 12 files changed, 245 insertions(+), 242 deletions(-)

diff --git a/arch/arm/boot/dts/armada-370-db.dts b/arch/arm/boot/dts/armada-370-db.dts
index 6403acd..e766f8b 100644
--- a/arch/arm/boot/dts/armada-370-db.dts
+++ b/arch/arm/boot/dts/armada-370-db.dts
@@ -30,11 +30,11 @@
 	};
 
 	soc {
-		serial at d0012000 {
+		serial at 12000 {
 			clock-frequency = <200000000>;
 			status = "okay";
 		};
-		sata at d00a0000 {
+		sata at a0000 {
 			nr-ports = <2>;
 			status = "okay";
 		};
@@ -49,18 +49,18 @@
 			};
 		};
 
-		ethernet at d0070000 {
+		ethernet at 70000 {
 			status = "okay";
 			phy = <&phy0>;
 			phy-mode = "rgmii-id";
 		};
-		ethernet at d0074000 {
+		ethernet at 74000 {
 			status = "okay";
 			phy = <&phy1>;
 			phy-mode = "rgmii-id";
 		};
 
-		mvsdio at d00d4000 {
+		mvsdio at d4000 {
 			pinctrl-0 = <&sdio_pins1>;
 			pinctrl-names = "default";
 			/*
@@ -75,15 +75,15 @@
 			/* No CD or WP GPIOs */
 		};
 
-		usb at d0050000 {
+		usb at 50000 {
 			status = "okay";
 		};
 
-		usb at d0051000 {
+		usb at 51000 {
 			status = "okay";
 		};
 
-		spi0: spi at d0010600 {
+		spi0: spi at 10600 {
 			status = "okay";
 
 			spi-flash at 0 {
diff --git a/arch/arm/boot/dts/armada-370-mirabox.dts b/arch/arm/boot/dts/armada-370-mirabox.dts
index 58ee793..6530ae3 100644
--- a/arch/arm/boot/dts/armada-370-mirabox.dts
+++ b/arch/arm/boot/dts/armada-370-mirabox.dts
@@ -25,11 +25,11 @@
 	};
 
 	soc {
-		serial at d0012000 {
+		serial at 12000 {
 			clock-frequency = <200000000>;
 			status = "okay";
 		};
-		timer at d0020300 {
+		timer at 20300 {
 			clock-frequency = <600000000>;
 			status = "okay";
 		};
@@ -79,18 +79,18 @@
 				reg = <1>;
 			};
 		};
-		ethernet at d0070000 {
+		ethernet at 70000 {
 			status = "okay";
 			phy = <&phy0>;
 			phy-mode = "rgmii-id";
 		};
-		ethernet at d0074000 {
+		ethernet at 74000 {
 			status = "okay";
 			phy = <&phy1>;
 			phy-mode = "rgmii-id";
 		};
 
-		mvsdio at d00d4000 {
+		mvsdio at d4000 {
 			pinctrl-0 = <&sdio_pins3>;
 			pinctrl-names = "default";
 			status = "okay";
@@ -100,15 +100,15 @@
 			 */
 		};
 
-		usb at d0050000 {
+		usb at 50000 {
 			status = "okay";
 		};
 
-		usb at d0051000 {
+		usb at 51000 {
 			status = "okay";
 		};
 
-		i2c at d0011000 {
+		i2c at 11000 {
 			status = "okay";
 			clock-frequency = <100000>;
 			pca9505: pca9505 at 25 {
diff --git a/arch/arm/boot/dts/armada-370-rd.dts b/arch/arm/boot/dts/armada-370-rd.dts
index 516dec3..83d5c04 100644
--- a/arch/arm/boot/dts/armada-370-rd.dts
+++ b/arch/arm/boot/dts/armada-370-rd.dts
@@ -28,11 +28,11 @@
 	};
 
 	soc {
-		serial at d0012000 {
+		serial at 12000 {
 			clock-frequency = <200000000>;
 			status = "okay";
 		};
-		sata at d00a0000 {
+		sata at a0000 {
 			nr-ports = <2>;
 			status = "okay";
 		};
@@ -47,29 +47,29 @@
 			};
 		};
 
-		ethernet at d0070000 {
+		ethernet at 70000 {
 			status = "okay";
 			phy = <&phy0>;
 			phy-mode = "sgmii";
 		};
-		ethernet at d0074000 {
+		ethernet at 74000 {
 			status = "okay";
 			phy = <&phy1>;
 			phy-mode = "rgmii-id";
 		};
 
-		mvsdio at d00d4000 {
+		mvsdio at d4000 {
 			pinctrl-0 = <&sdio_pins1>;
 			pinctrl-names = "default";
 			status = "okay";
 			/* No CD or WP GPIOs */
 		};
 
-		usb at d0050000 {
+		usb at 50000 {
 			status = "okay";
 		};
 
-		usb at d0051000 {
+		usb at 51000 {
 			status = "okay";
 		};
 	};
diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi b/arch/arm/boot/dts/armada-370-xp.dtsi
index 972448c..da40ce5 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -28,54 +28,55 @@
 		};
 	};
 
+
 	soc {
 		#address-cells = <1>;
 		#size-cells = <1>;
 		compatible = "simple-bus";
 		interrupt-parent = <&mpic>;
-		ranges;
+		ranges = <0 0xd0000000 0x100000>;
 
-		mpic: interrupt-controller at d0020000 {
-			compatible = "marvell,mpic";
-			#interrupt-cells = <1>;
-			#size-cells = <1>;
-			interrupt-controller;
+		mpic: interrupt-controller at 20000 {
+				compatible = "marvell,mpic";
+				#interrupt-cells = <1>;
+				#size-cells = <1>;
+				interrupt-controller;
 		};
 
-		coherency-fabric at d0020200 {
-			compatible = "marvell,coherency-fabric";
-			reg = <0xd0020200 0xb0>,
-			      <0xd0021810 0x1c>;
+		coherency-fabric at 20200 {
+				compatible = "marvell,coherency-fabric";
+				reg = <0x20200 0xb0>,
+				      <0x21810 0x1c>;
 		};
 
-		serial at d0012000 {
+		serial at 12000 {
 				compatible = "snps,dw-apb-uart";
-				reg = <0xd0012000 0x100>;
+				reg = <0x12000 0x100>;
 				reg-shift = <2>;
 				interrupts = <41>;
 				reg-io-width = <1>;
 				status = "disabled";
 		};
-		serial at d0012100 {
+		serial at 12100 {
 				compatible = "snps,dw-apb-uart";
-				reg = <0xd0012100 0x100>;
+				reg = <0x12100 0x100>;
 				reg-shift = <2>;
 				interrupts = <42>;
 				reg-io-width = <1>;
 				status = "disabled";
 		};
 
-		timer at d0020300 {
+		timer at 20300 {
 			       compatible = "marvell,armada-370-xp-timer";
-			       reg = <0xd0020300 0x30>,
-			       <0xd0021040 0x30>;
+			       reg = <0x20300 0x30>,
+			       <0x21040 0x30>;
 			       interrupts = <37>, <38>, <39>, <40>, <5>, <6>;
 			       clocks = <&coreclk 2>;
 		};
 
-		sata at d00a0000 {
+		sata at a0000 {
 			compatible = "marvell,orion-sata";
-			reg = <0xd00a0000 0x2400>;
+			reg = <0xa0000 0x2400>;
 			interrupts = <55>;
 			clocks = <&gateclk 15>, <&gateclk 30>;
 			clock-names = "0", "1";
@@ -86,28 +87,28 @@
 			#address-cells = <1>;
 			#size-cells = <0>;
 			compatible = "marvell,orion-mdio";
-			reg = <0xd0072004 0x4>;
+			reg = <0x72004 0x4>;
 		};
 
-		ethernet at d0070000 {
+		ethernet at 70000 {
 				compatible = "marvell,armada-370-neta";
-				reg = <0xd0070000 0x2500>;
+				reg = <0x70000 0x2500>;
 				interrupts = <8>;
 				clocks = <&gateclk 4>;
 				status = "disabled";
 		};
 
-		ethernet at d0074000 {
+		ethernet at 74000 {
 				compatible = "marvell,armada-370-neta";
-				reg = <0xd0074000 0x2500>;
+				reg = <0x74000 0x2500>;
 				interrupts = <10>;
 				clocks = <&gateclk 3>;
 				status = "disabled";
 		};
 
-		i2c0: i2c at d0011000 {
+		i2c0: i2c at 11000 {
 			compatible = "marvell,mv64xxx-i2c";
-			reg = <0xd0011000 0x20>;
+			reg = <0x11000 0x20>;
 			#address-cells = <1>;
 			#size-cells = <0>;
 			interrupts = <31>;
@@ -116,9 +117,9 @@
 			status = "disabled";
 		};
 
-		i2c1: i2c at d0011100 {
+		i2c1: i2c at 11100 {
 			compatible = "marvell,mv64xxx-i2c";
-			reg = <0xd0011100 0x20>;
+			reg = <0x11100 0x20>;
 			#address-cells = <1>;
 			#size-cells = <0>;
 			interrupts = <32>;
@@ -129,35 +130,35 @@
 
 		rtc at 10300 {
 			compatible = "marvell,orion-rtc";
-			reg = <0xd0010300 0x20>;
+			reg = <0x10300 0x20>;
 			interrupts = <50>;
 		};
 
-		mvsdio at d00d4000 {
+		mvsdio at d4000 {
 			compatible = "marvell,orion-sdio";
-			reg = <0xd00d4000 0x200>;
+			reg = <0xd4000 0x200>;
 			interrupts = <54>;
 			clocks = <&gateclk 17>;
 			status = "disabled";
 		};
 
-		usb at d0050000 {
+		usb at 50000 {
 			compatible = "marvell,orion-ehci";
-			reg = <0xd0050000 0x500>;
+			reg = <0x50000 0x500>;
 			interrupts = <45>;
 			status = "disabled";
 		};
 
-		usb at d0051000 {
+		usb at 51000 {
 			compatible = "marvell,orion-ehci";
-			reg = <0xd0051000 0x500>;
+			reg = <0x51000 0x500>;
 			interrupts = <46>;
 			status = "disabled";
 		};
 
-		spi0: spi at d0010600 {
+		spi0: spi at 10600 {
 			compatible = "marvell,orion-spi";
-			reg = <0xd0010600 0x28>;
+			reg = <0x10600 0x28>;
 			#address-cells = <1>;
 			#size-cells = <0>;
 			cell-index = <0>;
@@ -166,9 +167,9 @@
 			status = "disabled";
 		};
 
-		spi1: spi at d0010680 {
+		spi1: spi at 10680 {
 			compatible = "marvell,orion-spi";
-			reg = <0xd0010680 0x28>;
+			reg = <0x10680 0x28>;
 			#address-cells = <1>;
 			#size-cells = <0>;
 			cell-index = <1>;
@@ -177,45 +178,45 @@
 			status = "disabled";
 		};
 
-		devbus-bootcs at d0010400 {
+		devbus-bootcs at 10400 {
 			compatible = "marvell,mvebu-devbus";
-			reg = <0xd0010400 0x8>;
+			reg = <0x10400 0x8>;
 			#address-cells = <1>;
 			#size-cells = <1>;
 			clocks = <&coreclk 0>;
 			status = "disabled";
 		};
 
-		devbus-cs0 at d0010408 {
+		devbus-cs0 at 10408 {
 			compatible = "marvell,mvebu-devbus";
-			reg = <0xd0010408 0x8>;
+			reg = <0x10408 0x8>;
 			#address-cells = <1>;
 			#size-cells = <1>;
 			clocks = <&coreclk 0>;
 			status = "disabled";
 		};
 
-		devbus-cs1 at d0010410 {
+		devbus-cs1 at 10410 {
 			compatible = "marvell,mvebu-devbus";
-			reg = <0xd0010410 0x8>;
+			reg = <0x10410 0x8>;
 			#address-cells = <1>;
 			#size-cells = <1>;
 			clocks = <&coreclk 0>;
 			status = "disabled";
 		};
 
-		devbus-cs2 at d0010418 {
+		devbus-cs2 at 10418 {
 			compatible = "marvell,mvebu-devbus";
-			reg = <0xd0010418 0x8>;
+			reg = <0x10418 0x8>;
 			#address-cells = <1>;
 			#size-cells = <1>;
 			clocks = <&coreclk 0>;
 			status = "disabled";
 		};
 
-		devbus-cs3 at d0010420 {
+		devbus-cs3 at 10420 {
 			compatible = "marvell,mvebu-devbus";
-			reg = <0xd0010420 0x8>;
+			reg = <0x10420 0x8>;
 			#address-cells = <1>;
 			#size-cells = <1>;
 			clocks = <&coreclk 0>;
diff --git a/arch/arm/boot/dts/armada-370.dtsi b/arch/arm/boot/dts/armada-370.dtsi
index 209caeb..5c4fa65 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -28,14 +28,15 @@
 	};
 
 	soc {
-		mpic: interrupt-controller at d0020000 {
-			reg = <0xd0020a00 0x1d0>,
-			      <0xd0021870 0x58>;
+
+		mpic: interrupt-controller at 20000 {
+			reg = <0x20a00 0x1d0>,
+			      <0x21870 0x58>;
 		};
 
-		system-controller at d0018200 {
+		system-controller at 18200 {
 				compatible = "marvell,armada-370-xp-system-controller";
-				reg = <0xd0018200 0x100>;
+				reg = <0x18200 0x100>;
 		};
 
 		L2: l2-cache {
@@ -47,7 +48,7 @@
 
 		pinctrl {
 			compatible = "marvell,mv88f6710-pinctrl";
-			reg = <0xd0018000 0x38>;
+			reg = <0x18000 0x38>;
 
 			sdio_pins1: sdio-pins1 {
 			      marvell,pins = "mpp9",  "mpp11", "mpp12",
@@ -68,9 +69,9 @@
 			};
 	        };
 
-		gpio0: gpio at d0018100 {
+		gpio0: gpio at 18100 {
 			compatible = "marvell,orion-gpio";
-			reg = <0xd0018100 0x40>;
+			reg = <0x18100 0x40>;
 			ngpios = <32>;
 			gpio-controller;
 			#gpio-cells = <2>;
@@ -79,9 +80,9 @@
 			interrupts = <82>, <83>, <84>, <85>;
 		};
 
-		gpio1: gpio at d0018140 {
+		gpio1: gpio at 18140 {
 			compatible = "marvell,orion-gpio";
-			reg = <0xd0018140 0x40>;
+			reg = <0x18140 0x40>;
 			ngpios = <32>;
 			gpio-controller;
 			#gpio-cells = <2>;
@@ -90,9 +91,9 @@
 			interrupts = <87>, <88>, <89>, <90>;
 		};
 
-		gpio2: gpio at d0018180 {
+		gpio2: gpio at 18180 {
 			compatible = "marvell,orion-gpio";
-			reg = <0xd0018180 0x40>;
+			reg = <0x18180 0x40>;
 			ngpios = <2>;
 			gpio-controller;
 			#gpio-cells = <2>;
@@ -101,23 +102,23 @@
 			interrupts = <91>;
 		};
 
-		coreclk: mvebu-sar at d0018230 {
+		coreclk: mvebu-sar at 18230 {
 			compatible = "marvell,armada-370-core-clock";
-			reg = <0xd0018230 0x08>;
+			reg = <0x18230 0x08>;
 			#clock-cells = <1>;
 		};
 
-		gateclk: clock-gating-control at d0018220 {
+		gateclk: clock-gating-control at 18220 {
 			compatible = "marvell,armada-370-gating-clock";
-			reg = <0xd0018220 0x4>;
+			reg = <0x18220 0x4>;
 			clocks = <&coreclk 0>;
 			#clock-cells = <1>;
 		};
 
-		xor at d0060800 {
+		xor at 60800 {
 			compatible = "marvell,orion-xor";
-			reg = <0xd0060800 0x100
-			       0xd0060A00 0x100>;
+			reg = <0x60800 0x100
+			       0x60A00 0x100>;
 			status = "okay";
 
 			xor00 {
@@ -133,10 +134,10 @@
 			};
 		};
 
-		xor at d0060900 {
+		xor at 60900 {
 			compatible = "marvell,orion-xor";
-			reg = <0xd0060900 0x100
-			       0xd0060b00 0x100>;
+			reg = <0x60900 0x100
+			       0x60b00 0x100>;
 			status = "okay";
 
 			xor10 {
@@ -152,18 +153,18 @@
 			};
 		};
 
-		usb at d0050000 {
+		usb at 50000 {
 			clocks = <&coreclk 0>;
 		};
 
-		usb at d0051000 {
+		usb at 51000 {
 			clocks = <&coreclk 0>;
 		};
 
-		thermal at d0018300 {
+		thermal at 18300 {
 			compatible = "marvell,armada370-thermal";
-			reg = <0xd0018300 0x4
-			       0xd0018304 0x4>;
+			reg = <0x18300 0x4
+			       0x18304 0x4>;
 			status = "okay";
 		};
 
@@ -177,18 +178,18 @@
 
 			bus-range = <0x00 0xff>;
 
-			reg = <0xd0040000 0x2000>, <0xd0080000 0x2000>;
+			reg = <0x40000 0x2000>, <0x80000 0x2000>;
 
 			reg-names = "pcie0.0", "pcie1.0";
 
-			ranges = <0x82000000 0 0xd0040000 0xd0040000 0 0x00002000   /* Port 0.0 registers */
-				  0x82000000 0 0xd0080000 0xd0080000 0 0x00002000   /* Port 1.0 registers */
+			ranges = <0x82000000 0 0x40000 0x40000 0 0x00002000   /* Port 0.0 registers */
+				  0x82000000 0 0x80000 0x80000 0 0x00002000   /* Port 1.0 registers */
 				  0x82000000 0 0xe0000000 0xe0000000 0 0x08000000   /* non-prefetchable memory */
 			          0x81000000 0 0          0xe8000000 0 0x00100000>; /* downstream I/O */
 
 			pcie at 1,0 {
 				device_type = "pci";
-				assigned-addresses = <0x82000800 0 0xd0040000 0 0x2000>;
+				assigned-addresses = <0x82000800 0 0x40000 0 0x2000>;
 				reg = <0x0800 0 0 0 0>;
 				#address-cells = <3>;
 				#size-cells = <2>;
@@ -204,7 +205,7 @@
 
 			pcie at 2,0 {
 				device_type = "pci";
-				assigned-addresses = <0x82002800 0 0xd0080000 0 0x2000>;
+				assigned-addresses = <0x82002800 0 0x80000 0 0x2000>;
 				reg = <0x1000 0 0 0 0>;
 				#address-cells = <3>;
 				#size-cells = <2>;
diff --git a/arch/arm/boot/dts/armada-xp-db.dts b/arch/arm/boot/dts/armada-xp-db.dts
index 54cc5bb..e37863f 100644
--- a/arch/arm/boot/dts/armada-xp-db.dts
+++ b/arch/arm/boot/dts/armada-xp-db.dts
@@ -30,24 +30,24 @@
 	};
 
 	soc {
-		serial at d0012000 {
+		serial at 12000 {
 			clock-frequency = <250000000>;
 			status = "okay";
 		};
-		serial at d0012100 {
+		serial at 12100 {
 			clock-frequency = <250000000>;
 			status = "okay";
 		};
-		serial at d0012200 {
+		serial at 12200 {
 			clock-frequency = <250000000>;
 			status = "okay";
 		};
-		serial at d0012300 {
+		serial at 12300 {
 			clock-frequency = <250000000>;
 			status = "okay";
 		};
 
-		sata at d00a0000 {
+		sata at a0000 {
 			nr-ports = <2>;
 			status = "okay";
 		};
@@ -70,47 +70,47 @@
 			};
 		};
 
-		ethernet at d0070000 {
+		ethernet at 70000 {
 			status = "okay";
 			phy = <&phy0>;
 			phy-mode = "rgmii-id";
 		};
-		ethernet at d0074000 {
+		ethernet at 74000 {
 			status = "okay";
 			phy = <&phy1>;
 			phy-mode = "rgmii-id";
 		};
-		ethernet at d0030000 {
+		ethernet at 30000 {
 			status = "okay";
 			phy = <&phy2>;
 			phy-mode = "sgmii";
 		};
-		ethernet at d0034000 {
+		ethernet at 34000 {
 			status = "okay";
 			phy = <&phy3>;
 			phy-mode = "sgmii";
 		};
 
-		mvsdio at d00d4000 {
+		mvsdio at d4000 {
 			pinctrl-0 = <&sdio_pins>;
 			pinctrl-names = "default";
 			status = "okay";
 			/* No CD or WP GPIOs */
 		};
 
-		usb at d0050000 {
+		usb at 50000 {
 			status = "okay";
 		};
 
-		usb at d0051000 {
+		usb at 51000 {
 			status = "okay";
 		};
 
-		usb at d0052000 {
+		usb at 52000 {
 			status = "okay";
 		};
 
-		spi0: spi at d0010600 {
+		spi0: spi at 10600 {
 			status = "okay";
 
 			spi-flash at 0 {
diff --git a/arch/arm/boot/dts/armada-xp-gp.dts b/arch/arm/boot/dts/armada-xp-gp.dts
index 04f28a7..55bcbff 100644
--- a/arch/arm/boot/dts/armada-xp-gp.dts
+++ b/arch/arm/boot/dts/armada-xp-gp.dts
@@ -37,24 +37,24 @@
 	};
 
 	soc {
-		serial at d0012000 {
+		serial at 12000 {
 			clock-frequency = <250000000>;
 			status = "okay";
 		};
-		serial at d0012100 {
+		serial at 12100 {
 			clock-frequency = <250000000>;
 			status = "okay";
 		};
-		serial at d0012200 {
+		serial at 12200 {
 			clock-frequency = <250000000>;
 			status = "okay";
 		};
-		serial at d0012300 {
+		serial at 12300 {
 			clock-frequency = <250000000>;
 			status = "okay";
 		};
 
-		sata at d00a0000 {
+		sata at a0000 {
 			nr-ports = <2>;
 			status = "okay";
 		};
@@ -77,28 +77,28 @@
 			};
 		};
 
-		ethernet at d0070000 {
+		ethernet at 70000 {
 			status = "okay";
 			phy = <&phy0>;
 			phy-mode = "rgmii-id";
 		};
-		ethernet at d0074000 {
+		ethernet at 74000 {
 			status = "okay";
 			phy = <&phy1>;
 			phy-mode = "rgmii-id";
 		};
-		ethernet at d0030000 {
+		ethernet at 30000 {
 			status = "okay";
 			phy = <&phy2>;
 			phy-mode = "rgmii-id";
 		};
-		ethernet at d0034000 {
+		ethernet at 34000 {
 			status = "okay";
 			phy = <&phy3>;
 			phy-mode = "rgmii-id";
 		};
 
-		spi0: spi at d0010600 {
+		spi0: spi at 10600 {
 			status = "okay";
 
 			spi-flash at 0 {
@@ -110,7 +110,7 @@
 			};
 		};
 
-		devbus-bootcs at d0010400 {
+		devbus-bootcs at 10400 {
 			status = "okay";
 			ranges = <0 0xf0000000 0x1000000>; /* @addr 0xf000000, size 0x1000000 */
 
diff --git a/arch/arm/boot/dts/armada-xp-mv78230.dtsi b/arch/arm/boot/dts/armada-xp-mv78230.dtsi
index e072a53..12905ab 100644
--- a/arch/arm/boot/dts/armada-xp-mv78230.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78230.dtsi
@@ -46,7 +46,7 @@
 	soc {
 		pinctrl {
 			compatible = "marvell,mv78230-pinctrl";
-			reg = <0xd0018000 0x38>;
+			reg = <0x18000 0x38>;
 
 			sdio_pins: sdio-pins {
 				marvell,pins = "mpp30", "mpp31", "mpp32",
@@ -55,9 +55,9 @@
 			};
 		};
 
-		gpio0: gpio at d0018100 {
+		gpio0: gpio at 18100 {
 			compatible = "marvell,orion-gpio";
-			reg = <0xd0018100 0x40>;
+			reg = <0x18100 0x40>;
 			ngpios = <32>;
 			gpio-controller;
 			#gpio-cells = <2>;
@@ -66,9 +66,9 @@
 			interrupts = <82>, <83>, <84>, <85>;
 		};
 
-		gpio1: gpio at d0018140 {
+		gpio1: gpio at 18140 {
 			compatible = "marvell,orion-gpio";
-			reg = <0xd0018140 0x40>;
+			reg = <0x18140 0x40>;
 			ngpios = <17>;
 			gpio-controller;
 			#gpio-cells = <2>;
@@ -92,17 +92,17 @@
 
 			bus-range = <0x00 0xff>;
 
-			ranges = <0x82000000 0 0xd0040000 0xd0040000 0 0x00002000   /* Port 0.0 registers */
-				  0x82000000 0 0xd0042000 0xd0042000 0 0x00002000   /* Port 2.0 registers */
-				  0x82000000 0 0xd0044000 0xd0044000 0 0x00002000   /* Port 0.1 registers */
-				  0x82000000 0 0xd0048000 0xd0048000 0 0x00002000   /* Port 0.2 registers */
-				  0x82000000 0 0xd004c000 0xd004c000 0 0x00002000   /* Port 0.3 registers */
+			ranges = <0x82000000 0 0x40000 0x40000 0 0x00002000   /* Port 0.0 registers */
+				  0x82000000 0 0x42000 0x42000 0 0x00002000   /* Port 2.0 registers */
+				  0x82000000 0 0x44000 0x44000 0 0x00002000   /* Port 0.1 registers */
+				  0x82000000 0 0x48000 0x48000 0 0x00002000   /* Port 0.2 registers */
+				  0x82000000 0 0x4c000 0x4c000 0 0x00002000   /* Port 0.3 registers */
 				  0x82000000 0 0xe0000000 0xe0000000 0 0x08000000   /* non-prefetchable memory */
 				  0x81000000 0 0	  0xe8000000 0 0x00100000>; /* downstream I/O */
 
 			pcie at 1,0 {
 				device_type = "pci";
-				assigned-addresses = <0x82000800 0 0xd0040000 0 0x2000>;
+				assigned-addresses = <0x82000800 0 0x40000 0 0x2000>;
 				reg = <0x0800 0 0 0 0>;
 				#address-cells = <3>;
 				#size-cells = <2>;
@@ -118,7 +118,7 @@
 
 			pcie at 2,0 {
 				device_type = "pci";
-				assigned-addresses = <0x82000800 0 0xd0044000 0 0x2000>;
+				assigned-addresses = <0x82000800 0 0x44000 0 0x2000>;
 				reg = <0x1000 0 0 0 0>;
 				#address-cells = <3>;
 				#size-cells = <2>;
@@ -134,7 +134,7 @@
 
 			pcie at 3,0 {
 				device_type = "pci";
-				assigned-addresses = <0x82000800 0 0xd0048000 0 0x2000>;
+				assigned-addresses = <0x82000800 0 0x48000 0 0x2000>;
 				reg = <0x1800 0 0 0 0>;
 				#address-cells = <3>;
 				#size-cells = <2>;
@@ -150,7 +150,7 @@
 
 			pcie at 4,0 {
 				device_type = "pci";
-				assigned-addresses = <0x82000800 0 0xd004c000 0 0x2000>;
+				assigned-addresses = <0x82000800 0 0x4c000 0 0x2000>;
 				reg = <0x2000 0 0 0 0>;
 				#address-cells = <3>;
 				#size-cells = <2>;
@@ -166,7 +166,7 @@
 
 			pcie at 9,0 {
 				device_type = "pci";
-				assigned-addresses = <0x82000800 0 0xd0042000 0 0x2000>;
+				assigned-addresses = <0x82000800 0 0x42000 0 0x2000>;
 				reg = <0x4800 0 0 0 0>;
 				#address-cells = <3>;
 				#size-cells = <2>;
diff --git a/arch/arm/boot/dts/armada-xp-mv78260.dtsi b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
index 6dae1bc..1faacd1 100644
--- a/arch/arm/boot/dts/armada-xp-mv78260.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
@@ -47,7 +47,7 @@
 	soc {
 		pinctrl {
 			compatible = "marvell,mv78260-pinctrl";
-			reg = <0xd0018000 0x38>;
+			reg = <0x18000 0x38>;
 
 			sdio_pins: sdio-pins {
 				marvell,pins = "mpp30", "mpp31", "mpp32",
@@ -56,9 +56,9 @@
 			};
 		};
 
-		gpio0: gpio at d0018100 {
+		gpio0: gpio at 18100 {
 			compatible = "marvell,orion-gpio";
-			reg = <0xd0018100 0x40>;
+			reg = <0x18100 0x40>;
 			ngpios = <32>;
 			gpio-controller;
 			#gpio-cells = <2>;
@@ -67,9 +67,9 @@
 			interrupts = <82>, <83>, <84>, <85>;
 		};
 
-		gpio1: gpio at d0018140 {
+		gpio1: gpio at 18140 {
 			compatible = "marvell,orion-gpio";
-			reg = <0xd0018140 0x40>;
+			reg = <0x18140 0x40>;
 			ngpios = <32>;
 			gpio-controller;
 			#gpio-cells = <2>;
@@ -78,9 +78,9 @@
 			interrupts = <87>, <88>, <89>, <90>;
 		};
 
-		gpio2: gpio at d0018180 {
+		gpio2: gpio at 18180 {
 			compatible = "marvell,orion-gpio";
-			reg = <0xd0018180 0x40>;
+			reg = <0x18180 0x40>;
 			ngpios = <3>;
 			gpio-controller;
 			#gpio-cells = <2>;
@@ -89,9 +89,9 @@
 			interrupts = <91>;
 		};
 
-		ethernet at d0034000 {
+		ethernet at 34000 {
 				compatible = "marvell,armada-370-neta";
-				reg = <0xd0034000 0x2500>;
+				reg = <0x34000 0x2500>;
 				interrupts = <14>;
 				clocks = <&gateclk 1>;
 				status = "disabled";
@@ -112,19 +112,19 @@
 
 			bus-range = <0x00 0xff>;
 
-			ranges = <0x82000000 0 0xd0040000 0xd0040000 0 0x00002000   /* Port 0.0 registers */
-				  0x82000000 0 0xd0042000 0xd0042000 0 0x00002000   /* Port 2.0 registers */
-				  0x82000000 0 0xd0044000 0xd0044000 0 0x00002000   /* Port 0.1 registers */
-				  0x82000000 0 0xd0048000 0xd0048000 0 0x00002000   /* Port 0.2 registers */
-				  0x82000000 0 0xd004c000 0xd004c000 0 0x00002000   /* Port 0.3 registers */
-				  0x82000000 0 0xd0080000 0xd0080000 0 0x00002000   /* Port 1.0 registers */
-				  0x82000000 0 0xd0082000 0xd0082000 0 0x00002000   /* Port 3.0 registers */
+			ranges = <0x82000000 0 0x40000 0x40000 0 0x00002000   /* Port 0.0 registers */
+				  0x82000000 0 0x42000 0x42000 0 0x00002000   /* Port 2.0 registers */
+				  0x82000000 0 0x44000 0x44000 0 0x00002000   /* Port 0.1 registers */
+				  0x82000000 0 0x48000 0x48000 0 0x00002000   /* Port 0.2 registers */
+				  0x82000000 0 0x4c000 0x4c000 0 0x00002000   /* Port 0.3 registers */
+				  0x82000000 0 0x80000 0x80000 0 0x00002000   /* Port 1.0 registers */
+				  0x82000000 0 0x82000 0x82000 0 0x00002000   /* Port 3.0 registers */
 				  0x82000000 0 0xe0000000 0xe0000000 0 0x08000000   /* non-prefetchable memory */
 				  0x81000000 0 0	  0xe8000000 0 0x00100000>; /* downstream I/O */
 
 			pcie at 1,0 {
 				device_type = "pci";
-				assigned-addresses = <0x82000800 0 0xd0040000 0 0x2000>;
+				assigned-addresses = <0x82000800 0 0x40000 0 0x2000>;
 				reg = <0x0800 0 0 0 0>;
 				#address-cells = <3>;
 				#size-cells = <2>;
@@ -140,7 +140,7 @@
 
 			pcie at 2,0 {
 				device_type = "pci";
-				assigned-addresses = <0x82000800 0 0xd0044000 0 0x2000>;
+				assigned-addresses = <0x82000800 0 0x44000 0 0x2000>;
 				reg = <0x1000 0 0 0 0>;
 				#address-cells = <3>;
 				#size-cells = <2>;
@@ -156,7 +156,7 @@
 
 			pcie at 3,0 {
 				device_type = "pci";
-				assigned-addresses = <0x82000800 0 0xd0048000 0 0x2000>;
+				assigned-addresses = <0x82000800 0 0x48000 0 0x2000>;
 				reg = <0x1800 0 0 0 0>;
 				#address-cells = <3>;
 				#size-cells = <2>;
@@ -172,7 +172,7 @@
 
 			pcie at 4,0 {
 				device_type = "pci";
-				assigned-addresses = <0x82000800 0 0xd004c000 0 0x2000>;
+				assigned-addresses = <0x82000800 0 0x4c000 0 0x2000>;
 				reg = <0x2000 0 0 0 0>;
 				#address-cells = <3>;
 				#size-cells = <2>;
@@ -188,7 +188,7 @@
 
 			pcie at 9,0 {
 				device_type = "pci";
-				assigned-addresses = <0x82000800 0 0xd0042000 0 0x2000>;
+				assigned-addresses = <0x82000800 0 0x42000 0 0x2000>;
 				reg = <0x4800 0 0 0 0>;
 				#address-cells = <3>;
 				#size-cells = <2>;
@@ -204,7 +204,7 @@
 
 			pcie at 10,0 {
 				device_type = "pci";
-				assigned-addresses = <0x82000800 0 0xd0082000 0 0x2000>;
+				assigned-addresses = <0x82000800 0 0x82000 0 0x2000>;
 				reg = <0x5000 0 0 0 0>;
 				#address-cells = <3>;
 				#size-cells = <2>;
diff --git a/arch/arm/boot/dts/armada-xp-mv78460.dtsi b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
index b9da5b8..ce4f80a 100644
--- a/arch/arm/boot/dts/armada-xp-mv78460.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
@@ -62,7 +62,7 @@
 	soc {
 		pinctrl {
 			compatible = "marvell,mv78460-pinctrl";
-			reg = <0xd0018000 0x38>;
+			reg = <0x18000 0x38>;
 
 			sdio_pins: sdio-pins {
 				marvell,pins = "mpp30", "mpp31", "mpp32",
@@ -71,9 +71,9 @@
 			};
 		};
 
-		gpio0: gpio at d0018100 {
+		gpio0: gpio at 18100 {
 			compatible = "marvell,orion-gpio";
-			reg = <0xd0018100 0x40>;
+			reg = <0x18100 0x40>;
 			ngpios = <32>;
 			gpio-controller;
 			#gpio-cells = <2>;
@@ -82,9 +82,9 @@
 			interrupts = <82>, <83>, <84>, <85>;
 		};
 
-		gpio1: gpio at d0018140 {
+		gpio1: gpio at 18140 {
 			compatible = "marvell,orion-gpio";
-			reg = <0xd0018140 0x40>;
+			reg = <0x18140 0x40>;
 			ngpios = <32>;
 			gpio-controller;
 			#gpio-cells = <2>;
@@ -93,9 +93,9 @@
 			interrupts = <87>, <88>, <89>, <90>;
 		};
 
-		gpio2: gpio at d0018180 {
+		gpio2: gpio at 18180 {
 			compatible = "marvell,orion-gpio";
-			reg = <0xd0018180 0x40>;
+			reg = <0x18180 0x40>;
 			ngpios = <3>;
 			gpio-controller;
 			#gpio-cells = <2>;
@@ -104,9 +104,9 @@
 			interrupts = <91>;
 		};
 
-		ethernet at d0034000 {
+		ethernet at 34000 {
 				compatible = "marvell,armada-370-neta";
-				reg = <0xd0034000 0x2500>;
+				reg = <0x34000 0x2500>;
 				interrupts = <14>;
 				clocks = <&gateclk 1>;
 				status = "disabled";
@@ -127,22 +127,22 @@
 
 			bus-range = <0x00 0xff>;
 
-			ranges = <0x82000000 0 0xd0040000 0xd0040000 0 0x00002000   /* Port 0.0 registers */
-				  0x82000000 0 0xd0042000 0xd0042000 0 0x00002000   /* Port 2.0 registers */
-				  0x82000000 0 0xd0044000 0xd0044000 0 0x00002000   /* Port 0.1 registers */
-				  0x82000000 0 0xd0048000 0xd0048000 0 0x00002000   /* Port 0.2 registers */
-				  0x82000000 0 0xd004c000 0xd004c000 0 0x00002000   /* Port 0.3 registers */
-				  0x82000000 0 0xd0080000 0xd0080000 0 0x00002000   /* Port 1.0 registers */
-				  0x82000000 0 0xd0082000 0xd0082000 0 0x00002000   /* Port 3.0 registers */
-				  0x82000000 0 0xd0084000 0xd0084000 0 0x00002000   /* Port 1.1 registers */
-				  0x82000000 0 0xd0088000 0xd0088000 0 0x00002000   /* Port 1.2 registers */
-				  0x82000000 0 0xd008c000 0xd008c000 0 0x00002000   /* Port 1.3 registers */
+			ranges = <0x82000000 0 0x40000 0x40000 0 0x00002000   /* Port 0.0 registers */
+				  0x82000000 0 0x42000 0x42000 0 0x00002000   /* Port 2.0 registers */
+				  0x82000000 0 0x44000 0x44000 0 0x00002000   /* Port 0.1 registers */
+				  0x82000000 0 0x48000 0x48000 0 0x00002000   /* Port 0.2 registers */
+				  0x82000000 0 0x4c000 0x4c000 0 0x00002000   /* Port 0.3 registers */
+				  0x82000000 0 0x80000 0x80000 0 0x00002000   /* Port 1.0 registers */
+				  0x82000000 0 0x82000 0x82000 0 0x00002000   /* Port 3.0 registers */
+				  0x82000000 0 0x84000 0x84000 0 0x00002000   /* Port 1.1 registers */
+				  0x82000000 0 0x88000 0x88000 0 0x00002000   /* Port 1.2 registers */
+				  0x82000000 0 0x8c000 0x8c000 0 0x00002000   /* Port 1.3 registers */
 				  0x82000000 0 0xe0000000 0xe0000000 0 0x08000000   /* non-prefetchable memory */
 				  0x81000000 0 0	  0xe8000000 0 0x00100000>; /* downstream I/O */
 
 			pcie at 1,0 {
 				device_type = "pci";
-				assigned-addresses = <0x82000800 0 0xd0040000 0 0x2000>;
+				assigned-addresses = <0x82000800 0 0x40000 0 0x2000>;
 				reg = <0x0800 0 0 0 0>;
 				#address-cells = <3>;
 				#size-cells = <2>;
@@ -158,7 +158,7 @@
 
 			pcie at 2,0 {
 				device_type = "pci";
-				assigned-addresses = <0x82001000 0 0xd0044000 0 0x2000>;
+				assigned-addresses = <0x82001000 0 0x44000 0 0x2000>;
 				reg = <0x1000 0 0 0 0>;
 				#address-cells = <3>;
 				#size-cells = <2>;
@@ -174,7 +174,7 @@
 
 			pcie at 3,0 {
 				device_type = "pci";
-				assigned-addresses = <0x82001800 0 0xd0048000 0 0x2000>;
+				assigned-addresses = <0x82001800 0 0x48000 0 0x2000>;
 				reg = <0x1800 0 0 0 0>;
 				#address-cells = <3>;
 				#size-cells = <2>;
@@ -190,7 +190,7 @@
 
 			pcie at 4,0 {
 				device_type = "pci";
-				assigned-addresses = <0x82002000 0 0xd004c000 0 0x2000>;
+				assigned-addresses = <0x82002000 0 0x4c000 0 0x2000>;
 				reg = <0x2000 0 0 0 0>;
 				#address-cells = <3>;
 				#size-cells = <2>;
@@ -206,7 +206,7 @@
 
 			pcie at 5,0 {
 				device_type = "pci";
-				assigned-addresses = <0x82002800 0 0xd0080000 0 0x2000>;
+				assigned-addresses = <0x82002800 0 0x80000 0 0x2000>;
 				reg = <0x2800 0 0 0 0>;
 				#address-cells = <3>;
 				#size-cells = <2>;
@@ -222,7 +222,7 @@
 
 			pcie at 6,0 {
 				device_type = "pci";
-				assigned-addresses = <0x82003000 0 0xd0084000 0 0x2000>;
+				assigned-addresses = <0x82003000 0 0x84000 0 0x2000>;
 				reg = <0x3000 0 0 0 0>;
 				#address-cells = <3>;
 				#size-cells = <2>;
@@ -238,7 +238,7 @@
 
 			pcie at 7,0 {
 				device_type = "pci";
-				assigned-addresses = <0x82003800 0 0xd0088000 0 0x2000>;
+				assigned-addresses = <0x82003800 0 0x88000 0 0x2000>;
 				reg = <0x3800 0 0 0 0>;
 				#address-cells = <3>;
 				#size-cells = <2>;
@@ -254,7 +254,7 @@
 
 			pcie at 8,0 {
 				device_type = "pci";
-				assigned-addresses = <0x82004000 0 0xd008c000 0 0x2000>;
+				assigned-addresses = <0x82004000 0 0x8c000 0 0x2000>;
 				reg = <0x4000 0 0 0 0>;
 				#address-cells = <3>;
 				#size-cells = <2>;
@@ -269,7 +269,7 @@
 			};
 			pcie at 9,0 {
 				device_type = "pci";
-				assigned-addresses = <0x82004800 0 0xd0042000 0 0x2000>;
+				assigned-addresses = <0x82004800 0 0x42000 0 0x2000>;
 				reg = <0x4800 0 0 0 0>;
 				#address-cells = <3>;
 				#size-cells = <2>;
@@ -285,7 +285,7 @@
 
 			pcie at 10,0 {
 				device_type = "pci";
-				assigned-addresses = <0x82005000 0 0xd0082000 0 0x2000>;
+				assigned-addresses = <0x82005000 0 0x82000 0 0x2000>;
 				reg = <0x5000 0 0 0 0>;
 				#address-cells = <3>;
 				#size-cells = <2>;
diff --git a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
index 9d04f04..e9bc8bf 100644
--- a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
+++ b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
@@ -27,11 +27,11 @@
 	};
 
 	soc {
-		serial at d0012000 {
+		serial at 12000 {
 			clock-frequency = <250000000>;
 			status = "okay";
 		};
-		serial at d0012100 {
+		serial at 12100 {
 			clock-frequency = <250000000>;
 			status = "okay";
 		};
@@ -96,31 +96,31 @@
 			};
 		};
 
-		ethernet at d0070000 {
+		ethernet at 70000 {
 			status = "okay";
 			phy = <&phy0>;
 			phy-mode = "sgmii";
 		};
-		ethernet at d0074000 {
+		ethernet at 74000 {
 			status = "okay";
 			phy = <&phy1>;
 			phy-mode = "sgmii";
 		};
-		ethernet at d0030000 {
+		ethernet at 30000 {
 			status = "okay";
 			phy = <&phy2>;
 			phy-mode = "sgmii";
 		};
-		ethernet at d0034000 {
+		ethernet at 34000 {
 			status = "okay";
 			phy = <&phy3>;
 			phy-mode = "sgmii";
 		};
-		i2c at d0011000 {
+		i2c at 11000 {
 			status = "okay";
 			clock-frequency = <400000>;
 		};
-		i2c at d0011100 {
+		i2c at 11100 {
 			status = "okay";
 			clock-frequency = <400000>;
 
@@ -129,18 +129,18 @@
 				reg = <0x30>;
 			};
 		};
-		sata at d00a0000 {
+		sata at a0000 {
 			nr-ports = <2>;
 			status = "okay";
 		};
-		usb at d0050000 {
+		usb at 50000 {
 			status = "okay";
 		};
-		usb at d0051000 {
+		usb at 51000 {
 			status = "okay";
 		};
 
-		devbus-bootcs at d0010400 {
+		devbus-bootcs at 10400 {
 			status = "okay";
 			ranges = <0 0xf0000000 0x8000000>; /* @addr 0xf000000, size 0x8000000 */
 
diff --git a/arch/arm/boot/dts/armada-xp.dtsi b/arch/arm/boot/dts/armada-xp.dtsi
index ef3d413..465b9fa 100644
--- a/arch/arm/boot/dts/armada-xp.dtsi
+++ b/arch/arm/boot/dts/armada-xp.dtsi
@@ -22,83 +22,84 @@
 	model = "Marvell Armada XP family SoC";
 	compatible = "marvell,armadaxp", "marvell,armada-370-xp";
 
+
 	soc {
 		L2: l2-cache {
 			compatible = "marvell,aurora-system-cache";
-			reg = <0xd0008000 0x1000>;
+			reg = <0x08000 0x1000>;
 			cache-id-part = <0x100>;
 			wt-override;
 		};
 
-		mpic: interrupt-controller at d0020000 {
-		      reg = <0xd0020a00 0x2d0>,
-			    <0xd0021070 0x58>;
+		mpic: interrupt-controller at 20000 {
+		      reg = <0x20a00 0x2d0>,
+			    <0x21070 0x58>;
 		};
 
-		armada-370-xp-pmsu at d0022000 {
+		armada-370-xp-pmsu at 22000 {
 			compatible = "marvell,armada-370-xp-pmsu";
-			reg = <0xd0022100 0x430>,
-			      <0xd0020800 0x20>;
+			reg = <0x22100 0x430>,
+			      <0x20800 0x20>;
 		};
 
-		serial at d0012200 {
+		serial at 12200 {
 				compatible = "snps,dw-apb-uart";
-				reg = <0xd0012200 0x100>;
+				reg = <0x12200 0x100>;
 				reg-shift = <2>;
 				interrupts = <43>;
 				reg-io-width = <1>;
 				status = "disabled";
 		};
-		serial at d0012300 {
+		serial at 12300 {
 				compatible = "snps,dw-apb-uart";
-				reg = <0xd0012300 0x100>;
+				reg = <0x12300 0x100>;
 				reg-shift = <2>;
 				interrupts = <44>;
 				reg-io-width = <1>;
 				status = "disabled";
 		};
 
-		timer at d0020300 {
+		timer at 20300 {
 				marvell,timer-25Mhz;
 		};
 
-		coreclk: mvebu-sar at d0018230 {
+		coreclk: mvebu-sar at 18230 {
 			compatible = "marvell,armada-xp-core-clock";
-			reg = <0xd0018230 0x08>;
+			reg = <0x18230 0x08>;
 			#clock-cells = <1>;
 		};
 
-		cpuclk: clock-complex at d0018700 {
+		cpuclk: clock-complex at 18700 {
 			#clock-cells = <1>;
 			compatible = "marvell,armada-xp-cpu-clock";
-			reg = <0xd0018700 0xA0>;
+			reg = <0x18700 0xA0>;
 			clocks = <&coreclk 1>;
 		};
 
-		gateclk: clock-gating-control at d0018220 {
+		gateclk: clock-gating-control at 18220 {
 			compatible = "marvell,armada-xp-gating-clock";
-			reg = <0xd0018220 0x4>;
+			reg = <0x18220 0x4>;
 			clocks = <&coreclk 0>;
 			#clock-cells = <1>;
 		};
 
-		system-controller at d0018200 {
+		system-controller at 18200 {
 				compatible = "marvell,armada-370-xp-system-controller";
-				reg = <0xd0018200 0x500>;
+				reg = <0x18200 0x500>;
 		};
 
-		ethernet at d0030000 {
+		ethernet at 30000 {
 				compatible = "marvell,armada-370-neta";
-				reg = <0xd0030000 0x2500>;
+				reg = <0x30000 0x2500>;
 				interrupts = <12>;
 				clocks = <&gateclk 2>;
 				status = "disabled";
 		};
 
-		xor at d0060900 {
+		xor at 60900 {
 			compatible = "marvell,orion-xor";
-			reg = <0xd0060900 0x100
-			       0xd0060b00 0x100>;
+			reg = <0x60900 0x100
+			       0x60b00 0x100>;
 			clocks = <&gateclk 22>;
 			status = "okay";
 
@@ -115,10 +116,10 @@
 			};
 		};
 
-		xor at d00f0900 {
+		xor at f0900 {
 			compatible = "marvell,orion-xor";
-			reg = <0xd00F0900 0x100
-			       0xd00F0B00 0x100>;
+			reg = <0xF0900 0x100
+			       0xF0B00 0x100>;
 			clocks = <&gateclk 28>;
 			status = "okay";
 
@@ -135,26 +136,26 @@
 			};
 		};
 
-		usb at d0050000 {
+		usb at 50000 {
 			clocks = <&gateclk 18>;
 		};
 
-		usb at d0051000 {
+		usb at 51000 {
 			clocks = <&gateclk 19>;
 		};
 
-		usb at d0052000 {
+		usb at 52000 {
 			compatible = "marvell,orion-ehci";
-			reg = <0xd0052000 0x500>;
+			reg = <0x52000 0x500>;
 			interrupts = <47>;
 			clocks = <&gateclk 20>;
 			status = "disabled";
 		};
 
-		thermal at d00182b0 {
+		thermal at 182b0 {
 			compatible = "marvell,armadaxp-thermal";
-			reg = <0xd00182b0 0x4
-			       0xd00184d0 0x4>;
+			reg = <0x182b0 0x4
+			       0x184d0 0x4>;
 			status = "okay";
 		};
 	};
-- 
1.7.9.5



From gregory.clement at free-electrons.com  Fri Apr 12 10:29:10 2013
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Fri, 12 Apr 2013 16:29:10 +0200
Subject: [PATCH v4 5/5] ARM: dts: mvebu: Convert mvebu device tree files to 64
 bits
In-Reply-To: <1365776950-30094-1-git-send-email-gregory.clement@free-electrons.com>
References: <1365776950-30094-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1365776950-30094-6-git-send-email-gregory.clement@free-electrons.com>

In order to be able to use more than 4GB of RAM when the LPAE is
activated, the dts must be converted in 64 bits.

Only Armada XP is LPAE capable, but as it shares a common dtsi file
with Armada 370, then the common file include the skeleton64. Thanks
to the use of the overload capability of the device tree format,
armada-370 include the 32 bit skeleton and all the armada 370 based
dts can remain the same.

This was heavily based on the work of Lior Amsalem.

Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
---
 arch/arm/boot/dts/armada-370-xp.dtsi             |    4 ++--
 arch/arm/boot/dts/armada-370.dtsi                |    2 ++
 arch/arm/boot/dts/armada-xp-db.dts               |    2 +-
 arch/arm/boot/dts/armada-xp-gp.dts               |   14 ++++++++------
 arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts |    2 +-
 5 files changed, 14 insertions(+), 10 deletions(-)

diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi b/arch/arm/boot/dts/armada-370-xp.dtsi
index bf8f911..272bbc6 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -16,7 +16,7 @@
  * 370 and Armada XP SoC.
  */
 
-/include/ "skeleton.dtsi"
+/include/ "skeleton64.dtsi"
 
 / {
 	model = "Marvell Armada 370 and XP SoC";
@@ -33,7 +33,7 @@
 		#size-cells = <1>;
 		compatible = "simple-bus";
 		interrupt-parent = <&mpic>;
-		ranges = <0 0xd0000000 0x100000>;
+		ranges = <0 0 0xd0000000 0x100000>;
 
 		internal-regs {
 			compatible = "simple-bus";
diff --git a/arch/arm/boot/dts/armada-370.dtsi b/arch/arm/boot/dts/armada-370.dtsi
index 6ef95dd..b2c1b5a 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -16,6 +16,7 @@
  */
 
 /include/ "armada-370-xp.dtsi"
+/include/ "skeleton.dtsi"
 
 / {
 	model = "Marvell Armada 370 family SoC";
@@ -28,6 +29,7 @@
 	};
 
 	soc {
+		ranges = <0 0xd0000000 0x100000>;
 		internal-regs {
 			system-controller at 18200 {
 				compatible = "marvell,armada-370-xp-system-controller";
diff --git a/arch/arm/boot/dts/armada-xp-db.dts b/arch/arm/boot/dts/armada-xp-db.dts
index 6c8b032..d6cc8bf 100644
--- a/arch/arm/boot/dts/armada-xp-db.dts
+++ b/arch/arm/boot/dts/armada-xp-db.dts
@@ -26,7 +26,7 @@
 
 	memory {
 		device_type = "memory";
-		reg = <0x00000000 0x80000000>; /* 2 GB */
+		reg = <0 0x00000000 0 0x80000000>; /* 2 GB */
 	};
 
 	soc {
diff --git a/arch/arm/boot/dts/armada-xp-gp.dts b/arch/arm/boot/dts/armada-xp-gp.dts
index d9972c9..26ad06f 100644
--- a/arch/arm/boot/dts/armada-xp-gp.dts
+++ b/arch/arm/boot/dts/armada-xp-gp.dts
@@ -26,14 +26,16 @@
 
 	memory {
 		device_type = "memory";
-
 		/*
-		 * 4 GB of plug-in RAM modules by default but only 3GB
-		 * are visible, the amount of memory available can be
-		 * changed by the bootloader according the size of the
-		 * module actually plugged
+                 * 8 GB of plug-in RAM modules by default.The amount
+                 * of memory available can be changed by the
+                 * bootloader according the size of the module
+                 * actually plugged. Only 7GB are usable because
+                 * addresses from 0xC0000000 to 0xffffffff are used by
+                 * the internal registers of the SoC.
 		 */
-		reg = <0x00000000 0xC0000000>;
+		reg = <0x00000000 0x00000000 0x00000000 0xC0000000>,
+		      <0x00000001 0x00000000 0x00000001 0x00000000>;
 	};
 
 	soc {
diff --git a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
index 15a66a8..f14d36c 100644
--- a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
+++ b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
@@ -23,7 +23,7 @@
 
 	memory {
 		device_type = "memory";
-		reg = <0x00000000 0xC0000000>; /* 3 GB */
+		reg = <0 0x00000000 0 0xC0000000>; /* 3 GB */
 	};
 
 	soc {
-- 
1.7.9.5



From gregory.clement at free-electrons.com  Fri Apr 12 10:29:09 2013
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Fri, 12 Apr 2013 16:29:09 +0200
Subject: [PATCH v4 4/5] ARM: dts: mvebu: introduce internal-regs node
In-Reply-To: <1365776950-30094-1-git-send-email-gregory.clement@free-electrons.com>
References: <1365776950-30094-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1365776950-30094-5-git-send-email-gregory.clement@free-electrons.com>

Introduce a 'internal-regs' subnode, under which all devices are
moved. This is not really needed for now, but will be for the
mvebu-mbus driver. This generates a lot of code movement since it's
indenting by one more tab all the devices.  So it was a good
opportunity to fix all the bad indentation.

Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
---
 arch/arm/boot/dts/armada-370-db.dts              |  134 +++----
 arch/arm/boot/dts/armada-370-mirabox.dts         |  176 ++++-----
 arch/arm/boot/dts/armada-370-rd.dts              |   96 ++---
 arch/arm/boot/dts/armada-370-xp.dtsi             |  301 +++++++--------
 arch/arm/boot/dts/armada-370.dtsi                |  328 ++++++++---------
 arch/arm/boot/dts/armada-xp-db.dts               |  200 +++++-----
 arch/arm/boot/dts/armada-xp-gp.dts               |  208 +++++------
 arch/arm/boot/dts/armada-xp-mv78230.dtsi         |  252 ++++++-------
 arch/arm/boot/dts/armada-xp-mv78260.dtsi         |  308 ++++++++--------
 arch/arm/boot/dts/armada-xp-mv78460.dtsi         |  428 +++++++++++-----------
 arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts |  260 ++++++-------
 arch/arm/boot/dts/armada-xp.dtsi                 |  193 +++++-----
 12 files changed, 1452 insertions(+), 1432 deletions(-)

diff --git a/arch/arm/boot/dts/armada-370-db.dts b/arch/arm/boot/dts/armada-370-db.dts
index e766f8b..2353b1f 100644
--- a/arch/arm/boot/dts/armada-370-db.dts
+++ b/arch/arm/boot/dts/armada-370-db.dts
@@ -30,85 +30,87 @@
 	};
 
 	soc {
-		serial at 12000 {
-			clock-frequency = <200000000>;
-			status = "okay";
-		};
-		sata at a0000 {
-			nr-ports = <2>;
-			status = "okay";
-		};
-
-		mdio {
-			phy0: ethernet-phy at 0 {
-				reg = <0>;
+		internal-regs {
+			serial at 12000 {
+				clock-frequency = <200000000>;
+				status = "okay";
 			};
-
-			phy1: ethernet-phy at 1 {
-				reg = <1>;
+			sata at a0000 {
+				nr-ports = <2>;
+				status = "okay";
 			};
-		};
 
-		ethernet at 70000 {
-			status = "okay";
-			phy = <&phy0>;
-			phy-mode = "rgmii-id";
-		};
-		ethernet at 74000 {
-			status = "okay";
-			phy = <&phy1>;
-			phy-mode = "rgmii-id";
-		};
+			mdio {
+				phy0: ethernet-phy at 0 {
+					reg = <0>;
+				};
 
-		mvsdio at d4000 {
-			pinctrl-0 = <&sdio_pins1>;
-			pinctrl-names = "default";
-			/*
-			 * This device is disabled by default, because
-			 * using the SD card connector requires
-			 * changing the default CON40 connector
-			 * "DB-88F6710_MPP_2xRGMII_DEVICE_Jumper" to a
-			 * different connector
-			 * "DB-88F6710_MPP_RGMII_SD_Jumper".
-			 */
-			status = "disabled";
-			/* No CD or WP GPIOs */
-		};
+				phy1: ethernet-phy at 1 {
+					reg = <1>;
+				};
+			};
 
-		usb at 50000 {
-			status = "okay";
-		};
+			ethernet at 70000 {
+				status = "okay";
+				phy = <&phy0>;
+				phy-mode = "rgmii-id";
+			};
+			ethernet at 74000 {
+				status = "okay";
+				phy = <&phy1>;
+				phy-mode = "rgmii-id";
+			};
 
-		usb at 51000 {
-			status = "okay";
-		};
+			mvsdio at d4000 {
+				pinctrl-0 = <&sdio_pins1>;
+				pinctrl-names = "default";
+				/*
+				 * This device is disabled by default, because
+				 * using the SD card connector requires
+				 * changing the default CON40 connector
+				 * "DB-88F6710_MPP_2xRGMII_DEVICE_Jumper" to a
+				 * different connector
+				 * "DB-88F6710_MPP_RGMII_SD_Jumper".
+				 */
+				status = "disabled";
+				/* No CD or WP GPIOs */
+			};
 
-		spi0: spi at 10600 {
-			status = "okay";
+			usb at 50000 {
+				status = "okay";
+			};
 
-			spi-flash at 0 {
-				#address-cells = <1>;
-				#size-cells = <1>;
-				compatible = "mx25l25635e";
-				reg = <0>; /* Chip select 0 */
-				spi-max-frequency = <50000000>;
+			usb at 51000 {
+				status = "okay";
 			};
-		};
 
-		pcie-controller {
-			status = "okay";
-			/*
-			 * The two PCIe units are accessible through
-			 * both standard PCIe slots and mini-PCIe
-			 * slots on the board.
-			 */
-			pcie at 1,0 {
-				/* Port 0, Lane 0 */
+			spi0: spi at 10600 {
 				status = "okay";
+
+				spi-flash at 0 {
+					#address-cells = <1>;
+					#size-cells = <1>;
+					compatible = "mx25l25635e";
+					reg = <0>; /* Chip select 0 */
+					spi-max-frequency = <50000000>;
+				};
 			};
-			pcie at 2,0 {
-				/* Port 1, Lane 0 */
+
+			pcie-controller {
 				status = "okay";
+				/*
+				 * The two PCIe units are accessible through
+				 * both standard PCIe slots and mini-PCIe
+				 * slots on the board.
+				 */
+				pcie at 1,0 {
+					/* Port 0, Lane 0 */
+					status = "okay";
+				};
+				pcie at 2,0 {
+					/* Port 1, Lane 0 */
+					status = "okay";
+				};
 			};
 		};
 	};
diff --git a/arch/arm/boot/dts/armada-370-mirabox.dts b/arch/arm/boot/dts/armada-370-mirabox.dts
index 6530ae3..14e36e1 100644
--- a/arch/arm/boot/dts/armada-370-mirabox.dts
+++ b/arch/arm/boot/dts/armada-370-mirabox.dts
@@ -25,113 +25,115 @@
 	};
 
 	soc {
-		serial at 12000 {
-			clock-frequency = <200000000>;
-			status = "okay";
-		};
-		timer at 20300 {
-			clock-frequency = <600000000>;
-			status = "okay";
-		};
-
-		pinctrl {
-			pwr_led_pin: pwr-led-pin {
-				marvell,pins = "mpp63";
-				marvell,function = "gpo";
+		internal-regs {
+			serial at 12000 {
+				clock-frequency = <200000000>;
+				status = "okay";
 			};
-
-			stat_led_pins: stat-led-pins {
-				marvell,pins = "mpp64", "mpp65";
-				marvell,function = "gpio";
+			timer at 20300 {
+				clock-frequency = <600000000>;
+				status = "okay";
 			};
-		};
 
-		gpio_leds {
-			compatible = "gpio-leds";
-			pinctrl-names = "default";
-			pinctrl-0 = <&pwr_led_pin &stat_led_pins>;
+			pinctrl {
+				pwr_led_pin: pwr-led-pin {
+					marvell,pins = "mpp63";
+					marvell,function = "gpo";
+				};
 
-			green_pwr_led {
-				label = "mirabox:green:pwr";
-				gpios = <&gpio1 31 1>;
-				linux,default-trigger = "heartbeat";
+				stat_led_pins: stat-led-pins {
+					marvell,pins = "mpp64", "mpp65";
+					marvell,function = "gpio";
+				};
 			};
 
-			blue_stat_led {
-				label = "mirabox:blue:stat";
-				gpios = <&gpio2 0 1>;
-				linux,default-trigger = "cpu0";
+			gpio_leds {
+				compatible = "gpio-leds";
+				pinctrl-names = "default";
+				pinctrl-0 = <&pwr_led_pin &stat_led_pins>;
+
+				green_pwr_led {
+					label = "mirabox:green:pwr";
+					gpios = <&gpio1 31 1>;
+					linux,default-trigger = "heartbeat";
+				};
+
+				blue_stat_led {
+					label = "mirabox:blue:stat";
+					gpios = <&gpio2 0 1>;
+					linux,default-trigger = "cpu0";
+				};
+
+				green_stat_led {
+					label = "mirabox:green:stat";
+					gpios = <&gpio2 1 1>;
+					default-state = "off";
+				};
 			};
 
-			green_stat_led {
-				label = "mirabox:green:stat";
-				gpios = <&gpio2 1 1>;
-				default-state = "off";
-			};
-		};
+			mdio {
+				phy0: ethernet-phy at 0 {
+					reg = <0>;
+				};
 
-		mdio {
-			phy0: ethernet-phy at 0 {
-				reg = <0>;
+				phy1: ethernet-phy at 1 {
+					reg = <1>;
+				};
 			};
-
-			phy1: ethernet-phy at 1 {
-				reg = <1>;
+			ethernet at 70000 {
+				status = "okay";
+				phy = <&phy0>;
+				phy-mode = "rgmii-id";
+			};
+			ethernet at 74000 {
+				status = "okay";
+				phy = <&phy1>;
+				phy-mode = "rgmii-id";
 			};
-		};
-		ethernet at 70000 {
-			status = "okay";
-			phy = <&phy0>;
-			phy-mode = "rgmii-id";
-		};
-		ethernet at 74000 {
-			status = "okay";
-			phy = <&phy1>;
-			phy-mode = "rgmii-id";
-		};
-
-		mvsdio at d4000 {
-			pinctrl-0 = <&sdio_pins3>;
-			pinctrl-names = "default";
-			status = "okay";
-			/*
-			 * No CD or WP GPIOs: SDIO interface used for
-			 * Wifi/Bluetooth chip
-			 */
-		};
-
-		usb at 50000 {
-			status = "okay";
-		};
 
-		usb at 51000 {
-			status = "okay";
-		};
+			mvsdio at d4000 {
+				pinctrl-0 = <&sdio_pins3>;
+				pinctrl-names = "default";
+				status = "okay";
+				/*
+				 * No CD or WP GPIOs: SDIO interface used for
+				 * Wifi/Bluetooth chip
+				 */
+			};
 
-		i2c at 11000 {
-			status = "okay";
-			clock-frequency = <100000>;
-			pca9505: pca9505 at 25 {
-				compatible = "nxp,pca9505";
-				gpio-controller;
-				#gpio-cells = <2>;
-				reg = <0x25>;
+			usb at 50000 {
+				status = "okay";
 			};
-		};
 
-		pcie-controller {
-			status = "okay";
+			usb at 51000 {
+				status = "okay";
+			};
 
-			/* Internal mini-PCIe connector */
-			pcie at 1,0 {
-				/* Port 0, Lane 0 */
+			i2c at 11000 {
 				status = "okay";
+				clock-frequency = <100000>;
+				pca9505: pca9505 at 25 {
+					compatible = "nxp,pca9505";
+					gpio-controller;
+					#gpio-cells = <2>;
+					reg = <0x25>;
+				};
 			};
 
-			/* Connected on the PCB to a USB 3.0 XHCI controller */
-			pcie at 2,0 {
-				/* Port 1, Lane 0 */
+			pcie-controller {
 				status = "okay";
+
+				/* Internal mini-PCIe connector */
+				pcie at 1,0 {
+					/* Port 0, Lane 0 */
+					status = "okay";
+				};
+
+				/* Connected on the PCB to a USB 3.0 XHCI controller */
+				pcie at 2,0 {
+					/* Port 1, Lane 0 */
+					status = "okay";
+				};
 			};
 		};
 	};
diff --git a/arch/arm/boot/dts/armada-370-rd.dts b/arch/arm/boot/dts/armada-370-rd.dts
index 83d5c04..130f839 100644
--- a/arch/arm/boot/dts/armada-370-rd.dts
+++ b/arch/arm/boot/dts/armada-370-rd.dts
@@ -28,60 +28,62 @@
 	};
 
 	soc {
-		serial at 12000 {
-			clock-frequency = <200000000>;
-			status = "okay";
-		};
-		sata at a0000 {
-			nr-ports = <2>;
-			status = "okay";
-		};
-
-		mdio {
-			phy0: ethernet-phy at 0 {
-				reg = <0>;
+		internal-regs {
+			serial at 12000 {
+				clock-frequency = <200000000>;
+				status = "okay";
 			};
+			sata at a0000 {
+				nr-ports = <2>;
+				status = "okay";
+			};
+
+			mdio {
+				phy0: ethernet-phy at 0 {
+					reg = <0>;
+				};
 
-			phy1: ethernet-phy at 1 {
-				reg = <1>;
+				phy1: ethernet-phy at 1 {
+					reg = <1>;
+				};
 			};
-		};
 
-		ethernet at 70000 {
-			status = "okay";
-			phy = <&phy0>;
-			phy-mode = "sgmii";
-		};
-		ethernet at 74000 {
-			status = "okay";
-			phy = <&phy1>;
-			phy-mode = "rgmii-id";
-		};
+			ethernet at 70000 {
+				status = "okay";
+				phy = <&phy0>;
+				phy-mode = "sgmii";
+			};
+			ethernet at 74000 {
+				status = "okay";
+				phy = <&phy1>;
+				phy-mode = "rgmii-id";
+			};
 
-		mvsdio at d4000 {
-			pinctrl-0 = <&sdio_pins1>;
-			pinctrl-names = "default";
-			status = "okay";
-			/* No CD or WP GPIOs */
-		};
+			mvsdio at d4000 {
+				pinctrl-0 = <&sdio_pins1>;
+				pinctrl-names = "default";
+				status = "okay";
+				/* No CD or WP GPIOs */
+			};
 
-		usb at 50000 {
-			status = "okay";
-		};
+			usb at 50000 {
+				status = "okay";
+			};
 
-		usb at 51000 {
-			status = "okay";
-		};
-	};
+			usb at 51000 {
+				status = "okay";
+			};
 
-	gpio-keys {
-		compatible = "gpio-keys";
-		#address-cells = <1>;
-		#size-cells = <0>;
-		button at 1 {
-			label = "Software Button";
-			linux,code = <116>;
-			gpios = <&gpio0 6 1>;
+			gpio-keys {
+				compatible = "gpio-keys";
+				#address-cells = <1>;
+				#size-cells = <0>;
+				button at 1 {
+					label = "Software Button";
+					linux,code = <116>;
+					gpios = <&gpio0 6 1>;
+				};
+			};
 		};
 	};
-};
+ };
diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi b/arch/arm/boot/dts/armada-370-xp.dtsi
index da40ce5..bf8f911 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -28,7 +28,6 @@
 		};
 	};
 
-
 	soc {
 		#address-cells = <1>;
 		#size-cells = <1>;
@@ -36,192 +35,196 @@
 		interrupt-parent = <&mpic>;
 		ranges = <0 0xd0000000 0x100000>;
 
-		mpic: interrupt-controller at 20000 {
+		internal-regs {
+			compatible = "simple-bus";
+			#address-cells = <1>;
+			#size-cells = <1>;
+			ranges;
+
+			mpic: interrupt-controller at 20000 {
 				compatible = "marvell,mpic";
 				#interrupt-cells = <1>;
 				#size-cells = <1>;
 				interrupt-controller;
-		};
+			};
 
-		coherency-fabric at 20200 {
+			coherency-fabric at 20200 {
 				compatible = "marvell,coherency-fabric";
-				reg = <0x20200 0xb0>,
-				      <0x21810 0x1c>;
-		};
+				reg = <0x20200 0xb0>, <0x21810 0x1c>;
+			};
 
-		serial at 12000 {
+			serial at 12000 {
 				compatible = "snps,dw-apb-uart";
 				reg = <0x12000 0x100>;
 				reg-shift = <2>;
 				interrupts = <41>;
 				reg-io-width = <1>;
 				status = "disabled";
-		};
-		serial at 12100 {
+			};
+			serial at 12100 {
 				compatible = "snps,dw-apb-uart";
 				reg = <0x12100 0x100>;
 				reg-shift = <2>;
 				interrupts = <42>;
 				reg-io-width = <1>;
 				status = "disabled";
-		};
-
-		timer at 20300 {
-			       compatible = "marvell,armada-370-xp-timer";
-			       reg = <0x20300 0x30>,
-			       <0x21040 0x30>;
-			       interrupts = <37>, <38>, <39>, <40>, <5>, <6>;
-			       clocks = <&coreclk 2>;
-		};
-
-		sata at a0000 {
-			compatible = "marvell,orion-sata";
-			reg = <0xa0000 0x2400>;
-			interrupts = <55>;
-			clocks = <&gateclk 15>, <&gateclk 30>;
-			clock-names = "0", "1";
-			status = "disabled";
-		};
+			};
+
+			timer at 20300 {
+				compatible = "marvell,armada-370-xp-timer";
+				reg = <0x20300 0x30>, <0x21040 0x30>;
+				interrupts = <37>, <38>, <39>, <40>, <5>, <6>;
+				clocks = <&coreclk 2>;
+			};
+
+			sata at a0000 {
+				compatible = "marvell,orion-sata";
+				reg = <0xa0000 0x2400>;
+				interrupts = <55>;
+				clocks = <&gateclk 15>, <&gateclk 30>;
+				clock-names = "0", "1";
+				status = "disabled";
+			};
 
-		mdio {
-			#address-cells = <1>;
-			#size-cells = <0>;
-			compatible = "marvell,orion-mdio";
-			reg = <0x72004 0x4>;
-		};
+			mdio {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "marvell,orion-mdio";
+				reg = <0x72004 0x4>;
+			};
 
-		ethernet at 70000 {
+			ethernet at 70000 {
 				compatible = "marvell,armada-370-neta";
 				reg = <0x70000 0x2500>;
 				interrupts = <8>;
 				clocks = <&gateclk 4>;
 				status = "disabled";
-		};
+			};
 
-		ethernet at 74000 {
+			ethernet at 74000 {
 				compatible = "marvell,armada-370-neta";
 				reg = <0x74000 0x2500>;
 				interrupts = <10>;
 				clocks = <&gateclk 3>;
 				status = "disabled";
-		};
-
-		i2c0: i2c at 11000 {
-			compatible = "marvell,mv64xxx-i2c";
-			reg = <0x11000 0x20>;
-			#address-cells = <1>;
-			#size-cells = <0>;
-			interrupts = <31>;
-			timeout-ms = <1000>;
-			clocks = <&coreclk 0>;
-			status = "disabled";
-		};
-
-		i2c1: i2c at 11100 {
-			compatible = "marvell,mv64xxx-i2c";
-			reg = <0x11100 0x20>;
-			#address-cells = <1>;
-			#size-cells = <0>;
-			interrupts = <32>;
-			timeout-ms = <1000>;
-			clocks = <&coreclk 0>;
-			status = "disabled";
-		};
-
-		rtc at 10300 {
-			compatible = "marvell,orion-rtc";
-			reg = <0x10300 0x20>;
-			interrupts = <50>;
-		};
-
-		mvsdio at d4000 {
-			compatible = "marvell,orion-sdio";
-			reg = <0xd4000 0x200>;
-			interrupts = <54>;
-			clocks = <&gateclk 17>;
-			status = "disabled";
-		};
-
-		usb at 50000 {
-			compatible = "marvell,orion-ehci";
-			reg = <0x50000 0x500>;
-			interrupts = <45>;
-			status = "disabled";
-		};
-
-		usb at 51000 {
-			compatible = "marvell,orion-ehci";
-			reg = <0x51000 0x500>;
-			interrupts = <46>;
-			status = "disabled";
-		};
+			};
+
+			i2c0: i2c at 11000 {
+				compatible = "marvell,mv64xxx-i2c";
+				reg = <0x11000 0x20>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+				interrupts = <31>;
+				timeout-ms = <1000>;
+				clocks = <&coreclk 0>;
+				status = "disabled";
+			};
+
+			i2c1: i2c at 11100 {
+				compatible = "marvell,mv64xxx-i2c";
+				reg = <0x11100 0x20>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+				interrupts = <32>;
+				timeout-ms = <1000>;
+				clocks = <&coreclk 0>;
+				status = "disabled";
+			};
+
+			rtc at 10300 {
+				compatible = "marvell,orion-rtc";
+				reg = <0x10300 0x20>;
+				interrupts = <50>;
+			};
+
+			mvsdio at d4000 {
+				compatible = "marvell,orion-sdio";
+				reg = <0xd4000 0x200>;
+				interrupts = <54>;
+				clocks = <&gateclk 17>;
+				status = "disabled";
+			};
 
-		spi0: spi at 10600 {
-			compatible = "marvell,orion-spi";
-			reg = <0x10600 0x28>;
-			#address-cells = <1>;
-			#size-cells = <0>;
-			cell-index = <0>;
-			interrupts = <30>;
-			clocks = <&coreclk 0>;
-			status = "disabled";
-		};
+			usb at 50000 {
+				compatible = "marvell,orion-ehci";
+				reg = <0x50000 0x500>;
+				interrupts = <45>;
+				status = "disabled";
+			};
 
-		spi1: spi at 10680 {
-			compatible = "marvell,orion-spi";
-			reg = <0x10680 0x28>;
-			#address-cells = <1>;
-			#size-cells = <0>;
-			cell-index = <1>;
-			interrupts = <92>;
-			clocks = <&coreclk 0>;
-			status = "disabled";
-		};
+			usb at 51000 {
+				compatible = "marvell,orion-ehci";
+				reg = <0x51000 0x500>;
+				interrupts = <46>;
+				status = "disabled";
+			};
+
+			spi0: spi at 10600 {
+				compatible = "marvell,orion-spi";
+				reg = <0x10600 0x28>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+				cell-index = <0>;
+				interrupts = <30>;
+				clocks = <&coreclk 0>;
+				status = "disabled";
+			};
+
+			spi1: spi at 10680 {
+				compatible = "marvell,orion-spi";
+				reg = <0x10680 0x28>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+				cell-index = <1>;
+				interrupts = <92>;
+				clocks = <&coreclk 0>;
+				status = "disabled";
+			};
 
-		devbus-bootcs at 10400 {
-			compatible = "marvell,mvebu-devbus";
-			reg = <0x10400 0x8>;
-			#address-cells = <1>;
-			#size-cells = <1>;
-			clocks = <&coreclk 0>;
-			status = "disabled";
-		};
+			devbus-bootcs at 10400 {
+				compatible = "marvell,mvebu-devbus";
+				reg = <0x10400 0x8>;
+				#address-cells = <1>;
+				#size-cells = <1>;
+				clocks = <&coreclk 0>;
+				status = "disabled";
+			};
 
-		devbus-cs0 at 10408 {
-			compatible = "marvell,mvebu-devbus";
-			reg = <0x10408 0x8>;
-			#address-cells = <1>;
-			#size-cells = <1>;
-			clocks = <&coreclk 0>;
-			status = "disabled";
-		};
+			devbus-cs0 at 10408 {
+				compatible = "marvell,mvebu-devbus";
+				reg = <0x10408 0x8>;
+				#address-cells = <1>;
+				#size-cells = <1>;
+				clocks = <&coreclk 0>;
+				status = "disabled";
+			};
 
-		devbus-cs1 at 10410 {
-			compatible = "marvell,mvebu-devbus";
-			reg = <0x10410 0x8>;
-			#address-cells = <1>;
-			#size-cells = <1>;
-			clocks = <&coreclk 0>;
-			status = "disabled";
-		};
+			devbus-cs1 at 10410 {
+				compatible = "marvell,mvebu-devbus";
+				reg = <0x10410 0x8>;
+				#address-cells = <1>;
+				#size-cells = <1>;
+				clocks = <&coreclk 0>;
+				status = "disabled";
+			};
 
-		devbus-cs2 at 10418 {
-			compatible = "marvell,mvebu-devbus";
-			reg = <0x10418 0x8>;
-			#address-cells = <1>;
-			#size-cells = <1>;
-			clocks = <&coreclk 0>;
-			status = "disabled";
-		};
+			devbus-cs2 at 10418 {
+				compatible = "marvell,mvebu-devbus";
+				reg = <0x10418 0x8>;
+				#address-cells = <1>;
+				#size-cells = <1>;
+				clocks = <&coreclk 0>;
+				status = "disabled";
+			};
 
-		devbus-cs3 at 10420 {
-			compatible = "marvell,mvebu-devbus";
-			reg = <0x10420 0x8>;
-			#address-cells = <1>;
-			#size-cells = <1>;
-			clocks = <&coreclk 0>;
-			status = "disabled";
+			devbus-cs3 at 10420 {
+				compatible = "marvell,mvebu-devbus";
+				reg = <0x10420 0x8>;
+				#address-cells = <1>;
+				#size-cells = <1>;
+				clocks = <&coreclk 0>;
+				status = "disabled";
+			};
 		};
 	};
-};
-
+ };
diff --git a/arch/arm/boot/dts/armada-370.dtsi b/arch/arm/boot/dts/armada-370.dtsi
index 5c4fa65..6ef95dd 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -28,195 +28,195 @@
 	};
 
 	soc {
-
-		mpic: interrupt-controller at 20000 {
-			reg = <0x20a00 0x1d0>,
-			      <0x21870 0x58>;
-		};
-
-		system-controller at 18200 {
+		internal-regs {
+			system-controller at 18200 {
 				compatible = "marvell,armada-370-xp-system-controller";
 				reg = <0x18200 0x100>;
-		};
-
-		L2: l2-cache {
-			compatible = "marvell,aurora-outer-cache";
-			reg = <0xd0008000 0x1000>;
-			cache-id-part = <0x100>;
-			wt-override;
-		};
-
-		pinctrl {
-			compatible = "marvell,mv88f6710-pinctrl";
-			reg = <0x18000 0x38>;
-
-			sdio_pins1: sdio-pins1 {
-			      marvell,pins = "mpp9",  "mpp11", "mpp12",
-					     "mpp13", "mpp14", "mpp15";
-			      marvell,function = "sd0";
 			};
 
-			sdio_pins2: sdio-pins2 {
-			      marvell,pins = "mpp47", "mpp48", "mpp49",
-					     "mpp50", "mpp51", "mpp52";
-			      marvell,function = "sd0";
+			L2: l2-cache {
+				compatible = "marvell,aurora-outer-cache";
+				reg = <0xd0008000 0x1000>;
+				cache-id-part = <0x100>;
+				wt-override;
 			};
 
-			sdio_pins3: sdio-pins3 {
-			      marvell,pins = "mpp48", "mpp49", "mpp50",
-					     "mpp51", "mpp52", "mpp53";
-			      marvell,function = "sd0";
+			mpic: interrupt-controller at 20000 {
+				reg = <0x20a00 0x1d0>, <0x21870 0x58>;
 			};
-	        };
-
-		gpio0: gpio at 18100 {
-			compatible = "marvell,orion-gpio";
-			reg = <0x18100 0x40>;
-			ngpios = <32>;
-			gpio-controller;
-			#gpio-cells = <2>;
-			interrupt-controller;
-			#interrupts-cells = <2>;
-			interrupts = <82>, <83>, <84>, <85>;
-		};
-
-		gpio1: gpio at 18140 {
-			compatible = "marvell,orion-gpio";
-			reg = <0x18140 0x40>;
-			ngpios = <32>;
-			gpio-controller;
-			#gpio-cells = <2>;
-			interrupt-controller;
-			#interrupts-cells = <2>;
-			interrupts = <87>, <88>, <89>, <90>;
-		};
 
-		gpio2: gpio at 18180 {
-			compatible = "marvell,orion-gpio";
-			reg = <0x18180 0x40>;
-			ngpios = <2>;
-			gpio-controller;
-			#gpio-cells = <2>;
-			interrupt-controller;
-			#interrupts-cells = <2>;
-			interrupts = <91>;
-		};
-
-		coreclk: mvebu-sar at 18230 {
-			compatible = "marvell,armada-370-core-clock";
-			reg = <0x18230 0x08>;
-			#clock-cells = <1>;
-		};
-
-		gateclk: clock-gating-control at 18220 {
-			compatible = "marvell,armada-370-gating-clock";
-			reg = <0x18220 0x4>;
-			clocks = <&coreclk 0>;
-			#clock-cells = <1>;
-		};
-
-		xor at 60800 {
-			compatible = "marvell,orion-xor";
-			reg = <0x60800 0x100
-			       0x60A00 0x100>;
-			status = "okay";
-
-			xor00 {
-				interrupts = <51>;
-				dmacap,memcpy;
-				dmacap,xor;
-			};
-			xor01 {
-				interrupts = <52>;
-				dmacap,memcpy;
-				dmacap,xor;
-				dmacap,memset;
+			pinctrl {
+				compatible = "marvell,mv88f6710-pinctrl";
+				reg = <0x18000 0x38>;
+
+				sdio_pins1: sdio-pins1 {
+					marvell,pins = "mpp9",  "mpp11", "mpp12",
+							"mpp13", "mpp14", "mpp15";
+					marvell,function = "sd0";
+				};
+
+				sdio_pins2: sdio-pins2 {
+					marvell,pins = "mpp47", "mpp48", "mpp49",
+							"mpp50", "mpp51", "mpp52";
+					marvell,function = "sd0";
+				};
+
+				sdio_pins3: sdio-pins3 {
+					marvell,pins = "mpp48", "mpp49", "mpp50",
+							"mpp51", "mpp52", "mpp53";
+					marvell,function = "sd0";
+				};
 			};
-		};
 
-		xor at 60900 {
-			compatible = "marvell,orion-xor";
-			reg = <0x60900 0x100
-			       0x60b00 0x100>;
-			status = "okay";
-
-			xor10 {
-				interrupts = <94>;
-				dmacap,memcpy;
-				dmacap,xor;
-			};
-			xor11 {
-				interrupts = <95>;
-				dmacap,memcpy;
-				dmacap,xor;
-				dmacap,memset;
+			gpio0: gpio at 18100 {
+				compatible = "marvell,orion-gpio";
+				reg = <0x18100 0x40>;
+				ngpios = <32>;
+				gpio-controller;
+				#gpio-cells = <2>;
+				interrupt-controller;
+				#interrupts-cells = <2>;
+				interrupts = <82>, <83>, <84>, <85>;
 			};
-		};
-
-		usb at 50000 {
-			clocks = <&coreclk 0>;
-		};
 
-		usb at 51000 {
-			clocks = <&coreclk 0>;
-		};
+			gpio1: gpio at 18140 {
+				compatible = "marvell,orion-gpio";
+				reg = <0x18140 0x40>;
+				ngpios = <32>;
+				gpio-controller;
+				#gpio-cells = <2>;
+				interrupt-controller;
+				#interrupts-cells = <2>;
+				interrupts = <87>, <88>, <89>, <90>;
+			};
 
-		thermal at 18300 {
-			compatible = "marvell,armada370-thermal";
-			reg = <0x18300 0x4
-			       0x18304 0x4>;
-			status = "okay";
-		};
+			gpio2: gpio at 18180 {
+				compatible = "marvell,orion-gpio";
+				reg = <0x18180 0x40>;
+				ngpios = <2>;
+				gpio-controller;
+				#gpio-cells = <2>;
+				interrupt-controller;
+				#interrupts-cells = <2>;
+				interrupts = <91>;
+			};
 
-		pcie-controller {
-			compatible = "marvell,armada-370-pcie";
-			status = "disabled";
-			device_type = "pci";
+			coreclk: mvebu-sar at 18230 {
+				compatible = "marvell,armada-370-core-clock";
+				reg = <0x18230 0x08>;
+				#clock-cells = <1>;
+			};
 
-			#address-cells = <3>;
-			#size-cells = <2>;
+			gateclk: clock-gating-control at 18220 {
+				compatible = "marvell,armada-370-gating-clock";
+				reg = <0x18220 0x4>;
+				clocks = <&coreclk 0>;
+				#clock-cells = <1>;
+			};
 
-			bus-range = <0x00 0xff>;
+			xor at 60800 {
+				compatible = "marvell,orion-xor";
+				reg = <0x60800 0x100
+				       0x60A00 0x100>;
+				status = "okay";
+
+				xor00 {
+					interrupts = <51>;
+					dmacap,memcpy;
+					dmacap,xor;
+				};
+				xor01 {
+					interrupts = <52>;
+					dmacap,memcpy;
+					dmacap,xor;
+					dmacap,memset;
+				};
+			};
 
-			reg = <0x40000 0x2000>, <0x80000 0x2000>;
+			xor at 60900 {
+				compatible = "marvell,orion-xor";
+				reg = <0x60900 0x100
+				       0x60b00 0x100>;
+				status = "okay";
+
+				xor10 {
+					interrupts = <94>;
+					dmacap,memcpy;
+					dmacap,xor;
+				};
+				xor11 {
+					interrupts = <95>;
+					dmacap,memcpy;
+					dmacap,xor;
+					dmacap,memset;
+				};
+			};
 
-			reg-names = "pcie0.0", "pcie1.0";
+			usb at 50000 {
+				clocks = <&coreclk 0>;
+			};
 
-			ranges = <0x82000000 0 0x40000 0x40000 0 0x00002000   /* Port 0.0 registers */
-				  0x82000000 0 0x80000 0x80000 0 0x00002000   /* Port 1.0 registers */
-				  0x82000000 0 0xe0000000 0xe0000000 0 0x08000000   /* non-prefetchable memory */
-			          0x81000000 0 0          0xe8000000 0 0x00100000>; /* downstream I/O */
+			usb at 51000 {
+				clocks = <&coreclk 0>;
+			};
 
-			pcie at 1,0 {
-				device_type = "pci";
-				assigned-addresses = <0x82000800 0 0x40000 0 0x2000>;
-				reg = <0x0800 0 0 0 0>;
-				#address-cells = <3>;
-				#size-cells = <2>;
-				#interrupt-cells = <1>;
-				ranges;
-				interrupt-map-mask = <0 0 0 0>;
-				interrupt-map = <0 0 0 0 &mpic 58>;
-				marvell,pcie-port = <0>;
-				marvell,pcie-lane = <0>;
-				clocks = <&gateclk 5>;
-				status = "disabled";
+			thermal at 18300 {
+				compatible = "marvell,armada370-thermal";
+				reg = <0x18300 0x4
+					0x18304 0x4>;
+				status = "okay";
 			};
 
-			pcie at 2,0 {
+			pcie-controller {
+				compatible = "marvell,armada-370-pcie";
+				status = "disabled";
 				device_type = "pci";
-				assigned-addresses = <0x82002800 0 0x80000 0 0x2000>;
-				reg = <0x1000 0 0 0 0>;
+
 				#address-cells = <3>;
 				#size-cells = <2>;
-				#interrupt-cells = <1>;
-				ranges;
-				interrupt-map-mask = <0 0 0 0>;
-				interrupt-map = <0 0 0 0 &mpic 62>;
-				marvell,pcie-port = <1>;
-				marvell,pcie-lane = <0>;
-				clocks = <&gateclk 9>;
-				status = "disabled";
+
+				bus-range = <0x00 0xff>;
+
+				reg = <0x40000 0x2000>, <0x80000 0x2000>;
+
+				reg-names = "pcie0.0", "pcie1.0";
+
+				ranges = <0x82000000 0 0x40000 0x40000 0 0x00002000   /* Port 0.0 registers */
+					0x82000000 0 0x80000 0x80000 0 0x00002000   /* Port 1.0 registers */
+					0x82000000 0 0xe0000000 0xe0000000 0 0x08000000   /* non-prefetchable memory */
+					0x81000000 0 0          0xe8000000 0 0x00100000>; /* downstream I/O */
+
+				pcie at 1,0 {
+					device_type = "pci";
+					assigned-addresses = <0x82000800 0 0x40000 0 0x2000>;
+					reg = <0x0800 0 0 0 0>;
+					#address-cells = <3>;
+					#size-cells = <2>;
+					#interrupt-cells = <1>;
+					ranges;
+					interrupt-map-mask = <0 0 0 0>;
+					interrupt-map = <0 0 0 0 &mpic 58>;
+					marvell,pcie-port = <0>;
+					marvell,pcie-lane = <0>;
+					clocks = <&gateclk 5>;
+					status = "disabled";
+				};
+
+				pcie at 2,0 {
+					device_type = "pci";
+					assigned-addresses = <0x82002800 0 0x80000 0 0x2000>;
+					reg = <0x1000 0 0 0 0>;
+					#address-cells = <3>;
+					#size-cells = <2>;
+					#interrupt-cells = <1>;
+					ranges;
+					interrupt-map-mask = <0 0 0 0>;
+					interrupt-map = <0 0 0 0 &mpic 62>;
+					marvell,pcie-port = <1>;
+					marvell,pcie-lane = <0>;
+					clocks = <&gateclk 9>;
+					status = "disabled";
+				};
 			};
 		};
 	};
diff --git a/arch/arm/boot/dts/armada-xp-db.dts b/arch/arm/boot/dts/armada-xp-db.dts
index e37863f..6c8b032 100644
--- a/arch/arm/boot/dts/armada-xp-db.dts
+++ b/arch/arm/boot/dts/armada-xp-db.dts
@@ -30,128 +30,130 @@
 	};
 
 	soc {
-		serial at 12000 {
-			clock-frequency = <250000000>;
-			status = "okay";
-		};
-		serial at 12100 {
-			clock-frequency = <250000000>;
-			status = "okay";
-		};
-		serial at 12200 {
-			clock-frequency = <250000000>;
-			status = "okay";
-		};
-		serial at 12300 {
-			clock-frequency = <250000000>;
-			status = "okay";
-		};
-
-		sata at a0000 {
-			nr-ports = <2>;
-			status = "okay";
-		};
-
-		mdio {
-			phy0: ethernet-phy at 0 {
-				reg = <0>;
+		internal-regs {
+			serial at 12000 {
+				clock-frequency = <250000000>;
+				status = "okay";
 			};
-
-			phy1: ethernet-phy at 1 {
-				reg = <1>;
+			serial at 12100 {
+				clock-frequency = <250000000>;
+				status = "okay";
 			};
-
-			phy2: ethernet-phy at 2 {
-				reg = <25>;
+			serial at 12200 {
+				clock-frequency = <250000000>;
+				status = "okay";
 			};
-
-			phy3: ethernet-phy at 3 {
-				reg = <27>;
+			serial at 12300 {
+				clock-frequency = <250000000>;
+				status = "okay";
 			};
-		};
-
-		ethernet at 70000 {
-			status = "okay";
-			phy = <&phy0>;
-			phy-mode = "rgmii-id";
-		};
-		ethernet at 74000 {
-			status = "okay";
-			phy = <&phy1>;
-			phy-mode = "rgmii-id";
-		};
-		ethernet at 30000 {
-			status = "okay";
-			phy = <&phy2>;
-			phy-mode = "sgmii";
-		};
-		ethernet at 34000 {
-			status = "okay";
-			phy = <&phy3>;
-			phy-mode = "sgmii";
-		};
-
-		mvsdio at d4000 {
-			pinctrl-0 = <&sdio_pins>;
-			pinctrl-names = "default";
-			status = "okay";
-			/* No CD or WP GPIOs */
-		};
 
-		usb at 50000 {
-			status = "okay";
-		};
+			sata at a0000 {
+				nr-ports = <2>;
+				status = "okay";
+			};
 
-		usb at 51000 {
-			status = "okay";
-		};
+			mdio {
+				phy0: ethernet-phy at 0 {
+					reg = <0>;
+				};
 
-		usb at 52000 {
-			status = "okay";
-		};
+				phy1: ethernet-phy at 1 {
+					reg = <1>;
+				};
 
-		spi0: spi at 10600 {
-			status = "okay";
+				phy2: ethernet-phy at 2 {
+					reg = <25>;
+				};
 
-			spi-flash at 0 {
-				#address-cells = <1>;
-				#size-cells = <1>;
-				compatible = "m25p64";
-				reg = <0>; /* Chip select 0 */
-				spi-max-frequency = <20000000>;
+				phy3: ethernet-phy at 3 {
+					reg = <27>;
+				};
 			};
-		};
 
-		pcie-controller {
-			status = "okay";
+			ethernet at 70000 {
+				status = "okay";
+				phy = <&phy0>;
+				phy-mode = "rgmii-id";
+			};
+			ethernet at 74000 {
+				status = "okay";
+				phy = <&phy1>;
+				phy-mode = "rgmii-id";
+			};
+			ethernet at 30000 {
+				status = "okay";
+				phy = <&phy2>;
+				phy-mode = "sgmii";
+			};
+			ethernet at 34000 {
+				status = "okay";
+				phy = <&phy3>;
+				phy-mode = "sgmii";
+			};
 
-			/*
-			 * All 6 slots are physically present as
-			 * standard PCIe slots on the board.
-			 */
-			pcie at 1,0 {
-				/* Port 0, Lane 0 */
+			mvsdio at d4000 {
+				pinctrl-0 = <&sdio_pins>;
+				pinctrl-names = "default";
 				status = "okay";
+				/* No CD or WP GPIOs */
 			};
-			pcie at 2,0 {
-				/* Port 0, Lane 1 */
+
+			usb at 50000 {
 				status = "okay";
 			};
-			pcie at 3,0 {
-				/* Port 0, Lane 2 */
+
+			usb at 51000 {
 				status = "okay";
 			};
-			pcie at 4,0 {
-				/* Port 0, Lane 3 */
+
+			usb at 52000 {
 				status = "okay";
 			};
-			pcie at 9,0 {
-				/* Port 2, Lane 0 */
+
+			spi0: spi at 10600 {
 				status = "okay";
+
+				spi-flash at 0 {
+					#address-cells = <1>;
+					#size-cells = <1>;
+					compatible = "m25p64";
+					reg = <0>; /* Chip select 0 */
+					spi-max-frequency = <20000000>;
+				};
 			};
-			pcie at 10,0 {
-				/* Port 3, Lane 0 */
+
+			pcie-controller {
 				status = "okay";
+
+				/*
+				 * All 6 slots are physically present as
+				 * standard PCIe slots on the board.
+				 */
+				pcie at 1,0 {
+					/* Port 0, Lane 0 */
+					status = "okay";
+				};
+				pcie at 2,0 {
+					/* Port 0, Lane 1 */
+					status = "okay";
+				};
+				pcie at 3,0 {
+					/* Port 0, Lane 2 */
+					status = "okay";
+				};
+				pcie at 4,0 {
+					/* Port 0, Lane 3 */
+					status = "okay";
+				};
+				pcie at 9,0 {
+					/* Port 2, Lane 0 */
+					status = "okay";
+				};
+				pcie at 10,0 {
+					/* Port 3, Lane 0 */
+					status = "okay";
+				};
 			};
 		};
 	};
diff --git a/arch/arm/boot/dts/armada-xp-gp.dts b/arch/arm/boot/dts/armada-xp-gp.dts
index 55bcbff..d9972c9 100644
--- a/arch/arm/boot/dts/armada-xp-gp.dts
+++ b/arch/arm/boot/dts/armada-xp-gp.dts
@@ -37,126 +37,128 @@
 	};
 
 	soc {
-		serial at 12000 {
-			clock-frequency = <250000000>;
-			status = "okay";
-		};
-		serial at 12100 {
-			clock-frequency = <250000000>;
-			status = "okay";
-		};
-		serial at 12200 {
-			clock-frequency = <250000000>;
-			status = "okay";
-		};
-		serial at 12300 {
-			clock-frequency = <250000000>;
-			status = "okay";
-		};
-
-		sata at a0000 {
-			nr-ports = <2>;
-			status = "okay";
-		};
-
-		mdio {
-			phy0: ethernet-phy at 0 {
-				reg = <16>;
+		internal-regs {
+			serial at 12000 {
+				clock-frequency = <250000000>;
+				status = "okay";
 			};
-
-			phy1: ethernet-phy at 1 {
-				reg = <17>;
+			serial at 12100 {
+				clock-frequency = <250000000>;
+				status = "okay";
 			};
-
-			phy2: ethernet-phy at 2 {
-				reg = <18>;
+			serial at 12200 {
+				clock-frequency = <250000000>;
+				status = "okay";
+			};
+			serial at 12300 {
+				clock-frequency = <250000000>;
+				status = "okay";
 			};
 
-			phy3: ethernet-phy at 3 {
-				reg = <19>;
+			sata at a0000 {
+				nr-ports = <2>;
+				status = "okay";
 			};
-		};
 
-		ethernet at 70000 {
-			status = "okay";
-			phy = <&phy0>;
-			phy-mode = "rgmii-id";
-		};
-		ethernet at 74000 {
-			status = "okay";
-			phy = <&phy1>;
-			phy-mode = "rgmii-id";
-		};
-		ethernet at 30000 {
-			status = "okay";
-			phy = <&phy2>;
-			phy-mode = "rgmii-id";
-		};
-		ethernet at 34000 {
-			status = "okay";
-			phy = <&phy3>;
-			phy-mode = "rgmii-id";
-		};
+			mdio {
+				phy0: ethernet-phy at 0 {
+					reg = <16>;
+				};
 
-		spi0: spi at 10600 {
-			status = "okay";
+				phy1: ethernet-phy at 1 {
+					reg = <17>;
+				};
 
-			spi-flash at 0 {
-				#address-cells = <1>;
-				#size-cells = <1>;
-				compatible = "n25q128a13";
-				reg = <0>; /* Chip select 0 */
-				spi-max-frequency = <108000000>;
-			};
-		};
+				phy2: ethernet-phy at 2 {
+					reg = <18>;
+				};
 
-		devbus-bootcs at 10400 {
-			status = "okay";
-			ranges = <0 0xf0000000 0x1000000>; /* @addr 0xf000000, size 0x1000000 */
-
-			/* Device Bus parameters are required */
-
-			/* Read parameters */
-			devbus,bus-width    = <8>;
-			devbus,turn-off-ps  = <60000>;
-			devbus,badr-skew-ps = <0>;
-			devbus,acc-first-ps = <124000>;
-			devbus,acc-next-ps  = <248000>;
-			devbus,rd-setup-ps  = <0>;
-			devbus,rd-hold-ps   = <0>;
-
-			/* Write parameters */
-			devbus,sync-enable = <0>;
-			devbus,wr-high-ps  = <60000>;
-			devbus,wr-low-ps   = <60000>;
-			devbus,ale-wr-ps   = <60000>;
-
-			/* NOR 16 MiB */
-			nor at 0 {
-				compatible = "cfi-flash";
-				reg = <0 0x1000000>;
-				bank-width = <2>;
+				phy3: ethernet-phy at 3 {
+					reg = <19>;
+				};
 			};
-		};
 
-		pcie-controller {
-			status = "okay";
+			ethernet at 70000 {
+				status = "okay";
+				phy = <&phy0>;
+				phy-mode = "rgmii-id";
+			};
+			ethernet at 74000 {
+				status = "okay";
+				phy = <&phy1>;
+				phy-mode = "rgmii-id";
+			};
+			ethernet at 30000 {
+				status = "okay";
+				phy = <&phy2>;
+				phy-mode = "rgmii-id";
+			};
+			ethernet at 34000 {
+				status = "okay";
+				phy = <&phy3>;
+				phy-mode = "rgmii-id";
+			};
 
-			/*
-			 * The 3 slots are physically present as
-			 * standard PCIe slots on the board.
-			 */
-			pcie at 1,0 {
-				/* Port 0, Lane 0 */
+			spi0: spi at 10600 {
 				status = "okay";
+
+				spi-flash at 0 {
+					#address-cells = <1>;
+					#size-cells = <1>;
+					compatible = "n25q128a13";
+					reg = <0>; /* Chip select 0 */
+					spi-max-frequency = <108000000>;
+				};
 			};
-			pcie at 9,0 {
-				/* Port 2, Lane 0 */
+
+			devbus-bootcs at 10400 {
 				status = "okay";
+				ranges = <0 0xf0000000 0x1000000>; /* @addr 0xf000000, size 0x1000000 */
+
+				/* Device Bus parameters are required */
+
+				/* Read parameters */
+				devbus,bus-width    = <8>;
+				devbus,turn-off-ps  = <60000>;
+				devbus,badr-skew-ps = <0>;
+				devbus,acc-first-ps = <124000>;
+				devbus,acc-next-ps  = <248000>;
+				devbus,rd-setup-ps  = <0>;
+				devbus,rd-hold-ps   = <0>;
+
+				/* Write parameters */
+				devbus,sync-enable = <0>;
+				devbus,wr-high-ps  = <60000>;
+				devbus,wr-low-ps   = <60000>;
+				devbus,ale-wr-ps   = <60000>;
+
+				/* NOR 16 MiB */
+				nor at 0 {
+					compatible = "cfi-flash";
+					reg = <0 0x1000000>;
+					bank-width = <2>;
+				};
 			};
-			pcie at 10,0 {
-				/* Port 3, Lane 0 */
+
+			pcie-controller {
 				status = "okay";
+
+				/*
+				 * The 3 slots are physically present as
+				 * standard PCIe slots on the board.
+				 */
+				pcie at 1,0 {
+					/* Port 0, Lane 0 */
+					status = "okay";
+				};
+				pcie at 9,0 {
+					/* Port 2, Lane 0 */
+					status = "okay";
+				};
+				pcie at 10,0 {
+					/* Port 3, Lane 0 */
+					status = "okay";
+				};
 			};
 		};
 	};
diff --git a/arch/arm/boot/dts/armada-xp-mv78230.dtsi b/arch/arm/boot/dts/armada-xp-mv78230.dtsi
index 12905ab..f8eaa38 100644
--- a/arch/arm/boot/dts/armada-xp-mv78230.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78230.dtsi
@@ -44,140 +44,142 @@
 	};
 
 	soc {
-		pinctrl {
-			compatible = "marvell,mv78230-pinctrl";
-			reg = <0x18000 0x38>;
-
-			sdio_pins: sdio-pins {
-				marvell,pins = "mpp30", "mpp31", "mpp32",
-					       "mpp33", "mpp34", "mpp35";
-				marvell,function = "sd0";
+		internal-regs {
+			pinctrl {
+				compatible = "marvell,mv78230-pinctrl";
+				reg = <0x18000 0x38>;
+
+				sdio_pins: sdio-pins {
+					marvell,pins = "mpp30", "mpp31", "mpp32",
+						       "mpp33", "mpp34", "mpp35";
+					marvell,function = "sd0";
+				};
 			};
-		};
-
-		gpio0: gpio at 18100 {
-			compatible = "marvell,orion-gpio";
-			reg = <0x18100 0x40>;
-			ngpios = <32>;
-			gpio-controller;
-			#gpio-cells = <2>;
-			interrupt-controller;
-			#interrupts-cells = <2>;
-			interrupts = <82>, <83>, <84>, <85>;
-		};
-
-		gpio1: gpio at 18140 {
-			compatible = "marvell,orion-gpio";
-			reg = <0x18140 0x40>;
-			ngpios = <17>;
-			gpio-controller;
-			#gpio-cells = <2>;
-			interrupt-controller;
-			#interrupts-cells = <2>;
-			interrupts = <87>, <88>, <89>;
-		};
 
-		/*
-		 * MV78230 has 2 PCIe units Gen2.0: One unit can be
-		 * configured as x4 or quad x1 lanes. One unit is
-		 * x4/x1.
-		 */
-		pcie-controller {
-			compatible = "marvell,armada-xp-pcie";
-			status = "disabled";
-			device_type = "pci";
-
-			#address-cells = <3>;
-			#size-cells = <2>;
-
-			bus-range = <0x00 0xff>;
-
-			ranges = <0x82000000 0 0x40000 0x40000 0 0x00002000   /* Port 0.0 registers */
-				  0x82000000 0 0x42000 0x42000 0 0x00002000   /* Port 2.0 registers */
-				  0x82000000 0 0x44000 0x44000 0 0x00002000   /* Port 0.1 registers */
-				  0x82000000 0 0x48000 0x48000 0 0x00002000   /* Port 0.2 registers */
-				  0x82000000 0 0x4c000 0x4c000 0 0x00002000   /* Port 0.3 registers */
-				  0x82000000 0 0xe0000000 0xe0000000 0 0x08000000   /* non-prefetchable memory */
-				  0x81000000 0 0	  0xe8000000 0 0x00100000>; /* downstream I/O */
-
-			pcie at 1,0 {
-				device_type = "pci";
-				assigned-addresses = <0x82000800 0 0x40000 0 0x2000>;
-				reg = <0x0800 0 0 0 0>;
-				#address-cells = <3>;
-				#size-cells = <2>;
-				#interrupt-cells = <1>;
-				ranges;
-				interrupt-map-mask = <0 0 0 0>;
-				interrupt-map = <0 0 0 0 &mpic 58>;
-				marvell,pcie-port = <0>;
-				marvell,pcie-lane = <0>;
-				clocks = <&gateclk 5>;
-				status = "disabled";
+			gpio0: gpio at 18100 {
+				compatible = "marvell,orion-gpio";
+				reg = <0x18100 0x40>;
+				ngpios = <32>;
+				gpio-controller;
+				#gpio-cells = <2>;
+				interrupt-controller;
+				#interrupts-cells = <2>;
+				interrupts = <82>, <83>, <84>, <85>;
 			};
 
-			pcie at 2,0 {
-				device_type = "pci";
-				assigned-addresses = <0x82000800 0 0x44000 0 0x2000>;
-				reg = <0x1000 0 0 0 0>;
-				#address-cells = <3>;
-				#size-cells = <2>;
-				#interrupt-cells = <1>;
-				ranges;
-				interrupt-map-mask = <0 0 0 0>;
-				interrupt-map = <0 0 0 0 &mpic 59>;
-				marvell,pcie-port = <0>;
-				marvell,pcie-lane = <1>;
-				clocks = <&gateclk 6>;
-				status = "disabled";
+			gpio1: gpio at 18140 {
+				compatible = "marvell,orion-gpio";
+				reg = <0x18140 0x40>;
+				ngpios = <17>;
+				gpio-controller;
+				#gpio-cells = <2>;
+				interrupt-controller;
+				#interrupts-cells = <2>;
+				interrupts = <87>, <88>, <89>;
 			};
 
-			pcie at 3,0 {
-				device_type = "pci";
-				assigned-addresses = <0x82000800 0 0x48000 0 0x2000>;
-				reg = <0x1800 0 0 0 0>;
-				#address-cells = <3>;
-				#size-cells = <2>;
-				#interrupt-cells = <1>;
-				ranges;
-				interrupt-map-mask = <0 0 0 0>;
-				interrupt-map = <0 0 0 0 &mpic 60>;
-				marvell,pcie-port = <0>;
-				marvell,pcie-lane = <2>;
-				clocks = <&gateclk 7>;
+			/*
+			 * MV78230 has 2 PCIe units Gen2.0: One unit can be
+			 * configured as x4 or quad x1 lanes. One unit is
+			 * x4/x1.
+			 */
+			pcie-controller {
+				compatible = "marvell,armada-xp-pcie";
 				status = "disabled";
-			};
-
-			pcie at 4,0 {
 				device_type = "pci";
-				assigned-addresses = <0x82000800 0 0x4c000 0 0x2000>;
-				reg = <0x2000 0 0 0 0>;
-				#address-cells = <3>;
-				#size-cells = <2>;
-				#interrupt-cells = <1>;
-				ranges;
-				interrupt-map-mask = <0 0 0 0>;
-				interrupt-map = <0 0 0 0 &mpic 61>;
-				marvell,pcie-port = <0>;
-				marvell,pcie-lane = <3>;
-				clocks = <&gateclk 8>;
-				status = "disabled";
-			};
 
-			pcie at 9,0 {
-				device_type = "pci";
-				assigned-addresses = <0x82000800 0 0x42000 0 0x2000>;
-				reg = <0x4800 0 0 0 0>;
-				#address-cells = <3>;
-				#size-cells = <2>;
-				#interrupt-cells = <1>;
-				ranges;
-				interrupt-map-mask = <0 0 0 0>;
-				interrupt-map = <0 0 0 0 &mpic 99>;
-				marvell,pcie-port = <2>;
-				marvell,pcie-lane = <0>;
-				clocks = <&gateclk 26>;
-				status = "disabled";
+#address-cells = <3>;
+#size-cells = <2>;
+
+				bus-range = <0x00 0xff>;
+
+				ranges = <0x82000000 0 0x40000 0x40000 0 0x00002000   /* Port 0.0 registers */
+					0x82000000 0 0x42000 0x42000 0 0x00002000   /* Port 2.0 registers */
+					0x82000000 0 0x44000 0x44000 0 0x00002000   /* Port 0.1 registers */
+					0x82000000 0 0x48000 0x48000 0 0x00002000   /* Port 0.2 registers */
+					0x82000000 0 0x4c000 0x4c000 0 0x00002000   /* Port 0.3 registers */
+					0x82000000 0 0xe0000000 0xe0000000 0 0x08000000   /* non-prefetchable memory */
+					0x81000000 0 0	  0xe8000000 0 0x00100000>; /* downstream I/O */
+
+				pcie at 1,0 {
+					device_type = "pci";
+					assigned-addresses = <0x82000800 0 0x40000 0 0x2000>;
+					reg = <0x0800 0 0 0 0>;
+					#address-cells = <3>;
+					#size-cells = <2>;
+					#interrupt-cells = <1>;
+					ranges;
+					interrupt-map-mask = <0 0 0 0>;
+					interrupt-map = <0 0 0 0 &mpic 58>;
+					marvell,pcie-port = <0>;
+					marvell,pcie-lane = <0>;
+					clocks = <&gateclk 5>;
+					status = "disabled";
+				};
+
+				pcie at 2,0 {
+					device_type = "pci";
+					assigned-addresses = <0x82000800 0 0x44000 0 0x2000>;
+					reg = <0x1000 0 0 0 0>;
+					#address-cells = <3>;
+					#size-cells = <2>;
+					#interrupt-cells = <1>;
+					ranges;
+					interrupt-map-mask = <0 0 0 0>;
+					interrupt-map = <0 0 0 0 &mpic 59>;
+					marvell,pcie-port = <0>;
+					marvell,pcie-lane = <1>;
+					clocks = <&gateclk 6>;
+					status = "disabled";
+				};
+
+				pcie at 3,0 {
+					device_type = "pci";
+					assigned-addresses = <0x82000800 0 0x48000 0 0x2000>;
+					reg = <0x1800 0 0 0 0>;
+					#address-cells = <3>;
+					#size-cells = <2>;
+					#interrupt-cells = <1>;
+					ranges;
+					interrupt-map-mask = <0 0 0 0>;
+					interrupt-map = <0 0 0 0 &mpic 60>;
+					marvell,pcie-port = <0>;
+					marvell,pcie-lane = <2>;
+					clocks = <&gateclk 7>;
+					status = "disabled";
+				};
+
+				pcie at 4,0 {
+					device_type = "pci";
+					assigned-addresses = <0x82000800 0 0x4c000 0 0x2000>;
+					reg = <0x2000 0 0 0 0>;
+					#address-cells = <3>;
+					#size-cells = <2>;
+					#interrupt-cells = <1>;
+					ranges;
+					interrupt-map-mask = <0 0 0 0>;
+					interrupt-map = <0 0 0 0 &mpic 61>;
+					marvell,pcie-port = <0>;
+					marvell,pcie-lane = <3>;
+					clocks = <&gateclk 8>;
+					status = "disabled";
+				};
+
+				pcie at 9,0 {
+					device_type = "pci";
+					assigned-addresses = <0x82000800 0 0x42000 0 0x2000>;
+					reg = <0x4800 0 0 0 0>;
+					#address-cells = <3>;
+					#size-cells = <2>;
+					#interrupt-cells = <1>;
+					ranges;
+					interrupt-map-mask = <0 0 0 0>;
+					interrupt-map = <0 0 0 0 &mpic 99>;
+					marvell,pcie-port = <2>;
+					marvell,pcie-lane = <0>;
+					clocks = <&gateclk 26>;
+					status = "disabled";
+				};
 			};
 		};
 	};
diff --git a/arch/arm/boot/dts/armada-xp-mv78260.dtsi b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
index 1faacd1..f4029f0 100644
--- a/arch/arm/boot/dts/armada-xp-mv78260.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
@@ -45,177 +45,179 @@
 	};
 
 	soc {
-		pinctrl {
-			compatible = "marvell,mv78260-pinctrl";
-			reg = <0x18000 0x38>;
-
-			sdio_pins: sdio-pins {
-				marvell,pins = "mpp30", "mpp31", "mpp32",
-					       "mpp33", "mpp34", "mpp35";
-				marvell,function = "sd0";
+		internal-regs {
+			pinctrl {
+				compatible = "marvell,mv78260-pinctrl";
+				reg = <0x18000 0x38>;
+
+				sdio_pins: sdio-pins {
+					marvell,pins = "mpp30", "mpp31", "mpp32",
+						       "mpp33", "mpp34", "mpp35";
+					marvell,function = "sd0";
+				};
 			};
-		};
 
-		gpio0: gpio at 18100 {
-			compatible = "marvell,orion-gpio";
-			reg = <0x18100 0x40>;
-			ngpios = <32>;
-			gpio-controller;
-			#gpio-cells = <2>;
-			interrupt-controller;
-			#interrupts-cells = <2>;
-			interrupts = <82>, <83>, <84>, <85>;
-		};
+			gpio0: gpio at 18100 {
+				compatible = "marvell,orion-gpio";
+				reg = <0x18100 0x40>;
+				ngpios = <32>;
+				gpio-controller;
+				#gpio-cells = <2>;
+				interrupt-controller;
+				#interrupts-cells = <2>;
+				interrupts = <82>, <83>, <84>, <85>;
+			};
 
-		gpio1: gpio at 18140 {
-			compatible = "marvell,orion-gpio";
-			reg = <0x18140 0x40>;
-			ngpios = <32>;
-			gpio-controller;
-			#gpio-cells = <2>;
-			interrupt-controller;
-			#interrupts-cells = <2>;
-			interrupts = <87>, <88>, <89>, <90>;
-		};
+			gpio1: gpio at 18140 {
+				compatible = "marvell,orion-gpio";
+				reg = <0x18140 0x40>;
+				ngpios = <32>;
+				gpio-controller;
+				#gpio-cells = <2>;
+				interrupt-controller;
+				#interrupts-cells = <2>;
+				interrupts = <87>, <88>, <89>, <90>;
+			};
 
-		gpio2: gpio at 18180 {
-			compatible = "marvell,orion-gpio";
-			reg = <0x18180 0x40>;
-			ngpios = <3>;
-			gpio-controller;
-			#gpio-cells = <2>;
-			interrupt-controller;
-			#interrupts-cells = <2>;
-			interrupts = <91>;
-		};
+			gpio2: gpio at 18180 {
+				compatible = "marvell,orion-gpio";
+				reg = <0x18180 0x40>;
+				ngpios = <3>;
+				gpio-controller;
+				#gpio-cells = <2>;
+				interrupt-controller;
+				#interrupts-cells = <2>;
+				interrupts = <91>;
+			};
 
-		ethernet at 34000 {
+			ethernet at 34000 {
 				compatible = "marvell,armada-370-neta";
 				reg = <0x34000 0x2500>;
 				interrupts = <14>;
 				clocks = <&gateclk 1>;
 				status = "disabled";
-		};
-
-		/*
-		 * MV78260 has 3 PCIe units Gen2.0: Two units can be
-		 * configured as x4 or quad x1 lanes. One unit is
-		 * x4/x1.
-		 */
-		pcie-controller {
-			compatible = "marvell,armada-xp-pcie";
-			status = "disabled";
-			device_type = "pci";
-
-			#address-cells = <3>;
-			#size-cells = <2>;
-
-			bus-range = <0x00 0xff>;
-
-			ranges = <0x82000000 0 0x40000 0x40000 0 0x00002000   /* Port 0.0 registers */
-				  0x82000000 0 0x42000 0x42000 0 0x00002000   /* Port 2.0 registers */
-				  0x82000000 0 0x44000 0x44000 0 0x00002000   /* Port 0.1 registers */
-				  0x82000000 0 0x48000 0x48000 0 0x00002000   /* Port 0.2 registers */
-				  0x82000000 0 0x4c000 0x4c000 0 0x00002000   /* Port 0.3 registers */
-				  0x82000000 0 0x80000 0x80000 0 0x00002000   /* Port 1.0 registers */
-				  0x82000000 0 0x82000 0x82000 0 0x00002000   /* Port 3.0 registers */
-				  0x82000000 0 0xe0000000 0xe0000000 0 0x08000000   /* non-prefetchable memory */
-				  0x81000000 0 0	  0xe8000000 0 0x00100000>; /* downstream I/O */
-
-			pcie at 1,0 {
-				device_type = "pci";
-				assigned-addresses = <0x82000800 0 0x40000 0 0x2000>;
-				reg = <0x0800 0 0 0 0>;
-				#address-cells = <3>;
-				#size-cells = <2>;
-				#interrupt-cells = <1>;
-				ranges;
-				interrupt-map-mask = <0 0 0 0>;
-				interrupt-map = <0 0 0 0 &mpic 58>;
-				marvell,pcie-port = <0>;
-				marvell,pcie-lane = <0>;
-				clocks = <&gateclk 5>;
-				status = "disabled";
 			};
 
-			pcie at 2,0 {
-				device_type = "pci";
-				assigned-addresses = <0x82000800 0 0x44000 0 0x2000>;
-				reg = <0x1000 0 0 0 0>;
-				#address-cells = <3>;
-				#size-cells = <2>;
-				#interrupt-cells = <1>;
-				ranges;
-				interrupt-map-mask = <0 0 0 0>;
-				interrupt-map = <0 0 0 0 &mpic 59>;
-				marvell,pcie-port = <0>;
-				marvell,pcie-lane = <1>;
-				clocks = <&gateclk 6>;
+			/*
+			 * MV78260 has 3 PCIe units Gen2.0: Two units can be
+			 * configured as x4 or quad x1 lanes. One unit is
+			 * x4/x1.
+			 */
+			pcie-controller {
+				compatible = "marvell,armada-xp-pcie";
 				status = "disabled";
-			};
-
-			pcie at 3,0 {
 				device_type = "pci";
-				assigned-addresses = <0x82000800 0 0x48000 0 0x2000>;
-				reg = <0x1800 0 0 0 0>;
-				#address-cells = <3>;
-				#size-cells = <2>;
-				#interrupt-cells = <1>;
-				ranges;
-				interrupt-map-mask = <0 0 0 0>;
-				interrupt-map = <0 0 0 0 &mpic 60>;
-				marvell,pcie-port = <0>;
-				marvell,pcie-lane = <2>;
-				clocks = <&gateclk 7>;
-				status = "disabled";
-			};
 
-			pcie at 4,0 {
-				device_type = "pci";
-				assigned-addresses = <0x82000800 0 0x4c000 0 0x2000>;
-				reg = <0x2000 0 0 0 0>;
 				#address-cells = <3>;
 				#size-cells = <2>;
-				#interrupt-cells = <1>;
-				ranges;
-				interrupt-map-mask = <0 0 0 0>;
-				interrupt-map = <0 0 0 0 &mpic 61>;
-				marvell,pcie-port = <0>;
-				marvell,pcie-lane = <3>;
-				clocks = <&gateclk 8>;
-				status = "disabled";
-			};
 
-			pcie at 9,0 {
-				device_type = "pci";
-				assigned-addresses = <0x82000800 0 0x42000 0 0x2000>;
-				reg = <0x4800 0 0 0 0>;
-				#address-cells = <3>;
-				#size-cells = <2>;
-				#interrupt-cells = <1>;
-				ranges;
-				interrupt-map-mask = <0 0 0 0>;
-				interrupt-map = <0 0 0 0 &mpic 99>;
-				marvell,pcie-port = <2>;
-				marvell,pcie-lane = <0>;
-				clocks = <&gateclk 26>;
-				status = "disabled";
-			};
-
-			pcie at 10,0 {
-				device_type = "pci";
-				assigned-addresses = <0x82000800 0 0x82000 0 0x2000>;
-				reg = <0x5000 0 0 0 0>;
-				#address-cells = <3>;
-				#size-cells = <2>;
-				#interrupt-cells = <1>;
-				ranges;
-				interrupt-map-mask = <0 0 0 0>;
-				interrupt-map = <0 0 0 0 &mpic 103>;
-				marvell,pcie-port = <3>;
-				marvell,pcie-lane = <0>;
-				clocks = <&gateclk 27>;
-				status = "disabled";
+				bus-range = <0x00 0xff>;
+
+				ranges = <0x82000000 0 0x40000 0x40000 0 0x00002000   /* Port 0.0 registers */
+					0x82000000 0 0x42000 0x42000 0 0x00002000   /* Port 2.0 registers */
+					0x82000000 0 0x44000 0x44000 0 0x00002000   /* Port 0.1 registers */
+					0x82000000 0 0x48000 0x48000 0 0x00002000   /* Port 0.2 registers */
+					0x82000000 0 0x4c000 0x4c000 0 0x00002000   /* Port 0.3 registers */
+					0x82000000 0 0x80000 0x80000 0 0x00002000   /* Port 1.0 registers */
+					0x82000000 0 0x82000 0x82000 0 0x00002000   /* Port 3.0 registers */
+					0x82000000 0 0xe0000000 0xe0000000 0 0x08000000   /* non-prefetchable memory */
+					0x81000000 0 0	  0xe8000000 0 0x00100000>; /* downstream I/O */
+
+				pcie at 1,0 {
+					device_type = "pci";
+					assigned-addresses = <0x82000800 0 0x40000 0 0x2000>;
+					reg = <0x0800 0 0 0 0>;
+					#address-cells = <3>;
+					#size-cells = <2>;
+					#interrupt-cells = <1>;
+					ranges;
+					interrupt-map-mask = <0 0 0 0>;
+					interrupt-map = <0 0 0 0 &mpic 58>;
+					marvell,pcie-port = <0>;
+					marvell,pcie-lane = <0>;
+					clocks = <&gateclk 5>;
+					status = "disabled";
+				};
+
+				pcie at 2,0 {
+					device_type = "pci";
+					assigned-addresses = <0x82000800 0 0x44000 0 0x2000>;
+					reg = <0x1000 0 0 0 0>;
+					#address-cells = <3>;
+					#size-cells = <2>;
+					#interrupt-cells = <1>;
+					ranges;
+					interrupt-map-mask = <0 0 0 0>;
+					interrupt-map = <0 0 0 0 &mpic 59>;
+					marvell,pcie-port = <0>;
+					marvell,pcie-lane = <1>;
+					clocks = <&gateclk 6>;
+					status = "disabled";
+				};
+
+				pcie at 3,0 {
+					device_type = "pci";
+					assigned-addresses = <0x82000800 0 0x48000 0 0x2000>;
+					reg = <0x1800 0 0 0 0>;
+					#address-cells = <3>;
+					#size-cells = <2>;
+					#interrupt-cells = <1>;
+					ranges;
+					interrupt-map-mask = <0 0 0 0>;
+					interrupt-map = <0 0 0 0 &mpic 60>;
+					marvell,pcie-port = <0>;
+					marvell,pcie-lane = <2>;
+					clocks = <&gateclk 7>;
+					status = "disabled";
+				};
+
+				pcie at 4,0 {
+					device_type = "pci";
+					assigned-addresses = <0x82000800 0 0x4c000 0 0x2000>;
+					reg = <0x2000 0 0 0 0>;
+					#address-cells = <3>;
+					#size-cells = <2>;
+					#interrupt-cells = <1>;
+					ranges;
+					interrupt-map-mask = <0 0 0 0>;
+					interrupt-map = <0 0 0 0 &mpic 61>;
+					marvell,pcie-port = <0>;
+					marvell,pcie-lane = <3>;
+					clocks = <&gateclk 8>;
+					status = "disabled";
+				};
+
+				pcie at 9,0 {
+					device_type = "pci";
+					assigned-addresses = <0x82000800 0 0x42000 0 0x2000>;
+					reg = <0x4800 0 0 0 0>;
+					#address-cells = <3>;
+					#size-cells = <2>;
+					#interrupt-cells = <1>;
+					ranges;
+					interrupt-map-mask = <0 0 0 0>;
+					interrupt-map = <0 0 0 0 &mpic 99>;
+					marvell,pcie-port = <2>;
+					marvell,pcie-lane = <0>;
+					clocks = <&gateclk 26>;
+					status = "disabled";
+				};
+
+				pcie at 10,0 {
+					device_type = "pci";
+					assigned-addresses = <0x82000800 0 0x82000 0 0x2000>;
+					reg = <0x5000 0 0 0 0>;
+					#address-cells = <3>;
+					#size-cells = <2>;
+					#interrupt-cells = <1>;
+					ranges;
+					interrupt-map-mask = <0 0 0 0>;
+					interrupt-map = <0 0 0 0 &mpic 103>;
+					marvell,pcie-port = <3>;
+					marvell,pcie-lane = <0>;
+					clocks = <&gateclk 27>;
+					status = "disabled";
+				};
 			};
 		};
 	};
diff --git a/arch/arm/boot/dts/armada-xp-mv78460.dtsi b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
index ce4f80a..6ab56bd 100644
--- a/arch/arm/boot/dts/armada-xp-mv78460.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
@@ -60,243 +60,245 @@
 	};
 
 	soc {
-		pinctrl {
-			compatible = "marvell,mv78460-pinctrl";
-			reg = <0x18000 0x38>;
+		internal-regs {
+			pinctrl {
+				compatible = "marvell,mv78460-pinctrl";
+				reg = <0x18000 0x38>;
 
-			sdio_pins: sdio-pins {
-				marvell,pins = "mpp30", "mpp31", "mpp32",
-					       "mpp33", "mpp34", "mpp35";
-				marvell,function = "sd0";
+				sdio_pins: sdio-pins {
+					marvell,pins = "mpp30", "mpp31", "mpp32",
+						       "mpp33", "mpp34", "mpp35";
+					marvell,function = "sd0";
+				};
 			};
-		};
 
-		gpio0: gpio at 18100 {
-			compatible = "marvell,orion-gpio";
-			reg = <0x18100 0x40>;
-			ngpios = <32>;
-			gpio-controller;
-			#gpio-cells = <2>;
-			interrupt-controller;
-			#interrupts-cells = <2>;
-			interrupts = <82>, <83>, <84>, <85>;
-		};
+			gpio0: gpio at 18100 {
+				compatible = "marvell,orion-gpio";
+				reg = <0x18100 0x40>;
+				ngpios = <32>;
+				gpio-controller;
+				#gpio-cells = <2>;
+				interrupt-controller;
+				#interrupts-cells = <2>;
+				interrupts = <82>, <83>, <84>, <85>;
+			};
 
-		gpio1: gpio at 18140 {
-			compatible = "marvell,orion-gpio";
-			reg = <0x18140 0x40>;
-			ngpios = <32>;
-			gpio-controller;
-			#gpio-cells = <2>;
-			interrupt-controller;
-			#interrupts-cells = <2>;
-			interrupts = <87>, <88>, <89>, <90>;
-		};
+			gpio1: gpio at 18140 {
+				compatible = "marvell,orion-gpio";
+				reg = <0x18140 0x40>;
+				ngpios = <32>;
+				gpio-controller;
+				#gpio-cells = <2>;
+				interrupt-controller;
+				#interrupts-cells = <2>;
+				interrupts = <87>, <88>, <89>, <90>;
+			};
 
-		gpio2: gpio at 18180 {
-			compatible = "marvell,orion-gpio";
-			reg = <0x18180 0x40>;
-			ngpios = <3>;
-			gpio-controller;
-			#gpio-cells = <2>;
-			interrupt-controller;
-			#interrupts-cells = <2>;
-			interrupts = <91>;
-		};
+			gpio2: gpio at 18180 {
+				compatible = "marvell,orion-gpio";
+				reg = <0x18180 0x40>;
+				ngpios = <3>;
+				gpio-controller;
+				#gpio-cells = <2>;
+				interrupt-controller;
+				#interrupts-cells = <2>;
+				interrupts = <91>;
+			};
 
-		ethernet at 34000 {
+			ethernet at 34000 {
 				compatible = "marvell,armada-370-neta";
 				reg = <0x34000 0x2500>;
 				interrupts = <14>;
 				clocks = <&gateclk 1>;
 				status = "disabled";
-		};
+			};
 
-		/*
-		 * MV78460 has 4 PCIe units Gen2.0: Two units can be
-		 * configured as x4 or quad x1 lanes. Two units are
-		 * x4/x1.
-		 */
-		pcie-controller {
-			compatible = "marvell,armada-xp-pcie";
-			status = "disabled";
-			device_type = "pci";
+			/*
+			 * MV78460 has 4 PCIe units Gen2.0: Two units can be
+			 * configured as x4 or quad x1 lanes. Two units are
+			 * x4/x1.
+			 */
+			pcie-controller {
+				compatible = "marvell,armada-xp-pcie";
+				status = "disabled";
+				device_type = "pci";
 
-			#address-cells = <3>;
-			#size-cells = <2>;
+				#address-cells = <3>;
+				#size-cells = <2>;
 
-			bus-range = <0x00 0xff>;
+				bus-range = <0x00 0xff>;
 
-			ranges = <0x82000000 0 0x40000 0x40000 0 0x00002000   /* Port 0.0 registers */
-				  0x82000000 0 0x42000 0x42000 0 0x00002000   /* Port 2.0 registers */
-				  0x82000000 0 0x44000 0x44000 0 0x00002000   /* Port 0.1 registers */
-				  0x82000000 0 0x48000 0x48000 0 0x00002000   /* Port 0.2 registers */
-				  0x82000000 0 0x4c000 0x4c000 0 0x00002000   /* Port 0.3 registers */
-				  0x82000000 0 0x80000 0x80000 0 0x00002000   /* Port 1.0 registers */
-				  0x82000000 0 0x82000 0x82000 0 0x00002000   /* Port 3.0 registers */
-				  0x82000000 0 0x84000 0x84000 0 0x00002000   /* Port 1.1 registers */
-				  0x82000000 0 0x88000 0x88000 0 0x00002000   /* Port 1.2 registers */
-				  0x82000000 0 0x8c000 0x8c000 0 0x00002000   /* Port 1.3 registers */
-				  0x82000000 0 0xe0000000 0xe0000000 0 0x08000000   /* non-prefetchable memory */
-				  0x81000000 0 0	  0xe8000000 0 0x00100000>; /* downstream I/O */
+				ranges = <0x82000000 0 0x40000 0x40000 0 0x00002000   /* Port 0.0 registers */
+					0x82000000 0 0x42000 0x42000 0 0x00002000   /* Port 2.0 registers */
+					0x82000000 0 0x44000 0x44000 0 0x00002000   /* Port 0.1 registers */
+					0x82000000 0 0x48000 0x48000 0 0x00002000   /* Port 0.2 registers */
+					0x82000000 0 0x4c000 0x4c000 0 0x00002000   /* Port 0.3 registers */
+					0x82000000 0 0x80000 0x80000 0 0x00002000   /* Port 1.0 registers */
+					0x82000000 0 0x82000 0x82000 0 0x00002000   /* Port 3.0 registers */
+					0x82000000 0 0x84000 0x84000 0 0x00002000   /* Port 1.1 registers */
+					0x82000000 0 0x88000 0x88000 0 0x00002000   /* Port 1.2 registers */
+					0x82000000 0 0x8c000 0x8c000 0 0x00002000   /* Port 1.3 registers */
+					0x82000000 0 0xe0000000 0xe0000000 0 0x08000000   /* non-prefetchable memory */
+					0x81000000 0 0	  0xe8000000 0 0x00100000>; /* downstream I/O */
 
-			pcie at 1,0 {
-				device_type = "pci";
-				assigned-addresses = <0x82000800 0 0x40000 0 0x2000>;
-				reg = <0x0800 0 0 0 0>;
-				#address-cells = <3>;
-				#size-cells = <2>;
-				#interrupt-cells = <1>;
-				ranges;
-				interrupt-map-mask = <0 0 0 0>;
-				interrupt-map = <0 0 0 0 &mpic 58>;
-				marvell,pcie-port = <0>;
-				marvell,pcie-lane = <0>;
-				clocks = <&gateclk 5>;
-				status = "disabled";
-			};
+				pcie at 1,0 {
+					device_type = "pci";
+					assigned-addresses = <0x82000800 0 0x40000 0 0x2000>;
+					reg = <0x0800 0 0 0 0>;
+					#address-cells = <3>;
+					#size-cells = <2>;
+					#interrupt-cells = <1>;
+					ranges;
+					interrupt-map-mask = <0 0 0 0>;
+					interrupt-map = <0 0 0 0 &mpic 58>;
+					marvell,pcie-port = <0>;
+					marvell,pcie-lane = <0>;
+					clocks = <&gateclk 5>;
+					status = "disabled";
+				};
 
-			pcie at 2,0 {
-				device_type = "pci";
-				assigned-addresses = <0x82001000 0 0x44000 0 0x2000>;
-				reg = <0x1000 0 0 0 0>;
-				#address-cells = <3>;
-				#size-cells = <2>;
-				#interrupt-cells = <1>;
-				ranges;
-				interrupt-map-mask = <0 0 0 0>;
-				interrupt-map = <0 0 0 0 &mpic 59>;
-				marvell,pcie-port = <0>;
-				marvell,pcie-lane = <1>;
-				clocks = <&gateclk 6>;
-				status = "disabled";
-			};
+				pcie at 2,0 {
+					device_type = "pci";
+					assigned-addresses = <0x82001000 0 0x44000 0 0x2000>;
+					reg = <0x1000 0 0 0 0>;
+					#address-cells = <3>;
+					#size-cells = <2>;
+					#interrupt-cells = <1>;
+					ranges;
+					interrupt-map-mask = <0 0 0 0>;
+					interrupt-map = <0 0 0 0 &mpic 59>;
+					marvell,pcie-port = <0>;
+					marvell,pcie-lane = <1>;
+					clocks = <&gateclk 6>;
+					status = "disabled";
+				};
 
-			pcie at 3,0 {
-				device_type = "pci";
-				assigned-addresses = <0x82001800 0 0x48000 0 0x2000>;
-				reg = <0x1800 0 0 0 0>;
-				#address-cells = <3>;
-				#size-cells = <2>;
-				#interrupt-cells = <1>;
-				ranges;
-				interrupt-map-mask = <0 0 0 0>;
-				interrupt-map = <0 0 0 0 &mpic 60>;
-				marvell,pcie-port = <0>;
-				marvell,pcie-lane = <2>;
-				clocks = <&gateclk 7>;
-				status = "disabled";
-			};
+				pcie at 3,0 {
+					device_type = "pci";
+					assigned-addresses = <0x82001800 0 0x48000 0 0x2000>;
+					reg = <0x1800 0 0 0 0>;
+					#address-cells = <3>;
+					#size-cells = <2>;
+					#interrupt-cells = <1>;
+					ranges;
+					interrupt-map-mask = <0 0 0 0>;
+					interrupt-map = <0 0 0 0 &mpic 60>;
+					marvell,pcie-port = <0>;
+					marvell,pcie-lane = <2>;
+					clocks = <&gateclk 7>;
+					status = "disabled";
+				};
 
-			pcie at 4,0 {
-				device_type = "pci";
-				assigned-addresses = <0x82002000 0 0x4c000 0 0x2000>;
-				reg = <0x2000 0 0 0 0>;
-				#address-cells = <3>;
-				#size-cells = <2>;
-				#interrupt-cells = <1>;
-				ranges;
-				interrupt-map-mask = <0 0 0 0>;
-				interrupt-map = <0 0 0 0 &mpic 61>;
-				marvell,pcie-port = <0>;
-				marvell,pcie-lane = <3>;
-				clocks = <&gateclk 8>;
-				status = "disabled";
-			};
+				pcie at 4,0 {
+					device_type = "pci";
+					assigned-addresses = <0x82002000 0 0x4c000 0 0x2000>;
+					reg = <0x2000 0 0 0 0>;
+					#address-cells = <3>;
+					#size-cells = <2>;
+					#interrupt-cells = <1>;
+					ranges;
+					interrupt-map-mask = <0 0 0 0>;
+					interrupt-map = <0 0 0 0 &mpic 61>;
+					marvell,pcie-port = <0>;
+					marvell,pcie-lane = <3>;
+					clocks = <&gateclk 8>;
+					status = "disabled";
+				};
 
-			pcie at 5,0 {
-				device_type = "pci";
-				assigned-addresses = <0x82002800 0 0x80000 0 0x2000>;
-				reg = <0x2800 0 0 0 0>;
-				#address-cells = <3>;
-				#size-cells = <2>;
-				#interrupt-cells = <1>;
-				ranges;
-				interrupt-map-mask = <0 0 0 0>;
-				interrupt-map = <0 0 0 0 &mpic 62>;
-				marvell,pcie-port = <1>;
-				marvell,pcie-lane = <0>;
-				clocks = <&gateclk 9>;
-				status = "disabled";
-			};
+				pcie at 5,0 {
+					device_type = "pci";
+					assigned-addresses = <0x82002800 0 0x80000 0 0x2000>;
+					reg = <0x2800 0 0 0 0>;
+					#address-cells = <3>;
+					#size-cells = <2>;
+					#interrupt-cells = <1>;
+					ranges;
+					interrupt-map-mask = <0 0 0 0>;
+					interrupt-map = <0 0 0 0 &mpic 62>;
+					marvell,pcie-port = <1>;
+					marvell,pcie-lane = <0>;
+					clocks = <&gateclk 9>;
+					status = "disabled";
+				};
 
-			pcie at 6,0 {
-				device_type = "pci";
-				assigned-addresses = <0x82003000 0 0x84000 0 0x2000>;
-				reg = <0x3000 0 0 0 0>;
-				#address-cells = <3>;
-				#size-cells = <2>;
-				#interrupt-cells = <1>;
-				ranges;
-				interrupt-map-mask = <0 0 0 0>;
-				interrupt-map = <0 0 0 0 &mpic 63>;
-				marvell,pcie-port = <1>;
-				marvell,pcie-lane = <1>;
-				clocks = <&gateclk 10>;
-				status = "disabled";
-			};
+				pcie at 6,0 {
+					device_type = "pci";
+					assigned-addresses = <0x82003000 0 0x84000 0 0x2000>;
+					reg = <0x3000 0 0 0 0>;
+					#address-cells = <3>;
+					#size-cells = <2>;
+					#interrupt-cells = <1>;
+					ranges;
+					interrupt-map-mask = <0 0 0 0>;
+					interrupt-map = <0 0 0 0 &mpic 63>;
+					marvell,pcie-port = <1>;
+					marvell,pcie-lane = <1>;
+					clocks = <&gateclk 10>;
+					status = "disabled";
+				};
 
-			pcie at 7,0 {
-				device_type = "pci";
-				assigned-addresses = <0x82003800 0 0x88000 0 0x2000>;
-				reg = <0x3800 0 0 0 0>;
-				#address-cells = <3>;
-				#size-cells = <2>;
-				#interrupt-cells = <1>;
-				ranges;
-				interrupt-map-mask = <0 0 0 0>;
-				interrupt-map = <0 0 0 0 &mpic 64>;
-				marvell,pcie-port = <1>;
-				marvell,pcie-lane = <2>;
-				clocks = <&gateclk 11>;
-				status = "disabled";
-			};
+				pcie at 7,0 {
+					device_type = "pci";
+					assigned-addresses = <0x82003800 0 0x88000 0 0x2000>;
+					reg = <0x3800 0 0 0 0>;
+					#address-cells = <3>;
+					#size-cells = <2>;
+					#interrupt-cells = <1>;
+					ranges;
+					interrupt-map-mask = <0 0 0 0>;
+					interrupt-map = <0 0 0 0 &mpic 64>;
+					marvell,pcie-port = <1>;
+					marvell,pcie-lane = <2>;
+					clocks = <&gateclk 11>;
+					status = "disabled";
+				};
 
-			pcie at 8,0 {
-				device_type = "pci";
-				assigned-addresses = <0x82004000 0 0x8c000 0 0x2000>;
-				reg = <0x4000 0 0 0 0>;
-				#address-cells = <3>;
-				#size-cells = <2>;
-				#interrupt-cells = <1>;
-				ranges;
-				interrupt-map-mask = <0 0 0 0>;
-				interrupt-map = <0 0 0 0 &mpic 65>;
-				marvell,pcie-port = <1>;
-				marvell,pcie-lane = <3>;
-				clocks = <&gateclk 12>;
-				status = "disabled";
-			};
-			pcie at 9,0 {
-				device_type = "pci";
-				assigned-addresses = <0x82004800 0 0x42000 0 0x2000>;
-				reg = <0x4800 0 0 0 0>;
-				#address-cells = <3>;
-				#size-cells = <2>;
-				#interrupt-cells = <1>;
-				ranges;
-				interrupt-map-mask = <0 0 0 0>;
-				interrupt-map = <0 0 0 0 &mpic 99>;
-				marvell,pcie-port = <2>;
-				marvell,pcie-lane = <0>;
-				clocks = <&gateclk 26>;
-				status = "disabled";
-			};
+				pcie at 8,0 {
+					device_type = "pci";
+					assigned-addresses = <0x82004000 0 0x8c000 0 0x2000>;
+					reg = <0x4000 0 0 0 0>;
+					#address-cells = <3>;
+					#size-cells = <2>;
+					#interrupt-cells = <1>;
+					ranges;
+					interrupt-map-mask = <0 0 0 0>;
+					interrupt-map = <0 0 0 0 &mpic 65>;
+					marvell,pcie-port = <1>;
+					marvell,pcie-lane = <3>;
+					clocks = <&gateclk 12>;
+					status = "disabled";
+				};
+				pcie at 9,0 {
+					device_type = "pci";
+					assigned-addresses = <0x82004800 0 0x42000 0 0x2000>;
+					reg = <0x4800 0 0 0 0>;
+					#address-cells = <3>;
+					#size-cells = <2>;
+					#interrupt-cells = <1>;
+					ranges;
+					interrupt-map-mask = <0 0 0 0>;
+					interrupt-map = <0 0 0 0 &mpic 99>;
+					marvell,pcie-port = <2>;
+					marvell,pcie-lane = <0>;
+					clocks = <&gateclk 26>;
+					status = "disabled";
+				};
 
-			pcie at 10,0 {
-				device_type = "pci";
-				assigned-addresses = <0x82005000 0 0x82000 0 0x2000>;
-				reg = <0x5000 0 0 0 0>;
-				#address-cells = <3>;
-				#size-cells = <2>;
-				#interrupt-cells = <1>;
-				ranges;
-				interrupt-map-mask = <0 0 0 0>;
-				interrupt-map = <0 0 0 0 &mpic 103>;
-				marvell,pcie-port = <3>;
-				marvell,pcie-lane = <0>;
-				clocks = <&gateclk 27>;
-				status = "disabled";
+				pcie at 10,0 {
+					device_type = "pci";
+					assigned-addresses = <0x82005000 0 0x82000 0 0x2000>;
+					reg = <0x5000 0 0 0 0>;
+					#address-cells = <3>;
+					#size-cells = <2>;
+					#interrupt-cells = <1>;
+					ranges;
+					interrupt-map-mask = <0 0 0 0>;
+					interrupt-map = <0 0 0 0 &mpic 103>;
+					marvell,pcie-port = <3>;
+					marvell,pcie-lane = <0>;
+					clocks = <&gateclk 27>;
+					status = "disabled";
+				};
 			};
 		};
 	};
diff --git a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
index e9bc8bf..15a66a8 100644
--- a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
+++ b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
@@ -27,154 +27,156 @@
 	};
 
 	soc {
-		serial at 12000 {
-			clock-frequency = <250000000>;
-			status = "okay";
-		};
-		serial at 12100 {
-			clock-frequency = <250000000>;
-			status = "okay";
-		};
-		pinctrl {
-			led_pins: led-pins-0 {
-				marvell,pins = "mpp49", "mpp51", "mpp53";
-				marvell,function = "gpio";
+		internal-regs {
+			serial at 12000 {
+				clock-frequency = <250000000>;
+				status = "okay";
 			};
-		};
-		leds {
-			compatible = "gpio-leds";
-			pinctrl-names = "default";
-			pinctrl-0 = <&led_pins>;
-
-			red_led {
-				label = "red_led";
-				gpios = <&gpio1 17 1>;
-				default-state = "off";
+			serial at 12100 {
+				clock-frequency = <250000000>;
+				status = "okay";
 			};
-
-			yellow_led {
-				label = "yellow_led";
-				gpios = <&gpio1 19 1>;
-				default-state = "off";
+			pinctrl {
+				led_pins: led-pins-0 {
+					marvell,pins = "mpp49", "mpp51", "mpp53";
+					marvell,function = "gpio";
+				};
 			};
-
-			green_led {
-				label = "green_led";
-				gpios = <&gpio1 21 1>;
-				default-state = "off";
-				linux,default-trigger = "heartbeat";
+			leds {
+				compatible = "gpio-leds";
+				pinctrl-names = "default";
+				pinctrl-0 = <&led_pins>;
+
+				red_led {
+					label = "red_led";
+					gpios = <&gpio1 17 1>;
+					default-state = "off";
+				};
+
+				yellow_led {
+					label = "yellow_led";
+					gpios = <&gpio1 19 1>;
+					default-state = "off";
+				};
+
+				green_led {
+					label = "green_led";
+					gpios = <&gpio1 21 1>;
+					default-state = "off";
+					linux,default-trigger = "heartbeat";
+				};
 			};
-		};
 
-		gpio_keys {
-			compatible = "gpio-keys";
-			#address-cells = <1>;
-			#size-cells = <0>;
+			gpio_keys {
+				compatible = "gpio-keys";
+				#address-cells = <1>;
+				#size-cells = <0>;
 
-			button at 1 {
-				label = "Init Button";
-				linux,code = <116>;
-				gpios = <&gpio1 28 0>;
+				button at 1 {
+					label = "Init Button";
+					linux,code = <116>;
+					gpios = <&gpio1 28 0>;
+				};
 			};
-		};
 
-		mdio {
-			phy0: ethernet-phy at 0 {
-				reg = <0>;
-			};
+			mdio {
+				phy0: ethernet-phy at 0 {
+					reg = <0>;
+				};
 
-			phy1: ethernet-phy at 1 {
-				reg = <1>;
-			};
+				phy1: ethernet-phy at 1 {
+					reg = <1>;
+				};
 
-			phy2: ethernet-phy at 2 {
-				reg = <2>;
-			};
+				phy2: ethernet-phy at 2 {
+					reg = <2>;
+				};
 
-			phy3: ethernet-phy at 3 {
-				reg = <3>;
+				phy3: ethernet-phy at 3 {
+					reg = <3>;
+				};
 			};
-		};
 
-		ethernet at 70000 {
-			status = "okay";
-			phy = <&phy0>;
-			phy-mode = "sgmii";
-		};
-		ethernet at 74000 {
-			status = "okay";
-			phy = <&phy1>;
-			phy-mode = "sgmii";
-		};
-		ethernet at 30000 {
-			status = "okay";
-			phy = <&phy2>;
-			phy-mode = "sgmii";
-		};
-		ethernet at 34000 {
-			status = "okay";
-			phy = <&phy3>;
-			phy-mode = "sgmii";
-		};
-		i2c at 11000 {
-			status = "okay";
-			clock-frequency = <400000>;
-		};
-		i2c at 11100 {
-			status = "okay";
-			clock-frequency = <400000>;
+			ethernet at 70000 {
+				status = "okay";
+				phy = <&phy0>;
+				phy-mode = "sgmii";
+			};
+			ethernet at 74000 {
+				status = "okay";
+				phy = <&phy1>;
+				phy-mode = "sgmii";
+			};
+			ethernet at 30000 {
+				status = "okay";
+				phy = <&phy2>;
+				phy-mode = "sgmii";
+			};
+			ethernet at 34000 {
+				status = "okay";
+				phy = <&phy3>;
+				phy-mode = "sgmii";
+			};
+			i2c at 11000 {
+				status = "okay";
+				clock-frequency = <400000>;
+			};
+			i2c at 11100 {
+				status = "okay";
+				clock-frequency = <400000>;
 
-			s35390a: s35390a at 30 {
-				compatible = "s35390a";
-				reg = <0x30>;
+				s35390a: s35390a at 30 {
+					compatible = "s35390a";
+					reg = <0x30>;
+				};
+			};
+			sata at a0000 {
+				nr-ports = <2>;
+				status = "okay";
+			};
+			usb at 50000 {
+				status = "okay";
+			};
+			usb at 51000 {
+				status = "okay";
 			};
-		};
-		sata at a0000 {
-			nr-ports = <2>;
-			status = "okay";
-		};
-		usb at 50000 {
-			status = "okay";
-		};
-		usb at 51000 {
-			status = "okay";
-		};
 
-		devbus-bootcs at 10400 {
-			status = "okay";
-			ranges = <0 0xf0000000 0x8000000>; /* @addr 0xf000000, size 0x8000000 */
-
-			/* Device Bus parameters are required */
-
-			/* Read parameters */
-			devbus,bus-width    = <8>;
-			devbus,turn-off-ps  = <60000>;
-			devbus,badr-skew-ps = <0>;
-			devbus,acc-first-ps = <124000>;
-			devbus,acc-next-ps  = <248000>;
-			devbus,rd-setup-ps  = <0>;
-			devbus,rd-hold-ps   = <0>;
-
-			/* Write parameters */
-			devbus,sync-enable = <0>;
-			devbus,wr-high-ps  = <60000>;
-			devbus,wr-low-ps   = <60000>;
-			devbus,ale-wr-ps   = <60000>;
-
-			/* NOR 128 MiB */
-			nor at 0 {
-				compatible = "cfi-flash";
-				reg = <0 0x8000000>;
-				bank-width = <2>;
+			devbus-bootcs at 10400 {
+				status = "okay";
+				ranges = <0 0xf0000000 0x8000000>; /* @addr 0xf000000, size 0x8000000 */
+
+				/* Device Bus parameters are required */
+
+				/* Read parameters */
+				devbus,bus-width    = <8>;
+				devbus,turn-off-ps  = <60000>;
+				devbus,badr-skew-ps = <0>;
+				devbus,acc-first-ps = <124000>;
+				devbus,acc-next-ps  = <248000>;
+				devbus,rd-setup-ps  = <0>;
+				devbus,rd-hold-ps   = <0>;
+
+				/* Write parameters */
+				devbus,sync-enable = <0>;
+				devbus,wr-high-ps  = <60000>;
+				devbus,wr-low-ps   = <60000>;
+				devbus,ale-wr-ps   = <60000>;
+
+				/* NOR 128 MiB */
+				nor at 0 {
+					compatible = "cfi-flash";
+					reg = <0 0x8000000>;
+					bank-width = <2>;
+				};
 			};
-		};
 
-		pcie-controller {
-			status = "okay";
-			/* Internal mini-PCIe connector */
-			pcie at 1,0 {
-				/* Port 0, Lane 0 */
+			pcie-controller {
 				status = "okay";
+				/* Internal mini-PCIe connector */
+				pcie at 1,0 {
+					/* Port 0, Lane 0 */
+					status = "okay";
+				};
 			};
 		};
 	};
diff --git a/arch/arm/boot/dts/armada-xp.dtsi b/arch/arm/boot/dts/armada-xp.dtsi
index 465b9fa..bacab11 100644
--- a/arch/arm/boot/dts/armada-xp.dtsi
+++ b/arch/arm/boot/dts/armada-xp.dtsi
@@ -22,141 +22,140 @@
 	model = "Marvell Armada XP family SoC";
 	compatible = "marvell,armadaxp", "marvell,armada-370-xp";
 
-
 	soc {
-		L2: l2-cache {
-			compatible = "marvell,aurora-system-cache";
-			reg = <0x08000 0x1000>;
-			cache-id-part = <0x100>;
-			wt-override;
-		};
+		internal-regs {
+			L2: l2-cache {
+				compatible = "marvell,aurora-system-cache";
+				reg = <0x08000 0x1000>;
+				cache-id-part = <0x100>;
+				wt-override;
+			};
 
-		mpic: interrupt-controller at 20000 {
-		      reg = <0x20a00 0x2d0>,
-			    <0x21070 0x58>;
-		};
+			mpic: interrupt-controller at 20000 {
+			      reg = <0x20a00 0x2d0>, <0x21070 0x58>;
+			};
 
-		armada-370-xp-pmsu at 22000 {
-			compatible = "marvell,armada-370-xp-pmsu";
-			reg = <0x22100 0x430>,
-			      <0x20800 0x20>;
-		};
+			armada-370-xp-pmsu at 22000 {
+				compatible = "marvell,armada-370-xp-pmsu";
+				reg = <0x22100 0x430>, <0x20800 0x20>;
+			};
 
-		serial at 12200 {
+			serial at 12200 {
 				compatible = "snps,dw-apb-uart";
 				reg = <0x12200 0x100>;
 				reg-shift = <2>;
 				interrupts = <43>;
 				reg-io-width = <1>;
 				status = "disabled";
-		};
-		serial at 12300 {
+			};
+			serial at 12300 {
 				compatible = "snps,dw-apb-uart";
 				reg = <0x12300 0x100>;
 				reg-shift = <2>;
 				interrupts = <44>;
 				reg-io-width = <1>;
 				status = "disabled";
-		};
+			};
 
-		timer at 20300 {
+			timer at 20300 {
 				marvell,timer-25Mhz;
-		};
+			};
 
-		coreclk: mvebu-sar at 18230 {
-			compatible = "marvell,armada-xp-core-clock";
-			reg = <0x18230 0x08>;
-			#clock-cells = <1>;
-		};
+			coreclk: mvebu-sar at 18230 {
+				compatible = "marvell,armada-xp-core-clock";
+				reg = <0x18230 0x08>;
+				#clock-cells = <1>;
+			};
 
-		cpuclk: clock-complex at 18700 {
-			#clock-cells = <1>;
-			compatible = "marvell,armada-xp-cpu-clock";
-			reg = <0x18700 0xA0>;
-			clocks = <&coreclk 1>;
-		};
+			cpuclk: clock-complex at 18700 {
+				#clock-cells = <1>;
+				compatible = "marvell,armada-xp-cpu-clock";
+				reg = <0x18700 0xA0>;
+				clocks = <&coreclk 1>;
+			};
 
-		gateclk: clock-gating-control at 18220 {
-			compatible = "marvell,armada-xp-gating-clock";
-			reg = <0x18220 0x4>;
-			clocks = <&coreclk 0>;
-			#clock-cells = <1>;
-		};
+			gateclk: clock-gating-control at 18220 {
+				compatible = "marvell,armada-xp-gating-clock";
+				reg = <0x18220 0x4>;
+				clocks = <&coreclk 0>;
+				#clock-cells = <1>;
+			};
 
-		system-controller at 18200 {
+			system-controller at 18200 {
 				compatible = "marvell,armada-370-xp-system-controller";
 				reg = <0x18200 0x500>;
-		};
+			};
 
-		ethernet at 30000 {
+			ethernet at 30000 {
 				compatible = "marvell,armada-370-neta";
 				reg = <0x30000 0x2500>;
 				interrupts = <12>;
 				clocks = <&gateclk 2>;
 				status = "disabled";
-		};
-
-		xor at 60900 {
-			compatible = "marvell,orion-xor";
-			reg = <0x60900 0x100
-			       0x60b00 0x100>;
-			clocks = <&gateclk 22>;
-			status = "okay";
-
-			xor10 {
-				interrupts = <51>;
-				dmacap,memcpy;
-				dmacap,xor;
 			};
-			xor11 {
-				interrupts = <52>;
-				dmacap,memcpy;
-				dmacap,xor;
-				dmacap,memset;
-			};
-		};
 
-		xor at f0900 {
-			compatible = "marvell,orion-xor";
-			reg = <0xF0900 0x100
-			       0xF0B00 0x100>;
-			clocks = <&gateclk 28>;
-			status = "okay";
-
-			xor00 {
-				interrupts = <94>;
-				dmacap,memcpy;
-				dmacap,xor;
+			xor at 60900 {
+				compatible = "marvell,orion-xor";
+				reg = <0x60900 0x100
+				       0x60b00 0x100>;
+				clocks = <&gateclk 22>;
+				status = "okay";
+
+				xor10 {
+					interrupts = <51>;
+					dmacap,memcpy;
+					dmacap,xor;
+				};
+				xor11 {
+					interrupts = <52>;
+					dmacap,memcpy;
+					dmacap,xor;
+					dmacap,memset;
+				};
 			};
-			xor01 {
-				interrupts = <95>;
-				dmacap,memcpy;
-				dmacap,xor;
-				dmacap,memset;
+
+			xor at f0900 {
+				compatible = "marvell,orion-xor";
+				reg = <0xF0900 0x100
+				       0xF0B00 0x100>;
+				clocks = <&gateclk 28>;
+				status = "okay";
+
+				xor00 {
+					interrupts = <94>;
+					dmacap,memcpy;
+					dmacap,xor;
+				};
+				xor01 {
+					interrupts = <95>;
+					dmacap,memcpy;
+					dmacap,xor;
+					dmacap,memset;
+				};
 			};
-		};
 
-		usb at 50000 {
-			clocks = <&gateclk 18>;
-		};
+			usb at 50000 {
+				clocks = <&gateclk 18>;
+			};
 
-		usb at 51000 {
-			clocks = <&gateclk 19>;
-		};
+			usb at 51000 {
+				clocks = <&gateclk 19>;
+			};
 
-		usb at 52000 {
-			compatible = "marvell,orion-ehci";
-			reg = <0x52000 0x500>;
-			interrupts = <47>;
-			clocks = <&gateclk 20>;
-			status = "disabled";
-		};
+			usb at 52000 {
+				compatible = "marvell,orion-ehci";
+				reg = <0x52000 0x500>;
+				interrupts = <47>;
+				clocks = <&gateclk 20>;
+				status = "disabled";
+			};
 
-		thermal at 182b0 {
-			compatible = "marvell,armadaxp-thermal";
-			reg = <0x182b0 0x4
-			       0x184d0 0x4>;
-			status = "okay";
+			thermal at 182b0 {
+				compatible = "marvell,armadaxp-thermal";
+				reg = <0x182b0 0x4
+					0x184d0 0x4>;
+				status = "okay";
+			};
 		};
 	};
 };
-- 
1.7.9.5



From dave.martin at linaro.org  Fri Apr 12 10:36:44 2013
From: dave.martin at linaro.org (Dave Martin)
Date: Fri, 12 Apr 2013 15:36:44 +0100
Subject: [RFC PATCH 01/11] Documentation: DT: arm: define CPU topology
 bindings
In-Reply-To: <20130412114457.GC6637@e102568-lin.cambridge.arm.com>
References: <1365671562-2403-1-git-send-email-mark.rutland@arm.com>
 <1365671562-2403-2-git-send-email-mark.rutland@arm.com>
 <5166D01F.5070404@gmail.com>
 <20130411155054.GA29509@e102568-lin.cambridge.arm.com>
 <20130411180125.GB2239@linaro.org>
 <20130412114457.GC6637@e102568-lin.cambridge.arm.com>
Message-ID: <20130412143644.GB2992@linaro.org>

On Fri, Apr 12, 2013 at 12:44:58PM +0100, Lorenzo Pieralisi wrote:
> On Thu, Apr 11, 2013 at 07:01:25PM +0100, Dave Martin wrote:
> 
> [...]
> 
> > > > > +===========================================
> > > > > +2 - cpu-map node
> > > > > +===========================================
> > > > > +
> > > > > +The ARM CPU topology is defined within a container node, sitting at the top
> > > > > +level of the device tree (/), the cpu-map node.
> > > > > +
> > > > > +- cpu-map node
> > > > > +
> > > > > + Usage: Required to define ARM CPU topology
> > > > > +
> > > > > + Description: The cpu-map node is just a container node where its
> > > > > +              subnodes describe the CPU topology
> > > > > +
> > > > > + Node name must be "cpu-map".
> > > > > +
> > > > > + A cpu-map node's child nodes can be:
> > > > > +
> > > > > + - one or more cluster nodes
> > > > > +
> > > > > + Any other configuration is considered invalid.
> > > > > +
> > > > > +The cpu-map node can only contain three types of child nodes:
> > > > > +
> > > > > +- cluster node
> > > > > +- core node
> > > > > +- thread node
> > > > > +
> > > >
> > > > Why not put the topology in the /cpus nodes? I don't really see the
> > > > point of having a flat list of cpus and separate topology info. There is
> > > > some compatibility issue, but adding optional levels for clusters can be
> > > > handled.
> > >
> > > I thought this would break all code relying on /cpu nodes being /cpus node's
> > > children. Furthermore, I was told that the /cpus node can only have /cpu nodes
> > > as children.
> > >
> > > If you wish so, we can define the topology in the /cpus node, fine by me.
> > 
> > Can we make such extensive changes to the cpus node without violating
> > the ePAPR specification?
> > 
> > If we can, great, but I'm a but unclear on how this would be achieved.
> 
> +1
> 
> > > > > +whose bindings are described in paragraph 3.
> > > > > +
> > > > > +The nodes describing the CPU topology (cluster/core/thread) can only be
> > > > > +defined within the cpu-map node.
> > > > > +Any other configuration is consider invalid and therefore must be ignored.
> > > > > +
> > > > > +===========================================
> > > > > +2.1 - cpu-map child nodes naming convention
> > > > > +===========================================
> > > > > +
> > > > > +cpu-map child nodes must follow a naming convention where the node name
> > > > > +must be "clusterN", "coreN", "threadN" depending on the node type (ie
> > > > > +cluster/core/thread) (where N = {0, 1, ...} is the node number; nodes which
> > > > > +are siblings within a single common parent node must be given a unique and
> > > > > +sequential N value, starting from 0).
> > > > > +cpu-map child nodes which do not share a common parent node can have the same
> > > > > +name (ie same number N as other cpu-map child nodes at different device tree
> > > > > +levels) since name uniqueness will be guaranteed by the device tree hierarchy.
> > > > > +
> > > > > +===========================================
> > > > > +3 - cluster/core/thread node bindings
> > > > > +===========================================
> > > > > +
> > > > > +Bindings for cluster/cpu/thread nodes are defined as follows:
> > > > > +
> > > > > +- cluster node
> > > > > +
> > > > > +  Description: must be declared within a cpu-map node, one node
> > > > > +               per cluster. A system can contain several layers of
> > > > > +               clustering and cluster nodes can be contained in parent
> > > > > +               cluster nodes.
> > > > > +
> > > > > + The cluster node name must be "clusterN" as described in 2.1 above.
> > > > > + A cluster node can not be a leaf node.
> > > >
> > > > Follow standard conventions with "cluster at N" and a reg property with the
> > > > number.
> > >
> > > We are defining the topology to decouple the cluster/core/thread concept
> > > from the MPIDR. Having a reg property in the cluster (and core) nodes
> > > would complicate things if that reg property must correspond to an MPIDR
> > > bitfield. If it is meant to be just an enumeration at a given device tree
> > > level, I am ok with changing that.
> > 
> > As a pure enumeration, I think that works fine.  It's more verbose
> > but also more conformant to DT conventions.  I'm not sure there's
> > another difference.
> > 
> > The proposed support for C preprocessing of dts files might provide a
> > way to help debloat this to some extent in dts source, while still
> > following the DT convention of using unit addresses and reg properties.
> > This will significantly increase the size of the FDT blob if the
> > number of CPUs is large.  I don't remember offhand if we have a limit
> > on the size of FDT we can cope with.  Finding ways to relax the limit
> > is a better solution than dodging round standards, though.  We can
> > cross that bridge when/if we come to it.
> 
> Well, that's a problem by itself, certainly adding a reg property to
> the cluster nodes will make it worse, but as you said still better that
> than dodging standards.
> 
> > >
> > > > > +
> > > > > + A cluster node's child nodes must be:
> > > > > +
> > > > > + - one or more cluster nodes; or
> > > > > + - one or more core nodes
> > > > > +
> > > > > + Any other configuration is considered invalid.
> > > > > +
> > > > > +- core node
> > > > > +
> > > > > + Description: must be declared in a cluster node, one node per core in
> > > > > +              the cluster. If the system does not support SMT, core
> > > > > +              nodes are leaf nodes, otherwise they become containers of
> > > > > +              thread nodes.
> > > > > +
> > > > > + The core node name must be "coreN" as described in 2.1 above.
> > > > > +
> > > > > + A core node must be a leaf node if SMT is not supported.
> > > > > +
> > > > > + Properties for core nodes that are leaf nodes:
> > > > > +
> > > > > + - cpu
> > > > > +         Usage: required
> > > > > +         Value type: <phandle>
> > > > > +         Definition: a phandle to the cpu node that corresponds to the
> > > > > +                     core node.
> > > > > +
> > > > > + If a core node is not a leaf node (CPUs supporting SMT) a core node's
> > > > > + child nodes can be:
> > > > > +
> > > > > + - one or more thread nodes
> > > > > +
> > > > > + Any other configuration is considered invalid.
> > > > > +
> > > > > +- thread node
> > > > > +
> > > > > + Description: must be declared in a core node, one node per thread
> > > > > +              in the core if the system supports SMT. Thread nodes are
> > > > > +              always leaf nodes in the device tree.
> > > > > +
> > > > > + The thread node name must be "threadN" as described in 2.1 above.
> > > > > +
> > > > > + A thread node must be a leaf node.
> > > > > +
> > > > > + A thread node must contain the following property:
> > > > > +
> > > > > + - cpu
> > > > > +         Usage: required
> > > > > +         Value type: <phandle>
> > > > > +         Definition: a phandle to the cpu node that corresponds to
> > > > > +                     the thread node.
> > > >
> > > >
> > > > According to the ePAPR, threads are represented by an array of ids for
> > > > reg property, not another cpu node. Why the deviation.
> > >
> > > It is not a cpu node, it is a phandle property named cpu. Can you point
> > > me to the ePAPR section where threads bindings are described please ? I have
> > > not managed to find these details, I am reading version 1.0.
> > 
> > For cpu/reg:
> > 
> > [1]     If a CPU supports more than one thread (i.e. multiple streams of
> >         execution) the reg property is an array with 1 element per
> >         thread. The #address-cells on the /cpus node specifies how many
> >         cells each element of the array takes. Software can determine
> >         the number of threads by dividing the size of reg by the parent
> >         node's #address-cells.
> > 
> > I had not previously been aware of this, but I see no reason not to
> > follow this convention.
> 
> I don't see a reason either, but this changes the current cpu node bindings
> for ARM. On the upside there are no SMT ARM platforms out there, so no
> backward compatibility to worry about.

Actually, I've had second thoughts about this, from discussion with Mark
et al.

The extent to which threads share stuff is not really architecturally
visible on ARM.  It will be visible in performance terms (i.e., scheduling
two threads of the same process on threads of on CPU will give better
performance than scheduling threads of different processes), but in
architectural terms still look like fully-fledged, independent CPUs.

I don't know enough about how SMT scheduling currently works in the
kernel to know how best to describe this situation to the kernel...


Anyway, for the ARM case, there is not much architectural difference
between threads within a CPU, and CPUs in a cluster.  At both topological
levels the siblings are independent.  At both levels, there is an advantage
in scheduling related threads topologically close to each other -- though
probably more so for threads in a CPU than CPUs in a cluster.

Also, threads are independent interrupt destinations.  If we want to
put flat lists of SMT threads inside CPU nodes, then we need an
extra means of describing interrupt affinities, different from the
way this is described for CPUs and clusters.  This is definitely
complexity.  I'm not sure if there is a related benefit.


> This would reduce the topology problem to where cluster nodes should be
> defined, either in the cpus node or a separate node (ie cpu-map :-)).
> 
> > Also:
> > [2]     If other more complex CPU topographies are designed, the binding
> >         for the CPU must describe the topography
> > 
> > 
> > That's rather less helpful, but the suggestion is clear enough in that
> > such information should be in the cpu node and specific to that CPU's
> > binding.  For ARM, we can have some global extensions to the CPU node.
> > 
> > The problems start when you want to refer to clusters and groups of
> > CPUs from other nodes.  Only individual cpu nodes can be places in
> > the cpus node, so there is no node for a phandle to point at.
> > 
> > If you want to describe how other things like power, clock and
> > coherency domains map to clusters and larger entities, things could
> > get pretty awkward.
> > 
> > Keeping the topology description separate allows all topological entities
> > to appear as addressable entities in the DT; otherwise, a cryptic
> > convention is needed.
> > 
> > 
> > Hybrid approaches might be possible, putting cpu nodes into /cpus, and
> > giving them a "parent" property where appropriate pointing at the
> > relevant cluster node, which we put elsewhere in the DT.
> 
> That's what I did, with a couple of twists:
> 
> http://lists.infradead.org/pipermail/linux-arm-kernel/2012-January/080873.html
> 
> I have no preference, time to make a decision though.

With the arguments above, I'm not sure this is really better than the
current proposal...

> 
> > I'm not sure whether any of these approaches is an awful lot less ugly
> > or more easy to handle than what it currently proposed though.
> 
> +1
> 
> > The global binding for all ARM CPUs would specify that the topology
> > is described by /cpu-map and its associated binding.  For my
> > interpretation of [2], this is a compliant approach.  ePAPR does not
> > specify _how_ the cpu node binding achieves a description of the
> > topography, just that it must achieve it.  There's no statement to
> > say that it must not involve other nodes or bindings.
> 
> Again, I think it all boils down to deciding where cluster nodes should
> live.

If we want to be able to describe affinities and other hardware linkages,
describing the real hardware units as nodes still feels "right".
ePAPR doesn't insist upon how this is done, so we do have choice.

The older/hybrid proposals seem to require different means of describing
linkage depending on whether the target is a topological leaf or not.

I guess the question should be "what advantage is gained from describing
this stuff in the cpus node?"

Cheers
---Dave


From jagarwal at nvidia.com  Fri Apr 12 10:58:30 2013
From: jagarwal at nvidia.com (Jay Agarwal)
Date: Fri, 12 Apr 2013 20:28:30 +0530
Subject: [PATCH 1/3] ARM: tegra: pcie: Add tegra3 support
In-Reply-To: <51630852.1000107@wwwdotorg.org>
References: <1365435688-4179-1-git-send-email-jagarwal@nvidia.com>
 <51630852.1000107@wwwdotorg.org>
Message-ID: <C79B248886DD134989C8FF6B096A91AB91B36FB2FD@BGMAIL01.nvidia.com>

> >  	err = regulator_disable(pcie->pex_clk_supply);
> >  	if (err < 0)
> > -		dev_err(pcie->dev, "failed to disable pex-clk regulator:
> %d\n",
> > +		dev_warn(pcie->dev, "failed to disable pex-clk regulator:
> %d\n",
> >  			err);
> >
> >  	err = regulator_disable(pcie->vdd_supply);
> >  	if (err < 0)
> > -		dev_err(pcie->dev, "failed to disable VDD regulator: %d\n",
> > +		dev_warn(pcie->dev, "failed to disable VDD regulator:
> %d\n",
> >  			err);
> 
> Please explain why that change is correct. If the regulators only exist on
> Tegra20, please represent that fact in the SoC data. Regulators must always
> exist, so enable/disable should never fail due to missing regulators. Actual
> run-time failures seem like something that really is an error.
> 
[>] These regulators are needed for both tegra20 & tegra30. Since we are not returning error here, so changed to dev_warn.



From jagarwal at nvidia.com  Fri Apr 12 11:03:20 2013
From: jagarwal at nvidia.com (Jay Agarwal)
Date: Fri, 12 Apr 2013 20:33:20 +0530
Subject: [PATCH 2/3] ARM: dts: tegra: Correct PCIe entry
In-Reply-To: <20130409083050.GQ3572@tbergstrom-lnx.Nvidia.com>
References: <1365435688-4179-1-git-send-email-jagarwal@nvidia.com>
 <1365435688-4179-2-git-send-email-jagarwal@nvidia.com>
 <51630BF4.6000605@wwwdotorg.org>
 <20130409083050.GQ3572@tbergstrom-lnx.Nvidia.com>
Message-ID: <C79B248886DD134989C8FF6B096A91AB91B36FB2FE@BGMAIL01.nvidia.com>

> On Mon, Apr 08, 2013 at 08:27:00PM +0200, Stephen Warren wrote:
> > On 04/08/2013 09:41 AM, Jay Agarwal wrote:
> > > Signed-off-by: Jay Agarwal <jagarwal at nvidia.com>
> >
> > Your s-o-b line should be below the patch description, not above it.
> > Please see Documentation/SubmittingPatches.
> >
> > I also don't see a --- line between the patch description and diffstat.
> > How are you generating these patch emails? Please see our internal
> > wiki, or other git documentation.
> >
> > > diff --git a/arch/arm/boot/dts/tegra30.dtsi
> > > b/arch/arm/boot/dts/tegra30.dtsi
> >
> > > -		clock-names = "pex", "afi", "pcie_xclk", "pll_e", "cml";
> > > +		clock-names = "pex", "afi", "pcie_xclk", "pll_e", "cml0";
> >
> > Can you please explain more about this change?
> >
> > I see the Tegra clock driver provides both a "cml0" and a "cml1" clock.
> > Are both of those used for PCIe?
> >
> 
> cml0 is used for pcie and cml1 is used for sata.
> 
[>] Yes correct.


From s.hauer at pengutronix.de  Fri Apr 12 11:10:01 2013
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Fri, 12 Apr 2013 17:10:01 +0200
Subject: [PATCH] ARM: i.MX5 Allow DT clock providers
In-Reply-To: <20130412121329.3965.30768.stgit@localhost>
References: <20130412121329.3965.30768.stgit@localhost>
Message-ID: <20130412151001.GS1906@pengutronix.de>

On Fri, Apr 12, 2013 at 02:13:29PM +0200, Martin Fuzzey wrote:
> Currently clock providers defined in the DT are not registered
> on i.MX5 platforms since of_clk_init() is not called.
> 
> This is not a problem for the SOC's own clocks, which are registered
> in code,  but prevents the DT being used to define clocks for external
> hardware.
> 
> Fix this by calling of_clk_init() and actually using the DT to obtain
> the 4 SOC fixed clocks.
> These are already defined in the DT but were previously just used to
> manually obtain the rate.
> 
> Fall back to the old scheme for non DT platforms.
> 
> Signed-off-by: Martin Fuzzey <mfuzzey at parkeon.com>
> ---
>  arch/arm/mach-imx/clk-imx51-imx53.c |   75 +++++++++++++++++++----------------
>  1 files changed, 41 insertions(+), 34 deletions(-)
> 
> diff --git a/arch/arm/mach-imx/clk-imx51-imx53.c b/arch/arm/mach-imx/clk-imx51-imx53.c
> index 3228b4e..342c8b3 100644
> --- a/arch/arm/mach-imx/clk-imx51-imx53.c
> +++ b/arch/arm/mach-imx/clk-imx51-imx53.c
> @@ -117,17 +117,52 @@ enum imx5_clks {
>  static struct clk *clk[clk_max];
>  static struct clk_onecell_data clk_data;
>  
> +
> +static struct clk * __init mx5_obtain_fixed_clock_from_dt(const char *name)
> +{
> +#ifdef CONFIG_OF
> +	char compatible[20];
> +	struct of_phandle_args phandle = {0};
> +	struct clk *clk = NULL;
> +
> +	scnprintf(compatible, sizeof(compatible), "fsl,imx-%s", name);

Can we use kasprintf here? Not that it makes a big difference currently,
but it always looks a bit awkward to depend on a maximum string length.

> +	phandle.np = of_find_compatible_node(NULL, NULL, compatible);
> +	if (phandle.np) {
> +		clk = of_clk_get_from_provider(&phandle);
> +		of_node_put(phandle.np);
> +	}
> +	return clk;
> +#else
> +	return NULL;
> +#endif
> +}
> +
> +static struct clk * __init mx5_obtain_fixed_clock(
> +			const char *name, unsigned long rate)
> +{
> +	struct clk *clk;
> +
> +	clk = mx5_obtain_fixed_clock_from_dt(name);
> +	if (IS_ERR_OR_NULL(clk))

You shouldn't use IS_ERR_OR_NULL. Instead you could return
ERR_PTR(-ENODEV) for !CONFIG_OF. Another option would be to inline the
code from mx5_obtain_fixed_clock_from_dt here.

> +		clk = imx_clk_fixed(name, rate);
> +	return clk;
> +}
> +

Sascha


-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From ian.campbell at citrix.com  Fri Apr 12 11:09:59 2013
From: ian.campbell at citrix.com (Ian Campbell)
Date: Fri, 12 Apr 2013 16:09:59 +0100
Subject: [PATCH] arm64: remove PSR bit macros from uapi
Message-ID: <1365779399-16654-1-git-send-email-ian.campbell@citrix.com>

Exposing these in ptrace.h ends up polluting the namespace for user
applications which include headers such as <signal.h>, e.g. when building Xen
userspace tools on arm64:

tools/include/xen/arch-arm.h:229:0: error: "PSR_MODE_EL0t" redefined [-Werror]
In file included from /usr/lib/gcc-cross/aarch64-linux-gnu/4.7/../../../../aarch64-linux-gnu/include/sys/user.h:25:0,
                 from /usr/lib/gcc-cross/aarch64-linux-gnu/4.7/../../../../aarch64-linux-gnu/include/sys/procfs.h:34,
                 from /usr/lib/gcc-cross/aarch64-linux-gnu/4.7/../../../../aarch64-linux-gnu/include/sys/ucontext.h:26,
                 from /usr/lib/gcc-cross/aarch64-linux-gnu/4.7/../../../../aarch64-linux-gnu/include/signal.h:360,
                 from xentrace.c:21:
/usr/lib/gcc-cross/aarch64-linux-gnu/4.7/../../../../aarch64-linux-gnu/include/asm/ptrace.h:30:0: note: this is the location of the previous definition

I think these were brought over as part of the uapi transition in error
because they were not protected by the __KERNEL__ define.

Signed-off-by: Ian Campbell <ian.campbell at citrix.com>
Cc: Will Deacon <will.deacon at arm.com>
Cc: Catalin Marinas <catalin.marinas at arm.com>
Cc: David Howells <dhowells at redhat.com>
Cc: linux-arm-kernel at lists.infradead.org
Cc: xen-devel at lists.xen.org
---
 arch/arm64/include/asm/ptrace.h      |   34 ++++++++++++++++++++++++++++++++
 arch/arm64/include/uapi/asm/ptrace.h |   36 ----------------------------------
 2 files changed, 34 insertions(+), 36 deletions(-)

diff --git a/arch/arm64/include/asm/ptrace.h b/arch/arm64/include/asm/ptrace.h
index 4ce845f..758e41e 100644
--- a/arch/arm64/include/asm/ptrace.h
+++ b/arch/arm64/include/asm/ptrace.h
@@ -21,6 +21,40 @@
 
 #include <uapi/asm/ptrace.h>
 
+/*
+ * PSR bits
+ */
+#define PSR_MODE_EL0t	0x00000000
+#define PSR_MODE_EL1t	0x00000004
+#define PSR_MODE_EL1h	0x00000005
+#define PSR_MODE_EL2t	0x00000008
+#define PSR_MODE_EL2h	0x00000009
+#define PSR_MODE_EL3t	0x0000000c
+#define PSR_MODE_EL3h	0x0000000d
+#define PSR_MODE_MASK	0x0000000f
+
+/* AArch32 CPSR bits */
+#define PSR_MODE32_BIT		0x00000010
+
+/* AArch64 SPSR bits */
+#define PSR_F_BIT	0x00000040
+#define PSR_I_BIT	0x00000080
+#define PSR_A_BIT	0x00000100
+#define PSR_D_BIT	0x00000200
+#define PSR_Q_BIT	0x08000000
+#define PSR_V_BIT	0x10000000
+#define PSR_C_BIT	0x20000000
+#define PSR_Z_BIT	0x40000000
+#define PSR_N_BIT	0x80000000
+
+/*
+ * Groups of PSR bits
+ */
+#define PSR_f		0xff000000	/* Flags		*/
+#define PSR_s		0x00ff0000	/* Status		*/
+#define PSR_x		0x0000ff00	/* Extension		*/
+#define PSR_c		0x000000ff	/* Control		*/
+
 /* AArch32-specific ptrace requests */
 #define COMPAT_PTRACE_GETREGS		12
 #define COMPAT_PTRACE_SETREGS		13
diff --git a/arch/arm64/include/uapi/asm/ptrace.h b/arch/arm64/include/uapi/asm/ptrace.h
index 6913643..fd3ed98 100644
--- a/arch/arm64/include/uapi/asm/ptrace.h
+++ b/arch/arm64/include/uapi/asm/ptrace.h
@@ -23,42 +23,6 @@
 
 #include <asm/hwcap.h>
 
-
-/*
- * PSR bits
- */
-#define PSR_MODE_EL0t	0x00000000
-#define PSR_MODE_EL1t	0x00000004
-#define PSR_MODE_EL1h	0x00000005
-#define PSR_MODE_EL2t	0x00000008
-#define PSR_MODE_EL2h	0x00000009
-#define PSR_MODE_EL3t	0x0000000c
-#define PSR_MODE_EL3h	0x0000000d
-#define PSR_MODE_MASK	0x0000000f
-
-/* AArch32 CPSR bits */
-#define PSR_MODE32_BIT		0x00000010
-
-/* AArch64 SPSR bits */
-#define PSR_F_BIT	0x00000040
-#define PSR_I_BIT	0x00000080
-#define PSR_A_BIT	0x00000100
-#define PSR_D_BIT	0x00000200
-#define PSR_Q_BIT	0x08000000
-#define PSR_V_BIT	0x10000000
-#define PSR_C_BIT	0x20000000
-#define PSR_Z_BIT	0x40000000
-#define PSR_N_BIT	0x80000000
-
-/*
- * Groups of PSR bits
- */
-#define PSR_f		0xff000000	/* Flags		*/
-#define PSR_s		0x00ff0000	/* Status		*/
-#define PSR_x		0x0000ff00	/* Extension		*/
-#define PSR_c		0x000000ff	/* Control		*/
-
-
 #ifndef __ASSEMBLY__
 
 /*
-- 
1.7.2.5



From arnd at arndb.de  Fri Apr 12 11:11:07 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 12 Apr 2013 17:11:07 +0200
Subject: [PATCH 1/2] ARM: default machine descriptor for multiplatform
Message-ID: <1365779468-116419-1-git-send-email-arnd@arndb.de>

Since we now have default implementations for init_time and init_irq,
the init_machine callback is the only one that is not yet optional,
but since simple DT based platforms all have the same
of_platform_populate function call in there, we can consolidate them
as well, and then actually boot with a completely empty machine_desc.
Unofortunately we cannot just default to an empty init_machine: We
cannot call of_platform_populate before init_machine because that
does not work in case of auxdata, and we cannot call it after
init_machine either because the machine might need to run code
after adding the devices.

To take the final step, this adds support for booting without defining
any machine_desc whatsoever.

For the case that CONFIG_MULTIPLATFORM is enabled, it adds a
global machine descriptor that never matches any machine but is
used as a fallback if nothing else matches. We assume that without
CONFIG_MULTIPLATFORM, we only want to boot on the systems that the kernel
is built for, so we still retain the build-time warning for missing
machine descriptors and the run-time warning when the platform does not
match in that case.

In the case that we run on a multiplatform kernel and the machine
provides a fully populated device tree, we attempt to keep booting,
hoping that no machine specific callbacks are necessary.

Finally, this also removes the misguided "select ARCH_VEXPRESS" that
was only added to avoid a build error for allnoconfig kernels.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Acked-by: Nicolas Pitre <nico at linaro.org>
Acked-by: Olof Johansson <olof at lixom.net>
Cc: "Russell King - ARM Linux" <linux at arm.linux.org.uk>
Cc: Rob Herring <robherring2 at gmail.com>
---
 arch/arm/Kconfig          |  1 -
 arch/arm/kernel/devtree.c |  9 ++++++++-
 arch/arm/kernel/setup.c   | 13 +++++++++++--
 3 files changed, 19 insertions(+), 4 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 1cacda4..e67d49d 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1014,7 +1014,6 @@ config ARCH_MULTI_V7
 	bool "ARMv7 based platforms (Cortex-A, PJ4, Scorpion, Krait)"
 	default y
 	select ARCH_MULTI_V6_V7
-	select ARCH_VEXPRESS
 	select CPU_V7
 
 config ARCH_MULTI_V6_V7
diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
index 70f1bde..e6e34ba 100644
--- a/arch/arm/kernel/devtree.c
+++ b/arch/arm/kernel/devtree.c
@@ -180,6 +180,13 @@ struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys)
 	unsigned long dt_root;
 	const char *model;
 
+	if (IS_ENABLED(CONFIG_ARCH_MULTIPLATFORM)) {
+		DT_MACHINE_START(GENERIC_DT, "Generic DT based system")
+		MACHINE_END
+
+		mdesc_best = (struct machine_desc *)&__mach_desc_GENERIC_DT;
+	}
+
 	if (!dt_phys)
 		return NULL;
 
@@ -199,7 +206,7 @@ struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys)
 			mdesc_score = score;
 		}
 	}
-	if (!mdesc_best) {
+	if (!mdesc_best && !IS_ENABLED(CONFIG_ARCH_MULTIPLATFORM)) {
 		const char *prop;
 		long size;
 
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index d343a6c..8ea8d68 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -18,6 +18,7 @@
 #include <linux/bootmem.h>
 #include <linux/seq_file.h>
 #include <linux/screen_info.h>
+#include <linux/of_platform.h>
 #include <linux/init.h>
 #include <linux/kexec.h>
 #include <linux/of_fdt.h>
@@ -660,9 +661,17 @@ struct screen_info screen_info = {
 
 static int __init customize_machine(void)
 {
-	/* customizes platform devices, or adds new ones */
+	/*
+	 * customizes platform devices, or adds new ones
+	 * On DT based machines, we fall back to populating the
+	 * machine from the device tree, if no callback is provided,
+	 * otherwise we would always need an init_machine callback.
+	 */
 	if (machine_desc->init_machine)
 		machine_desc->init_machine();
+	else
+		of_platform_populate(NULL, of_default_bus_match_table,
+					NULL, NULL);
 	return 0;
 }
 arch_initcall(customize_machine);
@@ -752,7 +761,7 @@ void __init setup_arch(char **cmdline_p)
 
 	setup_processor();
 	mdesc = setup_machine_fdt(__atags_pointer);
-	if (!mdesc)
+	if (!mdesc && __machine_arch_type != ~0)
 		mdesc = setup_machine_tags(__atags_pointer, __machine_arch_type);
 	machine_desc = mdesc;
 	machine_name = mdesc->name;
-- 
1.8.1.2



From arnd at arndb.de  Fri Apr 12 11:11:08 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 12 Apr 2013 17:11:08 +0200
Subject: [PATCH 2/2] ARM: remove all trivial init_machine callbacks
In-Reply-To: <1365779468-116419-1-git-send-email-arnd@arndb.de>
References: <1365779468-116419-1-git-send-email-arnd@arndb.de>
Message-ID: <1365779468-116419-2-git-send-email-arnd@arndb.de>

The call to of_platform_populate(NULL, of_default_bus_match_table, NULL,
NULL) is now implied by having no init_machine callback in the machine
descriptor, so we can save a couple of lines in those machines that
do not need to do anything else.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Cc: Nicolas Pitre <nico at linaro.org>
Cc: Olof Johansson <olof at lixom.net>
Cc: "Russell King - ARM Linux" <linux at arm.linux.org.uk>
Cc: Rob Herring <robherring2 at gmail.com>
---
 arch/arm/mach-at91/board-dt.c           |  6 ------
 arch/arm/mach-at91/board-rm9200-dt.c    |  6 ------
 arch/arm/mach-exynos/mach-exynos4-dt.c  |  7 -------
 arch/arm/mach-imx/imx25-dt.c            |  6 ------
 arch/arm/mach-imx/imx31-dt.c            |  6 ------
 arch/arm/mach-imx/imx51-dt.c            |  6 ------
 arch/arm/mach-msm/board-dt-8660.c       | 11 -----------
 arch/arm/mach-msm/board-dt-8960.c       |  6 ------
 arch/arm/mach-tegra/board-dt-tegra114.c |  6 ------
 arch/arm/mach-tegra/board-dt-tegra30.c  |  6 ------
 arch/arm/mach-virt/virt.c               |  6 ------
 11 files changed, 72 deletions(-)

diff --git a/arch/arm/mach-at91/board-dt.c b/arch/arm/mach-at91/board-dt.c
index 8db3013..9903579 100644
--- a/arch/arm/mach-at91/board-dt.c
+++ b/arch/arm/mach-at91/board-dt.c
@@ -37,11 +37,6 @@ static void __init at91_dt_init_irq(void)
 	of_irq_init(irq_of_match);
 }
 
-static void __init at91_dt_device_init(void)
-{
-	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
-}
-
 static const char *at91_dt_board_compat[] __initdata = {
 	"atmel,at91sam9",
 	NULL
@@ -54,6 +49,5 @@ DT_MACHINE_START(at91sam_dt, "Atmel AT91SAM (Device Tree)")
 	.handle_irq	= at91_aic_handle_irq,
 	.init_early	= at91_dt_initialize,
 	.init_irq	= at91_dt_init_irq,
-	.init_machine	= at91_dt_device_init,
 	.dt_compat	= at91_dt_board_compat,
 MACHINE_END
diff --git a/arch/arm/mach-at91/board-rm9200-dt.c b/arch/arm/mach-at91/board-rm9200-dt.c
index 3fcb662..6b8d260 100644
--- a/arch/arm/mach-at91/board-rm9200-dt.c
+++ b/arch/arm/mach-at91/board-rm9200-dt.c
@@ -36,11 +36,6 @@ static void __init at91rm9200_dt_init_irq(void)
 	of_irq_init(irq_of_match);
 }
 
-static void __init at91rm9200_dt_device_init(void)
-{
-	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
-}
-
 static const char *at91rm9200_dt_board_compat[] __initdata = {
 	"atmel,at91rm9200",
 	NULL
@@ -52,6 +47,5 @@ DT_MACHINE_START(at91rm9200_dt, "Atmel AT91RM9200 (Device Tree)")
 	.handle_irq	= at91_aic_handle_irq,
 	.init_early	= at91rm9200_dt_initialize,
 	.init_irq	= at91rm9200_dt_init_irq,
-	.init_machine	= at91rm9200_dt_device_init,
 	.dt_compat	= at91rm9200_dt_board_compat,
 MACHINE_END
diff --git a/arch/arm/mach-exynos/mach-exynos4-dt.c b/arch/arm/mach-exynos/mach-exynos4-dt.c
index 3358088..25038a1 100644
--- a/arch/arm/mach-exynos/mach-exynos4-dt.c
+++ b/arch/arm/mach-exynos/mach-exynos4-dt.c
@@ -122,12 +122,6 @@ static void __init exynos4_dt_map_io(void)
 	s3c24xx_init_clocks(24000000);
 }
 
-static void __init exynos4_dt_machine_init(void)
-{
-	of_platform_populate(NULL, of_default_bus_match_table,
-				exynos4_auxdata_lookup, NULL);
-}
-
 static char const *exynos4_dt_compat[] __initdata = {
 	"samsung,exynos4210",
 	"samsung,exynos4212",
@@ -140,7 +134,6 @@ DT_MACHINE_START(EXYNOS4210_DT, "Samsung Exynos4 (Flattened Device Tree)")
 	.smp		= smp_ops(exynos_smp_ops),
 	.init_irq	= exynos4_init_irq,
 	.map_io		= exynos4_dt_map_io,
-	.init_machine	= exynos4_dt_machine_init,
 	.init_late	= exynos_init_late,
 	.init_time	= exynos4_timer_init,
 	.dt_compat	= exynos4_dt_compat,
diff --git a/arch/arm/mach-imx/imx25-dt.c b/arch/arm/mach-imx/imx25-dt.c
index 8234839..2ecaa6a 100644
--- a/arch/arm/mach-imx/imx25-dt.c
+++ b/arch/arm/mach-imx/imx25-dt.c
@@ -17,11 +17,6 @@
 #include "common.h"
 #include "mx25.h"
 
-static void __init imx25_dt_init(void)
-{
-	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
-}
-
 static const char * const imx25_dt_board_compat[] __initconst = {
 	"fsl,imx25",
 	NULL
@@ -38,7 +33,6 @@ DT_MACHINE_START(IMX25_DT, "Freescale i.MX25 (Device Tree Support)")
 	.init_irq	= mx25_init_irq,
 	.handle_irq	= imx25_handle_irq,
 	.init_time	= imx25_timer_init,
-	.init_machine	= imx25_dt_init,
 	.dt_compat	= imx25_dt_board_compat,
 	.restart	= mxc_restart,
 MACHINE_END
diff --git a/arch/arm/mach-imx/imx31-dt.c b/arch/arm/mach-imx/imx31-dt.c
index 67de611..5bb05d5 100644
--- a/arch/arm/mach-imx/imx31-dt.c
+++ b/arch/arm/mach-imx/imx31-dt.c
@@ -18,11 +18,6 @@
 #include "common.h"
 #include "mx31.h"
 
-static void __init imx31_dt_init(void)
-{
-	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
-}
-
 static const char *imx31_dt_board_compat[] __initdata = {
 	"fsl,imx31",
 	NULL
@@ -39,7 +34,6 @@ DT_MACHINE_START(IMX31_DT, "Freescale i.MX31 (Device Tree Support)")
 	.init_irq	= mx31_init_irq,
 	.handle_irq	= imx31_handle_irq,
 	.init_time	= imx31_dt_timer_init,
-	.init_machine	= imx31_dt_init,
 	.dt_compat	= imx31_dt_board_compat,
 	.restart	= mxc_restart,
 MACHINE_END
diff --git a/arch/arm/mach-imx/imx51-dt.c b/arch/arm/mach-imx/imx51-dt.c
index e2926a8..52985a5 100644
--- a/arch/arm/mach-imx/imx51-dt.c
+++ b/arch/arm/mach-imx/imx51-dt.c
@@ -19,11 +19,6 @@
 #include "common.h"
 #include "mx51.h"
 
-static void __init imx51_dt_init(void)
-{
-	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
-}
-
 static const char *imx51_dt_board_compat[] __initdata = {
 	"fsl,imx51",
 	NULL
@@ -40,7 +35,6 @@ DT_MACHINE_START(IMX51_DT, "Freescale i.MX51 (Device Tree Support)")
 	.init_irq	= mx51_init_irq,
 	.handle_irq	= imx51_handle_irq,
 	.init_time	= imx51_timer_init,
-	.init_machine	= imx51_dt_init,
 	.init_late	= imx51_init_late,
 	.dt_compat	= imx51_dt_board_compat,
 	.restart	= mxc_restart,
diff --git a/arch/arm/mach-msm/board-dt-8660.c b/arch/arm/mach-msm/board-dt-8660.c
index 7dcfc53..0c21245 100644
--- a/arch/arm/mach-msm/board-dt-8660.c
+++ b/arch/arm/mach-msm/board-dt-8660.c
@@ -25,16 +25,6 @@ static void __init msm8x60_init_late(void)
 	smd_debugfs_init();
 }
 
-static struct of_dev_auxdata msm_auxdata_lookup[] __initdata = {
-	{}
-};
-
-static void __init msm8x60_dt_init(void)
-{
-	of_platform_populate(NULL, of_default_bus_match_table,
-			msm_auxdata_lookup, NULL);
-}
-
 static const char *msm8x60_fluid_match[] __initdata = {
 	"qcom,msm8660-fluid",
 	"qcom,msm8660-surf",
@@ -45,7 +35,6 @@ DT_MACHINE_START(MSM_DT, "Qualcomm MSM (Flattened Device Tree)")
 	.smp = smp_ops(msm_smp_ops),
 	.map_io = msm_map_msm8x60_io,
 	.init_irq = irqchip_init,
-	.init_machine = msm8x60_dt_init,
 	.init_late = msm8x60_init_late,
 	.init_time	= msm_dt_timer_init,
 	.dt_compat = msm8x60_fluid_match,
diff --git a/arch/arm/mach-msm/board-dt-8960.c b/arch/arm/mach-msm/board-dt-8960.c
index 7301936..26461d2 100644
--- a/arch/arm/mach-msm/board-dt-8960.c
+++ b/arch/arm/mach-msm/board-dt-8960.c
@@ -18,11 +18,6 @@
 
 #include "common.h"
 
-static void __init msm_dt_init(void)
-{
-	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
-}
-
 static const char * const msm8960_dt_match[] __initconst = {
 	"qcom,msm8960-cdp",
 	NULL
@@ -33,6 +28,5 @@ DT_MACHINE_START(MSM8960_DT, "Qualcomm MSM (Flattened Device Tree)")
 	.map_io = msm_map_msm8960_io,
 	.init_irq = irqchip_init,
 	.init_time	= msm_dt_timer_init,
-	.init_machine = msm_dt_init,
 	.dt_compat = msm8960_dt_match,
 MACHINE_END
diff --git a/arch/arm/mach-tegra/board-dt-tegra114.c b/arch/arm/mach-tegra/board-dt-tegra114.c
index 085d636..ec7b8bf 100644
--- a/arch/arm/mach-tegra/board-dt-tegra114.c
+++ b/arch/arm/mach-tegra/board-dt-tegra114.c
@@ -23,11 +23,6 @@
 #include "board.h"
 #include "common.h"
 
-static void __init tegra114_dt_init(void)
-{
-	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
-}
-
 static const char * const tegra114_dt_board_compat[] = {
 	"nvidia,tegra114",
 	NULL,
@@ -39,7 +34,6 @@ DT_MACHINE_START(TEGRA114_DT, "NVIDIA Tegra114 (Flattened Device Tree)")
 	.init_early	= tegra114_init_early,
 	.init_irq	= tegra_dt_init_irq,
 	.init_time	= clocksource_of_init,
-	.init_machine	= tegra114_dt_init,
 	.init_late	= tegra_init_late,
 	.restart	= tegra_assert_system_reset,
 	.dt_compat	= tegra114_dt_board_compat,
diff --git a/arch/arm/mach-tegra/board-dt-tegra30.c b/arch/arm/mach-tegra/board-dt-tegra30.c
index bf68567..316bd9f 100644
--- a/arch/arm/mach-tegra/board-dt-tegra30.c
+++ b/arch/arm/mach-tegra/board-dt-tegra30.c
@@ -37,11 +37,6 @@
 #include "common.h"
 #include "iomap.h"
 
-static void __init tegra30_dt_init(void)
-{
-	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
-}
-
 static const char *tegra30_dt_board_compat[] = {
 	"nvidia,tegra30",
 	NULL
@@ -53,7 +48,6 @@ DT_MACHINE_START(TEGRA30_DT, "NVIDIA Tegra30 (Flattened Device Tree)")
 	.init_early	= tegra30_init_early,
 	.init_irq	= tegra_dt_init_irq,
 	.init_time	= clocksource_of_init,
-	.init_machine	= tegra30_dt_init,
 	.init_late	= tegra_init_late,
 	.restart	= tegra_assert_system_reset,
 	.dt_compat	= tegra30_dt_board_compat,
diff --git a/arch/arm/mach-virt/virt.c b/arch/arm/mach-virt/virt.c
index 31666f6..7bce0f8 100644
--- a/arch/arm/mach-virt/virt.c
+++ b/arch/arm/mach-virt/virt.c
@@ -27,11 +27,6 @@
 #include <asm/mach/arch.h>
 #include <asm/mach/time.h>
 
-static void __init virt_init(void)
-{
-	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
-}
-
 static void __init virt_timer_init(void)
 {
 	WARN_ON(arch_timer_of_register() != 0);
@@ -48,7 +43,6 @@ extern struct smp_operations virt_smp_ops;
 DT_MACHINE_START(VIRT, "Dummy Virtual Machine")
 	.init_irq	= irqchip_init,
 	.init_time	= virt_timer_init,
-	.init_machine	= virt_init,
 	.smp		= smp_ops(virt_smp_ops),
 	.dt_compat	= virt_dt_match,
 MACHINE_END
-- 
1.8.1.2



From will.deacon at arm.com  Fri Apr 12 11:18:36 2013
From: will.deacon at arm.com (Will Deacon)
Date: Fri, 12 Apr 2013 16:18:36 +0100
Subject: [PATCH] arm64: remove PSR bit macros from uapi
In-Reply-To: <1365779399-16654-1-git-send-email-ian.campbell@citrix.com>
References: <1365779399-16654-1-git-send-email-ian.campbell@citrix.com>
Message-ID: <20130412151835.GK12363@mudshark.cambridge.arm.com>

Hi Ian,

On Fri, Apr 12, 2013 at 04:09:59PM +0100, Ian Campbell wrote:
> Exposing these in ptrace.h ends up polluting the namespace for user
> applications which include headers such as <signal.h>, e.g. when building Xen
> userspace tools on arm64:
> 
> tools/include/xen/arch-arm.h:229:0: error: "PSR_MODE_EL0t" redefined [-Werror]
> In file included from /usr/lib/gcc-cross/aarch64-linux-gnu/4.7/../../../../aarch64-linux-gnu/include/sys/user.h:25:0,
>                  from /usr/lib/gcc-cross/aarch64-linux-gnu/4.7/../../../../aarch64-linux-gnu/include/sys/procfs.h:34,
>                  from /usr/lib/gcc-cross/aarch64-linux-gnu/4.7/../../../../aarch64-linux-gnu/include/sys/ucontext.h:26,
>                  from /usr/lib/gcc-cross/aarch64-linux-gnu/4.7/../../../../aarch64-linux-gnu/include/signal.h:360,
>                  from xentrace.c:21:
> /usr/lib/gcc-cross/aarch64-linux-gnu/4.7/../../../../aarch64-linux-gnu/include/asm/ptrace.h:30:0: note: this is the location of the previous definition

Strange... I don't see the PSR definitions in any headers other than
ptrace.h for my aarch64 toolchain. Which tools are you using?

Will


From marc.zyngier at arm.com  Fri Apr 12 11:18:49 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Fri, 12 Apr 2013 16:18:49 +0100
Subject: [PATCH v3 4/7] ARM: KVM: enforce maximum size for identity mapped code
In-Reply-To: <1365779932-20322-1-git-send-email-marc.zyngier@arm.com>
References: <1365779932-20322-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1365779932-20322-5-git-send-email-marc.zyngier@arm.com>

We're about to move to an init procedure where we rely on the
fact that the init code fits in a single page. Make sure we
align the idmap text on a vector alignment, and that the code is
not bigger than a single page.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm/kernel/vmlinux.lds.S | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
index b571484..a871b8e 100644
--- a/arch/arm/kernel/vmlinux.lds.S
+++ b/arch/arm/kernel/vmlinux.lds.S
@@ -20,7 +20,7 @@
 	VMLINUX_SYMBOL(__idmap_text_start) = .;				\
 	*(.idmap.text)							\
 	VMLINUX_SYMBOL(__idmap_text_end) = .;				\
-	ALIGN_FUNCTION();						\
+	. = ALIGN(32);							\
 	VMLINUX_SYMBOL(__hyp_idmap_text_start) = .;			\
 	*(.hyp.idmap.text)						\
 	VMLINUX_SYMBOL(__hyp_idmap_text_end) = .;
@@ -315,3 +315,8 @@ SECTIONS
  */
 ASSERT((__proc_info_end - __proc_info_begin), "missing CPU support")
 ASSERT((__arch_info_end - __arch_info_begin), "no machine record defined")
+/*
+ * The HYP init code can't be more than a page long.
+ * The above comment applies as well.
+ */
+ASSERT(((__hyp_idmap_text_end - __hyp_idmap_text_start) <= PAGE_SIZE), "HYP init code too big")
-- 
1.8.1.4




From marc.zyngier at arm.com  Fri Apr 12 11:18:45 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Fri, 12 Apr 2013 16:18:45 +0100
Subject: [PATCH v3 0/7] ARM: KVM: Revamping the HYP init code for fun and
 profit
Message-ID: <1365779932-20322-1-git-send-email-marc.zyngier@arm.com>

Over the past few weeks, I've gradually realized how broken our HYP
idmap code is. Badly broken.

The main problem is about supporting CPU hotplug. Imagine a CPU being
initialized normally, running VMs, and then being powered down. So
far, so good. Now mentally bring it back online. The CPU will come
back via the secondary CPU boot path, and then what? We cannot use it
anymore, because we need an idmap which is long gone, and because our
page tables are now live, containing the world-switch code, VM
structures, and other bits and pieces.

Another fun issue is that we don't have any TLB invalidation in the
HYP init code. And guess what? we cannot do it! HYP TLB invalidation
has to occur in HYP, and once we've installed the runtime page tables,
it is already too late. It is actually fairly easy to construct a
scenario where idmap and runtime pages have colliding translations.

The nail on the coffin was provided by Catalin Marinas who told me how
much he disliked the arm64 HYP idmap code, and made me realize that we
already have all the necessary code in arch/arm/kvm/mmu.c. It just
needs a tiny bit of care and affection. With a chainsaw.

The solution to the first two issues is a bit tricky, but doesn't
involve a lot of code. The hotplug problem mandates that we keep two
sets of page tables (boot and runtime). The TLB problem mandates that
we're able to transition from one PGD to another while in HYP,
invalidating the TLBs in the process.

To be able to do this, we need to share a page between the two page
tables. A page that will have the same VA in both configurations. All
we need is a VA that has the following properties:
- This VA can't be used to represent a kernel mapping.
- This VA will not conflict with the physical address of the kernel
  text

The vectors page VA seems to satisfy this requirement:
- The kernel never maps anything else there
- The kernel text being copied at the beginning of the physical
  memory, it is unlikely to use the last 64kB (I doubt we'll ever
  support KVM on a system with something like 4MB of RAM, but patches
  are very welcome).

Let's call this VA the trampoline VA.

Now, we map our init page at 3 locations:
- idmap in the boot pgd
- trampoline VA in the boot pgd
- trampoline VA in the runtime pgd

The init scenario is now the following:
- We jump in HYP with four parameters: boot HYP pgd, runtime HYP pgd,
  runtime stack, runtime vectors
- Enable the MMU with the boot pgd
- Jump to a target into the trampoline page (remember, this is the
  same physical page!)
- Now switch to the runtime pgd (same VA, and still the same physical
  page!)
- Invalidate TLBs
- Set stack and vectors
- Profit! (or eret, if you only care about the code).

Once we have this infrastructure in place, supporting CPU hot-plug is
a piece of cake. Just wire a cpu-notifier in the existing code.

This has been tested on both arm (VE TC2) and arm64 (Foundation Model).

>From v2:
- Fix the HYP page table freeing code by getting rid of it. Our
  stage-2 code does it a lot better, and I'd rather fix bugs only
  once.
- Flush HYP page tables to the Point of Coherency. This ensures that
  the incoming CPU will see the page tables, even with cache disabled
  (spotted by Will).
- Use kmalloc instead of kzalloc for the bounce page (spotted by
  Christoffer).

>From v1:
- Reduce the mandatory alignement of the init code page, and use a
  bounce page if the code is crossing a page boundary.
- Add some more comments to the code (as requested by Christoffer)
- Fixed compilation issue with older toolchains (spotted by Geoff)

Marc Zyngier (7):
  ARM: KVM: simplify HYP mapping population
  ARM: KVM: fix HYP mapping limitations around zero
  ARM: KVM: move to a KVM provided HYP idmap
  ARM: KVM: enforce maximum size for identity mapped code
  ARM: KVM: rework HYP page table freeing
  ARM: KVM: switch to a dual-step HYP init code
  ARM: KVM: perform HYP initilization for hotplugged CPUs

 arch/arm/include/asm/idmap.h    |   1 -
 arch/arm/include/asm/kvm_host.h |  31 +--
 arch/arm/include/asm/kvm_mmu.h  |  28 ++-
 arch/arm/kernel/vmlinux.lds.S   |   7 +-
 arch/arm/kvm/arm.c              |  62 ++++--
 arch/arm/kvm/init.S             |  78 +++++--
 arch/arm/kvm/mmu.c              | 458 +++++++++++++++++++++++-----------------
 arch/arm/mm/idmap.c             |  32 +--
 8 files changed, 407 insertions(+), 290 deletions(-)

-- 
1.8.1.4




From marc.zyngier at arm.com  Fri Apr 12 11:18:48 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Fri, 12 Apr 2013 16:18:48 +0100
Subject: [PATCH v3 3/7] ARM: KVM: move to a KVM provided HYP idmap
In-Reply-To: <1365779932-20322-1-git-send-email-marc.zyngier@arm.com>
References: <1365779932-20322-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1365779932-20322-4-git-send-email-marc.zyngier@arm.com>

After the HYP page table rework, it is pretty easy to let the KVM
code provide its own idmap, rather than expecting the kernel to
provide it. It takes actually less code to do so.

Acked-by: Will Deacon <will.deacon at arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm/include/asm/idmap.h   |  1 -
 arch/arm/include/asm/kvm_mmu.h |  1 -
 arch/arm/kvm/mmu.c             | 24 +++++++++++++++++++++++-
 arch/arm/mm/idmap.c            | 32 +-------------------------------
 4 files changed, 24 insertions(+), 34 deletions(-)

diff --git a/arch/arm/include/asm/idmap.h b/arch/arm/include/asm/idmap.h
index 1a66f907..bf863ed 100644
--- a/arch/arm/include/asm/idmap.h
+++ b/arch/arm/include/asm/idmap.h
@@ -8,7 +8,6 @@
 #define __idmap __section(.idmap.text) noinline notrace
 
 extern pgd_t *idmap_pgd;
-extern pgd_t *hyp_pgd;
 
 void setup_mm_for_reboot(void);
 
diff --git a/arch/arm/include/asm/kvm_mmu.h b/arch/arm/include/asm/kvm_mmu.h
index 970f3b5..3c71a1d 100644
--- a/arch/arm/include/asm/kvm_mmu.h
+++ b/arch/arm/include/asm/kvm_mmu.h
@@ -21,7 +21,6 @@
 
 #include <asm/cacheflush.h>
 #include <asm/pgalloc.h>
-#include <asm/idmap.h>
 
 /*
  * We directly use the kernel VA for the HYP, as we can directly share
diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
index 96d61da..bfc5927 100644
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@ -32,6 +32,7 @@
 
 extern char  __hyp_idmap_text_start[], __hyp_idmap_text_end[];
 
+static pgd_t *hyp_pgd;
 static DEFINE_MUTEX(kvm_hyp_pgd_mutex);
 
 static void kvm_tlb_flush_vmid_ipa(struct kvm *kvm, phys_addr_t ipa)
@@ -715,12 +716,33 @@ phys_addr_t kvm_mmu_get_httbr(void)
 
 int kvm_mmu_init(void)
 {
+	unsigned long hyp_idmap_start = virt_to_phys(__hyp_idmap_text_start);
+	unsigned long hyp_idmap_end = virt_to_phys(__hyp_idmap_text_end);
+	int err;
+
+	hyp_pgd = kzalloc(PTRS_PER_PGD * sizeof(pgd_t), GFP_KERNEL);
 	if (!hyp_pgd) {
 		kvm_err("Hyp mode PGD not allocated\n");
-		return -ENOMEM;
+		err = -ENOMEM;
+		goto out;
+	}
+
+	/* Create the idmap in the boot page tables */
+	err = 	__create_hyp_mappings(boot_hyp_pgd,
+				      hyp_idmap_start, hyp_idmap_end,
+				      __phys_to_pfn(hyp_idmap_start),
+				      PAGE_HYP);
+
+	if (err) {
+		kvm_err("Failed to idmap %lx-%lx\n",
+			hyp_idmap_start, hyp_idmap_end);
+		goto out;
 	}
 
 	return 0;
+out:
+	kfree(hyp_pgd);
+	return err;
 }
 
 /**
diff --git a/arch/arm/mm/idmap.c b/arch/arm/mm/idmap.c
index 5ee505c..83cb3ac 100644
--- a/arch/arm/mm/idmap.c
+++ b/arch/arm/mm/idmap.c
@@ -8,7 +8,6 @@
 #include <asm/pgtable.h>
 #include <asm/sections.h>
 #include <asm/system_info.h>
-#include <asm/virt.h>
 
 pgd_t *idmap_pgd;
 
@@ -83,37 +82,10 @@ static void identity_mapping_add(pgd_t *pgd, const char *text_start,
 	} while (pgd++, addr = next, addr != end);
 }
 
-#if defined(CONFIG_ARM_VIRT_EXT) && defined(CONFIG_ARM_LPAE)
-pgd_t *hyp_pgd;
-
-extern char  __hyp_idmap_text_start[], __hyp_idmap_text_end[];
-
-static int __init init_static_idmap_hyp(void)
-{
-	hyp_pgd = kzalloc(PTRS_PER_PGD * sizeof(pgd_t), GFP_KERNEL);
-	if (!hyp_pgd)
-		return -ENOMEM;
-
-	pr_info("Setting up static HYP identity map for 0x%p - 0x%p\n",
-		__hyp_idmap_text_start, __hyp_idmap_text_end);
-	identity_mapping_add(hyp_pgd, __hyp_idmap_text_start,
-			     __hyp_idmap_text_end, PMD_SECT_AP1);
-
-	return 0;
-}
-#else
-static int __init init_static_idmap_hyp(void)
-{
-	return 0;
-}
-#endif
-
 extern char  __idmap_text_start[], __idmap_text_end[];
 
 static int __init init_static_idmap(void)
 {
-	int ret;
-
 	idmap_pgd = pgd_alloc(&init_mm);
 	if (!idmap_pgd)
 		return -ENOMEM;
@@ -123,12 +95,10 @@ static int __init init_static_idmap(void)
 	identity_mapping_add(idmap_pgd, __idmap_text_start,
 			     __idmap_text_end, 0);
 
-	ret = init_static_idmap_hyp();
-
 	/* Flush L1 for the hardware to see this page table content */
 	flush_cache_louis();
 
-	return ret;
+	return 0;
 }
 early_initcall(init_static_idmap);
 
-- 
1.8.1.4




From marc.zyngier at arm.com  Fri Apr 12 11:18:47 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Fri, 12 Apr 2013 16:18:47 +0100
Subject: [PATCH v3 2/7] ARM: KVM: fix HYP mapping limitations around zero
In-Reply-To: <1365779932-20322-1-git-send-email-marc.zyngier@arm.com>
References: <1365779932-20322-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1365779932-20322-3-git-send-email-marc.zyngier@arm.com>

The current code for creating HYP mapping doesn't like to wrap
around zero, which prevents from mapping anything into the last
page of the virtual address space.

It doesn't take much effort to remove this limitation, making
the code more consistent with the rest of the kernel in the process.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm/kvm/mmu.c | 21 ++++++++++-----------
 1 file changed, 10 insertions(+), 11 deletions(-)

diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
index 3003321..96d61da 100644
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@ -131,11 +131,12 @@ static void create_hyp_pte_mappings(pmd_t *pmd, unsigned long start,
 	pte_t *pte;
 	unsigned long addr;
 
-	for (addr = start; addr < end; addr += PAGE_SIZE) {
+	addr = start;
+	do {
 		pte = pte_offset_kernel(pmd, addr);
 		kvm_set_pte(pte, pfn_pte(pfn, prot));
 		pfn++;
-	}
+	} while (addr += PAGE_SIZE, addr != end);
 }
 
 static int create_hyp_pmd_mappings(pud_t *pud, unsigned long start,
@@ -146,7 +147,8 @@ static int create_hyp_pmd_mappings(pud_t *pud, unsigned long start,
 	pte_t *pte;
 	unsigned long addr, next;
 
-	for (addr = start; addr < end; addr = next) {
+	addr = start;
+	do {
 		pmd = pmd_offset(pud, addr);
 
 		BUG_ON(pmd_sect(*pmd));
@@ -164,7 +166,7 @@ static int create_hyp_pmd_mappings(pud_t *pud, unsigned long start,
 
 		create_hyp_pte_mappings(pmd, addr, next, pfn, prot);
 		pfn += (next - addr) >> PAGE_SHIFT;
-	}
+	} while (addr = next, addr != end);
 
 	return 0;
 }
@@ -179,11 +181,10 @@ static int __create_hyp_mappings(pgd_t *pgdp,
 	unsigned long addr, next;
 	int err = 0;
 
-	if (start >= end)
-		return -EINVAL;
-
 	mutex_lock(&kvm_hyp_pgd_mutex);
-	for (addr = start & PAGE_MASK; addr < end; addr = next) {
+	addr = start & PAGE_MASK;
+	end = PAGE_ALIGN(end);
+	do {
 		pgd = pgdp + pgd_index(addr);
 		pud = pud_offset(pgd, addr);
 
@@ -202,7 +203,7 @@ static int __create_hyp_mappings(pgd_t *pgdp,
 		if (err)
 			goto out;
 		pfn += (next - addr) >> PAGE_SHIFT;
-	}
+	} while (addr = next, addr != end);
 out:
 	mutex_unlock(&kvm_hyp_pgd_mutex);
 	return err;
@@ -216,8 +217,6 @@ out:
  * The same virtual address as the kernel virtual address is also used
  * in Hyp-mode mapping (modulo HYP_PAGE_OFFSET) to the same underlying
  * physical pages.
- *
- * Note: Wrapping around zero in the "to" address is not supported.
  */
 int create_hyp_mappings(void *from, void *to)
 {
-- 
1.8.1.4




From marc.zyngier at arm.com  Fri Apr 12 11:18:46 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Fri, 12 Apr 2013 16:18:46 +0100
Subject: [PATCH v3 1/7] ARM: KVM: simplify HYP mapping population
In-Reply-To: <1365779932-20322-1-git-send-email-marc.zyngier@arm.com>
References: <1365779932-20322-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1365779932-20322-2-git-send-email-marc.zyngier@arm.com>

The way we populate HYP mappings is a bit convoluted, to say the least.
Passing a pointer around to keep track of the current PFN is quite
odd, and we end-up having two different PTE accessors for no good
reason.

Simplify the whole thing by unifying the two PTE accessors, passing
a pgprot_t around, and moving the various validity checks to the
upper layers.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm/kvm/mmu.c | 102 ++++++++++++++++++++++-------------------------------
 1 file changed, 42 insertions(+), 60 deletions(-)

diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
index 2f12e40..3003321 100644
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@ -125,54 +125,34 @@ void free_hyp_pmds(void)
 }
 
 static void create_hyp_pte_mappings(pmd_t *pmd, unsigned long start,
-				    unsigned long end)
+				    unsigned long end, unsigned long pfn,
+				    pgprot_t prot)
 {
 	pte_t *pte;
 	unsigned long addr;
-	struct page *page;
 
-	for (addr = start & PAGE_MASK; addr < end; addr += PAGE_SIZE) {
-		unsigned long hyp_addr = KERN_TO_HYP(addr);
-
-		pte = pte_offset_kernel(pmd, hyp_addr);
-		BUG_ON(!virt_addr_valid(addr));
-		page = virt_to_page(addr);
-		kvm_set_pte(pte, mk_pte(page, PAGE_HYP));
-	}
-}
-
-static void create_hyp_io_pte_mappings(pmd_t *pmd, unsigned long start,
-				       unsigned long end,
-				       unsigned long *pfn_base)
-{
-	pte_t *pte;
-	unsigned long addr;
-
-	for (addr = start & PAGE_MASK; addr < end; addr += PAGE_SIZE) {
-		unsigned long hyp_addr = KERN_TO_HYP(addr);
-
-		pte = pte_offset_kernel(pmd, hyp_addr);
-		BUG_ON(pfn_valid(*pfn_base));
-		kvm_set_pte(pte, pfn_pte(*pfn_base, PAGE_HYP_DEVICE));
-		(*pfn_base)++;
+	for (addr = start; addr < end; addr += PAGE_SIZE) {
+		pte = pte_offset_kernel(pmd, addr);
+		kvm_set_pte(pte, pfn_pte(pfn, prot));
+		pfn++;
 	}
 }
 
 static int create_hyp_pmd_mappings(pud_t *pud, unsigned long start,
-				   unsigned long end, unsigned long *pfn_base)
+				   unsigned long end, unsigned long pfn,
+				   pgprot_t prot)
 {
 	pmd_t *pmd;
 	pte_t *pte;
 	unsigned long addr, next;
 
 	for (addr = start; addr < end; addr = next) {
-		unsigned long hyp_addr = KERN_TO_HYP(addr);
-		pmd = pmd_offset(pud, hyp_addr);
+		pmd = pmd_offset(pud, addr);
 
 		BUG_ON(pmd_sect(*pmd));
 
 		if (pmd_none(*pmd)) {
-			pte = pte_alloc_one_kernel(NULL, hyp_addr);
+			pte = pte_alloc_one_kernel(NULL, addr);
 			if (!pte) {
 				kvm_err("Cannot allocate Hyp pte\n");
 				return -ENOMEM;
@@ -182,25 +162,17 @@ static int create_hyp_pmd_mappings(pud_t *pud, unsigned long start,
 
 		next = pmd_addr_end(addr, end);
 
-		/*
-		 * If pfn_base is NULL, we map kernel pages into HYP with the
-		 * virtual address. Otherwise, this is considered an I/O
-		 * mapping and we map the physical region starting at
-		 * *pfn_base to [start, end[.
-		 */
-		if (!pfn_base)
-			create_hyp_pte_mappings(pmd, addr, next);
-		else
-			create_hyp_io_pte_mappings(pmd, addr, next, pfn_base);
+		create_hyp_pte_mappings(pmd, addr, next, pfn, prot);
+		pfn += (next - addr) >> PAGE_SHIFT;
 	}
 
 	return 0;
 }
 
-static int __create_hyp_mappings(void *from, void *to, unsigned long *pfn_base)
+static int __create_hyp_mappings(pgd_t *pgdp,
+				 unsigned long start, unsigned long end,
+				 unsigned long pfn, pgprot_t prot)
 {
-	unsigned long start = (unsigned long)from;
-	unsigned long end = (unsigned long)to;
 	pgd_t *pgd;
 	pud_t *pud;
 	pmd_t *pmd;
@@ -209,21 +181,14 @@ static int __create_hyp_mappings(void *from, void *to, unsigned long *pfn_base)
 
 	if (start >= end)
 		return -EINVAL;
-	/* Check for a valid kernel memory mapping */
-	if (!pfn_base && (!virt_addr_valid(from) || !virt_addr_valid(to - 1)))
-		return -EINVAL;
-	/* Check for a valid kernel IO mapping */
-	if (pfn_base && (!is_vmalloc_addr(from) || !is_vmalloc_addr(to - 1)))
-		return -EINVAL;
 
 	mutex_lock(&kvm_hyp_pgd_mutex);
-	for (addr = start; addr < end; addr = next) {
-		unsigned long hyp_addr = KERN_TO_HYP(addr);
-		pgd = hyp_pgd + pgd_index(hyp_addr);
-		pud = pud_offset(pgd, hyp_addr);
+	for (addr = start & PAGE_MASK; addr < end; addr = next) {
+		pgd = pgdp + pgd_index(addr);
+		pud = pud_offset(pgd, addr);
 
 		if (pud_none_or_clear_bad(pud)) {
-			pmd = pmd_alloc_one(NULL, hyp_addr);
+			pmd = pmd_alloc_one(NULL, addr);
 			if (!pmd) {
 				kvm_err("Cannot allocate Hyp pmd\n");
 				err = -ENOMEM;
@@ -233,9 +198,10 @@ static int __create_hyp_mappings(void *from, void *to, unsigned long *pfn_base)
 		}
 
 		next = pgd_addr_end(addr, end);
-		err = create_hyp_pmd_mappings(pud, addr, next, pfn_base);
+		err = create_hyp_pmd_mappings(pud, addr, next, pfn, prot);
 		if (err)
 			goto out;
+		pfn += (next - addr) >> PAGE_SHIFT;
 	}
 out:
 	mutex_unlock(&kvm_hyp_pgd_mutex);
@@ -255,22 +221,38 @@ out:
  */
 int create_hyp_mappings(void *from, void *to)
 {
-	return __create_hyp_mappings(from, to, NULL);
+	unsigned long phys_addr = virt_to_phys(from);
+	unsigned long start = KERN_TO_HYP((unsigned long)from);
+	unsigned long end = KERN_TO_HYP((unsigned long)to);
+
+	/* Check for a valid kernel memory mapping */
+	if (!virt_addr_valid(from) || !virt_addr_valid(to - 1))
+		return -EINVAL;
+
+	return __create_hyp_mappings(hyp_pgd, start, end,
+				     __phys_to_pfn(phys_addr), PAGE_HYP);
 }
 
 /**
  * create_hyp_io_mappings - duplicate a kernel IO mapping into Hyp mode
  * @from:	The kernel start VA of the range
  * @to:		The kernel end VA of the range (exclusive)
- * @addr:	The physical start address which gets mapped
+ * @phys_addr:	The physical start address which gets mapped
  *
  * The resulting HYP VA is the same as the kernel VA, modulo
  * HYP_PAGE_OFFSET.
  */
-int create_hyp_io_mappings(void *from, void *to, phys_addr_t addr)
+int create_hyp_io_mappings(void *from, void *to, phys_addr_t phys_addr)
 {
-	unsigned long pfn = __phys_to_pfn(addr);
-	return __create_hyp_mappings(from, to, &pfn);
+	unsigned long start = KERN_TO_HYP((unsigned long)from);
+	unsigned long end = KERN_TO_HYP((unsigned long)to);
+
+	/* Check for a valid kernel IO mapping */
+	if (!is_vmalloc_addr(from) || !is_vmalloc_addr(to - 1))
+		return -EINVAL;
+
+	return __create_hyp_mappings(hyp_pgd, start, end,
+				     __phys_to_pfn(phys_addr), PAGE_HYP_DEVICE);
 }
 
 /**
-- 
1.8.1.4




From marc.zyngier at arm.com  Fri Apr 12 11:18:50 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Fri, 12 Apr 2013 16:18:50 +0100
Subject: [PATCH v3 5/7] ARM: KVM: rework HYP page table freeing
In-Reply-To: <1365779932-20322-1-git-send-email-marc.zyngier@arm.com>
References: <1365779932-20322-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1365779932-20322-6-git-send-email-marc.zyngier@arm.com>

There is no point in freeing HYP page tables differently from Stage-2.
They now have the same requirements, and should be dealt with the same way.

Promote unmap_stage2_range to be The One True Way, and get rid of a number
of nasty bugs in the process (goo thing we never actually called free_hyp_pmds
before...).

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm/include/asm/kvm_mmu.h |   2 +-
 arch/arm/kvm/arm.c             |   2 +-
 arch/arm/kvm/mmu.c             | 181 ++++++++++++++++++-----------------------
 3 files changed, 82 insertions(+), 103 deletions(-)

diff --git a/arch/arm/include/asm/kvm_mmu.h b/arch/arm/include/asm/kvm_mmu.h
index 3c71a1d..92eb20d 100644
--- a/arch/arm/include/asm/kvm_mmu.h
+++ b/arch/arm/include/asm/kvm_mmu.h
@@ -32,7 +32,7 @@
 
 int create_hyp_mappings(void *from, void *to);
 int create_hyp_io_mappings(void *from, void *to, phys_addr_t);
-void free_hyp_pmds(void);
+void free_hyp_pgds(void);
 
 int kvm_alloc_stage2_pgd(struct kvm *kvm);
 void kvm_free_stage2_pgd(struct kvm *kvm);
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index 23538ed..8992f05 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -937,7 +937,7 @@ static int init_hyp_mode(void)
 out_free_context:
 	free_percpu(kvm_host_cpu_state);
 out_free_mappings:
-	free_hyp_pmds();
+	free_hyp_pgds();
 out_free_stack_pages:
 	for_each_possible_cpu(cpu)
 		free_page(per_cpu(kvm_arm_hyp_stack_page, cpu));
diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
index bfc5927..7464824 100644
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@ -72,56 +72,104 @@ static void *mmu_memory_cache_alloc(struct kvm_mmu_memory_cache *mc)
 	return p;
 }
 
-static void free_ptes(pmd_t *pmd, unsigned long addr)
+static void clear_pud_entry(pud_t *pud)
 {
-	pte_t *pte;
-	unsigned int i;
+	pmd_t *pmd_table = pmd_offset(pud, 0);
+	pud_clear(pud);
+	pmd_free(NULL, pmd_table);
+	put_page(virt_to_page(pud));
+}
 
-	for (i = 0; i < PTRS_PER_PMD; i++, addr += PMD_SIZE) {
-		if (!pmd_none(*pmd) && pmd_table(*pmd)) {
-			pte = pte_offset_kernel(pmd, addr);
-			pte_free_kernel(NULL, pte);
-		}
-		pmd++;
+static void clear_pmd_entry(pmd_t *pmd)
+{
+	pte_t *pte_table = pte_offset_kernel(pmd, 0);
+	pmd_clear(pmd);
+	pte_free_kernel(NULL, pte_table);
+	put_page(virt_to_page(pmd));
+}
+
+static bool pmd_empty(pmd_t *pmd)
+{
+	struct page *pmd_page = virt_to_page(pmd);
+	return page_count(pmd_page) == 1;
+}
+
+static void clear_pte_entry(pte_t *pte)
+{
+	if (pte_present(*pte)) {
+		kvm_set_pte(pte, __pte(0));
+		put_page(virt_to_page(pte));
 	}
 }
 
-static void free_hyp_pgd_entry(unsigned long addr)
+static bool pte_empty(pte_t *pte)
+{
+	struct page *pte_page = virt_to_page(pte);
+	return page_count(pte_page) == 1;
+}
+
+static void unmap_range(pgd_t *pgdp, unsigned long long start, u64 size)
 {
 	pgd_t *pgd;
 	pud_t *pud;
 	pmd_t *pmd;
-	unsigned long hyp_addr = KERN_TO_HYP(addr);
+	pte_t *pte;
+	unsigned long long addr = start, end = start + size;
+	u64 range;
 
-	pgd = hyp_pgd + pgd_index(hyp_addr);
-	pud = pud_offset(pgd, hyp_addr);
+	while (addr < end) {
+		pgd = pgdp + pgd_index(addr);
+		pud = pud_offset(pgd, addr);
+		if (pud_none(*pud)) {
+			addr += PUD_SIZE;
+			continue;
+		}
 
-	if (pud_none(*pud))
-		return;
-	BUG_ON(pud_bad(*pud));
+		pmd = pmd_offset(pud, addr);
+		if (pmd_none(*pmd)) {
+			addr += PMD_SIZE;
+			continue;
+		}
 
-	pmd = pmd_offset(pud, hyp_addr);
-	free_ptes(pmd, addr);
-	pmd_free(NULL, pmd);
-	pud_clear(pud);
+		pte = pte_offset_kernel(pmd, addr);
+		clear_pte_entry(pte);
+		range = PAGE_SIZE;
+
+		/* If we emptied the pte, walk back up the ladder */
+		if (pte_empty(pte)) {
+			clear_pmd_entry(pmd);
+			range = PMD_SIZE;
+			if (pmd_empty(pmd)) {
+				clear_pud_entry(pud);
+				range = PUD_SIZE;
+			}
+		}
+
+		addr += range;
+	}
 }
 
 /**
- * free_hyp_pmds - free a Hyp-mode level-2 tables and child level-3 tables
+ * free_hyp_pgds - free Hyp-mode page tables
  *
- * Assumes this is a page table used strictly in Hyp-mode and therefore contains
+ * Assumes hyp_pgd is a page table used strictly in Hyp-mode and therefore contains
  * either mappings in the kernel memory area (above PAGE_OFFSET), or
  * device mappings in the vmalloc range (from VMALLOC_START to VMALLOC_END).
  */
-void free_hyp_pmds(void)
+void free_hyp_pgds(void)
 {
 	unsigned long addr;
 
 	mutex_lock(&kvm_hyp_pgd_mutex);
-	for (addr = PAGE_OFFSET; virt_addr_valid(addr); addr += PGDIR_SIZE)
-		free_hyp_pgd_entry(addr);
-	for (addr = VMALLOC_START; is_vmalloc_addr((void*)addr); addr += PGDIR_SIZE)
-		free_hyp_pgd_entry(addr);
+
+	if (hyp_pgd) {
+		for (addr = PAGE_OFFSET; virt_addr_valid(addr); addr += PGDIR_SIZE)
+			unmap_range(hyp_pgd, KERN_TO_HYP(addr), PGDIR_SIZE);
+		for (addr = VMALLOC_START; is_vmalloc_addr((void*)addr); addr += PGDIR_SIZE)
+			unmap_range(hyp_pgd, KERN_TO_HYP(addr), PGDIR_SIZE);
+		kfree(hyp_pgd);
+	}
+
 	mutex_unlock(&kvm_hyp_pgd_mutex);
 }
 
@@ -136,6 +184,7 @@ static void create_hyp_pte_mappings(pmd_t *pmd, unsigned long start,
 	do {
 		pte = pte_offset_kernel(pmd, addr);
 		kvm_set_pte(pte, pfn_pte(pfn, prot));
+		get_page(virt_to_page(pte));
 		pfn++;
 	} while (addr += PAGE_SIZE, addr != end);
 }
@@ -161,6 +210,7 @@ static int create_hyp_pmd_mappings(pud_t *pud, unsigned long start,
 				return -ENOMEM;
 			}
 			pmd_populate_kernel(NULL, pmd, pte);
+			get_page(virt_to_page(pmd));
 		}
 
 		next = pmd_addr_end(addr, end);
@@ -197,6 +247,7 @@ static int __create_hyp_mappings(pgd_t *pgdp,
 				goto out;
 			}
 			pud_populate(NULL, pud, pmd);
+			get_page(virt_to_page(pud));
 		}
 
 		next = pgd_addr_end(addr, end);
@@ -289,42 +340,6 @@ int kvm_alloc_stage2_pgd(struct kvm *kvm)
 	return 0;
 }
 
-static void clear_pud_entry(pud_t *pud)
-{
-	pmd_t *pmd_table = pmd_offset(pud, 0);
-	pud_clear(pud);
-	pmd_free(NULL, pmd_table);
-	put_page(virt_to_page(pud));
-}
-
-static void clear_pmd_entry(pmd_t *pmd)
-{
-	pte_t *pte_table = pte_offset_kernel(pmd, 0);
-	pmd_clear(pmd);
-	pte_free_kernel(NULL, pte_table);
-	put_page(virt_to_page(pmd));
-}
-
-static bool pmd_empty(pmd_t *pmd)
-{
-	struct page *pmd_page = virt_to_page(pmd);
-	return page_count(pmd_page) == 1;
-}
-
-static void clear_pte_entry(pte_t *pte)
-{
-	if (pte_present(*pte)) {
-		kvm_set_pte(pte, __pte(0));
-		put_page(virt_to_page(pte));
-	}
-}
-
-static bool pte_empty(pte_t *pte)
-{
-	struct page *pte_page = virt_to_page(pte);
-	return page_count(pte_page) == 1;
-}
-
 /**
  * unmap_stage2_range -- Clear stage2 page table entries to unmap a range
  * @kvm:   The VM pointer
@@ -338,43 +353,7 @@ static bool pte_empty(pte_t *pte)
  */
 static void unmap_stage2_range(struct kvm *kvm, phys_addr_t start, u64 size)
 {
-	pgd_t *pgd;
-	pud_t *pud;
-	pmd_t *pmd;
-	pte_t *pte;
-	phys_addr_t addr = start, end = start + size;
-	u64 range;
-
-	while (addr < end) {
-		pgd = kvm->arch.pgd + pgd_index(addr);
-		pud = pud_offset(pgd, addr);
-		if (pud_none(*pud)) {
-			addr += PUD_SIZE;
-			continue;
-		}
-
-		pmd = pmd_offset(pud, addr);
-		if (pmd_none(*pmd)) {
-			addr += PMD_SIZE;
-			continue;
-		}
-
-		pte = pte_offset_kernel(pmd, addr);
-		clear_pte_entry(pte);
-		range = PAGE_SIZE;
-
-		/* If we emptied the pte, walk back up the ladder */
-		if (pte_empty(pte)) {
-			clear_pmd_entry(pmd);
-			range = PMD_SIZE;
-			if (pmd_empty(pmd)) {
-				clear_pud_entry(pud);
-				range = PUD_SIZE;
-			}
-		}
-
-		addr += range;
-	}
+	unmap_range(kvm->arch.pgd, start, size);
 }
 
 /**
@@ -741,7 +720,7 @@ int kvm_mmu_init(void)
 
 	return 0;
 out:
-	kfree(hyp_pgd);
+	free_hyp_pgds();
 	return err;
 }
 
-- 
1.8.1.4




From marc.zyngier at arm.com  Fri Apr 12 11:18:52 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Fri, 12 Apr 2013 16:18:52 +0100
Subject: [PATCH v3 7/7] ARM: KVM: perform HYP initilization for hotplugged CPUs
In-Reply-To: <1365779932-20322-1-git-send-email-marc.zyngier@arm.com>
References: <1365779932-20322-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1365779932-20322-8-git-send-email-marc.zyngier@arm.com>

Now that we have the necessary infrastructure to boot a hotplugged CPU
at any point in time, wire a CPU notifier that will perform the HYP
init for the incoming CPU.

Note that this depends on the platform code and/or firmware to boot the
incoming CPU with HYP mode enabled and return to the kernel by following
the normal boot path (HYP stub installed).

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm/include/asm/kvm_mmu.h |  1 +
 arch/arm/kvm/arm.c             | 49 +++++++++++++++++++++++++++++-------------
 arch/arm/kvm/mmu.c             | 35 ++++++++++++++++++++++++------
 3 files changed, 63 insertions(+), 22 deletions(-)

diff --git a/arch/arm/include/asm/kvm_mmu.h b/arch/arm/include/asm/kvm_mmu.h
index 24b767a..472ac70 100644
--- a/arch/arm/include/asm/kvm_mmu.h
+++ b/arch/arm/include/asm/kvm_mmu.h
@@ -44,6 +44,7 @@
 
 int create_hyp_mappings(void *from, void *to);
 int create_hyp_io_mappings(void *from, void *to, phys_addr_t);
+void free_boot_hyp_pgd(void);
 void free_hyp_pgds(void);
 
 int kvm_alloc_stage2_pgd(struct kvm *kvm);
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index f8fbab3..fa177df 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -16,6 +16,7 @@
  * Foundation, 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.
  */
 
+#include <linux/cpu.h>
 #include <linux/errno.h>
 #include <linux/err.h>
 #include <linux/kvm_host.h>
@@ -794,7 +795,7 @@ long kvm_arch_vm_ioctl(struct file *filp,
 	}
 }
 
-static void cpu_init_hyp_mode(void *vector)
+static void cpu_init_hyp_mode(void *dummy)
 {
 	unsigned long long boot_pgd_ptr;
 	unsigned long long pgd_ptr;
@@ -814,12 +815,28 @@ static void cpu_init_hyp_mode(void *vector)
 	__cpu_init_hyp_mode(boot_pgd_ptr, pgd_ptr, hyp_stack_ptr, vector_ptr);
 }
 
+static int hyp_init_cpu_notify(struct notifier_block *self,
+			       unsigned long action, void *cpu)
+{
+	switch (action) {
+	case CPU_STARTING:
+	case CPU_STARTING_FROZEN:
+		cpu_init_hyp_mode(NULL);
+		break;
+	}
+
+	return NOTIFY_OK;
+}
+
+static struct notifier_block hyp_init_cpu_nb = {
+	.notifier_call = hyp_init_cpu_notify,
+};
+
 /**
  * Inits Hyp-mode on all online CPUs
  */
 static int init_hyp_mode(void)
 {
-	phys_addr_t init_phys_addr;
 	int cpu;
 	int err = 0;
 
@@ -852,19 +869,6 @@ static int init_hyp_mode(void)
 	}
 
 	/*
-	 * Execute the init code on each CPU.
-	 *
-	 * Note: The stack is not mapped yet, so don't do anything else than
-	 * initializing the hypervisor mode on each CPU using a local stack
-	 * space for temporary storage.
-	 */
-	init_phys_addr = virt_to_phys(__kvm_hyp_init);
-	for_each_online_cpu(cpu) {
-		smp_call_function_single(cpu, cpu_init_hyp_mode,
-					 (void *)(long)init_phys_addr, 1);
-	}
-
-	/*
 	 * Map the Hyp-code called directly from the host
 	 */
 	err = create_hyp_mappings(__kvm_hyp_code_start, __kvm_hyp_code_end);
@@ -909,6 +913,11 @@ static int init_hyp_mode(void)
 	}
 
 	/*
+	 * Execute the init code on each CPU.
+	 */
+	on_each_cpu(cpu_init_hyp_mode, NULL, 1);
+
+	/*
 	 * Init HYP view of VGIC
 	 */
 	err = kvm_vgic_hyp_init();
@@ -926,6 +935,10 @@ static int init_hyp_mode(void)
 	if (err)
 		goto out_free_mappings;
 
+#ifndef CONFIG_HOTPLUG_CPU
+	free_boot_hyp_pgd();
+#endif
+
 	kvm_perf_init();
 
 	kvm_info("Hyp mode initialized successfully\n");
@@ -964,6 +977,12 @@ int kvm_arch_init(void *opaque)
 	if (err)
 		goto out_err;
 
+	err = register_cpu_notifier(&hyp_init_cpu_nb);
+	if (err) {
+		kvm_err("Cannot register HYP init CPU notifier (%d)\n", err);
+		goto out_err;
+	}
+
 	kvm_coproc_table_init();
 	return 0;
 out_err:
diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
index afde82a..96a9227 100644
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@ -156,6 +156,31 @@ static void unmap_range(pgd_t *pgdp, unsigned long long start, u64 size)
 }
 
 /**
+ * free_boot_hyp_pgd - free HYP boot page tables
+ *
+ * Free the HYP boot page tables. The bounce page is also freed.
+ */
+void free_boot_hyp_pgd(void)
+{
+	mutex_lock(&kvm_hyp_pgd_mutex);
+
+	if (boot_hyp_pgd) {
+		unmap_range(boot_hyp_pgd, hyp_idmap_start, PAGE_SIZE);
+		unmap_range(boot_hyp_pgd, TRAMPOLINE_VA, PAGE_SIZE);
+		kfree(boot_hyp_pgd);
+		boot_hyp_pgd = NULL;
+	}
+
+	if (hyp_pgd)
+		unmap_range(hyp_pgd, TRAMPOLINE_VA, PAGE_SIZE);
+
+	kfree(init_bounce_page);
+	init_bounce_page = NULL;
+
+	mutex_unlock(&kvm_hyp_pgd_mutex);
+}
+
+/**
  * free_hyp_pgds - free Hyp-mode page tables
  *
  * Assumes hyp_pgd is a page table used strictly in Hyp-mode and
@@ -169,13 +194,9 @@ void free_hyp_pgds(void)
 {
 	unsigned long addr;
 
-	mutex_lock(&kvm_hyp_pgd_mutex);
+	free_boot_hyp_pgd();
 
-	if (boot_hyp_pgd) {
-		unmap_range(boot_hyp_pgd, hyp_idmap_start, PAGE_SIZE);
-		unmap_range(boot_hyp_pgd, TRAMPOLINE_VA, PAGE_SIZE);
-		kfree(boot_hyp_pgd);
-	}
+	mutex_lock(&kvm_hyp_pgd_mutex);
 
 	if (hyp_pgd) {
 		for (addr = PAGE_OFFSET; virt_addr_valid(addr); addr += PGDIR_SIZE)
@@ -183,9 +204,9 @@ void free_hyp_pgds(void)
 		for (addr = VMALLOC_START; is_vmalloc_addr((void*)addr); addr += PGDIR_SIZE)
 			unmap_range(hyp_pgd, KERN_TO_HYP(addr), PGDIR_SIZE);
 		kfree(hyp_pgd);
+		hyp_pgd = NULL;
 	}
 
-	kfree(init_bounce_page);
 	mutex_unlock(&kvm_hyp_pgd_mutex);
 }
 
-- 
1.8.1.4




From marc.zyngier at arm.com  Fri Apr 12 11:18:51 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Fri, 12 Apr 2013 16:18:51 +0100
Subject: [PATCH v3 6/7] ARM: KVM: switch to a dual-step HYP init code
In-Reply-To: <1365779932-20322-1-git-send-email-marc.zyngier@arm.com>
References: <1365779932-20322-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1365779932-20322-7-git-send-email-marc.zyngier@arm.com>

Our HYP init code suffers from two major design issues:
- it cannot support CPU hotplug, as we tear down the idmap very early
- it cannot perform a TLB invalidation when switching from init to
  runtime mappings, as pages are manipulated from PL1 exclusively

The hotplug problem mandates that we keep two sets of page tables
(boot and runtime). The TLB problem mandates that we're able to
transition from one PGD to another while in HYP, invalidating the TLBs
in the process.

To be able to do this, we need to share a page between the two page
tables. A page that will have the same VA in both configurations. All we
need is a VA that has the following properties:
- This VA can't be used to represent a kernel mapping.
- This VA will not conflict with the physical address of the kernel text

The vectors page seems to satisfy this requirement:
- The kernel never maps anything else there
- The kernel text being copied at the beginning of the physical memory,
  it is unlikely to use the last 64kB (I doubt we'll ever support KVM
  on a system with something like 4MB of RAM, but patches are very
  welcome).

Let's call this VA the trampoline VA.

Now, we map our init page at 3 locations:
- idmap in the boot pgd
- trampoline VA in the boot pgd
- trampoline VA in the runtime pgd

The init scenario is now the following:
- We jump in HYP with four parameters: boot HYP pgd, runtime HYP pgd,
  runtime stack, runtime vectors
- Enable the MMU with the boot pgd
- Jump to a target into the trampoline page (remember, this is the same
  physical page!)
- Now switch to the runtime pgd (same VA, and still the same physical
  page!)
- Invalidate TLBs
- Set stack and vectors
- Profit! (or eret, if you only care about the code).

Note that we keep the boot mapping permanently (it is not strictly an
idmap anymore) to allow for CPU hotplug in later patches.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm/include/asm/kvm_host.h |  31 +++++----
 arch/arm/include/asm/kvm_mmu.h  |  24 ++++++-
 arch/arm/kvm/arm.c              |  11 ++--
 arch/arm/kvm/init.S             |  78 +++++++++++++++++------
 arch/arm/kvm/mmu.c              | 135 +++++++++++++++++++++++++++++-----------
 5 files changed, 200 insertions(+), 79 deletions(-)

diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
index a2907fb..57cb786 100644
--- a/arch/arm/include/asm/kvm_host.h
+++ b/arch/arm/include/asm/kvm_host.h
@@ -190,23 +190,30 @@ int kvm_arm_coproc_set_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *);
 int handle_exit(struct kvm_vcpu *vcpu, struct kvm_run *run,
 		int exception_index);
 
-static inline void __cpu_init_hyp_mode(unsigned long long pgd_ptr,
+static inline void __cpu_init_hyp_mode(unsigned long long boot_pgd_ptr,
+				       unsigned long long pgd_ptr,
 				       unsigned long hyp_stack_ptr,
 				       unsigned long vector_ptr)
 {
-	unsigned long pgd_low, pgd_high;
-
-	pgd_low = (pgd_ptr & ((1ULL << 32) - 1));
-	pgd_high = (pgd_ptr >> 32ULL);
-
 	/*
-	 * Call initialization code, and switch to the full blown
-	 * HYP code. The init code doesn't need to preserve these registers as
-	 * r1-r3 and r12 are already callee save according to the AAPCS.
-	 * Note that we slightly misuse the prototype by casing the pgd_low to
-	 * a void *.
+	 * Call initialization code, and switch to the full blown HYP
+	 * code. The init code doesn't need to preserve these
+	 * registers as r0-r3 are already callee saved according to
+	 * the AAPCS.
+	 * Note that we slightly misuse the prototype by casing the
+	 * stack pointer to a void *.
+	 *
+	 * We don't have enough registers to perform the full init in
+	 * one go.  Install the boot PGD first, and then install the
+	 * runtime PGD, stack pointer and vectors. The PGDs are always
+	 * passed as the third argument, in order to be passed into
+	 * r2-r3 to the init code (yes, this is compliant with the
+	 * PCS!).
 	 */
-	kvm_call_hyp((void *)pgd_low, pgd_high, hyp_stack_ptr, vector_ptr);
+
+	kvm_call_hyp(NULL, 0, boot_pgd_ptr);
+
+	kvm_call_hyp((void*)hyp_stack_ptr, vector_ptr, pgd_ptr);
 }
 
 static inline int kvm_arch_dev_ioctl_check_extension(long ext)
diff --git a/arch/arm/include/asm/kvm_mmu.h b/arch/arm/include/asm/kvm_mmu.h
index 92eb20d..24b767a 100644
--- a/arch/arm/include/asm/kvm_mmu.h
+++ b/arch/arm/include/asm/kvm_mmu.h
@@ -19,17 +19,29 @@
 #ifndef __ARM_KVM_MMU_H__
 #define __ARM_KVM_MMU_H__
 
-#include <asm/cacheflush.h>
-#include <asm/pgalloc.h>
+#include <asm/memory.h>
+#include <asm/page.h>
 
 /*
  * We directly use the kernel VA for the HYP, as we can directly share
  * the mapping (HTTBR "covers" TTBR1).
  */
-#define HYP_PAGE_OFFSET_MASK	(~0UL)
+#define HYP_PAGE_OFFSET_MASK	UL(~0)
 #define HYP_PAGE_OFFSET		PAGE_OFFSET
 #define KERN_TO_HYP(kva)	(kva)
 
+/*
+ * Our virtual mapping for the boot-time MMU-enable code. Must be
+ * shared across all the page-tables. Conveniently, we use the vectors
+ * page, where no kernel data will ever be shared with HYP.
+ */
+#define TRAMPOLINE_VA		UL(CONFIG_VECTORS_BASE)
+
+#ifndef __ASSEMBLY__
+
+#include <asm/cacheflush.h>
+#include <asm/pgalloc.h>
+
 int create_hyp_mappings(void *from, void *to);
 int create_hyp_io_mappings(void *from, void *to, phys_addr_t);
 void free_hyp_pgds(void);
@@ -44,6 +56,8 @@ int kvm_handle_guest_abort(struct kvm_vcpu *vcpu, struct kvm_run *run);
 void kvm_mmu_free_memory_caches(struct kvm_vcpu *vcpu);
 
 phys_addr_t kvm_mmu_get_httbr(void);
+phys_addr_t kvm_mmu_get_boot_httbr(void);
+phys_addr_t kvm_get_idmap_vector(void);
 int kvm_mmu_init(void);
 void kvm_clear_hyp_idmap(void);
 
@@ -113,4 +127,8 @@ static inline void coherent_icache_guest_page(struct kvm *kvm, gfn_t gfn)
 	}
 }
 
+#define kvm_flush_dcache_to_poc(a,l)	__cpuc_flush_dcache_area((a), (l))
+
+#endif	/* !__ASSEMBLY__ */
+
 #endif /* __ARM_KVM_MMU_H__ */
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index 8992f05..f8fbab3 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -796,20 +796,22 @@ long kvm_arch_vm_ioctl(struct file *filp,
 
 static void cpu_init_hyp_mode(void *vector)
 {
+	unsigned long long boot_pgd_ptr;
 	unsigned long long pgd_ptr;
 	unsigned long hyp_stack_ptr;
 	unsigned long stack_page;
 	unsigned long vector_ptr;
 
 	/* Switch from the HYP stub to our own HYP init vector */
-	__hyp_set_vectors((unsigned long)vector);
+	__hyp_set_vectors(kvm_get_idmap_vector());
 
+	boot_pgd_ptr = (unsigned long long)kvm_mmu_get_boot_httbr();
 	pgd_ptr = (unsigned long long)kvm_mmu_get_httbr();
 	stack_page = __get_cpu_var(kvm_arm_hyp_stack_page);
 	hyp_stack_ptr = stack_page + PAGE_SIZE;
 	vector_ptr = (unsigned long)__kvm_hyp_vector;
 
-	__cpu_init_hyp_mode(pgd_ptr, hyp_stack_ptr, vector_ptr);
+	__cpu_init_hyp_mode(boot_pgd_ptr, pgd_ptr, hyp_stack_ptr, vector_ptr);
 }
 
 /**
@@ -863,11 +865,6 @@ static int init_hyp_mode(void)
 	}
 
 	/*
-	 * Unmap the identity mapping
-	 */
-	kvm_clear_hyp_idmap();
-
-	/*
 	 * Map the Hyp-code called directly from the host
 	 */
 	err = create_hyp_mappings(__kvm_hyp_code_start, __kvm_hyp_code_end);
diff --git a/arch/arm/kvm/init.S b/arch/arm/kvm/init.S
index 9f37a79..f048338 100644
--- a/arch/arm/kvm/init.S
+++ b/arch/arm/kvm/init.S
@@ -21,13 +21,33 @@
 #include <asm/asm-offsets.h>
 #include <asm/kvm_asm.h>
 #include <asm/kvm_arm.h>
+#include <asm/kvm_mmu.h>
 
 /********************************************************************
  * Hypervisor initialization
  *   - should be called with:
- *       r0,r1 = Hypervisor pgd pointer
- *       r2 = top of Hyp stack (kernel VA)
- *       r3 = pointer to hyp vectors
+ *       r0 = top of Hyp stack (kernel VA)
+ *       r1 = pointer to hyp vectors
+ *       r2,r3 = Hypervisor pgd pointer
+ *
+ * The init scenario is:
+ * - We jump in HYP with four parameters: boot HYP pgd, runtime HYP pgd,
+ *   runtime stack, runtime vectors
+ * - Enable the MMU with the boot pgd
+ * - Jump to a target into the trampoline page (remember, this is the same
+ *   physical page!)
+ * - Now switch to the runtime pgd (same VA, and still the same physical
+ *   page!)
+ * - Invalidate TLBs
+ * - Set stack and vectors
+ * - Profit! (or eret, if you only care about the code).
+ *
+ * As we only have four registers available to pass parameters (and we
+ * need six), we split the init in two phases:
+ * - Phase 1: r0 = 0, r1 = 0, r2,r3 contain the boot PGD.
+ *   Provides the basic HYP init, and enable the MMU.
+ * - Phase 2: r0 = ToS, r1 = vectors, r2,r3 contain the runtime PGD.
+ *   Switches to the runtime PGD, set stack and vectors.
  */
 
 	.text
@@ -47,22 +67,25 @@ __kvm_hyp_init:
 	W(b)	.
 
 __do_hyp_init:
+	cmp	r0, #0			@ We have a SP?
+	bne	phase2			@ Yes, second stage init
+
 	@ Set the HTTBR to point to the hypervisor PGD pointer passed
-	mcrr	p15, 4, r0, r1, c2
+	mcrr	p15, 4, r2, r3, c2
 
 	@ Set the HTCR and VTCR to the same shareability and cacheability
 	@ settings as the non-secure TTBCR and with T0SZ == 0.
 	mrc	p15, 4, r0, c2, c0, 2	@ HTCR
-	ldr	r12, =HTCR_MASK
-	bic	r0, r0, r12
+	ldr	r2, =HTCR_MASK
+	bic	r0, r0, r2
 	mrc	p15, 0, r1, c2, c0, 2	@ TTBCR
 	and	r1, r1, #(HTCR_MASK & ~TTBCR_T0SZ)
 	orr	r0, r0, r1
 	mcr	p15, 4, r0, c2, c0, 2	@ HTCR
 
 	mrc	p15, 4, r1, c2, c1, 2	@ VTCR
-	ldr	r12, =VTCR_MASK
-	bic	r1, r1, r12
+	ldr	r2, =VTCR_MASK
+	bic	r1, r1, r2
 	bic	r0, r0, #(~VTCR_HTCR_SH)	@ clear non-reusable HTCR bits
 	orr	r1, r0, r1
 	orr	r1, r1, #(KVM_VTCR_SL0 | KVM_VTCR_T0SZ | KVM_VTCR_S)
@@ -85,24 +108,41 @@ __do_hyp_init:
 	@  - Memory alignment checks: enabled
 	@  - MMU: enabled (this code must be run from an identity mapping)
 	mrc	p15, 4, r0, c1, c0, 0	@ HSCR
-	ldr	r12, =HSCTLR_MASK
-	bic	r0, r0, r12
+	ldr	r2, =HSCTLR_MASK
+	bic	r0, r0, r2
 	mrc	p15, 0, r1, c1, c0, 0	@ SCTLR
-	ldr	r12, =(HSCTLR_EE | HSCTLR_FI | HSCTLR_I | HSCTLR_C)
-	and	r1, r1, r12
- ARM(	ldr	r12, =(HSCTLR_M | HSCTLR_A)			)
- THUMB(	ldr	r12, =(HSCTLR_M | HSCTLR_A | HSCTLR_TE)		)
-	orr	r1, r1, r12
+	ldr	r2, =(HSCTLR_EE | HSCTLR_FI | HSCTLR_I | HSCTLR_C)
+	and	r1, r1, r2
+ ARM(	ldr	r2, =(HSCTLR_M | HSCTLR_A)			)
+ THUMB(	ldr	r2, =(HSCTLR_M | HSCTLR_A | HSCTLR_TE)		)
+	orr	r1, r1, r2
 	orr	r0, r0, r1
 	isb
 	mcr	p15, 4, r0, c1, c0, 0	@ HSCR
-	isb
 
-	@ Set stack pointer and return to the kernel
-	mov	sp, r2
+	@ End of init phase-1
+	eret
+
+phase2:
+	@ Set stack pointer
+	mov	sp, r0
 
 	@ Set HVBAR to point to the HYP vectors
-	mcr	p15, 4, r3, c12, c0, 0	@ HVBAR
+	mcr	p15, 4, r1, c12, c0, 0	@ HVBAR
+
+	@ Jump to the trampoline page
+	ldr	r0, =TRAMPOLINE_VA
+	adr	r1, target
+	bfi	r0, r1, #0, #PAGE_SHIFT
+	mov	pc, r0
+
+target:	@ We're now in the trampoline code, switch page tables
+	mcrr	p15, 4, r2, r3, c2
+	isb
+
+	@ Invalidate the old TLBs
+	mcr	p15, 4, r0, c8, c7, 0	@ TLBIALLH
+	dsb
 
 	eret
 
diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
index 7464824..afde82a 100644
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@ -32,9 +32,15 @@
 
 extern char  __hyp_idmap_text_start[], __hyp_idmap_text_end[];
 
+static pgd_t *boot_hyp_pgd;
 static pgd_t *hyp_pgd;
 static DEFINE_MUTEX(kvm_hyp_pgd_mutex);
 
+static void *init_bounce_page;
+static unsigned long hyp_idmap_start;
+static unsigned long hyp_idmap_end;
+static phys_addr_t hyp_idmap_vector;
+
 static void kvm_tlb_flush_vmid_ipa(struct kvm *kvm, phys_addr_t ipa)
 {
 	kvm_call_hyp(__kvm_tlb_flush_vmid_ipa, kvm, ipa);
@@ -152,9 +158,12 @@ static void unmap_range(pgd_t *pgdp, unsigned long long start, u64 size)
 /**
  * free_hyp_pgds - free Hyp-mode page tables
  *
- * Assumes hyp_pgd is a page table used strictly in Hyp-mode and therefore contains
- * either mappings in the kernel memory area (above PAGE_OFFSET), or
- * device mappings in the vmalloc range (from VMALLOC_START to VMALLOC_END).
+ * Assumes hyp_pgd is a page table used strictly in Hyp-mode and
+ * therefore contains either mappings in the kernel memory area (above
+ * PAGE_OFFSET), or device mappings in the vmalloc range (from
+ * VMALLOC_START to VMALLOC_END).
+ *
+ * boot_hyp_pgd should only map two pages for the init code.
  */
 void free_hyp_pgds(void)
 {
@@ -162,6 +171,12 @@ void free_hyp_pgds(void)
 
 	mutex_lock(&kvm_hyp_pgd_mutex);
 
+	if (boot_hyp_pgd) {
+		unmap_range(boot_hyp_pgd, hyp_idmap_start, PAGE_SIZE);
+		unmap_range(boot_hyp_pgd, TRAMPOLINE_VA, PAGE_SIZE);
+		kfree(boot_hyp_pgd);
+	}
+
 	if (hyp_pgd) {
 		for (addr = PAGE_OFFSET; virt_addr_valid(addr); addr += PGDIR_SIZE)
 			unmap_range(hyp_pgd, KERN_TO_HYP(addr), PGDIR_SIZE);
@@ -170,6 +185,7 @@ void free_hyp_pgds(void)
 		kfree(hyp_pgd);
 	}
 
+	kfree(init_bounce_page);
 	mutex_unlock(&kvm_hyp_pgd_mutex);
 }
 
@@ -185,6 +201,7 @@ static void create_hyp_pte_mappings(pmd_t *pmd, unsigned long start,
 		pte = pte_offset_kernel(pmd, addr);
 		kvm_set_pte(pte, pfn_pte(pfn, prot));
 		get_page(virt_to_page(pte));
+		kvm_flush_dcache_to_poc(pte, sizeof(*pte));
 		pfn++;
 	} while (addr += PAGE_SIZE, addr != end);
 }
@@ -211,6 +228,7 @@ static int create_hyp_pmd_mappings(pud_t *pud, unsigned long start,
 			}
 			pmd_populate_kernel(NULL, pmd, pte);
 			get_page(virt_to_page(pmd));
+			kvm_flush_dcache_to_poc(pmd, sizeof(*pmd));
 		}
 
 		next = pmd_addr_end(addr, end);
@@ -247,7 +265,11 @@ static int __create_hyp_mappings(pgd_t *pgdp,
 				goto out;
 			}
 			pud_populate(NULL, pud, pmd);
+<<<<<<< HEAD
 			get_page(virt_to_page(pud));
+=======
+			kvm_flush_dcache_to_poc(pud, sizeof(*pud));
+>>>>>>> 180de35... ARM: KVM: switch to a dual-step HYP init code
 		}
 
 		next = pgd_addr_end(addr, end);
@@ -689,18 +711,64 @@ void kvm_mmu_free_memory_caches(struct kvm_vcpu *vcpu)
 
 phys_addr_t kvm_mmu_get_httbr(void)
 {
-	VM_BUG_ON(!virt_addr_valid(hyp_pgd));
 	return virt_to_phys(hyp_pgd);
 }
 
+phys_addr_t kvm_mmu_get_boot_httbr(void)
+{
+	return virt_to_phys(boot_hyp_pgd);
+}
+
+phys_addr_t kvm_get_idmap_vector(void)
+{
+	return hyp_idmap_vector;
+}
+
 int kvm_mmu_init(void)
 {
-	unsigned long hyp_idmap_start = virt_to_phys(__hyp_idmap_text_start);
-	unsigned long hyp_idmap_end = virt_to_phys(__hyp_idmap_text_end);
 	int err;
 
+	hyp_idmap_start = virt_to_phys(__hyp_idmap_text_start);
+	hyp_idmap_end = virt_to_phys(__hyp_idmap_text_end);
+	hyp_idmap_vector = virt_to_phys(__kvm_hyp_init);
+
+	if ((hyp_idmap_start ^ hyp_idmap_end) & PAGE_MASK) {
+		/*
+		 * Our init code is crossing a page boundary. Allocate
+		 * a bounce page, copy the code over and use that.
+		 */
+		size_t len = __hyp_idmap_text_end - __hyp_idmap_text_start;
+		phys_addr_t phys_base;
+
+		init_bounce_page = kmalloc(PAGE_SIZE, GFP_KERNEL);
+		if (!init_bounce_page) {
+			kvm_err("Couldn't allocate HYP init bounce page\n");
+			err = -ENOMEM;
+			goto out;
+		}
+
+		memcpy(init_bounce_page, __hyp_idmap_text_start, len);
+		/*
+		 * Warning: the code we just copied to the bounce page
+		 * must be flushed to the point of coherency.
+		 * Otherwise, the data may be sitting in L2, and HYP
+		 * mode won't be able to observe it as it runs with
+		 * caches off at that point.
+		 */
+		kvm_flush_dcache_to_poc(init_bounce_page, len);
+
+		phys_base = virt_to_phys(init_bounce_page);
+		hyp_idmap_vector += phys_base - hyp_idmap_start;
+		hyp_idmap_start = phys_base;
+		hyp_idmap_end = phys_base + len;
+
+		kvm_info("Using HYP init bounce page @%lx\n",
+			 (unsigned long)phys_base);
+	}
+
 	hyp_pgd = kzalloc(PTRS_PER_PGD * sizeof(pgd_t), GFP_KERNEL);
-	if (!hyp_pgd) {
+	boot_hyp_pgd = kzalloc(PTRS_PER_PGD * sizeof(pgd_t), GFP_KERNEL);
+	if (!hyp_pgd || !boot_hyp_pgd) {
 		kvm_err("Hyp mode PGD not allocated\n");
 		err = -ENOMEM;
 		goto out;
@@ -718,39 +786,30 @@ int kvm_mmu_init(void)
 		goto out;
 	}
 
+	/* Map the very same page at the trampoline VA */
+	err = 	__create_hyp_mappings(boot_hyp_pgd,
+				      TRAMPOLINE_VA, TRAMPOLINE_VA + PAGE_SIZE,
+				      __phys_to_pfn(hyp_idmap_start),
+				      PAGE_HYP);
+	if (err) {
+		kvm_err("Failed to map trampoline @%lx into boot HYP pgd\n",
+			TRAMPOLINE_VA);
+		goto out;
+	}
+
+	/* Map the same page again into the runtime page tables */
+	err = 	__create_hyp_mappings(hyp_pgd,
+				      TRAMPOLINE_VA, TRAMPOLINE_VA + PAGE_SIZE,
+				      __phys_to_pfn(hyp_idmap_start),
+				      PAGE_HYP);
+	if (err) {
+		kvm_err("Failed to map trampoline @%lx into runtime HYP pgd\n",
+			TRAMPOLINE_VA);
+		goto out;
+	}
+
 	return 0;
 out:
 	free_hyp_pgds();
 	return err;
 }
-
-/**
- * kvm_clear_idmap - remove all idmaps from the hyp pgd
- *
- * Free the underlying pmds for all pgds in range and clear the pgds (but
- * don't free them) afterwards.
- */
-void kvm_clear_hyp_idmap(void)
-{
-	unsigned long addr, end;
-	unsigned long next;
-	pgd_t *pgd = hyp_pgd;
-	pud_t *pud;
-	pmd_t *pmd;
-
-	addr = virt_to_phys(__hyp_idmap_text_start);
-	end = virt_to_phys(__hyp_idmap_text_end);
-
-	pgd += pgd_index(addr);
-	do {
-		next = pgd_addr_end(addr, end);
-		if (pgd_none_or_clear_bad(pgd))
-			continue;
-		pud = pud_offset(pgd, addr);
-		pmd = pmd_offset(pud, addr);
-
-		pud_clear(pud);
-		kvm_clean_pmd_entry(pmd);
-		pmd_free(NULL, (pmd_t *)((unsigned long)pmd & PAGE_MASK));
-	} while (pgd++, addr = next, addr < end);
-}
-- 
1.8.1.4




From arnd at arndb.de  Fri Apr 12 11:19:41 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 12 Apr 2013 17:19:41 +0200
Subject: [PATCH 2/2] ARM: remove all trivial init_machine callbacks
In-Reply-To: <1365779468-116419-2-git-send-email-arnd@arndb.de>
References: <1365779468-116419-1-git-send-email-arnd@arndb.de>
 <1365779468-116419-2-git-send-email-arnd@arndb.de>
Message-ID: <201304121719.41580.arnd@arndb.de>

On Friday 12 April 2013, Arnd Bergmann wrote:
> 
> -static void __init exynos4_dt_machine_init(void)
> -{
> -       of_platform_populate(NULL, of_default_bus_match_table,
> -                               exynos4_auxdata_lookup, NULL);
> -}
> -

This part was wrong, sorry. In the kernel I used as a base, we
actually still need exynos4_auxdata_lookup, so this patch actually
changes the behavior. In the for-next branch however, the auxdata
is gone.

	Arnd


From swarren at wwwdotorg.org  Fri Apr 12 11:22:20 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Fri, 12 Apr 2013 09:22:20 -0600
Subject: Kexec couldn't reboot capture kernel on pandaboard ES with
 OMAP4460
In-Reply-To: <20130412104528.GE12363@mudshark.cambridge.arm.com>
References: <CAFNq8R5FFUyH+JgjoGc5ctgEfiLvxzi7fzawM7+wFX5nEyTv-w@mail.gmail.com>
 <51658B1A.6090706@wwwdotorg.org>
 <CAFNq8R6mRJRygfnYvZgwVWOqsrhrjNUYzyZGU0cVsnE30W_xGg@mail.gmail.com>
 <5166E289.8070104@wwwdotorg.org>
 <20130412104528.GE12363@mudshark.cambridge.arm.com>
Message-ID: <516826AC.20006@wwwdotorg.org>

On 04/12/2013 04:45 AM, Will Deacon wrote:
...
> Back to the SMP point: Stephen, did you ever get anywhere with that
> disable_nonboot_cpus thread from a few months back? I'm still keen to get
> that working, and I *thought* we had a potential solution...

No, I've been side-tracked on too many other things to follow up on that:-(


From marc.zyngier at arm.com  Fri Apr 12 11:22:46 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Fri, 12 Apr 2013 16:22:46 +0100
Subject: [PATCH v3 02/32] arm64: KVM: define HYP and Stage-2 translation
 page flags
In-Reply-To: <20130410140706.GF26992@mudshark.cambridge.arm.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
 <1365437854-30214-3-git-send-email-marc.zyngier@arm.com>
 <20130410140706.GF26992@mudshark.cambridge.arm.com>
Message-ID: <516826C6.60603@arm.com>

On 10/04/13 15:07, Will Deacon wrote:
> On Mon, Apr 08, 2013 at 05:17:04PM +0100, Marc Zyngier wrote:
>> Add HYP and S2 page flags, for both normal and device memory.
>>
>> Reviewed-by: Christopher Covington <cov at codeaurora.org>
>> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
>> ---
>>  arch/arm64/include/asm/pgtable-hwdef.h | 13 +++++++++++++
>>  arch/arm64/include/asm/pgtable.h       | 12 ++++++++++++
>>  2 files changed, 25 insertions(+)
>>
>> diff --git a/arch/arm64/include/asm/pgtable-hwdef.h b/arch/arm64/include/asm/pgtable-hwdef.h
>> index 75fd13d..acb4ee5 100644
>> --- a/arch/arm64/include/asm/pgtable-hwdef.h
>> +++ b/arch/arm64/include/asm/pgtable-hwdef.h
>> @@ -35,6 +35,7 @@
>>  /*
>>   * Section
>>   */
>> +#define PMD_SECT_USER		(_AT(pteval_t, 1) << 6)		/* AP[1] */
>>  #define PMD_SECT_S		(_AT(pmdval_t, 3) << 8)
>>  #define PMD_SECT_AF		(_AT(pmdval_t, 1) << 10)
>>  #define PMD_SECT_NG		(_AT(pmdval_t, 1) << 11)
>> @@ -68,6 +69,18 @@
>>  #define PTE_ATTRINDX_MASK	(_AT(pteval_t, 7) << 2)
>>  
>>  /*
>> + * 2nd stage PTE definitions
>> + */
>> +#define PTE_S2_RDONLY		 (_AT(pteval_t, 1) << 6)   /* HAP[1]   */
>> +#define PTE_S2_RDWR		 (_AT(pteval_t, 2) << 6)   /* HAP[2:1] */
> 
> Is this correct? My reading of the translation spec is that this is
> write-only.

Mumble mumble... This is wrong, hidden by some other bug, and 32bit
suffers from the same defect (though it seems to work fine...). Irk!

>> +
>> +/*
>> + * EL2/HYP PTE/PMD definitions
>> + */
>> +#define PMD_HYP			PMD_SECT_USER
>> +#define PTE_HYP			PTE_USER
>> +
>> +/*
>>   * 40-bit physical address supported.
>>   */
>>  #define PHYS_MASK_SHIFT		(40)
>> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
>> index e333a24..7c84ab4 100644
>> --- a/arch/arm64/include/asm/pgtable.h
>> +++ b/arch/arm64/include/asm/pgtable.h
>> @@ -76,6 +76,12 @@ extern pgprot_t pgprot_default;
>>  #define PAGE_KERNEL		_MOD_PROT(pgprot_default, PTE_PXN | PTE_UXN | PTE_DIRTY)
>>  #define PAGE_KERNEL_EXEC	_MOD_PROT(pgprot_default, PTE_UXN | PTE_DIRTY)
>>  
>> +#define PAGE_HYP		_MOD_PROT(pgprot_default, PTE_HYP)
>> +#define PAGE_HYP_DEVICE		_MOD_PROT(__pgprot(PROT_DEVICE_nGnRE), PTE_HYP)
> 
> You're dragging in UXN and PXN bits from PROT_DEVICE_nGnRE, which I don't
> think exist at EL2.

They do exist at EL2, but not in S2. I'll fix that as well.

>> +#define PAGE_S2			_MOD_PROT(pgprot_default, PTE_USER | PTE_S2_RDONLY)
>> +#define PAGE_S2_DEVICE		_MOD_PROT(__pgprot(PROT_DEVICE_nGnRE), PTE_USER | PTE_S2_RDWR)
> 
> You shouldn't set the user bit for stage-2 entries.

Yeah, I already fixed that one.

Thanks!

	M.
-- 
Jazz is not dead. It just smells funny...



From marc.zyngier at arm.com  Fri Apr 12 11:29:18 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Fri, 12 Apr 2013 16:29:18 +0100
Subject: [PATCH v3 07/32] arm64: KVM: fault injection into a guest
In-Reply-To: <20130410164038.GI26992@mudshark.cambridge.arm.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
 <1365437854-30214-8-git-send-email-marc.zyngier@arm.com>
 <20130410164038.GI26992@mudshark.cambridge.arm.com>
Message-ID: <5168284E.6030407@arm.com>

On 10/04/13 17:40, Will Deacon wrote:
> On Mon, Apr 08, 2013 at 05:17:09PM +0100, Marc Zyngier wrote:
>> Implement the injection of a fault (undefined, data abort or
>> prefetch abort) into a 64bit guest.
>>
>> Reviewed-by: Christopher Covington <cov at codeaurora.org>
>> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
>> ---
>>  arch/arm64/kvm/inject_fault.c | 118 ++++++++++++++++++++++++++++++++++++++++++
>>  1 file changed, 118 insertions(+)
>>  create mode 100644 arch/arm64/kvm/inject_fault.c
>>
>> diff --git a/arch/arm64/kvm/inject_fault.c b/arch/arm64/kvm/inject_fault.c
>> new file mode 100644
>> index 0000000..2ff3b78
>> --- /dev/null
>> +++ b/arch/arm64/kvm/inject_fault.c
>> @@ -0,0 +1,118 @@
>> +/*
>> + * Fault injection for 64bit guests.
>> + *
>> + * Copyright (C) 2012,2013 - ARM Ltd
>> + * Author: Marc Zyngier <marc.zyngier at arm.com>
>> + *
>> + * Based on arch/arm/kvm/emulate.c
>> + * Copyright (C) 2012 - Virtual Open Systems and Columbia University
>> + * Author: Christoffer Dall <c.dall at virtualopensystems.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.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
>> + */
>> +
>> +#include <linux/kvm_host.h>
>> +#include <asm/kvm_emulate.h>
>> +#include <asm/esr.h>
>> +
>> +static void inject_abt64(struct kvm_vcpu *vcpu, bool is_iabt, unsigned long addr)
>> +{
>> +	unsigned long cpsr = *vcpu_cpsr(vcpu);
>> +	int is_aarch32;
>> +	u32 esr = 0;
>> +
>> +	is_aarch32 = vcpu_mode_is_32bit(vcpu);
>> +
>> +	*vcpu_spsr(vcpu) = cpsr;
>> +	*vcpu_elr_el1(vcpu) = *vcpu_pc(vcpu);
>> +
>> +	*vcpu_cpsr(vcpu) = PSR_MODE_EL1h | PSR_A_BIT | PSR_F_BIT | PSR_I_BIT;
> 
> You probably want to set PSR_D_BIT too.

Ah! I didn't realize Debug was disabled on exception entry. I'll fix that.

>> +	*vcpu_pc(vcpu) = vcpu_sys_reg(vcpu, VBAR_EL1) + 0x200;
>> +
>> +	vcpu_sys_reg(vcpu, FAR_EL1) = addr;
>> +
>> +	/*
>> +	 * Build an {i,d}abort, depending on the level and the
>> +	 * instruction set. Report an external synchronous abort.
>> +	 */
>> +	if (kvm_vcpu_trap_il_is32bit(vcpu))
>> +		esr |= ESR_EL1_IL;
>> +
>> +	if (is_aarch32 || (cpsr & PSR_MODE_MASK) == PSR_MODE_EL0t)
>> +		esr |= (ESR_EL1_EC_IABT_EL0 << ESR_EL1_EC_SHIFT);
>> +	else
>> +		esr |= (ESR_EL1_EC_IABT_EL1 << ESR_EL1_EC_SHIFT);
>> +
>> +	if (!is_iabt)
>> +		esr |= ESR_EL1_EC_DABT_EL0;
>> +
>> +	vcpu_sys_reg(vcpu, ESR_EL1) = esr | 0x10; /* External abort */
>> +}
> 
> Probably worth #defining the el1_sync offset and also the esr external abort
> class.

Sure.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...



From marc.zyngier at arm.com  Fri Apr 12 11:31:21 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Fri, 12 Apr 2013 16:31:21 +0100
Subject: [PATCH v3 09/32] arm64: KVM: user space interface
In-Reply-To: <20130410164509.GJ26992@mudshark.cambridge.arm.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
 <1365437854-30214-10-git-send-email-marc.zyngier@arm.com>
 <20130410164509.GJ26992@mudshark.cambridge.arm.com>
Message-ID: <516828C9.7020701@arm.com>

On 10/04/13 17:45, Will Deacon wrote:
> On Mon, Apr 08, 2013 at 05:17:11PM +0100, Marc Zyngier wrote:
>> Provide the kvm.h file that defines the user space visible
>> interface.
>>
>> Reviewed-by: Christopher Covington <cov at codeaurora.org>
>> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
>> ---
>>  arch/arm64/include/uapi/asm/kvm.h | 117 ++++++++++++++++++++++++++++++++++++++
>>  1 file changed, 117 insertions(+)
>>  create mode 100644 arch/arm64/include/uapi/asm/kvm.h
>>
>> diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
>> new file mode 100644
>> index 0000000..4e64570
>> --- /dev/null
>> +++ b/arch/arm64/include/uapi/asm/kvm.h
>> @@ -0,0 +1,117 @@
>> +/*
>> + * Copyright (C) 2012,2013 - ARM Ltd
>> + * Author: Marc Zyngier <marc.zyngier at arm.com>
>> + *
>> + * Derived from arch/arm/include/uapi/asm/kvm.h:
>> + * Copyright (C) 2012 - Virtual Open Systems and Columbia University
>> + * Author: Christoffer Dall <c.dall at virtualopensystems.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.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
>> + */
>> +
>> +#ifndef __ARM_KVM_H__
>> +#define __ARM_KVM_H__
>> +
>> +#define KVM_SPSR_EL1	0
>> +#define KVM_NR_SPSR	1
>> +
>> +#ifndef __ASSEMBLY__
>> +#include <asm/types.h>
>> +#include <asm/ptrace.h>
>> +
>> +#define __KVM_HAVE_GUEST_DEBUG
>> +#define __KVM_HAVE_IRQ_LINE
>> +
>> +#define KVM_REG_SIZE(id)						\
>> +	(1U << (((id) & KVM_REG_SIZE_MASK) >> KVM_REG_SIZE_SHIFT))
>> +
>> +struct kvm_regs {
>> +	struct user_pt_regs regs;	/* sp = sp_el0 */
>> +
>> +	__u64	sp_el1;
>> +	__u64	elr_el1;
>> +
>> +	__u64	spsr[KVM_NR_SPSR];
>> +
>> +	struct user_fpsimd_state fp_regs;
>> +};
>> +
>> +/* Supported Processor Types */
>> +#define KVM_ARM_TARGET_AEM_V8		0
>> +#define KVM_ARM_TARGET_FOUNDATION_V8	1
>> +#define KVM_ARM_TARGET_CORTEX_A57	2
>> +
>> +#define KVM_ARM_NUM_TARGETS		3
>> +
>> +/* KVM_ARM_SET_DEVICE_ADDR ioctl id encoding */
>> +#define KVM_ARM_DEVICE_TYPE_SHIFT	0
>> +#define KVM_ARM_DEVICE_TYPE_MASK	(0xffff << KVM_ARM_DEVICE_TYPE_SHIFT)
>> +#define KVM_ARM_DEVICE_ID_SHIFT		16
>> +#define KVM_ARM_DEVICE_ID_MASK		(0xffff << KVM_ARM_DEVICE_ID_SHIFT)
>> +
>> +/* Supported device IDs */
>> +#define KVM_ARM_DEVICE_VGIC_V2		0
>> +
>> +/* Supported VGIC address types  */
>> +#define KVM_VGIC_V2_ADDR_TYPE_DIST	0
>> +#define KVM_VGIC_V2_ADDR_TYPE_CPU	1
>> +
>> +#define KVM_VGIC_V2_DIST_SIZE		0x1000
>> +#define KVM_VGIC_V2_CPU_SIZE		0x2000
> 
> How does this work with 64k pages?
> 
>> +struct kvm_vcpu_init {
>> +	__u32 target;
>> +	__u32 features[7];
>> +};
>> +
>> +struct kvm_sregs {
>> +};
>> +
>> +struct kvm_fpu {
>> +};
>> +
>> +struct kvm_guest_debug_arch {
>> +};
>> +
>> +struct kvm_debug_exit_arch {
>> +};
>> +
>> +struct kvm_sync_regs {
>> +};
>> +
>> +struct kvm_arch_memory_slot {
>> +};
>> +
>> +/* KVM_IRQ_LINE irq field index values */
>> +#define KVM_ARM_IRQ_TYPE_SHIFT		24
>> +#define KVM_ARM_IRQ_TYPE_MASK		0xff
>> +#define KVM_ARM_IRQ_VCPU_SHIFT		16
>> +#define KVM_ARM_IRQ_VCPU_MASK		0xff
>> +#define KVM_ARM_IRQ_NUM_SHIFT		0
>> +#define KVM_ARM_IRQ_NUM_MASK		0xffff
>> +
>> +/* irq_type field */
>> +#define KVM_ARM_IRQ_TYPE_CPU		0
>> +#define KVM_ARM_IRQ_TYPE_SPI		1
>> +#define KVM_ARM_IRQ_TYPE_PPI		2
>> +
>> +/* out-of-kernel GIC cpu interrupt injection irq_number field */
>> +#define KVM_ARM_IRQ_CPU_IRQ		0
>> +#define KVM_ARM_IRQ_CPU_FIQ		1
> 
> Do we need this support for AArch64?

Probably not mandatory, but removing it would lead to even more surgery
on the 32bit side.

Plus, you may want to inject a FIQ in a guest ;-)

	M.
-- 
Jazz is not dead. It just smells funny...



From swarren at wwwdotorg.org  Fri Apr 12 11:34:13 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Fri, 12 Apr 2013 09:34:13 -0600
Subject: [PATCH 1/3] ARM: tegra: pcie: Add tegra3 support
In-Reply-To: <C79B248886DD134989C8FF6B096A91AB91B36FB2FD@BGMAIL01.nvidia.com>
References: <1365435688-4179-1-git-send-email-jagarwal@nvidia.com>
 <51630852.1000107@wwwdotorg.org>
 <C79B248886DD134989C8FF6B096A91AB91B36FB2FD@BGMAIL01.nvidia.com>
Message-ID: <51682975.1080302@wwwdotorg.org>

On 04/12/2013 08:58 AM, Jay Agarwal wrote:
>>>  	err = regulator_disable(pcie->pex_clk_supply);
>>>  	if (err < 0)
>>> -		dev_err(pcie->dev, "failed to disable pex-clk regulator:
>> %d\n",
>>> +		dev_warn(pcie->dev, "failed to disable pex-clk regulator:
>> %d\n",
>>>  			err);
>>>
>>>  	err = regulator_disable(pcie->vdd_supply);
>>>  	if (err < 0)
>>> -		dev_err(pcie->dev, "failed to disable VDD regulator: %d\n",
>>> +		dev_warn(pcie->dev, "failed to disable VDD regulator:
>> %d\n",
>>>  			err);
>>
>> Please explain why that change is correct. If the regulators only exist on
>> Tegra20, please represent that fact in the SoC data. Regulators must always
>> exist, so enable/disable should never fail due to missing regulators. Actual
>> run-time failures seem like something that really is an error.
>>
> [>] These regulators are needed for both tegra20 & tegra30. Since we are not returning error here, so changed to dev_warn.

If the regulators are required, then any failure to operate them should
be an error, hence dev_err() seems correct.

As to why the code doesn't actually return an error? I'm not sure.
Perhaps that should be fixed with a separate patch, although I don't
recall exactly where in the code the above excerpt is; if it's in
remove(), then continuing on without returning an error would be
appropriate.


From swarren at wwwdotorg.org  Fri Apr 12 11:40:17 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Fri, 12 Apr 2013 09:40:17 -0600
Subject: [PATCH 2/2] ARM: remove all trivial init_machine callbacks
In-Reply-To: <1365779468-116419-2-git-send-email-arnd@arndb.de>
References: <1365779468-116419-1-git-send-email-arnd@arndb.de>
 <1365779468-116419-2-git-send-email-arnd@arndb.de>
Message-ID: <51682AE1.9090106@wwwdotorg.org>

On 04/12/2013 09:11 AM, Arnd Bergmann wrote:
> The call to of_platform_populate(NULL, of_default_bus_match_table, NULL,
> NULL) is now implied by having no init_machine callback in the machine
> descriptor, so we can save a couple of lines in those machines that
> do not need to do anything else.

>  arch/arm/mach-tegra/board-dt-tegra114.c |  6 ------
>  arch/arm/mach-tegra/board-dt-tegra30.c  |  6 ------

Those two files don't exist any more; they were merged with
board-dt-tegra20.c and all squashed into the new tegra.c.


From marc.zyngier at arm.com  Fri Apr 12 11:48:29 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Fri, 12 Apr 2013 16:48:29 +0100
Subject: [PATCH v3 10/32] arm64: KVM: system register handling
In-Reply-To: <20130410170435.GK26992@mudshark.cambridge.arm.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
 <1365437854-30214-11-git-send-email-marc.zyngier@arm.com>
 <20130410170435.GK26992@mudshark.cambridge.arm.com>
Message-ID: <51682CCD.6060704@arm.com>

On 10/04/13 18:04, Will Deacon wrote:
> On Mon, Apr 08, 2013 at 05:17:12PM +0100, Marc Zyngier wrote:
>> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
>> new file mode 100644
>> index 0000000..9df3b32
>> --- /dev/null
>> +++ b/arch/arm64/kvm/sys_regs.c
>> @@ -0,0 +1,871 @@
>> +/*
>> + * Copyright (C) 2012,2013 - ARM Ltd
>> + * Author: Marc Zyngier <marc.zyngier at arm.com>
>> + *
>> + * Derived from arch/arm/kvm/coproc.c:
>> + * Copyright (C) 2012 - Virtual Open Systems and Columbia University
>> + * Authors: Rusty Russell <rusty at rustcorp.com.au>
>> + *          Christoffer Dall <c.dall at virtualopensystems.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.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
>> + */
>> +
>> +#include <linux/mm.h>
>> +#include <linux/kvm_host.h>
>> +#include <linux/uaccess.h>
>> +#include <asm/kvm_arm.h>
>> +#include <asm/kvm_host.h>
>> +#include <asm/kvm_emulate.h>
>> +#include <asm/kvm_coproc.h>
>> +#include <asm/cacheflush.h>
>> +#include <asm/cputype.h>
>> +#include <trace/events/kvm.h>
>> +
>> +#include "sys_regs.h"
>> +
>> +/*
>> + * All of this file is extremly similar to the ARM coproc.c, but the
>> + * types are different. My gut feeling is that it should be pretty
>> + * easy to merge, but that would be an ABI breakage -- again. VFP
>> + * would also need to be abstracted.
>> + */
> 
> Yes, there's a lot of duplication here.

Tell me about it...

>> +/* 3 bits per cache level, as per CLIDR, but non-existent caches always 0 */
>> +static u32 cache_levels;
>> +
>> +/* CSSELR values; used to index KVM_REG_ARM_DEMUX_ID_CCSIDR */
>> +#define CSSELR_MAX 12
>> +
>> +/* Which cache CCSIDR represents depends on CSSELR value. */
>> +static u32 get_ccsidr(u32 csselr)
>> +{
>> +       u32 ccsidr;
>> +
>> +       /* Make sure noone else changes CSSELR during this! */
>> +       local_irq_disable();
>> +       /* Put value into CSSELR */
>> +       asm volatile("msr csselr_el1, %x0" : : "r" (csselr));
>> +       /* Read result out of CCSIDR */
>> +       asm volatile("mrs %0, ccsidr_el1" : "=r" (ccsidr));
>> +       local_irq_enable();
> 
> Case in point: you're missing an isb here, which I remember pointing out
> when Christoffer made the same mistake...

Yup. Will fix.

>> +       return ccsidr;
>> +}
>> +
>> +static void do_dc_cisw(u32 val)
>> +{
>> +       asm volatile("dc cisw, %x0" : : "r" (val));
>> +}
>> +
>> +static void do_dc_csw(u32 val)
>> +{
>> +       asm volatile("dc csw, %x0" : : "r" (val));
>> +}
> 
> You don't have any barriers here. Whilst you could expect the guest to take
> care of barriers, I don't think that works if you are preempted and handle
> this on a different core.

If we've been preempted, we don't execute this code at all, but do a
cache_flush_all instead. But I agree the code is pretty fragile as it
stands, and relies on barriers in the guest (or somewhere else in the
preempting code).

I'll add them, if only for peace of mind...

>> +/* See note at ARM ARM B1.14.4 */
>> +static bool access_dcsw(struct kvm_vcpu *vcpu,
>> +                       const struct sys_reg_params *p,
>> +                       const struct sys_reg_desc *r)
>> +{
>> +       unsigned long val;
>> +       int cpu;
>> +
>> +       cpu = get_cpu();
>> +
>> +       if (!p->is_write)
>> +               return read_from_write_only(vcpu, p);
> 
> Missing put_cpu().

Yeah! Another 32bit bug to be fixed! ;-)

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...



From Ian.Campbell at citrix.com  Fri Apr 12 11:50:34 2013
From: Ian.Campbell at citrix.com (Ian Campbell)
Date: Fri, 12 Apr 2013 16:50:34 +0100
Subject: [PATCH] arm64: remove PSR bit macros from uapi
In-Reply-To: <20130412151835.GK12363@mudshark.cambridge.arm.com>
References: <1365779399-16654-1-git-send-email-ian.campbell@citrix.com>
 <20130412151835.GK12363@mudshark.cambridge.arm.com>
Message-ID: <1365781834.15783.107.camel@zakaz.uk.xensource.com>

On Fri, 2013-04-12 at 16:18 +0100, Will Deacon wrote:
> Hi Ian,
> 
> On Fri, Apr 12, 2013 at 04:09:59PM +0100, Ian Campbell wrote:
> > Exposing these in ptrace.h ends up polluting the namespace for user
> > applications which include headers such as <signal.h>, e.g. when building Xen
> > userspace tools on arm64:
> > 
> > tools/include/xen/arch-arm.h:229:0: error: "PSR_MODE_EL0t" redefined [-Werror]
> > In file included from /usr/lib/gcc-cross/aarch64-linux-gnu/4.7/../../../../aarch64-linux-gnu/include/sys/user.h:25:0,
> >                  from /usr/lib/gcc-cross/aarch64-linux-gnu/4.7/../../../../aarch64-linux-gnu/include/sys/procfs.h:34,
> >                  from /usr/lib/gcc-cross/aarch64-linux-gnu/4.7/../../../../aarch64-linux-gnu/include/sys/ucontext.h:26,
> >                  from /usr/lib/gcc-cross/aarch64-linux-gnu/4.7/../../../../aarch64-linux-gnu/include/signal.h:360,
> >                  from xentrace.c:21:
> > /usr/lib/gcc-cross/aarch64-linux-gnu/4.7/../../../../aarch64-linux-gnu/include/asm/ptrace.h:30:0: note: this is the location of the previous definition
> 
> Strange... I don't see the PSR definitions in any headers other than
> ptrace.h for my aarch64 toolchain.

It's the definition in ptrace.h which is the problem, since it conflicts
with the application's own definitions (Xen userspace in this case). The
names are in the "applications" namespace (i.e. not prefixed with _) and
it hasn't included any headers which are defined to cause those names to
be used.

I'm not sure which (if any) spec includes ptrace.h but signal.h isn't
defined to #define PSR_FOO. Maybe the real bug is the signal.h ends up
including ptrace.h at all?

>  Which tools are you using?

Ubuntu Raring multiarch cross thing, which is gcc 4.7.2-22ubuntu3 and
glibc 2.17-0ubuntu4.

Ian.



From arnd at arndb.de  Fri Apr 12 12:03:17 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 12 Apr 2013 18:03:17 +0200
Subject: [PATCH 2/2] ARM: remove all trivial init_machine callbacks
In-Reply-To: <51682AE1.9090106@wwwdotorg.org>
References: <1365779468-116419-1-git-send-email-arnd@arndb.de>
 <1365779468-116419-2-git-send-email-arnd@arndb.de>
 <51682AE1.9090106@wwwdotorg.org>
Message-ID: <201304121803.17348.arnd@arndb.de>

On Friday 12 April 2013, Stephen Warren wrote:
> On 04/12/2013 09:11 AM, Arnd Bergmann wrote:
> > The call to of_platform_populate(NULL, of_default_bus_match_table, NULL,
> > NULL) is now implied by having no init_machine callback in the machine
> > descriptor, so we can save a couple of lines in those machines that
> > do not need to do anything else.
> 
> >  arch/arm/mach-tegra/board-dt-tegra114.c |  6 ------
> >  arch/arm/mach-tegra/board-dt-tegra30.c  |  6 ------
> 
> Those two files don't exist any more; they were merged with
> board-dt-tegra20.c and all squashed into the new tegra.c.

Right, I also noticed this when merging with the latest for-next
branch. The merged code refers to auxdata, so I'll drop the above
two without a replacement.

	Arnd


From marc.zyngier at arm.com  Fri Apr 12 12:04:14 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Fri, 12 Apr 2013 17:04:14 +0100
Subject: [PATCH v3 11/32] arm64: KVM: CPU specific system registers
 handling
In-Reply-To: <20130410170624.GL26992@mudshark.cambridge.arm.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
 <1365437854-30214-12-git-send-email-marc.zyngier@arm.com>
 <20130410170624.GL26992@mudshark.cambridge.arm.com>
Message-ID: <5168307E.2080700@arm.com>

On 10/04/13 18:06, Will Deacon wrote:
> On Mon, Apr 08, 2013 at 05:17:13PM +0100, Marc Zyngier wrote:
>> Add the support code for CPU specific system registers. Not much
>> here yet.
>>
>> Reviewed-by: Christopher Covington <cov at codeaurora.org>
>> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
>> ---
>>  arch/arm64/kvm/sys_regs_generic_v8.c | 85 ++++++++++++++++++++++++++++++++++++
>>  1 file changed, 85 insertions(+)
>>  create mode 100644 arch/arm64/kvm/sys_regs_generic_v8.c
>>
>> diff --git a/arch/arm64/kvm/sys_regs_generic_v8.c b/arch/arm64/kvm/sys_regs_generic_v8.c
>> new file mode 100644
>> index 0000000..d4e8039
>> --- /dev/null
>> +++ b/arch/arm64/kvm/sys_regs_generic_v8.c
>> @@ -0,0 +1,85 @@
>> +/*
>> + * Copyright (C) 2012,2013 - ARM Ltd
>> + * Author: Marc Zyngier <marc.zyngier at arm.com>
>> + *
>> + * Based on arch/arm/kvm/coproc_a15.c:
>> + * Copyright (C) 2012 - Virtual Open Systems and Columbia University
>> + * Authors: Rusty Russell <rusty at rustcorp.au>
>> + *          Christoffer Dall <c.dall at virtualopensystems.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.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
>> + */
>> +#include <linux/kvm_host.h>
>> +#include <asm/cputype.h>
>> +#include <asm/kvm_arm.h>
>> +#include <asm/kvm_asm.h>
>> +#include <asm/kvm_host.h>
>> +#include <asm/kvm_emulate.h>
>> +#include <asm/kvm_coproc.h>
>> +#include <linux/init.h>
>> +
>> +#include "sys_regs.h"
>> +
>> +static bool access_actlr(struct kvm_vcpu *vcpu,
>> +			 const struct sys_reg_params *p,
>> +			 const struct sys_reg_desc *r)
>> +{
>> +	if (p->is_write)
>> +		return ignore_write(vcpu, p);
>> +
>> +	*vcpu_reg(vcpu, p->Rt) = vcpu_sys_reg(vcpu, ACTLR_EL1);
>> +	return true;
>> +}
>> +
>> +static void reset_actlr(struct kvm_vcpu *vcpu, const struct sys_reg_desc *r)
>> +{
>> +	u64 actlr;
>> +
>> +	asm volatile("mrs %0, actlr_el1\n" : "=r" (actlr));
>> +	vcpu_sys_reg(vcpu, ACTLR_EL1) = actlr;
>> +}
> 
> Do we actually need this? If so, there are likely other registers (things
> like the ectlr) that should be considered too.

I'm focussing on the architected registers, and only those. ECTLR is
implementation dependent, and is not specified as an architected sysreg.

As this is one of the registers that we trap (TACR set in HCR_EL2), we
have to emulate it. Now, maybe it is not that useful to trap it (nobody
uses that code path yet).

	M.
-- 
Jazz is not dead. It just smells funny...



From marc.zyngier at arm.com  Fri Apr 12 12:04:28 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Fri, 12 Apr 2013 17:04:28 +0100
Subject: [PATCH v3 12/32] arm64: KVM: virtual CPU reset
In-Reply-To: <20130410170707.GM26992@mudshark.cambridge.arm.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
 <1365437854-30214-13-git-send-email-marc.zyngier@arm.com>
 <20130410170707.GM26992@mudshark.cambridge.arm.com>
Message-ID: <5168308C.5040107@arm.com>

On 10/04/13 18:07, Will Deacon wrote:
> On Mon, Apr 08, 2013 at 05:17:14PM +0100, Marc Zyngier wrote:
>> Provide the reset code for a virtual CPU booted in 64bit mode.
>>
>> Reviewed-by: Christopher Covington <cov at codeaurora.org>
>> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
>> ---
>>  arch/arm64/kvm/reset.c | 76 ++++++++++++++++++++++++++++++++++++++++++++++++++
>>  1 file changed, 76 insertions(+)
>>  create mode 100644 arch/arm64/kvm/reset.c
>>
>> diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
>> new file mode 100644
>> index 0000000..bc33e76
>> --- /dev/null
>> +++ b/arch/arm64/kvm/reset.c
>> @@ -0,0 +1,76 @@
>> +/*
>> + * Copyright (C) 2012,2013 - ARM Ltd
>> + * Author: Marc Zyngier <marc.zyngier at arm.com>
>> + *
>> + * Derived from arch/arm/kvm/reset.c
>> + * Copyright (C) 2012 - Virtual Open Systems and Columbia University
>> + * Author: Christoffer Dall <c.dall at virtualopensystems.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.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
>> + */
>> +
>> +#include <linux/errno.h>
>> +#include <linux/kvm_host.h>
>> +#include <linux/kvm.h>
>> +
>> +#include <asm/cputype.h>
>> +#include <asm/ptrace.h>
>> +#include <asm/kvm_arm.h>
>> +#include <asm/kvm_coproc.h>
>> +
>> +/*
>> + * ARMv8 Reset Values
>> + */
>> +static struct kvm_regs default_regs_reset = {
>> +	.regs.pstate = PSR_MODE_EL1h | PSR_A_BIT | PSR_I_BIT | PSR_F_BIT,
> 
> PSR_D_BIT again.

OK.

	M.
-- 
Jazz is not dead. It just smells funny...



From Ian.Campbell at citrix.com  Fri Apr 12 12:06:29 2013
From: Ian.Campbell at citrix.com (Ian Campbell)
Date: Fri, 12 Apr 2013 17:06:29 +0100
Subject: [Xen-devel] [PATCH] arm64: remove PSR bit macros from uapi
In-Reply-To: <1365781834.15783.107.camel@zakaz.uk.xensource.com>
References: <1365779399-16654-1-git-send-email-ian.campbell@citrix.com>
 <20130412151835.GK12363@mudshark.cambridge.arm.com>
 <1365781834.15783.107.camel@zakaz.uk.xensource.com>
Message-ID: <1365782789.15783.113.camel@zakaz.uk.xensource.com>

On Fri, 2013-04-12 at 16:50 +0100, Ian Campbell wrote:
> I'm not sure which (if any) spec includes ptrace.h but signal.h isn't
> defined to #define PSR_FOO. Maybe the real bug is the signal.h ends up
> including ptrace.h at all?

Having spoken to someone who understands this stuff better than I
(although I still reserve the right to be talking out my a**e) it
appears this is the case. ptrace.h is allowed to define whatever it
likes because it's not defined by a standard but signal.h is specified
by POSIX and is not allowed to define anything which isn't in the POSIX
reserved namespace or which isn't explicitly mentions, which PSR_* is
not.

So it seems like the bug is on the libc side for including this
particular #include chain?

On the flip side is there any reason for the Linux uapi headers to be
including architectural constants? e.g. the x86 uapi/ptrace.h doesn't
define the RFLAGS bits etc...

Ian.



From plagnioj at jcrosoft.com  Fri Apr 12 12:08:40 2013
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Fri, 12 Apr 2013 18:08:40 +0200
Subject: [PATCH 2/2] ARM: remove all trivial init_machine callbacks
In-Reply-To: <1365779468-116419-2-git-send-email-arnd@arndb.de>
References: <1365779468-116419-1-git-send-email-arnd@arndb.de>
 <1365779468-116419-2-git-send-email-arnd@arndb.de>
Message-ID: <20130412160840.GD25242@game.jcrosoft.org>

On 17:11 Fri 12 Apr     , Arnd Bergmann wrote:
> The call to of_platform_populate(NULL, of_default_bus_match_table, NULL,
> NULL) is now implied by having no init_machine callback in the machine
> descriptor, so we can save a couple of lines in those machines that
> do not need to do anything else.
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Cc: Nicolas Pitre <nico at linaro.org>
> Cc: Olof Johansson <olof at lixom.net>
> Cc: "Russell King - ARM Linux" <linux at arm.linux.org.uk>
> Cc: Rob Herring <robherring2 at gmail.com>
> ---
>  arch/arm/mach-at91/board-dt.c           |  6 ------
>  arch/arm/mach-at91/board-rm9200-dt.c    |  6 ------
on AT91 you have also sama5 file and those file are renaned for 3.10

Best Regards,
J.
>  arch/arm/mach-exynos/mach-exynos4-dt.c  |  7 -------
>  arch/arm/mach-imx/imx25-dt.c            |  6 ------
>  arch/arm/mach-imx/imx31-dt.c            |  6 ------
>  arch/arm/mach-imx/imx51-dt.c            |  6 ------
>  arch/arm/mach-msm/board-dt-8660.c       | 11 -----------
>  arch/arm/mach-msm/board-dt-8960.c       |  6 ------
>  arch/arm/mach-tegra/board-dt-tegra114.c |  6 ------
>  arch/arm/mach-tegra/board-dt-tegra30.c  |  6 ------
>  arch/arm/mach-virt/virt.c               |  6 ------
>  11 files changed, 72 deletions(-)
> 
> diff --git a/arch/arm/mach-at91/board-dt.c b/arch/arm/mach-at91/board-dt.c
> index 8db3013..9903579 100644
> --- a/arch/arm/mach-at91/board-dt.c
> +++ b/arch/arm/mach-at91/board-dt.c
> @@ -37,11 +37,6 @@ static void __init at91_dt_init_irq(void)
>  	of_irq_init(irq_of_match);
>  }
>  
> -static void __init at91_dt_device_init(void)
> -{
> -	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
> -}
> -
>  static const char *at91_dt_board_compat[] __initdata = {
>  	"atmel,at91sam9",
>  	NULL
> @@ -54,6 +49,5 @@ DT_MACHINE_START(at91sam_dt, "Atmel AT91SAM (Device Tree)")
>  	.handle_irq	= at91_aic_handle_irq,
>  	.init_early	= at91_dt_initialize,
>  	.init_irq	= at91_dt_init_irq,
> -	.init_machine	= at91_dt_device_init,
>  	.dt_compat	= at91_dt_board_compat,
>  MACHINE_END
> diff --git a/arch/arm/mach-at91/board-rm9200-dt.c b/arch/arm/mach-at91/board-rm9200-dt.c
> index 3fcb662..6b8d260 100644
> --- a/arch/arm/mach-at91/board-rm9200-dt.c
> +++ b/arch/arm/mach-at91/board-rm9200-dt.c
> @@ -36,11 +36,6 @@ static void __init at91rm9200_dt_init_irq(void)
>  	of_irq_init(irq_of_match);
>  }
>  
> -static void __init at91rm9200_dt_device_init(void)
> -{
> -	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
> -}
> -
>  static const char *at91rm9200_dt_board_compat[] __initdata = {
>  	"atmel,at91rm9200",
>  	NULL
> @@ -52,6 +47,5 @@ DT_MACHINE_START(at91rm9200_dt, "Atmel AT91RM9200 (Device Tree)")
>  	.handle_irq	= at91_aic_handle_irq,
>  	.init_early	= at91rm9200_dt_initialize,
>  	.init_irq	= at91rm9200_dt_init_irq,
> -	.init_machine	= at91rm9200_dt_device_init,
>  	.dt_compat	= at91rm9200_dt_board_compat,
>  MACHINE_END
> diff --git a/arch/arm/mach-exynos/mach-exynos4-dt.c b/arch/arm/mach-exynos/mach-exynos4-dt.c
> index 3358088..25038a1 100644
> --- a/arch/arm/mach-exynos/mach-exynos4-dt.c
> +++ b/arch/arm/mach-exynos/mach-exynos4-dt.c
> @@ -122,12 +122,6 @@ static void __init exynos4_dt_map_io(void)
>  	s3c24xx_init_clocks(24000000);
>  }
>  
> -static void __init exynos4_dt_machine_init(void)
> -{
> -	of_platform_populate(NULL, of_default_bus_match_table,
> -				exynos4_auxdata_lookup, NULL);
> -}
> -
>  static char const *exynos4_dt_compat[] __initdata = {
>  	"samsung,exynos4210",
>  	"samsung,exynos4212",
> @@ -140,7 +134,6 @@ DT_MACHINE_START(EXYNOS4210_DT, "Samsung Exynos4 (Flattened Device Tree)")
>  	.smp		= smp_ops(exynos_smp_ops),
>  	.init_irq	= exynos4_init_irq,
>  	.map_io		= exynos4_dt_map_io,
> -	.init_machine	= exynos4_dt_machine_init,
>  	.init_late	= exynos_init_late,
>  	.init_time	= exynos4_timer_init,
>  	.dt_compat	= exynos4_dt_compat,
> diff --git a/arch/arm/mach-imx/imx25-dt.c b/arch/arm/mach-imx/imx25-dt.c
> index 8234839..2ecaa6a 100644
> --- a/arch/arm/mach-imx/imx25-dt.c
> +++ b/arch/arm/mach-imx/imx25-dt.c
> @@ -17,11 +17,6 @@
>  #include "common.h"
>  #include "mx25.h"
>  
> -static void __init imx25_dt_init(void)
> -{
> -	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
> -}
> -
>  static const char * const imx25_dt_board_compat[] __initconst = {
>  	"fsl,imx25",
>  	NULL
> @@ -38,7 +33,6 @@ DT_MACHINE_START(IMX25_DT, "Freescale i.MX25 (Device Tree Support)")
>  	.init_irq	= mx25_init_irq,
>  	.handle_irq	= imx25_handle_irq,
>  	.init_time	= imx25_timer_init,
> -	.init_machine	= imx25_dt_init,
>  	.dt_compat	= imx25_dt_board_compat,
>  	.restart	= mxc_restart,
>  MACHINE_END
> diff --git a/arch/arm/mach-imx/imx31-dt.c b/arch/arm/mach-imx/imx31-dt.c
> index 67de611..5bb05d5 100644
> --- a/arch/arm/mach-imx/imx31-dt.c
> +++ b/arch/arm/mach-imx/imx31-dt.c
> @@ -18,11 +18,6 @@
>  #include "common.h"
>  #include "mx31.h"
>  
> -static void __init imx31_dt_init(void)
> -{
> -	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
> -}
> -
>  static const char *imx31_dt_board_compat[] __initdata = {
>  	"fsl,imx31",
>  	NULL
> @@ -39,7 +34,6 @@ DT_MACHINE_START(IMX31_DT, "Freescale i.MX31 (Device Tree Support)")
>  	.init_irq	= mx31_init_irq,
>  	.handle_irq	= imx31_handle_irq,
>  	.init_time	= imx31_dt_timer_init,
> -	.init_machine	= imx31_dt_init,
>  	.dt_compat	= imx31_dt_board_compat,
>  	.restart	= mxc_restart,
>  MACHINE_END
> diff --git a/arch/arm/mach-imx/imx51-dt.c b/arch/arm/mach-imx/imx51-dt.c
> index e2926a8..52985a5 100644
> --- a/arch/arm/mach-imx/imx51-dt.c
> +++ b/arch/arm/mach-imx/imx51-dt.c
> @@ -19,11 +19,6 @@
>  #include "common.h"
>  #include "mx51.h"
>  
> -static void __init imx51_dt_init(void)
> -{
> -	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
> -}
> -
>  static const char *imx51_dt_board_compat[] __initdata = {
>  	"fsl,imx51",
>  	NULL
> @@ -40,7 +35,6 @@ DT_MACHINE_START(IMX51_DT, "Freescale i.MX51 (Device Tree Support)")
>  	.init_irq	= mx51_init_irq,
>  	.handle_irq	= imx51_handle_irq,
>  	.init_time	= imx51_timer_init,
> -	.init_machine	= imx51_dt_init,
>  	.init_late	= imx51_init_late,
>  	.dt_compat	= imx51_dt_board_compat,
>  	.restart	= mxc_restart,
> diff --git a/arch/arm/mach-msm/board-dt-8660.c b/arch/arm/mach-msm/board-dt-8660.c
> index 7dcfc53..0c21245 100644
> --- a/arch/arm/mach-msm/board-dt-8660.c
> +++ b/arch/arm/mach-msm/board-dt-8660.c
> @@ -25,16 +25,6 @@ static void __init msm8x60_init_late(void)
>  	smd_debugfs_init();
>  }
>  
> -static struct of_dev_auxdata msm_auxdata_lookup[] __initdata = {
> -	{}
> -};
> -
> -static void __init msm8x60_dt_init(void)
> -{
> -	of_platform_populate(NULL, of_default_bus_match_table,
> -			msm_auxdata_lookup, NULL);
> -}
> -
>  static const char *msm8x60_fluid_match[] __initdata = {
>  	"qcom,msm8660-fluid",
>  	"qcom,msm8660-surf",
> @@ -45,7 +35,6 @@ DT_MACHINE_START(MSM_DT, "Qualcomm MSM (Flattened Device Tree)")
>  	.smp = smp_ops(msm_smp_ops),
>  	.map_io = msm_map_msm8x60_io,
>  	.init_irq = irqchip_init,
> -	.init_machine = msm8x60_dt_init,
>  	.init_late = msm8x60_init_late,
>  	.init_time	= msm_dt_timer_init,
>  	.dt_compat = msm8x60_fluid_match,
> diff --git a/arch/arm/mach-msm/board-dt-8960.c b/arch/arm/mach-msm/board-dt-8960.c
> index 7301936..26461d2 100644
> --- a/arch/arm/mach-msm/board-dt-8960.c
> +++ b/arch/arm/mach-msm/board-dt-8960.c
> @@ -18,11 +18,6 @@
>  
>  #include "common.h"
>  
> -static void __init msm_dt_init(void)
> -{
> -	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
> -}
> -
>  static const char * const msm8960_dt_match[] __initconst = {
>  	"qcom,msm8960-cdp",
>  	NULL
> @@ -33,6 +28,5 @@ DT_MACHINE_START(MSM8960_DT, "Qualcomm MSM (Flattened Device Tree)")
>  	.map_io = msm_map_msm8960_io,
>  	.init_irq = irqchip_init,
>  	.init_time	= msm_dt_timer_init,
> -	.init_machine = msm_dt_init,
>  	.dt_compat = msm8960_dt_match,
>  MACHINE_END
> diff --git a/arch/arm/mach-tegra/board-dt-tegra114.c b/arch/arm/mach-tegra/board-dt-tegra114.c
> index 085d636..ec7b8bf 100644
> --- a/arch/arm/mach-tegra/board-dt-tegra114.c
> +++ b/arch/arm/mach-tegra/board-dt-tegra114.c
> @@ -23,11 +23,6 @@
>  #include "board.h"
>  #include "common.h"
>  
> -static void __init tegra114_dt_init(void)
> -{
> -	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
> -}
> -
>  static const char * const tegra114_dt_board_compat[] = {
>  	"nvidia,tegra114",
>  	NULL,
> @@ -39,7 +34,6 @@ DT_MACHINE_START(TEGRA114_DT, "NVIDIA Tegra114 (Flattened Device Tree)")
>  	.init_early	= tegra114_init_early,
>  	.init_irq	= tegra_dt_init_irq,
>  	.init_time	= clocksource_of_init,
> -	.init_machine	= tegra114_dt_init,
>  	.init_late	= tegra_init_late,
>  	.restart	= tegra_assert_system_reset,
>  	.dt_compat	= tegra114_dt_board_compat,
> diff --git a/arch/arm/mach-tegra/board-dt-tegra30.c b/arch/arm/mach-tegra/board-dt-tegra30.c
> index bf68567..316bd9f 100644
> --- a/arch/arm/mach-tegra/board-dt-tegra30.c
> +++ b/arch/arm/mach-tegra/board-dt-tegra30.c
> @@ -37,11 +37,6 @@
>  #include "common.h"
>  #include "iomap.h"
>  
> -static void __init tegra30_dt_init(void)
> -{
> -	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
> -}
> -
>  static const char *tegra30_dt_board_compat[] = {
>  	"nvidia,tegra30",
>  	NULL
> @@ -53,7 +48,6 @@ DT_MACHINE_START(TEGRA30_DT, "NVIDIA Tegra30 (Flattened Device Tree)")
>  	.init_early	= tegra30_init_early,
>  	.init_irq	= tegra_dt_init_irq,
>  	.init_time	= clocksource_of_init,
> -	.init_machine	= tegra30_dt_init,
>  	.init_late	= tegra_init_late,
>  	.restart	= tegra_assert_system_reset,
>  	.dt_compat	= tegra30_dt_board_compat,
> diff --git a/arch/arm/mach-virt/virt.c b/arch/arm/mach-virt/virt.c
> index 31666f6..7bce0f8 100644
> --- a/arch/arm/mach-virt/virt.c
> +++ b/arch/arm/mach-virt/virt.c
> @@ -27,11 +27,6 @@
>  #include <asm/mach/arch.h>
>  #include <asm/mach/time.h>
>  
> -static void __init virt_init(void)
> -{
> -	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
> -}
> -
>  static void __init virt_timer_init(void)
>  {
>  	WARN_ON(arch_timer_of_register() != 0);
> @@ -48,7 +43,6 @@ extern struct smp_operations virt_smp_ops;
>  DT_MACHINE_START(VIRT, "Dummy Virtual Machine")
>  	.init_irq	= irqchip_init,
>  	.init_time	= virt_timer_init,
> -	.init_machine	= virt_init,
>  	.smp		= smp_ops(virt_smp_ops),
>  	.dt_compat	= virt_dt_match,
>  MACHINE_END
> -- 
> 1.8.1.2
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From lee.jones at linaro.org  Fri Apr 12 12:13:25 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Fri, 12 Apr 2013 17:13:25 +0100
Subject: [PATCH 3/8] dmaengine: ste_dma40: Actually write the runtime
 configuration to registers
In-Reply-To: <CAH+eYFB_fYmCjvh5PXKRhd-FnaWfeu+LtH+q3VywhCk-PYhHVQ@mail.gmail.com>
References: <1365532783-27425-1-git-send-email-lee.jones@linaro.org>
 <1365532783-27425-3-git-send-email-lee.jones@linaro.org>
 <CAH+eYFB_fYmCjvh5PXKRhd-FnaWfeu+LtH+q3VywhCk-PYhHVQ@mail.gmail.com>
Message-ID: <20130412161325.GB18459@gmail.com>

On Fri, 12 Apr 2013, Rabin Vincent wrote:

> 2013/4/9 Lee Jones <lee.jones at linaro.org>:
> > Someone has spent a fair amount of effort writing a runtime configuration
> > changing algorithm for DMA clients. However, the config appears to never
> > actually make it to hardware. In order for the configuration to take hold
> > we need to issue a d40_config_write(), as this is the routine which writes
> > it into the hardware's registers.
> 
> No, it's not.  This function is only for initial configuration which
> should only be written when the channel is allocated.  In fact, by
> calling it here in runtime_config, you are introducing a serious bug:
> other logical channels on the same physical channel will stop because of
> the SSLNK/SDLNK of the physical channel being zeroed.
> 
> The runtime config already makes it the hardware in the existing code,
> via d40_*_cfg().

Ah, I see. I'll move it all back and investigate my bug further then.

Thanks for taking the time to write such a well written review.

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From marc.zyngier at arm.com  Fri Apr 12 12:17:01 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Fri, 12 Apr 2013 18:17:01 +0200
Subject: [Xen-devel] [PATCH] arm64: remove PSR bit macros from uapi
In-Reply-To: <1365782789.15783.113.camel@zakaz.uk.xensource.com>
References: <1365779399-16654-1-git-send-email-ian.campbell@citrix.com>
 <20130412151835.GK12363@mudshark.cambridge.arm.com>
 <1365781834.15783.107.camel@zakaz.uk.xensource.com>
 <1365782789.15783.113.camel@zakaz.uk.xensource.com>
Message-ID: <60a204007309b815b1ac115c817dc808@localhost>

On Fri, 12 Apr 2013 17:06:29 +0100, Ian Campbell <Ian.Campbell at citrix.com>
wrote:

[...]

> On the flip side is there any reason for the Linux uapi headers to be
> including architectural constants? e.g. the x86 uapi/ptrace.h doesn't
> define the RFLAGS bits etc...

My favourite userspace program (aka the other platform emulation that
shall not ever be merged) needs it. QEMU probably will as well.

Of course, we could define them locally, but that seems like a massive
waste of perfectly innocent bytes. or convince the power that be to merge
the damned thing so we can include kernel headers with any remorse... ;-)

        M.
-- 
Fast, cheap, reliable. Pick two.


From jonathan.austin at arm.com  Fri Apr 12 12:25:25 2013
From: jonathan.austin at arm.com (Jonathan Austin)
Date: Fri, 12 Apr 2013 17:25:25 +0100
Subject: [PATCH v10 1/3] ARM: Add base support for ARMv7-M
In-Reply-To: <1364381692-7955-2-git-send-email-u.kleine-koenig@pengutronix.de>
References: <1363901310-9474-1-git-send-email-u.kleine-koenig@pengutronix.de>
 <1364381692-7955-1-git-send-email-u.kleine-koenig@pengutronix.de>
 <1364381692-7955-2-git-send-email-u.kleine-koenig@pengutronix.de>
Message-ID: <51683575.2000103@arm.com>

Hi Uwe,

I've just noticed an issue with this patch that we haven't seen because 
we're not using MULTI_CPU, but I *think* if we were to do that things 
wouldn't work out.

On 27/03/13 10:54, Uwe Kleine-K?nig wrote:
> From: Catalin Marinas <catalin.marinas at arm.com>
>

Aggressive snip...

> index 0000000..b18e3ba
> --- /dev/null
> +++ b/arch/arm/mm/proc-v7m.S
> @@ -0,0 +1,165 @@
> +/*
> + *  linux/arch/arm/mm/proc-v7m.S
> + *
> + *  Copyright (C) 2008 ARM Ltd.
> + *  Copyright (C) 2001 Deep Blue Solutions Ltd.
> + *
> + * 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.
> + *
> + *  This is the "shell" of the ARMv7-M processor support.
> + */
> +#include <linux/linkage.h>
> +#include <asm/assembler.h>
> +#include <asm/v7m.h>
> +
> +ENTRY(cpu_v7m_proc_init)
> +       mov     pc, lr
> +ENDPROC(cpu_v7m_proc_init)
> +
> +ENTRY(cpu_v7m_proc_fin)
> +       mov     pc, lr
> +ENDPROC(cpu_v7m_proc_fin)
> +
> +/*
> + *     cpu_v7m_reset(loc)
> + *
> + *     Perform a soft reset of the system.  Put the CPU into the
> + *     same state as it would be if it had been reset, and branch
> + *     to what would be the reset vector.
> + *
> + *     - loc   - location to jump to for soft reset
> + */
> +       .align  5
> +ENTRY(cpu_v7m_reset)
> +       mov     pc, r0
> +ENDPROC(cpu_v7m_reset)
> +
> +/*
> + *     cpu_v7m_do_idle()
> + *
> + *     Idle the processor (eg, wait for interrupt).
> + *
> + *     IRQs are already disabled.
> + */
> +ENTRY(cpu_v7m_do_idle)
> +       wfi
> +       mov     pc, lr
> +ENDPROC(cpu_v7m_do_idle)
> +
> +ENTRY(cpu_v7m_dcache_clean_area)
> +       mov     pc, lr
> +ENDPROC(cpu_v7m_dcache_clean_area)
> +
> +/*
> + * There is no MMU, so here is nothing to do.
> + */
> +ENTRY(cpu_v7m_switch_mm)
> +       mov     pc, lr
> +ENDPROC(cpu_v7m_switch_mm)
> +
> +cpu_v7m_name:
> +       .ascii  "ARMv7-M Processor"
> +       .align
> +
> +       .section ".text.init", #alloc, #execinstr
> +
> +/*
> + *     __v7m_setup
> + *
> + *     This should be able to cover all ARMv7-M cores.
> + */
> +__v7m_setup:
> +       @ Configure the vector table base address
> +       ldr     r0, =BASEADDR_V7M_SCB
> +       ldr     r12, =vector_table
> +       str     r12, [r0, V7M_SCB_VTOR]
> +
> +       @ enable UsageFault, BusFault and MemManage fault.
> +       ldr     r5, [r0, #V7M_SCB_SHCSR]
> +       orr     r5, #(V7M_SCB_SHCSR_USGFAULTENA | V7M_SCB_SHCSR_BUSFAULTENA | V7M_SCB_SHCSR_MEMFAULTENA)
> +       str     r5, [r0, #V7M_SCB_SHCSR]
> +
> +       @ Lower the priority of the SVC and PendSV exceptions
> +       mov     r5, #0x80000000
> +       str     r5, [r0, V7M_SCB_SHPR2] @ set SVC priority
> +       mov     r5, #0x00800000
> +       str     r5, [r0, V7M_SCB_SHPR3] @ set PendSV priority
> +
> +       @ SVC to run the kernel in this mode
> +       adr     r1, BSYM(1f)
> +       ldr     r5, [r12, #11 * 4]      @ read the SVC vector entry
> +       str     r1, [r12, #11 * 4]      @ write the temporary SVC vector entry
> +       mov     r6, lr                  @ save LR
> +       mov     r7, sp                  @ save SP
> +       ldr     sp, =__v7m_setup_stack_top
> +       cpsie   i
> +       svc     #0
> +1:     cpsid   i
> +       str     r5, [r12, #11 * 4]      @ restore the original SVC vector entry
> +       mov     lr, r6                  @ restore LR
> +       mov     sp, r7                  @ restore SP
> +
> +       @ Special-purpose control register
> +       mov     r1, #1
> +       msr     control, r1             @ Thread mode has unpriviledged access
> +
> +       @ Configure the System Control Register to ensure 8-byte stack alignment
> +       @ Note the STKALIGN bit is either RW or RAO.
> +       ldr     r12, [r0, V7M_SCB_CCR]  @ system control register
> +       orr     r12, #V7M_SCB_CCR_STKALIGN
> +       str     r12, [r0, V7M_SCB_CCR]
> +       mov     pc, lr
> +ENDPROC(__v7m_setup)
> +
> +       .align  2
> +       .type   v7m_processor_functions, #object
> +ENTRY(v7m_processor_functions)
> +       .word   nommu_early_abort
 > +       .word   cpu_v7m_proc_init
 > +       .word   cpu_v7m_proc_fin

This seems *not* to align with the struct processor defined in

arch/arm/include/asm/proc-fns.h:

...
extern struct processor {
	/* MISC
	 * get data abort address/flags
	 */
	void (*_data_abort)(unsigned long pc);
	/*
	 * Retrieve prefetch fault address
	 */
	unsigned long (*_prefetch_abort)(unsigned long lr);
	/*
	 * Set up any processor specifics
	 */
	void (*_proc_init)(void);
	/*
	 * Disable any processor specifics
	 */
...

So what's the deal? I presume this is because when Catalin originally 
did the very first M3 stuff it happened before this commit:

48d7927bdf Add a prefetch abort handler

And as we weren't using MULTI_CPU nobody noticed the bug when things got 
updated?


Jonny




From marc.zyngier at arm.com  Fri Apr 12 12:35:23 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Fri, 12 Apr 2013 17:35:23 +0100
Subject: [PATCH v3 15/32] arm64: KVM: guest one-reg interface
In-Reply-To: <20130410171339.GN26992@mudshark.cambridge.arm.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
 <1365437854-30214-16-git-send-email-marc.zyngier@arm.com>
 <20130410171339.GN26992@mudshark.cambridge.arm.com>
Message-ID: <516837CB.2030700@arm.com>

On 10/04/13 18:13, Will Deacon wrote:
> On Mon, Apr 08, 2013 at 05:17:17PM +0100, Marc Zyngier wrote:
>> Let userspace play with the guest registers.
>>
>> Reviewed-by: Christopher Covington <cov at codeaurora.org>
>> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
>> ---
>>  arch/arm64/kvm/guest.c | 254 +++++++++++++++++++++++++++++++++++++++++++++++++
>>  1 file changed, 254 insertions(+)
>>  create mode 100644 arch/arm64/kvm/guest.c
>>
>> diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
>> new file mode 100644
>> index 0000000..47d3729
>> --- /dev/null
>> +++ b/arch/arm64/kvm/guest.c
>> @@ -0,0 +1,254 @@
>> +/*
>> + * Copyright (C) 2012,2013 - ARM Ltd
>> + * Author: Marc Zyngier <marc.zyngier at arm.com>
>> + *
>> + * Derived from arch/arm/kvm/guest.c:
>> + * Copyright (C) 2012 - Virtual Open Systems and Columbia University
>> + * Author: Christoffer Dall <c.dall at virtualopensystems.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.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
>> + */
>> +
>> +#include <linux/errno.h>
>> +#include <linux/err.h>
>> +#include <linux/kvm_host.h>
>> +#include <linux/module.h>
>> +#include <linux/vmalloc.h>
>> +#include <linux/fs.h>
>> +#include <asm/cputype.h>
>> +#include <asm/uaccess.h>
>> +#include <asm/kvm.h>
>> +#include <asm/kvm_asm.h>
>> +#include <asm/kvm_emulate.h>
>> +#include <asm/kvm_coproc.h>
>> +
>> +struct kvm_stats_debugfs_item debugfs_entries[] = {
>> +	{ NULL }
>> +};
>> +
>> +int kvm_arch_vcpu_setup(struct kvm_vcpu *vcpu)
>> +{
>> +	vcpu->arch.hcr_el2 = HCR_GUEST_FLAGS;
>> +	return 0;
>> +}
>> +
>> +static u64 core_reg_offset_from_id(u64 id)
>> +{
>> +	return id & ~(KVM_REG_ARCH_MASK | KVM_REG_SIZE_MASK | KVM_REG_ARM_CORE);
>> +}
>> +
>> +static int get_core_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
>> +{
>> +	__u32 __user *uaddr = (__u32 __user *)(unsigned long)reg->addr;
>> +	struct kvm_regs *regs = vcpu_gp_regs(vcpu);
>> +	int nr_regs = sizeof(*regs) / sizeof(__u32);
> 
> Why are you treating the registers as u32?

Not the registers themselves, but the index into the kvm_regs structure.
The reason is that this structure is a mix of 32, 64 and 128bit fields.
So we index it on the smallest quantity.

	M.
-- 
Jazz is not dead. It just smells funny...



From lee.jones at linaro.org  Fri Apr 12 12:38:10 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Fri, 12 Apr 2013 17:38:10 +0100
Subject: [PATCH 4/8] dmaengine: ste_dma40: Do not configure channels
 during an channel allocation
In-Reply-To: <CAH+eYFBk8y28e+NwOBpvpdFa29JRXbNpFgjwNumC8GRtB-e7VQ@mail.gmail.com>
References: <1365532783-27425-1-git-send-email-lee.jones@linaro.org>
 <1365532783-27425-4-git-send-email-lee.jones@linaro.org>
 <CAH+eYFBk8y28e+NwOBpvpdFa29JRXbNpFgjwNumC8GRtB-e7VQ@mail.gmail.com>
Message-ID: <20130412163810.GC18459@gmail.com>

On Fri, 12 Apr 2013, Rabin Vincent wrote:

> 2013/4/9 Lee Jones <lee.jones at linaro.org>:
> > diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
> > index 2a0a9d4..9e423ad 100644
> > --- a/drivers/dma/ste_dma40.c
> > +++ b/drivers/dma/ste_dma40.c
> > @@ -2463,16 +2463,10 @@ static int d40_alloc_chan_resources(struct dma_chan *chan)
> >         }
> >
> >         pm_runtime_get_sync(d40c->base->dev);
> > -       /* Fill in basic CFG register values */
> > -       d40_phy_cfg(&d40c->dma_cfg, &d40c->src_def_cfg,
> > -                   &d40c->dst_def_cfg, chan_is_logical(d40c));
> >
> >         d40_set_prio_realtime(d40c);
> >
> >         if (chan_is_logical(d40c)) {
> > -               d40_log_cfg(&d40c->dma_cfg,
> > -                           &d40c->log_def.lcsp1, &d40c->log_def.lcsp3);
> > -
> >                 if (d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_MEM)
> >                         d40c->lcpa = d40c->base->lcpa_base +
> >                                 d40c->dma_cfg.src_dev_type * D40_LCPA_CHAN_SIZE;
> > @@ -2487,14 +2481,6 @@ static int d40_alloc_chan_resources(struct dma_chan *chan)
> >                  d40c->phy_chan->num,
> >                  d40c->dma_cfg.use_fixed_channel ? ", fixed" : "");
> >
> > -
> > -       /*
> > -        * Only write channel configuration to the DMA if the physical
> > -        * resource is free. In case of multiple logical channels
> > -        * on the same physical resource, only the first write is necessary.
> > -        */
> > -       if (is_free_phy)
> > -               d40_config_write(d40c);
> 
> This function does basic initial configuration which is linked to
> whether the channel is pysical or logical -- something that is not being
> allowed to be runtime configured, so the place to call this function is
> here.  Furthermore, it clears the SSLNK/SDLNK which has to be done here,
> when the phy channel is first allocated.

Okay, I see what you're saying.

So I need to devise another way, as this function cannot be called
here either. Using the dmaengine API, allocating a channel and
configuring it are to be completed using different calls. Using the
API correctly, there is no way the driver can setup the channel
with all of the relevant information during allocation time.

The steps are as follows:

dma_request_channel() - here we only allot a channel number and
                        allocate the appropriate resources for the
			channel.

dma_slave_config()    - this is where we're meant to configure the
                        channel, so d40_config_write() needs to be
			called here, as only dma_slave_config() will
			carry the information required so as
			d40_*_cfg() can make the correct decisions.

At the moment calling dma_slave_config() ends up calling
d40_set_runtime_config(), which, taking into consideration what you've
been saying about possibly cutting off other logical channels, is
probably not what we want. I'll take a look at the dmaengine API and
see if there's a more appropriate way to do that.

Thanks again for your input Rabin, it's invaluable.

Kind regards,
Lee		

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From jagarwal at nvidia.com  Fri Apr 12 12:43:35 2013
From: jagarwal at nvidia.com (Jay Agarwal)
Date: Fri, 12 Apr 2013 22:13:35 +0530
Subject: [PATCH 1/3] ARM: tegra: pcie: Add tegra3 support
In-Reply-To: <51630ABB.1020200@wwwdotorg.org>
References: <1365435688-4179-1-git-send-email-jagarwal@nvidia.com>
 <51630ABB.1020200@wwwdotorg.org>
Message-ID: <C79B248886DD134989C8FF6B096A91AB91B36FB300@BGMAIL01.nvidia.com>

> On 04/08/2013 09:41 AM, Jay Agarwal wrote:
> > Signed-off-by: Jay Agarwal <jagarwal at nvidia.com>
> >
> > - Enable pcie root port 2 for cardhu
> > - Make private data structure for each SOC
> > - Add required tegra3 clocks and regulators
> > - Add tegra3 specific code in enable controller
> > - Modify clock tree to get clocks based on device
> > - Based on git://gitorious.org/thierryreding/linux.git
> 	
> A couple more points on this patch:
> 
> * You didn't mention that this series is based on Thierry's work-in-progress
> tree, and not something immediately destined for upstream. As such, only
> Thierry is expected to actually apply any of these patches.
> 
[>] Stephen, I have mentioned it in comment description as Based on git://gitorious.org/thierryreding/linux.git, is this not enough?

> * Your changes to the Tegra PCIe driver require that device tree include
> extra clocks and regulators. You need to update
> Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt to describe
> these new requirements.
[>] Should I create tegra30-pcie.txt? or made changes in tegra20-pcie.txt itself?


From lorenzo.pieralisi at arm.com  Fri Apr 12 12:59:44 2013
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Fri, 12 Apr 2013 17:59:44 +0100
Subject: [RFC PATCH 01/11] Documentation: DT: arm: define CPU topology
 bindings
In-Reply-To: <20130412143644.GB2992@linaro.org>
References: <1365671562-2403-1-git-send-email-mark.rutland@arm.com>
 <1365671562-2403-2-git-send-email-mark.rutland@arm.com>
 <5166D01F.5070404@gmail.com>
 <20130411155054.GA29509@e102568-lin.cambridge.arm.com>
 <20130411180125.GB2239@linaro.org>
 <20130412114457.GC6637@e102568-lin.cambridge.arm.com>
 <20130412143644.GB2992@linaro.org>
Message-ID: <20130412165944.GA8778@e102568-lin.cambridge.arm.com>

On Fri, Apr 12, 2013 at 03:36:44PM +0100, Dave Martin wrote:

[...]

> > > > > According to the ePAPR, threads are represented by an array of ids for
> > > > > reg property, not another cpu node. Why the deviation.
> > > >
> > > > It is not a cpu node, it is a phandle property named cpu. Can you point
> > > > me to the ePAPR section where threads bindings are described please ? I have
> > > > not managed to find these details, I am reading version 1.0.
> > >
> > > For cpu/reg:
> > >
> > > [1]     If a CPU supports more than one thread (i.e. multiple streams of
> > >         execution) the reg property is an array with 1 element per
> > >         thread. The #address-cells on the /cpus node specifies how many
> > >         cells each element of the array takes. Software can determine
> > >         the number of threads by dividing the size of reg by the parent
> > >         node's #address-cells.
> > >
> > > I had not previously been aware of this, but I see no reason not to
> > > follow this convention.
> >
> > I don't see a reason either, but this changes the current cpu node bindings
> > for ARM. On the upside there are no SMT ARM platforms out there, so no
> > backward compatibility to worry about.
> 
> Actually, I've had second thoughts about this, from discussion with Mark
> et al.
> 
> The extent to which threads share stuff is not really architecturally
> visible on ARM.  It will be visible in performance terms (i.e., scheduling
> two threads of the same process on threads of on CPU will give better
> performance than scheduling threads of different processes), but in
> architectural terms still look like fully-fledged, independent CPUs.
> 
> I don't know enough about how SMT scheduling currently works in the
> kernel to know how best to describe this situation to the kernel...
> 
> 
> Anyway, for the ARM case, there is not much architectural difference
> between threads within a CPU, and CPUs in a cluster.  At both topological
> levels the siblings are independent.  At both levels, there is an advantage
> in scheduling related threads topologically close to each other -- though
> probably more so for threads in a CPU than CPUs in a cluster.
> 
> Also, threads are independent interrupt destinations.  If we want to
> put flat lists of SMT threads inside CPU nodes, then we need an
> extra means of describing interrupt affinities, different from the
> way this is described for CPUs and clusters.  This is definitely
> complexity.  I'm not sure if there is a related benefit.

Yes, I agree, I think the bindings we came up with are neater than
having threads as multiple reg properties in cpu nodes and adding cluster
nodes (within cpus node or elsewhere). On the interrupt affinity side I think
that it should still be feasible since cpu nodes would become containers
of threads, and cluster nodes containers (or pointed at by) of cpu nodes, but
it is true that the description won't be uniform anymore.

I prefer our solution :-)

> > This would reduce the topology problem to where cluster nodes should be
> > defined, either in the cpus node or a separate node (ie cpu-map :-)).
> >
> > > Also:
> > > [2]     If other more complex CPU topographies are designed, the binding
> > >         for the CPU must describe the topography
> > >
> > >
> > > That's rather less helpful, but the suggestion is clear enough in that
> > > such information should be in the cpu node and specific to that CPU's
> > > binding.  For ARM, we can have some global extensions to the CPU node.
> > >
> > > The problems start when you want to refer to clusters and groups of
> > > CPUs from other nodes.  Only individual cpu nodes can be places in
> > > the cpus node, so there is no node for a phandle to point at.
> > >
> > > If you want to describe how other things like power, clock and
> > > coherency domains map to clusters and larger entities, things could
> > > get pretty awkward.
> > >
> > > Keeping the topology description separate allows all topological entities
> > > to appear as addressable entities in the DT; otherwise, a cryptic
> > > convention is needed.
> > >
> > >
> > > Hybrid approaches might be possible, putting cpu nodes into /cpus, and
> > > giving them a "parent" property where appropriate pointing at the
> > > relevant cluster node, which we put elsewhere in the DT.
> >
> > That's what I did, with a couple of twists:
> >
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2012-January/080873.html
> >
> > I have no preference, time to make a decision though.
> 
> With the arguments above, I'm not sure this is really better than the
> current proposal...
>

I am not sure either, that's why I would like to hear other opinions as well.

> > > I'm not sure whether any of these approaches is an awful lot less ugly
> > > or more easy to handle than what it currently proposed though.
> >
> > +1
> >
> > > The global binding for all ARM CPUs would specify that the topology
> > > is described by /cpu-map and its associated binding.  For my
> > > interpretation of [2], this is a compliant approach.  ePAPR does not
> > > specify _how_ the cpu node binding achieves a description of the
> > > topography, just that it must achieve it.  There's no statement to
> > > say that it must not involve other nodes or bindings.

I agree with you, the SMT thread specification in the ePAPR would become
a bit confusing though for ARM, we must make sure that what we are doing
and the ePAPR spec evolve in concert otherwise this will become unmanageable
in the long run.

> > Again, I think it all boils down to deciding where cluster nodes should
> > live.
> 
> If we want to be able to describe affinities and other hardware linkages,
> describing the real hardware units as nodes still feels "right".
> ePAPR doesn't insist upon how this is done, so we do have choice.
> 
> The older/hybrid proposals seem to require different means of describing
> linkage depending on whether the target is a topological leaf or not.
> 
> I guess the question should be "what advantage is gained from describing
> this stuff in the cpus node?"

We do not need phandles (pointers to cpu nodes) to describe the topology,
I guess, is the only answer.
Backward compatibility is still my main worry as far as the ePAPR is
concerned, so I am still looking forward to getting feedback from powerPC
and DT people on our proposal.

Thanks a lot,
Lorenzo



From swarren at wwwdotorg.org  Fri Apr 12 13:01:52 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Fri, 12 Apr 2013 11:01:52 -0600
Subject: [PATCH 1/3] ARM: tegra: pcie: Add tegra3 support
In-Reply-To: <C79B248886DD134989C8FF6B096A91AB91B36FB300@BGMAIL01.nvidia.com>
References: <1365435688-4179-1-git-send-email-jagarwal@nvidia.com>
 <51630ABB.1020200@wwwdotorg.org>
 <C79B248886DD134989C8FF6B096A91AB91B36FB300@BGMAIL01.nvidia.com>
Message-ID: <51683E00.4020506@wwwdotorg.org>

On 04/12/2013 10:43 AM, Jay Agarwal wrote:
>> On 04/08/2013 09:41 AM, Jay Agarwal wrote:
>>> Signed-off-by: Jay Agarwal <jagarwal at nvidia.com>
>>>
>>> - Enable pcie root port 2 for cardhu
>>> - Make private data structure for each SOC
>>> - Add required tegra3 clocks and regulators
>>> - Add tegra3 specific code in enable controller
>>> - Modify clock tree to get clocks based on device
>>> - Based on git://gitorious.org/thierryreding/linux.git
>> 	
>> A couple more points on this patch:
>>
>> * You didn't mention that this series is based on Thierry's work-in-progress
>> tree, and not something immediately destined for upstream. As such, only
>> Thierry is expected to actually apply any of these patches.
>>
> [>] Stephen, I have mentioned it in comment description as Based on git://gitorious.org/thierryreding/linux.git, is this not enough?

Well, first off, there are many branches there, and secondly the branch
that a series is based on doesn't necessarily imply much about what you
expect people to do with it.

> 
>> * Your changes to the Tegra PCIe driver require that device tree include
>> extra clocks and regulators. You need to update
>> Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt to describe
>> these new requirements.
>
> [>] Should I create tegra30-pcie.txt? or made changes in tegra20-pcie.txt itself?

(What is "[>]"?)

It'd probably be simplest to edit tegra20-pcie.txt, and just mention the
extra requirements for Tegra30.


From jagarwal at nvidia.com  Fri Apr 12 13:06:12 2013
From: jagarwal at nvidia.com (Jay Agarwal)
Date: Fri, 12 Apr 2013 22:36:12 +0530
Subject: [PATCH 1/3] ARM: tegra: pcie: Add tegra3 support
In-Reply-To: <51683E00.4020506@wwwdotorg.org>
References: <1365435688-4179-1-git-send-email-jagarwal@nvidia.com>
 <51630ABB.1020200@wwwdotorg.org>
 <C79B248886DD134989C8FF6B096A91AB91B36FB300@BGMAIL01.nvidia.com>
 <51683E00.4020506@wwwdotorg.org>
Message-ID: <C79B248886DD134989C8FF6B096A91AB91B36FB302@BGMAIL01.nvidia.com>

> On 04/12/2013 10:43 AM, Jay Agarwal wrote:
> >> On 04/08/2013 09:41 AM, Jay Agarwal wrote:
> >>> Signed-off-by: Jay Agarwal <jagarwal at nvidia.com>
> >>>
> >>> - Enable pcie root port 2 for cardhu
> >>> - Make private data structure for each SOC
> >>> - Add required tegra3 clocks and regulators
> >>> - Add tegra3 specific code in enable controller
> >>> - Modify clock tree to get clocks based on device
> >>> - Based on git://gitorious.org/thierryreding/linux.git
> >>
> >> A couple more points on this patch:
> >>
> >> * You didn't mention that this series is based on Thierry's
> >> work-in-progress tree, and not something immediately destined for
> >> upstream. As such, only Thierry is expected to actually apply any of these
> patches.
> >>
> > [>] Stephen, I have mentioned it in comment description as Based on
> git://gitorious.org/thierryreding/linux.git, is this not enough?
> 
> Well, first off, there are many branches there, and secondly the branch that
> a series is based on doesn't necessarily imply much about what you expect
> people to do with it.
> 
I am not clear, What should I mention then?



From marc.zyngier at arm.com  Fri Apr 12 13:13:48 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Fri, 12 Apr 2013 18:13:48 +0100
Subject: [PATCH] ARM: KVM: fix unbalanced get_cpu() in access_dcsw
Message-ID: <1365786828-548-1-git-send-email-marc.zyngier@arm.com>

In the very unlikely event where a guest would be foolish enough to
*read* from a write-only cache maintainance register, we end up
with preemption disabled, due to a misplaced get_cpu().

Just move the "is_write" test outside of the critical section.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm/kvm/coproc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/kvm/coproc.c b/arch/arm/kvm/coproc.c
index 94eee8b..8eea97b 100644
--- a/arch/arm/kvm/coproc.c
+++ b/arch/arm/kvm/coproc.c
@@ -79,11 +79,11 @@ static bool access_dcsw(struct kvm_vcpu *vcpu,
 	unsigned long val;
 	int cpu;
 
-	cpu = get_cpu();
-
 	if (!p->is_write)
 		return read_from_write_only(vcpu, p);
 
+	cpu = get_cpu();
+
 	cpumask_setall(&vcpu->arch.require_dcache_flush);
 	cpumask_clear_cpu(cpu, &vcpu->arch.require_dcache_flush);
 
-- 
1.8.1.4




From lars at metafoo.de  Fri Apr 12 13:28:39 2013
From: lars at metafoo.de (Lars-Peter Clausen)
Date: Fri, 12 Apr 2013 19:28:39 +0200
Subject: [PATCH] SPI: spidev: Add DT compatible string for spidev driver.
In-Reply-To: <51681743.4020001@parkeon.com>
References: <20130412125621.9645.78102.stgit@localhost>
 <51680C91.6030005@free-electrons.com> <51681743.4020001@parkeon.com>
Message-ID: <51684447.4040600@metafoo.de>

On 04/12/2013 04:16 PM, Martin Fuzzey wrote:
> Hi Maxime,
> 
> On 12/04/13 15:30, Maxime Ripard wrote:
>> I submitted a similar patch quite some time ago [1], and at the time, this
>> patch was found inadequate, and we decided to add the compatible of the
>> particular device that we drive through spidev. 
> 
> Thanks for pointing this out.
> 
>> The rationale behind that is that the device tree is a hardware
>> description, so it's only interested about which device there is on the
>> SPI bus, and not the driver that will eventually handle it. That allows
>> both to have a meaningful devicetree, but also to easily handle the case
>> where a driver for that particular device is finally implemented, since we
>> won't have to change the device tree in itself to reflect this. 
> 
> I'm not sure this is really an advantage of using a "real" compatible string.
> 
> When a kernel driver is finally implemented it will not have the same
> userspace interface as spidev.
> 
> This means that the switch from spidev to the kernel driver will not be
> transparent to userspace.
> 
> So, if a "real" compatible string is used, upon upgrading to a new version
> of the kernel that adds support for that device userspace will break.
> 
> Using a generic compatible string allows the board maintainer to decide when
> to switch by updating the DT.
> 
> Of course, when a custom kernel is being configured and compiled, the
> problem can also be solved by not enabling the new driver but I thought one
> of the goals of DT was to enable using a single distribution style binary
> kernel images on multiple boards.
> 
> Note that my patch only changes the driver, not any DTS.
> Indeed I agree that _using_ a generic compatible string in an _in kernel_
> DTS would be a mistake for the reasons you point out.
> 
> The use case I'm talking about is where a mainline kernel is used but with a
> custom out of tree DTS - why force people to patch the driver for this use
> case?
> 
> Best regards,
> 
> Martin

In my opinion it would be good if we had a mechanism to bind to create a
spidev device for an existing spi device from sysfs. You wouldn't need any
special compilable strings in the spidev driver and could use it for any spi
device you'd like to.

- Lars


From mturquette at linaro.org  Fri Apr 12 13:55:13 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Fri, 12 Apr 2013 10:55:13 -0700
Subject: [PATCH v3] clk: add device tree fixed-factor-clock binding support
In-Reply-To: <1365767864-7829-2-git-send-email-gregory.clement@free-electrons.com>
References: <1365767864-7829-1-git-send-email-gregory.clement@free-electrons.com>
 <1365767864-7829-2-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <20130412175513.6507.64606@quantum>

Quoting Gregory CLEMENT (2013-04-12 04:57:44)
> Add support for DT "fixed-factor-clock" binding to the common fixed
> factor clock support.
> 
> Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
> Tested-by: Christian Ruppert <christian.ruppert at abilis.com>

Nice.  Taken into clk-next.

Thanks,
Mike

> ---
>  .../bindings/clock/fixed-factor-clock.txt          |   24 +++++++++++++
>  drivers/clk/clk-fixed-factor.c                     |   36 ++++++++++++++++++++
>  include/linux/clk-provider.h                       |    2 ++
>  3 files changed, 62 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/clock/fixed-factor-clock.txt
> 
> diff --git a/Documentation/devicetree/bindings/clock/fixed-factor-clock.txt b/Documentation/devicetree/bindings/clock/fixed-factor-clock.txt
> new file mode 100644
> index 0000000..5757f9a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/fixed-factor-clock.txt
> @@ -0,0 +1,24 @@
> +Binding for simple fixed factor rate clock sources.
> +
> +This binding uses the common clock binding[1].
> +
> +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
> +
> +Required properties:
> +- compatible : shall be "fixed-factor-clock".
> +- #clock-cells : from common clock binding; shall be set to 0.
> +- clock-div: fixed divider.
> +- clock-mult: fixed multiplier.
> +- clocks: parent clock.
> +
> +Optional properties:
> +- clock-output-names : From common clock binding.
> +
> +Example:
> +       clock {
> +               compatible = "fixed-factor-clock";
> +               clocks = <&parentclk>;
> +               #clock-cells = <0>;
> +               div = <2>;
> +               mult = <1>;
> +       };
> diff --git a/drivers/clk/clk-fixed-factor.c b/drivers/clk/clk-fixed-factor.c
> index 1ef271e..9ff7d51 100644
> --- a/drivers/clk/clk-fixed-factor.c
> +++ b/drivers/clk/clk-fixed-factor.c
> @@ -11,6 +11,7 @@
>  #include <linux/clk-provider.h>
>  #include <linux/slab.h>
>  #include <linux/err.h>
> +#include <linux/of.h>
>  
>  /*
>   * DOC: basic fixed multiplier and divider clock that cannot gate
> @@ -96,3 +97,38 @@ struct clk *clk_register_fixed_factor(struct device *dev, const char *name,
>  
>         return clk;
>  }
> +#ifdef CONFIG_OF
> +/**
> + * of_fixed_factor_clk_setup() - Setup function for simple fixed factor clock
> + */
> +void __init of_fixed_factor_clk_setup(struct device_node *node)
> +{
> +       struct clk *clk;
> +       const char *clk_name = node->name;
> +       const char *parent_name;
> +       u32 div, mult;
> +
> +       if (of_property_read_u32(node, "clock-div", &div)) {
> +               pr_err("%s Fixed factor clock <%s> must have a clock-div property\n",
> +                       __func__, node->name);
> +               return;
> +       }
> +
> +       if (of_property_read_u32(node, "clock-mult", &mult)) {
> +               pr_err("%s Fixed factor clock <%s> must have a clokc-mult property\n",
> +                       __func__, node->name);
> +               return;
> +       }
> +
> +       of_property_read_string(node, "clock-output-names", &clk_name);
> +       parent_name = of_clk_get_parent_name(node, 0);
> +
> +       clk = clk_register_fixed_factor(NULL, clk_name, parent_name, 0,
> +                                       mult, div);
> +       if (!IS_ERR(clk))
> +               of_clk_add_provider(node, of_clk_src_simple_get, clk);
> +}
> +EXPORT_SYMBOL_GPL(of_fixed_factor_clk_setup);
> +CLK_OF_DECLARE(fixed_factor_clk, "fixed-factor-clock",
> +               of_fixed_factor_clk_setup);
> +#endif
> diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
> index 7f197d7..7ea501b 100644
> --- a/include/linux/clk-provider.h
> +++ b/include/linux/clk-provider.h
> @@ -325,6 +325,8 @@ struct clk *clk_register_fixed_factor(struct device *dev, const char *name,
>                 const char *parent_name, unsigned long flags,
>                 unsigned int mult, unsigned int div);
>  
> +void of_fixed_factor_clk_setup(struct device_node *node);
> +
>  /**
>   * clk_register - allocate a new clock, register it and return an opaque cookie
>   * @dev: device that is registering this clock
> -- 
> 1.7.9.5


From will.deacon at arm.com  Fri Apr 12 14:02:07 2013
From: will.deacon at arm.com (Will Deacon)
Date: Fri, 12 Apr 2013 19:02:07 +0100
Subject: [PATCH v2] documentation: iommu: add description of ARM System MMU
 binding
Message-ID: <1365789727-5371-1-git-send-email-will.deacon@arm.com>

This patch adds a description of the device tree binding for the ARM
System MMU architecture.

Cc: Rob Herring <robherring2 at gmail.com>
Cc: Andreas Herrmann <andreas.herrmann at calxeda.com>
Signed-off-by: Will Deacon <will.deacon at arm.com>
---
 .../devicetree/bindings/iommu/arm,smmu.txt         | 66 ++++++++++++++++++++++
 1 file changed, 66 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iommu/arm,smmu.txt

diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
new file mode 100644
index 0000000..56de07c
--- /dev/null
+++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
@@ -0,0 +1,66 @@
+* ARM System MMU Architecture Implementation
+
+ARM SoCs may contain an implementation of the ARM System Memory
+Management Unit Architecture, which can be used to provide 1 or 2 stages
+of address translation to bus masters external to the CPU.
+
+The SMMU may also raise interrupts in response to various fault
+conditions.
+
+** System MMU required properties:
+
+- compatible    : Should be one of:
+
+                        "arm,smmu-v1"
+                        "arm,smmu-v2"
+                        "arm,mmu-400"
+
+                  depending on the particular implementation and/or the
+                  version of the architecture implemented.
+
+- reg           : Base address and size of the SMMU.
+
+- #global-interrupts : The number of global interrupts exposed by the
+                       device.
+
+- interrupts    : Interrupt list, with the first #global-irqs entries
+                  corresponding to the global interrupts and any
+                  following entries corresponding to context interrupts,
+                  specified in order of their indexing by the SMMU.
+
+- mmu-masters   : A list of phandles to device nodes representing bus
+                  masters for which the SMMU can provide a translation.
+
+- stream-ids    : A list of 32-bit values corresponding to the StreamIDs
+                  for the devices listed in the mmu-masters property.
+                  This list must be same length as mmu-masters, so
+                  masters with multiple stream-ids will have multiple
+                  entries in mmu-masters.
+
+** System MMU optional properties:
+
+- smmu-parent   : When multiple SMMUs are chained together, this
+                  property can be used to provide a phandle to the
+                  parent SMMU (that is the next SMMU on the path going
+                  from the mmu-masters towards memory) node for this
+                  SMMU.
+
+Example:
+
+        smmu {
+                compatible = "arm,smmu-v1";
+                reg = <0xba5e0000 0x10000>;
+                #global-interrupts = <2>;
+                interrupts = <0 32 4>,
+                             <0 33 4>,
+                             <0 34 4>, /* This is the first context interrupt */
+                             <0 35 4>,
+                             <0 36 4>,
+                             <0 37 4>;
+                mmu-masters = <&dma0>,
+                              <&dma0>,
+                              <&dma1>;
+                stream-ids  = <0xd01d>,
+                              <0xd01e>,
+                              <0xd11c>;
+        };
-- 
1.8.0



From marc.zyngier at arm.com  Fri Apr 12 14:12:02 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Fri, 12 Apr 2013 19:12:02 +0100
Subject: [PATCH v4 2/7] ARM: KVM: fix HYP mapping limitations around zero
In-Reply-To: <1365790327-2138-1-git-send-email-marc.zyngier@arm.com>
References: <1365790327-2138-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1365790327-2138-3-git-send-email-marc.zyngier@arm.com>

The current code for creating HYP mapping doesn't like to wrap
around zero, which prevents from mapping anything into the last
page of the virtual address space.

It doesn't take much effort to remove this limitation, making
the code more consistent with the rest of the kernel in the process.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm/kvm/mmu.c | 21 ++++++++++-----------
 1 file changed, 10 insertions(+), 11 deletions(-)

diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
index 3003321..96d61da 100644
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@ -131,11 +131,12 @@ static void create_hyp_pte_mappings(pmd_t *pmd, unsigned long start,
 	pte_t *pte;
 	unsigned long addr;
 
-	for (addr = start; addr < end; addr += PAGE_SIZE) {
+	addr = start;
+	do {
 		pte = pte_offset_kernel(pmd, addr);
 		kvm_set_pte(pte, pfn_pte(pfn, prot));
 		pfn++;
-	}
+	} while (addr += PAGE_SIZE, addr != end);
 }
 
 static int create_hyp_pmd_mappings(pud_t *pud, unsigned long start,
@@ -146,7 +147,8 @@ static int create_hyp_pmd_mappings(pud_t *pud, unsigned long start,
 	pte_t *pte;
 	unsigned long addr, next;
 
-	for (addr = start; addr < end; addr = next) {
+	addr = start;
+	do {
 		pmd = pmd_offset(pud, addr);
 
 		BUG_ON(pmd_sect(*pmd));
@@ -164,7 +166,7 @@ static int create_hyp_pmd_mappings(pud_t *pud, unsigned long start,
 
 		create_hyp_pte_mappings(pmd, addr, next, pfn, prot);
 		pfn += (next - addr) >> PAGE_SHIFT;
-	}
+	} while (addr = next, addr != end);
 
 	return 0;
 }
@@ -179,11 +181,10 @@ static int __create_hyp_mappings(pgd_t *pgdp,
 	unsigned long addr, next;
 	int err = 0;
 
-	if (start >= end)
-		return -EINVAL;
-
 	mutex_lock(&kvm_hyp_pgd_mutex);
-	for (addr = start & PAGE_MASK; addr < end; addr = next) {
+	addr = start & PAGE_MASK;
+	end = PAGE_ALIGN(end);
+	do {
 		pgd = pgdp + pgd_index(addr);
 		pud = pud_offset(pgd, addr);
 
@@ -202,7 +203,7 @@ static int __create_hyp_mappings(pgd_t *pgdp,
 		if (err)
 			goto out;
 		pfn += (next - addr) >> PAGE_SHIFT;
-	}
+	} while (addr = next, addr != end);
 out:
 	mutex_unlock(&kvm_hyp_pgd_mutex);
 	return err;
@@ -216,8 +217,6 @@ out:
  * The same virtual address as the kernel virtual address is also used
  * in Hyp-mode mapping (modulo HYP_PAGE_OFFSET) to the same underlying
  * physical pages.
- *
- * Note: Wrapping around zero in the "to" address is not supported.
  */
 int create_hyp_mappings(void *from, void *to)
 {
-- 
1.8.1.4




From marc.zyngier at arm.com  Fri Apr 12 14:12:00 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Fri, 12 Apr 2013 19:12:00 +0100
Subject: [PATCH v4 0/7] ARM: KVM: Revamping the HYP init code for fun and
 profit
Message-ID: <1365790327-2138-1-git-send-email-marc.zyngier@arm.com>

Over the past few weeks, I've gradually realized how broken our HYP
idmap code is. Badly broken.

The main problem is about supporting CPU hotplug. Imagine a CPU being
initialized normally, running VMs, and then being powered down. So
far, so good. Now mentally bring it back online. The CPU will come
back via the secondary CPU boot path, and then what? We cannot use it
anymore, because we need an idmap which is long gone, and because our
page tables are now live, containing the world-switch code, VM
structures, and other bits and pieces.

Another fun issue is that we don't have any TLB invalidation in the
HYP init code. And guess what? we cannot do it! HYP TLB invalidation
has to occur in HYP, and once we've installed the runtime page tables,
it is already too late. It is actually fairly easy to construct a
scenario where idmap and runtime pages have colliding translations.

The nail on the coffin was provided by Catalin Marinas who told me how
much he disliked the arm64 HYP idmap code, and made me realize that we
already have all the necessary code in arch/arm/kvm/mmu.c. It just
needs a tiny bit of care and affection. With a chainsaw.

The solution to the first two issues is a bit tricky, but doesn't
involve a lot of code. The hotplug problem mandates that we keep two
sets of page tables (boot and runtime). The TLB problem mandates that
we're able to transition from one PGD to another while in HYP,
invalidating the TLBs in the process.

To be able to do this, we need to share a page between the two page
tables. A page that will have the same VA in both configurations. All
we need is a VA that has the following properties:
- This VA can't be used to represent a kernel mapping.
- This VA will not conflict with the physical address of the kernel
  text

The vectors page VA seems to satisfy this requirement:
- The kernel never maps anything else there
- The kernel text being copied at the beginning of the physical
  memory, it is unlikely to use the last 64kB (I doubt we'll ever
  support KVM on a system with something like 4MB of RAM, but patches
  are very welcome).

Let's call this VA the trampoline VA.

Now, we map our init page at 3 locations:
- idmap in the boot pgd
- trampoline VA in the boot pgd
- trampoline VA in the runtime pgd

The init scenario is now the following:
- We jump in HYP with four parameters: boot HYP pgd, runtime HYP pgd,
  runtime stack, runtime vectors
- Enable the MMU with the boot pgd
- Jump to a target into the trampoline page (remember, this is the
  same physical page!)
- Now switch to the runtime pgd (same VA, and still the same physical
  page!)
- Invalidate TLBs
- Set stack and vectors
- Profit! (or eret, if you only care about the code).

Once we have this infrastructure in place, supporting CPU hot-plug is
a piece of cake. Just wire a cpu-notifier in the existing code.

This has been tested on both arm (VE TC2) and arm64 (Foundation Model).

>From v3:
- Remove stray conflict left in the middle of patch 6/7.
  Always send the patch series you're actually testing...

>From v2:
- Change the init.S calling convention to pass the PGD in r2-r3,
  removing the horrible endianess-dependant split of the 64bit
  physical address.
- Fix the HYP page table freeing code by getting rid of it. Our
  stage-2 code does it a lot better, and I'd rather fix bugs only
  once.
- Flush HYP page tables to the Point of Coherency. This ensures that
  the incoming CPU will see the page tables, even with cache disabled
  (spotted by Will).
- Use kmalloc instead of kzalloc for the bounce page (spotted by
  Christoffer).

>From v1:
- Reduce the mandatory alignement of the init code page, and use a
  bounce page if the code is crossing a page boundary.
- Add some more comments to the code (as requested by Christoffer)
- Fixed compilation issue with older toolchains (spotted by Geoff)

Marc Zyngier (7):
  ARM: KVM: simplify HYP mapping population
  ARM: KVM: fix HYP mapping limitations around zero
  ARM: KVM: move to a KVM provided HYP idmap
  ARM: KVM: enforce maximum size for identity mapped code
  ARM: KVM: rework HYP page table freeing
  ARM: KVM: switch to a dual-step HYP init code
  ARM: KVM: perform HYP initilization for hotplugged CPUs

 arch/arm/include/asm/idmap.h    |   1 -
 arch/arm/include/asm/kvm_host.h |  31 +--
 arch/arm/include/asm/kvm_mmu.h  |  28 ++-
 arch/arm/kernel/vmlinux.lds.S   |   7 +-
 arch/arm/kvm/arm.c              |  62 ++++--
 arch/arm/kvm/init.S             |  78 +++++--
 arch/arm/kvm/mmu.c              | 455 +++++++++++++++++++++++-----------------
 arch/arm/mm/idmap.c             |  32 +--
 8 files changed, 404 insertions(+), 290 deletions(-)

-- 
1.8.1.4




From marc.zyngier at arm.com  Fri Apr 12 14:12:04 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Fri, 12 Apr 2013 19:12:04 +0100
Subject: [PATCH v4 4/7] ARM: KVM: enforce maximum size for identity mapped code
In-Reply-To: <1365790327-2138-1-git-send-email-marc.zyngier@arm.com>
References: <1365790327-2138-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1365790327-2138-5-git-send-email-marc.zyngier@arm.com>

We're about to move to an init procedure where we rely on the
fact that the init code fits in a single page. Make sure we
align the idmap text on a vector alignment, and that the code is
not bigger than a single page.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm/kernel/vmlinux.lds.S | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
index b571484..a871b8e 100644
--- a/arch/arm/kernel/vmlinux.lds.S
+++ b/arch/arm/kernel/vmlinux.lds.S
@@ -20,7 +20,7 @@
 	VMLINUX_SYMBOL(__idmap_text_start) = .;				\
 	*(.idmap.text)							\
 	VMLINUX_SYMBOL(__idmap_text_end) = .;				\
-	ALIGN_FUNCTION();						\
+	. = ALIGN(32);							\
 	VMLINUX_SYMBOL(__hyp_idmap_text_start) = .;			\
 	*(.hyp.idmap.text)						\
 	VMLINUX_SYMBOL(__hyp_idmap_text_end) = .;
@@ -315,3 +315,8 @@ SECTIONS
  */
 ASSERT((__proc_info_end - __proc_info_begin), "missing CPU support")
 ASSERT((__arch_info_end - __arch_info_begin), "no machine record defined")
+/*
+ * The HYP init code can't be more than a page long.
+ * The above comment applies as well.
+ */
+ASSERT(((__hyp_idmap_text_end - __hyp_idmap_text_start) <= PAGE_SIZE), "HYP init code too big")
-- 
1.8.1.4




From marc.zyngier at arm.com  Fri Apr 12 14:12:03 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Fri, 12 Apr 2013 19:12:03 +0100
Subject: [PATCH v4 3/7] ARM: KVM: move to a KVM provided HYP idmap
In-Reply-To: <1365790327-2138-1-git-send-email-marc.zyngier@arm.com>
References: <1365790327-2138-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1365790327-2138-4-git-send-email-marc.zyngier@arm.com>

After the HYP page table rework, it is pretty easy to let the KVM
code provide its own idmap, rather than expecting the kernel to
provide it. It takes actually less code to do so.

Acked-by: Will Deacon <will.deacon at arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm/include/asm/idmap.h   |  1 -
 arch/arm/include/asm/kvm_mmu.h |  1 -
 arch/arm/kvm/mmu.c             | 24 +++++++++++++++++++++++-
 arch/arm/mm/idmap.c            | 32 +-------------------------------
 4 files changed, 24 insertions(+), 34 deletions(-)

diff --git a/arch/arm/include/asm/idmap.h b/arch/arm/include/asm/idmap.h
index 1a66f907..bf863ed 100644
--- a/arch/arm/include/asm/idmap.h
+++ b/arch/arm/include/asm/idmap.h
@@ -8,7 +8,6 @@
 #define __idmap __section(.idmap.text) noinline notrace
 
 extern pgd_t *idmap_pgd;
-extern pgd_t *hyp_pgd;
 
 void setup_mm_for_reboot(void);
 
diff --git a/arch/arm/include/asm/kvm_mmu.h b/arch/arm/include/asm/kvm_mmu.h
index 970f3b5..3c71a1d 100644
--- a/arch/arm/include/asm/kvm_mmu.h
+++ b/arch/arm/include/asm/kvm_mmu.h
@@ -21,7 +21,6 @@
 
 #include <asm/cacheflush.h>
 #include <asm/pgalloc.h>
-#include <asm/idmap.h>
 
 /*
  * We directly use the kernel VA for the HYP, as we can directly share
diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
index 96d61da..bfc5927 100644
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@ -32,6 +32,7 @@
 
 extern char  __hyp_idmap_text_start[], __hyp_idmap_text_end[];
 
+static pgd_t *hyp_pgd;
 static DEFINE_MUTEX(kvm_hyp_pgd_mutex);
 
 static void kvm_tlb_flush_vmid_ipa(struct kvm *kvm, phys_addr_t ipa)
@@ -715,12 +716,33 @@ phys_addr_t kvm_mmu_get_httbr(void)
 
 int kvm_mmu_init(void)
 {
+	unsigned long hyp_idmap_start = virt_to_phys(__hyp_idmap_text_start);
+	unsigned long hyp_idmap_end = virt_to_phys(__hyp_idmap_text_end);
+	int err;
+
+	hyp_pgd = kzalloc(PTRS_PER_PGD * sizeof(pgd_t), GFP_KERNEL);
 	if (!hyp_pgd) {
 		kvm_err("Hyp mode PGD not allocated\n");
-		return -ENOMEM;
+		err = -ENOMEM;
+		goto out;
+	}
+
+	/* Create the idmap in the boot page tables */
+	err = 	__create_hyp_mappings(boot_hyp_pgd,
+				      hyp_idmap_start, hyp_idmap_end,
+				      __phys_to_pfn(hyp_idmap_start),
+				      PAGE_HYP);
+
+	if (err) {
+		kvm_err("Failed to idmap %lx-%lx\n",
+			hyp_idmap_start, hyp_idmap_end);
+		goto out;
 	}
 
 	return 0;
+out:
+	kfree(hyp_pgd);
+	return err;
 }
 
 /**
diff --git a/arch/arm/mm/idmap.c b/arch/arm/mm/idmap.c
index 5ee505c..83cb3ac 100644
--- a/arch/arm/mm/idmap.c
+++ b/arch/arm/mm/idmap.c
@@ -8,7 +8,6 @@
 #include <asm/pgtable.h>
 #include <asm/sections.h>
 #include <asm/system_info.h>
-#include <asm/virt.h>
 
 pgd_t *idmap_pgd;
 
@@ -83,37 +82,10 @@ static void identity_mapping_add(pgd_t *pgd, const char *text_start,
 	} while (pgd++, addr = next, addr != end);
 }
 
-#if defined(CONFIG_ARM_VIRT_EXT) && defined(CONFIG_ARM_LPAE)
-pgd_t *hyp_pgd;
-
-extern char  __hyp_idmap_text_start[], __hyp_idmap_text_end[];
-
-static int __init init_static_idmap_hyp(void)
-{
-	hyp_pgd = kzalloc(PTRS_PER_PGD * sizeof(pgd_t), GFP_KERNEL);
-	if (!hyp_pgd)
-		return -ENOMEM;
-
-	pr_info("Setting up static HYP identity map for 0x%p - 0x%p\n",
-		__hyp_idmap_text_start, __hyp_idmap_text_end);
-	identity_mapping_add(hyp_pgd, __hyp_idmap_text_start,
-			     __hyp_idmap_text_end, PMD_SECT_AP1);
-
-	return 0;
-}
-#else
-static int __init init_static_idmap_hyp(void)
-{
-	return 0;
-}
-#endif
-
 extern char  __idmap_text_start[], __idmap_text_end[];
 
 static int __init init_static_idmap(void)
 {
-	int ret;
-
 	idmap_pgd = pgd_alloc(&init_mm);
 	if (!idmap_pgd)
 		return -ENOMEM;
@@ -123,12 +95,10 @@ static int __init init_static_idmap(void)
 	identity_mapping_add(idmap_pgd, __idmap_text_start,
 			     __idmap_text_end, 0);
 
-	ret = init_static_idmap_hyp();
-
 	/* Flush L1 for the hardware to see this page table content */
 	flush_cache_louis();
 
-	return ret;
+	return 0;
 }
 early_initcall(init_static_idmap);
 
-- 
1.8.1.4




From marc.zyngier at arm.com  Fri Apr 12 14:12:01 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Fri, 12 Apr 2013 19:12:01 +0100
Subject: [PATCH v4 1/7] ARM: KVM: simplify HYP mapping population
In-Reply-To: <1365790327-2138-1-git-send-email-marc.zyngier@arm.com>
References: <1365790327-2138-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1365790327-2138-2-git-send-email-marc.zyngier@arm.com>

The way we populate HYP mappings is a bit convoluted, to say the least.
Passing a pointer around to keep track of the current PFN is quite
odd, and we end-up having two different PTE accessors for no good
reason.

Simplify the whole thing by unifying the two PTE accessors, passing
a pgprot_t around, and moving the various validity checks to the
upper layers.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm/kvm/mmu.c | 102 ++++++++++++++++++++++-------------------------------
 1 file changed, 42 insertions(+), 60 deletions(-)

diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
index 2f12e40..3003321 100644
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@ -125,54 +125,34 @@ void free_hyp_pmds(void)
 }
 
 static void create_hyp_pte_mappings(pmd_t *pmd, unsigned long start,
-				    unsigned long end)
+				    unsigned long end, unsigned long pfn,
+				    pgprot_t prot)
 {
 	pte_t *pte;
 	unsigned long addr;
-	struct page *page;
 
-	for (addr = start & PAGE_MASK; addr < end; addr += PAGE_SIZE) {
-		unsigned long hyp_addr = KERN_TO_HYP(addr);
-
-		pte = pte_offset_kernel(pmd, hyp_addr);
-		BUG_ON(!virt_addr_valid(addr));
-		page = virt_to_page(addr);
-		kvm_set_pte(pte, mk_pte(page, PAGE_HYP));
-	}
-}
-
-static void create_hyp_io_pte_mappings(pmd_t *pmd, unsigned long start,
-				       unsigned long end,
-				       unsigned long *pfn_base)
-{
-	pte_t *pte;
-	unsigned long addr;
-
-	for (addr = start & PAGE_MASK; addr < end; addr += PAGE_SIZE) {
-		unsigned long hyp_addr = KERN_TO_HYP(addr);
-
-		pte = pte_offset_kernel(pmd, hyp_addr);
-		BUG_ON(pfn_valid(*pfn_base));
-		kvm_set_pte(pte, pfn_pte(*pfn_base, PAGE_HYP_DEVICE));
-		(*pfn_base)++;
+	for (addr = start; addr < end; addr += PAGE_SIZE) {
+		pte = pte_offset_kernel(pmd, addr);
+		kvm_set_pte(pte, pfn_pte(pfn, prot));
+		pfn++;
 	}
 }
 
 static int create_hyp_pmd_mappings(pud_t *pud, unsigned long start,
-				   unsigned long end, unsigned long *pfn_base)
+				   unsigned long end, unsigned long pfn,
+				   pgprot_t prot)
 {
 	pmd_t *pmd;
 	pte_t *pte;
 	unsigned long addr, next;
 
 	for (addr = start; addr < end; addr = next) {
-		unsigned long hyp_addr = KERN_TO_HYP(addr);
-		pmd = pmd_offset(pud, hyp_addr);
+		pmd = pmd_offset(pud, addr);
 
 		BUG_ON(pmd_sect(*pmd));
 
 		if (pmd_none(*pmd)) {
-			pte = pte_alloc_one_kernel(NULL, hyp_addr);
+			pte = pte_alloc_one_kernel(NULL, addr);
 			if (!pte) {
 				kvm_err("Cannot allocate Hyp pte\n");
 				return -ENOMEM;
@@ -182,25 +162,17 @@ static int create_hyp_pmd_mappings(pud_t *pud, unsigned long start,
 
 		next = pmd_addr_end(addr, end);
 
-		/*
-		 * If pfn_base is NULL, we map kernel pages into HYP with the
-		 * virtual address. Otherwise, this is considered an I/O
-		 * mapping and we map the physical region starting at
-		 * *pfn_base to [start, end[.
-		 */
-		if (!pfn_base)
-			create_hyp_pte_mappings(pmd, addr, next);
-		else
-			create_hyp_io_pte_mappings(pmd, addr, next, pfn_base);
+		create_hyp_pte_mappings(pmd, addr, next, pfn, prot);
+		pfn += (next - addr) >> PAGE_SHIFT;
 	}
 
 	return 0;
 }
 
-static int __create_hyp_mappings(void *from, void *to, unsigned long *pfn_base)
+static int __create_hyp_mappings(pgd_t *pgdp,
+				 unsigned long start, unsigned long end,
+				 unsigned long pfn, pgprot_t prot)
 {
-	unsigned long start = (unsigned long)from;
-	unsigned long end = (unsigned long)to;
 	pgd_t *pgd;
 	pud_t *pud;
 	pmd_t *pmd;
@@ -209,21 +181,14 @@ static int __create_hyp_mappings(void *from, void *to, unsigned long *pfn_base)
 
 	if (start >= end)
 		return -EINVAL;
-	/* Check for a valid kernel memory mapping */
-	if (!pfn_base && (!virt_addr_valid(from) || !virt_addr_valid(to - 1)))
-		return -EINVAL;
-	/* Check for a valid kernel IO mapping */
-	if (pfn_base && (!is_vmalloc_addr(from) || !is_vmalloc_addr(to - 1)))
-		return -EINVAL;
 
 	mutex_lock(&kvm_hyp_pgd_mutex);
-	for (addr = start; addr < end; addr = next) {
-		unsigned long hyp_addr = KERN_TO_HYP(addr);
-		pgd = hyp_pgd + pgd_index(hyp_addr);
-		pud = pud_offset(pgd, hyp_addr);
+	for (addr = start & PAGE_MASK; addr < end; addr = next) {
+		pgd = pgdp + pgd_index(addr);
+		pud = pud_offset(pgd, addr);
 
 		if (pud_none_or_clear_bad(pud)) {
-			pmd = pmd_alloc_one(NULL, hyp_addr);
+			pmd = pmd_alloc_one(NULL, addr);
 			if (!pmd) {
 				kvm_err("Cannot allocate Hyp pmd\n");
 				err = -ENOMEM;
@@ -233,9 +198,10 @@ static int __create_hyp_mappings(void *from, void *to, unsigned long *pfn_base)
 		}
 
 		next = pgd_addr_end(addr, end);
-		err = create_hyp_pmd_mappings(pud, addr, next, pfn_base);
+		err = create_hyp_pmd_mappings(pud, addr, next, pfn, prot);
 		if (err)
 			goto out;
+		pfn += (next - addr) >> PAGE_SHIFT;
 	}
 out:
 	mutex_unlock(&kvm_hyp_pgd_mutex);
@@ -255,22 +221,38 @@ out:
  */
 int create_hyp_mappings(void *from, void *to)
 {
-	return __create_hyp_mappings(from, to, NULL);
+	unsigned long phys_addr = virt_to_phys(from);
+	unsigned long start = KERN_TO_HYP((unsigned long)from);
+	unsigned long end = KERN_TO_HYP((unsigned long)to);
+
+	/* Check for a valid kernel memory mapping */
+	if (!virt_addr_valid(from) || !virt_addr_valid(to - 1))
+		return -EINVAL;
+
+	return __create_hyp_mappings(hyp_pgd, start, end,
+				     __phys_to_pfn(phys_addr), PAGE_HYP);
 }
 
 /**
  * create_hyp_io_mappings - duplicate a kernel IO mapping into Hyp mode
  * @from:	The kernel start VA of the range
  * @to:		The kernel end VA of the range (exclusive)
- * @addr:	The physical start address which gets mapped
+ * @phys_addr:	The physical start address which gets mapped
  *
  * The resulting HYP VA is the same as the kernel VA, modulo
  * HYP_PAGE_OFFSET.
  */
-int create_hyp_io_mappings(void *from, void *to, phys_addr_t addr)
+int create_hyp_io_mappings(void *from, void *to, phys_addr_t phys_addr)
 {
-	unsigned long pfn = __phys_to_pfn(addr);
-	return __create_hyp_mappings(from, to, &pfn);
+	unsigned long start = KERN_TO_HYP((unsigned long)from);
+	unsigned long end = KERN_TO_HYP((unsigned long)to);
+
+	/* Check for a valid kernel IO mapping */
+	if (!is_vmalloc_addr(from) || !is_vmalloc_addr(to - 1))
+		return -EINVAL;
+
+	return __create_hyp_mappings(hyp_pgd, start, end,
+				     __phys_to_pfn(phys_addr), PAGE_HYP_DEVICE);
 }
 
 /**
-- 
1.8.1.4




From marc.zyngier at arm.com  Fri Apr 12 14:12:07 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Fri, 12 Apr 2013 19:12:07 +0100
Subject: [PATCH v4 7/7] ARM: KVM: perform HYP initilization for hotplugged CPUs
In-Reply-To: <1365790327-2138-1-git-send-email-marc.zyngier@arm.com>
References: <1365790327-2138-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1365790327-2138-8-git-send-email-marc.zyngier@arm.com>

Now that we have the necessary infrastructure to boot a hotplugged CPU
at any point in time, wire a CPU notifier that will perform the HYP
init for the incoming CPU.

Note that this depends on the platform code and/or firmware to boot the
incoming CPU with HYP mode enabled and return to the kernel by following
the normal boot path (HYP stub installed).

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm/include/asm/kvm_mmu.h |  1 +
 arch/arm/kvm/arm.c             | 49 +++++++++++++++++++++++++++++-------------
 arch/arm/kvm/mmu.c             | 35 ++++++++++++++++++++++++------
 3 files changed, 63 insertions(+), 22 deletions(-)

diff --git a/arch/arm/include/asm/kvm_mmu.h b/arch/arm/include/asm/kvm_mmu.h
index 24b767a..472ac70 100644
--- a/arch/arm/include/asm/kvm_mmu.h
+++ b/arch/arm/include/asm/kvm_mmu.h
@@ -44,6 +44,7 @@
 
 int create_hyp_mappings(void *from, void *to);
 int create_hyp_io_mappings(void *from, void *to, phys_addr_t);
+void free_boot_hyp_pgd(void);
 void free_hyp_pgds(void);
 
 int kvm_alloc_stage2_pgd(struct kvm *kvm);
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index f8fbab3..fa177df 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -16,6 +16,7 @@
  * Foundation, 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.
  */
 
+#include <linux/cpu.h>
 #include <linux/errno.h>
 #include <linux/err.h>
 #include <linux/kvm_host.h>
@@ -794,7 +795,7 @@ long kvm_arch_vm_ioctl(struct file *filp,
 	}
 }
 
-static void cpu_init_hyp_mode(void *vector)
+static void cpu_init_hyp_mode(void *dummy)
 {
 	unsigned long long boot_pgd_ptr;
 	unsigned long long pgd_ptr;
@@ -814,12 +815,28 @@ static void cpu_init_hyp_mode(void *vector)
 	__cpu_init_hyp_mode(boot_pgd_ptr, pgd_ptr, hyp_stack_ptr, vector_ptr);
 }
 
+static int hyp_init_cpu_notify(struct notifier_block *self,
+			       unsigned long action, void *cpu)
+{
+	switch (action) {
+	case CPU_STARTING:
+	case CPU_STARTING_FROZEN:
+		cpu_init_hyp_mode(NULL);
+		break;
+	}
+
+	return NOTIFY_OK;
+}
+
+static struct notifier_block hyp_init_cpu_nb = {
+	.notifier_call = hyp_init_cpu_notify,
+};
+
 /**
  * Inits Hyp-mode on all online CPUs
  */
 static int init_hyp_mode(void)
 {
-	phys_addr_t init_phys_addr;
 	int cpu;
 	int err = 0;
 
@@ -852,19 +869,6 @@ static int init_hyp_mode(void)
 	}
 
 	/*
-	 * Execute the init code on each CPU.
-	 *
-	 * Note: The stack is not mapped yet, so don't do anything else than
-	 * initializing the hypervisor mode on each CPU using a local stack
-	 * space for temporary storage.
-	 */
-	init_phys_addr = virt_to_phys(__kvm_hyp_init);
-	for_each_online_cpu(cpu) {
-		smp_call_function_single(cpu, cpu_init_hyp_mode,
-					 (void *)(long)init_phys_addr, 1);
-	}
-
-	/*
 	 * Map the Hyp-code called directly from the host
 	 */
 	err = create_hyp_mappings(__kvm_hyp_code_start, __kvm_hyp_code_end);
@@ -909,6 +913,11 @@ static int init_hyp_mode(void)
 	}
 
 	/*
+	 * Execute the init code on each CPU.
+	 */
+	on_each_cpu(cpu_init_hyp_mode, NULL, 1);
+
+	/*
 	 * Init HYP view of VGIC
 	 */
 	err = kvm_vgic_hyp_init();
@@ -926,6 +935,10 @@ static int init_hyp_mode(void)
 	if (err)
 		goto out_free_mappings;
 
+#ifndef CONFIG_HOTPLUG_CPU
+	free_boot_hyp_pgd();
+#endif
+
 	kvm_perf_init();
 
 	kvm_info("Hyp mode initialized successfully\n");
@@ -964,6 +977,12 @@ int kvm_arch_init(void *opaque)
 	if (err)
 		goto out_err;
 
+	err = register_cpu_notifier(&hyp_init_cpu_nb);
+	if (err) {
+		kvm_err("Cannot register HYP init CPU notifier (%d)\n", err);
+		goto out_err;
+	}
+
 	kvm_coproc_table_init();
 	return 0;
 out_err:
diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
index 4646c17..9657065 100644
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@ -156,6 +156,31 @@ static void unmap_range(pgd_t *pgdp, unsigned long long start, u64 size)
 }
 
 /**
+ * free_boot_hyp_pgd - free HYP boot page tables
+ *
+ * Free the HYP boot page tables. The bounce page is also freed.
+ */
+void free_boot_hyp_pgd(void)
+{
+	mutex_lock(&kvm_hyp_pgd_mutex);
+
+	if (boot_hyp_pgd) {
+		unmap_range(boot_hyp_pgd, hyp_idmap_start, PAGE_SIZE);
+		unmap_range(boot_hyp_pgd, TRAMPOLINE_VA, PAGE_SIZE);
+		kfree(boot_hyp_pgd);
+		boot_hyp_pgd = NULL;
+	}
+
+	if (hyp_pgd)
+		unmap_range(hyp_pgd, TRAMPOLINE_VA, PAGE_SIZE);
+
+	kfree(init_bounce_page);
+	init_bounce_page = NULL;
+
+	mutex_unlock(&kvm_hyp_pgd_mutex);
+}
+
+/**
  * free_hyp_pgds - free Hyp-mode page tables
  *
  * Assumes hyp_pgd is a page table used strictly in Hyp-mode and
@@ -169,13 +194,9 @@ void free_hyp_pgds(void)
 {
 	unsigned long addr;
 
-	mutex_lock(&kvm_hyp_pgd_mutex);
+	free_boot_hyp_pgd();
 
-	if (boot_hyp_pgd) {
-		unmap_range(boot_hyp_pgd, hyp_idmap_start, PAGE_SIZE);
-		unmap_range(boot_hyp_pgd, TRAMPOLINE_VA, PAGE_SIZE);
-		kfree(boot_hyp_pgd);
-	}
+	mutex_lock(&kvm_hyp_pgd_mutex);
 
 	if (hyp_pgd) {
 		for (addr = PAGE_OFFSET; virt_addr_valid(addr); addr += PGDIR_SIZE)
@@ -183,9 +204,9 @@ void free_hyp_pgds(void)
 		for (addr = VMALLOC_START; is_vmalloc_addr((void*)addr); addr += PGDIR_SIZE)
 			unmap_range(hyp_pgd, KERN_TO_HYP(addr), PGDIR_SIZE);
 		kfree(hyp_pgd);
+		hyp_pgd = NULL;
 	}
 
-	kfree(init_bounce_page);
 	mutex_unlock(&kvm_hyp_pgd_mutex);
 }
 
-- 
1.8.1.4




From marc.zyngier at arm.com  Fri Apr 12 14:12:05 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Fri, 12 Apr 2013 19:12:05 +0100
Subject: [PATCH v4 5/7] ARM: KVM: rework HYP page table freeing
In-Reply-To: <1365790327-2138-1-git-send-email-marc.zyngier@arm.com>
References: <1365790327-2138-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1365790327-2138-6-git-send-email-marc.zyngier@arm.com>

There is no point in freeing HYP page tables differently from Stage-2.
They now have the same requirements, and should be dealt with the same way.

Promote unmap_stage2_range to be The One True Way, and get rid of a number
of nasty bugs in the process (goo thing we never actually called free_hyp_pmds
before...).

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm/include/asm/kvm_mmu.h |   2 +-
 arch/arm/kvm/arm.c             |   2 +-
 arch/arm/kvm/mmu.c             | 181 ++++++++++++++++++-----------------------
 3 files changed, 82 insertions(+), 103 deletions(-)

diff --git a/arch/arm/include/asm/kvm_mmu.h b/arch/arm/include/asm/kvm_mmu.h
index 3c71a1d..92eb20d 100644
--- a/arch/arm/include/asm/kvm_mmu.h
+++ b/arch/arm/include/asm/kvm_mmu.h
@@ -32,7 +32,7 @@
 
 int create_hyp_mappings(void *from, void *to);
 int create_hyp_io_mappings(void *from, void *to, phys_addr_t);
-void free_hyp_pmds(void);
+void free_hyp_pgds(void);
 
 int kvm_alloc_stage2_pgd(struct kvm *kvm);
 void kvm_free_stage2_pgd(struct kvm *kvm);
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index 23538ed..8992f05 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -937,7 +937,7 @@ static int init_hyp_mode(void)
 out_free_context:
 	free_percpu(kvm_host_cpu_state);
 out_free_mappings:
-	free_hyp_pmds();
+	free_hyp_pgds();
 out_free_stack_pages:
 	for_each_possible_cpu(cpu)
 		free_page(per_cpu(kvm_arm_hyp_stack_page, cpu));
diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
index bfc5927..7464824 100644
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@ -72,56 +72,104 @@ static void *mmu_memory_cache_alloc(struct kvm_mmu_memory_cache *mc)
 	return p;
 }
 
-static void free_ptes(pmd_t *pmd, unsigned long addr)
+static void clear_pud_entry(pud_t *pud)
 {
-	pte_t *pte;
-	unsigned int i;
+	pmd_t *pmd_table = pmd_offset(pud, 0);
+	pud_clear(pud);
+	pmd_free(NULL, pmd_table);
+	put_page(virt_to_page(pud));
+}
 
-	for (i = 0; i < PTRS_PER_PMD; i++, addr += PMD_SIZE) {
-		if (!pmd_none(*pmd) && pmd_table(*pmd)) {
-			pte = pte_offset_kernel(pmd, addr);
-			pte_free_kernel(NULL, pte);
-		}
-		pmd++;
+static void clear_pmd_entry(pmd_t *pmd)
+{
+	pte_t *pte_table = pte_offset_kernel(pmd, 0);
+	pmd_clear(pmd);
+	pte_free_kernel(NULL, pte_table);
+	put_page(virt_to_page(pmd));
+}
+
+static bool pmd_empty(pmd_t *pmd)
+{
+	struct page *pmd_page = virt_to_page(pmd);
+	return page_count(pmd_page) == 1;
+}
+
+static void clear_pte_entry(pte_t *pte)
+{
+	if (pte_present(*pte)) {
+		kvm_set_pte(pte, __pte(0));
+		put_page(virt_to_page(pte));
 	}
 }
 
-static void free_hyp_pgd_entry(unsigned long addr)
+static bool pte_empty(pte_t *pte)
+{
+	struct page *pte_page = virt_to_page(pte);
+	return page_count(pte_page) == 1;
+}
+
+static void unmap_range(pgd_t *pgdp, unsigned long long start, u64 size)
 {
 	pgd_t *pgd;
 	pud_t *pud;
 	pmd_t *pmd;
-	unsigned long hyp_addr = KERN_TO_HYP(addr);
+	pte_t *pte;
+	unsigned long long addr = start, end = start + size;
+	u64 range;
 
-	pgd = hyp_pgd + pgd_index(hyp_addr);
-	pud = pud_offset(pgd, hyp_addr);
+	while (addr < end) {
+		pgd = pgdp + pgd_index(addr);
+		pud = pud_offset(pgd, addr);
+		if (pud_none(*pud)) {
+			addr += PUD_SIZE;
+			continue;
+		}
 
-	if (pud_none(*pud))
-		return;
-	BUG_ON(pud_bad(*pud));
+		pmd = pmd_offset(pud, addr);
+		if (pmd_none(*pmd)) {
+			addr += PMD_SIZE;
+			continue;
+		}
 
-	pmd = pmd_offset(pud, hyp_addr);
-	free_ptes(pmd, addr);
-	pmd_free(NULL, pmd);
-	pud_clear(pud);
+		pte = pte_offset_kernel(pmd, addr);
+		clear_pte_entry(pte);
+		range = PAGE_SIZE;
+
+		/* If we emptied the pte, walk back up the ladder */
+		if (pte_empty(pte)) {
+			clear_pmd_entry(pmd);
+			range = PMD_SIZE;
+			if (pmd_empty(pmd)) {
+				clear_pud_entry(pud);
+				range = PUD_SIZE;
+			}
+		}
+
+		addr += range;
+	}
 }
 
 /**
- * free_hyp_pmds - free a Hyp-mode level-2 tables and child level-3 tables
+ * free_hyp_pgds - free Hyp-mode page tables
  *
- * Assumes this is a page table used strictly in Hyp-mode and therefore contains
+ * Assumes hyp_pgd is a page table used strictly in Hyp-mode and therefore contains
  * either mappings in the kernel memory area (above PAGE_OFFSET), or
  * device mappings in the vmalloc range (from VMALLOC_START to VMALLOC_END).
  */
-void free_hyp_pmds(void)
+void free_hyp_pgds(void)
 {
 	unsigned long addr;
 
 	mutex_lock(&kvm_hyp_pgd_mutex);
-	for (addr = PAGE_OFFSET; virt_addr_valid(addr); addr += PGDIR_SIZE)
-		free_hyp_pgd_entry(addr);
-	for (addr = VMALLOC_START; is_vmalloc_addr((void*)addr); addr += PGDIR_SIZE)
-		free_hyp_pgd_entry(addr);
+
+	if (hyp_pgd) {
+		for (addr = PAGE_OFFSET; virt_addr_valid(addr); addr += PGDIR_SIZE)
+			unmap_range(hyp_pgd, KERN_TO_HYP(addr), PGDIR_SIZE);
+		for (addr = VMALLOC_START; is_vmalloc_addr((void*)addr); addr += PGDIR_SIZE)
+			unmap_range(hyp_pgd, KERN_TO_HYP(addr), PGDIR_SIZE);
+		kfree(hyp_pgd);
+	}
+
 	mutex_unlock(&kvm_hyp_pgd_mutex);
 }
 
@@ -136,6 +184,7 @@ static void create_hyp_pte_mappings(pmd_t *pmd, unsigned long start,
 	do {
 		pte = pte_offset_kernel(pmd, addr);
 		kvm_set_pte(pte, pfn_pte(pfn, prot));
+		get_page(virt_to_page(pte));
 		pfn++;
 	} while (addr += PAGE_SIZE, addr != end);
 }
@@ -161,6 +210,7 @@ static int create_hyp_pmd_mappings(pud_t *pud, unsigned long start,
 				return -ENOMEM;
 			}
 			pmd_populate_kernel(NULL, pmd, pte);
+			get_page(virt_to_page(pmd));
 		}
 
 		next = pmd_addr_end(addr, end);
@@ -197,6 +247,7 @@ static int __create_hyp_mappings(pgd_t *pgdp,
 				goto out;
 			}
 			pud_populate(NULL, pud, pmd);
+			get_page(virt_to_page(pud));
 		}
 
 		next = pgd_addr_end(addr, end);
@@ -289,42 +340,6 @@ int kvm_alloc_stage2_pgd(struct kvm *kvm)
 	return 0;
 }
 
-static void clear_pud_entry(pud_t *pud)
-{
-	pmd_t *pmd_table = pmd_offset(pud, 0);
-	pud_clear(pud);
-	pmd_free(NULL, pmd_table);
-	put_page(virt_to_page(pud));
-}
-
-static void clear_pmd_entry(pmd_t *pmd)
-{
-	pte_t *pte_table = pte_offset_kernel(pmd, 0);
-	pmd_clear(pmd);
-	pte_free_kernel(NULL, pte_table);
-	put_page(virt_to_page(pmd));
-}
-
-static bool pmd_empty(pmd_t *pmd)
-{
-	struct page *pmd_page = virt_to_page(pmd);
-	return page_count(pmd_page) == 1;
-}
-
-static void clear_pte_entry(pte_t *pte)
-{
-	if (pte_present(*pte)) {
-		kvm_set_pte(pte, __pte(0));
-		put_page(virt_to_page(pte));
-	}
-}
-
-static bool pte_empty(pte_t *pte)
-{
-	struct page *pte_page = virt_to_page(pte);
-	return page_count(pte_page) == 1;
-}
-
 /**
  * unmap_stage2_range -- Clear stage2 page table entries to unmap a range
  * @kvm:   The VM pointer
@@ -338,43 +353,7 @@ static bool pte_empty(pte_t *pte)
  */
 static void unmap_stage2_range(struct kvm *kvm, phys_addr_t start, u64 size)
 {
-	pgd_t *pgd;
-	pud_t *pud;
-	pmd_t *pmd;
-	pte_t *pte;
-	phys_addr_t addr = start, end = start + size;
-	u64 range;
-
-	while (addr < end) {
-		pgd = kvm->arch.pgd + pgd_index(addr);
-		pud = pud_offset(pgd, addr);
-		if (pud_none(*pud)) {
-			addr += PUD_SIZE;
-			continue;
-		}
-
-		pmd = pmd_offset(pud, addr);
-		if (pmd_none(*pmd)) {
-			addr += PMD_SIZE;
-			continue;
-		}
-
-		pte = pte_offset_kernel(pmd, addr);
-		clear_pte_entry(pte);
-		range = PAGE_SIZE;
-
-		/* If we emptied the pte, walk back up the ladder */
-		if (pte_empty(pte)) {
-			clear_pmd_entry(pmd);
-			range = PMD_SIZE;
-			if (pmd_empty(pmd)) {
-				clear_pud_entry(pud);
-				range = PUD_SIZE;
-			}
-		}
-
-		addr += range;
-	}
+	unmap_range(kvm->arch.pgd, start, size);
 }
 
 /**
@@ -741,7 +720,7 @@ int kvm_mmu_init(void)
 
 	return 0;
 out:
-	kfree(hyp_pgd);
+	free_hyp_pgds();
 	return err;
 }
 
-- 
1.8.1.4




From marc.zyngier at arm.com  Fri Apr 12 14:12:06 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Fri, 12 Apr 2013 19:12:06 +0100
Subject: [PATCH v4 6/7] ARM: KVM: switch to a dual-step HYP init code
In-Reply-To: <1365790327-2138-1-git-send-email-marc.zyngier@arm.com>
References: <1365790327-2138-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1365790327-2138-7-git-send-email-marc.zyngier@arm.com>

Our HYP init code suffers from two major design issues:
- it cannot support CPU hotplug, as we tear down the idmap very early
- it cannot perform a TLB invalidation when switching from init to
  runtime mappings, as pages are manipulated from PL1 exclusively

The hotplug problem mandates that we keep two sets of page tables
(boot and runtime). The TLB problem mandates that we're able to
transition from one PGD to another while in HYP, invalidating the TLBs
in the process.

To be able to do this, we need to share a page between the two page
tables. A page that will have the same VA in both configurations. All we
need is a VA that has the following properties:
- This VA can't be used to represent a kernel mapping.
- This VA will not conflict with the physical address of the kernel text

The vectors page seems to satisfy this requirement:
- The kernel never maps anything else there
- The kernel text being copied at the beginning of the physical memory,
  it is unlikely to use the last 64kB (I doubt we'll ever support KVM
  on a system with something like 4MB of RAM, but patches are very
  welcome).

Let's call this VA the trampoline VA.

Now, we map our init page at 3 locations:
- idmap in the boot pgd
- trampoline VA in the boot pgd
- trampoline VA in the runtime pgd

The init scenario is now the following:
- We jump in HYP with four parameters: boot HYP pgd, runtime HYP pgd,
  runtime stack, runtime vectors
- Enable the MMU with the boot pgd
- Jump to a target into the trampoline page (remember, this is the same
  physical page!)
- Now switch to the runtime pgd (same VA, and still the same physical
  page!)
- Invalidate TLBs
- Set stack and vectors
- Profit! (or eret, if you only care about the code).

Note that we keep the boot mapping permanently (it is not strictly an
idmap anymore) to allow for CPU hotplug in later patches.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm/include/asm/kvm_host.h |  31 ++++++----
 arch/arm/include/asm/kvm_mmu.h  |  24 +++++++-
 arch/arm/kvm/arm.c              |  11 ++--
 arch/arm/kvm/init.S             |  78 ++++++++++++++++++------
 arch/arm/kvm/mmu.c              | 132 ++++++++++++++++++++++++++++------------
 5 files changed, 197 insertions(+), 79 deletions(-)

diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
index a2907fb..57cb786 100644
--- a/arch/arm/include/asm/kvm_host.h
+++ b/arch/arm/include/asm/kvm_host.h
@@ -190,23 +190,30 @@ int kvm_arm_coproc_set_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *);
 int handle_exit(struct kvm_vcpu *vcpu, struct kvm_run *run,
 		int exception_index);
 
-static inline void __cpu_init_hyp_mode(unsigned long long pgd_ptr,
+static inline void __cpu_init_hyp_mode(unsigned long long boot_pgd_ptr,
+				       unsigned long long pgd_ptr,
 				       unsigned long hyp_stack_ptr,
 				       unsigned long vector_ptr)
 {
-	unsigned long pgd_low, pgd_high;
-
-	pgd_low = (pgd_ptr & ((1ULL << 32) - 1));
-	pgd_high = (pgd_ptr >> 32ULL);
-
 	/*
-	 * Call initialization code, and switch to the full blown
-	 * HYP code. The init code doesn't need to preserve these registers as
-	 * r1-r3 and r12 are already callee save according to the AAPCS.
-	 * Note that we slightly misuse the prototype by casing the pgd_low to
-	 * a void *.
+	 * Call initialization code, and switch to the full blown HYP
+	 * code. The init code doesn't need to preserve these
+	 * registers as r0-r3 are already callee saved according to
+	 * the AAPCS.
+	 * Note that we slightly misuse the prototype by casing the
+	 * stack pointer to a void *.
+	 *
+	 * We don't have enough registers to perform the full init in
+	 * one go.  Install the boot PGD first, and then install the
+	 * runtime PGD, stack pointer and vectors. The PGDs are always
+	 * passed as the third argument, in order to be passed into
+	 * r2-r3 to the init code (yes, this is compliant with the
+	 * PCS!).
 	 */
-	kvm_call_hyp((void *)pgd_low, pgd_high, hyp_stack_ptr, vector_ptr);
+
+	kvm_call_hyp(NULL, 0, boot_pgd_ptr);
+
+	kvm_call_hyp((void*)hyp_stack_ptr, vector_ptr, pgd_ptr);
 }
 
 static inline int kvm_arch_dev_ioctl_check_extension(long ext)
diff --git a/arch/arm/include/asm/kvm_mmu.h b/arch/arm/include/asm/kvm_mmu.h
index 92eb20d..24b767a 100644
--- a/arch/arm/include/asm/kvm_mmu.h
+++ b/arch/arm/include/asm/kvm_mmu.h
@@ -19,17 +19,29 @@
 #ifndef __ARM_KVM_MMU_H__
 #define __ARM_KVM_MMU_H__
 
-#include <asm/cacheflush.h>
-#include <asm/pgalloc.h>
+#include <asm/memory.h>
+#include <asm/page.h>
 
 /*
  * We directly use the kernel VA for the HYP, as we can directly share
  * the mapping (HTTBR "covers" TTBR1).
  */
-#define HYP_PAGE_OFFSET_MASK	(~0UL)
+#define HYP_PAGE_OFFSET_MASK	UL(~0)
 #define HYP_PAGE_OFFSET		PAGE_OFFSET
 #define KERN_TO_HYP(kva)	(kva)
 
+/*
+ * Our virtual mapping for the boot-time MMU-enable code. Must be
+ * shared across all the page-tables. Conveniently, we use the vectors
+ * page, where no kernel data will ever be shared with HYP.
+ */
+#define TRAMPOLINE_VA		UL(CONFIG_VECTORS_BASE)
+
+#ifndef __ASSEMBLY__
+
+#include <asm/cacheflush.h>
+#include <asm/pgalloc.h>
+
 int create_hyp_mappings(void *from, void *to);
 int create_hyp_io_mappings(void *from, void *to, phys_addr_t);
 void free_hyp_pgds(void);
@@ -44,6 +56,8 @@ int kvm_handle_guest_abort(struct kvm_vcpu *vcpu, struct kvm_run *run);
 void kvm_mmu_free_memory_caches(struct kvm_vcpu *vcpu);
 
 phys_addr_t kvm_mmu_get_httbr(void);
+phys_addr_t kvm_mmu_get_boot_httbr(void);
+phys_addr_t kvm_get_idmap_vector(void);
 int kvm_mmu_init(void);
 void kvm_clear_hyp_idmap(void);
 
@@ -113,4 +127,8 @@ static inline void coherent_icache_guest_page(struct kvm *kvm, gfn_t gfn)
 	}
 }
 
+#define kvm_flush_dcache_to_poc(a,l)	__cpuc_flush_dcache_area((a), (l))
+
+#endif	/* !__ASSEMBLY__ */
+
 #endif /* __ARM_KVM_MMU_H__ */
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index 8992f05..f8fbab3 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -796,20 +796,22 @@ long kvm_arch_vm_ioctl(struct file *filp,
 
 static void cpu_init_hyp_mode(void *vector)
 {
+	unsigned long long boot_pgd_ptr;
 	unsigned long long pgd_ptr;
 	unsigned long hyp_stack_ptr;
 	unsigned long stack_page;
 	unsigned long vector_ptr;
 
 	/* Switch from the HYP stub to our own HYP init vector */
-	__hyp_set_vectors((unsigned long)vector);
+	__hyp_set_vectors(kvm_get_idmap_vector());
 
+	boot_pgd_ptr = (unsigned long long)kvm_mmu_get_boot_httbr();
 	pgd_ptr = (unsigned long long)kvm_mmu_get_httbr();
 	stack_page = __get_cpu_var(kvm_arm_hyp_stack_page);
 	hyp_stack_ptr = stack_page + PAGE_SIZE;
 	vector_ptr = (unsigned long)__kvm_hyp_vector;
 
-	__cpu_init_hyp_mode(pgd_ptr, hyp_stack_ptr, vector_ptr);
+	__cpu_init_hyp_mode(boot_pgd_ptr, pgd_ptr, hyp_stack_ptr, vector_ptr);
 }
 
 /**
@@ -863,11 +865,6 @@ static int init_hyp_mode(void)
 	}
 
 	/*
-	 * Unmap the identity mapping
-	 */
-	kvm_clear_hyp_idmap();
-
-	/*
 	 * Map the Hyp-code called directly from the host
 	 */
 	err = create_hyp_mappings(__kvm_hyp_code_start, __kvm_hyp_code_end);
diff --git a/arch/arm/kvm/init.S b/arch/arm/kvm/init.S
index 9f37a79..f048338 100644
--- a/arch/arm/kvm/init.S
+++ b/arch/arm/kvm/init.S
@@ -21,13 +21,33 @@
 #include <asm/asm-offsets.h>
 #include <asm/kvm_asm.h>
 #include <asm/kvm_arm.h>
+#include <asm/kvm_mmu.h>
 
 /********************************************************************
  * Hypervisor initialization
  *   - should be called with:
- *       r0,r1 = Hypervisor pgd pointer
- *       r2 = top of Hyp stack (kernel VA)
- *       r3 = pointer to hyp vectors
+ *       r0 = top of Hyp stack (kernel VA)
+ *       r1 = pointer to hyp vectors
+ *       r2,r3 = Hypervisor pgd pointer
+ *
+ * The init scenario is:
+ * - We jump in HYP with four parameters: boot HYP pgd, runtime HYP pgd,
+ *   runtime stack, runtime vectors
+ * - Enable the MMU with the boot pgd
+ * - Jump to a target into the trampoline page (remember, this is the same
+ *   physical page!)
+ * - Now switch to the runtime pgd (same VA, and still the same physical
+ *   page!)
+ * - Invalidate TLBs
+ * - Set stack and vectors
+ * - Profit! (or eret, if you only care about the code).
+ *
+ * As we only have four registers available to pass parameters (and we
+ * need six), we split the init in two phases:
+ * - Phase 1: r0 = 0, r1 = 0, r2,r3 contain the boot PGD.
+ *   Provides the basic HYP init, and enable the MMU.
+ * - Phase 2: r0 = ToS, r1 = vectors, r2,r3 contain the runtime PGD.
+ *   Switches to the runtime PGD, set stack and vectors.
  */
 
 	.text
@@ -47,22 +67,25 @@ __kvm_hyp_init:
 	W(b)	.
 
 __do_hyp_init:
+	cmp	r0, #0			@ We have a SP?
+	bne	phase2			@ Yes, second stage init
+
 	@ Set the HTTBR to point to the hypervisor PGD pointer passed
-	mcrr	p15, 4, r0, r1, c2
+	mcrr	p15, 4, r2, r3, c2
 
 	@ Set the HTCR and VTCR to the same shareability and cacheability
 	@ settings as the non-secure TTBCR and with T0SZ == 0.
 	mrc	p15, 4, r0, c2, c0, 2	@ HTCR
-	ldr	r12, =HTCR_MASK
-	bic	r0, r0, r12
+	ldr	r2, =HTCR_MASK
+	bic	r0, r0, r2
 	mrc	p15, 0, r1, c2, c0, 2	@ TTBCR
 	and	r1, r1, #(HTCR_MASK & ~TTBCR_T0SZ)
 	orr	r0, r0, r1
 	mcr	p15, 4, r0, c2, c0, 2	@ HTCR
 
 	mrc	p15, 4, r1, c2, c1, 2	@ VTCR
-	ldr	r12, =VTCR_MASK
-	bic	r1, r1, r12
+	ldr	r2, =VTCR_MASK
+	bic	r1, r1, r2
 	bic	r0, r0, #(~VTCR_HTCR_SH)	@ clear non-reusable HTCR bits
 	orr	r1, r0, r1
 	orr	r1, r1, #(KVM_VTCR_SL0 | KVM_VTCR_T0SZ | KVM_VTCR_S)
@@ -85,24 +108,41 @@ __do_hyp_init:
 	@  - Memory alignment checks: enabled
 	@  - MMU: enabled (this code must be run from an identity mapping)
 	mrc	p15, 4, r0, c1, c0, 0	@ HSCR
-	ldr	r12, =HSCTLR_MASK
-	bic	r0, r0, r12
+	ldr	r2, =HSCTLR_MASK
+	bic	r0, r0, r2
 	mrc	p15, 0, r1, c1, c0, 0	@ SCTLR
-	ldr	r12, =(HSCTLR_EE | HSCTLR_FI | HSCTLR_I | HSCTLR_C)
-	and	r1, r1, r12
- ARM(	ldr	r12, =(HSCTLR_M | HSCTLR_A)			)
- THUMB(	ldr	r12, =(HSCTLR_M | HSCTLR_A | HSCTLR_TE)		)
-	orr	r1, r1, r12
+	ldr	r2, =(HSCTLR_EE | HSCTLR_FI | HSCTLR_I | HSCTLR_C)
+	and	r1, r1, r2
+ ARM(	ldr	r2, =(HSCTLR_M | HSCTLR_A)			)
+ THUMB(	ldr	r2, =(HSCTLR_M | HSCTLR_A | HSCTLR_TE)		)
+	orr	r1, r1, r2
 	orr	r0, r0, r1
 	isb
 	mcr	p15, 4, r0, c1, c0, 0	@ HSCR
-	isb
 
-	@ Set stack pointer and return to the kernel
-	mov	sp, r2
+	@ End of init phase-1
+	eret
+
+phase2:
+	@ Set stack pointer
+	mov	sp, r0
 
 	@ Set HVBAR to point to the HYP vectors
-	mcr	p15, 4, r3, c12, c0, 0	@ HVBAR
+	mcr	p15, 4, r1, c12, c0, 0	@ HVBAR
+
+	@ Jump to the trampoline page
+	ldr	r0, =TRAMPOLINE_VA
+	adr	r1, target
+	bfi	r0, r1, #0, #PAGE_SHIFT
+	mov	pc, r0
+
+target:	@ We're now in the trampoline code, switch page tables
+	mcrr	p15, 4, r2, r3, c2
+	isb
+
+	@ Invalidate the old TLBs
+	mcr	p15, 4, r0, c8, c7, 0	@ TLBIALLH
+	dsb
 
 	eret
 
diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
index 7464824..4646c17 100644
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@ -32,9 +32,15 @@
 
 extern char  __hyp_idmap_text_start[], __hyp_idmap_text_end[];
 
+static pgd_t *boot_hyp_pgd;
 static pgd_t *hyp_pgd;
 static DEFINE_MUTEX(kvm_hyp_pgd_mutex);
 
+static void *init_bounce_page;
+static unsigned long hyp_idmap_start;
+static unsigned long hyp_idmap_end;
+static phys_addr_t hyp_idmap_vector;
+
 static void kvm_tlb_flush_vmid_ipa(struct kvm *kvm, phys_addr_t ipa)
 {
 	kvm_call_hyp(__kvm_tlb_flush_vmid_ipa, kvm, ipa);
@@ -152,9 +158,12 @@ static void unmap_range(pgd_t *pgdp, unsigned long long start, u64 size)
 /**
  * free_hyp_pgds - free Hyp-mode page tables
  *
- * Assumes hyp_pgd is a page table used strictly in Hyp-mode and therefore contains
- * either mappings in the kernel memory area (above PAGE_OFFSET), or
- * device mappings in the vmalloc range (from VMALLOC_START to VMALLOC_END).
+ * Assumes hyp_pgd is a page table used strictly in Hyp-mode and
+ * therefore contains either mappings in the kernel memory area (above
+ * PAGE_OFFSET), or device mappings in the vmalloc range (from
+ * VMALLOC_START to VMALLOC_END).
+ *
+ * boot_hyp_pgd should only map two pages for the init code.
  */
 void free_hyp_pgds(void)
 {
@@ -162,6 +171,12 @@ void free_hyp_pgds(void)
 
 	mutex_lock(&kvm_hyp_pgd_mutex);
 
+	if (boot_hyp_pgd) {
+		unmap_range(boot_hyp_pgd, hyp_idmap_start, PAGE_SIZE);
+		unmap_range(boot_hyp_pgd, TRAMPOLINE_VA, PAGE_SIZE);
+		kfree(boot_hyp_pgd);
+	}
+
 	if (hyp_pgd) {
 		for (addr = PAGE_OFFSET; virt_addr_valid(addr); addr += PGDIR_SIZE)
 			unmap_range(hyp_pgd, KERN_TO_HYP(addr), PGDIR_SIZE);
@@ -170,6 +185,7 @@ void free_hyp_pgds(void)
 		kfree(hyp_pgd);
 	}
 
+	kfree(init_bounce_page);
 	mutex_unlock(&kvm_hyp_pgd_mutex);
 }
 
@@ -185,6 +201,7 @@ static void create_hyp_pte_mappings(pmd_t *pmd, unsigned long start,
 		pte = pte_offset_kernel(pmd, addr);
 		kvm_set_pte(pte, pfn_pte(pfn, prot));
 		get_page(virt_to_page(pte));
+		kvm_flush_dcache_to_poc(pte, sizeof(*pte));
 		pfn++;
 	} while (addr += PAGE_SIZE, addr != end);
 }
@@ -211,6 +228,7 @@ static int create_hyp_pmd_mappings(pud_t *pud, unsigned long start,
 			}
 			pmd_populate_kernel(NULL, pmd, pte);
 			get_page(virt_to_page(pmd));
+			kvm_flush_dcache_to_poc(pmd, sizeof(*pmd));
 		}
 
 		next = pmd_addr_end(addr, end);
@@ -248,6 +266,7 @@ static int __create_hyp_mappings(pgd_t *pgdp,
 			}
 			pud_populate(NULL, pud, pmd);
 			get_page(virt_to_page(pud));
+			kvm_flush_dcache_to_poc(pud, sizeof(*pud));
 		}
 
 		next = pgd_addr_end(addr, end);
@@ -689,18 +708,64 @@ void kvm_mmu_free_memory_caches(struct kvm_vcpu *vcpu)
 
 phys_addr_t kvm_mmu_get_httbr(void)
 {
-	VM_BUG_ON(!virt_addr_valid(hyp_pgd));
 	return virt_to_phys(hyp_pgd);
 }
 
+phys_addr_t kvm_mmu_get_boot_httbr(void)
+{
+	return virt_to_phys(boot_hyp_pgd);
+}
+
+phys_addr_t kvm_get_idmap_vector(void)
+{
+	return hyp_idmap_vector;
+}
+
 int kvm_mmu_init(void)
 {
-	unsigned long hyp_idmap_start = virt_to_phys(__hyp_idmap_text_start);
-	unsigned long hyp_idmap_end = virt_to_phys(__hyp_idmap_text_end);
 	int err;
 
+	hyp_idmap_start = virt_to_phys(__hyp_idmap_text_start);
+	hyp_idmap_end = virt_to_phys(__hyp_idmap_text_end);
+	hyp_idmap_vector = virt_to_phys(__kvm_hyp_init);
+
+	if ((hyp_idmap_start ^ hyp_idmap_end) & PAGE_MASK) {
+		/*
+		 * Our init code is crossing a page boundary. Allocate
+		 * a bounce page, copy the code over and use that.
+		 */
+		size_t len = __hyp_idmap_text_end - __hyp_idmap_text_start;
+		phys_addr_t phys_base;
+
+		init_bounce_page = kmalloc(PAGE_SIZE, GFP_KERNEL);
+		if (!init_bounce_page) {
+			kvm_err("Couldn't allocate HYP init bounce page\n");
+			err = -ENOMEM;
+			goto out;
+		}
+
+		memcpy(init_bounce_page, __hyp_idmap_text_start, len);
+		/*
+		 * Warning: the code we just copied to the bounce page
+		 * must be flushed to the point of coherency.
+		 * Otherwise, the data may be sitting in L2, and HYP
+		 * mode won't be able to observe it as it runs with
+		 * caches off at that point.
+		 */
+		kvm_flush_dcache_to_poc(init_bounce_page, len);
+
+		phys_base = virt_to_phys(init_bounce_page);
+		hyp_idmap_vector += phys_base - hyp_idmap_start;
+		hyp_idmap_start = phys_base;
+		hyp_idmap_end = phys_base + len;
+
+		kvm_info("Using HYP init bounce page @%lx\n",
+			 (unsigned long)phys_base);
+	}
+
 	hyp_pgd = kzalloc(PTRS_PER_PGD * sizeof(pgd_t), GFP_KERNEL);
-	if (!hyp_pgd) {
+	boot_hyp_pgd = kzalloc(PTRS_PER_PGD * sizeof(pgd_t), GFP_KERNEL);
+	if (!hyp_pgd || !boot_hyp_pgd) {
 		kvm_err("Hyp mode PGD not allocated\n");
 		err = -ENOMEM;
 		goto out;
@@ -718,39 +783,30 @@ int kvm_mmu_init(void)
 		goto out;
 	}
 
+	/* Map the very same page at the trampoline VA */
+	err = 	__create_hyp_mappings(boot_hyp_pgd,
+				      TRAMPOLINE_VA, TRAMPOLINE_VA + PAGE_SIZE,
+				      __phys_to_pfn(hyp_idmap_start),
+				      PAGE_HYP);
+	if (err) {
+		kvm_err("Failed to map trampoline @%lx into boot HYP pgd\n",
+			TRAMPOLINE_VA);
+		goto out;
+	}
+
+	/* Map the same page again into the runtime page tables */
+	err = 	__create_hyp_mappings(hyp_pgd,
+				      TRAMPOLINE_VA, TRAMPOLINE_VA + PAGE_SIZE,
+				      __phys_to_pfn(hyp_idmap_start),
+				      PAGE_HYP);
+	if (err) {
+		kvm_err("Failed to map trampoline @%lx into runtime HYP pgd\n",
+			TRAMPOLINE_VA);
+		goto out;
+	}
+
 	return 0;
 out:
 	free_hyp_pgds();
 	return err;
 }
-
-/**
- * kvm_clear_idmap - remove all idmaps from the hyp pgd
- *
- * Free the underlying pmds for all pgds in range and clear the pgds (but
- * don't free them) afterwards.
- */
-void kvm_clear_hyp_idmap(void)
-{
-	unsigned long addr, end;
-	unsigned long next;
-	pgd_t *pgd = hyp_pgd;
-	pud_t *pud;
-	pmd_t *pmd;
-
-	addr = virt_to_phys(__hyp_idmap_text_start);
-	end = virt_to_phys(__hyp_idmap_text_end);
-
-	pgd += pgd_index(addr);
-	do {
-		next = pgd_addr_end(addr, end);
-		if (pgd_none_or_clear_bad(pgd))
-			continue;
-		pud = pud_offset(pgd, addr);
-		pmd = pmd_offset(pud, addr);
-
-		pud_clear(pud);
-		kvm_clean_pmd_entry(pmd);
-		pmd_free(NULL, (pmd_t *)((unsigned long)pmd & PAGE_MASK));
-	} while (pgd++, addr = next, addr < end);
-}
-- 
1.8.1.4




From sergei.shtylyov at cogentembedded.com  Fri Apr 12 14:11:59 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Fri, 12 Apr 2013 22:11:59 +0400
Subject: [PATCH v3 0/9] Reorganize R8A7779/Marzen USB code
In-Reply-To: <20130412003457.GC24461@verge.net.au>
References: <201304100226.08967.sergei.shtylyov@cogentembedded.com>
 <20130410044923.GD10044@verge.net.au> <20130410085033.GL7983@arwen.pp.htv.fi>
 <20130410090543.GB25890@verge.net.au> <20130411005155.GA18530@verge.net.au>
 <5166A659.6060405@cogentembedded.com> <20130412003457.GC24461@verge.net.au>
Message-ID: <51684E6F.5030009@cogentembedded.com>

Hello.

On 04/12/2013 04:34 AM, Simon Horman wrote:

>>>>>>>     Here's the set of 9 patches against the Simon Horman's 'renesas.git' repo,
>>>>>>> 'renesas-next-20130410' tag.  It was created to fix the shortcomings in the
>>>>>>> R8A7779/Marzen USB platform code and R8A7779 USB common PHY driver, and so
>>>>>>> spans both arch/arm/mach-shmobile/ and drivers/usb/ subtrees (some patches have
>>>>>>> to touch both subtrees). The patches were conceived with the complete
>>>>>>> bisectability goal in mind.
>>>>>>> [1/9] ARM: shmobile: Marzen: move USB EHCI, OHCI, and PHY devices to R8A7779 code
>>>>>>> [2/9] ehci-platform: add pre_setup() method to platform data
>>>>>>> [3/9] ARM: shmobile: R8A7779: setup EHCI internal buffer
>>>>>>> [4/9] rcar-phy: remove EHCI internal buffer setup
>>>>>>> [5/9] ARM: shmobile: R8A7779: remove USB PHY 2nd memory resource
>>>>>>> [6/9] rcar-phy: correct base address
>>>>>>> [7/9] rcar-phy: add platform data
>>>>>>> [8/9] ARM: shmobile: Marzen: pass platform data to USB PHY device
>>>>>>> [9/9] rcar-phy: handle platform data
>>>>>>>     I'm not sure thru which tree this patchset should be merged, however it turns
>>>>>>> out that it's too late now to push it thru Felipe Balbi's USB tree for 3.10
>>>>>>> (which would have been most convenient probably), and it's probably too late to
>>>>>>> merge thru Simon's tree for 3.10 too. So it now have to be postponed to 3.11,
>>>>>>> unfortunately...
>>>>>> Felipe, how would you prefer to handle this?
>>>>>> I'm happy for you to take it or to take it myself.
>>>>> please take it yourself, just keep in mind there will be conflicts, I
>>>>> will go over the patches now and give my Acked-by so you can queue them
>>>>> up.
>>>> Thanks
>>> Sergei, it looks like patches 1-7 are clear.
>>     #7 & #9 have been refused by Felipe (hence #8 isn't good too).
>>
>>> Do you want me to start queueing them up.
>>     I was going to repost the whole series soon, adding ACK from Alan

    It's not as soon as I had hoped but I hope I would be able to do it
in several hours...

>> to the patch #2 and resolving issues with patches #7..#9. It's worth
>> waiting for that to happen I think.
> I am quite happy to wait.
>
> One minor comment - there is no need to repost just to fix this -
> could you consider using lower-case for the socs for consistency
> with the common practice in patch subject lines.
>
> e.g.: ARM: shmobile: r8a7779: setup EHCI

     Alright, although I have a kind of idiosyncrasy to lowercasing 
otherwise
uppercase names.

>
>>> Or would you rather wait for the issue with patch 6 to be resolved?
>>     There's no special issue with patch #6 other than the PHY driver
>> files being renamed in Felipe's tree -- but that concerns all
>> patches touching drivers/usb/phy/rcar-phy.c (some of which precede
>> #6).
> Sorry, I made an error. I meant #8 and in turn #9.

    The issues start at patch #7 actually, where the platform data
represenation seemed inappropriate to Felipe.

>
>>     I don't know how the rename conflict will be handled (this is
>> really bad coincidence), perhaps I still should have done this
>> patchset against Felipe's 'next' branch and pushed it thru his tree.
>> If the patches will be queued for 3.11 anyway, maybe it's worth
>> doing that -- I'm still of the opinion that his tree would be the
>> one most fitting for this patchset.
> It seems that git will handle it :)

     Well, let's hope. There's still an issue with header file name it
wouldn't be able to handle but I'll probably leave it as is, as the other
PHY files in include/linux/usb/ didn't get renamed in the big rename.

WBR, Sergei



From cjb at laptop.org  Fri Apr 12 14:14:00 2013
From: cjb at laptop.org (Chris Ball)
Date: Fri, 12 Apr 2013 14:14:00 -0400
Subject: [PATCH] mmc: mxcmmc: Fix bug when card is present during boot
In-Reply-To: <20130409073318.GF1906@pengutronix.de> (Sascha Hauer's message of
 "Tue, 9 Apr 2013 09:33:18 +0200")
References: <1365228811-10928-1-git-send-email-shc_work@mail.ru>
 <20130409073318.GF1906@pengutronix.de>
Message-ID: <87bo9jfwgn.fsf@octavius.laptop.org>

Hi,

On Tue, Apr 09 2013, Sascha Hauer wrote:
> On Sat, Apr 06, 2013 at 10:13:31AM +0400, Alexander Shiyan wrote:
>> This patch fixes bug when card is present during boot.
>> Bug was introduced due commit "mmc: mxcmmc: fix bug that may block a
>> data transfer forever". When a card is present "mxcmci_setup_data"
>> function is executed, but the timer is not initialized.
>
> Acked-by: Sascha Hauer <s.hauer at pengutronix.de>

Thanks, pushed to mmc-next for 3.10.

- Chris.
-- 
Chris Ball   <cjb at laptop.org>   <http://printf.net/>
One Laptop Per Child


From will.deacon at arm.com  Fri Apr 12 14:13:32 2013
From: will.deacon at arm.com (Will Deacon)
Date: Fri, 12 Apr 2013 19:13:32 +0100
Subject: [PATCH] ARM: KVM: fix unbalanced get_cpu() in access_dcsw
In-Reply-To: <1365786828-548-1-git-send-email-marc.zyngier@arm.com>
References: <1365786828-548-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <20130412181332.GB5075@mudshark.cambridge.arm.com>

On Fri, Apr 12, 2013 at 06:13:48PM +0100, Marc Zyngier wrote:
> In the very unlikely event where a guest would be foolish enough to
> *read* from a write-only cache maintainance register, we end up
> with preemption disabled, due to a misplaced get_cpu().
> 
> Just move the "is_write" test outside of the critical section.
> 
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>

I found it second time around!

  Reported-by: Will Deacon <will.deacon at arm.com>

Will


From cjb at laptop.org  Fri Apr 12 14:19:15 2013
From: cjb at laptop.org (Chris Ball)
Date: Fri, 12 Apr 2013 14:19:15 -0400
Subject: [PATCH v5] mmc: dw_mmc: let device core setup the default pin
 configuration
In-Reply-To: <1365683047-8829-1-git-send-email-thomas.abraham@linaro.org>
 (Thomas Abraham's message of "Thu, 11 Apr 2013 17:54:07 +0530")
References: <1365683047-8829-1-git-send-email-thomas.abraham@linaro.org>
Message-ID: <87y5cnehng.fsf@octavius.laptop.org>

Hi,

On Thu, Apr 11 2013, Thomas Abraham wrote:
> With device core now able to setup the default pin configuration,
> the pin configuration code based on the deprecated Samsung specific
> gpio bindings is removed.
>
> Signed-off-by: Thomas Abraham <thomas.abraham at linaro.org>
> Acked-by: Linus Walleij <linus.walleij at linaro.org>
> Reviewed-by: Doug Anderson <dianders at chromium.org>
> Tested-by: Doug Anderson <dianders at chromium.org>
> Acked-by: Seungwon Jeon <tgih.jun at samsung.com>
> ---
> Changes since v4:
> - Fixed the incorrecr return path after error in enabling vmmc regulator
>   as pointed out by Doug.

Thanks, pushed to mmc-next for 3.10.

- Chris.
-- 
Chris Ball   <cjb at laptop.org>   <http://printf.net/>
One Laptop Per Child


From mturquette at linaro.org  Fri Apr 12 14:19:28 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Fri, 12 Apr 2013 11:19:28 -0700
Subject: [PATCH v8] clk: add si5351 i2c common clock driver
In-Reply-To: <1365709350-8344-1-git-send-email-sebastian.hesselbarth@gmail.com>
References: <1365586810-6752-1-git-send-email-sebastian.hesselbarth@gmail.com>
 <1365709350-8344-1-git-send-email-sebastian.hesselbarth@gmail.com>
Message-ID: <20130412181928.6507.62726@quantum>

Quoting Sebastian Hesselbarth (2013-04-11 12:42:29)
> This patch adds a common clock driver for Silicon Labs Si5351a/b/c
> i2c programmable clock generators. Currently, the driver does not
> support VXCO feature of si5351b. Passing platform_data or DT bindings
> selectively allows to overwrite stored Si5351 configuration which is
> very helpful for clock generators with empty eeprom configuration.
> Corresponding device tree binding documentation is also added.
> 
> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
> Tested-by: Daniel Mack <zonque at gmail.com>
> Acked-by: Guenter Roeck <linux at roeck-us.net>

Made it under the wire!  Thanks for cooking up v8 so quickly.  I've
taken this into clk-next.  It's cool to have a clk driver for a discrete
clock generator device.

Regards,
Mike

> ---
> Changes from v7:
> - readd clk powerup on clkout set_rate (Suggested by Michal Bachraty)
> 
> Changes from v6:
> - make invalid DT data parsing fatal (Suggested by Guenter Roeck)
> - add more variant checks and return errors
> - remove inline from _si5351_* functions
> - remove pll reset/clkout powerdown for gapless tuning
>   (Provided by Michal Backraty)
> 
> Changes from v5:
> - removed __clk_set_flags
> - remove CONFIG_OF dependency
> - introduce si5351_platform_data (non-DT untested)
> - parse DT into si5351_platform_data (tested)
> - minor cleanups
> 
> Changes from v4:
> - move from clk-private.h to clk-provider.h (Reported by Mike Turquette)
> - use __clk_set_flags() helper
> 
> Changes from v3:
> - add silabs prefix to custom DT properties (Reported by Lars-Peter Clausen)
> - use sizeof(*foo) instead of sizeof(struct bar) (Reported by Lars-Peter Clausen)
> - check return value of of_clk_add_provider (Reported by Lars-Peter Clausen)
> - clean up i2c client init (Reported by Lars-Peter Clausen)
> - silence successful probe (Suggested by Lars-Peter Clausen)
> - make CONFIG_CLK_SI5351 depend on CONFIG_OF
> 
> Changes from v2:
> - add curly brackets to if-else-statements (Reported by Daniel Mack)
> - fix div-by-zero for clk6/clk7 (Reported by Daniel Mack)
> - fix parameter address calculation for clk6/clk7
> 
> Changes from v1:
> - remove .is_enabled functions as they read from i2c
>   (Reported by Daniel Mack)
> - add CLK_SET_RATE_PARENT on clkout reparent if clkout uses
>   its own multisync
> 
> Cc: Grant Likely <grant.likely at secretlab.ca>
> Cc: Rob Herring <rob.herring at calxeda.com>
> Cc: Rob Landley <rob at landley.net>
> Cc: Mike Turquette <mturquette at linaro.org>
> Cc: Stephen Warren <swarren at nvidia.com>
> Cc: Thierry Reding <thierry.reding at avionic-design.de>
> Cc: Dom Cobley <popcornmix at gmail.com>
> Cc: Linus Walleij <linus.walleij at linaro.org>
> Cc: Arnd Bergmann <arnd at arndb.de>
> Cc: Andrew Morton <akpm at linux-foundation.org>
> Cc: Pawel Moll <pawel.moll at arm.com>
> Cc: Mark Brown <broonie at opensource.wolfsonmicro.com>
> Cc: Russell King - ARM Linux <linux at arm.linux.org.uk>
> Cc: Rabeeh Khoury <rabeeh at solid-run.com>
> Cc: Daniel Mack <zonque at gmail.com>
> Cc: Jean-Francois Moine <moinejf at free.fr>
> Cc: Lars-Peter Clausen <lars at metafoo.de>
> Cc: Guenter Roeck <linux at roeck-us.net>
> Cc: Michal Bachraty <michal.bachraty at streamunlimited.com>
> Cc: devicetree-discuss at lists.ozlabs.org
> Cc: linux-doc at vger.kernel.org
> Cc: linux-kernel at vger.kernel.org
> Cc: linux-arm-kernel at lists.infradead.org
> ---
>  .../devicetree/bindings/clock/silabs,si5351.txt    |  114 ++
>  .../devicetree/bindings/vendor-prefixes.txt        |    1 +
>  drivers/clk/Kconfig                                |    9 +
>  drivers/clk/Makefile                               |    1 +
>  drivers/clk/clk-si5351.c                           | 1510 ++++++++++++++++++++
>  drivers/clk/clk-si5351.h                           |  155 ++
>  include/linux/platform_data/si5351.h               |  114 ++
>  7 files changed, 1904 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/clock/silabs,si5351.txt
>  create mode 100644 drivers/clk/clk-si5351.c
>  create mode 100644 drivers/clk/clk-si5351.h
>  create mode 100644 include/linux/platform_data/si5351.h
> 
> diff --git a/Documentation/devicetree/bindings/clock/silabs,si5351.txt b/Documentation/devicetree/bindings/clock/silabs,si5351.txt
> new file mode 100644
> index 0000000..cc37465
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/silabs,si5351.txt
> @@ -0,0 +1,114 @@
> +Binding for Silicon Labs Si5351a/b/c programmable i2c clock generator.
> +
> +Reference
> +[1] Si5351A/B/C Data Sheet
> +    http://www.silabs.com/Support%20Documents/TechnicalDocs/Si5351.pdf
> +
> +The Si5351a/b/c are programmable i2c clock generators with upto 8 output
> +clocks. Si5351a also has a reduced pin-count package (MSOP10) where only
> +3 output clocks are accessible. The internal structure of the clock
> +generators can be found in [1].
> +
> +==I2C device node==
> +
> +Required properties:
> +- compatible: shall be one of "silabs,si5351{a,a-msop,b,c}".
> +- reg: i2c device address, shall be 0x60 or 0x61.
> +- #clock-cells: from common clock binding; shall be set to 1.
> +- clocks: from common clock binding; list of parent clock
> +  handles, shall be xtal reference clock or xtal and clkin for
> +  si5351c only.
> +- #address-cells: shall be set to 1.
> +- #size-cells: shall be set to 0.
> +
> +Optional properties:
> +- silabs,pll-source: pair of (number, source) for each pll. Allows
> +  to overwrite clock source of pll A (number=0) or B (number=1).
> +
> +==Child nodes==
> +
> +Each of the clock outputs can be overwritten individually by
> +using a child node to the I2C device node. If a child node for a clock
> +output is not set, the eeprom configuration is not overwritten.
> +
> +Required child node properties:
> +- reg: number of clock output.
> +
> +Optional child node properties:
> +- silabs,clock-source: source clock of the output divider stage N, shall be
> +  0 = multisynth N
> +  1 = multisynth 0 for output clocks 0-3, else multisynth4
> +  2 = xtal
> +  3 = clkin (si5351c only)
> +- silabs,drive-strength: output drive strength in mA, shall be one of {2,4,6,8}.
> +- silabs,multisynth-source: source pll A(0) or B(1) of corresponding multisynth
> +  divider.
> +- silabs,pll-master: boolean, multisynth can change pll frequency.
> +
> +==Example==
> +
> +/* 25MHz reference crystal */
> +ref25: ref25M {
> +       compatible = "fixed-clock";
> +       #clock-cells = <0>;
> +       clock-frequency = <25000000>;
> +};
> +
> +i2c-master-node {
> +
> +       /* Si5351a msop10 i2c clock generator */
> +       si5351a: clock-generator at 60 {
> +               compatible = "silabs,si5351a-msop";
> +               reg = <0x60>;
> +               #address-cells = <1>;
> +               #size-cells = <0>;
> +               #clock-cells = <1>;
> +
> +               /* connect xtal input to 25MHz reference */
> +               clocks = <&ref25>;
> +
> +               /* connect xtal input as source of pll0 and pll1 */
> +               silabs,pll-source = <0 0>, <1 0>;
> +
> +               /*
> +                * overwrite clkout0 configuration with:
> +                * - 8mA output drive strength
> +                * - pll0 as clock source of multisynth0
> +                * - multisynth0 as clock source of output divider
> +                * - multisynth0 can change pll0
> +                * - set initial clock frequency of 74.25MHz
> +                */
> +               clkout0 {
> +                       reg = <0>;
> +                       silabs,drive-strength = <8>;
> +                       silabs,multisynth-source = <0>;
> +                       silabs,clock-source = <0>;
> +                       silabs,pll-master;
> +                       clock-frequency = <74250000>;
> +               };
> +
> +               /*
> +                * overwrite clkout1 configuration with:
> +                * - 4mA output drive strength
> +                * - pll1 as clock source of multisynth1
> +                * - multisynth1 as clock source of output divider
> +                * - multisynth1 can change pll1
> +                */
> +               clkout1 {
> +                       reg = <1>;
> +                       silabs,drive-strength = <4>;
> +                       silabs,multisynth-source = <1>;
> +                       silabs,clock-source = <0>;
> +                       pll-master;
> +               };
> +
> +               /*
> +                * overwrite clkout2 configuration with:
> +                * - xtal as clock source of output divider
> +                */
> +               clkout2 {
> +                       reg = <2>;
> +                       silabs,clock-source = <2>;
> +               };
> +       };
> +};
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
> index 19e1ef7..ca60849 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> @@ -48,6 +48,7 @@ samsung       Samsung Semiconductor
>  sbs    Smart Battery System
>  schindler      Schindler
>  sil    Silicon Image
> +silabs Silicon Laboratories
>  simtek
>  sirf   SiRF Technology, Inc.
>  snps   Synopsys, Inc.
> diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
> index a47e6ee..5039e41 100644
> --- a/drivers/clk/Kconfig
> +++ b/drivers/clk/Kconfig
> @@ -55,6 +55,15 @@ config COMMON_CLK_MAX77686
>         ---help---
>           This driver supports Maxim 77686 crystal oscillator clock. 
>  
> +config COMMON_CLK_SI5351
> +       tristate "Clock driver for SiLabs 5351A/B/C"
> +       depends on I2C
> +       select REGMAP_I2C
> +       select RATIONAL
> +       ---help---
> +         This driver supports Silicon Labs 5351A/B/C programmable clock
> +         generators.
> +
>  config CLK_TWL6040
>         tristate "External McPDM functional clock from twl6040"
>         depends on TWL6040_CORE
> diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
> index 300d477..92ca698 100644
> --- a/drivers/clk/Makefile
> +++ b/drivers/clk/Makefile
> @@ -33,4 +33,5 @@ obj-$(CONFIG_X86)             += x86/
>  # Chip specific
>  obj-$(CONFIG_COMMON_CLK_WM831X) += clk-wm831x.o
>  obj-$(CONFIG_COMMON_CLK_MAX77686) += clk-max77686.o
> +obj-$(CONFIG_COMMON_CLK_SI5351) += clk-si5351.o
>  obj-$(CONFIG_CLK_TWL6040)      += clk-twl6040.o
> diff --git a/drivers/clk/clk-si5351.c b/drivers/clk/clk-si5351.c
> new file mode 100644
> index 0000000..8927284
> --- /dev/null
> +++ b/drivers/clk/clk-si5351.c
> @@ -0,0 +1,1510 @@
> +/*
> + * clk-si5351.c: Silicon Laboratories Si5351A/B/C I2C Clock Generator
> + *
> + * Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
> + * Rabeeh Khoury <rabeeh at solid-run.com>
> + *
> + * References:
> + * [1] "Si5351A/B/C Data Sheet"
> + *     http://www.silabs.com/Support%20Documents/TechnicalDocs/Si5351.pdf
> + * [2] "Manually Generating an Si5351 Register Map"
> + *     http://www.silabs.com/Support%20Documents/TechnicalDocs/AN619.pdf
> + *
> + * 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.
> + */
> +
> +#include <linux/module.h>
> +#include <linux/kernel.h>
> +#include <linux/clkdev.h>
> +#include <linux/clk-provider.h>
> +#include <linux/delay.h>
> +#include <linux/err.h>
> +#include <linux/errno.h>
> +#include <linux/rational.h>
> +#include <linux/i2c.h>
> +#include <linux/of_platform.h>
> +#include <linux/platform_data/si5351.h>
> +#include <linux/regmap.h>
> +#include <linux/slab.h>
> +#include <linux/string.h>
> +#include <asm/div64.h>
> +
> +#include "clk-si5351.h"
> +
> +struct si5351_driver_data;
> +
> +struct si5351_parameters {
> +       unsigned long   p1;
> +       unsigned long   p2;
> +       unsigned long   p3;
> +       int             valid;
> +};
> +
> +struct si5351_hw_data {
> +       struct clk_hw                   hw;
> +       struct si5351_driver_data       *drvdata;
> +       struct si5351_parameters        params;
> +       unsigned char                   num;
> +};
> +
> +struct si5351_driver_data {
> +       enum si5351_variant     variant;
> +       struct i2c_client       *client;
> +       struct regmap           *regmap;
> +       struct clk_onecell_data onecell;
> +
> +       struct clk              *pxtal;
> +       const char              *pxtal_name;
> +       struct clk_hw           xtal;
> +       struct clk              *pclkin;
> +       const char              *pclkin_name;
> +       struct clk_hw           clkin;
> +
> +       struct si5351_hw_data   pll[2];
> +       struct si5351_hw_data   *msynth;
> +       struct si5351_hw_data   *clkout;
> +};
> +
> +static const char const *si5351_input_names[] = {
> +       "xtal", "clkin"
> +};
> +static const char const *si5351_pll_names[] = {
> +       "plla", "pllb", "vxco"
> +};
> +static const char const *si5351_msynth_names[] = {
> +       "ms0", "ms1", "ms2", "ms3", "ms4", "ms5", "ms6", "ms7"
> +};
> +static const char const *si5351_clkout_names[] = {
> +       "clk0", "clk1", "clk2", "clk3", "clk4", "clk5", "clk6", "clk7"
> +};
> +
> +/*
> + * Si5351 i2c regmap
> + */
> +static inline u8 si5351_reg_read(struct si5351_driver_data *drvdata, u8 reg)
> +{
> +       u32 val;
> +       int ret;
> +
> +       ret = regmap_read(drvdata->regmap, reg, &val);
> +       if (ret) {
> +               dev_err(&drvdata->client->dev,
> +                       "unable to read from reg%02x\n", reg);
> +               return 0;
> +       }
> +
> +       return (u8)val;
> +}
> +
> +static inline int si5351_bulk_read(struct si5351_driver_data *drvdata,
> +                                  u8 reg, u8 count, u8 *buf)
> +{
> +       return regmap_bulk_read(drvdata->regmap, reg, buf, count);
> +}
> +
> +static inline int si5351_reg_write(struct si5351_driver_data *drvdata,
> +                                  u8 reg, u8 val)
> +{
> +       return regmap_write(drvdata->regmap, reg, val);
> +}
> +
> +static inline int si5351_bulk_write(struct si5351_driver_data *drvdata,
> +                                   u8 reg, u8 count, const u8 *buf)
> +{
> +       return regmap_raw_write(drvdata->regmap, reg, buf, count);
> +}
> +
> +static inline int si5351_set_bits(struct si5351_driver_data *drvdata,
> +                                 u8 reg, u8 mask, u8 val)
> +{
> +       return regmap_update_bits(drvdata->regmap, reg, mask, val);
> +}
> +
> +static inline u8 si5351_msynth_params_address(int num)
> +{
> +       if (num > 5)
> +               return SI5351_CLK6_PARAMETERS + (num - 6);
> +       return SI5351_CLK0_PARAMETERS + (SI5351_PARAMETERS_LENGTH * num);
> +}
> +
> +static void si5351_read_parameters(struct si5351_driver_data *drvdata,
> +                                  u8 reg, struct si5351_parameters *params)
> +{
> +       u8 buf[SI5351_PARAMETERS_LENGTH];
> +
> +       switch (reg) {
> +       case SI5351_CLK6_PARAMETERS:
> +       case SI5351_CLK7_PARAMETERS:
> +               buf[0] = si5351_reg_read(drvdata, reg);
> +               params->p1 = buf[0];
> +               params->p2 = 0;
> +               params->p3 = 1;
> +               break;
> +       default:
> +               si5351_bulk_read(drvdata, reg, SI5351_PARAMETERS_LENGTH, buf);
> +               params->p1 = ((buf[2] & 0x03) << 16) | (buf[3] << 8) | buf[4];
> +               params->p2 = ((buf[5] & 0x0f) << 16) | (buf[6] << 8) | buf[7];
> +               params->p3 = ((buf[5] & 0xf0) << 12) | (buf[0] << 8) | buf[1];
> +       }
> +       params->valid = 1;
> +}
> +
> +static void si5351_write_parameters(struct si5351_driver_data *drvdata,
> +                                   u8 reg, struct si5351_parameters *params)
> +{
> +       u8 buf[SI5351_PARAMETERS_LENGTH];
> +
> +       switch (reg) {
> +       case SI5351_CLK6_PARAMETERS:
> +       case SI5351_CLK7_PARAMETERS:
> +               buf[0] = params->p1 & 0xff;
> +               si5351_reg_write(drvdata, reg, buf[0]);
> +               break;
> +       default:
> +               buf[0] = ((params->p3 & 0x0ff00) >> 8) & 0xff;
> +               buf[1] = params->p3 & 0xff;
> +               /* save rdiv and divby4 */
> +               buf[2] = si5351_reg_read(drvdata, reg + 2) & ~0x03;
> +               buf[2] |= ((params->p1 & 0x30000) >> 16) & 0x03;
> +               buf[3] = ((params->p1 & 0x0ff00) >> 8) & 0xff;
> +               buf[4] = params->p1 & 0xff;
> +               buf[5] = ((params->p3 & 0xf0000) >> 12) |
> +                       ((params->p2 & 0xf0000) >> 16);
> +               buf[6] = ((params->p2 & 0x0ff00) >> 8) & 0xff;
> +               buf[7] = params->p2 & 0xff;
> +               si5351_bulk_write(drvdata, reg, SI5351_PARAMETERS_LENGTH, buf);
> +       }
> +}
> +
> +static bool si5351_regmap_is_volatile(struct device *dev, unsigned int reg)
> +{
> +       switch (reg) {
> +       case SI5351_DEVICE_STATUS:
> +       case SI5351_INTERRUPT_STATUS:
> +       case SI5351_PLL_RESET:
> +               return true;
> +       }
> +       return false;
> +}
> +
> +static bool si5351_regmap_is_writeable(struct device *dev, unsigned int reg)
> +{
> +       /* reserved registers */
> +       if (reg >= 4 && reg <= 8)
> +               return false;
> +       if (reg >= 10 && reg <= 14)
> +               return false;
> +       if (reg >= 173 && reg <= 176)
> +               return false;
> +       if (reg >= 178 && reg <= 182)
> +               return false;
> +       /* read-only */
> +       if (reg == SI5351_DEVICE_STATUS)
> +               return false;
> +       return true;
> +}
> +
> +static struct regmap_config si5351_regmap_config = {
> +       .reg_bits = 8,
> +       .val_bits = 8,
> +       .cache_type = REGCACHE_RBTREE,
> +       .max_register = 187,
> +       .writeable_reg = si5351_regmap_is_writeable,
> +       .volatile_reg = si5351_regmap_is_volatile,
> +};
> +
> +/*
> + * Si5351 xtal clock input
> + */
> +static int si5351_xtal_prepare(struct clk_hw *hw)
> +{
> +       struct si5351_driver_data *drvdata =
> +               container_of(hw, struct si5351_driver_data, xtal);
> +       si5351_set_bits(drvdata, SI5351_FANOUT_ENABLE,
> +                       SI5351_XTAL_ENABLE, SI5351_XTAL_ENABLE);
> +       return 0;
> +}
> +
> +static void si5351_xtal_unprepare(struct clk_hw *hw)
> +{
> +       struct si5351_driver_data *drvdata =
> +               container_of(hw, struct si5351_driver_data, xtal);
> +       si5351_set_bits(drvdata, SI5351_FANOUT_ENABLE,
> +                       SI5351_XTAL_ENABLE, 0);
> +}
> +
> +static const struct clk_ops si5351_xtal_ops = {
> +       .prepare = si5351_xtal_prepare,
> +       .unprepare = si5351_xtal_unprepare,
> +};
> +
> +/*
> + * Si5351 clkin clock input (Si5351C only)
> + */
> +static int si5351_clkin_prepare(struct clk_hw *hw)
> +{
> +       struct si5351_driver_data *drvdata =
> +               container_of(hw, struct si5351_driver_data, clkin);
> +       si5351_set_bits(drvdata, SI5351_FANOUT_ENABLE,
> +                       SI5351_CLKIN_ENABLE, SI5351_CLKIN_ENABLE);
> +       return 0;
> +}
> +
> +static void si5351_clkin_unprepare(struct clk_hw *hw)
> +{
> +       struct si5351_driver_data *drvdata =
> +               container_of(hw, struct si5351_driver_data, clkin);
> +       si5351_set_bits(drvdata, SI5351_FANOUT_ENABLE,
> +                       SI5351_CLKIN_ENABLE, 0);
> +}
> +
> +/*
> + * CMOS clock source constraints:
> + * The input frequency range of the PLL is 10Mhz to 40MHz.
> + * If CLKIN is >40MHz, the input divider must be used.
> + */
> +static unsigned long si5351_clkin_recalc_rate(struct clk_hw *hw,
> +                                             unsigned long parent_rate)
> +{
> +       struct si5351_driver_data *drvdata =
> +               container_of(hw, struct si5351_driver_data, clkin);
> +       unsigned long rate;
> +       unsigned char idiv;
> +
> +       rate = parent_rate;
> +       if (parent_rate > 160000000) {
> +               idiv = SI5351_CLKIN_DIV_8;
> +               rate /= 8;
> +       } else if (parent_rate > 80000000) {
> +               idiv = SI5351_CLKIN_DIV_4;
> +               rate /= 4;
> +       } else if (parent_rate > 40000000) {
> +               idiv = SI5351_CLKIN_DIV_2;
> +               rate /= 2;
> +       } else {
> +               idiv = SI5351_CLKIN_DIV_1;
> +       }
> +
> +       si5351_set_bits(drvdata, SI5351_PLL_INPUT_SOURCE,
> +                       SI5351_CLKIN_DIV_MASK, idiv);
> +
> +       dev_dbg(&drvdata->client->dev, "%s - clkin div = %d, rate = %lu\n",
> +               __func__, (1 << (idiv >> 6)), rate);
> +
> +       return rate;
> +}
> +
> +static const struct clk_ops si5351_clkin_ops = {
> +       .prepare = si5351_clkin_prepare,
> +       .unprepare = si5351_clkin_unprepare,
> +       .recalc_rate = si5351_clkin_recalc_rate,
> +};
> +
> +/*
> + * Si5351 vxco clock input (Si5351B only)
> + */
> +
> +static int si5351_vxco_prepare(struct clk_hw *hw)
> +{
> +       struct si5351_hw_data *hwdata =
> +               container_of(hw, struct si5351_hw_data, hw);
> +
> +       dev_warn(&hwdata->drvdata->client->dev, "VXCO currently unsupported\n");
> +
> +       return 0;
> +}
> +
> +static void si5351_vxco_unprepare(struct clk_hw *hw)
> +{
> +}
> +
> +static unsigned long si5351_vxco_recalc_rate(struct clk_hw *hw,
> +                                            unsigned long parent_rate)
> +{
> +       return 0;
> +}
> +
> +static int si5351_vxco_set_rate(struct clk_hw *hw, unsigned long rate,
> +                               unsigned long parent)
> +{
> +       return 0;
> +}
> +
> +static const struct clk_ops si5351_vxco_ops = {
> +       .prepare = si5351_vxco_prepare,
> +       .unprepare = si5351_vxco_unprepare,
> +       .recalc_rate = si5351_vxco_recalc_rate,
> +       .set_rate = si5351_vxco_set_rate,
> +};
> +
> +/*
> + * Si5351 pll a/b
> + *
> + * Feedback Multisynth Divider Equations [2]
> + *
> + * fVCO = fIN * (a + b/c)
> + *
> + * with 15 + 0/1048575 <= (a + b/c) <= 90 + 0/1048575 and
> + * fIN = fXTAL or fIN = fCLKIN/CLKIN_DIV
> + *
> + * Feedback Multisynth Register Equations
> + *
> + * (1) MSNx_P1[17:0] = 128 * a + floor(128 * b/c) - 512
> + * (2) MSNx_P2[19:0] = 128 * b - c * floor(128 * b/c) = (128*b) mod c
> + * (3) MSNx_P3[19:0] = c
> + *
> + * Transposing (2) yields: (4) floor(128 * b/c) = (128 * b / MSNx_P2)/c
> + *
> + * Using (4) on (1) yields:
> + * MSNx_P1 = 128 * a + (128 * b/MSNx_P2)/c - 512
> + * MSNx_P1 + 512 + MSNx_P2/c = 128 * a + 128 * b/c
> + *
> + * a + b/c = (MSNx_P1 + MSNx_P2/MSNx_P3 + 512)/128
> + *         = (MSNx_P1*MSNx_P3 + MSNx_P2 + 512*MSNx_P3)/(128*MSNx_P3)
> + *
> + */
> +static int _si5351_pll_reparent(struct si5351_driver_data *drvdata,
> +                               int num, enum si5351_pll_src parent)
> +{
> +       u8 mask = (num == 0) ? SI5351_PLLA_SOURCE : SI5351_PLLB_SOURCE;
> +
> +       if (parent == SI5351_PLL_SRC_DEFAULT)
> +               return 0;
> +
> +       if (num > 2)
> +               return -EINVAL;
> +
> +       if (drvdata->variant != SI5351_VARIANT_C &&
> +           parent != SI5351_PLL_SRC_XTAL)
> +               return -EINVAL;
> +
> +       si5351_set_bits(drvdata, SI5351_PLL_INPUT_SOURCE, mask,
> +                       (parent == SI5351_PLL_SRC_XTAL) ? 0 : mask);
> +       return 0;
> +}
> +
> +static unsigned char si5351_pll_get_parent(struct clk_hw *hw)
> +{
> +       struct si5351_hw_data *hwdata =
> +               container_of(hw, struct si5351_hw_data, hw);
> +       u8 mask = (hwdata->num == 0) ? SI5351_PLLA_SOURCE : SI5351_PLLB_SOURCE;
> +       u8 val;
> +
> +       val = si5351_reg_read(hwdata->drvdata, SI5351_PLL_INPUT_SOURCE);
> +
> +       return (val & mask) ? 1 : 0;
> +}
> +
> +static int si5351_pll_set_parent(struct clk_hw *hw, u8 index)
> +{
> +       struct si5351_hw_data *hwdata =
> +               container_of(hw, struct si5351_hw_data, hw);
> +
> +       if (hwdata->drvdata->variant != SI5351_VARIANT_C &&
> +           index > 0)
> +               return -EPERM;
> +
> +       if (index > 1)
> +               return -EINVAL;
> +
> +       return _si5351_pll_reparent(hwdata->drvdata, hwdata->num,
> +                            (index == 0) ? SI5351_PLL_SRC_XTAL :
> +                            SI5351_PLL_SRC_CLKIN);
> +}
> +
> +static unsigned long si5351_pll_recalc_rate(struct clk_hw *hw,
> +                                           unsigned long parent_rate)
> +{
> +       struct si5351_hw_data *hwdata =
> +               container_of(hw, struct si5351_hw_data, hw);
> +       u8 reg = (hwdata->num == 0) ? SI5351_PLLA_PARAMETERS :
> +               SI5351_PLLB_PARAMETERS;
> +       unsigned long long rate;
> +
> +       if (!hwdata->params.valid)
> +               si5351_read_parameters(hwdata->drvdata, reg, &hwdata->params);
> +
> +       if (hwdata->params.p3 == 0)
> +               return parent_rate;
> +
> +       /* fVCO = fIN * (P1*P3 + 512*P3 + P2)/(128*P3) */
> +       rate  = hwdata->params.p1 * hwdata->params.p3;
> +       rate += 512 * hwdata->params.p3;
> +       rate += hwdata->params.p2;
> +       rate *= parent_rate;
> +       do_div(rate, 128 * hwdata->params.p3);
> +
> +       dev_dbg(&hwdata->drvdata->client->dev,
> +               "%s - %s: p1 = %lu, p2 = %lu, p3 = %lu, parent_rate = %lu, rate = %lu\n",
> +               __func__, __clk_get_name(hwdata->hw.clk),
> +               hwdata->params.p1, hwdata->params.p2, hwdata->params.p3,
> +               parent_rate, (unsigned long)rate);
> +
> +       return (unsigned long)rate;
> +}
> +
> +static long si5351_pll_round_rate(struct clk_hw *hw, unsigned long rate,
> +                                 unsigned long *parent_rate)
> +{
> +       struct si5351_hw_data *hwdata =
> +               container_of(hw, struct si5351_hw_data, hw);
> +       unsigned long rfrac, denom, a, b, c;
> +       unsigned long long lltmp;
> +
> +       if (rate < SI5351_PLL_VCO_MIN)
> +               rate = SI5351_PLL_VCO_MIN;
> +       if (rate > SI5351_PLL_VCO_MAX)
> +               rate = SI5351_PLL_VCO_MAX;
> +
> +       /* determine integer part of feedback equation */
> +       a = rate / *parent_rate;
> +
> +       if (a < SI5351_PLL_A_MIN)
> +               rate = *parent_rate * SI5351_PLL_A_MIN;
> +       if (a > SI5351_PLL_A_MAX)
> +               rate = *parent_rate * SI5351_PLL_A_MAX;
> +
> +       /* find best approximation for b/c = fVCO mod fIN */
> +       denom = 1000 * 1000;
> +       lltmp = rate % (*parent_rate);
> +       lltmp *= denom;
> +       do_div(lltmp, *parent_rate);
> +       rfrac = (unsigned long)lltmp;
> +
> +       b = 0;
> +       c = 1;
> +       if (rfrac)
> +               rational_best_approximation(rfrac, denom,
> +                                   SI5351_PLL_B_MAX, SI5351_PLL_C_MAX, &b, &c);
> +
> +       /* calculate parameters */
> +       hwdata->params.p3  = c;
> +       hwdata->params.p2  = (128 * b) % c;
> +       hwdata->params.p1  = 128 * a;
> +       hwdata->params.p1 += (128 * b / c);
> +       hwdata->params.p1 -= 512;
> +
> +       /* recalculate rate by fIN * (a + b/c) */
> +       lltmp  = *parent_rate;
> +       lltmp *= b;
> +       do_div(lltmp, c);
> +
> +       rate  = (unsigned long)lltmp;
> +       rate += *parent_rate * a;
> +
> +       dev_dbg(&hwdata->drvdata->client->dev,
> +               "%s - %s: a = %lu, b = %lu, c = %lu, parent_rate = %lu, rate = %lu\n",
> +               __func__, __clk_get_name(hwdata->hw.clk), a, b, c,
> +               *parent_rate, rate);
> +
> +       return rate;
> +}
> +
> +static int si5351_pll_set_rate(struct clk_hw *hw, unsigned long rate,
> +                              unsigned long parent_rate)
> +{
> +       struct si5351_hw_data *hwdata =
> +               container_of(hw, struct si5351_hw_data, hw);
> +       u8 reg = (hwdata->num == 0) ? SI5351_PLLA_PARAMETERS :
> +               SI5351_PLLB_PARAMETERS;
> +
> +       /* write multisynth parameters */
> +       si5351_write_parameters(hwdata->drvdata, reg, &hwdata->params);
> +
> +       /* plla/pllb ctrl is in clk6/clk7 ctrl registers */
> +       si5351_set_bits(hwdata->drvdata, SI5351_CLK6_CTRL + hwdata->num,
> +               SI5351_CLK_INTEGER_MODE,
> +               (hwdata->params.p2 == 0) ? SI5351_CLK_INTEGER_MODE : 0);
> +
> +       dev_dbg(&hwdata->drvdata->client->dev,
> +               "%s - %s: p1 = %lu, p2 = %lu, p3 = %lu, parent_rate = %lu, rate = %lu\n",
> +               __func__, __clk_get_name(hwdata->hw.clk),
> +               hwdata->params.p1, hwdata->params.p2, hwdata->params.p3,
> +               parent_rate, rate);
> +
> +       return 0;
> +}
> +
> +static const struct clk_ops si5351_pll_ops = {
> +       .set_parent = si5351_pll_set_parent,
> +       .get_parent = si5351_pll_get_parent,
> +       .recalc_rate = si5351_pll_recalc_rate,
> +       .round_rate = si5351_pll_round_rate,
> +       .set_rate = si5351_pll_set_rate,
> +};
> +
> +/*
> + * Si5351 multisync divider
> + *
> + * for fOUT <= 150 MHz:
> + *
> + * fOUT = (fIN * (a + b/c)) / CLKOUTDIV
> + *
> + * with 6 + 0/1048575 <= (a + b/c) <= 1800 + 0/1048575 and
> + * fIN = fVCO0, fVCO1
> + *
> + * Output Clock Multisynth Register Equations
> + *
> + * MSx_P1[17:0] = 128 * a + floor(128 * b/c) - 512
> + * MSx_P2[19:0] = 128 * b - c * floor(128 * b/c) = (128*b) mod c
> + * MSx_P3[19:0] = c
> + *
> + * MS[6,7] are integer (P1) divide only, P2 = 0, P3 = 0
> + *
> + * for 150MHz < fOUT <= 160MHz:
> + *
> + * MSx_P1 = 0, MSx_P2 = 0, MSx_P3 = 1, MSx_INT = 1, MSx_DIVBY4 = 11b
> + */
> +static int _si5351_msynth_reparent(struct si5351_driver_data *drvdata,
> +                                  int num, enum si5351_multisynth_src parent)
> +{
> +       if (parent == SI5351_MULTISYNTH_SRC_DEFAULT)
> +               return 0;
> +
> +       if (num > 8)
> +               return -EINVAL;
> +
> +       si5351_set_bits(drvdata, SI5351_CLK0_CTRL + num, SI5351_CLK_PLL_SELECT,
> +                       (parent == SI5351_MULTISYNTH_SRC_VCO0) ? 0 :
> +                       SI5351_CLK_PLL_SELECT);
> +       return 0;
> +}
> +
> +static unsigned char si5351_msynth_get_parent(struct clk_hw *hw)
> +{
> +       struct si5351_hw_data *hwdata =
> +               container_of(hw, struct si5351_hw_data, hw);
> +       u8 val;
> +
> +       val = si5351_reg_read(hwdata->drvdata, SI5351_CLK0_CTRL + hwdata->num);
> +
> +       return (val & SI5351_CLK_PLL_SELECT) ? 1 : 0;
> +}
> +
> +static int si5351_msynth_set_parent(struct clk_hw *hw, u8 index)
> +{
> +       struct si5351_hw_data *hwdata =
> +               container_of(hw, struct si5351_hw_data, hw);
> +
> +       return _si5351_msynth_reparent(hwdata->drvdata, hwdata->num,
> +                              (index == 0) ? SI5351_MULTISYNTH_SRC_VCO0 :
> +                              SI5351_MULTISYNTH_SRC_VCO1);
> +}
> +
> +static unsigned long si5351_msynth_recalc_rate(struct clk_hw *hw,
> +                                              unsigned long parent_rate)
> +{
> +       struct si5351_hw_data *hwdata =
> +               container_of(hw, struct si5351_hw_data, hw);
> +       u8 reg = si5351_msynth_params_address(hwdata->num);
> +       unsigned long long rate;
> +       unsigned long m;
> +
> +       if (!hwdata->params.valid)
> +               si5351_read_parameters(hwdata->drvdata, reg, &hwdata->params);
> +
> +       if (hwdata->params.p3 == 0)
> +               return parent_rate;
> +
> +       /*
> +        * multisync0-5: fOUT = (128 * P3 * fIN) / (P1*P3 + P2 + 512*P3)
> +        * multisync6-7: fOUT = fIN / P1
> +        */
> +       rate = parent_rate;
> +       if (hwdata->num > 5) {
> +               m = hwdata->params.p1;
> +       } else if ((si5351_reg_read(hwdata->drvdata, reg + 2) &
> +                   SI5351_OUTPUT_CLK_DIVBY4) == SI5351_OUTPUT_CLK_DIVBY4) {
> +               m = 4;
> +       } else {
> +               rate *= 128 * hwdata->params.p3;
> +               m = hwdata->params.p1 * hwdata->params.p3;
> +               m += hwdata->params.p2;
> +               m += 512 * hwdata->params.p3;
> +       }
> +
> +       if (m == 0)
> +               return 0;
> +       do_div(rate, m);
> +
> +       dev_dbg(&hwdata->drvdata->client->dev,
> +               "%s - %s: p1 = %lu, p2 = %lu, p3 = %lu, m = %lu, parent_rate = %lu, rate = %lu\n",
> +               __func__, __clk_get_name(hwdata->hw.clk),
> +               hwdata->params.p1, hwdata->params.p2, hwdata->params.p3,
> +               m, parent_rate, (unsigned long)rate);
> +
> +       return (unsigned long)rate;
> +}
> +
> +static long si5351_msynth_round_rate(struct clk_hw *hw, unsigned long rate,
> +                                    unsigned long *parent_rate)
> +{
> +       struct si5351_hw_data *hwdata =
> +               container_of(hw, struct si5351_hw_data, hw);
> +       unsigned long long lltmp;
> +       unsigned long a, b, c;
> +       int divby4;
> +
> +       /* multisync6-7 can only handle freqencies < 150MHz */
> +       if (hwdata->num >= 6 && rate > SI5351_MULTISYNTH67_MAX_FREQ)
> +               rate = SI5351_MULTISYNTH67_MAX_FREQ;
> +
> +       /* multisync frequency is 1MHz .. 160MHz */
> +       if (rate > SI5351_MULTISYNTH_MAX_FREQ)
> +               rate = SI5351_MULTISYNTH_MAX_FREQ;
> +       if (rate < SI5351_MULTISYNTH_MIN_FREQ)
> +               rate = SI5351_MULTISYNTH_MIN_FREQ;
> +
> +       divby4 = 0;
> +       if (rate > SI5351_MULTISYNTH_DIVBY4_FREQ)
> +               divby4 = 1;
> +
> +       /* multisync can set pll */
> +       if (__clk_get_flags(hwdata->hw.clk) & CLK_SET_RATE_PARENT) {
> +               /*
> +                * find largest integer divider for max
> +                * vco frequency and given target rate
> +                */
> +               if (divby4 == 0) {
> +                       lltmp = SI5351_PLL_VCO_MAX;
> +                       do_div(lltmp, rate);
> +                       a = (unsigned long)lltmp;
> +               } else
> +                       a = 4;
> +
> +               b = 0;
> +               c = 1;
> +
> +               *parent_rate = a * rate;
> +       } else {
> +               unsigned long rfrac, denom;
> +
> +               /* disable divby4 */
> +               if (divby4) {
> +                       rate = SI5351_MULTISYNTH_DIVBY4_FREQ;
> +                       divby4 = 0;
> +               }
> +
> +               /* determine integer part of divider equation */
> +               a = *parent_rate / rate;
> +               if (a < SI5351_MULTISYNTH_A_MIN)
> +                       a = SI5351_MULTISYNTH_A_MIN;
> +               if (hwdata->num >= 6 && a > SI5351_MULTISYNTH67_A_MAX)
> +                       a = SI5351_MULTISYNTH67_A_MAX;
> +               else if (a > SI5351_MULTISYNTH_A_MAX)
> +                       a = SI5351_MULTISYNTH_A_MAX;
> +
> +               /* find best approximation for b/c = fVCO mod fOUT */
> +               denom = 1000 * 1000;
> +               lltmp = (*parent_rate) % rate;
> +               lltmp *= denom;
> +               do_div(lltmp, rate);
> +               rfrac = (unsigned long)lltmp;
> +
> +               b = 0;
> +               c = 1;
> +               if (rfrac)
> +                       rational_best_approximation(rfrac, denom,
> +                           SI5351_MULTISYNTH_B_MAX, SI5351_MULTISYNTH_C_MAX,
> +                           &b, &c);
> +       }
> +
> +       /* recalculate rate by fOUT = fIN / (a + b/c) */
> +       lltmp  = *parent_rate;
> +       lltmp *= c;
> +       do_div(lltmp, a * c + b);
> +       rate  = (unsigned long)lltmp;
> +
> +       /* calculate parameters */
> +       if (divby4) {
> +               hwdata->params.p3 = 1;
> +               hwdata->params.p2 = 0;
> +               hwdata->params.p1 = 0;
> +       } else {
> +               hwdata->params.p3  = c;
> +               hwdata->params.p2  = (128 * b) % c;
> +               hwdata->params.p1  = 128 * a;
> +               hwdata->params.p1 += (128 * b / c);
> +               hwdata->params.p1 -= 512;
> +       }
> +
> +       dev_dbg(&hwdata->drvdata->client->dev,
> +               "%s - %s: a = %lu, b = %lu, c = %lu, divby4 = %d, parent_rate = %lu, rate = %lu\n",
> +               __func__, __clk_get_name(hwdata->hw.clk), a, b, c, divby4,
> +               *parent_rate, rate);
> +
> +       return rate;
> +}
> +
> +static int si5351_msynth_set_rate(struct clk_hw *hw, unsigned long rate,
> +                                 unsigned long parent_rate)
> +{
> +       struct si5351_hw_data *hwdata =
> +               container_of(hw, struct si5351_hw_data, hw);
> +       u8 reg = si5351_msynth_params_address(hwdata->num);
> +       int divby4 = 0;
> +
> +       /* write multisynth parameters */
> +       si5351_write_parameters(hwdata->drvdata, reg, &hwdata->params);
> +
> +       if (rate > SI5351_MULTISYNTH_DIVBY4_FREQ)
> +               divby4 = 1;
> +
> +       /* enable/disable integer mode and divby4 on multisynth0-5 */
> +       if (hwdata->num < 6) {
> +               si5351_set_bits(hwdata->drvdata, reg + 2,
> +                               SI5351_OUTPUT_CLK_DIVBY4,
> +                               (divby4) ? SI5351_OUTPUT_CLK_DIVBY4 : 0);
> +               si5351_set_bits(hwdata->drvdata, SI5351_CLK0_CTRL + hwdata->num,
> +                       SI5351_CLK_INTEGER_MODE,
> +                       (hwdata->params.p2 == 0) ? SI5351_CLK_INTEGER_MODE : 0);
> +       }
> +
> +       dev_dbg(&hwdata->drvdata->client->dev,
> +               "%s - %s: p1 = %lu, p2 = %lu, p3 = %lu, divby4 = %d, parent_rate = %lu, rate = %lu\n",
> +               __func__, __clk_get_name(hwdata->hw.clk),
> +               hwdata->params.p1, hwdata->params.p2, hwdata->params.p3,
> +               divby4, parent_rate, rate);
> +
> +       return 0;
> +}
> +
> +static const struct clk_ops si5351_msynth_ops = {
> +       .set_parent = si5351_msynth_set_parent,
> +       .get_parent = si5351_msynth_get_parent,
> +       .recalc_rate = si5351_msynth_recalc_rate,
> +       .round_rate = si5351_msynth_round_rate,
> +       .set_rate = si5351_msynth_set_rate,
> +};
> +
> +/*
> + * Si5351 clkout divider
> + */
> +static int _si5351_clkout_reparent(struct si5351_driver_data *drvdata,
> +                                  int num, enum si5351_clkout_src parent)
> +{
> +       u8 val;
> +
> +       if (num > 8)
> +               return -EINVAL;
> +
> +       switch (parent) {
> +       case SI5351_CLKOUT_SRC_MSYNTH_N:
> +               val = SI5351_CLK_INPUT_MULTISYNTH_N;
> +               break;
> +       case SI5351_CLKOUT_SRC_MSYNTH_0_4:
> +               /* clk0/clk4 can only connect to its own multisync */
> +               if (num == 0 || num == 4)
> +                       val = SI5351_CLK_INPUT_MULTISYNTH_N;
> +               else
> +                       val = SI5351_CLK_INPUT_MULTISYNTH_0_4;
> +               break;
> +       case SI5351_CLKOUT_SRC_XTAL:
> +               val = SI5351_CLK_INPUT_XTAL;
> +               break;
> +       case SI5351_CLKOUT_SRC_CLKIN:
> +               if (drvdata->variant != SI5351_VARIANT_C)
> +                       return -EINVAL;
> +
> +               val = SI5351_CLK_INPUT_CLKIN;
> +               break;
> +       default:
> +               return 0;
> +       }
> +
> +       si5351_set_bits(drvdata, SI5351_CLK0_CTRL + num,
> +                       SI5351_CLK_INPUT_MASK, val);
> +       return 0;
> +}
> +
> +static int _si5351_clkout_set_drive_strength(
> +       struct si5351_driver_data *drvdata, int num,
> +       enum si5351_drive_strength drive)
> +{
> +       u8 mask;
> +
> +       if (num > 8)
> +               return -EINVAL;
> +
> +       switch (drive) {
> +       case SI5351_DRIVE_2MA:
> +               mask = SI5351_CLK_DRIVE_STRENGTH_2MA;
> +               break;
> +       case SI5351_DRIVE_4MA:
> +               mask = SI5351_CLK_DRIVE_STRENGTH_4MA;
> +               break;
> +       case SI5351_DRIVE_6MA:
> +               mask = SI5351_CLK_DRIVE_STRENGTH_6MA;
> +               break;
> +       case SI5351_DRIVE_8MA:
> +               mask = SI5351_CLK_DRIVE_STRENGTH_8MA;
> +               break;
> +       default:
> +               return 0;
> +       }
> +
> +       si5351_set_bits(drvdata, SI5351_CLK0_CTRL + num,
> +                       SI5351_CLK_DRIVE_STRENGTH_MASK, mask);
> +       return 0;
> +}
> +
> +static int si5351_clkout_prepare(struct clk_hw *hw)
> +{
> +       struct si5351_hw_data *hwdata =
> +               container_of(hw, struct si5351_hw_data, hw);
> +
> +       si5351_set_bits(hwdata->drvdata, SI5351_CLK0_CTRL + hwdata->num,
> +                       SI5351_CLK_POWERDOWN, 0);
> +       si5351_set_bits(hwdata->drvdata, SI5351_OUTPUT_ENABLE_CTRL,
> +                       (1 << hwdata->num), 0);
> +       return 0;
> +}
> +
> +static void si5351_clkout_unprepare(struct clk_hw *hw)
> +{
> +       struct si5351_hw_data *hwdata =
> +               container_of(hw, struct si5351_hw_data, hw);
> +
> +       si5351_set_bits(hwdata->drvdata, SI5351_CLK0_CTRL + hwdata->num,
> +                       SI5351_CLK_POWERDOWN, SI5351_CLK_POWERDOWN);
> +       si5351_set_bits(hwdata->drvdata, SI5351_OUTPUT_ENABLE_CTRL,
> +                       (1 << hwdata->num), (1 << hwdata->num));
> +}
> +
> +static u8 si5351_clkout_get_parent(struct clk_hw *hw)
> +{
> +       struct si5351_hw_data *hwdata =
> +               container_of(hw, struct si5351_hw_data, hw);
> +       int index = 0;
> +       unsigned char val;
> +
> +       val = si5351_reg_read(hwdata->drvdata, SI5351_CLK0_CTRL + hwdata->num);
> +       switch (val & SI5351_CLK_INPUT_MASK) {
> +       case SI5351_CLK_INPUT_MULTISYNTH_N:
> +               index = 0;
> +               break;
> +       case SI5351_CLK_INPUT_MULTISYNTH_0_4:
> +               index = 1;
> +               break;
> +       case SI5351_CLK_INPUT_XTAL:
> +               index = 2;
> +               break;
> +       case SI5351_CLK_INPUT_CLKIN:
> +               index = 3;
> +               break;
> +       }
> +
> +       return index;
> +}
> +
> +static int si5351_clkout_set_parent(struct clk_hw *hw, u8 index)
> +{
> +       struct si5351_hw_data *hwdata =
> +               container_of(hw, struct si5351_hw_data, hw);
> +       enum si5351_clkout_src parent = SI5351_CLKOUT_SRC_DEFAULT;
> +
> +       switch (index) {
> +       case 0:
> +               parent = SI5351_CLKOUT_SRC_MSYNTH_N;
> +               break;
> +       case 1:
> +               parent = SI5351_CLKOUT_SRC_MSYNTH_0_4;
> +               break;
> +       case 2:
> +               parent = SI5351_CLKOUT_SRC_XTAL;
> +               break;
> +       case 3:
> +               parent = SI5351_CLKOUT_SRC_CLKIN;
> +               break;
> +       }
> +
> +       return _si5351_clkout_reparent(hwdata->drvdata, hwdata->num, parent);
> +}
> +
> +static unsigned long si5351_clkout_recalc_rate(struct clk_hw *hw,
> +                                              unsigned long parent_rate)
> +{
> +       struct si5351_hw_data *hwdata =
> +               container_of(hw, struct si5351_hw_data, hw);
> +       unsigned char reg;
> +       unsigned char rdiv;
> +
> +       if (hwdata->num > 5)
> +               reg = si5351_msynth_params_address(hwdata->num) + 2;
> +       else
> +               reg = SI5351_CLK6_7_OUTPUT_DIVIDER;
> +
> +       rdiv = si5351_reg_read(hwdata->drvdata, reg);
> +       if (hwdata->num == 6) {
> +               rdiv &= SI5351_OUTPUT_CLK6_DIV_MASK;
> +       } else {
> +               rdiv &= SI5351_OUTPUT_CLK_DIV_MASK;
> +               rdiv >>= SI5351_OUTPUT_CLK_DIV_SHIFT;
> +       }
> +
> +       return parent_rate >> rdiv;
> +}
> +
> +static long si5351_clkout_round_rate(struct clk_hw *hw, unsigned long rate,
> +                                    unsigned long *parent_rate)
> +{
> +       struct si5351_hw_data *hwdata =
> +               container_of(hw, struct si5351_hw_data, hw);
> +       unsigned char rdiv;
> +
> +       /* clkout6/7 can only handle output freqencies < 150MHz */
> +       if (hwdata->num >= 6 && rate > SI5351_CLKOUT67_MAX_FREQ)
> +               rate = SI5351_CLKOUT67_MAX_FREQ;
> +
> +       /* clkout freqency is 8kHz - 160MHz */
> +       if (rate > SI5351_CLKOUT_MAX_FREQ)
> +               rate = SI5351_CLKOUT_MAX_FREQ;
> +       if (rate < SI5351_CLKOUT_MIN_FREQ)
> +               rate = SI5351_CLKOUT_MIN_FREQ;
> +
> +       /* request frequency if multisync master */
> +       if (__clk_get_flags(hwdata->hw.clk) & CLK_SET_RATE_PARENT) {
> +               /* use r divider for frequencies below 1MHz */
> +               rdiv = SI5351_OUTPUT_CLK_DIV_1;
> +               while (rate < SI5351_MULTISYNTH_MIN_FREQ &&
> +                      rdiv < SI5351_OUTPUT_CLK_DIV_128) {
> +                       rdiv += 1;
> +                       rate *= 2;
> +               }
> +               *parent_rate = rate;
> +       } else {
> +               unsigned long new_rate, new_err, err;
> +
> +               /* round to closed rdiv */
> +               rdiv = SI5351_OUTPUT_CLK_DIV_1;
> +               new_rate = *parent_rate;
> +               err = abs(new_rate - rate);
> +               do {
> +                       new_rate >>= 1;
> +                       new_err = abs(new_rate - rate);
> +                       if (new_err > err || rdiv == SI5351_OUTPUT_CLK_DIV_128)
> +                               break;
> +                       rdiv++;
> +                       err = new_err;
> +               } while (1);
> +       }
> +       rate = *parent_rate >> rdiv;
> +
> +       dev_dbg(&hwdata->drvdata->client->dev,
> +               "%s - %s: rdiv = %u, parent_rate = %lu, rate = %lu\n",
> +               __func__, __clk_get_name(hwdata->hw.clk), (1 << rdiv),
> +               *parent_rate, rate);
> +
> +       return rate;
> +}
> +
> +static int si5351_clkout_set_rate(struct clk_hw *hw, unsigned long rate,
> +                                 unsigned long parent_rate)
> +{
> +       struct si5351_hw_data *hwdata =
> +               container_of(hw, struct si5351_hw_data, hw);
> +       unsigned long new_rate, new_err, err;
> +       unsigned char rdiv;
> +
> +       /* round to closed rdiv */
> +       rdiv = SI5351_OUTPUT_CLK_DIV_1;
> +       new_rate = parent_rate;
> +       err = abs(new_rate - rate);
> +       do {
> +               new_rate >>= 1;
> +               new_err = abs(new_rate - rate);
> +               if (new_err > err || rdiv == SI5351_OUTPUT_CLK_DIV_128)
> +                       break;
> +               rdiv++;
> +               err = new_err;
> +       } while (1);
> +
> +       /* write output divider */
> +       switch (hwdata->num) {
> +       case 6:
> +               si5351_set_bits(hwdata->drvdata, SI5351_CLK6_7_OUTPUT_DIVIDER,
> +                               SI5351_OUTPUT_CLK6_DIV_MASK, rdiv);
> +               break;
> +       case 7:
> +               si5351_set_bits(hwdata->drvdata, SI5351_CLK6_7_OUTPUT_DIVIDER,
> +                               SI5351_OUTPUT_CLK_DIV_MASK,
> +                               rdiv << SI5351_OUTPUT_CLK_DIV_SHIFT);
> +               break;
> +       default:
> +               si5351_set_bits(hwdata->drvdata,
> +                               si5351_msynth_params_address(hwdata->num) + 2,
> +                               SI5351_OUTPUT_CLK_DIV_MASK,
> +                               rdiv << SI5351_OUTPUT_CLK_DIV_SHIFT);
> +       }
> +
> +       /* powerup clkout */
> +       si5351_set_bits(hwdata->drvdata, SI5351_CLK0_CTRL + hwdata->num,
> +                       SI5351_CLK_POWERDOWN, 0);
> +
> +       dev_dbg(&hwdata->drvdata->client->dev,
> +               "%s - %s: rdiv = %u, parent_rate = %lu, rate = %lu\n",
> +               __func__, __clk_get_name(hwdata->hw.clk), (1 << rdiv),
> +               parent_rate, rate);
> +
> +       return 0;
> +}
> +
> +static const struct clk_ops si5351_clkout_ops = {
> +       .prepare = si5351_clkout_prepare,
> +       .unprepare = si5351_clkout_unprepare,
> +       .set_parent = si5351_clkout_set_parent,
> +       .get_parent = si5351_clkout_get_parent,
> +       .recalc_rate = si5351_clkout_recalc_rate,
> +       .round_rate = si5351_clkout_round_rate,
> +       .set_rate = si5351_clkout_set_rate,
> +};
> +
> +/*
> + * Si5351 i2c probe and DT
> + */
> +#ifdef CONFIG_OF
> +static const struct of_device_id si5351_dt_ids[] = {
> +       { .compatible = "silabs,si5351a", .data = (void *)SI5351_VARIANT_A, },
> +       { .compatible = "silabs,si5351a-msop",
> +                                        .data = (void *)SI5351_VARIANT_A3, },
> +       { .compatible = "silabs,si5351b", .data = (void *)SI5351_VARIANT_B, },
> +       { .compatible = "silabs,si5351c", .data = (void *)SI5351_VARIANT_C, },
> +       { }
> +};
> +MODULE_DEVICE_TABLE(of, si5351_dt_ids);
> +
> +static int si5351_dt_parse(struct i2c_client *client)
> +{
> +       struct device_node *child, *np = client->dev.of_node;
> +       struct si5351_platform_data *pdata;
> +       const struct of_device_id *match;
> +       struct property *prop;
> +       const __be32 *p;
> +       int num = 0;
> +       u32 val;
> +
> +       if (np == NULL)
> +               return 0;
> +
> +       match = of_match_node(si5351_dt_ids, np);
> +       if (match == NULL)
> +               return -EINVAL;
> +
> +       pdata = devm_kzalloc(&client->dev, sizeof(*pdata), GFP_KERNEL);
> +       if (!pdata)
> +               return -ENOMEM;
> +
> +       pdata->variant = (enum si5351_variant)match->data;
> +       pdata->clk_xtal = of_clk_get(np, 0);
> +       if (!IS_ERR(pdata->clk_xtal))
> +               clk_put(pdata->clk_xtal);
> +       pdata->clk_clkin = of_clk_get(np, 1);
> +       if (!IS_ERR(pdata->clk_clkin))
> +               clk_put(pdata->clk_clkin);
> +
> +       /*
> +        * property silabs,pll-source : <num src>, [<..>]
> +        * allow to selectively set pll source
> +        */
> +       of_property_for_each_u32(np, "silabs,pll-source", prop, p, num) {
> +               if (num >= 2) {
> +                       dev_err(&client->dev,
> +                               "invalid pll %d on pll-source prop\n", num);
> +                       return -EINVAL;
> +               }
> +
> +               p = of_prop_next_u32(prop, p, &val);
> +               if (!p) {
> +                       dev_err(&client->dev,
> +                               "missing pll-source for pll %d\n", num);
> +                       return -EINVAL;
> +               }
> +
> +               switch (val) {
> +               case 0:
> +                       pdata->pll_src[num] = SI5351_PLL_SRC_XTAL;
> +                       break;
> +               case 1:
> +                       if (pdata->variant != SI5351_VARIANT_C) {
> +                               dev_err(&client->dev,
> +                                       "invalid parent %d for pll %d\n",
> +                                       val, num);
> +                               return -EINVAL;
> +                       }
> +                       pdata->pll_src[num] = SI5351_PLL_SRC_CLKIN;
> +                       break;
> +               default:
> +                       dev_err(&client->dev,
> +                                "invalid parent %d for pll %d\n", val, num);
> +                       return -EINVAL;
> +               }
> +       }
> +
> +       /* per clkout properties */
> +       for_each_child_of_node(np, child) {
> +               if (of_property_read_u32(child, "reg", &num)) {
> +                       dev_err(&client->dev, "missing reg property of %s\n",
> +                               child->name);
> +                       return -EINVAL;
> +               }
> +
> +               if (num >= 8 ||
> +                   (pdata->variant == SI5351_VARIANT_A3 && num >= 3)) {
> +                       dev_err(&client->dev, "invalid clkout %d\n", num);
> +                       return -EINVAL;
> +               }
> +
> +               if (!of_property_read_u32(child, "silabs,multisynth-source",
> +                                         &val)) {
> +                       switch (val) {
> +                       case 0:
> +                               pdata->clkout[num].multisynth_src =
> +                                       SI5351_MULTISYNTH_SRC_VCO0;
> +                               break;
> +                       case 1:
> +                               pdata->clkout[num].multisynth_src =
> +                                       SI5351_MULTISYNTH_SRC_VCO1;
> +                               break;
> +                       default:
> +                               dev_err(&client->dev,
> +                                       "invalid parent %d for multisynth %d\n",
> +                                       val, num);
> +                               return -EINVAL;
> +                       }
> +               }
> +
> +               if (!of_property_read_u32(child, "silabs,clock-source", &val)) {
> +                       switch (val) {
> +                       case 0:
> +                               pdata->clkout[num].clkout_src =
> +                                       SI5351_CLKOUT_SRC_MSYNTH_N;
> +                               break;
> +                       case 1:
> +                               pdata->clkout[num].clkout_src =
> +                                       SI5351_CLKOUT_SRC_MSYNTH_0_4;
> +                               break;
> +                       case 2:
> +                               pdata->clkout[num].clkout_src =
> +                                       SI5351_CLKOUT_SRC_XTAL;
> +                               break;
> +                       case 3:
> +                               if (pdata->variant != SI5351_VARIANT_C) {
> +                                       dev_err(&client->dev,
> +                                               "invalid parent %d for clkout %d\n",
> +                                               val, num);
> +                                       return -EINVAL;
> +                               }
> +                               pdata->clkout[num].clkout_src =
> +                                       SI5351_CLKOUT_SRC_CLKIN;
> +                               break;
> +                       default:
> +                               dev_err(&client->dev,
> +                                       "invalid parent %d for clkout %d\n",
> +                                       val, num);
> +                               return -EINVAL;
> +                       }
> +               }
> +
> +               if (!of_property_read_u32(child, "silabs,drive-strength",
> +                                         &val)) {
> +                       switch (val) {
> +                       case SI5351_DRIVE_2MA:
> +                       case SI5351_DRIVE_4MA:
> +                       case SI5351_DRIVE_6MA:
> +                       case SI5351_DRIVE_8MA:
> +                               pdata->clkout[num].drive = val;
> +                               break;
> +                       default:
> +                               dev_err(&client->dev,
> +                                       "invalid drive strength %d for clkout %d\n",
> +                                       val, num);
> +                               return -EINVAL;
> +                       }
> +               }
> +
> +               if (!of_property_read_u32(child, "clock-frequency", &val))
> +                       pdata->clkout[num].rate = val;
> +
> +               pdata->clkout[num].pll_master =
> +                       of_property_read_bool(child, "silabs,pll-master");
> +       }
> +       client->dev.platform_data = pdata;
> +
> +       return 0;
> +}
> +#else
> +static int si5351_dt_parse(struct i2c_client *client)
> +{
> +       return 0;
> +}
> +#endif /* CONFIG_OF */
> +
> +static int si5351_i2c_probe(struct i2c_client *client,
> +                           const struct i2c_device_id *id)
> +{
> +       struct si5351_platform_data *pdata;
> +       struct si5351_driver_data *drvdata;
> +       struct clk_init_data init;
> +       struct clk *clk;
> +       const char *parent_names[4];
> +       u8 num_parents, num_clocks;
> +       int ret, n;
> +
> +       ret = si5351_dt_parse(client);
> +       if (ret)
> +               return ret;
> +
> +       pdata = client->dev.platform_data;
> +       if (!pdata)
> +               return -EINVAL;
> +
> +       drvdata = devm_kzalloc(&client->dev, sizeof(*drvdata), GFP_KERNEL);
> +       if (drvdata == NULL) {
> +               dev_err(&client->dev, "unable to allocate driver data\n");
> +               return -ENOMEM;
> +       }
> +
> +       i2c_set_clientdata(client, drvdata);
> +       drvdata->client = client;
> +       drvdata->variant = pdata->variant;
> +       drvdata->pxtal = pdata->clk_xtal;
> +       drvdata->pclkin = pdata->clk_clkin;
> +
> +       drvdata->regmap = devm_regmap_init_i2c(client, &si5351_regmap_config);
> +       if (IS_ERR(drvdata->regmap)) {
> +               dev_err(&client->dev, "failed to allocate register map\n");
> +               return PTR_ERR(drvdata->regmap);
> +       }
> +
> +       /* Disable interrupts */
> +       si5351_reg_write(drvdata, SI5351_INTERRUPT_MASK, 0xf0);
> +       /* Set disabled output drivers to drive low */
> +       si5351_reg_write(drvdata, SI5351_CLK3_0_DISABLE_STATE, 0x00);
> +       si5351_reg_write(drvdata, SI5351_CLK7_4_DISABLE_STATE, 0x00);
> +       /* Ensure pll select is on XTAL for Si5351A/B */
> +       if (drvdata->variant != SI5351_VARIANT_C)
> +               si5351_set_bits(drvdata, SI5351_PLL_INPUT_SOURCE,
> +                               SI5351_PLLA_SOURCE | SI5351_PLLB_SOURCE, 0);
> +
> +       /* setup clock configuration */
> +       for (n = 0; n < 2; n++) {
> +               ret = _si5351_pll_reparent(drvdata, n, pdata->pll_src[n]);
> +               if (ret) {
> +                       dev_err(&client->dev,
> +                               "failed to reparent pll %d to %d\n",
> +                               n, pdata->pll_src[n]);
> +                       return ret;
> +               }
> +       }
> +
> +       for (n = 0; n < 8; n++) {
> +               ret = _si5351_msynth_reparent(drvdata, n,
> +                                             pdata->clkout[n].multisynth_src);
> +               if (ret) {
> +                       dev_err(&client->dev,
> +                               "failed to reparent multisynth %d to %d\n",
> +                               n, pdata->clkout[n].multisynth_src);
> +                       return ret;
> +               }
> +
> +               ret = _si5351_clkout_reparent(drvdata, n,
> +                                             pdata->clkout[n].clkout_src);
> +               if (ret) {
> +                       dev_err(&client->dev,
> +                               "failed to reparent clkout %d to %d\n",
> +                               n, pdata->clkout[n].clkout_src);
> +                       return ret;
> +               }
> +
> +               ret = _si5351_clkout_set_drive_strength(drvdata, n,
> +                                                       pdata->clkout[n].drive);
> +               if (ret) {
> +                       dev_err(&client->dev,
> +                               "failed set drive strength of clkout%d to %d\n",
> +                               n, pdata->clkout[n].drive);
> +                       return ret;
> +               }
> +       }
> +
> +       /* register xtal input clock gate */
> +       memset(&init, 0, sizeof(init));
> +       init.name = si5351_input_names[0];
> +       init.ops = &si5351_xtal_ops;
> +       init.flags = 0;
> +       if (!IS_ERR(drvdata->pxtal)) {
> +               drvdata->pxtal_name = __clk_get_name(drvdata->pxtal);
> +               init.parent_names = &drvdata->pxtal_name;
> +               init.num_parents = 1;
> +       }
> +       drvdata->xtal.init = &init;
> +       clk = devm_clk_register(&client->dev, &drvdata->xtal);
> +       if (IS_ERR(clk)) {
> +               dev_err(&client->dev, "unable to register %s\n", init.name);
> +               return PTR_ERR(clk);
> +       }
> +
> +       /* register clkin input clock gate */
> +       if (drvdata->variant == SI5351_VARIANT_C) {
> +               memset(&init, 0, sizeof(init));
> +               init.name = si5351_input_names[1];
> +               init.ops = &si5351_clkin_ops;
> +               if (!IS_ERR(drvdata->pclkin)) {
> +                       drvdata->pclkin_name = __clk_get_name(drvdata->pclkin);
> +                       init.parent_names = &drvdata->pclkin_name;
> +                       init.num_parents = 1;
> +               }
> +               drvdata->clkin.init = &init;
> +               clk = devm_clk_register(&client->dev, &drvdata->clkin);
> +               if (IS_ERR(clk)) {
> +                       dev_err(&client->dev, "unable to register %s\n",
> +                               init.name);
> +                       return PTR_ERR(clk);
> +               }
> +       }
> +
> +       /* Si5351C allows to mux either xtal or clkin to PLL input */
> +       num_parents = (drvdata->variant == SI5351_VARIANT_C) ? 2 : 1;
> +       parent_names[0] = si5351_input_names[0];
> +       parent_names[1] = si5351_input_names[1];
> +
> +       /* register PLLA */
> +       drvdata->pll[0].num = 0;
> +       drvdata->pll[0].drvdata = drvdata;
> +       drvdata->pll[0].hw.init = &init;
> +       memset(&init, 0, sizeof(init));
> +       init.name = si5351_pll_names[0];
> +       init.ops = &si5351_pll_ops;
> +       init.flags = 0;
> +       init.parent_names = parent_names;
> +       init.num_parents = num_parents;
> +       clk = devm_clk_register(&client->dev, &drvdata->pll[0].hw);
> +       if (IS_ERR(clk)) {
> +               dev_err(&client->dev, "unable to register %s\n", init.name);
> +               return -EINVAL;
> +       }
> +
> +       /* register PLLB or VXCO (Si5351B) */
> +       drvdata->pll[1].num = 1;
> +       drvdata->pll[1].drvdata = drvdata;
> +       drvdata->pll[1].hw.init = &init;
> +       memset(&init, 0, sizeof(init));
> +       if (drvdata->variant == SI5351_VARIANT_B) {
> +               init.name = si5351_pll_names[2];
> +               init.ops = &si5351_vxco_ops;
> +               init.flags = CLK_IS_ROOT;
> +               init.parent_names = NULL;
> +               init.num_parents = 0;
> +       } else {
> +               init.name = si5351_pll_names[1];
> +               init.ops = &si5351_pll_ops;
> +               init.flags = 0;
> +               init.parent_names = parent_names;
> +               init.num_parents = num_parents;
> +       }
> +       clk = devm_clk_register(&client->dev, &drvdata->pll[1].hw);
> +       if (IS_ERR(clk)) {
> +               dev_err(&client->dev, "unable to register %s\n", init.name);
> +               return -EINVAL;
> +       }
> +
> +       /* register clk multisync and clk out divider */
> +       num_clocks = (drvdata->variant == SI5351_VARIANT_A3) ? 3 : 8;
> +       parent_names[0] = si5351_pll_names[0];
> +       if (drvdata->variant == SI5351_VARIANT_B)
> +               parent_names[1] = si5351_pll_names[2];
> +       else
> +               parent_names[1] = si5351_pll_names[1];
> +
> +       drvdata->msynth = devm_kzalloc(&client->dev, num_clocks *
> +                                      sizeof(*drvdata->msynth), GFP_KERNEL);
> +       drvdata->clkout = devm_kzalloc(&client->dev, num_clocks *
> +                                      sizeof(*drvdata->clkout), GFP_KERNEL);
> +
> +       drvdata->onecell.clk_num = num_clocks;
> +       drvdata->onecell.clks = devm_kzalloc(&client->dev,
> +               num_clocks * sizeof(*drvdata->onecell.clks), GFP_KERNEL);
> +
> +       if (WARN_ON(!drvdata->msynth || !drvdata->clkout ||
> +                   !drvdata->onecell.clks))
> +               return -ENOMEM;
> +
> +       for (n = 0; n < num_clocks; n++) {
> +               drvdata->msynth[n].num = n;
> +               drvdata->msynth[n].drvdata = drvdata;
> +               drvdata->msynth[n].hw.init = &init;
> +               memset(&init, 0, sizeof(init));
> +               init.name = si5351_msynth_names[n];
> +               init.ops = &si5351_msynth_ops;
> +               init.flags = 0;
> +               if (pdata->clkout[n].pll_master)
> +                       init.flags |= CLK_SET_RATE_PARENT;
> +               init.parent_names = parent_names;
> +               init.num_parents = 2;
> +               clk = devm_clk_register(&client->dev, &drvdata->msynth[n].hw);
> +               if (IS_ERR(clk)) {
> +                       dev_err(&client->dev, "unable to register %s\n",
> +                               init.name);
> +                       return -EINVAL;
> +               }
> +       }
> +
> +       num_parents = (drvdata->variant == SI5351_VARIANT_C) ? 4 : 3;
> +       parent_names[2] = si5351_input_names[0];
> +       parent_names[3] = si5351_input_names[1];
> +       for (n = 0; n < num_clocks; n++) {
> +               parent_names[0] = si5351_msynth_names[n];
> +               parent_names[1] = (n < 4) ? si5351_msynth_names[0] :
> +                       si5351_msynth_names[4];
> +
> +               drvdata->clkout[n].num = n;
> +               drvdata->clkout[n].drvdata = drvdata;
> +               drvdata->clkout[n].hw.init = &init;
> +               memset(&init, 0, sizeof(init));
> +               init.name = si5351_clkout_names[n];
> +               init.ops = &si5351_clkout_ops;
> +               init.flags = 0;
> +               if (pdata->clkout[n].clkout_src == SI5351_CLKOUT_SRC_MSYNTH_N)
> +                       init.flags |= CLK_SET_RATE_PARENT;
> +               init.parent_names = parent_names;
> +               init.num_parents = num_parents;
> +               clk = devm_clk_register(&client->dev, &drvdata->clkout[n].hw);
> +               if (IS_ERR(clk)) {
> +                       dev_err(&client->dev, "unable to register %s\n",
> +                               init.name);
> +                       return -EINVAL;
> +               }
> +               drvdata->onecell.clks[n] = clk;
> +       }
> +
> +       ret = of_clk_add_provider(client->dev.of_node, of_clk_src_onecell_get,
> +                                 &drvdata->onecell);
> +       if (ret) {
> +               dev_err(&client->dev, "unable to add clk provider\n");
> +               return ret;
> +       }
> +
> +       return 0;
> +}
> +
> +static const struct i2c_device_id si5351_i2c_ids[] = {
> +       { "silabs,si5351", 0 },
> +       { }
> +};
> +MODULE_DEVICE_TABLE(i2c, si5351_i2c_ids);
> +
> +static struct i2c_driver si5351_driver = {
> +       .driver = {
> +               .name = "si5351",
> +               .of_match_table = of_match_ptr(si5351_dt_ids),
> +       },
> +       .probe = si5351_i2c_probe,
> +       .id_table = si5351_i2c_ids,
> +};
> +module_i2c_driver(si5351_driver);
> +
> +MODULE_AUTHOR("Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com");
> +MODULE_DESCRIPTION("Silicon Labs Si5351A/B/C clock generator driver");
> +MODULE_LICENSE("GPL");
> diff --git a/drivers/clk/clk-si5351.h b/drivers/clk/clk-si5351.h
> new file mode 100644
> index 0000000..af41b50
> --- /dev/null
> +++ b/drivers/clk/clk-si5351.h
> @@ -0,0 +1,155 @@
> +/*
> + * clk-si5351.h: Silicon Laboratories Si5351A/B/C I2C Clock Generator
> + *
> + * Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
> + * Rabeeh Khoury <rabeeh at solid-run.com>
> + *
> + * 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.
> + */
> +
> +#ifndef _CLK_SI5351_H_
> +#define _CLK_SI5351_H_
> +
> +#define SI5351_BUS_BASE_ADDR                   0x60
> +
> +#define SI5351_PLL_VCO_MIN                     600000000
> +#define SI5351_PLL_VCO_MAX                     900000000
> +#define SI5351_MULTISYNTH_MIN_FREQ             1000000
> +#define SI5351_MULTISYNTH_DIVBY4_FREQ          150000000
> +#define SI5351_MULTISYNTH_MAX_FREQ             160000000
> +#define SI5351_MULTISYNTH67_MAX_FREQ           SI5351_MULTISYNTH_DIVBY4_FREQ
> +#define SI5351_CLKOUT_MIN_FREQ                 8000
> +#define SI5351_CLKOUT_MAX_FREQ                 SI5351_MULTISYNTH_MAX_FREQ
> +#define SI5351_CLKOUT67_MAX_FREQ               SI5351_MULTISYNTH67_MAX_FREQ
> +
> +#define SI5351_PLL_A_MIN                       15
> +#define SI5351_PLL_A_MAX                       90
> +#define SI5351_PLL_B_MAX                       (SI5351_PLL_C_MAX-1)
> +#define SI5351_PLL_C_MAX                       1048575
> +#define SI5351_MULTISYNTH_A_MIN                        6
> +#define SI5351_MULTISYNTH_A_MAX                        1800
> +#define SI5351_MULTISYNTH67_A_MAX              254
> +#define SI5351_MULTISYNTH_B_MAX                        (SI5351_MULTISYNTH_C_MAX-1)
> +#define SI5351_MULTISYNTH_C_MAX                        1048575
> +#define SI5351_MULTISYNTH_P1_MAX               ((1<<18)-1)
> +#define SI5351_MULTISYNTH_P2_MAX               ((1<<20)-1)
> +#define SI5351_MULTISYNTH_P3_MAX               ((1<<20)-1)
> +
> +#define SI5351_DEVICE_STATUS                   0
> +#define SI5351_INTERRUPT_STATUS                        1
> +#define SI5351_INTERRUPT_MASK                  2
> +#define  SI5351_STATUS_SYS_INIT                        (1<<7)
> +#define  SI5351_STATUS_LOL_B                   (1<<6)
> +#define  SI5351_STATUS_LOL_A                   (1<<5)
> +#define  SI5351_STATUS_LOS                     (1<<4)
> +#define SI5351_OUTPUT_ENABLE_CTRL              3
> +#define SI5351_OEB_PIN_ENABLE_CTRL             9
> +#define SI5351_PLL_INPUT_SOURCE                        15
> +#define  SI5351_CLKIN_DIV_MASK                 (3<<6)
> +#define  SI5351_CLKIN_DIV_1                    (0<<6)
> +#define  SI5351_CLKIN_DIV_2                    (1<<6)
> +#define  SI5351_CLKIN_DIV_4                    (2<<6)
> +#define  SI5351_CLKIN_DIV_8                    (3<<6)
> +#define  SI5351_PLLB_SOURCE                    (1<<3)
> +#define  SI5351_PLLA_SOURCE                    (1<<2)
> +
> +#define SI5351_CLK0_CTRL                       16
> +#define SI5351_CLK1_CTRL                       17
> +#define SI5351_CLK2_CTRL                       18
> +#define SI5351_CLK3_CTRL                       19
> +#define SI5351_CLK4_CTRL                       20
> +#define SI5351_CLK5_CTRL                       21
> +#define SI5351_CLK6_CTRL                       22
> +#define SI5351_CLK7_CTRL                       23
> +#define  SI5351_CLK_POWERDOWN                  (1<<7)
> +#define  SI5351_CLK_INTEGER_MODE               (1<<6)
> +#define  SI5351_CLK_PLL_SELECT                 (1<<5)
> +#define  SI5351_CLK_INVERT                     (1<<4)
> +#define  SI5351_CLK_INPUT_MASK                 (3<<2)
> +#define  SI5351_CLK_INPUT_XTAL                 (0<<2)
> +#define  SI5351_CLK_INPUT_CLKIN                        (1<<2)
> +#define  SI5351_CLK_INPUT_MULTISYNTH_0_4       (2<<2)
> +#define  SI5351_CLK_INPUT_MULTISYNTH_N         (3<<2)
> +#define  SI5351_CLK_DRIVE_STRENGTH_MASK                (3<<0)
> +#define  SI5351_CLK_DRIVE_STRENGTH_2MA         (0<<0)
> +#define  SI5351_CLK_DRIVE_STRENGTH_4MA         (1<<0)
> +#define  SI5351_CLK_DRIVE_STRENGTH_6MA         (2<<0)
> +#define  SI5351_CLK_DRIVE_STRENGTH_8MA         (3<<0)
> +
> +#define SI5351_CLK3_0_DISABLE_STATE            24
> +#define SI5351_CLK7_4_DISABLE_STATE            25
> +#define  SI5351_CLK_DISABLE_STATE_LOW          0
> +#define  SI5351_CLK_DISABLE_STATE_HIGH         1
> +#define  SI5351_CLK_DISABLE_STATE_FLOAT                2
> +#define  SI5351_CLK_DISABLE_STATE_NEVER                3
> +
> +#define SI5351_PARAMETERS_LENGTH               8
> +#define SI5351_PLLA_PARAMETERS                 26
> +#define SI5351_PLLB_PARAMETERS                 34
> +#define SI5351_CLK0_PARAMETERS                 42
> +#define SI5351_CLK1_PARAMETERS                 50
> +#define SI5351_CLK2_PARAMETERS                 58
> +#define SI5351_CLK3_PARAMETERS                 66
> +#define SI5351_CLK4_PARAMETERS                 74
> +#define SI5351_CLK5_PARAMETERS                 82
> +#define SI5351_CLK6_PARAMETERS                 90
> +#define SI5351_CLK7_PARAMETERS                 91
> +#define SI5351_CLK6_7_OUTPUT_DIVIDER           92
> +#define  SI5351_OUTPUT_CLK_DIV_MASK            (7 << 4)
> +#define  SI5351_OUTPUT_CLK6_DIV_MASK           (7 << 0)
> +#define  SI5351_OUTPUT_CLK_DIV_SHIFT           4
> +#define  SI5351_OUTPUT_CLK_DIV6_SHIFT          0
> +#define  SI5351_OUTPUT_CLK_DIV_1               0
> +#define  SI5351_OUTPUT_CLK_DIV_2               1
> +#define  SI5351_OUTPUT_CLK_DIV_4               2
> +#define  SI5351_OUTPUT_CLK_DIV_8               3
> +#define  SI5351_OUTPUT_CLK_DIV_16              4
> +#define  SI5351_OUTPUT_CLK_DIV_32              5
> +#define  SI5351_OUTPUT_CLK_DIV_64              6
> +#define  SI5351_OUTPUT_CLK_DIV_128             7
> +#define  SI5351_OUTPUT_CLK_DIVBY4              (3<<2)
> +
> +#define SI5351_SSC_PARAM0                      149
> +#define SI5351_SSC_PARAM1                      150
> +#define SI5351_SSC_PARAM2                      151
> +#define SI5351_SSC_PARAM3                      152
> +#define SI5351_SSC_PARAM4                      153
> +#define SI5351_SSC_PARAM5                      154
> +#define SI5351_SSC_PARAM6                      155
> +#define SI5351_SSC_PARAM7                      156
> +#define SI5351_SSC_PARAM8                      157
> +#define SI5351_SSC_PARAM9                      158
> +#define SI5351_SSC_PARAM10                     159
> +#define SI5351_SSC_PARAM11                     160
> +#define SI5351_SSC_PARAM12                     161
> +
> +#define SI5351_VXCO_PARAMETERS_LOW             162
> +#define SI5351_VXCO_PARAMETERS_MID             163
> +#define SI5351_VXCO_PARAMETERS_HIGH            164
> +
> +#define SI5351_CLK0_PHASE_OFFSET               165
> +#define SI5351_CLK1_PHASE_OFFSET               166
> +#define SI5351_CLK2_PHASE_OFFSET               167
> +#define SI5351_CLK3_PHASE_OFFSET               168
> +#define SI5351_CLK4_PHASE_OFFSET               169
> +#define SI5351_CLK5_PHASE_OFFSET               170
> +
> +#define SI5351_PLL_RESET                       177
> +#define  SI5351_PLL_RESET_B                    (1<<7)
> +#define  SI5351_PLL_RESET_A                    (1<<5)
> +
> +#define SI5351_CRYSTAL_LOAD                    183
> +#define  SI5351_CRYSTAL_LOAD_MASK              (3<<6)
> +#define  SI5351_CRYSTAL_LOAD_6PF               (1<<6)
> +#define  SI5351_CRYSTAL_LOAD_8PF               (2<<6)
> +#define  SI5351_CRYSTAL_LOAD_10PF              (3<<6)
> +
> +#define SI5351_FANOUT_ENABLE                   187
> +#define  SI5351_CLKIN_ENABLE                   (1<<7)
> +#define  SI5351_XTAL_ENABLE                    (1<<6)
> +#define  SI5351_MULTISYNTH_ENABLE              (1<<4)
> +
> +#endif
> diff --git a/include/linux/platform_data/si5351.h b/include/linux/platform_data/si5351.h
> new file mode 100644
> index 0000000..92dabca
> --- /dev/null
> +++ b/include/linux/platform_data/si5351.h
> @@ -0,0 +1,114 @@
> +/*
> + * Si5351A/B/C programmable clock generator platform_data.
> + */
> +
> +#ifndef __LINUX_PLATFORM_DATA_SI5351_H__
> +#define __LINUX_PLATFORM_DATA_SI5351_H__
> +
> +struct clk;
> +
> +/**
> + * enum si5351_variant - SiLabs Si5351 chip variant
> + * @SI5351_VARIANT_A: Si5351A (8 output clocks, XTAL input)
> + * @SI5351_VARIANT_A3: Si5351A MSOP10 (3 output clocks, XTAL input)
> + * @SI5351_VARIANT_B: Si5351B (8 output clocks, XTAL/VXCO input)
> + * @SI5351_VARIANT_C: Si5351C (8 output clocks, XTAL/CLKIN input)
> + */
> +enum si5351_variant {
> +       SI5351_VARIANT_A = 1,
> +       SI5351_VARIANT_A3 = 2,
> +       SI5351_VARIANT_B = 3,
> +       SI5351_VARIANT_C = 4,
> +};
> +
> +/**
> + * enum si5351_pll_src - Si5351 pll clock source
> + * @SI5351_PLL_SRC_DEFAULT: default, do not change eeprom config
> + * @SI5351_PLL_SRC_XTAL: pll source clock is XTAL input
> + * @SI5351_PLL_SRC_CLKIN: pll source clock is CLKIN input (Si5351C only)
> + */
> +enum si5351_pll_src {
> +       SI5351_PLL_SRC_DEFAULT = 0,
> +       SI5351_PLL_SRC_XTAL = 1,
> +       SI5351_PLL_SRC_CLKIN = 2,
> +};
> +
> +/**
> + * enum si5351_multisynth_src - Si5351 multisynth clock source
> + * @SI5351_MULTISYNTH_SRC_DEFAULT: default, do not change eeprom config
> + * @SI5351_MULTISYNTH_SRC_VCO0: multisynth source clock is VCO0
> + * @SI5351_MULTISYNTH_SRC_VCO1: multisynth source clock is VCO1/VXCO
> + */
> +enum si5351_multisynth_src {
> +       SI5351_MULTISYNTH_SRC_DEFAULT = 0,
> +       SI5351_MULTISYNTH_SRC_VCO0 = 1,
> +       SI5351_MULTISYNTH_SRC_VCO1 = 2,
> +};
> +
> +/**
> + * enum si5351_clkout_src - Si5351 clock output clock source
> + * @SI5351_CLKOUT_SRC_DEFAULT: default, do not change eeprom config
> + * @SI5351_CLKOUT_SRC_MSYNTH_N: clkout N source clock is multisynth N
> + * @SI5351_CLKOUT_SRC_MSYNTH_0_4: clkout N source clock is multisynth 0 (N<4)
> + *                                or 4 (N>=4)
> + * @SI5351_CLKOUT_SRC_XTAL: clkout N source clock is XTAL
> + * @SI5351_CLKOUT_SRC_CLKIN: clkout N source clock is CLKIN (Si5351C only)
> + */
> +enum si5351_clkout_src {
> +       SI5351_CLKOUT_SRC_DEFAULT = 0,
> +       SI5351_CLKOUT_SRC_MSYNTH_N = 1,
> +       SI5351_CLKOUT_SRC_MSYNTH_0_4 = 2,
> +       SI5351_CLKOUT_SRC_XTAL = 3,
> +       SI5351_CLKOUT_SRC_CLKIN = 4,
> +};
> +
> +/**
> + * enum si5351_drive_strength - Si5351 clock output drive strength
> + * @SI5351_DRIVE_DEFAULT: default, do not change eeprom config
> + * @SI5351_DRIVE_2MA: 2mA clock output drive strength
> + * @SI5351_DRIVE_4MA: 4mA clock output drive strength
> + * @SI5351_DRIVE_6MA: 6mA clock output drive strength
> + * @SI5351_DRIVE_8MA: 8mA clock output drive strength
> + */
> +enum si5351_drive_strength {
> +       SI5351_DRIVE_DEFAULT = 0,
> +       SI5351_DRIVE_2MA = 2,
> +       SI5351_DRIVE_4MA = 4,
> +       SI5351_DRIVE_6MA = 6,
> +       SI5351_DRIVE_8MA = 8,
> +};
> +
> +/**
> + * struct si5351_clkout_config - Si5351 clock output configuration
> + * @clkout: clkout number
> + * @multisynth_src: multisynth source clock
> + * @clkout_src: clkout source clock
> + * @pll_master: if true, clkout can also change pll rate
> + * @drive: output drive strength
> + * @rate: initial clkout rate, or default if 0
> + */
> +struct si5351_clkout_config {
> +       enum si5351_multisynth_src multisynth_src;
> +       enum si5351_clkout_src clkout_src;
> +       enum si5351_drive_strength drive;
> +       bool pll_master;
> +       unsigned long rate;
> +};
> +
> +/**
> + * struct si5351_platform_data - Platform data for the Si5351 clock driver
> + * @variant: Si5351 chip variant
> + * @clk_xtal: xtal input clock
> + * @clk_clkin: clkin input clock
> + * @pll_src: array of pll source clock setting
> + * @clkout: array of clkout configuration
> + */
> +struct si5351_platform_data {
> +       enum si5351_variant variant;
> +       struct clk *clk_xtal;
> +       struct clk *clk_clkin;
> +       enum si5351_pll_src pll_src[2];
> +       struct si5351_clkout_config clkout[8];
> +};
> +
> +#endif
> -- 
> 1.7.10.4


From swarren at wwwdotorg.org  Fri Apr 12 14:29:06 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Fri, 12 Apr 2013 12:29:06 -0600
Subject: [PATCH 1/3] ARM: tegra: pcie: Add tegra3 support
In-Reply-To: <C79B248886DD134989C8FF6B096A91AB91B36FB302@BGMAIL01.nvidia.com>
References: <1365435688-4179-1-git-send-email-jagarwal@nvidia.com>
 <51630ABB.1020200@wwwdotorg.org>
 <C79B248886DD134989C8FF6B096A91AB91B36FB300@BGMAIL01.nvidia.com>
 <51683E00.4020506@wwwdotorg.org>
 <C79B248886DD134989C8FF6B096A91AB91B36FB302@BGMAIL01.nvidia.com>
Message-ID: <51685272.8010304@wwwdotorg.org>

On 04/12/2013 11:06 AM, Jay Agarwal wrote:
>> On 04/12/2013 10:43 AM, Jay Agarwal wrote:
>>>> On 04/08/2013 09:41 AM, Jay Agarwal wrote:
>>>>> Signed-off-by: Jay Agarwal <jagarwal at nvidia.com>
>>>>>
>>>>> - Enable pcie root port 2 for cardhu
>>>>> - Make private data structure for each SOC
>>>>> - Add required tegra3 clocks and regulators
>>>>> - Add tegra3 specific code in enable controller
>>>>> - Modify clock tree to get clocks based on device
>>>>> - Based on git://gitorious.org/thierryreding/linux.git
>>>>
>>>> A couple more points on this patch:
>>>>
>>>> * You didn't mention that this series is based on Thierry's
>>>> work-in-progress tree, and not something immediately destined for
>>>> upstream. As such, only Thierry is expected to actually apply any of these
>> patches.
>>>>
>>> [>] Stephen, I have mentioned it in comment description as Based on
>> git://gitorious.org/thierryreding/linux.git, is this not enough?
>>
>> Well, first off, there are many branches there, and secondly the branch that
>> a series is based on doesn't necessarily imply much about what you expect
>> people to do with it.
>>
> I am not clear, What should I mention then?

The branch name. Thierry's branch has the following:

  remotes/gitorious_thierryreding_linux/drm/hdmi-for-3.9
  remotes/gitorious_thierryreding_linux/drm/tegra-for-3.9
  remotes/gitorious_thierryreding_linux/tegra/drm/for-3.8
  remotes/gitorious_thierryreding_linux/tegra/drm/next
  remotes/gitorious_thierryreding_linux/tegra/next
  remotes/gitorious_thierryreding_linux/tegra/next-20130122

which of those was it based on?

Also, you simply said it was based on that repo. If you intend Thierry
to apply the patches to his repo/branch, rather than the usual
maintainers of the files you're editing, who you also CC'd, you should
specify that.


From cjb at laptop.org  Fri Apr 12 14:29:39 2013
From: cjb at laptop.org (Chris Ball)
Date: Fri, 12 Apr 2013 14:29:39 -0400
Subject: [PATCH v3] mmc: mxcmmc: DT support
In-Reply-To: <1364753258-16732-1-git-send-email-agust@denx.de> (Anatolij
 Gustschin's message of "Sun, 31 Mar 2013 20:07:38 +0200")
References: <1364225659-29677-1-git-send-email-mpa@pengutronix.de>
 <1364753258-16732-1-git-send-email-agust@denx.de>
Message-ID: <87sj2vd2lo.fsf@octavius.laptop.org>

Hi,

On Sun, Mar 31 2013, Anatolij Gustschin wrote:
> From: Markus Pargmann <mpa at pengutronix.de>
>
> Adding devicetree support for imx21-mmc and imx31-mmc. Based on generic
> gpio helper functions by Guennadi and generic DMA devicetree bindings.
>
> Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
> Signed-off-by:: Anatolij Gustschin <agust at denx.de>

Sascha, Arnd, perhaps one of you could review this?  There's another
patchset waiting on it.

Thanks!

- Chris.
-- 
Chris Ball   <cjb at laptop.org>   <http://printf.net/>
One Laptop Per Child


From mturquette at linaro.org  Fri Apr 12 14:40:37 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Fri, 12 Apr 2013 11:40:37 -0700
Subject: [PATCH v2 3/3] clk: sunxi: Unify oscillator clock
In-Reply-To: <5165FEB9.9080906@elopez.com.ar>
References: <1365515284-32061-2-git-send-email-emilio@elopez.com.ar>
 <1365631378-16103-1-git-send-email-mturquette@linaro.org>
 <1365631378-16103-4-git-send-email-mturquette@linaro.org>
 <5165FEB9.9080906@elopez.com.ar>
Message-ID: <20130412184037.6507.31234@quantum>

Quoting Emilio L?pez (2013-04-10 17:07:21)
> Hi Mike,
> 
> El 10/04/13 19:02, Mike Turquette escribi?:
> > From: Emilio L?pez <emilio at elopez.com.ar>
> > 
> > This commit uses the new fixed-rate support on the composite clock to
> > unify osc24M_fixed and osc24M clocks, so it matches the actual hardware.
> > 
> > Signed-off-by: Emilio L?pez <emilio at elopez.com.ar>
> > Signed-off-by: Mike Turquette <mturquette at linaro.org>
> > [mturquette at linaro.org: replace clk_register_gatable_osc with a call to
> > clk_register_composite]
> > ---
> > Emilio,
> > 
> > I haven't been able to test these changes at run-time.  Can you see if
> > they are valid for solving your issue on sunxi?
> 
> I tested the three patches you sent + 3/3 from the original series which
> is the DT part.
> 
> $ git log --oneline -n 4
> b63f51e ARM: sunxi: unify osc24M_fixed and osc24M
> 7f86473 clk: sunxi: Unify oscillator clock
> 78c8aaf clk: composite: allow fixed rates & fixed dividers
> 2d52a44 clk: composite: rename 'div' references to 'rate'
> 
> It seems to be working fine as far as I can tell, so
> 
> Tested-by: Emilio L?pez <emilio at elopez.com.ar>
> 

I've applied all three patches to clk-next.  I assume the DT patch will
go through Maxime's tree.

Regards,
Mike

> Thanks,
> 
> Emilio


From mturquette at linaro.org  Fri Apr 12 14:38:09 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Fri, 12 Apr 2013 11:38:09 -0700
Subject: [PATCH] clk: si5351: Add gapless tuning for SI5351 PLL
In-Reply-To: <1365495975-792-1-git-send-email-michal.bachraty@streamunlimited.com>
References: <1365495975-792-1-git-send-email-michal.bachraty@streamunlimited.com>
Message-ID: <20130412183809.6507.27844@quantum>

Quoting Michal Bachraty (2013-04-09 01:26:15)
> For gapless tuning, there is no need for PLL reset and clkout power-down
> when tuning output. "silabs,gapless-tuning" parameter enables gapless tuning
> for specific clock output.
> 
> Signed-off-by: Michal Bachraty <michal.bachraty at streamunlimited.com>

Hi Michal,

This did not apply cleanly on the latest (v8) si5351 clk driver.  Can
you refresh it?  I do not plan on taking any more patches for 3.10 after
3.9-rc7 drops (likely on Sunday or Monday).  So this patch may need to
wait until after the merge window.

Regards,
Mike

> ---
>  .../devicetree/bindings/clock/silabs,si5351.txt    |    2 ++
>  drivers/clk/clk-si5351.c                           |   27 +++++++++++++++++---
>  2 files changed, 25 insertions(+), 4 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/clock/silabs,si5351.txt b/Documentation/devicetree/bindings/clock/silabs,si5351.txt
> index cc37465..e16ab2b 100644
> --- a/Documentation/devicetree/bindings/clock/silabs,si5351.txt
> +++ b/Documentation/devicetree/bindings/clock/silabs,si5351.txt
> @@ -44,6 +44,8 @@ Optional child node properties:
>  - silabs,multisynth-source: source pll A(0) or B(1) of corresponding multisynth
>    divider.
>  - silabs,pll-master: boolean, multisynth can change pll frequency.
> +- silabs,gapless-tuning: boolean, enable gapless (glitch-free) tuning. Depends on
> +  "silabs,multisynth-source" parameter.
>  
>  ==Example==
>  
> diff --git a/drivers/clk/clk-si5351.c b/drivers/clk/clk-si5351.c
> index e259cec..d3933a9 100644
> --- a/drivers/clk/clk-si5351.c
> +++ b/drivers/clk/clk-si5351.c
> @@ -54,6 +54,7 @@ struct si5351_hw_data {
>         struct si5351_driver_data       *drvdata;
>         struct si5351_parameters        params;
>         unsigned char                   num;
> +       unsigned char                   gapless_tuning;
>  };
>  
>  struct si5351_driver_data {
> @@ -526,8 +527,10 @@ static int si5351_pll_set_rate(struct clk_hw *hw, unsigned long rate,
>                 (hwdata->params.p2 == 0) ? SI5351_CLK_INTEGER_MODE : 0);
>  
>         /* reset pll */
> -       val = (hwdata->num == 0) ? SI5351_PLL_RESET_A : SI5351_PLL_RESET_B;
> -       si5351_set_bits(hwdata->drvdata, SI5351_PLL_RESET, val, val);
> +       if (!hwdata->gapless_tuning) {
> +               val = (hwdata->num == 0) ? SI5351_PLL_RESET_A : SI5351_PLL_RESET_B;
> +               si5351_set_bits(hwdata->drvdata, SI5351_PLL_RESET, val, val);
> +       }
>  
>         dev_dbg(&hwdata->drvdata->client->dev,
>                 "%s - %s: p1 = %lu, p2 = %lu, p3 = %lu, parent_rate = %lu, rate = %lu\n",
> @@ -1064,8 +1067,9 @@ static int si5351_clkout_set_rate(struct clk_hw *hw, unsigned long rate,
>         } while (1);
>  
>         /* powerdown clkout */
> -       si5351_set_bits(hwdata->drvdata, SI5351_CLK0_CTRL + hwdata->num,
> -                       SI5351_CLK_POWERDOWN, SI5351_CLK_POWERDOWN);
> +       if (!hwdata->gapless_tuning)
> +               si5351_set_bits(hwdata->drvdata, SI5351_CLK0_CTRL + hwdata->num,
> +                               SI5351_CLK_POWERDOWN, SI5351_CLK_POWERDOWN);
>  
>         /* write output divider */
>         switch (hwdata->num) {
> @@ -1117,6 +1121,7 @@ static void si5351_dt_setup(
>         struct property *prop;
>         const __be32 *p;
>         unsigned int num, val;
> +       int pll = -1;
>  
>         if (np == NULL)
>                 return;
> @@ -1167,6 +1172,8 @@ static void si5351_dt_setup(
>                                 dev_warn(&client->dev,
>                                          "unable to reparent multisynth %d to %d\n",
>                                          num, val);
> +                       else
> +                               pll = val;
>                 }
>  
>                 if (!of_property_read_u32(np, "silabs,clock-source", &val)) {
> @@ -1178,6 +1185,15 @@ static void si5351_dt_setup(
>  
>                 if (!of_property_read_u32(np, "clock-frequency", &val))
>                         clk_set_rate(drvdata->onecell.clks[num], val);
> +
> +               if (of_property_read_bool(np, "silabs,gapless-tuning")) {
> +                       if (pll >= 0) {
> +                               drvdata->clkout[num].gapless_tuning = 1;
> +                               drvdata->pll[pll].gapless_tuning = 1;
> +                       } else
> +                               dev_warn(&client->dev,
> +                                       "unable to set gapless tuning");
> +               }
>         }
>  }
>  
> @@ -1294,6 +1310,7 @@ static int si5351_i2c_probe(struct i2c_client *client,
>         drvdata->pll[0].num = 0;
>         drvdata->pll[0].drvdata = drvdata;
>         drvdata->pll[0].hw.init = &init;
> +       drvdata->pll[0].gapless_tuning = 0;
>         memset(&init, 0, sizeof(init));
>         init.name = si5351_pll_names[0];
>         init.ops = &si5351_pll_ops;
> @@ -1310,6 +1327,7 @@ static int si5351_i2c_probe(struct i2c_client *client,
>         drvdata->pll[1].num = 1;
>         drvdata->pll[1].drvdata = drvdata;
>         drvdata->pll[1].hw.init = &init;
> +       drvdata->pll[1].gapless_tuning = 0;
>         memset(&init, 0, sizeof(init));
>         if (drvdata->variant == SI5351_VARIANT_B) {
>                 init.name = si5351_pll_names[2];
> @@ -1380,6 +1398,7 @@ static int si5351_i2c_probe(struct i2c_client *client,
>                 drvdata->clkout[n].num = n;
>                 drvdata->clkout[n].drvdata = drvdata;
>                 drvdata->clkout[n].hw.init = &init;
> +               drvdata->clkout[n].gapless_tuning = 0;
>                 memset(&init, 0, sizeof(init));
>                 init.name = si5351_clkout_names[n];
>                 init.ops = &si5351_clkout_ops;
> -- 
> 1.7.9.5


From rpimentel.silva at gmail.com  Fri Apr 12 14:49:09 2013
From: rpimentel.silva at gmail.com (Rogerio Pimentel)
Date: Fri, 12 Apr 2013 15:49:09 -0300
Subject: [PATCH v2 3/4] ARM: dts: mx53qsb: Add support for parallel display
In-Reply-To: <1365520643.4023.52.camel@pizza.hi.pengutronix.de>
References: <1365516452-1287-1-git-send-email-rogerio.pimentel@freescale.com>
 <1365516452-1287-3-git-send-email-rogerio.pimentel@freescale.com>
 <1365520643.4023.52.camel@pizza.hi.pengutronix.de>
Message-ID: <CAOkaPuV2xNR=Vxsa6tPdnPS34Q5ffV9-f8DefhcJfvVvXWOADQ@mail.gmail.com>

On Tue, Apr 9, 2013 at 12:17 PM, Philipp Zabel <p.zabel at pengutronix.de> wrote:
> Am Dienstag, den 09.04.2013, 11:07 -0300 schrieb Rogerio Pimentel:
>> Add support for CLAA WVGA display for i.MX53 QSB.
>>
>> Signed-off-by: Rogerio Pimentel <rogerio.pimentel at freescale.com>
>> ---
>> Changes since v1:
>> Changed the label disp1 to disp0 to correctly match the display pins
>>  arch/arm/boot/dts/imx53-qsb.dtsp |   26 ++++++++++++++++++++++++++
>>  arch/arm/boot/dts/imx53.dtsip    |   35 +++++++++++++++++++++++++++++++++++
>>  2 files changed, 61 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/imx53-qsb.dtsp b/arch/arm/boot/dts/imx53-qsb.dtsp
>> index dae8d9f..6086a3c 100644
>> --- a/arch/arm/boot/dts/imx53-qsb.dtsp
>> +++ b/arch/arm/boot/dts/imx53-qsb.dtsp
>> @@ -21,6 +21,32 @@
>>               reg = <0x70000000 0x40000000>;
>>       };
>>
>> +     display at di0 {
>> +             compatible = "fsl,imx-parallel-display";
>> +             crtcs = <&ipu 0>;
>> +             interface-pix-fmt = "rgb565";
>> +             pinctrl-names = "default";
>> +             pinctrl-0 = <&pinctrl_ipu_disp0_1>;
>> +             display-timings {
>> +                     claawvga {
>> +                             native-mode;
>> +                             clock-frequency = <27000000>;
>> +                             hactive = <800>;
>> +                             vactive = <480>;
>> +                             hback-porch = <40>;
>> +                             hfront-porch = <60>;
>> +                             vback-porch = <10>;
>> +                             vfront-porch = <10>;
>> +                             hsync-len = <20>;
>> +                             vsync-len = <10>;
>> +                             hsync-active = <0>;
>> +                             vsync-active = <0>;
>> +                             de-active = <1>;
>> +                             pixelclk-active = <0>;
>> +                     };
>> +             };
>> +     };
>> +
>
> This clashes with the MCIMXHDMICARD daughter module, which has a sii902x
> HDMI encoder connected to DISP0 for i.MX53-QSB. Would it make sense to
> add all possible options to the device tree but mark them with
> status = "disabled" by default?
>
> regards
> Philipp
>
I'm planning to add support for MCIMXHDMICARD later because it will also
require support for sii902x. I'd like to add the parallel display that
we have available
today and after that add the support for sii902x. What do you think?

Rgds
Rogerio
>>       gpio-keys {
>>               compatible = "gpio-keys";
>>
>> diff --git a/arch/arm/boot/dts/imx53.dtsip b/arch/arm/boot/dts/imx53.dtsip
>> index 845982e..a5f9d68 100644
>> --- a/arch/arm/boot/dts/imx53.dtsip
>> +++ b/arch/arm/boot/dts/imx53.dtsip
>> @@ -444,6 +444,41 @@
>>                                       };
>>                               };
>>
>> +                             ipu_disp0 {
>> +                                     pinctrl_ipu_disp0_1: ipudisp0grp-1 {
>> +                                             fsl,pins = <
>> +                                             MX53_PAD_DI0_DISP_CLK__IPU_DI0_DISP_CLK 0x5
>> +                                             MX53_PAD_DI0_PIN15__IPU_DI0_PIN15 0x5
>> +                                             MX53_PAD_DI0_PIN2__IPU_DI0_PIN2 0x5
>> +                                             MX53_PAD_DI0_PIN3__IPU_DI0_PIN3  0x5
>> +                                             MX53_PAD_DISP0_DAT0__IPU_DISP0_DAT_0 0x5
>> +                                             MX53_PAD_DISP0_DAT1__IPU_DISP0_DAT_1 0x5
>> +                                             MX53_PAD_DISP0_DAT2__IPU_DISP0_DAT_2 0x5
>> +                                             MX53_PAD_DISP0_DAT3__IPU_DISP0_DAT_3 0x5
>> +                                             MX53_PAD_DISP0_DAT4__IPU_DISP0_DAT_4 0x5
>> +                                             MX53_PAD_DISP0_DAT5__IPU_DISP0_DAT_5 0x5
>> +                                             MX53_PAD_DISP0_DAT6__IPU_DISP0_DAT_6 0x5
>> +                                             MX53_PAD_DISP0_DAT7__IPU_DISP0_DAT_7 0x5
>> +                                             MX53_PAD_DISP0_DAT8__IPU_DISP0_DAT_8 0x5
>> +                                             MX53_PAD_DISP0_DAT9__IPU_DISP0_DAT_9 0x5
>> +                                             MX53_PAD_DISP0_DAT10__IPU_DISP0_DAT_10 0x5
>> +                                             MX53_PAD_DISP0_DAT11__IPU_DISP0_DAT_11 0x5
>> +                                             MX53_PAD_DISP0_DAT12__IPU_DISP0_DAT_12 0x5
>> +                                             MX53_PAD_DISP0_DAT13__IPU_DISP0_DAT_13 0x5
>> +                                             MX53_PAD_DISP0_DAT14__IPU_DISP0_DAT_14 0x5
>> +                                             MX53_PAD_DISP0_DAT15__IPU_DISP0_DAT_15 0x5
>> +                                             MX53_PAD_DISP0_DAT16__IPU_DISP0_DAT_16 0x5
>> +                                             MX53_PAD_DISP0_DAT17__IPU_DISP0_DAT_17 0x5
>> +                                             MX53_PAD_DISP0_DAT18__IPU_DISP0_DAT_18 0x5
>> +                                             MX53_PAD_DISP0_DAT19__IPU_DISP0_DAT_19 0x5
>> +                                             MX53_PAD_DISP0_DAT20__IPU_DISP0_DAT_20 0x5
>> +                                             MX53_PAD_DISP0_DAT21__IPU_DISP0_DAT_21 0x5
>> +                                             MX53_PAD_DISP0_DAT22__IPU_DISP0_DAT_22 0x5
>> +                                             MX53_PAD_DISP0_DAT23__IPU_DISP0_DAT_23 0x5
>> +                                             >;
>> +                                     };
>> +                             };
>> +
>>                               owire {
>>                                       pinctrl_owire_1: owiregrp-1 {
>>                                               fsl,pins = <
>
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From arnd at arndb.de  Fri Apr 12 14:54:55 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 12 Apr 2013 20:54:55 +0200
Subject: [PATCH v3] mmc: mxcmmc: DT support
In-Reply-To: <1364753258-16732-1-git-send-email-agust@denx.de>
References: <1364225659-29677-1-git-send-email-mpa@pengutronix.de>
 <1364753258-16732-1-git-send-email-agust@denx.de>
Message-ID: <201304122054.55432.arnd@arndb.de>

On Sunday 31 March 2013, Anatolij Gustschin wrote:
> 
> From: Markus Pargmann <mpa at pengutronix.de>
> 
> Adding devicetree support for imx21-mmc and imx31-mmc. Based on generic
> gpio helper functions by Guennadi and generic DMA devicetree bindings.
> 
> Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
> Signed-off-by:: Anatolij Gustschin <agust at denx.de>

Acked-by: Arnd Bergmann <arnd at arndb.de>


From davem at davemloft.net  Fri Apr 12 15:05:46 2013
From: davem at davemloft.net (David Miller)
Date: Fri, 12 Apr 2013 15:05:46 -0400 (EDT)
Subject: [PATCH v2] net: mv643xx_eth: remove deprecated inet_lro support
In-Reply-To: <1365771339.4459.0.camel@edumazet-glaptop>
References: <1365707488-28819-1-git-send-email-sebastian.hesselbarth@gmail.com>
 <1365758400-12565-1-git-send-email-sebastian.hesselbarth@gmail.com>
 <1365771339.4459.0.camel@edumazet-glaptop>
Message-ID: <20130412.150546.1401935323621074376.davem@davemloft.net>

From: Eric Dumazet <eric.dumazet at gmail.com>
Date: Fri, 12 Apr 2013 05:55:39 -0700

> On Fri, 2013-04-12 at 11:20 +0200, Sebastian Hesselbarth wrote:
>> With recent support for GRO, there is no need to keep both LRO and
>> GRO. This patch therefore removes the deprecated inet_lro support
>> from mv643xx_eth. This is work is based on an experimental patch
>> provided by Eric Dumazet and Willy Tarreau.
>> 
>> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
>> Based-on-patch-by: Eric Dumazet <eric.dumazet at gmail.com>
>> Based-on-patch-by: Willy Tarreau <w at 1wt.eu>
>> ---
>> Changes from v1:
>> - also remove INET_LRO from Kconfig (Reported by Eric Dumazet)
> 
> Thanks for finishing this patch
> 
> Signed-off-by: Eric Dumazet <edumazet at google.com>

Applied, but this driver is full of skeletons:

drivers/net/ethernet/marvell/mv643xx_eth.c: In function ?rxq_refill?:
drivers/net/ethernet/marvell/mv643xx_eth.c:618:19: error: invalid operands to binary - (have ?sk_buff_data_t? and ?unsigned char *?)

which is:

		size = skb->end - skb->data;

that is absolutely not a legal computation.

It happens to be in the only configuration for which this driver
can be enabled in Kconfig but that is no excuse for it :-)

From cjb at laptop.org  Fri Apr 12 15:12:56 2013
From: cjb at laptop.org (Chris Ball)
Date: Fri, 12 Apr 2013 15:12:56 -0400
Subject: [PATCH v3] mmc: mxcmmc: DT support
In-Reply-To: <201304122054.55432.arnd@arndb.de> (Arnd Bergmann's message of
 "Fri, 12 Apr 2013 20:54:55 +0200")
References: <1364225659-29677-1-git-send-email-mpa@pengutronix.de>
 <1364753258-16732-1-git-send-email-agust@denx.de>
 <201304122054.55432.arnd@arndb.de>
Message-ID: <87fvyvbm13.fsf@octavius.laptop.org>

Hi,

On Fri, Apr 12 2013, Arnd Bergmann wrote:
> On Sunday 31 March 2013, Anatolij Gustschin wrote:
>> 
>> From: Markus Pargmann <mpa at pengutronix.de>
>> 
>> Adding devicetree support for imx21-mmc and imx31-mmc. Based on generic
>> gpio helper functions by Guennadi and generic DMA devicetree bindings.
>> 
>> Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
>> Signed-off-by:: Anatolij Gustschin <agust at denx.de>
>
> Acked-by: Arnd Bergmann <arnd at arndb.de>

Thanks!  Pushed to mmc-next for 3.10.

- Chris.
-- 
Chris Ball   <cjb at laptop.org>   <http://printf.net/>
One Laptop Per Child


From t.figa at samsung.com  Fri Apr 12 15:17:16 2013
From: t.figa at samsung.com (Tomasz Figa)
Date: Fri, 12 Apr 2013 21:17:16 +0200
Subject: [PATCH v5 00/14] ARM: samsung-time: Prepare for multiplatform support
Message-ID: <1365794250-14436-1-git-send-email-t.figa@samsung.com>

This series is an attempt to make the samsung-time clocksource driver ready
for multiplatform kernels. It moves the driver to drivers/clocksource, cleans
it up from uses of static platform-specific definitions, simplifies timer
interrupt handling and adds Device Tree support.

The samsung_pwm clocksource driver is made the master driver, which
exposes a single function to the PWM driver to get required data. Only
samsung-time driver is reworked to use the master driver at this time,
since the PWM driver can be already considered broken at the moment and
needs separate series of several patches to fix and clean it up, which
I am already working on.

Tested on Universal C210 board with Device Tree. Not tested without
Device Tree, since it has been already broken before this series.
Compile tested for other related SoCs.

Changes since v4:
(http://thread.gmane.org/gmane.linux.kernel.samsung-soc/17464)
 - Changed the design again - now clocksource driver is considered the master
   and exports a single function to get access to things like base address,
   hardware variant information, shared spinlock for register access
   synchronization and interrupt numbers
 - Renamed the clocksource driver to samsung_pwm
 - Cleaned up the code a bit more
 - Added clocksource_of_init support

Changes since v3:
(http://thread.gmane.org/gmane.linux.kernel.samsung-soc/16664/)
 - Changed the design to use common (master) driver for operations that
   can be done from both clocksource and PWM drivers (as suggested by
   Arnd Bergmann) - needed to properly synchronize access to PWM registers
 - Moved handling of PWM prescaler and divider to master driver

Changes since v2:
(http://thread.gmane.org/gmane.linux.kernel.samsung-soc/16158)
 - Addressed comments from Rob Herring and Mark Rutland
 - Removed unused register definitions
 - Replaced samsung,source-timer and samsung,event-timer properties
   with samsung,pwm-outputs property that defines which PWM channels
   are reserved for PWM outputs on particular platform
 - Split non-DT and DT initialization into two functions
 - Fixed a copy paste error

Changes since v1:
(http://thread.gmane.org/gmane.linux.kernel.samsung-soc/16005)
 - Addressed comments from Mark Rutland
 - Documented struct samsung_timer_variant
 - Dropped inactive mail addresses from CC

Tomasz Figa (14):
  ARM: SAMSUNG: Move samsung-time to drivers/clocksource
  clocksource: samsung-pwm: Clean up platform header
  clocksource: samsung-pwm: Add infrastructure to share PWM hardware
  ARM: SAMSUNG: Unify base address definitions of timer block
  ARM: SAMSUNG: Add new PWM platform device
  ARM: SAMSUNG: Set PWM platform data
  clocksource: samsung-pwm: Use platform data to setup the clocksource
  clocksource: samsung-pwm: Synchronize register accesses
  clocksource: samsung-pwm: Move IRQ mask/ack handling to the driver
  ARM: SAMSUNG: Remove unused PWM timer IRQ chip code
  clocksource: samsung-pwm: Configure dividers directly
  clocksource: samsung-pwm: Do not use static mapping of registers
  clocksource: samsung-pwm: Drop unnecessary includes
  clocksource: samsung-pwm: Prepare for clocksource_of_init

 .../devicetree/bindings/pwm/pwm-samsung.txt        |  43 ++
 arch/arm/Kconfig                                   |   1 -
 arch/arm/mach-exynos/common.c                      |  10 +
 arch/arm/mach-exynos/include/mach/irqs.h           |   3 +-
 arch/arm/mach-exynos/include/mach/map.h            |   1 +
 arch/arm/mach-s3c24xx/common.c                     |  10 +
 arch/arm/mach-s3c24xx/include/mach/irqs.h          |   6 +
 arch/arm/mach-s3c24xx/include/mach/map.h           |   2 +
 arch/arm/mach-s3c64xx/common.c                     |  14 +-
 arch/arm/mach-s3c64xx/include/mach/irqs.h          |   8 -
 arch/arm/mach-s3c64xx/include/mach/map.h           |   1 +
 arch/arm/mach-s5p64x0/common.c                     |  10 +
 arch/arm/mach-s5p64x0/include/mach/irqs.h          |   2 -
 arch/arm/mach-s5p64x0/include/mach/map.h           |   1 +
 arch/arm/mach-s5pc100/common.c                     |  10 +
 arch/arm/mach-s5pc100/include/mach/irqs.h          |   2 -
 arch/arm/mach-s5pc100/include/mach/map.h           |   1 +
 arch/arm/mach-s5pv210/common.c                     |  10 +
 arch/arm/mach-s5pv210/include/mach/irqs.h          |   2 -
 arch/arm/mach-s5pv210/include/mach/map.h           |   1 +
 arch/arm/plat-samsung/Kconfig                      |  14 -
 arch/arm/plat-samsung/Makefile                     |   2 -
 arch/arm/plat-samsung/devs.c                       |  33 +-
 arch/arm/plat-samsung/include/plat/devs.h          |   1 +
 arch/arm/plat-samsung/include/plat/irq-vic-timer.h |  13 -
 arch/arm/plat-samsung/include/plat/irqs.h          |   9 -
 arch/arm/plat-samsung/include/plat/samsung-time.h  |  38 +-
 arch/arm/plat-samsung/irq-vic-timer.c              |  98 ----
 arch/arm/plat-samsung/s5p-irq.c                    |   3 -
 arch/arm/plat-samsung/samsung-time.c               | 394 -------------
 drivers/clocksource/Kconfig                        |   7 +
 drivers/clocksource/Makefile                       |   1 +
 drivers/clocksource/samsung_pwm.c                  | 636 +++++++++++++++++++++
 include/clocksource/samsung_pwm.h                  |  45 ++
 34 files changed, 849 insertions(+), 583 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/pwm/pwm-samsung.txt
 delete mode 100644 arch/arm/plat-samsung/include/plat/irq-vic-timer.h
 delete mode 100644 arch/arm/plat-samsung/irq-vic-timer.c
 delete mode 100644 arch/arm/plat-samsung/samsung-time.c
 create mode 100644 drivers/clocksource/samsung_pwm.c
 create mode 100644 include/clocksource/samsung_pwm.h

-- 
1.8.1.5



From marc.zyngier at arm.com  Fri Apr 12 15:17:46 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Fri, 12 Apr 2013 21:17:46 +0200
Subject: [PATCH] ARM: KVM: fix unbalanced
 =?UTF-8?Q?get=5Fcpu=28=29=20in=20acc?= =?UTF-8?Q?ess=5Fdcsw?=
In-Reply-To: <20130412181332.GB5075@mudshark.cambridge.arm.com>
References: <1365786828-548-1-git-send-email-marc.zyngier@arm.com>
 <20130412181332.GB5075@mudshark.cambridge.arm.com>
Message-ID: <4a199cdd4998480ed6ba3f1858698903@localhost>

On Fri, 12 Apr 2013 19:13:32 +0100, Will Deacon <will.deacon at arm.com>
wrote:
> On Fri, Apr 12, 2013 at 06:13:48PM +0100, Marc Zyngier wrote:
>> In the very unlikely event where a guest would be foolish enough to
>> *read* from a write-only cache maintainance register, we end up
>> with preemption disabled, due to a misplaced get_cpu().
>> 
>> Just move the "is_write" test outside of the critical section.
>> 
>> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> 
> I found it second time around!
> 
>   Reported-by: Will Deacon <will.deacon at arm.com>

Indeed you did! :-)

I'll add that to the commit, and on a couple of other as well...

        M.
-- 
Fast, cheap, reliable. Pick two.


From t.figa at samsung.com  Fri Apr 12 15:17:17 2013
From: t.figa at samsung.com (Tomasz Figa)
Date: Fri, 12 Apr 2013 21:17:17 +0200
Subject: [PATCH v5 01/14] ARM: SAMSUNG: Move samsung-time to
 drivers/clocksource
In-Reply-To: <1365794250-14436-1-git-send-email-t.figa@samsung.com>
References: <1365794250-14436-1-git-send-email-t.figa@samsung.com>
Message-ID: <1365794250-14436-2-git-send-email-t.figa@samsung.com>

This patch moves the Samsung PWM-based high resolution timer support
code from arch/arm/plat-samsung to drivers/clocksource.

This is a prerequisite for further work on making the driver more
multiplatform and Device Tree friendly.

In addition, the driver is renamed to samsung_pwm, since it uses PWM
timers available on Samsung SoCs for timekeeping purposes.

Signed-off-by: Tomasz Figa <t.figa at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
---
 arch/arm/plat-samsung/Kconfig        |   8 -
 arch/arm/plat-samsung/Makefile       |   1 -
 arch/arm/plat-samsung/samsung-time.c | 394 -----------------------------------
 drivers/clocksource/Kconfig          |   7 +
 drivers/clocksource/Makefile         |   1 +
 drivers/clocksource/samsung_pwm.c    | 394 +++++++++++++++++++++++++++++++++++
 6 files changed, 402 insertions(+), 403 deletions(-)
 delete mode 100644 arch/arm/plat-samsung/samsung-time.c
 create mode 100644 drivers/clocksource/samsung_pwm.c

diff --git a/arch/arm/plat-samsung/Kconfig b/arch/arm/plat-samsung/Kconfig
index 54d1861..6f632ba 100644
--- a/arch/arm/plat-samsung/Kconfig
+++ b/arch/arm/plat-samsung/Kconfig
@@ -60,14 +60,6 @@ config S3C_LOWLEVEL_UART_PORT
 	  this configuration should be between zero and two. The port
 	  must have been initialised by the boot-loader before use.
 
-# timer options
-
-config SAMSUNG_HRT
-	bool
-	select SAMSUNG_DEV_PWM
-	help
-	  Use the High Resolution timer support
-
 # clock options
 
 config SAMSUNG_CLOCK
diff --git a/arch/arm/plat-samsung/Makefile b/arch/arm/plat-samsung/Makefile
index a23c460..87494e1 100644
--- a/arch/arm/plat-samsung/Makefile
+++ b/arch/arm/plat-samsung/Makefile
@@ -12,7 +12,6 @@ obj-				:=
 # Objects we always build independent of SoC choice
 
 obj-y				+= init.o cpu.o
-obj-$(CONFIG_SAMSUNG_HRT) 	+= samsung-time.o
 
 obj-$(CONFIG_SAMSUNG_CLOCK)	+= clock.o
 obj-$(CONFIG_SAMSUNG_CLOCK)	+= pwm-clock.o
diff --git a/arch/arm/plat-samsung/samsung-time.c b/arch/arm/plat-samsung/samsung-time.c
deleted file mode 100644
index f899cbc..0000000
--- a/arch/arm/plat-samsung/samsung-time.c
+++ /dev/null
@@ -1,394 +0,0 @@
-/*
- * Copyright (c) 2011 Samsung Electronics Co., Ltd.
- *		http://www.samsung.com/
- *
- * samsung - Common hr-timer support (s3c and s5p)
- *
- * 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/interrupt.h>
-#include <linux/irq.h>
-#include <linux/err.h>
-#include <linux/clk.h>
-#include <linux/clockchips.h>
-#include <linux/platform_device.h>
-
-#include <asm/smp_twd.h>
-#include <asm/mach/time.h>
-#include <asm/mach/arch.h>
-#include <asm/mach/map.h>
-#include <asm/sched_clock.h>
-
-#include <mach/map.h>
-#include <plat/devs.h>
-#include <plat/regs-timer.h>
-#include <plat/samsung-time.h>
-
-static struct clk *tin_event;
-static struct clk *tin_source;
-static struct clk *tdiv_event;
-static struct clk *tdiv_source;
-static struct clk *timerclk;
-static struct samsung_timer_source timer_source;
-static unsigned long clock_count_per_tick;
-static void samsung_timer_resume(void);
-
-static void samsung_time_stop(enum samsung_timer_mode mode)
-{
-	unsigned long tcon;
-
-	tcon = __raw_readl(S3C2410_TCON);
-
-	switch (mode) {
-	case SAMSUNG_PWM0:
-		tcon &= ~S3C2410_TCON_T0START;
-		break;
-
-	case SAMSUNG_PWM1:
-		tcon &= ~S3C2410_TCON_T1START;
-		break;
-
-	case SAMSUNG_PWM2:
-		tcon &= ~S3C2410_TCON_T2START;
-		break;
-
-	case SAMSUNG_PWM3:
-		tcon &= ~S3C2410_TCON_T3START;
-		break;
-
-	case SAMSUNG_PWM4:
-		tcon &= ~S3C2410_TCON_T4START;
-		break;
-
-	default:
-		printk(KERN_ERR "Invalid Timer %d\n", mode);
-		break;
-	}
-	__raw_writel(tcon, S3C2410_TCON);
-}
-
-static void samsung_time_setup(enum samsung_timer_mode mode, unsigned long tcnt)
-{
-	unsigned long tcon;
-
-	tcon = __raw_readl(S3C2410_TCON);
-
-	tcnt--;
-
-	switch (mode) {
-	case SAMSUNG_PWM0:
-		tcon &= ~(0x0f << 0);
-		tcon |= S3C2410_TCON_T0MANUALUPD;
-		break;
-
-	case SAMSUNG_PWM1:
-		tcon &= ~(0x0f << 8);
-		tcon |= S3C2410_TCON_T1MANUALUPD;
-		break;
-
-	case SAMSUNG_PWM2:
-		tcon &= ~(0x0f << 12);
-		tcon |= S3C2410_TCON_T2MANUALUPD;
-		break;
-
-	case SAMSUNG_PWM3:
-		tcon &= ~(0x0f << 16);
-		tcon |= S3C2410_TCON_T3MANUALUPD;
-		break;
-
-	case SAMSUNG_PWM4:
-		tcon &= ~(0x07 << 20);
-		tcon |= S3C2410_TCON_T4MANUALUPD;
-		break;
-
-	default:
-		printk(KERN_ERR "Invalid Timer %d\n", mode);
-		break;
-	}
-
-	__raw_writel(tcnt, S3C2410_TCNTB(mode));
-	__raw_writel(tcnt, S3C2410_TCMPB(mode));
-	__raw_writel(tcon, S3C2410_TCON);
-}
-
-static void samsung_time_start(enum samsung_timer_mode mode, bool periodic)
-{
-	unsigned long tcon;
-
-	tcon  = __raw_readl(S3C2410_TCON);
-
-	switch (mode) {
-	case SAMSUNG_PWM0:
-		tcon |= S3C2410_TCON_T0START;
-		tcon &= ~S3C2410_TCON_T0MANUALUPD;
-
-		if (periodic)
-			tcon |= S3C2410_TCON_T0RELOAD;
-		else
-			tcon &= ~S3C2410_TCON_T0RELOAD;
-		break;
-
-	case SAMSUNG_PWM1:
-		tcon |= S3C2410_TCON_T1START;
-		tcon &= ~S3C2410_TCON_T1MANUALUPD;
-
-		if (periodic)
-			tcon |= S3C2410_TCON_T1RELOAD;
-		else
-			tcon &= ~S3C2410_TCON_T1RELOAD;
-		break;
-
-	case SAMSUNG_PWM2:
-		tcon |= S3C2410_TCON_T2START;
-		tcon &= ~S3C2410_TCON_T2MANUALUPD;
-
-		if (periodic)
-			tcon |= S3C2410_TCON_T2RELOAD;
-		else
-			tcon &= ~S3C2410_TCON_T2RELOAD;
-		break;
-
-	case SAMSUNG_PWM3:
-		tcon |= S3C2410_TCON_T3START;
-		tcon &= ~S3C2410_TCON_T3MANUALUPD;
-
-		if (periodic)
-			tcon |= S3C2410_TCON_T3RELOAD;
-		else
-			tcon &= ~S3C2410_TCON_T3RELOAD;
-		break;
-
-	case SAMSUNG_PWM4:
-		tcon |= S3C2410_TCON_T4START;
-		tcon &= ~S3C2410_TCON_T4MANUALUPD;
-
-		if (periodic)
-			tcon |= S3C2410_TCON_T4RELOAD;
-		else
-			tcon &= ~S3C2410_TCON_T4RELOAD;
-		break;
-
-	default:
-		printk(KERN_ERR "Invalid Timer %d\n", mode);
-		break;
-	}
-	__raw_writel(tcon, S3C2410_TCON);
-}
-
-static int samsung_set_next_event(unsigned long cycles,
-				struct clock_event_device *evt)
-{
-	samsung_time_setup(timer_source.event_id, cycles);
-	samsung_time_start(timer_source.event_id, NON_PERIODIC);
-
-	return 0;
-}
-
-static void samsung_set_mode(enum clock_event_mode mode,
-				struct clock_event_device *evt)
-{
-	samsung_time_stop(timer_source.event_id);
-
-	switch (mode) {
-	case CLOCK_EVT_MODE_PERIODIC:
-		samsung_time_setup(timer_source.event_id, clock_count_per_tick);
-		samsung_time_start(timer_source.event_id, PERIODIC);
-		break;
-
-	case CLOCK_EVT_MODE_ONESHOT:
-		break;
-
-	case CLOCK_EVT_MODE_UNUSED:
-	case CLOCK_EVT_MODE_SHUTDOWN:
-		break;
-
-	case CLOCK_EVT_MODE_RESUME:
-		samsung_timer_resume();
-		break;
-	}
-}
-
-static void samsung_timer_resume(void)
-{
-	/* event timer restart */
-	samsung_time_setup(timer_source.event_id, clock_count_per_tick);
-	samsung_time_start(timer_source.event_id, PERIODIC);
-
-	/* source timer restart */
-	samsung_time_setup(timer_source.source_id, TCNT_MAX);
-	samsung_time_start(timer_source.source_id, PERIODIC);
-}
-
-void __init samsung_set_timer_source(enum samsung_timer_mode event,
-				 enum samsung_timer_mode source)
-{
-	s3c_device_timer[event].dev.bus = &platform_bus_type;
-	s3c_device_timer[source].dev.bus = &platform_bus_type;
-
-	timer_source.event_id = event;
-	timer_source.source_id = source;
-}
-
-static struct clock_event_device time_event_device = {
-	.name		= "samsung_event_timer",
-	.features	= CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT,
-	.rating		= 200,
-	.set_next_event	= samsung_set_next_event,
-	.set_mode	= samsung_set_mode,
-};
-
-static irqreturn_t samsung_clock_event_isr(int irq, void *dev_id)
-{
-	struct clock_event_device *evt = dev_id;
-
-	evt->event_handler(evt);
-
-	return IRQ_HANDLED;
-}
-
-static struct irqaction samsung_clock_event_irq = {
-	.name		= "samsung_time_irq",
-	.flags		= IRQF_DISABLED | IRQF_TIMER | IRQF_IRQPOLL,
-	.handler	= samsung_clock_event_isr,
-	.dev_id		= &time_event_device,
-};
-
-static void __init samsung_clockevent_init(void)
-{
-	unsigned long pclk;
-	unsigned long clock_rate;
-	unsigned int irq_number;
-	struct clk *tscaler;
-
-	pclk = clk_get_rate(timerclk);
-
-	tscaler = clk_get_parent(tdiv_event);
-
-	clk_set_rate(tscaler, pclk / TSCALER_DIV);
-	clk_set_rate(tdiv_event, pclk / TDIV);
-	clk_set_parent(tin_event, tdiv_event);
-
-	clock_rate = clk_get_rate(tin_event);
-	clock_count_per_tick = clock_rate / HZ;
-
-	time_event_device.cpumask = cpumask_of(0);
-	clockevents_config_and_register(&time_event_device, clock_rate, 1, -1);
-
-	irq_number = timer_source.event_id + IRQ_TIMER0;
-	setup_irq(irq_number, &samsung_clock_event_irq);
-}
-
-static void __iomem *samsung_timer_reg(void)
-{
-	unsigned long offset = 0;
-
-	switch (timer_source.source_id) {
-	case SAMSUNG_PWM0:
-	case SAMSUNG_PWM1:
-	case SAMSUNG_PWM2:
-	case SAMSUNG_PWM3:
-		offset = (timer_source.source_id * 0x0c) + 0x14;
-		break;
-
-	case SAMSUNG_PWM4:
-		offset = 0x40;
-		break;
-
-	default:
-		printk(KERN_ERR "Invalid Timer %d\n", timer_source.source_id);
-		return NULL;
-	}
-
-	return S3C_TIMERREG(offset);
-}
-
-/*
- * Override the global weak sched_clock symbol with this
- * local implementation which uses the clocksource to get some
- * better resolution when scheduling the kernel. We accept that
- * this wraps around for now, since it is just a relative time
- * stamp. (Inspired by U300 implementation.)
- */
-static u32 notrace samsung_read_sched_clock(void)
-{
-	void __iomem *reg = samsung_timer_reg();
-
-	if (!reg)
-		return 0;
-
-	return ~__raw_readl(reg);
-}
-
-static void __init samsung_clocksource_init(void)
-{
-	unsigned long pclk;
-	unsigned long clock_rate;
-
-	pclk = clk_get_rate(timerclk);
-
-	clk_set_rate(tdiv_source, pclk / TDIV);
-	clk_set_parent(tin_source, tdiv_source);
-
-	clock_rate = clk_get_rate(tin_source);
-
-	samsung_time_setup(timer_source.source_id, TCNT_MAX);
-	samsung_time_start(timer_source.source_id, PERIODIC);
-
-	setup_sched_clock(samsung_read_sched_clock, TSIZE, clock_rate);
-
-	if (clocksource_mmio_init(samsung_timer_reg(), "samsung_clocksource_timer",
-			clock_rate, 250, TSIZE, clocksource_mmio_readl_down))
-		panic("samsung_clocksource_timer: can't register clocksource\n");
-}
-
-static void __init samsung_timer_resources(void)
-{
-
-	unsigned long event_id = timer_source.event_id;
-	unsigned long source_id = timer_source.source_id;
-	char devname[15];
-
-	timerclk = clk_get(NULL, "timers");
-	if (IS_ERR(timerclk))
-		panic("failed to get timers clock for timer");
-
-	clk_enable(timerclk);
-
-	sprintf(devname, "s3c24xx-pwm.%lu", event_id);
-	s3c_device_timer[event_id].id = event_id;
-	s3c_device_timer[event_id].dev.init_name = devname;
-
-	tin_event = clk_get(&s3c_device_timer[event_id].dev, "pwm-tin");
-	if (IS_ERR(tin_event))
-		panic("failed to get pwm-tin clock for event timer");
-
-	tdiv_event = clk_get(&s3c_device_timer[event_id].dev, "pwm-tdiv");
-	if (IS_ERR(tdiv_event))
-		panic("failed to get pwm-tdiv clock for event timer");
-
-	clk_enable(tin_event);
-
-	sprintf(devname, "s3c24xx-pwm.%lu", source_id);
-	s3c_device_timer[source_id].id = source_id;
-	s3c_device_timer[source_id].dev.init_name = devname;
-
-	tin_source = clk_get(&s3c_device_timer[source_id].dev, "pwm-tin");
-	if (IS_ERR(tin_source))
-		panic("failed to get pwm-tin clock for source timer");
-
-	tdiv_source = clk_get(&s3c_device_timer[source_id].dev, "pwm-tdiv");
-	if (IS_ERR(tdiv_source))
-		panic("failed to get pwm-tdiv clock for source timer");
-
-	clk_enable(tin_source);
-}
-
-void __init samsung_timer_init(void)
-{
-	samsung_timer_resources();
-	samsung_clockevent_init();
-	samsung_clocksource_init();
-}
diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index e8c4532..dd20f6a 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -25,6 +25,13 @@ config DW_APB_TIMER_OF
 config ARMADA_370_XP_TIMER
 	bool
 
+config SAMSUNG_HRT
+	bool
+	depends on PLAT_SAMSUNG
+	select SAMSUNG_DEV_PWM
+	help
+	  Use the high resolution timer support on Samsung platforms.
+
 config SUNXI_TIMER
 	bool
 
diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index 1c1b15d..c0a1945 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -16,6 +16,7 @@ obj-$(CONFIG_CLKSRC_NOMADIK_MTU)	+= nomadik-mtu.o
 obj-$(CONFIG_CLKSRC_DBX500_PRCMU)	+= clksrc-dbx500-prcmu.o
 obj-$(CONFIG_ARMADA_370_XP_TIMER)	+= time-armada-370-xp.o
 obj-$(CONFIG_ARCH_BCM2835)	+= bcm2835_timer.o
+obj-$(CONFIG_SAMSUNG_HRT) 	+= samsung_pwm.o
 obj-$(CONFIG_SUNXI_TIMER)	+= sunxi_timer.o
 obj-$(CONFIG_ARCH_TEGRA)	+= tegra20_timer.o
 obj-$(CONFIG_VT8500_TIMER)	+= vt8500_timer.o
diff --git a/drivers/clocksource/samsung_pwm.c b/drivers/clocksource/samsung_pwm.c
new file mode 100644
index 0000000..f899cbc
--- /dev/null
+++ b/drivers/clocksource/samsung_pwm.c
@@ -0,0 +1,394 @@
+/*
+ * Copyright (c) 2011 Samsung Electronics Co., Ltd.
+ *		http://www.samsung.com/
+ *
+ * samsung - Common hr-timer support (s3c and s5p)
+ *
+ * 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/interrupt.h>
+#include <linux/irq.h>
+#include <linux/err.h>
+#include <linux/clk.h>
+#include <linux/clockchips.h>
+#include <linux/platform_device.h>
+
+#include <asm/smp_twd.h>
+#include <asm/mach/time.h>
+#include <asm/mach/arch.h>
+#include <asm/mach/map.h>
+#include <asm/sched_clock.h>
+
+#include <mach/map.h>
+#include <plat/devs.h>
+#include <plat/regs-timer.h>
+#include <plat/samsung-time.h>
+
+static struct clk *tin_event;
+static struct clk *tin_source;
+static struct clk *tdiv_event;
+static struct clk *tdiv_source;
+static struct clk *timerclk;
+static struct samsung_timer_source timer_source;
+static unsigned long clock_count_per_tick;
+static void samsung_timer_resume(void);
+
+static void samsung_time_stop(enum samsung_timer_mode mode)
+{
+	unsigned long tcon;
+
+	tcon = __raw_readl(S3C2410_TCON);
+
+	switch (mode) {
+	case SAMSUNG_PWM0:
+		tcon &= ~S3C2410_TCON_T0START;
+		break;
+
+	case SAMSUNG_PWM1:
+		tcon &= ~S3C2410_TCON_T1START;
+		break;
+
+	case SAMSUNG_PWM2:
+		tcon &= ~S3C2410_TCON_T2START;
+		break;
+
+	case SAMSUNG_PWM3:
+		tcon &= ~S3C2410_TCON_T3START;
+		break;
+
+	case SAMSUNG_PWM4:
+		tcon &= ~S3C2410_TCON_T4START;
+		break;
+
+	default:
+		printk(KERN_ERR "Invalid Timer %d\n", mode);
+		break;
+	}
+	__raw_writel(tcon, S3C2410_TCON);
+}
+
+static void samsung_time_setup(enum samsung_timer_mode mode, unsigned long tcnt)
+{
+	unsigned long tcon;
+
+	tcon = __raw_readl(S3C2410_TCON);
+
+	tcnt--;
+
+	switch (mode) {
+	case SAMSUNG_PWM0:
+		tcon &= ~(0x0f << 0);
+		tcon |= S3C2410_TCON_T0MANUALUPD;
+		break;
+
+	case SAMSUNG_PWM1:
+		tcon &= ~(0x0f << 8);
+		tcon |= S3C2410_TCON_T1MANUALUPD;
+		break;
+
+	case SAMSUNG_PWM2:
+		tcon &= ~(0x0f << 12);
+		tcon |= S3C2410_TCON_T2MANUALUPD;
+		break;
+
+	case SAMSUNG_PWM3:
+		tcon &= ~(0x0f << 16);
+		tcon |= S3C2410_TCON_T3MANUALUPD;
+		break;
+
+	case SAMSUNG_PWM4:
+		tcon &= ~(0x07 << 20);
+		tcon |= S3C2410_TCON_T4MANUALUPD;
+		break;
+
+	default:
+		printk(KERN_ERR "Invalid Timer %d\n", mode);
+		break;
+	}
+
+	__raw_writel(tcnt, S3C2410_TCNTB(mode));
+	__raw_writel(tcnt, S3C2410_TCMPB(mode));
+	__raw_writel(tcon, S3C2410_TCON);
+}
+
+static void samsung_time_start(enum samsung_timer_mode mode, bool periodic)
+{
+	unsigned long tcon;
+
+	tcon  = __raw_readl(S3C2410_TCON);
+
+	switch (mode) {
+	case SAMSUNG_PWM0:
+		tcon |= S3C2410_TCON_T0START;
+		tcon &= ~S3C2410_TCON_T0MANUALUPD;
+
+		if (periodic)
+			tcon |= S3C2410_TCON_T0RELOAD;
+		else
+			tcon &= ~S3C2410_TCON_T0RELOAD;
+		break;
+
+	case SAMSUNG_PWM1:
+		tcon |= S3C2410_TCON_T1START;
+		tcon &= ~S3C2410_TCON_T1MANUALUPD;
+
+		if (periodic)
+			tcon |= S3C2410_TCON_T1RELOAD;
+		else
+			tcon &= ~S3C2410_TCON_T1RELOAD;
+		break;
+
+	case SAMSUNG_PWM2:
+		tcon |= S3C2410_TCON_T2START;
+		tcon &= ~S3C2410_TCON_T2MANUALUPD;
+
+		if (periodic)
+			tcon |= S3C2410_TCON_T2RELOAD;
+		else
+			tcon &= ~S3C2410_TCON_T2RELOAD;
+		break;
+
+	case SAMSUNG_PWM3:
+		tcon |= S3C2410_TCON_T3START;
+		tcon &= ~S3C2410_TCON_T3MANUALUPD;
+
+		if (periodic)
+			tcon |= S3C2410_TCON_T3RELOAD;
+		else
+			tcon &= ~S3C2410_TCON_T3RELOAD;
+		break;
+
+	case SAMSUNG_PWM4:
+		tcon |= S3C2410_TCON_T4START;
+		tcon &= ~S3C2410_TCON_T4MANUALUPD;
+
+		if (periodic)
+			tcon |= S3C2410_TCON_T4RELOAD;
+		else
+			tcon &= ~S3C2410_TCON_T4RELOAD;
+		break;
+
+	default:
+		printk(KERN_ERR "Invalid Timer %d\n", mode);
+		break;
+	}
+	__raw_writel(tcon, S3C2410_TCON);
+}
+
+static int samsung_set_next_event(unsigned long cycles,
+				struct clock_event_device *evt)
+{
+	samsung_time_setup(timer_source.event_id, cycles);
+	samsung_time_start(timer_source.event_id, NON_PERIODIC);
+
+	return 0;
+}
+
+static void samsung_set_mode(enum clock_event_mode mode,
+				struct clock_event_device *evt)
+{
+	samsung_time_stop(timer_source.event_id);
+
+	switch (mode) {
+	case CLOCK_EVT_MODE_PERIODIC:
+		samsung_time_setup(timer_source.event_id, clock_count_per_tick);
+		samsung_time_start(timer_source.event_id, PERIODIC);
+		break;
+
+	case CLOCK_EVT_MODE_ONESHOT:
+		break;
+
+	case CLOCK_EVT_MODE_UNUSED:
+	case CLOCK_EVT_MODE_SHUTDOWN:
+		break;
+
+	case CLOCK_EVT_MODE_RESUME:
+		samsung_timer_resume();
+		break;
+	}
+}
+
+static void samsung_timer_resume(void)
+{
+	/* event timer restart */
+	samsung_time_setup(timer_source.event_id, clock_count_per_tick);
+	samsung_time_start(timer_source.event_id, PERIODIC);
+
+	/* source timer restart */
+	samsung_time_setup(timer_source.source_id, TCNT_MAX);
+	samsung_time_start(timer_source.source_id, PERIODIC);
+}
+
+void __init samsung_set_timer_source(enum samsung_timer_mode event,
+				 enum samsung_timer_mode source)
+{
+	s3c_device_timer[event].dev.bus = &platform_bus_type;
+	s3c_device_timer[source].dev.bus = &platform_bus_type;
+
+	timer_source.event_id = event;
+	timer_source.source_id = source;
+}
+
+static struct clock_event_device time_event_device = {
+	.name		= "samsung_event_timer",
+	.features	= CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT,
+	.rating		= 200,
+	.set_next_event	= samsung_set_next_event,
+	.set_mode	= samsung_set_mode,
+};
+
+static irqreturn_t samsung_clock_event_isr(int irq, void *dev_id)
+{
+	struct clock_event_device *evt = dev_id;
+
+	evt->event_handler(evt);
+
+	return IRQ_HANDLED;
+}
+
+static struct irqaction samsung_clock_event_irq = {
+	.name		= "samsung_time_irq",
+	.flags		= IRQF_DISABLED | IRQF_TIMER | IRQF_IRQPOLL,
+	.handler	= samsung_clock_event_isr,
+	.dev_id		= &time_event_device,
+};
+
+static void __init samsung_clockevent_init(void)
+{
+	unsigned long pclk;
+	unsigned long clock_rate;
+	unsigned int irq_number;
+	struct clk *tscaler;
+
+	pclk = clk_get_rate(timerclk);
+
+	tscaler = clk_get_parent(tdiv_event);
+
+	clk_set_rate(tscaler, pclk / TSCALER_DIV);
+	clk_set_rate(tdiv_event, pclk / TDIV);
+	clk_set_parent(tin_event, tdiv_event);
+
+	clock_rate = clk_get_rate(tin_event);
+	clock_count_per_tick = clock_rate / HZ;
+
+	time_event_device.cpumask = cpumask_of(0);
+	clockevents_config_and_register(&time_event_device, clock_rate, 1, -1);
+
+	irq_number = timer_source.event_id + IRQ_TIMER0;
+	setup_irq(irq_number, &samsung_clock_event_irq);
+}
+
+static void __iomem *samsung_timer_reg(void)
+{
+	unsigned long offset = 0;
+
+	switch (timer_source.source_id) {
+	case SAMSUNG_PWM0:
+	case SAMSUNG_PWM1:
+	case SAMSUNG_PWM2:
+	case SAMSUNG_PWM3:
+		offset = (timer_source.source_id * 0x0c) + 0x14;
+		break;
+
+	case SAMSUNG_PWM4:
+		offset = 0x40;
+		break;
+
+	default:
+		printk(KERN_ERR "Invalid Timer %d\n", timer_source.source_id);
+		return NULL;
+	}
+
+	return S3C_TIMERREG(offset);
+}
+
+/*
+ * Override the global weak sched_clock symbol with this
+ * local implementation which uses the clocksource to get some
+ * better resolution when scheduling the kernel. We accept that
+ * this wraps around for now, since it is just a relative time
+ * stamp. (Inspired by U300 implementation.)
+ */
+static u32 notrace samsung_read_sched_clock(void)
+{
+	void __iomem *reg = samsung_timer_reg();
+
+	if (!reg)
+		return 0;
+
+	return ~__raw_readl(reg);
+}
+
+static void __init samsung_clocksource_init(void)
+{
+	unsigned long pclk;
+	unsigned long clock_rate;
+
+	pclk = clk_get_rate(timerclk);
+
+	clk_set_rate(tdiv_source, pclk / TDIV);
+	clk_set_parent(tin_source, tdiv_source);
+
+	clock_rate = clk_get_rate(tin_source);
+
+	samsung_time_setup(timer_source.source_id, TCNT_MAX);
+	samsung_time_start(timer_source.source_id, PERIODIC);
+
+	setup_sched_clock(samsung_read_sched_clock, TSIZE, clock_rate);
+
+	if (clocksource_mmio_init(samsung_timer_reg(), "samsung_clocksource_timer",
+			clock_rate, 250, TSIZE, clocksource_mmio_readl_down))
+		panic("samsung_clocksource_timer: can't register clocksource\n");
+}
+
+static void __init samsung_timer_resources(void)
+{
+
+	unsigned long event_id = timer_source.event_id;
+	unsigned long source_id = timer_source.source_id;
+	char devname[15];
+
+	timerclk = clk_get(NULL, "timers");
+	if (IS_ERR(timerclk))
+		panic("failed to get timers clock for timer");
+
+	clk_enable(timerclk);
+
+	sprintf(devname, "s3c24xx-pwm.%lu", event_id);
+	s3c_device_timer[event_id].id = event_id;
+	s3c_device_timer[event_id].dev.init_name = devname;
+
+	tin_event = clk_get(&s3c_device_timer[event_id].dev, "pwm-tin");
+	if (IS_ERR(tin_event))
+		panic("failed to get pwm-tin clock for event timer");
+
+	tdiv_event = clk_get(&s3c_device_timer[event_id].dev, "pwm-tdiv");
+	if (IS_ERR(tdiv_event))
+		panic("failed to get pwm-tdiv clock for event timer");
+
+	clk_enable(tin_event);
+
+	sprintf(devname, "s3c24xx-pwm.%lu", source_id);
+	s3c_device_timer[source_id].id = source_id;
+	s3c_device_timer[source_id].dev.init_name = devname;
+
+	tin_source = clk_get(&s3c_device_timer[source_id].dev, "pwm-tin");
+	if (IS_ERR(tin_source))
+		panic("failed to get pwm-tin clock for source timer");
+
+	tdiv_source = clk_get(&s3c_device_timer[source_id].dev, "pwm-tdiv");
+	if (IS_ERR(tdiv_source))
+		panic("failed to get pwm-tdiv clock for source timer");
+
+	clk_enable(tin_source);
+}
+
+void __init samsung_timer_init(void)
+{
+	samsung_timer_resources();
+	samsung_clockevent_init();
+	samsung_clocksource_init();
+}
-- 
1.8.1.5



From t.figa at samsung.com  Fri Apr 12 15:17:18 2013
From: t.figa at samsung.com (Tomasz Figa)
Date: Fri, 12 Apr 2013 21:17:18 +0200
Subject: [PATCH v5 02/14] clocksource: samsung-pwm: Clean up platform header
In-Reply-To: <1365794250-14436-1-git-send-email-t.figa@samsung.com>
References: <1365794250-14436-1-git-send-email-t.figa@samsung.com>
Message-ID: <1365794250-14436-3-git-send-email-t.figa@samsung.com>

This patch moves private definitions out of the public platform header
and also cleans it up from unused and/or unnecessary ones.

Signed-off-by: Tomasz Figa <t.figa at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
---
 arch/arm/plat-samsung/include/plat/samsung-time.h | 11 -----------
 drivers/clocksource/samsung_pwm.c                 | 15 ++++++++++-----
 2 files changed, 10 insertions(+), 16 deletions(-)

diff --git a/arch/arm/plat-samsung/include/plat/samsung-time.h b/arch/arm/plat-samsung/include/plat/samsung-time.h
index 4cc99bb..ecc423c 100644
--- a/arch/arm/plat-samsung/include/plat/samsung-time.h
+++ b/arch/arm/plat-samsung/include/plat/samsung-time.h
@@ -22,14 +22,6 @@ enum samsung_timer_mode {
 	SAMSUNG_PWM4,
 };
 
-struct samsung_timer_source {
-	unsigned int event_id;
-	unsigned int source_id;
-};
-
-/* Be able to sleep for atleast 4 seconds (usually more) */
-#define SAMSUNG_TIMER_MIN_RANGE	4
-
 #if defined(CONFIG_ARCH_S3C24XX) || defined(CONFIG_ARCH_S5PC100)
 #define TCNT_MAX		0xffff
 #define TSCALER_DIV		25
@@ -42,9 +34,6 @@ struct samsung_timer_source {
 #define TSIZE			32
 #endif
 
-#define NON_PERIODIC		0
-#define PERIODIC		1
-
 extern void __init samsung_set_timer_source(enum samsung_timer_mode event,
 					enum samsung_timer_mode source);
 
diff --git a/drivers/clocksource/samsung_pwm.c b/drivers/clocksource/samsung_pwm.c
index f899cbc..974675b 100644
--- a/drivers/clocksource/samsung_pwm.c
+++ b/drivers/clocksource/samsung_pwm.c
@@ -27,6 +27,11 @@
 #include <plat/regs-timer.h>
 #include <plat/samsung-time.h>
 
+struct samsung_timer_source {
+	unsigned int event_id;
+	unsigned int source_id;
+};
+
 static struct clk *tin_event;
 static struct clk *tin_source;
 static struct clk *tdiv_event;
@@ -182,7 +187,7 @@ static int samsung_set_next_event(unsigned long cycles,
 				struct clock_event_device *evt)
 {
 	samsung_time_setup(timer_source.event_id, cycles);
-	samsung_time_start(timer_source.event_id, NON_PERIODIC);
+	samsung_time_start(timer_source.event_id, false);
 
 	return 0;
 }
@@ -195,7 +200,7 @@ static void samsung_set_mode(enum clock_event_mode mode,
 	switch (mode) {
 	case CLOCK_EVT_MODE_PERIODIC:
 		samsung_time_setup(timer_source.event_id, clock_count_per_tick);
-		samsung_time_start(timer_source.event_id, PERIODIC);
+		samsung_time_start(timer_source.event_id, true);
 		break;
 
 	case CLOCK_EVT_MODE_ONESHOT:
@@ -215,11 +220,11 @@ static void samsung_timer_resume(void)
 {
 	/* event timer restart */
 	samsung_time_setup(timer_source.event_id, clock_count_per_tick);
-	samsung_time_start(timer_source.event_id, PERIODIC);
+	samsung_time_start(timer_source.event_id, true);
 
 	/* source timer restart */
 	samsung_time_setup(timer_source.source_id, TCNT_MAX);
-	samsung_time_start(timer_source.source_id, PERIODIC);
+	samsung_time_start(timer_source.source_id, true);
 }
 
 void __init samsung_set_timer_source(enum samsung_timer_mode event,
@@ -335,7 +340,7 @@ static void __init samsung_clocksource_init(void)
 	clock_rate = clk_get_rate(tin_source);
 
 	samsung_time_setup(timer_source.source_id, TCNT_MAX);
-	samsung_time_start(timer_source.source_id, PERIODIC);
+	samsung_time_start(timer_source.source_id, true);
 
 	setup_sched_clock(samsung_read_sched_clock, TSIZE, clock_rate);
 
-- 
1.8.1.5



From t.figa at samsung.com  Fri Apr 12 15:17:19 2013
From: t.figa at samsung.com (Tomasz Figa)
Date: Fri, 12 Apr 2013 21:17:19 +0200
Subject: [PATCH v5 03/14] clocksource: samsung-pwm: Add infrastructure to share
 PWM hardware
In-Reply-To: <1365794250-14436-1-git-send-email-t.figa@samsung.com>
References: <1365794250-14436-1-git-send-email-t.figa@samsung.com>
Message-ID: <1365794250-14436-4-git-send-email-t.figa@samsung.com>

This patch extends samsung PWM clocksource driver with infrastructure
that allows sharing of PWM hardware between clocksource and PWM drivers.

Signed-off-by: Tomasz Figa <t.figa at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
---
 .../devicetree/bindings/pwm/pwm-samsung.txt        |  43 ++++
 drivers/clocksource/samsung_pwm.c                  | 250 +++++++++++++++++++++
 include/clocksource/samsung_pwm.h                  |  44 ++++
 3 files changed, 337 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pwm/pwm-samsung.txt
 create mode 100644 include/clocksource/samsung_pwm.h

diff --git a/Documentation/devicetree/bindings/pwm/pwm-samsung.txt b/Documentation/devicetree/bindings/pwm/pwm-samsung.txt
new file mode 100644
index 0000000..cc17c4c
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/pwm-samsung.txt
@@ -0,0 +1,43 @@
+* Samsung PWM timers
+
+Samsung SoCs contain PWM timer blocks which can be used for system clock source
+and clock event timers, as well as to drive SoC outputs with PWM signal. Each
+PWM timer block provides 5 PWM channels (not all of them can drive physical
+outputs - see SoC and board manual).
+
+Be aware that the clocksource driver supports only uniprocessor systems.
+
+Required properties:
+- compatible : should be one of following:
+    samsung,s3c2410-pwm - for 16-bit timers present on S3C24xx SoCs
+    samsung,s3c6400-pwm - for 32-bit timers present on S3C64xx SoCs
+    samsung,s5p6440-pwm - for 32-bit timers present on S5P64x0 SoCs
+    samsung,s5pc100-pwm - for 32-bit timers present on S5PC100, S5PV210,
+			  Exynos4210 rev0 SoCs
+    samsung,exynos4210-pwm - for 32-bit timers present on Exynos4210,
+                          Exynos4x12 and Exynos5250 SoCs
+- reg: base address and size of register area
+- interrupts: list of timer interrupts (one interrupt per timer, starting at
+  timer 0)
+- #pwm-cells: number of cells used for PWM specifier - must be 4
+   the specifier format is as follows:
+     - phandle to PWM controller node
+     - index of PWM channel (from 0 to 4)
+     - PWM signal period in nanoseconds
+     - bitmask of PWM flags:
+        0x1 - invert PWM signal
+
+Optional properties:
+- samsung,pwm-outputs: list of PWM channels used as PWM outputs on particular
+    platform - an array of up to 5 elements being indices of PWM channels
+    (from 0 to 4), the order does not matter.
+
+Example:
+	pwm at 7f006000 {
+		compatible = "samsung,s3c6400-pwm";
+		reg = <0x7f006000 0x1000>;
+		interrupt-parent = <&vic0>;
+		interrupts = <23>, <24>, <25>, <27>, <28>;
+		samsung,pwm-outputs = <0>, <1>;
+		#pwm-cells = <2>;
+	}
diff --git a/drivers/clocksource/samsung_pwm.c b/drivers/clocksource/samsung_pwm.c
index 974675b..7bbd55c 100644
--- a/drivers/clocksource/samsung_pwm.c
+++ b/drivers/clocksource/samsung_pwm.c
@@ -14,7 +14,15 @@
 #include <linux/err.h>
 #include <linux/clk.h>
 #include <linux/clockchips.h>
+#include <linux/list.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
 #include <linux/platform_device.h>
+#include <linux/slab.h>
+
+#include <clocksource/samsung_pwm.h>
 
 #include <asm/smp_twd.h>
 #include <asm/mach/time.h>
@@ -27,6 +35,248 @@
 #include <plat/regs-timer.h>
 #include <plat/samsung-time.h>
 
+/*
+ * PWM master driver
+ */
+
+struct samsung_pwm_drvdata {
+	struct samsung_pwm pwm;
+	struct platform_device *pdev;
+	struct device_node *of_node;
+	struct resource resource;
+	struct list_head list;
+};
+
+static LIST_HEAD(pwm_list);
+
+#ifdef CONFIG_OF
+static int samsung_pwm_parse_dt(struct samsung_pwm_drvdata *drvdata)
+{
+	struct samsung_pwm *pwm = &drvdata->pwm;
+	struct samsung_pwm_variant *variant = &pwm->variant;
+	struct device_node *np = drvdata->of_node;
+	struct property *prop;
+	const __be32 *cur;
+	u32 val;
+	int i;
+
+	for (i = 0; i < SAMSUNG_PWM_NUM; ++i)
+		pwm->irq[i] = irq_of_parse_and_map(np, i);
+
+	of_property_for_each_u32(np, "samsung,pwm-outputs", prop, cur, val) {
+		if (val >= SAMSUNG_PWM_NUM) {
+			pr_warning("%s: invalid channel index in samsung,pwm-outputs property\n",
+								__func__);
+			continue;
+		}
+		variant->output_mask |= 1 << val;
+	}
+
+	return 0;
+}
+
+static const struct samsung_pwm_variant s3c24xx_variant = {
+	.bits		= 16,
+	.div_base	= 1,
+	.has_tint_cstat	= false,
+	.tclk_mask	= (1 << 4),
+};
+
+static const struct samsung_pwm_variant s3c64xx_variant = {
+	.bits		= 32,
+	.div_base	= 0,
+	.has_tint_cstat	= true,
+	.tclk_mask	= (1 << 7) | (1 << 6) | (1 << 5),
+};
+
+static const struct samsung_pwm_variant s5p64x0_variant = {
+	.bits		= 32,
+	.div_base	= 0,
+	.has_tint_cstat	= true,
+	.tclk_mask	= 0,
+};
+
+static const struct samsung_pwm_variant s5p_variant = {
+	.bits		= 32,
+	.div_base	= 0,
+	.has_tint_cstat	= true,
+	.tclk_mask	= (1 << 5),
+};
+
+static const struct of_device_id samsung_pwm_matches[] = {
+	{ .compatible = "samsung,s3c2410-pwm", .data = &s3c24xx_variant, },
+	{ .compatible = "samsung,s3c6400-pwm", .data = &s3c64xx_variant, },
+	{ .compatible = "samsung,s5p6440-pwm", .data = &s5p64x0_variant, },
+	{ .compatible = "samsung,s5pc100-pwm", .data = &s5p_variant, },
+	{ .compatible = "samsung,exynos4210-pwm", .data = &s5p_variant, },
+	{},
+};
+
+static struct samsung_pwm_drvdata *samsung_pwm_alloc(
+		struct platform_device *pdev, struct device_node *of_node,
+		const struct samsung_pwm_variant *variant)
+{
+	struct samsung_pwm_drvdata *drvdata;
+
+	drvdata = kzalloc(sizeof(*drvdata), GFP_KERNEL);
+	if (!drvdata)
+		return NULL;
+
+	memcpy(&drvdata->pwm.variant, variant, sizeof(drvdata->pwm.variant));
+
+	spin_lock_init(&drvdata->pwm.slock);
+
+	drvdata->pdev = pdev;
+	drvdata->of_node = of_node;
+
+	return drvdata;
+}
+
+static struct samsung_pwm_drvdata *samsung_pwm_of_add(struct device_node *np)
+{
+	const struct samsung_pwm_variant *variant;
+	const struct of_device_id *match;
+	struct samsung_pwm_drvdata *pwm;
+	int ret;
+
+	if (!np) {
+		np = of_find_matching_node(NULL, samsung_pwm_matches);
+		if (!np) {
+			pr_err("%s: could not find PWM device\n", __func__);
+			return ERR_PTR(-ENODEV);
+		}
+	}
+
+	match = of_match_node(samsung_pwm_matches, np);
+	if (!match) {
+		pr_err("%s: failed to match given OF node\n", __func__);
+		return ERR_PTR(-EINVAL);
+	}
+	variant = match->data;
+
+	pwm = samsung_pwm_alloc(NULL, np, variant);
+	if (!pwm) {
+		pr_err("%s: could not allocate PWM device struct\n", __func__);
+		return ERR_PTR(-ENOMEM);
+	}
+
+	ret = of_address_to_resource(np, 0, &pwm->resource);
+	if (ret < 0) {
+		pr_err("%s: could not get IO resource\n", __func__);
+		goto err_free;
+	}
+
+	ret = samsung_pwm_parse_dt(pwm);
+	if (ret < 0) {
+		pr_err("%s: failed to parse device tree node\n", __func__);
+		goto err_free;
+	}
+
+	list_add_tail(&pwm->list, &pwm_list);
+
+	return pwm;
+
+err_free:
+	kfree(pwm);
+
+	return ERR_PTR(ret);
+}
+#else
+static struct samsung_pwm_drvdata *samsung_pwm_of_add(struct device_node *np)
+{
+	return ERR_PTR(-ENODEV);
+}
+#endif
+
+static struct samsung_pwm_drvdata *samsung_pwm_add(struct platform_device *pdev)
+{
+	struct samsung_pwm_variant *variant = pdev->dev.platform_data;
+	struct samsung_pwm_drvdata *pwm;
+	struct resource *res;
+	int i;
+
+	if (!variant) {
+		pr_err("%s: no platform data specified\n", __func__);
+		return ERR_PTR(-EINVAL);
+	}
+
+	pwm = samsung_pwm_alloc(pdev, pdev->dev.of_node, variant);
+	if (!pwm) {
+		pr_err("%s: could not allocate PWM device struct\n", __func__);
+		return ERR_PTR(-ENOMEM);
+	}
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	if (!res) {
+		pr_err("%s: could not get IO resource\n", __func__);
+		kfree(pwm);
+		return ERR_PTR(-EINVAL);
+	}
+	pwm->resource = *res;
+
+	for (i = 0; i < SAMSUNG_PWM_NUM; ++i)
+		pwm->pwm.irq[i] = platform_get_irq(pdev, i);
+
+	list_add_tail(&pwm->list, &pwm_list);
+
+	return pwm;
+}
+
+static struct samsung_pwm_drvdata *samsung_pwm_find(
+			struct platform_device *pdev, struct device_node *np)
+{
+	struct samsung_pwm_drvdata *pwm;
+
+	if (pdev)
+		np = pdev->dev.of_node;
+
+	list_for_each_entry(pwm, &pwm_list, list)
+		if ((np && pwm->of_node == np) || !pdev || pwm->pdev == pdev)
+			return pwm;
+
+	if (pdev && !np)
+		return samsung_pwm_add(pdev);
+
+	return samsung_pwm_of_add(np);
+}
+
+struct samsung_pwm *samsung_pwm_get(struct platform_device *pdev,
+						struct device_node *of_node)
+{
+	struct samsung_pwm_drvdata *pwm;
+	struct resource *res;
+
+	pwm = samsung_pwm_find(pdev, of_node);
+	if (IS_ERR(pwm)) {
+		pr_err("%s: failed to instantiate PWM device\n", __func__);
+		return &pwm->pwm;
+	}
+
+	if (pwm->pwm.base)
+		return &pwm->pwm;
+
+	res = request_mem_region(pwm->resource.start,
+				resource_size(&pwm->resource), "samsung-pwm");
+	if (!res) {
+		pr_err("%s: failed to request IO mem region\n", __func__);
+		return ERR_PTR(-ENOMEM);
+	}
+
+	pwm->pwm.base = ioremap(res->start, resource_size(res));
+	if (!pwm->pwm.base) {
+		pr_err("%s: failed to map PWM registers\n", __func__);
+		release_mem_region(res->start, resource_size(res));
+		return ERR_PTR(-ENOMEM);
+	}
+
+	return &pwm->pwm;
+}
+EXPORT_SYMBOL(samsung_pwm_get);
+
+/*
+ * Clocksource driver
+ */
+
 struct samsung_timer_source {
 	unsigned int event_id;
 	unsigned int source_id;
diff --git a/include/clocksource/samsung_pwm.h b/include/clocksource/samsung_pwm.h
new file mode 100644
index 0000000..d16415f
--- /dev/null
+++ b/include/clocksource/samsung_pwm.h
@@ -0,0 +1,44 @@
+/*
+ * Copyright (C) 2013 Samsung Electronics Co., Ltd.
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
+ */
+#ifndef __CLOCKSOURCE_SAMSUNG_PWM_H
+#define __CLOCKSOURCE_SAMSUNG_PWM_H
+
+#include <linux/spinlock.h>
+
+#define SAMSUNG_PWM_NUM		5
+
+struct platform_device;
+struct device_node;
+
+struct samsung_pwm_variant {
+	u8 bits;
+	u8 div_base;
+	u8 tclk_mask;
+	u8 output_mask;
+	bool has_tint_cstat;
+};
+
+struct samsung_pwm {
+	struct samsung_pwm_variant variant;
+	spinlock_t slock;
+	void __iomem *base;
+	int irq[SAMSUNG_PWM_NUM];
+};
+
+extern struct samsung_pwm *samsung_pwm_get(struct platform_device *,
+							struct device_node *);
+
+#endif /* __CLOCKSOURCE_SAMSUNG_PWM_H */
-- 
1.8.1.5



From t.figa at samsung.com  Fri Apr 12 15:17:20 2013
From: t.figa at samsung.com (Tomasz Figa)
Date: Fri, 12 Apr 2013 21:17:20 +0200
Subject: [PATCH v5 04/14] ARM: SAMSUNG: Unify base address definitions of timer
 block
In-Reply-To: <1365794250-14436-1-git-send-email-t.figa@samsung.com>
References: <1365794250-14436-1-git-send-email-t.figa@samsung.com>
Message-ID: <1365794250-14436-5-git-send-email-t.figa@samsung.com>

This patch makes all defintions of timer block base address use the same
prefix to allow using the common name to define platform device
resource.

Signed-off-by: Tomasz Figa <t.figa at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
---
 arch/arm/mach-exynos/include/mach/map.h  | 1 +
 arch/arm/mach-s3c24xx/include/mach/map.h | 2 ++
 arch/arm/mach-s3c64xx/include/mach/map.h | 1 +
 arch/arm/mach-s5p64x0/include/mach/map.h | 1 +
 arch/arm/mach-s5pc100/include/mach/map.h | 1 +
 arch/arm/mach-s5pv210/include/mach/map.h | 1 +
 6 files changed, 7 insertions(+)

diff --git a/arch/arm/mach-exynos/include/mach/map.h b/arch/arm/mach-exynos/include/mach/map.h
index 99e0a79..7167aba 100644
--- a/arch/arm/mach-exynos/include/mach/map.h
+++ b/arch/arm/mach-exynos/include/mach/map.h
@@ -272,6 +272,7 @@
 #define SAMSUNG_PA_ADC			EXYNOS4_PA_ADC
 #define SAMSUNG_PA_ADC1			EXYNOS4_PA_ADC1
 #define SAMSUNG_PA_KEYPAD		EXYNOS4_PA_KEYPAD
+#define SAMSUNG_PA_TIMER		EXYNOS4_PA_TIMER
 
 /* Compatibility UART */
 
diff --git a/arch/arm/mach-s3c24xx/include/mach/map.h b/arch/arm/mach-s3c24xx/include/mach/map.h
index 8ba381f..444793f 100644
--- a/arch/arm/mach-s3c24xx/include/mach/map.h
+++ b/arch/arm/mach-s3c24xx/include/mach/map.h
@@ -167,4 +167,6 @@
 #define S3C_PA_SPI0		S3C2443_PA_SPI0
 #define S3C_PA_SPI1		S3C2443_PA_SPI1
 
+#define SAMSUNG_PA_TIMER	S3C2410_PA_TIMER
+
 #endif /* __ASM_ARCH_MAP_H */
diff --git a/arch/arm/mach-s3c64xx/include/mach/map.h b/arch/arm/mach-s3c64xx/include/mach/map.h
index 8e2097b..f55ccb1 100644
--- a/arch/arm/mach-s3c64xx/include/mach/map.h
+++ b/arch/arm/mach-s3c64xx/include/mach/map.h
@@ -121,5 +121,6 @@
 #define SAMSUNG_PA_ADC		S3C64XX_PA_ADC
 #define SAMSUNG_PA_CFCON	S3C64XX_PA_CFCON
 #define SAMSUNG_PA_KEYPAD	S3C64XX_PA_KEYPAD
+#define SAMSUNG_PA_TIMER	S3C64XX_PA_TIMER
 
 #endif /* __ASM_ARCH_6400_MAP_H */
diff --git a/arch/arm/mach-s5p64x0/include/mach/map.h b/arch/arm/mach-s5p64x0/include/mach/map.h
index 0c0175d..50a6e96 100644
--- a/arch/arm/mach-s5p64x0/include/mach/map.h
+++ b/arch/arm/mach-s5p64x0/include/mach/map.h
@@ -76,6 +76,7 @@
 #define S5P_PA_TIMER		S5P64X0_PA_TIMER
 
 #define SAMSUNG_PA_ADC		S5P64X0_PA_ADC
+#define SAMSUNG_PA_TIMER	S5P64X0_PA_TIMER
 
 /* UART */
 
diff --git a/arch/arm/mach-s5pc100/include/mach/map.h b/arch/arm/mach-s5pc100/include/mach/map.h
index 54bc4f8..2550b61 100644
--- a/arch/arm/mach-s5pc100/include/mach/map.h
+++ b/arch/arm/mach-s5pc100/include/mach/map.h
@@ -116,6 +116,7 @@
 #define SAMSUNG_PA_ADC			S5PC100_PA_TSADC
 #define SAMSUNG_PA_CFCON		S5PC100_PA_CFCON
 #define SAMSUNG_PA_KEYPAD		S5PC100_PA_KEYPAD
+#define SAMSUNG_PA_TIMER		S5PC100_PA_TIMER
 
 #define S5PC100_VA_OTHERS		(S3C_VA_SYS + 0x10000)
 
diff --git a/arch/arm/mach-s5pv210/include/mach/map.h b/arch/arm/mach-s5pv210/include/mach/map.h
index b7c8a19..763929a 100644
--- a/arch/arm/mach-s5pv210/include/mach/map.h
+++ b/arch/arm/mach-s5pv210/include/mach/map.h
@@ -139,6 +139,7 @@
 #define SAMSUNG_PA_ADC			S5PV210_PA_ADC
 #define SAMSUNG_PA_CFCON		S5PV210_PA_CFCON
 #define SAMSUNG_PA_KEYPAD		S5PV210_PA_KEYPAD
+#define SAMSUNG_PA_TIMER		S5PV210_PA_TIMER
 
 /* UART */
 
-- 
1.8.1.5



From t.figa at samsung.com  Fri Apr 12 15:17:21 2013
From: t.figa at samsung.com (Tomasz Figa)
Date: Fri, 12 Apr 2013 21:17:21 +0200
Subject: [PATCH v5 05/14] ARM: SAMSUNG: Add new PWM platform device
In-Reply-To: <1365794250-14436-1-git-send-email-t.figa@samsung.com>
References: <1365794250-14436-1-git-send-email-t.figa@samsung.com>
Message-ID: <1365794250-14436-6-git-send-email-t.figa@samsung.com>

This patch adds new samsung_device_pwm platform device that represents
the whole PWM/timer block and includes memory and IRQ resources.

Signed-off-by: Tomasz Figa <t.figa at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
---
 arch/arm/plat-samsung/devs.c              | 16 ++++++++++++++++
 arch/arm/plat-samsung/include/plat/devs.h |  1 +
 2 files changed, 17 insertions(+)

diff --git a/arch/arm/plat-samsung/devs.c b/arch/arm/plat-samsung/devs.c
index e1124d9..bfae4dd 100644
--- a/arch/arm/plat-samsung/devs.c
+++ b/arch/arm/plat-samsung/devs.c
@@ -1168,6 +1168,22 @@ struct platform_device s3c_device_timer[] = {
 };
 #endif /* CONFIG_SAMSUNG_DEV_PWM */
 
+static struct resource samsung_pwm_resource[] = {
+	DEFINE_RES_IRQ(IRQ_TIMER0),
+	DEFINE_RES_IRQ(IRQ_TIMER1),
+	DEFINE_RES_IRQ(IRQ_TIMER2),
+	DEFINE_RES_IRQ(IRQ_TIMER3),
+	DEFINE_RES_IRQ(IRQ_TIMER4),
+	DEFINE_RES_MEM(SAMSUNG_PA_TIMER, SZ_4K),
+};
+
+struct platform_device samsung_device_pwm = {
+	.name		= "samsung-pwm",
+	.id		= -1,
+	.num_resources	= ARRAY_SIZE(samsung_pwm_resource),
+	.resource	= samsung_pwm_resource,
+};
+
 /* RTC */
 
 #ifdef CONFIG_PLAT_S3C24XX
diff --git a/arch/arm/plat-samsung/include/plat/devs.h b/arch/arm/plat-samsung/include/plat/devs.h
index 87d501f..0dc4ac4 100644
--- a/arch/arm/plat-samsung/include/plat/devs.h
+++ b/arch/arm/plat-samsung/include/plat/devs.h
@@ -134,6 +134,7 @@ extern struct platform_device exynos4_device_spdif;
 
 extern struct platform_device samsung_asoc_idma;
 extern struct platform_device samsung_device_keypad;
+extern struct platform_device samsung_device_pwm;
 
 /* s3c2440 specific devices */
 
-- 
1.8.1.5



From t.figa at samsung.com  Fri Apr 12 15:17:22 2013
From: t.figa at samsung.com (Tomasz Figa)
Date: Fri, 12 Apr 2013 21:17:22 +0200
Subject: [PATCH v5 06/14] ARM: SAMSUNG: Set PWM platform data
In-Reply-To: <1365794250-14436-1-git-send-email-t.figa@samsung.com>
References: <1365794250-14436-1-git-send-email-t.figa@samsung.com>
Message-ID: <1365794250-14436-7-git-send-email-t.figa@samsung.com>

This patch adds PWM platform data needed for legacy (non-DT) platforms
to handle SoC-specific bits of the PWM/timer block.

Signed-off-by: Tomasz Figa <t.figa at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
---
 arch/arm/mach-exynos/common.c  | 10 ++++++++++
 arch/arm/mach-s3c24xx/common.c | 10 ++++++++++
 arch/arm/mach-s3c64xx/common.c | 10 ++++++++++
 arch/arm/mach-s5p64x0/common.c | 10 ++++++++++
 arch/arm/mach-s5pc100/common.c | 10 ++++++++++
 arch/arm/mach-s5pv210/common.c | 10 ++++++++++
 6 files changed, 60 insertions(+)

diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
index a8570bf..b65229d 100644
--- a/arch/arm/mach-exynos/common.c
+++ b/arch/arm/mach-exynos/common.c
@@ -16,6 +16,7 @@
 #include <linux/io.h>
 #include <linux/device.h>
 #include <linux/gpio.h>
+#include <clocksource/samsung_pwm.h>
 #include <linux/sched.h>
 #include <linux/serial_core.h>
 #include <linux/of.h>
@@ -378,6 +379,13 @@ void __init exynos_init_io(struct map_desc *mach_desc, int size)
 	s3c_init_cpu(samsung_cpu_id, cpu_ids, ARRAY_SIZE(cpu_ids));
 }
 
+static struct samsung_pwm_variant exynos4_pwm_variant = {
+	.bits		= 32,
+	.div_base	= 0,
+	.has_tint_cstat	= true,
+	.tclk_mask	= (1 << 5),
+};
+
 static void __init exynos4_map_io(void)
 {
 	iotable_init(exynos4_iodesc, ARRAY_SIZE(exynos4_iodesc));
@@ -419,6 +427,8 @@ static void __init exynos4_map_io(void)
 	s5p_hdmi_setname("exynos4-hdmi");
 
 	s3c64xx_spi_setname("exynos4210-spi");
+
+	samsung_device_pwm.dev.platform_data = &exynos4_pwm_variant;
 }
 
 static void __init exynos5_map_io(void)
diff --git a/arch/arm/mach-s3c24xx/common.c b/arch/arm/mach-s3c24xx/common.c
index d97533d..a01cccb 100644
--- a/arch/arm/mach-s3c24xx/common.c
+++ b/arch/arm/mach-s3c24xx/common.c
@@ -27,6 +27,7 @@
 #include <linux/interrupt.h>
 #include <linux/ioport.h>
 #include <linux/serial_core.h>
+#include <clocksource/samsung_pwm.h>
 #include <linux/platform_device.h>
 #include <linux/delay.h>
 #include <linux/io.h>
@@ -216,6 +217,13 @@ static void s3c24xx_default_idle(void)
 		     S3C2410_CLKCON);
 }
 
+static struct samsung_pwm_variant s3c24xx_pwm_variant = {
+	.bits		= 16,
+	.div_base	= 1,
+	.has_tint_cstat	= false,
+	.tclk_mask	= (1 << 4),
+};
+
 void __init s3c24xx_init_io(struct map_desc *mach_desc, int size)
 {
 	arm_pm_idle = s3c24xx_default_idle;
@@ -232,6 +240,8 @@ void __init s3c24xx_init_io(struct map_desc *mach_desc, int size)
 	s3c24xx_init_cpu();
 
 	s3c_init_cpu(samsung_cpu_id, cpu_ids, ARRAY_SIZE(cpu_ids));
+
+	samsung_device_pwm.dev.platform_data = &s3c24xx_pwm_variant;
 }
 
 /* Serial port registrations */
diff --git a/arch/arm/mach-s3c64xx/common.c b/arch/arm/mach-s3c64xx/common.c
index 0b9c0ba..89d2823 100644
--- a/arch/arm/mach-s3c64xx/common.c
+++ b/arch/arm/mach-s3c64xx/common.c
@@ -26,6 +26,7 @@
 #include <linux/irq.h>
 #include <linux/gpio.h>
 #include <linux/irqchip/arm-vic.h>
+#include <clocksource/samsung_pwm.h>
 
 #include <asm/mach/arch.h>
 #include <asm/mach/map.h>
@@ -148,6 +149,13 @@ static struct device s3c64xx_dev = {
 	.bus	= &s3c64xx_subsys,
 };
 
+static struct samsung_pwm_variant s3c64xx_pwm_variant = {
+	.bits		= 32,
+	.div_base	= 0,
+	.has_tint_cstat	= true,
+	.tclk_mask	= (1 << 7) | (1 << 6) | (1 << 5),
+};
+
 /* read cpu identification code */
 
 void __init s3c64xx_init_io(struct map_desc *mach_desc, int size)
@@ -160,6 +168,8 @@ void __init s3c64xx_init_io(struct map_desc *mach_desc, int size)
 	s3c64xx_init_cpu();
 
 	s3c_init_cpu(samsung_cpu_id, cpu_ids, ARRAY_SIZE(cpu_ids));
+
+	samsung_device_pwm.dev.platform_data = &s3c64xx_pwm_variant;
 }
 
 static __init int s3c64xx_dev_init(void)
diff --git a/arch/arm/mach-s5p64x0/common.c b/arch/arm/mach-s5p64x0/common.c
index 8ae5800..cef1d3a 100644
--- a/arch/arm/mach-s5p64x0/common.c
+++ b/arch/arm/mach-s5p64x0/common.c
@@ -19,6 +19,7 @@
 #include <linux/io.h>
 #include <linux/device.h>
 #include <linux/serial_core.h>
+#include <clocksource/samsung_pwm.h>
 #include <linux/platform_device.h>
 #include <linux/sched.h>
 #include <linux/dma-mapping.h>
@@ -156,6 +157,13 @@ static void s5p64x0_idle(void)
 	cpu_do_idle();
 }
 
+static struct samsung_pwm_variant s5p64x0_pwm_variant = {
+	.bits		= 32,
+	.div_base	= 0,
+	.has_tint_cstat	= true,
+	.tclk_mask	= 0,
+};
+
 /*
  * s5p64x0_map_io
  *
@@ -173,6 +181,8 @@ void __init s5p64x0_init_io(struct map_desc *mach_desc, int size)
 	s5p_init_cpu(S5P64X0_SYS_ID);
 
 	s3c_init_cpu(samsung_cpu_id, cpu_ids, ARRAY_SIZE(cpu_ids));
+
+	samsung_device_pwm.dev.platform_data = &s5p64x0_pwm_variant;
 }
 
 void __init s5p6440_map_io(void)
diff --git a/arch/arm/mach-s5pc100/common.c b/arch/arm/mach-s5pc100/common.c
index cc6e561..3ccbd43 100644
--- a/arch/arm/mach-s5pc100/common.c
+++ b/arch/arm/mach-s5pc100/common.c
@@ -22,6 +22,7 @@
 #include <linux/io.h>
 #include <linux/device.h>
 #include <linux/serial_core.h>
+#include <clocksource/samsung_pwm.h>
 #include <linux/platform_device.h>
 #include <linux/sched.h>
 
@@ -131,6 +132,13 @@ static struct map_desc s5pc100_iodesc[] __initdata = {
 	}
 };
 
+static struct samsung_pwm_variant s5pc100_pwm_variant = {
+	.bits		= 32,
+	.div_base	= 0,
+	.has_tint_cstat	= true,
+	.tclk_mask	= (1 << 5),
+};
+
 /*
  * s5pc100_map_io
  *
@@ -148,6 +156,8 @@ void __init s5pc100_init_io(struct map_desc *mach_desc, int size)
 	s5p_init_cpu(S5P_VA_CHIPID);
 
 	s3c_init_cpu(samsung_cpu_id, cpu_ids, ARRAY_SIZE(cpu_ids));
+
+	samsung_device_pwm.dev.platform_data = &s5pc100_pwm_variant;
 }
 
 void __init s5pc100_map_io(void)
diff --git a/arch/arm/mach-s5pv210/common.c b/arch/arm/mach-s5pv210/common.c
index 9dfe93e..bfd918f 100644
--- a/arch/arm/mach-s5pv210/common.c
+++ b/arch/arm/mach-s5pv210/common.c
@@ -19,6 +19,7 @@
 #include <linux/clk.h>
 #include <linux/io.h>
 #include <linux/device.h>
+#include <clocksource/samsung_pwm.h>
 #include <linux/platform_device.h>
 #include <linux/sched.h>
 #include <linux/dma-mapping.h>
@@ -148,6 +149,13 @@ void s5pv210_restart(char mode, const char *cmd)
 	__raw_writel(0x1, S5P_SWRESET);
 }
 
+static struct samsung_pwm_variant s5pv210_pwm_variant = {
+	.bits		= 32,
+	.div_base	= 0,
+	.has_tint_cstat	= true,
+	.tclk_mask	= (1 << 5),
+};
+
 /*
  * s5pv210_map_io
  *
@@ -165,6 +173,8 @@ void __init s5pv210_init_io(struct map_desc *mach_desc, int size)
 	s5p_init_cpu(S5P_VA_CHIPID);
 
 	s3c_init_cpu(samsung_cpu_id, cpu_ids, ARRAY_SIZE(cpu_ids));
+
+	samsung_device_pwm.dev.platform_data = &s5pv210_pwm_variant;
 }
 
 void __init s5pv210_map_io(void)
-- 
1.8.1.5



From t.figa at samsung.com  Fri Apr 12 15:17:23 2013
From: t.figa at samsung.com (Tomasz Figa)
Date: Fri, 12 Apr 2013 21:17:23 +0200
Subject: [PATCH v5 07/14] clocksource: samsung-pwm: Use platform data to setup
 the clocksource
In-Reply-To: <1365794250-14436-1-git-send-email-t.figa@samsung.com>
References: <1365794250-14436-1-git-send-email-t.figa@samsung.com>
Message-ID: <1365794250-14436-8-git-send-email-t.figa@samsung.com>

This patch modifies the clocksource registration code to use data taken
from platform data instead of statically hardcoded defines.

Signed-off-by: Tomasz Figa <t.figa at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
---
 arch/arm/plat-samsung/devs.c                      |  7 +++
 arch/arm/plat-samsung/include/plat/samsung-time.h | 29 +++++-----
 drivers/clocksource/samsung_pwm.c                 | 70 ++++++++++++++++-------
 include/clocksource/samsung_pwm.h                 |  1 +
 4 files changed, 73 insertions(+), 34 deletions(-)

diff --git a/arch/arm/plat-samsung/devs.c b/arch/arm/plat-samsung/devs.c
index bfae4dd..fbfabd2 100644
--- a/arch/arm/plat-samsung/devs.c
+++ b/arch/arm/plat-samsung/devs.c
@@ -32,6 +32,8 @@
 #include <linux/platform_data/s3c-hsudc.h>
 #include <linux/platform_data/s3c-hsotg.h>
 
+#include <clocksource/samsung_pwm.h>
+
 #include <media/s5p_hdmi.h>
 
 #include <asm/irq.h>
@@ -1184,6 +1186,11 @@ struct platform_device samsung_device_pwm = {
 	.resource	= samsung_pwm_resource,
 };
 
+void samsung_timer_init(void)
+{
+	samsung_pwm_clocksource_init(&samsung_device_pwm);
+}
+
 /* RTC */
 
 #ifdef CONFIG_PLAT_S3C24XX
diff --git a/arch/arm/plat-samsung/include/plat/samsung-time.h b/arch/arm/plat-samsung/include/plat/samsung-time.h
index ecc423c..633c151 100644
--- a/arch/arm/plat-samsung/include/plat/samsung-time.h
+++ b/arch/arm/plat-samsung/include/plat/samsung-time.h
@@ -13,6 +13,10 @@
 #ifndef __ASM_PLAT_SAMSUNG_TIME_H
 #define __ASM_PLAT_SAMSUNG_TIME_H __FILE__
 
+#include <clocksource/samsung_pwm.h>
+
+#include <plat/devs.h>
+
 /* SAMSUNG HR-Timer Clock mode */
 enum samsung_timer_mode {
 	SAMSUNG_PWM0,
@@ -22,20 +26,17 @@ enum samsung_timer_mode {
 	SAMSUNG_PWM4,
 };
 
-#if defined(CONFIG_ARCH_S3C24XX) || defined(CONFIG_ARCH_S5PC100)
-#define TCNT_MAX		0xffff
-#define TSCALER_DIV		25
-#define TDIV			50
-#define TSIZE			16
-#else
-#define TCNT_MAX		0xffffffff
-#define TSCALER_DIV		2
-#define TDIV			2
-#define TSIZE			32
-#endif
-
-extern void __init samsung_set_timer_source(enum samsung_timer_mode event,
-					enum samsung_timer_mode source);
+static inline void samsung_set_timer_source(enum samsung_timer_mode event,
+						enum samsung_timer_mode source)
+{
+	struct samsung_pwm_variant *variant;
+
+	variant = samsung_device_pwm.dev.platform_data;
+	BUG_ON(!variant);
+
+	variant->output_mask = (1 << 5) - 1;
+	variant->output_mask &= ~((1 << event) | (1 << source));
+}
 
 extern void __init samsung_timer_init(void);
 
diff --git a/drivers/clocksource/samsung_pwm.c b/drivers/clocksource/samsung_pwm.c
index 7bbd55c..841d03c 100644
--- a/drivers/clocksource/samsung_pwm.c
+++ b/drivers/clocksource/samsung_pwm.c
@@ -280,8 +280,13 @@ EXPORT_SYMBOL(samsung_pwm_get);
 struct samsung_timer_source {
 	unsigned int event_id;
 	unsigned int source_id;
+	unsigned int tcnt_max;
+	unsigned int tscaler_div;
+	unsigned int tdiv;
 };
 
+static struct samsung_pwm *pwm;
+
 static struct clk *tin_event;
 static struct clk *tin_source;
 static struct clk *tdiv_event;
@@ -473,20 +478,10 @@ static void samsung_timer_resume(void)
 	samsung_time_start(timer_source.event_id, true);
 
 	/* source timer restart */
-	samsung_time_setup(timer_source.source_id, TCNT_MAX);
+	samsung_time_setup(timer_source.source_id, timer_source.tcnt_max);
 	samsung_time_start(timer_source.source_id, true);
 }
 
-void __init samsung_set_timer_source(enum samsung_timer_mode event,
-				 enum samsung_timer_mode source)
-{
-	s3c_device_timer[event].dev.bus = &platform_bus_type;
-	s3c_device_timer[source].dev.bus = &platform_bus_type;
-
-	timer_source.event_id = event;
-	timer_source.source_id = source;
-}
-
 static struct clock_event_device time_event_device = {
 	.name		= "samsung_event_timer",
 	.features	= CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT,
@@ -522,8 +517,9 @@ static void __init samsung_clockevent_init(void)
 
 	tscaler = clk_get_parent(tdiv_event);
 
-	clk_set_rate(tscaler, pclk / TSCALER_DIV);
-	clk_set_rate(tdiv_event, pclk / TDIV);
+	clk_set_rate(tscaler, pclk / timer_source.tscaler_div);
+	clk_set_rate(tdiv_event,
+			pclk / (timer_source.tdiv * timer_source.tscaler_div));
 	clk_set_parent(tin_event, tdiv_event);
 
 	clock_rate = clk_get_rate(tin_event);
@@ -532,7 +528,7 @@ static void __init samsung_clockevent_init(void)
 	time_event_device.cpumask = cpumask_of(0);
 	clockevents_config_and_register(&time_event_device, clock_rate, 1, -1);
 
-	irq_number = timer_source.event_id + IRQ_TIMER0;
+	irq_number = pwm->irq[timer_source.event_id];
 	setup_irq(irq_number, &samsung_clock_event_irq);
 }
 
@@ -579,23 +575,29 @@ static u32 notrace samsung_read_sched_clock(void)
 
 static void __init samsung_clocksource_init(void)
 {
+	void __iomem *reg = samsung_timer_reg();
 	unsigned long pclk;
 	unsigned long clock_rate;
+	int ret;
 
 	pclk = clk_get_rate(timerclk);
 
-	clk_set_rate(tdiv_source, pclk / TDIV);
+	clk_set_rate(tdiv_source,
+			pclk / (timer_source.tdiv * timer_source.tscaler_div));
 	clk_set_parent(tin_source, tdiv_source);
 
 	clock_rate = clk_get_rate(tin_source);
 
-	samsung_time_setup(timer_source.source_id, TCNT_MAX);
+	samsung_time_setup(timer_source.source_id, timer_source.tcnt_max);
 	samsung_time_start(timer_source.source_id, true);
 
-	setup_sched_clock(samsung_read_sched_clock, TSIZE, clock_rate);
+	setup_sched_clock(samsung_read_sched_clock,
+						pwm->variant.bits, clock_rate);
 
-	if (clocksource_mmio_init(samsung_timer_reg(), "samsung_clocksource_timer",
-			clock_rate, 250, TSIZE, clocksource_mmio_readl_down))
+	ret = clocksource_mmio_init(reg, "samsung_clocksource_timer",
+					clock_rate, 250, pwm->variant.bits,
+					clocksource_mmio_readl_down);
+	if (ret)
 		panic("samsung_clocksource_timer: can't register clocksource\n");
 }
 
@@ -639,10 +641,38 @@ static void __init samsung_timer_resources(void)
 		panic("failed to get pwm-tdiv clock for source timer");
 
 	clk_enable(tin_source);
+
+	timer_source.tcnt_max = (1UL << pwm->variant.bits) - 1;
+	if (pwm->variant.bits == 16) {
+		timer_source.tscaler_div = 25;
+		timer_source.tdiv = 2;
+	} else {
+		timer_source.tscaler_div = 2;
+		timer_source.tdiv = 1;
+	}
 }
 
-void __init samsung_timer_init(void)
+void __init samsung_pwm_clocksource_init(struct platform_device *pdev)
 {
+	u8 mask;
+	int channel;
+
+	pwm = samsung_pwm_get(pdev, NULL);
+	if (IS_ERR(pwm))
+		panic("failed to get PWM device");
+
+	mask = ~pwm->variant.output_mask & ((1 << SAMSUNG_PWM_NUM) - 1);
+	channel = fls(mask) - 1;
+	if (channel < 0)
+		panic("failed to find PWM channel for clocksource");
+	timer_source.source_id = channel;
+
+	mask &= ~(1 << channel);
+	channel = fls(mask) - 1;
+	if (channel < 0)
+		panic("failed to find PWM channel for clock event");
+	timer_source.event_id = channel;
+
 	samsung_timer_resources();
 	samsung_clockevent_init();
 	samsung_clocksource_init();
diff --git a/include/clocksource/samsung_pwm.h b/include/clocksource/samsung_pwm.h
index d16415f..a0449d5 100644
--- a/include/clocksource/samsung_pwm.h
+++ b/include/clocksource/samsung_pwm.h
@@ -38,6 +38,7 @@ struct samsung_pwm {
 	int irq[SAMSUNG_PWM_NUM];
 };
 
+extern void samsung_pwm_clocksource_init(struct platform_device *);
 extern struct samsung_pwm *samsung_pwm_get(struct platform_device *,
 							struct device_node *);
 
-- 
1.8.1.5



From t.figa at samsung.com  Fri Apr 12 15:17:24 2013
From: t.figa at samsung.com (Tomasz Figa)
Date: Fri, 12 Apr 2013 21:17:24 +0200
Subject: [PATCH v5 08/14] clocksource: samsung-pwm: Synchronize register
 accesses
In-Reply-To: <1365794250-14436-1-git-send-email-t.figa@samsung.com>
References: <1365794250-14436-1-git-send-email-t.figa@samsung.com>
Message-ID: <1365794250-14436-9-git-send-email-t.figa@samsung.com>

Since the registers of PWM block are shared between two drivers, it is
required to synchronize accesses to them. This patch introduces
necessary synchronization using spin_{un,}lock_irq{save,restore} and
a shared spinlock.

Signed-off-by: Tomasz Figa <t.figa at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
---
 drivers/clocksource/samsung_pwm.c | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/drivers/clocksource/samsung_pwm.c b/drivers/clocksource/samsung_pwm.c
index 841d03c..bddf9aa 100644
--- a/drivers/clocksource/samsung_pwm.c
+++ b/drivers/clocksource/samsung_pwm.c
@@ -299,6 +299,9 @@ static void samsung_timer_resume(void);
 static void samsung_time_stop(enum samsung_timer_mode mode)
 {
 	unsigned long tcon;
+	unsigned long flags;
+
+	spin_lock_irqsave(&pwm->slock, flags);
 
 	tcon = __raw_readl(S3C2410_TCON);
 
@@ -328,11 +331,16 @@ static void samsung_time_stop(enum samsung_timer_mode mode)
 		break;
 	}
 	__raw_writel(tcon, S3C2410_TCON);
+
+	spin_unlock_irqrestore(&pwm->slock, flags);
 }
 
 static void samsung_time_setup(enum samsung_timer_mode mode, unsigned long tcnt)
 {
 	unsigned long tcon;
+	unsigned long flags;
+
+	spin_lock_irqsave(&pwm->slock, flags);
 
 	tcon = __raw_readl(S3C2410_TCON);
 
@@ -372,11 +380,16 @@ static void samsung_time_setup(enum samsung_timer_mode mode, unsigned long tcnt)
 	__raw_writel(tcnt, S3C2410_TCNTB(mode));
 	__raw_writel(tcnt, S3C2410_TCMPB(mode));
 	__raw_writel(tcon, S3C2410_TCON);
+
+	spin_unlock_irqrestore(&pwm->slock, flags);
 }
 
 static void samsung_time_start(enum samsung_timer_mode mode, bool periodic)
 {
 	unsigned long tcon;
+	unsigned long flags;
+
+	spin_lock_irqsave(&pwm->slock, flags);
 
 	tcon  = __raw_readl(S3C2410_TCON);
 
@@ -436,6 +449,8 @@ static void samsung_time_start(enum samsung_timer_mode mode, bool periodic)
 		break;
 	}
 	__raw_writel(tcon, S3C2410_TCON);
+
+	spin_unlock_irqrestore(&pwm->slock, flags);
 }
 
 static int samsung_set_next_event(unsigned long cycles,
-- 
1.8.1.5



From t.figa at samsung.com  Fri Apr 12 15:17:25 2013
From: t.figa at samsung.com (Tomasz Figa)
Date: Fri, 12 Apr 2013 21:17:25 +0200
Subject: [PATCH v5 09/14] clocksource: samsung-pwm: Move IRQ mask/ack handling
 to the driver
In-Reply-To: <1365794250-14436-1-git-send-email-t.figa@samsung.com>
References: <1365794250-14436-1-git-send-email-t.figa@samsung.com>
Message-ID: <1365794250-14436-10-git-send-email-t.figa@samsung.com>

Since the clocksource driver is the only user of PWM timer interrupts,
there is no need to create an IRQ chip for handling them.

This patch changes the way of PWM timer interrupt handling to use
real VIC/GIC interrupt requests and handle PWM mask/ack register
internally in samsung-pwm clocksource driver.

Signed-off-by: Tomasz Figa <t.figa at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
---
 arch/arm/mach-exynos/include/mach/irqs.h  |  3 +--
 arch/arm/mach-s3c24xx/include/mach/irqs.h |  6 ++++++
 arch/arm/mach-s3c64xx/common.c            |  3 ---
 arch/arm/mach-s3c64xx/include/mach/irqs.h |  8 --------
 arch/arm/mach-s5p64x0/include/mach/irqs.h |  2 --
 arch/arm/mach-s5pc100/include/mach/irqs.h |  2 --
 arch/arm/mach-s5pv210/include/mach/irqs.h |  2 --
 arch/arm/plat-samsung/devs.c              | 20 ++++++++++----------
 arch/arm/plat-samsung/include/plat/irqs.h |  9 ---------
 arch/arm/plat-samsung/s5p-irq.c           |  2 --
 drivers/clocksource/samsung_pwm.c         | 10 ++++++++++
 11 files changed, 27 insertions(+), 40 deletions(-)

diff --git a/arch/arm/mach-exynos/include/mach/irqs.h b/arch/arm/mach-exynos/include/mach/irqs.h
index 35fe6d5..6fbe229 100644
--- a/arch/arm/mach-exynos/include/mach/irqs.h
+++ b/arch/arm/mach-exynos/include/mach/irqs.h
@@ -464,10 +464,9 @@
 #define S5P_EINT_BASE2			(S5P_EINT_BASE1 + 16)
 #define S5P_GPIOINT_BASE		(S5P_EINT_BASE1 + 32)
 #define IRQ_GPIO_END			(S5P_GPIOINT_BASE + S5P_GPIOINT_COUNT)
-#define IRQ_TIMER_BASE			(IRQ_GPIO_END + 64)
 
 /* Set the default NR_IRQS */
 
-#define NR_IRQS				(IRQ_TIMER_BASE + IRQ_TIMER_COUNT)
+#define NR_IRQS				(IRQ_GPIO_END + 64)
 
 #endif /* __ASM_ARCH_IRQS_H */
diff --git a/arch/arm/mach-s3c24xx/include/mach/irqs.h b/arch/arm/mach-s3c24xx/include/mach/irqs.h
index b6dd4cb..287545f 100644
--- a/arch/arm/mach-s3c24xx/include/mach/irqs.h
+++ b/arch/arm/mach-s3c24xx/include/mach/irqs.h
@@ -205,6 +205,12 @@
 #define IRQ_LCD_VSYNC		IRQ_S3C2443_LCD3
 #define IRQ_LCD_SYSTEM		IRQ_S3C2443_LCD2
 
+#define IRQ_TIMER0_VIC		IRQ_TIMER0
+#define IRQ_TIMER1_VIC		IRQ_TIMER1
+#define IRQ_TIMER2_VIC		IRQ_TIMER2
+#define IRQ_TIMER3_VIC		IRQ_TIMER3
+#define IRQ_TIMER4_VIC		IRQ_TIMER4
+
 #ifdef CONFIG_CPU_S3C2440
 #define IRQ_S3C244X_AC97 IRQ_S3C2440_AC97
 #else
diff --git a/arch/arm/mach-s3c64xx/common.c b/arch/arm/mach-s3c64xx/common.c
index 89d2823..4cb9afe6 100644
--- a/arch/arm/mach-s3c64xx/common.c
+++ b/arch/arm/mach-s3c64xx/common.c
@@ -198,9 +198,6 @@ void __init s3c64xx_init_irq(u32 vic0_valid, u32 vic1_valid)
 	/* initialise the pair of VICs */
 	vic_init(VA_VIC0, IRQ_VIC0_BASE, vic0_valid, IRQ_VIC0_RESUME);
 	vic_init(VA_VIC1, IRQ_VIC1_BASE, vic1_valid, IRQ_VIC1_RESUME);
-
-	/* add the timer sub-irqs */
-	s3c_init_vic_timer_irq(5, IRQ_TIMER0);
 }
 
 #define eint_offset(irq)	((irq) - IRQ_EINT(0))
diff --git a/arch/arm/mach-s3c64xx/include/mach/irqs.h b/arch/arm/mach-s3c64xx/include/mach/irqs.h
index 96d60e0..67bbd1d 100644
--- a/arch/arm/mach-s3c64xx/include/mach/irqs.h
+++ b/arch/arm/mach-s3c64xx/include/mach/irqs.h
@@ -107,14 +107,6 @@
 #define IRQ_TC			IRQ_PENDN
 #define IRQ_ADC			S3C64XX_IRQ_VIC1(31)
 
-#define S3C64XX_TIMER_IRQ(x)	S3C_IRQ(64 + (x))
-
-#define IRQ_TIMER0		S3C64XX_TIMER_IRQ(0)
-#define IRQ_TIMER1		S3C64XX_TIMER_IRQ(1)
-#define IRQ_TIMER2		S3C64XX_TIMER_IRQ(2)
-#define IRQ_TIMER3		S3C64XX_TIMER_IRQ(3)
-#define IRQ_TIMER4		S3C64XX_TIMER_IRQ(4)
-
 /* compatibility for device defines */
 
 #define IRQ_IIC1		IRQ_S3C6410_IIC1
diff --git a/arch/arm/mach-s5p64x0/include/mach/irqs.h b/arch/arm/mach-s5p64x0/include/mach/irqs.h
index 5b845e8..53982db 100644
--- a/arch/arm/mach-s5p64x0/include/mach/irqs.h
+++ b/arch/arm/mach-s5p64x0/include/mach/irqs.h
@@ -141,8 +141,6 @@
 
 #define IRQ_EINT_GROUP(grp, x)	(IRQ_EINT_GROUP##grp##_BASE + (x))
 
-#define IRQ_TIMER_BASE		(11)
-
 /* Set the default NR_IRQS */
 
 #define NR_IRQS			(IRQ_EINT_GROUP8_BASE + IRQ_EINT_GROUP8_NR + 1)
diff --git a/arch/arm/mach-s5pc100/include/mach/irqs.h b/arch/arm/mach-s5pc100/include/mach/irqs.h
index 2870f12..d2eb475 100644
--- a/arch/arm/mach-s5pc100/include/mach/irqs.h
+++ b/arch/arm/mach-s5pc100/include/mach/irqs.h
@@ -97,8 +97,6 @@
 #define IRQ_SDMFIQ		S5P_IRQ_VIC2(31)
 #define IRQ_VIC_END		S5P_IRQ_VIC2(31)
 
-#define IRQ_TIMER_BASE		(11)
-
 #define S5P_EINT_BASE1		(S5P_IRQ_VIC0(0))
 #define S5P_EINT_BASE2		(IRQ_VIC_END + 1)
 
diff --git a/arch/arm/mach-s5pv210/include/mach/irqs.h b/arch/arm/mach-s5pv210/include/mach/irqs.h
index e777e01..5e0de3a 100644
--- a/arch/arm/mach-s5pv210/include/mach/irqs.h
+++ b/arch/arm/mach-s5pv210/include/mach/irqs.h
@@ -118,8 +118,6 @@
 #define IRQ_MDNIE3		S5P_IRQ_VIC3(8)
 #define IRQ_VIC_END		S5P_IRQ_VIC3(31)
 
-#define IRQ_TIMER_BASE		(11)
-
 #define S5P_EINT_BASE1		(S5P_IRQ_VIC0(0))
 #define S5P_EINT_BASE2		(IRQ_VIC_END + 1)
 
diff --git a/arch/arm/plat-samsung/devs.c b/arch/arm/plat-samsung/devs.c
index fbfabd2..68b163a 100644
--- a/arch/arm/plat-samsung/devs.c
+++ b/arch/arm/plat-samsung/devs.c
@@ -1162,20 +1162,20 @@ arch_initcall(s5p_pmu_init);
  */
 
 struct platform_device s3c_device_timer[] = {
-	[0] = { DEFINE_S3C_TIMER(0, IRQ_TIMER0) },
-	[1] = { DEFINE_S3C_TIMER(1, IRQ_TIMER1) },
-	[2] = { DEFINE_S3C_TIMER(2, IRQ_TIMER2) },
-	[3] = { DEFINE_S3C_TIMER(3, IRQ_TIMER3) },
-	[4] = { DEFINE_S3C_TIMER(4, IRQ_TIMER4) },
+	[0] = { DEFINE_S3C_TIMER(0, IRQ_TIMER0_VIC) },
+	[1] = { DEFINE_S3C_TIMER(1, IRQ_TIMER1_VIC) },
+	[2] = { DEFINE_S3C_TIMER(2, IRQ_TIMER2_VIC) },
+	[3] = { DEFINE_S3C_TIMER(3, IRQ_TIMER3_VIC) },
+	[4] = { DEFINE_S3C_TIMER(4, IRQ_TIMER4_VIC) },
 };
 #endif /* CONFIG_SAMSUNG_DEV_PWM */
 
 static struct resource samsung_pwm_resource[] = {
-	DEFINE_RES_IRQ(IRQ_TIMER0),
-	DEFINE_RES_IRQ(IRQ_TIMER1),
-	DEFINE_RES_IRQ(IRQ_TIMER2),
-	DEFINE_RES_IRQ(IRQ_TIMER3),
-	DEFINE_RES_IRQ(IRQ_TIMER4),
+	DEFINE_RES_IRQ(IRQ_TIMER0_VIC),
+	DEFINE_RES_IRQ(IRQ_TIMER1_VIC),
+	DEFINE_RES_IRQ(IRQ_TIMER2_VIC),
+	DEFINE_RES_IRQ(IRQ_TIMER3_VIC),
+	DEFINE_RES_IRQ(IRQ_TIMER4_VIC),
 	DEFINE_RES_MEM(SAMSUNG_PA_TIMER, SZ_4K),
 };
 
diff --git a/arch/arm/plat-samsung/include/plat/irqs.h b/arch/arm/plat-samsung/include/plat/irqs.h
index df46b77..039001c 100644
--- a/arch/arm/plat-samsung/include/plat/irqs.h
+++ b/arch/arm/plat-samsung/include/plat/irqs.h
@@ -44,15 +44,6 @@
 #define S5P_IRQ_VIC2(x)		(S5P_VIC2_BASE + (x))
 #define S5P_IRQ_VIC3(x)		(S5P_VIC3_BASE + (x))
 
-#define S5P_TIMER_IRQ(x)	(IRQ_TIMER_BASE + (x))
-
-#define IRQ_TIMER0		S5P_TIMER_IRQ(0)
-#define IRQ_TIMER1		S5P_TIMER_IRQ(1)
-#define IRQ_TIMER2		S5P_TIMER_IRQ(2)
-#define IRQ_TIMER3		S5P_TIMER_IRQ(3)
-#define IRQ_TIMER4		S5P_TIMER_IRQ(4)
-#define IRQ_TIMER_COUNT		(5)
-
 #define IRQ_EINT(x)		((x) < 16 ? ((x) + S5P_EINT_BASE1) \
 					: ((x) - 16 + S5P_EINT_BASE2))
 
diff --git a/arch/arm/plat-samsung/s5p-irq.c b/arch/arm/plat-samsung/s5p-irq.c
index 103e371..ce8564d 100644
--- a/arch/arm/plat-samsung/s5p-irq.c
+++ b/arch/arm/plat-samsung/s5p-irq.c
@@ -29,6 +29,4 @@ void __init s5p_init_irq(u32 *vic, u32 num_vic)
 	for (irq = 0; irq < num_vic; irq++)
 		vic_init(VA_VIC(irq), VIC_BASE(irq), vic[irq], 0);
 #endif
-
-	s3c_init_vic_timer_irq(5, IRQ_TIMER0);
 }
diff --git a/drivers/clocksource/samsung_pwm.c b/drivers/clocksource/samsung_pwm.c
index bddf9aa..3219ecc 100644
--- a/drivers/clocksource/samsung_pwm.c
+++ b/drivers/clocksource/samsung_pwm.c
@@ -509,6 +509,11 @@ static irqreturn_t samsung_clock_event_isr(int irq, void *dev_id)
 {
 	struct clock_event_device *evt = dev_id;
 
+	if (pwm->variant.has_tint_cstat) {
+		u32 mask = (1 << timer_source.event_id);
+		writel(mask | (mask << 5), S3C64XX_TINT_CSTAT);
+	}
+
 	evt->event_handler(evt);
 
 	return IRQ_HANDLED;
@@ -545,6 +550,11 @@ static void __init samsung_clockevent_init(void)
 
 	irq_number = pwm->irq[timer_source.event_id];
 	setup_irq(irq_number, &samsung_clock_event_irq);
+
+	if (pwm->variant.has_tint_cstat) {
+		u32 mask = (1 << timer_source.event_id);
+		writel(mask | (mask << 5), S3C64XX_TINT_CSTAT);
+	}
 }
 
 static void __iomem *samsung_timer_reg(void)
-- 
1.8.1.5



From t.figa at samsung.com  Fri Apr 12 15:17:26 2013
From: t.figa at samsung.com (Tomasz Figa)
Date: Fri, 12 Apr 2013 21:17:26 +0200
Subject: [PATCH v5 10/14] ARM: SAMSUNG: Remove unused PWM timer IRQ chip code
In-Reply-To: <1365794250-14436-1-git-send-email-t.figa@samsung.com>
References: <1365794250-14436-1-git-send-email-t.figa@samsung.com>
Message-ID: <1365794250-14436-11-git-send-email-t.figa@samsung.com>

As the need for an IRQ chip handling PWM timer interrupt chaining is
gone now, this patch removes all the code made unnecessary.

Signed-off-by: Tomasz Figa <t.figa at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
---
 arch/arm/Kconfig                                   |  1 -
 arch/arm/mach-s3c64xx/common.c                     |  1 -
 arch/arm/plat-samsung/Kconfig                      |  6 --
 arch/arm/plat-samsung/Makefile                     |  1 -
 arch/arm/plat-samsung/include/plat/irq-vic-timer.h | 13 ---
 arch/arm/plat-samsung/irq-vic-timer.c              | 98 ----------------------
 arch/arm/plat-samsung/s5p-irq.c                    |  1 -
 7 files changed, 121 deletions(-)
 delete mode 100644 arch/arm/plat-samsung/include/plat/irq-vic-timer.h
 delete mode 100644 arch/arm/plat-samsung/irq-vic-timer.c

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index a957aa0..648eda3 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -806,7 +806,6 @@ config ARCH_S3C64XX
 	select S3C_GPIO_TRACK
 	select SAMSUNG_CLKSRC
 	select SAMSUNG_GPIOLIB_4BIT
-	select SAMSUNG_IRQ_VIC_TIMER
 	select USB_ARCH_HAS_OHCI
 	help
 	  Samsung S3C64XX series based systems
diff --git a/arch/arm/mach-s3c64xx/common.c b/arch/arm/mach-s3c64xx/common.c
index 4cb9afe6..e79ca92 100644
--- a/arch/arm/mach-s3c64xx/common.c
+++ b/arch/arm/mach-s3c64xx/common.c
@@ -42,7 +42,6 @@
 #include <plat/pm.h>
 #include <plat/gpio-cfg.h>
 #include <plat/irq-uart.h>
-#include <plat/irq-vic-timer.h>
 #include <plat/regs-irqtype.h>
 #include <plat/regs-serial.h>
 #include <plat/watchdog-reset.h>
diff --git a/arch/arm/plat-samsung/Kconfig b/arch/arm/plat-samsung/Kconfig
index 6f632ba..9951879 100644
--- a/arch/arm/plat-samsung/Kconfig
+++ b/arch/arm/plat-samsung/Kconfig
@@ -27,7 +27,6 @@ config PLAT_S5P
 	select S5P_GPIO_DRVSTR
 	select SAMSUNG_CLKSRC if !COMMON_CLK
 	select SAMSUNG_GPIOLIB_4BIT
-	select SAMSUNG_IRQ_VIC_TIMER
 	help
 	  Base platform code for Samsung's S5P series SoC.
 
@@ -79,11 +78,6 @@ config S5P_CLOCK
 
 # options for IRQ support
 
-config SAMSUNG_IRQ_VIC_TIMER
-       bool
-       help
-         Internal configuration to build the VIC timer interrupt code.
-
 config S5P_IRQ
 	def_bool (ARCH_S5P64X0 || ARCH_S5PC100 || ARCH_S5PV210 || ARCH_EXYNOS)
 	help
diff --git a/arch/arm/plat-samsung/Makefile b/arch/arm/plat-samsung/Makefile
index 87494e1..ae2a0fd 100644
--- a/arch/arm/plat-samsung/Makefile
+++ b/arch/arm/plat-samsung/Makefile
@@ -19,7 +19,6 @@ obj-$(CONFIG_SAMSUNG_CLOCK)	+= pwm-clock.o
 obj-$(CONFIG_SAMSUNG_CLKSRC)	+= clock-clksrc.o
 obj-$(CONFIG_S5P_CLOCK)		+= s5p-clock.o
 
-obj-$(CONFIG_SAMSUNG_IRQ_VIC_TIMER) += irq-vic-timer.o
 obj-$(CONFIG_S5P_IRQ)		+= s5p-irq.o
 obj-$(CONFIG_S5P_EXT_INT)	+= s5p-irq-eint.o
 obj-$(CONFIG_S5P_GPIO_INT)	+= s5p-irq-gpioint.o
diff --git a/arch/arm/plat-samsung/include/plat/irq-vic-timer.h b/arch/arm/plat-samsung/include/plat/irq-vic-timer.h
deleted file mode 100644
index 5b9c42f..0000000
--- a/arch/arm/plat-samsung/include/plat/irq-vic-timer.h
+++ /dev/null
@@ -1,13 +0,0 @@
-/* arch/arm/plat-samsung/include/plat/irq-vic-timer.h
- *
- * Copyright (c) 2010 Simtec Electronics
- *	Ben Dooks <ben at simtec.co.uk>
- *
- * Header file for Samsung SoC IRQ VIC timer
- *
- * 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.
-*/
-
-extern void s3c_init_vic_timer_irq(unsigned int num, unsigned int timer_irq);
diff --git a/arch/arm/plat-samsung/irq-vic-timer.c b/arch/arm/plat-samsung/irq-vic-timer.c
deleted file mode 100644
index f980cf3..0000000
--- a/arch/arm/plat-samsung/irq-vic-timer.c
+++ /dev/null
@@ -1,98 +0,0 @@
-/* arch/arm/plat-samsung/irq-vic-timer.c
- *	originally part of arch/arm/plat-s3c64xx/irq.c
- *
- * Copyright 2008 Openmoko, Inc.
- * Copyright 2008 Simtec Electronics
- *      Ben Dooks <ben at simtec.co.uk>
- *      http://armlinux.simtec.co.uk/
- *
- * S3C64XX - Interrupt handling
- *
- * 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/interrupt.h>
-#include <linux/irq.h>
-#include <linux/io.h>
-
-#include <mach/map.h>
-#include <plat/cpu.h>
-#include <plat/irq-vic-timer.h>
-#include <plat/regs-timer.h>
-
-#include <asm/mach/irq.h>
-
-static void s3c_irq_demux_vic_timer(unsigned int irq, struct irq_desc *desc)
-{
-	struct irq_chip *chip = irq_get_chip(irq);
-	chained_irq_enter(chip, desc);
-	generic_handle_irq((int)desc->irq_data.handler_data);
-	chained_irq_exit(chip, desc);
-}
-
-/* We assume the IRQ_TIMER0..IRQ_TIMER4 range is continuous. */
-static void s3c_irq_timer_ack(struct irq_data *d)
-{
-	struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
-	u32 mask = (1 << 5) << (d->irq - gc->irq_base);
-
-	irq_reg_writel(mask | gc->mask_cache, gc->reg_base);
-}
-
-/**
- * s3c_init_vic_timer_irq() - initialise timer irq chanined off VIC.\
- * @num: Number of timers to initialize
- * @timer_irq: Base IRQ number to be used for the timers.
- *
- * Register the necessary IRQ chaining and support for the timer IRQs
- * chained of the VIC.
- */
-void __init s3c_init_vic_timer_irq(unsigned int num, unsigned int timer_irq)
-{
-	unsigned int pirq[5] = { IRQ_TIMER0_VIC, IRQ_TIMER1_VIC, IRQ_TIMER2_VIC,
-				 IRQ_TIMER3_VIC, IRQ_TIMER4_VIC };
-	struct irq_chip_generic *s3c_tgc;
-	struct irq_chip_type *ct;
-	unsigned int i;
-
-#ifdef CONFIG_ARCH_EXYNOS
-	if (soc_is_exynos5250()) {
-		pirq[0] = EXYNOS5_IRQ_TIMER0_VIC;
-		pirq[1] = EXYNOS5_IRQ_TIMER1_VIC;
-		pirq[2] = EXYNOS5_IRQ_TIMER2_VIC;
-		pirq[3] = EXYNOS5_IRQ_TIMER3_VIC;
-		pirq[4] = EXYNOS5_IRQ_TIMER4_VIC;
-	} else {
-		pirq[0] = EXYNOS4_IRQ_TIMER0_VIC;
-		pirq[1] = EXYNOS4_IRQ_TIMER1_VIC;
-		pirq[2] = EXYNOS4_IRQ_TIMER2_VIC;
-		pirq[3] = EXYNOS4_IRQ_TIMER3_VIC;
-		pirq[4] = EXYNOS4_IRQ_TIMER4_VIC;
-	}
-#endif
-	s3c_tgc = irq_alloc_generic_chip("s3c-timer", 1, timer_irq,
-					 S3C64XX_TINT_CSTAT, handle_level_irq);
-
-	if (!s3c_tgc) {
-		pr_err("%s: irq_alloc_generic_chip for IRQ %d failed\n",
-		       __func__, timer_irq);
-		return;
-	}
-
-	ct = s3c_tgc->chip_types;
-	ct->chip.irq_mask = irq_gc_mask_clr_bit;
-	ct->chip.irq_unmask = irq_gc_mask_set_bit;
-	ct->chip.irq_ack = s3c_irq_timer_ack;
-	irq_setup_generic_chip(s3c_tgc, IRQ_MSK(num), IRQ_GC_INIT_MASK_CACHE,
-			       IRQ_NOREQUEST | IRQ_NOPROBE, 0);
-	/* Clear the upper bits of the mask_cache*/
-	s3c_tgc->mask_cache &= 0x1f;
-
-	for (i = 0; i < num; i++, timer_irq++) {
-		irq_set_chained_handler(pirq[i], s3c_irq_demux_vic_timer);
-		irq_set_handler_data(pirq[i], (void *)timer_irq);
-	}
-}
diff --git a/arch/arm/plat-samsung/s5p-irq.c b/arch/arm/plat-samsung/s5p-irq.c
index ce8564d..b1e2a82 100644
--- a/arch/arm/plat-samsung/s5p-irq.c
+++ b/arch/arm/plat-samsung/s5p-irq.c
@@ -18,7 +18,6 @@
 #include <mach/map.h>
 #include <plat/regs-timer.h>
 #include <plat/cpu.h>
-#include <plat/irq-vic-timer.h>
 
 void __init s5p_init_irq(u32 *vic, u32 num_vic)
 {
-- 
1.8.1.5



From t.figa at samsung.com  Fri Apr 12 15:17:27 2013
From: t.figa at samsung.com (Tomasz Figa)
Date: Fri, 12 Apr 2013 21:17:27 +0200
Subject: [PATCH v5 11/14] clocksource: samsung-pwm: Configure dividers directly
In-Reply-To: <1365794250-14436-1-git-send-email-t.figa@samsung.com>
References: <1365794250-14436-1-git-send-email-t.figa@samsung.com>
Message-ID: <1365794250-14436-12-git-send-email-t.figa@samsung.com>

Clock dividers present in the PWM blocks are used to generate signal for
PWM timers internally, so there is no need to export them using clock
API.

This patch moves handling of those dividers to the clocksource driver to
not use the clock API anymore.

Signed-off-by: Tomasz Figa <t.figa at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
---
 drivers/clocksource/samsung_pwm.c | 111 ++++++++++++++++++++------------------
 1 file changed, 60 insertions(+), 51 deletions(-)

diff --git a/drivers/clocksource/samsung_pwm.c b/drivers/clocksource/samsung_pwm.c
index 3219ecc..29b480a 100644
--- a/drivers/clocksource/samsung_pwm.c
+++ b/drivers/clocksource/samsung_pwm.c
@@ -277,6 +277,15 @@ EXPORT_SYMBOL(samsung_pwm_get);
  * Clocksource driver
  */
 
+#define REG_TCFG0			0x00
+#define REG_TCFG1			0x04
+
+#define TCFG0_PRESCALER_MASK		0xff
+#define TCFG0_PRESCALER1_SHIFT		8
+
+#define TCFG1_SHIFT(x)	  		((x) * 4)
+#define TCFG1_MUX_MASK	  		0xf
+
 struct samsung_timer_source {
 	unsigned int event_id;
 	unsigned int source_id;
@@ -286,16 +295,51 @@ struct samsung_timer_source {
 };
 
 static struct samsung_pwm *pwm;
-
-static struct clk *tin_event;
-static struct clk *tin_source;
-static struct clk *tdiv_event;
-static struct clk *tdiv_source;
 static struct clk *timerclk;
 static struct samsung_timer_source timer_source;
 static unsigned long clock_count_per_tick;
 static void samsung_timer_resume(void);
 
+static void samsung_timer_set_prescale(struct samsung_pwm *pwm,
+					unsigned int channel, u16 prescale)
+{
+	unsigned long flags;
+	u8 shift = 0;
+	u32 reg;
+
+	if (channel >= 2)
+		shift = TCFG0_PRESCALER1_SHIFT;
+
+	spin_lock_irqsave(&pwm->slock, flags);
+
+	reg = readl(pwm->base + REG_TCFG0);
+	reg &= ~(TCFG0_PRESCALER_MASK << shift);
+	reg |= (prescale - 1) << shift;
+	writel(reg, pwm->base + REG_TCFG0);
+
+	spin_unlock_irqrestore(&pwm->slock, flags);
+}
+
+static void samsung_timer_set_divisor(struct samsung_pwm *pwm,
+					unsigned int channel, u8 divisor)
+{
+	u8 shift = TCFG1_SHIFT(channel);
+	unsigned long flags;
+	u32 reg;
+	u8 bits;
+
+	bits = (fls(divisor) - 1) - pwm->variant.div_base;
+
+	spin_lock_irqsave(&pwm->slock, flags);
+
+	reg = readl(pwm->base + REG_TCFG1);
+	reg &= ~(TCFG1_MUX_MASK << shift);
+	reg |= bits << shift;
+	writel(reg, pwm->base + REG_TCFG1);
+
+	spin_unlock_irqrestore(&pwm->slock, flags);
+}
+
 static void samsung_time_stop(enum samsung_timer_mode mode)
 {
 	unsigned long tcon;
@@ -531,18 +575,15 @@ static void __init samsung_clockevent_init(void)
 	unsigned long pclk;
 	unsigned long clock_rate;
 	unsigned int irq_number;
-	struct clk *tscaler;
 
 	pclk = clk_get_rate(timerclk);
 
-	tscaler = clk_get_parent(tdiv_event);
-
-	clk_set_rate(tscaler, pclk / timer_source.tscaler_div);
-	clk_set_rate(tdiv_event,
-			pclk / (timer_source.tdiv * timer_source.tscaler_div));
-	clk_set_parent(tin_event, tdiv_event);
+	samsung_timer_set_prescale(pwm, timer_source.event_id,
+						timer_source.tscaler_div);
+	samsung_timer_set_divisor(pwm, timer_source.event_id,
+						timer_source.tdiv);
 
-	clock_rate = clk_get_rate(tin_event);
+	clock_rate = pclk / (timer_source.tscaler_div * timer_source.tdiv);
 	clock_count_per_tick = clock_rate / HZ;
 
 	time_event_device.cpumask = cpumask_of(0);
@@ -607,11 +648,12 @@ static void __init samsung_clocksource_init(void)
 
 	pclk = clk_get_rate(timerclk);
 
-	clk_set_rate(tdiv_source,
-			pclk / (timer_source.tdiv * timer_source.tscaler_div));
-	clk_set_parent(tin_source, tdiv_source);
+	samsung_timer_set_prescale(pwm, timer_source.source_id,
+						timer_source.tscaler_div);
+	samsung_timer_set_divisor(pwm, timer_source.source_id,
+						timer_source.tdiv);
 
-	clock_rate = clk_get_rate(tin_source);
+	clock_rate = pclk / (timer_source.tscaler_div * timer_source.tdiv);
 
 	samsung_time_setup(timer_source.source_id, timer_source.tcnt_max);
 	samsung_time_start(timer_source.source_id, true);
@@ -628,44 +670,11 @@ static void __init samsung_clocksource_init(void)
 
 static void __init samsung_timer_resources(void)
 {
-
-	unsigned long event_id = timer_source.event_id;
-	unsigned long source_id = timer_source.source_id;
-	char devname[15];
-
 	timerclk = clk_get(NULL, "timers");
 	if (IS_ERR(timerclk))
 		panic("failed to get timers clock for timer");
 
-	clk_enable(timerclk);
-
-	sprintf(devname, "s3c24xx-pwm.%lu", event_id);
-	s3c_device_timer[event_id].id = event_id;
-	s3c_device_timer[event_id].dev.init_name = devname;
-
-	tin_event = clk_get(&s3c_device_timer[event_id].dev, "pwm-tin");
-	if (IS_ERR(tin_event))
-		panic("failed to get pwm-tin clock for event timer");
-
-	tdiv_event = clk_get(&s3c_device_timer[event_id].dev, "pwm-tdiv");
-	if (IS_ERR(tdiv_event))
-		panic("failed to get pwm-tdiv clock for event timer");
-
-	clk_enable(tin_event);
-
-	sprintf(devname, "s3c24xx-pwm.%lu", source_id);
-	s3c_device_timer[source_id].id = source_id;
-	s3c_device_timer[source_id].dev.init_name = devname;
-
-	tin_source = clk_get(&s3c_device_timer[source_id].dev, "pwm-tin");
-	if (IS_ERR(tin_source))
-		panic("failed to get pwm-tin clock for source timer");
-
-	tdiv_source = clk_get(&s3c_device_timer[source_id].dev, "pwm-tdiv");
-	if (IS_ERR(tdiv_source))
-		panic("failed to get pwm-tdiv clock for source timer");
-
-	clk_enable(tin_source);
+	clk_prepare_enable(timerclk);
 
 	timer_source.tcnt_max = (1UL << pwm->variant.bits) - 1;
 	if (pwm->variant.bits == 16) {
-- 
1.8.1.5



From t.figa at samsung.com  Fri Apr 12 15:17:28 2013
From: t.figa at samsung.com (Tomasz Figa)
Date: Fri, 12 Apr 2013 21:17:28 +0200
Subject: [PATCH v5 12/14] clocksource: samsung-pwm: Do not use static mapping
 of registers
In-Reply-To: <1365794250-14436-1-git-send-email-t.figa@samsung.com>
References: <1365794250-14436-1-git-send-email-t.figa@samsung.com>
Message-ID: <1365794250-14436-13-git-send-email-t.figa@samsung.com>

This patch modifies the samsung-pwm clocksource driver to use registers
through the dynamic mapping created by the master driver, instead of
static, hardcoded mapping.

By the way, register definitions and accesses are cleaned up.

Signed-off-by: Tomasz Figa <t.figa at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
---
 drivers/clocksource/samsung_pwm.c | 190 ++++++++++----------------------------
 1 file changed, 50 insertions(+), 140 deletions(-)

diff --git a/drivers/clocksource/samsung_pwm.c b/drivers/clocksource/samsung_pwm.c
index 29b480a..99c376d 100644
--- a/drivers/clocksource/samsung_pwm.c
+++ b/drivers/clocksource/samsung_pwm.c
@@ -27,12 +27,9 @@
 #include <asm/smp_twd.h>
 #include <asm/mach/time.h>
 #include <asm/mach/arch.h>
-#include <asm/mach/map.h>
 #include <asm/sched_clock.h>
 
-#include <mach/map.h>
 #include <plat/devs.h>
-#include <plat/regs-timer.h>
 #include <plat/samsung-time.h>
 
 /*
@@ -279,6 +276,11 @@ EXPORT_SYMBOL(samsung_pwm_get);
 
 #define REG_TCFG0			0x00
 #define REG_TCFG1			0x04
+#define REG_TCON			0x08
+#define REG_TINT_CSTAT			0x44
+
+#define REG_TCNTB(chan)			(0x0c + 12 * (chan))
+#define REG_TCMPB(chan)			(0x10 + 12 * (chan))
 
 #define TCFG0_PRESCALER_MASK		0xff
 #define TCFG0_PRESCALER1_SHIFT		8
@@ -286,6 +288,11 @@ EXPORT_SYMBOL(samsung_pwm_get);
 #define TCFG1_SHIFT(x)	  		((x) * 4)
 #define TCFG1_MUX_MASK	  		0xf
 
+#define TCON_START(chan)		(1 << (4 * (chan) + 0))
+#define TCON_MANUALUPDATE(chan)		(1 << (4 * (chan) + 1))
+#define TCON_INVERT(chan)		(1 << (4 * (chan) + 2))
+#define TCON_AUTORELOAD(chan)		(1 << (4 * (chan) + 3))
+
 struct samsung_timer_source {
 	unsigned int event_id;
 	unsigned int source_id;
@@ -340,159 +347,69 @@ static void samsung_timer_set_divisor(struct samsung_pwm *pwm,
 	spin_unlock_irqrestore(&pwm->slock, flags);
 }
 
-static void samsung_time_stop(enum samsung_timer_mode mode)
+static void samsung_time_stop(unsigned int channel)
 {
 	unsigned long tcon;
 	unsigned long flags;
 
-	spin_lock_irqsave(&pwm->slock, flags);
-
-	tcon = __raw_readl(S3C2410_TCON);
-
-	switch (mode) {
-	case SAMSUNG_PWM0:
-		tcon &= ~S3C2410_TCON_T0START;
-		break;
-
-	case SAMSUNG_PWM1:
-		tcon &= ~S3C2410_TCON_T1START;
-		break;
-
-	case SAMSUNG_PWM2:
-		tcon &= ~S3C2410_TCON_T2START;
-		break;
+	if (channel > 0)
+		++channel;
 
-	case SAMSUNG_PWM3:
-		tcon &= ~S3C2410_TCON_T3START;
-		break;
-
-	case SAMSUNG_PWM4:
-		tcon &= ~S3C2410_TCON_T4START;
-		break;
+	spin_lock_irqsave(&pwm->slock, flags);
 
-	default:
-		printk(KERN_ERR "Invalid Timer %d\n", mode);
-		break;
-	}
-	__raw_writel(tcon, S3C2410_TCON);
+	tcon = __raw_readl(pwm->base + REG_TCON);
+	tcon &= ~TCON_START(channel);
+	__raw_writel(tcon, pwm->base + REG_TCON);
 
 	spin_unlock_irqrestore(&pwm->slock, flags);
 }
 
-static void samsung_time_setup(enum samsung_timer_mode mode, unsigned long tcnt)
+static void samsung_time_setup(unsigned int channel, unsigned long tcnt)
 {
 	unsigned long tcon;
 	unsigned long flags;
+	unsigned int tcon_chan = channel;
+
+	if (tcon_chan > 0)
+		++tcon_chan;
 
 	spin_lock_irqsave(&pwm->slock, flags);
 
-	tcon = __raw_readl(S3C2410_TCON);
+	tcon = __raw_readl(pwm->base + REG_TCON);
 
 	tcnt--;
 
-	switch (mode) {
-	case SAMSUNG_PWM0:
-		tcon &= ~(0x0f << 0);
-		tcon |= S3C2410_TCON_T0MANUALUPD;
-		break;
-
-	case SAMSUNG_PWM1:
-		tcon &= ~(0x0f << 8);
-		tcon |= S3C2410_TCON_T1MANUALUPD;
-		break;
-
-	case SAMSUNG_PWM2:
-		tcon &= ~(0x0f << 12);
-		tcon |= S3C2410_TCON_T2MANUALUPD;
-		break;
+	tcon &= ~(TCON_START(tcon_chan) | TCON_AUTORELOAD(tcon_chan));
+	tcon |= TCON_MANUALUPDATE(tcon_chan);
 
-	case SAMSUNG_PWM3:
-		tcon &= ~(0x0f << 16);
-		tcon |= S3C2410_TCON_T3MANUALUPD;
-		break;
-
-	case SAMSUNG_PWM4:
-		tcon &= ~(0x07 << 20);
-		tcon |= S3C2410_TCON_T4MANUALUPD;
-		break;
-
-	default:
-		printk(KERN_ERR "Invalid Timer %d\n", mode);
-		break;
-	}
-
-	__raw_writel(tcnt, S3C2410_TCNTB(mode));
-	__raw_writel(tcnt, S3C2410_TCMPB(mode));
-	__raw_writel(tcon, S3C2410_TCON);
+	__raw_writel(tcnt, pwm->base + REG_TCNTB(channel));
+	__raw_writel(tcnt, pwm->base + REG_TCMPB(channel));
+	__raw_writel(tcon, pwm->base + REG_TCON);
 
 	spin_unlock_irqrestore(&pwm->slock, flags);
 }
 
-static void samsung_time_start(enum samsung_timer_mode mode, bool periodic)
+static void samsung_time_start(unsigned int channel, bool periodic)
 {
 	unsigned long tcon;
 	unsigned long flags;
 
-	spin_lock_irqsave(&pwm->slock, flags);
-
-	tcon  = __raw_readl(S3C2410_TCON);
-
-	switch (mode) {
-	case SAMSUNG_PWM0:
-		tcon |= S3C2410_TCON_T0START;
-		tcon &= ~S3C2410_TCON_T0MANUALUPD;
-
-		if (periodic)
-			tcon |= S3C2410_TCON_T0RELOAD;
-		else
-			tcon &= ~S3C2410_TCON_T0RELOAD;
-		break;
-
-	case SAMSUNG_PWM1:
-		tcon |= S3C2410_TCON_T1START;
-		tcon &= ~S3C2410_TCON_T1MANUALUPD;
-
-		if (periodic)
-			tcon |= S3C2410_TCON_T1RELOAD;
-		else
-			tcon &= ~S3C2410_TCON_T1RELOAD;
-		break;
-
-	case SAMSUNG_PWM2:
-		tcon |= S3C2410_TCON_T2START;
-		tcon &= ~S3C2410_TCON_T2MANUALUPD;
+	if (channel > 0)
+		++channel;
 
-		if (periodic)
-			tcon |= S3C2410_TCON_T2RELOAD;
-		else
-			tcon &= ~S3C2410_TCON_T2RELOAD;
-		break;
+	spin_lock_irqsave(&pwm->slock, flags);
 
-	case SAMSUNG_PWM3:
-		tcon |= S3C2410_TCON_T3START;
-		tcon &= ~S3C2410_TCON_T3MANUALUPD;
+	tcon = __raw_readl(pwm->base + REG_TCON);
 
-		if (periodic)
-			tcon |= S3C2410_TCON_T3RELOAD;
-		else
-			tcon &= ~S3C2410_TCON_T3RELOAD;
-		break;
+	tcon &= ~TCON_MANUALUPDATE(channel);
+	tcon |= TCON_START(channel);
 
-	case SAMSUNG_PWM4:
-		tcon |= S3C2410_TCON_T4START;
-		tcon &= ~S3C2410_TCON_T4MANUALUPD;
+	if (periodic)
+		tcon |= TCON_AUTORELOAD(channel);
+	else
+		tcon &= ~TCON_AUTORELOAD(channel);
 
-		if (periodic)
-			tcon |= S3C2410_TCON_T4RELOAD;
-		else
-			tcon &= ~S3C2410_TCON_T4RELOAD;
-		break;
-
-	default:
-		printk(KERN_ERR "Invalid Timer %d\n", mode);
-		break;
-	}
-	__raw_writel(tcon, S3C2410_TCON);
+	__raw_writel(tcon, pwm->base + REG_TCON);
 
 	spin_unlock_irqrestore(&pwm->slock, flags);
 }
@@ -555,7 +472,7 @@ static irqreturn_t samsung_clock_event_isr(int irq, void *dev_id)
 
 	if (pwm->variant.has_tint_cstat) {
 		u32 mask = (1 << timer_source.event_id);
-		writel(mask | (mask << 5), S3C64XX_TINT_CSTAT);
+		writel(mask | (mask << 5), pwm->base + REG_TINT_CSTAT);
 	}
 
 	evt->event_handler(evt);
@@ -594,32 +511,25 @@ static void __init samsung_clockevent_init(void)
 
 	if (pwm->variant.has_tint_cstat) {
 		u32 mask = (1 << timer_source.event_id);
-		writel(mask | (mask << 5), S3C64XX_TINT_CSTAT);
+		writel(mask | (mask << 5), pwm->base + REG_TINT_CSTAT);
 	}
 }
 
 static void __iomem *samsung_timer_reg(void)
 {
-	unsigned long offset = 0;
-
 	switch (timer_source.source_id) {
-	case SAMSUNG_PWM0:
-	case SAMSUNG_PWM1:
-	case SAMSUNG_PWM2:
-	case SAMSUNG_PWM3:
-		offset = (timer_source.source_id * 0x0c) + 0x14;
-		break;
+	case 0:
+	case 1:
+	case 2:
+	case 3:
+		return pwm->base + timer_source.source_id * 0x0c + 0x14;
 
-	case SAMSUNG_PWM4:
-		offset = 0x40;
-		break;
+	case 4:
+		return pwm->base + 0x40;
 
 	default:
-		printk(KERN_ERR "Invalid Timer %d\n", timer_source.source_id);
-		return NULL;
+		BUG();
 	}
-
-	return S3C_TIMERREG(offset);
 }
 
 /*
-- 
1.8.1.5



From t.figa at samsung.com  Fri Apr 12 15:17:29 2013
From: t.figa at samsung.com (Tomasz Figa)
Date: Fri, 12 Apr 2013 21:17:29 +0200
Subject: [PATCH v5 13/14] clocksource: samsung-pwm: Drop unnecessary includes
In-Reply-To: <1365794250-14436-1-git-send-email-t.figa@samsung.com>
References: <1365794250-14436-1-git-send-email-t.figa@samsung.com>
Message-ID: <1365794250-14436-14-git-send-email-t.figa@samsung.com>

This patch removes unneccessary header inclusions from the samsung-pwm
clocksource driver.

Signed-off-by: Tomasz Figa <t.figa at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
---
 drivers/clocksource/samsung_pwm.c | 6 ------
 1 file changed, 6 deletions(-)

diff --git a/drivers/clocksource/samsung_pwm.c b/drivers/clocksource/samsung_pwm.c
index 99c376d..b816b65 100644
--- a/drivers/clocksource/samsung_pwm.c
+++ b/drivers/clocksource/samsung_pwm.c
@@ -24,14 +24,8 @@
 
 #include <clocksource/samsung_pwm.h>
 
-#include <asm/smp_twd.h>
-#include <asm/mach/time.h>
-#include <asm/mach/arch.h>
 #include <asm/sched_clock.h>
 
-#include <plat/devs.h>
-#include <plat/samsung-time.h>
-
 /*
  * PWM master driver
  */
-- 
1.8.1.5



From t.figa at samsung.com  Fri Apr 12 15:17:30 2013
From: t.figa at samsung.com (Tomasz Figa)
Date: Fri, 12 Apr 2013 21:17:30 +0200
Subject: [PATCH v5 14/14] clocksource: samsung-pwm: Prepare for
 clocksource_of_init
In-Reply-To: <1365794250-14436-1-git-send-email-t.figa@samsung.com>
References: <1365794250-14436-1-git-send-email-t.figa@samsung.com>
Message-ID: <1365794250-14436-15-git-send-email-t.figa@samsung.com>

This patch adds support for clocksource instantiation using
clocksource_of_init, by declaring OF clocksources with
CLOCKSOURCE_OF_DECLARE() macro.

Signed-off-by: Tomasz Figa <t.figa at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
---
 drivers/clocksource/samsung_pwm.c | 23 +++++++++++++++++++++--
 1 file changed, 21 insertions(+), 2 deletions(-)

diff --git a/drivers/clocksource/samsung_pwm.c b/drivers/clocksource/samsung_pwm.c
index b816b65..a12ee08 100644
--- a/drivers/clocksource/samsung_pwm.c
+++ b/drivers/clocksource/samsung_pwm.c
@@ -590,12 +590,13 @@ static void __init samsung_timer_resources(void)
 	}
 }
 
-void __init samsung_pwm_clocksource_init(struct platform_device *pdev)
+static void __init __samsung_pwm_clocksource_init(
+			struct platform_device *pdev, struct device_node *np)
 {
 	u8 mask;
 	int channel;
 
-	pwm = samsung_pwm_get(pdev, NULL);
+	pwm = samsung_pwm_get(pdev, np);
 	if (IS_ERR(pwm))
 		panic("failed to get PWM device");
 
@@ -615,3 +616,21 @@ void __init samsung_pwm_clocksource_init(struct platform_device *pdev)
 	samsung_clockevent_init();
 	samsung_clocksource_init();
 }
+
+static void __init samsung_pwm_clocksource_init_of(struct device_node *np)
+{
+	__samsung_pwm_clocksource_init(NULL, np);
+}
+CLOCKSOURCE_OF_DECLARE(s3c2410_pwm, "samsung,s3c2410-pwm",
+					samsung_pwm_clocksource_init_of);
+CLOCKSOURCE_OF_DECLARE(s3c6400_pwm, "samsung,s3c6400-pwm",
+					samsung_pwm_clocksource_init_of);
+CLOCKSOURCE_OF_DECLARE(s5p6440_pwm, "samsung,s5p6440-pwm",
+					samsung_pwm_clocksource_init_of);
+CLOCKSOURCE_OF_DECLARE(s5pc100_pwm, "samsung,s5pc100-pwm",
+					samsung_pwm_clocksource_init_of);
+
+void __init samsung_pwm_clocksource_init(struct platform_device *pdev)
+{
+	__samsung_pwm_clocksource_init(pdev, NULL);
+}
-- 
1.8.1.5



From sebastian.hesselbarth at gmail.com  Fri Apr 12 15:24:16 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Fri, 12 Apr 2013 21:24:16 +0200
Subject: [PATCH] clk: si5351: Add gapless tuning for SI5351 PLL
In-Reply-To: <20130412183809.6507.27844@quantum>
References: <1365495975-792-1-git-send-email-michal.bachraty@streamunlimited.com>
 <20130412183809.6507.27844@quantum>
Message-ID: <51685F60.9010802@gmail.com>

On 04/12/2013 08:38 PM, Mike Turquette wrote:
> Quoting Michal Bachraty (2013-04-09 01:26:15)
>> For gapless tuning, there is no need for PLL reset and clkout power-down
>> when tuning output. "silabs,gapless-tuning" parameter enables gapless tuning
>> for specific clock output.
>>
>> Signed-off-by: Michal Bachraty<michal.bachraty at streamunlimited.com>
>
> Hi Michal,
>
> This did not apply cleanly on the latest (v8) si5351 clk driver.  Can
> you refresh it?  I do not plan on taking any more patches for 3.10 after
> 3.9-rc7 drops (likely on Sunday or Monday).  So this patch may need to
> wait until after the merge window.

Mike,

I have integrated the above function into clk-si5351 during development
(see clk-si5351 changelog from v6->v7). I think we can drop this patch,
as Michal added his Tested-by to clk-si5351.

Regards,
   Sebastian


From lars at metafoo.de  Fri Apr 12 15:27:27 2013
From: lars at metafoo.de (Lars-Peter Clausen)
Date: Fri, 12 Apr 2013 21:27:27 +0200
Subject: [alsa-devel] [PATCH 20/30] ASoC: samsung: convert to dmaengine API
In-Reply-To: <201304111647.17796.arnd@arndb.de>
References: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
 <1365638712-1028578-21-git-send-email-arnd@arndb.de>
 <20130411142706.GB24971@opensource.wolfsonmicro.com>
 <201304111647.17796.arnd@arndb.de>
Message-ID: <5168601F.2070409@metafoo.de>

On 04/11/2013 04:47 PM, Arnd Bergmann wrote:
> On Thursday 11 April 2013, Mark Brown wrote:
>>
>> On Thu, Apr 11, 2013 at 02:05:02AM +0200, Arnd Bergmann wrote:
>>> In order to build the exynos kernel with CONFIG_ARCH_MULTIPLATFORM,
>>> we must convert all users of the Samsung private DMA interface to
>>> the generic dmaengine API. This version of the patch adds the
>>> generic dmaengine API as an alternative to the existing samsung
>>> specific one. Once all the older platforms provide support for
>>> the common dmaengine interfaces, we can remove the old code.
>>
>> There's generic ASoC dmaengine code which should be used instead of open
>> coding this.  Lars-Peter Clausen and Lee Jones have been working on
>> making this a totally generic driver, right now it's a library.
> 
> Ok, I see. I'll drop this patch from my series then and will let someone
> else handle this driver in 3.11. We can probably live without sound support
> in 3.10 when running a multiplatform kernel, and it will keep working
> for exynos-only kernels without the patch.

I actually had a look at how the Samsung PCM driver a couple of days back,
but I didn't fully grasp how things work with the secondary TX channel for
the i2s driver and to make it work with the generic dmaengine PCM driver.
The code handling this in the i2s driver seems to be rather messy with lots
of ifs and elses. Also things would have would be a lot easier if the dt
bindings had used two subnodes each with their own 'dmas' property.

- Lars



From festevam at gmail.com  Fri Apr 12 16:01:03 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Fri, 12 Apr 2013 17:01:03 -0300
Subject: [PATCH v2 1/1 net] enet: fec: fix fail resume from suspend state
In-Reply-To: <51682911.2040100@tqsc.de>
References: <1364350323-2488-1-git-send-email-Frank.Li@freescale.com>
 <CAOMZO5A9Tc_n8OGgxxw0ZE9xGOPjsYvyqVZtjWwTRn9as3eKCw@mail.gmail.com>
 <51682911.2040100@tqsc.de>
Message-ID: <CAOMZO5BQffpdQtwh7kYsPy9ymCh=95M0YdBY4KqTD+vbcteBjg@mail.gmail.com>

Hi Markus,

On Fri, Apr 12, 2013 at 12:32 PM, Markus Niebel <list-09 at tqsc.de> wrote:

> Which clock is connected to the PHY? Is it the enet_clock generated by i.MX28? Is the connection between PHY and i.MX28 RMII?

Yes, on mx28evk it is the ENET_CLK pin on mx28 that drives the LAN8270
PHY clock. The connection is RMII.


> If the FEC goes through a reset the clock generated by i.MX28 may switched to MII (25 MHz). Maybe the PHY gets confused if it is working in RMII mode.
>

Thanks for the suggestion, but I also tried not to turn off/on the
enet_clk and the issue also happens when enet_clk is kept constantly
at 50MHz.


From arnd at arndb.de  Fri Apr 12 16:42:36 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 12 Apr 2013 22:42:36 +0200
Subject: [PATCH v5 03/14] clocksource: samsung-pwm: Add infrastructure to
 share PWM hardware
In-Reply-To: <1365794250-14436-4-git-send-email-t.figa@samsung.com>
References: <1365794250-14436-1-git-send-email-t.figa@samsung.com>
 <1365794250-14436-4-git-send-email-t.figa@samsung.com>
Message-ID: <201304122242.36801.arnd@arndb.de>

On Friday 12 April 2013, Tomasz Figa wrote:
> +
> +Samsung SoCs contain PWM timer blocks which can be used for system clock source
> +and clock event timers, as well as to drive SoC outputs with PWM signal. Each
> +PWM timer block provides 5 PWM channels (not all of them can drive physical
> +outputs - see SoC and board manual).
> +
...
> +Optional properties:
> +- samsung,pwm-outputs: list of PWM channels used as PWM outputs on particular
> +    platform - an array of up to 5 elements being indices of PWM channels
> +    (from 0 to 4), the order does not matter.
> +

There is probably a good reason, but can you explain why this is actually required
to be a property? Wouldn't it be enough to just not refer to the PWM outputs from
other devices when they are not used?

	Arnd


From arnd at arndb.de  Fri Apr 12 16:44:03 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 12 Apr 2013 22:44:03 +0200
Subject: [PATCH v5 01/14] ARM: SAMSUNG: Move samsung-time to
 drivers/clocksource
In-Reply-To: <1365794250-14436-2-git-send-email-t.figa@samsung.com>
References: <1365794250-14436-1-git-send-email-t.figa@samsung.com>
 <1365794250-14436-2-git-send-email-t.figa@samsung.com>
Message-ID: <201304122244.03964.arnd@arndb.de>

On Friday 12 April 2013, Tomasz Figa wrote:
> ---
>  arch/arm/plat-samsung/Kconfig        |   8 -
>  arch/arm/plat-samsung/Makefile       |   1 -
>  arch/arm/plat-samsung/samsung-time.c | 394 -----------------------------------
>  drivers/clocksource/Kconfig          |   7 +
>  drivers/clocksource/Makefile         |   1 +
>  drivers/clocksource/samsung_pwm.c    | 394 +++++++++++++++++++++++++++++++++++

In general, please send patches generated with 'git format-patch -M'. You can
set that as a default using 'git config diff.renames true'.

	Arnd


From tomasz.figa at gmail.com  Fri Apr 12 16:47:16 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Fri, 12 Apr 2013 22:47:16 +0200
Subject: [PATCH v5 03/14] clocksource: samsung-pwm: Add infrastructure to
 share PWM hardware
In-Reply-To: <201304122242.36801.arnd@arndb.de>
References: <1365794250-14436-1-git-send-email-t.figa@samsung.com>
 <1365794250-14436-4-git-send-email-t.figa@samsung.com>
 <201304122242.36801.arnd@arndb.de>
Message-ID: <2367229.enzT7IXUEQ@flatron>

Hi Arnd,

On Friday 12 of April 2013 22:42:36 Arnd Bergmann wrote:
> On Friday 12 April 2013, Tomasz Figa wrote:
> > +
> > +Samsung SoCs contain PWM timer blocks which can be used for system
> > clock source +and clock event timers, as well as to drive SoC outputs
> > with PWM signal. Each +PWM timer block provides 5 PWM channels (not
> > all of them can drive physical +outputs - see SoC and board manual).
> > +
> 
> ...
> 
> > +Optional properties:
> > +- samsung,pwm-outputs: list of PWM channels used as PWM outputs on
> > particular +    platform - an array of up to 5 elements being indices
> > of PWM channels +    (from 0 to 4), the order does not matter.
> > +
> 
> There is probably a good reason, but can you explain why this is
> actually required to be a property? Wouldn't it be enough to just not
> refer to the PWM outputs from other devices when they are not used?

It is needed for the clocksource driver, to select unused channels for 
clocksource and clock event purposes.

Best regards,
Tomasz



From arnd at arndb.de  Fri Apr 12 16:51:41 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 12 Apr 2013 22:51:41 +0200
Subject: [PATCH v5 00/14] ARM: samsung-time: Prepare for multiplatform
 support
In-Reply-To: <1365794250-14436-1-git-send-email-t.figa@samsung.com>
References: <1365794250-14436-1-git-send-email-t.figa@samsung.com>
Message-ID: <201304122251.41393.arnd@arndb.de>

On Friday 12 April 2013, Tomasz Figa wrote:
> This series is an attempt to make the samsung-time clocksource driver ready
> for multiplatform kernels. It moves the driver to drivers/clocksource, cleans
> it up from uses of static platform-specific definitions, simplifies timer
> interrupt handling and adds Device Tree support.
> 
> The samsung_pwm clocksource driver is made the master driver, which
> exposes a single function to the PWM driver to get required data. Only
> samsung-time driver is reworked to use the master driver at this time,
> since the PWM driver can be already considered broken at the moment and
> needs separate series of several patches to fix and clean it up, which
> I am already working on.
> 
> Tested on Universal C210 board with Device Tree. Not tested without
> Device Tree, since it has been already broken before this series.
> Compile tested for other related SoCs.

Acked-by: Arnd Bergmann <arnd at arndb.de>


From tomasz.figa at gmail.com  Fri Apr 12 16:52:14 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Fri, 12 Apr 2013 22:52:14 +0200
Subject: [PATCH v5 01/14] ARM: SAMSUNG: Move samsung-time to
 drivers/clocksource
In-Reply-To: <201304122244.03964.arnd@arndb.de>
References: <1365794250-14436-1-git-send-email-t.figa@samsung.com>
 <1365794250-14436-2-git-send-email-t.figa@samsung.com>
 <201304122244.03964.arnd@arndb.de>
Message-ID: <2161915.CT7ruPYKGQ@flatron>

On Friday 12 of April 2013 22:44:03 Arnd Bergmann wrote:
> On Friday 12 April 2013, Tomasz Figa wrote:
> > ---
> > 
> >  arch/arm/plat-samsung/Kconfig        |   8 -
> >  arch/arm/plat-samsung/Makefile       |   1 -
> >  arch/arm/plat-samsung/samsung-time.c | 394
> >  ----------------------------------- drivers/clocksource/Kconfig     
> >      |   7 +
> >  drivers/clocksource/Makefile         |   1 +
> >  drivers/clocksource/samsung_pwm.c    | 394
> >  +++++++++++++++++++++++++++++++++++
> In general, please send patches generated with 'git format-patch -M'.
> You can set that as a default using 'git config diff.renames true'.

Oops, I forgot to add the switch, sorry. Setting it as default might be a 
good idea indeed.

Best regards,
Tomasz



From vladimir.danushevsky at oracle.com  Fri Apr 12 16:58:43 2013
From: vladimir.danushevsky at oracle.com (Vladimir Danushevsky)
Date: Fri, 12 Apr 2013 16:58:43 -0400
Subject: [PATCH] Report double word access atomicity on LPAE enabled
 targets through AUXV
In-Reply-To: <20130408155749.GS17476@mudshark.cambridge.arm.com>
References: <C3FF039D-7DE3-4A99-8317-789094095D8B@oracle.com>
 <20130408142406.GL17995@n2100.arm.linux.org.uk>
 <20130408155749.GS17476@mudshark.cambridge.arm.com>
Message-ID: <CD54D5A4-2E19-49D9-B6E7-051F36AB5DF8@oracle.com>

Hi Will,

On Apr 8, 2013, at 11:57 AM, Will Deacon wrote:

> Hi Russell,
> 
> On Mon, Apr 08, 2013 at 03:24:06PM +0100, Russell King - ARM Linux wrote:
>> I think we're heading towards running out of hwcap bits to represent all
>> these different features.  Not there yet, but after this we only have 11
>> spare bits.
>> 
>> Maybe we need to switch to a more x86-centric method where we report this
>> stuff in /proc/cpuinfo, and userspace parses this information out.  If
>> glibc already has code in there for x86, maybe we can reuse that?
> 
> Why can't we just pass multiple AT_HWCAP entries in the auxv? It would
> require a small change to the ELF loader to allow an architecture to provide
> more than just ELF_HWCAP, but it's fairly straightforward and easy to
> propogate without breaking backwards compatibility.
> 
>>> +        if (((read_cpuid_ext(CPUID_EXT_MMFR3) >> 28) & 0xf) > 0)
>>> 
>>> +          elf_hwcap |= HWCAP_ATOMICD;
>> 
>> We use tabs for indentation, not two spaces.  Also, on the face of it
>> ATOMICD isn't obvious what it means.  Maybe HWCAP_LDRDSTRD would be
>> better - it's only one character longer and truely reflects what you're
>> trying to report - the presence of these two instructions.
> 
> Actually, it's not just the presence of those instructions -- it's their
> behaviour wrt atomicity. They are only guaranteed to be atomic if the CPU in
> question supports LPAE. We could call it "lpae" but it might be set even
> when the kernel is using the short-descriptor format.

I also think that ATOMICD would describe the intended behavior better.

Below is a modified patch based on suggestions so far:


Signed-off-by: Vladimir Danushevsky <vladimir.danushevsky at oracle.com>

 include/uapi/asm/hwcap.h |    1 +
 kernel/setup.c           |   13 +++++++++++--
 2 files changed, 12 insertions(+), 2 deletions(-)


diff -uprN -X linux-3.9-rc6/Documentation/dontdiff linux-3.9-rc6-vanilla/arch/arm/include/uapi/asm/hwcap.h linux-3.9-rc6/arch/arm/include/uapi/asm/hwcap.h
--- linux-3.9-rc6-vanilla/arch/arm/include/uapi/asm/hwcap.h	2013-04-07 23:49:54.000000000 -0400
+++ linux-3.9-rc6/arch/arm/include/uapi/asm/hwcap.h	2013-04-08 12:01:24.952168593 -0400
@@ -25,6 +25,7 @@
 #define HWCAP_IDIVT	(1 << 18)
 #define HWCAP_VFPD32	(1 << 19)	/* set if VFP has 32 regs (not 16) */
 #define HWCAP_IDIV	(HWCAP_IDIVA | HWCAP_IDIVT)
+#define HWCAP_ATOMICD	(1 << 20)	/* atomic behavior of ldrd/strd */
 
 
 #endif /* _UAPI__ASMARM_HWCAP_H */
diff -uprN -X linux-3.9-rc6/Documentation/dontdiff linux-3.9-rc6-vanilla/arch/arm/kernel/setup.c linux-3.9-rc6/arch/arm/kernel/setup.c
--- linux-3.9-rc6-vanilla/arch/arm/kernel/setup.c	2013-04-07 23:49:54.000000000 -0400
+++ linux-3.9-rc6/arch/arm/kernel/setup.c	2013-04-08 12:42:26.145583364 -0400
@@ -355,7 +355,7 @@ void __init early_print(const char *str,
 
 static void __init cpuid_init_hwcaps(void)
 {
-	unsigned int divide_instrs;
+	unsigned int divide_instrs, vmsa;
 
 	if (cpu_architecture() < CPU_ARCH_ARMv7)
 		return;
@@ -368,6 +368,14 @@ static void __init cpuid_init_hwcaps(voi
 	case 1:
 		elf_hwcap |= HWCAP_IDIVT;
 	}
+
+        /*
+         * LDRD/STRD instructions are single-copy atomic on LPAE enabled targets
+         * as long as double-word alignment is kept. Report that feature.
+         */
+        vmsa = (read_cpuid_ext(CPUID_EXT_MMFR0) & 0xf) >> 0;
+        if (vmsa >= 5)
+                elf_hwcap |= HWCAP_ATOMICD;
 }
 
 static void __init feat_v6_fixup(void)
@@ -506,7 +514,7 @@ static void __init setup_processor(void)
 #ifndef CONFIG_ARM_THUMB
 	elf_hwcap &= ~(HWCAP_THUMB | HWCAP_IDIVT);
 #endif

 	feat_v6_fixup();
 
 	cacheid_init();
@@ -864,6 +872,7 @@ static const char *hwcap_str[] = {
 	"vfpv4",
 	"idiva",
 	"idivt",
+	"atomicd",
 	NULL
 };
 



> 
> Will



From heiko at sntech.de  Fri Apr 12 18:22:48 2013
From: heiko at sntech.de (Heiko =?utf-8?q?St=C3=BCbner?=)
Date: Sat, 13 Apr 2013 00:22:48 +0200
Subject: [PATCH v5 00/14] ARM: samsung-time: Prepare for multiplatform
 support
In-Reply-To: <1365794250-14436-1-git-send-email-t.figa@samsung.com>
References: <1365794250-14436-1-git-send-email-t.figa@samsung.com>
Message-ID: <201304130022.49987.heiko@sntech.de>

Hi Tomasz,

Am Freitag, 12. April 2013, 21:17:16 schrieb Tomasz Figa:
> This series is an attempt to make the samsung-time clocksource driver ready
> for multiplatform kernels. It moves the driver to drivers/clocksource,
> cleans it up from uses of static platform-specific definitions, simplifies
> timer interrupt handling and adds Device Tree support.
> 
> The samsung_pwm clocksource driver is made the master driver, which
> exposes a single function to the PWM driver to get required data. Only
> samsung-time driver is reworked to use the master driver at this time,
> since the PWM driver can be already considered broken at the moment and
> needs separate series of several patches to fix and clean it up, which
> I am already working on.
> 
> Tested on Universal C210 board with Device Tree. Not tested without
> Device Tree, since it has been already broken before this series.
> Compile tested for other related SoCs.

On a s3c2416 based board with both non-dt and preliminary-dt support
Tested-by: Heiko Stuebner <heiko at sntech.de>

One nitpick:

Without dt support, you get this:

  CC      drivers/clocksource/samsung_pwm.o
drivers/clocksource/samsung_pwm.c:620: warning: ?samsung_pwm_clocksource_init_of? defined but not used

So, something like the following might be necessary

-------------- 8< -------------------
diff --git a/drivers/clocksource/samsung_pwm.c b/drivers/clocksource/samsung_pwm.c
index a12ee08..2bf8303 100644
--- a/drivers/clocksource/samsung_pwm.c
+++ b/drivers/clocksource/samsung_pwm.c
@@ -617,6 +617,7 @@ static void __init __samsung_pwm_clocksource_init(
        samsung_clocksource_init();
 }
 
+#ifdef CONFIG_CLKSRC_OF
 static void __init samsung_pwm_clocksource_init_of(struct device_node *np)
 {
        __samsung_pwm_clocksource_init(NULL, np);
@@ -629,6 +630,7 @@ CLOCKSOURCE_OF_DECLARE(s5p6440_pwm, "samsung,s5p6440-pwm",
                                        samsung_pwm_clocksource_init_of);
 CLOCKSOURCE_OF_DECLARE(s5pc100_pwm, "samsung,s5pc100-pwm",
                                        samsung_pwm_clocksource_init_of);
+#endif
 
 void __init samsung_pwm_clocksource_init(struct platform_device *pdev)
 {
-------------- 8< -------------------


Heiko


From linus.walleij at linaro.org  Fri Apr 12 18:24:18 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Sat, 13 Apr 2013 00:24:18 +0200
Subject: [PATCH 3/3] pinctrl: add MVF pinctrl driver
In-Reply-To: <1365753432-14247-1-git-send-email-b35083@freescale.com>
References: <1365753432-14247-1-git-send-email-b35083@freescale.com>
Message-ID: <CACRpkdZMnFT4FUFsErRUKnbFW=sOif3n8rRL0zKChXSHj3RAbg@mail.gmail.com>

On Fri, Apr 12, 2013 at 9:57 AM, Jingchang Lu <b35083 at freescale.com> wrote:

> It adds Freescale Vybrid Family pin controller
> driver to I.MX IOMUXC common driver architecture.
> The only difference is the MUX and CONF register
> is the same on MVF platform, so the defined
> config value including the mux_mode int DTS.
>
> Signed-off-by: Jingchang Lu <b35083 at freescale.com>

Looks OK as such drivers goes, but can I have an ACK from
some of the Freescale maintainers?

Yours,
Linus Walleij


From davem at davemloft.net  Fri Apr 12 18:26:12 2013
From: davem at davemloft.net (David Miller)
Date: Fri, 12 Apr 2013 18:26:12 -0400 (EDT)
Subject: [PATCH] ethernet/fec: Add Vybrid family fec support
In-Reply-To: <1365750765-3615-1-git-send-email-b35083@freescale.com>
References: <1365750765-3615-1-git-send-email-b35083@freescale.com>
Message-ID: <20130412.182612.1613373240725639505.davem@davemloft.net>

From: Jingchang Lu <b35083 at freescale.com>
Date: Fri, 12 Apr 2013 15:12:45 +0800

> Freescale Vybrid platform implentments MAC-ENET core
> providing compatibility with half- or full-duplex
> 10/100 Mbit/s Ethernet LANs.
> 
> Signed-off-by: Jingchang Lu <b35083 at freescale.com>
> ---
>  drivers/net/ethernet/freescale/fec.c | 5 +++++

Applied, but the driver source file is now named:

	drivers/net/ethernet/freescale/fec_main.c

in net-next, so I had to edit your patch.


From arnd at arndb.de  Fri Apr 12 18:26:43 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Sat, 13 Apr 2013 00:26:43 +0200
Subject: [PATCH v5 00/14] ARM: samsung-time: Prepare for multiplatform
 support
In-Reply-To: <201304130022.49987.heiko@sntech.de>
References: <1365794250-14436-1-git-send-email-t.figa@samsung.com>
 <201304130022.49987.heiko@sntech.de>
Message-ID: <7765249.PbghLduf67@wuerfel>

On Saturday 13 April 2013 00:22:48 Heiko St?bner wrote:
> 
> Without dt support, you get this:
> 
>   CC      drivers/clocksource/samsung_pwm.o
> drivers/clocksource/samsung_pwm.c:620: warning: ?samsung_pwm_clocksource_init_of? defined but not used
> 
> So, something like the following might be necessary

That patch should not be required any more with the definition

#ifdef CONFIG_CLKSRC_OF
extern void clocksource_of_init(void);

#define CLOCKSOURCE_OF_DECLARE(name, compat, fn)                        \
        static const struct of_device_id __clksrc_of_table_##name       \
                __used __section(__clksrc_of_table)                     \
                 = { .compatible = compat,                              \
                     .data = (fn == (clocksource_of_init_fn)NULL) ? fn : fn }
#else
static inline void clocksource_of_init(void) {}
#define CLOCKSOURCE_OF_DECLARE(name, compat, fn)                        \
        static const struct of_device_id __clksrc_of_table_##name       \
                __attribute__((unused))                                 \
                 = { .compatible = compat,                              \
                     .data = (fn == (clocksource_of_init_fn)NULL) ? fn : fn }
#endif

which turns the ?samsung_pwm_clocksource_init_of? function into an unused
symbol that gets silently dropped by gcc, at least in theory. Are you
using the latest clksrc/cleanup branch as a base?

	Arnd


From heiko at sntech.de  Fri Apr 12 18:39:24 2013
From: heiko at sntech.de (Heiko =?utf-8?q?St=C3=BCbner?=)
Date: Sat, 13 Apr 2013 00:39:24 +0200
Subject: [PATCH v5 00/14] ARM: samsung-time: Prepare for multiplatform
 support
In-Reply-To: <7765249.PbghLduf67@wuerfel>
References: <1365794250-14436-1-git-send-email-t.figa@samsung.com>
 <201304130022.49987.heiko@sntech.de> <7765249.PbghLduf67@wuerfel>
Message-ID: <201304130039.24872.heiko@sntech.de>

Am Samstag, 13. April 2013, 00:26:43 schrieb Arnd Bergmann:
> On Saturday 13 April 2013 00:22:48 Heiko St?bner wrote:
> > Without dt support, you get this:
> >   CC      drivers/clocksource/samsung_pwm.o
> > 
> > drivers/clocksource/samsung_pwm.c:620: warning:
> > ?samsung_pwm_clocksource_init_of? defined but not used
> > 
> > So, something like the following might be necessary
> 
> That patch should not be required any more with the definition
> 
> #ifdef CONFIG_CLKSRC_OF
> extern void clocksource_of_init(void);
> 
> #define CLOCKSOURCE_OF_DECLARE(name, compat, fn)                        \
>         static const struct of_device_id __clksrc_of_table_##name       \
>                 __used __section(__clksrc_of_table)                     \
>                  = { .compatible = compat,                              \
>                      .data = (fn == (clocksource_of_init_fn)NULL) ? fn : fn
> } #else
> static inline void clocksource_of_init(void) {}
> #define CLOCKSOURCE_OF_DECLARE(name, compat, fn)                        \
>         static const struct of_device_id __clksrc_of_table_##name       \
>                 __attribute__((unused))                                 \
>                  = { .compatible = compat,                              \
>                      .data = (fn == (clocksource_of_init_fn)NULL) ? fn : fn
> } #endif
> 
> which turns the ?samsung_pwm_clocksource_init_of? function into an unused
> symbol that gets silently dropped by gcc, at least in theory. Are you
> using the latest clksrc/cleanup branch as a base?

Nope, I just put the stuff on top of all the other changes. So it seems 
everything is fine and working ... very nice :-)


Heiko


From davidb at codeaurora.org  Fri Apr 12 18:40:42 2013
From: davidb at codeaurora.org (David Brown)
Date: Fri, 12 Apr 2013 15:40:42 -0700
Subject: [GIT PULL] msm cleanup for 3.10
Message-ID: <8ya7gk7qsnp.fsf@huya.qualcomm.com>

The following changes since commit 6dbe51c251a327e012439c4772097a13df43c5b8:

  Linux 3.9-rc1 (2013-03-03 15:11:05 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/davidb/linux-msm.git tags/msm-cleanup-3.10

for you to fetch changes up to 641f71699ec96fb742cc891b9ea4f3a46c60050e:

  ARM: msm: Remove unused cpu.h header file (2013-03-05 12:05:43 -0800)

----------------------------------------------------------------
Cleanups for MSM for 3.10

These are some patches for various parts of MSM that gradually bring
us closer to being part of single zimage.

----------------------------------------------------------------
Stephen Boyd (4):
      ARM: msm: Move dma.h #defines that are private to dma.c
      mmc: msm_sdcc: Remove unnecessary include
      gpio: Make gpio-msm-v1 into a platform driver
      ARM: msm: Remove unused cpu.h header file

 arch/arm/mach-msm/board-halibut.c    |   1 +
 arch/arm/mach-msm/board-msm7x30.c    |   1 +
 arch/arm/mach-msm/board-qsd8x50.c    |   1 +
 arch/arm/mach-msm/board-trout.c      |   1 +
 arch/arm/mach-msm/devices-msm7x00.c  |  31 +++++
 arch/arm/mach-msm/devices-msm7x30.c  |  31 +++++
 arch/arm/mach-msm/devices-qsd8x50.c  |  31 +++++
 arch/arm/mach-msm/devices.h          |   4 +
 arch/arm/mach-msm/dma.c              |  26 +++++
 arch/arm/mach-msm/include/mach/cpu.h |  54 ---------
 arch/arm/mach-msm/include/mach/dma.h |  26 -----
 drivers/gpio/gpio-msm-v1.c           | 220 ++++++++++++++++++++++++-----------
 drivers/mmc/host/msm_sdcc.c          |   1 -
 13 files changed, 276 insertions(+), 152 deletions(-)
 delete mode 100644 arch/arm/mach-msm/include/mach/cpu.h

-- 
sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation


From tomasz.figa at gmail.com  Fri Apr 12 18:42:55 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Sat, 13 Apr 2013 00:42:55 +0200
Subject: [PATCH v5 00/14] ARM: samsung-time: Prepare for multiplatform
 support
In-Reply-To: <201304130039.24872.heiko@sntech.de>
References: <1365794250-14436-1-git-send-email-t.figa@samsung.com>
 <7765249.PbghLduf67@wuerfel> <201304130039.24872.heiko@sntech.de>
Message-ID: <11677814.fpOiq2szh2@flatron>

On Saturday 13 of April 2013 00:39:24 Heiko St?bner wrote:
> Am Samstag, 13. April 2013, 00:26:43 schrieb Arnd Bergmann:
> > On Saturday 13 April 2013 00:22:48 Heiko St?bner wrote:
> > > Without dt support, you get this:
> > >   CC      drivers/clocksource/samsung_pwm.o
> > > 
> > > drivers/clocksource/samsung_pwm.c:620: warning:
> > > ?samsung_pwm_clocksource_init_of? defined but not used
> > > 
> > > So, something like the following might be necessary
> > 
> > That patch should not be required any more with the definition
> > 
> > #ifdef CONFIG_CLKSRC_OF
> > extern void clocksource_of_init(void);
> > 
> > #define CLOCKSOURCE_OF_DECLARE(name, compat, fn)                      
> >  \> 
> >         static const struct of_device_id __clksrc_of_table_##name     
> >          \
> >         
> >                 __used __section(__clksrc_of_table)                   
> >                  \
> >                 
> >                  = { .compatible = compat,                            
> >                   \
> >                  
> >                      .data = (fn == (clocksource_of_init_fn)NULL) ? fn
> >                      : fn
> > 
> > } #else
> > static inline void clocksource_of_init(void) {}
> > #define CLOCKSOURCE_OF_DECLARE(name, compat, fn)                      
> >  \> 
> >         static const struct of_device_id __clksrc_of_table_##name     
> >          \
> >         
> >                 __attribute__((unused))                               
> >                  \
> >                 
> >                  = { .compatible = compat,                            
> >                   \
> >                  
> >                      .data = (fn == (clocksource_of_init_fn)NULL) ? fn
> >                      : fn
> > 
> > } #endif
> > 
> > which turns the ?samsung_pwm_clocksource_init_of? function into an
> > unused symbol that gets silently dropped by gcc, at least in theory.
> > Are you using the latest clksrc/cleanup branch as a base?
> 
> Nope, I just put the stuff on top of all the other changes. So it seems
> everything is fine and working ... very nice :-)

Great. Thanks for testing.

I will try to rebase my patches for s3c64xx on top of this and do some 
testing as well.

Best regards,
Tomasz



From davidb at codeaurora.org  Fri Apr 12 18:43:15 2013
From: davidb at codeaurora.org (David Brown)
Date: Fri, 12 Apr 2013 15:43:15 -0700
Subject: [GIT PULL] msm core for 3.10
In-Reply-To: <8ya7gk7qsnp.fsf@huya.qualcomm.com>
Message-ID: <8yazjx3pdz0.fsf@huya.qualcomm.com>

The following changes since commit f6161aa153581da4a3867a2d1a7caf4be19b6ec9:

  Linux 3.9-rc2 (2013-03-10 16:54:19 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/davidb/linux-msm.git tags/msm-core-3.10

for you to fetch changes up to e25e3d1fef2c57e49aef64535341c15fe2b29b4a:

  ARM: msm: Wait for timer clear to complete (2013-03-22 10:46:16 -0700)

----------------------------------------------------------------
Patches for MSM core

These patches are changes to the MSM timer code that will be for
upcoming targets, including a generalization of the binding and
preventing a missing timer interrupt.

----------------------------------------------------------------
Stephen Boyd (2):
      ARM: msm: Rework timer binding to be more general
      ARM: msm: Wait for timer clear to complete

 .../devicetree/bindings/arm/msm/timer.txt          |  41 ++++----
 arch/arm/boot/dts/msm8660-surf.dts                 |  20 ++--
 arch/arm/boot/dts/msm8960-cdp.dts                  |  22 ++---
 arch/arm/mach-msm/timer.c                          | 110 ++++++++++-----------
 4 files changed, 86 insertions(+), 107 deletions(-)

-- 
sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation


From davidb at codeaurora.org  Fri Apr 12 18:43:32 2013
From: davidb at codeaurora.org (David Brown)
Date: Fri, 12 Apr 2013 15:43:32 -0700
Subject: [GIT PULL] msm defconfig for 3.10
In-Reply-To: <8ya7gk7qsnp.fsf@huya.qualcomm.com>
Message-ID: <8yavc7rpdyj.fsf@huya.qualcomm.com>

The following changes since commit 6dbe51c251a327e012439c4772097a13df43c5b8:

  Linux 3.9-rc1 (2013-03-03 15:11:05 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/davidb/linux-msm.git tags/msm-defconfig-3.10

for you to fetch changes up to dd465b2400a77bea6e5a95045feb6dbcf2e48a38:

  ARM: msm: enable SSBI driver in defconfig (2013-03-12 11:14:32 -0700)

----------------------------------------------------------------
Defconfig updates for MSM

The msm_defconfig is quite out of date.  This allows the targets we
are actively working on to be more easily build and run tested.

----------------------------------------------------------------
David Brown (1):
      ARM: msm: enable SSBI driver in defconfig

Stephen Boyd (1):
      ARM: msm: Concentrate defconfig on DT supported devices

 arch/arm/configs/msm_defconfig | 154 +++++++++++++++++++++++++++++------------
 1 file changed, 109 insertions(+), 45 deletions(-)

-- 
sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation


From davidb at codeaurora.org  Fri Apr 12 18:43:44 2013
From: davidb at codeaurora.org (David Brown)
Date: Fri, 12 Apr 2013 15:43:44 -0700
Subject: [GIT PULL] msm fixes for 3.10
In-Reply-To: <8ya7gk7qsnp.fsf@huya.qualcomm.com>
Message-ID: <8yar4ifpdy7.fsf@huya.qualcomm.com>

The following changes since commit f6161aa153581da4a3867a2d1a7caf4be19b6ec9:

  Linux 3.9-rc2 (2013-03-10 16:54:19 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/davidb/linux-msm.git tags/msm-fix-3.10

for you to fetch changes up to 73a8c28f167c9e7bc42eafc0bcbd298031709430:

  ARM: msm: Fix uncompess.h tx underrun check (2013-04-11 09:40:35 -0700)

----------------------------------------------------------------
Some minor fixes for MSM for 3.10

  - Fix a timer problem that causes missed ticks and hangs.

  - Fix a problem with the decompressor UART dropping characters.

----------------------------------------------------------------
Stephen Boyd (2):
      ARM: msm: Stop counting before reprogramming clockevent
      ARM: msm: Fix uncompess.h tx underrun check

 arch/arm/mach-msm/include/mach/uncompress.h | 2 +-
 arch/arm/mach-msm/timer.c                   | 5 ++++-
 2 files changed, 5 insertions(+), 2 deletions(-)

-- 
sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation


From nm at ti.com  Fri Apr 12 18:54:32 2013
From: nm at ti.com (Nishanth Menon)
Date: Fri, 12 Apr 2013 17:54:32 -0500
Subject: [PATCH V4 0/6] ARM: OMAP3+: support cpufreq-cpu0 for device tree boot
Message-ID: <1365807278-554-1-git-send-email-nm@ti.com>

The following version 4 of the series arose from trying to use BeagleBoard-XM
(OMAP3 variant) for doing CPU DVFS using cpufreq-cpu0. This series enables the
generic cpufreq-cpu0 driver to be used in device tree enabled boot while
maintaining support of the legacy omap-cpufreq driver when used in non device
tree enabled boot.

However, in order to enable complete SoC entitlement for OMAP platforms, with
this series, key features are still pending on device tree adaptation for OMAP:
A) clock framework data transition to DT - this should happen soon, so this
series hacks the clock node for the time being as suggested in review of
original series[1].
B) On processors that use voltage controller, voltage processor (VC/VP hardware
loop using I2C_SR path) - we have started work on transitioning them to
regulator framework driven by DT.
C) Adaptive Body Bias and SmartReflex AVS conversion to DT. [2]

Note: At this point in time, we do not have DT entries for clock on OMAP
platforms. Common Clock Framework(CCF) could also control regulators[3].
Once these conversions are complete, there might be minimal cleanup work to
switch to the new data structure changes.

Key benefit of the series is to allow all relevant TI platforms now to use a
single cpufreq driver and equivalent frameworks in addition be part of the
transition to device tree.
NOTE: As a result of this series:
1. omap-cpufreq will be used only in non device tree boot scenario. we should
   delete this driver once the 100% DT conversion is complete.
2. Generic cpufreq-cpu0 will be used only in device tree boot scenario.
   boot systems.

Key changes in version 4 since version 3:
	- OMAP clock driver introduced as discussed in
		http://marc.info/?t=136370325600009&r=1&w=2
	- cpufreq-cpu0 dummy device introduced in pm.c late_initcall: discussed
	  in http://marc.info/?t=136450773400004&r=1&w=2
	- updated test script (prints regulator voltage where available)
	- parts of the series probably belong to different maintainer:
	  consolidated as a single series to aid review in-context.

version 3 of the series:
	http://marc.info/?l=linux-pm&m=136450759315742&w=2
	available at:
	http://git.kernel.org/cgit/linux/kernel/git/bcousson/linux-omap-dt.git/log/?h=for_3.10/dts

version 2 of the series:
	http://marc.info/?t=136371570200003&r=1&w=2
	available at:
	https://github.com/nmenon/linux-2.6-playground/commits/push/cpufreq-cpu0-omap-all-v2

version 1 of the series:
	http://marc.info/?t=136329485400005&r=1&w=2
	available at:
	https://github.com/nmenon/linux-2.6-playground/commits/push/cpufreq-cpu0-omap-all-v1

[1] Original discussion thread which triggered this series:
	http://marc.info/?l=linux-pm&m=136304313700602&w=2
	https://patchwork.kernel.org/patch/2251841/
	https://patchwork.kernel.org/patch/2251851/
[2] ABB RFC: http://marc.info/?l=linux-omap&m=136449099409794&w=2 
[3] CCF DVFS patches:
https://patchwork.kernel.org/patch/2195431/
https://patchwork.kernel.org/patch/2195421/
https://patchwork.kernel.org/patch/2195451/
https://patchwork.kernel.org/patch/2195441/
https://patchwork.kernel.org/patch/2195461/

Version 4 is now based on a few branches to prevent merge conflicts(v3.9-rc6):
	git://git.linaro.org/people/mturquette/linux.git
		clk-next 38e4aa0 clk: sunxi: Unify oscillator clock
	git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git
		linux-next 584fa10 Merge branch 'pm-runtime-next'
	git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git
		for_3.10/dts 1fac4ff ARM: dts: Add OMAP3430
	(merged branch is called baseline-v4 on my tree)

Version 4 is also available at:
	https://github.com/nmenon/linux-2.6-playground/commits/push/cpufreq-cpu0-omap-all-v4
	git link: git://github.com/nmenon/linux-2.6-playground.git
	branch: cpufreq-cpu0-omap-all-v4

Test coverage:
	test script: http://pastebin.com/z4yqZrBg
Platforms verified:
	beaglebone(rev A6a) - AM33xx compatible - http://pastebin.com/YnSNiTnx
	beagleboard (rev C1D) - OMAP3430 compatible
		- DT enabled boot: http://pastebin.com/eGaDD3B4
		- No DT enabled boot: http://pastebin.com/5xqsNBA6
	omap3-beagle-xm -OMAP3630 compatible - http://pastebin.com/FdrG4Rna
	Pandaboard -(OMAP4430 ES2.1) - http://pastebin.com/1jjSRKQh
	Pandaboard-ES -(OMAP4460 ES1.1) - http://pastebin.com/B5acTbch

Nishanth Menon (6):
  clk: OMAP: introduce device tree binding to kernel clock data
[Clk probably belongs to mike's tree?]
  ARM: dts: OMAP3: add clock nodes for CPU
  ARM: dts: OMAP4: add clock nodes for CPU
  ARM: dts: AM33XX: add clock nodes for CPU
[The above probably belong to Benoit's tree]
  ARM: OMAP2+: AM33XX: add lateinit hook for calling pm late init
  ARM: OMAP3+: use cpu0-cpufreq driver in device tree supported boot
[The above probably belong to Kevin/Tony's tree]

 .../devicetree/bindings/clock/omap-clock.txt       |   40 ++++++++
 arch/arm/boot/dts/am33xx.dtsi                      |    7 ++
 arch/arm/boot/dts/omap3.dtsi                       |    7 ++
 arch/arm/boot/dts/omap4.dtsi                       |    7 ++
 arch/arm/mach-omap2/board-generic.c                |    1 +
 arch/arm/mach-omap2/cclock33xx_data.c              |    1 -
 arch/arm/mach-omap2/common.h                       |    1 +
 arch/arm/mach-omap2/io.c                           |    6 ++
 arch/arm/mach-omap2/pm.c                           |   11 ++-
 drivers/clk/Makefile                               |    1 +
 drivers/clk/omap/Makefile                          |    1 +
 drivers/clk/omap/clk.c                             |   96 ++++++++++++++++++++
 12 files changed, 175 insertions(+), 4 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/clock/omap-clock.txt
 create mode 100644 drivers/clk/omap/Makefile
 create mode 100644 drivers/clk/omap/clk.c

Regards,
Nishanth Menon
-- 
1.7.9.5



From nm at ti.com  Fri Apr 12 18:54:34 2013
From: nm at ti.com (Nishanth Menon)
Date: Fri, 12 Apr 2013 17:54:34 -0500
Subject: [PATCH V4 2/6] ARM: dts: OMAP3: add clock nodes for CPU
In-Reply-To: <1365807278-554-1-git-send-email-nm@ti.com>
References: <1365807278-554-1-git-send-email-nm@ti.com>
Message-ID: <1365807278-554-3-git-send-email-nm@ti.com>

OMAP34xx and OMAP36xx platforms use dpll1 clock. Add same to common
definition.

Cc: Benoit Cousson <b-cousson at ti.com>
Signed-off-by: Nishanth Menon <nm at ti.com>
---
RFC of this patch was discussed in http://marc.info/?t=136370325600009&r=1&w=2
along with the detailed context as to why this is an intermediate step.

previous revisions of cpufreq-cpu0 support do not use this approach.

[Probably belongs to Benoit's tree]
 arch/arm/boot/dts/omap3.dtsi |    7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 559b02f..58c6ed6 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -23,6 +23,8 @@
 	cpus {
 		cpu at 0 {
 			compatible = "arm,cortex-a8";
+			clocks = <&dpll1>;
+			clock-names = "cpu";
 		};
 	};
 
@@ -73,6 +75,11 @@
 			ti,hwmods = "counter_32k";
 		};
 
+		dpll1: dpll1 {
+			#clock-cells = <0>;
+			compatible = "ti,omap-clock";
+		};
+
 		intc: interrupt-controller at 48200000 {
 			compatible = "ti,omap2-intc";
 			interrupt-controller;
-- 
1.7.9.5



From nm at ti.com  Fri Apr 12 18:54:33 2013
From: nm at ti.com (Nishanth Menon)
Date: Fri, 12 Apr 2013 17:54:33 -0500
Subject: [PATCH V4 1/6] clk: OMAP: introduce device tree binding to kernel
 clock data
In-Reply-To: <1365807278-554-1-git-send-email-nm@ti.com>
References: <1365807278-554-1-git-send-email-nm@ti.com>
Message-ID: <1365807278-554-2-git-send-email-nm@ti.com>

OMAP clock data is located in arch/arm/mach-omap2/cclockXYZ_data.c.
However, this presents an obstacle for using these clock nodes in
Device Tree definitions. This is especially true for board specific
clocks initially. The fixed clocks are currently found via clock
aliases table. There are many possible approaches to this problem as
discussed in the following thread:
http://marc.info/?t=136370325600009&r=1&w=2.
Highlights of the options:
a) device specific clk_add_alias:
   cons: driver handling required
b) using an generic clk node and indexing to reach the clock required.
   This is similar in approach taken by tegra and few other platforms.
   Example usage: clock = <&clk 5>;
   cons: potential to have mismatches in indexed table and associated
   dtb data. In addition, managing continued documentation in bindings
   as clock indexing increases. Even though readability angle could be
   improved by using preprocessing of DT using macros, indexed
   approach is inherently risky from cases like the following:
   clk indexes in kernel:
   1 - mpu_dpll
   2 - aux_clk1
   3 - core_clk
   DT entry for peripheral X uses <&clk 2> to reach aux_clk1. Now, let's
   say kernel updates indices to:
   1 - mpu_dpll
   2 - per_dpll
   3 - aux_clk1
   4 - core_clk
   using the old dtb(or dts missing an update), on new kernel which
   has updated indices will result in per_dpll now controlled for
   peripheral X without warning or any potential error detection.

   Even though we could claim this is user error, such errors are hard
   to track down and fix.

An alternate approach introduced here is to introduce device tree
bindings corresponding to the clock nodes required in DT definition
for SoC which automatically maps back to the definitions in
cclockXYZ_data.c.

The driver introduced here to do this mapping will eventually be the
place where the clock handling will migrate to. We need to consider
this angle as well so that the solution will be an valid transition
point for moving the clock data out of kernel image (into device tree
or firmware load etc..).

Overall strategy introduced here is simple: a clock node described in
device tree blob is used to identify the exact clock provided in the
SoC specific data. This is then linked back using of_clk_add_provider
to the device node to be accessible by of_clk_get.

Based on discussion contributions from Roger Quadros, Grygorii Strashko
and others.

Cc: Kevin Hilman <khilman at deeprootsystems.com>
Cc: Mike Turquette <mturquette at linaro.org>
Cc: Paul Walmsley <paul at pwsan.com>
[tony at atomide.com: co-developed]
Signed-off-by: Tony Lindgren <tony at atomide.com>
Signed-off-by: Nishanth Menon <nm at ti.com>
---

RFC of this patch was discussed in http://marc.info/?t=136370325600009&r=1&w=2
along with the detailed context as to why this is an intermediate step.

Previous revisions of cpufreq-cpu0 support do not use this approach.
[Might eventually belong to Mike's tree.]

 .../devicetree/bindings/clock/omap-clock.txt       |   40 ++++++++
 drivers/clk/Makefile                               |    1 +
 drivers/clk/omap/Makefile                          |    1 +
 drivers/clk/omap/clk.c                             |   96 ++++++++++++++++++++
 4 files changed, 138 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/omap-clock.txt
 create mode 100644 drivers/clk/omap/Makefile
 create mode 100644 drivers/clk/omap/clk.c

diff --git a/Documentation/devicetree/bindings/clock/omap-clock.txt b/Documentation/devicetree/bindings/clock/omap-clock.txt
new file mode 100644
index 0000000..047c1e7
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/omap-clock.txt
@@ -0,0 +1,40 @@
+Device Tree Clock bindings for Texas Instrument's OMAP compatible platforms
+
+This binding is an initial minimal binding that may be enhanced as part of
+transitioning OMAP clock data out of kernel image.
+
+This binding uses the common clock binding[1].
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties:
+- compatible : shall be "ti,omap-clock"
+- #clock-cells : from common clock binding; shall be set to 0.
+NOTE:
+node name should map to clock database in arch/arm/mach-omap2/cclock<SoC>_data.c
+Since all clocks are described with _ck, the node name is optimized to drop the
+usage of _ck. For example, a clock called dpll1_ck will be defined as dpll1.
+
+Example #1: describing clock node for CPU on OMAP34xx platform:
+Ref: arch/arm/mach-omap2/cclock3xxx_data.c
+describes the CPU clock to be as follows
+	CLK(NULL,	"dpll1_ck",	&dpll1_ck,	CK_3XXX),
+Corresponding binding will be:
+	dpll1: dpll1 {
+		#clock-cells = <0>;
+		compatible = "ti,omap-clock";
+	};
+And it's usage will be:
+		clocks = <&dpll1>;
+
+Example #2: describing clock node for auxilary clock #3 on OMAP443x platform:
+Ref: arch/arm/mach-omap2/cclock44xx_data.c
+describes the auxclk3 clock to be as follows:
+	CLK(NULL,	"auxclk3_ck",	&auxclk3_ck,	CK_443X),
+Corresponding binding will be:
+	auxclk3: auxclk3 {
+		#clock-cells = <0>;
+		compatible = "ti,omap-clock";
+	};
+And it's usage will be:
+	clocks = <&auxclk3>;
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index e7f7fe9..dbf9b13 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -29,6 +29,7 @@ obj-$(CONFIG_ARCH_U8500)	+= ux500/
 obj-$(CONFIG_ARCH_VT8500)	+= clk-vt8500.o
 obj-$(CONFIG_ARCH_ZYNQ)		+= clk-zynq.o
 obj-$(CONFIG_ARCH_TEGRA)	+= tegra/
+obj-$(CONFIG_ARCH_OMAP)		+= omap/
 
 obj-$(CONFIG_X86)		+= x86/
 
diff --git a/drivers/clk/omap/Makefile b/drivers/clk/omap/Makefile
new file mode 100644
index 0000000..8195931
--- /dev/null
+++ b/drivers/clk/omap/Makefile
@@ -0,0 +1 @@
+obj-y					+= clk.o
diff --git a/drivers/clk/omap/clk.c b/drivers/clk/omap/clk.c
new file mode 100644
index 0000000..6f12023
--- /dev/null
+++ b/drivers/clk/omap/clk.c
@@ -0,0 +1,96 @@
+/*
+ * Texas Instruments OMAP Clock driver
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ *	Nishanth Menon <nm at ti.com>
+ *	Tony Lindgren <tony at atomide.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.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/clkdev.h>
+#include <linux/clk-provider.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include <linux/string.h>
+
+static const struct of_device_id omap_clk_of_match[] = {
+	{.compatible = "ti,omap-clock",},
+	{},
+};
+
+/**
+ * omap_clk_src_get() - Get OMAP clock from node name when needed
+ * @clkspec:	clkspec argument
+ * @data:	unused
+ *
+ * REVISIT: We assume the following:
+ * 1. omap clock names end with _ck
+ * 2. omap clock names are under 32 characters in length
+ */
+static struct clk *omap_clk_src_get(struct of_phandle_args *clkspec, void *data)
+{
+	struct clk *clk;
+	char clk_name[32];
+	struct device_node *np = clkspec->np;
+
+	/* Set up things so consumer can call clk_get() with name */
+	snprintf(clk_name, 32, "%s_ck", np->name);
+	clk = clk_get(NULL, clk_name);
+	if (IS_ERR(clk)) {
+		pr_err("%s: could not get clock %s(%ld)\n", __func__,
+		       clk_name, PTR_ERR(clk));
+		goto out;
+	}
+	clk_put(clk);
+
+out:
+	return clk;
+}
+
+/**
+ * omap_clk_probe() - create link from DT definition to clock data
+ * @pdev:	device node
+ *
+ * NOTE: We assume that omap clocks are not removed.
+ */
+static int omap_clk_probe(struct platform_device *pdev)
+{
+	int res;
+	struct device_node *np = pdev->dev.of_node;
+
+	/* This allows the driver to of_clk_get() */
+	res = of_clk_add_provider(np, omap_clk_src_get, NULL);
+	if (res)
+		dev_err(&pdev->dev, "could not add provider(%d)\n", res);
+
+	return res;
+}
+
+/* We assume here that OMAP clocks will not be removed */
+static struct platform_driver omap_clk_driver = {
+	.probe = omap_clk_probe,
+	.driver = {
+		   .name = "omap_clk",
+		   .of_match_table = of_match_ptr(omap_clk_of_match),
+		   },
+};
+
+static int __init omap_clk_init(void)
+{
+	return platform_driver_register(&omap_clk_driver);
+}
+arch_initcall(omap_clk_init);
+
+MODULE_DESCRIPTION("OMAP Clock driver");
+MODULE_AUTHOR("Texas Instruments Inc.");
+MODULE_LICENSE("GPL v2");
-- 
1.7.9.5



From nm at ti.com  Fri Apr 12 18:54:35 2013
From: nm at ti.com (Nishanth Menon)
Date: Fri, 12 Apr 2013 17:54:35 -0500
Subject: [PATCH V4 3/6] ARM: dts: OMAP4: add clock nodes for CPU
In-Reply-To: <1365807278-554-1-git-send-email-nm@ti.com>
References: <1365807278-554-1-git-send-email-nm@ti.com>
Message-ID: <1365807278-554-4-git-send-email-nm@ti.com>

OMAP443x, OMAP446x and OMAP447x platforms use dpll_mpu clock.
Add same to common definition.

Cc: Benoit Cousson <b-cousson at ti.com>
Signed-off-by: Nishanth Menon <nm at ti.com>
---
RFC of this patch approach for OMAP3 was discussed in http://marc.info/?t=136370325600009&r=1&w=2
along with the detailed context as to why this is an intermediate step.

previous revisions of cpufreq-cpu0 support do not use this approach.
[Probably belongs to Benoit's tree]

 arch/arm/boot/dts/omap4.dtsi |    7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 2a56428..1c6d969 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -31,6 +31,8 @@
 		cpu at 0 {
 			compatible = "arm,cortex-a9";
 			next-level-cache = <&L2>;
+			clocks = <&dpll_mpu>;
+			clock-names = "cpu";
 		};
 		cpu at 1 {
 			compatible = "arm,cortex-a9";
@@ -106,6 +108,11 @@
 			ti,hwmods = "counter_32k";
 		};
 
+		dpll_mpu: dpll_mpu {
+			#clock-cells = <0>;
+			compatible = "ti,omap-clock";
+		};
+
 		omap4_pmx_core: pinmux at 4a100040 {
 			compatible = "ti,omap4-padconf", "pinctrl-single";
 			reg = <0x4a100040 0x0196>;
-- 
1.7.9.5



From nm at ti.com  Fri Apr 12 18:54:36 2013
From: nm at ti.com (Nishanth Menon)
Date: Fri, 12 Apr 2013 17:54:36 -0500
Subject: [PATCH V4 4/6] ARM: dts: AM33XX: add clock nodes for CPU
In-Reply-To: <1365807278-554-1-git-send-email-nm@ti.com>
References: <1365807278-554-1-git-send-email-nm@ti.com>
Message-ID: <1365807278-554-5-git-send-email-nm@ti.com>

AM33XX based platforms use dpll_mpu clock. Add same to common dtsi
and remove the dummy clock node entry as AM33XX platform supports
only device tree based boot.

Cc: Benoit Cousson <b-cousson at ti.com>
Cc: Kevin Hilman <khilman at deeprootsystems.com>
Cc: Paul Walmsley <paul at pwsan.com>
Cc: Tony Lindgren <tony at atomide.com>
Signed-off-by: Nishanth Menon <nm at ti.com>
---
RFC of this patch was discussed in http://marc.info/?t=136370325600009&r=1&w=2
along with the detailed context as to why this is an intermediate step.

previous revisions of cpufreq-cpu0 support do not use this approach.

[Probably belongs to Benoit/Tony/Paul tree?]

 arch/arm/boot/dts/am33xx.dtsi         |    7 +++++++
 arch/arm/mach-omap2/cclock33xx_data.c |    1 -
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index df62830..3aed044 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -42,6 +42,8 @@
 				275000  1125000
 			>;
 			voltage-tolerance = <2>; /* 2 percentage */
+			clocks = <&dpll_mpu>;
+			clock-names = "cpu";
 			clock-latency = <300000>; /* From omap-cpufreq driver */
 		};
 	};
@@ -89,6 +91,11 @@
 			reg = <0x48200000 0x1000>;
 		};
 
+		dpll_mpu: dpll_mpu {
+			#clock-cells = <0>;
+			compatible = "ti,omap-clock";
+		};
+
 		gpio0: gpio at 44e07000 {
 			compatible = "ti,omap4-gpio";
 			ti,hwmods = "gpio1";
diff --git a/arch/arm/mach-omap2/cclock33xx_data.c b/arch/arm/mach-omap2/cclock33xx_data.c
index 7f091c8..8be6832 100644
--- a/arch/arm/mach-omap2/cclock33xx_data.c
+++ b/arch/arm/mach-omap2/cclock33xx_data.c
@@ -852,7 +852,6 @@ static struct omap_clk am33xx_clks[] = {
 	CLK(NULL,	"dpll_core_m5_ck",	&dpll_core_m5_ck,	CK_AM33XX),
 	CLK(NULL,	"dpll_core_m6_ck",	&dpll_core_m6_ck,	CK_AM33XX),
 	CLK(NULL,	"dpll_mpu_ck",		&dpll_mpu_ck,	CK_AM33XX),
-	CLK("cpu0",	NULL,			&dpll_mpu_ck,	CK_AM33XX),
 	CLK(NULL,	"dpll_mpu_m2_ck",	&dpll_mpu_m2_ck,	CK_AM33XX),
 	CLK(NULL,	"dpll_ddr_ck",		&dpll_ddr_ck,	CK_AM33XX),
 	CLK(NULL,	"dpll_ddr_m2_ck",	&dpll_ddr_m2_ck,	CK_AM33XX),
-- 
1.7.9.5



From nm at ti.com  Fri Apr 12 18:54:38 2013
From: nm at ti.com (Nishanth Menon)
Date: Fri, 12 Apr 2013 17:54:38 -0500
Subject: [PATCH V4 6/6] ARM: OMAP3+: use cpu0-cpufreq driver in device tree
 supported boot
In-Reply-To: <1365807278-554-1-git-send-email-nm@ti.com>
References: <1365807278-554-1-git-send-email-nm@ti.com>
Message-ID: <1365807278-554-7-git-send-email-nm@ti.com>

With OMAP3+ and AM33xx supported SoC having defined CPU device tree
entries with operating-points and clock nodes defined, we can now use
the SoC generic cpufreq-cpu0 driver by registering appropriate device.

Cc: Benoit Cousson <b-cousson at ti.com>
Cc: Kevin Hilman <khilman at deeprootsystems.com>
Cc: Paul Walmsley <paul at pwsan.com>
Cc: Tony Lindgren <tony at atomide.com>
Signed-off-by: Nishanth Menon <nm at ti.com>
---
Introduced as a result of alignment in http://marc.info/?t=136450773400004&r=1&w=2
previous versions do not use this approach.

This would probably be good to get merged *after* Rafael's tree is merged in.

[Probably belongs to Kevin/Tony's tree?]

 arch/arm/mach-omap2/pm.c |   11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index 8d15f9a..6cf95160 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -267,7 +267,12 @@ static void __init omap4_init_voltages(void)
 
 static inline void omap_init_cpufreq(void)
 {
-	struct platform_device_info devinfo = { .name = "omap-cpufreq", };
+	struct platform_device_info devinfo = { };
+
+	if (!of_have_populated_dt())
+		devinfo.name = "omap-cpufreq";
+	else
+		devinfo.name = "cpufreq-cpu0";
 	platform_device_register_full(&devinfo);
 }
 
@@ -301,9 +306,9 @@ int __init omap2_common_pm_late_init(void)
 		/* Smartreflex device init */
 		omap_devinit_smartreflex();
 
-		/* cpufreq dummy device instantiation */
-		omap_init_cpufreq();
 	}
+	/* cpufreq dummy device instantiation */
+	omap_init_cpufreq();
 
 #ifdef CONFIG_SUSPEND
 	suspend_set_ops(&omap_pm_ops);
-- 
1.7.9.5



From nm at ti.com  Fri Apr 12 18:54:37 2013
From: nm at ti.com (Nishanth Menon)
Date: Fri, 12 Apr 2013 17:54:37 -0500
Subject: [PATCH V4 5/6] ARM: OMAP2+: AM33XX: add lateinit hook for calling pm
 late init
In-Reply-To: <1365807278-554-1-git-send-email-nm@ti.com>
References: <1365807278-554-1-git-send-email-nm@ti.com>
Message-ID: <1365807278-554-6-git-send-email-nm@ti.com>

Call OMAP2+ generic lateinit hook from AM specific late init hook.
This allows the generic late initializations such as cpufreq hooks
to be active.

Cc: Benoit Cousson <b-cousson at ti.com>
Cc: Kevin Hilman <khilman at deeprootsystems.com>
Cc: Paul Walmsley <paul at pwsan.com>
Cc: Tony Lindgren <tony at atomide.com>
Signed-off-by: Nishanth Menon <nm at ti.com>
---
Introduced as a result of alignment in http://marc.info/?t=136450773400004&r=1&w=2
previous versions do not use this approach.

[Probably belongs to Kevin/Tony's tree?]
 arch/arm/mach-omap2/board-generic.c |    1 +
 arch/arm/mach-omap2/common.h        |    1 +
 arch/arm/mach-omap2/io.c            |    6 ++++++
 3 files changed, 8 insertions(+)

diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.c
index afa509a..86e8479 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -141,6 +141,7 @@ DT_MACHINE_START(AM33XX_DT, "Generic AM33XX (Flattened Device Tree)")
 	.init_irq	= omap_intc_of_init,
 	.handle_irq	= omap3_intc_handle_irq,
 	.init_machine	= omap_generic_init,
+	.init_late	= am33xx_init_late,
 	.init_time	= omap3_am33xx_gptimer_timer_init,
 	.dt_compat	= am33xx_boards_compat,
 	.restart	= am33xx_restart,
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 14522d0..65f2ebc 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -108,6 +108,7 @@ void omap35xx_init_late(void);
 void omap3630_init_late(void);
 void am35xx_init_late(void);
 void ti81xx_init_late(void);
+void am33xx_init_late(void);
 int omap2_common_pm_late_init(void);
 
 #if defined(CONFIG_SOC_OMAP2420) || defined(CONFIG_SOC_OMAP2430)
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 5c445ca..61f5b84 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -576,6 +576,12 @@ void __init am33xx_init_early(void)
 	omap_hwmod_init_postsetup();
 	omap_clk_init = am33xx_clk_init;
 }
+
+void __init am33xx_init_late(void)
+{
+	omap2_common_pm_late_init();
+}
+
 #endif
 
 #ifdef CONFIG_ARCH_OMAP4
-- 
1.7.9.5



From sergei.shtylyov at cogentembedded.com  Fri Apr 12 19:07:05 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Sat, 13 Apr 2013 03:07:05 +0400
Subject: [PATCH v2 0/9] Reorganize R8A7779/Marzen USB code
In-Reply-To: <87txnfjhmu.wl%kuninori.morimoto.gx@renesas.com>
References: <201304090110.50154.sergei.shtylyov@cogentembedded.com>
 <87zjx89rfb.wl%kuninori.morimoto.gx@renesas.com>
 <51640D21.3090800@cogentembedded.com>
 <87txnfjhmu.wl%kuninori.morimoto.gx@renesas.com>
Message-ID: <51689399.5090203@cogentembedded.com>

Hello.

On 04/10/2013 05:31 AM, Kuninori Morimoto wrote:

>
>>> Please add this "tested on xxx" comment on each patch's log area, not only on [0/x].
>>> We need it on "git log"
>>      I'm going to post R8A7778/BOCK-W series following this one, and all the
>> patches in 1st series should additionally be tested on BOCK-W. Well, I
>> probably can hold up posting version 3 until I have the second series verified.
>>      BTW, about R8A7778/BOCK-W, R-Car M1A user manual talks about a ferrite
>> bead in 49.4.1 (3) Setting USB-PHY. Do you know for sure if it's used or not
>> on BOCK-W board? PHY initialization seems to work with either settings...
> I can ask it to HW team if you want me.
> But our local BSP is using "No ferrite bead" settings...

    I've rummaged thru the BSP I have and found not traces of a ferrite bead
(and rcar-phy driver as well) in the patches...

> Best regards
> ---
> Kuninori Morimoto

WBR, Sergei



From sergei.shtylyov at cogentembedded.com  Fri Apr 12 19:11:04 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Sat, 13 Apr 2013 03:11:04 +0400
Subject: [PATCH v2 0/9] Reorganize R8A7779/Marzen USB code
In-Reply-To: <51689399.5090203@cogentembedded.com>
References: <201304090110.50154.sergei.shtylyov@cogentembedded.com>
 <87zjx89rfb.wl%kuninori.morimoto.gx@renesas.com>
 <51640D21.3090800@cogentembedded.com>
 <87txnfjhmu.wl%kuninori.morimoto.gx@renesas.com>
 <51689399.5090203@cogentembedded.com>
Message-ID: <51689488.7040109@cogentembedded.com>

On 04/13/2013 03:07 AM, I wrote:

>
>>
>>>> Please add this "tested on xxx" comment on each patch's log area, 
>>>> not only on [0/x].
>>>> We need it on "git log"
>>>      I'm going to post R8A7778/BOCK-W series following this one, and 
>>> all the
>>> patches in 1st series should additionally be tested on BOCK-W. Well, I
>>> probably can hold up posting version 3 until I have the second 
>>> series verified.
>>>      BTW, about R8A7778/BOCK-W, R-Car M1A user manual talks about a 
>>> ferrite
>>> bead in 49.4.1 (3) Setting USB-PHY. Do you know for sure if it's 
>>> used or not
>>> on BOCK-W board? PHY initialization seems to work with either 
>>> settings...
>> I can ask it to HW team if you want me.

    Yes, ask them please.

WBR, Sergei




From sergei.shtylyov at cogentembedded.com  Fri Apr 12 19:26:32 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Sat, 13 Apr 2013 03:26:32 +0400
Subject: [PATCH v4 0/9] Reorganize R8A7779/Marzen USB code
Message-ID: <201304130326.33430.sergei.shtylyov@cogentembedded.com>

Hello.

   Here's the set of 9 patches against the Simon Horman's 'renesas.git' repo,
'renesas-next-20130412' tag.  It was created to fix the shortcomings in the
R8A7779/Marzen USB platform code and R8A7779 USB common PHY driver, and so
spans both arch/arm/mach-shmobile/ and drivers/usb/ subtrees (some patches have
to touch both subtrees). The patches were conceived with the complete
bisectability goal in mind.

[1/9] ARM: shmobile: Marzen: move USB EHCI, OHCI, and PHY devices to R8A7779 code
[2/9] ehci-platform: add pre_setup() method to platform data
[3/9] ARM: shmobile: r8a7779: setup EHCI internal buffer
[4/9] rcar-phy: remove EHCI internal buffer setup
[5/9] ARM: shmobile: r8a7779: remove USB PHY 2nd memory resource
[6/9] rcar-phy: correct base address
[7/9] rcar-phy: add platform data
[8/9] ARM: shmobile: Marzen: pass platform data to USB PHY device
[9/9] rcar-phy: handle platform data

WBR, Sergei


From sergei.shtylyov at cogentembedded.com  Fri Apr 12 19:27:48 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Sat, 13 Apr 2013 03:27:48 +0400
Subject: [PATCH v4 1/9] ARM: shmobile: Marzen: move USB EHCI, OHCI,
 and PHY devices to R8A7779 code
Message-ID: <201304130327.48962.sergei.shtylyov@cogentembedded.com>

USB EHCI, OHCI, and common PHY are the SoC devices but are wrongly defined and
registered in the Marzen board file.  Move the data and code to their proper
place in setup-r8a7779.c; while at it, we have to rename 8a7779_late_devices[]
to 8a7779_standard_devices[] -- this seems legitimate since they are registered
from r8a7779_add_standard_devices() anyway.

Note that I'm deliberately changing the USB PHY platform device's 'id' field
from (previously just omitted) 0 to -1 as the device is a single of its kind.

Note also that the board and SoC code have to be in one patch to keep the code
bisectable...

The patch has been tested on the Marzen board.

Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Acked-by: Simon Horman <horms+renesas at verge.net.au>

---
Changes since version 3:
- refreshed the 'board-marzen.c' file.

Changes since version 2:
- added a note about testing to the changelog;
- added ACKs from Simon Horman and Kuninori Morimoto.

Changes since the original posting:
- added a note about bisectability to the changelog.

 arch/arm/mach-shmobile/board-marzen.c         |  178 -------------------------
 arch/arm/mach-shmobile/include/mach/r8a7779.h |    1 
 arch/arm/mach-shmobile/setup-r8a7779.c        |  185 +++++++++++++++++++++++++-
 3 files changed, 184 insertions(+), 180 deletions(-)

Index: renesas/arch/arm/mach-shmobile/board-marzen.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/board-marzen.c
+++ renesas/arch/arm/mach-shmobile/board-marzen.c
@@ -37,10 +37,6 @@
 #include <linux/mmc/host.h>
 #include <linux/mmc/sh_mobile_sdhi.h>
 #include <linux/mfd/tmio.h>
-#include <linux/usb/otg.h>
-#include <linux/usb/ehci_pdriver.h>
-#include <linux/usb/ohci_pdriver.h>
-#include <linux/pm_runtime.h>
 #include <mach/hardware.h>
 #include <mach/r8a7779.h>
 #include <mach/common.h>
@@ -150,26 +146,6 @@ static struct platform_device hspi_devic
 	.num_resources	= ARRAY_SIZE(hspi_resources),
 };
 
-/* USB PHY */
-static struct resource usb_phy_resources[] = {
-	[0] = {
-		.start		= 0xffe70000,
-		.end		= 0xffe70900 - 1,
-		.flags		= IORESOURCE_MEM,
-	},
-	[1] = {
-		.start		= 0xfff70000,
-		.end		= 0xfff70900 - 1,
-		.flags		= IORESOURCE_MEM,
-	},
-};
-
-static struct platform_device usb_phy_device = {
-	.name		= "rcar_usb_phy",
-	.resource	= usb_phy_resources,
-	.num_resources	= ARRAY_SIZE(usb_phy_resources),
-};
-
 /* LEDS */
 static struct gpio_led marzen_leds[] = {
 	{
@@ -205,161 +181,9 @@ static struct platform_device *marzen_de
 	&sdhi0_device,
 	&thermal_device,
 	&hspi_device,
-	&usb_phy_device,
 	&leds_device,
 };
 
-/* USB */
-static struct usb_phy *phy;
-static int usb_power_on(struct platform_device *pdev)
-{
-	if (!phy)
-		return -EIO;
-
-	pm_runtime_enable(&pdev->dev);
-	pm_runtime_get_sync(&pdev->dev);
-
-	usb_phy_init(phy);
-
-	return 0;
-}
-
-static void usb_power_off(struct platform_device *pdev)
-{
-	if (!phy)
-		return;
-
-	usb_phy_shutdown(phy);
-
-	pm_runtime_put_sync(&pdev->dev);
-	pm_runtime_disable(&pdev->dev);
-}
-
-static struct usb_ehci_pdata ehcix_pdata = {
-	.power_on	= usb_power_on,
-	.power_off	= usb_power_off,
-	.power_suspend	= usb_power_off,
-};
-
-static struct resource ehci0_resources[] = {
-	[0] = {
-		.start	= 0xffe70000,
-		.end	= 0xffe70400 - 1,
-		.flags	= IORESOURCE_MEM,
-	},
-	[1] = {
-		.start	= gic_iid(0x4c),
-		.flags	= IORESOURCE_IRQ,
-	},
-};
-
-static struct platform_device ehci0_device = {
-	.name	= "ehci-platform",
-	.id	= 0,
-	.dev	= {
-		.dma_mask		= &ehci0_device.dev.coherent_dma_mask,
-		.coherent_dma_mask	= 0xffffffff,
-		.platform_data		= &ehcix_pdata,
-	},
-	.num_resources	= ARRAY_SIZE(ehci0_resources),
-	.resource	= ehci0_resources,
-};
-
-static struct resource ehci1_resources[] = {
-	[0] = {
-		.start	= 0xfff70000,
-		.end	= 0xfff70400 - 1,
-		.flags	= IORESOURCE_MEM,
-	},
-	[1] = {
-		.start	= gic_iid(0x4d),
-		.flags	= IORESOURCE_IRQ,
-	},
-};
-
-static struct platform_device ehci1_device = {
-	.name	= "ehci-platform",
-	.id	= 1,
-	.dev	= {
-		.dma_mask		= &ehci1_device.dev.coherent_dma_mask,
-		.coherent_dma_mask	= 0xffffffff,
-		.platform_data		= &ehcix_pdata,
-	},
-	.num_resources	= ARRAY_SIZE(ehci1_resources),
-	.resource	= ehci1_resources,
-};
-
-static struct usb_ohci_pdata ohcix_pdata = {
-	.power_on	= usb_power_on,
-	.power_off	= usb_power_off,
-	.power_suspend	= usb_power_off,
-};
-
-static struct resource ohci0_resources[] = {
-	[0] = {
-		.start	= 0xffe70400,
-		.end	= 0xffe70800 - 1,
-		.flags	= IORESOURCE_MEM,
-	},
-	[1] = {
-		.start	= gic_iid(0x4c),
-		.flags	= IORESOURCE_IRQ,
-	},
-};
-
-static struct platform_device ohci0_device = {
-	.name	= "ohci-platform",
-	.id	= 0,
-	.dev	= {
-		.dma_mask		= &ohci0_device.dev.coherent_dma_mask,
-		.coherent_dma_mask	= 0xffffffff,
-		.platform_data		= &ohcix_pdata,
-	},
-	.num_resources	= ARRAY_SIZE(ohci0_resources),
-	.resource	= ohci0_resources,
-};
-
-static struct resource ohci1_resources[] = {
-	[0] = {
-		.start	= 0xfff70400,
-		.end	= 0xfff70800 - 1,
-		.flags	= IORESOURCE_MEM,
-	},
-	[1] = {
-		.start	= gic_iid(0x4d),
-		.flags	= IORESOURCE_IRQ,
-	},
-};
-
-static struct platform_device ohci1_device = {
-	.name	= "ohci-platform",
-	.id	= 1,
-	.dev	= {
-		.dma_mask		= &ohci1_device.dev.coherent_dma_mask,
-		.coherent_dma_mask	= 0xffffffff,
-		.platform_data		= &ohcix_pdata,
-	},
-	.num_resources	= ARRAY_SIZE(ohci1_resources),
-	.resource	= ohci1_resources,
-};
-
-static struct platform_device *marzen_late_devices[] __initdata = {
-	&ehci0_device,
-	&ehci1_device,
-	&ohci0_device,
-	&ohci1_device,
-};
-
-void __init marzen_init_late(void)
-{
-	/* get usb phy */
-	phy = usb_get_phy(USB_PHY_TYPE_USB2);
-
-	shmobile_init_late();
-	platform_add_devices(marzen_late_devices,
-			     ARRAY_SIZE(marzen_late_devices));
-}
-
 static const struct pinctrl_map marzen_pinctrl_map[] = {
 	/* HSPI0 */
 	PIN_MAP_MUX_GROUP_DEFAULT("sh-hspi.0", "pfc-r8a7779",
@@ -417,6 +241,6 @@ MACHINE_START(MARZEN, "marzen")
 	.nr_irqs	= NR_IRQS_LEGACY,
 	.init_irq	= r8a7779_init_irq,
 	.init_machine	= marzen_init,
-	.init_late	= marzen_init_late,
+	.init_late	= r8a7779_init_late,
 	.init_time	= r8a7779_earlytimer_init,
 MACHINE_END
Index: renesas/arch/arm/mach-shmobile/include/mach/r8a7779.h
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/include/mach/r8a7779.h
+++ renesas/arch/arm/mach-shmobile/include/mach/r8a7779.h
@@ -33,6 +33,7 @@ extern void r8a7779_add_early_devices(vo
 extern void r8a7779_add_standard_devices(void);
 extern void r8a7779_add_standard_devices_dt(void);
 extern void r8a7779_add_ether_device(struct sh_eth_plat_data *pdata);
+extern void r8a7779_init_late(void);
 extern void r8a7779_clock_init(void);
 extern void r8a7779_pinmux_init(void);
 extern void r8a7779_pm_init(void);
Index: renesas/arch/arm/mach-shmobile/setup-r8a7779.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/setup-r8a7779.c
+++ renesas/arch/arm/mach-shmobile/setup-r8a7779.c
@@ -32,6 +32,10 @@
 #include <linux/sh_intc.h>
 #include <linux/sh_timer.h>
 #include <linux/dma-mapping.h>
+#include <linux/usb/otg.h>
+#include <linux/usb/ehci_pdriver.h>
+#include <linux/usb/ohci_pdriver.h>
+#include <linux/pm_runtime.h>
 #include <mach/hardware.h>
 #include <mach/irqs.h>
 #include <mach/r8a7779.h>
@@ -394,6 +398,162 @@ static struct platform_device sata_devic
 	},
 };
 
+/* USB PHY */
+static struct resource usb_phy_resources[] = {
+	[0] = {
+		.start		= 0xffe70000,
+		.end		= 0xffe70900 - 1,
+		.flags		= IORESOURCE_MEM,
+	},
+	[1] = {
+		.start		= 0xfff70000,
+		.end		= 0xfff70900 - 1,
+		.flags		= IORESOURCE_MEM,
+	},
+};
+
+static struct platform_device usb_phy_device = {
+	.name		= "rcar_usb_phy",
+	.id		= -1,
+	.resource	= usb_phy_resources,
+	.num_resources	= ARRAY_SIZE(usb_phy_resources),
+};
+
+/* USB */
+static struct usb_phy *phy;
+
+static int usb_power_on(struct platform_device *pdev)
+{
+	if (!phy)
+		return -EIO;
+
+	pm_runtime_enable(&pdev->dev);
+	pm_runtime_get_sync(&pdev->dev);
+
+	usb_phy_init(phy);
+
+	return 0;
+}
+
+static void usb_power_off(struct platform_device *pdev)
+{
+	if (!phy)
+		return;
+
+	usb_phy_shutdown(phy);
+
+	pm_runtime_put_sync(&pdev->dev);
+	pm_runtime_disable(&pdev->dev);
+}
+
+static struct usb_ehci_pdata ehcix_pdata = {
+	.power_on	= usb_power_on,
+	.power_off	= usb_power_off,
+	.power_suspend	= usb_power_off,
+};
+
+static struct resource ehci0_resources[] = {
+	[0] = {
+		.start	= 0xffe70000,
+		.end	= 0xffe70400 - 1,
+		.flags	= IORESOURCE_MEM,
+	},
+	[1] = {
+		.start	= gic_iid(0x4c),
+		.flags	= IORESOURCE_IRQ,
+	},
+};
+
+static struct platform_device ehci0_device = {
+	.name	= "ehci-platform",
+	.id	= 0,
+	.dev	= {
+		.dma_mask		= &ehci0_device.dev.coherent_dma_mask,
+		.coherent_dma_mask	= 0xffffffff,
+		.platform_data		= &ehcix_pdata,
+	},
+	.num_resources	= ARRAY_SIZE(ehci0_resources),
+	.resource	= ehci0_resources,
+};
+
+static struct resource ehci1_resources[] = {
+	[0] = {
+		.start	= 0xfff70000,
+		.end	= 0xfff70400 - 1,
+		.flags	= IORESOURCE_MEM,
+	},
+	[1] = {
+		.start	= gic_iid(0x4d),
+		.flags	= IORESOURCE_IRQ,
+	},
+};
+
+static struct platform_device ehci1_device = {
+	.name	= "ehci-platform",
+	.id	= 1,
+	.dev	= {
+		.dma_mask		= &ehci1_device.dev.coherent_dma_mask,
+		.coherent_dma_mask	= 0xffffffff,
+		.platform_data		= &ehcix_pdata,
+	},
+	.num_resources	= ARRAY_SIZE(ehci1_resources),
+	.resource	= ehci1_resources,
+};
+
+static struct usb_ohci_pdata ohcix_pdata = {
+	.power_on	= usb_power_on,
+	.power_off	= usb_power_off,
+	.power_suspend	= usb_power_off,
+};
+
+static struct resource ohci0_resources[] = {
+	[0] = {
+		.start	= 0xffe70400,
+		.end	= 0xffe70800 - 1,
+		.flags	= IORESOURCE_MEM,
+	},
+	[1] = {
+		.start	= gic_iid(0x4c),
+		.flags	= IORESOURCE_IRQ,
+	},
+};
+
+static struct platform_device ohci0_device = {
+	.name	= "ohci-platform",
+	.id	= 0,
+	.dev	= {
+		.dma_mask		= &ohci0_device.dev.coherent_dma_mask,
+		.coherent_dma_mask	= 0xffffffff,
+		.platform_data		= &ohcix_pdata,
+	},
+	.num_resources	= ARRAY_SIZE(ohci0_resources),
+	.resource	= ohci0_resources,
+};
+
+static struct resource ohci1_resources[] = {
+	[0] = {
+		.start	= 0xfff70400,
+		.end	= 0xfff70800 - 1,
+		.flags	= IORESOURCE_MEM,
+	},
+	[1] = {
+		.start	= gic_iid(0x4d),
+		.flags	= IORESOURCE_IRQ,
+	},
+};
+
+static struct platform_device ohci1_device = {
+	.name	= "ohci-platform",
+	.id	= 1,
+	.dev	= {
+		.dma_mask		= &ohci1_device.dev.coherent_dma_mask,
+		.coherent_dma_mask	= 0xffffffff,
+		.platform_data		= &ohcix_pdata,
+	},
+	.num_resources	= ARRAY_SIZE(ohci1_resources),
+	.resource	= ohci1_resources,
+};
+
 /* Ether */
 static struct resource ether_resources[] = {
 	{
@@ -415,9 +575,10 @@ static struct platform_device *r8a7779_d
 	&scif5_device,
 	&tmu00_device,
 	&tmu01_device,
+	&usb_phy_device,
 };
 
-static struct platform_device *r8a7779_late_devices[] __initdata = {
+static struct platform_device *r8a7779_standard_devices[] __initdata = {
 	&i2c0_device,
 	&i2c1_device,
 	&i2c2_device,
@@ -437,8 +598,8 @@ void __init r8a7779_add_standard_devices
 
 	platform_add_devices(r8a7779_devices_dt,
 			    ARRAY_SIZE(r8a7779_devices_dt));
-	platform_add_devices(r8a7779_late_devices,
-			    ARRAY_SIZE(r8a7779_late_devices));
+	platform_add_devices(r8a7779_standard_devices,
+			    ARRAY_SIZE(r8a7779_standard_devices));
 }
 
 void __init r8a7779_add_ether_device(struct sh_eth_plat_data *pdata)
@@ -481,6 +642,23 @@ void __init r8a7779_add_early_devices(vo
 	 */
 }
 
+static struct platform_device *r8a7779_late_devices[] __initdata = {
+	&ehci0_device,
+	&ehci1_device,
+	&ohci0_device,
+	&ohci1_device,
+};
+
+void __init r8a7779_init_late(void)
+{
+	/* get USB PHY */
+	phy = usb_get_phy(USB_PHY_TYPE_USB2);
+
+	shmobile_init_late();
+	platform_add_devices(r8a7779_late_devices,
+			     ARRAY_SIZE(r8a7779_late_devices));
+}
+
 #ifdef CONFIG_USE_OF
 void __init r8a7779_init_delay(void)
 {
@@ -514,6 +692,7 @@ DT_MACHINE_START(R8A7779_DT, "Generic R8
 	.init_irq	= r8a7779_init_irq_dt,
 	.init_machine	= r8a7779_add_standard_devices_dt,
 	.init_time	= shmobile_timer_init,
+	.init_late	= r8a7779_init_late,
 	.dt_compat	= r8a7779_compat_dt,
 MACHINE_END
 #endif /* CONFIG_USE_OF */


From sergei.shtylyov at cogentembedded.com  Fri Apr 12 19:29:46 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Sat, 13 Apr 2013 03:29:46 +0400
Subject: [PATCH v4 3/9] ARM: shmobile: r8a7779: setup EHCI internal buffer
Message-ID: <201304130329.47389.sergei.shtylyov@cogentembedded.com>

Setup the EHCI internal buffer (before EHCI driver has a chance to touch the
registers) using the pre_setup() method in 'struct usb_ehci_pdata'.

The patch has been tested on the Marzen board.

Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Acked-by: Simon Horman <horms+renesas at verge.net.au>

---
Changes since version 3:
- lowercased the SoC name in the subject.

Changes since version 2:
- added #include <linux/usb/hcd.h>;
- added a note about testing to the changelog;
- added ACKs from Simon Horman and Kuninori Morimoto.

Changes since the original posting:
- changed from init() platform device method to pre_setup() as per the previous
  patch.

 arch/arm/mach-shmobile/setup-r8a7779.c |   16 ++++++++++++++++
 1 file changed, 16 insertions(+)

Index: renesas/arch/arm/mach-shmobile/setup-r8a7779.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/setup-r8a7779.c
+++ renesas/arch/arm/mach-shmobile/setup-r8a7779.c
@@ -33,6 +33,7 @@
 #include <linux/sh_timer.h>
 #include <linux/dma-mapping.h>
 #include <linux/usb/otg.h>
+#include <linux/usb/hcd.h>
 #include <linux/usb/ehci_pdriver.h>
 #include <linux/usb/ohci_pdriver.h>
 #include <linux/pm_runtime.h>
@@ -446,10 +447,25 @@ static void usb_power_off(struct platfor
 	pm_runtime_disable(&pdev->dev);
 }
 
+static int ehci_init_internal_buffer(struct usb_hcd *hcd)
+{
+	/*
+	 * Below are recommended values from the datasheet;
+	 * see [USB :: Setting of EHCI Internal Buffer].
+	 */
+	/* EHCI IP internal buffer setting */
+	iowrite32(0x00ff0040, hcd->regs + 0x0094);
+	/* EHCI IP internal buffer enable */
+	iowrite32(0x00000001, hcd->regs + 0x009C);
+
+	return 0;
+}
+
 static struct usb_ehci_pdata ehcix_pdata = {
 	.power_on	= usb_power_on,
 	.power_off	= usb_power_off,
 	.power_suspend	= usb_power_off,
+	.pre_setup	= ehci_init_internal_buffer,
 };
 
 static struct resource ehci0_resources[] = {


From tony at atomide.com  Fri Apr 12 19:31:43 2013
From: tony at atomide.com (Tony Lindgren)
Date: Fri, 12 Apr 2013 16:31:43 -0700
Subject: [PATCH V4 1/6] clk: OMAP: introduce device tree binding to
 kernel clock data
In-Reply-To: <1365807278-554-2-git-send-email-nm@ti.com>
References: <1365807278-554-1-git-send-email-nm@ti.com>
 <1365807278-554-2-git-send-email-nm@ti.com>
Message-ID: <20130412233142.GE10155@atomide.com>

* Nishanth Menon <nm at ti.com> [130412 15:59]:
> --- /dev/null
> +++ b/drivers/clk/omap/clk.c
> +/**
> + * omap_clk_src_get() - Get OMAP clock from node name when needed
> + * @clkspec:	clkspec argument
> + * @data:	unused
> + *
> + * REVISIT: We assume the following:
> + * 1. omap clock names end with _ck
> + * 2. omap clock names are under 32 characters in length
> + */
> +static struct clk *omap_clk_src_get(struct of_phandle_args *clkspec, void *data)
> +{
> +	struct clk *clk;
> +	char clk_name[32];
> +	struct device_node *np = clkspec->np;
> +
> +	/* Set up things so consumer can call clk_get() with name */

I would leave out the comment above, it's a leftover from
the clk_add_alias() version that we don't need because of
of_clk_get().

> +	snprintf(clk_name, 32, "%s_ck", np->name);
> +	clk = clk_get(NULL, clk_name);
> +	if (IS_ERR(clk)) {
> +		pr_err("%s: could not get clock %s(%ld)\n", __func__,
> +		       clk_name, PTR_ERR(clk));
> +		goto out;
> +	}
> +	clk_put(clk);
> +
> +out:
> +	return clk;
> +}
> +
> +/**
> + * omap_clk_probe() - create link from DT definition to clock data
> + * @pdev:	device node
> + *
> + * NOTE: We assume that omap clocks are not removed.
> + */

How about drop the comment on clocks being removed above.
It no longer an issue, so maybe something like this instead:

* Note that we look up the clock lazily when the consumer
* driver does of_clk_get() and initialize a NULL clock here.

> +static int omap_clk_probe(struct platform_device *pdev)
> +{
> +	int res;
> +	struct device_node *np = pdev->dev.of_node;
> +
> +	/* This allows the driver to of_clk_get() */
> +	res = of_clk_add_provider(np, omap_clk_src_get, NULL);
> +	if (res)
> +		dev_err(&pdev->dev, "could not add provider(%d)\n", res);
> +
> +	return res;
> +}
> +
> +/* We assume here that OMAP clocks will not be removed */

Then the above comment can be removed too.

Regards,

Tony


From sergei.shtylyov at cogentembedded.com  Fri Apr 12 19:31:31 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Sat, 13 Apr 2013 03:31:31 +0400
Subject: [PATCH v4 4/9] rcar-phy: remove EHCI internal buffer setup
Message-ID: <201304130331.31834.sergei.shtylyov@cogentembedded.com>

Now that the EHCI internal  buffer setup is done by the platform code, we  can
remove  such code from this driver as it  never  really belonged here.  We also
no longer need the 2nd memory region now (2nd EHCI controller is simply missing
in e.g. R8A7778 SoC).

The patch has been tested on the Marzen and BOCK-W boards.

Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Acked-by: Simon Horman <horms+renesas at verge.net.au>

---
Changes since version 2:
- added a note about testing to the changelog;
- added ACKs from Simon Horman and Kuninori Morimoto.

Changes since the original posting:
- split R8A7779 SoC file change to a separate patch.

 drivers/usb/phy/rcar-phy.c |   28 ++++------------------------
 1 file changed, 4 insertions(+), 24 deletions(-)

Index: renesas/drivers/usb/phy/rcar-phy.c
===================================================================
--- renesas.orig/drivers/usb/phy/rcar-phy.c
+++ renesas/drivers/usb/phy/rcar-phy.c
@@ -23,8 +23,6 @@
 #define USBEH0		0x080C
 #define USBOH0		0x081C
 #define USBCTL0		0x0858
-#define EIIBC1		0x0094
-#define EIIBC2		0x009C
 
 /* USBPCTRL1 */
 #define PHY_RST		(1 << 2)
@@ -40,7 +38,6 @@ struct rcar_usb_phy_priv {
 	spinlock_t lock;
 
 	void __iomem *reg0;
-	void __iomem *reg1;
 	int counter;
 };
 
@@ -59,7 +56,6 @@ static int rcar_usb_phy_init(struct usb_
 	struct rcar_usb_phy_priv *priv = usb_phy_to_priv(phy);
 	struct device *dev = phy->dev;
 	void __iomem *reg0 = priv->reg0;
-	void __iomem *reg1 = priv->reg1;
 	int i;
 	u32 val;
 	unsigned long flags;
@@ -97,19 +93,6 @@ static int rcar_usb_phy_init(struct usb_
 		iowrite32(0x00000000, (reg0 + USBPCTRL0));
 
 		/*
-		 * EHCI IP internal buffer setting
-		 * EHCI IP internal buffer enable
-		 *
-		 * These are recommended value of a datasheet
-		 * see [USB :: EHCI internal buffer setting]
-		 */
-		iowrite32(0x00ff0040, (reg0 + EIIBC1));
-		iowrite32(0x00ff0040, (reg1 + EIIBC1));
-
-		iowrite32(0x00000001, (reg0 + EIIBC2));
-		iowrite32(0x00000001, (reg1 + EIIBC2));
-
-		/*
 		 * Bus alignment settings
 		 */
 
@@ -145,14 +128,13 @@ static void rcar_usb_phy_shutdown(struct
 static int rcar_usb_phy_probe(struct platform_device *pdev)
 {
 	struct rcar_usb_phy_priv *priv;
-	struct resource *res0, *res1;
+	struct resource *res0;
 	struct device *dev = &pdev->dev;
-	void __iomem *reg0, *reg1;
+	void __iomem *reg0;
 	int ret;
 
 	res0 = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-	res1 = platform_get_resource(pdev, IORESOURCE_MEM, 1);
-	if (!res0 || !res1) {
+	if (!res0) {
 		dev_err(dev, "Not enough platform resources\n");
 		return -EINVAL;
 	}
@@ -164,8 +146,7 @@ static int rcar_usb_phy_probe(struct pla
 	 * this driver can't use devm_request_and_ioremap(dev, res) here
 	 */
 	reg0 = devm_ioremap_nocache(dev, res0->start, resource_size(res0));
-	reg1 = devm_ioremap_nocache(dev, res1->start, resource_size(res1));
-	if (!reg0 || !reg1) {
+	if (!reg0) {
 		dev_err(dev, "ioremap error\n");
 		return -ENOMEM;
 	}
@@ -177,7 +158,6 @@ static int rcar_usb_phy_probe(struct pla
 	}
 
 	priv->reg0		= reg0;
-	priv->reg1		= reg1;
 	priv->counter		= 0;
 	priv->phy.dev		= dev;
 	priv->phy.label		= dev_name(dev);


From sergei.shtylyov at cogentembedded.com  Fri Apr 12 19:32:46 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Sat, 13 Apr 2013 03:32:46 +0400
Subject: [PATCH v4 5/9] ARM: shmobile: r8a7779: remove USB PHY 2nd memory
 resource
Message-ID: <201304130332.47246.sergei.shtylyov@cogentembedded.com>

Now that 'drivers/usb/phy/rcar-phy.c' doesn't require the second memory resource
anymore, we can remove it from the R8A7779's USB PHY platform device.

Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Acked-by: Simon Horman <horms+renesas at verge.net.au>

---
Changes since version 3:
- lowercased the SoC name in the subject.

Changes since version 2:
- refreshed atop of the prior patches;
- added a note about testing to the changelog;
- added ACKs from Simon Horman and Kuninori Morimoto.

Changes since the original posting:
- new patch in this version, split from the previous one.

 arch/arm/mach-shmobile/setup-r8a7779.c |    5 -----
 1 file changed, 5 deletions(-)

Index: renesas/arch/arm/mach-shmobile/setup-r8a7779.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/setup-r8a7779.c
+++ renesas/arch/arm/mach-shmobile/setup-r8a7779.c
@@ -406,11 +406,6 @@ static struct resource usb_phy_resources
 		.end		= 0xffe70900 - 1,
 		.flags		= IORESOURCE_MEM,
 	},
-	[1] = {
-		.start		= 0xfff70000,
-		.end		= 0xfff70900 - 1,
-		.flags		= IORESOURCE_MEM,
-	},
 };
 
 static struct platform_device usb_phy_device = {


From sergei.shtylyov at cogentembedded.com  Fri Apr 12 19:34:02 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Sat, 13 Apr 2013 03:34:02 +0400
Subject: [PATCH v4 6/9] rcar-phy: correct base address
Message-ID: <201304130334.02826.sergei.shtylyov@cogentembedded.com>

The memory region that is used by the driver overlaps EHCI and OHCI  register
regions for absolutely no reason now  -- fix it  by adding offset of 0x800 to
the base address, changing the register #define's accordingly. This has extra
positive effect that we now can use devm_ioremap_resource()...

Note that the driver and the SoC code have to be in one patch to keep the code
bisectable...

The patch has been tested on the Marzen board.

Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Acked-by: Simon Horman <horms+renesas at verge.net.au>

---
Changes since version 2:
- refreshed atop of the prior patches;
- added a note about testing to the changelog;
- added ACKs from Simon Horman and Kuninori Morimoto.

Changes since the original posting:
- added a note about bisectability to the changelog.

 arch/arm/mach-shmobile/setup-r8a7779.c |    2 +-
 drivers/usb/phy/rcar-phy.c             |   28 ++++++++++------------------
 2 files changed, 11 insertions(+), 19 deletions(-)

Index: renesas/arch/arm/mach-shmobile/setup-r8a7779.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/setup-r8a7779.c
+++ renesas/arch/arm/mach-shmobile/setup-r8a7779.c
@@ -402,7 +402,7 @@ static struct platform_device sata_devic
 /* USB PHY */
 static struct resource usb_phy_resources[] = {
 	[0] = {
-		.start		= 0xffe70000,
+		.start		= 0xffe70800,
 		.end		= 0xffe70900 - 1,
 		.flags		= IORESOURCE_MEM,
 	},
Index: renesas/drivers/usb/phy/rcar-phy.c
===================================================================
--- renesas.orig/drivers/usb/phy/rcar-phy.c
+++ renesas/drivers/usb/phy/rcar-phy.c
@@ -16,13 +16,13 @@
 #include <linux/spinlock.h>
 #include <linux/module.h>
 
-/* USBH common register */
-#define USBPCTRL0	0x0800
-#define USBPCTRL1	0x0804
-#define USBST		0x0808
-#define USBEH0		0x080C
-#define USBOH0		0x081C
-#define USBCTL0		0x0858
+/* REGS block */
+#define USBPCTRL0	0x00
+#define USBPCTRL1	0x04
+#define USBST		0x08
+#define USBEH0		0x0C
+#define USBOH0		0x1C
+#define USBCTL0		0x58
 
 /* USBPCTRL1 */
 #define PHY_RST		(1 << 2)
@@ -139,17 +139,9 @@ static int rcar_usb_phy_probe(struct pla
 		return -EINVAL;
 	}
 
-	/*
-	 * CAUTION
-	 *
-	 * Because this phy address is also mapped under OHCI/EHCI address area,
-	 * this driver can't use devm_request_and_ioremap(dev, res) here
-	 */
-	reg0 = devm_ioremap_nocache(dev, res0->start, resource_size(res0));
-	if (!reg0) {
-		dev_err(dev, "ioremap error\n");
-		return -ENOMEM;
-	}
+	reg0 = devm_ioremap_resource(dev, res0);
+	if (IS_ERR(reg0))
+		return PTR_ERR(reg0);
 
 	priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
 	if (!priv) {


From tim at krieglstein.org  Fri Apr 12 19:28:17 2013
From: tim at krieglstein.org (Tim Sander)
Date: Sat, 13 Apr 2013 01:28:17 +0200
Subject: devicetree pinmuxing on beaglebone
Message-ID: <201304130128.17892.tim@krieglstein.org>

Hi

I have a patched kernel with devicetree support. The kernel version i got 
running was 3.8.4. Unfortunatly with loads of patches.
After searching hours* for the right settings for pinmux in devicetree
i came up with the following fragment which i tried to drop into the end of 
am335x-bone.dts:

/ {
fragment at 0 {
   target = <&am33xx_pinmux>;
   __overlay__ {
      wind_pins:pinctrl-single,pins = <
         0x000  0x27      /* gpmc_ad0 = ad0 = P8-25 = gpio1_0|input, no 
pullup, gpio mux  */
         0x004  0x27      /* gpmc_ad1 = ad1 = P8-24 = gpio1_1|input, no 
pullup, gpio mux  */
         0x008  0x27      /* gpmc_ad2 = ad2 = P8-5 = gpio1_2|input, no pullup, 
gpio mux  */
         0x00c  0x27      /* gpmc_ad3 = ad3 = P8-6 = gpio1_3|input, no pullup, 
gpio mux  */
         0x020  0x27      /* gpmc_ad8  = ehrpwm2A = P8_19 = gpio0 22|input, no 
pullup, gpio mux */
      >;
   };
};
};

I am not sure if the offsets/values are correct (see below) but the dtc 
compiled without error. But i don't think it does any value checking?
But booting this thing i could not see any changes in the debugfs 
representation of the pinmux driver. Any ideas why these pinmux changes don't 
change up?

Thanks
Tim



*First the pinmux is not described in the kernel documentation for the 
beaglebone. It took me quite a while to figure out that there was an magic 
offset to of 0x800 to the first value. This was caused by a stupid 
documentation for the am3359 chip reference where page 811 (9.3.50) only 
states all functions for all mux register and refers to Table 9-10. This table 
contains the offset but the names are not very descriptive and the register 
description is empty ("?$%*!). But it says to look at the device datasheet. 
The device datasheet then says nothing about muxing but refers to a s****** 
windows tool. Please fixup the documentation TI.  


From sergei.shtylyov at cogentembedded.com  Fri Apr 12 19:36:23 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Sat, 13 Apr 2013 03:36:23 +0400
Subject: [PATCH v4 8/9] ARM: shmobile: Marzen: pass platform data to USB PHY
 device
Message-ID: <201304130336.24079.sergei.shtylyov@cogentembedded.com>

Since we're now going to setup the USBPCTRL0 register using the USB PHY device's
platform data, we now need a way to pass those platform data from the board file
to the device which is situated in setup-r8a7779.c -- and what I'm suggesting is
r8a7779_add_usb_phy_device() that will register USB PHY platform device with the
passed platform data using platform_device_register_resndata() call; creating
this function envolves deletion of 'usb_phy_device' from r8a7779_devices_dt[],
so that it will no longer be registered for the generic R8A7779 machine (where
we can't provide the platform data anyway), hence EHCI/OHCI drivers will fail
to load as well.

For the Marzen board, this new function will be called from marzen_init() to
register the USB PHY device early enough.

Note that the board and the SoC code have to be in one patch to keep the code
bisectable...

The patch has been tested on the Marzen board.

Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Acked-by: Simon Horman <horms+renesas at verge.net.au>

---
Changes since version 3:
- removed the initializer for 'usb_phy_platform_data';
- refreshed the 'board-marzen.c' file.

Changes since version 2:
- refreshed atop of the prior patches;
- added a note about testing to the changelog;
- added ACKs from Simon Horman and Kuninori Morimoto.

Changes since the original posting:
- added a note about bisectability to the changelog.

 arch/arm/mach-shmobile/board-marzen.c         |    3 +++
 arch/arm/mach-shmobile/include/mach/r8a7779.h |    2 ++
 arch/arm/mach-shmobile/setup-r8a7779.c        |   16 ++++++++--------
 3 files changed, 13 insertions(+), 8 deletions(-)

Index: renesas/arch/arm/mach-shmobile/board-marzen.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/board-marzen.c
+++ renesas/arch/arm/mach-shmobile/board-marzen.c
@@ -57,6 +57,8 @@ static struct regulator_consumer_supply 
 	REGULATOR_SUPPLY("vdd33a", "smsc911x"),
 };
 
+static struct rcar_phy_platform_data usb_phy_platform_data;
+
 /* SMSC LAN89218 */
 static struct resource smsc911x_resources[] = {
 	[0] = {
@@ -231,6 +233,7 @@ static void __init marzen_init(void)
 	r8a7779_pinmux_init();
 
 	r8a7779_add_standard_devices();
+	r8a7779_add_usb_phy_device(&usb_phy_platform_data);
 	platform_add_devices(marzen_devices, ARRAY_SIZE(marzen_devices));
 }
 
Index: renesas/arch/arm/mach-shmobile/include/mach/r8a7779.h
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/include/mach/r8a7779.h
+++ renesas/arch/arm/mach-shmobile/include/mach/r8a7779.h
@@ -4,6 +4,7 @@
 #include <linux/sh_clk.h>
 #include <linux/pm_domain.h>
 #include <linux/sh_eth.h>
+#include <linux/usb/rcar-phy.h>
 
 struct platform_device;
 
@@ -33,6 +34,7 @@ extern void r8a7779_add_early_devices(vo
 extern void r8a7779_add_standard_devices(void);
 extern void r8a7779_add_standard_devices_dt(void);
 extern void r8a7779_add_ether_device(struct sh_eth_plat_data *pdata);
+extern void r8a7779_add_usb_phy_device(struct rcar_phy_platform_data *pdata);
 extern void r8a7779_init_late(void);
 extern void r8a7779_clock_init(void);
 extern void r8a7779_pinmux_init(void);
Index: renesas/arch/arm/mach-shmobile/setup-r8a7779.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/setup-r8a7779.c
+++ renesas/arch/arm/mach-shmobile/setup-r8a7779.c
@@ -408,13 +408,6 @@ static struct resource usb_phy_resources
 	},
 };
 
-static struct platform_device usb_phy_device = {
-	.name		= "rcar_usb_phy",
-	.id		= -1,
-	.resource	= usb_phy_resources,
-	.num_resources	= ARRAY_SIZE(usb_phy_resources),
-};
-
 /* USB */
 static struct usb_phy *phy;
 
@@ -586,7 +579,6 @@ static struct platform_device *r8a7779_d
 	&scif5_device,
 	&tmu00_device,
 	&tmu01_device,
-	&usb_phy_device,
 };
 
 static struct platform_device *r8a7779_standard_devices[] __initdata = {
@@ -621,6 +613,14 @@ void __init r8a7779_add_ether_device(str
 					  pdata, sizeof(*pdata));
 }
 
+void __init r8a7779_add_usb_phy_device(struct rcar_phy_platform_data *pdata)
+{
+	platform_device_register_resndata(&platform_bus, "rcar_usb_phy", -1,
+					  usb_phy_resources,
+					  ARRAY_SIZE(usb_phy_resources),
+					  pdata, sizeof(*pdata));
+}
+
 /* do nothing for !CONFIG_SMP or !CONFIG_HAVE_TWD */
 void __init __weak r8a7779_register_twd(void) { }
 


From nm at ti.com  Fri Apr 12 19:39:00 2013
From: nm at ti.com (Nishanth Menon)
Date: Fri, 12 Apr 2013 18:39:00 -0500
Subject: [PATCH V4 1/6] clk: OMAP: introduce device tree binding to
 kernel clock data
In-Reply-To: <20130412233142.GE10155@atomide.com>
References: <1365807278-554-1-git-send-email-nm@ti.com>
 <1365807278-554-2-git-send-email-nm@ti.com>
 <20130412233142.GE10155@atomide.com>
Message-ID: <20130412233900.GA1599@kahuna>

On 16:31-20130412, Tony Lindgren wrote:
> * Nishanth Menon <nm at ti.com> [130412 15:59]:
> > --- /dev/null
> > +++ b/drivers/clk/omap/clk.c
> > +/**
> > + * omap_clk_src_get() - Get OMAP clock from node name when needed
> > + * @clkspec:	clkspec argument
> > + * @data:	unused
> > + *
> > + * REVISIT: We assume the following:
> > + * 1. omap clock names end with _ck
> > + * 2. omap clock names are under 32 characters in length
> > + */
> > +static struct clk *omap_clk_src_get(struct of_phandle_args *clkspec, void *data)
> > +{
> > +	struct clk *clk;
> > +	char clk_name[32];
> > +	struct device_node *np = clkspec->np;
> > +
> > +	/* Set up things so consumer can call clk_get() with name */
> 
> I would leave out the comment above, it's a leftover from
> the clk_add_alias() version that we don't need because of
> of_clk_get().
> 
> > +	snprintf(clk_name, 32, "%s_ck", np->name);
> > +	clk = clk_get(NULL, clk_name);
> > +	if (IS_ERR(clk)) {
> > +		pr_err("%s: could not get clock %s(%ld)\n", __func__,
> > +		       clk_name, PTR_ERR(clk));
> > +		goto out;
> > +	}
> > +	clk_put(clk);
> > +
> > +out:
> > +	return clk;
> > +}
> > +
> > +/**
> > + * omap_clk_probe() - create link from DT definition to clock data
> > + * @pdev:	device node
> > + *
> > + * NOTE: We assume that omap clocks are not removed.
> > + */
> 
> How about drop the comment on clocks being removed above.
> It no longer an issue, so maybe something like this instead:
> 
> * Note that we look up the clock lazily when the consumer
> * driver does of_clk_get() and initialize a NULL clock here.
> 
> > +static int omap_clk_probe(struct platform_device *pdev)
> > +{
> > +	int res;
> > +	struct device_node *np = pdev->dev.of_node;
> > +
> > +	/* This allows the driver to of_clk_get() */
> > +	res = of_clk_add_provider(np, omap_clk_src_get, NULL);
> > +	if (res)
> > +		dev_err(&pdev->dev, "could not add provider(%d)\n", res);
> > +
> > +	return res;
> > +}
> > +
> > +/* We assume here that OMAP clocks will not be removed */
> 
> Then the above comment can be removed too.
Thanks for checking up. Fixed all of them below, will post part of
series again, only if I need to address further comments in other
patches..

>From f96c04860794f9bbfe240a8661641a7c90dd1640 Mon Sep 17 00:00:00 2001
From: Nishanth Menon <nm at ti.com>
Date: Tue, 9 Apr 2013 19:26:40 -0500
Subject: [PATCH V5 1/6] clk: OMAP: introduce device tree binding to kernel clock
 data

OMAP clock data is located in arch/arm/mach-omap2/cclockXYZ_data.c.
However, this presents an obstacle for using these clock nodes in
Device Tree definitions. This is especially true for board specific
clocks initially. The fixed clocks are currently found via clock
aliases table. There are many possible approaches to this problem as
discussed in the following thread:
http://marc.info/?t=136370325600009&r=1&w=2.
Highlights of the options:
a) device specific clk_add_alias:
   cons: driver handling required
b) using an generic clk node and indexing to reach the clock required.
   This is similar in approach taken by tegra and few other platforms.
   Example usage: clock = <&clk 5>;
   cons: potential to have mismatches in indexed table and associated
   dtb data. In addition, managing continued documentation in bindings
   as clock indexing increases. Even though readability angle could be
   improved by using preprocessing of DT using macros, indexed
   approach is inherently risky from cases like the following:
   clk indexes in kernel:
   1 - mpu_dpll
   2 - aux_clk1
   3 - core_clk
   DT entry for peripheral X uses <&clk 2> to reach aux_clk1. Now, let's
   say kernel updates indices to:
   1 - mpu_dpll
   2 - per_dpll
   3 - aux_clk1
   4 - core_clk
   using the old dtb(or dts missing an update), on new kernel which
   has updated indices will result in per_dpll now controlled for
   peripheral X without warning or any potential error detection.

   Even though we could claim this is user error, such errors are hard
   to track down and fix.

An alternate approach introduced here is to introduce device tree
bindings corresponding to the clock nodes required in DT definition
for SoC which automatically maps back to the definitions in
cclockXYZ_data.c.

The driver introduced here to do this mapping will eventually be the
place where the clock handling will migrate to. We need to consider
this angle as well so that the solution will be an valid transition
point for moving the clock data out of kernel image (into device tree
or firmware load etc..).

Overall strategy introduced here is simple: a clock node described in
device tree blob is used to identify the exact clock provided in the
SoC specific data. This is then linked back using of_clk_add_provider
to the device node to be accessible by of_clk_get.

Based on discussion contributions from Roger Quadros, Grygorii Strashko
and others.

Cc: Kevin Hilman <khilman at deeprootsystems.com>
Cc: Mike Turquette <mturquette at linaro.org>
Cc: Paul Walmsley <paul at pwsan.com>
[tony at atomide.com: co-developed]
Signed-off-by: Tony Lindgren <tony at atomide.com>
Signed-off-by: Nishanth Menon <nm at ti.com>
---
 .../devicetree/bindings/clock/omap-clock.txt       |   40 +++++++++
 drivers/clk/Makefile                               |    1 +
 drivers/clk/omap/Makefile                          |    1 +
 drivers/clk/omap/clk.c                             |   95 ++++++++++++++++++++
 4 files changed, 137 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/omap-clock.txt
 create mode 100644 drivers/clk/omap/Makefile
 create mode 100644 drivers/clk/omap/clk.c

diff --git a/Documentation/devicetree/bindings/clock/omap-clock.txt b/Documentation/devicetree/bindings/clock/omap-clock.txt
new file mode 100644
index 0000000..047c1e7
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/omap-clock.txt
@@ -0,0 +1,40 @@
+Device Tree Clock bindings for Texas Instrument's OMAP compatible platforms
+
+This binding is an initial minimal binding that may be enhanced as part of
+transitioning OMAP clock data out of kernel image.
+
+This binding uses the common clock binding[1].
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties:
+- compatible : shall be "ti,omap-clock"
+- #clock-cells : from common clock binding; shall be set to 0.
+NOTE:
+node name should map to clock database in arch/arm/mach-omap2/cclock<SoC>_data.c
+Since all clocks are described with _ck, the node name is optimized to drop the
+usage of _ck. For example, a clock called dpll1_ck will be defined as dpll1.
+
+Example #1: describing clock node for CPU on OMAP34xx platform:
+Ref: arch/arm/mach-omap2/cclock3xxx_data.c
+describes the CPU clock to be as follows
+	CLK(NULL,	"dpll1_ck",	&dpll1_ck,	CK_3XXX),
+Corresponding binding will be:
+	dpll1: dpll1 {
+		#clock-cells = <0>;
+		compatible = "ti,omap-clock";
+	};
+And it's usage will be:
+		clocks = <&dpll1>;
+
+Example #2: describing clock node for auxilary clock #3 on OMAP443x platform:
+Ref: arch/arm/mach-omap2/cclock44xx_data.c
+describes the auxclk3 clock to be as follows:
+	CLK(NULL,	"auxclk3_ck",	&auxclk3_ck,	CK_443X),
+Corresponding binding will be:
+	auxclk3: auxclk3 {
+		#clock-cells = <0>;
+		compatible = "ti,omap-clock";
+	};
+And it's usage will be:
+	clocks = <&auxclk3>;
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index e7f7fe9..dbf9b13 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -29,6 +29,7 @@ obj-$(CONFIG_ARCH_U8500)	+= ux500/
 obj-$(CONFIG_ARCH_VT8500)	+= clk-vt8500.o
 obj-$(CONFIG_ARCH_ZYNQ)		+= clk-zynq.o
 obj-$(CONFIG_ARCH_TEGRA)	+= tegra/
+obj-$(CONFIG_ARCH_OMAP)		+= omap/
 
 obj-$(CONFIG_X86)		+= x86/
 
diff --git a/drivers/clk/omap/Makefile b/drivers/clk/omap/Makefile
new file mode 100644
index 0000000..8195931
--- /dev/null
+++ b/drivers/clk/omap/Makefile
@@ -0,0 +1 @@
+obj-y					+= clk.o
diff --git a/drivers/clk/omap/clk.c b/drivers/clk/omap/clk.c
new file mode 100644
index 0000000..e73496b
--- /dev/null
+++ b/drivers/clk/omap/clk.c
@@ -0,0 +1,95 @@
+/*
+ * Texas Instruments OMAP Clock driver
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ *	Nishanth Menon <nm at ti.com>
+ *	Tony Lindgren <tony at atomide.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.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/clkdev.h>
+#include <linux/clk-provider.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include <linux/string.h>
+
+static const struct of_device_id omap_clk_of_match[] = {
+	{.compatible = "ti,omap-clock",},
+	{},
+};
+
+/**
+ * omap_clk_src_get() - Get OMAP clock from node name when needed
+ * @clkspec:	clkspec argument
+ * @data:	unused
+ *
+ * REVISIT: We assume the following:
+ * 1. omap clock names end with _ck
+ * 2. omap clock names are under 32 characters in length
+ */
+static struct clk *omap_clk_src_get(struct of_phandle_args *clkspec, void *data)
+{
+	struct clk *clk;
+	char clk_name[32];
+	struct device_node *np = clkspec->np;
+
+	snprintf(clk_name, 32, "%s_ck", np->name);
+	clk = clk_get(NULL, clk_name);
+	if (IS_ERR(clk)) {
+		pr_err("%s: could not get clock %s(%ld)\n", __func__,
+		       clk_name, PTR_ERR(clk));
+		goto out;
+	}
+	clk_put(clk);
+
+out:
+	return clk;
+}
+
+/**
+ * omap_clk_probe() - create link from DT definition to clock data
+ * @pdev:	device node
+ *
+ * NOTE: we look up the clock lazily when the consumer driver does
+ * of_clk_get() and initialize a NULL clock here.
+ */
+static int omap_clk_probe(struct platform_device *pdev)
+{
+	int res;
+	struct device_node *np = pdev->dev.of_node;
+
+	/* This allows the driver to of_clk_get() */
+	res = of_clk_add_provider(np, omap_clk_src_get, NULL);
+	if (res)
+		dev_err(&pdev->dev, "could not add provider(%d)\n", res);
+
+	return res;
+}
+
+static struct platform_driver omap_clk_driver = {
+	.probe = omap_clk_probe,
+	.driver = {
+		   .name = "omap_clk",
+		   .of_match_table = of_match_ptr(omap_clk_of_match),
+		   },
+};
+
+static int __init omap_clk_init(void)
+{
+	return platform_driver_register(&omap_clk_driver);
+}
+arch_initcall(omap_clk_init);
+
+MODULE_DESCRIPTION("OMAP Clock driver");
+MODULE_AUTHOR("Texas Instruments Inc.");
+MODULE_LICENSE("GPL v2");
-- 
1.7.9.5


-- 
Regards,
Nishanth Menon


From sergei.shtylyov at cogentembedded.com  Fri Apr 12 19:39:09 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Sat, 13 Apr 2013 03:39:09 +0400
Subject: [PATCH v2 0/4] Add USB support to R8A7778/BOCK-W
Message-ID: <201304130339.09876.sergei.shtylyov@cogentembedded.com>

Hello.

   Here's the set of 4 patches against the Simon Horman's 'renesas.git' repo,
'renesas-next-20130412' tag and the R8A7779/Marzen patchset I've just posted.
 It was created to add support of R8A7778/BOCK-W USB to the platform code and
the USB common PHY driver, and so spans both arch/arm/mach-shmobile/ and
drivers/usb/phy/ subtrees.

[1/4] rcar-phy: add R8A7778 support
[2/4] ARM: shmobile: r8a7778: add USB support
[3/4] ARM: shmobile: BOCK-W: add USB support
[4/4] ARM: shmobile: BOCK-W: enable USB in defconfig

WBR, Sergei


From sergei.shtylyov at cogentembedded.com  Fri Apr 12 19:41:18 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Sat, 13 Apr 2013 03:41:18 +0400
Subject: [PATCH v2 2/4] ARM: shmobile: r8a7778: add USB support
Message-ID: <201304130341.19197.sergei.shtylyov@cogentembedded.com>

Add USB clock and EHCI, OHCI, and USB PHY platform devices for R8A7778 SoC;  add
a function to register PHY device with board-specific platform data and register
EHCI and OHCI platfrom devices from the init_late() board method.

Also,  don't forget to enable CONFIG_ARCH_HAS_[EO]HCI options for R8A7778 SoC in
Kconfig...

The patch has been tested on the BOCK-W board.

Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

---
Changes since the original posting:
- resolved rejects in the 'clock-r8a7778.c' file;
- lowercased the SoC name in the subject.

 arch/arm/mach-shmobile/Kconfig                |    2 
 arch/arm/mach-shmobile/clock-r8a7778.c        |    4 
 arch/arm/mach-shmobile/include/mach/r8a7778.h |    3 
 arch/arm/mach-shmobile/setup-r8a7778.c        |  108 ++++++++++++++++++++++++++
 4 files changed, 117 insertions(+)

Index: renesas/arch/arm/mach-shmobile/Kconfig
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/Kconfig
+++ renesas/arch/arm/mach-shmobile/Kconfig
@@ -40,6 +40,8 @@ config ARCH_R8A7778
 	select CPU_V7
 	select SH_CLK_CPG
 	select ARM_GIC
+	select USB_ARCH_HAS_EHCI
+	select USB_ARCH_HAS_OHCI
 
 config ARCH_R8A7779
 	bool "R-Car H1 (R8A77790)"
Index: renesas/arch/arm/mach-shmobile/clock-r8a7778.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/clock-r8a7778.c
+++ renesas/arch/arm/mach-shmobile/clock-r8a7778.c
@@ -104,12 +104,14 @@ static struct clk *main_clks[] = {
 
 enum {
 	MSTP114,
+	MSTP100,
 	MSTP026, MSTP025, MSTP024, MSTP023, MSTP022, MSTP021,
 	MSTP016, MSTP015,
 	MSTP_NR };
 
 static struct clk mstp_clks[MSTP_NR] = {
 	[MSTP114] = SH_CLK_MSTP32(&p_clk, MSTPCR1, 14, 0), /* Ether */
+	[MSTP100] = SH_CLK_MSTP32(&p_clk, MSTPCR1,  0, 0), /* USB0/1 */
 	[MSTP026] = SH_CLK_MSTP32(&p_clk, MSTPCR0, 26, 0), /* SCIF0 */
 	[MSTP025] = SH_CLK_MSTP32(&p_clk, MSTPCR0, 25, 0), /* SCIF1 */
 	[MSTP024] = SH_CLK_MSTP32(&p_clk, MSTPCR0, 24, 0), /* SCIF2 */
@@ -123,6 +125,8 @@ static struct clk mstp_clks[MSTP_NR] = {
 static struct clk_lookup lookups[] = {
 	/* MSTP32 clocks */
 	CLKDEV_DEV_ID("sh-eth",	&mstp_clks[MSTP114]), /* Ether */
+	CLKDEV_DEV_ID("ehci-platform", &mstp_clks[MSTP100]), /* USB EHCI port0/1 */
+	CLKDEV_DEV_ID("ohci-platform", &mstp_clks[MSTP100]), /* USB OHCI port0/1 */
 	CLKDEV_DEV_ID("sh-sci.0", &mstp_clks[MSTP026]), /* SCIF0 */
 	CLKDEV_DEV_ID("sh-sci.1", &mstp_clks[MSTP025]), /* SCIF1 */
 	CLKDEV_DEV_ID("sh-sci.2", &mstp_clks[MSTP024]), /* SCIF2 */
Index: renesas/arch/arm/mach-shmobile/include/mach/r8a7778.h
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/include/mach/r8a7778.h
+++ renesas/arch/arm/mach-shmobile/include/mach/r8a7778.h
@@ -19,10 +19,13 @@
 #define __ASM_R8A7778_H__
 
 #include <linux/sh_eth.h>
+#include <linux/usb/rcar-phy.h>
 
 extern void r8a7778_add_standard_devices(void);
 extern void r8a7778_add_standard_devices_dt(void);
 extern void r8a7778_add_ether_device(struct sh_eth_plat_data *pdata);
+extern void r8a7778_add_usb_phy_device(struct rcar_phy_platform_data *pdata);
+extern void r8a7778_init_late(void);
 extern void r8a7778_init_delay(void);
 extern void r8a7778_init_irq(void);
 extern void r8a7778_init_irq_dt(void);
Index: renesas/arch/arm/mach-shmobile/setup-r8a7778.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/setup-r8a7778.c
+++ renesas/arch/arm/mach-shmobile/setup-r8a7778.c
@@ -29,6 +29,12 @@
 #include <linux/irqchip.h>
 #include <linux/serial_sci.h>
 #include <linux/sh_timer.h>
+#include <linux/pm_runtime.h>
+#include <linux/usb/phy.h>
+#include <linux/usb/hcd.h>
+#include <linux/usb/ehci_pdriver.h>
+#include <linux/usb/ohci_pdriver.h>
+#include <linux/dma-mapping.h>
 #include <mach/irqs.h>
 #include <mach/r8a7778.h>
 #include <mach/common.h>
@@ -88,6 +94,99 @@ static struct sh_timer_config sh_tmu1_pl
 		&sh_tmu##idx##_platform_data,		\
 		sizeof(sh_tmu##idx##_platform_data))
 
+/* USB PHY */
+static struct resource usb_phy_resources[] = {
+	DEFINE_RES_MEM(0xffe70800, 0x100),
+	DEFINE_RES_MEM(0xffe76000, 0x100),
+};
+
+void __init r8a7778_add_usb_phy_device(struct rcar_phy_platform_data *pdata)
+{
+	platform_device_register_resndata(&platform_bus, "rcar_usb_phy", -1,
+					  usb_phy_resources,
+					  ARRAY_SIZE(usb_phy_resources),
+					  pdata, sizeof(*pdata));
+}
+
+/* USB */
+static struct usb_phy *phy;
+
+static int usb_power_on(struct platform_device *pdev)
+{
+	if (!phy)
+		return -EIO;
+
+	pm_runtime_enable(&pdev->dev);
+	pm_runtime_get_sync(&pdev->dev);
+
+	usb_phy_init(phy);
+
+	return 0;
+}
+
+static void usb_power_off(struct platform_device *pdev)
+{
+	if (!phy)
+		return;
+
+	usb_phy_shutdown(phy);
+
+	pm_runtime_put_sync(&pdev->dev);
+	pm_runtime_disable(&pdev->dev);
+}
+
+static int ehci_init_internal_buffer(struct usb_hcd *hcd)
+{
+	/*
+	 * Below are recommended values from the datasheet;
+	 * see [USB :: Setting of EHCI Internal Buffer].
+	 */
+	/* EHCI IP internal buffer setting */
+	iowrite32(0x00ff0040, hcd->regs + 0x0094);
+	/* EHCI IP internal buffer enable */
+	iowrite32(0x00000001, hcd->regs + 0x009C);
+
+	return 0;
+}
+
+static struct usb_ehci_pdata ehci_pdata = {
+	.power_on	= usb_power_on,
+	.power_off	= usb_power_off,
+	.power_suspend	= usb_power_off,
+	.pre_setup	= ehci_init_internal_buffer,
+};
+
+static struct resource ehci_resources[] = {
+	DEFINE_RES_MEM(0xffe70000, 0x400),
+	DEFINE_RES_IRQ(gic_iid(0x4c)),
+};
+
+static struct usb_ohci_pdata ohci_pdata = {
+	.power_on	= usb_power_on,
+	.power_off	= usb_power_off,
+	.power_suspend	= usb_power_off,
+};
+
+static struct resource ohci_resources[] = {
+	DEFINE_RES_MEM(0xffe70400, 0x400),
+	DEFINE_RES_IRQ(gic_iid(0x4c)),
+};
+
+#define USB_PLATFORM_INFO(hci)				\
+static struct platform_device_info hci##_info = {	\
+	.parent		= &platform_bus,		\
+	.name		= #hci "-platform",		\
+	.id		= -1,				\
+	.res		= hci##_resources,		\
+	.num_res	= ARRAY_SIZE(hci##_resources),	\
+	.data		= &hci##_pdata,			\
+	.size_data	= sizeof(hci##_pdata),		\
+	.dma_mask	= DMA_BIT_MASK(32),		\
+}
+
+USB_PLATFORM_INFO(ehci);
+USB_PLATFORM_INFO(ohci);
+
 /* Ether */
 static struct resource ether_resources[] = {
 	DEFINE_RES_MEM(0xfde00000, 0x400),
@@ -126,6 +225,14 @@ void __init r8a7778_add_standard_devices
 	r8a7778_register_tmu(1);
 }
 
+void __init r8a7778_init_late(void)
+{
+	phy = usb_get_phy(USB_PHY_TYPE_USB2);
+
+	platform_device_register_full(&ehci_info);
+	platform_device_register_full(&ohci_info);
+}
+
 static struct renesas_intc_irqpin_config irqpin_platform_data = {
 	.irq_base = irq_pin(0), /* IRQ0 -> IRQ3 */
 	.sense_bitfield_width = 2,
@@ -239,6 +346,7 @@ DT_MACHINE_START(R8A7778_DT, "Generic R8
 	.init_machine	= r8a7778_add_standard_devices_dt,
 	.init_time	= shmobile_timer_init,
 	.dt_compat	= r8a7778_compat_dt,
+	.init_late      = r8a7778_init_late,
 MACHINE_END
 
 #endif /* CONFIG_USE_OF */


From sergei.shtylyov at cogentembedded.com  Fri Apr 12 19:44:27 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Sat, 13 Apr 2013 03:44:27 +0400
Subject: [PATCH v2 3/4] ARM: shmobile: BOCK-W: add USB support
Message-ID: <201304130344.28060.sergei.shtylyov@cogentembedded.com>

Register the USB PHY device from bockw_init(), passing the platform  data to it.
Set machine's init_late() method to r8a7778_init_late() in order for [EO]HCI to
get registered too...

The patch has been tested on the BOCK-W board.

Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

---
Changes since the original posting:
- removed initializer for no longer existing field in 'usb_phy_platform_data',
  modified the comment to the 'ferrite_bead' field initializer.

 arch/arm/mach-shmobile/board-bockw.c |    6 ++++++
 1 file changed, 6 insertions(+)

Index: renesas/arch/arm/mach-shmobile/board-bockw.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/board-bockw.c
+++ renesas/arch/arm/mach-shmobile/board-bockw.c
@@ -53,6 +53,10 @@ static struct resource smsc911x_resource
 	DEFINE_RES_IRQ(irq_pin(0)), /* IRQ 0 */
 };
 
+static struct rcar_phy_platform_data usb_phy_platform_data = {
+	.ferrite_bead	= true,		/* not sure about this... */
+};
+
 #define IRQ0MR	0x30
 static void __init bockw_init(void)
 {
@@ -61,6 +65,7 @@ static void __init bockw_init(void)
 	r8a7778_clock_init();
 	r8a7778_init_irq_extpin(1);
 	r8a7778_add_standard_devices();
+	r8a7778_add_usb_phy_device(&usb_phy_platform_data);
 
 	fpga = ioremap_nocache(0x18200000, SZ_1M);
 	if (fpga) {
@@ -97,4 +102,5 @@ DT_MACHINE_START(BOCKW_DT, "bockw")
 	.init_machine	= bockw_init,
 	.init_time	= shmobile_timer_init,
 	.dt_compat	= bockw_boards_compat_dt,
+	.init_late      = r8a7778_init_late,
 MACHINE_END


From sergei.shtylyov at cogentembedded.com  Fri Apr 12 19:45:22 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Sat, 13 Apr 2013 03:45:22 +0400
Subject: [PATCH v2 4/4] ARM: shmobile: BOCK-W: enable USB in defconfig
Message-ID: <201304130345.22855.sergei.shtylyov@cogentembedded.com>

Enable USB platform EHCI/OHCI and common PHY drivers in 'bockw_defconfig'.
Enable USB storage driver and SCSI disk driver that it needs as well...

Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

---
 arch/arm/configs/bockw_defconfig |   11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

Index: renesas/arch/arm/configs/bockw_defconfig
===================================================================
--- renesas.orig/arch/arm/configs/bockw_defconfig
+++ renesas/arch/arm/configs/bockw_defconfig
@@ -48,6 +48,8 @@ CONFIG_DEVTMPFS_MOUNT=y
 # CONFIG_STANDALONE is not set
 # CONFIG_PREVENT_FIRMWARE_BUILD is not set
 # CONFIG_FW_LOADER is not set
+CONFIG_SCSI=y
+CONFIG_BLK_DEV_SD=y
 CONFIG_NETDEVICES=y
 # CONFIG_NET_CADENCE is not set
 # CONFIG_NET_VENDOR_BROADCOM is not set
@@ -71,7 +73,14 @@ CONFIG_SERIAL_SH_SCI_NR_UARTS=6
 CONFIG_SERIAL_SH_SCI_CONSOLE=y
 # CONFIG_HW_RANDOM is not set
 # CONFIG_HWMON is not set
-# CONFIG_USB_SUPPORT is not set
+CONFIG_USB=y
+CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
+CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_OHCI_HCD=y
+CONFIG_USB_OHCI_HCD_PLATFORM=y
+CONFIG_USB_EHCI_HCD_PLATFORM=y
+CONFIG_USB_STORAGE=y
+CONFIG_USB_RCAR_PHY=y
 CONFIG_UIO=y
 CONFIG_UIO_PDRV_GENIRQ=y
 # CONFIG_IOMMU_SUPPORT is not set


From heiko at sntech.de  Fri Apr 12 19:53:11 2013
From: heiko at sntech.de (Heiko =?utf-8?q?St=C3=BCbner?=)
Date: Sat, 13 Apr 2013 01:53:11 +0200
Subject: [PATCH] ARM: S3C24XX: add devicetree support for smdk2416
Message-ID: <201304130153.11653.heiko@sntech.de>

Definitions in s3c24xx.dtsi are usable for all s3c24xx SoCs, but some
need to be extended with proper compatible properties, as can be seen
in s3c2416.dtsi .

Signed-off-by: Heiko Stuebner <heiko at sntech.de>
---
This patch depends on the not yet merged s3c24xx pinctrl support and
the samsung-time muliplatform support.

 arch/arm/boot/dts/Makefile              |    1 +
 arch/arm/boot/dts/s3c2416-pinctrl.dtsi  |  173 +++++++++++++++++++++++++++++++
 arch/arm/boot/dts/s3c2416-smdk2416.dts  |   72 +++++++++++++
 arch/arm/boot/dts/s3c2416.dtsi          |   79 ++++++++++++++
 arch/arm/boot/dts/s3c24xx.dtsi          |   92 ++++++++++++++++
 arch/arm/mach-s3c24xx/Kconfig           |   12 ++
 arch/arm/mach-s3c24xx/Makefile          |    1 +
 arch/arm/mach-s3c24xx/mach-s3c2416-dt.c |   91 ++++++++++++++++
 8 files changed, 521 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/boot/dts/s3c2416-pinctrl.dtsi
 create mode 100644 arch/arm/boot/dts/s3c2416-smdk2416.dts
 create mode 100644 arch/arm/boot/dts/s3c2416.dtsi
 create mode 100644 arch/arm/boot/dts/s3c24xx.dtsi
 create mode 100644 arch/arm/mach-s3c24xx/mach-s3c2416-dt.c

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index d3cd880..4296353 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -137,6 +137,7 @@ dtb-$(CONFIG_ARCH_U8500) += snowball.dtb \
 	hrefprev60.dtb \
 	hrefv60plus.dtb \
 	ccu9540.dtb
+dtb-$(CONFIG_ARCH_S3C24XX) += s3c2416-smdk2416.dtb
 dtb-$(CONFIG_ARCH_SHMOBILE) += emev2-kzm9d.dtb \
 	r8a7740-armadillo800eva.dtb \
 	sh73a0-kzm9g.dtb \
diff --git a/arch/arm/boot/dts/s3c2416-pinctrl.dtsi b/arch/arm/boot/dts/s3c2416-pinctrl.dtsi
new file mode 100644
index 0000000..527e319
--- /dev/null
+++ b/arch/arm/boot/dts/s3c2416-pinctrl.dtsi
@@ -0,0 +1,173 @@
+/*
+ * Samsung S3C2416 pinctrl settings
+ *
+ * Copyright (c) 2013 Heiko Stuebner <heiko at sntech.de>
+ *
+ * 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.
+ */
+
+&pinctrl_0 {
+	/*
+	 * Pin banks
+	 */
+
+	gpa: gpa {
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
+	gpb: gpb {
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
+	gpc: gpc {
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
+	gpd: gpd {
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
+	gpe: gpe {
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
+	gpf: gpf {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpg: gpg {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gph: gph {
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
+	gpj: gpj {
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
+	gpk: gpk {
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
+	gpl: gpl {
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
+	gpm: gpm {
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
+	/*
+	 * Pin groups
+	 */
+
+	uart0_data: uart0-data {
+		samsung,pins = "gph-0", "gph-1";
+		samsung,pin-function = <2>;
+	};
+
+	uart0_fctl: uart0-fctl {
+		samsung,pins = "gph-8", "gph-9";
+		samsung,pin-function = <2>;
+	};
+
+	uart1_data: uart1-data {
+		samsung,pins = "gph-2", "gph-3";
+		samsung,pin-function = <2>;
+	};
+
+	uart1_fctl: uart1-fctl {
+		samsung,pins = "gph-10", "gph-11";
+		samsung,pin-function = <2>;
+	};
+
+	uart2_data: uart2-data {
+		samsung,pins = "gph-4", "gph-5";
+		samsung,pin-function = <2>;
+	};
+
+	uart2_fctl: uart2-fctl {
+		samsung,pins = "gph-6", "gph-7";
+		samsung,pin-function = <2>;
+	};
+
+	uart3_data: uart3-data {
+		samsung,pins = "gph-6", "gph-7";
+		samsung,pin-function = <2>;
+	};
+
+	extuart_clk: extuart-clk {
+		samsung,pins = "gph-12";
+		samsung,pin-function = <2>;
+	};
+
+	i2c0_bus: i2c0-bus {
+		samsung,pins = "gpe-14", "gpe-15";
+		samsung,pin-function = <2>;
+	};
+
+	spi0_bus: spi0-bus {
+		samsung,pins = "gpe-11", "gpe-12", "gpe-13";
+		samsung,pin-function = <2>;
+	};
+
+	sd0_clk: sd0-clk {
+		samsung,pins = "gpe-5";
+		samsung,pin-function = <2>;
+	};
+
+	sd0_cmd: sd0-cmd {
+		samsung,pins = "gpe-6";
+		samsung,pin-function = <2>;
+	};
+
+	sd0_bus1: sd0-bus1 {
+		samsung,pins = "gpe-7";
+		samsung,pin-function = <2>;
+	};
+
+	sd0_bus4: sd0-bus4 {
+		samsung,pins = "gpe-8", "gpe-9", "gpe-10";
+		samsung,pin-function = <2>;
+	};
+
+	sd1_cmd: sd1-cmd {
+		samsung,pins = "gpl-8";
+		samsung,pin-function = <2>;
+	};
+
+	sd1_clk: sd1-clk {
+		samsung,pins = "gpl-9";
+		samsung,pin-function = <2>;
+	};
+
+	sd1_bus1: sd1-bus1 {
+		samsung,pins = "gpl-0";
+		samsung,pin-function = <2>;
+	};
+
+	sd1_bus4: sd1-bus4 {
+		samsung,pins = "gpl-1", "gpl-2", "gpl-3";
+		samsung,pin-function = <2>;
+	};
+};
diff --git a/arch/arm/boot/dts/s3c2416-smdk2416.dts b/arch/arm/boot/dts/s3c2416-smdk2416.dts
new file mode 100644
index 0000000..ad1dd09
--- /dev/null
+++ b/arch/arm/boot/dts/s3c2416-smdk2416.dts
@@ -0,0 +1,72 @@
+/*
+ * SAMSUNG SMDK2416 board device tree source
+ *
+ * Copyright (c) 2013 Heiko Stuebner <heiko at sntech.de>
+ *
+ * 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.
+ */
+
+/dts-v1/;
+/include/ "s3c2416.dtsi"
+
+/ {
+	model = "SMDK2416";
+	compatible = "samsung,s3c2416";
+
+	memory {
+		reg =  <0x30000000 0x4000000>;
+	};
+
+	serial at 50000000 {
+		status = "okay";
+		pinctrl-names = "default";
+		pinctrl-0 = <&uart0_data>, <&uart0_fctl>;
+	};
+
+	serial at 50004000 {
+		status = "okay";
+		pinctrl-names = "default";
+		pinctrl-0 = <&uart1_data>, <&uart1_fctl>;
+	};
+
+	serial at 50008000 {
+		status = "okay";
+		pinctrl-names = "default";
+		pinctrl-0 = <&uart2_data>;
+	};
+
+	serial at 5000C000 {
+		status = "okay";
+		pinctrl-names = "default";
+		pinctrl-0 = <&uart3_data>;
+	};
+
+	watchdog at 53000000 {
+		status = "okay";
+	};
+
+	rtc at 57000000 {
+		status = "okay";
+	};
+
+	sdhci at 4AC00000 {
+		pinctrl-names = "default";
+		pinctrl-0 = <&sd0_clk>, <&sd0_cmd>,
+				<&sd0_bus1>, <&sd0_bus4>;
+		bus-width = <4>;
+		cd-gpios = <&gpf 1 0>;
+		cd-inverted;
+		status = "okay";
+	};
+
+	sdhci at 4A800000 {
+		pinctrl-names = "default";
+		pinctrl-0 = <&sd1_clk>, <&sd1_cmd>,
+				<&sd1_bus1>, <&sd1_bus4>;
+		bus-width = <4>;
+		broken-cd;
+		status = "okay";
+	};
+};
diff --git a/arch/arm/boot/dts/s3c2416.dtsi b/arch/arm/boot/dts/s3c2416.dtsi
new file mode 100644
index 0000000..6809324
--- /dev/null
+++ b/arch/arm/boot/dts/s3c2416.dtsi
@@ -0,0 +1,79 @@
+/*
+ * Samsung's S3C2416 SoC device tree source
+ *
+ * Copyright (c) 2013 Heiko Stuebner <heiko at sntech.de>
+ *
+ * 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/ "s3c24xx.dtsi"
+/include/ "s3c2416-pinctrl.dtsi"
+
+/ {
+	model = "Samsung S3C2416 SoC";
+	compatible = "samsung,s3c2416";
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		cpu {
+			compatible = "arm,arm926ejs";
+		};
+	};
+
+	interrupt-controller at 4a000000 {
+		compatible = "samsung,s3c2416-irq";
+	};
+
+	pinctrl at 56000000 {
+		compatible = "samsung,s3c2416-pinctrl";
+	};
+
+	serial at 50000000 {
+		compatible = "samsung,s3c2440-uart";
+	};
+
+	serial at 50004000 {
+		compatible = "samsung,s3c2440-uart";
+	};
+
+	serial at 50008000 {
+		compatible = "samsung,s3c2440-uart";
+	};
+
+	serial at 5000C000 {
+		compatible = "samsung,s3c2440-uart";
+		reg = <0x5000C000 0x4000>;
+		interrupts = <1 18 24 4>, <1 18 25 4>;
+		status = "disabled";
+	};
+
+	sdhci at 4AC00000 {
+		compatible = "samsung,s3c6410-sdhci";
+		reg = <0x4AC00000 0x100>;
+		interrupts = <0 0 21 3>;
+		status = "disabled";
+	};
+
+	sdhci at 4A800000 {
+		compatible = "samsung,s3c6410-sdhci";
+		reg = <0x4A800000 0x100>;
+		interrupts = <0 0 20 3>;
+		status = "disabled";
+	};
+
+	watchdog at 53000000 {
+		interrupts = <1 9 27 3>;
+	};
+
+	rtc at 57000000 {
+		compatible = "samsung,s3c2416-rtc";
+	};
+
+	i2c at 54000000 {
+		compatible = "samsung,s3c2440-i2c";
+	};
+};
diff --git a/arch/arm/boot/dts/s3c24xx.dtsi b/arch/arm/boot/dts/s3c24xx.dtsi
new file mode 100644
index 0000000..92017f6
--- /dev/null
+++ b/arch/arm/boot/dts/s3c24xx.dtsi
@@ -0,0 +1,92 @@
+/*
+ * Samsung's S3C24XX family device tree source
+ *
+ * Copyright (c) 2013 Heiko Stuebner <heiko at sntech.de>
+ *
+ * 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/ "skeleton.dtsi"
+
+/ {
+	compatible = "samsung,s3c24xx";
+	interrupt-parent = <&intc>;
+
+	aliases {
+		pinctrl0 = &pinctrl_0;
+	};
+
+	intc:interrupt-controller at 4a000000 {
+		compatible = "samsung,s3c24xx-irq";
+		reg = <0x4a000000 0x100>;
+		interrupt-controller;
+		#interrupt-cells = <4>;
+	};
+
+	pinctrl_0: pinctrl at 56000000 {
+		reg = <0x56000000 0x1000>;
+
+		wakeup-interrupt-controller {
+			compatible = "samsung,s3c2410-wakeup-eint";
+			interrupts = <0 0 0 3>,
+				     <0 0 1 3>,
+				     <0 0 2 3>,
+				     <0 0 3 3>,
+				     <0 0 4 4>,
+				     <0 0 5 4>;
+		};
+	};
+
+	timer at 51000000 {
+		compatible = "samsung,s3c2410-pwm";
+		reg = <0x51000000 0x1000>;
+		interrupts = <0 0 10 3>, <0 0 11 3>, <0 0 12 3>, <0 0 13 3>, <0 0 14 3>;
+		#pwm-cells = <4>;
+	};
+
+	serial at 50000000 {
+		compatible = "samsung,s3c2410-uart";
+		reg = <0x50000000 0x4000>;
+		interrupts = <1 28 0 4>, <1 28 1 4>;
+		status = "disabled";
+	};
+
+	serial at 50004000 {
+		compatible = "samsung,s3c2410-uart";
+		reg = <0x50004000 0x4000>;
+		interrupts = <1 23 3 4>, <1 23 4 4>;
+		status = "disabled";
+	};
+
+	serial at 50008000 {
+		compatible = "samsung,s3c2410-uart";
+		reg = <0x50008000 0x4000>;
+		interrupts = <1 15 6 4>, <1 15 7 4>;
+		status = "disabled";
+	};
+
+	watchdog at 53000000 {
+		compatible = "samsung,s3c2410-wdt";
+		reg = <0x53000000 0x100>;
+		interrupts = <0 0 9 3>;
+		status = "disabled";
+	};
+
+	rtc at 57000000 {
+		compatible = "samsung,s3c2410-rtc";
+		reg = <0x57000000 0x100>;
+		interrupts = <0 0 30 3>, <0 0 8 3>;
+		status = "disabled";
+	};
+
+	i2c at 54000000 {
+		compatible = "samsung,s3c2410-i2c";
+		reg = <0x54000000 0x100>;
+		interrupts = <0 0 27 3>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		status = "disabled";
+	};
+};
diff --git a/arch/arm/mach-s3c24xx/Kconfig b/arch/arm/mach-s3c24xx/Kconfig
index 0a8663c..f842e3e 100644
--- a/arch/arm/mach-s3c24xx/Kconfig
+++ b/arch/arm/mach-s3c24xx/Kconfig
@@ -496,6 +496,18 @@ config MACH_SMDK2416
 	help
 	  Say Y here if you are using an SMDK2416
 
+config MACH_S3C2416_DT
+	bool "Samsung S3C2416 machine using devicetree"
+	select CLKSRC_OF
+	select USE_OF
+	select PINCTRL
+	select PINCTRL_S3C24XX
+	help
+	  Machine support for Samsung S3C2416 machines with device tree enabled.
+	  Select this if a fdt blob is available for the S3C2416 SoC based board.
+	  Note: This is under development and not all peripherals can be supported
+	  with this machine file.
+
 endif	# CPU_S3C2416
 
 if CPU_S3C2440
diff --git a/arch/arm/mach-s3c24xx/Makefile b/arch/arm/mach-s3c24xx/Makefile
index 6f46ecf..6de730b 100644
--- a/arch/arm/mach-s3c24xx/Makefile
+++ b/arch/arm/mach-s3c24xx/Makefile
@@ -85,6 +85,7 @@ obj-$(CONFIG_MACH_SMDK2413)		+= mach-smdk2413.o
 obj-$(CONFIG_MACH_VSTMS)		+= mach-vstms.o
 
 obj-$(CONFIG_MACH_SMDK2416)		+= mach-smdk2416.o
+obj-$(CONFIG_MACH_S3C2416_DT)		+= mach-s3c2416-dt.o
 
 obj-$(CONFIG_MACH_ANUBIS)		+= mach-anubis.o
 obj-$(CONFIG_MACH_AT2440EVB)		+= mach-at2440evb.o
diff --git a/arch/arm/mach-s3c24xx/mach-s3c2416-dt.c b/arch/arm/mach-s3c24xx/mach-s3c2416-dt.c
new file mode 100644
index 0000000..f5c9072
--- /dev/null
+++ b/arch/arm/mach-s3c24xx/mach-s3c2416-dt.c
@@ -0,0 +1,91 @@
+/*
+ * Samsung's S3C2416 flattened device tree enabled machine
+ *
+ * Copyright (c) 2012 Heiko Stuebner <heiko at sntech.de>
+ *
+ * based on mach-exynos/mach-exynos4-dt.c
+ *
+ * Copyright (c) 2010-2011 Samsung Electronics Co., Ltd.
+ *		http://www.samsung.com
+ * Copyright (c) 2010-2011 Linaro Ltd.
+ *		www.linaro.org
+ *
+ * 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/clocksource.h>
+#include <linux/irqchip.h>
+#include <linux/of_platform.h>
+#include <linux/serial_core.h>
+
+#include <asm/mach/arch.h>
+#include <mach/map.h>
+
+#include <plat/cpu.h>
+#include <plat/pm.h>
+#include <plat/regs-serial.h>
+
+#include "common.h"
+
+/*
+ * The following lookup table is used to override device names when devices
+ * are registered from device tree. This is temporarily added to enable
+ * device tree support addition for the S3C2416 architecture.
+ *
+ * For drivers that require platform data to be provided from the machine
+ * file, a platform data pointer can also be supplied along with the
+ * devices names. Usually, the platform data elements that cannot be parsed
+ * from the device tree by the drivers (example: function pointers) are
+ * supplied. But it should be noted that this is a temporary mechanism and
+ * at some point, the drivers should be capable of parsing all the platform
+ * data from the device tree.
+ */
+static const struct of_dev_auxdata s3c2416_auxdata_lookup[] __initconst = {
+	OF_DEV_AUXDATA("samsung,s3c2440-uart", S3C2410_PA_UART0,
+				"s3c2440-uart.0", NULL),
+	OF_DEV_AUXDATA("samsung,s3c2440-uart", S3C2410_PA_UART1,
+				"s3c2440-uart.1", NULL),
+	OF_DEV_AUXDATA("samsung,s3c2440-uart", S3C2410_PA_UART2,
+				"s3c2440-uart.2", NULL),
+	OF_DEV_AUXDATA("samsung,s3c2440-uart", S3C2443_PA_UART3,
+				"s3c2440-uart.3", NULL),
+	OF_DEV_AUXDATA("samsung,s3c6410-sdhci", S3C_PA_HSMMC0,
+				"s3c-sdhci.0", NULL),
+	OF_DEV_AUXDATA("samsung,s3c6410-sdhci", S3C_PA_HSMMC1,
+				"s3c-sdhci.1", NULL),
+	OF_DEV_AUXDATA("samsung,s3c2440-i2c", S3C_PA_IIC,
+				"s3c2440-i2c.0", NULL),
+	{},
+};
+
+static void __init s3c2416_dt_map_io(void)
+{
+	s3c24xx_init_io(NULL, 0);
+	s3c24xx_init_clocks(12000000);
+}
+
+static void __init s3c2416_dt_machine_init(void)
+{
+	of_platform_populate(NULL, of_default_bus_match_table,
+				s3c2416_auxdata_lookup, NULL);
+
+	s3c_pm_init();
+}
+
+static char const *s3c2416_dt_compat[] __initdata = {
+	"samsung,s3c2416",
+	"samsung,s3c2450",
+	NULL
+};
+
+DT_MACHINE_START(S3C2416_DT, "Samsung S3C2416 (Flattened Device Tree)")
+	/* Maintainer: Heiko Stuebner <heiko at sntech.de> */
+	.dt_compat	= s3c2416_dt_compat,
+	.map_io		= s3c2416_dt_map_io,
+	.init_irq	= irqchip_init,
+	.init_machine	= s3c2416_dt_machine_init,
+	 .init_time	= clocksource_of_init,
+	.restart	= s3c2416_restart,
+MACHINE_END
-- 
1.7.2.3



From tony at atomide.com  Fri Apr 12 20:26:43 2013
From: tony at atomide.com (Tony Lindgren)
Date: Fri, 12 Apr 2013 17:26:43 -0700
Subject: [PATCH] ARM: dts: Configure and fix the McSPI pins for 4430sdp
Message-ID: <20130413002643.GH10155@atomide.com>

The bootloader configures the pins, but has pull bits
set without pull enable bits. While this is harmless,
and won't do anything, it seems to cause confusion at
least for me every time looking at the pin configuration.
Fix it for DT based boot.

Signed-off-by: Tony Lindgren <tony at atomide.com>

--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -223,6 +223,15 @@
 		>;
 	};
 
+	mcspi1_pins: pinmux_mcspi1_pins {
+		pinctrl-single,pins = <
+			0xf2 0x100	/*  mcspi1_clk.mcspi1_clk INPUT | MODE0 */
+			0xf4 0x100	/*  mcspi1_somi.mcspi1_somi INPUT | MODE0 */
+			0xf6 0x100	/*  mcspi1_simo.mcspi1_simo INPUT | MODE0 */
+			0xf8 0x100	/*  mcspi1_cs0.mcspi1_cs0 INPUT | MODE0*/
+		>;
+	};
+
 	dss_hdmi_pins: pinmux_dss_hdmi_pins {
 		pinctrl-single,pins = <
 			0x5a 0x118	/* hdmi_cec.hdmi_cec INPUT PULLUP | MODE 0 */
@@ -358,6 +367,9 @@
 };
 
 &mcspi1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&mcspi1_pins>;
+
 	eth at 0 {
 		compatible = "ks8851";
 		spi-max-frequency = <24000000>;


From sboyd at codeaurora.org  Fri Apr 12 20:27:39 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Fri, 12 Apr 2013 17:27:39 -0700
Subject: [PATCHv2 0/4] Memory mapped architected timers
Message-ID: <1365812863-5367-1-git-send-email-sboyd@codeaurora.org>

This patchset adds support for memory mapped architected timers. We
don't have any other global broadcast timer in our system, so we use the
mmio timer during low power modes. The first patch is the binding.
The next two patches lay some groundwork so that the last patch is simpler.
The final patch adds support for mmio timers.

Patches are based on a recent patch from Mark that removes the
physical count reading (clocksource: arch_timer: use virtual counter,
message id <1364404312-4427-4-git-send-email-mark.rutland at arm.com>).

Updates since v1:
 * Assigned counter reading function and commented why for arm64
 * Updated DT binding to replace frame-id with frame-number and use status
   property

Stephen Boyd (4):
  Documentation: Add memory mapped ARM architected timer binding
  ARM: arch_timers: Pass clock event to set_mode callback
  clocksource: arch_timer: Push the read/write wrappers deeper
  clocksource: arch_timer: Add support for memory mapped timers

 .../devicetree/bindings/arm/arch_timer.txt         |  59 ++-
 arch/arm/include/asm/arch_timer.h                  |   5 +-
 arch/arm64/include/asm/arch_timer.h                |   4 +-
 drivers/clocksource/arm_arch_timer.c               | 455 +++++++++++++++++----
 include/clocksource/arm_arch_timer.h               |   4 +-
 5 files changed, 449 insertions(+), 78 deletions(-)

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Fri Apr 12 20:27:42 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Fri, 12 Apr 2013 17:27:42 -0700
Subject: [PATCHv2 3/4] clocksource: arch_timer: Push the read/write wrappers
 deeper
In-Reply-To: <1365812863-5367-1-git-send-email-sboyd@codeaurora.org>
References: <1365812863-5367-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1365812863-5367-4-git-send-email-sboyd@codeaurora.org>

We're going to introduce support to read and write the memory
mapped timer registers in the next patch, so push the cp15
read/write functions one level deeper. This simplifies the next
patch and makes it clearer what's going on.

Cc: Mark Rutland <mark.rutland at arm.com>
Cc: Marc Zyngier <Marc.Zyngier at arm.com>
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 arch/arm/include/asm/arch_timer.h    |  5 ++--
 arch/arm64/include/asm/arch_timer.h  |  4 ++--
 drivers/clocksource/arm_arch_timer.c | 44 ++++++++++++++++++++++++------------
 3 files changed, 34 insertions(+), 19 deletions(-)

diff --git a/arch/arm/include/asm/arch_timer.h b/arch/arm/include/asm/arch_timer.h
index 35fea17..23d65f5 100644
--- a/arch/arm/include/asm/arch_timer.h
+++ b/arch/arm/include/asm/arch_timer.h
@@ -18,7 +18,8 @@ int arch_timer_sched_clock_init(void);
  * nicely work out which register we want, and chuck away the rest of
  * the code. At least it does so with a recent GCC (4.6.3).
  */
-static inline void arch_timer_reg_write(const int access, const int reg, u32 val)
+static inline void arch_timer_reg_write_cp15(const int access, const int reg,
+					  u32 val)
 {
 	if (access == ARCH_TIMER_PHYS_ACCESS) {
 		switch (reg) {
@@ -45,7 +46,7 @@ static inline void arch_timer_reg_write(const int access, const int reg, u32 val
 	isb();
 }
 
-static inline u32 arch_timer_reg_read(const int access, const int reg)
+static inline u32 arch_timer_reg_read_cp15(const int access, const int reg)
 {
 	u32 val = 0;
 
diff --git a/arch/arm64/include/asm/arch_timer.h b/arch/arm64/include/asm/arch_timer.h
index 5307737..95db1a9 100644
--- a/arch/arm64/include/asm/arch_timer.h
+++ b/arch/arm64/include/asm/arch_timer.h
@@ -26,7 +26,7 @@
 
 #include <clocksource/arm_arch_timer.h>
 
-static inline void arch_timer_reg_write(int access, int reg, u32 val)
+static inline void arch_timer_reg_write_cp15(int access, int reg, u32 val)
 {
 	if (access == ARCH_TIMER_PHYS_ACCESS) {
 		switch (reg) {
@@ -57,7 +57,7 @@ static inline void arch_timer_reg_write(int access, int reg, u32 val)
 	isb();
 }
 
-static inline u32 arch_timer_reg_read(int access, int reg)
+static inline u32 arch_timer_reg_read_cp15(int access, int reg)
 {
 	u32 val;
 
diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
index 545891b..4f1f002 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -43,14 +43,26 @@ static bool arch_timer_use_virtual = true;
  * Architected system timer support.
  */
 
+static inline void arch_timer_reg_write(int access, int reg, u32 val,
+					struct clock_event_device *clk)
+{
+	arch_timer_reg_write_cp15(access, reg, val);
+}
+
+static inline u32 arch_timer_reg_read(int access, int reg,
+				      struct clock_event_device *clk)
+{
+	return arch_timer_reg_read_cp15(access, reg);
+}
+
 static inline irqreturn_t timer_handler(const int access,
 					struct clock_event_device *evt)
 {
 	unsigned long ctrl;
-	ctrl = arch_timer_reg_read(access, ARCH_TIMER_REG_CTRL);
+	ctrl = arch_timer_reg_read(access, ARCH_TIMER_REG_CTRL, evt);
 	if (ctrl & ARCH_TIMER_CTRL_IT_STAT) {
 		ctrl |= ARCH_TIMER_CTRL_IT_MASK;
-		arch_timer_reg_write(access, ARCH_TIMER_REG_CTRL, ctrl);
+		arch_timer_reg_write(access, ARCH_TIMER_REG_CTRL, ctrl, evt);
 		evt->event_handler(evt);
 		return IRQ_HANDLED;
 	}
@@ -72,15 +84,16 @@ static irqreturn_t arch_timer_handler_phys(int irq, void *dev_id)
 	return timer_handler(ARCH_TIMER_PHYS_ACCESS, evt);
 }
 
-static inline void timer_set_mode(const int access, int mode)
+static inline void timer_set_mode(const int access, int mode,
+				  struct clock_event_device *clk)
 {
 	unsigned long ctrl;
 	switch (mode) {
 	case CLOCK_EVT_MODE_UNUSED:
 	case CLOCK_EVT_MODE_SHUTDOWN:
-		ctrl = arch_timer_reg_read(access, ARCH_TIMER_REG_CTRL);
+		ctrl = arch_timer_reg_read(access, ARCH_TIMER_REG_CTRL, clk);
 		ctrl &= ~ARCH_TIMER_CTRL_ENABLE;
-		arch_timer_reg_write(access, ARCH_TIMER_REG_CTRL, ctrl);
+		arch_timer_reg_write(access, ARCH_TIMER_REG_CTRL, ctrl, clk);
 		break;
 	default:
 		break;
@@ -90,36 +103,37 @@ static inline void timer_set_mode(const int access, int mode)
 static void arch_timer_set_mode_virt(enum clock_event_mode mode,
 				     struct clock_event_device *clk)
 {
-	timer_set_mode(ARCH_TIMER_VIRT_ACCESS, mode);
+	timer_set_mode(ARCH_TIMER_VIRT_ACCESS, mode, clk);
 }
 
 static void arch_timer_set_mode_phys(enum clock_event_mode mode,
 				     struct clock_event_device *clk)
 {
-	timer_set_mode(ARCH_TIMER_PHYS_ACCESS, mode);
+	timer_set_mode(ARCH_TIMER_PHYS_ACCESS, mode, clk);
 }
 
-static inline void set_next_event(const int access, unsigned long evt)
+static inline void set_next_event(const int access, unsigned long evt,
+				  struct clock_event_device *clk)
 {
 	unsigned long ctrl;
-	ctrl = arch_timer_reg_read(access, ARCH_TIMER_REG_CTRL);
+	ctrl = arch_timer_reg_read(access, ARCH_TIMER_REG_CTRL, clk);
 	ctrl |= ARCH_TIMER_CTRL_ENABLE;
 	ctrl &= ~ARCH_TIMER_CTRL_IT_MASK;
-	arch_timer_reg_write(access, ARCH_TIMER_REG_TVAL, evt);
-	arch_timer_reg_write(access, ARCH_TIMER_REG_CTRL, ctrl);
+	arch_timer_reg_write(access, ARCH_TIMER_REG_TVAL, evt, clk);
+	arch_timer_reg_write(access, ARCH_TIMER_REG_CTRL, ctrl, clk);
 }
 
 static int arch_timer_set_next_event_virt(unsigned long evt,
-					  struct clock_event_device *unused)
+					  struct clock_event_device *clk)
 {
-	set_next_event(ARCH_TIMER_VIRT_ACCESS, evt);
+	set_next_event(ARCH_TIMER_VIRT_ACCESS, evt, clk);
 	return 0;
 }
 
 static int arch_timer_set_next_event_phys(unsigned long evt,
-					  struct clock_event_device *unused)
+					  struct clock_event_device *clk)
 {
-	set_next_event(ARCH_TIMER_PHYS_ACCESS, evt);
+	set_next_event(ARCH_TIMER_PHYS_ACCESS, evt, clk);
 	return 0;
 }
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Fri Apr 12 20:27:40 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Fri, 12 Apr 2013 17:27:40 -0700
Subject: [PATCHv2 1/4] Documentation: Add memory mapped ARM architected timer
 binding
In-Reply-To: <1365812863-5367-1-git-send-email-sboyd@codeaurora.org>
References: <1365812863-5367-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1365812863-5367-2-git-send-email-sboyd@codeaurora.org>

Add a binding for the arm architected timer hardware's memory
mapped interface. The mmio timer hardware is made up of one base
frame and a collection of up to 8 timer frames, where each of the
8 timer frames can have either one or two views. A frame
typically maps to a privilege level (user/kernel, hypervisor,
secure). The first view has full access to the registers within a
frame, while the second view can be restricted to particular
registers within a frame. Each frame must support a physical
timer. It's optional for a frame to support a virtual timer.

Cc: devicetree-discuss at lists.ozlabs.org
Cc: Mark Rutland <mark.rutland at arm.com>
Cc: Marc Zyngier <Marc.Zyngier at arm.com>
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 .../devicetree/bindings/arm/arch_timer.txt         | 59 ++++++++++++++++++++--
 1 file changed, 56 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/arch_timer.txt b/Documentation/devicetree/bindings/arm/arch_timer.txt
index 20746e5..ac20cde 100644
--- a/Documentation/devicetree/bindings/arm/arch_timer.txt
+++ b/Documentation/devicetree/bindings/arm/arch_timer.txt
@@ -1,10 +1,14 @@
 * ARM architected timer
 
-ARM cores may have a per-core architected timer, which provides per-cpu timers.
+ARM cores may have a per-core architected timer, which provides per-cpu timers,
+or a memory mapped architected timer, which provides up to 8 frames with a
+physical and optional virtual timer per frame.
 
-The timer is attached to a GIC to deliver its per-processor interrupts.
+The per-core architected timer is attached to a GIC to deliver its
+per-processor interrupts via PPIs. The memory mapped timer is attached to a GIC
+to deliver its interrupts via SPIs.
 
-** Timer node properties:
+** CP15 Timer node properties:
 
 - compatible : Should at least contain one of
 	"arm,armv7-timer"
@@ -26,3 +30,52 @@ Example:
 			     <1 10 0xf08>;
 		clock-frequency = <100000000>;
 	};
+
+** Memory mapped timer node properties
+
+- compatible : Should at least contain "arm,armv7-timer-mem".
+
+- clock-frequency : The frequency of the main counter, in Hz. Optional.
+
+- reg : The control frame base address.
+
+Note that #address-cells, #size-cells, and ranges shall be present to ensure
+the CPU can address a frame's registers.
+
+Frame:
+
+- frame-number: 0 to 7.
+
+- interrupts : Interrupt list for physical and virtual timers in that order.
+  The virtual timer interrupt is optional.
+
+- reg : The first and second view base addresses in that order. The second view
+  base address is optional.
+
+- status : "disabled" indicates the frame is not available for use.
+
+Example:
+
+	timer at f0000000 {
+		compatible = "arm,armv7-timer-mem";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges;
+		reg = <0xf0000000 0x1000>;
+		clock-frequency = <50000000>;
+
+		frame at f0001000 {
+			frame-number = <0>
+			interrupts = <0 13 0x8>,
+				     <0 14 0x8>;
+			reg = <0xf0001000 0x1000>,
+			      <0xf0002000 0x1000>;
+		};
+
+		frame at f0003000 {
+			frame-number = <1>
+			interrupts = <0 15 0x8>;
+			reg = <0xf0003000 0x1000>;
+			status = "disabled";
+		};
+	};
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Fri Apr 12 20:27:41 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Fri, 12 Apr 2013 17:27:41 -0700
Subject: [PATCHv2 2/4] ARM: arch_timers: Pass clock event to set_mode callback
In-Reply-To: <1365812863-5367-1-git-send-email-sboyd@codeaurora.org>
References: <1365812863-5367-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1365812863-5367-3-git-send-email-sboyd@codeaurora.org>

There isn't any reason why we don't pass the event here and we'll
need it in the near future for memory mapped arch timers anyway.

Cc: Mark Rutland <mark.rutland at arm.com>
Cc: Marc Zyngier <Marc.Zyngier at arm.com>
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 drivers/clocksource/arm_arch_timer.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
index 2abb861..545891b 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -140,7 +140,7 @@ static int __cpuinit arch_timer_setup(struct clock_event_device *clk)
 
 	clk->cpumask = cpumask_of(smp_processor_id());
 
-	clk->set_mode(CLOCK_EVT_MODE_SHUTDOWN, NULL);
+	clk->set_mode(CLOCK_EVT_MODE_SHUTDOWN, clk);
 
 	clockevents_config_and_register(clk, arch_timer_rate,
 					0xf, 0x7fffffff);
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Fri Apr 12 20:27:43 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Fri, 12 Apr 2013 17:27:43 -0700
Subject: [PATCHv2 4/4] clocksource: arch_timer: Add support for memory mapped
 timers
In-Reply-To: <1365812863-5367-1-git-send-email-sboyd@codeaurora.org>
References: <1365812863-5367-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1365812863-5367-5-git-send-email-sboyd@codeaurora.org>

Add support for the memory mapped timers by filling in the
read/write functions and adding some parsing code. Note that we
only register one clocksource, preferring the cp15 based
clocksource over the mmio one.

To keep things simple we register one global clockevent. This
covers the case of UP and SMP systems with only mmio hardware and
systems where the memory mapped timers are used as the broadcast
timer in low power modes.

The DT binding allows for per-CPU memory mapped timers in case we
want to support that in the future, but the code isn't added
here. We also don't do much for hypervisor support, although it
should be possible to support it by searching for at least two
frames where one frame has the virtual capability and then
updating KVM timers to support it.

Cc: Mark Rutland <mark.rutland at arm.com>
Cc: Marc Zyngier <Marc.Zyngier at arm.com>
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 drivers/clocksource/arm_arch_timer.c | 415 ++++++++++++++++++++++++++++++-----
 include/clocksource/arm_arch_timer.h |   4 +-
 2 files changed, 361 insertions(+), 58 deletions(-)

diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
index 4f1f002..7385fca 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -16,13 +16,39 @@
 #include <linux/clockchips.h>
 #include <linux/interrupt.h>
 #include <linux/of_irq.h>
+#include <linux/of_address.h>
 #include <linux/io.h>
+#include <linux/slab.h>
 
 #include <asm/arch_timer.h>
 #include <asm/virt.h>
 
 #include <clocksource/arm_arch_timer.h>
 
+#define CNTTIDR		0x08
+#define CNTTIDR_VIRT(n)	(BIT(1) << ((n) * 4))
+
+#define CNTVCT_LO	0x08
+#define CNTVCT_HI	0x0c
+#define CNTFRQ		0x10
+#define CNTP_TVAL	0x28
+#define CNTP_CTL	0x2c
+#define CNTV_TVAL	0x38
+#define CNTV_CTL	0x3c
+
+#define ARCH_CP15_TIMER	BIT(0)
+#define ARCH_MEM_TIMER	BIT(1)
+static unsigned arch_timers_present;
+
+static void __iomem *arch_counter_base;
+
+struct arch_timer {
+	void __iomem *base;
+	struct clock_event_device evt;
+};
+
+#define to_arch_timer(e) container_of(e, struct arch_timer, evt)
+
 static u32 arch_timer_rate;
 
 enum ppi_nr {
@@ -38,6 +64,7 @@ static int arch_timer_ppi[MAX_TIMER_PPI];
 static struct clock_event_device __percpu *arch_timer_evt;
 
 static bool arch_timer_use_virtual = true;
+static bool arch_timer_mem_use_virtual = false;
 
 /*
  * Architected system timer support.
@@ -46,13 +73,69 @@ static bool arch_timer_use_virtual = true;
 static inline void arch_timer_reg_write(int access, int reg, u32 val,
 					struct clock_event_device *clk)
 {
-	arch_timer_reg_write_cp15(access, reg, val);
+	if (access == ARCH_TIMER_MEM_PHYS_ACCESS) {
+		struct arch_timer *timer = to_arch_timer(clk);
+		switch (reg) {
+		case ARCH_TIMER_REG_CTRL:
+			writel_relaxed(val, timer->base + CNTP_CTL);
+			break;
+		case ARCH_TIMER_REG_TVAL:
+			writel_relaxed(val, timer->base + CNTP_TVAL);
+			break;
+		default:
+			BUILD_BUG();
+		}
+	} else if (access == ARCH_TIMER_MEM_VIRT_ACCESS) {
+		struct arch_timer *timer = to_arch_timer(clk);
+		switch (reg) {
+		case ARCH_TIMER_REG_CTRL:
+			writel_relaxed(val, timer->base + CNTV_CTL);
+			break;
+		case ARCH_TIMER_REG_TVAL:
+			writel_relaxed(val, timer->base + CNTV_TVAL);
+			break;
+		default:
+			BUILD_BUG();
+		}
+	} else {
+		arch_timer_reg_write_cp15(access, reg, val);
+	}
 }
 
 static inline u32 arch_timer_reg_read(int access, int reg,
 				      struct clock_event_device *clk)
 {
-	return arch_timer_reg_read_cp15(access, reg);
+	u32 val;
+
+	if (access == ARCH_TIMER_MEM_PHYS_ACCESS) {
+		struct arch_timer *timer = to_arch_timer(clk);
+		switch (reg) {
+		case ARCH_TIMER_REG_CTRL:
+			val = readl_relaxed(timer->base + CNTP_CTL);
+			break;
+		case ARCH_TIMER_REG_TVAL:
+			val = readl_relaxed(timer->base + CNTP_TVAL);
+			break;
+		default:
+			BUILD_BUG();
+		}
+	} else if (access == ARCH_TIMER_MEM_VIRT_ACCESS) {
+		struct arch_timer *timer = to_arch_timer(clk);
+		switch (reg) {
+		case ARCH_TIMER_REG_CTRL:
+			val = readl_relaxed(timer->base + CNTV_CTL);
+			break;
+		case ARCH_TIMER_REG_TVAL:
+			val = readl_relaxed(timer->base + CNTV_TVAL);
+			break;
+		default:
+			BUILD_BUG();
+		}
+	} else {
+		val = arch_timer_reg_read_cp15(access, reg);
+	}
+
+	return val;
 }
 
 static inline irqreturn_t timer_handler(const int access,
@@ -84,6 +167,20 @@ static irqreturn_t arch_timer_handler_phys(int irq, void *dev_id)
 	return timer_handler(ARCH_TIMER_PHYS_ACCESS, evt);
 }
 
+static irqreturn_t arch_timer_handler_phys_mem(int irq, void *dev_id)
+{
+	struct clock_event_device *evt = dev_id;
+
+	return timer_handler(ARCH_TIMER_MEM_PHYS_ACCESS, evt);
+}
+
+static irqreturn_t arch_timer_handler_virt_mem(int irq, void *dev_id)
+{
+	struct clock_event_device *evt = dev_id;
+
+	return timer_handler(ARCH_TIMER_MEM_VIRT_ACCESS, evt);
+}
+
 static inline void timer_set_mode(const int access, int mode,
 				  struct clock_event_device *clk)
 {
@@ -112,6 +209,18 @@ static void arch_timer_set_mode_phys(enum clock_event_mode mode,
 	timer_set_mode(ARCH_TIMER_PHYS_ACCESS, mode, clk);
 }
 
+static void arch_timer_set_mode_virt_mem(enum clock_event_mode mode,
+					 struct clock_event_device *clk)
+{
+	timer_set_mode(ARCH_TIMER_MEM_VIRT_ACCESS, mode, clk);
+}
+
+static void arch_timer_set_mode_phys_mem(enum clock_event_mode mode,
+					 struct clock_event_device *clk)
+{
+	timer_set_mode(ARCH_TIMER_MEM_PHYS_ACCESS, mode, clk);
+}
+
 static inline void set_next_event(const int access, unsigned long evt,
 				  struct clock_event_device *clk)
 {
@@ -137,27 +246,62 @@ static int arch_timer_set_next_event_phys(unsigned long evt,
 	return 0;
 }
 
-static int __cpuinit arch_timer_setup(struct clock_event_device *clk)
+static int arch_timer_set_next_event_virt_mem(unsigned long evt,
+					      struct clock_event_device *clk)
 {
-	clk->features = CLOCK_EVT_FEAT_ONESHOT | CLOCK_EVT_FEAT_C3STOP;
-	clk->name = "arch_sys_timer";
-	clk->rating = 450;
-	if (arch_timer_use_virtual) {
-		clk->irq = arch_timer_ppi[VIRT_PPI];
-		clk->set_mode = arch_timer_set_mode_virt;
-		clk->set_next_event = arch_timer_set_next_event_virt;
+	set_next_event(ARCH_TIMER_MEM_VIRT_ACCESS, evt, clk);
+	return 0;
+}
+
+static int arch_timer_set_next_event_phys_mem(unsigned long evt,
+					      struct clock_event_device *clk)
+{
+	set_next_event(ARCH_TIMER_MEM_PHYS_ACCESS, evt, clk);
+	return 0;
+}
+
+static void __cpuinit __arch_timer_setup(unsigned type,
+				       struct clock_event_device *clk)
+{
+	clk->features = CLOCK_EVT_FEAT_ONESHOT;
+
+	if (type == ARCH_CP15_TIMER) {
+		clk->features |= CLOCK_EVT_FEAT_C3STOP;
+		clk->name = "arch_sys_timer";
+		clk->rating = 450;
+		clk->cpumask = cpumask_of(smp_processor_id());
+		if (arch_timer_use_virtual) {
+			clk->irq = arch_timer_ppi[VIRT_PPI];
+			clk->set_mode = arch_timer_set_mode_virt;
+			clk->set_next_event = arch_timer_set_next_event_virt;
+		} else {
+			clk->irq = arch_timer_ppi[PHYS_SECURE_PPI];
+			clk->set_mode = arch_timer_set_mode_phys;
+			clk->set_next_event = arch_timer_set_next_event_phys;
+		}
 	} else {
-		clk->irq = arch_timer_ppi[PHYS_SECURE_PPI];
-		clk->set_mode = arch_timer_set_mode_phys;
-		clk->set_next_event = arch_timer_set_next_event_phys;
+		clk->name = "arch_mem_timer";
+		clk->rating = 400;
+		clk->cpumask = cpu_all_mask;
+		if (arch_timer_mem_use_virtual) {
+			clk->set_mode = arch_timer_set_mode_virt_mem;
+			clk->set_next_event =
+				arch_timer_set_next_event_virt_mem;
+		} else {
+			clk->set_mode = arch_timer_set_mode_phys_mem;
+			clk->set_next_event =
+				arch_timer_set_next_event_phys_mem;
+		}
 	}
 
-	clk->cpumask = cpumask_of(smp_processor_id());
-
 	clk->set_mode(CLOCK_EVT_MODE_SHUTDOWN, clk);
 
-	clockevents_config_and_register(clk, arch_timer_rate,
-					0xf, 0x7fffffff);
+	clockevents_config_and_register(clk, arch_timer_rate, 0xf, 0x7fffffff);
+}
+
+static int __cpuinit arch_timer_setup(struct clock_event_device *clk)
+{
+	__arch_timer_setup(ARCH_CP15_TIMER, clk);
 
 	if (arch_timer_use_virtual)
 		enable_percpu_irq(arch_timer_ppi[VIRT_PPI], 0);
@@ -172,27 +316,41 @@ static int __cpuinit arch_timer_setup(struct clock_event_device *clk)
 	return 0;
 }
 
-static int arch_timer_available(void)
+static void
+arch_timer_detect_rate(void __iomem *cntbase, struct device_node *np)
 {
-	u32 freq;
-
-	if (arch_timer_rate == 0) {
-		freq = arch_timer_get_cntfrq();
+	/* Who has more than one independent system counter? */
+	if (arch_timer_rate)
+		return;
 
-		/* Check the timer frequency. */
-		if (freq == 0) {
-			pr_warn("Architected timer frequency not available\n");
-			return -EINVAL;
-		}
-
-		arch_timer_rate = freq;
+	/* Try to determine the frequency from the device tree or CNTFRQ */
+	if (of_property_read_u32(np, "clock-frequency", &arch_timer_rate)) {
+		if (cntbase)
+			arch_timer_rate = readl_relaxed(cntbase + CNTFRQ);
+		else
+			arch_timer_rate = arch_timer_get_cntfrq();
 	}
 
-	pr_info_once("Architected local timer running at %lu.%02luMHz (%s).\n",
+	/* Check the timer frequency. */
+	if (arch_timer_rate == 0)
+		pr_warn("Architected timer frequency not available\n");
+}
+
+static void arch_timer_banner(unsigned type)
+{
+	pr_info("Architected %s%s%s timer(s) running at %lu.%02luMHz (%s%s%s).\n",
+		     type & ARCH_CP15_TIMER ? "cp15" : "",
+		     type == (ARCH_CP15_TIMER | ARCH_MEM_TIMER) ?  " and " : "",
+		     type & ARCH_MEM_TIMER ? "mmio" : "",
 		     (unsigned long)arch_timer_rate / 1000000,
 		     (unsigned long)(arch_timer_rate / 10000) % 100,
-		     arch_timer_use_virtual ? "virt" : "phys");
-	return 0;
+		     type & ARCH_CP15_TIMER ?
+			arch_timer_use_virtual ? "virt" : "phys" :
+			"",
+		     type == (ARCH_CP15_TIMER | ARCH_MEM_TIMER) ?  "/" : "",
+		     type & ARCH_MEM_TIMER ?
+			arch_timer_mem_use_virtual ? "virt" : "phys" :
+			"");
 }
 
 u32 arch_timer_get_rate(void)
@@ -200,19 +358,35 @@ u32 arch_timer_get_rate(void)
 	return arch_timer_rate;
 }
 
-u64 arch_timer_read_counter(void)
+static u64 arch_counter_get_mem_cntvct(void)
 {
-	return arch_counter_get_cntvct();
+	u32 vct_lo, vct_hi, tmp_hi;
+
+	do {
+		vct_hi = readl_relaxed(arch_counter_base + CNTVCT_HI);
+		vct_lo = readl_relaxed(arch_counter_base + CNTVCT_LO);
+		tmp_hi = readl_relaxed(arch_counter_base + CNTVCT_HI);
+	} while (vct_hi != tmp_hi);
+
+	return ((u64) vct_hi << 32) | vct_lo;
 }
 
+/*
+ * Default to cp15 based access because arm64 uses this function for
+ * sched_clock() before DT is probed and the cp15 method is guaranteed
+ * to exist on arm64. arm doesn't use this before DT is probed so even
+ * if we don't have the cp15 accessors we won't have a problem.
+ */
+u64 (*arch_timer_read_counter)(void) = arch_counter_get_cntvct;
+
 static cycle_t arch_counter_read(struct clocksource *cs)
 {
-	return arch_counter_get_cntvct();
+	return arch_timer_read_counter();
 }
 
 static cycle_t arch_counter_read_cc(const struct cyclecounter *cc)
 {
-	return arch_counter_get_cntvct();
+	return arch_timer_read_counter();
 }
 
 static struct clocksource clocksource_counter = {
@@ -235,6 +409,23 @@ struct timecounter *arch_timer_get_timecounter(void)
 	return &timecounter;
 }
 
+static void __init arch_counter_register(unsigned type)
+{
+	u64 start_count;
+
+	/* Register the CP15 based counter if we have one */
+	if (type & ARCH_CP15_TIMER)
+		arch_timer_read_counter = arch_counter_get_cntvct;
+	else
+		arch_timer_read_counter = arch_counter_get_mem_cntvct;
+
+	start_count = arch_timer_read_counter();
+	clocksource_register_hz(&clocksource_counter, arch_timer_rate);
+	cyclecounter.mult = clocksource_counter.mult;
+	cyclecounter.shift = clocksource_counter.shift;
+	timecounter_init(&timecounter, &cyclecounter, start_count);
+}
+
 static void __cpuinit arch_timer_stop(struct clock_event_device *clk)
 {
 	pr_debug("arch_timer_teardown disable IRQ%d cpu #%d\n",
@@ -277,22 +468,12 @@ static int __init arch_timer_register(void)
 	int err;
 	int ppi;
 
-	err = arch_timer_available();
-	if (err)
-		goto out;
-
 	arch_timer_evt = alloc_percpu(struct clock_event_device);
 	if (!arch_timer_evt) {
 		err = -ENOMEM;
 		goto out;
 	}
 
-	clocksource_register_hz(&clocksource_counter, arch_timer_rate);
-	cyclecounter.mult = clocksource_counter.mult;
-	cyclecounter.shift = clocksource_counter.shift;
-	timecounter_init(&timecounter, &cyclecounter,
-			 arch_counter_get_cntvct());
-
 	if (arch_timer_use_virtual) {
 		ppi = arch_timer_ppi[VIRT_PPI];
 		err = request_percpu_irq(ppi, arch_timer_handler_virt,
@@ -343,31 +524,51 @@ out:
 	return err;
 }
 
+static int __init arch_timer_mem_register(void __iomem *base, unsigned int irq)
+{
+	int ret;
+	irq_handler_t func;
+	struct arch_timer *t;
+
+	t = kzalloc(sizeof(*t), GFP_KERNEL);
+	if (!t)
+		return -ENOMEM;
+
+	t->base = base;
+	t->evt.irq = irq;
+	__arch_timer_setup(ARCH_MEM_TIMER, &t->evt);
+
+	if (arch_timer_mem_use_virtual)
+		func = arch_timer_handler_virt_mem;
+	else
+		func = arch_timer_handler_phys_mem;
+
+	ret = request_irq(irq, func, IRQF_TIMER, "arch_mem_timer", &t->evt);
+	if (ret)
+		kfree(t);
+
+	return ret;
+}
+
 static const struct of_device_id arch_timer_of_match[] __initconst = {
 	{ .compatible	= "arm,armv7-timer",	},
 	{ .compatible	= "arm,armv8-timer",	},
 	{},
 };
 
-int __init arch_timer_init(void)
+static int __init arch_timer_parse(void)
 {
 	struct device_node *np;
-	u32 freq;
 	int i;
 
 	np = of_find_matching_node(NULL, arch_timer_of_match);
-	if (!np) {
-		pr_err("arch_timer: can't find DT node\n");
-		return -ENODEV;
-	}
-
-	/* Try to determine the frequency from the device tree or CNTFRQ */
-	if (!of_property_read_u32(np, "clock-frequency", &freq))
-		arch_timer_rate = freq;
+	if (!np)
+		return 0;
 
+	arch_timers_present |= ARCH_CP15_TIMER;
 	for (i = PHYS_SECURE_PPI; i < MAX_TIMER_PPI; i++)
 		arch_timer_ppi[i] = irq_of_parse_and_map(np, i);
-
+	arch_timer_detect_rate(NULL, np);
 	of_node_put(np);
 
 	/*
@@ -390,3 +591,103 @@ int __init arch_timer_init(void)
 
 	return arch_timer_register();
 }
+
+static const struct of_device_id arch_timer_mem_of_match[] __initconst = {
+	{ .compatible	= "arm,armv7-timer-mem", },
+	{},
+};
+
+static int __init arch_timer_mem_parse(void)
+{
+	struct device_node *np, *frame, *best_frame = NULL;
+	void __iomem *cntctlbase, *base;
+	unsigned int irq;
+	u32 cnttidr;
+
+	np = of_find_matching_node(NULL, arch_timer_mem_of_match);
+	if (!np)
+		return 0;
+
+	arch_timers_present |= ARCH_MEM_TIMER;
+	cntctlbase = of_iomap(np, 0);
+	if (!cntctlbase) {
+		pr_err("arch_timer: Can't find CNTCTLBase\n");
+		of_node_put(np);
+		return -ENOMEM;
+	}
+
+	cnttidr = readl_relaxed(cntctlbase + CNTTIDR);
+	iounmap(cntctlbase);
+
+	/*
+	 * Try to find a virtual capable frame. Otherwise fall back to a
+	 * physical capable frame.
+	 */
+	for_each_available_child_of_node(np, frame) {
+		int n;
+
+		if (of_property_read_u32(frame, "frame-number", &n)) {
+			pr_err("arch_timer: Missing frame-number\n");
+			of_node_put(best_frame);
+			of_node_put(frame);
+			of_node_put(np);
+			return -EINVAL;
+		}
+
+		if (cnttidr & CNTTIDR_VIRT(n)) {
+			of_node_put(best_frame);
+			best_frame = frame;
+			arch_timer_mem_use_virtual = true;
+			break;
+		}
+		of_node_put(best_frame);
+		best_frame = of_node_get(frame);
+	}
+	of_node_put(np);
+
+	base = arch_counter_base = of_iomap(best_frame, 0);
+	if (!base) {
+		pr_err("arch_timer: Can't map frame's registers\n");
+		of_node_put(best_frame);
+		return -ENOMEM;
+	}
+
+	if (arch_timer_mem_use_virtual)
+		irq = irq_of_parse_and_map(best_frame, 1);
+	else
+		irq = irq_of_parse_and_map(best_frame, 0);
+	if (!irq) {
+		pr_err("arch_timer: Frame missing %s irq",
+				arch_timer_mem_use_virtual ? "virt" : "phys");
+		of_node_put(best_frame);
+		return -EINVAL;
+	}
+
+	arch_timer_detect_rate(base, best_frame);
+	of_node_put(best_frame);
+
+	return arch_timer_mem_register(base, irq);
+}
+
+int __init arch_timer_init(void)
+{
+	int err;
+
+	err = arch_timer_parse();
+	if (err)
+		return err;
+
+	err = arch_timer_mem_parse();
+	if (err)
+		return err;
+
+	if (!(arch_timers_present & (ARCH_CP15_TIMER | ARCH_MEM_TIMER))) {
+		pr_err("arch_timer: can't find DT node\n");
+		return -ENODEV;
+	}
+
+	arch_timer_banner(arch_timers_present);
+	arch_counter_register(arch_timers_present);
+
+	return 0;
+}
diff --git a/include/clocksource/arm_arch_timer.h b/include/clocksource/arm_arch_timer.h
index 3883812..c3ff7fe 100644
--- a/include/clocksource/arm_arch_timer.h
+++ b/include/clocksource/arm_arch_timer.h
@@ -28,12 +28,14 @@
 
 #define ARCH_TIMER_PHYS_ACCESS		0
 #define ARCH_TIMER_VIRT_ACCESS		1
+#define ARCH_TIMER_MEM_PHYS_ACCESS	2
+#define ARCH_TIMER_MEM_VIRT_ACCESS	3
 
 #ifdef CONFIG_ARM_ARCH_TIMER
 
 extern int arch_timer_init(void);
 extern u32 arch_timer_get_rate(void);
-extern u64 arch_timer_read_counter(void);
+extern u64 (*arch_timer_read_counter)(void);
 extern struct timecounter *arch_timer_get_timecounter(void);
 
 #else
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Fri Apr 12 20:49:47 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Fri, 12 Apr 2013 17:49:47 -0700
Subject: [PATCHv2] ARM: arch_timer: Silence debug preempt warnings
In-Reply-To: <211ac95efd49bd57933aec8c8e746648@localhost>
References: <1365195449-6755-1-git-send-email-sboyd@codeaurora.org>
 <211ac95efd49bd57933aec8c8e746648@localhost>
Message-ID: <5168ABAB.4090402@codeaurora.org>

On 04/06/13 03:41, Marc Zyngier wrote:
> On Fri,  5 Apr 2013 13:57:29 -0700, Stephen Boyd <sboyd at codeaurora.org>
> wrote:
>> Hot-plugging with CONFIG_DEBUG_PREEMPT=y on a device with arm
>> architected timers causes a slew of "using smp_processor_id() in
>> preemptible" warnings:
>>
>>   BUG: using smp_processor_id() in preemptible [00000000] code: sh/111
>>   caller is arch_timer_cpu_notify+0x14/0xc8
>>
>> This happens because sometimes the cpu notifier,
>> arch_timer_cpu_notify(), is called in preemptible context and
>> other times in non-preemptible context but we use this_cpu_ptr()
>> to retrieve the clockevent in all cases. We're only going to
>> actually use the pointer in non-preemptible context though, so
>> push the this_cpu_ptr() access down into the cases to force the
>> checks to occur only in non-preemptible contexts.
>>
>> Cc: Mark Rutland <mark.rutland at arm.com>
>> Cc: Marc Zyngier <Marc.Zyngier at arm.com>
>> Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
>> ---
>>
>> Changes since v1:
>>  * Pushed down this_cpu_ptr and added a comment
>>
>>  drivers/clocksource/arm_arch_timer.c | 10 ++++++----
>>  1 file changed, 6 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/clocksource/arm_arch_timer.c
>> b/drivers/clocksource/arm_arch_timer.c
>> index d7ad425..a65a710 100644
>> --- a/drivers/clocksource/arm_arch_timer.c
>> +++ b/drivers/clocksource/arm_arch_timer.c
>> @@ -248,14 +248,16 @@ static void __cpuinit arch_timer_stop(struct
>> clock_event_device *clk)
>>  static int __cpuinit arch_timer_cpu_notify(struct notifier_block *self,
>>  					   unsigned long action, void *hcpu)
>>  {
>> -	struct clock_event_device *evt = this_cpu_ptr(arch_timer_evt);
>> -
>> +	/*
>> +	 * Grab cpu pointer in each case to avoid spurious
>> +	 * preemptible warnings
>> +	 */
>>  	switch (action & ~CPU_TASKS_FROZEN) {
>>  	case CPU_STARTING:
>> -		arch_timer_setup(evt);
>> +		arch_timer_setup(this_cpu_ptr(arch_timer_evt));
>>  		break;
>>  	case CPU_DYING:
>> -		arch_timer_stop(evt);
>> +		arch_timer_stop(this_cpu_ptr(arch_timer_evt));
>>  		break;
>>  	}
> Looks good to me.
>
> Acked-by: Marc Zyngier <marc.zyngier at arm.com>
>

Thanks Marc.

Thomas/John, can you pick this up for 3.10?

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation



From haojian.zhuang at gmail.com  Sat Apr 13 00:13:14 2013
From: haojian.zhuang at gmail.com (Haojian Zhuang)
Date: Sat, 13 Apr 2013 12:13:14 +0800
Subject: [GIT PULL] [for 3.10] pull request from armsoc/dt branch in pxa git
 tree
Message-ID: <CAN1soZxcmHMABTGi6FBtXysmY0TwWx7cdEvf1_ycHv2RtCLcpw@mail.gmail.com>

Hi Arnd & Olof,

Please help to pull armsoc/dt branch from pxa git tree. These patches
are used to enable hi3xxx SoC
and they're depend on Rob's clock source patches.

Regards
Haojian

The following changes since commit f6161aa153581da4a3867a2d1a7caf4be19b6ec9:

  Linux 3.9-rc2 (2013-03-10 16:54:19 -0700)

are available in the git repository at:

  git://github.com/hzhuang1/linux.git armsoc/dt

for you to fetch changes up to 280aab1bbd0521381cba7aa942db388b15cec6bd:

  ARM: config: append arch hi3xxx into multi defconfig (2013-04-13
11:54:04 +0800)

----------------------------------------------------------------
Arnd Bergmann (2):
      clocksource: make CLOCKSOURCE_OF_DECLARE type safe
      ARM: make machine_desc->init_time default to clocksource_of_init

Haojian Zhuang (6):
      devtree: add binding documentation for sp804
      ARM: debug: support debug ll on hisilicon soc
      clk: hi3xxx: add clock support
      ARM: hi3xxx: add board support with device tree
      ARM: hi3xxx: enable hi4511 with device tree
      ARM: config: append arch hi3xxx into multi defconfig

Rob Herring (17):
      clocksource: add empty version of clocksource_of_init
      clocksource: pass DT node pointer to init functions
      clocksource: tegra20: use the device_node pointer passed to init
      ARM: smp_twd: convert to use CLKSRC_OF init
      ARM: sched_clock: allow changing to higher frequency counter
      ARM: make sched_clock just call a function pointer
      ARM: arch_timer: use full 64-bit counter for sched_clock
      ARM: convert arm/arm64 arch timer to use CLKSRC_OF init
      OF: add empty of_device_is_available for !OF
      ARM: timer-sp: convert to use CLKSRC_OF init
      ARM: highbank: use OF init for sp804 timer
      ARM: vexpress: remove sp804 OF init
      ARM: dts: vexpress: disable CA9 core tile sp804 timer
      ARM: vexpress: remove extra timer-sp control register clearing
      ARM: versatile: add versatile dtbs to dtbs target
      ARM: versatile: use OF init for sp804 timer
      ARM: integrator-cp: convert use CLKSRC_OF for timer init

 Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt |   10 +
 Documentation/devicetree/bindings/clock/hisilicon.txt         |   73 +++++
 Documentation/devicetree/bindings/timer/arm,sp804.txt         |   29 ++
 arch/arm/Kconfig                                              |    4 +
 arch/arm/Kconfig.debug                                        |   15 ++
 arch/arm/Makefile                                             |    1 +
 arch/arm/boot/dts/Makefile                                    |    3 +
 arch/arm/boot/dts/hi3620.dtsi                                 | 1155
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 arch/arm/boot/dts/hi4511.dts                                  |  738
++++++++++++++++++++++++++++++++++++++++++++++++++
 arch/arm/boot/dts/integratorcp.dts                            |    6 +-
 arch/arm/boot/dts/versatile-ab.dts                            |   12 +
 arch/arm/boot/dts/vexpress-v2p-ca9.dts                        |    1 +
 arch/arm/common/timer-sp.c                                    |  140 ++++++++--
 arch/arm/configs/multi_v7_defconfig                           |    1 +
 arch/arm/include/asm/arch_timer.h                             |   13 +-
 arch/arm/include/asm/hardware/timer-sp.h                      |   16 +-
 arch/arm/include/asm/sched_clock.h                            |    2 +
 arch/arm/include/asm/smp_twd.h                                |    8 -
 arch/arm/include/debug/hisilicon.S                            |   30 +++
 arch/arm/kernel/arch_timer.c                                  |   29 +-
 arch/arm/kernel/sched_clock.c                                 |   15 +-
 arch/arm/kernel/smp_twd.c                                     |   17 +-
 arch/arm/kernel/time.c                                        |    7 +-
 arch/arm/mach-exynos/mach-exynos5-dt.c                        |    1 -
 arch/arm/mach-exynos/mct.c                                    |    6 -
 arch/arm/mach-hi3xxx/Kconfig                                  |   13 +
 arch/arm/mach-hi3xxx/Makefile                                 |    5 +
 arch/arm/mach-hi3xxx/hi3xxx.c                                 |   45 ++++
 arch/arm/mach-highbank/highbank.c                             |   27 +-
 arch/arm/mach-imx/mach-imx6q.c                                |    5 +-
 arch/arm/mach-integrator/integrator_cp.c                      |   34 ---
 arch/arm/mach-omap2/timer.c                                   |    7 +-
 arch/arm/mach-shmobile/board-kzm9d.c                          |    1 -
 arch/arm/mach-shmobile/setup-emev2.c                          |    1 -
 arch/arm/mach-shmobile/setup-r8a7740.c                        |    1 -
 arch/arm/mach-shmobile/setup-sh7372.c                         |    1 -
 arch/arm/mach-shmobile/setup-sh73a0.c                         |    1 -
 arch/arm/mach-shmobile/timer.c                                |    7 +-
 arch/arm/mach-spear13xx/spear13xx.c                           |    4 +-
 arch/arm/mach-ux500/timer.c                                   |    3 +-
 arch/arm/mach-versatile/core.c                                |   26 +-
 arch/arm/mach-versatile/versatile_dt.c                        |    1 -
 arch/arm/mach-vexpress/v2m.c                                  |   25 +-
 arch/arm/mach-virt/virt.c                                     |    9 -
 arch/arm64/include/asm/arch_timer.h                           |    5 +
 arch/arm64/kernel/time.c                                      |    6 +-
 drivers/clk/Makefile                                          |    1 +
 drivers/clk/clk-hi3xxx.c                                      |  643
++++++++++++++++++++++++++++++++++++++++++++
 drivers/clocksource/Kconfig                                   |    1 +
 drivers/clocksource/arm_arch_timer.c                          |   23 +-
 drivers/clocksource/bcm2835_timer.c                           |   12 +-
 drivers/clocksource/clksrc-of.c                               |    5 +-
 drivers/clocksource/tegra20_timer.c                           |   73 ++---
 drivers/clocksource/vt8500_timer.c                            |   16 +-
 include/clocksource/arm_arch_timer.h                          |    6 -
 include/linux/clocksource.h                                   |   12 +-
 include/linux/of.h                                            |    5 +
 57 files changed, 3053 insertions(+), 303 deletions(-)
 create mode 100644
Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
 create mode 100644 Documentation/devicetree/bindings/clock/hisilicon.txt
 create mode 100644 Documentation/devicetree/bindings/timer/arm,sp804.txt
 create mode 100644 arch/arm/boot/dts/hi3620.dtsi
 create mode 100644 arch/arm/boot/dts/hi4511.dts
 create mode 100644 arch/arm/include/debug/hisilicon.S
 create mode 100644 arch/arm/mach-hi3xxx/Kconfig
 create mode 100644 arch/arm/mach-hi3xxx/Makefile
 create mode 100644 arch/arm/mach-hi3xxx/hi3xxx.c
 create mode 100644 drivers/clk/clk-hi3xxx.c


From shc_work at mail.ru  Sat Apr 13 00:21:40 2013
From: shc_work at mail.ru (Alexander Shiyan)
Date: Sat, 13 Apr 2013 08:21:40 +0400
Subject: [PATCH 2/2] GPIO: clps711x: Add DT support
In-Reply-To: <1365826900-30136-1-git-send-email-shc_work@mail.ru>
References: <1365826900-30136-1-git-send-email-shc_work@mail.ru>
Message-ID: <1365826900-30136-2-git-send-email-shc_work@mail.ru>

Add DT support to the CLPS711X GPIO driver.

Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
---
 .../devicetree/bindings/gpio/clps711x-gpio.txt     | 28 ++++++++++++++++++++++
 drivers/gpio/gpio-clps711x.c                       | 14 ++++++++---
 2 files changed, 39 insertions(+), 3 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/gpio/clps711x-gpio.txt

diff --git a/Documentation/devicetree/bindings/gpio/clps711x-gpio.txt b/Documentation/devicetree/bindings/gpio/clps711x-gpio.txt
new file mode 100644
index 0000000..0fe2bb6
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/clps711x-gpio.txt
@@ -0,0 +1,28 @@
+Cirrus Logic CLPS711X GPIO controller
+
+Required properties:
+- compatible : Should be "cirrus,clps711x-gpio"
+- reg : Physical base GPIO controller registers location and length.
+  There should be two registers, first is DATA register, the second
+  is DIRECTION.
+- gpio-controller : Marks the device node as a gpio controller.
+- #gpio-cells : Should be two. The first cell is the pin number and
+  the second cell is used to specify the gpio polarity:
+    0 = active high
+    1 = active low
+
+Note: Each GPIO port should have an alias correctly numbered in "aliases"
+node.
+
+Example:
+
+aliases {
+	gpio0 = &porta;
+};
+
+porta: gpio at 80000000 {
+	compatible = "cirrus,clps711x-gpio";
+	reg = <0x80000000 0x1>, <0x80000040 0x1>;
+	gpio-controller;
+	#gpio-cells = <2>;
+};
diff --git a/drivers/gpio/gpio-clps711x.c b/drivers/gpio/gpio-clps711x.c
index 3c71815..e2e7ec9 100644
--- a/drivers/gpio/gpio-clps711x.c
+++ b/drivers/gpio/gpio-clps711x.c
@@ -16,10 +16,11 @@
 
 static int clps711x_gpio_probe(struct platform_device *pdev)
 {
+	struct device_node *np = pdev->dev.of_node;
 	void __iomem *dat, *dir;
 	struct bgpio_chip *bgc;
 	struct resource *res;
-	int err, id = pdev->id;
+	int err, id = np ? of_alias_get_id(np, "gpio") : pdev->id;
 
 	if ((id < 0) || (id > 4))
 		return -ENODEV;
@@ -76,10 +77,17 @@ static int clps711x_gpio_remove(struct platform_device *pdev)
 	return bgpio_remove(bgc);
 }
 
+static const struct of_device_id clps711x_gpio_ids[] = {
+	{ .compatible = "cirrus,clps711x-gpio" },
+	{ },
+};
+MODULE_DEVICE_TABLE(of, clps711x_gpio_ids);
+
 static struct platform_driver clps711x_gpio_driver = {
 	.driver	= {
-		.name	= "clps711x-gpio",
-		.owner	= THIS_MODULE,
+		.name		= "clps711x-gpio",
+		.owner		= THIS_MODULE,
+		.of_match_table	= of_match_ptr(clps711x_gpio_ids),
 	},
 	.probe	= clps711x_gpio_probe,
 	.remove	= clps711x_gpio_remove,
-- 
1.8.1.5



From shc_work at mail.ru  Sat Apr 13 00:21:39 2013
From: shc_work at mail.ru (Alexander Shiyan)
Date: Sat, 13 Apr 2013 08:21:39 +0400
Subject: [PATCH 1/2] GPIO: clps711x: Rewrite driver for using generic GPIO code
Message-ID: <1365826900-30136-1-git-send-email-shc_work@mail.ru>

This patch provides rewritten driver for CLPS711X GPIO which uses
generic GPIO code.

Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
---
 arch/arm/configs/clps711x_defconfig            |   1 +
 arch/arm/mach-clps711x/Makefile                |   5 +-
 arch/arm/mach-clps711x/board-autcpu12.c        |   2 +
 arch/arm/mach-clps711x/board-cdb89712.c        |   2 +
 arch/arm/mach-clps711x/board-edb7211.c         |   7 +
 arch/arm/mach-clps711x/board-p720t.c           |  10 +-
 arch/arm/mach-clps711x/devices.c               |  56 ++++++
 arch/arm/mach-clps711x/devices.h               |  12 ++
 arch/arm/mach-clps711x/include/mach/clps711x.h |  23 +--
 drivers/gpio/Kconfig                           |   5 +-
 drivers/gpio/gpio-clps711x.c                   | 228 +++++++------------------
 11 files changed, 164 insertions(+), 187 deletions(-)
 create mode 100644 arch/arm/mach-clps711x/devices.c
 create mode 100644 arch/arm/mach-clps711x/devices.h

diff --git a/arch/arm/configs/clps711x_defconfig b/arch/arm/configs/clps711x_defconfig
index 1cd94c3..e9a1747 100644
--- a/arch/arm/configs/clps711x_defconfig
+++ b/arch/arm/configs/clps711x_defconfig
@@ -64,6 +64,7 @@ CONFIG_CS89x0_PLATFORM=y
 CONFIG_SERIAL_CLPS711X_CONSOLE=y
 # CONFIG_HW_RANDOM is not set
 CONFIG_SPI=y
+CONFIG_GPIO_CLPS711X=y
 CONFIG_GPIO_GENERIC_PLATFORM=y
 # CONFIG_HWMON is not set
 CONFIG_FB=y
diff --git a/arch/arm/mach-clps711x/Makefile b/arch/arm/mach-clps711x/Makefile
index 992995a..f30ed2b 100644
--- a/arch/arm/mach-clps711x/Makefile
+++ b/arch/arm/mach-clps711x/Makefile
@@ -4,10 +4,7 @@
 
 # Object file lists.
 
-obj-y			:= common.o
-obj-m			:=
-obj-n			:=
-obj-			:=
+obj-y				:= common.o devices.o
 
 obj-$(CONFIG_ARCH_AUTCPU12)	+= board-autcpu12.o
 obj-$(CONFIG_ARCH_CDB89712)	+= board-cdb89712.o
diff --git a/arch/arm/mach-clps711x/board-autcpu12.c b/arch/arm/mach-clps711x/board-autcpu12.c
index f385847..1e22cb4 100644
--- a/arch/arm/mach-clps711x/board-autcpu12.c
+++ b/arch/arm/mach-clps711x/board-autcpu12.c
@@ -43,6 +43,7 @@
 #include <mach/autcpu12.h>
 
 #include "common.h"
+#include "devices.h"
 
 #define AUTCPU12_CS8900_BASE	(CS2_PHYS_BASE + 0x300)
 #define AUTCPU12_CS8900_IRQ	(IRQ_EINT3)
@@ -149,6 +150,7 @@ static struct platform_device autcpu12_mmgpio_pdev __initdata = {
 
 static void __init autcpu12_init(void)
 {
+	clps711x_devices_init();
 	platform_device_register_simple("video-clps711x", 0, NULL, 0);
 	platform_device_register_simple("cs89x0", 0, autcpu12_cs8900_resource,
 					ARRAY_SIZE(autcpu12_cs8900_resource));
diff --git a/arch/arm/mach-clps711x/board-cdb89712.c b/arch/arm/mach-clps711x/board-cdb89712.c
index baab7da..a80ae57 100644
--- a/arch/arm/mach-clps711x/board-cdb89712.c
+++ b/arch/arm/mach-clps711x/board-cdb89712.c
@@ -39,6 +39,7 @@
 #include <asm/mach/map.h>
 
 #include "common.h"
+#include "devices.h"
 
 #define CDB89712_CS8900_BASE	(CS2_PHYS_BASE + 0x300)
 #define CDB89712_CS8900_IRQ	(IRQ_EINT3)
@@ -127,6 +128,7 @@ static struct platform_device cdb89712_sram_pdev __initdata = {
 
 static void __init cdb89712_init(void)
 {
+	clps711x_devices_init();
 	platform_device_register(&cdb89712_flash_pdev);
 	platform_device_register(&cdb89712_bootrom_pdev);
 	platform_device_register(&cdb89712_sram_pdev);
diff --git a/arch/arm/mach-clps711x/board-edb7211.c b/arch/arm/mach-clps711x/board-edb7211.c
index 5f928e9..e1c5573 100644
--- a/arch/arm/mach-clps711x/board-edb7211.c
+++ b/arch/arm/mach-clps711x/board-edb7211.c
@@ -29,6 +29,7 @@
 #include <mach/hardware.h>
 
 #include "common.h"
+#include "devices.h"
 
 #define VIDEORAM_SIZE		SZ_128K
 
@@ -151,6 +152,11 @@ fixup_edb7211(struct tag *tags, char **cmdline, struct meminfo *mi)
 
 static void __init edb7211_init(void)
 {
+	clps711x_devices_init();
+}
+
+static void __init edb7211_init_late(void)
+{
 	gpio_request_array(edb7211_gpios, ARRAY_SIZE(edb7211_gpios));
 
 	platform_device_register(&edb7211_flash_pdev);
@@ -175,6 +181,7 @@ MACHINE_START(EDB7211, "CL-EDB7211 (EP7211 eval board)")
 	.init_irq	= clps711x_init_irq,
 	.init_time	= clps711x_timer_init,
 	.init_machine	= edb7211_init,
+	.init_late	= edb7211_init_late,
 	.handle_irq	= clps711x_handle_irq,
 	.restart	= clps711x_restart,
 MACHINE_END
diff --git a/arch/arm/mach-clps711x/board-p720t.c b/arch/arm/mach-clps711x/board-p720t.c
index 8d3ee67..48d0737 100644
--- a/arch/arm/mach-clps711x/board-p720t.c
+++ b/arch/arm/mach-clps711x/board-p720t.c
@@ -43,6 +43,7 @@
 #include <video/platform_lcd.h>
 
 #include "common.h"
+#include "devices.h"
 
 #define P720T_USERLED		CLPS711X_GPIO(3, 0)
 #define P720T_NAND_CLE		CLPS711X_GPIO(4, 0)
@@ -199,6 +200,11 @@ static struct gpio_led_platform_data p720t_gpio_led_pdata __initdata = {
 
 static void __init p720t_init(void)
 {
+	clps711x_devices_init();
+}
+
+static void __init p720t_init_late(void)
+{
 	platform_device_register(&p720t_nand_pdev);
 	platform_device_register_data(&platform_bus, "platform-lcd", 0,
 				      &p720t_lcd_power_pdata,
@@ -207,10 +213,6 @@ static void __init p720t_init(void)
 				      &p720t_lcd_backlight_pdata,
 				      sizeof(p720t_lcd_backlight_pdata));
 	platform_device_register_simple("video-clps711x", 0, NULL, 0);
-}
-
-static void __init p720t_init_late(void)
-{
 	platform_device_register_data(&platform_bus, "leds-gpio", 0,
 				      &p720t_gpio_led_pdata,
 				      sizeof(p720t_gpio_led_pdata));
diff --git a/arch/arm/mach-clps711x/devices.c b/arch/arm/mach-clps711x/devices.c
new file mode 100644
index 0000000..100ddec
--- /dev/null
+++ b/arch/arm/mach-clps711x/devices.c
@@ -0,0 +1,56 @@
+/*
+ *  CLPS711X common devices definitions
+ *
+ *  Copyright (C) 2013 Alexander Shiyan <shc_work at mail.ru>
+ *
+ * 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.
+ */
+
+#include <linux/io.h>
+#include <linux/sizes.h>
+#include <linux/platform_device.h>
+
+#include <mach/hardware.h>
+
+static void __init clps711x_add_gpio(void)
+{
+	const struct resource clps711x_gpio0_res[] = {
+		DEFINE_RES_MEM(PADR, SZ_1),
+		DEFINE_RES_MEM(PADDR, SZ_1),
+	};
+	const struct resource clps711x_gpio1_res[] = {
+		DEFINE_RES_MEM(PBDR, SZ_1),
+		DEFINE_RES_MEM(PBDDR, SZ_1),
+	};
+	const struct resource clps711x_gpio2_res[] = {
+		DEFINE_RES_MEM(PCDR, SZ_1),
+		DEFINE_RES_MEM(PCDDR, SZ_1),
+	};
+	const struct resource clps711x_gpio3_res[] = {
+		DEFINE_RES_MEM(PDDR, SZ_1),
+		DEFINE_RES_MEM(PDDDR, SZ_1),
+	};
+	const struct resource clps711x_gpio4_res[] = {
+		DEFINE_RES_MEM(PEDR, SZ_1),
+		DEFINE_RES_MEM(PEDDR, SZ_1),
+	};
+
+	platform_device_register_simple("clps711x-gpio", 0, clps711x_gpio0_res,
+					ARRAY_SIZE(clps711x_gpio0_res));
+	platform_device_register_simple("clps711x-gpio", 1, clps711x_gpio1_res,
+					ARRAY_SIZE(clps711x_gpio1_res));
+	platform_device_register_simple("clps711x-gpio", 2, clps711x_gpio2_res,
+					ARRAY_SIZE(clps711x_gpio2_res));
+	platform_device_register_simple("clps711x-gpio", 3, clps711x_gpio3_res,
+					ARRAY_SIZE(clps711x_gpio3_res));
+	platform_device_register_simple("clps711x-gpio", 4, clps711x_gpio4_res,
+					ARRAY_SIZE(clps711x_gpio4_res));
+}
+
+void __init clps711x_devices_init(void)
+{
+	clps711x_add_gpio();
+}
diff --git a/arch/arm/mach-clps711x/devices.h b/arch/arm/mach-clps711x/devices.h
new file mode 100644
index 0000000..a5efc17
--- /dev/null
+++ b/arch/arm/mach-clps711x/devices.h
@@ -0,0 +1,12 @@
+/*
+ *  CLPS711X common devices definitions
+ *
+ *  Copyright (C) 2013 Alexander Shiyan <shc_work at mail.ru>
+ *
+ * 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.
+ */
+
+void clps711x_devices_init(void);
diff --git a/arch/arm/mach-clps711x/include/mach/clps711x.h b/arch/arm/mach-clps711x/include/mach/clps711x.h
index 01d1b95..9279f0a 100644
--- a/arch/arm/mach-clps711x/include/mach/clps711x.h
+++ b/arch/arm/mach-clps711x/include/mach/clps711x.h
@@ -23,16 +23,19 @@
 
 #define CLPS711X_PHYS_BASE	(0x80000000)
 
-#define PADR		(0x0000)
-#define PBDR		(0x0001)
-#define PCDR		(0x0002)
-#define PDDR		(0x0003)
-#define PADDR		(0x0040)
-#define PBDDR		(0x0041)
-#define PCDDR		(0x0042)
-#define PDDDR		(0x0043)
-#define PEDR		(0x0083)
-#define PEDDR		(0x00c3)
+#define CLPS711X_REGS(x)	(CLPS711X_PHYS_BASE + (x))
+
+#define PADR		CLPS711X_REGS(0x0000)
+#define PBDR		CLPS711X_REGS(0x0001)
+#define PCDR		CLPS711X_REGS(0x0002)
+#define PDDR		CLPS711X_REGS(0x0003)
+#define PADDR		CLPS711X_REGS(0x0040)
+#define PBDDR		CLPS711X_REGS(0x0041)
+#define PCDDR		CLPS711X_REGS(0x0042)
+#define PDDDR		CLPS711X_REGS(0x0043)
+#define PEDR		CLPS711X_REGS(0x0083)
+#define PEDDR		CLPS711X_REGS(0x00c3)
+
 #define SYSCON1		(0x0100)
 #define SYSFLG1		(0x0140)
 #define MEMCFG1		(0x0180)
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 723091d..47973c1 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -110,8 +110,11 @@ config GPIO_MAX730X
 comment "Memory mapped GPIO drivers:"
 
 config GPIO_CLPS711X
-	def_bool y
+	tristate "CLPS711X GPIO support"
 	depends on ARCH_CLPS711X
+	select GPIO_GENERIC
+	help
+	  Say yes here to support GPIO on CLPS711X SoCs.
 
 config GPIO_GENERIC_PLATFORM
 	tristate "Generic memory-mapped GPIO controller support (MMIO platform device)"
diff --git a/drivers/gpio/gpio-clps711x.c b/drivers/gpio/gpio-clps711x.c
index ce63b75..3c71815 100644
--- a/drivers/gpio/gpio-clps711x.c
+++ b/drivers/gpio/gpio-clps711x.c
@@ -1,7 +1,7 @@
 /*
  *  CLPS711X GPIO driver
  *
- *  Copyright (C) 2012 Alexander Shiyan <shc_work at mail.ru>
+ *  Copyright (C) 2013 Alexander Shiyan <shc_work at mail.ru>
  *
  * 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
@@ -9,191 +9,83 @@
  * (at your option) any later version.
  */
 
-#include <linux/io.h>
-#include <linux/slab.h>
 #include <linux/gpio.h>
 #include <linux/module.h>
-#include <linux/spinlock.h>
+#include <linux/basic_mmio_gpio.h>
 #include <linux/platform_device.h>
 
-#include <mach/hardware.h>
-
-#define CLPS711X_GPIO_PORTS	5
-#define CLPS711X_GPIO_NAME	"gpio-clps711x"
-
-struct clps711x_gpio {
-	struct gpio_chip	chip[CLPS711X_GPIO_PORTS];
-	spinlock_t		lock;
-};
-
-static void __iomem *clps711x_ports[] = {
-	CLPS711X_VIRT_BASE + PADR,
-	CLPS711X_VIRT_BASE + PBDR,
-	CLPS711X_VIRT_BASE + PCDR,
-	CLPS711X_VIRT_BASE + PDDR,
-	CLPS711X_VIRT_BASE + PEDR,
-};
-
-static void __iomem *clps711x_pdirs[] = {
-	CLPS711X_VIRT_BASE + PADDR,
-	CLPS711X_VIRT_BASE + PBDDR,
-	CLPS711X_VIRT_BASE + PCDDR,
-	CLPS711X_VIRT_BASE + PDDDR,
-	CLPS711X_VIRT_BASE + PEDDR,
-};
-
-#define clps711x_port(x)	clps711x_ports[x->base / 8]
-#define clps711x_pdir(x)	clps711x_pdirs[x->base / 8]
-
-static int gpio_clps711x_get(struct gpio_chip *chip, unsigned offset)
+static int clps711x_gpio_probe(struct platform_device *pdev)
 {
-	return !!(readb(clps711x_port(chip)) & (1 << offset));
-}
+	void __iomem *dat, *dir;
+	struct bgpio_chip *bgc;
+	struct resource *res;
+	int err, id = pdev->id;
 
-static void gpio_clps711x_set(struct gpio_chip *chip, unsigned offset,
-			      int value)
-{
-	int tmp;
-	unsigned long flags;
-	struct clps711x_gpio *gpio = dev_get_drvdata(chip->dev);
+	if ((id < 0) || (id > 4))
+		return -ENODEV;
 
-	spin_lock_irqsave(&gpio->lock, flags);
-	tmp = readb(clps711x_port(chip)) & ~(1 << offset);
-	if (value)
-		tmp |= 1 << offset;
-	writeb(tmp, clps711x_port(chip));
-	spin_unlock_irqrestore(&gpio->lock, flags);
-}
-
-static int gpio_clps711x_dir_in(struct gpio_chip *chip, unsigned offset)
-{
-	int tmp;
-	unsigned long flags;
-	struct clps711x_gpio *gpio = dev_get_drvdata(chip->dev);
-
-	spin_lock_irqsave(&gpio->lock, flags);
-	tmp = readb(clps711x_pdir(chip)) & ~(1 << offset);
-	writeb(tmp, clps711x_pdir(chip));
-	spin_unlock_irqrestore(&gpio->lock, flags);
-
-	return 0;
-}
-
-static int gpio_clps711x_dir_out(struct gpio_chip *chip, unsigned offset,
-				 int value)
-{
-	int tmp;
-	unsigned long flags;
-	struct clps711x_gpio *gpio = dev_get_drvdata(chip->dev);
-
-	spin_lock_irqsave(&gpio->lock, flags);
-	tmp = readb(clps711x_pdir(chip)) | (1 << offset);
-	writeb(tmp, clps711x_pdir(chip));
-	tmp = readb(clps711x_port(chip)) & ~(1 << offset);
-	if (value)
-		tmp |= 1 << offset;
-	writeb(tmp, clps711x_port(chip));
-	spin_unlock_irqrestore(&gpio->lock, flags);
+	bgc = devm_kzalloc(&pdev->dev, sizeof(*bgc), GFP_KERNEL);
+	if (!bgc)
+		return -ENOMEM;
 
-	return 0;
-}
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	dat = devm_request_and_ioremap(&pdev->dev, res);
+	if (!dat)
+		return -ENXIO;
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+	dir = devm_request_and_ioremap(&pdev->dev, res);
+	if (!dir)
+		return -ENXIO;
+
+	switch (id) {
+	case 3:
+		/* PORTD is inverted logic for direction register */
+		err = bgpio_init(bgc, &pdev->dev, 1, dat, NULL, NULL,
+				 NULL, dir, 0);
+		break;
+	default:
+		err = bgpio_init(bgc, &pdev->dev, 1, dat, NULL, NULL,
+				 dir, NULL, 0);
+		break;
+	}
 
-static int gpio_clps711x_dir_in_inv(struct gpio_chip *chip, unsigned offset)
-{
-	int tmp;
-	unsigned long flags;
-	struct clps711x_gpio *gpio = dev_get_drvdata(chip->dev);
+	if (err)
+		return err;
+
+	switch (id) {
+	case 4:
+		/* PORTE is 3 lines only */
+		bgc->gc.ngpio = 3;
+		break;
+	default:
+		bgc->gc.ngpio = 8;
+		break;
+	}
 
-	spin_lock_irqsave(&gpio->lock, flags);
-	tmp = readb(clps711x_pdir(chip)) | (1 << offset);
-	writeb(tmp, clps711x_pdir(chip));
-	spin_unlock_irqrestore(&gpio->lock, flags);
+	bgc->gc.base = id * 8;
+	platform_set_drvdata(pdev, bgc);
 
-	return 0;
+	return gpiochip_add(&bgc->gc);
 }
 
-static int gpio_clps711x_dir_out_inv(struct gpio_chip *chip, unsigned offset,
-				     int value)
+static int clps711x_gpio_remove(struct platform_device *pdev)
 {
-	int tmp;
-	unsigned long flags;
-	struct clps711x_gpio *gpio = dev_get_drvdata(chip->dev);
-
-	spin_lock_irqsave(&gpio->lock, flags);
-	tmp = readb(clps711x_pdir(chip)) & ~(1 << offset);
-	writeb(tmp, clps711x_pdir(chip));
-	tmp = readb(clps711x_port(chip)) & ~(1 << offset);
-	if (value)
-		tmp |= 1 << offset;
-	writeb(tmp, clps711x_port(chip));
-	spin_unlock_irqrestore(&gpio->lock, flags);
+	struct bgpio_chip *bgc = platform_get_drvdata(pdev);
 
-	return 0;
+	return bgpio_remove(bgc);
 }
 
-static struct {
-	char	*name;
-	int	nr;
-	int	inv_dir;
-} clps711x_gpio_ports[] __initconst = {
-	{ "PORTA", 8, 0, },
-	{ "PORTB", 8, 0, },
-	{ "PORTC", 8, 0, },
-	{ "PORTD", 8, 1, },
-	{ "PORTE", 3, 0, },
+static struct platform_driver clps711x_gpio_driver = {
+	.driver	= {
+		.name	= "clps711x-gpio",
+		.owner	= THIS_MODULE,
+	},
+	.probe	= clps711x_gpio_probe,
+	.remove	= clps711x_gpio_remove,
 };
+module_platform_driver(clps711x_gpio_driver);
 
-static int __init gpio_clps711x_init(void)
-{
-	int i;
-	struct platform_device *pdev;
-	struct clps711x_gpio *gpio;
-
-	pdev = platform_device_alloc(CLPS711X_GPIO_NAME, 0);
-	if (!pdev) {
-		pr_err("Cannot create platform device: %s\n",
-		       CLPS711X_GPIO_NAME);
-		return -ENOMEM;
-	}
-
-	platform_device_add(pdev);
-
-	gpio = devm_kzalloc(&pdev->dev, sizeof(struct clps711x_gpio),
-			    GFP_KERNEL);
-	if (!gpio) {
-		dev_err(&pdev->dev, "GPIO allocating memory error\n");
-		platform_device_unregister(pdev);
-		return -ENOMEM;
-	}
-
-	platform_set_drvdata(pdev, gpio);
-
-	spin_lock_init(&gpio->lock);
-
-	for (i = 0; i < CLPS711X_GPIO_PORTS; i++) {
-		gpio->chip[i].owner		= THIS_MODULE;
-		gpio->chip[i].dev		= &pdev->dev;
-		gpio->chip[i].label		= clps711x_gpio_ports[i].name;
-		gpio->chip[i].base		= i * 8;
-		gpio->chip[i].ngpio		= clps711x_gpio_ports[i].nr;
-		gpio->chip[i].get		= gpio_clps711x_get;
-		gpio->chip[i].set		= gpio_clps711x_set;
-		if (!clps711x_gpio_ports[i].inv_dir) {
-			gpio->chip[i].direction_input = gpio_clps711x_dir_in;
-			gpio->chip[i].direction_output = gpio_clps711x_dir_out;
-		} else {
-			gpio->chip[i].direction_input = gpio_clps711x_dir_in_inv;
-			gpio->chip[i].direction_output = gpio_clps711x_dir_out_inv;
-		}
-		WARN_ON(gpiochip_add(&gpio->chip[i]));
-	}
-
-	dev_info(&pdev->dev, "GPIO driver initialized\n");
-
-	return 0;
-}
-arch_initcall(gpio_clps711x_init);
-
-MODULE_LICENSE("GPL v2");
+MODULE_LICENSE("GPL");
 MODULE_AUTHOR("Alexander Shiyan <shc_work at mail.ru>");
 MODULE_DESCRIPTION("CLPS711X GPIO driver");
-- 
1.8.1.5



From olof at lixom.net  Sat Apr 13 01:40:41 2013
From: olof at lixom.net (Olof Johansson)
Date: Fri, 12 Apr 2013 22:40:41 -0700
Subject: [PATCH] arm: vt8500: Add SDHC support to WM8505 DT
In-Reply-To: <1365706829-9626-1-git-send-email-linux@prisktech.co.nz>
References: <1365706829-9626-1-git-send-email-linux@prisktech.co.nz>
Message-ID: <20130413054041.GA12845@quad.lixom.net>

On Fri, Apr 12, 2013 at 07:00:29AM +1200, Tony Prisk wrote:
> This patch adds the required node for the SDHC controller on WM8505 SoCs.
> 
> Signed-off-by: Tony Prisk <linux at prisktech.co.nz>
> ---
> Arnd,
> 
> Any chance you can apply this for 3.10

Applied to next/dt


-Olof


From olof at lixom.net  Sat Apr 13 02:08:58 2013
From: olof at lixom.net (Olof Johansson)
Date: Fri, 12 Apr 2013 23:08:58 -0700
Subject: [GIT PULL v3] Reset controller API
In-Reply-To: <1365756131.5330.10.camel@pizza.hi.pengutronix.de>
References: <1365756131.5330.10.camel@pizza.hi.pengutronix.de>
Message-ID: <20130413060858.GC12845@quad.lixom.net>

On Fri, Apr 12, 2013 at 10:42:11AM +0200, Philipp Zabel wrote:
> Hi Olof,
> 
> the following changes since commit 8bb9660418e05bb1845ac1a2428444d78e322cc7:
> 
>   Linux 3.9-rc4 (2013-03-23 16:52:44 -0700)
> 
> are available in the git repository at:
> 
>   git://git.pengutronix.de/git/pza/linux.git reset/for_v3.10

Thanks, pulled in with next/drivers.


-Olof


From olof at lixom.net  Sat Apr 13 02:10:23 2013
From: olof at lixom.net (Olof Johansson)
Date: Fri, 12 Apr 2013 23:10:23 -0700
Subject: [GIT PULL v3] Reset controller API
In-Reply-To: <20130413060858.GC12845@quad.lixom.net>
References: <1365756131.5330.10.camel@pizza.hi.pengutronix.de>
 <20130413060858.GC12845@quad.lixom.net>
Message-ID: <CAOesGMii3o8Z_yrETnaz4NT_W92wY-Yzo-DUkCrhKy6Pah+Ckw@mail.gmail.com>

On Fri, Apr 12, 2013 at 11:08 PM, Olof Johansson <olof at lixom.net> wrote:
> On Fri, Apr 12, 2013 at 10:42:11AM +0200, Philipp Zabel wrote:
>> Hi Olof,
>>
>> the following changes since commit 8bb9660418e05bb1845ac1a2428444d78e322cc7:
>>
>>   Linux 3.9-rc4 (2013-03-23 16:52:44 -0700)
>>
>> are available in the git repository at:
>>
>>   git://git.pengutronix.de/git/pza/linux.git reset/for_v3.10
>
> Thanks, pulled in with next/drivers.


The branch itself is in arm-soc as reset/devel in case someone (Shawn)
needs to base development on it; please don't base it on the
next/drivers branch.


-Olof


From olof at lixom.net  Sat Apr 13 02:50:56 2013
From: olof at lixom.net (Olof Johansson)
Date: Fri, 12 Apr 2013 23:50:56 -0700
Subject: [GIT PULL] Timer clean-ups for 3.10, Part 2
In-Reply-To: <201304112257.07645.arnd@arndb.de>
References: <516720B4.3000703@gmail.com>
 <201304112257.07645.arnd@arndb.de>
Message-ID: <20130413065056.GB14735@quad.lixom.net>

On Thu, Apr 11, 2013 at 10:57:07PM +0200, Arnd Bergmann wrote:
> On Thursday 11 April 2013, Rob Herring wrote:
> > Olof, Arnd,
> > 
> > Please pull timer clean-ups for arch timer, sp804, and integrator-cp timers.
> > 
> > I've dropped the final patch which moved the sp804 and integrator timers
> > code to drivers/clocksource until the desired structure is worked out.
> > 
> > Simon, the fixes for shmobile were trivial. Please comment if you see
> > any issues.
> 
> Ok, nice!
> 
> There are various bits for which I'd like to see Russell's ACK before
> we send them Linuswards, but it all looks good to me.
> 
> I would put it into arm-soc tomorrow, and hopefully Haojian Zhuang is
> able to send an updated version of his hisilicon platform code based
> on top of this in time for the merge window. The patches are all
> reviewed but just waiting for the sp804 changes now, and since
> it's a new platform, I'm not worried about regressions.

I've pulled this in as a late/clksrc branch now, so that we keep it separate
from the other work in case Russell ends up having comments on it when he is
back online.

Also, I based the branch on samsung/mct and samsung/clk, since they had merge
conflicts. Kukjin, Rob, please confirm that I've resolved them properly.


-Olof


From olof at lixom.net  Sat Apr 13 02:56:53 2013
From: olof at lixom.net (Olof Johansson)
Date: Fri, 12 Apr 2013 23:56:53 -0700
Subject: [GIT PULL v2 3/4] ARM: imx: soc changes for 3.10
In-Reply-To: <20130412123220.GB16494@S2101-09.ap.freescale.net>
References: <20130412123220.GB16494@S2101-09.ap.freescale.net>
Message-ID: <20130413065653.GC14735@quad.lixom.net>

On Fri, Apr 12, 2013 at 08:32:22PM +0800, Shawn Guo wrote:
> Hi Arnd, Olof,
> 
> It merges imx-fixes-3.9-5, imx-cleanup-3.10 and "[GIT PULL v3] Reset
> controller API" as the base to resolve dependency and conflicts.
> 
> Changes since v1:
> * Rebase to Philipp Zabel's new pull request.
> * Merge imx-fixes-3.9-5 into the base to resolve one more conflict.
> 
> Shawn
> 
> The following changes since commit cb872cacb2ef57ade6bb0ff41e18b9508a0e073e:
> 
>   Merge remote-tracking branch 'pza/reset/for_v3.10' into imx/soc (2013-04-12 19:00:44 +0800)
> 
> are available in the git repository at:
> 
>   git://git.linaro.org/people/shawnguo/linux-2.6.git tags/imx-soc-3.10

Thanks. I've pulled this into next/soc2 since it depends on contents in
next/drivers.


-Olof


From olof at lixom.net  Sat Apr 13 03:09:05 2013
From: olof at lixom.net (Olof Johansson)
Date: Sat, 13 Apr 2013 00:09:05 -0700
Subject: [GIT PULL] [for 3.10] pull request from armsoc/dt branch in pxa
 git tree
In-Reply-To: <CAN1soZxcmHMABTGi6FBtXysmY0TwWx7cdEvf1_ycHv2RtCLcpw@mail.gmail.com>
References: <CAN1soZxcmHMABTGi6FBtXysmY0TwWx7cdEvf1_ycHv2RtCLcpw@mail.gmail.com>
Message-ID: <20130413070905.GA28595@quad.lixom.net>

Hi,

On Sat, Apr 13, 2013 at 12:13:14PM +0800, Haojian Zhuang wrote:
> Hi Arnd & Olof,
> 
> Please help to pull armsoc/dt branch from pxa git tree. These patches
> are used to enable hi3xxx SoC
> and they're depend on Rob's clock source patches.
> 
> Regards
> Haojian
> 
> The following changes since commit f6161aa153581da4a3867a2d1a7caf4be19b6ec9:
> 
>   Linux 3.9-rc2 (2013-03-10 16:54:19 -0700)
> 
> are available in the git repository at:
> 
>   git://github.com/hzhuang1/linux.git armsoc/dt

First of all, please try to move your repo somewhere else than github. We
really prefer to see signed tags when repos come from github or gitorious
or other similar sites. Maybe you can get a linaro git repo instead?

That's not a showstopper in this case though, since there's only a few
patches here and easy for us to review.

A couple of more important comments below.

> Haojian Zhuang (6):
>       devtree: add binding documentation for sp804
>       ARM: debug: support debug ll on hisilicon soc
>       clk: hi3xxx: add clock support

I didn't see an Acked-by from Mike Turquette on this one. Since this driver is
an addition to his subsystem, I would like to see one. It could even go through
his tree since this is all new platform code.

Not only that, but when I went searching for email to find reviews of this
patch, I see that Arnd had a round of comments including a request to move
hs_init_clocks() that, according to the email, was addressed but this patch
does not seem to have moved.

>       ARM: hi3xxx: add board support with device tree
>       ARM: hi3xxx: enable hi4511 with device tree
>       ARM: config: append arch hi3xxx into multi defconfig

Given the comments above, and the currently late time for 3.10, I think this
will be better held off for more review and a merge for 3.11. Please get the
above taken care of and resubmit to us as soon as 3.10-rc1 is out and we'll
stage it for 3.11. The code does look nice and clean and looks to be in good
shape, so there should be no problem to get it in for 3.10.


-Olof


From olof at lixom.net  Sat Apr 13 03:09:45 2013
From: olof at lixom.net (Olof Johansson)
Date: Sat, 13 Apr 2013 00:09:45 -0700
Subject: [GIT PULL] [for 3.10] pull request from armsoc/dt branch in pxa
 git tree
In-Reply-To: <20130413070905.GA28595@quad.lixom.net>
References: <CAN1soZxcmHMABTGi6FBtXysmY0TwWx7cdEvf1_ycHv2RtCLcpw@mail.gmail.com>
 <20130413070905.GA28595@quad.lixom.net>
Message-ID: <CAOesGMha8oQaZRLpOsxTt8xayNb28FWA2yFYy5uYxq5ZVc3G-w@mail.gmail.com>

Whoops:

> stage it for 3.11. The code does look nice and clean and looks to be in good
> shape, so there should be no problem to get it in for 3.10.

...to get it in for 3.11, I mean.


-Olof


From shc_work at mail.ru  Sat Apr 13 05:18:31 2013
From: shc_work at mail.ru (=?UTF-8?B?QWxleGFuZGVyIFNoaXlhbg==?=)
Date: Sat, 13 Apr 2013 13:18:31 +0400
Subject: =?UTF-8?B?UmVbMl06IFtQQVRDSF0gbW1jOiBteGNtbWM6IEZpeCBidWcgd2hlbiBjYXJk?=
 =?UTF-8?B?IGlzIHByZXNlbnQgZHVyaW5nIGJvb3Q=?=
In-Reply-To: <87bo9jfwgn.fsf@octavius.laptop.org>
References: <1365228811-10928-1-git-send-email-shc_work@mail.ru>
 <20130409073318.GF1906@pengutronix.de>
 <87bo9jfwgn.fsf@octavius.laptop.org>
Message-ID: <1365844711.170912126@f179.mail.ru>

> Hi,
> 
> On Tue, Apr 09 2013, Sascha Hauer wrote:
> > On Sat, Apr 06, 2013 at 10:13:31AM +0400, Alexander Shiyan wrote:
> >> This patch fixes bug when card is present during boot.
> >> Bug was introduced due commit "mmc: mxcmmc: fix bug that may block a
> >> data transfer forever". When a card is present "mxcmci_setup_data"
> >> function is executed, but the timer is not initialized.
> >
> > Acked-by: Sascha Hauer <s.hauer at pengutronix.de>
> 
> Thanks, pushed to mmc-next for 3.10.

OK. What about commit this patch in 3.8 stable?

---

From andrew at lunn.ch  Sat Apr 13 05:26:29 2013
From: andrew at lunn.ch (Andrew Lunn)
Date: Sat, 13 Apr 2013 11:26:29 +0200
Subject: [PATCHv2 08/10] arm: kirkwood: convert QNAP TS219 to use DT for
 the PCIe interface
In-Reply-To: <20130411165158.GA5865@obsidianresearch.com>
References: <1365632436-25367-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1365632436-25367-9-git-send-email-thomas.petazzoni@free-electrons.com>
 <20130411003301.GH28693@titan.lakedaemon.net>
 <20130411052432.GP13524@lunn.ch>
 <20130411165158.GA5865@obsidianresearch.com>
Message-ID: <20130413092629.GF2824@lunn.ch>

On Thu, Apr 11, 2013 at 10:51:58AM -0600, Jason Gunthorpe wrote:
> On Thu, Apr 11, 2013 at 07:24:32AM +0200, Andrew Lunn wrote:
>  
> > I've hacked around with PCI driver on my QNAP TS119P+, which does not
> > have any PCI devices, and never had any problems with the driver
> > enabled and finding two empty PCI busses. PCI does not share any pins
> > with anything else. So i think it is safe to just enable it for all
> > devices.
> 
> In the general case, this is probably only safe if the board has
> configured the PEX to have the PHY clock. Marvell has guidelines for
> unused PEX's that would result in the PHY clock being permanently
> inactive.
> 
> Register 10030 tells what the strap for the PHY clock is. I expect in
> many cases the PEX driver should not be loaded if the PHY clock is not
> internally derived. Maybe checking this register will tell your QNAPs
> apart?
 
Hi Jason

I did a bit of experimentation and reading of documents.

My QNAP, which has nothing on the PCI bus, has bit 14 of register
10030, the Sample At Reset, set. This indicates it should derive the
PCIe clock from the internal clock.

I also played with Topkick. It also has bit 14 set, and is quite happy
having the PCI driver loaded, even though there is nothing on the bus,
and USI website makes no reference to PCIe, so i don't think there is
an hardware support for PCIe devices.

The hardware manual says that this strapping pin has an internal
pullup, so it will default to one, internal clock.

So, to have a problem, it would mean the hardware designed has
deliberately pulled the strapping pin low to indicate external clock,
and not actually applied an external clock. Is this likely? Given my
QNAP board is not designed to have active PCIe, i kind of expect if
QNAP where to do such a thing, it would be so on my board....

So i'm tempted to go with Thomas's patch, once fixed, so enabling
loading of the PCI driver for all QNAP devices. If we get reports of
issues, we can then look at the specific hardware and decide what to
do.

	Andrew


From sylvester.nawrocki at gmail.com  Sat Apr 13 05:40:39 2013
From: sylvester.nawrocki at gmail.com (Sylwester Nawrocki)
Date: Sat, 13 Apr 2013 11:40:39 +0200
Subject: [PATCH] ARM: S3C24XX: add devicetree support for smdk2416
In-Reply-To: <201304130153.11653.heiko@sntech.de>
References: <201304130153.11653.heiko@sntech.de>
Message-ID: <51692817.7060501@gmail.com>

On 04/13/2013 01:53 AM, Heiko St?bner wrote:
> Definitions in s3c24xx.dtsi are usable for all s3c24xx SoCs, but some
> need to be extended with proper compatible properties, as can be seen
> in s3c2416.dtsi .
>
> Signed-off-by: Heiko Stuebner<heiko at sntech.de>

Well done, thanks!

Would be nice to see it in 3.10.

Reviewed-by: Sylwester Nawrocki <s.nawrocki at samsung.com>

> ---
> This patch depends on the not yet merged s3c24xx pinctrl support and
> the samsung-time muliplatform support.
>
>   arch/arm/boot/dts/Makefile              |    1 +
>   arch/arm/boot/dts/s3c2416-pinctrl.dtsi  |  173 +++++++++++++++++++++++++++++++
>   arch/arm/boot/dts/s3c2416-smdk2416.dts  |   72 +++++++++++++
>   arch/arm/boot/dts/s3c2416.dtsi          |   79 ++++++++++++++
>   arch/arm/boot/dts/s3c24xx.dtsi          |   92 ++++++++++++++++
>   arch/arm/mach-s3c24xx/Kconfig           |   12 ++
>   arch/arm/mach-s3c24xx/Makefile          |    1 +
>   arch/arm/mach-s3c24xx/mach-s3c2416-dt.c |   91 ++++++++++++++++
>   8 files changed, 521 insertions(+), 0 deletions(-)
>   create mode 100644 arch/arm/boot/dts/s3c2416-pinctrl.dtsi
>   create mode 100644 arch/arm/boot/dts/s3c2416-smdk2416.dts
>   create mode 100644 arch/arm/boot/dts/s3c2416.dtsi
>   create mode 100644 arch/arm/boot/dts/s3c24xx.dtsi
>   create mode 100644 arch/arm/mach-s3c24xx/mach-s3c2416-dt.c


From thierry.reding at avionic-design.de  Sat Apr 13 06:23:19 2013
From: thierry.reding at avionic-design.de (Thierry Reding)
Date: Sat, 13 Apr 2013 12:23:19 +0200
Subject: [PATCH 1/3] ARM: tegra: pcie: Add tegra3 support
In-Reply-To: <51682975.1080302@wwwdotorg.org>
References: <1365435688-4179-1-git-send-email-jagarwal@nvidia.com>
 <51630852.1000107@wwwdotorg.org>
 <C79B248886DD134989C8FF6B096A91AB91B36FB2FD@BGMAIL01.nvidia.com>
 <51682975.1080302@wwwdotorg.org>
Message-ID: <20130413102319.GA30758@avionic-0098.mockup.avionic-design.de>

On Fri, Apr 12, 2013 at 09:34:13AM -0600, Stephen Warren wrote:
> On 04/12/2013 08:58 AM, Jay Agarwal wrote:
> >>>  	err = regulator_disable(pcie->pex_clk_supply);
> >>>  	if (err < 0)
> >>> -		dev_err(pcie->dev, "failed to disable pex-clk regulator:
> >> %d\n",
> >>> +		dev_warn(pcie->dev, "failed to disable pex-clk regulator:
> >> %d\n",
> >>>  			err);
> >>>
> >>>  	err = regulator_disable(pcie->vdd_supply);
> >>>  	if (err < 0)
> >>> -		dev_err(pcie->dev, "failed to disable VDD regulator: %d\n",
> >>> +		dev_warn(pcie->dev, "failed to disable VDD regulator:
> >> %d\n",
> >>>  			err);
> >>
> >> Please explain why that change is correct. If the regulators only exist on
> >> Tegra20, please represent that fact in the SoC data. Regulators must always
> >> exist, so enable/disable should never fail due to missing regulators. Actual
> >> run-time failures seem like something that really is an error.
> >>
> > [>] These regulators are needed for both tegra20 & tegra30. Since we are not returning error here, so changed to dev_warn.
> 
> If the regulators are required, then any failure to operate them should
> be an error, hence dev_err() seems correct.
> 
> As to why the code doesn't actually return an error? I'm not sure.
> Perhaps that should be fixed with a separate patch, although I don't
> recall exactly where in the code the above excerpt is; if it's in
> remove(), then continuing on without returning an error would be
> appropriate.

That code is from tegra_pcie_power_off(), which is called only during
error cleanup or from tegra_pcie_put_resources() which in turn is also
only called in cleanup paths or during module/device removal. Disabling
as many regulators as possible is still what we want in that case, so
returning an error prematurely might leave more regulators turned on
than necessary.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130413/8453eb72/attachment.sig>

From thierry.reding at avionic-design.de  Sat Apr 13 06:29:29 2013
From: thierry.reding at avionic-design.de (Thierry Reding)
Date: Sat, 13 Apr 2013 12:29:29 +0200
Subject: [PATCH v3] ARM: pci: create pci_common_init_dev()
In-Reply-To: <1365788748-7908-1-git-send-email-linus.walleij@linaro.org>
References: <1365788748-7908-1-git-send-email-linus.walleij@linaro.org>
Message-ID: <20130413102929.GB30758@avionic-0098.mockup.avionic-design.de>

On Fri, Apr 12, 2013 at 07:45:48PM +0200, Linus Walleij wrote:
[...]
> +static inline void pci_common_init(struct hw_pci *hw) {

I think that the CodingStyle rule for putting the opening brace on a
line by itself also applies to inline functions.

Aside from that nit:

Reviewed-by: Thierry Reding <thierry.reding at avionic-design.de>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130413/9b8b3779/attachment.sig>

From andrew at lunn.ch  Sat Apr 13 06:30:57 2013
From: andrew at lunn.ch (Andrew Lunn)
Date: Sat, 13 Apr 2013 12:30:57 +0200
Subject: [PATCHv2 04/10] arm: kirkwood: add SoC-level Device Tree data
 for PCIe interfaces
In-Reply-To: <1365632436-25367-5-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1365632436-25367-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1365632436-25367-5-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <20130413103057.GG2824@lunn.ch>

On Thu, Apr 11, 2013 at 12:20:30AM +0200, Thomas Petazzoni wrote:
> This commit adds Device Tree details to enable the PCIe interfaces on
> Kirkwood. The 6281 has one PCIe interface, the 6282 has two PCIe
> interfaces.
> 
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> ---
>  arch/arm/boot/dts/kirkwood-6281.dtsi |   31 ++++++++++++++++++++++
>  arch/arm/boot/dts/kirkwood-6282.dtsi |   48 ++++++++++++++++++++++++++++++++++
>  arch/arm/boot/dts/kirkwood.dtsi      |    1 +
>  3 files changed, 80 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/kirkwood-6281.dtsi b/arch/arm/boot/dts/kirkwood-6281.dtsi
> index d6c9d65..5137668 100644
> --- a/arch/arm/boot/dts/kirkwood-6281.dtsi
> +++ b/arch/arm/boot/dts/kirkwood-6281.dtsi
> @@ -40,5 +40,36 @@
>  				marvell,function = "sdio";
>  			};
>  		};
> +
> +		pcie-controller {

Hi Thomas

Convention seems to be to use _ not - in these names.

	   Andrew


From andrew at lunn.ch  Sat Apr 13 06:36:50 2013
From: andrew at lunn.ch (Andrew Lunn)
Date: Sat, 13 Apr 2013 12:36:50 +0200
Subject: [PATCHv2 08/10] arm: kirkwood: convert QNAP TS219 to use DT for
 the PCIe interface
In-Reply-To: <20130411193349.GA5061@lunn.ch>
References: <1365632436-25367-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1365632436-25367-9-git-send-email-thomas.petazzoni@free-electrons.com>
 <20130411193349.GA5061@lunn.ch>
Message-ID: <20130413103650.GH2824@lunn.ch>

On Thu, Apr 11, 2013 at 09:33:49PM +0200, Andrew Lunn wrote:
> On Thu, Apr 11, 2013 at 12:20:34AM +0200, Thomas Petazzoni wrote:
> > Now that the PCIe mvebu driver is usable on Kirkwood, use it instead
> > of the legacy PCIe code, since it allows to describe the PCIe
> > interfaces in the Device Tree.
> > 
> > Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> > ---
> >  arch/arm/boot/dts/kirkwood-ts219.dtsi |    7 +++++++
> >  arch/arm/mach-kirkwood/board-ts219.c  |   10 ----------
> >  2 files changed, 7 insertions(+), 10 deletions(-)
> > 
> > diff --git a/arch/arm/boot/dts/kirkwood-ts219.dtsi b/arch/arm/boot/dts/kirkwood-ts219.dtsi
> > index 64ea27c..341e1d8 100644
> > --- a/arch/arm/boot/dts/kirkwood-ts219.dtsi
> > +++ b/arch/arm/boot/dts/kirkwood-ts219.dtsi
> > @@ -74,5 +74,12 @@
> >  			status = "okay";
> >  			nr-ports = <2>;
> >  		};
> > +		pcie-controller {
> > +			status = "okay";
> > +
> > +			pcie at 1,0 {
> > +				status = "okay";
> > +			};
> > +		};
> >  	};
> >  };
> 
> Hi Thomas
> 
> There is some DT weirdness going on here. With that you have above,
> the .dtb file has both status="disabled" when i convert it back to dts
> format.
> 
> In order to get it to work, i had to move this fragment into the
> kirkwood-ts219-628[12].dtsi files.
> 
> Can some dtc guru comment if this is supposed to work with the
> arrangement of includes we have?

Hi Thomas

I got my head around what is happening here.

When the dtc merges nodes, it replaces an old property value with the
new proper value. For this "okay" above to work, is has to be the new
property. When in fact, due to the order of the include files, it was
actually the old property value. It was reading kirkwood-ts219.dtsi
first, and then later merging in kirkwood-6282.dtsi, replacing the
status okay with status disabled :-(

I will send an updated version soon.

  Andrew


From thomas.petazzoni at free-electrons.com  Sat Apr 13 06:40:55 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Sat, 13 Apr 2013 12:40:55 +0200
Subject: [PATCHv2 08/10] arm: kirkwood: convert QNAP TS219 to use DT for
 the PCIe interface
In-Reply-To: <20130413092629.GF2824@lunn.ch>
References: <1365632436-25367-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1365632436-25367-9-git-send-email-thomas.petazzoni@free-electrons.com>
 <20130411003301.GH28693@titan.lakedaemon.net>
 <20130411052432.GP13524@lunn.ch>
 <20130411165158.GA5865@obsidianresearch.com>
 <20130413092629.GF2824@lunn.ch>
Message-ID: <20130413124055.1f8aeeac@skate>

Dear Andrew Lunn,

On Sat, 13 Apr 2013 11:26:29 +0200, Andrew Lunn wrote:

> So i'm tempted to go with Thomas's patch, once fixed, so enabling
> loading of the PCI driver for all QNAP devices. If we get reports of
> issues, we can then look at the specific hardware and decide what to
> do.

So to conclude, which fix should I apply to my patch set?

Thanks a lot for all your investigations!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From sylvester.nawrocki at gmail.com  Sat Apr 13 06:57:19 2013
From: sylvester.nawrocki at gmail.com (Sylwester Nawrocki)
Date: Sat, 13 Apr 2013 12:57:19 +0200
Subject: [PATCH v3] pinctrl: Add pinctrl-s3c24xx driver
In-Reply-To: <201304111409.01983.heiko@sntech.de>
References: <201304111409.01983.heiko@sntech.de>
Message-ID: <51693A0F.30709@gmail.com>

On 04/11/2013 02:09 PM, Heiko St?bner wrote:
> The s3c24xx pins follow a similar pattern as the other Samsung SoCs and
> can therefore reuse the already introduced infrastructure.
>
> The s3c24xx SoCs have one design oddity in that the first 4 external
> interrupts do not reside in the eint pending register but in the main
> interrupt controller instead. We solve this by forwarding the external
> interrupt from the main controller into the irq domain of the pin bank.
> The masking/acking of these interrupts is handled in the same way.
>
> Furthermore the S3C2412/2413 SoCs contain another oddity in that they
> keep the same 4 eints in the main interrupt controller and eintpend
> register and requiring ack operations to happen in both. This is solved
> by using different compatible properties for the wakeup eint node which
> set a property accordingly.
>
> Signed-off-by: Heiko Stuebner<heiko at sntech.de>

Reviewed-by: Sylwester Nawrocki <s.nawrocki at samsung.com>

Just couple nitpicks below...

> ---
> changes since v2:
> - address more comments from Tomasz Figa:
>    * remove obsolete ctrl_type references
>    * remove redundant check for parent_chip
>    * update docs and commit message
>
> changes since v1:
> - address comments from Tomasz Figa:
>    * split handling functions for eints 0-3 for s3c2412 and all others
>    * change the handling for s3c2412 eints 0-3 in that they now use
>      chained_irq_* for the outer parent interrupt
>
>   .../bindings/pinctrl/samsung-pinctrl.txt           |    8 +
>   drivers/gpio/gpio-samsung.c                        |    4 +
>   drivers/pinctrl/Kconfig                            |    5 +
>   drivers/pinctrl/Makefile                           |    1 +
>   drivers/pinctrl/pinctrl-s3c24xx.c                  |  664 ++++++++++++++++++++
>   drivers/pinctrl/pinctrl-samsung.c                  |   10 +
>   drivers/pinctrl/pinctrl-samsung.h                  |    4 +
>   7 files changed, 696 insertions(+), 0 deletions(-)
>   create mode 100644 drivers/pinctrl/pinctrl-s3c24xx.c
>
> diff --git a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
> index c70fca1..e4443e3 100644
> --- a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
> +++ b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
> @@ -7,6 +7,10 @@ on-chip controllers onto these pads.
>
>   Required Properties:
>   - compatible: should be one of the following.
> +  - "samsung,s3c2413-pinctrl": for S3C64xx-compatible pin-controller,
> +  - "samsung,s3c2416-pinctrl": for S3C64xx-compatible pin-controller,
> +  - "samsung,s3c2440-pinctrl": for S3C64xx-compatible pin-controller,
> +  - "samsung,s3c2450-pinctrl": for S3C64xx-compatible pin-controller,

Shouldn't "S3C64xx" be changed to match each SoC name ?

>     - "samsung,s3c64xx-pinctrl": for S3C64xx-compatible pin-controller,
>     - "samsung,exynos4210-pinctrl": for Exynos4210 compatible pin-controller.
>     - "samsung,exynos4x12-pinctrl": for Exynos4x12 compatible pin-controller.
> @@ -106,6 +110,10 @@ B. External Wakeup Interrupts: For supporting external wakeup interrupts, a
>
>      - compatible: identifies the type of the external wakeup interrupt controller
>        The possible values are:
> +     - samsung,s3c2410-wakeup-eint: represents wakeup interrupt controller
> +       found on Samsung S3C24xx SoCs except S3C2412 and S3C2413,
> +     - samsung,s3c2412-wakeup-eint: represents wakeup interrupt controller
> +       found on Samsung S3C2412 and S3C2413 SoCs,
>        - samsung,s3c64xx-wakeup-eint: represents wakeup interrupt controller
>          found on Samsung S3C64xx SoCs,
>        - samsung,exynos4210-wakeup-eint: represents wakeup interrupt controller
> diff --git a/drivers/gpio/gpio-samsung.c b/drivers/gpio/gpio-samsung.c
> index dc06a6f..73017b9 100644
> --- a/drivers/gpio/gpio-samsung.c
> +++ b/drivers/gpio/gpio-samsung.c
> @@ -3026,6 +3026,10 @@ static __init int samsung_gpiolib_init(void)
>   	*/
>   	struct device_node *pctrl_np;
>   	static const struct of_device_id exynos_pinctrl_ids[] = {
> +		{ .compatible = "samsung,s3c2413-pinctrl", },
> +		{ .compatible = "samsung,s3c2416-pinctrl", },
> +		{ .compatible = "samsung,s3c2440-pinctrl", },
> +		{ .compatible = "samsung,s3c2450-pinctrl", },
>   		{ .compatible = "samsung,s3c64xx-pinctrl", },
>   		{ .compatible = "samsung,exynos4210-pinctrl", },
>   		{ .compatible = "samsung,exynos4x12-pinctrl", },
> diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
> index 7402ac9..58d73ac 100644
> --- a/drivers/pinctrl/Kconfig
> +++ b/drivers/pinctrl/Kconfig
> @@ -226,6 +226,11 @@ config PINCTRL_EXYNOS5440
>   	select PINMUX
>   	select PINCONF
>
> +config PINCTRL_S3C24XX
> +	bool "Samsung S3C24XX SoC pinctrl driver"
> +	depends on ARCH_S3C24XX
> +	select PINCTRL_SAMSUNG
> +
>   config PINCTRL_S3C64XX
>   	bool "Samsung S3C64XX SoC pinctrl driver"
>   	depends on ARCH_S3C64XX
> diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
> index 21d34c2..1ccdfd8 100644
> --- a/drivers/pinctrl/Makefile
> +++ b/drivers/pinctrl/Makefile
> @@ -45,6 +45,7 @@ obj-$(CONFIG_PINCTRL_COH901)	+= pinctrl-coh901.o
>   obj-$(CONFIG_PINCTRL_SAMSUNG)	+= pinctrl-samsung.o
>   obj-$(CONFIG_PINCTRL_EXYNOS)	+= pinctrl-exynos.o
>   obj-$(CONFIG_PINCTRL_EXYNOS5440)	+= pinctrl-exynos5440.o
> +obj-$(CONFIG_PINCTRL_S3C24XX)	+= pinctrl-s3c24xx.o
>   obj-$(CONFIG_PINCTRL_S3C64XX)	+= pinctrl-s3c64xx.o
>   obj-$(CONFIG_PINCTRL_XWAY)	+= pinctrl-xway.o
>   obj-$(CONFIG_PINCTRL_LANTIQ)	+= pinctrl-lantiq.o
> diff --git a/drivers/pinctrl/pinctrl-s3c24xx.c b/drivers/pinctrl/pinctrl-s3c24xx.c
> new file mode 100644
> index 0000000..4b03c8f
> --- /dev/null
> +++ b/drivers/pinctrl/pinctrl-s3c24xx.c
> @@ -0,0 +1,664 @@
> +/*
> + * S3C24XX specific support for Samsung pinctrl/gpiolib driver.
> + *
> + * Copyright (c) 2013 Heiko Stuebner<heiko at sntech.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.
> + *
> + * This file contains the SamsungS3C24XX specific information required by the
> + * the Samsung pinctrl/gpiolib driver. It also includes the implementation of

s/the Samsung/Samsung

> + * external gpio and wakeup interrupt support.
> + */
> +
[...]
> +/**
> + * struct s3c24xx_eint_domain_data: per irq-domain data
> + * @bank

Missing description.

> + * @eint_data: common data
> + * eint0_3_parent_only: live eints 0-3 only in the main intc
> + */
> +struct s3c24xx_eint_domain_data {
> +	struct samsung_pin_bank *bank;
> +	struct s3c24xx_eint_data *eint_data;
> +	bool eint0_3_parent_only;
> +};
> +
> +static int s3c24xx_eint_get_trigger(unsigned int type)
> +{
> +	int trigger;
> +
> +	switch (type) {
> +	case IRQ_TYPE_EDGE_RISING:
> +		trigger = EINT_EDGE_RISING;
> +		break;
> +	case IRQ_TYPE_EDGE_FALLING:
> +		trigger = EINT_EDGE_FALLING;
> +		break;
> +	case IRQ_TYPE_EDGE_BOTH:
> +		trigger = EINT_EDGE_BOTH;
> +		break;
> +	case IRQ_TYPE_LEVEL_HIGH:
> +		trigger = EINT_LEVEL_HIGH;
> +		break;
> +	case IRQ_TYPE_LEVEL_LOW:
> +		trigger = EINT_LEVEL_LOW;
> +		break;

EINT_* could be directly returned above, and the local variable is not
needed then. That's presumably just a matter of personal preference though.

> +	default:
> +		return -EINVAL;
> +	}
> +
> +	return trigger;
> +}

> +static int s3c24xx_eint_type(struct irq_data *data, unsigned int type)
> +{
> +	struct samsung_pin_bank *bank = irq_data_get_irq_chip_data(data);
> +	struct samsung_pinctrl_drv_data *d = bank->drvdata;
> +	int index = bank->eint_offset + data->hwirq;
> +	void __iomem *reg;
> +	int trigger;
> +	u8 shift;
> +	u32 val;
> +
> +	trigger = s3c24xx_eint_get_trigger(type);
> +	if (trigger<  0) {
> +		dev_err(d->dev, "unsupported external interrupt type\n");
> +		return -EINVAL;
> +	}
> +
> +	s3c24xx_eint_set_handler(data->irq, type);
> +
> +	/* Set up interrupt trigger */
> +	reg = d->virt_base + EINT_REG(index);
> +	shift = EINT_OFFS(index);
> +
> +	val = readl(reg);
> +	val&= ~(EINT_MASK<<  shift);
> +	val |= trigger<<  shift;
> +	writel(val, reg);
> +
> +	s3c24xx_eint_set_function(d, bank, data->hwirq);
> +
> +	return 0;
> +}
> +
> +/* handling of EINTs 0-3 on all except S3C2412 and S3C2413 */

s/handling/Handling ?

> +
> +static void s3c2410_eint0_3_ack(struct irq_data *data)
> +{
> +	struct samsung_pin_bank *bank = irq_data_get_irq_chip_data(data);
> +	struct s3c24xx_eint_domain_data *ddata = bank->irq_domain->host_data;
> +	struct s3c24xx_eint_data *eint_data = ddata->eint_data;
> +	int parent_irq = eint_data->parents[data->hwirq];
> +	struct irq_chip *parent_chip = irq_get_chip(parent_irq);
> +
> +	parent_chip->irq_ack(irq_get_irq_data(parent_irq));
> +}
> +
> +static void s3c2410_eint0_3_mask(struct irq_data *data)
> +{
> +	struct samsung_pin_bank *bank = irq_data_get_irq_chip_data(data);
> +	struct s3c24xx_eint_domain_data *ddata = bank->irq_domain->host_data;
> +	struct s3c24xx_eint_data *eint_data = ddata->eint_data;
> +	int parent_irq = eint_data->parents[data->hwirq];
> +	struct irq_chip *parent_chip = irq_get_chip(parent_irq);
> +
> +	parent_chip->irq_mask(irq_get_irq_data(parent_irq));
> +}
> +
> +static void s3c2410_eint0_3_unmask(struct irq_data *data)
> +{
> +	struct samsung_pin_bank *bank = irq_data_get_irq_chip_data(data);
> +	struct s3c24xx_eint_domain_data *ddata = bank->irq_domain->host_data;
> +	struct s3c24xx_eint_data *eint_data = ddata->eint_data;
> +	int parent_irq = eint_data->parents[data->hwirq];
> +	struct irq_chip *parent_chip = irq_get_chip(parent_irq);
> +
> +	parent_chip->irq_unmask(irq_get_irq_data(parent_irq));
> +}
> +
> +static struct irq_chip s3c2410_eint0_3_chip = {
> +	.name		= "s3c2410-eint0_3",
> +	.irq_ack	= s3c2410_eint0_3_ack,
> +	.irq_mask	= s3c2410_eint0_3_mask,
> +	.irq_unmask	= s3c2410_eint0_3_unmask,
> +	.irq_set_type	= s3c24xx_eint_type,
> +};
> +
> +static void s3c2410_demux_eint0_3(unsigned int irq, struct irq_desc *desc)
> +{
> +	struct irq_data *data = irq_desc_get_irq_data(desc);
> +	struct s3c24xx_eint_data *eint_data = irq_get_handler_data(irq);
> +	unsigned int virq;
> +
> +	/* the first 4 eints have a simple 1 to 1 mapping */
> +	virq = irq_linear_revmap(eint_data->domains[data->hwirq], data->hwirq);
> +	/* Something must be really wrong if an unmapped EINT
> +	 * was unmasked...
> +	 */

Not a proper multi line comment style.

> +	BUG_ON(!virq);
> +
> +	generic_handle_irq(virq);
> +}
> +
> +/* handling of EINTs 0-3 on S3C2412 and S3C2413 */

s/handling/Handling ?

> +static void s3c2412_demux_eint0_3(unsigned int irq, struct irq_desc *desc)
> +{
> +	struct irq_chip *chip = irq_get_chip(irq);
> +	struct irq_data *data = irq_desc_get_irq_data(desc);
> +	struct s3c24xx_eint_data *eint_data = irq_get_handler_data(irq);
> +	unsigned int virq;
> +
> +	chained_irq_enter(chip, desc);
> +
> +	/* the first 4 eints have a simple 1 to 1 mapping */
> +	virq = irq_linear_revmap(eint_data->domains[data->hwirq], data->hwirq);
> +	/* Something must be really wrong if an unmapped EINT
> +	 * was unmasked...
> +	 */
> +	BUG_ON(!virq);
> +
> +	generic_handle_irq(virq);
> +
> +	chained_irq_exit(chip, desc);
> +}
> +
> +/* handling of all other eints */

s/handling/Handling ?

> +static inline void s3c24xx_demux_eint(unsigned int irq, struct irq_desc *desc,
> +				      u32 offset, u32 range)
> +{
> +	struct irq_chip *chip = irq_get_chip(irq);
> +	struct s3c24xx_eint_data *data = irq_get_handler_data(irq);
> +	struct samsung_pinctrl_drv_data *d = data->drvdata;
> +	unsigned int pend, mask;
> +
> +	chained_irq_enter(chip, desc);
> +
> +	pend = readl(d->virt_base + EINTPEND_REG);
> +	mask = readl(d->virt_base + EINTMASK_REG);
> +
> +	pend&= ~mask;
> +	pend&= range;
> +
> +	while (pend) {
> +		unsigned int virq;
> +
> +		irq = __ffs(pend);
> +		pend&= ~(1<<  irq);
> +		virq = irq_linear_revmap(data->domains[irq], irq - offset);
> +		/* Something must be really wrong if an unmapped EINT
> +		 * was unmasked...
> +		 */
> +		BUG_ON(!virq);
> +
> +		generic_handle_irq(virq);
> +	}
> +
> +	chained_irq_exit(chip, desc);
> +}

> +static int s3c24xx_eint_init(struct samsung_pinctrl_drv_data *d)
> +{
> +	struct device *dev = d->dev;
> +	const struct of_device_id *match;
> +	struct device_node *eint_np = NULL;
> +	struct device_node *np;
> +	struct samsung_pin_bank *bank;
> +	struct s3c24xx_eint_data *eint_data;
> +	const struct irq_domain_ops *ops;
> +	unsigned int i;
> +	bool eint0_3_parent_only;
> +	irq_flow_handler_t *handlers;
> +
> +	for_each_child_of_node(dev->of_node, np) {
> +		match = of_match_node(s3c24xx_eint_irq_ids, np);
> +		if (match) {
> +			eint_np = np;
> +			eint0_3_parent_only = (bool)match->data;
> +			break;
> +		}
> +	}
> +	if (!eint_np)
> +		return -ENODEV;
> +
> +	eint_data = devm_kzalloc(dev, sizeof(*eint_data), GFP_KERNEL);
> +	if (!eint_data) {
> +		dev_err(dev, "could not allocate memory for wkup eint data\n");

k*alloc functions already log any errors, you could just return -ENOMEM,
without printing anything.

> +		return -ENOMEM;
> +	}
> +	eint_data->drvdata = d;
> +
> +	handlers = eint0_3_parent_only ? s3c2410_eint_handlers
> +				       : s3c2412_eint_handlers;
> +	for (i = 0; i<  NUM_EINT_IRQ; ++i) {
> +		unsigned int irq;
> +
> +		irq = irq_of_parse_and_map(eint_np, i);
> +		if (!irq) {
> +			dev_err(dev, "failed to get wakeup EINT IRQ %d\n", i);
> +			return -ENXIO;
> +		}
> +
> +		eint_data->parents[i] = irq;
> +		irq_set_chained_handler(irq, handlers[i]);
> +		irq_set_handler_data(irq, eint_data);
> +	}
> +
> +	bank = d->ctrl->pin_banks;
> +	for (i = 0; i<  d->ctrl->nr_banks; ++i, ++bank) {
> +		struct s3c24xx_eint_domain_data *ddata;
> +		unsigned int mask;
> +		unsigned int irq;
> +		unsigned int pin;
> +
> +		if (bank->eint_type != EINT_TYPE_WKUP)
> +			continue;
> +
> +		ddata = devm_kzalloc(dev, sizeof(*ddata), GFP_KERNEL);
> +		if (!ddata) {
> +			dev_err(dev, "failed to allocate domain data\n");

Ditto.

> +			return -ENOMEM;
> +		}
> +		ddata->bank = bank;
> +		ddata->eint_data = eint_data;
> +		ddata->eint0_3_parent_only = eint0_3_parent_only;
> +
> +		ops = (bank->eint_offset == 0) ?&s3c24xx_gpf_irq_ops
> +					       :&s3c24xx_gpg_irq_ops;
> +
> +		bank->irq_domain = irq_domain_add_linear(bank->of_node,
> +				bank->nr_pins, ops, ddata);
> +		if (!bank->irq_domain) {
> +			dev_err(dev, "wkup irq domain add failed\n");
> +			return -ENXIO;
> +		}
> +
> +		irq = bank->eint_offset;
> +		mask = bank->eint_mask;
> +		for (pin = 0; mask; ++pin, mask>>= 1) {
> +			if (irq>  NUM_EINT)
> +				break;
> +			if (!(mask&  1))
> +				continue;
> +			eint_data->domains[irq] = bank->irq_domain;
> +			++irq;
> +		}
> +	}
> +
> +	return 0;
> +}

Regards,
Sylwester


From andrew at lunn.ch  Sat Apr 13 07:03:56 2013
From: andrew at lunn.ch (Andrew Lunn)
Date: Sat, 13 Apr 2013 13:03:56 +0200
Subject: [PATCH] arm: kirkwood: convert QNAP TS219 to use DT for the PCIe
 interface
In-Reply-To: <1365632436-25367-9-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1365632436-25367-9-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1365851036-27363-1-git-send-email-andrew@lunn.ch>

From: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>

Now that the PCIe mvebu driver is usable on Kirkwood, use it instead
of the legacy PCIe code, since it allows to describe the PCIe
interfaces in the Device Tree.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Signed-off-by: Andrew Lunn <andrew at lunn.ch>
---
 arch/arm/boot/dts/kirkwood-ts219-6281.dts |    3 ++-
 arch/arm/boot/dts/kirkwood-ts219-6282.dts |    3 ++-
 arch/arm/boot/dts/kirkwood-ts219.dtsi     |    9 +++++++--
 arch/arm/mach-kirkwood/board-ts219.c      |   10 ----------
 4 files changed, 11 insertions(+), 14 deletions(-)

diff --git a/arch/arm/boot/dts/kirkwood-ts219-6281.dts b/arch/arm/boot/dts/kirkwood-ts219-6281.dts
index 8295c83..42648ab 100644
--- a/arch/arm/boot/dts/kirkwood-ts219-6281.dts
+++ b/arch/arm/boot/dts/kirkwood-ts219-6281.dts
@@ -1,7 +1,8 @@
 /dts-v1/;
 
-/include/ "kirkwood-ts219.dtsi"
+/include/ "kirkwood.dtsi"
 /include/ "kirkwood-6281.dtsi"
+/include/ "kirkwood-ts219.dtsi"
 
 / {
 	ocp at f1000000 {
diff --git a/arch/arm/boot/dts/kirkwood-ts219-6282.dts b/arch/arm/boot/dts/kirkwood-ts219-6282.dts
index df3f95d..95ceeb9 100644
--- a/arch/arm/boot/dts/kirkwood-ts219-6282.dts
+++ b/arch/arm/boot/dts/kirkwood-ts219-6282.dts
@@ -1,7 +1,8 @@
 /dts-v1/;
 
-/include/ "kirkwood-ts219.dtsi"
+/include/ "kirkwood.dtsi"
 /include/ "kirkwood-6282.dtsi"
+/include/ "kirkwood-ts219.dtsi"
 
 / {
 	ocp at f1000000 {
diff --git a/arch/arm/boot/dts/kirkwood-ts219.dtsi b/arch/arm/boot/dts/kirkwood-ts219.dtsi
index 64ea27c..7c022fd 100644
--- a/arch/arm/boot/dts/kirkwood-ts219.dtsi
+++ b/arch/arm/boot/dts/kirkwood-ts219.dtsi
@@ -1,5 +1,3 @@
-/include/ "kirkwood.dtsi"
-
 / {
 	model = "QNAP TS219 family";
 	compatible = "qnap,ts219", "marvell,kirkwood";
@@ -74,5 +72,12 @@
 			status = "okay";
 			nr-ports = <2>;
 		};
+		pcie-controller {
+			status = "okay";
+
+			pcie at 1,0 {
+				status = "okay";
+			};
+		};
 	};
 };
diff --git a/arch/arm/mach-kirkwood/board-ts219.c b/arch/arm/mach-kirkwood/board-ts219.c
index acb0187..4695d5f 100644
--- a/arch/arm/mach-kirkwood/board-ts219.c
+++ b/arch/arm/mach-kirkwood/board-ts219.c
@@ -41,13 +41,3 @@ void __init qnap_dt_ts219_init(void)
 
 	pm_power_off = qnap_tsx1x_power_off;
 }
-
-/* FIXME: Will not work with DT. Maybe use MPP40_GPIO? */
-static int __init ts219_pci_init(void)
-{
-	if (machine_is_ts219())
-		kirkwood_pcie_init(KW_PCIE0);
-
-	return 0;
-}
-subsys_initcall(ts219_pci_init);
-- 
1.7.10.4



From tomasz.figa at gmail.com  Sat Apr 13 08:28:18 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Sat, 13 Apr 2013 14:28:18 +0200
Subject: [PATCH v5 00/14] ARM: samsung-time: Prepare for multiplatform
 support
In-Reply-To: <1365794250-14436-1-git-send-email-t.figa@samsung.com>
References: <1365794250-14436-1-git-send-email-t.figa@samsung.com>
Message-ID: <14380521.emfIF6y4Om@flatron>

On Friday 12 of April 2013 21:17:16 Tomasz Figa wrote:
> This series is an attempt to make the samsung-time clocksource driver
> ready for multiplatform kernels. It moves the driver to
> drivers/clocksource, cleans it up from uses of static platform-specific
> definitions, simplifies timer interrupt handling and adds Device Tree
> support.
> 
> The samsung_pwm clocksource driver is made the master driver, which
> exposes a single function to the PWM driver to get required data. Only
> samsung-time driver is reworked to use the master driver at this time,
> since the PWM driver can be already considered broken at the moment and
> needs separate series of several patches to fix and clean it up, which
> I am already working on.
> 
> Tested on Universal C210 board with Device Tree. Not tested without
> Device Tree, since it has been already broken before this series.
> Compile tested for other related SoCs.
> 
> Changes since v4:
> (http://thread.gmane.org/gmane.linux.kernel.samsung-soc/17464)
>  - Changed the design again - now clocksource driver is considered the
> master and exports a single function to get access to things like base
> address, hardware variant information, shared spinlock for register
> access synchronization and interrupt numbers
>  - Renamed the clocksource driver to samsung_pwm
>  - Cleaned up the code a bit more
>  - Added clocksource_of_init support
> 
> Changes since v3:
> (http://thread.gmane.org/gmane.linux.kernel.samsung-soc/16664/)
>  - Changed the design to use common (master) driver for operations that
>    can be done from both clocksource and PWM drivers (as suggested by
>    Arnd Bergmann) - needed to properly synchronize access to PWM
> registers - Moved handling of PWM prescaler and divider to master
> driver
> 
> Changes since v2:
> (http://thread.gmane.org/gmane.linux.kernel.samsung-soc/16158)
>  - Addressed comments from Rob Herring and Mark Rutland
>  - Removed unused register definitions
>  - Replaced samsung,source-timer and samsung,event-timer properties
>    with samsung,pwm-outputs property that defines which PWM channels
>    are reserved for PWM outputs on particular platform
>  - Split non-DT and DT initialization into two functions
>  - Fixed a copy paste error
> 
> Changes since v1:
> (http://thread.gmane.org/gmane.linux.kernel.samsung-soc/16005)
>  - Addressed comments from Mark Rutland
>  - Documented struct samsung_timer_variant
>  - Dropped inactive mail addresses from CC
> 
> Tomasz Figa (14):
>   ARM: SAMSUNG: Move samsung-time to drivers/clocksource
>   clocksource: samsung-pwm: Clean up platform header
>   clocksource: samsung-pwm: Add infrastructure to share PWM hardware
>   ARM: SAMSUNG: Unify base address definitions of timer block
>   ARM: SAMSUNG: Add new PWM platform device
>   ARM: SAMSUNG: Set PWM platform data
>   clocksource: samsung-pwm: Use platform data to setup the clocksource
>   clocksource: samsung-pwm: Synchronize register accesses
>   clocksource: samsung-pwm: Move IRQ mask/ack handling to the driver
>   ARM: SAMSUNG: Remove unused PWM timer IRQ chip code
>   clocksource: samsung-pwm: Configure dividers directly
>   clocksource: samsung-pwm: Do not use static mapping of registers
>   clocksource: samsung-pwm: Drop unnecessary includes
>   clocksource: samsung-pwm: Prepare for clocksource_of_init

On S3C6410-based Tiny6410 (Mini6410-compatible) board, both with and 
without Device Tree:

Tested-by: Tomasz Figa <tomasz.figa at gmail.com>

Best regards,
Tomasz



From haojian.zhuang at gmail.com  Sat Apr 13 08:50:17 2013
From: haojian.zhuang at gmail.com (Haojian Zhuang)
Date: Sat, 13 Apr 2013 20:50:17 +0800
Subject: [PATCH 1/4] ARM: mmp: add wakeup function for ICU
In-Reply-To: <1365651463-11502-2-git-send-email-zhangwm@marvell.com>
References: <1365651463-11502-1-git-send-email-zhangwm@marvell.com>
 <1365651463-11502-2-git-send-email-zhangwm@marvell.com>
Message-ID: <CAN1soZwFJybMUZgxZJyXcDdKXbpQxaVntyZd8oGnQivLF=ZNNA@mail.gmail.com>

On Thu, Apr 11, 2013 at 11:37 AM, Neil Zhang <zhangwm at marvell.com> wrote:
> From: Chao Xie <chao.xie at marvell.com>
>
> PXA988 will use GIC as its interrupt controller, and ICU is used as wakeup
> logic. When AP subsystem is powered off, GIC will lose its context, the
> PMU will need ICU to wakeup the AP subsystem.
> When ICU works as wakeup logic, there is no need to know intc-nr-irqs,
> change the corresponding code.
>
> Signed-off-by: Chao Xie <chao.xie at marvell.com>
> Signed-off-by: Neil Zhang <zhangwm at marvell.com>
> ---
>  .../devicetree/bindings/arm/mrvl/intc.txt          |    9 ++++
>  arch/arm/mach-mmp/irq.c                            |   51 ++++++++++++++++----
>  2 files changed, 50 insertions(+), 10 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/arm/mrvl/intc.txt b/Documentation/devicetree/bindings/arm/mrvl/intc.txt
> index 8b53273..58c0e74 100644
> --- a/Documentation/devicetree/bindings/arm/mrvl/intc.txt
> +++ b/Documentation/devicetree/bindings/arm/mrvl/intc.txt
> @@ -15,6 +15,8 @@ Required properties:
>  - interrupt-controller : Identifies the node as an interrupt controller.
>  - #interrupt-cells : Specifies the number of cells needed to encode an
>    interrupt source.
> +- mrvl,intc-wakeup : Specifies the address and value for global mask in the
> +  interrupt controller.
>  - mrvl,intc-nr-irqs : Specifies the number of interrupts in the interrupt
>    controller.
>  - mrvl,clr-mfp-irq : Specifies the interrupt that needs to clear MFP edge
> @@ -39,6 +41,13 @@ Example:
>                 mrvl,intc-nr-irqs = <2>;
>         };
>
> +       intc: interrupt-controller at d4282000 {
> +               compatible = "mrvl,mmp-intc";
> +               reg = <0xd4282000 0x1000>;
> +               mrvl,intc-wakeup = <0x114 0x3
> +                                   0x144 0x3>;
> +       };
> +
>  * Marvell Orion Interrupt controller
>
>  Required properties
> diff --git a/arch/arm/mach-mmp/irq.c b/arch/arm/mach-mmp/irq.c
> index 3c71246..b8df948 100644
> --- a/arch/arm/mach-mmp/irq.c
> +++ b/arch/arm/mach-mmp/irq.c
> @@ -16,6 +16,7 @@
>  #include <linux/init.h>
>  #include <linux/irq.h>
>  #include <linux/irqdomain.h>
> +#include <linux/irqchip/arm-gic.h>
>  #include <linux/io.h>
>  #include <linux/ioport.h>
>  #include <linux/of_address.h>
> @@ -57,6 +58,7 @@ struct mmp_intc_conf {
>  void __iomem *mmp_icu_base;
>  static struct icu_chip_data icu_data[MAX_ICU_NR];
>  static int max_icu_nr;
> +static bool mmp_icu_wakeup;
>
>  extern void mmp2_clear_pmic_int(void);
>
> @@ -91,8 +93,11 @@ static void icu_mask_irq(struct irq_data *d)
>         int hwirq;
>         u32 r;
>
> -       hwirq = d->irq - data->virq_base;
> -       if (data == &icu_data[0]) {
> +       if (mmp_icu_wakeup)
> +               hwirq = d->hwirq;
> +       else
> +               hwirq = d->irq - data->virq_base;
> +       if (data == &icu_data[0] || mmp_icu_wakeup) {
>                 r = readl_relaxed(mmp_icu_base + (hwirq << 2));
>                 r &= ~data->conf_mask;
>                 r |= data->conf_disable;
> @@ -110,8 +115,11 @@ static void icu_unmask_irq(struct irq_data *d)
>         int hwirq;
>         u32 r;
>
> -       hwirq = d->irq - data->virq_base;
> -       if (data == &icu_data[0]) {
> +       if (mmp_icu_wakeup)
> +               hwirq = d->hwirq;
> +       else
> +               hwirq = d->irq - data->virq_base;
> +       if (data == &icu_data[0] || mmp_icu_wakeup) {
>                 r = readl_relaxed(mmp_icu_base + (hwirq << 2));
>                 r &= ~data->conf_mask;
>                 r |= data->conf_enable;
> @@ -415,6 +423,8 @@ void __init mmp_dt_irq_init(void)
>         const struct of_device_id *of_id;
>         struct mmp_intc_conf *conf;
>         int nr_irqs, irq_base, ret, irq;
> +       const __be32 *wakeup_reg;
> +       int size, i;
>
>         node = of_find_matching_node(NULL, intc_ids);
>         if (!node) {
> @@ -424,18 +434,39 @@ void __init mmp_dt_irq_init(void)
>         of_id = of_match_node(intc_ids, node);
>         conf = of_id->data;
>
> -       ret = of_property_read_u32(node, "mrvl,intc-nr-irqs", &nr_irqs);
> -       if (ret) {
> -               pr_err("Not found mrvl,intc-nr-irqs property\n");
> -               return;
> -       }
> -
>         mmp_icu_base = of_iomap(node, 0);
>         if (!mmp_icu_base) {
>                 pr_err("Failed to get interrupt controller register\n");
>                 return;
>         }
>
> +       /* ICU is only used as wake up logic. */
> +       wakeup_reg = of_get_property(node, "mrvl,intc-wakeup", &size);
> +       if (wakeup_reg) {
> +               mmp_icu_wakeup = 1;
> +               size /= sizeof(*wakeup_reg);
> +               i = 0;
> +               /* disable the global irq/fiq in icu for all cores. */
> +               while (i < size) {
> +                       unsigned offset, val;
> +
> +                       offset = be32_to_cpup(wakeup_reg + i++);
> +                       val = be32_to_cpup(wakeup_reg + i++);
> +                       writel_relaxed(val, mmp_icu_base + offset);
> +               }
> +
> +               gic_arch_extn.irq_mask = icu_mask_irq;
> +               gic_arch_extn.irq_unmask = icu_unmask_irq;
> +
> +               return;
> +       }

Since it's totally different from original ICU irq initialization, I suggest to
create a new entry to handle this kind of wakeup event. And we could
create a new mask/unmask function.

> +
> +       ret = of_property_read_u32(node, "mrvl,intc-nr-irqs", &nr_irqs);
> +       if (ret) {
> +               pr_err("Not found mrvl,intc-nr-irqs property\n");
> +               return;
> +       }
> +
>         irq_base = irq_alloc_descs(-1, 0, nr_irqs - NR_IRQS_LEGACY, 0);
>         if (irq_base < 0) {
>                 pr_err("Failed to allocate IRQ numbers\n");
> --
> 1.7.4.1
>


From robdclark at gmail.com  Sat Apr 13 08:54:22 2013
From: robdclark at gmail.com (Rob Clark)
Date: Sat, 13 Apr 2013 08:54:22 -0400
Subject: Latest randconfig build errors
In-Reply-To: <20130304184649.GO11806@atomide.com>
References: <20130304095136.GI17833@n2100.arm.linux.org.uk>
 <20130304184649.GO11806@atomide.com>
Message-ID: <CAF6AEGv=3453KKS9-8YAgHrxMMbNvLMvt0pz-=qdG+zcd-Trrw@mail.gmail.com>

On Mon, Mar 4, 2013 at 1:46 PM, Tony Lindgren <tony at atomide.com> wrote:
>
>> drivers/gpu/drm/tilcdc/tilcdc_slave.o:(.data+0x54): multiple definition of `__mod_of_device_table'
>> drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54): first defined here
>> drivers/gpu/drm/tilcdc/tilcdc_panel.o:(.data+0x54): multiple definition of `__mod_of_device_table'
>> drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54): first defined here
>> drivers/gpu/drm/tilcdc/tilcdc_drv.o:(.data+0x184): multiple definition of `__mod_of_device_table'
>> drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54): first defined here
>
> Rob, I assume you'll do a patch for this one?


oh, I apologize for the late reply, I didn't see this email...

There is a patch that we can merge to make tilcdc bool instead of
tristate[1], which I suppose is ok for a temporary fix.  Although I'm
all-ears if someone has a better idea about how to fix this.  The
problem is that we have multiple sub-devices for different possible
panel drivers, so that depending on DT tables, the correct ones get
loaded for the hw.  But they are all built into a single module.
Splitting them into multiple modules will be problematic, as panel
drivers which are present really need to get probed before the
toplevel drm device.. I suppose in theory it is possible to make drm
cope better with dynamically loaded outputs, but I'm not sure that
there is any way to do this without breaking userspace which expects
that all of the connectors/encoders are present once the drm device is
loaded.

BR,
-R

[1] https://patchwork.kernel.org/patch/2376061/


From haojian.zhuang at gmail.com  Sat Apr 13 08:59:13 2013
From: haojian.zhuang at gmail.com (Haojian Zhuang)
Date: Sat, 13 Apr 2013 20:59:13 +0800
Subject: [PATCH 2/4] ARM: mmp: move function declaration to head file
In-Reply-To: <1365651463-11502-3-git-send-email-zhangwm@marvell.com>
References: <1365651463-11502-1-git-send-email-zhangwm@marvell.com>
 <1365651463-11502-3-git-send-email-zhangwm@marvell.com>
Message-ID: <CAN1soZyibQLOkeeZAi-8kWVJtgS9z9g0kyVSGunP-QO4dEkuzg@mail.gmail.com>

On Thu, Apr 11, 2013 at 11:37 AM, Neil Zhang <zhangwm at marvell.com> wrote:
> Move some of the function declaration to head file.
>
> Signed-off-by: Neil Zhang <zhangwm at marvell.com>
> Signed-off-by: Chao Xie <chao.xie at marvell.com>
> ---
>  arch/arm/mach-mmp/common.h  |    3 +++
>  arch/arm/mach-mmp/mmp-dt.c  |    3 ---
>  arch/arm/mach-mmp/mmp2-dt.c |    3 ---
>  3 files changed, 3 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/mach-mmp/common.h b/arch/arm/mach-mmp/common.h
> index 0bdc50b..8c9b510 100644
> --- a/arch/arm/mach-mmp/common.h
> +++ b/arch/arm/mach-mmp/common.h
> @@ -8,3 +8,6 @@ extern void mmp_restart(char, const char *);
>  extern void __init pxa168_clk_init(void);
>  extern void __init pxa910_clk_init(void);
>  extern void __init mmp2_clk_init(void);
> +
> +extern void __init mmp_dt_irq_init(void);
> +extern void __init mmp_dt_init_timer(void);

It's better to make use of of_irq_init() & CLOCKSOURCE_OF_DECLARE()
for timer. So I'll move mmp timer into clocksource & mmp irq into
irqchip directory in the next week. You can rebase your code. Is it OK?

> diff --git a/arch/arm/mach-mmp/mmp-dt.c b/arch/arm/mach-mmp/mmp-dt.c
> index d063efa..af0bb5b 100644
> --- a/arch/arm/mach-mmp/mmp-dt.c
> +++ b/arch/arm/mach-mmp/mmp-dt.c
> @@ -19,9 +19,6 @@
>
>  #include "common.h"
>
> -extern void __init mmp_dt_irq_init(void);
> -extern void __init mmp_dt_init_timer(void);
> -
>  static const struct of_dev_auxdata pxa168_auxdata_lookup[] __initconst = {
>         OF_DEV_AUXDATA("mrvl,mmp-uart", 0xd4017000, "pxa2xx-uart.0", NULL),
>         OF_DEV_AUXDATA("mrvl,mmp-uart", 0xd4018000, "pxa2xx-uart.1", NULL),
> diff --git a/arch/arm/mach-mmp/mmp2-dt.c b/arch/arm/mach-mmp/mmp2-dt.c
> index fad431a..4ba1fbe 100644
> --- a/arch/arm/mach-mmp/mmp2-dt.c
> +++ b/arch/arm/mach-mmp/mmp2-dt.c
> @@ -21,9 +21,6 @@
>
>  #include "common.h"
>
> -extern void __init mmp_dt_irq_init(void);
> -extern void __init mmp_dt_init_timer(void);
> -
>  static const struct of_dev_auxdata mmp2_auxdata_lookup[] __initconst = {
>         OF_DEV_AUXDATA("mrvl,mmp-uart", 0xd4030000, "pxa2xx-uart.0", NULL),
>         OF_DEV_AUXDATA("mrvl,mmp-uart", 0xd4017000, "pxa2xx-uart.1", NULL),
> --
> 1.7.4.1
>


From haojian.zhuang at gmail.com  Sat Apr 13 09:04:18 2013
From: haojian.zhuang at gmail.com (Haojian Zhuang)
Date: Sat, 13 Apr 2013 21:04:18 +0800
Subject: [PATCH 3/4] ARM: mmp: bring up pxa988 with device tree support
In-Reply-To: <1365651529-11545-1-git-send-email-zhangwm@marvell.com>
References: <1365651529-11545-1-git-send-email-zhangwm@marvell.com>
Message-ID: <CAN1soZxhXW=pNGihz6g4arK0zWi7_rzXQyJfuuat0d+Yw+P0Gg@mail.gmail.com>

On Thu, Apr 11, 2013 at 11:38 AM, Neil Zhang <zhangwm at marvell.com> wrote:
> bring up pxa988 with device tree support.
>
> Signed-off-by: Neil Zhang <zhangwm at marvell.com>
> Signed-off-by: Chao Xie <chao.xie at marvell.com>
> ---
>  arch/arm/boot/dts/pxa988-dkb.dts          |   36 ++++++
>  arch/arm/boot/dts/pxa988.dtsi             |  196 +++++++++++++++++++++++++++++
>  arch/arm/mach-mmp/Kconfig                 |   25 ++++
>  arch/arm/mach-mmp/Makefile                |    1 +
>  arch/arm/mach-mmp/common.c                |   11 ++-
>  arch/arm/mach-mmp/include/mach/addr-map.h |    6 +
>  arch/arm/mach-mmp/mmpx-dt.c               |   79 ++++++++++++
>  drivers/clk/mmp/Makefile                  |    1 +
>  8 files changed, 354 insertions(+), 1 deletions(-)
>  create mode 100644 arch/arm/boot/dts/pxa988-dkb.dts
>  create mode 100644 arch/arm/boot/dts/pxa988.dtsi
>  create mode 100644 arch/arm/mach-mmp/mmpx-dt.c
>
> diff --git a/arch/arm/boot/dts/pxa988-dkb.dts b/arch/arm/boot/dts/pxa988-dkb.dts
> new file mode 100644
> index 0000000..2cee3ed
> --- /dev/null
> +++ b/arch/arm/boot/dts/pxa988-dkb.dts
> @@ -0,0 +1,36 @@
> +/*
> + *  Copyright (C) 2012 Marvell Technology Group Ltd.
> + *  Author: Haojian Zhuang <haojian.zhuang at marvell.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
> + *  publishhed by the Free Software Foundation.
> + */
> +
> +/dts-v1/;
> +/include/ "pxa988.dtsi"
> +
> +
> +                       gpio at d4019000 {
> +                               compatible = "mrvl,mmp-gpio";
Since gpio-pxa driver is updated & merged just now, you need
to update this as "marvell,mmp-gpio".

> +
> +/* PXA988 */
> +static const struct of_dev_auxdata pxa988_auxdata_lookup[] __initconst = {
> +       OF_DEV_AUXDATA("mrvl,mmp-uart", 0xd4017000, "pxa2xx-uart.0", NULL),
> +       OF_DEV_AUXDATA("mrvl,mmp-uart", 0xd4018000, "pxa2xx-uart.1", NULL),
> +       OF_DEV_AUXDATA("mrvl,mmp-uart", 0xd4036000, "pxa2xx-uart.2", NULL),
> +       OF_DEV_AUXDATA("mrvl,mmp-twsi", 0xd4011000, "pxa2xx-i2c.0", NULL),
> +       OF_DEV_AUXDATA("mrvl,mmp-twsi", 0xd4037000, "pxa2xx-i2c.1", NULL),
> +       OF_DEV_AUXDATA("mrvl,mmp-gpio", 0xd4019000, "pxa-gpio", NULL),
"marvell,mmp-gpio"


From haojian.zhuang at gmail.com  Sat Apr 13 09:08:12 2013
From: haojian.zhuang at gmail.com (Haojian Zhuang)
Date: Sat, 13 Apr 2013 21:08:12 +0800
Subject: [PATCH 4/4] ARM: mmp: add SMP support for pxa988
In-Reply-To: <1365651547-11583-1-git-send-email-zhangwm@marvell.com>
References: <1365651547-11583-1-git-send-email-zhangwm@marvell.com>
Message-ID: <CAN1soZxCX1oUg69MTy0ZAL2vH8SOywDBaZHJ7wgnwgasxPAPdQ@mail.gmail.com>

On Thu, Apr 11, 2013 at 11:39 AM, Neil Zhang <zhangwm at marvell.com> wrote:
> Add SMP support for pxa988.
>
> Signed-off-by: Neil Zhang <zhangwm at marvell.com>
> Signed-off-by: Chao Xie <chao.xie at marvell.com>
> ---
>  arch/arm/mach-mmp/Makefile  |    4 +
>  arch/arm/mach-mmp/common.h  |    2 +
>  arch/arm/mach-mmp/headsmp.S |  104 ++++++++++++++++++++++++++
>  arch/arm/mach-mmp/mmpx-dt.c |    1 +
>  arch/arm/mach-mmp/platsmp.c |  170 +++++++++++++++++++++++++++++++++++++++++++
>  arch/arm/mach-mmp/reset.c   |   66 +++++++++++++++++
>  arch/arm/mach-mmp/reset.h   |   29 +++++++
>  7 files changed, 376 insertions(+), 0 deletions(-)
>  create mode 100644 arch/arm/mach-mmp/headsmp.S
>  create mode 100644 arch/arm/mach-mmp/platsmp.c
>  create mode 100644 arch/arm/mach-mmp/reset.c
>  create mode 100644 arch/arm/mach-mmp/reset.h
>
> diff --git a/arch/arm/mach-mmp/Makefile b/arch/arm/mach-mmp/Makefile
> index b60065f..e7b6173 100644
> --- a/arch/arm/mach-mmp/Makefile
> +++ b/arch/arm/mach-mmp/Makefile
> @@ -9,6 +9,10 @@ obj-$(CONFIG_CPU_PXA168)       += pxa168.o
>  obj-$(CONFIG_CPU_PXA910)       += pxa910.o
>  obj-$(CONFIG_CPU_MMP2)         += mmp2.o sram.o
>
> +ifeq ($(CONFIG_SMP),y)
> +obj-$(CONFIG_CPU_PXA988)       += platsmp.o headsmp.o reset.o
> +endif
> +
You already select CONFIG_SMP if PXA988 is selected. There's no reason
to check CONFIG_SMP in Makefile again.

>  ifeq ($(CONFIG_COMMON_CLK), )
>  obj-y                          += clock.o
>  obj-$(CONFIG_CPU_PXA168)       += clock-pxa168.o
> diff --git a/arch/arm/mach-mmp/common.h b/arch/arm/mach-mmp/common.h
> index 8c9b510..7496cd0 100644
> --- a/arch/arm/mach-mmp/common.h
> +++ b/arch/arm/mach-mmp/common.h
> @@ -1,5 +1,7 @@
>  #define ARRAY_AND_SIZE(x)      (x), ARRAY_SIZE(x)
>
> +extern struct smp_operations mmp_smp_ops;
> +
>  extern void timer_init(int irq);
>
>  extern void __init icu_init_irq(void);
> diff --git a/arch/arm/mach-mmp/headsmp.S b/arch/arm/mach-mmp/headsmp.S
> new file mode 100644
> index 0000000..2b6177e
> --- /dev/null
> +++ b/arch/arm/mach-mmp/headsmp.S
> @@ -0,0 +1,104 @@
> +/*
> + * linux/arch/arm/mach-mmp/headsmp.S
> + *
> + * Copyright (C) 2012 Marvell, Inc.
> + *
> + * Author: Neil Zhang <zhangwm at marvell.com>
> + *
> + * This software is licensed under the terms of the GNU General Public
> + * License version 2, as published by the Free Software Foundation, and
> + * may be copied, distributed, and modified under those terms.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + */
> +#include <linux/linkage.h>
> +#include <linux/init.h>
> +#include <asm/memory.h>
> +#include <asm/cache.h>
> +#include <asm/assembler.h>
> +#include <mach/addr-map.h>
> +
> +       __CPUINIT
> +
> +/*
> + * Marvell specific entry point for secondary CPUs.
> + * The secondary kernel init calls v7_flush_dcache_all before it enables
> + * the L1; however, the L1 comes out of reset in an undefined state, so
> + * the clean + invalidate performed by v7_flush_dcache_all causes a bunch
> + * of cache lines with uninitialized data and uninitialized tags to get
> + * written out to memory, which does really unpleasant things to the main
> + * processor.  We fix this by performing an invalidate, rather than a
> + * clean + invalidate for secondary core, before jumping into the kernel.
> + *
> + * This funciton is cloned from arch/arm/mach-tegra/headsmp.S, and needs
> + * to be called for both secondary cores startup and primary core resume
> + * procedures.
> + */
> +       .align L1_CACHE_SHIFT
> +
> +
> +/*
> + * PXA specific entry point for secondary CPUs.  This provides
> + * a "holding pen" into which all secondary cores are held until we're
> + * ready for them to initialise.
> + */
> +ENTRY(mmp_secondary_startup)
> +       mrc     p15, 0, r0, c0, c0, 5
> +       and     r0, r0, #15
> +       adr     r4, 1f
> +       ldmia   r4, {r5, r6}
> +       sub     r4, r4, r5
> +       add     r6, r6, r4
> +pen:   ldr     r7, [r6]
> +       cmp     r7, r0
> +       bne     pen
> +
> +       /*
> +        * we've been released from the holding pen: secondary_stack
> +        * should now contain the SVC stack for this core
> +        */
> +       bl      v7_invalidate_l1
> +       b       secondary_startup
> +ENDPROC(mmp_secondary_startup)
> +
> +       .align  2
> +1:     .long   .
> +       .long   pen_release
> +
> +
> +/*
> + * Note: The following code is located into the .data section. This is to
> + *       allow sw_reset_flag and cpu_plugin_handler to be accessed with a
> + *       relative load while we can't rely on any MMU translation.
> + *       Reference from: arch/arm/kernel/sleep.S
> + */
> +
> +       .data
> +       .align
> +
> +/*
> + * ROM code jumps to this function while waking up from CPU
> + * OFF or software reset state. Physical address of the function is
> + * stored at CA9_WARM_RESET_VECTOR while system is bring up.
> + */
> +ENTRY(mmp_cpu_reset_entry)
> +       adr     r1, mmp_entry_vectors
> +       mrc     p15, 0, r0, c0, c0, 5
> +       and     r0, r0, #15             @ fetch CPUID
> +1:
> +       ldr     r2, [r1, r0, lsl #2]    @ get the handler addr for this core
> +       cmp     r2, #0
> +       movne   pc, r2                  @ jump to the handler
> +       beq     1b
> +ENDPROC(mmp_cpu_reset_entry)
> +
> +       /* Point to the address that save handlers for each core */
> +       .global mmp_entry_vectors
> +mmp_entry_vectors:
> +       .rept   CONFIG_NR_CPUS
> +        .long   0                               @ preserve stack phys ptr here
> +       .endr
> diff --git a/arch/arm/mach-mmp/mmpx-dt.c b/arch/arm/mach-mmp/mmpx-dt.c
> index bbc0c50..a5f5501 100644
> --- a/arch/arm/mach-mmp/mmpx-dt.c
> +++ b/arch/arm/mach-mmp/mmpx-dt.c
> @@ -71,6 +71,7 @@ static const char *pxa988_dt_board_compat[] __initdata = {
>  };
>
>  DT_MACHINE_START(PXA988_DT, "Marvell PXA988 (Device Tree Support)")
> +       .smp            = smp_ops(mmp_smp_ops),
>         .map_io         = mmp_map_io,
>         .init_irq       = pxa988_dt_gic_init,
>         .init_time      = pxa988_dt_init_timer,
> diff --git a/arch/arm/mach-mmp/platsmp.c b/arch/arm/mach-mmp/platsmp.c
> new file mode 100644
> index 0000000..a6590a3
> --- /dev/null
> +++ b/arch/arm/mach-mmp/platsmp.c
> @@ -0,0 +1,170 @@
> +/*
> + *  linux/arch/arm/mach-mmp/platsmp.c
> + *
> + *  Copyright (C) 2002 ARM Ltd.
> + *  All Rights Reserved
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +#include <linux/init.h>
> +#include <linux/errno.h>
> +#include <linux/delay.h>
> +#include <linux/device.h>
> +#include <linux/jiffies.h>
> +#include <linux/smp.h>
> +#include <linux/io.h>
> +#include <linux/irq.h>
> +
> +#include <asm/cacheflush.h>
> +#include <mach/hardware.h>
> +#include <linux/irqchip/arm-gic.h>
> +#include <asm/mach-types.h>
> +#include <asm/localtimer.h>
> +#include <asm/smp_scu.h>
> +
> +#include <mach/irqs.h>
> +#include <mach/addr-map.h>
> +
> +#include "common.h"
> +#include "reset.h"
> +
> +/*
> + * Write pen_release in a way that is guaranteed to be visible to all
> + * observers, irrespective of whether they're taking part in coherency
> + * or not.  This is necessary for the hotplug code to work reliably.
> + */
> +static void __cpuinit write_pen_release(int val)
> +{
> +       pen_release = val;
> +       smp_wmb();
> +       __cpuc_flush_dcache_area((void *)&pen_release, sizeof(pen_release));
> +       outer_clean_range(__pa(&pen_release), __pa(&pen_release + 1));
> +}
> +
> +#ifdef CONFIG_HAVE_ARM_SCU
> +static void __iomem *scu_get_base_addr(void)
> +{
> +       return SCU_VIRT_BASE;
> +}
> +#endif
> +
> +static inline unsigned int get_core_count(void)
> +{
> +       u32 ret = 1;
> +#ifdef CONFIG_HAVE_ARM_SCU
> +       ret = scu_get_core_count(scu_get_base_addr());
> +#endif
> +
> +       return ret;
> +}
> +
> +static DEFINE_SPINLOCK(boot_lock);
> +
> +static void __cpuinit mmp_secondary_init(unsigned int cpu)
> +{
> +       /*
> +        * if any interrupts are already enabled for the primary
> +        * core (e.g. timer irq), then they will not have been enabled
> +        * for us: do so
> +        */
> +       gic_secondary_init(0);
> +
> +       /*
> +        * let the primary processor know we're out of the
> +        * pen, then head off into the C entry point
> +        */
> +       write_pen_release(-1);
> +
> +       /*
> +        * Synchronise with the boot thread.
> +        */
> +       spin_lock(&boot_lock);
> +       spin_unlock(&boot_lock);
Lock & unlock without protecting anything. If so, you can remove this.

> +}
> +
> +static int __cpuinit mmp_boot_secondary(unsigned int cpu, struct task_struct *idle)
> +{
> +       unsigned long timeout;
> +
> +       /*
> +        * Avoid timer calibration on slave cpus. Use the value calibrated
> +        * on master cpu. Referenced from tegra3
> +        */
> +       preset_lpj = loops_per_jiffy;
> +
> +       /*
> +        * set synchronisation state between this boot processor
> +        * and the secondary one
> +        */
> +
> +       spin_lock(&boot_lock);
> +
> +       /*
> +        * The secondary processor is waiting to be released from
> +        * the holding pen - release it, then wait for it to flag
> +        * that it has been released by resetting pen_release.
> +        *
> +        * Note that "pen_release" is the hardware CPU ID, whereas
> +        * "cpu" is Linux's internal ID.
> +        */
> +       write_pen_release(cpu);
> +
> +       /* reset the cpu, let it branch to the kernel entry */
> +       mmp_cpu_power_up(cpu);
> +
> +       timeout = jiffies + (1 * HZ);
> +       while (time_before(jiffies, timeout)) {
> +               smp_rmb();
> +               if (pen_release == -1)
> +                       break;
> +
> +               udelay(10);
> +       }
> +
> +       /*
> +        * now the secondary core is starting up let it run its
> +        * calibrations, then wait for it to finish
> +        */
> +       spin_unlock(&boot_lock);
> +
> +       return pen_release != -1 ? -ENOSYS : 0;
> +}
> +
> +/*
> + * Initialise the CPU possible map early - this describes the CPUs
> + * which may be present or become present in the system.
> + */
> +static void __init mmp_smp_init_cpus(void)
> +{
> +       unsigned int i, ncores = get_core_count();
> +
> +       for (i = 0; i < ncores; i++)
> +               set_cpu_possible(i, true);
> +}
> +
> +static void __init mmp_smp_prepare_cpus(unsigned int max_cpus)
> +{
> +       int i;
> +
> +       /*
> +        * Initialise the present map, which describes the set of CPUs
> +        * actually populated at the present time.
> +        */
> +       for (i = 0; i < max_cpus; i++)
> +               set_cpu_present(i, true);
> +
> +#ifdef CONFIG_HAVE_ARM_SCU
> +       scu_enable(scu_get_base_addr());
> +#endif
> +
> +       mmp_entry_vector_init();
> +}
> +
> +struct smp_operations mmp_smp_ops __initdata = {
> +       .smp_init_cpus          = mmp_smp_init_cpus,
> +       .smp_prepare_cpus       = mmp_smp_prepare_cpus,
> +       .smp_secondary_init     = mmp_secondary_init,
> +       .smp_boot_secondary     = mmp_boot_secondary,
> +};
> diff --git a/arch/arm/mach-mmp/reset.c b/arch/arm/mach-mmp/reset.c
> new file mode 100644
> index 0000000..b47e400
> --- /dev/null
> +++ b/arch/arm/mach-mmp/reset.c
> @@ -0,0 +1,66 @@
> +/*
> + * linux/arch/arm/mach-mmp/reset.c
> + *
> + * Author:     Neil Zhang <zhangwm at marvell.com>
> + * Copyright:  (C) 2012 Marvell International Ltd.
> + *
> + * 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.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/smp.h>
> +
> +#include <asm/io.h>
> +#include <asm/cacheflush.h>
> +#include <asm/mach/map.h>
> +
> +#include <mach/addr-map.h>
> +
> +#include "reset.h"
> +
> +#define PMU_CC2_AP                     APMU_REG(0x0100)
> +#define CIU_CA9_WARM_RESET_VECTOR      CIU_REG(0x00d8)
> +
> +/*
> + * This function is called from boot_secondary to bootup the secondary cpu.
> + */
> +void mmp_cpu_power_up(u32 cpu)
> +{
> +       u32 tmp;
> +
> +       BUG_ON(cpu == 0);
> +
> +       tmp = readl(PMU_CC2_AP);
> +       if (tmp & CPU_CORE_RST(cpu)) {
> +               /* Release secondary core from reset */
> +               tmp &= ~(CPU_CORE_RST(cpu)
> +                       | CPU_DBG_RST(cpu) | CPU_WDOG_RST(cpu));
> +               writel(tmp, PMU_CC2_AP);
> +       }
> +}
> +
> +void mmp_set_entry_vector(u32 cpu, u32 addr)
> +{
> +       BUG_ON(cpu >= CONFIG_NR_CPUS);
> +
> +       mmp_entry_vectors[cpu] = addr;
> +       smp_wmb();
> +       __cpuc_flush_dcache_area((void *)&mmp_entry_vectors[cpu],
> +                               sizeof(mmp_entry_vectors[cpu]));
> +       outer_clean_range(__pa(&mmp_entry_vectors[cpu]),
> +                               __pa(&mmp_entry_vectors[cpu + 1]));
> +}
> +
> +void __init mmp_entry_vector_init(void)
> +{
> +       int cpu;
> +
> +       /* We will reset from DDR directly by default */
> +       writel(__pa(mmp_cpu_reset_entry), CIU_CA9_WARM_RESET_VECTOR);
> +
> +       for (cpu = 1; cpu < CONFIG_NR_CPUS; cpu++)
> +               mmp_set_entry_vector(cpu, __pa(mmp_secondary_startup));
> +}
> diff --git a/arch/arm/mach-mmp/reset.h b/arch/arm/mach-mmp/reset.h
> new file mode 100644
> index 0000000..78d5486
> --- /dev/null
> +++ b/arch/arm/mach-mmp/reset.h
> @@ -0,0 +1,29 @@
> +/*
> + * linux/arch/arm/mach-mmp/include/mach/reset.h
> + *
> + * Author:     Neil Zhang <zhangwm at marvell.com>
> + * Copyright:  (C) 2012 Marvell International Ltd.
> + *
> + * 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.
> + */
> +
> +#ifndef __RESET_PXA988_H__
> +#define __RESET_PXA988_H__
> +
> +#define CPU_CORE_RST(n)        (1 << ((n) * 4 + 16))
> +#define CPU_DBG_RST(n) (1 << ((n) * 4 + 18))
> +#define CPU_WDOG_RST(n)        (1 << ((n) * 4 + 19))
> +
> +extern u32 mmp_entry_vectors[CONFIG_NR_CPUS];
> +
> +void mmp_secondary_startup(void);
> +void mmp_cpu_reset_entry(void);
> +
> +void mmp_cpu_power_up(u32 cpu);
> +void mmp_set_entry_vector(u32 cpu, u32 addr);
> +void __init mmp_entry_vector_init(void);
> +
> +#endif /* __RESET_PXA988_H__ */
> --
> 1.7.4.1
>


From andrew at lunn.ch  Sat Apr 13 09:14:36 2013
From: andrew at lunn.ch (Andrew Lunn)
Date: Sat, 13 Apr 2013 15:14:36 +0200
Subject: [PATCHv2 00/10] Use the mvebu PCIe driver on Kirkwood
In-Reply-To: <1365632436-25367-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1365632436-25367-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <20130413131436.GL2824@lunn.ch>

On Thu, Apr 11, 2013 at 12:20:26AM +0200, Thomas Petazzoni wrote:
> Hello,
> 
> Here is a set of patches that migrates adds support for Kirkwood
> platforms to use the mvebu PCIe driver. All the Kirkwood platforms
> that have already been converted to the Device Tree are converted to
> use the new driver, and the DB-88F6281 evaluation board from Marvell
> is also converted to the Device Tree and the usage of the new PCIe
> driver.
> 
> Only non-DT platforms continue to use the legacy code in
> arch/arm/mach-kirkwood/pcie.c.
> 
> This branch depends on the mvebu-mbus driver and the mvebu-pcie
> driver. I have pushed this branch to the following Git repository for
> easier testing:
> 
>   https://github.com/MISL-EBU-System-SW/mainline-public/tree/kirkwood-dt
> 
> # /usr/sbin/lspci
> 00:01.0 PCI bridge: Marvell Technology Group Ltd. Device 7846
> 00:02.0 PCI bridge: Marvell Technology Group Ltd. Device 7846
> 01:00.0 SCSI storage controller: Marvell Technology Group Ltd. 88SX7042 PCI-e 4-port SATA-II (rev 02)
> 02:00.0 Ethernet controller: Intel Corporation 82572EI Gigabit Ethernet Controller (Copper) (rev 06)
> 
> # cat /proc/cpuinfo | grep ^Hardware
> Hardware	: Marvell Kirkwood (Flattened Device Tree)
> 
> I've tested both the e1000e NIC card and the SATA 4 ports card and
> they work fine.
> 
> Changes between v1 and v2:
> 
>  * Remove the 'needs_pcie_win' logic, and instead move the static
>    initialization of PCIe windows into the legacy PCIe code, for the
>    platforms that will still be using it. Platforms that will use the
>    new PCIe driver benefit directly from dynamic allocation of PCIe
>    windows.
> 
>  * Move the PCIe interface definitions from kirkwood.dtsi to
>    kirkwood-6281.dtsi and kirkwood-6282.dtsi to take into account the
>    fact that the 6281 has one PCIe interface, and the 6282 has two of
>    them.
> 
>  * Convert all DT-platforms that were initializing PCIe using the
>    legacy driver to use the DT to initialize the PCIe interface. This
>    includes the Iomega Iconnect, the MPL CEC4, the ZyXEL NSA310and the
>    QNAP TS219.
> 
>  * Fix the conversion to the Device Tree of the DB-88F6181/6282
>    board. We now have two Device Trees, one for the 6281 variant of
>    the board (one PCIe interface) and another for the 6282 variant of
>    the board (two PCIe interfaces).
> 
>  * Update the defconfig with PCIe driver enabled and some board
>    updates.
> 
> Best regards,
> 
> Thomas
> 
> Thomas Petazzoni (10):
>   pci: mvebu: enable driver usage on Kirkwood
>   bus: mvebu: fix mistake in PCIe window target attribute for Kirkwood
>   arm: kirkwood: move PCIe window init to legacy driver
>   arm: kirkwood: add SoC-level Device Tree data for PCIe interfaces
>   arm: kirkwood: convert Iomega Iconnect to use DT for the PCIe
>     interface
>   arm: kirkwood: convert MPL CEC4 to use DT for the PCIe interface
>   arm: kirkwood: convert ZyXEL NSA310 to use DT for the PCIe interface
>   arm: kirkwood: convert QNAP TS219 to use DT for the PCIe interface
>   arm: kirkwood: convert db-88f6281 to the Device Tree
>   arm: kirkwood: update defconfig with PCIe driver and board updates
> 
>  .../devicetree/bindings/pci/mvebu-pci.txt          |    1 +
>  arch/arm/boot/dts/Makefile                         |    5 +-
>  arch/arm/boot/dts/kirkwood-6281.dtsi               |   31 ++++++
>  arch/arm/boot/dts/kirkwood-6282.dtsi               |   48 +++++++++
>  arch/arm/boot/dts/kirkwood-db-88f6281.dts          |   30 ++++++
>  arch/arm/boot/dts/kirkwood-db-88f6282.dts          |   34 ++++++
>  arch/arm/boot/dts/kirkwood-db.dtsi                 |   89 ++++++++++++++++
>  arch/arm/boot/dts/kirkwood-iconnect.dts            |    8 ++
>  arch/arm/boot/dts/kirkwood-mplcec4.dts             |    8 ++
>  arch/arm/boot/dts/kirkwood-nsa310.dts              |    8 ++
>  arch/arm/boot/dts/kirkwood-ts219.dtsi              |    7 ++
>  arch/arm/boot/dts/kirkwood.dtsi                    |    1 +
>  arch/arm/configs/kirkwood_defconfig                |    6 +-
>  arch/arm/mach-kirkwood/Kconfig                     |   21 ++--
>  arch/arm/mach-kirkwood/Makefile                    |    3 +-
>  arch/arm/mach-kirkwood/board-db88f6281-bp.c        |   26 +++++
>  arch/arm/mach-kirkwood/board-dt.c                  |    2 +
>  arch/arm/mach-kirkwood/board-iconnect.c            |    8 --
>  arch/arm/mach-kirkwood/board-mplcec4.c             |    1 -
>  arch/arm/mach-kirkwood/board-nsa310.c              |   25 -----
>  arch/arm/mach-kirkwood/board-ts219.c               |   10 --
>  arch/arm/mach-kirkwood/common.c                    |   24 -----
>  arch/arm/mach-kirkwood/common.h                    |    6 ++
>  arch/arm/mach-kirkwood/db88f6281-bp-setup.c        |  108 --------------------
>  arch/arm/mach-kirkwood/pcie.c                      |   22 ++++
>  drivers/bus/mvebu-mbus.c                           |    2 +-
>  drivers/pci/host/Kconfig                           |    2 +-
>  drivers/pci/host/pci-mvebu.c                       |    1 +
>  28 files changed, 339 insertions(+), 198 deletions(-)
>  create mode 100644 arch/arm/boot/dts/kirkwood-db-88f6281.dts
>  create mode 100644 arch/arm/boot/dts/kirkwood-db-88f6282.dts
>  create mode 100644 arch/arm/boot/dts/kirkwood-db.dtsi
>  create mode 100644 arch/arm/mach-kirkwood/board-db88f6281-bp.c
>  delete mode 100644 arch/arm/mach-kirkwood/board-nsa310.c
>  delete mode 100644 arch/arm/mach-kirkwood/db88f6281-bp-setup.c
> 
> -- 
> 1.7.9.5
> 

Hi Thomas

So i tested on QNAP and Topkick. Neither of which actually have any
PCI devices on the busses. So you can add my some what worthless:

Tested-by: Andrew Lunn <andrew at lunn.ch>

	   Andrew


From haojian.zhuang at gmail.com  Sat Apr 13 09:14:47 2013
From: haojian.zhuang at gmail.com (Haojian Zhuang)
Date: Sat, 13 Apr 2013 21:14:47 +0800
Subject: [GIT PULL] [for 3.10] pull request from armsoc/dt branch in pxa
 git tree
In-Reply-To: <20130413070905.GA28595@quad.lixom.net>
References: <CAN1soZxcmHMABTGi6FBtXysmY0TwWx7cdEvf1_ycHv2RtCLcpw@mail.gmail.com>
 <20130413070905.GA28595@quad.lixom.net>
Message-ID: <CAN1soZy5_i784zLixtDzJvD_H5esmfXGPv22eFSGtxNvHWQaBg@mail.gmail.com>

On Sat, Apr 13, 2013 at 3:09 PM, Olof Johansson <olof at lixom.net> wrote:
> Hi,
>
> On Sat, Apr 13, 2013 at 12:13:14PM +0800, Haojian Zhuang wrote:
>> Hi Arnd & Olof,
>>
>> Please help to pull armsoc/dt branch from pxa git tree. These patches
>> are used to enable hi3xxx SoC
>> and they're depend on Rob's clock source patches.
>>
>> Regards
>> Haojian
>>
>> The following changes since commit f6161aa153581da4a3867a2d1a7caf4be19b6ec9:
>>
>>   Linux 3.9-rc2 (2013-03-10 16:54:19 -0700)
>>
>> are available in the git repository at:
>>
>>   git://github.com/hzhuang1/linux.git armsoc/dt
>
> First of all, please try to move your repo somewhere else than github. We
> really prefer to see signed tags when repos come from github or gitorious
> or other similar sites. Maybe you can get a linaro git repo instead?
>
Sure. Let me move the git repo and use tags for pull request.

> That's not a showstopper in this case though, since there's only a few
> patches here and easy for us to review.
>
> A couple of more important comments below.
>
>> Haojian Zhuang (6):
>>       devtree: add binding documentation for sp804
>>       ARM: debug: support debug ll on hisilicon soc
>>       clk: hi3xxx: add clock support
>
> I didn't see an Acked-by from Mike Turquette on this one. Since this driver is
> an addition to his subsystem, I would like to see one. It could even go through
> his tree since this is all new platform code.
>
I'll resend these patches and wait Mike to Ack them.

> Not only that, but when I went searching for email to find reviews of this
> patch, I see that Arnd had a round of comments including a request to move
> hs_init_clocks() that, according to the email, was addressed but this patch
> does not seem to have moved.
>
>>       ARM: hi3xxx: add board support with device tree
>>       ARM: hi3xxx: enable hi4511 with device tree
>>       ARM: config: append arch hi3xxx into multi defconfig
>
> Given the comments above, and the currently late time for 3.10, I think this
> will be better held off for more review and a merge for 3.11. Please get the
> above taken care of and resubmit to us as soon as 3.10-rc1 is out and we'll
> stage it for 3.11. The code does look nice and clean and looks to be in good
> shape, so there should be no problem to get it in for 3.10.
>
I'm OK for 3.11 merge window.

Regards
Haojian


From mpa at pengutronix.de  Sat Apr 13 09:32:02 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Sat, 13 Apr 2013 15:32:02 +0200
Subject: [alsa-devel] [PATCH v2 00/11] ASoC: fsl-ssi: ac97-slave support
In-Reply-To: <5161D876.6020007@metafoo.de>
References: <1365362721-3731-1-git-send-email-mpa@pengutronix.de>
 <5161CB73.4000302@metafoo.de>
 <20130407200843.GA8350@pengutronix.de>
 <5161D876.6020007@metafoo.de>
Message-ID: <20130413133202.GA4573@pengutronix.de>

On Sun, Apr 07, 2013 at 10:35:02PM +0200, Lars-Peter Clausen wrote:
> On 04/07/2013 10:08 PM, Markus Pargmann wrote:
> > Hi,
> > 
> > On Sun, Apr 07, 2013 at 09:39:31PM +0200, Lars-Peter Clausen wrote:
> >> On 04/07/2013 09:25 PM, Markus Pargmann wrote:
> >>> Hi,
> >>>
> >>> This series adds DT support for phycore-ac97 using the fsl-ssi driver. In
> >>> version 2 I discarded most of the imx-ssi work and integrated the ac97-slave
> >>> support in fsl-ssi, including support for imx-pcm-fiq as alternative to dma.
> >>> There are some other changes to get phycore-ac97 working. The first two patches
> >>> have notes about the detailed changes since version 1. The rest of the patches
> >>> is new and necessary for the ac97-slave support.
> >>>
> >>> Regards,
> >>>
> >>> Markus
> >>>
> >>
> >> Hi,
> >>
> >> The DMA PCM related changes won't apply anymore due to the recent dmaengine
> >> PCM cleanups. I've also been working on a more generic dmaengine PCM driver
> >> which has DT support and can be used by imx. The work in progress patches
> >> can be found here:
> >> https://github.com/lclausen-adi/linux-2.6/commits/asoc-dmaengine-cleanups
> >>
> >> - Lars
> > 
> > Okay, I will rebase it for v3 onto your committed cleanups and will have
> > a look on your latest patches.
> > 
> 
> It might be a good idea to rebase it ontop of the generic dmaengine driver
> patches right away, since it will simplify things quite a bit.

I rebased the series onto your branch now. But there is a small problem
with the DMA handling.

Currently you pass the device pointer into snd_dmaengine_pcm_register
and use it to request the dma channels. At least for imx-pcm-audio
driver, it would be useful to pass a second device just for the dma
requests. Otherwise imx-pcm-audio needs devicetree bindings, but I think
the dma properties belong to fsl-ssi.

Regards,

Markus

> 
> - Lars
> 
> > Regards,
> > 
> > Markus
> > 
> >>
> >>>
> >>> Markus Pargmann (11):
> >>>   ASoC: phycore-ac97: Add DT support
> >>>   ASoC: imx-pcm-dma: Add support for DMA init by
> >>>   ASoC: imx-pcm-fiq: Introduce pcm-fiq-params
> >>>   ASoC: fsl-ssi: Add SACNT definitions
> >>>   ASoC: fsl-ssi: Add support for imx-pcm-fiq
> >>>   ASoC: fsl-ssi: Setup generic imx dma params
> >>>   ARM: imx: Export ac97 reset functions
> >>>   ASoC: fsl-ssi: imx ac97 support
> >>>   ASoC: fsl: Kconfig: Use fsl-ssi for phycore-ac97
> >>>   ASoC: fsl: Move fsl-ssi binding doc to sound/
> >>>   ASoC: fsl: Update fsl-ssi binding doc
> >>>
> >>>  Documentation/devicetree/bindings/powerpc/fsl/ssi.txt             |   73 -
> >>>  Documentation/devicetree/bindings/sound/fsl,ssi.txt               |   13 
> >>>  b/Documentation/devicetree/bindings/sound/fsl,ssi.txt             |   73 +
> >>>  b/Documentation/devicetree/bindings/sound/phytec,phycore-ac97.txt |   12 
> >>>  b/arch/arm/mach-imx/mach-pca100.c                                 |    7 
> >>>  b/arch/arm/mach-imx/mach-pcm043.c                                 |    7 
> >>>  b/sound/soc/fsl/Kconfig                                           |    2 
> >>>  b/sound/soc/fsl/fsl_ssi.c                                         |   70 +
> >>>  b/sound/soc/fsl/fsl_ssi.h                                         |    8 
> >>>  b/sound/soc/fsl/imx-pcm-dma.c                                     |   31 
> >>>  b/sound/soc/fsl/imx-pcm-fiq.c                                     |   14 
> >>>  b/sound/soc/fsl/imx-pcm.h                                         |    6 
> >>>  b/sound/soc/fsl/imx-ssi.c                                         |    7 
> >>>  b/sound/soc/fsl/imx-ssi.h                                         |    1 
> >>>  b/sound/soc/fsl/phycore-ac97.c                                    |  185 ++++
> >>>  sound/soc/fsl/fsl_ssi.c                                           |  379 +++++++---
> >>>  sound/soc/fsl/imx-pcm.h                                           |    9 
> >>>  17 files changed, 664 insertions(+), 233 deletions(-)
> >>>
> >>> _______________________________________________
> >>> Alsa-devel mailing list
> >>> Alsa-devel at alsa-project.org
> >>> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> >>
> >>
> > 
> 
> 

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From lars at metafoo.de  Sat Apr 13 09:40:04 2013
From: lars at metafoo.de (Lars-Peter Clausen)
Date: Sat, 13 Apr 2013 15:40:04 +0200
Subject: [alsa-devel] [PATCH v2 00/11] ASoC: fsl-ssi: ac97-slave support
In-Reply-To: <20130413133202.GA4573@pengutronix.de>
References: <1365362721-3731-1-git-send-email-mpa@pengutronix.de>
 <5161CB73.4000302@metafoo.de> <20130407200843.GA8350@pengutronix.de>
 <5161D876.6020007@metafoo.de> <20130413133202.GA4573@pengutronix.de>
Message-ID: <51696034.6060709@metafoo.de>

On 04/13/2013 03:32 PM, Markus Pargmann wrote:
> On Sun, Apr 07, 2013 at 10:35:02PM +0200, Lars-Peter Clausen wrote:
>> On 04/07/2013 10:08 PM, Markus Pargmann wrote:
>>> Hi,
>>>
>>> On Sun, Apr 07, 2013 at 09:39:31PM +0200, Lars-Peter Clausen wrote:
>>>> On 04/07/2013 09:25 PM, Markus Pargmann wrote:
>>>>> Hi,
>>>>>
>>>>> This series adds DT support for phycore-ac97 using the fsl-ssi driver. In
>>>>> version 2 I discarded most of the imx-ssi work and integrated the ac97-slave
>>>>> support in fsl-ssi, including support for imx-pcm-fiq as alternative to dma.
>>>>> There are some other changes to get phycore-ac97 working. The first two patches
>>>>> have notes about the detailed changes since version 1. The rest of the patches
>>>>> is new and necessary for the ac97-slave support.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Markus
>>>>>
>>>>
>>>> Hi,
>>>>
>>>> The DMA PCM related changes won't apply anymore due to the recent dmaengine
>>>> PCM cleanups. I've also been working on a more generic dmaengine PCM driver
>>>> which has DT support and can be used by imx. The work in progress patches
>>>> can be found here:
>>>> https://github.com/lclausen-adi/linux-2.6/commits/asoc-dmaengine-cleanups
>>>>
>>>> - Lars
>>>
>>> Okay, I will rebase it for v3 onto your committed cleanups and will have
>>> a look on your latest patches.
>>>
>>
>> It might be a good idea to rebase it ontop of the generic dmaengine driver
>> patches right away, since it will simplify things quite a bit.
> 
> I rebased the series onto your branch now. But there is a small problem
> with the DMA handling.
> 
> Currently you pass the device pointer into snd_dmaengine_pcm_register
> and use it to request the dma channels. At least for imx-pcm-audio
> driver, it would be useful to pass a second device just for the dma
> requests. Otherwise imx-pcm-audio needs devicetree bindings, but I think
> the dma properties belong to fsl-ssi.
> 

I though about that as well, just initialize of_node of the newly allocated
imx-pcm-audio platform device to that of the parent device. That should work
nicely.

- Lars


From mpa at pengutronix.de  Sat Apr 13 09:52:31 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Sat, 13 Apr 2013 15:52:31 +0200
Subject: [PATCH v2 06/11] ASoC: fsl-ssi: Setup generic imx dma params
In-Reply-To: <5162306B.6090207@tabi.org>
References: <1365362721-3731-1-git-send-email-mpa@pengutronix.de>
 <1365362721-3731-7-git-send-email-mpa@pengutronix.de>
 <5162306B.6090207@tabi.org>
Message-ID: <20130413135231.GC4573@pengutronix.de>

On Sun, Apr 07, 2013 at 09:50:19PM -0500, Timur Tabi wrote:
> Markus Pargmann wrote:
> >-		ret = of_property_read_u32_array(pdev->dev.of_node,
> >-					"fsl,ssi-dma-events", dma_events, 2);
> 
> Does this mean that the "fsl,ssi-dma-events" property is no longer used?

Yes, I just realized that it would break all platforms that do not have
a DMA driver with generic bindings yet. So I will instead still check
for this property in case 'dmas' is not set.

Regards,

Markus

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From mpa at pengutronix.de  Sat Apr 13 09:55:35 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Sat, 13 Apr 2013 15:55:35 +0200
Subject: [alsa-devel] [PATCH v2 00/11] ASoC: fsl-ssi: ac97-slave support
In-Reply-To: <51696034.6060709@metafoo.de>
References: <1365362721-3731-1-git-send-email-mpa@pengutronix.de>
 <5161CB73.4000302@metafoo.de>
 <20130407200843.GA8350@pengutronix.de>
 <5161D876.6020007@metafoo.de>
 <20130413133202.GA4573@pengutronix.de>
 <51696034.6060709@metafoo.de>
Message-ID: <20130413135535.GD4573@pengutronix.de>

On Sat, Apr 13, 2013 at 03:40:04PM +0200, Lars-Peter Clausen wrote:
> On 04/13/2013 03:32 PM, Markus Pargmann wrote:
> > On Sun, Apr 07, 2013 at 10:35:02PM +0200, Lars-Peter Clausen wrote:
> >> On 04/07/2013 10:08 PM, Markus Pargmann wrote:
> >>> Hi,
> >>>
> >>> On Sun, Apr 07, 2013 at 09:39:31PM +0200, Lars-Peter Clausen wrote:
> >>>> On 04/07/2013 09:25 PM, Markus Pargmann wrote:
> >>>>> Hi,
> >>>>>
> >>>>> This series adds DT support for phycore-ac97 using the fsl-ssi driver. In
> >>>>> version 2 I discarded most of the imx-ssi work and integrated the ac97-slave
> >>>>> support in fsl-ssi, including support for imx-pcm-fiq as alternative to dma.
> >>>>> There are some other changes to get phycore-ac97 working. The first two patches
> >>>>> have notes about the detailed changes since version 1. The rest of the patches
> >>>>> is new and necessary for the ac97-slave support.
> >>>>>
> >>>>> Regards,
> >>>>>
> >>>>> Markus
> >>>>>
> >>>>
> >>>> Hi,
> >>>>
> >>>> The DMA PCM related changes won't apply anymore due to the recent dmaengine
> >>>> PCM cleanups. I've also been working on a more generic dmaengine PCM driver
> >>>> which has DT support and can be used by imx. The work in progress patches
> >>>> can be found here:
> >>>> https://github.com/lclausen-adi/linux-2.6/commits/asoc-dmaengine-cleanups
> >>>>
> >>>> - Lars
> >>>
> >>> Okay, I will rebase it for v3 onto your committed cleanups and will have
> >>> a look on your latest patches.
> >>>
> >>
> >> It might be a good idea to rebase it ontop of the generic dmaengine driver
> >> patches right away, since it will simplify things quite a bit.
> > 
> > I rebased the series onto your branch now. But there is a small problem
> > with the DMA handling.
> > 
> > Currently you pass the device pointer into snd_dmaengine_pcm_register
> > and use it to request the dma channels. At least for imx-pcm-audio
> > driver, it would be useful to pass a second device just for the dma
> > requests. Otherwise imx-pcm-audio needs devicetree bindings, but I think
> > the dma properties belong to fsl-ssi.
> > 
> 
> I though about that as well, just initialize of_node of the newly allocated
> imx-pcm-audio platform device to that of the parent device. That should work
> nicely.

Okay, I wasn't sure if this is good practice, but then I will do it
like this.

Regards,

Markus

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From thomas.petazzoni at free-electrons.com  Sat Apr 13 10:04:46 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Sat, 13 Apr 2013 16:04:46 +0200
Subject: [PATCHv2 04/10] arm: kirkwood: add SoC-level Device Tree data
 for PCIe interfaces
In-Reply-To: <20130413103057.GG2824@lunn.ch>
References: <1365632436-25367-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1365632436-25367-5-git-send-email-thomas.petazzoni@free-electrons.com>
 <20130413103057.GG2824@lunn.ch>
Message-ID: <20130413160446.4fa00358@skate>

Dear Andrew Lunn,

On Sat, 13 Apr 2013 12:30:57 +0200, Andrew Lunn wrote:
> > diff --git a/arch/arm/boot/dts/kirkwood-6281.dtsi
> > b/arch/arm/boot/dts/kirkwood-6281.dtsi index d6c9d65..5137668 100644
> > --- a/arch/arm/boot/dts/kirkwood-6281.dtsi
> > +++ b/arch/arm/boot/dts/kirkwood-6281.dtsi
> > @@ -40,5 +40,36 @@
> >  				marvell,function = "sdio";
> >  			};
> >  		};
> > +
> > +		pcie-controller {
> 
> Hi Thomas
> 
> Convention seems to be to use _ not - in these names.

As we discussed on IRC, there are quite a number of .dts/.dtsi files
that use '-' in DT node names. Also, the PCIe DT patches for Armada
370/XP have already been merged by Jason with this exact node name. I'm
fine changing it specifically for Kirkwood, but that would make it
inconsistent with what we have for Armada 370/XP.

Jason, what do you think?

Thanks,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From heiko at sntech.de  Sat Apr 13 10:06:47 2013
From: heiko at sntech.de (Heiko =?utf-8?q?St=C3=BCbner?=)
Date: Sat, 13 Apr 2013 16:06:47 +0200
Subject: [PATCH v2] ARM: S3C24XX: add devicetree support for smdk2416
Message-ID: <201304131606.48278.heiko@sntech.de>

Definitions in s3c24xx.dtsi are usable for all s3c24xx SoCs, but some
need to be extended with proper compatible properties, as can be seen
in s3c2416.dtsi .

Signed-off-by: Heiko Stuebner <heiko at sntech.de>
Reviewed-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
---
changes since v1:
  fix compatible property of default irq controller
  (the correct one is samsung,s3c2410-irq)

 arch/arm/boot/dts/Makefile              |    1 +
 arch/arm/boot/dts/s3c2416-pinctrl.dtsi  |  173 +++++++++++++++++++++++++++++++
 arch/arm/boot/dts/s3c2416-smdk2416.dts  |   72 +++++++++++++
 arch/arm/boot/dts/s3c2416.dtsi          |   79 ++++++++++++++
 arch/arm/boot/dts/s3c24xx.dtsi          |   92 ++++++++++++++++
 arch/arm/mach-s3c24xx/Kconfig           |   12 ++
 arch/arm/mach-s3c24xx/Makefile          |    1 +
 arch/arm/mach-s3c24xx/mach-s3c2416-dt.c |   91 ++++++++++++++++
 8 files changed, 521 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/boot/dts/s3c2416-pinctrl.dtsi
 create mode 100644 arch/arm/boot/dts/s3c2416-smdk2416.dts
 create mode 100644 arch/arm/boot/dts/s3c2416.dtsi
 create mode 100644 arch/arm/boot/dts/s3c24xx.dtsi
 create mode 100644 arch/arm/mach-s3c24xx/mach-s3c2416-dt.c

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index d3cd880..4296353 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -137,6 +137,7 @@ dtb-$(CONFIG_ARCH_U8500) += snowball.dtb \
 	hrefprev60.dtb \
 	hrefv60plus.dtb \
 	ccu9540.dtb
+dtb-$(CONFIG_ARCH_S3C24XX) += s3c2416-smdk2416.dtb
 dtb-$(CONFIG_ARCH_SHMOBILE) += emev2-kzm9d.dtb \
 	r8a7740-armadillo800eva.dtb \
 	sh73a0-kzm9g.dtb \
diff --git a/arch/arm/boot/dts/s3c2416-pinctrl.dtsi b/arch/arm/boot/dts/s3c2416-pinctrl.dtsi
new file mode 100644
index 0000000..527e319
--- /dev/null
+++ b/arch/arm/boot/dts/s3c2416-pinctrl.dtsi
@@ -0,0 +1,173 @@
+/*
+ * Samsung S3C2416 pinctrl settings
+ *
+ * Copyright (c) 2013 Heiko Stuebner <heiko at sntech.de>
+ *
+ * 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.
+ */
+
+&pinctrl_0 {
+	/*
+	 * Pin banks
+	 */
+
+	gpa: gpa {
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
+	gpb: gpb {
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
+	gpc: gpc {
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
+	gpd: gpd {
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
+	gpe: gpe {
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
+	gpf: gpf {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpg: gpg {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gph: gph {
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
+	gpj: gpj {
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
+	gpk: gpk {
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
+	gpl: gpl {
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
+	gpm: gpm {
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
+	/*
+	 * Pin groups
+	 */
+
+	uart0_data: uart0-data {
+		samsung,pins = "gph-0", "gph-1";
+		samsung,pin-function = <2>;
+	};
+
+	uart0_fctl: uart0-fctl {
+		samsung,pins = "gph-8", "gph-9";
+		samsung,pin-function = <2>;
+	};
+
+	uart1_data: uart1-data {
+		samsung,pins = "gph-2", "gph-3";
+		samsung,pin-function = <2>;
+	};
+
+	uart1_fctl: uart1-fctl {
+		samsung,pins = "gph-10", "gph-11";
+		samsung,pin-function = <2>;
+	};
+
+	uart2_data: uart2-data {
+		samsung,pins = "gph-4", "gph-5";
+		samsung,pin-function = <2>;
+	};
+
+	uart2_fctl: uart2-fctl {
+		samsung,pins = "gph-6", "gph-7";
+		samsung,pin-function = <2>;
+	};
+
+	uart3_data: uart3-data {
+		samsung,pins = "gph-6", "gph-7";
+		samsung,pin-function = <2>;
+	};
+
+	extuart_clk: extuart-clk {
+		samsung,pins = "gph-12";
+		samsung,pin-function = <2>;
+	};
+
+	i2c0_bus: i2c0-bus {
+		samsung,pins = "gpe-14", "gpe-15";
+		samsung,pin-function = <2>;
+	};
+
+	spi0_bus: spi0-bus {
+		samsung,pins = "gpe-11", "gpe-12", "gpe-13";
+		samsung,pin-function = <2>;
+	};
+
+	sd0_clk: sd0-clk {
+		samsung,pins = "gpe-5";
+		samsung,pin-function = <2>;
+	};
+
+	sd0_cmd: sd0-cmd {
+		samsung,pins = "gpe-6";
+		samsung,pin-function = <2>;
+	};
+
+	sd0_bus1: sd0-bus1 {
+		samsung,pins = "gpe-7";
+		samsung,pin-function = <2>;
+	};
+
+	sd0_bus4: sd0-bus4 {
+		samsung,pins = "gpe-8", "gpe-9", "gpe-10";
+		samsung,pin-function = <2>;
+	};
+
+	sd1_cmd: sd1-cmd {
+		samsung,pins = "gpl-8";
+		samsung,pin-function = <2>;
+	};
+
+	sd1_clk: sd1-clk {
+		samsung,pins = "gpl-9";
+		samsung,pin-function = <2>;
+	};
+
+	sd1_bus1: sd1-bus1 {
+		samsung,pins = "gpl-0";
+		samsung,pin-function = <2>;
+	};
+
+	sd1_bus4: sd1-bus4 {
+		samsung,pins = "gpl-1", "gpl-2", "gpl-3";
+		samsung,pin-function = <2>;
+	};
+};
diff --git a/arch/arm/boot/dts/s3c2416-smdk2416.dts b/arch/arm/boot/dts/s3c2416-smdk2416.dts
new file mode 100644
index 0000000..ad1dd09
--- /dev/null
+++ b/arch/arm/boot/dts/s3c2416-smdk2416.dts
@@ -0,0 +1,72 @@
+/*
+ * SAMSUNG SMDK2416 board device tree source
+ *
+ * Copyright (c) 2013 Heiko Stuebner <heiko at sntech.de>
+ *
+ * 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.
+ */
+
+/dts-v1/;
+/include/ "s3c2416.dtsi"
+
+/ {
+	model = "SMDK2416";
+	compatible = "samsung,s3c2416";
+
+	memory {
+		reg =  <0x30000000 0x4000000>;
+	};
+
+	serial at 50000000 {
+		status = "okay";
+		pinctrl-names = "default";
+		pinctrl-0 = <&uart0_data>, <&uart0_fctl>;
+	};
+
+	serial at 50004000 {
+		status = "okay";
+		pinctrl-names = "default";
+		pinctrl-0 = <&uart1_data>, <&uart1_fctl>;
+	};
+
+	serial at 50008000 {
+		status = "okay";
+		pinctrl-names = "default";
+		pinctrl-0 = <&uart2_data>;
+	};
+
+	serial at 5000C000 {
+		status = "okay";
+		pinctrl-names = "default";
+		pinctrl-0 = <&uart3_data>;
+	};
+
+	watchdog at 53000000 {
+		status = "okay";
+	};
+
+	rtc at 57000000 {
+		status = "okay";
+	};
+
+	sdhci at 4AC00000 {
+		pinctrl-names = "default";
+		pinctrl-0 = <&sd0_clk>, <&sd0_cmd>,
+				<&sd0_bus1>, <&sd0_bus4>;
+		bus-width = <4>;
+		cd-gpios = <&gpf 1 0>;
+		cd-inverted;
+		status = "okay";
+	};
+
+	sdhci at 4A800000 {
+		pinctrl-names = "default";
+		pinctrl-0 = <&sd1_clk>, <&sd1_cmd>,
+				<&sd1_bus1>, <&sd1_bus4>;
+		bus-width = <4>;
+		broken-cd;
+		status = "okay";
+	};
+};
diff --git a/arch/arm/boot/dts/s3c2416.dtsi b/arch/arm/boot/dts/s3c2416.dtsi
new file mode 100644
index 0000000..6809324
--- /dev/null
+++ b/arch/arm/boot/dts/s3c2416.dtsi
@@ -0,0 +1,79 @@
+/*
+ * Samsung's S3C2416 SoC device tree source
+ *
+ * Copyright (c) 2013 Heiko Stuebner <heiko at sntech.de>
+ *
+ * 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/ "s3c24xx.dtsi"
+/include/ "s3c2416-pinctrl.dtsi"
+
+/ {
+	model = "Samsung S3C2416 SoC";
+	compatible = "samsung,s3c2416";
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		cpu {
+			compatible = "arm,arm926ejs";
+		};
+	};
+
+	interrupt-controller at 4a000000 {
+		compatible = "samsung,s3c2416-irq";
+	};
+
+	pinctrl at 56000000 {
+		compatible = "samsung,s3c2416-pinctrl";
+	};
+
+	serial at 50000000 {
+		compatible = "samsung,s3c2440-uart";
+	};
+
+	serial at 50004000 {
+		compatible = "samsung,s3c2440-uart";
+	};
+
+	serial at 50008000 {
+		compatible = "samsung,s3c2440-uart";
+	};
+
+	serial at 5000C000 {
+		compatible = "samsung,s3c2440-uart";
+		reg = <0x5000C000 0x4000>;
+		interrupts = <1 18 24 4>, <1 18 25 4>;
+		status = "disabled";
+	};
+
+	sdhci at 4AC00000 {
+		compatible = "samsung,s3c6410-sdhci";
+		reg = <0x4AC00000 0x100>;
+		interrupts = <0 0 21 3>;
+		status = "disabled";
+	};
+
+	sdhci at 4A800000 {
+		compatible = "samsung,s3c6410-sdhci";
+		reg = <0x4A800000 0x100>;
+		interrupts = <0 0 20 3>;
+		status = "disabled";
+	};
+
+	watchdog at 53000000 {
+		interrupts = <1 9 27 3>;
+	};
+
+	rtc at 57000000 {
+		compatible = "samsung,s3c2416-rtc";
+	};
+
+	i2c at 54000000 {
+		compatible = "samsung,s3c2440-i2c";
+	};
+};
diff --git a/arch/arm/boot/dts/s3c24xx.dtsi b/arch/arm/boot/dts/s3c24xx.dtsi
new file mode 100644
index 0000000..cab46ff
--- /dev/null
+++ b/arch/arm/boot/dts/s3c24xx.dtsi
@@ -0,0 +1,92 @@
+/*
+ * Samsung's S3C24XX family device tree source
+ *
+ * Copyright (c) 2013 Heiko Stuebner <heiko at sntech.de>
+ *
+ * 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/ "skeleton.dtsi"
+
+/ {
+	compatible = "samsung,s3c24xx";
+	interrupt-parent = <&intc>;
+
+	aliases {
+		pinctrl0 = &pinctrl_0;
+	};
+
+	intc:interrupt-controller at 4a000000 {
+		compatible = "samsung,s3c2410-irq";
+		reg = <0x4a000000 0x100>;
+		interrupt-controller;
+		#interrupt-cells = <4>;
+	};
+
+	pinctrl_0: pinctrl at 56000000 {
+		reg = <0x56000000 0x1000>;
+
+		wakeup-interrupt-controller {
+			compatible = "samsung,s3c2410-wakeup-eint";
+			interrupts = <0 0 0 3>,
+				     <0 0 1 3>,
+				     <0 0 2 3>,
+				     <0 0 3 3>,
+				     <0 0 4 4>,
+				     <0 0 5 4>;
+		};
+	};
+
+	timer at 51000000 {
+		compatible = "samsung,s3c2410-pwm";
+		reg = <0x51000000 0x1000>;
+		interrupts = <0 0 10 3>, <0 0 11 3>, <0 0 12 3>, <0 0 13 3>, <0 0 14 3>;
+		#pwm-cells = <4>;
+	};
+
+	serial at 50000000 {
+		compatible = "samsung,s3c2410-uart";
+		reg = <0x50000000 0x4000>;
+		interrupts = <1 28 0 4>, <1 28 1 4>;
+		status = "disabled";
+	};
+
+	serial at 50004000 {
+		compatible = "samsung,s3c2410-uart";
+		reg = <0x50004000 0x4000>;
+		interrupts = <1 23 3 4>, <1 23 4 4>;
+		status = "disabled";
+	};
+
+	serial at 50008000 {
+		compatible = "samsung,s3c2410-uart";
+		reg = <0x50008000 0x4000>;
+		interrupts = <1 15 6 4>, <1 15 7 4>;
+		status = "disabled";
+	};
+
+	watchdog at 53000000 {
+		compatible = "samsung,s3c2410-wdt";
+		reg = <0x53000000 0x100>;
+		interrupts = <0 0 9 3>;
+		status = "disabled";
+	};
+
+	rtc at 57000000 {
+		compatible = "samsung,s3c2410-rtc";
+		reg = <0x57000000 0x100>;
+		interrupts = <0 0 30 3>, <0 0 8 3>;
+		status = "disabled";
+	};
+
+	i2c at 54000000 {
+		compatible = "samsung,s3c2410-i2c";
+		reg = <0x54000000 0x100>;
+		interrupts = <0 0 27 3>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		status = "disabled";
+	};
+};
diff --git a/arch/arm/mach-s3c24xx/Kconfig b/arch/arm/mach-s3c24xx/Kconfig
index 0a8663c..f842e3e 100644
--- a/arch/arm/mach-s3c24xx/Kconfig
+++ b/arch/arm/mach-s3c24xx/Kconfig
@@ -496,6 +496,18 @@ config MACH_SMDK2416
 	help
 	  Say Y here if you are using an SMDK2416
 
+config MACH_S3C2416_DT
+	bool "Samsung S3C2416 machine using devicetree"
+	select CLKSRC_OF
+	select USE_OF
+	select PINCTRL
+	select PINCTRL_S3C24XX
+	help
+	  Machine support for Samsung S3C2416 machines with device tree enabled.
+	  Select this if a fdt blob is available for the S3C2416 SoC based board.
+	  Note: This is under development and not all peripherals can be supported
+	  with this machine file.
+
 endif	# CPU_S3C2416
 
 if CPU_S3C2440
diff --git a/arch/arm/mach-s3c24xx/Makefile b/arch/arm/mach-s3c24xx/Makefile
index 6f46ecf..6de730b 100644
--- a/arch/arm/mach-s3c24xx/Makefile
+++ b/arch/arm/mach-s3c24xx/Makefile
@@ -85,6 +85,7 @@ obj-$(CONFIG_MACH_SMDK2413)		+= mach-smdk2413.o
 obj-$(CONFIG_MACH_VSTMS)		+= mach-vstms.o
 
 obj-$(CONFIG_MACH_SMDK2416)		+= mach-smdk2416.o
+obj-$(CONFIG_MACH_S3C2416_DT)		+= mach-s3c2416-dt.o
 
 obj-$(CONFIG_MACH_ANUBIS)		+= mach-anubis.o
 obj-$(CONFIG_MACH_AT2440EVB)		+= mach-at2440evb.o
diff --git a/arch/arm/mach-s3c24xx/mach-s3c2416-dt.c b/arch/arm/mach-s3c24xx/mach-s3c2416-dt.c
new file mode 100644
index 0000000..f5c9072
--- /dev/null
+++ b/arch/arm/mach-s3c24xx/mach-s3c2416-dt.c
@@ -0,0 +1,91 @@
+/*
+ * Samsung's S3C2416 flattened device tree enabled machine
+ *
+ * Copyright (c) 2012 Heiko Stuebner <heiko at sntech.de>
+ *
+ * based on mach-exynos/mach-exynos4-dt.c
+ *
+ * Copyright (c) 2010-2011 Samsung Electronics Co., Ltd.
+ *		http://www.samsung.com
+ * Copyright (c) 2010-2011 Linaro Ltd.
+ *		www.linaro.org
+ *
+ * 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/clocksource.h>
+#include <linux/irqchip.h>
+#include <linux/of_platform.h>
+#include <linux/serial_core.h>
+
+#include <asm/mach/arch.h>
+#include <mach/map.h>
+
+#include <plat/cpu.h>
+#include <plat/pm.h>
+#include <plat/regs-serial.h>
+
+#include "common.h"
+
+/*
+ * The following lookup table is used to override device names when devices
+ * are registered from device tree. This is temporarily added to enable
+ * device tree support addition for the S3C2416 architecture.
+ *
+ * For drivers that require platform data to be provided from the machine
+ * file, a platform data pointer can also be supplied along with the
+ * devices names. Usually, the platform data elements that cannot be parsed
+ * from the device tree by the drivers (example: function pointers) are
+ * supplied. But it should be noted that this is a temporary mechanism and
+ * at some point, the drivers should be capable of parsing all the platform
+ * data from the device tree.
+ */
+static const struct of_dev_auxdata s3c2416_auxdata_lookup[] __initconst = {
+	OF_DEV_AUXDATA("samsung,s3c2440-uart", S3C2410_PA_UART0,
+				"s3c2440-uart.0", NULL),
+	OF_DEV_AUXDATA("samsung,s3c2440-uart", S3C2410_PA_UART1,
+				"s3c2440-uart.1", NULL),
+	OF_DEV_AUXDATA("samsung,s3c2440-uart", S3C2410_PA_UART2,
+				"s3c2440-uart.2", NULL),
+	OF_DEV_AUXDATA("samsung,s3c2440-uart", S3C2443_PA_UART3,
+				"s3c2440-uart.3", NULL),
+	OF_DEV_AUXDATA("samsung,s3c6410-sdhci", S3C_PA_HSMMC0,
+				"s3c-sdhci.0", NULL),
+	OF_DEV_AUXDATA("samsung,s3c6410-sdhci", S3C_PA_HSMMC1,
+				"s3c-sdhci.1", NULL),
+	OF_DEV_AUXDATA("samsung,s3c2440-i2c", S3C_PA_IIC,
+				"s3c2440-i2c.0", NULL),
+	{},
+};
+
+static void __init s3c2416_dt_map_io(void)
+{
+	s3c24xx_init_io(NULL, 0);
+	s3c24xx_init_clocks(12000000);
+}
+
+static void __init s3c2416_dt_machine_init(void)
+{
+	of_platform_populate(NULL, of_default_bus_match_table,
+				s3c2416_auxdata_lookup, NULL);
+
+	s3c_pm_init();
+}
+
+static char const *s3c2416_dt_compat[] __initdata = {
+	"samsung,s3c2416",
+	"samsung,s3c2450",
+	NULL
+};
+
+DT_MACHINE_START(S3C2416_DT, "Samsung S3C2416 (Flattened Device Tree)")
+	/* Maintainer: Heiko Stuebner <heiko at sntech.de> */
+	.dt_compat	= s3c2416_dt_compat,
+	.map_io		= s3c2416_dt_map_io,
+	.init_irq	= irqchip_init,
+	.init_machine	= s3c2416_dt_machine_init,
+	 .init_time	= clocksource_of_init,
+	.restart	= s3c2416_restart,
+MACHINE_END
-- 
1.7.2.3



From thomas.petazzoni at free-electrons.com  Sat Apr 13 10:56:35 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Sat, 13 Apr 2013 16:56:35 +0200
Subject: [PATCHv3 00/10] Use the mvebu PCIe driver on Kirkwood
Message-ID: <1365865005-26653-1-git-send-email-thomas.petazzoni@free-electrons.com>

Hello,

Here is a set of patches that migrates adds support for Kirkwood
platforms to use the mvebu PCIe driver. All the Kirkwood platforms
that have already been converted to the Device Tree are converted to
use the new driver, and the DB-88F6281 evaluation board from Marvell
is also converted to the Device Tree and the usage of the new PCIe
driver.

Only non-DT platforms continue to use the legacy code in
arch/arm/mach-kirkwood/pcie.c.

This branch depends on the mvebu-mbus driver and the mvebu-pcie
driver. I have pushed this branch to the following Git repository for
easier testing:

  https://github.com/MISL-EBU-System-SW/mainline-public/tree/kirkwood-pcie-dt-v3

# /usr/sbin/lspci
00:01.0 PCI bridge: Marvell Technology Group Ltd. Device 7846
00:02.0 PCI bridge: Marvell Technology Group Ltd. Device 7846
01:00.0 SCSI storage controller: Marvell Technology Group Ltd. 88SX7042 PCI-e 4-port SATA-II (rev 02)
02:00.0 Ethernet controller: Intel Corporation 82572EI Gigabit Ethernet Controller (Copper) (rev 06)

# cat /proc/cpuinfo | grep ^Hardware
Hardware	: Marvell Kirkwood (Flattened Device Tree)

I've tested both the e1000e NIC card and the SATA 4 ports card and
they work fine.

Changes between v2 and v3:

 * Integrate a replacement patch from Andrew Lunn for the QNAP changes
   after he tested on his hardware platform.

 * Add Andrew Lunn Tested-by tags on the appropriate patches.

Changes between v1 and v2:

 * Remove the 'needs_pcie_win' logic, and instead move the static
   initialization of PCIe windows into the legacy PCIe code, for the
   platforms that will still be using it. Platforms that will use the
   new PCIe driver benefit directly from dynamic allocation of PCIe
   windows.

 * Move the PCIe interface definitions from kirkwood.dtsi to
   kirkwood-6281.dtsi and kirkwood-6282.dtsi to take into account the
   fact that the 6281 has one PCIe interface, and the 6282 has two of
   them.

 * Convert all DT-platforms that were initializing PCIe using the
   legacy driver to use the DT to initialize the PCIe interface. This
   includes the Iomega Iconnect, the MPL CEC4, the ZyXEL NSA310and the
   QNAP TS219.

 * Fix the conversion to the Device Tree of the DB-88F6181/6282
   board. We now have two Device Trees, one for the 6281 variant of
   the board (one PCIe interface) and another for the 6282 variant of
   the board (two PCIe interfaces).

 * Update the defconfig with PCIe driver enabled and some board
   updates.

Best regards,

Thomas

Thomas Petazzoni (10):
  pci: mvebu: enable driver usage on Kirkwood
  bus: mvebu: fix mistake in PCIe window target attribute for Kirkwood
  arm: kirkwood: move PCIe window init to legacy driver
  arm: kirkwood: add SoC-level Device Tree data for PCIe interfaces
  arm: kirkwood: convert Iomega Iconnect to use DT for the PCIe
    interface
  arm: kirkwood: convert MPL CEC4 to use DT for the PCIe interface
  arm: kirkwood: convert ZyXEL NSA310 to use DT for the PCIe interface
  arm: kirkwood: convert QNAP TS219 to use DT for the PCIe interface
  arm: kirkwood: convert db-88f6281 to the Device Tree
  arm: kirkwood: update defconfig with PCIe driver and board updates

 .../devicetree/bindings/pci/mvebu-pci.txt          |    1 +
 arch/arm/boot/dts/Makefile                         |    5 +-
 arch/arm/boot/dts/kirkwood-6281.dtsi               |   31 ++++++
 arch/arm/boot/dts/kirkwood-6282.dtsi               |   48 +++++++++
 arch/arm/boot/dts/kirkwood-db-88f6281.dts          |   30 ++++++
 arch/arm/boot/dts/kirkwood-db-88f6282.dts          |   34 ++++++
 arch/arm/boot/dts/kirkwood-db.dtsi                 |   89 ++++++++++++++++
 arch/arm/boot/dts/kirkwood-iconnect.dts            |    8 ++
 arch/arm/boot/dts/kirkwood-mplcec4.dts             |    8 ++
 arch/arm/boot/dts/kirkwood-nsa310.dts              |    8 ++
 arch/arm/boot/dts/kirkwood-ts219-6281.dts          |    3 +-
 arch/arm/boot/dts/kirkwood-ts219-6282.dts          |    3 +-
 arch/arm/boot/dts/kirkwood-ts219.dtsi              |    9 +-
 arch/arm/boot/dts/kirkwood.dtsi                    |    1 +
 arch/arm/configs/kirkwood_defconfig                |    6 +-
 arch/arm/mach-kirkwood/Kconfig                     |   21 ++--
 arch/arm/mach-kirkwood/Makefile                    |    3 +-
 arch/arm/mach-kirkwood/board-db88f6281-bp.c        |   26 +++++
 arch/arm/mach-kirkwood/board-dt.c                  |    2 +
 arch/arm/mach-kirkwood/board-iconnect.c            |    8 --
 arch/arm/mach-kirkwood/board-mplcec4.c             |    1 -
 arch/arm/mach-kirkwood/board-nsa310.c              |   25 -----
 arch/arm/mach-kirkwood/board-ts219.c               |   10 --
 arch/arm/mach-kirkwood/common.c                    |   24 -----
 arch/arm/mach-kirkwood/common.h                    |    6 ++
 arch/arm/mach-kirkwood/db88f6281-bp-setup.c        |  108 --------------------
 arch/arm/mach-kirkwood/pcie.c                      |   22 ++++
 drivers/bus/mvebu-mbus.c                           |    2 +-
 drivers/pci/host/Kconfig                           |    2 +-
 drivers/pci/host/pci-mvebu.c                       |    1 +
 30 files changed, 343 insertions(+), 202 deletions(-)
 create mode 100644 arch/arm/boot/dts/kirkwood-db-88f6281.dts
 create mode 100644 arch/arm/boot/dts/kirkwood-db-88f6282.dts
 create mode 100644 arch/arm/boot/dts/kirkwood-db.dtsi
 create mode 100644 arch/arm/mach-kirkwood/board-db88f6281-bp.c
 delete mode 100644 arch/arm/mach-kirkwood/board-nsa310.c
 delete mode 100644 arch/arm/mach-kirkwood/db88f6281-bp-setup.c

-- 
1.7.9.5



From thomas.petazzoni at free-electrons.com  Sat Apr 13 10:56:36 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Sat, 13 Apr 2013 16:56:36 +0200
Subject: [PATCHv3 01/10] pci: mvebu: enable driver usage on Kirkwood
In-Reply-To: <1365865005-26653-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1365865005-26653-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1365865005-26653-2-git-send-email-thomas.petazzoni@free-electrons.com>

We allow the pci-mvebu driver to be compiled on the Kirkwood platform,
and add the 'marvell,kirkwood-pcie' as a compatible string supported
by the driver.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Tested-by: Andrew Lunn <andrew at lunn.ch>
---
 .../devicetree/bindings/pci/mvebu-pci.txt          |    1 +
 drivers/pci/host/Kconfig                           |    2 +-
 drivers/pci/host/pci-mvebu.c                       |    1 +
 3 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/pci/mvebu-pci.txt b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
index eb69d92..f8d4058 100644
--- a/Documentation/devicetree/bindings/pci/mvebu-pci.txt
+++ b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
@@ -4,6 +4,7 @@ Mandatory properties:
 - compatible: one of the following values:
     marvell,armada-370-pcie
     marvell,armada-xp-pcie
+    marvell,kirkwood-pcie
 - #address-cells, set to <3>
 - #size-cells, set to <2>
 - #interrupt-cells, set to <1>
diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index 6918fbc..1f1d67f 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -3,6 +3,6 @@ menu "PCI host controller drivers"
 
 config PCI_MVEBU
 	bool "Marvell EBU PCIe controller"
-	depends on ARCH_MVEBU
+	depends on ARCH_MVEBU || ARCH_KIRKWOOD
 
 endmenu
diff --git a/drivers/pci/host/pci-mvebu.c b/drivers/pci/host/pci-mvebu.c
index 9c15a25..a083d19 100644
--- a/drivers/pci/host/pci-mvebu.c
+++ b/drivers/pci/host/pci-mvebu.c
@@ -853,6 +853,7 @@ static int __init mvebu_pcie_probe(struct platform_device *pdev)
 static const struct of_device_id mvebu_pcie_of_match_table[] = {
 	{ .compatible = "marvell,armada-xp-pcie", },
 	{ .compatible = "marvell,armada-370-pcie", },
+	{ .compatible = "marvell,kirkwood-pcie", },
 	{},
 };
 MODULE_DEVICE_TABLE(of, mvebu_pcie_of_match_table);
-- 
1.7.9.5



From thomas.petazzoni at free-electrons.com  Sat Apr 13 10:56:37 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Sat, 13 Apr 2013 16:56:37 +0200
Subject: [PATCHv3 02/10] bus: mvebu: fix mistake in PCIe window target
 attribute for Kirkwood
In-Reply-To: <1365865005-26653-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1365865005-26653-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1365865005-26653-3-git-send-email-thomas.petazzoni@free-electrons.com>

The target and attributes for the PCIe address decoding windows were
not correct on Kirkwood for the second PCIe interface.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Tested-by: Andrew Lunn <andrew at lunn.ch>
---
Note: this patch should be merged with the existing mvebu-mbus driver.
---
 drivers/bus/mvebu-mbus.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
index 586d03e..4de2c6b 100644
--- a/drivers/bus/mvebu-mbus.c
+++ b/drivers/bus/mvebu-mbus.c
@@ -626,7 +626,7 @@ static const struct mvebu_mbus_soc_data armada_xp_mbus_data = {
 
 static const struct mvebu_mbus_mapping kirkwood_map[] = {
 	MAPDEF("pcie0.0", 4, 0xe0, MAPDEF_PCIMASK),
-	MAPDEF("pcie1.0", 8, 0xe0, MAPDEF_PCIMASK),
+	MAPDEF("pcie1.0", 4, 0xd0, MAPDEF_PCIMASK),
 	MAPDEF("sram",    3, 0x01, MAPDEF_NOMASK),
 	MAPDEF("nand",    1, 0x2f, MAPDEF_NOMASK),
 	{},
-- 
1.7.9.5



From thomas.petazzoni at free-electrons.com  Sat Apr 13 10:56:38 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Sat, 13 Apr 2013 16:56:38 +0200
Subject: [PATCHv3 03/10] arm: kirkwood: move PCIe window init to legacy driver
In-Reply-To: <1365865005-26653-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1365865005-26653-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1365865005-26653-4-git-send-email-thomas.petazzoni@free-electrons.com>

Since we are going to enable the usage of the mvebu PCIe driver on
Kirkwood, we don't want the PCIe windows to be unconditionally created
by kirkwood_setup_wins(). Therefore, we move the PCIe window
initialization into the legacy PCIe driver
(arch/arm/mach-kirkwood/pcie.c).

The platforms using the legacy driver will see their windows
statically allocated by
arch/arm/mach-kirkwood/pcie.c:kirkwood_pcie_init(). The platforms
using the new driver in drivers/pci/ will see their windows
dynamically allocated directly by the driver.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Tested-by: Andrew Lunn <andrew at lunn.ch>
---
 arch/arm/mach-kirkwood/common.c |   24 ------------------------
 arch/arm/mach-kirkwood/pcie.c   |   22 ++++++++++++++++++++++
 2 files changed, 22 insertions(+), 24 deletions(-)

diff --git a/arch/arm/mach-kirkwood/common.c b/arch/arm/mach-kirkwood/common.c
index c2cae69..9b0b901 100644
--- a/arch/arm/mach-kirkwood/common.c
+++ b/arch/arm/mach-kirkwood/common.c
@@ -654,30 +654,6 @@ char * __init kirkwood_id(void)
 
 void __init kirkwood_setup_wins(void)
 {
-	/*
-	 * The PCIe windows will no longer be statically allocated
-	 * here once Kirkwood is migrated to the pci-mvebu driver.
-	 */
-	mvebu_mbus_add_window_remap_flags("pcie0.0",
-					  KIRKWOOD_PCIE_IO_PHYS_BASE,
-					  KIRKWOOD_PCIE_IO_SIZE,
-					  KIRKWOOD_PCIE_IO_BUS_BASE,
-					  MVEBU_MBUS_PCI_IO);
-	mvebu_mbus_add_window_remap_flags("pcie0.0",
-					  KIRKWOOD_PCIE_MEM_PHYS_BASE,
-					  KIRKWOOD_PCIE_MEM_SIZE,
-					  MVEBU_MBUS_NO_REMAP,
-					  MVEBU_MBUS_PCI_MEM);
-	mvebu_mbus_add_window_remap_flags("pcie1.0",
-					  KIRKWOOD_PCIE1_IO_PHYS_BASE,
-					  KIRKWOOD_PCIE1_IO_SIZE,
-					  KIRKWOOD_PCIE1_IO_BUS_BASE,
-					  MVEBU_MBUS_PCI_IO);
-	mvebu_mbus_add_window_remap_flags("pcie1.0",
-					  KIRKWOOD_PCIE1_MEM_PHYS_BASE,
-					  KIRKWOOD_PCIE1_MEM_SIZE,
-					  MVEBU_MBUS_NO_REMAP,
-					  MVEBU_MBUS_PCI_MEM);
 	mvebu_mbus_add_window("nand", KIRKWOOD_NAND_MEM_PHYS_BASE,
 			      KIRKWOOD_NAND_MEM_SIZE);
 	mvebu_mbus_add_window("sram", KIRKWOOD_SRAM_PHYS_BASE,
diff --git a/arch/arm/mach-kirkwood/pcie.c b/arch/arm/mach-kirkwood/pcie.c
index 7f43e6c..ddcb09f 100644
--- a/arch/arm/mach-kirkwood/pcie.c
+++ b/arch/arm/mach-kirkwood/pcie.c
@@ -12,6 +12,7 @@
 #include <linux/pci.h>
 #include <linux/slab.h>
 #include <linux/clk.h>
+#include <linux/mbus.h>
 #include <video/vga.h>
 #include <asm/irq.h>
 #include <asm/mach/pci.h>
@@ -253,6 +254,27 @@ static void __init add_pcie_port(int index, void __iomem *base)
 
 void __init kirkwood_pcie_init(unsigned int portmask)
 {
+	mvebu_mbus_add_window_remap_flags("pcie0.0",
+					  KIRKWOOD_PCIE_IO_PHYS_BASE,
+					  KIRKWOOD_PCIE_IO_SIZE,
+					  KIRKWOOD_PCIE_IO_BUS_BASE,
+					  MVEBU_MBUS_PCI_IO);
+	mvebu_mbus_add_window_remap_flags("pcie0.0",
+					  KIRKWOOD_PCIE_MEM_PHYS_BASE,
+					  KIRKWOOD_PCIE_MEM_SIZE,
+					  MVEBU_MBUS_NO_REMAP,
+					  MVEBU_MBUS_PCI_MEM);
+	mvebu_mbus_add_window_remap_flags("pcie1.0",
+					  KIRKWOOD_PCIE1_IO_PHYS_BASE,
+					  KIRKWOOD_PCIE1_IO_SIZE,
+					  KIRKWOOD_PCIE1_IO_BUS_BASE,
+					  MVEBU_MBUS_PCI_IO);
+	mvebu_mbus_add_window_remap_flags("pcie1.0",
+					  KIRKWOOD_PCIE1_MEM_PHYS_BASE,
+					  KIRKWOOD_PCIE1_MEM_SIZE,
+					  MVEBU_MBUS_NO_REMAP,
+					  MVEBU_MBUS_PCI_MEM);
+
 	vga_base = KIRKWOOD_PCIE_MEM_PHYS_BASE;
 
 	if (portmask & KW_PCIE0)
-- 
1.7.9.5



From thomas.petazzoni at free-electrons.com  Sat Apr 13 10:56:39 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Sat, 13 Apr 2013 16:56:39 +0200
Subject: [PATCHv3 04/10] arm: kirkwood: add SoC-level Device Tree data for
 PCIe interfaces
In-Reply-To: <1365865005-26653-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1365865005-26653-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1365865005-26653-5-git-send-email-thomas.petazzoni@free-electrons.com>

This commit adds Device Tree details to enable the PCIe interfaces on
Kirkwood. The 6281 has one PCIe interface, the 6282 has two PCIe
interfaces.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Tested-by: Andrew Lunn <andrew at lunn.ch>
---
 arch/arm/boot/dts/kirkwood-6281.dtsi |   31 ++++++++++++++++++++++
 arch/arm/boot/dts/kirkwood-6282.dtsi |   48 ++++++++++++++++++++++++++++++++++
 arch/arm/boot/dts/kirkwood.dtsi      |    1 +
 3 files changed, 80 insertions(+)

diff --git a/arch/arm/boot/dts/kirkwood-6281.dtsi b/arch/arm/boot/dts/kirkwood-6281.dtsi
index d6c9d65..5137668 100644
--- a/arch/arm/boot/dts/kirkwood-6281.dtsi
+++ b/arch/arm/boot/dts/kirkwood-6281.dtsi
@@ -40,5 +40,36 @@
 				marvell,function = "sdio";
 			};
 		};
+
+		pcie-controller {
+			compatible = "marvell,kirkwood-pcie";
+			status = "disabled";
+			device_type = "pci";
+
+			#address-cells = <3>;
+			#size-cells = <2>;
+
+			bus-range = <0x00 0xff>;
+
+			ranges = <0x82000000 0 0x00040000 0x00040000 0 0x00002000   /* Port 0.0 registers */
+				  0x82000000 0 0xe0000000 0xe0000000 0 0x08000000   /* non-prefetchable memory */
+			          0x81000000 0 0          0xe8000000 0 0x00100000>; /* downstream I/O */
+
+			pcie at 1,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82000800 0 0x00040000 0 0x2000>;
+				reg = <0x0800 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &intc 9>;
+				marvell,pcie-port = <0>;
+				marvell,pcie-lane = <0>;
+				clocks = <&gate_clk 2>;
+				status = "disabled";
+			};
+		};
 	};
 };
diff --git a/arch/arm/boot/dts/kirkwood-6282.dtsi b/arch/arm/boot/dts/kirkwood-6282.dtsi
index 192cf76..00a698e 100644
--- a/arch/arm/boot/dts/kirkwood-6282.dtsi
+++ b/arch/arm/boot/dts/kirkwood-6282.dtsi
@@ -59,5 +59,53 @@
 			clocks = <&gate_clk 7>;
 			status = "disabled";
 		};
+
+		pcie-controller {
+			compatible = "marvell,kirkwood-pcie";
+			status = "disabled";
+			device_type = "pci";
+
+			#address-cells = <3>;
+			#size-cells = <2>;
+
+			bus-range = <0x00 0xff>;
+
+			ranges = <0x82000000 0 0x00040000 0x00040000 0 0x00002000   /* Port 0.0 registers */
+			          0x82000000 0 0x00044000 0x00044000 0 0x00002000   /* Port 1.0 registers */
+				  0x82000000 0 0xe0000000 0xe0000000 0 0x08000000   /* non-prefetchable memory */
+			          0x81000000 0 0          0xe8000000 0 0x00100000>; /* downstream I/O */
+
+			pcie at 1,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82000800 0 0x00040000 0 0x2000>;
+				reg = <0x0800 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &intc 9>;
+				marvell,pcie-port = <0>;
+				marvell,pcie-lane = <0>;
+				clocks = <&gate_clk 2>;
+				status = "disabled";
+			};
+
+			pcie at 2,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82001000 0 0x00044000 0 0x2000>;
+				reg = <0x1000 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &intc 10>;
+				marvell,pcie-port = <1>;
+				marvell,pcie-lane = <0>;
+				clocks = <&gate_clk 18>;
+				status = "disabled";
+			};
+		};
 	};
 };
diff --git a/arch/arm/boot/dts/kirkwood.dtsi b/arch/arm/boot/dts/kirkwood.dtsi
index 2c738d9..8aae1cf 100644
--- a/arch/arm/boot/dts/kirkwood.dtsi
+++ b/arch/arm/boot/dts/kirkwood.dtsi
@@ -19,6 +19,7 @@
 	ocp at f1000000 {
 		compatible = "simple-bus";
 		ranges = <0x00000000 0xf1000000 0x4000000
+		          0xe0000000 0xe0000000 0x8100000 /* PCIE */
 		          0xf5000000 0xf5000000 0x0000400>;
 		#address-cells = <1>;
 		#size-cells = <1>;
-- 
1.7.9.5



From thomas.petazzoni at free-electrons.com  Sat Apr 13 10:56:40 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Sat, 13 Apr 2013 16:56:40 +0200
Subject: [PATCHv3 05/10] arm: kirkwood: convert Iomega Iconnect to use DT for
 the PCIe interface
In-Reply-To: <1365865005-26653-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1365865005-26653-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1365865005-26653-6-git-send-email-thomas.petazzoni@free-electrons.com>

Now that the PCIe mvebu driver is usable on Kirkwood, use it instead
of the legacy PCIe code, since it allows to describe the PCIe
interfaces in the Device Tree.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 arch/arm/boot/dts/kirkwood-iconnect.dts |    8 ++++++++
 arch/arm/mach-kirkwood/board-iconnect.c |    8 --------
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/arch/arm/boot/dts/kirkwood-iconnect.dts b/arch/arm/boot/dts/kirkwood-iconnect.dts
index 504f16b..4c8f0df 100644
--- a/arch/arm/boot/dts/kirkwood-iconnect.dts
+++ b/arch/arm/boot/dts/kirkwood-iconnect.dts
@@ -110,6 +110,14 @@
 				reg = <0x980000 0x1f400000>;
 			};
 		};
+
+		pcie-controller {
+			status = "okay";
+
+			pcie at 1,0 {
+				status = "okay";
+			};
+		};
 	};
 
 	gpio-leds {
diff --git a/arch/arm/mach-kirkwood/board-iconnect.c b/arch/arm/mach-kirkwood/board-iconnect.c
index c8ebde4..98b5ad1 100644
--- a/arch/arm/mach-kirkwood/board-iconnect.c
+++ b/arch/arm/mach-kirkwood/board-iconnect.c
@@ -22,11 +22,3 @@ void __init iconnect_init(void)
 {
 	kirkwood_ge00_init(&iconnect_ge00_data);
 }
-
-static int __init iconnect_pci_init(void)
-{
-	if (of_machine_is_compatible("iom,iconnect"))
-		kirkwood_pcie_init(KW_PCIE0);
-	return 0;
-}
-subsys_initcall(iconnect_pci_init);
-- 
1.7.9.5



From thomas.petazzoni at free-electrons.com  Sat Apr 13 10:56:41 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Sat, 13 Apr 2013 16:56:41 +0200
Subject: [PATCHv3 06/10] arm: kirkwood: convert MPL CEC4 to use DT for the
 PCIe interface
In-Reply-To: <1365865005-26653-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1365865005-26653-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1365865005-26653-7-git-send-email-thomas.petazzoni@free-electrons.com>

Now that the PCIe mvebu driver is usable on Kirkwood, use it instead
of the legacy PCIe code, since it allows to describe the PCIe
interfaces in the Device Tree.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 arch/arm/boot/dts/kirkwood-mplcec4.dts |    8 ++++++++
 arch/arm/mach-kirkwood/board-mplcec4.c |    1 -
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/kirkwood-mplcec4.dts b/arch/arm/boot/dts/kirkwood-mplcec4.dts
index 662dfd8..080f28e 100644
--- a/arch/arm/boot/dts/kirkwood-mplcec4.dts
+++ b/arch/arm/boot/dts/kirkwood-mplcec4.dts
@@ -140,6 +140,14 @@
 			cd-gpios = <&gpio1 15 0>;
 			/* No WP GPIO */
 		};
+
+		pcie-controller {
+			status = "okay";
+
+			pcie at 1,0 {
+				status = "okay";
+			};
+		};
 	};
 
 	gpio-leds {
diff --git a/arch/arm/mach-kirkwood/board-mplcec4.c b/arch/arm/mach-kirkwood/board-mplcec4.c
index 7d6dc66..938712e 100644
--- a/arch/arm/mach-kirkwood/board-mplcec4.c
+++ b/arch/arm/mach-kirkwood/board-mplcec4.c
@@ -29,7 +29,6 @@ void __init mplcec4_init(void)
 	 */
 	kirkwood_ge00_init(&mplcec4_ge00_data);
 	kirkwood_ge01_init(&mplcec4_ge01_data);
-	kirkwood_pcie_init(KW_PCIE0);
 }
 
 
-- 
1.7.9.5



From thomas.petazzoni at free-electrons.com  Sat Apr 13 10:56:42 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Sat, 13 Apr 2013 16:56:42 +0200
Subject: [PATCHv3 07/10] arm: kirkwood: convert ZyXEL NSA310 to use DT for the
 PCIe interface
In-Reply-To: <1365865005-26653-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1365865005-26653-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1365865005-26653-8-git-send-email-thomas.petazzoni@free-electrons.com>

Now that the PCIe mvebu driver is usable on Kirkwood, use it instead
of the legacy PCIe code, since it allows to describe the PCIe
interfaces in the Device Tree.

Since it was the only device left that prevented this platform to use
the Device Tree only, we remove the board-nsa310.c file and the
related Kconfig/Makefile bits.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 arch/arm/boot/dts/kirkwood-nsa310.dts |    8 ++++++++
 arch/arm/mach-kirkwood/Kconfig        |    8 --------
 arch/arm/mach-kirkwood/Makefile       |    1 -
 arch/arm/mach-kirkwood/board-nsa310.c |   25 -------------------------
 4 files changed, 8 insertions(+), 34 deletions(-)
 delete mode 100644 arch/arm/mach-kirkwood/board-nsa310.c

diff --git a/arch/arm/boot/dts/kirkwood-nsa310.dts b/arch/arm/boot/dts/kirkwood-nsa310.dts
index 3a178cf..1cd15ba 100644
--- a/arch/arm/boot/dts/kirkwood-nsa310.dts
+++ b/arch/arm/boot/dts/kirkwood-nsa310.dts
@@ -177,6 +177,14 @@
 				reg = <0x5040000 0x2fc0000>;
 			};
 		};
+
+		pcie-controller {
+			status = "okay";
+
+			pcie at 1,0 {
+				status = "okay";
+			};
+		};
 	};
 
 	gpio_keys {
diff --git a/arch/arm/mach-kirkwood/Kconfig b/arch/arm/mach-kirkwood/Kconfig
index 7b6a64b..1fe5f2f 100644
--- a/arch/arm/mach-kirkwood/Kconfig
+++ b/arch/arm/mach-kirkwood/Kconfig
@@ -287,14 +287,6 @@ config MACH_T5325
 	  Say 'Y' here if you want your kernel to support the
 	  HP t5325 Thin Client.
 
-config MACH_NSA310_DT
-	bool "ZyXEL NSA-310 (Flattened Device Tree)"
-	select ARCH_KIRKWOOD_DT
-	select ARM_ATAG_DTB_COMPAT
-	help
-	  Say 'Y' here if you want your kernel to support the
-	  ZyXEL NSA-310 board (Flattened Device Tree).
-
 endmenu
 
 endif
diff --git a/arch/arm/mach-kirkwood/Makefile b/arch/arm/mach-kirkwood/Makefile
index d805f80..0e5ccad 100644
--- a/arch/arm/mach-kirkwood/Makefile
+++ b/arch/arm/mach-kirkwood/Makefile
@@ -37,6 +37,5 @@ obj-$(CONFIG_MACH_NETSPACE_V2_DT)	+= board-ns2.o
 obj-$(CONFIG_MACH_NETSPACE_MAX_V2_DT)	+= board-ns2.o
 obj-$(CONFIG_MACH_NETSPACE_LITE_V2_DT)	+= board-ns2.o
 obj-$(CONFIG_MACH_NETSPACE_MINI_V2_DT)	+= board-ns2.o
-obj-$(CONFIG_MACH_NSA310_DT)		+= board-nsa310.o
 obj-$(CONFIG_MACH_OPENBLOCKS_A6_DT)	+= board-openblocks_a6.o
 obj-$(CONFIG_MACH_TOPKICK_DT)		+= board-usi_topkick.o
diff --git a/arch/arm/mach-kirkwood/board-nsa310.c b/arch/arm/mach-kirkwood/board-nsa310.c
deleted file mode 100644
index 55ade93..0000000
--- a/arch/arm/mach-kirkwood/board-nsa310.c
+++ /dev/null
@@ -1,25 +0,0 @@
-/*
- * arch/arm/mach-kirkwood/nsa-310-setup.c
- *
- * ZyXEL NSA-310 Setup
- *
- * 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/kernel.h>
-#include <linux/init.h>
-#include <mach/kirkwood.h>
-#include <linux/of.h>
-#include "common.h"
-
-static int __init nsa310_pci_init(void)
-{
-	if (of_machine_is_compatible("zyxel,nsa310"))
-		kirkwood_pcie_init(KW_PCIE0);
-
-	return 0;
-}
-
-subsys_initcall(nsa310_pci_init);
-- 
1.7.9.5



From thomas.petazzoni at free-electrons.com  Sat Apr 13 10:56:43 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Sat, 13 Apr 2013 16:56:43 +0200
Subject: [PATCHv3 08/10] arm: kirkwood: convert QNAP TS219 to use DT for the
 PCIe interface
In-Reply-To: <1365865005-26653-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1365865005-26653-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1365865005-26653-9-git-send-email-thomas.petazzoni@free-electrons.com>

Now that the PCIe mvebu driver is usable on Kirkwood, use it instead
of the legacy PCIe code, since it allows to describe the PCIe
interfaces in the Device Tree.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Signed-off-by: Andrew Lunn <andrew at lunn.ch>
Tested-by: Andrew Lunn <andrew at lunn.ch>
---
 arch/arm/boot/dts/kirkwood-ts219-6281.dts |    3 ++-
 arch/arm/boot/dts/kirkwood-ts219-6282.dts |    3 ++-
 arch/arm/boot/dts/kirkwood-ts219.dtsi     |    9 +++++++--
 arch/arm/mach-kirkwood/board-ts219.c      |   10 ----------
 4 files changed, 11 insertions(+), 14 deletions(-)

diff --git a/arch/arm/boot/dts/kirkwood-ts219-6281.dts b/arch/arm/boot/dts/kirkwood-ts219-6281.dts
index 8295c83..42648ab 100644
--- a/arch/arm/boot/dts/kirkwood-ts219-6281.dts
+++ b/arch/arm/boot/dts/kirkwood-ts219-6281.dts
@@ -1,7 +1,8 @@
 /dts-v1/;
 
-/include/ "kirkwood-ts219.dtsi"
+/include/ "kirkwood.dtsi"
 /include/ "kirkwood-6281.dtsi"
+/include/ "kirkwood-ts219.dtsi"
 
 / {
 	ocp at f1000000 {
diff --git a/arch/arm/boot/dts/kirkwood-ts219-6282.dts b/arch/arm/boot/dts/kirkwood-ts219-6282.dts
index df3f95d..95ceeb9 100644
--- a/arch/arm/boot/dts/kirkwood-ts219-6282.dts
+++ b/arch/arm/boot/dts/kirkwood-ts219-6282.dts
@@ -1,7 +1,8 @@
 /dts-v1/;
 
-/include/ "kirkwood-ts219.dtsi"
+/include/ "kirkwood.dtsi"
 /include/ "kirkwood-6282.dtsi"
+/include/ "kirkwood-ts219.dtsi"
 
 / {
 	ocp at f1000000 {
diff --git a/arch/arm/boot/dts/kirkwood-ts219.dtsi b/arch/arm/boot/dts/kirkwood-ts219.dtsi
index 64ea27c..7c022fd 100644
--- a/arch/arm/boot/dts/kirkwood-ts219.dtsi
+++ b/arch/arm/boot/dts/kirkwood-ts219.dtsi
@@ -1,5 +1,3 @@
-/include/ "kirkwood.dtsi"
-
 / {
 	model = "QNAP TS219 family";
 	compatible = "qnap,ts219", "marvell,kirkwood";
@@ -74,5 +72,12 @@
 			status = "okay";
 			nr-ports = <2>;
 		};
+		pcie-controller {
+			status = "okay";
+
+			pcie at 1,0 {
+				status = "okay";
+			};
+		};
 	};
 };
diff --git a/arch/arm/mach-kirkwood/board-ts219.c b/arch/arm/mach-kirkwood/board-ts219.c
index acb0187..4695d5f 100644
--- a/arch/arm/mach-kirkwood/board-ts219.c
+++ b/arch/arm/mach-kirkwood/board-ts219.c
@@ -41,13 +41,3 @@ void __init qnap_dt_ts219_init(void)
 
 	pm_power_off = qnap_tsx1x_power_off;
 }
-
-/* FIXME: Will not work with DT. Maybe use MPP40_GPIO? */
-static int __init ts219_pci_init(void)
-{
-	if (machine_is_ts219())
-		kirkwood_pcie_init(KW_PCIE0);
-
-	return 0;
-}
-subsys_initcall(ts219_pci_init);
-- 
1.7.9.5



From thomas.petazzoni at free-electrons.com  Sat Apr 13 10:56:45 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Sat, 13 Apr 2013 16:56:45 +0200
Subject: [PATCHv3 10/10] arm: kirkwood: update defconfig with PCIe driver and
 board updates
In-Reply-To: <1365865005-26653-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1365865005-26653-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1365865005-26653-11-git-send-email-thomas.petazzoni@free-electrons.com>

This commit enables the mvebu PCIe driver in kirkwood_defconfig and
updates various options related to Kirkwood boards.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 arch/arm/configs/kirkwood_defconfig |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/configs/kirkwood_defconfig b/arch/arm/configs/kirkwood_defconfig
index 13482ea..c5275ea 100644
--- a/arch/arm/configs/kirkwood_defconfig
+++ b/arch/arm/configs/kirkwood_defconfig
@@ -10,13 +10,13 @@ CONFIG_MODULES=y
 CONFIG_MODULE_UNLOAD=y
 # CONFIG_BLK_DEV_BSG is not set
 CONFIG_ARCH_KIRKWOOD=y
-CONFIG_MACH_DB88F6281_BP=y
 CONFIG_MACH_RD88F6192_NAS=y
 CONFIG_MACH_RD88F6281=y
 CONFIG_MACH_MV88F6281GTW_GE=y
 CONFIG_MACH_SHEEVAPLUG=y
 CONFIG_MACH_ESATA_SHEEVAPLUG=y
-CONFIG_MACH_GURUPLUG=y
+CONFIG_MACH_DB88F6281_BP_DT=y
+CONFIG_MACH_GURUPLUG_DT=y
 CONFIG_MACH_DREAMPLUG_DT=y
 CONFIG_MACH_ICONNECT_DT=y
 CONFIG_MACH_DLINK_KIRKWOOD_DT=y
@@ -48,8 +48,8 @@ CONFIG_MACH_D2NET_V2=y
 CONFIG_MACH_NET2BIG_V2=y
 CONFIG_MACH_NET5BIG_V2=y
 CONFIG_MACH_T5325=y
-CONFIG_MACH_NSA310_DT=y
 # CONFIG_CPU_FEROCEON_OLD_ID is not set
+CONFIG_PCI_MVEBU=y
 CONFIG_PREEMPT=y
 CONFIG_AEABI=y
 # CONFIG_OABI_COMPAT is not set
-- 
1.7.9.5



From thomas.petazzoni at free-electrons.com  Sat Apr 13 10:56:44 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Sat, 13 Apr 2013 16:56:44 +0200
Subject: [PATCHv3 09/10] arm: kirkwood: convert db-88f6281 to the Device Tree
In-Reply-To: <1365865005-26653-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1365865005-26653-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1365865005-26653-10-git-send-email-thomas.petazzoni@free-electrons.com>

This commit converts the Marvell DB-88F6281/DB-88F6282 board to the
Device Tree. In fact, the code was supporting two different boards:
one with the 6281 SoC variant, and one with the 6282 SoC variant. The
difference between the two being that the 6281 has one PCIe interface,
and the 6282 has two PCIe interfaces.

In order to handle that with the Device Tree, we create a
'kirkwood-db.dtsi' file that contains the definitions common to both
boards, and 'kirkwood-db-88f6281.dts' and 'kirkwood-db-88f6282.dts'
for the definitions specific to each board. This is similar to what is
done for the QNAP TS219 Kirkwood platform.

We have kept one single Kconfig option, just like it was before.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 arch/arm/boot/dts/Makefile                  |    5 +-
 arch/arm/boot/dts/kirkwood-db-88f6281.dts   |   30 ++++++++
 arch/arm/boot/dts/kirkwood-db-88f6282.dts   |   34 +++++++++
 arch/arm/boot/dts/kirkwood-db.dtsi          |   89 ++++++++++++++++++++++
 arch/arm/mach-kirkwood/Kconfig              |   13 ++--
 arch/arm/mach-kirkwood/Makefile             |    2 +-
 arch/arm/mach-kirkwood/board-db88f6281-bp.c |   26 +++++++
 arch/arm/mach-kirkwood/board-dt.c           |    2 +
 arch/arm/mach-kirkwood/common.h             |    6 ++
 arch/arm/mach-kirkwood/db88f6281-bp-setup.c |  108 ---------------------------
 10 files changed, 199 insertions(+), 116 deletions(-)
 create mode 100644 arch/arm/boot/dts/kirkwood-db-88f6281.dts
 create mode 100644 arch/arm/boot/dts/kirkwood-db-88f6282.dts
 create mode 100644 arch/arm/boot/dts/kirkwood-db.dtsi
 create mode 100644 arch/arm/mach-kirkwood/board-db88f6281-bp.c
 delete mode 100644 arch/arm/mach-kirkwood/db88f6281-bp-setup.c

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 9c62558..f28a23e 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -51,7 +51,10 @@ dtb-$(CONFIG_ARCH_HIGHBANK) += highbank.dtb \
 dtb-$(CONFIG_ARCH_INTEGRATOR) += integratorap.dtb \
 	integratorcp.dtb
 dtb-$(CONFIG_ARCH_LPC32XX) += ea3250.dtb phy3250.dtb
-dtb-$(CONFIG_ARCH_KIRKWOOD) += kirkwood-dns320.dtb \
+dtb-$(CONFIG_ARCH_KIRKWOOD) += \
+	kirkwood-db-88f6281.dtb \
+	kirkwood-db-88f6282.dtb \
+	kirkwood-dns320.dtb \
 	kirkwood-dns325.dtb \
 	kirkwood-dockstar.dtb \
 	kirkwood-dreamplug.dtb \
diff --git a/arch/arm/boot/dts/kirkwood-db-88f6281.dts b/arch/arm/boot/dts/kirkwood-db-88f6281.dts
new file mode 100644
index 0000000..9d777ed
--- /dev/null
+++ b/arch/arm/boot/dts/kirkwood-db-88f6281.dts
@@ -0,0 +1,30 @@
+/*
+ * Marvell DB-88F6281-BP Development Board Setup
+ *
+ * Saeed Bishara <saeed at marvell.com>
+ * Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
+ *
+ * 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.
+ */
+
+/dts-v1/;
+
+/include/ "kirkwood-db.dtsi"
+/include/ "kirkwood-6281.dtsi"
+
+/ {
+	model = "Marvell DB-88F6281-BP Development Board";
+	compatible = "marvell,db-88f6281-bp", "marvell,kirkwood-88f6281", "marvell,kirkwood";
+
+	ocp at f1000000 {
+		pcie-controller {
+			status = "okay";
+
+			pcie at 1,0 {
+				status = "okay";
+			};
+		};
+	};
+};
diff --git a/arch/arm/boot/dts/kirkwood-db-88f6282.dts b/arch/arm/boot/dts/kirkwood-db-88f6282.dts
new file mode 100644
index 0000000..f4c8528
--- /dev/null
+++ b/arch/arm/boot/dts/kirkwood-db-88f6282.dts
@@ -0,0 +1,34 @@
+/*
+ * Marvell DB-88F6282-BP Development Board Setup
+ *
+ * Saeed Bishara <saeed at marvell.com>
+ * Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
+ *
+ * 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.
+ */
+
+/dts-v1/;
+
+/include/ "kirkwood-db.dtsi"
+/include/ "kirkwood-6282.dtsi"
+
+/ {
+	model = "Marvell DB-88F6282-BP Development Board";
+	compatible = "marvell,db-88f6282-bp", "marvell,kirkwood-88f6282", "marvell,kirkwood";
+
+	ocp at f1000000 {
+		pcie-controller {
+			status = "okay";
+
+			pcie at 1,0 {
+				status = "okay";
+			};
+
+			pcie at 2,0 {
+				status = "okay";
+			};
+		};
+	};
+};
diff --git a/arch/arm/boot/dts/kirkwood-db.dtsi b/arch/arm/boot/dts/kirkwood-db.dtsi
new file mode 100644
index 0000000..c87cfb8
--- /dev/null
+++ b/arch/arm/boot/dts/kirkwood-db.dtsi
@@ -0,0 +1,89 @@
+/*
+ * Marvell DB-{88F6281,88F6282}-BP Development Board Setup
+ *
+ * Saeed Bishara <saeed at marvell.com>
+ * Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
+ *
+ * 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.
+ *
+ * This file contains the definitions that are common between the 6281
+ * and 6282 variants of the Marvell Kirkwood Development Board.
+ */
+
+/include/ "kirkwood.dtsi"
+
+/ {
+	memory {
+		device_type = "memory";
+		reg = <0x00000000 0x20000000>; /* 512 MB */
+	};
+
+	chosen {
+		bootargs = "console=ttyS0,115200n8 earlyprintk";
+	};
+
+	ocp at f1000000 {
+		pinctrl at 10000 {
+			pmx_sdio_gpios: pmx-sdio-gpios {
+				marvell,pins = "mpp37", "mpp38";
+				marvell,function = "gpio";
+			};
+		};
+
+		serial at 12000 {
+			pinctrl-0 = <&pmx_uart0>;
+			pinctrl-names = "default";
+			clock-frequency = <200000000>;
+			status = "ok";
+		};
+
+		nand at 3000000 {
+			pinctrl-0 = <&pmx_nand>;
+			pinctrl-names = "default";
+			chip-delay = <25>;
+			status = "okay";
+
+			partition at 0 {
+				label = "uboot";
+				reg = <0x0 0x100000>;
+			};
+
+			partition at 100000 {
+				label = "uImage";
+				reg = <0x100000 0x400000>;
+			};
+
+			partition at 500000 {
+				label = "root";
+				reg = <0x500000 0x1fb00000>;
+			};
+		};
+
+		sata at 80000 {
+			nr-ports = <2>;
+			status = "okay";
+		};
+
+		ehci at 50000 {
+			status = "okay";
+		};
+
+		mvsdio at 90000 {
+			pinctrl-0 = <&pmx_sdio_gpios>;
+			pinctrl-names = "default";
+			wp-gpios = <&gpio1 5 0>;
+			cd-gpios = <&gpio1 6 0>;
+			status = "okay";
+		};
+
+		pcie-controller {
+			status = "okay";
+
+			pcie at 1,0 {
+				status = "okay";
+			};
+		};
+	};
+};
diff --git a/arch/arm/mach-kirkwood/Kconfig b/arch/arm/mach-kirkwood/Kconfig
index 1fe5f2f..b09afca 100644
--- a/arch/arm/mach-kirkwood/Kconfig
+++ b/arch/arm/mach-kirkwood/Kconfig
@@ -2,12 +2,6 @@ if ARCH_KIRKWOOD
 
 menu "Marvell Kirkwood Implementations"
 
-config MACH_DB88F6281_BP
-	bool "Marvell DB-88F6281-BP Development Board"
-	help
-	  Say 'Y' here if you want your kernel to support the
-	  Marvell DB-88F6281-BP Development Board.
-
 config MACH_RD88F6192_NAS
 	bool "Marvell RD-88F6192-NAS Reference Board"
 	help
@@ -58,6 +52,13 @@ config ARCH_KIRKWOOD_DT
 	  Say 'Y' here if you want your kernel to support the
 	  Marvell Kirkwood using flattened device tree.
 
+config MACH_DB88F6281_BP_DT
+	bool "Marvell DB-88F6281-BP Development Board (Flattened Device Tree)"
+	help
+	  Say 'Y' here if you want your kernel to support the Marvell
+	  DB-88F6281-BP and DB-88F6282-BP Development Board (Flattened
+	  Device Tree).
+
 config MACH_GURUPLUG_DT
 	bool "Marvell GuruPlug Reference Board (Flattened Device Tree)"
 	select ARCH_KIRKWOOD_DT
diff --git a/arch/arm/mach-kirkwood/Makefile b/arch/arm/mach-kirkwood/Makefile
index 0e5ccad..e6a88ab 100644
--- a/arch/arm/mach-kirkwood/Makefile
+++ b/arch/arm/mach-kirkwood/Makefile
@@ -1,6 +1,5 @@
 obj-y				+= common.o irq.o pcie.o mpp.o
 
-obj-$(CONFIG_MACH_DB88F6281_BP)		+= db88f6281-bp-setup.o
 obj-$(CONFIG_MACH_RD88F6192_NAS)	+= rd88f6192-nas-setup.o
 obj-$(CONFIG_MACH_RD88F6281)		+= rd88f6281-setup.o
 obj-$(CONFIG_MACH_MV88F6281GTW_GE)	+= mv88f6281gtw_ge-setup.o
@@ -20,6 +19,7 @@ obj-$(CONFIG_MACH_NET5BIG_V2)		+= netxbig_v2-setup.o lacie_v2-common.o
 obj-$(CONFIG_MACH_T5325)		+= t5325-setup.o
 
 obj-$(CONFIG_ARCH_KIRKWOOD_DT)		+= board-dt.o
+obj-$(CONFIG_MACH_DB88F6281_BP_DT)	+= board-db88f6281-bp.o
 obj-$(CONFIG_MACH_DREAMPLUG_DT)		+= board-dreamplug.o
 obj-$(CONFIG_MACH_GURUPLUG_DT)		+= board-guruplug.o
 obj-$(CONFIG_MACH_ICONNECT_DT)		+= board-iconnect.o
diff --git a/arch/arm/mach-kirkwood/board-db88f6281-bp.c b/arch/arm/mach-kirkwood/board-db88f6281-bp.c
new file mode 100644
index 0000000..bffd160
--- /dev/null
+++ b/arch/arm/mach-kirkwood/board-db88f6281-bp.c
@@ -0,0 +1,26 @@
+/*
+ * arch/arm/mach-kirkwood/db88f6281-bp-setup.c
+ *
+ * Saeed Bishara <saeed at marvell.com>
+ *
+ * Marvell DB-88F6281-BP Development Board Setup
+ *
+ * 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/kernel.h>
+#include <linux/init.h>
+#include <linux/of.h>
+#include <linux/mv643xx_eth.h>
+#include "common.h"
+
+static struct mv643xx_eth_platform_data db88f6281_ge00_data = {
+	.phy_addr	= MV643XX_ETH_PHY_ADDR(8),
+};
+
+void __init db88f6281_init(void)
+{
+	kirkwood_ge00_init(&db88f6281_ge00_data);
+}
diff --git a/arch/arm/mach-kirkwood/board-dt.c b/arch/arm/mach-kirkwood/board-dt.c
index ea49476..b6cb807 100644
--- a/arch/arm/mach-kirkwood/board-dt.c
+++ b/arch/arm/mach-kirkwood/board-dt.c
@@ -165,6 +165,8 @@ static const char * const kirkwood_dt_board_compat[] = {
 	"lacie,netspace_v2",
 	"lacie,netspace_lite_v2",
 	"lacie,netspace_mini_v2",
+	"marvell,db-88f6281-bp",
+	"marvell,db-88f6282-bp",
 	"mpl,cec4",
 	"plathome,openblocks-a6",
 	"usi,topkick",
diff --git a/arch/arm/mach-kirkwood/common.h b/arch/arm/mach-kirkwood/common.h
index e24f743..d174ab5 100644
--- a/arch/arm/mach-kirkwood/common.h
+++ b/arch/arm/mach-kirkwood/common.h
@@ -119,6 +119,12 @@ void km_kirkwood_init(void);
 static inline void km_kirkwood_init(void) {};
 #endif
 
+#ifdef CONFIG_MACH_DB88F6281_BP_DT
+void db88f6281_init(void);
+#else
+static inline void db88f6281_init(void) {};
+#endif
+
 #ifdef CONFIG_MACH_MPLCEC4_DT
 void mplcec4_init(void);
 #else
diff --git a/arch/arm/mach-kirkwood/db88f6281-bp-setup.c b/arch/arm/mach-kirkwood/db88f6281-bp-setup.c
deleted file mode 100644
index 5a369fe..0000000
--- a/arch/arm/mach-kirkwood/db88f6281-bp-setup.c
+++ /dev/null
@@ -1,108 +0,0 @@
-/*
- * arch/arm/mach-kirkwood/db88f6281-bp-setup.c
- *
- * Marvell DB-88F6281-BP Development Board Setup
- *
- * 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/kernel.h>
-#include <linux/init.h>
-#include <linux/sizes.h>
-#include <linux/platform_device.h>
-#include <linux/mtd/partitions.h>
-#include <linux/ata_platform.h>
-#include <linux/mv643xx_eth.h>
-#include <asm/mach-types.h>
-#include <asm/mach/arch.h>
-#include <mach/kirkwood.h>
-#include <linux/platform_data/mmc-mvsdio.h>
-#include "common.h"
-#include "mpp.h"
-
-static struct mtd_partition db88f6281_nand_parts[] = {
-	{
-		.name = "u-boot",
-		.offset = 0,
-		.size = SZ_1M
-	}, {
-		.name = "uImage",
-		.offset = MTDPART_OFS_NXTBLK,
-		.size = SZ_4M
-	}, {
-		.name = "root",
-		.offset = MTDPART_OFS_NXTBLK,
-		.size = MTDPART_SIZ_FULL
-	},
-};
-
-static struct mv643xx_eth_platform_data db88f6281_ge00_data = {
-	.phy_addr	= MV643XX_ETH_PHY_ADDR(8),
-};
-
-static struct mv_sata_platform_data db88f6281_sata_data = {
-	.n_ports	= 2,
-};
-
-static struct mvsdio_platform_data db88f6281_mvsdio_data = {
-	.gpio_write_protect	= 37,
-	.gpio_card_detect	= 38,
-};
-
-static unsigned int db88f6281_mpp_config[] __initdata = {
-	MPP0_NF_IO2,
-	MPP1_NF_IO3,
-	MPP2_NF_IO4,
-	MPP3_NF_IO5,
-	MPP4_NF_IO6,
-	MPP5_NF_IO7,
-	MPP18_NF_IO0,
-	MPP19_NF_IO1,
-	MPP37_GPIO,
-	MPP38_GPIO,
-	0
-};
-
-static void __init db88f6281_init(void)
-{
-	/*
-	 * Basic setup. Needs to be called early.
-	 */
-	kirkwood_init();
-	kirkwood_mpp_conf(db88f6281_mpp_config);
-
-	kirkwood_nand_init(ARRAY_AND_SIZE(db88f6281_nand_parts), 25);
-	kirkwood_ehci_init();
-	kirkwood_ge00_init(&db88f6281_ge00_data);
-	kirkwood_sata_init(&db88f6281_sata_data);
-	kirkwood_uart0_init();
-	kirkwood_sdio_init(&db88f6281_mvsdio_data);
-}
-
-static int __init db88f6281_pci_init(void)
-{
-	if (machine_is_db88f6281_bp()) {
-		u32 dev, rev;
-
-		kirkwood_pcie_id(&dev, &rev);
-		if (dev == MV88F6282_DEV_ID)
-			kirkwood_pcie_init(KW_PCIE1 | KW_PCIE0);
-		else
-			kirkwood_pcie_init(KW_PCIE0);
-	}
-	return 0;
-}
-subsys_initcall(db88f6281_pci_init);
-
-MACHINE_START(DB88F6281_BP, "Marvell DB-88F6281-BP Development Board")
-	/* Maintainer: Saeed Bishara <saeed at marvell.com> */
-	.atag_offset	= 0x100,
-	.init_machine	= db88f6281_init,
-	.map_io		= kirkwood_map_io,
-	.init_early	= kirkwood_init_early,
-	.init_irq	= kirkwood_init_irq,
-	.init_time	= kirkwood_timer_init,
-	.restart	= kirkwood_restart,
-MACHINE_END
-- 
1.7.9.5



From thomas.petazzoni at free-electrons.com  Sat Apr 13 11:21:26 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Sat, 13 Apr 2013 17:21:26 +0200
Subject: [PATCH 0/5 v2] mv643xx_eth: device tree bindings
In-Reply-To: <20130411165303.GI28693@titan.lakedaemon.net>
References: <1365071235-11611-1-git-send-email-florian@openwrt.org>
 <20130411165303.GI28693@titan.lakedaemon.net>
Message-ID: <20130413172126.6cca0809@skate>

Dear Jason Cooper,

On Thu, 11 Apr 2013 12:53:03 -0400, Jason Cooper wrote:

> With this and Thomas' pci series, we will have Kirkwood fully
> converted to devicetree, can begin removing board files, and finally
> begin migrating everything over to mach-mvebu/.  This will lead to
> the removal of five directories under arch/arm/ (plat-orion,
> mach-kirkwood, mach-orion5x, mach-dove, and mach-mv78xx0).

No, we can't remove mach-orion5x and mach-mv78xx0 for now, they have
not been converted at all in terms of gpio/pinmux support. I've started
writing some pinmux code for orion5x but it's not ready.

I don't think we should rush in doing this merge into mach-mvebu. I'd
prefer to have the following conditions be met before a platform gets
merged into mach-mvebu:

 * The mach-<foo> directory no longer depends on anything in
   plat-orion. For mach-kirkwood, things are OK (for the DT platforms)
   for GPIO, MPP and PCIe, but some work remains for the IRQ controller
   driver and the timer driver.

 * All boards have been converted to the Device Tree. For
   mach-kirkwood, we're getting closer.

Once a given mach-<foo> platform meets these conditions, it will be a
clean platform, and we can merge it into mach-mvebu without any
problem.

So let's continue the cleanup work, conversion to DT, usage of drivers
in drivers/, improvement of pinmux to support orion5x/mv78xx0, and do
the move per-platform, once they are ready.

What do you think?

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From liuj97 at gmail.com  Sat Apr 13 11:36:35 2013
From: liuj97 at gmail.com (Jiang Liu)
Date: Sat, 13 Apr 2013 23:36:35 +0800
Subject: [RFC PATCH v1 15/19] mm/ARM: fix stale comment about VALID_PAGE()
In-Reply-To: <1365867399-21323-1-git-send-email-jiang.liu@huawei.com>
References: <1365867399-21323-1-git-send-email-jiang.liu@huawei.com>
Message-ID: <1365867399-21323-16-git-send-email-jiang.liu@huawei.com>

VALID_PAGE() has been removed from kernel long time ago,
so fix the comment.

Signed-off-by: Jiang Liu <jiang.liu at huawei.com>
Cc: Russell King <linux at arm.linux.org.uk>
Cc: Will Deacon <will.deacon at arm.com>
Cc: Nicolas Pitre <nico at linaro.org>
Cc: Stephen Boyd <sboyd at codeaurora.org>
Cc: Giancarlo Asnaghi <giancarlo.asnaghi at st.com>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
---
 arch/arm/include/asm/memory.h |    6 ------
 1 file changed, 6 deletions(-)

diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
index 57870ab..0cd2a3d 100644
--- a/arch/arm/include/asm/memory.h
+++ b/arch/arm/include/asm/memory.h
@@ -260,12 +260,6 @@ static inline __deprecated void *bus_to_virt(unsigned long x)
 /*
  * Conversion between a struct page and a physical address.
  *
- * Note: when converting an unknown physical address to a
- * struct page, the resulting pointer must be validated
- * using VALID_PAGE().  It must return an invalid struct page
- * for any physical address not corresponding to a system
- * RAM address.
- *
  *  page_to_pfn(page)	convert a struct page * to a PFN number
  *  pfn_to_page(pfn)	convert a _valid_ PFN number to struct page *
  *
-- 
1.7.9.5



From s.hauer at pengutronix.de  Sat Apr 13 13:09:43 2013
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Sat, 13 Apr 2013 19:09:43 +0200
Subject: [PATCH v2 3/4] ARM: dts: mx53qsb: Add support for parallel display
In-Reply-To: <CAOkaPuV2xNR=Vxsa6tPdnPS34Q5ffV9-f8DefhcJfvVvXWOADQ@mail.gmail.com>
References: <1365516452-1287-1-git-send-email-rogerio.pimentel@freescale.com>
 <1365516452-1287-3-git-send-email-rogerio.pimentel@freescale.com>
 <1365520643.4023.52.camel@pizza.hi.pengutronix.de>
 <CAOkaPuV2xNR=Vxsa6tPdnPS34Q5ffV9-f8DefhcJfvVvXWOADQ@mail.gmail.com>
Message-ID: <20130413170943.GX1906@pengutronix.de>

On Fri, Apr 12, 2013 at 03:49:09PM -0300, Rogerio Pimentel wrote:
> On Tue, Apr 9, 2013 at 12:17 PM, Philipp Zabel <p.zabel at pengutronix.de> wrote:
> > Am Dienstag, den 09.04.2013, 11:07 -0300 schrieb Rogerio Pimentel:
> >> Add support for CLAA WVGA display for i.MX53 QSB.
> >>
> >> Signed-off-by: Rogerio Pimentel <rogerio.pimentel at freescale.com>
> >> ---
> >> Changes since v1:
> >> Changed the label disp1 to disp0 to correctly match the display pins
> >>  arch/arm/boot/dts/imx53-qsb.dtsp |   26 ++++++++++++++++++++++++++
> >>  arch/arm/boot/dts/imx53.dtsip    |   35 +++++++++++++++++++++++++++++++++++
> >>  2 files changed, 61 insertions(+)
> >>
> >> diff --git a/arch/arm/boot/dts/imx53-qsb.dtsp b/arch/arm/boot/dts/imx53-qsb.dtsp
> >> index dae8d9f..6086a3c 100644
> >> --- a/arch/arm/boot/dts/imx53-qsb.dtsp
> >> +++ b/arch/arm/boot/dts/imx53-qsb.dtsp
> >> @@ -21,6 +21,32 @@
> >>               reg = <0x70000000 0x40000000>;
> >>       };
> >>
> >> +     display at di0 {
> >> +             compatible = "fsl,imx-parallel-display";
> >> +             crtcs = <&ipu 0>;
> >> +             interface-pix-fmt = "rgb565";
> >> +             pinctrl-names = "default";
> >> +             pinctrl-0 = <&pinctrl_ipu_disp0_1>;
> >> +             display-timings {
> >> +                     claawvga {
> >> +                             native-mode;
> >> +                             clock-frequency = <27000000>;
> >> +                             hactive = <800>;
> >> +                             vactive = <480>;
> >> +                             hback-porch = <40>;
> >> +                             hfront-porch = <60>;
> >> +                             vback-porch = <10>;
> >> +                             vfront-porch = <10>;
> >> +                             hsync-len = <20>;
> >> +                             vsync-len = <10>;
> >> +                             hsync-active = <0>;
> >> +                             vsync-active = <0>;
> >> +                             de-active = <1>;
> >> +                             pixelclk-active = <0>;
> >> +                     };
> >> +             };
> >> +     };
> >> +
> >
> > This clashes with the MCIMXHDMICARD daughter module, which has a sii902x
> > HDMI encoder connected to DISP0 for i.MX53-QSB. Would it make sense to
> > add all possible options to the device tree but mark them with
> > status = "disabled" by default?
> >
> > regards
> > Philipp
> >
> I'm planning to add support for MCIMXHDMICARD later because it will also
> require support for sii902x. I'd like to add the parallel display that
> we have available
> today and after that add the support for sii902x. What do you think?

Having the parallel display support is fine. Philipp just suggested to
add status = "disabled" for both the parallel display and the lvds
encoder so that for example the bootloader can decide which one to enable
during runtime. Otherwise we have two display options on the same pins and
the first one wins.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From tony at atomide.com  Sat Apr 13 13:22:10 2013
From: tony at atomide.com (Tony Lindgren)
Date: Sat, 13 Apr 2013 10:22:10 -0700
Subject: [PATCH V4 1/6] clk: OMAP: introduce device tree binding to
 kernel clock data
In-Reply-To: <20130412233900.GA1599@kahuna>
References: <1365807278-554-1-git-send-email-nm@ti.com>
 <1365807278-554-2-git-send-email-nm@ti.com>
 <20130412233142.GE10155@atomide.com> <20130412233900.GA1599@kahuna>
Message-ID: <20130413172210.GM10155@atomide.com>

* Nishanth Menon <nm at ti.com> [130412 16:43]:
> Thanks for checking up. Fixed all of them below, will post part of
> series again, only if I need to address further comments in other
> patches..

Thanks it seems that the other ones are ready to go, just one
more comment below.

> --- /dev/null
> +++ b/drivers/clk/omap/clk.c
> @@ -0,0 +1,95 @@
> +/*
> + * Texas Instruments OMAP Clock driver
> + *
> + * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
> + *	Nishanth Menon <nm at ti.com>
> + *	Tony Lindgren <tony at atomide.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.
> + *
> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
> + * kind, whether express or implied; without even the implied warranty
> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include <linux/clkdev.h>
> +#include <linux/clk-provider.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/of_device.h>
> +#include <linux/platform_device.h>
> +#include <linux/string.h>
> +
> +static const struct of_device_id omap_clk_of_match[] = {
> +	{.compatible = "ti,omap-clock",},
> +	{},
> +};
> +
> +/**
> + * omap_clk_src_get() - Get OMAP clock from node name when needed
> + * @clkspec:	clkspec argument
> + * @data:	unused
> + *
> + * REVISIT: We assume the following:
> + * 1. omap clock names end with _ck
> + * 2. omap clock names are under 32 characters in length
> + */
> +static struct clk *omap_clk_src_get(struct of_phandle_args *clkspec, void *data)
> +{
> +	struct clk *clk;
> +	char clk_name[32];
> +	struct device_node *np = clkspec->np;
> +
> +	snprintf(clk_name, 32, "%s_ck", np->name);
> +	clk = clk_get(NULL, clk_name);
> +	if (IS_ERR(clk)) {
> +		pr_err("%s: could not get clock %s(%ld)\n", __func__,
> +		       clk_name, PTR_ERR(clk));
> +		goto out;
> +	}
> +	clk_put(clk);

It seems that clk_put() is actually wrong here. That's because
of_clk_get() should boild down to just the look up of the clock 
and then clk_get() on it, so no double clk_get() is done in this
case. Once the consumer driver is done, it will just call clk_put()
on it.

> +out:
> +	return clk;
> +}
> +
> +/**
> + * omap_clk_probe() - create link from DT definition to clock data
> + * @pdev:	device node
> + *
> + * NOTE: we look up the clock lazily when the consumer driver does
> + * of_clk_get() and initialize a NULL clock here.
> + */
> +static int omap_clk_probe(struct platform_device *pdev)
> +{
> +	int res;
> +	struct device_node *np = pdev->dev.of_node;
> +
> +	/* This allows the driver to of_clk_get() */
> +	res = of_clk_add_provider(np, omap_clk_src_get, NULL);
> +	if (res)
> +		dev_err(&pdev->dev, "could not add provider(%d)\n", res);
> +
> +	return res;
> +}
> +
> +static struct platform_driver omap_clk_driver = {
> +	.probe = omap_clk_probe,
> +	.driver = {
> +		   .name = "omap_clk",
> +		   .of_match_table = of_match_ptr(omap_clk_of_match),
> +		   },
> +};
> +
> +static int __init omap_clk_init(void)
> +{
> +	return platform_driver_register(&omap_clk_driver);
> +}
> +arch_initcall(omap_clk_init);
> +
> +MODULE_DESCRIPTION("OMAP Clock driver");
> +MODULE_AUTHOR("Texas Instruments Inc.");
> +MODULE_LICENSE("GPL v2");

Other than that looks OK to me.

Tony


From chf.fritz at googlemail.com  Sat Apr 13 13:42:16 2013
From: chf.fritz at googlemail.com (Christoph Fritz)
Date: Sat, 13 Apr 2013 19:42:16 +0200
Subject: [RFC][BUG] arm/dts: OMAP3: set #interrupt-cells to two
In-Reply-To: <CAAwP0s1H9zaBZPMDz9=He-E68UK0Ay3jnxZ2frYH9r1xNeQhxQ@mail.gmail.com>
References: <1364631689.3767.7.camel@mars>
 <CAAwP0s35J-edpvFv08xjjpwaezQBYNvMNhhXL-UacsuUtSt4ZA@mail.gmail.com>
 <1364834508.3939.74.camel@mars>
 <CAAwP0s1H9zaBZPMDz9=He-E68UK0Ay3jnxZ2frYH9r1xNeQhxQ@mail.gmail.com>
Message-ID: <1365874936.3812.65.camel@mars>

On Mon, 2013-04-01 at 22:05 +0200, Javier Martinez Canillas wrote:
> On Mon, Apr 1, 2013 at 6:41 PM, Christoph Fritz
> > As a quick-fix (hack) I wrote directly to the registers in gpio_probe()
> > to enable GPIO banks. I now geht this:
> >
> >> > [    0.214630] omap_gpio_probe, 1133, CM_CLKSEL_PER 0x48005040: 0x000000ff
> >> > [    0.214660] omap_gpio_probe, 1136, CM_ICLKEN_PER 0x48005010: 0x0007ffff
> >> > [    0.214660] omap_gpio_probe, 1139, CM_FCLKEN_PER 0x48005000: 0x0007ffff
> >
> > And it works for me. _But_ when I do enable regulator twl4030
> > (CONFIG_REGULATOR_TWL4030=y) in my config these registers get reset:
> >
> > [    2.935455] smsc911x_open, 1537, CM_CLKSEL_PER 0x48005040: 0x000000ff
> > [    2.942291] smsc911x_open, 1540, CM_ICLKEN_PER 0x48005010: 0x00040fff
> > [    2.949066] smsc911x_open, 1543, CM_FCLKEN_PER 0x48005000: 0x00000000
> >
> > And the IRQ source for the network chip (smsc911x) is disabled :-(
> >
> > Do you have any idea how to ("quick") fix this?
> >
> 
> A quick hack is to call gpio_request() explicitly before calling to
> irq_set_type() is made.
> I've this patch just to make it work until we find a clean solution:
> 
> diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
> index 90c15ee..d594e1d 100644
> --- a/arch/arm/mach-omap2/gpmc.c
> +++ b/arch/arm/mach-omap2/gpmc.c
> @@ -14,6 +14,7 @@
>   */
>  #undef DEBUG
> 
> +#include <linux/gpio.h>
>  #include <linux/irq.h>
>  #include <linux/kernel.h>
>  #include <linux/init.h>
> @@ -1528,6 +1529,11 @@ static int gpmc_probe_dt(struct platform_device *pdev)
>                 return ret;
>         }
> 
> +       ret = gpio_request_one(176, GPIOF_IN, "smsc911x irq");
> +       if (ret) {
> +               pr_err("Failed to request IRQ GPIO%d\n", 176);
> +               return ret;
> +       }
> +
>         for_each_node_by_name(child, "nand") {
>                 ret = gpmc_probe_nand_child(pdev, child);
>                 if (ret < 0) {
> 
> This solves the issue of the non-initialized GPIO bank before that
> makes the kernel to hang. Since I've to configure the IRQ polarity as
> active low level-sensitive on my board and the flags are not set by
> the IRQ core, I've another ugly hack that forces this:
> 
> diff --git a/drivers/net/ethernet/smsc/smsc911x.c
> b/drivers/net/ethernet/smsc/smsc
> index da5cc9a..27e46f9 100644
> --- a/drivers/net/ethernet/smsc/smsc911x.c
> +++ b/drivers/net/ethernet/smsc/smsc911x.c
> @@ -2390,6 +2390,9 @@ static int smsc911x_drv_probe(struct
> platform_device *pdev)
>         pdata = netdev_priv(dev);
>         dev->irq = irq_res->start;
> -        irq_flags = irq_res->flags & IRQF_TRIGGER_MASK;
> +       irq_flags = IRQF_TRIGGER_LOW;
>         pdata->ioaddr = ioremap_nocache(res->start, res_size);
> 
>         pdata->dev = dev;
> 
> >  Thanks
> >   -- Christoph
> >
> 
> I hope to find some time this week to work on this and at least find a
> solution for the second issue (IORESOURCE_IRQ struct resource flags
> not being set).

Any updates on this issue?

For me it works when doing this in the device tree:

+&omap3_pmx_wkup {
+	pinctrl-names = "default";
+
+	lan9221_pins: pinmux_lan9221_pins {
+		pinctrl-single,pins = <
+			0x5A 0x104	/* gpio_129, INPUT | MODE4 */
+		>;
+	};
+};
+
<SNIP>
+	lan9221 at 15000000 {
+		compatible = "smsc,lan9221", "smsc,lan9115";
+		reg = <0x15000000 0x400>;
+		phy-mode = "mii";
+		interrupt-parent = <&gpio5>;
+		interrupts = <1 0x2>;	/* gpio_129, trigger: falling-edge */
+		reg-io-width = <4>;
+		vdd33a-supply = <&reg_vcc3>;
+		vddvario-supply = <&reg_vcc3>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&lan9221_pins>;
+	};

but in arch/arm/mach-omap2/gpmc.c gpmc_probe_dt() I still need this
hack:

+	ret = gpio_request_one(129, GPIOF_IN, "lan9221 irq");
+	if (ret) {
+		pr_err("Failed to request IRQ GPIO%d\n", 129);
+		return ret;
+	}

The following patches (already sent mainline) are also applied:
 "arm/dts: OMAP3: fix pinctrl-single configuration"
 "net: smsc911x: adopt pinctrl support"

 Thanks
  -- Christoph



From martinez.javier at gmail.com  Sat Apr 13 14:30:26 2013
From: martinez.javier at gmail.com (Javier Martinez Canillas)
Date: Sat, 13 Apr 2013 20:30:26 +0200
Subject: [RFC][BUG] arm/dts: OMAP3: set #interrupt-cells to two
In-Reply-To: <1365874936.3812.65.camel@mars>
References: <1364631689.3767.7.camel@mars>
 <CAAwP0s35J-edpvFv08xjjpwaezQBYNvMNhhXL-UacsuUtSt4ZA@mail.gmail.com>
 <1364834508.3939.74.camel@mars>
 <CAAwP0s1H9zaBZPMDz9=He-E68UK0Ay3jnxZ2frYH9r1xNeQhxQ@mail.gmail.com>
 <1365874936.3812.65.camel@mars>
Message-ID: <CAAwP0s1i16coo78cBChyFK78BQq2CG4KKJLQSqeuneLuhg2WUg@mail.gmail.com>

On Sat, Apr 13, 2013 at 7:42 PM, Christoph Fritz
<chf.fritz at googlemail.com> wrote:
> On Mon, 2013-04-01 at 22:05 +0200, Javier Martinez Canillas wrote:
>> On Mon, Apr 1, 2013 at 6:41 PM, Christoph Fritz
>> > As a quick-fix (hack) I wrote directly to the registers in gpio_probe()
>> > to enable GPIO banks. I now geht this:
>> >
>> >> > [    0.214630] omap_gpio_probe, 1133, CM_CLKSEL_PER 0x48005040: 0x000000ff
>> >> > [    0.214660] omap_gpio_probe, 1136, CM_ICLKEN_PER 0x48005010: 0x0007ffff
>> >> > [    0.214660] omap_gpio_probe, 1139, CM_FCLKEN_PER 0x48005000: 0x0007ffff
>> >
>> > And it works for me. _But_ when I do enable regulator twl4030
>> > (CONFIG_REGULATOR_TWL4030=y) in my config these registers get reset:
>> >
>> > [    2.935455] smsc911x_open, 1537, CM_CLKSEL_PER 0x48005040: 0x000000ff
>> > [    2.942291] smsc911x_open, 1540, CM_ICLKEN_PER 0x48005010: 0x00040fff
>> > [    2.949066] smsc911x_open, 1543, CM_FCLKEN_PER 0x48005000: 0x00000000
>> >
>> > And the IRQ source for the network chip (smsc911x) is disabled :-(
>> >
>> > Do you have any idea how to ("quick") fix this?
>> >
>>
>> A quick hack is to call gpio_request() explicitly before calling to
>> irq_set_type() is made.
>> I've this patch just to make it work until we find a clean solution:
>>
>> diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
>> index 90c15ee..d594e1d 100644
>> --- a/arch/arm/mach-omap2/gpmc.c
>> +++ b/arch/arm/mach-omap2/gpmc.c
>> @@ -14,6 +14,7 @@
>>   */
>>  #undef DEBUG
>>
>> +#include <linux/gpio.h>
>>  #include <linux/irq.h>
>>  #include <linux/kernel.h>
>>  #include <linux/init.h>
>> @@ -1528,6 +1529,11 @@ static int gpmc_probe_dt(struct platform_device *pdev)
>>                 return ret;
>>         }
>>
>> +       ret = gpio_request_one(176, GPIOF_IN, "smsc911x irq");
>> +       if (ret) {
>> +               pr_err("Failed to request IRQ GPIO%d\n", 176);
>> +               return ret;
>> +       }
>> +
>>         for_each_node_by_name(child, "nand") {
>>                 ret = gpmc_probe_nand_child(pdev, child);
>>                 if (ret < 0) {
>>
>> This solves the issue of the non-initialized GPIO bank before that
>> makes the kernel to hang. Since I've to configure the IRQ polarity as
>> active low level-sensitive on my board and the flags are not set by
>> the IRQ core, I've another ugly hack that forces this:
>>
>> diff --git a/drivers/net/ethernet/smsc/smsc911x.c
>> b/drivers/net/ethernet/smsc/smsc
>> index da5cc9a..27e46f9 100644
>> --- a/drivers/net/ethernet/smsc/smsc911x.c
>> +++ b/drivers/net/ethernet/smsc/smsc911x.c
>> @@ -2390,6 +2390,9 @@ static int smsc911x_drv_probe(struct
>> platform_device *pdev)
>>         pdata = netdev_priv(dev);
>>         dev->irq = irq_res->start;
>> -        irq_flags = irq_res->flags & IRQF_TRIGGER_MASK;
>> +       irq_flags = IRQF_TRIGGER_LOW;
>>         pdata->ioaddr = ioremap_nocache(res->start, res_size);
>>
>>         pdata->dev = dev;
>>
>> >  Thanks
>> >   -- Christoph
>> >
>>
>> I hope to find some time this week to work on this and at least find a
>> solution for the second issue (IORESOURCE_IRQ struct resource flags
>> not being set).
>
> Any updates on this issue?
>

Yes, my last approach to solve the IRQ flags not saved on the
IORESOURCE_IRQ struct resource issue is to add a new
irq_get_trigger_type() function to get the edge/level flags from an
IRQ number and use that function on the smsc911x driver probe function
to get the IRQ flags.

The patch-set is composed of these patches:

[PATCH v2 1/2] genirq: add function to get IRQ edge/level flags [1]
[PATCH 2/2] net: smsc911x: get IRQ flags from chip if not present in
IORESOURCE_IRQ [2]

and the cover letter is this [3]

It would be great if you can test these patches and give some feedback.

> For me it works when doing this in the device tree:
>
> +&omap3_pmx_wkup {
> +       pinctrl-names = "default";
> +
> +       lan9221_pins: pinmux_lan9221_pins {
> +               pinctrl-single,pins = <
> +                       0x5A 0x104      /* gpio_129, INPUT | MODE4 */
> +               >;
> +       };
> +};
> +
> <SNIP>
> +       lan9221 at 15000000 {
> +               compatible = "smsc,lan9221", "smsc,lan9115";
> +               reg = <0x15000000 0x400>;

If I understood correctly your smsc ethernet chip is connected to the
OMAP through the GPMC, then you should use a chip-select, base address
and size instead of the physical address and size.

Do you have commit 5330dc161 ("ARM: OMAP2+: Add GPMC DT support for
Ethernet child nodes") already on your tree? [4]

> +               phy-mode = "mii";
> +               interrupt-parent = <&gpio5>;
> +               interrupts = <1 0x2>;   /* gpio_129, trigger: falling-edge */

I'm confused here, do you get the IRQ_TYPE_EDGE_FALLING (0x2) trigger
type flag on the smsc911x driver probe function?

> +               reg-io-width = <4>;
> +               vdd33a-supply = <&reg_vcc3>;
> +               vddvario-supply = <&reg_vcc3>;
> +               pinctrl-names = "default";
> +               pinctrl-0 = <&lan9221_pins>;
> +       };
>
> but in arch/arm/mach-omap2/gpmc.c gpmc_probe_dt() I still need this
> hack:
>
> +       ret = gpio_request_one(129, GPIOF_IN, "lan9221 irq");
> +       if (ret) {
> +               pr_err("Failed to request IRQ GPIO%d\n", 129);
> +               return ret;
> +       }
>

Yes, this hack is still needed until we figure out how to enable the
GPIO bank before a call to request_irq() is made.

> The following patches (already sent mainline) are also applied:
>  "arm/dts: OMAP3: fix pinctrl-single configuration"
>  "net: smsc911x: adopt pinctrl support"
>

Yes, but that patch is not needed anymore from 3.9, look at this [5]

>  Thanks
>   -- Christoph
>

Best regards,
Javier

[1]: http://www.mail-archive.com/linux-omap at vger.kernel.org/msg88241.html
[2]: http://www.mail-archive.com/linux-omap at vger.kernel.org/msg88225.html
[3]: http://www.mail-archive.com/linux-omap at vger.kernel.org/msg88224.html
[4]: https://patchwork.kernel.org/patch/2273851/
[5]: http://marc.info/?l=linux-kernel&m=135887740715083&w=2


From chf.fritz at googlemail.com  Sat Apr 13 14:59:56 2013
From: chf.fritz at googlemail.com (Christoph Fritz)
Date: Sat, 13 Apr 2013 20:59:56 +0200
Subject: [RFC][BUG] arm/dts: OMAP3: set #interrupt-cells to two
In-Reply-To: <CAAwP0s1i16coo78cBChyFK78BQq2CG4KKJLQSqeuneLuhg2WUg@mail.gmail.com>
References: <1364631689.3767.7.camel@mars>
 <CAAwP0s35J-edpvFv08xjjpwaezQBYNvMNhhXL-UacsuUtSt4ZA@mail.gmail.com>
 <1364834508.3939.74.camel@mars>
 <CAAwP0s1H9zaBZPMDz9=He-E68UK0Ay3jnxZ2frYH9r1xNeQhxQ@mail.gmail.com>
 <1365874936.3812.65.camel@mars>
 <CAAwP0s1i16coo78cBChyFK78BQq2CG4KKJLQSqeuneLuhg2WUg@mail.gmail.com>
Message-ID: <1365879596.3812.118.camel@mars>

On Sat, 2013-04-13 at 20:30 +0200, Javier Martinez Canillas wrote:
> On Sat, Apr 13, 2013 at 7:42 PM, Christoph Fritz
> <chf.fritz at googlemail.com> wrote:

> Yes, my last approach to solve the IRQ flags not saved on the
> IORESOURCE_IRQ struct resource issue is to add a new
> irq_get_trigger_type() function to get the edge/level flags from an
> IRQ number and use that function on the smsc911x driver probe function
> to get the IRQ flags.
> 
> The patch-set is composed of these patches:
> 
> [PATCH v2 1/2] genirq: add function to get IRQ edge/level flags [1]
> [PATCH 2/2] net: smsc911x: get IRQ flags from chip if not present in
> IORESOURCE_IRQ [2]
> 
> and the cover letter is this [3]
> 
> It would be great if you can test these patches and give some feedback.
> 
> > For me it works when doing this in the device tree:
> >
> > +&omap3_pmx_wkup {
> > +       pinctrl-names = "default";
> > +
> > +       lan9221_pins: pinmux_lan9221_pins {
> > +               pinctrl-single,pins = <
> > +                       0x5A 0x104      /* gpio_129, INPUT | MODE4 */
> > +               >;
> > +       };
> > +};
> > +
> > <SNIP>
> > +       lan9221 at 15000000 {
> > +               compatible = "smsc,lan9221", "smsc,lan9115";
> > +               reg = <0x15000000 0x400>;
> 
> If I understood correctly your smsc ethernet chip is connected to the
> OMAP through the GPMC, then you should use a chip-select, base address
> and size instead of the physical address and size.

Yes, it's connected with GPMC.

> Do you have commit 5330dc161 ("ARM: OMAP2+: Add GPMC DT support for
> Ethernet child nodes") already on your tree? [4]

No I haven't.

> 
> > +               phy-mode = "mii";
> > +               interrupt-parent = <&gpio5>;
> > +               interrupts = <1 0x2>;   /* gpio_129, trigger: falling-edge */
> 
> I'm confused here, do you get the IRQ_TYPE_EDGE_FALLING (0x2) trigger
> type flag on the smsc911x driver probe function?

I added printks for irq_res->flags and irq_flags:
[    1.259857] smsc911x_drv_probe, 2396, irq_res->flags 0x00000400
[    1.266113] smsc911x_drv_probe, 2397, irq_flags 0x00000000

So the answer is no. But weird that the smsc911x works nevertheless.

> 
> > +               reg-io-width = <4>;
> > +               vdd33a-supply = <&reg_vcc3>;
> > +               vddvario-supply = <&reg_vcc3>;
> > +               pinctrl-names = "default";
> > +               pinctrl-0 = <&lan9221_pins>;
> > +       };
> >
> > but in arch/arm/mach-omap2/gpmc.c gpmc_probe_dt() I still need this
> > hack:
> >
> > +       ret = gpio_request_one(129, GPIOF_IN, "lan9221 irq");
> > +       if (ret) {
> > +               pr_err("Failed to request IRQ GPIO%d\n", 129);
> > +               return ret;
> > +       }
> >
> 
> Yes, this hack is still needed until we figure out how to enable the
> GPIO bank before a call to request_irq() is made.
> 
> > The following patches (already sent mainline) are also applied:
> >  "arm/dts: OMAP3: fix pinctrl-single configuration"
> >  "net: smsc911x: adopt pinctrl support"
> >
> 
> Yes, but that patch is not needed anymore from 3.9, look at this [5]
> 
> [1]: http://www.mail-archive.com/linux-omap at vger.kernel.org/msg88241.html
> [2]: http://www.mail-archive.com/linux-omap at vger.kernel.org/msg88225.html
> [3]: http://www.mail-archive.com/linux-omap at vger.kernel.org/msg88224.html
> [4]: https://patchwork.kernel.org/patch/2273851/
> [5]: http://marc.info/?l=linux-kernel&m=135887740715083&w=2

Thanks
 -- Christoph




From jason at lakedaemon.net  Sat Apr 13 15:00:37 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Sat, 13 Apr 2013 15:00:37 -0400
Subject: [PATCH 0/5 v2] mv643xx_eth: device tree bindings
In-Reply-To: <20130413172126.6cca0809@skate>
References: <1365071235-11611-1-git-send-email-florian@openwrt.org>
 <20130411165303.GI28693@titan.lakedaemon.net>
 <20130413172126.6cca0809@skate>
Message-ID: <20130413190037.GY28693@titan.lakedaemon.net>

On Sat, Apr 13, 2013 at 05:21:26PM +0200, Thomas Petazzoni wrote:
> Dear Jason Cooper,
> 
> On Thu, 11 Apr 2013 12:53:03 -0400, Jason Cooper wrote:
> 
> > With this and Thomas' pci series, we will have Kirkwood fully
> > converted to devicetree, can begin removing board files, and finally
> > begin migrating everything over to mach-mvebu/.  This will lead to
> > the removal of five directories under arch/arm/ (plat-orion,
> > mach-kirkwood, mach-orion5x, mach-dove, and mach-mv78xx0).
> 
> No, we can't remove mach-orion5x and mach-mv78xx0 for now, they have
> not been converted at all in terms of gpio/pinmux support. I've started
> writing some pinmux code for orion5x but it's not ready.
> 
> I don't think we should rush in doing this merge into mach-mvebu. I'd
> prefer to have the following conditions be met before a platform gets
> merged into mach-mvebu:
> 
>  * The mach-<foo> directory no longer depends on anything in
>    plat-orion. For mach-kirkwood, things are OK (for the DT platforms)
>    for GPIO, MPP and PCIe, but some work remains for the IRQ controller
>    driver and the timer driver.
> 
>  * All boards have been converted to the Device Tree. For
>    mach-kirkwood, we're getting closer.
> 
> Once a given mach-<foo> platform meets these conditions, it will be a
> clean platform, and we can merge it into mach-mvebu without any
> problem.
> 
> So let's continue the cleanup work, conversion to DT, usage of drivers
> in drivers/, improvement of pinmux to support orion5x/mv78xx0, and do
> the move per-platform, once they are ready.
> 
> What do you think?

I agree completely.  I was simply restating the longview goal of the
work we are doing (above and beyond adding armadaXP/370).  I probably
should have given a time reference for "This will lead to..." :)

Also, I have a feeling that not all legacy boards will get converted
over.  If there is no interest or no way to test, certains boards may
get deprecated.

thx,

Jason.


From jason at lakedaemon.net  Sat Apr 13 15:04:16 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Sat, 13 Apr 2013 15:04:16 -0400
Subject: [PATCHv2 04/10] arm: kirkwood: add SoC-level Device Tree data
 for PCIe interfaces
In-Reply-To: <20130413160446.4fa00358@skate>
References: <1365632436-25367-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1365632436-25367-5-git-send-email-thomas.petazzoni@free-electrons.com>
 <20130413103057.GG2824@lunn.ch> <20130413160446.4fa00358@skate>
Message-ID: <20130413190416.GZ28693@titan.lakedaemon.net>

On Sat, Apr 13, 2013 at 04:04:46PM +0200, Thomas Petazzoni wrote:
> Dear Andrew Lunn,
> 
> On Sat, 13 Apr 2013 12:30:57 +0200, Andrew Lunn wrote:
> > > diff --git a/arch/arm/boot/dts/kirkwood-6281.dtsi
> > > b/arch/arm/boot/dts/kirkwood-6281.dtsi index d6c9d65..5137668 100644
> > > --- a/arch/arm/boot/dts/kirkwood-6281.dtsi
> > > +++ b/arch/arm/boot/dts/kirkwood-6281.dtsi
> > > @@ -40,5 +40,36 @@
> > >  				marvell,function = "sdio";
> > >  			};
> > >  		};
> > > +
> > > +		pcie-controller {
> > 
> > Hi Thomas
> > 
> > Convention seems to be to use _ not - in these names.
> 
> As we discussed on IRC, there are quite a number of .dts/.dtsi files
> that use '-' in DT node names. Also, the PCIe DT patches for Armada
> 370/XP have already been merged by Jason with this exact node name. I'm
> fine changing it specifically for Kirkwood, but that would make it
> inconsistent with what we have for Armada 370/XP.
> 
> Jason, what do you think?

I say leave it alone.  If it's that offensive to somebody, we can patch
it up during the -rc cycle.  I'd rather not get into *another* lengthy
discussion regarding this patch-set.  We need to be doing PRs
today/tomorrow.

thx,

Jason.


From francescolavra.fl at gmail.com  Sat Apr 13 16:13:58 2013
From: francescolavra.fl at gmail.com (Francesco Lavra)
Date: Sat, 13 Apr 2013 22:13:58 +0200
Subject: [PATCH V2] cpufreq: ARM big LITTLE: Add generic cpufreq driver
 and its DT glue
In-Reply-To: <1f864ec505cae7c5daea3810a3c26e0f5cda38ea.1364290815.git.viresh.kumar@linaro.org>
References: <1f864ec505cae7c5daea3810a3c26e0f5cda38ea.1364290815.git.viresh.kumar@linaro.org>
Message-ID: <5169BC86.7010905@gmail.com>

On 03/26/2013 10:51 AM, Viresh Kumar wrote:
> big LITTLE is ARM's new Architecture focussing power/performance needs of modern
> world. More information about big LITTLE can be found here:
> 
> http://www.arm.com/products/processors/technologies/biglittleprocessing.php
> http://lwn.net/Articles/481055/
> 
> In order to keep cpufreq support for all big LITTLE platforms simple/generic,
> this patch tries to add a generic cpufreq driver layer for all big LITTLE
> platforms.
> 
> The driver is divided into two parts:
> - Core driver: Generic and shared across all big LITTLE SoC's
> - Glue drivers: Per platform drivers providing ops to the core driver
> 
> This patch adds in a generic glue driver which would extract information from
> Device Tree.
> 
> Future SoC's can either reuse the DT glue or write their own depending on the
> need.
> 
> Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
> Signed-off-by: Viresh Kumar <viresh.kumar at linaro.org>
[...]
> diff --git a/drivers/cpufreq/arm_big_little_dt.c b/drivers/cpufreq/arm_big_little_dt.c
> new file mode 100644
> index 0000000..452ff46
> --- /dev/null
> +++ b/drivers/cpufreq/arm_big_little_dt.c
> @@ -0,0 +1,92 @@
> +/*
> + * Generic big.LITTLE CPUFreq Interface driver
> + *
> + * It provides necessary ops to arm_big_little cpufreq driver and gets
> + * Frequency information from Device Tree. Freq table in DT must be in KHz.
> + *
> + * Copyright (C) 2013 Linaro.
> + * Viresh Kumar <viresh.kumar at linaro.org>
> + *
> + * 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.
> + *
> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
> + * kind, whether express or implied; without even the implied warranty
> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> +
> +#include <linux/cpufreq.h>
> +#include <linux/device.h>
> +#include <linux/export.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/opp.h>
> +#include <linux/slab.h>
> +#include <linux/types.h>
> +#include "arm_big_little.h"
> +
> +static int dt_init_opp_table(struct device *cpu_dev)
> +{
> +	struct device_node *np = NULL;
> +	int count = 0, ret;
> +
> +	for_each_child_of_node(of_find_node_by_path("/cpus"), np) {

If of_find_node_by_path() returns NULL, there will be a NULL pointer
dereference.

> +		if (count++ != cpu_dev->id)
> +			continue;
> +		if (!of_get_property(np, "operating-points", NULL))
> +			return -ENODATA;
> +
> +		cpu_dev->of_node = np;
> +
> +		ret = of_init_opp_table(cpu_dev);
> +		if (ret)
> +			return ret;
> +
> +		return 0;

of_node_put() should be called on np before returning.
Also, the reference count of the parent node should be decremented as well.

These comments apply to the below function dt_get_transition_latency() too.

> +	}
> +
> +	return -ENODEV;
> +}
> +
> +static int dt_get_transition_latency(struct device *cpu_dev)
> +{
> +	struct device_node *np = NULL;
> +	u32 transition_latency = CPUFREQ_ETERNAL;
> +	int count = 0;
> +
> +	for_each_child_of_node(of_find_node_by_path("/cpus"), np) {
> +		if (count++ != cpu_dev->id)
> +			continue;
> +
> +		of_property_read_u32(np, "clock-latency", &transition_latency);
> +		return 0;
> +	}
> +
> +	return -ENODEV;
> +}

--
Francesco


From festevam at gmail.com  Sat Apr 13 16:41:26 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Sat, 13 Apr 2013 17:41:26 -0300
Subject: [PATCH] tty/serial: add MVF uart driver support
In-Reply-To: <1365750655-3530-1-git-send-email-b35083@freescale.com>
References: <1365750655-3530-1-git-send-email-b35083@freescale.com>
Message-ID: <CAOMZO5D-uQQJAc6zAMkF9ViR0KWg4q7cPr7+pLdfyAm9gtPyTA@mail.gmail.com>

On Fri, Apr 12, 2013 at 4:10 AM, Jingchang Lu <b35083 at freescale.com> wrote:
> It adds Freescale Vybrid Family uart driver support
>
> Signed-off-by: Jingchang Lu <b35083 at freescale.com>
> ---
>  drivers/tty/serial/Kconfig       |   17 +
>  drivers/tty/serial/Makefile      |    1 +
>  drivers/tty/serial/mvf.c         | 1246 ++++++++++++++++++++++++++++++++++++++
>  include/uapi/linux/serial_core.h |    3 +
>  4 files changed, 1267 insertions(+)
>  create mode 100644 drivers/tty/serial/mvf.c

Would it be possible to add Vybrid support into the existing imx serial port?


From ohaugan at codeaurora.org  Sat Apr 13 17:02:09 2013
From: ohaugan at codeaurora.org (Olav Haugan)
Date: Sat, 13 Apr 2013 14:02:09 -0700
Subject: [PATCH] documentation: iommu: add description of ARM System MMU
 binding
In-Reply-To: <20130410173732.GQ26992@mudshark.cambridge.arm.com>
References: <1365094259-24847-1-git-send-email-will.deacon@arm.com>
 <515F37C1.4000109@codeaurora.org>
 <20130408092535.GA17476@mudshark.cambridge.arm.com>
 <5162F87A.7070409@codeaurora.org>
 <20130410173732.GQ26992@mudshark.cambridge.arm.com>
Message-ID: <5169C7D1.8070300@codeaurora.org>

Hi again Will,

On 4/10/2013 10:37 AM, Will Deacon wrote:
> On Mon, Apr 08, 2013 at 06:03:54PM +0100, Olav Haugan wrote:
> 
>>> Generally, the StreamIDs are fixed in hardware (as a function of
>>> various AXI bits -- see the SMMU integration guide) and cannot be
>>> set by software. Furthermore, when the StreamIDs have an implicit
>>> effect on IOMMU domain configuration, since stream-matching may
>>> not be always be able to identify a master uniquely.
>> 
>> Let me clarify what I mean by "our SMMU driver programs the SMMU
>> SIDs". What I meant to say is that our SMMU driver programs the SID
>> into the Stream Match Register (SMR) to route the transactions to
>> the correct context bank based on the SID.
> 
> Ok, but then how does that interact with the IOMMU API in Linux? e.g.
> if a client asks for an iova <-> pa mapping on a device, then you
> need to lookup the StreamIDs for that device, no?

Can you explain this use case a bit more. I am not clear what you mean
by a "client"? Are you referring to a client in Linux or are you
referring to the client being the core behind an IOMMU (such as a DMA
engine or a video core)?

I am not sure how StreamIDs relates to the IOMMU API in Linux :-)
I think it helps if I explain my use case to you so you understand how
we use the IOMMU and maybe you can explain your use case and how your
driver works so that we can get on the same page. BTW, our ARMv1 IOMMU
driver can be found @ [1]

Our use case:

1) During boot IOMMU HW is probed, devices for each IOMMU and for each
context bank are created.
2) Video session starts.
3) Linux Video Driver (LVD) creates one or more domain
(iommu_domain_alloc) and calls iommu_attach_device() for each context
bank it is going to use.
4) LVD then calls map as needed for the buffers that the video core
needs to access.
5) LVD shares IOVA with video core and kicks off video core decoding.
6) Video session ends.
7) LVD unmaps
8) LVD detaches.

The video driver selects context bank to attach to based on the use case
and does not know about StreamIDs really.

BTW, when you call iommu_attach_device() what "device" do you pass as
argument? Do you pass the IOMMU as a device? How do you specify which
Context Bank to attach to?

>>> StreamIDs aren't statically associated with a translation
>>> context. Why do you put them here? Also, how do this interact
>>> with stream matching?
>> 
>> We put the StreamIDs in the context bank to tell our driver that
>> these StreamIDs should be programmed into the Stream Match Register
>> (SMR) to route the transactions bearing these StreamIDs to this
>> context bank. We don't really change the SID2CB mapping during
>> run-time. It is set during compile time.
> 
> Again, I'm struggling to see how this interfaces to the more
> general-purpose IOMMU API.

What general-purpose IOMMU API deals with StreamIDs?

>>>> Optional sub-node properties: - qcom,secure-context : boolean
>>>> indicating that a context is secure and programmed by the
>>>> secure environment.
>>> 
>>> Why does Linux care about this?
>> 
>> Linux cares about this because if we are doing content protection
>> using one of the context banks then the context bank is programmed
>> by the secure environment and not accessible/programmable by the
>> HLOS.
> 
> Why can't the secure world just hide those context banks by using 
> SMMU_SCR1.NSNUMCBO?

Yes, that is a possibility for context banks. If you have 1 or more
"secure" context banks it also means that Linux does not have access
(read: can't have) to the global register space and this must be
communicated somehow (hence the "secure-id" IOMMU node property. The
secure-context property might be redundant. However, there might be use
cases were Linux would want to know about the secure context bank. One
such use case could be to register for page fault from the secure
context bank so that Linux can log a useful page fault message to the
kernel log.

[1]
https://www.codeaurora.org/gitweb/quic/la/?p=kernel/msm.git;a=blob;f=drivers/iommu/msm_iommu-v2.c;h=e3aa30c6e31bf55ae5eea3800a8ad910545c5edb;hb=bd3e933fcaca9ffdb45ddc0ce341c45e1ee14091

Thanks,

Olav Haugan

-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation


From grant.likely at secretlab.ca  Sat Apr 13 17:33:22 2013
From: grant.likely at secretlab.ca (Grant Likely)
Date: Sat, 13 Apr 2013 22:33:22 +0100
Subject: [RFCv2 0/2] Representing interrupt affinity in devicetree
In-Reply-To: <20130305092849.GA15661@e106331-lin.cambridge.arm.com>
References: <1355417368-6861-1-git-send-email-mark.rutland@arm.com>
 <20130304025115.05D413E17F8@localhost>
 <20130305092849.GA15661@e106331-lin.cambridge.arm.com>
Message-ID: <20130413213322.7C6193E2249@localhost>

On Tue, 5 Mar 2013 09:28:49 +0000, Mark Rutland <mark.rutland at arm.com> wrote:
> On Mon, Mar 04, 2013 at 02:51:14AM +0000, Grant Likely wrote:
> > I could use some more context for how this will be used. Do device
> > drivers need to be aware of which CPU can handle an interrupt for a
> > device, or is it the sort of thing that can be done in the background
> > when an irq is requested? What are some examples of device drivers using
> > this interface.
> 
> The main users I can think of for this would be PMUs in multi-cluster systems,
> where we may have differing PMUs in each cluster. The driver for each needs to
> know the set of CPUs it's handling, and which CPU each interrupt is affine to.
> 
> With the above binding scheme, we'd describe the A15x2 A7x3 CoreTile's PMUs
> something like:
> 
> pmu_a15s {
> 	compatible = "arm,cortex-a15-pmu";
> 	interrupts = <0 68 4>,
> 	             <0 69 4>;
> 	interrupts-affinity = <0 0x0>,
> 	                      <0 0x1>;
> };
> 
> pmu_a7s {
> 	compatible = arm,cortex-a7-pmu";
> 	interrupts = <0 128 4>,
> 	             <0 129 4>,
> 	             <0 130 4>;
> 	interrupts-affinity = <0 0x100>,
> 	                      <0 0x101>,
> 	                      <0 0x102>;
> };

That does sound an awful lot like what Lorenzo has been trying to solve.
I really do think that you need to coordinate with him.

g.



From martinez.javier at gmail.com  Sat Apr 13 17:40:36 2013
From: martinez.javier at gmail.com (Javier Martinez Canillas)
Date: Sat, 13 Apr 2013 23:40:36 +0200
Subject: [RFC][BUG] arm/dts: OMAP3: set #interrupt-cells to two
In-Reply-To: <1365879596.3812.118.camel@mars>
References: <1364631689.3767.7.camel@mars>
 <CAAwP0s35J-edpvFv08xjjpwaezQBYNvMNhhXL-UacsuUtSt4ZA@mail.gmail.com>
 <1364834508.3939.74.camel@mars>
 <CAAwP0s1H9zaBZPMDz9=He-E68UK0Ay3jnxZ2frYH9r1xNeQhxQ@mail.gmail.com>
 <1365874936.3812.65.camel@mars>
 <CAAwP0s1i16coo78cBChyFK78BQq2CG4KKJLQSqeuneLuhg2WUg@mail.gmail.com>
 <1365879596.3812.118.camel@mars>
Message-ID: <CAAwP0s2Adjb_e50Gf91zqfXiPDMNRZ=eAmQzJzxfDw8bFfzMrg@mail.gmail.com>

On Sat, Apr 13, 2013 at 8:59 PM, Christoph Fritz
<chf.fritz at googlemail.com> wrote:
> On Sat, 2013-04-13 at 20:30 +0200, Javier Martinez Canillas wrote:
>> On Sat, Apr 13, 2013 at 7:42 PM, Christoph Fritz
>> <chf.fritz at googlemail.com> wrote:
>
>> Yes, my last approach to solve the IRQ flags not saved on the
>> IORESOURCE_IRQ struct resource issue is to add a new
>> irq_get_trigger_type() function to get the edge/level flags from an
>> IRQ number and use that function on the smsc911x driver probe function
>> to get the IRQ flags.
>>
>> The patch-set is composed of these patches:
>>
>> [PATCH v2 1/2] genirq: add function to get IRQ edge/level flags [1]
>> [PATCH 2/2] net: smsc911x: get IRQ flags from chip if not present in
>> IORESOURCE_IRQ [2]
>>
>> and the cover letter is this [3]
>>
>> It would be great if you can test these patches and give some feedback.
>>
>> > For me it works when doing this in the device tree:
>> >
>> > +&omap3_pmx_wkup {
>> > +       pinctrl-names = "default";
>> > +
>> > +       lan9221_pins: pinmux_lan9221_pins {
>> > +               pinctrl-single,pins = <
>> > +                       0x5A 0x104      /* gpio_129, INPUT | MODE4 */
>> > +               >;
>> > +       };
>> > +};
>> > +
>> > <SNIP>
>> > +       lan9221 at 15000000 {
>> > +               compatible = "smsc,lan9221", "smsc,lan9115";
>> > +               reg = <0x15000000 0x400>;
>>
>> If I understood correctly your smsc ethernet chip is connected to the
>> OMAP through the GPMC, then you should use a chip-select, base address
>> and size instead of the physical address and size.
>
> Yes, it's connected with GPMC.
>
>> Do you have commit 5330dc161 ("ARM: OMAP2+: Add GPMC DT support for
>> Ethernet child nodes") already on your tree? [4]
>
> No I haven't.
>

In that case you should have that commit on your tree. But the GPMC
driver has changed a lot for 3.9 and 3.10, so I recommend you to base
your work on linux-next that has the latest changes.

And then you will need something like this on your DT (in this example
is using the chip-select 5 but adjust according to your board):

gpmc: gpmc at 6e000000 {
        compatible = "ti,omap3430-gpmc";
        ti,hwmods = "gpmc";
        reg = <0x6e000000 0x1000>;
        interrupts = <20>;
        gpmc,num-cs = <8>;
        gpmc,num-waitpins = <4>;
        #address-cells = <2>;
        #size-cells = <1>;

        ranges = <5 0 0x2c000000 0x1000000>;

        ethernet at 5,0 {
                pinctrl-names = "default";
                pinctrl-0 = <&lan9221_pins>;
                compatible = "smsc,lan9221", "smsc,lan9115";
                reg = <5 0 0xff>;
                bank-width = <2>;

                gpmc,mux-add-data;
                gpmc,cs-on-ns = <0>;
                gpmc,cs-rd-off-ns = <186>;
                gpmc,cs-wr-off-ns = <186>;
                gpmc,adv-on-ns = <12>;
                gpmc,adv-rd-off-ns = <48>;
                gpmc,adv-wr-off-ns = <48>;
                gpmc,oe-on-ns = <54>;
                gpmc,oe-off-ns = <168>;
                gpmc,we-on-ns = <54>;
                gpmc,we-off-ns = <168>;
                gpmc,rd-cycle-ns = <186>;
                gpmc,wr-cycle-ns = <186>;
                gpmc,access-ns = <114>;
                gpmc,page-burst-access-ns = <6>;
                gpmc,bus-turnaround-ns = <12>;
                gpmc,cycle2cycle-delay-ns = <18>;
                gpmc,wr-data-mux-bus-ns = <90>;
                gpmc,wr-access-ns = <186>;
                gpmc,cycle2cycle-samecsen;
                gpmc,cycle2cycle-diffcsen;

                interrupt-parent = <&gpio5>;
                interrupts = <1 0x2>;
                reg-io-width = <4>;
                vdd33a-supply = <&reg_vcc3>;
                vmmc_aux-supply = <&vdd33a>;
                vddvario-supply = <&reg_vcc3>;
        };
};

>>
>> > +               phy-mode = "mii";
>> > +               interrupt-parent = <&gpio5>;
>> > +               interrupts = <1 0x2>;   /* gpio_129, trigger: falling-edge */
>>
>> I'm confused here, do you get the IRQ_TYPE_EDGE_FALLING (0x2) trigger
>> type flag on the smsc911x driver probe function?
>
> I added printks for irq_res->flags and irq_flags:
> [    1.259857] smsc911x_drv_probe, 2396, irq_res->flags 0x00000400
> [    1.266113] smsc911x_drv_probe, 2397, irq_flags 0x00000000
>
> So the answer is no. But weird that the smsc911x works nevertheless.
>

Yes, that's what I thought. You will need patch [1] and [2] to allow
smsc911x driver to get the GPIO-IRQ trigger type flags.

With those patches + linux-next + the device node I posted above +
your gpio_request_one() hack on gpmc_probe_dt() should be enough to
have your smsc ethernet chip working on your board.

>>
>> > +               reg-io-width = <4>;
>> > +               vdd33a-supply = <&reg_vcc3>;
>> > +               vddvario-supply = <&reg_vcc3>;
>> > +               pinctrl-names = "default";
>> > +               pinctrl-0 = <&lan9221_pins>;
>> > +       };
>> >
>> > but in arch/arm/mach-omap2/gpmc.c gpmc_probe_dt() I still need this
>> > hack:
>> >
>> > +       ret = gpio_request_one(129, GPIOF_IN, "lan9221 irq");
>> > +       if (ret) {
>> > +               pr_err("Failed to request IRQ GPIO%d\n", 129);
>> > +               return ret;
>> > +       }
>> >
>>
>> Yes, this hack is still needed until we figure out how to enable the
>> GPIO bank before a call to request_irq() is made.
>>
>> > The following patches (already sent mainline) are also applied:
>> >  "arm/dts: OMAP3: fix pinctrl-single configuration"
>> >  "net: smsc911x: adopt pinctrl support"
>> >
>>
>> Yes, but that patch is not needed anymore from 3.9, look at this [5]
>>
>> [1]: http://www.mail-archive.com/linux-omap at vger.kernel.org/msg88241.html
>> [2]: http://www.mail-archive.com/linux-omap at vger.kernel.org/msg88225.html
>> [3]: http://www.mail-archive.com/linux-omap at vger.kernel.org/msg88224.html
>> [4]: https://patchwork.kernel.org/patch/2273851/
>> [5]: http://marc.info/?l=linux-kernel&m=135887740715083&w=2
>
> Thanks
>  -- Christoph
>
>

Best regards,
Javier


From thierry.reding at avionic-design.de  Sat Apr 13 17:45:39 2013
From: thierry.reding at avionic-design.de (Thierry Reding)
Date: Sat, 13 Apr 2013 23:45:39 +0200
Subject: Latest randconfig build errors
In-Reply-To: <CAF6AEGv=3453KKS9-8YAgHrxMMbNvLMvt0pz-=qdG+zcd-Trrw@mail.gmail.com>
References: <20130304095136.GI17833@n2100.arm.linux.org.uk>
 <20130304184649.GO11806@atomide.com>
 <CAF6AEGv=3453KKS9-8YAgHrxMMbNvLMvt0pz-=qdG+zcd-Trrw@mail.gmail.com>
Message-ID: <20130413214539.GA32613@avionic-0098.mockup.avionic-design.de>

On Sat, Apr 13, 2013 at 08:54:22AM -0400, Rob Clark wrote:
> On Mon, Mar 4, 2013 at 1:46 PM, Tony Lindgren <tony at atomide.com> wrote:
> >
> >> drivers/gpu/drm/tilcdc/tilcdc_slave.o:(.data+0x54): multiple definition of `__mod_of_device_table'
> >> drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54): first defined here
> >> drivers/gpu/drm/tilcdc/tilcdc_panel.o:(.data+0x54): multiple definition of `__mod_of_device_table'
> >> drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54): first defined here
> >> drivers/gpu/drm/tilcdc/tilcdc_drv.o:(.data+0x184): multiple definition of `__mod_of_device_table'
> >> drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54): first defined here
> >
> > Rob, I assume you'll do a patch for this one?
> 
> 
> oh, I apologize for the late reply, I didn't see this email...
> 
> There is a patch that we can merge to make tilcdc bool instead of
> tristate[1], which I suppose is ok for a temporary fix.  Although I'm
> all-ears if someone has a better idea about how to fix this.  The
> problem is that we have multiple sub-devices for different possible
> panel drivers, so that depending on DT tables, the correct ones get
> loaded for the hw.  But they are all built into a single module.
> Splitting them into multiple modules will be problematic, as panel
> drivers which are present really need to get probed before the
> toplevel drm device..

You could look at the Tegra driver. I had to solve a similar problem
there. What I did is basically parse the DT in the host1x driver and add
all device nodes which are required by DRM to a list. Later when the
individual devices are probed they are removed from that list, so that
when the list becomes empty we are sure that all required devices are
there and only then call the drm_platform_init() function.

This fits very well with how Tegra hardware is designed because host1x
is the parent for all DRM subdevices (DC, RGB/LVDS, HDMI, ...). So it is
probed before any of its children and it can easily parse the DT upfront
and initialize the list of required devices.

> I suppose in theory it is possible to make drm
> cope better with dynamically loaded outputs, but I'm not sure that
> there is any way to do this without breaking userspace which expects
> that all of the connectors/encoders are present once the drm device is
> loaded.

I had been thinking about this on and off for a while, but I haven't
come up with anything concrete. Ideally we could just have some kind of
event that userspace would listen for, so that new outputs can be
dynamically added and userspace informed about them. Last time I checked
most of the helpers assumed that the complete output configuration is
known when the DRM device is registered, so some major rework will be
required to efficiently make use of such dynamicity.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130413/e0117fe8/attachment.sig>

From heiko at sntech.de  Sat Apr 13 19:38:39 2013
From: heiko at sntech.de (Heiko =?utf-8?q?St=C3=BCbner?=)
Date: Sun, 14 Apr 2013 01:38:39 +0200
Subject: [PATCH v4] pinctrl: Add pinctrl-s3c24xx driver
Message-ID: <201304140138.40142.heiko@sntech.de>

The s3c24xx pins follow a similar pattern as the other Samsung SoCs and
can therefore reuse the already introduced infrastructure.

The s3c24xx SoCs have one design oddity in that the first 4 external
interrupts do not reside in the eint pending register but in the main
interrupt controller instead. We solve this by forwarding the external
interrupt from the main controller into the irq domain of the pin bank.
The masking/acking of these interrupts is handled in the same way.

Furthermore the S3C2412/2413 SoCs contain another oddity in that they
keep the same 4 eints in the main interrupt controller and eintpend
register and requiring ack operations to happen in both. This is solved
by using different compatible properties for the wakeup eint node which
set a property accordingly.

Signed-off-by: Heiko Stuebner <heiko at sntech.de>
Reviewed-by: Tomasz Figa <t.figa at samsung.com>
Reviewed-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
---
changes since v3:
- address comments from Sylwester Nawrocki:
  (typos, wrong comments, etc)
changes since v2:
- address more comments from Tomasz Figa:
  * remove obsolete ctrl_type references
  * remove redundant check for parent_chip
  * update docs and commit message

changes since v1:
- address comments from Tomasz Figa:
  * split handling functions for eints 0-3 for s3c2412 and all others
  * change the handling for s3c2412 eints 0-3 in that they now use
    chained_irq_* for the outer parent interrupt

 .../bindings/pinctrl/samsung-pinctrl.txt           |    8 +
 drivers/gpio/gpio-samsung.c                        |    4 +
 drivers/pinctrl/Kconfig                            |    5 +
 drivers/pinctrl/Makefile                           |    1 +
 drivers/pinctrl/pinctrl-s3c24xx.c                  |  652 ++++++++++++++++++++
 drivers/pinctrl/pinctrl-samsung.c                  |   10 +
 drivers/pinctrl/pinctrl-samsung.h                  |    4 +
 7 files changed, 684 insertions(+), 0 deletions(-)
 create mode 100644 drivers/pinctrl/pinctrl-s3c24xx.c

diff --git a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
index c70fca1..dc50c7e 100644
--- a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
@@ -7,6 +7,10 @@ on-chip controllers onto these pads.
 
 Required Properties:
 - compatible: should be one of the following.
+  - "samsung,s3c2413-pinctrl": for S3C2413-compatible pin-controller,
+  - "samsung,s3c2416-pinctrl": for S3C2416-compatible pin-controller,
+  - "samsung,s3c2440-pinctrl": for S3C2440-compatible pin-controller,
+  - "samsung,s3c2450-pinctrl": for S3C2450-compatible pin-controller,
   - "samsung,s3c64xx-pinctrl": for S3C64xx-compatible pin-controller,
   - "samsung,exynos4210-pinctrl": for Exynos4210 compatible pin-controller.
   - "samsung,exynos4x12-pinctrl": for Exynos4x12 compatible pin-controller.
@@ -106,6 +110,10 @@ B. External Wakeup Interrupts: For supporting external wakeup interrupts, a
 
    - compatible: identifies the type of the external wakeup interrupt controller
      The possible values are:
+     - samsung,s3c2410-wakeup-eint: represents wakeup interrupt controller
+       found on Samsung S3C24xx SoCs except S3C2412 and S3C2413,
+     - samsung,s3c2412-wakeup-eint: represents wakeup interrupt controller
+       found on Samsung S3C2412 and S3C2413 SoCs,
      - samsung,s3c64xx-wakeup-eint: represents wakeup interrupt controller
        found on Samsung S3C64xx SoCs,
      - samsung,exynos4210-wakeup-eint: represents wakeup interrupt controller
diff --git a/drivers/gpio/gpio-samsung.c b/drivers/gpio/gpio-samsung.c
index dc06a6f..73017b9 100644
--- a/drivers/gpio/gpio-samsung.c
+++ b/drivers/gpio/gpio-samsung.c
@@ -3026,6 +3026,10 @@ static __init int samsung_gpiolib_init(void)
 	*/
 	struct device_node *pctrl_np;
 	static const struct of_device_id exynos_pinctrl_ids[] = {
+		{ .compatible = "samsung,s3c2413-pinctrl", },
+		{ .compatible = "samsung,s3c2416-pinctrl", },
+		{ .compatible = "samsung,s3c2440-pinctrl", },
+		{ .compatible = "samsung,s3c2450-pinctrl", },
 		{ .compatible = "samsung,s3c64xx-pinctrl", },
 		{ .compatible = "samsung,exynos4210-pinctrl", },
 		{ .compatible = "samsung,exynos4x12-pinctrl", },
diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index 7402ac9..58d73ac 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -226,6 +226,11 @@ config PINCTRL_EXYNOS5440
 	select PINMUX
 	select PINCONF
 
+config PINCTRL_S3C24XX
+	bool "Samsung S3C24XX SoC pinctrl driver"
+	depends on ARCH_S3C24XX
+	select PINCTRL_SAMSUNG
+
 config PINCTRL_S3C64XX
 	bool "Samsung S3C64XX SoC pinctrl driver"
 	depends on ARCH_S3C64XX
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index 21d34c2..1ccdfd8 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -45,6 +45,7 @@ obj-$(CONFIG_PINCTRL_COH901)	+= pinctrl-coh901.o
 obj-$(CONFIG_PINCTRL_SAMSUNG)	+= pinctrl-samsung.o
 obj-$(CONFIG_PINCTRL_EXYNOS)	+= pinctrl-exynos.o
 obj-$(CONFIG_PINCTRL_EXYNOS5440)	+= pinctrl-exynos5440.o
+obj-$(CONFIG_PINCTRL_S3C24XX)	+= pinctrl-s3c24xx.o
 obj-$(CONFIG_PINCTRL_S3C64XX)	+= pinctrl-s3c64xx.o
 obj-$(CONFIG_PINCTRL_XWAY)	+= pinctrl-xway.o
 obj-$(CONFIG_PINCTRL_LANTIQ)	+= pinctrl-lantiq.o
diff --git a/drivers/pinctrl/pinctrl-s3c24xx.c b/drivers/pinctrl/pinctrl-s3c24xx.c
new file mode 100644
index 0000000..efd0908
--- /dev/null
+++ b/drivers/pinctrl/pinctrl-s3c24xx.c
@@ -0,0 +1,652 @@
+/*
+ * S3C24XX specific support for Samsung pinctrl/gpiolib driver.
+ *
+ * Copyright (c) 2013 Heiko Stuebner <heiko at sntech.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.
+ *
+ * This file contains the SamsungS3C24XX specific information required by the
+ * Samsung pinctrl/gpiolib driver. It also includes the implementation of
+ * external gpio and wakeup interrupt support.
+ */
+
+#include <linux/module.h>
+#include <linux/device.h>
+#include <linux/interrupt.h>
+#include <linux/irqdomain.h>
+#include <linux/irq.h>
+#include <linux/of_irq.h>
+#include <linux/io.h>
+#include <linux/slab.h>
+#include <linux/err.h>
+
+#include <asm/mach/irq.h>
+
+#include "pinctrl-samsung.h"
+
+#define NUM_EINT	24
+#define NUM_EINT_IRQ	6
+#define EINT_MAX_PER_GROUP	8
+
+#define EINTPEND_REG	0xa8
+#define EINTMASK_REG	0xa4
+
+#define EINT_GROUP(i)		((int)((i) / EINT_MAX_PER_GROUP))
+#define EINT_REG(i)		((EINT_GROUP(i) * 4) + 0x88)
+#define EINT_OFFS(i)		((i) % EINT_MAX_PER_GROUP * 4)
+
+#define EINT_LEVEL_LOW		0
+#define EINT_LEVEL_HIGH		1
+#define EINT_EDGE_FALLING	2
+#define EINT_EDGE_RISING	4
+#define EINT_EDGE_BOTH		6
+#define EINT_MASK		0xf
+
+static struct samsung_pin_bank_type bank_type_1bit = {
+	.fld_width = { 1, 1, },
+	.reg_offset = { 0x00, 0x04, },
+};
+
+static struct samsung_pin_bank_type bank_type_2bit = {
+	.fld_width = { 2, 1, 2, },
+	.reg_offset = { 0x00, 0x04, 0x08, },
+};
+
+#define PIN_BANK_A(pins, reg, id)		\
+	{						\
+		.type		= &bank_type_1bit,	\
+		.pctl_offset	= reg,			\
+		.nr_pins	= pins,			\
+		.eint_type	= EINT_TYPE_NONE,	\
+		.name		= id			\
+	}
+
+#define PIN_BANK_2BIT(pins, reg, id)		\
+	{						\
+		.type		= &bank_type_2bit,	\
+		.pctl_offset	= reg,			\
+		.nr_pins	= pins,			\
+		.eint_type	= EINT_TYPE_NONE,	\
+		.name		= id			\
+	}
+
+#define PIN_BANK_2BIT_EINTW(pins, reg, id, eoffs, emask)\
+	{						\
+		.type		= &bank_type_2bit,	\
+		.pctl_offset	= reg,			\
+		.nr_pins	= pins,			\
+		.eint_type	= EINT_TYPE_WKUP,	\
+		.eint_func	= 2,			\
+		.eint_mask	= emask,		\
+		.eint_offset	= eoffs,		\
+		.name		= id			\
+	}
+
+/**
+ * struct s3c24xx_eint_data: EINT common data
+ * @drvdata: pin controller driver data
+ * @domains: IRQ domains of particular EINT interrupts
+ * @parents: mapped parent irqs in the main interrupt controller
+ */
+struct s3c24xx_eint_data {
+	struct samsung_pinctrl_drv_data *drvdata;
+	struct irq_domain *domains[NUM_EINT];
+	int parents[NUM_EINT_IRQ];
+};
+
+/**
+ * struct s3c24xx_eint_domain_data: per irq-domain data
+ * @bank: pin bank related to the domain
+ * @eint_data: common data
+ * eint0_3_parent_only: live eints 0-3 only in the main intc
+ */
+struct s3c24xx_eint_domain_data {
+	struct samsung_pin_bank *bank;
+	struct s3c24xx_eint_data *eint_data;
+	bool eint0_3_parent_only;
+};
+
+static int s3c24xx_eint_get_trigger(unsigned int type)
+{
+	switch (type) {
+	case IRQ_TYPE_EDGE_RISING:
+		return EINT_EDGE_RISING;
+		break;
+	case IRQ_TYPE_EDGE_FALLING:
+		return EINT_EDGE_FALLING;
+		break;
+	case IRQ_TYPE_EDGE_BOTH:
+		return EINT_EDGE_BOTH;
+		break;
+	case IRQ_TYPE_LEVEL_HIGH:
+		return EINT_LEVEL_HIGH;
+		break;
+	case IRQ_TYPE_LEVEL_LOW:
+		return EINT_LEVEL_LOW;
+		break;
+	default:
+		return -EINVAL;
+	}
+}
+
+static void s3c24xx_eint_set_handler(unsigned int irq, unsigned int type)
+{
+	/* Edge- and level-triggered interrupts need different handlers */
+	if (type & IRQ_TYPE_EDGE_BOTH)
+		__irq_set_handler_locked(irq, handle_edge_irq);
+	else
+		__irq_set_handler_locked(irq, handle_level_irq);
+}
+
+static void s3c24xx_eint_set_function(struct samsung_pinctrl_drv_data *d,
+					struct samsung_pin_bank *bank, int pin)
+{
+	struct samsung_pin_bank_type *bank_type = bank->type;
+	unsigned long flags;
+	void __iomem *reg;
+	u8 shift;
+	u32 mask;
+	u32 val;
+
+	/* Make sure that pin is configured as interrupt */
+	reg = d->virt_base + bank->pctl_offset;
+	shift = pin * bank_type->fld_width[PINCFG_TYPE_FUNC];
+	mask = (1 << bank_type->fld_width[PINCFG_TYPE_FUNC]) - 1;
+
+	spin_lock_irqsave(&bank->slock, flags);
+
+	val = readl(reg);
+	val &= ~(mask << shift);
+	val |= bank->eint_func << shift;
+	writel(val, reg);
+
+	spin_unlock_irqrestore(&bank->slock, flags);
+}
+
+static int s3c24xx_eint_type(struct irq_data *data, unsigned int type)
+{
+	struct samsung_pin_bank *bank = irq_data_get_irq_chip_data(data);
+	struct samsung_pinctrl_drv_data *d = bank->drvdata;
+	int index = bank->eint_offset + data->hwirq;
+	void __iomem *reg;
+	int trigger;
+	u8 shift;
+	u32 val;
+
+	trigger = s3c24xx_eint_get_trigger(type);
+	if (trigger < 0) {
+		dev_err(d->dev, "unsupported external interrupt type\n");
+		return -EINVAL;
+	}
+
+	s3c24xx_eint_set_handler(data->irq, type);
+
+	/* Set up interrupt trigger */
+	reg = d->virt_base + EINT_REG(index);
+	shift = EINT_OFFS(index);
+
+	val = readl(reg);
+	val &= ~(EINT_MASK << shift);
+	val |= trigger << shift;
+	writel(val, reg);
+
+	s3c24xx_eint_set_function(d, bank, data->hwirq);
+
+	return 0;
+}
+
+/* Handling of EINTs 0-3 on all except S3C2412 and S3C2413 */
+
+static void s3c2410_eint0_3_ack(struct irq_data *data)
+{
+	struct samsung_pin_bank *bank = irq_data_get_irq_chip_data(data);
+	struct s3c24xx_eint_domain_data *ddata = bank->irq_domain->host_data;
+	struct s3c24xx_eint_data *eint_data = ddata->eint_data;
+	int parent_irq = eint_data->parents[data->hwirq];
+	struct irq_chip *parent_chip = irq_get_chip(parent_irq);
+
+	parent_chip->irq_ack(irq_get_irq_data(parent_irq));
+}
+
+static void s3c2410_eint0_3_mask(struct irq_data *data)
+{
+	struct samsung_pin_bank *bank = irq_data_get_irq_chip_data(data);
+	struct s3c24xx_eint_domain_data *ddata = bank->irq_domain->host_data;
+	struct s3c24xx_eint_data *eint_data = ddata->eint_data;
+	int parent_irq = eint_data->parents[data->hwirq];
+	struct irq_chip *parent_chip = irq_get_chip(parent_irq);
+
+	parent_chip->irq_mask(irq_get_irq_data(parent_irq));
+}
+
+static void s3c2410_eint0_3_unmask(struct irq_data *data)
+{
+	struct samsung_pin_bank *bank = irq_data_get_irq_chip_data(data);
+	struct s3c24xx_eint_domain_data *ddata = bank->irq_domain->host_data;
+	struct s3c24xx_eint_data *eint_data = ddata->eint_data;
+	int parent_irq = eint_data->parents[data->hwirq];
+	struct irq_chip *parent_chip = irq_get_chip(parent_irq);
+
+	parent_chip->irq_unmask(irq_get_irq_data(parent_irq));
+}
+
+static struct irq_chip s3c2410_eint0_3_chip = {
+	.name		= "s3c2410-eint0_3",
+	.irq_ack	= s3c2410_eint0_3_ack,
+	.irq_mask	= s3c2410_eint0_3_mask,
+	.irq_unmask	= s3c2410_eint0_3_unmask,
+	.irq_set_type	= s3c24xx_eint_type,
+};
+
+static void s3c2410_demux_eint0_3(unsigned int irq, struct irq_desc *desc)
+{
+	struct irq_data *data = irq_desc_get_irq_data(desc);
+	struct s3c24xx_eint_data *eint_data = irq_get_handler_data(irq);
+	unsigned int virq;
+
+	/* the first 4 eints have a simple 1 to 1 mapping */
+	virq = irq_linear_revmap(eint_data->domains[data->hwirq], data->hwirq);
+	/* Something must be really wrong if an unmapped EINT is unmasked */
+	BUG_ON(!virq);
+
+	generic_handle_irq(virq);
+}
+
+/* Handling of EINTs 0-3 on S3C2412 and S3C2413 */
+
+static void s3c2412_eint0_3_ack(struct irq_data *data)
+{
+	struct samsung_pin_bank *bank = irq_data_get_irq_chip_data(data);
+	struct samsung_pinctrl_drv_data *d = bank->drvdata;
+
+	unsigned long bitval = 1UL << data->hwirq;
+	writel(bitval, d->virt_base + EINTPEND_REG);
+}
+
+static void s3c2412_eint0_3_mask(struct irq_data *data)
+{
+	struct samsung_pin_bank *bank = irq_data_get_irq_chip_data(data);
+	struct samsung_pinctrl_drv_data *d = bank->drvdata;
+	unsigned long mask;
+
+	mask = readl(d->virt_base + EINTMASK_REG);
+	mask |= (1UL << data->hwirq);
+	writel(mask, d->virt_base + EINTMASK_REG);
+}
+
+static void s3c2412_eint0_3_unmask(struct irq_data *data)
+{
+	struct samsung_pin_bank *bank = irq_data_get_irq_chip_data(data);
+	struct samsung_pinctrl_drv_data *d = bank->drvdata;
+	unsigned long mask;
+
+	mask = readl(d->virt_base + EINTMASK_REG);
+	mask &= ~(1UL << data->hwirq);
+	writel(mask, d->virt_base + EINTMASK_REG);
+}
+
+static struct irq_chip s3c2412_eint0_3_chip = {
+	.name		= "s3c2412-eint0_3",
+	.irq_ack	= s3c2412_eint0_3_ack,
+	.irq_mask	= s3c2412_eint0_3_mask,
+	.irq_unmask	= s3c2412_eint0_3_unmask,
+	.irq_set_type	= s3c24xx_eint_type,
+};
+
+static void s3c2412_demux_eint0_3(unsigned int irq, struct irq_desc *desc)
+{
+	struct irq_chip *chip = irq_get_chip(irq);
+	struct irq_data *data = irq_desc_get_irq_data(desc);
+	struct s3c24xx_eint_data *eint_data = irq_get_handler_data(irq);
+	unsigned int virq;
+
+	chained_irq_enter(chip, desc);
+
+	/* the first 4 eints have a simple 1 to 1 mapping */
+	virq = irq_linear_revmap(eint_data->domains[data->hwirq], data->hwirq);
+	/* Something must be really wrong if an unmapped EINT is unmasked */
+	BUG_ON(!virq);
+
+	generic_handle_irq(virq);
+
+	chained_irq_exit(chip, desc);
+}
+
+/* Handling of all other eints */
+
+static void s3c24xx_eint_ack(struct irq_data *data)
+{
+	struct samsung_pin_bank *bank = irq_data_get_irq_chip_data(data);
+	struct samsung_pinctrl_drv_data *d = bank->drvdata;
+	unsigned char index = bank->eint_offset + data->hwirq;
+
+	writel(1UL << index, d->virt_base + EINTPEND_REG);
+}
+
+static void s3c24xx_eint_mask(struct irq_data *data)
+{
+	struct samsung_pin_bank *bank = irq_data_get_irq_chip_data(data);
+	struct samsung_pinctrl_drv_data *d = bank->drvdata;
+	unsigned char index = bank->eint_offset + data->hwirq;
+	unsigned long mask;
+
+	mask = readl(d->virt_base + EINTMASK_REG);
+	mask |= (1UL << index);
+	writel(mask, d->virt_base + EINTMASK_REG);
+}
+
+static void s3c24xx_eint_unmask(struct irq_data *data)
+{
+	struct samsung_pin_bank *bank = irq_data_get_irq_chip_data(data);
+	struct samsung_pinctrl_drv_data *d = bank->drvdata;
+	unsigned char index = bank->eint_offset + data->hwirq;
+	unsigned long mask;
+
+	mask = readl(d->virt_base + EINTMASK_REG);
+	mask &= ~(1UL << index);
+	writel(mask, d->virt_base + EINTMASK_REG);
+}
+
+static struct irq_chip s3c24xx_eint_chip = {
+	.name		= "s3c-eint",
+	.irq_ack	= s3c24xx_eint_ack,
+	.irq_mask	= s3c24xx_eint_mask,
+	.irq_unmask	= s3c24xx_eint_unmask,
+	.irq_set_type	= s3c24xx_eint_type,
+};
+
+static inline void s3c24xx_demux_eint(unsigned int irq, struct irq_desc *desc,
+				      u32 offset, u32 range)
+{
+	struct irq_chip *chip = irq_get_chip(irq);
+	struct s3c24xx_eint_data *data = irq_get_handler_data(irq);
+	struct samsung_pinctrl_drv_data *d = data->drvdata;
+	unsigned int pend, mask;
+
+	chained_irq_enter(chip, desc);
+
+	pend = readl(d->virt_base + EINTPEND_REG);
+	mask = readl(d->virt_base + EINTMASK_REG);
+
+	pend &= ~mask;
+	pend &= range;
+
+	while (pend) {
+		unsigned int virq;
+
+		irq = __ffs(pend);
+		pend &= ~(1 << irq);
+		virq = irq_linear_revmap(data->domains[irq], irq - offset);
+		/* Something is really wrong if an unmapped EINT is unmasked */
+		BUG_ON(!virq);
+
+		generic_handle_irq(virq);
+	}
+
+	chained_irq_exit(chip, desc);
+}
+
+static void s3c24xx_demux_eint4_7(unsigned int irq, struct irq_desc *desc)
+{
+	s3c24xx_demux_eint(irq, desc, 0, 0xf0);
+}
+
+static void s3c24xx_demux_eint8_23(unsigned int irq, struct irq_desc *desc)
+{
+	s3c24xx_demux_eint(irq, desc, 8, 0xffff00);
+}
+
+static irq_flow_handler_t s3c2410_eint_handlers[NUM_EINT_IRQ] = {
+	s3c2410_demux_eint0_3,
+	s3c2410_demux_eint0_3,
+	s3c2410_demux_eint0_3,
+	s3c2410_demux_eint0_3,
+	s3c24xx_demux_eint4_7,
+	s3c24xx_demux_eint8_23,
+};
+
+static irq_flow_handler_t s3c2412_eint_handlers[NUM_EINT_IRQ] = {
+	s3c2412_demux_eint0_3,
+	s3c2412_demux_eint0_3,
+	s3c2412_demux_eint0_3,
+	s3c2412_demux_eint0_3,
+	s3c24xx_demux_eint4_7,
+	s3c24xx_demux_eint8_23,
+};
+
+static int s3c24xx_gpf_irq_map(struct irq_domain *h, unsigned int virq,
+					irq_hw_number_t hw)
+{
+	struct s3c24xx_eint_domain_data *ddata = h->host_data;
+	struct samsung_pin_bank *bank = ddata->bank;
+
+	if (!(bank->eint_mask & (1 << (bank->eint_offset + hw))))
+		return -EINVAL;
+
+	if (hw <= 3) {
+		if (ddata->eint0_3_parent_only)
+			irq_set_chip_and_handler(virq, &s3c2410_eint0_3_chip,
+						 handle_edge_irq);
+		else
+			irq_set_chip_and_handler(virq, &s3c2412_eint0_3_chip,
+						 handle_edge_irq);
+	} else {
+		irq_set_chip_and_handler(virq, &s3c24xx_eint_chip,
+					 handle_edge_irq);
+	}
+	irq_set_chip_data(virq, bank);
+	set_irq_flags(virq, IRQF_VALID);
+	return 0;
+}
+
+static const struct irq_domain_ops s3c24xx_gpf_irq_ops = {
+	.map	= s3c24xx_gpf_irq_map,
+	.xlate	= irq_domain_xlate_twocell,
+};
+
+static int s3c24xx_gpg_irq_map(struct irq_domain *h, unsigned int virq,
+					irq_hw_number_t hw)
+{
+	struct s3c24xx_eint_domain_data *ddata = h->host_data;
+	struct samsung_pin_bank *bank = ddata->bank;
+
+	if (!(bank->eint_mask & (1 << (bank->eint_offset + hw))))
+		return -EINVAL;
+
+	irq_set_chip_and_handler(virq, &s3c24xx_eint_chip, handle_edge_irq);
+	irq_set_chip_data(virq, bank);
+	set_irq_flags(virq, IRQF_VALID);
+	return 0;
+}
+
+static const struct irq_domain_ops s3c24xx_gpg_irq_ops = {
+	.map	= s3c24xx_gpg_irq_map,
+	.xlate	= irq_domain_xlate_twocell,
+};
+
+static const struct of_device_id s3c24xx_eint_irq_ids[] = {
+	{ .compatible = "samsung,s3c2410-wakeup-eint", .data = (void *)1 },
+	{ .compatible = "samsung,s3c2412-wakeup-eint", .data = (void *)0 },
+	{ }
+};
+
+static int s3c24xx_eint_init(struct samsung_pinctrl_drv_data *d)
+{
+	struct device *dev = d->dev;
+	const struct of_device_id *match;
+	struct device_node *eint_np = NULL;
+	struct device_node *np;
+	struct samsung_pin_bank *bank;
+	struct s3c24xx_eint_data *eint_data;
+	const struct irq_domain_ops *ops;
+	unsigned int i;
+	bool eint0_3_parent_only;
+	irq_flow_handler_t *handlers;
+
+	for_each_child_of_node(dev->of_node, np) {
+		match = of_match_node(s3c24xx_eint_irq_ids, np);
+		if (match) {
+			eint_np = np;
+			eint0_3_parent_only = (bool)match->data;
+			break;
+		}
+	}
+	if (!eint_np)
+		return -ENODEV;
+
+	eint_data = devm_kzalloc(dev, sizeof(*eint_data), GFP_KERNEL);
+	if (!eint_data)
+		return -ENOMEM;
+
+	eint_data->drvdata = d;
+
+	handlers = eint0_3_parent_only ? s3c2410_eint_handlers
+				       : s3c2412_eint_handlers;
+	for (i = 0; i < NUM_EINT_IRQ; ++i) {
+		unsigned int irq;
+
+		irq = irq_of_parse_and_map(eint_np, i);
+		if (!irq) {
+			dev_err(dev, "failed to get wakeup EINT IRQ %d\n", i);
+			return -ENXIO;
+		}
+
+		eint_data->parents[i] = irq;
+		irq_set_chained_handler(irq, handlers[i]);
+		irq_set_handler_data(irq, eint_data);
+	}
+
+	bank = d->ctrl->pin_banks;
+	for (i = 0; i < d->ctrl->nr_banks; ++i, ++bank) {
+		struct s3c24xx_eint_domain_data *ddata;
+		unsigned int mask;
+		unsigned int irq;
+		unsigned int pin;
+
+		if (bank->eint_type != EINT_TYPE_WKUP)
+			continue;
+
+		ddata = devm_kzalloc(dev, sizeof(*ddata), GFP_KERNEL);
+		if (!ddata)
+			return -ENOMEM;
+
+		ddata->bank = bank;
+		ddata->eint_data = eint_data;
+		ddata->eint0_3_parent_only = eint0_3_parent_only;
+
+		ops = (bank->eint_offset == 0) ? &s3c24xx_gpf_irq_ops
+					       : &s3c24xx_gpg_irq_ops;
+
+		bank->irq_domain = irq_domain_add_linear(bank->of_node,
+				bank->nr_pins, ops, ddata);
+		if (!bank->irq_domain) {
+			dev_err(dev, "wkup irq domain add failed\n");
+			return -ENXIO;
+		}
+
+		irq = bank->eint_offset;
+		mask = bank->eint_mask;
+		for (pin = 0; mask; ++pin, mask >>= 1) {
+			if (irq > NUM_EINT)
+				break;
+			if (!(mask & 1))
+				continue;
+			eint_data->domains[irq] = bank->irq_domain;
+			++irq;
+		}
+	}
+
+	return 0;
+}
+
+static struct samsung_pin_bank s3c2413_pin_banks[] = {
+	PIN_BANK_A(23, 0x000, "gpa"),
+	PIN_BANK_2BIT(11, 0x010, "gpb"),
+	PIN_BANK_2BIT(16, 0x020, "gpc"),
+	PIN_BANK_2BIT(16, 0x030, "gpd"),
+	PIN_BANK_2BIT(16, 0x040, "gpe"),
+	PIN_BANK_2BIT_EINTW(8, 0x050, "gpf", 0, 0xff),
+	PIN_BANK_2BIT_EINTW(16, 0x060, "gpg", 8, 0xffff00),
+	PIN_BANK_2BIT(11, 0x070, "gph"),
+	PIN_BANK_2BIT(13, 0x080, "gpj"),
+};
+
+struct samsung_pin_ctrl s3c2413_pin_ctrl[] = {
+	{
+		.pin_banks	= s3c2413_pin_banks,
+		.nr_banks	= ARRAY_SIZE(s3c2413_pin_banks),
+		.eint_wkup_init = s3c24xx_eint_init,
+		.label		= "S3C2413-GPIO",
+	},
+};
+
+static struct samsung_pin_bank s3c2416_pin_banks[] = {
+	PIN_BANK_A(27, 0x000, "gpa"),
+	PIN_BANK_2BIT(11, 0x010, "gpb"),
+	PIN_BANK_2BIT(16, 0x020, "gpc"),
+	PIN_BANK_2BIT(16, 0x030, "gpd"),
+	PIN_BANK_2BIT(16, 0x040, "gpe"),
+	PIN_BANK_2BIT_EINTW(8, 0x050, "gpf", 0, 0xff),
+	PIN_BANK_2BIT_EINTW(8, 0x060, "gpg", 8, 0xff00),
+	PIN_BANK_2BIT(15, 0x070, "gph"),
+	PIN_BANK_2BIT(16, 0x0e0, "gpk"),
+	PIN_BANK_2BIT(14, 0x0f0, "gpl"),
+	PIN_BANK_2BIT(2, 0x100, "gpm"),
+};
+
+struct samsung_pin_ctrl s3c2416_pin_ctrl[] = {
+	{
+		.pin_banks	= s3c2416_pin_banks,
+		.nr_banks	= ARRAY_SIZE(s3c2416_pin_banks),
+		.eint_wkup_init = s3c24xx_eint_init,
+		.label		= "S3C2416-GPIO",
+	},
+};
+
+static struct samsung_pin_bank s3c2440_pin_banks[] = {
+	PIN_BANK_A(25, 0x000, "gpa"),
+	PIN_BANK_2BIT(11, 0x010, "gpb"),
+	PIN_BANK_2BIT(16, 0x020, "gpc"),
+	PIN_BANK_2BIT(16, 0x030, "gpd"),
+	PIN_BANK_2BIT(16, 0x040, "gpe"),
+	PIN_BANK_2BIT_EINTW(8, 0x050, "gpf", 0, 0xff),
+	PIN_BANK_2BIT_EINTW(16, 0x060, "gpg", 8, 0xffff00),
+	PIN_BANK_2BIT(11, 0x070, "gph"),
+	PIN_BANK_2BIT(13, 0x0d0, "gpj"),
+};
+
+struct samsung_pin_ctrl s3c2440_pin_ctrl[] = {
+	{
+		.pin_banks	= s3c2440_pin_banks,
+		.nr_banks	= ARRAY_SIZE(s3c2440_pin_banks),
+		.eint_wkup_init = s3c24xx_eint_init,
+		.label		= "S3C2440-GPIO",
+	},
+};
+
+static struct samsung_pin_bank s3c2450_pin_banks[] = {
+	PIN_BANK_A(28, 0x000, "gpa"),
+	PIN_BANK_2BIT(11, 0x010, "gpb"),
+	PIN_BANK_2BIT(16, 0x020, "gpc"),
+	PIN_BANK_2BIT(16, 0x030, "gpd"),
+	PIN_BANK_2BIT(16, 0x040, "gpe"),
+	PIN_BANK_2BIT_EINTW(8, 0x050, "gpf", 0, 0xff),
+	PIN_BANK_2BIT_EINTW(16, 0x060, "gpg", 8, 0xffff00),
+	PIN_BANK_2BIT(15, 0x070, "gph"),
+	PIN_BANK_2BIT(16, 0x0d0, "gpj"),
+	PIN_BANK_2BIT(16, 0x0e0, "gpk"),
+	PIN_BANK_2BIT(15, 0x0f0, "gpl"),
+	PIN_BANK_2BIT(2, 0x100, "gpm"),
+};
+
+struct samsung_pin_ctrl s3c2450_pin_ctrl[] = {
+	{
+		.pin_banks	= s3c2450_pin_banks,
+		.nr_banks	= ARRAY_SIZE(s3c2450_pin_banks),
+		.eint_wkup_init = s3c24xx_eint_init,
+		.label		= "S3C2450-GPIO",
+	},
+};
diff --git a/drivers/pinctrl/pinctrl-samsung.c b/drivers/pinctrl/pinctrl-samsung.c
index e836135..234c32f 100644
--- a/drivers/pinctrl/pinctrl-samsung.c
+++ b/drivers/pinctrl/pinctrl-samsung.c
@@ -977,6 +977,16 @@ static const struct of_device_id samsung_pinctrl_dt_match[] = {
 	{ .compatible = "samsung,s3c64xx-pinctrl",
 		.data = s3c64xx_pin_ctrl },
 #endif
+#ifdef CONFIG_PINCTRL_S3C24XX
+	{ .compatible = "samsung,s3c2413-pinctrl",
+		.data = s3c2413_pin_ctrl },
+	{ .compatible = "samsung,s3c2416-pinctrl",
+		.data = s3c2416_pin_ctrl },
+	{ .compatible = "samsung,s3c2440-pinctrl",
+		.data = s3c2440_pin_ctrl },
+	{ .compatible = "samsung,s3c2450-pinctrl",
+		.data = s3c2450_pin_ctrl },
+#endif
 	{},
 };
 MODULE_DEVICE_TABLE(of, samsung_pinctrl_dt_match);
diff --git a/drivers/pinctrl/pinctrl-samsung.h b/drivers/pinctrl/pinctrl-samsung.h
index 7c7f9eb..c79d634 100644
--- a/drivers/pinctrl/pinctrl-samsung.h
+++ b/drivers/pinctrl/pinctrl-samsung.h
@@ -246,5 +246,9 @@ extern struct samsung_pin_ctrl exynos4210_pin_ctrl[];
 extern struct samsung_pin_ctrl exynos4x12_pin_ctrl[];
 extern struct samsung_pin_ctrl exynos5250_pin_ctrl[];
 extern struct samsung_pin_ctrl s3c64xx_pin_ctrl[];
+extern struct samsung_pin_ctrl s3c2413_pin_ctrl[];
+extern struct samsung_pin_ctrl s3c2416_pin_ctrl[];
+extern struct samsung_pin_ctrl s3c2440_pin_ctrl[];
+extern struct samsung_pin_ctrl s3c2450_pin_ctrl[];
 
 #endif /* __PINCTRL_SAMSUNG_H */
-- 
1.7.2.3



From martinez.javier at gmail.com  Sat Apr 13 21:35:44 2013
From: martinez.javier at gmail.com (Javier Martinez Canillas)
Date: Sun, 14 Apr 2013 03:35:44 +0200
Subject: [PATCH 3/5] gpio/omap: Add DT support to GPIO driver
In-Reply-To: <51673D70.3010503@wwwdotorg.org>
References: <1329321854-24490-1-git-send-email-b-cousson@ti.com>
 <4F47AD08.4030504@ti.com>
 <CAAwP0s0cB368R2mtbJpTZJreR-5GSRLfxC+8DJLo5nw3_OwBuA@mail.gmail.com>
 <512D39DA.7020306@ti.com> <512D3AB1.1080202@wwwdotorg.org>
 <512D3EC2.6050408@ti.com> <20130302200524.D230F3E1571@localhost>
 <51391F41.5000303@ti.com>
 <CAAwP0s1CFRO-rf==p5sYs1n0gigMif7wuT8Yv0N_iLUDMrtcOg@mail.gmail.com>
 <CACRpkdYHj-rEF3Rk_CWnmmMw_Amr7m8SgQ=-2zsDYuLeuu3azw@mail.gmail.com>
 <514C79E1.4090106@wwwdotorg.org> <514CE0AB.6060207@ti.com>
 <CACRpkdZmv-rAoKSQYpkHHSMzKJOn5TixVW_P3=m7ZNagBYCUPw@mail.gmail.com>
 <515319D5.20105@wwwdotorg.org>
 <CACRpkdYXVLgCz1Tyu-Ls2V2OTc4R3cGNJhfQJB6Hiz_K9dkZYQ@mail.gmail.com>
 <5155C902.7080207@wwwdotorg.org>
 <CACRpkdYbs4-uudpRUY8e+7icYYkZrfM0kReP3pLL5DMiURJ4dg@mail.gmail.com>
 <5165CB9D.1090202@wwwdotorg.org>
 <CACRpkdYirFNqmGhA4K9CL4ve4NYhs8Rd3SFt1iwW9vHBkrcz8g@mail.gmail.com>
 <51671D7B.5060303@wwwdotorg.org>
 <CACRpkdbf32Ef77GmXk9id9+RRjcDRTr7S+F4nznoeZU8y=BT_Q@mail.gmail.com>
 <51673D70.3010503@wwwdotorg.org>
Message-ID: <CAAwP0s0e2x33jZQhFRY+Hoo61SFqYKRgWk=1mL2+DNxSDJHz+A@mail.gmail.com>

On Fri, Apr 12, 2013 at 12:47 AM, Stephen Warren <swarren at wwwdotorg.org> wrote:
> On 04/11/2013 04:16 PM, Linus Walleij wrote:
>> On Thu, Apr 11, 2013 at 10:30 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
>>> On 04/10/2013 03:28 PM, Linus Walleij wrote:
>>
>>>> So the only reason I'm rambing on about this is that it breaks the
>>>
>>> I'm not sure I understand this paragraph; what is "it" in the line above.
>>>
>>> If "it" is this patch, then should "breaks" be re-establishes?
>>
>> No I'm replying to Javier Martinez Canillas mail in this thread:
>> http://marc.info/?l=linux-arm-kernel&m=136334655902407&w=2
>> which is stating a question to grand, and contains the below
>> hunk:
>>
>>> +static int gpio_irq_request(struct irq_data *d)
>>> +{
>>> +       struct gpio_bank *bank = irq_data_get_irq_chip_data(d);
>>> +
>>> +       return gpio_request(irq_to_gpio(bank, d->irq), "gpio-irq");
>>> +}
>>
>> irq_to_gpio(). Notice that. not my_funny_driver_irq_to_gpio().
>
> OK, right. sorry for being so confused/confusing.
>
> Yes, that code should certainly call e.g. omap_gpio__irq_to_gpio() not
> irq_to_gpio(). Probably gpio_irq_request() wants renaming to something
> more like omap_gpio__irq_request() too, so the names don't look like
> they'd clash with global functions. (__ added for clarity but probably
> only one _ at a time)

Stephen, Linus,

Is the following inlined patch [1] what you were thinking that would
be the right approach?

With this patch an explicit call to call gpio_request() before a call
to chip->irq_set_type() is needed. I've tested both with DT and
without DT where a explicit call to gpio_request() is made and it
works in both cases. So it shouldn't have a functional change for
non-DT cases as far as I know.

If you agree with [1] then I'll split in two patches (one that adds
the irq_request function pointer to irq_chip and another one that adds
the implementation for gpio-omap) and send as a patch-set. I just
thought that it would be easier for you if I posted here an inlined
patch so you could have context.

Thanks a lot for your feedback and best regards,
Javier

[1]
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 685e850..e035e64 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -811,6 +811,13 @@ static void gpio_unmask_irq(struct irq_data *d)
 	spin_unlock_irqrestore(&bank->lock, flags);
 }

+static int omap_gpio_irq_request(struct irq_data *d)
+{
+	struct gpio_bank *bank = irq_data_get_irq_chip_data(d);
+
+	return omap_gpio_request(&bank->chip, d->hwirq);
+}
+
 static struct irq_chip gpio_irq_chip = {
 	.name		= "GPIO",
 	.irq_shutdown	= gpio_irq_shutdown,
@@ -819,6 +826,7 @@ static struct irq_chip gpio_irq_chip = {
 	.irq_unmask	= gpio_unmask_irq,
 	.irq_set_type	= gpio_irq_type,
 	.irq_set_wake	= gpio_wake_enable,
+	.irq_request    = omap_gpio_irq_request,
 };

 /*---------------------------------------------------------------------*/
@@ -1028,6 +1036,7 @@ omap_mpuio_alloc_gc(struct gpio_bank *bank,
unsigned int irq_start,
 	ct->chip.irq_mask = irq_gc_mask_set_bit;
 	ct->chip.irq_unmask = irq_gc_mask_clr_bit;
 	ct->chip.irq_set_type = gpio_irq_type;
+	ct->chip.irq_request = omap_gpio_irq_request;

 	if (bank->regs->wkup_en)
 		ct->chip.irq_set_wake = gpio_wake_enable,
diff --git a/include/linux/irq.h b/include/linux/irq.h
index 0e8e3a6..85596cc 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -303,6 +303,7 @@ struct irq_chip {
 	void		(*irq_shutdown)(struct irq_data *data);
 	void		(*irq_enable)(struct irq_data *data);
 	void		(*irq_disable)(struct irq_data *data);
+	int             (*irq_request)(struct irq_data *data);

 	void		(*irq_ack)(struct irq_data *data);
 	void		(*irq_mask)(struct irq_data *data);
diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
index fa17855..a4bd4f7 100644
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -588,6 +588,12 @@ int __irq_set_trigger(struct irq_desc *desc,
unsigned int irq,
 			unmask = 1;
 	}

+	if (chip->irq_request) {
+			ret = chip->irq_request(&desc->irq_data);
+			if (ret)
+				return ret;
+	}
+
 	/* caller masked out all except trigger mode flags */
 	ret = chip->irq_set_type(&desc->irq_data, flags);


From robdclark at gmail.com  Sun Apr 14 00:29:46 2013
From: robdclark at gmail.com (Rob Clark)
Date: Sun, 14 Apr 2013 00:29:46 -0400
Subject: Latest randconfig build errors
In-Reply-To: <20130413214539.GA32613@avionic-0098.mockup.avionic-design.de>
References: <20130304095136.GI17833@n2100.arm.linux.org.uk>
 <20130304184649.GO11806@atomide.com>
 <CAF6AEGv=3453KKS9-8YAgHrxMMbNvLMvt0pz-=qdG+zcd-Trrw@mail.gmail.com>
 <20130413214539.GA32613@avionic-0098.mockup.avionic-design.de>
Message-ID: <CAF6AEGtbqT23bjniwmGP-PhcxRPk5Q9aDaWM-=vVgkVrvDbCaQ@mail.gmail.com>

On Sat, Apr 13, 2013 at 5:45 PM, Thierry Reding
<thierry.reding at avionic-design.de> wrote:
> On Sat, Apr 13, 2013 at 08:54:22AM -0400, Rob Clark wrote:
>> On Mon, Mar 4, 2013 at 1:46 PM, Tony Lindgren <tony at atomide.com> wrote:
>> >
>> >> drivers/gpu/drm/tilcdc/tilcdc_slave.o:(.data+0x54): multiple definition of `__mod_of_device_table'
>> >> drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54): first defined here
>> >> drivers/gpu/drm/tilcdc/tilcdc_panel.o:(.data+0x54): multiple definition of `__mod_of_device_table'
>> >> drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54): first defined here
>> >> drivers/gpu/drm/tilcdc/tilcdc_drv.o:(.data+0x184): multiple definition of `__mod_of_device_table'
>> >> drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54): first defined here
>> >
>> > Rob, I assume you'll do a patch for this one?
>>
>>
>> oh, I apologize for the late reply, I didn't see this email...
>>
>> There is a patch that we can merge to make tilcdc bool instead of
>> tristate[1], which I suppose is ok for a temporary fix.  Although I'm
>> all-ears if someone has a better idea about how to fix this.  The
>> problem is that we have multiple sub-devices for different possible
>> panel drivers, so that depending on DT tables, the correct ones get
>> loaded for the hw.  But they are all built into a single module.
>> Splitting them into multiple modules will be problematic, as panel
>> drivers which are present really need to get probed before the
>> toplevel drm device..
>
> You could look at the Tegra driver. I had to solve a similar problem
> there. What I did is basically parse the DT in the host1x driver and add
> all device nodes which are required by DRM to a list. Later when the
> individual devices are probed they are removed from that list, so that
> when the list becomes empty we are sure that all required devices are
> there and only then call the drm_platform_init() function.

thx, ok, I'll have a look at this

> This fits very well with how Tegra hardware is designed because host1x
> is the parent for all DRM subdevices (DC, RGB/LVDS, HDMI, ...). So it is
> probed before any of its children and it can easily parse the DT upfront
> and initialize the list of required devices.
>
>> I suppose in theory it is possible to make drm
>> cope better with dynamically loaded outputs, but I'm not sure that
>> there is any way to do this without breaking userspace which expects
>> that all of the connectors/encoders are present once the drm device is
>> loaded.
>
> I had been thinking about this on and off for a while, but I haven't
> come up with anything concrete. Ideally we could just have some kind of
> event that userspace would listen for, so that new outputs can be
> dynamically added and userspace informed about them. Last time I checked
> most of the helpers assumed that the complete output configuration is
> known when the DRM device is registered, so some major rework will be
> required to efficiently make use of such dynamicity.

I'm less worried about the kernel re-work.. more worried about the
fact that we have no way to know whether userspace knows to listen for
this new event.  So anything down this path could, I think, be
considered as breaking userspace.

I think in the end, we need some way to have sort of "dummy"
connectors for output drivers which might or might not be probed, so
that from userspace perspective, non-present panels appear as displays
that are not plugged in.

BR,
-R


> Thierry


From linux at prisktech.co.nz  Sun Apr 14 01:28:35 2013
From: linux at prisktech.co.nz (Tony Prisk)
Date: Sun, 14 Apr 2013 17:28:35 +1200
Subject: [PATCH] clk: vt8500: Missing breaks in vtwm_pll_round_rate/_set_rate.
Message-ID: <1365917315-3615-1-git-send-email-linux@prisktech.co.nz>

The case of PLL_TYPE_WM8750 in both these functions is missing a break
statement causing a fall-through to the default: case.

Insert the missing break statements.

Signed-off-by: Tony Prisk <linux at prisktech.co.nz>
---
Mike,

Any chance this can still go in as a fix for 3.9
The fault makes it impossible to set the PLL clocks on WM8750 and later SoCs.

Regards
Tony P
 drivers/clk/clk-vt8500.c |    2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/clk/clk-vt8500.c b/drivers/clk/clk-vt8500.c
index 09c6331..debf688 100644
--- a/drivers/clk/clk-vt8500.c
+++ b/drivers/clk/clk-vt8500.c
@@ -488,6 +488,7 @@ static int vtwm_pll_set_rate(struct clk_hw *hw, unsigned long rate,
 	case PLL_TYPE_WM8750:
 		wm8750_find_pll_bits(rate, parent_rate, &filter, &mul, &div1, &div2);
 		pll_val = WM8750_BITS_TO_VAL(filter, mul, div1, div2);
+		break;
 	default:
 		pr_err("%s: invalid pll type\n", __func__);
 		return 0;
@@ -523,6 +524,7 @@ static long vtwm_pll_round_rate(struct clk_hw *hw, unsigned long rate,
 	case PLL_TYPE_WM8750:
 		wm8750_find_pll_bits(rate, *prate, &filter, &mul, &div1, &div2);
 		round_rate = WM8750_BITS_TO_FREQ(*prate, mul, div1, div2);
+		break;
 	default:
 		round_rate = 0;
 	}
-- 
1.7.9.5



From joe at perches.com  Sun Apr 14 01:55:45 2013
From: joe at perches.com (Joe Perches)
Date: Sat, 13 Apr 2013 22:55:45 -0700
Subject: [PATCH] ARM: KVM: Add missing break;
In-Reply-To: <1365917315-3615-1-git-send-email-linux@prisktech.co.nz>
References: <1365917315-3615-1-git-send-email-linux@prisktech.co.nz>
Message-ID: <1365918945.1878.8.camel@joe-AO722>

commit 3401d54696f ("KVM: ARM: Introduce KVM_ARM_SET_DEVICE_ADDR ioctl")
added the case, but omitted adding break;

Add it.

Found with grep version 2.54 pattern:

$ grep -rP --include=*.[ch] "\b(\w+)\s*=[^;]+;\s*(?:case\s+\w+:|default:)\s*\1\s*="

Signed-off-by: Joe Perches <joe at perches.com>
---
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index 5777e0c..b9f2228 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -198,6 +198,7 @@ int kvm_dev_ioctl_check_extension(long ext)
 		break;
 	case KVM_CAP_ARM_SET_DEVICE_ADDR:
 		r = 1;
+		break;
 	case KVM_CAP_NR_VCPUS:
 		r = num_online_cpus();
 		break;




From mturquette at linaro.org  Sun Apr 14 03:00:56 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Sun, 14 Apr 2013 00:00:56 -0700
Subject: [PATCH] clk: si5351: Add gapless tuning for SI5351 PLL
In-Reply-To: <51685F60.9010802@gmail.com>
References: <1365495975-792-1-git-send-email-michal.bachraty@streamunlimited.com>
 <20130412183809.6507.27844@quantum> <51685F60.9010802@gmail.com>
Message-ID: <20130414070056.6507.87735@quantum>

Quoting Sebastian Hesselbarth (2013-04-12 12:24:16)
> On 04/12/2013 08:38 PM, Mike Turquette wrote:
> > Quoting Michal Bachraty (2013-04-09 01:26:15)
> >> For gapless tuning, there is no need for PLL reset and clkout power-down
> >> when tuning output. "silabs,gapless-tuning" parameter enables gapless tuning
> >> for specific clock output.
> >>
> >> Signed-off-by: Michal Bachraty<michal.bachraty at streamunlimited.com>
> >
> > Hi Michal,
> >
> > This did not apply cleanly on the latest (v8) si5351 clk driver.  Can
> > you refresh it?  I do not plan on taking any more patches for 3.10 after
> > 3.9-rc7 drops (likely on Sunday or Monday).  So this patch may need to
> > wait until after the merge window.
> 
> Mike,
> 
> I have integrated the above function into clk-si5351 during development
> (see clk-si5351 changelog from v6->v7). I think we can drop this patch,
> as Michal added his Tested-by to clk-si5351.
> 

Great.

Thanks,
Mike

> Regards,
>    Sebastian


From mturquette at linaro.org  Sun Apr 14 03:03:38 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Sun, 14 Apr 2013 00:03:38 -0700
Subject: [PATCH] clk: vt8500: Missing breaks in
 vtwm_pll_round_rate/_set_rate.
In-Reply-To: <1365917315-3615-1-git-send-email-linux@prisktech.co.nz>
References: <1365917315-3615-1-git-send-email-linux@prisktech.co.nz>
Message-ID: <20130414070338.6507.10991@quantum>

Quoting Tony Prisk (2013-04-13 22:28:35)
> The case of PLL_TYPE_WM8750 in both these functions is missing a break
> statement causing a fall-through to the default: case.
> 
> Insert the missing break statements.
> 
> Signed-off-by: Tony Prisk <linux at prisktech.co.nz>
> ---
> Mike,
> 
> Any chance this can still go in as a fix for 3.9
> The fault makes it impossible to set the PLL clocks on WM8750 and later SoCs.

Definitely not too late for fixes.  Taken into clk-next.

Thanks,
Mike

> 
> Regards
> Tony P
>  drivers/clk/clk-vt8500.c |    2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/clk/clk-vt8500.c b/drivers/clk/clk-vt8500.c
> index 09c6331..debf688 100644
> --- a/drivers/clk/clk-vt8500.c
> +++ b/drivers/clk/clk-vt8500.c
> @@ -488,6 +488,7 @@ static int vtwm_pll_set_rate(struct clk_hw *hw, unsigned long rate,
>         case PLL_TYPE_WM8750:
>                 wm8750_find_pll_bits(rate, parent_rate, &filter, &mul, &div1, &div2);
>                 pll_val = WM8750_BITS_TO_VAL(filter, mul, div1, div2);
> +               break;
>         default:
>                 pr_err("%s: invalid pll type\n", __func__);
>                 return 0;
> @@ -523,6 +524,7 @@ static long vtwm_pll_round_rate(struct clk_hw *hw, unsigned long rate,
>         case PLL_TYPE_WM8750:
>                 wm8750_find_pll_bits(rate, *prate, &filter, &mul, &div1, &div2);
>                 round_rate = WM8750_BITS_TO_FREQ(*prate, mul, div1, div2);
> +               break;
>         default:
>                 round_rate = 0;
>         }
> -- 
> 1.7.9.5


From gwenhael.goavec-merou at armadeus.com  Sun Apr 14 03:44:25 2013
From: gwenhael.goavec-merou at armadeus.com (Gwenhael Goavec-Merou)
Date: Sun, 14 Apr 2013 09:44:25 +0200
Subject: [PATCH v2] ARM: imx27: Add PWM0 to device tree
Message-ID: <1365925465-17453-1-git-send-email-gwenhael.goavec-merou@armadeus.com>


Signed-off-by: Gwenhael Goavec-Merou <gwenhael.goavec-merou at armadeus.com>
---
v2:
- Suppress status, now PWM is always enabled;
- Suppress platform patch.

 arch/arm/boot/dts/imx27.dtsi | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/imx27.dtsi b/arch/arm/boot/dts/imx27.dtsi
index ff4bd48..14e97cf 100644
--- a/arch/arm/boot/dts/imx27.dtsi
+++ b/arch/arm/boot/dts/imx27.dtsi
@@ -89,6 +89,14 @@
 				clock-names = "ipg", "per";
 			};
 
+			pwm0: pwm at 10006000 {
+				compatible = "fsl,imx27-pwm";
+				reg = <0x10006000 0x1000>;
+				interrupts = <23>;
+				clocks = <&clks 34>, <&clks 61>;
+				clock-names = "ipg", "per";
+			};
+
 			uart1: serial at 1000a000 {
 				compatible = "fsl,imx27-uart", "fsl,imx21-uart";
 				reg = <0x1000a000 0x1000>;
-- 
1.8.1.5



From s.hauer at pengutronix.de  Sun Apr 14 04:42:40 2013
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Sun, 14 Apr 2013 10:42:40 +0200
Subject: [PATCH] tty/serial: add MVF uart driver support
In-Reply-To: <CAOMZO5D-uQQJAc6zAMkF9ViR0KWg4q7cPr7+pLdfyAm9gtPyTA@mail.gmail.com>
References: <1365750655-3530-1-git-send-email-b35083@freescale.com>
 <CAOMZO5D-uQQJAc6zAMkF9ViR0KWg4q7cPr7+pLdfyAm9gtPyTA@mail.gmail.com>
Message-ID: <20130414084240.GY1906@pengutronix.de>

On Sat, Apr 13, 2013 at 05:41:26PM -0300, Fabio Estevam wrote:
> On Fri, Apr 12, 2013 at 4:10 AM, Jingchang Lu <b35083 at freescale.com> wrote:
> > It adds Freescale Vybrid Family uart driver support
> >
> > Signed-off-by: Jingchang Lu <b35083 at freescale.com>
> > ---
> >  drivers/tty/serial/Kconfig       |   17 +
> >  drivers/tty/serial/Makefile      |    1 +
> >  drivers/tty/serial/mvf.c         | 1246 ++++++++++++++++++++++++++++++++++++++
> >  include/uapi/linux/serial_core.h |    3 +
> >  4 files changed, 1267 insertions(+)
> >  create mode 100644 drivers/tty/serial/mvf.c
> 
> Would it be possible to add Vybrid support into the existing imx serial port?

That's completely different hardware.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From s.hauer at pengutronix.de  Sun Apr 14 04:49:27 2013
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Sun, 14 Apr 2013 10:49:27 +0200
Subject: [PATCH v2] ARM: imx27: Add PWM0 to device tree
In-Reply-To: <1365925465-17453-1-git-send-email-gwenhael.goavec-merou@armadeus.com>
References: <1365925465-17453-1-git-send-email-gwenhael.goavec-merou@armadeus.com>
Message-ID: <20130414084927.GA1906@pengutronix.de>

On Sun, Apr 14, 2013 at 09:44:25AM +0200, Gwenhael Goavec-Merou wrote:
> 
> Signed-off-by: Gwenhael Goavec-Merou <gwenhael.goavec-merou at armadeus.com>

Acked-by: Sascha Hauer <s.hauer at pengutronix.de>

Sascha

> ---
> v2:
> - Suppress status, now PWM is always enabled;
> - Suppress platform patch.
> 
>  arch/arm/boot/dts/imx27.dtsi | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/imx27.dtsi b/arch/arm/boot/dts/imx27.dtsi
> index ff4bd48..14e97cf 100644
> --- a/arch/arm/boot/dts/imx27.dtsi
> +++ b/arch/arm/boot/dts/imx27.dtsi
> @@ -89,6 +89,14 @@
>  				clock-names = "ipg", "per";
>  			};
>  
> +			pwm0: pwm at 10006000 {
> +				compatible = "fsl,imx27-pwm";
> +				reg = <0x10006000 0x1000>;
> +				interrupts = <23>;
> +				clocks = <&clks 34>, <&clks 61>;
> +				clock-names = "ipg", "per";
> +			};
> +
>  			uart1: serial at 1000a000 {
>  				compatible = "fsl,imx27-uart", "fsl,imx21-uart";
>  				reg = <0x1000a000 0x1000>;
> -- 
> 1.8.1.5
> 
> 

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From mpa at pengutronix.de  Sun Apr 14 06:38:19 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Sun, 14 Apr 2013 12:38:19 +0200
Subject: [PATCH v2 05/11] ASoC: fsl-ssi: Add support for imx-pcm-fiq
In-Reply-To: <51620CEA.3010703@tabi.org>
References: <1365362721-3731-1-git-send-email-mpa@pengutronix.de>
 <1365362721-3731-6-git-send-email-mpa@pengutronix.de>
 <51620CEA.3010703@tabi.org>
Message-ID: <20130414103819.GA27394@pengutronix.de>

On Sun, Apr 07, 2013 at 07:18:50PM -0500, Timur Tabi wrote:
> Markus Pargmann wrote:
> >Add support for non-dma pcm for imx platforms with imx-pcm-fiq support.
> >Instead of imx-pcm-audio, in this case imx-pcm-fiq-audio device is added
> >and the SIER flags are set differently.
> 
> So just to be clear, this is interrupt-driven SSI audio?  So you're
> generating an interrupt every time the transmit FIFO goes below the
> threshold?

Yes

> I wonder if it makes sense to enable both FIFOs, so that you take
> half as many interrupts per second.

It looks like imx-pcm-fiq and ssi-fiq.s do not support transmitting
through two FIFOs at the moment.

> 
> >
> >Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
> >---
> >  sound/soc/fsl/fsl_ssi.c | 70 ++++++++++++++++++++++++++++++++++++++++---------
> >  1 file changed, 58 insertions(+), 12 deletions(-)
> >
> >diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
> >index 7decbd9..afb5a23 100644
> >--- a/sound/soc/fsl/fsl_ssi.c
> >+++ b/sound/soc/fsl/fsl_ssi.c
> >@@ -120,10 +120,12 @@ struct fsl_ssi_private {
> >
> >  	bool new_binding;
> >  	bool ssi_on_imx;
> >+	bool dma;
> 
> Can you rename this to "use_dma" or something like that?

Done.

> 
> >  	struct clk *clk;
> >  	struct platform_device *imx_pcm_pdev;
> >  	struct imx_pcm_dma_params dma_params_tx;
> >  	struct imx_pcm_dma_params dma_params_rx;
> >+	struct imx_pcm_fiq_params fiq_params;
> >
> >  	struct {
> >  		unsigned int rfrc;
> >@@ -353,7 +355,8 @@ static int fsl_ssi_startup(struct snd_pcm_substream *substream,
> >  		 */
> >
> >  		/* Enable the interrupts and DMA requests */
> >-		write_ssi(SIER_FLAGS, &ssi->sier);
> >+		if (ssi_private->dma)
> >+			write_ssi(SIER_FLAGS, &ssi->sier);
> >
> >  		/*
> >  		 * Set the watermark for transmit FIFI 0 and receive FIFO 0. We
> >@@ -520,6 +523,18 @@ static int fsl_ssi_trigger(struct snd_pcm_substream *substream, int cmd,
> >  		return -EINVAL;
> >  	}
> >
> >+	if (!ssi_private->dma) {
> >+		if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
> >+			write_ssi(CCSR_SSI_SOR_TX_CLR, &ssi->sor);
> >+			write_ssi(CCSR_SSI_SIER_TIE | CCSR_SSI_SIER_TFE0_EN,
> >+					&ssi->sier);
> >+		} else {
> >+			write_ssi(CCSR_SSI_SOR_RX_CLR, &ssi->sor);
> >+			write_ssi(CCSR_SSI_SIER_RIE | CCSR_SSI_SIER_RFF0_EN,
> >+					&ssi->sier);
> >+		}
> >+	}
> >+
> >  	return 0;
> >  }
> >
> >@@ -680,6 +695,8 @@ static int fsl_ssi_probe(struct platform_device *pdev)
> >  	       sizeof(fsl_ssi_dai_template));
> >  	ssi_private->cpu_dai_drv.name = ssi_private->name;
> >
> >+	ssi_private->dma = !of_property_read_bool(np, "fsl,imx-fiq");
> 
> Instead of looking for the FIQ property, maybe you should just look
> for the absence of a DMA property/node, and then default to
> interrupts if there is no DMA.  That would make it more generic, and
> even work on non-IMX systems.

I do not think it is possible. For example imx27 ssi does support
DMA but for specific boards we have to use fiq instead (phycore-ac97).
So I would prefer to define the DMA in the chip dtsi file and choose
fiq, if necessary, in the board dts.

Regards,

Markus

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From mpa at pengutronix.de  Sun Apr 14 07:42:50 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Sun, 14 Apr 2013 13:42:50 +0200
Subject: [PATCH v3 06/15] ASoC: imx-pcm-dma: DT support
In-Reply-To: <1365939779-4507-1-git-send-email-mpa@pengutronix.de>
References: <1365939779-4507-1-git-send-email-mpa@pengutronix.de>
Message-ID: <1365939779-4507-7-git-send-email-mpa@pengutronix.de>

From: Markus Pargmann <mpa at pengutrnoix.de>

This patch adds the possibility to pass a of_node as platform_data which
is used by generic-pcm-dma to request a DMA slave channel.

Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
---
 sound/soc/fsl/imx-pcm-dma.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/sound/soc/fsl/imx-pcm-dma.c b/sound/soc/fsl/imx-pcm-dma.c
index 9eb0021..a6cdae7 100644
--- a/sound/soc/fsl/imx-pcm-dma.c
+++ b/sound/soc/fsl/imx-pcm-dma.c
@@ -62,9 +62,11 @@ static const struct snd_dmaengine_pcm_config imx_dmaengine_pcm_config = {
 
 int imx_pcm_dma_init(struct platform_device *pdev)
 {
+	if (pdev->dev.platform_data)
+		pdev->dev.of_node = pdev->dev.platform_data;
+
 	return snd_dmaengine_pcm_register(&pdev->dev, &imx_dmaengine_pcm_config,
 		SND_DMAENGINE_PCM_FLAG_NO_RESIDUE |
-		SND_DMAENGINE_PCM_FLAG_NO_DT |
 		SND_DMAENGINE_PCM_FLAG_COMPAT);
 }
 
-- 
1.8.1.5



From mpa at pengutronix.de  Sun Apr 14 07:42:47 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Sun, 14 Apr 2013 13:42:47 +0200
Subject: [PATCH v3 03/15] ASoC: dmaengine-pcm: Fix function name
In-Reply-To: <1365939779-4507-1-git-send-email-mpa@pengutronix.de>
References: <1365939779-4507-1-git-send-email-mpa@pengutronix.de>
Message-ID: <1365939779-4507-4-git-send-email-mpa@pengutronix.de>

From: Markus Pargmann <mpa at pengutrnoix.de>

Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
---
 sound/soc/soc-generic-dmaengine-pcm.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/sound/soc/soc-generic-dmaengine-pcm.c b/sound/soc/soc-generic-dmaengine-pcm.c
index 2e25402..f752577 100644
--- a/sound/soc/soc-generic-dmaengine-pcm.c
+++ b/sound/soc/soc-generic-dmaengine-pcm.c
@@ -50,7 +50,8 @@ int snd_dmaengine_pcm_prepare_slave_config(struct snd_pcm_substream *substream,
 	if (ret)
 		return ret;
 
-	snd_dmaengine_set_config_from_dai_data(substream, dma_data, slave_config);
+	snd_dmaengine_pcm_set_config_from_dai_data(substream, dma_data,
+			slave_config);
 
 	return 0;
 }
-- 
1.8.1.5



From mpa at pengutronix.de  Sun Apr 14 07:42:44 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Sun, 14 Apr 2013 13:42:44 +0200
Subject: [PATCH v3 00/15] ASoC: fsl-ssi: ac97-slave support
Message-ID: <1365939779-4507-1-git-send-email-mpa@pengutronix.de>

Hi,

This series adds DT support for phycore-ac97. It is now based on the pcm dma
cleanups from Lars. Beside ac97 support, the series adds fsl-ssi imx-pcm-fiq
and generic DMA binding handling.

@Lars:
There are 4 new patches at the beginning of the series that fix some problems
of your cleanups. I think they were in the changes you posted. If not, could you
please add them to your branch?

Regards,

Markus


Changes in v3:
 - Rebased onto pcm dma cleanup patches
 - A lot of cleanups for the fsl-ssi ac97 integration
 - Some small changes which are listed in the notes of the patches.


Markus Pargmann (15):
      ASoC: imx-ssi: Fix includes
      ASoC: dmaengine-pcm: Replace of specific helper function
      ASoC: dmaengine-pcm: Fix function name
      ASoC: dmaengine-pcm: Fix pcm_request_chan function name
      ASoC: phycore-ac97: Add DT support
      ASoC: imx-pcm-dma: DT support
      ASoC: imx-pcm-fiq: Introduce pcm-fiq-params
      ASoC: fsl-ssi: Add SACNT definitions
      ASoC: fsl-ssi: Add support for imx-pcm-fiq
      ASoC: fsl-ssi: Use generic DMA bindings if possible
      ARM: imx: Export ac97 reset functions
      ASoC: fsl-ssi: imx ac97 support
      ASoC: fsl: Kconfig: Use fsl-ssi for phycore-ac97
      ASoC: fsl: Move fsl-ssi binding doc to sound/
      ASoC: fsl: Update fsl-ssi binding doc

 Documentation/devicetree/bindings/{powerpc/fsl/ssi.txt => sound/fsl,ssi.txt} |   7 +
 Documentation/devicetree/bindings/sound/phytec,phycore-ac97.txt              |  12 ++
 arch/arm/mach-imx/mach-pca100.c                                              |   7 +-
 arch/arm/mach-imx/mach-pcm043.c                                              |   7 +-
 include/sound/dmaengine_pcm.h                                                |   2 +-
 sound/soc/fsl/Kconfig                                                        |   2 +-
 sound/soc/fsl/fsl_ssi.c                                                      | 484 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++-------------
 sound/soc/fsl/fsl_ssi.h                                                      |   8 ++
 sound/soc/fsl/imx-pcm-dma.c                                                  |   4 +-
 sound/soc/fsl/imx-pcm-fiq.c                                                  |  16 ++-
 sound/soc/fsl/imx-pcm.h                                                      |   9 ++
 sound/soc/fsl/imx-ssi.c                                                      |   7 +-
 sound/soc/fsl/imx-ssi.h                                                      |   2 +
 sound/soc/fsl/phycore-ac97.c                                                 | 184 +++++++++++++++++++++++----
 sound/soc/soc-generic-dmaengine-pcm.c                                        |   9 +-
 sound/soc/spear/spear_pcm.c                                                  |   2 +-
 16 files changed, 634 insertions(+), 128 deletions(-)
 rename Documentation/devicetree/bindings/{powerpc/fsl/ssi.txt => sound/fsl,ssi.txt} (92%)
 create mode 100644 Documentation/devicetree/bindings/sound/phytec,phycore-ac97.txt



From mpa at pengutronix.de  Sun Apr 14 07:42:59 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Sun, 14 Apr 2013 13:42:59 +0200
Subject: [PATCH v3 15/15] ASoC: fsl: Update fsl-ssi binding doc
In-Reply-To: <1365939779-4507-1-git-send-email-mpa@pengutronix.de>
References: <1365939779-4507-1-git-send-email-mpa@pengutronix.de>
Message-ID: <1365939779-4507-16-git-send-email-mpa@pengutronix.de>

Update the fsl-ssi bindings. DMA is no required property anymore and
uses the generic DMA bindings. imx-fiq is a new alternative to DMA

Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
---

Notes:
    Changes in v3:
     - In previous versions, I removed fsl,playback-dma and capture-dma. But they
       are still in use by fsl_dma.c, so I added them again.

 Documentation/devicetree/bindings/sound/fsl,ssi.txt | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/devicetree/bindings/sound/fsl,ssi.txt b/Documentation/devicetree/bindings/sound/fsl,ssi.txt
index 5ff76c9..6ea2ff2 100644
--- a/Documentation/devicetree/bindings/sound/fsl,ssi.txt
+++ b/Documentation/devicetree/bindings/sound/fsl,ssi.txt
@@ -43,10 +43,17 @@ Required properties:
                     together.  This would still allow different sample sizes,
                     but not different sample rates.
 
+Note that either dmas, dma-names or fsl,imx-fiq are required.
+
 Optional properties:
 - codec-handle:     Phandle to a 'codec' node that defines an audio
                     codec connected to this SSI.  This node is typically
                     a child of an I2C or other control node.
+- dmas:		    Generic dma devicetree binding as described in
+		    Documentation/devicetree/bindings/dma/dma.txt.
+- dma-names:	    Two dmas have to be defined, "tx" and "rx", if fsl,imx-fiq
+		    is not defined.
+- fsl,imx-fiq:	    Bool property. Use imx-pcm-fiq instead of imx-pcm-dma.
 
 Child 'codec' node required properties:
 - compatible:       Compatible list, contains the name of the codec
-- 
1.8.1.5



From mpa at pengutronix.de  Sun Apr 14 07:42:46 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Sun, 14 Apr 2013 13:42:46 +0200
Subject: [PATCH v3 02/15] ASoC: dmaengine-pcm: Replace of specific helper
 function
In-Reply-To: <1365939779-4507-1-git-send-email-mpa@pengutronix.de>
References: <1365939779-4507-1-git-send-email-mpa@pengutronix.de>
Message-ID: <1365939779-4507-3-git-send-email-mpa@pengutronix.de>

From: Markus Pargmann <mpa at pengutrnoix.de>

Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
---
 sound/soc/soc-generic-dmaengine-pcm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/sound/soc/soc-generic-dmaengine-pcm.c b/sound/soc/soc-generic-dmaengine-pcm.c
index d5467ff..2e25402 100644
--- a/sound/soc/soc-generic-dmaengine-pcm.c
+++ b/sound/soc/soc-generic-dmaengine-pcm.c
@@ -221,9 +221,9 @@ int snd_dmaengine_pcm_register(struct device *dev,
 	if (flags & SND_DMAENGINE_PCM_FLAG_COMPAT)
 		pcm->compat = true;
 
-	if (!(flags & SND_DMAENGINE_PCM_FLAG_NO_DT) && dev->of_node) {
+	if (!(flags & SND_DMAENGINE_PCM_FLAG_NO_DT)) {
 		for (i = SNDRV_PCM_STREAM_PLAYBACK; i <= SNDRV_PCM_STREAM_CAPTURE; i++) {
-			pcm->chan[i] = of_dma_request_slave_channel(dev->of_node,
+			pcm->chan[i] = dma_request_slave_channel(dev,
 					dmaengine_pcm_dma_channel_names[i]);
 		}
 	}
-- 
1.8.1.5



From mpa at pengutronix.de  Sun Apr 14 07:42:45 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Sun, 14 Apr 2013 13:42:45 +0200
Subject: [PATCH v3 01/15] ASoC: imx-ssi: Fix includes
In-Reply-To: <1365939779-4507-1-git-send-email-mpa@pengutronix.de>
References: <1365939779-4507-1-git-send-email-mpa@pengutronix.de>
Message-ID: <1365939779-4507-2-git-send-email-mpa@pengutronix.de>

From: Markus Pargmann <mpa at pengutrnoix.de>

Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
---
 sound/soc/fsl/imx-ssi.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sound/soc/fsl/imx-ssi.h b/sound/soc/fsl/imx-ssi.h
index d8063c2..bb6b3db 100644
--- a/sound/soc/fsl/imx-ssi.h
+++ b/sound/soc/fsl/imx-ssi.h
@@ -187,6 +187,7 @@
 
 #include <linux/dmaengine.h>
 #include <linux/platform_data/dma-imx.h>
+#include <sound/dmaengine_pcm.h>
 #include "imx-pcm.h"
 
 struct imx_ssi {
-- 
1.8.1.5



From mpa at pengutronix.de  Sun Apr 14 07:42:55 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Sun, 14 Apr 2013 13:42:55 +0200
Subject: [PATCH v3 11/15] ARM: imx: Export ac97 reset functions
In-Reply-To: <1365939779-4507-1-git-send-email-mpa@pengutronix.de>
References: <1365939779-4507-1-git-send-email-mpa@pengutronix.de>
Message-ID: <1365939779-4507-12-git-send-email-mpa@pengutronix.de>

Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
---
 arch/arm/mach-imx/mach-pca100.c | 7 +++++--
 arch/arm/mach-imx/mach-pcm043.c | 7 +++++--
 2 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-imx/mach-pca100.c b/arch/arm/mach-imx/mach-pca100.c
index b8b15bb..68badf8 100644
--- a/arch/arm/mach-imx/mach-pca100.c
+++ b/arch/arm/mach-imx/mach-pca100.c
@@ -22,6 +22,7 @@
 #include <linux/i2c.h>
 #include <linux/i2c/at24.h>
 #include <linux/dma-mapping.h>
+#include <linux/export.h>
 #include <linux/spi/spi.h>
 #include <linux/spi/eeprom.h>
 #include <linux/irq.h>
@@ -208,7 +209,7 @@ static const struct spi_imx_master pca100_spi0_data __initconst = {
 	.num_chipselect = ARRAY_SIZE(pca100_spi_cs),
 };
 
-static void pca100_ac97_warm_reset(struct snd_ac97 *ac97)
+void pca100_ac97_warm_reset(struct snd_ac97 *ac97)
 {
 	mxc_gpio_mode(GPIO_PORTC | 20 | GPIO_GPIO | GPIO_OUT);
 	gpio_set_value(GPIO_PORTC + 20, 1);
@@ -217,8 +218,9 @@ static void pca100_ac97_warm_reset(struct snd_ac97 *ac97)
 	mxc_gpio_mode(PC20_PF_SSI1_FS);
 	msleep(2);
 }
+EXPORT_SYMBOL(pca100_ac97_warm_reset);
 
-static void pca100_ac97_cold_reset(struct snd_ac97 *ac97)
+void pca100_ac97_cold_reset(struct snd_ac97 *ac97)
 {
 	mxc_gpio_mode(GPIO_PORTC | 20 | GPIO_GPIO | GPIO_OUT);  /* FS */
 	gpio_set_value(GPIO_PORTC + 20, 0);
@@ -232,6 +234,7 @@ static void pca100_ac97_cold_reset(struct snd_ac97 *ac97)
 	mxc_gpio_mode(PC22_PF_SSI1_TXD);
 	msleep(2);
 }
+EXPORT_SYMBOL(pca100_ac97_cold_reset);
 
 static const struct imx_ssi_platform_data pca100_ssi_pdata __initconst = {
 	.ac97_reset		= pca100_ac97_cold_reset,
diff --git a/arch/arm/mach-imx/mach-pcm043.c b/arch/arm/mach-imx/mach-pcm043.c
index 8ed533f..4f318ca 100644
--- a/arch/arm/mach-imx/mach-pcm043.c
+++ b/arch/arm/mach-imx/mach-pcm043.c
@@ -27,6 +27,7 @@
 #include <linux/i2c/at24.h>
 #include <linux/usb/otg.h>
 #include <linux/usb/ulpi.h>
+#include <linux/export.h>
 
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
@@ -217,7 +218,7 @@ static iomux_v3_cfg_t pcm043_pads[] = {
 #define SD1_GPIO_WP	IMX_GPIO_NR(2, 23)
 #define SD1_GPIO_CD	IMX_GPIO_NR(2, 24)
 
-static void pcm043_ac97_warm_reset(struct snd_ac97 *ac97)
+void pcm043_ac97_warm_reset(struct snd_ac97 *ac97)
 {
 	iomux_v3_cfg_t txfs_gpio = MX35_PAD_STXFS4__GPIO2_31;
 	iomux_v3_cfg_t txfs = MX35_PAD_STXFS4__AUDMUX_AUD4_TXFS;
@@ -239,8 +240,9 @@ static void pcm043_ac97_warm_reset(struct snd_ac97 *ac97)
 	gpio_free(AC97_GPIO_TXFS);
 	mxc_iomux_v3_setup_pad(txfs);
 }
+EXPORT_SYMBOL(pcm043_ac97_warm_reset);
 
-static void pcm043_ac97_cold_reset(struct snd_ac97 *ac97)
+void pcm043_ac97_cold_reset(struct snd_ac97 *ac97)
 {
 	iomux_v3_cfg_t txfs_gpio = MX35_PAD_STXFS4__GPIO2_31;
 	iomux_v3_cfg_t txfs = MX35_PAD_STXFS4__AUDMUX_AUD4_TXFS;
@@ -286,6 +288,7 @@ err1:
 		printk("%s failed with %d\n", __func__, ret);
 	mdelay(1);
 }
+EXPORT_SYMBOL(pcm043_ac97_cold_reset);
 
 static const struct imx_ssi_platform_data pcm043_ssi_pdata __initconst = {
 	.ac97_reset = pcm043_ac97_cold_reset,
-- 
1.8.1.5



From mpa at pengutronix.de  Sun Apr 14 07:42:58 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Sun, 14 Apr 2013 13:42:58 +0200
Subject: [PATCH v3 14/15] ASoC: fsl: Move fsl-ssi binding doc to sound/
In-Reply-To: <1365939779-4507-1-git-send-email-mpa@pengutronix.de>
References: <1365939779-4507-1-git-send-email-mpa@pengutronix.de>
Message-ID: <1365939779-4507-15-git-send-email-mpa@pengutronix.de>

fsl-ssi was located in powerpc/fsl/ssi.txt. This is no powerpc specific
device, so it should be moved to sound/ as it connects to differen audio
codecs.

Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
---
 .../devicetree/bindings/powerpc/fsl/ssi.txt        | 73 ----------------------
 .../devicetree/bindings/sound/fsl,ssi.txt          | 73 ++++++++++++++++++++++
 2 files changed, 73 insertions(+), 73 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/powerpc/fsl/ssi.txt
 create mode 100644 Documentation/devicetree/bindings/sound/fsl,ssi.txt

diff --git a/Documentation/devicetree/bindings/powerpc/fsl/ssi.txt b/Documentation/devicetree/bindings/powerpc/fsl/ssi.txt
deleted file mode 100644
index 5ff76c9..0000000
--- a/Documentation/devicetree/bindings/powerpc/fsl/ssi.txt
+++ /dev/null
@@ -1,73 +0,0 @@
-Freescale Synchronous Serial Interface
-
-The SSI is a serial device that communicates with audio codecs.  It can
-be programmed in AC97, I2S, left-justified, or right-justified modes.
-
-Required properties:
-- compatible:       Compatible list, contains "fsl,ssi".
-- cell-index:       The SSI, <0> = SSI1, <1> = SSI2, and so on.
-- reg:              Offset and length of the register set for the device.
-- 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.  This should be
-                    encoded based on the information in section 2)
-                    depending on the type of interrupt controller you
-                    have.
-- interrupt-parent: The phandle for the interrupt controller that
-                    services interrupts for this device.
-- fsl,mode:         The operating mode for the SSI interface.
-                    "i2s-slave" - I2S mode, SSI is clock slave
-                    "i2s-master" - I2S mode, SSI is clock master
-                    "lj-slave" - left-justified mode, SSI is clock slave
-                    "lj-master" - l.j. mode, SSI is clock master
-                    "rj-slave" - right-justified mode, SSI is clock slave
-                    "rj-master" - r.j., SSI is clock master
-                    "ac97-slave" - AC97 mode, SSI is clock slave
-                    "ac97-master" - AC97 mode, SSI is clock master
-- fsl,playback-dma: Phandle to a node for the DMA channel to use for
-                    playback of audio.  This is typically dictated by SOC
-                    design.  See the notes below.
-- fsl,capture-dma:  Phandle to a node for the DMA channel to use for
-                    capture (recording) of audio.  This is typically dictated
-                    by SOC design.  See the notes below.
-- fsl,fifo-depth:   The number of elements in the transmit and receive FIFOs.
-                    This number is the maximum allowed value for SFCSR[TFWM0].
-- fsl,ssi-asynchronous:
-                    If specified, the SSI is to be programmed in asynchronous
-                    mode.  In this mode, pins SRCK, STCK, SRFS, and STFS must
-                    all be connected to valid signals.  In synchronous mode,
-                    SRCK and SRFS are ignored.  Asynchronous mode allows
-                    playback and capture to use different sample sizes and
-                    sample rates.  Some drivers may require that SRCK and STCK
-                    be connected together, and SRFS and STFS be connected
-                    together.  This would still allow different sample sizes,
-                    but not different sample rates.
-
-Optional properties:
-- codec-handle:     Phandle to a 'codec' node that defines an audio
-                    codec connected to this SSI.  This node is typically
-                    a child of an I2C or other control node.
-
-Child 'codec' node required properties:
-- compatible:       Compatible list, contains the name of the codec
-
-Child 'codec' node optional properties:
-- clock-frequency:  The frequency of the input clock, which typically comes
-                    from an on-board dedicated oscillator.
-
-Notes on fsl,playback-dma and fsl,capture-dma:
-
-On SOCs that have an SSI, specific DMA channels are hard-wired for playback
-and capture.  On the MPC8610, for example, SSI1 must use DMA channel 0 for
-playback and DMA channel 1 for capture.  SSI2 must use DMA channel 2 for
-playback and DMA channel 3 for capture.  The developer can choose which
-DMA controller to use, but the channels themselves are hard-wired.  The
-purpose of these two properties is to represent this hardware design.
-
-The device tree nodes for the DMA channels that are referenced by
-"fsl,playback-dma" and "fsl,capture-dma" must be marked as compatible with
-"fsl,ssi-dma-channel".  The SOC-specific compatible string (e.g.
-"fsl,mpc8610-dma-channel") can remain.  If these nodes are left as
-"fsl,elo-dma-channel" or "fsl,eloplus-dma-channel", then the generic Elo DMA
-drivers (fsldma) will attempt to use them, and it will conflict with the
-sound drivers.
diff --git a/Documentation/devicetree/bindings/sound/fsl,ssi.txt b/Documentation/devicetree/bindings/sound/fsl,ssi.txt
new file mode 100644
index 0000000..5ff76c9
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/fsl,ssi.txt
@@ -0,0 +1,73 @@
+Freescale Synchronous Serial Interface
+
+The SSI is a serial device that communicates with audio codecs.  It can
+be programmed in AC97, I2S, left-justified, or right-justified modes.
+
+Required properties:
+- compatible:       Compatible list, contains "fsl,ssi".
+- cell-index:       The SSI, <0> = SSI1, <1> = SSI2, and so on.
+- reg:              Offset and length of the register set for the device.
+- 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.  This should be
+                    encoded based on the information in section 2)
+                    depending on the type of interrupt controller you
+                    have.
+- interrupt-parent: The phandle for the interrupt controller that
+                    services interrupts for this device.
+- fsl,mode:         The operating mode for the SSI interface.
+                    "i2s-slave" - I2S mode, SSI is clock slave
+                    "i2s-master" - I2S mode, SSI is clock master
+                    "lj-slave" - left-justified mode, SSI is clock slave
+                    "lj-master" - l.j. mode, SSI is clock master
+                    "rj-slave" - right-justified mode, SSI is clock slave
+                    "rj-master" - r.j., SSI is clock master
+                    "ac97-slave" - AC97 mode, SSI is clock slave
+                    "ac97-master" - AC97 mode, SSI is clock master
+- fsl,playback-dma: Phandle to a node for the DMA channel to use for
+                    playback of audio.  This is typically dictated by SOC
+                    design.  See the notes below.
+- fsl,capture-dma:  Phandle to a node for the DMA channel to use for
+                    capture (recording) of audio.  This is typically dictated
+                    by SOC design.  See the notes below.
+- fsl,fifo-depth:   The number of elements in the transmit and receive FIFOs.
+                    This number is the maximum allowed value for SFCSR[TFWM0].
+- fsl,ssi-asynchronous:
+                    If specified, the SSI is to be programmed in asynchronous
+                    mode.  In this mode, pins SRCK, STCK, SRFS, and STFS must
+                    all be connected to valid signals.  In synchronous mode,
+                    SRCK and SRFS are ignored.  Asynchronous mode allows
+                    playback and capture to use different sample sizes and
+                    sample rates.  Some drivers may require that SRCK and STCK
+                    be connected together, and SRFS and STFS be connected
+                    together.  This would still allow different sample sizes,
+                    but not different sample rates.
+
+Optional properties:
+- codec-handle:     Phandle to a 'codec' node that defines an audio
+                    codec connected to this SSI.  This node is typically
+                    a child of an I2C or other control node.
+
+Child 'codec' node required properties:
+- compatible:       Compatible list, contains the name of the codec
+
+Child 'codec' node optional properties:
+- clock-frequency:  The frequency of the input clock, which typically comes
+                    from an on-board dedicated oscillator.
+
+Notes on fsl,playback-dma and fsl,capture-dma:
+
+On SOCs that have an SSI, specific DMA channels are hard-wired for playback
+and capture.  On the MPC8610, for example, SSI1 must use DMA channel 0 for
+playback and DMA channel 1 for capture.  SSI2 must use DMA channel 2 for
+playback and DMA channel 3 for capture.  The developer can choose which
+DMA controller to use, but the channels themselves are hard-wired.  The
+purpose of these two properties is to represent this hardware design.
+
+The device tree nodes for the DMA channels that are referenced by
+"fsl,playback-dma" and "fsl,capture-dma" must be marked as compatible with
+"fsl,ssi-dma-channel".  The SOC-specific compatible string (e.g.
+"fsl,mpc8610-dma-channel") can remain.  If these nodes are left as
+"fsl,elo-dma-channel" or "fsl,eloplus-dma-channel", then the generic Elo DMA
+drivers (fsldma) will attempt to use them, and it will conflict with the
+sound drivers.
-- 
1.8.1.5



From mpa at pengutronix.de  Sun Apr 14 07:42:52 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Sun, 14 Apr 2013 13:42:52 +0200
Subject: [PATCH v3 08/15] ASoC: fsl-ssi: Add SACNT definitions
In-Reply-To: <1365939779-4507-1-git-send-email-mpa@pengutronix.de>
References: <1365939779-4507-1-git-send-email-mpa@pengutronix.de>
Message-ID: <1365939779-4507-9-git-send-email-mpa@pengutronix.de>

Add definitions for AC97 control register.

Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
Acked-by: Timur Tabi <timur at tabi.org>
---
 sound/soc/fsl/fsl_ssi.h | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/sound/soc/fsl/fsl_ssi.h b/sound/soc/fsl/fsl_ssi.h
index 2173000..e6b9a69 100644
--- a/sound/soc/fsl/fsl_ssi.h
+++ b/sound/soc/fsl/fsl_ssi.h
@@ -196,5 +196,13 @@ struct ccsr_ssi {
 #define CCSR_SSI_SOR_WAIT(x) (((x) & 3) << CCSR_SSI_SOR_WAIT_SHIFT)
 #define CCSR_SSI_SOR_SYNRST 		0x00000001
 
+#define CCSR_SSI_SACNT_FRDIV(x)		(((x) & 0x3f) << 5)
+#define CCSR_SSI_SACNT_WR		0x00000010
+#define CCSR_SSI_SACNT_RD		0x00000008
+#define CCSR_SSI_SACNT_RDWR_MASK	0x00000018
+#define CCSR_SSI_SACNT_TIF		0x00000004
+#define CCSR_SSI_SACNT_FV		0x00000002
+#define CCSR_SSI_SACNT_AC97EN		0x00000001
+
 #endif
 
-- 
1.8.1.5



From mpa at pengutronix.de  Sun Apr 14 07:42:48 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Sun, 14 Apr 2013 13:42:48 +0200
Subject: [PATCH v3 04/15] ASoC: dmaengine-pcm: Fix pcm_request_chan function
 name
In-Reply-To: <1365939779-4507-1-git-send-email-mpa@pengutronix.de>
References: <1365939779-4507-1-git-send-email-mpa@pengutronix.de>
Message-ID: <1365939779-4507-5-git-send-email-mpa@pengutronix.de>

From: Markus Pargmann <mpa at pengutrnoix.de>

dmaengine_pcm.c implements snd_dmaengine_pcm_request_channel. This
function fixes all function calls to the shorter
snd_dmaengine_pcm_request_chan.

Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
---
 include/sound/dmaengine_pcm.h         | 2 +-
 sound/soc/soc-generic-dmaengine-pcm.c | 2 +-
 sound/soc/spear/spear_pcm.c           | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/sound/dmaengine_pcm.h b/include/sound/dmaengine_pcm.h
index b346098..b7dbec0 100644
--- a/include/sound/dmaengine_pcm.h
+++ b/include/sound/dmaengine_pcm.h
@@ -47,7 +47,7 @@ int snd_dmaengine_pcm_open_request_chan(struct snd_pcm_substream *substream,
 	dma_filter_fn filter_fn, void *filter_data);
 int snd_dmaengine_pcm_close_release_chan(struct snd_pcm_substream *substream);
 
-struct dma_chan *snd_dmaengine_pcm_request_chan(dma_filter_fn filter_fn,
+struct dma_chan *snd_dmaengine_pcm_request_channel(dma_filter_fn filter_fn,
 	void *filter_data);
 struct dma_chan *snd_dmaengine_pcm_get_chan(struct snd_pcm_substream *substream);
 
diff --git a/sound/soc/soc-generic-dmaengine-pcm.c b/sound/soc/soc-generic-dmaengine-pcm.c
index f752577..9480087 100644
--- a/sound/soc/soc-generic-dmaengine-pcm.c
+++ b/sound/soc/soc-generic-dmaengine-pcm.c
@@ -117,7 +117,7 @@ static struct dma_chan *dmaengine_pcm_compat_request_channel(
 	if (pcm->config->compat_request_channel)
 	    return pcm->config->compat_request_channel(rtd, substream);
 
-	return snd_dmaengine_pcm_request_chan(pcm->config->compat_filter_fn,
+	return snd_dmaengine_pcm_request_channel(pcm->config->compat_filter_fn,
 		snd_soc_dai_get_dma_data(rtd->cpu_dai, substream));
 }
 
diff --git a/sound/soc/spear/spear_pcm.c b/sound/soc/spear/spear_pcm.c
index a8222ae..10fc7c9 100644
--- a/sound/soc/spear/spear_pcm.c
+++ b/sound/soc/spear/spear_pcm.c
@@ -38,7 +38,7 @@ static struct dma_chan *spear_pcm_request_chan(struct snd_soc_pcm_runtime *rtd,
 
 	dma_data = snd_soc_dai_get_dma_data(rtd->cpu_dai, substream);
 
-	return snd_dmaengine_pcm_request_chan(dma_data->filter, dma_data);
+	return snd_dmaengine_pcm_request_channel(dma_data->filter, dma_data);
 }
 
 static const struct snd_dmaengine_pcm_config spear_dmaengine_pcm_config = {
-- 
1.8.1.5



From mpa at pengutronix.de  Sun Apr 14 07:42:49 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Sun, 14 Apr 2013 13:42:49 +0200
Subject: [PATCH v3 05/15] ASoC: phycore-ac97: Add DT support
In-Reply-To: <1365939779-4507-1-git-send-email-mpa@pengutronix.de>
References: <1365939779-4507-1-git-send-email-mpa@pengutronix.de>
Message-ID: <1365939779-4507-6-git-send-email-mpa@pengutronix.de>

Add devicetree support for this audio soc fabric driver.

DT initialized drivers do not have real device ids, so
imx-pcm-fiq-audio.0 is used without '.0'.

This patch also simplifies the way audmux ports are configured. Before
there was knowledge about the used board. As the audmux driver knows the
used board, we know use the returned errorcodes to correctly set the
audmux port. So this driver does not have to know which board it is
running on.

Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
---

Notes:
    Changes in v3:
     - Add some more information in the commit message.
    
    Changes in v2:
     - Simplify the driver, by combining audmux port configurations. The
       audmux driver actually knows on which platform he is running and
       will return the appropriate error code if we use functions for
       another platform. So we don't need to have the knowledge about it
       in phycore-ac97 and can try both functions. This removes the need
       of different compatibilities and renames it to phycore-ac97.
     - Use a phandle for the cpu_dai link.
     - Add devicetree binding documentation.
     - Rename binding to phytec,phycore-ac97 and fsl,ssi to phytec,ssi
    
    Changes in v2:
     - Simplify the driver, by combining audmux port configurations. The
       audmux driver actually knows on which platform he is running and
       will return the appropriate error code if we use functions for
       another platform. So we don't need to have the knowledge about it
       in phycore-ac97 and can try both functions. This removes the need
       of different compatibilities and renames it to imx27-ac97.
     - Use a phandle for the cpu_dai link.
     - Add devicetree binding documentation.
     - Rename binding to phytec,phycore-ac97 and fsl,ssi to phytec,ssi

 .../bindings/sound/phytec,phycore-ac97.txt         |  12 ++
 sound/soc/fsl/phycore-ac97.c                       | 184 ++++++++++++++++++---
 2 files changed, 174 insertions(+), 22 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/sound/phytec,phycore-ac97.txt

diff --git a/Documentation/devicetree/bindings/sound/phytec,phycore-ac97.txt b/Documentation/devicetree/bindings/sound/phytec,phycore-ac97.txt
new file mode 100644
index 0000000..e04221d
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/phytec,phycore-ac97.txt
@@ -0,0 +1,12 @@
+Phytec phycore AC97
+
+Required properties:
+- compatible: "phytec,phycore-ac97"
+- phytec,ssi: A phandle to the ssi device that is connected to ac97.
+
+Example:
+
+sound {
+	compatible = "phytec,phycore-ac97";
+	phytec,ssi = <&ssi1>;
+};
diff --git a/sound/soc/fsl/phycore-ac97.c b/sound/soc/fsl/phycore-ac97.c
index f8da6dd..cebd93f 100644
--- a/sound/soc/fsl/phycore-ac97.c
+++ b/sound/soc/fsl/phycore-ac97.c
@@ -21,7 +21,10 @@
 
 #include "imx-audmux.h"
 
+#define DRV_NAME "phycore-audio-fabric"
+
 static struct snd_soc_card imx_phycore;
+static struct device_node *phycore_dai_cpu_node;
 
 static struct snd_soc_ops imx_phycore_hifi_ops = {
 };
@@ -32,8 +35,12 @@ static struct snd_soc_dai_link imx_phycore_dai_ac97[] = {
 		.stream_name	= "HiFi",
 		.codec_dai_name		= "wm9712-hifi",
 		.codec_name	= "wm9712-codec",
+#ifdef CONFIG_MACH_IMX27_DT
+		.platform_name	= "imx-fiq-pcm-audio",
+#else
 		.cpu_dai_name	= "imx-ssi.0",
 		.platform_name	= "imx-fiq-pcm-audio.0",
+#endif
 		.ops		= &imx_phycore_hifi_ops,
 	},
 };
@@ -45,35 +52,78 @@ static struct snd_soc_card imx_phycore = {
 	.num_links	= ARRAY_SIZE(imx_phycore_dai_ac97),
 };
 
-static struct platform_device *imx_phycore_snd_ac97_device;
+static int phycore_ac97_pca100_audmux(void)
+{
+	int ret;
+
+	ret = imx_audmux_v1_configure_port(MX27_AUDMUX_HPCR1_SSI0,
+		IMX_AUDMUX_V1_PCR_SYN | /* 4wire mode */
+		IMX_AUDMUX_V1_PCR_TFCSEL(3) |
+		IMX_AUDMUX_V1_PCR_TCLKDIR | /* clock is output */
+		IMX_AUDMUX_V1_PCR_RXDSEL(3));
+	if (ret)
+		return ret;
+
+	ret = imx_audmux_v1_configure_port(3,
+		IMX_AUDMUX_V1_PCR_SYN | /* 4wire mode */
+		IMX_AUDMUX_V1_PCR_TFCSEL(0) |
+		IMX_AUDMUX_V1_PCR_TFSDIR |
+		IMX_AUDMUX_V1_PCR_RXDSEL(0));
+	return ret;
+}
+
+static int phycore_ac97_pcm043_audmux(void)
+{
+	int ret;
+
+	ret = imx_audmux_v2_configure_port(3,
+		IMX_AUDMUX_V2_PTCR_SYN | /* 4wire mode */
+		IMX_AUDMUX_V2_PTCR_TFSEL(0) |
+		IMX_AUDMUX_V2_PTCR_TFSDIR,
+		IMX_AUDMUX_V2_PDCR_RXDSEL(0));
+	if (ret)
+		return ret;
+
+	ret = imx_audmux_v2_configure_port(0,
+		IMX_AUDMUX_V2_PTCR_SYN | /* 4wire mode */
+		IMX_AUDMUX_V2_PTCR_TCSEL(3) |
+		IMX_AUDMUX_V2_PTCR_TCLKDIR, /* clock is output */
+		IMX_AUDMUX_V2_PDCR_RXDSEL(3));
+	return ret;
+}
+
+static __maybe_unused int phycore_ac97_init_audmux(void)
+{
+	int ret;
+
+	/*
+	 * This driver doesn't need to know which actual hardware is used.
+	 * The audmux driver has knowledge about it's type, and returns
+	 * an error if executed on the wrong type of hardware.
+	 */
+	ret = phycore_ac97_pca100_audmux();
+	if (!ret)
+		return 0;
+
+	ret = phycore_ac97_pcm043_audmux();
+
+	return ret;
+}
+
 static struct platform_device *imx_phycore_snd_device;
 
+#ifndef CONFIG_MACH_IMX27_DT
+
+static struct platform_device *imx_phycore_snd_ac97_device;
+
 static int __init imx_phycore_init(void)
 {
 	int ret;
 
 	if (machine_is_pca100()) {
-		imx_audmux_v1_configure_port(MX27_AUDMUX_HPCR1_SSI0,
-			IMX_AUDMUX_V1_PCR_SYN | /* 4wire mode */
-			IMX_AUDMUX_V1_PCR_TFCSEL(3) |
-			IMX_AUDMUX_V1_PCR_TCLKDIR | /* clock is output */
-			IMX_AUDMUX_V1_PCR_RXDSEL(3));
-		imx_audmux_v1_configure_port(3,
-			IMX_AUDMUX_V1_PCR_SYN | /* 4wire mode */
-			IMX_AUDMUX_V1_PCR_TFCSEL(0) |
-			IMX_AUDMUX_V1_PCR_TFSDIR |
-			IMX_AUDMUX_V1_PCR_RXDSEL(0));
+		phycore_ac97_pca100_audmux();
 	} else if (machine_is_pcm043()) {
-		imx_audmux_v2_configure_port(3,
-			IMX_AUDMUX_V2_PTCR_SYN | /* 4wire mode */
-			IMX_AUDMUX_V2_PTCR_TFSEL(0) |
-			IMX_AUDMUX_V2_PTCR_TFSDIR,
-			IMX_AUDMUX_V2_PDCR_RXDSEL(0));
-		imx_audmux_v2_configure_port(0,
-			IMX_AUDMUX_V2_PTCR_SYN | /* 4wire mode */
-			IMX_AUDMUX_V2_PTCR_TCSEL(3) |
-			IMX_AUDMUX_V2_PTCR_TCLKDIR, /* clock is output */
-			IMX_AUDMUX_V2_PDCR_RXDSEL(3));
+		phycore_ac97_pcm043_audmux();
 	} else {
 		/* return happy. We might run on a totally different machine */
 		return 0;
@@ -120,6 +170,96 @@ static void __exit imx_phycore_exit(void)
 late_initcall(imx_phycore_init);
 module_exit(imx_phycore_exit);
 
+#else  /* !CONFIG_MACH_IMX27_DT */
+
+static const struct of_device_id imx_phycore_ac97_of_dev_id[] = {
+	{
+		.compatible = "phytec,phycore-ac97",
+	}, {
+		/* sentinel */
+	}
+};
+MODULE_DEVICE_TABLE(of, imx_phycore_ac97_of_dev_id);
+
+static int phycore_ac97_setup_devices(struct platform_device *pdev)
+{
+	int ret;
+
+	imx_phycore_snd_device = platform_device_alloc("wm9712-codec", -1);
+	if (!imx_phycore_snd_device)
+		return -ENOMEM;
+
+	ret = platform_device_add(imx_phycore_snd_device);
+	if (ret) {
+		dev_err(&pdev->dev, "ASoC: Platform device allocation failed\n");
+		goto fail1;
+	}
+
+	ret = snd_soc_register_card(&imx_phycore);
+	if (ret) {
+		dev_err(&pdev->dev, "ASoC: soc card registration failed\n");
+		goto fail2;
+	}
+	return 0;
+
+fail2:
+	platform_device_del(imx_phycore_snd_device);
+fail1:
+	platform_device_put(imx_phycore_snd_device);
+	return ret;
+}
+
+static int imx_phycore_ac97_probe(struct platform_device *pdev)
+{
+	int ret;
+	struct device_node *ssi_np;
+
+	imx_phycore.dev = &pdev->dev;
+
+	ret = phycore_ac97_init_audmux();
+	if (ret) {
+		dev_err(&pdev->dev, "Failed to initialize audmux\n");
+		return ret;
+	}
+
+	ssi_np = of_parse_phandle(pdev->dev.of_node, "phytec,ssi", 0);
+	if (!ssi_np) {
+		dev_err(&pdev->dev, "No valid ssi phandle found\n");
+		return -EINVAL;
+	}
+
+	imx_phycore_dai_ac97[0].cpu_of_node = ssi_np;
+	phycore_dai_cpu_node = ssi_np;
+
+
+	ret = phycore_ac97_setup_devices(pdev);
+	if (ret)
+		of_node_put(phycore_dai_cpu_node);
+
+	return ret;
+}
+
+static int imx_phycore_ac97_remove(struct platform_device *pdev)
+{
+	of_node_put(phycore_dai_cpu_node);
+	platform_device_unregister(imx_phycore_snd_device);
+	return 0;
+}
+
+static struct platform_driver imx_phycore_ac97_driver = {
+	.probe		= imx_phycore_ac97_probe,
+	.remove		= imx_phycore_ac97_remove,
+	.driver		= {
+		.name	= DRV_NAME,
+		.owner	= THIS_MODULE,
+		.of_match_table = imx_phycore_ac97_of_dev_id,
+	},
+};
+
+module_platform_driver(imx_phycore_ac97_driver);
+
+#endif  /* CONFIG_MACH_IMX27_DT */
+
 MODULE_AUTHOR("Sascha Hauer <s.hauer at pengutronix.de>");
-MODULE_DESCRIPTION("PhyCORE ALSA SoC driver");
+MODULE_DESCRIPTION(DRV_NAME ": PhyCORE ALSA SoC fabric driver");
 MODULE_LICENSE("GPL");
-- 
1.8.1.5



From mpa at pengutronix.de  Sun Apr 14 07:42:51 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Sun, 14 Apr 2013 13:42:51 +0200
Subject: [PATCH v3 07/15] ASoC: imx-pcm-fiq: Introduce pcm-fiq-params
In-Reply-To: <1365939779-4507-1-git-send-email-mpa@pengutronix.de>
References: <1365939779-4507-1-git-send-email-mpa@pengutronix.de>
Message-ID: <1365939779-4507-8-git-send-email-mpa@pengutronix.de>

Cleaner parameter passing for imx-pcm-fiq. Create a seperated fiq-params
struct to pass all arguments.

Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
---

Notes:
    Changes in v3:
     - Using snd_dmaengine_dai_dma_data for dma_params after rebasing onto
       dmaengine cleanups.

 sound/soc/fsl/imx-pcm-fiq.c | 16 +++++++++-------
 sound/soc/fsl/imx-pcm.h     |  9 +++++++++
 sound/soc/fsl/imx-ssi.c     |  7 ++++++-
 sound/soc/fsl/imx-ssi.h     |  1 +
 4 files changed, 25 insertions(+), 8 deletions(-)

diff --git a/sound/soc/fsl/imx-pcm-fiq.c b/sound/soc/fsl/imx-pcm-fiq.c
index 670b96b..c3fdb2f 100644
--- a/sound/soc/fsl/imx-pcm-fiq.c
+++ b/sound/soc/fsl/imx-pcm-fiq.c
@@ -22,6 +22,7 @@
 #include <linux/slab.h>
 
 #include <sound/core.h>
+#include <sound/dmaengine_pcm.h>
 #include <sound/initval.h>
 #include <sound/pcm.h>
 #include <sound/pcm_params.h>
@@ -32,6 +33,7 @@
 #include <linux/platform_data/asoc-imx-ssi.h>
 
 #include "imx-ssi.h"
+#include "imx-pcm.h"
 
 struct imx_pcm_runtime_data {
 	unsigned int period;
@@ -283,7 +285,7 @@ static struct snd_soc_platform_driver imx_soc_platform_fiq = {
 
 int imx_pcm_fiq_init(struct platform_device *pdev)
 {
-	struct imx_ssi *ssi = platform_get_drvdata(pdev);
+	struct imx_pcm_fiq_params *params = platform_get_drvdata(pdev);
 	int ret;
 
 	ret = claim_fiq(&fh);
@@ -292,15 +294,15 @@ int imx_pcm_fiq_init(struct platform_device *pdev)
 		return ret;
 	}
 
-	mxc_set_irq_fiq(ssi->irq, 1);
-	ssi_irq = ssi->irq;
+	mxc_set_irq_fiq(params->irq, 1);
+	ssi_irq = params->irq;
 
-	imx_pcm_fiq = ssi->irq;
+	imx_pcm_fiq = params->irq;
 
-	imx_ssi_fiq_base = (unsigned long)ssi->base;
+	imx_ssi_fiq_base = (unsigned long)params->base;
 
-	ssi->dma_params_tx.maxburst = 4;
-	ssi->dma_params_rx.maxburst = 6;
+	params->dma_params_tx->maxburst = 4;
+	params->dma_params_rx->maxburst = 6;
 
 	ret = snd_soc_register_platform(&pdev->dev, &imx_soc_platform_fiq);
 	if (ret)
diff --git a/sound/soc/fsl/imx-pcm.h b/sound/soc/fsl/imx-pcm.h
index 3661b13..cde849b 100644
--- a/sound/soc/fsl/imx-pcm.h
+++ b/sound/soc/fsl/imx-pcm.h
@@ -32,6 +32,15 @@ imx_pcm_dma_params_init_data(struct imx_dma_data *dma_data,
 		dma_data->peripheral_type = IMX_DMATYPE_SSI;
 }
 
+struct imx_pcm_fiq_params {
+	int irq;
+	void __iomem *base;
+
+	/* Pointer to original ssi driver to setup tx rx sizes */
+	struct snd_dmaengine_dai_dma_data *dma_params_rx;
+	struct snd_dmaengine_dai_dma_data *dma_params_tx;
+};
+
 int snd_imx_pcm_mmap(struct snd_pcm_substream *substream,
 		     struct vm_area_struct *vma);
 int imx_pcm_new(struct snd_soc_pcm_runtime *rtd);
diff --git a/sound/soc/fsl/imx-ssi.c b/sound/soc/fsl/imx-ssi.c
index 902fab0..f80f4c7 100644
--- a/sound/soc/fsl/imx-ssi.c
+++ b/sound/soc/fsl/imx-ssi.c
@@ -601,7 +601,12 @@ static int imx_ssi_probe(struct platform_device *pdev)
 		goto failed_pdev_fiq_alloc;
 	}
 
-	platform_set_drvdata(ssi->soc_platform_pdev_fiq, ssi);
+	ssi->fiq_params.irq = ssi->irq;
+	ssi->fiq_params.base = ssi->base;
+	ssi->fiq_params.dma_params_rx = &ssi->dma_params_rx;
+	ssi->fiq_params.dma_params_tx = &ssi->dma_params_tx;
+
+	platform_set_drvdata(ssi->soc_platform_pdev_fiq, &ssi->fiq_params);
 	ret = platform_device_add(ssi->soc_platform_pdev_fiq);
 	if (ret) {
 		dev_err(&pdev->dev, "failed to add platform device\n");
diff --git a/sound/soc/fsl/imx-ssi.h b/sound/soc/fsl/imx-ssi.h
index bb6b3db..20ce7ca 100644
--- a/sound/soc/fsl/imx-ssi.h
+++ b/sound/soc/fsl/imx-ssi.h
@@ -209,6 +209,7 @@ struct imx_ssi {
 	struct snd_dmaengine_dai_dma_data dma_params_tx;
 	struct imx_dma_data filter_data_tx;
 	struct imx_dma_data filter_data_rx;
+	struct imx_pcm_fiq_params fiq_params;
 
 	int enabled;
 
-- 
1.8.1.5



From mpa at pengutronix.de  Sun Apr 14 07:42:53 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Sun, 14 Apr 2013 13:42:53 +0200
Subject: [PATCH v3 09/15] ASoC: fsl-ssi: Add support for imx-pcm-fiq
In-Reply-To: <1365939779-4507-1-git-send-email-mpa@pengutronix.de>
References: <1365939779-4507-1-git-send-email-mpa@pengutronix.de>
Message-ID: <1365939779-4507-10-git-send-email-mpa@pengutronix.de>

Add support for non-dma pcm for imx platforms with imx-pcm-fiq support.
Instead of imx-pcm-audio, in this case imx-pcm-fiq-audio device is added
and the SIER flags are set differently.

Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
---

Notes:
    Changes in v3:
     - Rename bool "dma" to "use_dma"

 sound/soc/fsl/fsl_ssi.c | 66 ++++++++++++++++++++++++++++++++++++++-----------
 1 file changed, 52 insertions(+), 14 deletions(-)

diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index 0f0bed6..6a9be9c 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -121,12 +121,14 @@ struct fsl_ssi_private {
 
 	bool new_binding;
 	bool ssi_on_imx;
+	bool use_dma;
 	struct clk *clk;
 	struct platform_device *imx_pcm_pdev;
 	struct snd_dmaengine_dai_dma_data dma_params_tx;
 	struct snd_dmaengine_dai_dma_data dma_params_rx;
 	struct imx_dma_data filter_data_tx;
 	struct imx_dma_data filter_data_rx;
+	struct imx_pcm_fiq_params fiq_params;
 
 	struct {
 		unsigned int rfrc;
@@ -356,7 +358,12 @@ static int fsl_ssi_startup(struct snd_pcm_substream *substream,
 		 */
 
 		/* Enable the interrupts and DMA requests */
-		write_ssi(SIER_FLAGS, &ssi->sier);
+		if (ssi_private->use_dma)
+			write_ssi(SIER_FLAGS, &ssi->sier);
+		else
+			write_ssi(CCSR_SSI_SIER_TIE | CCSR_SSI_SIER_TFE0_EN |
+					CCSR_SSI_SIER_RIE |
+					CCSR_SSI_SIER_RFF0_EN, &ssi->sier);
 
 		/*
 		 * Set the watermark for transmit FIFI 0 and receive FIFO 0. We
@@ -550,7 +557,7 @@ static int fsl_ssi_dai_probe(struct snd_soc_dai *dai)
 {
 	struct fsl_ssi_private *ssi_private = snd_soc_dai_get_drvdata(dai);
 
-	if (ssi_private->ssi_on_imx) {
+	if (ssi_private->ssi_on_imx && ssi_private->use_dma) {
 		dai->playback_dma_data = &ssi_private->dma_params_tx;
 		dai->capture_dma_data = &ssi_private->dma_params_rx;
 	}
@@ -695,6 +702,8 @@ static int fsl_ssi_probe(struct platform_device *pdev)
 	       sizeof(fsl_ssi_dai_template));
 	ssi_private->cpu_dai_drv.name = ssi_private->name;
 
+	ssi_private->use_dma = !of_property_read_bool(np, "fsl,imx-fiq");
+
 	/* Get the addresses and IRQ */
 	ret = of_address_to_resource(np, 0, &res);
 	if (ret) {
@@ -716,12 +725,15 @@ static int fsl_ssi_probe(struct platform_device *pdev)
 		goto error_iomap;
 	}
 
-	/* The 'name' should not have any slashes in it. */
-	ret = request_irq(ssi_private->irq, fsl_ssi_isr, 0, ssi_private->name,
-			  ssi_private);
-	if (ret < 0) {
-		dev_err(&pdev->dev, "could not claim irq %u\n", ssi_private->irq);
-		goto error_irqmap;
+	if (ssi_private->use_dma) {
+		/* The 'name' should not have any slashes in it. */
+		ret = request_irq(ssi_private->irq, fsl_ssi_isr, 0,
+				ssi_private->name, ssi_private);
+		if (ret < 0) {
+			dev_err(&pdev->dev, "could not claim irq %u\n",
+					ssi_private->irq);
+			goto error_irqmap;
+		}
 	}
 
 	/* Are the RX and the TX clocks locked? */
@@ -770,7 +782,7 @@ static int fsl_ssi_probe(struct platform_device *pdev)
 		 */
 		ret = of_property_read_u32_array(pdev->dev.of_node,
 					"fsl,ssi-dma-events", dma_events, 2);
-		if (ret) {
+		if (ret && !ssi_private->use_dma) {
 			dev_err(&pdev->dev, "could not get dma events\n");
 			goto error_clk;
 		}
@@ -809,12 +821,38 @@ static int fsl_ssi_probe(struct platform_device *pdev)
 	}
 
 	if (ssi_private->ssi_on_imx) {
-		ssi_private->imx_pcm_pdev =
-			platform_device_register_simple("imx-pcm-audio",
+		if (!ssi_private->use_dma) {
+			ssi_private->imx_pcm_pdev = platform_device_alloc(
+							"imx-fiq-pcm-audio",
+							pdev->id);
+			if (!ssi_private->imx_pcm_pdev) {
+				ret = -ENOMEM;
+				goto error_dev;
+			}
+
+			ssi_private->fiq_params.irq = ssi_private->irq;
+			ssi_private->fiq_params.base = ssi_private->ssi;
+			ssi_private->fiq_params.dma_params_rx =
+				&ssi_private->dma_params_rx;
+			ssi_private->fiq_params.dma_params_tx =
+				&ssi_private->dma_params_tx;
+
+			platform_set_drvdata(ssi_private->imx_pcm_pdev,
+					&ssi_private->fiq_params);
+			ret = platform_device_add(ssi_private->imx_pcm_pdev);
+			if (ret) {
+				dev_err(&pdev->dev, "Failed to add imx-fiq-pcm-audio device\n");
+				platform_device_put(ssi_private->imx_pcm_pdev);
+				goto error_dev;
+			}
+		} else {
+			ssi_private->imx_pcm_pdev =
+				platform_device_register_simple("imx-pcm-audio",
 							-1, NULL, 0);
-		if (IS_ERR(ssi_private->imx_pcm_pdev)) {
-			ret = PTR_ERR(ssi_private->imx_pcm_pdev);
-			goto error_dev;
+			if (IS_ERR(ssi_private->imx_pcm_pdev)) {
+				ret = PTR_ERR(ssi_private->imx_pcm_pdev);
+				goto error_dev;
+			}
 		}
 	}
 
-- 
1.8.1.5



From mpa at pengutronix.de  Sun Apr 14 07:42:57 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Sun, 14 Apr 2013 13:42:57 +0200
Subject: [PATCH v3 13/15] ASoC: fsl: Kconfig: Use fsl-ssi for phycore-ac97
In-Reply-To: <1365939779-4507-1-git-send-email-mpa@pengutronix.de>
References: <1365939779-4507-1-git-send-email-mpa@pengutronix.de>
Message-ID: <1365939779-4507-14-git-send-email-mpa@pengutronix.de>

Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
---
 sound/soc/fsl/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig
index 3843a18..28af843 100644
--- a/sound/soc/fsl/Kconfig
+++ b/sound/soc/fsl/Kconfig
@@ -153,7 +153,7 @@ config SND_SOC_PHYCORE_AC97
 	select SND_SOC_WM9712
 	select SND_SOC_IMX_PCM_FIQ
 	select SND_SOC_IMX_AUDMUX
-	select SND_SOC_IMX_SSI
+	select SND_SOC_FSL_SSI
 	help
 	  Say Y if you want to add support for SoC audio on Phytec phyCORE
 	  and phyCARD boards in AC97 mode
-- 
1.8.1.5



From mpa at pengutronix.de  Sun Apr 14 07:42:56 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Sun, 14 Apr 2013 13:42:56 +0200
Subject: [PATCH v3 12/15] ASoC: fsl-ssi: imx ac97 support
In-Reply-To: <1365939779-4507-1-git-send-email-mpa@pengutronix.de>
References: <1365939779-4507-1-git-send-email-mpa@pengutronix.de>
Message-ID: <1365939779-4507-13-git-send-email-mpa@pengutronix.de>

This patch copies some parts from imx-ssi to support AC97 on
imx27-pca100 and imx27-pcm043. This is a implementation of the
ac97-slave mode.

For ac97, the registers have to be setup earlier than for other ssi
modes because there is some communication with the external device
before actual streaming. So this patch introduces a fsl_ssi_setup
function to setup the registers at different times.

This patch was tested with imx27-pca100.

Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
---

Notes:
    Changes in v3:
     - Cleanup ac97 code by adding a fsl_ssi_setup function for initial register
       setup. For ac97 the registers have to be setup earlier than in normal
       mode.

 sound/soc/fsl/fsl_ssi.c | 412 +++++++++++++++++++++++++++++++++++++++---------
 1 file changed, 340 insertions(+), 72 deletions(-)

diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index 1ab66f8..0ffb898 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -121,6 +121,7 @@ struct fsl_ssi_private {
 
 	bool new_binding;
 	bool ssi_on_imx;
+	bool imx_ac97;
 	bool use_dma;
 	struct clk *clk;
 	struct platform_device *imx_pcm_pdev;
@@ -130,6 +131,9 @@ struct fsl_ssi_private {
 	struct imx_dma_data filter_data_rx;
 	struct imx_pcm_fiq_params fiq_params;
 
+	void (*ac97_reset) (struct snd_ac97 *ac97);
+	void (*ac97_warm_reset)(struct snd_ac97 *ac97);
+
 	struct {
 		unsigned int rfrc;
 		unsigned int tfrc;
@@ -301,6 +305,124 @@ static irqreturn_t fsl_ssi_isr(int irq, void *dev_id)
 	return ret;
 }
 
+static int fsl_ssi_setup(struct fsl_ssi_private *ssi_private)
+{
+	struct ccsr_ssi __iomem *ssi = ssi_private->ssi;
+	u8 i2s_mode;
+	u8 wm;
+	int synchronous = ssi_private->cpu_dai_drv.symmetric_rates;
+
+	if (ssi_private->imx_ac97)
+		i2s_mode = CCSR_SSI_SCR_I2S_MODE_NORMAL | CCSR_SSI_SCR_NET;
+	else
+		i2s_mode = CCSR_SSI_SCR_I2S_MODE_SLAVE;
+
+	/*
+	 * Section 16.5 of the MPC8610 reference manual says that the SSI needs
+	 * to be disabled before updating the registers we set here.
+	 */
+	write_ssi_mask(&ssi->scr, CCSR_SSI_SCR_SSIEN, 0);
+
+	/*
+	 * Program the SSI into I2S Slave Non-Network Synchronous mode. Also
+	 * enable the transmit and receive FIFO.
+	 *
+	 * FIXME: Little-endian samples require a different shift dir
+	 */
+	write_ssi_mask(&ssi->scr,
+		CCSR_SSI_SCR_I2S_MODE_MASK | CCSR_SSI_SCR_SYN,
+		CCSR_SSI_SCR_TFR_CLK_DIS |
+		i2s_mode |
+		(synchronous ? CCSR_SSI_SCR_SYN : 0));
+
+	write_ssi(CCSR_SSI_STCR_TXBIT0 | CCSR_SSI_STCR_TFEN0 |
+		 CCSR_SSI_STCR_TFSI | CCSR_SSI_STCR_TEFS |
+		 CCSR_SSI_STCR_TSCKP, &ssi->stcr);
+
+	write_ssi(CCSR_SSI_SRCR_RXBIT0 | CCSR_SSI_SRCR_RFEN0 |
+		 CCSR_SSI_SRCR_RFSI | CCSR_SSI_SRCR_REFS |
+		 CCSR_SSI_SRCR_RSCKP, &ssi->srcr);
+	/*
+	 * The DC and PM bits are only used if the SSI is the clock master.
+	 */
+
+	/*
+	 * Set the watermark for transmit FIFI 0 and receive FIFO 0. We don't
+	 * use FIFO 1. We program the transmit water to signal a DMA transfer
+	 * if there are only two (or fewer) elements left in the FIFO. Two
+	 * elements equals one frame (left channel, right channel). This value,
+	 * however, depends on the depth of the transmit buffer.
+	 *
+	 * We set the watermark on the same level as the DMA burstsize.  For
+	 * fiq it is probably better to use the biggest possible watermark
+	 * size.
+	 */
+	if (ssi_private->use_dma)
+		wm = ssi_private->fifo_depth - 2;
+	else
+		wm = ssi_private->fifo_depth;
+
+	write_ssi(CCSR_SSI_SFCSR_TFWM0(wm) | CCSR_SSI_SFCSR_RFWM0(wm) |
+		CCSR_SSI_SFCSR_TFWM1(wm) | CCSR_SSI_SFCSR_RFWM1(wm),
+		&ssi->sfcsr);
+
+	/*
+	 * For non-ac97 setups, we keep the SSI disabled because if we enable
+	 * it, then the DMA controller will start. It's not supposed to start
+	 * until the SCR.TE (or SCR.RE) bit is set, but it does anyway. The DMA
+	 * controller will transfer one "BWC" of data (i.e. the amount of data
+	 * that the MR.BWC bits are set to). The reason this is bad is because
+	 * at this point, the PCM driver has not finished initializing the DMA
+	 * controller.
+	 */
+
+
+	/*
+	 * For ac97 interrupts are enabled with the startup of the substream
+	 * because it is also running without an active substream. Normally SSI
+	 * is only enabled when there is a substream.
+	 */
+	if (!ssi_private->imx_ac97) {
+		/* Enable the interrupts and DMA requests */
+		if (ssi_private->use_dma)
+			write_ssi(SIER_FLAGS, &ssi->sier);
+		else
+			write_ssi(CCSR_SSI_SIER_TIE | CCSR_SSI_SIER_TFE0_EN |
+					CCSR_SSI_SIER_RIE |
+					CCSR_SSI_SIER_RFF0_EN, &ssi->sier);
+	} else {
+		/*
+		 * Setup the clock control register
+		 */
+		write_ssi(CCSR_SSI_SxCCR_WL(17) | CCSR_SSI_SxCCR_DC(13),
+				&ssi->stccr);
+		write_ssi(CCSR_SSI_SxCCR_WL(17) | CCSR_SSI_SxCCR_DC(13),
+				&ssi->srccr);
+
+		/*
+		 * Enable AC97 mode and startup the SSI
+		 */
+		write_ssi(CCSR_SSI_SACNT_AC97EN | CCSR_SSI_SACNT_FV,
+				&ssi->sacnt);
+		write_ssi(0xff, &ssi->saccdis);
+		write_ssi(0x300, &ssi->saccen);
+
+		/*
+		 * Enable SSI
+		 */
+		write_ssi_mask(&ssi->scr, 0, CCSR_SSI_SCR_SSIEN);
+		write_ssi(CCSR_SSI_SOR_WAIT(3), &ssi->sor);
+
+		/*
+		 * Enable Transmit and Receive
+		 */
+		write_ssi_mask(&ssi->scr, 0, CCSR_SSI_SCR_TE | CCSR_SSI_SCR_RE);
+	}
+
+	return 0;
+}
+
+
 /**
  * fsl_ssi_startup: create a new substream
  *
@@ -322,75 +444,14 @@ static int fsl_ssi_startup(struct snd_pcm_substream *substream,
 	 * and initialize the SSI registers.
 	 */
 	if (!ssi_private->first_stream) {
-		struct ccsr_ssi __iomem *ssi = ssi_private->ssi;
-
 		ssi_private->first_stream = substream;
 
 		/*
-		 * Section 16.5 of the MPC8610 reference manual says that the
-		 * SSI needs to be disabled before updating the registers we set
-		 * here.
-		 */
-		write_ssi_mask(&ssi->scr, CCSR_SSI_SCR_SSIEN, 0);
-
-		/*
-		 * Program the SSI into I2S Slave Non-Network Synchronous mode.
-		 * Also enable the transmit and receive FIFO.
-		 *
-		 * FIXME: Little-endian samples require a different shift dir
-		 */
-		write_ssi_mask(&ssi->scr,
-			CCSR_SSI_SCR_I2S_MODE_MASK | CCSR_SSI_SCR_SYN,
-			CCSR_SSI_SCR_TFR_CLK_DIS | CCSR_SSI_SCR_I2S_MODE_SLAVE
-			| (synchronous ? CCSR_SSI_SCR_SYN : 0));
-
-		write_ssi(CCSR_SSI_STCR_TXBIT0 | CCSR_SSI_STCR_TFEN0 |
-			 CCSR_SSI_STCR_TFSI | CCSR_SSI_STCR_TEFS |
-			 CCSR_SSI_STCR_TSCKP, &ssi->stcr);
-
-		write_ssi(CCSR_SSI_SRCR_RXBIT0 | CCSR_SSI_SRCR_RFEN0 |
-			 CCSR_SSI_SRCR_RFSI | CCSR_SSI_SRCR_REFS |
-			 CCSR_SSI_SRCR_RSCKP, &ssi->srcr);
-
-		/*
-		 * The DC and PM bits are only used if the SSI is the clock
-		 * master.
-		 */
-
-		/* Enable the interrupts and DMA requests */
-		if (ssi_private->use_dma)
-			write_ssi(SIER_FLAGS, &ssi->sier);
-		else
-			write_ssi(CCSR_SSI_SIER_TIE | CCSR_SSI_SIER_TFE0_EN |
-					CCSR_SSI_SIER_RIE |
-					CCSR_SSI_SIER_RFF0_EN, &ssi->sier);
-
-		/*
-		 * Set the watermark for transmit FIFI 0 and receive FIFO 0. We
-		 * don't use FIFO 1.  We program the transmit water to signal a
-		 * DMA transfer if there are only two (or fewer) elements left
-		 * in the FIFO.  Two elements equals one frame (left channel,
-		 * right channel).  This value, however, depends on the depth of
-		 * the transmit buffer.
-		 *
-		 * We program the receive FIFO to notify us if at least two
-		 * elements (one frame) have been written to the FIFO.  We could
-		 * make this value larger (and maybe we should), but this way
-		 * data will be written to memory as soon as it's available.
-		 */
-		write_ssi(CCSR_SSI_SFCSR_TFWM0(ssi_private->fifo_depth - 2) |
-			CCSR_SSI_SFCSR_RFWM0(ssi_private->fifo_depth - 2),
-			&ssi->sfcsr);
-
-		/*
-		 * We keep the SSI disabled because if we enable it, then the
-		 * DMA controller will start.  It's not supposed to start until
-		 * the SCR.TE (or SCR.RE) bit is set, but it does anyway.  The
-		 * DMA controller will transfer one "BWC" of data (i.e. the
-		 * amount of data that the MR.BWC bits are set to).  The reason
-		 * this is bad is because at this point, the PCM driver has not
-		 * finished initializing the DMA controller.
+		 * fsl_ssi_setup was already called by ac97_init earlier if
+		 * the driver is in ac97 mode.
 		 */
+		if (!ssi_private->imx_ac97)
+			fsl_ssi_setup(ssi_private);
 	} else {
 		if (synchronous) {
 			struct snd_pcm_runtime *first_runtime =
@@ -545,8 +606,9 @@ static void fsl_ssi_shutdown(struct snd_pcm_substream *substream,
 
 	/*
 	 * If this is the last active substream, disable the SSI.
+	 * If AC97 is active, we don't want to disable SSI.
 	 */
-	if (!ssi_private->first_stream) {
+	if (!ssi_private->first_stream && !ssi_private->imx_ac97) {
 		struct ccsr_ssi __iomem *ssi = ssi_private->ssi;
 
 		write_ssi_mask(&ssi->scr, CCSR_SSI_SCR_SSIEN, 0);
@@ -595,6 +657,176 @@ static const struct snd_soc_component_driver fsl_ssi_component = {
 	.name		= "fsl-ssi",
 };
 
+/**
+ * fsl_ssi_ac97_trigger: start and stop the AC97 receive/transmit.
+ *
+ * This function is called by ALSA to start, stop, pause, and resume the
+ * transfer of data.
+ */
+static int fsl_ssi_ac97_trigger(struct snd_pcm_substream *substream, int cmd,
+			   struct snd_soc_dai *dai)
+{
+	struct snd_soc_pcm_runtime *rtd = substream->private_data;
+	struct fsl_ssi_private *ssi_private = snd_soc_dai_get_drvdata(rtd->cpu_dai);
+	struct ccsr_ssi __iomem *ssi = ssi_private->ssi;
+
+	switch (cmd) {
+	case SNDRV_PCM_TRIGGER_START:
+	case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
+		if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
+			write_ssi_mask(&ssi->sier, 0, CCSR_SSI_SIER_TIE |
+					CCSR_SSI_SIER_TFE0_EN);
+		else
+			write_ssi_mask(&ssi->sier, 0, CCSR_SSI_SIER_RIE |
+					CCSR_SSI_SIER_RFF0_EN);
+		break;
+
+	case SNDRV_PCM_TRIGGER_STOP:
+	case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
+		if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
+			write_ssi_mask(&ssi->sier, CCSR_SSI_SIER_TIE |
+					CCSR_SSI_SIER_TFE0_EN, 0);
+		else
+			write_ssi_mask(&ssi->sier, CCSR_SSI_SIER_RIE |
+					CCSR_SSI_SIER_RFF0_EN, 0);
+		break;
+
+	default:
+		return -EINVAL;
+	}
+
+	if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
+		write_ssi(CCSR_SSI_SOR_TX_CLR, &ssi->sor);
+	else
+		write_ssi(CCSR_SSI_SOR_RX_CLR, &ssi->sor);
+
+	return 0;
+}
+
+static const struct snd_soc_dai_ops fsl_ssi_ac97_dai_ops = {
+	.startup	= fsl_ssi_startup,
+	.shutdown	= fsl_ssi_shutdown,
+	.trigger	= fsl_ssi_ac97_trigger,
+};
+
+static struct snd_soc_dai_driver fsl_ssi_ac97_dai = {
+	.ac97_control = 1,
+	.playback = {
+		.stream_name = "AC97 Playback",
+		.channels_min = 2,
+		.channels_max = 2,
+		.rates = SNDRV_PCM_RATE_8000_48000,
+		.formats = SNDRV_PCM_FMTBIT_S16_LE,
+	},
+	.capture = {
+		.stream_name = "AC97 Capture",
+		.channels_min = 2,
+		.channels_max = 2,
+		.rates = SNDRV_PCM_RATE_48000,
+		.formats = SNDRV_PCM_FMTBIT_S16_LE,
+	},
+	.ops = &fsl_ssi_ac97_dai_ops,
+};
+
+
+static struct fsl_ssi_private *fsl_ac97_data;
+
+static void fsl_ssi_ac97_init(void)
+{
+	fsl_ssi_setup(fsl_ac97_data);
+}
+
+static void fsl_ssi_ac97_write(struct snd_ac97 *ac97, unsigned short reg,
+		unsigned short val)
+{
+	struct ccsr_ssi *ssi = fsl_ac97_data->ssi;
+	unsigned int lreg;
+	unsigned int lval;
+
+	if (reg > 0x7f)
+		return;
+
+
+	lreg = reg <<  12;
+	write_ssi(lreg, &ssi->sacadd);
+
+	lval = val << 4;
+	write_ssi(lval , &ssi->sacdat);
+
+	write_ssi_mask(&ssi->sacnt, CCSR_SSI_SACNT_RDWR_MASK,
+			CCSR_SSI_SACNT_WR);
+	udelay(100);
+}
+
+static unsigned short fsl_ssi_ac97_read(struct snd_ac97 *ac97,
+		unsigned short reg)
+{
+	struct ccsr_ssi *ssi = fsl_ac97_data->ssi;
+
+	unsigned short val = -1;
+	unsigned int lreg;
+
+	lreg = (reg & 0x7f) <<  12 ;
+	write_ssi(lreg, &ssi->sacadd);
+	write_ssi_mask(&ssi->sacnt, CCSR_SSI_SACNT_RDWR_MASK,
+			CCSR_SSI_SACNT_RD);
+
+	udelay(100);
+
+	val = (read_ssi(&ssi->sacdat) >> 4) & 0xffff;
+
+	return val;
+}
+
+static void fsl_ssi_ac97_reset(struct snd_ac97 *ac97)
+{
+	struct fsl_ssi_private *ssi_private = fsl_ac97_data;
+
+	if (ssi_private->ac97_reset)
+		ssi_private->ac97_reset(ac97);
+	/* First read sometimes fails, do a dummy read */
+	fsl_ssi_ac97_read(ac97, 0);
+}
+
+static void fsl_ssi_ac97_warm_reset(struct snd_ac97 *ac97)
+{
+	struct fsl_ssi_private *ssi_private = fsl_ac97_data;
+
+	if (ssi_private->ac97_warm_reset)
+		ssi_private->ac97_warm_reset(ac97);
+
+	/* First read sometimes fails, do a dummy read */
+	fsl_ssi_ac97_read(ac97, 0);
+}
+
+struct snd_ac97_bus_ops soc_ac97_ops = {
+	.read		= fsl_ssi_ac97_read,
+	.write		= fsl_ssi_ac97_write,
+	.reset		= fsl_ssi_ac97_reset,
+	.warm_reset	= fsl_ssi_ac97_warm_reset
+};
+EXPORT_SYMBOL_GPL(soc_ac97_ops);
+
+/*
+ * Pointer to AC97 reset functions for specific boards
+ */
+#if IS_ENABLED(CONFIG_MACH_PCA100)
+extern void pca100_ac97_cold_reset(struct snd_ac97 *ac97);
+extern void pca100_ac97_warm_reset(struct snd_ac97 *ac97);
+#else
+void pca100_ac97_cold_reset(struct snd_ac97 *ac97) { }
+void pca100_ac97_warm_reset(struct snd_ac97 *ac97) { }
+#endif
+
+#if IS_ENABLED(CONFIG_MACH_PCM043)
+extern void pcm043_ac97_cold_reset(struct snd_ac97 *ac97);
+extern void pcm043_ac97_warm_reset(struct snd_ac97 *ac97);
+#else
+void pcm043_ac97_cold_reset(struct snd_ac97 *ac97) { }
+void pcm043_ac97_warm_reset(struct snd_ac97 *ac97) { }
+#endif
+
+
 /* Show the statistics of a flag only if its interrupt is enabled.  The
  * compiler will optimze this code to a no-op if the interrupt is not
  * enabled.
@@ -671,6 +903,7 @@ static int fsl_ssi_probe(struct platform_device *pdev)
 	struct resource res;
 	char name[64];
 	bool shared;
+	bool ac97 = false;
 
 	/* SSIs that are not connected on the board should have a
 	 *      status = "disabled"
@@ -681,7 +914,13 @@ static int fsl_ssi_probe(struct platform_device *pdev)
 
 	/* We only support the SSI in "I2S Slave" mode */
 	sprop = of_get_property(np, "fsl,mode", NULL);
-	if (!sprop || strcmp(sprop, "i2s-slave")) {
+	if (!sprop) {
+		dev_err(&pdev->dev, "fsl,mode property is necessary\n");
+		return -EINVAL;
+	}
+	if (!strcmp(sprop, "ac97-slave")) {
+		ac97 = true;
+	} else if (strcmp(sprop, "i2s-slave")) {
 		dev_notice(&pdev->dev, "mode %s is unsupported\n", sprop);
 		return -ENODEV;
 	}
@@ -697,13 +936,39 @@ static int fsl_ssi_probe(struct platform_device *pdev)
 
 	strcpy(ssi_private->name, p);
 
-	/* Initialize this copy of the CPU DAI driver structure */
-	memcpy(&ssi_private->cpu_dai_drv, &fsl_ssi_dai_template,
-	       sizeof(fsl_ssi_dai_template));
-	ssi_private->cpu_dai_drv.name = ssi_private->name;
-
 	ssi_private->use_dma = !of_property_read_bool(np, "fsl,imx-fiq");
 
+	if (ac97) {
+		sprop = of_get_property(of_find_node_by_path("/"), "compatible",
+				NULL);
+		p = strrchr(sprop, ',');
+		if (p)
+			sprop = p + 1;
+
+		if (!strcmp(sprop, "imx27-pca100")) {
+			ssi_private->ac97_reset = pca100_ac97_cold_reset;
+			ssi_private->ac97_warm_reset = pca100_ac97_warm_reset;
+		} else if (!strcmp(sprop, "imx27-pcm043")) {
+			ssi_private->ac97_reset = pcm043_ac97_cold_reset;
+			ssi_private->ac97_warm_reset = pcm043_ac97_warm_reset;
+		} else {
+			dev_err(&pdev->dev, "Failed to enable ssi AC97 mode, unknown board.\n");
+			ret = -EINVAL;
+			goto error_kmalloc;
+		}
+
+		memcpy(&ssi_private->cpu_dai_drv, &fsl_ssi_ac97_dai,
+				sizeof(fsl_ssi_ac97_dai));
+
+		fsl_ac97_data = ssi_private;
+		ssi_private->imx_ac97 = true;
+	} else {
+		/* Initialize this copy of the CPU DAI driver structure */
+		memcpy(&ssi_private->cpu_dai_drv, &fsl_ssi_dai_template,
+		       sizeof(fsl_ssi_dai_template));
+	}
+	ssi_private->cpu_dai_drv.name = ssi_private->name;
+
 	/* Get the addresses and IRQ */
 	ret = of_address_to_resource(np, 0, &res);
 	if (ret) {
@@ -894,6 +1159,9 @@ static int fsl_ssi_probe(struct platform_device *pdev)
 	}
 
 done:
+	if (ssi_private->imx_ac97)
+		fsl_ssi_ac97_init();
+
 	return 0;
 
 error_dai:
-- 
1.8.1.5



From mpa at pengutronix.de  Sun Apr 14 07:42:54 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Sun, 14 Apr 2013 13:42:54 +0200
Subject: [PATCH v3 10/15] ASoC: fsl-ssi: Use generic DMA bindings if possible
In-Reply-To: <1365939779-4507-1-git-send-email-mpa@pengutronix.de>
References: <1365939779-4507-1-git-send-email-mpa@pengutronix.de>
Message-ID: <1365939779-4507-11-git-send-email-mpa@pengutronix.de>

From: Markus Pargmann <mpa at pengutrnoix.de>

There may be some platforms using fsl-ssi that do not have a DMA driver
with generic DMA bindings. So this patch adds support for the generic
DMA bindings, while still using the old "fsl,dma-events" property if
"dmas" is not found.

Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
---
 sound/soc/fsl/fsl_ssi.c | 26 ++++++++++++++++----------
 1 file changed, 16 insertions(+), 10 deletions(-)

diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index 6a9be9c..1ab66f8 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -776,15 +776,19 @@ static int fsl_ssi_probe(struct platform_device *pdev)
 			&ssi_private->filter_data_tx;
 		ssi_private->dma_params_rx.filter_data =
 			&ssi_private->filter_data_rx;
-		/*
-		 * TODO: This is a temporary solution and should be changed
-		 * to use generic DMA binding later when the helplers get in.
-		 */
-		ret = of_property_read_u32_array(pdev->dev.of_node,
+		if (!of_property_read_bool(pdev->dev.of_node, "dmas") &&
+				ssi_private->use_dma) {
+			/*
+			 * TODO: This is a temporary solution and should be
+			 * changed to use generic DMA binding later when the
+			 * helplers get in.
+			 */
+			ret = of_property_read_u32_array(pdev->dev.of_node,
 					"fsl,ssi-dma-events", dma_events, 2);
-		if (ret && !ssi_private->use_dma) {
-			dev_err(&pdev->dev, "could not get dma events\n");
-			goto error_clk;
+			if (ret && ssi_private->use_dma) {
+				dev_err(&pdev->dev, "could not get dma events but fsl-ssi is configured to use DMA\n");
+				goto error_clk;
+			}
 		}
 
 		shared = of_device_is_compatible(of_get_parent(np),
@@ -847,8 +851,10 @@ static int fsl_ssi_probe(struct platform_device *pdev)
 			}
 		} else {
 			ssi_private->imx_pcm_pdev =
-				platform_device_register_simple("imx-pcm-audio",
-							-1, NULL, 0);
+				platform_device_register_data(&pdev->dev,
+						"imx-pcm-audio", -1,
+						pdev->dev.of_node,
+						sizeof(*pdev->dev.of_node));
 			if (IS_ERR(ssi_private->imx_pcm_pdev)) {
 				ret = PTR_ERR(ssi_private->imx_pcm_pdev);
 				goto error_dev;
-- 
1.8.1.5



From lars at metafoo.de  Sun Apr 14 08:13:15 2013
From: lars at metafoo.de (Lars-Peter Clausen)
Date: Sun, 14 Apr 2013 14:13:15 +0200
Subject: [PATCH v3 00/15] ASoC: fsl-ssi: ac97-slave support
In-Reply-To: <1365939779-4507-1-git-send-email-mpa@pengutronix.de>
References: <1365939779-4507-1-git-send-email-mpa@pengutronix.de>
Message-ID: <516A9D5B.2070707@metafoo.de>

On 04/14/2013 01:42 PM, Markus Pargmann wrote:
> Hi,
> 
> This series adds DT support for phycore-ac97. It is now based on the pcm dma
> cleanups from Lars. Beside ac97 support, the series adds fsl-ssi imx-pcm-fiq
> and generic DMA binding handling.
> 
> @Lars:
> There are 4 new patches at the beginning of the series that fix some problems
> of your cleanups. I think they were in the changes you posted. If not, could you
> please add them to your branch?

Hi,

I had already fixed them localy. I'm in the process of polishing the last bits
and pieces of my generic dmaengine PCM driver series right now and will submit
it later today.

- Lars


From wsa at the-dreams.de  Sun Apr 14 08:20:35 2013
From: wsa at the-dreams.de (Wolfram Sang)
Date: Sun, 14 Apr 2013 14:20:35 +0200
Subject: [PATCH 08/30] i2c: s3c2410: make header file local
In-Reply-To: <1365638712-1028578-9-git-send-email-arnd@arndb.de>
References: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
 <1365638712-1028578-9-git-send-email-arnd@arndb.de>
Message-ID: <20130414122035.GB9013@the-dreams.de>

On Thu, Apr 11, 2013 at 02:04:50AM +0200, Arnd Bergmann wrote:

> No other file in the kernel besides i2c-s3c2410.c uses the current
> plat/regs-iic.h, so we can simply move the header file to live in the
> same directory as the driver, as a preparation to multiplatform builds.

What about putting the regs in the driver itself?



From timur at tabi.org  Sun Apr 14 09:37:21 2013
From: timur at tabi.org (Timur Tabi)
Date: Sun, 14 Apr 2013 08:37:21 -0500
Subject: [PATCH v2 05/11] ASoC: fsl-ssi: Add support for imx-pcm-fiq
In-Reply-To: <20130414103819.GA27394@pengutronix.de>
References: <1365362721-3731-1-git-send-email-mpa@pengutronix.de>
 <1365362721-3731-6-git-send-email-mpa@pengutronix.de>
 <51620CEA.3010703@tabi.org> <20130414103819.GA27394@pengutronix.de>
Message-ID: <516AB111.3000007@tabi.org>

Markus Pargmann wrote:
> I do not think it is possible. For example imx27 ssi does support
> DMA but for specific boards we have to use fiq instead (phycore-ac97).
> So I would prefer to define the DMA in the chip dtsi file and choose
> fiq, if necessary, in the board dts.

I'm not completely familiar with the way i.MX SSI bindings work, but isn't 
there some property that says, "this SSI needs to use this DMA channel"? 
So if that property is missing, then it means that there's no link between 
the SSI and a DMA channel, and so you need to use FIQ.

For example, for PowerPC bindings, we have this:

		ssi at 16000 {
			compatible = "fsl,mpc8610-ssi";
			cell-index = <0>;
			reg = <0x16000 0x100>;
			interrupt-parent = <&mpic>;
			interrupts = <62 2>;
			fsl,mode = "i2s-slave";
			codec-handle = <&cs4270>;
-->			fsl,playback-dma = <&dma00>;
-->			fsl,capture-dma = <&dma01>;

So on PowerPC, if these two properties are missing, then we would use 
interrupt mode.


-- 
Timur Tabi


From mpa at pengutronix.de  Sun Apr 14 10:10:15 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Sun, 14 Apr 2013 16:10:15 +0200
Subject: [PATCH v2 05/11] ASoC: fsl-ssi: Add support for imx-pcm-fiq
In-Reply-To: <516AB111.3000007@tabi.org>
References: <1365362721-3731-1-git-send-email-mpa@pengutronix.de>
 <1365362721-3731-6-git-send-email-mpa@pengutronix.de>
 <51620CEA.3010703@tabi.org> <20130414103819.GA27394@pengutronix.de>
 <516AB111.3000007@tabi.org>
Message-ID: <20130414141015.GC27394@pengutronix.de>

On Sun, Apr 14, 2013 at 08:37:21AM -0500, Timur Tabi wrote:
> Markus Pargmann wrote:
> >I do not think it is possible. For example imx27 ssi does support
> >DMA but for specific boards we have to use fiq instead (phycore-ac97).
> >So I would prefer to define the DMA in the chip dtsi file and choose
> >fiq, if necessary, in the board dts.
>
> I'm not completely familiar with the way i.MX SSI bindings work, but
> isn't there some property that says, "this SSI needs to use this DMA
> channel"? So if that property is missing, then it means that there's
> no link between the SSI and a DMA channel, and so you need to use
> FIQ.
>
> For example, for PowerPC bindings, we have this:
>
> 		ssi at 16000 {
> 			compatible = "fsl,mpc8610-ssi";
> 			cell-index = <0>;
> 			reg = <0x16000 0x100>;
> 			interrupt-parent = <&mpic>;
> 			interrupts = <62 2>;
> 			fsl,mode = "i2s-slave";
> 			codec-handle = <&cs4270>;
> -->			fsl,playback-dma = <&dma00>;
> -->			fsl,capture-dma = <&dma01>;
>
> So on PowerPC, if these two properties are missing, then we would
> use interrupt mode.

In general, imx27 does support SSI with DMA, for example
MACH_IMX27_VISSTRIM_M10 does use SSI with DMA. But there are special
boards like Eukrea TLV320 and phycore-ac97 that have to use FIQ instead.
All of them have a imx27 chip.
The imx27 SSI node (not posted yet) using the generic DMA bindings:

	ssi1: ssi at 10010000 {
		compatible = "fsl,imx21-ssi";
		reg = <0x10010000 0x1000>;
		interrupts = <14>;
		dmas = <&dma 13
			&dma 12
			&dma 15
			&dma 14>;
		dma-names = "tx", "rx", "tx1", "rx1";
		clocks = <&clks 26>;
		clock-names = "ipg";
		fsl,mode = "i2s-slave";
		status = "disabled";
	};

So instead of defining the dma channels in imx27.dtsi, we could define
them only in board dts files. But that would duplicate the DMA property for
every board using DMA. The alternative is the "fsl,imx-fiq" property as
introduced in this patch.

Regards,

Markus

--
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From mpa at pengutronix.de  Sun Apr 14 10:31:32 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Sun, 14 Apr 2013 16:31:32 +0200
Subject: [PATCH v3 2/2] video: imxfb: Add DT support
In-Reply-To: <20130408075742.GR20693@game.jcrosoft.org>
References: <1365157876-1757-1-git-send-email-mpa@pengutronix.de>
 <1365157876-1757-3-git-send-email-mpa@pengutronix.de>
 <20130408075742.GR20693@game.jcrosoft.org>
Message-ID: <20130414143132.GD27394@pengutronix.de>

On Mon, Apr 08, 2013 at 09:57:42AM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 12:31 Fri 05 Apr     , Markus Pargmann wrote:
> > Add devicetree support for imx framebuffer driver. It uses the generic
> > display bindings and helper functions.
> > 
> > Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
> > Cc: Fabio Estevam <festevam at gmail.com>
> > Cc: Mark Rutland <mark.rutland at arm.com>
> > ---
> >  .../devicetree/bindings/video/fsl,imx-fb.txt       |  49 ++++++
> >  drivers/video/imxfb.c                              | 192 +++++++++++++++++----
> >  2 files changed, 207 insertions(+), 34 deletions(-)
> >  create mode 100644 Documentation/devicetree/bindings/video/fsl,imx-fb.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/video/fsl,imx-fb.txt b/Documentation/devicetree/bindings/video/fsl,imx-fb.txt
> > new file mode 100644
> > index 0000000..bde9c77
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/video/fsl,imx-fb.txt
> > @@ -0,0 +1,49 @@
> > +Freescale imx21 Framebuffer
> > +
> > +This framebuffer driver supports devices imx1, imx21, imx25, and imx27.
> > +
> > +Required properties:
> > +- compatible : "fsl,<chip>-fb", chip should be imx1 or imx21
> > +- reg : Should contain 1 register ranges(address and length)
> > +- interrupts : One interrupt of the fb dev
> > +
> > +Required nodes:
> > +- display: Phandle to a display node as described in
> > +	Documentation/devicetree/bindings/video/display-timing.txt
> > +	Additional, the display node has to define properties:
> > +	- fsl,bpp: Bits per pixel
> > +	- fsl,pcr: LCDC PCR value
> > +
> > +Optional properties:
> > +- dmacr-eukrea: Should be set for eukrea boards.
> why ?

Because eukrea boards have a different dmacr then all other boards using
imxfb. The dmacr address is hardcoded as defaults in the code. I could
also search for the board name in the DT, but there are no eukrea boards
with DT at the moment, so I thought a bool property may be better for
the moment.

> 
> and This should be prefix by yhe Vendor here Eukrea

Okay.

Regards,

Markus

> > +
> > +Example:
> > +
> > +	imxfb: fb at 10021000 {
> > +		compatible = "fsl,imx27-fb", "fsl,imx21-fb";
> > +		interrupts = <61>;
> > +		reg = <0x10021000 0x1000>;
> > +		display = <&display0>;
> > +	};
> > +
> > +	...
> > +
> > +	display0: display0 {
> > +		model = "Primeview-PD050VL1";
> > +		native-mode = <&timing_disp0>;
> > +		fsl,bpp = <16>;		/* non-standard but required */
> > +		fsl,pcr = <0xf0c88080>;	/* non-standard but required */
> > +		display-timings {
> > +			timing_disp0: 640x480 {
> > +				hactive = <640>;
> > +				vactive = <480>;
> > +				hback-porch = <112>;
> > +				hfront-porch = <36>;
> > +				hsync-len = <32>;
> > +				vback-porch = <33>;
> > +				vfront-porch = <33>;
> > +				vsync-len = <2>;
> > +				clock-frequency = <25000000>;
> > +			};
> > +		};
> > +	};
> > diff --git a/drivers/video/imxfb.c b/drivers/video/imxfb.c
> > index ef2b587..5a9bc598 100644
> > --- a/drivers/video/imxfb.c
> > +++ b/drivers/video/imxfb.c
> > @@ -32,6 +32,12 @@
> >  #include <linux/io.h>
> >  #include <linux/math64.h>
> >  #include <linux/uaccess.h>
> > +#include <linux/of.h>
> > +#include <linux/of_device.h>
> > +
> > +#include <video/of_display_timing.h>
> > +#include <video/of_videomode.h>
> > +#include <video/videomode.h>
> >  
> >  #include <linux/platform_data/video-imxfb.h>
> >  
> > @@ -117,10 +123,13 @@
> >  #define LGWCR_GWAV(alpha)	(((alpha) & 0xff) << 24)
> >  #define LGWCR_GWE	(1 << 22)
> >  
> > +#define IMXFB_LSCR1_DEFAULT 0x00120300
> > +#define IMXFB_DMACR_DEFAULT 0x00020010
> > +#define IMXFB_DMACR_EUKREA_DEFAULT 0x00040060
> > +
> >  /* Used fb-mode. Can be set on kernel command line, therefore file-static. */
> >  static const char *fb_mode;
> >  
> > -
> >  /*
> >   * These are the bitfields for each
> >   * display depth that we support.
> > @@ -192,6 +201,19 @@ static struct platform_device_id imxfb_devtype[] = {
> >  };
> >  MODULE_DEVICE_TABLE(platform, imxfb_devtype);
> >  
> > +static struct of_device_id imxfb_of_dev_id[] = {
> > +	{
> > +		.compatible = "fsl,imx1-fb",
> > +		.data = &imxfb_devtype[IMX1_FB],
> > +	}, {
> > +		.compatible = "fsl,imx21-fb",
> > +		.data = &imxfb_devtype[IMX21_FB],
> > +	}, {
> > +		/* sentinel */
> > +	}
> > +};
> > +MODULE_DEVICE_TABLE(of, imxfb_of_dev_id);
> > +
> >  static inline int is_imx1_fb(struct imxfb_info *fbi)
> >  {
> >  	return fbi->devtype == IMX1_FB;
> > @@ -324,6 +346,9 @@ static const struct imx_fb_videomode *imxfb_find_mode(struct imxfb_info *fbi)
> >  	struct imx_fb_videomode *m;
> >  	int i;
> >  
> > +	if (!fb_mode)
> > +		return &fbi->mode[0];
> > +
> >  	for (i = 0, m = &fbi->mode[0]; i < fbi->num_modes; i++, m++) {
> >  		if (!strcmp(m->mode.name, fb_mode))
> >  			return m;
> > @@ -479,6 +504,9 @@ static int imxfb_bl_update_status(struct backlight_device *bl)
> >  	struct imxfb_info *fbi = bl_get_data(bl);
> >  	int brightness = bl->props.brightness;
> >  
> > +	if (!fbi->pwmr)
> > +		return 0;
> > +
> >  	if (bl->props.power != FB_BLANK_UNBLANK)
> >  		brightness = 0;
> >  	if (bl->props.fb_blank != FB_BLANK_UNBLANK)
> > @@ -719,7 +747,8 @@ static int imxfb_activate_var(struct fb_var_screeninfo *var, struct fb_info *inf
> >  
> >  	writel(fbi->pcr, fbi->regs + LCDC_PCR);
> >  #ifndef PWMR_BACKLIGHT_AVAILABLE
> > -	writel(fbi->pwmr, fbi->regs + LCDC_PWMR);
> > +	if (fbi->pwmr)
> > +		writel(fbi->pwmr, fbi->regs + LCDC_PWMR);
> >  #endif
> >  	writel(fbi->lscr1, fbi->regs + LCDC_LSCR1);
> >  	writel(fbi->dmacr, fbi->regs + LCDC_DMACR);
> > @@ -758,13 +787,12 @@ static int imxfb_resume(struct platform_device *dev)
> >  #define imxfb_resume	NULL
> >  #endif
> >  
> > -static int __init imxfb_init_fbinfo(struct platform_device *pdev)
> > +static int imxfb_init_fbinfo(struct platform_device *pdev)
> >  {
> >  	struct imx_fb_platform_data *pdata = pdev->dev.platform_data;
> >  	struct fb_info *info = dev_get_drvdata(&pdev->dev);
> >  	struct imxfb_info *fbi = info->par;
> > -	struct imx_fb_videomode *m;
> > -	int i;
> > +	struct device_node *np;
> >  
> >  	pr_debug("%s\n",__func__);
> >  
> > @@ -795,41 +823,96 @@ static int __init imxfb_init_fbinfo(struct platform_device *pdev)
> >  	info->fbops			= &imxfb_ops;
> >  	info->flags			= FBINFO_FLAG_DEFAULT |
> >  					  FBINFO_READS_FAST;
> > -	info->var.grayscale		= pdata->cmap_greyscale;
> > -	fbi->cmap_inverse		= pdata->cmap_inverse;
> > -	fbi->cmap_static		= pdata->cmap_static;
> > -	fbi->lscr1			= pdata->lscr1;
> > -	fbi->dmacr			= pdata->dmacr;
> > -	fbi->pwmr			= pdata->pwmr;
> > -	fbi->lcd_power			= pdata->lcd_power;
> > -	fbi->backlight_power		= pdata->backlight_power;
> > -
> > -	for (i = 0, m = &pdata->mode[0]; i < pdata->num_modes; i++, m++)
> > -		info->fix.smem_len = max_t(size_t, info->fix.smem_len,
> > -				m->mode.xres * m->mode.yres * m->bpp / 8);
> > +	if (pdata) {
> > +		info->var.grayscale		= pdata->cmap_greyscale;
> > +		fbi->cmap_inverse		= pdata->cmap_inverse;
> > +		fbi->cmap_static		= pdata->cmap_static;
> > +		fbi->lscr1			= pdata->lscr1;
> > +		fbi->dmacr			= pdata->dmacr;
> > +		fbi->pwmr			= pdata->pwmr;
> > +		fbi->lcd_power			= pdata->lcd_power;
> > +		fbi->backlight_power		= pdata->backlight_power;
> > +	} else {
> > +		np = pdev->dev.of_node;
> > +		info->var.grayscale = of_property_read_bool(np,
> > +						"cmap-greyscale");
> > +		fbi->cmap_inverse = of_property_read_bool(np, "cmap-inverse");
> > +		fbi->cmap_static = of_property_read_bool(np, "cmap-static");
> > +
> > +		fbi->lscr1 = IMXFB_LSCR1_DEFAULT;
> > +		if (of_property_read_bool(np, "dmacr-eukrea"))
> > +			fbi->dmacr = IMXFB_DMACR_EUKREA_DEFAULT;
> > +		else
> > +			fbi->dmacr = IMXFB_DMACR_DEFAULT;
> > +
> > +		/* These two function pointers could be used by some specific
> > +		 * platforms. */
> > +		fbi->lcd_power = NULL;
> > +		fbi->backlight_power = NULL;
> > +	}
> > +
> > +	return 0;
> > +}
> > +
> > +static int imxfb_of_read_mode(struct device *dev, struct device_node *np,
> > +		struct imx_fb_videomode *imxfb_mode)
> > +{
> > +	int ret;
> > +	struct fb_videomode *of_mode = &imxfb_mode->mode;
> > +	u32 bpp;
> > +	u32 pcr;
> > +
> > +	ret = of_property_read_string(np, "model", &of_mode->name);
> > +	if (ret)
> > +		of_mode->name = NULL;
> > +
> > +	ret = of_get_fb_videomode(np, of_mode, OF_USE_NATIVE_MODE);
> > +	if (ret) {
> > +		dev_err(dev, "Failed to get videomode from DT\n");
> > +		return ret;
> > +	}
> > +
> > +	ret = of_property_read_u32(np, "fsl,bpp", &bpp);
> > +	ret |= of_property_read_u32(np, "fsl,pcr", &pcr);
> > +
> > +	if (ret) {
> > +		dev_err(dev, "Failed to read bpp and pcr from DT\n");
> > +		return -EINVAL;
> > +	}
> > +
> > +	if (bpp < 1 || bpp > 255) {
> > +		dev_err(dev, "Bits per pixel have to be between 1 and 255\n");
> > +		return -EINVAL;
> > +	}
> > +
> > +	imxfb_mode->bpp = bpp;
> > +	imxfb_mode->pcr = pcr;
> >  
> >  	return 0;
> >  }
> >  
> > -static int __init imxfb_probe(struct platform_device *pdev)
> > +static int imxfb_probe(struct platform_device *pdev)
> >  {
> >  	struct imxfb_info *fbi;
> >  	struct fb_info *info;
> >  	struct imx_fb_platform_data *pdata;
> >  	struct resource *res;
> > +	struct imx_fb_videomode *m;
> > +	const struct of_device_id *of_id;
> >  	int ret, i;
> > +	int bytes_per_pixel;
> >  
> >  	dev_info(&pdev->dev, "i.MX Framebuffer driver\n");
> >  
> > +	of_id = of_match_device(imxfb_of_dev_id, &pdev->dev);
> > +	if (of_id)
> > +		pdev->id_entry = of_id->data;
> > +
> >  	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> >  	if (!res)
> >  		return -ENODEV;
> >  
> >  	pdata = pdev->dev.platform_data;
> > -	if (!pdata) {
> > -		dev_err(&pdev->dev,"No platform_data available\n");
> > -		return -ENOMEM;
> > -	}
> >  
> >  	info = framebuffer_alloc(sizeof(struct imxfb_info), &pdev->dev);
> >  	if (!info)
> > @@ -837,15 +920,55 @@ static int __init imxfb_probe(struct platform_device *pdev)
> >  
> >  	fbi = info->par;
> >  
> > -	if (!fb_mode)
> > -		fb_mode = pdata->mode[0].mode.name;
> > -
> >  	platform_set_drvdata(pdev, info);
> >  
> >  	ret = imxfb_init_fbinfo(pdev);
> >  	if (ret < 0)
> >  		goto failed_init;
> >  
> > +	if (pdata) {
> > +		if (!fb_mode)
> > +			fb_mode = pdata->mode[0].mode.name;
> > +
> > +		fbi->mode = pdata->mode;
> > +		fbi->num_modes = pdata->num_modes;
> > +	} else {
> > +		struct device_node *display_np;
> > +		fb_mode = NULL;
> > +
> > +		display_np = of_parse_phandle(pdev->dev.of_node, "display", 0);
> > +		if (!display_np) {
> > +			dev_err(&pdev->dev, "No display defined in devicetree\n");
> > +			ret = -EINVAL;
> > +			goto failed_of_parse;
> > +		}
> > +
> > +		/*
> > +		 * imxfb does not support more modes, we choose only the native
> > +		 * mode.
> > +		 */
> > +		fbi->num_modes = 1;
> > +
> > +		fbi->mode = devm_kzalloc(&pdev->dev,
> > +				sizeof(struct imx_fb_videomode), GFP_KERNEL);
> > +		if (!fbi->mode) {
> > +			ret = -ENOMEM;
> > +			goto failed_of_parse;
> > +		}
> > +
> > +		ret = imxfb_of_read_mode(&pdev->dev, display_np, fbi->mode);
> > +		if (ret)
> > +			goto failed_of_parse;
> > +	}
> > +
> > +	/* Calculate maximum bytes used per pixel. In most cases this should
> > +	 * be the same as m->bpp/8 */
> > +	m = &fbi->mode[0];
> > +	bytes_per_pixel = (m->bpp + 7) / 8;
> > +	for (i = 0; i < fbi->num_modes; i++, m++)
> > +		info->fix.smem_len = max_t(size_t, info->fix.smem_len,
> > +				m->mode.xres * m->mode.yres * bytes_per_pixel);
> > +
> >  	res = request_mem_region(res->start, resource_size(res),
> >  				DRIVER_NAME);
> >  	if (!res) {
> > @@ -878,7 +1001,8 @@ static int __init imxfb_probe(struct platform_device *pdev)
> >  		goto failed_ioremap;
> >  	}
> >  
> > -	if (!pdata->fixed_screen_cpu) {
> > +	/* Seems not being used by anyone, so no support for oftree */
> > +	if (!pdata || !pdata->fixed_screen_cpu) {
> >  		fbi->map_size = PAGE_ALIGN(info->fix.smem_len);
> >  		fbi->map_cpu = dma_alloc_writecombine(&pdev->dev,
> >  				fbi->map_size, &fbi->map_dma, GFP_KERNEL);
> > @@ -903,18 +1027,16 @@ static int __init imxfb_probe(struct platform_device *pdev)
> >  		info->fix.smem_start = fbi->screen_dma;
> >  	}
> >  
> > -	if (pdata->init) {
> > +	if (pdata && pdata->init) {
> >  		ret = pdata->init(fbi->pdev);
> >  		if (ret)
> >  			goto failed_platform_init;
> >  	}
> >  
> > -	fbi->mode = pdata->mode;
> > -	fbi->num_modes = pdata->num_modes;
> >  
> >  	INIT_LIST_HEAD(&info->modelist);
> > -	for (i = 0; i < pdata->num_modes; i++)
> > -		fb_add_videomode(&pdata->mode[i].mode, &info->modelist);
> > +	for (i = 0; i < fbi->num_modes; i++)
> > +		fb_add_videomode(&fbi->mode[i].mode, &info->modelist);
> >  
> >  	/*
> >  	 * This makes sure that our colour bitfield
> > @@ -944,10 +1066,10 @@ static int __init imxfb_probe(struct platform_device *pdev)
> >  failed_register:
> >  	fb_dealloc_cmap(&info->cmap);
> >  failed_cmap:
> > -	if (pdata->exit)
> > +	if (pdata && pdata->exit)
> >  		pdata->exit(fbi->pdev);
> >  failed_platform_init:
> > -	if (!pdata->fixed_screen_cpu)
> > +	if (pdata && !pdata->fixed_screen_cpu)
> >  		dma_free_writecombine(&pdev->dev,fbi->map_size,fbi->map_cpu,
> >  			fbi->map_dma);
> >  failed_map:
> > @@ -956,6 +1078,7 @@ failed_ioremap:
> >  failed_getclock:
> >  	release_mem_region(res->start, resource_size(res));
> >  failed_req:
> > +failed_of_parse:
> >  	kfree(info->pseudo_palette);
> >  failed_init:
> >  	platform_set_drvdata(pdev, NULL);
> > @@ -980,7 +1103,7 @@ static int imxfb_remove(struct platform_device *pdev)
> >  	unregister_framebuffer(info);
> >  
> >  	pdata = pdev->dev.platform_data;
> > -	if (pdata->exit)
> > +	if (pdata && pdata->exit)
> >  		pdata->exit(fbi->pdev);
> >  
> >  	fb_dealloc_cmap(&info->cmap);
> > @@ -1009,6 +1132,7 @@ static struct platform_driver imxfb_driver = {
> >  	.shutdown	= imxfb_shutdown,
> >  	.driver		= {
> >  		.name	= DRIVER_NAME,
> > +		.of_match_table = imxfb_of_dev_id,
> >  	},
> >  	.id_table	= imxfb_devtype,
> >  };
> > -- 
> > 1.8.1.5
> > 
> > _______________________________________________
> > devicetree-discuss mailing list
> > devicetree-discuss at lists.ozlabs.org
> > https://lists.ozlabs.org/listinfo/devicetree-discuss
> 

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From timur at tabi.org  Sun Apr 14 10:53:57 2013
From: timur at tabi.org (Timur Tabi)
Date: Sun, 14 Apr 2013 09:53:57 -0500
Subject: [PATCH v2 05/11] ASoC: fsl-ssi: Add support for imx-pcm-fiq
In-Reply-To: <20130414141015.GC27394@pengutronix.de>
References: <1365362721-3731-1-git-send-email-mpa@pengutronix.de>
 <1365362721-3731-6-git-send-email-mpa@pengutronix.de>
 <51620CEA.3010703@tabi.org> <20130414103819.GA27394@pengutronix.de>
 <516AB111.3000007@tabi.org> <20130414141015.GC27394@pengutronix.de>
Message-ID: <516AC305.2000800@tabi.org>

Markus Pargmann wrote:
> In general, imx27 does support SSI with DMA, for example
> MACH_IMX27_VISSTRIM_M10 does use SSI with DMA. But there are special
> boards like Eukrea TLV320 and phycore-ac97 that have to use FIQ instead.
> All of them have a imx27 chip.

Why is the decision to use FIQ board-specific?  All of the hardware is 
inside the SoC itself.  How could a board make using DMA impossible?

-- 
Timur Tabi


From andrew at lunn.ch  Sun Apr 14 11:14:29 2013
From: andrew at lunn.ch (Andrew Lunn)
Date: Sun, 14 Apr 2013 17:14:29 +0200
Subject: [V3 patch 17/19] ARM: kirkwood: cpuidle: use init/exit common
 routine
In-Reply-To: <1365770165-27096-18-git-send-email-daniel.lezcano@linaro.org>
References: <1365770165-27096-1-git-send-email-daniel.lezcano@linaro.org>
 <1365770165-27096-18-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <20130414151429.GF5061@lunn.ch>

On Fri, Apr 12, 2013 at 02:36:03PM +0200, Daniel Lezcano wrote:
> Remove the duplicated code and use the cpuidle common code for initialization.
> 
> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
> ---
>  drivers/cpuidle/cpuidle-kirkwood.c |   17 ++---------------
>  1 file changed, 2 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/cpuidle/cpuidle-kirkwood.c b/drivers/cpuidle/cpuidle-kirkwood.c
> index 6f31524..53290e1 100644
> --- a/drivers/cpuidle/cpuidle-kirkwood.c
> +++ b/drivers/cpuidle/cpuidle-kirkwood.c
> @@ -52,9 +52,6 @@ static struct cpuidle_driver kirkwood_idle_driver = {
>  	},
>  	.state_count = KIRKWOOD_MAX_STATES,
>  };
> -static struct cpuidle_device *device;
> -
> -static DEFINE_PER_CPU(struct cpuidle_device, kirkwood_cpuidle_device);
>  
>  /* Initialize CPU idle by registering the idle states */
>  static int kirkwood_cpuidle_probe(struct platform_device *pdev)
> @@ -69,22 +66,12 @@ static int kirkwood_cpuidle_probe(struct platform_device *pdev)
>  	if (IS_ERR(ddr_operation_base))
>  		return PTR_ERR(ddr_operation_base);
>  
> -	device = &per_cpu(kirkwood_cpuidle_device, smp_processor_id());
> -	device->state_count = KIRKWOOD_MAX_STATES;
> -
> -	cpuidle_register_driver(&kirkwood_idle_driver);
> -	if (cpuidle_register_device(device)) {
> -		pr_err("kirkwood_init_cpuidle: Failed registering\n");
> -		return -EIO;
> -	}
> -	return 0;
> +	return cpuidle_register(&kirkwood_idle_driver, NULL);
>  }
>  
>  int kirkwood_cpuidle_remove(struct platform_device *pdev)
>  {
> -	cpuidle_unregister_device(device);
> -	cpuidle_unregister_driver(&kirkwood_idle_driver);
> -
> +	cpuidle_unregister(&kirkwood_idle_driver);
>  	return 0;
>  }
>  
> -- 
> 1.7.9.5
> 

Tested-by: Andrew Lunn <andrew at lunn.ch>


From mpa at pengutronix.de  Sun Apr 14 11:20:16 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Sun, 14 Apr 2013 17:20:16 +0200
Subject: [PATCH v2 05/11] ASoC: fsl-ssi: Add support for imx-pcm-fiq
In-Reply-To: <516AC305.2000800@tabi.org>
References: <1365362721-3731-1-git-send-email-mpa@pengutronix.de>
 <1365362721-3731-6-git-send-email-mpa@pengutronix.de>
 <51620CEA.3010703@tabi.org> <20130414103819.GA27394@pengutronix.de>
 <516AB111.3000007@tabi.org> <20130414141015.GC27394@pengutronix.de>
 <516AC305.2000800@tabi.org>
Message-ID: <20130414152016.GE27394@pengutronix.de>

On Sun, Apr 14, 2013 at 09:53:57AM -0500, Timur Tabi wrote:
> Markus Pargmann wrote:
> >In general, imx27 does support SSI with DMA, for example
> >MACH_IMX27_VISSTRIM_M10 does use SSI with DMA. But there are special
> >boards like Eukrea TLV320 and phycore-ac97 that have to use FIQ instead.
> >All of them have a imx27 chip.
> 
> Why is the decision to use FIQ board-specific?  All of the hardware
> is inside the SoC itself.  How could a board make using DMA
> impossible?

I only ported the imx-ssi ac97 driver code and tested twice using DMA
without success. But there is a good description of the problem in
imx-ssi:

" The WM9712 with which this driver
was developed with always sends GPIO status data in slot 12 which
we receive in our (PCM-) data stream. The only chance we have is to
manually skip this data in the FIQ handler."

Regards,

Markus

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From timur at tabi.org  Sun Apr 14 11:25:49 2013
From: timur at tabi.org (Timur Tabi)
Date: Sun, 14 Apr 2013 10:25:49 -0500
Subject: [PATCH v2 05/11] ASoC: fsl-ssi: Add support for imx-pcm-fiq
In-Reply-To: <20130414152016.GE27394@pengutronix.de>
References: <1365362721-3731-1-git-send-email-mpa@pengutronix.de>
 <1365362721-3731-6-git-send-email-mpa@pengutronix.de>
 <51620CEA.3010703@tabi.org> <20130414103819.GA27394@pengutronix.de>
 <516AB111.3000007@tabi.org> <20130414141015.GC27394@pengutronix.de>
 <516AC305.2000800@tabi.org> <20130414152016.GE27394@pengutronix.de>
Message-ID: <516ACA7D.60807@tabi.org>

Markus Pargmann wrote:
> I only ported the imx-ssi ac97 driver code and tested twice using DMA
> without success. But there is a good description of the problem in
> imx-ssi:
>
> " The WM9712 with which this driver
> was developed with always sends GPIO status data in slot 12 which
> we receive in our (PCM-) data stream. The only chance we have is to
> manually skip this data in the FIQ handler."

Ah, so this is a work-around for a bug, where the codec is incompatible 
with the SoC?  Mark, are you familiar with this issue?  Is there a way to 
reconfigure the codec so that it works better with the SoC?  It seems 
ridiculous to add all this code just because an incompatible codec was 
chosen for some board.

Either way, the board DTS needs to clearly state *why* we're enabling FIQ 
mode when DMA mode should work.  And the patch that adds FIQ support needs 
to say that it's for boards with broken DMA support.

-- 
Timur Tabi


From mpa at pengutronix.de  Sun Apr 14 11:44:56 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Sun, 14 Apr 2013 17:44:56 +0200
Subject: [PATCH v2 05/11] ASoC: fsl-ssi: Add support for imx-pcm-fiq
In-Reply-To: <516ACA7D.60807@tabi.org>
References: <1365362721-3731-1-git-send-email-mpa@pengutronix.de>
 <1365362721-3731-6-git-send-email-mpa@pengutronix.de>
 <51620CEA.3010703@tabi.org> <20130414103819.GA27394@pengutronix.de>
 <516AB111.3000007@tabi.org> <20130414141015.GC27394@pengutronix.de>
 <516AC305.2000800@tabi.org> <20130414152016.GE27394@pengutronix.de>
 <516ACA7D.60807@tabi.org>
Message-ID: <20130414154456.GF27394@pengutronix.de>

On Sun, Apr 14, 2013 at 10:25:49AM -0500, Timur Tabi wrote:
> Markus Pargmann wrote:
> >I only ported the imx-ssi ac97 driver code and tested twice using DMA
> >without success. But there is a good description of the problem in
> >imx-ssi:
> >
> >" The WM9712 with which this driver
> >was developed with always sends GPIO status data in slot 12 which
> >we receive in our (PCM-) data stream. The only chance we have is to
> >manually skip this data in the FIQ handler."
> 
> Ah, so this is a work-around for a bug, where the codec is
> incompatible with the SoC?  Mark, are you familiar with this issue?
> Is there a way to reconfigure the codec so that it works better with
> the SoC?  It seems ridiculous to add all this code just because an
> incompatible codec was chosen for some board.
> 
> Either way, the board DTS needs to clearly state *why* we're
> enabling FIQ mode when DMA mode should work.  And the patch that
> adds FIQ support needs to say that it's for boards with broken DMA
> support.

Okay, I will add those comments to the commit message, binding
documentation and add parts of the imx-ssi problem description to
fsl-ssi.

Regards,

Markus

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From rabin at rab.in  Sun Apr 14 12:34:51 2013
From: rabin at rab.in (Rabin Vincent)
Date: Sun, 14 Apr 2013 18:34:51 +0200
Subject: [PATCH 4/8] dmaengine: ste_dma40: Do not configure channels
 during an channel allocation
In-Reply-To: <20130412163810.GC18459@gmail.com>
References: <1365532783-27425-1-git-send-email-lee.jones@linaro.org>
 <1365532783-27425-4-git-send-email-lee.jones@linaro.org>
 <CAH+eYFBk8y28e+NwOBpvpdFa29JRXbNpFgjwNumC8GRtB-e7VQ@mail.gmail.com>
 <20130412163810.GC18459@gmail.com>
Message-ID: <CAH+eYFD4ZVrW4-UQf2YC0CmqMzWu2EtgLSeMA=3etR_u0o7faA@mail.gmail.com>

2013/4/12 Lee Jones <lee.jones at linaro.org>:
> So I need to devise another way, as this function cannot be called
> here either. Using the dmaengine API, allocating a channel and
> configuring it are to be completed using different calls. Using the
> API correctly, there is no way the driver can setup the channel
> with all of the relevant information during allocation time.
>
> The steps are as follows:
>
> dma_request_channel() - here we only allot a channel number and
>                         allocate the appropriate resources for the
>                         channel.
>
> dma_slave_config()    - this is where we're meant to configure the
>                         channel, so d40_config_write() needs to be
>                         called here, as only dma_slave_config() will
>                         carry the information required so as
>                         d40_*_cfg() can make the correct decisions.

The choice between whether a physical or a logical channel is used is
not something that is configurable via dma_slave_config().  And
d40_config_write() only needs that information, and that information is
available in dma_request_channel().  Therefore no more information
relevant to d40_config_write() will be obtained in dma_slave_config().
Hence d40_config_write() can be called in dma_request_channel().


From heiko at sntech.de  Sun Apr 14 13:01:31 2013
From: heiko at sntech.de (Heiko =?iso-8859-1?q?St=FCbner?=)
Date: Sun, 14 Apr 2013 19:01:31 +0200
Subject: [PATCH 08/30] i2c: s3c2410: make header file local
In-Reply-To: <20130414122035.GB9013@the-dreams.de>
References: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
 <1365638712-1028578-9-git-send-email-arnd@arndb.de>
 <20130414122035.GB9013@the-dreams.de>
Message-ID: <201304141901.32286.heiko@sntech.de>

Am Sonntag, 14. April 2013, 14:20:35 schrieb Wolfram Sang:
> On Thu, Apr 11, 2013 at 02:04:50AM +0200, Arnd Bergmann wrote:
> > No other file in the kernel besides i2c-s3c2410.c uses the current
> > plat/regs-iic.h, so we can simply move the header file to live in the
> > same directory as the driver, as a preparation to multiplatform builds.
> 
> What about putting the regs in the driver itself?

they already are :-) [0] and Arnd will drop this patch in his next iteration 
[1].


Heiko


[0] 
https://git.kernel.org/cgit/linux/kernel/git/wsa/linux.git/commit/?h=i2c/for-
next&id=e636602ac2613da8c1777cb42443223994be4107

[1] Message-Id: <201304121011.13028.arnd at arndb.de>


From marc.zyngier at arm.com  Sun Apr 14 13:26:25 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Sun, 14 Apr 2013 19:26:25 +0200
Subject: [PATCH] ARM: KVM: Add missing break;
In-Reply-To: <1365918945.1878.8.camel@joe-AO722>
References: <1365917315-3615-1-git-send-email-linux@prisktech.co.nz>
 <1365918945.1878.8.camel@joe-AO722>
Message-ID: <d57c84379b08873899ad0bcf95848fa7@localhost>

Hi Joe,

On Sat, 13 Apr 2013 22:55:45 -0700, Joe Perches <joe at perches.com> wrote:
> commit 3401d54696f ("KVM: ARM: Introduce KVM_ARM_SET_DEVICE_ADDR ioctl")
> added the case, but omitted adding break;

[...]

Already reported here:
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-April/160127.html

> $ grep -rP --include=*.[ch]
> "\b(\w+)\s*=[^;]+;\s*(?:case\s+\w+:|default:)\s*\1\s*="

Cool regexp! :-)
 
Cheers,

        M.
-- 
Fast, cheap, reliable. Pick two.


From pavel at denx.de  Sun Apr 14 14:07:29 2013
From: pavel at denx.de (Pavel Machek)
Date: Sun, 14 Apr 2013 20:07:29 +0200
Subject: [PATCHv3 1/3] ARM: socfpga: Enable soft reset
In-Reply-To: <1365695726-26849-1-git-send-email-dinguyen@altera.com>
References: <1365695726-26849-1-git-send-email-dinguyen@altera.com>
Message-ID: <20130414180729.GA11770@amd.pavel.ucw.cz>

On Thu 2013-04-11 10:55:24, dinguyen at altera.com wrote:
> From: Dinh Nguyen <dinguyen at altera.com>
> 
> Enable a cold or warm reset to the HW from userspace.
> 
> Also fix a few sparse errors:
> 
> warning: symbol 'sys_manager_base_addr' was not declared. Should it be static?
> warning: symbol 'rst_manager_base_addr' was not declared. Should it be static?
> 
> Signed-off-by: Dinh Nguyen <dinguyen at altera.com>

Reviewed-by: Pavel Machek <pavel at denx.de>

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


From pavel at denx.de  Sun Apr 14 14:13:07 2013
From: pavel at denx.de (Pavel Machek)
Date: Sun, 14 Apr 2013 20:13:07 +0200
Subject: [PATCHv3 2/3] ARM: socfpga: Add clock entries into device tree
In-Reply-To: <1365695726-26849-2-git-send-email-dinguyen@altera.com>
References: <1365695726-26849-1-git-send-email-dinguyen@altera.com>
 <1365695726-26849-2-git-send-email-dinguyen@altera.com>
Message-ID: <20130414181307.GB11770@amd.pavel.ucw.cz>

Hi!

Looks good.

> Signed-off-by: Dinh Nguyen <dinguyen at altera.com>

Reviewed-by: Pavel Machek <pavel at denx.de>

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


From pavel at denx.de  Sun Apr 14 14:15:10 2013
From: pavel at denx.de (Pavel Machek)
Date: Sun, 14 Apr 2013 20:15:10 +0200
Subject: [PATCHv3 3/3] ARM: socfpga: Upgrade clk driver for socfpga to
 make use of dts clock entries
In-Reply-To: <1365695726-26849-3-git-send-email-dinguyen@altera.com>
References: <1365695726-26849-1-git-send-email-dinguyen@altera.com>
 <1365695726-26849-3-git-send-email-dinguyen@altera.com>
Message-ID: <20130414181510.GC11770@amd.pavel.ucw.cz>

On Thu 2013-04-11 10:55:26, dinguyen at altera.com wrote:
> From: Dinh Nguyen <dinguyen at altera.com>
> 
> With this patch, the socfpga clk driver is able to query the clock and clock
> rates appropriately.
> 
> Signed-off-by: Dinh Nguyen <dinguyen at altera.com>

Reviewed-by: Pavel Machek <pavel at denx.de>

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


From marex at denx.de  Sun Apr 14 14:35:48 2013
From: marex at denx.de (Marek Vasut)
Date: Sun, 14 Apr 2013 20:35:48 +0200
Subject: [PATCH v2] UCB1400: Pass ucb1400-gpio data through ac97 bus
In-Reply-To: <CACRpkdZ+ku_-SBTXwwwRDh7F2TXzpgpAF3k+Ksn98BNYXximXw@mail.gmail.com>
References: <CACRpkdZ+ku_-SBTXwwwRDh7F2TXzpgpAF3k+Ksn98BNYXximXw@mail.gmail.com>
Message-ID: <1365964548-4193-1-git-send-email-marex@denx.de>

Cc: Linus Walleij <linus.walleij at linaro.org>
Cc: Jean Delvare <jdelvare at suse.de>
Cc: Samuel Ortiz <sameo at linux.intel.com>
Cc: Mark Brown <broonie at opensource.wolfsonmicro.com>
Cc: Guenter Roeck <linux at roeck-us.net>
Cc: linux-kernel <linux-kernel at vger.kernel.org>
Cc: Grant Likely <grant.likely at secretlab.ca>
Signed-off-by: Marek Vasut <marex at denx.de>
---
 drivers/gpio/gpio-ucb1400.c |   19 ++++++-------------
 drivers/mfd/ucb1400_core.c  |    5 +++++
 include/linux/ucb1400.h     |   18 ++++++------------
 3 files changed, 17 insertions(+), 25 deletions(-)

v2: Rebase patch from:
http://lists.infradead.org/pipermail/linux-arm-kernel/2010-October/028656.html

NOTE: I didn't even compile-test this, but the fix was plenty straightforward.

diff --git a/drivers/gpio/gpio-ucb1400.c b/drivers/gpio/gpio-ucb1400.c
index 26405ef..6d0feb2 100644
--- a/drivers/gpio/gpio-ucb1400.c
+++ b/drivers/gpio/gpio-ucb1400.c
@@ -12,8 +12,6 @@
 #include <linux/module.h>
 #include <linux/ucb1400.h>
 
-struct ucb1400_gpio_data *ucbdata;
-
 static int ucb1400_gpio_dir_in(struct gpio_chip *gc, unsigned off)
 {
 	struct ucb1400_gpio *gpio;
@@ -50,7 +48,7 @@ static int ucb1400_gpio_probe(struct platform_device *dev)
 	struct ucb1400_gpio *ucb = dev->dev.platform_data;
 	int err = 0;
 
-	if (!(ucbdata && ucbdata->gpio_offset)) {
+	if (!(ucb && ucb->gpio_offset)) {
 		err = -EINVAL;
 		goto err;
 	}
@@ -58,7 +56,7 @@ static int ucb1400_gpio_probe(struct platform_device *dev)
 	platform_set_drvdata(dev, ucb);
 
 	ucb->gc.label = "ucb1400_gpio";
-	ucb->gc.base = ucbdata->gpio_offset;
+	ucb->gc.base = ucb->gpio_offset;
 	ucb->gc.ngpio = 10;
 	ucb->gc.owner = THIS_MODULE;
 
@@ -72,8 +70,8 @@ static int ucb1400_gpio_probe(struct platform_device *dev)
 	if (err)
 		goto err;
 
-	if (ucbdata && ucbdata->gpio_setup)
-		err = ucbdata->gpio_setup(&dev->dev, ucb->gc.ngpio);
+	if (ucb && ucb->gpio_setup)
+		err = ucb->gpio_setup(&dev->dev, ucb->gc.ngpio);
 
 err:
 	return err;
@@ -85,8 +83,8 @@ static int ucb1400_gpio_remove(struct platform_device *dev)
 	int err = 0;
 	struct ucb1400_gpio *ucb = platform_get_drvdata(dev);
 
-	if (ucbdata && ucbdata->gpio_teardown) {
-		err = ucbdata->gpio_teardown(&dev->dev, ucb->gc.ngpio);
+	if (ucb && ucb->gpio_teardown) {
+		err = ucb->gpio_teardown(&dev->dev, ucb->gc.ngpio);
 		if (err)
 			return err;
 	}
@@ -103,11 +101,6 @@ static struct platform_driver ucb1400_gpio_driver = {
 	},
 };
 
-void __init ucb1400_gpio_set_data(struct ucb1400_gpio_data *data)
-{
-	ucbdata = data;
-}
-
 module_platform_driver(ucb1400_gpio_driver);
 
 MODULE_DESCRIPTION("Philips UCB1400 GPIO driver");
diff --git a/drivers/mfd/ucb1400_core.c b/drivers/mfd/ucb1400_core.c
index daf6952..e9031fa 100644
--- a/drivers/mfd/ucb1400_core.c
+++ b/drivers/mfd/ucb1400_core.c
@@ -75,6 +75,11 @@ static int ucb1400_core_probe(struct device *dev)
 
 	/* GPIO */
 	ucb_gpio.ac97 = ac97;
+	if (pdata) {
+		ucb_gpio.gpio_setup = pdata->gpio_setup;
+		ucb_gpio.gpio_teardown = pdata->gpio_teardown;
+		ucb_gpio.gpio_offset = pdata->gpio_offset;
+	}
 	ucb->ucb1400_gpio = platform_device_alloc("ucb1400_gpio", -1);
 	if (!ucb->ucb1400_gpio) {
 		err = -ENOMEM;
diff --git a/include/linux/ucb1400.h b/include/linux/ucb1400.h
index d21b33c..2e9ee4d 100644
--- a/include/linux/ucb1400.h
+++ b/include/linux/ucb1400.h
@@ -83,15 +83,12 @@
 #define UCB_ID			0x7e
 #define UCB_ID_1400             0x4304
 
-struct ucb1400_gpio_data {
-	int gpio_offset;
-	int (*gpio_setup)(struct device *dev, int ngpio);
-	int (*gpio_teardown)(struct device *dev, int ngpio);
-};
-
 struct ucb1400_gpio {
 	struct gpio_chip	gc;
 	struct snd_ac97		*ac97;
+	int			gpio_offset;
+	int			(*gpio_setup)(struct device *dev, int ngpio);
+	int			(*gpio_teardown)(struct device *dev, int ngpio);
 };
 
 struct ucb1400_ts {
@@ -110,6 +107,9 @@ struct ucb1400 {
 
 struct ucb1400_pdata {
 	int	irq;
+	int	gpio_offset;
+	int	(*gpio_setup)(struct device *dev, int ngpio);
+	int	(*gpio_teardown)(struct device *dev, int ngpio);
 };
 
 static inline u16 ucb1400_reg_read(struct snd_ac97 *ac97, u16 reg)
@@ -162,10 +162,4 @@ static inline void ucb1400_adc_disable(struct snd_ac97 *ac97)
 unsigned int ucb1400_adc_read(struct snd_ac97 *ac97, u16 adc_channel,
 			      int adcsync);
 
-#ifdef CONFIG_GPIO_UCB1400
-void __init ucb1400_gpio_set_data(struct ucb1400_gpio_data *data);
-#else
-static inline void ucb1400_gpio_set_data(struct ucb1400_gpio_data *data) {}
-#endif
-
 #endif
-- 
1.7.10.4



From marex at denx.de  Sun Apr 14 14:01:52 2013
From: marex at denx.de (Marek Vasut)
Date: Sun, 14 Apr 2013 20:01:52 +0200
Subject: [PATCH V2 01/12] spi/mxs: Always set LOCK_CS
In-Reply-To: <1364905195-24286-1-git-send-email-tpiepho@gmail.com>
References: <1364905195-24286-1-git-send-email-tpiepho@gmail.com>
Message-ID: <201304142001.52391.marex@denx.de>

Hello Trent,

> There are two bits which control the CS line in the CTRL0 register:
> LOCK_CS and IGNORE_CRC.  The latter would be better named DEASSERT_CS
> in SPI mode.
> 
> LOCK_CS keeps CS asserted though the entire transfer.  This should
> always be set.  The DMA code will always set it, explicitly on the
> first segment of the first transfer, and then implicitly on all the
> rest by never clearing the bit from the value read from the ctrl0
> register.
> 
> The only reason to not set LOCK_CS would be to attempt an altered
> protocol where CS pulses between each word.  Though don't get your
> hopes up if you want to do this, as the hardware doesn't appear to do
> this in any sane manner.
> 
> The code can be simplified by just setting LOCK_CS once and then not
> needing to deal with it in the PIO and DMA transfer functions.
> 
> Signed-off-by: Trent Piepho <tpiepho at gmail.com>
> Cc: Marek Vasut <marex at denx.de>
> Cc: Fabio Estevam <fabio.estevam at freescale.com>
> Cc: Shawn Guo <shawn.guo at linaro.org>

Will we see a V3 of this stuff? I don't want to see this lost.

Best regards,
Marek Vasut


From marex at denx.de  Sun Apr 14 14:09:01 2013
From: marex at denx.de (Marek Vasut)
Date: Sun, 14 Apr 2013 20:09:01 +0200
Subject: [PATCH] mxs/spi: Add SPI slave mode operation DT prop
In-Reply-To: <CA+7tXiheWUsKstWRYOR-kQoTrkDSivnYrxVuxNSNYE+rk6u79w@mail.gmail.com>
References: <1345776161-9778-1-git-send-email-marex@denx.de>
 <201303210035.52984.marex@denx.de>
 <CA+7tXiheWUsKstWRYOR-kQoTrkDSivnYrxVuxNSNYE+rk6u79w@mail.gmail.com>
Message-ID: <201304142009.01829.marex@denx.de>

Dear Trent Piepho,

> On Wed, Mar 20, 2013 at 4:35 PM, Marek Vasut <marex at denx.de> wrote:
> >> On Thu, Aug 23, 2012 at 7:42 PM, Marek Vasut
> >> 
> >> > +              - The DMA has to wait indefinitelly for the arriving
> >> > data.
> >> 
> >> Is there a reason that this must be done?  I'd guess that after the
> >> SSP is told to start a transfer in slave mode it waits for the master
> >> to assert the SSn line and begin the transfer.  If the completion
> >> times out before this happens then it makes sense it wouldn't work.
> >> But does it still not work if the SPI transfer completes before the
> >> completion timeout?  Or is this necessary because in your application
> >> there might be a long wait before the master chooses to initiate a
> >> transfer after you program it on the Linux side?
> > 
> > The problem is the SPI block in slave mode ignores SS being pulled back
> > up.
> 
> I've setup a board with a spi-gpio port looped to a spi-mxs port in
> slave mode so I can test this.  I did not need to change the DMA
> timeout to get it to work.  If the master does not send enough within
> the SSP timeout the slave transaction will timeout.  It does not seem
> to ignore SS, but rather the DMA will not finish until all the
> requested words are received, no matter how many SS pulses that
> happens to take.  For general purpose slave support it would of course
> be nice to be able to end the message when the master drops SS, but
> the SSP either doesn't support this or a different technique is
> needed.

It ignores the SS getting back up, confirmed by FSL. Sad :-(

> I've found that if PHASE = 0, the SSP expects the SS to be pulsed high
> between each word (w/ current driver, word == 8 bits).  This is
> slightly alluded to in the imx28 manual, where the PHASE = 0
> descriptions in sections 17.5.3 and 17.5.5 contain, "... in the case
> of continuous back-to-back transmissions, the SSn signal must be
> pulsed high between each data word[.]"  While for the PHASE = 1
> descriptions in sections 17.5.4 and 17.5.6 it says, "For continuous
> back-to-back transfers, the SSn pin is held low between successive
> data words[.]"

When it comes to slave mode, you can not trust anything you don't research 
yourself, sorry :-(

> One would think this is talking about master mode like the rest of the
> section, but it seems to only apply to slave mode.  In master mode one
> can easily produce a SPI signal without SS pulsed between each word
> with either phase setting.
> 
> Testing with the master TX sending 1 byte per SS asserted period:
> $ echo abcd1234ABCDwxyz | dd of=/dev/spidev4.0 bs=1
> 
> Slave RX receives the first four bytes:
> $ dd if=/dev/spidev2.0 count=1 bs=4 | hd
> [  638.673625] spidev spi2.0: Start POL 0 PHA 0
> 00000000  61 62 63 64                                       |abcd|
> 
> Trying with 4 bytes per SS assertion:
> $ echo abcd1234ABCDwxyz | dd of=/dev/spidev4.0 bs=4
> $ dd if=/dev/spidev2.0 count=1 bs=4 | hd
> 00000000  61 31 41 77                                       |a1Aw|
> 
> The slave receives the first byte of each SS assertion pulse.  If I
> change the protocol to PHASE=1, then this case works as well and I
> receive the first four bytes.  I didn't need to set POLARITY to 1,
> just phase.
> 
> $ dd if=/dev/spidev2.0 count=1 bs=16 | hd
> [  261.277000] spidev spi2.0: Start POL 0 PHA 1
> $ echo abcd1234ABCDwxyz | dd of=/dev/spidev4.0 bs=4
> 00000000  61 62 63 64 31 32 33 34  41 42 43 44 77 78 79 7a 
> |abcd1234ABCDwxyz|
> 
> The same thing happens if the bs for the master size is to 1, 2, 8, or
> 16.  Setting it to another values like 3, 5, 32 doesn't work.  Maybe
> the slave ignores extra SS pulses in the middle of a transfer, but
> will fail to complete the transfer if it doesn't get SS de-asserted at
> the end as expected?

Fabio , can you tell?

> >> another application but was never happy with it.  I imagine this is
> >> why no one has ever created a general spi slave framework for Linux.
> > 
> > SPI slave is hard because you can not anticipate the amount of data you
> > will receive. You can not anticipate when you will receive those either.
> 
> The same can be said for a serial UART or an ethernet MAC, yet those
> don't seem to be too hard.

You have a fixed-size MTU for those. But you can do gigabytes-long continuous 
transfer on generic SPI slave.

> I think the problem is that these devices
> usually have things like FIFOs, IRQ trigger levels, pools of buffer
> descriptors, etc. that are designed to handle this.  The design of
> slave mode in SPI and I2C controllers seems to be more of an
> afterthought, with none of the features one would except to deal with
> it.  Also, the slave protocol design for things like EEPROMs often
> have nanosecond scale latencies that are nearly impossible to achieve
> in a general purpose CPU running a multitasking OS.  No one would
> design a network protocol that requires an ACK packet within 10 ns of
> receiving a REQ, and expect the CPU to handle that.  Yet that can be
> expected of a SPI EEPROM.

That can be handled with the DMA ... more or less. The problem really is that 
you generally can't anticipate the length of transfer.

Note that UART will either start dropping characters if it's buffers blow or 
something, ethernet will start dropping packets. 

> However, there are applications where one can predict what the master
> will do ahead of time and don't have these problems.  In my case I
> know what and when the master will do something and can prime the SSP
> with a matching slave mode transaction before the master initiates.  I
> know I'm not the first person who has needed to do this on Linux.  So
> maybe it's worthwhile to add a limited slave support system without
> solving the problem of general purpose slave support.

You're welcome to try this, many people did before and failed :(

Best regards,
Marek Vasut


From marex at denx.de  Sun Apr 14 14:40:47 2013
From: marex at denx.de (Marek Vasut)
Date: Sun, 14 Apr 2013 20:40:47 +0200
Subject: [PATCH v2] UCB1400: Pass ucb1400-gpio data through ac97 bus
In-Reply-To: <1365964548-4193-1-git-send-email-marex@denx.de>
References: <CACRpkdZ+ku_-SBTXwwwRDh7F2TXzpgpAF3k+Ksn98BNYXximXw@mail.gmail.com>
 <1365964548-4193-1-git-send-email-marex@denx.de>
Message-ID: <201304142040.48132.marex@denx.de>

Dear Marek Vasut,

> Cc: Linus Walleij <linus.walleij at linaro.org>
> Cc: Jean Delvare <jdelvare at suse.de>
> Cc: Samuel Ortiz <sameo at linux.intel.com>
> Cc: Mark Brown <broonie at opensource.wolfsonmicro.com>
> Cc: Guenter Roeck <linux at roeck-us.net>
> Cc: linux-kernel <linux-kernel at vger.kernel.org>
> Cc: Grant Likely <grant.likely at secretlab.ca>
> Signed-off-by: Marek Vasut <marex at denx.de>
> ---
>  drivers/gpio/gpio-ucb1400.c |   19 ++++++-------------
>  drivers/mfd/ucb1400_core.c  |    5 +++++
>  include/linux/ucb1400.h     |   18 ++++++------------
>  3 files changed, 17 insertions(+), 25 deletions(-)
> 
> v2: Rebase patch from:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2010-October/028656.h
> tml
> 
> NOTE: I didn't even compile-test this, but the fix was plenty
> straightforward.

But damn, this code is ugly. I'm retrospectively-ashamed.

Best regards,
Marek Vasut


From mpfj-list at mimc.co.uk  Sun Apr 14 15:16:40 2013
From: mpfj-list at mimc.co.uk (Mark Jackson)
Date: Sun, 14 Apr 2013 20:16:40 +0100
Subject: [PATCH 0/3] Dual EMAC mode implementation of CPSW
In-Reply-To: <1360612340-9266-1-git-send-email-mugunthanvnm@ti.com>
References: <1360612340-9266-1-git-send-email-mugunthanvnm@ti.com>
Message-ID: <516B0098.4040809@mimc.co.uk>

On 11/02/13 19:52, Mugunthan V N wrote:
> This patch series implements Dual EMAC mode implementation of CPSW
> which acts as two standalone EMAC by segregating the switch using VIDs
> and port VLAN
>
> Mugunthan V N (3):
>    driver: net: ethernet: davinci_cpdma: add support for directed packet
>      and source port detection
>    driver: net: ethernet: cpsw: make cpts as pointer
>    driver: net: ethernet: cpsw: dual emac interface implementation
>
>   Documentation/devicetree/bindings/net/cpsw.txt |    2 +
>   drivers/net/ethernet/ti/cpsw.c                 |  387 +++++++++++++++++++-----
>   drivers/net/ethernet/ti/davinci_cpdma.c        |   17 +-
>   drivers/net/ethernet/ti/davinci_cpdma.h        |    4 +-
>   drivers/net/ethernet/ti/davinci_emac.c         |    6 +-
>   include/linux/platform_data/cpsw.h             |    3 +
>   6 files changed, 338 insertions(+), 81 deletions(-)

I'm trying to get dual emac mode working, but I'm only having partial 
success.  We have a custom AM335x board with dual LAN8710 PYHs, but the 
basic design is based on the BeagleBone board.

I have the following in my .dts file:-

mac: ethernet at 4a100000 {
	dual_emac = <1>;
	cpsw_emac0: slave at 4a100200 {
		dual_emac_res_vlan = <1>;
	};
	cpsw_emac1: slave at 4a100300 {
		dual_emac_res_vlan = <2>;
	};
};

When I boot my board (across nfs via eth1):-

(a) the kernel is loaded (via tftp under U-Boot)
(b) the kernel mounts the nfsroot
(c) my init scripts are run (e.g. dropbear)
(d) the shell prompt appears

So far so good, but when I then try any shell command (e.g. "ps") the 
nfs link just hangs.

Below is an extract from the boot messages:-

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 3.9.0-rc6-00186-g5b55d70-dirty 
(mpfj at mpfj-nanobone) (gcc version 4.7.2 (Buildroot 
2013.02-00154-g851ceaa) ) #19 Sun Apr 14 19:50:21 BST 2013
[    0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), 
cr=10c53c7d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
instruction cache
[    0.000000] Machine: Generic AM33XX (Flattened Device Tree), model: 
Newflow AM335x NanoBone
[    0.000000] Memory policy: ECC disabled, Data cache writeback
[    0.000000] CPU: All CPU(s) started in SVC mode.
[    0.000000] AM335X ES1.0 (neon )
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on. 
Total pages: 64768
[    0.000000] Kernel command line: root=/dev/nfs 
nfsroot=10.1.0.111:/tftpboot/nanobone/rootfs rw 
ip=10.1.0.199:10.1.0.111:10.1.0.1:255.255.0.0::eth1:off console=ttyO0,115200
...
[    1.424977] davinci_mdio 4a101000.mdio: davinci mdio revision 1.6
[    1.431443] davinci_mdio 4a101000.mdio: detected phy mask fffffffc
[    1.440939] libphy: 4a101000.mdio: probed
[    1.445266] davinci_mdio 4a101000.mdio: phy[0]: device 
4a101000.mdio:00, driver SMSC LAN8710/LAN8720
[    1.454962] davinci_mdio 4a101000.mdio: phy[1]: device 
4a101000.mdio:01, driver SMSC LAN8710/LAN8720
[    1.465059] Random MACID = a2:3f:fb:2c:47:d9
[    1.472276] cpsw: Random MACID = ae:d5:c0:c0:27:03
[    1.480588] rtc-ds1307 0-0068: setting system clock to 2013-04-14 
19:59:52 UTC (1365969592)
[    1.491543] net eth1: initializing cpsw version 1.12 (0)
[    1.516965] net eth1: phy found : id is : 0x7c0f1
[    4.595479] libphy: 4a101000.mdio:01 - Link is Up - 100/Full
[    4.625872] IP-Config: Complete:
[    4.629307]      device=eth1, hwaddr=ae:d5:c0:c0:27:03, 
ipaddr=10.1.0.199, mask=255.255.0.0, gw=10.1.0.1
[    4.639365]      host=10.1.0.199, domain=, nis-domain=(none)
[    4.645359]      bootserver=10.1.0.111, rootserver=10.1.0.111, rootpath=
[    4.674219] VFS: Mounted root (nfs filesystem) on device 0:12.
[    4.682438] devtmpfs: mounted
[    4.686042] Freeing init memory: 196K
Starting logging: OK
Initializing random number generator... done.
Starting network...
ip: RTNETLINK answers: File exists
[    5.340677] net eth0: initializing cpsw version 1.12 (0)
[    5.366463] net eth0: phy found : id is : 0x7c0f1
ip: RTNETLINK answers: File exists
ip: RTNETLINK answers: File exists
ip: RTNETLINK answers: File exists
Starting dropbear sshd: OK

Welcome to Buildroot
nanobone login: root
Password:
# ps
[   18.845266] nfs: server 10.1.0.111 not responding, still trying

At this point, I can disconnect my network cable from eth1 and connect 
to eth0, and back again which shows the PYHs appear to be detecting the 
link up/down status of each port.

[  562.675229] libphy: 4a101000.mdio:01 - Link is Down
[  567.885586] libphy: 4a101000.mdio:00 - Link is Up - 100/Full
[  571.965156] libphy: 4a101000.mdio:00 - Link is Down
[  575.014943] nfs: server 10.1.0.111 not responding, still trying
[  576.635412] libphy: 4a101000.mdio:01 - Link is Up - 100/Full
[  579.426051] nfs: server 10.1.0.111 OK

Notice that at the end, the nfs link appears to come back "ok", but the 
"ps" command never completes.

Any ideas of what's going on ?

Cheers
Mark J.


From mpfj-list at mimc.co.uk  Sun Apr 14 15:20:15 2013
From: mpfj-list at mimc.co.uk (Mark Jackson)
Date: Sun, 14 Apr 2013 20:20:15 +0100
Subject: [PATCH 3/3] driver: net: ethernet: cpsw: dual emac interface
 implementation
In-Reply-To: <1360612340-9266-4-git-send-email-mugunthanvnm@ti.com>
References: <1360612340-9266-1-git-send-email-mugunthanvnm@ti.com>
 <1360612340-9266-4-git-send-email-mugunthanvnm@ti.com>
Message-ID: <516B016F.3020308@mimc.co.uk>

On 11/02/13 19:52, Mugunthan V N wrote:
> The CPSW switch can act as Dual EMAC by segregating the switch ports
> using VLAN and port VLAN as per the TRM description in
> 14.3.2.10.2 Dual Mac Mode
>
> Following CPSW components will be common for both the interfaces.
> * Interrupt source is common for both eth interfaces
> * Interrupt pacing is common for both interfaces
> * Hardware statistics is common for all the ports
> * CPDMA is common for both eth interface
> * CPTS is common for both the interface and it should not be enabled on
>    both the interface as timestamping information doesn't contain port
>    information.
>
> Constrains
> * Reserved VID of One port should not be used in other interface which will
>    enable switching functionality
> * Same VID must not be used in both the interface which will enable switching
>    functionality
>
> Signed-off-by: Mugunthan V N <mugunthanvnm at ti.com>
> ---
>   Documentation/devicetree/bindings/net/cpsw.txt |    2 +
>   drivers/net/ethernet/ti/cpsw.c                 |  335 ++++++++++++++++++++----
>   include/linux/platform_data/cpsw.h             |    3 +
>   3 files changed, 288 insertions(+), 52 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/net/cpsw.txt b/Documentation/devicetree/bindings/net/cpsw.txt
> index 6ddd028..ecfdf75 100644
> --- a/Documentation/devicetree/bindings/net/cpsw.txt
> +++ b/Documentation/devicetree/bindings/net/cpsw.txt
> @@ -24,6 +24,8 @@ Required properties:
>   Optional properties:
>   - ti,hwmods		: Must be "cpgmac0"
>   - no_bd_ram		: Must be 0 or 1
> +- dual_emac		: Specifies Switch to act as Dual EMAC
> +- dual_emac_res_vlan	: Specifies VID to be used to segregate the ports
>
>   Note: "ti,hwmods" field is used to fetch the base address and irq
>   resources from TI, omap hwmod data base during device registration.
> diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
> index 4b964bb..4ceed6e 100644
> --- a/drivers/net/ethernet/ti/cpsw.c
> +++ b/drivers/net/ethernet/ti/cpsw.c

<snip>

> @@ -1237,6 +1372,18 @@ static int cpsw_probe_dt(struct cpsw_platform_data *data,
>   		if (mac_addr)
>   			memcpy(slave_data->mac_addr, mac_addr, ETH_ALEN);
>
> +		if (data->dual_emac) {
> +			if (of_property_read_u32(node, "dual_emac_res_vlan",
> +						 &prop)) {

Shouldn't this be:-

	if (of_property_read_u32(slave_node, "dual_emac_res_vlan",
                                  ^^^^^^^^^^

... so we pick each VLAN id from the individual slaves ?

Regards
Mark J.


From daniel.lezcano at linaro.org  Sun Apr 14 16:22:54 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Sun, 14 Apr 2013 22:22:54 +0200
Subject: [V3 patch 17/19] ARM: kirkwood: cpuidle: use init/exit common
 routine
In-Reply-To: <20130414151429.GF5061@lunn.ch>
References: <1365770165-27096-1-git-send-email-daniel.lezcano@linaro.org>
 <1365770165-27096-18-git-send-email-daniel.lezcano@linaro.org>
 <20130414151429.GF5061@lunn.ch>
Message-ID: <516B101E.3040807@linaro.org>

On 04/14/2013 05:14 PM, Andrew Lunn wrote:
> On Fri, Apr 12, 2013 at 02:36:03PM +0200, Daniel Lezcano wrote:
>> Remove the duplicated code and use the cpuidle common code for initialization.
>>
>> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
>> ---

[ ... ]

> Tested-by: Andrew Lunn <andrew at lunn.ch>

Thanks Andrew for testing.

  -- Daniel



-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From linus.walleij at linaro.org  Sun Apr 14 16:53:05 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Sun, 14 Apr 2013 22:53:05 +0200
Subject: [PATCH 3/5] gpio/omap: Add DT support to GPIO driver
In-Reply-To: <CAAwP0s0e2x33jZQhFRY+Hoo61SFqYKRgWk=1mL2+DNxSDJHz+A@mail.gmail.com>
References: <1329321854-24490-1-git-send-email-b-cousson@ti.com>
 <4F47AD08.4030504@ti.com>
 <CAAwP0s0cB368R2mtbJpTZJreR-5GSRLfxC+8DJLo5nw3_OwBuA@mail.gmail.com>
 <512D39DA.7020306@ti.com> <512D3AB1.1080202@wwwdotorg.org>
 <512D3EC2.6050408@ti.com> <20130302200524.D230F3E1571@localhost>
 <51391F41.5000303@ti.com>
 <CAAwP0s1CFRO-rf==p5sYs1n0gigMif7wuT8Yv0N_iLUDMrtcOg@mail.gmail.com>
 <CACRpkdYHj-rEF3Rk_CWnmmMw_Amr7m8SgQ=-2zsDYuLeuu3azw@mail.gmail.com>
 <514C79E1.4090106@wwwdotorg.org> <514CE0AB.6060207@ti.com>
 <CACRpkdZmv-rAoKSQYpkHHSMzKJOn5TixVW_P3=m7ZNagBYCUPw@mail.gmail.com>
 <515319D5.20105@wwwdotorg.org>
 <CACRpkdYXVLgCz1Tyu-Ls2V2OTc4R3cGNJhfQJB6Hiz_K9dkZYQ@mail.gmail.com>
 <5155C902.7080207@wwwdotorg.org>
 <CACRpkdYbs4-uudpRUY8e+7icYYkZrfM0kReP3pLL5DMiURJ4dg@mail.gmail.com>
 <5165CB9D.1090202@wwwdotorg.org>
 <CACRpkdYirFNqmGhA4K9CL4ve4NYhs8Rd3SFt1iwW9vHBkrcz8g@mail.gmail.com>
 <51671D7B.5060303@wwwdotorg.org>
 <CACRpkdbf32Ef77GmXk9id9+RRjcDRTr7S+F4nznoeZU8y=BT_Q@mail.gmail.com>
 <51673D70.3010503@wwwdotorg.org>
 <CAAwP0s0e2x33jZQhFRY+Hoo61SFqYKRgWk=1mL2+DNxSDJHz+A@mail.gmail.com>
Message-ID: <CACRpkda4h+qXTvsirPAS7E7sjXhMLE62q=VDy53W8UchsYjbNg@mail.gmail.com>

On Sun, Apr 14, 2013 at 3:35 AM, Javier Martinez Canillas
<martinez.javier at gmail.com> wrote:

> Is the following inlined patch [1] what you were thinking that would
> be the right approach?

This looks sort of OK, but I'm still struggling with the question of
what we could do to help other implementations facing the same issue.

This is a pretty hard design pattern to properly replicate in every such
driver is it not?

Hmmmm

Yours,
Linus Walleij


From nm at ti.com  Sun Apr 14 17:19:17 2013
From: nm at ti.com (Nishanth Menon)
Date: Sun, 14 Apr 2013 16:19:17 -0500
Subject: [PATCH V4 1/6] clk: OMAP: introduce device tree binding to
 kernel clock data
In-Reply-To: <20130413172210.GM10155@atomide.com>
References: <1365807278-554-1-git-send-email-nm@ti.com>
 <1365807278-554-2-git-send-email-nm@ti.com>
 <20130412233142.GE10155@atomide.com> <20130412233900.GA1599@kahuna>
 <20130413172210.GM10155@atomide.com>
Message-ID: <20130414211917.GA3275@snafu>

On 10:22-20130413, Tony Lindgren wrote:
> * Nishanth Menon <nm at ti.com> [130412 16:43]:
> > Thanks for checking up. Fixed all of them below, will post part of
> > series again, only if I need to address further comments in other
> > patches..
> 
> Thanks it seems that the other ones are ready to go, just one
> more comment below.
> 
[...]
> > +static struct clk *omap_clk_src_get(struct of_phandle_args *clkspec, void *data)
> > +{
> > +	struct clk *clk;
> > +	char clk_name[32];
> > +	struct device_node *np = clkspec->np;
> > +
> > +	snprintf(clk_name, 32, "%s_ck", np->name);
> > +	clk = clk_get(NULL, clk_name);
> > +	if (IS_ERR(clk)) {
> > +		pr_err("%s: could not get clock %s(%ld)\n", __func__,
> > +		       clk_name, PTR_ERR(clk));
> > +		goto out;
> > +	}
> > +	clk_put(clk);
> 
> It seems that clk_put() is actually wrong here. That's because
> of_clk_get() should boild down to just the look up of the clock 
> and then clk_get() on it, so no double clk_get() is done in this
> case. Once the consumer driver is done, it will just call clk_put()
> on it.
Yep - updated version below.
>From d0bf3fce235cff46feac7f5ef1a40e2fa0f2aa12 Mon Sep 17 00:00:00 2001
From: Nishanth Menon <nm at ti.com>
Date: Tue, 9 Apr 2013 19:26:40 -0500
Subject: [PATCH V5.1 1/6] clk: OMAP: introduce device tree binding to kernel clock
 data

OMAP clock data is located in arch/arm/mach-omap2/cclockXYZ_data.c.
However, this presents an obstacle for using these clock nodes in
Device Tree definitions. This is especially true for board specific
clocks initially. The fixed clocks are currently found via clock
aliases table. There are many possible approaches to this problem as
discussed in the following thread:
http://marc.info/?t=136370325600009&r=1&w=2.
Highlights of the options:
a) device specific clk_add_alias:
   cons: driver handling required
b) using an generic clk node and indexing to reach the clock required.
   This is similar in approach taken by tegra and few other platforms.
   Example usage: clock = <&clk 5>;
   cons: potential to have mismatches in indexed table and associated
   dtb data. In addition, managing continued documentation in bindings
   as clock indexing increases. Even though readability angle could be
   improved by using preprocessing of DT using macros, indexed
   approach is inherently risky from cases like the following:
   clk indexes in kernel:
   1 - mpu_dpll
   2 - aux_clk1
   3 - core_clk
   DT entry for peripheral X uses <&clk 2> to reach aux_clk1. Now, let's
   say kernel updates indices to:
   1 - mpu_dpll
   2 - per_dpll
   3 - aux_clk1
   4 - core_clk
   using the old dtb(or dts missing an update), on new kernel which
   has updated indices will result in per_dpll now controlled for
   peripheral X without warning or any potential error detection.

   Even though we could claim this is user error, such errors are hard
   to track down and fix.

An alternate approach introduced here is to introduce device tree
bindings corresponding to the clock nodes required in DT definition
for SoC which automatically maps back to the definitions in
cclockXYZ_data.c.

The driver introduced here to do this mapping will eventually be the
place where the clock handling will migrate to. We need to consider
this angle as well so that the solution will be an valid transition
point for moving the clock data out of kernel image (into device tree
or firmware load etc..).

Overall strategy introduced here is simple: a clock node described in
device tree blob is used to identify the exact clock provided in the
SoC specific data. This is then linked back using of_clk_add_provider
to the device node to be accessible by of_clk_get.

Based on discussion contributions from Roger Quadros, Grygorii Strashko
and others.

Cc: Kevin Hilman <khilman at deeprootsystems.com>
Cc: Mike Turquette <mturquette at linaro.org>
Cc: Paul Walmsley <paul at pwsan.com>
[tony at atomide.com: co-developed]
Signed-off-by: Tony Lindgren <tony at atomide.com>
Signed-off-by: Nishanth Menon <nm at ti.com>
---
 .../devicetree/bindings/clock/omap-clock.txt       |   40 +++++++++
 drivers/clk/Makefile                               |    1 +
 drivers/clk/omap/Makefile                          |    1 +
 drivers/clk/omap/clk.c                             |   91 ++++++++++++++++++++
 4 files changed, 133 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/omap-clock.txt
 create mode 100644 drivers/clk/omap/Makefile
 create mode 100644 drivers/clk/omap/clk.c

diff --git a/Documentation/devicetree/bindings/clock/omap-clock.txt b/Documentation/devicetree/bindings/clock/omap-clock.txt
new file mode 100644
index 0000000..047c1e7
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/omap-clock.txt
@@ -0,0 +1,40 @@
+Device Tree Clock bindings for Texas Instrument's OMAP compatible platforms
+
+This binding is an initial minimal binding that may be enhanced as part of
+transitioning OMAP clock data out of kernel image.
+
+This binding uses the common clock binding[1].
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties:
+- compatible : shall be "ti,omap-clock"
+- #clock-cells : from common clock binding; shall be set to 0.
+NOTE:
+node name should map to clock database in arch/arm/mach-omap2/cclock<SoC>_data.c
+Since all clocks are described with _ck, the node name is optimized to drop the
+usage of _ck. For example, a clock called dpll1_ck will be defined as dpll1.
+
+Example #1: describing clock node for CPU on OMAP34xx platform:
+Ref: arch/arm/mach-omap2/cclock3xxx_data.c
+describes the CPU clock to be as follows
+	CLK(NULL,	"dpll1_ck",	&dpll1_ck,	CK_3XXX),
+Corresponding binding will be:
+	dpll1: dpll1 {
+		#clock-cells = <0>;
+		compatible = "ti,omap-clock";
+	};
+And it's usage will be:
+		clocks = <&dpll1>;
+
+Example #2: describing clock node for auxilary clock #3 on OMAP443x platform:
+Ref: arch/arm/mach-omap2/cclock44xx_data.c
+describes the auxclk3 clock to be as follows:
+	CLK(NULL,	"auxclk3_ck",	&auxclk3_ck,	CK_443X),
+Corresponding binding will be:
+	auxclk3: auxclk3 {
+		#clock-cells = <0>;
+		compatible = "ti,omap-clock";
+	};
+And it's usage will be:
+	clocks = <&auxclk3>;
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index e7f7fe9..dbf9b13 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -29,6 +29,7 @@ obj-$(CONFIG_ARCH_U8500)	+= ux500/
 obj-$(CONFIG_ARCH_VT8500)	+= clk-vt8500.o
 obj-$(CONFIG_ARCH_ZYNQ)		+= clk-zynq.o
 obj-$(CONFIG_ARCH_TEGRA)	+= tegra/
+obj-$(CONFIG_ARCH_OMAP)		+= omap/
 
 obj-$(CONFIG_X86)		+= x86/
 
diff --git a/drivers/clk/omap/Makefile b/drivers/clk/omap/Makefile
new file mode 100644
index 0000000..8195931
--- /dev/null
+++ b/drivers/clk/omap/Makefile
@@ -0,0 +1 @@
+obj-y					+= clk.o
diff --git a/drivers/clk/omap/clk.c b/drivers/clk/omap/clk.c
new file mode 100644
index 0000000..5a3c6d9
--- /dev/null
+++ b/drivers/clk/omap/clk.c
@@ -0,0 +1,91 @@
+/*
+ * Texas Instruments OMAP Clock driver
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ *	Nishanth Menon <nm at ti.com>
+ *	Tony Lindgren <tony at atomide.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.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/clkdev.h>
+#include <linux/clk-provider.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include <linux/string.h>
+
+static const struct of_device_id omap_clk_of_match[] = {
+	{.compatible = "ti,omap-clock",},
+	{},
+};
+
+/**
+ * omap_clk_src_get() - Get OMAP clock from node name when needed
+ * @clkspec:	clkspec argument
+ * @data:	unused
+ *
+ * REVISIT: We assume the following:
+ * 1. omap clock names end with _ck
+ * 2. omap clock names are under 32 characters in length
+ */
+static struct clk *omap_clk_src_get(struct of_phandle_args *clkspec, void *data)
+{
+	struct clk *clk;
+	char clk_name[32];
+	struct device_node *np = clkspec->np;
+
+	snprintf(clk_name, 32, "%s_ck", np->name);
+	clk = clk_get(NULL, clk_name);
+	if (IS_ERR(clk))
+		pr_err("%s: could not get clock %s(%ld)\n", __func__,
+		       clk_name, PTR_ERR(clk));
+
+	return clk;
+}
+
+/**
+ * omap_clk_probe() - create link from DT definition to clock data
+ * @pdev:	device node
+ *
+ * NOTE: we look up the clock lazily when the consumer driver does
+ * of_clk_get() and initialize a NULL clock here.
+ */
+static int omap_clk_probe(struct platform_device *pdev)
+{
+	int res;
+	struct device_node *np = pdev->dev.of_node;
+
+	/* This allows the driver to of_clk_get() */
+	res = of_clk_add_provider(np, omap_clk_src_get, NULL);
+	if (res)
+		dev_err(&pdev->dev, "could not add provider(%d)\n", res);
+
+	return res;
+}
+
+static struct platform_driver omap_clk_driver = {
+	.probe = omap_clk_probe,
+	.driver = {
+		   .name = "omap_clk",
+		   .of_match_table = of_match_ptr(omap_clk_of_match),
+		   },
+};
+
+static int __init omap_clk_init(void)
+{
+	return platform_driver_register(&omap_clk_driver);
+}
+arch_initcall(omap_clk_init);
+
+MODULE_DESCRIPTION("OMAP Clock driver");
+MODULE_AUTHOR("Texas Instruments Inc.");
+MODULE_LICENSE("GPL v2");
-- 
1.7.9.5


-- 
Regards,
Nishanth Menon


From ben at decadent.org.uk  Sun Apr 14 23:07:14 2013
From: ben at decadent.org.uk (Ben Hutchings)
Date: Mon, 15 Apr 2013 04:07:14 +0100
Subject: [PATCH 0/5 v2] mv643xx_eth: device tree bindings
In-Reply-To: <20130413190037.GY28693@titan.lakedaemon.net>
References: <1365071235-11611-1-git-send-email-florian@openwrt.org>
 <20130411165303.GI28693@titan.lakedaemon.net>
 <20130413172126.6cca0809@skate>
 <20130413190037.GY28693@titan.lakedaemon.net>
Message-ID: <1365995234.3566.17.camel@deadeye.wl.decadent.org.uk>

On Sat, 2013-04-13 at 15:00 -0400, Jason Cooper wrote:
> On Sat, Apr 13, 2013 at 05:21:26PM +0200, Thomas Petazzoni wrote:
> > Dear Jason Cooper,
> > 
> > On Thu, 11 Apr 2013 12:53:03 -0400, Jason Cooper wrote:
> > 
> > > With this and Thomas' pci series, we will have Kirkwood fully
> > > converted to devicetree, can begin removing board files, and finally
> > > begin migrating everything over to mach-mvebu/.  This will lead to
> > > the removal of five directories under arch/arm/ (plat-orion,
> > > mach-kirkwood, mach-orion5x, mach-dove, and mach-mv78xx0).
> > 
> > No, we can't remove mach-orion5x and mach-mv78xx0 for now, they have
> > not been converted at all in terms of gpio/pinmux support. I've started
> > writing some pinmux code for orion5x but it's not ready.
[...]
> Also, I have a feeling that not all legacy boards will get converted
> over.  If there is no interest or no way to test, certains boards may
> get deprecated.

Debian supports many Kirkwood and Orion 5x systems.  A call for testing
on the debian-arm at lists.debian.org list might be worthwhile.

I would be very glad to see kirkwood, orion5x and mv78xx0 merged - we
build natively and this takes about 8 hours for each configuration.

Ben.

-- 
Ben Hutchings
The first rule of tautology club is the first rule of tautology club.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130415/2648cd5c/attachment.sig>

From olof at lixom.net  Sun Apr 14 23:20:55 2013
From: olof at lixom.net (Olof Johansson)
Date: Sun, 14 Apr 2013 20:20:55 -0700
Subject: [PATCHv3 1/3] ARM: socfpga: Enable soft reset
In-Reply-To: <20130414180729.GA11770@amd.pavel.ucw.cz>
References: <1365695726-26849-1-git-send-email-dinguyen@altera.com>
 <20130414180729.GA11770@amd.pavel.ucw.cz>
Message-ID: <20130415032055.GA10949@quad.lixom.net>

On Sun, Apr 14, 2013 at 08:07:29PM +0200, Pavel Machek wrote:
> On Thu 2013-04-11 10:55:24, dinguyen at altera.com wrote:
> > From: Dinh Nguyen <dinguyen at altera.com>
> > 
> > Enable a cold or warm reset to the HW from userspace.
> > 
> > Also fix a few sparse errors:
> > 
> > warning: symbol 'sys_manager_base_addr' was not declared. Should it be static?
> > warning: symbol 'rst_manager_base_addr' was not declared. Should it be static?
> > 
> > Signed-off-by: Dinh Nguyen <dinguyen at altera.com>
> 
> Reviewed-by: Pavel Machek <pavel at denx.de>

Applied 1-3 to next/soc in arm-soc.

Thanks!

-Olof


From olof at lixom.net  Sun Apr 14 23:33:24 2013
From: olof at lixom.net (Olof Johansson)
Date: Sun, 14 Apr 2013 20:33:24 -0700
Subject: [PATCH 1/2] GPIO: clps711x: Rewrite driver for using generic
 GPIO code
In-Reply-To: <1365826900-30136-1-git-send-email-shc_work@mail.ru>
References: <1365826900-30136-1-git-send-email-shc_work@mail.ru>
Message-ID: <20130415033324.GB10949@quad.lixom.net>

Hi,

On Sat, Apr 13, 2013 at 08:21:39AM +0400, Alexander Shiyan wrote:
> This patch provides rewritten driver for CLPS711X GPIO which uses
> generic GPIO code.
> 
> Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
> ---
>  arch/arm/configs/clps711x_defconfig            |   1 +
>  arch/arm/mach-clps711x/Makefile                |   5 +-
>  arch/arm/mach-clps711x/board-autcpu12.c        |   2 +
>  arch/arm/mach-clps711x/board-cdb89712.c        |   2 +
>  arch/arm/mach-clps711x/board-edb7211.c         |   7 +
>  arch/arm/mach-clps711x/board-p720t.c           |  10 +-
>  arch/arm/mach-clps711x/devices.c               |  56 ++++++
>  arch/arm/mach-clps711x/devices.h               |  12 ++
>  arch/arm/mach-clps711x/include/mach/clps711x.h |  23 +--
>  drivers/gpio/Kconfig                           |   5 +-
>  drivers/gpio/gpio-clps711x.c                   | 228 +++++++------------------
>  11 files changed, 164 insertions(+), 187 deletions(-)
>  create mode 100644 arch/arm/mach-clps711x/devices.c
>  create mode 100644 arch/arm/mach-clps711x/devices.h

It would be nice to see this split up in a short series of patches instead,
each patch doing one thing. For example, I'm not sure enabling the GPIO driver
in the defconfig really belongs in the rewrite patch, for example.

> diff --git a/arch/arm/mach-clps711x/board-cdb89712.c b/arch/arm/mach-clps711x/board-cdb89712.c
> index baab7da..a80ae57 100644
> --- a/arch/arm/mach-clps711x/board-cdb89712.c
> +++ b/arch/arm/mach-clps711x/board-cdb89712.c
> @@ -39,6 +39,7 @@
>  #include <asm/mach/map.h>
>  
>  #include "common.h"
> +#include "devices.h"
>  
>  #define CDB89712_CS8900_BASE	(CS2_PHYS_BASE + 0x300)
>  #define CDB89712_CS8900_IRQ	(IRQ_EINT3)
> @@ -127,6 +128,7 @@ static struct platform_device cdb89712_sram_pdev __initdata = {
>  
>  static void __init cdb89712_init(void)
>  {
> +	clps711x_devices_init();
>  	platform_device_register(&cdb89712_flash_pdev);
>  	platform_device_register(&cdb89712_bootrom_pdev);
>  	platform_device_register(&cdb89712_sram_pdev);
> diff --git a/arch/arm/mach-clps711x/board-edb7211.c b/arch/arm/mach-clps711x/board-edb7211.c
> index 5f928e9..e1c5573 100644
> --- a/arch/arm/mach-clps711x/board-edb7211.c
> +++ b/arch/arm/mach-clps711x/board-edb7211.c
> @@ -29,6 +29,7 @@
>  #include <mach/hardware.h>
>  
>  #include "common.h"
> +#include "devices.h"
>  
>  #define VIDEORAM_SIZE		SZ_128K
>  
> @@ -151,6 +152,11 @@ fixup_edb7211(struct tag *tags, char **cmdline, struct meminfo *mi)
>  
>  static void __init edb7211_init(void)
>  {
> +	clps711x_devices_init();
> +}
> +
> +static void __init edb7211_init_late(void)
> +{

It'd be good for people reading the changelog in the future to see why you
chose to split this up among two initcalls now.

> @@ -199,6 +200,11 @@ static struct gpio_led_platform_data p720t_gpio_led_pdata __initdata = {
>  
>  static void __init p720t_init(void)
>  {
> +	clps711x_devices_init();
> +}
> +
> +static void __init p720t_init_late(void)
> +{
>  	platform_device_register(&p720t_nand_pdev);
>  	platform_device_register_data(&platform_bus, "platform-lcd", 0,
>  				      &p720t_lcd_power_pdata,
> @@ -207,10 +213,6 @@ static void __init p720t_init(void)
>  				      &p720t_lcd_backlight_pdata,
>  				      sizeof(p720t_lcd_backlight_pdata));
>  	platform_device_register_simple("video-clps711x", 0, NULL, 0);
> -}
> -
> -static void __init p720t_init_late(void)
> -{
>  	platform_device_register_data(&platform_bus, "leds-gpio", 0,
>  				      &p720t_gpio_led_pdata,
>  				      sizeof(p720t_gpio_led_pdata));

Same here.

> diff --git a/arch/arm/mach-clps711x/devices.c b/arch/arm/mach-clps711x/devices.c
> new file mode 100644
> index 0000000..100ddec
> --- /dev/null
> +++ b/arch/arm/mach-clps711x/devices.c
> @@ -0,0 +1,56 @@
> +/*
> + *  CLPS711X common devices definitions
> + *
> + *  Copyright (C) 2013 Alexander Shiyan <shc_work at mail.ru>
> + *
> + * 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.
> + */
> +
> +#include <linux/io.h>
> +#include <linux/sizes.h>
> +#include <linux/platform_device.h>
> +
> +#include <mach/hardware.h>
> +
> +static void __init clps711x_add_gpio(void)
> +{
> +	const struct resource clps711x_gpio0_res[] = {
> +		DEFINE_RES_MEM(PADR, SZ_1),
> +		DEFINE_RES_MEM(PADDR, SZ_1),
> +	};
> +	const struct resource clps711x_gpio1_res[] = {
> +		DEFINE_RES_MEM(PBDR, SZ_1),
> +		DEFINE_RES_MEM(PBDDR, SZ_1),
> +	};
> +	const struct resource clps711x_gpio2_res[] = {
> +		DEFINE_RES_MEM(PCDR, SZ_1),
> +		DEFINE_RES_MEM(PCDDR, SZ_1),
> +	};
> +	const struct resource clps711x_gpio3_res[] = {
> +		DEFINE_RES_MEM(PDDR, SZ_1),
> +		DEFINE_RES_MEM(PDDDR, SZ_1),
> +	};
> +	const struct resource clps711x_gpio4_res[] = {
> +		DEFINE_RES_MEM(PEDR, SZ_1),
> +		DEFINE_RES_MEM(PEDDR, SZ_1),
> +	};

It's common to have the resources as static globals in the file instead of
local const variables, so please move them out to stay common with other
platforms.

> +	platform_device_register_simple("clps711x-gpio", 0, clps711x_gpio0_res,
> +					ARRAY_SIZE(clps711x_gpio0_res));
> +	platform_device_register_simple("clps711x-gpio", 1, clps711x_gpio1_res,
> +					ARRAY_SIZE(clps711x_gpio1_res));
> +	platform_device_register_simple("clps711x-gpio", 2, clps711x_gpio2_res,
> +					ARRAY_SIZE(clps711x_gpio2_res));
> +	platform_device_register_simple("clps711x-gpio", 3, clps711x_gpio3_res,
> +					ARRAY_SIZE(clps711x_gpio3_res));
> +	platform_device_register_simple("clps711x-gpio", 4, clps711x_gpio4_res,
> +					ARRAY_SIZE(clps711x_gpio4_res));
> +}
> +
> +void __init clps711x_devices_init(void)
> +{
> +	clps711x_add_gpio();
> +}
> diff --git a/arch/arm/mach-clps711x/devices.h b/arch/arm/mach-clps711x/devices.h
> new file mode 100644
> index 0000000..a5efc17
> --- /dev/null
> +++ b/arch/arm/mach-clps711x/devices.h
> @@ -0,0 +1,12 @@
> +/*
> + *  CLPS711X common devices definitions
> + *
> + *  Copyright (C) 2013 Alexander Shiyan <shc_work at mail.ru>
> + *
> + * 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.
> + */
> +
> +void clps711x_devices_init(void);
> diff --git a/arch/arm/mach-clps711x/include/mach/clps711x.h b/arch/arm/mach-clps711x/include/mach/clps711x.h
> index 01d1b95..9279f0a 100644
> --- a/arch/arm/mach-clps711x/include/mach/clps711x.h
> +++ b/arch/arm/mach-clps711x/include/mach/clps711x.h
> @@ -23,16 +23,19 @@
>  
>  #define CLPS711X_PHYS_BASE	(0x80000000)
>  
> -#define PADR		(0x0000)
> -#define PBDR		(0x0001)
> -#define PCDR		(0x0002)
> -#define PDDR		(0x0003)
> -#define PADDR		(0x0040)
> -#define PBDDR		(0x0041)
> -#define PCDDR		(0x0042)
> -#define PDDDR		(0x0043)
> -#define PEDR		(0x0083)
> -#define PEDDR		(0x00c3)
> +#define CLPS711X_REGS(x)	(CLPS711X_PHYS_BASE + (x))
> +
> +#define PADR		CLPS711X_REGS(0x0000)
> +#define PBDR		CLPS711X_REGS(0x0001)
> +#define PCDR		CLPS711X_REGS(0x0002)
> +#define PDDR		CLPS711X_REGS(0x0003)
> +#define PADDR		CLPS711X_REGS(0x0040)
> +#define PBDDR		CLPS711X_REGS(0x0041)
> +#define PCDDR		CLPS711X_REGS(0x0042)
> +#define PDDDR		CLPS711X_REGS(0x0043)
> +#define PEDR		CLPS711X_REGS(0x0083)
> +#define PEDDR		CLPS711X_REGS(0x00c3)
> +

Are these needed in a shared include file, or could they just be pushed out in
the one driver that uses them? There's been a lot of churn moving mach includes
out to drivers on multiplatform enabled platforms, it'd be nice to avoid adding
more dependencies on it on legacy platforms that haven't yet been enabled (or
even if they never will be, it still doesn't hurt).

> diff --git a/drivers/gpio/gpio-clps711x.c b/drivers/gpio/gpio-clps711x.c
> index ce63b75..3c71815 100644
> --- a/drivers/gpio/gpio-clps711x.c
> +++ b/drivers/gpio/gpio-clps711x.c
> @@ -1,7 +1,7 @@
>  /*
>   *  CLPS711X GPIO driver
>   *
> - *  Copyright (C) 2012 Alexander Shiyan <shc_work at mail.ru>
> + *  Copyright (C) 2013 Alexander Shiyan <shc_work at mail.ru>

2012-2013?

>   *
>   * 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
> @@ -9,191 +9,83 @@
>   * (at your option) any later version.
>   */
>  
> -#include <linux/io.h>
> -#include <linux/slab.h>
>  #include <linux/gpio.h>
>  #include <linux/module.h>
> -#include <linux/spinlock.h>
> +#include <linux/basic_mmio_gpio.h>
>  #include <linux/platform_device.h>
>  
> -#include <mach/hardware.h>
> -
> -#define CLPS711X_GPIO_PORTS	5
> -#define CLPS711X_GPIO_NAME	"gpio-clps711x"
> -
> -struct clps711x_gpio {
> -	struct gpio_chip	chip[CLPS711X_GPIO_PORTS];
> -	spinlock_t		lock;
> -};
> -
> -static void __iomem *clps711x_ports[] = {
> -	CLPS711X_VIRT_BASE + PADR,
> -	CLPS711X_VIRT_BASE + PBDR,
> -	CLPS711X_VIRT_BASE + PCDR,
> -	CLPS711X_VIRT_BASE + PDDR,
> -	CLPS711X_VIRT_BASE + PEDR,
> -};
> -
> -static void __iomem *clps711x_pdirs[] = {
> -	CLPS711X_VIRT_BASE + PADDR,
> -	CLPS711X_VIRT_BASE + PBDDR,
> -	CLPS711X_VIRT_BASE + PCDDR,
> -	CLPS711X_VIRT_BASE + PDDDR,
> -	CLPS711X_VIRT_BASE + PEDDR,
> -};
> -
> -#define clps711x_port(x)	clps711x_ports[x->base / 8]
> -#define clps711x_pdir(x)	clps711x_pdirs[x->base / 8]
> -
> -static int gpio_clps711x_get(struct gpio_chip *chip, unsigned offset)
> +static int clps711x_gpio_probe(struct platform_device *pdev)
>  {
> -	return !!(readb(clps711x_port(chip)) & (1 << offset));
> -}
> +	void __iomem *dat, *dir;
> +	struct bgpio_chip *bgc;
> +	struct resource *res;
> +	int err, id = pdev->id;
>  
> -static void gpio_clps711x_set(struct gpio_chip *chip, unsigned offset,
> -			      int value)
> -{
> -	int tmp;
> -	unsigned long flags;
> -	struct clps711x_gpio *gpio = dev_get_drvdata(chip->dev);
> +	if ((id < 0) || (id > 4))
> +		return -ENODEV;
>  
> -	spin_lock_irqsave(&gpio->lock, flags);
> -	tmp = readb(clps711x_port(chip)) & ~(1 << offset);
> -	if (value)
> -		tmp |= 1 << offset;
> -	writeb(tmp, clps711x_port(chip));
> -	spin_unlock_irqrestore(&gpio->lock, flags);
> -}
> -
> -static int gpio_clps711x_dir_in(struct gpio_chip *chip, unsigned offset)
> -{
> -	int tmp;
> -	unsigned long flags;
> -	struct clps711x_gpio *gpio = dev_get_drvdata(chip->dev);
> -
> -	spin_lock_irqsave(&gpio->lock, flags);
> -	tmp = readb(clps711x_pdir(chip)) & ~(1 << offset);
> -	writeb(tmp, clps711x_pdir(chip));
> -	spin_unlock_irqrestore(&gpio->lock, flags);
> -
> -	return 0;
> -}
> -
> -static int gpio_clps711x_dir_out(struct gpio_chip *chip, unsigned offset,
> -				 int value)
> -{
> -	int tmp;
> -	unsigned long flags;
> -	struct clps711x_gpio *gpio = dev_get_drvdata(chip->dev);
> -
> -	spin_lock_irqsave(&gpio->lock, flags);
> -	tmp = readb(clps711x_pdir(chip)) | (1 << offset);
> -	writeb(tmp, clps711x_pdir(chip));
> -	tmp = readb(clps711x_port(chip)) & ~(1 << offset);
> -	if (value)
> -		tmp |= 1 << offset;
> -	writeb(tmp, clps711x_port(chip));
> -	spin_unlock_irqrestore(&gpio->lock, flags);
> +	bgc = devm_kzalloc(&pdev->dev, sizeof(*bgc), GFP_KERNEL);
> +	if (!bgc)
> +		return -ENOMEM;
>  
> -	return 0;
> -}
> +	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +	dat = devm_request_and_ioremap(&pdev->dev, res);
> +	if (!dat)
> +		return -ENXIO;
> +
> +	res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> +	dir = devm_request_and_ioremap(&pdev->dev, res);
> +	if (!dir)
> +		return -ENXIO;
> +
> +	switch (id) {
> +	case 3:
> +		/* PORTD is inverted logic for direction register */
> +		err = bgpio_init(bgc, &pdev->dev, 1, dat, NULL, NULL,
> +				 NULL, dir, 0);
> +		break;
> +	default:
> +		err = bgpio_init(bgc, &pdev->dev, 1, dat, NULL, NULL,
> +				 dir, NULL, 0);
> +		break;
> +	}
>  
> -static int gpio_clps711x_dir_in_inv(struct gpio_chip *chip, unsigned offset)
> -{
> -	int tmp;
> -	unsigned long flags;
> -	struct clps711x_gpio *gpio = dev_get_drvdata(chip->dev);
> +	if (err)
> +		return err;
> +
> +	switch (id) {
> +	case 4:
> +		/* PORTE is 3 lines only */
> +		bgc->gc.ngpio = 3;
> +		break;
> +	default:
> +		bgc->gc.ngpio = 8;
> +		break;
> +	}
>  
> -	spin_lock_irqsave(&gpio->lock, flags);
> -	tmp = readb(clps711x_pdir(chip)) | (1 << offset);
> -	writeb(tmp, clps711x_pdir(chip));
> -	spin_unlock_irqrestore(&gpio->lock, flags);
> +	bgc->gc.base = id * 8;
> +	platform_set_drvdata(pdev, bgc);
>  
> -	return 0;
> +	return gpiochip_add(&bgc->gc);
>  }
>  
> -static int gpio_clps711x_dir_out_inv(struct gpio_chip *chip, unsigned offset,
> -				     int value)
> +static int clps711x_gpio_remove(struct platform_device *pdev)
>  {
> -	int tmp;
> -	unsigned long flags;
> -	struct clps711x_gpio *gpio = dev_get_drvdata(chip->dev);
> -
> -	spin_lock_irqsave(&gpio->lock, flags);
> -	tmp = readb(clps711x_pdir(chip)) & ~(1 << offset);
> -	writeb(tmp, clps711x_pdir(chip));
> -	tmp = readb(clps711x_port(chip)) & ~(1 << offset);
> -	if (value)
> -		tmp |= 1 << offset;
> -	writeb(tmp, clps711x_port(chip));
> -	spin_unlock_irqrestore(&gpio->lock, flags);
> +	struct bgpio_chip *bgc = platform_get_drvdata(pdev);
>  
> -	return 0;
> +	return bgpio_remove(bgc);
>  }
>  
> -static struct {
> -	char	*name;
> -	int	nr;
> -	int	inv_dir;
> -} clps711x_gpio_ports[] __initconst = {
> -	{ "PORTA", 8, 0, },
> -	{ "PORTB", 8, 0, },
> -	{ "PORTC", 8, 0, },
> -	{ "PORTD", 8, 1, },
> -	{ "PORTE", 3, 0, },
> +static struct platform_driver clps711x_gpio_driver = {
> +	.driver	= {
> +		.name	= "clps711x-gpio",
> +		.owner	= THIS_MODULE,
> +	},
> +	.probe	= clps711x_gpio_probe,
> +	.remove	= clps711x_gpio_remove,
>  };
> +module_platform_driver(clps711x_gpio_driver);
>  
> -static int __init gpio_clps711x_init(void)
> -{
> -	int i;
> -	struct platform_device *pdev;
> -	struct clps711x_gpio *gpio;
> -
> -	pdev = platform_device_alloc(CLPS711X_GPIO_NAME, 0);
> -	if (!pdev) {
> -		pr_err("Cannot create platform device: %s\n",
> -		       CLPS711X_GPIO_NAME);
> -		return -ENOMEM;
> -	}
> -
> -	platform_device_add(pdev);
> -
> -	gpio = devm_kzalloc(&pdev->dev, sizeof(struct clps711x_gpio),
> -			    GFP_KERNEL);
> -	if (!gpio) {
> -		dev_err(&pdev->dev, "GPIO allocating memory error\n");
> -		platform_device_unregister(pdev);
> -		return -ENOMEM;
> -	}
> -
> -	platform_set_drvdata(pdev, gpio);
> -
> -	spin_lock_init(&gpio->lock);
> -
> -	for (i = 0; i < CLPS711X_GPIO_PORTS; i++) {
> -		gpio->chip[i].owner		= THIS_MODULE;
> -		gpio->chip[i].dev		= &pdev->dev;
> -		gpio->chip[i].label		= clps711x_gpio_ports[i].name;
> -		gpio->chip[i].base		= i * 8;
> -		gpio->chip[i].ngpio		= clps711x_gpio_ports[i].nr;
> -		gpio->chip[i].get		= gpio_clps711x_get;
> -		gpio->chip[i].set		= gpio_clps711x_set;
> -		if (!clps711x_gpio_ports[i].inv_dir) {
> -			gpio->chip[i].direction_input = gpio_clps711x_dir_in;
> -			gpio->chip[i].direction_output = gpio_clps711x_dir_out;
> -		} else {
> -			gpio->chip[i].direction_input = gpio_clps711x_dir_in_inv;
> -			gpio->chip[i].direction_output = gpio_clps711x_dir_out_inv;
> -		}
> -		WARN_ON(gpiochip_add(&gpio->chip[i]));
> -	}
> -
> -	dev_info(&pdev->dev, "GPIO driver initialized\n");
> -
> -	return 0;
> -}
> -arch_initcall(gpio_clps711x_init);
> -
> -MODULE_LICENSE("GPL v2");
> +MODULE_LICENSE("GPL");
>  MODULE_AUTHOR("Alexander Shiyan <shc_work at mail.ru>");
>  MODULE_DESCRIPTION("CLPS711X GPIO driver");

The way the git generated the diff here made it a bit awkward to follow what
was actually left after the patch, but it looks reasonable to me. It'd be good
to see an ack from the gpio maintainers though.


-Olof


From olof at lixom.net  Sun Apr 14 23:49:05 2013
From: olof at lixom.net (Olof Johansson)
Date: Sun, 14 Apr 2013 20:49:05 -0700
Subject: [GIT PULL] msm core for 3.10
In-Reply-To: <8yazjx3pdz0.fsf@huya.qualcomm.com>
References: <8ya7gk7qsnp.fsf@huya.qualcomm.com>
 <8yazjx3pdz0.fsf@huya.qualcomm.com>
Message-ID: <20130415034905.GC10949@quad.lixom.net>

Hi,

On Fri, Apr 12, 2013 at 03:43:15PM -0700, David Brown wrote:
> The following changes since commit f6161aa153581da4a3867a2d1a7caf4be19b6ec9:
> 
>   Linux 3.9-rc2 (2013-03-10 16:54:19 -0700)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/davidb/linux-msm.git tags/msm-core-3.10
> 
> for you to fetch changes up to e25e3d1fef2c57e49aef64535341c15fe2b29b4a:
> 
>   ARM: msm: Wait for timer clear to complete (2013-03-22 10:46:16 -0700)
> 
> ----------------------------------------------------------------
> Patches for MSM core
> 
> These patches are changes to the MSM timer code that will be for
> upcoming targets, including a generalization of the binding and
> preventing a missing timer interrupt.
> 
> ----------------------------------------------------------------
> Stephen Boyd (2):
>       ARM: msm: Rework timer binding to be more general
>       ARM: msm: Wait for timer clear to complete
> 
>  .../devicetree/bindings/arm/msm/timer.txt          |  41 ++++----
>  arch/arm/boot/dts/msm8660-surf.dts                 |  20 ++--
>  arch/arm/boot/dts/msm8960-cdp.dts                  |  22 ++---
>  arch/arm/mach-msm/timer.c                          | 110 ++++++++++-----------
>  4 files changed, 86 insertions(+), 107 deletions(-)

I didn't see either of the device tree maintainers cc:d on the bindings
update, nor an ack from them. It looks reasonable enough to me, but I
also do know that in your private downstream tree you have a lot of new
bindings. Please make sure these go through proper review channels as
you start to upstream them; i.e. Grant Likely and Rob Herring should
either merge or ack them.

I've cc:d Rob and Grant on this reply and I'll merge it for now but to avoid
delays in getting your code merged in the future please make sure they are in
the loop from the beginning.


Thanks,

-Olof


From horms at verge.net.au  Sun Apr 14 23:56:08 2013
From: horms at verge.net.au (Simon Horman)
Date: Mon, 15 Apr 2013 12:56:08 +0900
Subject: [V3 patch 01/19] ARM: shmobile: cpuidle: remove
 shmobile_enter_wfi function
In-Reply-To: <1365770165-27096-2-git-send-email-daniel.lezcano@linaro.org>
References: <1365770165-27096-1-git-send-email-daniel.lezcano@linaro.org>
 <1365770165-27096-2-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <20130415035608.GB3070@verge.net.au>

On Fri, Apr 12, 2013 at 02:35:47PM +0200, Daniel Lezcano wrote:
> Remove the shmobile_enter_wfi function which is the same as the
> common WFI enter function from the arm cpuidle driver defined
> with the ARM_CPUIDLE_WFI_STATE macro.
> 
> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>

Acked-by: Simon Horman <horms+renesas at verge.net.au>

> ---
>  arch/arm/mach-shmobile/pm-sh7372.c |    1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/arch/arm/mach-shmobile/pm-sh7372.c b/arch/arm/mach-shmobile/pm-sh7372.c
> index f6b14ca..fbef7b9 100644
> --- a/arch/arm/mach-shmobile/pm-sh7372.c
> +++ b/arch/arm/mach-shmobile/pm-sh7372.c
> @@ -414,7 +414,6 @@ static struct cpuidle_driver sh7372_cpuidle_driver = {
>  	.state_count		= 5,
>  	.safe_state_index	= 0, /* C1 */
>  	.states[0] = ARM_CPUIDLE_WFI_STATE,
> -	.states[0].enter = shmobile_enter_wfi,
>  	.states[1] = {
>  		.name = "C2",
>  		.desc = "Core Standby Mode",
> -- 
> 1.7.9.5
> 


From horms at verge.net.au  Sun Apr 14 23:56:18 2013
From: horms at verge.net.au (Simon Horman)
Date: Mon, 15 Apr 2013 12:56:18 +0900
Subject: [V3 patch 02/19] ARM: shmobile: cpuidle: remove
 shmobile_enter_wfi prototype
In-Reply-To: <1365770165-27096-3-git-send-email-daniel.lezcano@linaro.org>
References: <1365770165-27096-1-git-send-email-daniel.lezcano@linaro.org>
 <1365770165-27096-3-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <20130415035618.GC3070@verge.net.au>

On Fri, Apr 12, 2013 at 02:35:48PM +0200, Daniel Lezcano wrote:
> Commit 688036b538974de32ce55be8b0e013b003992abc removed the function
> 'shmobile_enter_wfi' but we forgot to remove the definition in the header file.
> 
> Note this function is just an alias to 'cpu_do_idle()' wrapped into a cpuidle
> function callback prototype which already exists with the default WFI state
> and the arm_simple_enter function.
> 
> Remove the function prototype.
> 
> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>

Acked-by: Simon Horman <horms+renesas at verge.net.au>

> ---
>  arch/arm/mach-shmobile/include/mach/common.h |    3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/arch/arm/mach-shmobile/include/mach/common.h b/arch/arm/mach-shmobile/include/mach/common.h
> index e48606d..362f9b2 100644
> --- a/arch/arm/mach-shmobile/include/mach/common.h
> +++ b/arch/arm/mach-shmobile/include/mach/common.h
> @@ -13,9 +13,6 @@ extern int shmobile_clk_init(void);
>  extern void shmobile_handle_irq_intc(struct pt_regs *);
>  extern struct platform_suspend_ops shmobile_suspend_ops;
>  struct cpuidle_driver;
> -struct cpuidle_device;
> -extern int shmobile_enter_wfi(struct cpuidle_device *dev,
> -			      struct cpuidle_driver *drv, int index);
>  extern void shmobile_cpuidle_set_driver(struct cpuidle_driver *drv);
>  
>  extern void sh7372_init_irq(void);
> -- 
> 1.7.9.5
> 


From horms at verge.net.au  Sun Apr 14 23:56:25 2013
From: horms at verge.net.au (Simon Horman)
Date: Mon, 15 Apr 2013 12:56:25 +0900
Subject: [V3 patch 12/19] ARM: shmobile: cpuidle: use init/exit common
 routine
In-Reply-To: <1365770165-27096-13-git-send-email-daniel.lezcano@linaro.org>
References: <1365770165-27096-1-git-send-email-daniel.lezcano@linaro.org>
 <1365770165-27096-13-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <20130415035625.GD3070@verge.net.au>

On Fri, Apr 12, 2013 at 02:35:58PM +0200, Daniel Lezcano wrote:
> Remove the duplicated code and use the cpuidle common code for initialization.
> 
> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
> Acked-by: Simon Horman <horms+renesas at verge.net.au>
> ---
>  arch/arm/mach-shmobile/cpuidle.c |   10 +---------
>  1 file changed, 1 insertion(+), 9 deletions(-)
> 
> diff --git a/arch/arm/mach-shmobile/cpuidle.c b/arch/arm/mach-shmobile/cpuidle.c
> index d671ae9..0afeb5c 100644
> --- a/arch/arm/mach-shmobile/cpuidle.c
> +++ b/arch/arm/mach-shmobile/cpuidle.c
> @@ -16,7 +16,6 @@
>  #include <asm/cpuidle.h>
>  #include <asm/io.h>
>  
> -static struct cpuidle_device shmobile_cpuidle_dev;
>  static struct cpuidle_driver shmobile_cpuidle_default_driver = {
>  	.name			= "shmobile_cpuidle",
>  	.owner			= THIS_MODULE,
> @@ -34,12 +33,5 @@ void __init shmobile_cpuidle_set_driver(struct cpuidle_driver *drv)
>  
>  int __init shmobile_cpuidle_init(void)
>  {
> -	struct cpuidle_device *dev = &shmobile_cpuidle_dev;
> -
> -	cpuidle_register_driver(cpuidle_drv);
> -
> -	dev->state_count = cpuidle_drv->state_count;
> -	cpuidle_register_device(dev);
> -
> -	return 0;
> +	return cpuidle_register(cpuidle_drv, NULL);
>  }
> -- 
> 1.7.9.5
> 


From olof at lixom.net  Sun Apr 14 23:56:49 2013
From: olof at lixom.net (Olof Johansson)
Date: Sun, 14 Apr 2013 20:56:49 -0700
Subject: [GIT PULL] msm fixes for 3.10
In-Reply-To: <8yar4ifpdy7.fsf@huya.qualcomm.com>
References: <8ya7gk7qsnp.fsf@huya.qualcomm.com>
 <8yar4ifpdy7.fsf@huya.qualcomm.com>
Message-ID: <20130415035649.GD10949@quad.lixom.net>

On Fri, Apr 12, 2013 at 03:43:44PM -0700, David Brown wrote:
> The following changes since commit f6161aa153581da4a3867a2d1a7caf4be19b6ec9:
> 
>   Linux 3.9-rc2 (2013-03-10 16:54:19 -0700)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/davidb/linux-msm.git tags/msm-fix-3.10
> 
> for you to fetch changes up to 73a8c28f167c9e7bc42eafc0bcbd298031709430:
> 
>   ARM: msm: Fix uncompess.h tx underrun check (2013-04-11 09:40:35 -0700)
> 
> ----------------------------------------------------------------
> Some minor fixes for MSM for 3.10
> 
>   - Fix a timer problem that causes missed ticks and hangs.
> 
>   - Fix a problem with the decompressor UART dropping characters.
> 
> ----------------------------------------------------------------
> Stephen Boyd (2):
>       ARM: msm: Stop counting before reprogramming clockevent
>       ARM: msm: Fix uncompess.h tx underrun check
> 
>  arch/arm/mach-msm/include/mach/uncompress.h | 2 +-
>  arch/arm/mach-msm/timer.c                   | 5 ++++-
>  2 files changed, 5 insertions(+), 2 deletions(-)

Looks like the "Stop counting before reprogramming" patch has already been
merged through fixes for 3.9.

Since that was provided in a branch with the same SHA, there's no problem with
this branch and I've pulled it, but in the future it'd be nice to get a pull
request that doesn't list already merged patches since the diffstat won't match
when I compare them otherwise.



-Olof


From horms at verge.net.au  Sun Apr 14 23:58:05 2013
From: horms at verge.net.au (Simon Horman)
Date: Mon, 15 Apr 2013 12:58:05 +0900
Subject: [PATCH v4 7/7] ARM: mach-shmobile: r8a7740: Setup the timer
 CMT10 using DT
In-Reply-To: <CABYn4szS=dLwQbnWe4rY==yomeefoLc7NNCR+KfM8pO3L5ihmQ@mail.gmail.com>
References: <1365679443-25456-1-git-send-email-hechtb+renesas@gmail.com>
 <1365679443-25456-7-git-send-email-hechtb+renesas@gmail.com>
 <20130412012350.GA25941@verge.net.au>
 <CABYn4szS=dLwQbnWe4rY==yomeefoLc7NNCR+KfM8pO3L5ihmQ@mail.gmail.com>
Message-ID: <20130415035805.GE3070@verge.net.au>

On Fri, Apr 12, 2013 at 02:46:15PM +0200, Bastian Hecht wrote:
> Hello Simon,
> 
> 2013/4/12 Simon Horman <horms at verge.net.au>:
> > On Thu, Apr 11, 2013 at 01:24:03PM +0200, Bastian Hecht wrote:
> >> We can now use the Device Tree for bringing up our timer device CMT10 on
> >> the SoC r8a7740.
> >
> > Hi Bastian,
> >
> > unfortunately with this patch the armaillo800eva no longer boots.
> >
> > I am testing  against renesas-next-20130411v2 with the other
> > 6 patches in this series applied. I am using the armadillo800eva defconfig.
> > The boot log is below.
> 
> Ouch, sorry! I checked the patches and somehow I missed a chunk in
> 0007-... when I rebased the series to next. The part that actually
> adds the DT info to r8a7740.dtsi. Further we need the GIC to be
> present in the DT to make things work here (my old patch used the
> INTCA as interrupt controller reference, but that has gone in the
> meantime).
> I want to repost my A1 reference code soon and in there I add the way
> to set up the GIC via DT.
> 
> To accelerate things maybe we take 0001-0006 now and postpone 0007
> until the GIC is in the DT?
> I diffed the new patches against the v3 series, and the .dtsi chunk is
> the only one that didn't make it, so I strongly believe the series is
> fine now.

Ok, thanks. I'll see about queuing-up 0001-0006 and you can repost
0007 at a later date.


From horms at verge.net.au  Mon Apr 15 00:01:09 2013
From: horms at verge.net.au (Simon Horman)
Date: Mon, 15 Apr 2013 13:01:09 +0900
Subject: [PATCH v2 1/2] ARM: shmobile: r8a7740: Add Suspend-To-RAM A3SM
In-Reply-To: <CABYn4sx6czjsCqF0UQf3qD1h4sj9Si1AmtMSogEjjdbTuy7zzQ@mail.gmail.com>
References: <1365689264-14410-1-git-send-email-hechtb+renesas@gmail.com>
 <20130412005635.GG24461@verge.net.au>
 <CABYn4sx6czjsCqF0UQf3qD1h4sj9Si1AmtMSogEjjdbTuy7zzQ@mail.gmail.com>
Message-ID: <20130415040109.GF3070@verge.net.au>

On Fri, Apr 12, 2013 at 02:54:46PM +0200, Bastian Hecht wrote:
> Hi Simon,
> 
> 2013/4/12 Simon Horman <horms at verge.net.au>:
> > On Thu, Apr 11, 2013 at 04:07:43PM +0200, Bastian Hecht wrote:
> >> We add 2 Suspend to RAM modes:
> >> - A3SM PLL0 on/off:     Power domain A3SM that contains the ARM core
> >>                         and the 2nd level cache with either PLL0 on
> >>                         or off
> >>
> >> As the suspend to memory mechanism we use A3SM PLL off. A3SM PLL on
> >> is included here too, so CPUIdle can use both power down modes (not
> >> included in this patch).
> >>
> >> The setup of the SYSC regarding the external IRQs is taken from
> >> pm-sh7372.c from Magnus Damm.
> >>
> >> Signed-off-by: Bastian Hecht <hechtb+renesas at gmail.com>
> >> ---
> >> This patch relies on
> >> ARM: hw_breakpoint: Do not use __cpuinitdata for dbg_cpu_pm_nb
> >>
> >> v2: successor to [PATCH] ARM: shmobile: r8a7740: Add Suspend-To-RAM modes and CPUIdle
> >>
> >> - Removed the 2nd L1 flush in the asm shutdown code. See comment in code for explanation.
> >> - Reworked the ifdefs: We can only use CPUIdle if SUSPEND is set as well.
> >> - Removed cpu_do_idle() in r8a7740_enter_suspend: We don't want to sleep twice...
> >>
> >> If you want to test this use this workaround in the st1232 driver in
> >> drivers/input/touchscreen/st1232.c:
> >>
> >>         error = request_threaded_irq(client->irq, NULL, st1232_ts_irq_handler,
> >> -                                    IRQF_ONESHOT, client->name, ts);
> >> +                                    IRQF_NO_SUSPEND | IRQF_ONESHOT, client->name, ts);
> >>
> >> You need it as the current irqpin driver doesn't handle wakeup devices properly yet.
> >>
> >> Tested with the 4 possiblities        L2 on - Suspend on/off - CPUIdle on/off
> >> and with the additional test  L2 off - Suspend on - CPUIdle on
> >
> > Hi Bastian,
> >
> > are the pre-requisites listed above likely to be in v3.11-rc1 or rc2?
> 
> I probably was a bit incorrect by saying "relies on". Right now the
> complete suspend system is broken on ARM UP systems. So I think we can
> use this patch without coordination regarding the other patch. It's
> just when you want to test this here, then you need the above
> mentioned patch to fix the system first before you can do anything.

Thanks that seems reasonable.

However, I will hold of queuing-up this series as there seems
to be some discussion relating to patch 1/2. Please let me know
when that is resolved via discussion or a fresh series.


From olof at lixom.net  Mon Apr 15 00:01:44 2013
From: olof at lixom.net (Olof Johansson)
Date: Sun, 14 Apr 2013 21:01:44 -0700
Subject: [GIT PULL] msm cleanup for 3.10
In-Reply-To: <8ya7gk7qsnp.fsf@huya.qualcomm.com>
References: <8ya7gk7qsnp.fsf@huya.qualcomm.com>
Message-ID: <20130415040144.GE10949@quad.lixom.net>

On Fri, Apr 12, 2013 at 03:40:42PM -0700, David Brown wrote:
> The following changes since commit 6dbe51c251a327e012439c4772097a13df43c5b8:
> 
>   Linux 3.9-rc1 (2013-03-03 15:11:05 -0800)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/davidb/linux-msm.git tags/msm-cleanup-3.10

Hi,

I've pulled in all 4 branches, see two comments on the individual pull requests
though.

Given the date stamps on the commits, it seems like you've been sitting on
these for a while. Please try to send them in sooner in future release
cycles, it is perfectly OK to send a newer pull request for the same
branch with a few more patches on it later on (ideally with a new tag
describing the new portions). That way we don't get all the code so
late, and you run a lower risk of us being grumpy because several other
maintainers have also been late and we're slammed with merges.

The bulk of the material for the merge window really should be in arm-soc
by -rc6, with minor updates thereafter.


-Olof


From cdall at cs.columbia.edu  Mon Apr 15 00:37:47 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Sun, 14 Apr 2013 21:37:47 -0700
Subject: [PATCH] KVM: ARM: Fix wrong address in comment
In-Reply-To: <000801ce365d$7b9bce70$72d36b50$%choi@samsung.com>
References: <000801ce365d$7b9bce70$72d36b50$%choi@samsung.com>
Message-ID: <CAEDV+gKXSFqS6_Q1K7b7i1PCdhAYH1_77UMzLomHLwreUsaTFQ@mail.gmail.com>

On Wed, Apr 10, 2013 at 7:37 PM, Jonghwan Choi <jhbird.choi at samsung.com> wrote:
> hyp_hvc vector offset should be 0x14 and hyp_svc vector offset should be
> 0x8.
>
> Signed-off-by: Jonghwan Choi <jhbird.choi at samsung.com>
> ---
>  arch/arm/kvm/interrupts.S |    4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/kvm/interrupts.S b/arch/arm/kvm/interrupts.S
> index 8ca87ab..a8e0c2d 100644
> --- a/arch/arm/kvm/interrupts.S
> +++ b/arch/arm/kvm/interrupts.S
> @@ -235,9 +235,9 @@ ENTRY(kvm_call_hyp)
>   * instruction is issued since all traps are disabled when running the host
>   * kernel as per the Hyp-mode initialization at boot time.
>   *
> - * HVC instructions cause a trap to the vector page + offset 0x18 (see
> hyp_hvc
> + * HVC instructions cause a trap to the vector page + offset 0x14 (see
> hyp_hvc
>   * below) when the HVC instruction is called from SVC mode (i.e. a guest or
> the
> - * host kernel) and they cause a trap to the vector page + offset 0xc when
> HVC
> + * host kernel) and they cause a trap to the vector page + offset 0x8 when
> HVC
>   * instructions are called from within Hyp-mode.
>   *
>   * Hyp-ABI: Calling HYP-mode functions from host (in SVC mode):
> --
> 1.7.9.5
>
this has already been applied:
https://github.com/columbia/linux-kvm-arm/commit/0b5e3bac30c545720f7e6b026241b5f8dd832df2


From nobuhiro.iwamatsu.yj at renesas.com  Mon Apr 15 00:44:52 2013
From: nobuhiro.iwamatsu.yj at renesas.com (Nobuhiro Iwamatsu)
Date: Mon, 15 Apr 2013 13:44:52 +0900
Subject: [PATCH] arm: shmobile: armadillo800eva: Fix maximum number of SCIF
Message-ID: <1366001092-8753-1-git-send-email-nobuhiro.iwamatsu.yj@renesas.com>

The r8a77740 has 9ch SCIF. It is not 8ch.

Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj at renesas.com>
---
 arch/arm/configs/armadillo800eva_defconfig |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/configs/armadillo800eva_defconfig b/arch/arm/configs/armadillo800eva_defconfig
index 0f2d80d..fae939d 100644
--- a/arch/arm/configs/armadillo800eva_defconfig
+++ b/arch/arm/configs/armadillo800eva_defconfig
@@ -86,7 +86,7 @@ CONFIG_TOUCHSCREEN_ST1232=y
 # CONFIG_SERIO is not set
 # CONFIG_LEGACY_PTYS is not set
 CONFIG_SERIAL_SH_SCI=y
-CONFIG_SERIAL_SH_SCI_NR_UARTS=8
+CONFIG_SERIAL_SH_SCI_NR_UARTS=9
 CONFIG_SERIAL_SH_SCI_CONSOLE=y
 # CONFIG_HW_RANDOM is not set
 CONFIG_I2C=y
-- 
1.7.10.4



From cdall at cs.columbia.edu  Mon Apr 15 00:52:55 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Sun, 14 Apr 2013 21:52:55 -0700
Subject: [PATCH] ARM: KVM: fix L_PTE_S2_RDWR to actually be Read/Write
In-Reply-To: <1365771616-7380-1-git-send-email-marc.zyngier@arm.com>
References: <1365771616-7380-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <CAEDV+g+eMFOX4GepsLtNe0JGxqQ1pnFDOs8y7_iaUgppTFouvQ@mail.gmail.com>

On Fri, Apr 12, 2013 at 6:00 AM, Marc Zyngier <marc.zyngier at arm.com> wrote:
> Looks like our L_PTE_S2_RDWR definition is slightly wrong,
> and is actually write only (see ARM ARM Table B3-9, Stage 2 control
> of access permissions). Didn't make a difference for normal pages,
> as we OR the flags together, but I'm still wondering how it worked
> for Stage-2 mapped devices, such as the GIC.

PAGE_S2_DEVICE uses L_PTE_USER which sets bit 6, so that's why it works.

The define used to be called _WRITE, which is how this creeped in. We
should probably change this to be completely independent of
L_PTE_USER, I'll cook up a patch.

>
> Brown paper bag time, again.

thanks

>
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> ---
>  arch/arm/include/asm/pgtable-3level.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/include/asm/pgtable-3level.h b/arch/arm/include/asm/pgtable-3level.h
> index 6ef8afd..86b8fe3 100644
> --- a/arch/arm/include/asm/pgtable-3level.h
> +++ b/arch/arm/include/asm/pgtable-3level.h
> @@ -111,7 +111,7 @@
>  #define L_PTE_S2_MT_WRITETHROUGH (_AT(pteval_t, 0xa) << 2) /* MemAttr[3:0] */
>  #define L_PTE_S2_MT_WRITEBACK   (_AT(pteval_t, 0xf) << 2) /* MemAttr[3:0] */
>  #define L_PTE_S2_RDONLY                 (_AT(pteval_t, 1) << 6)   /* HAP[1]   */
> -#define L_PTE_S2_RDWR           (_AT(pteval_t, 2) << 6)   /* HAP[2:1] */
> +#define L_PTE_S2_RDWR           (_AT(pteval_t, 3) << 6)   /* HAP[2:1] */
>
>  /*
>   * Hyp-mode PL2 PTE definitions for LPAE.
> --
> 1.8.1.4
>
>
>
> _______________________________________________
> kvmarm mailing list
> kvmarm at lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm


From cdall at cs.columbia.edu  Mon Apr 15 00:57:36 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Sun, 14 Apr 2013 21:57:36 -0700
Subject: [PATCH] ARM: KVM: iterate over all CPUs for CPU compatibility
 check
In-Reply-To: <51680AF9.7040109@arm.com>
References: <1365771875-5788-1-git-send-email-andre.przywara@linaro.org>
 <51680AF9.7040109@arm.com>
Message-ID: <CAEDV+g+E8PLc60vMRhq4O_AL2WjmYDLb6=Wh34ynhevh7uAGJA@mail.gmail.com>

On Fri, Apr 12, 2013 at 6:24 AM, Marc Zyngier <marc.zyngier at arm.com> wrote:
> On 12/04/13 14:04, Andre Przywara wrote:
>> kvm_target_cpus() checks the compatibility of the used CPU with
>> KVM, which is currently limited to ARM Cortex-A15 cores.
>> However by calling it only once on any random CPU it assumes that
>> all cores are the same, which is not true for big.LITTLE parts.
>>
>> After doing about 40 boots on a TC-2 core tile, I found it running
>> in all but one case on one of the A7 cores (which correctly denied
>> KVM initialization). On the 39th boot however the code ran on
>> an A15, leading to a hang after returning success:
>>
>> ...
>> TCP: reno registered
>> UDP hash table entries: 512 (order: 2, 16384 bytes)
>> UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
>> NET: Registered protocol family 1
>> kvm_target_cpu() on CPU #1, part is c0f0
>>  ... (pause for a while) ...
>> INFO: rcu_sched self-detected stall on CPUINFO: rcu_sched detected stalls on CPU
>> s/tasks: { 1} (detected by 0, t=6002 jiffies, g=4294966999, c=4294966998, q=15)
>> Task dump for CPU 1:
>> swapper/0       R running      0     1      0 0x00000002
>>
>> So iterate over every CPU to correctly determine the capability of
>> the system to run the current KVM implementation.
>> In case a big.LITTLE configuration is the reason for denial, give
>> the user a hint how to get it running anyway (maxcpus= on the kernel
>> command line).
>>
>> Please push this still into 3.9.
>>
>> Signed-off-by: Andre Przywara <andre.przywara at linaro.org>
>
> [...]
>
> Nak. The fact that one of the CPUs seem to hang is a sure sign that
> something is severely broken, and you definitely want to fix that issue,
> instead of blindly ignoring it.
>
> Additionally, it seems you're just papering over the issue. You should
> be able to exclude the A7 processors, but not completely deny KVM from
> running on the hardware.
>
Marc, I disagree with this nak. If the current kernel breaks boot on a
Big.Little system, we need to take care of that first, and the
proposed patch is a quick way to do so, and it does not stand in the
way of introducing proper Big.Little support in any way, which I'm
sure is going to open up a lot of other interesting questions.

I'm going to take this one.

-Christoffer


From hvaibhav at ti.com  Mon Apr 15 01:06:33 2013
From: hvaibhav at ti.com (Hiremath, Vaibhav)
Date: Mon, 15 Apr 2013 05:06:33 +0000
Subject: [GIT PULL] ARM: OMAP5: hwmod, prm/cm data files and updates for
 3.10
In-Reply-To: <51654DC5.2040909@ti.com>
References: <1363768852-18125-1-git-send-email-santosh.shilimkar@ti.com>
 <20130401170539.GK10155@atomide.com> <515BA76D.3000302@ti.com>
 <alpine.DEB.2.00.1304031146230.2616@utopia.booyaka.com>
 <515D6020.2030103@ti.com> <20130404165208.GI10155@atomide.com>
 <515DB110.9000503@ti.com> <515F00B8.3000501@ti.com>
 <79CD15C6BA57404B839C016229A409A83EC4A81D@DBDE01.ent.ti.com>
 <51654DC5.2040909@ti.com>
Message-ID: <79CD15C6BA57404B839C016229A409A83EC55521@DBDE01.ent.ti.com>


> -----Original Message-----
> From: Shilimkar, Santosh
> Sent: Wednesday, April 10, 2013 5:02 PM
> To: Hiremath, Vaibhav
> Cc: Tony Lindgren; Paul Walmsley; linux-omap at vger.kernel.org; linux-
> arm-kernel at lists.infradead.org; Kristo, Tero; Menon, Nishanth; Nayak,
> Rajendra; Valentin, Eduardo; Anna, Suman; Bedia, Vaibhav
> Subject: Re: [GIT PULL] ARM: OMAP5: hwmod, prm/cm data files and
> updates for 3.10
> 
> On Wednesday 10 April 2013 04:45 PM, Hiremath, Vaibhav wrote:
> >> -----Original Message-----
> >> From: Shilimkar, Santosh
> >> Sent: Friday, April 05, 2013 10:20 PM
> >> To: Tony Lindgren
> >> Cc: Paul Walmsley; linux-omap at vger.kernel.org; linux-arm-
> >> kernel at lists.infradead.org; Kristo, Tero; Menon, Nishanth; Nayak,
> >> Rajendra; Valentin, Eduardo; Anna, Suman; Bedia, Vaibhav; Hiremath,
> >> Vaibhav
> >> Subject: Re: [GIT PULL] ARM: OMAP5: hwmod, prm/cm data files and
> >> updates for 3.10
> >>
> >> On Thursday 04 April 2013 10:27 PM, Santosh Shilimkar wrote:
> >>> On Thursday 04 April 2013 10:22 PM, Tony Lindgren wrote:
> >>>> * Santosh Shilimkar <santosh.shilimkar at ti.com> [130404 04:15]:
> >> [..]
> >>
> >>>> Can't we already trim the am33xx hwmod data after your patches for
> >>>> v3.10 as am33xx is already DT only? Unfortunately we cannot create
> >>>> negative diffstat in other ways for v3.10 merge window as we
> cannot
> >>>> make omap4 DT only just quite yet.
> >>>>
> >>> Yes we can and I can take a stab it tomorrow. The only thing is I
> >>> might need some support for testing but thats manageable. Will
> >>> take a stab at it tomorrow and if everything goes well, post a
> >>> patch for smae.
> >>>
> >> Patch for the AM33XX to trim is end of the email. Thanks to
> >> Sricharan and Pekon for patch and testing. Looping both
> >> Vaibhav's if they have any objection on the patch.
> >>
> >> Regards,
> >> Santosh
> >>
> >> From b95dd33fe59b8e77727eb3b1717d763bbf9a2893 Mon Sep 17 00:00:00
> 2001
> >> From: Sricharan R <r.sricharan at ti.com>
> >> Date: Fri, 5 Apr 2013 20:39:12 +0530
> >> Subject: [PATCH] ARM: AM33XX: hwmod data: Clean up the data file
> >>
> >> - The IO resource information like dma request lines, irq number and
> >> ocp address space can be populated via dt blob. So such data can be
> >> stripped
> >> from SOC hwmod data file.
> >>
> >> - The devices like adc, mailbox, gpmc which are missing the device
> >> tree bindings, hwmod data is not added since AM33XX is DT only
> build.
> >> When such devices add the dt bindings, respective hwmod data can be
> >> added along with it.
> >>
> > This seems unnecessary churn to me. DT bindings for most of the
> devices
> > which you mentioned above are submitted and are at various stages of
> review
> > process.
> >
> > ADC:
> >
> > GPMC:
> >
> > PWM:
> >
> The modules are dropped as per what is going for 3.10 merge window.
> Above 3 modules can be retained if the DT conversion patches are
> under review and can go along with this patch most likely for 3.11.
> 
> >
> >> - The hwmod like firewall etc which are not useful are also dropped.
> >>
> >> This gets us around ~2000 loc of negative diff. Patch is boot tested
> on
> >> AM335X EVM.
> >>
> > I would not recommend to get into unnecessary code churn in the
> future just
> > to reduce temp Number of Lines of code. This will also kill our
> autogeneration
> > concept as well.
> >
> It doesn't break any concept. We just autogenrate what is *useful*
> rather.
> BTW, I didn't find any srcipt to auto-generate the AM33XX data so we
> have
> to manually do the updates. Can you send me a pointer if you have a
> sript
> for this. With script it is much simpler to clean-up the data.
> 
> 
> > I would suggest you to just alone drop base-addr, irq and dma
> references
> > from hwmod entries.
> >
> That we are doing anyways. Apart from that we should also clean-up data
> which is not used and useful. Why do you need unused data like firewall
> and
> friends ?
> 
> So as I understood, you would like to keep the data for ADC, PWM and
> GPMC
> which is fine by me. We just need those DT bindings in place so that
> they
> go together. Who is following the DT patches for these ?
> 
> Thanks for looking into it Vaibhav.
> 
Are you planning to send updated version of this?
I would rather prefer to review next version.

Please let me know if you need any help here.

Thanks,
Vaibhav


From prabhakar.csengg at gmail.com  Mon Apr 15 01:09:55 2013
From: prabhakar.csengg at gmail.com (Prabhakar Lad)
Date: Mon, 15 Apr 2013 10:39:55 +0530
Subject: Query on pinctrl usage for DT nodes
In-Reply-To: <20130410203408.GP10155@atomide.com>
References: <CA+V-a8uiPwsAD--OHFAE=i2ed+-wbXm4p2deZXr92+Zv6GDS1w@mail.gmail.com>
 <515C5C76.3080009@wwwdotorg.org>
 <CA+V-a8t3wtP77DdeUoQHKMjAuWmV+ude+1J3UjJmMTqobgStjA@mail.gmail.com>
 <5162FD4A.1030909@wwwdotorg.org>
 <CA+V-a8vwdCkyMqiynj5BodXbjwJ=e4qNb-29FhLweqbjc7DBQA@mail.gmail.com>
 <5165A22B.4070200@wwwdotorg.org> <20130410203408.GP10155@atomide.com>
Message-ID: <CA+V-a8syL4YCddiz5W4dEhAhQjFo07_Hg+J6TN94cuPV7SQGag@mail.gmail.com>

Hi Tony,

On Thu, Apr 11, 2013 at 2:04 AM, Tony Lindgren <tony at atomide.com> wrote:
> * Stephen Warren <swarren at wwwdotorg.org> [130410 10:37]:
>> On 04/10/2013 02:12 AM, Prabhakar Lad wrote:
>> ...
>> > Following is the proposed fix/hack let me know if its OK.
>> >
>> > Regards,
>> > --Prabhakar
>> >
>> > ->>>>>>>>>>>>>>>>>>>
>> >
>> > diff --git a/drivers/pinctrl/core.h b/drivers/pinctrl/core.h
>> > index ee72f1f..78fb42d 100644
>> > --- a/drivers/pinctrl/core.h
>> > +++ b/drivers/pinctrl/core.h
>> > @@ -46,6 +46,7 @@ struct pinctrl_dev {
>> >         struct pinctrl *p;
>> >         struct pinctrl_state *hog_default;
>> >         struct pinctrl_state *hog_sleep;
>> > +       bool bits_per_mux;
>>
>> This clearly isn't correct; any change to solve this problem should only
>> touch the internals of the pinctrl-single driver, not the pinctrl core.
>
> Yeah how about just change the pintctrl-single,bits register
> naming to be register + bit?  Something like 0xdeadbeef.0 and
> 0xdeadbeef.1 and so on.
>
How and where the changing the register naming would help ?

Regards,
--Prabhakar

> Regards,
>
> Tony


From paul at pwsan.com  Mon Apr 15 01:33:48 2013
From: paul at pwsan.com (Paul Walmsley)
Date: Mon, 15 Apr 2013 05:33:48 +0000 (UTC)
Subject: OMAP baseline test results for v3.9-rc7
Message-ID: <alpine.DEB.2.00.1304150530520.17469@utopia.booyaka.com>


Here are some basic OMAP test results for Linux v3.9-rc7.
Logs and other details at:

    http://www.pwsan.com/omap/testlogs/test_v3.9-rc7/20130414220303/


Test summary
------------

Build:
    FAIL ( 2/16): am33xx_only, omap2plus_defconfig_2430sdp_only
    Pass (14/16): n800_multi_omap2xxx, n800_only_a, omap1_defconfig, 
                  omap1_defconfig_1510innovator_only, 
                  omap1_defconfig_5912osk_only, omap2plus_defconfig, 
                  omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm, 
                  omap2plus_defconfig_omap2_4_only, 
                  omap2plus_defconfig_omap3_4_only, 
                  rmk_omap3430_ldp_allnoconfig, 
                  rmk_omap3430_ldp_oldconfig, 
                  rmk_omap4430_sdp_allnoconfig, 
                  rmk_omap4430_sdp_oldconfig

Boot to userspace:
    FAIL ( 1/11): am335xbone
    Pass (10/11): 2420n800, 2430sdp, 3517evm, 3530es3beagle,
                  3730beaglexm, 37xxevm, 4430es2panda, 4460pandaes,
                  5912osk, cmt3517

PM ret, suspend:
    FAIL ( 2/ 6): 2430sdp, 4430es2panda
    Pass ( 4/ 6): 3530es3beagle, 3730beaglexm, 37xxevm, 4460pandaes

PM ret, dynamic idle:
    FAIL ( 3/ 6): 2430sdp, 4430es2panda, 4460pandaes
    Pass ( 3/ 6): 3530es3beagle, 3730beaglexm, 37xxevm

PM off, suspend:
    FAIL ( 2/ 5): 4430es2panda, 4460pandaes
    Pass ( 3/ 5): 3530es3beagle, 3730beaglexm, 37xxevm

PM off, dynamic idle:
    FAIL ( 2/ 5): 4430es2panda, 4460pandaes
    Pass ( 3/ 5): 3530es3beagle, 3730beaglexm, 37xxevm



Failing tests: fixed by posted patches
--------------------------------------

Build:

* am33xx_only, omap2plus_defconfig_2430sdp_only: omap-{smp,hotplug}.c link errors
  - Discussion & RFC patch: http://www.spinics.net/lists/arm-kernel/msg230017.html
  - Still needs revision of the patch


Failing tests: needing investigation
------------------------------------

Boot tests:

* 3517EVM & CM-T3517: boot hangs with NFS root
  - Likely some Kconfig, board file, and PM issues with EMAC
  - Longstanding bug
  - Not currently part of the automated test suite

Boot warnings:

* CM-T3517: L3 in-band error with IPSS during boot
  - Cause unknown but see http://marc.info/?l=linux-omap&m=134833869730129&w=2
  - Longstanding issue; does not occur on the 3517EVM

PM tests:

* 2430sdp: pwrdm state mismatch(dsp_pwrdm) 0 != 3
  - need to doublecheck wakeup dependencies
  - (am assuming it's still there; userspace problems prevent the test
     from running, probably due to the lock warning)

* 2430sdp: power domains not entering retention
  - Cause unknown
  - (am assuming it's still there; userspace problems prevent the test
     from running, probably due to the lock warning)

* 4430es2panda, 4460pandaes: pwrdm state mismatch on CAM, DSS, ABE

* 4460pandaes: pwrdm state mismatch on IVAHD, TESLA 

* 4430es2panda: CORE, TESLA, IVAHD, L3INIT didn't enter target state
  - Probably due to lack of reset code for M3, DSP, SL2IF, FSUSB
    per discussion with Tero Kristo
  - Likely dependent on the bootloader version
    - fails with 2012.07-00136-g755de79
  - http://marc.info/?l=linux-arm-kernel&m=136432340618226&w=2

* 4460pandaes: chip not entering retention in dynamic idle
  - Presumably 4430es2panda also fails this
  - Suspend-to-RAM enters full chip retention

* 3730 Beagle XM: does not serial wake from off-idle suspend when console
  UART doesn't clock-gate ("debug ignore_loglevel")
  - Cause unknown
  - Not yet part of the automated test suite
  - Re-tested at v3.7; still failing:
    http://www.pwsan.com/omap/transcripts/20121211-3730beaglexm-3.7-pm-offmode-fail-debug.txt

Other:

* 4430es2panda: omap_hwmod: l3_instr: _wait_target_disable failed
  - Unknown cause; could be due to the lack of hierarchical enable/disable
    in hwmod code
  - Jon Hunter and Santosh Shilimkar report this does not appear with
    the same X-loader/bootloader on his 4430ES2.3 Panda, so could be
    ES-level dependent


Failing tests: reported by others 
---------------------------------

- MUSB broken after v3.9-rc6
  - due to commit 92702df3570e1ccfa050e135e50c450502251b79
  - discussion here: http://marc.info/?l=linux-omap&m=136544098331552&w=2
  - patch pending upstream:
    http://marc.info/?l=linux-omap&m=136562302329307&w=2

vmlinux object size
(delta in bytes from test_v3.9-rc6 
(31880c37c11e28cb81c70757e38392b42e695dc6)):
   text     data      bss    total  kernel
  +5067        0        0    +5067  n800_multi_omap2xxx
   +975        0        0     +975  n800_only_a
  +1135        0        0    +1135  omap1_defconfig
  +1119        0        0    +1119  omap1_defconfig_1510innovator_only
  +1135        0        0    +1135  omap1_defconfig_5912osk_only
  +1251        0        0    +1251  omap2plus_defconfig
  +1271       -8        0    +1263  omap2plus_defconfig_cpupm
  +1255      +24        0    +1279  omap2plus_defconfig_no_pm
  +1255       -8        0    +1247  omap2plus_defconfig_omap2_4_only
  +1359        0        0    +1359  omap2plus_defconfig_omap3_4_only
  +2064       +8      -56    +2016  rmk_omap3430_ldp_allnoconfig
   +703        0        0     +703  rmk_omap3430_ldp_oldconfig
  +2064       +8      -56    +2016  rmk_omap4430_sdp_allnoconfig
  +1743      -16        0    +1727  rmk_omap4430_sdp_oldconfig

Boot-time memory difference
(delta in bytes from test_v3.9-rc6 
(31880c37c11e28cb81c70757e38392b42e695dc6))
  avail  rsrvd   high  freed  board          kconfig
    -8k     8k      .      .  2420n800       n800_only_a




From rajagopal.venkat at linaro.org  Mon Apr 15 01:56:38 2013
From: rajagopal.venkat at linaro.org (Rajagopal Venkat)
Date: Mon, 15 Apr 2013 11:26:38 +0530
Subject: [PATCH V4 3/3] clk: Fixup locking issues for clk_set_parent
In-Reply-To: <CAPDyKFq-R5u-cJruacApi3ZKfaQDshgCpdstTTMWgmg9fH4N3Q@mail.gmail.com>
References: <1364936979-20805-1-git-send-email-ulf.hansson@stericsson.com>
 <1364936979-20805-4-git-send-email-ulf.hansson@stericsson.com>
 <CA+Z25wWi7S1fcTmhs=63sOVbzjN9q8rtNJF67eNCLT70YZpPFw@mail.gmail.com>
 <CAPDyKFq-R5u-cJruacApi3ZKfaQDshgCpdstTTMWgmg9fH4N3Q@mail.gmail.com>
Message-ID: <CA+Z25wUkqY06HfLUmaSFndQOoXMHdkCXPOcNxe6hhFGst7pQ4g@mail.gmail.com>

On 5 April 2013 00:58, Ulf Hansson <ulf.hansson at linaro.org> wrote:
> On 4 April 2013 12:35, Rajagopal Venkat <rajagopal.venkat at linaro.org> wrote:
>> On 3 April 2013 02:39, Ulf Hansson <ulf.hansson at stericsson.com> wrote:
>>> From: Ulf Hansson <ulf.hansson at linaro.org>

Sorry for the delayed response.

>>>
>>> Updating the clock tree topology must be protected with the spinlock
>>> when doing clk_set_parent, otherwise we can not handle the migration
>>> of the enable_count in a safe manner.
>>
>> Why is not safe to update tree topology with no spinlock?
>
> clk_enable|disable propagates upwards in the tree. While in the middle
> of changing parents, you could end up in operating on more than one
> parent. This must be prevented and is done by holding the enable lock.

I see.

>
>>
>>>
>>> While issuing the .set_parent callback to make the clk-hw perform the
>>> switch to the new parent, we can not hold the spinlock since it is must
>>> be allowed to be slow path. This complicates error handling, but is still
>>> possible to achieve.
>>>
>>> Signed-off-by: Ulf Hansson <ulf.hansson at linaro.org>
>>> Cc: Rajagopal Venkat <rajagopal.venkat at linaro.org>
>>> ---
>>>  drivers/clk/clk.c |   67 +++++++++++++++++++++++++++++++++++++++++------------
>>>  1 file changed, 52 insertions(+), 15 deletions(-)
>>>
>>> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
>>> index c83e8e5..de6b459 100644
>>> --- a/drivers/clk/clk.c
>>> +++ b/drivers/clk/clk.c
>>> @@ -1363,31 +1363,71 @@ static int __clk_set_parent(struct clk *clk, struct clk *parent, u8 p_index)
>>>         unsigned long flags;
>>>         int ret = 0;
>>>         struct clk *old_parent = clk->parent;
>>> +       bool migrated_enable = false;
>>>
>>> -       /* migrate prepare and enable */
>>> +       /* migrate prepare */
>>>         if (clk->prepare_count)
>>>                 __clk_prepare(parent);
>>>
>>> -       /* FIXME replace with clk_is_enabled(clk) someday */
>>>         flags = clk_enable_lock();
>>> -       if (clk->enable_count)
>>> +
>>> +       /* migrate enable */
>>> +       if (clk->enable_count) {
>>>                 __clk_enable(parent);
>>> +               migrated_enable = true;
>>> +       }
>>> +
>>> +       /* update the clk tree topology */
>>> +       clk_reparent(clk, parent);
>>> +
>>>         clk_enable_unlock(flags);
>>>
>>>         /* change clock input source */
>>>         if (parent && clk->ops->set_parent)
>>>                 ret = clk->ops->set_parent(clk->hw, p_index);
>>>
>>> -       /* clean up old prepare and enable */
>>> -       flags = clk_enable_lock();
>>> -       if (clk->enable_count)
>>> +       if (ret) {
>>> +               /*
>>> +                * The error handling is tricky due to that we need to release
>>> +                * the spinlock while issuing the .set_parent callback. This
>>> +                * means the new parent might have been enabled/disabled in
>>
>> But then new parent is reference counted with  __clk_enable(parent)
>> isn't it? Even if other children are disabling newparent, it is still
>> alive. Am I missing anything here?
>
> Since we have released and later fetched the enable_lock, the clk
> might very well have been enabled|disabled in between. Thus we can not
> solely trust the enable count.

I am confused here. The code comments talks about new parent, "This
means the new parent might have been enabled/disabled in between". But
your review comments talks about clk in consideration which I agree.
Please update the comments.

>
> If we have migrated the enable, we need to keep track of this so we
> can roll back that change.
>
>>
>>> +                * between, which must be considered when doing rollback.
>>> +                */
>>> +               flags = clk_enable_lock();
>>> +
>>> +               clk_reparent(clk, old_parent);
>>> +
>>> +               if (migrated_enable && clk->enable_count) {
>>> +                       __clk_disable(parent);
>>> +               } else if (migrated_enable && (clk->enable_count == 0)) {
>>
>> Will this condition happen at all? the reference counting should
>> prevent this AFAICT. Can this error path be simplified?
>
> I am trying to handle the scenarios described below. If you think we
> can simplify error handling please advise me, I know the code looks a
> bit tricky.
>
> Scenario 1 (migration done):
>
> 1. Fetch enable_lock.
> 2. clk->enable_count is > 0, so we decide to migrate it for the new parent.
> 3. Update clock tree topology.

How about detaching clk subtree from old parent and attaching to
orphan list while in transition. Depending on clk->ops->set_parent()
outcome, attach the clk subtree to either new/old parent. I haven't
thought much about it, check if this helps.

> 4. Release enable_lock.
>
> 5 a. A client does clk_disable(clk) and clk->enable_count reaches 0.
> Then a reference to the new parent will also be decreased.
> 5 b. A client does clk_enable(clk) so clk->enable_count is still > 0.
> This means no reference change is propagated to the new parent.
>
> 6.  clk->ops->set_parent fails, we need error handling.
> - If 5a, we need to decrease a reference for the old parent to reflect
> that clk->enable_count has reached 0.
> - If 5b, we need to revert the increased reference count for the new parent.
>
>
> Scenario 2 (no migration):
>
> 1. Fetch enable_lock.
> 2. clk->enable_count is 0, so no migration done.
> 3. Update clock tree topology.
> 4. Release enable_lock.
>
> 5. A client does clk_enable(clk) so clk->enable_count is > 0.  Then a
> reference to the new parent will also be increased.
>
> 6.  clk->ops->set_parent fails, we need error handling.
> - We need to revert the reference change on the new parent and instead
> transfer it to the old parent.
>
>>
>>> +                       __clk_disable(old_parent);
>>> +               } else if (!migrated_enable && clk->enable_count) {
>>> +                       __clk_disable(parent);
>>> +                       __clk_enable(old_parent);
>>> +               }
>>> +
>>> +               clk_enable_unlock(flags);
>>> +
>>> +               if (clk->prepare_count)
>>> +                       __clk_unprepare(parent);
>>> +
>>> +               return ret;
>>> +       }
>>> +
>>> +       /* clean up enable for old parent if migration was done */
>>> +       if (migrated_enable) {
>>
>> Reaching here, the old_parent should be disabled in any case. Is this
>> 'if (migrated_enable)' check required?
>
> Why is it disabled?
>
> Where did we decrease a reference to it?
>
>>
>>> +               flags = clk_enable_lock();
>>>                 __clk_disable(old_parent);
>>> -       clk_enable_unlock(flags);
>>> +               clk_enable_unlock(flags);
>>> +       }
>>>
>>> +       /* clean up prepare for old parent if migration was done */
>>>         if (clk->prepare_count)
>>>                 __clk_unprepare(old_parent);
>>>
>>> -       return ret;
>>> +       /* update debugfs with new clk tree topology */
>>> +       clk_debug_reparent(clk, parent);
>>> +       return 0;
>>>  }
>>>
>>>  /**
>>> @@ -1450,14 +1490,11 @@ int clk_set_parent(struct clk *clk, struct clk *parent)
>>>         /* do the re-parent */
>>>         ret = __clk_set_parent(clk, parent, p_index);
>>>
>>> -       /* propagate ABORT_RATE_CHANGE if .set_parent failed */
>>> -       if (ret) {
>>> +       /* propagate rate recalculation accordingly */
>>> +       if (ret)
>>>                 __clk_recalc_rates(clk, ABORT_RATE_CHANGE);
>>> -               goto out;
>>> -       }
>>> -
>>> -       /* propagate rate recalculation downstream */
>>> -       __clk_reparent(clk, parent);
>>> +       else
>>> +               __clk_recalc_rates(clk, POST_RATE_CHANGE);
>>>
>>>  out:
>>>         clk_prepare_unlock();
>>> --
>>> 1.7.10
>>>
>>
>>
>>
>> --
>> Regards,
>> Rajagopal
>
> Kind regards
> Ulf Hansson



-- 
Regards,
Rajagopal


From nsekhar at ti.com  Mon Apr 15 02:04:04 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Mon, 15 Apr 2013 11:34:04 +0530
Subject: [PATCH v5] ARM: davinci: da850: add EHRPWM & ECAP DT node
In-Reply-To: <1365595961-4060-1-git-send-email-avinashphilip@ti.com>
References: <1365595961-4060-1-git-send-email-avinashphilip@ti.com>
Message-ID: <516B9854.9080502@ti.com>

On 4/10/2013 5:42 PM, Philip Avinash wrote:
> Add da850 EHRPWM & ECAP DT node along with pin-mux details.
> Also adds OF_DEV_AUXDATA for EHRPWM & ECAP driver to use EHRPWM & ECAP
> clock.
> 
> Signed-off-by: Philip Avinash <avinashphilip at ti.com>

Looks good to me. Will try and see if this can make it to v3.10.

Thanks,
Sekhar


From thierry.reding at avionic-design.de  Mon Apr 15 02:04:44 2013
From: thierry.reding at avionic-design.de (Thierry Reding)
Date: Mon, 15 Apr 2013 08:04:44 +0200
Subject: Latest randconfig build errors
In-Reply-To: <CAF6AEGtbqT23bjniwmGP-PhcxRPk5Q9aDaWM-=vVgkVrvDbCaQ@mail.gmail.com>
References: <20130304095136.GI17833@n2100.arm.linux.org.uk>
 <20130304184649.GO11806@atomide.com>
 <CAF6AEGv=3453KKS9-8YAgHrxMMbNvLMvt0pz-=qdG+zcd-Trrw@mail.gmail.com>
 <20130413214539.GA32613@avionic-0098.mockup.avionic-design.de>
 <CAF6AEGtbqT23bjniwmGP-PhcxRPk5Q9aDaWM-=vVgkVrvDbCaQ@mail.gmail.com>
Message-ID: <20130415060444.GA7746@avionic-0098.mockup.avionic-design.de>

On Sun, Apr 14, 2013 at 12:29:46AM -0400, Rob Clark wrote:
> On Sat, Apr 13, 2013 at 5:45 PM, Thierry Reding
[...]
> > I had been thinking about this on and off for a while, but I haven't
> > come up with anything concrete. Ideally we could just have some kind of
> > event that userspace would listen for, so that new outputs can be
> > dynamically added and userspace informed about them. Last time I checked
> > most of the helpers assumed that the complete output configuration is
> > known when the DRM device is registered, so some major rework will be
> > required to efficiently make use of such dynamicity.
> 
> I'm less worried about the kernel re-work.. more worried about the
> fact that we have no way to know whether userspace knows to listen for
> this new event.  So anything down this path could, I think, be
> considered as breaking userspace.

Yes, that's probably true. Although the typical use-case would be that
the application would run on any of the detected outputs and if there is
none to begin with it will just fail. If there already is one, it will
try to use that instead and only fail to use a second one if it becomes
available.

> I think in the end, we need some way to have sort of "dummy"
> connectors for output drivers which might or might not be probed, so
> that from userspace perspective, non-present panels appear as displays
> that are not plugged in.

I can imagine that quite a few userspace programs will be broken by this
as well. For instance if you have an LVDS panel, I'm pretty sure people
will just assume that it can't be in a disconnected state and therefore
won't deal with that case.

From a driver's point of view this isn't all that different from the
case you're trying to solve now. You still need to find out which
outputs can eventually become available. But instead of waiting until
they do before registering the DRM device you'd have to create dummy
outputs and keep checking whether the device is actually there each time
somebody interacts with the output.

But maybe this case is different. For Tegra the problem is that some
outputs (such as HDMI) require other drivers to be loaded first because
they provide resources (regulators, GPIOs, ...) that the output drivers
require. All of the drivers use deferred probing to resolve this
dependency and we can be reasonably sure that eventually probing of the
output will succeed (and therefore the output will become available).
Postponing the DRM registration until that point doesn't hurt. From what
I understand your use-case is similar. You need to load drivers for
different panels based on a runtime decision. So the only thing you need
is to be able to postpone the DRM registration until the panel driver
has been loaded, right?

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130415/131aaef8/attachment-0001.sig>

From ohad at wizery.com  Mon Apr 15 02:11:26 2013
From: ohad at wizery.com (Ohad Ben-Cohen)
Date: Mon, 15 Apr 2013 09:11:26 +0300
Subject: [PATCH v9 1/6] rpmsg: Process all available messages in virtqueue
 callback
In-Reply-To: <13514BD7FAEBA745BBD7D8A672905C1431230582@DFLE12.ent.ti.com>
References: <1364521307-1219-1-git-send-email-rtivy@ti.com>
 <1364521307-1219-2-git-send-email-rtivy@ti.com>
 <CAK=WgbaCtACsvt9cqQmGqXsADFb_3bfnNKeWq9iijR2vkYVuQQ@mail.gmail.com>
 <13514BD7FAEBA745BBD7D8A672905C1431230345@DFLE12.ent.ti.com>
 <CAK=WgbbpJuh8M4FLEgQKzbOPadJFHO=gvpA2jVOrN5N1g=1f2w@mail.gmail.com>
 <13514BD7FAEBA745BBD7D8A672905C1431230582@DFLE12.ent.ti.com>
Message-ID: <CAK=WgbZeAqy_u0R_oOKn7ovE7Rqkj3sNcg2rwgMMXvJBGRFrsw@mail.gmail.com>

On Tue, Apr 9, 2013 at 11:56 PM, Tivy, Robert <rtivy at ti.com> wrote:
> This new function also uses an 'int err;', so the above line should not be removed.

Added, thanks!

> I added the above-mentioned 'int err;' to my tree's rpmsg_recv_single() and tested it out, it worked well.  So once that is corrected, you can add:
> Acked-by: Robert Tivy <rtivy at ti.com>

No need to add your Acked-by as you are the author :)

Applied - will show up in linux next soon, please check it out there.

Thanks,
Ohad.


From santosh.shilimkar at ti.com  Mon Apr 15 02:20:04 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Mon, 15 Apr 2013 11:50:04 +0530
Subject: [GIT PULL] ARM: OMAP5: hwmod, prm/cm data files and updates for
 3.10
In-Reply-To: <79CD15C6BA57404B839C016229A409A83EC55521@DBDE01.ent.ti.com>
References: <1363768852-18125-1-git-send-email-santosh.shilimkar@ti.com>
 <20130401170539.GK10155@atomide.com> <515BA76D.3000302@ti.com>
 <alpine.DEB.2.00.1304031146230.2616@utopia.booyaka.com>
 <515D6020.2030103@ti.com> <20130404165208.GI10155@atomide.com>
 <515DB110.9000503@ti.com> <515F00B8.3000501@ti.com>
 <79CD15C6BA57404B839C016229A409A83EC4A81D@DBDE01.ent.ti.com>
 <51654DC5.2040909@ti.com>
 <79CD15C6BA57404B839C016229A409A83EC55521@DBDE01.ent.ti.com>
Message-ID: <516B9C14.5070406@ti.com>

On Monday 15 April 2013 10:36 AM, Hiremath, Vaibhav wrote:
> 
>> -----Original Message-----
>> From: Shilimkar, Santosh
>> Sent: Wednesday, April 10, 2013 5:02 PM

[..]

>>>> From b95dd33fe59b8e77727eb3b1717d763bbf9a2893 Mon Sep 17 00:00:00
>> 2001
>>>> From: Sricharan R <r.sricharan at ti.com>
>>>> Date: Fri, 5 Apr 2013 20:39:12 +0530
>>>> Subject: [PATCH] ARM: AM33XX: hwmod data: Clean up the data file
>>>>
>>>> - The IO resource information like dma request lines, irq number and
>>>> ocp address space can be populated via dt blob. So such data can be
>>>> stripped
>>>> from SOC hwmod data file.
>>>>
>>>> - The devices like adc, mailbox, gpmc which are missing the device
>>>> tree bindings, hwmod data is not added since AM33XX is DT only
>> build.
>>>> When such devices add the dt bindings, respective hwmod data can be
>>>> added along with it.
>>>>
>>> This seems unnecessary churn to me. DT bindings for most of the
>> devices
>>> which you mentioned above are submitted and are at various stages of
>> review
>>> process.
>>>
>>> ADC:
>>>
>>> GPMC:
>>>
>>> PWM:
>>>
>> The modules are dropped as per what is going for 3.10 merge window.
>> Above 3 modules can be retained if the DT conversion patches are
>> under review and can go along with this patch most likely for 3.11.
>>
>>>
>>>> - The hwmod like firewall etc which are not useful are also dropped.
>>>>
>>>> This gets us around ~2000 loc of negative diff. Patch is boot tested
>> on
>>>> AM335X EVM.
>>>>
>>> I would not recommend to get into unnecessary code churn in the
>> future just
>>> to reduce temp Number of Lines of code. This will also kill our
>> autogeneration
>>> concept as well.
>>>
>> It doesn't break any concept. We just autogenrate what is *useful*
>> rather.
>> BTW, I didn't find any srcipt to auto-generate the AM33XX data so we
>> have
>> to manually do the updates. Can you send me a pointer if you have a
>> sript
>> for this. With script it is much simpler to clean-up the data.
>>
>>
>>> I would suggest you to just alone drop base-addr, irq and dma
>> references
>>> from hwmod entries.
>>>
>> That we are doing anyways. Apart from that we should also clean-up data
>> which is not used and useful. Why do you need unused data like firewall
>> and
>> friends ?
>>
>> So as I understood, you would like to keep the data for ADC, PWM and
>> GPMC
>> which is fine by me. We just need those DT bindings in place so that
>> they
>> go together. Who is following the DT patches for these ?
>>
>> Thanks for looking into it Vaibhav.
>>
> Are you planning to send updated version of this?
> I would rather prefer to review next version.
> 
> Please let me know if you need any help here.
> 
Yes :-)
It will be great if you take the patch forward and update it
based on the discussion.

Regards,
Santosh



From amit.daniel at samsung.com  Mon Apr 15 02:24:47 2013
From: amit.daniel at samsung.com (Amit Daniel Kachhap)
Date: Mon, 15 Apr 2013 11:54:47 +0530
Subject: [PATCH] cpufreq: exynos5440: Protect opp search calls with rcu lock
Message-ID: <1366007087-12090-1-git-send-email-amit.daniel@samsung.com>

As per the OPP library documentation(Documentation/power/opp.txt) all
opp find/get calls should be protected by rcu locks.

Signed-off-by: Amit Daniel Kachhap <amit.daniel at samsung.com>
---

This patch is created against linux-next tree and is suggested by
Nishanth Menon. (https://lkml.org/lkml/2013/4/12/119)

 drivers/cpufreq/exynos5440-cpufreq.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/drivers/cpufreq/exynos5440-cpufreq.c b/drivers/cpufreq/exynos5440-cpufreq.c
index ead7ed4..0c74018 100644
--- a/drivers/cpufreq/exynos5440-cpufreq.c
+++ b/drivers/cpufreq/exynos5440-cpufreq.c
@@ -120,11 +120,13 @@ static int init_div_table(void)
 	int i = 0;
 	struct opp *opp;
 
+	rcu_read_lock();
 	for (i = 0; freq_tbl[i].frequency != CPUFREQ_TABLE_END; i++) {
 
 		opp = opp_find_freq_exact(dvfs_info->dev,
 					freq_tbl[i].frequency * 1000, true);
 		if (IS_ERR(opp)) {
+			rcu_read_unlock();
 			dev_err(dvfs_info->dev,
 				"failed to find valid OPP for %u KHZ\n",
 				freq_tbl[i].frequency);
@@ -159,6 +161,7 @@ static int init_div_table(void)
 		__raw_writel(tmp, dvfs_info->base + XMU_PMU_P0_7 + 4 * i);
 	}
 
+	rcu_read_unlock();
 	return 0;
 }
 
-- 
1.7.1



From thomas.abraham at linaro.org  Mon Apr 15 02:27:25 2013
From: thomas.abraham at linaro.org (Thomas Abraham)
Date: Mon, 15 Apr 2013 11:57:25 +0530
Subject: [PATCH 3/7] ARM: exynos: add missing properties for combiner IRQs
In-Reply-To: <1365775405-115297-4-git-send-email-arnd@arndb.de>
References: <1365775405-115297-1-git-send-email-arnd@arndb.de>
 <1365775405-115297-4-git-send-email-arnd@arndb.de>
Message-ID: <CAJuYYwSJyDt7aBLyY0S8LUaGf9-VwuSeM_n3V1UuBzgTyDyTUQ@mail.gmail.com>

On 12 April 2013 19:33, Arnd Bergmann <arnd at arndb.de> wrote:
> The exynos combiner irqchip needs to find the parent interrupts
> and needs to know their number, so add the missing properties
> for exynos4 as they were already present for exynos5.
>
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> ---
>  arch/arm/boot/dts/exynos4210.dtsi | 1 +
>  arch/arm/boot/dts/exynos4212.dtsi | 9 +++++++++
>  arch/arm/boot/dts/exynos4412.dtsi | 9 +++++++++
>  3 files changed, 19 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos4210.dtsi b/arch/arm/boot/dts/exynos4210.dtsi
> index 15143bd..c102869 100644
> --- a/arch/arm/boot/dts/exynos4210.dtsi
> +++ b/arch/arm/boot/dts/exynos4210.dtsi
> @@ -41,6 +41,7 @@
>         };
>
>         combiner:interrupt-controller at 10440000 {
> +               combiner-nr = <16>;

The default value of the combiner-nr is case it is not specified is
16. The default value is documented in the bindings documentation.

>                 interrupts = <0 0 0>, <0 1 0>, <0 2 0>, <0 3 0>,
>                              <0 4 0>, <0 5 0>, <0 6 0>, <0 7 0>,
>                              <0 8 0>, <0 9 0>, <0 10 0>, <0 11 0>,
> diff --git a/arch/arm/boot/dts/exynos4212.dtsi b/arch/arm/boot/dts/exynos4212.dtsi
> index 36d4299..f83c3c1 100644
> --- a/arch/arm/boot/dts/exynos4212.dtsi
> +++ b/arch/arm/boot/dts/exynos4212.dtsi
> @@ -26,6 +26,15 @@
>                 cpu-offset = <0x8000>;
>         };
>
> +       interrupt-controller at 10440000 {
> +                combiner-nr = <18>;
> +               interrupts = <0 0 0>, <0 1 0>, <0 2 0>, <0 3 0>,
> +                            <0 4 0>, <0 5 0>, <0 6 0>, <0 7 0>,
> +                            <0 8 0>, <0 9 0>, <0 10 0>, <0 11 0>,
> +                            <0 12 0>, <0 13 0>, <0 14 0>, <0 15 0>,
> +                            <0 107 0>, <0 108 0>;
> +       };
> +
>         mct at 10050000 {
>                 compatible = "samsung,exynos4412-mct";
>                 reg = <0x10050000 0x800>;
> diff --git a/arch/arm/boot/dts/exynos4412.dtsi b/arch/arm/boot/dts/exynos4412.dtsi
> index d75c047..4cb657e 100644
> --- a/arch/arm/boot/dts/exynos4412.dtsi
> +++ b/arch/arm/boot/dts/exynos4412.dtsi
> @@ -26,6 +26,15 @@
>                 cpu-offset = <0x4000>;
>         };
>
> +       interrupt-controller at 10440000 {
> +               combiner-nr = <20>;
> +               interrupts = <0 0 0>, <0 1 0>, <0 2 0>, <0 3 0>,
> +                            <0 4 0>, <0 5 0>, <0 6 0>, <0 7 0>,
> +                            <0 8 0>, <0 9 0>, <0 10 0>, <0 11 0>,
> +                            <0 12 0>, <0 13 0>, <0 14 0>, <0 15 0>,
> +                            <0 107 0>, <0 108 0>>, <0 48 0>, <0 42 0>;

Extra '>' for <0 108 0> can be removed.

Reviewed-by: Thomas Abraham <thomas.abraham at linaro.org?

> +       };
> +
>         mct at 10050000 {
>                 compatible = "samsung,exynos4412-mct";
>                 reg = <0x10050000 0x800>;
> --
> 1.8.1.2
>


From ohad at wizery.com  Mon Apr 15 02:28:17 2013
From: ohad at wizery.com (Ohad Ben-Cohen)
Date: Mon, 15 Apr 2013 09:28:17 +0300
Subject: adding rpmsg.git to linux next
Message-ID: <CAK=WgbY=4rosYr2g3fYYk6WrqXjN7f=5Dk5+D-h3cWrOtVmNag@mail.gmail.com>

Hi Stephen,

Could you please add:

git://git.kernel.org/pub/scm/linux/kernel/git/ohad/rpmsg.git#for-next

to linux-next to include new stuff coming from Rob?

Thanks,
Ohad.


From thomas.abraham at linaro.org  Mon Apr 15 02:31:43 2013
From: thomas.abraham at linaro.org (Thomas Abraham)
Date: Mon, 15 Apr 2013 12:01:43 +0530
Subject: [PATCH 1/7] clk: exynos: prepare for multiplatform
In-Reply-To: <1365775405-115297-2-git-send-email-arnd@arndb.de>
References: <1365775405-115297-1-git-send-email-arnd@arndb.de>
 <1365775405-115297-2-git-send-email-arnd@arndb.de>
Message-ID: <CAJuYYwRfoU1y_3qbZtdhdyRugPD_QCYWr_LuesOXzq+-jmxouw@mail.gmail.com>

On 12 April 2013 19:33, Arnd Bergmann <arnd at arndb.de> wrote:
> The new common clock drivers for exynos are using compile
> time constants and soc_is_exynos* macros to provide backwards
> compatibility for pre-DT systems, which is not possible with
> multiplatform kernels. This moves all the necessary
> information back into platform code and removes the mach/*
> header inclusions.


Since kgene has submitted a patch to remove pre-dt Exynos support
which looks like it will be accepted, we could just remove the use of
soc_is_xyz() instead of continuing to support non-dt Exynos.

Thanks,
Thomas.


From ohad at wizery.com  Mon Apr 15 02:34:41 2013
From: ohad at wizery.com (Ohad Ben-Cohen)
Date: Mon, 15 Apr 2013 09:34:41 +0300
Subject: [PATCH v10 1/1] ARM: davinci: Add a remoteproc driver
 implementation for OMAP-L13x DSP
In-Reply-To: <1365542421-18589-1-git-send-email-rtivy@ti.com>
References: <1365542421-18589-1-git-send-email-rtivy@ti.com>
Message-ID: <CAK=WgbZPC6KdnsDLAcEd0YisXj1Jo7h3WG22AZ4NFaaB_i6Wsw@mail.gmail.com>

Hi Rob,

On Wed, Apr 10, 2013 at 12:20 AM, Robert Tivy <rtivy at ti.com> wrote:
> Adding a new remoteproc driver for OMAP-L13x DSP
>
> Signed-off-by: Robert Tivy <rtivy at ti.com>

Looks good, thanks! It's now applied (with some tiny changes) to
git://git.kernel.org/pub/scm/linux/kernel/git/ohad/remoteproc.git#for-next.

Sekhar, this for-next branch is immutable, feel free to merge it in
order to apply the davinci-specific patches.

Thanks,
Ohad.


From w at 1wt.eu  Mon Apr 15 02:35:37 2013
From: w at 1wt.eu (Willy Tarreau)
Date: Mon, 15 Apr 2013 08:35:37 +0200
Subject: net: mvneta: fix improper tx queue usage in mvneta_tx()
Message-ID: <20130415063537.GA26507@1wt.eu>

>From 4f2069c92a27790e6071dc2a80f92c166e0b0ca4 Mon Sep 17 00:00:00 2001
From: Willy Tarreau <w at 1wt.eu>
Date: Thu, 11 Apr 2013 23:00:37 +0200
Subject: net: mvneta: fix improper tx queue usage in mvneta_tx()

mvneta_tx() was using a static tx queue number causing crashes as
soon as a little bit of traffic was sent via the interface, because
it is normally expected that the same queue should be used as in
dev_queue_xmit().

As suggested by Ben Hutchings, let's use skb_get_queue_mapping() to
get the proper Tx queue number, and use alloc_etherdev_mqs() instead
of alloc_etherdev_mq() to create the queues.

Both my Mirabox and my OpenBlocks AX3 used to crash without this patch
and don't anymore with it. The issue appeared in 3.8 but became more
visible after the fix allowing GSO to be enabled.

Original work was done by Dmitri Epshtein and Thomas Petazzoni. I
just adapted it to take care of Ben's comments.

Signed-off-by: Willy Tarreau <w at 1wt.eu>
Cc: Dmitri Epshtein <dima at marvell.com>
Cc: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Cc: Gregory CLEMENT <gregory.clement at free-electrons.com>
Cc: Ben Hutchings <bhutchings at solarflare.com>
---
 drivers/net/ethernet/marvell/mvneta.c | 9 ++++-----
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
index 1e628ce..a47a097 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -374,7 +374,6 @@ static int rxq_number = 8;
 static int txq_number = 8;
 
 static int rxq_def;
-static int txq_def;
 
 #define MVNETA_DRIVER_NAME "mvneta"
 #define MVNETA_DRIVER_VERSION "1.0"
@@ -1475,7 +1474,8 @@ error:
 static int mvneta_tx(struct sk_buff *skb, struct net_device *dev)
 {
 	struct mvneta_port *pp = netdev_priv(dev);
-	struct mvneta_tx_queue *txq = &pp->txqs[txq_def];
+	u16 txq_id = skb_get_queue_mapping(skb);
+	struct mvneta_tx_queue *txq = &pp->txqs[txq_id];
 	struct mvneta_tx_desc *tx_desc;
 	struct netdev_queue *nq;
 	int frags = 0;
@@ -1485,7 +1485,7 @@ static int mvneta_tx(struct sk_buff *skb, struct net_device *dev)
 		goto out;
 
 	frags = skb_shinfo(skb)->nr_frags + 1;
-	nq    = netdev_get_tx_queue(dev, txq_def);
+	nq    = netdev_get_tx_queue(dev, txq_id);
 
 	/* Get a descriptor for the first part of the packet */
 	tx_desc = mvneta_txq_next_desc_get(txq);
@@ -2689,7 +2689,7 @@ static int mvneta_probe(struct platform_device *pdev)
 		return -EINVAL;
 	}
 
-	dev = alloc_etherdev_mq(sizeof(struct mvneta_port), 8);
+	dev = alloc_etherdev_mqs(sizeof(struct mvneta_port), txq_number, rxq_number);
 	if (!dev)
 		return -ENOMEM;
 
@@ -2844,4 +2844,3 @@ module_param(rxq_number, int, S_IRUGO);
 module_param(txq_number, int, S_IRUGO);
 
 module_param(rxq_def, int, S_IRUGO);
-module_param(txq_def, int, S_IRUGO);
-- 
1.7.12.2.21.g234cd45.dirty



From prabhakar.csengg at gmail.com  Mon Apr 15 02:42:39 2013
From: prabhakar.csengg at gmail.com (Prabhakar Lad)
Date: Mon, 15 Apr 2013 12:12:39 +0530
Subject: Query on pinctrl usage for DT nodes
In-Reply-To: <CA+V-a8syL4YCddiz5W4dEhAhQjFo07_Hg+J6TN94cuPV7SQGag@mail.gmail.com>
References: <CA+V-a8uiPwsAD--OHFAE=i2ed+-wbXm4p2deZXr92+Zv6GDS1w@mail.gmail.com>
 <515C5C76.3080009@wwwdotorg.org>
 <CA+V-a8t3wtP77DdeUoQHKMjAuWmV+ude+1J3UjJmMTqobgStjA@mail.gmail.com>
 <5162FD4A.1030909@wwwdotorg.org>
 <CA+V-a8vwdCkyMqiynj5BodXbjwJ=e4qNb-29FhLweqbjc7DBQA@mail.gmail.com>
 <5165A22B.4070200@wwwdotorg.org> <20130410203408.GP10155@atomide.com>
 <CA+V-a8syL4YCddiz5W4dEhAhQjFo07_Hg+J6TN94cuPV7SQGag@mail.gmail.com>
Message-ID: <CA+V-a8tmOd_r3Ry=udMeioFq3JuNXqNvWmhLhp-2XLyAy+PFCA@mail.gmail.com>

Hi Tony,

On Mon, Apr 15, 2013 at 10:39 AM, Prabhakar Lad
<prabhakar.csengg at gmail.com> wrote:
> Hi Tony,
>
> On Thu, Apr 11, 2013 at 2:04 AM, Tony Lindgren <tony at atomide.com> wrote:
>> * Stephen Warren <swarren at wwwdotorg.org> [130410 10:37]:
>>> On 04/10/2013 02:12 AM, Prabhakar Lad wrote:
>>> ...
>>> > Following is the proposed fix/hack let me know if its OK.
>>> >
>>> > Regards,
>>> > --Prabhakar
>>> >
>>> > ->>>>>>>>>>>>>>>>>>>
>>> >
>>> > diff --git a/drivers/pinctrl/core.h b/drivers/pinctrl/core.h
>>> > index ee72f1f..78fb42d 100644
>>> > --- a/drivers/pinctrl/core.h
>>> > +++ b/drivers/pinctrl/core.h
>>> > @@ -46,6 +46,7 @@ struct pinctrl_dev {
>>> >         struct pinctrl *p;
>>> >         struct pinctrl_state *hog_default;
>>> >         struct pinctrl_state *hog_sleep;
>>> > +       bool bits_per_mux;
>>>
>>> This clearly isn't correct; any change to solve this problem should only
>>> touch the internals of the pinctrl-single driver, not the pinctrl core.
>>
>> Yeah how about just change the pintctrl-single,bits register
>> naming to be register + bit?  Something like 0xdeadbeef.0 and
>> 0xdeadbeef.1 and so on.
>>
> How and where the changing the register naming would help ?
>
No matter we change the register name, it would fail in pin_request()
function, see the following code snippet

static int pin_request(struct pinctrl_dev *pctldev,
		       int pin, const char *owner,
		       struct pinctrl_gpio_range *gpio_range)
{
	struct pin_desc *desc;
	const struct pinmux_ops *ops = pctldev->desc->pmxops;
	int status = -EINVAL;

	desc = pin_desc_get(pctldev, pin);
	if (desc == NULL) {
		dev_err(pctldev->dev,
			"pin %d is not registered so it cannot be requested\n",
			pin);
		goto out;
	}

	dev_dbg(pctldev->dev, "request pin %d (%s) for %s\n",
		pin, desc->name, owner);

	if (gpio_range) {
		/* There's no need to support multiple GPIO requests */
		if (desc->gpio_owner) {
			dev_err(pctldev->dev,
				"pin %s already requested by %s; cannot claim for %s\n",
				desc->name, desc->gpio_owner, owner);
			goto out;
		}

		desc->gpio_owner = owner;
	} else {
		if (desc->mux_usecount && strcmp(desc->mux_owner, owner)) {
			dev_err(pctldev->dev,
				"pin %s already requested by %s; cannot claim for %s\n",
				desc->name, desc->mux_owner, owner);
			goto out;
		}

		desc->mux_usecount++;
		if (desc->mux_usecount > 1)
			return 0;

		desc->mux_owner = owner;
	}

      ...........
}

Since desc->mux_owner and owner would obviously differ.

Regards,
--Prabhakar

> Regards,
> --Prabhakar
>
>> Regards,
>>
>> Tony


From sachin.kamat at linaro.org  Mon Apr 15 02:43:31 2013
From: sachin.kamat at linaro.org (Sachin Kamat)
Date: Mon, 15 Apr 2013 12:13:31 +0530
Subject: [PATCH 3/7] ARM: exynos: add missing properties for combiner IRQs
In-Reply-To: <1365775405-115297-4-git-send-email-arnd@arndb.de>
References: <1365775405-115297-1-git-send-email-arnd@arndb.de>
 <1365775405-115297-4-git-send-email-arnd@arndb.de>
Message-ID: <CAK9yfHzubnyo7wD4gmmjLobkoy2qPXWyPp-0GQq8wiJH1PWZTg@mail.gmail.com>

On 12 April 2013 19:33, Arnd Bergmann <arnd at arndb.de> wrote:
> The exynos combiner irqchip needs to find the parent interrupts
> and needs to know their number, so add the missing properties
> for exynos4 as they were already present for exynos5.
>
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> ---
>  arch/arm/boot/dts/exynos4210.dtsi | 1 +
>  arch/arm/boot/dts/exynos4212.dtsi | 9 +++++++++
>  arch/arm/boot/dts/exynos4412.dtsi | 9 +++++++++
>  3 files changed, 19 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos4210.dtsi b/arch/arm/boot/dts/exynos4210.dtsi
> index 15143bd..c102869 100644
> --- a/arch/arm/boot/dts/exynos4210.dtsi
> +++ b/arch/arm/boot/dts/exynos4210.dtsi
> @@ -41,6 +41,7 @@
>         };
>
>         combiner:interrupt-controller at 10440000 {
> +               combiner-nr = <16>;

I think this should be "samsung,combiner-nr"
Without this i see the following message in boot log:
"combiner_of_init: number of combiners not specified"

>                 interrupts = <0 0 0>, <0 1 0>, <0 2 0>, <0 3 0>,
>                              <0 4 0>, <0 5 0>, <0 6 0>, <0 7 0>,
>                              <0 8 0>, <0 9 0>, <0 10 0>, <0 11 0>,
> diff --git a/arch/arm/boot/dts/exynos4212.dtsi b/arch/arm/boot/dts/exynos4212.dtsi
> index 36d4299..f83c3c1 100644
> --- a/arch/arm/boot/dts/exynos4212.dtsi
> +++ b/arch/arm/boot/dts/exynos4212.dtsi
> @@ -26,6 +26,15 @@
>                 cpu-offset = <0x8000>;
>         };
>
> +       interrupt-controller at 10440000 {

Don't we need a node name here (combiner:interrupt-controller at 10440000)?

> +                combiner-nr = <18>;
    ^^^^^^^^^^^
nit: tabs instead of space would look better.

> +               interrupts = <0 0 0>, <0 1 0>, <0 2 0>, <0 3 0>,
> +                            <0 4 0>, <0 5 0>, <0 6 0>, <0 7 0>,
> +                            <0 8 0>, <0 9 0>, <0 10 0>, <0 11 0>,
> +                            <0 12 0>, <0 13 0>, <0 14 0>, <0 15 0>,
> +                            <0 107 0>, <0 108 0>;
> +       };
> +
>         mct at 10050000 {
>                 compatible = "samsung,exynos4412-mct";
>                 reg = <0x10050000 0x800>;
> diff --git a/arch/arm/boot/dts/exynos4412.dtsi b/arch/arm/boot/dts/exynos4412.dtsi
> index d75c047..4cb657e 100644
> --- a/arch/arm/boot/dts/exynos4412.dtsi
> +++ b/arch/arm/boot/dts/exynos4412.dtsi
> @@ -26,6 +26,15 @@
>                 cpu-offset = <0x4000>;
>         };
>
> +       interrupt-controller at 10440000 {
> +               combiner-nr = <20>;
Same as above (for exynos4212.dtsi).

> +               interrupts = <0 0 0>, <0 1 0>, <0 2 0>, <0 3 0>,
> +                            <0 4 0>, <0 5 0>, <0 6 0>, <0 7 0>,
> +                            <0 8 0>, <0 9 0>, <0 10 0>, <0 11 0>,
> +                            <0 12 0>, <0 13 0>, <0 14 0>, <0 15 0>,
> +                            <0 107 0>, <0 108 0>>, <0 48 0>, <0 42 0>;
                                                              ^^^
Syntax error.

We have a combiner node defined in exynos4x12.dtsi. With the bindings
now defined separately in 4212 and 4412 dtsi files, probably the one
in 4x12 could be dropped?


-- 
With warm regards,
Sachin


From cdall at cs.columbia.edu  Mon Apr 15 02:46:50 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Sun, 14 Apr 2013 23:46:50 -0700
Subject: [PATCH] ARM: KVM: fix unbalanced get_cpu() in access_dcsw
In-Reply-To: <4a199cdd4998480ed6ba3f1858698903@localhost>
References: <1365786828-548-1-git-send-email-marc.zyngier@arm.com>
 <20130412181332.GB5075@mudshark.cambridge.arm.com>
 <4a199cdd4998480ed6ba3f1858698903@localhost>
Message-ID: <20130415064650.GA44752@gmail.com>

On Fri, Apr 12, 2013 at 09:17:46PM +0200, Marc Zyngier wrote:
> On Fri, 12 Apr 2013 19:13:32 +0100, Will Deacon <will.deacon at arm.com>
> wrote:
> > On Fri, Apr 12, 2013 at 06:13:48PM +0100, Marc Zyngier wrote:
> >> In the very unlikely event where a guest would be foolish enough to
> >> *read* from a write-only cache maintainance register, we end up
> >> with preemption disabled, due to a misplaced get_cpu().
> >> 
> >> Just move the "is_write" test outside of the critical section.
> >> 
> >> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> > 
> > I found it second time around!
> > 
> >   Reported-by: Will Deacon <will.deacon at arm.com>
> 
> Indeed you did! :-)
> 
> I'll add that to the commit, and on a couple of other as well...

I applied the patch and added the tag, thanks.

-Christoffer


From cdall at cs.columbia.edu  Mon Apr 15 02:51:55 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Sun, 14 Apr 2013 23:51:55 -0700
Subject: [PATCH v3 5/7] ARM: KVM: rework HYP page table freeing
In-Reply-To: <1365779932-20322-6-git-send-email-marc.zyngier@arm.com>
References: <1365779932-20322-1-git-send-email-marc.zyngier@arm.com>
 <1365779932-20322-6-git-send-email-marc.zyngier@arm.com>
Message-ID: <CAEDV+gJAUOsi3yjwp3hmBPbLkaL_0PaUNGFLLZN0nOzya7BA-A@mail.gmail.com>

On Fri, Apr 12, 2013 at 8:18 AM, Marc Zyngier <marc.zyngier at arm.com> wrote:
> There is no point in freeing HYP page tables differently from Stage-2.
> They now have the same requirements, and should be dealt with the same way.
>
> Promote unmap_stage2_range to be The One True Way, and get rid of a number
> of nasty bugs in the process (goo thing we never actually called free_hyp_pmds

could you remind me, did you already point out these nasty bugs
somewhere or did we discuss them in an older thread?

nit: s/goo/good/

> before...).
>
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> ---
>  arch/arm/include/asm/kvm_mmu.h |   2 +-
>  arch/arm/kvm/arm.c             |   2 +-
>  arch/arm/kvm/mmu.c             | 181 ++++++++++++++++++-----------------------
>  3 files changed, 82 insertions(+), 103 deletions(-)
>
> diff --git a/arch/arm/include/asm/kvm_mmu.h b/arch/arm/include/asm/kvm_mmu.h
> index 3c71a1d..92eb20d 100644
> --- a/arch/arm/include/asm/kvm_mmu.h
> +++ b/arch/arm/include/asm/kvm_mmu.h
> @@ -32,7 +32,7 @@
>
>  int create_hyp_mappings(void *from, void *to);
>  int create_hyp_io_mappings(void *from, void *to, phys_addr_t);
> -void free_hyp_pmds(void);
> +void free_hyp_pgds(void);
>
>  int kvm_alloc_stage2_pgd(struct kvm *kvm);
>  void kvm_free_stage2_pgd(struct kvm *kvm);
> diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
> index 23538ed..8992f05 100644
> --- a/arch/arm/kvm/arm.c
> +++ b/arch/arm/kvm/arm.c
> @@ -937,7 +937,7 @@ static int init_hyp_mode(void)
>  out_free_context:
>         free_percpu(kvm_host_cpu_state);
>  out_free_mappings:
> -       free_hyp_pmds();
> +       free_hyp_pgds();
>  out_free_stack_pages:
>         for_each_possible_cpu(cpu)
>                 free_page(per_cpu(kvm_arm_hyp_stack_page, cpu));
> diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
> index bfc5927..7464824 100644
> --- a/arch/arm/kvm/mmu.c
> +++ b/arch/arm/kvm/mmu.c
> @@ -72,56 +72,104 @@ static void *mmu_memory_cache_alloc(struct kvm_mmu_memory_cache *mc)
>         return p;
>  }
>
> -static void free_ptes(pmd_t *pmd, unsigned long addr)
> +static void clear_pud_entry(pud_t *pud)
>  {
> -       pte_t *pte;
> -       unsigned int i;
> +       pmd_t *pmd_table = pmd_offset(pud, 0);
> +       pud_clear(pud);
> +       pmd_free(NULL, pmd_table);
> +       put_page(virt_to_page(pud));
> +}
>
> -       for (i = 0; i < PTRS_PER_PMD; i++, addr += PMD_SIZE) {
> -               if (!pmd_none(*pmd) && pmd_table(*pmd)) {
> -                       pte = pte_offset_kernel(pmd, addr);
> -                       pte_free_kernel(NULL, pte);
> -               }
> -               pmd++;
> +static void clear_pmd_entry(pmd_t *pmd)
> +{
> +       pte_t *pte_table = pte_offset_kernel(pmd, 0);
> +       pmd_clear(pmd);
> +       pte_free_kernel(NULL, pte_table);
> +       put_page(virt_to_page(pmd));
> +}
> +
> +static bool pmd_empty(pmd_t *pmd)
> +{
> +       struct page *pmd_page = virt_to_page(pmd);
> +       return page_count(pmd_page) == 1;
> +}
> +
> +static void clear_pte_entry(pte_t *pte)
> +{
> +       if (pte_present(*pte)) {
> +               kvm_set_pte(pte, __pte(0));
> +               put_page(virt_to_page(pte));
>         }
>  }
>
> -static void free_hyp_pgd_entry(unsigned long addr)
> +static bool pte_empty(pte_t *pte)
> +{
> +       struct page *pte_page = virt_to_page(pte);
> +       return page_count(pte_page) == 1;
> +}
> +
> +static void unmap_range(pgd_t *pgdp, unsigned long long start, u64 size)
>  {
>         pgd_t *pgd;
>         pud_t *pud;
>         pmd_t *pmd;
> -       unsigned long hyp_addr = KERN_TO_HYP(addr);
> +       pte_t *pte;
> +       unsigned long long addr = start, end = start + size;
> +       u64 range;
>
> -       pgd = hyp_pgd + pgd_index(hyp_addr);
> -       pud = pud_offset(pgd, hyp_addr);
> +       while (addr < end) {
> +               pgd = pgdp + pgd_index(addr);
> +               pud = pud_offset(pgd, addr);
> +               if (pud_none(*pud)) {
> +                       addr += PUD_SIZE;
> +                       continue;
> +               }
>
> -       if (pud_none(*pud))
> -               return;
> -       BUG_ON(pud_bad(*pud));
> +               pmd = pmd_offset(pud, addr);
> +               if (pmd_none(*pmd)) {
> +                       addr += PMD_SIZE;
> +                       continue;
> +               }
>
> -       pmd = pmd_offset(pud, hyp_addr);
> -       free_ptes(pmd, addr);
> -       pmd_free(NULL, pmd);
> -       pud_clear(pud);
> +               pte = pte_offset_kernel(pmd, addr);
> +               clear_pte_entry(pte);
> +               range = PAGE_SIZE;
> +
> +               /* If we emptied the pte, walk back up the ladder */
> +               if (pte_empty(pte)) {
> +                       clear_pmd_entry(pmd);
> +                       range = PMD_SIZE;
> +                       if (pmd_empty(pmd)) {
> +                               clear_pud_entry(pud);
> +                               range = PUD_SIZE;
> +                       }
> +               }
> +
> +               addr += range;
> +       }
>  }
>
>  /**
> - * free_hyp_pmds - free a Hyp-mode level-2 tables and child level-3 tables
> + * free_hyp_pgds - free Hyp-mode page tables
>   *
> - * Assumes this is a page table used strictly in Hyp-mode and therefore contains
> + * Assumes hyp_pgd is a page table used strictly in Hyp-mode and therefore contains
>   * either mappings in the kernel memory area (above PAGE_OFFSET), or
>   * device mappings in the vmalloc range (from VMALLOC_START to VMALLOC_END).
>   */
> -void free_hyp_pmds(void)
> +void free_hyp_pgds(void)
>  {
>         unsigned long addr;
>
>         mutex_lock(&kvm_hyp_pgd_mutex);
> -       for (addr = PAGE_OFFSET; virt_addr_valid(addr); addr += PGDIR_SIZE)
> -               free_hyp_pgd_entry(addr);
> -       for (addr = VMALLOC_START; is_vmalloc_addr((void*)addr); addr += PGDIR_SIZE)
> -               free_hyp_pgd_entry(addr);
> +
> +       if (hyp_pgd) {
> +               for (addr = PAGE_OFFSET; virt_addr_valid(addr); addr += PGDIR_SIZE)
> +                       unmap_range(hyp_pgd, KERN_TO_HYP(addr), PGDIR_SIZE);
> +               for (addr = VMALLOC_START; is_vmalloc_addr((void*)addr); addr += PGDIR_SIZE)
> +                       unmap_range(hyp_pgd, KERN_TO_HYP(addr), PGDIR_SIZE);
> +               kfree(hyp_pgd);
> +       }
> +
>         mutex_unlock(&kvm_hyp_pgd_mutex);
>  }
>
> @@ -136,6 +184,7 @@ static void create_hyp_pte_mappings(pmd_t *pmd, unsigned long start,
>         do {
>                 pte = pte_offset_kernel(pmd, addr);
>                 kvm_set_pte(pte, pfn_pte(pfn, prot));
> +               get_page(virt_to_page(pte));
>                 pfn++;
>         } while (addr += PAGE_SIZE, addr != end);
>  }
> @@ -161,6 +210,7 @@ static int create_hyp_pmd_mappings(pud_t *pud, unsigned long start,
>                                 return -ENOMEM;
>                         }
>                         pmd_populate_kernel(NULL, pmd, pte);
> +                       get_page(virt_to_page(pmd));
>                 }
>
>                 next = pmd_addr_end(addr, end);
> @@ -197,6 +247,7 @@ static int __create_hyp_mappings(pgd_t *pgdp,
>                                 goto out;
>                         }
>                         pud_populate(NULL, pud, pmd);
> +                       get_page(virt_to_page(pud));
>                 }
>
>                 next = pgd_addr_end(addr, end);
> @@ -289,42 +340,6 @@ int kvm_alloc_stage2_pgd(struct kvm *kvm)
>         return 0;
>  }
>
> -static void clear_pud_entry(pud_t *pud)
> -{
> -       pmd_t *pmd_table = pmd_offset(pud, 0);
> -       pud_clear(pud);
> -       pmd_free(NULL, pmd_table);
> -       put_page(virt_to_page(pud));
> -}
> -
> -static void clear_pmd_entry(pmd_t *pmd)
> -{
> -       pte_t *pte_table = pte_offset_kernel(pmd, 0);
> -       pmd_clear(pmd);
> -       pte_free_kernel(NULL, pte_table);
> -       put_page(virt_to_page(pmd));
> -}
> -
> -static bool pmd_empty(pmd_t *pmd)
> -{
> -       struct page *pmd_page = virt_to_page(pmd);
> -       return page_count(pmd_page) == 1;
> -}
> -
> -static void clear_pte_entry(pte_t *pte)
> -{
> -       if (pte_present(*pte)) {
> -               kvm_set_pte(pte, __pte(0));
> -               put_page(virt_to_page(pte));
> -       }
> -}
> -
> -static bool pte_empty(pte_t *pte)
> -{
> -       struct page *pte_page = virt_to_page(pte);
> -       return page_count(pte_page) == 1;
> -}
> -
>  /**
>   * unmap_stage2_range -- Clear stage2 page table entries to unmap a range
>   * @kvm:   The VM pointer
> @@ -338,43 +353,7 @@ static bool pte_empty(pte_t *pte)
>   */
>  static void unmap_stage2_range(struct kvm *kvm, phys_addr_t start, u64 size)
>  {
> -       pgd_t *pgd;
> -       pud_t *pud;
> -       pmd_t *pmd;
> -       pte_t *pte;
> -       phys_addr_t addr = start, end = start + size;
> -       u64 range;
> -
> -       while (addr < end) {
> -               pgd = kvm->arch.pgd + pgd_index(addr);
> -               pud = pud_offset(pgd, addr);
> -               if (pud_none(*pud)) {
> -                       addr += PUD_SIZE;
> -                       continue;
> -               }
> -
> -               pmd = pmd_offset(pud, addr);
> -               if (pmd_none(*pmd)) {
> -                       addr += PMD_SIZE;
> -                       continue;
> -               }
> -
> -               pte = pte_offset_kernel(pmd, addr);
> -               clear_pte_entry(pte);
> -               range = PAGE_SIZE;
> -
> -               /* If we emptied the pte, walk back up the ladder */
> -               if (pte_empty(pte)) {
> -                       clear_pmd_entry(pmd);
> -                       range = PMD_SIZE;
> -                       if (pmd_empty(pmd)) {
> -                               clear_pud_entry(pud);
> -                               range = PUD_SIZE;
> -                       }
> -               }
> -
> -               addr += range;
> -       }
> +       unmap_range(kvm->arch.pgd, start, size);
>  }
>
>  /**
> @@ -741,7 +720,7 @@ int kvm_mmu_init(void)
>
>         return 0;
>  out:
> -       kfree(hyp_pgd);
> +       free_hyp_pgds();
>         return err;
>  }
>
> --
> 1.8.1.4
>
>
>
> _______________________________________________
> kvmarm mailing list
> kvmarm at lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm


From sebastian.hesselbarth at gmail.com  Mon Apr 15 02:59:46 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Mon, 15 Apr 2013 08:59:46 +0200
Subject: [PATCH RESEND] clk: export __clk_get_flags for modular clock providers
Message-ID: <1366009186-32199-1-git-send-email-sebastian.hesselbarth@gmail.com>

The common clock api provides some helpers for clk-providers but does
not export these helpers. This hinders clk-providers to be built as modules.
This patch adds __clk_get_flags() to the list of exported symbols.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
---
Cc: Mike Turquette <mturquette at linaro.org>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
---
 drivers/clk/clk.c |    1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index ed87b24..3e478b8 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -450,6 +450,7 @@ unsigned long __clk_get_flags(struct clk *clk)
 {
 	return !clk ? 0 : clk->flags;
 }
+EXPORT_SYMBOL_GPL(__clk_get_flags);
 
 bool __clk_is_enabled(struct clk *clk)
 {
-- 
1.7.10.4



From sebastian.hesselbarth at gmail.com  Mon Apr 15 03:00:14 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Mon, 15 Apr 2013 09:00:14 +0200
Subject: [PATCH] clk: si5351: make clk-si5351 depend on CONFIG_OF
Message-ID: <1366009214-32234-1-git-send-email-sebastian.hesselbarth@gmail.com>

Calling clk-si5351 driver non-OF ready was too early. This patch
makes clk-si5351 depend on CONFIG_OF again, until things get sorted out.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
Reported-by: Stephen Rottweil <sfr at canb.auug.org.au>
---
Cc: Stephen Rothwell <sfr at canb.auug.org.au>
Cc: Grant Likely <grant.likely at secretlab.ca>
Cc: Rob Herring <rob.herring at calxeda.com>
Cc: Rob Landley <rob at landley.net>
Cc: Mike Turquette <mturquette at linaro.org>
Cc: Stephen Warren <swarren at nvidia.com>
Cc: Thierry Reding <thierry.reding at avionic-design.de>
Cc: Dom Cobley <popcornmix at gmail.com>
Cc: Linus Walleij <linus.walleij at linaro.org>
Cc: Arnd Bergmann <arnd at arndb.de>
Cc: Andrew Morton <akpm at linux-foundation.org>
Cc: Pawel Moll <pawel.moll at arm.com>
Cc: Mark Brown <broonie at opensource.wolfsonmicro.com>
Cc: Russell King - ARM Linux <linux at arm.linux.org.uk>
Cc: Rabeeh Khoury <rabeeh at solid-run.com>
Cc: Daniel Mack <zonque at gmail.com>
Cc: Jean-Francois Moine <moinejf at free.fr>
Cc: Lars-Peter Clausen <lars at metafoo.de>
Cc: Guenter Roeck <linux at roeck-us.net>
Cc: Michal Bachraty <michal.bachraty at streamunlimited.com>
Cc: devicetree-discuss at lists.ozlabs.org
Cc: linux-doc at vger.kernel.org
Cc: linux-kernel at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
---
 drivers/clk/Kconfig |    1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 5039e41..6412f55 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -58,6 +58,7 @@ config COMMON_CLK_MAX77686
 config COMMON_CLK_SI5351
 	tristate "Clock driver for SiLabs 5351A/B/C"
 	depends on I2C
+	depends on OF
 	select REGMAP_I2C
 	select RATIONAL
 	---help---
-- 
1.7.10.4



From viresh.kumar at linaro.org  Mon Apr 15 03:02:59 2013
From: viresh.kumar at linaro.org (Viresh Kumar)
Date: Mon, 15 Apr 2013 12:32:59 +0530
Subject: [PATCH V2] cpufreq: ARM big LITTLE: Add generic cpufreq driver
 and its DT glue
In-Reply-To: <5169BC86.7010905@gmail.com>
References: <1f864ec505cae7c5daea3810a3c26e0f5cda38ea.1364290815.git.viresh.kumar@linaro.org>
 <5169BC86.7010905@gmail.com>
Message-ID: <CAKohpo=zGZzE7Fvj6zhdwNcnLGX0LN0jbpo+1goJz586N20cXw@mail.gmail.com>

On 14 April 2013 01:43, Francesco Lavra <francescolavra.fl at gmail.com> wrote:

>> +     for_each_child_of_node(of_find_node_by_path("/cpus"), np) {
>
> If of_find_node_by_path() returns NULL, there will be a NULL pointer
> dereference.
>
>> +             if (count++ != cpu_dev->id)
>> +                     continue;
>> +             if (!of_get_property(np, "operating-points", NULL))
>> +                     return -ENODATA;
>> +
>> +             cpu_dev->of_node = np;
>> +
>> +             ret = of_init_opp_table(cpu_dev);
>> +             if (ret)
>> +                     return ret;
>> +
>> +             return 0;
>
> of_node_put() should be called on np before returning.
> Also, the reference count of the parent node should be decremented as well.
>
> These comments apply to the below function dt_get_transition_latency() too.

Thanks Francesco.

Below fixes this (I will send it separately to Rafael):

Subject: [PATCH 1/2] cpufreq: ARM big LITTLE: put DT nodes after using them

DT nodes should be put using of_node_put() to balance their usage counts. This
is not done properly in ARM's big LITTLE driver. Fix it.

Signed-off-by: Viresh Kumar <viresh.kumar at linaro.org>
---
 drivers/cpufreq/arm_big_little_dt.c | 43 +++++++++++++++++++++++++------------
 1 file changed, 29 insertions(+), 14 deletions(-)

diff --git a/drivers/cpufreq/arm_big_little_dt.c
b/drivers/cpufreq/arm_big_little_dt.c
index 452ff46..44be311 100644
--- a/drivers/cpufreq/arm_big_little_dt.c
+++ b/drivers/cpufreq/arm_big_little_dt.c
@@ -31,22 +31,28 @@

 static int dt_init_opp_table(struct device *cpu_dev)
 {
-	struct device_node *np = NULL;
+	struct device_node *np, *parent;
 	int count = 0, ret;

-	for_each_child_of_node(of_find_node_by_path("/cpus"), np) {
+	parent = of_find_node_by_path("/cpus");
+	if (!parent) {
+		pr_err("failed to find OF /cpus\n");
+		return -ENOENT;
+	}
+
+	for_each_child_of_node(parent, np) {
 		if (count++ != cpu_dev->id)
 			continue;
-		if (!of_get_property(np, "operating-points", NULL))
-			return -ENODATA;
-
-		cpu_dev->of_node = np;
-
-		ret = of_init_opp_table(cpu_dev);
-		if (ret)
-			return ret;
-
-		return 0;
+		if (!of_get_property(np, "operating-points", NULL)) {
+			ret = -ENODATA;
+		} else {
+			cpu_dev->of_node = np;
+			ret = of_init_opp_table(cpu_dev);
+		}
+		of_node_put(np);
+		of_node_put(parent);
+
+		return ret;
 	}

 	return -ENODEV;
@@ -54,15 +60,24 @@ static int dt_init_opp_table(struct device *cpu_dev)

 static int dt_get_transition_latency(struct device *cpu_dev)
 {
-	struct device_node *np = NULL;
+	struct device_node *np, *parent;
 	u32 transition_latency = CPUFREQ_ETERNAL;
 	int count = 0;

-	for_each_child_of_node(of_find_node_by_path("/cpus"), np) {
+	parent = of_find_node_by_path("/cpus");
+	if (!parent) {
+		pr_err("failed to find OF /cpus\n");
+		return -ENOENT;
+	}
+
+	for_each_child_of_node(parent, np) {
 		if (count++ != cpu_dev->id)
 			continue;

 		of_property_read_u32(np, "clock-latency", &transition_latency);
+		of_node_put(np);
+		of_node_put(parent);
+
 		return 0;
 	}


From shc_work at mail.ru  Mon Apr 15 03:13:33 2013
From: shc_work at mail.ru (=?UTF-8?B?QWxleGFuZGVyIFNoaXlhbg==?=)
Date: Mon, 15 Apr 2013 11:13:33 +0400
Subject: =?UTF-8?B?UmVbMl06IFtQQVRDSCAxLzJdIEdQSU86IGNscHM3MTF4OiBSZXdyaXRlIGRy?=
 =?UTF-8?B?aXZlciBmb3IgdXNpbmcgZ2VuZXJpYyBHUElPIGNvZGU=?=
In-Reply-To: <20130415033324.GB10949@quad.lixom.net>
References: <1365826900-30136-1-git-send-email-shc_work@mail.ru>
 <20130415033324.GB10949@quad.lixom.net>
Message-ID: <1366010013.44756903@f279.mail.ru>

> On Sat, Apr 13, 2013 at 08:21:39AM +0400, Alexander Shiyan wrote:
> > This patch provides rewritten driver for CLPS711X GPIO which uses
> > generic GPIO code.
> > 
> > Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
> > ---
> >  arch/arm/configs/clps711x_defconfig            |   1 +
> >  arch/arm/mach-clps711x/Makefile                |   5 +-
> >  arch/arm/mach-clps711x/board-autcpu12.c        |   2 +
> >  arch/arm/mach-clps711x/board-cdb89712.c        |   2 +
> >  arch/arm/mach-clps711x/board-edb7211.c         |   7 +
> >  arch/arm/mach-clps711x/board-p720t.c           |  10 +-
> >  arch/arm/mach-clps711x/devices.c               |  56 ++++++
> >  arch/arm/mach-clps711x/devices.h               |  12 ++
> >  arch/arm/mach-clps711x/include/mach/clps711x.h |  23 +--
> >  drivers/gpio/Kconfig                           |   5 +-
> >  drivers/gpio/gpio-clps711x.c                   | 228 +++++++------------------
> >  11 files changed, 164 insertions(+), 187 deletions(-)
> >  create mode 100644 arch/arm/mach-clps711x/devices.c
> >  create mode 100644 arch/arm/mach-clps711x/devices.h
> 
> It would be nice to see this split up in a short series of patches instead,
> each patch doing one thing. For example, I'm not sure enabling the GPIO driver
> in the defconfig really belongs in the rewrite patch, for example.

New driver replaces arch_initcall by pure platform driver, so for keep working
defconfig should use symbol for driver.
Of course this change can be split into separate patch, but in this case series
will be marked not only for GPIO-sybsustem, if this OK, I will do as you say.

...
> >  static void __init edb7211_init(void)
> >  {
> > +	clps711x_devices_init();
> > +}
> > +
> > +static void __init edb7211_init_late(void)
> > +{
> 
> It'd be good for people reading the changelog in the future to see why you
> chose to split this up among two initcalls now.

OK. It makes sense.
We have some drivers (spi, backlight, nand) which depends on GPIO but not
use deferral probe yet, so at this point I just use separate initcalls for proper
loading sequence.

...
> > +static void __init clps711x_add_gpio(void)
> > +{
> > +	const struct resource clps711x_gpio0_res[] = {
> > +		DEFINE_RES_MEM(PADR, SZ_1),
> > +		DEFINE_RES_MEM(PADDR, SZ_1),
> > +	};
> > +	const struct resource clps711x_gpio1_res[] = {
> > +		DEFINE_RES_MEM(PBDR, SZ_1),
> > +		DEFINE_RES_MEM(PBDDR, SZ_1),
> > +	};
> > +	const struct resource clps711x_gpio2_res[] = {
> > +		DEFINE_RES_MEM(PCDR, SZ_1),
> > +		DEFINE_RES_MEM(PCDDR, SZ_1),
> > +	};
> > +	const struct resource clps711x_gpio3_res[] = {
> > +		DEFINE_RES_MEM(PDDR, SZ_1),
> > +		DEFINE_RES_MEM(PDDDR, SZ_1),
> > +	};
> > +	const struct resource clps711x_gpio4_res[] = {
> > +		DEFINE_RES_MEM(PEDR, SZ_1),
> > +		DEFINE_RES_MEM(PEDDR, SZ_1),
> > +	};
> 
> It's common to have the resources as static globals in the file instead of
> local const variables, so please move them out to stay common with other
> platforms.

AFAIK platform_device_add_resources makes a copy of all used resources,
is resource really need to be a global variable? Or you just mean make these
variables global and put in "__initconst" section?

...
> > --- a/arch/arm/mach-clps711x/include/mach/clps711x.h
> > +++ b/arch/arm/mach-clps711x/include/mach/clps711x.h
> > @@ -23,16 +23,19 @@
> >  
> >  #define CLPS711X_PHYS_BASE	(0x80000000)
> >  
> > -#define PADR		(0x0000)
> > -#define PBDR		(0x0001)
> > -#define PCDR		(0x0002)
> > -#define PDDR		(0x0003)
> > -#define PADDR		(0x0040)
> > -#define PBDDR		(0x0041)
> > -#define PCDDR		(0x0042)
> > -#define PDDDR		(0x0043)
> > -#define PEDR		(0x0083)
> > -#define PEDDR		(0x00c3)
> > +#define CLPS711X_REGS(x)	(CLPS711X_PHYS_BASE + (x))
> > +
> > +#define PADR		CLPS711X_REGS(0x0000)
> > +#define PBDR		CLPS711X_REGS(0x0001)
> > +#define PCDR		CLPS711X_REGS(0x0002)
> > +#define PDDR		CLPS711X_REGS(0x0003)
> > +#define PADDR		CLPS711X_REGS(0x0040)
> > +#define PBDDR		CLPS711X_REGS(0x0041)
> > +#define PCDDR		CLPS711X_REGS(0x0042)
> > +#define PDDDR		CLPS711X_REGS(0x0043)
> > +#define PEDR		CLPS711X_REGS(0x0083)
> > +#define PEDDR		CLPS711X_REGS(0x00c3)
> > +
> 
> Are these needed in a shared include file, or could they just be pushed out in
> the one driver that uses them? There's been a lot of churn moving mach includes
> out to drivers on multiplatform enabled platforms, it'd be nice to avoid adding
> more dependencies on it on legacy platforms that haven't yet been enabled (or
> even if they never will be, it still doesn't hurt).

This just an initial change for avoiding usage CLPS711X_PHYS_BASE in other code.
No new global users for this header.
As you can view in GPIO driver, I remove dependency on <mach/hardware.h> completely.

...
> > diff --git a/drivers/gpio/gpio-clps711x.c b/drivers/gpio/gpio-clps711x.c
> > index ce63b75..3c71815 100644
> > --- a/drivers/gpio/gpio-clps711x.c
> > +++ b/drivers/gpio/gpio-clps711x.c
...
> > -#include <linux/io.h>
> > -#include <linux/slab.h>
> >  #include <linux/gpio.h>
> >  #include <linux/module.h>
> > -#include <linux/spinlock.h>
> > +#include <linux/basic_mmio_gpio.h>
> >  #include <linux/platform_device.h>
> >  
> > -#include <mach/hardware.h>
...

---

From marc.zyngier at arm.com  Mon Apr 15 03:50:38 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon, 15 Apr 2013 09:50:38 +0200
Subject: [PATCH] ARM: KVM: iterate over all CPUs for CPU compatibility
 check
In-Reply-To: <CAEDV+g+E8PLc60vMRhq4O_AL2WjmYDLb6=Wh34ynhevh7uAGJA@mail.gmail.com>
References: <1365771875-5788-1-git-send-email-andre.przywara@linaro.org>
 <51680AF9.7040109@arm.com>
 <CAEDV+g+E8PLc60vMRhq4O_AL2WjmYDLb6=Wh34ynhevh7uAGJA@mail.gmail.com>
Message-ID: <d455f2823b9639af8d38d30f2c3234bd@localhost>

On Sun, 14 Apr 2013 21:57:36 -0700, Christoffer Dall
<cdall at cs.columbia.edu> wrote:
> On Fri, Apr 12, 2013 at 6:24 AM, Marc Zyngier <marc.zyngier at arm.com>
wrote:
>> On 12/04/13 14:04, Andre Przywara wrote:
>>> kvm_target_cpus() checks the compatibility of the used CPU with
>>> KVM, which is currently limited to ARM Cortex-A15 cores.
>>> However by calling it only once on any random CPU it assumes that
>>> all cores are the same, which is not true for big.LITTLE parts.
>>>
>>> After doing about 40 boots on a TC-2 core tile, I found it running
>>> in all but one case on one of the A7 cores (which correctly denied
>>> KVM initialization). On the 39th boot however the code ran on
>>> an A15, leading to a hang after returning success:
>>>
>>> ...
>>> TCP: reno registered
>>> UDP hash table entries: 512 (order: 2, 16384 bytes)
>>> UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
>>> NET: Registered protocol family 1
>>> kvm_target_cpu() on CPU #1, part is c0f0
>>>  ... (pause for a while) ...
>>> INFO: rcu_sched self-detected stall on CPUINFO: rcu_sched detected
>>> stalls on CPU
>>> s/tasks: { 1} (detected by 0, t=6002 jiffies, g=4294966999,
>>> c=4294966998, q=15)
>>> Task dump for CPU 1:
>>> swapper/0       R running      0     1      0 0x00000002
>>>
>>> So iterate over every CPU to correctly determine the capability of
>>> the system to run the current KVM implementation.
>>> In case a big.LITTLE configuration is the reason for denial, give
>>> the user a hint how to get it running anyway (maxcpus= on the kernel
>>> command line).
>>>
>>> Please push this still into 3.9.
>>>
>>> Signed-off-by: Andre Przywara <andre.przywara at linaro.org>
>>
>> [...]
>>
>> Nak. The fact that one of the CPUs seem to hang is a sure sign that
>> something is severely broken, and you definitely want to fix that
issue,
>> instead of blindly ignoring it.
>>
>> Additionally, it seems you're just papering over the issue. You should
>> be able to exclude the A7 processors, but not completely deny KVM from
>> running on the hardware.
>>
> Marc, I disagree with this nak. If the current kernel breaks boot on a
> Big.Little system, we need to take care of that first, and the
> proposed patch is a quick way to do so, and it does not stand in the
> way of introducing proper Big.Little support in any way, which I'm
> sure is going to open up a lot of other interesting questions.
> 
> I'm going to take this one.

That's your privilege.

Now, my objections about this patch still stand:
- It papers over what looks like a serious bug (CPU hanging? bah, let's
not bother with that). It is an A15 hanging here by the way, not an A7.
- It forces the user to choose between 5 CPUs and KVM (while simply
setting thread affinity would solve the problem this patch tries to solve).
- It reports potentially wrong information (setting maxcpus= will probably
do the wrong thing if cluster 0 is A7 based).

For these reasons, I'm still strongly opposed to this patch being merged.
Yes, this is a quick way to hide a (much) bigger problem, but in no way a
fix.

        M.
-- 
Fast, cheap, reliable. Pick two.


From marc.zyngier at arm.com  Mon Apr 15 04:00:35 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon, 15 Apr 2013 10:00:35 +0200
Subject: [PATCH v3 5/7] ARM: KVM: rework HYP page table freeing
In-Reply-To: <CAEDV+gJAUOsi3yjwp3hmBPbLkaL_0PaUNGFLLZN0nOzya7BA-A@mail.gmail.com>
References: <1365779932-20322-1-git-send-email-marc.zyngier@arm.com>
 <1365779932-20322-6-git-send-email-marc.zyngier@arm.com>
 <CAEDV+gJAUOsi3yjwp3hmBPbLkaL_0PaUNGFLLZN0nOzya7BA-A@mail.gmail.com>
Message-ID: <89815b00ef8a11e6fc7bc03497b9668a@localhost>

On Sun, 14 Apr 2013 23:51:55 -0700, Christoffer Dall
<cdall at cs.columbia.edu> wrote:
> On Fri, Apr 12, 2013 at 8:18 AM, Marc Zyngier <marc.zyngier at arm.com>
wrote:
>> There is no point in freeing HYP page tables differently from Stage-2.
>> They now have the same requirements, and should be dealt with the same
>> way.
>>
>> Promote unmap_stage2_range to be The One True Way, and get rid of a
>> number
>> of nasty bugs in the process (goo thing we never actually called
>> free_hyp_pmds
> 
> could you remind me, did you already point out these nasty bugs
> somewhere or did we discuss them in an older thread?

No, I decided it wasn't worth the hassle when I spotted them (specially as
we're moving away from section mapped idmap)... But for the record:

<quote>
static void free_hyp_pgd_entry(pgd_t *pgdp, unsigned long addr)
{
	pgd_t *pgd;
	pud_t *pud;
	pmd_t *pmd;

	pgd = pgdp + pgd_index(addr);
	pud = pud_offset(pgd, addr);

	if (pud_none(*pud))
		return;
	BUG_ON(pud_bad(*pud));

	pmd = pmd_offset(pud, addr);
	free_ptes(pmd, addr);
	pmd_free(NULL, pmd);
        ^^^^^^^^^^^^^^^^^^^^<-- BUG_ON(pmd not page aligned)
	pud_clear(pud);
}
</quote>

Now, if you decide to fix the above by forcing the page alignment:

<quote>
static void free_ptes(pmd_t *pmd, unsigned long addr)
{
	pte_t *pte;
	unsigned int i;

	for (i = 0; i < PTRS_PER_PMD; i++, addr += PMD_SIZE) {
             ^^^^^^^^^^^^^<-- start freeing memory outside of the
(unaligned) pmd...
		if (!pmd_none(*pmd) && pmd_table(*pmd)) {
			pte = pte_offset_kernel(pmd, addr);
			pte_free_kernel(NULL, pte);
		}
		pmd++;
	}
}
</quote>

Once you've fixed that as well, you end up noticing that if you have PTEs
pointed to by the same PMD, you need to introduce some refcounting if you
need to free one PTE and not the others.

At this point, I had enough, and decided to reuse what we already had
instead of reinventing the wheel.

> nit: s/goo/good/
> 
>> before...).

Will fix.

Thanks,

        M.
-- 
Fast, cheap, reliable. Pick two.


From nicolas.ferre at atmel.com  Mon Apr 15 04:04:33 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Mon, 15 Apr 2013 10:04:33 +0200
Subject: [PATCH] net/macb: fix error return code in macb_probe()
Message-ID: <1366013073-22934-1-git-send-email-nicolas.ferre@atmel.com>

Fix to return a negative error code from the error handling
case instead of 0, as returned elsewhere in this function.

Original-idea-by: <yongjun_wei at trendmicro.com.cn>
Signed-off-by: Nicolas Ferre <nicolas.ferre at atmel.com>
---
Hi,

This fix was written originally for at91_ether.c and I found it interesting
to adapt it to macb.
Thanks to Wei Yongjun for finding it.

Best regards,

 drivers/net/ethernet/cadence/macb.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/cadence/macb.c b/drivers/net/ethernet/cadence/macb.c
index 7fd0e3e..6be513d 100644
--- a/drivers/net/ethernet/cadence/macb.c
+++ b/drivers/net/ethernet/cadence/macb.c
@@ -1602,9 +1602,9 @@ static int __init macb_probe(struct platform_device *pdev)
 		goto err_out_free_irq;
 	}
 
-	if (macb_mii_init(bp) != 0) {
+	err = macb_mii_init(bp);
+	if (err)
 		goto err_out_unregister_netdev;
-	}
 
 	platform_set_drvdata(pdev, dev);
 
-- 
1.8.0



From p.zabel at pengutronix.de  Mon Apr 15 04:05:32 2013
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Mon, 15 Apr 2013 10:05:32 +0200
Subject: [PATCH v2 3/4] ARM: dts: mx53qsb: Add support for parallel display
In-Reply-To: <CAOkaPuV2xNR=Vxsa6tPdnPS34Q5ffV9-f8DefhcJfvVvXWOADQ@mail.gmail.com>
References: <1365516452-1287-1-git-send-email-rogerio.pimentel@freescale.com>
 <1365516452-1287-3-git-send-email-rogerio.pimentel@freescale.com>
 <1365520643.4023.52.camel@pizza.hi.pengutronix.de>
 <CAOkaPuV2xNR=Vxsa6tPdnPS34Q5ffV9-f8DefhcJfvVvXWOADQ@mail.gmail.com>
Message-ID: <1366013132.4012.13.camel@pizza.hi.pengutronix.de>

Am Freitag, den 12.04.2013, 15:49 -0300 schrieb Rogerio Pimentel:
> On Tue, Apr 9, 2013 at 12:17 PM, Philipp Zabel <p.zabel at pengutronix.de> wrote:
> > Am Dienstag, den 09.04.2013, 11:07 -0300 schrieb Rogerio Pimentel:
> >> Add support for CLAA WVGA display for i.MX53 QSB.
> >>
> >> Signed-off-by: Rogerio Pimentel <rogerio.pimentel at freescale.com>
> >> ---
> >> Changes since v1:
> >> Changed the label disp1 to disp0 to correctly match the display pins
> >>  arch/arm/boot/dts/imx53-qsb.dtsp |   26 ++++++++++++++++++++++++++
> >>  arch/arm/boot/dts/imx53.dtsip    |   35 +++++++++++++++++++++++++++++++++++
> >>  2 files changed, 61 insertions(+)
> >>
> >> diff --git a/arch/arm/boot/dts/imx53-qsb.dtsp b/arch/arm/boot/dts/imx53-qsb.dtsp
> >> index dae8d9f..6086a3c 100644
> >> --- a/arch/arm/boot/dts/imx53-qsb.dtsp
> >> +++ b/arch/arm/boot/dts/imx53-qsb.dtsp
> >> @@ -21,6 +21,32 @@
> >>               reg = <0x70000000 0x40000000>;
> >>       };
> >>
> >> +     display at di0 {
> >> +             compatible = "fsl,imx-parallel-display";
> >> +             crtcs = <&ipu 0>;
> >> +             interface-pix-fmt = "rgb565";
> >> +             pinctrl-names = "default";
> >> +             pinctrl-0 = <&pinctrl_ipu_disp0_1>;
> >> +             display-timings {
> >> +                     claawvga {
> >> +                             native-mode;
> >> +                             clock-frequency = <27000000>;
> >> +                             hactive = <800>;
> >> +                             vactive = <480>;
> >> +                             hback-porch = <40>;
> >> +                             hfront-porch = <60>;
> >> +                             vback-porch = <10>;
> >> +                             vfront-porch = <10>;
> >> +                             hsync-len = <20>;
> >> +                             vsync-len = <10>;
> >> +                             hsync-active = <0>;
> >> +                             vsync-active = <0>;
> >> +                             de-active = <1>;
> >> +                             pixelclk-active = <0>;
> >> +                     };
> >> +             };
> >> +     };
> >> +
> >
> > This clashes with the MCIMXHDMICARD daughter module, which has a sii902x
> > HDMI encoder connected to DISP0 for i.MX53-QSB. Would it make sense to
> > add all possible options to the device tree but mark them with
> > status = "disabled" by default?
> >
> > regards
> > Philipp
> >
> I'm planning to add support for MCIMXHDMICARD later because it will also
> require support for sii902x.

That's good to hear. We have some (very) work-in-progress sii902x driver
patches floating around, if you are interested.

>  I'd like to add the parallel display that
> we have available
> today and after that add the support for sii902x. What do you think?

As Sascha said, I'm in favor of adding the parallel display support now,
but with the status = "disabled" property in there.
Then anybody who has the CLAAWVGA display can just set status = "okay"
manually at build time or from the bootloader.

regards
Philipp



From mfuzzey at parkeon.com  Mon Apr 15 04:07:41 2013
From: mfuzzey at parkeon.com (Martin Fuzzey)
Date: Mon, 15 Apr 2013 10:07:41 +0200
Subject: [PATCH V2] ARM: i.MX5: Allow DT clock providers
Message-ID: <20130415080741.20173.70704.stgit@localhost>

Currently clock providers defined in the DT are not registered
on i.MX5 platforms since of_clk_init() is not called.

This is not a problem for the SOC's own clocks, which are registered
in code,  but prevents the DT being used to define clocks for external
hardware.

Fix this by calling of_clk_init() and actually using the DT to obtain
the 4 SOC fixed clocks.
These are already defined in the DT but were previously just used to
manually obtain the rate.

Fall back to the old scheme for non DT platforms.

Signed-off-by: Martin Fuzzey <mfuzzey at parkeon.com>

---
Changelog:
V2: Applied comments from Sashca Hauer:
	* Use kasprintf instead of scnprintf to avoid length limit
	* Avoid use of IS_ERR_OR_NULL
---
 arch/arm/mach-imx/clk-imx51-imx53.c |   79 ++++++++++++++++++++---------------
 1 files changed, 45 insertions(+), 34 deletions(-)

diff --git a/arch/arm/mach-imx/clk-imx51-imx53.c b/arch/arm/mach-imx/clk-imx51-imx53.c
index 3228b4e..4b28cfc 100644
--- a/arch/arm/mach-imx/clk-imx51-imx53.c
+++ b/arch/arm/mach-imx/clk-imx51-imx53.c
@@ -117,17 +117,56 @@ enum imx5_clks {
 static struct clk *clk[clk_max];
 static struct clk_onecell_data clk_data;
 
+
+static struct clk * __init mx5_obtain_fixed_clock_from_dt(const char *name)
+{
+#ifdef CONFIG_OF
+	struct of_phandle_args phandle = {0};
+	struct clk *clk = ERR_PTR(-ENODEV);
+	char *compatible;
+
+	compatible = kasprintf(GFP_KERNEL, "fsl,imx-%s", name);
+	if (!compatible)
+		return ERR_PTR(-ENOMEM);
+
+	phandle.np = of_find_compatible_node(NULL, NULL, compatible);
+	kfree(compatible);
+	if (phandle.np) {
+		clk = of_clk_get_from_provider(&phandle);
+		of_node_put(phandle.np);
+	}
+	return clk;
+#else
+	return ERR_PTR(-ENODEV);
+#endif
+}
+
+static struct clk * __init mx5_obtain_fixed_clock(
+			const char *name, unsigned long rate)
+{
+	struct clk *clk;
+
+	clk = mx5_obtain_fixed_clock_from_dt(name);
+	if (IS_ERR(clk))
+		clk = imx_clk_fixed(name, rate);
+	return clk;
+}
+
 static void __init mx5_clocks_common_init(unsigned long rate_ckil,
 		unsigned long rate_osc, unsigned long rate_ckih1,
 		unsigned long rate_ckih2)
 {
 	int i;
 
+#ifdef CONFIG_OF
+	of_clk_init(NULL);
+#endif
+
 	clk[dummy] = imx_clk_fixed("dummy", 0);
-	clk[ckil] = imx_clk_fixed("ckil", rate_ckil);
-	clk[osc] = imx_clk_fixed("osc", rate_osc);
-	clk[ckih1] = imx_clk_fixed("ckih1", rate_ckih1);
-	clk[ckih2] = imx_clk_fixed("ckih2", rate_ckih2);
+	clk[ckil] = mx5_obtain_fixed_clock("ckil", rate_ckil);
+	clk[osc] = mx5_obtain_fixed_clock("osc", rate_osc);
+	clk[ckih1] = mx5_obtain_fixed_clock("ckih1", rate_ckih1);
+	clk[ckih2] = mx5_obtain_fixed_clock("ckih2", rate_ckih2);
 
 	clk[lp_apm] = imx_clk_mux("lp_apm", MXC_CCM_CCSR, 9, 1,
 				lp_apm_sel, ARRAY_SIZE(lp_apm_sel));
@@ -540,41 +579,13 @@ int __init mx53_clocks_init(unsigned long rate_ckil, unsigned long rate_osc,
 }
 
 #ifdef CONFIG_OF
-static void __init clk_get_freq_dt(unsigned long *ckil, unsigned long *osc,
-				   unsigned long *ckih1, unsigned long *ckih2)
-{
-	struct device_node *np;
-
-	/* retrieve the freqency of fixed clocks from device tree */
-	for_each_compatible_node(np, NULL, "fixed-clock") {
-		u32 rate;
-		if (of_property_read_u32(np, "clock-frequency", &rate))
-			continue;
-
-		if (of_device_is_compatible(np, "fsl,imx-ckil"))
-			*ckil = rate;
-		else if (of_device_is_compatible(np, "fsl,imx-osc"))
-			*osc = rate;
-		else if (of_device_is_compatible(np, "fsl,imx-ckih1"))
-			*ckih1 = rate;
-		else if (of_device_is_compatible(np, "fsl,imx-ckih2"))
-			*ckih2 = rate;
-	}
-}
-
 int __init mx51_clocks_init_dt(void)
 {
-	unsigned long ckil, osc, ckih1, ckih2;
-
-	clk_get_freq_dt(&ckil, &osc, &ckih1, &ckih2);
-	return mx51_clocks_init(ckil, osc, ckih1, ckih2);
+	return mx51_clocks_init(0, 0, 0, 0);
 }
 
 int __init mx53_clocks_init_dt(void)
 {
-	unsigned long ckil, osc, ckih1, ckih2;
-
-	clk_get_freq_dt(&ckil, &osc, &ckih1, &ckih2);
-	return mx53_clocks_init(ckil, osc, ckih1, ckih2);
+	return mx53_clocks_init(0, 0, 0, 0);
 }
 #endif



From peter.ujfalusi at ti.com  Mon Apr 15 04:19:36 2013
From: peter.ujfalusi at ti.com (Peter Ujfalusi)
Date: Mon, 15 Apr 2013 10:19:36 +0200
Subject: Query on pinctrl usage for DT nodes
In-Reply-To: <20130403184202.GB10155@atomide.com>
References: <CA+V-a8uiPwsAD--OHFAE=i2ed+-wbXm4p2deZXr92+Zv6GDS1w@mail.gmail.com>
 <515C5C76.3080009@wwwdotorg.org> <20130403183803.GA10155@atomide.com>
 <20130403184202.GB10155@atomide.com>
Message-ID: <516BB818.3060603@ti.com>

Hi,

On 04/03/2013 08:42 PM, Tony Lindgren wrote:
> Oh it's already using pinctrl-single,bits option. Maybe there's a
> bug, adding Peter to cc.

I think all boils down to the fact that in pinctrl (single only?) _one_
register can be only associated with _one_ driver. Even through ,bit type
would allow us to only change parts of the same register, another device can
not take the same register with different mask.
I did noticed this after I have sent the bits-per-mux support.
Right now I don't have solution for this...

-- 
P?ter


From peter.ujfalusi at ti.com  Mon Apr 15 04:26:07 2013
From: peter.ujfalusi at ti.com (Peter Ujfalusi)
Date: Mon, 15 Apr 2013 10:26:07 +0200
Subject: Query on pinctrl usage for DT nodes
In-Reply-To: <20130410203408.GP10155@atomide.com>
References: <CA+V-a8uiPwsAD--OHFAE=i2ed+-wbXm4p2deZXr92+Zv6GDS1w@mail.gmail.com>
 <515C5C76.3080009@wwwdotorg.org>
 <CA+V-a8t3wtP77DdeUoQHKMjAuWmV+ude+1J3UjJmMTqobgStjA@mail.gmail.com>
 <5162FD4A.1030909@wwwdotorg.org>
 <CA+V-a8vwdCkyMqiynj5BodXbjwJ=e4qNb-29FhLweqbjc7DBQA@mail.gmail.com>
 <5165A22B.4070200@wwwdotorg.org> <20130410203408.GP10155@atomide.com>
Message-ID: <516BB99F.2080502@ti.com>

On 04/10/2013 10:34 PM, Tony Lindgren wrote:
> Yeah how about just change the pintctrl-single,bits register
> naming to be register + bit?  Something like 0xdeadbeef.0 and
> 0xdeadbeef.1 and so on.

Something like this might work I think. It is going to be a bit tricky IMHO
since we might need span out new 'register' every time a device requests for a
new pinctrl-single,bits for already used register in the
pinctrl-single,bit-per-mux area. In this way we still can make sure that
certain bit are only used by a single driver.

-- 
P?ter


From cdall at cs.columbia.edu  Mon Apr 15 04:28:25 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Mon, 15 Apr 2013 01:28:25 -0700
Subject: [PATCH] ARM: KVM: iterate over all CPUs for CPU compatibility
 check
In-Reply-To: <d455f2823b9639af8d38d30f2c3234bd@localhost>
References: <1365771875-5788-1-git-send-email-andre.przywara@linaro.org>
 <51680AF9.7040109@arm.com>
 <CAEDV+g+E8PLc60vMRhq4O_AL2WjmYDLb6=Wh34ynhevh7uAGJA@mail.gmail.com>
 <d455f2823b9639af8d38d30f2c3234bd@localhost>
Message-ID: <CAEDV+gJuFG49oQ=BEaCHcTP=nHVyX8ALw6076dR_C1s7TuyqXQ@mail.gmail.com>

On Mon, Apr 15, 2013 at 12:50 AM, Marc Zyngier <marc.zyngier at arm.com> wrote:
> On Sun, 14 Apr 2013 21:57:36 -0700, Christoffer Dall
> <cdall at cs.columbia.edu> wrote:
>> On Fri, Apr 12, 2013 at 6:24 AM, Marc Zyngier <marc.zyngier at arm.com>
> wrote:
>>> On 12/04/13 14:04, Andre Przywara wrote:
>>>> kvm_target_cpus() checks the compatibility of the used CPU with
>>>> KVM, which is currently limited to ARM Cortex-A15 cores.
>>>> However by calling it only once on any random CPU it assumes that
>>>> all cores are the same, which is not true for big.LITTLE parts.
>>>>
>>>> After doing about 40 boots on a TC-2 core tile, I found it running
>>>> in all but one case on one of the A7 cores (which correctly denied
>>>> KVM initialization). On the 39th boot however the code ran on
>>>> an A15, leading to a hang after returning success:
>>>>
>>>> ...
>>>> TCP: reno registered
>>>> UDP hash table entries: 512 (order: 2, 16384 bytes)
>>>> UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
>>>> NET: Registered protocol family 1
>>>> kvm_target_cpu() on CPU #1, part is c0f0
>>>>  ... (pause for a while) ...
>>>> INFO: rcu_sched self-detected stall on CPUINFO: rcu_sched detected
>>>> stalls on CPU
>>>> s/tasks: { 1} (detected by 0, t=6002 jiffies, g=4294966999,
>>>> c=4294966998, q=15)
>>>> Task dump for CPU 1:
>>>> swapper/0       R running      0     1      0 0x00000002
>>>>
>>>> So iterate over every CPU to correctly determine the capability of
>>>> the system to run the current KVM implementation.
>>>> In case a big.LITTLE configuration is the reason for denial, give
>>>> the user a hint how to get it running anyway (maxcpus= on the kernel
>>>> command line).
>>>>
>>>> Please push this still into 3.9.
>>>>
>>>> Signed-off-by: Andre Przywara <andre.przywara at linaro.org>
>>>
>>> [...]
>>>
>>> Nak. The fact that one of the CPUs seem to hang is a sure sign that
>>> something is severely broken, and you definitely want to fix that
> issue,
>>> instead of blindly ignoring it.
>>>
>>> Additionally, it seems you're just papering over the issue. You should
>>> be able to exclude the A7 processors, but not completely deny KVM from
>>> running on the hardware.
>>>
>> Marc, I disagree with this nak. If the current kernel breaks boot on a
>> Big.Little system, we need to take care of that first, and the
>> proposed patch is a quick way to do so, and it does not stand in the
>> way of introducing proper Big.Little support in any way, which I'm
>> sure is going to open up a lot of other interesting questions.
>>
>> I'm going to take this one.
>
> That's your privilege.
>
> Now, my objections about this patch still stand:
> - It papers over what looks like a serious bug (CPU hanging? bah, let's
> not bother with that). It is an A15 hanging here by the way, not an A7.

I missed that part. Are we even sure then that this is related to
running on Big.Little?

> - It forces the user to choose between 5 CPUs and KVM (while simply
> setting thread affinity would solve the problem this patch tries to solve).

But this happens during boot, so thread affinity won't really be a
valid work around for this...

> - It reports potentially wrong information (setting maxcpus= will probably
> do the wrong thing if cluster 0 is A7 based).

ok, fair enough.

>
> For these reasons, I'm still strongly opposed to this patch being merged.
> Yes, this is a quick way to hide a (much) bigger problem, but in no way a
> fix.
>

I'm not claiming this to be a fix for the underlying problem, and I
would much rather see a proper fix. But, I also don't want kernels
configured with KVM to cause systems not to boot and if we can prevent
that from happening for now, in whichever rough possible way, I think
that takes priority.

Right now all the code is written with the inherent assumption that
we're running on an A15, and while I did not scrutinize if some of our
code can break the host if run on an A7, we should probably make sure
that doesn't happen until we actively support Big.Little and A7.  I
think relying on users not to crash their kernels by setting CPU
affinities is also a big mistake.

Andre, when I look back over the log, I'm actually not seeing definite
proof that it's inside the KVM init that the core hangs, how do you
determine this?

Also, if you only experienced the problem in one boot out of 40, how
can you be sure that this patch actually fixes the issue you're
seeing?


From arnd at arndb.de  Mon Apr 15 04:35:09 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 15 Apr 2013 10:35:09 +0200
Subject: [PATCH 1/7] clk: exynos: prepare for multiplatform
In-Reply-To: <CAJuYYwRfoU1y_3qbZtdhdyRugPD_QCYWr_LuesOXzq+-jmxouw@mail.gmail.com>
References: <1365775405-115297-1-git-send-email-arnd@arndb.de>
 <1365775405-115297-2-git-send-email-arnd@arndb.de>
 <CAJuYYwRfoU1y_3qbZtdhdyRugPD_QCYWr_LuesOXzq+-jmxouw@mail.gmail.com>
Message-ID: <201304151035.09583.arnd@arndb.de>

On Monday 15 April 2013, Thomas Abraham wrote:
> On 12 April 2013 19:33, Arnd Bergmann <arnd at arndb.de> wrote:
> > The new common clock drivers for exynos are using compile
> > time constants and soc_is_exynos* macros to provide backwards
> > compatibility for pre-DT systems, which is not possible with
> > multiplatform kernels. This moves all the necessary
> > information back into platform code and removes the mach/*
> > header inclusions.
> 
> 
> Since kgene has submitted a patch to remove pre-dt Exynos support
> which looks like it will be accepted, we could just remove the use of
> soc_is_xyz() instead of continuing to support non-dt Exynos.

I think based on the most recent discussion, we are not actually doing
that for 3.10, since there are still people that require ATAGS support.

	Arnd


From arnd at arndb.de  Mon Apr 15 04:36:35 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 15 Apr 2013 10:36:35 +0200
Subject: [PATCH 3/7] ARM: exynos: add missing properties for combiner IRQs
In-Reply-To: <CAJuYYwSJyDt7aBLyY0S8LUaGf9-VwuSeM_n3V1UuBzgTyDyTUQ@mail.gmail.com>
References: <1365775405-115297-1-git-send-email-arnd@arndb.de>
 <1365775405-115297-4-git-send-email-arnd@arndb.de>
 <CAJuYYwSJyDt7aBLyY0S8LUaGf9-VwuSeM_n3V1UuBzgTyDyTUQ@mail.gmail.com>
Message-ID: <201304151036.35228.arnd@arndb.de>

On Monday 15 April 2013, Thomas Abraham wrote:
> On 12 April 2013 19:33, Arnd Bergmann <arnd at arndb.de> wrote:
> > The exynos combiner irqchip needs to find the parent interrupts
> > and needs to know their number, so add the missing properties
> > for exynos4 as they were already present for exynos5.
> >
> > Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> > ---
> >  arch/arm/boot/dts/exynos4210.dtsi | 1 +
> >  arch/arm/boot/dts/exynos4212.dtsi | 9 +++++++++
> >  arch/arm/boot/dts/exynos4412.dtsi | 9 +++++++++
> >  3 files changed, 19 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/exynos4210.dtsi b/arch/arm/boot/dts/exynos4210.dtsi
> > index 15143bd..c102869 100644
> > --- a/arch/arm/boot/dts/exynos4210.dtsi
> > +++ b/arch/arm/boot/dts/exynos4210.dtsi
> > @@ -41,6 +41,7 @@
> >         };
> >
> >         combiner:interrupt-controller at 10440000 {
> > +               combiner-nr = <16>;
> 
> The default value of the combiner-nr is case it is not specified is
> 16. The default value is documented in the bindings documentation.

Unfortunately, the driver now warns about a missing attribute, which
seems right. I also made the default "20" instead of "16" to cover the
other exynos4 chips. I'd say it's best to keep this one explicitly listed
even if it's optional.

> > +       interrupt-controller at 10440000 {
> > +               combiner-nr = <20>;
> > +               interrupts = <0 0 0>, <0 1 0>, <0 2 0>, <0 3 0>,
> > +                            <0 4 0>, <0 5 0>, <0 6 0>, <0 7 0>,
> > +                            <0 8 0>, <0 9 0>, <0 10 0>, <0 11 0>,
> > +                            <0 12 0>, <0 13 0>, <0 14 0>, <0 15 0>,
> > +                            <0 107 0>, <0 108 0>>, <0 48 0>, <0 42 0>;
> 
> Extra '>' for <0 108 0> can be removed.
> 
> Reviewed-by: Thomas Abraham <thomas.abraham at linaro.org?

Thanks!


From girishks2000 at gmail.com  Mon Apr 15 04:40:28 2013
From: girishks2000 at gmail.com (Girish K S)
Date: Mon, 15 Apr 2013 14:10:28 +0530
Subject: [PATCH V3 RESEND 3/5] spi: s3c64xx: Added provision for non-gpio i/o's
In-Reply-To: <1366015230-18243-1-git-send-email-ks.giri@samsung.com>
References: <1366015230-18243-1-git-send-email-ks.giri@samsung.com>
Message-ID: <1366015230-18243-2-git-send-email-ks.giri@samsung.com>

From: Girish K S <girishks2000 at gmail.com>

Currently the drivers supports only the GPIO based i/o pins.
But there are Exynos SoC's that use the same controller with
dedicated i/o pins.

This patch  provides provision to support gpio/dedicated pins.
The decision is made by parsing the "gpios" property in the spi
node.

Signed-off-by: Girish K S <ks.giri at samsung.com>
---
 drivers/spi/spi-s3c64xx.c |    8 ++++++++
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index a6fdc71..79de18f 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -1111,6 +1111,9 @@ static int s3c64xx_spi_parse_dt_gpio(struct s3c64xx_spi_driver_data *sdd)
 	struct device *dev = &sdd->pdev->dev;
 	int idx, gpio, ret;
 
+	if (!of_find_property(dev->of_node, "gpios", NULL))
+		return 0;
+
 	/* find gpios for mosi, miso and clock lines */
 	for (idx = 0; idx < 3; idx++) {
 		gpio = of_get_gpio(dev->of_node, idx);
@@ -1137,6 +1140,11 @@ free_gpio:
 static void s3c64xx_spi_dt_gpio_free(struct s3c64xx_spi_driver_data *sdd)
 {
 	unsigned int idx;
+	struct device *dev = &sdd->pdev->dev;
+
+	if (!of_find_property(dev->of_node, "gpios", NULL))
+		return;
+
 	for (idx = 0; idx < 3; idx++)
 		gpio_free(sdd->gpios[idx]);
 }
-- 
1.7.5.4



From girishks2000 at gmail.com  Mon Apr 15 04:40:27 2013
From: girishks2000 at gmail.com (Girish K S)
Date: Mon, 15 Apr 2013 14:10:27 +0530
Subject: [PATCH V4 2/5] spi: s3c64xx: added support for polling mode
Message-ID: <1366015230-18243-1-git-send-email-ks.giri@samsung.com>

From: Girish K S <girishks2000 at gmail.com>

The 64xx spi driver supports partial polling mode.
Only the last chunk of the transfer length is transferred
or recieved in polling mode.

Some SoC's that adopt this controller might not have have dma
interface. This patch adds support for complete polling mode
and gives flexibity for the user to select poll/dma mode.

Signed-off-by: Girish K S <ks.giri at samsung.com>
---
changes in v4:
		Handled the dma allocation failure and switching to poll
if dma resource allocation failed

changes in v3:
		Separated the polling mode and gpio handling separately

changes in v2:
		changed the logic to handle the buffer from the user space.
moved out the timeout code as a separate function.

 drivers/spi/spi-s3c64xx.c |  133 ++++++++++++++++++++++++++++++---------------
 1 files changed, 89 insertions(+), 44 deletions(-)

diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index 4188b2f..a6fdc71 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -35,6 +35,7 @@
 #include <linux/platform_data/spi-s3c64xx.h>
 
 #define MAX_SPI_PORTS		3
+#define S3C64XX_SPI_QUIRK_POLL		(1 << 0)
 
 /* Registers and bit-fields */
 
@@ -126,6 +127,7 @@
 #define S3C64XX_SPI_TRAILCNT		S3C64XX_SPI_MAX_TRAILCNT
 
 #define msecs_to_loops(t) (loops_per_jiffy / 1000 * HZ * t)
+#define is_polling(x)	(x->port_conf->quirks & S3C64XX_SPI_QUIRK_POLL)
 
 #define RXBUSY    (1<<2)
 #define TXBUSY    (1<<3)
@@ -154,6 +156,7 @@ struct s3c64xx_spi_port_config {
 	int	fifo_lvl_mask[MAX_SPI_PORTS];
 	int	rx_lvl_offset;
 	int	tx_st_done;
+	int	quirks;
 	bool	high_speed;
 	bool	clk_from_cmu;
 };
@@ -419,6 +422,27 @@ static inline void enable_cs(struct s3c64xx_spi_driver_data *sdd,
 
 	cs = spi->controller_data;
 	gpio_set_value(cs->line, spi->mode & SPI_CS_HIGH ? 1 : 0);
+
+	/* Start the signals */
+	writel(0, sdd->regs + S3C64XX_SPI_SLAVE_SEL);
+}
+
+static u32 wait_for_timeout(struct s3c64xx_spi_driver_data *sdd,
+					int timeout_ms)
+{
+	void __iomem *regs = sdd->regs;
+	unsigned long val;
+	u32 status;
+	/* max fifo depth available */
+	u32 max_fifo = (FIFO_LVL_MASK(sdd) >> 1) + 1;
+
+	val = msecs_to_loops(timeout_ms);
+	do {
+		status = readl(regs + S3C64XX_SPI_STATUS);
+	} while (RX_FIFO_LVL(status, sdd) < max_fifo && --val);
+
+	/* return the actual received data length */
+	return RX_FIFO_LVL(status, sdd);
 }
 
 static int wait_for_xfer(struct s3c64xx_spi_driver_data *sdd,
@@ -443,20 +467,19 @@ static int wait_for_xfer(struct s3c64xx_spi_driver_data *sdd,
 		} while (RX_FIFO_LVL(status, sdd) < xfer->len && --val);
 	}
 
-	if (!val)
-		return -EIO;
-
 	if (dma_mode) {
 		u32 status;
 
 		/*
+		 * If the previous xfer was completed within timeout, then
+		 * proceed further else return -EIO.
 		 * DmaTx returns after simply writing data in the FIFO,
 		 * w/o waiting for real transmission on the bus to finish.
 		 * DmaRx returns only after Dma read data from FIFO which
 		 * needs bus transmission to finish, so we don't worry if
 		 * Xfer involved Rx(with or without Tx).
 		 */
-		if (xfer->rx_buf == NULL) {
+		if (val && !xfer->rx_buf) {
 			val = msecs_to_loops(10);
 			status = readl(regs + S3C64XX_SPI_STATUS);
 			while ((TX_FIFO_LVL(status, sdd)
@@ -466,30 +489,53 @@ static int wait_for_xfer(struct s3c64xx_spi_driver_data *sdd,
 				status = readl(regs + S3C64XX_SPI_STATUS);
 			}
 
-			if (!val)
-				return -EIO;
 		}
+
+		/* If timed out while checking rx/tx status return error */
+		if (!val)
+			return -EIO;
 	} else {
+		int loops;
+		u32 cpy_len;
+		u8 *buf;
+
 		/* If it was only Tx */
-		if (xfer->rx_buf == NULL) {
+		if (!xfer->rx_buf) {
 			sdd->state &= ~TXBUSY;
 			return 0;
 		}
 
-		switch (sdd->cur_bpw) {
-		case 32:
-			ioread32_rep(regs + S3C64XX_SPI_RX_DATA,
-				xfer->rx_buf, xfer->len / 4);
-			break;
-		case 16:
-			ioread16_rep(regs + S3C64XX_SPI_RX_DATA,
-				xfer->rx_buf, xfer->len / 2);
-			break;
-		default:
-			ioread8_rep(regs + S3C64XX_SPI_RX_DATA,
-				xfer->rx_buf, xfer->len);
-			break;
-		}
+		/*
+		 * If the receive length is bigger than the controller fifo
+		 * size, calculate the loops and read the fifo as many times.
+		 * loops = length / max fifo size (calculated by using the
+		 * fifo mask).
+		 * For any size less than the fifo size the below code is
+		 * executed atleast once.
+		 */
+		loops = xfer->len / ((FIFO_LVL_MASK(sdd) >> 1) + 1);
+		buf = xfer->rx_buf;
+		do{
+			/* wait for data to be received in the fifo */
+			cpy_len = wait_for_timeout(sdd, ms);
+
+			switch (sdd->cur_bpw) {
+			case 32:
+				ioread32_rep(regs + S3C64XX_SPI_RX_DATA,
+					buf, cpy_len / 4);
+				break;
+			case 16:
+				ioread16_rep(regs + S3C64XX_SPI_RX_DATA,
+					buf, cpy_len / 2);
+				break;
+			default:
+				ioread8_rep(regs + S3C64XX_SPI_RX_DATA,
+					buf, cpy_len);
+				break;
+			}
+
+			buf = buf + cpy_len;
+		}while(loops--);
 		sdd->state &= ~RXBUSY;
 	}
 
@@ -505,6 +551,9 @@ static inline void disable_cs(struct s3c64xx_spi_driver_data *sdd,
 		sdd->tgl_spi = NULL;
 
 	gpio_set_value(cs->line, spi->mode & SPI_CS_HIGH ? 0 : 1);
+
+	/* Quiese the signals */
+	writel(S3C64XX_SPI_SLAVE_SIG_INACT, sdd->regs + S3C64XX_SPI_SLAVE_SEL);
 }
 
 static void s3c64xx_spi_config(struct s3c64xx_spi_driver_data *sdd)
@@ -586,7 +635,7 @@ static int s3c64xx_spi_map_mssg(struct s3c64xx_spi_driver_data *sdd,
 	struct device *dev = &sdd->pdev->dev;
 	struct spi_transfer *xfer;
 
-	if (msg->is_dma_mapped)
+	if (is_polling(sdd) || msg->is_dma_mapped)
 		return 0;
 
 	/* First mark all xfer unmapped */
@@ -635,7 +684,7 @@ static void s3c64xx_spi_unmap_mssg(struct s3c64xx_spi_driver_data *sdd,
 	struct device *dev = &sdd->pdev->dev;
 	struct spi_transfer *xfer;
 
-	if (msg->is_dma_mapped)
+	if (is_polling(sdd) || msg->is_dma_mapped)
 		return;
 
 	list_for_each_entry(xfer, &msg->transfers, transfer_list) {
@@ -713,7 +762,8 @@ static int s3c64xx_spi_transfer_one_message(struct spi_master *master,
 		}
 
 		/* Polling method for xfers not bigger than FIFO capacity */
-		if (xfer->len <= ((FIFO_LVL_MASK(sdd) >> 1) + 1))
+		if (is_polling(sdd) ||
+			xfer->len <= ((FIFO_LVL_MASK(sdd) >> 1) + 1))
 			use_dma = 0;
 		else
 			use_dma = 1;
@@ -729,17 +779,10 @@ static int s3c64xx_spi_transfer_one_message(struct spi_master *master,
 		/* Slave Select */
 		enable_cs(sdd, spi);
 
-		/* Start the signals */
-		writel(0, sdd->regs + S3C64XX_SPI_SLAVE_SEL);
-
 		spin_unlock_irqrestore(&sdd->lock, flags);
 
 		status = wait_for_xfer(sdd, xfer, use_dma);
 
-		/* Quiese the signals */
-		writel(S3C64XX_SPI_SLAVE_SIG_INACT,
-		       sdd->regs + S3C64XX_SPI_SLAVE_SEL);
-
 		if (status) {
 			dev_err(&spi->dev, "I/O Error: rx-%d tx-%d res:rx-%c tx-%c len-%d\n",
 				xfer->rx_buf ? 1 : 0, xfer->tx_buf ? 1 : 0,
@@ -795,7 +838,7 @@ static int s3c64xx_spi_prepare_transfer(struct spi_master *spi)
 	struct s3c64xx_spi_driver_data *sdd = spi_master_get_devdata(spi);
 
 	/* Acquire DMA channels */
-	while (!acquire_dma(sdd))
+	while (!is_polling(sdd) && !acquire_dma(sdd))
 		usleep_range(10000, 11000);
 
 	pm_runtime_get_sync(&sdd->pdev->dev);
@@ -808,8 +851,10 @@ static int s3c64xx_spi_unprepare_transfer(struct spi_master *spi)
 	struct s3c64xx_spi_driver_data *sdd = spi_master_get_devdata(spi);
 
 	/* Free DMA channels */
-	sdd->ops->release(sdd->rx_dma.ch, &s3c64xx_spi_dma_client);
-	sdd->ops->release(sdd->tx_dma.ch, &s3c64xx_spi_dma_client);
+	if (!is_polling(sdd)) {
+		sdd->ops->release(sdd->rx_dma.ch, &s3c64xx_spi_dma_client);
+		sdd->ops->release(sdd->tx_dma.ch, &s3c64xx_spi_dma_client);
+	}
 
 	pm_runtime_put(&sdd->pdev->dev);
 
@@ -1220,19 +1265,19 @@ static int s3c64xx_spi_probe(struct platform_device *pdev)
 	if (!sdd->pdev->dev.of_node) {
 		res = platform_get_resource(pdev, IORESOURCE_DMA,  0);
 		if (!res) {
-			dev_err(&pdev->dev, "Unable to get SPI tx dma "
-					"resource\n");
-			return -ENXIO;
-		}
-		sdd->tx_dma.dmach = res->start;
+			dev_warn(&pdev->dev, "Unable to get SPI tx dma "
+					"resource. Switching to poll mode\n");
+			sdd->port_conf->quirks = S3C64XX_SPI_QUIRK_POLL;
+		} else
+			sdd->tx_dma.dmach = res->start;
 
 		res = platform_get_resource(pdev, IORESOURCE_DMA,  1);
 		if (!res) {
-			dev_err(&pdev->dev, "Unable to get SPI rx dma "
-					"resource\n");
-			return -ENXIO;
-		}
-		sdd->rx_dma.dmach = res->start;
+			dev_warn(&pdev->dev, "Unable to get SPI rx dma "
+					"resource. Switching to poll mode\n");
+			sdd->port_conf->quirks = S3C64XX_SPI_QUIRK_POLL;
+		} else
+			sdd->rx_dma.dmach = res->start;
 	}
 
 	sdd->tx_dma.direction = DMA_MEM_TO_DEV;
-- 
1.7.5.4



From girishks2000 at gmail.com  Mon Apr 15 04:40:29 2013
From: girishks2000 at gmail.com (Girish K S)
Date: Mon, 15 Apr 2013 14:10:29 +0530
Subject: [PATCH V4 4/5] spi: s3c64xx: Added provision for dedicated cs pin
In-Reply-To: <1366015230-18243-1-git-send-email-ks.giri@samsung.com>
References: <1366015230-18243-1-git-send-email-ks.giri@samsung.com>
Message-ID: <1366015230-18243-3-git-send-email-ks.giri@samsung.com>

From: Girish K S <girishks2000 at gmail.com>

The existing driver supports gpio based /cs signal.
For controller's that have one device per controller,
the slave device's /cs signal might be internally controlled
by the chip select bit of slave select register. They are not
externally asserted/deasserted using gpio pin.

This patch adds support for controllers with dedicated /cs pin.
if "cs-gpio" property doesnt exist in a spi dts node, the controller
would treat the /cs pin as dedicated.

Signed-off-by: Girish K S <ks.giri at samsung.com>
---
changes in v4:
		moved the struct member cs_gpio from platform data to driver
private data.

changes in v3:
		detelted the quirk for GPIO and handled it in the dts file

changes in v2:
		separated the gpio ios and cs gpio as separate patches

 drivers/spi/spi-s3c64xx.c |   32 ++++++++++++++++++++++++--------
 1 files changed, 24 insertions(+), 8 deletions(-)

diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index 79de18f..7fdc940 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -202,6 +202,7 @@ struct s3c64xx_spi_driver_data {
 	struct s3c64xx_spi_port_config	*port_conf;
 	unsigned int			port_id;
 	unsigned long			gpios[4];
+	bool				cs_gpio;
 };
 
 static struct s3c2410_dma_client s3c64xx_spi_dma_client = {
@@ -414,14 +415,16 @@ static inline void enable_cs(struct s3c64xx_spi_driver_data *sdd,
 		if (sdd->tgl_spi != spi) { /* if last mssg on diff device */
 			/* Deselect the last toggled device */
 			cs = sdd->tgl_spi->controller_data;
-			gpio_set_value(cs->line,
-				spi->mode & SPI_CS_HIGH ? 0 : 1);
+			if (sdd->cs_gpio)
+				gpio_set_value(cs->line,
+					spi->mode & SPI_CS_HIGH ? 0 : 1);
 		}
 		sdd->tgl_spi = NULL;
 	}
 
 	cs = spi->controller_data;
-	gpio_set_value(cs->line, spi->mode & SPI_CS_HIGH ? 1 : 0);
+	if (sdd->cs_gpio)
+		gpio_set_value(cs->line, spi->mode & SPI_CS_HIGH ? 1 : 0);
 
 	/* Start the signals */
 	writel(0, sdd->regs + S3C64XX_SPI_SLAVE_SEL);
@@ -550,7 +553,8 @@ static inline void disable_cs(struct s3c64xx_spi_driver_data *sdd,
 	if (sdd->tgl_spi == spi)
 		sdd->tgl_spi = NULL;
 
-	gpio_set_value(cs->line, spi->mode & SPI_CS_HIGH ? 0 : 1);
+	if (sdd->cs_gpio)
+		gpio_set_value(cs->line, spi->mode & SPI_CS_HIGH ? 0 : 1);
 
 	/* Quiese the signals */
 	writel(S3C64XX_SPI_SLAVE_SIG_INACT, sdd->regs + S3C64XX_SPI_SLAVE_SEL);
@@ -888,7 +892,10 @@ static struct s3c64xx_spi_csinfo *s3c64xx_get_slave_ctrldata(
 		return ERR_PTR(-ENOMEM);
 	}
 
-	cs->line = of_get_named_gpio(data_np, "cs-gpio", 0);
+	/* The CS line is asserted/deasserted by the gpio pin */
+	if (sdd->cs_gpio)
+		cs->line = of_get_named_gpio(data_np, "cs-gpio", 0);
+
 	if (!gpio_is_valid(cs->line)) {
 		dev_err(&spi->dev, "chip select gpio is not specified or invalid\n");
 		kfree(cs);
@@ -928,7 +935,8 @@ static int s3c64xx_spi_setup(struct spi_device *spi)
 		return -ENODEV;
 	}
 
-	if (!spi_get_ctldata(spi)) {
+	/* Request gpio only if cs line is asserted by gpio pins */
+	if (sdd->cs_gpio) {
 		err = gpio_request_one(cs->line, GPIOF_OUT_INIT_HIGH,
 				       dev_name(&spi->dev));
 		if (err) {
@@ -937,9 +945,11 @@ static int s3c64xx_spi_setup(struct spi_device *spi)
 				cs->line, err);
 			goto err_gpio_req;
 		}
-		spi_set_ctldata(spi, cs);
 	}
 
+	if (!spi_get_ctldata(spi))
+		spi_set_ctldata(spi, cs);
+
 	sci = sdd->cntrlr_info;
 
 	spin_lock_irqsave(&sdd->lock, flags);
@@ -1026,8 +1036,10 @@ err_gpio_req:
 static void s3c64xx_spi_cleanup(struct spi_device *spi)
 {
 	struct s3c64xx_spi_csinfo *cs = spi_get_ctldata(spi);
+	struct s3c64xx_spi_driver_data *sdd;
 
-	if (cs) {
+	sdd = spi_master_get_devdata(spi->master);
+	if (cs && sdd->cs_gpio) {
 		gpio_free(cs->line);
 		if (spi->dev.of_node)
 			kfree(cs);
@@ -1256,7 +1268,11 @@ static int s3c64xx_spi_probe(struct platform_device *pdev)
 	sdd->cntrlr_info = sci;
 	sdd->pdev = pdev;
 	sdd->sfr_start = mem_res->start;
+	sdd->cs_gpio = false;
 	if (pdev->dev.of_node) {
+		if (of_find_property(pdev->dev.of_node, "cs-gpio", NULL))
+			sdd->cs_gpio = true;
+
 		ret = of_alias_get_id(pdev->dev.of_node, "spi");
 		if (ret < 0) {
 			dev_err(&pdev->dev, "failed to get alias id, errno %d\n",
-- 
1.7.5.4



From girishks2000 at gmail.com  Mon Apr 15 04:40:30 2013
From: girishks2000 at gmail.com (Girish K S)
Date: Mon, 15 Apr 2013 14:10:30 +0530
Subject: [PATCH RESEND V3 5/5] spi: s3c64xx: Added support for exynos5440 spi
In-Reply-To: <1366015230-18243-1-git-send-email-ks.giri@samsung.com>
References: <1366015230-18243-1-git-send-email-ks.giri@samsung.com>
Message-ID: <1366015230-18243-4-git-send-email-ks.giri@samsung.com>

From: Girish K S <girishks2000 at gmail.com>

This patch adds support for the exynos5440 spi controller.
The integration of the spi IP in exynos5440 is different from
other SoC's. The I/O pins are no more configured via gpio, they
have dedicated pins.

Signed-off-by: Girish K S <ks.giri at samsung.com>
---
 drivers/spi/spi-s3c64xx.c |   12 ++++++++++++
 1 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index 7fdc940..01db8f7 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -1550,6 +1550,15 @@ static struct s3c64xx_spi_port_config exynos4_spi_port_config = {
 	.clk_from_cmu	= true,
 };
 
+static struct s3c64xx_spi_port_config exynos5440_spi_port_config = {
+	.fifo_lvl_mask	= { 0x1ff },
+	.rx_lvl_offset	= 15,
+	.tx_st_done	= 25,
+	.high_speed	= true,
+	.clk_from_cmu	= true,
+	.quirks		= S3C64XX_SPI_QUIRK_POLL,
+};
+
 static struct platform_device_id s3c64xx_spi_driver_ids[] = {
 	{
 		.name		= "s3c2443-spi",
@@ -1578,6 +1587,9 @@ static const struct of_device_id s3c64xx_spi_dt_match[] = {
 	{ .compatible = "samsung,exynos4210-spi",
 			.data = (void *)&exynos4_spi_port_config,
 	},
+	{ .compatible = "samsung,exynos5440-spi",
+			.data = (void *)&exynos5440_spi_port_config,
+	},
 	{ },
 };
 MODULE_DEVICE_TABLE(of, s3c64xx_spi_dt_match);
-- 
1.7.5.4



From arnd at arndb.de  Mon Apr 15 04:41:44 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 15 Apr 2013 10:41:44 +0200
Subject: [PATCH 3/7] ARM: exynos: add missing properties for combiner IRQs
In-Reply-To: <CAK9yfHzubnyo7wD4gmmjLobkoy2qPXWyPp-0GQq8wiJH1PWZTg@mail.gmail.com>
References: <1365775405-115297-1-git-send-email-arnd@arndb.de>
 <1365775405-115297-4-git-send-email-arnd@arndb.de>
 <CAK9yfHzubnyo7wD4gmmjLobkoy2qPXWyPp-0GQq8wiJH1PWZTg@mail.gmail.com>
Message-ID: <201304151041.44805.arnd@arndb.de>

On Monday 15 April 2013, Sachin Kamat wrote:
> On 12 April 2013 19:33, Arnd Bergmann <arnd at arndb.de> wrote:

> >
> >         combiner:interrupt-controller at 10440000 {
> > +               combiner-nr = <16>;
> 
> I think this should be "samsung,combiner-nr"
> Without this i see the following message in boot log:
> "combiner_of_init: number of combiners not specified"

Right, thanks!

> > diff --git a/arch/arm/boot/dts/exynos4212.dtsi b/arch/arm/boot/dts/exynos4212.dtsi
> > index 36d4299..f83c3c1 100644
> > --- a/arch/arm/boot/dts/exynos4212.dtsi
> > +++ b/arch/arm/boot/dts/exynos4212.dtsi
> > @@ -26,6 +26,15 @@
> >                 cpu-offset = <0x8000>;
> >         };
> >
> > +       interrupt-controller at 10440000 {
> 
> Don't we need a node name here (combiner:interrupt-controller at 10440000)?

Why? The "combiner:" part is just a label. Actually I think the preferred
syntax is 

&combiner {
	samsung,combiner-nr = <18>;	
};

which is much shorter to write, but I did not want to change the style used
in the rest of the file.

> > +                combiner-nr = <18>;
>     ^^^^^^^^^^^
> nit: tabs instead of space would look better.

I fixed that up locally, but I think I sent out the wrong version.

> > diff --git a/arch/arm/boot/dts/exynos4412.dtsi b/arch/arm/boot/dts/exynos4412.dtsi
> > index d75c047..4cb657e 100644
> > --- a/arch/arm/boot/dts/exynos4412.dtsi
> > +++ b/arch/arm/boot/dts/exynos4412.dtsi
> > @@ -26,6 +26,15 @@
> >                 cpu-offset = <0x4000>;
> >         };
> >
> > +       interrupt-controller at 10440000 {
> > +               combiner-nr = <20>;
> Same as above (for exynos4212.dtsi).
> 
> > +               interrupts = <0 0 0>, <0 1 0>, <0 2 0>, <0 3 0>,
> > +                            <0 4 0>, <0 5 0>, <0 6 0>, <0 7 0>,
> > +                            <0 8 0>, <0 9 0>, <0 10 0>, <0 11 0>,
> > +                            <0 12 0>, <0 13 0>, <0 14 0>, <0 15 0>,
> > +                            <0 107 0>, <0 108 0>>, <0 48 0>, <0 42 0>;
>                                                               ^^^
> Syntax error.
> 
> We have a combiner node defined in exynos4x12.dtsi. With the bindings
> now defined separately in 4212 and 4412 dtsi files, probably the one
> in 4x12 could be dropped?

I did not see that one, but it seems to have the wrong numbers in the last
four interrupt specifiers. I think it would be better to just fix that one
and keep using it.

	Arnd


From marc.zyngier at arm.com  Mon Apr 15 04:43:11 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon, 15 Apr 2013 10:43:11 +0200
Subject: [PATCH] ARM: KVM: iterate over all CPUs for CPU compatibility
 check
In-Reply-To: <CAEDV+gJuFG49oQ=BEaCHcTP=nHVyX8ALw6076dR_C1s7TuyqXQ@mail.gmail.com>
References: <1365771875-5788-1-git-send-email-andre.przywara@linaro.org>
 <51680AF9.7040109@arm.com>
 <CAEDV+g+E8PLc60vMRhq4O_AL2WjmYDLb6=Wh34ynhevh7uAGJA@mail.gmail.com>
 <d455f2823b9639af8d38d30f2c3234bd@localhost>
 <CAEDV+gJuFG49oQ=BEaCHcTP=nHVyX8ALw6076dR_C1s7TuyqXQ@mail.gmail.com>
Message-ID: <d47697abd39a0d5d41f5ac110a40e261@localhost>

On Mon, 15 Apr 2013 01:28:25 -0700, Christoffer Dall
<cdall at cs.columbia.edu> wrote:
> On Mon, Apr 15, 2013 at 12:50 AM, Marc Zyngier <marc.zyngier at arm.com>
> wrote:
>> On Sun, 14 Apr 2013 21:57:36 -0700, Christoffer Dall
>> <cdall at cs.columbia.edu> wrote:
>>> On Fri, Apr 12, 2013 at 6:24 AM, Marc Zyngier <marc.zyngier at arm.com>
>> wrote:
>>>> On 12/04/13 14:04, Andre Przywara wrote:
>>>>> kvm_target_cpus() checks the compatibility of the used CPU with
>>>>> KVM, which is currently limited to ARM Cortex-A15 cores.
>>>>> However by calling it only once on any random CPU it assumes that
>>>>> all cores are the same, which is not true for big.LITTLE parts.
>>>>>
>>>>> After doing about 40 boots on a TC-2 core tile, I found it running
>>>>> in all but one case on one of the A7 cores (which correctly denied
>>>>> KVM initialization). On the 39th boot however the code ran on
>>>>> an A15, leading to a hang after returning success:
>>>>>
>>>>> ...
>>>>> TCP: reno registered
>>>>> UDP hash table entries: 512 (order: 2, 16384 bytes)
>>>>> UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
>>>>> NET: Registered protocol family 1
>>>>> kvm_target_cpu() on CPU #1, part is c0f0
>>>>>  ... (pause for a while) ...
>>>>> INFO: rcu_sched self-detected stall on CPUINFO: rcu_sched detected
>>>>> stalls on CPU
>>>>> s/tasks: { 1} (detected by 0, t=6002 jiffies, g=4294966999,
>>>>> c=4294966998, q=15)
>>>>> Task dump for CPU 1:
>>>>> swapper/0       R running      0     1      0 0x00000002
>>>>>
>>>>> So iterate over every CPU to correctly determine the capability of
>>>>> the system to run the current KVM implementation.
>>>>> In case a big.LITTLE configuration is the reason for denial, give
>>>>> the user a hint how to get it running anyway (maxcpus= on the kernel
>>>>> command line).
>>>>>
>>>>> Please push this still into 3.9.
>>>>>
>>>>> Signed-off-by: Andre Przywara <andre.przywara at linaro.org>
>>>>
>>>> [...]
>>>>
>>>> Nak. The fact that one of the CPUs seem to hang is a sure sign that
>>>> something is severely broken, and you definitely want to fix that
>> issue,
>>>> instead of blindly ignoring it.
>>>>
>>>> Additionally, it seems you're just papering over the issue. You
should
>>>> be able to exclude the A7 processors, but not completely deny KVM
from
>>>> running on the hardware.
>>>>
>>> Marc, I disagree with this nak. If the current kernel breaks boot on a
>>> Big.Little system, we need to take care of that first, and the
>>> proposed patch is a quick way to do so, and it does not stand in the
>>> way of introducing proper Big.Little support in any way, which I'm
>>> sure is going to open up a lot of other interesting questions.
>>>
>>> I'm going to take this one.
>>
>> That's your privilege.
>>
>> Now, my objections about this patch still stand:
>> - It papers over what looks like a serious bug (CPU hanging? bah, let's
>> not bother with that). It is an A15 hanging here by the way, not an A7.
> 
> I missed that part. Are we even sure then that this is related to
> running on Big.Little?

The log is way to terse to tell. I asked Andre to investigate this in a
separate email (I'm away from my TC2 for a while).

>> - It forces the user to choose between 5 CPUs and KVM (while simply
>> setting thread affinity would solve the problem this patch tries to
>> solve).
> 
> But this happens during boot, so thread affinity won't really be a
> valid work around for this...

Just refuse to initialize KVM on the A7s, display a warning indicating the
*valid* CPUs, and let the user use taskset to run their KVM guest. And/or
enforce this in the kernel when hitting vcpu initialisation (using
sched_setaffinity).

>> - It reports potentially wrong information (setting maxcpus= will
>> probably
>> do the wrong thing if cluster 0 is A7 based).
> 
> ok, fair enough.
> 
>>
>> For these reasons, I'm still strongly opposed to this patch being
merged.
>> Yes, this is a quick way to hide a (much) bigger problem, but in no way
a
>> fix.
>>
> 
> I'm not claiming this to be a fix for the underlying problem, and I
> would much rather see a proper fix. But, I also don't want kernels
> configured with KVM to cause systems not to boot and if we can prevent
> that from happening for now, in whichever rough possible way, I think
> that takes priority.

I agree with this. I disagree with the method.

> Right now all the code is written with the inherent assumption that
> we're running on an A15, and while I did not scrutinize if some of our
> code can break the host if run on an A7, we should probably make sure
> that doesn't happen until we actively support Big.Little and A7.  I
> think relying on users not to crash their kernels by setting CPU
> affinities is also a big mistake.

KVM initialization on A7 should really already work as it is. If it
doesn't, then it is a bug that is waiting to occur on A15. And the above
hang may just be a sign that the problem is actually occurring already.

As for the affinity, we can enforce this very easily.

        M.
-- 
Fast, cheap, reliable. Pick two.


From maxime.ripard at free-electrons.com  Mon Apr 15 04:45:02 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Mon, 15 Apr 2013 10:45:02 +0200
Subject: [PATCH 3/3] ARM: sunxi: unify osc24M_fixed and osc24M
In-Reply-To: <1365515284-32061-4-git-send-email-emilio@elopez.com.ar>
References: <1365515284-32061-1-git-send-email-emilio@elopez.com.ar>
 <1365515284-32061-4-git-send-email-emilio@elopez.com.ar>
Message-ID: <516BBE0E.2010007@free-electrons.com>

Hi,

Le 09/04/2013 15:48, Emilio L?pez a ?crit :
> Now that the clock driver supports the gatable oscillator as one single
> clock, drop osc24M_fixed and move the relevant properties to osc24M
> 
> Signed-off-by: Emilio L?pez <emilio at elopez.com.ar>

Rebased and applied in my dt-for-3.10 branch.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


From rogerq at ti.com  Mon Apr 15 04:48:41 2013
From: rogerq at ti.com (Roger Quadros)
Date: Mon, 15 Apr 2013 11:48:41 +0300
Subject: [PATCH] ARM: dts: omap4-panda: Add USB Host support
Message-ID: <1366015721-25608-1-git-send-email-rogerq@ti.com>

Provide the RESET and Power regulators for the USB PHY,
the USB Host port mode and the PHY device.

The USB PHY needs AUXCLK3 to operate. Provide this information
as well.

Also provide pin multiplexer information for the USB host
pins.

This patch depends on OMAP clock binding introduced in
https://lkml.org/lkml/2013/4/12/407

CC: Beno?t Cousson <b-cousson at ti.com>
Signed-off-by: Roger Quadros <rogerq at ti.com>
---
 arch/arm/boot/dts/omap4-panda-common.dtsi |   58 +++++++++++++++++++++++++++++
 arch/arm/boot/dts/omap4.dtsi              |    5 ++
 2 files changed, 63 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 03bd60d..628f744 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -54,6 +54,38 @@
 			"AFML", "Line In",
 			"AFMR", "Line In";
 	};
+
+	/* HS USB Port 1 RESET */
+	hsusb1_reset: hsusb1_reset_reg {
+		compatible = "regulator-fixed";
+		regulator-name = "hsusb1_reset";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		gpio = <&gpio2 30 0>;	/* gpio_62 */
+		startup-delay-us = <70000>;
+		enable-active-high;
+	};
+
+	/* HS USB Port 1 Power */
+	hsusb1_power: hsusb1_power_reg {
+		compatible = "regulator-fixed";
+		regulator-name = "hsusb1_vbus";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		gpio = <&gpio1 1 0>;	/* gpio_1 */
+		startup-delay-us = <70000>;
+		enable-active-high;
+	};
+
+	/* HS USB Host PHY on PORT 1 */
+	hsusb1_phy: hsusb1_phy {
+		compatible = "usb-nop-xceiv";
+		reset-supply = <&hsusb1_reset>;
+		vcc-supply = <&hsusb1_power>;
+		clocks = <&auxclk3>;
+		clock-names = "main_clk";
+		clock-frequency = <19200000>;
+	};
 };
 
 &omap4_pmx_core {
@@ -64,6 +96,7 @@
 			&mcbsp1_pins
 			&dss_hdmi_pins
 			&tpd12s015_pins
+			&hsusbb1_pins
 	>;
 
 	twl6040_pins: pinmux_twl6040_pins {
@@ -108,6 +141,23 @@
 		>;
 	};
 
+	hsusbb1_pins: pinmux_hsusbb1_pins {
+		pinctrl-single,pins = <
+			0x82 0x10C	/* USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_clk INPUT | PULLDOWN */
+			0x84 0x4	/* USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_stp OUTPUT */
+			0x86 0x104	/* USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dir INPUT | PULLDOWN */
+			0x88 0x104	/* USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_nxt INPUT | PULLDOWN */
+			0x8a 0x104	/* USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat0 INPUT | PULLDOWN */
+			0x8c 0x104	/* USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat1 INPUT | PULLDOWN */
+			0x8e 0x104	/* USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat2 INPUT | PULLDOWN */
+			0x90 0x104	/* USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat3 INPUT | PULLDOWN */
+			0x92 0x104	/* USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat4 INPUT | PULLDOWN */
+			0x94 0x104	/* USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat5 INPUT | PULLDOWN */
+			0x96 0x104	/* USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat6 INPUT | PULLDOWN */
+			0x98 0x104	/* USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat7 INPUT | PULLDOWN */
+		>;
+	};
+
 	i2c1_pins: pinmux_i2c1_pins {
 		pinctrl-single,pins = <
 			0xe2 0x118        /* i2c1_scl PULLUP | INPUTENABLE | MODE0 */
@@ -249,3 +299,11 @@
 	mode = <3>;
 	power = <50>;
 };
+
+&usbhshost {
+	port1-mode = "ehci-phy";
+};
+
+&usbhsehci {
+	phys = <&hsusb1_phy>;
+};
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 2a56428..bd6036e 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -660,5 +660,10 @@
 			ram-bits = <12>;
 			ti,has-mailbox;
 		};
+
+		auxclk3: auxclk3 {
+			#clock-cells = <0>;
+			compatible = "ti,omap-clock";
+		};
 	};
 };
-- 
1.7.4.1



From cdall at cs.columbia.edu  Mon Apr 15 04:54:30 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Mon, 15 Apr 2013 01:54:30 -0700
Subject: [PATCH] ARM: KVM: iterate over all CPUs for CPU compatibility
 check
In-Reply-To: <d47697abd39a0d5d41f5ac110a40e261@localhost>
References: <1365771875-5788-1-git-send-email-andre.przywara@linaro.org>
 <51680AF9.7040109@arm.com>
 <CAEDV+g+E8PLc60vMRhq4O_AL2WjmYDLb6=Wh34ynhevh7uAGJA@mail.gmail.com>
 <d455f2823b9639af8d38d30f2c3234bd@localhost>
 <CAEDV+gJuFG49oQ=BEaCHcTP=nHVyX8ALw6076dR_C1s7TuyqXQ@mail.gmail.com>
 <d47697abd39a0d5d41f5ac110a40e261@localhost>
Message-ID: <CAEDV+gK9==sXYxRVZ8JVFYPiw3_xgzZBbydEwPunmnocNLKXrQ@mail.gmail.com>

On Mon, Apr 15, 2013 at 1:43 AM, Marc Zyngier <marc.zyngier at arm.com> wrote:
> On Mon, 15 Apr 2013 01:28:25 -0700, Christoffer Dall
> <cdall at cs.columbia.edu> wrote:
>> On Mon, Apr 15, 2013 at 12:50 AM, Marc Zyngier <marc.zyngier at arm.com>
>> wrote:
>>> On Sun, 14 Apr 2013 21:57:36 -0700, Christoffer Dall
>>> <cdall at cs.columbia.edu> wrote:
>>>> On Fri, Apr 12, 2013 at 6:24 AM, Marc Zyngier <marc.zyngier at arm.com>
>>> wrote:
>>>>> On 12/04/13 14:04, Andre Przywara wrote:
>>>>>> kvm_target_cpus() checks the compatibility of the used CPU with
>>>>>> KVM, which is currently limited to ARM Cortex-A15 cores.
>>>>>> However by calling it only once on any random CPU it assumes that
>>>>>> all cores are the same, which is not true for big.LITTLE parts.
>>>>>>
>>>>>> After doing about 40 boots on a TC-2 core tile, I found it running
>>>>>> in all but one case on one of the A7 cores (which correctly denied
>>>>>> KVM initialization). On the 39th boot however the code ran on
>>>>>> an A15, leading to a hang after returning success:
>>>>>>
>>>>>> ...
>>>>>> TCP: reno registered
>>>>>> UDP hash table entries: 512 (order: 2, 16384 bytes)
>>>>>> UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
>>>>>> NET: Registered protocol family 1
>>>>>> kvm_target_cpu() on CPU #1, part is c0f0
>>>>>>  ... (pause for a while) ...
>>>>>> INFO: rcu_sched self-detected stall on CPUINFO: rcu_sched detected
>>>>>> stalls on CPU
>>>>>> s/tasks: { 1} (detected by 0, t=6002 jiffies, g=4294966999,
>>>>>> c=4294966998, q=15)
>>>>>> Task dump for CPU 1:
>>>>>> swapper/0       R running      0     1      0 0x00000002
>>>>>>
>>>>>> So iterate over every CPU to correctly determine the capability of
>>>>>> the system to run the current KVM implementation.
>>>>>> In case a big.LITTLE configuration is the reason for denial, give
>>>>>> the user a hint how to get it running anyway (maxcpus= on the kernel
>>>>>> command line).
>>>>>>
>>>>>> Please push this still into 3.9.
>>>>>>
>>>>>> Signed-off-by: Andre Przywara <andre.przywara at linaro.org>
>>>>>
>>>>> [...]
>>>>>
>>>>> Nak. The fact that one of the CPUs seem to hang is a sure sign that
>>>>> something is severely broken, and you definitely want to fix that
>>> issue,
>>>>> instead of blindly ignoring it.
>>>>>
>>>>> Additionally, it seems you're just papering over the issue. You
> should
>>>>> be able to exclude the A7 processors, but not completely deny KVM
> from
>>>>> running on the hardware.
>>>>>
>>>> Marc, I disagree with this nak. If the current kernel breaks boot on a
>>>> Big.Little system, we need to take care of that first, and the
>>>> proposed patch is a quick way to do so, and it does not stand in the
>>>> way of introducing proper Big.Little support in any way, which I'm
>>>> sure is going to open up a lot of other interesting questions.
>>>>
>>>> I'm going to take this one.
>>>
>>> That's your privilege.
>>>
>>> Now, my objections about this patch still stand:
>>> - It papers over what looks like a serious bug (CPU hanging? bah, let's
>>> not bother with that). It is an A15 hanging here by the way, not an A7.
>>
>> I missed that part. Are we even sure then that this is related to
>> running on Big.Little?
>
> The log is way to terse to tell. I asked Andre to investigate this in a
> separate email (I'm away from my TC2 for a while).
>
>>> - It forces the user to choose between 5 CPUs and KVM (while simply
>>> setting thread affinity would solve the problem this patch tries to
>>> solve).
>>
>> But this happens during boot, so thread affinity won't really be a
>> valid work around for this...
>
> Just refuse to initialize KVM on the A7s, display a warning indicating the
> *valid* CPUs, and let the user use taskset to run their KVM guest. And/or
> enforce this in the kernel when hitting vcpu initialisation (using
> sched_setaffinity).
>
>>> - It reports potentially wrong information (setting maxcpus= will
>>> probably
>>> do the wrong thing if cluster 0 is A7 based).
>>
>> ok, fair enough.
>>
>>>
>>> For these reasons, I'm still strongly opposed to this patch being
> merged.
>>> Yes, this is a quick way to hide a (much) bigger problem, but in no way
> a
>>> fix.
>>>
>>
>> I'm not claiming this to be a fix for the underlying problem, and I
>> would much rather see a proper fix. But, I also don't want kernels
>> configured with KVM to cause systems not to boot and if we can prevent
>> that from happening for now, in whichever rough possible way, I think
>> that takes priority.
>
> I agree with this. I disagree with the method.
>
>> Right now all the code is written with the inherent assumption that
>> we're running on an A15, and while I did not scrutinize if some of our
>> code can break the host if run on an A7, we should probably make sure
>> that doesn't happen until we actively support Big.Little and A7.  I
>> think relying on users not to crash their kernels by setting CPU
>> affinities is also a big mistake.
>
> KVM initialization on A7 should really already work as it is. If it
> doesn't, then it is a bug that is waiting to occur on A15. And the above
> hang may just be a sign that the problem is actually occurring already.
>
> As for the affinity, we can enforce this very easily.
>
OK, but let's not go down this road until we've verified that this is
really an issue that needs to be handled by excluding A7s.  Andre, can
you give us some more details?


From mark.rutland at arm.com  Mon Apr 15 05:09:04 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Mon, 15 Apr 2013 10:09:04 +0100
Subject: [RFCv2 0/2] Representing interrupt affinity in devicetree
In-Reply-To: <20130413213322.7C6193E2249@localhost>
References: <1355417368-6861-1-git-send-email-mark.rutland@arm.com>
 <20130304025115.05D413E17F8@localhost>
 <20130305092849.GA15661@e106331-lin.cambridge.arm.com>
 <20130413213322.7C6193E2249@localhost>
Message-ID: <20130415090904.GF8151@e106331-lin.cambridge.arm.com>

On Sat, Apr 13, 2013 at 10:33:22PM +0100, Grant Likely wrote:
> On Tue, 5 Mar 2013 09:28:49 +0000, Mark Rutland <mark.rutland at arm.com> wrote:
> > On Mon, Mar 04, 2013 at 02:51:14AM +0000, Grant Likely wrote:
> > > I could use some more context for how this will be used. Do device
> > > drivers need to be aware of which CPU can handle an interrupt for a
> > > device, or is it the sort of thing that can be done in the background
> > > when an irq is requested? What are some examples of device drivers using
> > > this interface.
> > 
> > The main users I can think of for this would be PMUs in multi-cluster systems,
> > where we may have differing PMUs in each cluster. The driver for each needs to
> > know the set of CPUs it's handling, and which CPU each interrupt is affine to.
> > 
> > With the above binding scheme, we'd describe the A15x2 A7x3 CoreTile's PMUs
> > something like:
> > 
> > pmu_a15s {
> > 	compatible = "arm,cortex-a15-pmu";
> > 	interrupts = <0 68 4>,
> > 	             <0 69 4>;
> > 	interrupts-affinity = <0 0x0>,
> > 	                      <0 0x1>;
> > };
> > 
> > pmu_a7s {
> > 	compatible = arm,cortex-a7-pmu";
> > 	interrupts = <0 128 4>,
> > 	             <0 129 4>,
> > 	             <0 130 4>;
> > 	interrupts-affinity = <0 0x100>,
> > 	                      <0 0x101>,
> > 	                      <0 0x102>;
> > };
> 
> That does sound an awful lot like what Lorenzo has been trying to solve.
> I really do think that you need to coordinate with him.

Indeed it does. Lorenzo and I have been working together on this, and having
realised issues with the above approach, we've put a new series together [1]
which we both believe has a more workable approach.

Mark.

[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2013-April/162457.html


From peter.maydell at linaro.org  Mon Apr 15 05:14:02 2013
From: peter.maydell at linaro.org (Peter Maydell)
Date: Mon, 15 Apr 2013 10:14:02 +0100
Subject: [PATCH] ARM: KVM: iterate over all CPUs for CPU compatibility
 check
In-Reply-To: <CAEDV+gK9==sXYxRVZ8JVFYPiw3_xgzZBbydEwPunmnocNLKXrQ@mail.gmail.com>
References: <1365771875-5788-1-git-send-email-andre.przywara@linaro.org>
 <51680AF9.7040109@arm.com>
 <CAEDV+g+E8PLc60vMRhq4O_AL2WjmYDLb6=Wh34ynhevh7uAGJA@mail.gmail.com>
 <d455f2823b9639af8d38d30f2c3234bd@localhost>
 <CAEDV+gJuFG49oQ=BEaCHcTP=nHVyX8ALw6076dR_C1s7TuyqXQ@mail.gmail.com>
 <d47697abd39a0d5d41f5ac110a40e261@localhost>
 <CAEDV+gK9==sXYxRVZ8JVFYPiw3_xgzZBbydEwPunmnocNLKXrQ@mail.gmail.com>
Message-ID: <CAFEAcA-bPoa8YoPuHPmupzfUW+yR233XquK79eNorzcRpFiK=g@mail.gmail.com>

On 15 April 2013 09:54, Christoffer Dall <cdall at cs.columbia.edu> wrote:
> On Mon, Apr 15, 2013 at 1:43 AM, Marc Zyngier <marc.zyngier at arm.com> wrote:
>> As for the affinity, we can enforce this very easily.
>>
> OK, but let's not go down this road until we've verified that this is
> really an issue that needs to be handled by excluding A7s.  Andre, can
> you give us some more details?

We *must* exclude KVM vcpu threads from ever running on A7s,
because the cp15 handling code as it stands does not virtualize
various registers (most notably the ID/feature registers) and
so the vcpu will bounce between "looks like an A15" and "looks
like a weird hybrid between A7 and A15".

Assuming we don't want to tackle full big.LITTLE host support
right now, I can see two options:
 * forbid KVM completely on a system with any non-A15s
 * force KVM vcpus to only ever run on the A15s [Q: does
   all the hyp mode code have to also run on the A15s or
   is it A7-safe?]

-- PMM


From andrew.murray at arm.com  Mon Apr 15 05:31:15 2013
From: andrew.murray at arm.com (Andrew Murray)
Date: Mon, 15 Apr 2013 10:31:15 +0100
Subject: [PATCH v4] ARM: pci: create pci_common_init_dev()
In-Reply-To: <1365970932-10998-1-git-send-email-linus.walleij@linaro.org>
References: <1365970932-10998-1-git-send-email-linus.walleij@linaro.org>
Message-ID: <20130415093115.GA3849@arm.com>

On Sun, Apr 14, 2013 at 09:22:12PM +0100, Linus Walleij wrote:
> When working with device tree support for PCI on ARM you run
> into a problem when mapping IRQs from the device tree irqmaps:
> doing this the code in drivers/of/of_pci_irq.c will try to
> find the OF node on the root bridge and this fails, because
> bus->dev.of_node is NULL, and that in turn boils down to
> the fact that pci_set_bus_of_node() has called
> pcibios_get_phb_of_node() from drivers/pci/of.c to obtain
> the OF node of the bridge or its parent and none is set
> and thus NULL is returned.
> 
> Fix this by adding an additional parent argument API for
> registering PCI bridges on the ARM architecture called
> pci_common_init_dev(), and pass along this parent to
> pci_scan_root_bus() called from pcibios_init_hw() in
> bios32.c and voila: the IRQ mappings start working:
> the OF node can be retrieved from the parent.
> 
> Create the old pci_common_init() as a wrapper around
> the new call.
> 
> Cc: Mike Rapoport <mike at compulab.co.il>
> Cc: Russell King <rmk+kernel at arm.linux.org.uk>
> Cc: Ralf Baechle <ralf at linux-mips.org>
> Cc: Andrew Murray <andrew.murray at arm.com>
> Cc: Arnd Bergmann <arnd at arndb.de>
> Cc: Benjamin Herrenschmitt <benh at kernel.crashing.org>
> Reviewed-by: Thierry Reding <thierry.reding at avionic-design.de>
> Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
> ---
> ChangeLog v3->v4:
> - Put opening bracket on its own line.
> - Use the proper rmk+kernel address for Russells CC.
> ---

Reviewed-by: Andrew Murray <andrew.murray at arm.com>


From andre.przywara at linaro.org  Mon Apr 15 05:39:28 2013
From: andre.przywara at linaro.org (Andre Przywara)
Date: Mon, 15 Apr 2013 11:39:28 +0200
Subject: [PATCH] ARM: KVM: iterate over all CPUs for CPU compatibility
 check
In-Reply-To: <CAFEAcA-bPoa8YoPuHPmupzfUW+yR233XquK79eNorzcRpFiK=g@mail.gmail.com>
References: <1365771875-5788-1-git-send-email-andre.przywara@linaro.org>
 <51680AF9.7040109@arm.com>
 <CAEDV+g+E8PLc60vMRhq4O_AL2WjmYDLb6=Wh34ynhevh7uAGJA@mail.gmail.com>
 <d455f2823b9639af8d38d30f2c3234bd@localhost>
 <CAEDV+gJuFG49oQ=BEaCHcTP=nHVyX8ALw6076dR_C1s7TuyqXQ@mail.gmail.com>
 <d47697abd39a0d5d41f5ac110a40e261@localhost>
 <CAEDV+gK9==sXYxRVZ8JVFYPiw3_xgzZBbydEwPunmnocNLKXrQ@mail.gmail.com>
 <CAFEAcA-bPoa8YoPuHPmupzfUW+yR233XquK79eNorzcRpFiK=g@mail.gmail.com>
Message-ID: <516BCAD0.9000708@linaro.org>

On 04/15/2013 11:14 AM, Peter Maydell wrote:
> On 15 April 2013 09:54, Christoffer Dall <cdall at cs.columbia.edu> wrote:
>> On Mon, Apr 15, 2013 at 1:43 AM, Marc Zyngier <marc.zyngier at arm.com> wrote:
>>> As for the affinity, we can enforce this very easily.
>>>
>> OK, but let's not go down this road until we've verified that this is
>> really an issue that needs to be handled by excluding A7s.  Andre, can
>> you give us some more details?

Sure, I am about to collect some data.

>
> We *must* exclude KVM vcpu threads from ever running on A7s,
> because the cp15 handling code as it stands does not virtualize
> various registers (most notably the ID/feature registers) and
> so the vcpu will bounce between "looks like an A15" and "looks
> like a weird hybrid between A7 and A15".

Can't we propagate some least common denominator or safe values for 
those registers instead of propagating the host ones? Or ignore writes 
to them? Or are there any real showstoppers which I overlooked? Things 
like cache architecture properties could just be set to some basic 
values, right?
On x86 propagating too much of host CPU information has proven to be 
problematic, so for instance cache info is very generic. Things are more 
complicated here, because CPUID is (guest) userland accessible.

Eventually the user/qemu should be able to override this, but as a 
default and for now we should inject one fixed handcrafted CPU 
regardless of the actual host CPU. If A7 is easier in this regards, this 
should be considered, too.

> Assuming we don't want to tackle full big.LITTLE host support
> right now, I can see two options:
>   * forbid KVM completely on a system with any non-A15s
>   * force KVM vcpus to only ever run on the A15s

I thought a bit about this. It is not so easy to accomplish in a sane 
way. The CPU is chosen by the scheduler, actually for the QEMU thread. 
taskset could be of use here, but the affinity could be changed at any 
time by userland. I thought about returning -EINVAL for the KVM_RUN 
ioctl if the CPU is not appropriate, but a) QEMU does not know how to 
handle this properly and b) kvm_arch_vcpu_load currently returns void, 
so we would need to change it for all KVM architectures.
Not sure if its worth to establish this until we fix bL support properly.


> [Q: does
>     all the hyp mode code have to also run on the A15s or
>     is it A7-safe?]

Good point. It seems like the code hangs in init_hyp_mode().
Will do more debugging in there now.

Regards,
Andre.



From catalin.marinas at arm.com  Mon Apr 15 05:39:58 2013
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Mon, 15 Apr 2013 10:39:58 +0100
Subject: [PATCH v2 02/13] ARM: convert arm/arm64 arch timer to use
 CLKSRC_OF init
In-Reply-To: <1364854883-5961-3-git-send-email-robherring2@gmail.com>
References: <1364854883-5961-1-git-send-email-robherring2@gmail.com>
 <1364854883-5961-3-git-send-email-robherring2@gmail.com>
Message-ID: <20130415093958.GA29528@arm.com>

On Mon, Apr 01, 2013 at 11:21:12PM +0100, Rob Herring wrote:
> From: Rob Herring <rob.herring at calxeda.com>
> 
> This converts arm and arm64 to use CLKSRC_OF DT based initialization for
> the arch timer. A new function arch_timer_arch_init is added to allow for
> arch specific setup.
> 
> This has a side effect of enabling sched_clock on omap5 and exynos5. There
> should not be any reason not to use the arch timers for sched_clock.
> 
> Signed-off-by: Rob Herring <rob.herring at calxeda.com>
> Cc: Russell King <linux at arm.linux.org.uk>
> Cc: Kukjin Kim <kgene.kim at samsung.com>
> Cc: Tony Lindgren <tony at atomide.com>
> Cc: Simon Horman <horms at verge.net.au>
> Cc: Magnus Damm <magnus.damm at gmail.com>
> Cc: Catalin Marinas <catalin.marinas at arm.com>
> Cc: Will Deacon <will.deacon at arm.com>
> Cc: John Stultz <john.stultz at linaro.org>
> Cc: Thomas Gleixner <tglx at linutronix.de>
> Cc: linux-samsung-soc at vger.kernel.org
> Cc: linux-omap at vger.kernel.org
> Cc: linux-sh at vger.kernel.org

Unless you pushed the patches already (I've been away for two weeks),
for arm64:

Acked-by: Catalin Marinas <catalin.marinas at arm.com>


From peter.maydell at linaro.org  Mon Apr 15 05:45:14 2013
From: peter.maydell at linaro.org (Peter Maydell)
Date: Mon, 15 Apr 2013 10:45:14 +0100
Subject: [PATCH] ARM: KVM: iterate over all CPUs for CPU compatibility
 check
In-Reply-To: <516BCAD0.9000708@linaro.org>
References: <1365771875-5788-1-git-send-email-andre.przywara@linaro.org>
 <51680AF9.7040109@arm.com>
 <CAEDV+g+E8PLc60vMRhq4O_AL2WjmYDLb6=Wh34ynhevh7uAGJA@mail.gmail.com>
 <d455f2823b9639af8d38d30f2c3234bd@localhost>
 <CAEDV+gJuFG49oQ=BEaCHcTP=nHVyX8ALw6076dR_C1s7TuyqXQ@mail.gmail.com>
 <d47697abd39a0d5d41f5ac110a40e261@localhost>
 <CAEDV+gK9==sXYxRVZ8JVFYPiw3_xgzZBbydEwPunmnocNLKXrQ@mail.gmail.com>
 <CAFEAcA-bPoa8YoPuHPmupzfUW+yR233XquK79eNorzcRpFiK=g@mail.gmail.com>
 <516BCAD0.9000708@linaro.org>
Message-ID: <CAFEAcA88OpCB63kYuUHS6fUn027SvVWNEozL0EbrjoMEeQdykg@mail.gmail.com>

On 15 April 2013 10:39, Andre Przywara <andre.przywara at linaro.org> wrote:
> On 04/15/2013 11:14 AM, Peter Maydell wrote:
>> We *must* exclude KVM vcpu threads from ever running on A7s,
>> because the cp15 handling code as it stands does not virtualize
>> various registers (most notably the ID/feature registers) and
>> so the vcpu will bounce between "looks like an A15" and "looks
>> like a weird hybrid between A7 and A15".
>
> Can't we propagate some least common denominator or safe values for those
> registers instead of propagating the host ones? Or ignore writes to them? Or
> are there any real showstoppers which I overlooked?

Yes, we could do all these things, and will have to; and
we need to analyse all the cp15 registers to determine which
we need to virtualize and in which of these ways. This is
"tackling full big.LITTLE host support" and it is a big job.
We need to do it at some point but for the moment we should
just make sure we don't do weird and wrong things on an
unsupported host config.

-- PMM


From thomas.petazzoni at free-electrons.com  Mon Apr 15 06:00:11 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Mon, 15 Apr 2013 12:00:11 +0200
Subject: [PATCH 0/5 v2] mv643xx_eth: device tree bindings
In-Reply-To: <20130413190037.GY28693@titan.lakedaemon.net>
References: <1365071235-11611-1-git-send-email-florian@openwrt.org>
 <20130411165303.GI28693@titan.lakedaemon.net>
 <20130413172126.6cca0809@skate>
 <20130413190037.GY28693@titan.lakedaemon.net>
Message-ID: <20130415120011.61e4b44c@skate>

Dear Jason Cooper,

On Sat, 13 Apr 2013 15:00:37 -0400, Jason Cooper wrote:

> > So let's continue the cleanup work, conversion to DT, usage of
> > drivers in drivers/, improvement of pinmux to support
> > orion5x/mv78xx0, and do the move per-platform, once they are ready.
> > 
> > What do you think?
> 
> I agree completely.  I was simply restating the longview goal of the
> work we are doing (above and beyond adding armadaXP/370).  I probably
> should have given a time reference for "This will lead to..." :)

Ok. I definitely agree with the long-term goal.

> Also, I have a feeling that not all legacy boards will get converted
> over.  If there is no interest or no way to test, certains boards may
> get deprecated.

I think for many of them, we can do a 'blind' conversion to DT, and ask
the users who have posted patches or even submitted support for those
boards to test the DT. But I don't think we should move things into
mach-mvebu if there are still legacy non-DT Kirkwood platforms
supported in mach-kirkwood. So either we convert them to the DT, or we
remove the support for them if no-one is really interested. But I
believe in most cases, converting them to DT should be quite easy.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From grant.likely at secretlab.ca  Mon Apr 15 06:12:53 2013
From: grant.likely at secretlab.ca (Grant Likely)
Date: Mon, 15 Apr 2013 11:12:53 +0100
Subject: [PATCHv2 1/7] of: Add support for reading a u32 from a
 multi-value property.
In-Reply-To: <1364015633-18580-2-git-send-email-linux@prisktech.co.nz>
References: <1364015633-18580-1-git-send-email-linux@prisktech.co.nz>
 <1364015633-18580-2-git-send-email-linux@prisktech.co.nz>
Message-ID: <20130415101253.C22ED3E0AA8@localhost>

On Sat, 23 Mar 2013 18:13:47 +1300, Tony Prisk <linux at prisktech.co.nz> wrote:
> This patch adds an of_property_read_u32_index() function to allow
> reading a single indexed u32 value from a property containing multiple
> u32 values.
> 
> Signed-off-by: Tony Prisk <linux at prisktech.co.nz>
> ---
> cc: Grant Likely <grant.likely at secretlab.ca>
> cc: Rob Herring <rob.herring at calxeda.com>
> cc: devicetree-discuss at lists.ozlabs.org
> 
> Hi Rob/Grant,
> After a review of my pinctrl driver, it was suggested that one of the helper
> functions be moved into the OF subsystem. Could you review and ack this patch
> if you're happy with it.

Hey Tony,

Instead of implementing this as a sparate function, this should be done
as an extension to the of_proprety_read_u32_array() interface, just like
how of_property_read_u32() is implemented. It will result in less code
that way.  So, rename of_property_read_u32_array() to __of_property_read_u32()
and add a 'index' argument to it. Then of_property_read_u32_index()
can be implemented as:

static inline int of_property_read_u32_index(const struct device_node *np,
					     const char *propname,
					     int index, u32 *out_value)
{
	return __of_property_read_u32(np, propname, index, 1, out_value);
}

And the new of_property_read_u32_array() becomes:

static inline int of_property_read_u32_array(const struct device_node *np,
					     const char *propname,
					     int sz, u32 *out_value)
{
	return __of_property_read_u32(np, propname, 0, sz, out_value);
}

g.

> Regards
> Tony P
> 
>  drivers/of/base.c  |   33 +++++++++++++++++++++++++++++++++
>  include/linux/of.h |    9 +++++++++
>  2 files changed, 42 insertions(+)
> 
> diff --git a/drivers/of/base.c b/drivers/of/base.c
> index 321d3ef..7dc001e 100644
> --- a/drivers/of/base.c
> +++ b/drivers/of/base.c
> @@ -746,6 +746,39 @@ struct device_node *of_find_node_by_phandle(phandle handle)
>  EXPORT_SYMBOL(of_find_node_by_phandle);
>  
>  /**
> + * of_property_read_u32_index - Find and read a u32 from a multi-value property.
> + *
> + * @np:		device node from which the property value is to be read.
> + * @propname:	name of the property to be searched.
> + * @index:	index of the u32 in the list of values
> + * @out_value:	pointer to return value, modified only if no error.
> + *
> + * Search for a property in a device node and read nth 32-bit value from
> + * it. Returns 0 on success, -EINVAL if the property does not exist,
> + * -ENODATA if property does not have a value, and -EOVERFLOW if the
> + * property data isn't large enough.
> + *
> + * The out_value is modified only if a valid u32 value can be decoded.
> + */
> +int of_property_read_u32_index(const struct device_node *np,
> +				       const char *propname,
> +				       u32 index, u32 *out_value)
> +{
> +	struct property *prop = of_find_property(np, propname, NULL);
> +
> +	if (!prop)
> +		return -EINVAL;
> +	if (!prop->value)
> +		return -ENODATA;
> +	if ((index * sizeof(*out_value)) > prop->length)
> +		return -EOVERFLOW;
> +
> +	*out_value = be32_to_cpup(((__be32 *)prop->value) + index);
> +	return 0;
> +}
> +EXPORT_SYMBOL_GPL(of_property_read_u32_index);
> +
> +/**
>   * of_property_read_u8_array - Find and read an array of u8 from a property.
>   *
>   * @np:		device node from which the property value is to be read.
> diff --git a/include/linux/of.h b/include/linux/of.h
> index a0f1292..c0747a4 100644
> --- a/include/linux/of.h
> +++ b/include/linux/of.h
> @@ -235,6 +235,9 @@ extern struct device_node *of_find_node_with_property(
>  extern struct property *of_find_property(const struct device_node *np,
>  					 const char *name,
>  					 int *lenp);
> +extern int of_property_read_u32_index(const struct device_node *np,
> +				       const char *propname,
> +				       u32 index, u32 *out_value);
>  extern int of_property_read_u8_array(const struct device_node *np,
>  			const char *propname, u8 *out_values, size_t sz);
>  extern int of_property_read_u16_array(const struct device_node *np,
> @@ -394,6 +397,12 @@ static inline struct device_node *of_find_compatible_node(
>  	return NULL;
>  }
>  
> +static inline int of_property_read_u32_index(const struct device_node *np,
> +			const char *propname, u32 index, u32 *out_value)
> +{
> +	return -ENOSYS;
> +}
> +
>  static inline int of_property_read_u8_array(const struct device_node *np,
>  			const char *propname, u8 *out_values, size_t sz)
>  {
> -- 
> 1.7.9.5
> 

-- 
Grant Likely, B.Sc, P.Eng.
Secret Lab Technologies, Ltd.


From catalin.marinas at arm.com  Mon Apr 15 06:11:59 2013
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Mon, 15 Apr 2013 11:11:59 +0100
Subject: [PATCH v2] arm64: Fix task tracing
In-Reply-To: <1365510814-21343-1-git-send-email-cov@codeaurora.org>
References: <20130408153132.GQ17476@mudshark.cambridge.arm.com>
 <1365510814-21343-1-git-send-email-cov@codeaurora.org>
Message-ID: <20130415101159.GA25095@localhost.cambridge.arm.com>

On Tue, Apr 09, 2013 at 01:33:34PM +0100, Christopher Covington wrote:
> For accurate accounting pass contextidr_thread_switch the prev
> task pointer, since cpu_switch_to has at that point changed the
> the stack pointer.
> 
> Signed-off-by: Christopher Covington <cov at codeaurora.org>
> ---
>  arch/arm64/kernel/process.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
> index 0337cdb..a49b25a 100644
> --- a/arch/arm64/kernel/process.c
> +++ b/arch/arm64/kernel/process.c
> @@ -315,7 +315,7 @@ struct task_struct *__switch_to(struct task_struct *prev,
>  	/* the actual thread switch */
>  	last = cpu_switch_to(prev, next);
>  
> -	contextidr_thread_switch(next);
> +	contextidr_thread_switch(prev);

The original code was indeed wrong but using prev isn't any better. For
a newly created thread, prev is probably 0 (if it's in a register,
cpu_context has been zeroed by copy_thread()) or some random stack
value.

So we either use current or move the call before cpu_switch_to() (I
would go for the former).

-- 
Catalin


From grant.likely at secretlab.ca  Mon Apr 15 06:20:09 2013
From: grant.likely at secretlab.ca (Grant Likely)
Date: Mon, 15 Apr 2013 11:20:09 +0100
Subject: [PATCH v3 0/6] Generic PHY Framework
In-Reply-To: <1363770725-13717-1-git-send-email-kishon@ti.com>
References: <1363770725-13717-1-git-send-email-kishon@ti.com>
Message-ID: <20130415102009.D358E3E0AA8@localhost>

On Wed, 20 Mar 2013 14:41:59 +0530, Kishon Vijay Abraham I <kishon at ti.com> wrote:
> Added a generic PHY framework that provides a set of APIs for the PHY drivers
> to create/destroy a PHY and APIs for the PHY users to obtain a reference to
> the PHY with or without using phandle. To obtain a reference to the PHY
> without using phandle, the platform specfic intialization code (say from board
> file) should have already called phy_bind with the binding information. The
> binding information consists of phy's device name, phy user device name and an
> index. The index is used when the same phy user binds to mulitple phys.
> 
> This framework will be of use only to devices that uses external PHY (PHY
> functionality is not embedded within the controller).
> 
> The intention of creating this framework is to bring the phy drivers spread
> all over the Linux kernel to drivers/phy to increase code re-use and to
> increase code maintainability.
> 
> Comments to make PHY as bus wasn't done because PHY devices can be part of
> other bus and making a same device attached to multiple bus leads to bad
> design.
> 
> Making omap-usb2 and twl4030 to use this framework is provided as a sample.
> 
> This patch series is developed on 3.9-rc3. Once the patch series gets finalised
> I'll resend omap-usb2 and twl4030 part based on Felipe's tree.
> 

[...]

>  drivers/Kconfig                                    |    2 +
>  drivers/Makefile                                   |    2 +
>  drivers/phy/Kconfig                                |   13 +
>  drivers/phy/Makefile                               |    5 +
>  drivers/phy/phy-core.c                             |  574 ++++++++++++++++++++

This looks to be very specific for USB PHYs. Are you intending it to be
used for other types of PHYs, like Ethernet PHYs? If not, then this
infrastruction should be named something like usb-phy so that it isn't
confused with other layers, and it really should live under drivers/usb.

g.



From kishon at ti.com  Mon Apr 15 06:36:37 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Mon, 15 Apr 2013 16:06:37 +0530
Subject: [PATCH v3 0/6] Generic PHY Framework
In-Reply-To: <20130415102009.D358E3E0AA8@localhost>
References: <1363770725-13717-1-git-send-email-kishon@ti.com>
 <20130415102009.D358E3E0AA8@localhost>
Message-ID: <516BD835.8060007@ti.com>

Hi,

On Monday 15 April 2013 03:50 PM, Grant Likely wrote:
> On Wed, 20 Mar 2013 14:41:59 +0530, Kishon Vijay Abraham I <kishon at ti.com> wrote:
>> Added a generic PHY framework that provides a set of APIs for the PHY drivers
>> to create/destroy a PHY and APIs for the PHY users to obtain a reference to
>> the PHY with or without using phandle. To obtain a reference to the PHY
>> without using phandle, the platform specfic intialization code (say from board
>> file) should have already called phy_bind with the binding information. The
>> binding information consists of phy's device name, phy user device name and an
>> index. The index is used when the same phy user binds to mulitple phys.
>>
>> This framework will be of use only to devices that uses external PHY (PHY
>> functionality is not embedded within the controller).
>>
>> The intention of creating this framework is to bring the phy drivers spread
>> all over the Linux kernel to drivers/phy to increase code re-use and to
>> increase code maintainability.
>>
>> Comments to make PHY as bus wasn't done because PHY devices can be part of
>> other bus and making a same device attached to multiple bus leads to bad
>> design.
>>
>> Making omap-usb2 and twl4030 to use this framework is provided as a sample.
>>
>> This patch series is developed on 3.9-rc3. Once the patch series gets finalised
>> I'll resend omap-usb2 and twl4030 part based on Felipe's tree.
>>
>
> [...]
>
>>   drivers/Kconfig                                    |    2 +
>>   drivers/Makefile                                   |    2 +
>>   drivers/phy/Kconfig                                |   13 +
>>   drivers/phy/Makefile                               |    5 +
>>   drivers/phy/phy-core.c                             |  574 ++++++++++++++++++++
>
> This looks to be very specific for USB PHYs. Are you intending it to be
> used for other types of PHYs, like Ethernet PHYs? If not, then this

Not really. This can be used by USB, SATA and Sylwester was planning to 
use it for video PHY's.

Thanks
Kishon


From linus.walleij at stericsson.com  Mon Apr 15 06:41:32 2013
From: linus.walleij at stericsson.com (Linus Walleij)
Date: Mon, 15 Apr 2013 12:41:32 +0200
Subject: [PATCH] ARM: ux500: DT: Rename root node "soc-u9500" into "soc-ux500"
Message-ID: <1366022492-8701-1-git-send-email-linus.walleij@stericsson.com>

From: Gabriel Fernandez <gabriel.fernandez at stericsson.com>

This root node is used in the whole family of chips, the a9500
is just one particular instance.

Cc: Lee Jones <lee.jones at linaro.org>
Signed-off-by: Gabriel Fernandez <gabriel.fernandez at stericsson.com>
Reviewed-by: Philippe Langlais <philippe.langlais at stericsson.com>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 arch/arm/boot/dts/ccu9540.dts     | 2 +-
 arch/arm/boot/dts/dbx5x0.dtsi     | 2 +-
 arch/arm/boot/dts/href.dtsi       | 2 +-
 arch/arm/boot/dts/hrefprev60.dts  | 2 +-
 arch/arm/boot/dts/hrefv60plus.dts | 2 +-
 arch/arm/boot/dts/snowball.dts    | 2 +-
 arch/arm/boot/dts/stuib.dtsi      | 2 +-
 7 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/arm/boot/dts/ccu9540.dts b/arch/arm/boot/dts/ccu9540.dts
index 0430546..bd69305 100644
--- a/arch/arm/boot/dts/ccu9540.dts
+++ b/arch/arm/boot/dts/ccu9540.dts
@@ -20,7 +20,7 @@
 		reg = <0x00000000 0x20000000>;
 	};
 
-	soc-u9500 {
+	soc-ux500 {
 		uart at 80120000 {
 			status = "okay";
 		};
diff --git a/arch/arm/boot/dts/dbx5x0.dtsi b/arch/arm/boot/dts/dbx5x0.dtsi
index d765c38..76eba0a 100644
--- a/arch/arm/boot/dts/dbx5x0.dtsi
+++ b/arch/arm/boot/dts/dbx5x0.dtsi
@@ -12,7 +12,7 @@
 /include/ "skeleton.dtsi"
 
 / {
-	soc-u9500 {
+	soc-ux500 {
 		#address-cells = <1>;
 		#size-cells = <1>;
 		compatible = "stericsson,db8500";
diff --git a/arch/arm/boot/dts/href.dtsi b/arch/arm/boot/dts/href.dtsi
index f2c0f66..527755f 100644
--- a/arch/arm/boot/dts/href.dtsi
+++ b/arch/arm/boot/dts/href.dtsi
@@ -27,7 +27,7 @@
 		};
 	};
 
-	soc-u9500 {
+	soc-ux500 {
 		uart at 80120000 {
 			status = "okay";
 		};
diff --git a/arch/arm/boot/dts/hrefprev60.dts b/arch/arm/boot/dts/hrefprev60.dts
index c2d2748..3d4a64e 100644
--- a/arch/arm/boot/dts/hrefprev60.dts
+++ b/arch/arm/boot/dts/hrefprev60.dts
@@ -24,7 +24,7 @@
 		};
 	};
 
-	soc-u9500 {
+	soc-ux500 {
 		prcmu at 80157000 {
 			ab8500 at 5 {
 				ab8500-gpio {
diff --git a/arch/arm/boot/dts/hrefv60plus.dts b/arch/arm/boot/dts/hrefv60plus.dts
index 55f4191..916bb91 100644
--- a/arch/arm/boot/dts/hrefv60plus.dts
+++ b/arch/arm/boot/dts/hrefv60plus.dts
@@ -24,7 +24,7 @@
 		};
 	};
 
-	soc-u9500 {
+	soc-ux500 {
 		i2c at 80110000 {
 			bu21013_tp at 0x5c {
 				reset-gpio = <&gpio4 15 0x4>;
diff --git a/arch/arm/boot/dts/snowball.dts b/arch/arm/boot/dts/snowball.dts
index 5fcd7a8..4bb8f11 100644
--- a/arch/arm/boot/dts/snowball.dts
+++ b/arch/arm/boot/dts/snowball.dts
@@ -82,7 +82,7 @@
 		};
 	};
 
-	soc-u9500 {
+	soc-ux500 {
 
 		sound {
 			compatible = "stericsson,snd-soc-mop500";
diff --git a/arch/arm/boot/dts/stuib.dtsi b/arch/arm/boot/dts/stuib.dtsi
index 615392a..1be4ec9 100644
--- a/arch/arm/boot/dts/stuib.dtsi
+++ b/arch/arm/boot/dts/stuib.dtsi
@@ -10,7 +10,7 @@
  */
 
 / {
-	soc-u9500 {
+	soc-ux500 {
 		i2c at 80004000 {
 			stmpe1601: stmpe1601 at 40 {
 				compatible = "st,stmpe1601";
-- 
1.7.11.3



From linus.walleij at linaro.org  Mon Apr 15 06:43:40 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Mon, 15 Apr 2013 12:43:40 +0200
Subject: [PATCH] ARM: ux500: Fix intcore regulator name
In-Reply-To: <1365499016-8348-1-git-send-email-fabio.baltieri@linaro.org>
References: <1365499016-8348-1-git-send-email-fabio.baltieri@linaro.org>
Message-ID: <CACRpkdb2NMdArJcp2niS4=-sbnZtj75itu5Rm5WA0BHMpO7amg@mail.gmail.com>

On Tue, Apr 9, 2013 at 11:16 AM, Fabio Baltieri
<fabio.baltieri at linaro.org> wrote:

> Ux500 regulator name for V-INTCORE is misspelled as vinitcore instead of
> vintcore in some .dts file, causing the AB8500 regulator driver to not
> bind properly.  Fix this by replacing all occurrences with the right
> name.
>
> Acked-by: Lee Jones <lee.jones at linaro.org>
> Signed-off-by: Fabio Baltieri <fabio.baltieri at linaro.org>

I've accumulated the patch in my tree but will not be sending to
ARM SoC for v3.10 as of now. Currently I have a huge conflict
between some 4-5 DT patches and ARM SoC and I will just wait
for -rc1 to happen before trying to clean out the mess.

Yours,
Linus Walleij


From will.deacon at arm.com  Mon Apr 15 06:45:42 2013
From: will.deacon at arm.com (Will Deacon)
Date: Mon, 15 Apr 2013 11:45:42 +0100
Subject: [PATCH v2] arm64: Fix task tracing
In-Reply-To: <20130415101159.GA25095@localhost.cambridge.arm.com>
References: <20130408153132.GQ17476@mudshark.cambridge.arm.com>
 <1365510814-21343-1-git-send-email-cov@codeaurora.org>
 <20130415101159.GA25095@localhost.cambridge.arm.com>
Message-ID: <20130415104542.GE9827@mudshark.cambridge.arm.com>

On Mon, Apr 15, 2013 at 11:11:59AM +0100, Catalin Marinas wrote:
> On Tue, Apr 09, 2013 at 01:33:34PM +0100, Christopher Covington wrote:
> > For accurate accounting pass contextidr_thread_switch the prev
> > task pointer, since cpu_switch_to has at that point changed the
> > the stack pointer.
> > 
> > Signed-off-by: Christopher Covington <cov at codeaurora.org>
> > ---
> >  arch/arm64/kernel/process.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
> > index 0337cdb..a49b25a 100644
> > --- a/arch/arm64/kernel/process.c
> > +++ b/arch/arm64/kernel/process.c
> > @@ -315,7 +315,7 @@ struct task_struct *__switch_to(struct task_struct *prev,
> >  	/* the actual thread switch */
> >  	last = cpu_switch_to(prev, next);
> >  
> > -	contextidr_thread_switch(next);
> > +	contextidr_thread_switch(prev);
> 
> The original code was indeed wrong but using prev isn't any better. For
> a newly created thread, prev is probably 0 (if it's in a register,
> cpu_context has been zeroed by copy_thread()) or some random stack
> value.

Really? If prev is NULL in context_switch(...), the scheduler will implode,
and I can't see where else switch_to is called from.

Which code path are you thinking of?

Will


From linus.walleij at linaro.org  Mon Apr 15 06:47:09 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Mon, 15 Apr 2013 12:47:09 +0200
Subject: [PATCH 1/5] ARM: ux500: Move DMA40 platform data includes file
 out to include/
In-Reply-To: <1365434591-21569-1-git-send-email-lee.jones@linaro.org>
References: <1365434591-21569-1-git-send-email-lee.jones@linaro.org>
Message-ID: <CACRpkdauTuDhEq7H9DPLTGwQsZvpOrcJ62Kk7j6BkLMn8CxqVQ@mail.gmail.com>

On Mon, Apr 8, 2013 at 5:23 PM, Lee Jones <lee.jones at linaro.org> wrote:

> The pin names for DB8500 based platforms need to be moved out of

"pin names" ???

> ux500 platform data and into the new proper location in include/
> linux/platform_data/. This way we an reference them from other
> external locations, such as the main DMA50 driver(s).
>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>

(...)
>  rename arch/arm/mach-ux500/ste-dma40-db8500.h => include/linux/platform_data/dma-ste-dma40-db8500.h (98%)

Those are the DB8500 DMA channel definitions...

I will not interfere with the fruitful discussion with Arnd on this
subject though, I suspect he's right.

Yours,
Linus Walleij


From lee.jones at linaro.org  Mon Apr 15 06:58:00 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Mon, 15 Apr 2013 11:58:00 +0100
Subject: [PATCH 1/5] ARM: ux500: Move DMA40 platform data includes file
 out to include/
In-Reply-To: <CACRpkdauTuDhEq7H9DPLTGwQsZvpOrcJ62Kk7j6BkLMn8CxqVQ@mail.gmail.com>
References: <1365434591-21569-1-git-send-email-lee.jones@linaro.org>
 <CACRpkdauTuDhEq7H9DPLTGwQsZvpOrcJ62Kk7j6BkLMn8CxqVQ@mail.gmail.com>
Message-ID: <20130415105800.GC6512@gmail.com>

On Mon, 15 Apr 2013, Linus Walleij wrote:

> On Mon, Apr 8, 2013 at 5:23 PM, Lee Jones <lee.jones at linaro.org> wrote:
> 
> > The pin names for DB8500 based platforms need to be moved out of
> 
> "pin names" ???
> 
> > ux500 platform data and into the new proper location in include/
> > linux/platform_data/. This way we an reference them from other
> > external locations, such as the main DMA50 driver(s).
> >
> > Signed-off-by: Lee Jones <lee.jones at linaro.org>
> 
> (...)
> >  rename arch/arm/mach-ux500/ste-dma40-db8500.h => include/linux/platform_data/dma-ste-dma40-db8500.h (98%)
> 
> Those are the DB8500 DMA channel definitions...
> 
> I will not interfere with the fruitful discussion with Arnd on this
> subject though, I suspect he's right.

It's okay, I've since removed this patch.

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From catalin.marinas at arm.com  Mon Apr 15 06:58:40 2013
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Mon, 15 Apr 2013 11:58:40 +0100
Subject: [PATCH v2] arm64: Fix task tracing
In-Reply-To: <20130415104542.GE9827@mudshark.cambridge.arm.com>
References: <20130408153132.GQ17476@mudshark.cambridge.arm.com>
 <1365510814-21343-1-git-send-email-cov@codeaurora.org>
 <20130415101159.GA25095@localhost.cambridge.arm.com>
 <20130415104542.GE9827@mudshark.cambridge.arm.com>
Message-ID: <20130415105840.GB29528@arm.com>

On Mon, Apr 15, 2013 at 11:45:42AM +0100, Will Deacon wrote:
> On Mon, Apr 15, 2013 at 11:11:59AM +0100, Catalin Marinas wrote:
> > On Tue, Apr 09, 2013 at 01:33:34PM +0100, Christopher Covington wrote:
> > > For accurate accounting pass contextidr_thread_switch the prev
> > > task pointer, since cpu_switch_to has at that point changed the
> > > the stack pointer.
> > > 
> > > Signed-off-by: Christopher Covington <cov at codeaurora.org>
> > > ---
> > >  arch/arm64/kernel/process.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
> > > index 0337cdb..a49b25a 100644
> > > --- a/arch/arm64/kernel/process.c
> > > +++ b/arch/arm64/kernel/process.c
> > > @@ -315,7 +315,7 @@ struct task_struct *__switch_to(struct task_struct *prev,
> > >  	/* the actual thread switch */
> > >  	last = cpu_switch_to(prev, next);
> > >  
> > > -	contextidr_thread_switch(next);
> > > +	contextidr_thread_switch(prev);
> > 
> > The original code was indeed wrong but using prev isn't any better. For
> > a newly created thread, prev is probably 0 (if it's in a register,
> > cpu_context has been zeroed by copy_thread()) or some random stack
> > value.
> 
> Really? If prev is NULL in context_switch(...), the scheduler will implode,
> and I can't see where else switch_to is called from.
> 
> Which code path are you thinking of?

copy_thread() zeros cpu_context which is used by cpu_switch_to() to load
the next saved registers. The switch_to() function sets prev to last as
returned by __switch_to(), so this is valid but in __switch_to() we
don't have a valid prev (nor next) after cpu_switch_to() for newly
created threads.

-- 
Catalin


From lee.jones at linaro.org  Mon Apr 15 07:00:07 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Mon, 15 Apr 2013 12:00:07 +0100
Subject: [PATCH] ARM: ux500: DT: Rename root node "soc-u9500" into
 "soc-ux500"
In-Reply-To: <1366022492-8701-1-git-send-email-linus.walleij@stericsson.com>
References: <1366022492-8701-1-git-send-email-linus.walleij@stericsson.com>
Message-ID: <20130415110007.GD6512@gmail.com>

On Mon, 15 Apr 2013, Linus Walleij wrote:

> From: Gabriel Fernandez <gabriel.fernandez at stericsson.com>
> 
> This root node is used in the whole family of chips, the a9500
> is just one particular instance.
> 
> Cc: Lee Jones <lee.jones at linaro.org>
> Signed-off-by: Gabriel Fernandez <gabriel.fernandez at stericsson.com>
> Reviewed-by: Philippe Langlais <philippe.langlais at stericsson.com>
> Signed-off-by: Linus Walleij <linus.walleij at linaro.org>


Looks good to me:

Acked-by: Lee Jones <lee.jones at linaro.org>

>  arch/arm/boot/dts/ccu9540.dts     | 2 +-
>  arch/arm/boot/dts/dbx5x0.dtsi     | 2 +-
>  arch/arm/boot/dts/href.dtsi       | 2 +-
>  arch/arm/boot/dts/hrefprev60.dts  | 2 +-
>  arch/arm/boot/dts/hrefv60plus.dts | 2 +-
>  arch/arm/boot/dts/snowball.dts    | 2 +-
>  arch/arm/boot/dts/stuib.dtsi      | 2 +-
>  7 files changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/ccu9540.dts b/arch/arm/boot/dts/ccu9540.dts
> index 0430546..bd69305 100644
> --- a/arch/arm/boot/dts/ccu9540.dts
> +++ b/arch/arm/boot/dts/ccu9540.dts
> @@ -20,7 +20,7 @@
>  		reg = <0x00000000 0x20000000>;
>  	};
>  
> -	soc-u9500 {
> +	soc-ux500 {
>  		uart at 80120000 {
>  			status = "okay";
>  		};
> diff --git a/arch/arm/boot/dts/dbx5x0.dtsi b/arch/arm/boot/dts/dbx5x0.dtsi
> index d765c38..76eba0a 100644
> --- a/arch/arm/boot/dts/dbx5x0.dtsi
> +++ b/arch/arm/boot/dts/dbx5x0.dtsi
> @@ -12,7 +12,7 @@
>  /include/ "skeleton.dtsi"
>  
>  / {
> -	soc-u9500 {
> +	soc-ux500 {
>  		#address-cells = <1>;
>  		#size-cells = <1>;
>  		compatible = "stericsson,db8500";
> diff --git a/arch/arm/boot/dts/href.dtsi b/arch/arm/boot/dts/href.dtsi
> index f2c0f66..527755f 100644
> --- a/arch/arm/boot/dts/href.dtsi
> +++ b/arch/arm/boot/dts/href.dtsi
> @@ -27,7 +27,7 @@
>  		};
>  	};
>  
> -	soc-u9500 {
> +	soc-ux500 {
>  		uart at 80120000 {
>  			status = "okay";
>  		};
> diff --git a/arch/arm/boot/dts/hrefprev60.dts b/arch/arm/boot/dts/hrefprev60.dts
> index c2d2748..3d4a64e 100644
> --- a/arch/arm/boot/dts/hrefprev60.dts
> +++ b/arch/arm/boot/dts/hrefprev60.dts
> @@ -24,7 +24,7 @@
>  		};
>  	};
>  
> -	soc-u9500 {
> +	soc-ux500 {
>  		prcmu at 80157000 {
>  			ab8500 at 5 {
>  				ab8500-gpio {
> diff --git a/arch/arm/boot/dts/hrefv60plus.dts b/arch/arm/boot/dts/hrefv60plus.dts
> index 55f4191..916bb91 100644
> --- a/arch/arm/boot/dts/hrefv60plus.dts
> +++ b/arch/arm/boot/dts/hrefv60plus.dts
> @@ -24,7 +24,7 @@
>  		};
>  	};
>  
> -	soc-u9500 {
> +	soc-ux500 {
>  		i2c at 80110000 {
>  			bu21013_tp at 0x5c {
>  				reset-gpio = <&gpio4 15 0x4>;
> diff --git a/arch/arm/boot/dts/snowball.dts b/arch/arm/boot/dts/snowball.dts
> index 5fcd7a8..4bb8f11 100644
> --- a/arch/arm/boot/dts/snowball.dts
> +++ b/arch/arm/boot/dts/snowball.dts
> @@ -82,7 +82,7 @@
>  		};
>  	};
>  
> -	soc-u9500 {
> +	soc-ux500 {
>  
>  		sound {
>  			compatible = "stericsson,snd-soc-mop500";
> diff --git a/arch/arm/boot/dts/stuib.dtsi b/arch/arm/boot/dts/stuib.dtsi
> index 615392a..1be4ec9 100644
> --- a/arch/arm/boot/dts/stuib.dtsi
> +++ b/arch/arm/boot/dts/stuib.dtsi
> @@ -10,7 +10,7 @@
>   */
>  
>  / {
> -	soc-u9500 {
> +	soc-ux500 {
>  		i2c at 80004000 {
>  			stmpe1601: stmpe1601 at 40 {
>  				compatible = "st,stmpe1601";

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From broonie at kernel.org  Mon Apr 15 07:04:23 2013
From: broonie at kernel.org (Mark Brown)
Date: Mon, 15 Apr 2013 12:04:23 +0100
Subject: [alsa-devel] [PATCH 20/30] ASoC: samsung: convert to dmaengine API
In-Reply-To: <5168601F.2070409@metafoo.de>
References: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
 <1365638712-1028578-21-git-send-email-arnd@arndb.de>
 <20130411142706.GB24971@opensource.wolfsonmicro.com>
 <201304111647.17796.arnd@arndb.de> <5168601F.2070409@metafoo.de>
Message-ID: <20130415110422.GA15837@opensource.wolfsonmicro.com>

On Fri, Apr 12, 2013 at 09:27:27PM +0200, Lars-Peter Clausen wrote:

> I actually had a look at how the Samsung PCM driver a couple of days back,
> but I didn't fully grasp how things work with the secondary TX channel for
> the i2s driver and to make it work with the generic dmaengine PCM driver.
> The code handling this in the i2s driver seems to be rather messy with lots
> of ifs and elses. Also things would have would be a lot easier if the dt
> bindings had used two subnodes each with their own 'dmas' property.

Yeah, it's quite messy at the minute as it predates any subsystem
support for things like multiple DMA channels going into a single DAI on
an AP so it was having to do things it really shouldn't have done.  What
ought to happen is that the driver gets refactored to use soc-pcm or
change to represent the mixer block as a CODEC, I think if that happens
then things ought to get easier.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130415/53099be0/attachment.sig>

From lee.jones at linaro.org  Mon Apr 15 07:06:01 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Mon, 15 Apr 2013 12:06:01 +0100
Subject: [PATCH 3/8] dmaengine: ste_dma40: Actually write the runtime
 configuration to registers
In-Reply-To: <CAH+eYFB_fYmCjvh5PXKRhd-FnaWfeu+LtH+q3VywhCk-PYhHVQ@mail.gmail.com>
References: <1365532783-27425-1-git-send-email-lee.jones@linaro.org>
 <1365532783-27425-3-git-send-email-lee.jones@linaro.org>
 <CAH+eYFB_fYmCjvh5PXKRhd-FnaWfeu+LtH+q3VywhCk-PYhHVQ@mail.gmail.com>
Message-ID: <20130415110601.GE6512@gmail.com>

On Fri, 12 Apr 2013, Rabin Vincent wrote:

> 2013/4/9 Lee Jones <lee.jones at linaro.org>:
> > Someone has spent a fair amount of effort writing a runtime configuration
> > changing algorithm for DMA clients. However, the config appears to never
> > actually make it to hardware. In order for the configuration to take hold
> > we need to issue a d40_config_write(), as this is the routine which writes
> > it into the hardware's registers.
> 
> No, it's not.  This function is only for initial configuration which
> should only be written when the channel is allocated.  In fact, by
> calling it here in runtime_config, you are introducing a serious bug:
> other logical channels on the same physical channel will stop because of
> the SSLNK/SDLNK of the physical channel being zeroed.
> 
> The runtime config already makes it the hardware in the existing code,
> via d40_*_cfg().

Sorry Rabin, but the only place I can see the config being written is
in d40_config_write().

Can you paste the line of code in d40_*_cfg() which actually writes
the config to hardware please? I don't see it.

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From zhangwm at marvell.com  Mon Apr 15 07:10:03 2013
From: zhangwm at marvell.com (Neil Zhang)
Date: Mon, 15 Apr 2013 04:10:03 -0700
Subject: [PATCH 1/4] ARM: mmp: add wakeup function for ICU
In-Reply-To: <CAN1soZwFJybMUZgxZJyXcDdKXbpQxaVntyZd8oGnQivLF=ZNNA@mail.gmail.com>
References: <1365651463-11502-1-git-send-email-zhangwm@marvell.com>
 <1365651463-11502-2-git-send-email-zhangwm@marvell.com>
 <CAN1soZwFJybMUZgxZJyXcDdKXbpQxaVntyZd8oGnQivLF=ZNNA@mail.gmail.com>
Message-ID: <175CCF5F49938B4D99B2E3EF7F558EBE2D0F68CFD8@SC-VEXCH4.marvell.com>





> -----Original Message-----
> From: Haojian Zhuang [mailto:haojian.zhuang at gmail.com]
> Sent: 2013?4?13? 20:50
> To: Neil Zhang
> Cc: Grant Likely; linux-arm-kernel at lists.infradead.org;
> linux-kernel at vger.kernel.org; Chao Xie
> Subject: Re: [PATCH 1/4] ARM: mmp: add wakeup function for ICU
> 
> On Thu, Apr 11, 2013 at 11:37 AM, Neil Zhang <zhangwm at marvell.com>
> wrote:
> > From: Chao Xie <chao.xie at marvell.com>
> >
> > PXA988 will use GIC as its interrupt controller, and ICU is used as
> > wakeup logic. When AP subsystem is powered off, GIC will lose its
> > context, the PMU will need ICU to wakeup the AP subsystem.
> > When ICU works as wakeup logic, there is no need to know intc-nr-irqs,
> > change the corresponding code.
> >
> > Signed-off-by: Chao Xie <chao.xie at marvell.com>
> > Signed-off-by: Neil Zhang <zhangwm at marvell.com>
> > ---
> >  .../devicetree/bindings/arm/mrvl/intc.txt          |    9 ++++
> >  arch/arm/mach-mmp/irq.c                            |   51
> ++++++++++++++++----
> >  2 files changed, 50 insertions(+), 10 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/arm/mrvl/intc.txt
> > b/Documentation/devicetree/bindings/arm/mrvl/intc.txt
> > index 8b53273..58c0e74 100644
> > --- a/Documentation/devicetree/bindings/arm/mrvl/intc.txt
> > +++ b/Documentation/devicetree/bindings/arm/mrvl/intc.txt
> > @@ -15,6 +15,8 @@ Required properties:
> >  - interrupt-controller : Identifies the node as an interrupt controller.
> >  - #interrupt-cells : Specifies the number of cells needed to encode an
> >    interrupt source.
> > +- mrvl,intc-wakeup : Specifies the address and value for global mask
> > +in the
> > +  interrupt controller.
> >  - mrvl,intc-nr-irqs : Specifies the number of interrupts in the interrupt
> >    controller.
> >  - mrvl,clr-mfp-irq : Specifies the interrupt that needs to clear MFP
> > edge @@ -39,6 +41,13 @@ Example:
> >                 mrvl,intc-nr-irqs = <2>;
> >         };
> >
> > +       intc: interrupt-controller at d4282000 {
> > +               compatible = "mrvl,mmp-intc";
> > +               reg = <0xd4282000 0x1000>;
> > +               mrvl,intc-wakeup = <0x114 0x3
> > +                                   0x144 0x3>;
> > +       };
> > +
> >  * Marvell Orion Interrupt controller
> >
> >  Required properties
> > diff --git a/arch/arm/mach-mmp/irq.c b/arch/arm/mach-mmp/irq.c index
> > 3c71246..b8df948 100644
> > --- a/arch/arm/mach-mmp/irq.c
> > +++ b/arch/arm/mach-mmp/irq.c
> > @@ -16,6 +16,7 @@
> >  #include <linux/init.h>
> >  #include <linux/irq.h>
> >  #include <linux/irqdomain.h>
> > +#include <linux/irqchip/arm-gic.h>
> >  #include <linux/io.h>
> >  #include <linux/ioport.h>
> >  #include <linux/of_address.h>
> > @@ -57,6 +58,7 @@ struct mmp_intc_conf {  void __iomem
> *mmp_icu_base;
> > static struct icu_chip_data icu_data[MAX_ICU_NR];  static int
> > max_icu_nr;
> > +static bool mmp_icu_wakeup;
> >
> >  extern void mmp2_clear_pmic_int(void);
> >
> > @@ -91,8 +93,11 @@ static void icu_mask_irq(struct irq_data *d)
> >         int hwirq;
> >         u32 r;
> >
> > -       hwirq = d->irq - data->virq_base;
> > -       if (data == &icu_data[0]) {
> > +       if (mmp_icu_wakeup)
> > +               hwirq = d->hwirq;
> > +       else
> > +               hwirq = d->irq - data->virq_base;
> > +       if (data == &icu_data[0] || mmp_icu_wakeup) {
> >                 r = readl_relaxed(mmp_icu_base + (hwirq << 2));
> >                 r &= ~data->conf_mask;
> >                 r |= data->conf_disable; @@ -110,8 +115,11 @@
> static
> > void icu_unmask_irq(struct irq_data *d)
> >         int hwirq;
> >         u32 r;
> >
> > -       hwirq = d->irq - data->virq_base;
> > -       if (data == &icu_data[0]) {
> > +       if (mmp_icu_wakeup)
> > +               hwirq = d->hwirq;
> > +       else
> > +               hwirq = d->irq - data->virq_base;
> > +       if (data == &icu_data[0] || mmp_icu_wakeup) {
> >                 r = readl_relaxed(mmp_icu_base + (hwirq << 2));
> >                 r &= ~data->conf_mask;
> >                 r |= data->conf_enable; @@ -415,6 +423,8 @@ void
> > __init mmp_dt_irq_init(void)
> >         const struct of_device_id *of_id;
> >         struct mmp_intc_conf *conf;
> >         int nr_irqs, irq_base, ret, irq;
> > +       const __be32 *wakeup_reg;
> > +       int size, i;
> >
> >         node = of_find_matching_node(NULL, intc_ids);
> >         if (!node) {
> > @@ -424,18 +434,39 @@ void __init mmp_dt_irq_init(void)
> >         of_id = of_match_node(intc_ids, node);
> >         conf = of_id->data;
> >
> > -       ret = of_property_read_u32(node, "mrvl,intc-nr-irqs", &nr_irqs);
> > -       if (ret) {
> > -               pr_err("Not found mrvl,intc-nr-irqs property\n");
> > -               return;
> > -       }
> > -
> >         mmp_icu_base = of_iomap(node, 0);
> >         if (!mmp_icu_base) {
> >                 pr_err("Failed to get interrupt controller register\n");
> >                 return;
> >         }
> >
> > +       /* ICU is only used as wake up logic. */
> > +       wakeup_reg = of_get_property(node, "mrvl,intc-wakeup", &size);
> > +       if (wakeup_reg) {
> > +               mmp_icu_wakeup = 1;
> > +               size /= sizeof(*wakeup_reg);
> > +               i = 0;
> > +               /* disable the global irq/fiq in icu for all cores. */
> > +               while (i < size) {
> > +                       unsigned offset, val;
> > +
> > +                       offset = be32_to_cpup(wakeup_reg + i++);
> > +                       val = be32_to_cpup(wakeup_reg + i++);
> > +                       writel_relaxed(val, mmp_icu_base + offset);
> > +               }
> > +
> > +               gic_arch_extn.irq_mask = icu_mask_irq;
> > +               gic_arch_extn.irq_unmask = icu_unmask_irq;
> > +
> > +               return;
> > +       }
> 
> Since it's totally different from original ICU irq initialization, I suggest to
> create a new entry to handle this kind of wakeup event. And we could create
> a new mask/unmask function.

Ok, I'll update it.

> 
> > +
> > +       ret = of_property_read_u32(node, "mrvl,intc-nr-irqs", &nr_irqs);
> > +       if (ret) {
> > +               pr_err("Not found mrvl,intc-nr-irqs property\n");
> > +               return;
> > +       }
> > +
> >         irq_base = irq_alloc_descs(-1, 0, nr_irqs - NR_IRQS_LEGACY, 0);
> >         if (irq_base < 0) {
> >                 pr_err("Failed to allocate IRQ numbers\n");
> > --
> > 1.7.4.1
> >

Best Regards,
Neil Zhang

From zhangwm at marvell.com  Mon Apr 15 07:10:46 2013
From: zhangwm at marvell.com (Neil Zhang)
Date: Mon, 15 Apr 2013 04:10:46 -0700
Subject: [PATCH 3/4] ARM: mmp: bring up pxa988 with device tree support
In-Reply-To: <CAN1soZxhXW=pNGihz6g4arK0zWi7_rzXQyJfuuat0d+Yw+P0Gg@mail.gmail.com>
References: <1365651529-11545-1-git-send-email-zhangwm@marvell.com>
 <CAN1soZxhXW=pNGihz6g4arK0zWi7_rzXQyJfuuat0d+Yw+P0Gg@mail.gmail.com>
Message-ID: <175CCF5F49938B4D99B2E3EF7F558EBE2D0F68CFD9@SC-VEXCH4.marvell.com>



> -----Original Message-----
> From: Haojian Zhuang [mailto:haojian.zhuang at gmail.com]
> Sent: 2013?4?13? 21:04
> To: Neil Zhang
> Cc: Grant Likely; linux-arm-kernel at lists.infradead.org;
> linux-kernel at vger.kernel.org; Chao Xie
> Subject: Re: [PATCH 3/4] ARM: mmp: bring up pxa988 with device tree
> support
> 
> On Thu, Apr 11, 2013 at 11:38 AM, Neil Zhang <zhangwm at marvell.com>
> wrote:
> > bring up pxa988 with device tree support.
> >
> > Signed-off-by: Neil Zhang <zhangwm at marvell.com>
> > Signed-off-by: Chao Xie <chao.xie at marvell.com>
> > ---
> >  arch/arm/boot/dts/pxa988-dkb.dts          |   36 ++++++
> >  arch/arm/boot/dts/pxa988.dtsi             |  196
> +++++++++++++++++++++++++++++
> >  arch/arm/mach-mmp/Kconfig                 |   25 ++++
> >  arch/arm/mach-mmp/Makefile                |    1 +
> >  arch/arm/mach-mmp/common.c                |   11 ++-
> >  arch/arm/mach-mmp/include/mach/addr-map.h |    6 +
> >  arch/arm/mach-mmp/mmpx-dt.c               |   79
> ++++++++++++
> >  drivers/clk/mmp/Makefile                  |    1 +
> >  8 files changed, 354 insertions(+), 1 deletions(-)  create mode
> > 100644 arch/arm/boot/dts/pxa988-dkb.dts  create mode 100644
> > arch/arm/boot/dts/pxa988.dtsi  create mode 100644
> > arch/arm/mach-mmp/mmpx-dt.c
> >
> > diff --git a/arch/arm/boot/dts/pxa988-dkb.dts
> > b/arch/arm/boot/dts/pxa988-dkb.dts
> > new file mode 100644
> > index 0000000..2cee3ed
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/pxa988-dkb.dts
> > @@ -0,0 +1,36 @@
> > +/*
> > + *  Copyright (C) 2012 Marvell Technology Group Ltd.
> > + *  Author: Haojian Zhuang <haojian.zhuang at marvell.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
> > + *  publishhed by the Free Software Foundation.
> > + */
> > +
> > +/dts-v1/;
> > +/include/ "pxa988.dtsi"
> > +
> > +
> > +                       gpio at d4019000 {
> > +                               compatible = "mrvl,mmp-gpio";
> Since gpio-pxa driver is updated & merged just now, you need to update this
> as "marvell,mmp-gpio".
> 
Ok, I'll update.

> > +
> > +/* PXA988 */
> > +static const struct of_dev_auxdata pxa988_auxdata_lookup[] __initconst
> = {
> > +       OF_DEV_AUXDATA("mrvl,mmp-uart", 0xd4017000,
> "pxa2xx-uart.0", NULL),
> > +       OF_DEV_AUXDATA("mrvl,mmp-uart", 0xd4018000,
> "pxa2xx-uart.1", NULL),
> > +       OF_DEV_AUXDATA("mrvl,mmp-uart", 0xd4036000,
> "pxa2xx-uart.2", NULL),
> > +       OF_DEV_AUXDATA("mrvl,mmp-twsi", 0xd4011000,
> "pxa2xx-i2c.0", NULL),
> > +       OF_DEV_AUXDATA("mrvl,mmp-twsi", 0xd4037000,
> "pxa2xx-i2c.1", NULL),
> > +       OF_DEV_AUXDATA("mrvl,mmp-gpio", 0xd4019000, "pxa-gpio",
> NULL),
> "marvell,mmp-gpio"



Best Regards,
Neil Zhang

From pawel.moll at arm.com  Mon Apr 15 07:11:07 2013
From: pawel.moll at arm.com (Pawel Moll)
Date: Mon, 15 Apr 2013 12:11:07 +0100
Subject: [PATCH] clk: vexpress: Add separate SP810 driver
In-Reply-To: <1365589500.362.15.camel@hornet>
References: <1363358409-5693-1-git-send-email-pawel.moll@arm.com>
 <1365589500.362.15.camel@hornet>
Message-ID: <1366024267.3061.26.camel@hornet>

On Wed, 2013-04-10 at 11:25 +0100, Pawel Moll wrote:
> On Fri, 2013-03-15 at 14:40 +0000, Pawel Moll wrote:
> > Hi Mike,
> > 
> > I'd like to get this merged in 3.10. After this arm64
> > will be able to avoid any platform clocking code. And
> > in case of v7 this will happen once Rob's SP804 work
> > is done.
> > 
> > Thanks!
> > 
> > Pawel
> 
> Ping?

Ping again?

Pawe?




From zhangwm at marvell.com  Mon Apr 15 07:09:21 2013
From: zhangwm at marvell.com (Neil Zhang)
Date: Mon, 15 Apr 2013 04:09:21 -0700
Subject: [PATCH 2/4] ARM: mmp: move function declaration to head file
In-Reply-To: <CAN1soZyibQLOkeeZAi-8kWVJtgS9z9g0kyVSGunP-QO4dEkuzg@mail.gmail.com>
References: <1365651463-11502-1-git-send-email-zhangwm@marvell.com>
 <1365651463-11502-3-git-send-email-zhangwm@marvell.com>
 <CAN1soZyibQLOkeeZAi-8kWVJtgS9z9g0kyVSGunP-QO4dEkuzg@mail.gmail.com>
Message-ID: <175CCF5F49938B4D99B2E3EF7F558EBE2D0F68CFD7@SC-VEXCH4.marvell.com>





> -----Original Message-----
> From: Haojian Zhuang [mailto:haojian.zhuang at gmail.com]
> Sent: 2013?4?13? 20:59
> To: Neil Zhang
> Cc: Grant Likely; linux-arm-kernel at lists.infradead.org;
> linux-kernel at vger.kernel.org; Chao Xie
> Subject: Re: [PATCH 2/4] ARM: mmp: move function declaration to head file
> 
> On Thu, Apr 11, 2013 at 11:37 AM, Neil Zhang <zhangwm at marvell.com>
> wrote:
> > Move some of the function declaration to head file.
> >
> > Signed-off-by: Neil Zhang <zhangwm at marvell.com>
> > Signed-off-by: Chao Xie <chao.xie at marvell.com>
> > ---
> >  arch/arm/mach-mmp/common.h  |    3 +++
> >  arch/arm/mach-mmp/mmp-dt.c  |    3 ---
> >  arch/arm/mach-mmp/mmp2-dt.c |    3 ---
> >  3 files changed, 3 insertions(+), 6 deletions(-)
> >
> > diff --git a/arch/arm/mach-mmp/common.h
> b/arch/arm/mach-mmp/common.h
> > index 0bdc50b..8c9b510 100644
> > --- a/arch/arm/mach-mmp/common.h
> > +++ b/arch/arm/mach-mmp/common.h
> > @@ -8,3 +8,6 @@ extern void mmp_restart(char, const char *);  extern
> > void __init pxa168_clk_init(void);  extern void __init
> > pxa910_clk_init(void);  extern void __init mmp2_clk_init(void);
> > +
> > +extern void __init mmp_dt_irq_init(void); extern void __init
> > +mmp_dt_init_timer(void);
> 
> It's better to make use of of_irq_init() & CLOCKSOURCE_OF_DECLARE() for
> timer. So I'll move mmp timer into clocksource & mmp irq into irqchip
> directory in the next week. You can rebase your code. Is it OK?
> 

Ok, I'll rebase after your update.


> > diff --git a/arch/arm/mach-mmp/mmp-dt.c
> b/arch/arm/mach-mmp/mmp-dt.c
> > index d063efa..af0bb5b 100644
> > --- a/arch/arm/mach-mmp/mmp-dt.c
> > +++ b/arch/arm/mach-mmp/mmp-dt.c
> > @@ -19,9 +19,6 @@
> >
> >  #include "common.h"
> >
> > -extern void __init mmp_dt_irq_init(void); -extern void __init
> > mmp_dt_init_timer(void);
> > -
> >  static const struct of_dev_auxdata pxa168_auxdata_lookup[] __initconst
> = {
> >         OF_DEV_AUXDATA("mrvl,mmp-uart", 0xd4017000,
> "pxa2xx-uart.0", NULL),
> >         OF_DEV_AUXDATA("mrvl,mmp-uart", 0xd4018000,
> "pxa2xx-uart.1",
> > NULL), diff --git a/arch/arm/mach-mmp/mmp2-dt.c
> > b/arch/arm/mach-mmp/mmp2-dt.c index fad431a..4ba1fbe 100644
> > --- a/arch/arm/mach-mmp/mmp2-dt.c
> > +++ b/arch/arm/mach-mmp/mmp2-dt.c
> > @@ -21,9 +21,6 @@
> >
> >  #include "common.h"
> >
> > -extern void __init mmp_dt_irq_init(void); -extern void __init
> > mmp_dt_init_timer(void);
> > -
> >  static const struct of_dev_auxdata mmp2_auxdata_lookup[] __initconst
> = {
> >         OF_DEV_AUXDATA("mrvl,mmp-uart", 0xd4030000,
> "pxa2xx-uart.0", NULL),
> >         OF_DEV_AUXDATA("mrvl,mmp-uart", 0xd4017000,
> "pxa2xx-uart.1",
> > NULL),
> > --
> > 1.7.4.1
> >

Best Regards,
Neil Zhang

From broonie at kernel.org  Mon Apr 15 07:15:33 2013
From: broonie at kernel.org (Mark Brown)
Date: Mon, 15 Apr 2013 12:15:33 +0100
Subject: [PATCH v2] UCB1400: Pass ucb1400-gpio data through ac97 bus
In-Reply-To: <1365964548-4193-1-git-send-email-marex@denx.de>
References: <CACRpkdZ+ku_-SBTXwwwRDh7F2TXzpgpAF3k+Ksn98BNYXximXw@mail.gmail.com>
 <1365964548-4193-1-git-send-email-marex@denx.de>
Message-ID: <20130415111533.GB15837@opensource.wolfsonmicro.com>

On Sun, Apr 14, 2013 at 08:35:48PM +0200, Marek Vasut wrote:
> Cc: Linus Walleij <linus.walleij at linaro.org>
> Cc: Jean Delvare <jdelvare at suse.de>
> Cc: Samuel Ortiz <sameo at linux.intel.com>
> Cc: Mark Brown <broonie at opensource.wolfsonmicro.com>
> Cc: Guenter Roeck <linux at roeck-us.net>
> Cc: linux-kernel <linux-kernel at vger.kernel.org>
> Cc: Grant Likely <grant.likely at secretlab.ca>
> Signed-off-by: Marek Vasut <marex at denx.de>

Reviewed-by: Mark Brown <broonie at opensource.wolfsonmicro.com>

it may be a bit ugly but it's still an improvement :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130415/ae84e487/attachment-0001.sig>

From rogerq at ti.com  Mon Apr 15 07:20:08 2013
From: rogerq at ti.com (Roger Quadros)
Date: Mon, 15 Apr 2013 14:20:08 +0300
Subject: [PATCH] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx
Message-ID: <1366024808-4691-1-git-send-email-rogerq@ti.com>

On Beagle xM Rev. Ax/Bx, the USB power enable GPIO logic is
reversed when compared to other revisions i.e. it is
active high instead of active low.

Use the beagle_config.usb_pwr_level flag correctly so that
the power regulator can be configured at runtime.

Signed-off-by: Roger Quadros <rogerq at ti.com>
---
 arch/arm/mach-omap2/board-omap3beagle.c |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c
index 5382215..21136b2 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -112,13 +112,13 @@ static u8 omap3_beagle_version;
  */
 static struct {
 	int mmc1_gpio_wp;
-	int usb_pwr_level;
+	bool usb_pwr_level;	/* 0 - Active Low, 1 - Active High */
 	int dvi_pd_gpio;
 	int usr_button_gpio;
 	int mmc_caps;
 } beagle_config = {
 	.mmc1_gpio_wp = -EINVAL,
-	.usb_pwr_level = GPIOF_OUT_INIT_LOW,
+	.usb_pwr_level = 0,
 	.dvi_pd_gpio = -EINVAL,
 	.usr_button_gpio = 4,
 	.mmc_caps = MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA,
@@ -178,7 +178,7 @@ static void __init omap3_beagle_init_rev(void)
 	case 0:
 		printk(KERN_INFO "OMAP3 Beagle Rev: xM Ax/Bx\n");
 		omap3_beagle_version = OMAP3BEAGLE_BOARD_XM;
-		beagle_config.usb_pwr_level = GPIOF_OUT_INIT_HIGH;
+		beagle_config.usb_pwr_level = 1;
 		beagle_config.mmc_caps &= ~MMC_CAP_8_BIT_DATA;
 		break;
 	case 2:
-- 
1.7.4.1



From martinez.javier at gmail.com  Mon Apr 15 07:25:38 2013
From: martinez.javier at gmail.com (Javier Martinez Canillas)
Date: Mon, 15 Apr 2013 13:25:38 +0200
Subject: [PATCH 3/5] gpio/omap: Add DT support to GPIO driver
In-Reply-To: <CACRpkda4h+qXTvsirPAS7E7sjXhMLE62q=VDy53W8UchsYjbNg@mail.gmail.com>
References: <1329321854-24490-1-git-send-email-b-cousson@ti.com>
 <4F47AD08.4030504@ti.com>
 <CAAwP0s0cB368R2mtbJpTZJreR-5GSRLfxC+8DJLo5nw3_OwBuA@mail.gmail.com>
 <512D39DA.7020306@ti.com> <512D3AB1.1080202@wwwdotorg.org>
 <512D3EC2.6050408@ti.com> <20130302200524.D230F3E1571@localhost>
 <51391F41.5000303@ti.com>
 <CAAwP0s1CFRO-rf==p5sYs1n0gigMif7wuT8Yv0N_iLUDMrtcOg@mail.gmail.com>
 <CACRpkdYHj-rEF3Rk_CWnmmMw_Amr7m8SgQ=-2zsDYuLeuu3azw@mail.gmail.com>
 <514C79E1.4090106@wwwdotorg.org> <514CE0AB.6060207@ti.com>
 <CACRpkdZmv-rAoKSQYpkHHSMzKJOn5TixVW_P3=m7ZNagBYCUPw@mail.gmail.com>
 <515319D5.20105@wwwdotorg.org>
 <CACRpkdYXVLgCz1Tyu-Ls2V2OTc4R3cGNJhfQJB6Hiz_K9dkZYQ@mail.gmail.com>
 <5155C902.7080207@wwwdotorg.org>
 <CACRpkdYbs4-uudpRUY8e+7icYYkZrfM0kReP3pLL5DMiURJ4dg@mail.gmail.com>
 <5165CB9D.1090202@wwwdotorg.org>
 <CACRpkdYirFNqmGhA4K9CL4ve4NYhs8Rd3SFt1iwW9vHBkrcz8g@mail.gmail.com>
 <51671D7B.5060303@wwwdotorg.org>
 <CACRpkdbf32Ef77GmXk9id9+RRjcDRTr7S+F4nznoeZU8y=BT_Q@mail.gmail.com>
 <51673D70.3010503@wwwdotorg.org>
 <CAAwP0s0e2x33jZQhFRY+Hoo61SFqYKRgWk=1mL2+DNxSDJHz+A@mail.gmail.com>
 <CACRpkda4h+qXTvsirPAS7E7sjXhMLE62q=VDy53W8UchsYjbNg@mail.gmail.com>
Message-ID: <CAAwP0s2tdDGXsWm0b5rHsxcv_qjMSOqE8g_mmyNW3oeXW=VpYA@mail.gmail.com>

On Sun, Apr 14, 2013 at 10:53 PM, Linus Walleij
<linus.walleij at linaro.org> wrote:
> On Sun, Apr 14, 2013 at 3:35 AM, Javier Martinez Canillas
> <martinez.javier at gmail.com> wrote:
>
>> Is the following inlined patch [1] what you were thinking that would
>> be the right approach?

Hi Linus, thanks a lot for your feedback.

>
> This looks sort of OK, but I'm still struggling with the question of
> what we could do to help other implementations facing the same issue.
>

Yes, I don't know how we can make it easier to other implementations
(besides adding the irq_request hook to irq_chip) since the logic is
GPIO controller specific.

For example I took a look to drivers/gpio/gpio-tegra.c and if I
understood correctly, the implementation for this driver should be
something like this:

diff --git a/drivers/gpio/gpio-tegra.c b/drivers/gpio/gpio-tegra.c
index 414ad91..a2d5c3d 100644
--- a/drivers/gpio/gpio-tegra.c
+++ b/drivers/gpio/gpio-tegra.c
@@ -346,6 +346,11 @@ static int tegra_gpio_wake_enable(struct irq_data
*d, unsigned int enable)
 }
 #endif

+static int tegra_gpio_irq_request(struct irq_data *d)
+{
+	tegra_gpio_request(NULL, d->hwirq);
+}
+
 static struct irq_chip tegra_gpio_irq_chip = {
 	.name		= "GPIO",
 	.irq_ack	= tegra_gpio_irq_ack,
@@ -355,6 +360,7 @@ static struct irq_chip tegra_gpio_irq_chip = {
 #ifdef CONFIG_PM_SLEEP
 	.irq_set_wake	= tegra_gpio_wake_enable,
 #endif
+	.irq_request    = tegra_gpio_irq_request,
 };

 static const struct dev_pm_ops tegra_gpio_pm_ops = {

This is definitely quite similar to the omap-gpio.c change but not the same.

> This is a pretty hard design pattern to properly replicate in every such
> driver is it not?
>
> Hmmmm
>

Is indeed a hard design pattern but I couldn't figure out a more
generic way to handle this.

Maybe we could use [1] for now to solve the issue that we have with
OMAP GPIO and later when the same issue is found on other GPIO
controllers and a similar change is made on these drivers we will see
some form of pattern that emerge allowing us to make a later refactor
to reduce the code duplication.

Or do you have a better idea on how to solve this?

> Yours,
> Linus Walleij

Best regards,
Javier


From s.nawrocki at samsung.com  Mon Apr 15 07:27:37 2013
From: s.nawrocki at samsung.com (Sylwester Nawrocki)
Date: Mon, 15 Apr 2013 13:27:37 +0200
Subject: [PATCH v3 0/6] Generic PHY Framework
In-Reply-To: <516BD835.8060007@ti.com>
References: <1363770725-13717-1-git-send-email-kishon@ti.com>
 <20130415102009.D358E3E0AA8@localhost> <516BD835.8060007@ti.com>
Message-ID: <516BE429.9040002@samsung.com>

On 04/15/2013 12:36 PM, Kishon Vijay Abraham I wrote:
> On Monday 15 April 2013 03:50 PM, Grant Likely wrote:
>> On Wed, 20 Mar 2013 14:41:59 +0530, Kishon Vijay Abraham I <kishon at ti.com>
>> wrote:
>>> Added a generic PHY framework that provides a set of APIs for the PHY drivers
>>> to create/destroy a PHY and APIs for the PHY users to obtain a reference to
>>> the PHY with or without using phandle. To obtain a reference to the PHY
>>> without using phandle, the platform specfic intialization code (say from board
>>> file) should have already called phy_bind with the binding information. The
>>> binding information consists of phy's device name, phy user device name and an
>>> index. The index is used when the same phy user binds to mulitple phys.
>>>
>>> This framework will be of use only to devices that uses external PHY (PHY
>>> functionality is not embedded within the controller).
>>>
>>> The intention of creating this framework is to bring the phy drivers spread
>>> all over the Linux kernel to drivers/phy to increase code re-use and to
>>> increase code maintainability.
>>>
>>> Comments to make PHY as bus wasn't done because PHY devices can be part of
>>> other bus and making a same device attached to multiple bus leads to bad
>>> design.
>>>
>>> Making omap-usb2 and twl4030 to use this framework is provided as a sample.
>>>
>>> This patch series is developed on 3.9-rc3. Once the patch series gets finalised
>>> I'll resend omap-usb2 and twl4030 part based on Felipe's tree.
>>>
>>
>> [...]
>>
>>>   drivers/Kconfig                                    |    2 +
>>>   drivers/Makefile                                   |    2 +
>>>   drivers/phy/Kconfig                                |   13 +
>>>   drivers/phy/Makefile                               |    5 +
>>>   drivers/phy/phy-core.c                             |  574
>>> ++++++++++++++++++++
>>
>> This looks to be very specific for USB PHYs. Are you intending it to be
>> used for other types of PHYs, like Ethernet PHYs? If not, then this
> 
> Not really. This can be used by USB, SATA and Sylwester was planning to use it
> for video PHY's.

Yes, I have already some RFC patches to handle the display and the camera
interface DPHYs (MIPI DSI, MIPI CSI-2) with this API. I didn't post it, since
this framework is not settled yet. Those DPHYs need very few operations, like
disable/enable only and there was really not suitable API in the kernel until
now to handle them. We had plans in the past to write something like this 
generic PHY framework for the Samsung SoCs.

Some SoCs have plenty different PHYs: USB, SATA, MIPI CSI-2, MIPI DSI, HDMI... 
And some of them are simple enough to be covered by this generic PHY API.

Thanks,
Sylwester


From zhangwm at marvell.com  Mon Apr 15 07:28:51 2013
From: zhangwm at marvell.com (Neil Zhang)
Date: Mon, 15 Apr 2013 04:28:51 -0700
Subject: [PATCH 4/4] ARM: mmp: add SMP support for pxa988
In-Reply-To: <CAN1soZxCX1oUg69MTy0ZAL2vH8SOywDBaZHJ7wgnwgasxPAPdQ@mail.gmail.com>
References: <1365651547-11583-1-git-send-email-zhangwm@marvell.com>
 <CAN1soZxCX1oUg69MTy0ZAL2vH8SOywDBaZHJ7wgnwgasxPAPdQ@mail.gmail.com>
Message-ID: <175CCF5F49938B4D99B2E3EF7F558EBE2D0F68CFE5@SC-VEXCH4.marvell.com>




> -----Original Message-----
> From: Haojian Zhuang [mailto:haojian.zhuang at gmail.com]
> Sent: 2013?4?13? 21:08
> To: Neil Zhang
> Cc: Grant Likely; linux-arm-kernel at lists.infradead.org;
> linux-kernel at vger.kernel.org; Chao Xie
> Subject: Re: [PATCH 4/4] ARM: mmp: add SMP support for pxa988
>
> On Thu, Apr 11, 2013 at 11:39 AM, Neil Zhang <zhangwm at marvell.com>
> wrote:
> > Add SMP support for pxa988.
> >
> > Signed-off-by: Neil Zhang <zhangwm at marvell.com>
> > Signed-off-by: Chao Xie <chao.xie at marvell.com>
> > ---
> >  arch/arm/mach-mmp/Makefile  |    4 +
> >  arch/arm/mach-mmp/common.h  |    2 +
> >  arch/arm/mach-mmp/headsmp.S |  104
> ++++++++++++++++++++++++++
> >  arch/arm/mach-mmp/mmpx-dt.c |    1 +
> >  arch/arm/mach-mmp/platsmp.c |  170
> +++++++++++++++++++++++++++++++++++++++++++
> >  arch/arm/mach-mmp/reset.c   |   66 +++++++++++++++++
> >  arch/arm/mach-mmp/reset.h   |   29 +++++++
> >  7 files changed, 376 insertions(+), 0 deletions(-)  create mode
> > 100644 arch/arm/mach-mmp/headsmp.S  create mode 100644
> > arch/arm/mach-mmp/platsmp.c  create mode 100644
> > arch/arm/mach-mmp/reset.c  create mode 100644
> > arch/arm/mach-mmp/reset.h
> >
> > diff --git a/arch/arm/mach-mmp/Makefile
> b/arch/arm/mach-mmp/Makefile
> > index b60065f..e7b6173 100644
> > --- a/arch/arm/mach-mmp/Makefile
> > +++ b/arch/arm/mach-mmp/Makefile
> > @@ -9,6 +9,10 @@ obj-$(CONFIG_CPU_PXA168)       += pxa168.o
> >  obj-$(CONFIG_CPU_PXA910)       += pxa910.o
> >  obj-$(CONFIG_CPU_MMP2)         += mmp2.o sram.o
> >
> > +ifeq ($(CONFIG_SMP),y)
> > +obj-$(CONFIG_CPU_PXA988)       += platsmp.o headsmp.o reset.o
> > +endif
> > +
> You already select CONFIG_SMP if PXA988 is selected. There's no reason to
> check CONFIG_SMP in Makefile again.

CPU_PXA988 only select HAVE_SMP, we can still not enable SMP.


>
> >  ifeq ($(CONFIG_COMMON_CLK), )
> >  obj-y                          += clock.o
> >  obj-$(CONFIG_CPU_PXA168)       += clock-pxa168.o
> > diff --git a/arch/arm/mach-mmp/common.h
> b/arch/arm/mach-mmp/common.h
> > index 8c9b510..7496cd0 100644
> > --- a/arch/arm/mach-mmp/common.h
> > +++ b/arch/arm/mach-mmp/common.h
> > @@ -1,5 +1,7 @@
> >  #define ARRAY_AND_SIZE(x)      (x), ARRAY_SIZE(x)
> >
> > +extern struct smp_operations mmp_smp_ops;
> > +
> >  extern void timer_init(int irq);
> >
> >  extern void __init icu_init_irq(void); diff --git
> > a/arch/arm/mach-mmp/headsmp.S b/arch/arm/mach-mmp/headsmp.S
> new file
> > mode 100644 index 0000000..2b6177e
> > --- /dev/null
> > +++ b/arch/arm/mach-mmp/headsmp.S
> > @@ -0,0 +1,104 @@
> > +/*
> > + * linux/arch/arm/mach-mmp/headsmp.S
> > + *
> > + * Copyright (C) 2012 Marvell, Inc.
> > + *
> > + * Author: Neil Zhang <zhangwm at marvell.com>
> > + *
> > + * This software is licensed under the terms of the GNU General
> > +Public
> > + * License version 2, as published by the Free Software Foundation,
> > +and
> > + * may be copied, distributed, and modified under those terms.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > + * GNU General Public License for more details.
> > + *
> > + */
> > +#include <linux/linkage.h>
> > +#include <linux/init.h>
> > +#include <asm/memory.h>
> > +#include <asm/cache.h>
> > +#include <asm/assembler.h>
> > +#include <mach/addr-map.h>
> > +
> > +       __CPUINIT
> > +
> > +/*
> > + * Marvell specific entry point for secondary CPUs.
> > + * The secondary kernel init calls v7_flush_dcache_all before it
> > +enables
> > + * the L1; however, the L1 comes out of reset in an undefined state,
> > +so
> > + * the clean + invalidate performed by v7_flush_dcache_all causes a
> > +bunch
> > + * of cache lines with uninitialized data and uninitialized tags to
> > +get
> > + * written out to memory, which does really unpleasant things to the
> > +main
> > + * processor.  We fix this by performing an invalidate, rather than a
> > + * clean + invalidate for secondary core, before jumping into the kernel.
> > + *
> > + * This funciton is cloned from arch/arm/mach-tegra/headsmp.S, and
> > +needs
> > + * to be called for both secondary cores startup and primary core
> > +resume
> > + * procedures.
> > + */
> > +       .align L1_CACHE_SHIFT
> > +
> > +
> > +/*
> > + * PXA specific entry point for secondary CPUs.  This provides
> > + * a "holding pen" into which all secondary cores are held until
> > +we're
> > + * ready for them to initialise.
> > + */
> > +ENTRY(mmp_secondary_startup)
> > +       mrc     p15, 0, r0, c0, c0, 5
> > +       and     r0, r0, #15
> > +       adr     r4, 1f
> > +       ldmia   r4, {r5, r6}
> > +       sub     r4, r4, r5
> > +       add     r6, r6, r4
> > +pen:   ldr     r7, [r6]
> > +       cmp     r7, r0
> > +       bne     pen
> > +
> > +       /*
> > +        * we've been released from the holding pen: secondary_stack
> > +        * should now contain the SVC stack for this core
> > +        */
> > +       bl      v7_invalidate_l1
> > +       b       secondary_startup
> > +ENDPROC(mmp_secondary_startup)
> > +
> > +       .align  2
> > +1:     .long   .
> > +       .long   pen_release
> > +
> > +
> > +/*
> > + * Note: The following code is located into the .data section. This is to
> > + *       allow sw_reset_flag and cpu_plugin_handler to be accessed
> with a
> > + *       relative load while we can't rely on any MMU translation.
> > + *       Reference from: arch/arm/kernel/sleep.S
> > + */
> > +
> > +       .data
> > +       .align
> > +
> > +/*
> > + * ROM code jumps to this function while waking up from CPU
> > + * OFF or software reset state. Physical address of the function is
> > + * stored at CA9_WARM_RESET_VECTOR while system is bring up.
> > + */
> > +ENTRY(mmp_cpu_reset_entry)
> > +       adr     r1, mmp_entry_vectors
> > +       mrc     p15, 0, r0, c0, c0, 5
> > +       and     r0, r0, #15             @ fetch CPUID
> > +1:
> > +       ldr     r2, [r1, r0, lsl #2]    @ get the handler addr for this
> core
> > +       cmp     r2, #0
> > +       movne   pc, r2                  @ jump to the handler
> > +       beq     1b
> > +ENDPROC(mmp_cpu_reset_entry)
> > +
> > +       /* Point to the address that save handlers for each core */
> > +       .global mmp_entry_vectors
> > +mmp_entry_vectors:
> > +       .rept   CONFIG_NR_CPUS
> > +        .long   0                               @ preserve
> stack phys ptr here
> > +       .endr
> > diff --git a/arch/arm/mach-mmp/mmpx-dt.c
> b/arch/arm/mach-mmp/mmpx-dt.c
> > index bbc0c50..a5f5501 100644
> > --- a/arch/arm/mach-mmp/mmpx-dt.c
> > +++ b/arch/arm/mach-mmp/mmpx-dt.c
> > @@ -71,6 +71,7 @@ static const char *pxa988_dt_board_compat[]
> > __initdata = {  };
> >
> >  DT_MACHINE_START(PXA988_DT, "Marvell PXA988 (Device Tree
> Support)")
> > +       .smp            = smp_ops(mmp_smp_ops),
> >         .map_io         = mmp_map_io,
> >         .init_irq       = pxa988_dt_gic_init,
> >         .init_time      = pxa988_dt_init_timer,
> > diff --git a/arch/arm/mach-mmp/platsmp.c
> b/arch/arm/mach-mmp/platsmp.c
> > new file mode 100644 index 0000000..a6590a3
> > --- /dev/null
> > +++ b/arch/arm/mach-mmp/platsmp.c
> > @@ -0,0 +1,170 @@
> > +/*
> > + *  linux/arch/arm/mach-mmp/platsmp.c
> > + *
> > + *  Copyright (C) 2002 ARM Ltd.
> > + *  All Rights Reserved
> > + *
> > + * This program is free software; you can redistribute it and/or
> > +modify
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
> > + */
> > +#include <linux/init.h>
> > +#include <linux/errno.h>
> > +#include <linux/delay.h>
> > +#include <linux/device.h>
> > +#include <linux/jiffies.h>
> > +#include <linux/smp.h>
> > +#include <linux/io.h>
> > +#include <linux/irq.h>
> > +
> > +#include <asm/cacheflush.h>
> > +#include <mach/hardware.h>
> > +#include <linux/irqchip/arm-gic.h>
> > +#include <asm/mach-types.h>
> > +#include <asm/localtimer.h>
> > +#include <asm/smp_scu.h>
> > +
> > +#include <mach/irqs.h>
> > +#include <mach/addr-map.h>
> > +
> > +#include "common.h"
> > +#include "reset.h"
> > +
> > +/*
> > + * Write pen_release in a way that is guaranteed to be visible to all
> > + * observers, irrespective of whether they're taking part in
> > +coherency
> > + * or not.  This is necessary for the hotplug code to work reliably.
> > + */
> > +static void __cpuinit write_pen_release(int val) {
> > +       pen_release = val;
> > +       smp_wmb();
> > +       __cpuc_flush_dcache_area((void *)&pen_release,
> sizeof(pen_release));
> > +       outer_clean_range(__pa(&pen_release), __pa(&pen_release +
> 1));
> > +}
> > +
> > +#ifdef CONFIG_HAVE_ARM_SCU
> > +static void __iomem *scu_get_base_addr(void) {
> > +       return SCU_VIRT_BASE;
> > +}
> > +#endif
> > +
> > +static inline unsigned int get_core_count(void) {
> > +       u32 ret = 1;
> > +#ifdef CONFIG_HAVE_ARM_SCU
> > +       ret = scu_get_core_count(scu_get_base_addr());
> > +#endif
> > +
> > +       return ret;
> > +}
> > +
> > +static DEFINE_SPINLOCK(boot_lock);
> > +
> > +static void __cpuinit mmp_secondary_init(unsigned int cpu) {
> > +       /*
> > +        * if any interrupts are already enabled for the primary
> > +        * core (e.g. timer irq), then they will not have been enabled
> > +        * for us: do so
> > +        */
> > +       gic_secondary_init(0);
> > +
> > +       /*
> > +        * let the primary processor know we're out of the
> > +        * pen, then head off into the C entry point
> > +        */
> > +       write_pen_release(-1);
> > +
> > +       /*
> > +        * Synchronise with the boot thread.
> > +        */
> > +       spin_lock(&boot_lock);
> > +       spin_unlock(&boot_lock);
> Lock & unlock without protecting anything. If so, you can remove this.
>
> > +}
> > +
> > +static int __cpuinit mmp_boot_secondary(unsigned int cpu, struct
> > +task_struct *idle) {
> > +       unsigned long timeout;
> > +
> > +       /*
> > +        * Avoid timer calibration on slave cpus. Use the value calibrated
> > +        * on master cpu. Referenced from tegra3
> > +        */
> > +       preset_lpj = loops_per_jiffy;
> > +
> > +       /*
> > +        * set synchronisation state between this boot processor
> > +        * and the secondary one
> > +        */
> > +
> > +       spin_lock(&boot_lock);
> > +
> > +       /*
> > +        * The secondary processor is waiting to be released from
> > +        * the holding pen - release it, then wait for it to flag
> > +        * that it has been released by resetting pen_release.
> > +        *
> > +        * Note that "pen_release" is the hardware CPU ID, whereas
> > +        * "cpu" is Linux's internal ID.
> > +        */
> > +       write_pen_release(cpu);
> > +
> > +       /* reset the cpu, let it branch to the kernel entry */
> > +       mmp_cpu_power_up(cpu);
> > +
> > +       timeout = jiffies + (1 * HZ);
> > +       while (time_before(jiffies, timeout)) {
> > +               smp_rmb();
> > +               if (pen_release == -1)
> > +                       break;
> > +
> > +               udelay(10);
> > +       }
> > +
> > +       /*
> > +        * now the secondary core is starting up let it run its
> > +        * calibrations, then wait for it to finish
> > +        */
> > +       spin_unlock(&boot_lock);
> > +
> > +       return pen_release != -1 ? -ENOSYS : 0; }
> > +
> > +/*
> > + * Initialise the CPU possible map early - this describes the CPUs
> > + * which may be present or become present in the system.
> > + */
> > +static void __init mmp_smp_init_cpus(void) {
> > +       unsigned int i, ncores = get_core_count();
> > +
> > +       for (i = 0; i < ncores; i++)
> > +               set_cpu_possible(i, true); }
> > +
> > +static void __init mmp_smp_prepare_cpus(unsigned int max_cpus) {
> > +       int i;
> > +
> > +       /*
> > +        * Initialise the present map, which describes the set of CPUs
> > +        * actually populated at the present time.
> > +        */
> > +       for (i = 0; i < max_cpus; i++)
> > +               set_cpu_present(i, true);
> > +
> > +#ifdef CONFIG_HAVE_ARM_SCU
> > +       scu_enable(scu_get_base_addr()); #endif
> > +
> > +       mmp_entry_vector_init();
> > +}
> > +
> > +struct smp_operations mmp_smp_ops __initdata = {
> > +       .smp_init_cpus          = mmp_smp_init_cpus,
> > +       .smp_prepare_cpus       = mmp_smp_prepare_cpus,
> > +       .smp_secondary_init     = mmp_secondary_init,
> > +       .smp_boot_secondary     = mmp_boot_secondary,
> > +};
> > diff --git a/arch/arm/mach-mmp/reset.c b/arch/arm/mach-mmp/reset.c
> new
> > file mode 100644 index 0000000..b47e400
> > --- /dev/null
> > +++ b/arch/arm/mach-mmp/reset.c
> > @@ -0,0 +1,66 @@
> > +/*
> > + * linux/arch/arm/mach-mmp/reset.c
> > + *
> > + * Author:     Neil Zhang <zhangwm at marvell.com>
> > + * Copyright:  (C) 2012 Marvell International Ltd.
> > + *
> > + * 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.
> > + */
> > +
> > +#include <linux/kernel.h>
> > +#include <linux/smp.h>
> > +
> > +#include <asm/io.h>
> > +#include <asm/cacheflush.h>
> > +#include <asm/mach/map.h>
> > +
> > +#include <mach/addr-map.h>
> > +
> > +#include "reset.h"
> > +
> > +#define PMU_CC2_AP                     APMU_REG(0x0100)
> > +#define CIU_CA9_WARM_RESET_VECTOR      CIU_REG(0x00d8)
> > +
> > +/*
> > + * This function is called from boot_secondary to bootup the secondary
> cpu.
> > + */
> > +void mmp_cpu_power_up(u32 cpu)
> > +{
> > +       u32 tmp;
> > +
> > +       BUG_ON(cpu == 0);
> > +
> > +       tmp = readl(PMU_CC2_AP);
> > +       if (tmp & CPU_CORE_RST(cpu)) {
> > +               /* Release secondary core from reset */
> > +               tmp &= ~(CPU_CORE_RST(cpu)
> > +                       | CPU_DBG_RST(cpu) |
> CPU_WDOG_RST(cpu));
> > +               writel(tmp, PMU_CC2_AP);
> > +       }
> > +}
> > +
> > +void mmp_set_entry_vector(u32 cpu, u32 addr) {
> > +       BUG_ON(cpu >= CONFIG_NR_CPUS);
> > +
> > +       mmp_entry_vectors[cpu] = addr;
> > +       smp_wmb();
> > +       __cpuc_flush_dcache_area((void *)&mmp_entry_vectors[cpu],
> > +                               sizeof(mmp_entry_vectors[cpu]));
> > +       outer_clean_range(__pa(&mmp_entry_vectors[cpu]),
> > +                               __pa(&mmp_entry_vectors[cpu +
> 1])); }
> > +
> > +void __init mmp_entry_vector_init(void) {
> > +       int cpu;
> > +
> > +       /* We will reset from DDR directly by default */
> > +       writel(__pa(mmp_cpu_reset_entry),
> CIU_CA9_WARM_RESET_VECTOR);
> > +
> > +       for (cpu = 1; cpu < CONFIG_NR_CPUS; cpu++)
> > +               mmp_set_entry_vector(cpu,
> > +__pa(mmp_secondary_startup)); }
> > diff --git a/arch/arm/mach-mmp/reset.h b/arch/arm/mach-mmp/reset.h
> new
> > file mode 100644 index 0000000..78d5486
> > --- /dev/null
> > +++ b/arch/arm/mach-mmp/reset.h
> > @@ -0,0 +1,29 @@
> > +/*
> > + * linux/arch/arm/mach-mmp/include/mach/reset.h
> > + *
> > + * Author:     Neil Zhang <zhangwm at marvell.com>
> > + * Copyright:  (C) 2012 Marvell International Ltd.
> > + *
> > + * 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.
> > + */
> > +
> > +#ifndef __RESET_PXA988_H__
> > +#define __RESET_PXA988_H__
> > +
> > +#define CPU_CORE_RST(n)        (1 << ((n) * 4 + 16))
> > +#define CPU_DBG_RST(n) (1 << ((n) * 4 + 18))
> > +#define CPU_WDOG_RST(n)        (1 << ((n) * 4 + 19))
> > +
> > +extern u32 mmp_entry_vectors[CONFIG_NR_CPUS];
> > +
> > +void mmp_secondary_startup(void);
> > +void mmp_cpu_reset_entry(void);
> > +
> > +void mmp_cpu_power_up(u32 cpu);
> > +void mmp_set_entry_vector(u32 cpu, u32 addr); void __init
> > +mmp_entry_vector_init(void);
> > +
> > +#endif /* __RESET_PXA988_H__ */
> > --
> > 1.7.4.1
> >


Best Regards,
Neil Zhang

From hechtb at gmail.com  Mon Apr 15 07:33:31 2013
From: hechtb at gmail.com (Bastian Hecht)
Date: Mon, 15 Apr 2013 13:33:31 +0200
Subject: [PATCH v2 1/2] ARM: shmobile: r8a7740: Add Suspend-To-RAM A3SM
In-Reply-To: <20130412142649.GE6637@e102568-lin.cambridge.arm.com>
References: <1365689264-14410-1-git-send-email-hechtb+renesas@gmail.com>
 <20130412142649.GE6637@e102568-lin.cambridge.arm.com>
Message-ID: <CABYn4szh7WZSCZn-xskyEW+J6+YGL0n9ueqAA3MX-fAhyjsLsA@mail.gmail.com>

Hello Lorenzo,

thanks for the review.

2013/4/12 Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>:
> On Thu, Apr 11, 2013 at 03:07:43PM +0100, Bastian Hecht wrote:
>
> [...]
>
>> diff --git a/arch/arm/mach-shmobile/sleep-r8a7740.S b/arch/arm/mach-shmobile/sleep-r8a7740.S
>> new file mode 100644
>> index 0000000..762f978
>> --- /dev/null
>> +++ b/arch/arm/mach-shmobile/sleep-r8a7740.S
>> @@ -0,0 +1,72 @@
>> +/*
>> + * Low level sleep code for the SoC r8a7740
>> + *
>> + * Copyright (C) 2013 Bastian Hecht
>> + *
>> + * This file is subject to the terms and conditions of the GNU General Public
>> + * License.  See the file "COPYING" in the main directory of this archive
>> + * for more details.
>> + */
>> +
>> +#include <linux/linkage.h>
>> +#include <linux/init.h>
>> +#include <asm/memory.h>
>> +
>> +#ifdef CONFIG_SUSPEND
>> +
>> +/* r8a7740_shutdown expects L2 to be flushed */
>> +     .text
>> +ENTRY(r8a7740_shutdown)
>> +     stmfd   sp!, {r4-r12, lr}
>> +
>> +     /* make sure the stack stays intact */
>> +     bl      v7_flush_dcache_all
>> +
>
> Why do not you move the cache flush above after clearing the C bit ?
> You must not push on the stack _after_ clearing the C bit and before
> cleaning the cache, that's the only requirement (well basically you
> should not write any data and do not rely on any dirty data sitting
> in the cache, since with the C bit cleared as I already said A9 L1
> D-cache is not searched).
>
> AS long as, with C bit cleared, you do NOT push on the stack before
> cleaning the cache, your cache flushing routine will clean data to DRAM,
> so you are fine. v7_flush_dcache_all does not use the stack.
>
>         mrc     p15, 0, r0, c1, c0, 0
>         bic     r0, r0, #(1 << 2)               @ Disable the C bit
>         mcr     p15, 0, r0, c1, c0, 0
>         isb
>         bl      v7_flush_dcache_all
>
> This code snippet will do and it is compliant with the SMP procedure,
> I do not want people to copy'n'paste code that does not work on SMP,
> I know this code runs on UP so the sequence above is safe, but why not make
> the sequence identical for both UP/SMP ?

Now this looks super straight forward. I wonder how I came up with
inverted order (even if works in the UP case). Probably when you look
at others code and they put a v7_flush_dcache_all before the disable,
one (meaning me...) starts to bend the underlying ideas about the
caches until it fits to the code you see.

Anyway: Of course I'll take the code sequence then that works for the
UP and SMP cases.

>> +     /*
>> +      * Clear the SCTLR.C bit to prevent further data cache
>> +      * allocation. Clearing SCTLR.C would make all the data accesses
>> +      * strongly ordered and would not hit the cache.
>> +      */
>> +     mrc     p15, 0, r0, c1, c0, 0
>> +     bic     r0, r0, #(1 << 2)               @ Disable the C bit
>> +     mcr     p15, 0, r0, c1, c0, 0
>> +     isb
>> +
>> +     /*
>> +      * We don't issue another v7_flush_dcache_all here as seen in many
>> +      * other places as we have a UP core and the L1 could not soak up
>> +      * data from other L1 caches in the meantime.
>> +      */
>> +
>> +     bl      cpu_v7_do_idle
>> +
>> +     /* in rare cases when WFI fails we end up here and restore things */
>
> I am still baffled by this "wfi failures" and how hardware can manage
> this situation _properly_, if you can explain to me how this works
> that would be grand.

I unfortunately don't know about the hardware design of this SoC.

> This code is also called by CPUidle right ?

I haven't experienced this when using suspend-to-ram but only for
CPUIdle. Of course this might be just a matter of probability though.

> So,
> IRQs can still cause wfi completion, there has to be a handshake between
> the core and power controller to prevent the CPU from being shutdown
> while executing code (power down command sent, standbywfi asserted and
> then released following wfi completion).
>
> Anyway, I do not like the code sequence (and I know that eg OMAP4 executes
> the same code) above because again, it works on UP, but people might be
> tempted to copy'n'paste it to their SMP implementation (with the addition
> of SMP bit restore in ACTLR).
>
> OMAP4 sequence is missing TLB flush since the core runs for a time window with
> incoherent TLBs (out of SMP). It works because other cores can't update
> their page tables while the core exiting wfi is running out of coherency
> (ie coupled idle C-states, either all CPUs down or no CPU down), but
> again, that code should not be copied verbatim since it fails to flush
> TLBs, AFAIK.
>
> Again, you are running a UP kernel so this code does not suffer from
> the same problem, but if this code is copied and used on SMP platforms then
> we do have problem and that has to be prevented.
>
> Why do not you turn MMU off (cpu_reset) and jump to the reset vector if
> wfi fails (code in arch/arm/kernel/process.c __soft_restart(), minus the
> cache flushing ?
>
>         phys_reset_t phys_reset;
>
>         /* Take out a flat memory mapping. */
>         setup_mm_for_reboot();
>
>         phys_reset = (phys_reset_t)(unsigned long)virt_to_phys(cpu_reset);
>         phys_reset((unsigned long)addr);
>
>         BUG();
>
> where addr == virt_to_phys(cpu_resume);
>
> from what I gather from the code below.
>
> There is just a tiny performance hit owing to a couple of fetches from
> DRAM (MMU off), then cpu_resume restores the C bit and the MMU (and flushes
> the TLBs) so the virtual address space and caches are back on. By the time wfi
> fails, caches are invalid anyway so in both cases they have to be refilled.
>
> On top of that, this code is not really SH specific, it is plain v7 code
> that can be standardised.

Ok that sounds good. As we don't touch the hotpath I don't care much
about some extra cycles and I appreciate moving towards
standardization. I'll try that out and send a v3 with the two changes.

So thanks a lot,

 Bastian

> For now it is just a, hopefully useful, rant.
>
> Lorenzo
>
>> +     mrc     p15, 0, r0, c1, c0, 0
>> +     orr     r0, r0, #(1 << 2)               @ Enable the C bit
>> +     mcr     p15, 0, r0, c1, c0, 0
>> +     isb
>> +
>> +     ldmfd   sp!, {r4-r12, pc}
>> +ENDPROC(r8a7740)
>> +
>> +     .text
>> +ENTRY(v7_cpu_resume)
>> +     bl      v7_invalidate_l1
>> +     b       cpu_resume
>> +ENDPROC(v7_cpu_resume)
>> +
>> +/*
>> + * The entry point of a warm reboot, used by wakeup scenarios
>> + *
>> + * The CPU jumps in this case to (0xfffff000 & SBAR), so we need
>> + * to align this function properly.
>> + * We use a long jump into the text segment and use the physical
>> + * address as the MMU is still turned off.
>> + */
>> +     .align  12
>> +     .text
>> +ENTRY(r8a7740_resume)
>> +     ldr     pc, 1f
>> +1:   .long   v7_cpu_resume - PAGE_OFFSET + PLAT_PHYS_OFFSET
>> +ENDPROC(r8a7740_resume_core_standby)
>> +#endif
>> --
>


From grant.likely at secretlab.ca  Mon Apr 15 07:34:16 2013
From: grant.likely at secretlab.ca (Grant Likely)
Date: Mon, 15 Apr 2013 12:34:16 +0100
Subject: [PATCH v3 1/6] drivers: phy: add generic PHY framework
In-Reply-To: <1363770725-13717-2-git-send-email-kishon@ti.com>
References: <1363770725-13717-1-git-send-email-kishon@ti.com>
 <1363770725-13717-2-git-send-email-kishon@ti.com>
Message-ID: <20130415113416.7C3943E0AA8@localhost>

On Wed, 20 Mar 2013 14:42:00 +0530, Kishon Vijay Abraham I <kishon at ti.com> wrote:
> The PHY framework provides a set of APIs for the PHY drivers to
> create/destroy a PHY and APIs for the PHY users to obtain a reference to the
> PHY with or without using phandle. To obtain a reference to the PHY without
> using phandle, the platform specfic intialization code (say from board file)
> should have already called phy_bind with the binding information. The binding
> information consists of phy's device name, phy user device name and an index.
> The index is used when the same phy user binds to mulitple phys.
> 
> PHY drivers should create the PHY by passing phy_descriptor that has
> describes the PHY (label, type etc..) and ops like init, exit, suspend, resume,
> poweron, shutdown.
> 
> The documentation for the generic PHY framework is added in
> Documentation/phy.txt and the documentation for the sysfs entry is added
> in Documentation/ABI/testing/sysfs-class-phy.
> 
> Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>

Hi Kishon,

For review purposes, I'll skip most of the implementation and focus on
the data structures. I think you need to take another look at the
approach your using. The kernel already provides a lot of support for
implementing devices and binding them to drivers that you should be
able to use...


[...]
> +/**
> + * struct phy - represent the phy device
> + * @dev: phy device
> + * @label: label given to phy
> + * @type: specifies the phy type
> + * @of_node: device node of the phy
> + * @ops: function pointers for performing phy operations
> + */
> +struct phy {
> +	struct device		dev;
> +	const char		*label;
> +	int			type;
> +	struct bus_type		*bus;
> +	struct device_node	*of_node;
> +	struct phy_ops		*ops;
> +};

Alright, so the core of the functionality is this 'struct phy' which
tracks all the instances of PHY devices. As I understand it each
physical phy will have a 'struct phy' instance tracking it. That makes
sense.

struct phy embeds a struct device. Also good. The linux driver model
knows all about devices and how to handle them. However, most of the
rest of this structure looks to be reinventing stuff the driver model
already does.

'label' seems unnecessary. struct device embeds a struct kobject, which
means it has a name and shows up in sysfs. Is there a reason that the
device name cannot be used directly?

'type' I just don't understand. I don't see any users of it in this
patch. I only see where it is set.

'bus' absolutely should not be here. The bus type should be set in the
struct device by this subsystem when the device gets registered. There
is no reason to have a pointer to it here.

'of_node' is already in struct device

Finally, it really doesn't look right for a device object to have an
'ops' structure. The whole point of the driver model is that a struct
device doesn't encapsulate any behaviour. A device gets registers to a
bus type, and then the driver core will associate a struct device_driver
to a device that it is able to drive, and the struct device_driver is
supposed to contain any ops structure used to control the device.

> +
> +/**
> + * struct phy_bind - represent the binding for the phy
> + * @dev_name: the device name of the device that will bind to the phy
> + * @phy_dev_name: the device name of the phy
> + * @index: used if a single controller uses multiple phys
> + * @auto_bind: tells if the binding is done explicitly from board file or not
> + * @phy: reference to the phy
> + * @list: to maintain a linked list of the binding information
> + */
> +struct phy_bind {
> +	const char	*dev_name;
> +	const char	*phy_dev_name;
> +	int		index;
> +	int		auto_bind:1;
> +	struct phy	*phy;
> +	struct list_head list;
> +};

How are PHYs attached to the system. Would the PHY be a direct child of
the host controller device, or would a PHY hang off another bus (like
i2c) for control? (this is how Ethernet phys work; they hang off the
MDIO bus, but may be attached to any Ethernet controller).

Since there is at most a 1:N relationship between host controllers and
PHYs, there shouldn't be any need for a separate structure to describe
binding. Put the inding data into the struct phy itself. Each host
controller can have a list of phys that it is bound to.

Tring to maintain a separate global list of PHY bindings isn't a good
idea. Keep it local to the host controller and the specific phys
instead.

g.


From rabin at rab.in  Mon Apr 15 07:36:00 2013
From: rabin at rab.in (Rabin Vincent)
Date: Mon, 15 Apr 2013 13:36:00 +0200
Subject: [PATCH 3/8] dmaengine: ste_dma40: Actually write the runtime
 configuration to registers
In-Reply-To: <20130415110601.GE6512@gmail.com>
References: <1365532783-27425-1-git-send-email-lee.jones@linaro.org>
 <1365532783-27425-3-git-send-email-lee.jones@linaro.org>
 <CAH+eYFB_fYmCjvh5PXKRhd-FnaWfeu+LtH+q3VywhCk-PYhHVQ@mail.gmail.com>
 <20130415110601.GE6512@gmail.com>
Message-ID: <CAH+eYFB2+oMPXsnzQVVrEK8CjKGVYFa_n4Wxr=CpdtJwFfOGYw@mail.gmail.com>

2013/4/15 Lee Jones <lee.jones at linaro.org>:
> On Fri, 12 Apr 2013, Rabin Vincent wrote:
>> 2013/4/9 Lee Jones <lee.jones at linaro.org>:
>> > Someone has spent a fair amount of effort writing a runtime configuration
>> > changing algorithm for DMA clients. However, the config appears to never
>> > actually make it to hardware. In order for the configuration to take hold
>> > we need to issue a d40_config_write(), as this is the routine which writes
>> > it into the hardware's registers.
>>
>> No, it's not.  This function is only for initial configuration which
>> should only be written when the channel is allocated.  In fact, by
>> calling it here in runtime_config, you are introducing a serious bug:
>> other logical channels on the same physical channel will stop because of
>> the SSLNK/SDLNK of the physical channel being zeroed.
>>
>> The runtime config already makes it the hardware in the existing code,
>> via d40_*_cfg().
>
> Sorry Rabin, but the only place I can see the config being written is
> in d40_config_write().
>
> Can you paste the line of code in d40_*_cfg() which actually writes
> the config to hardware please? I don't see it.

It's not that simple.  There are some pointers passed to d40_*_cfg() and
that function writes the configuration to the variables those pointers
point to (d40c->log_def.lcsp1, d40c->src_def_cfg, etc.).  Please read
the code to see how those variables end up being used later when the
LLIs are prepared for the HW.


From sachin.kamat at linaro.org  Mon Apr 15 07:32:02 2013
From: sachin.kamat at linaro.org (Sachin Kamat)
Date: Mon, 15 Apr 2013 17:02:02 +0530
Subject: [PATCH 3/7] ARM: exynos: add missing properties for combiner IRQs
In-Reply-To: <201304151041.44805.arnd@arndb.de>
References: <1365775405-115297-1-git-send-email-arnd@arndb.de>
 <1365775405-115297-4-git-send-email-arnd@arndb.de>
 <CAK9yfHzubnyo7wD4gmmjLobkoy2qPXWyPp-0GQq8wiJH1PWZTg@mail.gmail.com>
 <201304151041.44805.arnd@arndb.de>
Message-ID: <CAK9yfHwXYRqo2yG1moWvMnEmNWXCVL7a9eKzi2we=QmdpVsz-w@mail.gmail.com>

>> > diff --git a/arch/arm/boot/dts/exynos4212.dtsi b/arch/arm/boot/dts/exynos4212.dtsi
>> > index 36d4299..f83c3c1 100644
>> > --- a/arch/arm/boot/dts/exynos4212.dtsi
>> > +++ b/arch/arm/boot/dts/exynos4212.dtsi
>> > @@ -26,6 +26,15 @@
>> >                 cpu-offset = <0x8000>;
>> >         };
>> >
>> > +       interrupt-controller at 10440000 {
>>
>> Don't we need a node name here (combiner:interrupt-controller at 10440000)?
>
> Why?

Since it is being referenced as "&combiner" by other bindings, i
thought that was required.

The "combiner:" part is just a label. Actually I think the preferred
> syntax is
>
> &combiner {
>         samsung,combiner-nr = <18>;
> };
>
> which is much shorter to write, but I did not want to change the style used
> in the rest of the file.
>
>> > +                combiner-nr = <18>;
>>     ^^^^^^^^^^^
>> nit: tabs instead of space would look better.
>
> I fixed that up locally, but I think I sent out the wrong version.

OK.

>
>> > diff --git a/arch/arm/boot/dts/exynos4412.dtsi b/arch/arm/boot/dts/exynos4412.dtsi
>> > index d75c047..4cb657e 100644
>> > --- a/arch/arm/boot/dts/exynos4412.dtsi
>> > +++ b/arch/arm/boot/dts/exynos4412.dtsi
>> > @@ -26,6 +26,15 @@
>> >                 cpu-offset = <0x4000>;
>> >         };
>> >
>> > +       interrupt-controller at 10440000 {
>> > +               combiner-nr = <20>;
>> Same as above (for exynos4212.dtsi).
>>
>> > +               interrupts = <0 0 0>, <0 1 0>, <0 2 0>, <0 3 0>,
>> > +                            <0 4 0>, <0 5 0>, <0 6 0>, <0 7 0>,
>> > +                            <0 8 0>, <0 9 0>, <0 10 0>, <0 11 0>,
>> > +                            <0 12 0>, <0 13 0>, <0 14 0>, <0 15 0>,
>> > +                            <0 107 0>, <0 108 0>>, <0 48 0>, <0 42 0>;
>>                                                               ^^^
>> Syntax error.
>>
>> We have a combiner node defined in exynos4x12.dtsi. With the bindings
>> now defined separately in 4212 and 4412 dtsi files, probably the one
>> in 4x12 could be dropped?
>
> I did not see that one, but it seems to have the wrong numbers in the last
> four interrupt specifiers. I think it would be better to just fix that one
> and keep using it.

OK. Do you want me to fix it and send as a patch or would you like to do it?


-- 
With warm regards,
Sachin


From catalin.marinas at arm.com  Mon Apr 15 07:43:07 2013
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Mon, 15 Apr 2013 12:43:07 +0100
Subject: [PATCH v2] arm64: Fix task tracing
In-Reply-To: <20130415105840.GB29528@arm.com>
References: <20130408153132.GQ17476@mudshark.cambridge.arm.com>
 <1365510814-21343-1-git-send-email-cov@codeaurora.org>
 <20130415101159.GA25095@localhost.cambridge.arm.com>
 <20130415104542.GE9827@mudshark.cambridge.arm.com>
 <20130415105840.GB29528@arm.com>
Message-ID: <20130415114307.GC29528@arm.com>

On Mon, Apr 15, 2013 at 11:58:40AM +0100, Catalin Marinas wrote:
> On Mon, Apr 15, 2013 at 11:45:42AM +0100, Will Deacon wrote:
> > On Mon, Apr 15, 2013 at 11:11:59AM +0100, Catalin Marinas wrote:
> > > On Tue, Apr 09, 2013 at 01:33:34PM +0100, Christopher Covington wrote:
> > > > For accurate accounting pass contextidr_thread_switch the prev
> > > > task pointer, since cpu_switch_to has at that point changed the
> > > > the stack pointer.
> > > > 
> > > > Signed-off-by: Christopher Covington <cov at codeaurora.org>
> > > > ---
> > > >  arch/arm64/kernel/process.c | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > 
> > > > diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
> > > > index 0337cdb..a49b25a 100644
> > > > --- a/arch/arm64/kernel/process.c
> > > > +++ b/arch/arm64/kernel/process.c
> > > > @@ -315,7 +315,7 @@ struct task_struct *__switch_to(struct task_struct *prev,
> > > >  	/* the actual thread switch */
> > > >  	last = cpu_switch_to(prev, next);
> > > >  
> > > > -	contextidr_thread_switch(next);
> > > > +	contextidr_thread_switch(prev);
> > > 
> > > The original code was indeed wrong but using prev isn't any better. For
> > > a newly created thread, prev is probably 0 (if it's in a register,
> > > cpu_context has been zeroed by copy_thread()) or some random stack
> > > value.
> > 
> > Really? If prev is NULL in context_switch(...), the scheduler will implode,
> > and I can't see where else switch_to is called from.
> > 
> > Which code path are you thinking of?
> 
> copy_thread() zeros cpu_context which is used by cpu_switch_to() to load
> the next saved registers. The switch_to() function sets prev to last as
> returned by __switch_to(), so this is valid but in __switch_to() we
> don't have a valid prev (nor next) after cpu_switch_to() for newly
> created threads.

Correction - newly created threads return to ret_from_fork rather than
__switch_to(), which means that we miss the first
contextidr_thread_switch() call for a new thread. I would vote for
Christopher's original patch moving the call before cpu_switch_to(). The
alternative is to define finish_arch_switch() and add the call there. If
you are primarily tracing user space, it doesn't really matter whether
the stack was switched or not when we set the contextidr. For kernel
tracking, it could be a problem as we have the next task with the old
stack. But the same could be said about the prev task with the new
stack.

-- 
Catalin


From Ian.Campbell at citrix.com  Mon Apr 15 07:48:33 2013
From: Ian.Campbell at citrix.com (Ian Campbell)
Date: Mon, 15 Apr 2013 12:48:33 +0100
Subject: [Xen-devel] [PATCH] arm64: remove PSR bit macros from uapi
In-Reply-To: <60a204007309b815b1ac115c817dc808@localhost>
References: <1365779399-16654-1-git-send-email-ian.campbell@citrix.com>
 <20130412151835.GK12363@mudshark.cambridge.arm.com>
 <1365781834.15783.107.camel@zakaz.uk.xensource.com>
 <1365782789.15783.113.camel@zakaz.uk.xensource.com>
 <60a204007309b815b1ac115c817dc808@localhost>
Message-ID: <1366026513.4963.106.camel@zakaz.uk.xensource.com>

On Fri, 2013-04-12 at 17:17 +0100, Marc Zyngier wrote:
> On Fri, 12 Apr 2013 17:06:29 +0100, Ian Campbell <Ian.Campbell at citrix.com>
> wrote:
> 
> [...]
> 
> > On the flip side is there any reason for the Linux uapi headers to be
> > including architectural constants? e.g. the x86 uapi/ptrace.h doesn't
> > define the RFLAGS bits etc...
> 
> My favourite userspace program (aka the other platform emulation that
> shall not ever be merged) needs it. QEMU probably will as well.
> 
> Of course, we could define them locally, but that seems like a massive
> waste of perfectly innocent bytes.

I appreciate it's convenient but I'm not sure there is a shortage of
bytes in the world, especially for well known unchanging constants like
this. Your favourite userspace program is a bit of a special case since
it doesn't need to be portable to non-Linux (or I assume not).

Anyway, ignoring the red-herring I introduced the main point isn't that
uapi/ptrace.h includes these definitions (that seems to be OK, standards
wise and is useful to you etc) but rather that they end up infecting
signal.h too. I'll file a bug against glibc/ubuntu/linaro as soon as I
figure out which is the best target...

>  or convince the power that be to merge
> the damned thing so we can include kernel headers with any remorse... ;-)

/me steps back several paces and puts away his barge pole. ;-)

Ian.



From nsekhar at ti.com  Mon Apr 15 07:48:59 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Mon, 15 Apr 2013 17:18:59 +0530
Subject: [PATCH v5 0/5] Patch enables support for m25p64 SPI flash support
 on da850-EVM.
In-Reply-To: <A73F36158E33644199EB82C5EC81C7BC3EA4C560@DBDE01.ent.ti.com>
References: <1364998150-5980-1-git-send-email-prakash.pm@ti.com>
 <A73F36158E33644199EB82C5EC81C7BC3EA4C560@DBDE01.ent.ti.com>
Message-ID: <516BE92B.90002@ti.com>

On 4/9/2013 11:14 AM, Manjunathappa, Prakash wrote:
> Hi Grant,
> 
> On Wed, Apr 03, 2013 at 19:39:05, Manjunathappa, Prakash wrote:
>> Testing information:
>> da850-evm comes with partitions specified in DT blob.
>> Able to mount/umount and create/delete files on filesystem partition.
>>
> 
> Could you please ack the driver(1/5) and documentation(2/5) changes so
> that Sekhar can merge the platform changes, he doesn't have any
> objection on this series.
> http://marc.info/?l=linux-doc&m=136489750130615&w=1

I am planning to queue these patches for ARM-SoC today. Grant has not
acked these but 1/5 just fixes the binding name to not use wild cards
and 2/5 just documents existing bindings and is something that should
have been merge last merge window itself (when the bindings were
accepted). So, the patches pending on Grant's ack seem very low risk to
me and we are much delayed already to wait further.

Thanks,
Sekhar


From nsekhar at ti.com  Mon Apr 15 07:50:35 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Mon, 15 Apr 2013 17:20:35 +0530
Subject: [PATCH 0/4] ARM: davinci: sparse warning fixes
In-Reply-To: <1365586035-26583-1-git-send-email-nsekhar@ti.com>
References: <1365586035-26583-1-git-send-email-nsekhar@ti.com>
Message-ID: <516BE98B.9080201@ti.com>

On 4/10/2013 2:57 PM, Sekhar Nori wrote:
> This patch series fixes some sparse errors/warnings
> occurring in arch/arm/mach-davinci/*
> 
> Tested on DA850 EVM (boot and suspend-to-RAM test).

Queuing these for v3.10.

Thanks,
Sekhar


From gregory.clement at free-electrons.com  Mon Apr 15 07:50:37 2013
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Mon, 15 Apr 2013 13:50:37 +0200
Subject: net: mvneta: fix improper tx queue usage in mvneta_tx()
In-Reply-To: <20130415063537.GA26507@1wt.eu>
References: <20130415063537.GA26507@1wt.eu>
Message-ID: <516BE98D.2040706@free-electrons.com>

Hi Willy

On 04/15/2013 08:35 AM, Willy Tarreau wrote:
> From 4f2069c92a27790e6071dc2a80f92c166e0b0ca4 Mon Sep 17 00:00:00 2001
> From: Willy Tarreau <w at 1wt.eu>
> Date: Thu, 11 Apr 2013 23:00:37 +0200
> Subject: net: mvneta: fix improper tx queue usage in mvneta_tx()
> 
> mvneta_tx() was using a static tx queue number causing crashes as
> soon as a little bit of traffic was sent via the interface, because
> it is normally expected that the same queue should be used as in
> dev_queue_xmit().
> 
> As suggested by Ben Hutchings, let's use skb_get_queue_mapping() to
> get the proper Tx queue number, and use alloc_etherdev_mqs() instead
> of alloc_etherdev_mq() to create the queues.
> 
> Both my Mirabox and my OpenBlocks AX3 used to crash without this patch
> and don't anymore with it. The issue appeared in 3.8 but became more
> visible after the fix allowing GSO to be enabled.
> 
> Original work was done by Dmitri Epshtein and Thomas Petazzoni. I
> just adapted it to take care of Ben's comments.

Thanks for this work. I have tested on a DB-MV784MP-GP board in SMP
with 4 CPUs. Without this patch a "iperf -P 4" lead to a kernel crash
in 80% of the case and to a hang in the remaining cases. Now after
a dozen of tests on this board, I didn't see any crash or hang.
You can add my
Tested-by: Gregory CLEMENT <gregory.clement at free-electrons.com>

Thanks,

> 
> Signed-off-by: Willy Tarreau <w at 1wt.eu>
> Cc: Dmitri Epshtein <dima at marvell.com>
> Cc: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> Cc: Gregory CLEMENT <gregory.clement at free-electrons.com>
> Cc: Ben Hutchings <bhutchings at solarflare.com>
> ---
>  drivers/net/ethernet/marvell/mvneta.c | 9 ++++-----
>  1 file changed, 4 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
> index 1e628ce..a47a097 100644
> --- a/drivers/net/ethernet/marvell/mvneta.c
> +++ b/drivers/net/ethernet/marvell/mvneta.c
> @@ -374,7 +374,6 @@ static int rxq_number = 8;
>  static int txq_number = 8;
>  
>  static int rxq_def;
> -static int txq_def;
>  
>  #define MVNETA_DRIVER_NAME "mvneta"
>  #define MVNETA_DRIVER_VERSION "1.0"
> @@ -1475,7 +1474,8 @@ error:
>  static int mvneta_tx(struct sk_buff *skb, struct net_device *dev)
>  {
>  	struct mvneta_port *pp = netdev_priv(dev);
> -	struct mvneta_tx_queue *txq = &pp->txqs[txq_def];
> +	u16 txq_id = skb_get_queue_mapping(skb);
> +	struct mvneta_tx_queue *txq = &pp->txqs[txq_id];
>  	struct mvneta_tx_desc *tx_desc;
>  	struct netdev_queue *nq;
>  	int frags = 0;
> @@ -1485,7 +1485,7 @@ static int mvneta_tx(struct sk_buff *skb, struct net_device *dev)
>  		goto out;
>  
>  	frags = skb_shinfo(skb)->nr_frags + 1;
> -	nq    = netdev_get_tx_queue(dev, txq_def);
> +	nq    = netdev_get_tx_queue(dev, txq_id);
>  
>  	/* Get a descriptor for the first part of the packet */
>  	tx_desc = mvneta_txq_next_desc_get(txq);
> @@ -2689,7 +2689,7 @@ static int mvneta_probe(struct platform_device *pdev)
>  		return -EINVAL;
>  	}
>  
> -	dev = alloc_etherdev_mq(sizeof(struct mvneta_port), 8);
> +	dev = alloc_etherdev_mqs(sizeof(struct mvneta_port), txq_number, rxq_number);
>  	if (!dev)
>  		return -ENOMEM;
>  
> @@ -2844,4 +2844,3 @@ module_param(rxq_number, int, S_IRUGO);
>  module_param(txq_number, int, S_IRUGO);
>  
>  module_param(rxq_def, int, S_IRUGO);
> -module_param(txq_def, int, S_IRUGO);
> 


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From lee.jones at linaro.org  Mon Apr 15 07:59:06 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Mon, 15 Apr 2013 12:59:06 +0100
Subject: [PATCH 3/8] dmaengine: ste_dma40: Actually write the runtime
 configuration to registers
In-Reply-To: <CAH+eYFB2+oMPXsnzQVVrEK8CjKGVYFa_n4Wxr=CpdtJwFfOGYw@mail.gmail.com>
References: <1365532783-27425-1-git-send-email-lee.jones@linaro.org>
 <1365532783-27425-3-git-send-email-lee.jones@linaro.org>
 <CAH+eYFB_fYmCjvh5PXKRhd-FnaWfeu+LtH+q3VywhCk-PYhHVQ@mail.gmail.com>
 <20130415110601.GE6512@gmail.com>
 <CAH+eYFB2+oMPXsnzQVVrEK8CjKGVYFa_n4Wxr=CpdtJwFfOGYw@mail.gmail.com>
Message-ID: <20130415115906.GF6512@gmail.com>

On Mon, 15 Apr 2013, Rabin Vincent wrote:

> 2013/4/15 Lee Jones <lee.jones at linaro.org>:
> > On Fri, 12 Apr 2013, Rabin Vincent wrote:
> >> 2013/4/9 Lee Jones <lee.jones at linaro.org>:
> >> > Someone has spent a fair amount of effort writing a runtime configuration
> >> > changing algorithm for DMA clients. However, the config appears to never
> >> > actually make it to hardware. In order for the configuration to take hold
> >> > we need to issue a d40_config_write(), as this is the routine which writes
> >> > it into the hardware's registers.
> >>
> >> No, it's not.  This function is only for initial configuration which
> >> should only be written when the channel is allocated.  In fact, by
> >> calling it here in runtime_config, you are introducing a serious bug:
> >> other logical channels on the same physical channel will stop because of
> >> the SSLNK/SDLNK of the physical channel being zeroed.
> >>
> >> The runtime config already makes it the hardware in the existing code,
> >> via d40_*_cfg().
> >
> > Sorry Rabin, but the only place I can see the config being written is
> > in d40_config_write().
> >
> > Can you paste the line of code in d40_*_cfg() which actually writes
> > the config to hardware please? I don't see it.
> 
> It's not that simple.  There are some pointers passed to d40_*_cfg() and
> that function writes the configuration to the variables those pointers
> point to (d40c->log_def.lcsp1, d40c->src_def_cfg, etc.).  Please read
> the code to see how those variables end up being used later when the
> LLIs are prepared for the HW.

I have read the code, which is why I know that the config only gets
written in d40_config_write(). :)

So the configuration which gets set in the runtime_config routine
doesn't ever make it to hardware - hence this patch.

Unless I'm missing something?

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From w at 1wt.eu  Mon Apr 15 08:05:48 2013
From: w at 1wt.eu (Willy Tarreau)
Date: Mon, 15 Apr 2013 14:05:48 +0200
Subject: net: mvneta: fix improper tx queue usage in mvneta_tx()
In-Reply-To: <516BE98D.2040706@free-electrons.com>
References: <20130415063537.GA26507@1wt.eu>
 <516BE98D.2040706@free-electrons.com>
Message-ID: <20130415120548.GD27217@1wt.eu>

On Mon, Apr 15, 2013 at 01:50:37PM +0200, Gregory CLEMENT wrote:
> Hi Willy
> 
> On 04/15/2013 08:35 AM, Willy Tarreau wrote:
> > From 4f2069c92a27790e6071dc2a80f92c166e0b0ca4 Mon Sep 17 00:00:00 2001
> > From: Willy Tarreau <w at 1wt.eu>
> > Date: Thu, 11 Apr 2013 23:00:37 +0200
> > Subject: net: mvneta: fix improper tx queue usage in mvneta_tx()
> > 
> > mvneta_tx() was using a static tx queue number causing crashes as
> > soon as a little bit of traffic was sent via the interface, because
> > it is normally expected that the same queue should be used as in
> > dev_queue_xmit().
> > 
> > As suggested by Ben Hutchings, let's use skb_get_queue_mapping() to
> > get the proper Tx queue number, and use alloc_etherdev_mqs() instead
> > of alloc_etherdev_mq() to create the queues.
> > 
> > Both my Mirabox and my OpenBlocks AX3 used to crash without this patch
> > and don't anymore with it. The issue appeared in 3.8 but became more
> > visible after the fix allowing GSO to be enabled.
> > 
> > Original work was done by Dmitri Epshtein and Thomas Petazzoni. I
> > just adapted it to take care of Ben's comments.
> 
> Thanks for this work. I have tested on a DB-MV784MP-GP board in SMP
> with 4 CPUs. Without this patch a "iperf -P 4" lead to a kernel crash
> in 80% of the case and to a hang in the remaining cases. Now after
> a dozen of tests on this board, I didn't see any crash or hang.
> You can add my
> Tested-by: Gregory CLEMENT <gregory.clement at free-electrons.com>

Thanks for testing Gregory !

Willy



From robherring2 at gmail.com  Mon Apr 15 08:15:22 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Mon, 15 Apr 2013 07:15:22 -0500
Subject: [GIT PULL] msm core for 3.10
In-Reply-To: <20130415034905.GC10949@quad.lixom.net>
References: <8ya7gk7qsnp.fsf@huya.qualcomm.com>
 <8yazjx3pdz0.fsf@huya.qualcomm.com> <20130415034905.GC10949@quad.lixom.net>
Message-ID: <516BEF5A.7000101@gmail.com>

On 04/14/2013 10:49 PM, Olof Johansson wrote:
> Hi,
> 
> On Fri, Apr 12, 2013 at 03:43:15PM -0700, David Brown wrote:
>> The following changes since commit f6161aa153581da4a3867a2d1a7caf4be19b6ec9:
>>
>>   Linux 3.9-rc2 (2013-03-10 16:54:19 -0700)
>>
>> are available in the git repository at:
>>
>>   git://git.kernel.org/pub/scm/linux/kernel/git/davidb/linux-msm.git tags/msm-core-3.10

>>  .../devicetree/bindings/arm/msm/timer.txt          |  41 ++++----
>>  arch/arm/boot/dts/msm8660-surf.dts                 |  20 ++--
>>  arch/arm/boot/dts/msm8960-cdp.dts                  |  22 ++---
>>  arch/arm/mach-msm/timer.c                          | 110 ++++++++++-----------
>>  4 files changed, 86 insertions(+), 107 deletions(-)
> 
> I didn't see either of the device tree maintainers cc:d on the bindings
> update, nor an ack from them. It looks reasonable enough to me, but I
> also do know that in your private downstream tree you have a lot of new
> bindings. Please make sure these go through proper review channels as
> you start to upstream them; i.e. Grant Likely and Rob Herring should
> either merge or ack them.
> 
> I've cc:d Rob and Grant on this reply and I'll merge it for now but to avoid
> delays in getting your code merged in the future please make sure they are in
> the loop from the beginning.

Other than breaking the DTB-kernel ABI, looks fine to me. It's a
platform decision whether they are okay with that or not.

Rob




From ludovic.desroches at atmel.com  Mon Apr 15 08:16:54 2013
From: ludovic.desroches at atmel.com (ludovic.desroches at atmel.com)
Date: Mon, 15 Apr 2013 14:16:54 +0200
Subject: [PATCH 0/3] ARM: at91: move to generic DMA device tree bindings
Message-ID: <1366028217-5037-1-git-send-email-ludovic.desroches@atmel.com>

From: Ludovic Desroches <ludovic.desroches at atmel.com>

Hi,

This set of patches introduces DMA device tree bindings support for the atmel
DMA controller and first driver conversions.

I'll send an update of dts file in the next version if there is no major issue
with the bindings.

Regards


Ludovic Desroches (3):
  at_hdmac: move to generic DMA binding
  i2c: at91: convert to dma_request_slave_channel_compat()
  mci: at91: convert to dma_request_slave_channel_compat()

 .../devicetree/bindings/dma/atmel-dma.txt          | 26 +++++-
 arch/arm/boot/dts/sama5d3.dtsi                     |  4 +-
 drivers/dma/at_hdmac.c                             | 93 ++++++++++++++++++++--
 drivers/dma/at_hdmac_regs.h                        |  4 +
 drivers/i2c/busses/i2c-at91.c                      | 49 ++++++------
 drivers/mmc/host/atmel-mci.c                       | 25 +++---
 6 files changed, 154 insertions(+), 47 deletions(-)

-- 
1.7.11.3



From ludovic.desroches at atmel.com  Mon Apr 15 08:16:55 2013
From: ludovic.desroches at atmel.com (ludovic.desroches at atmel.com)
Date: Mon, 15 Apr 2013 14:16:55 +0200
Subject: [PATCH 1/3] at_hdmac: move to generic DMA binding
In-Reply-To: <1366028217-5037-1-git-send-email-ludovic.desroches@atmel.com>
References: <1366028217-5037-1-git-send-email-ludovic.desroches@atmel.com>
Message-ID: <1366028217-5037-2-git-send-email-ludovic.desroches@atmel.com>

From: Ludovic Desroches <ludovic.desroches at atmel.com>

Update at_hdmac driver to support generic DMA device tree binding. Devices
can still request channel with dma_request_channel() then it doesn't break
DMA for non DT boards.

Signed-off-by: Ludovic Desroches <ludovic.desroches at atmel.com>
---
 .../devicetree/bindings/dma/atmel-dma.txt          | 26 +++++-
 arch/arm/boot/dts/sama5d3.dtsi                     |  4 +-
 drivers/dma/at_hdmac.c                             | 93 ++++++++++++++++++++--
 drivers/dma/at_hdmac_regs.h                        |  4 +
 4 files changed, 117 insertions(+), 10 deletions(-)

diff --git a/Documentation/devicetree/bindings/dma/atmel-dma.txt b/Documentation/devicetree/bindings/dma/atmel-dma.txt
index 3c046ee..4179bd2 100644
--- a/Documentation/devicetree/bindings/dma/atmel-dma.txt
+++ b/Documentation/devicetree/bindings/dma/atmel-dma.txt
@@ -4,11 +4,33 @@ Required properties:
 - compatible: Should be "atmel,<chip>-dma"
 - reg: Should contain DMA registers location and length
 - interrupts: Should contain DMA interrupt
+- #dma-cells: Must be <2>
 
-Examples:
+Example:
 
-dma at ffffec00 {
+dma0: dma at ffffec00 {
 	compatible = "atmel,at91sam9g45-dma";
 	reg = <0xffffec00 0x200>;
 	interrupts = <21>;
+	#dma-cells = <2>;
+};
+
+DMA clients connected to the Atmel DMA controller must use the format
+described in the dma.txt file, using a three-cell specifier for each channel.
+The three cells in order are:
+
+1. A phandle pointing to the DMA controller
+2. The memory interface (16 most significant bits), the peripheral interface
+(16 less significant bits)
+3. The peripheral identifier (can be different for tx and rx)
+
+Example:
+
+i2c0 at i2c@f8010000 {
+	compatible = "atmel,at91sam9x5-i2c";
+	reg = <0xf8010000 0x100>;
+	interrupts = <9 4 6>;
+	dmas = <&dma0 1 7>,
+	       <&dma0 1 8>;
+	dma-names = "tx", "rx"
 };
diff --git a/arch/arm/boot/dts/sama5d3.dtsi b/arch/arm/boot/dts/sama5d3.dtsi
index 39b0458..95c00a3 100644
--- a/arch/arm/boot/dts/sama5d3.dtsi
+++ b/arch/arm/boot/dts/sama5d3.dtsi
@@ -348,14 +348,14 @@
 				compatible = "atmel,at91sam9g45-dma";
 				reg = <0xffffe600 0x200>;
 				interrupts = <30 4 0>;
-				#dma-cells = <1>;
+				#dma-cells = <2>;
 			};
 
 			dma1: dma-controller at ffffe800 {
 				compatible = "atmel,at91sam9g45-dma";
 				reg = <0xffffe800 0x200>;
 				interrupts = <31 4 0>;
-				#dma-cells = <1>;
+				#dma-cells = <2>;
 			};
 
 			ramc0: ramc at ffffea00 {
diff --git a/drivers/dma/at_hdmac.c b/drivers/dma/at_hdmac.c
index 8415467..d5f7a1b 100644
--- a/drivers/dma/at_hdmac.c
+++ b/drivers/dma/at_hdmac.c
@@ -24,6 +24,7 @@
 #include <linux/slab.h>
 #include <linux/of.h>
 #include <linux/of_device.h>
+#include <linux/of_dma.h>
 
 #include "at_hdmac_regs.h"
 #include "dmaengine.h"
@@ -676,7 +677,7 @@ atc_prep_slave_sg(struct dma_chan *chan, struct scatterlist *sgl,
 		ctrlb |=  ATC_DST_ADDR_MODE_FIXED
 			| ATC_SRC_ADDR_MODE_INCR
 			| ATC_FC_MEM2PER
-			| ATC_SIF(AT_DMA_MEM_IF) | ATC_DIF(AT_DMA_PER_IF);
+			| ATC_SIF(atchan->mem_if) | ATC_DIF(atchan->per_if);
 		reg = sconfig->dst_addr;
 		for_each_sg(sgl, sg, sg_len, i) {
 			struct at_desc	*desc;
@@ -715,7 +716,7 @@ atc_prep_slave_sg(struct dma_chan *chan, struct scatterlist *sgl,
 		ctrlb |=  ATC_DST_ADDR_MODE_INCR
 			| ATC_SRC_ADDR_MODE_FIXED
 			| ATC_FC_PER2MEM
-			| ATC_SIF(AT_DMA_PER_IF) | ATC_DIF(AT_DMA_MEM_IF);
+			| ATC_SIF(atchan->per_if) | ATC_DIF(atchan->mem_if);
 
 		reg = sconfig->src_addr;
 		for_each_sg(sgl, sg, sg_len, i) {
@@ -821,8 +822,8 @@ atc_dma_cyclic_fill_desc(struct dma_chan *chan, struct at_desc *desc,
 		desc->lli.ctrlb = ATC_DST_ADDR_MODE_FIXED
 				| ATC_SRC_ADDR_MODE_INCR
 				| ATC_FC_MEM2PER
-				| ATC_SIF(AT_DMA_MEM_IF)
-				| ATC_DIF(AT_DMA_PER_IF);
+				| ATC_SIF(atchan->mem_if)
+				| ATC_DIF(atchan->per_if);
 		break;
 
 	case DMA_DEV_TO_MEM:
@@ -832,8 +833,8 @@ atc_dma_cyclic_fill_desc(struct dma_chan *chan, struct at_desc *desc,
 		desc->lli.ctrlb = ATC_DST_ADDR_MODE_INCR
 				| ATC_SRC_ADDR_MODE_FIXED
 				| ATC_FC_PER2MEM
-				| ATC_SIF(AT_DMA_PER_IF)
-				| ATC_DIF(AT_DMA_MEM_IF);
+				| ATC_SIF(atchan->per_if)
+				| ATC_DIF(atchan->mem_if);
 		break;
 
 	default:
@@ -1189,6 +1190,67 @@ static void atc_free_chan_resources(struct dma_chan *chan)
 	dev_vdbg(chan2dev(chan), "free_chan_resources: done\n");
 }
 
+static bool at_dma_filter(struct dma_chan *chan, void *slave)
+{
+	struct at_dma_slave *atslave = slave;
+
+	if (atslave->dma_dev == chan->device->dev) {
+		chan->private = atslave;
+		return true;
+	} else {
+		return false;
+	}
+}
+
+#ifdef CONFIG_OF
+static struct dma_chan *at_dma_xlate(struct of_phandle_args *dma_spec,
+				     struct of_dma *of_dma)
+{
+	struct dma_chan *chan;
+	struct at_dma_chan *atchan;
+	struct at_dma_slave *atslave;
+	dma_cap_mask_t mask;
+	unsigned int per_id;
+	struct platform_device *dmac_pdev;
+
+	if (dma_spec->args_count != 2)
+		return NULL;
+
+	dmac_pdev = of_find_device_by_node(dma_spec->np);
+
+	dma_cap_zero(mask);
+	dma_cap_set(DMA_SLAVE, mask);
+
+	atslave = devm_kzalloc(&dmac_pdev->dev, sizeof(*atslave), GFP_KERNEL);
+	if (!atslave)
+		return NULL;
+	/*
+	 * We can fill both SRC_PER and DST_PER, one of these fields will be
+	 * ignored depending on DMA transfer direction.
+	 */
+	per_id = dma_spec->args[1];
+	atslave->cfg = ATC_FIFOCFG_HALFFIFO | ATC_DST_H2SEL_HW
+		      | ATC_SRC_H2SEL_HW | ATC_DST_PER(per_id)
+		      | ATC_SRC_PER(per_id);
+	atslave->dma_dev = &dmac_pdev->dev;
+
+	chan = dma_request_channel(mask, at_dma_filter, atslave);
+	if (!chan)
+		return NULL;
+
+	atchan = to_at_dma_chan(chan);
+	atchan->per_if = dma_spec->args[0] & 0xff;
+	atchan->mem_if = (dma_spec->args[0] >> 16) & 0xff;
+
+	return chan;
+}
+#else
+static struct dma_chan *at_dma_xlate(struct of_phandle_args *dma_spec,
+				     struct of_dma *of_dma)
+{
+	return NULL;
+}
+#endif
 
 /*--  Module Management  -----------------------------------------------*/
 
@@ -1343,6 +1405,8 @@ static int __init at_dma_probe(struct platform_device *pdev)
 	for (i = 0; i < plat_dat->nr_channels; i++) {
 		struct at_dma_chan	*atchan = &atdma->chan[i];
 
+		atchan->mem_if = AT_DMA_MEM_IF;
+		atchan->per_if = AT_DMA_PER_IF;
 		atchan->chan_common.device = &atdma->dma_common;
 		dma_cookie_init(&atchan->chan_common);
 		list_add_tail(&atchan->chan_common.device_node,
@@ -1389,8 +1453,25 @@ static int __init at_dma_probe(struct platform_device *pdev)
 
 	dma_async_device_register(&atdma->dma_common);
 
+	/*
+	 * Do not return an error if the dmac node is not present in order to
+	 * not break the existing way of requesting channel with
+	 * dma_request_channel().
+	 */
+	if (pdev->dev.of_node) {
+		err = of_dma_controller_register(pdev->dev.of_node,
+						 at_dma_xlate, atdma);
+		if (err) {
+			dev_err(&pdev->dev, "could not register of_dma_controller\n");
+			goto err_of_dma_controller_register;
+		}
+	}
+
 	return 0;
 
+err_of_dma_controller_register:
+	dma_async_device_unregister(&atdma->dma_common);
+	dma_pool_destroy(atdma->dma_desc_pool);
 err_pool_create:
 	platform_set_drvdata(pdev, NULL);
 	free_irq(platform_get_irq(pdev, 0), atdma);
diff --git a/drivers/dma/at_hdmac_regs.h b/drivers/dma/at_hdmac_regs.h
index 0eb3c13..c604d26 100644
--- a/drivers/dma/at_hdmac_regs.h
+++ b/drivers/dma/at_hdmac_regs.h
@@ -220,6 +220,8 @@ enum atc_status {
  * @device: parent device
  * @ch_regs: memory mapped register base
  * @mask: channel index in a mask
+ * @per_if: peripheral interface
+ * @mem_if: memory interface
  * @status: transmit status information from irq/prep* functions
  *                to tasklet (use atomic operations)
  * @tasklet: bottom half to finish transaction work
@@ -238,6 +240,8 @@ struct at_dma_chan {
 	struct at_dma		*device;
 	void __iomem		*ch_regs;
 	u8			mask;
+	u8			per_if;
+	u8			mem_if;
 	unsigned long		status;
 	struct tasklet_struct	tasklet;
 	u32			save_cfg;
-- 
1.7.11.3



From ludovic.desroches at atmel.com  Mon Apr 15 08:16:56 2013
From: ludovic.desroches at atmel.com (ludovic.desroches at atmel.com)
Date: Mon, 15 Apr 2013 14:16:56 +0200
Subject: [PATCH 2/3] i2c: at91: convert to dma_request_slave_channel_compat()
In-Reply-To: <1366028217-5037-1-git-send-email-ludovic.desroches@atmel.com>
References: <1366028217-5037-1-git-send-email-ludovic.desroches@atmel.com>
Message-ID: <1366028217-5037-3-git-send-email-ludovic.desroches@atmel.com>

From: Ludovic Desroches <ludovic.desroches at atmel.com>

Use generic DMA DT helper. Platforms booting with or without DT populated are
both supported.

Signed-off-by: Ludovic Desroches <ludovic.desroches at atmel.com>
---
 drivers/i2c/busses/i2c-at91.c | 49 ++++++++++++++++++++++---------------------
 1 file changed, 25 insertions(+), 24 deletions(-)

diff --git a/drivers/i2c/busses/i2c-at91.c b/drivers/i2c/busses/i2c-at91.c
index 75195e3..7ffd544 100644
--- a/drivers/i2c/busses/i2c-at91.c
+++ b/drivers/i2c/busses/i2c-at91.c
@@ -607,11 +607,16 @@ MODULE_DEVICE_TABLE(of, atmel_twi_dt_ids);
 #define atmel_twi_dt_ids NULL
 #endif
 
-static bool filter(struct dma_chan *chan, void *slave)
+static bool filter(struct dma_chan *chan, void *pdata)
 {
-	struct at_dma_slave *sl = slave;
+	struct at91_twi_pdata *sl_pdata = pdata;
+	struct at_dma_slave *sl;
 
-	if (sl->dma_dev == chan->device->dev) {
+	if (!sl_pdata)
+		return false;
+
+	sl = &sl_pdata->dma_slave;
+	if (sl && (sl->dma_dev == chan->device->dev)) {
 		chan->private = sl;
 		return true;
 	} else {
@@ -622,11 +627,10 @@ static bool filter(struct dma_chan *chan, void *slave)
 static int at91_twi_configure_dma(struct at91_twi_dev *dev, u32 phy_addr)
 {
 	int ret = 0;
-	struct at_dma_slave *sdata;
+	struct at91_twi_pdata *pdata = dev->pdata;
 	struct dma_slave_config slave_config;
 	struct at91_twi_dma *dma = &dev->dma;
-
-	sdata = &dev->pdata->dma_slave;
+	dma_cap_mask_t mask;
 
 	memset(&slave_config, 0, sizeof(slave_config));
 	slave_config.src_addr = (dma_addr_t)phy_addr + AT91_TWI_RHR;
@@ -637,25 +641,22 @@ static int at91_twi_configure_dma(struct at91_twi_dev *dev, u32 phy_addr)
 	slave_config.dst_maxburst = 1;
 	slave_config.device_fc = false;
 
-	if (sdata && sdata->dma_dev) {
-		dma_cap_mask_t mask;
+	dma_cap_zero(mask);
+	dma_cap_set(DMA_SLAVE, mask);
 
-		dma_cap_zero(mask);
-		dma_cap_set(DMA_SLAVE, mask);
-		dma->chan_tx = dma_request_channel(mask, filter, sdata);
-		if (!dma->chan_tx) {
-			dev_err(dev->dev, "no DMA channel available for tx\n");
-			ret = -EBUSY;
-			goto error;
-		}
-		dma->chan_rx = dma_request_channel(mask, filter, sdata);
-		if (!dma->chan_rx) {
-			dev_err(dev->dev, "no DMA channel available for rx\n");
-			ret = -EBUSY;
-			goto error;
-		}
-	} else {
-		ret = -EINVAL;
+	dma->chan_tx = dma_request_slave_channel_compat(mask, filter, pdata,
+							dev->dev, "tx");
+	if (!dma->chan_tx) {
+		dev_err(dev->dev, "can't get a DMA channel for tx\n");
+		ret = -EBUSY;
+		goto error;
+	}
+
+	dma->chan_rx = dma_request_slave_channel_compat(mask, filter, pdata,
+							dev->dev, "rx");
+	if (!dma->chan_rx) {
+		dev_err(dev->dev, "can't get a DMA channel for rx\n");
+		ret = -EBUSY;
 		goto error;
 	}
 
-- 
1.7.11.3



From ludovic.desroches at atmel.com  Mon Apr 15 08:16:57 2013
From: ludovic.desroches at atmel.com (ludovic.desroches at atmel.com)
Date: Mon, 15 Apr 2013 14:16:57 +0200
Subject: [PATCH 3/3] mci: at91: convert to dma_request_slave_channel_compat()
In-Reply-To: <1366028217-5037-1-git-send-email-ludovic.desroches@atmel.com>
References: <1366028217-5037-1-git-send-email-ludovic.desroches@atmel.com>
Message-ID: <1366028217-5037-4-git-send-email-ludovic.desroches@atmel.com>

From: Ludovic Desroches <ludovic.desroches at atmel.com>

Use generic DMA DT helper. Platforms booting with or without DT populated are
both supported.

Signed-off-by: Ludovic Desroches <ludovic.desroches at atmel.com>
---
 drivers/mmc/host/atmel-mci.c | 25 ++++++++++++-------------
 1 file changed, 12 insertions(+), 13 deletions(-)

diff --git a/drivers/mmc/host/atmel-mci.c b/drivers/mmc/host/atmel-mci.c
index 10f8b73..73d5d24 100644
--- a/drivers/mmc/host/atmel-mci.c
+++ b/drivers/mmc/host/atmel-mci.c
@@ -2224,10 +2224,15 @@ static void __exit atmci_cleanup_slot(struct atmel_mci_slot *slot,
 	mmc_free_host(slot->mmc);
 }
 
-static bool atmci_filter(struct dma_chan *chan, void *slave)
+static bool atmci_filter(struct dma_chan *chan, void *pdata)
 {
-	struct mci_dma_data	*sl = slave;
+	struct mci_platform_data *sl_pdata = pdata;
+	struct mci_dma_data *sl;
 
+	if (!sl_pdata)
+		return false;
+
+	sl = sl_pdata->dma_slave;
 	if (sl && find_slave_dev(sl) == chan->device->dev) {
 		chan->private = slave_data_ptr(sl);
 		return true;
@@ -2239,24 +2244,18 @@ static bool atmci_filter(struct dma_chan *chan, void *slave)
 static bool atmci_configure_dma(struct atmel_mci *host)
 {
 	struct mci_platform_data	*pdata;
+	dma_cap_mask_t mask;
 
 	if (host == NULL)
 		return false;
 
 	pdata = host->pdev->dev.platform_data;
 
-	if (!pdata)
-		return false;
+	dma_cap_zero(mask);
+	dma_cap_set(DMA_SLAVE, mask);
 
-	if (pdata->dma_slave && find_slave_dev(pdata->dma_slave)) {
-		dma_cap_mask_t mask;
-
-		/* Try to grab a DMA channel */
-		dma_cap_zero(mask);
-		dma_cap_set(DMA_SLAVE, mask);
-		host->dma.chan =
-			dma_request_channel(mask, atmci_filter, pdata->dma_slave);
-	}
+	host->dma.chan = dma_request_slave_channel_compat(mask, atmci_filter, pdata,
+						   	  &host->pdev->dev, "rxtx");
 	if (!host->dma.chan) {
 		dev_warn(&host->pdev->dev, "no DMA channel available\n");
 		return false;
-- 
1.7.11.3



From arnd at arndb.de  Mon Apr 15 08:20:35 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 15 Apr 2013 14:20:35 +0200
Subject: [PATCH 3/7] ARM: exynos: add missing properties for combiner IRQs
In-Reply-To: <CAK9yfHwXYRqo2yG1moWvMnEmNWXCVL7a9eKzi2we=QmdpVsz-w@mail.gmail.com>
References: <1365775405-115297-1-git-send-email-arnd@arndb.de>
 <201304151041.44805.arnd@arndb.de>
 <CAK9yfHwXYRqo2yG1moWvMnEmNWXCVL7a9eKzi2we=QmdpVsz-w@mail.gmail.com>
Message-ID: <201304151420.35843.arnd@arndb.de>

On Monday 15 April 2013, Sachin Kamat wrote:
> >> > diff --git a/arch/arm/boot/dts/exynos4212.dtsi b/arch/arm/boot/dts/exynos4212.dtsi
> >> > index 36d4299..f83c3c1 100644
> >> > --- a/arch/arm/boot/dts/exynos4212.dtsi
> >> > +++ b/arch/arm/boot/dts/exynos4212.dtsi
> >> > @@ -26,6 +26,15 @@
> >> >                 cpu-offset = <0x8000>;
> >> >         };
> >> >
> >> > +       interrupt-controller at 10440000 {
> >>
> >> Don't we need a node name here (combiner:interrupt-controller at 10440000)?
> >
> > Why?
> 
> Since it is being referenced as "&combiner" by other bindings, i
> thought that was required.

The original definition actually comes from exynos4.dtsi. It's enough
to have the label in one place.

> >> We have a combiner node defined in exynos4x12.dtsi. With the bindings
> >> now defined separately in 4212 and 4412 dtsi files, probably the one
> >> in 4x12 could be dropped?
> >
> > I did not see that one, but it seems to have the wrong numbers in the last
> > four interrupt specifiers. I think it would be better to just fix that one
> > and keep using it.
> 
> OK. Do you want me to fix it and send as a patch or would you like to do it?

If you have a patch that works, you could just send it out, oetherwise I'd
do it.

	ARnd


From grant.likely at secretlab.ca  Mon Apr 15 08:26:34 2013
From: grant.likely at secretlab.ca (Grant Likely)
Date: Mon, 15 Apr 2013 13:26:34 +0100
Subject: [PATCH v3 0/6] Generic PHY Framework
In-Reply-To: <516BD835.8060007@ti.com>
References: <1363770725-13717-1-git-send-email-kishon@ti.com>
 <20130415102009.D358E3E0AA8@localhost> <516BD835.8060007@ti.com>
Message-ID: <20130415122634.3A08A3E0AA8@localhost>

On Mon, 15 Apr 2013 16:06:37 +0530, Kishon Vijay Abraham I <kishon at ti.com> wrote:
> Hi,
> 
> On Monday 15 April 2013 03:50 PM, Grant Likely wrote:
> > On Wed, 20 Mar 2013 14:41:59 +0530, Kishon Vijay Abraham I <kishon at ti.com> wrote:
> >> Added a generic PHY framework that provides a set of APIs for the PHY drivers
> >> to create/destroy a PHY and APIs for the PHY users to obtain a reference to
> >> the PHY with or without using phandle. To obtain a reference to the PHY
> >> without using phandle, the platform specfic intialization code (say from board
> >> file) should have already called phy_bind with the binding information. The
> >> binding information consists of phy's device name, phy user device name and an
> >> index. The index is used when the same phy user binds to mulitple phys.
> >>
> >> This framework will be of use only to devices that uses external PHY (PHY
> >> functionality is not embedded within the controller).
> >>
> >> The intention of creating this framework is to bring the phy drivers spread
> >> all over the Linux kernel to drivers/phy to increase code re-use and to
> >> increase code maintainability.
> >>
> >> Comments to make PHY as bus wasn't done because PHY devices can be part of
> >> other bus and making a same device attached to multiple bus leads to bad
> >> design.
> >>
> >> Making omap-usb2 and twl4030 to use this framework is provided as a sample.
> >>
> >> This patch series is developed on 3.9-rc3. Once the patch series gets finalised
> >> I'll resend omap-usb2 and twl4030 part based on Felipe's tree.
> >>
> >
> > [...]
> >
> >>   drivers/Kconfig                                    |    2 +
> >>   drivers/Makefile                                   |    2 +
> >>   drivers/phy/Kconfig                                |   13 +
> >>   drivers/phy/Makefile                               |    5 +
> >>   drivers/phy/phy-core.c                             |  574 ++++++++++++++++++++
> >
> > This looks to be very specific for USB PHYs. Are you intending it to be
> > used for other types of PHYs, like Ethernet PHYs? If not, then this
> 
> Not really. This can be used by USB, SATA and Sylwester was planning to 
> use it for video PHY's.

So what are the common bits that are shared between those phys? Merely
matching phys to controllers? Besides that, each of those devices have
very different behaviour. You wouldn't be able to attach any interface
logic to the generic struct phy. I don't think it makes a whole lot of
sense to lump them all into the same type of registration.

g.


From kishon at ti.com  Mon Apr 15 08:26:10 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Mon, 15 Apr 2013 17:56:10 +0530
Subject: [PATCH v3 1/6] drivers: phy: add generic PHY framework
In-Reply-To: <20130415113416.7C3943E0AA8@localhost>
References: <1363770725-13717-1-git-send-email-kishon@ti.com>
 <1363770725-13717-2-git-send-email-kishon@ti.com>
 <20130415113416.7C3943E0AA8@localhost>
Message-ID: <516BF1E2.3020104@ti.com>

Hi,

On Monday 15 April 2013 05:04 PM, Grant Likely wrote:
> On Wed, 20 Mar 2013 14:42:00 +0530, Kishon Vijay Abraham I <kishon at ti.com> wrote:
>> The PHY framework provides a set of APIs for the PHY drivers to
>> create/destroy a PHY and APIs for the PHY users to obtain a reference to the
>> PHY with or without using phandle. To obtain a reference to the PHY without
>> using phandle, the platform specfic intialization code (say from board file)
>> should have already called phy_bind with the binding information. The binding
>> information consists of phy's device name, phy user device name and an index.
>> The index is used when the same phy user binds to mulitple phys.
>>
>> PHY drivers should create the PHY by passing phy_descriptor that has
>> describes the PHY (label, type etc..) and ops like init, exit, suspend, resume,
>> poweron, shutdown.
>>
>> The documentation for the generic PHY framework is added in
>> Documentation/phy.txt and the documentation for the sysfs entry is added
>> in Documentation/ABI/testing/sysfs-class-phy.
>>
>> Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
>
> Hi Kishon,
>
> For review purposes, I'll skip most of the implementation and focus on
> the data structures. I think you need to take another look at the
> approach your using. The kernel already provides a lot of support for
> implementing devices and binding them to drivers that you should be
> able to use...
>
>
> [...]
>> +/**
>> + * struct phy - represent the phy device
>> + * @dev: phy device
>> + * @label: label given to phy
>> + * @type: specifies the phy type
>> + * @of_node: device node of the phy
>> + * @ops: function pointers for performing phy operations
>> + */
>> +struct phy {
>> +	struct device		dev;
>> +	const char		*label;
>> +	int			type;
>> +	struct bus_type		*bus;
>> +	struct device_node	*of_node;
>> +	struct phy_ops		*ops;
>> +};
>
> Alright, so the core of the functionality is this 'struct phy' which
> tracks all the instances of PHY devices. As I understand it each
> physical phy will have a 'struct phy' instance tracking it. That makes
> sense.
>
> struct phy embeds a struct device. Also good. The linux driver model
> knows all about devices and how to handle them. However, most of the
> rest of this structure looks to be reinventing stuff the driver model
> already does.
>
> 'label' seems unnecessary. struct device embeds a struct kobject, which
> means it has a name and shows up in sysfs. Is there a reason that the
> device name cannot be used directly?

hmm.. the label name is supposed to be a simpler name than device name.
Say for instance "omap-usb2.1.auto" device name can simply be 
"omap-usb2-phy". Further the device name while using dt will have 
register address in it. However it's used only for displaying the label 
in sysfs entry (/sys/class/phy/<phy>/label).
>
> 'type' I just don't understand. I don't see any users of it in this
> patch. I only see where it is set.

yeah. Was planning to remove this in my next version (btw the latest is 
version 5).
>
> 'bus' absolutely should not be here. The bus type should be set in the
> struct device by this subsystem when the device gets registered. There
> is no reason to have a pointer to it here.

right. I had removed it in version 5 of this patch series.
>
> 'of_node' is already in struct device

I wasn't sure if we can manually assign the of_node of one device to 
of_node of an another device. Here the of_node comes from _phy provider_.
>
> Finally, it really doesn't look right for a device object to have an
> 'ops' structure. The whole point of the driver model is that a struct
> device doesn't encapsulate any behaviour. A device gets registers to a
> bus type, and then the driver core will associate a struct device_driver

We have decided not to implement the PHY layer as a separate bus layer. 
The PHY provider can be part of any other bus. Making the PHY layer as a 
bus will make the PHY provider to be part of multiple buses which will 
lead to bad design. All we are trying to do here is keep the pool of PHY 
devices under PHY class in this layer and help any controller that wants 
to use the PHY to get it.
> to a device that it is able to drive, and the struct device_driver is
> supposed to contain any ops structure used to control the device.
>
>> +
>> +/**
>> + * struct phy_bind - represent the binding for the phy
>> + * @dev_name: the device name of the device that will bind to the phy
>> + * @phy_dev_name: the device name of the phy
>> + * @index: used if a single controller uses multiple phys
>> + * @auto_bind: tells if the binding is done explicitly from board file or not
>> + * @phy: reference to the phy
>> + * @list: to maintain a linked list of the binding information
>> + */
>> +struct phy_bind {
>> +	const char	*dev_name;
>> +	const char	*phy_dev_name;
>> +	int		index;
>> +	int		auto_bind:1;
>> +	struct phy	*phy;
>> +	struct list_head list;
>> +};
>
> How are PHYs attached to the system. Would the PHY be a direct child of
> the host controller device, or would a PHY hang off another bus (like
> i2c) for control? (this is how Ethernet phys work; they hang off the
> MDIO bus, but may be attached to any Ethernet controller).

This layer does not have any restriction on how the PHY is attached to 
the system. For all the sample cases (USB OTG controller in OMAP 
platforms) that follows this patch, the PHY is attached to the platform 
bus and the PHY provider is a platform driver. All this framework does 
is maintain a list of PHY's added in the system and helps the controller 
to find the appropriate PHY.
We are currently not looking at having Ethernet use this layer because 
it itself has a comprehensive PHY layer and merging it with this will 
take some effort. However other subsystems like USB, SATA, video etc.. 
can make use of this.
>
> Since there is at most a 1:N relationship between host controllers and
> PHYs, there shouldn't be any need for a separate structure to describe
> binding. Put the inding data into the struct phy itself. Each host
> controller can have a list of phys that it is bound to.

No. Having the host controller to have a list of phys wont be a good 
idea IMHO. The host controller is just an IP and the PHY to which it 
will be connected can vary from board to board, platform to platform. So 
ideally this binding should come from platform initialization code/dt data.

Thanks
Kishon


From Ian.Campbell at citrix.com  Mon Apr 15 08:28:57 2013
From: Ian.Campbell at citrix.com (Ian Campbell)
Date: Mon, 15 Apr 2013 13:28:57 +0100
Subject: [Xen-devel] [PATCH] arm64: remove PSR bit macros from uapi
In-Reply-To: <1366026513.4963.106.camel@zakaz.uk.xensource.com>
References: <1365779399-16654-1-git-send-email-ian.campbell@citrix.com>
 <20130412151835.GK12363@mudshark.cambridge.arm.com>
 <1365781834.15783.107.camel@zakaz.uk.xensource.com>
 <1365782789.15783.113.camel@zakaz.uk.xensource.com>
 <60a204007309b815b1ac115c817dc808@localhost>
 <1366026513.4963.106.camel@zakaz.uk.xensource.com>
Message-ID: <1366028937.4963.122.camel@zakaz.uk.xensource.com>

On Mon, 2013-04-15 at 12:48 +0100, Ian Campbell wrote:
> I'll file a bug against glibc/ubuntu/linaro as soon as I
> figure out which is the best target... 

https://bugs.launchpad.net/linaro-aarch64/+bug/1169164

Ian.



From arnd at arndb.de  Mon Apr 15 08:32:45 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 15 Apr 2013 14:32:45 +0200
Subject: Latest randconfig build errors
In-Reply-To: <CAF6AEGv=3453KKS9-8YAgHrxMMbNvLMvt0pz-=qdG+zcd-Trrw@mail.gmail.com>
References: <20130304095136.GI17833@n2100.arm.linux.org.uk>
 <20130304184649.GO11806@atomide.com>
 <CAF6AEGv=3453KKS9-8YAgHrxMMbNvLMvt0pz-=qdG+zcd-Trrw@mail.gmail.com>
Message-ID: <201304151432.45362.arnd@arndb.de>

On Saturday 13 April 2013, Rob Clark wrote:
> On Mon, Mar 4, 2013 at 1:46 PM, Tony Lindgren <tony at atomide.com> wrote:
> >
> >> drivers/gpu/drm/tilcdc/tilcdc_slave.o:(.data+0x54): multiple definition of `__mod_of_device_table'
> >> drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54): first defined here
> >> drivers/gpu/drm/tilcdc/tilcdc_panel.o:(.data+0x54): multiple definition of `__mod_of_device_table'
> >> drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54): first defined here
> >> drivers/gpu/drm/tilcdc/tilcdc_drv.o:(.data+0x184): multiple definition of `__mod_of_device_table'
> >> drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54): first defined here
> >
> > Rob, I assume you'll do a patch for this one?
> 
> 
> oh, I apologize for the late reply, I didn't see this email...
> 
> There is a patch that we can merge to make tilcdc bool instead of
> tristate[1], which I suppose is ok for a temporary fix.  Although I'm
> all-ears if someone has a better idea about how to fix this.  The
> problem is that we have multiple sub-devices for different possible
> panel drivers, so that depending on DT tables, the correct ones get
> loaded for the hw.  But they are all built into a single module.

If the master device is always present, that's enough for autoloading
the module anyway, you can just drop the other two MODULE_DEVICE_TABLE
lines.

	Arnd


From kishon at ti.com  Mon Apr 15 08:33:04 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Mon, 15 Apr 2013 18:03:04 +0530
Subject: [PATCH v3 0/6] Generic PHY Framework
In-Reply-To: <20130415122634.3A08A3E0AA8@localhost>
References: <1363770725-13717-1-git-send-email-kishon@ti.com>
 <20130415102009.D358E3E0AA8@localhost> <516BD835.8060007@ti.com>
 <20130415122634.3A08A3E0AA8@localhost>
Message-ID: <516BF380.9020004@ti.com>

Hi,

On Monday 15 April 2013 05:56 PM, Grant Likely wrote:
> On Mon, 15 Apr 2013 16:06:37 +0530, Kishon Vijay Abraham I <kishon at ti.com> wrote:
>> Hi,
>>
>> On Monday 15 April 2013 03:50 PM, Grant Likely wrote:
>>> On Wed, 20 Mar 2013 14:41:59 +0530, Kishon Vijay Abraham I <kishon at ti.com> wrote:
>>>> Added a generic PHY framework that provides a set of APIs for the PHY drivers
>>>> to create/destroy a PHY and APIs for the PHY users to obtain a reference to
>>>> the PHY with or without using phandle. To obtain a reference to the PHY
>>>> without using phandle, the platform specfic intialization code (say from board
>>>> file) should have already called phy_bind with the binding information. The
>>>> binding information consists of phy's device name, phy user device name and an
>>>> index. The index is used when the same phy user binds to mulitple phys.
>>>>
>>>> This framework will be of use only to devices that uses external PHY (PHY
>>>> functionality is not embedded within the controller).
>>>>
>>>> The intention of creating this framework is to bring the phy drivers spread
>>>> all over the Linux kernel to drivers/phy to increase code re-use and to
>>>> increase code maintainability.
>>>>
>>>> Comments to make PHY as bus wasn't done because PHY devices can be part of
>>>> other bus and making a same device attached to multiple bus leads to bad
>>>> design.
>>>>
>>>> Making omap-usb2 and twl4030 to use this framework is provided as a sample.
>>>>
>>>> This patch series is developed on 3.9-rc3. Once the patch series gets finalised
>>>> I'll resend omap-usb2 and twl4030 part based on Felipe's tree.
>>>>
>>>
>>> [...]
>>>
>>>>    drivers/Kconfig                                    |    2 +
>>>>    drivers/Makefile                                   |    2 +
>>>>    drivers/phy/Kconfig                                |   13 +
>>>>    drivers/phy/Makefile                               |    5 +
>>>>    drivers/phy/phy-core.c                             |  574 ++++++++++++++++++++
>>>
>>> This looks to be very specific for USB PHYs. Are you intending it to be
>>> used for other types of PHYs, like Ethernet PHYs? If not, then this
>>
>> Not really. This can be used by USB, SATA and Sylwester was planning to
>> use it for video PHY's.
>
> So what are the common bits that are shared between those phys? Merely
> matching phys to controllers? Besides that, each of those devices have

The same PIPE3 PHY IP is used for USB (usb3) and SATA in OMAP5. Even for 
just matching PHYs to controllers you need a simple framework (like 
this) or else we'll end up in creating such frameworks for lot of these 
subsystems.

Thanks
Kishon


From rogerq at ti.com  Mon Apr 15 08:35:06 2013
From: rogerq at ti.com (Roger Quadros)
Date: Mon, 15 Apr 2013 15:35:06 +0300
Subject: [PATCH] ARM: dts: omap3-beagle-xm: Add USB Host support for Rev Ax/Bx
Message-ID: <1366029306-1824-1-git-send-email-rogerq@ti.com>

Provide RESET and Power regulators for the USB PHY,
the USB Host port mode and the PHY device.

Also provide pin multiplexer information for USB host
pins.

This will not work for Rev Cx boards because of reversed logic
for USB_POWER_Enable.

CC: Beno?t Cousson <b-cousson at ti.com>
Signed-off-by: Roger Quadros <rogerq at ti.com>
---
 arch/arm/boot/dts/omap3-beagle-xm.dts |   62 +++++++++++++++++++++++++++++++++
 1 files changed, 62 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts b/arch/arm/boot/dts/omap3-beagle-xm.dts
index 5a31964..d394c51 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -57,6 +57,60 @@
 		ti,mcbsp = <&mcbsp2>;
 		ti,codec = <&twl_audio>;
 	};
+
+	/* HS USB Port 2 RESET */
+	hsusb2_reset: hsusb2_reset_reg {
+		compatible = "regulator-fixed";
+		regulator-name = "hsusb2_reset";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		gpio = <&gpio5 19 0>;	/* gpio_147 */
+		startup-delay-us = <70000>;
+		enable-active-high;
+	};
+
+	/* HS USB Port 2 Power */
+	hsusb2_power: hsusb2_power_reg {
+		compatible = "regulator-fixed";
+		regulator-name = "hsusb2_vbus";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		gpio = <&twl_gpio 18 0>;	/* GPIO LEDA */
+		startup-delay-us = <70000>;
+		enable-active-high;	/* FIXME: active-low for Rev. C */
+	};
+
+	/* HS USB Host PHY on PORT 2 */
+	hsusb2_phy: hsusb2_phy {
+		compatible = "usb-nop-xceiv";
+		reset-supply = <&hsusb2_reset>;
+		vcc-supply = <&hsusb2_power>;
+	};
+
+};
+
+&omap3_pmx_core {
+	pinctrl-names = "default";
+	pinctrl-0 = <
+			&hsusbb2_pins
+	>;
+
+	hsusbb2_pins: pinmux_hsusbb2_pins {
+		pinctrl-single,pins = <
+			0x5c0 0x3  /* USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_clk OUTPUT */
+			0x5c2 0x3  /* USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_stp OUTPUT */
+			0x5c4 0x10b  /* USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dir INPUT | PULLDOWN */
+			0x5c6 0x10b  /* USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_nxt INPUT | PULLDOWN */
+			0x5c8 0x10b  /* USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat0 INPUT | PULLDOWN */
+			0x5cA 0x10b  /* USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat1 INPUT | PULLDOWN */
+			0x1a4 0x10b  /* USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat2 INPUT | PULLDOWN */
+			0x1a6 0x10b  /* USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat3 INPUT | PULLDOWN */
+			0x1a8 0x10b  /* USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat4 INPUT | PULLDOWN */
+			0x1aa 0x10b  /* USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat5 INPUT | PULLDOWN */
+			0x1ac 0x10b  /* USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat6 INPUT | PULLDOWN */
+			0x1ae 0x10b  /* USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat7 INPUT | PULLDOWN */
+		>;
+	};
 };
 
 &i2c1 {
@@ -125,3 +179,11 @@
 	mode = <3>;
 	power = <50>;
 };
+
+&usbhshost {
+	port2-mode = "ehci-phy";
+};
+
+&usbhsehci {
+	phys = <0 &hsusb2_phy>;
+};
-- 
1.7.4.1



From rogerq at ti.com  Mon Apr 15 08:39:15 2013
From: rogerq at ti.com (Roger Quadros)
Date: Mon, 15 Apr 2013 15:39:15 +0300
Subject: [PATCH] ARM: dts: omap3-beagle-xm: Add USB Host support for Rev
 Ax/Bx
In-Reply-To: <1366029306-1824-1-git-send-email-rogerq@ti.com>
References: <1366029306-1824-1-git-send-email-rogerq@ti.com>
Message-ID: <516BF4F3.5060904@ti.com>

On 04/15/2013 03:35 PM, Roger Quadros wrote:
> Provide RESET and Power regulators for the USB PHY,
> the USB Host port mode and the PHY device.
> 
> Also provide pin multiplexer information for USB host
> pins.
> 
> This will not work for Rev Cx boards because of reversed logic
> for USB_POWER_Enable.
> 
> CC: Beno?t Cousson <b-cousson at ti.com>
> Signed-off-by: Roger Quadros <rogerq at ti.com>
> ---
>  arch/arm/boot/dts/omap3-beagle-xm.dts |   62 +++++++++++++++++++++++++++++++++
>  1 files changed, 62 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts b/arch/arm/boot/dts/omap3-beagle-xm.dts
> index 5a31964..d394c51 100644
> --- a/arch/arm/boot/dts/omap3-beagle-xm.dts
> +++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
> @@ -57,6 +57,60 @@
>  		ti,mcbsp = <&mcbsp2>;
>  		ti,codec = <&twl_audio>;
>  	};
> +
> +	/* HS USB Port 2 RESET */
> +	hsusb2_reset: hsusb2_reset_reg {
> +		compatible = "regulator-fixed";
> +		regulator-name = "hsusb2_reset";
> +		regulator-min-microvolt = <3300000>;
> +		regulator-max-microvolt = <3300000>;
> +		gpio = <&gpio5 19 0>;	/* gpio_147 */
> +		startup-delay-us = <70000>;
> +		enable-active-high;
> +	};
> +
> +	/* HS USB Port 2 Power */
> +	hsusb2_power: hsusb2_power_reg {
> +		compatible = "regulator-fixed";
> +		regulator-name = "hsusb2_vbus";
> +		regulator-min-microvolt = <3300000>;
> +		regulator-max-microvolt = <3300000>;
> +		gpio = <&twl_gpio 18 0>;	/* GPIO LEDA */
> +		startup-delay-us = <70000>;
> +		enable-active-high;	/* FIXME: active-low for Rev. C */

Benoit & Tony,

Any ideas how to tackle the reversed logic for Rev. C boards?

> +	};
> +
> +	/* HS USB Host PHY on PORT 2 */
> +	hsusb2_phy: hsusb2_phy {
> +		compatible = "usb-nop-xceiv";
> +		reset-supply = <&hsusb2_reset>;
> +		vcc-supply = <&hsusb2_power>;
> +	};
> +
> +};

cheers,
-roger



From josephl at nvidia.com  Mon Apr 15 08:42:27 2013
From: josephl at nvidia.com (Joseph Lo)
Date: Mon, 15 Apr 2013 20:42:27 +0800
Subject: [PATCH 1/3] ARM: tegra: fix build error when THUMB2_KERNEL enabled
Message-ID: <1366029749-16476-1-git-send-email-josephl@nvidia.com>

This patch fix the build failure when CONFIG_THUBM2_KERNEL enabled. You
clould see the error message below:

arch/arm/mach-tegra/sleep-tegra30.S:69: Error: shift must be constant --
`orr r12,r12,r4,lsl r3'

Reported-by: Arnd Bergmann <arnd at arndb.de>
Signed-off-by: Joseph Lo <josephl at nvidia.com>
---
 arch/arm/mach-tegra/sleep-tegra30.S | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-tegra/sleep-tegra30.S b/arch/arm/mach-tegra/sleep-tegra30.S
index 63a15bd..d29dfcc 100644
--- a/arch/arm/mach-tegra/sleep-tegra30.S
+++ b/arch/arm/mach-tegra/sleep-tegra30.S
@@ -66,7 +66,9 @@ ENTRY(tegra30_cpu_shutdown)
 		FLOW_CTRL_CSR_INTR_FLAG | FLOW_CTRL_CSR_EVENT_FLAG | \
 		FLOW_CTRL_CSR_ENABLE
 	mov	r4, #(1 << 4)
-	orr	r12, r12, r4, lsl r3
+ ARM(	orr	r12, r12, r4, lsl r3	)
+ THUMB(	lsl	r4, r4, r3		)
+ THUMB(	orr	r12, r12, r4		)
 	str	r12, [r1]
 
 	/* Halt this CPU. */
-- 
1.8.2



From josephl at nvidia.com  Mon Apr 15 08:42:28 2013
From: josephl at nvidia.com (Joseph Lo)
Date: Mon, 15 Apr 2013 20:42:28 +0800
Subject: [PATCH 2/3] ARM: tegra: fix relocation truncated error when
 THUMB2_KERNEL enabled
In-Reply-To: <1366029749-16476-1-git-send-email-josephl@nvidia.com>
References: <1366029749-16476-1-git-send-email-josephl@nvidia.com>
Message-ID: <1366029749-16476-2-git-send-email-josephl@nvidia.com>

The conditional branch instruction in Thumb2 only available to short range.
The linker will fail when the conditional branch over the range. Then
resulting in link error when generating kernel image. e.g.:

arch/arm/mach-tegra/reset-handler.S:47:(.text+0xf8e):
relocation truncated to fit: R_ARM_THM_JUMP19 against symbol
`cpu_resume' defined in .data section in arch/arm/kernel/built-in.o

This patch using a Thumb2 instruction IT (if-then) to have a longer branch
range.

Reported-by: Arnd Bergmann <arnd at arndb.de>
Signed-off-by: Joseph Lo <josephl at nvidia.com>
---
 arch/arm/mach-tegra/reset-handler.S | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-tegra/reset-handler.S b/arch/arm/mach-tegra/reset-handler.S
index 1676aba..e6de88a 100644
--- a/arch/arm/mach-tegra/reset-handler.S
+++ b/arch/arm/mach-tegra/reset-handler.S
@@ -44,6 +44,7 @@ ENTRY(tegra_resume)
 
 	cpu_id	r0
 	cmp	r0, #0				@ CPU0?
+ THUMB(	it	ne )
 	bne	cpu_resume			@ no
 
 #ifdef CONFIG_ARCH_TEGRA_3x_SOC
-- 
1.8.2



From josephl at nvidia.com  Mon Apr 15 08:42:29 2013
From: josephl at nvidia.com (Joseph Lo)
Date: Mon, 15 Apr 2013 20:42:29 +0800
Subject: [PATCH 3/3] ARM: tegra: make sure the pointer on 4 byte align when
 THUMB2_KERNEL enabled
In-Reply-To: <1366029749-16476-1-git-send-email-josephl@nvidia.com>
References: <1366029749-16476-1-git-send-email-josephl@nvidia.com>
Message-ID: <1366029749-16476-3-git-send-email-josephl@nvidia.com>

When building kernel with CONFIG_THUMB2_KERNEL, the data pointer in the
assembly may not on the 4 byte alignment. Then causing a data abort when
accessing the pointer. This patch add a ".align" flag in the head of the
pointer. And always using 32-bit ADR Thumb instruction to make sure it
won't build failure.

Signed-off-by: Joseph Lo <josephl at nvidia.com>
---
 arch/arm/mach-tegra/reset-handler.S | 1 +
 arch/arm/mach-tegra/sleep.h         | 3 ++-
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-tegra/reset-handler.S b/arch/arm/mach-tegra/reset-handler.S
index e6de88a..519a8c5 100644
--- a/arch/arm/mach-tegra/reset-handler.S
+++ b/arch/arm/mach-tegra/reset-handler.S
@@ -83,6 +83,7 @@ ENDPROC(tegra_resume)
 
 #ifdef CONFIG_CACHE_L2X0
 	.globl	l2x0_saved_regs_addr
+	.align
 l2x0_saved_regs_addr:
 	.long	0
 #endif
diff --git a/arch/arm/mach-tegra/sleep.h b/arch/arm/mach-tegra/sleep.h
index 970ebd5..73a49b7 100644
--- a/arch/arm/mach-tegra/sleep.h
+++ b/arch/arm/mach-tegra/sleep.h
@@ -92,7 +92,8 @@
 
 #ifdef CONFIG_CACHE_L2X0
 .macro l2_cache_resume, tmp1, tmp2, tmp3, phys_l2x0_saved_regs
-	adr	\tmp1, \phys_l2x0_saved_regs
+ ARM(	adr	\tmp1, \phys_l2x0_saved_regs )
+ THUMB(	adr.w	\tmp1, \phys_l2x0_saved_regs )
 	ldr	\tmp1, [\tmp1]
 	ldr	\tmp2, [\tmp1, #L2X0_R_PHY_BASE]
 	ldr	\tmp3, [\tmp2, #L2X0_CTRL]
-- 
1.8.2



From plagnioj at jcrosoft.com  Mon Apr 15 08:38:34 2013
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Mon, 15 Apr 2013 14:38:34 +0200
Subject: [PATCH 0/3] ARM: at91: move to generic DMA device tree bindings
In-Reply-To: <1366028217-5037-1-git-send-email-ludovic.desroches@atmel.com>
References: <1366028217-5037-1-git-send-email-ludovic.desroches@atmel.com>
Message-ID: <20130415123834.GA15139@game.jcrosoft.org>

On 14:16 Mon 15 Apr     , ludovic.desroches at atmel.com wrote:
> From: Ludovic Desroches <ludovic.desroches at atmel.com>
> 
> Hi,
> 
> This set of patches introduces DMA device tree bindings support for the atmel
> DMA controller and first driver conversions.
> 
> I'll send an update of dts file in the next version if there is no major issue
> with the bindings.
looks fine

Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>

Best Regards,
J.
> 
> Regards
> 
> 
> Ludovic Desroches (3):
>   at_hdmac: move to generic DMA binding
>   i2c: at91: convert to dma_request_slave_channel_compat()
>   mci: at91: convert to dma_request_slave_channel_compat()
> 
>  .../devicetree/bindings/dma/atmel-dma.txt          | 26 +++++-
>  arch/arm/boot/dts/sama5d3.dtsi                     |  4 +-
>  drivers/dma/at_hdmac.c                             | 93 ++++++++++++++++++++--
>  drivers/dma/at_hdmac_regs.h                        |  4 +
>  drivers/i2c/busses/i2c-at91.c                      | 49 ++++++------
>  drivers/mmc/host/atmel-mci.c                       | 25 +++---
>  6 files changed, 154 insertions(+), 47 deletions(-)
> 
> -- 
> 1.7.11.3
> 


From sachin.kamat at linaro.org  Mon Apr 15 08:45:28 2013
From: sachin.kamat at linaro.org (Sachin Kamat)
Date: Mon, 15 Apr 2013 18:15:28 +0530
Subject: [PATCH 3/7] ARM: exynos: add missing properties for combiner IRQs
In-Reply-To: <201304151420.35843.arnd@arndb.de>
References: <1365775405-115297-1-git-send-email-arnd@arndb.de>
 <201304151041.44805.arnd@arndb.de>
 <CAK9yfHwXYRqo2yG1moWvMnEmNWXCVL7a9eKzi2we=QmdpVsz-w@mail.gmail.com>
 <201304151420.35843.arnd@arndb.de>
Message-ID: <CAK9yfHz7X5CA+CfYajtVOBL1r17V0YcFz1BfuZ1PSE0qFiSFEA@mail.gmail.com>

On 15 April 2013 17:50, Arnd Bergmann <arnd at arndb.de> wrote:
> On Monday 15 April 2013, Sachin Kamat wrote:
>> >> > diff --git a/arch/arm/boot/dts/exynos4212.dtsi b/arch/arm/boot/dts/exynos4212.dtsi
>> >> > index 36d4299..f83c3c1 100644
>> >> > --- a/arch/arm/boot/dts/exynos4212.dtsi
>> >> > +++ b/arch/arm/boot/dts/exynos4212.dtsi
>> >> > @@ -26,6 +26,15 @@
>> >> >                 cpu-offset = <0x8000>;
>> >> >         };
>> >> >
>> >> > +       interrupt-controller at 10440000 {
>> >>
>> >> Don't we need a node name here (combiner:interrupt-controller at 10440000)?
>> >
>> > Why?
>>
>> Since it is being referenced as "&combiner" by other bindings, i
>> thought that was required.
>
> The original definition actually comes from exynos4.dtsi. It's enough
> to have the label in one place.

Yes, right. I overlooked that.

>
>> >> We have a combiner node defined in exynos4x12.dtsi. With the bindings
>> >> now defined separately in 4212 and 4412 dtsi files, probably the one
>> >> in 4x12 could be dropped?
>> >
>> > I did not see that one, but it seems to have the wrong numbers in the last
>> > four interrupt specifiers. I think it would be better to just fix that one
>> > and keep using it.
>>
>> OK. Do you want me to fix it and send as a patch or would you like to do it?
>
> If you have a patch that works, you could just send it out, oetherwise I'd
> do it.

Not ATM, so please go ahead.

-- 
With warm regards,
Sachin


From plagnioj at jcrosoft.com  Mon Apr 15 08:43:21 2013
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Mon, 15 Apr 2013 14:43:21 +0200
Subject: [PATCH v3 2/2] video: imxfb: Add DT support
In-Reply-To: <20130414143132.GD27394@pengutronix.de>
References: <1365157876-1757-1-git-send-email-mpa@pengutronix.de>
 <1365157876-1757-3-git-send-email-mpa@pengutronix.de>
 <20130408075742.GR20693@game.jcrosoft.org>
 <20130414143132.GD27394@pengutronix.de>
Message-ID: <20130415124321.GB15139@game.jcrosoft.org>

On 16:31 Sun 14 Apr     , Markus Pargmann wrote:
> On Mon, Apr 08, 2013 at 09:57:42AM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > On 12:31 Fri 05 Apr     , Markus Pargmann wrote:
> > > Add devicetree support for imx framebuffer driver. It uses the generic
> > > display bindings and helper functions.
> > > 
> > > Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
> > > Cc: Fabio Estevam <festevam at gmail.com>
> > > Cc: Mark Rutland <mark.rutland at arm.com>
> > > ---
> > >  .../devicetree/bindings/video/fsl,imx-fb.txt       |  49 ++++++
> > >  drivers/video/imxfb.c                              | 192 +++++++++++++++++----
> > >  2 files changed, 207 insertions(+), 34 deletions(-)
> > >  create mode 100644 Documentation/devicetree/bindings/video/fsl,imx-fb.txt
> > > 
> > > diff --git a/Documentation/devicetree/bindings/video/fsl,imx-fb.txt b/Documentation/devicetree/bindings/video/fsl,imx-fb.txt
> > > new file mode 100644
> > > index 0000000..bde9c77
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/video/fsl,imx-fb.txt
> > > @@ -0,0 +1,49 @@
> > > +Freescale imx21 Framebuffer
> > > +
> > > +This framebuffer driver supports devices imx1, imx21, imx25, and imx27.
> > > +
> > > +Required properties:
> > > +- compatible : "fsl,<chip>-fb", chip should be imx1 or imx21
> > > +- reg : Should contain 1 register ranges(address and length)
> > > +- interrupts : One interrupt of the fb dev
> > > +
> > > +Required nodes:
> > > +- display: Phandle to a display node as described in
> > > +	Documentation/devicetree/bindings/video/display-timing.txt
> > > +	Additional, the display node has to define properties:
> > > +	- fsl,bpp: Bits per pixel
> > > +	- fsl,pcr: LCDC PCR value
> > > +
> > > +Optional properties:
> > > +- dmacr-eukrea: Should be set for eukrea boards.
> > why ?
> 
> Because eukrea boards have a different dmacr then all other boards using
> imxfb. The dmacr address is hardcoded as defaults in the code. I could
> also search for the board name in the DT, but there are no eukrea boards
> with DT at the moment, so I thought a bool property may be better for
> the moment.
so no if an other board come will have an other property no

add an optionnal option to pass the dmacr
> 
> > 
> > and This should be prefix by yhe Vendor here Eukrea
> 
> Okay.
> 
> Regards,
> 
> Markus
> 
> > > +
> > > +Example:
> > > +
> > > +	imxfb: fb at 10021000 {
> > > +		compatible = "fsl,imx27-fb", "fsl,imx21-fb";
> > > +		interrupts = <61>;
> > > +		reg = <0x10021000 0x1000>;
> > > +		display = <&display0>;
> > > +	};
> > > +
> > > +	...
> > > +
> > > +	display0: display0 {
> > > +		model = "Primeview-PD050VL1";
> > > +		native-mode = <&timing_disp0>;
> > > +		fsl,bpp = <16>;		/* non-standard but required */
> > > +		fsl,pcr = <0xf0c88080>;	/* non-standard but required */
> > > +		display-timings {
> > > +			timing_disp0: 640x480 {
> > > +				hactive = <640>;
> > > +				vactive = <480>;
> > > +				hback-porch = <112>;
> > > +				hfront-porch = <36>;
> > > +				hsync-len = <32>;
> > > +				vback-porch = <33>;
> > > +				vfront-porch = <33>;
> > > +				vsync-len = <2>;
> > > +				clock-frequency = <25000000>;
> > > +			};
> > > +		};
> > > +	};
> > > diff --git a/drivers/video/imxfb.c b/drivers/video/imxfb.c
> > > index ef2b587..5a9bc598 100644
> > > --- a/drivers/video/imxfb.c
> > > +++ b/drivers/video/imxfb.c
> > > @@ -32,6 +32,12 @@
> > >  #include <linux/io.h>
> > >  #include <linux/math64.h>
> > >  #include <linux/uaccess.h>
> > > +#include <linux/of.h>
> > > +#include <linux/of_device.h>
> > > +
> > > +#include <video/of_display_timing.h>
> > > +#include <video/of_videomode.h>
> > > +#include <video/videomode.h>
> > >  
> > >  #include <linux/platform_data/video-imxfb.h>
> > >  
> > > @@ -117,10 +123,13 @@
> > >  #define LGWCR_GWAV(alpha)	(((alpha) & 0xff) << 24)
> > >  #define LGWCR_GWE	(1 << 22)
> > >  
> > > +#define IMXFB_LSCR1_DEFAULT 0x00120300
> > > +#define IMXFB_DMACR_DEFAULT 0x00020010
> > > +#define IMXFB_DMACR_EUKREA_DEFAULT 0x00040060
> > > +
> > >  /* Used fb-mode. Can be set on kernel command line, therefore file-static. */
> > >  static const char *fb_mode;
> > >  
> > > -
> > >  /*
> > >   * These are the bitfields for each
> > >   * display depth that we support.
> > > @@ -192,6 +201,19 @@ static struct platform_device_id imxfb_devtype[] = {
> > >  };
> > >  MODULE_DEVICE_TABLE(platform, imxfb_devtype);
> > >  
> > > +static struct of_device_id imxfb_of_dev_id[] = {
> > > +	{
> > > +		.compatible = "fsl,imx1-fb",
> > > +		.data = &imxfb_devtype[IMX1_FB],
> > > +	}, {
> > > +		.compatible = "fsl,imx21-fb",
> > > +		.data = &imxfb_devtype[IMX21_FB],
> > > +	}, {
> > > +		/* sentinel */
> > > +	}
> > > +};
> > > +MODULE_DEVICE_TABLE(of, imxfb_of_dev_id);
> > > +
> > >  static inline int is_imx1_fb(struct imxfb_info *fbi)
> > >  {
> > >  	return fbi->devtype == IMX1_FB;
> > > @@ -324,6 +346,9 @@ static const struct imx_fb_videomode *imxfb_find_mode(struct imxfb_info *fbi)
> > >  	struct imx_fb_videomode *m;
> > >  	int i;
> > >  
> > > +	if (!fb_mode)
> > > +		return &fbi->mode[0];
> > > +
> > >  	for (i = 0, m = &fbi->mode[0]; i < fbi->num_modes; i++, m++) {
> > >  		if (!strcmp(m->mode.name, fb_mode))
> > >  			return m;
> > > @@ -479,6 +504,9 @@ static int imxfb_bl_update_status(struct backlight_device *bl)
> > >  	struct imxfb_info *fbi = bl_get_data(bl);
> > >  	int brightness = bl->props.brightness;
> > >  
> > > +	if (!fbi->pwmr)
> > > +		return 0;
> > > +
> > >  	if (bl->props.power != FB_BLANK_UNBLANK)
> > >  		brightness = 0;
> > >  	if (bl->props.fb_blank != FB_BLANK_UNBLANK)
> > > @@ -719,7 +747,8 @@ static int imxfb_activate_var(struct fb_var_screeninfo *var, struct fb_info *inf
> > >  
> > >  	writel(fbi->pcr, fbi->regs + LCDC_PCR);
> > >  #ifndef PWMR_BACKLIGHT_AVAILABLE
> > > -	writel(fbi->pwmr, fbi->regs + LCDC_PWMR);
> > > +	if (fbi->pwmr)
> > > +		writel(fbi->pwmr, fbi->regs + LCDC_PWMR);
> > >  #endif
> > >  	writel(fbi->lscr1, fbi->regs + LCDC_LSCR1);
> > >  	writel(fbi->dmacr, fbi->regs + LCDC_DMACR);
> > > @@ -758,13 +787,12 @@ static int imxfb_resume(struct platform_device *dev)
> > >  #define imxfb_resume	NULL
> > >  #endif
> > >  
> > > -static int __init imxfb_init_fbinfo(struct platform_device *pdev)
> > > +static int imxfb_init_fbinfo(struct platform_device *pdev)
> > >  {
> > >  	struct imx_fb_platform_data *pdata = pdev->dev.platform_data;
> > >  	struct fb_info *info = dev_get_drvdata(&pdev->dev);
> > >  	struct imxfb_info *fbi = info->par;
> > > -	struct imx_fb_videomode *m;
> > > -	int i;
> > > +	struct device_node *np;
> > >  
> > >  	pr_debug("%s\n",__func__);
> > >  
> > > @@ -795,41 +823,96 @@ static int __init imxfb_init_fbinfo(struct platform_device *pdev)
> > >  	info->fbops			= &imxfb_ops;
> > >  	info->flags			= FBINFO_FLAG_DEFAULT |
> > >  					  FBINFO_READS_FAST;
> > > -	info->var.grayscale		= pdata->cmap_greyscale;
> > > -	fbi->cmap_inverse		= pdata->cmap_inverse;
> > > -	fbi->cmap_static		= pdata->cmap_static;
> > > -	fbi->lscr1			= pdata->lscr1;
> > > -	fbi->dmacr			= pdata->dmacr;
> > > -	fbi->pwmr			= pdata->pwmr;
> > > -	fbi->lcd_power			= pdata->lcd_power;
> > > -	fbi->backlight_power		= pdata->backlight_power;
> > > -
> > > -	for (i = 0, m = &pdata->mode[0]; i < pdata->num_modes; i++, m++)
> > > -		info->fix.smem_len = max_t(size_t, info->fix.smem_len,
> > > -				m->mode.xres * m->mode.yres * m->bpp / 8);
> > > +	if (pdata) {
> > > +		info->var.grayscale		= pdata->cmap_greyscale;
> > > +		fbi->cmap_inverse		= pdata->cmap_inverse;
> > > +		fbi->cmap_static		= pdata->cmap_static;
> > > +		fbi->lscr1			= pdata->lscr1;
> > > +		fbi->dmacr			= pdata->dmacr;
> > > +		fbi->pwmr			= pdata->pwmr;
> > > +		fbi->lcd_power			= pdata->lcd_power;
> > > +		fbi->backlight_power		= pdata->backlight_power;
> > > +	} else {
> > > +		np = pdev->dev.of_node;
> > > +		info->var.grayscale = of_property_read_bool(np,
> > > +						"cmap-greyscale");
> > > +		fbi->cmap_inverse = of_property_read_bool(np, "cmap-inverse");
> > > +		fbi->cmap_static = of_property_read_bool(np, "cmap-static");
> > > +
> > > +		fbi->lscr1 = IMXFB_LSCR1_DEFAULT;
> > > +		if (of_property_read_bool(np, "dmacr-eukrea"))
> > > +			fbi->dmacr = IMXFB_DMACR_EUKREA_DEFAULT;
> > > +		else
> > > +			fbi->dmacr = IMXFB_DMACR_DEFAULT;
> > > +
> > > +		/* These two function pointers could be used by some specific
> > > +		 * platforms. */
> > > +		fbi->lcd_power = NULL;
> > > +		fbi->backlight_power = NULL;
> > > +	}
> > > +
> > > +	return 0;
> > > +}
> > > +
> > > +static int imxfb_of_read_mode(struct device *dev, struct device_node *np,
> > > +		struct imx_fb_videomode *imxfb_mode)
> > > +{
> > > +	int ret;
> > > +	struct fb_videomode *of_mode = &imxfb_mode->mode;
> > > +	u32 bpp;
> > > +	u32 pcr;
> > > +
> > > +	ret = of_property_read_string(np, "model", &of_mode->name);
> > > +	if (ret)
> > > +		of_mode->name = NULL;
> > > +
> > > +	ret = of_get_fb_videomode(np, of_mode, OF_USE_NATIVE_MODE);
> > > +	if (ret) {
> > > +		dev_err(dev, "Failed to get videomode from DT\n");
> > > +		return ret;
> > > +	}
> > > +
> > > +	ret = of_property_read_u32(np, "fsl,bpp", &bpp);
> > > +	ret |= of_property_read_u32(np, "fsl,pcr", &pcr);
> > > +
> > > +	if (ret) {
> > > +		dev_err(dev, "Failed to read bpp and pcr from DT\n");
> > > +		return -EINVAL;
> > > +	}
> > > +
> > > +	if (bpp < 1 || bpp > 255) {
> > > +		dev_err(dev, "Bits per pixel have to be between 1 and 255\n");
> > > +		return -EINVAL;
> > > +	}
> > > +
> > > +	imxfb_mode->bpp = bpp;
> > > +	imxfb_mode->pcr = pcr;
> > >  
> > >  	return 0;
> > >  }
> > >  
> > > -static int __init imxfb_probe(struct platform_device *pdev)
> > > +static int imxfb_probe(struct platform_device *pdev)
> > >  {
> > >  	struct imxfb_info *fbi;
> > >  	struct fb_info *info;
> > >  	struct imx_fb_platform_data *pdata;
> > >  	struct resource *res;
> > > +	struct imx_fb_videomode *m;
> > > +	const struct of_device_id *of_id;
> > >  	int ret, i;
> > > +	int bytes_per_pixel;
> > >  
> > >  	dev_info(&pdev->dev, "i.MX Framebuffer driver\n");
> > >  
> > > +	of_id = of_match_device(imxfb_of_dev_id, &pdev->dev);
> > > +	if (of_id)
> > > +		pdev->id_entry = of_id->data;
> > > +
> > >  	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > >  	if (!res)
> > >  		return -ENODEV;
> > >  
> > >  	pdata = pdev->dev.platform_data;
> > > -	if (!pdata) {
> > > -		dev_err(&pdev->dev,"No platform_data available\n");
> > > -		return -ENOMEM;
> > > -	}
> > >  
> > >  	info = framebuffer_alloc(sizeof(struct imxfb_info), &pdev->dev);
> > >  	if (!info)
> > > @@ -837,15 +920,55 @@ static int __init imxfb_probe(struct platform_device *pdev)
> > >  
> > >  	fbi = info->par;
> > >  
> > > -	if (!fb_mode)
> > > -		fb_mode = pdata->mode[0].mode.name;
> > > -
> > >  	platform_set_drvdata(pdev, info);
> > >  
> > >  	ret = imxfb_init_fbinfo(pdev);
> > >  	if (ret < 0)
> > >  		goto failed_init;
> > >  
> > > +	if (pdata) {
> > > +		if (!fb_mode)
> > > +			fb_mode = pdata->mode[0].mode.name;
> > > +
> > > +		fbi->mode = pdata->mode;
> > > +		fbi->num_modes = pdata->num_modes;
> > > +	} else {
> > > +		struct device_node *display_np;
> > > +		fb_mode = NULL;
> > > +
> > > +		display_np = of_parse_phandle(pdev->dev.of_node, "display", 0);
> > > +		if (!display_np) {
> > > +			dev_err(&pdev->dev, "No display defined in devicetree\n");
> > > +			ret = -EINVAL;
> > > +			goto failed_of_parse;
> > > +		}
> > > +
> > > +		/*
> > > +		 * imxfb does not support more modes, we choose only the native
> > > +		 * mode.
> > > +		 */
> > > +		fbi->num_modes = 1;
> > > +
> > > +		fbi->mode = devm_kzalloc(&pdev->dev,
> > > +				sizeof(struct imx_fb_videomode), GFP_KERNEL);
> > > +		if (!fbi->mode) {
> > > +			ret = -ENOMEM;
> > > +			goto failed_of_parse;
> > > +		}
> > > +
> > > +		ret = imxfb_of_read_mode(&pdev->dev, display_np, fbi->mode);
> > > +		if (ret)
> > > +			goto failed_of_parse;
> > > +	}
> > > +
> > > +	/* Calculate maximum bytes used per pixel. In most cases this should
> > > +	 * be the same as m->bpp/8 */
> > > +	m = &fbi->mode[0];
> > > +	bytes_per_pixel = (m->bpp + 7) / 8;
> > > +	for (i = 0; i < fbi->num_modes; i++, m++)
> > > +		info->fix.smem_len = max_t(size_t, info->fix.smem_len,
> > > +				m->mode.xres * m->mode.yres * bytes_per_pixel);
> > > +
> > >  	res = request_mem_region(res->start, resource_size(res),
> > >  				DRIVER_NAME);
> > >  	if (!res) {
> > > @@ -878,7 +1001,8 @@ static int __init imxfb_probe(struct platform_device *pdev)
> > >  		goto failed_ioremap;
> > >  	}
> > >  
> > > -	if (!pdata->fixed_screen_cpu) {
> > > +	/* Seems not being used by anyone, so no support for oftree */
> > > +	if (!pdata || !pdata->fixed_screen_cpu) {
> > >  		fbi->map_size = PAGE_ALIGN(info->fix.smem_len);
> > >  		fbi->map_cpu = dma_alloc_writecombine(&pdev->dev,
> > >  				fbi->map_size, &fbi->map_dma, GFP_KERNEL);
> > > @@ -903,18 +1027,16 @@ static int __init imxfb_probe(struct platform_device *pdev)
> > >  		info->fix.smem_start = fbi->screen_dma;
> > >  	}
> > >  
> > > -	if (pdata->init) {
> > > +	if (pdata && pdata->init) {
> > >  		ret = pdata->init(fbi->pdev);
> > >  		if (ret)
> > >  			goto failed_platform_init;
> > >  	}
> > >  
> > > -	fbi->mode = pdata->mode;
> > > -	fbi->num_modes = pdata->num_modes;
> > >  
> > >  	INIT_LIST_HEAD(&info->modelist);
> > > -	for (i = 0; i < pdata->num_modes; i++)
> > > -		fb_add_videomode(&pdata->mode[i].mode, &info->modelist);
> > > +	for (i = 0; i < fbi->num_modes; i++)
> > > +		fb_add_videomode(&fbi->mode[i].mode, &info->modelist);
> > >  
> > >  	/*
> > >  	 * This makes sure that our colour bitfield
> > > @@ -944,10 +1066,10 @@ static int __init imxfb_probe(struct platform_device *pdev)
> > >  failed_register:
> > >  	fb_dealloc_cmap(&info->cmap);
> > >  failed_cmap:
> > > -	if (pdata->exit)
> > > +	if (pdata && pdata->exit)
> > >  		pdata->exit(fbi->pdev);
> > >  failed_platform_init:
> > > -	if (!pdata->fixed_screen_cpu)
> > > +	if (pdata && !pdata->fixed_screen_cpu)
> > >  		dma_free_writecombine(&pdev->dev,fbi->map_size,fbi->map_cpu,
> > >  			fbi->map_dma);
> > >  failed_map:
> > > @@ -956,6 +1078,7 @@ failed_ioremap:
> > >  failed_getclock:
> > >  	release_mem_region(res->start, resource_size(res));
> > >  failed_req:
> > > +failed_of_parse:
> > >  	kfree(info->pseudo_palette);
> > >  failed_init:
> > >  	platform_set_drvdata(pdev, NULL);
> > > @@ -980,7 +1103,7 @@ static int imxfb_remove(struct platform_device *pdev)
> > >  	unregister_framebuffer(info);
> > >  
> > >  	pdata = pdev->dev.platform_data;
> > > -	if (pdata->exit)
> > > +	if (pdata && pdata->exit)
> > >  		pdata->exit(fbi->pdev);
> > >  
> > >  	fb_dealloc_cmap(&info->cmap);
> > > @@ -1009,6 +1132,7 @@ static struct platform_driver imxfb_driver = {
> > >  	.shutdown	= imxfb_shutdown,
> > >  	.driver		= {
> > >  		.name	= DRIVER_NAME,
> > > +		.of_match_table = imxfb_of_dev_id,
> > >  	},
> > >  	.id_table	= imxfb_devtype,
> > >  };
> > > -- 
> > > 1.8.1.5
> > > 
> > > _______________________________________________
> > > devicetree-discuss mailing list
> > > devicetree-discuss at lists.ozlabs.org
> > > https://lists.ozlabs.org/listinfo/devicetree-discuss
> > 
> 
> -- 
> Pengutronix e.K.                           |                             |
> Industrial Linux Solutions                 | http://www.pengutronix.de/  |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
> Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From thomas.petazzoni at free-electrons.com  Mon Apr 15 08:57:41 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Mon, 15 Apr 2013 14:57:41 +0200
Subject: [PATCH v6 1/3] of/pci: Unify pci_process_bridge_OF_ranges from
 Microblaze and PowerPC
In-Reply-To: <1365693969-23907-2-git-send-email-Andrew.Murray@arm.com>
References: <1365693969-23907-1-git-send-email-Andrew.Murray@arm.com>
 <1365693969-23907-2-git-send-email-Andrew.Murray@arm.com>
Message-ID: <20130415145741.4e4c362b@skate>

Michal, Ben,

Would you have some time to look at this patch and give your comments
and/or ACK ? Since it touches the PowerPC and Microblaze core code, we
need your agreement to merge this code, and quite a bit of code pending
for 3.10 depends on this patch.

Rob, alternatively, could we imagine doing a different version of the
'of/pci: Provide support for parsing PCI DT ranges property' that
introduces the new API only, leaving the PowerPC and Microblaze rework
as follow-up efforts, so that all the PCIe drivers that depend on this
patch can get in for 3.10 ? I'd find it pretty sad if the Marvell PCIe
driver that has been worked on since 4+ months does not get into 3.10
just because this patch cannot be merged.

Thanks!

Thomas

On Thu, 11 Apr 2013 16:26:07 +0100, Andrew Murray wrote:
> The pci_process_bridge_OF_ranges function, used to parse the "ranges"
> property of a PCI host device, is found in both Microblaze and PowerPC
> architectures. These implementations are nearly identical. This patch
> moves this common code to a common place.
> 
> Signed-off-by: Andrew Murray <Andrew.Murray at arm.com>
> Signed-off-by: Liviu Dudau <Liviu.Dudau at arm.com>
> Reviewed-by: Rob Herring <rob.herring at calxeda.com>
> Tested-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> ---
>  arch/microblaze/include/asm/pci-bridge.h |    5 +-
>  arch/microblaze/pci/pci-common.c         |  192 ----------------------------
>  arch/powerpc/include/asm/pci-bridge.h    |    5 +-
>  arch/powerpc/kernel/pci-common.c         |  192 ----------------------------
>  drivers/of/of_pci.c                      |  200 ++++++++++++++++++++++++++++++
>  include/linux/of_pci.h                   |    4 +
>  6 files changed, 206 insertions(+), 392 deletions(-)
> 
> diff --git a/arch/microblaze/include/asm/pci-bridge.h b/arch/microblaze/include/asm/pci-bridge.h
> index cb5d397..5783cd6 100644
> --- a/arch/microblaze/include/asm/pci-bridge.h
> +++ b/arch/microblaze/include/asm/pci-bridge.h
> @@ -10,6 +10,7 @@
>  #include <linux/pci.h>
>  #include <linux/list.h>
>  #include <linux/ioport.h>
> +#include <linux/of_pci.h>
>  
>  struct device_node;
>  
> @@ -132,10 +133,6 @@ extern void setup_indirect_pci(struct pci_controller *hose,
>  extern struct pci_controller *pci_find_hose_for_OF_device(
>  			struct device_node *node);
>  
> -/* Fill up host controller resources from the OF node */
> -extern void pci_process_bridge_OF_ranges(struct pci_controller *hose,
> -			struct device_node *dev, int primary);
> -
>  /* Allocate & free a PCI host bridge structure */
>  extern struct pci_controller *pcibios_alloc_controller(struct device_node *dev);
>  extern void pcibios_free_controller(struct pci_controller *phb);
> diff --git a/arch/microblaze/pci/pci-common.c b/arch/microblaze/pci/pci-common.c
> index 9ea521e..2735ad9 100644
> --- a/arch/microblaze/pci/pci-common.c
> +++ b/arch/microblaze/pci/pci-common.c
> @@ -622,198 +622,6 @@ void pci_resource_to_user(const struct pci_dev *dev, int bar,
>  	*end = rsrc->end - offset;
>  }
>  
> -/**
> - * pci_process_bridge_OF_ranges - Parse PCI bridge resources from device tree
> - * @hose: newly allocated pci_controller to be setup
> - * @dev: device node of the host bridge
> - * @primary: set if primary bus (32 bits only, soon to be deprecated)
> - *
> - * This function will parse the "ranges" property of a PCI host bridge device
> - * node and setup the resource mapping of a pci controller based on its
> - * content.
> - *
> - * Life would be boring if it wasn't for a few issues that we have to deal
> - * with here:
> - *
> - *   - We can only cope with one IO space range and up to 3 Memory space
> - *     ranges. However, some machines (thanks Apple !) tend to split their
> - *     space into lots of small contiguous ranges. So we have to coalesce.
> - *
> - *   - We can only cope with all memory ranges having the same offset
> - *     between CPU addresses and PCI addresses. Unfortunately, some bridges
> - *     are setup for a large 1:1 mapping along with a small "window" which
> - *     maps PCI address 0 to some arbitrary high address of the CPU space in
> - *     order to give access to the ISA memory hole.
> - *     The way out of here that I've chosen for now is to always set the
> - *     offset based on the first resource found, then override it if we
> - *     have a different offset and the previous was set by an ISA hole.
> - *
> - *   - Some busses have IO space not starting at 0, which causes trouble with
> - *     the way we do our IO resource renumbering. The code somewhat deals with
> - *     it for 64 bits but I would expect problems on 32 bits.
> - *
> - *   - Some 32 bits platforms such as 4xx can have physical space larger than
> - *     32 bits so we need to use 64 bits values for the parsing
> - */
> -void pci_process_bridge_OF_ranges(struct pci_controller *hose,
> -				  struct device_node *dev, int primary)
> -{
> -	const u32 *ranges;
> -	int rlen;
> -	int pna = of_n_addr_cells(dev);
> -	int np = pna + 5;
> -	int memno = 0, isa_hole = -1;
> -	u32 pci_space;
> -	unsigned long long pci_addr, cpu_addr, pci_next, cpu_next, size;
> -	unsigned long long isa_mb = 0;
> -	struct resource *res;
> -
> -	pr_info("PCI host bridge %s %s ranges:\n",
> -	       dev->full_name, primary ? "(primary)" : "");
> -
> -	/* Get ranges property */
> -	ranges = of_get_property(dev, "ranges", &rlen);
> -	if (ranges == NULL)
> -		return;
> -
> -	/* Parse it */
> -	pr_debug("Parsing ranges property...\n");
> -	while ((rlen -= np * 4) >= 0) {
> -		/* Read next ranges element */
> -		pci_space = ranges[0];
> -		pci_addr = of_read_number(ranges + 1, 2);
> -		cpu_addr = of_translate_address(dev, ranges + 3);
> -		size = of_read_number(ranges + pna + 3, 2);
> -
> -		pr_debug("pci_space: 0x%08x pci_addr:0x%016llx ",
> -				pci_space, pci_addr);
> -		pr_debug("cpu_addr:0x%016llx size:0x%016llx\n",
> -					cpu_addr, size);
> -
> -		ranges += np;
> -
> -		/* If we failed translation or got a zero-sized region
> -		 * (some FW try to feed us with non sensical zero sized regions
> -		 * such as power3 which look like some kind of attempt
> -		 * at exposing the VGA memory hole)
> -		 */
> -		if (cpu_addr == OF_BAD_ADDR || size == 0)
> -			continue;
> -
> -		/* Now consume following elements while they are contiguous */
> -		for (; rlen >= np * sizeof(u32);
> -		     ranges += np, rlen -= np * 4) {
> -			if (ranges[0] != pci_space)
> -				break;
> -			pci_next = of_read_number(ranges + 1, 2);
> -			cpu_next = of_translate_address(dev, ranges + 3);
> -			if (pci_next != pci_addr + size ||
> -			    cpu_next != cpu_addr + size)
> -				break;
> -			size += of_read_number(ranges + pna + 3, 2);
> -		}
> -
> -		/* Act based on address space type */
> -		res = NULL;
> -		switch ((pci_space >> 24) & 0x3) {
> -		case 1:		/* PCI IO space */
> -			pr_info("  IO 0x%016llx..0x%016llx -> 0x%016llx\n",
> -			       cpu_addr, cpu_addr + size - 1, pci_addr);
> -
> -			/* We support only one IO range */
> -			if (hose->pci_io_size) {
> -				pr_info(" \\--> Skipped (too many) !\n");
> -				continue;
> -			}
> -			/* On 32 bits, limit I/O space to 16MB */
> -			if (size > 0x01000000)
> -				size = 0x01000000;
> -
> -			/* 32 bits needs to map IOs here */
> -			hose->io_base_virt = ioremap(cpu_addr, size);
> -
> -			/* Expect trouble if pci_addr is not 0 */
> -			if (primary)
> -				isa_io_base =
> -					(unsigned long)hose->io_base_virt;
> -			/* pci_io_size and io_base_phys always represent IO
> -			 * space starting at 0 so we factor in pci_addr
> -			 */
> -			hose->pci_io_size = pci_addr + size;
> -			hose->io_base_phys = cpu_addr - pci_addr;
> -
> -			/* Build resource */
> -			res = &hose->io_resource;
> -			res->flags = IORESOURCE_IO;
> -			res->start = pci_addr;
> -			break;
> -		case 2:		/* PCI Memory space */
> -		case 3:		/* PCI 64 bits Memory space */
> -			pr_info(" MEM 0x%016llx..0x%016llx -> 0x%016llx %s\n",
> -			       cpu_addr, cpu_addr + size - 1, pci_addr,
> -			       (pci_space & 0x40000000) ? "Prefetch" : "");
> -
> -			/* We support only 3 memory ranges */
> -			if (memno >= 3) {
> -				pr_info(" \\--> Skipped (too many) !\n");
> -				continue;
> -			}
> -			/* Handles ISA memory hole space here */
> -			if (pci_addr == 0) {
> -				isa_mb = cpu_addr;
> -				isa_hole = memno;
> -				if (primary || isa_mem_base == 0)
> -					isa_mem_base = cpu_addr;
> -				hose->isa_mem_phys = cpu_addr;
> -				hose->isa_mem_size = size;
> -			}
> -
> -			/* We get the PCI/Mem offset from the first range or
> -			 * the, current one if the offset came from an ISA
> -			 * hole. If they don't match, bugger.
> -			 */
> -			if (memno == 0 ||
> -			    (isa_hole >= 0 && pci_addr != 0 &&
> -			     hose->pci_mem_offset == isa_mb))
> -				hose->pci_mem_offset = cpu_addr - pci_addr;
> -			else if (pci_addr != 0 &&
> -				 hose->pci_mem_offset != cpu_addr - pci_addr) {
> -				pr_info(" \\--> Skipped (offset mismatch) !\n");
> -				continue;
> -			}
> -
> -			/* Build resource */
> -			res = &hose->mem_resources[memno++];
> -			res->flags = IORESOURCE_MEM;
> -			if (pci_space & 0x40000000)
> -				res->flags |= IORESOURCE_PREFETCH;
> -			res->start = cpu_addr;
> -			break;
> -		}
> -		if (res != NULL) {
> -			res->name = dev->full_name;
> -			res->end = res->start + size - 1;
> -			res->parent = NULL;
> -			res->sibling = NULL;
> -			res->child = NULL;
> -		}
> -	}
> -
> -	/* If there's an ISA hole and the pci_mem_offset is -not- matching
> -	 * the ISA hole offset, then we need to remove the ISA hole from
> -	 * the resource list for that brige
> -	 */
> -	if (isa_hole >= 0 && hose->pci_mem_offset != isa_mb) {
> -		unsigned int next = isa_hole + 1;
> -		pr_info(" Removing ISA hole at 0x%016llx\n", isa_mb);
> -		if (next < memno)
> -			memmove(&hose->mem_resources[isa_hole],
> -				&hose->mem_resources[next],
> -				sizeof(struct resource) * (memno - next));
> -		hose->mem_resources[--memno].flags = 0;
> -	}
> -}
> -
>  /* Decide whether to display the domain number in /proc */
>  int pci_proc_domain(struct pci_bus *bus)
>  {
> diff --git a/arch/powerpc/include/asm/pci-bridge.h b/arch/powerpc/include/asm/pci-bridge.h
> index 025a130..205bfba 100644
> --- a/arch/powerpc/include/asm/pci-bridge.h
> +++ b/arch/powerpc/include/asm/pci-bridge.h
> @@ -10,6 +10,7 @@
>  #include <linux/pci.h>
>  #include <linux/list.h>
>  #include <linux/ioport.h>
> +#include <linux/of_pci.h>
>  #include <asm-generic/pci-bridge.h>
>  
>  struct device_node;
> @@ -231,10 +232,6 @@ extern int pcibios_map_io_space(struct pci_bus *bus);
>  extern struct pci_controller *pci_find_hose_for_OF_device(
>  			struct device_node* node);
>  
> -/* Fill up host controller resources from the OF node */
> -extern void pci_process_bridge_OF_ranges(struct pci_controller *hose,
> -			struct device_node *dev, int primary);
> -
>  /* Allocate & free a PCI host bridge structure */
>  extern struct pci_controller *pcibios_alloc_controller(struct device_node *dev);
>  extern void pcibios_free_controller(struct pci_controller *phb);
> diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
> index fa12ae4..6edf396 100644
> --- a/arch/powerpc/kernel/pci-common.c
> +++ b/arch/powerpc/kernel/pci-common.c
> @@ -640,198 +640,6 @@ void pci_resource_to_user(const struct pci_dev *dev, int bar,
>  	*end = rsrc->end - offset;
>  }
>  
> -/**
> - * pci_process_bridge_OF_ranges - Parse PCI bridge resources from device tree
> - * @hose: newly allocated pci_controller to be setup
> - * @dev: device node of the host bridge
> - * @primary: set if primary bus (32 bits only, soon to be deprecated)
> - *
> - * This function will parse the "ranges" property of a PCI host bridge device
> - * node and setup the resource mapping of a pci controller based on its
> - * content.
> - *
> - * Life would be boring if it wasn't for a few issues that we have to deal
> - * with here:
> - *
> - *   - We can only cope with one IO space range and up to 3 Memory space
> - *     ranges. However, some machines (thanks Apple !) tend to split their
> - *     space into lots of small contiguous ranges. So we have to coalesce.
> - *
> - *   - We can only cope with all memory ranges having the same offset
> - *     between CPU addresses and PCI addresses. Unfortunately, some bridges
> - *     are setup for a large 1:1 mapping along with a small "window" which
> - *     maps PCI address 0 to some arbitrary high address of the CPU space in
> - *     order to give access to the ISA memory hole.
> - *     The way out of here that I've chosen for now is to always set the
> - *     offset based on the first resource found, then override it if we
> - *     have a different offset and the previous was set by an ISA hole.
> - *
> - *   - Some busses have IO space not starting at 0, which causes trouble with
> - *     the way we do our IO resource renumbering. The code somewhat deals with
> - *     it for 64 bits but I would expect problems on 32 bits.
> - *
> - *   - Some 32 bits platforms such as 4xx can have physical space larger than
> - *     32 bits so we need to use 64 bits values for the parsing
> - */
> -void pci_process_bridge_OF_ranges(struct pci_controller *hose,
> -				  struct device_node *dev, int primary)
> -{
> -	const u32 *ranges;
> -	int rlen;
> -	int pna = of_n_addr_cells(dev);
> -	int np = pna + 5;
> -	int memno = 0, isa_hole = -1;
> -	u32 pci_space;
> -	unsigned long long pci_addr, cpu_addr, pci_next, cpu_next, size;
> -	unsigned long long isa_mb = 0;
> -	struct resource *res;
> -
> -	printk(KERN_INFO "PCI host bridge %s %s ranges:\n",
> -	       dev->full_name, primary ? "(primary)" : "");
> -
> -	/* Get ranges property */
> -	ranges = of_get_property(dev, "ranges", &rlen);
> -	if (ranges == NULL)
> -		return;
> -
> -	/* Parse it */
> -	while ((rlen -= np * 4) >= 0) {
> -		/* Read next ranges element */
> -		pci_space = ranges[0];
> -		pci_addr = of_read_number(ranges + 1, 2);
> -		cpu_addr = of_translate_address(dev, ranges + 3);
> -		size = of_read_number(ranges + pna + 3, 2);
> -		ranges += np;
> -
> -		/* If we failed translation or got a zero-sized region
> -		 * (some FW try to feed us with non sensical zero sized regions
> -		 * such as power3 which look like some kind of attempt at exposing
> -		 * the VGA memory hole)
> -		 */
> -		if (cpu_addr == OF_BAD_ADDR || size == 0)
> -			continue;
> -
> -		/* Now consume following elements while they are contiguous */
> -		for (; rlen >= np * sizeof(u32);
> -		     ranges += np, rlen -= np * 4) {
> -			if (ranges[0] != pci_space)
> -				break;
> -			pci_next = of_read_number(ranges + 1, 2);
> -			cpu_next = of_translate_address(dev, ranges + 3);
> -			if (pci_next != pci_addr + size ||
> -			    cpu_next != cpu_addr + size)
> -				break;
> -			size += of_read_number(ranges + pna + 3, 2);
> -		}
> -
> -		/* Act based on address space type */
> -		res = NULL;
> -		switch ((pci_space >> 24) & 0x3) {
> -		case 1:		/* PCI IO space */
> -			printk(KERN_INFO
> -			       "  IO 0x%016llx..0x%016llx -> 0x%016llx\n",
> -			       cpu_addr, cpu_addr + size - 1, pci_addr);
> -
> -			/* We support only one IO range */
> -			if (hose->pci_io_size) {
> -				printk(KERN_INFO
> -				       " \\--> Skipped (too many) !\n");
> -				continue;
> -			}
> -#ifdef CONFIG_PPC32
> -			/* On 32 bits, limit I/O space to 16MB */
> -			if (size > 0x01000000)
> -				size = 0x01000000;
> -
> -			/* 32 bits needs to map IOs here */
> -			hose->io_base_virt = ioremap(cpu_addr, size);
> -
> -			/* Expect trouble if pci_addr is not 0 */
> -			if (primary)
> -				isa_io_base =
> -					(unsigned long)hose->io_base_virt;
> -#endif /* CONFIG_PPC32 */
> -			/* pci_io_size and io_base_phys always represent IO
> -			 * space starting at 0 so we factor in pci_addr
> -			 */
> -			hose->pci_io_size = pci_addr + size;
> -			hose->io_base_phys = cpu_addr - pci_addr;
> -
> -			/* Build resource */
> -			res = &hose->io_resource;
> -			res->flags = IORESOURCE_IO;
> -			res->start = pci_addr;
> -			break;
> -		case 2:		/* PCI Memory space */
> -		case 3:		/* PCI 64 bits Memory space */
> -			printk(KERN_INFO
> -			       " MEM 0x%016llx..0x%016llx -> 0x%016llx %s\n",
> -			       cpu_addr, cpu_addr + size - 1, pci_addr,
> -			       (pci_space & 0x40000000) ? "Prefetch" : "");
> -
> -			/* We support only 3 memory ranges */
> -			if (memno >= 3) {
> -				printk(KERN_INFO
> -				       " \\--> Skipped (too many) !\n");
> -				continue;
> -			}
> -			/* Handles ISA memory hole space here */
> -			if (pci_addr == 0) {
> -				isa_mb = cpu_addr;
> -				isa_hole = memno;
> -				if (primary || isa_mem_base == 0)
> -					isa_mem_base = cpu_addr;
> -				hose->isa_mem_phys = cpu_addr;
> -				hose->isa_mem_size = size;
> -			}
> -
> -			/* We get the PCI/Mem offset from the first range or
> -			 * the, current one if the offset came from an ISA
> -			 * hole. If they don't match, bugger.
> -			 */
> -			if (memno == 0 ||
> -			    (isa_hole >= 0 && pci_addr != 0 &&
> -			     hose->pci_mem_offset == isa_mb))
> -				hose->pci_mem_offset = cpu_addr - pci_addr;
> -			else if (pci_addr != 0 &&
> -				 hose->pci_mem_offset != cpu_addr - pci_addr) {
> -				printk(KERN_INFO
> -				       " \\--> Skipped (offset mismatch) !\n");
> -				continue;
> -			}
> -
> -			/* Build resource */
> -			res = &hose->mem_resources[memno++];
> -			res->flags = IORESOURCE_MEM;
> -			if (pci_space & 0x40000000)
> -				res->flags |= IORESOURCE_PREFETCH;
> -			res->start = cpu_addr;
> -			break;
> -		}
> -		if (res != NULL) {
> -			res->name = dev->full_name;
> -			res->end = res->start + size - 1;
> -			res->parent = NULL;
> -			res->sibling = NULL;
> -			res->child = NULL;
> -		}
> -	}
> -
> -	/* If there's an ISA hole and the pci_mem_offset is -not- matching
> -	 * the ISA hole offset, then we need to remove the ISA hole from
> -	 * the resource list for that brige
> -	 */
> -	if (isa_hole >= 0 && hose->pci_mem_offset != isa_mb) {
> -		unsigned int next = isa_hole + 1;
> -		printk(KERN_INFO " Removing ISA hole at 0x%016llx\n", isa_mb);
> -		if (next < memno)
> -			memmove(&hose->mem_resources[isa_hole],
> -				&hose->mem_resources[next],
> -				sizeof(struct resource) * (memno - next));
> -		hose->mem_resources[--memno].flags = 0;
> -	}
> -}
> -
>  /* Decide whether to display the domain number in /proc */
>  int pci_proc_domain(struct pci_bus *bus)
>  {
> diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
> index 13e37e2..1626172 100644
> --- a/drivers/of/of_pci.c
> +++ b/drivers/of/of_pci.c
> @@ -4,6 +4,10 @@
>  #include <linux/of_pci.h>
>  #include <asm/prom.h>
>  
> +#if defined(CONFIG_PPC32) || defined(CONFIG_PPC64) || defined(CONFIG_MICROBLAZE)
> +#include <asm/pci-bridge.h>
> +#endif
> +
>  static inline int __of_pci_pci_compare(struct device_node *node,
>  				       unsigned int devfn)
>  {
> @@ -40,3 +44,199 @@ struct device_node *of_pci_find_child_device(struct device_node *parent,
>  	return NULL;
>  }
>  EXPORT_SYMBOL_GPL(of_pci_find_child_device);
> +
> +/**
> + * pci_process_bridge_OF_ranges - Parse PCI bridge resources from device tree
> + * @hose: newly allocated pci_controller to be setup
> + * @dev: device node of the host bridge
> + * @primary: set if primary bus (32 bits only, soon to be deprecated)
> + *
> + * This function will parse the "ranges" property of a PCI host bridge device
> + * node and setup the resource mapping of a pci controller based on its
> + * content.
> + *
> + * Life would be boring if it wasn't for a few issues that we have to deal
> + * with here:
> + *
> + *   - We can only cope with one IO space range and up to 3 Memory space
> + *     ranges. However, some machines (thanks Apple !) tend to split their
> + *     space into lots of small contiguous ranges. So we have to coalesce.
> + *
> + *   - We can only cope with all memory ranges having the same offset
> + *     between CPU addresses and PCI addresses. Unfortunately, some bridges
> + *     are setup for a large 1:1 mapping along with a small "window" which
> + *     maps PCI address 0 to some arbitrary high address of the CPU space in
> + *     order to give access to the ISA memory hole.
> + *     The way out of here that I've chosen for now is to always set the
> + *     offset based on the first resource found, then override it if we
> + *     have a different offset and the previous was set by an ISA hole.
> + *
> + *   - Some busses have IO space not starting at 0, which causes trouble with
> + *     the way we do our IO resource renumbering. The code somewhat deals with
> + *     it for 64 bits but I would expect problems on 32 bits.
> + *
> + *   - Some 32 bits platforms such as 4xx can have physical space larger than
> + *     32 bits so we need to use 64 bits values for the parsing
> + */
> +#if defined(CONFIG_PPC32) || defined(CONFIG_PPC64) || defined(CONFIG_MICROBLAZE)
> +void pci_process_bridge_OF_ranges(struct pci_controller *hose,
> +				  struct device_node *dev, int primary)
> +{
> +	const u32 *ranges;
> +	int rlen;
> +	int pna = of_n_addr_cells(dev);
> +	int np = pna + 5;
> +	int memno = 0, isa_hole = -1;
> +	u32 pci_space;
> +	unsigned long long pci_addr, cpu_addr, pci_next, cpu_next, size;
> +	unsigned long long isa_mb = 0;
> +	struct resource *res;
> +
> +	pr_info("PCI host bridge %s %s ranges:\n",
> +	       dev->full_name, primary ? "(primary)" : "");
> +
> +	/* Get ranges property */
> +	ranges = of_get_property(dev, "ranges", &rlen);
> +	if (ranges == NULL)
> +		return;
> +
> +	/* Parse it */
> +	pr_debug("Parsing ranges property...\n");
> +	while ((rlen -= np * 4) >= 0) {
> +		/* Read next ranges element */
> +		pci_space = ranges[0];
> +		pci_addr = of_read_number(ranges + 1, 2);
> +		cpu_addr = of_translate_address(dev, ranges + 3);
> +		size = of_read_number(ranges + pna + 3, 2);
> +
> +		pr_debug("pci_space: 0x%08x pci_addr:0x%016llx ",
> +				pci_space, pci_addr);
> +		pr_debug("cpu_addr:0x%016llx size:0x%016llx\n",
> +					cpu_addr, size);
> +
> +		ranges += np;
> +
> +		/* If we failed translation or got a zero-sized region
> +		 * (some FW try to feed us with non sensical zero sized regions
> +		 * such as power3 which look like some kind of attempt
> +		 * at exposing the VGA memory hole)
> +		 */
> +		if (cpu_addr == OF_BAD_ADDR || size == 0)
> +			continue;
> +
> +		/* Now consume following elements while they are contiguous */
> +		for (; rlen >= np * sizeof(u32);
> +		     ranges += np, rlen -= np * 4) {
> +			if (ranges[0] != pci_space)
> +				break;
> +			pci_next = of_read_number(ranges + 1, 2);
> +			cpu_next = of_translate_address(dev, ranges + 3);
> +			if (pci_next != pci_addr + size ||
> +			    cpu_next != cpu_addr + size)
> +				break;
> +			size += of_read_number(ranges + pna + 3, 2);
> +		}
> +
> +		/* Act based on address space type */
> +		res = NULL;
> +		switch ((pci_space >> 24) & 0x3) {
> +		case 1:		/* PCI IO space */
> +			pr_info("  IO 0x%016llx..0x%016llx -> 0x%016llx\n",
> +			       cpu_addr, cpu_addr + size - 1, pci_addr);
> +
> +			/* We support only one IO range */
> +			if (hose->pci_io_size) {
> +				pr_info(" \\--> Skipped (too many) !\n");
> +				continue;
> +			}
> +#if (!IS_ENABLED(CONFIG_64BIT))
> +			/* On 32 bits, limit I/O space to 16MB */
> +			if (size > 0x01000000)
> +				size = 0x01000000;
> +
> +			/* 32 bits needs to map IOs here */
> +			hose->io_base_virt = ioremap(cpu_addr, size);
> +
> +			/* Expect trouble if pci_addr is not 0 */
> +			if (primary)
> +				isa_io_base =
> +					(unsigned long)hose->io_base_virt;
> +#endif /* !CONFIG_64BIT */
> +			/* pci_io_size and io_base_phys always represent IO
> +			 * space starting at 0 so we factor in pci_addr
> +			 */
> +			hose->pci_io_size = pci_addr + size;
> +			hose->io_base_phys = cpu_addr - pci_addr;
> +
> +			/* Build resource */
> +			res = &hose->io_resource;
> +			res->flags = IORESOURCE_IO;
> +			res->start = pci_addr;
> +			break;
> +		case 2:		/* PCI Memory space */
> +		case 3:		/* PCI 64 bits Memory space */
> +			pr_info(" MEM 0x%016llx..0x%016llx -> 0x%016llx %s\n",
> +			       cpu_addr, cpu_addr + size - 1, pci_addr,
> +			       (pci_space & 0x40000000) ? "Prefetch" : "");
> +
> +			/* We support only 3 memory ranges */
> +			if (memno >= 3) {
> +				pr_info(" \\--> Skipped (too many) !\n");
> +				continue;
> +			}
> +			/* Handles ISA memory hole space here */
> +			if (pci_addr == 0) {
> +				isa_mb = cpu_addr;
> +				isa_hole = memno;
> +				if (primary || isa_mem_base == 0)
> +					isa_mem_base = cpu_addr;
> +				hose->isa_mem_phys = cpu_addr;
> +				hose->isa_mem_size = size;
> +			}
> +
> +			/* We get the PCI/Mem offset from the first range or
> +			 * the, current one if the offset came from an ISA
> +			 * hole. If they don't match, bugger.
> +			 */
> +			if (memno == 0 ||
> +			    (isa_hole >= 0 && pci_addr != 0 &&
> +			     hose->pci_mem_offset == isa_mb))
> +				hose->pci_mem_offset = cpu_addr - pci_addr;
> +			else if (pci_addr != 0 &&
> +				 hose->pci_mem_offset != cpu_addr - pci_addr) {
> +				pr_info(" \\--> Skipped (offset mismatch) !\n");
> +				continue;
> +			}
> +
> +			/* Build resource */
> +			res = &hose->mem_resources[memno++];
> +			res->flags = IORESOURCE_MEM;
> +			if (pci_space & 0x40000000)
> +				res->flags |= IORESOURCE_PREFETCH;
> +			res->start = cpu_addr;
> +			break;
> +		}
> +		if (res != NULL) {
> +			res->name = dev->full_name;
> +			res->end = res->start + size - 1;
> +			res->parent = NULL;
> +			res->sibling = NULL;
> +			res->child = NULL;
> +		}
> +	}
> +
> +	/* If there's an ISA hole and the pci_mem_offset is -not- matching
> +	 * the ISA hole offset, then we need to remove the ISA hole from
> +	 * the resource list for that brige
> +	 */
> +	if (isa_hole >= 0 && hose->pci_mem_offset != isa_mb) {
> +		unsigned int next = isa_hole + 1;
> +		pr_info(" Removing ISA hole at 0x%016llx\n", isa_mb);
> +		if (next < memno)
> +			memmove(&hose->mem_resources[isa_hole],
> +				&hose->mem_resources[next],
> +				sizeof(struct resource) * (memno - next));
> +		hose->mem_resources[--memno].flags = 0;
> +	}
> +}
> +#endif
> diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
> index bb115de..33e8ead 100644
> --- a/include/linux/of_pci.h
> +++ b/include/linux/of_pci.h
> @@ -11,4 +11,8 @@ struct device_node;
>  struct device_node *of_pci_find_child_device(struct device_node *parent,
>  					     unsigned int devfn);
>  
> +struct pci_controller;
> +void pci_process_bridge_OF_ranges(struct pci_controller *hose,
> +			struct device_node *dev, int primary);
> +
>  #endif



-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From grygorii.strashko at ti.com  Mon Apr 15 09:03:34 2013
From: grygorii.strashko at ti.com (Grygorii Strashko)
Date: Mon, 15 Apr 2013 16:03:34 +0300
Subject: [RFC v1 0/1] introduce regulator chain locking scheme
Message-ID: <1366031015-17073-1-git-send-email-grygorii.strashko@ti.com>

Hi Mark, Liam, All

Our target is to reuse common DVFS framework proposed by Mike Turquette
in http://lwn.net/Articles/540422/ and cpufreq-cpu0.c for all TI SoC and
minimize creation of any TI specific APIs or modules.
The common DVFS framework solution is based on assumption that Regulator,
connected to DVFS FW or CPU0 CPUFreq, is able to change requested voltage for
the corresponding Voltage domain (like CPU/MPU) by itself.
But most of TI SoCs, which support DVFS, have more complex voltage supply
schema as shown below:

  |------------|  |------------|
--| RegulatorY |--| CPU DVFS   |
  |------------|  |------------|
   \           \
    \           \_____________________________
     \                                        \
     |-------------------|  |---------------|  |---------|
   --| RegulatorX (PMIC) |--| Regulator AVS |--| ABB LDO |--
     |-------------------|  |---------------|  |---------|
		/|\				        |					
         |______________________|
         Voltage adjustment

and they need to configure, at least, internal ABB LDO befor/after
reconfiguring external voltage supplier in PMIC.
(as maximum - Regulator AVS (Adaptive voltage scaling) is needed to be
reconfigured after ABB LDO, and Regulator AVS may, finally, reconfigure external
voltage supplier with voltage value which is different from initially requested by DVFS).

for example (Vcur<Vreq):
- DVFS requests voltage change
- AVS converts Vreq to Vreq1 (say calibrated)
- AVS reconfigure RegulatorX (PMIC) to voltage Vreq1
- ABB LDO change type to FBB

This Regulator chaining scema can fit to Regulator framework very well
(from our point of view):
- DVFS: abb->set_voltage(Vreq)
- ABB: if (Vcur<Vreq)
			AVS->set_voltage(Vreq)
- AVS: PMIC->set_voltage(Vreq1)
- ABB: if (Vcur<Vreq)
			change type to FBB

But there are some limitations:
 - the whole Regulator chain need to be locked in case if any part of
   it has been accessed from outside;
 - child regulator should have access to set/get voltage methods of its 
   parent (supplier).

The proposed patches allow to remove these restrictions and they are inspired by
http://lwn.net/Articles/540422/.

Related dicussions:
 - regulator: query on regulator re-entrance 
   http://marc.info/?l=linux-omap&m=136513861315970&w=2
 - clk: notifier handler for dynamic voltage scaling
   https://lkml.org/lkml/2013/2/27/414

Tested on K3.8 OMAP4 SDP/T2 (ABB+vcvp regulator) and
OMAP5 sevm (ABB+smps123(i2c) regulator):
- cpu freq & voltages was scaled.

Could you please review and advise? Does anyone else interested in or have similar problems?

Grygorii Strashko (1):
  regulator: core: introduce regulator chain locking scheme

 drivers/regulator/core.c         |  134 ++++++++++++++++++++++++--------------
 include/linux/regulator/driver.h |    2 +
 2 files changed, 88 insertions(+), 48 deletions(-)

Regards
Grygorii Strashko

Cc: linux-kernel at vger.kernel.org (open list)
Cc: Mike Turquette <mturquette at linaro.org>
Cc: Tero Kristo <t-kristo at ti.com>
Cc: Nishanth Menon <nm at ti.com>
Cc: linux-omap <linux-omap at vger.kernel.org>
Cc: linux-arm <linux-arm-kernel at lists.infradead.org>
-- 
1.7.9.5



From grygorii.strashko at ti.com  Mon Apr 15 09:03:35 2013
From: grygorii.strashko at ti.com (Grygorii Strashko)
Date: Mon, 15 Apr 2013 16:03:35 +0300
Subject: [RFC v1] regulator: core: introduce regulator chain locking scheme
In-Reply-To: <1366031015-17073-1-git-send-email-grygorii.strashko@ti.com>
References: <1366031015-17073-1-git-send-email-grygorii.strashko@ti.com>
Message-ID: <1366031015-17073-2-git-send-email-grygorii.strashko@ti.com>

In some cases the regulators may be organized in a chain like:
  ->regA->regB->regC
where regA is supplier for regB and regB is supplier for regC.

Currently it would be possible to reconfigure regA and regC at same time
form different contexts, because each regulator has it own mutex.
But in some cases, the only the whole chain is allowed be reconfigured
because of dependencies between regulators - to change regB
configuration the regA need to be updated first.

Hence, introduce regulator chain locking scheme to lock whole Regulator
chain in case if any part of it has been accessed from outside.

To achieve this goal:
- abstract regulator locking out into helper functions;
- use the root Regulator (which has no supply defined, like regA) in chain to
  protect the whole chain;
- implement regulator chain locking scheme as proposed by Thomas Gleixner for CCF
  re-entrance in https://lkml.org/lkml/2013/3/27/171 and in the similar way as
  it is done for CCF by Mike Turquette in https://lkml.org/lkml/2013/3/28/512

In addition, such locking scheme allows to have access to the supplier
regulator API from inside child's (consumer) regulator API.

Cc: linux-kernel at vger.kernel.org
Cc: Mike Turquette <mturquette at linaro.org>
Cc: Nishanth Menon <nm at ti.com>
Cc: Tero Kristo <t-kristo at ti.com>
Cc: linux-omap <linux-omap at vger.kernel.org>
Cc: linux-arm <linux-arm-kernel at lists.infradead.org>

Signed-off-by: Grygorii Strashko <grygorii.strashko at ti.com>
---
 drivers/regulator/core.c         |  134 ++++++++++++++++++++++++--------------
 include/linux/regulator/driver.h |    2 +
 2 files changed, 88 insertions(+), 48 deletions(-)

diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index e3661c2..089cc63 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -110,6 +110,44 @@ static const char *rdev_get_name(struct regulator_dev *rdev)
 		return "";
 }
 
+static void regulator_lock(struct regulator_dev *rdev)
+{
+	struct regulator_dev *locking_rdev = rdev;
+
+	while (locking_rdev->supply)
+		locking_rdev = locking_rdev->supply->rdev;
+
+	if (!mutex_trylock(&locking_rdev->mutex)) {
+		if (locking_rdev->lock_owner == current) {
+			locking_rdev->lock_count++;
+			return;
+		}
+		mutex_lock(&locking_rdev->mutex);
+	}
+
+	WARN_ON_ONCE(locking_rdev->lock_owner != NULL);
+	WARN_ON_ONCE(locking_rdev->lock_count != 0);
+
+	locking_rdev->lock_count = 1;
+	locking_rdev->lock_owner = current;
+	dev_dbg(&locking_rdev->dev, "Is locked. locking %s\n",
+		rdev_get_name(rdev));
+}
+
+static void regulator_unlock(struct regulator_dev *rdev)
+{
+	struct regulator_dev *locking_rdev = rdev;
+
+	while (locking_rdev->supply)
+		locking_rdev = locking_rdev->supply->rdev;
+
+	if (--locking_rdev->lock_count)
+		return;
+
+	locking_rdev->lock_owner = NULL;
+	mutex_unlock(&locking_rdev->mutex);
+}
+
 /**
  * of_get_regulator - get a regulator device node based on supply name
  * @dev: Device pointer for the consumer (of regulator) device
@@ -292,9 +330,9 @@ static ssize_t regulator_uV_show(struct device *dev,
 	struct regulator_dev *rdev = dev_get_drvdata(dev);
 	ssize_t ret;
 
-	mutex_lock(&rdev->mutex);
+	regulator_lock(rdev);
 	ret = sprintf(buf, "%d\n", _regulator_get_voltage(rdev));
-	mutex_unlock(&rdev->mutex);
+	regulator_unlock(rdev);
 
 	return ret;
 }
@@ -357,9 +395,9 @@ static ssize_t regulator_state_show(struct device *dev,
 	struct regulator_dev *rdev = dev_get_drvdata(dev);
 	ssize_t ret;
 
-	mutex_lock(&rdev->mutex);
+	regulator_lock(rdev);
 	ret = regulator_print_state(buf, _regulator_is_enabled(rdev));
-	mutex_unlock(&rdev->mutex);
+	regulator_unlock(rdev);
 
 	return ret;
 }
@@ -467,10 +505,10 @@ static ssize_t regulator_total_uA_show(struct device *dev,
 	struct regulator *regulator;
 	int uA = 0;
 
-	mutex_lock(&rdev->mutex);
+	regulator_lock(rdev);
 	list_for_each_entry(regulator, &rdev->consumer_list, list)
 		uA += regulator->uA_load;
-	mutex_unlock(&rdev->mutex);
+	regulator_unlock(rdev);
 	return sprintf(buf, "%d\n", uA);
 }
 static DEVICE_ATTR(requested_microamps, 0444, regulator_total_uA_show, NULL);
@@ -1104,7 +1142,7 @@ static struct regulator *create_regulator(struct regulator_dev *rdev,
 	if (regulator == NULL)
 		return NULL;
 
-	mutex_lock(&rdev->mutex);
+	regulator_lock(rdev);
 	regulator->rdev = rdev;
 	list_add(&regulator->list, &rdev->consumer_list);
 
@@ -1156,12 +1194,12 @@ static struct regulator *create_regulator(struct regulator_dev *rdev,
 	    _regulator_is_enabled(rdev))
 		regulator->always_on = true;
 
-	mutex_unlock(&rdev->mutex);
+	regulator_unlock(rdev);
 	return regulator;
 overflow_err:
 	list_del(&regulator->list);
 	kfree(regulator);
-	mutex_unlock(&rdev->mutex);
+	regulator_unlock(rdev);
 	return NULL;
 }
 
@@ -1558,9 +1596,9 @@ int regulator_enable(struct regulator *regulator)
 			return ret;
 	}
 
-	mutex_lock(&rdev->mutex);
+	regulator_lock(rdev);
 	ret = _regulator_enable(rdev);
-	mutex_unlock(&rdev->mutex);
+	regulator_unlock(rdev);
 
 	if (ret != 0 && rdev->supply)
 		regulator_disable(rdev->supply);
@@ -1649,9 +1687,9 @@ int regulator_disable(struct regulator *regulator)
 	if (regulator->always_on)
 		return 0;
 
-	mutex_lock(&rdev->mutex);
+	regulator_lock(rdev);
 	ret = _regulator_disable(rdev);
-	mutex_unlock(&rdev->mutex);
+	regulator_unlock(rdev);
 
 	if (ret == 0 && rdev->supply)
 		regulator_disable(rdev->supply);
@@ -1695,10 +1733,10 @@ int regulator_force_disable(struct regulator *regulator)
 	struct regulator_dev *rdev = regulator->rdev;
 	int ret;
 
-	mutex_lock(&rdev->mutex);
+	regulator_lock(rdev);
 	regulator->uA_load = 0;
 	ret = _regulator_force_disable(regulator->rdev);
-	mutex_unlock(&rdev->mutex);
+	regulator_unlock(rdev);
 
 	if (rdev->supply)
 		while (rdev->open_count--)
@@ -1714,7 +1752,7 @@ static void regulator_disable_work(struct work_struct *work)
 						  disable_work.work);
 	int count, i, ret;
 
-	mutex_lock(&rdev->mutex);
+	regulator_lock(rdev);
 
 	BUG_ON(!rdev->deferred_disables);
 
@@ -1727,7 +1765,7 @@ static void regulator_disable_work(struct work_struct *work)
 			rdev_err(rdev, "Deferred disable failed: %d\n", ret);
 	}
 
-	mutex_unlock(&rdev->mutex);
+	regulator_unlock(rdev);
 
 	if (rdev->supply) {
 		for (i = 0; i < count; i++) {
@@ -1763,9 +1801,9 @@ int regulator_disable_deferred(struct regulator *regulator, int ms)
 	if (!ms)
 		return regulator_disable(regulator);
 
-	mutex_lock(&rdev->mutex);
+	regulator_lock(rdev);
 	rdev->deferred_disables++;
-	mutex_unlock(&rdev->mutex);
+	regulator_unlock(rdev);
 
 	ret = schedule_delayed_work(&rdev->disable_work,
 				    msecs_to_jiffies(ms));
@@ -1863,9 +1901,9 @@ int regulator_is_enabled(struct regulator *regulator)
 	if (regulator->always_on)
 		return 1;
 
-	mutex_lock(&regulator->rdev->mutex);
+	regulator_lock(regulator->rdev);
 	ret = _regulator_is_enabled(regulator->rdev);
-	mutex_unlock(&regulator->rdev->mutex);
+	regulator_unlock(regulator->rdev);
 
 	return ret;
 }
@@ -1983,9 +2021,9 @@ int regulator_list_voltage(struct regulator *regulator, unsigned selector)
 	if (!ops->list_voltage || selector >= rdev->desc->n_voltages)
 		return -EINVAL;
 
-	mutex_lock(&rdev->mutex);
+	regulator_lock(rdev);
 	ret = ops->list_voltage(rdev, selector);
-	mutex_unlock(&rdev->mutex);
+	regulator_unlock(rdev);
 
 	if (ret > 0) {
 		if (ret < rdev->constraints->min_uV)
@@ -2309,7 +2347,7 @@ int regulator_set_voltage(struct regulator *regulator, int min_uV, int max_uV)
 	int ret = 0;
 	int old_min_uV, old_max_uV;
 
-	mutex_lock(&rdev->mutex);
+	regulator_lock(rdev);
 
 	/* If we're setting the same range as last time the change
 	 * should be a noop (some cpufreq implementations use the same
@@ -2345,12 +2383,12 @@ int regulator_set_voltage(struct regulator *regulator, int min_uV, int max_uV)
 		goto out2;
 	
 out:
-	mutex_unlock(&rdev->mutex);
+	regulator_unlock(rdev);
 	return ret;
 out2:
 	regulator->min_uV = old_min_uV;
 	regulator->max_uV = old_max_uV;
-	mutex_unlock(&rdev->mutex);
+	regulator_unlock(rdev);
 	return ret;
 }
 EXPORT_SYMBOL_GPL(regulator_set_voltage);
@@ -2453,7 +2491,7 @@ int regulator_sync_voltage(struct regulator *regulator)
 	struct regulator_dev *rdev = regulator->rdev;
 	int ret, min_uV, max_uV;
 
-	mutex_lock(&rdev->mutex);
+	regulator_lock(rdev);
 
 	if (!rdev->desc->ops->set_voltage &&
 	    !rdev->desc->ops->set_voltage_sel) {
@@ -2482,7 +2520,7 @@ int regulator_sync_voltage(struct regulator *regulator)
 	ret = _regulator_do_set_voltage(rdev, min_uV, max_uV);
 
 out:
-	mutex_unlock(&rdev->mutex);
+	regulator_unlock(rdev);
 	return ret;
 }
 EXPORT_SYMBOL_GPL(regulator_sync_voltage);
@@ -2522,11 +2560,11 @@ int regulator_get_voltage(struct regulator *regulator)
 {
 	int ret;
 
-	mutex_lock(&regulator->rdev->mutex);
+	regulator_lock(regulator->rdev);
 
 	ret = _regulator_get_voltage(regulator->rdev);
 
-	mutex_unlock(&regulator->rdev->mutex);
+	regulator_unlock(regulator->rdev);
 
 	return ret;
 }
@@ -2554,7 +2592,7 @@ int regulator_set_current_limit(struct regulator *regulator,
 	struct regulator_dev *rdev = regulator->rdev;
 	int ret;
 
-	mutex_lock(&rdev->mutex);
+	regulator_lock(rdev);
 
 	/* sanity check */
 	if (!rdev->desc->ops->set_current_limit) {
@@ -2569,7 +2607,7 @@ int regulator_set_current_limit(struct regulator *regulator,
 
 	ret = rdev->desc->ops->set_current_limit(rdev, min_uA, max_uA);
 out:
-	mutex_unlock(&rdev->mutex);
+	regulator_unlock(rdev);
 	return ret;
 }
 EXPORT_SYMBOL_GPL(regulator_set_current_limit);
@@ -2578,7 +2616,7 @@ static int _regulator_get_current_limit(struct regulator_dev *rdev)
 {
 	int ret;
 
-	mutex_lock(&rdev->mutex);
+	regulator_lock(rdev);
 
 	/* sanity check */
 	if (!rdev->desc->ops->get_current_limit) {
@@ -2588,7 +2626,7 @@ static int _regulator_get_current_limit(struct regulator_dev *rdev)
 
 	ret = rdev->desc->ops->get_current_limit(rdev);
 out:
-	mutex_unlock(&rdev->mutex);
+	regulator_unlock(rdev);
 	return ret;
 }
 
@@ -2624,7 +2662,7 @@ int regulator_set_mode(struct regulator *regulator, unsigned int mode)
 	int ret;
 	int regulator_curr_mode;
 
-	mutex_lock(&rdev->mutex);
+	regulator_lock(rdev);
 
 	/* sanity check */
 	if (!rdev->desc->ops->set_mode) {
@@ -2648,7 +2686,7 @@ int regulator_set_mode(struct regulator *regulator, unsigned int mode)
 
 	ret = rdev->desc->ops->set_mode(rdev, mode);
 out:
-	mutex_unlock(&rdev->mutex);
+	regulator_unlock(rdev);
 	return ret;
 }
 EXPORT_SYMBOL_GPL(regulator_set_mode);
@@ -2657,7 +2695,7 @@ static unsigned int _regulator_get_mode(struct regulator_dev *rdev)
 {
 	int ret;
 
-	mutex_lock(&rdev->mutex);
+	regulator_lock(rdev);
 
 	/* sanity check */
 	if (!rdev->desc->ops->get_mode) {
@@ -2667,7 +2705,7 @@ static unsigned int _regulator_get_mode(struct regulator_dev *rdev)
 
 	ret = rdev->desc->ops->get_mode(rdev);
 out:
-	mutex_unlock(&rdev->mutex);
+	regulator_unlock(rdev);
 	return ret;
 }
 
@@ -2719,7 +2757,7 @@ int regulator_set_optimum_mode(struct regulator *regulator, int uA_load)
 	if (rdev->supply)
 		input_uV = regulator_get_voltage(rdev->supply);
 
-	mutex_lock(&rdev->mutex);
+	regulator_lock(rdev);
 
 	/*
 	 * first check to see if we can set modes at all, otherwise just
@@ -2780,7 +2818,7 @@ int regulator_set_optimum_mode(struct regulator *regulator, int uA_load)
 	}
 	ret = mode;
 out:
-	mutex_unlock(&rdev->mutex);
+	regulator_unlock(rdev);
 	return ret;
 }
 EXPORT_SYMBOL_GPL(regulator_set_optimum_mode);
@@ -2849,7 +2887,7 @@ int regulator_allow_bypass(struct regulator *regulator, bool enable)
 	    !(rdev->constraints->valid_ops_mask & REGULATOR_CHANGE_BYPASS))
 		return 0;
 
-	mutex_lock(&rdev->mutex);
+	regulator_lock(rdev);
 
 	if (enable && !regulator->bypass) {
 		rdev->bypass_count++;
@@ -2873,7 +2911,7 @@ int regulator_allow_bypass(struct regulator *regulator, bool enable)
 	if (ret == 0)
 		regulator->bypass = enable;
 
-	mutex_unlock(&rdev->mutex);
+	regulator_unlock(rdev);
 
 	return ret;
 }
@@ -3588,9 +3626,9 @@ int regulator_suspend_prepare(suspend_state_t state)
 	mutex_lock(&regulator_list_mutex);
 	list_for_each_entry(rdev, &regulator_list, list) {
 
-		mutex_lock(&rdev->mutex);
+		regulator_lock(rdev);
 		ret = suspend_prepare(rdev, state);
-		mutex_unlock(&rdev->mutex);
+		regulator_unlock(rdev);
 
 		if (ret < 0) {
 			rdev_err(rdev, "failed to prepare\n");
@@ -3618,7 +3656,7 @@ int regulator_suspend_finish(void)
 	list_for_each_entry(rdev, &regulator_list, list) {
 		struct regulator_ops *ops = rdev->desc->ops;
 
-		mutex_lock(&rdev->mutex);
+		regulator_lock(rdev);
 		if ((rdev->use_count > 0  || rdev->constraints->always_on) &&
 				ops->enable) {
 			error = ops->enable(rdev);
@@ -3637,7 +3675,7 @@ int regulator_suspend_finish(void)
 				ret = error;
 		}
 unlock:
-		mutex_unlock(&rdev->mutex);
+		regulator_unlock(rdev);
 	}
 	mutex_unlock(&regulator_list_mutex);
 	return ret;
@@ -3825,7 +3863,7 @@ static int __init regulator_init_complete(void)
 		if (!ops->disable || (c && c->always_on))
 			continue;
 
-		mutex_lock(&rdev->mutex);
+		regulator_lock(rdev);
 
 		if (rdev->use_count)
 			goto unlock;
@@ -3857,7 +3895,7 @@ static int __init regulator_init_complete(void)
 		}
 
 unlock:
-		mutex_unlock(&rdev->mutex);
+		regulator_unlock(rdev);
 	}
 
 	mutex_unlock(&regulator_list_mutex);
diff --git a/include/linux/regulator/driver.h b/include/linux/regulator/driver.h
index 7df93f5..6bfa2af 100644
--- a/include/linux/regulator/driver.h
+++ b/include/linux/regulator/driver.h
@@ -289,6 +289,8 @@ struct regulator_dev {
 
 	struct blocking_notifier_head notifier;
 	struct mutex mutex; /* consumer lock */
+	struct task_struct *lock_owner; /* consumer thread context */
+	int lock_count; /* number of recursive locks taken */
 	struct module *owner;
 	struct device dev;
 	struct regulation_constraints *constraints;
-- 
1.7.9.5



From cov at codeaurora.org  Mon Apr 15 09:09:20 2013
From: cov at codeaurora.org (Christopher Covington)
Date: Mon, 15 Apr 2013 09:09:20 -0400
Subject: [PATCH v2] arm64: Fix task tracing
In-Reply-To: <20130415114307.GC29528@arm.com>
References: <20130408153132.GQ17476@mudshark.cambridge.arm.com>
 <1365510814-21343-1-git-send-email-cov@codeaurora.org>
 <20130415101159.GA25095@localhost.cambridge.arm.com>
 <20130415104542.GE9827@mudshark.cambridge.arm.com>
 <20130415105840.GB29528@arm.com> <20130415114307.GC29528@arm.com>
Message-ID: <516BFC00.5050700@codeaurora.org>

Hi Catalin,

On 04/15/2013 07:43 AM, Catalin Marinas wrote:
> On Mon, Apr 15, 2013 at 11:58:40AM +0100, Catalin Marinas wrote:
>> On Mon, Apr 15, 2013 at 11:45:42AM +0100, Will Deacon wrote:
>>> On Mon, Apr 15, 2013 at 11:11:59AM +0100, Catalin Marinas wrote:
>>>> On Tue, Apr 09, 2013 at 01:33:34PM +0100, Christopher Covington wrote:
>>>>> For accurate accounting pass contextidr_thread_switch the prev
>>>>> task pointer, since cpu_switch_to has at that point changed the
>>>>> the stack pointer.
>>>>>
>>>>> Signed-off-by: Christopher Covington <cov at codeaurora.org>
>>>>> ---
>>>>>  arch/arm64/kernel/process.c | 2 +-
>>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
>>>>> index 0337cdb..a49b25a 100644
>>>>> --- a/arch/arm64/kernel/process.c
>>>>> +++ b/arch/arm64/kernel/process.c
>>>>> @@ -315,7 +315,7 @@ struct task_struct *__switch_to(struct task_struct *prev,
>>>>>  	/* the actual thread switch */
>>>>>  	last = cpu_switch_to(prev, next);
>>>>>  
>>>>> -	contextidr_thread_switch(next);
>>>>> +	contextidr_thread_switch(prev);
>>>>
>>>> The original code was indeed wrong but using prev isn't any better. For
>>>> a newly created thread, prev is probably 0 (if it's in a register,
>>>> cpu_context has been zeroed by copy_thread()) or some random stack
>>>> value.

<nit>
I have to I disagree with the statement that using prev isn't _any_ better.
Even if there are unhandled cases, from my observations, using prev is
_measurably_ better. On the other hand, I agree that 100% accuracy is essential.
</nit>

>>> Really? If prev is NULL in context_switch(...), the scheduler will implode,
>>> and I can't see where else switch_to is called from.
>>>
>>> Which code path are you thinking of?
>>
>> copy_thread() zeros cpu_context which is used by cpu_switch_to() to load
>> the next saved registers. The switch_to() function sets prev to last as
>> returned by __switch_to(), so this is valid but in __switch_to() we
>> don't have a valid prev (nor next) after cpu_switch_to() for newly
>> created threads.
> 
> Correction - newly created threads return to ret_from_fork rather than
> __switch_to(), which means that we miss the first
> contextidr_thread_switch() call for a new thread. I would vote for
> Christopher's original patch moving the call before cpu_switch_to(). The
> alternative is to define finish_arch_switch() and add the call there. If
> you are primarily tracing user space, it doesn't really matter whether
> the stack was switched or not when we set the contextidr. For kernel
> tracking, it could be a problem as we have the next task with the old
> stack. But the same could be said about the prev task with the new
> stack.

I'm fine with using either of my previous patches (or are there still cases
where the second one is suspected to be wrong?) or rolling a new one using
finish_arch_switch(). Let me know if you all would prefer for me to start on
the latter.

Christopher

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by the Linux Foundation.


From eric at eukrea.com  Mon Apr 15 09:13:16 2013
From: eric at eukrea.com (Eric =?UTF-8?B?QsOpbmFyZA==?=)
Date: Mon, 15 Apr 2013 15:13:16 +0200
Subject: [PATCH v3 2/2] video: imxfb: Add DT support
In-Reply-To: <20130415124321.GB15139@game.jcrosoft.org>
References: <1365157876-1757-1-git-send-email-mpa@pengutronix.de>
 <1365157876-1757-3-git-send-email-mpa@pengutronix.de>
 <20130408075742.GR20693@game.jcrosoft.org>
 <20130414143132.GD27394@pengutronix.de>
 <20130415124321.GB15139@game.jcrosoft.org>
Message-ID: <20130415151316.4d49e9b2@e6520eb>

Hi,

Le Mon, 15 Apr 2013 14:43:21 +0200,
Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com> a ?crit :

> On 16:31 Sun 14 Apr     , Markus Pargmann wrote:
> > On Mon, Apr 08, 2013 at 09:57:42AM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > > On 12:31 Fri 05 Apr     , Markus Pargmann wrote:
> > > > Add devicetree support for imx framebuffer driver. It uses the generic
> > > > display bindings and helper functions.
> > > > 
> > > > Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
> > > > Cc: Fabio Estevam <festevam at gmail.com>
> > > > Cc: Mark Rutland <mark.rutland at arm.com>
> > > > ---
> > > >  .../devicetree/bindings/video/fsl,imx-fb.txt       |  49 ++++++
> > > >  drivers/video/imxfb.c                              | 192 +++++++++++++++++----
> > > >  2 files changed, 207 insertions(+), 34 deletions(-)
> > > >  create mode 100644 Documentation/devicetree/bindings/video/fsl,imx-fb.txt
> > > > 
> > > > diff --git a/Documentation/devicetree/bindings/video/fsl,imx-fb.txt b/Documentation/devicetree/bindings/video/fsl,imx-fb.txt
> > > > new file mode 100644
> > > > index 0000000..bde9c77
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/video/fsl,imx-fb.txt
> > > > @@ -0,0 +1,49 @@
> > > > +Freescale imx21 Framebuffer
> > > > +
> > > > +This framebuffer driver supports devices imx1, imx21, imx25, and imx27.
> > > > +
> > > > +Required properties:
> > > > +- compatible : "fsl,<chip>-fb", chip should be imx1 or imx21
> > > > +- reg : Should contain 1 register ranges(address and length)
> > > > +- interrupts : One interrupt of the fb dev
> > > > +
> > > > +Required nodes:
> > > > +- display: Phandle to a display node as described in
> > > > +	Documentation/devicetree/bindings/video/display-timing.txt
> > > > +	Additional, the display node has to define properties:
> > > > +	- fsl,bpp: Bits per pixel
> > > > +	- fsl,pcr: LCDC PCR value
> > > > +
> > > > +Optional properties:
> > > > +- dmacr-eukrea: Should be set for eukrea boards.
> > > why ?
> > 
> > Because eukrea boards have a different dmacr then all other boards using
> > imxfb. The dmacr address is hardcoded as defaults in the code. I could
> > also search for the board name in the DT, but there are no eukrea boards
> > with DT at the moment, so I thought a bool property may be better for
> > the moment.
> so no if an other board come will have an other property no
> 
> add an optionnal option to pass the dmacr

I didn't follow the thread but dmacr is not specific to our boards :
$ grep -rn dmacr arch/arm/mach-imx/
arch/arm/mach-imx/mach-mx27_3ds.c:446:	.dmacr		= 0x00020010,
arch/arm/mach-imx/mach-mx21ads.c:231:	.dmacr		= 0x00020008,
arch/arm/mach-imx/mach-mxt_td60.c:210:	.dmacr		= 0x00020010,
arch/arm/mach-imx/eukrea_mbimx27-baseboard.c:192:	.dmacr		= 0x00040060,
arch/arm/mach-imx/eukrea_mbimxsd25-baseboard.c:165:	.dmacr		= 0x00040060,
arch/arm/mach-imx/mach-mx27ads.c:241:	.dmacr		= 0x00020010,
arch/arm/mach-imx/mach-pca100.c:351:	.dmacr		= 0x00020010,
arch/arm/mach-imx/pcm970-baseboard.c:185:	.dmacr		= 0x00020010,
arch/arm/mach-imx/mach-mx25_3ds.c:173:	.dmacr		= 0x00020010,

Best regards,
Eric


From will.deacon at arm.com  Mon Apr 15 09:13:41 2013
From: will.deacon at arm.com (Will Deacon)
Date: Mon, 15 Apr 2013 14:13:41 +0100
Subject: [PATCH] documentation: iommu: add description of ARM System MMU
 binding
In-Reply-To: <5169C7D1.8070300@codeaurora.org>
References: <1365094259-24847-1-git-send-email-will.deacon@arm.com>
 <515F37C1.4000109@codeaurora.org>
 <20130408092535.GA17476@mudshark.cambridge.arm.com>
 <5162F87A.7070409@codeaurora.org>
 <20130410173732.GQ26992@mudshark.cambridge.arm.com>
 <5169C7D1.8070300@codeaurora.org>
Message-ID: <20130415131341.GG9827@mudshark.cambridge.arm.com>

On Sat, Apr 13, 2013 at 10:02:09PM +0100, Olav Haugan wrote:
> Hi again Will,

Hello Olav,

> On 4/10/2013 10:37 AM, Will Deacon wrote:
> > Ok, but then how does that interact with the IOMMU API in Linux? e.g.
> > if a client asks for an iova <-> pa mapping on a device, then you
> > need to lookup the StreamIDs for that device, no?
> 
> Can you explain this use case a bit more. I am not clear what you mean
> by a "client"? Are you referring to a client in Linux or are you
> referring to the client being the core behind an IOMMU (such as a DMA
> engine or a video core)?

Sure. By `client', I mean any use of the IOMMU API. It could be something
like your LVD example later on, it could be KVM or it could be indirectly
via dma-mapping. Basically, any user of <linux/iommu.h>.

> I am not sure how StreamIDs relates to the IOMMU API in Linux :-)

That's the thing; they don't, at least not explicitly. The StreamIDs must
all be handled inside the driver and it's actually what the driver would
deal with, rather than devices.

For example, if I create an IOMMU domain containing a DMA controller, that
means that I have associated a set of StreamIDs (i.e. those configured to
identify the DMA controller's master ports) with that domain. That may have
further consequences on which other devices can be put in the same domain
(stream-matching may require some IDs to sit in the same address space/domain)
and also effectively parameterises the domain, by pointing those StreamIDs
at the same context bank.

> I think it helps if I explain my use case to you so you understand how
> we use the IOMMU and maybe you can explain your use case and how your
> driver works so that we can get on the same page. BTW, our ARMv1 IOMMU
> driver can be found @ [1]
> 
> Our use case:
> 
> 1) During boot IOMMU HW is probed, devices for each IOMMU and for each
> context bank are created.

So you create a device for each context bank...

> 2) Video session starts.
> 3) Linux Video Driver (LVD) creates one or more domain
> (iommu_domain_alloc) and calls iommu_attach_device() for each context
> bank it is going to use.

...and attach the context bank to the domain dynamically?

If so, doesn't that strongly tie your video driver to the SMMU?

> 4) LVD then calls map as needed for the buffers that the video core
> needs to access.
> 5) LVD shares IOVA with video core and kicks off video core decoding.
> 6) Video session ends.
> 7) LVD unmaps
> 8) LVD detaches.
> 
> The video driver selects context bank to attach to based on the use case
> and does not know about StreamIDs really.
> 
> BTW, when you call iommu_attach_device() what "device" do you pass as
> argument? Do you pass the IOMMU as a device? How do you specify which
> Context Bank to attach to?

This seems to be where we differ. My anticipated use-case is that a domain
is allocated, which defines an empty address space. Masters are then
attached to the domain by passing their struct device, so this may
correspond to a DMA controller or a video core, in your case. The context
bank is allocated dynamically when the first device is added to the
domain, and then it is subsequently shared between all the masters in that
domain.

I think this also matches what dma-mapping.c expects.

> > Why can't the secure world just hide those context banks by using 
> > SMMU_SCR1.NSNUMCBO?
> 
> Yes, that is a possibility for context banks. If you have 1 or more
> "secure" context banks it also means that Linux does not have access
> (read: can't have) to the global register space and this must be
> communicated somehow (hence the "secure-id" IOMMU node property. The
> secure-context property might be redundant. However, there might be use
> cases were Linux would want to know about the secure context bank. One
> such use case could be to register for page fault from the secure
> context bank so that Linux can log a useful page fault message to the
> kernel log.

Perhaps, but I don't think it's worth complicating the binding based on a
potential nice-to-have fault message.

Will


From andre.przywara at linaro.org  Mon Apr 15 09:13:55 2013
From: andre.przywara at linaro.org (Andre Przywara)
Date: Mon, 15 Apr 2013 15:13:55 +0200
Subject: [PATCH] ARM: KVM: iterate over all CPUs for CPU compatibility
 check
In-Reply-To: <CAJRNFKJoBzgt4UhxsH65_LyhcGXPnzB_pg3q-zeYT2OVv59q4A@mail.gmail.com>
References: <1365771875-5788-1-git-send-email-andre.przywara@linaro.org>
 <51680AF9.7040109@arm.com>
 <CAEDV+g+E8PLc60vMRhq4O_AL2WjmYDLb6=Wh34ynhevh7uAGJA@mail.gmail.com>
 <d455f2823b9639af8d38d30f2c3234bd@localhost>
 <CAEDV+gJuFG49oQ=BEaCHcTP=nHVyX8ALw6076dR_C1s7TuyqXQ@mail.gmail.com>
 <d47697abd39a0d5d41f5ac110a40e261@localhost>
 <CAEDV+gK9==sXYxRVZ8JVFYPiw3_xgzZBbydEwPunmnocNLKXrQ@mail.gmail.com>
 <CAFEAcA-bPoa8YoPuHPmupzfUW+yR233XquK79eNorzcRpFiK=g@mail.gmail.com>
 <516BCAD0.9000708@linaro.org>
 <CAJRNFKJoBzgt4UhxsH65_LyhcGXPnzB_pg3q-zeYT2OVv59q4A@mail.gmail.com>
Message-ID: <516BFD13.1000400@linaro.org>

On 04/15/2013 11:52 AM, Alexander Spyridakis wrote:
> On 15 April 2013 11:39, Andre Przywara <andre.przywara at linaro.org
> <mailto:andre.przywara at linaro.org>> wrote:
>
>      > [Q: does
>      >     all the hyp mode code have to also run on the A15s or
>      >     is it A7-safe?]
>
>     Good point. It seems like the code hangs in init_hyp_mode().
>     Will do more debugging in there now.
>
>
> I've run on this problem before, while trying to run KVM guests on A7 cores.
>
> For some reason the 3rd A7 hangs in arch/arm/kvm/init.S, on the
> instruction that updates HSCTLR between the two isbs on __do_hyp_init
> (mcr p15, 4, r0, c1, c0, 0). If you boot the system with maxcpus=4 then
> init_hyp_mode() will not hang on the A7 cluster. Other than that from my
> limited testing KVM on A7 works on a usual linux guest. I also tried to
> only boot the 3rd A7 core to rule out any racing issues, but still the
> same behaviour applies.

Could well be the same issue here. I chased it down till CPU 2 goes into 
HYP mode to do the initialization.
I am running with maxcpus=3 (this increases the likelyhood that 
kvm_target_cpu() runs on an A15), so CPU #2 is the only one A7.
As the HYP mode exception table is empty except for the HVC trap, it may 
be looping here. I am trying now to get the PC of the faulty instruction.


(on a TC2: 0-1: A15, 2-4: A7)
kvm_target_cpu() on CPU #1, part is c0f0
kvm [1]: entering init_hyp_mode on CPU 1
kvm [1]: kvm_mmu_init() returned 0 on CPU 1
kvm [1]: hyp_get_vectors() finished on CPU 1
kvm [1]: allocated stack for HV mode on 5 CPUs, now on CPU 1
kvm [0]: entering cpu_init_hyp_mode(8050fde0) on CPU 0
kvm [0]: c_i_h_m: set vectors finished
kvm [0]: c_i_h_m: initialization of local variables finished
kvm [0]: c_i_h_m: kvm_call_hyp() finished, returning...
kvm [1]: entering cpu_init_hyp_mode(8050fde0) on CPU 1
kvm [1]: c_i_h_m: set vectors finished
kvm [1]: c_i_h_m: initialization of local variables finished
kvm [1]: c_i_h_m: kvm_call_hyp() finished, returning...
kvm [0]: entering cpu_init_hyp_mode(8050fde0) on CPU 2
kvm [0]: c_i_h_m: set vectors finished
kvm [0]: c_i_h_m: initialization of local variables finished


Regards,
Andre.



From will.deacon at arm.com  Mon Apr 15 09:19:52 2013
From: will.deacon at arm.com (Will Deacon)
Date: Mon, 15 Apr 2013 14:19:52 +0100
Subject: [PATCH v2] arm64: Fix task tracing
In-Reply-To: <20130415114307.GC29528@arm.com>
References: <20130408153132.GQ17476@mudshark.cambridge.arm.com>
 <1365510814-21343-1-git-send-email-cov@codeaurora.org>
 <20130415101159.GA25095@localhost.cambridge.arm.com>
 <20130415104542.GE9827@mudshark.cambridge.arm.com>
 <20130415105840.GB29528@arm.com> <20130415114307.GC29528@arm.com>
Message-ID: <20130415131952.GH9827@mudshark.cambridge.arm.com>

On Mon, Apr 15, 2013 at 12:43:07PM +0100, Catalin Marinas wrote:
> On Mon, Apr 15, 2013 at 11:58:40AM +0100, Catalin Marinas wrote:
> > On Mon, Apr 15, 2013 at 11:45:42AM +0100, Will Deacon wrote:
> > > Really? If prev is NULL in context_switch(...), the scheduler will implode,
> > > and I can't see where else switch_to is called from.
> > > 
> > > Which code path are you thinking of?
> > 
> > copy_thread() zeros cpu_context which is used by cpu_switch_to() to load
> > the next saved registers. The switch_to() function sets prev to last as
> > returned by __switch_to(), so this is valid but in __switch_to() we
> > don't have a valid prev (nor next) after cpu_switch_to() for newly
> > created threads.
> 
> Correction - newly created threads return to ret_from_fork rather than
> __switch_to(), which means that we miss the first
> contextidr_thread_switch() call for a new thread. I would vote for
> Christopher's original patch moving the call before cpu_switch_to(). The
> alternative is to define finish_arch_switch() and add the call there. If
> you are primarily tracing user space, it doesn't really matter whether
> the stack was switched or not when we set the contextidr. For kernel
> tracking, it could be a problem as we have the next task with the old
> stack. But the same could be said about the prev task with the new
> stack.

The sp defines the current task, which is what the debugger will be
interested in and will likely try to correlate with the PID reported in
the contextidr, so I still maintain that it's important for these to be
in sync.

Will


From grant.likely at secretlab.ca  Mon Apr 15 09:27:37 2013
From: grant.likely at secretlab.ca (Grant Likely)
Date: Mon, 15 Apr 2013 14:27:37 +0100
Subject: [PATCH V4 10/18] ARM: OMAP2+: Add function to read GPMC settings
 from device-tree
In-Reply-To: <1363710956-26773-11-git-send-email-jon-hunter@ti.com>
References: <1363710956-26773-1-git-send-email-jon-hunter@ti.com>
 <1363710956-26773-11-git-send-email-jon-hunter@ti.com>
Message-ID: <20130415132737.A2A6E3E0AA8@localhost>

On Tue, 19 Mar 2013 11:35:48 -0500, Jon Hunter <jon-hunter at ti.com> wrote:
> Adds a function to read the various GPMC chip-select settings from
> device-tree and store them in the gpmc_settings structure.
> 
> Update the GPMC device-tree binding documentation to describe these
> options.
> 
> Signed-off-by: Jon Hunter <jon-hunter at ti.com>
> Tested-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
> ---
>  Documentation/devicetree/bindings/bus/ti-gpmc.txt |   23 ++++++++++++
>  arch/arm/mach-omap2/gpmc.c                        |   40 +++++++++++++++++++++
>  arch/arm/mach-omap2/gpmc.h                        |    2 ++
>  3 files changed, 65 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/bus/ti-gpmc.txt b/Documentation/devicetree/bindings/bus/ti-gpmc.txt
> index 5ddb2e9..6fde1cf 100644
> --- a/Documentation/devicetree/bindings/bus/ti-gpmc.txt
> +++ b/Documentation/devicetree/bindings/bus/ti-gpmc.txt
> @@ -65,6 +65,29 @@ The following are only applicable to OMAP3+ and AM335x:
>   - gpmc,wr-access
>   - gpmc,wr-data-mux-bus
>  
> +GPMC chip-select settings properties for child nodes. All are optional.
> +
> +- gpmc,burst-length	Page/burst length. Must be 4, 8 or 16.
> +- gpmc,burst-wrap	Enables wrap bursting
> +- gpmc,burst-read	Enables read page/burst mode
> +- gpmc,burst-write	Enables write page/burst mode
> +- gpmc,device-nand	Device is NAND
> +- gpmc,device-width	Total width of device(s) connected to a GPMC
> +			chip-select in bytes. The GPMC supports 8-bit
> +			and 16-bit devices and so this property must be
> +			1 or 2.

I would suggest specifying the actual number of bits. ie. 8 or 16. There is some
precidence for that already in DT bindings.

> +- gpmc,mux-add-data	Address and data multiplexing configuration.
> +			Valid values are 1 for address-address-data
> +			multiplexing mode and 2 for address-data
> +			multiplexing mode.
> +- gpmc,sync-read	Enables synchronous read. Defaults to asynchronous
> +			is this is not set.

'if'?

> +- gpmc,sync-write	Enables synchronous writes. Defaults to asynchronous
> +			is this is not set.
> +- gpmc,wait-pin		Wait-pin used by client. Must be less than
> +			"gpmc,num-waitpins".
> +- gpmc,wait-on-read	Enables wait monitoring on reads.
> +- gpmc,wait-on-write	Enables wait monitoring on writes.

Otherwise looks okay to me.

g.



From plagnioj at jcrosoft.com  Mon Apr 15 09:23:22 2013
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Mon, 15 Apr 2013 15:23:22 +0200
Subject: [PATCH v3 2/2] video: imxfb: Add DT support
In-Reply-To: <20130415151316.4d49e9b2@e6520eb>
References: <1365157876-1757-1-git-send-email-mpa@pengutronix.de>
 <1365157876-1757-3-git-send-email-mpa@pengutronix.de>
 <20130408075742.GR20693@game.jcrosoft.org>
 <20130414143132.GD27394@pengutronix.de>
 <20130415124321.GB15139@game.jcrosoft.org>
 <20130415151316.4d49e9b2@e6520eb>
Message-ID: <20130415132322.GC15139@game.jcrosoft.org>

On 15:13 Mon 15 Apr     , Eric B?nard wrote:
> Hi,
> 
> Le Mon, 15 Apr 2013 14:43:21 +0200,
> Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com> a ?crit :
> 
> > On 16:31 Sun 14 Apr     , Markus Pargmann wrote:
> > > On Mon, Apr 08, 2013 at 09:57:42AM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > > > On 12:31 Fri 05 Apr     , Markus Pargmann wrote:
> > > > > Add devicetree support for imx framebuffer driver. It uses the generic
> > > > > display bindings and helper functions.
> > > > > 
> > > > > Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
> > > > > Cc: Fabio Estevam <festevam at gmail.com>
> > > > > Cc: Mark Rutland <mark.rutland at arm.com>
> > > > > ---
> > > > >  .../devicetree/bindings/video/fsl,imx-fb.txt       |  49 ++++++
> > > > >  drivers/video/imxfb.c                              | 192 +++++++++++++++++----
> > > > >  2 files changed, 207 insertions(+), 34 deletions(-)
> > > > >  create mode 100644 Documentation/devicetree/bindings/video/fsl,imx-fb.txt
> > > > > 
> > > > > diff --git a/Documentation/devicetree/bindings/video/fsl,imx-fb.txt b/Documentation/devicetree/bindings/video/fsl,imx-fb.txt
> > > > > new file mode 100644
> > > > > index 0000000..bde9c77
> > > > > --- /dev/null
> > > > > +++ b/Documentation/devicetree/bindings/video/fsl,imx-fb.txt
> > > > > @@ -0,0 +1,49 @@
> > > > > +Freescale imx21 Framebuffer
> > > > > +
> > > > > +This framebuffer driver supports devices imx1, imx21, imx25, and imx27.
> > > > > +
> > > > > +Required properties:
> > > > > +- compatible : "fsl,<chip>-fb", chip should be imx1 or imx21
> > > > > +- reg : Should contain 1 register ranges(address and length)
> > > > > +- interrupts : One interrupt of the fb dev
> > > > > +
> > > > > +Required nodes:
> > > > > +- display: Phandle to a display node as described in
> > > > > +	Documentation/devicetree/bindings/video/display-timing.txt
> > > > > +	Additional, the display node has to define properties:
> > > > > +	- fsl,bpp: Bits per pixel
> > > > > +	- fsl,pcr: LCDC PCR value
> > > > > +
> > > > > +Optional properties:
> > > > > +- dmacr-eukrea: Should be set for eukrea boards.
> > > > why ?
> > > 
> > > Because eukrea boards have a different dmacr then all other boards using
> > > imxfb. The dmacr address is hardcoded as defaults in the code. I could
> > > also search for the board name in the DT, but there are no eukrea boards
> > > with DT at the moment, so I thought a bool property may be better for
> > > the moment.
> > so no if an other board come will have an other property no
> > 
> > add an optionnal option to pass the dmacr
> 
> I didn't follow the thread but dmacr is not specific to our boards :
> $ grep -rn dmacr arch/arm/mach-imx/
> arch/arm/mach-imx/mach-mx27_3ds.c:446:	.dmacr		= 0x00020010,
> arch/arm/mach-imx/mach-mx21ads.c:231:	.dmacr		= 0x00020008,
> arch/arm/mach-imx/mach-mxt_td60.c:210:	.dmacr		= 0x00020010,
> arch/arm/mach-imx/eukrea_mbimx27-baseboard.c:192:	.dmacr		= 0x00040060,
> arch/arm/mach-imx/eukrea_mbimxsd25-baseboard.c:165:	.dmacr		= 0x00040060,
> arch/arm/mach-imx/mach-mx27ads.c:241:	.dmacr		= 0x00020010,
> arch/arm/mach-imx/mach-pca100.c:351:	.dmacr		= 0x00020010,
> arch/arm/mach-imx/pcm970-baseboard.c:185:	.dmacr		= 0x00020010,
> arch/arm/mach-imx/mach-mx25_3ds.c:173:	.dmacr		= 0x00020010,

with this it even more clear nack on the dmacr-eukrea property

use an optional property where we can specify the value to use

Best Regsrds,
J.


From hechtb at gmail.com  Mon Apr 15 09:29:33 2013
From: hechtb at gmail.com (Bastian Hecht)
Date: Mon, 15 Apr 2013 15:29:33 +0200
Subject: [PATCH v2 1/2] ARM: shmobile: r8a7740: Add Suspend-To-RAM A3SM
In-Reply-To: <CABYn4szh7WZSCZn-xskyEW+J6+YGL0n9ueqAA3MX-fAhyjsLsA@mail.gmail.com>
References: <1365689264-14410-1-git-send-email-hechtb+renesas@gmail.com>
 <20130412142649.GE6637@e102568-lin.cambridge.arm.com>
 <CABYn4szh7WZSCZn-xskyEW+J6+YGL0n9ueqAA3MX-fAhyjsLsA@mail.gmail.com>
Message-ID: <CABYn4sz6GXX0OTcNK40_+4pbxoJmupcGc=-FOmSBGFULtE5fbA@mail.gmail.com>

2013/4/15 Bastian Hecht <hechtb at gmail.com>:
> Hello Lorenzo,
>
> thanks for the review.
>
> 2013/4/12 Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>:
>> On Thu, Apr 11, 2013 at 03:07:43PM +0100, Bastian Hecht wrote:
>>
>> [...]
>>
>>> diff --git a/arch/arm/mach-shmobile/sleep-r8a7740.S b/arch/arm/mach-shmobile/sleep-r8a7740.S
>>> new file mode 100644
>>> index 0000000..762f978
>>> --- /dev/null
>>> +++ b/arch/arm/mach-shmobile/sleep-r8a7740.S
>>> @@ -0,0 +1,72 @@
>>> +/*
>>> + * Low level sleep code for the SoC r8a7740
>>> + *
>>> + * Copyright (C) 2013 Bastian Hecht
>>> + *
>>> + * This file is subject to the terms and conditions of the GNU General Public
>>> + * License.  See the file "COPYING" in the main directory of this archive
>>> + * for more details.
>>> + */
>>> +
>>> +#include <linux/linkage.h>
>>> +#include <linux/init.h>
>>> +#include <asm/memory.h>
>>> +
>>> +#ifdef CONFIG_SUSPEND
>>> +
>>> +/* r8a7740_shutdown expects L2 to be flushed */
>>> +     .text
>>> +ENTRY(r8a7740_shutdown)
>>> +     stmfd   sp!, {r4-r12, lr}
>>> +
>>> +     /* make sure the stack stays intact */
>>> +     bl      v7_flush_dcache_all
>>> +
>>
>> Why do not you move the cache flush above after clearing the C bit ?
>> You must not push on the stack _after_ clearing the C bit and before
>> cleaning the cache, that's the only requirement (well basically you
>> should not write any data and do not rely on any dirty data sitting
>> in the cache, since with the C bit cleared as I already said A9 L1
>> D-cache is not searched).
>>
>> AS long as, with C bit cleared, you do NOT push on the stack before
>> cleaning the cache, your cache flushing routine will clean data to DRAM,
>> so you are fine. v7_flush_dcache_all does not use the stack.
>>
>>         mrc     p15, 0, r0, c1, c0, 0
>>         bic     r0, r0, #(1 << 2)               @ Disable the C bit
>>         mcr     p15, 0, r0, c1, c0, 0
>>         isb
>>         bl      v7_flush_dcache_all
>>
>> This code snippet will do and it is compliant with the SMP procedure,
>> I do not want people to copy'n'paste code that does not work on SMP,
>> I know this code runs on UP so the sequence above is safe, but why not make
>> the sequence identical for both UP/SMP ?
>
> Now this looks super straight forward. I wonder how I came up with
> inverted order (even if works in the UP case). Probably when you look
> at others code and they put a v7_flush_dcache_all before the disable,
> one (meaning me...) starts to bend the underlying ideas about the
> caches until it fits to the code you see.
>
> Anyway: Of course I'll take the code sequence then that works for the
> UP and SMP cases.
>
>>> +     /*
>>> +      * Clear the SCTLR.C bit to prevent further data cache
>>> +      * allocation. Clearing SCTLR.C would make all the data accesses
>>> +      * strongly ordered and would not hit the cache.
>>> +      */
>>> +     mrc     p15, 0, r0, c1, c0, 0
>>> +     bic     r0, r0, #(1 << 2)               @ Disable the C bit
>>> +     mcr     p15, 0, r0, c1, c0, 0
>>> +     isb
>>> +
>>> +     /*
>>> +      * We don't issue another v7_flush_dcache_all here as seen in many
>>> +      * other places as we have a UP core and the L1 could not soak up
>>> +      * data from other L1 caches in the meantime.
>>> +      */
>>> +
>>> +     bl      cpu_v7_do_idle
>>> +
>>> +     /* in rare cases when WFI fails we end up here and restore things */
>>
>> I am still baffled by this "wfi failures" and how hardware can manage
>> this situation _properly_, if you can explain to me how this works
>> that would be grand.
>
> I unfortunately don't know about the hardware design of this SoC.
>
>> This code is also called by CPUidle right ?
>
> I haven't experienced this when using suspend-to-ram but only for
> CPUIdle. Of course this might be just a matter of probability though.
>
>> So,
>> IRQs can still cause wfi completion, there has to be a handshake between
>> the core and power controller to prevent the CPU from being shutdown
>> while executing code (power down command sent, standbywfi asserted and
>> then released following wfi completion).
>>
>> Anyway, I do not like the code sequence (and I know that eg OMAP4 executes
>> the same code) above because again, it works on UP, but people might be
>> tempted to copy'n'paste it to their SMP implementation (with the addition
>> of SMP bit restore in ACTLR).
>>
>> OMAP4 sequence is missing TLB flush since the core runs for a time window with
>> incoherent TLBs (out of SMP). It works because other cores can't update
>> their page tables while the core exiting wfi is running out of coherency
>> (ie coupled idle C-states, either all CPUs down or no CPU down), but
>> again, that code should not be copied verbatim since it fails to flush
>> TLBs, AFAIK.
>>
>> Again, you are running a UP kernel so this code does not suffer from
>> the same problem, but if this code is copied and used on SMP platforms then
>> we do have problem and that has to be prevented.
>>
>> Why do not you turn MMU off (cpu_reset) and jump to the reset vector if
>> wfi fails (code in arch/arm/kernel/process.c __soft_restart(), minus the
>> cache flushing ?
>>
>>         phys_reset_t phys_reset;
>>
>>         /* Take out a flat memory mapping. */
>>         setup_mm_for_reboot();
>>
>>         phys_reset = (phys_reset_t)(unsigned long)virt_to_phys(cpu_reset);
>>         phys_reset((unsigned long)addr);
>>
>>         BUG();
>>
>> where addr == virt_to_phys(cpu_resume);
>>
>> from what I gather from the code below.
>>
>> There is just a tiny performance hit owing to a couple of fetches from
>> DRAM (MMU off), then cpu_resume restores the C bit and the MMU (and flushes
>> the TLBs) so the virtual address space and caches are back on. By the time wfi
>> fails, caches are invalid anyway so in both cases they have to be refilled.
>>
>> On top of that, this code is not really SH specific, it is plain v7 code
>> that can be standardised.
>
> Ok that sounds good. As we don't touch the hotpath I don't care much
> about some extra cycles and I appreciate moving towards
> standardization. I'll try that out and send a v3 with the two changes.

I just found out that this would work as well:

wfi_loop:
    bl    cpu_v7_do_idle
    b wfi_loop

So it looks like the SYSC (System Controller - the block that handles
power management) didn't have time to set up the powering down of the
domain that includes the ARM core. I haven't found a way to poll for
that event.

Currently the chip has successfully entered the low power state >
200.000 times, so I feel inclined to post this variation as v3.

> So thanks a lot,
>
>  Bastian
>
>> For now it is just a, hopefully useful, rant.
>>
>> Lorenzo
>>
>>> +     mrc     p15, 0, r0, c1, c0, 0
>>> +     orr     r0, r0, #(1 << 2)               @ Enable the C bit
>>> +     mcr     p15, 0, r0, c1, c0, 0
>>> +     isb
>>> +
>>> +     ldmfd   sp!, {r4-r12, pc}
>>> +ENDPROC(r8a7740)
>>> +
>>> +     .text
>>> +ENTRY(v7_cpu_resume)
>>> +     bl      v7_invalidate_l1
>>> +     b       cpu_resume
>>> +ENDPROC(v7_cpu_resume)
>>> +
>>> +/*
>>> + * The entry point of a warm reboot, used by wakeup scenarios
>>> + *
>>> + * The CPU jumps in this case to (0xfffff000 & SBAR), so we need
>>> + * to align this function properly.
>>> + * We use a long jump into the text segment and use the physical
>>> + * address as the MMU is still turned off.
>>> + */
>>> +     .align  12
>>> +     .text
>>> +ENTRY(r8a7740_resume)
>>> +     ldr     pc, 1f
>>> +1:   .long   v7_cpu_resume - PAGE_OFFSET + PLAT_PHYS_OFFSET
>>> +ENDPROC(r8a7740_resume_core_standby)
>>> +#endif
>>> --
>>


From daniel.lezcano at linaro.org  Mon Apr 15 09:29:56 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Mon, 15 Apr 2013 15:29:56 +0200
Subject: [RFC patch 0/2] ARM: at91: cpuidle: move driver to drivers/cpuidle
Message-ID: <1366032598-23053-1-git-send-email-daniel.lezcano@linaro.org>

The number of cpuidle drivers is increasing more and more. Today we have
in total 24 drivers. A lot of the code is duplicated, at least for the
initialization. A work of consolidation has been done during this year:
 * a lot of code cleanup in all the drivers
 * time keeping is now part of the framework
 * timer broadcast is now part of the framework
 * a WFI state function for ARM is defined and used in the drivers
 * an init function has been proposed to factor out the initialization across
   the drivers (patchset pending)

What has been observed is a lot of code duplicationis, modification made in
the framework takes awhile before reaching the driver which uses an old API,
duplicate routine and bugs, etc ...

It appears the drivers are belonging to different trees, the cpuidle framework
is under linux-pm, the drivers are per SoC tree. The communication is made
difficult because of the different mailing lists where the cpuidle are
submitted.

After this work, it is time to prevent all these problems to occur again.

I propose to move the cpuidle drivers to the drivers/cpuidle directory, hence
having one single submission path for cpuidle in order to have the cpuidle
framework and the different drivers synced.

This series move the AT91 cpuidle driver under drivers/cpuidle. That does not
change the rule to have the patches acked-by the author of the driver.

Note the calxeda and kirkwood drivers are now in drivers/cpuidle.

Daniel Lezcano (2):
  ARM: at91: cpuidle: encapsulate the standby code
  ARM: at91: cpuidle: move the driver to drivers/cpuidle directory

 arch/arm/mach-at91/Makefile  |    1 -
 arch/arm/mach-at91/cpuidle.c |   66 ------------------------------------------
 arch/arm/mach-at91/pm.c      |    8 ++++-
 drivers/cpuidle/Makefile     |    1 +
 drivers/cpuidle/at91.c       |   55 +++++++++++++++++++++++++++++++++++
 5 files changed, 63 insertions(+), 68 deletions(-)
 delete mode 100644 arch/arm/mach-at91/cpuidle.c
 create mode 100644 drivers/cpuidle/at91.c

-- 
1.7.9.5



From daniel.lezcano at linaro.org  Mon Apr 15 09:29:57 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Mon, 15 Apr 2013 15:29:57 +0200
Subject: [RFC patch 1/2] ARM: at91: cpuidle: encapsulate the standby code
In-Reply-To: <1366032598-23053-1-git-send-email-daniel.lezcano@linaro.org>
References: <1366032598-23053-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1366032598-23053-2-git-send-email-daniel.lezcano@linaro.org>

In order to split the pm code from the cpuidle driver, add an ops for the
standby function which will be initialized by the pm init functions directly,
thus no need of the SoC specific headers.

Cleanup also the headers included in this file as they are no longer needed.

Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
---
 arch/arm/mach-at91/cpuidle.c |   19 ++++---------------
 arch/arm/mach-at91/pm.c      |    8 +++++++-
 2 files changed, 11 insertions(+), 16 deletions(-)

diff --git a/arch/arm/mach-at91/cpuidle.c b/arch/arm/mach-at91/cpuidle.c
index 48f1228..b2bec92 100644
--- a/arch/arm/mach-at91/cpuidle.c
+++ b/arch/arm/mach-at91/cpuidle.c
@@ -13,32 +13,21 @@
  * #2 wait-for-interrupt and RAM self refresh
  */
 
-#include <linux/kernel.h>
+#include <linux/module.h>
 #include <linux/init.h>
-#include <linux/platform_device.h>
 #include <linux/cpuidle.h>
-#include <linux/io.h>
-#include <linux/export.h>
-#include <asm/proc-fns.h>
 #include <asm/cpuidle.h>
-#include <mach/cpu.h>
-
-#include "pm.h"
 
 #define AT91_MAX_STATES	2
 
+extern void (*at91_standby_ops)(void);
+
 /* Actual code that puts the SoC in different idle states */
 static int at91_enter_idle(struct cpuidle_device *dev,
 			struct cpuidle_driver *drv,
 			       int index)
 {
-	if (cpu_is_at91rm9200())
-		at91rm9200_standby();
-	else if (cpu_is_at91sam9g45())
-		at91sam9g45_standby();
-	else
-		at91sam9_standby();
-
+	at91_standby_ops();
 	return index;
 }
 
diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
index 73f1f25..f456e86 100644
--- a/arch/arm/mach-at91/pm.c
+++ b/arch/arm/mach-at91/pm.c
@@ -39,6 +39,8 @@
 #include "at91_rstc.h"
 #include "at91_shdwc.h"
 
+void (*at91_standby_ops)(void);
+
 static void __init show_reset_status(void)
 {
 	static char reset[] __initdata = "reset";
@@ -321,8 +323,12 @@ static int __init at91_pm_init(void)
 	pr_info("AT91: Power Management%s\n", (slow_clock ? " (with slow clock mode)" : ""));
 
 	/* AT91RM9200 SDRAM low-power mode cannot be used with self-refresh. */
-	if (cpu_is_at91rm9200())
+	if (cpu_is_at91rm9200()) {
 		at91_ramc_write(0, AT91RM9200_SDRAMC_LPR, 0);
+		at91_standby_ops = at91rm9200_standby;
+	} else if (cpu_is_at91sam9g45())
+		at91_standby_ops= at91sam9g45_standby;
+	else at91_standby_ops = at91sam9_standby;
 
 	suspend_set_ops(&at91_pm_ops);
 
-- 
1.7.9.5



From daniel.lezcano at linaro.org  Mon Apr 15 09:29:58 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Mon, 15 Apr 2013 15:29:58 +0200
Subject: [RFC patch 2/2] ARM: at91: cpuidle: move the driver to
 drivers/cpuidle directory
In-Reply-To: <1366032598-23053-1-git-send-email-daniel.lezcano@linaro.org>
References: <1366032598-23053-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1366032598-23053-3-git-send-email-daniel.lezcano@linaro.org>

We don't have any dependency with the SoC specific code.

Move the driver to the drivers/cpuidle directory.

Add Nicolas Ferre as author of the driver, so it will be in copy of the emails.

Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
---
 arch/arm/mach-at91/Makefile  |    1 -
 arch/arm/mach-at91/cpuidle.c |   55 ----------------------------------------
 drivers/cpuidle/Makefile     |    1 +
 drivers/cpuidle/at91.c       |   57 ++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 58 insertions(+), 56 deletions(-)
 delete mode 100644 arch/arm/mach-at91/cpuidle.c
 create mode 100644 drivers/cpuidle/at91.c

diff --git a/arch/arm/mach-at91/Makefile b/arch/arm/mach-at91/Makefile
index 39218ca..3c7fca1 100644
--- a/arch/arm/mach-at91/Makefile
+++ b/arch/arm/mach-at91/Makefile
@@ -99,7 +99,6 @@ obj-y				+= leds.o
 # Power Management
 obj-$(CONFIG_PM)		+= pm.o
 obj-$(CONFIG_AT91_SLOW_CLOCK)	+= pm_slowclock.o
-obj-$(CONFIG_CPU_IDLE)	+= cpuidle.o
 
 ifeq ($(CONFIG_PM_DEBUG),y)
 CFLAGS_pm.o += -DDEBUG
diff --git a/arch/arm/mach-at91/cpuidle.c b/arch/arm/mach-at91/cpuidle.c
deleted file mode 100644
index b2bec92..0000000
--- a/arch/arm/mach-at91/cpuidle.c
+++ /dev/null
@@ -1,55 +0,0 @@
-/*
- * based on arch/arm/mach-kirkwood/cpuidle.c
- *
- * CPU idle support for AT91 SoC
- *
- * 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.
- *
- * The cpu idle uses wait-for-interrupt and RAM self refresh in order
- * to implement two idle states -
- * #1 wait-for-interrupt
- * #2 wait-for-interrupt and RAM self refresh
- */
-
-#include <linux/module.h>
-#include <linux/init.h>
-#include <linux/cpuidle.h>
-#include <asm/cpuidle.h>
-
-#define AT91_MAX_STATES	2
-
-extern void (*at91_standby_ops)(void);
-
-/* Actual code that puts the SoC in different idle states */
-static int at91_enter_idle(struct cpuidle_device *dev,
-			struct cpuidle_driver *drv,
-			       int index)
-{
-	at91_standby_ops();
-	return index;
-}
-
-static struct cpuidle_driver at91_idle_driver = {
-	.name			= "at91_idle",
-	.owner			= THIS_MODULE,
-	.states[0]		= ARM_CPUIDLE_WFI_STATE,
-	.states[1]		= {
-		.enter			= at91_enter_idle,
-		.exit_latency		= 10,
-		.target_residency	= 100000,
-		.flags			= CPUIDLE_FLAG_TIME_VALID,
-		.name			= "RAM_SR",
-		.desc			= "WFI and DDR Self Refresh",
-	},
-	.state_count = AT91_MAX_STATES,
-};
-
-/* Initialize CPU idle by registering the idle states */
-static int __init at91_init_cpuidle(void)
-{
-	return cpuidle_register(&at91_idle_driver, NULL);
-}
-
-device_initcall(at91_init_cpuidle);
diff --git a/drivers/cpuidle/Makefile b/drivers/cpuidle/Makefile
index 0d8bd55..ba4e977 100644
--- a/drivers/cpuidle/Makefile
+++ b/drivers/cpuidle/Makefile
@@ -7,3 +7,4 @@ obj-$(CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED) += coupled.o
 
 obj-$(CONFIG_CPU_IDLE_CALXEDA) += cpuidle-calxeda.o
 obj-$(CONFIG_ARCH_KIRKWOOD) += cpuidle-kirkwood.o
+obj-$(CONFIG_ARCH_AT91) += at91.o
diff --git a/drivers/cpuidle/at91.c b/drivers/cpuidle/at91.c
new file mode 100644
index 0000000..2bc745b
--- /dev/null
+++ b/drivers/cpuidle/at91.c
@@ -0,0 +1,57 @@
+/*
+ * based on arch/arm/mach-kirkwood/cpuidle.c
+ *
+ * CPU idle support for AT91 SoC
+ *
+ * Author: Nicolas Ferre <nicolas.ferre at atmel.com>
+ *
+ * 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.
+ *
+ * The cpu idle uses wait-for-interrupt and RAM self refresh in order
+ * to implement two idle states -
+ * #1 wait-for-interrupt
+ * #2 wait-for-interrupt and RAM self refresh
+ */
+
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/cpuidle.h>
+#include <asm/cpuidle.h>
+
+#define AT91_MAX_STATES	2
+
+extern void (*at91_standby_ops)(void);
+
+/* Actual code that puts the SoC in different idle states */
+static int at91_enter_idle(struct cpuidle_device *dev,
+			struct cpuidle_driver *drv,
+			       int index)
+{
+	at91_standby_ops();
+	return index;
+}
+
+static struct cpuidle_driver at91_idle_driver = {
+	.name			= "at91_idle",
+	.owner			= THIS_MODULE,
+	.states[0]		= ARM_CPUIDLE_WFI_STATE,
+	.states[1]		= {
+		.enter			= at91_enter_idle,
+		.exit_latency		= 10,
+		.target_residency	= 100000,
+		.flags			= CPUIDLE_FLAG_TIME_VALID,
+		.name			= "RAM_SR",
+		.desc			= "WFI and DDR Self Refresh",
+	},
+	.state_count = AT91_MAX_STATES,
+};
+
+/* Initialize CPU idle by registering the idle states */
+static int __init at91_init_cpuidle(void)
+{
+	return cpuidle_register(&at91_idle_driver, NULL);
+}
+
+device_initcall(at91_init_cpuidle);
-- 
1.7.9.5



From grant.likely at secretlab.ca  Mon Apr 15 09:30:38 2013
From: grant.likely at secretlab.ca (Grant Likely)
Date: Mon, 15 Apr 2013 14:30:38 +0100
Subject: [PATCH] clk: add DT test clock consumer driver
In-Reply-To: <1363439376-21294-1-git-send-email-sebastian.hesselbarth@gmail.com>
References: <1363439376-21294-1-git-send-email-sebastian.hesselbarth@gmail.com>
Message-ID: <20130415133038.2A7723E0AA8@localhost>

On Sat, 16 Mar 2013 14:09:36 +0100, Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com> wrote:
> This driver adds a DT test clock consumer that exposes debugfs files to
> enable/disable and set/get rate of the attached programmable clock.
> During development of a i2c-attached clock generator I found it useful
> to debug the clock generator's internal pll settings by enforcing clock
> rates through debugfs.
> 
> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>

Rather that using a DT binding to enable this, would it not be better to
have the debug interface bound entirely at runtime, and be able to
attach to pretty much any clock. It is less usable if it requires
modifying the dtb to use a debug feature.

g.



From robherring2 at gmail.com  Mon Apr 15 09:36:23 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Mon, 15 Apr 2013 08:36:23 -0500
Subject: [GIT PULL] Timer clean-ups for 3.10, Part 2
In-Reply-To: <20130413065056.GB14735@quad.lixom.net>
References: <516720B4.3000703@gmail.com> <201304112257.07645.arnd@arndb.de>
 <20130413065056.GB14735@quad.lixom.net>
Message-ID: <516C0257.8040103@gmail.com>

On 04/13/2013 01:50 AM, Olof Johansson wrote:
> On Thu, Apr 11, 2013 at 10:57:07PM +0200, Arnd Bergmann wrote:
>> On Thursday 11 April 2013, Rob Herring wrote:
>>> Olof, Arnd,
>>>
>>> Please pull timer clean-ups for arch timer, sp804, and integrator-cp timers.
>>>
>>> I've dropped the final patch which moved the sp804 and integrator timers
>>> code to drivers/clocksource until the desired structure is worked out.
>>>
>>> Simon, the fixes for shmobile were trivial. Please comment if you see
>>> any issues.
>>
>> Ok, nice!
>>
>> There are various bits for which I'd like to see Russell's ACK before
>> we send them Linuswards, but it all looks good to me.
>>
>> I would put it into arm-soc tomorrow, and hopefully Haojian Zhuang is
>> able to send an updated version of his hisilicon platform code based
>> on top of this in time for the merge window. The patches are all
>> reviewed but just waiting for the sp804 changes now, and since
>> it's a new platform, I'm not worried about regressions.
> 
> I've pulled this in as a late/clksrc branch now, so that we keep it separate
> from the other work in case Russell ends up having comments on it when he is
> back online.
> 
> Also, I based the branch on samsung/mct and samsung/clk, since they had merge
> conflicts. Kukjin, Rob, please confirm that I've resolved them properly.

It is quite messed up because the mct timer changes are not based on
arm-soc/clksrc/cleanup. Any timer changes adding CLKSRC_OF support need
to be based on this. I've fixed it up in this branch (untested):

git://sources.calxeda.com/kernel/linux.git exynos-mct-merge

I merged with clksrc-cleanup-for-3.10-part2 and fixed it in the merge,
but really either the mct branch should be rebased or some of the
changes can be a preparatory commit before merging.

Also, I really don't like how intermingled the DT and non-DT init is in
the exynos code. We should remove of_have_populated_dt so we don't have
stuff like this:

        if (!of_have_populated_dt())
                gic_init_bases(0, IRQ_PPI(0), S5P_VA_GIC_DIST,
S5P_VA_GIC_CPU, gic_bank_offset, NULL);
#ifdef CONFIG_OF
        else
                irqchip_init();
#endif

        if (!of_have_populated_dt())
                combiner_init(S5P_VA_COMBINER_BASE, NULL);


I went thru arm-soc/for-next and all the other conversions not done by
me (mxs, sirf, zynq) are based on clksrc/cleanup.

Rob


From jason at lakedaemon.net  Mon Apr 15 09:43:25 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Mon, 15 Apr 2013 09:43:25 -0400
Subject: [PATCH 0/5 v2] mv643xx_eth: device tree bindings
In-Reply-To: <1365995234.3566.17.camel@deadeye.wl.decadent.org.uk>
References: <1365071235-11611-1-git-send-email-florian@openwrt.org>
 <20130411165303.GI28693@titan.lakedaemon.net>
 <20130413172126.6cca0809@skate>
 <20130413190037.GY28693@titan.lakedaemon.net>
 <1365995234.3566.17.camel@deadeye.wl.decadent.org.uk>
Message-ID: <20130415134325.GB28693@titan.lakedaemon.net>

On Mon, Apr 15, 2013 at 04:07:14AM +0100, Ben Hutchings wrote:
> On Sat, 2013-04-13 at 15:00 -0400, Jason Cooper wrote:
> > On Sat, Apr 13, 2013 at 05:21:26PM +0200, Thomas Petazzoni wrote:
> > > Dear Jason Cooper,
> > > 
> > > On Thu, 11 Apr 2013 12:53:03 -0400, Jason Cooper wrote:
> > > 
> > > > With this and Thomas' pci series, we will have Kirkwood fully
> > > > converted to devicetree, can begin removing board files, and finally
> > > > begin migrating everything over to mach-mvebu/.  This will lead to
> > > > the removal of five directories under arch/arm/ (plat-orion,
> > > > mach-kirkwood, mach-orion5x, mach-dove, and mach-mv78xx0).
> > > 
> > > No, we can't remove mach-orion5x and mach-mv78xx0 for now, they have
> > > not been converted at all in terms of gpio/pinmux support. I've started
> > > writing some pinmux code for orion5x but it's not ready.
> [...]
> > Also, I have a feeling that not all legacy boards will get converted
> > over.  If there is no interest or no way to test, certains boards may
> > get deprecated.
> 
> Debian supports many Kirkwood and Orion 5x systems.  A call for testing
> on the debian-arm at lists.debian.org list might be worthwhile.

definitely.

> I would be very glad to see kirkwood, orion5x and mv78xx0 merged - we
> build natively and this takes about 8 hours for each configuration.

That's the plan, build an armv5 kernel, and dtb's for all the boards.
Then, an armv7 kernel for the armadaXP/370 boards, etc.

thx,

Jason.


From linus.walleij at linaro.org  Mon Apr 15 09:47:30 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Mon, 15 Apr 2013 15:47:30 +0200
Subject: [PATCH 3/8] dmaengine: ste_dma40: Actually write the runtime
 configuration to registers
In-Reply-To: <20130415115906.GF6512@gmail.com>
References: <1365532783-27425-1-git-send-email-lee.jones@linaro.org>
 <1365532783-27425-3-git-send-email-lee.jones@linaro.org>
 <CAH+eYFB_fYmCjvh5PXKRhd-FnaWfeu+LtH+q3VywhCk-PYhHVQ@mail.gmail.com>
 <20130415110601.GE6512@gmail.com>
 <CAH+eYFB2+oMPXsnzQVVrEK8CjKGVYFa_n4Wxr=CpdtJwFfOGYw@mail.gmail.com>
 <20130415115906.GF6512@gmail.com>
Message-ID: <CACRpkdawUPPzh-EgVdmvOVP2SOjgKXYrfus=yMee7n+PtAQPHg@mail.gmail.com>

On Mon, Apr 15, 2013 at 1:59 PM, Lee Jones <lee.jones at linaro.org> wrote:
> On Mon, 15 Apr 2013, Rabin Vincent wrote:
>> 2013/4/15 Lee Jones <lee.jones at linaro.org>:
>> > On Fri, 12 Apr 2013, Rabin Vincent wrote:
>> >> 2013/4/9 Lee Jones <lee.jones at linaro.org>:
>> >> > Someone has spent a fair amount of effort writing a runtime configuration
>> >> > changing algorithm for DMA clients. However, the config appears to never
>> >> > actually make it to hardware. In order for the configuration to take hold
>> >> > we need to issue a d40_config_write(), as this is the routine which writes
>> >> > it into the hardware's registers.
>> >>
>> >> No, it's not.  This function is only for initial configuration which
>> >> should only be written when the channel is allocated.  In fact, by
>> >> calling it here in runtime_config, you are introducing a serious bug:
>> >> other logical channels on the same physical channel will stop because of
>> >> the SSLNK/SDLNK of the physical channel being zeroed.
>> >>
>> >> The runtime config already makes it the hardware in the existing code,
>> >> via d40_*_cfg().
>> >
>> > Sorry Rabin, but the only place I can see the config being written is
>> > in d40_config_write().
>> >
>> > Can you paste the line of code in d40_*_cfg() which actually writes
>> > the config to hardware please? I don't see it.
>>
>> It's not that simple.  There are some pointers passed to d40_*_cfg() and
>> that function writes the configuration to the variables those pointers
>> point to (d40c->log_def.lcsp1, d40c->src_def_cfg, etc.).  Please read
>> the code to see how those variables end up being used later when the
>> LLIs are prepared for the HW.
>
> I have read the code, which is why I know that the config only gets
> written in d40_config_write(). :)
>
> So the configuration which gets set in the runtime_config routine
> doesn't ever make it to hardware - hence this patch.
>
> Unless I'm missing something?

The runtime config sets up the config for all *subsequent* jobs.
struct d40_chan contains e.g. runtime_addr, runtime_direction
etc to store up the stuff being configured. This is done for
all the other config as well using d40_log_cfg() or
d40_phy_cfg(), and the result is cached in the channel
struct, here called d40c.

Next, when preparing jobs, the DMA40 LLI engine will fill in
job descriptors using e.g. d40_get_dev_addr()
and pick settings from this cached runtime config.

When the subsequent jobs trigger, it allocates channel resources
by calling d40_alloc_chan_resources(). The config is written to the
hardware by calling d40_config_write().

So the basic misunderstanding here is that you think
the config shall take effect immediately, that is not the
idea. The configuration will be cached in the channel
struct, then it will take effect when the next job that is
queued up allocates its resources to commence.

Maybe you haven't grasped the asynchronous nature
of the DMAengine? It's a bit like multithreading. You
queue up things, then they commence at a later time.
Not immediately.

Example: the SPI driver for PL022 may talk to a
8, 16 or 32bit capable device. Depending on which device
it wants to queue a job for, it need to be configured differently,
like for another width.

At the time you are queueing a new job, another job may
already be in flight. If you issue d40_config_write() at this
point, you will cause undesired effects to the job that may
already be running. Such as reconfiguring the width
of the channel.

You may not observe that bug because there is no
job in flight, or because the actual configuration is identical
for two consecutive jobs, but if you're really stressing something,
queuing jobs while others are already in flight, you will
see it immediately.

Therefore, this patch should be dropped.

Yours,
Linus Walleij


From will.deacon at arm.com  Mon Apr 15 09:48:37 2013
From: will.deacon at arm.com (Will Deacon)
Date: Mon, 15 Apr 2013 14:48:37 +0100
Subject: [PATCH] ARM: KVM: iterate over all CPUs for CPU compatibility
 check
In-Reply-To: <516BFD13.1000400@linaro.org>
References: <51680AF9.7040109@arm.com>
 <CAEDV+g+E8PLc60vMRhq4O_AL2WjmYDLb6=Wh34ynhevh7uAGJA@mail.gmail.com>
 <d455f2823b9639af8d38d30f2c3234bd@localhost>
 <CAEDV+gJuFG49oQ=BEaCHcTP=nHVyX8ALw6076dR_C1s7TuyqXQ@mail.gmail.com>
 <d47697abd39a0d5d41f5ac110a40e261@localhost>
 <CAEDV+gK9==sXYxRVZ8JVFYPiw3_xgzZBbydEwPunmnocNLKXrQ@mail.gmail.com>
 <CAFEAcA-bPoa8YoPuHPmupzfUW+yR233XquK79eNorzcRpFiK=g@mail.gmail.com>
 <516BCAD0.9000708@linaro.org>
 <CAJRNFKJoBzgt4UhxsH65_LyhcGXPnzB_pg3q-zeYT2OVv59q4A@mail.gmail.com>
 <516BFD13.1000400@linaro.org>
Message-ID: <20130415134837.GI9827@mudshark.cambridge.arm.com>

On Mon, Apr 15, 2013 at 02:13:55PM +0100, Andre Przywara wrote:
> On 04/15/2013 11:52 AM, Alexander Spyridakis wrote:
> > I've run on this problem before, while trying to run KVM guests on A7 cores.
> >
> > For some reason the 3rd A7 hangs in arch/arm/kvm/init.S, on the
> > instruction that updates HSCTLR between the two isbs on __do_hyp_init
> > (mcr p15, 4, r0, c1, c0, 0). If you boot the system with maxcpus=4 then
> > init_hyp_mode() will not hang on the A7 cluster. Other than that from my
> > limited testing KVM on A7 works on a usual linux guest. I also tried to
> > only boot the 3rd A7 core to rule out any racing issues, but still the
> > same behaviour applies.
> 
> Could well be the same issue here. I chased it down till CPU 2 goes into 
> HYP mode to do the initialization.
> I am running with maxcpus=3 (this increases the likelyhood that 
> kvm_target_cpu() runs on an A15), so CPU #2 is the only one A7.
> As the HYP mode exception table is empty except for the HVC trap, it may 
> be looping here. I am trying now to get the PC of the faulty instruction.

Yes, it sounds like you're taking a recursive fault because the vectors
aren't installed yet. Is there any chance you can find out what value you end
up writing (or trying to write) to the HSCTLR please?

Will


From nicolas.ferre at atmel.com  Mon Apr 15 09:54:38 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Mon, 15 Apr 2013 15:54:38 +0200
Subject: [RFC patch 1/2] ARM: at91: cpuidle: encapsulate the standby code
In-Reply-To: <1366032598-23053-2-git-send-email-daniel.lezcano@linaro.org>
References: <1366032598-23053-1-git-send-email-daniel.lezcano@linaro.org>
 <1366032598-23053-2-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <516C069E.2040205@atmel.com>

Hi Daniel,

On 04/15/2013 03:29 PM, Daniel Lezcano :
> In order to split the pm code from the cpuidle driver, add an ops for the
> standby function which will be initialized by the pm init functions directly,
> thus no need of the SoC specific headers.
> 
> Cleanup also the headers included in this file as they are no longer needed.
> 
> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
> ---
>  arch/arm/mach-at91/cpuidle.c |   19 ++++---------------
>  arch/arm/mach-at91/pm.c      |    8 +++++++-
>  2 files changed, 11 insertions(+), 16 deletions(-)
> 
> diff --git a/arch/arm/mach-at91/cpuidle.c b/arch/arm/mach-at91/cpuidle.c
> index 48f1228..b2bec92 100644
> --- a/arch/arm/mach-at91/cpuidle.c
> +++ b/arch/arm/mach-at91/cpuidle.c
> @@ -13,32 +13,21 @@
>   * #2 wait-for-interrupt and RAM self refresh
>   */
>  
> -#include <linux/kernel.h>
> +#include <linux/module.h>
>  #include <linux/init.h>
> -#include <linux/platform_device.h>
>  #include <linux/cpuidle.h>
> -#include <linux/io.h>
> -#include <linux/export.h>
> -#include <asm/proc-fns.h>
>  #include <asm/cpuidle.h>
> -#include <mach/cpu.h>
> -
> -#include "pm.h"
>  
>  #define AT91_MAX_STATES	2
>  
> +extern void (*at91_standby_ops)(void);
> +
>  /* Actual code that puts the SoC in different idle states */
>  static int at91_enter_idle(struct cpuidle_device *dev,
>  			struct cpuidle_driver *drv,
>  			       int index)
>  {
> -	if (cpu_is_at91rm9200())
> -		at91rm9200_standby();
> -	else if (cpu_is_at91sam9g45())
> -		at91sam9g45_standby();
> -	else
> -		at91sam9_standby();
> -
> +	at91_standby_ops();
>  	return index;
>  }
>  
> diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
> index 73f1f25..f456e86 100644
> --- a/arch/arm/mach-at91/pm.c
> +++ b/arch/arm/mach-at91/pm.c
> @@ -39,6 +39,8 @@
>  #include "at91_rstc.h"
>  #include "at91_shdwc.h"
>  
> +void (*at91_standby_ops)(void);

Is this a common pattern to have such a floating function pointer in the
pm code?

> +
>  static void __init show_reset_status(void)
>  {
>  	static char reset[] __initdata = "reset";
> @@ -321,8 +323,12 @@ static int __init at91_pm_init(void)
>  	pr_info("AT91: Power Management%s\n", (slow_clock ? " (with slow clock mode)" : ""));
>  
>  	/* AT91RM9200 SDRAM low-power mode cannot be used with self-refresh. */
> -	if (cpu_is_at91rm9200())
> +	if (cpu_is_at91rm9200()) {
>  		at91_ramc_write(0, AT91RM9200_SDRAMC_LPR, 0);
> +		at91_standby_ops = at91rm9200_standby;
> +	} else if (cpu_is_at91sam9g45())

CodingStyle: ending "{" is missing.

> +		at91_standby_ops= at91sam9g45_standby;

CodingStyle: " " is missing

> +	else at91_standby_ops = at91sam9_standby;

CodingStyle: not on the same line + "{}" missing

>  
>  	suspend_set_ops(&at91_pm_ops);

I am in favor for the move. But please rewrite a new series.

Bye,
-- 
Nicolas Ferre


From khilman at linaro.org  Mon Apr 15 10:02:40 2013
From: khilman at linaro.org (Kevin Hilman)
Date: Mon, 15 Apr 2013 07:02:40 -0700
Subject: [PATCH 1/3] cputime_nsecs: use math64.h for nsec resolution
 conversion helpers
In-Reply-To: <20130411171047.GB17129@somewhere.redhat.com> (Frederic
 Weisbecker's message of "Thu, 11 Apr 2013 19:10:50 +0200")
References: <1363822467-6275-1-git-send-email-khilman@linaro.org>
 <1363822467-6275-2-git-send-email-khilman@linaro.org>
 <20130411171047.GB17129@somewhere.redhat.com>
Message-ID: <87r4ibdh8f.fsf@linaro.org>

Frederic Weisbecker <fweisbec at gmail.com> writes:

> On Wed, Mar 20, 2013 at 04:34:25PM -0700, Kevin Hilman wrote:
>> For the nsec resolution conversions to be useable on non 64-bit
>> architectures, the helpers in <linux/math64.h> need to be used so the
>> right arch-specific 64-bit math helpers can be used (e.g. do_div())
>> 
>> Cc: Frederic Weisbecker <fweisbec at gmail.com>
>> Signed-off-by: Kevin Hilman <khilman at linaro.org>
>
> Ok the patch is nice!
>
> I'm queuing it.

Thanks, did you queue PATCH 3/3 also to remove the 64-bit limitation
from VIRT_CPU_ACCOUNTING_GEN:  https://lkml.org/lkml/2013/3/20/656

Kevin


From fweisbec at gmail.com  Mon Apr 15 10:08:24 2013
From: fweisbec at gmail.com (Frederic Weisbecker)
Date: Mon, 15 Apr 2013 16:08:24 +0200
Subject: [PATCH 1/3] cputime_nsecs: use math64.h for nsec resolution
 conversion helpers
In-Reply-To: <87r4ibdh8f.fsf@linaro.org>
References: <1363822467-6275-1-git-send-email-khilman@linaro.org>
 <1363822467-6275-2-git-send-email-khilman@linaro.org>
 <20130411171047.GB17129@somewhere.redhat.com>
 <87r4ibdh8f.fsf@linaro.org>
Message-ID: <CAFTL4hwroTC6HN7WvDRpn=6y-JkX4GeFzS1nro0w3L1CGNMrnA@mail.gmail.com>

2013/4/15 Kevin Hilman <khilman at linaro.org>:
> Frederic Weisbecker <fweisbec at gmail.com> writes:
>
>> On Wed, Mar 20, 2013 at 04:34:25PM -0700, Kevin Hilman wrote:
>>> For the nsec resolution conversions to be useable on non 64-bit
>>> architectures, the helpers in <linux/math64.h> need to be used so the
>>> right arch-specific 64-bit math helpers can be used (e.g. do_div())
>>>
>>> Cc: Frederic Weisbecker <fweisbec at gmail.com>
>>> Signed-off-by: Kevin Hilman <khilman at linaro.org>
>>
>> Ok the patch is nice!
>>
>> I'm queuing it.
>
> Thanks, did you queue PATCH 3/3 also to remove the 64-bit limitation
> from VIRT_CPU_ACCOUNTING_GEN:  https://lkml.org/lkml/2013/3/20/656

Not yet, for this one I need to deeply check we haven't forgotten
anything concerning cputime_t operations in 32 bits archs.


From nm at ti.com  Mon Apr 15 10:10:40 2013
From: nm at ti.com (Nishanth Menon)
Date: Mon, 15 Apr 2013 09:10:40 -0500
Subject: [PATCH] cpufreq: exynos5440: Protect opp search calls with rcu
 lock
In-Reply-To: <1366007087-12090-1-git-send-email-amit.daniel@samsung.com>
References: <1366007087-12090-1-git-send-email-amit.daniel@samsung.com>
Message-ID: <CAGo_u6qD5hO7x0fYwe+cZ5GHRA6tRG+vmhnf4GFjt9G0inQ0xA@mail.gmail.com>

Daniel,
On Mon, Apr 15, 2013 at 1:24 AM, Amit Daniel Kachhap
<amit.daniel at samsung.com> wrote:
> As per the OPP library documentation(Documentation/power/opp.txt) all
> opp find/get calls should be protected by rcu locks.
>
> Signed-off-by: Amit Daniel Kachhap <amit.daniel at samsung.com>
> ---
>
> This patch is created against linux-next tree and is suggested by
> Nishanth Menon. (https://lkml.org/lkml/2013/4/12/119)
>
>  drivers/cpufreq/exynos5440-cpufreq.c |    3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/cpufreq/exynos5440-cpufreq.c b/drivers/cpufreq/exynos5440-cpufreq.c
> index ead7ed4..0c74018 100644
> --- a/drivers/cpufreq/exynos5440-cpufreq.c
> +++ b/drivers/cpufreq/exynos5440-cpufreq.c
> @@ -120,11 +120,13 @@ static int init_div_table(void)
>         int i = 0;
>         struct opp *opp;
>
> +       rcu_read_lock();
>         for (i = 0; freq_tbl[i].frequency != CPUFREQ_TABLE_END; i++) {
>
>                 opp = opp_find_freq_exact(dvfs_info->dev,
>                                         freq_tbl[i].frequency * 1000, true);
>                 if (IS_ERR(opp)) {
> +                       rcu_read_unlock();
>                         dev_err(dvfs_info->dev,
>                                 "failed to find valid OPP for %u KHZ\n",
>                                 freq_tbl[i].frequency);
> @@ -159,6 +161,7 @@ static int init_div_table(void)
>                 __raw_writel(tmp, dvfs_info->base + XMU_PMU_P0_7 + 4 * i);
>         }
>
> +       rcu_read_unlock();

Is it not possible to reduce the amount of code protected by RCU lock?
something like this:
+               rcu_read_lock();
                opp = opp_find_freq_exact(dvfs_info->dev,
                                        freq_tbl[i].frequency * 1000, true);
                if (IS_ERR(opp)) {
+                       rcu_read_unlock();
                        dev_err(dvfs_info->dev,
                                "failed to find valid OPP for %u KHZ\n",
                                freq_tbl[i].frequency);
                        return PTR_ERR(opp);
                }
+               volt_id = opp_get_voltage(opp);
+               rcu_unlock();


From daniel.lezcano at linaro.org  Mon Apr 15 10:13:59 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Mon, 15 Apr 2013 16:13:59 +0200
Subject: [RFC patch 1/2] ARM: at91: cpuidle: encapsulate the standby code
In-Reply-To: <516C069E.2040205@atmel.com>
References: <1366032598-23053-1-git-send-email-daniel.lezcano@linaro.org>
 <1366032598-23053-2-git-send-email-daniel.lezcano@linaro.org>
 <516C069E.2040205@atmel.com>
Message-ID: <516C0B27.9080406@linaro.org>

On 04/15/2013 03:54 PM, Nicolas Ferre wrote:
> Hi Daniel,
> 
> On 04/15/2013 03:29 PM, Daniel Lezcano :
>> In order to split the pm code from the cpuidle driver, add an ops for the
>> standby function which will be initialized by the pm init functions directly,
>> thus no need of the SoC specific headers.
>>
>> Cleanup also the headers included in this file as they are no longer needed.
>>
>> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
>> ---
>>  arch/arm/mach-at91/cpuidle.c |   19 ++++---------------
>>  arch/arm/mach-at91/pm.c      |    8 +++++++-
>>  2 files changed, 11 insertions(+), 16 deletions(-)
>>
>> diff --git a/arch/arm/mach-at91/cpuidle.c b/arch/arm/mach-at91/cpuidle.c
>> index 48f1228..b2bec92 100644
>> --- a/arch/arm/mach-at91/cpuidle.c
>> +++ b/arch/arm/mach-at91/cpuidle.c
>> @@ -13,32 +13,21 @@
>>   * #2 wait-for-interrupt and RAM self refresh
>>   */
>>  
>> -#include <linux/kernel.h>
>> +#include <linux/module.h>
>>  #include <linux/init.h>
>> -#include <linux/platform_device.h>
>>  #include <linux/cpuidle.h>
>> -#include <linux/io.h>
>> -#include <linux/export.h>
>> -#include <asm/proc-fns.h>
>>  #include <asm/cpuidle.h>
>> -#include <mach/cpu.h>
>> -
>> -#include "pm.h"
>>  
>>  #define AT91_MAX_STATES	2
>>  
>> +extern void (*at91_standby_ops)(void);
>> +
>>  /* Actual code that puts the SoC in different idle states */
>>  static int at91_enter_idle(struct cpuidle_device *dev,
>>  			struct cpuidle_driver *drv,
>>  			       int index)
>>  {
>> -	if (cpu_is_at91rm9200())
>> -		at91rm9200_standby();
>> -	else if (cpu_is_at91sam9g45())
>> -		at91sam9g45_standby();
>> -	else
>> -		at91sam9_standby();
>> -
>> +	at91_standby_ops();
>>  	return index;
>>  }
>>  
>> diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
>> index 73f1f25..f456e86 100644
>> --- a/arch/arm/mach-at91/pm.c
>> +++ b/arch/arm/mach-at91/pm.c
>> @@ -39,6 +39,8 @@
>>  #include "at91_rstc.h"
>>  #include "at91_shdwc.h"
>>  
>> +void (*at91_standby_ops)(void);
> 
> Is this a common pattern to have such a floating function pointer in the
> pm code?

Well, already seen but I agree it is not really nice.

The idea I had was to convert little by little all these pm functions
into ops, then order, group and use them to initialize the cpuidle
drivers through a single ARM driver. The correct order would have been
to convert first these to ops then move the driver but there are so many
drivers, so many code, I don't know where do I start.

Do you have a suggestion ?

>> +
>>  static void __init show_reset_status(void)
>>  {
>>  	static char reset[] __initdata = "reset";
>> @@ -321,8 +323,12 @@ static int __init at91_pm_init(void)
>>  	pr_info("AT91: Power Management%s\n", (slow_clock ? " (with slow clock mode)" : ""));
>>  
>>  	/* AT91RM9200 SDRAM low-power mode cannot be used with self-refresh. */
>> -	if (cpu_is_at91rm9200())
>> +	if (cpu_is_at91rm9200()) {
>>  		at91_ramc_write(0, AT91RM9200_SDRAMC_LPR, 0);
>> +		at91_standby_ops = at91rm9200_standby;
>> +	} else if (cpu_is_at91sam9g45())
> 
> CodingStyle: ending "{" is missing.
> 
>> +		at91_standby_ops= at91sam9g45_standby;
> 
> CodingStyle: " " is missing
> 
>> +	else at91_standby_ops = at91sam9_standby;
> 
> CodingStyle: not on the same line + "{}" missing
> 
>>  
>>  	suspend_set_ops(&at91_pm_ops);
> 
> I am in favor for the move. 

Ok, cool.

> But please rewrite a new series.

Yes, sure, that was a draft.

Thanks for the review.

  -- Daniel


-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From nicolas.ferre at atmel.com  Mon Apr 15 10:14:08 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Mon, 15 Apr 2013 16:14:08 +0200
Subject: [RFC patch 2/2] ARM: at91: cpuidle: move the driver to
 drivers/cpuidle directory
In-Reply-To: <1366032598-23053-3-git-send-email-daniel.lezcano@linaro.org>
References: <1366032598-23053-1-git-send-email-daniel.lezcano@linaro.org>
 <1366032598-23053-3-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <516C0B30.501@atmel.com>

On 04/15/2013 03:29 PM, Daniel Lezcano :
> We don't have any dependency with the SoC specific code.
> 
> Move the driver to the drivers/cpuidle directory.
> 
> Add Nicolas Ferre as author of the driver, so it will be in copy of the emails.

Unfortunately, I am not the author of this driver. It is the work of
Albin Tonnerre <albin.tonnerre at free-electrons.com>. So, for sure, I (and
Jean-Christohpe) can babysit this code but I cannot be awarded for it...

You can certainly add to the header of this file:
Maintained by the AT91 crew: Nicolas Ferre, Jean-Christophe
Plagniol-Villard (together with email addresses).



> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
> ---
>  arch/arm/mach-at91/Makefile  |    1 -
>  arch/arm/mach-at91/cpuidle.c |   55 ----------------------------------------
>  drivers/cpuidle/Makefile     |    1 +
>  drivers/cpuidle/at91.c       |   57 ++++++++++++++++++++++++++++++++++++++++++

No, sorry this file name is not appropriate: I prefer cpuidle-at91.c

>  4 files changed, 58 insertions(+), 56 deletions(-)
>  delete mode 100644 arch/arm/mach-at91/cpuidle.c
>  create mode 100644 drivers/cpuidle/at91.c
> 
> diff --git a/arch/arm/mach-at91/Makefile b/arch/arm/mach-at91/Makefile
> index 39218ca..3c7fca1 100644
> --- a/arch/arm/mach-at91/Makefile
> +++ b/arch/arm/mach-at91/Makefile
> @@ -99,7 +99,6 @@ obj-y				+= leds.o
>  # Power Management
>  obj-$(CONFIG_PM)		+= pm.o
>  obj-$(CONFIG_AT91_SLOW_CLOCK)	+= pm_slowclock.o
> -obj-$(CONFIG_CPU_IDLE)	+= cpuidle.o
>  
>  ifeq ($(CONFIG_PM_DEBUG),y)
>  CFLAGS_pm.o += -DDEBUG
> diff --git a/arch/arm/mach-at91/cpuidle.c b/arch/arm/mach-at91/cpuidle.c
> deleted file mode 100644
> index b2bec92..0000000
> --- a/arch/arm/mach-at91/cpuidle.c
> +++ /dev/null
> @@ -1,55 +0,0 @@
> -/*
> - * based on arch/arm/mach-kirkwood/cpuidle.c
> - *
> - * CPU idle support for AT91 SoC
> - *
> - * 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.
> - *
> - * The cpu idle uses wait-for-interrupt and RAM self refresh in order
> - * to implement two idle states -
> - * #1 wait-for-interrupt
> - * #2 wait-for-interrupt and RAM self refresh
> - */
> -
> -#include <linux/module.h>
> -#include <linux/init.h>
> -#include <linux/cpuidle.h>
> -#include <asm/cpuidle.h>
> -
> -#define AT91_MAX_STATES	2
> -
> -extern void (*at91_standby_ops)(void);
> -
> -/* Actual code that puts the SoC in different idle states */
> -static int at91_enter_idle(struct cpuidle_device *dev,
> -			struct cpuidle_driver *drv,
> -			       int index)
> -{
> -	at91_standby_ops();
> -	return index;
> -}
> -
> -static struct cpuidle_driver at91_idle_driver = {
> -	.name			= "at91_idle",
> -	.owner			= THIS_MODULE,
> -	.states[0]		= ARM_CPUIDLE_WFI_STATE,
> -	.states[1]		= {
> -		.enter			= at91_enter_idle,
> -		.exit_latency		= 10,
> -		.target_residency	= 100000,
> -		.flags			= CPUIDLE_FLAG_TIME_VALID,
> -		.name			= "RAM_SR",
> -		.desc			= "WFI and DDR Self Refresh",
> -	},
> -	.state_count = AT91_MAX_STATES,
> -};
> -
> -/* Initialize CPU idle by registering the idle states */
> -static int __init at91_init_cpuidle(void)
> -{
> -	return cpuidle_register(&at91_idle_driver, NULL);
> -}
> -
> -device_initcall(at91_init_cpuidle);
> diff --git a/drivers/cpuidle/Makefile b/drivers/cpuidle/Makefile
> index 0d8bd55..ba4e977 100644
> --- a/drivers/cpuidle/Makefile
> +++ b/drivers/cpuidle/Makefile
> @@ -7,3 +7,4 @@ obj-$(CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED) += coupled.o
>  
>  obj-$(CONFIG_CPU_IDLE_CALXEDA) += cpuidle-calxeda.o
>  obj-$(CONFIG_ARCH_KIRKWOOD) += cpuidle-kirkwood.o
> +obj-$(CONFIG_ARCH_AT91) += at91.o
> diff --git a/drivers/cpuidle/at91.c b/drivers/cpuidle/at91.c
> new file mode 100644
> index 0000000..2bc745b
> --- /dev/null
> +++ b/drivers/cpuidle/at91.c
> @@ -0,0 +1,57 @@
> +/*
> + * based on arch/arm/mach-kirkwood/cpuidle.c
> + *
> + * CPU idle support for AT91 SoC
> + *
> + * Author: Nicolas Ferre <nicolas.ferre at atmel.com>
> + *
> + * 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.
> + *
> + * The cpu idle uses wait-for-interrupt and RAM self refresh in order
> + * to implement two idle states -
> + * #1 wait-for-interrupt
> + * #2 wait-for-interrupt and RAM self refresh
> + */
> +
> +#include <linux/module.h>
> +#include <linux/init.h>
> +#include <linux/cpuidle.h>
> +#include <asm/cpuidle.h>
> +
> +#define AT91_MAX_STATES	2
> +
> +extern void (*at91_standby_ops)(void);
> +
> +/* Actual code that puts the SoC in different idle states */
> +static int at91_enter_idle(struct cpuidle_device *dev,
> +			struct cpuidle_driver *drv,
> +			       int index)
> +{
> +	at91_standby_ops();
> +	return index;
> +}
> +
> +static struct cpuidle_driver at91_idle_driver = {
> +	.name			= "at91_idle",
> +	.owner			= THIS_MODULE,
> +	.states[0]		= ARM_CPUIDLE_WFI_STATE,
> +	.states[1]		= {
> +		.enter			= at91_enter_idle,
> +		.exit_latency		= 10,
> +		.target_residency	= 100000,
> +		.flags			= CPUIDLE_FLAG_TIME_VALID,
> +		.name			= "RAM_SR",
> +		.desc			= "WFI and DDR Self Refresh",
> +	},
> +	.state_count = AT91_MAX_STATES,
> +};
> +
> +/* Initialize CPU idle by registering the idle states */
> +static int __init at91_init_cpuidle(void)
> +{
> +	return cpuidle_register(&at91_idle_driver, NULL);
> +}
> +
> +device_initcall(at91_init_cpuidle);
> 


-- 
Nicolas Ferre


From plagnioj at jcrosoft.com  Mon Apr 15 10:17:12 2013
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Mon, 15 Apr 2013 16:17:12 +0200
Subject: [RFC patch 1/2] ARM: at91: cpuidle: encapsulate the standby code
In-Reply-To: <1366032598-23053-2-git-send-email-daniel.lezcano@linaro.org>
References: <1366032598-23053-1-git-send-email-daniel.lezcano@linaro.org>
 <1366032598-23053-2-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <20130415141712.GD15139@game.jcrosoft.org>

On 15:29 Mon 15 Apr     , Daniel Lezcano wrote:
> In order to split the pm code from the cpuidle driver, add an ops for the
> standby function which will be initialized by the pm init functions directly,
> thus no need of the SoC specific headers.
> 
> Cleanup also the headers included in this file as they are no longer needed.
> 
> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
> ---
>  arch/arm/mach-at91/cpuidle.c |   19 ++++---------------
>  arch/arm/mach-at91/pm.c      |    8 +++++++-
>  2 files changed, 11 insertions(+), 16 deletions(-)
> 
> diff --git a/arch/arm/mach-at91/cpuidle.c b/arch/arm/mach-at91/cpuidle.c
> index 48f1228..b2bec92 100644
> --- a/arch/arm/mach-at91/cpuidle.c
> +++ b/arch/arm/mach-at91/cpuidle.c
> @@ -13,32 +13,21 @@
>   * #2 wait-for-interrupt and RAM self refresh
>   */
>  
> -#include <linux/kernel.h>
> +#include <linux/module.h>
>  #include <linux/init.h>
> -#include <linux/platform_device.h>
>  #include <linux/cpuidle.h>
> -#include <linux/io.h>
> -#include <linux/export.h>
> -#include <asm/proc-fns.h>
>  #include <asm/cpuidle.h>
> -#include <mach/cpu.h>
> -
> -#include "pm.h"
>  
>  #define AT91_MAX_STATES	2
>  
> +extern void (*at91_standby_ops)(void);
> +
>  /* Actual code that puts the SoC in different idle states */
>  static int at91_enter_idle(struct cpuidle_device *dev,
>  			struct cpuidle_driver *drv,
>  			       int index)
>  {
> -	if (cpu_is_at91rm9200())
> -		at91rm9200_standby();
> -	else if (cpu_is_at91sam9g45())
> -		at91sam9g45_standby();
> -	else
> -		at91sam9_standby();
> -
> +	at91_standby_ops();
>  	return index;
>  }
>  
> diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
> index 73f1f25..f456e86 100644
> --- a/arch/arm/mach-at91/pm.c
> +++ b/arch/arm/mach-at91/pm.c
> @@ -39,6 +39,8 @@
>  #include "at91_rstc.h"
>  #include "at91_shdwc.h"
>  
> +void (*at91_standby_ops)(void);
> +
>  static void __init show_reset_status(void)
>  {
>  	static char reset[] __initdata = "reset";
> @@ -321,8 +323,12 @@ static int __init at91_pm_init(void)
>  	pr_info("AT91: Power Management%s\n", (slow_clock ? " (with slow clock mode)" : ""));
>  
>  	/* AT91RM9200 SDRAM low-power mode cannot be used with self-refresh. */
> -	if (cpu_is_at91rm9200())
> +	if (cpu_is_at91rm9200()) {
>  		at91_ramc_write(0, AT91RM9200_SDRAMC_LPR, 0);
> +		at91_standby_ops = at91rm9200_standby;
> +	} else if (cpu_is_at91sam9g45())
> +		at91_standby_ops= at91sam9g45_standby;
keep the {} for codying stye rules

> +	else at91_standby_ops = at91sam9_standby;
I'm not a fan of global symbol but ok

Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>

Best Regards,
J.


From plagnioj at jcrosoft.com  Mon Apr 15 10:20:47 2013
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Mon, 15 Apr 2013 16:20:47 +0200
Subject: [RFC patch 2/2] ARM: at91: cpuidle: move the driver to
 drivers/cpuidle directory
In-Reply-To: <1366032598-23053-3-git-send-email-daniel.lezcano@linaro.org>
References: <1366032598-23053-1-git-send-email-daniel.lezcano@linaro.org>
 <1366032598-23053-3-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <20130415142047.GE15139@game.jcrosoft.org>

On 15:29 Mon 15 Apr     , Daniel Lezcano wrote:
> We don't have any dependency with the SoC specific code.
> 
> Move the driver to the drivers/cpuidle directory.
> 
> Add Nicolas Ferre as author of the driver, so it will be in copy of the emails.
> 
> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
please use -M when generating the patch
> ---
>  arch/arm/mach-at91/Makefile  |    1 -
>  arch/arm/mach-at91/cpuidle.c |   55 ----------------------------------------
>  drivers/cpuidle/Makefile     |    1 +
>  drivers/cpuidle/at91.c       |   57 ++++++++++++++++++++++++++++++++++++++++++
>  4 files changed, 58 insertions(+), 56 deletions(-)
>  delete mode 100644 arch/arm/mach-at91/cpuidle.c
>  create mode 100644 drivers/cpuidle/at91.c
> 
> diff --git a/arch/arm/mach-at91/Makefile b/arch/arm/mach-at91/Makefile
> index 39218ca..3c7fca1 100644
> --- a/arch/arm/mach-at91/Makefile
> +++ b/arch/arm/mach-at91/Makefile
> @@ -99,7 +99,6 @@ obj-y				+= leds.o
>  # Power Management
>  obj-$(CONFIG_PM)		+= pm.o
>  obj-$(CONFIG_AT91_SLOW_CLOCK)	+= pm_slowclock.o
> -obj-$(CONFIG_CPU_IDLE)	+= cpuidle.o
>  
>  ifeq ($(CONFIG_PM_DEBUG),y)
>  CFLAGS_pm.o += -DDEBUG
> diff --git a/arch/arm/mach-at91/cpuidle.c b/arch/arm/mach-at91/cpuidle.c
> deleted file mode 100644
> index b2bec92..0000000
> --- a/arch/arm/mach-at91/cpuidle.c
> +++ /dev/null
> @@ -1,55 +0,0 @@
> -/*
> - * based on arch/arm/mach-kirkwood/cpuidle.c
> - *
> - * CPU idle support for AT91 SoC
> - *
> - * 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.
> - *
> - * The cpu idle uses wait-for-interrupt and RAM self refresh in order
> - * to implement two idle states -
> - * #1 wait-for-interrupt
> - * #2 wait-for-interrupt and RAM self refresh
> - */
> -
> -#include <linux/module.h>
> -#include <linux/init.h>
> -#include <linux/cpuidle.h>
> -#include <asm/cpuidle.h>
> -
> -#define AT91_MAX_STATES	2
> -
> -extern void (*at91_standby_ops)(void);
> -
> -/* Actual code that puts the SoC in different idle states */
> -static int at91_enter_idle(struct cpuidle_device *dev,
> -			struct cpuidle_driver *drv,
> -			       int index)
> -{
> -	at91_standby_ops();
> -	return index;
> -}
> -
> -static struct cpuidle_driver at91_idle_driver = {
> -	.name			= "at91_idle",
> -	.owner			= THIS_MODULE,
> -	.states[0]		= ARM_CPUIDLE_WFI_STATE,
> -	.states[1]		= {
> -		.enter			= at91_enter_idle,
> -		.exit_latency		= 10,
> -		.target_residency	= 100000,
> -		.flags			= CPUIDLE_FLAG_TIME_VALID,
> -		.name			= "RAM_SR",
> -		.desc			= "WFI and DDR Self Refresh",
> -	},
> -	.state_count = AT91_MAX_STATES,
> -};
> -
> -/* Initialize CPU idle by registering the idle states */
> -static int __init at91_init_cpuidle(void)
> -{
> -	return cpuidle_register(&at91_idle_driver, NULL);
> -}
> -
> -device_initcall(at91_init_cpuidle);
> diff --git a/drivers/cpuidle/Makefile b/drivers/cpuidle/Makefile
> index 0d8bd55..ba4e977 100644
> --- a/drivers/cpuidle/Makefile
> +++ b/drivers/cpuidle/Makefile
> @@ -7,3 +7,4 @@ obj-$(CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED) += coupled.o
>  
>  obj-$(CONFIG_CPU_IDLE_CALXEDA) += cpuidle-calxeda.o
>  obj-$(CONFIG_ARCH_KIRKWOOD) += cpuidle-kirkwood.o
> +obj-$(CONFIG_ARCH_AT91) += at91.o
> diff --git a/drivers/cpuidle/at91.c b/drivers/cpuidle/at91.c
> new file mode 100644
> index 0000000..2bc745b
> --- /dev/null
> +++ b/drivers/cpuidle/at91.c
> @@ -0,0 +1,57 @@
> +/*
> + * based on arch/arm/mach-kirkwood/cpuidle.c
> + *
> + * CPU idle support for AT91 SoC
> + *
> + * Author: Nicolas Ferre <nicolas.ferre at atmel.com>
> + *
> + * 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.
> + *
> + * The cpu idle uses wait-for-interrupt and RAM self refresh in order
> + * to implement two idle states -
> + * #1 wait-for-interrupt
> + * #2 wait-for-interrupt and RAM self refresh
> + */
> +
> +#include <linux/module.h>
> +#include <linux/init.h>
> +#include <linux/cpuidle.h>
> +#include <asm/cpuidle.h>
> +
> +#define AT91_MAX_STATES	2
> +
> +extern void (*at91_standby_ops)(void);
really don't like can we pass it via the pm?
> +
> +/* Actual code that puts the SoC in different idle states */
> +static int at91_enter_idle(struct cpuidle_device *dev,
> +			struct cpuidle_driver *drv,
> +			       int index)
> +{
> +	at91_standby_ops();
> +	return index;
> +}
> +
> +static struct cpuidle_driver at91_idle_driver = {
> +	.name			= "at91_idle",
> +	.owner			= THIS_MODULE,
> +	.states[0]		= ARM_CPUIDLE_WFI_STATE,
> +	.states[1]		= {
> +		.enter			= at91_enter_idle,
> +		.exit_latency		= 10,
> +		.target_residency	= 100000,
> +		.flags			= CPUIDLE_FLAG_TIME_VALID,
> +		.name			= "RAM_SR",
> +		.desc			= "WFI and DDR Self Refresh",
> +	},
> +	.state_count = AT91_MAX_STATES,
> +};
> +
> +/* Initialize CPU idle by registering the idle states */
> +static int __init at91_init_cpuidle(void)
> +{
> +	return cpuidle_register(&at91_idle_driver, NULL);
> +}
> +
> +device_initcall(at91_init_cpuidle);
> -- 
> 1.7.9.5
> 


From andre.przywara at linaro.org  Mon Apr 15 10:26:50 2013
From: andre.przywara at linaro.org (Andre Przywara)
Date: Mon, 15 Apr 2013 16:26:50 +0200
Subject: [PATCH] ARM: KVM: iterate over all CPUs for CPU compatibility
 check
In-Reply-To: <20130415134837.GI9827@mudshark.cambridge.arm.com>
References: <51680AF9.7040109@arm.com>
 <CAEDV+g+E8PLc60vMRhq4O_AL2WjmYDLb6=Wh34ynhevh7uAGJA@mail.gmail.com>
 <d455f2823b9639af8d38d30f2c3234bd@localhost>
 <CAEDV+gJuFG49oQ=BEaCHcTP=nHVyX8ALw6076dR_C1s7TuyqXQ@mail.gmail.com>
 <d47697abd39a0d5d41f5ac110a40e261@localhost>
 <CAEDV+gK9==sXYxRVZ8JVFYPiw3_xgzZBbydEwPunmnocNLKXrQ@mail.gmail.com>
 <CAFEAcA-bPoa8YoPuHPmupzfUW+yR233XquK79eNorzcRpFiK=g@mail.gmail.com>
 <516BCAD0.9000708@linaro.org>
 <CAJRNFKJoBzgt4UhxsH65_LyhcGXPnzB_pg3q-zeYT2OVv59q4A@mail.gmail.com>
 <516BFD13.1000400@linaro.org>
 <20130415134837.GI9827@mudshark.cambridge.arm.com>
Message-ID: <516C0E2A.40809@linaro.org>

On 04/15/2013 03:48 PM, Will Deacon wrote:
> On Mon, Apr 15, 2013 at 02:13:55PM +0100, Andre Przywara wrote:
>> On 04/15/2013 11:52 AM, Alexander Spyridakis wrote:
>>> I've run on this problem before, while trying to run KVM guests on A7 cores.
>>>
>>> For some reason the 3rd A7 hangs in arch/arm/kvm/init.S, on the
>>> instruction that updates HSCTLR between the two isbs on __do_hyp_init
>>> (mcr p15, 4, r0, c1, c0, 0). If you boot the system with maxcpus=4 then
>>> init_hyp_mode() will not hang on the A7 cluster. Other than that from my
>>> limited testing KVM on A7 works on a usual linux guest. I also tried to
>>> only boot the 3rd A7 core to rule out any racing issues, but still the
>>> same behaviour applies.
>>
>> Could well be the same issue here. I chased it down till CPU 2 goes into
>> HYP mode to do the initialization.
>> I am running with maxcpus=3 (this increases the likelyhood that
>> kvm_target_cpu() runs on an A15), so CPU #2 is the only one A7.
>> As the HYP mode exception table is empty except for the HVC trap, it may
>> be looping here. I am trying now to get the PC of the faulty instruction.
>
> Yes, it sounds like you're taking a recursive fault because the vectors
> aren't installed yet. Is there any chance you can find out what value you end
> up writing (or trying to write) to the HSCTLR please?

Mmh, still thinking about a nice way to get some information out of HYP 
mode. schedule_delayed_work() to monitor a memory address didn't work 
(too early?).

But meanwhile I compared the A7 and A15 TRM 4.3.32 HSCTLR:
Bit 21 is fixed 0 on A15, but fixed 1 on A7.
Can someone confirm that this is not a typo?

Regards,
Andre.



From lee.jones at linaro.org  Mon Apr 15 10:28:24 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Mon, 15 Apr 2013 15:28:24 +0100
Subject: [PATCH 3/8] dmaengine: ste_dma40: Actually write the runtime
 configuration to registers
In-Reply-To: <CACRpkdawUPPzh-EgVdmvOVP2SOjgKXYrfus=yMee7n+PtAQPHg@mail.gmail.com>
References: <1365532783-27425-1-git-send-email-lee.jones@linaro.org>
 <1365532783-27425-3-git-send-email-lee.jones@linaro.org>
 <CAH+eYFB_fYmCjvh5PXKRhd-FnaWfeu+LtH+q3VywhCk-PYhHVQ@mail.gmail.com>
 <20130415110601.GE6512@gmail.com>
 <CAH+eYFB2+oMPXsnzQVVrEK8CjKGVYFa_n4Wxr=CpdtJwFfOGYw@mail.gmail.com>
 <20130415115906.GF6512@gmail.com>
 <CACRpkdawUPPzh-EgVdmvOVP2SOjgKXYrfus=yMee7n+PtAQPHg@mail.gmail.com>
Message-ID: <20130415142824.GG6512@gmail.com>

On Mon, 15 Apr 2013, Linus Walleij wrote:

> On Mon, Apr 15, 2013 at 1:59 PM, Lee Jones <lee.jones at linaro.org> wrote:
> > On Mon, 15 Apr 2013, Rabin Vincent wrote:
> >> 2013/4/15 Lee Jones <lee.jones at linaro.org>:
> >> > On Fri, 12 Apr 2013, Rabin Vincent wrote:
> >> >> 2013/4/9 Lee Jones <lee.jones at linaro.org>:
> >> >> > Someone has spent a fair amount of effort writing a runtime configuration
> >> >> > changing algorithm for DMA clients. However, the config appears to never
> >> >> > actually make it to hardware. In order for the configuration to take hold
> >> >> > we need to issue a d40_config_write(), as this is the routine which writes
> >> >> > it into the hardware's registers.
> >> >>
> >> >> No, it's not.  This function is only for initial configuration which
> >> >> should only be written when the channel is allocated.  In fact, by
> >> >> calling it here in runtime_config, you are introducing a serious bug:
> >> >> other logical channels on the same physical channel will stop because of
> >> >> the SSLNK/SDLNK of the physical channel being zeroed.
> >> >>
> >> >> The runtime config already makes it the hardware in the existing code,
> >> >> via d40_*_cfg().
> >> >
> >> > Sorry Rabin, but the only place I can see the config being written is
> >> > in d40_config_write().
> >> >
> >> > Can you paste the line of code in d40_*_cfg() which actually writes
> >> > the config to hardware please? I don't see it.
> >>
> >> It's not that simple.  There are some pointers passed to d40_*_cfg() and
> >> that function writes the configuration to the variables those pointers
> >> point to (d40c->log_def.lcsp1, d40c->src_def_cfg, etc.).  Please read
> >> the code to see how those variables end up being used later when the
> >> LLIs are prepared for the HW.
> >
> > I have read the code, which is why I know that the config only gets
> > written in d40_config_write(). :)
> >
> > So the configuration which gets set in the runtime_config routine
> > doesn't ever make it to hardware - hence this patch.
> >
> > Unless I'm missing something?
> 
> The runtime config sets up the config for all *subsequent* jobs.
> struct d40_chan contains e.g. runtime_addr, runtime_direction
> etc to store up the stuff being configured. This is done for
> all the other config as well using d40_log_cfg() or
> d40_phy_cfg(), and the result is cached in the channel
> struct, here called d40c.
> 
> Next, when preparing jobs, the DMA40 LLI engine will fill in
> job descriptors using e.g. d40_get_dev_addr()
> and pick settings from this cached runtime config.
> 
> When the subsequent jobs trigger, it allocates channel resources
> by calling d40_alloc_chan_resources(). The config is written to the
> hardware by calling d40_config_write().
> 
> So the basic misunderstanding here is that you think
> the config shall take effect immediately, that is not the
> idea. The configuration will be cached in the channel
> struct, then it will take effect when the next job that is
> queued up allocates its resources to commence.
> 
> Maybe you haven't grasped the asynchronous nature
> of the DMAengine? It's a bit like multithreading. You
> queue up things, then they commence at a later time.
> Not immediately.
> 
> Example: the SPI driver for PL022 may talk to a
> 8, 16 or 32bit capable device. Depending on which device
> it wants to queue a job for, it need to be configured differently,
> like for another width.
> 
> At the time you are queueing a new job, another job may
> already be in flight. If you issue d40_config_write() at this
> point, you will cause undesired effects to the job that may
> already be running. Such as reconfiguring the width
> of the channel.
> 
> You may not observe that bug because there is no
> job in flight, or because the actual configuration is identical
> for two consecutive jobs, but if you're really stressing something,
> queuing jobs while others are already in flight, you will
> see it immediately.
> 
> Therefore, this patch should be dropped.

Ah right, thanks for your explanation.

I have also just finished speaking to Rabin privately, who painted a
good picture of how the configuration side of this driver should
work.

I have dropped this patch and will shortly be replacing it with
something else.

Thanks again to both of you.

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From daniel.lezcano at linaro.org  Mon Apr 15 10:29:02 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Mon, 15 Apr 2013 16:29:02 +0200
Subject: [RFC patch 2/2] ARM: at91: cpuidle: move the driver to
 drivers/cpuidle directory
In-Reply-To: <516C0B30.501@atmel.com>
References: <1366032598-23053-1-git-send-email-daniel.lezcano@linaro.org>
 <1366032598-23053-3-git-send-email-daniel.lezcano@linaro.org>
 <516C0B30.501@atmel.com>
Message-ID: <516C0EAE.10804@linaro.org>

On 04/15/2013 04:14 PM, Nicolas Ferre wrote:
> On 04/15/2013 03:29 PM, Daniel Lezcano :
>> We don't have any dependency with the SoC specific code.
>>
>> Move the driver to the drivers/cpuidle directory.
>>
>> Add Nicolas Ferre as author of the driver, so it will be in copy of the emails.
> 
> Unfortunately, I am not the author of this driver. It is the work of
> Albin Tonnerre <albin.tonnerre at free-electrons.com>. So, for sure, I (and
> Jean-Christohpe) can babysit this code but I cannot be awarded for it...
> You can certainly add to the header of this file:
> Maintained by the AT91 crew: Nicolas Ferre, Jean-Christophe
> Plagniol-Villard (together with email addresses).

Ok, will do.

>> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
>> ---
>>  arch/arm/mach-at91/Makefile  |    1 -
>>  arch/arm/mach-at91/cpuidle.c |   55 ----------------------------------------
>>  drivers/cpuidle/Makefile     |    1 +
>>  drivers/cpuidle/at91.c       |   57 ++++++++++++++++++++++++++++++++++++++++++
> 
> No, sorry this file name is not appropriate: I prefer cpuidle-at91.c

Sure ? :)

It is a bit redundant drivers/cpuidle/cpuidle-at91.c, no ? and if all
the cpuidle drivers are there, the directory content will look:

cpuidle/cpuidle-tegra114.c
cpuidle/cpuidle-tegra20.c
cpuidle/cpuidle-tegra30.c
cpuidle/cpuidle-imx5.c
cpuidle/cpuidle-imx6.c
cpuidle/cpuidle-kirkwood.c
cpuidle/cpuidle-calxeda.c
cpuidle/cpuidle-shmobile.c
cpuidle/cpuidle-intel-idle.c
cpuidle/cpuidle-at91.c
cpuidle/cpuidle-omap34xx.c
cpuidle/cpuidle-omap44xx.c
cpuidle/cpuidle-ux500.c
cpuidle/cpuidle-exynos4.c
cpuidle/cpuidle-acpi.c
cpuidle/cpuidle-pseries.c
cpuidle/cpuidle-sh.c
cpuidle/cpuidle-s3c64xx.c
cpuidle/cpuidle-davinci.c

etc ...

But I won't argue if you really want cpuidle-at91.c, it is a detail IMO.

Thanks
  -- Daniel

-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From daniel.lezcano at linaro.org  Mon Apr 15 10:37:57 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Mon, 15 Apr 2013 16:37:57 +0200
Subject: [RFC patch 2/2] ARM: at91: cpuidle: move the driver to
 drivers/cpuidle directory
In-Reply-To: <20130415142047.GE15139@game.jcrosoft.org>
References: <1366032598-23053-1-git-send-email-daniel.lezcano@linaro.org>
 <1366032598-23053-3-git-send-email-daniel.lezcano@linaro.org>
 <20130415142047.GE15139@game.jcrosoft.org>
Message-ID: <516C10C5.4050107@linaro.org>

On 04/15/2013 04:20 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 15:29 Mon 15 Apr     , Daniel Lezcano wrote:
>> We don't have any dependency with the SoC specific code.
>>
>> Move the driver to the drivers/cpuidle directory.
>>
>> Add Nicolas Ferre as author of the driver, so it will be in copy of the emails.
>>
>> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
> please use -M when generating the patch

Oh, right. Thanks for reminding me the option.

[ ... ]

>> +#include <linux/module.h>
>> +#include <linux/init.h>
>> +#include <linux/cpuidle.h>
>> +#include <asm/cpuidle.h>
>> +
>> +#define AT91_MAX_STATES	2
>> +
>> +extern void (*at91_standby_ops)(void);
> really don't like can we pass it via the pm?

I agree, it is hackish. Can you elaborate when you say "pass it via the
pm" ?



-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From peter.maydell at linaro.org  Mon Apr 15 10:39:22 2013
From: peter.maydell at linaro.org (Peter Maydell)
Date: Mon, 15 Apr 2013 15:39:22 +0100
Subject: [PATCH] ARM: KVM: iterate over all CPUs for CPU compatibility
 check
In-Reply-To: <516C0E2A.40809@linaro.org>
References: <51680AF9.7040109@arm.com>
 <CAEDV+g+E8PLc60vMRhq4O_AL2WjmYDLb6=Wh34ynhevh7uAGJA@mail.gmail.com>
 <d455f2823b9639af8d38d30f2c3234bd@localhost>
 <CAEDV+gJuFG49oQ=BEaCHcTP=nHVyX8ALw6076dR_C1s7TuyqXQ@mail.gmail.com>
 <d47697abd39a0d5d41f5ac110a40e261@localhost>
 <CAEDV+gK9==sXYxRVZ8JVFYPiw3_xgzZBbydEwPunmnocNLKXrQ@mail.gmail.com>
 <CAFEAcA-bPoa8YoPuHPmupzfUW+yR233XquK79eNorzcRpFiK=g@mail.gmail.com>
 <516BCAD0.9000708@linaro.org>
 <CAJRNFKJoBzgt4UhxsH65_LyhcGXPnzB_pg3q-zeYT2OVv59q4A@mail.gmail.com>
 <516BFD13.1000400@linaro.org>
 <20130415134837.GI9827@mudshark.cambridge.arm.com>
 <516C0E2A.40809@linaro.org>
Message-ID: <CAFEAcA-CwKBnkoGZpO0XmqqKn60bmPvR_tZXM2S3PRv5Rspc2w@mail.gmail.com>

On 15 April 2013 15:26, Andre Przywara <andre.przywara at linaro.org> wrote:
> But meanwhile I compared the A7 and A15 TRM 4.3.32 HSCTLR:
> Bit 21 is fixed 0 on A15, but fixed 1 on A7.
> Can someone confirm that this is not a typo?

The A7 TRM diagram says '1' but the text says RAZ/WI.
The bit should match SCTLR.FI (bit 21), which the A7 TRM
definitely says is RAZ/WI. If you have the hardware you
can confirm the behaviour yourself by reading the register
and seeing what the bit value is :-)

-- PMM


From t.figa at samsung.com  Mon Apr 15 10:41:59 2013
From: t.figa at samsung.com (Tomasz Figa)
Date: Mon, 15 Apr 2013 16:41:59 +0200
Subject: [PATCH v2 0/3] ARM: EXYNOS: DT-enabled support for Universal C210
Message-ID: <1366036922-4103-1-git-send-email-t.figa@samsung.com>

This series intends to add support for Universal C210 board using Device
Tree. Main difference from other boards based on Exynos 4210 is that
hardware revision of the SoC used on Universal C210 does not support MCT
timers and legacy PWM timers must be used instead.

First patch adds device tree node for PWM block available on Exynos4 SoCs,
second patch adds support for Exynos4210 rev0 SoC in exynos_init_time()
and third patch introduces initial device tree for Universal C210 board.

Depends on my series for PWM timers rework:
[PATCH v5 00/14] ARM: samsung-time: Prepare for multiplatform support
(http://thread.gmane.org/gmane.linux.kernel.samsung-soc/17864)

On Universal C210 board:

Tested-by: Tomasz Figa <t.figa at samsung.com>

Tomasz Figa (3):
  ARM: dts: exynos4: Add node for PWM device
  ARM: EXYNOS: Fix support of Exynos4210 rev0 SoC
  ARM: dts: exynos4210: Add basic dts file for universal_c210 board

 arch/arm/boot/dts/Makefile                      |   1 +
 arch/arm/boot/dts/exynos4.dtsi                  |   8 +
 arch/arm/boot/dts/exynos4210-universal_c210.dts | 352 ++++++++++++++++++++++++
 arch/arm/mach-exynos/common.c                   |   6 +-
 arch/arm/mach-exynos/mach-universal_c210.c      |   2 +-
 5 files changed, 367 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm/boot/dts/exynos4210-universal_c210.dts

-- 
1.8.1.5



From t.figa at samsung.com  Mon Apr 15 10:42:00 2013
From: t.figa at samsung.com (Tomasz Figa)
Date: Mon, 15 Apr 2013 16:42:00 +0200
Subject: [PATCH v2 1/3] ARM: dts: exynos4: Add node for PWM device
In-Reply-To: <1366036922-4103-1-git-send-email-t.figa@samsung.com>
References: <1366036922-4103-1-git-send-email-t.figa@samsung.com>
Message-ID: <1366036922-4103-2-git-send-email-t.figa@samsung.com>

This patch adds device tree node for PWM block present on Exynos 4 SoCs.

Signed-off-by: Tomasz Figa <t.figa at samsung.com>
---
 arch/arm/boot/dts/exynos4.dtsi | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index d73eaa1..d7058c1 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -333,6 +333,14 @@
 		status = "disabled";
 	};
 
+	pwm at 139D0000 {
+		compatible = "samsung,exynos4210-pwm";
+		reg = <0x139D0000 0x1000>;
+		interrupts = <0 37 0>, <0 38 0>, <0 39 0>, <0 40 0>, <0 41 0>;
+		#pwm-cells = <2>;
+		status = "disabled";
+	};
+
 	amba {
 		#address-cells = <1>;
 		#size-cells = <1>;
-- 
1.8.1.5



From t.figa at samsung.com  Mon Apr 15 10:42:01 2013
From: t.figa at samsung.com (Tomasz Figa)
Date: Mon, 15 Apr 2013 16:42:01 +0200
Subject: [PATCH v2 2/3] ARM: EXYNOS: Fix support of Exynos4210 rev0 SoC
In-Reply-To: <1366036922-4103-1-git-send-email-t.figa@samsung.com>
References: <1366036922-4103-1-git-send-email-t.figa@samsung.com>
Message-ID: <1366036922-4103-3-git-send-email-t.figa@samsung.com>

This patch extends exynos_init_time() function to handle Exynos4210 rev0
SoC, which differs in availability of system timers and needs different
clocksource initialization.

This makes it possible to use exynos_init_time() function as init_time
callback for all Exynos-based boards, including Universal_C210, which
originally had to use samsung_timer_init().

Signed-off-by: Tomasz Figa <t.figa at samsung.com>
---
 arch/arm/mach-exynos/common.c              | 6 +++++-
 arch/arm/mach-exynos/mach-universal_c210.c | 2 +-
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
index b65229d..ec596fc 100644
--- a/arch/arm/mach-exynos/common.c
+++ b/arch/arm/mach-exynos/common.c
@@ -51,6 +51,7 @@
 #include <plat/fimc-core.h>
 #include <plat/iic-core.h>
 #include <plat/tv-core.h>
+#include <plat/samsung-time.h>
 #include <plat/spi-core.h>
 #include <plat/regs-serial.h>
 
@@ -457,7 +458,10 @@ void __init exynos_init_time(void)
 		exynos4_clk_init(NULL);
 		exynos4_clk_register_fixed_ext(xxti_f, xusbxti_f);
 #endif
-		mct_init();
+		if (soc_is_exynos4210() && samsung_rev() == EXYNOS4210_REV_0)
+			samsung_timer_init();
+		else
+			mct_init();
 	}
 }
 
diff --git a/arch/arm/mach-exynos/mach-universal_c210.c b/arch/arm/mach-exynos/mach-universal_c210.c
index 020e1f4..a728812 100644
--- a/arch/arm/mach-exynos/mach-universal_c210.c
+++ b/arch/arm/mach-exynos/mach-universal_c210.c
@@ -1177,7 +1177,7 @@ MACHINE_START(UNIVERSAL_C210, "UNIVERSAL_C210")
 	.map_io		= universal_map_io,
 	.init_machine	= universal_machine_init,
 	.init_late	= exynos_init_late,
-	.init_time	= samsung_timer_init,
+	.init_time	= exynos_init_time,
 	.reserve        = &universal_reserve,
 	.restart	= exynos4_restart,
 MACHINE_END
-- 
1.8.1.5



From t.figa at samsung.com  Mon Apr 15 10:42:02 2013
From: t.figa at samsung.com (Tomasz Figa)
Date: Mon, 15 Apr 2013 16:42:02 +0200
Subject: [PATCH v2 3/3] ARM: dts: exynos4210: Add basic dts file for
 universal_c210 board
In-Reply-To: <1366036922-4103-1-git-send-email-t.figa@samsung.com>
References: <1366036922-4103-1-git-send-email-t.figa@samsung.com>
Message-ID: <1366036922-4103-4-git-send-email-t.figa@samsung.com>

This patch adds basic device tree sources for Universal C210 board.

Currently support includes:
- eMMC
- serial
- max8952 and max8998 voltage regulators.
- gpio-keys

More support will be added in further patches.

Signed-off-by: Tomasz Figa <t.figa at samsung.com>
---
 arch/arm/boot/dts/Makefile                      |   1 +
 arch/arm/boot/dts/exynos4210-universal_c210.dts | 352 ++++++++++++++++++++++++
 2 files changed, 353 insertions(+)
 create mode 100644 arch/arm/boot/dts/exynos4210-universal_c210.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 11fef62..95b7311 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -42,6 +42,7 @@ dtb-$(CONFIG_ARCH_DOVE) += dove-cm-a510.dtb \
 dtb-$(CONFIG_ARCH_EXYNOS) += exynos4210-origen.dtb \
 	exynos4210-smdkv310.dtb \
 	exynos4210-trats.dtb \
+	exynos4210-universal_c210.dtb \
 	exynos4412-odroidx.dtb \
 	exynos4412-smdk4412.dtb \
 	exynos4412-origen.dtb \
diff --git a/arch/arm/boot/dts/exynos4210-universal_c210.dts b/arch/arm/boot/dts/exynos4210-universal_c210.dts
new file mode 100644
index 0000000..8174a7a
--- /dev/null
+++ b/arch/arm/boot/dts/exynos4210-universal_c210.dts
@@ -0,0 +1,352 @@
+/*
+ * Samsung's Exynos4210 based Universal C210 board device tree source
+ *
+ * Copyright (c) 2012 Samsung Electronics Co., Ltd.
+ *		http://www.samsung.com
+ *
+ * Device tree source file for Samsung's Universal C210 board which is based on
+ * Samsung's Exynos4210 EVT0 SoC.
+ *
+ * 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.
+*/
+
+/dts-v1/;
+/include/ "exynos4210.dtsi"
+
+/ {
+	model = "Samsung Universal C210 based on Exynos4210 EVT0";
+	compatible = "samsung,universal_c210", "samsung,exynos4210";
+
+	memory {
+		reg =  <0x40000000 0x10000000
+			0x50000000 0x10000000>;
+	};
+
+	chosen {
+		bootargs = "console=ttySAC2,115200N8 root=/dev/mmcblk0p5 rw rootwait earlyprintk panic=5 maxcpus=1";
+	};
+
+	mct at 10050000 {
+		compatible = "none";
+	};
+
+	fixed-rate-clocks {
+		xxti {
+			compatible = "samsung,clock-xxti";
+			clock-frequency = <0>;
+		};
+
+		xusbxti {
+			compatible = "samsung,clock-xusbxti";
+			clock-frequency = <24000000>;
+		};
+	};
+
+	vemmc_reg: voltage-regulator {
+	        compatible = "regulator-fixed";
+		regulator-name = "VMEM_VDD_2_8V";
+		regulator-min-microvolt = <2800000>;
+		regulator-max-microvolt = <2800000>;
+		gpio = <&gpe1 3 0>;
+		enable-active-high;
+	};
+
+	sdhci_emmc: sdhci at 12510000 {
+		bus-width = <8>;
+		non-removable;
+		pinctrl-0 = <&sd0_clk &sd0_cmd &sd0_bus8>;
+		pinctrl-names = "default";
+		vmmc-supply = <&vemmc_reg>;
+		status = "okay";
+	};
+
+	serial at 13800000 {
+		status = "okay";
+	};
+
+	serial at 13810000 {
+		status = "okay";
+	};
+
+	serial at 13820000 {
+		status = "okay";
+	};
+
+	serial at 13830000 {
+		status = "okay";
+	};
+
+	gpio-keys {
+		compatible = "gpio-keys";
+
+		vol-up-key {
+			gpios = <&gpx2 0 1>;
+			linux,code = <115>;
+			label = "volume up";
+			debounce-interval = <1>;
+		};
+
+		vol-down-key {
+			gpios = <&gpx2 1 1>;
+			linux,code = <114>;
+			label = "volume down";
+			debounce-interval = <1>;
+		};
+
+		config-key {
+			gpios = <&gpx2 2 1>;
+			linux,code = <171>;
+			label = "config";
+			debounce-interval = <1>;
+			gpio-key,wakeup;
+		};
+
+		camera-key {
+			gpios = <&gpx2 3 1>;
+			linux,code = <212>;
+			label = "camera";
+			debounce-interval = <1>;
+		};
+
+		power-key {
+			gpios = <&gpx2 7 1>;
+			linux,code = <116>;
+			label = "power";
+			debounce-interval = <1>;
+			gpio-key,wakeup;
+		};
+
+		ok-key {
+			gpios = <&gpx3 5 1>;
+			linux,code = <352>;
+			label = "ok";
+			debounce-interval = <1>;
+		};
+	};
+
+	tsp_reg: voltage-regulator {
+	        compatible = "regulator-fixed";
+		regulator-name = "TSP_2_8V";
+		regulator-min-microvolt = <2800000>;
+		regulator-max-microvolt = <2800000>;
+		gpio = <&gpe2 3 0>;
+		enable-active-high;
+	};
+
+	i2c at 13890000 {
+		samsung,i2c-sda-delay = <100>;
+		samsung,i2c-slave-addr = <0x10>;
+		samsung,i2c-max-bus-freq = <100000>;
+		pinctrl-0 = <&i2c3_bus>;
+		pinctrl-names = "default";
+		status = "okay";
+
+		tsp at 4a {
+			/* TBD: Atmel maXtouch touchscreen */
+			reg = <0x4a>;
+		};
+	};
+
+	i2c at 138B0000 {
+		samsung,i2c-sda-delay = <100>;
+		samsung,i2c-slave-addr = <0x10>;
+		samsung,i2c-max-bus-freq = <100000>;
+		pinctrl-0 = <&i2c5_bus>;
+		pinctrl-names = "default";
+		status = "okay";
+
+		vdd_arm_reg: pmic at 60 {
+			compatible = "maxim,max8952";
+			reg = <0x60>;
+
+			max8952,vid-gpios = <&gpx0 3 0>, <&gpx0 4 0>;
+			max8952,default-mode = <0>;
+			max8952,dvs-mode-microvolt = <1250000>, <1200000>,
+							<1050000>, <950000>;
+			max8952,sync-freq = <0>;
+			max8952,ramp-speed = <0>;
+
+			regulator-name = "vdd_arm";
+			regulator-min-microvolt = <770000>;
+			regulator-max-microvolt = <1400000>;
+			regulator-always-on;
+			regulator-boot-on;
+		};
+
+		pmic at 66 {
+			compatible = "national,lp3974";
+			reg = <0x66>;
+
+			max8998,pmic-buck1-default-dvs-idx = <0>;
+			max8998,pmic-buck1-dvs-gpios = <&gpx0 5 0>,
+							<&gpx0 6 0>;
+			max8998,pmic-buck1-dvs-voltage = <1100000>, <1000000>,
+							<1100000>, <1000000>;
+
+			max8998,pmic-buck2-default-dvs-idx = <0>;
+			max8998,pmic-buck2-dvs-gpio = <&gpe2 0 0>;
+			max8998,pmic-buck2-dvs-voltage = <1200000>, <1100000>;
+
+			regulators {
+				ldo2_reg: LDO2 {
+					regulator-name = "VALIVE_1.2V";
+					regulator-min-microvolt = <1200000>;
+					regulator-max-microvolt = <1200000>;
+					regulator-always-on;
+				};
+
+				ldo3_reg: LDO3 {
+					regulator-name = "VUSB+MIPI_1.1V";
+					regulator-min-microvolt = <1100000>;
+					regulator-max-microvolt = <1100000>;
+				};
+
+				ldo4_reg: LDO4 {
+					regulator-name = "VADC_3.3V";
+					regulator-min-microvolt = <3300000>;
+					regulator-max-microvolt = <3300000>;
+				};
+
+				ldo5_reg: LDO5 {
+					regulator-name = "VTF_2.8V";
+					regulator-min-microvolt = <2800000>;
+					regulator-max-microvolt = <2800000>;
+				};
+
+				ldo6_reg: LDO6 {
+					regulator-name = "LDO6";
+					regulator-min-microvolt = <2000000>;
+					regulator-max-microvolt = <2000000>;
+				};
+
+				ldo7_reg: LDO7 {
+					regulator-name = "VLCD+VMIPI_1.8V";
+					regulator-min-microvolt = <1800000>;
+					regulator-max-microvolt = <1800000>;
+				};
+
+				ldo8_reg: LDO8 {
+					regulator-name = "VUSB+VDAC_3.3V";
+					regulator-min-microvolt = <3300000>;
+					regulator-max-microvolt = <3300000>;
+				};
+
+				ldo9_reg: LDO9 {
+					regulator-name = "VCC_2.8V";
+					regulator-min-microvolt = <2800000>;
+					regulator-max-microvolt = <2800000>;
+					regulator-always-on;
+				};
+
+				ldo10_reg: LDO10 {
+					regulator-name = "VPLL_1.1V";
+					regulator-min-microvolt = <1100000>;
+					regulator-max-microvolt = <1100000>;
+					regulator-boot-on;
+					regulator-always-on;
+				};
+
+				ldo11_reg: LDO11 {
+					regulator-name = "CAM_AF_3.3V";
+					regulator-min-microvolt = <3300000>;
+					regulator-max-microvolt = <3300000>;
+				};
+
+				ldo12_reg: LDO12 {
+					regulator-name = "PS_2.8V";
+					regulator-min-microvolt = <2800000>;
+					regulator-max-microvolt = <2800000>;
+				};
+
+				ldo13_reg: LDO13 {
+					regulator-name = "VHIC_1.2V";
+					regulator-min-microvolt = <1200000>;
+					regulator-max-microvolt = <1200000>;
+				};
+
+				ldo14_reg: LDO14 {
+					regulator-name = "CAM_I_HOST_1.8V";
+					regulator-min-microvolt = <1800000>;
+					regulator-max-microvolt = <1800000>;
+				};
+
+				ldo15_reg: LDO15 {
+					regulator-name = "CAM_S_DIG+FM33_CORE_1.2V";
+					regulator-min-microvolt = <1200000>;
+					regulator-max-microvolt = <1200000>;
+				};
+
+				ldo16_reg: LDO16 {
+					regulator-name = "CAM_S_ANA_2.8V";
+					regulator-min-microvolt = <2800000>;
+					regulator-max-microvolt = <2800000>;
+				};
+
+				ldo17_reg: LDO17 {
+					regulator-name = "VCC_3.0V_LCD";
+					regulator-min-microvolt = <3000000>;
+					regulator-max-microvolt = <3000000>;
+				};
+
+				buck1_reg: BUCK1 {
+					regulator-name = "VINT_1.1V";
+					regulator-min-microvolt = <750000>;
+					regulator-max-microvolt = <1500000>;
+					regulator-boot-on;
+					regulator-always-on;
+				};
+
+				buck2_reg: BUCK2 {
+					regulator-name = "VG3D_1.1V";
+					regulator-min-microvolt = <750000>;
+					regulator-max-microvolt = <1500000>;
+					regulator-boot-on;
+				};
+
+				buck3_reg: BUCK3 {
+					regulator-name = "VCC_1.8V";
+					regulator-min-microvolt = <1800000>;
+					regulator-max-microvolt = <1800000>;
+					regulator-always-on;
+				};
+
+				buck4_reg: BUCK4 {
+					regulator-name = "VMEM_1.2V";
+					regulator-min-microvolt = <1200000>;
+					regulator-max-microvolt = <1200000>;
+					regulator-always-on;
+				};
+
+				ap32khz_reg: EN32KHz-AP {
+					regulator-name = "32KHz AP";
+					regulator-always-on;
+				};
+
+				cp32khz_reg: EN32KHz-CP {
+					regulator-name = "32KHz CP";
+				};
+
+				vichg_reg: ENVICHG {
+					regulator-name = "VICHG";
+				};
+
+				safeout1_reg: ESAFEOUT1 {
+					regulator-name = "SAFEOUT1";
+					regulator-always-on;
+				};
+
+				safeout2_reg: ESAFEOUT2 {
+					regulator-name = "SAFEOUT2";
+					regulator-boot-on;
+				};
+			};
+		};
+	};
+
+	pwm at 139D0000 {
+		compatible = "samsung,s5p6440-pwm";
+		status = "okay";
+	};
+};
-- 
1.8.1.5



From a.spyridakis at virtualopensystems.com  Mon Apr 15 10:53:15 2013
From: a.spyridakis at virtualopensystems.com (Alexander Spyridakis)
Date: Mon, 15 Apr 2013 16:53:15 +0200
Subject: [PATCH] ARM: KVM: iterate over all CPUs for CPU compatibility
 check
In-Reply-To: <516C0E2A.40809@linaro.org>
References: <51680AF9.7040109@arm.com>
 <CAEDV+g+E8PLc60vMRhq4O_AL2WjmYDLb6=Wh34ynhevh7uAGJA@mail.gmail.com>
 <d455f2823b9639af8d38d30f2c3234bd@localhost>
 <CAEDV+gJuFG49oQ=BEaCHcTP=nHVyX8ALw6076dR_C1s7TuyqXQ@mail.gmail.com>
 <d47697abd39a0d5d41f5ac110a40e261@localhost>
 <CAEDV+gK9==sXYxRVZ8JVFYPiw3_xgzZBbydEwPunmnocNLKXrQ@mail.gmail.com>
 <CAFEAcA-bPoa8YoPuHPmupzfUW+yR233XquK79eNorzcRpFiK=g@mail.gmail.com>
 <516BCAD0.9000708@linaro.org>
 <CAJRNFKJoBzgt4UhxsH65_LyhcGXPnzB_pg3q-zeYT2OVv59q4A@mail.gmail.com>
 <516BFD13.1000400@linaro.org>
 <20130415134837.GI9827@mudshark.cambridge.arm.com>
 <516C0E2A.40809@linaro.org>
Message-ID: <CAJRNFKJsVFhymgTuKdwufTX_u0DbZBn+HdhRZkgSwjC3U3w=mg@mail.gmail.com>

On 15 April 2013 16:26, Andre Przywara <andre.przywara at linaro.org> wrote:
> Mmh, still thinking about a nice way to get some information out of HYP mode. schedule_delayed_work() to monitor a memory address didn't work (too early?).
>
> But meanwhile I compared the A7 and A15 TRM 4.3.32 HSCTLR:
> Bit 21 is fixed 0 on A15, but fixed 1 on A7.
> Can someone confirm that this is not a typo?

The HSCTLR value, seemed sane for all cores and it was fixed (read
HSCTLR and SCTLR, ORs some bits and updates HSCTLR). If I remember
correctly, at the time I was testing it, all cores reported the same
value for SCTLR but in the case of the 3rd A7 it would crash as soon
as it would try to write on HSCTLR. If you want to continue execution
remove one of the isbs, of course the 3rd A7 will immediately hang
when you try to run a guest (the rest of the cores will operate
normally even when running a guest on them).

Regards.


From dinguyen at altera.com  Mon Apr 15 11:06:18 2013
From: dinguyen at altera.com (Dinh Nguyen)
Date: Mon, 15 Apr 2013 10:06:18 -0500
Subject: [PATCHv3 1/3] ARM: socfpga: Enable soft reset
In-Reply-To: <20130415032055.GA10949@quad.lixom.net>
References: <1365695726-26849-1-git-send-email-dinguyen@altera.com>
 <20130414180729.GA11770@amd.pavel.ucw.cz>
 <20130415032055.GA10949@quad.lixom.net>
Message-ID: <1366038378.9074.0.camel@linux-builds1>

Hi Olof,

On Sun, 2013-04-14 at 20:20 -0700, Olof Johansson wrote:
> On Sun, Apr 14, 2013 at 08:07:29PM +0200, Pavel Machek wrote:
> > On Thu 2013-04-11 10:55:24, dinguyen at altera.com wrote:
> > > From: Dinh Nguyen <dinguyen at altera.com>
> > > 
> > > Enable a cold or warm reset to the HW from userspace.
> > > 
> > > Also fix a few sparse errors:
> > > 
> > > warning: symbol 'sys_manager_base_addr' was not declared. Should it be static?
> > > warning: symbol 'rst_manager_base_addr' was not declared. Should it be static?
> > > 
> > > Signed-off-by: Dinh Nguyen <dinguyen at altera.com>
> > 
> > Reviewed-by: Pavel Machek <pavel at denx.de>
> 
> Applied 1-3 to next/soc in arm-soc.

Thanks alot!

Dinh
> 
> Thanks!
> 
> -Olof
> 





From bhelgaas at google.com  Mon Apr 15 11:11:02 2013
From: bhelgaas at google.com (Bjorn Helgaas)
Date: Mon, 15 Apr 2013 09:11:02 -0600
Subject: [PATCHv3 01/10] pci: mvebu: enable driver usage on Kirkwood
In-Reply-To: <1365865005-26653-2-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1365865005-26653-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1365865005-26653-2-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <CAErSpo5unBoJG=TEPjwHsiXPD_1T-QPDwLznUq_8sRSudQQqEA@mail.gmail.com>

On Sat, Apr 13, 2013 at 8:56 AM, Thomas Petazzoni
<thomas.petazzoni at free-electrons.com> wrote:
> We allow the pci-mvebu driver to be compiled on the Kirkwood platform,
> and add the 'marvell,kirkwood-pcie' as a compatible string supported
> by the driver.
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> Tested-by: Andrew Lunn <andrew at lunn.ch>

Acked-by: Bjorn Helgaas <bhelgaas at google.com>

I assume you'll merge this via some tree other than mine.

> ---
>  .../devicetree/bindings/pci/mvebu-pci.txt          |    1 +
>  drivers/pci/host/Kconfig                           |    2 +-
>  drivers/pci/host/pci-mvebu.c                       |    1 +
>  3 files changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/pci/mvebu-pci.txt b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
> index eb69d92..f8d4058 100644
> --- a/Documentation/devicetree/bindings/pci/mvebu-pci.txt
> +++ b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
> @@ -4,6 +4,7 @@ Mandatory properties:
>  - compatible: one of the following values:
>      marvell,armada-370-pcie
>      marvell,armada-xp-pcie
> +    marvell,kirkwood-pcie
>  - #address-cells, set to <3>
>  - #size-cells, set to <2>
>  - #interrupt-cells, set to <1>
> diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
> index 6918fbc..1f1d67f 100644
> --- a/drivers/pci/host/Kconfig
> +++ b/drivers/pci/host/Kconfig
> @@ -3,6 +3,6 @@ menu "PCI host controller drivers"
>
>  config PCI_MVEBU
>         bool "Marvell EBU PCIe controller"
> -       depends on ARCH_MVEBU
> +       depends on ARCH_MVEBU || ARCH_KIRKWOOD
>
>  endmenu
> diff --git a/drivers/pci/host/pci-mvebu.c b/drivers/pci/host/pci-mvebu.c
> index 9c15a25..a083d19 100644
> --- a/drivers/pci/host/pci-mvebu.c
> +++ b/drivers/pci/host/pci-mvebu.c
> @@ -853,6 +853,7 @@ static int __init mvebu_pcie_probe(struct platform_device *pdev)
>  static const struct of_device_id mvebu_pcie_of_match_table[] = {
>         { .compatible = "marvell,armada-xp-pcie", },
>         { .compatible = "marvell,armada-370-pcie", },
> +       { .compatible = "marvell,kirkwood-pcie", },
>         {},
>  };
>  MODULE_DEVICE_TABLE(of, mvebu_pcie_of_match_table);
> --
> 1.7.9.5
>


From catalin.marinas at arm.com  Mon Apr 15 11:23:19 2013
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Mon, 15 Apr 2013 16:23:19 +0100
Subject: [PATCH v2] arm64: Fix task tracing
In-Reply-To: <516BFC00.5050700@codeaurora.org>
References: <20130408153132.GQ17476@mudshark.cambridge.arm.com>
 <1365510814-21343-1-git-send-email-cov@codeaurora.org>
 <20130415101159.GA25095@localhost.cambridge.arm.com>
 <20130415104542.GE9827@mudshark.cambridge.arm.com>
 <20130415105840.GB29528@arm.com> <20130415114307.GC29528@arm.com>
 <516BFC00.5050700@codeaurora.org>
Message-ID: <20130415152319.GF29528@arm.com>

On Mon, Apr 15, 2013 at 02:09:20PM +0100, Christopher Covington wrote:
> On 04/15/2013 07:43 AM, Catalin Marinas wrote:
> > On Mon, Apr 15, 2013 at 11:58:40AM +0100, Catalin Marinas wrote:
> >> On Mon, Apr 15, 2013 at 11:45:42AM +0100, Will Deacon wrote:
> >>> On Mon, Apr 15, 2013 at 11:11:59AM +0100, Catalin Marinas wrote:
> >>>> On Tue, Apr 09, 2013 at 01:33:34PM +0100, Christopher Covington wrote:
> >>>>> For accurate accounting pass contextidr_thread_switch the prev
> >>>>> task pointer, since cpu_switch_to has at that point changed the
> >>>>> the stack pointer.
> >>>>>
> >>>>> Signed-off-by: Christopher Covington <cov at codeaurora.org>
> >>>>> ---
> >>>>>  arch/arm64/kernel/process.c | 2 +-
> >>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>>>>
> >>>>> diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
> >>>>> index 0337cdb..a49b25a 100644
> >>>>> --- a/arch/arm64/kernel/process.c
> >>>>> +++ b/arch/arm64/kernel/process.c
> >>>>> @@ -315,7 +315,7 @@ struct task_struct *__switch_to(struct task_struct *prev,
> >>>>>  	/* the actual thread switch */
> >>>>>  	last = cpu_switch_to(prev, next);
> >>>>>  
> >>>>> -	contextidr_thread_switch(next);
> >>>>> +	contextidr_thread_switch(prev);
> >>>>
> >>>> The original code was indeed wrong but using prev isn't any better. For
> >>>> a newly created thread, prev is probably 0 (if it's in a register,
> >>>> cpu_context has been zeroed by copy_thread()) or some random stack
> >>>> value.
> 
> <nit>
> I have to I disagree with the statement that using prev isn't _any_ better.
> Even if there are unhandled cases, from my observations, using prev is
> _measurably_ better. On the other hand, I agree that 100% accuracy is essential.
> </nit>

It is indeed better but we still miss the task creation (we only start
tracing once the task is scheduled out and scheduled back in.

> >>> Really? If prev is NULL in context_switch(...), the scheduler will implode,
> >>> and I can't see where else switch_to is called from.
> >>>
> >>> Which code path are you thinking of?
> >>
> >> copy_thread() zeros cpu_context which is used by cpu_switch_to() to load
> >> the next saved registers. The switch_to() function sets prev to last as
> >> returned by __switch_to(), so this is valid but in __switch_to() we
> >> don't have a valid prev (nor next) after cpu_switch_to() for newly
> >> created threads.
> > 
> > Correction - newly created threads return to ret_from_fork rather than
> > __switch_to(), which means that we miss the first
> > contextidr_thread_switch() call for a new thread. I would vote for
> > Christopher's original patch moving the call before cpu_switch_to(). The
> > alternative is to define finish_arch_switch() and add the call there. If
> > you are primarily tracing user space, it doesn't really matter whether
> > the stack was switched or not when we set the contextidr. For kernel
> > tracking, it could be a problem as we have the next task with the old
> > stack. But the same could be said about the prev task with the new
> > stack.
> 
> I'm fine with using either of my previous patches (or are there still cases
> where the second one is suspected to be wrong?) or rolling a new one using
> finish_arch_switch(). Let me know if you all would prefer for me to start on
> the latter.

The second patch is not wrong but insufficient since it doesn't cover
ret_from_fork. Will has a point that debuggers may use the contextidr
event to look into the state of the tread which would still have the old
stack with your first patch. But at least it is consistent with the
arch/arm implementation which uses notifiers.

So I would go with your first patch until we hear otherwise from the
debuggers people, in which case we would probably need to fix both
arch/arm and arch/arm64.

-- 
Catalin


From benh at kernel.crashing.org  Mon Apr 15 11:32:59 2013
From: benh at kernel.crashing.org (Benjamin Herrenschmidt)
Date: Mon, 15 Apr 2013 17:32:59 +0200
Subject: [PATCH v6 1/3] of/pci: Unify pci_process_bridge_OF_ranges from
 Microblaze and PowerPC
In-Reply-To: <20130415145741.4e4c362b@skate>
References: <1365693969-23907-1-git-send-email-Andrew.Murray@arm.com>
 <1365693969-23907-2-git-send-email-Andrew.Murray@arm.com>
 <20130415145741.4e4c362b@skate>
Message-ID: <1366039979.24994.36.camel@pasglop>

On Mon, 2013-04-15 at 14:57 +0200, Thomas Petazzoni wrote:
> Michal, Ben,
> 
> Would you have some time to look at this patch and give your comments
> and/or ACK ? Since it touches the PowerPC and Microblaze core code, we
> need your agreement to merge this code, and quite a bit of code pending
> for 3.10 depends on this patch.

I'm currently still on vacation. I will be able to look at this after
I'm back in about a week.

> Rob, alternatively, could we imagine doing a different version of the
> 'of/pci: Provide support for parsing PCI DT ranges property' that
> introduces the new API only, leaving the PowerPC and Microblaze rework
> as follow-up efforts, so that all the PCIe drivers that depend on this
> patch can get in for 3.10 ? I'd find it pretty sad if the Marvell PCIe
> driver that has been worked on since 4+ months does not get into 3.10
> just because this patch cannot be merged.

Cheers,
Ben.

> Thanks!
> 
> Thomas
> 
> On Thu, 11 Apr 2013 16:26:07 +0100, Andrew Murray wrote:
> > The pci_process_bridge_OF_ranges function, used to parse the "ranges"
> > property of a PCI host device, is found in both Microblaze and PowerPC
> > architectures. These implementations are nearly identical. This patch
> > moves this common code to a common place.
> > 
> > Signed-off-by: Andrew Murray <Andrew.Murray at arm.com>
> > Signed-off-by: Liviu Dudau <Liviu.Dudau at arm.com>
> > Reviewed-by: Rob Herring <rob.herring at calxeda.com>
> > Tested-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> > ---
> >  arch/microblaze/include/asm/pci-bridge.h |    5 +-
> >  arch/microblaze/pci/pci-common.c         |  192 ----------------------------
> >  arch/powerpc/include/asm/pci-bridge.h    |    5 +-
> >  arch/powerpc/kernel/pci-common.c         |  192 ----------------------------
> >  drivers/of/of_pci.c                      |  200 ++++++++++++++++++++++++++++++
> >  include/linux/of_pci.h                   |    4 +
> >  6 files changed, 206 insertions(+), 392 deletions(-)
> > 
> > diff --git a/arch/microblaze/include/asm/pci-bridge.h b/arch/microblaze/include/asm/pci-bridge.h
> > index cb5d397..5783cd6 100644
> > --- a/arch/microblaze/include/asm/pci-bridge.h
> > +++ b/arch/microblaze/include/asm/pci-bridge.h
> > @@ -10,6 +10,7 @@
> >  #include <linux/pci.h>
> >  #include <linux/list.h>
> >  #include <linux/ioport.h>
> > +#include <linux/of_pci.h>
> >  
> >  struct device_node;
> >  
> > @@ -132,10 +133,6 @@ extern void setup_indirect_pci(struct pci_controller *hose,
> >  extern struct pci_controller *pci_find_hose_for_OF_device(
> >  			struct device_node *node);
> >  
> > -/* Fill up host controller resources from the OF node */
> > -extern void pci_process_bridge_OF_ranges(struct pci_controller *hose,
> > -			struct device_node *dev, int primary);
> > -
> >  /* Allocate & free a PCI host bridge structure */
> >  extern struct pci_controller *pcibios_alloc_controller(struct device_node *dev);
> >  extern void pcibios_free_controller(struct pci_controller *phb);
> > diff --git a/arch/microblaze/pci/pci-common.c b/arch/microblaze/pci/pci-common.c
> > index 9ea521e..2735ad9 100644
> > --- a/arch/microblaze/pci/pci-common.c
> > +++ b/arch/microblaze/pci/pci-common.c
> > @@ -622,198 +622,6 @@ void pci_resource_to_user(const struct pci_dev *dev, int bar,
> >  	*end = rsrc->end - offset;
> >  }
> >  
> > -/**
> > - * pci_process_bridge_OF_ranges - Parse PCI bridge resources from device tree
> > - * @hose: newly allocated pci_controller to be setup
> > - * @dev: device node of the host bridge
> > - * @primary: set if primary bus (32 bits only, soon to be deprecated)
> > - *
> > - * This function will parse the "ranges" property of a PCI host bridge device
> > - * node and setup the resource mapping of a pci controller based on its
> > - * content.
> > - *
> > - * Life would be boring if it wasn't for a few issues that we have to deal
> > - * with here:
> > - *
> > - *   - We can only cope with one IO space range and up to 3 Memory space
> > - *     ranges. However, some machines (thanks Apple !) tend to split their
> > - *     space into lots of small contiguous ranges. So we have to coalesce.
> > - *
> > - *   - We can only cope with all memory ranges having the same offset
> > - *     between CPU addresses and PCI addresses. Unfortunately, some bridges
> > - *     are setup for a large 1:1 mapping along with a small "window" which
> > - *     maps PCI address 0 to some arbitrary high address of the CPU space in
> > - *     order to give access to the ISA memory hole.
> > - *     The way out of here that I've chosen for now is to always set the
> > - *     offset based on the first resource found, then override it if we
> > - *     have a different offset and the previous was set by an ISA hole.
> > - *
> > - *   - Some busses have IO space not starting at 0, which causes trouble with
> > - *     the way we do our IO resource renumbering. The code somewhat deals with
> > - *     it for 64 bits but I would expect problems on 32 bits.
> > - *
> > - *   - Some 32 bits platforms such as 4xx can have physical space larger than
> > - *     32 bits so we need to use 64 bits values for the parsing
> > - */
> > -void pci_process_bridge_OF_ranges(struct pci_controller *hose,
> > -				  struct device_node *dev, int primary)
> > -{
> > -	const u32 *ranges;
> > -	int rlen;
> > -	int pna = of_n_addr_cells(dev);
> > -	int np = pna + 5;
> > -	int memno = 0, isa_hole = -1;
> > -	u32 pci_space;
> > -	unsigned long long pci_addr, cpu_addr, pci_next, cpu_next, size;
> > -	unsigned long long isa_mb = 0;
> > -	struct resource *res;
> > -
> > -	pr_info("PCI host bridge %s %s ranges:\n",
> > -	       dev->full_name, primary ? "(primary)" : "");
> > -
> > -	/* Get ranges property */
> > -	ranges = of_get_property(dev, "ranges", &rlen);
> > -	if (ranges == NULL)
> > -		return;
> > -
> > -	/* Parse it */
> > -	pr_debug("Parsing ranges property...\n");
> > -	while ((rlen -= np * 4) >= 0) {
> > -		/* Read next ranges element */
> > -		pci_space = ranges[0];
> > -		pci_addr = of_read_number(ranges + 1, 2);
> > -		cpu_addr = of_translate_address(dev, ranges + 3);
> > -		size = of_read_number(ranges + pna + 3, 2);
> > -
> > -		pr_debug("pci_space: 0x%08x pci_addr:0x%016llx ",
> > -				pci_space, pci_addr);
> > -		pr_debug("cpu_addr:0x%016llx size:0x%016llx\n",
> > -					cpu_addr, size);
> > -
> > -		ranges += np;
> > -
> > -		/* If we failed translation or got a zero-sized region
> > -		 * (some FW try to feed us with non sensical zero sized regions
> > -		 * such as power3 which look like some kind of attempt
> > -		 * at exposing the VGA memory hole)
> > -		 */
> > -		if (cpu_addr == OF_BAD_ADDR || size == 0)
> > -			continue;
> > -
> > -		/* Now consume following elements while they are contiguous */
> > -		for (; rlen >= np * sizeof(u32);
> > -		     ranges += np, rlen -= np * 4) {
> > -			if (ranges[0] != pci_space)
> > -				break;
> > -			pci_next = of_read_number(ranges + 1, 2);
> > -			cpu_next = of_translate_address(dev, ranges + 3);
> > -			if (pci_next != pci_addr + size ||
> > -			    cpu_next != cpu_addr + size)
> > -				break;
> > -			size += of_read_number(ranges + pna + 3, 2);
> > -		}
> > -
> > -		/* Act based on address space type */
> > -		res = NULL;
> > -		switch ((pci_space >> 24) & 0x3) {
> > -		case 1:		/* PCI IO space */
> > -			pr_info("  IO 0x%016llx..0x%016llx -> 0x%016llx\n",
> > -			       cpu_addr, cpu_addr + size - 1, pci_addr);
> > -
> > -			/* We support only one IO range */
> > -			if (hose->pci_io_size) {
> > -				pr_info(" \\--> Skipped (too many) !\n");
> > -				continue;
> > -			}
> > -			/* On 32 bits, limit I/O space to 16MB */
> > -			if (size > 0x01000000)
> > -				size = 0x01000000;
> > -
> > -			/* 32 bits needs to map IOs here */
> > -			hose->io_base_virt = ioremap(cpu_addr, size);
> > -
> > -			/* Expect trouble if pci_addr is not 0 */
> > -			if (primary)
> > -				isa_io_base =
> > -					(unsigned long)hose->io_base_virt;
> > -			/* pci_io_size and io_base_phys always represent IO
> > -			 * space starting at 0 so we factor in pci_addr
> > -			 */
> > -			hose->pci_io_size = pci_addr + size;
> > -			hose->io_base_phys = cpu_addr - pci_addr;
> > -
> > -			/* Build resource */
> > -			res = &hose->io_resource;
> > -			res->flags = IORESOURCE_IO;
> > -			res->start = pci_addr;
> > -			break;
> > -		case 2:		/* PCI Memory space */
> > -		case 3:		/* PCI 64 bits Memory space */
> > -			pr_info(" MEM 0x%016llx..0x%016llx -> 0x%016llx %s\n",
> > -			       cpu_addr, cpu_addr + size - 1, pci_addr,
> > -			       (pci_space & 0x40000000) ? "Prefetch" : "");
> > -
> > -			/* We support only 3 memory ranges */
> > -			if (memno >= 3) {
> > -				pr_info(" \\--> Skipped (too many) !\n");
> > -				continue;
> > -			}
> > -			/* Handles ISA memory hole space here */
> > -			if (pci_addr == 0) {
> > -				isa_mb = cpu_addr;
> > -				isa_hole = memno;
> > -				if (primary || isa_mem_base == 0)
> > -					isa_mem_base = cpu_addr;
> > -				hose->isa_mem_phys = cpu_addr;
> > -				hose->isa_mem_size = size;
> > -			}
> > -
> > -			/* We get the PCI/Mem offset from the first range or
> > -			 * the, current one if the offset came from an ISA
> > -			 * hole. If they don't match, bugger.
> > -			 */
> > -			if (memno == 0 ||
> > -			    (isa_hole >= 0 && pci_addr != 0 &&
> > -			     hose->pci_mem_offset == isa_mb))
> > -				hose->pci_mem_offset = cpu_addr - pci_addr;
> > -			else if (pci_addr != 0 &&
> > -				 hose->pci_mem_offset != cpu_addr - pci_addr) {
> > -				pr_info(" \\--> Skipped (offset mismatch) !\n");
> > -				continue;
> > -			}
> > -
> > -			/* Build resource */
> > -			res = &hose->mem_resources[memno++];
> > -			res->flags = IORESOURCE_MEM;
> > -			if (pci_space & 0x40000000)
> > -				res->flags |= IORESOURCE_PREFETCH;
> > -			res->start = cpu_addr;
> > -			break;
> > -		}
> > -		if (res != NULL) {
> > -			res->name = dev->full_name;
> > -			res->end = res->start + size - 1;
> > -			res->parent = NULL;
> > -			res->sibling = NULL;
> > -			res->child = NULL;
> > -		}
> > -	}
> > -
> > -	/* If there's an ISA hole and the pci_mem_offset is -not- matching
> > -	 * the ISA hole offset, then we need to remove the ISA hole from
> > -	 * the resource list for that brige
> > -	 */
> > -	if (isa_hole >= 0 && hose->pci_mem_offset != isa_mb) {
> > -		unsigned int next = isa_hole + 1;
> > -		pr_info(" Removing ISA hole at 0x%016llx\n", isa_mb);
> > -		if (next < memno)
> > -			memmove(&hose->mem_resources[isa_hole],
> > -				&hose->mem_resources[next],
> > -				sizeof(struct resource) * (memno - next));
> > -		hose->mem_resources[--memno].flags = 0;
> > -	}
> > -}
> > -
> >  /* Decide whether to display the domain number in /proc */
> >  int pci_proc_domain(struct pci_bus *bus)
> >  {
> > diff --git a/arch/powerpc/include/asm/pci-bridge.h b/arch/powerpc/include/asm/pci-bridge.h
> > index 025a130..205bfba 100644
> > --- a/arch/powerpc/include/asm/pci-bridge.h
> > +++ b/arch/powerpc/include/asm/pci-bridge.h
> > @@ -10,6 +10,7 @@
> >  #include <linux/pci.h>
> >  #include <linux/list.h>
> >  #include <linux/ioport.h>
> > +#include <linux/of_pci.h>
> >  #include <asm-generic/pci-bridge.h>
> >  
> >  struct device_node;
> > @@ -231,10 +232,6 @@ extern int pcibios_map_io_space(struct pci_bus *bus);
> >  extern struct pci_controller *pci_find_hose_for_OF_device(
> >  			struct device_node* node);
> >  
> > -/* Fill up host controller resources from the OF node */
> > -extern void pci_process_bridge_OF_ranges(struct pci_controller *hose,
> > -			struct device_node *dev, int primary);
> > -
> >  /* Allocate & free a PCI host bridge structure */
> >  extern struct pci_controller *pcibios_alloc_controller(struct device_node *dev);
> >  extern void pcibios_free_controller(struct pci_controller *phb);
> > diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
> > index fa12ae4..6edf396 100644
> > --- a/arch/powerpc/kernel/pci-common.c
> > +++ b/arch/powerpc/kernel/pci-common.c
> > @@ -640,198 +640,6 @@ void pci_resource_to_user(const struct pci_dev *dev, int bar,
> >  	*end = rsrc->end - offset;
> >  }
> >  
> > -/**
> > - * pci_process_bridge_OF_ranges - Parse PCI bridge resources from device tree
> > - * @hose: newly allocated pci_controller to be setup
> > - * @dev: device node of the host bridge
> > - * @primary: set if primary bus (32 bits only, soon to be deprecated)
> > - *
> > - * This function will parse the "ranges" property of a PCI host bridge device
> > - * node and setup the resource mapping of a pci controller based on its
> > - * content.
> > - *
> > - * Life would be boring if it wasn't for a few issues that we have to deal
> > - * with here:
> > - *
> > - *   - We can only cope with one IO space range and up to 3 Memory space
> > - *     ranges. However, some machines (thanks Apple !) tend to split their
> > - *     space into lots of small contiguous ranges. So we have to coalesce.
> > - *
> > - *   - We can only cope with all memory ranges having the same offset
> > - *     between CPU addresses and PCI addresses. Unfortunately, some bridges
> > - *     are setup for a large 1:1 mapping along with a small "window" which
> > - *     maps PCI address 0 to some arbitrary high address of the CPU space in
> > - *     order to give access to the ISA memory hole.
> > - *     The way out of here that I've chosen for now is to always set the
> > - *     offset based on the first resource found, then override it if we
> > - *     have a different offset and the previous was set by an ISA hole.
> > - *
> > - *   - Some busses have IO space not starting at 0, which causes trouble with
> > - *     the way we do our IO resource renumbering. The code somewhat deals with
> > - *     it for 64 bits but I would expect problems on 32 bits.
> > - *
> > - *   - Some 32 bits platforms such as 4xx can have physical space larger than
> > - *     32 bits so we need to use 64 bits values for the parsing
> > - */
> > -void pci_process_bridge_OF_ranges(struct pci_controller *hose,
> > -				  struct device_node *dev, int primary)
> > -{
> > -	const u32 *ranges;
> > -	int rlen;
> > -	int pna = of_n_addr_cells(dev);
> > -	int np = pna + 5;
> > -	int memno = 0, isa_hole = -1;
> > -	u32 pci_space;
> > -	unsigned long long pci_addr, cpu_addr, pci_next, cpu_next, size;
> > -	unsigned long long isa_mb = 0;
> > -	struct resource *res;
> > -
> > -	printk(KERN_INFO "PCI host bridge %s %s ranges:\n",
> > -	       dev->full_name, primary ? "(primary)" : "");
> > -
> > -	/* Get ranges property */
> > -	ranges = of_get_property(dev, "ranges", &rlen);
> > -	if (ranges == NULL)
> > -		return;
> > -
> > -	/* Parse it */
> > -	while ((rlen -= np * 4) >= 0) {
> > -		/* Read next ranges element */
> > -		pci_space = ranges[0];
> > -		pci_addr = of_read_number(ranges + 1, 2);
> > -		cpu_addr = of_translate_address(dev, ranges + 3);
> > -		size = of_read_number(ranges + pna + 3, 2);
> > -		ranges += np;
> > -
> > -		/* If we failed translation or got a zero-sized region
> > -		 * (some FW try to feed us with non sensical zero sized regions
> > -		 * such as power3 which look like some kind of attempt at exposing
> > -		 * the VGA memory hole)
> > -		 */
> > -		if (cpu_addr == OF_BAD_ADDR || size == 0)
> > -			continue;
> > -
> > -		/* Now consume following elements while they are contiguous */
> > -		for (; rlen >= np * sizeof(u32);
> > -		     ranges += np, rlen -= np * 4) {
> > -			if (ranges[0] != pci_space)
> > -				break;
> > -			pci_next = of_read_number(ranges + 1, 2);
> > -			cpu_next = of_translate_address(dev, ranges + 3);
> > -			if (pci_next != pci_addr + size ||
> > -			    cpu_next != cpu_addr + size)
> > -				break;
> > -			size += of_read_number(ranges + pna + 3, 2);
> > -		}
> > -
> > -		/* Act based on address space type */
> > -		res = NULL;
> > -		switch ((pci_space >> 24) & 0x3) {
> > -		case 1:		/* PCI IO space */
> > -			printk(KERN_INFO
> > -			       "  IO 0x%016llx..0x%016llx -> 0x%016llx\n",
> > -			       cpu_addr, cpu_addr + size - 1, pci_addr);
> > -
> > -			/* We support only one IO range */
> > -			if (hose->pci_io_size) {
> > -				printk(KERN_INFO
> > -				       " \\--> Skipped (too many) !\n");
> > -				continue;
> > -			}
> > -#ifdef CONFIG_PPC32
> > -			/* On 32 bits, limit I/O space to 16MB */
> > -			if (size > 0x01000000)
> > -				size = 0x01000000;
> > -
> > -			/* 32 bits needs to map IOs here */
> > -			hose->io_base_virt = ioremap(cpu_addr, size);
> > -
> > -			/* Expect trouble if pci_addr is not 0 */
> > -			if (primary)
> > -				isa_io_base =
> > -					(unsigned long)hose->io_base_virt;
> > -#endif /* CONFIG_PPC32 */
> > -			/* pci_io_size and io_base_phys always represent IO
> > -			 * space starting at 0 so we factor in pci_addr
> > -			 */
> > -			hose->pci_io_size = pci_addr + size;
> > -			hose->io_base_phys = cpu_addr - pci_addr;
> > -
> > -			/* Build resource */
> > -			res = &hose->io_resource;
> > -			res->flags = IORESOURCE_IO;
> > -			res->start = pci_addr;
> > -			break;
> > -		case 2:		/* PCI Memory space */
> > -		case 3:		/* PCI 64 bits Memory space */
> > -			printk(KERN_INFO
> > -			       " MEM 0x%016llx..0x%016llx -> 0x%016llx %s\n",
> > -			       cpu_addr, cpu_addr + size - 1, pci_addr,
> > -			       (pci_space & 0x40000000) ? "Prefetch" : "");
> > -
> > -			/* We support only 3 memory ranges */
> > -			if (memno >= 3) {
> > -				printk(KERN_INFO
> > -				       " \\--> Skipped (too many) !\n");
> > -				continue;
> > -			}
> > -			/* Handles ISA memory hole space here */
> > -			if (pci_addr == 0) {
> > -				isa_mb = cpu_addr;
> > -				isa_hole = memno;
> > -				if (primary || isa_mem_base == 0)
> > -					isa_mem_base = cpu_addr;
> > -				hose->isa_mem_phys = cpu_addr;
> > -				hose->isa_mem_size = size;
> > -			}
> > -
> > -			/* We get the PCI/Mem offset from the first range or
> > -			 * the, current one if the offset came from an ISA
> > -			 * hole. If they don't match, bugger.
> > -			 */
> > -			if (memno == 0 ||
> > -			    (isa_hole >= 0 && pci_addr != 0 &&
> > -			     hose->pci_mem_offset == isa_mb))
> > -				hose->pci_mem_offset = cpu_addr - pci_addr;
> > -			else if (pci_addr != 0 &&
> > -				 hose->pci_mem_offset != cpu_addr - pci_addr) {
> > -				printk(KERN_INFO
> > -				       " \\--> Skipped (offset mismatch) !\n");
> > -				continue;
> > -			}
> > -
> > -			/* Build resource */
> > -			res = &hose->mem_resources[memno++];
> > -			res->flags = IORESOURCE_MEM;
> > -			if (pci_space & 0x40000000)
> > -				res->flags |= IORESOURCE_PREFETCH;
> > -			res->start = cpu_addr;
> > -			break;
> > -		}
> > -		if (res != NULL) {
> > -			res->name = dev->full_name;
> > -			res->end = res->start + size - 1;
> > -			res->parent = NULL;
> > -			res->sibling = NULL;
> > -			res->child = NULL;
> > -		}
> > -	}
> > -
> > -	/* If there's an ISA hole and the pci_mem_offset is -not- matching
> > -	 * the ISA hole offset, then we need to remove the ISA hole from
> > -	 * the resource list for that brige
> > -	 */
> > -	if (isa_hole >= 0 && hose->pci_mem_offset != isa_mb) {
> > -		unsigned int next = isa_hole + 1;
> > -		printk(KERN_INFO " Removing ISA hole at 0x%016llx\n", isa_mb);
> > -		if (next < memno)
> > -			memmove(&hose->mem_resources[isa_hole],
> > -				&hose->mem_resources[next],
> > -				sizeof(struct resource) * (memno - next));
> > -		hose->mem_resources[--memno].flags = 0;
> > -	}
> > -}
> > -
> >  /* Decide whether to display the domain number in /proc */
> >  int pci_proc_domain(struct pci_bus *bus)
> >  {
> > diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
> > index 13e37e2..1626172 100644
> > --- a/drivers/of/of_pci.c
> > +++ b/drivers/of/of_pci.c
> > @@ -4,6 +4,10 @@
> >  #include <linux/of_pci.h>
> >  #include <asm/prom.h>
> >  
> > +#if defined(CONFIG_PPC32) || defined(CONFIG_PPC64) || defined(CONFIG_MICROBLAZE)
> > +#include <asm/pci-bridge.h>
> > +#endif
> > +
> >  static inline int __of_pci_pci_compare(struct device_node *node,
> >  				       unsigned int devfn)
> >  {
> > @@ -40,3 +44,199 @@ struct device_node *of_pci_find_child_device(struct device_node *parent,
> >  	return NULL;
> >  }
> >  EXPORT_SYMBOL_GPL(of_pci_find_child_device);
> > +
> > +/**
> > + * pci_process_bridge_OF_ranges - Parse PCI bridge resources from device tree
> > + * @hose: newly allocated pci_controller to be setup
> > + * @dev: device node of the host bridge
> > + * @primary: set if primary bus (32 bits only, soon to be deprecated)
> > + *
> > + * This function will parse the "ranges" property of a PCI host bridge device
> > + * node and setup the resource mapping of a pci controller based on its
> > + * content.
> > + *
> > + * Life would be boring if it wasn't for a few issues that we have to deal
> > + * with here:
> > + *
> > + *   - We can only cope with one IO space range and up to 3 Memory space
> > + *     ranges. However, some machines (thanks Apple !) tend to split their
> > + *     space into lots of small contiguous ranges. So we have to coalesce.
> > + *
> > + *   - We can only cope with all memory ranges having the same offset
> > + *     between CPU addresses and PCI addresses. Unfortunately, some bridges
> > + *     are setup for a large 1:1 mapping along with a small "window" which
> > + *     maps PCI address 0 to some arbitrary high address of the CPU space in
> > + *     order to give access to the ISA memory hole.
> > + *     The way out of here that I've chosen for now is to always set the
> > + *     offset based on the first resource found, then override it if we
> > + *     have a different offset and the previous was set by an ISA hole.
> > + *
> > + *   - Some busses have IO space not starting at 0, which causes trouble with
> > + *     the way we do our IO resource renumbering. The code somewhat deals with
> > + *     it for 64 bits but I would expect problems on 32 bits.
> > + *
> > + *   - Some 32 bits platforms such as 4xx can have physical space larger than
> > + *     32 bits so we need to use 64 bits values for the parsing
> > + */
> > +#if defined(CONFIG_PPC32) || defined(CONFIG_PPC64) || defined(CONFIG_MICROBLAZE)
> > +void pci_process_bridge_OF_ranges(struct pci_controller *hose,
> > +				  struct device_node *dev, int primary)
> > +{
> > +	const u32 *ranges;
> > +	int rlen;
> > +	int pna = of_n_addr_cells(dev);
> > +	int np = pna + 5;
> > +	int memno = 0, isa_hole = -1;
> > +	u32 pci_space;
> > +	unsigned long long pci_addr, cpu_addr, pci_next, cpu_next, size;
> > +	unsigned long long isa_mb = 0;
> > +	struct resource *res;
> > +
> > +	pr_info("PCI host bridge %s %s ranges:\n",
> > +	       dev->full_name, primary ? "(primary)" : "");
> > +
> > +	/* Get ranges property */
> > +	ranges = of_get_property(dev, "ranges", &rlen);
> > +	if (ranges == NULL)
> > +		return;
> > +
> > +	/* Parse it */
> > +	pr_debug("Parsing ranges property...\n");
> > +	while ((rlen -= np * 4) >= 0) {
> > +		/* Read next ranges element */
> > +		pci_space = ranges[0];
> > +		pci_addr = of_read_number(ranges + 1, 2);
> > +		cpu_addr = of_translate_address(dev, ranges + 3);
> > +		size = of_read_number(ranges + pna + 3, 2);
> > +
> > +		pr_debug("pci_space: 0x%08x pci_addr:0x%016llx ",
> > +				pci_space, pci_addr);
> > +		pr_debug("cpu_addr:0x%016llx size:0x%016llx\n",
> > +					cpu_addr, size);
> > +
> > +		ranges += np;
> > +
> > +		/* If we failed translation or got a zero-sized region
> > +		 * (some FW try to feed us with non sensical zero sized regions
> > +		 * such as power3 which look like some kind of attempt
> > +		 * at exposing the VGA memory hole)
> > +		 */
> > +		if (cpu_addr == OF_BAD_ADDR || size == 0)
> > +			continue;
> > +
> > +		/* Now consume following elements while they are contiguous */
> > +		for (; rlen >= np * sizeof(u32);
> > +		     ranges += np, rlen -= np * 4) {
> > +			if (ranges[0] != pci_space)
> > +				break;
> > +			pci_next = of_read_number(ranges + 1, 2);
> > +			cpu_next = of_translate_address(dev, ranges + 3);
> > +			if (pci_next != pci_addr + size ||
> > +			    cpu_next != cpu_addr + size)
> > +				break;
> > +			size += of_read_number(ranges + pna + 3, 2);
> > +		}
> > +
> > +		/* Act based on address space type */
> > +		res = NULL;
> > +		switch ((pci_space >> 24) & 0x3) {
> > +		case 1:		/* PCI IO space */
> > +			pr_info("  IO 0x%016llx..0x%016llx -> 0x%016llx\n",
> > +			       cpu_addr, cpu_addr + size - 1, pci_addr);
> > +
> > +			/* We support only one IO range */
> > +			if (hose->pci_io_size) {
> > +				pr_info(" \\--> Skipped (too many) !\n");
> > +				continue;
> > +			}
> > +#if (!IS_ENABLED(CONFIG_64BIT))
> > +			/* On 32 bits, limit I/O space to 16MB */
> > +			if (size > 0x01000000)
> > +				size = 0x01000000;
> > +
> > +			/* 32 bits needs to map IOs here */
> > +			hose->io_base_virt = ioremap(cpu_addr, size);
> > +
> > +			/* Expect trouble if pci_addr is not 0 */
> > +			if (primary)
> > +				isa_io_base =
> > +					(unsigned long)hose->io_base_virt;
> > +#endif /* !CONFIG_64BIT */
> > +			/* pci_io_size and io_base_phys always represent IO
> > +			 * space starting at 0 so we factor in pci_addr
> > +			 */
> > +			hose->pci_io_size = pci_addr + size;
> > +			hose->io_base_phys = cpu_addr - pci_addr;
> > +
> > +			/* Build resource */
> > +			res = &hose->io_resource;
> > +			res->flags = IORESOURCE_IO;
> > +			res->start = pci_addr;
> > +			break;
> > +		case 2:		/* PCI Memory space */
> > +		case 3:		/* PCI 64 bits Memory space */
> > +			pr_info(" MEM 0x%016llx..0x%016llx -> 0x%016llx %s\n",
> > +			       cpu_addr, cpu_addr + size - 1, pci_addr,
> > +			       (pci_space & 0x40000000) ? "Prefetch" : "");
> > +
> > +			/* We support only 3 memory ranges */
> > +			if (memno >= 3) {
> > +				pr_info(" \\--> Skipped (too many) !\n");
> > +				continue;
> > +			}
> > +			/* Handles ISA memory hole space here */
> > +			if (pci_addr == 0) {
> > +				isa_mb = cpu_addr;
> > +				isa_hole = memno;
> > +				if (primary || isa_mem_base == 0)
> > +					isa_mem_base = cpu_addr;
> > +				hose->isa_mem_phys = cpu_addr;
> > +				hose->isa_mem_size = size;
> > +			}
> > +
> > +			/* We get the PCI/Mem offset from the first range or
> > +			 * the, current one if the offset came from an ISA
> > +			 * hole. If they don't match, bugger.
> > +			 */
> > +			if (memno == 0 ||
> > +			    (isa_hole >= 0 && pci_addr != 0 &&
> > +			     hose->pci_mem_offset == isa_mb))
> > +				hose->pci_mem_offset = cpu_addr - pci_addr;
> > +			else if (pci_addr != 0 &&
> > +				 hose->pci_mem_offset != cpu_addr - pci_addr) {
> > +				pr_info(" \\--> Skipped (offset mismatch) !\n");
> > +				continue;
> > +			}
> > +
> > +			/* Build resource */
> > +			res = &hose->mem_resources[memno++];
> > +			res->flags = IORESOURCE_MEM;
> > +			if (pci_space & 0x40000000)
> > +				res->flags |= IORESOURCE_PREFETCH;
> > +			res->start = cpu_addr;
> > +			break;
> > +		}
> > +		if (res != NULL) {
> > +			res->name = dev->full_name;
> > +			res->end = res->start + size - 1;
> > +			res->parent = NULL;
> > +			res->sibling = NULL;
> > +			res->child = NULL;
> > +		}
> > +	}
> > +
> > +	/* If there's an ISA hole and the pci_mem_offset is -not- matching
> > +	 * the ISA hole offset, then we need to remove the ISA hole from
> > +	 * the resource list for that brige
> > +	 */
> > +	if (isa_hole >= 0 && hose->pci_mem_offset != isa_mb) {
> > +		unsigned int next = isa_hole + 1;
> > +		pr_info(" Removing ISA hole at 0x%016llx\n", isa_mb);
> > +		if (next < memno)
> > +			memmove(&hose->mem_resources[isa_hole],
> > +				&hose->mem_resources[next],
> > +				sizeof(struct resource) * (memno - next));
> > +		hose->mem_resources[--memno].flags = 0;
> > +	}
> > +}
> > +#endif
> > diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
> > index bb115de..33e8ead 100644
> > --- a/include/linux/of_pci.h
> > +++ b/include/linux/of_pci.h
> > @@ -11,4 +11,8 @@ struct device_node;
> >  struct device_node *of_pci_find_child_device(struct device_node *parent,
> >  					     unsigned int devfn);
> >  
> > +struct pci_controller;
> > +void pci_process_bridge_OF_ranges(struct pci_controller *hose,
> > +			struct device_node *dev, int primary);
> > +
> >  #endif
> 
> 
> 




From jason at lakedaemon.net  Mon Apr 15 11:46:20 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Mon, 15 Apr 2013 11:46:20 -0400
Subject: [PATCHv8 00/19] PCIe support for the Armada 370 and Armada XP SoCs
In-Reply-To: <1365541601-14095-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1365541601-14095-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <20130415154620.GE28693@titan.lakedaemon.net>

Thomas,

On Tue, Apr 09, 2013 at 11:06:21PM +0200, Thomas Petazzoni wrote:
> Hello,
> 
> This series of patches introduces PCIe support for the Marvell Armada
> 370 and Armada XP. In the future, we plan to extend the driver to
> cover Kirkwood platforms, and possibly other Marvell EBU platforms as
> well.
> 
> Here is the current status of the different patches:
> 
>  * Patches 1-5 are awaiting a formal Acked-by from the Device Tree
>    maintainers. Patches 1-3 are the new version of the OF PCI range
>    parsing functions from Andrew Murray, which he worked on after the
>    comments from Rob Herring. Patches 4 and 5 are much more trivial
>    and have been around since many versions of this series.

Applied to mvebu/drivers


>  * Patch 6 and 10, that are touching drivers/pci/ have been formally
>    Acked-by Bjorn Helgaas, the PCI maintainer.

Applied to mvebu/drivers

>  * Patch 7, which is touching arch/arm/kernel, has been merged by
>    Russell King already, see
>    http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=7683/1.

Added remote branch dependency on rmk/for-next in mvebu/soc

>  * Patches 8 and 9 are touching drivers/clk, and are awaiting an
>    Acked-by from Mike Turquette. However, they are fairly trivial
>    patches, so they shouldn't cause too much problem.

Applied to mvebu/drivers

> 
>  * All the other patches touch mvebu-specific things, either
>    mach-mvebu or the related Device Tree files or defconfig, so it's
>    up to the Marvell maintainers to pick them up.

Patches 10,11,19 applied to mvebu/soc with dep on rmk/for-next, and
mvebu/drivers (in /soc to catch mvebu-mbus dependency).

I'm going to flag a separate PR for this marked "late" so that it goes
in *after* rmk/for-next.

thx,

Jason.


From jason at lakedaemon.net  Mon Apr 15 11:47:00 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Mon, 15 Apr 2013 11:47:00 -0400
Subject: [PATCH v4 0/5]  LPAE remaining device tree file
In-Reply-To: <1365776950-30094-1-git-send-email-gregory.clement@free-electrons.com>
References: <1365776950-30094-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <20130415154700.GF28693@titan.lakedaemon.net>

On Fri, Apr 12, 2013 at 04:29:05PM +0200, Gregory CLEMENT wrote:
> Hi Jason,
> 
> I have just rebased the commits that you haven't applied yet. They are
> rebased on mvebu/dt. I check that all the dtb can be built.
> 
> Thanks,
> 
> Gregory CLEMENT (3):
>   ARM: dts: mvebu: Convert all the mvebu files to use the range
>     property
>   ARM: dts: mvebu: introduce internal-regs node
>   ARM: dts: mvebu: Convert mvebu device tree files to 64 bits
> 
> Thomas Petazzoni (2):
>   ARM: dts: mvebu: fix cpus section indentation
>   ARM: dts: mvebu: move all peripherals inside soc
> 
>  arch/arm/boot/dts/armada-370-db.dts              |  134 +++---
>  arch/arm/boot/dts/armada-370-mirabox.dts         |  176 ++++----
>  arch/arm/boot/dts/armada-370-rd.dts              |   96 ++---
>  arch/arm/boot/dts/armada-370-xp.dtsi             |  336 +++++++--------
>  arch/arm/boot/dts/armada-370.dtsi                |  330 +++++++--------
>  arch/arm/boot/dts/armada-xp-db.dts               |  202 ++++-----
>  arch/arm/boot/dts/armada-xp-gp.dts               |  222 +++++-----
>  arch/arm/boot/dts/armada-xp-mv78230.dtsi         |  284 ++++++-------
>  arch/arm/boot/dts/armada-xp-mv78260.dtsi         |  342 +++++++--------
>  arch/arm/boot/dts/armada-xp-mv78460.dtsi         |  484 +++++++++++-----------
>  arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts |  262 ++++++------
>  arch/arm/boot/dts/armada-xp.dtsi                 |  202 ++++-----
>  12 files changed, 1549 insertions(+), 1521 deletions(-)

whole series applied to mvebu/dt

thx,

Jason.


From gregory.clement at free-electrons.com  Mon Apr 15 11:47:30 2013
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Mon, 15 Apr 2013 17:47:30 +0200
Subject: [PATCH v4 0/5]  LPAE remaining device tree file
In-Reply-To: <20130415154700.GF28693@titan.lakedaemon.net>
References: <1365776950-30094-1-git-send-email-gregory.clement@free-electrons.com>
 <20130415154700.GF28693@titan.lakedaemon.net>
Message-ID: <516C2112.9060703@free-electrons.com>

On 04/15/2013 05:47 PM, Jason Cooper wrote:
> On Fri, Apr 12, 2013 at 04:29:05PM +0200, Gregory CLEMENT wrote:
>> Hi Jason,
>>
>> I have just rebased the commits that you haven't applied yet. They are
>> rebased on mvebu/dt. I check that all the dtb can be built.
>>
>> Thanks,
>>
>> Gregory CLEMENT (3):
>>   ARM: dts: mvebu: Convert all the mvebu files to use the range
>>     property
>>   ARM: dts: mvebu: introduce internal-regs node
>>   ARM: dts: mvebu: Convert mvebu device tree files to 64 bits
>>
>> Thomas Petazzoni (2):
>>   ARM: dts: mvebu: fix cpus section indentation
>>   ARM: dts: mvebu: move all peripherals inside soc
>>
>>  arch/arm/boot/dts/armada-370-db.dts              |  134 +++---
>>  arch/arm/boot/dts/armada-370-mirabox.dts         |  176 ++++----
>>  arch/arm/boot/dts/armada-370-rd.dts              |   96 ++---
>>  arch/arm/boot/dts/armada-370-xp.dtsi             |  336 +++++++--------
>>  arch/arm/boot/dts/armada-370.dtsi                |  330 +++++++--------
>>  arch/arm/boot/dts/armada-xp-db.dts               |  202 ++++-----
>>  arch/arm/boot/dts/armada-xp-gp.dts               |  222 +++++-----
>>  arch/arm/boot/dts/armada-xp-mv78230.dtsi         |  284 ++++++-------
>>  arch/arm/boot/dts/armada-xp-mv78260.dtsi         |  342 +++++++--------
>>  arch/arm/boot/dts/armada-xp-mv78460.dtsi         |  484 +++++++++++-----------
>>  arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts |  262 ++++++------
>>  arch/arm/boot/dts/armada-xp.dtsi                 |  202 ++++-----
>>  12 files changed, 1549 insertions(+), 1521 deletions(-)
> 
> whole series applied to mvebu/dt
> 
> thx,
> 

Great, Thanks!
> Jason.
> 


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From jason at lakedaemon.net  Mon Apr 15 11:49:40 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Mon, 15 Apr 2013 11:49:40 -0400
Subject: [PATCHv3 01/10] pci: mvebu: enable driver usage on Kirkwood
In-Reply-To: <CAErSpo5unBoJG=TEPjwHsiXPD_1T-QPDwLznUq_8sRSudQQqEA@mail.gmail.com>
References: <1365865005-26653-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1365865005-26653-2-git-send-email-thomas.petazzoni@free-electrons.com>
 <CAErSpo5unBoJG=TEPjwHsiXPD_1T-QPDwLznUq_8sRSudQQqEA@mail.gmail.com>
Message-ID: <20130415154940.GG28693@titan.lakedaemon.net>

On Mon, Apr 15, 2013 at 09:11:02AM -0600, Bjorn Helgaas wrote:
> On Sat, Apr 13, 2013 at 8:56 AM, Thomas Petazzoni
> <thomas.petazzoni at free-electrons.com> wrote:
> > We allow the pci-mvebu driver to be compiled on the Kirkwood platform,
> > and add the 'marvell,kirkwood-pcie' as a compatible string supported
> > by the driver.
> >
> > Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> > Tested-by: Andrew Lunn <andrew at lunn.ch>
> 
> Acked-by: Bjorn Helgaas <bhelgaas at google.com>
> 
> I assume you'll merge this via some tree other than mine.

If you don't mind, it'll prevent us from having a nasty cross-tree
dependency and merge-ordering.  Any conflicts should be trivial.

thx,

Jason.

> > ---
> >  .../devicetree/bindings/pci/mvebu-pci.txt          |    1 +
> >  drivers/pci/host/Kconfig                           |    2 +-
> >  drivers/pci/host/pci-mvebu.c                       |    1 +
> >  3 files changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/devicetree/bindings/pci/mvebu-pci.txt b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
> > index eb69d92..f8d4058 100644
> > --- a/Documentation/devicetree/bindings/pci/mvebu-pci.txt
> > +++ b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
> > @@ -4,6 +4,7 @@ Mandatory properties:
> >  - compatible: one of the following values:
> >      marvell,armada-370-pcie
> >      marvell,armada-xp-pcie
> > +    marvell,kirkwood-pcie
> >  - #address-cells, set to <3>
> >  - #size-cells, set to <2>
> >  - #interrupt-cells, set to <1>
> > diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
> > index 6918fbc..1f1d67f 100644
> > --- a/drivers/pci/host/Kconfig
> > +++ b/drivers/pci/host/Kconfig
> > @@ -3,6 +3,6 @@ menu "PCI host controller drivers"
> >
> >  config PCI_MVEBU
> >         bool "Marvell EBU PCIe controller"
> > -       depends on ARCH_MVEBU
> > +       depends on ARCH_MVEBU || ARCH_KIRKWOOD
> >
> >  endmenu
> > diff --git a/drivers/pci/host/pci-mvebu.c b/drivers/pci/host/pci-mvebu.c
> > index 9c15a25..a083d19 100644
> > --- a/drivers/pci/host/pci-mvebu.c
> > +++ b/drivers/pci/host/pci-mvebu.c
> > @@ -853,6 +853,7 @@ static int __init mvebu_pcie_probe(struct platform_device *pdev)
> >  static const struct of_device_id mvebu_pcie_of_match_table[] = {
> >         { .compatible = "marvell,armada-xp-pcie", },
> >         { .compatible = "marvell,armada-370-pcie", },
> > +       { .compatible = "marvell,kirkwood-pcie", },
> >         {},
> >  };
> >  MODULE_DEVICE_TABLE(of, mvebu_pcie_of_match_table);
> > --
> > 1.7.9.5
> >


From broonie at kernel.org  Mon Apr 15 11:50:40 2013
From: broonie at kernel.org (Mark Brown)
Date: Mon, 15 Apr 2013 16:50:40 +0100
Subject: [RFC v1] regulator: core: introduce regulator chain locking scheme
In-Reply-To: <1366031015-17073-2-git-send-email-grygorii.strashko@ti.com>
References: <1366031015-17073-1-git-send-email-grygorii.strashko@ti.com>
 <1366031015-17073-2-git-send-email-grygorii.strashko@ti.com>
Message-ID: <20130415155040.GD15837@opensource.wolfsonmicro.com>

On Mon, Apr 15, 2013 at 04:03:35PM +0300, Grygorii Strashko wrote:

> To achieve this goal:
> - abstract regulator locking out into helper functions;
> - use the root Regulator (which has no supply defined, like regA) in chain to
>   protect the whole chain;
> - implement regulator chain locking scheme as proposed by Thomas Gleixner for CCF
>   re-entrance in https://lkml.org/lkml/2013/3/27/171 and in the similar way as
>   it is done for CCF by Mike Turquette in https://lkml.org/lkml/2013/3/28/512

Split this into separate refactoring and other change commits - one
change per commit.

> In addition, such locking scheme allows to have access to the supplier
> regulator API from inside child's (consumer) regulator API.

I've still not seen any use case articulated for doing this...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130415/b87dbd6a/attachment.sig>

From maxime.ripard at free-electrons.com  Mon Apr 15 12:01:02 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Mon, 15 Apr 2013 18:01:02 +0200
Subject: [GIT PULL] sunXi dt additions, take 4
Message-ID: <516C243E.2050407@free-electrons.com>

Hi Arnd, Olof,

This pull request for 3.10 is just one small patch changing slightly
merging the fixed rate oscillator with the oscillator gates.

This one will be the last pull request for 3.10-rc1.

Thanks,
Maxime

The following changes since commit 0b19b7c2c6e169efccb4b1632fe628969d001618:

  ARM: sunxi: dt: Update watchdog compatible string (2013-04-08 21:56:34 +0200)

are available in the git repository at:

  git://github.com/mripard/linux.git tags/sunxi-dt-for-3.10-4

for you to fetch changes up to 92fd6e066a4ecdf161710afe6460bc372899ae5f:

  ARM: sunxi: unify osc24M_fixed and osc24M (2013-04-15 10:24:54 +0200)

----------------------------------------------------------------
Fourth round of dt additions for 3.10

There's only one late patch that merge together two clocks that were
already defined in a previous patch.

----------------------------------------------------------------
Emilio L?pez (1):
      ARM: sunxi: unify osc24M_fixed and osc24M

 arch/arm/boot/dts/sun4i-a10.dtsi |    8 +-------
 arch/arm/boot/dts/sun5i-a13.dtsi |    8 +-------
 2 files changed, 2 insertions(+), 14 deletions(-)


-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


From plagnioj at jcrosoft.com  Mon Apr 15 12:00:41 2013
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Mon, 15 Apr 2013 18:00:41 +0200
Subject: [RFC patch 2/2] ARM: at91: cpuidle: move the driver to
 drivers/cpuidle directory
In-Reply-To: <516C10C5.4050107@linaro.org>
References: <1366032598-23053-1-git-send-email-daniel.lezcano@linaro.org>
 <1366032598-23053-3-git-send-email-daniel.lezcano@linaro.org>
 <20130415142047.GE15139@game.jcrosoft.org>
 <516C10C5.4050107@linaro.org>
Message-ID: <20130415160041.GF15139@game.jcrosoft.org>

On 16:37 Mon 15 Apr     , Daniel Lezcano wrote:
> On 04/15/2013 04:20 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > On 15:29 Mon 15 Apr     , Daniel Lezcano wrote:
> >> We don't have any dependency with the SoC specific code.
> >>
> >> Move the driver to the drivers/cpuidle directory.
> >>
> >> Add Nicolas Ferre as author of the driver, so it will be in copy of the emails.
> >>
> >> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
> > please use -M when generating the patch
> 
> Oh, right. Thanks for reminding me the option.
> 
> [ ... ]
> 
> >> +#include <linux/module.h>
> >> +#include <linux/init.h>
> >> +#include <linux/cpuidle.h>
> >> +#include <asm/cpuidle.h>
> >> +
> >> +#define AT91_MAX_STATES	2
> >> +
> >> +extern void (*at91_standby_ops)(void);
> > really don't like can we pass it via the pm?
> 
> I agree, it is hackish. Can you elaborate when you say "pass it via the
> pm" ?

I was thinking about it

I would even prefer to have a platfrom driver that pass it via platform data
even in DT

but not something that can touch globally

and for drivers I prefer to do not use cpu_is only for the core

Best Regards,
J.
> 
> 
> 
> -- 
>  <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs
> 
> Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
> <http://twitter.com/#!/linaroorg> Twitter |
> <http://www.linaro.org/linaro-blog/> Blog
> 


From wsa at the-dreams.de  Mon Apr 15 12:06:51 2013
From: wsa at the-dreams.de (Wolfram Sang)
Date: Mon, 15 Apr 2013 18:06:51 +0200
Subject: [PATCH] i2c: s3c2410: Add SMBus emulation for block read
In-Reply-To: <20130409122313.GD4913@pengutronix.de>
References: <1364308196-10101-1-git-send-email-prasanna.ps@samsung.com>
 <20130409122313.GD4913@pengutronix.de>
Message-ID: <20130415160651.GA6286@the-dreams.de>


> I don't know if that can happen, but if the block has length 0 (that is,
> only consists of a single byte that is read as 0) the is_msglast() test
> returns 0 which might be wrong. Maybe even if it cannot regularily
> happen handle it in a sane way?

Length of 0 is illegal according to the specs, but a check won't hurt.

> Also I wonder if error checking for byte > I2C_SMBUS_BLOCK_MAX would be
> needed to prevent a buffer overrun?

Yes. Although I have seen devices able to send more than that, yet
adding support for that is a seperate issue.



From lorenzo.pieralisi at arm.com  Mon Apr 15 12:13:21 2013
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Mon, 15 Apr 2013 17:13:21 +0100
Subject: [RFC PATCH 1/2] ARM: DT: kernel: move temporary cpu map stack array
 to static data
In-Reply-To: <1366042402-8987-1-git-send-email-lorenzo.pieralisi@arm.com>
References: <1366042402-8987-1-git-send-email-lorenzo.pieralisi@arm.com>
Message-ID: <1366042402-8987-2-git-send-email-lorenzo.pieralisi@arm.com>

As the number of CPUs increase, the temporary array allocated on the
stack in arm_dt_init_cpu_maps() can become too big and trigger stack
issues.
This patch moves the allocated memory to static __initdata so that stack
data is not used anymore to allocate the temporary array.
Memory is marked as __initdata since it need not be persistent after boot.

Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
---
 arch/arm/kernel/devtree.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
index 70f1bde..f149217 100644
--- a/arch/arm/kernel/devtree.c
+++ b/arch/arm/kernel/devtree.c
@@ -78,11 +78,12 @@ void __init arm_dt_init_cpu_maps(void)
 	 * contain a list of MPIDR[23:0] values where MPIDR[31:24] must
 	 * read as 0.
 	 */
+	static u32 tmp_map[NR_CPUS] __initdata = {
+				[0 ... NR_CPUS-1] = UINT_MAX };
 	struct device_node *cpu, *cpus;
 	u32 i, j, cpuidx = 1;
 	u32 mpidr = is_smp() ? read_cpuid_mpidr() & MPIDR_HWID_BITMASK : 0;
 
-	u32 tmp_map[NR_CPUS] = { [0 ... NR_CPUS-1] = UINT_MAX };
 	bool bootcpu_valid = false;
 	cpus = of_find_node_by_path("/cpus");
 
-- 
1.7.12




From lorenzo.pieralisi at arm.com  Mon Apr 15 12:13:20 2013
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Mon, 15 Apr 2013 17:13:20 +0100
Subject: [RFC PATCH 0/2] ARM: DT cpu bindings updates
Message-ID: <1366042402-8987-1-git-send-email-lorenzo.pieralisi@arm.com>

The introduction of DT cpus/cpu bindings for ARM requires well established
rules to enforce the reg property definition for 32-bit and 64-bit ARM
processors, inclusive of legacy and current uniprocessor/SMP systems.

ARM 64 bit architecture also requires dtb compiled for 64-bit configurations
to be reused for kernels running in 32 bit mode, so the cpus/cpu bindings
specification must be made compliant to cope with this configuration.

Patch #1 of this series is a fix and is included to have a clean patch
series and should get reviewed and merged separately.

Patch #2, along with some kernel fixes related to DT parsing function,
updates the cpu node bindings to cope with legacy, current and upcoming
ARM systems.

In-kernel device tree source files are updated to comply with the latest
specification, so thorough testing is required in order to validate all
changes on all affected ARM systems, in particular systems with exotic
MPIDR configurations that are likely to break with the changes provided.

Code relying on the reg property size to be 4-bytes will break when
dtb compiled for 64-bit kernels are used to boot a 32-bit system so
kernel code relying on that (bogus) assumption must be updated properly.

Lorenzo Pieralisi (2):
  ARM: DT: kernel: move temporary cpu map stack array to static data
  ARM: DT: kernel: DT cpu node bindings update

 Documentation/devicetree/bindings/arm/cpus.txt | 335 +++++++++++++++++++++----
 arch/arm/boot/dts/exynos5440.dtsi              |   7 +
 arch/arm/boot/dts/omap3.dtsi                   |   4 +
 arch/arm/boot/dts/omap4.dtsi                   |   5 +
 arch/arm/boot/dts/omap5.dtsi                   |   5 +
 arch/arm/boot/dts/r8a7740.dtsi                 |   3 +
 arch/arm/boot/dts/sh7372.dtsi                  |   4 +
 arch/arm/boot/dts/sunxi.dtsi                   |   4 +
 arch/arm/kernel/devtree.c                      |  85 ++++---
 9 files changed, 379 insertions(+), 73 deletions(-)

-- 
1.7.12




From lorenzo.pieralisi at arm.com  Mon Apr 15 12:13:22 2013
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Mon, 15 Apr 2013 17:13:22 +0100
Subject: [RFC PATCH 2/2] ARM: DT: kernel: DT cpu node bindings update
In-Reply-To: <1366042402-8987-1-git-send-email-lorenzo.pieralisi@arm.com>
References: <1366042402-8987-1-git-send-email-lorenzo.pieralisi@arm.com>
Message-ID: <1366042402-8987-3-git-send-email-lorenzo.pieralisi@arm.com>

In order to extend the current cpu nodes bindings to newer CPUs
inclusive of AArch64 and to update support for older ARM CPUs this
patch updates device tree documentation for the cpu nodes bindings.

Main changes:

- adds 64-bit bindings (inclusive of cpus node #address-cells updates)
- defines behaviour on pre and post v7 uniprocessor systems
- adds ARM 11MPcore specific reg property definition

DT cpu map parsing code must be made compliant with the latest bindings
updates, hence this patch also updates the arm_dt_init_cpu_maps() function
with checks and additional parsing rules.

Uniprocessor systems predating v7 do not parse the cpus node at all
since the reg property is meaningless on those systems.

Device trees for 64-bit systems can be taken as device tree input also
for 64-bit CPUs running in 32-bit mode. The code checks that the reg entries
are zeroed as required in the respective fields and detects automatically
the cpus node #address-cells value so that device tree written for
64-bit ARM platforms (cpus #address-cells == 2) can still be taken as
input. The correct device tree entries are to be set up by the boot
loader, kernel code just checks that device tree entries in the cpus
node are as expected for a 32-bit CPU (reg[63:24] == 0).

cpu node entries with invalid reg property or containing duplicates are
ignored and the device tree parsing is not stopped anymore when such
entries are encountered, the device tree cpu entry is just skipped.

A device tree with cpu nodes missing the boot CPU MPIDR is considered a
hard error and the kernel flags this up as a bug to force firmware updates.

The updates to cpus/cpu node bindings for ARM require all in-kernel dts files
present in the mainline to be made compliant to the latest specification.

This patch also updates ARM in-kernel non-compliant dts files to the latest
cpus/cpu nodes bindings specification.

Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
---
 Documentation/devicetree/bindings/arm/cpus.txt | 335 +++++++++++++++++++++----
 arch/arm/boot/dts/exynos5440.dtsi              |   7 +
 arch/arm/boot/dts/omap3.dtsi                   |   4 +
 arch/arm/boot/dts/omap4.dtsi                   |   5 +
 arch/arm/boot/dts/omap5.dtsi                   |   5 +
 arch/arm/boot/dts/r8a7740.dtsi                 |   3 +
 arch/arm/boot/dts/sh7372.dtsi                  |   4 +
 arch/arm/boot/dts/sunxi.dtsi                   |   4 +
 arch/arm/kernel/devtree.c                      |  82 +++---
 9 files changed, 377 insertions(+), 72 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt
index f32494d..b1ef3d8 100644
--- a/Documentation/devicetree/bindings/arm/cpus.txt
+++ b/Documentation/devicetree/bindings/arm/cpus.txt
@@ -1,4 +1,6 @@
-* ARM CPUs binding description
+=============================
+ARM CPUs bindings description
+=============================
 
 The device tree allows to describe the layout of CPUs in a system through
 the "cpus" node, which in turn contains a number of subnodes (ie "cpu")
@@ -8,70 +10,317 @@ Bindings for CPU nodes follow the ePAPR standard, available from:
 
 http://devicetree.org
 
-For the ARM architecture every CPU node must contain the following properties:
-
-- device_type:	must be "cpu"
-- reg:		property matching the CPU MPIDR[23:0] register bits
-		reg[31:24] bits must be set to 0
-- compatible:	should be one of:
-		"arm,arm1020"
-		"arm,arm1020e"
-		"arm,arm1022"
-		"arm,arm1026"
-		"arm,arm720"
-		"arm,arm740"
-		"arm,arm7tdmi"
-		"arm,arm920"
-		"arm,arm922"
-		"arm,arm925"
-		"arm,arm926"
-		"arm,arm940"
-		"arm,arm946"
-		"arm,arm9tdmi"
-		"arm,cortex-a5"
-		"arm,cortex-a7"
-		"arm,cortex-a8"
-		"arm,cortex-a9"
-		"arm,cortex-a15"
-		"arm,arm1136"
-		"arm,arm1156"
-		"arm,arm1176"
-		"arm,arm11mpcore"
-		"faraday,fa526"
-		"intel,sa110"
-		"intel,sa1100"
-		"marvell,feroceon"
-		"marvell,mohawk"
-		"marvell,xsc3"
-		"marvell,xscale"
-
-Example:
+with updates for 32-bit and 64-bit ARM systems provided in this document.
+
+In the bindings below:
+
+- square brackets define bitfields, eg reg[7:0] value of the bitfield in
+  the reg property contained in bits 7 down to 0
+
+- cpus node
+
+	Description: Container of cpu nodes
+
+	The node name must be "cpus".
+
+	A cpus node must define the following properties:
+
+	- #address-cells
+		Usage: required
+		Value type: <u32>
+		Definition: must be set to 1 for 32-bit systems and 2 for
+			    64-bit systems
+	- #size-cells
+		Usage: required
+		Value type: <u32>
+		Definition: must be set to 0
+
+- cpu node
+
+	Description: Describes a CPU in an ARM based system
+
+	PROPERTIES
+
+	- device_type
+		Usage: required
+		Value type: <string>
+		Definition: must be "cpu"
+	- reg
+		Usage and definition depend on ARM architecture version and
+		configuration:
+
+			# On uniprocessor ARM architectures previous to v7
+			  this property is optional since they do not define
+			  any register that provides a CPU identifier.
+			  Any value set in the reg property for these CPUs
+			  should be ignored.
+
+			# On ARM 11 MPcore based systems this property is
+			  required and matches the CPUID[11:0] register bits.
+
+			  Bits [11:0] in the reg cell must be set to
+			  bits [11:0] in CPU ID register.
+
+			  All other bits in the reg cell must be set to 0.
+
+			# On ARM architecture versions >= 7 based 32-bit
+			  systems this property is required and matches the
+			  CPU MPIDR[23:0] register bits.
+
+			  Bits [23:0] in the reg cell must be set to
+			  bits [23:0] in MPIDR.
+
+			  All other bits in the reg cell must be set to 0.
+
+			# On ARM v8 64-bit systems, where the reg property
+			  is made up of two cells to accomodate the 64-bit
+			  MPDIR_EL1 register this property is required and
+			  matches:
+
+			  The first reg cell bits [7:0] must be set to
+			  bits [39:32] of MPIDR_EL1.
+
+			  The second reg cell bits [23:0] must be set to
+			  bits [23:0] of MPIDR_EL1.
+
+			  All other bits in the reg cells must be set to 0.
+	- compatible:
+		Usage: required
+		Value type: <string>
+		Definition: should be one of:
+			    "arm,arm1020"
+			    "arm,arm1020e"
+			    "arm,arm1022"
+			    "arm,arm1026"
+			    "arm,arm720"
+			    "arm,arm740"
+			    "arm,arm7tdmi"
+			    "arm,arm920"
+			    "arm,arm922"
+			    "arm,arm925"
+			    "arm,arm926"
+			    "arm,arm940"
+			    "arm,arm946"
+			    "arm,arm9tdmi"
+			    "arm,cortex-a5"
+			    "arm,cortex-a7"
+			    "arm,cortex-a8"
+			    "arm,cortex-a9"
+			    "arm,cortex-a15"
+			    "arm,cortex-a57"
+			    "arm,arm1136"
+			    "arm,arm1156"
+			    "arm,arm1176"
+			    "arm,arm11mpcore"
+			    "faraday,fa526"
+			    "intel,sa110"
+			    "intel,sa1100"
+			    "marvell,feroceon"
+			    "marvell,mohawk"
+			    "marvell,xsc3"
+			    "marvell,xscale"
+	- enable-method
+		Usage: required on ARM 64-bit systems, optional on ARM 32-bit
+		       systems
+		Value type: <string>
+		Definition: On ARM 64-bit systems must be "spin-table" [1].
+
+	- cpu-release-addr
+		Usage: required on ARM 64-bit systems, optional on ARM 32-bit
+		       systems
+		Value type: <prop-encoded-array>
+		Definition: On ARM 64-bit systems must be a two cell
+			    property identifying a 64-bit zero-initialised
+			    memory location [1].
+
+Example 1 (dual-cluster big.LITTLE system 32-bit):
 
 	cpus {
 		#size-cells = <0>;
 		#address-cells = <1>;
 
-		CPU0: cpu at 0 {
+		cpu at 0 {
 			device_type = "cpu";
 			compatible = "arm,cortex-a15";
 			reg = <0x0>;
 		};
 
-		CPU1: cpu at 1 {
+		cpu at 1 {
 			device_type = "cpu";
 			compatible = "arm,cortex-a15";
 			reg = <0x1>;
 		};
 
-		CPU2: cpu at 100 {
+		cpu at 100 {
 			device_type = "cpu";
 			compatible = "arm,cortex-a7";
 			reg = <0x100>;
 		};
 
-		CPU3: cpu at 101 {
+		cpu at 101 {
 			device_type = "cpu";
 			compatible = "arm,cortex-a7";
 			reg = <0x101>;
 		};
 	};
+
+Example 2 (Cortex-A8 uniprocessor 32-bit system):
+
+	cpus {
+		#size-cells = <0>;
+		#address-cells = <1>;
+
+		cpu at 0 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a8";
+			reg = <0x0>;
+		};
+
+	};
+
+Example 3 (ARM 1176 uniprocessor 32-bit system):
+
+	cpus {
+		cpu {
+			device_type = "cpu";
+			compatible = "arm,arm1176";
+		};
+	};
+
+Example 4 (ARM Cortex-A57 64-bit system):
+
+cpus {
+	#size-cells = <0>;
+	#address-cells = <2>;
+
+	cpu at 0 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a57";
+		reg = <0x0 0x0>;
+		enable-method = "spin-table";
+		cpu-release-addr = <0 0x20000000>;
+	};
+
+	cpu at 1 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a57";
+		reg = <0x0 0x1>;
+		enable-method = "spin-table";
+		cpu-release-addr = <0 0x20000000>;
+	};
+
+	cpu at 100 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a57";
+		reg = <0x0 0x100>;
+		enable-method = "spin-table";
+		cpu-release-addr = <0 0x20000000>;
+	};
+
+	cpu at 101 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a57";
+		reg = <0x0 0x101>;
+		enable-method = "spin-table";
+		cpu-release-addr = <0 0x20000000>;
+	};
+
+	cpu at 10000 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a57";
+		reg = <0x0 0x10000>;
+		enable-method = "spin-table";
+		cpu-release-addr = <0 0x20000000>;
+	};
+
+	cpu at 10001 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a57";
+		reg = <0x0 0x10001>;
+		enable-method = "spin-table";
+		cpu-release-addr = <0 0x20000000>;
+	};
+
+	cpu at 10100 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a57";
+		reg = <0x0 0x10100>;
+		enable-method = "spin-table";
+		cpu-release-addr = <0 0x20000000>;
+	};
+
+	cpu at 10101 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a57";
+		reg = <0x0 0x10101>;
+		enable-method = "spin-table";
+		cpu-release-addr = <0 0x20000000>;
+	};
+
+	cpu at 100000000 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a57";
+		reg = <0x1 0x0>;
+		enable-method = "spin-table";
+		cpu-release-addr = <0 0x20000000>;
+	};
+
+	cpu at 100000001 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a57";
+		reg = <0x1 0x1>;
+		enable-method = "spin-table";
+		cpu-release-addr = <0 0x20000000>;
+	};
+
+	cpu at 100000100 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a57";
+		reg = <0x1 0x100>;
+		enable-method = "spin-table";
+		cpu-release-addr = <0 0x20000000>;
+	};
+
+	cpu at 100000101 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a57";
+		reg = <0x1 0x101>;
+		enable-method = "spin-table";
+		cpu-release-addr = <0 0x20000000>;
+	};
+
+	cpu at 100010000 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a57";
+		reg = <0x1 0x10000>;
+		enable-method = "spin-table";
+		cpu-release-addr = <0 0x20000000>;
+	};
+
+	cpu at 100010001 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a57";
+		reg = <0x1 0x10001>;
+		enable-method = "spin-table";
+		cpu-release-addr = <0 0x20000000>;
+	};
+
+	cpu at 100010100 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a57";
+		reg = <0x1 0x10100>;
+		enable-method = "spin-table";
+		cpu-release-addr = <0 0x20000000>;
+	};
+
+	cpu at 100010101 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a57";
+		reg = <0x1 0x10101>;
+		enable-method = "spin-table";
+		cpu-release-addr = <0 0x20000000>;
+	};
+};
+===============================================================================
+[1] ARM Linux kernel documentation
+    Documentation/devicetree/bindings/arm64/booting.txt
diff --git a/arch/arm/boot/dts/exynos5440.dtsi b/arch/arm/boot/dts/exynos5440.dtsi
index 5f3562a..eda21d5 100644
--- a/arch/arm/boot/dts/exynos5440.dtsi
+++ b/arch/arm/boot/dts/exynos5440.dtsi
@@ -24,8 +24,12 @@
 	};
 
 	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
 		cpu at 0 {
 			compatible = "arm,cortex-a15";
+			reg = <0x0>;
 			timer {
 				compatible = "arm,armv7-timer";
 				interrupts = <1 13 0xf08>;
@@ -34,6 +38,7 @@
 		};
 		cpu at 1 {
 			compatible = "arm,cortex-a15";
+			reg = <0x1>;
 			timer {
 				compatible = "arm,armv7-timer";
 				interrupts = <1 14 0xf08>;
@@ -42,6 +47,7 @@
 		};
 		cpu at 2 {
 			compatible = "arm,cortex-a15";
+			reg = <0x2>;
 			timer {
 				compatible = "arm,armv7-timer";
 				interrupts = <1 14 0xf08>;
@@ -50,6 +56,7 @@
 		};
 		cpu at 3 {
 			compatible = "arm,cortex-a15";
+			reg = <0x3>;
 			timer {
 				compatible = "arm,armv7-timer";
 				interrupts = <1 14 0xf08>;
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 1acc261..b4e2b8d 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -21,8 +21,12 @@
 	};
 
 	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
 		cpu at 0 {
 			compatible = "arm,cortex-a8";
+			reg = <0x0>;
 		};
 	};
 
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 739bb79..9c5f7c2 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -28,13 +28,18 @@
 	};
 
 	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
 		cpu at 0 {
 			compatible = "arm,cortex-a9";
 			next-level-cache = <&L2>;
+			reg = <0x0>;
 		};
 		cpu at 1 {
 			compatible = "arm,cortex-a9";
 			next-level-cache = <&L2>;
+			reg = <0x1>;
 		};
 	};
 
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 790bb2a..d2106b6 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -31,8 +31,12 @@
 	};
 
 	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
 		cpu at 0 {
 			compatible = "arm,cortex-a15";
+			reg = <0x0>;
 			timer {
 				compatible = "arm,armv7-timer";
 				/* 14th PPI IRQ, active low level-sensitive */
@@ -42,6 +46,7 @@
 		};
 		cpu at 1 {
 			compatible = "arm,cortex-a15";
+			reg = <0x1>;
 			timer {
 				compatible = "arm,armv7-timer";
 				/* 14th PPI IRQ, active low level-sensitive */
diff --git a/arch/arm/boot/dts/r8a7740.dtsi b/arch/arm/boot/dts/r8a7740.dtsi
index 798fa35..b47bb36 100644
--- a/arch/arm/boot/dts/r8a7740.dtsi
+++ b/arch/arm/boot/dts/r8a7740.dtsi
@@ -14,8 +14,11 @@
 	compatible = "renesas,r8a7740";
 
 	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
 		cpu at 0 {
 			compatible = "arm,cortex-a9";
+			reg = <0x0>;
 		};
 	};
 };
diff --git a/arch/arm/boot/dts/sh7372.dtsi b/arch/arm/boot/dts/sh7372.dtsi
index 677fc60..78478af 100644
--- a/arch/arm/boot/dts/sh7372.dtsi
+++ b/arch/arm/boot/dts/sh7372.dtsi
@@ -14,8 +14,12 @@
 	compatible = "renesas,sh7372";
 
 	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
 		cpu at 0 {
 			compatible = "arm,cortex-a8";
+			reg = <0x0>;
 		};
 	};
 };
diff --git a/arch/arm/boot/dts/sunxi.dtsi b/arch/arm/boot/dts/sunxi.dtsi
index 8b36abe..447a0f0 100644
--- a/arch/arm/boot/dts/sunxi.dtsi
+++ b/arch/arm/boot/dts/sunxi.dtsi
@@ -17,8 +17,12 @@
 	interrupt-parent = <&intc>;
 
 	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
 		cpu at 0 {
 			compatible = "arm,cortex-a8";
+			reg = <0x0>;
 		};
 	};
 
diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
index f149217..4eda2dc 100644
--- a/arch/arm/kernel/devtree.c
+++ b/arch/arm/kernel/devtree.c
@@ -23,6 +23,7 @@
 #include <asm/setup.h>
 #include <asm/page.h>
 #include <asm/smp_plat.h>
+#include <asm/system_info.h>
 #include <asm/mach/arch.h>
 #include <asm/mach-types.h>
 
@@ -81,48 +82,68 @@ void __init arm_dt_init_cpu_maps(void)
 	static u32 tmp_map[NR_CPUS] __initdata = {
 				[0 ... NR_CPUS-1] = UINT_MAX };
 	struct device_node *cpu, *cpus;
-	u32 i, j, cpuidx = 1;
+	u32 i, j, ac, cpuidx = 1;
 	u32 mpidr = is_smp() ? read_cpuid_mpidr() & MPIDR_HWID_BITMASK : 0;
-
+	int len;
 	bool bootcpu_valid = false;
+
 	cpus = of_find_node_by_path("/cpus");
 
-	if (!cpus)
+	if (!cpus || ((cpu_architecture() < CPU_ARCH_ARMv7) && !is_smp()))
 		return;
 
+	if (WARN_ON(of_property_read_u32(cpus, "#address-cells", &ac)))
+		ac = of_n_addr_cells(cpus);
+
 	for_each_child_of_node(cpus, cpu) {
-		u32 hwid;
+		u64 hwid64;
+		u32 hwid32;
+		const __be32 *prop;
 
 		pr_debug(" * %s...\n", cpu->full_name);
 		/*
-		 * A device tree containing CPU nodes with missing "reg"
-		 * properties is considered invalid to build the
-		 * cpu_logical_map.
+		 * A CPU node with missing or wrong "reg" property is
+		 * considered invalid to build a cpu_logical_map entry.
 		 */
-		if (of_property_read_u32(cpu, "reg", &hwid)) {
-			pr_debug(" * %s missing reg property\n",
-				     cpu->full_name);
-			return;
+		prop = of_get_property(cpu, "reg", &len);
+		if (!prop || len < (ac * sizeof(*prop))) {
+				WARN(1, " * %s node missing/wrong reg"
+					 " property, skipped\n",
+					 cpu->full_name);
+				goto next;
 		}
-
 		/*
-		 * 8 MSBs must be set to 0 in the DT since the reg property
-		 * defines the MPIDR[23:0].
+		 * Always read reg as u64 value.
+		 * For dts with #address-cells == 1 hwid64[63:32]
+		 * will be set to 0 by of_read_number.
+		 * Toss away the top 32 bits and store value in hwid32.
+		 */
+		hwid32 = hwid64 = of_read_number(prop, ac);
+		/*
+		 * hwid64[63:24] must be always be 0 since the reg
+		 * property defines the MPIDR[23:0] bits regardless
+		 * of the cpus node #address-cells value.
 		 */
-		if (hwid & ~MPIDR_HWID_BITMASK)
-			return;
+		if (hwid64 & ~MPIDR_HWID_BITMASK) {
+			WARN(1, " * %s node reg[63:24] must be 0 on"
+			       " 32-bit dts, got %#016llx, skipped\n",
+			       cpu->full_name, hwid64);
+			goto next;
+		}
 
 		/*
 		 * Duplicate MPIDRs are a recipe for disaster.
 		 * Scan all initialized entries and check for
-		 * duplicates. If any is found just bail out.
+		 * duplicates. If any is found just ignore the CPU.
 		 * temp values were initialized to UINT_MAX
 		 * to avoid matching valid MPIDR[23:0] values.
 		 */
 		for (j = 0; j < cpuidx; j++)
-			if (WARN(tmp_map[j] == hwid, "Duplicate /cpu reg "
-						     "properties in the DT\n"))
-				return;
+			if (WARN(tmp_map[j] == hwid32, " * %s node "
+						"duplicate cpu reg "
+						"property, skipped\n",
+						cpu->full_name))
+				goto next;
 
 		/*
 		 * Build a stashed array of MPIDR values. Numbering scheme
@@ -133,26 +154,29 @@ void __init arm_dt_init_cpu_maps(void)
 		 * logical map built from DT is validated and can be used
 		 * to override the map created in smp_setup_processor_id().
 		 */
-		if (hwid == mpidr) {
+		if (hwid32 == mpidr) {
 			i = 0;
 			bootcpu_valid = true;
 		} else {
 			i = cpuidx++;
 		}
 
-		if (WARN(cpuidx > nr_cpu_ids, "DT /cpu %u nodes greater than "
-					       "max cores %u, capping them\n",
+		if (WARN_ONCE(cpuidx > nr_cpu_ids, "DT cpu %u nodes greater"
+						   " than max cores %u,"
+						   " capping them\n",
 					       cpuidx, nr_cpu_ids)) {
 			cpuidx = nr_cpu_ids;
-			break;
+			goto next;
 		}
 
-		tmp_map[i] = hwid;
+		tmp_map[i] = hwid32;
+next:	;
 	}
-
-	if (WARN(!bootcpu_valid, "DT missing boot CPU MPIDR[23:0], "
-				 "fall back to default cpu_logical_map\n"))
-		return;
+	/*
+	 * A DT missing the boot CPU MPIDR is a really bad omen
+	 * Flag it up as such and force firmware/dtb updates
+	 */
+	BUG_ON(!bootcpu_valid);
 
 	/*
 	 * Since the boot CPU node contains proper data, and all nodes have
-- 
1.7.12




From broonie at kernel.org  Mon Apr 15 12:15:45 2013
From: broonie at kernel.org (Mark Brown)
Date: Mon, 15 Apr 2013 17:15:45 +0100
Subject: [PATCH v2 05/11] ASoC: fsl-ssi: Add support for imx-pcm-fiq
In-Reply-To: <516ACA7D.60807@tabi.org>
References: <1365362721-3731-1-git-send-email-mpa@pengutronix.de>
 <1365362721-3731-6-git-send-email-mpa@pengutronix.de>
 <51620CEA.3010703@tabi.org> <20130414103819.GA27394@pengutronix.de>
 <516AB111.3000007@tabi.org> <20130414141015.GC27394@pengutronix.de>
 <516AC305.2000800@tabi.org> <20130414152016.GE27394@pengutronix.de>
 <516ACA7D.60807@tabi.org>
Message-ID: <20130415161544.GH15837@opensource.wolfsonmicro.com>

On Sun, Apr 14, 2013 at 10:25:49AM -0500, Timur Tabi wrote:

> Ah, so this is a work-around for a bug, where the codec is
> incompatible with the SoC?  Mark, are you familiar with this issue?
> Is there a way to reconfigure the codec so that it works better with
> the SoC?  It seems ridiculous to add all this code just because an
> incompatible codec was chosen for some board.

It's a limitation in the SoC - it sort of tries to bodge AC'97 in but
doesn't do a great job of it and can't handle the idea that there's
multiple streams of data on the bus.  This isn't something that can be
configured in the CODEC.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130415/17c01bc8/attachment.sig>

From andrii.tseglytskyi at ti.com  Mon Apr 15 12:21:25 2013
From: andrii.tseglytskyi at ti.com (Andrii Tseglytskyi)
Date: Mon, 15 Apr 2013 19:21:25 +0300
Subject: [RFC v1] regulator: core: introduce regulator chain locking scheme
In-Reply-To: <20130415155040.GD15837@opensource.wolfsonmicro.com>
References: <1366031015-17073-1-git-send-email-grygorii.strashko@ti.com>
 <1366031015-17073-2-git-send-email-grygorii.strashko@ti.com>
 <20130415155040.GD15837@opensource.wolfsonmicro.com>
Message-ID: <516C2905.8000200@ti.com>

Hi Mark,

On 04/15/2013 06:50 PM, Mark Brown wrote:
>> In addition, such locking scheme allows to have access to the supplier
>> regulator API from inside child's (consumer) regulator API.
> I've still not seen any use case articulated for doing this...
Use case is introduced in ABB series:

http://www.mail-archive.com/linux-omap at vger.kernel.org/msg88293.html

During voltage scaling we would like to have the following sequence:

cpufreq_cpu0
     |
     |---> set_voltage(ABB)
                 |
                 |->set_voltage(AVS)
                         |
                         |-->set_voltage(smps123)


Where smps123 is a regulator, connected ot i2c bus. In this particular 
case "regulator chain" guarantees proper order of calls of voltage 
scaling sequence.

Regards,
Andrii


From swarren at wwwdotorg.org  Mon Apr 15 12:22:37 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Mon, 15 Apr 2013 10:22:37 -0600
Subject: [PATCH V4 1/6] clk: OMAP: introduce device tree binding to kernel
 clock data
In-Reply-To: <1365807278-554-2-git-send-email-nm@ti.com>
References: <1365807278-554-1-git-send-email-nm@ti.com>
 <1365807278-554-2-git-send-email-nm@ti.com>
Message-ID: <516C294D.6070700@wwwdotorg.org>

On 04/12/2013 04:54 PM, Nishanth Menon wrote:
> OMAP clock data is located in arch/arm/mach-omap2/cclockXYZ_data.c.
> However, this presents an obstacle for using these clock nodes in
> Device Tree definitions. This is especially true for board specific
> clocks initially. The fixed clocks are currently found via clock
> aliases table. There are many possible approaches to this problem as
> discussed in the following thread:
> http://marc.info/?t=136370325600009&r=1&w=2.
> Highlights of the options:
> a) device specific clk_add_alias:
>    cons: driver handling required
> b) using an generic clk node and indexing to reach the clock required.
>    This is similar in approach taken by tegra and few other platforms.
>    Example usage: clock = <&clk 5>;
>    cons: potential to have mismatches in indexed table and associated
>    dtb data. In addition, managing continued documentation in bindings
>    as clock indexing increases. Even though readability angle could be
>    improved by using preprocessing of DT using macros, indexed
>    approach is inherently risky from cases like the following:
>    clk indexes in kernel:
>    1 - mpu_dpll
>    2 - aux_clk1
>    3 - core_clk
>    DT entry for peripheral X uses <&clk 2> to reach aux_clk1. Now, let's
>    say kernel updates indices to:
>    1 - mpu_dpll
>    2 - per_dpll
>    3 - aux_clk1
>    4 - core_clk
>    using the old dtb(or dts missing an update), on new kernel which
>    has updated indices will result in per_dpll now controlled for
>    peripheral X without warning or any potential error detection.
> 
>    Even though we could claim this is user error, such errors are hard
>    to track down and fix.

The error in case (b) is that you shouldn't be changing the DT bindings
after they've first been created. That would avoid the problem
situation. The person using the old DTB with the new kernel didn't
commit user error.

> An alternate approach introduced here is to introduce device tree
> bindings corresponding to the clock nodes required in DT definition
> for SoC which automatically maps back to the definitions in
> cclockXYZ_data.c.

Well, I haven't read the patches, but isn't that exactly what the "2" is
in <&clk 2>?


From jason at lakedaemon.net  Mon Apr 15 12:36:09 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Mon, 15 Apr 2013 12:36:09 -0400
Subject: [PATCHv8 07/19] arm: pci: add a align_resource hook
In-Reply-To: <1365541601-14095-8-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1365541601-14095-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1365541601-14095-8-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <20130415163609.GJ28693@titan.lakedaemon.net>

Russell,

Thanks for applying this patch (7683/1) to your tree.  I see it's in
your for-next, which I understand *isn't* stable.

  029baf1 ARM: 7683/1: pci: add a align_resource hook

Is there a stable branch I could depend on for the rest of this series
(particularly, patch 10)?  It looks like you applied it to your misc
branch, but that's not currently available.

thx,

Jason.

On Tue, Apr 09, 2013 at 11:06:28PM +0200, Thomas Petazzoni wrote:
> The PCI specifications says that an I/O region must be aligned on a 4
> KB boundary, and a memory region aligned on a 1 MB boundary.
> 
> However, the Marvell PCIe interfaces rely on address decoding windows
> (which allow to associate a range of physical addresses with a given
> device). For PCIe memory windows, those windows are defined with a 1
> MB granularity (which matches the PCI specs), but PCIe I/O windows can
> only be defined with a 64 KB granularity, so they have to be 64 KB
> aligned. We therefore need to tell the PCI core about this special
> alignement requirement.
> 
> The PCI core already calls pcibios_align_resource() in the ARM PCI
> core, specifically for such purposes. So this patch extends the ARM
> PCI core so that it calls a ->align_resource() hook registered by the
> PCI driver, exactly like the existing ->map_irq() and ->swizzle()
> hooks.
> 
> A particular PCI driver can register a align_resource() hook, and do
> its own specific alignement, depending on the specific constraints of
> the underlying hardware.
> 
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> Cc: Russell King <linux at arm.linux.org.uk>
> ---
>  arch/arm/include/asm/mach/pci.h |   11 +++++++++++
>  arch/arm/kernel/bios32.c        |    6 ++++++
>  2 files changed, 17 insertions(+)
> 
> diff --git a/arch/arm/include/asm/mach/pci.h b/arch/arm/include/asm/mach/pci.h
> index 5cf2e97..7d2c3c8 100644
> --- a/arch/arm/include/asm/mach/pci.h
> +++ b/arch/arm/include/asm/mach/pci.h
> @@ -30,6 +30,11 @@ struct hw_pci {
>  	void		(*postinit)(void);
>  	u8		(*swizzle)(struct pci_dev *dev, u8 *pin);
>  	int		(*map_irq)(const struct pci_dev *dev, u8 slot, u8 pin);
> +	resource_size_t (*align_resource)(struct pci_dev *dev,
> +					  const struct resource *res,
> +					  resource_size_t start,
> +					  resource_size_t size,
> +					  resource_size_t align);
>  };
>  
>  /*
> @@ -51,6 +56,12 @@ struct pci_sys_data {
>  	u8		(*swizzle)(struct pci_dev *, u8 *);
>  					/* IRQ mapping				*/
>  	int		(*map_irq)(const struct pci_dev *, u8, u8);
> +					/* Resource alignement requirements	*/
> +	resource_size_t (*align_resource)(struct pci_dev *dev,
> +					  const struct resource *res,
> +					  resource_size_t start,
> +					  resource_size_t size,
> +					  resource_size_t align);
>  	void		*private_data;	/* platform controller private data	*/
>  };
>  
> diff --git a/arch/arm/kernel/bios32.c b/arch/arm/kernel/bios32.c
> index a1f73b5..b2ed73c 100644
> --- a/arch/arm/kernel/bios32.c
> +++ b/arch/arm/kernel/bios32.c
> @@ -462,6 +462,7 @@ static void pcibios_init_hw(struct hw_pci *hw, struct list_head *head)
>  		sys->busnr   = busnr;
>  		sys->swizzle = hw->swizzle;
>  		sys->map_irq = hw->map_irq;
> +		sys->align_resource = hw->align_resource;
>  		INIT_LIST_HEAD(&sys->resources);
>  
>  		if (hw->private_data)
> @@ -574,6 +575,8 @@ char * __init pcibios_setup(char *str)
>  resource_size_t pcibios_align_resource(void *data, const struct resource *res,
>  				resource_size_t size, resource_size_t align)
>  {
> +	struct pci_dev *dev = data;
> +	struct pci_sys_data *sys = dev->sysdata;
>  	resource_size_t start = res->start;
>  
>  	if (res->flags & IORESOURCE_IO && start & 0x300)
> @@ -581,6 +584,9 @@ resource_size_t pcibios_align_resource(void *data, const struct resource *res,
>  
>  	start = (start + align - 1) & ~(align - 1);
>  
> +	if (sys->align_resource)
> +		return sys->align_resource(dev, res, start, size, align);
> +
>  	return start;
>  }
>  
> -- 
> 1.7.9.5
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From thomas.petazzoni at free-electrons.com  Mon Apr 15 12:36:23 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Mon, 15 Apr 2013 18:36:23 +0200
Subject: [PATCHv8 00/19] PCIe support for the Armada 370 and Armada XP SoCs
In-Reply-To: <20130415154620.GE28693@titan.lakedaemon.net>
References: <1365541601-14095-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <20130415154620.GE28693@titan.lakedaemon.net>
Message-ID: <20130415183623.04797912@skate>

Dear Jason Cooper,

On Mon, 15 Apr 2013 11:46:20 -0400, Jason Cooper wrote:

> >  * Patches 1-5 are awaiting a formal Acked-by from the Device Tree
> >    maintainers. Patches 1-3 are the new version of the OF PCI range
> >    parsing functions from Andrew Murray, which he worked on after the
> >    comments from Rob Herring. Patches 4 and 5 are much more trivial
> >    and have been around since many versions of this series.
> 
> Applied to mvebu/drivers

Patches 1-3 have a newer version that has been posted by Andrew Murray
recently, see:

Subject: [PATCH v6 0/3] of/pci: Provide common support for PCI DT
parsing Date: Thu, 11 Apr 2013 16:26:06 +0100
Message-Id: <1365693969-23907-1-git-send-email-Andrew.Murray at arm.com>

http://lists.infradead.org/pipermail/linux-arm-kernel/2013-April/162558.html

This ones are more recent than the v5 I originally used as a base for
my PCIe v8. I can resend a v9 of my PCIe patch set based on the v6 of
Andrew, or you can directly use PATCH 1,2,3 from Andrew series to
replace PATCH 1,2,3 from my series. Andrew v6 has quite a number of
changes compared to v5, so I really recommend using those ones.

Thanks!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From jason at lakedaemon.net  Mon Apr 15 12:38:45 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Mon, 15 Apr 2013 12:38:45 -0400
Subject: [PATCHv8 00/19] PCIe support for the Armada 370 and Armada XP SoCs
In-Reply-To: <20130415183623.04797912@skate>
References: <1365541601-14095-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <20130415154620.GE28693@titan.lakedaemon.net>
 <20130415183623.04797912@skate>
Message-ID: <20130415163845.GK28693@titan.lakedaemon.net>

On Mon, Apr 15, 2013 at 06:36:23PM +0200, Thomas Petazzoni wrote:
> Dear Jason Cooper,
> 
> On Mon, 15 Apr 2013 11:46:20 -0400, Jason Cooper wrote:
> 
> > >  * Patches 1-5 are awaiting a formal Acked-by from the Device Tree
> > >    maintainers. Patches 1-3 are the new version of the OF PCI range
> > >    parsing functions from Andrew Murray, which he worked on after the
> > >    comments from Rob Herring. Patches 4 and 5 are much more trivial
> > >    and have been around since many versions of this series.
> > 
> > Applied to mvebu/drivers
> 
> Patches 1-3 have a newer version that has been posted by Andrew Murray
> recently, see:
> 
> Subject: [PATCH v6 0/3] of/pci: Provide common support for PCI DT
> parsing Date: Thu, 11 Apr 2013 16:26:06 +0100
> Message-Id: <1365693969-23907-1-git-send-email-Andrew.Murray at arm.com>
> 
> http://lists.infradead.org/pipermail/linux-arm-kernel/2013-April/162558.html
> 
> This ones are more recent than the v5 I originally used as a base for
> my PCIe v8. I can resend a v9 of my PCIe patch set based on the v6 of
> Andrew, or you can directly use PATCH 1,2,3 from Andrew series to
> replace PATCH 1,2,3 from my series. Andrew v6 has quite a number of
> changes compared to v5, so I really recommend using those ones.

No need to mess with v9, I'll pull AndrewM's v6.

thx,

Jason.


From swarren at wwwdotorg.org  Mon Apr 15 12:32:58 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Mon, 15 Apr 2013 10:32:58 -0600
Subject: [PATCH] ARM: ux500: DT: Rename root node "soc-u9500" into
 "soc-ux500"
In-Reply-To: <1366022492-8701-1-git-send-email-linus.walleij@stericsson.com>
References: <1366022492-8701-1-git-send-email-linus.walleij@stericsson.com>
Message-ID: <516C2BBA.2040406@wwwdotorg.org>

On 04/15/2013 04:41 AM, Linus Walleij wrote:
> From: Gabriel Fernandez <gabriel.fernandez at stericsson.com>
> 
> This root node is used in the whole family of chips, the a9500
> is just one particular instance.

> diff --git a/arch/arm/boot/dts/ccu9540.dts b/arch/arm/boot/dts/ccu9540.dts

> -	soc-u9500 {
> +	soc-ux500 {

Shouldn't this just be "soc" then; nodes are usually named based on type
of object rather than identity.


From swarren at wwwdotorg.org  Mon Apr 15 12:40:20 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Mon, 15 Apr 2013 10:40:20 -0600
Subject: Query on pinctrl usage for DT nodes
In-Reply-To: <516BB818.3060603@ti.com>
References: <CA+V-a8uiPwsAD--OHFAE=i2ed+-wbXm4p2deZXr92+Zv6GDS1w@mail.gmail.com>
 <515C5C76.3080009@wwwdotorg.org> <20130403183803.GA10155@atomide.com>
 <20130403184202.GB10155@atomide.com> <516BB818.3060603@ti.com>
Message-ID: <516C2D74.2090106@wwwdotorg.org>

On 04/15/2013 02:19 AM, Peter Ujfalusi wrote:
> Hi,
> 
> On 04/03/2013 08:42 PM, Tony Lindgren wrote:
>> Oh it's already using pinctrl-single,bits option. Maybe there's a
>> bug, adding Peter to cc.
> 
> I think all boils down to the fact that in pinctrl (single only?) _one_
> register can be only associated with _one_ driver. Even through ,bit type
> would allow us to only change parts of the same register, another device can
> not take the same register with different mask.

pinctrl itself certainly imposes no such restriction that I'm aware of.
pinctrl is only concerned with the ownership of *pins* (or perhaps
groups). The mapping of pins to registers is something entirely internal
to individual pinctrl drivers.

So, the solution here is for pinctrl-single to create a separate
pin/group object for each separately controllable entity, and that may
be each bit in a register rather than each register, depending on HW.


From thomas.petazzoni at free-electrons.com  Mon Apr 15 12:40:57 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Mon, 15 Apr 2013 18:40:57 +0200
Subject: [PATCHv8 00/19] PCIe support for the Armada 370 and Armada XP SoCs
In-Reply-To: <20130415163845.GK28693@titan.lakedaemon.net>
References: <1365541601-14095-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <20130415154620.GE28693@titan.lakedaemon.net>
 <20130415183623.04797912@skate>
 <20130415163845.GK28693@titan.lakedaemon.net>
Message-ID: <20130415184057.7783c272@skate>

Dear Jason Cooper,

On Mon, 15 Apr 2013 12:38:45 -0400, Jason Cooper wrote:

> > This ones are more recent than the v5 I originally used as a base for
> > my PCIe v8. I can resend a v9 of my PCIe patch set based on the v6 of
> > Andrew, or you can directly use PATCH 1,2,3 from Andrew series to
> > replace PATCH 1,2,3 from my series. Andrew v6 has quite a number of
> > changes compared to v5, so I really recommend using those ones.
> 
> No need to mess with v9, I'll pull AndrewM's v6.

Excellent, thanks.

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From broonie at opensource.wolfsonmicro.com  Mon Apr 15 12:40:18 2013
From: broonie at opensource.wolfsonmicro.com (Mark Brown)
Date: Mon, 15 Apr 2013 17:40:18 +0100
Subject: [RFC v1] regulator: core: introduce regulator chain locking scheme
In-Reply-To: <516C2905.8000200@ti.com>
References: <1366031015-17073-1-git-send-email-grygorii.strashko@ti.com>
 <1366031015-17073-2-git-send-email-grygorii.strashko@ti.com>
 <20130415155040.GD15837@opensource.wolfsonmicro.com>
 <516C2905.8000200@ti.com>
Message-ID: <20130415164018.GA14064@sirena.org.uk>

On Mon, Apr 15, 2013 at 07:21:25PM +0300, Andrii Tseglytskyi wrote:
> On 04/15/2013 06:50 PM, Mark Brown wrote:

> >>In addition, such locking scheme allows to have access to the supplier
> >>regulator API from inside child's (consumer) regulator API.

> >I've still not seen any use case articulated for doing this...

> Use case is introduced in ABB series:

Sorry, I meant any sensible use case.


From monstr at monstr.eu  Mon Apr 15 12:50:55 2013
From: monstr at monstr.eu (Michal Simek)
Date: Mon, 15 Apr 2013 18:50:55 +0200
Subject: [PATCH v6 1/3] of/pci: Unify pci_process_bridge_OF_ranges from
 Microblaze and PowerPC
In-Reply-To: <20130415145741.4e4c362b@skate>
References: <1365693969-23907-1-git-send-email-Andrew.Murray@arm.com>
 <1365693969-23907-2-git-send-email-Andrew.Murray@arm.com>
 <20130415145741.4e4c362b@skate>
Message-ID: <516C2FEF.7080006@monstr.eu>

Hi Thomas and Andrew,

First of all I would recommend you to add your tree to 0-day testing
system where you can easily catch up compilation failures for
microblaze and others.

Getting this compilation failure:
drivers/of/of_pci.c: In function 'pci_process_bridge_OF_ranges':
drivers/of/of_pci.c:88:22: error: storage size of 'range' isn't known
drivers/of/of_pci.c:89:29: error: storage size of 'parser' isn't known
drivers/of/of_pci.c:96:2: error: implicit declaration of function 'of_pci_range_parser' [-Werror=implicit-function-declaration]
drivers/of/of_pci.c:100:2: error: implicit declaration of function 'for_each_of_pci_range' [-Werror=implicit-function-declaration]
drivers/of/of_pci.c:100:41: error: expected ';' before '{' token
drivers/of/of_pci.c:90:6: warning: unused variable 'res_type' [-Wunused-variable]
drivers/of/of_pci.c:89:29: warning: unused variable 'parser' [-Wunused-variable]
drivers/of/of_pci.c:88:22: warning: unused variable 'range' [-Wunused-variable]
drivers/of/of_pci.c:87:19: warning: unused variable 'res' [-Wunused-variable]
drivers/of/of_pci.c:86:21: warning: unused variable 'isa_mb' [-Wunused-variable]
drivers/of/of_pci.c:85:17: warning: unused variable 'isa_hole' [-Wunused-variable]
drivers/of/of_pci.c:85:6: warning: unused variable 'memno' [-Wunused-variable]

which is caused missing linux/of_addresss.h in of_pci.c.
PowerPC probably won't have this problem because you have this header in asm/prom.h
but based on the same comment it is better to add it directly to the files.

That's why please add this header to this patch.

diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
index 3e428a1..f30887e 100644
--- a/drivers/of/of_pci.c
+++ b/drivers/of/of_pci.c
@@ -1,6 +1,7 @@
 #include <linux/kernel.h>
 #include <linux/export.h>
 #include <linux/of.h>
+#include <linux/of_address.h>
 #include <linux/of_pci.h>
 #include <asm/prom.h>


When you fix it:
Acked-by: Michal Simek <monstr at monstr.eu>

Thanks,
Michal



On 04/15/2013 02:57 PM, Thomas Petazzoni wrote:
> Michal, Ben,
> 
> Would you have some time to look at this patch and give your comments
> and/or ACK ? Since it touches the PowerPC and Microblaze core code, we
> need your agreement to merge this code, and quite a bit of code pending
> for 3.10 depends on this patch.
> 
> Rob, alternatively, could we imagine doing a different version of the
> 'of/pci: Provide support for parsing PCI DT ranges property' that
> introduces the new API only, leaving the PowerPC and Microblaze rework
> as follow-up efforts, so that all the PCIe drivers that depend on this
> patch can get in for 3.10 ? I'd find it pretty sad if the Marvell PCIe
> driver that has been worked on since 4+ months does not get into 3.10
> just because this patch cannot be merged.
> 
> Thanks!
> 
> Thomas
> 
> On Thu, 11 Apr 2013 16:26:07 +0100, Andrew Murray wrote:
>> The pci_process_bridge_OF_ranges function, used to parse the "ranges"
>> property of a PCI host device, is found in both Microblaze and PowerPC
>> architectures. These implementations are nearly identical. This patch
>> moves this common code to a common place.
>>
>> Signed-off-by: Andrew Murray <Andrew.Murray at arm.com>
>> Signed-off-by: Liviu Dudau <Liviu.Dudau at arm.com>
>> Reviewed-by: Rob Herring <rob.herring at calxeda.com>
>> Tested-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
>> ---
>>  arch/microblaze/include/asm/pci-bridge.h |    5 +-
>>  arch/microblaze/pci/pci-common.c         |  192 ----------------------------
>>  arch/powerpc/include/asm/pci-bridge.h    |    5 +-
>>  arch/powerpc/kernel/pci-common.c         |  192 ----------------------------
>>  drivers/of/of_pci.c                      |  200 ++++++++++++++++++++++++++++++
>>  include/linux/of_pci.h                   |    4 +
>>  6 files changed, 206 insertions(+), 392 deletions(-)
>>
>> diff --git a/arch/microblaze/include/asm/pci-bridge.h b/arch/microblaze/include/asm/pci-bridge.h
>> index cb5d397..5783cd6 100644
>> --- a/arch/microblaze/include/asm/pci-bridge.h
>> +++ b/arch/microblaze/include/asm/pci-bridge.h
>> @@ -10,6 +10,7 @@
>>  #include <linux/pci.h>
>>  #include <linux/list.h>
>>  #include <linux/ioport.h>
>> +#include <linux/of_pci.h>
>>  
>>  struct device_node;
>>  
>> @@ -132,10 +133,6 @@ extern void setup_indirect_pci(struct pci_controller *hose,
>>  extern struct pci_controller *pci_find_hose_for_OF_device(
>>  			struct device_node *node);
>>  
>> -/* Fill up host controller resources from the OF node */
>> -extern void pci_process_bridge_OF_ranges(struct pci_controller *hose,
>> -			struct device_node *dev, int primary);
>> -
>>  /* Allocate & free a PCI host bridge structure */
>>  extern struct pci_controller *pcibios_alloc_controller(struct device_node *dev);
>>  extern void pcibios_free_controller(struct pci_controller *phb);
>> diff --git a/arch/microblaze/pci/pci-common.c b/arch/microblaze/pci/pci-common.c
>> index 9ea521e..2735ad9 100644
>> --- a/arch/microblaze/pci/pci-common.c
>> +++ b/arch/microblaze/pci/pci-common.c
>> @@ -622,198 +622,6 @@ void pci_resource_to_user(const struct pci_dev *dev, int bar,
>>  	*end = rsrc->end - offset;
>>  }
>>  
>> -/**
>> - * pci_process_bridge_OF_ranges - Parse PCI bridge resources from device tree
>> - * @hose: newly allocated pci_controller to be setup
>> - * @dev: device node of the host bridge
>> - * @primary: set if primary bus (32 bits only, soon to be deprecated)
>> - *
>> - * This function will parse the "ranges" property of a PCI host bridge device
>> - * node and setup the resource mapping of a pci controller based on its
>> - * content.
>> - *
>> - * Life would be boring if it wasn't for a few issues that we have to deal
>> - * with here:
>> - *
>> - *   - We can only cope with one IO space range and up to 3 Memory space
>> - *     ranges. However, some machines (thanks Apple !) tend to split their
>> - *     space into lots of small contiguous ranges. So we have to coalesce.
>> - *
>> - *   - We can only cope with all memory ranges having the same offset
>> - *     between CPU addresses and PCI addresses. Unfortunately, some bridges
>> - *     are setup for a large 1:1 mapping along with a small "window" which
>> - *     maps PCI address 0 to some arbitrary high address of the CPU space in
>> - *     order to give access to the ISA memory hole.
>> - *     The way out of here that I've chosen for now is to always set the
>> - *     offset based on the first resource found, then override it if we
>> - *     have a different offset and the previous was set by an ISA hole.
>> - *
>> - *   - Some busses have IO space not starting at 0, which causes trouble with
>> - *     the way we do our IO resource renumbering. The code somewhat deals with
>> - *     it for 64 bits but I would expect problems on 32 bits.
>> - *
>> - *   - Some 32 bits platforms such as 4xx can have physical space larger than
>> - *     32 bits so we need to use 64 bits values for the parsing
>> - */
>> -void pci_process_bridge_OF_ranges(struct pci_controller *hose,
>> -				  struct device_node *dev, int primary)
>> -{
>> -	const u32 *ranges;
>> -	int rlen;
>> -	int pna = of_n_addr_cells(dev);
>> -	int np = pna + 5;
>> -	int memno = 0, isa_hole = -1;
>> -	u32 pci_space;
>> -	unsigned long long pci_addr, cpu_addr, pci_next, cpu_next, size;
>> -	unsigned long long isa_mb = 0;
>> -	struct resource *res;
>> -
>> -	pr_info("PCI host bridge %s %s ranges:\n",
>> -	       dev->full_name, primary ? "(primary)" : "");
>> -
>> -	/* Get ranges property */
>> -	ranges = of_get_property(dev, "ranges", &rlen);
>> -	if (ranges == NULL)
>> -		return;
>> -
>> -	/* Parse it */
>> -	pr_debug("Parsing ranges property...\n");
>> -	while ((rlen -= np * 4) >= 0) {
>> -		/* Read next ranges element */
>> -		pci_space = ranges[0];
>> -		pci_addr = of_read_number(ranges + 1, 2);
>> -		cpu_addr = of_translate_address(dev, ranges + 3);
>> -		size = of_read_number(ranges + pna + 3, 2);
>> -
>> -		pr_debug("pci_space: 0x%08x pci_addr:0x%016llx ",
>> -				pci_space, pci_addr);
>> -		pr_debug("cpu_addr:0x%016llx size:0x%016llx\n",
>> -					cpu_addr, size);
>> -
>> -		ranges += np;
>> -
>> -		/* If we failed translation or got a zero-sized region
>> -		 * (some FW try to feed us with non sensical zero sized regions
>> -		 * such as power3 which look like some kind of attempt
>> -		 * at exposing the VGA memory hole)
>> -		 */
>> -		if (cpu_addr == OF_BAD_ADDR || size == 0)
>> -			continue;
>> -
>> -		/* Now consume following elements while they are contiguous */
>> -		for (; rlen >= np * sizeof(u32);
>> -		     ranges += np, rlen -= np * 4) {
>> -			if (ranges[0] != pci_space)
>> -				break;
>> -			pci_next = of_read_number(ranges + 1, 2);
>> -			cpu_next = of_translate_address(dev, ranges + 3);
>> -			if (pci_next != pci_addr + size ||
>> -			    cpu_next != cpu_addr + size)
>> -				break;
>> -			size += of_read_number(ranges + pna + 3, 2);
>> -		}
>> -
>> -		/* Act based on address space type */
>> -		res = NULL;
>> -		switch ((pci_space >> 24) & 0x3) {
>> -		case 1:		/* PCI IO space */
>> -			pr_info("  IO 0x%016llx..0x%016llx -> 0x%016llx\n",
>> -			       cpu_addr, cpu_addr + size - 1, pci_addr);
>> -
>> -			/* We support only one IO range */
>> -			if (hose->pci_io_size) {
>> -				pr_info(" \\--> Skipped (too many) !\n");
>> -				continue;
>> -			}
>> -			/* On 32 bits, limit I/O space to 16MB */
>> -			if (size > 0x01000000)
>> -				size = 0x01000000;
>> -
>> -			/* 32 bits needs to map IOs here */
>> -			hose->io_base_virt = ioremap(cpu_addr, size);
>> -
>> -			/* Expect trouble if pci_addr is not 0 */
>> -			if (primary)
>> -				isa_io_base =
>> -					(unsigned long)hose->io_base_virt;
>> -			/* pci_io_size and io_base_phys always represent IO
>> -			 * space starting at 0 so we factor in pci_addr
>> -			 */
>> -			hose->pci_io_size = pci_addr + size;
>> -			hose->io_base_phys = cpu_addr - pci_addr;
>> -
>> -			/* Build resource */
>> -			res = &hose->io_resource;
>> -			res->flags = IORESOURCE_IO;
>> -			res->start = pci_addr;
>> -			break;
>> -		case 2:		/* PCI Memory space */
>> -		case 3:		/* PCI 64 bits Memory space */
>> -			pr_info(" MEM 0x%016llx..0x%016llx -> 0x%016llx %s\n",
>> -			       cpu_addr, cpu_addr + size - 1, pci_addr,
>> -			       (pci_space & 0x40000000) ? "Prefetch" : "");
>> -
>> -			/* We support only 3 memory ranges */
>> -			if (memno >= 3) {
>> -				pr_info(" \\--> Skipped (too many) !\n");
>> -				continue;
>> -			}
>> -			/* Handles ISA memory hole space here */
>> -			if (pci_addr == 0) {
>> -				isa_mb = cpu_addr;
>> -				isa_hole = memno;
>> -				if (primary || isa_mem_base == 0)
>> -					isa_mem_base = cpu_addr;
>> -				hose->isa_mem_phys = cpu_addr;
>> -				hose->isa_mem_size = size;
>> -			}
>> -
>> -			/* We get the PCI/Mem offset from the first range or
>> -			 * the, current one if the offset came from an ISA
>> -			 * hole. If they don't match, bugger.
>> -			 */
>> -			if (memno == 0 ||
>> -			    (isa_hole >= 0 && pci_addr != 0 &&
>> -			     hose->pci_mem_offset == isa_mb))
>> -				hose->pci_mem_offset = cpu_addr - pci_addr;
>> -			else if (pci_addr != 0 &&
>> -				 hose->pci_mem_offset != cpu_addr - pci_addr) {
>> -				pr_info(" \\--> Skipped (offset mismatch) !\n");
>> -				continue;
>> -			}
>> -
>> -			/* Build resource */
>> -			res = &hose->mem_resources[memno++];
>> -			res->flags = IORESOURCE_MEM;
>> -			if (pci_space & 0x40000000)
>> -				res->flags |= IORESOURCE_PREFETCH;
>> -			res->start = cpu_addr;
>> -			break;
>> -		}
>> -		if (res != NULL) {
>> -			res->name = dev->full_name;
>> -			res->end = res->start + size - 1;
>> -			res->parent = NULL;
>> -			res->sibling = NULL;
>> -			res->child = NULL;
>> -		}
>> -	}
>> -
>> -	/* If there's an ISA hole and the pci_mem_offset is -not- matching
>> -	 * the ISA hole offset, then we need to remove the ISA hole from
>> -	 * the resource list for that brige
>> -	 */
>> -	if (isa_hole >= 0 && hose->pci_mem_offset != isa_mb) {
>> -		unsigned int next = isa_hole + 1;
>> -		pr_info(" Removing ISA hole at 0x%016llx\n", isa_mb);
>> -		if (next < memno)
>> -			memmove(&hose->mem_resources[isa_hole],
>> -				&hose->mem_resources[next],
>> -				sizeof(struct resource) * (memno - next));
>> -		hose->mem_resources[--memno].flags = 0;
>> -	}
>> -}
>> -
>>  /* Decide whether to display the domain number in /proc */
>>  int pci_proc_domain(struct pci_bus *bus)
>>  {
>> diff --git a/arch/powerpc/include/asm/pci-bridge.h b/arch/powerpc/include/asm/pci-bridge.h
>> index 025a130..205bfba 100644
>> --- a/arch/powerpc/include/asm/pci-bridge.h
>> +++ b/arch/powerpc/include/asm/pci-bridge.h
>> @@ -10,6 +10,7 @@
>>  #include <linux/pci.h>
>>  #include <linux/list.h>
>>  #include <linux/ioport.h>
>> +#include <linux/of_pci.h>
>>  #include <asm-generic/pci-bridge.h>
>>  
>>  struct device_node;
>> @@ -231,10 +232,6 @@ extern int pcibios_map_io_space(struct pci_bus *bus);
>>  extern struct pci_controller *pci_find_hose_for_OF_device(
>>  			struct device_node* node);
>>  
>> -/* Fill up host controller resources from the OF node */
>> -extern void pci_process_bridge_OF_ranges(struct pci_controller *hose,
>> -			struct device_node *dev, int primary);
>> -
>>  /* Allocate & free a PCI host bridge structure */
>>  extern struct pci_controller *pcibios_alloc_controller(struct device_node *dev);
>>  extern void pcibios_free_controller(struct pci_controller *phb);
>> diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
>> index fa12ae4..6edf396 100644
>> --- a/arch/powerpc/kernel/pci-common.c
>> +++ b/arch/powerpc/kernel/pci-common.c
>> @@ -640,198 +640,6 @@ void pci_resource_to_user(const struct pci_dev *dev, int bar,
>>  	*end = rsrc->end - offset;
>>  }
>>  
>> -/**
>> - * pci_process_bridge_OF_ranges - Parse PCI bridge resources from device tree
>> - * @hose: newly allocated pci_controller to be setup
>> - * @dev: device node of the host bridge
>> - * @primary: set if primary bus (32 bits only, soon to be deprecated)
>> - *
>> - * This function will parse the "ranges" property of a PCI host bridge device
>> - * node and setup the resource mapping of a pci controller based on its
>> - * content.
>> - *
>> - * Life would be boring if it wasn't for a few issues that we have to deal
>> - * with here:
>> - *
>> - *   - We can only cope with one IO space range and up to 3 Memory space
>> - *     ranges. However, some machines (thanks Apple !) tend to split their
>> - *     space into lots of small contiguous ranges. So we have to coalesce.
>> - *
>> - *   - We can only cope with all memory ranges having the same offset
>> - *     between CPU addresses and PCI addresses. Unfortunately, some bridges
>> - *     are setup for a large 1:1 mapping along with a small "window" which
>> - *     maps PCI address 0 to some arbitrary high address of the CPU space in
>> - *     order to give access to the ISA memory hole.
>> - *     The way out of here that I've chosen for now is to always set the
>> - *     offset based on the first resource found, then override it if we
>> - *     have a different offset and the previous was set by an ISA hole.
>> - *
>> - *   - Some busses have IO space not starting at 0, which causes trouble with
>> - *     the way we do our IO resource renumbering. The code somewhat deals with
>> - *     it for 64 bits but I would expect problems on 32 bits.
>> - *
>> - *   - Some 32 bits platforms such as 4xx can have physical space larger than
>> - *     32 bits so we need to use 64 bits values for the parsing
>> - */
>> -void pci_process_bridge_OF_ranges(struct pci_controller *hose,
>> -				  struct device_node *dev, int primary)
>> -{
>> -	const u32 *ranges;
>> -	int rlen;
>> -	int pna = of_n_addr_cells(dev);
>> -	int np = pna + 5;
>> -	int memno = 0, isa_hole = -1;
>> -	u32 pci_space;
>> -	unsigned long long pci_addr, cpu_addr, pci_next, cpu_next, size;
>> -	unsigned long long isa_mb = 0;
>> -	struct resource *res;
>> -
>> -	printk(KERN_INFO "PCI host bridge %s %s ranges:\n",
>> -	       dev->full_name, primary ? "(primary)" : "");
>> -
>> -	/* Get ranges property */
>> -	ranges = of_get_property(dev, "ranges", &rlen);
>> -	if (ranges == NULL)
>> -		return;
>> -
>> -	/* Parse it */
>> -	while ((rlen -= np * 4) >= 0) {
>> -		/* Read next ranges element */
>> -		pci_space = ranges[0];
>> -		pci_addr = of_read_number(ranges + 1, 2);
>> -		cpu_addr = of_translate_address(dev, ranges + 3);
>> -		size = of_read_number(ranges + pna + 3, 2);
>> -		ranges += np;
>> -
>> -		/* If we failed translation or got a zero-sized region
>> -		 * (some FW try to feed us with non sensical zero sized regions
>> -		 * such as power3 which look like some kind of attempt at exposing
>> -		 * the VGA memory hole)
>> -		 */
>> -		if (cpu_addr == OF_BAD_ADDR || size == 0)
>> -			continue;
>> -
>> -		/* Now consume following elements while they are contiguous */
>> -		for (; rlen >= np * sizeof(u32);
>> -		     ranges += np, rlen -= np * 4) {
>> -			if (ranges[0] != pci_space)
>> -				break;
>> -			pci_next = of_read_number(ranges + 1, 2);
>> -			cpu_next = of_translate_address(dev, ranges + 3);
>> -			if (pci_next != pci_addr + size ||
>> -			    cpu_next != cpu_addr + size)
>> -				break;
>> -			size += of_read_number(ranges + pna + 3, 2);
>> -		}
>> -
>> -		/* Act based on address space type */
>> -		res = NULL;
>> -		switch ((pci_space >> 24) & 0x3) {
>> -		case 1:		/* PCI IO space */
>> -			printk(KERN_INFO
>> -			       "  IO 0x%016llx..0x%016llx -> 0x%016llx\n",
>> -			       cpu_addr, cpu_addr + size - 1, pci_addr);
>> -
>> -			/* We support only one IO range */
>> -			if (hose->pci_io_size) {
>> -				printk(KERN_INFO
>> -				       " \\--> Skipped (too many) !\n");
>> -				continue;
>> -			}
>> -#ifdef CONFIG_PPC32
>> -			/* On 32 bits, limit I/O space to 16MB */
>> -			if (size > 0x01000000)
>> -				size = 0x01000000;
>> -
>> -			/* 32 bits needs to map IOs here */
>> -			hose->io_base_virt = ioremap(cpu_addr, size);
>> -
>> -			/* Expect trouble if pci_addr is not 0 */
>> -			if (primary)
>> -				isa_io_base =
>> -					(unsigned long)hose->io_base_virt;
>> -#endif /* CONFIG_PPC32 */
>> -			/* pci_io_size and io_base_phys always represent IO
>> -			 * space starting at 0 so we factor in pci_addr
>> -			 */
>> -			hose->pci_io_size = pci_addr + size;
>> -			hose->io_base_phys = cpu_addr - pci_addr;
>> -
>> -			/* Build resource */
>> -			res = &hose->io_resource;
>> -			res->flags = IORESOURCE_IO;
>> -			res->start = pci_addr;
>> -			break;
>> -		case 2:		/* PCI Memory space */
>> -		case 3:		/* PCI 64 bits Memory space */
>> -			printk(KERN_INFO
>> -			       " MEM 0x%016llx..0x%016llx -> 0x%016llx %s\n",
>> -			       cpu_addr, cpu_addr + size - 1, pci_addr,
>> -			       (pci_space & 0x40000000) ? "Prefetch" : "");
>> -
>> -			/* We support only 3 memory ranges */
>> -			if (memno >= 3) {
>> -				printk(KERN_INFO
>> -				       " \\--> Skipped (too many) !\n");
>> -				continue;
>> -			}
>> -			/* Handles ISA memory hole space here */
>> -			if (pci_addr == 0) {
>> -				isa_mb = cpu_addr;
>> -				isa_hole = memno;
>> -				if (primary || isa_mem_base == 0)
>> -					isa_mem_base = cpu_addr;
>> -				hose->isa_mem_phys = cpu_addr;
>> -				hose->isa_mem_size = size;
>> -			}
>> -
>> -			/* We get the PCI/Mem offset from the first range or
>> -			 * the, current one if the offset came from an ISA
>> -			 * hole. If they don't match, bugger.
>> -			 */
>> -			if (memno == 0 ||
>> -			    (isa_hole >= 0 && pci_addr != 0 &&
>> -			     hose->pci_mem_offset == isa_mb))
>> -				hose->pci_mem_offset = cpu_addr - pci_addr;
>> -			else if (pci_addr != 0 &&
>> -				 hose->pci_mem_offset != cpu_addr - pci_addr) {
>> -				printk(KERN_INFO
>> -				       " \\--> Skipped (offset mismatch) !\n");
>> -				continue;
>> -			}
>> -
>> -			/* Build resource */
>> -			res = &hose->mem_resources[memno++];
>> -			res->flags = IORESOURCE_MEM;
>> -			if (pci_space & 0x40000000)
>> -				res->flags |= IORESOURCE_PREFETCH;
>> -			res->start = cpu_addr;
>> -			break;
>> -		}
>> -		if (res != NULL) {
>> -			res->name = dev->full_name;
>> -			res->end = res->start + size - 1;
>> -			res->parent = NULL;
>> -			res->sibling = NULL;
>> -			res->child = NULL;
>> -		}
>> -	}
>> -
>> -	/* If there's an ISA hole and the pci_mem_offset is -not- matching
>> -	 * the ISA hole offset, then we need to remove the ISA hole from
>> -	 * the resource list for that brige
>> -	 */
>> -	if (isa_hole >= 0 && hose->pci_mem_offset != isa_mb) {
>> -		unsigned int next = isa_hole + 1;
>> -		printk(KERN_INFO " Removing ISA hole at 0x%016llx\n", isa_mb);
>> -		if (next < memno)
>> -			memmove(&hose->mem_resources[isa_hole],
>> -				&hose->mem_resources[next],
>> -				sizeof(struct resource) * (memno - next));
>> -		hose->mem_resources[--memno].flags = 0;
>> -	}
>> -}
>> -
>>  /* Decide whether to display the domain number in /proc */
>>  int pci_proc_domain(struct pci_bus *bus)
>>  {
>> diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
>> index 13e37e2..1626172 100644
>> --- a/drivers/of/of_pci.c
>> +++ b/drivers/of/of_pci.c
>> @@ -4,6 +4,10 @@
>>  #include <linux/of_pci.h>
>>  #include <asm/prom.h>
>>  
>> +#if defined(CONFIG_PPC32) || defined(CONFIG_PPC64) || defined(CONFIG_MICROBLAZE)
>> +#include <asm/pci-bridge.h>
>> +#endif
>> +
>>  static inline int __of_pci_pci_compare(struct device_node *node,
>>  				       unsigned int devfn)
>>  {
>> @@ -40,3 +44,199 @@ struct device_node *of_pci_find_child_device(struct device_node *parent,
>>  	return NULL;
>>  }
>>  EXPORT_SYMBOL_GPL(of_pci_find_child_device);
>> +
>> +/**
>> + * pci_process_bridge_OF_ranges - Parse PCI bridge resources from device tree
>> + * @hose: newly allocated pci_controller to be setup
>> + * @dev: device node of the host bridge
>> + * @primary: set if primary bus (32 bits only, soon to be deprecated)
>> + *
>> + * This function will parse the "ranges" property of a PCI host bridge device
>> + * node and setup the resource mapping of a pci controller based on its
>> + * content.
>> + *
>> + * Life would be boring if it wasn't for a few issues that we have to deal
>> + * with here:
>> + *
>> + *   - We can only cope with one IO space range and up to 3 Memory space
>> + *     ranges. However, some machines (thanks Apple !) tend to split their
>> + *     space into lots of small contiguous ranges. So we have to coalesce.
>> + *
>> + *   - We can only cope with all memory ranges having the same offset
>> + *     between CPU addresses and PCI addresses. Unfortunately, some bridges
>> + *     are setup for a large 1:1 mapping along with a small "window" which
>> + *     maps PCI address 0 to some arbitrary high address of the CPU space in
>> + *     order to give access to the ISA memory hole.
>> + *     The way out of here that I've chosen for now is to always set the
>> + *     offset based on the first resource found, then override it if we
>> + *     have a different offset and the previous was set by an ISA hole.
>> + *
>> + *   - Some busses have IO space not starting at 0, which causes trouble with
>> + *     the way we do our IO resource renumbering. The code somewhat deals with
>> + *     it for 64 bits but I would expect problems on 32 bits.
>> + *
>> + *   - Some 32 bits platforms such as 4xx can have physical space larger than
>> + *     32 bits so we need to use 64 bits values for the parsing
>> + */
>> +#if defined(CONFIG_PPC32) || defined(CONFIG_PPC64) || defined(CONFIG_MICROBLAZE)
>> +void pci_process_bridge_OF_ranges(struct pci_controller *hose,
>> +				  struct device_node *dev, int primary)
>> +{
>> +	const u32 *ranges;
>> +	int rlen;
>> +	int pna = of_n_addr_cells(dev);
>> +	int np = pna + 5;
>> +	int memno = 0, isa_hole = -1;
>> +	u32 pci_space;
>> +	unsigned long long pci_addr, cpu_addr, pci_next, cpu_next, size;
>> +	unsigned long long isa_mb = 0;
>> +	struct resource *res;
>> +
>> +	pr_info("PCI host bridge %s %s ranges:\n",
>> +	       dev->full_name, primary ? "(primary)" : "");
>> +
>> +	/* Get ranges property */
>> +	ranges = of_get_property(dev, "ranges", &rlen);
>> +	if (ranges == NULL)
>> +		return;
>> +
>> +	/* Parse it */
>> +	pr_debug("Parsing ranges property...\n");
>> +	while ((rlen -= np * 4) >= 0) {
>> +		/* Read next ranges element */
>> +		pci_space = ranges[0];
>> +		pci_addr = of_read_number(ranges + 1, 2);
>> +		cpu_addr = of_translate_address(dev, ranges + 3);
>> +		size = of_read_number(ranges + pna + 3, 2);
>> +
>> +		pr_debug("pci_space: 0x%08x pci_addr:0x%016llx ",
>> +				pci_space, pci_addr);
>> +		pr_debug("cpu_addr:0x%016llx size:0x%016llx\n",
>> +					cpu_addr, size);
>> +
>> +		ranges += np;
>> +
>> +		/* If we failed translation or got a zero-sized region
>> +		 * (some FW try to feed us with non sensical zero sized regions
>> +		 * such as power3 which look like some kind of attempt
>> +		 * at exposing the VGA memory hole)
>> +		 */
>> +		if (cpu_addr == OF_BAD_ADDR || size == 0)
>> +			continue;
>> +
>> +		/* Now consume following elements while they are contiguous */
>> +		for (; rlen >= np * sizeof(u32);
>> +		     ranges += np, rlen -= np * 4) {
>> +			if (ranges[0] != pci_space)
>> +				break;
>> +			pci_next = of_read_number(ranges + 1, 2);
>> +			cpu_next = of_translate_address(dev, ranges + 3);
>> +			if (pci_next != pci_addr + size ||
>> +			    cpu_next != cpu_addr + size)
>> +				break;
>> +			size += of_read_number(ranges + pna + 3, 2);
>> +		}
>> +
>> +		/* Act based on address space type */
>> +		res = NULL;
>> +		switch ((pci_space >> 24) & 0x3) {
>> +		case 1:		/* PCI IO space */
>> +			pr_info("  IO 0x%016llx..0x%016llx -> 0x%016llx\n",
>> +			       cpu_addr, cpu_addr + size - 1, pci_addr);
>> +
>> +			/* We support only one IO range */
>> +			if (hose->pci_io_size) {
>> +				pr_info(" \\--> Skipped (too many) !\n");
>> +				continue;
>> +			}
>> +#if (!IS_ENABLED(CONFIG_64BIT))
>> +			/* On 32 bits, limit I/O space to 16MB */
>> +			if (size > 0x01000000)
>> +				size = 0x01000000;
>> +
>> +			/* 32 bits needs to map IOs here */
>> +			hose->io_base_virt = ioremap(cpu_addr, size);
>> +
>> +			/* Expect trouble if pci_addr is not 0 */
>> +			if (primary)
>> +				isa_io_base =
>> +					(unsigned long)hose->io_base_virt;
>> +#endif /* !CONFIG_64BIT */
>> +			/* pci_io_size and io_base_phys always represent IO
>> +			 * space starting at 0 so we factor in pci_addr
>> +			 */
>> +			hose->pci_io_size = pci_addr + size;
>> +			hose->io_base_phys = cpu_addr - pci_addr;
>> +
>> +			/* Build resource */
>> +			res = &hose->io_resource;
>> +			res->flags = IORESOURCE_IO;
>> +			res->start = pci_addr;
>> +			break;
>> +		case 2:		/* PCI Memory space */
>> +		case 3:		/* PCI 64 bits Memory space */
>> +			pr_info(" MEM 0x%016llx..0x%016llx -> 0x%016llx %s\n",
>> +			       cpu_addr, cpu_addr + size - 1, pci_addr,
>> +			       (pci_space & 0x40000000) ? "Prefetch" : "");
>> +
>> +			/* We support only 3 memory ranges */
>> +			if (memno >= 3) {
>> +				pr_info(" \\--> Skipped (too many) !\n");
>> +				continue;
>> +			}
>> +			/* Handles ISA memory hole space here */
>> +			if (pci_addr == 0) {
>> +				isa_mb = cpu_addr;
>> +				isa_hole = memno;
>> +				if (primary || isa_mem_base == 0)
>> +					isa_mem_base = cpu_addr;
>> +				hose->isa_mem_phys = cpu_addr;
>> +				hose->isa_mem_size = size;
>> +			}
>> +
>> +			/* We get the PCI/Mem offset from the first range or
>> +			 * the, current one if the offset came from an ISA
>> +			 * hole. If they don't match, bugger.
>> +			 */
>> +			if (memno == 0 ||
>> +			    (isa_hole >= 0 && pci_addr != 0 &&
>> +			     hose->pci_mem_offset == isa_mb))
>> +				hose->pci_mem_offset = cpu_addr - pci_addr;
>> +			else if (pci_addr != 0 &&
>> +				 hose->pci_mem_offset != cpu_addr - pci_addr) {
>> +				pr_info(" \\--> Skipped (offset mismatch) !\n");
>> +				continue;
>> +			}
>> +
>> +			/* Build resource */
>> +			res = &hose->mem_resources[memno++];
>> +			res->flags = IORESOURCE_MEM;
>> +			if (pci_space & 0x40000000)
>> +				res->flags |= IORESOURCE_PREFETCH;
>> +			res->start = cpu_addr;
>> +			break;
>> +		}
>> +		if (res != NULL) {
>> +			res->name = dev->full_name;
>> +			res->end = res->start + size - 1;
>> +			res->parent = NULL;
>> +			res->sibling = NULL;
>> +			res->child = NULL;
>> +		}
>> +	}
>> +
>> +	/* If there's an ISA hole and the pci_mem_offset is -not- matching
>> +	 * the ISA hole offset, then we need to remove the ISA hole from
>> +	 * the resource list for that brige
>> +	 */
>> +	if (isa_hole >= 0 && hose->pci_mem_offset != isa_mb) {
>> +		unsigned int next = isa_hole + 1;
>> +		pr_info(" Removing ISA hole at 0x%016llx\n", isa_mb);
>> +		if (next < memno)
>> +			memmove(&hose->mem_resources[isa_hole],
>> +				&hose->mem_resources[next],
>> +				sizeof(struct resource) * (memno - next));
>> +		hose->mem_resources[--memno].flags = 0;
>> +	}
>> +}
>> +#endif
>> diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
>> index bb115de..33e8ead 100644
>> --- a/include/linux/of_pci.h
>> +++ b/include/linux/of_pci.h
>> @@ -11,4 +11,8 @@ struct device_node;
>>  struct device_node *of_pci_find_child_device(struct device_node *parent,
>>  					     unsigned int devfn);
>>  
>> +struct pci_controller;
>> +void pci_process_bridge_OF_ranges(struct pci_controller *hose,
>> +			struct device_node *dev, int primary);
>> +
>>  #endif
> 
> 
> 


-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID:
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform



From swarren at wwwdotorg.org  Mon Apr 15 12:53:10 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Mon, 15 Apr 2013 10:53:10 -0600
Subject: [PATCH 3/5] gpio/omap: Add DT support to GPIO driver
In-Reply-To: <CAAwP0s0e2x33jZQhFRY+Hoo61SFqYKRgWk=1mL2+DNxSDJHz+A@mail.gmail.com>
References: <1329321854-24490-1-git-send-email-b-cousson@ti.com>
 <512D39DA.7020306@ti.com> <512D3AB1.1080202@wwwdotorg.org>
 <512D3EC2.6050408@ti.com> <20130302200524.D230F3E1571@localhost>
 <51391F41.5000303@ti.com>
 <CAAwP0s1CFRO-rf==p5sYs1n0gigMif7wuT8Yv0N_iLUDMrtcOg@mail.gmail.com>
 <CACRpkdYHj-rEF3Rk_CWnmmMw_Amr7m8SgQ=-2zsDYuLeuu3azw@mail.gmail.com>
 <514C79E1.4090106@wwwdotorg.org> <514CE0AB.6060207@ti.com>
 <CACRpkdZmv-rAoKSQYpkHHSMzKJOn5TixVW_P3=m7ZNagBYCUPw@mail.gmail.com>
 <515319D5.20105@wwwdotorg.org>
 <CACRpkdYXVLgCz1Tyu-Ls2V2OTc4R3cGNJhfQJB6Hiz_K9dkZYQ@mail.gmail.com>
 <5155C902.7080207@wwwdotorg.org>
 <CACRpkdYbs4-uudpRUY8e+7icYYkZrfM0kReP3pLL5DMiURJ4dg@mail.gmail.com>
 <5165CB9D.1090202@wwwdotorg.org>
 <CACRpkdYirFNqmGhA4K9CL4ve4NYhs8Rd3SFt1iwW9vHBkrcz8g@mail.gmail.com>
 <51671D7B.5060303@wwwdotorg.org>
 <CACRpkdbf32Ef77GmXk9id9+RRjcDRTr7S+F4nznoeZU8y=BT_Q@mail.gmail.com>
 <51673D70.3010503@wwwdotorg.org>
 <CAAwP0s0e2x33jZQhFRY+Hoo61SFqYKRgWk=1mL2+DNxSDJHz+A@mail.gmail.com>
Message-ID: <516C3076.3000107@wwwdotorg.org>

On 04/13/2013 07:35 PM, Javier Martinez Canillas wrote:
...
> Is the following inlined patch [1] what you were thinking that would
> be the right approach?
...
> diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
...
> +static int omap_gpio_irq_request(struct irq_data *d)
> +{
> +	struct gpio_bank *bank = irq_data_get_irq_chip_data(d);
> +
> +	return omap_gpio_request(&bank->chip, d->hwirq);

If you want the GPIO usage to be known to the GPIO subsystem, then
wouldn't you call gpio_request() here rather than omap_gpio_request()?
The above code will certainly do enough so that the OMAP GPIO HW is
fully enabled as you need, but I thought the idea was to also prevent
some other code successfully running gpio_request() on that same GPIO?


From jon-hunter at ti.com  Mon Apr 15 12:54:32 2013
From: jon-hunter at ti.com (Jon Hunter)
Date: Mon, 15 Apr 2013 11:54:32 -0500
Subject: [PATCH V4 10/18] ARM: OMAP2+: Add function to read GPMC settings
 from device-tree
In-Reply-To: <20130415132737.A2A6E3E0AA8@localhost>
References: <1363710956-26773-1-git-send-email-jon-hunter@ti.com>
 <1363710956-26773-11-git-send-email-jon-hunter@ti.com>
 <20130415132737.A2A6E3E0AA8@localhost>
Message-ID: <516C30C8.2000804@ti.com>


On 04/15/2013 08:27 AM, Grant Likely wrote:
> On Tue, 19 Mar 2013 11:35:48 -0500, Jon Hunter <jon-hunter at ti.com> wrote:
>> Adds a function to read the various GPMC chip-select settings from
>> device-tree and store them in the gpmc_settings structure.
>>
>> Update the GPMC device-tree binding documentation to describe these
>> options.
>>
>> Signed-off-by: Jon Hunter <jon-hunter at ti.com>
>> Tested-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
>> ---
>>  Documentation/devicetree/bindings/bus/ti-gpmc.txt |   23 ++++++++++++
>>  arch/arm/mach-omap2/gpmc.c                        |   40 +++++++++++++++++++++
>>  arch/arm/mach-omap2/gpmc.h                        |    2 ++
>>  3 files changed, 65 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/bus/ti-gpmc.txt b/Documentation/devicetree/bindings/bus/ti-gpmc.txt
>> index 5ddb2e9..6fde1cf 100644
>> --- a/Documentation/devicetree/bindings/bus/ti-gpmc.txt
>> +++ b/Documentation/devicetree/bindings/bus/ti-gpmc.txt
>> @@ -65,6 +65,29 @@ The following are only applicable to OMAP3+ and AM335x:
>>   - gpmc,wr-access
>>   - gpmc,wr-data-mux-bus
>>  
>> +GPMC chip-select settings properties for child nodes. All are optional.
>> +
>> +- gpmc,burst-length	Page/burst length. Must be 4, 8 or 16.
>> +- gpmc,burst-wrap	Enables wrap bursting
>> +- gpmc,burst-read	Enables read page/burst mode
>> +- gpmc,burst-write	Enables write page/burst mode
>> +- gpmc,device-nand	Device is NAND
>> +- gpmc,device-width	Total width of device(s) connected to a GPMC
>> +			chip-select in bytes. The GPMC supports 8-bit
>> +			and 16-bit devices and so this property must be
>> +			1 or 2.
> 
> I would suggest specifying the actual number of bits. ie. 8 or 16. There is some
> precidence for that already in DT bindings.

I used bytes and not bits here as it was more convenient for programming
a register bit field. However, it would be equally easy to shift the
value and program the register if we use bits. So this can be changed.

By the way, I have seen some of the flash bindings (eg. mtd-physmap.txt)
use bytes and not bits, however, I do see others use bits (nand.txt).
However, if the preference is for bits then we can conform to that.

Tony has this queued for v3.10 now. However, we can fix this up if you
feel strongly about this.

>> +- gpmc,mux-add-data	Address and data multiplexing configuration.
>> +			Valid values are 1 for address-address-data
>> +			multiplexing mode and 2 for address-data
>> +			multiplexing mode.
>> +- gpmc,sync-read	Enables synchronous read. Defaults to asynchronous
>> +			is this is not set.
> 
> 'if'?
> 
>> +- gpmc,sync-write	Enables synchronous writes. Defaults to asynchronous
>> +			is this is not set.
>> +- gpmc,wait-pin		Wait-pin used by client. Must be less than
>> +			"gpmc,num-waitpins".
>> +- gpmc,wait-on-read	Enables wait monitoring on reads.
>> +- gpmc,wait-on-write	Enables wait monitoring on writes.
> 
> Otherwise looks okay to me.

Thanks
Jon


From swarren at wwwdotorg.org  Mon Apr 15 12:58:43 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Mon, 15 Apr 2013 10:58:43 -0600
Subject: [PATCH 3/5] gpio/omap: Add DT support to GPIO driver
In-Reply-To: <CACRpkda4h+qXTvsirPAS7E7sjXhMLE62q=VDy53W8UchsYjbNg@mail.gmail.com>
References: <1329321854-24490-1-git-send-email-b-cousson@ti.com>
 <20130302200524.D230F3E1571@localhost> <51391F41.5000303@ti.com>
 <CAAwP0s1CFRO-rf==p5sYs1n0gigMif7wuT8Yv0N_iLUDMrtcOg@mail.gmail.com>
 <CACRpkdYHj-rEF3Rk_CWnmmMw_Amr7m8SgQ=-2zsDYuLeuu3azw@mail.gmail.com>
 <514C79E1.4090106@wwwdotorg.org> <514CE0AB.6060207@ti.com>
 <CACRpkdZmv-rAoKSQYpkHHSMzKJOn5TixVW_P3=m7ZNagBYCUPw@mail.gmail.com>
 <515319D5.20105@wwwdotorg.org>
 <CACRpkdYXVLgCz1Tyu-Ls2V2OTc4R3cGNJhfQJB6Hiz_K9dkZYQ@mail.gmail.com>
 <5155C902.7080207@wwwdotorg.org>
 <CACRpkdYbs4-uudpRUY8e+7icYYkZrfM0kReP3pLL5DMiURJ4dg@mail.gmail.com>
 <5165CB9D.1090202@wwwdotorg.org>
 <CACRpkdYirFNqmGhA4K9CL4ve4NYhs8Rd3SFt1iwW9vHBkrcz8g@mail.gmail.com>
 <51671D7B.5060303@wwwdotorg.org>
 <CACRpkdbf32Ef77GmXk9id9+RRjcDRTr7S+F4nznoeZU8y=BT_Q@mail.gmail.com>
 <51673D70.3010503@wwwdotorg.org>
 <CAAwP0s0e2x33jZQhFRY+Hoo61SFqYKRgWk=1mL2+DNxSDJHz+A@mail.gmail.com>
 <CACRpkda4h+qXTvsirPAS7E7sjXhMLE62q=VDy53W8UchsYjbNg@mail.gmail.com>
Message-ID: <516C31C3.9040505@wwwdotorg.org>

On 04/14/2013 02:53 PM, Linus Walleij wrote:
> On Sun, Apr 14, 2013 at 3:35 AM, Javier Martinez Canillas
> <martinez.javier at gmail.com> wrote:
> 
>> Is the following inlined patch [1] what you were thinking that would
>> be the right approach?
> 
> This looks sort of OK, but I'm still struggling with the question of
> what we could do to help other implementations facing the same issue.
> 
> This is a pretty hard design pattern to properly replicate in every such
> driver is it not?

Well, instead of adding .request_irq() to the irqchip, and then making
each driver call gpio_request() from the implementation, perhaps you
could add a .irq_to_gpio() to the irqchip, have the IRQ core call that,
and if it gets back a non-error response, the IRQ core could call
gpio_request(). That means that the change to each GPIO+IRQ driver is
simply to implement a standalone data transformation function
.irq_to_gpio().

Now, this does re-introduce irq_to_gpio() in some way, but with the
following advantages:

1) The implementation is per-controller, not a single global function,
so isn't introducing any kind of centralized mapping scheme again.

2) This irq-chip-specific .irq_to_gpio() would only be implemented for
IRQ+GPIO chips that actually have a 1:1 mapping between GPIOs and IRQs.
Its potential existence doesn't imply that all IRQ chips need implement
this; it would be very specifically be for this one particular case.

So, I think it's reasonable to introduce this.


From mugunthanvnm at ti.com  Mon Apr 15 13:04:00 2013
From: mugunthanvnm at ti.com (Mugunthan V N)
Date: Mon, 15 Apr 2013 22:34:00 +0530
Subject: [PATCH 3/3] driver: net: ethernet: cpsw: dual emac interface
 implementation
In-Reply-To: <516B016F.3020308@mimc.co.uk>
References: <1360612340-9266-1-git-send-email-mugunthanvnm@ti.com>
 <1360612340-9266-4-git-send-email-mugunthanvnm@ti.com>
 <516B016F.3020308@mimc.co.uk>
Message-ID: <516C3300.10005@ti.com>

On 4/15/2013 12:50 AM, Mark Jackson wrote:
> On 11/02/13 19:52, Mugunthan V N wrote:
>> The CPSW switch can act as Dual EMAC by segregating the switch ports
>> using VLAN and port VLAN as per the TRM description in
>> 14.3.2.10.2 Dual Mac Mode
>>
>> Following CPSW components will be common for both the interfaces.
>> * Interrupt source is common for both eth interfaces
>> * Interrupt pacing is common for both interfaces
>> * Hardware statistics is common for all the ports
>> * CPDMA is common for both eth interface
>> * CPTS is common for both the interface and it should not be enabled on
>>    both the interface as timestamping information doesn't contain port
>>    information.
>>
>> Constrains
>> * Reserved VID of One port should not be used in other interface 
>> which will
>>    enable switching functionality
>> * Same VID must not be used in both the interface which will enable 
>> switching
>>    functionality
>>
>> Signed-off-by: Mugunthan V N <mugunthanvnm at ti.com>
>> ---
>
>> @@ -1237,6 +1372,18 @@ static int cpsw_probe_dt(struct 
>> cpsw_platform_data *data,
>>           if (mac_addr)
>>               memcpy(slave_data->mac_addr, mac_addr, ETH_ALEN);
>>
>> +        if (data->dual_emac) {
>> +            if (of_property_read_u32(node, "dual_emac_res_vlan",
>> +                         &prop)) {
>
> Shouldn't this be:-
>
>     if (of_property_read_u32(slave_node, "dual_emac_res_vlan",
>                                  ^^^^^^^^^^
>
> ... so we pick each VLAN id from the individual slaves ?

Good catch, will send a fixup patch for this.

Regards
Mugunthan V N


From mugunthanvnm at ti.com  Mon Apr 15 13:07:30 2013
From: mugunthanvnm at ti.com (Mugunthan V N)
Date: Mon, 15 Apr 2013 22:37:30 +0530
Subject: [PATCH 0/3] Dual EMAC mode implementation of CPSW
In-Reply-To: <516B0098.4040809@mimc.co.uk>
References: <1360612340-9266-1-git-send-email-mugunthanvnm@ti.com>
 <516B0098.4040809@mimc.co.uk>
Message-ID: <516C33D2.4050105@ti.com>

On 4/15/2013 12:46 AM, Mark Jackson wrote:
> On 11/02/13 19:52, Mugunthan V N wrote:
>> This patch series implements Dual EMAC mode implementation of CPSW
>> which acts as two standalone EMAC by segregating the switch using VIDs
>> and port VLAN
>>
>> Mugunthan V N (3):
>>    driver: net: ethernet: davinci_cpdma: add support for directed packet
>>      and source port detection
>>    driver: net: ethernet: cpsw: make cpts as pointer
>>    driver: net: ethernet: cpsw: dual emac interface implementation
>>
>>   Documentation/devicetree/bindings/net/cpsw.txt |    2 +
>>   drivers/net/ethernet/ti/cpsw.c                 |  387 
>> +++++++++++++++++++-----
>>   drivers/net/ethernet/ti/davinci_cpdma.c        |   17 +-
>>   drivers/net/ethernet/ti/davinci_cpdma.h        |    4 +-
>>   drivers/net/ethernet/ti/davinci_emac.c         |    6 +-
>>   include/linux/platform_data/cpsw.h             |    3 +
>>   6 files changed, 338 insertions(+), 81 deletions(-)
>
> I'm trying to get dual emac mode working, but I'm only having partial 
> success.  We have a custom AM335x board with dual LAN8710 PYHs, but 
> the basic design is based on the BeagleBone board.
>
> I have the following in my .dts file:-
>
> mac: ethernet at 4a100000 {
>     dual_emac = <1>;
>     cpsw_emac0: slave at 4a100200 {
>         dual_emac_res_vlan = <1>;
>     };
>     cpsw_emac1: slave at 4a100300 {
>         dual_emac_res_vlan = <2>;
>     };
> };
>
> When I boot my board (across nfs via eth1):-
>
> (a) the kernel is loaded (via tftp under U-Boot)
> (b) the kernel mounts the nfsroot
> (c) my init scripts are run (e.g. dropbear)
> (d) the shell prompt appears
>
> So far so good, but when I then try any shell command (e.g. "ps") the 
> nfs link just hangs.
>
> Below is an extract from the boot messages:-
>
> [    0.000000] Booting Linux on physical CPU 0x0
> [    0.000000] Linux version 3.9.0-rc6-00186-g5b55d70-dirty 
> (mpfj at mpfj-nanobone) (gcc version 4.7.2 (Buildroot 
> 2013.02-00154-g851ceaa) ) #19 Sun Apr 14 19:50:21 BST 2013
> [    0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), 
> cr=10c53c7d
> [    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
> instruction cache
> [    0.000000] Machine: Generic AM33XX (Flattened Device Tree), model: 
> Newflow AM335x NanoBone
> [    0.000000] Memory policy: ECC disabled, Data cache writeback
> [    0.000000] CPU: All CPU(s) started in SVC mode.
> [    0.000000] AM335X ES1.0 (neon )
> [    0.000000] Built 1 zonelists in Zone order, mobility grouping on. 
> Total pages: 64768
> [    0.000000] Kernel command line: root=/dev/nfs 
> nfsroot=10.1.0.111:/tftpboot/nanobone/rootfs rw 
> ip=10.1.0.199:10.1.0.111:10.1.0.1:255.255.0.0::eth1:off 
> console=ttyO0,115200
> ...
> [    1.424977] davinci_mdio 4a101000.mdio: davinci mdio revision 1.6
> [    1.431443] davinci_mdio 4a101000.mdio: detected phy mask fffffffc
> [    1.440939] libphy: 4a101000.mdio: probed
> [    1.445266] davinci_mdio 4a101000.mdio: phy[0]: device 
> 4a101000.mdio:00, driver SMSC LAN8710/LAN8720
> [    1.454962] davinci_mdio 4a101000.mdio: phy[1]: device 
> 4a101000.mdio:01, driver SMSC LAN8710/LAN8720
> [    1.465059] Random MACID = a2:3f:fb:2c:47:d9
> [    1.472276] cpsw: Random MACID = ae:d5:c0:c0:27:03
> [    1.480588] rtc-ds1307 0-0068: setting system clock to 2013-04-14 
> 19:59:52 UTC (1365969592)
> [    1.491543] net eth1: initializing cpsw version 1.12 (0)
> [    1.516965] net eth1: phy found : id is : 0x7c0f1
> [    4.595479] libphy: 4a101000.mdio:01 - Link is Up - 100/Full
> [    4.625872] IP-Config: Complete:
> [    4.629307]      device=eth1, hwaddr=ae:d5:c0:c0:27:03, 
> ipaddr=10.1.0.199, mask=255.255.0.0, gw=10.1.0.1
> [    4.639365]      host=10.1.0.199, domain=, nis-domain=(none)
> [    4.645359]      bootserver=10.1.0.111, rootserver=10.1.0.111, 
> rootpath=
> [    4.674219] VFS: Mounted root (nfs filesystem) on device 0:12.
> [    4.682438] devtmpfs: mounted
> [    4.686042] Freeing init memory: 196K
> Starting logging: OK
> Initializing random number generator... done.
> Starting network...
> ip: RTNETLINK answers: File exists
> [    5.340677] net eth0: initializing cpsw version 1.12 (0)
> [    5.366463] net eth0: phy found : id is : 0x7c0f1
> ip: RTNETLINK answers: File exists
> ip: RTNETLINK answers: File exists
> ip: RTNETLINK answers: File exists
> Starting dropbear sshd: OK
>
> Welcome to Buildroot
> nanobone login: root
> Password:
> # ps
> [   18.845266] nfs: server 10.1.0.111 not responding, still trying
>
> At this point, I can disconnect my network cable from eth1 and connect 
> to eth0, and back again which shows the PYHs appear to be detecting 
> the link up/down status of each port.
>
> [  562.675229] libphy: 4a101000.mdio:01 - Link is Down
> [  567.885586] libphy: 4a101000.mdio:00 - Link is Up - 100/Full
> [  571.965156] libphy: 4a101000.mdio:00 - Link is Down
> [  575.014943] nfs: server 10.1.0.111 not responding, still trying
> [  576.635412] libphy: 4a101000.mdio:01 - Link is Up - 100/Full
> [  579.426051] nfs: server 10.1.0.111 OK
>
> Notice that at the end, the nfs link appears to come back "ok", but 
> the "ps" command never completes.
>
> Any ideas of what's going on ?

I have tried ping on both the interface fine. Will verify with ps again 
later in this week.
Can you provide below details details
- Are you using EVMsk or custom build EVM?

Regards
Mugunthan V N



From s.nawrocki at samsung.com  Mon Apr 15 13:20:36 2013
From: s.nawrocki at samsung.com (Sylwester Nawrocki)
Date: Mon, 15 Apr 2013 19:20:36 +0200
Subject: [PATCH 1/7] clk: exynos: prepare for multiplatform
In-Reply-To: <201304151035.09583.arnd@arndb.de>
References: <1365775405-115297-1-git-send-email-arnd@arndb.de>
 <1365775405-115297-2-git-send-email-arnd@arndb.de>
 <CAJuYYwRfoU1y_3qbZtdhdyRugPD_QCYWr_LuesOXzq+-jmxouw@mail.gmail.com>
 <201304151035.09583.arnd@arndb.de>
Message-ID: <516C36E4.1090505@samsung.com>

On 04/15/2013 10:35 AM, Arnd Bergmann wrote:
> On Monday 15 April 2013, Thomas Abraham wrote:
>> On 12 April 2013 19:33, Arnd Bergmann <arnd at arndb.de> wrote:
>>> The new common clock drivers for exynos are using compile
>>> time constants and soc_is_exynos* macros to provide backwards
>>> compatibility for pre-DT systems, which is not possible with
>>> multiplatform kernels. This moves all the necessary
>>> information back into platform code and removes the mach/*
>>> header inclusions.
>>
>>
>> Since kgene has submitted a patch to remove pre-dt Exynos support
>> which looks like it will be accepted, we could just remove the use of
>> soc_is_xyz() instead of continuing to support non-dt Exynos.
> 
> I think based on the most recent discussion, we are not actually doing
> that for 3.10, since there are still people that require ATAGS support.

It seems patches from Tomasz [1] will likely make it to 3.10, thus
it is fine to apply Kukjin's patch as far as we are concerned.

Besides, it seems some drivers are already broken with ATAGS booting
(e.g. Exynos DRM, SDHCI) due to introduction of the common clock
framework driver. It doesn't seem worthwhile to spend time fixing
this, I would rather focus on improving the DT support.

Sorry for any confusion.

[1] http://www.spinics.net/lists/arm-kernel/msg238387.html

Sylwester


From dianders at chromium.org  Mon Apr 15 13:23:17 2013
From: dianders at chromium.org (Doug Anderson)
Date: Mon, 15 Apr 2013 10:23:17 -0700
Subject: [PATCH] spi: s3c64xx: let device core setup the default pin
 configuration
In-Reply-To: <CAD=FV=W++WXLOazKR=f6PHdzr=AVOwyT2i=swNtw6yMOJhJgmA@mail.gmail.com>
References: <1362570130-14084-1-git-send-email-thomas.abraham@linaro.org>
 <CAD=FV=W++WXLOazKR=f6PHdzr=AVOwyT2i=swNtw6yMOJhJgmA@mail.gmail.com>
Message-ID: <CAD=FV=V99ucNRuZ3iAb7Eh5XTmWNRVOXqP8af_a6ii98hoV76Q@mail.gmail.com>

Mark,

On Mon, Mar 11, 2013 at 10:36 AM, Doug Anderson <dianders at chromium.org> wrote:
> Thomas,
>
> On Wed, Mar 6, 2013 at 3:42 AM, Thomas Abraham
> <thomas.abraham at linaro.org> wrote:
>> With device core now able to setup the default pin configuration,
>> the pin configuration code based on the deprecated Samsung specific
>> gpio bindings is removed.
>>
>> Signed-off-by: Thomas Abraham <thomas.abraham at linaro.org>
>> ---
>>  .../devicetree/bindings/spi/spi-samsung.txt        |    8 +--
>>  drivers/spi/spi-s3c64xx.c                          |   66 +------------------
>>  2 files changed, 6 insertions(+), 68 deletions(-)

Is this something you would pick up?  It looks like you weren't copied
on the original email thread, unfortunately.

Without this (or some equivalent) patch we can't use the SPI driver on
any SoCs that have switched over to the proper pinmux support.

Thanks!

-Doug


From nsekhar at ti.com  Mon Apr 15 13:23:17 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Mon, 15 Apr 2013 22:53:17 +0530
Subject: [GIT PULL 1/3] ARM: davinci: DT updates for v3.10 (part 2)
Message-ID: <1366046599-6590-1-git-send-email-nsekhar@ti.com>

Hi Arnd, Olof,

Can you please pull these DaVinci DT updates for v3.10?
The SPI patches were waiting for Grant's ack. Grant hasn't
responded but the changes are pretty non-controversial.

One patch removes wild-cards in binding names and ties
them to complete part numbers. Another patch documents
the bindings. This patch should have gone in last merge
window itself since the bindings were accepted in v3.9
itself. Rest of the patches just make use of accepted
bindings.

Thanks,
Sekhar

The following changes since commit db4c8fa7c0214c83cbbc990ba630b3b613fcf7c5:

  ARM: davinci: da850: override mmc DT node device name (2013-04-04 16:58:10 +0530)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-for-v3.10/dt-2

for you to fetch changes up to 24a1415d10718d10231e2284fb8fbeff44d3641d:

  ARM: davinci: da850-evm: add SPI flash support (2013-04-15 12:16:52 +0530)

----------------------------------------------------------------
v3.10 DT updates for DaVinci

This set of patches adds support for PWMs and SPI
controller present on DA850 and for SPI flash present on
DA850 EVM.

----------------------------------------------------------------
Manjunathappa, Prakash (4):
      spi/davinci: no wildcards in DT compatible property
      ARM: davinci: da850: add SPI1 DT node
      ARM: davinci: da850: override SPI DT node device name
      ARM: davinci: da850-evm: add SPI flash support

Murali Karicheri (1):
      spi/davinci: add DT binding documentation

Philip Avinash (1):
      ARM: davinci: da850: add EHRPWM & ECAP DT node

 .../devicetree/bindings/spi/spi-davinci.txt        |   51 +++++++++++
 arch/arm/boot/dts/da850-evm.dts                    |   40 +++++++++
 arch/arm/boot/dts/da850.dtsi                       |   94 ++++++++++++++++++++
 arch/arm/mach-davinci/da8xx-dt.c                   |    6 ++
 drivers/spi/spi-davinci.c                          |    4 +-
 5 files changed, 193 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/spi/spi-davinci.txt


From nsekhar at ti.com  Mon Apr 15 13:23:18 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Mon, 15 Apr 2013 22:53:18 +0530
Subject: [GIT PULL 2/3] ARM: davinci: SoC updates for v3.10 (part 2)
In-Reply-To: <1366046599-6590-1-git-send-email-nsekhar@ti.com>
References: <1366046599-6590-1-git-send-email-nsekhar@ti.com>
Message-ID: <1366046599-6590-2-git-send-email-nsekhar@ti.com>

Hi Arnd, Olof,

Can you please the following SoC updates for DaVinci.
The branch depends on (and merges) an immutable branch
from Ohad adding DA8XX rempote proc driver.

Thanks,
Sekhar

The following changes since commit a0e5cda94cf0fab47a9bc87c50bce7f5cd26acda:

  Merge branch 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/ohad/remoteproc into v3.10/soc (2013-04-15 14:37:45 +0530)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-for-v3.10/soc-2

for you to fetch changes up to 1511a86e71baebc7b27da5f52cbaf3272f13d556:

  ARM: davinci: ensure global variables are declared (2013-04-15 15:13:13 +0530)

----------------------------------------------------------------
v3.10 SoC updates for DaVinci

This set of patches add support for remoteproc
used to control the DSP and also fix sparse
errors existing for quite some time.

----------------------------------------------------------------
Robert Tivy (1):
      ARM: davinci: da8xx: add remoteproc support

Sekhar Nori (3):
      ARM: davinci: da8xx dt: make file local symbols static
      ARM: davinci: sram.c: fix incorrect type in assignment
      ARM: davinci: ensure global variables are declared

 Documentation/kernel-parameters.txt        |    6 ++
 arch/arm/mach-davinci/da8xx-dt.c           |    4 +-
 arch/arm/mach-davinci/devices-da8xx.c      |   88 +++++++++++++++++++++++++++-
 arch/arm/mach-davinci/include/mach/da8xx.h |    4 ++
 arch/arm/mach-davinci/pm.c                 |    1 +
 arch/arm/mach-davinci/sram.c               |    4 +-
 arch/arm/mach-davinci/usb.c                |    1 +
 7 files changed, 103 insertions(+), 5 deletions(-)


From nsekhar at ti.com  Mon Apr 15 13:23:19 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Mon, 15 Apr 2013 22:53:19 +0530
Subject: [GIT PULL 3/3] ARM: davinci: board updates for v3.10 (part 2)
In-Reply-To: <1366046599-6590-1-git-send-email-nsekhar@ti.com>
References: <1366046599-6590-1-git-send-email-nsekhar@ti.com>
Message-ID: <1366046599-6590-3-git-send-email-nsekhar@ti.com>

Hi Arnd, Olof,

Please pull the following board updates for v3.10. This
depends on SoC updates in previous request.

Thanks,
Sekhar

The following changes since commit 1511a86e71baebc7b27da5f52cbaf3272f13d556:

  ARM: davinci: ensure global variables are declared (2013-04-15 15:13:13 +0530)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-for-v3.10/board-2

for you to fetch changes up to 38406c06e00a1cef839ac3efb886df153bb8f448:

  ARM: davinci: da850 evm: fix const qualifier placement (2013-04-15 15:17:06 +0530)

----------------------------------------------------------------
v3.10 board updates for DaVinci

This set of patches enables remoteproc support
on DA850 EVM and fixes some sparse warnings for
the same board.

----------------------------------------------------------------
Robert Tivy (1):
      ARM: davinci: da850 board: add remoteproc support

Sekhar Nori (1):
      ARM: davinci: da850 evm: fix const qualifier placement

 arch/arm/mach-davinci/board-da850-evm.c     |   10 ++++++++--
 arch/arm/mach-davinci/board-omapl138-hawk.c |    6 ++++++
 2 files changed, 14 insertions(+), 2 deletions(-)


From mpfj-list at mimc.co.uk  Mon Apr 15 13:28:25 2013
From: mpfj-list at mimc.co.uk (Mark Jackson)
Date: Mon, 15 Apr 2013 18:28:25 +0100
Subject: [PATCH 0/3] Dual EMAC mode implementation of CPSW
In-Reply-To: <516C33D2.4050105@ti.com>
References: <1360612340-9266-1-git-send-email-mugunthanvnm@ti.com>
 <516B0098.4040809@mimc.co.uk> <516C33D2.4050105@ti.com>
Message-ID: <516C38B9.50904@mimc.co.uk>

On 15/04/13 18:07, Mugunthan V N wrote:
> On 4/15/2013 12:46 AM, Mark Jackson wrote:

<snip>

>>
>> Notice that at the end, the nfs link appears to come back "ok", but
>> the "ps" command never completes.
>>
>> Any ideas of what's going on ?
>
> I have tried ping on both the interface fine. Will verify with ps again
> later in this week.
> Can you provide below details details
> - Are you using EVMsk or custom build EVM?

This is a custom board (based on the BeagleBone design) with dual 
Ethernet, NAND, NOR and FRAM.

The dual emac thing is (one of) the last things to get signed off, so 
I'm willing to assist in tracking this down.

Regards
Mark J.


From mugunthanvnm at ti.com  Mon Apr 15 13:34:05 2013
From: mugunthanvnm at ti.com (Mugunthan V N)
Date: Mon, 15 Apr 2013 23:04:05 +0530
Subject: [PATCH 0/3] Dual EMAC mode implementation of CPSW
In-Reply-To: <516C38B9.50904@mimc.co.uk>
References: <1360612340-9266-1-git-send-email-mugunthanvnm@ti.com>
 <516B0098.4040809@mimc.co.uk> <516C33D2.4050105@ti.com>
 <516C38B9.50904@mimc.co.uk>
Message-ID: <516C3A0D.70903@ti.com>

On 4/15/2013 10:58 PM, Mark Jackson wrote:
> On 15/04/13 18:07, Mugunthan V N wrote:
>> On 4/15/2013 12:46 AM, Mark Jackson wrote:
>
> <snip>
>
>>>
>>> Notice that at the end, the nfs link appears to come back "ok", but
>>> the "ps" command never completes.
>>>
>>> Any ideas of what's going on ?
>>
>> I have tried ping on both the interface fine. Will verify with ps again
>> later in this week.
>> Can you provide below details details
>> - Are you using EVMsk or custom build EVM?
>
> This is a custom board (based on the BeagleBone design) with dual 
> Ethernet, NAND, NOR and FRAM.
>
> The dual emac thing is (one of) the last things to get signed off, so 
> I'm willing to assist in tracking this down.

After testing the scenario i may be able to send you an update later in 
this week.

Regards
Mugunthan V N


From jason at lakedaemon.net  Mon Apr 15 13:56:41 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Mon, 15 Apr 2013 13:56:41 -0400
Subject: [PATCH v6 0/3] of/pci: Provide common support for PCI DT parsing
In-Reply-To: <1365693969-23907-1-git-send-email-Andrew.Murray@arm.com>
References: <1365693969-23907-1-git-send-email-Andrew.Murray@arm.com>
Message-ID: <20130415175641.GM28693@titan.lakedaemon.net>

Andrew Murray, Thomas,

On Thu, Apr 11, 2013 at 04:26:06PM +0100, Andrew Murray wrote:
> This patchset factors out duplicated code associated with parsing PCI
> DT "ranges" properties across the architectures and introduces a
> "ranges" parser. This parser "of_pci_range_parser" can be used directly
> by ARM host bridge drivers enabling them to obtain ranges from device
> trees.
> 
> I've included the Reviewed-by and Tested-by's received from v5 in this
> patchset, earlier versions of this patchset (v3) have been tested-by:
> 
> Thierry Reding <thierry.reding at avionic-design.de>
> Jingoo Han <jg1.han at samsung.com>
> 
> I believe a version of this patchset has also been tested through its
> inclusion in Thomas Petazzoni's Armada 370 and Armada XP SoCs PCIe support by:
> 
> Linus Walleij <linus.walleij at linaro.org>
> 
> I've tested that this patchset builds and runs on ARM and that it builds on
> PowerPC.
> 
> Compared to the v5 sent by Andrew Murray, the following changes have
> been made:
> 
>  * Use of CONFIG_64BIT instead of CONFIG_[a32bitarch] as suggested by
>    Rob Herring in drivers/of/of_pci.c
> 
>  * Added forward declaration of struct pci_controller in linux/of_pci.h
>    to prevent compiler warning as suggested by Thomas Petazzoni
> 
>  * Improved error checking (!range check), removal of unnecessary be32_to_cpup
>    call, improved formatting of struct of_pci_range_parser layout and
>    replacement of macro with a static inline. All suggested by Rob Herring.
> 
> Compared to the v4 (incorrectly labelled v3) sent by Andrew Murray,
> the following changes have been made:
> 
>  * Split the patch as suggested by Rob Herring
> 
> Compared to the v3 sent by Andrew Murray, the following changes have
> been made:
> 
>  * Unify and move duplicate pci_process_bridge_OF_ranges functions to
>    drivers/of/of_pci.c as suggested by Rob Herring
> 
>  * Fix potential build errors with Microblaze/MIPS
> 
> Compared to "[PATCH v5 01/17] of/pci: Provide support for parsing PCI DT
> ranges property", the following changes have been made:
> 
>  * Correct use of IORESOURCE_* as suggested by Russell King
> 
>  * Improved interface and naming as suggested by Thierry Reding
> 
> Compared to the v2 sent by Andrew Murray, Thomas Petazzoni did:
> 
>  * Add a memset() on the struct of_pci_range_iter when starting the
>    for loop in for_each_pci_range(). Otherwise, with an uninitialized
>    of_pci_range_iter, of_pci_process_ranges() may crash.
> 
>  * Add parenthesis around 'res', 'np' and 'iter' in the
>    for_each_of_pci_range macro definitions. Otherwise, passing
>    something like &foobar as 'res' didn't work.
> 
>  * Rebased on top of 3.9-rc2, which required fixing a few conflicts in
>    the Microblaze code.
> 
> v2:
>   This follows on from suggestions made by Grant Likely
>   (marc.info/?l=linux-kernel&m=136079602806328)
> 
> Andrew Murray (3):
>   of/pci: Unify pci_process_bridge_OF_ranges from Microblaze and
>     PowerPC
>   of/pci: Provide support for parsing PCI DT ranges property
>   of/pci: mips: convert to common of_pci_range_parser
> 
>  arch/microblaze/include/asm/pci-bridge.h |    5 +-
>  arch/microblaze/pci/pci-common.c         |  192 ------------------------------
>  arch/mips/pci/pci.c                      |   50 +++------
>  arch/powerpc/include/asm/pci-bridge.h    |    5 +-
>  arch/powerpc/kernel/pci-common.c         |  192 ------------------------------
>  drivers/of/address.c                     |   66 ++++++++++
>  drivers/of/of_pci.c                      |  168 ++++++++++++++++++++++++++
>  include/linux/of_address.h               |   46 +++++++
>  include/linux/of_pci.h                   |    4 +
>  9 files changed, 302 insertions(+), 426 deletions(-)

As agreed with Rob Herring, series applied to mvebu/drivers to support
mvebu pcie driver.

thx,

Jason.


From mpfj-list at mimc.co.uk  Mon Apr 15 14:00:49 2013
From: mpfj-list at mimc.co.uk (Mark Jackson)
Date: Mon, 15 Apr 2013 19:00:49 +0100
Subject: [PATCH 0/3] Dual EMAC mode implementation of CPSW
In-Reply-To: <516C3A0D.70903@ti.com>
References: <1360612340-9266-1-git-send-email-mugunthanvnm@ti.com>
 <516B0098.4040809@mimc.co.uk> <516C33D2.4050105@ti.com>
 <516C38B9.50904@mimc.co.uk> <516C3A0D.70903@ti.com>
Message-ID: <516C4051.2090100@mimc.co.uk>

On 15/04/13 18:34, Mugunthan V N wrote:
> On 4/15/2013 10:58 PM, Mark Jackson wrote:
>> On 15/04/13 18:07, Mugunthan V N wrote:
>>> On 4/15/2013 12:46 AM, Mark Jackson wrote:
>>
>> <snip>
>>
>>>>
>>>> Notice that at the end, the nfs link appears to come back "ok", but
>>>> the "ps" command never completes.
>>>>
>>>> Any ideas of what's going on ?
>>>
>>> I have tried ping on both the interface fine. Will verify with ps again
>>> later in this week.
>>> Can you provide below details details
>>> - Are you using EVMsk or custom build EVM?
>>
>> This is a custom board (based on the BeagleBone design) with dual
>> Ethernet, NAND, NOR and FRAM.
>>
>> The dual emac thing is (one of) the last things to get signed off, so
>> I'm willing to assist in tracking this down.
>
> After testing the scenario i may be able to send you an update later in
> this week.

Excellent ... if you've anything I can test now, I'd be happy to try.

Cheers
Mark J.



From davem at davemloft.net  Mon Apr 15 14:08:37 2013
From: davem at davemloft.net (David Miller)
Date: Mon, 15 Apr 2013 14:08:37 -0400 (EDT)
Subject: net: mvneta: fix improper tx queue usage in mvneta_tx()
In-Reply-To: <20130415063537.GA26507@1wt.eu>
References: <20130415063537.GA26507@1wt.eu>
Message-ID: <20130415.140837.1962205759703539734.davem@davemloft.net>

From: Willy Tarreau <w at 1wt.eu>
Date: Mon, 15 Apr 2013 08:35:37 +0200

> From 4f2069c92a27790e6071dc2a80f92c166e0b0ca4 Mon Sep 17 00:00:00 2001
> From: Willy Tarreau <w at 1wt.eu>
> Date: Thu, 11 Apr 2013 23:00:37 +0200
> Subject: net: mvneta: fix improper tx queue usage in mvneta_tx()
> 
> mvneta_tx() was using a static tx queue number causing crashes as
> soon as a little bit of traffic was sent via the interface, because
> it is normally expected that the same queue should be used as in
> dev_queue_xmit().
> 
> As suggested by Ben Hutchings, let's use skb_get_queue_mapping() to
> get the proper Tx queue number, and use alloc_etherdev_mqs() instead
> of alloc_etherdev_mq() to create the queues.
> 
> Both my Mirabox and my OpenBlocks AX3 used to crash without this patch
> and don't anymore with it. The issue appeared in 3.8 but became more
> visible after the fix allowing GSO to be enabled.
> 
> Original work was done by Dmitri Epshtein and Thomas Petazzoni. I
> just adapted it to take care of Ben's comments.
> 
> Signed-off-by: Willy Tarreau <w at 1wt.eu>

Applied.


From davem at davemloft.net  Mon Apr 15 14:10:20 2013
From: davem at davemloft.net (David Miller)
Date: Mon, 15 Apr 2013 14:10:20 -0400 (EDT)
Subject: [PATCH] net/macb: fix error return code in macb_probe()
In-Reply-To: <1366013073-22934-1-git-send-email-nicolas.ferre@atmel.com>
References: <1366013073-22934-1-git-send-email-nicolas.ferre@atmel.com>
Message-ID: <20130415.141020.1721813812373854975.davem@davemloft.net>

From: Nicolas Ferre <nicolas.ferre at atmel.com>
Date: Mon, 15 Apr 2013 10:04:33 +0200

> Fix to return a negative error code from the error handling
> case instead of 0, as returned elsewhere in this function.
> 
> Original-idea-by: <yongjun_wei at trendmicro.com.cn>
> Signed-off-by: Nicolas Ferre <nicolas.ferre at atmel.com>

Applied.


From linus.walleij at linaro.org  Mon Apr 15 14:27:52 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Mon, 15 Apr 2013 20:27:52 +0200
Subject: [PATCH] spi: s3c64xx: let device core setup the default pin
 configuration
In-Reply-To: <CAD=FV=V99ucNRuZ3iAb7Eh5XTmWNRVOXqP8af_a6ii98hoV76Q@mail.gmail.com>
References: <1362570130-14084-1-git-send-email-thomas.abraham@linaro.org>
 <CAD=FV=W++WXLOazKR=f6PHdzr=AVOwyT2i=swNtw6yMOJhJgmA@mail.gmail.com>
 <CAD=FV=V99ucNRuZ3iAb7Eh5XTmWNRVOXqP8af_a6ii98hoV76Q@mail.gmail.com>
Message-ID: <CACRpkdbsL-PfTudLSnq7dBeJpzBjJ70edHSXkrH6MqZ8vhvf5A@mail.gmail.com>

On Mon, Apr 15, 2013 at 7:23 PM, Doug Anderson <dianders at chromium.org> wrote:

> Mark,
(...)
> Is this something you would pick up?  It looks like you weren't copied
> on the original email thread, unfortunately.

Resend the patch with collected ACKs and Mark+Grant explitly on the
To: line and I think it'll be picked up.

Yours,
Linus Walleij


From swarren at wwwdotorg.org  Mon Apr 15 14:28:12 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Mon, 15 Apr 2013 12:28:12 -0600
Subject: [PATCH v3 07/12] PCI: tegra: Move PCIe driver to drivers/pci/host
In-Reply-To: <1365000318-28256-8-git-send-email-thierry.reding@avionic-design.de>
References: <1365000318-28256-1-git-send-email-thierry.reding@avionic-design.de>
 <1365000318-28256-8-git-send-email-thierry.reding@avionic-design.de>
Message-ID: <516C46BC.2040707@wwwdotorg.org>

On 04/03/2013 08:45 AM, Thierry Reding wrote:
> Move the PCIe driver from arch/arm/mach-tegra into the drivers/pci/host
> directory. The motivation is to collect various host controller drivers
> in the same location in order to facilitate refactoring.
> 
> The Tegra PCIe driver has been largely rewritten, both in order to turn
> it into a proper platform driver and to add MSI (based on code by
> Krishna Kishore <kthota at nvidia.com>) as well as device tree support.

> diff --git a/drivers/pci/host/pci-tegra.c b/drivers/pci/host/pci-tegra.c

> +struct tegra_msi {
> +	DECLARE_BITMAP(used, INT_PCI_MSI_NR);
> +	struct irq_domain *domain;
> +	struct msi_chip chip;

Nit: You could move that to be the first field in the struct, then
to_tegra_msi() would end up being a no-op, which might save a byte or two.

> +static int tegra_pcie_write_conf(struct pci_bus *bus, unsigned int devfn,
> +				 int where, int size, u32 value)
...
> +	if (bus->number == 0) {
> +		unsigned int slot = PCI_SLOT(devfn);
> +		struct tegra_pcie_port *port;
> +
> +		list_for_each_entry(port, &pcie->ports, list) {
> +			if (port->index + 1 == slot) {
> +				addr = port->base + (where & ~3);
> +				break;
> +			}
> +		}
> +	} else {
> +		addr = tegra_pcie_bus_map(pcie, bus->number);
> +		if (!addr) {
> +			dev_err(pcie->dev,
> +				"failed to map cfg. space for bus %u\n",
> +				bus->number);
> +			return PCIBIOS_DEVICE_NOT_FOUND;
> +		}
> +
> +		addr += tegra_pcie_conf_offset(devfn, where);
> +	}

It seems like that chunk of code could be shared between
tegra_pcie_read_conf() and tegra_pcie_write_conf().

Also, tegra_pcie_read_conf() checks again for addr == NULL and returns
if so. read and write should be consistent.

> +static void tegra_pcie_port_free(struct tegra_pcie_port *port)
> +{
> +	struct tegra_pcie *pcie = port->pcie;
> +
> +	devm_iounmap(pcie->dev, port->base);
> +	devm_release_mem_region(pcie->dev, port->regs.start,
> +				resource_size(&port->regs));
> +	list_del(&port->list);
> +	devm_kfree(pcie->dev, port);
> +}

Do ports get allocated and freed separately from the host controller,
such that it's actually worth manually calling the
devm_iounmap/release/free functions?

> +static int tegra_pcie_enable_controller(struct tegra_pcie *pcie)
...
> +	/* disable all exceptions */
> +	afi_writel(pcie, 0, AFI_FPCI_ERROR_MASKS);

Is that a good idea?

> +static int tegra_pcie_get_resources(struct tegra_pcie *pcie)

> +	err = devm_request_irq(&pdev->dev, pcie->irq, tegra_pcie_isr,
> +			       IRQF_SHARED, "PCIE", pcie);

devm_request_irq and IRQF_SHARED sounds like a bad combination; what if
the IRQ goes off after this driver's remove() is called, but before the
driver core devm cleanup runs?

> +static irqreturn_t tegra_pcie_msi_irq(int irq, void *data)
...
> +	return IRQ_HANDLED;

Shouldn't this function return IRQ_NONE if no MSI status bits were found
set?

> +static int tegra_pcie_enable_msi(struct tegra_pcie *pcie)

> +	/* setup AFI/FPCI range */
> +	msi->pages = __get_free_pages(GFP_KERNEL, 3);

If tegra_msi_setup_irq() hard-codes the MSI address as msi->pages, then
I expect you can get away with a single page here. Of course, perhaps
tegra_msi_setup_irq() is supposed to give a different address to every
MSI client? Even so, 256 clients * 4 bytes is still less than 1 page.

> +static u32 tegra_pcie_get_xbar_config(struct tegra_pcie *pcie, u32 lanes)
> +{
> +	struct device_node *np = pcie->dev->of_node;
> +
> +	switch (lanes) {
> +	case 0x00000004:
> +		dev_info(pcie->dev, "single-mode configuration\n");
> +		return AFI_PCIE_CONFIG_SM2TMS0_XBAR_CONFIG_SINGLE;
> +
> +	case 0x00000202:
> +		dev_info(pcie->dev, "dual-mode configuration\n");
> +		return AFI_PCIE_CONFIG_SM2TMS0_XBAR_CONFIG_DUAL;
> +	}
> +
> +	return 0;

Shouldn't that return an error, and dev_err() about it? If not, then I
think using one of the #defines for the default would make the result a
lot more obvious.

> +static int tegra_pcie_parse_dt(struct tegra_pcie *pcie)

> +	pcie->xbar_config = tegra_pcie_get_xbar_config(pcie, lanes);
> +	if (!pcie->xbar_config) {
> +		dev_err(pcie->dev, "invalid lane configuration\n");
> +		return -EINVAL;
> +	}

Oh, but AFI_PCIE_CONFIG_SM2TMS0_XBAR_CONFIG_SINGLE==0, which is valid...

> +static bool tegra_pcie_port_check_link(struct tegra_pcie_port *port)
...
> +			if (value & 0x20000000)
> +				return true;

Can we use a #define for 0x20000000?

> +static int tegra_pcie_enable(struct tegra_pcie *pcie)
> +{
> +	struct tegra_pcie_port *port, *tmp;
> +	struct hw_pci hw;
> +
> +	list_for_each_entry_safe(port, tmp, &pcie->ports, list) {
> +		dev_info(pcie->dev, "probing port %u, using %u lanes\n",
> +			 port->index, port->lanes);
> +
> +		tegra_pcie_port_enable(port);
> +
> +		if (tegra_pcie_port_check_link(port))
> +			continue;
> +
> +		dev_info(pcie->dev, "link %u down, ignoring\n", port->index);
> +
> +		tegra_pcie_port_disable(port);
> +		tegra_pcie_port_free(port);
> +	}

Why is that needed; when would a port get enabled if it was already
enabled, and if it was already enabled, wouldn't you want this function
to be a no-op rather than destroying everything and starting again?

> +static int tegra_pcie_probe(struct platform_device *pdev)
...
> +	pcibios_min_mem = 0;

What does that mean/do? I wonder if that should be set to 0x80000000 by
the Tegra30 patches?


From linus.walleij at linaro.org  Mon Apr 15 14:29:06 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Mon, 15 Apr 2013 20:29:06 +0200
Subject: [PATCH v6 0/3] of/pci: Provide common support for PCI DT parsing
In-Reply-To: <20130415175641.GM28693@titan.lakedaemon.net>
References: <1365693969-23907-1-git-send-email-Andrew.Murray@arm.com>
 <20130415175641.GM28693@titan.lakedaemon.net>
Message-ID: <CACRpkdbSd8pRG5pUS0ymqXDSp=ZhoQa2ctVuRA0cCmUcX5qFAA@mail.gmail.com>

On Mon, Apr 15, 2013 at 7:56 PM, Jason Cooper <jason at lakedaemon.net> wrote:

> As agreed with Rob Herring, series applied to mvebu/drivers to support
> mvebu pcie driver.

Will this hit ARM SoC soon-ish so I can base a pull request for the Integrator
on this stuff as well?

Yours,
Linus Walleij


From nm at ti.com  Mon Apr 15 14:43:52 2013
From: nm at ti.com (Nishanth Menon)
Date: Mon, 15 Apr 2013 13:43:52 -0500
Subject: [PATCH V4 1/6] clk: OMAP: introduce device tree binding to kernel
 clock data
In-Reply-To: <516C294D.6070700@wwwdotorg.org>
References: <1365807278-554-1-git-send-email-nm@ti.com>
 <1365807278-554-2-git-send-email-nm@ti.com>
 <516C294D.6070700@wwwdotorg.org>
Message-ID: <CAGo_u6oHLxu2zqb_5e3pbnHU7Rp+ReXM9nEeHBw6_d8__aoVxQ@mail.gmail.com>

On Mon, Apr 15, 2013 at 11:22 AM, Stephen Warren <swarren at wwwdotorg.org> wrote:
> On 04/12/2013 04:54 PM, Nishanth Menon wrote:
>> OMAP clock data is located in arch/arm/mach-omap2/cclockXYZ_data.c.
>> However, this presents an obstacle for using these clock nodes in
>> Device Tree definitions. This is especially true for board specific
>> clocks initially. The fixed clocks are currently found via clock
>> aliases table. There are many possible approaches to this problem as
>> discussed in the following thread:
>> http://marc.info/?t=136370325600009&r=1&w=2.
>> Highlights of the options:
>> a) device specific clk_add_alias:
>>    cons: driver handling required
>> b) using an generic clk node and indexing to reach the clock required.
>>    This is similar in approach taken by tegra and few other platforms.
>>    Example usage: clock = <&clk 5>;
>>    cons: potential to have mismatches in indexed table and associated
>>    dtb data. In addition, managing continued documentation in bindings
>>    as clock indexing increases. Even though readability angle could be
>>    improved by using preprocessing of DT using macros, indexed
>>    approach is inherently risky from cases like the following:
>>    clk indexes in kernel:
>>    1 - mpu_dpll
>>    2 - aux_clk1
>>    3 - core_clk
>>    DT entry for peripheral X uses <&clk 2> to reach aux_clk1. Now, let's
>>    say kernel updates indices to:
>>    1 - mpu_dpll
>>    2 - per_dpll
>>    3 - aux_clk1
>>    4 - core_clk
>>    using the old dtb(or dts missing an update), on new kernel which
>>    has updated indices will result in per_dpll now controlled for
>>    peripheral X without warning or any potential error detection.
>>
>>    Even though we could claim this is user error, such errors are hard
>>    to track down and fix.
>
> The error in case (b) is that you shouldn't be changing the DT bindings
> after they've first been created. That would avoid the problem
> situation. The person using the old DTB with the new kernel didn't
> commit user error.
That is what we'd like folks to follow, but when code is in
development, or productization, there is no saying the type of
mistakes people end up doing.
>
>> An alternate approach introduced here is to introduce device tree
>> bindings corresponding to the clock nodes required in DT definition
>> for SoC which automatically maps back to the definitions in
>> cclockXYZ_data.c.
>
> Well, I haven't read the patches, but isn't that exactly what the "2" is
> in <&clk 2>?
partly so. yes: it indexes back to the right clock node - at that
point the comparison stops. we just point back on naming as needed and
introduce nodes purely for the ones that we need.

Regards,
Nishanth Menon


From linus.walleij at stericsson.com  Mon Apr 15 15:08:21 2013
From: linus.walleij at stericsson.com (Linus Walleij)
Date: Mon, 15 Apr 2013 21:08:21 +0200
Subject: [PATCH v2] ARM: ux500: DT: Rename root node "soc-u9500" into "soc"
Message-ID: <1366052901-32490-1-git-send-email-linus.walleij@stericsson.com>

From: Gabriel Fernandez <gabriel.fernandez at stericsson.com>

This root node is used in the whole family of chips, the a9500
is just one particular instance. Nodes should be named after
the type of object rather than identity.

Acked-by: Lee Jones <lee.jones at linaro.org>
Signed-off-by: Gabriel Fernandez <gabriel.fernandez at stericsson.com>
Reviewed-by: Philippe Langlais <philippe.langlais at stericsson.com>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
ChangeLog v1->v2:
- Rename from "sox-ux500" to just "soc" at Stephen's suggestion.
---
 arch/arm/boot/dts/ccu9540.dts     | 2 +-
 arch/arm/boot/dts/dbx5x0.dtsi     | 2 +-
 arch/arm/boot/dts/href.dtsi       | 2 +-
 arch/arm/boot/dts/hrefprev60.dts  | 2 +-
 arch/arm/boot/dts/hrefv60plus.dts | 2 +-
 arch/arm/boot/dts/snowball.dts    | 2 +-
 arch/arm/boot/dts/stuib.dtsi      | 2 +-
 7 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/arm/boot/dts/ccu9540.dts b/arch/arm/boot/dts/ccu9540.dts
index 0430546..c72d7aa 100644
--- a/arch/arm/boot/dts/ccu9540.dts
+++ b/arch/arm/boot/dts/ccu9540.dts
@@ -20,7 +20,7 @@
 		reg = <0x00000000 0x20000000>;
 	};
 
-	soc-u9500 {
+	soc {
 		uart at 80120000 {
 			status = "okay";
 		};
diff --git a/arch/arm/boot/dts/dbx5x0.dtsi b/arch/arm/boot/dts/dbx5x0.dtsi
index d765c38..c028fe4 100644
--- a/arch/arm/boot/dts/dbx5x0.dtsi
+++ b/arch/arm/boot/dts/dbx5x0.dtsi
@@ -12,7 +12,7 @@
 /include/ "skeleton.dtsi"
 
 / {
-	soc-u9500 {
+	soc {
 		#address-cells = <1>;
 		#size-cells = <1>;
 		compatible = "stericsson,db8500";
diff --git a/arch/arm/boot/dts/href.dtsi b/arch/arm/boot/dts/href.dtsi
index f2c0f66..85bab39 100644
--- a/arch/arm/boot/dts/href.dtsi
+++ b/arch/arm/boot/dts/href.dtsi
@@ -27,7 +27,7 @@
 		};
 	};
 
-	soc-u9500 {
+	soc {
 		uart at 80120000 {
 			status = "okay";
 		};
diff --git a/arch/arm/boot/dts/hrefprev60.dts b/arch/arm/boot/dts/hrefprev60.dts
index c2d2748..8a9357b 100644
--- a/arch/arm/boot/dts/hrefprev60.dts
+++ b/arch/arm/boot/dts/hrefprev60.dts
@@ -24,7 +24,7 @@
 		};
 	};
 
-	soc-u9500 {
+	soc {
 		prcmu at 80157000 {
 			ab8500 at 5 {
 				ab8500-gpio {
diff --git a/arch/arm/boot/dts/hrefv60plus.dts b/arch/arm/boot/dts/hrefv60plus.dts
index 55f4191..665f3a7 100644
--- a/arch/arm/boot/dts/hrefv60plus.dts
+++ b/arch/arm/boot/dts/hrefv60plus.dts
@@ -24,7 +24,7 @@
 		};
 	};
 
-	soc-u9500 {
+	soc {
 		i2c at 80110000 {
 			bu21013_tp at 0x5c {
 				reset-gpio = <&gpio4 15 0x4>;
diff --git a/arch/arm/boot/dts/snowball.dts b/arch/arm/boot/dts/snowball.dts
index 5fcd7a8..5d1c55c 100644
--- a/arch/arm/boot/dts/snowball.dts
+++ b/arch/arm/boot/dts/snowball.dts
@@ -82,7 +82,7 @@
 		};
 	};
 
-	soc-u9500 {
+	soc {
 
 		sound {
 			compatible = "stericsson,snd-soc-mop500";
diff --git a/arch/arm/boot/dts/stuib.dtsi b/arch/arm/boot/dts/stuib.dtsi
index 615392a..7fa10a7 100644
--- a/arch/arm/boot/dts/stuib.dtsi
+++ b/arch/arm/boot/dts/stuib.dtsi
@@ -10,7 +10,7 @@
  */
 
 / {
-	soc-u9500 {
+	soc {
 		i2c at 80004000 {
 			stmpe1601: stmpe1601 at 40 {
 				compatible = "st,stmpe1601";
-- 
1.7.11.3



From swarren at wwwdotorg.org  Mon Apr 15 15:26:02 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Mon, 15 Apr 2013 13:26:02 -0600
Subject: [RFC PATCH 2/2] ARM: DT: kernel: DT cpu node bindings update
In-Reply-To: <1366042402-8987-3-git-send-email-lorenzo.pieralisi@arm.com>
References: <1366042402-8987-1-git-send-email-lorenzo.pieralisi@arm.com>
 <1366042402-8987-3-git-send-email-lorenzo.pieralisi@arm.com>
Message-ID: <516C544A.4090107@wwwdotorg.org>

On 04/15/2013 10:13 AM, Lorenzo Pieralisi wrote:
> In order to extend the current cpu nodes bindings to newer CPUs
> inclusive of AArch64 and to update support for older ARM CPUs this
> patch updates device tree documentation for the cpu nodes bindings.
> 

> diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt

>  http://devicetree.org
>  
> -For the ARM architecture every CPU node must contain the following properties:
> -
...
> +with updates for 32-bit and 64-bit ARM systems provided in this document.
> +
> +In the bindings below:

That's a slightly odd change, since it removes the statement that a cpus
node must exist, and "in the bindings below" is not idiomatic for DT
binding definitions.

Perhaps replace that last list with:

The ARM architecture requires the following properties in the cpus and
cpu nodes contain the properties described below.

> +- square brackets define bitfields, eg reg[7:0] value of the bitfield in
> +  the reg property contained in bits 7 down to 0

Isn't that standard enough it's not even worth mentioning? If it is,
it's certainly not something that should be mentioned in the part of the
document that describes which properties are requried.

> +	- #address-cells
> +		Usage: required

"Usage" sounds more like what it's used for. "Presence" seems better to me.

> +			# On ARM architecture versions >= 7 based 32-bit
> +			  systems this property is required and matches the

Perhaps "On 32-bit ARMv7 or later systems, this property ..."

> +			# On ARM v8 64-bit systems, where the reg property

Should there be an explicit note here re: 32-bit SW running on a 64-bit
system?

Perhaps "on ARMv8 systems running 32-bit or 64- bit software, the reg
property ..."

> +			  is made up of two cells to accomodate the 64-bit
> +			  MPDIR_EL1 register this property is required and
> +			  matches:

s/matches/must contain/

> +	- enable-method
> +		Usage: required on ARM 64-bit systems, optional on ARM 32-bit
> +		       systems
> +		Value type: <string>
> +		Definition: On ARM 64-bit systems must be "spin-table" [1].

Can that be an integer instead? with dtc+cpp support, that shouldn't
hurt the eyes too much any more.

> +	- cpu-release-addr
> +		Usage: required on ARM 64-bit systems, optional on ARM 32-bit
> +		       systems
> +		Value type: <prop-encoded-array>
> +		Definition: On ARM 64-bit systems must be a two cell
> +			    property identifying a 64-bit zero-initialised
> +			    memory location [1].

Presumably that property is required, or not, based on the value of
enable-method, not based on the ARM architecture or bit-size?

> +[1] ARM Linux kernel documentation
> +    Documentation/devicetree/bindings/arm64/booting.txt

Is referencing Linux-specific documentation from a supposedly
OS-agnostic DT binding definition a good idea?


From s.hauer at pengutronix.de  Mon Apr 15 15:47:38 2013
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Mon, 15 Apr 2013 21:47:38 +0200
Subject: [PATCH v3 2/2] video: imxfb: Add DT support
In-Reply-To: <20130415151316.4d49e9b2@e6520eb>
References: <1365157876-1757-1-git-send-email-mpa@pengutronix.de>
 <1365157876-1757-3-git-send-email-mpa@pengutronix.de>
 <20130408075742.GR20693@game.jcrosoft.org>
 <20130414143132.GD27394@pengutronix.de>
 <20130415124321.GB15139@game.jcrosoft.org>
 <20130415151316.4d49e9b2@e6520eb>
Message-ID: <20130415194738.GE1906@pengutronix.de>

On Mon, Apr 15, 2013 at 03:13:16PM +0200, Eric B?nard wrote:
> Hi,
> 
> 
> I didn't follow the thread but dmacr is not specific to our boards :
> $ grep -rn dmacr arch/arm/mach-imx/
> arch/arm/mach-imx/mach-mx27_3ds.c:446:	.dmacr		= 0x00020010,
> arch/arm/mach-imx/mach-mx21ads.c:231:	.dmacr		= 0x00020008,
> arch/arm/mach-imx/mach-mxt_td60.c:210:	.dmacr		= 0x00020010,
> arch/arm/mach-imx/eukrea_mbimx27-baseboard.c:192:	.dmacr		= 0x00040060,
> arch/arm/mach-imx/eukrea_mbimxsd25-baseboard.c:165:	.dmacr		= 0x00040060,
> arch/arm/mach-imx/mach-mx27ads.c:241:	.dmacr		= 0x00020010,
> arch/arm/mach-imx/mach-pca100.c:351:	.dmacr		= 0x00020010,
> arch/arm/mach-imx/pcm970-baseboard.c:185:	.dmacr		= 0x00020010,
> arch/arm/mach-imx/mach-mx25_3ds.c:173:	.dmacr		= 0x00020010,

The reference manual has this about the dmacr register:

The dynamic mode is recommend, and also the TM and HM reset value are
recommend in the dynamic mode. The same recommendation is for the
graphic DMA control.

So maybe we should ask whether the boards really have to change this
value or if the reset value is suitable for all.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From grant.likely at secretlab.ca  Mon Apr 15 15:50:30 2013
From: grant.likely at secretlab.ca (Grant Likely)
Date: Mon, 15 Apr 2013 20:50:30 +0100
Subject: [PATCH v3 1/6] drivers: phy: add generic PHY framework
In-Reply-To: <516BF1E2.3020104@ti.com>
References: <1363770725-13717-1-git-send-email-kishon@ti.com>
 <1363770725-13717-2-git-send-email-kishon@ti.com>
 <20130415113416.7C3943E0AA8@localhost> <516BF1E2.3020104@ti.com>
Message-ID: <20130415195030.9F7E93E0AA8@localhost>

On Mon, 15 Apr 2013 17:56:10 +0530, Kishon Vijay Abraham I <kishon at ti.com> wrote:
> Hi,
> 
> On Monday 15 April 2013 05:04 PM, Grant Likely wrote:
> > On Wed, 20 Mar 2013 14:42:00 +0530, Kishon Vijay Abraham I <kishon at ti.com> wrote:
> >> The PHY framework provides a set of APIs for the PHY drivers to
> >> create/destroy a PHY and APIs for the PHY users to obtain a reference to the
> >> PHY with or without using phandle. To obtain a reference to the PHY without
> >> using phandle, the platform specfic intialization code (say from board file)
> >> should have already called phy_bind with the binding information. The binding
> >> information consists of phy's device name, phy user device name and an index.
> >> The index is used when the same phy user binds to mulitple phys.
> >>
> >> PHY drivers should create the PHY by passing phy_descriptor that has
> >> describes the PHY (label, type etc..) and ops like init, exit, suspend, resume,
> >> poweron, shutdown.
> >>
> >> The documentation for the generic PHY framework is added in
> >> Documentation/phy.txt and the documentation for the sysfs entry is added
> >> in Documentation/ABI/testing/sysfs-class-phy.
> >>
> >> Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
> >
> > Hi Kishon,
> >
> > For review purposes, I'll skip most of the implementation and focus on
> > the data structures. I think you need to take another look at the
> > approach your using. The kernel already provides a lot of support for
> > implementing devices and binding them to drivers that you should be
> > able to use...
> >
> >
> > [...]
> >> +/**
> >> + * struct phy - represent the phy device
> >> + * @dev: phy device
> >> + * @label: label given to phy
> >> + * @type: specifies the phy type
> >> + * @of_node: device node of the phy
> >> + * @ops: function pointers for performing phy operations
> >> + */
> >> +struct phy {
> >> +	struct device		dev;
> >> +	const char		*label;
> >> +	int			type;
> >> +	struct bus_type		*bus;
> >> +	struct device_node	*of_node;
> >> +	struct phy_ops		*ops;
> >> +};
> >
> > Alright, so the core of the functionality is this 'struct phy' which
> > tracks all the instances of PHY devices. As I understand it each
> > physical phy will have a 'struct phy' instance tracking it. That makes
> > sense.
> >
> > struct phy embeds a struct device. Also good. The linux driver model
> > knows all about devices and how to handle them. However, most of the
> > rest of this structure looks to be reinventing stuff the driver model
> > already does.
> >
> > 'label' seems unnecessary. struct device embeds a struct kobject, which
> > means it has a name and shows up in sysfs. Is there a reason that the
> > device name cannot be used directly?
> 
> hmm.. the label name is supposed to be a simpler name than device name.
> Say for instance "omap-usb2.1.auto" device name can simply be 
> "omap-usb2-phy". Further the device name while using dt will have 
> register address in it. However it's used only for displaying the label 
> in sysfs entry (/sys/class/phy/<phy>/label).

I wouldn't go mucking with names in that way. Stick with one name and
drop the separate label. Otherwise you introduce addtional sources of
confusion.

> >
> > 'type' I just don't understand. I don't see any users of it in this
> > patch. I only see where it is set.
> 
> yeah. Was planning to remove this in my next version (btw the latest is 
> version 5).
> >
> > 'bus' absolutely should not be here. The bus type should be set in the
> > struct device by this subsystem when the device gets registered. There
> > is no reason to have a pointer to it here.
> 
> right. I had removed it in version 5 of this patch series.
> >
> > 'of_node' is already in struct device
> 
> I wasn't sure if we can manually assign the of_node of one device to 
> of_node of an another device. Here the of_node comes from _phy provider_.

There is no problem with multiple devices referencing the same node. The
only time it may cause problems is when two devices of the same bus type
are referencing the same of_node. In that situation the device will get
probed more than once. You're not in that situation.

> > Finally, it really doesn't look right for a device object to have an
> > 'ops' structure. The whole point of the driver model is that a struct
> > device doesn't encapsulate any behaviour. A device gets registers to a
> > bus type, and then the driver core will associate a struct device_driver
> 
> We have decided not to implement the PHY layer as a separate bus layer. 
> The PHY provider can be part of any other bus. Making the PHY layer as a 
> bus will make the PHY provider to be part of multiple buses which will 
> lead to bad design. All we are trying to do here is keep the pool of PHY 
> devices under PHY class in this layer and help any controller that wants 
> to use the PHY to get it.

If you're using a class, then you already have your list of registered
phy devices! :-) No need to create another global list that you need to
manage.

You really need to be careful here though. By lumping all the phy types
into a single pot your glossing over the fact that different subsystems
have phys that behave differently. It is just fine to have a framework
that works in lots of places, it's actively encouraged, but by putting
the struct device into struct phy, you're taping into a large amount of
assumptions that the linux kernel makes about what devices are. For
instance, it is generally assumed that a class contains a bunch of the
same devices; but in this framework it is explicitly not true.

I would also imagine that each of the subsystems will want to wrap the
struct phy with subsystem specific additions so it will be important to
ensure the correct type of device is always returned.

You'd be better off providing a set of utility functions that work for
all the types of phys, but have a separate instance for each one. For
example, you could have a separate class for each phy type, but all of
them use the same utility function.

> > to a device that it is able to drive, and the struct device_driver is
> > supposed to contain any ops structure used to control the device.
> >
> >> +
> >> +/**
> >> + * struct phy_bind - represent the binding for the phy
> >> + * @dev_name: the device name of the device that will bind to the phy
> >> + * @phy_dev_name: the device name of the phy
> >> + * @index: used if a single controller uses multiple phys
> >> + * @auto_bind: tells if the binding is done explicitly from board file or not
> >> + * @phy: reference to the phy
> >> + * @list: to maintain a linked list of the binding information
> >> + */
> >> +struct phy_bind {
> >> +	const char	*dev_name;
> >> +	const char	*phy_dev_name;
> >> +	int		index;
> >> +	int		auto_bind:1;
> >> +	struct phy	*phy;
> >> +	struct list_head list;
> >> +};
> >
> > How are PHYs attached to the system. Would the PHY be a direct child of
> > the host controller device, or would a PHY hang off another bus (like
> > i2c) for control? (this is how Ethernet phys work; they hang off the
> > MDIO bus, but may be attached to any Ethernet controller).
> 
> This layer does not have any restriction on how the PHY is attached to 
> the system. For all the sample cases (USB OTG controller in OMAP 
> platforms) that follows this patch, the PHY is attached to the platform 
> bus and the PHY provider is a platform driver. All this framework does 
> is maintain a list of PHY's added in the system and helps the controller 
> to find the appropriate PHY.

Okay, that's what I thought. A lot of systems end up looking this way.
So I would assume that for an i2c-controlled phy, and i2c driver would
bind against the device, and the probe hook would create and register a
phy device. That would make the sysfs tree look something like:

/sys/devices/.../i2c at 80000000/usbphy at 2/phy0

where, i2c at 80000000 is the i2c master, usbphy at 2 is what the phy's driver
binds against, and phy0 is created and registered by the driver of
usbphy at 2 at probe time. Correct?

> We are currently not looking at having Ethernet use this layer because 
> it itself has a comprehensive PHY layer and merging it with this will 
> take some effort. However other subsystems like USB, SATA, video etc.. 
> can make use of this.
> >
> > Since there is at most a 1:N relationship between host controllers and
> > PHYs, there shouldn't be any need for a separate structure to describe
> > binding. Put the inding data into the struct phy itself. Each host
> > controller can have a list of phys that it is bound to.
> 
> No. Having the host controller to have a list of phys wont be a good 
> idea IMHO. The host controller is just an IP and the PHY to which it 
> will be connected can vary from board to board, platform to platform. So 
> ideally this binding should come from platform initialization code/dt data.

That is not what I mean. I mean the host controller instance should
contain a list of all the PHYs that are attached to it. There should not
be a global list. That has nothing to do with where the data of binding
comes from.

g.


From jon-hunter at ti.com  Mon Apr 15 16:00:31 2013
From: jon-hunter at ti.com (Jon Hunter)
Date: Mon, 15 Apr 2013 15:00:31 -0500
Subject: [PATCH 3/5] gpio/omap: Add DT support to GPIO driver
In-Reply-To: <516C3076.3000107@wwwdotorg.org>
References: <1329321854-24490-1-git-send-email-b-cousson@ti.com>
 <512D3AB1.1080202@wwwdotorg.org> <512D3EC2.6050408@ti.com>
 <20130302200524.D230F3E1571@localhost> <51391F41.5000303@ti.com>
 <CAAwP0s1CFRO-rf==p5sYs1n0gigMif7wuT8Yv0N_iLUDMrtcOg@mail.gmail.com>
 <CACRpkdYHj-rEF3Rk_CWnmmMw_Amr7m8SgQ=-2zsDYuLeuu3azw@mail.gmail.com>
 <514C79E1.4090106@wwwdotorg.org> <514CE0AB.6060207@ti.com>
 <CACRpkdZmv-rAoKSQYpkHHSMzKJOn5TixVW_P3=m7ZNagBYCUPw@mail.gmail.com>
 <515319D5.20105@wwwdotorg.org>
 <CACRpkdYXVLgCz1Tyu-Ls2V2OTc4R3cGNJhfQJB6Hiz_K9dkZYQ@mail.gmail.com>
 <5155C902.7080207@wwwdotorg.org>
 <CACRpkdYbs4-uudpRUY8e+7icYYkZrfM0kReP3pLL5DMiURJ4dg@mail.gmail.com>
 <5165CB9D.1090202@wwwdotorg.org>
 <CACRpkdYirFNqmGhA4K9CL4ve4NYhs8Rd3SFt1iwW9vHBkrcz8g@mail.gmail.com>
 <51671D7B.5060303@wwwdotorg.org>
 <CACRpkdbf32Ef77GmXk9id9+RRjcDRTr7S+F4nznoeZU8y=BT_Q@mail.gmail.com>
 <51673D70.3010503@wwwdotorg.org>
 <CAAwP0s0e2x33jZQhFRY+Hoo61SFqYKRgWk=1mL2+DNxSDJHz+A@mail.gmail.com>
 <516C3076.3000107@wwwdotor! g.org>
Message-ID: <516C5C5F.4060106@ti.com>


On 04/15/2013 11:53 AM, Stephen Warren wrote:
> On 04/13/2013 07:35 PM, Javier Martinez Canillas wrote:
> ...
>> Is the following inlined patch [1] what you were thinking that would
>> be the right approach?
> ...
>> diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
> ...
>> +static int omap_gpio_irq_request(struct irq_data *d)
>> +{
>> +	struct gpio_bank *bank = irq_data_get_irq_chip_data(d);
>> +
>> +	return omap_gpio_request(&bank->chip, d->hwirq);
> 
> If you want the GPIO usage to be known to the GPIO subsystem, then
> wouldn't you call gpio_request() here rather than omap_gpio_request()?
> The above code will certainly do enough so that the OMAP GPIO HW is
> fully enabled as you need, but I thought the idea was to also prevent
> some other code successfully running gpio_request() on that same GPIO?

Also, although omap gpios default to being inputs, we should not assume
that. So may be you should call gpio_request_one() here passing as flags
GPIOF_IN to configure as an input.

Cheers
Jon


From olof at lixom.net  Mon Apr 15 16:18:35 2013
From: olof at lixom.net (Olof Johansson)
Date: Mon, 15 Apr 2013 13:18:35 -0700
Subject: [GIT PULL 2/3] ARM: davinci: SoC updates for v3.10 (part 2)
In-Reply-To: <1366046599-6590-2-git-send-email-nsekhar@ti.com>
References: <1366046599-6590-1-git-send-email-nsekhar@ti.com>
 <1366046599-6590-2-git-send-email-nsekhar@ti.com>
Message-ID: <20130415201835.GA24600@quad.lixom.net>

On Mon, Apr 15, 2013 at 10:53:18PM +0530, Sekhar Nori wrote:
> Hi Arnd, Olof,
> 
> Can you please the following SoC updates for DaVinci.
> The branch depends on (and merges) an immutable branch
> from Ohad adding DA8XX rempote proc driver.

Hi,

Where is this branch from? Git URL and branch name, please -- we prefer to pull
these in as separate branches under depends/* as well to document it.


-Olof



From tomasz.figa at gmail.com  Mon Apr 15 17:14:37 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Mon, 15 Apr 2013 23:14:37 +0200
Subject: [PATCH v5 0/6] Initial Device Tree support for S3C64xx
Message-ID: <1366060483-20342-1-git-send-email-tomasz.figa@gmail.com>

This series adds Device Tree support for Samsung S3C64xx SoC series.

It fixes several problems preventing from booting an S3C64xx-based system
using Device Tree, adds all the infrastructure for Device Tree-based board
support, including mach-s3c64xx-dt and dts include files for S3C64xx SoCs,
and basic device tree source for FriendlyARM Mini6410 board.

Current support is very limited and allows only basic bootup with UART and
SDHCI, but should be fine as a start and will be extended in future,
hopefully with help of S3C64xx board maintainers.

This series depends on my other series reworking samsung-time for
multiplatform:
[PATCH v5 00/14] ARM: samsung-time: Prepare for multiplatform support
http://thread.gmane.org/gmane.linux.kernel.samsung-soc/17864

Changes since v4:
 - Rebased onto current for-next branch of Kgene's tree
 - Added support for pinctrl (driver merged through pinctrl tree)
 - Added labels to all nodes that can be overridden from board dts
 - Modified board dts to use the &label syntax to reference device nodes

Changes since v3:
 - Rebased onto current for-next branch of Kgene's tree
 - Updated timer node for next version of samsung-time patches
 - Replaced local s3c64xx_dt_init_irq with irqchip_init

Changes since v2:
 - Updated timer node for next version of samsung-time patches

Changes since v1:
 - Dropped two VIC-related patches that are no longer necessary
 - Added Device Tree-based instantation of system timers
 - Corrected VIC interrupt specifiers
 - Adjusted CPU compatible values and dropped @id

Tomasz Figa (6):
  ARM: common: vic: Parse interrupt and resume masks from device tree
  ARM: s3c64xx: Skip legacy EINT setup if pinctrl-s3c64xx driver is
    present
  gpio: samsung: Skip legacy GPIO registration if pinctrl-s3c64xx is
    present
  ARM: s3c64xx: Add board file for boot using Device Tree
  ARM: dts: Add basic dts include files for Samsung S3C64xx SoCs
  ARM: dts: Add dts file for S3C6410-based Mini6410 board

 Documentation/devicetree/bindings/arm/vic.txt |   6 +
 arch/arm/boot/dts/Makefile                    |   1 +
 arch/arm/boot/dts/s3c6400.dtsi                |  33 ++
 arch/arm/boot/dts/s3c6410-mini6410.dts        | 168 +++++++
 arch/arm/boot/dts/s3c6410.dtsi                |  33 ++
 arch/arm/boot/dts/s3c64xx-pinctrl.dtsi        | 683 ++++++++++++++++++++++++++
 arch/arm/boot/dts/s3c64xx.dtsi                | 136 +++++
 arch/arm/mach-s3c64xx/Kconfig                 |  16 +
 arch/arm/mach-s3c64xx/Makefile                |   1 +
 arch/arm/mach-s3c64xx/common.c                |  20 +-
 arch/arm/mach-s3c64xx/mach-s3c64xx-dt.c       |  83 ++++
 drivers/gpio/gpio-samsung.c                   |   4 +-
 drivers/irqchip/irq-vic.c                     |   7 +-
 13 files changed, 1188 insertions(+), 3 deletions(-)
 create mode 100644 arch/arm/boot/dts/s3c6400.dtsi
 create mode 100644 arch/arm/boot/dts/s3c6410-mini6410.dts
 create mode 100644 arch/arm/boot/dts/s3c6410.dtsi
 create mode 100644 arch/arm/boot/dts/s3c64xx-pinctrl.dtsi
 create mode 100644 arch/arm/boot/dts/s3c64xx.dtsi
 create mode 100644 arch/arm/mach-s3c64xx/mach-s3c64xx-dt.c

-- 
1.8.1.5



From tomasz.figa at gmail.com  Mon Apr 15 17:14:38 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Mon, 15 Apr 2013 23:14:38 +0200
Subject: [PATCH v5 1/6] ARM: common: vic: Parse interrupt and resume masks
 from device tree
In-Reply-To: <1366060483-20342-1-git-send-email-tomasz.figa@gmail.com>
References: <1366060483-20342-1-git-send-email-tomasz.figa@gmail.com>
Message-ID: <1366060483-20342-2-git-send-email-tomasz.figa@gmail.com>

This patch extends vic_of_init to parse valid interrupt sources
and resume sources masks from device tree.

If mask values are not specified in device tree, all sources
are assumed to be valid, as before this patch.

Signed-off-by: Tomasz Figa <tomasz.figa at gmail.com>
---
 Documentation/devicetree/bindings/arm/vic.txt | 6 ++++++
 drivers/irqchip/irq-vic.c                     | 7 ++++++-
 2 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/arm/vic.txt b/Documentation/devicetree/bindings/arm/vic.txt
index 266716b..bb7137c 100644
--- a/Documentation/devicetree/bindings/arm/vic.txt
+++ b/Documentation/devicetree/bindings/arm/vic.txt
@@ -18,6 +18,9 @@ Required properties:
 Optional properties:
 
 - interrupts : Interrupt source for parent controllers if the VIC is nested.
+- interrupt-mask : Bit mask of valid interrupt sources (defaults to all valid)
+- wakeup-mask : Bit mask of interrupt sources that can wake up the system
+  (defaults to all allowed)
 
 Example:
 
@@ -26,4 +29,7 @@ Example:
 		interrupt-controller;
 		#interrupt-cells = <1>;
 		reg = <0x60000 0x1000>;
+
+		interrupt-mask = <0xffffff7f>;
+		wakeup-mask = <0x0000ff7f>;
 	};
diff --git a/drivers/irqchip/irq-vic.c b/drivers/irqchip/irq-vic.c
index 3cf97aa..61602df 100644
--- a/drivers/irqchip/irq-vic.c
+++ b/drivers/irqchip/irq-vic.c
@@ -468,6 +468,8 @@ void __init vic_init(void __iomem *base, unsigned int irq_start,
 int __init vic_of_init(struct device_node *node, struct device_node *parent)
 {
 	void __iomem *regs;
+	u32 interrupt_mask = ~0;
+	u32 wakeup_mask = ~0;
 
 	if (WARN(parent, "non-root VICs are not supported"))
 		return -EINVAL;
@@ -476,10 +478,13 @@ int __init vic_of_init(struct device_node *node, struct device_node *parent)
 	if (WARN_ON(!regs))
 		return -EIO;
 
+	of_property_read_u32(node, "interrupt-mask", &interrupt_mask);
+	of_property_read_u32(node, "wakeup-mask", &wakeup_mask);
+
 	/*
 	 * Passing 0 as first IRQ makes the simple domain allocate descriptors
 	 */
-	__vic_init(regs, 0, ~0, ~0, node);
+	__vic_init(regs, 0, interrupt_mask, wakeup_mask, node);
 
 	return 0;
 }
-- 
1.8.1.5



From tomasz.figa at gmail.com  Mon Apr 15 17:14:39 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Mon, 15 Apr 2013 23:14:39 +0200
Subject: [PATCH v5 2/6] ARM: s3c64xx: Skip legacy EINT setup if
 pinctrl-s3c64xx driver is present
In-Reply-To: <1366060483-20342-1-git-send-email-tomasz.figa@gmail.com>
References: <1366060483-20342-1-git-send-email-tomasz.figa@gmail.com>
Message-ID: <1366060483-20342-3-git-send-email-tomasz.figa@gmail.com>

The new pinctrl-s3c64xx is responsible for EINT handling on DT-enabled
platforms.

Signed-off-by: Tomasz Figa <tomasz.figa at gmail.com>
---
 arch/arm/mach-s3c64xx/common.c | 20 +++++++++++++++++++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-s3c64xx/common.c b/arch/arm/mach-s3c64xx/common.c
index e79ca92..866be9e 100644
--- a/arch/arm/mach-s3c64xx/common.c
+++ b/arch/arm/mach-s3c64xx/common.c
@@ -365,7 +365,25 @@ static void s3c_irq_demux_eint20_27(unsigned int irq, struct irq_desc *desc)
 static int __init s3c64xx_init_irq_eint(void)
 {
 	int irq;
-
+#if defined(CONFIG_PINCTRL_S3C64XX)
+	/*
+	* This gpio driver includes support for device tree support and there
+	* are platforms using it. In order to maintain compatibility with those
+	* platforms, and to allow non-dt Exynos4210 platforms to use this
+	* gpiolib support, a check is added to find out if there is a active
+	* pin-controller driver support available. If it is available, this
+	* gpiolib support is ignored and the gpiolib support available in
+	* pin-controller driver is used. This is a temporary check and will go
+	* away when all of the Exynos4210 platforms have switched to using
+	* device tree and the pin-ctrl driver.
+	*/
+	struct device_node *pctrl_np;
+
+	pctrl_np = of_find_compatible_node(NULL, NULL,
+						"samsung,s3c64xx-pinctrl");
+	if (pctrl_np && of_device_is_available(pctrl_np))
+		return -ENODEV;
+#endif
 	for (irq = IRQ_EINT(0); irq <= IRQ_EINT(27); irq++) {
 		irq_set_chip_and_handler(irq, &s3c_irq_eint, handle_level_irq);
 		irq_set_chip_data(irq, (void *)eint_irq_to_bit(irq));
-- 
1.8.1.5



From tomasz.figa at gmail.com  Mon Apr 15 17:14:40 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Mon, 15 Apr 2013 23:14:40 +0200
Subject: [PATCH v5 3/6] gpio: samsung: Skip legacy GPIO registration if
 pinctrl-s3c64xx is present
In-Reply-To: <1366060483-20342-1-git-send-email-tomasz.figa@gmail.com>
References: <1366060483-20342-1-git-send-email-tomasz.figa@gmail.com>
Message-ID: <1366060483-20342-4-git-send-email-tomasz.figa@gmail.com>

The new driver handles GPIO on DT-enabled platforms.

Signed-off-by: Tomasz Figa <tomasz.figa at gmail.com>
---
 drivers/gpio/gpio-samsung.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpio/gpio-samsung.c b/drivers/gpio/gpio-samsung.c
index 99e0fa4..dc06a6f 100644
--- a/drivers/gpio/gpio-samsung.c
+++ b/drivers/gpio/gpio-samsung.c
@@ -3012,7 +3012,7 @@ static __init int samsung_gpiolib_init(void)
 	int i, nr_chips;
 	int group = 0;
 
-#if defined(CONFIG_PINCTRL_EXYNOS) || defined(CONFIG_PINCTRL_EXYNOS5440)
+#if defined(CONFIG_PINCTRL_SAMSUNG) || defined(CONFIG_PINCTRL_EXYNOS5440)
 	/*
 	* This gpio driver includes support for device tree support and there
 	* are platforms using it. In order to maintain compatibility with those
@@ -3026,10 +3026,12 @@ static __init int samsung_gpiolib_init(void)
 	*/
 	struct device_node *pctrl_np;
 	static const struct of_device_id exynos_pinctrl_ids[] = {
+		{ .compatible = "samsung,s3c64xx-pinctrl", },
 		{ .compatible = "samsung,exynos4210-pinctrl", },
 		{ .compatible = "samsung,exynos4x12-pinctrl", },
 		{ .compatible = "samsung,exynos5250-pinctrl", },
 		{ .compatible = "samsung,exynos5440-pinctrl", },
+		{ },
 	};
 	for_each_matching_node(pctrl_np, exynos_pinctrl_ids)
 		if (pctrl_np && of_device_is_available(pctrl_np))
-- 
1.8.1.5



From tomasz.figa at gmail.com  Mon Apr 15 17:14:41 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Mon, 15 Apr 2013 23:14:41 +0200
Subject: [PATCH v5 4/6] ARM: s3c64xx: Add board file for boot using Device Tree
In-Reply-To: <1366060483-20342-1-git-send-email-tomasz.figa@gmail.com>
References: <1366060483-20342-1-git-send-email-tomasz.figa@gmail.com>
Message-ID: <1366060483-20342-5-git-send-email-tomasz.figa@gmail.com>

This patch adds board file that will be used to boot S3C64xx-based boards
using Device Tree.

Signed-off-by: Tomasz Figa <tomasz.figa at gmail.com>
---
 arch/arm/mach-s3c64xx/Kconfig           | 16 +++++++
 arch/arm/mach-s3c64xx/Makefile          |  1 +
 arch/arm/mach-s3c64xx/mach-s3c64xx-dt.c | 83 +++++++++++++++++++++++++++++++++
 3 files changed, 100 insertions(+)
 create mode 100644 arch/arm/mach-s3c64xx/mach-s3c64xx-dt.c

diff --git a/arch/arm/mach-s3c64xx/Kconfig b/arch/arm/mach-s3c64xx/Kconfig
index 283cb77..184d53c 100644
--- a/arch/arm/mach-s3c64xx/Kconfig
+++ b/arch/arm/mach-s3c64xx/Kconfig
@@ -311,3 +311,19 @@ config MACH_WLF_CRAGG_6410
 	select SAMSUNG_GPIO_EXTRA128
 	help
 	  Machine support for the Wolfson Cragganmore S3C6410 variant.
+
+config MACH_S3C64XX_DT
+	bool "Samsung S3C6400/S3C6410 machine using Device Tree"
+	select CLKSRC_OF
+	select CPU_S3C6400
+	select CPU_S3C6410
+	select PINCTRL
+	select PINCTRL_S3C64XX
+	select USE_OF
+	help
+	  Machine support for Samsung S3C6400/S3C6410 machines with Device Tree
+	  enabled.
+	  Select this if a fdt blob is available for your S3C64XX SoC based
+	  board.
+	  Note: This is under development and not all peripherals can be
+	  supported with this machine file.
diff --git a/arch/arm/mach-s3c64xx/Makefile b/arch/arm/mach-s3c64xx/Makefile
index 31d0c91..5e5eb4b 100644
--- a/arch/arm/mach-s3c64xx/Makefile
+++ b/arch/arm/mach-s3c64xx/Makefile
@@ -57,3 +57,4 @@ obj-$(CONFIG_MACH_SMARTQ7)		+= mach-smartq7.o
 obj-$(CONFIG_MACH_SMDK6400)		+= mach-smdk6400.o
 obj-$(CONFIG_MACH_SMDK6410)		+= mach-smdk6410.o
 obj-$(CONFIG_MACH_WLF_CRAGG_6410)	+= mach-crag6410.o mach-crag6410-module.o
+obj-$(CONFIG_MACH_S3C64XX_DT)		+= mach-s3c64xx-dt.o
diff --git a/arch/arm/mach-s3c64xx/mach-s3c64xx-dt.c b/arch/arm/mach-s3c64xx/mach-s3c64xx-dt.c
new file mode 100644
index 0000000..10b76cc
--- /dev/null
+++ b/arch/arm/mach-s3c64xx/mach-s3c64xx-dt.c
@@ -0,0 +1,83 @@
+/*
+ * Samsung's S3C64XX flattened device tree enabled machine
+ *
+ * Copyright (c) 2013 Tomasz Figa <tomasz.figa at gmail.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/clocksource.h>
+#include <linux/irqchip.h>
+#include <linux/of_irq.h>
+#include <linux/of_platform.h>
+#include <linux/serial_core.h>
+
+#include <asm/mach/arch.h>
+#include <mach/map.h>
+
+#include <plat/cpu.h>
+#include <plat/regs-serial.h>
+
+#include "common.h"
+
+/*
+ * The following lookup table is used to override device names when devices
+ * are registered from device tree. This is temporarily added to enable
+ * device tree support addition for the S3C64xx architecture.
+ *
+ * For drivers that require platform data to be provided from the machine
+ * file, a platform data pointer can also be supplied along with the
+ * devices names. Usually, the platform data elements that cannot be parsed
+ * from the device tree by the drivers (example: function pointers) are
+ * supplied. But it should be noted that this is a temporary mechanism and
+ * at some point, the drivers should be capable of parsing all the platform
+ * data from the device tree.
+ */
+static const struct of_dev_auxdata s3c64xx_auxdata_lookup[] __initconst = {
+	OF_DEV_AUXDATA("samsung,s3c6400-uart", 0x7f005000,
+				"s3c6400-uart.0", NULL),
+	OF_DEV_AUXDATA("samsung,s3c6400-uart", 0x7f005400,
+				"s3c6400-uart.1", NULL),
+	OF_DEV_AUXDATA("samsung,s3c6400-uart", 0x7f005800,
+				"s3c6400-uart.2", NULL),
+	OF_DEV_AUXDATA("samsung,s3c6400-uart", 0x7f005c00,
+				"s3c6400-uart.3", NULL),
+	OF_DEV_AUXDATA("samsung,s3c6410-sdhci", 0x7c200000,
+				"s3c-sdhci.0", NULL),
+	OF_DEV_AUXDATA("samsung,s3c6410-sdhci", 0x7c300000,
+				"s3c-sdhci.1", NULL),
+	OF_DEV_AUXDATA("samsung,s3c6410-sdhci", 0x7c400000,
+				"s3c-sdhci.2", NULL),
+	{},
+};
+
+static void __init s3c64xx_dt_map_io(void)
+{
+	s3c64xx_init_io(NULL, 0);
+	s3c24xx_init_clocks(12000000);
+}
+
+static void __init s3c64xx_dt_machine_init(void)
+{
+	of_platform_populate(NULL, of_default_bus_match_table,
+						s3c64xx_auxdata_lookup, NULL);
+}
+
+static char const *s3c64xx_dt_compat[] __initdata = {
+	"samsung,s3c6400",
+	"samsung,s3c6410",
+	NULL
+};
+
+DT_MACHINE_START(S3C6400_DT, "Samsung S3C64xx (Flattened Device Tree)")
+	/* Maintainer: Tomasz Figa <tomasz.figa at gmail.com> */
+	.init_irq	= irqchip_init,
+	.map_io		= s3c64xx_dt_map_io,
+	.init_machine	= s3c64xx_dt_machine_init,
+	.init_late	= s3c64xx_init_late,
+	.init_time	= clocksource_of_init,
+	.dt_compat	= s3c64xx_dt_compat,
+	.restart        = s3c64xx_restart,
+MACHINE_END
-- 
1.8.1.5



From tomasz.figa at gmail.com  Mon Apr 15 17:14:43 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Mon, 15 Apr 2013 23:14:43 +0200
Subject: [PATCH v5 6/6] ARM: dts: Add dts file for S3C6410-based Mini6410 board
In-Reply-To: <1366060483-20342-1-git-send-email-tomasz.figa@gmail.com>
References: <1366060483-20342-1-git-send-email-tomasz.figa@gmail.com>
Message-ID: <1366060483-20342-7-git-send-email-tomasz.figa@gmail.com>

This patch adds basic device tree sources for FriendlyARM Mini6410 board
based on Samsung S3C6410 SoC.

Signed-off-by: Tomasz Figa <tomasz.figa at gmail.com>
---
 arch/arm/boot/dts/Makefile             |   1 +
 arch/arm/boot/dts/s3c6410-mini6410.dts | 168 +++++++++++++++++++++++++++++++++
 2 files changed, 169 insertions(+)
 create mode 100644 arch/arm/boot/dts/s3c6410-mini6410.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 11fef62..5885c37 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -138,6 +138,7 @@ dtb-$(CONFIG_ARCH_U8500) += snowball.dtb \
 	hrefprev60.dtb \
 	hrefv60plus.dtb \
 	ccu9540.dtb
+dtb-$(CONFIG_ARCH_S3C64XX) += s3c6410-mini6410.dtb
 dtb-$(CONFIG_ARCH_SHMOBILE) += emev2-kzm9d.dtb \
 	r8a7740-armadillo800eva.dtb \
 	sh73a0-kzm9g.dtb \
diff --git a/arch/arm/boot/dts/s3c6410-mini6410.dts b/arch/arm/boot/dts/s3c6410-mini6410.dts
new file mode 100644
index 0000000..679b1bb
--- /dev/null
+++ b/arch/arm/boot/dts/s3c6410-mini6410.dts
@@ -0,0 +1,168 @@
+/*
+ * Samsung's S3C6410 based Mini6410 board device tree source
+ *
+ * Copyright (c) 2013 Tomasz Figa <tomasz.figa at gmail.com>
+ *
+ * Device tree source file for FriendlyARM Mini6410 board which is based on
+ * Samsung's S3C6410 SoC.
+ *
+ * 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.
+*/
+
+/dts-v1/;
+/include/ "s3c6410.dtsi"
+
+/ {
+	model = "FriendlyARM Mini6410 board based on S3C6410";
+	compatible = "friendlyarm,mini6410", "samsung,s3c6410";
+
+	memory {
+		reg = <0x50000000 0x10000000>;
+	};
+
+	chosen {
+		bootargs = "console=ttySAC0,115200n8 earlyprintk rootwait root=/dev/mmcblk0p1";
+	};
+
+	gpio-keys {
+		compatible = "gpio-keys";
+		pinctrl-names = "default";
+		pinctrl-0 = <&gpio_keys>;
+		autorepeat;
+
+		button-k1 {
+			label = "K1";
+			gpios = <&gpn 0 1>;
+			linux,code = <2>;
+			debounce-interval = <20>;
+		};
+
+		button-k2 {
+			label = "K2";
+			gpios = <&gpn 1 1>;
+			linux,code = <3>;
+			debounce-interval = <20>;
+		};
+
+		button-k3 {
+			label = "K3";
+			gpios = <&gpn 2 1>;
+			linux,code = <4>;
+			debounce-interval = <20>;
+		};
+
+		button-k4 {
+			label = "K4";
+			gpios = <&gpn 3 1>;
+			linux,code = <5>;
+			debounce-interval = <20>;
+		};
+
+		button-k5 {
+			label = "K5";
+			gpios = <&gpn 4 1>;
+			linux,code = <6>;
+			debounce-interval = <20>;
+		};
+
+		button-k6 {
+			label = "K6";
+			gpios = <&gpn 5 1>;
+			linux,code = <7>;
+			debounce-interval = <20>;
+		};
+
+		button-k7 {
+			label = "K7";
+			gpios = <&gpl 11 1>;
+			linux,code = <8>;
+			debounce-interval = <20>;
+		};
+
+		button-k8 {
+			label = "K8";
+			gpios = <&gpl 12 1>;
+			linux,code = <9>;
+			debounce-interval = <20>;
+		};
+	};
+
+	leds {
+		compatible = "gpio-leds";
+		pinctrl-names = "default";
+		pinctrl-0 = <&gpio_leds>;
+
+		led-1 {
+			label = "LED1";
+			gpios = <&gpk 4 1>;
+			linux,default-trigger = "heartbeat";
+		};
+
+		led-2 {
+			label = "LED2";
+			gpios = <&gpk 5 1>;
+			linux,default-trigger = "mmc0";
+		};
+
+		led-3 {
+			label = "LED3";
+			gpios = <&gpk 6 1>;
+		};
+
+		led-4 {
+			label = "LED4";
+			gpios = <&gpk 7 1>;
+		};
+	};
+};
+
+&pinctrl0 {
+	gpio_leds: gpio-leds {
+		samsung,pins = "gpk-4", "gpk-5", "gpk-6", "gpk-7";
+		samsung,pin-function = <1>;
+		samsung,pin-pud = <0>;
+	};
+
+	gpio_keys: gpio-keys {
+		samsung,pins = "gpn-0", "gpn-1", "gpn-2", "gpn-3",
+				"gpn-4", "gpn-5", "gpl-11", "gpl-12";
+		samsung,pin-pud = <0>;
+	};
+};
+
+&pwm {
+	status = "okay";
+};
+
+&uart0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart0_data>;
+	status = "okay";
+};
+
+&uart1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart1_data>, <&uart1_fctl>;
+	status = "okay";
+};
+
+&uart2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart2_data>;
+	status = "okay";
+};
+
+&uart3 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart3_data>;
+	status = "okay";
+};
+
+&sdhci0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&sd0_clk>, <&sd0_cmd>, <&sd0_cd>, <&sd0_bus4>;
+	bus-width = <4>;
+	status = "okay";
+};
-- 
1.8.1.5



From tomasz.figa at gmail.com  Mon Apr 15 17:14:42 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Mon, 15 Apr 2013 23:14:42 +0200
Subject: [PATCH v5 5/6] ARM: dts: Add basic dts include files for Samsung
 S3C64xx SoCs
In-Reply-To: <1366060483-20342-1-git-send-email-tomasz.figa@gmail.com>
References: <1366060483-20342-1-git-send-email-tomasz.figa@gmail.com>
Message-ID: <1366060483-20342-6-git-send-email-tomasz.figa@gmail.com>

This patch adds basic device tree definitions for Samsung S3C64xx SoCs.

Since all the SoCs in the series are very similar, the files are created
hierarchically - one file for the whole series and then separate files
for particular SoCs including the common one.

Signed-off-by: Tomasz Figa <tomasz.figa at gmail.com>
---
 arch/arm/boot/dts/s3c6400.dtsi         |  33 ++
 arch/arm/boot/dts/s3c6410.dtsi         |  33 ++
 arch/arm/boot/dts/s3c64xx-pinctrl.dtsi | 683 +++++++++++++++++++++++++++++++++
 arch/arm/boot/dts/s3c64xx.dtsi         | 136 +++++++
 4 files changed, 885 insertions(+)
 create mode 100644 arch/arm/boot/dts/s3c6400.dtsi
 create mode 100644 arch/arm/boot/dts/s3c6410.dtsi
 create mode 100644 arch/arm/boot/dts/s3c64xx-pinctrl.dtsi
 create mode 100644 arch/arm/boot/dts/s3c64xx.dtsi

diff --git a/arch/arm/boot/dts/s3c6400.dtsi b/arch/arm/boot/dts/s3c6400.dtsi
new file mode 100644
index 0000000..76106b8
--- /dev/null
+++ b/arch/arm/boot/dts/s3c6400.dtsi
@@ -0,0 +1,33 @@
+/*
+ * Samsung's S3C6400 SoC device tree source
+ *
+ * Copyright (c) 2013 Tomasz Figa <tomasz.figa at gmail.com>
+ *
+ * Samsung's S3C6400 SoC device nodes are listed in this file. S3C6400
+ * based board files can include this file and provide values for board specfic
+ * bindings.
+ *
+ * Note: This file does not include device nodes for all the controllers in
+ * S3C6400 SoC. As device tree coverage for S3C6400 increases, additional
+ * nodes can be added to this file.
+ *
+ * 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/ "s3c64xx.dtsi"
+
+/ {
+	compatible = "samsung,s3c6400";
+
+	vic0: interrupt-controller at 71200000 {
+		interrupt-mask = <0xfffffe1f>;
+		wakeup-mask = <0x00200004>;
+	};
+
+	vic1: interrupt-controller at 71300000 {
+		interrupt-mask = <0xffffffff>;
+		wakeup-mask = <0x53020000>;
+	};
+};
diff --git a/arch/arm/boot/dts/s3c6410.dtsi b/arch/arm/boot/dts/s3c6410.dtsi
new file mode 100644
index 0000000..4a74df9
--- /dev/null
+++ b/arch/arm/boot/dts/s3c6410.dtsi
@@ -0,0 +1,33 @@
+/*
+ * Samsung's S3C6410 SoC device tree source
+ *
+ * Copyright (c) 2013 Tomasz Figa <tomasz.figa at gmail.com>
+ *
+ * Samsung's S3C6410 SoC device nodes are listed in this file. S3C6410
+ * based board files can include this file and provide values for board specfic
+ * bindings.
+ *
+ * Note: This file does not include device nodes for all the controllers in
+ * S3C6410 SoC. As device tree coverage for S3C6410 increases, additional
+ * nodes can be added to this file.
+ *
+ * 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/ "s3c64xx.dtsi"
+
+/ {
+	compatible = "samsung,s3c6410";
+
+	vic0: interrupt-controller at 71200000 {
+		interrupt-mask = <0xffffff7f>;
+		wakeup-mask = <0x00200004>;
+	};
+
+	vic1: interrupt-controller at 71300000 {
+		interrupt-mask = <0xffffffff>;
+		wakeup-mask = <0x53020000>;
+	};
+};
diff --git a/arch/arm/boot/dts/s3c64xx-pinctrl.dtsi b/arch/arm/boot/dts/s3c64xx-pinctrl.dtsi
new file mode 100644
index 0000000..738017f
--- /dev/null
+++ b/arch/arm/boot/dts/s3c64xx-pinctrl.dtsi
@@ -0,0 +1,683 @@
+/*
+ * Samsung's S3C64xx SoC series common device tree source
+ * - pin control-related definitions
+ *
+ * Copyright (c) 2013 Tomasz Figa <tomasz.figa at gmail.com>
+ *
+ * Samsung's S3C64xx SoCs pin banks, pin-mux and pin-config options are
+ * listed as device tree nodes in this file.
+ *
+ * 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.
+ */
+
+&pinctrl0 {
+	/*
+	 * Pin banks
+	 */
+
+	gpa: gpa {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpb: gpb {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpc: gpc {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpd: gpd {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpe: gpe {
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
+	gpf: gpf {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpg: gpg {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gph: gph {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpi: gpi {
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
+	gpj: gpj {
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
+	gpk: gpk {
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
+	gpl: gpl {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpm: gpm {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpn: gpn {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpo: gpo {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp: gpp {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpq: gpq {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	/*
+	 * Pin groups
+	 */
+
+	uart0_data: uart0-data {
+		samsung,pins = "gpa-0", "gpa-1";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <0>;
+	};
+
+	uart0_fctl: uart0-fctl {
+		samsung,pins = "gpa-2", "gpa-3";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <0>;
+	};
+
+	uart1_data: uart1-data {
+		samsung,pins = "gpa-4", "gpa-5";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <0>;
+	};
+
+	uart1_fctl: uart1-fctl {
+		samsung,pins = "gpa-6", "gpa-7";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <0>;
+	};
+
+	uart2_data: uart2-data {
+		samsung,pins = "gpb-0", "gpb-1";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <0>;
+	};
+
+	uart3_data: uart3-data {
+		samsung,pins = "gpb-2", "gpb-3";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <0>;
+	};
+
+	ext_dma_0: ext-dma-0 {
+		samsung,pins = "gpb-0", "gpb-1";
+		samsung,pin-function = <3>;
+		samsung,pid-pud = <0>;
+	};
+
+	ext_dma_1: ext-dma-1 {
+		samsung,pins = "gpb-2", "gpb-3";
+		samsung,pin-function = <4>;
+		samsung,pid-pud = <0>;
+	};
+
+	irda_data_0: irda-data-0 {
+		samsung,pins = "gpb-0", "gpb-1";
+		samsung,pin-function = <4>;
+		samsung,pid-pud = <0>;
+	};
+
+	irda_data_1: irda-data-1 {
+		samsung,pins = "gpb-2", "gpb-3";
+		samsung,pin-function = <3>;
+		samsung,pid-pud = <0>;
+	};
+
+	irda_sdbw: irda-sdbw {
+		samsung,pins = "gpb-4";
+		samsung,pin-function = <2>;
+		samsung,pid-pud = <0>;
+	};
+
+	i2c0_bus: i2c0-bus {
+		samsung,pins = "gpb-5", "gpb-6";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <2>;
+	};
+
+	i2c1_bus: i2c1-bus {
+		/* S3C6410-only */
+		samsung,pins = "gpb-2", "gpb-3";
+		samsung,pin-function = <6>;
+		samsung,pin-pud = <2>;
+	};
+
+	spi0_bus: spi0-bus {
+		samsung,pins = "gpc-0", "gpc-1", "gpc-2";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <2>;
+	};
+
+	spi0_cs: spi0-cs {
+		samsung,pins = "gpc-3";
+		samsung,pin-function = <2>;
+		samsung,pid-pud = <0>;
+	};
+
+	spi1_bus: spi1-bus {
+		samsung,pins = "gpc-4", "gpc-5", "gpc-6";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <2>;
+	};
+
+	spi1_cs: spi1-cs {
+		samsung,pins = "gpc-7";
+		samsung,pin-function = <2>;
+		samsung,pid-pud = <0>;
+	};
+
+	sd0_cmd: sd0-cmd {
+		samsung,pins = "gpg-1";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <0>;
+	};
+
+	sd0_clk: sd0-clk {
+		samsung,pins = "gpg-0";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <0>;
+	};
+
+	sd0_bus1: sd0-bus1 {
+		samsung,pins = "gpg-2";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <0>;
+	};
+
+	sd0_bus4: sd0-bus4 {
+		samsung,pins = "gpg-2", "gpg-3", "gpg-4", "gpg-5";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <0>;
+	};
+
+	sd0_cd: sd0-cd {
+		samsung,pins = "gpg-6";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <2>;
+	};
+
+	sd1_cmd: sd1-cmd {
+		samsung,pins = "gph-1";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <0>;
+	};
+
+	sd1_clk: sd1-clk {
+		samsung,pins = "gph-0";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <0>;
+	};
+
+	sd1_bus1: sd1-bus1 {
+		samsung,pins = "gph-2";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <0>;
+	};
+
+	sd1_bus4: sd1-bus4 {
+		samsung,pins = "gph-2", "gph-3", "gph-4", "gph-5";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <0>;
+	};
+
+	sd1_bus8: sd1-bus8 {
+		samsung,pins = "gph-2", "gph-3", "gph-4", "gph-5",
+				"gph-6", "gph-7", "gph-8", "gph-9";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <0>;
+	};
+
+	sd1_cd: sd1-cd {
+		samsung,pins = "gpg-6";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <2>;
+	};
+
+	sd2_cmd: sd2-cmd {
+		samsung,pins = "gpc-4";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+	};
+
+	sd2_clk: sd2-clk {
+		samsung,pins = "gpc-5";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+	};
+
+	sd2_bus1: sd2-bus1 {
+		samsung,pins = "gph-6";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+	};
+
+	sd2_bus4: sd2-bus4 {
+		samsung,pins = "gph-6", "gph-7", "gph-8", "gph-9";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+	};
+
+	i2s0_bus: i2s0-bus {
+		samsung,pins = "gpd-0", "gpd-2", "gpd-3", "gpd-4";
+		samsung,pin-function = <3>;
+		samsung,pid-pud = <0>;
+	};
+
+	i2s0_cdclk: i2s0-cdclk {
+		samsung,pins = "gpd-1";
+		samsung,pin-function = <3>;
+		samsung,pid-pud = <0>;
+	};
+
+	i2s1_bus: i2s1-bus {
+		samsung,pins = "gpe-0", "gpe-2", "gpe-3", "gpe-4";
+		samsung,pin-function = <3>;
+		samsung,pid-pud = <0>;
+	};
+
+	i2s1_cdclk: i2s1-cdclk {
+		samsung,pins = "gpe-1";
+		samsung,pin-function = <3>;
+		samsung,pid-pud = <0>;
+	};
+
+	i2s2_bus: i2s2-bus {
+		/* S3C6410-only */
+		samsung,pins = "gpc-4", "gpc-5", "gpc-6", "gph-6",
+				"gph-8", "gph-9";
+		samsung,pin-function = <5>;
+		samsung,pid-pud = <0>;
+	};
+
+	i2s2_cdclk: i2s2-cdclk {
+		/* S3C6410-only */
+		samsung,pins = "gph-7";
+		samsung,pin-function = <5>;
+		samsung,pid-pud = <0>;
+	};
+
+	pcm0_bus: pcm0-bus {
+		samsung,pins = "gpd-0", "gpd-2", "gpd-3", "gpd-4";
+		samsung,pin-function = <2>;
+		samsung,pid-pud = <0>;
+	};
+
+	pcm0_extclk: pcm0-extclk {
+		samsung,pins = "gpd-1";
+		samsung,pin-function = <2>;
+		samsung,pid-pud = <0>;
+	};
+
+	pcm1_bus: pcm1-bus {
+		samsung,pins = "gpe-0", "gpe-2", "gpe-3", "gpe-4";
+		samsung,pin-function = <2>;
+		samsung,pid-pud = <0>;
+	};
+
+	pcm1_extclk: pcm1-extclk {
+		samsung,pins = "gpe-1";
+		samsung,pin-function = <2>;
+		samsung,pid-pud = <0>;
+	};
+
+	ac97_bus_0: ac97-bus-0 {
+		samsung,pins = "gpd-0", "gpd-1", "gpd-2", "gpd-3", "gpd-4";
+		samsung,pin-function = <4>;
+		samsung,pid-pud = <0>;
+	};
+
+	ac97_bus_1: ac97-bus-1 {
+		samsung,pins = "gpe-0", "gpe-1", "gpe-2", "gpe-3", "gpe-4";
+		samsung,pin-function = <4>;
+		samsung,pid-pud = <0>;
+	};
+
+	cam_port: cam-port {
+		samsung,pins = "gpf-0", "gpf-1", "gpf-2", "gpf-4",
+				"gpf-5", "gpf-6", "gpf-7", "gpf-8",
+				"gpf-9", "gpf-10", "gpf-11", "gpf-12";
+		samsung,pin-function = <2>;
+		samsung,pid-pud = <0>;
+	};
+
+	cam_rst: cam-rst {
+		samsung,pins = "gpf-3";
+		samsung,pin-function = <2>;
+		samsung,pid-pud = <0>;
+	};
+
+	cam_field: cam-field {
+		/* S3C6410-only */
+		samsung,pins = "gpb-4";
+		samsung,pin-function = <3>;
+		samsung,pid-pud = <0>;
+	};
+
+	pwm_extclk: pwm-extclk {
+		samsung,pins = "gpf-13";
+		samsung,pin-function = <2>;
+		samsung,pid-pud = <0>;
+	};
+
+	pwm0_out: pwm0-out {
+		samsung,pins = "gpf-14";
+		samsung,pin-function = <2>;
+		samsung,pid-pud = <0>;
+	};
+
+	pwm1_out: pwm1-out {
+		samsung,pins = "gpf-15";
+		samsung,pin-function = <2>;
+		samsung,pid-pud = <0>;
+	};
+
+	clkout0: clkout-0 {
+		samsung,pins = "gpf-14";
+		samsung,pin-function = <3>;
+		samsung,pid-pud = <0>;
+	};
+
+	keypad_col0_0: keypad-col0-0 {
+		samsung,pins = "gph-0";
+		samsung,pin-function = <4>;
+		samsung,pin-pud = <0>;
+	};
+
+	keypad_col1_0: keypad-col1-0 {
+		samsung,pins = "gph-1";
+		samsung,pin-function = <4>;
+		samsung,pin-pud = <0>;
+	};
+
+	keypad_col2_0: keypad-col2-0 {
+		samsung,pins = "gph-2";
+		samsung,pin-function = <4>;
+		samsung,pin-pud = <0>;
+	};
+
+	keypad_col3_0: keypad-col3-0 {
+		samsung,pins = "gph-3";
+		samsung,pin-function = <4>;
+		samsung,pin-pud = <0>;
+	};
+
+	keypad_col4_0: keypad-col4-0 {
+		samsung,pins = "gph-4";
+		samsung,pin-function = <4>;
+		samsung,pin-pud = <0>;
+	};
+
+	keypad_col5_0: keypad-col5-0 {
+		samsung,pins = "gph-5";
+		samsung,pin-function = <4>;
+		samsung,pin-pud = <0>;
+	};
+
+	keypad_col6_0: keypad-col6-0 {
+		samsung,pins = "gph-6";
+		samsung,pin-function = <4>;
+		samsung,pin-pud = <0>;
+	};
+
+	keypad_col7_0: keypad-col7-0 {
+		samsung,pins = "gph-7";
+		samsung,pin-function = <4>;
+		samsung,pin-pud = <0>;
+	};
+
+	keypad_col0_1: keypad-col0-1 {
+		samsung,pins = "gpl-0";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+	};
+
+	keypad_col1_1: keypad-col1-1 {
+		samsung,pins = "gpl-1";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+	};
+
+	keypad_col2_1: keypad-col2-1 {
+		samsung,pins = "gpl-2";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+	};
+
+	keypad_col3_1: keypad-col3-1 {
+		samsung,pins = "gpl-3";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+	};
+
+	keypad_col4_1: keypad-col4-1 {
+		samsung,pins = "gpl-4";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+	};
+
+	keypad_col5_1: keypad-col5-1 {
+		samsung,pins = "gpl-5";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+	};
+
+	keypad_col6_1: keypad-col6-1 {
+		samsung,pins = "gpl-6";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+	};
+
+	keypad_col7_1: keypad-col7-1 {
+		samsung,pins = "gpl-7";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+	};
+
+	keypad_row0_0: keypad-row0-0 {
+		samsung,pins = "gpk-8";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+	};
+
+	keypad_row1_0: keypad-row1-0 {
+		samsung,pins = "gpk-9";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+	};
+
+	keypad_row2_0: keypad-row2-0 {
+		samsung,pins = "gpk-10";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+	};
+
+	keypad_row3_0: keypad-row3-0 {
+		samsung,pins = "gpk-11";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+	};
+
+	keypad_row4_0: keypad-row4-0 {
+		samsung,pins = "gpk-12";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+	};
+
+	keypad_row5_0: keypad-row5-0 {
+		samsung,pins = "gpk-13";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+	};
+
+	keypad_row6_0: keypad-row6-0 {
+		samsung,pins = "gpk-14";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+	};
+
+	keypad_row7_0: keypad-row7-0 {
+		samsung,pins = "gpk-15";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+	};
+
+	keypad_row0_1: keypad-row0-1 {
+		samsung,pins = "gpn-0";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+	};
+
+	keypad_row1_1: keypad-row1-1 {
+		samsung,pins = "gpn-1";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+	};
+
+	keypad_row2_1: keypad-row2-1 {
+		samsung,pins = "gpn-2";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+	};
+
+	keypad_row3_1: keypad-row3-1 {
+		samsung,pins = "gpn-3";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+	};
+
+	keypad_row4_1: keypad-row4-1 {
+		samsung,pins = "gpn-4";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+	};
+
+	keypad_row5_1: keypad-row5-1 {
+		samsung,pins = "gpn-5";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+	};
+
+	keypad_row6_1: keypad-row6-1 {
+		samsung,pins = "gpn-6";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+	};
+
+	keypad_row7_1: keypad-row7-1 {
+		samsung,pins = "gpn-7";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+	};
+
+	lcd_ctrl: lcd-ctrl {
+		samsung,pins = "gpj-8", "gpj-9", "gpj-10", "gpj-11";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <0>;
+	};
+
+	lcd_data16: lcd-data-width16 {
+		samsung,pins = "gpi-3", "gpi-4", "gpi-5", "gpi-6",
+				"gpi-7", "gpi-10", "gpi-11", "gpi-12",
+				"gpi-13", "gpi-14", "gpi-15", "gpj-3",
+				"gpj-4", "gpj-5", "gpj-6", "gpj-7";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <0>;
+	};
+
+	lcd_data18: lcd-data-width18 {
+		samsung,pins = "gpi-2", "gpi-3", "gpi-4", "gpi-5",
+				"gpi-6", "gpi-7", "gpi-10", "gpi-11",
+				"gpi-12", "gpi-13", "gpi-14", "gpi-15",
+				"gpj-2", "gpj-3", "gpj-4", "gpj-5",
+				"gpj-6", "gpj-7";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <0>;
+	};
+
+	lcd_data24: lcd-data-width24 {
+		samsung,pins = "gpi-0", "gpi-1", "gpi-2", "gpi-3",
+				"gpi-4", "gpi-5", "gpi-6", "gpi-7",
+				"gpi-8", "gpi-9", "gpi-10", "gpi-11",
+				"gpi-12", "gpi-13", "gpi-14", "gpi-15",
+				"gpj-0", "gpj-1", "gpj-2", "gpj-3",
+				"gpj-4", "gpj-5", "gpj-6", "gpj-7";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <0>;
+	};
+
+	hsi_bus: hsi-bus {
+		samsung,pins = "gpk-0", "gpk-1", "gpk-2", "gpk-3",
+				"gpk-4", "gpk-5", "gpk-6", "gpk-7";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+	};
+};
diff --git a/arch/arm/boot/dts/s3c64xx.dtsi b/arch/arm/boot/dts/s3c64xx.dtsi
new file mode 100644
index 0000000..f86c0e4
--- /dev/null
+++ b/arch/arm/boot/dts/s3c64xx.dtsi
@@ -0,0 +1,136 @@
+/*
+ * Samsung's S3C64xx SoC series common device tree source
+ *
+ * Copyright (c) 2013 Tomasz Figa <tomasz.figa at gmail.com>
+ *
+ * Samsung's S3C64xx SoC series device nodes are listed in this file.
+ * Particular SoCs from S3C64xx series can include this file and provide
+ * values for SoCs specfic bindings.
+ *
+ * Note: This file does not include device nodes for all the controllers in
+ * S3C64xx SoCs. As device tree coverage for S3C64xx increases, additional
+ * nodes can be added to this file.
+ *
+ * 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/ "skeleton.dtsi"
+
+/ {
+	aliases {
+		pinctrl0 = &pinctrl0;
+	};
+
+	cpus {
+		cpu {
+			compatible = "arm,arm1176jzf-s", "arm,arm1176";
+		};
+	};
+
+	vic0: interrupt-controller at 71200000 {
+		compatible = "arm,pl192-vic";
+		interrupt-controller;
+		reg = <0x71200000 0x1000>;
+		#interrupt-cells = <1>;
+	};
+
+	vic1: interrupt-controller at 71300000 {
+		compatible = "arm,pl192-vic";
+		interrupt-controller;
+		reg = <0x71300000 0x1000>;
+		#interrupt-cells = <1>;
+	};
+
+	pinctrl0: pinctrl at 7f008000 {
+		compatible = "samsung,s3c64xx-pinctrl";
+		reg = <0x7f008000 0x1000>;
+		interrupt-parent = <&vic1>;
+		interrupts = <21>;
+
+		pctrl_int_map: pinctrl-interrupt-map {
+			interrupt-map = <0 &vic0 0>,
+					<1 &vic0 1>,
+					<2 &vic1 0>,
+					<3 &vic1 1>;
+			#address-cells = <0>;
+			#size-cells = <0>;
+			#interrupt-cells = <1>;
+		};
+
+		wakeup-interrupt-controller {
+			compatible = "samsung,s3c64xx-wakeup-eint";
+			interrupts = <0>, <1>, <2>, <3>;
+			interrupt-parent = <&pctrl_int_map>;
+		};
+	};
+
+	pwm: pwm at 7f006000 {
+		compatible = "samsung,s3c6400-pwm";
+		reg = <0x7f006000 0x1000>;
+		interrupt-parent = <&vic0>;
+		interrupts = <23>, <24>, <25>, <27>, <28>;
+		samsung,pwm-outputs = <0>, <1>;
+		#pwm-cells = <3>;
+		status = "disabled";
+	};
+
+	uart0: serial at 7f005000 {
+		compatible = "samsung,s3c6400-uart";
+		reg = <0x7f005000 0x100>;
+		interrupt-parent = <&vic1>;
+		interrupts = <5>;
+		status = "disabled";
+	};
+
+	uart1: serial at 7f005400 {
+		compatible = "samsung,s3c6400-uart";
+		reg = <0x7f005400 0x100>;
+		interrupt-parent = <&vic1>;
+		interrupts = <6>;
+		status = "disabled";
+	};
+
+	uart2: serial at 7f005800 {
+		compatible = "samsung,s3c6400-uart";
+		reg = <0x7f005800 0x100>;
+		interrupt-parent = <&vic1>;
+		interrupts = <7>;
+		status = "disabled";
+	};
+
+	uart3: serial at 7f005c00 {
+		compatible = "samsung,s3c6400-uart";
+		reg = <0x7f005c00 0x100>;
+		interrupt-parent = <&vic1>;
+		interrupts = <8>;
+		status = "disabled";
+	};
+
+	sdhci0: sdhci at 7c200000 {
+		compatible = "samsung,s3c6410-sdhci";
+		reg = <0x7c200000 0x100>;
+		interrupt-parent = <&vic1>;
+		interrupts = <24>;
+		status = "disabled";
+	};
+
+	sdhci1: sdhci at 7c300000 {
+		compatible = "samsung,s3c6410-sdhci";
+		reg = <0x7c300000 0x100>;
+		interrupt-parent = <&vic1>;
+		interrupts = <25>;
+		status = "disabled";
+	};
+
+	sdhci2: sdhci at 7c400000 {
+		compatible = "samsung,s3c6410-sdhci";
+		reg = <0x7c400000 0x100>;
+		interrupt-parent = <&vic1>;
+		interrupts = <17>;
+		status = "disabled";
+	};
+};
+
+/include/ "s3c64xx-pinctrl.dtsi"
-- 
1.8.1.5



From robherring2 at gmail.com  Mon Apr 15 17:20:18 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Mon, 15 Apr 2013 16:20:18 -0500
Subject: [PATCHv2 1/4] Documentation: Add memory mapped ARM architected
 timer binding
In-Reply-To: <1365812863-5367-2-git-send-email-sboyd@codeaurora.org>
References: <1365812863-5367-1-git-send-email-sboyd@codeaurora.org>
 <1365812863-5367-2-git-send-email-sboyd@codeaurora.org>
Message-ID: <516C6F12.5020208@gmail.com>

On Fri, Apr 12, 2013 at 7:27 PM, Stephen Boyd <sboyd at codeaurora.org> wrote:
> Add a binding for the arm architected timer hardware's memory
> mapped interface. The mmio timer hardware is made up of one base
> frame and a collection of up to 8 timer frames, where each of the
> 8 timer frames can have either one or two views. A frame
> typically maps to a privilege level (user/kernel, hypervisor,
> secure). The first view has full access to the registers within a
> frame, while the second view can be restricted to particular
> registers within a frame. Each frame must support a physical
> timer. It's optional for a frame to support a virtual timer.
>
> Cc: devicetree-discuss at lists.ozlabs.org
> Cc: Mark Rutland <mark.rutland at arm.com>
> Cc: Marc Zyngier <Marc.Zyngier at arm.com>
> Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
> ---
>  .../devicetree/bindings/arm/arch_timer.txt         | 59 ++++++++++++++++++++--
>  1 file changed, 56 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/arm/arch_timer.txt b/Documentation/devicetree/bindings/arm/arch_timer.txt
> index 20746e5..ac20cde 100644
> --- a/Documentation/devicetree/bindings/arm/arch_timer.txt
> +++ b/Documentation/devicetree/bindings/arm/arch_timer.txt
> @@ -1,10 +1,14 @@
>  * ARM architected timer
>
> -ARM cores may have a per-core architected timer, which provides per-cpu timers.
> +ARM cores may have a per-core architected timer, which provides per-cpu timers,
> +or a memory mapped architected timer, which provides up to 8 frames with a
> +physical and optional virtual timer per frame.
>
> -The timer is attached to a GIC to deliver its per-processor interrupts.
> +The per-core architected timer is attached to a GIC to deliver its
> +per-processor interrupts via PPIs. The memory mapped timer is attached to a GIC
> +to deliver its interrupts via SPIs.
>
> -** Timer node properties:
> +** CP15 Timer node properties:
>
>  - compatible : Should at least contain one of
>         "arm,armv7-timer"
> @@ -26,3 +30,52 @@ Example:
>                              <1 10 0xf08>;
>                 clock-frequency = <100000000>;
>         };
> +
> +** Memory mapped timer node properties
> +
> +- compatible : Should at least contain "arm,armv7-timer-mem".

Everything about this timer is architecturally defined? If not, let's
use a more specific name.

> +
> +- clock-frequency : The frequency of the main counter, in Hz. Optional.
> +
> +- reg : The control frame base address.
> +
> +Note that #address-cells, #size-cells, and ranges shall be present to ensure
> +the CPU can address a frame's registers.
> +
> +Frame:
> +
> +- frame-number: 0 to 7.

I'd really like to get rid of the frame numbers and sub-nodes. Is the
frame number significant to software?

> +- interrupts : Interrupt list for physical and virtual timers in that order.
> +  The virtual timer interrupt is optional.

Is that optional per frame?

Rob

> +
> +- reg : The first and second view base addresses in that order. The second view
> +  base address is optional.
> +
> +- status : "disabled" indicates the frame is not available for use.
> +
> +Example:
> +
> +       timer at f0000000 {
> +               compatible = "arm,armv7-timer-mem";
> +               #address-cells = <1>;
> +               #size-cells = <1>;
> +               ranges;
> +               reg = <0xf0000000 0x1000>;
> +               clock-frequency = <50000000>;
> +
> +               frame at f0001000 {
> +                       frame-number = <0>
> +                       interrupts = <0 13 0x8>,
> +                                    <0 14 0x8>;
> +                       reg = <0xf0001000 0x1000>,
> +                             <0xf0002000 0x1000>;
> +               };
> +
> +               frame at f0003000 {
> +                       frame-number = <1>
> +                       interrupts = <0 15 0x8>;
> +                       reg = <0xf0003000 0x1000>;
> +                       status = "disabled";
> +               };
> +       };
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> hosted by The Linux Foundation
>
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss


From sboyd at codeaurora.org  Mon Apr 15 17:33:37 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Mon, 15 Apr 2013 14:33:37 -0700
Subject: [PATCHv2 1/4] Documentation: Add memory mapped ARM architected
 timer binding
In-Reply-To: <516C6F12.5020208@gmail.com>
References: <1365812863-5367-1-git-send-email-sboyd@codeaurora.org>
 <1365812863-5367-2-git-send-email-sboyd@codeaurora.org>
 <516C6F12.5020208@gmail.com>
Message-ID: <516C7231.6060305@codeaurora.org>

On 04/15/13 14:20, Rob Herring wrote:
> On Fri, Apr 12, 2013 at 7:27 PM, Stephen Boyd <sboyd at codeaurora.org> wrote:
>> @@ -26,3 +30,52 @@ Example:
>>                              <1 10 0xf08>;
>>                 clock-frequency = <100000000>;
>>         };
>> +
>> +** Memory mapped timer node properties
>> +
>> +- compatible : Should at least contain "arm,armv7-timer-mem".
> Everything about this timer is architecturally defined? If not, let's
> use a more specific name.

I'm not sure I'm following you, but everything described here is part of
the ARM definition. What would be a more specific name?

>
>> +
>> +- clock-frequency : The frequency of the main counter, in Hz. Optional.
>> +
>> +- reg : The control frame base address.
>> +
>> +Note that #address-cells, #size-cells, and ranges shall be present to ensure
>> +the CPU can address a frame's registers.
>> +
>> +Frame:
>> +
>> +- frame-number: 0 to 7.
> I'd really like to get rid of the frame numbers and sub-nodes. Is the
> frame number significant to software?

We need the frame number to read and write registers in the control
frame (the first base in the parent node). We currently use it to
determine if a frame has support for the virtual timer by reading the
CNTTIDR (a register with 4 bits per frame describing capabilities). If
we wanted to control access to the second view of a frame we would also
need to configure the CNTPL0ACRn register that pertains to the frame
we're controlling. Without a frame number we wouldn't know which
register to write.

>
>> +- interrupts : Interrupt list for physical and virtual timers in that order.
>> +  The virtual timer interrupt is optional.
> Is that optional per frame?

Yes the virtual and physical timer interrupt is per-frame and the
virtual interrupt is optional.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation



From jon-hunter at ti.com  Mon Apr 15 17:40:22 2013
From: jon-hunter at ti.com (Jon Hunter)
Date: Mon, 15 Apr 2013 16:40:22 -0500
Subject: [PATCH 3/5] gpio/omap: Add DT support to GPIO driver
In-Reply-To: <516C31C3.9040505@wwwdotorg.org>
References: <1329321854-24490-1-git-send-email-b-cousson@ti.com>
 <51391F41.5000303@ti.com>
 <CAAwP0s1CFRO-rf==p5sYs1n0gigMif7wuT8Yv0N_iLUDMrtcOg@mail.gmail.com>
 <CACRpkdYHj-rEF3Rk_CWnmmMw_Amr7m8SgQ=-2zsDYuLeuu3azw@mail.gmail.com>
 <514C79E1.4090106@wwwdotorg.org> <514CE0AB.6060207@ti.com>
 <CACRpkdZmv-rAoKSQYpkHHSMzKJOn5TixVW_P3=m7ZNagBYCUPw@mail.gmail.com>
 <515319D5.20105@wwwdotorg.org>
 <CACRpkdYXVLgCz1Tyu-Ls2V2OTc4R3cGNJhfQJB6Hiz_K9dkZYQ@mail.gmail.com>
 <5155C902.7080207@wwwdotorg.org>
 <CACRpkdYbs4-uudpRUY8e+7icYYkZrfM0kReP3pLL5DMiURJ4dg@mail.gmail.com>
 <5165CB9D.1090202@wwwdotorg.org>
 <CACRpkdYirFNqmGhA4K9CL4ve4NYhs8Rd3SFt1iwW9vHBkrcz8g@mail.gmail.com>
 <51671D7B.5060303@wwwdotorg.org>
 <CACRpkdbf32Ef77GmXk9id9+RRjcDRTr7S+F4nznoeZU8y=BT_Q@mail.gmail.com>
 <51673D70.3010503@wwwdotorg.org>
 <CAAwP0s0e2x33jZQhFRY+Hoo61SFqYKRgWk=1mL2+DNxSDJHz+A@mail.gmail.com>
 <CACRpkda4h+qXTvsirPAS7E7sjXhMLE62q=VDy53W8UchsYjbNg@mail.gmail.com>
 <516C31C3.9040505@wwwdotorg.org>
Message-ID: <516C73C6.5050409@ti.com>


On 04/15/2013 11:58 AM, Stephen Warren wrote:
> On 04/14/2013 02:53 PM, Linus Walleij wrote:
>> On Sun, Apr 14, 2013 at 3:35 AM, Javier Martinez Canillas
>> <martinez.javier at gmail.com> wrote:
>>
>>> Is the following inlined patch [1] what you were thinking that would
>>> be the right approach?
>>
>> This looks sort of OK, but I'm still struggling with the question of
>> what we could do to help other implementations facing the same issue.
>>
>> This is a pretty hard design pattern to properly replicate in every such
>> driver is it not?
> 
> Well, instead of adding .request_irq() to the irqchip, and then making
> each driver call gpio_request() from the implementation, perhaps you
> could add a .irq_to_gpio() to the irqchip, have the IRQ core call that,
> and if it gets back a non-error response, the IRQ core could call
> gpio_request(). That means that the change to each GPIO+IRQ driver is
> simply to implement a standalone data transformation function
> .irq_to_gpio().

I am still concerned about the case where a driver may have already
called gpio_request() and then calls request_irq(). I think that the
solution needs to handle cases where the driver may or may not call
gpio_request() to allocate the gpio.

Although it could be argued that this is problem is not DT specific,
it does become a bigger problem to handle in the case of DT. Therefore,
I am wondering if we should just focus on the DT case for now. 

> Now, this does re-introduce irq_to_gpio() in some way, but with the
> following advantages:
> 
> 1) The implementation is per-controller, not a single global function,
> so isn't introducing any kind of centralized mapping scheme again.
> 
> 2) This irq-chip-specific .irq_to_gpio() would only be implemented for
> IRQ+GPIO chips that actually have a 1:1 mapping between GPIOs and IRQs.
> Its potential existence doesn't imply that all IRQ chips need implement
> this; it would be very specifically be for this one particular case.
> 
> So, I think it's reasonable to introduce this.

How about using the gpio irq domain xlate function?

Typically, in DT land a device using a gpio as an interrupt source
will have something like the following ...

eth at 0 {
	compatible = "ks8851";
	...
	interrupt-parent = <&gpio2>;
	interrupts = <2 8>; /* gpio line 34, low triggered */
};

... or ...

mmc {
	label = "pandaboard::status2";
 	gpios = <&gpio1 8 0>;
	...
};

Both these devices are using a gpio as an interrupt source, but the mmc
driver is requesting the gpio directly. In the first case the xlate
function for the gpio irq domain will be called where as it is not used
in the 2nd case. Therefore, we could add a custom xlate function. For
example ...

diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 53bb8d5..caaeab2 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -1085,6 +1085,33 @@ static void omap_gpio_chip_init(struct gpio_bank *bank)
        irq_set_handler_data(bank->irq, bank);
 }
 
+
+int omap_irq_domain_xlate(struct irq_domain *d, struct device_node *ctrlr,
+                         const u32 *intspec, unsigned int intsize,
+                         unsigned long *out_hwirq, unsigned int *out_type)
+{
+       struct gpio_bank *bank;
+       int irq;
+
+       if (WARN_ON(intsize < 1))
+               return -EINVAL;
+
+       irq = irq_find_mapping(d, intspec[0]);
+       bank = irq_get_chip_data(irq);
+       if (!bank)
+               return -ENODEV;
+
+       gpio_request_one(irq_to_gpio(bank, intspec[0]), GPIOF_IN, ctrlr->name);
+
+       *out_hwirq = intspec[0];
+       *out_type = (intsize > 1) ? intspec[1] : IRQ_TYPE_NONE;
+       return 0;
+}
+
+static const struct irq_domain_ops omap_irq_domain_ops = {
+       .xlate = omap_irq_domain_xlate,
+};
+
 static const struct of_device_id omap_gpio_match[];
 static void omap_gpio_setup_context(struct gpio_bank *p);
 
@@ -1135,7 +1162,7 @@ static int omap_gpio_probe(struct platform_device *pdev)
 
 
        bank->domain = irq_domain_add_linear(node, bank->width,
-                                            &irq_domain_simple_ops, NULL);
+                                            &omap_irq_domain_ops, NULL);
        if (!bank->domain)
                return -ENODEV;
 
Cheers
Jon
 


From jon-hunter at ti.com  Mon Apr 15 17:44:14 2013
From: jon-hunter at ti.com (Jon Hunter)
Date: Mon, 15 Apr 2013 16:44:14 -0500
Subject: [PATCH 3/5] gpio/omap: Add DT support to GPIO driver
In-Reply-To: <516C73C6.5050409@ti.com>
References: <1329321854-24490-1-git-send-email-b-cousson@ti.com>
 <51391F41.5000303@ti.com>
 <CAAwP0s1CFRO-rf==p5sYs1n0gigMif7wuT8Yv0N_iLUDMrtcOg@mail.gmail.com>
 <CACRpkdYHj-rEF3Rk_CWnmmMw_Amr7m8SgQ=-2zsDYuLeuu3azw@mail.gmail.com>
 <514C79E1.4090106@wwwdotorg.org> <514CE0AB.6060207@ti.com>
 <CACRpkdZmv-rAoKSQYpkHHSMzKJOn5TixVW_P3=m7ZNagBYCUPw@mail.gmail.com>
 <515319D5.20105@wwwdotorg.org>
 <CACRpkdYXVLgCz1Tyu-Ls2V2OTc4R3cGNJhfQJB6Hiz_K9dkZYQ@mail.gmail.com>
 <5155C902.7080207@wwwdotorg.org>
 <CACRpkdYbs4-uudpRUY8e+7icYYkZrfM0kReP3pLL5DMiURJ4dg@mail.gmail.com>
 <5165CB9D.1090202@wwwdotorg.org>
 <CACRpkdYirFNqmGhA4K9CL4ve4NYhs8Rd3SFt1iwW9vHBkrcz8g@mail.gmail.com>
 <51671D7B.5060303@wwwdotorg.org>
 <CACRpkdbf32Ef77GmXk9id9+RRjcDRTr7S+F4nznoeZU8y=BT_Q@mail.gmail.com>
 <51673D70.3010503@wwwdotorg.org>
 <CAAwP0s0e2x33jZQhFRY+Hoo61SFqYKRgWk=1mL2+DNxSDJHz+A@mail.gmail.com>
 <CACRpkda4h+qXTvsirPAS7E7sjXhMLE62q=VDy53W8UchsYjbNg@mail.gmail.com>
 <516C31C3.9040505@wwwdotorg.org> <516C73C6.5050409@ti.c! om>
Message-ID: <516C74AE.8040607@ti.com>


On 04/15/2013 04:40 PM, Jon Hunter wrote:
> 
> On 04/15/2013 11:58 AM, Stephen Warren wrote:
>> On 04/14/2013 02:53 PM, Linus Walleij wrote:
>>> On Sun, Apr 14, 2013 at 3:35 AM, Javier Martinez Canillas
>>> <martinez.javier at gmail.com> wrote:
>>>
>>>> Is the following inlined patch [1] what you were thinking that would
>>>> be the right approach?
>>>
>>> This looks sort of OK, but I'm still struggling with the question of
>>> what we could do to help other implementations facing the same issue.
>>>
>>> This is a pretty hard design pattern to properly replicate in every such
>>> driver is it not?
>>
>> Well, instead of adding .request_irq() to the irqchip, and then making
>> each driver call gpio_request() from the implementation, perhaps you
>> could add a .irq_to_gpio() to the irqchip, have the IRQ core call that,
>> and if it gets back a non-error response, the IRQ core could call
>> gpio_request(). That means that the change to each GPIO+IRQ driver is
>> simply to implement a standalone data transformation function
>> .irq_to_gpio().
> 
> I am still concerned about the case where a driver may have already
> called gpio_request() and then calls request_irq(). I think that the
> solution needs to handle cases where the driver may or may not call
> gpio_request() to allocate the gpio.
> 
> Although it could be argued that this is problem is not DT specific,
> it does become a bigger problem to handle in the case of DT. Therefore,
> I am wondering if we should just focus on the DT case for now. 
> 
>> Now, this does re-introduce irq_to_gpio() in some way, but with the
>> following advantages:
>>
>> 1) The implementation is per-controller, not a single global function,
>> so isn't introducing any kind of centralized mapping scheme again.
>>
>> 2) This irq-chip-specific .irq_to_gpio() would only be implemented for
>> IRQ+GPIO chips that actually have a 1:1 mapping between GPIOs and IRQs.
>> Its potential existence doesn't imply that all IRQ chips need implement
>> this; it would be very specifically be for this one particular case.
>>
>> So, I think it's reasonable to introduce this.
> 
> How about using the gpio irq domain xlate function?
> 
> Typically, in DT land a device using a gpio as an interrupt source
> will have something like the following ...
> 
> eth at 0 {
> 	compatible = "ks8851";
> 	...
> 	interrupt-parent = <&gpio2>;
> 	interrupts = <2 8>; /* gpio line 34, low triggered */
> };
> 
> ... or ...
> 
> mmc {
> 	label = "pandaboard::status2";
>  	gpios = <&gpio1 8 0>;
> 	...
> };
> 
> Both these devices are using a gpio as an interrupt source, but the mmc
> driver is requesting the gpio directly. In the first case the xlate
> function for the gpio irq domain will be called where as it is not used
> in the 2nd case. Therefore, we could add a custom xlate function. For
> example ...
> 
> diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
> index 53bb8d5..caaeab2 100644
> --- a/drivers/gpio/gpio-omap.c
> +++ b/drivers/gpio/gpio-omap.c
> @@ -1085,6 +1085,33 @@ static void omap_gpio_chip_init(struct gpio_bank *bank)
>         irq_set_handler_data(bank->irq, bank);
>  }
>  
> +
> +int omap_irq_domain_xlate(struct irq_domain *d, struct device_node *ctrlr,
> +                         const u32 *intspec, unsigned int intsize,
> +                         unsigned long *out_hwirq, unsigned int *out_type)
> +{
> +       struct gpio_bank *bank;
> +       int irq;
> +
> +       if (WARN_ON(intsize < 1))
> +               return -EINVAL;
> +
> +       irq = irq_find_mapping(d, intspec[0]);
> +       bank = irq_get_chip_data(irq);
> +       if (!bank)
> +               return -ENODEV;
> +
> +       gpio_request_one(irq_to_gpio(bank, intspec[0]), GPIOF_IN, ctrlr->name);

By the way, I know that I should check the return code here, but this
was just an example. Also I don't think using ctrlr->name here works
either as this is just "gpio".

Jon


From khilman at linaro.org  Mon Apr 15 18:06:33 2013
From: khilman at linaro.org (Kevin Hilman)
Date: Mon, 15 Apr 2013 15:06:33 -0700
Subject: [PATCH 1/5] gpio/omap: free irq domain in probe() failure paths
In-Reply-To: <5165C201.8010500@ti.com> (Jon Hunter's message of "Wed, 10 Apr
 2013 14:48:17 -0500")
References: <1365106576-31816-1-git-send-email-jon-hunter@ti.com>
 <1365106576-31816-2-git-send-email-jon-hunter@ti.com>
 <CACRpkdbGw8_eL2KbXU2FxSrDof=O_5tA+siZDLvTqERqa650wA@mail.gmail.com>
 <5165C201.8010500@ti.com>
Message-ID: <87a9ozbg9i.fsf@linaro.org>

Jon Hunter <jon-hunter at ti.com> writes:

> On 04/10/2013 02:33 PM, Linus Walleij wrote:
>> On Thu, Apr 4, 2013 at 10:16 PM, Jon Hunter <jon-hunter at ti.com> wrote:
>> 
>>> Currently the IRQ domain is not freed once allocated, in the case where
>>> omap_gpio_probe() fails. Therefore, ensure we free the domain if the
>>> probe does fail. Furthermore, the local variable "ret" is not needed
>>> and so remove this.
>>>
>>> Signed-off-by: Jon Hunter <jon-hunter at ti.com>
>> 
>> Hm Kevin is still listed as maintainer on this driver but on a mail
>> address that bounces, can you send a patch replacing him in MAINTAINERS
>> with yourself if you're willing to pick it up?
>> 
>> Anyway, patch applied.
>
> Thanks. There is a patch to fix this queued for v3.10 [1].

Yeah, but you've already been doing the heavly lifting here and should
be the maintainer going forward, IMO.  Patch below.

Linus, do you want to queue this up?

Kevin

>From 00d19c10c02c3a3aa99ca7ae75bc88a932437abd Mon Sep 17 00:00:00 2001
From: Kevin Hilman <khilman at linaro.org>
Date: Mon, 15 Apr 2013 15:02:26 -0700
Subject: [PATCH] MAINTAINERS: update OMAP GPIO driver: Jon Hunter taking over

Jon has already been doing most of maintenance of this driver, so
make it official.

Cc: Linus Walleij <linus.walleij at linaro.org>
Cc: Grant Likely <grant.likely at secretlab.ca>
Signed-off-by: Kevin Hilman <khilman at linaro.org>
---
Applies on v3.9-rc7

 MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 8bdd7a7..a18cacb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5789,7 +5789,7 @@ F:	arch/arm/*omap*/usb*
 
 OMAP GPIO DRIVER
 M:	Santosh Shilimkar <santosh.shilimkar at ti.com>
-M:	Kevin Hilman <khilman at deeprootsystems.com>
+M:	Jon Hunter <jon-hunter at ti.com>
 L:	linux-omap at vger.kernel.org
 S:	Maintained
 F:	drivers/gpio/gpio-omap.c
-- 
1.8.2



From swarren at wwwdotorg.org  Mon Apr 15 18:16:35 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Mon, 15 Apr 2013 16:16:35 -0600
Subject: [PATCH 3/5] gpio/omap: Add DT support to GPIO driver
In-Reply-To: <516C73C6.5050409@ti.com>
References: <1329321854-24490-1-git-send-email-b-cousson@ti.com>
 <51391F41.5000303@ti.com>
 <CAAwP0s1CFRO-rf==p5sYs1n0gigMif7wuT8Yv0N_iLUDMrtcOg@mail.gmail.com>
 <CACRpkdYHj-rEF3Rk_CWnmmMw_Amr7m8SgQ=-2zsDYuLeuu3azw@mail.gmail.com>
 <514C79E1.4090106@wwwdotorg.org> <514CE0AB.6060207@ti.com>
 <CACRpkdZmv-rAoKSQYpkHHSMzKJOn5TixVW_P3=m7ZNagBYCUPw@mail.gmail.com>
 <515319D5.20105@wwwdotorg.org>
 <CACRpkdYXVLgCz1Tyu-Ls2V2OTc4R3cGNJhfQJB6Hiz_K9dkZYQ@mail.gmail.com>
 <5155C902.7080207@wwwdotorg.org>
 <CACRpkdYbs4-uudpRUY8e+7icYYkZrfM0kReP3pLL5DMiURJ4dg@mail.gmail.com>
 <5165CB9D.1090202@wwwdotorg.org>
 <CACRpkdYirFNqmGhA4K9CL4ve4NYhs8Rd3SFt1iwW9vHBkrcz8g@mail.gmail.com>
 <51671D7B.5060303@wwwdotorg.org>
 <CACRpkdbf32Ef77GmXk9id9+RRjcDRTr7S+F4nznoeZU8y=BT_Q@mail.gmail.com>
 <51673D70.3010503@wwwdotorg.org>
 <CAAwP0s0e2x33jZQhFRY+Hoo61SFqYKRgWk=1mL2+DNxSDJHz+A@mail.gmail.com>
 <CACRpkda4h+qXTvsirPAS7E7sjXhMLE62q=VDy53W8UchsYjbNg@mail.gmail.com>
 <516C31C3.9040505@wwwdotorg.org> <516C73C6.5050409@ti.co m>
Message-ID: <516C7C43.3040105@wwwdotorg.org>

On 04/15/2013 03:40 PM, Jon Hunter wrote:
> 
> On 04/15/2013 11:58 AM, Stephen Warren wrote:
>> On 04/14/2013 02:53 PM, Linus Walleij wrote:
>>> On Sun, Apr 14, 2013 at 3:35 AM, Javier Martinez Canillas
>>> <martinez.javier at gmail.com> wrote:
>>>
>>>> Is the following inlined patch [1] what you were thinking that would
>>>> be the right approach?
>>>
>>> This looks sort of OK, but I'm still struggling with the question of
>>> what we could do to help other implementations facing the same issue.
>>>
>>> This is a pretty hard design pattern to properly replicate in every such
>>> driver is it not?
>>
>> Well, instead of adding .request_irq() to the irqchip, and then making
>> each driver call gpio_request() from the implementation, perhaps you
>> could add a .irq_to_gpio() to the irqchip, have the IRQ core call that,
>> and if it gets back a non-error response, the IRQ core could call
>> gpio_request(). That means that the change to each GPIO+IRQ driver is
>> simply to implement a standalone data transformation function
>> .irq_to_gpio().
> 
> I am still concerned about the case where a driver may have already
> called gpio_request() and then calls request_irq(). I think that the
> solution needs to handle cases where the driver may or may not call
> gpio_request() to allocate the gpio.

Are there actually drivers that do this? Perhaps they could just be
fixed not to.

> Although it could be argued that this is problem is not DT specific,
> it does become a bigger problem to handle in the case of DT. Therefore,
> I am wondering if we should just focus on the DT case for now. 

That doesn't sound like a good idea; this issue is entirely orthogonal
to DT.

>> Now, this does re-introduce irq_to_gpio() in some way, but with the
>> following advantages:
>>
>> 1) The implementation is per-controller, not a single global function,
>> so isn't introducing any kind of centralized mapping scheme again.
>>
>> 2) This irq-chip-specific .irq_to_gpio() would only be implemented for
>> IRQ+GPIO chips that actually have a 1:1 mapping between GPIOs and IRQs.
>> Its potential existence doesn't imply that all IRQ chips need implement
>> this; it would be very specifically be for this one particular case.
>>
>> So, I think it's reasonable to introduce this.
> 
> How about using the gpio irq domain xlate function?

That translates DT IRQ-specifiers to Linux IRQ numbers. There's no
reason to believe that, as an absolute rule, it would work for anything
GPIO-related. The fact that in practice most GPIO+IRQ controllers happen
to use the same numbering for GPIOs and IRQs is just co-incidence.

> Typically, in DT land a device using a gpio as an interrupt source
> will have something like the following ...
> 
> eth at 0 {
> 	compatible = "ks8851";
> 	...
> 	interrupt-parent = <&gpio2>;
> 	interrupts = <2 8>; /* gpio line 34, low triggered */
> };

OK, that really is an interrupt...

> ... or ...
> 
> mmc {
> 	label = "pandaboard::status2";
>  	gpios = <&gpio1 8 0>;
> 	...
> };

But that's a gpio-leds instance, not an MMC controller... I really
really hope there's no DT node using "gpios" to mean "interrupts"... And
it wouldn't make any sense for an on-SoC device anyway.

> Both these devices are using a gpio as an interrupt source, but the mmc
> driver is requesting the gpio directly. In the first case the xlate
> function for the gpio irq domain will be called where as it is not used
> in the 2nd case. Therefore, we could add a custom xlate function. For
> example ...
> 
> diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c

> +int omap_irq_domain_xlate(struct irq_domain *d, struct device_node *ctrlr,
...
> +       gpio_request_one(irq_to_gpio(bank, intspec[0]), GPIOF_IN, ctrlr->name);

I guess that could work, but:

a) It still means doing the gpio_request() in each driver instead of
centrally.

b) This approach doesn't solve the issue where some client driver has
already requested the GPIO. This code would simply prevent that call
from succeeding, which would probably make the driver probe() error out,
which isn't any different to the equivalent proposed centralized
gpio_request() inside some request_irq() failing, and causing the
device's probe() to error out.


From ccross at android.com  Mon Apr 15 18:21:14 2013
From: ccross at android.com (Colin Cross)
Date: Mon, 15 Apr 2013 15:21:14 -0700
Subject: [RFC PATCH 1/3] pstore-ram: use write-combine mappings
In-Reply-To: <51656992.60203@gmail.com>
References: <1365563297-12480-1-git-send-email-robherring2@gmail.com>
 <CAMbhsRSvQPbzJ7Nt=OSSYE_A1e+eaUjO7XY+qRppJ5_gfWmW4A@mail.gmail.com>
 <51656992.60203@gmail.com>
Message-ID: <CAMbhsRS1hnBRoomoiNijrXZB-938d2RSs1cu9EdSfmXD3xpSQg@mail.gmail.com>

On Wed, Apr 10, 2013 at 6:30 AM, Rob Herring <robherring2 at gmail.com> wrote:
> On 04/09/2013 10:53 PM, Colin Cross wrote:
>> On Tue, Apr 9, 2013 at 8:08 PM, Rob Herring <robherring2 at gmail.com> wrote:
>>> From: Rob Herring <rob.herring at calxeda.com>
>>>
>>> Atomic operations are undefined behavior on ARM for device or strongly
>>> ordered memory types. So use write-combine variants for mappings. This
>>> corresponds to normal, non-cacheable memory on ARM. For many other
>>> architectures, this change should not change the mapping type.
>>
>> This is going to make ramconsole less reliable.  A debugging printk
>> followed by a __raw_writel that causes an immediate hard crash is
>> likely to lose the last updates, including the most useful message, in
>> the write buffers.
>
> It would have to be a write that hangs the bus. In my experience with
> AXI, the bus doesn't actually hang until you hit max outstanding
> transactions.

I've seen many cases where a single write to device memory in an
unclocked slave will completely and instantly hang all cpus, and the
next write will never happen.

> I think exclusive stores will limit the buffering, but that is probably
> not architecturally guaranteed.
>
> I could put a wb() in at the end of persistent_ram_write.
>
>> Also, isn't this patch unnecessary after patch 3 in this set?
>
> It is still needed in the main memory case to be architecturally correct
> to avoid multiple mappings of different memory types and exclusive
> accesses to device memory. At least on an A9, it doesn't really seem to
> matter. I could remove this for the ioremap case.

According to my reading of the latest ARM ARM (Issue C, section
A3.5.7), and Catalin's excellent explanation
(http://lists.linaro.org/pipermail/linaro-dev/2012-February/010239.html),
it is no longer considered unpredictable to have both cached and
non-cached mappings to the same memory, as long as you use proper
cache maintenance between accessing the two mappings.

In pstore_ram the cached mapping will never be accessed (and we don't
care about speculative accesses), so no cache maintenance is
necessary.  I don't see any need for this patch, and I see plenty of
possible problems.


From jason at lakedaemon.net  Mon Apr 15 15:00:19 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Mon, 15 Apr 2013 15:00:19 -0400
Subject: [GIT PULL] mvebu dt (LPAE) for v3.10
Message-ID: <20130415190019.GS28693@titan.lakedaemon.net>


The following changes since commit b757f17e9184b65428c48a281d82f9acb3e96f0e:

  Merge tag 'tags/soc_for_v3.10' into mvebu/dt (2013-04-15 14:55:23 +0000)

are available in the git repository at:


  git://git.infradead.org/users/jcooper/linux.git tags/dt-3.10-4

for you to fetch changes up to 74898364e717c6bd939bb88d95049fc91d2b4950:

  ARM: dts: mvebu: Convert mvebu device tree files to 64 bits (2013-04-15 15:00:29 +0000)

----------------------------------------------------------------
mvebu dt for v3.10 round 4

 - mvebu LPAE 64bit dts file changes

Depends:
 - mvebu/fixes (tags/mvebu_fixes_for_v3.9_round3)
 - mvebu/soc (tags/soc_for_v3.10)

----------------------------------------------------------------
Gregory CLEMENT (3):
      ARM: dts: mvebu: Convert all the mvebu files to use the range property
      ARM: dts: mvebu: introduce internal-regs node
      ARM: dts: mvebu: Convert mvebu device tree files to 64 bits

Thomas Petazzoni (2):
      ARM: dts: mvebu: fix cpus section indentation
      ARM: dts: mvebu: move all peripherals inside soc

 arch/arm/boot/dts/armada-370-db.dts              | 134 +++----
 arch/arm/boot/dts/armada-370-mirabox.dts         | 176 +++++----
 arch/arm/boot/dts/armada-370-rd.dts              |  96 ++---
 arch/arm/boot/dts/armada-370-xp.dtsi             | 336 ++++++++--------
 arch/arm/boot/dts/armada-370.dtsi                | 330 ++++++++--------
 arch/arm/boot/dts/armada-xp-db.dts               | 202 +++++-----
 arch/arm/boot/dts/armada-xp-gp.dts               | 222 ++++++-----
 arch/arm/boot/dts/armada-xp-mv78230.dtsi         | 284 ++++++-------
 arch/arm/boot/dts/armada-xp-mv78260.dtsi         | 342 ++++++++--------
 arch/arm/boot/dts/armada-xp-mv78460.dtsi         | 484 ++++++++++++-----------
 arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 262 ++++++------
 arch/arm/boot/dts/armada-xp.dtsi                 | 202 +++++-----
 12 files changed, 1549 insertions(+), 1521 deletions(-)


From jason at lakedaemon.net  Mon Apr 15 14:28:24 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Mon, 15 Apr 2013 14:28:24 -0400
Subject: [GIT PULL 1/4] mvebu driver changes for v3.10
Message-ID: <20130415182824.GN28693@titan.lakedaemon.net>


The following changes since commit 8bb9660418e05bb1845ac1a2428444d78e322cc7:

  Linux 3.9-rc4 (2013-03-23 16:52:44 -0700)

are available in the git repository at:

  git://git.infradead.org/users/jcooper/linux.git tags/drivers-3.10-2

for you to fetch changes up to 198d1ec0221f2e57f5d7f82294faeb81d822fd74:

  clk: mvebu: add more PCIe clocks for Armada XP (2013-04-15 17:52:12 +0000)

----------------------------------------------------------------
mvebu drivers for v3.10 round 2

 - mvebu
    - device bus driver (Acked by gregkh to go through arm-soc)
    - PCIe prep work Acked by appropriate maintainers (of,pci,clk) for arm-soc

----------------------------------------------------------------
Andrew Murray (3):
      of/pci: Unify pci_process_bridge_OF_ranges from Microblaze and PowerPC
      of/pci: Provide support for parsing PCI DT ranges property
      of/pci: mips: convert to common of_pci_range_parser

Ezequiel Garcia (1):
      drivers: memory: Introduce Marvell EBU Device Bus driver

Neil Greatorex (1):
      bus: mvebu-mbus: Restore checking for coherency fabric hardware

Thierry Reding (2):
      of/pci: Add of_pci_get_devfn() function
      of/pci: Add of_pci_parse_bus_range() function

Thomas Petazzoni (5):
      bus: introduce an Marvell EBU MBus driver
      bus: mvebu: fix mistake in PCIe window target attribute for Kirkwood
      pci: infrastructure to add drivers in drivers/pci/host
      clk: mvebu: create parent-child relation for PCIe clocks on Armada 370
      clk: mvebu: add more PCIe clocks for Armada XP

 .../bindings/memory-controllers/mvebu-devbus.txt   | 156 ++++
 arch/microblaze/include/asm/pci-bridge.h           |   5 +-
 arch/microblaze/pci/pci-common.c                   | 192 -----
 arch/mips/pci/pci.c                                |  50 +-
 arch/powerpc/include/asm/pci-bridge.h              |   5 +-
 arch/powerpc/kernel/pci-common.c                   | 192 -----
 drivers/bus/Kconfig                                |   7 +
 drivers/bus/Makefile                               |   1 +
 drivers/bus/mvebu-mbus.c                           | 870 +++++++++++++++++++++
 drivers/clk/mvebu/clk-gating-ctrl.c                |  18 +-
 drivers/memory/Kconfig                             |  10 +
 drivers/memory/Makefile                            |   1 +
 drivers/memory/mvebu-devbus.c                      | 340 ++++++++
 drivers/of/address.c                               |  66 ++
 drivers/of/of_pci.c                                | 228 +++++-
 drivers/pci/Kconfig                                |   2 +
 drivers/pci/Makefile                               |   3 +
 drivers/pci/host/Kconfig                           |   4 +
 drivers/pci/host/Makefile                          |   1 +
 include/linux/mbus.h                               |  24 +-
 include/linux/of_address.h                         |  46 ++
 include/linux/of_pci.h                             |   6 +
 22 files changed, 1789 insertions(+), 438 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/memory-controllers/mvebu-devbus.txt
 create mode 100644 drivers/bus/mvebu-mbus.c
 create mode 100644 drivers/memory/mvebu-devbus.c
 create mode 100644 drivers/pci/host/Kconfig
 create mode 100644 drivers/pci/host/Makefile


From jason at lakedaemon.net  Mon Apr 15 15:48:25 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Mon, 15 Apr 2013 15:48:25 -0400
Subject: [PATCHv1 0/5] Marvell EBU irqchip improvements
In-Reply-To: <1365542778-27959-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1365542778-27959-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <20130415194825.GT28693@titan.lakedaemon.net>

On Tue, Apr 09, 2013 at 11:26:13PM +0200, Thomas Petazzoni wrote:
> Hello,
> 
> Here is a set of 5 patches that move the Marvell EBU IRQ controller
> driver to drivers/irqchip/ and do a few minor related cleanup or
> improvements.
> 
> Those commits were originally part of the series introducing PCIe MSI
> support for Marvell EBU platform, but the MSI support is not ready for
> merging. However, I'd like those preparation patches to be considered
> for 3.10.
> 
> Thanks,
> 
> Thomas
> 
> Thomas Petazzoni (5):
>   ARM: mvebu: move L2 cache initialization in init_early()
>   irqchip: move IRQ driver for Armada 370/XP
>   irqchip: armada-370-xp: move IRQ handler to avoid forward declaration
>   irqchip: armada-370-xp: slightly cleanup irq controller driver

I applied the above 4 patches to mvebu/irqchip in case tglx objects, it
can be dropped without impacting other work.

>   ARM: mvebu: do not duplicate the mpic alias

I already sent the PR for LPAE, which will conflict with this.  I'll add
this to mvebu/fixes once v3.9 drops.

>  arch/arm/boot/dts/armada-370.dtsi                  |    2 +-
>  arch/arm/boot/dts/armada-xp.dtsi                   |    2 +-
>  arch/arm/mach-mvebu/Makefile                       |    2 +-
>  arch/arm/mach-mvebu/armada-370-xp.c                |    9 +-
>  drivers/irqchip/Makefile                           |    1 +
>  .../irqchip}/irq-armada-370-xp.c                   |  106 ++++++++++----------
>  6 files changed, 62 insertions(+), 60 deletions(-)
>  rename {arch/arm/mach-mvebu => drivers/irqchip}/irq-armada-370-xp.c (91%)

thx,

Jason.


From jason at lakedaemon.net  Mon Apr 15 14:41:49 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Mon, 15 Apr 2013 14:41:49 -0400
Subject: [GIT PULL 3/4] mvebu boards for v3.10
Message-ID: <20130415184149.GQ28693@titan.lakedaemon.net>


The following changes since commit 8bb9660418e05bb1845ac1a2428444d78e322cc7:

  Linux 3.9-rc4 (2013-03-23 16:52:44 -0700)

are available in the git repository at:

  git://git.infradead.org/users/jcooper/linux.git tags/boards-3.10

for you to fetch changes up to d3dde4df4483cefc614317a2ae550b20ef29f58c:

  ARM: Kirkwood: update Network Space Mini v2 description (2013-04-10 18:16:25 +0000)

----------------------------------------------------------------
mvebu boards for v3.10

 - kirkwood
    - Netgear ReadyNAS Duo v2
    - add guruplug dt to defconfig
    - Lacie Cloudbox

----------------------------------------------------------------
Arnaud Ebalard (1):
      ARM: kirkwood: Add support for NETGEAR ReadyNAS Duo v2 using DT

Sebastian Hesselbarth (1):
      ARM: kirkwood: add MACH_GURUPLUG_DT to defconfig

Simon Guinot (3):
      ARM: Kirkwood: sort board entries by ASCII-code order
      ARM: Kirkwood: DT board setup for CloudBox
      ARM: Kirkwood: update Network Space Mini v2 description

 arch/arm/boot/dts/Makefile                         |   4 +-
 arch/arm/boot/dts/kirkwood-cloudbox.dts            |  89 ++++++
 .../boot/dts/kirkwood-netgear_readynas_duo_v2.dts  | 180 +++++++++++
 arch/arm/boot/dts/kirkwood-ns2mini.dts             |   1 +
 arch/arm/configs/kirkwood_defconfig                |  53 ++--
 arch/arm/mach-kirkwood/Kconfig                     | 334 +++++++++++----------
 arch/arm/mach-kirkwood/Makefile                    |  42 +--
 arch/arm/mach-kirkwood/board-dt.c                  |  18 +-
 arch/arm/mach-kirkwood/board-ns2.c                 |   3 +-
 arch/arm/mach-kirkwood/board-readynas.c            |  28 ++
 arch/arm/mach-kirkwood/common.h                    |  12 +
 11 files changed, 555 insertions(+), 209 deletions(-)
 create mode 100644 arch/arm/boot/dts/kirkwood-cloudbox.dts
 create mode 100644 arch/arm/boot/dts/kirkwood-netgear_readynas_duo_v2.dts
 create mode 100644 arch/arm/mach-kirkwood/board-readynas.c


From jason at lakedaemon.net  Mon Apr 15 14:50:18 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Mon, 15 Apr 2013 14:50:18 -0400
Subject: [GIT PULL 4/4] mvebu dt for v3.10
Message-ID: <20130415185018.GR28693@titan.lakedaemon.net>


The following changes since commit c3117edec5f92cce39f2d220c62f76675397af8d:

  Dove: Thermal: Add DT node and enable in defconfig (2013-03-12 11:33:22 +0000)

are available in the git repository at:

  git://git.infradead.org/users/jcooper/linux.git tags/dt-3.10-3

for you to fetch changes up to 513a7917b13370d9fbc41331413428dd713cb3fc:

  arm: mvebu: PCIe Device Tree informations for Armada XP GP (2013-04-15 14:53:53 +0000)

----------------------------------------------------------------
mvebu dt for v3.10 round 3

 - mvebu PCIe DT support

from round 2 (no pr was sent):
 - 64bit dts skeleton
 - mvebu devicebus additions
 - mvebu thermal nodes
 - mirabox gpio leds
 - orion5x xor and ehci
 - use mvsdio on guruplug dt

----------------------------------------------------------------
Alexander Clouter (2):
      arm: orion5x: add ehci bindings to dtsi
      arm: orion5x: enable xor for orion5x platform

Ezequiel Garcia (8):
      ARM: mvebu: Add button on Armada 370 Reference Design board
      ARM: mvebu: Add thermal support to Armada XP device tree
      ARM: mvebu: Add thermal support to Armada 370 device tree
      ARM: configs: Update mvebu defconfig for thermal
      ARM: mvebu: Add Device Bus support for Armada 370/XP SoC
      ARM: mvebu: Add support for NOR flash device on Armada XP-GP board
      ARM: mvebu: Add support for NOR flash device on Openblocks AX3 board
      ARM: mvebu: Add Device Bus and CFI flash memory support to defconfig

Lior Amsalem (1):
      ARM: dts: Add a 64 bits version of the skeleton device tree

Ryan Press (1):
      arm: mvebu: Add GPIO LEDs to Mirabox board

Sebastian Hesselbarth (1):
      ARM: kirkwood: make use of DT mvsdio on guruplug board

Thomas Petazzoni (7):
      arm: mvebu: add PCIe Device Tree informations for Armada 370
      arm: mvebu: add PCIe Device Tree informations for Armada XP
      arm: mvebu: PCIe Device Tree informations for OpenBlocks AX3-4
      arm: mvebu: PCIe Device Tree informations for Armada XP DB
      arm: mvebu: PCIe Device Tree informations for Armada 370 Mirabox
      arm: mvebu: PCIe Device Tree informations for Armada 370 DB
      arm: mvebu: PCIe Device Tree informations for Armada XP GP

 arch/arm/boot/dts/armada-370-db.dts                |  17 ++
 arch/arm/boot/dts/armada-370-mirabox.dts           |  53 ++++++
 arch/arm/boot/dts/armada-370-rd.dts                |  11 ++
 arch/arm/boot/dts/armada-370-xp.dtsi               |  45 +++++
 arch/arm/boot/dts/armada-370.dtsi                  |  58 +++++++
 arch/arm/boot/dts/armada-xp-db.dts                 |  33 ++++
 arch/arm/boot/dts/armada-xp-gp.dts                 |  50 ++++++
 arch/arm/boot/dts/armada-xp-mv78230.dtsi           | 104 ++++++++++++
 arch/arm/boot/dts/armada-xp-mv78260.dtsi           | 122 +++++++++++++
 arch/arm/boot/dts/armada-xp-mv78460.dtsi           | 188 +++++++++++++++++++++
 arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts   |  38 +++++
 arch/arm/boot/dts/armada-xp.dtsi                   |   6 +
 .../arm/boot/dts/kirkwood-guruplug-server-plus.dts |   4 +
 arch/arm/boot/dts/orion5x.dtsi                     |  33 ++++
 arch/arm/boot/dts/skeleton64.dtsi                  |  13 ++
 arch/arm/configs/mvebu_defconfig                   |   9 +
 arch/arm/mach-kirkwood/board-guruplug.c            |   6 -
 17 files changed, 784 insertions(+), 6 deletions(-)
 create mode 100644 arch/arm/boot/dts/skeleton64.dtsi


From jason at lakedaemon.net  Mon Apr 15 14:36:05 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Mon, 15 Apr 2013 14:36:05 -0400
Subject: [GIT PULL 2/4] mvebu soc for v3.10
Message-ID: <20130415183605.GO28693@titan.lakedaemon.net>


The following changes since commit 8bb9660418e05bb1845ac1a2428444d78e322cc7:

  Linux 3.9-rc4 (2013-03-23 16:52:44 -0700)

are available in the git repository at:

  git://git.infradead.org/users/jcooper/linux.git tags/soc_for_v3.10

for you to fetch changes up to da497f6fbaa190d34907ecc9dd85cfc62ba9f5a2:

  ARM: mvebu: Align the internal registers virtual base to support LPAE (2013-04-15 14:06:59 +0000)

----------------------------------------------------------------
mvebu soc changes for v3.10

 - use the mvebu-mbus driver
 - prep for LPAE support

Depends:
 - mvebu/cleanup (tags/cleanup_for_v3.10)
 - mvebu/drivers (tags/drivers_for_v3.10)

----------------------------------------------------------------
Gregory CLEMENT (1):
      ARM: mvebu: Limit the DMA zone when LPAE is selected

Jason Cooper (2):
      Merge tag 'tags/cleanup_for_v3.10' into mvebu/soc
      Merge tag 'tags/drivers_for_v3.10' into mvebu/soc

Lior Amsalem (1):
      ARM: mvebu: Align the internal registers virtual base to support LPAE

Neil Greatorex (1):
      bus: mvebu-mbus: Restore checking for coherency fabric hardware

Simon Guinot (1):
      ARM: Orion: add dbg_show function to gpio-orion driver

Thomas Petazzoni (11):
      arm: plat-orion: only build addr-map.c when needed
      arm: plat-orion: use mv_mbus_dram_info() in PCIe code
      arm: mach-orion5x: use mv_mbus_dram_info() in PCI code
      bus: introduce an Marvell EBU MBus driver
      bus: mvebu: fix mistake in PCIe window target attribute for Kirkwood
      arm: mach-mvebu: convert to use mvebu-mbus driver
      arm: mach-kirkwood: convert to use mvebu-mbus driver
      arm: mach-dove: convert to use mvebu-mbus driver
      arm: mach-orion5x: convert to use mvebu-mbus driver
      arm: mach-mv78xx0: convert to use the mvebu-mbus driver
      arm: plat-orion: remove addr-map code

 arch/arm/Kconfig                               |   4 +
 arch/arm/boot/dts/armada-370-xp.dtsi           |   5 -
 arch/arm/include/debug/mvebu.S                 |   2 +-
 arch/arm/mach-dove/Makefile                    |   2 +-
 arch/arm/mach-dove/addr-map.c                  | 125 ----
 arch/arm/mach-dove/board-dt.c                  |   2 +-
 arch/arm/mach-dove/common.c                    |  39 +-
 arch/arm/mach-dove/common.h                    |   2 +-
 arch/arm/mach-dove/include/mach/dove.h         |   5 +
 arch/arm/mach-kirkwood/Makefile                |   2 +-
 arch/arm/mach-kirkwood/addr-map.c              |  91 ---
 arch/arm/mach-kirkwood/board-dt.c              |   2 +-
 arch/arm/mach-kirkwood/common.c                |  38 +-
 arch/arm/mach-kirkwood/common.h                |   2 +-
 arch/arm/mach-kirkwood/include/mach/kirkwood.h |   7 +-
 arch/arm/mach-kirkwood/pcie.c                  |   1 -
 arch/arm/mach-mv78xx0/Makefile                 |   2 +-
 arch/arm/mach-mv78xx0/addr-map.c               |  93 ---
 arch/arm/mach-mv78xx0/common.c                 |  10 +-
 arch/arm/mach-mv78xx0/include/mach/mv78xx0.h   |   9 +-
 arch/arm/mach-mv78xx0/pcie.c                   |  21 +-
 arch/arm/mach-mvebu/Kconfig                    |   2 +
 arch/arm/mach-mvebu/Makefile                   |   2 +-
 arch/arm/mach-mvebu/addr-map.c                 | 137 ----
 arch/arm/mach-mvebu/armada-370-xp.c            |  18 +
 arch/arm/mach-mvebu/armada-370-xp.h            |   8 +-
 arch/arm/mach-mvebu/platsmp.c                  |   2 +
 arch/arm/mach-orion5x/Makefile                 |   2 +-
 arch/arm/mach-orion5x/addr-map.c               | 155 -----
 arch/arm/mach-orion5x/board-dt.c               |   2 +-
 arch/arm/mach-orion5x/common.c                 |  49 +-
 arch/arm/mach-orion5x/common.h                 |  13 +-
 arch/arm/mach-orion5x/d2net-setup.c            |   4 +-
 arch/arm/mach-orion5x/db88f5281-setup.c        |  13 +-
 arch/arm/mach-orion5x/dns323-setup.c           |   3 +-
 arch/arm/mach-orion5x/edmini_v2-setup.c        |   4 +-
 arch/arm/mach-orion5x/include/mach/orion5x.h   |   6 +-
 arch/arm/mach-orion5x/kurobox_pro-setup.c      |   8 +-
 arch/arm/mach-orion5x/ls-chl-setup.c           |   4 +-
 arch/arm/mach-orion5x/ls_hgl-setup.c           |   4 +-
 arch/arm/mach-orion5x/lsmini-setup.c           |   4 +-
 arch/arm/mach-orion5x/mss2-setup.c             |   3 +-
 arch/arm/mach-orion5x/mv2120-setup.c           |   3 +-
 arch/arm/mach-orion5x/net2big-setup.c          |   4 +-
 arch/arm/mach-orion5x/pci.c                    |  14 +-
 arch/arm/mach-orion5x/rd88f5181l-fxo-setup.c   |   4 +-
 arch/arm/mach-orion5x/rd88f5181l-ge-setup.c    |   4 +-
 arch/arm/mach-orion5x/rd88f5182-setup.c        |   7 +-
 arch/arm/mach-orion5x/terastation_pro2-setup.c |   4 +-
 arch/arm/mach-orion5x/ts209-setup.c            |   4 +-
 arch/arm/mach-orion5x/ts409-setup.c            |   4 +-
 arch/arm/mach-orion5x/wnr854t-setup.c          |   4 +-
 arch/arm/mach-orion5x/wrt350n-v2-setup.c       |   4 +-
 arch/arm/plat-orion/Makefile                   |   2 -
 arch/arm/plat-orion/addr-map.c                 | 178 -----
 arch/arm/plat-orion/gpio.c                     |  59 ++
 arch/arm/plat-orion/pcie.c                     |  10 +-
 drivers/bus/Kconfig                            |   7 +
 drivers/bus/Makefile                           |   1 +
 drivers/bus/mvebu-mbus.c                       | 870 +++++++++++++++++++++++++
 include/linux/mbus.h                           |  27 +-
 61 files changed, 1234 insertions(+), 883 deletions(-)
 delete mode 100644 arch/arm/mach-dove/addr-map.c
 delete mode 100644 arch/arm/mach-kirkwood/addr-map.c
 delete mode 100644 arch/arm/mach-mv78xx0/addr-map.c
 delete mode 100644 arch/arm/mach-mvebu/addr-map.c
 delete mode 100644 arch/arm/mach-orion5x/addr-map.c
 delete mode 100644 arch/arm/plat-orion/addr-map.c
 create mode 100644 drivers/bus/mvebu-mbus.c


From jason at lakedaemon.net  Mon Apr 15 14:37:45 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Mon, 15 Apr 2013 14:37:45 -0400
Subject: [PATCH v6 0/3] of/pci: Provide common support for PCI DT parsing
In-Reply-To: <CACRpkdbSd8pRG5pUS0ymqXDSp=ZhoQa2ctVuRA0cCmUcX5qFAA@mail.gmail.com>
References: <1365693969-23907-1-git-send-email-Andrew.Murray@arm.com>
 <20130415175641.GM28693@titan.lakedaemon.net>
 <CACRpkdbSd8pRG5pUS0ymqXDSp=ZhoQa2ctVuRA0cCmUcX5qFAA@mail.gmail.com>
Message-ID: <20130415183745.GP28693@titan.lakedaemon.net>

On Mon, Apr 15, 2013 at 08:29:06PM +0200, Linus Walleij wrote:
> On Mon, Apr 15, 2013 at 7:56 PM, Jason Cooper <jason at lakedaemon.net> wrote:
> 
> > As agreed with Rob Herring, series applied to mvebu/drivers to support
> > mvebu pcie driver.
> 
> Will this hit ARM SoC soon-ish so I can base a pull request for the Integrator
> on this stuff as well?

PR just sent, I'll defer to our kind overlords ;-)

thx,

Jason.


From jason at lakedaemon.net  Mon Apr 15 15:52:45 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Mon, 15 Apr 2013 15:52:45 -0400
Subject: [GIT PULL] mvebu irqchip for v3.10
Message-ID: <20130415195245.GU28693@titan.lakedaemon.net>


The following changes since commit 31880c37c11e28cb81c70757e38392b42e695dc6:

  Linux 3.9-rc6 (2013-04-07 20:49:54 -0700)

are available in the git repository at:

  git://git.infradead.org/users/jcooper/linux.git tags/irqchip-3.10

for you to fetch changes up to 5ec69017cc944f3ed88362d4b60818713a45e616:

  irqchip: armada-370-xp: slightly cleanup irq controller driver (2013-04-15 19:35:17 +0000)

----------------------------------------------------------------
mvebu driver irqchip for v3.10

 - move the armada irqchip driver to drivers/irqchip/

Note:
 - I asked tglx if it was ok to take this series on 10 Apr due to it's complex
   dependencies.  5+ days have passed with no objection.
 - I put this driver in a separate mvebu branch in case tglx or others object,
   it can be dropped with minimal impact to other work.

----------------------------------------------------------------
Thomas Petazzoni (4):
      ARM: mvebu: move L2 cache initialization in init_early()
      irqchip: move IRQ driver for Armada 370/XP
      irqchip: armada-370-xp: move IRQ handler to avoid forward declaration
      irqchip: armada-370-xp: slightly cleanup irq controller driver

 arch/arm/mach-mvebu/Makefile                       |   2 +-
 arch/arm/mach-mvebu/armada-370-xp.c                |   9 +-
 drivers/irqchip/Makefile                           |   1 +
 .../irqchip}/irq-armada-370-xp.c                   | 106 ++++++++++-----------
 4 files changed, 60 insertions(+), 58 deletions(-)
 rename {arch/arm/mach-mvebu => drivers/irqchip}/irq-armada-370-xp.c (91%)


From khilman at linaro.org  Mon Apr 15 18:44:51 2013
From: khilman at linaro.org (Kevin Hilman)
Date: Mon, 15 Apr 2013 15:44:51 -0700
Subject: [PATCH] PM / Runtime: Improve prepare handling at system suspend
 for genpd
In-Reply-To: <1844674.ZBv3XGts1U@vostro.rjw.lan> (Rafael J. Wysocki's message
 of "Fri, 12 Apr 2013 13:50:36 +0200")
References: <1365759704-23722-1-git-send-email-ulf.hansson@stericsson.com>
 <1844674.ZBv3XGts1U@vostro.rjw.lan>
Message-ID: <87vc7n8lcs.fsf@linaro.org>

"Rafael J. Wysocki" <rjw at sisk.pl> writes:

> On Friday, April 12, 2013 11:41:44 AM Ulf Hansson wrote:
>> From: Ulf Hansson <ulf.hansson at linaro.org>
>> 
>> When genpd prepares for a system suspend it will fetch a runtime
>> reference for the device. When returning it we now use the
>> asyncronous runtime PM API. Thus we don't have to wait for the
>> device to become idle|suspended before we move on and handle the
>> next device in queue.
>> 
>> Signed-off-by: Ulf Hansson <ulf.hansson at linaro.org>
>> Cc: Kevin Hilman <khilman at linaro.org>
>> Cc: Alan Stern <stern at rowland.harvard.edu>
>
> All three patches applied to linux-pm.git/linux-next.

In case it matters, for all three:

Reviewed-by: Kevin Hilman <khilman at linaro.org>


From swarren at wwwdotorg.org  Mon Apr 15 18:51:28 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Mon, 15 Apr 2013 16:51:28 -0600
Subject: [PATCH 1/3] ARM: tegra: fix build error when THUMB2_KERNEL enabled
In-Reply-To: <1366029749-16476-1-git-send-email-josephl@nvidia.com>
References: <1366029749-16476-1-git-send-email-josephl@nvidia.com>
Message-ID: <516C8470.5090007@wwwdotorg.org>

On 04/15/2013 06:42 AM, Joseph Lo wrote:
> This patch fix the build failure when CONFIG_THUBM2_KERNEL enabled. You
> clould see the error message below:
> 
> arch/arm/mach-tegra/sleep-tegra30.S:69: Error: shift must be constant --
> `orr r12,r12,r4,lsl r3'

I have forwarded the series to the arm-soc maintainers to be applied
there. Thanks.


From swarren at wwwdotorg.org  Mon Apr 15 18:53:05 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Mon, 15 Apr 2013 16:53:05 -0600
Subject: [PATCH] ARM: tegra: pm: fix build error w/o PM_SLEEP
Message-ID: <1366066385-18246-1-git-send-email-swarren@wwwdotorg.org>

From: Joseph Lo <josephl at nvidia.com>

This fixes the building error when the PM_SLEEP is disabled. The fucntional
defintion of "tegra_pm_validate_suspend_mode" without "static inline"
would become a multiple definition error.

Reported-by: Rhyland Klein <rklein at nvidia.com>
Signed-off-by: Joseph Lo <josephl at nvidia.com>
Signed-off-by: Stephen Warren <swarren at nvidia.com>
---
Arnd, Olof, can you please apply this to arm-soc too.

It probably should be applied wherever Tegra's for-3.10/soc branch was
merged, since it fixes up code that was introduced in that branch. I have
checked it applies cleanly to that Tegra branch, and doesn't cause any
merge issues with at least other Tegra for-3.10 branches.

 arch/arm/mach-tegra/pm.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-tegra/pm.h b/arch/arm/mach-tegra/pm.h
index 9d2d038..778a4aa 100644
--- a/arch/arm/mach-tegra/pm.h
+++ b/arch/arm/mach-tegra/pm.h
@@ -39,7 +39,7 @@ enum tegra_suspend_mode tegra_pm_validate_suspend_mode(
 				enum tegra_suspend_mode mode);
 void tegra_init_suspend(void);
 #else
-enum tegra_suspend_mode tegra_pm_validate_suspend_mode(
+static inline enum tegra_suspend_mode tegra_pm_validate_suspend_mode(
 				enum tegra_suspend_mode mode)
 {
 	return TEGRA_SUSPEND_NONE;
-- 
1.7.10.4



From swarren at wwwdotorg.org  Mon Apr 15 18:53:34 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Mon, 15 Apr 2013 16:53:34 -0600
Subject: [PATCH] ARM: tegra: pm: fix build error w/o PM_SLEEP
In-Reply-To: <1365730733-22701-1-git-send-email-josephl@nvidia.com>
References: <1365730733-22701-1-git-send-email-josephl@nvidia.com>
Message-ID: <516C84EE.8010204@wwwdotorg.org>

On 04/11/2013 07:38 PM, Joseph Lo wrote:
> This fixes the building error when the PM_SLEEP is disabled. The fucntional
> defintion of "tegra_pm_validate_suspend_mode" without "static inline"
> would become a multiple definition error.

Thanks. I have forwarded this to arm-soc to be applied.


From khilman at linaro.org  Mon Apr 15 18:55:47 2013
From: khilman at linaro.org (Kevin Hilman)
Date: Mon, 15 Apr 2013 15:55:47 -0700
Subject: [V3 patch 03/19] ARM: OMAP3: remove cpuidle_wrap_enter
In-Reply-To: <1365770165-27096-4-git-send-email-daniel.lezcano@linaro.org>
 (Daniel Lezcano's message of "Fri, 12 Apr 2013 14:35:49 +0200")
References: <1365770165-27096-1-git-send-email-daniel.lezcano@linaro.org>
 <1365770165-27096-4-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <87ppxv8kuk.fsf@linaro.org>

Daniel Lezcano <daniel.lezcano at linaro.org> writes:

> In a previous commit the en_core_tk_irqen flag has been added but we missed
> the cpuidle_wrap_enter which was doing the job to measure the time for the
> 'omap3_enter_idle' function.
>
> Actually, I don't see any reason to use this wrapper in the code. In the better
> case, the time computation is not correctly done because of the different
> operations done in omap3_enter_idle_bm which were not taken into account
> before the en_core_tk_irqen flag was set.
>
> As the time is reflected for the state overridden by the omap3_enter_idle_bm,
> using the wrapper is pointless now, so removing it.
>
> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>

Acked-by: Kevin Hilman <khilman at linaro.org>

If this doesn't make it for v3.10 (since Rafael is travelling), it should
probably be queued for v3.10-rc.

Kevin

> ---
>  arch/arm/mach-omap2/cpuidle34xx.c |   30 +++++++++---------------------
>  1 file changed, 9 insertions(+), 21 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/cpuidle34xx.c b/arch/arm/mach-omap2/cpuidle34xx.c
> index 4f67a5b..a56310a 100644
> --- a/arch/arm/mach-omap2/cpuidle34xx.c
> +++ b/arch/arm/mach-omap2/cpuidle34xx.c
> @@ -99,11 +99,15 @@ static struct omap3_idle_statedata omap3_idle_data[] = {
>  	},
>  };
>  
> -/* Private functions */
> -
> -static int __omap3_enter_idle(struct cpuidle_device *dev,
> -				struct cpuidle_driver *drv,
> -				int index)
> +/**
> + * omap3_enter_idle - Programs OMAP3 to enter the specified state
> + * @dev: cpuidle device
> + * @drv: cpuidle driver
> + * @index: the index of state to be entered
> + */
> +static int omap3_enter_idle(struct cpuidle_device *dev,
> +			    struct cpuidle_driver *drv,
> +			    int index)
>  {
>  	struct omap3_idle_statedata *cx = &omap3_idle_data[index];
>  
> @@ -149,22 +153,6 @@ return_sleep_time:
>  }
>  
>  /**
> - * omap3_enter_idle - Programs OMAP3 to enter the specified state
> - * @dev: cpuidle device
> - * @drv: cpuidle driver
> - * @index: the index of state to be entered
> - *
> - * Called from the CPUidle framework to program the device to the
> - * specified target state selected by the governor.
> - */
> -static inline int omap3_enter_idle(struct cpuidle_device *dev,
> -				struct cpuidle_driver *drv,
> -				int index)
> -{
> -	return cpuidle_wrap_enter(dev, drv, index, __omap3_enter_idle);
> -}
> -
> -/**
>   * next_valid_state - Find next valid C-state
>   * @dev: cpuidle device
>   * @drv: cpuidle driver


From swarren at wwwdotorg.org  Mon Apr 15 18:50:54 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Mon, 15 Apr 2013 16:50:54 -0600
Subject: [PATCH 2/3] ARM: tegra: fix relocation truncated error when
 THUMB2_KERNEL enabled
In-Reply-To: <1366066255-18192-1-git-send-email-swarren@wwwdotorg.org>
References: <1366066255-18192-1-git-send-email-swarren@wwwdotorg.org>
Message-ID: <1366066255-18192-2-git-send-email-swarren@wwwdotorg.org>

From: Joseph Lo <josephl at nvidia.com>

The conditional branch instruction in Thumb2 only available to short range.
The linker will fail when the conditional branch over the range. Then
resulting in link error when generating kernel image. e.g.:

arch/arm/mach-tegra/reset-handler.S:47:(.text+0xf8e):
relocation truncated to fit: R_ARM_THM_JUMP19 against symbol
`cpu_resume' defined in .data section in arch/arm/kernel/built-in.o

This patch using a Thumb2 instruction IT (if-then) to have a longer branch
range.

Reported-by: Arnd Bergmann <arnd at arndb.de>
Signed-off-by: Joseph Lo <josephl at nvidia.com>
Signed-off-by: Stephen Warren <swarren at nvidia.com>
---
 arch/arm/mach-tegra/reset-handler.S |    1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-tegra/reset-handler.S b/arch/arm/mach-tegra/reset-handler.S
index 1676aba..e6de88a 100644
--- a/arch/arm/mach-tegra/reset-handler.S
+++ b/arch/arm/mach-tegra/reset-handler.S
@@ -44,6 +44,7 @@ ENTRY(tegra_resume)
 
 	cpu_id	r0
 	cmp	r0, #0				@ CPU0?
+ THUMB(	it	ne )
 	bne	cpu_resume			@ no
 
 #ifdef CONFIG_ARCH_TEGRA_3x_SOC
-- 
1.7.10.4



From swarren at wwwdotorg.org  Mon Apr 15 18:50:53 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Mon, 15 Apr 2013 16:50:53 -0600
Subject: [PATCH 1/3] ARM: tegra: fix build error when THUMB2_KERNEL enabled
Message-ID: <1366066255-18192-1-git-send-email-swarren@wwwdotorg.org>

From: Joseph Lo <josephl at nvidia.com>

This patch fix the build failure when CONFIG_THUBM2_KERNEL enabled. You
clould see the error message below:

arch/arm/mach-tegra/sleep-tegra30.S:69: Error: shift must be constant --
`orr r12,r12,r4,lsl r3'

Reported-by: Arnd Bergmann <arnd at arndb.de>
Signed-off-by: Joseph Lo <josephl at nvidia.com>
Signed-off-by: Stephen Warren <swarren at nvidia.com>
---
Arnd, Olof, here are 3 fixes from Joseph for some Tegra build issues,
mostly exposed by multi-platform enablement and/or related randconfig
testing.

Can you please apply these to arm-soc? For reference, I tested applying
them to Tegra's for-3.10/fixes branch and they apply there fine, and
merge with the other Tegra for-3.10 branches at least, without any issue.

Note: patch 3 triggers checkpatch, but I can't work out why; the code
seems to be formatted the same as patch 1 and 2, and is consistent with
other usage of ARM() and THUMB() macros in arch/arm/.

 arch/arm/mach-tegra/sleep-tegra30.S |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-tegra/sleep-tegra30.S b/arch/arm/mach-tegra/sleep-tegra30.S
index 63a15bd..d29dfcc 100644
--- a/arch/arm/mach-tegra/sleep-tegra30.S
+++ b/arch/arm/mach-tegra/sleep-tegra30.S
@@ -66,7 +66,9 @@ ENTRY(tegra30_cpu_shutdown)
 		FLOW_CTRL_CSR_INTR_FLAG | FLOW_CTRL_CSR_EVENT_FLAG | \
 		FLOW_CTRL_CSR_ENABLE
 	mov	r4, #(1 << 4)
-	orr	r12, r12, r4, lsl r3
+ ARM(	orr	r12, r12, r4, lsl r3	)
+ THUMB(	lsl	r4, r4, r3		)
+ THUMB(	orr	r12, r12, r4		)
 	str	r12, [r1]
 
 	/* Halt this CPU. */
-- 
1.7.10.4



From swarren at wwwdotorg.org  Mon Apr 15 18:50:55 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Mon, 15 Apr 2013 16:50:55 -0600
Subject: [PATCH 3/3] ARM: tegra: make sure the pointer on 4 byte align when
 THUMB2_KERNEL enabled
In-Reply-To: <1366066255-18192-1-git-send-email-swarren@wwwdotorg.org>
References: <1366066255-18192-1-git-send-email-swarren@wwwdotorg.org>
Message-ID: <1366066255-18192-3-git-send-email-swarren@wwwdotorg.org>

From: Joseph Lo <josephl at nvidia.com>

When building kernel with CONFIG_THUMB2_KERNEL, the data pointer in the
assembly may not on the 4 byte alignment. Then causing a data abort when
accessing the pointer. This patch add a ".align" flag in the head of the
pointer. And always using 32-bit ADR Thumb instruction to make sure it
won't build failure.

Signed-off-by: Joseph Lo <josephl at nvidia.com>
Signed-off-by: Stephen Warren <swarren at nvidia.com>
---
 arch/arm/mach-tegra/reset-handler.S |    1 +
 arch/arm/mach-tegra/sleep.h         |    3 ++-
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-tegra/reset-handler.S b/arch/arm/mach-tegra/reset-handler.S
index e6de88a..519a8c5 100644
--- a/arch/arm/mach-tegra/reset-handler.S
+++ b/arch/arm/mach-tegra/reset-handler.S
@@ -83,6 +83,7 @@ ENDPROC(tegra_resume)
 
 #ifdef CONFIG_CACHE_L2X0
 	.globl	l2x0_saved_regs_addr
+	.align
 l2x0_saved_regs_addr:
 	.long	0
 #endif
diff --git a/arch/arm/mach-tegra/sleep.h b/arch/arm/mach-tegra/sleep.h
index 4ffae54..8e9b6af 100644
--- a/arch/arm/mach-tegra/sleep.h
+++ b/arch/arm/mach-tegra/sleep.h
@@ -92,7 +92,8 @@
 
 #ifdef CONFIG_CACHE_L2X0
 .macro l2_cache_resume, tmp1, tmp2, tmp3, phys_l2x0_saved_regs
-	adr	\tmp1, \phys_l2x0_saved_regs
+ ARM(	adr	\tmp1, \phys_l2x0_saved_regs )
+ THUMB(	adr.w	\tmp1, \phys_l2x0_saved_regs )
 	ldr	\tmp1, [\tmp1]
 	ldr	\tmp2, [\tmp1, #L2X0_R_PHY_BASE]
 	ldr	\tmp3, [\tmp2, #L2X0_CTRL]
-- 
1.7.10.4



From khilman at linaro.org  Mon Apr 15 19:03:51 2013
From: khilman at linaro.org (Kevin Hilman)
Date: Mon, 15 Apr 2013 16:03:51 -0700
Subject: [V3 patch 00/19] cpuidle: code consolidation
In-Reply-To: <1365770165-27096-1-git-send-email-daniel.lezcano@linaro.org>
 (Daniel Lezcano's message of "Fri, 12 Apr 2013 14:35:46 +0200")
References: <1365770165-27096-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <87k3o38kh4.fsf@linaro.org>

Hi Daniel,

Daniel Lezcano <daniel.lezcano at linaro.org> writes:

> This patchset series provide some code consolidation across the different
> cpuidle drivers. It contains two parts, the first one is the removal of
> the time keeping flag and the second one, is a common initialization routine.

Do you have this series in a branch somewhere (preferrable on top of
Rafael's linux-next) for ease of testing?

Thanks,

Kevin


From jon-hunter at ti.com  Mon Apr 15 19:04:00 2013
From: jon-hunter at ti.com (Jon Hunter)
Date: Mon, 15 Apr 2013 18:04:00 -0500
Subject: [PATCH 3/5] gpio/omap: Add DT support to GPIO driver
In-Reply-To: <516C7C43.3040105@wwwdotorg.org>
References: <1329321854-24490-1-git-send-email-b-cousson@ti.com>
 <CACRpkdYHj-rEF3Rk_CWnmmMw_Amr7m8SgQ=-2zsDYuLeuu3azw@mail.gmail.com>
 <514C79E1.4090106@wwwdotorg.org> <514CE0AB.6060207@ti.com>
 <CACRpkdZmv-rAoKSQYpkHHSMzKJOn5TixVW_P3=m7ZNagBYCUPw@mail.gmail.com>
 <515319D5.20105@wwwdotorg.org>
 <CACRpkdYXVLgCz1Tyu-Ls2V2OTc4R3cGNJhfQJB6Hiz_K9dkZYQ@mail.gmail.com>
 <5155C902.7080207@wwwdotorg.org>
 <CACRpkdYbs4-uudpRUY8e+7icYYkZrfM0kReP3pLL5DMiURJ4dg@mail.gmail.com>
 <5165CB9D.1090202@wwwdotorg.org>
 <CACRpkdYirFNqmGhA4K9CL4ve4NYhs8Rd3SFt1iwW9vHBkrcz8g@mail.gmail.com>
 <51671D7B.5060303@wwwdotorg.org>
 <CACRpkdbf32Ef77GmXk9id9+RRjcDRTr7S+F4nznoeZU8y=BT_Q@mail.gmail.com>
 <51673D70.3010503@wwwdotorg.org>
 <CAAwP0s0e2x33jZQhFRY+Hoo61SFqYKRgWk=1mL2+DNxSDJHz+A@mail.gmail.com>
 <CACRpkda4h+qXTvsirPAS7E7sjXhMLE62q=VDy53W8UchsYjbNg@mail.gmail.com>
 <516C31C3.9040505@wwwdotorg.org> <516C73C6.5050409@ti.co m>
 <516C7C43.3040105@wwwdotorg.org>
Message-ID: <516C8760.2050500@ti.com>


On 04/15/2013 05:16 PM, Stephen Warren wrote:
> On 04/15/2013 03:40 PM, Jon Hunter wrote:
>>
>> On 04/15/2013 11:58 AM, Stephen Warren wrote:
>>> On 04/14/2013 02:53 PM, Linus Walleij wrote:
>>>> On Sun, Apr 14, 2013 at 3:35 AM, Javier Martinez Canillas
>>>> <martinez.javier at gmail.com> wrote:
>>>>
>>>>> Is the following inlined patch [1] what you were thinking that would
>>>>> be the right approach?
>>>>
>>>> This looks sort of OK, but I'm still struggling with the question of
>>>> what we could do to help other implementations facing the same issue.
>>>>
>>>> This is a pretty hard design pattern to properly replicate in every such
>>>> driver is it not?
>>>
>>> Well, instead of adding .request_irq() to the irqchip, and then making
>>> each driver call gpio_request() from the implementation, perhaps you
>>> could add a .irq_to_gpio() to the irqchip, have the IRQ core call that,
>>> and if it gets back a non-error response, the IRQ core could call
>>> gpio_request(). That means that the change to each GPIO+IRQ driver is
>>> simply to implement a standalone data transformation function
>>> .irq_to_gpio().
>>
>> I am still concerned about the case where a driver may have already
>> called gpio_request() and then calls request_irq(). I think that the
>> solution needs to handle cases where the driver may or may not call
>> gpio_request() to allocate the gpio.
> 
> Are there actually drivers that do this? Perhaps they could just be
> fixed not to.

Yes ideally, but my fear is that there are several. I know both omap
display and mmc drivers do this. There are many drivers calling
gpio_direction_input() but I have not looked to see which of those are
just reading state versus configuring an interrupt.

>> Although it could be argued that this is problem is not DT specific,
>> it does become a bigger problem to handle in the case of DT. Therefore,
>> I am wondering if we should just focus on the DT case for now. 
> 
> That doesn't sound like a good idea; this issue is entirely orthogonal
> to DT.

True, but it is proving to be difficult to find a solution that everyone
can agree on.

>>> Now, this does re-introduce irq_to_gpio() in some way, but with the
>>> following advantages:
>>>
>>> 1) The implementation is per-controller, not a single global function,
>>> so isn't introducing any kind of centralized mapping scheme again.
>>>
>>> 2) This irq-chip-specific .irq_to_gpio() would only be implemented for
>>> IRQ+GPIO chips that actually have a 1:1 mapping between GPIOs and IRQs.
>>> Its potential existence doesn't imply that all IRQ chips need implement
>>> this; it would be very specifically be for this one particular case.
>>>
>>> So, I think it's reasonable to introduce this.
>>
>> How about using the gpio irq domain xlate function?
> 
> That translates DT IRQ-specifiers to Linux IRQ numbers. There's no
> reason to believe that, as an absolute rule, it would work for anything
> GPIO-related. The fact that in practice most GPIO+IRQ controllers happen
> to use the same numbering for GPIOs and IRQs is just co-incidence.

Yes but provides a hook where we could call gpio_request(). However, I
am not sure if this would be considered abuse :-p

>> Typically, in DT land a device using a gpio as an interrupt source
>> will have something like the following ...
>>
>> eth at 0 {
>> 	compatible = "ks8851";
>> 	...
>> 	interrupt-parent = <&gpio2>;
>> 	interrupts = <2 8>; /* gpio line 34, low triggered */
>> };
> 
> OK, that really is an interrupt...
> 
>> ... or ...
>>
>> mmc {
>> 	label = "pandaboard::status2";
>>  	gpios = <&gpio1 8 0>;
>> 	...
>> };
> 
> But that's a gpio-leds instance, not an MMC controller... I really
> really hope there's no DT node using "gpios" to mean "interrupts"... And
> it wouldn't make any sense for an on-SoC device anyway.

Oops yes, I overlooked that. However, the omap mmc driver
(drivers/mmc/host/omap_hsmmc.c) does call gpio_request() and
request_threaded_irq() for the mmc card-detect interrupt. I believe
tegra is doing the same ...

sdhci at 78000000 {
	...
	cd-gpios = <&gpio 69 0>; /* gpio PI5 */
	...	
};

>> Both these devices are using a gpio as an interrupt source, but the mmc
>> driver is requesting the gpio directly. In the first case the xlate
>> function for the gpio irq domain will be called where as it is not used
>> in the 2nd case. Therefore, we could add a custom xlate function. For
>> example ...
>>
>> diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
> 
>> +int omap_irq_domain_xlate(struct irq_domain *d, struct device_node *ctrlr,
> ...
>> +       gpio_request_one(irq_to_gpio(bank, intspec[0]), GPIOF_IN, ctrlr->name);
> 
> I guess that could work, but:
> 
> a) It still means doing the gpio_request() in each driver instead of
> centrally.

Right this is device specific, but it avoids exposing irq_to_gpio for a
device. However, we could make this generic if we did expose irq_to_gpio
for each device.

> b) This approach doesn't solve the issue where some client driver has
> already requested the GPIO. This code would simply prevent that call
> from succeeding, which would probably make the driver probe() error out,
> which isn't any different to the equivalent proposed centralized
> gpio_request() inside some request_irq() failing, and causing the
> device's probe() to error out.

If some driver is calling gpio_request() directly, then they will most
likely just call gpio_to_irq() when requesting the interrupt and so the
xlate function would not be called in this case (mmc drivers are a good
example). So I don't see that as being a problem. In fact that's the
benefit of this approach as AFAICT it solves this problem.

Cheers
Jon


From robherring2 at gmail.com  Mon Apr 15 19:59:16 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Mon, 15 Apr 2013 18:59:16 -0500
Subject: [RFC PATCH 1/3] pstore-ram: use write-combine mappings
In-Reply-To: <CAMbhsRS1hnBRoomoiNijrXZB-938d2RSs1cu9EdSfmXD3xpSQg@mail.gmail.com>
References: <1365563297-12480-1-git-send-email-robherring2@gmail.com>
 <CAMbhsRSvQPbzJ7Nt=OSSYE_A1e+eaUjO7XY+qRppJ5_gfWmW4A@mail.gmail.com>
 <51656992.60203@gmail.com>
 <CAMbhsRS1hnBRoomoiNijrXZB-938d2RSs1cu9EdSfmXD3xpSQg@mail.gmail.com>
Message-ID: <516C9454.4060009@gmail.com>

On 04/15/2013 05:21 PM, Colin Cross wrote:
> On Wed, Apr 10, 2013 at 6:30 AM, Rob Herring <robherring2 at gmail.com> wrote:
>> On 04/09/2013 10:53 PM, Colin Cross wrote:
>>> On Tue, Apr 9, 2013 at 8:08 PM, Rob Herring <robherring2 at gmail.com> wrote:
>>>> From: Rob Herring <rob.herring at calxeda.com>
>>>>
>>>> Atomic operations are undefined behavior on ARM for device or strongly
>>>> ordered memory types. So use write-combine variants for mappings. This
>>>> corresponds to normal, non-cacheable memory on ARM. For many other
>>>> architectures, this change should not change the mapping type.
>>>
>>> This is going to make ramconsole less reliable.  A debugging printk
>>> followed by a __raw_writel that causes an immediate hard crash is
>>> likely to lose the last updates, including the most useful message, in
>>> the write buffers.
>>
>> It would have to be a write that hangs the bus. In my experience with
>> AXI, the bus doesn't actually hang until you hit max outstanding
>> transactions.
> 
> I've seen many cases where a single write to device memory in an
> unclocked slave will completely and instantly hang all cpus, and the
> next write will never happen.
> 
>> I think exclusive stores will limit the buffering, but that is probably
>> not architecturally guaranteed.
>>
>> I could put a wb() in at the end of persistent_ram_write.
>>
>>> Also, isn't this patch unnecessary after patch 3 in this set?
>>
>> It is still needed in the main memory case to be architecturally correct
>> to avoid multiple mappings of different memory types and exclusive
>> accesses to device memory. At least on an A9, it doesn't really seem to
>> matter. I could remove this for the ioremap case.
> 
> According to my reading of the latest ARM ARM (Issue C, section
> A3.5.7), and Catalin's excellent explanation
> (http://lists.linaro.org/pipermail/linaro-dev/2012-February/010239.html),
> it is no longer considered unpredictable to have both cached and
> non-cached mappings to the same memory, as long as you use proper
> cache maintenance between accessing the two mappings.
> 
> In pstore_ram the cached mapping will never be accessed (and we don't
> care about speculative accesses), so no cache maintenance is
> necessary.  I don't see any need for this patch, and I see plenty of
> possible problems.

Exclusive accesses still have further restrictions. From section 3.4.5:

? It is IMPLEMENTATION DEFINED whether LDREX and STREX operations can be
performed to a memory region
   with the Device or Strongly-ordered memory attribute. Unless the
implementation documentation explicitly
  states that LDREX and STREX operations to a memory region with the
Device or Strongly-ordered attribute are
 permitted, the effect of such operations is UNPREDICTABLE.


Given that it is implementation defined, I don't see how Linux can rely
on that behavior.

Rob


From sfr at canb.auug.org.au  Mon Apr 15 20:07:15 2013
From: sfr at canb.auug.org.au (Stephen Rothwell)
Date: Tue, 16 Apr 2013 10:07:15 +1000
Subject: adding rpmsg.git to linux next
In-Reply-To: <CAK=WgbY=4rosYr2g3fYYk6WrqXjN7f=5Dk5+D-h3cWrOtVmNag@mail.gmail.com>
References: <CAK=WgbY=4rosYr2g3fYYk6WrqXjN7f=5Dk5+D-h3cWrOtVmNag@mail.gmail.com>
Message-ID: <20130416100715.cd726b96944237ef975ebe7d@canb.auug.org.au>

Hi Ohad,

On Mon, 15 Apr 2013 09:28:17 +0300 Ohad Ben-Cohen <ohad at wizery.com> wrote:
>
> Could you please add:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/ohad/rpmsg.git#for-next
> 
> to linux-next to include new stuff coming from Rob?

Well, you could tell me something about it.  Like what is in it and how
it will be merged up to Linus.  Does this have anything to do with the
remoteproc tree I already include?  Who is the official maintainer (there
is no mention of drivers/rpmsg in the MAINTAINERS file).

-- 
Cheers,
Stephen Rothwell                    sfr at canb.auug.org.au
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130416/9933b11a/attachment.sig>

From festevam at gmail.com  Mon Apr 15 20:18:35 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Mon, 15 Apr 2013 21:18:35 -0300
Subject: [PATCH v2 3/4] ARM: dts: mx53qsb: Add support for parallel display
In-Reply-To: <20130413170943.GX1906@pengutronix.de>
References: <1365516452-1287-1-git-send-email-rogerio.pimentel@freescale.com>
 <1365516452-1287-3-git-send-email-rogerio.pimentel@freescale.com>
 <1365520643.4023.52.camel@pizza.hi.pengutronix.de>
 <CAOkaPuV2xNR=Vxsa6tPdnPS34Q5ffV9-f8DefhcJfvVvXWOADQ@mail.gmail.com>
 <20130413170943.GX1906@pengutronix.de>
Message-ID: <CAOMZO5DwoP4WXEVfKkqbfrJ60s0GxqkLOa_h1TQNJXY61_NTbQ@mail.gmail.com>

Sascha/Phillip,

On Sat, Apr 13, 2013 at 2:09 PM, Sascha Hauer <s.hauer at pengutronix.de> wrote:

> Having the parallel display support is fine. Philipp just suggested to
> add status = "disabled" for both the parallel display and the lvds
> encoder so that for example the bootloader can decide which one to enable
> during runtime. Otherwise we have two display options on the same pins and
> the first one wins.

Ok, understood.

It is not clear how we can tell the bootloader that we want the CLAA
WVGA panel or the HDMI daughter card, for example?

What would be the kernel command line in each case?

Thanks,

Fabio Estevam


From timur at tabi.org  Mon Apr 15 20:25:43 2013
From: timur at tabi.org (Timur Tabi)
Date: Mon, 15 Apr 2013 19:25:43 -0500
Subject: [PATCH v3 00/15] ASoC: fsl-ssi: ac97-slave support
In-Reply-To: <516A9D5B.2070707@metafoo.de>
References: <1365939779-4507-1-git-send-email-mpa@pengutronix.de>
 <516A9D5B.2070707@metafoo.de>
Message-ID: <516C9A87.4090307@tabi.org>

Lars-Peter Clausen wrote:
>> >@Lars:
>> >There are 4 new patches at the beginning of the series that fix some problems
>> >of your cleanups. I think they were in the changes you posted. If not, could you
>> >please add them to your branch?
> Hi,
>
> I had already fixed them localy. I'm in the process of polishing the last bits
> and pieces of my generic dmaengine PCM driver series right now and will submit
> it later today.

So which repository should I apply these patches to?  I want to make sure 
they don't break PowerPC.

-- 
Timur Tabi


From geoff at infradead.org  Mon Apr 15 20:26:36 2013
From: geoff at infradead.org (Geoff Levand)
Date: Mon, 15 Apr 2013 17:26:36 -0700
Subject: [PATCH] ARM: KVM: iterate over all CPUs for CPU compatibility
 check
In-Reply-To: <CAEDV+g+E8PLc60vMRhq4O_AL2WjmYDLb6=Wh34ynhevh7uAGJA@mail.gmail.com>
References: <1365771875-5788-1-git-send-email-andre.przywara@linaro.org>
 <51680AF9.7040109@arm.com>
 <CAEDV+g+E8PLc60vMRhq4O_AL2WjmYDLb6=Wh34ynhevh7uAGJA@mail.gmail.com>
Message-ID: <1366071996.10931.15.camel@smoke>

On Sun, 2013-04-14 at 21:57 -0700, Christoffer Dall wrote:
> On Fri, Apr 12, 2013 at 6:24 AM, Marc Zyngier <marc.zyngier at arm.com> wrote:
> Nak. The fact that one of the CPUs seem to hang is a sure sign that
> > something is severely broken, and you definitely want to fix that issue,
> > instead of blindly ignoring it.
> >
> > Additionally, it seems you're just papering over the issue. You should
> > be able to exclude the A7 processors, but not completely deny KVM from
> > running on the hardware.
> >
> Marc, I disagree with this nak. If the current kernel breaks boot on a
> Big.Little system, we need to take care of that first, and the
> proposed patch is a quick way to do so, and it does not stand in the
> way of introducing proper Big.Little support in any way, which I'm
> sure is going to open up a lot of other interesting questions.
> 
> I'm going to take this one.

Since this problem will cause the 3.9 kernel to hang then a workaround
like this should go in.  There isn't enough time to do a proper fix for
3.9, and even if it could be done I think it would be too intrusive to
get merged this late.

-Geoff




From ccross at android.com  Mon Apr 15 20:43:09 2013
From: ccross at android.com (Colin Cross)
Date: Mon, 15 Apr 2013 17:43:09 -0700
Subject: [RFC PATCH 1/3] pstore-ram: use write-combine mappings
In-Reply-To: <516C9454.4060009@gmail.com>
References: <1365563297-12480-1-git-send-email-robherring2@gmail.com>
 <CAMbhsRSvQPbzJ7Nt=OSSYE_A1e+eaUjO7XY+qRppJ5_gfWmW4A@mail.gmail.com>
 <51656992.60203@gmail.com>
 <CAMbhsRS1hnBRoomoiNijrXZB-938d2RSs1cu9EdSfmXD3xpSQg@mail.gmail.com>
 <516C9454.4060009@gmail.com>
Message-ID: <CAMbhsRRT7tOBHppvjJEW5wRtVaUhwxr8=YQY=Sy0VAFeBg1JmQ@mail.gmail.com>

On Mon, Apr 15, 2013 at 4:59 PM, Rob Herring <robherring2 at gmail.com> wrote:
> On 04/15/2013 05:21 PM, Colin Cross wrote:
>> On Wed, Apr 10, 2013 at 6:30 AM, Rob Herring <robherring2 at gmail.com> wrote:
>>> On 04/09/2013 10:53 PM, Colin Cross wrote:
>>>> On Tue, Apr 9, 2013 at 8:08 PM, Rob Herring <robherring2 at gmail.com> wrote:
>>>>> From: Rob Herring <rob.herring at calxeda.com>
>>>>>
>>>>> Atomic operations are undefined behavior on ARM for device or strongly
>>>>> ordered memory types. So use write-combine variants for mappings. This
>>>>> corresponds to normal, non-cacheable memory on ARM. For many other
>>>>> architectures, this change should not change the mapping type.
>>>>
>>>> This is going to make ramconsole less reliable.  A debugging printk
>>>> followed by a __raw_writel that causes an immediate hard crash is
>>>> likely to lose the last updates, including the most useful message, in
>>>> the write buffers.
>>>
>>> It would have to be a write that hangs the bus. In my experience with
>>> AXI, the bus doesn't actually hang until you hit max outstanding
>>> transactions.
>>
>> I've seen many cases where a single write to device memory in an
>> unclocked slave will completely and instantly hang all cpus, and the
>> next write will never happen.
>>
>>> I think exclusive stores will limit the buffering, but that is probably
>>> not architecturally guaranteed.
>>>
>>> I could put a wb() in at the end of persistent_ram_write.
>>>
>>>> Also, isn't this patch unnecessary after patch 3 in this set?
>>>
>>> It is still needed in the main memory case to be architecturally correct
>>> to avoid multiple mappings of different memory types and exclusive
>>> accesses to device memory. At least on an A9, it doesn't really seem to
>>> matter. I could remove this for the ioremap case.
>>
>> According to my reading of the latest ARM ARM (Issue C, section
>> A3.5.7), and Catalin's excellent explanation
>> (http://lists.linaro.org/pipermail/linaro-dev/2012-February/010239.html),
>> it is no longer considered unpredictable to have both cached and
>> non-cached mappings to the same memory, as long as you use proper
>> cache maintenance between accessing the two mappings.
>>
>> In pstore_ram the cached mapping will never be accessed (and we don't
>> care about speculative accesses), so no cache maintenance is
>> necessary.  I don't see any need for this patch, and I see plenty of
>> possible problems.
>
> Exclusive accesses still have further restrictions. From section 3.4.5:
>
> ? It is IMPLEMENTATION DEFINED whether LDREX and STREX operations can be
> performed to a memory region
>    with the Device or Strongly-ordered memory attribute. Unless the
> implementation documentation explicitly
>   states that LDREX and STREX operations to a memory region with the
> Device or Strongly-ordered attribute are
>  permitted, the effect of such operations is UNPREDICTABLE.
>
>
> Given that it is implementation defined, I don't see how Linux can rely
> on that behavior.

I see, the problem is that while noncached and writecombined appear to
be similar mappings, noncached is mapped in PRRR to strongly-ordered,
while writecombined is mapped to unbufferable normal memory.

I think adding a wmb() to persistent_ram_write is going to be
expensive on cpus with outer caches like the L2X0, where wmb() will
result in a spinlock.  Is there a real SoC where this doesn't work?


From sfr at canb.auug.org.au  Mon Apr 15 20:55:13 2013
From: sfr at canb.auug.org.au (Stephen Rothwell)
Date: Tue, 16 Apr 2013 10:55:13 +1000
Subject: [PATCH] clk: si5351: make clk-si5351 depend on CONFIG_OF
In-Reply-To: <1366009214-32234-1-git-send-email-sebastian.hesselbarth@gmail.com>
References: <1366009214-32234-1-git-send-email-sebastian.hesselbarth@gmail.com>
Message-ID: <20130416105513.913219ac889b1db952876197@canb.auug.org.au>

Hi Sebastian,

On Mon, 15 Apr 2013 09:00:14 +0200 Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com> wrote:
>
> Calling clk-si5351 driver non-OF ready was too early. This patch
> makes clk-si5351 depend on CONFIG_OF again, until things get sorted out.
> 
> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
> Reported-by: Stephen Rottweil <sfr at canb.auug.org.au>

My name is spelt "Rothwell" (as in the Cc: line below) :-(

> ---
> Cc: Stephen Rothwell <sfr at canb.auug.org.au>

-- 
Cheers,
Stephen Rothwell                    sfr at canb.auug.org.au
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130416/08cfb712/attachment.sig>

From zhangwm at marvell.com  Mon Apr 15 21:55:17 2013
From: zhangwm at marvell.com (Neil Zhang)
Date: Mon, 15 Apr 2013 18:55:17 -0700
Subject: [PATCH 1/4] ARM: mmp: add wakeup function for ICU
References: <1365651463-11502-1-git-send-email-zhangwm@marvell.com>
 <1365651463-11502-2-git-send-email-zhangwm@marvell.com>
 <CAN1soZwFJybMUZgxZJyXcDdKXbpQxaVntyZd8oGnQivLF=ZNNA@mail.gmail.com> 
Message-ID: <175CCF5F49938B4D99B2E3EF7F558EBE2D0FB04F2B@SC-VEXCH4.marvell.com>

Haojian,

> -----Original Message-----
> From: Neil Zhang
> Sent: 2013?4?15? 19:10
> To: 'Haojian Zhuang'
> Cc: Grant Likely; linux-arm-kernel at lists.infradead.org;
> linux-kernel at vger.kernel.org; Chao Xie
> Subject: RE: [PATCH 1/4] ARM: mmp: add wakeup function for ICU
> 
> 
> 
> 
> 
> > -----Original Message-----
> > From: Haojian Zhuang [mailto:haojian.zhuang at gmail.com]
> > Sent: 2013?4?13? 20:50
> > To: Neil Zhang
> > Cc: Grant Likely; linux-arm-kernel at lists.infradead.org;
> > linux-kernel at vger.kernel.org; Chao Xie
> > Subject: Re: [PATCH 1/4] ARM: mmp: add wakeup function for ICU
> >
> > On Thu, Apr 11, 2013 at 11:37 AM, Neil Zhang <zhangwm at marvell.com>
> > wrote:
> > > From: Chao Xie <chao.xie at marvell.com>
> > >
> > > PXA988 will use GIC as its interrupt controller, and ICU is used as
> > > wakeup logic. When AP subsystem is powered off, GIC will lose its
> > > context, the PMU will need ICU to wakeup the AP subsystem.
> > > When ICU works as wakeup logic, there is no need to know
> > > intc-nr-irqs, change the corresponding code.
> > >
> > > Signed-off-by: Chao Xie <chao.xie at marvell.com>
> > > Signed-off-by: Neil Zhang <zhangwm at marvell.com>
> > > ---
> > >  .../devicetree/bindings/arm/mrvl/intc.txt          |    9 ++++
> > >  arch/arm/mach-mmp/irq.c                            |   51
> > ++++++++++++++++----
> > >  2 files changed, 50 insertions(+), 10 deletions(-)
> > >
> > > diff --git a/Documentation/devicetree/bindings/arm/mrvl/intc.txt
> > > b/Documentation/devicetree/bindings/arm/mrvl/intc.txt
> > > index 8b53273..58c0e74 100644
> > > --- a/Documentation/devicetree/bindings/arm/mrvl/intc.txt
> > > +++ b/Documentation/devicetree/bindings/arm/mrvl/intc.txt
> > > @@ -15,6 +15,8 @@ Required properties:
> > >  - interrupt-controller : Identifies the node as an interrupt controller.
> > >  - #interrupt-cells : Specifies the number of cells needed to encode an
> > >    interrupt source.
> > > +- mrvl,intc-wakeup : Specifies the address and value for global
> > > +mask in the
> > > +  interrupt controller.
> > >  - mrvl,intc-nr-irqs : Specifies the number of interrupts in the interrupt
> > >    controller.
> > >  - mrvl,clr-mfp-irq : Specifies the interrupt that needs to clear
> > > MFP edge @@ -39,6 +41,13 @@ Example:
> > >                 mrvl,intc-nr-irqs = <2>;
> > >         };
> > >
> > > +       intc: interrupt-controller at d4282000 {
> > > +               compatible = "mrvl,mmp-intc";
> > > +               reg = <0xd4282000 0x1000>;
> > > +               mrvl,intc-wakeup = <0x114 0x3
> > > +                                   0x144 0x3>;
> > > +       };
> > > +
> > >  * Marvell Orion Interrupt controller
> > >
> > >  Required properties
> > > diff --git a/arch/arm/mach-mmp/irq.c b/arch/arm/mach-mmp/irq.c
> index
> > > 3c71246..b8df948 100644
> > > --- a/arch/arm/mach-mmp/irq.c
> > > +++ b/arch/arm/mach-mmp/irq.c
> > > @@ -16,6 +16,7 @@
> > >  #include <linux/init.h>
> > >  #include <linux/irq.h>
> > >  #include <linux/irqdomain.h>
> > > +#include <linux/irqchip/arm-gic.h>
> > >  #include <linux/io.h>
> > >  #include <linux/ioport.h>
> > >  #include <linux/of_address.h>
> > > @@ -57,6 +58,7 @@ struct mmp_intc_conf {  void __iomem
> > *mmp_icu_base;
> > > static struct icu_chip_data icu_data[MAX_ICU_NR];  static int
> > > max_icu_nr;
> > > +static bool mmp_icu_wakeup;
> > >
> > >  extern void mmp2_clear_pmic_int(void);
> > >
> > > @@ -91,8 +93,11 @@ static void icu_mask_irq(struct irq_data *d)
> > >         int hwirq;
> > >         u32 r;
> > >
> > > -       hwirq = d->irq - data->virq_base;
> > > -       if (data == &icu_data[0]) {
> > > +       if (mmp_icu_wakeup)
> > > +               hwirq = d->hwirq;
> > > +       else
> > > +               hwirq = d->irq - data->virq_base;
> > > +       if (data == &icu_data[0] || mmp_icu_wakeup) {
> > >                 r = readl_relaxed(mmp_icu_base + (hwirq << 2));
> > >                 r &= ~data->conf_mask;
> > >                 r |= data->conf_disable; @@ -110,8 +115,11 @@
> > static
> > > void icu_unmask_irq(struct irq_data *d)
> > >         int hwirq;
> > >         u32 r;
> > >
> > > -       hwirq = d->irq - data->virq_base;
> > > -       if (data == &icu_data[0]) {
> > > +       if (mmp_icu_wakeup)
> > > +               hwirq = d->hwirq;
> > > +       else
> > > +               hwirq = d->irq - data->virq_base;
> > > +       if (data == &icu_data[0] || mmp_icu_wakeup) {
> > >                 r = readl_relaxed(mmp_icu_base + (hwirq << 2));
> > >                 r &= ~data->conf_mask;
> > >                 r |= data->conf_enable; @@ -415,6 +423,8 @@
> void
> > > __init mmp_dt_irq_init(void)
> > >         const struct of_device_id *of_id;
> > >         struct mmp_intc_conf *conf;
> > >         int nr_irqs, irq_base, ret, irq;
> > > +       const __be32 *wakeup_reg;
> > > +       int size, i;
> > >
> > >         node = of_find_matching_node(NULL, intc_ids);
> > >         if (!node) {
> > > @@ -424,18 +434,39 @@ void __init mmp_dt_irq_init(void)
> > >         of_id = of_match_node(intc_ids, node);
> > >         conf = of_id->data;
> > >
> > > -       ret = of_property_read_u32(node, "mrvl,intc-nr-irqs",
> &nr_irqs);
> > > -       if (ret) {
> > > -               pr_err("Not found mrvl,intc-nr-irqs property\n");
> > > -               return;
> > > -       }
> > > -
> > >         mmp_icu_base = of_iomap(node, 0);
> > >         if (!mmp_icu_base) {
> > >                 pr_err("Failed to get interrupt controller register\n");
> > >                 return;
> > >         }
> > >
> > > +       /* ICU is only used as wake up logic. */
> > > +       wakeup_reg = of_get_property(node, "mrvl,intc-wakeup",
> &size);
> > > +       if (wakeup_reg) {
> > > +               mmp_icu_wakeup = 1;
> > > +               size /= sizeof(*wakeup_reg);
> > > +               i = 0;
> > > +               /* disable the global irq/fiq in icu for all cores. */
> > > +               while (i < size) {
> > > +                       unsigned offset, val;
> > > +
> > > +                       offset = be32_to_cpup(wakeup_reg + i++);
> > > +                       val = be32_to_cpup(wakeup_reg + i++);
> > > +                       writel_relaxed(val, mmp_icu_base +
> offset);
> > > +               }
> > > +
> > > +               gic_arch_extn.irq_mask = icu_mask_irq;
> > > +               gic_arch_extn.irq_unmask = icu_unmask_irq;
> > > +
> > > +               return;
> > > +       }
> >
> > Since it's totally different from original ICU irq initialization, I
> > suggest to create a new entry to handle this kind of wakeup event. And
> > we could create a new mask/unmask function.
> 
> Ok, I'll update it.
Are you OK if use icu_mask_irq_wakeup / icu_unmask_irq_wakeup for the new functions.
> 
> >
> > > +
> > > +       ret = of_property_read_u32(node, "mrvl,intc-nr-irqs",
> &nr_irqs);
> > > +       if (ret) {
> > > +               pr_err("Not found mrvl,intc-nr-irqs property\n");
> > > +               return;
> > > +       }
> > > +
> > >         irq_base = irq_alloc_descs(-1, 0, nr_irqs - NR_IRQS_LEGACY,
> 0);
> > >         if (irq_base < 0) {
> > >                 pr_err("Failed to allocate IRQ numbers\n");
> > > --
> > > 1.7.4.1
> > >
> 
> Best Regards,
> Neil Zhang

Best Regards,
Neil Zhang

From horms at verge.net.au  Mon Apr 15 22:35:22 2013
From: horms at verge.net.au (Simon Horman)
Date: Tue, 16 Apr 2013 11:35:22 +0900
Subject: [PATCH] arm: shmobile: armadillo800eva: Fix maximum number of SCIF
In-Reply-To: <1366001092-8753-1-git-send-email-nobuhiro.iwamatsu.yj@renesas.com>
References: <1366001092-8753-1-git-send-email-nobuhiro.iwamatsu.yj@renesas.com>
Message-ID: <20130416023522.GA28660@verge.net.au>

On Mon, Apr 15, 2013 at 01:44:52PM +0900, Nobuhiro Iwamatsu wrote:
> The r8a77740 has 9ch SCIF. It is not 8ch.

Thanks, queued up for v3.11 in the defconfig-armadillo800eva branch.
I plan to push that branch later today.


From horms at verge.net.au  Mon Apr 15 22:41:46 2013
From: horms at verge.net.au (Simon Horman)
Date: Tue, 16 Apr 2013 11:41:46 +0900
Subject: [RFC PATCH 2/2] ARM: DT: kernel: DT cpu node bindings update
In-Reply-To: <1366042402-8987-3-git-send-email-lorenzo.pieralisi@arm.com>
References: <1366042402-8987-1-git-send-email-lorenzo.pieralisi@arm.com>
 <1366042402-8987-3-git-send-email-lorenzo.pieralisi@arm.com>
Message-ID: <20130416024146.GG28660@verge.net.au>

On Mon, Apr 15, 2013 at 05:13:22PM +0100, Lorenzo Pieralisi wrote:
> In order to extend the current cpu nodes bindings to newer CPUs
> inclusive of AArch64 and to update support for older ARM CPUs this
> patch updates device tree documentation for the cpu nodes bindings.
> 
> Main changes:
> 
> - adds 64-bit bindings (inclusive of cpus node #address-cells updates)
> - defines behaviour on pre and post v7 uniprocessor systems
> - adds ARM 11MPcore specific reg property definition
> 
> DT cpu map parsing code must be made compliant with the latest bindings
> updates, hence this patch also updates the arm_dt_init_cpu_maps() function
> with checks and additional parsing rules.
> 
> Uniprocessor systems predating v7 do not parse the cpus node at all
> since the reg property is meaningless on those systems.
> 
> Device trees for 64-bit systems can be taken as device tree input also
> for 64-bit CPUs running in 32-bit mode. The code checks that the reg entries
> are zeroed as required in the respective fields and detects automatically
> the cpus node #address-cells value so that device tree written for
> 64-bit ARM platforms (cpus #address-cells == 2) can still be taken as
> input. The correct device tree entries are to be set up by the boot
> loader, kernel code just checks that device tree entries in the cpus
> node are as expected for a 32-bit CPU (reg[63:24] == 0).
> 
> cpu node entries with invalid reg property or containing duplicates are
> ignored and the device tree parsing is not stopped anymore when such
> entries are encountered, the device tree cpu entry is just skipped.
> 
> A device tree with cpu nodes missing the boot CPU MPIDR is considered a
> hard error and the kernel flags this up as a bug to force firmware updates.
> 
> The updates to cpus/cpu node bindings for ARM require all in-kernel dts files
> present in the mainline to be made compliant to the latest specification.
> 
> This patch also updates ARM in-kernel non-compliant dts files to the latest
> cpus/cpu nodes bindings specification.
> 
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
> ---
>  Documentation/devicetree/bindings/arm/cpus.txt | 335 +++++++++++++++++++++----
>  arch/arm/boot/dts/exynos5440.dtsi              |   7 +
>  arch/arm/boot/dts/omap3.dtsi                   |   4 +
>  arch/arm/boot/dts/omap4.dtsi                   |   5 +
>  arch/arm/boot/dts/omap5.dtsi                   |   5 +
>  arch/arm/boot/dts/r8a7740.dtsi                 |   3 +
>  arch/arm/boot/dts/sh7372.dtsi                  |   4 +

I would prefer if the SoC updates, in particular the sh7372 portion,
was a separate patch.

>  arch/arm/boot/dts/sunxi.dtsi                   |   4 +
>  arch/arm/kernel/devtree.c                      |  82 +++---
>  9 files changed, 377 insertions(+), 72 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt
> index f32494d..b1ef3d8 100644
> --- a/Documentation/devicetree/bindings/arm/cpus.txt
> +++ b/Documentation/devicetree/bindings/arm/cpus.txt
> @@ -1,4 +1,6 @@
> -* ARM CPUs binding description
> +=============================
> +ARM CPUs bindings description
> +=============================
>  
>  The device tree allows to describe the layout of CPUs in a system through
>  the "cpus" node, which in turn contains a number of subnodes (ie "cpu")
> @@ -8,70 +10,317 @@ Bindings for CPU nodes follow the ePAPR standard, available from:
>  
>  http://devicetree.org
>  
> -For the ARM architecture every CPU node must contain the following properties:
> -
> -- device_type:	must be "cpu"
> -- reg:		property matching the CPU MPIDR[23:0] register bits
> -		reg[31:24] bits must be set to 0
> -- compatible:	should be one of:
> -		"arm,arm1020"
> -		"arm,arm1020e"
> -		"arm,arm1022"
> -		"arm,arm1026"
> -		"arm,arm720"
> -		"arm,arm740"
> -		"arm,arm7tdmi"
> -		"arm,arm920"
> -		"arm,arm922"
> -		"arm,arm925"
> -		"arm,arm926"
> -		"arm,arm940"
> -		"arm,arm946"
> -		"arm,arm9tdmi"
> -		"arm,cortex-a5"
> -		"arm,cortex-a7"
> -		"arm,cortex-a8"
> -		"arm,cortex-a9"
> -		"arm,cortex-a15"
> -		"arm,arm1136"
> -		"arm,arm1156"
> -		"arm,arm1176"
> -		"arm,arm11mpcore"
> -		"faraday,fa526"
> -		"intel,sa110"
> -		"intel,sa1100"
> -		"marvell,feroceon"
> -		"marvell,mohawk"
> -		"marvell,xsc3"
> -		"marvell,xscale"
> -
> -Example:
> +with updates for 32-bit and 64-bit ARM systems provided in this document.
> +
> +In the bindings below:
> +
> +- square brackets define bitfields, eg reg[7:0] value of the bitfield in
> +  the reg property contained in bits 7 down to 0
> +
> +- cpus node
> +
> +	Description: Container of cpu nodes
> +
> +	The node name must be "cpus".
> +
> +	A cpus node must define the following properties:
> +
> +	- #address-cells
> +		Usage: required
> +		Value type: <u32>
> +		Definition: must be set to 1 for 32-bit systems and 2 for
> +			    64-bit systems
> +	- #size-cells
> +		Usage: required
> +		Value type: <u32>
> +		Definition: must be set to 0
> +
> +- cpu node
> +
> +	Description: Describes a CPU in an ARM based system
> +
> +	PROPERTIES
> +
> +	- device_type
> +		Usage: required
> +		Value type: <string>
> +		Definition: must be "cpu"
> +	- reg
> +		Usage and definition depend on ARM architecture version and
> +		configuration:
> +
> +			# On uniprocessor ARM architectures previous to v7
> +			  this property is optional since they do not define
> +			  any register that provides a CPU identifier.
> +			  Any value set in the reg property for these CPUs
> +			  should be ignored.
> +
> +			# On ARM 11 MPcore based systems this property is
> +			  required and matches the CPUID[11:0] register bits.
> +
> +			  Bits [11:0] in the reg cell must be set to
> +			  bits [11:0] in CPU ID register.
> +
> +			  All other bits in the reg cell must be set to 0.
> +
> +			# On ARM architecture versions >= 7 based 32-bit
> +			  systems this property is required and matches the
> +			  CPU MPIDR[23:0] register bits.
> +
> +			  Bits [23:0] in the reg cell must be set to
> +			  bits [23:0] in MPIDR.
> +
> +			  All other bits in the reg cell must be set to 0.
> +
> +			# On ARM v8 64-bit systems, where the reg property
> +			  is made up of two cells to accomodate the 64-bit
> +			  MPDIR_EL1 register this property is required and
> +			  matches:
> +
> +			  The first reg cell bits [7:0] must be set to
> +			  bits [39:32] of MPIDR_EL1.
> +
> +			  The second reg cell bits [23:0] must be set to
> +			  bits [23:0] of MPIDR_EL1.
> +
> +			  All other bits in the reg cells must be set to 0.
> +	- compatible:
> +		Usage: required
> +		Value type: <string>
> +		Definition: should be one of:
> +			    "arm,arm1020"
> +			    "arm,arm1020e"
> +			    "arm,arm1022"
> +			    "arm,arm1026"
> +			    "arm,arm720"
> +			    "arm,arm740"
> +			    "arm,arm7tdmi"
> +			    "arm,arm920"
> +			    "arm,arm922"
> +			    "arm,arm925"
> +			    "arm,arm926"
> +			    "arm,arm940"
> +			    "arm,arm946"
> +			    "arm,arm9tdmi"
> +			    "arm,cortex-a5"
> +			    "arm,cortex-a7"
> +			    "arm,cortex-a8"
> +			    "arm,cortex-a9"
> +			    "arm,cortex-a15"
> +			    "arm,cortex-a57"
> +			    "arm,arm1136"
> +			    "arm,arm1156"
> +			    "arm,arm1176"
> +			    "arm,arm11mpcore"
> +			    "faraday,fa526"
> +			    "intel,sa110"
> +			    "intel,sa1100"
> +			    "marvell,feroceon"
> +			    "marvell,mohawk"
> +			    "marvell,xsc3"
> +			    "marvell,xscale"
> +	- enable-method
> +		Usage: required on ARM 64-bit systems, optional on ARM 32-bit
> +		       systems
> +		Value type: <string>
> +		Definition: On ARM 64-bit systems must be "spin-table" [1].
> +
> +	- cpu-release-addr
> +		Usage: required on ARM 64-bit systems, optional on ARM 32-bit
> +		       systems
> +		Value type: <prop-encoded-array>
> +		Definition: On ARM 64-bit systems must be a two cell
> +			    property identifying a 64-bit zero-initialised
> +			    memory location [1].
> +
> +Example 1 (dual-cluster big.LITTLE system 32-bit):
>  
>  	cpus {
>  		#size-cells = <0>;
>  		#address-cells = <1>;
>  
> -		CPU0: cpu at 0 {
> +		cpu at 0 {
>  			device_type = "cpu";
>  			compatible = "arm,cortex-a15";
>  			reg = <0x0>;
>  		};
>  
> -		CPU1: cpu at 1 {
> +		cpu at 1 {
>  			device_type = "cpu";
>  			compatible = "arm,cortex-a15";
>  			reg = <0x1>;
>  		};
>  
> -		CPU2: cpu at 100 {
> +		cpu at 100 {
>  			device_type = "cpu";
>  			compatible = "arm,cortex-a7";
>  			reg = <0x100>;
>  		};
>  
> -		CPU3: cpu at 101 {
> +		cpu at 101 {
>  			device_type = "cpu";
>  			compatible = "arm,cortex-a7";
>  			reg = <0x101>;
>  		};
>  	};
> +
> +Example 2 (Cortex-A8 uniprocessor 32-bit system):
> +
> +	cpus {
> +		#size-cells = <0>;
> +		#address-cells = <1>;
> +
> +		cpu at 0 {
> +			device_type = "cpu";
> +			compatible = "arm,cortex-a8";
> +			reg = <0x0>;
> +		};
> +
> +	};
> +
> +Example 3 (ARM 1176 uniprocessor 32-bit system):
> +
> +	cpus {
> +		cpu {
> +			device_type = "cpu";
> +			compatible = "arm,arm1176";
> +		};
> +	};
> +
> +Example 4 (ARM Cortex-A57 64-bit system):
> +
> +cpus {
> +	#size-cells = <0>;
> +	#address-cells = <2>;
> +
> +	cpu at 0 {
> +		device_type = "cpu";
> +		compatible = "arm,cortex-a57";
> +		reg = <0x0 0x0>;
> +		enable-method = "spin-table";
> +		cpu-release-addr = <0 0x20000000>;
> +	};
> +
> +	cpu at 1 {
> +		device_type = "cpu";
> +		compatible = "arm,cortex-a57";
> +		reg = <0x0 0x1>;
> +		enable-method = "spin-table";
> +		cpu-release-addr = <0 0x20000000>;
> +	};
> +
> +	cpu at 100 {
> +		device_type = "cpu";
> +		compatible = "arm,cortex-a57";
> +		reg = <0x0 0x100>;
> +		enable-method = "spin-table";
> +		cpu-release-addr = <0 0x20000000>;
> +	};
> +
> +	cpu at 101 {
> +		device_type = "cpu";
> +		compatible = "arm,cortex-a57";
> +		reg = <0x0 0x101>;
> +		enable-method = "spin-table";
> +		cpu-release-addr = <0 0x20000000>;
> +	};
> +
> +	cpu at 10000 {
> +		device_type = "cpu";
> +		compatible = "arm,cortex-a57";
> +		reg = <0x0 0x10000>;
> +		enable-method = "spin-table";
> +		cpu-release-addr = <0 0x20000000>;
> +	};
> +
> +	cpu at 10001 {
> +		device_type = "cpu";
> +		compatible = "arm,cortex-a57";
> +		reg = <0x0 0x10001>;
> +		enable-method = "spin-table";
> +		cpu-release-addr = <0 0x20000000>;
> +	};
> +
> +	cpu at 10100 {
> +		device_type = "cpu";
> +		compatible = "arm,cortex-a57";
> +		reg = <0x0 0x10100>;
> +		enable-method = "spin-table";
> +		cpu-release-addr = <0 0x20000000>;
> +	};
> +
> +	cpu at 10101 {
> +		device_type = "cpu";
> +		compatible = "arm,cortex-a57";
> +		reg = <0x0 0x10101>;
> +		enable-method = "spin-table";
> +		cpu-release-addr = <0 0x20000000>;
> +	};
> +
> +	cpu at 100000000 {
> +		device_type = "cpu";
> +		compatible = "arm,cortex-a57";
> +		reg = <0x1 0x0>;
> +		enable-method = "spin-table";
> +		cpu-release-addr = <0 0x20000000>;
> +	};
> +
> +	cpu at 100000001 {
> +		device_type = "cpu";
> +		compatible = "arm,cortex-a57";
> +		reg = <0x1 0x1>;
> +		enable-method = "spin-table";
> +		cpu-release-addr = <0 0x20000000>;
> +	};
> +
> +	cpu at 100000100 {
> +		device_type = "cpu";
> +		compatible = "arm,cortex-a57";
> +		reg = <0x1 0x100>;
> +		enable-method = "spin-table";
> +		cpu-release-addr = <0 0x20000000>;
> +	};
> +
> +	cpu at 100000101 {
> +		device_type = "cpu";
> +		compatible = "arm,cortex-a57";
> +		reg = <0x1 0x101>;
> +		enable-method = "spin-table";
> +		cpu-release-addr = <0 0x20000000>;
> +	};
> +
> +	cpu at 100010000 {
> +		device_type = "cpu";
> +		compatible = "arm,cortex-a57";
> +		reg = <0x1 0x10000>;
> +		enable-method = "spin-table";
> +		cpu-release-addr = <0 0x20000000>;
> +	};
> +
> +	cpu at 100010001 {
> +		device_type = "cpu";
> +		compatible = "arm,cortex-a57";
> +		reg = <0x1 0x10001>;
> +		enable-method = "spin-table";
> +		cpu-release-addr = <0 0x20000000>;
> +	};
> +
> +	cpu at 100010100 {
> +		device_type = "cpu";
> +		compatible = "arm,cortex-a57";
> +		reg = <0x1 0x10100>;
> +		enable-method = "spin-table";
> +		cpu-release-addr = <0 0x20000000>;
> +	};
> +
> +	cpu at 100010101 {
> +		device_type = "cpu";
> +		compatible = "arm,cortex-a57";
> +		reg = <0x1 0x10101>;
> +		enable-method = "spin-table";
> +		cpu-release-addr = <0 0x20000000>;
> +	};
> +};
> +===============================================================================
> +[1] ARM Linux kernel documentation
> +    Documentation/devicetree/bindings/arm64/booting.txt
> diff --git a/arch/arm/boot/dts/exynos5440.dtsi b/arch/arm/boot/dts/exynos5440.dtsi
> index 5f3562a..eda21d5 100644
> --- a/arch/arm/boot/dts/exynos5440.dtsi
> +++ b/arch/arm/boot/dts/exynos5440.dtsi
> @@ -24,8 +24,12 @@
>  	};
>  
>  	cpus {
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
>  		cpu at 0 {
>  			compatible = "arm,cortex-a15";
> +			reg = <0x0>;
>  			timer {
>  				compatible = "arm,armv7-timer";
>  				interrupts = <1 13 0xf08>;
> @@ -34,6 +38,7 @@
>  		};
>  		cpu at 1 {
>  			compatible = "arm,cortex-a15";
> +			reg = <0x1>;
>  			timer {
>  				compatible = "arm,armv7-timer";
>  				interrupts = <1 14 0xf08>;
> @@ -42,6 +47,7 @@
>  		};
>  		cpu at 2 {
>  			compatible = "arm,cortex-a15";
> +			reg = <0x2>;
>  			timer {
>  				compatible = "arm,armv7-timer";
>  				interrupts = <1 14 0xf08>;
> @@ -50,6 +56,7 @@
>  		};
>  		cpu at 3 {
>  			compatible = "arm,cortex-a15";
> +			reg = <0x3>;
>  			timer {
>  				compatible = "arm,armv7-timer";
>  				interrupts = <1 14 0xf08>;
> diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
> index 1acc261..b4e2b8d 100644
> --- a/arch/arm/boot/dts/omap3.dtsi
> +++ b/arch/arm/boot/dts/omap3.dtsi
> @@ -21,8 +21,12 @@
>  	};
>  
>  	cpus {
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
>  		cpu at 0 {
>  			compatible = "arm,cortex-a8";
> +			reg = <0x0>;
>  		};
>  	};
>  
> diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
> index 739bb79..9c5f7c2 100644
> --- a/arch/arm/boot/dts/omap4.dtsi
> +++ b/arch/arm/boot/dts/omap4.dtsi
> @@ -28,13 +28,18 @@
>  	};
>  
>  	cpus {
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
>  		cpu at 0 {
>  			compatible = "arm,cortex-a9";
>  			next-level-cache = <&L2>;
> +			reg = <0x0>;
>  		};
>  		cpu at 1 {
>  			compatible = "arm,cortex-a9";
>  			next-level-cache = <&L2>;
> +			reg = <0x1>;
>  		};
>  	};
>  
> diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
> index 790bb2a..d2106b6 100644
> --- a/arch/arm/boot/dts/omap5.dtsi
> +++ b/arch/arm/boot/dts/omap5.dtsi
> @@ -31,8 +31,12 @@
>  	};
>  
>  	cpus {
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
>  		cpu at 0 {
>  			compatible = "arm,cortex-a15";
> +			reg = <0x0>;
>  			timer {
>  				compatible = "arm,armv7-timer";
>  				/* 14th PPI IRQ, active low level-sensitive */
> @@ -42,6 +46,7 @@
>  		};
>  		cpu at 1 {
>  			compatible = "arm,cortex-a15";
> +			reg = <0x1>;
>  			timer {
>  				compatible = "arm,armv7-timer";
>  				/* 14th PPI IRQ, active low level-sensitive */
> diff --git a/arch/arm/boot/dts/r8a7740.dtsi b/arch/arm/boot/dts/r8a7740.dtsi
> index 798fa35..b47bb36 100644
> --- a/arch/arm/boot/dts/r8a7740.dtsi
> +++ b/arch/arm/boot/dts/r8a7740.dtsi
> @@ -14,8 +14,11 @@
>  	compatible = "renesas,r8a7740";
>  
>  	cpus {
> +		#address-cells = <1>;
> +		#size-cells = <0>;
>  		cpu at 0 {
>  			compatible = "arm,cortex-a9";
> +			reg = <0x0>;
>  		};
>  	};
>  };
> diff --git a/arch/arm/boot/dts/sh7372.dtsi b/arch/arm/boot/dts/sh7372.dtsi
> index 677fc60..78478af 100644
> --- a/arch/arm/boot/dts/sh7372.dtsi
> +++ b/arch/arm/boot/dts/sh7372.dtsi
> @@ -14,8 +14,12 @@
>  	compatible = "renesas,sh7372";
>  
>  	cpus {
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
>  		cpu at 0 {
>  			compatible = "arm,cortex-a8";
> +			reg = <0x0>;
>  		};
>  	};
>  };
> diff --git a/arch/arm/boot/dts/sunxi.dtsi b/arch/arm/boot/dts/sunxi.dtsi
> index 8b36abe..447a0f0 100644
> --- a/arch/arm/boot/dts/sunxi.dtsi
> +++ b/arch/arm/boot/dts/sunxi.dtsi
> @@ -17,8 +17,12 @@
>  	interrupt-parent = <&intc>;
>  
>  	cpus {
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
>  		cpu at 0 {
>  			compatible = "arm,cortex-a8";
> +			reg = <0x0>;
>  		};
>  	};
>  
> diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
> index f149217..4eda2dc 100644
> --- a/arch/arm/kernel/devtree.c
> +++ b/arch/arm/kernel/devtree.c
> @@ -23,6 +23,7 @@
>  #include <asm/setup.h>
>  #include <asm/page.h>
>  #include <asm/smp_plat.h>
> +#include <asm/system_info.h>
>  #include <asm/mach/arch.h>
>  #include <asm/mach-types.h>
>  
> @@ -81,48 +82,68 @@ void __init arm_dt_init_cpu_maps(void)
>  	static u32 tmp_map[NR_CPUS] __initdata = {
>  				[0 ... NR_CPUS-1] = UINT_MAX };
>  	struct device_node *cpu, *cpus;
> -	u32 i, j, cpuidx = 1;
> +	u32 i, j, ac, cpuidx = 1;
>  	u32 mpidr = is_smp() ? read_cpuid_mpidr() & MPIDR_HWID_BITMASK : 0;
> -
> +	int len;
>  	bool bootcpu_valid = false;
> +
>  	cpus = of_find_node_by_path("/cpus");
>  
> -	if (!cpus)
> +	if (!cpus || ((cpu_architecture() < CPU_ARCH_ARMv7) && !is_smp()))
>  		return;
>  
> +	if (WARN_ON(of_property_read_u32(cpus, "#address-cells", &ac)))
> +		ac = of_n_addr_cells(cpus);
> +
>  	for_each_child_of_node(cpus, cpu) {
> -		u32 hwid;
> +		u64 hwid64;
> +		u32 hwid32;
> +		const __be32 *prop;
>  
>  		pr_debug(" * %s...\n", cpu->full_name);
>  		/*
> -		 * A device tree containing CPU nodes with missing "reg"
> -		 * properties is considered invalid to build the
> -		 * cpu_logical_map.
> +		 * A CPU node with missing or wrong "reg" property is
> +		 * considered invalid to build a cpu_logical_map entry.
>  		 */
> -		if (of_property_read_u32(cpu, "reg", &hwid)) {
> -			pr_debug(" * %s missing reg property\n",
> -				     cpu->full_name);
> -			return;
> +		prop = of_get_property(cpu, "reg", &len);
> +		if (!prop || len < (ac * sizeof(*prop))) {
> +				WARN(1, " * %s node missing/wrong reg"
> +					 " property, skipped\n",
> +					 cpu->full_name);
> +				goto next;
>  		}
> -
>  		/*
> -		 * 8 MSBs must be set to 0 in the DT since the reg property
> -		 * defines the MPIDR[23:0].
> +		 * Always read reg as u64 value.
> +		 * For dts with #address-cells == 1 hwid64[63:32]
> +		 * will be set to 0 by of_read_number.
> +		 * Toss away the top 32 bits and store value in hwid32.
> +		 */
> +		hwid32 = hwid64 = of_read_number(prop, ac);
> +		/*
> +		 * hwid64[63:24] must be always be 0 since the reg
> +		 * property defines the MPIDR[23:0] bits regardless
> +		 * of the cpus node #address-cells value.
>  		 */
> -		if (hwid & ~MPIDR_HWID_BITMASK)
> -			return;
> +		if (hwid64 & ~MPIDR_HWID_BITMASK) {
> +			WARN(1, " * %s node reg[63:24] must be 0 on"
> +			       " 32-bit dts, got %#016llx, skipped\n",
> +			       cpu->full_name, hwid64);
> +			goto next;
> +		}
>  
>  		/*
>  		 * Duplicate MPIDRs are a recipe for disaster.
>  		 * Scan all initialized entries and check for
> -		 * duplicates. If any is found just bail out.
> +		 * duplicates. If any is found just ignore the CPU.
>  		 * temp values were initialized to UINT_MAX
>  		 * to avoid matching valid MPIDR[23:0] values.
>  		 */
>  		for (j = 0; j < cpuidx; j++)
> -			if (WARN(tmp_map[j] == hwid, "Duplicate /cpu reg "
> -						     "properties in the DT\n"))
> -				return;
> +			if (WARN(tmp_map[j] == hwid32, " * %s node "
> +						"duplicate cpu reg "
> +						"property, skipped\n",
> +						cpu->full_name))
> +				goto next;
>  
>  		/*
>  		 * Build a stashed array of MPIDR values. Numbering scheme
> @@ -133,26 +154,29 @@ void __init arm_dt_init_cpu_maps(void)
>  		 * logical map built from DT is validated and can be used
>  		 * to override the map created in smp_setup_processor_id().
>  		 */
> -		if (hwid == mpidr) {
> +		if (hwid32 == mpidr) {
>  			i = 0;
>  			bootcpu_valid = true;
>  		} else {
>  			i = cpuidx++;
>  		}
>  
> -		if (WARN(cpuidx > nr_cpu_ids, "DT /cpu %u nodes greater than "
> -					       "max cores %u, capping them\n",
> +		if (WARN_ONCE(cpuidx > nr_cpu_ids, "DT cpu %u nodes greater"
> +						   " than max cores %u,"
> +						   " capping them\n",
>  					       cpuidx, nr_cpu_ids)) {
>  			cpuidx = nr_cpu_ids;
> -			break;
> +			goto next;
>  		}
>  
> -		tmp_map[i] = hwid;
> +		tmp_map[i] = hwid32;
> +next:	;
>  	}
> -
> -	if (WARN(!bootcpu_valid, "DT missing boot CPU MPIDR[23:0], "
> -				 "fall back to default cpu_logical_map\n"))
> -		return;
> +	/*
> +	 * A DT missing the boot CPU MPIDR is a really bad omen
> +	 * Flag it up as such and force firmware/dtb updates
> +	 */
> +	BUG_ON(!bootcpu_valid);
>  
>  	/*
>  	 * Since the boot CPU node contains proper data, and all nodes have
> -- 
> 1.7.12
> 
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 


From shawn.guo at linaro.org  Mon Apr 15 23:08:03 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 16 Apr 2013 11:08:03 +0800
Subject: [GIT PULL 4/4] ARM: imx: device tree changes for 3.10
In-Reply-To: <1365520775-28478-4-git-send-email-shawn.guo@linaro.org>
References: <1365520775-28478-1-git-send-email-shawn.guo@linaro.org>
 <1365520775-28478-4-git-send-email-shawn.guo@linaro.org>
Message-ID: <20130416030801.GA3293@S2101-09.ap.freescale.net>

Ping.

On Tue, Apr 09, 2013 at 11:19:35PM +0800, Shawn Guo wrote:
> Hi Arnd, Olof,
> 
> It's based on imx-cleanup-3.10 and Stephen Warren's "[GIT PULL] dt:
> run C pre-processor on *.dts, create some standard headers" to resolve
> dependency and conflicts.
> 
> Shawn
> 
> The following changes since commit 8b9ad9f67d094efd2c2765d82cc1866bee9052c2:
> 
>   Merge remote-tracking branch 'swarren/for-3.10/dtc-cpp-chroot-std-headers' into imx/dt (2013-04-09 22:52:42 +0800)
> 
> are available in the git repository at:
> 
> 
>   git://git.linaro.org/people/shawnguo/linux-2.6.git tags/imx-dt-3.10
> 
> for you to fetch changes up to 4b23185ff5e1c2ada2845002a034e8840ab98b63:
> 
>   ARM: dts: imx6dl-wandboard: Add USB Host support (2013-04-09 22:53:40 +0800)
> 
> ----------------------------------------------------------------
> The imx device tree changes for 3.10:
> 
> * The huge diff stat is introduced by the pinctrl changes.  With DTC
>   macro support ready, we're moving those huge mount of data about pins
>   out of pinctrl driver.
> * Device tree source updates for GPI, LDB, SRC, cpufreq-cpu0.
> * Initial imx6dl device tree support
> * Board level DTS changes for some imx27 and imx51 platforms.
> 
> ----------------------------------------------------------------
> Alexander Shiyan (2):
>       ARM: dts: Add NFC support for i.MX27 Phytec PCM038 module
>       ARM: dts: Add missing imx27-phytec-phycore dtb target
> 
> Dirk Behme (1):
>       ARM: dts: imx6q: add PMU
> 
> Fabio Estevam (3):
>       ARM: mx27: Replace clk_register_clkdev with clock DT lookup
>       ARM: dts: Add initial support for Wandboard Dual-Lite
>       ARM: dts: imx6dl-wandboard: Add USB Host support
> 
> Gwenhael Goavec-Merou (5):
>       ARM: imx: Add support for the Armadeus Systems APF51Dev docking board
>       ARM: imx51: Add pinctrl for ecspi2
>       ARM: imx51: Add a second pinctrl group for i2c2
>       ARM: imx: apf51dev: add ecspi1, ecspi2 and i2c2 support
>       ARM: imx: Add support for the Armadeus Systems APF27Dev docking board
> 
> Marek Vasut (1):
>       ARM: dts: imx53: fix SD2_DATA1 pad AUDMUX_AUD4 configuration
> 
> Markus Pargmann (3):
>       ARM: imx27 DT init cpufreq-cpu0 device
>       ARM: imx5 DT init cpufreq-cpu0 device
>       ARM: dts: imx51 cpu node
> 
> Pavel Machek (1):
>       ARM: dts: MicroSys sbc6x support (i.MX6)
> 
> Peter Chen (1):
>       ARM: dts: imx6q-sabresd: Add USB support
> 
> Philipp Zabel (6):
>       ARM i.MX5: Move IPU clock lookups into device tree
>       ARM i.MX53: Add IOMUXC GPR to device tree
>       ARM i.MX53: Add LDB device to device tree
>       ARM i.MX6q: Link system reset controller (SRC) to IPU in DT
>       ARM i.MX5: Add system reset controller (SRC) to i.MX51 and i.MX53 device tree
>       ARM i.MX5: Add System Reset Controller (SRC) support for i.MX51 and i.MX53
> 
> Sascha Hauer (8):
>       ARM: i.MX: Add GPT devicetree Documentation
>       ARM: i.MX27: Add GPT devicetree nodes
>       ARM: i.MX31: Add GPT devicetree node
>       ARM: i.MX51: Add GPT devicetree node
>       ARM: i.MX53: Add GPT devicetree node
>       ARM: i.MX6: Add clocks to GPT devicetree node
>       ARM: i.MX27: Add clocks to GPT devicetree nodes
>       ARM: i.MX51: Add PATA support
> 
> Sean Cross (3):
>       ARM: dts: imx6q: Add pinctrl for ecspi3
>       ARM: dts: imx6q: Add pinctrl for i2c2 and i2c3
>       ARM: dts: imx6q: Add pinctrl for audmix on AUD3
> 
> Shawn Guo (7):
>       ARM: imx: use #include for all device trees
>       pinctrl: imx: move hard-coding data into device tree
>       pinctrl: add pinctrl driver for imx6dl
>       pinctrl: add pinctrl driver for imx6sl
>       ARM: dts: imx: make sabreauto and sabresd common
>       ARM: dts: imx: add initial imx6dl-sabresd support
>       ARM: dts: imx: add initial imx6dl-sabreauto support
> 
> Steffen Trumtrar (1):
>       ARM i.MX6q: Add LDB device to device tree
> 
>  .../devicetree/bindings/clock/imx27-clock.txt      |  117 +
>  .../bindings/pinctrl/fsl,imx-pinctrl.txt           |    6 +-
>  .../bindings/pinctrl/fsl,imx35-pinctrl.txt         |  955 +-------
>  .../bindings/pinctrl/fsl,imx51-pinctrl.txt         |  759 +------
>  .../bindings/pinctrl/fsl,imx53-pinctrl.txt         | 1174 +---------
>  .../bindings/pinctrl/fsl,imx6dl-pinctrl.txt        |   38 +
>  .../bindings/pinctrl/fsl,imx6q-pinctrl.txt         | 1596 +-------------
>  .../bindings/pinctrl/fsl,imx6sl-pinctrl.txt        |   39 +
>  .../devicetree/bindings/timer/fsl,imxgpt.txt       |   18 +
>  arch/arm/boot/dts/Makefile                         |    9 +-
>  arch/arm/boot/dts/imx25-karo-tx25.dts              |    2 +-
>  arch/arm/boot/dts/imx25-pdk.dts                    |    2 +-
>  arch/arm/boot/dts/imx25.dtsi                       |    2 +-
>  arch/arm/boot/dts/imx27-apf27.dts                  |    2 +-
>  arch/arm/boot/dts/imx27-apf27dev.dts               |   60 +
>  arch/arm/boot/dts/imx27-pdk.dts                    |    2 +-
>  arch/arm/boot/dts/imx27-phytec-phycore.dts         |    8 +-
>  arch/arm/boot/dts/imx27.dtsi                       |   82 +-
>  arch/arm/boot/dts/imx31-bug.dts                    |    2 +-
>  arch/arm/boot/dts/imx31.dtsi                       |   18 +-
>  arch/arm/boot/dts/imx35-pinfunc.h                  |  970 +++++++++
>  arch/arm/boot/dts/imx51-apf51.dts                  |    2 +-
>  arch/arm/boot/dts/imx51-apf51dev.dts               |   97 +
>  arch/arm/boot/dts/imx51-babbage.dts                |   16 +-
>  arch/arm/boot/dts/imx51-pinfunc.h                  |  773 +++++++
>  arch/arm/boot/dts/imx51.dtsi                       |  343 +--
>  arch/arm/boot/dts/imx53-ard.dts                    |   70 +-
>  arch/arm/boot/dts/imx53-evk.dts                    |   18 +-
>  arch/arm/boot/dts/imx53-mba53.dts                  |   82 +-
>  arch/arm/boot/dts/imx53-pinfunc.h                  | 1189 ++++++++++
>  arch/arm/boot/dts/imx53-qsb.dts                    |   22 +-
>  arch/arm/boot/dts/imx53-smd.dts                    |   16 +-
>  arch/arm/boot/dts/imx53-tqma53.dtsi                |   32 +-
>  arch/arm/boot/dts/imx53.dtsi                       |  256 ++-
>  arch/arm/boot/dts/imx6dl-pinfunc.h                 | 1085 +++++++++
>  arch/arm/boot/dts/imx6dl-sabreauto.dts             |   31 +
>  arch/arm/boot/dts/imx6dl-sabresd.dts               |   35 +
>  arch/arm/boot/dts/imx6dl-wandboard.dts             |   44 +
>  arch/arm/boot/dts/imx6dl.dtsi                      |  125 +-
>  arch/arm/boot/dts/imx6q-arm2.dts                   |    8 +-
>  arch/arm/boot/dts/imx6q-pinfunc.h                  | 1041 +++++++++
>  arch/arm/boot/dts/imx6q-sabreauto.dts              |   33 +-
>  arch/arm/boot/dts/imx6q-sabrelite.dts              |   18 +-
>  arch/arm/boot/dts/imx6q-sabresd.dts                |   67 +-
>  arch/arm/boot/dts/imx6q-sbc6x.dts                  |   44 +
>  arch/arm/boot/dts/imx6q.dtsi                       |  280 ++-
>  arch/arm/boot/dts/imx6qdl-sabreauto.dtsi           |   38 +
>  arch/arm/boot/dts/imx6qdl-sabresd.dtsi             |   87 +
>  arch/arm/boot/dts/imx6qdl.dtsi                     |   33 +-
>  arch/arm/boot/dts/imx6sl-pinfunc.h                 | 1077 +++++++++
>  arch/arm/mach-imx/Kconfig                          |    2 +
>  arch/arm/mach-imx/clk-imx27.c                      |   11 +-
>  arch/arm/mach-imx/clk-imx51-imx53.c                |    9 +-
>  arch/arm/mach-imx/imx27-dt.c                       |   22 +-
>  arch/arm/mach-imx/imx51-dt.c                       |    3 +
>  arch/arm/mach-imx/mm-imx5.c                        |    2 +
>  arch/arm/mach-imx/src.c                            |    4 +-
>  drivers/pinctrl/Kconfig                            |   12 +-
>  drivers/pinctrl/Makefile                           |    1 +
>  drivers/pinctrl/pinctrl-imx.c                      |  126 +-
>  drivers/pinctrl/pinctrl-imx.h                      |   29 +-
>  drivers/pinctrl/pinctrl-imx35.c                    | 2088 +++++++-----------
>  drivers/pinctrl/pinctrl-imx51.c                    | 1532 +++++--------
>  drivers/pinctrl/pinctrl-imx53.c                    | 1597 ++------------
>  drivers/pinctrl/pinctrl-imx6dl.c                   |  497 +++++
>  drivers/pinctrl/pinctrl-imx6q.c                    | 2301 ++------------------
>  drivers/pinctrl/pinctrl-imx6sl.c                   |  403 ++++
>  67 files changed, 10490 insertions(+), 10972 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/clock/imx27-clock.txt
>  create mode 100644 Documentation/devicetree/bindings/pinctrl/fsl,imx6dl-pinctrl.txt
>  create mode 100644 Documentation/devicetree/bindings/pinctrl/fsl,imx6sl-pinctrl.txt
>  create mode 100644 Documentation/devicetree/bindings/timer/fsl,imxgpt.txt
>  create mode 100644 arch/arm/boot/dts/imx27-apf27dev.dts
>  create mode 100644 arch/arm/boot/dts/imx35-pinfunc.h
>  create mode 100644 arch/arm/boot/dts/imx51-apf51dev.dts
>  create mode 100644 arch/arm/boot/dts/imx51-pinfunc.h
>  create mode 100644 arch/arm/boot/dts/imx53-pinfunc.h
>  create mode 100644 arch/arm/boot/dts/imx6dl-pinfunc.h
>  create mode 100644 arch/arm/boot/dts/imx6dl-sabreauto.dts
>  create mode 100644 arch/arm/boot/dts/imx6dl-sabresd.dts
>  create mode 100644 arch/arm/boot/dts/imx6dl-wandboard.dts
>  create mode 100644 arch/arm/boot/dts/imx6q-pinfunc.h
>  create mode 100644 arch/arm/boot/dts/imx6q-sbc6x.dts
>  create mode 100644 arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
>  create mode 100644 arch/arm/boot/dts/imx6qdl-sabresd.dtsi
>  create mode 100644 arch/arm/boot/dts/imx6sl-pinfunc.h
>  create mode 100644 drivers/pinctrl/pinctrl-imx6dl.c
>  create mode 100644 drivers/pinctrl/pinctrl-imx6sl.c
> 



From shawn.guo at linaro.org  Mon Apr 15 23:12:56 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 16 Apr 2013 11:12:56 +0800
Subject: [PATCH v2] ARM: imx27: Add PWM0 to device tree
In-Reply-To: <1365925465-17453-1-git-send-email-gwenhael.goavec-merou@armadeus.com>
References: <1365925465-17453-1-git-send-email-gwenhael.goavec-merou@armadeus.com>
Message-ID: <20130416031254.GB3293@S2101-09.ap.freescale.net>

On Sun, Apr 14, 2013 at 09:44:25AM +0200, Gwenhael Goavec-Merou wrote:
> 
> Signed-off-by: Gwenhael Goavec-Merou <gwenhael.goavec-merou at armadeus.com>

Applied, thanks.

> ---
> v2:
> - Suppress status, now PWM is always enabled;
> - Suppress platform patch.
> 
>  arch/arm/boot/dts/imx27.dtsi | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/imx27.dtsi b/arch/arm/boot/dts/imx27.dtsi
> index ff4bd48..14e97cf 100644
> --- a/arch/arm/boot/dts/imx27.dtsi
> +++ b/arch/arm/boot/dts/imx27.dtsi
> @@ -89,6 +89,14 @@
>  				clock-names = "ipg", "per";
>  			};
>  
> +			pwm0: pwm at 10006000 {
> +				compatible = "fsl,imx27-pwm";
> +				reg = <0x10006000 0x1000>;
> +				interrupts = <23>;
> +				clocks = <&clks 34>, <&clks 61>;
> +				clock-names = "ipg", "per";
> +			};
> +
>  			uart1: serial at 1000a000 {
>  				compatible = "fsl,imx27-uart", "fsl,imx21-uart";
>  				reg = <0x1000a000 0x1000>;
> -- 
> 1.8.1.5
> 



From dianders at chromium.org  Mon Apr 15 23:42:57 2013
From: dianders at chromium.org (Doug Anderson)
Date: Mon, 15 Apr 2013 20:42:57 -0700
Subject: [REPOST PATCH] spi: s3c64xx: let device core setup the default pin
 configuration
In-Reply-To: <1362570130-14084-1-git-send-email-thomas.abraham@linaro.org>
References: <1362570130-14084-1-git-send-email-thomas.abraham@linaro.org>
Message-ID: <1366083777-9118-1-git-send-email-dianders@chromium.org>

From: Thomas Abraham <thomas.abraham at linaro.org>

With device core now able to setup the default pin configuration,
the pin configuration code based on the deprecated Samsung specific
gpio bindings is removed.

Signed-off-by: Thomas Abraham <thomas.abraham at linaro.org>
Signed-off-by: Doug Anderson <dianders at chromium.org>
Acked-by: Linus Walleij <linus.walleij at linaro.org>
Reviewed-by: Doug Anderson <dianders at chromium.org>
Tested-by: Doug Anderson <dianders at chromium.org>
---
 .../devicetree/bindings/spi/spi-samsung.txt        |  8 +--
 drivers/spi/spi-s3c64xx.c                          | 66 ++--------------------
 2 files changed, 6 insertions(+), 68 deletions(-)

diff --git a/Documentation/devicetree/bindings/spi/spi-samsung.txt b/Documentation/devicetree/bindings/spi/spi-samsung.txt
index a15ffed..86aa061 100644
--- a/Documentation/devicetree/bindings/spi/spi-samsung.txt
+++ b/Documentation/devicetree/bindings/spi/spi-samsung.txt
@@ -31,9 +31,6 @@ Required Board Specific Properties:
 
 - #address-cells: should be 1.
 - #size-cells: should be 0.
-- gpios: The gpio specifier for clock, mosi and miso interface lines (in the
-  order specified). The format of the gpio specifier depends on the gpio
-  controller.
 
 Optional Board Specific Properties:
 
@@ -86,9 +83,8 @@ Example:
 	spi_0: spi at 12d20000 {
 		#address-cells = <1>;
 		#size-cells = <0>;
-		gpios = <&gpa2 4 2 3 0>,
-			<&gpa2 6 2 3 0>,
-			<&gpa2 7 2 3 0>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&spi0_bus>;
 
 		w25q80bw at 0 {
 			#address-cells = <1>;
diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index 4989aeb..4ab992b 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -1148,41 +1148,6 @@ static void s3c64xx_spi_hwinit(struct s3c64xx_spi_driver_data *sdd, int channel)
 }
 
 #ifdef CONFIG_OF
-static int s3c64xx_spi_parse_dt_gpio(struct s3c64xx_spi_driver_data *sdd)
-{
-	struct device *dev = &sdd->pdev->dev;
-	int idx, gpio, ret;
-
-	/* find gpios for mosi, miso and clock lines */
-	for (idx = 0; idx < 3; idx++) {
-		gpio = of_get_gpio(dev->of_node, idx);
-		if (!gpio_is_valid(gpio)) {
-			dev_err(dev, "invalid gpio[%d]: %d\n", idx, gpio);
-			goto free_gpio;
-		}
-		sdd->gpios[idx] = gpio;
-		ret = gpio_request(gpio, "spi-bus");
-		if (ret) {
-			dev_err(dev, "gpio [%d] request failed: %d\n",
-				gpio, ret);
-			goto free_gpio;
-		}
-	}
-	return 0;
-
-free_gpio:
-	while (--idx >= 0)
-		gpio_free(sdd->gpios[idx]);
-	return -EINVAL;
-}
-
-static void s3c64xx_spi_dt_gpio_free(struct s3c64xx_spi_driver_data *sdd)
-{
-	unsigned int idx;
-	for (idx = 0; idx < 3; idx++)
-		gpio_free(sdd->gpios[idx]);
-}
-
 static struct s3c64xx_spi_info *s3c64xx_spi_parse_dt(struct device *dev)
 {
 	struct s3c64xx_spi_info *sci;
@@ -1215,15 +1180,6 @@ static struct s3c64xx_spi_info *s3c64xx_spi_parse_dt(struct device *dev)
 {
 	return dev->platform_data;
 }
-
-static int s3c64xx_spi_parse_dt_gpio(struct s3c64xx_spi_driver_data *sdd)
-{
-	return -EINVAL;
-}
-
-static void s3c64xx_spi_dt_gpio_free(struct s3c64xx_spi_driver_data *sdd)
-{
-}
 #endif
 
 static const struct of_device_id s3c64xx_spi_dt_match[];
@@ -1344,10 +1300,7 @@ static int s3c64xx_spi_probe(struct platform_device *pdev)
 		goto err0;
 	}
 
-	if (!sci->cfg_gpio && pdev->dev.of_node) {
-		if (s3c64xx_spi_parse_dt_gpio(sdd))
-			return -EBUSY;
-	} else if (sci->cfg_gpio == NULL || sci->cfg_gpio()) {
+	if (sci->cfg_gpio && sci->cfg_gpio()) {
 		dev_err(&pdev->dev, "Unable to config gpio\n");
 		ret = -EBUSY;
 		goto err0;
@@ -1358,13 +1311,13 @@ static int s3c64xx_spi_probe(struct platform_device *pdev)
 	if (IS_ERR(sdd->clk)) {
 		dev_err(&pdev->dev, "Unable to acquire clock 'spi'\n");
 		ret = PTR_ERR(sdd->clk);
-		goto err1;
+		goto err0;
 	}
 
 	if (clk_prepare_enable(sdd->clk)) {
 		dev_err(&pdev->dev, "Couldn't enable clock 'spi'\n");
 		ret = -EBUSY;
-		goto err1;
+		goto err0;
 	}
 
 	sprintf(clk_name, "spi_busclk%d", sci->src_clk_nr);
@@ -1421,9 +1374,6 @@ err3:
 	clk_disable_unprepare(sdd->src_clk);
 err2:
 	clk_disable_unprepare(sdd->clk);
-err1:
-	if (!sdd->cntrlr_info->cfg_gpio && pdev->dev.of_node)
-		s3c64xx_spi_dt_gpio_free(sdd);
 err0:
 	platform_set_drvdata(pdev, NULL);
 	spi_master_put(master);
@@ -1446,9 +1396,6 @@ static int s3c64xx_spi_remove(struct platform_device *pdev)
 
 	clk_disable_unprepare(sdd->clk);
 
-	if (!sdd->cntrlr_info->cfg_gpio && pdev->dev.of_node)
-		s3c64xx_spi_dt_gpio_free(sdd);
-
 	platform_set_drvdata(pdev, NULL);
 	spi_master_put(master);
 
@@ -1467,9 +1414,6 @@ static int s3c64xx_spi_suspend(struct device *dev)
 	clk_disable_unprepare(sdd->src_clk);
 	clk_disable_unprepare(sdd->clk);
 
-	if (!sdd->cntrlr_info->cfg_gpio && dev->of_node)
-		s3c64xx_spi_dt_gpio_free(sdd);
-
 	sdd->cur_speed = 0; /* Output Clock is stopped */
 
 	return 0;
@@ -1481,9 +1425,7 @@ static int s3c64xx_spi_resume(struct device *dev)
 	struct s3c64xx_spi_driver_data *sdd = spi_master_get_devdata(master);
 	struct s3c64xx_spi_info *sci = sdd->cntrlr_info;
 
-	if (!sci->cfg_gpio && dev->of_node)
-		s3c64xx_spi_parse_dt_gpio(sdd);
-	else
+	if (sci->cfg_gpio)
 		sci->cfg_gpio();
 
 	/* Enable the clock */
-- 
1.8.1.3



From mturquette at linaro.org  Tue Apr 16 00:45:14 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Mon, 15 Apr 2013 21:45:14 -0700
Subject: [PATCH] clk: si5351: make clk-si5351 depend on CONFIG_OF
In-Reply-To: <20130416105513.913219ac889b1db952876197@canb.auug.org.au>
References: <1366009214-32234-1-git-send-email-sebastian.hesselbarth@gmail.com>
 <20130416105513.913219ac889b1db952876197@canb.auug.org.au>
Message-ID: <20130416044514.19887.93969@quantum>

Quoting Stephen Rothwell (2013-04-15 17:55:13)
> Hi Sebastian,
> 
> On Mon, 15 Apr 2013 09:00:14 +0200 Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com> wrote:
> >
> > Calling clk-si5351 driver non-OF ready was too early. This patch
> > makes clk-si5351 depend on CONFIG_OF again, until things get sorted out.
> > 
> > Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
> > Reported-by: Stephen Rottweil <sfr at canb.auug.org.au>
> 
> My name is spelt "Rothwell" (as in the Cc: line below) :-(
> 

It's fixed in the merged version.

Regards,
Mike

> > ---
> > Cc: Stephen Rothwell <sfr at canb.auug.org.au>
> 
> -- 
> Cheers,
> Stephen Rothwell                    sfr at canb.auug.org.au


From nsekhar at ti.com  Tue Apr 16 02:12:31 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Tue, 16 Apr 2013 11:42:31 +0530
Subject: [GIT PULL 2/3] ARM: davinci: SoC updates for v3.10 (part 2)
In-Reply-To: <20130415201835.GA24600@quad.lixom.net>
References: <1366046599-6590-1-git-send-email-nsekhar@ti.com>
 <1366046599-6590-2-git-send-email-nsekhar@ti.com>
 <20130415201835.GA24600@quad.lixom.net>
Message-ID: <516CEBCF.60507@ti.com>

On 4/16/2013 1:48 AM, Olof Johansson wrote:
> On Mon, Apr 15, 2013 at 10:53:18PM +0530, Sekhar Nori wrote:
>> Hi Arnd, Olof,
>>
>> Can you please the following SoC updates for DaVinci.
>> The branch depends on (and merges) an immutable branch
>> from Ohad adding DA8XX rempote proc driver.
> 
> Hi,
> 
> Where is this branch from? Git URL and branch name, please -- we prefer to pull
> these in as separate branches under depends/* as well to document it.

Here is the repo and branch:

git://git.kernel.org/pub/scm/linux/kernel/git/ohad/remoteproc.git for-next

Thanks,
Sekhar


From s.hauer at pengutronix.de  Tue Apr 16 02:32:22 2013
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Tue, 16 Apr 2013 08:32:22 +0200
Subject: [PATCH v2 3/4] ARM: dts: mx53qsb: Add support for parallel display
In-Reply-To: <CAOMZO5DwoP4WXEVfKkqbfrJ60s0GxqkLOa_h1TQNJXY61_NTbQ@mail.gmail.com>
References: <1365516452-1287-1-git-send-email-rogerio.pimentel@freescale.com>
 <1365516452-1287-3-git-send-email-rogerio.pimentel@freescale.com>
 <1365520643.4023.52.camel@pizza.hi.pengutronix.de>
 <CAOkaPuV2xNR=Vxsa6tPdnPS34Q5ffV9-f8DefhcJfvVvXWOADQ@mail.gmail.com>
 <20130413170943.GX1906@pengutronix.de>
 <CAOMZO5DwoP4WXEVfKkqbfrJ60s0GxqkLOa_h1TQNJXY61_NTbQ@mail.gmail.com>
Message-ID: <20130416063222.GF1906@pengutronix.de>

On Mon, Apr 15, 2013 at 09:18:35PM -0300, Fabio Estevam wrote:
> Sascha/Phillip,
> 
> On Sat, Apr 13, 2013 at 2:09 PM, Sascha Hauer <s.hauer at pengutronix.de> wrote:
> 
> > Having the parallel display support is fine. Philipp just suggested to
> > add status = "disabled" for both the parallel display and the lvds
> > encoder so that for example the bootloader can decide which one to enable
> > during runtime. Otherwise we have two display options on the same pins and
> > the first one wins.
> 
> Ok, understood.
> 
> It is not clear how we can tell the bootloader that we want the CLAA
> WVGA panel or the HDMI daughter card, for example?

In barebox we would do a 'of_property -s /soc/display at di0 status okay'.
I don't know the corresponding U-Boot command.

> 
> What would be the kernel command line in each case?

Ther kernel command line is not involved here.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From amit.daniel at samsung.com  Tue Apr 16 02:51:41 2013
From: amit.daniel at samsung.com (amit daniel kachhap)
Date: Tue, 16 Apr 2013 12:21:41 +0530
Subject: [PATCH] cpufreq: exynos5440: Protect opp search calls with rcu
 lock
In-Reply-To: <CAGo_u6qD5hO7x0fYwe+cZ5GHRA6tRG+vmhnf4GFjt9G0inQ0xA@mail.gmail.com>
References: <1366007087-12090-1-git-send-email-amit.daniel@samsung.com>
 <CAGo_u6qD5hO7x0fYwe+cZ5GHRA6tRG+vmhnf4GFjt9G0inQ0xA@mail.gmail.com>
Message-ID: <CADGdYn6FJFWgx=8PGNwjmxVpsBU=QrvMKpPQMANuBwOHUPmt8w@mail.gmail.com>

Hi Nishanth,

Thanks for reviewing this patch.

On Mon, Apr 15, 2013 at 7:40 PM, Nishanth Menon <nm at ti.com> wrote:
> Daniel,
> On Mon, Apr 15, 2013 at 1:24 AM, Amit Daniel Kachhap
> <amit.daniel at samsung.com> wrote:
>> As per the OPP library documentation(Documentation/power/opp.txt) all
>> opp find/get calls should be protected by rcu locks.
>>
>> Signed-off-by: Amit Daniel Kachhap <amit.daniel at samsung.com>
>> ---
>>
>> This patch is created against linux-next tree and is suggested by
>> Nishanth Menon. (https://lkml.org/lkml/2013/4/12/119)
>>
>>  drivers/cpufreq/exynos5440-cpufreq.c |    3 +++
>>  1 files changed, 3 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/cpufreq/exynos5440-cpufreq.c b/drivers/cpufreq/exynos5440-cpufreq.c
>> index ead7ed4..0c74018 100644
>> --- a/drivers/cpufreq/exynos5440-cpufreq.c
>> +++ b/drivers/cpufreq/exynos5440-cpufreq.c
>> @@ -120,11 +120,13 @@ static int init_div_table(void)
>>         int i = 0;
>>         struct opp *opp;
>>
>> +       rcu_read_lock();
>>         for (i = 0; freq_tbl[i].frequency != CPUFREQ_TABLE_END; i++) {
>>
>>                 opp = opp_find_freq_exact(dvfs_info->dev,
>>                                         freq_tbl[i].frequency * 1000, true);
>>                 if (IS_ERR(opp)) {
>> +                       rcu_read_unlock();
>>                         dev_err(dvfs_info->dev,
>>                                 "failed to find valid OPP for %u KHZ\n",
>>                                 freq_tbl[i].frequency);
>> @@ -159,6 +161,7 @@ static int init_div_table(void)
>>                 __raw_writel(tmp, dvfs_info->base + XMU_PMU_P0_7 + 4 * i);
>>         }
>>
>> +       rcu_read_unlock();
>
> Is it not possible to reduce the amount of code protected by RCU lock?
> something like this:
Yes it is possible but then this part of code is a loop of max 8
iteration so rcu_read_lock will be called those many times.
Also this code blocks are just register writes and not doing any time
consuming operations.

Thanks,
Amit Daniel
> +               rcu_read_lock();
>                 opp = opp_find_freq_exact(dvfs_info->dev,
>                                         freq_tbl[i].frequency * 1000, true);
>                 if (IS_ERR(opp)) {
> +                       rcu_read_unlock();
>                         dev_err(dvfs_info->dev,
>                                 "failed to find valid OPP for %u KHZ\n",
>                                 freq_tbl[i].frequency);
>                         return PTR_ERR(opp);
>                 }
> +               volt_id = opp_get_voltage(opp);
> +               rcu_unlock();
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From sfr at canb.auug.org.au  Tue Apr 16 03:00:10 2013
From: sfr at canb.auug.org.au (Stephen Rothwell)
Date: Tue, 16 Apr 2013 17:00:10 +1000
Subject: linux-next: manual merge of the arm-soc tree with the input tree
Message-ID: <20130416170010.9c2bf713b12fa89e663aea2d@canb.auug.org.au>

Hi all,

Today's linux-next merge of the arm-soc tree got a conflict in
arch/arm/mach-shmobile/board-armadillo800eva.c between commit
cbaf7f808081 ("ARM - shmobile: Armadillo800EVA: Move st1232 reset pin
handling") from the input tree and commits ead10fed8b4b ("ARM: shmobile:
armadillo: Replace GPIO_PORTx enum with GPIO port numbers") and
0b7d78202260 ("ARM: shmobile: r8a7740: Migrate from INTC to GIC") from
the arm-soc tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr at canb.auug.org.au

diff --cc arch/arm/mach-shmobile/board-armadillo800eva.c
index 881e5c0,81db74a..0000000
--- a/arch/arm/mach-shmobile/board-armadillo800eva.c
+++ b/arch/arm/mach-shmobile/board-armadillo800eva.c
@@@ -890,8 -1000,7 +1009,8 @@@ static struct st1232_pdata st1232_i2c0_
  static struct i2c_board_info i2c0_devices[] = {
  	{
  		I2C_BOARD_INFO("st1232-ts", 0x55),
- 		.irq = evt2irq(0x0340),
+ 		.irq = irq_pin(10),
 +		.platform_data = &st1232_i2c0_pdata,
  	},
  	{
  		I2C_BOARD_INFO("wm8978", 0x1a),
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130416/3b686bf6/attachment.sig>

From peter.ujfalusi at ti.com  Tue Apr 16 03:18:22 2013
From: peter.ujfalusi at ti.com (Peter Ujfalusi)
Date: Tue, 16 Apr 2013 09:18:22 +0200
Subject: Query on pinctrl usage for DT nodes
In-Reply-To: <516C2D74.2090106@wwwdotorg.org>
References: <CA+V-a8uiPwsAD--OHFAE=i2ed+-wbXm4p2deZXr92+Zv6GDS1w@mail.gmail.com>
 <515C5C76.3080009@wwwdotorg.org> <20130403183803.GA10155@atomide.com>
 <20130403184202.GB10155@atomide.com> <516BB818.3060603@ti.com>
 <516C2D74.2090106@wwwdotorg.org>
Message-ID: <516CFB3E.8040703@ti.com>

On 04/15/2013 06:40 PM, Stephen Warren wrote:
> So, the solution here is for pinctrl-single to create a separate
> pin/group object for each separately controllable entity, and that may
> be each bit in a register rather than each register, depending on HW.

Exactly what I was thinking.
It would be ideal if we could do this dynamically, so when a new
pinctr-single,bits is added we create a new object (after checking for
overlapping bits from previous objects).
If this is not possible we should have new property telling pinctrl-single how
many objects to create for one physical register (used only when
pinctrl-single,bit-per-mux is defined), something like:

pinctrl-single,bit-per-mux;
pinctrl-single,functions-per-register = <X>;

For sure we need to check here as well for overlaps in the bitfields...

-- 
P?ter


From benh at kernel.crashing.org  Tue Apr 16 03:12:41 2013
From: benh at kernel.crashing.org (Benjamin Herrenschmidt)
Date: Tue, 16 Apr 2013 09:12:41 +0200
Subject: [PATCH v6 0/3] of/pci: Provide common support for PCI DT parsing
In-Reply-To: <CACRpkdbSd8pRG5pUS0ymqXDSp=ZhoQa2ctVuRA0cCmUcX5qFAA@mail.gmail.com>
References: <1365693969-23907-1-git-send-email-Andrew.Murray@arm.com>
 <20130415175641.GM28693@titan.lakedaemon.net>
 <CACRpkdbSd8pRG5pUS0ymqXDSp=ZhoQa2ctVuRA0cCmUcX5qFAA@mail.gmail.com>
Message-ID: <1366096361.24994.49.camel@pasglop>

On Mon, 2013-04-15 at 20:29 +0200, Linus Walleij wrote:
> > As agreed with Rob Herring, series applied to mvebu/drivers to
> support
> > mvebu pcie driver.
> 
> Will this hit ARM SoC soon-ish so I can base a pull request for the
> Integrator on this stuff as well?

Do not send this series upstream (or even in -next) until it has been at
least build-tested and acked by the affected architectures. AFAIK it
breaks microblaze build (simple missing #include) and isn't yet tested
on powerpc (I'm on vacation, maybe somebody else on linuxppc-dev can do
it though).

Ben.




From lars at metafoo.de  Tue Apr 16 04:06:26 2013
From: lars at metafoo.de (Lars-Peter Clausen)
Date: Tue, 16 Apr 2013 10:06:26 +0200
Subject: [PATCH v3 00/15] ASoC: fsl-ssi: ac97-slave support
In-Reply-To: <516C9A87.4090307@tabi.org>
References: <1365939779-4507-1-git-send-email-mpa@pengutronix.de>
 <516A9D5B.2070707@metafoo.de> <516C9A87.4090307@tabi.org>
Message-ID: <516D0682.5010309@metafoo.de>

On 04/16/2013 02:25 AM, Timur Tabi wrote:
> Lars-Peter Clausen wrote:
>>> >@Lars:
>>> >There are 4 new patches at the beginning of the series that fix some
>>> problems
>>> >of your cleanups. I think they were in the changes you posted. If not,
>>> could you
>>> >please add them to your branch?
>> Hi,
>>
>> I had already fixed them localy. I'm in the process of polishing the last
>> bits
>> and pieces of my generic dmaengine PCM driver series right now and will
>> submit
>> it later today.
> 
> So which repository should I apply these patches to?  I want to make sure
> they don't break PowerPC.
> 

You can use
https://github.com/lclausen-adi/linux-2.6/tree/asoc-dmaengine-cleanups, but
make sure to skip the first 4 patches from this series.

- Lars


From girishks2000 at gmail.com  Tue Apr 16 04:31:14 2013
From: girishks2000 at gmail.com (girishks2000 at gmail.com)
Date: Tue, 16 Apr 2013 14:01:14 +0530
Subject: [PATCH] mtd: devices: added the 16mb winbond device
Message-ID: <516d0c68.e10b420a.287d.ffff894c@mx.google.com>

From: Girish K S <ks.giri at samsung.com>

added a 16mb winbond devce to the device list
erase size = 64k and number of blocks = 256

Signed-off-by: Girish K S <ks.giri at samsung.com>
---
 drivers/mtd/devices/m25p80.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
index 2f3d2a5..c81ee12 100644
--- a/drivers/mtd/devices/m25p80.c
+++ b/drivers/mtd/devices/m25p80.c
@@ -840,6 +840,7 @@ static const struct spi_device_id m25p_ids[] = {
 	{ "w25q32dw", INFO(0xef6016, 0, 64 * 1024,  64, SECT_4K) },
 	{ "w25x64", INFO(0xef3017, 0, 64 * 1024, 128, SECT_4K) },
 	{ "w25q64", INFO(0xef4017, 0, 64 * 1024, 128, SECT_4K) },
+	{ "w25q128", INFO(0xef4018, 0, 64 * 1024, 256, SECT_4K) },
 	{ "w25q80", INFO(0xef5014, 0, 64 * 1024,  16, SECT_4K) },
 	{ "w25q80bl", INFO(0xef4014, 0, 64 * 1024,  16, SECT_4K) },
 	{ "w25q128", INFO(0xef4018, 0, 64 * 1024, 256, SECT_4K) },
-- 
1.7.5.4



From nsekhar at ti.com  Tue Apr 16 04:30:41 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Tue, 16 Apr 2013 14:00:41 +0530
Subject: [V3 patch 18/19] ARM: davinci: cpuidle: use init/exit common
 routine
In-Reply-To: <1365770165-27096-19-git-send-email-daniel.lezcano@linaro.org>
References: <1365770165-27096-1-git-send-email-daniel.lezcano@linaro.org>
 <1365770165-27096-19-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <516D0C31.2010403@ti.com>

On 4/12/2013 6:06 PM, Daniel Lezcano wrote:
> Remove the duplicated code and use the cpuidle common code for initialization.
> 
> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
> ---

Tested on DA850 EVM.

Acked-by: Sekhar Nori <nsekhar at ti.com>

Thanks,
Sekhar


From daniel.lezcano at linaro.org  Tue Apr 16 04:42:17 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Tue, 16 Apr 2013 10:42:17 +0200
Subject: [V3 patch 00/19] cpuidle: code consolidation
In-Reply-To: <87k3o38kh4.fsf@linaro.org>
References: <1365770165-27096-1-git-send-email-daniel.lezcano@linaro.org>
 <87k3o38kh4.fsf@linaro.org>
Message-ID: <516D0EE9.40704@linaro.org>

On 04/16/2013 01:03 AM, Kevin Hilman wrote:
> Hi Daniel,
> 
> Daniel Lezcano <daniel.lezcano at linaro.org> writes:
> 
>> This patchset series provide some code consolidation across the different
>> cpuidle drivers. It contains two parts, the first one is the removal of
>> the time keeping flag and the second one, is a common initialization routine.
> 
> Do you have this series in a branch somewhere (preferrable on top of
> Rafael's linux-next) for ease of testing?

Yes, I updated my git tree [1].

Thanks for testing.

  -- Daniel

[1] git://git.linaro.org/people/dlezcano/cpuidle-next.git linux-pm-next

-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From will.deacon at arm.com  Tue Apr 16 04:44:18 2013
From: will.deacon at arm.com (Will Deacon)
Date: Tue, 16 Apr 2013 09:44:18 +0100
Subject: [RFC PATCH 1/3] pstore-ram: use write-combine mappings
In-Reply-To: <CAMbhsRRT7tOBHppvjJEW5wRtVaUhwxr8=YQY=Sy0VAFeBg1JmQ@mail.gmail.com>
References: <1365563297-12480-1-git-send-email-robherring2@gmail.com>
 <CAMbhsRSvQPbzJ7Nt=OSSYE_A1e+eaUjO7XY+qRppJ5_gfWmW4A@mail.gmail.com>
 <51656992.60203@gmail.com>
 <CAMbhsRS1hnBRoomoiNijrXZB-938d2RSs1cu9EdSfmXD3xpSQg@mail.gmail.com>
 <516C9454.4060009@gmail.com>
 <CAMbhsRRT7tOBHppvjJEW5wRtVaUhwxr8=YQY=Sy0VAFeBg1JmQ@mail.gmail.com>
Message-ID: <20130416084418.GA30756@mudshark.cambridge.arm.com>

On Tue, Apr 16, 2013 at 01:43:09AM +0100, Colin Cross wrote:
> On Mon, Apr 15, 2013 at 4:59 PM, Rob Herring <robherring2 at gmail.com> wrote:
> > Exclusive accesses still have further restrictions. From section 3.4.5:
> >
> > ? It is IMPLEMENTATION DEFINED whether LDREX and STREX operations can be
> > performed to a memory region
> >    with the Device or Strongly-ordered memory attribute. Unless the
> > implementation documentation explicitly
> >   states that LDREX and STREX operations to a memory region with the
> > Device or Strongly-ordered attribute are
> >  permitted, the effect of such operations is UNPREDICTABLE.
> >
> >
> > Given that it is implementation defined, I don't see how Linux can rely
> > on that behavior.
> 
> I see, the problem is that while noncached and writecombined appear to
> be similar mappings, noncached is mapped in PRRR to strongly-ordered,
> while writecombined is mapped to unbufferable normal memory.
> 
> I think adding a wmb() to persistent_ram_write is going to be
> expensive on cpus with outer caches like the L2X0, where wmb() will
> result in a spinlock.  Is there a real SoC where this doesn't work?

A real SoC where exclusives don't work to memory not mapped as normal? Take
your pick...

Will


From girishks2000 at gmail.com  Tue Apr 16 04:58:52 2013
From: girishks2000 at gmail.com (Girish K S)
Date: Tue, 16 Apr 2013 14:28:52 +0530
Subject: [PATCH 1/2] ARM: dts: enable spi for EXYNOS5440 SOC
Message-ID: <1366102733-3570-1-git-send-email-ks.giri@samsung.com>

This patch enables the SPI in EXYNOS5440 SoC. The NOR
Flash can be accessed by enabling the spi interface

Signed-off-by: Girish K S <ks.giri at samsung.com>
---
 arch/arm/boot/dts/exynos5440-ssdk5440.dts |   39 +++++++++++++++++++++++++++-
 arch/arm/boot/dts/exynos5440.dtsi         |   16 +++++++----
 2 files changed, 47 insertions(+), 8 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5440-ssdk5440.dts b/arch/arm/boot/dts/exynos5440-ssdk5440.dts
index d55042b..a85ac0e 100644
--- a/arch/arm/boot/dts/exynos5440-ssdk5440.dts
+++ b/arch/arm/boot/dts/exynos5440-ssdk5440.dts
@@ -20,8 +20,43 @@
 		bootargs = "root=/dev/sda2 rw rootwait ignore_loglevel early_printk no_console_suspend mem=2048M at 0x80000000 console=ttySAC0,115200";
 	};
 
-	spi {
-		status = "disabled";
+	spi_0: spi at D0000 {
+
+		flash: w25q128 at 0 {
+			#address-cells = <1>;
+			#size-cells = <1>;
+			compatible = "winbond,w25q128";
+			spi-max-frequency = <15625000>;
+			reg = <0>;
+			controller-data {
+				samsung,spi-feedback-delay = <0>;
+			};
+
+			partition at 00000 {
+				label = "BootLoader";
+				reg = <0x60000 0x80000>;
+				read-only;
+			};
+
+			partition at e0000 {
+				label = "Recovery-Kernel";
+				reg = <0xe0000 0x300000>;
+				read-only;
+			};
+
+			partition at 3e0000 {
+				label = "CRAM-FS";
+				reg = <0x3e0000 0x700000>;
+				read-only;
+			};
+
+			partition at ae0000 {
+				label = "User-Data";
+				reg = <0xae0000 0x520000>;
+			};
+
+		};
+
 	};
 
 	fixed-rate-clocks {
diff --git a/arch/arm/boot/dts/exynos5440.dtsi b/arch/arm/boot/dts/exynos5440.dtsi
index f6b1c89..7c5dc38 100644
--- a/arch/arm/boot/dts/exynos5440.dtsi
+++ b/arch/arm/boot/dts/exynos5440.dtsi
@@ -16,6 +16,10 @@
 
 	interrupt-parent = <&gic>;
 
+	aliases {
+		spi0 = &spi_0;
+	};
+
 	clock: clock-controller at 0x160000 {
 		compatible = "samsung,exynos5440-clock";
 		reg = <0x160000 0x1000>;
@@ -101,15 +105,15 @@
 		clock-names = "uart", "clk_uart_baud0";
 	};
 
-	spi {
-		compatible = "samsung,exynos4210-spi";
-		reg = <0xD0000 0x1000>;
+	spi_0: spi at D0000 {
+		compatible = "samsung,exynos5440-spi";
+		reg = <0xD0000 0x100>;
 		interrupts = <0 4 0>;
-		tx-dma-channel = <&pdma0 5>; /* preliminary */
-		rx-dma-channel = <&pdma0 4>; /* preliminary */
 		#address-cells = <1>;
 		#size-cells = <0>;
-		clocks = <&clock 21>, <&clock 16>;
+		samsung,spi-src-clk = <0>;
+		num-cs = <1>;
+		clocks = <&clock 8>, <&clock 3>;
 		clock-names = "spi", "spi_busclk0";
 	};
 
-- 
1.7.5.4



From girishks2000 at gmail.com  Tue Apr 16 04:58:53 2013
From: girishks2000 at gmail.com (Girish K S)
Date: Tue, 16 Apr 2013 14:28:53 +0530
Subject: [PATCH 2/2] ARM: dts: add dts node for the ahci sata exynos5440
In-Reply-To: <1366102733-3570-1-git-send-email-ks.giri@samsung.com>
References: <1366102733-3570-1-git-send-email-ks.giri@samsung.com>
Message-ID: <1366102733-3570-2-git-send-email-ks.giri@samsung.com>

This patch adds dts support for the sata controller

Signed-off-by: Girish K S <ks.giri at samsung.com>
---
 arch/arm/boot/dts/exynos5440.dtsi |    9 +++++++++
 1 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5440.dtsi b/arch/arm/boot/dts/exynos5440.dtsi
index 7c5dc38..2dc4ffa 100644
--- a/arch/arm/boot/dts/exynos5440.dtsi
+++ b/arch/arm/boot/dts/exynos5440.dtsi
@@ -220,4 +220,13 @@
 		clock-names = "rtc";
 		status = "disabled";
 	};
+
+	sata at 210000 {
+		compatible = "samsung,exynos5440-ahci";
+		reg = <0x210000 0x10000>;
+		interrupts = <0 30 0>;
+		clocks = <&clock 10>;
+		clock-names = "sata";
+	};
+
 };
-- 
1.7.5.4



From girishks2000 at gmail.com  Tue Apr 16 05:10:04 2013
From: girishks2000 at gmail.com (Girish K S)
Date: Tue, 16 Apr 2013 14:40:04 +0530
Subject: [PATCH] ahci: sata: add support for exynos5440 sata
Message-ID: <1366103404-14105-1-git-send-email-ks.giri@samsung.com>

This patch adds the compatible string of the exynos5440 sata controller
compliant with the ahci 1.3 and sata 3.0 specification.

Signed-off-by: Girish K S <ks.giri at samsung.com>
---
 drivers/ata/ahci_platform.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/ata/ahci_platform.c b/drivers/ata/ahci_platform.c
index 7a8a284..c06f021 100644
--- a/drivers/ata/ahci_platform.c
+++ b/drivers/ata/ahci_platform.c
@@ -327,6 +327,7 @@ static SIMPLE_DEV_PM_OPS(ahci_pm_ops, ahci_suspend, ahci_resume);
 
 static const struct of_device_id ahci_of_match[] = {
 	{ .compatible = "snps,spear-ahci", },
+	{ .compatible = "samsung,exynos5440-ahci", },
 	{},
 };
 MODULE_DEVICE_TABLE(of, ahci_of_match);
-- 
1.6.6.rc2



From wsa at the-dreams.de  Tue Apr 16 05:10:32 2013
From: wsa at the-dreams.de (Wolfram Sang)
Date: Tue, 16 Apr 2013 11:10:32 +0200
Subject: [PATCH 2/3] i2c: at91: convert to
 dma_request_slave_channel_compat()
In-Reply-To: <1366028217-5037-3-git-send-email-ludovic.desroches@atmel.com>
References: <1366028217-5037-1-git-send-email-ludovic.desroches@atmel.com>
 <1366028217-5037-3-git-send-email-ludovic.desroches@atmel.com>
Message-ID: <20130416091032.GA16978@the-dreams.de>

On Mon, Apr 15, 2013 at 02:16:56PM +0200, ludovic.desroches at atmel.com wrote:
> From: Ludovic Desroches <ludovic.desroches at atmel.com>
> 
> Use generic DMA DT helper. Platforms booting with or without DT populated are
> both supported.
> 
> Signed-off-by: Ludovic Desroches <ludovic.desroches at atmel.com>

Applied to for-next, thanks!



From balbi at ti.com  Tue Apr 16 05:13:00 2013
From: balbi at ti.com (Felipe Balbi)
Date: Tue, 16 Apr 2013 12:13:00 +0300
Subject: [PATCH] ahci: sata: add support for exynos5440 sata
In-Reply-To: <1366103404-14105-1-git-send-email-ks.giri@samsung.com>
References: <1366103404-14105-1-git-send-email-ks.giri@samsung.com>
Message-ID: <20130416091300.GD25040@arwen.pp.htv.fi>

Hi,

On Tue, Apr 16, 2013 at 02:40:04PM +0530, Girish K S wrote:
> This patch adds the compatible string of the exynos5440 sata controller
> compliant with the ahci 1.3 and sata 3.0 specification.
> 
> Signed-off-by: Girish K S <ks.giri at samsung.com>
> ---
>  drivers/ata/ahci_platform.c |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/ata/ahci_platform.c b/drivers/ata/ahci_platform.c
> index 7a8a284..c06f021 100644
> --- a/drivers/ata/ahci_platform.c
> +++ b/drivers/ata/ahci_platform.c
> @@ -327,6 +327,7 @@ static SIMPLE_DEV_PM_OPS(ahci_pm_ops, ahci_suspend, ahci_resume);
>  
>  static const struct of_device_id ahci_of_match[] = {
>  	{ .compatible = "snps,spear-ahci", },
> +	{ .compatible = "samsung,exynos5440-ahci", },

is this an IP designed by samsung or something you licensed from e.g
snps ? If the latter you should add:

"snps,ahci"

instead. Right ?

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130416/ff530ab3/attachment.sig>

From girishks2000 at gmail.com  Tue Apr 16 05:21:16 2013
From: girishks2000 at gmail.com (Girish KS)
Date: Tue, 16 Apr 2013 14:51:16 +0530
Subject: [PATCH] ahci: sata: add support for exynos5440 sata
In-Reply-To: <20130416091300.GD25040@arwen.pp.htv.fi>
References: <1366103404-14105-1-git-send-email-ks.giri@samsung.com>
 <20130416091300.GD25040@arwen.pp.htv.fi>
Message-ID: <CAKrE-KcvNYNztSfVaecmbu4kbsD5DFM83va0sm8bsSKceBOiNw@mail.gmail.com>

On Tue, Apr 16, 2013 at 2:43 PM, Felipe Balbi <balbi at ti.com> wrote:
> Hi,
>
> On Tue, Apr 16, 2013 at 02:40:04PM +0530, Girish K S wrote:
>> This patch adds the compatible string of the exynos5440 sata controller
>> compliant with the ahci 1.3 and sata 3.0 specification.
>>
>> Signed-off-by: Girish K S <ks.giri at samsung.com>
>> ---
>>  drivers/ata/ahci_platform.c |    1 +
>>  1 files changed, 1 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/ata/ahci_platform.c b/drivers/ata/ahci_platform.c
>> index 7a8a284..c06f021 100644
>> --- a/drivers/ata/ahci_platform.c
>> +++ b/drivers/ata/ahci_platform.c
>> @@ -327,6 +327,7 @@ static SIMPLE_DEV_PM_OPS(ahci_pm_ops, ahci_suspend, ahci_resume);
>>
>>  static const struct of_device_id ahci_of_match[] = {
>>       { .compatible = "snps,spear-ahci", },
>> +     { .compatible = "samsung,exynos5440-ahci", },
>
> is this an IP designed by samsung or something you licensed from e.g
> snps ? If the latter you should add:
>
> "snps,ahci"
>
> instead. Right ?
Yes right. Its a licensed IP. Thanks a lot
>
> --
> balbi


From girishks2000 at gmail.com  Tue Apr 16 05:28:02 2013
From: girishks2000 at gmail.com (Girish K S)
Date: Tue, 16 Apr 2013 14:58:02 +0530
Subject: [PATCH V2] ahci: sata: add support for exynos5440 sata
Message-ID: <1366104482-14240-1-git-send-email-ks.giri@samsung.com>

This patch adds the compatible string of the exynos5440 sata controller
compliant with the ahci 1.3 and sata 3.0 specification.

Signed-off-by: Girish K S <ks.giri at samsung.com>

changes in v2:
		changed the compatible string by adding the actual IP
owners name instead of the SoC vendor name.

---
 drivers/ata/ahci_platform.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/ata/ahci_platform.c b/drivers/ata/ahci_platform.c
index 7a8a284..c06f021 100644
--- a/drivers/ata/ahci_platform.c
+++ b/drivers/ata/ahci_platform.c
@@ -327,6 +327,7 @@ static SIMPLE_DEV_PM_OPS(ahci_pm_ops, ahci_suspend, ahci_resume);
 
 static const struct of_device_id ahci_of_match[] = {
 	{ .compatible = "snps,spear-ahci", },
+	{ .compatible = "snps,exynos5440-ahci", },
 	{},
 };
 MODULE_DEVICE_TABLE(of, ahci_of_match);
-- 
1.7.5.4



From girishks2000 at gmail.com  Tue Apr 16 05:30:11 2013
From: girishks2000 at gmail.com (Girish K S)
Date: Tue, 16 Apr 2013 15:00:11 +0530
Subject: [PATCH V2 2/2] ARM: dts: add dts node for the ahci sata exynos5440
Message-ID: <1366104611-14315-1-git-send-email-ks.giri@samsung.com>

This patch adds dts support for the sata controller

Signed-off-by: Girish K S <ks.giri at samsung.com>
---
 arch/arm/boot/dts/exynos5440.dtsi |    9 +++++++++
 1 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5440.dtsi b/arch/arm/boot/dts/exynos5440.dtsi
index 7c5dc38..2dc4ffa 100644
--- a/arch/arm/boot/dts/exynos5440.dtsi
+++ b/arch/arm/boot/dts/exynos5440.dtsi
@@ -220,4 +220,13 @@
 		clock-names = "rtc";
 		status = "disabled";
 	};
+
+	sata at 210000 {
+		compatible = "snps,exynos5440-ahci";
+		reg = <0x210000 0x10000>;
+		interrupts = <0 30 0>;
+		clocks = <&clock 10>;
+		clock-names = "sata";
+	};
+
 };
-- 
1.7.5.4



From grant.likely at secretlab.ca  Tue Apr 16 06:01:24 2013
From: grant.likely at secretlab.ca (Grant Likely)
Date: Tue, 16 Apr 2013 11:01:24 +0100
Subject: [PATCH] Documentation: dt: update properties in TI GPMC NAND
 example
In-Reply-To: <1365528215-5030-1-git-send-email-jon-hunter@ti.com>
References: <1365528215-5030-1-git-send-email-jon-hunter@ti.com>
Message-ID: <20130416100124.78A3B3E14C0@localhost>

On Tue, 9 Apr 2013 12:23:35 -0500, Jon Hunter <jon-hunter at ti.com> wrote:
> The GPMC timing properties for device-tree have been updated
> by adding a "-ns" or "-ps" suffix to indicate the units of
> time the property represents. Therefore, update the timing
> property names for TI GPMC NAND example.
> 
> Signed-off-by: Jon Hunter <jon-hunter at ti.com>

Acked-by: Grant Likely <grant.likely at secretlab.ca>

> ---
>  .../devicetree/bindings/mtd/gpmc-nand.txt          |   28 ++++++++++----------
>  1 file changed, 14 insertions(+), 14 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
> index e7f8d7e..6a983c1 100644
> --- a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
> +++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
> @@ -56,20 +56,20 @@ Example for an AM33xx board:
>  			nand-bus-width = <16>;
>  			ti,nand-ecc-opt = "bch8";
>  
> -			gpmc,sync-clk = <0>;
> -			gpmc,cs-on = <0>;
> -			gpmc,cs-rd-off = <44>;
> -			gpmc,cs-wr-off = <44>;
> -			gpmc,adv-on = <6>;
> -			gpmc,adv-rd-off = <34>;
> -			gpmc,adv-wr-off = <44>;
> -			gpmc,we-off = <40>;
> -			gpmc,oe-off = <54>;
> -			gpmc,access = <64>;
> -			gpmc,rd-cycle = <82>;
> -			gpmc,wr-cycle = <82>;
> -			gpmc,wr-access = <40>;
> -			gpmc,wr-data-mux-bus = <0>;
> +			gpmc,sync-clk-ps = <0>;
> +			gpmc,cs-on-ns = <0>;
> +			gpmc,cs-rd-off-ns = <44>;
> +			gpmc,cs-wr-off-ns = <44>;
> +			gpmc,adv-on-ns = <6>;
> +			gpmc,adv-rd-off-ns = <34>;
> +			gpmc,adv-wr-off-ns = <44>;
> +			gpmc,we-off-ns = <40>;
> +			gpmc,oe-off-ns = <54>;
> +			gpmc,access-ns = <64>;
> +			gpmc,rd-cycle-ns = <82>;
> +			gpmc,wr-cycle-ns = <82>;
> +			gpmc,wr-access-ns = <40>;
> +			gpmc,wr-data-mux-bus-ns = <0>;
>  
>  			#address-cells = <1>;
>  			#size-cells = <1>;
> -- 
> 1.7.10.4
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 
Grant Likely, B.Sc, P.Eng.
Secret Lab Technologies, Ltd.


From nicolas.ferre at atmel.com  Tue Apr 16 06:03:45 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Tue, 16 Apr 2013 12:03:45 +0200
Subject: [PATCH 1/3] at_hdmac: move to generic DMA binding
In-Reply-To: <1366028217-5037-2-git-send-email-ludovic.desroches@atmel.com>
References: <1366028217-5037-1-git-send-email-ludovic.desroches@atmel.com>
 <1366028217-5037-2-git-send-email-ludovic.desroches@atmel.com>
Message-ID: <516D2201.8030002@atmel.com>

On 04/15/2013 02:16 PM, ludovic.desroches at atmel.com :
> From: Ludovic Desroches <ludovic.desroches at atmel.com>
> 
> Update at_hdmac driver to support generic DMA device tree binding. Devices
> can still request channel with dma_request_channel() then it doesn't break
> DMA for non DT boards.
> 
> Signed-off-by: Ludovic Desroches <ludovic.desroches at atmel.com>

Some minor comments but the overall is good: so, after adding a little
more explanation to documentation:

Acked-by: Nicolas Ferre <nicolas.ferre at atmel.com>

Very nice and concise patch for adding such an important feature: kudos!


> ---
>  .../devicetree/bindings/dma/atmel-dma.txt          | 26 +++++-
>  arch/arm/boot/dts/sama5d3.dtsi                     |  4 +-

Maybe we can have a separate patch for .dtsi modifications.

>  drivers/dma/at_hdmac.c                             | 93 ++++++++++++++++++++--
>  drivers/dma/at_hdmac_regs.h                        |  4 +
>  4 files changed, 117 insertions(+), 10 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/dma/atmel-dma.txt b/Documentation/devicetree/bindings/dma/atmel-dma.txt
> index 3c046ee..4179bd2 100644
> --- a/Documentation/devicetree/bindings/dma/atmel-dma.txt
> +++ b/Documentation/devicetree/bindings/dma/atmel-dma.txt
> @@ -4,11 +4,33 @@ Required properties:
>  - compatible: Should be "atmel,<chip>-dma"
>  - reg: Should contain DMA registers location and length
>  - interrupts: Should contain DMA interrupt
> +- #dma-cells: Must be <2>

Maybe add some explanation (taken from pl330): "used to represent the
number of integer cells in the dmas property of client device."



> -Examples:
> +Example:
>  
> -dma at ffffec00 {
> +dma0: dma at ffffec00 {
>  	compatible = "atmel,at91sam9g45-dma";
>  	reg = <0xffffec00 0x200>;
>  	interrupts = <21>;
> +	#dma-cells = <2>;
> +};
> +
> +DMA clients connected to the Atmel DMA controller must use the format
> +described in the dma.txt file, using a three-cell specifier for each channel

(to establish the link with the #dma-cells property:)
"
using a three-cell specifier for each channel: a phandle plus two
integer cells.
"

> +The three cells in order are:
> +
> +1. A phandle pointing to the DMA controller
> +2. The memory interface (16 most significant bits), the peripheral interface
> +(16 less significant bits)
> +3. The peripheral identifier (can be different for tx and rx)

Yes but the peripheral identifier needs more explanation: what about:
"
Peripheral identifier for the hardware handshaking interface. The
identifier can be different for tx and rx.
"

> +
> +Example:
> +
> +i2c0 at i2c@f8010000 {
> +	compatible = "atmel,at91sam9x5-i2c";
> +	reg = <0xf8010000 0x100>;
> +	interrupts = <9 4 6>;
> +	dmas = <&dma0 1 7>,
> +	       <&dma0 1 8>;
> +	dma-names = "tx", "rx"
>  };
> diff --git a/arch/arm/boot/dts/sama5d3.dtsi b/arch/arm/boot/dts/sama5d3.dtsi
> index 39b0458..95c00a3 100644
> --- a/arch/arm/boot/dts/sama5d3.dtsi
> +++ b/arch/arm/boot/dts/sama5d3.dtsi

Ditto.

> @@ -348,14 +348,14 @@
>  				compatible = "atmel,at91sam9g45-dma";
>  				reg = <0xffffe600 0x200>;
>  				interrupts = <30 4 0>;
> -				#dma-cells = <1>;
> +				#dma-cells = <2>;
>  			};
>  
>  			dma1: dma-controller at ffffe800 {
>  				compatible = "atmel,at91sam9g45-dma";
>  				reg = <0xffffe800 0x200>;
>  				interrupts = <31 4 0>;
> -				#dma-cells = <1>;
> +				#dma-cells = <2>;
>  			};
>  
>  			ramc0: ramc at ffffea00 {
> diff --git a/drivers/dma/at_hdmac.c b/drivers/dma/at_hdmac.c
> index 8415467..d5f7a1b 100644
> --- a/drivers/dma/at_hdmac.c
> +++ b/drivers/dma/at_hdmac.c
> @@ -24,6 +24,7 @@
>  #include <linux/slab.h>
>  #include <linux/of.h>
>  #include <linux/of_device.h>
> +#include <linux/of_dma.h>
>  
>  #include "at_hdmac_regs.h"
>  #include "dmaengine.h"
> @@ -676,7 +677,7 @@ atc_prep_slave_sg(struct dma_chan *chan, struct scatterlist *sgl,
>  		ctrlb |=  ATC_DST_ADDR_MODE_FIXED
>  			| ATC_SRC_ADDR_MODE_INCR
>  			| ATC_FC_MEM2PER
> -			| ATC_SIF(AT_DMA_MEM_IF) | ATC_DIF(AT_DMA_PER_IF);
> +			| ATC_SIF(atchan->mem_if) | ATC_DIF(atchan->per_if);
>  		reg = sconfig->dst_addr;
>  		for_each_sg(sgl, sg, sg_len, i) {
>  			struct at_desc	*desc;
> @@ -715,7 +716,7 @@ atc_prep_slave_sg(struct dma_chan *chan, struct scatterlist *sgl,
>  		ctrlb |=  ATC_DST_ADDR_MODE_INCR
>  			| ATC_SRC_ADDR_MODE_FIXED
>  			| ATC_FC_PER2MEM
> -			| ATC_SIF(AT_DMA_PER_IF) | ATC_DIF(AT_DMA_MEM_IF);
> +			| ATC_SIF(atchan->per_if) | ATC_DIF(atchan->mem_if);
>  
>  		reg = sconfig->src_addr;
>  		for_each_sg(sgl, sg, sg_len, i) {
> @@ -821,8 +822,8 @@ atc_dma_cyclic_fill_desc(struct dma_chan *chan, struct at_desc *desc,
>  		desc->lli.ctrlb = ATC_DST_ADDR_MODE_FIXED
>  				| ATC_SRC_ADDR_MODE_INCR
>  				| ATC_FC_MEM2PER
> -				| ATC_SIF(AT_DMA_MEM_IF)
> -				| ATC_DIF(AT_DMA_PER_IF);
> +				| ATC_SIF(atchan->mem_if)
> +				| ATC_DIF(atchan->per_if);
>  		break;
>  
>  	case DMA_DEV_TO_MEM:
> @@ -832,8 +833,8 @@ atc_dma_cyclic_fill_desc(struct dma_chan *chan, struct at_desc *desc,
>  		desc->lli.ctrlb = ATC_DST_ADDR_MODE_INCR
>  				| ATC_SRC_ADDR_MODE_FIXED
>  				| ATC_FC_PER2MEM
> -				| ATC_SIF(AT_DMA_PER_IF)
> -				| ATC_DIF(AT_DMA_MEM_IF);
> +				| ATC_SIF(atchan->per_if)
> +				| ATC_DIF(atchan->mem_if);
>  		break;
>  
>  	default:
> @@ -1189,6 +1190,67 @@ static void atc_free_chan_resources(struct dma_chan *chan)
>  	dev_vdbg(chan2dev(chan), "free_chan_resources: done\n");
>  }
>  
> +static bool at_dma_filter(struct dma_chan *chan, void *slave)
> +{
> +	struct at_dma_slave *atslave = slave;
> +
> +	if (atslave->dma_dev == chan->device->dev) {
> +		chan->private = atslave;
> +		return true;
> +	} else {
> +		return false;
> +	}
> +}
> +
> +#ifdef CONFIG_OF
> +static struct dma_chan *at_dma_xlate(struct of_phandle_args *dma_spec,
> +				     struct of_dma *of_dma)
> +{
> +	struct dma_chan *chan;
> +	struct at_dma_chan *atchan;
> +	struct at_dma_slave *atslave;
> +	dma_cap_mask_t mask;
> +	unsigned int per_id;
> +	struct platform_device *dmac_pdev;
> +
> +	if (dma_spec->args_count != 2)
> +		return NULL;
> +
> +	dmac_pdev = of_find_device_by_node(dma_spec->np);
> +
> +	dma_cap_zero(mask);
> +	dma_cap_set(DMA_SLAVE, mask);
> +
> +	atslave = devm_kzalloc(&dmac_pdev->dev, sizeof(*atslave), GFP_KERNEL);
> +	if (!atslave)
> +		return NULL;
> +	/*
> +	 * We can fill both SRC_PER and DST_PER, one of these fields will be
> +	 * ignored depending on DMA transfer direction.
> +	 */
> +	per_id = dma_spec->args[1];
> +	atslave->cfg = ATC_FIFOCFG_HALFFIFO | ATC_DST_H2SEL_HW
> +		      | ATC_SRC_H2SEL_HW | ATC_DST_PER(per_id)
> +		      | ATC_SRC_PER(per_id);
> +	atslave->dma_dev = &dmac_pdev->dev;
> +
> +	chan = dma_request_channel(mask, at_dma_filter, atslave);
> +	if (!chan)
> +		return NULL;
> +
> +	atchan = to_at_dma_chan(chan);
> +	atchan->per_if = dma_spec->args[0] & 0xff;
> +	atchan->mem_if = (dma_spec->args[0] >> 16) & 0xff;
> +
> +	return chan;
> +}
> +#else
> +static struct dma_chan *at_dma_xlate(struct of_phandle_args *dma_spec,
> +				     struct of_dma *of_dma)
> +{
> +	return NULL;
> +}
> +#endif
>  
>  /*--  Module Management  -----------------------------------------------*/
>  
> @@ -1343,6 +1405,8 @@ static int __init at_dma_probe(struct platform_device *pdev)
>  	for (i = 0; i < plat_dat->nr_channels; i++) {
>  		struct at_dma_chan	*atchan = &atdma->chan[i];
>  
> +		atchan->mem_if = AT_DMA_MEM_IF;
> +		atchan->per_if = AT_DMA_PER_IF;
>  		atchan->chan_common.device = &atdma->dma_common;
>  		dma_cookie_init(&atchan->chan_common);
>  		list_add_tail(&atchan->chan_common.device_node,
> @@ -1389,8 +1453,25 @@ static int __init at_dma_probe(struct platform_device *pdev)
>  
>  	dma_async_device_register(&atdma->dma_common);
>  
> +	/*
> +	 * Do not return an error if the dmac node is not present in order to
> +	 * not break the existing way of requesting channel with
> +	 * dma_request_channel().
> +	 */
> +	if (pdev->dev.of_node) {
> +		err = of_dma_controller_register(pdev->dev.of_node,
> +						 at_dma_xlate, atdma);
> +		if (err) {
> +			dev_err(&pdev->dev, "could not register of_dma_controller\n");
> +			goto err_of_dma_controller_register;
> +		}
> +	}
> +
>  	return 0;
>  
> +err_of_dma_controller_register:
> +	dma_async_device_unregister(&atdma->dma_common);
> +	dma_pool_destroy(atdma->dma_desc_pool);
>  err_pool_create:
>  	platform_set_drvdata(pdev, NULL);
>  	free_irq(platform_get_irq(pdev, 0), atdma);
> diff --git a/drivers/dma/at_hdmac_regs.h b/drivers/dma/at_hdmac_regs.h
> index 0eb3c13..c604d26 100644
> --- a/drivers/dma/at_hdmac_regs.h
> +++ b/drivers/dma/at_hdmac_regs.h
> @@ -220,6 +220,8 @@ enum atc_status {
>   * @device: parent device
>   * @ch_regs: memory mapped register base
>   * @mask: channel index in a mask
> + * @per_if: peripheral interface
> + * @mem_if: memory interface
>   * @status: transmit status information from irq/prep* functions
>   *                to tasklet (use atomic operations)
>   * @tasklet: bottom half to finish transaction work
> @@ -238,6 +240,8 @@ struct at_dma_chan {
>  	struct at_dma		*device;
>  	void __iomem		*ch_regs;
>  	u8			mask;
> +	u8			per_if;
> +	u8			mem_if;
>  	unsigned long		status;
>  	struct tasklet_struct	tasklet;
>  	u32			save_cfg;
> 


-- 
Nicolas Ferre


From nicolas.ferre at atmel.com  Tue Apr 16 06:06:25 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Tue, 16 Apr 2013 12:06:25 +0200
Subject: [PATCH 3/3] mci: at91: convert to
 dma_request_slave_channel_compat()
In-Reply-To: <1366028217-5037-4-git-send-email-ludovic.desroches@atmel.com>
References: <1366028217-5037-1-git-send-email-ludovic.desroches@atmel.com>
 <1366028217-5037-4-git-send-email-ludovic.desroches@atmel.com>
Message-ID: <516D22A1.6010508@atmel.com>

On 04/15/2013 02:16 PM, ludovic.desroches at atmel.com :
> From: Ludovic Desroches <ludovic.desroches at atmel.com>
> 
> Use generic DMA DT helper. Platforms booting with or without DT populated are
> both supported.
> 
> Signed-off-by: Ludovic Desroches <ludovic.desroches at atmel.com>

Acked-by: Nicolas Ferre <nicolas.ferre at atmel.com>

> ---
>  drivers/mmc/host/atmel-mci.c | 25 ++++++++++++-------------
>  1 file changed, 12 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/mmc/host/atmel-mci.c b/drivers/mmc/host/atmel-mci.c
> index 10f8b73..73d5d24 100644
> --- a/drivers/mmc/host/atmel-mci.c
> +++ b/drivers/mmc/host/atmel-mci.c
> @@ -2224,10 +2224,15 @@ static void __exit atmci_cleanup_slot(struct atmel_mci_slot *slot,
>  	mmc_free_host(slot->mmc);
>  }
>  
> -static bool atmci_filter(struct dma_chan *chan, void *slave)
> +static bool atmci_filter(struct dma_chan *chan, void *pdata)
>  {
> -	struct mci_dma_data	*sl = slave;
> +	struct mci_platform_data *sl_pdata = pdata;
> +	struct mci_dma_data *sl;
>  
> +	if (!sl_pdata)
> +		return false;
> +
> +	sl = sl_pdata->dma_slave;
>  	if (sl && find_slave_dev(sl) == chan->device->dev) {
>  		chan->private = slave_data_ptr(sl);
>  		return true;
> @@ -2239,24 +2244,18 @@ static bool atmci_filter(struct dma_chan *chan, void *slave)
>  static bool atmci_configure_dma(struct atmel_mci *host)
>  {
>  	struct mci_platform_data	*pdata;
> +	dma_cap_mask_t mask;
>  
>  	if (host == NULL)
>  		return false;
>  
>  	pdata = host->pdev->dev.platform_data;
>  
> -	if (!pdata)
> -		return false;
> +	dma_cap_zero(mask);
> +	dma_cap_set(DMA_SLAVE, mask);
>  
> -	if (pdata->dma_slave && find_slave_dev(pdata->dma_slave)) {
> -		dma_cap_mask_t mask;
> -
> -		/* Try to grab a DMA channel */
> -		dma_cap_zero(mask);
> -		dma_cap_set(DMA_SLAVE, mask);
> -		host->dma.chan =
> -			dma_request_channel(mask, atmci_filter, pdata->dma_slave);
> -	}
> +	host->dma.chan = dma_request_slave_channel_compat(mask, atmci_filter, pdata,
> +						   	  &host->pdev->dev, "rxtx");
>  	if (!host->dma.chan) {
>  		dev_warn(&host->pdev->dev, "no DMA channel available\n");
>  		return false;
> 


-- 
Nicolas Ferre


From kishon at ti.com  Tue Apr 16 06:18:07 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Tue, 16 Apr 2013 15:48:07 +0530
Subject: [PATCH v3 1/6] drivers: phy: add generic PHY framework
In-Reply-To: <20130415195030.9F7E93E0AA8@localhost>
References: <1363770725-13717-1-git-send-email-kishon@ti.com>
 <1363770725-13717-2-git-send-email-kishon@ti.com>
 <20130415113416.7C3943E0AA8@localhost> <516BF1E2.3020104@ti.com>
 <20130415195030.9F7E93E0AA8@localhost>
Message-ID: <516D255F.40604@ti.com>

Hi,

On Tuesday 16 April 2013 01:20 AM, Grant Likely wrote:
> On Mon, 15 Apr 2013 17:56:10 +0530, Kishon Vijay Abraham I <kishon at ti.com> wrote:
>> Hi,
>>
>> On Monday 15 April 2013 05:04 PM, Grant Likely wrote:
>>> On Wed, 20 Mar 2013 14:42:00 +0530, Kishon Vijay Abraham I <kishon at ti.com> wrote:
>>>> The PHY framework provides a set of APIs for the PHY drivers to
>>>> create/destroy a PHY and APIs for the PHY users to obtain a reference to the
>>>> PHY with or without using phandle. To obtain a reference to the PHY without
>>>> using phandle, the platform specfic intialization code (say from board file)
>>>> should have already called phy_bind with the binding information. The binding
>>>> information consists of phy's device name, phy user device name and an index.
>>>> The index is used when the same phy user binds to mulitple phys.
>>>>
>>>> PHY drivers should create the PHY by passing phy_descriptor that has
>>>> describes the PHY (label, type etc..) and ops like init, exit, suspend, resume,
>>>> poweron, shutdown.
>>>>
>>>> The documentation for the generic PHY framework is added in
>>>> Documentation/phy.txt and the documentation for the sysfs entry is added
>>>> in Documentation/ABI/testing/sysfs-class-phy.
>>>>
>>>> Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
>>>
>>> Hi Kishon,
>>>
>>> For review purposes, I'll skip most of the implementation and focus on
>>> the data structures. I think you need to take another look at the
>>> approach your using. The kernel already provides a lot of support for
>>> implementing devices and binding them to drivers that you should be
>>> able to use...
>>>
>>>
>>> [...]
>>>> +/**
>>>> + * struct phy - represent the phy device
>>>> + * @dev: phy device
>>>> + * @label: label given to phy
>>>> + * @type: specifies the phy type
>>>> + * @of_node: device node of the phy
>>>> + * @ops: function pointers for performing phy operations
>>>> + */
>>>> +struct phy {
>>>> +	struct device		dev;
>>>> +	const char		*label;
>>>> +	int			type;
>>>> +	struct bus_type		*bus;
>>>> +	struct device_node	*of_node;
>>>> +	struct phy_ops		*ops;
>>>> +};
>>>
>>> Alright, so the core of the functionality is this 'struct phy' which
>>> tracks all the instances of PHY devices. As I understand it each
>>> physical phy will have a 'struct phy' instance tracking it. That makes
>>> sense.
>>>
>>> struct phy embeds a struct device. Also good. The linux driver model
>>> knows all about devices and how to handle them. However, most of the
>>> rest of this structure looks to be reinventing stuff the driver model
>>> already does.
>>>
>>> 'label' seems unnecessary. struct device embeds a struct kobject, which
>>> means it has a name and shows up in sysfs. Is there a reason that the
>>> device name cannot be used directly?
>>
>> hmm.. the label name is supposed to be a simpler name than device name.
>> Say for instance "omap-usb2.1.auto" device name can simply be
>> "omap-usb2-phy". Further the device name while using dt will have
>> register address in it. However it's used only for displaying the label
>> in sysfs entry (/sys/class/phy/<phy>/label).
>
> I wouldn't go mucking with names in that way. Stick with one name and
> drop the separate label. Otherwise you introduce addtional sources of
> confusion.

hmm.. ok.
>
>>>
>>> 'type' I just don't understand. I don't see any users of it in this
>>> patch. I only see where it is set.
>>
>> yeah. Was planning to remove this in my next version (btw the latest is
>> version 5).
>>>
>>> 'bus' absolutely should not be here. The bus type should be set in the
>>> struct device by this subsystem when the device gets registered. There
>>> is no reason to have a pointer to it here.
>>
>> right. I had removed it in version 5 of this patch series.
>>>
>>> 'of_node' is already in struct device
>>
>> I wasn't sure if we can manually assign the of_node of one device to
>> of_node of an another device. Here the of_node comes from _phy provider_.
>
> There is no problem with multiple devices referencing the same node. The
> only time it may cause problems is when two devices of the same bus type
> are referencing the same of_node. In that situation the device will get
> probed more than once. You're not in that situation.

right. Will re-use of_node.
>
>>> Finally, it really doesn't look right for a device object to have an
>>> 'ops' structure. The whole point of the driver model is that a struct
>>> device doesn't encapsulate any behaviour. A device gets registers to a
>>> bus type, and then the driver core will associate a struct device_driver
>>
>> We have decided not to implement the PHY layer as a separate bus layer.
>> The PHY provider can be part of any other bus. Making the PHY layer as a
>> bus will make the PHY provider to be part of multiple buses which will
>> lead to bad design. All we are trying to do here is keep the pool of PHY
>> devices under PHY class in this layer and help any controller that wants
>> to use the PHY to get it.
>
> If you're using a class, then you already have your list of registered
> phy devices! :-) No need to create another global list that you need to
> manage.

right. We already use _class_dev_iter_ for finding the phy device.
.
.
+static struct phy *of_phy_lookup(struct device *dev, struct device_node 
*node)
+{
+	struct phy *phy;
+	struct class_dev_iter iter;
+
+	class_dev_iter_init(&iter, phy_class, NULL, NULL);
+	while ((dev = class_dev_iter_next(&iter))) {
+		phy = container_of(dev, struct phy, dev);
+		if (node != phy->of_node)
+			continue;
+
+		class_dev_iter_exit(&iter);
+		return phy;
+	}
+
+	class_dev_iter_exit(&iter);
+	return ERR_PTR(-EPROBE_DEFER);
+}
.
.

however we can't get rid of the other list (phy_bind_list) where we 
maintain the phy binding information. It's used for the non-dt boot case.
>
> You really need to be careful here though. By lumping all the phy types
> into a single pot your glossing over the fact that different subsystems
> have phys that behave differently. It is just fine to have a framework
> that works in lots of places, it's actively encouraged, but by putting
> the struct device into struct phy, you're taping into a large amount of
> assumptions that the linux kernel makes about what devices are. For
> instance, it is generally assumed that a class contains a bunch of the
> same devices; but in this framework it is explicitly not true.
>
> I would also imagine that each of the subsystems will want to wrap the
> struct phy with subsystem specific additions so it will be important to
> ensure the correct type of device is always returned.

right. Probably this framework right now tries to implement the 
simplest/default case which wouldn't need subsystem specific additions. 
But yes, we might need to add subsystem specific additions in the future.
>
> You'd be better off providing a set of utility functions that work for
> all the types of phys, but have a separate instance for each one. For
> example, you could have a separate class for each phy type, but all of
> them use the same utility function.
>
>>> to a device that it is able to drive, and the struct device_driver is
>>> supposed to contain any ops structure used to control the device.
>>>
>>>> +
>>>> +/**
>>>> + * struct phy_bind - represent the binding for the phy
>>>> + * @dev_name: the device name of the device that will bind to the phy
>>>> + * @phy_dev_name: the device name of the phy
>>>> + * @index: used if a single controller uses multiple phys
>>>> + * @auto_bind: tells if the binding is done explicitly from board file or not
>>>> + * @phy: reference to the phy
>>>> + * @list: to maintain a linked list of the binding information
>>>> + */
>>>> +struct phy_bind {
>>>> +	const char	*dev_name;
>>>> +	const char	*phy_dev_name;
>>>> +	int		index;
>>>> +	int		auto_bind:1;
>>>> +	struct phy	*phy;
>>>> +	struct list_head list;
>>>> +};
>>>
>>> How are PHYs attached to the system. Would the PHY be a direct child of
>>> the host controller device, or would a PHY hang off another bus (like
>>> i2c) for control? (this is how Ethernet phys work; they hang off the
>>> MDIO bus, but may be attached to any Ethernet controller).
>>
>> This layer does not have any restriction on how the PHY is attached to
>> the system. For all the sample cases (USB OTG controller in OMAP
>> platforms) that follows this patch, the PHY is attached to the platform
>> bus and the PHY provider is a platform driver. All this framework does
>> is maintain a list of PHY's added in the system and helps the controller
>> to find the appropriate PHY.
>
> Okay, that's what I thought. A lot of systems end up looking this way.
> So I would assume that for an i2c-controlled phy, and i2c driver would
> bind against the device, and the probe hook would create and register a
> phy device. That would make the sysfs tree look something like:
>
> /sys/devices/.../i2c at 80000000/usbphy at 2/phy0
>
> where, i2c at 80000000 is the i2c master, usbphy at 2 is what the phy's driver
> binds against, and phy0 is created and registered by the driver of
> usbphy at 2 at probe time. Correct?

correct.
>
>> We are currently not looking at having Ethernet use this layer because
>> it itself has a comprehensive PHY layer and merging it with this will
>> take some effort. However other subsystems like USB, SATA, video etc..
>> can make use of this.
>>>
>>> Since there is at most a 1:N relationship between host controllers and
>>> PHYs, there shouldn't be any need for a separate structure to describe
>>> binding. Put the inding data into the struct phy itself. Each host
>>> controller can have a list of phys that it is bound to.
>>
>> No. Having the host controller to have a list of phys wont be a good
>> idea IMHO. The host controller is just an IP and the PHY to which it
>> will be connected can vary from board to board, platform to platform. So
>> ideally this binding should come from platform initialization code/dt data.
>
> That is not what I mean. I mean the host controller instance should
> contain a list of all the PHYs that are attached to it. There should not

Doesn't sound correct IMO. The host controller instance need not know 
anything about the PHY instances that is connected to it. Think of it 
similar to regulator, the controller wouldn't know which regulator it is 
connected to, all it has to know is it just has a regulator connected to 
it. It's up-to the regulator framework to give the controller the 
correct regulator. It's similar here. It makes sense for me to keep a 
list in the PHY framework in order for it to return the correct PHY (but 
note that this list is not needed for dt boot).

Thanks
Kishon


From Andrew.Murray at arm.com  Tue Apr 16 06:18:25 2013
From: Andrew.Murray at arm.com (Andrew Murray)
Date: Tue, 16 Apr 2013 11:18:25 +0100
Subject: [PATCH v7 0/3] of/pci: Provide common support for PCI DT parsing
Message-ID: <1366107508-12672-1-git-send-email-Andrew.Murray@arm.com>

This patchset factors out duplicated code associated with parsing PCI
DT "ranges" properties across the architectures and introduces a
"ranges" parser. This parser "of_pci_range_parser" can be used directly
by ARM host bridge drivers enabling them to obtain ranges from device
trees.

I've included the Reviewed-by and Tested-by's received from v5/v6 in this
patchset, earlier versions of this patchset (v3) have been tested-by:

Thierry Reding <thierry.reding at avionic-design.de>
Jingoo Han <jg1.han at samsung.com>

I've tested that this patchset builds and runs on ARM and that it builds on
PowerPC and x86_64.

Compared to the v6 sent by Andrew Murray, the following changes have
been made in response to build errors/warnings:

 * Inclusion of linux/of_address.h in of_pci.c as suggested by Michal
   Simek to prevent compilation failures on Microblaze (and others) and his
   ack.

 * Use of externs, static inlines and a typo in linux/of_address.h in response
   to linker errors (multiple defination) on x86_64 as spotted by a kbuild test
   robot on (jcooper/linux.git mvebu/drivers)

 * Add EXPORT_SYMBOL_GPL to of_pci_range_parser function to be consistent
   with of_pci_process_ranges function

Compared to the v5 sent by Andrew Murray, the following changes have
been made:

 * Use of CONFIG_64BIT instead of CONFIG_[a32bitarch] as suggested by
   Rob Herring in drivers/of/of_pci.c

 * Added forward declaration of struct pci_controller in linux/of_pci.h
   to prevent compiler warning as suggested by Thomas Petazzoni

 * Improved error checking (!range check), removal of unnecessary be32_to_cpup
   call, improved formatting of struct of_pci_range_parser layout and
   replacement of macro with a static inline. All suggested by Rob Herring.

Compared to the v4 (incorrectly labelled v3) sent by Andrew Murray,
the following changes have been made:

 * Split the patch as suggested by Rob Herring

Compared to the v3 sent by Andrew Murray, the following changes have
been made:

 * Unify and move duplicate pci_process_bridge_OF_ranges functions to
   drivers/of/of_pci.c as suggested by Rob Herring

 * Fix potential build errors with Microblaze/MIPS

Compared to "[PATCH v5 01/17] of/pci: Provide support for parsing PCI DT
ranges property", the following changes have been made:

 * Correct use of IORESOURCE_* as suggested by Russell King

 * Improved interface and naming as suggested by Thierry Reding

Compared to the v2 sent by Andrew Murray, Thomas Petazzoni did:

 * Add a memset() on the struct of_pci_range_iter when starting the
   for loop in for_each_pci_range(). Otherwise, with an uninitialized
   of_pci_range_iter, of_pci_process_ranges() may crash.

 * Add parenthesis around 'res', 'np' and 'iter' in the
   for_each_of_pci_range macro definitions. Otherwise, passing
   something like &foobar as 'res' didn't work.

 * Rebased on top of 3.9-rc2, which required fixing a few conflicts in
   the Microblaze code.

v2:
  This follows on from suggestions made by Grant Likely
  (marc.info/?l=linux-kernel&m=136079602806328)

Andrew Murray (3):
  of/pci: Unify pci_process_bridge_OF_ranges from Microblaze and
    PowerPC
  of/pci: Provide support for parsing PCI DT ranges property
  of/pci: mips: convert to common of_pci_range_parser

 arch/microblaze/include/asm/pci-bridge.h |    5 +-
 arch/microblaze/pci/pci-common.c         |  192 ------------------------------
 arch/mips/pci/pci.c                      |   50 +++------
 arch/powerpc/include/asm/pci-bridge.h    |    5 +-
 arch/powerpc/kernel/pci-common.c         |  192 ------------------------------
 drivers/of/address.c                     |   67 +++++++++++
 drivers/of/of_pci.c                      |  169 ++++++++++++++++++++++++++
 include/linux/of_address.h               |   46 +++++++
 include/linux/of_pci.h                   |    4 +
 9 files changed, 304 insertions(+), 426 deletions(-)


From Andrew.Murray at arm.com  Tue Apr 16 06:18:26 2013
From: Andrew.Murray at arm.com (Andrew Murray)
Date: Tue, 16 Apr 2013 11:18:26 +0100
Subject: [PATCH v7 1/3] of/pci: Unify pci_process_bridge_OF_ranges from
 Microblaze and PowerPC
In-Reply-To: <1366107508-12672-1-git-send-email-Andrew.Murray@arm.com>
References: <1366107508-12672-1-git-send-email-Andrew.Murray@arm.com>
Message-ID: <1366107508-12672-2-git-send-email-Andrew.Murray@arm.com>

The pci_process_bridge_OF_ranges function, used to parse the "ranges"
property of a PCI host device, is found in both Microblaze and PowerPC
architectures. These implementations are nearly identical. This patch
moves this common code to a common place.

Signed-off-by: Andrew Murray <Andrew.Murray at arm.com>
Signed-off-by: Liviu Dudau <Liviu.Dudau at arm.com>
Reviewed-by: Rob Herring <rob.herring at calxeda.com>
Tested-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Tested-by: Linus Walleij <linus.walleij at linaro.org>
Acked-by: Michal Simek <monstr at monstr.eu>
---
 arch/microblaze/include/asm/pci-bridge.h |    5 +-
 arch/microblaze/pci/pci-common.c         |  192 ----------------------------
 arch/powerpc/include/asm/pci-bridge.h    |    5 +-
 arch/powerpc/kernel/pci-common.c         |  192 ----------------------------
 drivers/of/of_pci.c                      |  200 ++++++++++++++++++++++++++++++
 include/linux/of_pci.h                   |    4 +
 6 files changed, 206 insertions(+), 392 deletions(-)

diff --git a/arch/microblaze/include/asm/pci-bridge.h b/arch/microblaze/include/asm/pci-bridge.h
index cb5d397..5783cd6 100644
--- a/arch/microblaze/include/asm/pci-bridge.h
+++ b/arch/microblaze/include/asm/pci-bridge.h
@@ -10,6 +10,7 @@
 #include <linux/pci.h>
 #include <linux/list.h>
 #include <linux/ioport.h>
+#include <linux/of_pci.h>
 
 struct device_node;
 
@@ -132,10 +133,6 @@ extern void setup_indirect_pci(struct pci_controller *hose,
 extern struct pci_controller *pci_find_hose_for_OF_device(
 			struct device_node *node);
 
-/* Fill up host controller resources from the OF node */
-extern void pci_process_bridge_OF_ranges(struct pci_controller *hose,
-			struct device_node *dev, int primary);
-
 /* Allocate & free a PCI host bridge structure */
 extern struct pci_controller *pcibios_alloc_controller(struct device_node *dev);
 extern void pcibios_free_controller(struct pci_controller *phb);
diff --git a/arch/microblaze/pci/pci-common.c b/arch/microblaze/pci/pci-common.c
index 9ea521e..2735ad9 100644
--- a/arch/microblaze/pci/pci-common.c
+++ b/arch/microblaze/pci/pci-common.c
@@ -622,198 +622,6 @@ void pci_resource_to_user(const struct pci_dev *dev, int bar,
 	*end = rsrc->end - offset;
 }
 
-/**
- * pci_process_bridge_OF_ranges - Parse PCI bridge resources from device tree
- * @hose: newly allocated pci_controller to be setup
- * @dev: device node of the host bridge
- * @primary: set if primary bus (32 bits only, soon to be deprecated)
- *
- * This function will parse the "ranges" property of a PCI host bridge device
- * node and setup the resource mapping of a pci controller based on its
- * content.
- *
- * Life would be boring if it wasn't for a few issues that we have to deal
- * with here:
- *
- *   - We can only cope with one IO space range and up to 3 Memory space
- *     ranges. However, some machines (thanks Apple !) tend to split their
- *     space into lots of small contiguous ranges. So we have to coalesce.
- *
- *   - We can only cope with all memory ranges having the same offset
- *     between CPU addresses and PCI addresses. Unfortunately, some bridges
- *     are setup for a large 1:1 mapping along with a small "window" which
- *     maps PCI address 0 to some arbitrary high address of the CPU space in
- *     order to give access to the ISA memory hole.
- *     The way out of here that I've chosen for now is to always set the
- *     offset based on the first resource found, then override it if we
- *     have a different offset and the previous was set by an ISA hole.
- *
- *   - Some busses have IO space not starting at 0, which causes trouble with
- *     the way we do our IO resource renumbering. The code somewhat deals with
- *     it for 64 bits but I would expect problems on 32 bits.
- *
- *   - Some 32 bits platforms such as 4xx can have physical space larger than
- *     32 bits so we need to use 64 bits values for the parsing
- */
-void pci_process_bridge_OF_ranges(struct pci_controller *hose,
-				  struct device_node *dev, int primary)
-{
-	const u32 *ranges;
-	int rlen;
-	int pna = of_n_addr_cells(dev);
-	int np = pna + 5;
-	int memno = 0, isa_hole = -1;
-	u32 pci_space;
-	unsigned long long pci_addr, cpu_addr, pci_next, cpu_next, size;
-	unsigned long long isa_mb = 0;
-	struct resource *res;
-
-	pr_info("PCI host bridge %s %s ranges:\n",
-	       dev->full_name, primary ? "(primary)" : "");
-
-	/* Get ranges property */
-	ranges = of_get_property(dev, "ranges", &rlen);
-	if (ranges == NULL)
-		return;
-
-	/* Parse it */
-	pr_debug("Parsing ranges property...\n");
-	while ((rlen -= np * 4) >= 0) {
-		/* Read next ranges element */
-		pci_space = ranges[0];
-		pci_addr = of_read_number(ranges + 1, 2);
-		cpu_addr = of_translate_address(dev, ranges + 3);
-		size = of_read_number(ranges + pna + 3, 2);
-
-		pr_debug("pci_space: 0x%08x pci_addr:0x%016llx ",
-				pci_space, pci_addr);
-		pr_debug("cpu_addr:0x%016llx size:0x%016llx\n",
-					cpu_addr, size);
-
-		ranges += np;
-
-		/* If we failed translation or got a zero-sized region
-		 * (some FW try to feed us with non sensical zero sized regions
-		 * such as power3 which look like some kind of attempt
-		 * at exposing the VGA memory hole)
-		 */
-		if (cpu_addr == OF_BAD_ADDR || size == 0)
-			continue;
-
-		/* Now consume following elements while they are contiguous */
-		for (; rlen >= np * sizeof(u32);
-		     ranges += np, rlen -= np * 4) {
-			if (ranges[0] != pci_space)
-				break;
-			pci_next = of_read_number(ranges + 1, 2);
-			cpu_next = of_translate_address(dev, ranges + 3);
-			if (pci_next != pci_addr + size ||
-			    cpu_next != cpu_addr + size)
-				break;
-			size += of_read_number(ranges + pna + 3, 2);
-		}
-
-		/* Act based on address space type */
-		res = NULL;
-		switch ((pci_space >> 24) & 0x3) {
-		case 1:		/* PCI IO space */
-			pr_info("  IO 0x%016llx..0x%016llx -> 0x%016llx\n",
-			       cpu_addr, cpu_addr + size - 1, pci_addr);
-
-			/* We support only one IO range */
-			if (hose->pci_io_size) {
-				pr_info(" \\--> Skipped (too many) !\n");
-				continue;
-			}
-			/* On 32 bits, limit I/O space to 16MB */
-			if (size > 0x01000000)
-				size = 0x01000000;
-
-			/* 32 bits needs to map IOs here */
-			hose->io_base_virt = ioremap(cpu_addr, size);
-
-			/* Expect trouble if pci_addr is not 0 */
-			if (primary)
-				isa_io_base =
-					(unsigned long)hose->io_base_virt;
-			/* pci_io_size and io_base_phys always represent IO
-			 * space starting at 0 so we factor in pci_addr
-			 */
-			hose->pci_io_size = pci_addr + size;
-			hose->io_base_phys = cpu_addr - pci_addr;
-
-			/* Build resource */
-			res = &hose->io_resource;
-			res->flags = IORESOURCE_IO;
-			res->start = pci_addr;
-			break;
-		case 2:		/* PCI Memory space */
-		case 3:		/* PCI 64 bits Memory space */
-			pr_info(" MEM 0x%016llx..0x%016llx -> 0x%016llx %s\n",
-			       cpu_addr, cpu_addr + size - 1, pci_addr,
-			       (pci_space & 0x40000000) ? "Prefetch" : "");
-
-			/* We support only 3 memory ranges */
-			if (memno >= 3) {
-				pr_info(" \\--> Skipped (too many) !\n");
-				continue;
-			}
-			/* Handles ISA memory hole space here */
-			if (pci_addr == 0) {
-				isa_mb = cpu_addr;
-				isa_hole = memno;
-				if (primary || isa_mem_base == 0)
-					isa_mem_base = cpu_addr;
-				hose->isa_mem_phys = cpu_addr;
-				hose->isa_mem_size = size;
-			}
-
-			/* We get the PCI/Mem offset from the first range or
-			 * the, current one if the offset came from an ISA
-			 * hole. If they don't match, bugger.
-			 */
-			if (memno == 0 ||
-			    (isa_hole >= 0 && pci_addr != 0 &&
-			     hose->pci_mem_offset == isa_mb))
-				hose->pci_mem_offset = cpu_addr - pci_addr;
-			else if (pci_addr != 0 &&
-				 hose->pci_mem_offset != cpu_addr - pci_addr) {
-				pr_info(" \\--> Skipped (offset mismatch) !\n");
-				continue;
-			}
-
-			/* Build resource */
-			res = &hose->mem_resources[memno++];
-			res->flags = IORESOURCE_MEM;
-			if (pci_space & 0x40000000)
-				res->flags |= IORESOURCE_PREFETCH;
-			res->start = cpu_addr;
-			break;
-		}
-		if (res != NULL) {
-			res->name = dev->full_name;
-			res->end = res->start + size - 1;
-			res->parent = NULL;
-			res->sibling = NULL;
-			res->child = NULL;
-		}
-	}
-
-	/* If there's an ISA hole and the pci_mem_offset is -not- matching
-	 * the ISA hole offset, then we need to remove the ISA hole from
-	 * the resource list for that brige
-	 */
-	if (isa_hole >= 0 && hose->pci_mem_offset != isa_mb) {
-		unsigned int next = isa_hole + 1;
-		pr_info(" Removing ISA hole at 0x%016llx\n", isa_mb);
-		if (next < memno)
-			memmove(&hose->mem_resources[isa_hole],
-				&hose->mem_resources[next],
-				sizeof(struct resource) * (memno - next));
-		hose->mem_resources[--memno].flags = 0;
-	}
-}
-
 /* Decide whether to display the domain number in /proc */
 int pci_proc_domain(struct pci_bus *bus)
 {
diff --git a/arch/powerpc/include/asm/pci-bridge.h b/arch/powerpc/include/asm/pci-bridge.h
index 025a130..205bfba 100644
--- a/arch/powerpc/include/asm/pci-bridge.h
+++ b/arch/powerpc/include/asm/pci-bridge.h
@@ -10,6 +10,7 @@
 #include <linux/pci.h>
 #include <linux/list.h>
 #include <linux/ioport.h>
+#include <linux/of_pci.h>
 #include <asm-generic/pci-bridge.h>
 
 struct device_node;
@@ -231,10 +232,6 @@ extern int pcibios_map_io_space(struct pci_bus *bus);
 extern struct pci_controller *pci_find_hose_for_OF_device(
 			struct device_node* node);
 
-/* Fill up host controller resources from the OF node */
-extern void pci_process_bridge_OF_ranges(struct pci_controller *hose,
-			struct device_node *dev, int primary);
-
 /* Allocate & free a PCI host bridge structure */
 extern struct pci_controller *pcibios_alloc_controller(struct device_node *dev);
 extern void pcibios_free_controller(struct pci_controller *phb);
diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index fa12ae4..6edf396 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -640,198 +640,6 @@ void pci_resource_to_user(const struct pci_dev *dev, int bar,
 	*end = rsrc->end - offset;
 }
 
-/**
- * pci_process_bridge_OF_ranges - Parse PCI bridge resources from device tree
- * @hose: newly allocated pci_controller to be setup
- * @dev: device node of the host bridge
- * @primary: set if primary bus (32 bits only, soon to be deprecated)
- *
- * This function will parse the "ranges" property of a PCI host bridge device
- * node and setup the resource mapping of a pci controller based on its
- * content.
- *
- * Life would be boring if it wasn't for a few issues that we have to deal
- * with here:
- *
- *   - We can only cope with one IO space range and up to 3 Memory space
- *     ranges. However, some machines (thanks Apple !) tend to split their
- *     space into lots of small contiguous ranges. So we have to coalesce.
- *
- *   - We can only cope with all memory ranges having the same offset
- *     between CPU addresses and PCI addresses. Unfortunately, some bridges
- *     are setup for a large 1:1 mapping along with a small "window" which
- *     maps PCI address 0 to some arbitrary high address of the CPU space in
- *     order to give access to the ISA memory hole.
- *     The way out of here that I've chosen for now is to always set the
- *     offset based on the first resource found, then override it if we
- *     have a different offset and the previous was set by an ISA hole.
- *
- *   - Some busses have IO space not starting at 0, which causes trouble with
- *     the way we do our IO resource renumbering. The code somewhat deals with
- *     it for 64 bits but I would expect problems on 32 bits.
- *
- *   - Some 32 bits platforms such as 4xx can have physical space larger than
- *     32 bits so we need to use 64 bits values for the parsing
- */
-void pci_process_bridge_OF_ranges(struct pci_controller *hose,
-				  struct device_node *dev, int primary)
-{
-	const u32 *ranges;
-	int rlen;
-	int pna = of_n_addr_cells(dev);
-	int np = pna + 5;
-	int memno = 0, isa_hole = -1;
-	u32 pci_space;
-	unsigned long long pci_addr, cpu_addr, pci_next, cpu_next, size;
-	unsigned long long isa_mb = 0;
-	struct resource *res;
-
-	printk(KERN_INFO "PCI host bridge %s %s ranges:\n",
-	       dev->full_name, primary ? "(primary)" : "");
-
-	/* Get ranges property */
-	ranges = of_get_property(dev, "ranges", &rlen);
-	if (ranges == NULL)
-		return;
-
-	/* Parse it */
-	while ((rlen -= np * 4) >= 0) {
-		/* Read next ranges element */
-		pci_space = ranges[0];
-		pci_addr = of_read_number(ranges + 1, 2);
-		cpu_addr = of_translate_address(dev, ranges + 3);
-		size = of_read_number(ranges + pna + 3, 2);
-		ranges += np;
-
-		/* If we failed translation or got a zero-sized region
-		 * (some FW try to feed us with non sensical zero sized regions
-		 * such as power3 which look like some kind of attempt at exposing
-		 * the VGA memory hole)
-		 */
-		if (cpu_addr == OF_BAD_ADDR || size == 0)
-			continue;
-
-		/* Now consume following elements while they are contiguous */
-		for (; rlen >= np * sizeof(u32);
-		     ranges += np, rlen -= np * 4) {
-			if (ranges[0] != pci_space)
-				break;
-			pci_next = of_read_number(ranges + 1, 2);
-			cpu_next = of_translate_address(dev, ranges + 3);
-			if (pci_next != pci_addr + size ||
-			    cpu_next != cpu_addr + size)
-				break;
-			size += of_read_number(ranges + pna + 3, 2);
-		}
-
-		/* Act based on address space type */
-		res = NULL;
-		switch ((pci_space >> 24) & 0x3) {
-		case 1:		/* PCI IO space */
-			printk(KERN_INFO
-			       "  IO 0x%016llx..0x%016llx -> 0x%016llx\n",
-			       cpu_addr, cpu_addr + size - 1, pci_addr);
-
-			/* We support only one IO range */
-			if (hose->pci_io_size) {
-				printk(KERN_INFO
-				       " \\--> Skipped (too many) !\n");
-				continue;
-			}
-#ifdef CONFIG_PPC32
-			/* On 32 bits, limit I/O space to 16MB */
-			if (size > 0x01000000)
-				size = 0x01000000;
-
-			/* 32 bits needs to map IOs here */
-			hose->io_base_virt = ioremap(cpu_addr, size);
-
-			/* Expect trouble if pci_addr is not 0 */
-			if (primary)
-				isa_io_base =
-					(unsigned long)hose->io_base_virt;
-#endif /* CONFIG_PPC32 */
-			/* pci_io_size and io_base_phys always represent IO
-			 * space starting at 0 so we factor in pci_addr
-			 */
-			hose->pci_io_size = pci_addr + size;
-			hose->io_base_phys = cpu_addr - pci_addr;
-
-			/* Build resource */
-			res = &hose->io_resource;
-			res->flags = IORESOURCE_IO;
-			res->start = pci_addr;
-			break;
-		case 2:		/* PCI Memory space */
-		case 3:		/* PCI 64 bits Memory space */
-			printk(KERN_INFO
-			       " MEM 0x%016llx..0x%016llx -> 0x%016llx %s\n",
-			       cpu_addr, cpu_addr + size - 1, pci_addr,
-			       (pci_space & 0x40000000) ? "Prefetch" : "");
-
-			/* We support only 3 memory ranges */
-			if (memno >= 3) {
-				printk(KERN_INFO
-				       " \\--> Skipped (too many) !\n");
-				continue;
-			}
-			/* Handles ISA memory hole space here */
-			if (pci_addr == 0) {
-				isa_mb = cpu_addr;
-				isa_hole = memno;
-				if (primary || isa_mem_base == 0)
-					isa_mem_base = cpu_addr;
-				hose->isa_mem_phys = cpu_addr;
-				hose->isa_mem_size = size;
-			}
-
-			/* We get the PCI/Mem offset from the first range or
-			 * the, current one if the offset came from an ISA
-			 * hole. If they don't match, bugger.
-			 */
-			if (memno == 0 ||
-			    (isa_hole >= 0 && pci_addr != 0 &&
-			     hose->pci_mem_offset == isa_mb))
-				hose->pci_mem_offset = cpu_addr - pci_addr;
-			else if (pci_addr != 0 &&
-				 hose->pci_mem_offset != cpu_addr - pci_addr) {
-				printk(KERN_INFO
-				       " \\--> Skipped (offset mismatch) !\n");
-				continue;
-			}
-
-			/* Build resource */
-			res = &hose->mem_resources[memno++];
-			res->flags = IORESOURCE_MEM;
-			if (pci_space & 0x40000000)
-				res->flags |= IORESOURCE_PREFETCH;
-			res->start = cpu_addr;
-			break;
-		}
-		if (res != NULL) {
-			res->name = dev->full_name;
-			res->end = res->start + size - 1;
-			res->parent = NULL;
-			res->sibling = NULL;
-			res->child = NULL;
-		}
-	}
-
-	/* If there's an ISA hole and the pci_mem_offset is -not- matching
-	 * the ISA hole offset, then we need to remove the ISA hole from
-	 * the resource list for that brige
-	 */
-	if (isa_hole >= 0 && hose->pci_mem_offset != isa_mb) {
-		unsigned int next = isa_hole + 1;
-		printk(KERN_INFO " Removing ISA hole at 0x%016llx\n", isa_mb);
-		if (next < memno)
-			memmove(&hose->mem_resources[isa_hole],
-				&hose->mem_resources[next],
-				sizeof(struct resource) * (memno - next));
-		hose->mem_resources[--memno].flags = 0;
-	}
-}
-
 /* Decide whether to display the domain number in /proc */
 int pci_proc_domain(struct pci_bus *bus)
 {
diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
index 13e37e2..1626172 100644
--- a/drivers/of/of_pci.c
+++ b/drivers/of/of_pci.c
@@ -4,6 +4,10 @@
 #include <linux/of_pci.h>
 #include <asm/prom.h>
 
+#if defined(CONFIG_PPC32) || defined(CONFIG_PPC64) || defined(CONFIG_MICROBLAZE)
+#include <asm/pci-bridge.h>
+#endif
+
 static inline int __of_pci_pci_compare(struct device_node *node,
 				       unsigned int devfn)
 {
@@ -40,3 +44,199 @@ struct device_node *of_pci_find_child_device(struct device_node *parent,
 	return NULL;
 }
 EXPORT_SYMBOL_GPL(of_pci_find_child_device);
+
+/**
+ * pci_process_bridge_OF_ranges - Parse PCI bridge resources from device tree
+ * @hose: newly allocated pci_controller to be setup
+ * @dev: device node of the host bridge
+ * @primary: set if primary bus (32 bits only, soon to be deprecated)
+ *
+ * This function will parse the "ranges" property of a PCI host bridge device
+ * node and setup the resource mapping of a pci controller based on its
+ * content.
+ *
+ * Life would be boring if it wasn't for a few issues that we have to deal
+ * with here:
+ *
+ *   - We can only cope with one IO space range and up to 3 Memory space
+ *     ranges. However, some machines (thanks Apple !) tend to split their
+ *     space into lots of small contiguous ranges. So we have to coalesce.
+ *
+ *   - We can only cope with all memory ranges having the same offset
+ *     between CPU addresses and PCI addresses. Unfortunately, some bridges
+ *     are setup for a large 1:1 mapping along with a small "window" which
+ *     maps PCI address 0 to some arbitrary high address of the CPU space in
+ *     order to give access to the ISA memory hole.
+ *     The way out of here that I've chosen for now is to always set the
+ *     offset based on the first resource found, then override it if we
+ *     have a different offset and the previous was set by an ISA hole.
+ *
+ *   - Some busses have IO space not starting at 0, which causes trouble with
+ *     the way we do our IO resource renumbering. The code somewhat deals with
+ *     it for 64 bits but I would expect problems on 32 bits.
+ *
+ *   - Some 32 bits platforms such as 4xx can have physical space larger than
+ *     32 bits so we need to use 64 bits values for the parsing
+ */
+#if defined(CONFIG_PPC32) || defined(CONFIG_PPC64) || defined(CONFIG_MICROBLAZE)
+void pci_process_bridge_OF_ranges(struct pci_controller *hose,
+				  struct device_node *dev, int primary)
+{
+	const u32 *ranges;
+	int rlen;
+	int pna = of_n_addr_cells(dev);
+	int np = pna + 5;
+	int memno = 0, isa_hole = -1;
+	u32 pci_space;
+	unsigned long long pci_addr, cpu_addr, pci_next, cpu_next, size;
+	unsigned long long isa_mb = 0;
+	struct resource *res;
+
+	pr_info("PCI host bridge %s %s ranges:\n",
+	       dev->full_name, primary ? "(primary)" : "");
+
+	/* Get ranges property */
+	ranges = of_get_property(dev, "ranges", &rlen);
+	if (ranges == NULL)
+		return;
+
+	/* Parse it */
+	pr_debug("Parsing ranges property...\n");
+	while ((rlen -= np * 4) >= 0) {
+		/* Read next ranges element */
+		pci_space = ranges[0];
+		pci_addr = of_read_number(ranges + 1, 2);
+		cpu_addr = of_translate_address(dev, ranges + 3);
+		size = of_read_number(ranges + pna + 3, 2);
+
+		pr_debug("pci_space: 0x%08x pci_addr:0x%016llx ",
+				pci_space, pci_addr);
+		pr_debug("cpu_addr:0x%016llx size:0x%016llx\n",
+					cpu_addr, size);
+
+		ranges += np;
+
+		/* If we failed translation or got a zero-sized region
+		 * (some FW try to feed us with non sensical zero sized regions
+		 * such as power3 which look like some kind of attempt
+		 * at exposing the VGA memory hole)
+		 */
+		if (cpu_addr == OF_BAD_ADDR || size == 0)
+			continue;
+
+		/* Now consume following elements while they are contiguous */
+		for (; rlen >= np * sizeof(u32);
+		     ranges += np, rlen -= np * 4) {
+			if (ranges[0] != pci_space)
+				break;
+			pci_next = of_read_number(ranges + 1, 2);
+			cpu_next = of_translate_address(dev, ranges + 3);
+			if (pci_next != pci_addr + size ||
+			    cpu_next != cpu_addr + size)
+				break;
+			size += of_read_number(ranges + pna + 3, 2);
+		}
+
+		/* Act based on address space type */
+		res = NULL;
+		switch ((pci_space >> 24) & 0x3) {
+		case 1:		/* PCI IO space */
+			pr_info("  IO 0x%016llx..0x%016llx -> 0x%016llx\n",
+			       cpu_addr, cpu_addr + size - 1, pci_addr);
+
+			/* We support only one IO range */
+			if (hose->pci_io_size) {
+				pr_info(" \\--> Skipped (too many) !\n");
+				continue;
+			}
+#if (!IS_ENABLED(CONFIG_64BIT))
+			/* On 32 bits, limit I/O space to 16MB */
+			if (size > 0x01000000)
+				size = 0x01000000;
+
+			/* 32 bits needs to map IOs here */
+			hose->io_base_virt = ioremap(cpu_addr, size);
+
+			/* Expect trouble if pci_addr is not 0 */
+			if (primary)
+				isa_io_base =
+					(unsigned long)hose->io_base_virt;
+#endif /* !CONFIG_64BIT */
+			/* pci_io_size and io_base_phys always represent IO
+			 * space starting at 0 so we factor in pci_addr
+			 */
+			hose->pci_io_size = pci_addr + size;
+			hose->io_base_phys = cpu_addr - pci_addr;
+
+			/* Build resource */
+			res = &hose->io_resource;
+			res->flags = IORESOURCE_IO;
+			res->start = pci_addr;
+			break;
+		case 2:		/* PCI Memory space */
+		case 3:		/* PCI 64 bits Memory space */
+			pr_info(" MEM 0x%016llx..0x%016llx -> 0x%016llx %s\n",
+			       cpu_addr, cpu_addr + size - 1, pci_addr,
+			       (pci_space & 0x40000000) ? "Prefetch" : "");
+
+			/* We support only 3 memory ranges */
+			if (memno >= 3) {
+				pr_info(" \\--> Skipped (too many) !\n");
+				continue;
+			}
+			/* Handles ISA memory hole space here */
+			if (pci_addr == 0) {
+				isa_mb = cpu_addr;
+				isa_hole = memno;
+				if (primary || isa_mem_base == 0)
+					isa_mem_base = cpu_addr;
+				hose->isa_mem_phys = cpu_addr;
+				hose->isa_mem_size = size;
+			}
+
+			/* We get the PCI/Mem offset from the first range or
+			 * the, current one if the offset came from an ISA
+			 * hole. If they don't match, bugger.
+			 */
+			if (memno == 0 ||
+			    (isa_hole >= 0 && pci_addr != 0 &&
+			     hose->pci_mem_offset == isa_mb))
+				hose->pci_mem_offset = cpu_addr - pci_addr;
+			else if (pci_addr != 0 &&
+				 hose->pci_mem_offset != cpu_addr - pci_addr) {
+				pr_info(" \\--> Skipped (offset mismatch) !\n");
+				continue;
+			}
+
+			/* Build resource */
+			res = &hose->mem_resources[memno++];
+			res->flags = IORESOURCE_MEM;
+			if (pci_space & 0x40000000)
+				res->flags |= IORESOURCE_PREFETCH;
+			res->start = cpu_addr;
+			break;
+		}
+		if (res != NULL) {
+			res->name = dev->full_name;
+			res->end = res->start + size - 1;
+			res->parent = NULL;
+			res->sibling = NULL;
+			res->child = NULL;
+		}
+	}
+
+	/* If there's an ISA hole and the pci_mem_offset is -not- matching
+	 * the ISA hole offset, then we need to remove the ISA hole from
+	 * the resource list for that brige
+	 */
+	if (isa_hole >= 0 && hose->pci_mem_offset != isa_mb) {
+		unsigned int next = isa_hole + 1;
+		pr_info(" Removing ISA hole at 0x%016llx\n", isa_mb);
+		if (next < memno)
+			memmove(&hose->mem_resources[isa_hole],
+				&hose->mem_resources[next],
+				sizeof(struct resource) * (memno - next));
+		hose->mem_resources[--memno].flags = 0;
+	}
+}
+#endif
diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
index bb115de..33e8ead 100644
--- a/include/linux/of_pci.h
+++ b/include/linux/of_pci.h
@@ -11,4 +11,8 @@ struct device_node;
 struct device_node *of_pci_find_child_device(struct device_node *parent,
 					     unsigned int devfn);
 
+struct pci_controller;
+void pci_process_bridge_OF_ranges(struct pci_controller *hose,
+			struct device_node *dev, int primary);
+
 #endif
-- 
1.7.0.4



From Andrew.Murray at arm.com  Tue Apr 16 06:18:27 2013
From: Andrew.Murray at arm.com (Andrew Murray)
Date: Tue, 16 Apr 2013 11:18:27 +0100
Subject: [PATCH v7 2/3] of/pci: Provide support for parsing PCI DT ranges
 property
In-Reply-To: <1366107508-12672-1-git-send-email-Andrew.Murray@arm.com>
References: <1366107508-12672-1-git-send-email-Andrew.Murray@arm.com>
Message-ID: <1366107508-12672-3-git-send-email-Andrew.Murray@arm.com>

This patch factors out common implementation patterns to reduce overall kernel
code and provide a means for host bridge drivers to directly obtain struct
resources from the DT's ranges property without relying on architecture specific
DT handling. This will make it easier to write archiecture independent host bridge
drivers and mitigate against further duplication of DT parsing code.

This patch can be used in the following way:

	struct of_pci_range_parser parser;
	struct of_pci_range range;

	if (of_pci_range_parser(&parser, np))
		; //no ranges property

	for_each_of_pci_range(&parser, &range) {

		/*
			directly access properties of the address range, e.g.:
			range.pci_space, range.pci_addr, range.cpu_addr,
			range.size, range.flags

			alternatively obtain a struct resource, e.g.:
			struct resource res;
			of_pci_range_to_resource(&range, np, &res);
		*/
	}

Additionally the implementation takes care of adjacent ranges and merges them
into a single range (as was the case with powerpc and microblaze).

Signed-off-by: Andrew Murray <Andrew.Murray at arm.com>
Signed-off-by: Liviu Dudau <Liviu.Dudau at arm.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Reviewed-by: Rob Herring <rob.herring at calxeda.com>
Tested-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Tested-by: Linus Walleij <linus.walleij at linaro.org>
---
 drivers/of/address.c       |   67 ++++++++++++++++++++++++++
 drivers/of/of_pci.c        |  113 ++++++++++++++++----------------------------
 include/linux/of_address.h |   46 ++++++++++++++++++
 3 files changed, 154 insertions(+), 72 deletions(-)

diff --git a/drivers/of/address.c b/drivers/of/address.c
index 04da786..6eec70c 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -227,6 +227,73 @@ int of_pci_address_to_resource(struct device_node *dev, int bar,
 	return __of_address_to_resource(dev, addrp, size, flags, NULL, r);
 }
 EXPORT_SYMBOL_GPL(of_pci_address_to_resource);
+
+int of_pci_range_parser(struct of_pci_range_parser *parser,
+			struct device_node *node)
+{
+	const int na = 3, ns = 2;
+	int rlen;
+
+	parser->node = node;
+	parser->pna = of_n_addr_cells(node);
+	parser->np = parser->pna + na + ns;
+
+	parser->range = of_get_property(node, "ranges", &rlen);
+	if (parser->range == NULL)
+		return -ENOENT;
+
+	parser->end = parser->range + rlen / sizeof(__be32);
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(of_pci_range_parser);
+
+struct of_pci_range *of_pci_process_ranges(struct of_pci_range_parser *parser,
+						struct of_pci_range *range)
+{
+	const int na = 3, ns = 2;
+
+	if (!range)
+		return NULL;
+
+	if (!parser->range || parser->range + parser->np > parser->end)
+		return NULL;
+
+	range->pci_space = parser->range[0];
+	range->flags = of_bus_pci_get_flags(parser->range);
+	range->pci_addr = of_read_number(parser->range + 1, ns);
+	range->cpu_addr = of_translate_address(parser->node,
+				parser->range + na);
+	range->size = of_read_number(parser->range + parser->pna + na, ns);
+
+	parser->range += parser->np;
+
+	/* Now consume following elements while they are contiguous */
+	while (parser->range + parser->np <= parser->end) {
+		u32 flags, pci_space;
+		u64 pci_addr, cpu_addr, size;
+
+		pci_space = be32_to_cpup(parser->range);
+		flags = of_bus_pci_get_flags(parser->range);
+		pci_addr = of_read_number(parser->range + 1, ns);
+		cpu_addr = of_translate_address(parser->node,
+				parser->range + na);
+		size = of_read_number(parser->range + parser->pna + na, ns);
+
+		if (flags != range->flags)
+			break;
+		if (pci_addr != range->pci_addr + range->size ||
+		    cpu_addr != range->cpu_addr + range->size)
+			break;
+
+		range->size += size;
+		parser->range += parser->np;
+	}
+
+	return range;
+}
+EXPORT_SYMBOL_GPL(of_pci_process_ranges);
+
 #endif /* CONFIG_PCI */
 
 /*
diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
index 1626172..e5ab604 100644
--- a/drivers/of/of_pci.c
+++ b/drivers/of/of_pci.c
@@ -2,6 +2,7 @@
 #include <linux/export.h>
 #include <linux/of.h>
 #include <linux/of_pci.h>
+#include <linux/of_address.h>
 #include <asm/prom.h>
 
 #if defined(CONFIG_PPC32) || defined(CONFIG_PPC64) || defined(CONFIG_MICROBLAZE)
@@ -82,67 +83,43 @@ EXPORT_SYMBOL_GPL(of_pci_find_child_device);
 void pci_process_bridge_OF_ranges(struct pci_controller *hose,
 				  struct device_node *dev, int primary)
 {
-	const u32 *ranges;
-	int rlen;
-	int pna = of_n_addr_cells(dev);
-	int np = pna + 5;
 	int memno = 0, isa_hole = -1;
-	u32 pci_space;
-	unsigned long long pci_addr, cpu_addr, pci_next, cpu_next, size;
 	unsigned long long isa_mb = 0;
 	struct resource *res;
+	struct of_pci_range range;
+	struct of_pci_range_parser parser;
+	u32 res_type;
 
 	pr_info("PCI host bridge %s %s ranges:\n",
 	       dev->full_name, primary ? "(primary)" : "");
 
-	/* Get ranges property */
-	ranges = of_get_property(dev, "ranges", &rlen);
-	if (ranges == NULL)
+	/* Check for ranges property */
+	if (of_pci_range_parser(&parser, dev))
 		return;
 
-	/* Parse it */
 	pr_debug("Parsing ranges property...\n");
-	while ((rlen -= np * 4) >= 0) {
+	for_each_of_pci_range(&parser, &range) {
 		/* Read next ranges element */
-		pci_space = ranges[0];
-		pci_addr = of_read_number(ranges + 1, 2);
-		cpu_addr = of_translate_address(dev, ranges + 3);
-		size = of_read_number(ranges + pna + 3, 2);
-
-		pr_debug("pci_space: 0x%08x pci_addr:0x%016llx ",
-				pci_space, pci_addr);
-		pr_debug("cpu_addr:0x%016llx size:0x%016llx\n",
-					cpu_addr, size);
-
-		ranges += np;
+		pr_debug("pci_space: 0x%08x pci_addr: 0x%016llx ",
+				range.pci_space, range.pci_addr);
+		pr_debug("cpu_addr: 0x%016llx size: 0x%016llx\n",
+				range.cpu_addr, range.size);
 
 		/* If we failed translation or got a zero-sized region
 		 * (some FW try to feed us with non sensical zero sized regions
 		 * such as power3 which look like some kind of attempt
 		 * at exposing the VGA memory hole)
 		 */
-		if (cpu_addr == OF_BAD_ADDR || size == 0)
+		if (range.cpu_addr == OF_BAD_ADDR || range.size == 0)
 			continue;
 
-		/* Now consume following elements while they are contiguous */
-		for (; rlen >= np * sizeof(u32);
-		     ranges += np, rlen -= np * 4) {
-			if (ranges[0] != pci_space)
-				break;
-			pci_next = of_read_number(ranges + 1, 2);
-			cpu_next = of_translate_address(dev, ranges + 3);
-			if (pci_next != pci_addr + size ||
-			    cpu_next != cpu_addr + size)
-				break;
-			size += of_read_number(ranges + pna + 3, 2);
-		}
-
 		/* Act based on address space type */
 		res = NULL;
-		switch ((pci_space >> 24) & 0x3) {
-		case 1:		/* PCI IO space */
+		res_type = range.flags & IORESOURCE_TYPE_BITS;
+		if (res_type == IORESOURCE_IO) {
 			pr_info("  IO 0x%016llx..0x%016llx -> 0x%016llx\n",
-			       cpu_addr, cpu_addr + size - 1, pci_addr);
+				range.cpu_addr, range.cpu_addr + range.size - 1,
+				range.pci_addr);
 
 			/* We support only one IO range */
 			if (hose->pci_io_size) {
@@ -151,11 +128,12 @@ void pci_process_bridge_OF_ranges(struct pci_controller *hose,
 			}
 #if (!IS_ENABLED(CONFIG_64BIT))
 			/* On 32 bits, limit I/O space to 16MB */
-			if (size > 0x01000000)
-				size = 0x01000000;
+			if (range.size > 0x01000000)
+				range.size = 0x01000000;
 
 			/* 32 bits needs to map IOs here */
-			hose->io_base_virt = ioremap(cpu_addr, size);
+			hose->io_base_virt = ioremap(range.cpu_addr,
+						range.size);
 
 			/* Expect trouble if pci_addr is not 0 */
 			if (primary)
@@ -165,19 +143,18 @@ void pci_process_bridge_OF_ranges(struct pci_controller *hose,
 			/* pci_io_size and io_base_phys always represent IO
 			 * space starting at 0 so we factor in pci_addr
 			 */
-			hose->pci_io_size = pci_addr + size;
-			hose->io_base_phys = cpu_addr - pci_addr;
+			hose->pci_io_size = range.pci_addr + range.size;
+			hose->io_base_phys = range.cpu_addr - range.pci_addr;
 
 			/* Build resource */
 			res = &hose->io_resource;
-			res->flags = IORESOURCE_IO;
-			res->start = pci_addr;
-			break;
-		case 2:		/* PCI Memory space */
-		case 3:		/* PCI 64 bits Memory space */
+			range.cpu_addr = range.pci_addr;
+		} else if (res_type == IORESOURCE_MEM) {
 			pr_info(" MEM 0x%016llx..0x%016llx -> 0x%016llx %s\n",
-			       cpu_addr, cpu_addr + size - 1, pci_addr,
-			       (pci_space & 0x40000000) ? "Prefetch" : "");
+				range.cpu_addr, range.cpu_addr + range.size - 1,
+				range.pci_addr,
+				(range.pci_space & 0x40000000) ?
+				"Prefetch" : "");
 
 			/* We support only 3 memory ranges */
 			if (memno >= 3) {
@@ -185,13 +162,13 @@ void pci_process_bridge_OF_ranges(struct pci_controller *hose,
 				continue;
 			}
 			/* Handles ISA memory hole space here */
-			if (pci_addr == 0) {
-				isa_mb = cpu_addr;
+			if (range.pci_addr == 0) {
+				isa_mb = range.cpu_addr;
 				isa_hole = memno;
 				if (primary || isa_mem_base == 0)
-					isa_mem_base = cpu_addr;
-				hose->isa_mem_phys = cpu_addr;
-				hose->isa_mem_size = size;
+					isa_mem_base = range.cpu_addr;
+				hose->isa_mem_phys = range.cpu_addr;
+				hose->isa_mem_size = range.size;
 			}
 
 			/* We get the PCI/Mem offset from the first range or
@@ -199,30 +176,22 @@ void pci_process_bridge_OF_ranges(struct pci_controller *hose,
 			 * hole. If they don't match, bugger.
 			 */
 			if (memno == 0 ||
-			    (isa_hole >= 0 && pci_addr != 0 &&
+			(isa_hole >= 0 && range.pci_addr != 0 &&
 			     hose->pci_mem_offset == isa_mb))
-				hose->pci_mem_offset = cpu_addr - pci_addr;
-			else if (pci_addr != 0 &&
-				 hose->pci_mem_offset != cpu_addr - pci_addr) {
+				hose->pci_mem_offset = range.cpu_addr -
+							range.pci_addr;
+			else if (range.pci_addr != 0 &&
+				hose->pci_mem_offset != range.cpu_addr -
+							range.pci_addr) {
 				pr_info(" \\--> Skipped (offset mismatch) !\n");
 				continue;
 			}
 
 			/* Build resource */
 			res = &hose->mem_resources[memno++];
-			res->flags = IORESOURCE_MEM;
-			if (pci_space & 0x40000000)
-				res->flags |= IORESOURCE_PREFETCH;
-			res->start = cpu_addr;
-			break;
-		}
-		if (res != NULL) {
-			res->name = dev->full_name;
-			res->end = res->start + size - 1;
-			res->parent = NULL;
-			res->sibling = NULL;
-			res->child = NULL;
 		}
+		if (res != NULL)
+			of_pci_range_to_resource(&range, dev, res);
 	}
 
 	/* If there's an ISA hole and the pci_mem_offset is -not- matching
diff --git a/include/linux/of_address.h b/include/linux/of_address.h
index 0506eb5..1cfb779 100644
--- a/include/linux/of_address.h
+++ b/include/linux/of_address.h
@@ -4,6 +4,36 @@
 #include <linux/errno.h>
 #include <linux/of.h>
 
+struct of_pci_range_parser {
+	struct device_node *node;
+	const __be32 *range;
+	const __be32 *end;
+	int np;
+	int pna;
+};
+
+struct of_pci_range {
+	u32 pci_space;
+	u64 pci_addr;
+	u64 cpu_addr;
+	u64 size;
+	u32 flags;
+};
+
+#define for_each_of_pci_range(parser, range) \
+	for (; of_pci_process_ranges(parser, range);)
+
+static inline void of_pci_range_to_resource(struct of_pci_range *range,
+					    struct device_node *np,
+					    struct resource *res)
+{
+	res->flags = range->flags;
+	res->start = range->cpu_addr;
+	res->end = range->cpu_addr + range->size - 1;
+	res->parent = res->child = res->sibling = NULL;
+	res->name = np->full_name;
+}
+
 #ifdef CONFIG_OF_ADDRESS
 extern u64 of_translate_address(struct device_node *np, const __be32 *addr);
 extern bool of_can_translate_address(struct device_node *dev);
@@ -27,6 +57,10 @@ static inline unsigned long pci_address_to_pio(phys_addr_t addr) { return -1; }
 #define pci_address_to_pio pci_address_to_pio
 #endif
 
+extern int of_pci_range_parser(struct of_pci_range_parser *parser,
+			struct device_node *node);
+extern struct of_pci_range *of_pci_process_ranges(struct of_pci_range_parser *parser,
+						struct of_pci_range *range);
 #else /* CONFIG_OF_ADDRESS */
 #ifndef of_address_to_resource
 static inline int of_address_to_resource(struct device_node *dev, int index,
@@ -53,6 +87,18 @@ static inline const __be32 *of_get_address(struct device_node *dev, int index,
 {
 	return NULL;
 }
+
+static inline int of_pci_range_parser(struct of_pci_range_parser *parser,
+			struct device_node *node)
+{
+	return -1;
+}
+
+static inline struct of_pci_range *of_pci_process_ranges(struct of_pci_range_parser *parser,
+						struct of_pci_range *range)
+{
+	return NULL;
+}
 #endif /* CONFIG_OF_ADDRESS */
 
 
-- 
1.7.0.4



From Andrew.Murray at arm.com  Tue Apr 16 06:18:28 2013
From: Andrew.Murray at arm.com (Andrew Murray)
Date: Tue, 16 Apr 2013 11:18:28 +0100
Subject: [PATCH v7 3/3] of/pci: mips: convert to common of_pci_range_parser
In-Reply-To: <1366107508-12672-1-git-send-email-Andrew.Murray@arm.com>
References: <1366107508-12672-1-git-send-email-Andrew.Murray@arm.com>
Message-ID: <1366107508-12672-4-git-send-email-Andrew.Murray@arm.com>

This patch converts the pci_load_of_ranges function to use the new common
of_pci_range_parser.

Signed-off-by: Andrew Murray <Andrew.Murray at arm.com>
Signed-off-by: Liviu Dudau <Liviu.Dudau at arm.com>
Reviewed-by: Rob Herring <rob.herring at calxeda.com>
---
 arch/mips/pci/pci.c |   50 ++++++++++++++++----------------------------------
 1 files changed, 16 insertions(+), 34 deletions(-)

diff --git a/arch/mips/pci/pci.c b/arch/mips/pci/pci.c
index 0872f12..bee49a4 100644
--- a/arch/mips/pci/pci.c
+++ b/arch/mips/pci/pci.c
@@ -122,51 +122,33 @@ static void pcibios_scanbus(struct pci_controller *hose)
 #ifdef CONFIG_OF
 void pci_load_of_ranges(struct pci_controller *hose, struct device_node *node)
 {
-	const __be32 *ranges;
-	int rlen;
-	int pna = of_n_addr_cells(node);
-	int np = pna + 5;
+	struct of_pci_range_range range;
+	struct of_pci_range_parser parser;
+	u32 res_type;
 
 	pr_info("PCI host bridge %s ranges:\n", node->full_name);
-	ranges = of_get_property(node, "ranges", &rlen);
-	if (ranges == NULL)
-		return;
 	hose->of_node = node;
 
-	while ((rlen -= np * 4) >= 0) {
-		u32 pci_space;
+	if (of_pci_range_parser(&parser, node))
+		return;
+
+	for_each_of_pci_range(&parser, &range) {
 		struct resource *res = NULL;
-		u64 addr, size;
-
-		pci_space = be32_to_cpup(&ranges[0]);
-		addr = of_translate_address(node, ranges + 3);
-		size = of_read_number(ranges + pna + 3, 2);
-		ranges += np;
-		switch ((pci_space >> 24) & 0x3) {
-		case 1:		/* PCI IO space */
+
+		res_type = range.flags & IORESOURCE_TYPE_BITS;
+		if (res_type == IORESOURCE_IO) {
 			pr_info("  IO 0x%016llx..0x%016llx\n",
-					addr, addr + size - 1);
+				range.addr, range.addr + range.size - 1);
 			hose->io_map_base =
-				(unsigned long)ioremap(addr, size);
+				(unsigned long)ioremap(range.addr, range.size);
 			res = hose->io_resource;
-			res->flags = IORESOURCE_IO;
-			break;
-		case 2:		/* PCI Memory space */
-		case 3:		/* PCI 64 bits Memory space */
+		} else if (res_type == IORESOURCE_MEM) {
 			pr_info(" MEM 0x%016llx..0x%016llx\n",
-					addr, addr + size - 1);
+				range.addr, range.addr + range.size - 1);
 			res = hose->mem_resource;
-			res->flags = IORESOURCE_MEM;
-			break;
-		}
-		if (res != NULL) {
-			res->start = addr;
-			res->name = node->full_name;
-			res->end = res->start + size - 1;
-			res->parent = NULL;
-			res->sibling = NULL;
-			res->child = NULL;
 		}
+		if (res != NULL)
+			of_pci_range_to_resource(&range, node, res);
 	}
 }
 #endif
-- 
1.7.0.4



From grant.likely at secretlab.ca  Tue Apr 16 06:20:41 2013
From: grant.likely at secretlab.ca (Grant Likely)
Date: Tue, 16 Apr 2013 11:20:41 +0100
Subject: [PATCH v5 0/5] Patch enables support for m25p64 SPI flash support
 on da850-EVM.
In-Reply-To: <516BE92B.90002@ti.com>
References: <1364998150-5980-1-git-send-email-prakash.pm@ti.com>
 <A73F36158E33644199EB82C5EC81C7BC3EA4C560@DBDE01.ent.ti.com>
 <516BE92B.90002@ti.com>
Message-ID: <20130416102041.CC5633E14C0@localhost>

On Mon, 15 Apr 2013 17:18:59 +0530, Sekhar Nori <nsekhar at ti.com> wrote:
> On 4/9/2013 11:14 AM, Manjunathappa, Prakash wrote:
> > Hi Grant,
> > 
> > On Wed, Apr 03, 2013 at 19:39:05, Manjunathappa, Prakash wrote:
> >> Testing information:
> >> da850-evm comes with partitions specified in DT blob.
> >> Able to mount/umount and create/delete files on filesystem partition.
> >>
> > 
> > Could you please ack the driver(1/5) and documentation(2/5) changes so
> > that Sekhar can merge the platform changes, he doesn't have any
> > objection on this series.
> > http://marc.info/?l=linux-doc&m=136489750130615&w=1
> 
> I am planning to queue these patches for ARM-SoC today. Grant has not
> acked these but 1/5 just fixes the binding name to not use wild cards
> and 2/5 just documents existing bindings and is something that should
> have been merge last merge window itself (when the bindings were
> accepted). So, the patches pending on Grant's ack seem very low risk to
> me and we are much delayed already to wait further.

For both of those patches:
Acked-by: Grant Likely <grant.likely at secretlab.ca>


From grant.likely at secretlab.ca  Tue Apr 16 06:24:02 2013
From: grant.likely at secretlab.ca (Grant Likely)
Date: Tue, 16 Apr 2013 11:24:02 +0100
Subject: [REPOST PATCH] spi: s3c64xx: let device core setup the default
 pin configuration
In-Reply-To: <1366083777-9118-1-git-send-email-dianders@chromium.org>
References: <1362570130-14084-1-git-send-email-thomas.abraham@linaro.org>
 <1366083777-9118-1-git-send-email-dianders@chromium.org>
Message-ID: <20130416102402.DF3493E14C0@localhost>

On Mon, 15 Apr 2013 20:42:57 -0700, Doug Anderson <dianders at chromium.org> wrote:
> From: Thomas Abraham <thomas.abraham at linaro.org>
> 
> With device core now able to setup the default pin configuration,
> the pin configuration code based on the deprecated Samsung specific
> gpio bindings is removed.
> 
> Signed-off-by: Thomas Abraham <thomas.abraham at linaro.org>
> Signed-off-by: Doug Anderson <dianders at chromium.org>
> Acked-by: Linus Walleij <linus.walleij at linaro.org>
> Reviewed-by: Doug Anderson <dianders at chromium.org>
> Tested-by: Doug Anderson <dianders at chromium.org>

Applied, thanks.

g.



From andrew.murray at arm.com  Tue Apr 16 06:30:06 2013
From: andrew.murray at arm.com (Andrew Murray)
Date: Tue, 16 Apr 2013 11:30:06 +0100
Subject: [PATCH v7 1/3] of/pci: Unify pci_process_bridge_OF_ranges from
 Microblaze and PowerPC
In-Reply-To: <1366107508-12672-2-git-send-email-Andrew.Murray@arm.com>
References: <1366107508-12672-1-git-send-email-Andrew.Murray@arm.com>
 <1366107508-12672-2-git-send-email-Andrew.Murray@arm.com>
Message-ID: <20130416103005.GB12726@arm.com>

On Tue, Apr 16, 2013 at 11:18:26AM +0100, Andrew Murray wrote:
> The pci_process_bridge_OF_ranges function, used to parse the "ranges"
> property of a PCI host device, is found in both Microblaze and PowerPC
> architectures. These implementations are nearly identical. This patch
> moves this common code to a common place.
> 
> Signed-off-by: Andrew Murray <Andrew.Murray at arm.com>
> Signed-off-by: Liviu Dudau <Liviu.Dudau at arm.com>
> Reviewed-by: Rob Herring <rob.herring at calxeda.com>
> Tested-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> Tested-by: Linus Walleij <linus.walleij at linaro.org>
> Acked-by: Michal Simek <monstr at monstr.eu>
> ---
>  arch/microblaze/include/asm/pci-bridge.h |    5 +-
>  arch/microblaze/pci/pci-common.c         |  192 ----------------------------
>  arch/powerpc/include/asm/pci-bridge.h    |    5 +-
>  arch/powerpc/kernel/pci-common.c         |  192 ----------------------------

Is there anyone on linuxppc-dev/linux-mips that can help test this patchset?

I've tested that it builds on powerpc with a variety of configs (some which
include fsl_pci.c implementation). Though I don't have hardware to verify that
it works.

I haven't tested this builds or runs on MIPS.

You shouldn't see any difference in behaviour or new warnings and PCI devices
should continue to operate as before.

Andrew Murray


From nsekhar at ti.com  Tue Apr 16 06:36:27 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Tue, 16 Apr 2013 16:06:27 +0530
Subject: [PATCH v5 0/5] Patch enables support for m25p64 SPI flash support
 on da850-EVM.
In-Reply-To: <20130416102041.CC5633E14C0@localhost>
References: <1364998150-5980-1-git-send-email-prakash.pm@ti.com>
 <A73F36158E33644199EB82C5EC81C7BC3EA4C560@DBDE01.ent.ti.com>
 <516BE92B.90002@ti.com> <20130416102041.CC5633E14C0@localhost>
Message-ID: <516D29AB.8000004@ti.com>

On 4/16/2013 3:50 PM, Grant Likely wrote:
> On Mon, 15 Apr 2013 17:18:59 +0530, Sekhar Nori <nsekhar at ti.com> wrote:
>> On 4/9/2013 11:14 AM, Manjunathappa, Prakash wrote:
>>> Hi Grant,
>>>
>>> On Wed, Apr 03, 2013 at 19:39:05, Manjunathappa, Prakash wrote:
>>>> Testing information:
>>>> da850-evm comes with partitions specified in DT blob.
>>>> Able to mount/umount and create/delete files on filesystem partition.
>>>>
>>>
>>> Could you please ack the driver(1/5) and documentation(2/5) changes so
>>> that Sekhar can merge the platform changes, he doesn't have any
>>> objection on this series.
>>> http://marc.info/?l=linux-doc&m=136489750130615&w=1
>>
>> I am planning to queue these patches for ARM-SoC today. Grant has not
>> acked these but 1/5 just fixes the binding name to not use wild cards
>> and 2/5 just documents existing bindings and is something that should
>> have been merge last merge window itself (when the bindings were
>> accepted). So, the patches pending on Grant's ack seem very low risk to
>> me and we are much delayed already to wait further.
> 
> For both of those patches:
> Acked-by: Grant Likely <grant.likely at secretlab.ca>

Thanks Grant. I sent my pull request already. CCing Olof to see if
adding your ack locally when he pulls is something he is open to.

Thanks,
Sekhar


From lorenzo.pieralisi at arm.com  Tue Apr 16 06:45:45 2013
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Tue, 16 Apr 2013 11:45:45 +0100
Subject: [RFC PATCH 2/2] ARM: DT: kernel: DT cpu node bindings update
In-Reply-To: <516C544A.4090107@wwwdotorg.org>
References: <1366042402-8987-1-git-send-email-lorenzo.pieralisi@arm.com>
 <1366042402-8987-3-git-send-email-lorenzo.pieralisi@arm.com>
 <516C544A.4090107@wwwdotorg.org>
Message-ID: <20130416104545.GA19837@e102568-lin.cambridge.arm.com>

Thanks Stephen for the review.

On Mon, Apr 15, 2013 at 08:26:02PM +0100, Stephen Warren wrote:
> On 04/15/2013 10:13 AM, Lorenzo Pieralisi wrote:
> > In order to extend the current cpu nodes bindings to newer CPUs
> > inclusive of AArch64 and to update support for older ARM CPUs this
> > patch updates device tree documentation for the cpu nodes bindings.
> > 
> 
> > diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt
> 
> >  http://devicetree.org
> >  
> > -For the ARM architecture every CPU node must contain the following properties:
> > -
> ...
> > +with updates for 32-bit and 64-bit ARM systems provided in this document.
> > +
> > +In the bindings below:
> 
> That's a slightly odd change, since it removes the statement that a cpus
> node must exist, and "in the bindings below" is not idiomatic for DT
> binding definitions.

I beg to differ.

"Bindings for CPU nodes follow the ePAPR standard...."

ePAPR v1.1

3.6 CPUS node properties

"A cpus node is required for all device trees".

> Perhaps replace that last list with:
> 
> The ARM architecture requires the following properties in the cpus and
> cpu nodes contain the properties described below.
> 
> > +- square brackets define bitfields, eg reg[7:0] value of the bitfield in
> > +  the reg property contained in bits 7 down to 0
> 
> Isn't that standard enough it's not even worth mentioning? If it is,
> it's certainly not something that should be mentioned in the part of the
> document that describes which properties are requried.

It is mentioned before cpus node and cpu node descriptions start.

I think you have a point though and it can be omitted, I certainly would
like to understand better what's "standard enough" in DT world to write
these bindings, I took ePAPR as a reference and tried to assume nothing.

> 
> > +	- #address-cells
> > +		Usage: required
> 
> "Usage" sounds more like what it's used for. "Presence" seems better to me.

I have not reinvented the wheel, just had a look at powerPC bindings and
tried to comply. If "Usage" is not proper we also have to patch a number
of in-kernel DT bindings and update the ePAPR.

> > +			# On ARM architecture versions >= 7 based 32-bit
> > +			  systems this property is required and matches the
> 
> Perhaps "On 32-bit ARMv7 or later systems, this property ..."
> 
> > +			# On ARM v8 64-bit systems, where the reg property
> 
> Should there be an explicit note here re: 32-bit SW running on a 64-bit
> system?

Yes, I think I should add an explicit note.

> Perhaps "on ARMv8 systems running 32-bit or 64- bit software, the reg
> property ..."
> 
> > +			  is made up of two cells to accomodate the 64-bit
> > +			  MPDIR_EL1 register this property is required and
> > +			  matches:
> 
> s/matches/must contain/

Ok, I will reword it.

> > +	- enable-method
> > +		Usage: required on ARM 64-bit systems, optional on ARM 32-bit
> > +		       systems
> > +		Value type: <string>
> > +		Definition: On ARM 64-bit systems must be "spin-table" [1].
> 
> Can that be an integer instead? with dtc+cpp support, that shouldn't
> hurt the eyes too much any more.

Mmm, I need to read more on dtc+cpp, I do not think that leaving it
as a string would hurt though, am I wrong ? Can we assume that all dts
are preprocessed before being compiled and passed to the kernel ?

I need to catch up on dtc+cpp before commenting further though, thanks
for the hint.

> > +	- cpu-release-addr
> > +		Usage: required on ARM 64-bit systems, optional on ARM 32-bit
> > +		       systems
> > +		Value type: <prop-encoded-array>
> > +		Definition: On ARM 64-bit systems must be a two cell
> > +			    property identifying a 64-bit zero-initialised
> > +			    memory location [1].
> 
> Presumably that property is required, or not, based on the value of
> enable-method, not based on the ARM architecture or bit-size?

Yes, you have a point even though the bit-size implicitly plays a role
since we have to decouple 32-bit vs 64-bit boot methods.

> > +[1] ARM Linux kernel documentation
> > +    Documentation/devicetree/bindings/arm64/booting.txt
> 
> Is referencing Linux-specific documentation from a supposedly
> OS-agnostic DT binding definition a good idea?

Well, an OS-agnostic DT binding definition in the Linux kernel Documentation
directory. I would like to hear more on this to understand where these
bindings should be published, for now I have no choice but to point
people at Linux kernel documentation (and the ePAPR does too BTW, even
though it is not for explicit bindings).

Thank you !
Lorenzo



From lorenzo.pieralisi at arm.com  Tue Apr 16 07:00:41 2013
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Tue, 16 Apr 2013 12:00:41 +0100
Subject: [RFC PATCH 2/2] ARM: DT: kernel: DT cpu node bindings update
In-Reply-To: <20130416024146.GG28660@verge.net.au>
References: <1366042402-8987-1-git-send-email-lorenzo.pieralisi@arm.com>
 <1366042402-8987-3-git-send-email-lorenzo.pieralisi@arm.com>
 <20130416024146.GG28660@verge.net.au>
Message-ID: <20130416110040.GB19837@e102568-lin.cambridge.arm.com>

On Tue, Apr 16, 2013 at 03:41:46AM +0100, Simon Horman wrote:
> On Mon, Apr 15, 2013 at 05:13:22PM +0100, Lorenzo Pieralisi wrote:
> > In order to extend the current cpu nodes bindings to newer CPUs
> > inclusive of AArch64 and to update support for older ARM CPUs this
> > patch updates device tree documentation for the cpu nodes bindings.
> >
> > Main changes:
> >
> > - adds 64-bit bindings (inclusive of cpus node #address-cells updates)
> > - defines behaviour on pre and post v7 uniprocessor systems
> > - adds ARM 11MPcore specific reg property definition
> >
> > DT cpu map parsing code must be made compliant with the latest bindings
> > updates, hence this patch also updates the arm_dt_init_cpu_maps() function
> > with checks and additional parsing rules.
> >
> > Uniprocessor systems predating v7 do not parse the cpus node at all
> > since the reg property is meaningless on those systems.
> >
> > Device trees for 64-bit systems can be taken as device tree input also
> > for 64-bit CPUs running in 32-bit mode. The code checks that the reg entries
> > are zeroed as required in the respective fields and detects automatically
> > the cpus node #address-cells value so that device tree written for
> > 64-bit ARM platforms (cpus #address-cells == 2) can still be taken as
> > input. The correct device tree entries are to be set up by the boot
> > loader, kernel code just checks that device tree entries in the cpus
> > node are as expected for a 32-bit CPU (reg[63:24] == 0).
> >
> > cpu node entries with invalid reg property or containing duplicates are
> > ignored and the device tree parsing is not stopped anymore when such
> > entries are encountered, the device tree cpu entry is just skipped.
> >
> > A device tree with cpu nodes missing the boot CPU MPIDR is considered a
> > hard error and the kernel flags this up as a bug to force firmware updates.
> >
> > The updates to cpus/cpu node bindings for ARM require all in-kernel dts files
> > present in the mainline to be made compliant to the latest specification.
> >
> > This patch also updates ARM in-kernel non-compliant dts files to the latest
> > cpus/cpu nodes bindings specification.
> >
> > Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
> > ---
> >  Documentation/devicetree/bindings/arm/cpus.txt | 335 +++++++++++++++++++++----
> >  arch/arm/boot/dts/exynos5440.dtsi              |   7 +
> >  arch/arm/boot/dts/omap3.dtsi                   |   4 +
> >  arch/arm/boot/dts/omap4.dtsi                   |   5 +
> >  arch/arm/boot/dts/omap5.dtsi                   |   5 +
> >  arch/arm/boot/dts/r8a7740.dtsi                 |   3 +
> >  arch/arm/boot/dts/sh7372.dtsi                  |   4 +
> 
> I would prefer if the SoC updates, in particular the sh7372 portion,
> was a separate patch.

Ok, I will split the patch accordingly.

Thanks,
Lorenzo



From mpfj-list at mimc.co.uk  Tue Apr 16 07:09:16 2013
From: mpfj-list at mimc.co.uk (Mark Jackson)
Date: Tue, 16 Apr 2013 12:09:16 +0100
Subject: [PATCH 0/3] Dual EMAC mode implementation of CPSW
In-Reply-To: <516C3A0D.70903@ti.com>
References: <1360612340-9266-1-git-send-email-mugunthanvnm@ti.com>
 <516B0098.4040809@mimc.co.uk> <516C33D2.4050105@ti.com>
 <516C38B9.50904@mimc.co.uk> <516C3A0D.70903@ti.com>
Message-ID: <516D315C.90306@mimc.co.uk>

On 15/04/13 18:34, Mugunthan V N wrote:
> On 4/15/2013 10:58 PM, Mark Jackson wrote:
>> On 15/04/13 18:07, Mugunthan V N wrote:
>>> On 4/15/2013 12:46 AM, Mark Jackson wrote:
>>
>> <snip>
>>
>>>>
>>>> Notice that at the end, the nfs link appears to come back "ok", but
>>>> the "ps" command never completes.
>>>>
>>>> Any ideas of what's going on ?
>>>
>>> I have tried ping on both the interface fine. Will verify with ps again
>>> later in this week.
>>> Can you provide below details details
>>> - Are you using EVMsk or custom build EVM?
>>
>> This is a custom board (based on the BeagleBone design) with dual Ethernet, NAND, NOR and FRAM.
>>
>> The dual emac thing is (one of) the last things to get signed off, so I'm willing to assist in tracking this down.
> 
> After testing the scenario i may be able to send you an update later in this week.

Just a quick update ...

I've now setup our board to boot entirely from NAND (UBoot -> Kernel -> UBIFS) so
that I'm no longer using NFS (just to isolate any issues there).

I am still *unable* to get a connection on either Ethernet port.

*HOWEVER* ... I *can* ping my board from another PC on the network:-

mpfj at mpfj-nanobone:~/uboot/u-boot$ ping 10.0.101.111 -c 5
PING 10.0.101.111 (10.0.101.111) 56(84) bytes of data.
64 bytes from 10.0.101.111: icmp_req=1 ttl=64 time=0.692 ms
64 bytes from 10.0.101.111: icmp_req=2 ttl=64 time=0.551 ms
64 bytes from 10.0.101.111: icmp_req=3 ttl=64 time=0.462 ms
64 bytes from 10.0.101.111: icmp_req=4 ttl=64 time=0.409 ms
64 bytes from 10.0.101.111: icmp_req=5 ttl=64 time=0.344 ms

--- 10.0.101.111 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 3998ms
rtt min/avg/max/mdev = 0.344/0.491/0.692/0.123 ms

So I can't ping *out*, but I can ping *in* !!

Note that I've only tried this ping test to/from eth0 ... I'll
setup another box on the correct IP range so I can also test eth1.

I've added my boot log below.

Cheers
Mark J.
---
U-Boot SPL 2013.04-rc2-00065-g7450e4d-dirty (Apr 16 2013 - 11:36:17)


U-Boot 2013.04-rc2-00065-g7450e4d-dirty (Apr 16 2013 - 11:36:17)

I2C:   ready
DRAM:  256 MiB
WARNING: Caches not enabled
NAND:  256 MiB
MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
Net:   cpsw:0 is connected to cpsw.  Reconnecting to cpsw
cpsw
Hit any key to stop autoboot:  0

NAND read: device 0 offset 0x200000, size 0x400000
 4194304 bytes read: OK
## Booting kernel from Legacy Image at 80200000 ...
   Image Name:   Linux 3.9.0-rc7-00023-gfcc38a5
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2997518 Bytes = 2.9 MiB
   Load Address: 80008000
   Entry Point:  80008000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 3.9.0-rc7-00023-gfcc38a5 (mpfj at mpfj-nanobone) (gcc version 4.5.4 (Buildroot 2012.11) ) #156 Tue Apr 16 08:55:28 BST 2013
[    0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[    0.000000] Machine: Generic AM33XX (Flattened Device Tree), model: Newflow AM335x NanoBone
[    0.000000] debug: ignoring loglevel setting.
[    0.000000] Memory policy: ECC disabled, Data cache writeback
[    0.000000] On node 0 totalpages: 65280
[    0.000000] free_area_init_node: node 0, pgdat c059a858, node_mem_map c0ac4000
[    0.000000]   Normal zone: 512 pages used for memmap
[    0.000000]   Normal zone: 0 pages reserved
[    0.000000]   Normal zone: 65280 pages, LIFO batch:15
[    0.000000] CPU: All CPU(s) started in SVC mode.
[    0.000000] AM335X ES1.0 (neon )
[    0.000000] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
[    0.000000] pcpu-alloc: [0] 0
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 64768
[    0.000000] Kernel command line: console=ttyO0,115200n8 noinitrd ip=off mem=256M rootwait=1 ubi.mtd=4,2048 rootfstype=ubifs root=ubi0:rootfs ignore_loglevel
[    0.000000] PID hash table entries: 1024 (order: 0, 4096 bytes)
[    0.000000] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
[    0.000000] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
[    0.000000] __ex_table already sorted, skipping sort
[    0.000000] Memory: 255MB = 255MB total
[    0.000000] Memory: 247776k/247776k available, 14368k reserved, 0K highmem
[    0.000000] Virtual kernel memory layout:
[    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
[    0.000000]     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
[    0.000000]     vmalloc : 0xd0800000 - 0xff000000   ( 744 MB)
[    0.000000]     lowmem  : 0xc0000000 - 0xd0000000   ( 256 MB)
[    0.000000]     pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
[    0.000000]       .text : 0xc0008000 - 0xc0517550   (5182 kB)
[    0.000000]       .init : 0xc0518000 - 0xc0549fdc   ( 200 kB)
[    0.000000]       .data : 0xc054a000 - 0xc059b420   ( 326 kB)
[    0.000000]        .bss : 0xc059b420 - 0xc0ac0210   (5268 kB)
[    0.000000] NR_IRQS:16 nr_irqs:16 16
[    0.000000] IRQ: Found an INTC at 0xfa200000 (revision 5.0) with 128 interrupts
[    0.000000] Total of 128 interrupts on 1 active controller
[    0.000000] OMAP clockevent source: GPTIMER1 at 26000000 Hz
[    0.000000] sched_clock: 32 bits at 26MHz, resolution 38ns, wraps every 165191ms
[    0.000000] OMAP clocksource: GPTIMER2 at 26000000 Hz
[    0.000000] Console: colour dummy device 80x30
[    0.000000] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
[    0.000000] ... MAX_LOCKDEP_SUBCLASSES:  8
[    0.000000] ... MAX_LOCK_DEPTH:          48
[    0.000000] ... MAX_LOCKDEP_KEYS:        8191
[    0.000000] ... CLASSHASH_SIZE:          4096
[    0.000000] ... MAX_LOCKDEP_ENTRIES:     16384
[    0.000000] ... MAX_LOCKDEP_CHAINS:      32768
[    0.000000] ... CHAINHASH_SIZE:          16384
[    0.000000]  memory used by lock dependency info: 3695 kB
[    0.000000]  per task-struct memory footprint: 1152 bytes
[    0.000847] Calibrating delay loop... 479.23 BogoMIPS (lpj=2396160)
[    0.109871] pid_max: default: 32768 minimum: 301
[    0.110137] Security Framework initialized
[    0.110240] Mount-cache hash table entries: 512
[    0.120776] CPU: Testing write buffer coherency: ok
[    0.122005] Setting up static identity map for 0xc0401520 - 0xc0401578
[    0.125334] devtmpfs: initialized
[    0.187056] pinctrl core: initialized pinctrl subsystem
[    0.192364] regulator-dummy: no parameters
[    0.194592] NET: Registered protocol family 16
[    0.195373] DMA: preallocated 256 KiB pool for atomic coherent allocations
[    0.213975] gpiochip_add: registered GPIOs 0 to 31 on device: gpio
[    0.214363] OMAP GPIO hardware version 0.1
[    0.217164] gpiochip_add: registered GPIOs 32 to 63 on device: gpio
[    0.219783] gpiochip_add: registered GPIOs 64 to 95 on device: gpio
[    0.222396] gpiochip_add: registered GPIOs 96 to 127 on device: gpio
[    0.237302] omap-gpmc 50000000.gpmc: could not find pctldev for node /pinmux at 44e10800/gpmc_pins, deferring probe
[    0.237355] platform 50000000.gpmc: Driver omap-gpmc requests probe deferral
[    0.237973] No ATAGs?
[    0.237993] hw-breakpoint: debug architecture 0x4 unsupported.
[    0.276361] bio: create slab <bio-0> at 0
[    0.342986] omap-dma-engine omap-dma-engine: OMAP DMA engine driver
[    0.349442] usbcore: registered new interface driver usbfs
[    0.350031] usbcore: registered new interface driver hub
[    0.350724] usbcore: registered new device driver usb
[    0.351718] omap_i2c 44e0b000.i2c: could not find pctldev for node /pinmux at 44e10800/i2c1_pins, deferring probe
[    0.351765] platform 44e0b000.i2c: Driver omap_i2c requests probe deferral
[    0.358976] cfg80211: Calling CRDA to update world regulatory domain
[    0.360721] Switching to clocksource gp_timer
[    0.410493] NET: Registered protocol family 2
[    0.412172] TCP established hash table entries: 2048 (order: 2, 16384 bytes)
[    0.412382] TCP bind hash table entries: 2048 (order: 4, 73728 bytes)
[    0.413327] TCP: Hash tables configured (established 2048 bind 2048)
[    0.413543] TCP: reno registered
[    0.413576] UDP hash table entries: 256 (order: 2, 20480 bytes)
[    0.413836] UDP-Lite hash table entries: 256 (order: 2, 20480 bytes)
[    0.414647] NET: Registered protocol family 1
[    0.416021] RPC: Registered named UNIX socket transport module.
[    0.416048] RPC: Registered udp transport module.
[    0.416062] RPC: Registered tcp transport module.
[    0.416076] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    0.416981] NetWinder Floating Point Emulator V0.97 (double precision)
[    0.417431] CPU PMU: probing PMU on CPU 0
[    0.417461] hw perfevents: enabled with ARMv7 Cortex-A8 PMU driver, 5 counters available
[    0.429858] msgmni has been set to 483
[    0.434203] io scheduler noop registered
[    0.434229] io scheduler deadline registered
[    0.434299] io scheduler cfq registered (default)
[    0.435365] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 size 568
[    0.436997] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[    0.444362] 44e09000.serial: ttyO0 at MMIO 0x44e09000 (irq = 88) is a OMAP UART0
[    1.057074] console [ttyO0] enabled
[    1.063340] 48022000.serial: ttyO1 at MMIO 0x48022000 (irq = 89) is a OMAP UART1
[    1.072890] 48024000.serial: ttyO2 at MMIO 0x48024000 (irq = 90) is a OMAP UART2
[    1.082323] 481a6000.serial: ttyO3 at MMIO 0x481a6000 (irq = 60) is a OMAP UART3
[    1.091771] 481a8000.serial: ttyO4 at MMIO 0x481a8000 (irq = 61) is a OMAP UART4
[    1.101172] 481aa000.serial: ttyO5 at MMIO 0x481aa000 (irq = 62) is a OMAP UART5
[    1.135992] brd: module loaded
[    1.155121] loop: module loaded
[    1.161971] Generic platform RAM MTD, (c) 2004 Simtec Electronics
[    1.173565] usbcore: registered new interface driver rt2800usb
[    1.180130] usbcore: registered new interface driver asix
[    1.186291] usbcore: registered new interface driver cdc_ether
[    1.192897] usbcore: registered new interface driver smsc95xx
[    1.199347] usbcore: registered new interface driver net1080
[    1.205770] usbcore: registered new interface driver cdc_subset
[    1.212450] usbcore: registered new interface driver zaurus
[    1.218778] usbcore: registered new interface driver cdc_ncm
[    1.226712] usbcore: registered new interface driver cdc_wdm
[    1.233200] usbcore: registered new interface driver usbtest
[    1.239574] i2c /dev entries driver
[    1.246666] omap_wdt: OMAP Watchdog Timer Rev 0x01: initial timeout 60 sec
[    1.255267] omap_cpufreq_init: unable to get MPU regulator
[    1.263425] leds-gpio leds.3: pins are not configured from the driver
[    1.270281] of_get_named_gpio_flags exited with status 5
[    1.275978] of_get_named_gpio_flags exited with status 5
[    1.284737] usbcore: registered new interface driver usbhid
[    1.290643] usbhid: USB HID core driver
[    1.295943] oprofile: using arm/armv7
[    1.300536] TCP: cubic registered
[    1.304134] Initializing XFRM netlink socket
[    1.308766] NET: Registered protocol family 17
[    1.313610] NET: Registered protocol family 15
[    1.318770] Key type dns_resolver registered
[    1.323453] VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 3
[    1.331650] ThumbEE CPU extension supported.
[    1.340254] omap-gpmc 50000000.gpmc: GPMC revision 6.0
[    1.347867] enabling NAND BCH ecc with 8-bit correction
[    1.353814] ONFI param page 0 valid
[    1.357509] ONFI flash detected
[    1.360873] NAND device: Manufacturer ID: 0x2c, Chip ID: 0xda (Micron MT29F2G08ABAEAWP), 256MiB, page size: 2048, OOB size: 64
[    1.373151] 6 ofpart partitions found on MTD device omap2-nand.0
[    1.379506] Creating 6 MTD partitions on "omap2-nand.0":
[    1.385173] 0x000000000000-0x000000020000 : "spl"
[    1.392610] 0x000000020000-0x0000001e0000 : "boot"
[    1.399934] 0x0000001e0000-0x000000200000 : "env"
[    1.405820] 0x000000200000-0x000000600000 : "kernel"
[    1.415189] 0x000000600000-0x000004600000 : "rootfs"
[    1.476147] 0x000004600000-0x000010000000 : "data"
[    1.645387] omap_i2c 44e0b000.i2c: bus 0 rev0.11 at 400 kHz
[    1.652197] mcp230xx 0-0020: invalid or missing platform data
[    1.658321] mcp230xx: probe of 0-0020 failed with error -22
[    1.669107] DCDC1: at 1800 mV
[    1.674476] vdd_mpu: 925 <--> 1325 mV at 3300 mV
[    1.681644] vdd_core: 925 <--> 1150 mV at 1100 mV
[    1.688614] LDO1: at 1800 mV
[    1.693751] LDO2: at 3300 mV
[    1.698747] LDO3: at 1800 mV
[    1.703850] LDO4: at 2800 mV
[    1.708625] tps65217 0-0024: TPS65217 ID 0x7 version 1.1
[    1.715197] at24 0-0053: 256 byte 24c02 EEPROM, writable, 8 bytes/write
[    1.725928] rtc-ds1307 0-0068: rtc core: registered ds1307 as rtc0
[    1.732584] rtc-ds1307 0-0068: 56 bytes nvram
[    1.739183] UBI: attaching mtd4 to ubi0
[    2.062968] UBI: scanning is finished
[    2.074398] UBI warning: print_rsvd_warning: cannot reserve enough PEBs for bad PEB handling, reserved 4, need 40
[    2.089143] UBI: attached mtd4 (name "rootfs", size 64 MiB) to ubi0
[    2.095874] UBI: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
[    2.103085] UBI: min./max. I/O unit sizes: 2048/2048, sub-page size 512
[    2.110079] UBI: VID header offset: 2048 (aligned 2048), data offset: 4096
[    2.117376] UBI: good PEBs: 512, bad PEBs: 0, corrupted PEBs: 0
[    2.123661] UBI: user volume: 1, internal volumes: 1, max. volumes count: 128
[    2.131233] UBI: max/mean erase counter: 2/1, WL threshold: 4096, image sequence number: 1434266085
[    2.140824] UBI: available PEBs: 0, total reserved PEBs: 512, PEBs reserved for bad PEB handling: 4
[    2.151800] UBI: background thread "ubi_bgt0d" started, PID 591
[    2.220904] davinci_mdio 4a101000.mdio: davinci mdio revision 1.6
[    2.227366] davinci_mdio 4a101000.mdio: detected phy mask fffffffc
[    2.236894] libphy: 4a101000.mdio: probed
[    2.241232] davinci_mdio 4a101000.mdio: phy[0]: device 4a101000.mdio:00, driver SMSC LAN8710/LAN8720
[    2.250932] davinci_mdio 4a101000.mdio: phy[1]: device 4a101000.mdio:01, driver SMSC LAN8710/LAN8720
[    2.260831] Missing dual_emac_res_vlan in DT.
[    2.265440] Using 1 as Reserved VLAN for 0 slave
[    2.270383] Missing dual_emac_res_vlan in DT.
[    2.275018] Using 2 as Reserved VLAN for 1 slave
[    2.280057] Random MACID = 7a:9d:bf:22:b3:c7
[    2.287417] cpsw: Random MACID = 1a:48:dc:88:09:4d
[    2.295871] rtc-ds1307 0-0068: setting system clock to 2013-04-16 11:38:41 UTC (1366112321)
[    2.373950] UBIFS: mounted UBI device 0, volume 0, name "rootfs", R/O mode
[    2.381327] UBIFS: LEB size: 126976 bytes (124 KiB), min./max. I/O unit sizes: 2048 bytes/2048 bytes
[    2.391019] UBIFS: FS size: 60059648 bytes (57 MiB, 473 LEBs), journal size 7999488 bytes (7 MiB, 63 LEBs)
[    2.401254] UBIFS: reserved for root: 0 bytes (0 KiB)
[    2.406601] UBIFS: media format: w4/r0 (latest is w4/r0), UUID 93286679-C044-4BC4-8FCB-6E5055E65825, small LPT model
[    2.419981] VFS: Mounted root (ubifs filesystem) readonly on device 0:12.
[    2.429644] devtmpfs: mounted
[    2.433300] Freeing init memory: 196K
[    2.558990] UBIFS: background thread "ubifs_bgt0_0" started, PID 604
Starting logging: OK
Initializing random number generator... done.
Starting network...
[    2.870749] net eth0: initializing cpsw version 1.12 (0)
[    2.879972] net eth0: phy found : id is : 0x7c0f1
[    2.943874] net eth1: initializing cpsw version 1.12 (0)
[    2.952704] net eth1: phy found : id is : 0x7c0f1
ip: RTNETLINK answers: File exists
Starting dropbear sshd: OK
Starting lighttpd: OK

Welcome to Buildroot
nanobone login: root
Password: 
[    5.951540] libphy: 4a101000.mdio:00 - Link is Up - 100/Full

# cat /etc/network/interfaces
# Configure Loopback
auto lo eth0 eth1
iface lo inet loopback
iface eth0 inet static
address 10.0.101.111
netmask 255.255.0.0
gateway 10.0.0.1
iface eth1 inet static
address 10.1.101.111
netmask 255.255.0.0
gateway 10.1.0.1

# ifconfig
eth0      Link encap:Ethernet  HWaddr 7A:9D:BF:22:B3:C7
          inet addr:10.0.101.111  Bcast:0.0.0.0  Mask:255.255.0.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:11 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:704 (704.0 B)  TX bytes:0 (0.0 B)
          Interrupt:56

eth1      Link encap:Ethernet  HWaddr 1A:48:DC:88:09:4D
          inet addr:10.1.101.111  Bcast:0.0.0.0  Mask:255.255.0.0
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

#
[   20.031081] libphy: 4a101000.mdio:00 - Link is Down
[   24.391357] libphy: 4a101000.mdio:01 - Link is Up - 100/Full
[   30.471110] libphy: 4a101000.mdio:01 - Link is Down
[   33.991395] libphy: 4a101000.mdio:00 - Link is Up - 100/Full
#
#
# ping 10.0.0.1
PING 10.0.0.1 (10.0.0.1): 56 data bytes

--- 10.0.0.1 ping statistics ---
46 packets transmitted, 0 packets received, 100% packet loss
# 
# ping 10.0.101.111
PING 10.0.101.111 (10.0.101.111): 56 data bytes
64 bytes from 10.0.101.111: seq=0 ttl=64 time=0.364 ms
64 bytes from 10.0.101.111: seq=1 ttl=64 time=0.252 ms

--- 10.0.101.111 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 0.252/0.308/0.364 ms
# ping 127.0.0.1
PING 127.0.0.1 (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: seq=0 ttl=64 time=0.751 ms
64 bytes from 127.0.0.1: seq=1 ttl=64 time=0.303 ms
#



From broonie at kernel.org  Tue Apr 16 07:20:35 2013
From: broonie at kernel.org (Mark Brown)
Date: Tue, 16 Apr 2013 12:20:35 +0100
Subject: [PATCH V4 2/5] spi: s3c64xx: added support for polling mode
In-Reply-To: <1366015230-18243-1-git-send-email-ks.giri@samsung.com>
References: <1366015230-18243-1-git-send-email-ks.giri@samsung.com>
Message-ID: <20130416112035.GD26958@opensource.wolfsonmicro.com>

On Mon, Apr 15, 2013 at 02:10:27PM +0530, Girish K S wrote:
> From: Girish K S <girishks2000 at gmail.com>
> 
> The 64xx spi driver supports partial polling mode.
> Only the last chunk of the transfer length is transferred
> or recieved in polling mode.

I'm missing patch 1 of this series.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130416/fad8a0c1/attachment.sig>

From girishks2000 at gmail.com  Tue Apr 16 07:28:47 2013
From: girishks2000 at gmail.com (Girish KS)
Date: Tue, 16 Apr 2013 16:58:47 +0530
Subject: [PATCH V4 2/5] spi: s3c64xx: added support for polling mode
In-Reply-To: <20130416112035.GD26958@opensource.wolfsonmicro.com>
References: <1366015230-18243-1-git-send-email-ks.giri@samsung.com>
 <20130416112035.GD26958@opensource.wolfsonmicro.com>
Message-ID: <CAKrE-Kd4Vis0-V_n8zEzqJVBbEYvTiYS8hY_7s7AnUqaK2tFCQ@mail.gmail.com>

On Tue, Apr 16, 2013 at 4:50 PM, Mark Brown <broonie at kernel.org> wrote:
> On Mon, Apr 15, 2013 at 02:10:27PM +0530, Girish K S wrote:
>> From: Girish K S <girishks2000 at gmail.com>
>>
>> The 64xx spi driver supports partial polling mode.
>> Only the last chunk of the transfer length is transferred
>> or recieved in polling mode.
>
> I'm missing patch 1 of this series.

its already  merged to stable tree after your review


From jason at lakedaemon.net  Tue Apr 16 07:29:51 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Tue, 16 Apr 2013 07:29:51 -0400
Subject: [PATCH v6 0/3] of/pci: Provide common support for PCI DT parsing
In-Reply-To: <1366096361.24994.49.camel@pasglop>
References: <1365693969-23907-1-git-send-email-Andrew.Murray@arm.com>
 <20130415175641.GM28693@titan.lakedaemon.net>
 <CACRpkdbSd8pRG5pUS0ymqXDSp=ZhoQa2ctVuRA0cCmUcX5qFAA@mail.gmail.com>
 <1366096361.24994.49.camel@pasglop>
Message-ID: <20130416112951.GZ28693@titan.lakedaemon.net>

On Tue, Apr 16, 2013 at 09:12:41AM +0200, Benjamin Herrenschmidt wrote:
> On Mon, 2013-04-15 at 20:29 +0200, Linus Walleij wrote:
> > > As agreed with Rob Herring, series applied to mvebu/drivers to
> > support
> > > mvebu pcie driver.
> > 
> > Will this hit ARM SoC soon-ish so I can base a pull request for the
> > Integrator on this stuff as well?
> 
> Do not send this series upstream (or even in -next) until it has been at
> least build-tested and acked by the affected architectures. AFAIK it
> breaks microblaze build (simple missing #include) and isn't yet tested
> on powerpc (I'm on vacation, maybe somebody else on linuxppc-dev can do
> it though).

I added the missing include reference by Michal Simek for the branch at
mvebu/drivers.

thx,

Jason.


From thomas.petazzoni at free-electrons.com  Tue Apr 16 07:31:40 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Tue, 16 Apr 2013 13:31:40 +0200
Subject: [PATCH v6 0/3] of/pci: Provide common support for PCI DT parsing
In-Reply-To: <20130416112951.GZ28693@titan.lakedaemon.net>
References: <1365693969-23907-1-git-send-email-Andrew.Murray@arm.com>
 <20130415175641.GM28693@titan.lakedaemon.net>
 <CACRpkdbSd8pRG5pUS0ymqXDSp=ZhoQa2ctVuRA0cCmUcX5qFAA@mail.gmail.com>
 <1366096361.24994.49.camel@pasglop>
 <20130416112951.GZ28693@titan.lakedaemon.net>
Message-ID: <20130416133140.7de24c89@skate>

Dear Jason Cooper,

On Tue, 16 Apr 2013 07:29:51 -0400, Jason Cooper wrote:

> > Do not send this series upstream (or even in -next) until it has been at
> > least build-tested and acked by the affected architectures. AFAIK it
> > breaks microblaze build (simple missing #include) and isn't yet tested
> > on powerpc (I'm on vacation, maybe somebody else on linuxppc-dev can do
> > it though).
> 
> I added the missing include reference by Michal Simek for the branch at
> mvebu/drivers.

Some other build issues were reported on x86 during the night (thanks
to automated build tests), and Andrew Murray has just sent a new
version v7 of the patch set addressing those issues, as well as the
missing include.

Also, please note that Andrew's patch set contains three patches, but
the Marvell PCIe driver only requires PATCH 1/3 and PATCH 2/3.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From jason at lakedaemon.net  Tue Apr 16 07:37:27 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Tue, 16 Apr 2013 07:37:27 -0400
Subject: [PATCH v6 0/3] of/pci: Provide common support for PCI DT parsing
In-Reply-To: <20130416133140.7de24c89@skate>
References: <1365693969-23907-1-git-send-email-Andrew.Murray@arm.com>
 <20130415175641.GM28693@titan.lakedaemon.net>
 <CACRpkdbSd8pRG5pUS0ymqXDSp=ZhoQa2ctVuRA0cCmUcX5qFAA@mail.gmail.com>
 <1366096361.24994.49.camel@pasglop>
 <20130416112951.GZ28693@titan.lakedaemon.net>
 <20130416133140.7de24c89@skate>
Message-ID: <20130416113727.GA28693@titan.lakedaemon.net>

On Tue, Apr 16, 2013 at 01:31:40PM +0200, Thomas Petazzoni wrote:
> Dear Jason Cooper,
> 
> On Tue, 16 Apr 2013 07:29:51 -0400, Jason Cooper wrote:
> 
> > > Do not send this series upstream (or even in -next) until it has been at
> > > least build-tested and acked by the affected architectures. AFAIK it
> > > breaks microblaze build (simple missing #include) and isn't yet tested
> > > on powerpc (I'm on vacation, maybe somebody else on linuxppc-dev can do
> > > it though).
> > 
> > I added the missing include reference by Michal Simek for the branch at
> > mvebu/drivers.
> 
> Some other build issues were reported on x86 during the night (thanks
> to automated build tests), and Andrew Murray has just sent a new
> version v7 of the patch set addressing those issues, as well as the
> missing include.
> 
> Also, please note that Andrew's patch set contains three patches, but
> the Marvell PCIe driver only requires PATCH 1/3 and PATCH 2/3.

Ok.  Thanks Andrew!  Do you (AndrewM) want me to keep the series
together?  Or drop 3/3 from my tree?  I can do either, I just need to
know.

thx,

Jason.


From andrew.murray at arm.com  Tue Apr 16 07:49:03 2013
From: andrew.murray at arm.com (Andrew Murray)
Date: Tue, 16 Apr 2013 12:49:03 +0100
Subject: [PATCH v6 1/3] of/pci: Unify pci_process_bridge_OF_ranges from
 Microblaze and PowerPC
In-Reply-To: <516C2FEF.7080006@monstr.eu>
References: <1365693969-23907-1-git-send-email-Andrew.Murray@arm.com>
 <1365693969-23907-2-git-send-email-Andrew.Murray@arm.com>
 <20130415145741.4e4c362b@skate> <516C2FEF.7080006@monstr.eu>
Message-ID: <20130416114903.GA13259@arm.com>

On Mon, Apr 15, 2013 at 05:50:55PM +0100, Michal Simek wrote:
> That's why please add this header to this patch.
> 
> diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
> index 3e428a1..f30887e 100644
> --- a/drivers/of/of_pci.c
> +++ b/drivers/of/of_pci.c
> @@ -1,6 +1,7 @@
>  #include <linux/kernel.h>
>  #include <linux/export.h>
>  #include <linux/of.h>
> +#include <linux/of_address.h>
>  #include <linux/of_pci.h>
>  #include <asm/prom.h>
> 
> 
> When you fix it:
> Acked-by: Michal Simek <monstr at monstr.eu>

I've added this fix to the latest patchset (v7) and also your Ack - thanks for
your feedback (and the robot...).

Andrew Murray


From nicolas.ferre at atmel.com  Tue Apr 16 07:49:34 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Tue, 16 Apr 2013 13:49:34 +0200
Subject: [PATCH] dmaengine: at_hdmac: fix race condition in atc_advance_work()
Message-ID: <1366112974-32043-1-git-send-email-nicolas.ferre@atmel.com>

From: Ludovic Desroches <ludovic.desroches at atmel.com>

The BUG_ON() directive is triggered probably due to a latency modification
following inclusion of c10d736 (softirq: reduce latencies).
This condition has not been met before 3.9-rc1 and doesn't trigger without
this patch.

We now make sure that DMA channel is idle before calling atc_complete_all()
which makes the BUG_ON() "protection" useless.

Signed-off-by: Ludovic Desroches <ludovic.desroches at atmel.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre at atmel.com>
---
Linus,

We have identified a race condition on the Atmel ARM-based AT91 DMA controller
driver that leads to hitting a BUG_ON() directive.
This error, only triggered after the inclusion of a patch that reduces the
softirq latency, is affecting several AT91 SoCs and can be seen
as a regression by people using the dmaengine driver (on NAND flash
accesses for instance).

I know that it is late in the development cycle but can you please consider
including it in your tree before 3.9-final?

This patch can also go through dmaengine tree (Vinod Koul) but I do not know if
there is enough time remaining.

Thanks a lot, best regards,

Nicolas Ferre


 drivers/dma/at_hdmac.c | 9 ++++-----
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/dma/at_hdmac.c b/drivers/dma/at_hdmac.c
index 6e13f26..88cfc61 100644
--- a/drivers/dma/at_hdmac.c
+++ b/drivers/dma/at_hdmac.c
@@ -310,8 +310,6 @@ static void atc_complete_all(struct at_dma_chan *atchan)
 
 	dev_vdbg(chan2dev(&atchan->chan_common), "complete all\n");
 
-	BUG_ON(atc_chan_is_enabled(atchan));
-
 	/*
 	 * Submit queued descriptors ASAP, i.e. before we go through
 	 * the completed ones.
@@ -368,6 +366,9 @@ static void atc_advance_work(struct at_dma_chan *atchan)
 {
 	dev_vdbg(chan2dev(&atchan->chan_common), "advance_work\n");
 
+	if (atc_chan_is_enabled(atchan))
+		return;
+
 	if (list_empty(&atchan->active_list) ||
 	    list_is_singular(&atchan->active_list)) {
 		atc_complete_all(atchan);
@@ -1078,9 +1079,7 @@ static void atc_issue_pending(struct dma_chan *chan)
 		return;
 
 	spin_lock_irqsave(&atchan->lock, flags);
-	if (!atc_chan_is_enabled(atchan)) {
-		atc_advance_work(atchan);
-	}
+	atc_advance_work(atchan);
 	spin_unlock_irqrestore(&atchan->lock, flags);
 }
 
-- 
1.8.0



From broonie at kernel.org  Tue Apr 16 07:59:43 2013
From: broonie at kernel.org (Mark Brown)
Date: Tue, 16 Apr 2013 12:59:43 +0100
Subject: [PATCH v3 05/15] ASoC: phycore-ac97: Add DT support
In-Reply-To: <1365939779-4507-6-git-send-email-mpa@pengutronix.de>
References: <1365939779-4507-1-git-send-email-mpa@pengutronix.de>
 <1365939779-4507-6-git-send-email-mpa@pengutronix.de>
Message-ID: <20130416115942.GG26958@opensource.wolfsonmicro.com>

On Sun, Apr 14, 2013 at 01:42:49PM +0200, Markus Pargmann wrote:

> +	/*
> +	 * This driver doesn't need to know which actual hardware is used.
> +	 * The audmux driver has knowledge about it's type, and returns
> +	 * an error if executed on the wrong type of hardware.
> +	 */
> +	ret = phycore_ac97_pca100_audmux();
> +	if (!ret)
> +		return 0;
> +
> +	ret = phycore_ac97_pcm043_audmux();

The DT really ought to be able to give enough information to figure out
the audmux configuration.  If we can't do that it rather defeats the
point of moving to DT...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130416/c8e2f1bc/attachment.sig>

From andrew.murray at arm.com  Tue Apr 16 07:59:29 2013
From: andrew.murray at arm.com (Andrew Murray)
Date: Tue, 16 Apr 2013 12:59:29 +0100
Subject: [PATCH v6 0/3] of/pci: Provide common support for PCI DT parsing
In-Reply-To: <20130416113727.GA28693@titan.lakedaemon.net>
References: <1365693969-23907-1-git-send-email-Andrew.Murray@arm.com>
 <20130415175641.GM28693@titan.lakedaemon.net>
 <CACRpkdbSd8pRG5pUS0ymqXDSp=ZhoQa2ctVuRA0cCmUcX5qFAA@mail.gmail.com>
 <1366096361.24994.49.camel@pasglop>
 <20130416112951.GZ28693@titan.lakedaemon.net>
 <20130416133140.7de24c89@skate>
 <20130416113727.GA28693@titan.lakedaemon.net>
Message-ID: <20130416115929.GB13259@arm.com>

On Tue, Apr 16, 2013 at 12:37:27PM +0100, Jason Cooper wrote:
> On Tue, Apr 16, 2013 at 01:31:40PM +0200, Thomas Petazzoni wrote:
> > Dear Jason Cooper,
> > 
> > On Tue, 16 Apr 2013 07:29:51 -0400, Jason Cooper wrote:
> > 
> > > > Do not send this series upstream (or even in -next) until it has been at
> > > > least build-tested and acked by the affected architectures. AFAIK it
> > > > breaks microblaze build (simple missing #include) and isn't yet tested
> > > > on powerpc (I'm on vacation, maybe somebody else on linuxppc-dev can do
> > > > it though).
> > > 
> > > I added the missing include reference by Michal Simek for the branch at
> > > mvebu/drivers.
> > 
> > Some other build issues were reported on x86 during the night (thanks
> > to automated build tests), and Andrew Murray has just sent a new
> > version v7 of the patch set addressing those issues, as well as the
> > missing include.
> > 
> > Also, please note that Andrew's patch set contains three patches, but
> > the Marvell PCIe driver only requires PATCH 1/3 and PATCH 2/3.
> 
> Ok.  Thanks Andrew!  Do you (AndrewM) want me to keep the series
> together?  Or drop 3/3 from my tree?  I can do either, I just need to
> know.

Patch 1 has an ack from Microblaze but not yet from PowerPC, it probably needs
an ack from both of these before moving upwards.

Patch 3 is awaiting feedback from Mips, ideally all three patches could stay
together but if feedback blocks this then I guess it could go alone later.

Andrew Murray


From broonie at kernel.org  Tue Apr 16 08:03:29 2013
From: broonie at kernel.org (Mark Brown)
Date: Tue, 16 Apr 2013 13:03:29 +0100
Subject: [PATCH v3 08/15] ASoC: fsl-ssi: Add SACNT definitions
In-Reply-To: <1365939779-4507-9-git-send-email-mpa@pengutronix.de>
References: <1365939779-4507-1-git-send-email-mpa@pengutronix.de>
 <1365939779-4507-9-git-send-email-mpa@pengutronix.de>
Message-ID: <20130416120329.GI26958@opensource.wolfsonmicro.com>

On Sun, Apr 14, 2013 at 01:42:52PM +0200, Markus Pargmann wrote:
> Add definitions for AC97 control register.

Applied, thanks.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130416/d57826bc/attachment.sig>

From broonie at kernel.org  Tue Apr 16 08:12:55 2013
From: broonie at kernel.org (Mark Brown)
Date: Tue, 16 Apr 2013 13:12:55 +0100
Subject: [PATCH V4 2/5] spi: s3c64xx: added support for polling mode
In-Reply-To: <CAKrE-Kd4Vis0-V_n8zEzqJVBbEYvTiYS8hY_7s7AnUqaK2tFCQ@mail.gmail.com>
References: <1366015230-18243-1-git-send-email-ks.giri@samsung.com>
 <20130416112035.GD26958@opensource.wolfsonmicro.com>
 <CAKrE-Kd4Vis0-V_n8zEzqJVBbEYvTiYS8hY_7s7AnUqaK2tFCQ@mail.gmail.com>
Message-ID: <20130416121255.GA15878@sirena.org.uk>

On Tue, Apr 16, 2013 at 04:58:47PM +0530, Girish KS wrote:
> On Tue, Apr 16, 2013 at 4:50 PM, Mark Brown <broonie at kernel.org> wrote:

> > I'm missing patch 1 of this series.

> its already  merged to stable tree after your review

The patch numbering should reflect what you're posting.  If you're only
sending four patches they should be numbered 1-4, otherwise it looks
like there's something missing.  The goal with the numbers is to help
people get the patches in the right order, the name should be enough to
associate with other versions of the same patch.


From nicolas.ferre at atmel.com  Tue Apr 16 08:33:51 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Tue, 16 Apr 2013 14:33:51 +0200
Subject: [PATCH 1/8] video: atmel_lcdfb: fix platform data struct
In-Reply-To: <1365692422-9565-1-git-send-email-plagnioj@jcrosoft.com>
References: <20130411145741.GB25242@game.jcrosoft.org>
 <1365692422-9565-1-git-send-email-plagnioj@jcrosoft.com>
Message-ID: <516D452F.2000109@atmel.com>

On 04/11/2013 05:00 PM, Jean-Christophe PLAGNIOL-VILLARD :
> Today we mix pdata and drivers data in the struct atmel_lcdfb_info
> Fix it and introduce a new struct atmel_lcdfb_pdata for platform data only
> 
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
> Cc: linux-fbdev at vger.kernel.org
> Cc: Nicolas Ferre <nicolas.ferre at atmel.com>
> Cc: Andrew Morton <akpm at linux-foundation.org>
> Cc: Hans-Christian Egtvedt <egtvedt at samfundet.no>
> ---
>  arch/arm/mach-at91/at91sam9261_devices.c    |    6 +-
>  arch/arm/mach-at91/at91sam9263_devices.c    |    6 +-
>  arch/arm/mach-at91/at91sam9g45_devices.c    |    6 +-
>  arch/arm/mach-at91/at91sam9rl_devices.c     |    6 +-
>  arch/arm/mach-at91/board-sam9261ek.c        |    6 +-
>  arch/arm/mach-at91/board-sam9263ek.c        |    4 +-
>  arch/arm/mach-at91/board-sam9m10g45ek.c     |    4 +-
>  arch/arm/mach-at91/board-sam9rlek.c         |    4 +-
>  arch/arm/mach-at91/board.h                  |    4 +-
>  arch/avr32/boards/atngw100/evklcd10x.c      |    6 +-
>  arch/avr32/boards/atngw100/mrmt.c           |    4 +-
>  arch/avr32/boards/atstk1000/atstk1000.h     |    2 +-
>  arch/avr32/boards/atstk1000/setup.c         |    2 +-
>  arch/avr32/boards/favr-32/setup.c           |    2 +-
>  arch/avr32/boards/hammerhead/setup.c        |    2 +-
>  arch/avr32/boards/merisc/display.c          |    2 +-
>  arch/avr32/boards/mimc200/setup.c           |    4 +-
>  arch/avr32/mach-at32ap/at32ap700x.c         |    8 +--
>  arch/avr32/mach-at32ap/include/mach/board.h |    4 +-
>  drivers/video/atmel_lcdfb.c                 |  104 +++++++++++++++++----------
>  include/video/atmel_lcdc.h                  |   24 +------
>  21 files changed, 109 insertions(+), 101 deletions(-)
> 
> diff --git a/arch/arm/mach-at91/at91sam9261_devices.c b/arch/arm/mach-at91/at91sam9261_devices.c
> index 629ea5f..b2a3474 100644
> --- a/arch/arm/mach-at91/at91sam9261_devices.c
> +++ b/arch/arm/mach-at91/at91sam9261_devices.c
> @@ -465,7 +465,7 @@ void __init at91_add_device_spi(struct spi_board_info *devices, int nr_devices)
>  
>  #if defined(CONFIG_FB_ATMEL) || defined(CONFIG_FB_ATMEL_MODULE)
>  static u64 lcdc_dmamask = DMA_BIT_MASK(32);
> -static struct atmel_lcdfb_info lcdc_data;
> +static struct atmel_lcdfb_pdata lcdc_data;
>  
>  static struct resource lcdc_resources[] = {
>  	[0] = {
> @@ -498,7 +498,7 @@ static struct platform_device at91_lcdc_device = {
>  	.num_resources	= ARRAY_SIZE(lcdc_resources),
>  };
>  
> -void __init at91_add_device_lcdc(struct atmel_lcdfb_info *data)
> +void __init at91_add_device_lcdc(struct atmel_lcdfb_pdata *data)
>  {
>  	if (!data) {
>  		return;
> @@ -559,7 +559,7 @@ void __init at91_add_device_lcdc(struct atmel_lcdfb_info *data)
>  	platform_device_register(&at91_lcdc_device);
>  }
>  #else
> -void __init at91_add_device_lcdc(struct atmel_lcdfb_info *data) {}
> +void __init at91_add_device_lcdc(struct atmel_lcdfb_pdata *data) {}
>  #endif
>  
>  
> diff --git a/arch/arm/mach-at91/at91sam9263_devices.c b/arch/arm/mach-at91/at91sam9263_devices.c
> index 858c8aa..4aeaddd 100644
> --- a/arch/arm/mach-at91/at91sam9263_devices.c
> +++ b/arch/arm/mach-at91/at91sam9263_devices.c
> @@ -832,7 +832,7 @@ void __init at91_add_device_can(struct at91_can_data *data) {}
>  
>  #if defined(CONFIG_FB_ATMEL) || defined(CONFIG_FB_ATMEL_MODULE)
>  static u64 lcdc_dmamask = DMA_BIT_MASK(32);
> -static struct atmel_lcdfb_info lcdc_data;
> +static struct atmel_lcdfb_pdata lcdc_data;
>  
>  static struct resource lcdc_resources[] = {
>  	[0] = {
> @@ -859,7 +859,7 @@ static struct platform_device at91_lcdc_device = {
>  	.num_resources	= ARRAY_SIZE(lcdc_resources),
>  };
>  
> -void __init at91_add_device_lcdc(struct atmel_lcdfb_info *data)
> +void __init at91_add_device_lcdc(struct atmel_lcdfb_pdata *data)
>  {
>  	if (!data)
>  		return;
> @@ -891,7 +891,7 @@ void __init at91_add_device_lcdc(struct atmel_lcdfb_info *data)
>  	platform_device_register(&at91_lcdc_device);
>  }
>  #else
> -void __init at91_add_device_lcdc(struct atmel_lcdfb_info *data) {}
> +void __init at91_add_device_lcdc(struct atmel_lcdfb_pdata *data) {}
>  #endif
>  
>  
> diff --git a/arch/arm/mach-at91/at91sam9g45_devices.c b/arch/arm/mach-at91/at91sam9g45_devices.c
> index fe626d4..82636c7 100644
> --- a/arch/arm/mach-at91/at91sam9g45_devices.c
> +++ b/arch/arm/mach-at91/at91sam9g45_devices.c
> @@ -965,7 +965,7 @@ void __init at91_add_device_isi(struct isi_platform_data *data,
>  
>  #if defined(CONFIG_FB_ATMEL) || defined(CONFIG_FB_ATMEL_MODULE)
>  static u64 lcdc_dmamask = DMA_BIT_MASK(32);
> -static struct atmel_lcdfb_info lcdc_data;
> +static struct atmel_lcdfb_pdata lcdc_data;
>  
>  static struct resource lcdc_resources[] = {
>  	[0] = {
> @@ -991,7 +991,7 @@ static struct platform_device at91_lcdc_device = {
>  	.num_resources	= ARRAY_SIZE(lcdc_resources),
>  };
>  
> -void __init at91_add_device_lcdc(struct atmel_lcdfb_info *data)
> +void __init at91_add_device_lcdc(struct atmel_lcdfb_pdata *data)
>  {
>  	if (!data)
>  		return;
> @@ -1037,7 +1037,7 @@ void __init at91_add_device_lcdc(struct atmel_lcdfb_info *data)
>  	platform_device_register(&at91_lcdc_device);
>  }
>  #else
> -void __init at91_add_device_lcdc(struct atmel_lcdfb_info *data) {}
> +void __init at91_add_device_lcdc(struct atmel_lcdfb_pdata *data) {}
>  #endif
>  
>  
> diff --git a/arch/arm/mach-at91/at91sam9rl_devices.c b/arch/arm/mach-at91/at91sam9rl_devices.c
> index 352468f..a698bda 100644
> --- a/arch/arm/mach-at91/at91sam9rl_devices.c
> +++ b/arch/arm/mach-at91/at91sam9rl_devices.c
> @@ -498,7 +498,7 @@ void __init at91_add_device_ac97(struct ac97c_platform_data *data) {}
>  
>  #if defined(CONFIG_FB_ATMEL) || defined(CONFIG_FB_ATMEL_MODULE)
>  static u64 lcdc_dmamask = DMA_BIT_MASK(32);
> -static struct atmel_lcdfb_info lcdc_data;
> +static struct atmel_lcdfb_pdata lcdc_data;
>  
>  static struct resource lcdc_resources[] = {
>  	[0] = {
> @@ -525,7 +525,7 @@ static struct platform_device at91_lcdc_device = {
>  	.num_resources	= ARRAY_SIZE(lcdc_resources),
>  };
>  
> -void __init at91_add_device_lcdc(struct atmel_lcdfb_info *data)
> +void __init at91_add_device_lcdc(struct atmel_lcdfb_pdata *data)
>  {
>  	if (!data) {
>  		return;
> @@ -557,7 +557,7 @@ void __init at91_add_device_lcdc(struct atmel_lcdfb_info *data)
>  	platform_device_register(&at91_lcdc_device);
>  }
>  #else
> -void __init at91_add_device_lcdc(struct atmel_lcdfb_info *data) {}
> +void __init at91_add_device_lcdc(struct atmel_lcdfb_pdata *data) {}
>  #endif
>  
>  
> diff --git a/arch/arm/mach-at91/board-sam9261ek.c b/arch/arm/mach-at91/board-sam9261ek.c
> index b446645..c819e29 100644
> --- a/arch/arm/mach-at91/board-sam9261ek.c
> +++ b/arch/arm/mach-at91/board-sam9261ek.c
> @@ -405,7 +405,7 @@ static void at91_lcdc_stn_power_control(int on)
>  	}
>  }
>  
> -static struct atmel_lcdfb_info __initdata ek_lcdc_data = {
> +static struct atmel_lcdfb_pdata __initdata ek_lcdc_data = {
>  	.default_bpp			= 1,
>  	.default_dmacon			= ATMEL_LCDC_DMAEN,
>  	.default_lcdcon2		= AT91SAM9261_DEFAULT_STN_LCDCON2,
> @@ -460,7 +460,7 @@ static void at91_lcdc_tft_power_control(int on)
>  		at91_set_gpio_value(AT91_PIN_PA12, 1);	/* power down */
>  }
>  
> -static struct atmel_lcdfb_info __initdata ek_lcdc_data = {
> +static struct atmel_lcdfb_pdata __initdata ek_lcdc_data = {
>  	.lcdcon_is_backlight		= true,
>  	.default_bpp			= 16,
>  	.default_dmacon			= ATMEL_LCDC_DMAEN,
> @@ -475,7 +475,7 @@ static struct atmel_lcdfb_info __initdata ek_lcdc_data = {
>  #endif
>  
>  #else
> -static struct atmel_lcdfb_info __initdata ek_lcdc_data;
> +static struct atmel_lcdfb_pdata __initdata ek_lcdc_data;
>  #endif
>  
>  
> diff --git a/arch/arm/mach-at91/board-sam9263ek.c b/arch/arm/mach-at91/board-sam9263ek.c
> index 3284df0..0fdae3f 100644
> --- a/arch/arm/mach-at91/board-sam9263ek.c
> +++ b/arch/arm/mach-at91/board-sam9263ek.c
> @@ -281,7 +281,7 @@ static void at91_lcdc_power_control(int on)
>  }
>  
>  /* Driver datas */
> -static struct atmel_lcdfb_info __initdata ek_lcdc_data = {
> +static struct atmel_lcdfb_pdata __initdata ek_lcdc_data = {
>  	.lcdcon_is_backlight		= true,
>  	.default_bpp			= 16,
>  	.default_dmacon			= ATMEL_LCDC_DMAEN,
> @@ -292,7 +292,7 @@ static struct atmel_lcdfb_info __initdata ek_lcdc_data = {
>  };
>  
>  #else
> -static struct atmel_lcdfb_info __initdata ek_lcdc_data;
> +static struct atmel_lcdfb_pdata __initdata ek_lcdc_data;
>  #endif
>  
>  
> diff --git a/arch/arm/mach-at91/board-sam9m10g45ek.c b/arch/arm/mach-at91/board-sam9m10g45ek.c
> index 2a94896..ef39078 100644
> --- a/arch/arm/mach-at91/board-sam9m10g45ek.c
> +++ b/arch/arm/mach-at91/board-sam9m10g45ek.c
> @@ -284,7 +284,7 @@ static struct fb_monspecs at91fb_default_monspecs = {
>  					| ATMEL_LCDC_CLKMOD_ALWAYSACTIVE)
>  
>  /* Driver datas */
> -static struct atmel_lcdfb_info __initdata ek_lcdc_data = {
> +static struct atmel_lcdfb_pdata __initdata ek_lcdc_data = {
>  	.lcdcon_is_backlight		= true,
>  	.default_bpp			= 32,
>  	.default_dmacon			= ATMEL_LCDC_DMAEN,
> @@ -295,7 +295,7 @@ static struct atmel_lcdfb_info __initdata ek_lcdc_data = {
>  };
>  
>  #else
> -static struct atmel_lcdfb_info __initdata ek_lcdc_data;
> +static struct atmel_lcdfb_pdata __initdata ek_lcdc_data;
>  #endif
>  
>  
> diff --git a/arch/arm/mach-at91/board-sam9rlek.c b/arch/arm/mach-at91/board-sam9rlek.c
> index aa265dc..b77d7a9 100644
> --- a/arch/arm/mach-at91/board-sam9rlek.c
> +++ b/arch/arm/mach-at91/board-sam9rlek.c
> @@ -179,7 +179,7 @@ static void at91_lcdc_power_control(int on)
>  }
>  
>  /* Driver datas */
> -static struct atmel_lcdfb_info __initdata ek_lcdc_data = {
> +static struct atmel_lcdfb_pdata __initdata ek_lcdc_data = {
>  	.lcdcon_is_backlight            = true,
>  	.default_bpp			= 16,
>  	.default_dmacon			= ATMEL_LCDC_DMAEN,
> @@ -191,7 +191,7 @@ static struct atmel_lcdfb_info __initdata ek_lcdc_data = {
>  };
>  
>  #else
> -static struct atmel_lcdfb_info __initdata ek_lcdc_data;
> +static struct atmel_lcdfb_pdata __initdata ek_lcdc_data;
>  #endif
>  
>  
> diff --git a/arch/arm/mach-at91/board.h b/arch/arm/mach-at91/board.h
> index 4a234fb..6c08b34 100644
> --- a/arch/arm/mach-at91/board.h
> +++ b/arch/arm/mach-at91/board.h
> @@ -107,8 +107,8 @@ extern void __init at91_add_device_pwm(u32 mask);
>  extern void __init at91_add_device_ssc(unsigned id, unsigned pins);
>  
>   /* LCD Controller */
> -struct atmel_lcdfb_info;
> -extern void __init at91_add_device_lcdc(struct atmel_lcdfb_info *data);
> +struct atmel_lcdfb_pdata;
> +extern void __init at91_add_device_lcdc(struct atmel_lcdfb_pdata *data);
>  
>   /* AC97 */
>  extern void __init at91_add_device_ac97(struct ac97c_platform_data *data);
> diff --git a/arch/avr32/boards/atngw100/evklcd10x.c b/arch/avr32/boards/atngw100/evklcd10x.c
> index 2038875..dc42804 100644
> --- a/arch/avr32/boards/atngw100/evklcd10x.c
> +++ b/arch/avr32/boards/atngw100/evklcd10x.c
> @@ -58,7 +58,7 @@ static struct fb_monspecs __initdata atevklcd10x_default_monspecs = {
>  	.dclkmax		= 28330000,
>  };
>  
> -static struct atmel_lcdfb_info __initdata atevklcd10x_lcdc_data = {
> +static struct atmel_lcdfb_pdata __initdata atevklcd10x_lcdc_data = {
>  	.default_bpp		= 16,
>  	.default_dmacon		= ATMEL_LCDC_DMAEN | ATMEL_LCDC_DMA2DEN,
>  	.default_lcdcon2	= (ATMEL_LCDC_DISTYPE_TFT
> @@ -96,7 +96,7 @@ static struct fb_monspecs __initdata atevklcd10x_default_monspecs = {
>  	.dclkmax		= 7000000,
>  };
>  
> -static struct atmel_lcdfb_info __initdata atevklcd10x_lcdc_data = {
> +static struct atmel_lcdfb_pdata __initdata atevklcd10x_lcdc_data = {
>  	.default_bpp		= 16,
>  	.default_dmacon		= ATMEL_LCDC_DMAEN | ATMEL_LCDC_DMA2DEN,
>  	.default_lcdcon2	= (ATMEL_LCDC_DISTYPE_TFT
> @@ -134,7 +134,7 @@ static struct fb_monspecs __initdata atevklcd10x_default_monspecs = {
>  	.dclkmax		= 6400000,
>  };
>  
> -static struct atmel_lcdfb_info __initdata atevklcd10x_lcdc_data = {
> +static struct atmel_lcdfb_pdata __initdata atevklcd10x_lcdc_data = {
>  	.default_bpp		= 16,
>  	.default_dmacon		= ATMEL_LCDC_DMAEN | ATMEL_LCDC_DMA2DEN,
>  	.default_lcdcon2	= (ATMEL_LCDC_DISTYPE_TFT
> diff --git a/arch/avr32/boards/atngw100/mrmt.c b/arch/avr32/boards/atngw100/mrmt.c
> index f914319..ccc9599 100644
> --- a/arch/avr32/boards/atngw100/mrmt.c
> +++ b/arch/avr32/boards/atngw100/mrmt.c
> @@ -83,7 +83,7 @@ static struct fb_monspecs __initdata lcd_fb_default_monspecs = {
>  	.dclkmax		= 9260000,
>  };
>  
> -static struct atmel_lcdfb_info __initdata rmt_lcdc_data = {
> +static struct atmel_lcdfb_pdata __initdata rmt_lcdc_data = {
>  	.default_bpp		= 24,
>  	.default_dmacon		= ATMEL_LCDC_DMAEN | ATMEL_LCDC_DMA2DEN,
>  	.default_lcdcon2	= (ATMEL_LCDC_DISTYPE_TFT
> @@ -126,7 +126,7 @@ static struct fb_monspecs __initdata lcd_fb_default_monspecs = {
>  	.dclkmax		= 9260000,
>  };
>  
> -static struct atmel_lcdfb_info __initdata rmt_lcdc_data = {
> +static struct atmel_lcdfb_pdata __initdata rmt_lcdc_data = {
>  	.default_bpp		= 24,
>  	.default_dmacon		= ATMEL_LCDC_DMAEN | ATMEL_LCDC_DMA2DEN,
>  	.default_lcdcon2	= (ATMEL_LCDC_DISTYPE_TFT
> diff --git a/arch/avr32/boards/atstk1000/atstk1000.h b/arch/avr32/boards/atstk1000/atstk1000.h
> index 9392d32..653cc09 100644
> --- a/arch/avr32/boards/atstk1000/atstk1000.h
> +++ b/arch/avr32/boards/atstk1000/atstk1000.h
> @@ -10,7 +10,7 @@
>  #ifndef __ARCH_AVR32_BOARDS_ATSTK1000_ATSTK1000_H
>  #define __ARCH_AVR32_BOARDS_ATSTK1000_ATSTK1000_H
>  
> -extern struct atmel_lcdfb_info atstk1000_lcdc_data;
> +extern struct atmel_lcdfb_pdata atstk1000_lcdc_data;
>  
>  void atstk1000_setup_j2_leds(void);
>  
> diff --git a/arch/avr32/boards/atstk1000/setup.c b/arch/avr32/boards/atstk1000/setup.c
> index 2d6b560..b6b88f5 100644
> --- a/arch/avr32/boards/atstk1000/setup.c
> +++ b/arch/avr32/boards/atstk1000/setup.c
> @@ -55,7 +55,7 @@ static struct fb_monspecs __initdata atstk1000_default_monspecs = {
>  	.dclkmax		= 30000000,
>  };
>  
> -struct atmel_lcdfb_info __initdata atstk1000_lcdc_data = {
> +struct atmel_lcdfb_pdata __initdata atstk1000_lcdc_data = {
>  	.default_bpp		= 24,
>  	.default_dmacon		= ATMEL_LCDC_DMAEN | ATMEL_LCDC_DMA2DEN,
>  	.default_lcdcon2	= (ATMEL_LCDC_DISTYPE_TFT
> diff --git a/arch/avr32/boards/favr-32/setup.c b/arch/avr32/boards/favr-32/setup.c
> index 27bd6fb..7b1f2cd 100644
> --- a/arch/avr32/boards/favr-32/setup.c
> +++ b/arch/avr32/boards/favr-32/setup.c
> @@ -125,7 +125,7 @@ static struct fb_monspecs __initdata favr32_default_monspecs = {
>  	.dclkmax		= 28000000,
>  };
>  
> -struct atmel_lcdfb_info __initdata favr32_lcdc_data = {
> +struct atmel_lcdfb_pdata __initdata favr32_lcdc_data = {
>  	.default_bpp		= 16,
>  	.default_dmacon		= ATMEL_LCDC_DMAEN | ATMEL_LCDC_DMA2DEN,
>  	.default_lcdcon2	= (ATMEL_LCDC_DISTYPE_TFT
> diff --git a/arch/avr32/boards/hammerhead/setup.c b/arch/avr32/boards/hammerhead/setup.c
> index 9d1efd1..dc0e317 100644
> --- a/arch/avr32/boards/hammerhead/setup.c
> +++ b/arch/avr32/boards/hammerhead/setup.c
> @@ -77,7 +77,7 @@ static struct fb_monspecs __initdata hammerhead_hda350t_monspecs = {
>  	.dclkmax		= 10000000,
>  };
>  
> -struct atmel_lcdfb_info __initdata hammerhead_lcdc_data = {
> +struct atmel_lcdfb_pdata __initdata hammerhead_lcdc_data = {
>  	.default_bpp		= 24,
>  	.default_dmacon		= ATMEL_LCDC_DMAEN | ATMEL_LCDC_DMA2DEN,
>  	.default_lcdcon2	= (ATMEL_LCDC_DISTYPE_TFT
> diff --git a/arch/avr32/boards/merisc/display.c b/arch/avr32/boards/merisc/display.c
> index 85a543c..e7683ee 100644
> --- a/arch/avr32/boards/merisc/display.c
> +++ b/arch/avr32/boards/merisc/display.c
> @@ -45,7 +45,7 @@ static struct fb_monspecs merisc_fb_monspecs = {
>  	.dclkmax	= 30000000,
>  };
>  
> -struct atmel_lcdfb_info merisc_lcdc_data = {
> +struct atmel_lcdfb_pdata merisc_lcdc_data = {
>  	.default_bpp		= 24,
>  	.default_dmacon		= ATMEL_LCDC_DMAEN | ATMEL_LCDC_DMA2DEN,
>  	.default_lcdcon2	= (ATMEL_LCDC_DISTYPE_TFT
> diff --git a/arch/avr32/boards/mimc200/setup.c b/arch/avr32/boards/mimc200/setup.c
> index 05358aa..1cb8e9c 100644
> --- a/arch/avr32/boards/mimc200/setup.c
> +++ b/arch/avr32/boards/mimc200/setup.c
> @@ -8,7 +8,7 @@
>   * published by the Free Software Foundation.
>   */
>  
> -extern struct atmel_lcdfb_info mimc200_lcdc_data;
> +extern struct atmel_lcdfb_pdata mimc200_lcdc_data;
>  
>  #include <linux/clk.h>
>  #include <linux/etherdevice.h>
> @@ -71,7 +71,7 @@ static struct fb_monspecs __initdata mimc200_default_monspecs = {
>  	.dclkmax		= 25200000,
>  };
>  
> -struct atmel_lcdfb_info __initdata mimc200_lcdc_data = {
> +struct atmel_lcdfb_pdata __initdata mimc200_lcdc_data = {
>  	.default_bpp		= 16,
>  	.default_dmacon		= ATMEL_LCDC_DMAEN | ATMEL_LCDC_DMA2DEN,
>  	.default_lcdcon2	= (ATMEL_LCDC_DISTYPE_TFT
> diff --git a/arch/avr32/mach-at32ap/at32ap700x.c b/arch/avr32/mach-at32ap/at32ap700x.c
> index 7c2f668..0badb05 100644
> --- a/arch/avr32/mach-at32ap/at32ap700x.c
> +++ b/arch/avr32/mach-at32ap/at32ap700x.c
> @@ -1437,7 +1437,7 @@ fail:
>   *  LCDC
>   * -------------------------------------------------------------------- */
>  #if defined(CONFIG_CPU_AT32AP7000) || defined(CONFIG_CPU_AT32AP7002)
> -static struct atmel_lcdfb_info atmel_lcdfb0_data;
> +static struct atmel_lcdfb_pdata atmel_lcdfb0_data;
>  static struct resource atmel_lcdfb0_resource[] = {
>  	{
>  		.start		= 0xff000000,
> @@ -1465,12 +1465,12 @@ static struct clk atmel_lcdfb0_pixclk = {
>  };
>  
>  struct platform_device *__init
> -at32_add_device_lcdc(unsigned int id, struct atmel_lcdfb_info *data,
> +at32_add_device_lcdc(unsigned int id, struct atmel_lcdfb_pdata *data,
>  		     unsigned long fbmem_start, unsigned long fbmem_len,
>  		     u64 pin_mask)
>  {
>  	struct platform_device *pdev;
> -	struct atmel_lcdfb_info *info;
> +	struct atmel_lcdfb_pdata *info;
>  	struct fb_monspecs *monspecs;
>  	struct fb_videomode *modedb;
>  	unsigned int modedb_size;
> @@ -1527,7 +1527,7 @@ at32_add_device_lcdc(unsigned int id, struct atmel_lcdfb_info *data,
>  	}
>  
>  	info = pdev->dev.platform_data;
> -	memcpy(info, data, sizeof(struct atmel_lcdfb_info));
> +	memcpy(info, data, sizeof(struct atmel_lcdfb_pdata));
>  	info->default_monspecs = monspecs;
>  
>  	pdev->name = "at32ap-lcdfb";
> diff --git a/arch/avr32/mach-at32ap/include/mach/board.h b/arch/avr32/mach-at32ap/include/mach/board.h
> index d485b03..f1a316d 100644
> --- a/arch/avr32/mach-at32ap/include/mach/board.h
> +++ b/arch/avr32/mach-at32ap/include/mach/board.h
> @@ -44,9 +44,9 @@ struct platform_device *
>  at32_add_device_spi(unsigned int id, struct spi_board_info *b, unsigned int n);
>  void at32_spi_setup_slaves(unsigned int bus_num, struct spi_board_info *b, unsigned int n);
>  
> -struct atmel_lcdfb_info;
> +struct atmel_lcdfb_pdata;
>  struct platform_device *
> -at32_add_device_lcdc(unsigned int id, struct atmel_lcdfb_info *data,
> +at32_add_device_lcdc(unsigned int id, struct atmel_lcdfb_pdata *data,
>  		     unsigned long fbmem_start, unsigned long fbmem_len,
>  		     u64 pin_mask);
>  
> diff --git a/drivers/video/atmel_lcdfb.c b/drivers/video/atmel_lcdfb.c
> index c1a2914..98733cd4 100644
> --- a/drivers/video/atmel_lcdfb.c
> +++ b/drivers/video/atmel_lcdfb.c
> @@ -20,12 +20,45 @@
>  #include <linux/gfp.h>
>  #include <linux/module.h>
>  #include <linux/platform_data/atmel.h>
> +#include <video/of_display_timing.h>

I am not sure this one is useful for this patch, maybe place it in the
4/8 one.


>  #include <mach/cpu.h>
>  #include <asm/gpio.h>
>  
>  #include <video/atmel_lcdc.h>
>  
> +struct atmel_lcdfb_config {
> +	bool have_alt_pixclock;
> +	bool have_hozval;
> +	bool have_intensity_bit;
> +};
> +
> + /* LCD Controller info data structure, stored in device platform_data */

Is comment still relevant?

> +struct atmel_lcdfb_info {
> +	spinlock_t		lock;
> +	struct fb_info		*info;
> +	void __iomem		*mmio;
> +	int			irq_base;
> +	struct work_struct	task;
> +
> +	unsigned int		smem_len;
> +	struct platform_device	*pdev;
> +	struct clk		*bus_clk;
> +	struct clk		*lcdc_clk;
> +
> +	struct backlight_device	*backlight;
> +	u8			bl_power;
> +	bool			lcdcon_pol_negative;
> +	u8			saved_lcdcon;
> +
> +	u32			pseudo_palette[16];
> +	bool			have_intensity_bit;
> +
> +	struct atmel_lcdfb_pdata pdata;
> +
> +	struct atmel_lcdfb_config *config;
> +};
> +
>  #define lcdc_readl(sinfo, reg)		__raw_readl((sinfo)->mmio+(reg))
>  #define lcdc_writel(sinfo, reg, val)	__raw_writel((val), (sinfo)->mmio+(reg))
>  
> @@ -34,12 +67,6 @@
>  #define ATMEL_LCDC_DMA_BURST_LEN	8	/* words */
>  #define ATMEL_LCDC_FIFO_SIZE		512	/* words */
>  
> -struct atmel_lcdfb_config {
> -	bool have_alt_pixclock;
> -	bool have_hozval;
> -	bool have_intensity_bit;
> -};
> -
>  static struct atmel_lcdfb_config at91sam9261_config = {
>  	.have_hozval		= true,
>  	.have_intensity_bit	= true,
> @@ -242,6 +269,8 @@ static void exit_backlight(struct atmel_lcdfb_info *sinfo)
>  
>  static void init_contrast(struct atmel_lcdfb_info *sinfo)
>  {
> +	struct atmel_lcdfb_pdata *pdata = &sinfo->pdata;
> +
>  	/* contrast pwm can be 'inverted' */
>  	if (sinfo->lcdcon_pol_negative)
>  			contrast_ctr &= ~(ATMEL_LCDC_POL_POSITIVE);
> @@ -250,7 +279,7 @@ static void init_contrast(struct atmel_lcdfb_info *sinfo)
>  	lcdc_writel(sinfo, ATMEL_LCDC_CONTRAST_CTR, contrast_ctr);
>  	lcdc_writel(sinfo, ATMEL_LCDC_CONTRAST_VAL, ATMEL_LCDC_CVAL_DEFAULT);
>  
> -	if (sinfo->lcdcon_is_backlight)
> +	if (pdata->lcdcon_is_backlight)
>  		init_backlight(sinfo);
>  }
>  
> @@ -293,9 +322,11 @@ static unsigned long compute_hozval(struct atmel_lcdfb_info *sinfo,
>  
>  static void atmel_lcdfb_stop_nowait(struct atmel_lcdfb_info *sinfo)
>  {
> +	struct atmel_lcdfb_pdata *pdata = &sinfo->pdata;
> +
>  	/* Turn off the LCD controller and the DMA controller */
>  	lcdc_writel(sinfo, ATMEL_LCDC_PWRCON,
> -			sinfo->guard_time << ATMEL_LCDC_GUARDT_OFFSET);
> +			pdata->guard_time << ATMEL_LCDC_GUARDT_OFFSET);
>  
>  	/* Wait for the LCDC core to become idle */
>  	while (lcdc_readl(sinfo, ATMEL_LCDC_PWRCON) & ATMEL_LCDC_BUSY)
> @@ -315,9 +346,11 @@ static void atmel_lcdfb_stop(struct atmel_lcdfb_info *sinfo)
>  
>  static void atmel_lcdfb_start(struct atmel_lcdfb_info *sinfo)
>  {
> -	lcdc_writel(sinfo, ATMEL_LCDC_DMACON, sinfo->default_dmacon);
> +	struct atmel_lcdfb_pdata *pdata = &sinfo->pdata;
> +
> +	lcdc_writel(sinfo, ATMEL_LCDC_DMACON, pdata->default_dmacon);
>  	lcdc_writel(sinfo, ATMEL_LCDC_PWRCON,
> -		(sinfo->guard_time << ATMEL_LCDC_GUARDT_OFFSET)
> +		(pdata->guard_time << ATMEL_LCDC_GUARDT_OFFSET)
>  		| ATMEL_LCDC_PWR);
>  }
>  
> @@ -418,6 +451,7 @@ static int atmel_lcdfb_check_var(struct fb_var_screeninfo *var,
>  {
>  	struct device *dev = info->device;
>  	struct atmel_lcdfb_info *sinfo = info->par;
> +	struct atmel_lcdfb_pdata *pdata = &sinfo->pdata;
>  	unsigned long clk_value_khz;
>  
>  	clk_value_khz = clk_get_rate(sinfo->lcdc_clk) / 1000;
> @@ -501,7 +535,7 @@ static int atmel_lcdfb_check_var(struct fb_var_screeninfo *var,
>  		else
>  			var->green.length = 6;
>  
> -		if (sinfo->lcd_wiring_mode == ATMEL_LCDC_WIRING_RGB) {
> +		if (pdata->lcd_wiring_mode == ATMEL_LCDC_WIRING_RGB) {
>  			/* RGB:5X5 mode */
>  			var->red.offset = var->green.length + 5;
>  			var->blue.offset = 0;
> @@ -518,7 +552,7 @@ static int atmel_lcdfb_check_var(struct fb_var_screeninfo *var,
>  		var->transp.length = 8;
>  		/* fall through */
>  	case 24:
> -		if (sinfo->lcd_wiring_mode == ATMEL_LCDC_WIRING_RGB) {
> +		if (pdata->lcd_wiring_mode == ATMEL_LCDC_WIRING_RGB) {
>  			/* RGB:888 mode */
>  			var->red.offset = 16;
>  			var->blue.offset = 0;
> @@ -567,6 +601,7 @@ static void atmel_lcdfb_reset(struct atmel_lcdfb_info *sinfo)
>  static int atmel_lcdfb_set_par(struct fb_info *info)
>  {
>  	struct atmel_lcdfb_info *sinfo = info->par;
> +	struct atmel_lcdfb_pdata *pdata = &sinfo->pdata;
>  	unsigned long hozval_linesz;
>  	unsigned long value;
>  	unsigned long clk_value_khz;
> @@ -628,7 +663,7 @@ static int atmel_lcdfb_set_par(struct fb_info *info)
>  
>  
>  	/* Initialize control register 2 */
> -	value = sinfo->default_lcdcon2;
> +	value = pdata->default_lcdcon2;
>  
>  	if (!(info->var.sync & FB_SYNC_HOR_HIGH_ACT))
>  		value |= ATMEL_LCDC_INVLINE_INVERTED;
> @@ -732,6 +767,7 @@ static int atmel_lcdfb_setcolreg(unsigned int regno, unsigned int red,
>  			     unsigned int transp, struct fb_info *info)
>  {
>  	struct atmel_lcdfb_info *sinfo = info->par;
> +	struct atmel_lcdfb_pdata *pdata = &sinfo->pdata;
>  	unsigned int val;
>  	u32 *pal;
>  	int ret = 1;
> @@ -768,8 +804,7 @@ static int atmel_lcdfb_setcolreg(unsigned int regno, unsigned int red,
>  				 */
>  			} else {
>  				/* new style BGR:565 / RGB:565 */
> -				if (sinfo->lcd_wiring_mode ==
> -				    ATMEL_LCDC_WIRING_RGB) {
> +				if (pdata->lcd_wiring_mode == ATMEL_LCDC_WIRING_RGB) {
>  					val  = ((blue >> 11) & 0x001f);
>  					val |= ((red  >>  0) & 0xf800);
>  				} else {
> @@ -909,7 +944,7 @@ static int __init atmel_lcdfb_probe(struct platform_device *pdev)
>  	struct device *dev = &pdev->dev;
>  	struct fb_info *info;
>  	struct atmel_lcdfb_info *sinfo;
> -	struct atmel_lcdfb_info *pdata_sinfo;
> +	struct atmel_lcdfb_pdata *pdata;
>  	struct fb_videomode fbmode;
>  	struct resource *regs = NULL;
>  	struct resource *map = NULL;
> @@ -927,17 +962,8 @@ static int __init atmel_lcdfb_probe(struct platform_device *pdev)
>  	sinfo = info->par;
>  
>  	if (dev->platform_data) {
> -		pdata_sinfo = (struct atmel_lcdfb_info *)dev->platform_data;
> -		sinfo->default_bpp = pdata_sinfo->default_bpp;
> -		sinfo->default_dmacon = pdata_sinfo->default_dmacon;
> -		sinfo->default_lcdcon2 = pdata_sinfo->default_lcdcon2;
> -		sinfo->default_monspecs = pdata_sinfo->default_monspecs;
> -		sinfo->atmel_lcdfb_power_control = pdata_sinfo->atmel_lcdfb_power_control;
> -		sinfo->guard_time = pdata_sinfo->guard_time;
> -		sinfo->smem_len = pdata_sinfo->smem_len;
> -		sinfo->lcdcon_is_backlight = pdata_sinfo->lcdcon_is_backlight;
> -		sinfo->lcdcon_pol_negative = pdata_sinfo->lcdcon_pol_negative;
> -		sinfo->lcd_wiring_mode = pdata_sinfo->lcd_wiring_mode;
> +		pdata = (struct atmel_lcdfb_pdata *)dev->platform_data;
> +		sinfo->pdata = *pdata;
>  	} else {
>  		dev_err(dev, "cannot get default configuration\n");
>  		goto free_info;
> @@ -953,7 +979,7 @@ static int __init atmel_lcdfb_probe(struct platform_device *pdev)
>  	info->pseudo_palette = sinfo->pseudo_palette;
>  	info->fbops = &atmel_lcdfb_ops;
>  
> -	memcpy(&info->monspecs, sinfo->default_monspecs, sizeof(info->monspecs));
> +	memcpy(&info->monspecs, pdata->default_monspecs, sizeof(info->monspecs));
>  	info->fix = atmel_lcdfb_fix;
>  
>  	/* Enable LCDC Clocks */
> @@ -971,7 +997,7 @@ static int __init atmel_lcdfb_probe(struct platform_device *pdev)
>  
>  	ret = fb_find_mode(&info->var, info, NULL, info->monspecs.modedb,
>  			info->monspecs.modedb_len, info->monspecs.modedb,
> -			sinfo->default_bpp);
> +			pdata->default_bpp);
>  	if (!ret) {
>  		dev_err(dev, "no suitable video mode found\n");
>  		goto stop_clk;
> @@ -1088,8 +1114,8 @@ static int __init atmel_lcdfb_probe(struct platform_device *pdev)
>  	fb_add_videomode(&fbmode, &info->modelist);
>  
>  	/* Power up the LCDC screen */
> -	if (sinfo->atmel_lcdfb_power_control)
> -		sinfo->atmel_lcdfb_power_control(1);
> +	if (pdata->atmel_lcdfb_power_control)
> +		pdata->atmel_lcdfb_power_control(1);
>  
>  	dev_info(dev, "fb%d: Atmel LCDC at 0x%08lx (mapped at %p), irq %d\n",
>  		       info->node, info->fix.mmio_start, sinfo->mmio, sinfo->irq_base);
> @@ -1134,15 +1160,17 @@ static int __exit atmel_lcdfb_remove(struct platform_device *pdev)
>  	struct device *dev = &pdev->dev;
>  	struct fb_info *info = dev_get_drvdata(dev);
>  	struct atmel_lcdfb_info *sinfo;
> +	struct atmel_lcdfb_pdata *pdata;
>  
>  	if (!info || !info->par)
>  		return 0;
>  	sinfo = info->par;
> +	pdata = &sinfo->pdata;
>  
>  	cancel_work_sync(&sinfo->task);
>  	exit_backlight(sinfo);
> -	if (sinfo->atmel_lcdfb_power_control)
> -		sinfo->atmel_lcdfb_power_control(0);
> +	if (pdata->atmel_lcdfb_power_control)
> +		pdata->atmel_lcdfb_power_control(0);
>  	unregister_framebuffer(info);
>  	atmel_lcdfb_stop_clock(sinfo);
>  	clk_put(sinfo->lcdc_clk);
> @@ -1170,6 +1198,7 @@ static int atmel_lcdfb_suspend(struct platform_device *pdev, pm_message_t mesg)
>  {
>  	struct fb_info *info = platform_get_drvdata(pdev);
>  	struct atmel_lcdfb_info *sinfo = info->par;
> +	struct atmel_lcdfb_pdata *pdata = &sinfo->pdata;
>  
>  	/*
>  	 * We don't want to handle interrupts while the clock is
> @@ -1179,8 +1208,8 @@ static int atmel_lcdfb_suspend(struct platform_device *pdev, pm_message_t mesg)
>  
>  	sinfo->saved_lcdcon = lcdc_readl(sinfo, ATMEL_LCDC_CONTRAST_CTR);
>  	lcdc_writel(sinfo, ATMEL_LCDC_CONTRAST_CTR, 0);
> -	if (sinfo->atmel_lcdfb_power_control)
> -		sinfo->atmel_lcdfb_power_control(0);
> +	if (pdata->atmel_lcdfb_power_control)
> +		pdata->atmel_lcdfb_power_control(0);
>  
>  	atmel_lcdfb_stop(sinfo);
>  	atmel_lcdfb_stop_clock(sinfo);
> @@ -1192,11 +1221,12 @@ static int atmel_lcdfb_resume(struct platform_device *pdev)
>  {
>  	struct fb_info *info = platform_get_drvdata(pdev);
>  	struct atmel_lcdfb_info *sinfo = info->par;
> +	struct atmel_lcdfb_pdata *pdata = &sinfo->pdata;
>  
>  	atmel_lcdfb_start_clock(sinfo);
>  	atmel_lcdfb_start(sinfo);
> -	if (sinfo->atmel_lcdfb_power_control)
> -		sinfo->atmel_lcdfb_power_control(1);
> +	if (pdata->atmel_lcdfb_power_control)
> +		pdata->atmel_lcdfb_power_control(1);
>  	lcdc_writel(sinfo, ATMEL_LCDC_CONTRAST_CTR, sinfo->saved_lcdcon);
>  
>  	/* Enable FIFO & DMA errors */
> diff --git a/include/video/atmel_lcdc.h b/include/video/atmel_lcdc.h
> index 0f5a2fc..2eb601c 100644
> --- a/include/video/atmel_lcdc.h
> +++ b/include/video/atmel_lcdc.h
> @@ -31,39 +31,17 @@
>  #define ATMEL_LCDC_WIRING_BGR	0
>  #define ATMEL_LCDC_WIRING_RGB	1
>  
> -struct atmel_lcdfb_config;
>  
>   /* LCD Controller info data structure, stored in device platform_data */

Wrong comment: it is not the "info" data structure, this time.

> -struct atmel_lcdfb_info {
> -	spinlock_t		lock;
> -	struct fb_info		*info;
> -	void __iomem		*mmio;
> -	int			irq_base;
> -	struct work_struct	task;
> -
> +struct atmel_lcdfb_pdata {
>  	unsigned int		guard_time;
> -	unsigned int 		smem_len;
> -	struct platform_device	*pdev;
> -	struct clk		*bus_clk;
> -	struct clk		*lcdc_clk;
> -
> -#ifdef CONFIG_BACKLIGHT_ATMEL_LCDC
> -	struct backlight_device	*backlight;
> -	u8			bl_power;
> -#endif
>  	bool			lcdcon_is_backlight;
> -	bool			lcdcon_pol_negative;
> -	u8			saved_lcdcon;
> -
>  	u8			default_bpp;
>  	u8			lcd_wiring_mode;
>  	unsigned int		default_lcdcon2;
>  	unsigned int		default_dmacon;
>  	void (*atmel_lcdfb_power_control)(int on);
>  	struct fb_monspecs	*default_monspecs;
> -	u32			pseudo_palette[16];
> -
> -	struct atmel_lcdfb_config *config;
>  };
>  
>  #define ATMEL_LCDC_DMABADDR1	0x00
> 


-- 
Nicolas Ferre


From linus.walleij at linaro.org  Tue Apr 16 08:34:39 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Tue, 16 Apr 2013 14:34:39 +0200
Subject: [V3 patch 05/19] ARM: ux500: cpuidle: replace for_each_online_cpu
 by for_each_possible_cpu
In-Reply-To: <1365770165-27096-6-git-send-email-daniel.lezcano@linaro.org>
References: <1365770165-27096-1-git-send-email-daniel.lezcano@linaro.org>
 <1365770165-27096-6-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <CACRpkdasndAyCitHkB3z3vH06WOD7qtzzjD9cXmAkvUEO_x3OA@mail.gmail.com>

On Fri, Apr 12, 2013 at 2:35 PM, Daniel Lezcano
<daniel.lezcano at linaro.org> wrote:

> All the drivers are using, in their initialization function, the
> for_each_possible_cpu macro.
>
> Using for_each_online_cpu means the driver must handle the initialization
> of the cpuidle device when a cpu is up which is not the case here.
>
> Change the macro to for_each_possible_cpu as that fix the hotplug
> initialization and make the initialization routine consistent with the
> rest of the code in the different drivers.
>
> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>

Acked-by: Linus Walleij <linus.walleij at linaro.org>

Yours,
Linus Walleij


From nicolas.ferre at atmel.com  Tue Apr 16 08:35:24 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Tue, 16 Apr 2013 14:35:24 +0200
Subject: [PATCH 2/8] video: atmel_lcdfb: introduce
 atmel_lcdfb_power_control
In-Reply-To: <1365692422-9565-2-git-send-email-plagnioj@jcrosoft.com>
References: <20130411145741.GB25242@game.jcrosoft.org>
 <1365692422-9565-1-git-send-email-plagnioj@jcrosoft.com>
 <1365692422-9565-2-git-send-email-plagnioj@jcrosoft.com>
Message-ID: <516D458C.8050205@atmel.com>

On 04/11/2013 05:00 PM, Jean-Christophe PLAGNIOL-VILLARD :
> to simplify the check on the presence of the callback
> 
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
> Cc: linux-fbdev at vger.kernel.org
> Cc: Nicolas Ferre <nicolas.ferre at atmel.com>

Simple and nice

Acked-by: Nicolas Ferre <nicolas.ferre at atmel.com>


> Cc: Andrew Morton <akpm at linux-foundation.org>
> ---
>  drivers/video/atmel_lcdfb.c |   22 +++++++++++-----------
>  1 file changed, 11 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/video/atmel_lcdfb.c b/drivers/video/atmel_lcdfb.c
> index 98733cd4..9574c47 100644
> --- a/drivers/video/atmel_lcdfb.c
> +++ b/drivers/video/atmel_lcdfb.c
> @@ -283,6 +283,13 @@ static void init_contrast(struct atmel_lcdfb_info *sinfo)
>  		init_backlight(sinfo);
>  }
>  
> +static inline void atmel_lcdfb_power_control(struct atmel_lcdfb_info *sinfo, int on)
> +{
> +	struct atmel_lcdfb_pdata *pdata = &sinfo->pdata;
> +
> +	if (pdata->atmel_lcdfb_power_control)
> +		pdata->atmel_lcdfb_power_control(on);
> +}
>  
>  static struct fb_fix_screeninfo atmel_lcdfb_fix __initdata = {
>  	.type		= FB_TYPE_PACKED_PIXELS,
> @@ -1114,8 +1121,7 @@ static int __init atmel_lcdfb_probe(struct platform_device *pdev)
>  	fb_add_videomode(&fbmode, &info->modelist);
>  
>  	/* Power up the LCDC screen */
> -	if (pdata->atmel_lcdfb_power_control)
> -		pdata->atmel_lcdfb_power_control(1);
> +	atmel_lcdfb_power_control(sinfo, 1);
>  
>  	dev_info(dev, "fb%d: Atmel LCDC at 0x%08lx (mapped at %p), irq %d\n",
>  		       info->node, info->fix.mmio_start, sinfo->mmio, sinfo->irq_base);
> @@ -1169,8 +1175,7 @@ static int __exit atmel_lcdfb_remove(struct platform_device *pdev)
>  
>  	cancel_work_sync(&sinfo->task);
>  	exit_backlight(sinfo);
> -	if (pdata->atmel_lcdfb_power_control)
> -		pdata->atmel_lcdfb_power_control(0);
> +	atmel_lcdfb_power_control(sinfo, 0);
>  	unregister_framebuffer(info);
>  	atmel_lcdfb_stop_clock(sinfo);
>  	clk_put(sinfo->lcdc_clk);
> @@ -1198,7 +1203,6 @@ static int atmel_lcdfb_suspend(struct platform_device *pdev, pm_message_t mesg)
>  {
>  	struct fb_info *info = platform_get_drvdata(pdev);
>  	struct atmel_lcdfb_info *sinfo = info->par;
> -	struct atmel_lcdfb_pdata *pdata = &sinfo->pdata;
>  
>  	/*
>  	 * We don't want to handle interrupts while the clock is
> @@ -1208,9 +1212,7 @@ static int atmel_lcdfb_suspend(struct platform_device *pdev, pm_message_t mesg)
>  
>  	sinfo->saved_lcdcon = lcdc_readl(sinfo, ATMEL_LCDC_CONTRAST_CTR);
>  	lcdc_writel(sinfo, ATMEL_LCDC_CONTRAST_CTR, 0);
> -	if (pdata->atmel_lcdfb_power_control)
> -		pdata->atmel_lcdfb_power_control(0);
> -
> +	atmel_lcdfb_power_control(sinfo, 0);
>  	atmel_lcdfb_stop(sinfo);
>  	atmel_lcdfb_stop_clock(sinfo);
>  
> @@ -1221,12 +1223,10 @@ static int atmel_lcdfb_resume(struct platform_device *pdev)
>  {
>  	struct fb_info *info = platform_get_drvdata(pdev);
>  	struct atmel_lcdfb_info *sinfo = info->par;
> -	struct atmel_lcdfb_pdata *pdata = &sinfo->pdata;
>  
>  	atmel_lcdfb_start_clock(sinfo);
>  	atmel_lcdfb_start(sinfo);
> -	if (pdata->atmel_lcdfb_power_control)
> -		pdata->atmel_lcdfb_power_control(1);
> +	atmel_lcdfb_power_control(sinfo, 1);
>  	lcdc_writel(sinfo, ATMEL_LCDC_CONTRAST_CTR, sinfo->saved_lcdcon);
>  
>  	/* Enable FIFO & DMA errors */
> 


-- 
Nicolas Ferre


From nicolas.ferre at atmel.com  Tue Apr 16 08:38:44 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Tue, 16 Apr 2013 14:38:44 +0200
Subject: [PATCH 3/8] video: atmel_lcdfb: pass the pdata as params
In-Reply-To: <1365692422-9565-3-git-send-email-plagnioj@jcrosoft.com>
References: <20130411145741.GB25242@game.jcrosoft.org>
 <1365692422-9565-1-git-send-email-plagnioj@jcrosoft.com>
 <1365692422-9565-3-git-send-email-plagnioj@jcrosoft.com>
Message-ID: <516D4654.3060109@atmel.com>

On 04/11/2013 05:00 PM, Jean-Christophe PLAGNIOL-VILLARD :
> so we can use have list gpio as example (probe via DT)

Please refine the commit message: I do not understand.

After reading the patch, it seems obvious that more explanations are
needed in the message.

> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
> Cc: linux-fbdev at vger.kernel.org
> Cc: Nicolas Ferre <nicolas.ferre at atmel.com>
> Cc: Andrew Morton <akpm at linux-foundation.org>
> ---
>  arch/arm/mach-at91/board-sam9261ek.c   |    4 ++--
>  arch/arm/mach-at91/board-sam9263ek.c   |    2 +-
>  arch/arm/mach-at91/board-sam9rlek.c    |    2 +-
>  arch/avr32/boards/atngw100/evklcd10x.c |    2 +-
>  drivers/video/atmel_lcdfb.c            |    2 +-
>  include/video/atmel_lcdc.h             |    4 +++-
>  6 files changed, 9 insertions(+), 7 deletions(-)
> 
> diff --git a/arch/arm/mach-at91/board-sam9261ek.c b/arch/arm/mach-at91/board-sam9261ek.c
> index c819e29..9a6618a 100644
> --- a/arch/arm/mach-at91/board-sam9261ek.c
> +++ b/arch/arm/mach-at91/board-sam9261ek.c
> @@ -393,7 +393,7 @@ static struct fb_monspecs at91fb_default_stn_monspecs = {
>  					| ATMEL_LCDC_IFWIDTH_4 \
>  					| ATMEL_LCDC_SCANMOD_SINGLE)
>  
> -static void at91_lcdc_stn_power_control(int on)
> +static void at91_lcdc_stn_power_control(struct atmel_lcdfb_pdata *pdata, int on)
>  {
>  	/* backlight */
>  	if (on) {	/* power up */
> @@ -452,7 +452,7 @@ static struct fb_monspecs at91fb_default_tft_monspecs = {
>  					| ATMEL_LCDC_DISTYPE_TFT    \
>  					| ATMEL_LCDC_CLKMOD_ALWAYSACTIVE)
>  
> -static void at91_lcdc_tft_power_control(int on)
> +static void at91_lcdc_tft_power_control(struct atmel_lcdfb_pdata *pdata, int on)
>  {
>  	if (on)
>  		at91_set_gpio_value(AT91_PIN_PA12, 0);	/* power up */
> diff --git a/arch/arm/mach-at91/board-sam9263ek.c b/arch/arm/mach-at91/board-sam9263ek.c
> index 0fdae3f..8b4942c 100644
> --- a/arch/arm/mach-at91/board-sam9263ek.c
> +++ b/arch/arm/mach-at91/board-sam9263ek.c
> @@ -275,7 +275,7 @@ static struct fb_monspecs at91fb_default_monspecs = {
>  					| ATMEL_LCDC_DISTYPE_TFT \
>  					| ATMEL_LCDC_CLKMOD_ALWAYSACTIVE)
>  
> -static void at91_lcdc_power_control(int on)
> +static void at91_lcdc_power_control(struct atmel_lcdfb_pdata *pdata, int on)
>  {
>  	at91_set_gpio_value(AT91_PIN_PA30, on);
>  }
> diff --git a/arch/arm/mach-at91/board-sam9rlek.c b/arch/arm/mach-at91/board-sam9rlek.c
> index b77d7a9..604eecf 100644
> --- a/arch/arm/mach-at91/board-sam9rlek.c
> +++ b/arch/arm/mach-at91/board-sam9rlek.c
> @@ -170,7 +170,7 @@ static struct fb_monspecs at91fb_default_monspecs = {
>  					| ATMEL_LCDC_DISTYPE_TFT \
>  					| ATMEL_LCDC_CLKMOD_ALWAYSACTIVE)
>  
> -static void at91_lcdc_power_control(int on)
> +static void at91_lcdc_power_control(struct atmel_lcdfb_pdata *pdata, int on)
>  {
>  	if (on)
>  		at91_set_gpio_value(AT91_PIN_PC1, 0);	/* power up */
> diff --git a/arch/avr32/boards/atngw100/evklcd10x.c b/arch/avr32/boards/atngw100/evklcd10x.c
> index dc42804..64919b0 100644
> --- a/arch/avr32/boards/atngw100/evklcd10x.c
> +++ b/arch/avr32/boards/atngw100/evklcd10x.c
> @@ -145,7 +145,7 @@ static struct atmel_lcdfb_pdata __initdata atevklcd10x_lcdc_data = {
>  };
>  #endif
>  
> -static void atevklcd10x_lcdc_power_control(int on)
> +static void atevklcd10x_lcdc_power_control(struct atmel_lcdfb_pdata *pdata, int on)
>  {
>  	gpio_set_value(GPIO_PIN_PB(15), on);
>  }
> diff --git a/drivers/video/atmel_lcdfb.c b/drivers/video/atmel_lcdfb.c
> index 9574c47..f67e226 100644
> --- a/drivers/video/atmel_lcdfb.c
> +++ b/drivers/video/atmel_lcdfb.c
> @@ -288,7 +288,7 @@ static inline void atmel_lcdfb_power_control(struct atmel_lcdfb_info *sinfo, int
>  	struct atmel_lcdfb_pdata *pdata = &sinfo->pdata;
>  
>  	if (pdata->atmel_lcdfb_power_control)
> -		pdata->atmel_lcdfb_power_control(on);
> +		pdata->atmel_lcdfb_power_control(pdata, on);
>  }
>  
>  static struct fb_fix_screeninfo atmel_lcdfb_fix __initdata = {
> diff --git a/include/video/atmel_lcdc.h b/include/video/atmel_lcdc.h
> index 2eb601c..f624c51 100644
> --- a/include/video/atmel_lcdc.h
> +++ b/include/video/atmel_lcdc.h
> @@ -40,8 +40,10 @@ struct atmel_lcdfb_pdata {
>  	u8			lcd_wiring_mode;
>  	unsigned int		default_lcdcon2;
>  	unsigned int		default_dmacon;
> -	void (*atmel_lcdfb_power_control)(int on);
> +	void (*atmel_lcdfb_power_control)(struct atmel_lcdfb_pdata *pdata, int on);
>  	struct fb_monspecs	*default_monspecs;
> +
> +	struct list_head	pwr_gpios;
>  };
>  
>  #define ATMEL_LCDC_DMABADDR1	0x00
> 


-- 
Nicolas Ferre


From robherring2 at gmail.com  Tue Apr 16 08:58:27 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Tue, 16 Apr 2013 07:58:27 -0500
Subject: [RFC PATCH 1/3] pstore-ram: use write-combine mappings
In-Reply-To: <20130416084418.GA30756@mudshark.cambridge.arm.com>
References: <1365563297-12480-1-git-send-email-robherring2@gmail.com>
 <CAMbhsRSvQPbzJ7Nt=OSSYE_A1e+eaUjO7XY+qRppJ5_gfWmW4A@mail.gmail.com>
 <51656992.60203@gmail.com>
 <CAMbhsRS1hnBRoomoiNijrXZB-938d2RSs1cu9EdSfmXD3xpSQg@mail.gmail.com>
 <516C9454.4060009@gmail.com>
 <CAMbhsRRT7tOBHppvjJEW5wRtVaUhwxr8=YQY=Sy0VAFeBg1JmQ@mail.gmail.com>
 <20130416084418.GA30756@mudshark.cambridge.arm.com>
Message-ID: <516D4AF3.5060205@gmail.com>

On 04/16/2013 03:44 AM, Will Deacon wrote:
> On Tue, Apr 16, 2013 at 01:43:09AM +0100, Colin Cross wrote:
>> On Mon, Apr 15, 2013 at 4:59 PM, Rob Herring <robherring2 at gmail.com> wrote:
>>> Exclusive accesses still have further restrictions. From section 3.4.5:
>>>
>>> ? It is IMPLEMENTATION DEFINED whether LDREX and STREX operations can be
>>> performed to a memory region
>>>    with the Device or Strongly-ordered memory attribute. Unless the
>>> implementation documentation explicitly
>>>   states that LDREX and STREX operations to a memory region with the
>>> Device or Strongly-ordered attribute are
>>>  permitted, the effect of such operations is UNPREDICTABLE.
>>>
>>>
>>> Given that it is implementation defined, I don't see how Linux can rely
>>> on that behavior.
>>
>> I see, the problem is that while noncached and writecombined appear to
>> be similar mappings, noncached is mapped in PRRR to strongly-ordered,
>> while writecombined is mapped to unbufferable normal memory.
>>
>> I think adding a wmb() to persistent_ram_write is going to be
>> expensive on cpus with outer caches like the L2X0, where wmb() will
>> result in a spinlock.  Is there a real SoC where this doesn't work?
> 
> A real SoC where exclusives don't work to memory not mapped as normal? Take
> your pick...

This patch doesn't actually fix problems for me. Exclusives to DDR work
for any memory type for me as the DDR controller has an exclusive
monitor. It takes write-thru cache mapping to get internal RAM to work.

Rob



From ludovic.desroches at atmel.com  Tue Apr 16 09:03:04 2013
From: ludovic.desroches at atmel.com (ludovic.desroches at atmel.com)
Date: Tue, 16 Apr 2013 15:03:04 +0200
Subject: [PATCH v2 0/6] ARM: at91: move to generic DMA device tree binding
Message-ID: <1366117390-24686-1-git-send-email-ludovic.desroches@atmel.com>

From: Ludovic Desroches <ludovic.desroches at atmel.com>

Hi,

This set of patches introduces DMA device tree bindings support for the atmel
DMA controller and first driver conversions.

Patch 3/6 has already been taken by Wolfram.

v2 changes:
- update documentation about dma bindings according to Nicolas' comments
- put dtsi changes in a separate patch
- add dtb update for i2c and mci nodes

Ludovic Desroches (6):
  at_hdmac: move to generic DMA binding
  ARM: at91: dts: set #dma-cells to the correct value
  i2c: at91: convert to dma_request_slave_channel_compat()
  ARM: at91: dts: add i2c dma support
  mci: at91: convert to dma_request_slave_channel_compat()
  ARM: at91: dts: add MCI DMA support

 .../devicetree/bindings/dma/atmel-dma.txt          | 35 ++++++--
 arch/arm/boot/dts/at91sam9g45.dtsi                 |  5 ++
 arch/arm/boot/dts/at91sam9n12.dtsi                 |  9 +++
 arch/arm/boot/dts/at91sam9x5.dtsi                  | 15 ++++
 arch/arm/boot/dts/sama5d3.dtsi                     | 19 ++++-
 drivers/dma/at_hdmac.c                             | 93 ++++++++++++++++++++--
 drivers/dma/at_hdmac_regs.h                        |  4 +
 drivers/i2c/busses/i2c-at91.c                      | 49 ++++++------
 drivers/mmc/host/atmel-mci.c                       | 25 +++---
 9 files changed, 204 insertions(+), 50 deletions(-)

-- 
1.7.11.3



From ludovic.desroches at atmel.com  Tue Apr 16 09:03:05 2013
From: ludovic.desroches at atmel.com (ludovic.desroches at atmel.com)
Date: Tue, 16 Apr 2013 15:03:05 +0200
Subject: [PATCH 1/6] at_hdmac: move to generic DMA binding
In-Reply-To: <1366117390-24686-1-git-send-email-ludovic.desroches@atmel.com>
References: <1366117390-24686-1-git-send-email-ludovic.desroches@atmel.com>
Message-ID: <1366117390-24686-2-git-send-email-ludovic.desroches@atmel.com>

From: Ludovic Desroches <ludovic.desroches at atmel.com>

Update at_hdmac driver to support generic DMA device tree binding. Devices
can still request channel with dma_request_channel() then it doesn't break
DMA for non DT boards.

Signed-off-by: Ludovic Desroches <ludovic.desroches at atmel.com>
Acked-by: Nicolas Ferre <nicolas.ferre at atmel.com>
Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
---
 .../devicetree/bindings/dma/atmel-dma.txt          | 35 ++++++--
 drivers/dma/at_hdmac.c                             | 93 ++++++++++++++++++++--
 drivers/dma/at_hdmac_regs.h                        |  4 +
 3 files changed, 121 insertions(+), 11 deletions(-)

diff --git a/Documentation/devicetree/bindings/dma/atmel-dma.txt b/Documentation/devicetree/bindings/dma/atmel-dma.txt
index 3c046ee..c80e8a3 100644
--- a/Documentation/devicetree/bindings/dma/atmel-dma.txt
+++ b/Documentation/devicetree/bindings/dma/atmel-dma.txt
@@ -1,14 +1,39 @@
 * Atmel Direct Memory Access Controller (DMA)
 
 Required properties:
-- compatible: Should be "atmel,<chip>-dma"
-- reg: Should contain DMA registers location and length
-- interrupts: Should contain DMA interrupt
+- compatible: Should be "atmel,<chip>-dma".
+- reg: Should contain DMA registers location and length.
+- interrupts: Should contain DMA interrupt.
+- #dma-cells: Must be <2>, used to represent the number of integer cells in
+the dmas property of client devices.
 
-Examples:
+Example:
 
-dma at ffffec00 {
+dma0: dma at ffffec00 {
 	compatible = "atmel,at91sam9g45-dma";
 	reg = <0xffffec00 0x200>;
 	interrupts = <21>;
+	#dma-cells = <2>;
+};
+
+DMA clients connected to the Atmel DMA controller must use the format
+described in the dma.txt file, using a three-cell specifier for each channel:
+a phandle plus two interger cells.
+The three cells in order are:
+
+1. A phandle pointing to the DMA controller.
+2. The memory interface (16 most significant bits), the peripheral interface
+(16 less significant bits).
+3. The peripheral identifier for the hardware handshaking interface. The
+identifier can be different for tx and rx.
+
+Example:
+
+i2c0 at i2c@f8010000 {
+	compatible = "atmel,at91sam9x5-i2c";
+	reg = <0xf8010000 0x100>;
+	interrupts = <9 4 6>;
+	dmas = <&dma0 1 7>,
+	       <&dma0 1 8>;
+	dma-names = "tx", "rx";
 };
diff --git a/drivers/dma/at_hdmac.c b/drivers/dma/at_hdmac.c
index de4e930..2a63dbe 100644
--- a/drivers/dma/at_hdmac.c
+++ b/drivers/dma/at_hdmac.c
@@ -24,6 +24,7 @@
 #include <linux/slab.h>
 #include <linux/of.h>
 #include <linux/of_device.h>
+#include <linux/of_dma.h>
 
 #include "at_hdmac_regs.h"
 #include "dmaengine.h"
@@ -677,7 +678,7 @@ atc_prep_slave_sg(struct dma_chan *chan, struct scatterlist *sgl,
 		ctrlb |=  ATC_DST_ADDR_MODE_FIXED
 			| ATC_SRC_ADDR_MODE_INCR
 			| ATC_FC_MEM2PER
-			| ATC_SIF(AT_DMA_MEM_IF) | ATC_DIF(AT_DMA_PER_IF);
+			| ATC_SIF(atchan->mem_if) | ATC_DIF(atchan->per_if);
 		reg = sconfig->dst_addr;
 		for_each_sg(sgl, sg, sg_len, i) {
 			struct at_desc	*desc;
@@ -716,7 +717,7 @@ atc_prep_slave_sg(struct dma_chan *chan, struct scatterlist *sgl,
 		ctrlb |=  ATC_DST_ADDR_MODE_INCR
 			| ATC_SRC_ADDR_MODE_FIXED
 			| ATC_FC_PER2MEM
-			| ATC_SIF(AT_DMA_PER_IF) | ATC_DIF(AT_DMA_MEM_IF);
+			| ATC_SIF(atchan->per_if) | ATC_DIF(atchan->mem_if);
 
 		reg = sconfig->src_addr;
 		for_each_sg(sgl, sg, sg_len, i) {
@@ -822,8 +823,8 @@ atc_dma_cyclic_fill_desc(struct dma_chan *chan, struct at_desc *desc,
 		desc->lli.ctrlb = ATC_DST_ADDR_MODE_FIXED
 				| ATC_SRC_ADDR_MODE_INCR
 				| ATC_FC_MEM2PER
-				| ATC_SIF(AT_DMA_MEM_IF)
-				| ATC_DIF(AT_DMA_PER_IF);
+				| ATC_SIF(atchan->mem_if)
+				| ATC_DIF(atchan->per_if);
 		break;
 
 	case DMA_DEV_TO_MEM:
@@ -833,8 +834,8 @@ atc_dma_cyclic_fill_desc(struct dma_chan *chan, struct at_desc *desc,
 		desc->lli.ctrlb = ATC_DST_ADDR_MODE_INCR
 				| ATC_SRC_ADDR_MODE_FIXED
 				| ATC_FC_PER2MEM
-				| ATC_SIF(AT_DMA_PER_IF)
-				| ATC_DIF(AT_DMA_MEM_IF);
+				| ATC_SIF(atchan->per_if)
+				| ATC_DIF(atchan->mem_if);
 		break;
 
 	default:
@@ -1190,6 +1191,67 @@ static void atc_free_chan_resources(struct dma_chan *chan)
 	dev_vdbg(chan2dev(chan), "free_chan_resources: done\n");
 }
 
+static bool at_dma_filter(struct dma_chan *chan, void *slave)
+{
+	struct at_dma_slave *atslave = slave;
+
+	if (atslave->dma_dev == chan->device->dev) {
+		chan->private = atslave;
+		return true;
+	} else {
+		return false;
+	}
+}
+
+#ifdef CONFIG_OF
+static struct dma_chan *at_dma_xlate(struct of_phandle_args *dma_spec,
+				     struct of_dma *of_dma)
+{
+	struct dma_chan *chan;
+	struct at_dma_chan *atchan;
+	struct at_dma_slave *atslave;
+	dma_cap_mask_t mask;
+	unsigned int per_id;
+	struct platform_device *dmac_pdev;
+
+	if (dma_spec->args_count != 2)
+		return NULL;
+
+	dmac_pdev = of_find_device_by_node(dma_spec->np);
+
+	dma_cap_zero(mask);
+	dma_cap_set(DMA_SLAVE, mask);
+
+	atslave = devm_kzalloc(&dmac_pdev->dev, sizeof(*atslave), GFP_KERNEL);
+	if (!atslave)
+		return NULL;
+	/*
+	 * We can fill both SRC_PER and DST_PER, one of these fields will be
+	 * ignored depending on DMA transfer direction.
+	 */
+	per_id = dma_spec->args[1];
+	atslave->cfg = ATC_FIFOCFG_HALFFIFO | ATC_DST_H2SEL_HW
+		      | ATC_SRC_H2SEL_HW | ATC_DST_PER(per_id)
+		      | ATC_SRC_PER(per_id);
+	atslave->dma_dev = &dmac_pdev->dev;
+
+	chan = dma_request_channel(mask, at_dma_filter, atslave);
+	if (!chan)
+		return NULL;
+
+	atchan = to_at_dma_chan(chan);
+	atchan->per_if = dma_spec->args[0] & 0xff;
+	atchan->mem_if = (dma_spec->args[0] >> 16) & 0xff;
+
+	return chan;
+}
+#else
+static struct dma_chan *at_dma_xlate(struct of_phandle_args *dma_spec,
+				     struct of_dma *of_dma)
+{
+	return NULL;
+}
+#endif
 
 /*--  Module Management  -----------------------------------------------*/
 
@@ -1344,6 +1406,8 @@ static int __init at_dma_probe(struct platform_device *pdev)
 	for (i = 0; i < plat_dat->nr_channels; i++) {
 		struct at_dma_chan	*atchan = &atdma->chan[i];
 
+		atchan->mem_if = AT_DMA_MEM_IF;
+		atchan->per_if = AT_DMA_PER_IF;
 		atchan->chan_common.device = &atdma->dma_common;
 		dma_cookie_init(&atchan->chan_common);
 		list_add_tail(&atchan->chan_common.device_node,
@@ -1390,8 +1454,25 @@ static int __init at_dma_probe(struct platform_device *pdev)
 
 	dma_async_device_register(&atdma->dma_common);
 
+	/*
+	 * Do not return an error if the dmac node is not present in order to
+	 * not break the existing way of requesting channel with
+	 * dma_request_channel().
+	 */
+	if (pdev->dev.of_node) {
+		err = of_dma_controller_register(pdev->dev.of_node,
+						 at_dma_xlate, atdma);
+		if (err) {
+			dev_err(&pdev->dev, "could not register of_dma_controller\n");
+			goto err_of_dma_controller_register;
+		}
+	}
+
 	return 0;
 
+err_of_dma_controller_register:
+	dma_async_device_unregister(&atdma->dma_common);
+	dma_pool_destroy(atdma->dma_desc_pool);
 err_pool_create:
 	platform_set_drvdata(pdev, NULL);
 	free_irq(platform_get_irq(pdev, 0), atdma);
diff --git a/drivers/dma/at_hdmac_regs.h b/drivers/dma/at_hdmac_regs.h
index 0eb3c13..c604d26 100644
--- a/drivers/dma/at_hdmac_regs.h
+++ b/drivers/dma/at_hdmac_regs.h
@@ -220,6 +220,8 @@ enum atc_status {
  * @device: parent device
  * @ch_regs: memory mapped register base
  * @mask: channel index in a mask
+ * @per_if: peripheral interface
+ * @mem_if: memory interface
  * @status: transmit status information from irq/prep* functions
  *                to tasklet (use atomic operations)
  * @tasklet: bottom half to finish transaction work
@@ -238,6 +240,8 @@ struct at_dma_chan {
 	struct at_dma		*device;
 	void __iomem		*ch_regs;
 	u8			mask;
+	u8			per_if;
+	u8			mem_if;
 	unsigned long		status;
 	struct tasklet_struct	tasklet;
 	u32			save_cfg;
-- 
1.7.11.3



From ludovic.desroches at atmel.com  Tue Apr 16 09:03:06 2013
From: ludovic.desroches at atmel.com (ludovic.desroches at atmel.com)
Date: Tue, 16 Apr 2013 15:03:06 +0200
Subject: [PATCH 2/6] ARM: at91: dts: set #dma-cells to the correct value
In-Reply-To: <1366117390-24686-1-git-send-email-ludovic.desroches@atmel.com>
References: <1366117390-24686-1-git-send-email-ludovic.desroches@atmel.com>
Message-ID: <1366117390-24686-3-git-send-email-ludovic.desroches@atmel.com>

From: Ludovic Desroches <ludovic.desroches at atmel.com>

Moving to generic DMA DT binding involves to set #dma-cells to 2.

Signed-off-by: Ludovic Desroches <ludovic.desroches at atmel.com>
---
 arch/arm/boot/dts/at91sam9g45.dtsi | 1 +
 arch/arm/boot/dts/at91sam9n12.dtsi | 1 +
 arch/arm/boot/dts/at91sam9x5.dtsi  | 2 ++
 arch/arm/boot/dts/sama5d3.dtsi     | 4 ++--
 4 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/at91sam9g45.dtsi b/arch/arm/boot/dts/at91sam9g45.dtsi
index 6b1d4ca..275e768 100644
--- a/arch/arm/boot/dts/at91sam9g45.dtsi
+++ b/arch/arm/boot/dts/at91sam9g45.dtsi
@@ -108,6 +108,7 @@
 				compatible = "atmel,at91sam9g45-dma";
 				reg = <0xffffec00 0x200>;
 				interrupts = <21 4 0>;
+				#dma-cells = <2>;
 			};
 
 			pinctrl at fffff200 {
diff --git a/arch/arm/boot/dts/at91sam9n12.dtsi b/arch/arm/boot/dts/at91sam9n12.dtsi
index 7750f98..acc4526 100644
--- a/arch/arm/boot/dts/at91sam9n12.dtsi
+++ b/arch/arm/boot/dts/at91sam9n12.dtsi
@@ -110,6 +110,7 @@
 				compatible = "atmel,at91sam9g45-dma";
 				reg = <0xffffec00 0x200>;
 				interrupts = <20 4 0>;
+				#dma-cells = <2>;
 			};
 
 			pinctrl at fffff400 {
diff --git a/arch/arm/boot/dts/at91sam9x5.dtsi b/arch/arm/boot/dts/at91sam9x5.dtsi
index 3870322..8e83d87 100644
--- a/arch/arm/boot/dts/at91sam9x5.dtsi
+++ b/arch/arm/boot/dts/at91sam9x5.dtsi
@@ -104,12 +104,14 @@
 				compatible = "atmel,at91sam9g45-dma";
 				reg = <0xffffec00 0x200>;
 				interrupts = <20 4 0>;
+				#dma-cells = <2>;
 			};
 
 			dma1: dma-controller at ffffee00 {
 				compatible = "atmel,at91sam9g45-dma";
 				reg = <0xffffee00 0x200>;
 				interrupts = <21 4 0>;
+				#dma-cells = <2>;
 			};
 
 			pinctrl at fffff400 {
diff --git a/arch/arm/boot/dts/sama5d3.dtsi b/arch/arm/boot/dts/sama5d3.dtsi
index 39b0458..95c00a3 100644
--- a/arch/arm/boot/dts/sama5d3.dtsi
+++ b/arch/arm/boot/dts/sama5d3.dtsi
@@ -348,14 +348,14 @@
 				compatible = "atmel,at91sam9g45-dma";
 				reg = <0xffffe600 0x200>;
 				interrupts = <30 4 0>;
-				#dma-cells = <1>;
+				#dma-cells = <2>;
 			};
 
 			dma1: dma-controller at ffffe800 {
 				compatible = "atmel,at91sam9g45-dma";
 				reg = <0xffffe800 0x200>;
 				interrupts = <31 4 0>;
-				#dma-cells = <1>;
+				#dma-cells = <2>;
 			};
 
 			ramc0: ramc at ffffea00 {
-- 
1.7.11.3



From ludovic.desroches at atmel.com  Tue Apr 16 09:03:07 2013
From: ludovic.desroches at atmel.com (ludovic.desroches at atmel.com)
Date: Tue, 16 Apr 2013 15:03:07 +0200
Subject: [PATCH 3/6] i2c: at91: convert to dma_request_slave_channel_compat()
In-Reply-To: <1366117390-24686-1-git-send-email-ludovic.desroches@atmel.com>
References: <1366117390-24686-1-git-send-email-ludovic.desroches@atmel.com>
Message-ID: <1366117390-24686-4-git-send-email-ludovic.desroches@atmel.com>

From: Ludovic Desroches <ludovic.desroches at atmel.com>

Use generic DMA DT helper. Platforms booting with or without DT populated are
both supported.

Signed-off-by: Ludovic Desroches <ludovic.desroches at atmel.com>
---
 drivers/i2c/busses/i2c-at91.c | 49 ++++++++++++++++++++++---------------------
 1 file changed, 25 insertions(+), 24 deletions(-)

diff --git a/drivers/i2c/busses/i2c-at91.c b/drivers/i2c/busses/i2c-at91.c
index 75195e3..7ffd544 100644
--- a/drivers/i2c/busses/i2c-at91.c
+++ b/drivers/i2c/busses/i2c-at91.c
@@ -607,11 +607,16 @@ MODULE_DEVICE_TABLE(of, atmel_twi_dt_ids);
 #define atmel_twi_dt_ids NULL
 #endif
 
-static bool filter(struct dma_chan *chan, void *slave)
+static bool filter(struct dma_chan *chan, void *pdata)
 {
-	struct at_dma_slave *sl = slave;
+	struct at91_twi_pdata *sl_pdata = pdata;
+	struct at_dma_slave *sl;
 
-	if (sl->dma_dev == chan->device->dev) {
+	if (!sl_pdata)
+		return false;
+
+	sl = &sl_pdata->dma_slave;
+	if (sl && (sl->dma_dev == chan->device->dev)) {
 		chan->private = sl;
 		return true;
 	} else {
@@ -622,11 +627,10 @@ static bool filter(struct dma_chan *chan, void *slave)
 static int at91_twi_configure_dma(struct at91_twi_dev *dev, u32 phy_addr)
 {
 	int ret = 0;
-	struct at_dma_slave *sdata;
+	struct at91_twi_pdata *pdata = dev->pdata;
 	struct dma_slave_config slave_config;
 	struct at91_twi_dma *dma = &dev->dma;
-
-	sdata = &dev->pdata->dma_slave;
+	dma_cap_mask_t mask;
 
 	memset(&slave_config, 0, sizeof(slave_config));
 	slave_config.src_addr = (dma_addr_t)phy_addr + AT91_TWI_RHR;
@@ -637,25 +641,22 @@ static int at91_twi_configure_dma(struct at91_twi_dev *dev, u32 phy_addr)
 	slave_config.dst_maxburst = 1;
 	slave_config.device_fc = false;
 
-	if (sdata && sdata->dma_dev) {
-		dma_cap_mask_t mask;
+	dma_cap_zero(mask);
+	dma_cap_set(DMA_SLAVE, mask);
 
-		dma_cap_zero(mask);
-		dma_cap_set(DMA_SLAVE, mask);
-		dma->chan_tx = dma_request_channel(mask, filter, sdata);
-		if (!dma->chan_tx) {
-			dev_err(dev->dev, "no DMA channel available for tx\n");
-			ret = -EBUSY;
-			goto error;
-		}
-		dma->chan_rx = dma_request_channel(mask, filter, sdata);
-		if (!dma->chan_rx) {
-			dev_err(dev->dev, "no DMA channel available for rx\n");
-			ret = -EBUSY;
-			goto error;
-		}
-	} else {
-		ret = -EINVAL;
+	dma->chan_tx = dma_request_slave_channel_compat(mask, filter, pdata,
+							dev->dev, "tx");
+	if (!dma->chan_tx) {
+		dev_err(dev->dev, "can't get a DMA channel for tx\n");
+		ret = -EBUSY;
+		goto error;
+	}
+
+	dma->chan_rx = dma_request_slave_channel_compat(mask, filter, pdata,
+							dev->dev, "rx");
+	if (!dma->chan_rx) {
+		dev_err(dev->dev, "can't get a DMA channel for rx\n");
+		ret = -EBUSY;
 		goto error;
 	}
 
-- 
1.7.11.3



From ludovic.desroches at atmel.com  Tue Apr 16 09:03:08 2013
From: ludovic.desroches at atmel.com (ludovic.desroches at atmel.com)
Date: Tue, 16 Apr 2013 15:03:08 +0200
Subject: [PATCH 4/6] ARM: at91: dts: add i2c dma support
In-Reply-To: <1366117390-24686-1-git-send-email-ludovic.desroches@atmel.com>
References: <1366117390-24686-1-git-send-email-ludovic.desroches@atmel.com>
Message-ID: <1366117390-24686-5-git-send-email-ludovic.desroches@atmel.com>

From: Ludovic Desroches <ludovic.desroches at atmel.com>

Add DMA resources to i2c nodes.

Signed-off-by: Ludovic Desroches <ludovic.desroches at atmel.com>
---
 arch/arm/boot/dts/at91sam9n12.dtsi | 6 ++++++
 arch/arm/boot/dts/at91sam9x5.dtsi  | 9 +++++++++
 arch/arm/boot/dts/sama5d3.dtsi     | 9 +++++++++
 3 files changed, 24 insertions(+)

diff --git a/arch/arm/boot/dts/at91sam9n12.dtsi b/arch/arm/boot/dts/at91sam9n12.dtsi
index acc4526..f912124 100644
--- a/arch/arm/boot/dts/at91sam9n12.dtsi
+++ b/arch/arm/boot/dts/at91sam9n12.dtsi
@@ -361,6 +361,9 @@
 				compatible = "atmel,at91sam9x5-i2c";
 				reg = <0xf8010000 0x100>;
 				interrupts = <9 4 6>;
+				dmas = <&dma0 1 13>,
+				       <&dma0 1 14>;
+				dma-names = "tx", "rx";
 				#address-cells = <1>;
 				#size-cells = <0>;
 				status = "disabled";
@@ -370,6 +373,9 @@
 				compatible = "atmel,at91sam9x5-i2c";
 				reg = <0xf8014000 0x100>;
 				interrupts = <10 4 6>;
+				dmas = <&dma0 1 15>,
+				       <&dma0 1 16>;
+				dma-names = "tx", "rx";
 				#address-cells = <1>;
 				#size-cells = <0>;
 				status = "disabled";
diff --git a/arch/arm/boot/dts/at91sam9x5.dtsi b/arch/arm/boot/dts/at91sam9x5.dtsi
index 8e83d87..16c9b81 100644
--- a/arch/arm/boot/dts/at91sam9x5.dtsi
+++ b/arch/arm/boot/dts/at91sam9x5.dtsi
@@ -519,6 +519,9 @@
 				compatible = "atmel,at91sam9x5-i2c";
 				reg = <0xf8010000 0x100>;
 				interrupts = <9 4 6>;
+				dmas = <&dma0 1 7>,
+				       <&dma0 1 8>;
+				dma-names = "tx", "rx";
 				#address-cells = <1>;
 				#size-cells = <0>;
 				pinctrl-names = "default";
@@ -530,6 +533,9 @@
 				compatible = "atmel,at91sam9x5-i2c";
 				reg = <0xf8014000 0x100>;
 				interrupts = <10 4 6>;
+				dmas = <&dma1 1 5>,
+				       <&dma1 1 6>;
+				dma-names = "tx", "rx";
 				#address-cells = <1>;
 				#size-cells = <0>;
 				pinctrl-names = "default";
@@ -541,6 +547,9 @@
 				compatible = "atmel,at91sam9x5-i2c";
 				reg = <0xf8018000 0x100>;
 				interrupts = <11 4 6>;
+				dmas = <&dma0 1 9>,
+				       <&dma0 1 10>;
+				dma-names = "tx", "rx";
 				#address-cells = <1>;
 				#size-cells = <0>;
 				pinctrl-names = "default";
diff --git a/arch/arm/boot/dts/sama5d3.dtsi b/arch/arm/boot/dts/sama5d3.dtsi
index 95c00a3..8e87277 100644
--- a/arch/arm/boot/dts/sama5d3.dtsi
+++ b/arch/arm/boot/dts/sama5d3.dtsi
@@ -111,6 +111,9 @@
 				compatible = "atmel,at91sam9x5-i2c";
 				reg = <0xf0014000 0x4000>;
 				interrupts = <18 4 6>;
+				dmas = <&dma0 2 7>,
+				       <&dma0 2 8>;
+				dma-names = "tx", "rx";
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_i2c0>;
 				#address-cells = <1>;
@@ -122,6 +125,9 @@
 				compatible = "atmel,at91sam9x5-i2c";
 				reg = <0xf0018000 0x4000>;
 				interrupts = <19 4 6>;
+				dmas = <&dma0 2 9>,
+				       <&dma0 2 10>;
+				dma-names = "tx", "rx";
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_i2c1>;
 				#address-cells = <1>;
@@ -294,6 +300,9 @@
 				compatible = "atmel,at91sam9x5-i2c";
 				reg = <0xf801c000 0x4000>;
 				interrupts = <20 4 6>;
+				dmas = <&dma1 2 11>,
+				       <&dma1 2 12>;
+				dma-names = "tx", "rx";
 				#address-cells = <1>;
 				#size-cells = <0>;
 				status = "disabled";
-- 
1.7.11.3



From ludovic.desroches at atmel.com  Tue Apr 16 09:03:09 2013
From: ludovic.desroches at atmel.com (ludovic.desroches at atmel.com)
Date: Tue, 16 Apr 2013 15:03:09 +0200
Subject: [PATCH 5/6] mci: at91: convert to dma_request_slave_channel_compat()
In-Reply-To: <1366117390-24686-1-git-send-email-ludovic.desroches@atmel.com>
References: <1366117390-24686-1-git-send-email-ludovic.desroches@atmel.com>
Message-ID: <1366117390-24686-6-git-send-email-ludovic.desroches@atmel.com>

From: Ludovic Desroches <ludovic.desroches at atmel.com>

Use generic DMA DT helper. Platforms booting with or without DT populated are
both supported.

Signed-off-by: Ludovic Desroches <ludovic.desroches at atmel.com>
Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
Acked-by: Nicolas Ferre <nicolas.ferre at atmel.com>
---
 drivers/mmc/host/atmel-mci.c | 25 ++++++++++++-------------
 1 file changed, 12 insertions(+), 13 deletions(-)

diff --git a/drivers/mmc/host/atmel-mci.c b/drivers/mmc/host/atmel-mci.c
index 10f8b73..73d5d24 100644
--- a/drivers/mmc/host/atmel-mci.c
+++ b/drivers/mmc/host/atmel-mci.c
@@ -2224,10 +2224,15 @@ static void __exit atmci_cleanup_slot(struct atmel_mci_slot *slot,
 	mmc_free_host(slot->mmc);
 }
 
-static bool atmci_filter(struct dma_chan *chan, void *slave)
+static bool atmci_filter(struct dma_chan *chan, void *pdata)
 {
-	struct mci_dma_data	*sl = slave;
+	struct mci_platform_data *sl_pdata = pdata;
+	struct mci_dma_data *sl;
 
+	if (!sl_pdata)
+		return false;
+
+	sl = sl_pdata->dma_slave;
 	if (sl && find_slave_dev(sl) == chan->device->dev) {
 		chan->private = slave_data_ptr(sl);
 		return true;
@@ -2239,24 +2244,18 @@ static bool atmci_filter(struct dma_chan *chan, void *slave)
 static bool atmci_configure_dma(struct atmel_mci *host)
 {
 	struct mci_platform_data	*pdata;
+	dma_cap_mask_t mask;
 
 	if (host == NULL)
 		return false;
 
 	pdata = host->pdev->dev.platform_data;
 
-	if (!pdata)
-		return false;
+	dma_cap_zero(mask);
+	dma_cap_set(DMA_SLAVE, mask);
 
-	if (pdata->dma_slave && find_slave_dev(pdata->dma_slave)) {
-		dma_cap_mask_t mask;
-
-		/* Try to grab a DMA channel */
-		dma_cap_zero(mask);
-		dma_cap_set(DMA_SLAVE, mask);
-		host->dma.chan =
-			dma_request_channel(mask, atmci_filter, pdata->dma_slave);
-	}
+	host->dma.chan = dma_request_slave_channel_compat(mask, atmci_filter, pdata,
+						   	  &host->pdev->dev, "rxtx");
 	if (!host->dma.chan) {
 		dev_warn(&host->pdev->dev, "no DMA channel available\n");
 		return false;
-- 
1.7.11.3



From ludovic.desroches at atmel.com  Tue Apr 16 09:03:10 2013
From: ludovic.desroches at atmel.com (ludovic.desroches at atmel.com)
Date: Tue, 16 Apr 2013 15:03:10 +0200
Subject: [PATCH 6/6] ARM: at91: dts: add MCI DMA support
In-Reply-To: <1366117390-24686-1-git-send-email-ludovic.desroches@atmel.com>
References: <1366117390-24686-1-git-send-email-ludovic.desroches@atmel.com>
Message-ID: <1366117390-24686-7-git-send-email-ludovic.desroches@atmel.com>

From: Ludovic Desroches <ludovic.desroches at atmel.com>

Add DMA resources to MCI nodes.

Signed-off-by: Ludovic Desroches <ludovic.desroches at atmel.com>
---
 arch/arm/boot/dts/at91sam9g45.dtsi | 4 ++++
 arch/arm/boot/dts/at91sam9n12.dtsi | 2 ++
 arch/arm/boot/dts/at91sam9x5.dtsi  | 4 ++++
 arch/arm/boot/dts/sama5d3.dtsi     | 6 ++++++
 4 files changed, 16 insertions(+)

diff --git a/arch/arm/boot/dts/at91sam9g45.dtsi b/arch/arm/boot/dts/at91sam9g45.dtsi
index 275e768..de2abc0 100644
--- a/arch/arm/boot/dts/at91sam9g45.dtsi
+++ b/arch/arm/boot/dts/at91sam9g45.dtsi
@@ -513,6 +513,8 @@
 				compatible = "atmel,hsmci";
 				reg = <0xfff80000 0x600>;
 				interrupts = <11 4 0>;
+				dmas = <&dma0 1 0>;
+				dma-names = "rxtx";
 				#address-cells = <1>;
 				#size-cells = <0>;
 				status = "disabled";
@@ -522,6 +524,8 @@
 				compatible = "atmel,hsmci";
 				reg = <0xfffd0000 0x600>;
 				interrupts = <29 4 0>;
+				dmas = <&dma0 1 13>;
+				dma-names = "rxtx";
 				#address-cells = <1>;
 				#size-cells = <0>;
 				status = "disabled";
diff --git a/arch/arm/boot/dts/at91sam9n12.dtsi b/arch/arm/boot/dts/at91sam9n12.dtsi
index f912124..0b61c41 100644
--- a/arch/arm/boot/dts/at91sam9n12.dtsi
+++ b/arch/arm/boot/dts/at91sam9n12.dtsi
@@ -89,6 +89,8 @@
 				compatible = "atmel,hsmci";
 				reg = <0xf0008000 0x600>;
 				interrupts = <12 4 0>;
+				dmas = <&dma0 1 0>
+				dma-names = "rxtx";
 				#address-cells = <1>;
 				#size-cells = <0>;
 				status = "disabled";
diff --git a/arch/arm/boot/dts/at91sam9x5.dtsi b/arch/arm/boot/dts/at91sam9x5.dtsi
index 16c9b81..5f42e7a 100644
--- a/arch/arm/boot/dts/at91sam9x5.dtsi
+++ b/arch/arm/boot/dts/at91sam9x5.dtsi
@@ -449,6 +449,8 @@
 				compatible = "atmel,hsmci";
 				reg = <0xf0008000 0x600>;
 				interrupts = <12 4 0>;
+				dmas = <&dma0 1 0>;
+				dma-names = "rxtx";
 				#address-cells = <1>;
 				#size-cells = <0>;
 				status = "disabled";
@@ -458,6 +460,8 @@
 				compatible = "atmel,hsmci";
 				reg = <0xf000c000 0x600>;
 				interrupts = <26 4 0>;
+				dmas = <&dma1 1 0>;
+				dma-names = "rxtx";
 				#address-cells = <1>;
 				#size-cells = <0>;
 				status = "disabled";
diff --git a/arch/arm/boot/dts/sama5d3.dtsi b/arch/arm/boot/dts/sama5d3.dtsi
index 8e87277..2e643ea 100644
--- a/arch/arm/boot/dts/sama5d3.dtsi
+++ b/arch/arm/boot/dts/sama5d3.dtsi
@@ -60,6 +60,8 @@
 				compatible = "atmel,hsmci";
 				reg = <0xf0000000 0x600>;
 				interrupts = <21 4 0>;
+				dmas = <&dma0 2 0>;
+				dma-names = "rxtx";
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_mmc0_clk_cmd_dat0 &pinctrl_mmc0_dat1_3 &pinctrl_mmc0_dat4_7>;
 				status = "disabled";
@@ -173,6 +175,8 @@
 				compatible = "atmel,hsmci";
 				reg = <0xf8000000 0x600>;
 				interrupts = <22 4 0>;
+				dmas = <&dma1 2 0>;
+				dma-names = "rxtx";
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_mmc1_clk_cmd_dat0 &pinctrl_mmc1_dat1_3>;
 				status = "disabled";
@@ -184,6 +188,8 @@
 				compatible = "atmel,hsmci";
 				reg = <0xf8004000 0x600>;
 				interrupts = <23 4 0>;
+				dmas = <&dma1 2 1>;
+				dma-names = "rxtx";
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_mmc2_clk_cmd_dat0 &pinctrl_mmc2_dat1_3>;
 				status = "disabled";
-- 
1.7.11.3



From robherring2 at gmail.com  Tue Apr 16 09:09:10 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Tue, 16 Apr 2013 08:09:10 -0500
Subject: [PATCH v5 5/6] ARM: dts: Add basic dts include files for Samsung
 S3C64xx SoCs
In-Reply-To: <1366060483-20342-6-git-send-email-tomasz.figa@gmail.com>
References: <1366060483-20342-1-git-send-email-tomasz.figa@gmail.com>
 <1366060483-20342-6-git-send-email-tomasz.figa@gmail.com>
Message-ID: <516D4D76.2010409@gmail.com>

On 04/15/2013 04:14 PM, Tomasz Figa wrote:
> This patch adds basic device tree definitions for Samsung S3C64xx SoCs.
> 
> Since all the SoCs in the series are very similar, the files are created
> hierarchically - one file for the whole series and then separate files
> for particular SoCs including the common one.
> 
> Signed-off-by: Tomasz Figa <tomasz.figa at gmail.com>
> ---
>  arch/arm/boot/dts/s3c6400.dtsi         |  33 ++
>  arch/arm/boot/dts/s3c6410.dtsi         |  33 ++
>  arch/arm/boot/dts/s3c64xx-pinctrl.dtsi | 683 +++++++++++++++++++++++++++++++++
>  arch/arm/boot/dts/s3c64xx.dtsi         | 136 +++++++
>  4 files changed, 885 insertions(+)
>  create mode 100644 arch/arm/boot/dts/s3c6400.dtsi
>  create mode 100644 arch/arm/boot/dts/s3c6410.dtsi
>  create mode 100644 arch/arm/boot/dts/s3c64xx-pinctrl.dtsi
>  create mode 100644 arch/arm/boot/dts/s3c64xx.dtsi
> 

[...]

> +
> +	vic0: interrupt-controller at 71200000 {

These nodes should be off a "simple-bus" node.

Rob

> +		compatible = "arm,pl192-vic";
> +		interrupt-controller;
> +		reg = <0x71200000 0x1000>;
> +		#interrupt-cells = <1>;
> +	};
> +
> +	vic1: interrupt-controller at 71300000 {
> +		compatible = "arm,pl192-vic";
> +		interrupt-controller;
> +		reg = <0x71300000 0x1000>;
> +		#interrupt-cells = <1>;
> +	};
> +
> +	pinctrl0: pinctrl at 7f008000 {
> +		compatible = "samsung,s3c64xx-pinctrl";
> +		reg = <0x7f008000 0x1000>;
> +		interrupt-parent = <&vic1>;
> +		interrupts = <21>;
> +
> +		pctrl_int_map: pinctrl-interrupt-map {
> +			interrupt-map = <0 &vic0 0>,
> +					<1 &vic0 1>,
> +					<2 &vic1 0>,
> +					<3 &vic1 1>;
> +			#address-cells = <0>;
> +			#size-cells = <0>;
> +			#interrupt-cells = <1>;
> +		};
> +
> +		wakeup-interrupt-controller {
> +			compatible = "samsung,s3c64xx-wakeup-eint";
> +			interrupts = <0>, <1>, <2>, <3>;
> +			interrupt-parent = <&pctrl_int_map>;
> +		};
> +	};
> +
> +	pwm: pwm at 7f006000 {
> +		compatible = "samsung,s3c6400-pwm";
> +		reg = <0x7f006000 0x1000>;
> +		interrupt-parent = <&vic0>;
> +		interrupts = <23>, <24>, <25>, <27>, <28>;
> +		samsung,pwm-outputs = <0>, <1>;
> +		#pwm-cells = <3>;
> +		status = "disabled";
> +	};
> +
> +	uart0: serial at 7f005000 {
> +		compatible = "samsung,s3c6400-uart";
> +		reg = <0x7f005000 0x100>;
> +		interrupt-parent = <&vic1>;
> +		interrupts = <5>;
> +		status = "disabled";
> +	};
> +
> +	uart1: serial at 7f005400 {
> +		compatible = "samsung,s3c6400-uart";
> +		reg = <0x7f005400 0x100>;
> +		interrupt-parent = <&vic1>;
> +		interrupts = <6>;
> +		status = "disabled";
> +	};
> +
> +	uart2: serial at 7f005800 {
> +		compatible = "samsung,s3c6400-uart";
> +		reg = <0x7f005800 0x100>;
> +		interrupt-parent = <&vic1>;
> +		interrupts = <7>;
> +		status = "disabled";
> +	};
> +
> +	uart3: serial at 7f005c00 {
> +		compatible = "samsung,s3c6400-uart";
> +		reg = <0x7f005c00 0x100>;
> +		interrupt-parent = <&vic1>;
> +		interrupts = <8>;
> +		status = "disabled";
> +	};
> +
> +	sdhci0: sdhci at 7c200000 {
> +		compatible = "samsung,s3c6410-sdhci";
> +		reg = <0x7c200000 0x100>;
> +		interrupt-parent = <&vic1>;
> +		interrupts = <24>;
> +		status = "disabled";
> +	};
> +
> +	sdhci1: sdhci at 7c300000 {
> +		compatible = "samsung,s3c6410-sdhci";
> +		reg = <0x7c300000 0x100>;
> +		interrupt-parent = <&vic1>;
> +		interrupts = <25>;
> +		status = "disabled";
> +	};
> +
> +	sdhci2: sdhci at 7c400000 {
> +		compatible = "samsung,s3c6410-sdhci";
> +		reg = <0x7c400000 0x100>;
> +		interrupt-parent = <&vic1>;
> +		interrupts = <17>;
> +		status = "disabled";
> +	};
> +};
> +
> +/include/ "s3c64xx-pinctrl.dtsi"
> 



From t.figa at samsung.com  Tue Apr 16 09:19:00 2013
From: t.figa at samsung.com (Tomasz Figa)
Date: Tue, 16 Apr 2013 15:19 +0200
Subject: [PATCH v5 5/6] ARM: dts: Add basic dts include files for Samsung
 S3C64xx SoCs
In-Reply-To: <516D4D76.2010409@gmail.com>
References: <1366060483-20342-1-git-send-email-tomasz.figa@gmail.com>
 <1366060483-20342-6-git-send-email-tomasz.figa@gmail.com>
 <516D4D76.2010409@gmail.com>
Message-ID: <1829212.6niSeTsyIU@amdc1227>

On Tuesday 16 of April 2013 08:09:10 Rob Herring wrote:
> On 04/15/2013 04:14 PM, Tomasz Figa wrote:
> > This patch adds basic device tree definitions for Samsung S3C64xx SoCs.
> > 
> > Since all the SoCs in the series are very similar, the files are created
> > hierarchically - one file for the whole series and then separate files
> > for particular SoCs including the common one.
> > 
> > Signed-off-by: Tomasz Figa <tomasz.figa at gmail.com>
> > ---
> > 
> >  arch/arm/boot/dts/s3c6400.dtsi         |  33 ++
> >  arch/arm/boot/dts/s3c6410.dtsi         |  33 ++
> >  arch/arm/boot/dts/s3c64xx-pinctrl.dtsi | 683
> >  +++++++++++++++++++++++++++++++++ arch/arm/boot/dts/s3c64xx.dtsi        
> >  | 136 +++++++
> >  4 files changed, 885 insertions(+)
> >  create mode 100644 arch/arm/boot/dts/s3c6400.dtsi
> >  create mode 100644 arch/arm/boot/dts/s3c6410.dtsi
> >  create mode 100644 arch/arm/boot/dts/s3c64xx-pinctrl.dtsi
> >  create mode 100644 arch/arm/boot/dts/s3c64xx.dtsi
> 
> [...]
> 
> > +
> > +	vic0: interrupt-controller at 71200000 {
> 
> These nodes should be off a "simple-bus" node.

Hmm, is there any reason behind it?

I thought simple bus was just a convenient helper to represent hierarchical 
bus structures if one has a need to do so.

Best regards,
Tomasz

> Rob
> 
> > +		compatible = "arm,pl192-vic";
> > +		interrupt-controller;
> > +		reg = <0x71200000 0x1000>;
> > +		#interrupt-cells = <1>;
> > +	};
> > +
> > +	vic1: interrupt-controller at 71300000 {
> > +		compatible = "arm,pl192-vic";
> > +		interrupt-controller;
> > +		reg = <0x71300000 0x1000>;
> > +		#interrupt-cells = <1>;
> > +	};
> > +
> > +	pinctrl0: pinctrl at 7f008000 {
> > +		compatible = "samsung,s3c64xx-pinctrl";
> > +		reg = <0x7f008000 0x1000>;
> > +		interrupt-parent = <&vic1>;
> > +		interrupts = <21>;
> > +
> > +		pctrl_int_map: pinctrl-interrupt-map {
> > +			interrupt-map = <0 &vic0 0>,
> > +					<1 &vic0 1>,
> > +					<2 &vic1 0>,
> > +					<3 &vic1 1>;
> > +			#address-cells = <0>;
> > +			#size-cells = <0>;
> > +			#interrupt-cells = <1>;
> > +		};
> > +
> > +		wakeup-interrupt-controller {
> > +			compatible = "samsung,s3c64xx-wakeup-eint";
> > +			interrupts = <0>, <1>, <2>, <3>;
> > +			interrupt-parent = <&pctrl_int_map>;
> > +		};
> > +	};
> > +
> > +	pwm: pwm at 7f006000 {
> > +		compatible = "samsung,s3c6400-pwm";
> > +		reg = <0x7f006000 0x1000>;
> > +		interrupt-parent = <&vic0>;
> > +		interrupts = <23>, <24>, <25>, <27>, <28>;
> > +		samsung,pwm-outputs = <0>, <1>;
> > +		#pwm-cells = <3>;
> > +		status = "disabled";
> > +	};
> > +
> > +	uart0: serial at 7f005000 {
> > +		compatible = "samsung,s3c6400-uart";
> > +		reg = <0x7f005000 0x100>;
> > +		interrupt-parent = <&vic1>;
> > +		interrupts = <5>;
> > +		status = "disabled";
> > +	};
> > +
> > +	uart1: serial at 7f005400 {
> > +		compatible = "samsung,s3c6400-uart";
> > +		reg = <0x7f005400 0x100>;
> > +		interrupt-parent = <&vic1>;
> > +		interrupts = <6>;
> > +		status = "disabled";
> > +	};
> > +
> > +	uart2: serial at 7f005800 {
> > +		compatible = "samsung,s3c6400-uart";
> > +		reg = <0x7f005800 0x100>;
> > +		interrupt-parent = <&vic1>;
> > +		interrupts = <7>;
> > +		status = "disabled";
> > +	};
> > +
> > +	uart3: serial at 7f005c00 {
> > +		compatible = "samsung,s3c6400-uart";
> > +		reg = <0x7f005c00 0x100>;
> > +		interrupt-parent = <&vic1>;
> > +		interrupts = <8>;
> > +		status = "disabled";
> > +	};
> > +
> > +	sdhci0: sdhci at 7c200000 {
> > +		compatible = "samsung,s3c6410-sdhci";
> > +		reg = <0x7c200000 0x100>;
> > +		interrupt-parent = <&vic1>;
> > +		interrupts = <24>;
> > +		status = "disabled";
> > +	};
> > +
> > +	sdhci1: sdhci at 7c300000 {
> > +		compatible = "samsung,s3c6410-sdhci";
> > +		reg = <0x7c300000 0x100>;
> > +		interrupt-parent = <&vic1>;
> > +		interrupts = <25>;
> > +		status = "disabled";
> > +	};
> > +
> > +	sdhci2: sdhci at 7c400000 {
> > +		compatible = "samsung,s3c6410-sdhci";
> > +		reg = <0x7c400000 0x100>;
> > +		interrupt-parent = <&vic1>;
> > +		interrupts = <17>;
> > +		status = "disabled";
> > +	};
> > +};
> > +
> > +/include/ "s3c64xx-pinctrl.dtsi"
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
> in the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
-- 
Tomasz Figa
Samsung Poland R&D Center
SW Solution Development, Kernel and System Framework



From nicolas.ferre at atmel.com  Tue Apr 16 09:42:36 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Tue, 16 Apr 2013 15:42:36 +0200
Subject: [PATCH 4/8] video: atmel_lcdfb: add device tree suport
In-Reply-To: <1365692422-9565-4-git-send-email-plagnioj@jcrosoft.com>
References: <20130411145741.GB25242@game.jcrosoft.org>
 <1365692422-9565-1-git-send-email-plagnioj@jcrosoft.com>
 <1365692422-9565-4-git-send-email-plagnioj@jcrosoft.com>
Message-ID: <516D554C.1090909@atmel.com>

On 04/11/2013 05:00 PM, Jean-Christophe PLAGNIOL-VILLARD :
> get display timings from device tree
> Use videomode helpers to get display timings and configurations from
> device tree

2 sentences? Simply elaborate the 2nd one and it will be good.

> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
> Cc: linux-fbdev at vger.kernel.org
> Cc: Nicolas Ferre <nicolas.ferre at atmel.com>
> Cc: Andrew Morton <akpm at linux-foundation.org>
> ---
>  .../devicetree/bindings/video/atmel,lcdc.txt       |   75 ++++++
>  drivers/video/Kconfig                              |    2 +
>  drivers/video/atmel_lcdfb.c                        |  244 +++++++++++++++++---
>  3 files changed, 289 insertions(+), 32 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/video/atmel,lcdc.txt
> 
> diff --git a/Documentation/devicetree/bindings/video/atmel,lcdc.txt b/Documentation/devicetree/bindings/video/atmel,lcdc.txt
> new file mode 100644
> index 0000000..1ec175e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/atmel,lcdc.txt

Why lcdc? I would have preferred atmel,lcdfb, like the driver's name: it
is even more self-explanatory...

> @@ -0,0 +1,75 @@
> +Atmel LCDC Framebuffer
> +-----------------------------------------------------
> +
> +Required properties:
> +- compatible :
> +	"atmel,at91sam9261-lcdc" , 
> +	"atmel,at91sam9263-lcdc" ,
> +	"atmel,at91sam9g10-lcdc" ,
> +	"atmel,at91sam9g45-lcdc" ,
> +	"atmel,at91sam9g45es-lcdc" ,
> +	"atmel,at91sam9rl-lcdc" ,
> +	"atmel,at32ap-lcdc"
> +- reg : Should contain 1 register ranges(address and length)
> +- interrupts : framebuffer controller interrupt
> +- display: a phandle pointing to the display node
> +
> +Required nodes:
> +- display: a display node is required to initialize the lcd panel
> +	This should be in the board dts.
> +- default-mode: a videomode within the display with timing parameters
> +	as specified below.
> +
> +Example:
> +
> +	fb0: fb at 0x00500000 {
> +		compatible = "atmel,at91sam9g45-lcdc";
> +		reg = <0x00500000 0x1000>;
> +		interrupts = <23 3 0>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&pinctrl_fb>;
> +		display = <&display0>;
> +		status = "okay";
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +
> +	};
> +
> +Atmel LCDC Display
> +-----------------------------------------------------
> +Required properties (as per of_videomode_helper):

Can you please point somewhere to the documentation:
Documentation/devicetree/bindings/video/display-timing.txt

> + - atmel,dmacon: dma controler configuration

Typo: controller.

> + - atmel,lcdcon2: lcd controler configuration

Ditto

> + - atmel,guard-time: lcd guard time (Delay in frame periods)

periods -> period, no?

> + - bits-per-pixel: lcd panel bit-depth.
> +
> +Optional properties (as per of_videomode_helper):
> + - atmel,lcdcon-backlight: enable backlight
> + - atmel,lcd-wiring-mode: lcd wiring mode "RGB" or "BRG"

Is it a sting, or a number (as seen below)? If it is a number, please
tell how to choose the index.


> + - atmel,power-control-gpio: gpio to power on or off the LCD (as many as needed)
> +
> +Example:
> +	display0: display {
> +		bits-per-pixel = <32>;
> +		atmel,lcdcon-backlight;
> +		atmel,dmacon = <0x1>;
> +		atmel,lcdcon2 = <0x80008002>;
> +		atmel,guard-time = <9>;
> +		atmel,lcd-wiring-mode = <1>;
> +
> +		display-timings {
> +			native-mode = <&timing0>;
> +			timing0: timing0 {
> +				clock-frequency = <9000000>;
> +				hactive = <480>;
> +				vactive = <272>;
> +				hback-porch = <1>;
> +				hfront-porch = <1>;
> +				vback-porch = <40>;
> +				vfront-porch = <1>;
> +				hsync-len = <45>;
> +				vsync-len = <1>;
> +			};
> +		};
> +	};
> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> index 4c1546f..0687482 100644
> --- a/drivers/video/Kconfig
> +++ b/drivers/video/Kconfig
> @@ -1018,6 +1018,8 @@ config FB_ATMEL
>  	select FB_CFB_FILLRECT
>  	select FB_CFB_COPYAREA
>  	select FB_CFB_IMAGEBLIT
> +	select FB_MODE_HELPERS
> +	select OF_VIDEOMODE
>  	help
>  	  This enables support for the AT91/AT32 LCD Controller.
>  
> diff --git a/drivers/video/atmel_lcdfb.c b/drivers/video/atmel_lcdfb.c
> index f67e226..4a31570 100644
> --- a/drivers/video/atmel_lcdfb.c
> +++ b/drivers/video/atmel_lcdfb.c
> @@ -20,7 +20,11 @@
>  #include <linux/gfp.h>
>  #include <linux/module.h>
>  #include <linux/platform_data/atmel.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>
> +#include <linux/of_gpio.h>
>  #include <video/of_display_timing.h>

As said in patch 1/8, this one belongs to this 4/8 patch.

> +#include <video/videomode.h>
>  
>  #include <mach/cpu.h>
>  #include <asm/gpio.h>
> @@ -59,6 +63,13 @@ struct atmel_lcdfb_info {
>  	struct atmel_lcdfb_config *config;
>  };
>  
> +struct atmel_lcdfb_power_ctrl_gpio {
> +	int gpio;
> +	int active_low;
> +
> +	struct list_head list;
> +};
> +
>  #define lcdc_readl(sinfo, reg)		__raw_readl((sinfo)->mmio+(reg))
>  #define lcdc_writel(sinfo, reg, val)	__raw_writel((val), (sinfo)->mmio+(reg))
>  
> @@ -945,16 +956,187 @@ static void atmel_lcdfb_stop_clock(struct atmel_lcdfb_info *sinfo)
>  	clk_disable(sinfo->lcdc_clk);
>  }
>  
> +#ifdef CONFIG_OF
> +static const struct of_device_id atmel_lcdfb_dt_ids[] = {
> +	{ .compatible = "atmel,at91sam9261-lcdc" , .data = &at91sam9261_config, },
> +	{ .compatible = "atmel,at91sam9263-lcdc" , .data = &at91sam9263_config, },
> +	{ .compatible = "atmel,at91sam9g10-lcdc" , .data = &at91sam9g10_config, },
> +	{ .compatible = "atmel,at91sam9g45-lcdc" , .data = &at91sam9g45_config, },
> +	{ .compatible = "atmel,at91sam9g45es-lcdc" , .data = &at91sam9g45es_config, },
> +	{ .compatible = "atmel,at91sam9rl-lcdc" , .data = &at91sam9rl_config, },
> +	{ .compatible = "atmel,at32ap-lcdc" , .data = &at32ap_config, },
> +	{ /* sentinel */ }
> +};
> +
> +MODULE_DEVICE_TABLE(of, atmel_lcdfb_dt_ids);
> +
> +static const char *atmel_lcdfb_wiring_modes[] = {
> +	[ATMEL_LCDC_WIRING_BGR]	= "BRG",
> +	[ATMEL_LCDC_WIRING_RGB]	= "RGB",
> +};
> +
> +const int atmel_lcdfb_get_of_wiring_modes(struct device_node *np)
> +{
> +	const char *mode;
> +	int err, i;
> +
> +	err = of_property_read_string(np, "atmel,lcd-wiring-mode", &mode);
> +	if (err < 0)
> +		return ATMEL_LCDC_WIRING_BGR;
> +
> +	for (i = 0; i < ARRAY_SIZE(atmel_lcdfb_wiring_modes); i++)
> +		if (!strcasecmp(mode, atmel_lcdfb_wiring_modes[i]))
> +			return i;
> +
> +	return -ENODEV;
> +}
> +
> +static void atmel_lcdfb_power_control_gpio(struct atmel_lcdfb_pdata *pdata, int on)
> +{
> +	struct atmel_lcdfb_power_ctrl_gpio *og;
> +
> +	list_for_each_entry(og, &pdata->pwr_gpios, list)
> +		gpio_set_value(og->gpio, on);
> +}
> +
> +static int atmel_lcdfb_of_init(struct atmel_lcdfb_info *sinfo)
> +{
> +	struct fb_info *info = sinfo->info;
> +	struct atmel_lcdfb_pdata *pdata = &sinfo->pdata;
> +	struct fb_var_screeninfo *var = &info->var;
> +	struct device *dev = &sinfo->pdev->dev;
> +	struct device_node *np =dev->of_node;
> +	struct device_node *display_np;
> +	struct device_node *timings_np;
> +	struct display_timings *timings;
> +	enum of_gpio_flags flags;
> +	struct atmel_lcdfb_power_ctrl_gpio *og;
> +	bool is_gpio_power = false;
> +	int ret = -ENOENT;
> +	int i, gpio;
> +
> +	sinfo->config = (struct atmel_lcdfb_config*)
> +		of_match_device(atmel_lcdfb_dt_ids, dev)->data;

Please split it in 2 steps, otherwise the day that the drivers doesn't
find the device in dt_ids table, it hangs here with an Oops.

> +
> +	display_np = of_parse_phandle(np, "display", 0);
> +	if (!display_np) {
> +		dev_err(dev, "failed to find display phandle\n");
> +		return -ENOENT;
> +	}
> +
> +	ret = of_property_read_u32(display_np, "bits-per-pixel", &var->bits_per_pixel);
> +	if (ret < 0) {
> +		dev_err(dev, "failed to get property bits-per-pixel\n");
> +		goto put_display_node;
> +	}
> +
> +	ret = of_property_read_u32(display_np, "atmel,guard-time", &pdata->guard_time);
> +	if (ret < 0) {
> +		dev_err(dev, "failed to get property atmel,guard-time\n");
> +		goto put_display_node;
> +	}
> +
> +	ret = of_property_read_u32(display_np, "atmel,lcdcon2", &pdata->default_lcdcon2);
> +	if (ret < 0) {
> +		dev_err(dev, "failed to get property atmel,lcdcon2\n");
> +		goto put_display_node;
> +	}
> +
> +	ret = of_property_read_u32(display_np, "atmel,dmacon", &pdata->default_dmacon);
> +	if (ret < 0) {
> +		dev_err(dev, "failed to get property bits-per-pixel\n");

No, wrong error message.

> +		goto put_display_node;
> +	}
> +
> +	ret = -ENOMEM;
> +	for (i = 0; i < of_gpio_named_count(display_np, "atmel,power-control-gpio"); i++) {
> +		gpio = of_get_named_gpio_flags(display_np, "atmel,power-control-gpio",
> +					       i, &flags);
> +		if (gpio < 0)
> +			continue;
> +
> +		og = devm_kzalloc(dev, sizeof(*og), GFP_KERNEL);
> +		if (!og)
> +			goto put_display_node;
> +
> +		og->gpio = gpio;
> +		og->active_low = flags & OF_GPIO_ACTIVE_LOW;
> +		is_gpio_power = true;
> +		ret = devm_gpio_request(dev, gpio, "lcd-power-control-gpio");
> +		if (ret) {
> +			dev_err(dev, "request gpio %d failed\n", gpio);
> +			goto put_display_node;
> +		}
> +
> +		ret = gpio_direction_output(gpio, og->active_low);
> +		if (ret) {
> +			dev_err(dev, "set direction output gpio %d failed\n", gpio);
> +			goto put_display_node;
> +		}
> +	}
> +
> +	if (is_gpio_power)
> +		pdata->atmel_lcdfb_power_control = atmel_lcdfb_power_control_gpio;
> +
> +	ret = atmel_lcdfb_get_of_wiring_modes(display_np);
> +	if (ret < 0) {
> +		dev_err(dev, "invalid atmel,lcd-wiring-mode\n");
> +		goto put_display_node;
> +	}
> +	pdata->lcd_wiring_mode = ret;
> +
> +	pdata->lcdcon_is_backlight = of_property_read_bool(display_np, "atmel,lcdcon-backlight");
> +
> +	timings = of_get_display_timings(display_np);
> +	if (!timings) {
> +		dev_err(dev, "failed to get display timings\n");
> +		goto put_display_node;
> +	}
> +
> +	timings_np = of_find_node_by_name(display_np, "display-timings");
> +	if (!timings_np) {
> +		dev_err(dev, "failed to find display-timings node\n");
> +		goto put_display_node;
> +	}
> +
> +	for (i = 0; i < of_get_child_count(timings_np); i++) {
> +		struct videomode vm;
> +		struct fb_videomode fb_vm;
> +
> +		ret = videomode_from_timing(timings, &vm, i);
> +		if (ret < 0)
> +			goto put_timings_node;
> +		ret = fb_videomode_from_videomode(&vm, &fb_vm);
> +		if (ret < 0)
> +			goto put_timings_node;
> +
> +		fb_add_videomode(&fb_vm, &info->modelist);
> +	}
> +
> +	return 0;
> +
> +put_timings_node:
> +	of_node_put(timings_np);
> +put_display_node:
> +	of_node_put(display_np);
> +	return ret;
> +}
> +#else
> +static int atmel_lcdfb_of_init(struct atmel_lcdfb_info *sinfo)
> +{
> +	return 0;
> +}
> +#endif
>  
>  static int __init atmel_lcdfb_probe(struct platform_device *pdev)
>  {
>  	struct device *dev = &pdev->dev;
>  	struct fb_info *info;
>  	struct atmel_lcdfb_info *sinfo;
> -	struct atmel_lcdfb_pdata *pdata;
> -	struct fb_videomode fbmode;
> +	struct atmel_lcdfb_pdata *pdata = NULL;
>  	struct resource *regs = NULL;
>  	struct resource *map = NULL;
> +	struct fb_modelist *modelist;
>  	int ret;
>  
>  	dev_dbg(dev, "%s BEGIN\n", __func__);
> @@ -967,17 +1149,35 @@ static int __init atmel_lcdfb_probe(struct platform_device *pdev)
>  	}
>  
>  	sinfo = info->par;
> +	sinfo->pdev = pdev;
> +	sinfo->info = info;
> +
> +	INIT_LIST_HEAD(&info->modelist);
>  
> -	if (dev->platform_data) {
> -		pdata = (struct atmel_lcdfb_pdata *)dev->platform_data;
> +	if (pdev->dev.of_node) {
> +		ret = atmel_lcdfb_of_init(sinfo);
> +		if (ret)
> +			goto free_info;
> +	} else if (dev->platform_data) {
> +		struct fb_monspecs *monspecs;
> +		int i;
> +
> +		pdata = dev->platform_data;
> +		monspecs = pdata->default_monspecs;
>  		sinfo->pdata = *pdata;
> +
> +		for (i = 0; i < monspecs->modedb_len; i++)
> +			fb_add_videomode(&monspecs->modedb[i], &info->modelist);
> +
> +		sinfo->config = atmel_lcdfb_get_config(pdev);
> +
> +		info->var.bits_per_pixel = pdata->default_bpp ? pdata->default_bpp : 16;
> +		memcpy(&info->monspecs, pdata->default_monspecs, sizeof(info->monspecs));
>  	} else {
>  		dev_err(dev, "cannot get default configuration\n");
>  		goto free_info;
>  	}
> -	sinfo->info = info;
> -	sinfo->pdev = pdev;
> -	sinfo->config = atmel_lcdfb_get_config(pdev);
> +
>  	if (!sinfo->config)
>  		goto free_info;
>  
> @@ -986,7 +1186,6 @@ static int __init atmel_lcdfb_probe(struct platform_device *pdev)
>  	info->pseudo_palette = sinfo->pseudo_palette;
>  	info->fbops = &atmel_lcdfb_ops;
>  
> -	memcpy(&info->monspecs, pdata->default_monspecs, sizeof(info->monspecs));
>  	info->fix = atmel_lcdfb_fix;
>  
>  	/* Enable LCDC Clocks */
> @@ -1002,14 +1201,11 @@ static int __init atmel_lcdfb_probe(struct platform_device *pdev)
>  	}
>  	atmel_lcdfb_start_clock(sinfo);
>  
> -	ret = fb_find_mode(&info->var, info, NULL, info->monspecs.modedb,
> -			info->monspecs.modedb_len, info->monspecs.modedb,
> -			pdata->default_bpp);
> -	if (!ret) {
> -		dev_err(dev, "no suitable video mode found\n");
> -		goto stop_clk;
> -	}
> +	modelist = list_first_entry(&info->modelist,
> +			struct fb_modelist, list);
> +	fb_videomode_to_var(&info->var, &modelist->mode);
>  
> +	atmel_lcdfb_check_var(&info->var, info);
>  
>  	regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>  	if (!regs) {
> @@ -1093,18 +1289,6 @@ static int __init atmel_lcdfb_probe(struct platform_device *pdev)
>  		goto unregister_irqs;
>  	}
>  
> -	/*
> -	 * This makes sure that our colour bitfield
> -	 * descriptors are correctly initialised.
> -	 */
> -	atmel_lcdfb_check_var(&info->var, info);
> -
> -	ret = fb_set_var(info, &info->var);
> -	if (ret) {
> -		dev_warn(dev, "unable to set display parameters\n");
> -		goto free_cmap;
> -	}
> -
>  	dev_set_drvdata(dev, info);
>  
>  	/*
> @@ -1116,10 +1300,6 @@ static int __init atmel_lcdfb_probe(struct platform_device *pdev)
>  		goto reset_drvdata;
>  	}
>  
> -	/* add selected videomode to modelist */
> -	fb_var_to_videomode(&fbmode, &info->var);
> -	fb_add_videomode(&fbmode, &info->modelist);
> -
>  	/* Power up the LCDC screen */
>  	atmel_lcdfb_power_control(sinfo, 1);
>  
> @@ -1130,7 +1310,6 @@ static int __init atmel_lcdfb_probe(struct platform_device *pdev)
>  
>  reset_drvdata:
>  	dev_set_drvdata(dev, NULL);
> -free_cmap:
>  	fb_dealloc_cmap(&info->cmap);
>  unregister_irqs:
>  	cancel_work_sync(&sinfo->task);
> @@ -1249,6 +1428,7 @@ static struct platform_driver atmel_lcdfb_driver = {
>  	.driver		= {
>  		.name	= "atmel_lcdfb",
>  		.owner	= THIS_MODULE,
> +		.of_match_table	= of_match_ptr(atmel_lcdfb_dt_ids),
>  	},
>  };
>  
> 


-- 
Nicolas Ferre


From vinod.koul at intel.com  Tue Apr 16 09:15:19 2013
From: vinod.koul at intel.com (Vinod Koul)
Date: Tue, 16 Apr 2013 18:45:19 +0530
Subject: [PATCH] dmaengine: at_hdmac: fix race condition in
 atc_advance_work()
In-Reply-To: <1366112974-32043-1-git-send-email-nicolas.ferre@atmel.com>
References: <1366112974-32043-1-git-send-email-nicolas.ferre@atmel.com>
Message-ID: <20130416131519.GL12436@intel.com>

On Tue, Apr 16, 2013 at 01:49:34PM +0200, Nicolas Ferre wrote:
> From: Ludovic Desroches <ludovic.desroches at atmel.com>
> 
> The BUG_ON() directive is triggered probably due to a latency modification
> following inclusion of c10d736 (softirq: reduce latencies).
> This condition has not been met before 3.9-rc1 and doesn't trigger without
> this patch.
> 
> We now make sure that DMA channel is idle before calling atc_complete_all()
> which makes the BUG_ON() "protection" useless.
> 
> Signed-off-by: Ludovic Desroches <ludovic.desroches at atmel.com>
> Signed-off-by: Nicolas Ferre <nicolas.ferre at atmel.com>
Acked-by: Vinod Koul <vinod.koul at intel.com>
> ---
> Linus,
> 
> We have identified a race condition on the Atmel ARM-based AT91 DMA controller
> driver that leads to hitting a BUG_ON() directive.
> This error, only triggered after the inclusion of a patch that reduces the
> softirq latency, is affecting several AT91 SoCs and can be seen
> as a regression by people using the dmaengine driver (on NAND flash
> accesses for instance).
> 
> I know that it is late in the development cycle but can you please consider
> including it in your tree before 3.9-final?
> 
> This patch can also go through dmaengine tree (Vinod Koul) but I do not know if
> there is enough time remaining.
> 
> Thanks a lot, best regards,
> 
> Nicolas Ferre
> 
> 
>  drivers/dma/at_hdmac.c | 9 ++++-----
>  1 file changed, 4 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/dma/at_hdmac.c b/drivers/dma/at_hdmac.c
> index 6e13f26..88cfc61 100644
> --- a/drivers/dma/at_hdmac.c
> +++ b/drivers/dma/at_hdmac.c
> @@ -310,8 +310,6 @@ static void atc_complete_all(struct at_dma_chan *atchan)
>  
>  	dev_vdbg(chan2dev(&atchan->chan_common), "complete all\n");
>  
> -	BUG_ON(atc_chan_is_enabled(atchan));
> -
>  	/*
>  	 * Submit queued descriptors ASAP, i.e. before we go through
>  	 * the completed ones.
> @@ -368,6 +366,9 @@ static void atc_advance_work(struct at_dma_chan *atchan)
>  {
>  	dev_vdbg(chan2dev(&atchan->chan_common), "advance_work\n");
>  
> +	if (atc_chan_is_enabled(atchan))
> +		return;
> +
>  	if (list_empty(&atchan->active_list) ||
>  	    list_is_singular(&atchan->active_list)) {
>  		atc_complete_all(atchan);
> @@ -1078,9 +1079,7 @@ static void atc_issue_pending(struct dma_chan *chan)
>  		return;
>  
>  	spin_lock_irqsave(&atchan->lock, flags);
> -	if (!atc_chan_is_enabled(atchan)) {
> -		atc_advance_work(atchan);
> -	}
> +	atc_advance_work(atchan);
>  	spin_unlock_irqrestore(&atchan->lock, flags);
>  }
>  
> -- 
> 1.8.0
> 


From plagnioj at jcrosoft.com  Tue Apr 16 09:44:04 2013
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Tue, 16 Apr 2013 15:44:04 +0200
Subject: [PATCH 4/8] video: atmel_lcdfb: add device tree suport
In-Reply-To: <516D554C.1090909@atmel.com>
References: <20130411145741.GB25242@game.jcrosoft.org>
 <1365692422-9565-1-git-send-email-plagnioj@jcrosoft.com>
 <1365692422-9565-4-git-send-email-plagnioj@jcrosoft.com>
 <516D554C.1090909@atmel.com>
Message-ID: <20130416134404.GA4998@game.jcrosoft.org>

On 15:42 Tue 16 Apr     , Nicolas Ferre wrote:
> On 04/11/2013 05:00 PM, Jean-Christophe PLAGNIOL-VILLARD :
> > get display timings from device tree
> > Use videomode helpers to get display timings and configurations from
> > device tree
> 
> 2 sentences? Simply elaborate the 2nd one and it will be good.
> 
> > Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
> > Cc: linux-fbdev at vger.kernel.org
> > Cc: Nicolas Ferre <nicolas.ferre at atmel.com>
> > Cc: Andrew Morton <akpm at linux-foundation.org>
> > ---
> >  .../devicetree/bindings/video/atmel,lcdc.txt       |   75 ++++++
> >  drivers/video/Kconfig                              |    2 +
> >  drivers/video/atmel_lcdfb.c                        |  244 +++++++++++++++++---
> >  3 files changed, 289 insertions(+), 32 deletions(-)
> >  create mode 100644 Documentation/devicetree/bindings/video/atmel,lcdc.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/video/atmel,lcdc.txt b/Documentation/devicetree/bindings/video/atmel,lcdc.txt
> > new file mode 100644
> > index 0000000..1ec175e
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/video/atmel,lcdc.txt
> 
> Why lcdc? I would have preferred atmel,lcdfb, like the driver's name: it
> is even more self-explanatory...
we do not describe drivers but IP
> 
> > @@ -0,0 +1,75 @@
> > +Atmel LCDC Framebuffer
> > +-----------------------------------------------------
> > +
> > +Required properties:
> > +- compatible :
> > +	"atmel,at91sam9261-lcdc" , 
> > +	"atmel,at91sam9263-lcdc" ,
> > +	"atmel,at91sam9g10-lcdc" ,
> > +	"atmel,at91sam9g45-lcdc" ,
> > +	"atmel,at91sam9g45es-lcdc" ,
> > +	"atmel,at91sam9rl-lcdc" ,
> > +	"atmel,at32ap-lcdc"
> > +- reg : Should contain 1 register ranges(address and length)
> > +- interrupts : framebuffer controller interrupt
> > +- display: a phandle pointing to the display node
> > +
> > +Required nodes:
> > +- display: a display node is required to initialize the lcd panel
> > +	This should be in the board dts.
> > +- default-mode: a videomode within the display with timing parameters
> > +	as specified below.
> > +
> > +Example:
> > +
> > +	fb0: fb at 0x00500000 {
> > +		compatible = "atmel,at91sam9g45-lcdc";
> > +		reg = <0x00500000 0x1000>;
> > +		interrupts = <23 3 0>;
> > +		pinctrl-names = "default";
> > +		pinctrl-0 = <&pinctrl_fb>;
> > +		display = <&display0>;
> > +		status = "okay";
> > +		#address-cells = <1>;
> > +		#size-cells = <1>;
> > +
> > +	};
> > +
> > +Atmel LCDC Display
> > +-----------------------------------------------------
> > +Required properties (as per of_videomode_helper):
> 
> Can you please point somewhere to the documentation:
> Documentation/devicetree/bindings/video/display-timing.txt
> 
> > + - atmel,dmacon: dma controler configuration
> 
> Typo: controller.
> 
> > + - atmel,lcdcon2: lcd controler configuration
> 
> Ditto
> 
> > + - atmel,guard-time: lcd guard time (Delay in frame periods)
> 
> periods -> period, no?
no it's periods even in the datasheet
> 
> > + - bits-per-pixel: lcd panel bit-depth.
> > +
> > +Optional properties (as per of_videomode_helper):
> > + - atmel,lcdcon-backlight: enable backlight
> > + - atmel,lcd-wiring-mode: lcd wiring mode "RGB" or "BRG"
> 
> Is it a sting, or a number (as seen below)? If it is a number, please
> tell how to choose the index.
String
> 
> 
> > + - atmel,power-control-gpio: gpio to power on or off the LCD (as many as needed)
> > +
> > +Example:
> > +	display0: display {
> > +		bits-per-pixel = <32>;
> > +		atmel,lcdcon-backlight;
> > +		atmel,dmacon = <0x1>;
> > +		atmel,lcdcon2 = <0x80008002>;
> > +		atmel,guard-time = <9>;
> > +		atmel,lcd-wiring-mode = <1>;
> > +
> > +		display-timings {
> > +			native-mode = <&timing0>;
> > +			timing0: timing0 {
> > +				clock-frequency = <9000000>;
> > +				hactive = <480>;
> > +				vactive = <272>;
> > +				hback-porch = <1>;
> > +				hfront-porch = <1>;
> > +				vback-porch = <40>;
> > +				vfront-porch = <1>;
> > +				hsync-len = <45>;
> > +				vsync-len = <1>;
> > +			};
> > +		};
> > +	};
> > diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> > index 4c1546f..0687482 100644
> > --- a/drivers/video/Kconfig
> > +++ b/drivers/video/Kconfig
> > @@ -1018,6 +1018,8 @@ config FB_ATMEL
> >  	select FB_CFB_FILLRECT
> >  	select FB_CFB_COPYAREA
> >  	select FB_CFB_IMAGEBLIT
> > +	select FB_MODE_HELPERS
> > +	select OF_VIDEOMODE
> >  	help
> >  	  This enables support for the AT91/AT32 LCD Controller.
> >  
> > diff --git a/drivers/video/atmel_lcdfb.c b/drivers/video/atmel_lcdfb.c
> > index f67e226..4a31570 100644
> > --- a/drivers/video/atmel_lcdfb.c
> > +++ b/drivers/video/atmel_lcdfb.c
> > @@ -20,7 +20,11 @@
> >  #include <linux/gfp.h>
> >  #include <linux/module.h>
> >  #include <linux/platform_data/atmel.h>
> > +#include <linux/of.h>
> > +#include <linux/of_device.h>
> > +#include <linux/of_gpio.h>
> >  #include <video/of_display_timing.h>
> 
> As said in patch 1/8, this one belongs to this 4/8 patch.
> 
> > +#include <video/videomode.h>
> >  
> >  #include <mach/cpu.h>
> >  #include <asm/gpio.h>
> > @@ -59,6 +63,13 @@ struct atmel_lcdfb_info {
> >  	struct atmel_lcdfb_config *config;
> >  };
> >  
> > +struct atmel_lcdfb_power_ctrl_gpio {
> > +	int gpio;
> > +	int active_low;
> > +
> > +	struct list_head list;
> > +};
> > +
> >  #define lcdc_readl(sinfo, reg)		__raw_readl((sinfo)->mmio+(reg))
> >  #define lcdc_writel(sinfo, reg, val)	__raw_writel((val), (sinfo)->mmio+(reg))
> >  
> > @@ -945,16 +956,187 @@ static void atmel_lcdfb_stop_clock(struct atmel_lcdfb_info *sinfo)
> >  	clk_disable(sinfo->lcdc_clk);
> >  }
> >  
> > +#ifdef CONFIG_OF
> > +static const struct of_device_id atmel_lcdfb_dt_ids[] = {
> > +	{ .compatible = "atmel,at91sam9261-lcdc" , .data = &at91sam9261_config, },
> > +	{ .compatible = "atmel,at91sam9263-lcdc" , .data = &at91sam9263_config, },
> > +	{ .compatible = "atmel,at91sam9g10-lcdc" , .data = &at91sam9g10_config, },
> > +	{ .compatible = "atmel,at91sam9g45-lcdc" , .data = &at91sam9g45_config, },
> > +	{ .compatible = "atmel,at91sam9g45es-lcdc" , .data = &at91sam9g45es_config, },
> > +	{ .compatible = "atmel,at91sam9rl-lcdc" , .data = &at91sam9rl_config, },
> > +	{ .compatible = "atmel,at32ap-lcdc" , .data = &at32ap_config, },
> > +	{ /* sentinel */ }
> > +};
> > +
> > +MODULE_DEVICE_TABLE(of, atmel_lcdfb_dt_ids);
> > +
> > +static const char *atmel_lcdfb_wiring_modes[] = {
> > +	[ATMEL_LCDC_WIRING_BGR]	= "BRG",
> > +	[ATMEL_LCDC_WIRING_RGB]	= "RGB",
> > +};
> > +
> > +const int atmel_lcdfb_get_of_wiring_modes(struct device_node *np)
> > +{
> > +	const char *mode;
> > +	int err, i;
> > +
> > +	err = of_property_read_string(np, "atmel,lcd-wiring-mode", &mode);
> > +	if (err < 0)
> > +		return ATMEL_LCDC_WIRING_BGR;
> > +
> > +	for (i = 0; i < ARRAY_SIZE(atmel_lcdfb_wiring_modes); i++)
> > +		if (!strcasecmp(mode, atmel_lcdfb_wiring_modes[i]))
> > +			return i;
> > +
> > +	return -ENODEV;
> > +}
> > +
> > +static void atmel_lcdfb_power_control_gpio(struct atmel_lcdfb_pdata *pdata, int on)
> > +{
> > +	struct atmel_lcdfb_power_ctrl_gpio *og;
> > +
> > +	list_for_each_entry(og, &pdata->pwr_gpios, list)
> > +		gpio_set_value(og->gpio, on);
> > +}
> > +
> > +static int atmel_lcdfb_of_init(struct atmel_lcdfb_info *sinfo)
> > +{
> > +	struct fb_info *info = sinfo->info;
> > +	struct atmel_lcdfb_pdata *pdata = &sinfo->pdata;
> > +	struct fb_var_screeninfo *var = &info->var;
> > +	struct device *dev = &sinfo->pdev->dev;
> > +	struct device_node *np =dev->of_node;
> > +	struct device_node *display_np;
> > +	struct device_node *timings_np;
> > +	struct display_timings *timings;
> > +	enum of_gpio_flags flags;
> > +	struct atmel_lcdfb_power_ctrl_gpio *og;
> > +	bool is_gpio_power = false;
> > +	int ret = -ENOENT;
> > +	int i, gpio;
> > +
> > +	sinfo->config = (struct atmel_lcdfb_config*)
> > +		of_match_device(atmel_lcdfb_dt_ids, dev)->data;
> 
> Please split it in 2 steps, otherwise the day that the drivers doesn't
> find the device in dt_ids table, it hangs here with an Oops.
no as you will never end here in this case
> 
> > +
> > +	display_np = of_parse_phandle(np, "display", 0);
> > +	if (!display_np) {
> > +		dev_err(dev, "failed to find display phandle\n");
> > +		return -ENOENT;
> > +	}
> > +
> > +	ret = of_property_read_u32(display_np, "bits-per-pixel", &var->bits_per_pixel);
> > +	if (ret < 0) {
> > +		dev_err(dev, "failed to get property bits-per-pixel\n");
> > +		goto put_display_node;
> > +	}
> > +
> > +	ret = of_property_read_u32(display_np, "atmel,guard-time", &pdata->guard_time);
> > +	if (ret < 0) {
> > +		dev_err(dev, "failed to get property atmel,guard-time\n");
> > +		goto put_display_node;
> > +	}
> > +
> > +	ret = of_property_read_u32(display_np, "atmel,lcdcon2", &pdata->default_lcdcon2);
> > +	if (ret < 0) {
> > +		dev_err(dev, "failed to get property atmel,lcdcon2\n");
> > +		goto put_display_node;
> > +	}
> > +
> > +	ret = of_property_read_u32(display_np, "atmel,dmacon", &pdata->default_dmacon);
> > +	if (ret < 0) {
> > +		dev_err(dev, "failed to get property bits-per-pixel\n");
> 
> No, wrong error message.
> 
> > +		goto put_display_node;
> > +	}
> > +
> > +	ret = -ENOMEM;
> > +	for (i = 0; i < of_gpio_named_count(display_np, "atmel,power-control-gpio"); i++) {
> > +		gpio = of_get_named_gpio_flags(display_np, "atmel,power-control-gpio",
> > +					       i, &flags);
> > +		if (gpio < 0)
> > +			continue;
> > +
> > +		og = devm_kzalloc(dev, sizeof(*og), GFP_KERNEL);
> > +		if (!og)
> > +			goto put_display_node;
> > +
> > +		og->gpio = gpio;
> > +		og->active_low = flags & OF_GPIO_ACTIVE_LOW;
> > +		is_gpio_power = true;
> > +		ret = devm_gpio_request(dev, gpio, "lcd-power-control-gpio");
> > +		if (ret) {
> > +			dev_err(dev, "request gpio %d failed\n", gpio);
> > +			goto put_display_node;
> > +		}
> > +
> > +		ret = gpio_direction_output(gpio, og->active_low);
> > +		if (ret) {
> > +			dev_err(dev, "set direction output gpio %d failed\n", gpio);
> > +			goto put_display_node;
> > +		}
> > +	}
> > +
> > +	if (is_gpio_power)
> > +		pdata->atmel_lcdfb_power_control = atmel_lcdfb_power_control_gpio;
> > +
> > +	ret = atmel_lcdfb_get_of_wiring_modes(display_np);
> > +	if (ret < 0) {
> > +		dev_err(dev, "invalid atmel,lcd-wiring-mode\n");
> > +		goto put_display_node;
> > +	}
> > +	pdata->lcd_wiring_mode = ret;
> > +
> > +	pdata->lcdcon_is_backlight = of_property_read_bool(display_np, "atmel,lcdcon-backlight");
> > +
> > +	timings = of_get_display_timings(display_np);
> > +	if (!timings) {
> > +		dev_err(dev, "failed to get display timings\n");
> > +		goto put_display_node;
> > +	}
> > +
> > +	timings_np = of_find_node_by_name(display_np, "display-timings");
> > +	if (!timings_np) {
> > +		dev_err(dev, "failed to find display-timings node\n");
> > +		goto put_display_node;
> > +	}
> > +
> > +	for (i = 0; i < of_get_child_count(timings_np); i++) {
> > +		struct videomode vm;
> > +		struct fb_videomode fb_vm;
> > +
> > +		ret = videomode_from_timing(timings, &vm, i);
> > +		if (ret < 0)
> > +			goto put_timings_node;
> > +		ret = fb_videomode_from_videomode(&vm, &fb_vm);
> > +		if (ret < 0)
> > +			goto put_timings_node;
> > +
> > +		fb_add_videomode(&fb_vm, &info->modelist);
> > +	}
> > +
> > +	return 0;
> > +
> > +put_timings_node:
> > +	of_node_put(timings_np);
> > +put_display_node:
> > +	of_node_put(display_np);
> > +	return ret;
> > +}
> > +#else
> > +static int atmel_lcdfb_of_init(struct atmel_lcdfb_info *sinfo)
> > +{
> > +	return 0;
> > +}
> > +#endif
> >  
> >  static int __init atmel_lcdfb_probe(struct platform_device *pdev)
> >  {
> >  	struct device *dev = &pdev->dev;
> >  	struct fb_info *info;
> >  	struct atmel_lcdfb_info *sinfo;
> > -	struct atmel_lcdfb_pdata *pdata;
> > -	struct fb_videomode fbmode;
> > +	struct atmel_lcdfb_pdata *pdata = NULL;
> >  	struct resource *regs = NULL;
> >  	struct resource *map = NULL;
> > +	struct fb_modelist *modelist;
> >  	int ret;
> >  
> >  	dev_dbg(dev, "%s BEGIN\n", __func__);
> > @@ -967,17 +1149,35 @@ static int __init atmel_lcdfb_probe(struct platform_device *pdev)
> >  	}
> >  
> >  	sinfo = info->par;
> > +	sinfo->pdev = pdev;
> > +	sinfo->info = info;
> > +
> > +	INIT_LIST_HEAD(&info->modelist);
> >  
> > -	if (dev->platform_data) {
> > -		pdata = (struct atmel_lcdfb_pdata *)dev->platform_data;
> > +	if (pdev->dev.of_node) {
> > +		ret = atmel_lcdfb_of_init(sinfo);
> > +		if (ret)
> > +			goto free_info;
> > +	} else if (dev->platform_data) {
> > +		struct fb_monspecs *monspecs;
> > +		int i;
> > +
> > +		pdata = dev->platform_data;
> > +		monspecs = pdata->default_monspecs;
> >  		sinfo->pdata = *pdata;
> > +
> > +		for (i = 0; i < monspecs->modedb_len; i++)
> > +			fb_add_videomode(&monspecs->modedb[i], &info->modelist);
> > +
> > +		sinfo->config = atmel_lcdfb_get_config(pdev);
> > +
> > +		info->var.bits_per_pixel = pdata->default_bpp ? pdata->default_bpp : 16;
> > +		memcpy(&info->monspecs, pdata->default_monspecs, sizeof(info->monspecs));
> >  	} else {
> >  		dev_err(dev, "cannot get default configuration\n");
> >  		goto free_info;
> >  	}
> > -	sinfo->info = info;
> > -	sinfo->pdev = pdev;
> > -	sinfo->config = atmel_lcdfb_get_config(pdev);
> > +
> >  	if (!sinfo->config)
> >  		goto free_info;
> >  
> > @@ -986,7 +1186,6 @@ static int __init atmel_lcdfb_probe(struct platform_device *pdev)
> >  	info->pseudo_palette = sinfo->pseudo_palette;
> >  	info->fbops = &atmel_lcdfb_ops;
> >  
> > -	memcpy(&info->monspecs, pdata->default_monspecs, sizeof(info->monspecs));
> >  	info->fix = atmel_lcdfb_fix;
> >  
> >  	/* Enable LCDC Clocks */
> > @@ -1002,14 +1201,11 @@ static int __init atmel_lcdfb_probe(struct platform_device *pdev)
> >  	}
> >  	atmel_lcdfb_start_clock(sinfo);
> >  
> > -	ret = fb_find_mode(&info->var, info, NULL, info->monspecs.modedb,
> > -			info->monspecs.modedb_len, info->monspecs.modedb,
> > -			pdata->default_bpp);
> > -	if (!ret) {
> > -		dev_err(dev, "no suitable video mode found\n");
> > -		goto stop_clk;
> > -	}
> > +	modelist = list_first_entry(&info->modelist,
> > +			struct fb_modelist, list);
> > +	fb_videomode_to_var(&info->var, &modelist->mode);
> >  
> > +	atmel_lcdfb_check_var(&info->var, info);
> >  
> >  	regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> >  	if (!regs) {
> > @@ -1093,18 +1289,6 @@ static int __init atmel_lcdfb_probe(struct platform_device *pdev)
> >  		goto unregister_irqs;
> >  	}
> >  
> > -	/*
> > -	 * This makes sure that our colour bitfield
> > -	 * descriptors are correctly initialised.
> > -	 */
> > -	atmel_lcdfb_check_var(&info->var, info);
> > -
> > -	ret = fb_set_var(info, &info->var);
> > -	if (ret) {
> > -		dev_warn(dev, "unable to set display parameters\n");
> > -		goto free_cmap;
> > -	}
> > -
> >  	dev_set_drvdata(dev, info);
> >  
> >  	/*
> > @@ -1116,10 +1300,6 @@ static int __init atmel_lcdfb_probe(struct platform_device *pdev)
> >  		goto reset_drvdata;
> >  	}
> >  
> > -	/* add selected videomode to modelist */
> > -	fb_var_to_videomode(&fbmode, &info->var);
> > -	fb_add_videomode(&fbmode, &info->modelist);
> > -
> >  	/* Power up the LCDC screen */
> >  	atmel_lcdfb_power_control(sinfo, 1);
> >  
> > @@ -1130,7 +1310,6 @@ static int __init atmel_lcdfb_probe(struct platform_device *pdev)
> >  
> >  reset_drvdata:
> >  	dev_set_drvdata(dev, NULL);
> > -free_cmap:
> >  	fb_dealloc_cmap(&info->cmap);
> >  unregister_irqs:
> >  	cancel_work_sync(&sinfo->task);
> > @@ -1249,6 +1428,7 @@ static struct platform_driver atmel_lcdfb_driver = {
> >  	.driver		= {
> >  		.name	= "atmel_lcdfb",
> >  		.owner	= THIS_MODULE,
> > +		.of_match_table	= of_match_ptr(atmel_lcdfb_dt_ids),
> >  	},
> >  };
> >  
> > 
> 
> 
> -- 
> Nicolas Ferre


From catalin.marinas at arm.com  Tue Apr 16 09:48:56 2013
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Tue, 16 Apr 2013 14:48:56 +0100
Subject: [RFC PATCH 1/3] pstore-ram: use write-combine mappings
In-Reply-To: <516D4AF3.5060205@gmail.com>
References: <1365563297-12480-1-git-send-email-robherring2@gmail.com>
 <CAMbhsRSvQPbzJ7Nt=OSSYE_A1e+eaUjO7XY+qRppJ5_gfWmW4A@mail.gmail.com>
 <51656992.60203@gmail.com>
 <CAMbhsRS1hnBRoomoiNijrXZB-938d2RSs1cu9EdSfmXD3xpSQg@mail.gmail.com>
 <516C9454.4060009@gmail.com>
 <CAMbhsRRT7tOBHppvjJEW5wRtVaUhwxr8=YQY=Sy0VAFeBg1JmQ@mail.gmail.com>
 <20130416084418.GA30756@mudshark.cambridge.arm.com>
 <516D4AF3.5060205@gmail.com>
Message-ID: <20130416134856.GB30292@arm.com>

On Tue, Apr 16, 2013 at 01:58:27PM +0100, Rob Herring wrote:
> On 04/16/2013 03:44 AM, Will Deacon wrote:
> > On Tue, Apr 16, 2013 at 01:43:09AM +0100, Colin Cross wrote:
> >> On Mon, Apr 15, 2013 at 4:59 PM, Rob Herring <robherring2 at gmail.com> wrote:
> >>> Exclusive accesses still have further restrictions. From section 3.4.5:
> >>>
> >>> ? It is IMPLEMENTATION DEFINED whether LDREX and STREX operations can be
> >>> performed to a memory region
> >>>    with the Device or Strongly-ordered memory attribute. Unless the
> >>> implementation documentation explicitly
> >>>   states that LDREX and STREX operations to a memory region with the
> >>> Device or Strongly-ordered attribute are
> >>>  permitted, the effect of such operations is UNPREDICTABLE.
> >>>
> >>>
> >>> Given that it is implementation defined, I don't see how Linux can rely
> >>> on that behavior.
> >>
> >> I see, the problem is that while noncached and writecombined appear to
> >> be similar mappings, noncached is mapped in PRRR to strongly-ordered,
> >> while writecombined is mapped to unbufferable normal memory.
> >>
> >> I think adding a wmb() to persistent_ram_write is going to be
> >> expensive on cpus with outer caches like the L2X0, where wmb() will
> >> result in a spinlock.  Is there a real SoC where this doesn't work?
> > 
> > A real SoC where exclusives don't work to memory not mapped as normal? Take
> > your pick...
> 
> This patch doesn't actually fix problems for me. Exclusives to DDR work
> for any memory type for me as the DDR controller has an exclusive
> monitor. It takes write-thru cache mapping to get internal RAM to work.

I can't find any reference in the ARM ARM but I think you would need
cacheable memory for the exclusives to work. A9 for example uses the
cacheline exclusiveness to emulate the global monitor.

-- 
Catalin


From nicolas.ferre at atmel.com  Tue Apr 16 09:57:06 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Tue, 16 Apr 2013 15:57:06 +0200
Subject: [PATCH 5/8] ARM: at91: sam9g45: add lcd support
In-Reply-To: <1365692422-9565-5-git-send-email-plagnioj@jcrosoft.com>
References: <20130411145741.GB25242@game.jcrosoft.org>
 <1365692422-9565-1-git-send-email-plagnioj@jcrosoft.com>
 <1365692422-9565-5-git-send-email-plagnioj@jcrosoft.com>
Message-ID: <516D58B2.7010305@atmel.com>

On 04/11/2013 05:00 PM, Jean-Christophe PLAGNIOL-VILLARD :
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
> Cc: Nicolas Ferre <nicolas.ferre at atmel.com>
> ---
>  arch/arm/boot/dts/at91sam9g45.dtsi |   47 ++++++++++++++++++++++++++++++++++++
>  1 file changed, 47 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/at91sam9g45.dtsi b/arch/arm/boot/dts/at91sam9g45.dtsi
> index 6b1d4ca..ab8a8fc 100644
> --- a/arch/arm/boot/dts/at91sam9g45.dtsi
> +++ b/arch/arm/boot/dts/at91sam9g45.dtsi
> @@ -322,6 +322,42 @@
>  					};
>  				};
>  
> +				fb {
> +					pinctrl_fb: fb-0 {
> +						atmel,pins =
> +							<4 0 0x1 0x0	/* PE0 periph A */
> +							 4 2 0x1 0x0	/* PE2 periph A */
> +							 4 3 0x1 0x0	/* PE3 periph A */
> +							 4 4 0x1 0x0	/* PE4 periph A */
> +							 4 5 0x1 0x0	/* PE5 periph A */
> +							 4 6 0x1 0x0	/* PE6 periph A */
> +							 4 7 0x1 0x0	/* PE7 periph A */
> +							 4 8 0x1 0x0	/* PE8 periph A */
> +							 4 9 0x1 0x0	/* PE9 periph A */
> +							 4 10 0x1 0x0	/* PE10 periph A */
> +							 4 11 0x1 0x0	/* PE11 periph A */
> +							 4 12 0x1 0x0	/* PE12 periph A */
> +							 4 13 0x1 0x0	/* PE13 periph A */
> +							 4 14 0x1 0x0	/* PE14 periph A */
> +							 4 15 0x1 0x0	/* PE15 periph A */
> +							 4 16 0x1 0x0	/* PE16 periph A */
> +							 4 17 0x1 0x0	/* PE17 periph A */
> +							 4 18 0x1 0x0	/* PE18 periph A */
> +							 4 19 0x1 0x0	/* PE19 periph A */
> +							 4 20 0x1 0x0	/* PE20 periph A */
> +							 4 21 0x1 0x0	/* PE21 periph A */
> +							 4 22 0x1 0x0	/* PE22 periph A */
> +							 4 23 0x1 0x0	/* PE23 periph A */
> +							 4 24 0x1 0x0	/* PE24 periph A */
> +							 4 25 0x1 0x0	/* PE25 periph A */
> +							 4 26 0x1 0x0	/* PE26 periph A */
> +							 4 27 0x1 0x0	/* PE27 periph A */
> +							 4 28 0x1 0x0	/* PE28 periph A */
> +							 4 29 0x1 0x0	/* PE29 periph A */
> +							 4 30 0x1 0x0>;	/* PE30 periph A */

Verified, correct.

> +					};
> +				};
> +
>  				pioA: gpio at fffff200 {
>  					compatible = "atmel,at91rm9200-gpio";
>  					reg = <0xfffff200 0x200>;
> @@ -533,6 +569,17 @@
>  			};
>  		};
>  
> +		fb0: fb at 0x00500000 {
> +			compatible = "atmel,at91sam9g45-lcdc";

If we change to "atmel,at91sam9g45-lcdfb", we will have to change this
as-well.

> +			reg = <0x00500000 0x1000>;
> +			interrupts = <23 3 0>;
> +			pinctrl-names = "default";
> +			pinctrl-0 = <&pinctrl_fb>;
> +			status = "disabled";

> +			#address-cells = <1>;
> +			#size-cells = <1>;

I do not think we need these 2 properties: is a "reg" property existing
in child nodes?

> +		};
> +
>  		nand0: nand at 40000000 {
>  			compatible = "atmel,at91rm9200-nand";
>  			#address-cells = <1>;
> 


-- 
Nicolas Ferre


From nicolas.ferre at atmel.com  Tue Apr 16 10:00:49 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Tue, 16 Apr 2013 16:00:49 +0200
Subject: [PATCH 5/8] ARM: at91: sam9g45: add lcd support
In-Reply-To: <1365692422-9565-5-git-send-email-plagnioj@jcrosoft.com>
References: <20130411145741.GB25242@game.jcrosoft.org>
 <1365692422-9565-1-git-send-email-plagnioj@jcrosoft.com>
 <1365692422-9565-5-git-send-email-plagnioj@jcrosoft.com>
Message-ID: <516D5991.8020603@atmel.com>

On 04/11/2013 05:00 PM, Jean-Christophe PLAGNIOL-VILLARD :
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
> Cc: Nicolas Ferre <nicolas.ferre at atmel.com>
> ---
>  arch/arm/boot/dts/at91sam9g45.dtsi |   47 ++++++++++++++++++++++++++++++++++++
>  1 file changed, 47 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/at91sam9g45.dtsi b/arch/arm/boot/dts/at91sam9g45.dtsi
> index 6b1d4ca..ab8a8fc 100644
> --- a/arch/arm/boot/dts/at91sam9g45.dtsi
> +++ b/arch/arm/boot/dts/at91sam9g45.dtsi
> @@ -322,6 +322,42 @@
>  					};
>  				};
>  
> +				fb {
> +					pinctrl_fb: fb-0 {
> +						atmel,pins =
> +							<4 0 0x1 0x0	/* PE0 periph A */
> +							 4 2 0x1 0x0	/* PE2 periph A */
> +							 4 3 0x1 0x0	/* PE3 periph A */
> +							 4 4 0x1 0x0	/* PE4 periph A */
> +							 4 5 0x1 0x0	/* PE5 periph A */
> +							 4 6 0x1 0x0	/* PE6 periph A */
> +							 4 7 0x1 0x0	/* PE7 periph A */
> +							 4 8 0x1 0x0	/* PE8 periph A */
> +							 4 9 0x1 0x0	/* PE9 periph A */
> +							 4 10 0x1 0x0	/* PE10 periph A */
> +							 4 11 0x1 0x0	/* PE11 periph A */
> +							 4 12 0x1 0x0	/* PE12 periph A */
> +							 4 13 0x1 0x0	/* PE13 periph A */
> +							 4 14 0x1 0x0	/* PE14 periph A */
> +							 4 15 0x1 0x0	/* PE15 periph A */
> +							 4 16 0x1 0x0	/* PE16 periph A */
> +							 4 17 0x1 0x0	/* PE17 periph A */
> +							 4 18 0x1 0x0	/* PE18 periph A */
> +							 4 19 0x1 0x0	/* PE19 periph A */
> +							 4 20 0x1 0x0	/* PE20 periph A */
> +							 4 21 0x1 0x0	/* PE21 periph A */
> +							 4 22 0x1 0x0	/* PE22 periph A */
> +							 4 23 0x1 0x0	/* PE23 periph A */
> +							 4 24 0x1 0x0	/* PE24 periph A */
> +							 4 25 0x1 0x0	/* PE25 periph A */
> +							 4 26 0x1 0x0	/* PE26 periph A */
> +							 4 27 0x1 0x0	/* PE27 periph A */
> +							 4 28 0x1 0x0	/* PE28 periph A */
> +							 4 29 0x1 0x0	/* PE29 periph A */
> +							 4 30 0x1 0x0>;	/* PE30 periph A */
> +					};
> +				};
> +
>  				pioA: gpio at fffff200 {
>  					compatible = "atmel,at91rm9200-gpio";
>  					reg = <0xfffff200 0x200>;
> @@ -533,6 +569,17 @@
>  			};
>  		};
>  
> +		fb0: fb at 0x00500000 {
> +			compatible = "atmel,at91sam9g45-lcdc";
> +			reg = <0x00500000 0x1000>;
> +			interrupts = <23 3 0>;

Error: here, it is <23 4 0>

> +			pinctrl-names = "default";
> +			pinctrl-0 = <&pinctrl_fb>;
> +			status = "disabled";
> +			#address-cells = <1>;
> +			#size-cells = <1>;
> +		};
> +
>  		nand0: nand at 40000000 {
>  			compatible = "atmel,at91rm9200-nand";
>  			#address-cells = <1>;
> 


-- 
Nicolas Ferre


From nicolas.ferre at atmel.com  Tue Apr 16 10:11:18 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Tue, 16 Apr 2013 16:11:18 +0200
Subject: [PATCH 6/8] ARM: at91: sam9263: add fb dt support
In-Reply-To: <1365692422-9565-6-git-send-email-plagnioj@jcrosoft.com>
References: <20130411145741.GB25242@game.jcrosoft.org>
 <1365692422-9565-1-git-send-email-plagnioj@jcrosoft.com>
 <1365692422-9565-6-git-send-email-plagnioj@jcrosoft.com>
Message-ID: <516D5C06.1050807@atmel.com>

On 04/11/2013 05:00 PM, Jean-Christophe PLAGNIOL-VILLARD :
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
> Cc: Nicolas Ferre <nicolas.ferre at atmel.com>
> ---
>  arch/arm/boot/dts/at91sam9263.dtsi |   39 ++++++++++++++++++++++++++++++++++++
>  1 file changed, 39 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/at91sam9263.dtsi b/arch/arm/boot/dts/at91sam9263.dtsi
> index 271d4de..3d0effa 100644
> --- a/arch/arm/boot/dts/at91sam9263.dtsi
> +++ b/arch/arm/boot/dts/at91sam9263.dtsi
> @@ -303,6 +303,34 @@
>  					};
>  				};
>  
> +				fb {
> +					pinctrl_fb: fb-0 {
> +						atmel,pins =
> +							<2 1 0x1 0x0	/* PC1 periph A */
> +							 2 2 0x1 0x0	/* PC2 periph A */
> +							 2 3 0x1 0x0	/* PC3 periph A */
> +							 1 9 0x2 0x0	/* PB9 periph B */
> +							 2 6 0x1 0x0	/* PC6 periph A */
> +							 2 7 0x1 0x0	/* PC7 periph A */
> +							 2 8 0x1 0x0	/* PC8 periph A */
> +							 2 9 0x1 0x0	/* PC9 periph A */
> +							 2 10 0x1 0x0	/* PC10 periph A */
> +							 2 11 0x1 0x0	/* PC11 periph A */
> +							 2 14 0x1 0x0	/* PC14 periph A */
> +							 2 15 0x1 0x0	/* PC15 periph A */
> +							 2 16 0x1 0x0	/* PC16 periph A */
> +							 2 12 0x2 0x0	/* PC12 periph B */
> +							 2 18 0x1 0x0	/* PC18 periph A */
> +							 2 19 0x1 0x0	/* PC19 periph A */
> +							 2 22 0x1 0x0	/* PC22 periph A */
> +							 2 23 0x1 0x0	/* PC23 periph A */
> +							 2 24 0x1 0x0	/* PC24 periph A */
> +							 2 17 0x2 0x0	/* PC17 periph B */
> +							 2 26 0x1 0x0	/* PC26 periph A */
> +							 2 27 0x1 0x0>;	/* PC27 periph A */

Verified, okay.

> +					};
> +				};
> +
>  				pioA: gpio at fffff200 {
>  					compatible = "atmel,at91rm9200-gpio";
>  					reg = <0xfffff200 0x200>;
> @@ -464,6 +492,17 @@
>  			};
>  		};
>  
> +		fb0: fb at 0x00500000 {

No, it is 0x700000

> +			compatible = "atmel,at91sam9263-lcdc";
> +			reg = <0x00700000 0x1000>;

Ditto.

> +			interrupts = <26 3 0>;

<26 4 0> here.


> +			pinctrl-names = "default";
> +			pinctrl-0 = <&pinctrl_fb>;
> +			status = "disabled";
> +			#address-cells = <1>;
> +			#size-cells = <1>;

Ditto in 9g45 case.

> +		};
> +
>  		nand0: nand at 40000000 {
>  			compatible = "atmel,at91rm9200-nand";
>  			#address-cells = <1>;
> 


-- 
Nicolas Ferre


From dave.martin at linaro.org  Tue Apr 16 10:13:24 2013
From: dave.martin at linaro.org (Dave Martin)
Date: Tue, 16 Apr 2013 15:13:24 +0100
Subject: [PATCH 3/3] ARM: tegra: make sure the pointer on 4 byte align
 when THUMB2_KERNEL enabled
In-Reply-To: <1366066255-18192-3-git-send-email-swarren@wwwdotorg.org>
References: <1366066255-18192-1-git-send-email-swarren@wwwdotorg.org>
 <1366066255-18192-3-git-send-email-swarren@wwwdotorg.org>
Message-ID: <20130416141252.GA2229@linaro.org>

On Mon, Apr 15, 2013 at 04:50:55PM -0600, Stephen Warren wrote:
> From: Joseph Lo <josephl at nvidia.com>
> 
> When building kernel with CONFIG_THUMB2_KERNEL, the data pointer in the
> assembly may not on the 4 byte alignment. Then causing a data abort when
> accessing the pointer. This patch add a ".align" flag in the head of the
> pointer. And always using 32-bit ADR Thumb instruction to make sure it
> won't build failure.
> 
> Signed-off-by: Joseph Lo <josephl at nvidia.com>
> Signed-off-by: Stephen Warren <swarren at nvidia.com>
> ---
>  arch/arm/mach-tegra/reset-handler.S |    1 +
>  arch/arm/mach-tegra/sleep.h         |    3 ++-
>  2 files changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-tegra/reset-handler.S b/arch/arm/mach-tegra/reset-handler.S
> index e6de88a..519a8c5 100644
> --- a/arch/arm/mach-tegra/reset-handler.S
> +++ b/arch/arm/mach-tegra/reset-handler.S
> @@ -83,6 +83,7 @@ ENDPROC(tegra_resume)
>  
>  #ifdef CONFIG_CACHE_L2X0
>  	.globl	l2x0_saved_regs_addr
> +	.align
>  l2x0_saved_regs_addr:
>  	.long	0
>  #endif
> diff --git a/arch/arm/mach-tegra/sleep.h b/arch/arm/mach-tegra/sleep.h
> index 4ffae54..8e9b6af 100644
> --- a/arch/arm/mach-tegra/sleep.h
> +++ b/arch/arm/mach-tegra/sleep.h
> @@ -92,7 +92,8 @@
>  
>  #ifdef CONFIG_CACHE_L2X0
>  .macro l2_cache_resume, tmp1, tmp2, tmp3, phys_l2x0_saved_regs
> -	adr	\tmp1, \phys_l2x0_saved_regs
> + ARM(	adr	\tmp1, \phys_l2x0_saved_regs )
> + THUMB(	adr.w	\tmp1, \phys_l2x0_saved_regs )

Can you give an example of the assembler error you get without this?

The target symbol is local and the assembler can see where it is,
so it should choose the correct variant for the adr instruction
with no need for the ".w" suffix.

If not, it could mean that there is a bug in the version of the
assembler you're using.


If it's definitely needed, you can append a Thumb-only .w suffix with

	W(adr)	\tmp1, \phys_l2x0_saved_regs

...which is slightly neater.

Cheers
---Dave

>  	ldr	\tmp1, [\tmp1]
>  	ldr	\tmp2, [\tmp1, #L2X0_R_PHY_BASE]
>  	ldr	\tmp3, [\tmp2, #L2X0_CTRL]
> -- 
> 1.7.10.4
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From mpa at pengutronix.de  Tue Apr 16 10:17:29 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Tue, 16 Apr 2013 16:17:29 +0200
Subject: [PATCH v3 2/2] video: imxfb: Add DT support
In-Reply-To: <20130415132322.GC15139@game.jcrosoft.org>
References: <1365157876-1757-1-git-send-email-mpa@pengutronix.de>
 <1365157876-1757-3-git-send-email-mpa@pengutronix.de>
 <20130408075742.GR20693@game.jcrosoft.org>
 <20130414143132.GD27394@pengutronix.de>
 <20130415124321.GB15139@game.jcrosoft.org>
 <20130415151316.4d49e9b2@e6520eb>
 <20130415132322.GC15139@game.jcrosoft.org>
Message-ID: <20130416141729.GC13272@pengutronix.de>

On Mon, Apr 15, 2013 at 03:23:22PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 15:13 Mon 15 Apr     , Eric B?nard wrote:
> > Hi,
> > 
> > Le Mon, 15 Apr 2013 14:43:21 +0200,
> > Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com> a ?crit :
> > 
> > > On 16:31 Sun 14 Apr     , Markus Pargmann wrote:
> > > > On Mon, Apr 08, 2013 at 09:57:42AM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > > > > On 12:31 Fri 05 Apr     , Markus Pargmann wrote:
> > > > > > Add devicetree support for imx framebuffer driver. It uses the generic
> > > > > > display bindings and helper functions.
> > > > > > 
> > > > > > Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
> > > > > > Cc: Fabio Estevam <festevam at gmail.com>
> > > > > > Cc: Mark Rutland <mark.rutland at arm.com>
> > > > > > ---
> > > > > >  .../devicetree/bindings/video/fsl,imx-fb.txt       |  49 ++++++
> > > > > >  drivers/video/imxfb.c                              | 192 +++++++++++++++++----
> > > > > >  2 files changed, 207 insertions(+), 34 deletions(-)
> > > > > >  create mode 100644 Documentation/devicetree/bindings/video/fsl,imx-fb.txt
> > > > > > 
> > > > > > diff --git a/Documentation/devicetree/bindings/video/fsl,imx-fb.txt b/Documentation/devicetree/bindings/video/fsl,imx-fb.txt
> > > > > > new file mode 100644
> > > > > > index 0000000..bde9c77
> > > > > > --- /dev/null
> > > > > > +++ b/Documentation/devicetree/bindings/video/fsl,imx-fb.txt
> > > > > > @@ -0,0 +1,49 @@
> > > > > > +Freescale imx21 Framebuffer
> > > > > > +
> > > > > > +This framebuffer driver supports devices imx1, imx21, imx25, and imx27.
> > > > > > +
> > > > > > +Required properties:
> > > > > > +- compatible : "fsl,<chip>-fb", chip should be imx1 or imx21
> > > > > > +- reg : Should contain 1 register ranges(address and length)
> > > > > > +- interrupts : One interrupt of the fb dev
> > > > > > +
> > > > > > +Required nodes:
> > > > > > +- display: Phandle to a display node as described in
> > > > > > +	Documentation/devicetree/bindings/video/display-timing.txt
> > > > > > +	Additional, the display node has to define properties:
> > > > > > +	- fsl,bpp: Bits per pixel
> > > > > > +	- fsl,pcr: LCDC PCR value
> > > > > > +
> > > > > > +Optional properties:
> > > > > > +- dmacr-eukrea: Should be set for eukrea boards.
> > > > > why ?
> > > > 
> > > > Because eukrea boards have a different dmacr then all other boards using
> > > > imxfb. The dmacr address is hardcoded as defaults in the code. I could
> > > > also search for the board name in the DT, but there are no eukrea boards
> > > > with DT at the moment, so I thought a bool property may be better for
> > > > the moment.
> > > so no if an other board come will have an other property no
> > > 
> > > add an optionnal option to pass the dmacr
> > 
> > I didn't follow the thread but dmacr is not specific to our boards :
> > $ grep -rn dmacr arch/arm/mach-imx/
> > arch/arm/mach-imx/mach-mx27_3ds.c:446:	.dmacr		= 0x00020010,
> > arch/arm/mach-imx/mach-mx21ads.c:231:	.dmacr		= 0x00020008,
> > arch/arm/mach-imx/mach-mxt_td60.c:210:	.dmacr		= 0x00020010,
> > arch/arm/mach-imx/eukrea_mbimx27-baseboard.c:192:	.dmacr		= 0x00040060,
> > arch/arm/mach-imx/eukrea_mbimxsd25-baseboard.c:165:	.dmacr		= 0x00040060,
> > arch/arm/mach-imx/mach-mx27ads.c:241:	.dmacr		= 0x00020010,
> > arch/arm/mach-imx/mach-pca100.c:351:	.dmacr		= 0x00020010,
> > arch/arm/mach-imx/pcm970-baseboard.c:185:	.dmacr		= 0x00020010,
> > arch/arm/mach-imx/mach-mx25_3ds.c:173:	.dmacr		= 0x00020010,
> 
> with this it even more clear nack on the dmacr-eukrea property
> 
> use an optional property where we can specify the value to use
> 
> Best Regsrds,
> J.
> 

v4 will contain a optional fsl,dmacr property now. By default the reset
value of dmacr register is not changed.

Regards,

Markus

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From plagnioj at jcrosoft.com  Tue Apr 16 10:13:26 2013
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Tue, 16 Apr 2013 16:13:26 +0200
Subject: [PATCH 6/8] ARM: at91: sam9263: add fb dt support
In-Reply-To: <516D5C06.1050807@atmel.com>
References: <20130411145741.GB25242@game.jcrosoft.org>
 <1365692422-9565-1-git-send-email-plagnioj@jcrosoft.com>
 <1365692422-9565-6-git-send-email-plagnioj@jcrosoft.com>
 <516D5C06.1050807@atmel.com>
Message-ID: <20130416141326.GB4998@game.jcrosoft.org>

On 16:11 Tue 16 Apr     , Nicolas Ferre wrote:
> On 04/11/2013 05:00 PM, Jean-Christophe PLAGNIOL-VILLARD :
> > Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
> > Cc: Nicolas Ferre <nicolas.ferre at atmel.com>
> > ---
> >  arch/arm/boot/dts/at91sam9263.dtsi |   39 ++++++++++++++++++++++++++++++++++++
> >  1 file changed, 39 insertions(+)
> > 
> > diff --git a/arch/arm/boot/dts/at91sam9263.dtsi b/arch/arm/boot/dts/at91sam9263.dtsi
> > index 271d4de..3d0effa 100644
> > --- a/arch/arm/boot/dts/at91sam9263.dtsi
> > +++ b/arch/arm/boot/dts/at91sam9263.dtsi
> > @@ -303,6 +303,34 @@
> >  					};
> >  				};
> >  
> > +				fb {
> > +					pinctrl_fb: fb-0 {
> > +						atmel,pins =
> > +							<2 1 0x1 0x0	/* PC1 periph A */
> > +							 2 2 0x1 0x0	/* PC2 periph A */
> > +							 2 3 0x1 0x0	/* PC3 periph A */
> > +							 1 9 0x2 0x0	/* PB9 periph B */
> > +							 2 6 0x1 0x0	/* PC6 periph A */
> > +							 2 7 0x1 0x0	/* PC7 periph A */
> > +							 2 8 0x1 0x0	/* PC8 periph A */
> > +							 2 9 0x1 0x0	/* PC9 periph A */
> > +							 2 10 0x1 0x0	/* PC10 periph A */
> > +							 2 11 0x1 0x0	/* PC11 periph A */
> > +							 2 14 0x1 0x0	/* PC14 periph A */
> > +							 2 15 0x1 0x0	/* PC15 periph A */
> > +							 2 16 0x1 0x0	/* PC16 periph A */
> > +							 2 12 0x2 0x0	/* PC12 periph B */
> > +							 2 18 0x1 0x0	/* PC18 periph A */
> > +							 2 19 0x1 0x0	/* PC19 periph A */
> > +							 2 22 0x1 0x0	/* PC22 periph A */
> > +							 2 23 0x1 0x0	/* PC23 periph A */
> > +							 2 24 0x1 0x0	/* PC24 periph A */
> > +							 2 17 0x2 0x0	/* PC17 periph B */
> > +							 2 26 0x1 0x0	/* PC26 periph A */
> > +							 2 27 0x1 0x0>;	/* PC27 periph A */
> 
> Verified, okay.
> 
> > +					};
> > +				};
> > +
> >  				pioA: gpio at fffff200 {
> >  					compatible = "atmel,at91rm9200-gpio";
> >  					reg = <0xfffff200 0x200>;
> > @@ -464,6 +492,17 @@
> >  			};
> >  		};
> >  
> > +		fb0: fb at 0x00500000 {
> 
> No, it is 0x700000
> 
> > +			compatible = "atmel,at91sam9263-lcdc";
> > +			reg = <0x00700000 0x1000>;
> 
> Ditto.
> 
> > +			interrupts = <26 3 0>;
> 
> <26 4 0> here.
no lcd is 3 even in c

and even 3 could be slow in some big lcd case
> 
> 
> > +			pinctrl-names = "default";
> > +			pinctrl-0 = <&pinctrl_fb>;
> > +			status = "disabled";
> > +			#address-cells = <1>;
> > +			#size-cells = <1>;
> 
> Ditto in 9g45 case.
> 
> > +		};
> > +
> >  		nand0: nand at 40000000 {
> >  			compatible = "atmel,at91rm9200-nand";
> >  			#address-cells = <1>;
> > 
> 
> 
> -- 
> Nicolas Ferre


From dave.martin at linaro.org  Tue Apr 16 10:30:18 2013
From: dave.martin at linaro.org (Dave Martin)
Date: Tue, 16 Apr 2013 15:30:18 +0100
Subject: [RFC PATCH 2/2] ARM: DT: kernel: DT cpu node bindings update
In-Reply-To: <516C544A.4090107@wwwdotorg.org>
References: <1366042402-8987-1-git-send-email-lorenzo.pieralisi@arm.com>
 <1366042402-8987-3-git-send-email-lorenzo.pieralisi@arm.com>
 <516C544A.4090107@wwwdotorg.org>
Message-ID: <20130416143018.GB2229@linaro.org>

On Mon, Apr 15, 2013 at 01:26:02PM -0600, Stephen Warren wrote:
> On 04/15/2013 10:13 AM, Lorenzo Pieralisi wrote:

[...]

> > +	- enable-method
> > +		Usage: required on ARM 64-bit systems, optional on ARM 32-bit
> > +		       systems

If we define no meaningful enumerations for 32-bit systems (for example,
the spin-table boot method doesn't exist), then arguably this property
should be prohibited for 32-bit systems in this version of the binding.

The binding should be extended later when we have enable methods to add?

(enable-method = "psci" is one plausible addition)

> > +		Value type: <string>
> > +		Definition: On ARM 64-bit systems must be "spin-table" [1].
> 
> Can that be an integer instead? with dtc+cpp support, that shouldn't
> hurt the eyes too much any more.

That doesn't feel very DT-like, and it makes the standalone FDT excessively
cryptic without the headers.  Does it really matter that much?  DT parsing
should not be on any performance-critical path.

Mostly, DT convention seems to be to use legible string names for
enumerations like this.

Anything which tends to encrypt the DT content starts us on a slippery
slope IMHO.  Converting the DT back to a vaguely human-readable form
becomes impossible without the headers.

Cheers
---Dave


From shawn.guo at linaro.org  Tue Apr 16 10:30:42 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 16 Apr 2013 22:30:42 +0800
Subject: [PATCH 1/2] ARM: add diagnostic register access helpers
Message-ID: <1366122643-1961-1-git-send-email-shawn.guo@linaro.org>

The CP15 diagnostic register holds many ARM errata bits.  Add a pair of
access helpers for it.

Signed-off-by: Shawn Guo <shawn.guo at linaro.org>
---
 arch/arm/include/asm/cp15.h |   13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/arch/arm/include/asm/cp15.h b/arch/arm/include/asm/cp15.h
index 5ef4d80..0b14dfb 100644
--- a/arch/arm/include/asm/cp15.h
+++ b/arch/arm/include/asm/cp15.h
@@ -82,6 +82,19 @@ static inline void set_copro_access(unsigned int val)
 	isb();
 }
 
+static inline unsigned int get_diag_reg(void)
+{
+	unsigned int val;
+	asm("mrc p15, 0, %0, c15, c0, 1" : "=r" (val) : : "cc");
+	return val;
+}
+
+static inline void set_diag_reg(unsigned int val)
+{
+	asm volatile("mcr p15, 0, %0, c15, c0, 1" : : "r" (val) : "cc");
+	isb();
+}
+
 #endif
 
 #endif
-- 
1.7.9.5




From shawn.guo at linaro.org  Tue Apr 16 10:30:43 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 16 Apr 2013 22:30:43 +0800
Subject: [PATCH 2/2] ARM: imx: replicate the diagnostic register of boot cpu
 into secondary cores
In-Reply-To: <1366122643-1961-1-git-send-email-shawn.guo@linaro.org>
References: <1366122643-1961-1-git-send-email-shawn.guo@linaro.org>
Message-ID: <1366122643-1961-2-git-send-email-shawn.guo@linaro.org>

The diagnostic register holds the errata bits.  Mostly bootloader
does not bring up secondary cores, so that when errata bits are set
in bootloader, they are set only for boot cpu.  But on a SMP
configuration, it should be equally done on every single core.
Set up the diagnostic register for secondary cores by replicating
the register from boot cpu.

Signed-off-by: Shawn Guo <shawn.guo at linaro.org>
---
 arch/arm/mach-imx/platsmp.c |   15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/arch/arm/mach-imx/platsmp.c b/arch/arm/mach-imx/platsmp.c
index 7c0b03f..93854f9 100644
--- a/arch/arm/mach-imx/platsmp.c
+++ b/arch/arm/mach-imx/platsmp.c
@@ -13,6 +13,7 @@
 #include <linux/init.h>
 #include <linux/smp.h>
 #include <linux/irqchip/arm-gic.h>
+#include <asm/cp15.h>
 #include <asm/page.h>
 #include <asm/smp_scu.h>
 #include <asm/mach/map.h>
@@ -23,6 +24,7 @@
 #define SCU_STANDBY_ENABLE	(1 << 5)
 
 static void __iomem *scu_base;
+static u32 diag_reg;
 
 static struct map_desc scu_io_desc __initdata = {
 	/* .virtual and .pfn are run-time assigned */
@@ -60,6 +62,9 @@ static void __cpuinit imx_secondary_init(unsigned int cpu)
 	 * for us: do so
 	 */
 	gic_secondary_init(0);
+
+	/* Replicate the diagnostic register of boot cpu */
+	set_diag_reg(diag_reg);
 }
 
 static int __cpuinit imx_boot_secondary(unsigned int cpu, struct task_struct *idle)
@@ -91,6 +96,16 @@ void imx_smp_prepare(void)
 static void __init imx_smp_prepare_cpus(unsigned int max_cpus)
 {
 	imx_smp_prepare();
+
+	/*
+	 * The diagnostic register holds the errata bits.  Mostly bootloader
+	 * does not bring up secondary cores, so that when errata bits are set
+	 * in bootloader, they are set only for boot cpu.  But on a SMP
+	 * configuration, it should be equally done on every single core.
+	 * Read the register from boot cpu here, and will replicate it into
+	 * secondary cores when booting them.
+	 */
+	diag_reg = get_diag_reg();
 }
 
 struct smp_operations  imx_smp_ops __initdata = {
-- 
1.7.9.5




From will.deacon at arm.com  Tue Apr 16 10:48:53 2013
From: will.deacon at arm.com (Will Deacon)
Date: Tue, 16 Apr 2013 15:48:53 +0100
Subject: [PATCH 1/2] ARM: add diagnostic register access helpers
In-Reply-To: <1366122643-1961-1-git-send-email-shawn.guo@linaro.org>
References: <1366122643-1961-1-git-send-email-shawn.guo@linaro.org>
Message-ID: <20130416144853.GB3770@mudshark.cambridge.arm.com>

On Tue, Apr 16, 2013 at 03:30:42PM +0100, Shawn Guo wrote:
> The CP15 diagnostic register holds many ARM errata bits.  Add a pair of
> access helpers for it.
> 
> Signed-off-by: Shawn Guo <shawn.guo at linaro.org>
> ---
>  arch/arm/include/asm/cp15.h |   13 +++++++++++++
>  1 file changed, 13 insertions(+)
> 
> diff --git a/arch/arm/include/asm/cp15.h b/arch/arm/include/asm/cp15.h
> index 5ef4d80..0b14dfb 100644
> --- a/arch/arm/include/asm/cp15.h
> +++ b/arch/arm/include/asm/cp15.h
> @@ -82,6 +82,19 @@ static inline void set_copro_access(unsigned int val)
>  	isb();
>  }
>  
> +static inline unsigned int get_diag_reg(void)
> +{
> +	unsigned int val;
> +	asm("mrc p15, 0, %0, c15, c0, 1" : "=r" (val) : : "cc");
> +	return val;
> +}
> +
> +static inline void set_diag_reg(unsigned int val)
> +{
> +	asm volatile("mcr p15, 0, %0, c15, c0, 1" : : "r" (val) : "cc");
> +	isb();
> +}
> +

You don't want to poke this register with the MMU on, so I don't think this
patch is a very good idea.

Will


From nicolas.ferre at atmel.com  Tue Apr 16 10:54:01 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Tue, 16 Apr 2013 16:54:01 +0200
Subject: [PATCH 8/8] ARM: at91: sam9263ek: add dt lcd support
In-Reply-To: <1365692422-9565-8-git-send-email-plagnioj@jcrosoft.com>
References: <20130411145741.GB25242@game.jcrosoft.org>
 <1365692422-9565-1-git-send-email-plagnioj@jcrosoft.com>
 <1365692422-9565-8-git-send-email-plagnioj@jcrosoft.com>
Message-ID: <516D6609.5020706@atmel.com>

On 04/11/2013 05:00 PM, Jean-Christophe PLAGNIOL-VILLARD :
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
> Cc: Nicolas Ferre <nicolas.ferre at atmel.com>
> ---
>  arch/arm/boot/dts/at91sam9263ek.dts |   30 ++++++++++++++++++++++++++++++
>  1 file changed, 30 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/at91sam9263ek.dts b/arch/arm/boot/dts/at91sam9263ek.dts
> index 1eb0872..d471b49 100644
> --- a/arch/arm/boot/dts/at91sam9263ek.dts
> +++ b/arch/arm/boot/dts/at91sam9263ek.dts
> @@ -81,6 +81,36 @@
>  			};
>  		};
>  
> +		fb0: fb at 0x00500000 {

Ditto: Not good address: 0x700000

> +			display = <&display0>;
> +			status = "okay";
> +
> +			display0: display {
> +				bits-per-pixel = <16>;
> +				atmel,lcdcon-backlight;
> +				atmel,dmacon = <0x1>;
> +				atmel,lcdcon2 = <0x80008002>;
> +				atmel,guard-time = <1>;
> +
> +				display-timings {
> +					native-mode = <&timing0>;
> +					timing0: timing0 {
> +						clock-frequency = <4965000>;
> +						hactive = <240>;
> +						vactive = <320>;
> +						hback-porch = <1>;
> +						hfront-porch = <33>;
> +						vback-porch = <1>;
> +						vfront-porch = <0>;
> +						hsync-len = <5>;
> +						vsync-len = <1>;
> +						hsync-active = <1>;
> +						vsync-active = <1>;
> +					};
> +				};
> +			};
> +		};

Otherwise, seems good.

> +
>  		nand0: nand at 40000000 {
>  			nand-bus-width = <8>;
>  			nand-ecc-mode = "soft";
> 


-- 
Nicolas Ferre


From nicolas.ferre at atmel.com  Tue Apr 16 10:56:43 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Tue, 16 Apr 2013 16:56:43 +0200
Subject: [PATCH 7/8] ARM: at91: at9sam9m10g45ek: add dt lcd support
In-Reply-To: <1365692422-9565-7-git-send-email-plagnioj@jcrosoft.com>
References: <20130411145741.GB25242@game.jcrosoft.org>
 <1365692422-9565-1-git-send-email-plagnioj@jcrosoft.com>
 <1365692422-9565-7-git-send-email-plagnioj@jcrosoft.com>
Message-ID: <516D66AB.7050804@atmel.com>

On 04/11/2013 05:00 PM, Jean-Christophe PLAGNIOL-VILLARD :
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
> Cc: Nicolas Ferre <nicolas.ferre at atmel.com>
> ---
>  arch/arm/boot/dts/at91sam9m10g45ek.dts |   29 +++++++++++++++++++++++++++++
>  1 file changed, 29 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/at91sam9m10g45ek.dts b/arch/arm/boot/dts/at91sam9m10g45ek.dts
> index 20c3191..79dc034 100644
> --- a/arch/arm/boot/dts/at91sam9m10g45ek.dts
> +++ b/arch/arm/boot/dts/at91sam9m10g45ek.dts
> @@ -104,6 +104,35 @@
>  			};
>  		};
>  
> +		fb0: fb at 0x00500000 {
> +			display = <&display0>;
> +			status = "okay";
> +
> +			display0: display {
> +				bits-per-pixel = <32>;
> +				atmel,lcdcon-backlight;
> +				atmel,dmacon = <0x1>;
> +				atmel,lcdcon2 = <0x80008002>;
> +				atmel,guard-time = <9>;
> +				atmel,lcd-wiring-mode = "RGB";
> +
> +				display-timings {
> +					native-mode = <&timing0>;
> +					timing0: timing0 {
> +						clock-frequency = <9000000>;
> +						hactive = <480>;
> +						vactive = <272>;
> +						hback-porch = <1>;
> +						hfront-porch = <1>;
> +						vback-porch = <40>;
> +						vfront-porch = <1>;
> +						hsync-len = <45>;
> +						vsync-len = <1>;
> +					};
> +				};
> +			};
> +		};
> +

Seems good.

>  		nand0: nand at 40000000 {
>  			nand-bus-width = <8>;
>  			nand-ecc-mode = "soft";
> 


-- 
Nicolas Ferre


From jason at lakedaemon.net  Tue Apr 16 11:04:16 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Tue, 16 Apr 2013 11:04:16 -0400
Subject: [GIT PULL V2 1/4] mvebu driver changes for v3.10
In-Reply-To: <20130415182824.GN28693@titan.lakedaemon.net>
References: <20130415182824.GN28693@titan.lakedaemon.net>
Message-ID: <20130416150416.GB28693@titan.lakedaemon.net>


The following changes since commit 8bb9660418e05bb1845ac1a2428444d78e322cc7:

  Linux 3.9-rc4 (2013-03-23 16:52:44 -0700)

are available in the git repository at:

  git://git.infradead.org/users/jcooper/linux.git tags/drivers-3.10-2

for you to fetch changes up to ac7b07ec369324063e52c37b3fb0ad1a1814d879:

  clk: mvebu: add more PCIe clocks for Armada XP (2013-04-16 14:47:01 +0000)

----------------------------------------------------------------
mvebu drivers for v3.10 round 2

 - mvebu
    - device bus driver (Acked by gregkh to go through arm-soc)
    - PCIe prep work Acked by appropriate maintainers (of,pci,clk) for arm-soc

----------------------------------------------------------------

Changes for v2:
 - updated to Andrew Murray's v7 patchset.

Andrew Murray (3):
      of/pci: Unify pci_process_bridge_OF_ranges from Microblaze and PowerPC
      of/pci: Provide support for parsing PCI DT ranges property
      of/pci: mips: convert to common of_pci_range_parser

Ezequiel Garcia (1):
      drivers: memory: Introduce Marvell EBU Device Bus driver

Neil Greatorex (1):
      bus: mvebu-mbus: Restore checking for coherency fabric hardware

Thierry Reding (2):
      of/pci: Add of_pci_get_devfn() function
      of/pci: Add of_pci_parse_bus_range() function

Thomas Petazzoni (5):
      bus: introduce an Marvell EBU MBus driver
      bus: mvebu: fix mistake in PCIe window target attribute for Kirkwood
      pci: infrastructure to add drivers in drivers/pci/host
      clk: mvebu: create parent-child relation for PCIe clocks on Armada 370
      clk: mvebu: add more PCIe clocks for Armada XP

 .../bindings/memory-controllers/mvebu-devbus.txt   | 156 ++++
 arch/microblaze/include/asm/pci-bridge.h           |   5 +-
 arch/microblaze/pci/pci-common.c                   | 192 -----
 arch/mips/pci/pci.c                                |  50 +-
 arch/powerpc/include/asm/pci-bridge.h              |   5 +-
 arch/powerpc/kernel/pci-common.c                   | 192 -----
 drivers/bus/Kconfig                                |   7 +
 drivers/bus/Makefile                               |   1 +
 drivers/bus/mvebu-mbus.c                           | 870 +++++++++++++++++++++
 drivers/clk/mvebu/clk-gating-ctrl.c                |  18 +-
 drivers/memory/Kconfig                             |  10 +
 drivers/memory/Makefile                            |   1 +
 drivers/memory/mvebu-devbus.c                      | 340 ++++++++
 drivers/of/address.c                               |  67 ++
 drivers/of/of_pci.c                                | 228 +++++-
 drivers/pci/Kconfig                                |   2 +
 drivers/pci/Makefile                               |   3 +
 drivers/pci/host/Kconfig                           |   4 +
 drivers/pci/host/Makefile                          |   1 +
 include/linux/mbus.h                               |  24 +-
 include/linux/of_address.h                         |  46 ++
 include/linux/of_pci.h                             |   6 +
 22 files changed, 1790 insertions(+), 438 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/memory-controllers/mvebu-devbus.txt
 create mode 100644 drivers/bus/mvebu-mbus.c
 create mode 100644 drivers/memory/mvebu-devbus.c
 create mode 100644 drivers/pci/host/Kconfig
 create mode 100644 drivers/pci/host/Makefile


From jason at lakedaemon.net  Tue Apr 16 11:05:37 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Tue, 16 Apr 2013 11:05:37 -0400
Subject: [PATCH v7 0/3] of/pci: Provide common support for PCI DT parsing
In-Reply-To: <1366107508-12672-1-git-send-email-Andrew.Murray@arm.com>
References: <1366107508-12672-1-git-send-email-Andrew.Murray@arm.com>
Message-ID: <20130416150537.GC28693@titan.lakedaemon.net>

On Tue, Apr 16, 2013 at 11:18:25AM +0100, Andrew Murray wrote:
> This patchset factors out duplicated code associated with parsing PCI
> DT "ranges" properties across the architectures and introduces a
> "ranges" parser. This parser "of_pci_range_parser" can be used directly
> by ARM host bridge drivers enabling them to obtain ranges from device
> trees.
> 
> I've included the Reviewed-by and Tested-by's received from v5/v6 in this
> patchset, earlier versions of this patchset (v3) have been tested-by:
> 
> Thierry Reding <thierry.reding at avionic-design.de>
> Jingoo Han <jg1.han at samsung.com>
> 
> I've tested that this patchset builds and runs on ARM and that it builds on
> PowerPC and x86_64.

Series replaces v6 in mvebu/drivers

thx,

Jason.

> 
> Compared to the v6 sent by Andrew Murray, the following changes have
> been made in response to build errors/warnings:
> 
>  * Inclusion of linux/of_address.h in of_pci.c as suggested by Michal
>    Simek to prevent compilation failures on Microblaze (and others) and his
>    ack.
> 
>  * Use of externs, static inlines and a typo in linux/of_address.h in response
>    to linker errors (multiple defination) on x86_64 as spotted by a kbuild test
>    robot on (jcooper/linux.git mvebu/drivers)
> 
>  * Add EXPORT_SYMBOL_GPL to of_pci_range_parser function to be consistent
>    with of_pci_process_ranges function


From nicolas.ferre at atmel.com  Tue Apr 16 11:11:35 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Tue, 16 Apr 2013 17:11:35 +0200
Subject: [PATCH 6/8] ARM: at91: sam9263: add fb dt support
In-Reply-To: <20130416141326.GB4998@game.jcrosoft.org>
References: <20130411145741.GB25242@game.jcrosoft.org>
 <1365692422-9565-1-git-send-email-plagnioj@jcrosoft.com>
 <1365692422-9565-6-git-send-email-plagnioj@jcrosoft.com>
 <516D5C06.1050807@atmel.com> <20130416141326.GB4998@game.jcrosoft.org>
Message-ID: <516D6A27.6070202@atmel.com>

On 04/16/2013 04:13 PM, Jean-Christophe PLAGNIOL-VILLARD :
> On 16:11 Tue 16 Apr     , Nicolas Ferre wrote:
>> On 04/11/2013 05:00 PM, Jean-Christophe PLAGNIOL-VILLARD :
>>> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
>>> Cc: Nicolas Ferre <nicolas.ferre at atmel.com>
>>> ---
>>>  arch/arm/boot/dts/at91sam9263.dtsi |   39 ++++++++++++++++++++++++++++++++++++
>>>  1 file changed, 39 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/at91sam9263.dtsi b/arch/arm/boot/dts/at91sam9263.dtsi
>>> index 271d4de..3d0effa 100644
>>> --- a/arch/arm/boot/dts/at91sam9263.dtsi
>>> +++ b/arch/arm/boot/dts/at91sam9263.dtsi
>>> @@ -303,6 +303,34 @@
>>>  					};
>>>  				};
>>>  
>>> +				fb {
>>> +					pinctrl_fb: fb-0 {
>>> +						atmel,pins =
>>> +							<2 1 0x1 0x0	/* PC1 periph A */
>>> +							 2 2 0x1 0x0	/* PC2 periph A */
>>> +							 2 3 0x1 0x0	/* PC3 periph A */
>>> +							 1 9 0x2 0x0	/* PB9 periph B */
>>> +							 2 6 0x1 0x0	/* PC6 periph A */
>>> +							 2 7 0x1 0x0	/* PC7 periph A */
>>> +							 2 8 0x1 0x0	/* PC8 periph A */
>>> +							 2 9 0x1 0x0	/* PC9 periph A */
>>> +							 2 10 0x1 0x0	/* PC10 periph A */
>>> +							 2 11 0x1 0x0	/* PC11 periph A */
>>> +							 2 14 0x1 0x0	/* PC14 periph A */
>>> +							 2 15 0x1 0x0	/* PC15 periph A */
>>> +							 2 16 0x1 0x0	/* PC16 periph A */
>>> +							 2 12 0x2 0x0	/* PC12 periph B */
>>> +							 2 18 0x1 0x0	/* PC18 periph A */
>>> +							 2 19 0x1 0x0	/* PC19 periph A */
>>> +							 2 22 0x1 0x0	/* PC22 periph A */
>>> +							 2 23 0x1 0x0	/* PC23 periph A */
>>> +							 2 24 0x1 0x0	/* PC24 periph A */
>>> +							 2 17 0x2 0x0	/* PC17 periph B */
>>> +							 2 26 0x1 0x0	/* PC26 periph A */
>>> +							 2 27 0x1 0x0>;	/* PC27 periph A */
>>
>> Verified, okay.
>>
>>> +					};
>>> +				};
>>> +
>>>  				pioA: gpio at fffff200 {
>>>  					compatible = "atmel,at91rm9200-gpio";
>>>  					reg = <0xfffff200 0x200>;
>>> @@ -464,6 +492,17 @@
>>>  			};
>>>  		};
>>>  
>>> +		fb0: fb at 0x00500000 {
>>
>> No, it is 0x700000
>>
>>> +			compatible = "atmel,at91sam9263-lcdc";
>>> +			reg = <0x00700000 0x1000>;
>>
>> Ditto.
>>
>>> +			interrupts = <26 3 0>;
>>
>> <26 4 0> here.
> no lcd is 3 even in c
> 
> and even 3 could be slow in some big lcd case

No, you mean the priority, but priority is encoded as the 3rd cell. So,
we end up with:

<26 4 3>

(I agree with the 3)


>>
>>
>>> +			pinctrl-names = "default";
>>> +			pinctrl-0 = <&pinctrl_fb>;
>>> +			status = "disabled";
>>> +			#address-cells = <1>;
>>> +			#size-cells = <1>;
>>
>> Ditto in 9g45 case.
>>
>>> +		};
>>> +
>>>  		nand0: nand at 40000000 {
>>>  			compatible = "atmel,at91rm9200-nand";
>>>  			#address-cells = <1>;
>>>
>>
>>
>> -- 
>> Nicolas Ferre
> 

Bye,
-- 
Nicolas Ferre


From shawn.guo at linaro.org  Tue Apr 16 11:11:32 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 16 Apr 2013 23:11:32 +0800
Subject: [PATCH 1/2] ARM: add diagnostic register access helpers
In-Reply-To: <20130416144853.GB3770@mudshark.cambridge.arm.com>
References: <1366122643-1961-1-git-send-email-shawn.guo@linaro.org>
 <20130416144853.GB3770@mudshark.cambridge.arm.com>
Message-ID: <20130416151130.GE11245@S2101-09.ap.freescale.net>

On Tue, Apr 16, 2013 at 03:48:53PM +0100, Will Deacon wrote:
> > +static inline unsigned int get_diag_reg(void)
> > +{
> > +	unsigned int val;
> > +	asm("mrc p15, 0, %0, c15, c0, 1" : "=r" (val) : : "cc");
> > +	return val;
> > +}
> > +
> > +static inline void set_diag_reg(unsigned int val)
> > +{
> > +	asm volatile("mcr p15, 0, %0, c15, c0, 1" : : "r" (val) : "cc");
> > +	isb();
> > +}
> > +
> 
> You don't want to poke this register with the MMU on, so I don't think this
> patch is a very good idea.

If you are worrying about that the helpers could be abused by people, I
can certainly make them local in arch/arm/mach-imx/platsmp.c.  But I do
not understand why diagnostic register shouldn't be accessed when MMU is
on.  I'm doing that in patch #2 to get my problem fixed, and not seeing
anything broken there.

Shawn



From nicolas.ferre at atmel.com  Tue Apr 16 11:12:59 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Tue, 16 Apr 2013 17:12:59 +0200
Subject: [PATCH 5/8] ARM: at91: sam9g45: add lcd support
In-Reply-To: <516D5991.8020603@atmel.com>
References: <20130411145741.GB25242@game.jcrosoft.org>
 <1365692422-9565-1-git-send-email-plagnioj@jcrosoft.com>
 <1365692422-9565-5-git-send-email-plagnioj@jcrosoft.com>
 <516D5991.8020603@atmel.com>
Message-ID: <516D6A7B.8050503@atmel.com>

On 04/16/2013 04:00 PM, Nicolas Ferre :
> On 04/11/2013 05:00 PM, Jean-Christophe PLAGNIOL-VILLARD :
>> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
>> Cc: Nicolas Ferre <nicolas.ferre at atmel.com>
>> ---
>>  arch/arm/boot/dts/at91sam9g45.dtsi |   47 ++++++++++++++++++++++++++++++++++++
>>  1 file changed, 47 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/at91sam9g45.dtsi b/arch/arm/boot/dts/at91sam9g45.dtsi
>> index 6b1d4ca..ab8a8fc 100644
>> --- a/arch/arm/boot/dts/at91sam9g45.dtsi
>> +++ b/arch/arm/boot/dts/at91sam9g45.dtsi
>> @@ -322,6 +322,42 @@
>>  					};
>>  				};
>>  
>> +				fb {
>> +					pinctrl_fb: fb-0 {
>> +						atmel,pins =
>> +							<4 0 0x1 0x0	/* PE0 periph A */
>> +							 4 2 0x1 0x0	/* PE2 periph A */
>> +							 4 3 0x1 0x0	/* PE3 periph A */
>> +							 4 4 0x1 0x0	/* PE4 periph A */
>> +							 4 5 0x1 0x0	/* PE5 periph A */
>> +							 4 6 0x1 0x0	/* PE6 periph A */
>> +							 4 7 0x1 0x0	/* PE7 periph A */
>> +							 4 8 0x1 0x0	/* PE8 periph A */
>> +							 4 9 0x1 0x0	/* PE9 periph A */
>> +							 4 10 0x1 0x0	/* PE10 periph A */
>> +							 4 11 0x1 0x0	/* PE11 periph A */
>> +							 4 12 0x1 0x0	/* PE12 periph A */
>> +							 4 13 0x1 0x0	/* PE13 periph A */
>> +							 4 14 0x1 0x0	/* PE14 periph A */
>> +							 4 15 0x1 0x0	/* PE15 periph A */
>> +							 4 16 0x1 0x0	/* PE16 periph A */
>> +							 4 17 0x1 0x0	/* PE17 periph A */
>> +							 4 18 0x1 0x0	/* PE18 periph A */
>> +							 4 19 0x1 0x0	/* PE19 periph A */
>> +							 4 20 0x1 0x0	/* PE20 periph A */
>> +							 4 21 0x1 0x0	/* PE21 periph A */
>> +							 4 22 0x1 0x0	/* PE22 periph A */
>> +							 4 23 0x1 0x0	/* PE23 periph A */
>> +							 4 24 0x1 0x0	/* PE24 periph A */
>> +							 4 25 0x1 0x0	/* PE25 periph A */
>> +							 4 26 0x1 0x0	/* PE26 periph A */
>> +							 4 27 0x1 0x0	/* PE27 periph A */
>> +							 4 28 0x1 0x0	/* PE28 periph A */
>> +							 4 29 0x1 0x0	/* PE29 periph A */
>> +							 4 30 0x1 0x0>;	/* PE30 periph A */
>> +					};
>> +				};
>> +
>>  				pioA: gpio at fffff200 {
>>  					compatible = "atmel,at91rm9200-gpio";
>>  					reg = <0xfffff200 0x200>;
>> @@ -533,6 +569,17 @@
>>  			};
>>  		};
>>  
>> +		fb0: fb at 0x00500000 {
>> +			compatible = "atmel,at91sam9g45-lcdc";
>> +			reg = <0x00500000 0x1000>;
>> +			interrupts = <23 3 0>;
> 
> Error: here, it is <23 4 0>

Collecting all the remarks, we end-up with:

<23 4 3>

>> +			pinctrl-names = "default";
>> +			pinctrl-0 = <&pinctrl_fb>;
>> +			status = "disabled";
>> +			#address-cells = <1>;
>> +			#size-cells = <1>;
>> +		};
>> +
>>  		nand0: nand at 40000000 {
>>  			compatible = "atmel,at91rm9200-nand";
>>  			#address-cells = <1>;
>>
> 
> 


-- 
Nicolas Ferre


From haojian.zhuang at gmail.com  Tue Apr 16 11:13:41 2013
From: haojian.zhuang at gmail.com (Haojian Zhuang)
Date: Tue, 16 Apr 2013 23:13:41 +0800
Subject: [PATCH 1/4] ARM: mmp: add wakeup function for ICU
In-Reply-To: <175CCF5F49938B4D99B2E3EF7F558EBE2D0FB04F2B@SC-VEXCH4.marvell.com>
References: <1365651463-11502-1-git-send-email-zhangwm@marvell.com>
 <1365651463-11502-2-git-send-email-zhangwm@marvell.com>
 <CAN1soZwFJybMUZgxZJyXcDdKXbpQxaVntyZd8oGnQivLF=ZNNA@mail.gmail.com>
 <175CCF5F49938B4D99B2E3EF7F558EBE2D0FB04F2B@SC-VEXCH4.marvell.com>
Message-ID: <CAN1soZxWkXn4CxJEgZFQHc0MY6Arq2UfpvOEhJ5ZrTKOT=rw4g@mail.gmail.com>

>> > From: Haojian Zhuang [mailto:haojian.zhuang at gmail.com]
>> > Sent: 2013?4?13? 20:50
>> > To: Neil Zhang
>> > Cc: Grant Likely; linux-arm-kernel at lists.infradead.org;
>> > linux-kernel at vger.kernel.org; Chao Xie
>> > Subject: Re: [PATCH 1/4] ARM: mmp: add wakeup function for ICU
>> >
>> > On Thu, Apr 11, 2013 at 11:37 AM, Neil Zhang <zhangwm at marvell.com>
>> > wrote:
>> > > From: Chao Xie <chao.xie at marvell.com>
>> > >
>> > > PXA988 will use GIC as its interrupt controller, and ICU is used as
>> > > wakeup logic. When AP subsystem is powered off, GIC will lose its
>> > > context, the PMU will need ICU to wakeup the AP subsystem.
>> > > When ICU works as wakeup logic, there is no need to know
>> > > intc-nr-irqs, change the corresponding code.
>> > >
>> > > Signed-off-by: Chao Xie <chao.xie at marvell.com>
>> > > Signed-off-by: Neil Zhang <zhangwm at marvell.com>
>> > > ---
>> >
>> > Since it's totally different from original ICU irq initialization, I
>> > suggest to create a new entry to handle this kind of wakeup event. And
>> > we could create a new mask/unmask function.
>>
>> Ok, I'll update it.
> Are you OK if use icu_mask_irq_wakeup / icu_unmask_irq_wakeup for the new functions.

Yes, it's ok to me.


From mpa at pengutronix.de  Tue Apr 16 11:23:05 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Tue, 16 Apr 2013 17:23:05 +0200
Subject: [PATCH v3 05/15] ASoC: phycore-ac97: Add DT support
In-Reply-To: <20130416115942.GG26958@opensource.wolfsonmicro.com>
References: <1365939779-4507-1-git-send-email-mpa@pengutronix.de>
 <1365939779-4507-6-git-send-email-mpa@pengutronix.de>
 <20130416115942.GG26958@opensource.wolfsonmicro.com>
Message-ID: <20130416152305.GE13272@pengutronix.de>

On Tue, Apr 16, 2013 at 12:59:43PM +0100, Mark Brown wrote:
> On Sun, Apr 14, 2013 at 01:42:49PM +0200, Markus Pargmann wrote:
> 
> > +	/*
> > +	 * This driver doesn't need to know which actual hardware is used.
> > +	 * The audmux driver has knowledge about it's type, and returns
> > +	 * an error if executed on the wrong type of hardware.
> > +	 */
> > +	ret = phycore_ac97_pca100_audmux();
> > +	if (!ret)
> > +		return 0;
> > +
> > +	ret = phycore_ac97_pcm043_audmux();
> 
> The DT really ought to be able to give enough information to figure out
> the audmux configuration.  If we can't do that it rather defeats the
> point of moving to DT...

Yes you are right, I added a phandle "phytec,audmux" to check which
audmux setup function we have to use.

Regards,

Markus

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From nicolas.ferre at atmel.com  Tue Apr 16 11:43:18 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Tue, 16 Apr 2013 17:43:18 +0200
Subject: [PATCH 4/8] video: atmel_lcdfb: add device tree suport
In-Reply-To: <20130416134404.GA4998@game.jcrosoft.org>
References: <20130411145741.GB25242@game.jcrosoft.org>
 <1365692422-9565-1-git-send-email-plagnioj@jcrosoft.com>
 <1365692422-9565-4-git-send-email-plagnioj@jcrosoft.com>
 <516D554C.1090909@atmel.com> <20130416134404.GA4998@game.jcrosoft.org>
Message-ID: <516D7196.4010307@atmel.com>

On 04/16/2013 03:44 PM, Jean-Christophe PLAGNIOL-VILLARD :
> On 15:42 Tue 16 Apr     , Nicolas Ferre wrote:
>> On 04/11/2013 05:00 PM, Jean-Christophe PLAGNIOL-VILLARD :
>>> get display timings from device tree
>>> Use videomode helpers to get display timings and configurations from
>>> device tree
>>
>> 2 sentences? Simply elaborate the 2nd one and it will be good.
>>
>>> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
>>> Cc: linux-fbdev at vger.kernel.org
>>> Cc: Nicolas Ferre <nicolas.ferre at atmel.com>
>>> Cc: Andrew Morton <akpm at linux-foundation.org>
>>> ---
>>>  .../devicetree/bindings/video/atmel,lcdc.txt       |   75 ++++++
>>>  drivers/video/Kconfig                              |    2 +
>>>  drivers/video/atmel_lcdfb.c                        |  244 +++++++++++++++++---
>>>  3 files changed, 289 insertions(+), 32 deletions(-)
>>>  create mode 100644 Documentation/devicetree/bindings/video/atmel,lcdc.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/video/atmel,lcdc.txt b/Documentation/devicetree/bindings/video/atmel,lcdc.txt
>>> new file mode 100644
>>> index 0000000..1ec175e
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/video/atmel,lcdc.txt
>>
>> Why lcdc? I would have preferred atmel,lcdfb, like the driver's name: it
>> is even more self-explanatory...
> we do not describe drivers but IP

fine, but in
static const struct platform_device_id atmel_lcdfb_devtypes, we use
"xxx-lcdfb" type...

>>
>>> @@ -0,0 +1,75 @@
>>> +Atmel LCDC Framebuffer
>>> +-----------------------------------------------------
>>> +
>>> +Required properties:
>>> +- compatible :
>>> +	"atmel,at91sam9261-lcdc" , 
>>> +	"atmel,at91sam9263-lcdc" ,
>>> +	"atmel,at91sam9g10-lcdc" ,
>>> +	"atmel,at91sam9g45-lcdc" ,
>>> +	"atmel,at91sam9g45es-lcdc" ,
>>> +	"atmel,at91sam9rl-lcdc" ,
>>> +	"atmel,at32ap-lcdc"
>>> +- reg : Should contain 1 register ranges(address and length)
>>> +- interrupts : framebuffer controller interrupt
>>> +- display: a phandle pointing to the display node
>>> +
>>> +Required nodes:
>>> +- display: a display node is required to initialize the lcd panel
>>> +	This should be in the board dts.
>>> +- default-mode: a videomode within the display with timing parameters
>>> +	as specified below.
>>> +
>>> +Example:
>>> +
>>> +	fb0: fb at 0x00500000 {
>>> +		compatible = "atmel,at91sam9g45-lcdc";
>>> +		reg = <0x00500000 0x1000>;
>>> +		interrupts = <23 3 0>;
>>> +		pinctrl-names = "default";
>>> +		pinctrl-0 = <&pinctrl_fb>;
>>> +		display = <&display0>;
>>> +		status = "okay";
>>> +		#address-cells = <1>;
>>> +		#size-cells = <1>;
>>> +
>>> +	};
>>> +
>>> +Atmel LCDC Display
>>> +-----------------------------------------------------
>>> +Required properties (as per of_videomode_helper):
>>
>> Can you please point somewhere to the documentation:
>> Documentation/devicetree/bindings/video/display-timing.txt
>>
>>> + - atmel,dmacon: dma controler configuration
>>
>> Typo: controller.
>>
>>> + - atmel,lcdcon2: lcd controler configuration
>>
>> Ditto
>>
>>> + - atmel,guard-time: lcd guard time (Delay in frame periods)
>>
>> periods -> period, no?
> no it's periods even in the datasheet
>>
>>> + - bits-per-pixel: lcd panel bit-depth.
>>> +
>>> +Optional properties (as per of_videomode_helper):
>>> + - atmel,lcdcon-backlight: enable backlight
>>> + - atmel,lcd-wiring-mode: lcd wiring mode "RGB" or "BRG"
>>
>> Is it a sting, or a number (as seen below)? If it is a number, please
>> tell how to choose the index.
> String

Okay: so tell it in the description and correct the example below.


>>> + - atmel,power-control-gpio: gpio to power on or off the LCD (as many as needed)
>>> +
>>> +Example:
>>> +	display0: display {
>>> +		bits-per-pixel = <32>;
>>> +		atmel,lcdcon-backlight;
>>> +		atmel,dmacon = <0x1>;
>>> +		atmel,lcdcon2 = <0x80008002>;
>>> +		atmel,guard-time = <9>;
>>> +		atmel,lcd-wiring-mode = <1>;

Here ----------------------------------^^^^

>>> +
>>> +		display-timings {
>>> +			native-mode = <&timing0>;
>>> +			timing0: timing0 {
>>> +				clock-frequency = <9000000>;
>>> +				hactive = <480>;
>>> +				vactive = <272>;
>>> +				hback-porch = <1>;
>>> +				hfront-porch = <1>;
>>> +				vback-porch = <40>;
>>> +				vfront-porch = <1>;
>>> +				hsync-len = <45>;
>>> +				vsync-len = <1>;
>>> +			};
>>> +		};
>>> +	};
>>> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
>>> index 4c1546f..0687482 100644
>>> --- a/drivers/video/Kconfig
>>> +++ b/drivers/video/Kconfig
>>> @@ -1018,6 +1018,8 @@ config FB_ATMEL
>>>  	select FB_CFB_FILLRECT
>>>  	select FB_CFB_COPYAREA
>>>  	select FB_CFB_IMAGEBLIT
>>> +	select FB_MODE_HELPERS
>>> +	select OF_VIDEOMODE
>>>  	help
>>>  	  This enables support for the AT91/AT32 LCD Controller.
>>>  
>>> diff --git a/drivers/video/atmel_lcdfb.c b/drivers/video/atmel_lcdfb.c
>>> index f67e226..4a31570 100644
>>> --- a/drivers/video/atmel_lcdfb.c
>>> +++ b/drivers/video/atmel_lcdfb.c
>>> @@ -20,7 +20,11 @@
>>>  #include <linux/gfp.h>
>>>  #include <linux/module.h>
>>>  #include <linux/platform_data/atmel.h>
>>> +#include <linux/of.h>
>>> +#include <linux/of_device.h>
>>> +#include <linux/of_gpio.h>
>>>  #include <video/of_display_timing.h>
>>
>> As said in patch 1/8, this one belongs to this 4/8 patch.
>>
>>> +#include <video/videomode.h>
>>>  
>>>  #include <mach/cpu.h>
>>>  #include <asm/gpio.h>
>>> @@ -59,6 +63,13 @@ struct atmel_lcdfb_info {
>>>  	struct atmel_lcdfb_config *config;
>>>  };
>>>  
>>> +struct atmel_lcdfb_power_ctrl_gpio {
>>> +	int gpio;
>>> +	int active_low;
>>> +
>>> +	struct list_head list;
>>> +};
>>> +
>>>  #define lcdc_readl(sinfo, reg)		__raw_readl((sinfo)->mmio+(reg))
>>>  #define lcdc_writel(sinfo, reg, val)	__raw_writel((val), (sinfo)->mmio+(reg))
>>>  
>>> @@ -945,16 +956,187 @@ static void atmel_lcdfb_stop_clock(struct atmel_lcdfb_info *sinfo)
>>>  	clk_disable(sinfo->lcdc_clk);
>>>  }
>>>  
>>> +#ifdef CONFIG_OF
>>> +static const struct of_device_id atmel_lcdfb_dt_ids[] = {
>>> +	{ .compatible = "atmel,at91sam9261-lcdc" , .data = &at91sam9261_config, },
>>> +	{ .compatible = "atmel,at91sam9263-lcdc" , .data = &at91sam9263_config, },
>>> +	{ .compatible = "atmel,at91sam9g10-lcdc" , .data = &at91sam9g10_config, },
>>> +	{ .compatible = "atmel,at91sam9g45-lcdc" , .data = &at91sam9g45_config, },
>>> +	{ .compatible = "atmel,at91sam9g45es-lcdc" , .data = &at91sam9g45es_config, },
>>> +	{ .compatible = "atmel,at91sam9rl-lcdc" , .data = &at91sam9rl_config, },
>>> +	{ .compatible = "atmel,at32ap-lcdc" , .data = &at32ap_config, },
>>> +	{ /* sentinel */ }
>>> +};
>>> +
>>> +MODULE_DEVICE_TABLE(of, atmel_lcdfb_dt_ids);
>>> +
>>> +static const char *atmel_lcdfb_wiring_modes[] = {
>>> +	[ATMEL_LCDC_WIRING_BGR]	= "BRG",
>>> +	[ATMEL_LCDC_WIRING_RGB]	= "RGB",
>>> +};
>>> +
>>> +const int atmel_lcdfb_get_of_wiring_modes(struct device_node *np)
>>> +{
>>> +	const char *mode;
>>> +	int err, i;
>>> +
>>> +	err = of_property_read_string(np, "atmel,lcd-wiring-mode", &mode);
>>> +	if (err < 0)
>>> +		return ATMEL_LCDC_WIRING_BGR;
>>> +
>>> +	for (i = 0; i < ARRAY_SIZE(atmel_lcdfb_wiring_modes); i++)
>>> +		if (!strcasecmp(mode, atmel_lcdfb_wiring_modes[i]))
>>> +			return i;
>>> +
>>> +	return -ENODEV;
>>> +}
>>> +
>>> +static void atmel_lcdfb_power_control_gpio(struct atmel_lcdfb_pdata *pdata, int on)
>>> +{
>>> +	struct atmel_lcdfb_power_ctrl_gpio *og;
>>> +
>>> +	list_for_each_entry(og, &pdata->pwr_gpios, list)
>>> +		gpio_set_value(og->gpio, on);
>>> +}
>>> +
>>> +static int atmel_lcdfb_of_init(struct atmel_lcdfb_info *sinfo)
>>> +{
>>> +	struct fb_info *info = sinfo->info;
>>> +	struct atmel_lcdfb_pdata *pdata = &sinfo->pdata;
>>> +	struct fb_var_screeninfo *var = &info->var;
>>> +	struct device *dev = &sinfo->pdev->dev;
>>> +	struct device_node *np =dev->of_node;
>>> +	struct device_node *display_np;
>>> +	struct device_node *timings_np;
>>> +	struct display_timings *timings;
>>> +	enum of_gpio_flags flags;
>>> +	struct atmel_lcdfb_power_ctrl_gpio *og;
>>> +	bool is_gpio_power = false;
>>> +	int ret = -ENOENT;
>>> +	int i, gpio;
>>> +
>>> +	sinfo->config = (struct atmel_lcdfb_config*)
>>> +		of_match_device(atmel_lcdfb_dt_ids, dev)->data;
>>
>> Please split it in 2 steps, otherwise the day that the drivers doesn't
>> find the device in dt_ids table, it hangs here with an Oops.
> no as you will never end here in this case

Ok, I see.

>>
>>> +
>>> +	display_np = of_parse_phandle(np, "display", 0);
>>> +	if (!display_np) {
>>> +		dev_err(dev, "failed to find display phandle\n");
>>> +		return -ENOENT;
>>> +	}
>>> +
>>> +	ret = of_property_read_u32(display_np, "bits-per-pixel", &var->bits_per_pixel);
>>> +	if (ret < 0) {
>>> +		dev_err(dev, "failed to get property bits-per-pixel\n");
>>> +		goto put_display_node;
>>> +	}
>>> +
>>> +	ret = of_property_read_u32(display_np, "atmel,guard-time", &pdata->guard_time);
>>> +	if (ret < 0) {
>>> +		dev_err(dev, "failed to get property atmel,guard-time\n");
>>> +		goto put_display_node;
>>> +	}
>>> +
>>> +	ret = of_property_read_u32(display_np, "atmel,lcdcon2", &pdata->default_lcdcon2);
>>> +	if (ret < 0) {
>>> +		dev_err(dev, "failed to get property atmel,lcdcon2\n");
>>> +		goto put_display_node;
>>> +	}
>>> +
>>> +	ret = of_property_read_u32(display_np, "atmel,dmacon", &pdata->default_dmacon);
>>> +	if (ret < 0) {
>>> +		dev_err(dev, "failed to get property bits-per-pixel\n");
>>
>> No, wrong error message.
>>
>>> +		goto put_display_node;
>>> +	}
>>> +
>>> +	ret = -ENOMEM;
>>> +	for (i = 0; i < of_gpio_named_count(display_np, "atmel,power-control-gpio"); i++) {
>>> +		gpio = of_get_named_gpio_flags(display_np, "atmel,power-control-gpio",
>>> +					       i, &flags);
>>> +		if (gpio < 0)
>>> +			continue;
>>> +
>>> +		og = devm_kzalloc(dev, sizeof(*og), GFP_KERNEL);
>>> +		if (!og)
>>> +			goto put_display_node;
>>> +
>>> +		og->gpio = gpio;
>>> +		og->active_low = flags & OF_GPIO_ACTIVE_LOW;
>>> +		is_gpio_power = true;
>>> +		ret = devm_gpio_request(dev, gpio, "lcd-power-control-gpio");
>>> +		if (ret) {
>>> +			dev_err(dev, "request gpio %d failed\n", gpio);
>>> +			goto put_display_node;
>>> +		}
>>> +
>>> +		ret = gpio_direction_output(gpio, og->active_low);
>>> +		if (ret) {
>>> +			dev_err(dev, "set direction output gpio %d failed\n", gpio);
>>> +			goto put_display_node;
>>> +		}
>>> +	}
>>> +
>>> +	if (is_gpio_power)
>>> +		pdata->atmel_lcdfb_power_control = atmel_lcdfb_power_control_gpio;
>>> +
>>> +	ret = atmel_lcdfb_get_of_wiring_modes(display_np);
>>> +	if (ret < 0) {
>>> +		dev_err(dev, "invalid atmel,lcd-wiring-mode\n");
>>> +		goto put_display_node;
>>> +	}
>>> +	pdata->lcd_wiring_mode = ret;
>>> +
>>> +	pdata->lcdcon_is_backlight = of_property_read_bool(display_np, "atmel,lcdcon-backlight");
>>> +
>>> +	timings = of_get_display_timings(display_np);
>>> +	if (!timings) {
>>> +		dev_err(dev, "failed to get display timings\n");
>>> +		goto put_display_node;
>>> +	}
>>> +
>>> +	timings_np = of_find_node_by_name(display_np, "display-timings");
>>> +	if (!timings_np) {
>>> +		dev_err(dev, "failed to find display-timings node\n");
>>> +		goto put_display_node;
>>> +	}
>>> +
>>> +	for (i = 0; i < of_get_child_count(timings_np); i++) {
>>> +		struct videomode vm;
>>> +		struct fb_videomode fb_vm;
>>> +
>>> +		ret = videomode_from_timing(timings, &vm, i);
>>> +		if (ret < 0)
>>> +			goto put_timings_node;
>>> +		ret = fb_videomode_from_videomode(&vm, &fb_vm);
>>> +		if (ret < 0)
>>> +			goto put_timings_node;
>>> +
>>> +		fb_add_videomode(&fb_vm, &info->modelist);
>>> +	}
>>> +
>>> +	return 0;
>>> +
>>> +put_timings_node:
>>> +	of_node_put(timings_np);
>>> +put_display_node:
>>> +	of_node_put(display_np);
>>> +	return ret;
>>> +}
>>> +#else
>>> +static int atmel_lcdfb_of_init(struct atmel_lcdfb_info *sinfo)
>>> +{
>>> +	return 0;
>>> +}
>>> +#endif
>>>  
>>>  static int __init atmel_lcdfb_probe(struct platform_device *pdev)
>>>  {
>>>  	struct device *dev = &pdev->dev;
>>>  	struct fb_info *info;
>>>  	struct atmel_lcdfb_info *sinfo;
>>> -	struct atmel_lcdfb_pdata *pdata;
>>> -	struct fb_videomode fbmode;
>>> +	struct atmel_lcdfb_pdata *pdata = NULL;
>>>  	struct resource *regs = NULL;
>>>  	struct resource *map = NULL;
>>> +	struct fb_modelist *modelist;
>>>  	int ret;
>>>  
>>>  	dev_dbg(dev, "%s BEGIN\n", __func__);
>>> @@ -967,17 +1149,35 @@ static int __init atmel_lcdfb_probe(struct platform_device *pdev)
>>>  	}
>>>  
>>>  	sinfo = info->par;
>>> +	sinfo->pdev = pdev;
>>> +	sinfo->info = info;
>>> +
>>> +	INIT_LIST_HEAD(&info->modelist);
>>>  
>>> -	if (dev->platform_data) {
>>> -		pdata = (struct atmel_lcdfb_pdata *)dev->platform_data;
>>> +	if (pdev->dev.of_node) {
>>> +		ret = atmel_lcdfb_of_init(sinfo);
>>> +		if (ret)
>>> +			goto free_info;
>>> +	} else if (dev->platform_data) {
>>> +		struct fb_monspecs *monspecs;
>>> +		int i;
>>> +
>>> +		pdata = dev->platform_data;
>>> +		monspecs = pdata->default_monspecs;
>>>  		sinfo->pdata = *pdata;
>>> +
>>> +		for (i = 0; i < monspecs->modedb_len; i++)
>>> +			fb_add_videomode(&monspecs->modedb[i], &info->modelist);
>>> +
>>> +		sinfo->config = atmel_lcdfb_get_config(pdev);
>>> +
>>> +		info->var.bits_per_pixel = pdata->default_bpp ? pdata->default_bpp : 16;
>>> +		memcpy(&info->monspecs, pdata->default_monspecs, sizeof(info->monspecs));
>>>  	} else {
>>>  		dev_err(dev, "cannot get default configuration\n");
>>>  		goto free_info;
>>>  	}
>>> -	sinfo->info = info;
>>> -	sinfo->pdev = pdev;
>>> -	sinfo->config = atmel_lcdfb_get_config(pdev);
>>> +
>>>  	if (!sinfo->config)
>>>  		goto free_info;
>>>  
>>> @@ -986,7 +1186,6 @@ static int __init atmel_lcdfb_probe(struct platform_device *pdev)
>>>  	info->pseudo_palette = sinfo->pseudo_palette;
>>>  	info->fbops = &atmel_lcdfb_ops;
>>>  
>>> -	memcpy(&info->monspecs, pdata->default_monspecs, sizeof(info->monspecs));
>>>  	info->fix = atmel_lcdfb_fix;
>>>  
>>>  	/* Enable LCDC Clocks */
>>> @@ -1002,14 +1201,11 @@ static int __init atmel_lcdfb_probe(struct platform_device *pdev)
>>>  	}
>>>  	atmel_lcdfb_start_clock(sinfo);
>>>  
>>> -	ret = fb_find_mode(&info->var, info, NULL, info->monspecs.modedb,
>>> -			info->monspecs.modedb_len, info->monspecs.modedb,
>>> -			pdata->default_bpp);
>>> -	if (!ret) {
>>> -		dev_err(dev, "no suitable video mode found\n");
>>> -		goto stop_clk;
>>> -	}
>>> +	modelist = list_first_entry(&info->modelist,
>>> +			struct fb_modelist, list);
>>> +	fb_videomode_to_var(&info->var, &modelist->mode);
>>>  
>>> +	atmel_lcdfb_check_var(&info->var, info);
>>>  
>>>  	regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>>>  	if (!regs) {
>>> @@ -1093,18 +1289,6 @@ static int __init atmel_lcdfb_probe(struct platform_device *pdev)
>>>  		goto unregister_irqs;
>>>  	}
>>>  
>>> -	/*
>>> -	 * This makes sure that our colour bitfield
>>> -	 * descriptors are correctly initialised.
>>> -	 */
>>> -	atmel_lcdfb_check_var(&info->var, info);
>>> -
>>> -	ret = fb_set_var(info, &info->var);
>>> -	if (ret) {
>>> -		dev_warn(dev, "unable to set display parameters\n");
>>> -		goto free_cmap;
>>> -	}
>>> -
>>>  	dev_set_drvdata(dev, info);
>>>  
>>>  	/*
>>> @@ -1116,10 +1300,6 @@ static int __init atmel_lcdfb_probe(struct platform_device *pdev)
>>>  		goto reset_drvdata;
>>>  	}
>>>  
>>> -	/* add selected videomode to modelist */
>>> -	fb_var_to_videomode(&fbmode, &info->var);
>>> -	fb_add_videomode(&fbmode, &info->modelist);
>>> -
>>>  	/* Power up the LCDC screen */
>>>  	atmel_lcdfb_power_control(sinfo, 1);
>>>  
>>> @@ -1130,7 +1310,6 @@ static int __init atmel_lcdfb_probe(struct platform_device *pdev)
>>>  
>>>  reset_drvdata:
>>>  	dev_set_drvdata(dev, NULL);
>>> -free_cmap:
>>>  	fb_dealloc_cmap(&info->cmap);
>>>  unregister_irqs:
>>>  	cancel_work_sync(&sinfo->task);
>>> @@ -1249,6 +1428,7 @@ static struct platform_driver atmel_lcdfb_driver = {
>>>  	.driver		= {
>>>  		.name	= "atmel_lcdfb",
>>>  		.owner	= THIS_MODULE,
>>> +		.of_match_table	= of_match_ptr(atmel_lcdfb_dt_ids),
>>>  	},
>>>  };
>>>  
>>>
>>
>>
>> -- 
>> Nicolas Ferre
> 
> 


-- 
Nicolas Ferre


From plagnioj at jcrosoft.com  Tue Apr 16 11:48:05 2013
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Tue, 16 Apr 2013 17:48:05 +0200
Subject: [PATCH 6/8] ARM: at91: sam9263: add fb dt support
In-Reply-To: <516D6A27.6070202@atmel.com>
References: <20130411145741.GB25242@game.jcrosoft.org>
 <1365692422-9565-1-git-send-email-plagnioj@jcrosoft.com>
 <1365692422-9565-6-git-send-email-plagnioj@jcrosoft.com>
 <516D5C06.1050807@atmel.com>
 <20130416141326.GB4998@game.jcrosoft.org>
 <516D6A27.6070202@atmel.com>
Message-ID: <20130416154805.GC4998@game.jcrosoft.org>

On 17:11 Tue 16 Apr     , Nicolas Ferre wrote:
> On 04/16/2013 04:13 PM, Jean-Christophe PLAGNIOL-VILLARD :
> > On 16:11 Tue 16 Apr     , Nicolas Ferre wrote:
> >> On 04/11/2013 05:00 PM, Jean-Christophe PLAGNIOL-VILLARD :
> >>> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
> >>> Cc: Nicolas Ferre <nicolas.ferre at atmel.com>
> >>> ---
> >>>  arch/arm/boot/dts/at91sam9263.dtsi |   39 ++++++++++++++++++++++++++++++++++++
> >>>  1 file changed, 39 insertions(+)
> >>>
> >>> diff --git a/arch/arm/boot/dts/at91sam9263.dtsi b/arch/arm/boot/dts/at91sam9263.dtsi
> >>> index 271d4de..3d0effa 100644
> >>> --- a/arch/arm/boot/dts/at91sam9263.dtsi
> >>> +++ b/arch/arm/boot/dts/at91sam9263.dtsi
> >>> @@ -303,6 +303,34 @@
> >>>  					};
> >>>  				};
> >>>  
> >>> +				fb {
> >>> +					pinctrl_fb: fb-0 {
> >>> +						atmel,pins =
> >>> +							<2 1 0x1 0x0	/* PC1 periph A */
> >>> +							 2 2 0x1 0x0	/* PC2 periph A */
> >>> +							 2 3 0x1 0x0	/* PC3 periph A */
> >>> +							 1 9 0x2 0x0	/* PB9 periph B */
> >>> +							 2 6 0x1 0x0	/* PC6 periph A */
> >>> +							 2 7 0x1 0x0	/* PC7 periph A */
> >>> +							 2 8 0x1 0x0	/* PC8 periph A */
> >>> +							 2 9 0x1 0x0	/* PC9 periph A */
> >>> +							 2 10 0x1 0x0	/* PC10 periph A */
> >>> +							 2 11 0x1 0x0	/* PC11 periph A */
> >>> +							 2 14 0x1 0x0	/* PC14 periph A */
> >>> +							 2 15 0x1 0x0	/* PC15 periph A */
> >>> +							 2 16 0x1 0x0	/* PC16 periph A */
> >>> +							 2 12 0x2 0x0	/* PC12 periph B */
> >>> +							 2 18 0x1 0x0	/* PC18 periph A */
> >>> +							 2 19 0x1 0x0	/* PC19 periph A */
> >>> +							 2 22 0x1 0x0	/* PC22 periph A */
> >>> +							 2 23 0x1 0x0	/* PC23 periph A */
> >>> +							 2 24 0x1 0x0	/* PC24 periph A */
> >>> +							 2 17 0x2 0x0	/* PC17 periph B */
> >>> +							 2 26 0x1 0x0	/* PC26 periph A */
> >>> +							 2 27 0x1 0x0>;	/* PC27 periph A */
> >>
> >> Verified, okay.
> >>
> >>> +					};
> >>> +				};
> >>> +
> >>>  				pioA: gpio at fffff200 {
> >>>  					compatible = "atmel,at91rm9200-gpio";
> >>>  					reg = <0xfffff200 0x200>;
> >>> @@ -464,6 +492,17 @@
> >>>  			};
> >>>  		};
> >>>  
> >>> +		fb0: fb at 0x00500000 {
> >>
> >> No, it is 0x700000
> >>
> >>> +			compatible = "atmel,at91sam9263-lcdc";
> >>> +			reg = <0x00700000 0x1000>;
> >>
> >> Ditto.
> >>
> >>> +			interrupts = <26 3 0>;
> >>
> >> <26 4 0> here.
> > no lcd is 3 even in c
> > 
> > and even 3 could be slow in some big lcd case
> 
> No, you mean the priority, but priority is encoded as the 3rd cell. So,
> we end up with:
> 
> <26 4 3>
> 
> (I agree with the 3)
I hate those magic number

so this is the las patch to go in with as soon as the macro for dts are in I
free the at91 dts and switch to it
> 
> 
> >>
> >>
> >>> +			pinctrl-names = "default";
> >>> +			pinctrl-0 = <&pinctrl_fb>;
> >>> +			status = "disabled";
> >>> +			#address-cells = <1>;
> >>> +			#size-cells = <1>;
> >>
> >> Ditto in 9g45 case.
> >>
> >>> +		};
> >>> +
> >>>  		nand0: nand at 40000000 {
> >>>  			compatible = "atmel,at91rm9200-nand";
> >>>  			#address-cells = <1>;
> >>>
> >>
> >>
> >> -- 
> >> Nicolas Ferre
> > 
> 
> Bye,
> -- 
> Nicolas Ferre


From broonie at kernel.org  Tue Apr 16 11:58:50 2013
From: broonie at kernel.org (Mark Brown)
Date: Tue, 16 Apr 2013 16:58:50 +0100
Subject: [PATCH V3 RESEND 3/5] spi: s3c64xx: Added provision for non-gpio
 i/o's
In-Reply-To: <1366015230-18243-2-git-send-email-ks.giri@samsung.com>
References: <1366015230-18243-1-git-send-email-ks.giri@samsung.com>
 <1366015230-18243-2-git-send-email-ks.giri@samsung.com>
Message-ID: <20130416155850.GL26958@opensource.wolfsonmicro.com>

On Mon, Apr 15, 2013 at 02:10:28PM +0530, Girish K S wrote:
> From: Girish K S <girishks2000 at gmail.com>
> 
> Currently the drivers supports only the GPIO based i/o pins.
> But there are Exynos SoC's that use the same controller with
> dedicated i/o pins.
> 
> This patch  provides provision to support gpio/dedicated pins.
> The decision is made by parsing the "gpios" property in the spi
> node.

This has some conflicts with my SPI -next branch, I think it's all due
to Arnd's changes to support multi-platform boot on Exynos but there may
be some other stuff.  Can you please rebase against

   git://git.kernel.org/pub/scm/linux/kernel/git/broonie/misc.git spi-next

and make sure everything is OK?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130416/bda0d1b0/attachment.sig>

From cdall at cs.columbia.edu  Tue Apr 16 11:59:22 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Tue, 16 Apr 2013 08:59:22 -0700
Subject: [PATCH] ARM: KVM: iterate over all CPUs for CPU compatibility
 check
In-Reply-To: <CAJRNFKJoBzgt4UhxsH65_LyhcGXPnzB_pg3q-zeYT2OVv59q4A@mail.gmail.com>
References: <1365771875-5788-1-git-send-email-andre.przywara@linaro.org>
 <51680AF9.7040109@arm.com>
 <CAEDV+g+E8PLc60vMRhq4O_AL2WjmYDLb6=Wh34ynhevh7uAGJA@mail.gmail.com>
 <d455f2823b9639af8d38d30f2c3234bd@localhost>
 <CAEDV+gJuFG49oQ=BEaCHcTP=nHVyX8ALw6076dR_C1s7TuyqXQ@mail.gmail.com>
 <d47697abd39a0d5d41f5ac110a40e261@localhost>
 <CAEDV+gK9==sXYxRVZ8JVFYPiw3_xgzZBbydEwPunmnocNLKXrQ@mail.gmail.com>
 <CAFEAcA-bPoa8YoPuHPmupzfUW+yR233XquK79eNorzcRpFiK=g@mail.gmail.com>
 <516BCAD0.9000708@linaro.org>
 <CAJRNFKJoBzgt4UhxsH65_LyhcGXPnzB_pg3q-zeYT2OVv59q4A@mail.gmail.com>
Message-ID: <CAEDV+g+8iE2_8Z6q7NYRPwKNDDBd8MnEEmB8KjrWwvUdSaxXmg@mail.gmail.com>

On Mon, Apr 15, 2013 at 2:52 AM, Alexander Spyridakis
<a.spyridakis at virtualopensystems.com> wrote:
> On 15 April 2013 11:39, Andre Przywara <andre.przywara at linaro.org> wrote:
>>
>> > [Q: does
>> >     all the hyp mode code have to also run on the A15s or
>> >     is it A7-safe?]
>>
>> Good point. It seems like the code hangs in init_hyp_mode().
>> Will do more debugging in there now.
>
>
> I've run on this problem before, while trying to run KVM guests on A7 cores.
>
> For some reason the 3rd A7 hangs in arch/arm/kvm/init.S, on the instruction
> that updates HSCTLR between the two isbs on __do_hyp_init (mcr p15, 4, r0,
> c1, c0, 0). If you boot the system with maxcpus=4 then init_hyp_mode() will
> not hang on the A7 cluster. Other than that from my limited testing KVM on
> A7 works on a usual linux guest. I also tried to only boot the 3rd A7 core
> to rule out any racing issues, but still the same behaviour applies.
>
You lost me on the maxcpus=4 and racing point here. If it works with
maxcpus=4 then it works with two A7s, right? Why would running with
maxcpus=3 (ie. one A7) rule out any race condition?

-Christoffer


From cdall at cs.columbia.edu  Tue Apr 16 12:03:45 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Tue, 16 Apr 2013 09:03:45 -0700
Subject: [PATCH] ARM: KVM: iterate over all CPUs for CPU compatibility
 check
In-Reply-To: <CAEDV+g+8iE2_8Z6q7NYRPwKNDDBd8MnEEmB8KjrWwvUdSaxXmg@mail.gmail.com>
References: <1365771875-5788-1-git-send-email-andre.przywara@linaro.org>
 <51680AF9.7040109@arm.com>
 <CAEDV+g+E8PLc60vMRhq4O_AL2WjmYDLb6=Wh34ynhevh7uAGJA@mail.gmail.com>
 <d455f2823b9639af8d38d30f2c3234bd@localhost>
 <CAEDV+gJuFG49oQ=BEaCHcTP=nHVyX8ALw6076dR_C1s7TuyqXQ@mail.gmail.com>
 <d47697abd39a0d5d41f5ac110a40e261@localhost>
 <CAEDV+gK9==sXYxRVZ8JVFYPiw3_xgzZBbydEwPunmnocNLKXrQ@mail.gmail.com>
 <CAFEAcA-bPoa8YoPuHPmupzfUW+yR233XquK79eNorzcRpFiK=g@mail.gmail.com>
 <516BCAD0.9000708@linaro.org>
 <CAJRNFKJoBzgt4UhxsH65_LyhcGXPnzB_pg3q-zeYT2OVv59q4A@mail.gmail.com>
 <CAEDV+g+8iE2_8Z6q7NYRPwKNDDBd8MnEEmB8KjrWwvUdSaxXmg@mail.gmail.com>
Message-ID: <CAEDV+gJr9bK6FNkH3o+xVup7p3hrOZ+piB_hExzht4=USFvhBQ@mail.gmail.com>

On Tue, Apr 16, 2013 at 8:59 AM, Christoffer Dall <cdall at cs.columbia.edu> wrote:
> On Mon, Apr 15, 2013 at 2:52 AM, Alexander Spyridakis
> <a.spyridakis at virtualopensystems.com> wrote:
>> On 15 April 2013 11:39, Andre Przywara <andre.przywara at linaro.org> wrote:
>>>
>>> > [Q: does
>>> >     all the hyp mode code have to also run on the A15s or
>>> >     is it A7-safe?]
>>>
>>> Good point. It seems like the code hangs in init_hyp_mode().
>>> Will do more debugging in there now.
>>
>>
>> I've run on this problem before, while trying to run KVM guests on A7 cores.
>>
>> For some reason the 3rd A7 hangs in arch/arm/kvm/init.S, on the instruction
>> that updates HSCTLR between the two isbs on __do_hyp_init (mcr p15, 4, r0,
>> c1, c0, 0). If you boot the system with maxcpus=4 then init_hyp_mode() will
>> not hang on the A7 cluster. Other than that from my limited testing KVM on
>> A7 works on a usual linux guest. I also tried to only boot the 3rd A7 core
>> to rule out any racing issues, but still the same behaviour applies.
>>
> You lost me on the maxcpus=4 and racing point here. If it works with
> maxcpus=4 then it works with two A7s, right? Why would running with
> maxcpus=3 (ie. one A7) rule out any race condition?
>
[resending this as someone misspelled Marc's e-mail]


From catalin.marinas at arm.com  Tue Apr 16 12:04:19 2013
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Tue, 16 Apr 2013 17:04:19 +0100
Subject: [PATCH] Report double word access atomicity on LPAE enabled
 targets through AUXV
In-Reply-To: <CD54D5A4-2E19-49D9-B6E7-051F36AB5DF8@oracle.com>
References: <C3FF039D-7DE3-4A99-8317-789094095D8B@oracle.com>
 <20130408142406.GL17995@n2100.arm.linux.org.uk>
 <20130408155749.GS17476@mudshark.cambridge.arm.com>
 <CD54D5A4-2E19-49D9-B6E7-051F36AB5DF8@oracle.com>
Message-ID: <20130416160419.GC30292@arm.com>

On Fri, Apr 12, 2013 at 09:58:43PM +0100, Vladimir Danushevsky wrote:
> Below is a modified patch based on suggestions so far:

You need to add a description, maybe just the comment that you already
added in the code.

> Signed-off-by: Vladimir Danushevsky <vladimir.danushevsky at oracle.com>
> 
>  include/uapi/asm/hwcap.h |    1 +
>  kernel/setup.c           |   13 +++++++++++--
>  2 files changed, 12 insertions(+), 2 deletions(-)

Otherwise,

Acked-by: Catalin Marinas <catalin.marinas at arm.com>


From swarren at wwwdotorg.org  Tue Apr 16 11:57:29 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Tue, 16 Apr 2013 09:57:29 -0600
Subject: [RFC PATCH 2/2] ARM: DT: kernel: DT cpu node bindings update
In-Reply-To: <20130416104545.GA19837@e102568-lin.cambridge.arm.com>
References: <1366042402-8987-1-git-send-email-lorenzo.pieralisi@arm.com>
 <1366042402-8987-3-git-send-email-lorenzo.pieralisi@arm.com>
 <516C544A.4090107@wwwdotorg.org>
 <20130416104545.GA19837@e102568-lin.cambridge.arm.com>
Message-ID: <516D74E9.9030404@wwwdotorg.org>

On 04/16/2013 04:45 AM, Lorenzo Pieralisi wrote:
> Thanks Stephen for the review.
> 
> On Mon, Apr 15, 2013 at 08:26:02PM +0100, Stephen Warren wrote:
>> On 04/15/2013 10:13 AM, Lorenzo Pieralisi wrote:
>>> In order to extend the current cpu nodes bindings to newer CPUs
>>> inclusive of AArch64 and to update support for older ARM CPUs this
>>> patch updates device tree documentation for the cpu nodes bindings.
>>>
>>
>>> diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt
>>
>>>  http://devicetree.org
>>>  
>>> -For the ARM architecture every CPU node must contain the following properties:
>>> -
>> ...
>>> +with updates for 32-bit and 64-bit ARM systems provided in this document.
>>> +
>>> +In the bindings below:
>>
>> That's a slightly odd change, since it removes the statement that a cpus
>> node must exist, and "in the bindings below" is not idiomatic for DT
>> binding definitions.
> 
> I beg to differ.
> 
> "Bindings for CPU nodes follow the ePAPR standard...."
> 
> ePAPR v1.1
> 
> 3.6 CPUS node properties
> 
> "A cpus node is required for all device trees".

Hmm, OK, I guess that's true. Still, I think this binding was pretty
much complete without having to read that document before wasn't it, yet
now it isn't? I suppose that's OK.

>> Perhaps replace that last list with:
>>
>> The ARM architecture requires the following properties in the cpus and
>> cpu nodes contain the properties described below.
>>
>>> +- square brackets define bitfields, eg reg[7:0] value of the bitfield in
>>> +  the reg property contained in bits 7 down to 0
>>
>> Isn't that standard enough it's not even worth mentioning? If it is,
>> it's certainly not something that should be mentioned in the part of the
>> document that describes which properties are requried.
> 
> It is mentioned before cpus node and cpu node descriptions start.

It's in the list "In the bindings below", which kinda lumps together
some syntax definitions for the text, and the actual semantic
definitions of the node contents.

>>> +	- #address-cells
>>> +		Usage: required
>>
>> "Usage" sounds more like what it's used for. "Presence" seems better to me.
> 
> I have not reinvented the wheel, just had a look at powerPC bindings and
> tried to comply. If "Usage" is not proper we also have to patch a number
> of in-kernel DT bindings and update the ePAPR.

The existing language seems unfortunate. I suppose it makes sense to
follow it since this document is defining a "sub class" of it, but
still, I'd still be tempted just to use the right word.

>>> +	- enable-method
>>> +		Usage: required on ARM 64-bit systems, optional on ARM 32-bit
>>> +		       systems
>>> +		Value type: <string>
>>> +		Definition: On ARM 64-bit systems must be "spin-table" [1].
>>
>> Can that be an integer instead? with dtc+cpp support, that shouldn't
>> hurt the eyes too much any more.
> 
> Mmm, I need to read more on dtc+cpp, I do not think that leaving it
> as a string would hurt though, am I wrong ? Can we assume that all dts
> are preprocessed before being compiled and passed to the kernel ?

It wouldn't hurt too much, but representing enums as strings when
there's a capability to simply represent it as a integer just feels
pretty gross to me.

>>> +[1] ARM Linux kernel documentation
>>> +    Documentation/devicetree/bindings/arm64/booting.txt
>>
>> Is referencing Linux-specific documentation from a supposedly
>> OS-agnostic DT binding definition a good idea?
> 
> Well, an OS-agnostic DT binding definition in the Linux kernel Documentation
> directory.

I think that's mainly a historical "accident". There is perpetual talk
of moving the bindings directory, and even the .dts files I believe, to
a separate repository to make this distinction clear.


From swarren at wwwdotorg.org  Tue Apr 16 12:20:11 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Tue, 16 Apr 2013 10:20:11 -0600
Subject: [PATCH 3/3] ARM: tegra: make sure the pointer on 4 byte align
 when THUMB2_KERNEL enabled
In-Reply-To: <20130416141252.GA2229@linaro.org>
References: <1366066255-18192-1-git-send-email-swarren@wwwdotorg.org>
 <1366066255-18192-3-git-send-email-swarren@wwwdotorg.org>
 <20130416141252.GA2229@linaro.org>
Message-ID: <516D7A3B.9030404@wwwdotorg.org>

On 04/16/2013 08:13 AM, Dave Martin wrote:
> On Mon, Apr 15, 2013 at 04:50:55PM -0600, Stephen Warren wrote:
>> From: Joseph Lo <josephl at nvidia.com>
>>
>> When building kernel with CONFIG_THUMB2_KERNEL, the data pointer in the
>> assembly may not on the 4 byte alignment. Then causing a data abort when
>> accessing the pointer. This patch add a ".align" flag in the head of the
>> pointer. And always using 32-bit ADR Thumb instruction to make sure it
>> won't build failure.
>>
>> Signed-off-by: Joseph Lo <josephl at nvidia.com>
>> Signed-off-by: Stephen Warren <swarren at nvidia.com>
>> ---
>>  arch/arm/mach-tegra/reset-handler.S |    1 +
>>  arch/arm/mach-tegra/sleep.h         |    3 ++-
>>  2 files changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/mach-tegra/reset-handler.S b/arch/arm/mach-tegra/reset-handler.S
>> index e6de88a..519a8c5 100644
>> --- a/arch/arm/mach-tegra/reset-handler.S
>> +++ b/arch/arm/mach-tegra/reset-handler.S
>> @@ -83,6 +83,7 @@ ENDPROC(tegra_resume)
>>  
>>  #ifdef CONFIG_CACHE_L2X0
>>  	.globl	l2x0_saved_regs_addr
>> +	.align
>>  l2x0_saved_regs_addr:
>>  	.long	0
>>  #endif
>> diff --git a/arch/arm/mach-tegra/sleep.h b/arch/arm/mach-tegra/sleep.h
>> index 4ffae54..8e9b6af 100644
>> --- a/arch/arm/mach-tegra/sleep.h
>> +++ b/arch/arm/mach-tegra/sleep.h
>> @@ -92,7 +92,8 @@
>>  
>>  #ifdef CONFIG_CACHE_L2X0
>>  .macro l2_cache_resume, tmp1, tmp2, tmp3, phys_l2x0_saved_regs
>> -	adr	\tmp1, \phys_l2x0_saved_regs
>> + ARM(	adr	\tmp1, \phys_l2x0_saved_regs )
>> + THUMB(	adr.w	\tmp1, \phys_l2x0_saved_regs )
> 
> Can you give an example of the assembler error you get without this?

arch/arm/mach-tegra/reset-handler.S: Assembler messages:
arch/arm/mach-tegra/reset-handler.S:78: Error: invalid immediate for
address calculation (value = 0x00000004)

This is with gcc-4.5.3, as:
GNU assembler (crosstool-NG hg_unknown at 20110628.165246) 2.20.1.20100303

> The target symbol is local and the assembler can see where it is,
> so it should choose the correct variant for the adr instruction
> with no need for the ".w" suffix.
> 
> If not, it could mean that there is a bug in the version of the
> assembler you're using.

True. Switching to the Ubuntu-packaged ARM cross-compiler that ships
with Ubuntu 12.10, I do not see this problem.

Still, many people probably still use older compilers.

> If it's definitely needed, you can append a Thumb-only .w suffix with
> 
> 	W(adr)	\tmp1, \phys_l2x0_saved_regs
> 
> ...which is slightly neater.

Yes, that certainly works too, even without the .align change in
reset-handler.S.

Arnd, Olof, I guess let's drop this once patch from this series, but
apply the other two, and I'll send an updated version of this one patch.
Thanks.


From benh at kernel.crashing.org  Tue Apr 16 12:21:08 2013
From: benh at kernel.crashing.org (Benjamin Herrenschmidt)
Date: Tue, 16 Apr 2013 18:21:08 +0200
Subject: [RFC PATCH 2/2] ARM: DT: kernel: DT cpu node bindings update
In-Reply-To: <516D74E9.9030404@wwwdotorg.org>
References: <1366042402-8987-1-git-send-email-lorenzo.pieralisi@arm.com>
 <1366042402-8987-3-git-send-email-lorenzo.pieralisi@arm.com>
 <516C544A.4090107@wwwdotorg.org>
 <20130416104545.GA19837@e102568-lin.cambridge.arm.com>
 <516D74E9.9030404@wwwdotorg.org>
Message-ID: <1366129268.24994.60.camel@pasglop>

On Tue, 2013-04-16 at 09:57 -0600, Stephen Warren wrote:
> > Mmm, I need to read more on dtc+cpp, I do not think that leaving it
> > as a string would hurt though, am I wrong ? Can we assume that all
> dts
> > are preprocessed before being compiled and passed to the kernel ?
> 
> It wouldn't hurt too much, but representing enums as strings when
> there's a capability to simply represent it as a integer just feels
> pretty gross to me.

It's the other way around...

Unless there's a direct semantic meaning of the numbers, things like
that (ie. "methods") should be represented as strings.

Else we fall back to the realm of "magic numbers" which sucks and causes
all sort of pains when several new methods get added by different
people, etc...

The tree is meant to be generally human readable and we should stick to
that. The tiny memory usage is irrelevant on any modern setup.

Cheers,
Ben.




From broonie at kernel.org  Tue Apr 16 12:22:57 2013
From: broonie at kernel.org (Mark Brown)
Date: Tue, 16 Apr 2013 17:22:57 +0100
Subject: [PATCH v5 00/14] ARM: samsung-time: Prepare for multiplatform
 support
In-Reply-To: <1365794250-14436-1-git-send-email-t.figa@samsung.com>
References: <1365794250-14436-1-git-send-email-t.figa@samsung.com>
Message-ID: <20130416162256.GM26958@opensource.wolfsonmicro.com>

On Fri, Apr 12, 2013 at 09:17:16PM +0200, Tomasz Figa wrote:
> This series is an attempt to make the samsung-time clocksource driver ready
> for multiplatform kernels. It moves the driver to drivers/clocksource, cleans
> it up from uses of static platform-specific definitions, simplifies timer
> interrupt handling and adds Device Tree support.

Tested-by: Mark Brown <broonie at opensource.wolfsonmicro.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130416/4c95907a/attachment-0001.sig>

From cdall at cs.columbia.edu  Tue Apr 16 12:24:03 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Tue, 16 Apr 2013 09:24:03 -0700
Subject: [PATCH] ARM: KVM: iterate over all CPUs for CPU compatibility
 check
In-Reply-To: <1366071996.10931.15.camel@smoke>
References: <1365771875-5788-1-git-send-email-andre.przywara@linaro.org>
 <51680AF9.7040109@arm.com>
 <CAEDV+g+E8PLc60vMRhq4O_AL2WjmYDLb6=Wh34ynhevh7uAGJA@mail.gmail.com>
 <1366071996.10931.15.camel@smoke>
Message-ID: <CAEDV+gKbmbdg-xX2Zf5febaeJv5TzLdLZZ5ZrEX9xGc0zsdZQw@mail.gmail.com>

On Mon, Apr 15, 2013 at 5:26 PM, Geoff Levand <geoff at infradead.org> wrote:
> On Sun, 2013-04-14 at 21:57 -0700, Christoffer Dall wrote:
>> On Fri, Apr 12, 2013 at 6:24 AM, Marc Zyngier <marc.zyngier at arm.com> wrote:
>> Nak. The fact that one of the CPUs seem to hang is a sure sign that
>> > something is severely broken, and you definitely want to fix that issue,
>> > instead of blindly ignoring it.
>> >
>> > Additionally, it seems you're just papering over the issue. You should
>> > be able to exclude the A7 processors, but not completely deny KVM from
>> > running on the hardware.
>> >
>> Marc, I disagree with this nak. If the current kernel breaks boot on a
>> Big.Little system, we need to take care of that first, and the
>> proposed patch is a quick way to do so, and it does not stand in the
>> way of introducing proper Big.Little support in any way, which I'm
>> sure is going to open up a lot of other interesting questions.
>>
>> I'm going to take this one.
>
> Since this problem will cause the 3.9 kernel to hang then a workaround
> like this should go in.  There isn't enough time to do a proper fix for
> 3.9, and even if it could be done I think it would be too intrusive to
> get merged this late.
>
That's why I was inclined to take the patch, but as Marc pointed out
the error message is incorrect, so that should be fixed at the very
least. Also I don't think we need the counting logic, just bail out if
we have any CPUs that are not supported.

Marc, since you're the strongest opponent of this patch, are you still
opposed to making sure we don't try to run KVM on Big.Little until
support is properly introduced?

I also cannot see how we can fix the affinity issue easily from within
the kernel, do you have a concrete approach in mind you can share?

Note that this is irrespective of the boot delay issue that you guys
are observing.

-Christoffer


From cdall at cs.columbia.edu  Tue Apr 16 12:26:26 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Tue, 16 Apr 2013 09:26:26 -0700
Subject: [PATCH] ARM: KVM: iterate over all CPUs for CPU compatibility
 check
In-Reply-To: <20130415134837.GI9827@mudshark.cambridge.arm.com>
References: <51680AF9.7040109@arm.com>
 <CAEDV+g+E8PLc60vMRhq4O_AL2WjmYDLb6=Wh34ynhevh7uAGJA@mail.gmail.com>
 <d455f2823b9639af8d38d30f2c3234bd@localhost>
 <CAEDV+gJuFG49oQ=BEaCHcTP=nHVyX8ALw6076dR_C1s7TuyqXQ@mail.gmail.com>
 <d47697abd39a0d5d41f5ac110a40e261@localhost>
 <CAEDV+gK9==sXYxRVZ8JVFYPiw3_xgzZBbydEwPunmnocNLKXrQ@mail.gmail.com>
 <CAFEAcA-bPoa8YoPuHPmupzfUW+yR233XquK79eNorzcRpFiK=g@mail.gmail.com>
 <516BCAD0.9000708@linaro.org>
 <CAJRNFKJoBzgt4UhxsH65_LyhcGXPnzB_pg3q-zeYT2OVv59q4A@mail.gmail.com>
 <516BFD13.1000400@linaro.org>
 <20130415134837.GI9827@mudshark.cambridge.arm.com>
Message-ID: <CAEDV+gJB7Bj9O7pftFqoYQ=goORjdurBnEfQVmC5arDuNJfpBg@mail.gmail.com>

On Mon, Apr 15, 2013 at 6:48 AM, Will Deacon <will.deacon at arm.com> wrote:
> On Mon, Apr 15, 2013 at 02:13:55PM +0100, Andre Przywara wrote:
>> On 04/15/2013 11:52 AM, Alexander Spyridakis wrote:
>> > I've run on this problem before, while trying to run KVM guests on A7 cores.
>> >
>> > For some reason the 3rd A7 hangs in arch/arm/kvm/init.S, on the
>> > instruction that updates HSCTLR between the two isbs on __do_hyp_init
>> > (mcr p15, 4, r0, c1, c0, 0). If you boot the system with maxcpus=4 then
>> > init_hyp_mode() will not hang on the A7 cluster. Other than that from my
>> > limited testing KVM on A7 works on a usual linux guest. I also tried to
>> > only boot the 3rd A7 core to rule out any racing issues, but still the
>> > same behaviour applies.
>>
>> Could well be the same issue here. I chased it down till CPU 2 goes into
>> HYP mode to do the initialization.
>> I am running with maxcpus=3 (this increases the likelyhood that
>> kvm_target_cpu() runs on an A15), so CPU #2 is the only one A7.
>> As the HYP mode exception table is empty except for the HVC trap, it may
>> be looping here. I am trying now to get the PC of the faulty instruction.
>
> Yes, it sounds like you're taking a recursive fault because the vectors
> aren't installed yet. Is there any chance you can find out what value you end
> up writing (or trying to write) to the HSCTLR please?
>
Actually I'm a little confused, wasn't Andre seeing a halt on an A15
cpu, not an A7? Or is the theory that an A7 locks up and the calling
A15 hangs on the SMP call to cpu_init_hyp_mode, waiting for the A7 to
complete?

-Christoffer


From broonie at kernel.org  Tue Apr 16 12:26:43 2013
From: broonie at kernel.org (Mark Brown)
Date: Tue, 16 Apr 2013 17:26:43 +0100
Subject: [PATCH v5 2/6] ARM: s3c64xx: Skip legacy EINT setup if
 pinctrl-s3c64xx driver is present
In-Reply-To: <1366060483-20342-3-git-send-email-tomasz.figa@gmail.com>
References: <1366060483-20342-1-git-send-email-tomasz.figa@gmail.com>
 <1366060483-20342-3-git-send-email-tomasz.figa@gmail.com>
Message-ID: <20130416162642.GN26958@opensource.wolfsonmicro.com>

On Mon, Apr 15, 2013 at 11:14:39PM +0200, Tomasz Figa wrote:

> +	* This gpio driver includes support for device tree support and there
> +	* are platforms using it. In order to maintain compatibility with those
> +	* platforms, and to allow non-dt Exynos4210 platforms to use this
> +	* gpiolib support, a check is added to find out if there is a active

Cut'n'paste error here.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130416/32076ae8/attachment.sig>

From broonie at kernel.org  Tue Apr 16 12:27:50 2013
From: broonie at kernel.org (Mark Brown)
Date: Tue, 16 Apr 2013 17:27:50 +0100
Subject: [PATCH v5 3/6] gpio: samsung: Skip legacy GPIO registration if
 pinctrl-s3c64xx is present
In-Reply-To: <1366060483-20342-4-git-send-email-tomasz.figa@gmail.com>
References: <1366060483-20342-1-git-send-email-tomasz.figa@gmail.com>
 <1366060483-20342-4-git-send-email-tomasz.figa@gmail.com>
Message-ID: <20130416162750.GO26958@opensource.wolfsonmicro.com>

On Mon, Apr 15, 2013 at 11:14:40PM +0200, Tomasz Figa wrote:

>  		{ .compatible = "samsung,exynos4x12-pinctrl", },
>  		{ .compatible = "samsung,exynos5250-pinctrl", },
>  		{ .compatible = "samsung,exynos5440-pinctrl", },
> +		{ },

Strictly speaking this is a separate bug fix (though I see that's
already in -next separately anyway so whatever).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130416/a1200eaa/attachment.sig>

From dianders at chromium.org  Tue Apr 16 12:29:01 2013
From: dianders at chromium.org (Doug Anderson)
Date: Tue, 16 Apr 2013 09:29:01 -0700
Subject: [PATCH v6 2/3] ARM: dts: Add i2c-arbitrator bus for exynos5250-snow
In-Reply-To: <1366129742-16048-1-git-send-email-dianders@chromium.org>
References: <1365543270-10736-1-git-send-email-dianders@chromium.org>
 <1366129742-16048-1-git-send-email-dianders@chromium.org>
Message-ID: <1366129742-16048-2-git-send-email-dianders@chromium.org>

We need to use the i2c-arbitrator to talk to any of the devices on i2c
bus 4 on exynos5250-snow so that we don't confuse the embedded
controller (EC).  Add the i2c-arbitrator to the device tree.  As we
add future devices (keyboard, sbs, tps65090) we'll add them on top of
this.

The arbitrated bus is numbered 104 simply as a convenience to make it
easier for people poking around to guess that it might have something
to do with the physical bus 4.

The addition is split between the cros5250-common and the snow device
tree file since not all cros5250-class devices use arbitration.

Signed-off-by: Doug Anderson <dianders at chromium.org>
---
Changes in v6: None
Changes in v5:
- Adjust bindings as per Wolfram Sang.

Changes in v4:
- Changed mux gpio syntax to work atop Thomas's "ARM: dts: add pin
  state information in client nodes for Exynos5 platforms"; avoid
  adding gpios property to i2c at 12CA0000 for the same reason.

Changes in v3: None
Changes in v2:
- Use new device tree property names / compatible string.
- Include that the GPIOs for arbitration are active low.

 arch/arm/boot/dts/cros5250-common.dtsi |  3 ++-
 arch/arm/boot/dts/exynos5250-snow.dts  | 25 +++++++++++++++++++++++++
 2 files changed, 27 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/cros5250-common.dtsi b/arch/arm/boot/dts/cros5250-common.dtsi
index 8a5b3a6..0a61bbb 100644
--- a/arch/arm/boot/dts/cros5250-common.dtsi
+++ b/arch/arm/boot/dts/cros5250-common.dtsi
@@ -193,7 +193,8 @@
 	};
 
 	i2c at 12CA0000 {
-		status = "disabled";
+		samsung,i2c-sda-delay = <100>;
+		samsung,i2c-max-bus-freq = <66000>;
 	};
 
 	i2c at 12CB0000 {
diff --git a/arch/arm/boot/dts/exynos5250-snow.dts b/arch/arm/boot/dts/exynos5250-snow.dts
index 581ffae..fa85f58 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -16,6 +16,10 @@
 	model = "Google Snow";
 	compatible = "google,snow", "samsung,exynos5250";
 
+	aliases {
+		i2c104 = &i2c_104;
+	};
+
 	pinctrl at 11400000 {
 		sd3_clk: sd3-clk {
 			samsung,pin-drv = <0>;
@@ -44,6 +48,27 @@
 		};
 	};
 
+	i2c-arbitrator {
+		compatible = "i2c-arb-gpio-challenge";
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		i2c-parent = <&{/i2c at 12CA0000}>;
+
+		our-claim-gpio = <&gpf0 3 1>;
+		their-claim-gpios = <&gpe0 4 1>;
+		slew-delay-us = <10>;
+		wait-retry-us = <3000>;
+		wait-free-us = <50000>;
+
+		/* Use ID 104 as a hint that we're on physical bus 4 */
+		i2c_104: i2c at 0 {
+			reg = <0>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+	};
+
 	/*
 	 * On Snow we've got SIP WiFi and so can keep drive strengths low to
 	 * reduce EMI.
-- 
1.8.1.3



From dianders at chromium.org  Tue Apr 16 12:29:02 2013
From: dianders at chromium.org (Doug Anderson)
Date: Tue, 16 Apr 2013 09:29:02 -0700
Subject: [PATCH v6 3/3] ARM: dts: Add sbs-battery for exynos5250-snow
In-Reply-To: <1366129742-16048-1-git-send-email-dianders@chromium.org>
References: <1365543270-10736-1-git-send-email-dianders@chromium.org>
 <1366129742-16048-1-git-send-email-dianders@chromium.org>
Message-ID: <1366129742-16048-3-git-send-email-dianders@chromium.org>

Now that we have i2c-arbitrator in place on bus 4 we can add the
sbs-battery driver.  Future devices will be added onto bus 4 once
drivers are in good shape.

Signed-off-by: Doug Anderson <dianders at chromium.org>
---
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 arch/arm/boot/dts/exynos5250-snow.dts | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5250-snow.dts b/arch/arm/boot/dts/exynos5250-snow.dts
index fa85f58..c115143 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -66,6 +66,12 @@
 			reg = <0>;
 			#address-cells = <1>;
 			#size-cells = <0>;
+
+			battery: sbs-battery at b {
+				compatible = "sbs,sbs-battery";
+				reg = <0xb>;
+				sbs,poll-retry-count = <1>;
+			};
 		};
 	};
 
-- 
1.8.1.3



From marc.zyngier at arm.com  Tue Apr 16 12:33:05 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Tue, 16 Apr 2013 18:33:05 +0200
Subject: [PATCH] ARM: KVM: iterate over all CPUs for CPU compatibility
 check
In-Reply-To: <CAEDV+gJB7Bj9O7pftFqoYQ=goORjdurBnEfQVmC5arDuNJfpBg@mail.gmail.com>
References: <51680AF9.7040109@arm.com>
 <CAEDV+g+E8PLc60vMRhq4O_AL2WjmYDLb6=Wh34ynhevh7uAGJA@mail.gmail.com>
 <d455f2823b9639af8d38d30f2c3234bd@localhost>
 <CAEDV+gJuFG49oQ=BEaCHcTP=nHVyX8ALw6076dR_C1s7TuyqXQ@mail.gmail.com>
 <d47697abd39a0d5d41f5ac110a40e261@localhost>
 <CAEDV+gK9==sXYxRVZ8JVFYPiw3_xgzZBbydEwPunmnocNLKXrQ@mail.gmail.com>
 <CAFEAcA-bPoa8YoPuHPmupzfUW+yR233XquK79eNorzcRpFiK=g@mail.gmail.com>
 <516BCAD0.9000708@linaro.org>
 <CAJRNFKJoBzgt4UhxsH65_LyhcGXPnzB_pg3q-zeYT2OVv59q4A@mail.gmail.com>
 <516BFD13.1000400@linaro.org>
 <20130415134837.GI9827@mudshark.cambridge.arm.com>
 <CAEDV+gJB7Bj9O7pftFqoYQ=goORjdurBnEfQVmC5arDuNJfpBg@mail.gmail.com>
Message-ID: <32d532438f5b621e40679aea9f5888c7@localhost>

On Tue, 16 Apr 2013 09:26:26 -0700, Christoffer Dall
<cdall at cs.columbia.edu> wrote:
> On Mon, Apr 15, 2013 at 6:48 AM, Will Deacon <will.deacon at arm.com>
wrote:
>> On Mon, Apr 15, 2013 at 02:13:55PM +0100, Andre Przywara wrote:
>>> On 04/15/2013 11:52 AM, Alexander Spyridakis wrote:
>>> > I've run on this problem before, while trying to run KVM guests on
A7
>>> > cores.
>>> >
>>> > For some reason the 3rd A7 hangs in arch/arm/kvm/init.S, on the
>>> > instruction that updates HSCTLR between the two isbs on
__do_hyp_init
>>> > (mcr p15, 4, r0, c1, c0, 0). If you boot the system with maxcpus=4
>>> > then
>>> > init_hyp_mode() will not hang on the A7 cluster. Other than that
from
>>> > my
>>> > limited testing KVM on A7 works on a usual linux guest. I also tried
>>> > to
>>> > only boot the 3rd A7 core to rule out any racing issues, but still
the
>>> > same behaviour applies.
>>>
>>> Could well be the same issue here. I chased it down till CPU 2 goes
into
>>> HYP mode to do the initialization.
>>> I am running with maxcpus=3 (this increases the likelyhood that
>>> kvm_target_cpu() runs on an A15), so CPU #2 is the only one A7.
>>> As the HYP mode exception table is empty except for the HVC trap, it
may
>>> be looping here. I am trying now to get the PC of the faulty
>>> instruction.
>>
>> Yes, it sounds like you're taking a recursive fault because the vectors
>> aren't installed yet. Is there any chance you can find out what value
>> you end
>> up writing (or trying to write) to the HSCTLR please?
>>
> Actually I'm a little confused, wasn't Andre seeing a halt on an A15
> cpu, not an A7? Or is the theory that an A7 locks up and the calling
> A15 hangs on the SMP call to cpu_init_hyp_mode, waiting for the A7 to
> complete?

Yes, A15 hanging, not A7. That's why I'm strongly opposed to this patch.
I'm pretty sure the A7s only have a side effect that triggers a kernel bug
on the A15 side. Before taking *any* patch around this, we should
understand the issue fully, and not start patching random stuff just
because Linus is going to tag 3.9.

        M.
-- 
Fast, cheap, reliable. Pick two.


From broonie at kernel.org  Tue Apr 16 12:33:32 2013
From: broonie at kernel.org (Mark Brown)
Date: Tue, 16 Apr 2013 17:33:32 +0100
Subject: [PATCH v5 0/6] Initial Device Tree support for S3C64xx
In-Reply-To: <1366060483-20342-1-git-send-email-tomasz.figa@gmail.com>
References: <1366060483-20342-1-git-send-email-tomasz.figa@gmail.com>
Message-ID: <20130416163331.GP26958@opensource.wolfsonmicro.com>

On Mon, Apr 15, 2013 at 11:14:37PM +0200, Tomasz Figa wrote:
> This series adds Device Tree support for Samsung S3C64xx SoC series.
> 
> It fixes several problems preventing from booting an S3C64xx-based system
> using Device Tree, adds all the infrastructure for Device Tree-based board
> support, including mach-s3c64xx-dt and dts include files for S3C64xx SoCs,
> and basic device tree source for FriendlyARM Mini6410 board.

I tried to test this but the pinctrl driver doesn't build in -next
(drivers/pinctrl/pinctrl-s3c64xx.c:418:9: error: undefined identifier
'chained_irq_enter') - will check properly tomorrow, need to leave now.
But that's separate anyway. :P

Reviewed-by: Mark Brown <broonie at opensource.wolfsonmicro.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130416/f5621dd8/attachment.sig>

From olof at lixom.net  Tue Apr 16 12:35:26 2013
From: olof at lixom.net (Olof Johansson)
Date: Tue, 16 Apr 2013 09:35:26 -0700
Subject: [PATCH v6 2/3] ARM: dts: Add i2c-arbitrator bus for
 exynos5250-snow
In-Reply-To: <1366129742-16048-2-git-send-email-dianders@chromium.org>
References: <1365543270-10736-1-git-send-email-dianders@chromium.org>
 <1366129742-16048-1-git-send-email-dianders@chromium.org>
 <1366129742-16048-2-git-send-email-dianders@chromium.org>
Message-ID: <20130416163526.GB4918@quad.lixom.net>

On Tue, Apr 16, 2013 at 09:29:01AM -0700, Doug Anderson wrote:
> We need to use the i2c-arbitrator to talk to any of the devices on i2c
> bus 4 on exynos5250-snow so that we don't confuse the embedded
> controller (EC).  Add the i2c-arbitrator to the device tree.  As we
> add future devices (keyboard, sbs, tps65090) we'll add them on top of
> this.
> 
> The arbitrated bus is numbered 104 simply as a convenience to make it
> easier for people poking around to guess that it might have something
> to do with the physical bus 4.
> 
> The addition is split between the cros5250-common and the snow device
> tree file since not all cros5250-class devices use arbitration.
> 
> Signed-off-by: Doug Anderson <dianders at chromium.org>

Acked-by: Olof Johansson <olof at lixom.net>


-Olof


From olof at lixom.net  Tue Apr 16 12:36:00 2013
From: olof at lixom.net (Olof Johansson)
Date: Tue, 16 Apr 2013 09:36:00 -0700
Subject: [PATCH v6 3/3] ARM: dts: Add sbs-battery for exynos5250-snow
In-Reply-To: <1366129742-16048-3-git-send-email-dianders@chromium.org>
References: <1365543270-10736-1-git-send-email-dianders@chromium.org>
 <1366129742-16048-1-git-send-email-dianders@chromium.org>
 <1366129742-16048-3-git-send-email-dianders@chromium.org>
Message-ID: <20130416163600.GC4918@quad.lixom.net>

On Tue, Apr 16, 2013 at 09:29:02AM -0700, Doug Anderson wrote:
> Now that we have i2c-arbitrator in place on bus 4 we can add the
> sbs-battery driver.  Future devices will be added onto bus 4 once
> drivers are in good shape.
> 
> Signed-off-by: Doug Anderson <dianders at chromium.org>

Acked-by: Olof Johansson <olof at lixom.net>


-Olof


From marc.zyngier at arm.com  Tue Apr 16 12:40:52 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Tue, 16 Apr 2013 18:40:52 +0200
Subject: [PATCH] ARM: KVM: iterate over all CPUs for CPU compatibility
 check
In-Reply-To: <CAEDV+gKbmbdg-xX2Zf5febaeJv5TzLdLZZ5ZrEX9xGc0zsdZQw@mail.gmail.com>
References: <1365771875-5788-1-git-send-email-andre.przywara@linaro.org>
 <51680AF9.7040109@arm.com>
 <CAEDV+g+E8PLc60vMRhq4O_AL2WjmYDLb6=Wh34ynhevh7uAGJA@mail.gmail.com>
 <1366071996.10931.15.camel@smoke>
 <CAEDV+gKbmbdg-xX2Zf5febaeJv5TzLdLZZ5ZrEX9xGc0zsdZQw@mail.gmail.com>
Message-ID: <6327a7cba36fe46cb3787617a8f10420@localhost>

On Tue, 16 Apr 2013 09:24:03 -0700, Christoffer Dall
<cdall at cs.columbia.edu> wrote:
> On Mon, Apr 15, 2013 at 5:26 PM, Geoff Levand <geoff at infradead.org>
wrote:
>> On Sun, 2013-04-14 at 21:57 -0700, Christoffer Dall wrote:
>>> On Fri, Apr 12, 2013 at 6:24 AM, Marc Zyngier <marc.zyngier at arm.com>
>>> wrote:
>>> Nak. The fact that one of the CPUs seem to hang is a sure sign that
>>> > something is severely broken, and you definitely want to fix that
>>> > issue,
>>> > instead of blindly ignoring it.
>>> >
>>> > Additionally, it seems you're just papering over the issue. You
should
>>> > be able to exclude the A7 processors, but not completely deny KVM
from
>>> > running on the hardware.
>>> >
>>> Marc, I disagree with this nak. If the current kernel breaks boot on a
>>> Big.Little system, we need to take care of that first, and the
>>> proposed patch is a quick way to do so, and it does not stand in the
>>> way of introducing proper Big.Little support in any way, which I'm
>>> sure is going to open up a lot of other interesting questions.
>>>
>>> I'm going to take this one.
>>
>> Since this problem will cause the 3.9 kernel to hang then a workaround
>> like this should go in.  There isn't enough time to do a proper fix for
>> 3.9, and even if it could be done I think it would be too intrusive to
>> get merged this late.
>>
> That's why I was inclined to take the patch, but as Marc pointed out
> the error message is incorrect, so that should be fixed at the very
> least. Also I don't think we need the counting logic, just bail out if
> we have any CPUs that are not supported.
> 
> Marc, since you're the strongest opponent of this patch, are you still
> opposed to making sure we don't try to run KVM on Big.Little until
> support is properly introduced?

Nothing I've seen so far proves that BL isn't working. Yes, we know the
guest side is going to break. But the host should be solid, and if it
isn't, let's fix it. What we've seen so far is an A15 hanging (Andre's
trace), and Alexander's weird problem with the third A7 hanging. So far,
I'd be inclined to say that BL is working well enough for that bug to be
reproduced on both sides.

> I also cannot see how we can fix the affinity issue easily from within
> the kernel, do you have a concrete approach in mind you can share?

My idea was to check the affinity of the vcpu thread, compare it to the
"KVM affinity", and force it to the intersection of these two sets
(rescheduling if not on an A15). If the intersection is null, just give up.

Not pretty, but ensures nothing gets scheduled on an A7.

        M.
-- 
Fast, cheap, reliable. Pick two.


From rabryn at c2development.com  Tue Apr 16 12:47:57 2013
From: rabryn at c2development.com (Ryan Bryngelson)
Date: Tue, 16 Apr 2013 11:47:57 -0500
Subject: iMX28 DTS GPIO IRQ Definition
Message-ID: <CAGUvELcRFK9vjx3t69ccEfjLanPSnpZmSo83fxQN0yWvbjTX7w@mail.gmail.com>

I'm having trouble defining a node in imx28-evk.dts that will
configure a GPIO pin to be an IRQ (high-to-low edge triggered
interrupt).  I'm using mainline kernel version 3.8.3.  I've read the
documentation located in 'Documentation/devicetree/bindings/gpio, I
see the following in gpio-mxs.txt' where it says the following...



As the GPIO controller is embedded in the PIN controller and all the
GPIO ports share the same IO space with PIN controller, the GPIO node
will be represented as sub-nodes of MXS pinctrl node.

Required properties for GPIO node:
- compatible : Should be "fsl,<soc>-gpio".  The supported SoCs include
  imx23 and imx28.
- interrupts : Should be the port interrupt shared by all 32 pins.
- gpio-controller : Marks the device node as a gpio controller.
- #gpio-cells : Should be two.  The first cell is the pin number and
  the second cell is used to specify the gpio polarity:
      0 = active high
      1 = active low
- interrupt-controller: Marks the device node as an interrupt controller.
- #interrupt-cells : Should be 2.  The first cell is the GPIO number.
  The second cell bits[3:0] is used to specify trigger type and level flags:
      1 = low-to-high edge triggered.
      2 = high-to-low edge triggered.
      4 = active high level-sensitive.
      8 = active low level-sensitive.

Note: Each GPIO port should have an alias correctly numbered in "aliases"
node.



How would I define this?  I assume the "pin number" in the gpio-cells
definition is the bit in the port.  So if I wanted to configure port
0, bit 4 to be an interrupt, it would be '4'.  In the interrupt-cells
definition what is "GPIO number"?  I see in the imx28.dtsi the
definitions of the aliases and GPIO ports, for example...



                gpio0: gpio at 0 {
                    compatible = "fsl,imx28-gpio", "fsl,mxs-gpio";
                    interrupts = <127>;
                    gpio-controller;
                    #gpio-cells = <2>;
                    interrupt-controller;
                    #interrupt-cells = <2>;
                };



I don't see how I should define a node in the imx28-evk.dts that
defines a GPIO that is an IRQ.  The "interrupts" in the dtsi file, 127
in the example above, refer to the IRQ source in the ICOLL.  Where are
the definitions of the interrupt-cells and gpio-cells at that are
described in the gpio-mxs.txt documentation?

I'm new to the device tree and any help would be appreciated.  I've
already tried to take this up with Freescale support and they sent me
here.

Thanks,
Ryan


From olof at lixom.net  Tue Apr 16 12:48:38 2013
From: olof at lixom.net (Olof Johansson)
Date: Tue, 16 Apr 2013 09:48:38 -0700
Subject: [GIT PULL 2/3] ARM: davinci: SoC updates for v3.10 (part 2)
In-Reply-To: <516CEBCF.60507@ti.com>
References: <1366046599-6590-1-git-send-email-nsekhar@ti.com>
 <1366046599-6590-2-git-send-email-nsekhar@ti.com>
 <20130415201835.GA24600@quad.lixom.net> <516CEBCF.60507@ti.com>
Message-ID: <20130416164838.GE4918@quad.lixom.net>

On Tue, Apr 16, 2013 at 11:42:31AM +0530, Sekhar Nori wrote:
> On 4/16/2013 1:48 AM, Olof Johansson wrote:
> > On Mon, Apr 15, 2013 at 10:53:18PM +0530, Sekhar Nori wrote:
> >> Hi Arnd, Olof,
> >>
> >> Can you please the following SoC updates for DaVinci.
> >> The branch depends on (and merges) an immutable branch
> >> from Ohad adding DA8XX rempote proc driver.
> > 
> > Hi,
> > 
> > Where is this branch from? Git URL and branch name, please -- we prefer to pull
> > these in as separate branches under depends/* as well to document it.
> 
> Here is the repo and branch:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/ohad/remoteproc.git for-next

Oh! Looking at that branch, and the new branch from you, I don't actually see
a dependency between them. Sure, the Davinci mach-side code registers a new
device, but until the driver has the corresponding changes, there's no breakage
caused by the new registration. There are no new data structures introduced
either, so there's no build-time dependency added.

So it would be just as easy to just merge this as a nondependent branch. When
both sides of the change land, remoteproc will work. But until then, nothing
existing will be broken.

Sound ok? If so, please just rebase your 4 patches on top of the old SoC branch
without the dependency and send a fresh pull request, please. :)

-Olof


From p.pisati at gmail.com  Tue Apr 16 12:55:16 2013
From: p.pisati at gmail.com (Paolo Pisati)
Date: Tue, 16 Apr 2013 18:55:16 +0200
Subject: 3.8+, PL310_ERRATA_769419 and highbank: borked reboot
Message-ID: <20130416165516.GA3097@luxor.wired.org>

Scenario:

3.9-rc7 kernel, multiplatform support with highbank and imx6 selected, highbank
node -> reboot doesn't work (actually it works 1 out of 10 times)

And playing around with the config i was able to track it down to
PL310_ERRATA_769419.

-a config and kernel that reproduce the issue:

http://people.canonical.com/~ppisati/highbank_769419_reboot/config.brk

http://people.canonical.com/~ppisati/highbank_769419_reboot/zImage.brk

-a config and kernel that don't reproduce it: 

http://people.canonical.com/~ppisati/highbank_769419_reboot/0003-highbank-dbg-comment-out-PL310_ERRATA_769419.patch

http://people.canonical.com/~ppisati/highbank_769419_reboot/config.ok

http://people.canonical.com/~ppisati/highbank_769419_reboot/zImage.ok

If you are building pl330 support too, you need a patch like this one:

http://people.canonical.com/~ppisati/highbank_769419_reboot/0001-dma-of-dma-check-OF-pointer-property-before-derefere.patch

to avoid a NULL ptr oops during boot.

Same issue happens on 3.8, and due to my test environment (conserver
on top of ipmi for 'serial over lan') i was unable to sysrq and give you a
stacktrace, sorry.
-- 
bye,
p.


From soren.brinkmann at xilinx.com  Tue Apr 16 13:06:50 2013
From: soren.brinkmann at xilinx.com (Soren Brinkmann)
Date: Tue, 16 Apr 2013 10:06:50 -0700
Subject: [PATCH] clk: Always notify whole subtree when reparenting
Message-ID: <afe397e3-c674-4dc3-9f3e-feea9275bb91@TX2EHSMHS023.ehs.local>

A clock's notifier count only reflects notifiers which are registered
directly for that clock. A reparent operation though affects the whole
subtree because of a potential rate change.
When issuing the pre rate change notifications only the notifier count
for the clock to be changed is considered and notifiers for subclocks
may never be called. Resulting in clocks in the subtree which have
registered notifiers, may receive a POST_- or ABORT_RATE_CHANGE
notification, without a PRE_RATE_CHANGE_NOTIFICATION.
Therefore always traverse the whole subtree when issueing pre rate
change notifications during a reparent operation.

Signed-off-by: Soren Brinkmann <soren.brinkmann at xilinx.com>
---
This should probably be considered an RFC. There may be smarter ways to
resolve this issue. E.g. forward notifier counts upstream the way it is done
with enable counts.

	S?ren


 drivers/clk/clk.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 20ce67f..1179cb5 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -1481,8 +1481,7 @@ int clk_set_parent(struct clk *clk, struct clk *parent)
 	}
 
 	/* propagate PRE_RATE_CHANGE notifications */
-	if (clk->notifier_count)
-		ret = __clk_speculate_rates(clk, p_rate);
+	ret = __clk_speculate_rates(clk, p_rate);
 
 	/* abort if a driver objects */
 	if (ret & NOTIFY_STOP_MASK)
-- 
1.8.2.1




From swarren at wwwdotorg.org  Tue Apr 16 13:09:09 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Tue, 16 Apr 2013 11:09:09 -0600
Subject: [PATCH] ARM: tegra: solve adr range issue with THUMB2_KERNEL enabled
Message-ID: <1366132149-17294-1-git-send-email-swarren@wwwdotorg.org>

From: Stephen Warren <swarren at nvidia.com>

When building the kernel with CONFIG_THUMB2_KERNEL enabled, older
assemblers may emit the following error:

reset-handler.S:78: Error: invalid immediate for address calculation (value = 0x00000004)

Using an explicit adr.w instruction will solve this. Newer assemblers do
this automatically. Use the W() macro to do this under Thumb mode only.

Inspired-by: Joseph Lo <josephl at nvidia.com>
Suggested-by: Dave Martin <dave.martin at linaro.org>
Signed-off-by: Stephen Warren <swarren at nvidia.com>
---
Olof, Arnd,

Can you please apply this directly to arm-soc. Thanks.

This patch replaces patch 3/3 "ARM: tegra: make sure the pointer on 4
byte align when THUMB2_KERNEL enabled" which I forwarded yesterday. It
can be applied to wherever Tegra's for-3.10/fixes branch was applied,
and doesn't cause any conflicts/merge-issues with any other Tegra patches
this cycle.

 arch/arm/mach-tegra/sleep.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-tegra/sleep.h b/arch/arm/mach-tegra/sleep.h
index 4ffae54..bb308ea 100644
--- a/arch/arm/mach-tegra/sleep.h
+++ b/arch/arm/mach-tegra/sleep.h
@@ -92,7 +92,7 @@
 
 #ifdef CONFIG_CACHE_L2X0
 .macro l2_cache_resume, tmp1, tmp2, tmp3, phys_l2x0_saved_regs
-	adr	\tmp1, \phys_l2x0_saved_regs
+	W(adr)	\tmp1, \phys_l2x0_saved_regs
 	ldr	\tmp1, [\tmp1]
 	ldr	\tmp2, [\tmp1, #L2X0_R_PHY_BASE]
 	ldr	\tmp3, [\tmp2, #L2X0_CTRL]
-- 
1.7.10.4



From will.deacon at arm.com  Tue Apr 16 13:22:59 2013
From: will.deacon at arm.com (Will Deacon)
Date: Tue, 16 Apr 2013 18:22:59 +0100
Subject: [PATCH] Report double word access atomicity on LPAE enabled
 targets through AUXV
In-Reply-To: <CD54D5A4-2E19-49D9-B6E7-051F36AB5DF8@oracle.com>
References: <C3FF039D-7DE3-4A99-8317-789094095D8B@oracle.com>
 <20130408142406.GL17995@n2100.arm.linux.org.uk>
 <20130408155749.GS17476@mudshark.cambridge.arm.com>
 <CD54D5A4-2E19-49D9-B6E7-051F36AB5DF8@oracle.com>
Message-ID: <20130416172258.GE3770@mudshark.cambridge.arm.com>

On Fri, Apr 12, 2013 at 09:58:43PM +0100, Vladimir Danushevsky wrote:
> On Apr 8, 2013, at 11:57 AM, Will Deacon wrote:
> > Actually, it's not just the presence of those instructions -- it's their
> > behaviour wrt atomicity. They are only guaranteed to be atomic if the CPU in
> > question supports LPAE. We could call it "lpae" but it might be set even
> > when the kernel is using the short-descriptor format.
> 
> I also think that ATOMICD would describe the intended behavior better.

I started having second thoughts about the name, on the offchance that some
other feature introduced with LPAE is found to be useful to userspace. Then
userspace would end up checking ATOMICD in order to determine something
different, which is counter-intuitive.

Maybe there is no other `killer feature' for userspace with LPAE, but at
least we'd be reporting what the hardware says, rather than the small bit
which we're interested in.

Patch below...

Will

--->8

commit c6eaaa758c7956b18aa0cfabe9500ef73514b319
Author: Will Deacon <will.deacon at arm.com>
Date:   Mon Apr 8 17:13:12 2013 +0100

    ARM: elf: add new hwcap for identifying atomic ldrd/strd instructions
    
    CPUs implementing LPAE have atomic ldrd/strd instructions, meaning that
    userspace software can avoid having to use the exclusive variants of
    these instructions if they wish.
    
    This patch advertises the atomicity of these instructions via the
    hwcaps, so userspace can detect this CPU feature.
    
    Signed-off-by: Will Deacon <will.deacon at arm.com>

diff --git a/arch/arm/include/uapi/asm/hwcap.h b/arch/arm/include/uapi/asm/hwcap.h
index 3688fd1..6d34d08 100644
--- a/arch/arm/include/uapi/asm/hwcap.h
+++ b/arch/arm/include/uapi/asm/hwcap.h
@@ -25,6 +25,6 @@
 #define HWCAP_IDIVT    (1 << 18)
 #define HWCAP_VFPD32   (1 << 19)       /* set if VFP has 32 regs (not 16) */
 #define HWCAP_IDIV     (HWCAP_IDIVA | HWCAP_IDIVT)
-
+#define HWCAP_LPAE     (1 << 20)
 
 #endif /* _UAPI__ASMARM_HWCAP_H */
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index eaa7900..57a53c5 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -356,7 +356,7 @@ void __init early_print(const char *str, ...)
 
 static void __init cpuid_init_hwcaps(void)
 {
-       unsigned int divide_instrs;
+       unsigned int divide_instrs, vmsa;
 
        if (cpu_architecture() < CPU_ARCH_ARMv7)
                return;
@@ -369,6 +369,11 @@ static void __init cpuid_init_hwcaps(void)
        case 1:
                elf_hwcap |= HWCAP_IDIVT;
        }
+
+       /* LPAE implies atomic ldrd/strd instructions */
+       vmsa = (read_cpuid_ext(CPUID_EXT_MMFR0) & 0xf) >> 0;
+       if (vmsa >= 5)
+               elf_hwcap |= HWCAP_LPAE;
 }
 
 static void __init feat_v6_fixup(void)
@@ -875,6 +880,7 @@ static const char *hwcap_str[] = {
        "vfpv4",
        "idiva",
        "idivt",
+       "atomicd",
        NULL
 };
 



From ohad at wizery.com  Tue Apr 16 13:51:13 2013
From: ohad at wizery.com (Ohad Ben-Cohen)
Date: Tue, 16 Apr 2013 20:51:13 +0300
Subject: adding rpmsg.git to linux next
In-Reply-To: <20130416100715.cd726b96944237ef975ebe7d@canb.auug.org.au>
References: <CAK=WgbY=4rosYr2g3fYYk6WrqXjN7f=5Dk5+D-h3cWrOtVmNag@mail.gmail.com>
 <20130416100715.cd726b96944237ef975ebe7d@canb.auug.org.au>
Message-ID: <CAK=WgbbVP+3eugev8szRBCV84uZLdKP6QXAH_Fr89SXDs-V5GQ@mail.gmail.com>

Hi Stephen,

On Tue, Apr 16, 2013 at 3:07 AM, Stephen Rothwell <sfr at canb.auug.org.au> wrote:
> On Mon, 15 Apr 2013 09:28:17 +0300 Ohad Ben-Cohen <ohad at wizery.com> wrote:
>> Could you please add:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/ohad/rpmsg.git#for-next
>>
>> to linux-next to include new stuff coming from Rob?
>
> Well, you could tell me something about it.  Like what is in it and how
> it will be merged up to Linus.  Does this have anything to do with the
> remoteproc tree I already include?  Who is the official maintainer (there
> is no mention of drivers/rpmsg in the MAINTAINERS file).

Sorry for not mentioning this.

This tree isn't new and is being used to send pull requests to Linus
for some time. I guess that most (all?) of the pull requests contained
fixes which needed no linux-next presence, so it never occurred to me
the tree isn't part of linux-next.

Some background:

Rpmsg is a virtio-based messaging bus that allows kernel drivers to communicate
with entities running on remote processors available on the system. In
turn, drivers could then
expose appropriate user space interfaces, if needed.

Rpmsg is essentially a multiplexer providing communication channels
which rpmsg drivers utilizes; it does not handle the physical state of
the remote processor, and in fact is completely decoupled from
remoteproc, which does focus on the physical state of the remote
processor (but has no communications aspect). For much more
information, please see Documentation/rpmsg.txt.

I maintain rpmsg (by sending pull requests to Linus), and for some
reason never added a MAINTAINERS entry for it. I can fix that quite
easily, let me know if this helps:

commit d8115db52b99eefb99bcbf992edc349e691b4ca7
Author: Ohad Ben-Cohen <ohad at wizery.com>
Date:   Tue Apr 16 20:34:49 2013 +0300

    MAINTAINERS: add rpmsg entry

    People and scripts look for this.

    Signed-off-by: Ohad Ben-Cohen <ohad at wizery.com>

diff --git a/MAINTAINERS b/MAINTAINERS
index 9561658..eaca6c8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6604,6 +6604,14 @@ F:       drivers/remoteproc/
 F:     Documentation/remoteproc.txt
 F:     include/linux/remoteproc.h

+REMOTE PROCESSOR MESSAGING (RPMSG) SUBSYSTEM
+M:     Ohad Ben-Cohen <ohad at wizery.com>
+T:     git git://git.kernel.org/pub/scm/linux/kernel/git/ohad/rpmsg.git
+S:     Maintained
+F:     drivers/rpmsg/
+F:     Documentation/rpmsg.txt
+F:     include/linux/rpmsg.h
+
 RFKILL
 M:     Johannes Berg <johannes at sipsolutions.net>
 L:     linux-wireless at vger.kernel.org

Hope this all helps, please let me know if anything else is needed.

Thanks,
Ohad.


From ohaugan at codeaurora.org  Tue Apr 16 14:18:42 2013
From: ohaugan at codeaurora.org (Olav Haugan)
Date: Tue, 16 Apr 2013 11:18:42 -0700
Subject: [PATCH] documentation: iommu: add description of ARM System MMU
 binding
In-Reply-To: <20130415131341.GG9827@mudshark.cambridge.arm.com>
References: <1365094259-24847-1-git-send-email-will.deacon@arm.com>
 <515F37C1.4000109@codeaurora.org>
 <20130408092535.GA17476@mudshark.cambridge.arm.com>
 <5162F87A.7070409@codeaurora.org>
 <20130410173732.GQ26992@mudshark.cambridge.arm.com>
 <5169C7D1.8070300@codeaurora.org>
 <20130415131341.GG9827@mudshark.cambridge.arm.com>
Message-ID: <516D9602.2010404@codeaurora.org>

On 4/15/2013 6:13 AM, Will Deacon wrote:
> On Sat, Apr 13, 2013 at 10:02:09PM +0100, Olav Haugan wrote:
>> On 4/10/2013 10:37 AM, Will Deacon wrote:
>>> Ok, but then how does that interact with the IOMMU API in Linux? e.g.
>>> if a client asks for an iova <-> pa mapping on a device, then you
>>> need to lookup the StreamIDs for that device, no?
>>
>> Can you explain this use case a bit more. I am not clear what you mean
>> by a "client"? Are you referring to a client in Linux or are you
>> referring to the client being the core behind an IOMMU (such as a DMA
>> engine or a video core)?
> 
> Sure. By `client', I mean any use of the IOMMU API. It could be something
> like your LVD example later on, it could be KVM or it could be indirectly
> via dma-mapping. Basically, any user of <linux/iommu.h>.

Ok, so if I do a VA2PA on a domain (calling iommu_iova_to_phys()) you
don't need any information about StreamID (no need to look up the
StreamID). You would just walk the page table of the domain and find the
address (or use ATS on the IOMMU if supported by the HW).

>> I am not sure how StreamIDs relates to the IOMMU API in Linux :-)
> 
> That's the thing; they don't, at least not explicitly. The StreamIDs must
> all be handled inside the driver and it's actually what the driver would
> deal with, rather than devices.
> 
> For example, if I create an IOMMU domain containing a DMA controller, that
> means that I have associated a set of StreamIDs (i.e. those configured to
> identify the DMA controller's master ports) with that domain. That may have
> further consequences on which other devices can be put in the same domain
> (stream-matching may require some IDs to sit in the same address space/domain)
> and also effectively parameterises the domain, by pointing those StreamIDs
> at the same context bank.

Yes, this is clear to me.

>> I think it helps if I explain my use case to you so you understand how
>> we use the IOMMU and maybe you can explain your use case and how your
>> driver works so that we can get on the same page. BTW, our ARMv1 IOMMU
>> driver can be found @ [1]
>>
>> Our use case:
>>
>> 1) During boot IOMMU HW is probed, devices for each IOMMU and for each
>> context bank are created.
> 
> So you create a device for each context bank...
> 
>> 2) Video session starts.
>> 3) Linux Video Driver (LVD) creates one or more domain
>> (iommu_domain_alloc) and calls iommu_attach_device() for each context
>> bank it is going to use.
> 
> ...and attach the context bank to the domain dynamically?

Yes

> If so, doesn't that strongly tie your video driver to the SMMU?

Isn't this more or less what you are doing in DT where you associate
specific devices with an IOMMU (mmu-masters)?

>> The video driver selects context bank to attach to based on the use case
>> and does not know about StreamIDs really.
>>
>> BTW, when you call iommu_attach_device() what "device" do you pass as
>> argument? Do you pass the IOMMU as a device? How do you specify which
>> Context Bank to attach to?
> 
> This seems to be where we differ. My anticipated use-case is that a domain
> is allocated, which defines an empty address space. Masters are then
> attached to the domain by passing their struct device, so this may
> correspond to a DMA controller or a video core, in your case. The context
> bank is allocated dynamically when the first device is added to the
> domain, and then it is subsequently shared between all the masters in that
> domain.

I feel that there are some limitation with this. Maybe you can address
the following:

1) What if you want two context banks in one domain (shared page table)?
2) What if a master (device) needs to use 2 or more context banks?

>>> Why can't the secure world just hide those context banks by using 
>>> SMMU_SCR1.NSNUMCBO?
>>
>> Yes, that is a possibility for context banks. If you have 1 or more
>> "secure" context banks it also means that Linux does not have access
>> (read: can't have) to the global register space and this must be
>> communicated somehow (hence the "secure-id" IOMMU node property. The
>> secure-context property might be redundant. However, there might be use
>> cases were Linux would want to know about the secure context bank. One
>> such use case could be to register for page fault from the secure
>> context bank so that Linux can log a useful page fault message to the
>> kernel log.
> 
> Perhaps, but I don't think it's worth complicating the binding based on a
> potential nice-to-have fault message.
> 

However, global register space (including Stream Match Registers [SMR])
needs to be programmed by the secure environment for security or by
hyper-visor if you are in such an environment.

Thanks,

Olav Haugan

-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation


From a.spyridakis at virtualopensystems.com  Tue Apr 16 14:37:37 2013
From: a.spyridakis at virtualopensystems.com (Alexander Spyridakis)
Date: Tue, 16 Apr 2013 20:37:37 +0200
Subject: [PATCH] ARM: KVM: iterate over all CPUs for CPU compatibility
 check
In-Reply-To: <CAEDV+g+8iE2_8Z6q7NYRPwKNDDBd8MnEEmB8KjrWwvUdSaxXmg@mail.gmail.com>
References: <1365771875-5788-1-git-send-email-andre.przywara@linaro.org>
 <51680AF9.7040109@arm.com>
 <CAEDV+g+E8PLc60vMRhq4O_AL2WjmYDLb6=Wh34ynhevh7uAGJA@mail.gmail.com>
 <d455f2823b9639af8d38d30f2c3234bd@localhost>
 <CAEDV+gJuFG49oQ=BEaCHcTP=nHVyX8ALw6076dR_C1s7TuyqXQ@mail.gmail.com>
 <d47697abd39a0d5d41f5ac110a40e261@localhost>
 <CAEDV+gK9==sXYxRVZ8JVFYPiw3_xgzZBbydEwPunmnocNLKXrQ@mail.gmail.com>
 <CAFEAcA-bPoa8YoPuHPmupzfUW+yR233XquK79eNorzcRpFiK=g@mail.gmail.com>
 <516BCAD0.9000708@linaro.org>
 <CAJRNFKJoBzgt4UhxsH65_LyhcGXPnzB_pg3q-zeYT2OVv59q4A@mail.gmail.com>
 <CAEDV+g+8iE2_8Z6q7NYRPwKNDDBd8MnEEmB8KjrWwvUdSaxXmg@mail.gmail.com>
Message-ID: <CAJRNFKJ4ayqup6kSTg_1jeU0cBen1sYoBXLsEzZujndiZ-kE6w@mail.gmail.com>

On 16 April 2013 17:59, Christoffer Dall <cdall at cs.columbia.edu> wrote:
> On Mon, Apr 15, 2013 at 2:52 AM, Alexander Spyridakis
> <a.spyridakis at virtualopensystems.com> wrote:
>> I've run on this problem before, while trying to run KVM guests on A7 cores.
>>
>> For some reason the 3rd A7 hangs in arch/arm/kvm/init.S, on the instruction
>> that updates HSCTLR between the two isbs on __do_hyp_init (mcr p15, 4, r0,
>> c1, c0, 0). If you boot the system with maxcpus=4 then init_hyp_mode() will
>> not hang on the A7 cluster. Other than that from my limited testing KVM on
>> A7 works on a usual linux guest. I also tried to only boot the 3rd A7 core
>> to rule out any racing issues, but still the same behaviour applies.
>>
> You lost me on the maxcpus=4 and racing point here. If it works with
> maxcpus=4 then it works with two A7s, right? Why would running with
> maxcpus=3 (ie. one A7) rule out any race condition?

maxcpus=3 would still work (only one A7), but I didn't test it that
way. To make sure and avoid any race conditions from other cpus, I
changed the bootwrapper to explicitly boot only the 3rd A7 (rest of
the cpus being in an infinite loop) and it would still hang. Booting
only the 1st or 2nd A7 core by the same method would work as expected
(no hang in __do_hyp_init_).

Regards.


From swarren at wwwdotorg.org  Tue Apr 16 14:40:05 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Tue, 16 Apr 2013 12:40:05 -0600
Subject: [PATCH 3/5] gpio/omap: Add DT support to GPIO driver
In-Reply-To: <516C8760.2050500@ti.com>
References: <1329321854-24490-1-git-send-email-b-cousson@ti.com>
 <CACRpkdYHj-rEF3Rk_CWnmmMw_Amr7m8SgQ=-2zsDYuLeuu3azw@mail.gmail.com>
 <514C79E1.4090106@wwwdotorg.org> <514CE0AB.6060207@ti.com>
 <CACRpkdZmv-rAoKSQYpkHHSMzKJOn5TixVW_P3=m7ZNagBYCUPw@mail.gmail.com>
 <515319D5.20105@wwwdotorg.org>
 <CACRpkdYXVLgCz1Tyu-Ls2V2OTc4R3cGNJhfQJB6Hiz_K9dkZYQ@mail.gmail.com>
 <5155C902.7080207@wwwdotorg.org>
 <CACRpkdYbs4-uudpRUY8e+7icYYkZrfM0kReP3pLL5DMiURJ4dg@mail.gmail.com>
 <5165CB9D.1090202@wwwdotorg.org>
 <CACRpkdYirFNqmGhA4K9CL4ve4NYhs8Rd3SFt1iwW9vHBkrcz8g@mail.gmail.com>
 <51671D7B.5060303@wwwdotorg.org>
 <CACRpkdbf32Ef77GmXk9id9+RRjcDRTr7S+F4nznoeZU8y=BT_Q@mail.gmail.com>
 <51673D70.3010503@wwwdotorg.org>
 <CAAwP0s0e2x33jZQhFRY+Hoo61SFqYKRgWk=1mL2+DNxSDJHz+A@mail.gmail.com>
 <CACRpkda4h+qXTvsirPAS7E7sjXhMLE62q=VDy53W8UchsYjbNg@mail.gmail.com>
 <516C31C3.9040505@wwwdotorg.org> <516C73C6.5050409@ti.co m>
 <516C7C43.3040105@wwwdotorg.org> <516C8760.2050500@ti.com>
Message-ID: <516D9B05.1000501@wwwdotorg.org>

On 04/15/2013 05:04 PM, Jon Hunter wrote:
> 
> On 04/15/2013 05:16 PM, Stephen Warren wrote:
>> On 04/15/2013 03:40 PM, Jon Hunter wrote:
...
>>> mmc {
>>> 	label = "pandaboard::status2";
>>>  	gpios = <&gpio1 8 0>;
>>> 	...
>>> };
>>
>> But that's a gpio-leds instance, not an MMC controller... I really
>> really hope there's no DT node using "gpios" to mean "interrupts"... And
>> it wouldn't make any sense for an on-SoC device anyway.
> 
> Oops yes, I overlooked that. However, the omap mmc driver
> (drivers/mmc/host/omap_hsmmc.c) does call gpio_request() and
> request_threaded_irq() for the mmc card-detect interrupt. I believe
> tegra is doing the same ...
> 
> sdhci at 78000000 {
> 	...
> 	cd-gpios = <&gpio 69 0>; /* gpio PI5 */
> 	...	
> };

Ah true. I guess at least all MMC drivers are likely hooking cd-gpios as
an interrupt, /and/ requesting it as a GPIO so that they can read the
current state when the GPIO goes off.

That tends to imply that no core code can possibly call gpio_request()
in response to request_irq(), since doing so likely will conflict with
quite a few drivers...

>>> Both these devices are using a gpio as an interrupt source, but the mmc
>>> driver is requesting the gpio directly. In the first case the xlate
>>> function for the gpio irq domain will be called where as it is not used
>>> in the 2nd case. Therefore, we could add a custom xlate function. For
>>> example ...
>>>
>>> diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
>>
>>> +int omap_irq_domain_xlate(struct irq_domain *d, struct device_node *ctrlr,
>> ...
>>> +       gpio_request_one(irq_to_gpio(bank, intspec[0]), GPIOF_IN, ctrlr->name);
>>
>> I guess that could work, but:
>>
>> a) It still means doing the gpio_request() in each driver instead of
>> centrally.
> 
> Right this is device specific, but it avoids exposing irq_to_gpio for a
> device. However, we could make this generic if we did expose irq_to_gpio
> for each device.
> 
>> b) This approach doesn't solve the issue where some client driver has
>> already requested the GPIO. This code would simply prevent that call
>> from succeeding, which would probably make the driver probe() error out,
>> which isn't any different to the equivalent proposed centralized
>> gpio_request() inside some request_irq() failing, and causing the
>> device's probe() to error out.
> 
> If some driver is calling gpio_request() directly, then they will most
> likely just call gpio_to_irq() when requesting the interrupt and so the
> xlate function would not be called in this case (mmc drivers are a good
> example). So I don't see that as being a problem. In fact that's the
> benefit of this approach as AFAICT it solves this problem.

Oh. That assumption seems very fragile. What about drivers that actually
do have platform data (or DT bindings) that provide both the IRQ and
GPIO IDs, and hence don't use gpio_to_irq()? That's entirely possible.

Given all this, I guess simply having each GPIO+IRQ driver's set_type
function simply do whatever is required in HW to set up that GPIO
actually does seem like the best idea. Admittedly that isn't
centralized, but I'm not sure now that any centralized implementation is
possible, without significant rework of a bunch of drivers. This is what
the Tegra GPIO driver already does, and I think one of the earlier
patches in this thread did exactly that for OMAP IRQs too right?

BTW, just so you know, I'm on vacation for 2 weeks starting Wed
afternoon, so replies will be non-existent or spotty during that time.


From a.spyridakis at virtualopensystems.com  Tue Apr 16 14:43:01 2013
From: a.spyridakis at virtualopensystems.com (Alexander Spyridakis)
Date: Tue, 16 Apr 2013 20:43:01 +0200
Subject: [PATCH] ARM: KVM: iterate over all CPUs for CPU compatibility
 check
In-Reply-To: <CAJRNFKJ4ayqup6kSTg_1jeU0cBen1sYoBXLsEzZujndiZ-kE6w@mail.gmail.com>
References: <1365771875-5788-1-git-send-email-andre.przywara@linaro.org>
 <51680AF9.7040109@arm.com>
 <CAEDV+g+E8PLc60vMRhq4O_AL2WjmYDLb6=Wh34ynhevh7uAGJA@mail.gmail.com>
 <d455f2823b9639af8d38d30f2c3234bd@localhost>
 <CAEDV+gJuFG49oQ=BEaCHcTP=nHVyX8ALw6076dR_C1s7TuyqXQ@mail.gmail.com>
 <d47697abd39a0d5d41f5ac110a40e261@localhost>
 <CAEDV+gK9==sXYxRVZ8JVFYPiw3_xgzZBbydEwPunmnocNLKXrQ@mail.gmail.com>
 <CAFEAcA-bPoa8YoPuHPmupzfUW+yR233XquK79eNorzcRpFiK=g@mail.gmail.com>
 <516BCAD0.9000708@linaro.org>
 <CAJRNFKJoBzgt4UhxsH65_LyhcGXPnzB_pg3q-zeYT2OVv59q4A@mail.gmail.com>
 <CAEDV+g+8iE2_8Z6q7NYRPwKNDDBd8MnEEmB8KjrWwvUdSaxXmg@mail.gmail.com>
 <CAJRNFKJ4ayqup6kSTg_1jeU0cBen1sYoBXLsEzZujndiZ-kE6w@mail.gmail.com>
Message-ID: <CAJRNFKJ7r9PPA5+t9hTSk_tBY2424QdVKgPFq5kwrzQSLpqCcw@mail.gmail.com>

[sorry, resending this as my client still insists on misspelling Marc's mail]

On 16 April 2013 20:37, Alexander Spyridakis
<a.spyridakis at virtualopensystems.com> wrote:
> On 16 April 2013 17:59, Christoffer Dall <cdall at cs.columbia.edu> wrote:
>> On Mon, Apr 15, 2013 at 2:52 AM, Alexander Spyridakis
>> <a.spyridakis at virtualopensystems.com> wrote:
>>> I've run on this problem before, while trying to run KVM guests on A7 cores.
>>>
>>> For some reason the 3rd A7 hangs in arch/arm/kvm/init.S, on the instruction
>>> that updates HSCTLR between the two isbs on __do_hyp_init (mcr p15, 4, r0,
>>> c1, c0, 0). If you boot the system with maxcpus=4 then init_hyp_mode() will
>>> not hang on the A7 cluster. Other than that from my limited testing KVM on
>>> A7 works on a usual linux guest. I also tried to only boot the 3rd A7 core
>>> to rule out any racing issues, but still the same behaviour applies.
>>>
>> You lost me on the maxcpus=4 and racing point here. If it works with
>> maxcpus=4 then it works with two A7s, right? Why would running with
>> maxcpus=3 (ie. one A7) rule out any race condition?
>
> maxcpus=3 would still work (only one A7), but I didn't test it that
> way. To make sure and avoid any race conditions from other cpus, I
> changed the bootwrapper to explicitly boot only the 3rd A7 (rest of
> the cpus being in an infinite loop) and it would still hang. Booting
> only the 1st or 2nd A7 core by the same method would work as expected
> (no hang in __do_hyp_init_).
>
> Regards.


From olof at lixom.net  Tue Apr 16 15:24:01 2013
From: olof at lixom.net (Olof Johansson)
Date: Tue, 16 Apr 2013 12:24:01 -0700
Subject: [GIT PULL] Timer clean-ups for 3.10, Part 2
In-Reply-To: <516C0257.8040103@gmail.com>
References: <516720B4.3000703@gmail.com> <201304112257.07645.arnd@arndb.de>
 <20130413065056.GB14735@quad.lixom.net>
 <516C0257.8040103@gmail.com>
Message-ID: <20130416192401.GA8730@quad.lixom.net>

On Mon, Apr 15, 2013 at 08:36:23AM -0500, Rob Herring wrote:
> On 04/13/2013 01:50 AM, Olof Johansson wrote:
> > On Thu, Apr 11, 2013 at 10:57:07PM +0200, Arnd Bergmann wrote:
> >> On Thursday 11 April 2013, Rob Herring wrote:
> >>> Olof, Arnd,
> >>>
> >>> Please pull timer clean-ups for arch timer, sp804, and integrator-cp timers.
> >>>
> >>> I've dropped the final patch which moved the sp804 and integrator timers
> >>> code to drivers/clocksource until the desired structure is worked out.
> >>>
> >>> Simon, the fixes for shmobile were trivial. Please comment if you see
> >>> any issues.
> >>
> >> Ok, nice!
> >>
> >> There are various bits for which I'd like to see Russell's ACK before
> >> we send them Linuswards, but it all looks good to me.
> >>
> >> I would put it into arm-soc tomorrow, and hopefully Haojian Zhuang is
> >> able to send an updated version of his hisilicon platform code based
> >> on top of this in time for the merge window. The patches are all
> >> reviewed but just waiting for the sp804 changes now, and since
> >> it's a new platform, I'm not worried about regressions.
> > 
> > I've pulled this in as a late/clksrc branch now, so that we keep it separate
> > from the other work in case Russell ends up having comments on it when he is
> > back online.
> > 
> > Also, I based the branch on samsung/mct and samsung/clk, since they had merge
> > conflicts. Kukjin, Rob, please confirm that I've resolved them properly.
> 
> It is quite messed up because the mct timer changes are not based on
> arm-soc/clksrc/cleanup. Any timer changes adding CLKSRC_OF support need
> to be based on this. I've fixed it up in this branch (untested):
> 
> git://sources.calxeda.com/kernel/linux.git exynos-mct-merge
> 
> I merged with clksrc-cleanup-for-3.10-part2 and fixed it in the merge,
> but really either the mct branch should be rebased or some of the
> changes can be a preparatory commit before merging.

Sigh. I'd like to just drop the Exynos MCT patches, but they're now a bit down
into the next/drivers branch with various dependencies into later branches too.

Given that things are already broken, I'll just fix this up in an incremental
patch on top of the late/clksrc branch for now.

> Also, I really don't like how intermingled the DT and non-DT init is in
> the exynos code. We should remove of_have_populated_dt so we don't have
> stuff like this:

Agreed. Hopefully we can remove the non-DT code when Exynos is going DT-only.

> I went thru arm-soc/for-next and all the other conversions not done by
> me (mxs, sirf, zynq) are based on clksrc/cleanup.

Good.


-Olof



From jon-hunter at ti.com  Tue Apr 16 15:27:06 2013
From: jon-hunter at ti.com (Jon Hunter)
Date: Tue, 16 Apr 2013 14:27:06 -0500
Subject: [PATCH 3/5] gpio/omap: Add DT support to GPIO driver
In-Reply-To: <516D9B05.1000501@wwwdotorg.org>
References: <1329321854-24490-1-git-send-email-b-cousson@ti.com>
 <CACRpkdYHj-rEF3Rk_CWnmmMw_Amr7m8SgQ=-2zsDYuLeuu3azw@mail.gmail.com>
 <514C79E1.4090106@wwwdotorg.org> <514CE0AB.6060207@ti.com>
 <CACRpkdZmv-rAoKSQYpkHHSMzKJOn5TixVW_P3=m7ZNagBYCUPw@mail.gmail.com>
 <515319D5.20105@wwwdotorg.org>
 <CACRpkdYXVLgCz1Tyu-Ls2V2OTc4R3cGNJhfQJB6Hiz_K9dkZYQ@mail.gmail.com>
 <5155C902.7080207@wwwdotorg.org>
 <CACRpkdYbs4-uudpRUY8e+7icYYkZrfM0kReP3pLL5DMiURJ4dg@mail.gmail.com>
 <5165CB9D.1090202@wwwdotorg.org>
 <CACRpkdYirFNqmGhA4K9CL4ve4NYhs8Rd3SFt1iwW9vHBkrcz8g@mail.gmail.com>
 <51671D7B.5060303@wwwdotorg.org>
 <CACRpkdbf32Ef77GmXk9id9+RRjcDRTr7S+F4nznoeZU8y=BT_Q@mail.gmail.com>
 <51673D70.3010503@wwwdotorg.org>
 <CAAwP0s0e2x33jZQhFRY+Hoo61SFqYKRgWk=1mL2+DNxSDJHz+A@mail.gmail.com>
 <CACRpkda4h+qXTvsirPAS7E7sjXhMLE62q=VDy53W8UchsYjbNg@mail.gmail.com>
 <516C31C3.9040505@wwwdotorg.org> <516C73C6.5050409@ti.co m>
 <516C7C43.3040105@wwwdotorg.org> <516C8760.2050500@ti.com>
 <516D9B05.1000501@wwwdotorg.org>
Message-ID: <516DA60A.5070000@ti.com>


On 04/16/2013 01:40 PM, Stephen Warren wrote:
> On 04/15/2013 05:04 PM, Jon Hunter wrote:
>>
>> On 04/15/2013 05:16 PM, Stephen Warren wrote:
>>> On 04/15/2013 03:40 PM, Jon Hunter wrote:
> ...
>>>> mmc {
>>>> 	label = "pandaboard::status2";
>>>>  	gpios = <&gpio1 8 0>;
>>>> 	...
>>>> };
>>>
>>> But that's a gpio-leds instance, not an MMC controller... I really
>>> really hope there's no DT node using "gpios" to mean "interrupts"... And
>>> it wouldn't make any sense for an on-SoC device anyway.
>>
>> Oops yes, I overlooked that. However, the omap mmc driver
>> (drivers/mmc/host/omap_hsmmc.c) does call gpio_request() and
>> request_threaded_irq() for the mmc card-detect interrupt. I believe
>> tegra is doing the same ...
>>
>> sdhci at 78000000 {
>> 	...
>> 	cd-gpios = <&gpio 69 0>; /* gpio PI5 */
>> 	...	
>> };
> 
> Ah true. I guess at least all MMC drivers are likely hooking cd-gpios as
> an interrupt, /and/ requesting it as a GPIO so that they can read the
> current state when the GPIO goes off.
> 
> That tends to imply that no core code can possibly call gpio_request()
> in response to request_irq(), since doing so likely will conflict with
> quite a few drivers...

Yes that was my concern.

>>>> Both these devices are using a gpio as an interrupt source, but the mmc
>>>> driver is requesting the gpio directly. In the first case the xlate
>>>> function for the gpio irq domain will be called where as it is not used
>>>> in the 2nd case. Therefore, we could add a custom xlate function. For
>>>> example ...
>>>>
>>>> diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
>>>
>>>> +int omap_irq_domain_xlate(struct irq_domain *d, struct device_node *ctrlr,
>>> ...
>>>> +       gpio_request_one(irq_to_gpio(bank, intspec[0]), GPIOF_IN, ctrlr->name);
>>>
>>> I guess that could work, but:
>>>
>>> a) It still means doing the gpio_request() in each driver instead of
>>> centrally.
>>
>> Right this is device specific, but it avoids exposing irq_to_gpio for a
>> device. However, we could make this generic if we did expose irq_to_gpio
>> for each device.
>>
>>> b) This approach doesn't solve the issue where some client driver has
>>> already requested the GPIO. This code would simply prevent that call
>>> from succeeding, which would probably make the driver probe() error out,
>>> which isn't any different to the equivalent proposed centralized
>>> gpio_request() inside some request_irq() failing, and causing the
>>> device's probe() to error out.
>>
>> If some driver is calling gpio_request() directly, then they will most
>> likely just call gpio_to_irq() when requesting the interrupt and so the
>> xlate function would not be called in this case (mmc drivers are a good
>> example). So I don't see that as being a problem. In fact that's the
>> benefit of this approach as AFAICT it solves this problem.
> 
> Oh. That assumption seems very fragile. What about drivers that actually
> do have platform data (or DT bindings) that provide both the IRQ and
> GPIO IDs, and hence don't use gpio_to_irq()? That's entirely possible.

Right. In the DT case though, if someone does provide the IRQ and GPIO
IDs then at least they would use a different xlate function. Another
option to consider would be defining the #interrupt-cells = <3> where we
would have ...

cell-#1 --> IRQ domain ID
cell-#2 --> Trigger type
cell-#3 --> GPIO ID

Then we could have a generic xlate for 3 cells that would also request
the GPIO. Again not sure if people are against a gpio being requested in
the xlate but just an idea. Or given that irq_of_parse_and_map() calls
the xlate, we could have this function call gpio_request() if the
interrupt controller is a gpio and there are 3 cells.

> Given all this, I guess simply having each GPIO+IRQ driver's set_type
> function simply do whatever is required in HW to set up that GPIO
> actually does seem like the best idea. Admittedly that isn't
> centralized, but I'm not sure now that any centralized implementation is
> possible, without significant rework of a bunch of drivers. This is what
> the Tegra GPIO driver already does, and I think one of the earlier
> patches in this thread did exactly that for OMAP IRQs too right?

Yes, however, Linus wanted us to make sure the gpio is requested which
is why we have not taken that patch. However, if we cannot find a better
alternative may be we have to do that for now.

> BTW, just so you know, I'm on vacation for 2 weeks starting Wed
> afternoon, so replies will be non-existent or spotty during that time.

Thanks!
Jon


From plagnioj at jcrosoft.com  Tue Apr 16 15:47:52 2013
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Tue, 16 Apr 2013 21:47:52 +0200
Subject: [PATCH 1/1] ARM: at91sam9260: dt: uart1 fix pinctrl typo
Message-ID: <1366141672-10302-1-git-send-email-plagnioj@jcrosoft.com>

it's bank B not C

Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
Cc: Nicolas Ferre <nicolas.ferre at atmel.com>
Reported-by: Adam Porter <porter.adam at gmail.com>
---
 arch/arm/boot/dts/at91sam9260.dtsi |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/at91sam9260.dtsi b/arch/arm/boot/dts/at91sam9260.dtsi
index 367a604..6980ed1 100644
--- a/arch/arm/boot/dts/at91sam9260.dtsi
+++ b/arch/arm/boot/dts/at91sam9260.dtsi
@@ -220,8 +220,8 @@
 				uart1 {
 					pinctrl_uart1: uart1-0 {
 						atmel,pins =
-							<2 12 0x1 0x1	/* PB12 periph A with pullup */
-							 2 13 0x1 0x0>;	/* PB13 periph A */
+							<1 12 0x1 0x1	/* PB12 periph A with pullup */
+							 1 13 0x1 0x0>;	/* PB13 periph A */
 					};
 				};
 
-- 
1.7.10.4



From mturquette at linaro.org  Tue Apr 16 15:58:26 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Tue, 16 Apr 2013 12:58:26 -0700
Subject: [PATCH] clk: Always notify whole subtree when reparenting
In-Reply-To: <afe397e3-c674-4dc3-9f3e-feea9275bb91@TX2EHSMHS023.ehs.local>
References: <afe397e3-c674-4dc3-9f3e-feea9275bb91@TX2EHSMHS023.ehs.local>
Message-ID: <20130416195826.19887.78037@quantum>

Quoting Soren Brinkmann (2013-04-16 10:06:50)
> A clock's notifier count only reflects notifiers which are registered
> directly for that clock. A reparent operation though affects the whole
> subtree because of a potential rate change.
> When issuing the pre rate change notifications only the notifier count
> for the clock to be changed is considered and notifiers for subclocks
> may never be called. Resulting in clocks in the subtree which have
> registered notifiers, may receive a POST_- or ABORT_RATE_CHANGE
> notification, without a PRE_RATE_CHANGE_NOTIFICATION.
> Therefore always traverse the whole subtree when issueing pre rate
> change notifications during a reparent operation.
> 
> Signed-off-by: Soren Brinkmann <soren.brinkmann at xilinx.com>
> ---
> This should probably be considered an RFC. There may be smarter ways to
> resolve this issue. E.g. forward notifier counts upstream the way it is done
> with enable counts.
> 

Hi Soren,

Thanks for the fix.  Some of the core code has changed enough lately
that it is worth going through and consolidating/cleaning up.  For
instance another nice optimization that is related might be something
like:


diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 20ce67f..15e8b41 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -1028,6 +1028,9 @@ static int __clk_speculate_rates(struct clk *clk, unsigned long parent_rate)
 	else
 		new_rate = parent_rate;
 
+	if (new_rate == clk->rate)
+		return ret;
+
 	/* abort rate change if a driver returns NOTIFY_BAD or NOTIFY_STOP */
 	if (clk->notifier_count)
 		ret = __clk_notify(clk, PRE_RATE_CHANGE, clk->rate, new_rate);


However it remains to be seen whether any drivers rely on
PRE_RATE_CHANGE notifiers even if the clock rate stays the same.

I don't think I'll take your patch for 3.10 since no one has reported a
bug with it yet, but I'll roll it into a larger cleanup series after the
merge window.

Thanks,
Mike

>         S?ren
> 
> 
>  drivers/clk/clk.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index 20ce67f..1179cb5 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -1481,8 +1481,7 @@ int clk_set_parent(struct clk *clk, struct clk *parent)
>         }
>  
>         /* propagate PRE_RATE_CHANGE notifications */
> -       if (clk->notifier_count)
> -               ret = __clk_speculate_rates(clk, p_rate);
> +       ret = __clk_speculate_rates(clk, p_rate);
>  
>         /* abort if a driver objects */
>         if (ret & NOTIFY_STOP_MASK)
> -- 
> 1.8.2.1


From soren.brinkmann at xilinx.com  Tue Apr 16 16:13:44 2013
From: soren.brinkmann at xilinx.com (=?utf-8?B?U8O2cmVu?= Brinkmann)
Date: Tue, 16 Apr 2013 13:13:44 -0700
Subject: [PATCH] clk: Always notify whole subtree when reparenting
In-Reply-To: <20130416195826.19887.78037@quantum>
References: <afe397e3-c674-4dc3-9f3e-feea9275bb91@TX2EHSMHS023.ehs.local>
 <20130416195826.19887.78037@quantum>
Message-ID: <ba2aafcd-94ad-442c-9366-77f34541334e@AM1EHSMHS009.ehs.local>

Hi Mike,

On Tue, Apr 16, 2013 at 12:58:26PM -0700, Mike Turquette wrote:
> Quoting Soren Brinkmann (2013-04-16 10:06:50)
> > A clock's notifier count only reflects notifiers which are registered
> > directly for that clock. A reparent operation though affects the whole
> > subtree because of a potential rate change.
> > When issuing the pre rate change notifications only the notifier count
> > for the clock to be changed is considered and notifiers for subclocks
> > may never be called. Resulting in clocks in the subtree which have
> > registered notifiers, may receive a POST_- or ABORT_RATE_CHANGE
> > notification, without a PRE_RATE_CHANGE_NOTIFICATION.
> > Therefore always traverse the whole subtree when issueing pre rate
> > change notifications during a reparent operation.
> > 
> > Signed-off-by: Soren Brinkmann <soren.brinkmann at xilinx.com>
> > ---
> > This should probably be considered an RFC. There may be smarter ways to
> > resolve this issue. E.g. forward notifier counts upstream the way it is done
> > with enable counts.
> > 
> 
> Hi Soren,
> 
> Thanks for the fix.  Some of the core code has changed enough lately
> that it is worth going through and consolidating/cleaning up.  For
> instance another nice optimization that is related might be something
> like:
> 
> 
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index 20ce67f..15e8b41 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -1028,6 +1028,9 @@ static int __clk_speculate_rates(struct clk *clk, unsigned long parent_rate)
>  	else
>  		new_rate = parent_rate;
>  
> +	if (new_rate == clk->rate)
> +		return ret;
> +
>  	/* abort rate change if a driver returns NOTIFY_BAD or NOTIFY_STOP */
>  	if (clk->notifier_count)
>  		ret = __clk_notify(clk, PRE_RATE_CHANGE, clk->rate, new_rate);
> 
> 
> However it remains to be seen whether any drivers rely on
> PRE_RATE_CHANGE notifiers even if the clock rate stays the same.
Even if it changes the pre-rate change notifier is not issued.

> I don't think I'll take your patch for 3.10 since no one has reported a
> bug with it yet, but I'll roll it into a larger cleanup series after the
> merge window.
That's fine. I'm still revising Zynq's clock code and w/o this patch my
UART breaks since I don't receive a pre-rate-change notification when its
input frequency changes due to reparenting of clocks further up in the
hierarchy.

	S?ren




From sylvester.nawrocki at gmail.com  Tue Apr 16 16:51:35 2013
From: sylvester.nawrocki at gmail.com (Sylwester Nawrocki)
Date: Tue, 16 Apr 2013 22:51:35 +0200
Subject: [PATCH v5 00/14] ARM: samsung-time: Prepare for multiplatform
 support
In-Reply-To: <1365794250-14436-1-git-send-email-t.figa@samsung.com>
References: <1365794250-14436-1-git-send-email-t.figa@samsung.com>
Message-ID: <516DB9D7.1070705@gmail.com>

On 04/12/2013 09:17 PM, Tomasz Figa wrote:
> This series is an attempt to make the samsung-time clocksource driver ready
> for multiplatform kernels. It moves the driver to drivers/clocksource, cleans
> it up from uses of static platform-specific definitions, simplifies timer
> interrupt handling and adds Device Tree support.
>
> The samsung_pwm clocksource driver is made the master driver, which
> exposes a single function to the PWM driver to get required data. Only
> samsung-time driver is reworked to use the master driver at this time,
> since the PWM driver can be already considered broken at the moment and
> needs separate series of several patches to fix and clean it up, which
> I am already working on.
>
> Tested on Universal C210 board with Device Tree. Not tested without
> Device Tree, since it has been already broken before this series.
> Compile tested for other related SoCs.

On s3c2440 based board

Tested-by: Sylwester Nawrocki <s.nawrocki at samsung.com>


From sergei.shtylyov at cogentembedded.com  Tue Apr 16 17:30:59 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Wed, 17 Apr 2013 01:30:59 +0400
Subject: [PATCH v3 0/4] Add USB support to R8A7778/BOCK-W
Message-ID: <201304170131.00238.sergei.shtylyov@cogentembedded.com>

Hello.

   Here's the set of 4 patches against the Simon Horman's 'renesas.git' repo,
'renesas-next-20130416' tag and the R8A7779/Marzen patchset I've posted.
 It was created to add support of R8A7778/BOCK-W USB to the platform code and
the USB common PHY driver, and so spans both arch/arm/mach-shmobile/ and
drivers/usb/phy/ subtrees.

[1/4] rcar-phy: add R8A7778 support
[2/4] ARM: shmobile: r8a7778: add USB support
[3/4] ARM: shmobile: BOCK-W: add USB support
[4/4] ARM: shmobile: BOCK-W: enable USB in defconfig

WBR, Sergei


From tony at atomide.com  Tue Apr 16 17:32:33 2013
From: tony at atomide.com (Tony Lindgren)
Date: Tue, 16 Apr 2013 14:32:33 -0700
Subject: Query on pinctrl usage for DT nodes
In-Reply-To: <516BB99F.2080502@ti.com>
References: <CA+V-a8uiPwsAD--OHFAE=i2ed+-wbXm4p2deZXr92+Zv6GDS1w@mail.gmail.com>
 <515C5C76.3080009@wwwdotorg.org>
 <CA+V-a8t3wtP77DdeUoQHKMjAuWmV+ude+1J3UjJmMTqobgStjA@mail.gmail.com>
 <5162FD4A.1030909@wwwdotorg.org>
 <CA+V-a8vwdCkyMqiynj5BodXbjwJ=e4qNb-29FhLweqbjc7DBQA@mail.gmail.com>
 <5165A22B.4070200@wwwdotorg.org>
 <20130410203408.GP10155@atomide.com> <516BB99F.2080502@ti.com>
Message-ID: <20130416213232.GU10155@atomide.com>

* Peter Ujfalusi <peter.ujfalusi at ti.com> [130415 01:30]:
> On 04/10/2013 10:34 PM, Tony Lindgren wrote:
> > Yeah how about just change the pintctrl-single,bits register
> > naming to be register + bit?  Something like 0xdeadbeef.0 and
> > 0xdeadbeef.1 and so on.
> 
> Something like this might work I think. It is going to be a bit tricky IMHO
> since we might need span out new 'register' every time a device requests for a
> new pinctrl-single,bits for already used register in the
> pinctrl-single,bit-per-mux area. In this way we still can make sure that
> certain bit are only used by a single driver.

OK. If it's one bit per mux type register we should be able to create
the right amount of entries based on the submask in pinctrs-single,bit?

Regards,

Tony


From sergei.shtylyov at cogentembedded.com  Tue Apr 16 17:33:52 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Wed, 17 Apr 2013 01:33:52 +0400
Subject: [PATCH v3 2/4] ARM: shmobile: r8a7778: add USB support
Message-ID: <201304170133.52854.sergei.shtylyov@cogentembedded.com>

Add USB clock and EHCI, OHCI, and USB PHY platform devices for R8A7778 SoC;  add
a function to register PHY device with board-specific platform data and register
EHCI and OHCI platfrom devices from the init_late() board method.

Also,  don't forget to enable CONFIG_ARCH_HAS_[EO]HCI options for R8A7778 SoC in
Kconfig...

The patch has been tested on the BOCK-W board.

Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

---
Changes since version 2:
- refreshed the patch.

Changes since the original posting:
- resolved rejects in the 'clock-r8a7778.c' file;
- lowercased the SoC name in the subject.

 arch/arm/mach-shmobile/Kconfig                |    2 
 arch/arm/mach-shmobile/clock-r8a7778.c        |    4 
 arch/arm/mach-shmobile/include/mach/r8a7778.h |    3 
 arch/arm/mach-shmobile/setup-r8a7778.c        |  108 ++++++++++++++++++++++++++
 4 files changed, 117 insertions(+)

Index: renesas/arch/arm/mach-shmobile/Kconfig
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/Kconfig
+++ renesas/arch/arm/mach-shmobile/Kconfig
@@ -41,6 +41,8 @@ config ARCH_R8A7778
 	select CPU_V7
 	select SH_CLK_CPG
 	select ARM_GIC
+	select USB_ARCH_HAS_EHCI
+	select USB_ARCH_HAS_OHCI
 
 config ARCH_R8A7779
 	bool "R-Car H1 (R8A77790)"
Index: renesas/arch/arm/mach-shmobile/clock-r8a7778.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/clock-r8a7778.c
+++ renesas/arch/arm/mach-shmobile/clock-r8a7778.c
@@ -104,12 +104,14 @@ static struct clk *main_clks[] = {
 
 enum {
 	MSTP114,
+	MSTP100,
 	MSTP026, MSTP025, MSTP024, MSTP023, MSTP022, MSTP021,
 	MSTP016, MSTP015,
 	MSTP_NR };
 
 static struct clk mstp_clks[MSTP_NR] = {
 	[MSTP114] = SH_CLK_MSTP32(&p_clk, MSTPCR1, 14, 0), /* Ether */
+	[MSTP100] = SH_CLK_MSTP32(&p_clk, MSTPCR1,  0, 0), /* USB0/1 */
 	[MSTP026] = SH_CLK_MSTP32(&p_clk, MSTPCR0, 26, 0), /* SCIF0 */
 	[MSTP025] = SH_CLK_MSTP32(&p_clk, MSTPCR0, 25, 0), /* SCIF1 */
 	[MSTP024] = SH_CLK_MSTP32(&p_clk, MSTPCR0, 24, 0), /* SCIF2 */
@@ -123,6 +125,8 @@ static struct clk mstp_clks[MSTP_NR] = {
 static struct clk_lookup lookups[] = {
 	/* MSTP32 clocks */
 	CLKDEV_DEV_ID("sh-eth",	&mstp_clks[MSTP114]), /* Ether */
+	CLKDEV_DEV_ID("ehci-platform", &mstp_clks[MSTP100]), /* USB EHCI port0/1 */
+	CLKDEV_DEV_ID("ohci-platform", &mstp_clks[MSTP100]), /* USB OHCI port0/1 */
 	CLKDEV_DEV_ID("sh-sci.0", &mstp_clks[MSTP026]), /* SCIF0 */
 	CLKDEV_DEV_ID("sh-sci.1", &mstp_clks[MSTP025]), /* SCIF1 */
 	CLKDEV_DEV_ID("sh-sci.2", &mstp_clks[MSTP024]), /* SCIF2 */
Index: renesas/arch/arm/mach-shmobile/include/mach/r8a7778.h
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/include/mach/r8a7778.h
+++ renesas/arch/arm/mach-shmobile/include/mach/r8a7778.h
@@ -19,10 +19,13 @@
 #define __ASM_R8A7778_H__
 
 #include <linux/sh_eth.h>
+#include <linux/usb/rcar-phy.h>
 
 extern void r8a7778_add_standard_devices(void);
 extern void r8a7778_add_standard_devices_dt(void);
 extern void r8a7778_add_ether_device(struct sh_eth_plat_data *pdata);
+extern void r8a7778_add_usb_phy_device(struct rcar_phy_platform_data *pdata);
+extern void r8a7778_init_late(void);
 extern void r8a7778_init_delay(void);
 extern void r8a7778_init_irq(void);
 extern void r8a7778_init_irq_dt(void);
Index: renesas/arch/arm/mach-shmobile/setup-r8a7778.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/setup-r8a7778.c
+++ renesas/arch/arm/mach-shmobile/setup-r8a7778.c
@@ -29,6 +29,12 @@
 #include <linux/irqchip.h>
 #include <linux/serial_sci.h>
 #include <linux/sh_timer.h>
+#include <linux/pm_runtime.h>
+#include <linux/usb/phy.h>
+#include <linux/usb/hcd.h>
+#include <linux/usb/ehci_pdriver.h>
+#include <linux/usb/ohci_pdriver.h>
+#include <linux/dma-mapping.h>
 #include <mach/irqs.h>
 #include <mach/r8a7778.h>
 #include <mach/common.h>
@@ -88,6 +94,99 @@ static struct sh_timer_config sh_tmu1_pl
 		&sh_tmu##idx##_platform_data,		\
 		sizeof(sh_tmu##idx##_platform_data))
 
+/* USB PHY */
+static struct resource usb_phy_resources[] = {
+	DEFINE_RES_MEM(0xffe70800, 0x100),
+	DEFINE_RES_MEM(0xffe76000, 0x100),
+};
+
+void __init r8a7778_add_usb_phy_device(struct rcar_phy_platform_data *pdata)
+{
+	platform_device_register_resndata(&platform_bus, "rcar_usb_phy", -1,
+					  usb_phy_resources,
+					  ARRAY_SIZE(usb_phy_resources),
+					  pdata, sizeof(*pdata));
+}
+
+/* USB */
+static struct usb_phy *phy;
+
+static int usb_power_on(struct platform_device *pdev)
+{
+	if (!phy)
+		return -EIO;
+
+	pm_runtime_enable(&pdev->dev);
+	pm_runtime_get_sync(&pdev->dev);
+
+	usb_phy_init(phy);
+
+	return 0;
+}
+
+static void usb_power_off(struct platform_device *pdev)
+{
+	if (!phy)
+		return;
+
+	usb_phy_shutdown(phy);
+
+	pm_runtime_put_sync(&pdev->dev);
+	pm_runtime_disable(&pdev->dev);
+}
+
+static int ehci_init_internal_buffer(struct usb_hcd *hcd)
+{
+	/*
+	 * Below are recommended values from the datasheet;
+	 * see [USB :: Setting of EHCI Internal Buffer].
+	 */
+	/* EHCI IP internal buffer setting */
+	iowrite32(0x00ff0040, hcd->regs + 0x0094);
+	/* EHCI IP internal buffer enable */
+	iowrite32(0x00000001, hcd->regs + 0x009C);
+
+	return 0;
+}
+
+static struct usb_ehci_pdata ehci_pdata = {
+	.power_on	= usb_power_on,
+	.power_off	= usb_power_off,
+	.power_suspend	= usb_power_off,
+	.pre_setup	= ehci_init_internal_buffer,
+};
+
+static struct resource ehci_resources[] = {
+	DEFINE_RES_MEM(0xffe70000, 0x400),
+	DEFINE_RES_IRQ(gic_iid(0x4c)),
+};
+
+static struct usb_ohci_pdata ohci_pdata = {
+	.power_on	= usb_power_on,
+	.power_off	= usb_power_off,
+	.power_suspend	= usb_power_off,
+};
+
+static struct resource ohci_resources[] = {
+	DEFINE_RES_MEM(0xffe70400, 0x400),
+	DEFINE_RES_IRQ(gic_iid(0x4c)),
+};
+
+#define USB_PLATFORM_INFO(hci)				\
+static struct platform_device_info hci##_info = {	\
+	.parent		= &platform_bus,		\
+	.name		= #hci "-platform",		\
+	.id		= -1,				\
+	.res		= hci##_resources,		\
+	.num_res	= ARRAY_SIZE(hci##_resources),	\
+	.data		= &hci##_pdata,			\
+	.size_data	= sizeof(hci##_pdata),		\
+	.dma_mask	= DMA_BIT_MASK(32),		\
+}
+
+USB_PLATFORM_INFO(ehci);
+USB_PLATFORM_INFO(ohci);
+
 /* Ether */
 static struct resource ether_resources[] = {
 	DEFINE_RES_MEM(0xfde00000, 0x400),
@@ -139,6 +238,14 @@ void __init r8a7778_add_standard_devices
 	r8a7778_register_tmu(1);
 }
 
+void __init r8a7778_init_late(void)
+{
+	phy = usb_get_phy(USB_PHY_TYPE_USB2);
+
+	platform_device_register_full(&ehci_info);
+	platform_device_register_full(&ohci_info);
+}
+
 static struct renesas_intc_irqpin_config irqpin_platform_data = {
 	.irq_base = irq_pin(0), /* IRQ0 -> IRQ3 */
 	.sense_bitfield_width = 2,
@@ -252,6 +359,7 @@ DT_MACHINE_START(R8A7778_DT, "Generic R8
 	.init_machine	= r8a7778_add_standard_devices_dt,
 	.init_time	= shmobile_timer_init,
 	.dt_compat	= r8a7778_compat_dt,
+	.init_late      = r8a7778_init_late,
 MACHINE_END
 
 #endif /* CONFIG_USE_OF */


From sergei.shtylyov at cogentembedded.com  Tue Apr 16 17:34:47 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Wed, 17 Apr 2013 01:34:47 +0400
Subject: [PATCH v3 3/4] ARM: shmobile: BOCK-W: add USB support
Message-ID: <201304170134.47851.sergei.shtylyov@cogentembedded.com>

Register the USB PHY device from bockw_init(), passing the platform  data to it.
Set machine's init_late() method to r8a7778_init_late() in order for [EO]HCI to
get registered too...

The patch has been tested on the BOCK-W board.

Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

---
Changes since version 2:
- refreshed the patch.

Changes since the original posting:
- removed initializer for no longer existing field in 'usb_phy_platform_data',
  modified the comment to the 'ferrite_bead' field initializer.

 arch/arm/mach-shmobile/board-bockw.c |    6 ++++++
 1 file changed, 6 insertions(+)

Index: renesas/arch/arm/mach-shmobile/board-bockw.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/board-bockw.c
+++ renesas/arch/arm/mach-shmobile/board-bockw.c
@@ -54,6 +54,10 @@ static struct resource smsc911x_resource
 	DEFINE_RES_IRQ(irq_pin(0)), /* IRQ 0 */
 };
 
+static struct rcar_phy_platform_data usb_phy_platform_data = {
+	.ferrite_bead	= true,		/* not sure about this... */
+};
+
 static const struct pinctrl_map bockw_pinctrl_map[] = {
 	/* SCIF0 */
 	PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.0", "pfc-r8a7778",
@@ -70,6 +74,7 @@ static void __init bockw_init(void)
 	r8a7778_clock_init();
 	r8a7778_init_irq_extpin(1);
 	r8a7778_add_standard_devices();
+	r8a7778_add_usb_phy_device(&usb_phy_platform_data);
 
 	pinctrl_register_mappings(bockw_pinctrl_map,
 				  ARRAY_SIZE(bockw_pinctrl_map));
@@ -110,4 +115,5 @@ DT_MACHINE_START(BOCKW_DT, "bockw")
 	.init_machine	= bockw_init,
 	.init_time	= shmobile_timer_init,
 	.dt_compat	= bockw_boards_compat_dt,
+	.init_late      = r8a7778_init_late,
 MACHINE_END


From sergei.shtylyov at cogentembedded.com  Tue Apr 16 17:35:09 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Wed, 17 Apr 2013 01:35:09 +0400
Subject: [PATCH v3 4/4] ARM: shmobile: BOCK-W: enable USB in defconfig
Message-ID: <201304170135.10251.sergei.shtylyov@cogentembedded.com>

Enable USB platform EHCI/OHCI and common PHY drivers in 'bockw_defconfig'.
Enable USB storage driver and SCSI disk driver that it needs as well...

Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

---
 arch/arm/configs/bockw_defconfig |   11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

Index: renesas/arch/arm/configs/bockw_defconfig
===================================================================
--- renesas.orig/arch/arm/configs/bockw_defconfig
+++ renesas/arch/arm/configs/bockw_defconfig
@@ -48,6 +48,8 @@ CONFIG_DEVTMPFS_MOUNT=y
 # CONFIG_STANDALONE is not set
 # CONFIG_PREVENT_FIRMWARE_BUILD is not set
 # CONFIG_FW_LOADER is not set
+CONFIG_SCSI=y
+CONFIG_BLK_DEV_SD=y
 CONFIG_NETDEVICES=y
 # CONFIG_NET_CADENCE is not set
 # CONFIG_NET_VENDOR_BROADCOM is not set
@@ -71,7 +73,14 @@ CONFIG_SERIAL_SH_SCI_NR_UARTS=6
 CONFIG_SERIAL_SH_SCI_CONSOLE=y
 # CONFIG_HW_RANDOM is not set
 # CONFIG_HWMON is not set
-# CONFIG_USB_SUPPORT is not set
+CONFIG_USB=y
+CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
+CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_OHCI_HCD=y
+CONFIG_USB_OHCI_HCD_PLATFORM=y
+CONFIG_USB_EHCI_HCD_PLATFORM=y
+CONFIG_USB_STORAGE=y
+CONFIG_USB_RCAR_PHY=y
 CONFIG_UIO=y
 CONFIG_UIO_PDRV_GENIRQ=y
 # CONFIG_IOMMU_SUPPORT is not set


From jon-hunter at ti.com  Tue Apr 16 17:57:02 2013
From: jon-hunter at ti.com (Jon Hunter)
Date: Tue, 16 Apr 2013 16:57:02 -0500
Subject: [PATCH 3/5] gpio/omap: Add DT support to GPIO driver
In-Reply-To: <516DA60A.5070000@ti.com>
References: <1329321854-24490-1-git-send-email-b-cousson@ti.com>
 <514C79E1.4090106@wwwdotorg.org> <514CE0AB.6060207@ti.com>
 <CACRpkdZmv-rAoKSQYpkHHSMzKJOn5TixVW_P3=m7ZNagBYCUPw@mail.gmail.com>
 <515319D5.20105@wwwdotorg.org>
 <CACRpkdYXVLgCz1Tyu-Ls2V2OTc4R3cGNJhfQJB6Hiz_K9dkZYQ@mail.gmail.com>
 <5155C902.7080207@wwwdotorg.org>
 <CACRpkdYbs4-uudpRUY8e+7icYYkZrfM0kReP3pLL5DMiURJ4dg@mail.gmail.com>
 <5165CB9D.1090202@wwwdotorg.org>
 <CACRpkdYirFNqmGhA4K9CL4ve4NYhs8Rd3SFt1iwW9vHBkrcz8g@mail.gmail.com>
 <51671D7B.5060303@wwwdotorg.org>
 <CACRpkdbf32Ef77GmXk9id9+RRjcDRTr7S+F4nznoeZU8y=BT_Q@mail.gmail.com>
 <51673D70.3010503@wwwdotorg.org>
 <CAAwP0s0e2x33jZQhFRY+Hoo61SFqYKRgWk=1mL2+DNxSDJHz+A@mail.gmail.com>
 <CACRpkda4h+qXTvsirPAS7E7sjXhMLE62q=VDy53W8UchsYjbNg@mail.gmail.com>
 <516C31C3.9040505@wwwdotorg.org> <516C73C6.5050409@ti.co m>
 <516C7C43.3040105@wwwdotorg.org> <516C8760.2050500@ti.com>
 <516D9B05.1000501@wwwdotorg.org> <516DA60A.5070000@ti.com>
Message-ID: <516DC92E.106@ti.com>


On 04/16/2013 02:27 PM, Jon Hunter wrote:

...

> Right. In the DT case though, if someone does provide the IRQ and GPIO
> IDs then at least they would use a different xlate function. Another
> option to consider would be defining the #interrupt-cells = <3> where we
> would have ...
> 
> cell-#1 --> IRQ domain ID
> cell-#2 --> Trigger type
> cell-#3 --> GPIO ID
> 
> Then we could have a generic xlate for 3 cells that would also request
> the GPIO. Again not sure if people are against a gpio being requested in
> the xlate but just an idea. Or given that irq_of_parse_and_map() calls
> the xlate, we could have this function call gpio_request() if the
> interrupt controller is a gpio and there are 3 cells.

So basically some like the following (note I have only included the omap
portion in here for an example). The other benefit being no need to 
re-introduce irq_to_gpio.

Jon

>From f01ce047075a922969fcbe904b339fe8d03a997b Mon Sep 17 00:00:00 2001
From: Jon Hunter <jon-hunter at ti.com>
Date: Tue, 16 Apr 2013 09:54:28 -0500
Subject: [PATCH] gpio: add custom xlate for gpio irqs

---
 drivers/gpio/gpio-omap.c  |    3 ++-
 drivers/gpio/gpiolib-of.c |   24 ++++++++++++++++++++++++
 include/linux/of_gpio.h   |    1 +
 3 files changed, 27 insertions(+), 1 deletion(-)

diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index d337318..b3d7d43 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -24,6 +24,7 @@
 #include <linux/pm.h>
 #include <linux/of.h>
 #include <linux/of_device.h>
+#include <linux/of_gpio.h>
 #include <linux/irqdomain.h>
 #include <linux/gpio.h>
 #include <linux/platform_data/gpio-omap.h>
@@ -1135,7 +1136,7 @@ static int omap_gpio_probe(struct platform_device *pdev)
 
 
 	bank->domain = irq_domain_add_linear(node, bank->width,
-					     &irq_domain_simple_ops, NULL);
+					     &of_gpio_irq_domain_ops, NULL);
 	if (!bank->domain)
 		return -ENODEV;
 
diff --git a/drivers/gpio/gpiolib-of.c b/drivers/gpio/gpiolib-of.c
index 5150df6..fc01ec1 100644
--- a/drivers/gpio/gpiolib-of.c
+++ b/drivers/gpio/gpiolib-of.c
@@ -15,6 +15,8 @@
 #include <linux/errno.h>
 #include <linux/module.h>
 #include <linux/io.h>
+#include <linux/irq.h>
+#include <linux/irqdomain.h>
 #include <linux/gpio.h>
 #include <linux/of.h>
 #include <linux/of_address.h>
@@ -253,3 +255,25 @@ void of_gpiochip_remove(struct gpio_chip *chip)
 	if (chip->of_node)
 		of_node_put(chip->of_node);
 }
+
+int of_gpio_irq_domain_xlate(struct irq_domain *d, struct device_node *ctrlr,
+                            const u32 *intspec, unsigned int intsize,
+                            unsigned long *out_hwirq, unsigned int *out_type)
+{
+       int ret;
+
+       if (WARN_ON(intsize < 3))
+               return -EINVAL;
+
+       ret = gpio_request_one(intspec[2], GPIOF_IN, NULL);
+       if (ret)
+               return ret;
+
+       *out_hwirq = intspec[0];
+       *out_type = (intsize > 1) ? intspec[1] : IRQ_TYPE_NONE;
+       return 0;
+}
+
+const struct irq_domain_ops of_gpio_irq_domain_ops = {
+       .xlate = of_gpio_irq_domain_xlate,
+};
diff --git a/include/linux/of_gpio.h b/include/linux/of_gpio.h
index a83dc6f..ad2b962 100644
--- a/include/linux/of_gpio.h
+++ b/include/linux/of_gpio.h
@@ -58,6 +58,7 @@ extern void of_gpiochip_remove(struct gpio_chip *gc);
 extern int of_gpio_simple_xlate(struct gpio_chip *gc,
 				const struct of_phandle_args *gpiospec,
 				u32 *flags);
+extern const struct irq_domain_ops of_gpio_irq_domain_ops;
 
 #else /* CONFIG_OF_GPIO */
 
-- 
1.7.10.4



From swarren at wwwdotorg.org  Tue Apr 16 18:11:52 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Tue, 16 Apr 2013 16:11:52 -0600
Subject: [PATCH 3/5] gpio/omap: Add DT support to GPIO driver
In-Reply-To: <516DA60A.5070000@ti.com>
References: <1329321854-24490-1-git-send-email-b-cousson@ti.com>
 <514C79E1.4090106@wwwdotorg.org> <514CE0AB.6060207@ti.com>
 <CACRpkdZmv-rAoKSQYpkHHSMzKJOn5TixVW_P3=m7ZNagBYCUPw@mail.gmail.com>
 <515319D5.20105@wwwdotorg.org>
 <CACRpkdYXVLgCz1Tyu-Ls2V2OTc4R3cGNJhfQJB6Hiz_K9dkZYQ@mail.gmail.com>
 <5155C902.7080207@wwwdotorg.org>
 <CACRpkdYbs4-uudpRUY8e+7icYYkZrfM0kReP3pLL5DMiURJ4dg@mail.gmail.com>
 <5165CB9D.1090202@wwwdotorg.org>
 <CACRpkdYirFNqmGhA4K9CL4ve4NYhs8Rd3SFt1iwW9vHBkrcz8g@mail.gmail.com>
 <51671D7B.5060303@wwwdotorg.org>
 <CACRpkdbf32Ef77GmXk9id9+RRjcDRTr7S+F4nznoeZU8y=BT_Q@mail.gmail.com>
 <51673D70.3010503@wwwdotorg.org>
 <CAAwP0s0e2x33jZQhFRY+Hoo61SFqYKRgWk=1mL2+DNxSDJHz+A@mail.gmail.com>
 <CACRpkda4h+qXTvsirPAS7E7sjXhMLE62q=VDy53W8UchsYjbNg@mail.gmail.com>
 <516C31C3.9040505@wwwdotorg.org> <516C73C6.5050409@ti.co m>
 <516C7C43.3040105@wwwdotorg.org> <516C8760.2050500@ti.com>
 <516D9B05.1000501@wwwdotorg.org> <516DA60A.5070000@ti.com>
Message-ID: <516DCCA8.3070108@wwwdotorg.org>

On 04/16/2013 01:27 PM, Jon Hunter wrote:
> 
> On 04/16/2013 01:40 PM, Stephen Warren wrote:
>> On 04/15/2013 05:04 PM, Jon Hunter wrote:
...
>>> If some driver is calling gpio_request() directly, then they will most
>>> likely just call gpio_to_irq() when requesting the interrupt and so the
>>> xlate function would not be called in this case (mmc drivers are a good
>>> example). So I don't see that as being a problem. In fact that's the
>>> benefit of this approach as AFAICT it solves this problem.
>>
>> Oh. That assumption seems very fragile. What about drivers that actually
>> do have platform data (or DT bindings) that provide both the IRQ and
>> GPIO IDs, and hence don't use gpio_to_irq()? That's entirely possible.
> 
> Right. In the DT case though, if someone does provide the IRQ and GPIO
> IDs then at least they would use a different xlate function. Another
> option to consider would be defining the #interrupt-cells = <3> where we
> would have ...
> 
> cell-#1 --> IRQ domain ID
> cell-#2 --> Trigger type
> cell-#3 --> GPIO ID
> 
> Then we could have a generic xlate for 3 cells that would also request
> the GPIO. Again not sure if people are against a gpio being requested in
> the xlate but just an idea. Or given that irq_of_parse_and_map() calls
> the xlate, we could have this function call gpio_request() if the
> interrupt controller is a gpio and there are 3 cells.

I rather dislike this approach since:

a) It requires changes to the DT bindings, which are already defined.
Admittedly it's backwards-compatible, but still.

b) There isn't really any need for the DT to represent this; the
GPIO+IRQ driver itself already knows which IRQ ID is which GPIO ID and
vice-versa (if the HW has such a concept), so there's no need for the DT
to contain this information. This seems like pushing Linux's internal
requirements into the design of the DT binding.

c) I have the feeling that hooking the of_xlate function for this is a
bit of an abuse of the function.


From tomasz.figa at gmail.com  Tue Apr 16 18:23:59 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Wed, 17 Apr 2013 00:23:59 +0200
Subject: [PATCH 1/2] pinctrl: s3c64xx: Fix build error caused by undefined
 chained_irq_enter
In-Reply-To: <20130416163331.GP26958@opensource.wolfsonmicro.com>
References: <1366060483-20342-1-git-send-email-tomasz.figa@gmail.com>
 <20130416163331.GP26958@opensource.wolfsonmicro.com>
Message-ID: <30362001.FF4K7WsZvh@flatron>

Commit de88cbb7 moved definitions of chained_irq_enter and
chained_irq_exit to a generic header, which must be now included instead
of the legacy arch-specific one.

This patch fixes build error caused by including the legacy header
leading to undefined chained_irq_enter and chained_irq_exit symbols.

Signed-off-by: Tomasz Figa <tomasz.figa at gmail.com>
---
 drivers/pinctrl/pinctrl-s3c64xx.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-s3c64xx.c b/drivers/pinctrl/pinctrl-s3c64xx.c
index b5d1c4a..89143c9 100644
--- a/drivers/pinctrl/pinctrl-s3c64xx.c
+++ b/drivers/pinctrl/pinctrl-s3c64xx.c
@@ -22,11 +22,10 @@
 #include <linux/irq.h>
 #include <linux/of_irq.h>
 #include <linux/io.h>
+#include <linux/irqchip/chained_irq.h>
 #include <linux/slab.h>
 #include <linux/err.h>
 
-#include <asm/mach/irq.h>
-
 #include "pinctrl-samsung.h"
 
 #define NUM_EINT0		28
-- 
1.8.1.5




From tomasz.figa at gmail.com  Tue Apr 16 18:24:39 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Wed, 17 Apr 2013 00:24:39 +0200
Subject: [PATCH 2/2] pinctrl: samsung: Fix link error with
 CONFIG_PINCTRL_EXYNOS disabled
In-Reply-To: <30362001.FF4K7WsZvh@flatron>
References: <1366060483-20342-1-git-send-email-tomasz.figa@gmail.com>
 <20130416163331.GP26958@opensource.wolfsonmicro.com>
 <30362001.FF4K7WsZvh@flatron>
Message-ID: <1398545.9FqHoC0WZW@flatron>

Commit f67faf487 added driver data for Exynos5250, which is available
only if CONFIG_PINCTRL_EXYNOS is enabled. However probably due to merge
error, the reference to this driver data structure was located outside
of relevant ifdef and compiled unconditionally, leading to link error
with CONFIG_PINCTRL_EXYNOS.

This patch fixes mentioned link error by moving driver data entry under
ifdef CONFIG_PINCTRL_EXYNOS.

Signed-off-by: Tomasz Figa <tomasz.figa at gmail.com>
---
 drivers/pinctrl/pinctrl-samsung.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-samsung.c b/drivers/pinctrl/pinctrl-
samsung.c
index f95dd69..9763668 100644
--- a/drivers/pinctrl/pinctrl-samsung.c
+++ b/drivers/pinctrl/pinctrl-samsung.c
@@ -970,13 +970,13 @@ static const struct of_device_id 
samsung_pinctrl_dt_match[] = {
 		.data = (void *)exynos4210_pin_ctrl },
 	{ .compatible = "samsung,exynos4x12-pinctrl",
 		.data = (void *)exynos4x12_pin_ctrl },
+	{ .compatible = "samsung,exynos5250-pinctrl",
+		.data = (void *)exynos5250_pin_ctrl },
 #endif
 #ifdef CONFIG_PINCTRL_S3C64XX
 	{ .compatible = "samsung,s3c64xx-pinctrl",
 		.data = s3c64xx_pin_ctrl },
 #endif
-	{ .compatible = "samsung,exynos5250-pinctrl",
-		.data = (void *)exynos5250_pin_ctrl },
 	{},
 };
 MODULE_DEVICE_TABLE(of, samsung_pinctrl_dt_match);
-- 
1.8.1.5




From tomasz.figa at gmail.com  Tue Apr 16 18:29:05 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Wed, 17 Apr 2013 00:29:05 +0200
Subject: [PATCH RESEND 2/2] pinctrl: samsung: Fix link error with
 CONFIG_PINCTRL_EXYNOS disabled
In-Reply-To: <30362001.FF4K7WsZvh@flatron>
References: <1366060483-20342-1-git-send-email-tomasz.figa@gmail.com>
 <20130416163331.GP26958@opensource.wolfsonmicro.com>
 <30362001.FF4K7WsZvh@flatron>
Message-ID: <2934745.t3ZR6H9zHp@flatron>

Commit f67faf487 added driver data for Exynos5250, which is available
only if CONFIG_PINCTRL_EXYNOS is enabled. However probably due to merge
error, the reference to this driver data structure was located outside
of relevant ifdef and compiled unconditionally, leading to link error
with CONFIG_PINCTRL_EXYNOS.

This patch fixes mentioned link error by moving driver data entry under
ifdef CONFIG_PINCTRL_EXYNOS.

Signed-off-by: Tomasz Figa <tomasz.figa at gmail.com>
---
 drivers/pinctrl/pinctrl-samsung.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-samsung.c b/drivers/pinctrl/pinctrl-samsung.c
index f95dd69..9763668 100644
--- a/drivers/pinctrl/pinctrl-samsung.c
+++ b/drivers/pinctrl/pinctrl-samsung.c
@@ -970,13 +970,13 @@ static const struct of_device_id samsung_pinctrl_dt_match[] = {
 		.data = (void *)exynos4210_pin_ctrl },
 	{ .compatible = "samsung,exynos4x12-pinctrl",
 		.data = (void *)exynos4x12_pin_ctrl },
+	{ .compatible = "samsung,exynos5250-pinctrl",
+		.data = (void *)exynos5250_pin_ctrl },
 #endif
 #ifdef CONFIG_PINCTRL_S3C64XX
 	{ .compatible = "samsung,s3c64xx-pinctrl",
 		.data = s3c64xx_pin_ctrl },
 #endif
-	{ .compatible = "samsung,exynos5250-pinctrl",
-		.data = (void *)exynos5250_pin_ctrl },
 	{},
 };
 MODULE_DEVICE_TABLE(of, samsung_pinctrl_dt_match);
-- 
1.8.1.5




From tomasz.figa at gmail.com  Tue Apr 16 18:31:50 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Wed, 17 Apr 2013 00:31:50 +0200
Subject: [PATCH v5 2/6] ARM: s3c64xx: Skip legacy EINT setup if
 pinctrl-s3c64xx driver is present
In-Reply-To: <20130416162642.GN26958@opensource.wolfsonmicro.com>
References: <1366060483-20342-1-git-send-email-tomasz.figa@gmail.com>
 <1366060483-20342-3-git-send-email-tomasz.figa@gmail.com>
 <20130416162642.GN26958@opensource.wolfsonmicro.com>
Message-ID: <4730257.2Cvjq41NtX@flatron>

On Tuesday 16 of April 2013 17:26:43 Mark Brown wrote:
> On Mon, Apr 15, 2013 at 11:14:39PM +0200, Tomasz Figa wrote:
> > +	* This gpio driver includes support for device tree support and
> > there
> > +	* are platforms using it. In order to maintain compatibility with
> > those +	* platforms, and to allow non-dt Exynos4210 platforms to 
use
> > this +	* gpiolib support, a check is added to find out if there 
is a
> > active
> Cut'n'paste error here.

<blushed>

Thanks for catching this.

Best regards,
Tomasz



From tomasz.figa at gmail.com  Tue Apr 16 18:35:58 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Wed, 17 Apr 2013 00:35:58 +0200
Subject: [PATCH v5 3/6] gpio: samsung: Skip legacy GPIO registration if
 pinctrl-s3c64xx is present
In-Reply-To: <20130416162750.GO26958@opensource.wolfsonmicro.com>
References: <1366060483-20342-1-git-send-email-tomasz.figa@gmail.com>
 <1366060483-20342-4-git-send-email-tomasz.figa@gmail.com>
 <20130416162750.GO26958@opensource.wolfsonmicro.com>
Message-ID: <22399020.Z89v9QS8su@flatron>

On Tuesday 16 of April 2013 17:27:50 Mark Brown wrote:
> On Mon, Apr 15, 2013 at 11:14:40PM +0200, Tomasz Figa wrote:
> >  		{ .compatible = "samsung,exynos4x12-pinctrl", },
> >  		{ .compatible = "samsung,exynos5250-pinctrl", },
> >  		{ .compatible = "samsung,exynos5440-pinctrl", },
> > 
> > +		{ },
> 
> Strictly speaking this is a separate bug fix (though I see that's
> already in -next separately anyway so whatever).

Right. But this fix is so small that I thought it would be a major waste 
of mail server processing power to send it as a separate patch.

Best regards,
Tomasz



From daniel.lezcano at linaro.org  Tue Apr 16 18:39:12 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Wed, 17 Apr 2013 00:39:12 +0200
Subject: [RFC patch 2/2] ARM: at91: cpuidle: move the driver to
 drivers/cpuidle directory
In-Reply-To: <20130415160041.GF15139@game.jcrosoft.org>
References: <1366032598-23053-1-git-send-email-daniel.lezcano@linaro.org>
 <1366032598-23053-3-git-send-email-daniel.lezcano@linaro.org>
 <20130415142047.GE15139@game.jcrosoft.org> <516C10C5.4050107@linaro.org>
 <20130415160041.GF15139@game.jcrosoft.org>
Message-ID: <516DD310.6030006@linaro.org>

On 04/15/2013 06:00 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 16:37 Mon 15 Apr     , Daniel Lezcano wrote:
>> On 04/15/2013 04:20 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
>>> On 15:29 Mon 15 Apr     , Daniel Lezcano wrote:
>>>> We don't have any dependency with the SoC specific code.
>>>>
>>>> Move the driver to the drivers/cpuidle directory.
>>>>
>>>> Add Nicolas Ferre as author of the driver, so it will be in copy of the emails.
>>>>
>>>> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
>>> please use -M when generating the patch
>>
>> Oh, right. Thanks for reminding me the option.
>>
>> [ ... ]
>>
>>>> +#include <linux/module.h>
>>>> +#include <linux/init.h>
>>>> +#include <linux/cpuidle.h>
>>>> +#include <asm/cpuidle.h>
>>>> +
>>>> +#define AT91_MAX_STATES	2
>>>> +
>>>> +extern void (*at91_standby_ops)(void);
>>> really don't like can we pass it via the pm?
>>
>> I agree, it is hackish. Can you elaborate when you say "pass it via the
>> pm" ?
> 
> I was thinking about it
> 
> I would even prefer to have a platfrom driver that pass it via platform data
> even in DT
> 
> but not something that can touch globally
> 
> and for drivers I prefer to do not use cpu_is only for the core

Is the following code what you had in mind ?

Please, be lenient, it is the first time I write something based on
'platform' :)


Index: cpuidle-next/arch/arm/mach-at91/cpuidle.c
===================================================================
--- cpuidle-next.orig/arch/arm/mach-at91/cpuidle.c      2013-04-16
10:40:21.058315042 +0200
+++ cpuidle-next/arch/arm/mach-at91/cpuidle.c   2013-04-17
00:35:42.836314931 +0200
@@ -13,32 +13,22 @@
  * #2 wait-for-interrupt and RAM self refresh
  */

-#include <linux/kernel.h>
+#include <linux/module.h>
 #include <linux/init.h>
-#include <linux/platform_device.h>
 #include <linux/cpuidle.h>
-#include <linux/io.h>
-#include <linux/export.h>
-#include <asm/proc-fns.h>
+#include <linux/platform_device.h>
 #include <asm/cpuidle.h>
-#include <mach/cpu.h>
-
-#include "pm.h"

 #define AT91_MAX_STATES        2

+static void (*at91_standby_ops)(void);
+
 /* Actual code that puts the SoC in different idle states */
 static int at91_enter_idle(struct cpuidle_device *dev,
                        struct cpuidle_driver *drv,
                               int index)
 {
-       if (cpu_is_at91rm9200())
-               at91rm9200_standby();
-       else if (cpu_is_at91sam9g45())
-               at91sam9g45_standby();
-       else
-               at91sam9_standby();
-
+       at91_standby_ops();
        return index;
 }

@@ -58,9 +48,16 @@ static struct cpuidle_driver at91_idle_d
 };

 /* Initialize CPU idle by registering the idle states */
-static int __init at91_init_cpuidle(void)
+int __init at91_init_cpuidle(struct platform_device *pdev)
 {
-       return cpuidle_register(&at91_idle_driver, NULL);
+       at91_standby_ops = pdata;
+       return 0;
 }

-device_initcall(at91_init_cpuidle);
+static int __init at91_cpuidle_init(void)
+{
+
+
+       return cpuidle_register(&at91_idle_driver, NULL);
+}
+device_initcall(at91_cpuidle_init);
Index: cpuidle-next/arch/arm/mach-at91/pm.c
===================================================================
--- cpuidle-next.orig/arch/arm/mach-at91/pm.c   2013-04-16
09:52:33.048426618 +0200
+++ cpuidle-next/arch/arm/mach-at91/pm.c        2013-04-16
18:22:03.207420375 +0200
@@ -312,21 +312,40 @@ static const struct platform_suspend_ops
        .end    = at91_pm_end,
 };

-static int __init at91_pm_init(void)
+static int __init at91_pm_probe(struct platform_device *pdev)
 {
-#ifdef CONFIG_AT91_SLOW_CLOCK
-       slow_clock = (void *) (AT91_IO_VIRT_BASE - at91_slow_clock_sz);
-#endif
-
-       pr_info("AT91: Power Management%s\n", (slow_clock ? " (with slow
clock mode)" : ""));
-
        /* AT91RM9200 SDRAM low-power mode cannot be used with
self-refresh. */
-       if (cpu_is_at91rm9200())
+       if (of_machine_is_compatible("atmel,at91rm9200")) {
                at91_ramc_write(0, AT91RM9200_SDRAMC_LPR, 0);
+               pdev->dev.platform_data = at91rm9200_standby;
+       } else if (of_machine_is_compatible("atmel,atmel,at91sam9g45")) {
+               pdev->dev.platform_data = at91sam9g45_standby;
+       } else {
+               pdev->dev.platform_data = at91sam9_standby;
+       }

        suspend_set_ops(&at91_pm_ops);

        show_reset_status();
+
        return 0;
 }
+
+static struct platform_driver at91_pm_driver = {
+       .driver = {
+               .name    = "pm-at91",
+               .owner   = THIS_MODULE,
+       },
+};
+
+static int __init at91_pm_init(void)
+{
+#ifdef CONFIG_AT91_SLOW_CLOCK
+       slow_clock = (void *) (AT91_IO_VIRT_BASE - at91_slow_clock_sz);
+#endif
+       pr_info("AT91: Power Management%s\n",
+               (slow_clock ? " (with slow clock mode)" : ""));
+
+       return platform_driver_probe(&at91_pm_driver, at91_pm_probe);
+}
 arch_initcall(at91_pm_init);
Index: cpuidle-next/arch/arm/mach-at91/board-usb-a926x.c
===================================================================
--- cpuidle-next.orig/arch/arm/mach-at91/board-usb-a926x.c
2013-04-15 10:31:45.503051053 +0200
+++ cpuidle-next/arch/arm/mach-at91/board-usb-a926x.c   2013-04-17
00:35:38.480314758 +0200
@@ -49,7 +49,6 @@
 #include "sam9_smc.h"
 #include "generic.h"

-
 static void __init ek_init_early(void)
 {
        /* Initialize processor: 12.00 MHz crystal */
@@ -319,6 +318,19 @@ static void __init ek_add_device_leds(vo
        at91_gpio_leds(ek_leds, ARRAY_SIZE(ek_leds));
 }

+#ifdef CONFIG_PM
+static struct platform_device at91_pm_device = {
+       .name = "pm-at91",
+       .id = -1,
+};
+#endif
+
+static struct platform_device *platform_devices[] __initdata = {
+#ifdef CONFIG_PM
+       &at91_pm_device,
+#endif
+}
+
 static void __init ek_board_init(void)
 {
        /* Serial */
@@ -351,6 +363,9 @@ static void __init ek_board_init(void)
                                | AT91_SHDW_WKMODE0_LOW
                                | AT91_SHDW_RTTWKEN);
        }
+
+       /* Platform devices */
+       platform_add_devices(&platform_devices,
ARRAY_SIZE(platform_devices));
 }

 MACHINE_START(USB_A9263, "CALAO USB_A9263")


if (of_machine_is_compatible("atmel,at91rm9200")) {
	printk("at91rm9200\n");
} else if (of_machine_is_compatible("atmel,atmel,at91sam9g45")) {
	printk(at91sam9g45\n");
} else {
	printk(other at91 cpu\n");
}

> 
> Best Regards,
> J.
>>
>>
>>
>> -- 
>>  <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs
>>
>> Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
>> <http://twitter.com/#!/linaroorg> Twitter |
>> <http://www.linaro.org/linaro-blog/> Blog
>>


-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From tomasz.figa at gmail.com  Tue Apr 16 18:43:56 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Wed, 17 Apr 2013 00:43:56 +0200
Subject: [PATCH v6 2/6] ARM: s3c64xx: Skip legacy EINT setup if
 pinctrl-s3c64xx driver is present
In-Reply-To: <20130416162642.GN26958@opensource.wolfsonmicro.com>
References: <1366060483-20342-1-git-send-email-tomasz.figa@gmail.com>
 <1366060483-20342-3-git-send-email-tomasz.figa@gmail.com>
 <20130416162642.GN26958@opensource.wolfsonmicro.com>
Message-ID: <5007310.KGcYpvCKGp@flatron>

The new pinctrl-s3c64xx is responsible for EINT handling on DT-enabled
platforms.

Signed-off-by: Tomasz Figa <tomasz.figa at gmail.com>
---
 arch/arm/mach-s3c64xx/common.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/mach-s3c64xx/common.c b/arch/arm/mach-s3c64xx/common.c
index e79ca92..5053879 100644
--- a/arch/arm/mach-s3c64xx/common.c
+++ b/arch/arm/mach-s3c64xx/common.c
@@ -366,6 +366,10 @@ static int __init s3c64xx_init_irq_eint(void)
 {
 	int irq;
 
+	/* On DT-enabled systems EINTs are handled by pinctrl-s3c64xx driver. */
+	if (of_have_populated_dt())
+		return -ENODEV;
+
 	for (irq = IRQ_EINT(0); irq <= IRQ_EINT(27); irq++) {
 		irq_set_chip_and_handler(irq, &s3c_irq_eint, handle_level_irq);
 		irq_set_chip_data(irq, (void *)eint_irq_to_bit(irq));
-- 
1.8.1.5




From sergei.shtylyov at cogentembedded.com  Tue Apr 16 19:03:45 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Wed, 17 Apr 2013 03:03:45 +0400
Subject: [PATCH] ARM: shmobile: BOCK-W: enable CONFIG_PM_RUNTIME in defconfig
Message-ID: <201304170303.46193.sergei.shtylyov@cogentembedded.com>

From: Vladimir Barinov <vladimir.barinov at cogentembedded.com>

Enable CONFIG_PM_RUNTIME in 'bockw_defconfig' -- it's already used by TMU, SCI,
I2C, and Ether drivers to control the clocks...

Signed-off-by: Vladimir Barinov <vladimir.barinov at cogentembedded.com>
Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

---
The patch is atop of Simon's 'renesas.git' tree, 'renesas-next-20130416' tag.

 arch/arm/configs/bockw_defconfig |    1 +
 1 file changed, 1 insertion(+)

Index: renesas/arch/arm/configs/bockw_defconfig
===================================================================
--- renesas.orig/arch/arm/configs/bockw_defconfig
+++ renesas/arch/arm/configs/bockw_defconfig
@@ -31,6 +31,7 @@ CONFIG_CMDLINE="console=ttySC0,115200 ig
 CONFIG_CMDLINE_FORCE=y
 # CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
 # CONFIG_SUSPEND is not set
+CONFIG_PM_RUNTIME=y
 CONFIG_NET=y
 CONFIG_UNIX=y
 CONFIG_INET=y


From cdall at cs.columbia.edu  Tue Apr 16 19:13:33 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Tue, 16 Apr 2013 16:13:33 -0700
Subject: [PATCH] ARM: KVM: iterate over all CPUs for CPU compatibility
 check
In-Reply-To: <CAJRNFKJ4ayqup6kSTg_1jeU0cBen1sYoBXLsEzZujndiZ-kE6w@mail.gmail.com>
References: <1365771875-5788-1-git-send-email-andre.przywara@linaro.org>
 <51680AF9.7040109@arm.com>
 <CAEDV+g+E8PLc60vMRhq4O_AL2WjmYDLb6=Wh34ynhevh7uAGJA@mail.gmail.com>
 <d455f2823b9639af8d38d30f2c3234bd@localhost>
 <CAEDV+gJuFG49oQ=BEaCHcTP=nHVyX8ALw6076dR_C1s7TuyqXQ@mail.gmail.com>
 <d47697abd39a0d5d41f5ac110a40e261@localhost>
 <CAEDV+gK9==sXYxRVZ8JVFYPiw3_xgzZBbydEwPunmnocNLKXrQ@mail.gmail.com>
 <CAFEAcA-bPoa8YoPuHPmupzfUW+yR233XquK79eNorzcRpFiK=g@mail.gmail.com>
 <516BCAD0.9000708@linaro.org>
 <CAJRNFKJoBzgt4UhxsH65_LyhcGXPnzB_pg3q-zeYT2OVv59q4A@mail.gmail.com>
 <CAEDV+g+8iE2_8Z6q7NYRPwKNDDBd8MnEEmB8KjrWwvUdSaxXmg@mail.gmail.com>
 <CAJRNFKJ4ayqup6kSTg_1jeU0cBen1sYoBXLsEzZujndiZ-kE6w@mail.gmail.com>
Message-ID: <CAEDV+gJML5dL+7L5UhTxrqoJvungK51=on6hZsHa55DtQT=niA@mail.gmail.com>

On Tue, Apr 16, 2013 at 11:37 AM, Alexander Spyridakis
<a.spyridakis at virtualopensystems.com> wrote:
> On 16 April 2013 17:59, Christoffer Dall <cdall at cs.columbia.edu> wrote:
>> On Mon, Apr 15, 2013 at 2:52 AM, Alexander Spyridakis
>> <a.spyridakis at virtualopensystems.com> wrote:
>>> I've run on this problem before, while trying to run KVM guests on A7 cores.
>>>
>>> For some reason the 3rd A7 hangs in arch/arm/kvm/init.S, on the instruction
>>> that updates HSCTLR between the two isbs on __do_hyp_init (mcr p15, 4, r0,
>>> c1, c0, 0). If you boot the system with maxcpus=4 then init_hyp_mode() will
>>> not hang on the A7 cluster. Other than that from my limited testing KVM on
>>> A7 works on a usual linux guest. I also tried to only boot the 3rd A7 core
>>> to rule out any racing issues, but still the same behaviour applies.
>>>
>> You lost me on the maxcpus=4 and racing point here. If it works with
>> maxcpus=4 then it works with two A7s, right? Why would running with
>> maxcpus=3 (ie. one A7) rule out any race condition?
>
> maxcpus=3 would still work (only one A7), but I didn't test it that
> way. To make sure and avoid any race conditions from other cpus, I
> changed the bootwrapper to explicitly boot only the 3rd A7 (rest of
> the cpus being in an infinite loop) and it would still hang. Booting
> only the 1st or 2nd A7 core by the same method would work as expected
> (no hang in __do_hyp_init_).
>
so work as expected, as in it doesn't work... Hence the confusion.

I don't think this is racy in any way, but for the record, you still
have a couple of other A15s running here, so you can't completely rule
out races based on your experimental approach, but I really don't
think that's the issue anyhow.


From jon-hunter at ti.com  Tue Apr 16 19:14:21 2013
From: jon-hunter at ti.com (Jon Hunter)
Date: Tue, 16 Apr 2013 18:14:21 -0500
Subject: [PATCH 3/5] gpio/omap: Add DT support to GPIO driver
In-Reply-To: <516DCCA8.3070108@wwwdotorg.org>
References: <1329321854-24490-1-git-send-email-b-cousson@ti.com>
 <514C79E1.4090106@wwwdotorg.org> <514CE0AB.6060207@ti.com>
 <CACRpkdZmv-rAoKSQYpkHHSMzKJOn5TixVW_P3=m7ZNagBYCUPw@mail.gmail.com>
 <515319D5.20105@wwwdotorg.org>
 <CACRpkdYXVLgCz1Tyu-Ls2V2OTc4R3cGNJhfQJB6Hiz_K9dkZYQ@mail.gmail.com>
 <5155C902.7080207@wwwdotorg.org>
 <CACRpkdYbs4-uudpRUY8e+7icYYkZrfM0kReP3pLL5DMiURJ4dg@mail.gmail.com>
 <5165CB9D.1090202@wwwdotorg.org>
 <CACRpkdYirFNqmGhA4K9CL4ve4NYhs8Rd3SFt1iwW9vHBkrcz8g@mail.gmail.com>
 <51671D7B.5060303@wwwdotorg.org>
 <CACRpkdbf32Ef77GmXk9id9+RRjcDRTr7S+F4nznoeZU8y=BT_Q@mail.gmail.com>
 <51673D70.3010503@wwwdotorg.org>
 <CAAwP0s0e2x33jZQhFRY+Hoo61SFqYKRgWk=1mL2+DNxSDJHz+A@mail.gmail.com>
 <CACRpkda4h+qXTvsirPAS7E7sjXhMLE62q=VDy53W8UchsYjbNg@mail.gmail.com>
 <516C31C3.9040505@wwwdotorg.org> <516C73C6.5050409@ti.co m>
 <516C7C43.3040105@wwwdotorg.org> <516C8760.2050500@ti.com>
 <516D9B05.1000501@wwwdotorg.org> <516DA60A.5070000@ti.com>
 <516DCCA8.3070108@wwwdotorg.org>
Message-ID: <516DDB4D.9020500@ti.com>


On 04/16/2013 05:11 PM, Stephen Warren wrote:
> On 04/16/2013 01:27 PM, Jon Hunter wrote:
>>
>> On 04/16/2013 01:40 PM, Stephen Warren wrote:
>>> On 04/15/2013 05:04 PM, Jon Hunter wrote:
> ...
>>>> If some driver is calling gpio_request() directly, then they will most
>>>> likely just call gpio_to_irq() when requesting the interrupt and so the
>>>> xlate function would not be called in this case (mmc drivers are a good
>>>> example). So I don't see that as being a problem. In fact that's the
>>>> benefit of this approach as AFAICT it solves this problem.
>>>
>>> Oh. That assumption seems very fragile. What about drivers that actually
>>> do have platform data (or DT bindings) that provide both the IRQ and
>>> GPIO IDs, and hence don't use gpio_to_irq()? That's entirely possible.
>>
>> Right. In the DT case though, if someone does provide the IRQ and GPIO
>> IDs then at least they would use a different xlate function. Another
>> option to consider would be defining the #interrupt-cells = <3> where we
>> would have ...
>>
>> cell-#1 --> IRQ domain ID
>> cell-#2 --> Trigger type
>> cell-#3 --> GPIO ID
>>
>> Then we could have a generic xlate for 3 cells that would also request
>> the GPIO. Again not sure if people are against a gpio being requested in
>> the xlate but just an idea. Or given that irq_of_parse_and_map() calls
>> the xlate, we could have this function call gpio_request() if the
>> interrupt controller is a gpio and there are 3 cells.
> 
> I rather dislike this approach since:
>
> a) It requires changes to the DT bindings, which are already defined.
> Admittedly it's backwards-compatible, but still.
> 
> b) There isn't really any need for the DT to represent this; the
> GPIO+IRQ driver itself already knows which IRQ ID is which GPIO ID and
> vice-versa (if the HW has such a concept), so there's no need for the DT
> to contain this information. This seems like pushing Linux's internal
> requirements into the design of the DT binding.

Yes, so the only alternative is to use irq_to_gpio to avoid this.

> c) I have the feeling that hooking the of_xlate function for this is a
> bit of an abuse of the function.

I was wondering about that. So I was grep'ing through the various xlate
implementations and found this [1]. Also you may recall that in the
of_dma_simple_xlate() we call the dma_request_channel() to allocate the
channel, which is very similar. However, I don't wish to get a
reputation as abusing APIs so would be good to know if this really is
abuse or not ;-)

Cheers
Jon

[1] http://permalink.gmane.org/gmane.linux.ports.arm.kernel/195124


From sfr at canb.auug.org.au  Tue Apr 16 20:02:33 2013
From: sfr at canb.auug.org.au (Stephen Rothwell)
Date: Wed, 17 Apr 2013 10:02:33 +1000
Subject: adding rpmsg.git to linux next
In-Reply-To: <CAK=WgbbVP+3eugev8szRBCV84uZLdKP6QXAH_Fr89SXDs-V5GQ@mail.gmail.com>
References: <CAK=WgbY=4rosYr2g3fYYk6WrqXjN7f=5Dk5+D-h3cWrOtVmNag@mail.gmail.com>
 <20130416100715.cd726b96944237ef975ebe7d@canb.auug.org.au>
 <CAK=WgbbVP+3eugev8szRBCV84uZLdKP6QXAH_Fr89SXDs-V5GQ@mail.gmail.com>
Message-ID: <20130417100233.a31e740ec21c96150fde0d81@canb.auug.org.au>

Hi Ohad,

On Tue, 16 Apr 2013 20:51:13 +0300 Ohad Ben-Cohen <ohad at wizery.com> wrote:
>
> On Tue, Apr 16, 2013 at 3:07 AM, Stephen Rothwell <sfr at canb.auug.org.au> wrote:
> > On Mon, 15 Apr 2013 09:28:17 +0300 Ohad Ben-Cohen <ohad at wizery.com> wrote:
> >> Could you please add:
> >>
> >> git://git.kernel.org/pub/scm/linux/kernel/git/ohad/rpmsg.git#for-next
> >>
> >> to linux-next to include new stuff coming from Rob?
> >
> > Well, you could tell me something about it.  Like what is in it and how
> > it will be merged up to Linus.  Does this have anything to do with the
> > remoteproc tree I already include?  Who is the official maintainer (there
> > is no mention of drivers/rpmsg in the MAINTAINERS file).
> 
> Sorry for not mentioning this.
> 
> This tree isn't new and is being used to send pull requests to Linus
> for some time. I guess that most (all?) of the pull requests contained
> fixes which needed no linux-next presence, so it never occurred to me
> the tree isn't part of linux-next.

All good, thanks for the explanation.  I have added that tree from today.

> commit d8115db52b99eefb99bcbf992edc349e691b4ca7
> Author: Ohad Ben-Cohen <ohad at wizery.com>
> Date:   Tue Apr 16 20:34:49 2013 +0300
> 
>     MAINTAINERS: add rpmsg entry
> 
>     People and scripts look for this.
> 
>     Signed-off-by: Ohad Ben-Cohen <ohad at wizery.com>

Good idea.

Thanks for adding your subsystem tree as a participant of linux-next.  As
you may know, this is not a judgment of your code.  The purpose of
linux-next is for integration testing and to lower the impact of
conflicts between subsystems in the next merge window. 

You will need to ensure that the patches/commits in your tree/series have
been:
     * submitted under GPL v2 (or later) and include the Contributor's
	Signed-off-by,
     * posted to the relevant mailing list,
     * reviewed by you (or another maintainer of your subsystem tree),
     * successfully unit tested, and 
     * destined for the current or next Linux merge window.

Basically, this should be just what you would send to Linus (or ask him
to fetch).  It is allowed to be rebased if you deem it necessary.

-- 
Cheers,
Stephen Rothwell 
sfr at canb.auug.org.au

Legal Stuff:
By participating in linux-next, your subsystem tree contributions are
public and will be included in the linux-next trees.  You may be sent
e-mail messages indicating errors or other issues when the
patches/commits from your subsystem tree are merged and tested in
linux-next.  These messages may also be cross-posted to the linux-next
mailing list, the linux-kernel mailing list, etc.  The linux-next tree
project and IBM (my employer) make no warranties regarding the linux-next
project, the testing procedures, the results, the e-mails, etc.  If you
don't agree to these ground rules, let me know and I'll remove your tree
from participation in linux-next.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130417/6b35f1b5/attachment.sig>

From shawn.guo at linaro.org  Tue Apr 16 20:13:02 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Wed, 17 Apr 2013 08:13:02 +0800
Subject: [PATCH] ARM i.MX53: dts: add i2c aliases
In-Reply-To: <1365527927-20618-1-git-send-email-p.zabel@pengutronix.de>
References: <1365527927-20618-1-git-send-email-p.zabel@pengutronix.de>
Message-ID: <20130417001300.GG11245@S2101-09.ap.freescale.net>

On Tue, Apr 09, 2013 at 07:18:47PM +0200, Philipp Zabel wrote:
> This allows to order the i2c character devices correctly,
> so that /dev/i2c-0 corresponds to i2c1, /dev/i2c-1 corresponds
> to i2c2, and so on. Currently they are ordered by register
> address.
> 
> Signed-off-by: Philipp Zabel <p.zabel at pengutronix.de>

Applied, thanks.

> ---
>  arch/arm/boot/dts/imx53.dtsi | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/imx53.dtsi b/arch/arm/boot/dts/imx53.dtsi
> index 845982e..7b9a391 100644
> --- a/arch/arm/boot/dts/imx53.dtsi
> +++ b/arch/arm/boot/dts/imx53.dtsi
> @@ -27,6 +27,9 @@
>  		gpio4 = &gpio5;
>  		gpio5 = &gpio6;
>  		gpio6 = &gpio7;
> +		i2c0 = &i2c1;
> +		i2c1 = &i2c2;
> +		i2c2 = &i2c3;
>  	};
>  
>  	tzic: tz-interrupt-controller at 0fffc000 {
> -- 
> 1.8.2.rc2
> 



From sboyd at codeaurora.org  Tue Apr 16 20:27:20 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Tue, 16 Apr 2013 17:27:20 -0700
Subject: [GIT PULL] Timer clean-ups for 3.10, Part 2
In-Reply-To: <516720B4.3000703@gmail.com>
References: <516720B4.3000703@gmail.com>
Message-ID: <516DEC68.8030101@codeaurora.org>

On 04/11/13 13:44, Rob Herring wrote:
>
> Rob Herring (13):
>       ARM: sched_clock: allow changing to higher frequency counter
>       ARM: make sched_clock just call a function pointer
>       ARM: arch_timer: use full 64-bit counter for sched_clock

If I leave my system in the bootloader for a while this seems to cause
my sched_clock timestamps to jump once the sched_clock is setup. It also
sets up a sched_clock twice because read_sched_clock ==
jiffy_sched_clock_read.

[    0.000000] Switching to timer-based delay loop
[    0.000000] sched_clock: ARM arch timer >56 bits at 19200kHz,
resolution 52ns
[    0.000000] sched_clock: 32 bits at 100 Hz, resolution 10000000ns,
wraps every 4294967286ms
[    0.000000] Console: colour dummy device 80x30
[16645.193054] Calibrating delay loop (skipped), value calculated using
timer frequency.. 38.40 BogoMIPS (lpj=192000)

I suspect it's because we don't do any cyc_to_sched_clock() stuff in the
arm architected timer case. Instead we just return the value from the
counter when we really should do some sort of subtraction from the first
value we read.

I'm also curious how this is going to work for suspend/resume because it
doesn't look like we're going to stop sched_clock on arm architected
timer systems. See 6a4dae5e138a3 (ARM: 7565/1: sched: stop sched_clock()
during suspend, 2012-10-23) for why we need to do this.

Finally, looks like this is unused now...

---8<----

diff --git a/arch/arm/kernel/sched_clock.c b/arch/arm/kernel/sched_clock.c
index 8805848..48ab64a 100644
--- a/arch/arm/kernel/sched_clock.c
+++ b/arch/arm/kernel/sched_clock.c
@@ -24,7 +24,6 @@ struct clock_data {
        u32 mult;
        u32 shift;
        bool suspended;
-       bool needs_suspend;
 };
 
 static void sched_clock_poll(unsigned long wrap_ticks);

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation



From martinez.javier at gmail.com  Tue Apr 16 20:41:02 2013
From: martinez.javier at gmail.com (Javier Martinez Canillas)
Date: Wed, 17 Apr 2013 02:41:02 +0200
Subject: [PATCH 3/5] gpio/omap: Add DT support to GPIO driver
In-Reply-To: <516DDB4D.9020500@ti.com>
References: <1329321854-24490-1-git-send-email-b-cousson@ti.com>
 <514C79E1.4090106@wwwdotorg.org> <514CE0AB.6060207@ti.com>
 <CACRpkdZmv-rAoKSQYpkHHSMzKJOn5TixVW_P3=m7ZNagBYCUPw@mail.gmail.com>
 <515319D5.20105@wwwdotorg.org>
 <CACRpkdYXVLgCz1Tyu-Ls2V2OTc4R3cGNJhfQJB6Hiz_K9dkZYQ@mail.gmail.com>
 <5155C902.7080207@wwwdotorg.org>
 <CACRpkdYbs4-uudpRUY8e+7icYYkZrfM0kReP3pLL5DMiURJ4dg@mail.gmail.com>
 <5165CB9D.1090202@wwwdotorg.org>
 <CACRpkdYirFNqmGhA4K9CL4ve4NYhs8Rd3SFt1iwW9vHBkrcz8g@mail.gmail.com>
 <51671D7B.5060303@wwwdotorg.org>
 <CACRpkdbf32Ef77GmXk9id9+RRjcDRTr7S+F4nznoeZU8y=BT_Q@mail.gmail.com>
 <51673D70.3010503@wwwdotorg.org>
 <CAAwP0s0e2x33jZQhFRY+Hoo61SFqYKRgWk=1mL2+DNxSDJHz+A@mail.gmail.com>
 <CACRpkda4h+qXTvsirPAS7E7sjXhMLE62q=VDy53W8UchsYjbNg@mail.gmail.com>
 <516C31C3.9040505@wwwdotorg.org> <516C7C43.3040105@wwwdotorg.org>
 <516C8760.2050500@ti.com> <516D9B05.1000501@wwwdotorg.org>
 <516DA60A.5070000@ti.com> <516DCCA8.3070108@wwwdotorg.org>
 <516DDB4D.9020500@ti.com>
Message-ID: <CAAwP0s0-VNUoeSKaGbvoDeD7m7kZRdp5rCJ7iVpFoFAaQtXcmQ@mail.gmail.com>

On Wed, Apr 17, 2013 at 1:14 AM, Jon Hunter <jon-hunter at ti.com> wrote:
>
> On 04/16/2013 05:11 PM, Stephen Warren wrote:
>> On 04/16/2013 01:27 PM, Jon Hunter wrote:
>>>
>>> On 04/16/2013 01:40 PM, Stephen Warren wrote:
>>>> On 04/15/2013 05:04 PM, Jon Hunter wrote:
>> ...
>>>>> If some driver is calling gpio_request() directly, then they will most
>>>>> likely just call gpio_to_irq() when requesting the interrupt and so the
>>>>> xlate function would not be called in this case (mmc drivers are a good
>>>>> example). So I don't see that as being a problem. In fact that's the
>>>>> benefit of this approach as AFAICT it solves this problem.
>>>>
>>>> Oh. That assumption seems very fragile. What about drivers that actually
>>>> do have platform data (or DT bindings) that provide both the IRQ and
>>>> GPIO IDs, and hence don't use gpio_to_irq()? That's entirely possible.
>>>
>>> Right. In the DT case though, if someone does provide the IRQ and GPIO
>>> IDs then at least they would use a different xlate function. Another
>>> option to consider would be defining the #interrupt-cells = <3> where we
>>> would have ...
>>>
>>> cell-#1 --> IRQ domain ID
>>> cell-#2 --> Trigger type
>>> cell-#3 --> GPIO ID
>>>
>>> Then we could have a generic xlate for 3 cells that would also request
>>> the GPIO. Again not sure if people are against a gpio being requested in
>>> the xlate but just an idea. Or given that irq_of_parse_and_map() calls
>>> the xlate, we could have this function call gpio_request() if the
>>> interrupt controller is a gpio and there are 3 cells.
>>
>> I rather dislike this approach since:
>>
>> a) It requires changes to the DT bindings, which are already defined.
>> Admittedly it's backwards-compatible, but still.
>>
>> b) There isn't really any need for the DT to represent this; the
>> GPIO+IRQ driver itself already knows which IRQ ID is which GPIO ID and
>> vice-versa (if the HW has such a concept), so there's no need for the DT
>> to contain this information. This seems like pushing Linux's internal
>> requirements into the design of the DT binding.
>
> Yes, so the only alternative is to use irq_to_gpio to avoid this.
>
>> c) I have the feeling that hooking the of_xlate function for this is a
>> bit of an abuse of the function.
>
> I was wondering about that. So I was grep'ing through the various xlate
> implementations and found this [1]. Also you may recall that in the
> of_dma_simple_xlate() we call the dma_request_channel() to allocate the
> channel, which is very similar. However, I don't wish to get a
> reputation as abusing APIs so would be good to know if this really is
> abuse or not ;-)
>
> Cheers
> Jon
>
> [1] http://permalink.gmane.org/gmane.linux.ports.arm.kernel/195124

I was looking at [1] shared by Jon and come up with the following
patch that does something similar for OMAP GPIO. This has the
advantage that is local to gpio-omap instead changing gpiolib-of and
also doesn't require DT changes

But I don't want to get a reputation for abusing APIs neither :-)

Best regards,
Javier

>From 23368eb72b125227fcf4b22be19ea70b4ab94556 Mon Sep 17 00:00:00 2001
From: Javier Martinez Canillas <javier.martinez at collabora.co.uk>
Date: Wed, 17 Apr 2013 02:03:08 +0200
Subject: [PATCH 1/1] gpio/omap: add custom xlate function handler

Signed-off-by: Javier Martinez Canillas <javier.martinez at collabora.co.uk>
---
 drivers/gpio/gpio-omap.c |   29 ++++++++++++++++++++++++++++-
 1 files changed, 28 insertions(+), 1 deletions(-)

diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 8524ce5..77216f9 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -1097,6 +1097,33 @@ static void omap_gpio_chip_init(struct gpio_bank *bank)
 static const struct of_device_id omap_gpio_match[];
 static void omap_gpio_init_context(struct gpio_bank *p);

+static int omap_gpio_irq_domain_xlate(struct irq_domain *d,
+				      struct device_node *ctrlr,
+				      const u32 *intspec, unsigned int intsize,
+				      irq_hw_number_t *out_hwirq,
+				      unsigned int *out_type)
+{
+	int ret;
+	struct gpio_bank *bank = d->host_data;
+	int gpio = bank->chip.base + intspec[0];
+
+	if (WARN_ON(intsize < 2))
+		return -EINVAL;
+
+	ret = gpio_request_one(gpio, GPIOF_IN, ctrlr->full_name);
+	if (ret)
+		return ret;
+
+	*out_hwirq = intspec[0];
+	*out_type = (intsize > 1) ? intspec[1] : IRQ_TYPE_NONE;
+
+	return 0;
+}
+
+static struct irq_domain_ops omap_gpio_irq_ops = {
+	.xlate	= omap_gpio_irq_domain_xlate,
+};
+
 static int omap_gpio_probe(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
@@ -1144,7 +1171,7 @@ static int omap_gpio_probe(struct platform_device *pdev)


 	bank->domain = irq_domain_add_linear(node, bank->width,
-					     &irq_domain_simple_ops, NULL);
+					     &omap_gpio_irq_ops, bank);
 	if (!bank->domain)
 		return -ENODEV;

-- 
1.7.7.6


From tony at atomide.com  Tue Apr 16 20:52:32 2013
From: tony at atomide.com (Tony Lindgren)
Date: Tue, 16 Apr 2013 17:52:32 -0700
Subject: [PATCH] ARM: dts: omap3-beagle-xm: Add USB Host support for
 Rev Ax/Bx
In-Reply-To: <516BF4F3.5060904@ti.com>
References: <1366029306-1824-1-git-send-email-rogerq@ti.com>
 <516BF4F3.5060904@ti.com>
Message-ID: <20130417005232.GV10155@atomide.com>

* Roger Quadros <rogerq at ti.com> [130415 05:44]:
> On 04/15/2013 03:35 PM, Roger Quadros wrote:
> > Provide RESET and Power regulators for the USB PHY,
> > the USB Host port mode and the PHY device.
> > 
> > Also provide pin multiplexer information for USB host
> > pins.
> > 
> > This will not work for Rev Cx boards because of reversed logic
> > for USB_POWER_Enable.
> > 
> > CC: Beno?t Cousson <b-cousson at ti.com>
> > Signed-off-by: Roger Quadros <rogerq at ti.com>
> > ---
> >  arch/arm/boot/dts/omap3-beagle-xm.dts |   62 +++++++++++++++++++++++++++++++++
> >  1 files changed, 62 insertions(+), 0 deletions(-)
> > 
> > diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts b/arch/arm/boot/dts/omap3-beagle-xm.dts
> > index 5a31964..d394c51 100644
> > --- a/arch/arm/boot/dts/omap3-beagle-xm.dts
> > +++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
> > @@ -57,6 +57,60 @@
> >  		ti,mcbsp = <&mcbsp2>;
> >  		ti,codec = <&twl_audio>;
> >  	};
> > +
> > +	/* HS USB Port 2 RESET */
> > +	hsusb2_reset: hsusb2_reset_reg {
> > +		compatible = "regulator-fixed";
> > +		regulator-name = "hsusb2_reset";
> > +		regulator-min-microvolt = <3300000>;
> > +		regulator-max-microvolt = <3300000>;
> > +		gpio = <&gpio5 19 0>;	/* gpio_147 */
> > +		startup-delay-us = <70000>;
> > +		enable-active-high;
> > +	};
> > +
> > +	/* HS USB Port 2 Power */
> > +	hsusb2_power: hsusb2_power_reg {
> > +		compatible = "regulator-fixed";
> > +		regulator-name = "hsusb2_vbus";
> > +		regulator-min-microvolt = <3300000>;
> > +		regulator-max-microvolt = <3300000>;
> > +		gpio = <&twl_gpio 18 0>;	/* GPIO LEDA */
> > +		startup-delay-us = <70000>;
> > +		enable-active-high;	/* FIXME: active-low for Rev. C */
> 
> Benoit & Tony,
> 
> Any ideas how to tackle the reversed logic for Rev. C boards?

Sounds like we need a shared omap3-beage.dtsi, then omap3-beagle-xm.dts
and omap3-beagle-rev-c.dts. Then xm and rev-c can both include the
common .dtsi.

Regards,

Tony


From kuninori.morimoto.gx at renesas.com  Tue Apr 16 21:14:42 2013
From: kuninori.morimoto.gx at renesas.com (Kuninori Morimoto)
Date: Tue, 16 Apr 2013 18:14:42 -0700 (PDT)
Subject: [PATCH v2 0/9] Reorganize R8A7779/Marzen USB code
In-Reply-To: <51689488.7040109@cogentembedded.com>
References: <201304090110.50154.sergei.shtylyov@cogentembedded.com>
 <87zjx89rfb.wl%kuninori.morimoto.gx@renesas.com>
 <51640D21.3090800@cogentembedded.com>
 <87txnfjhmu.wl%kuninori.morimoto.gx@renesas.com>
 <51689399.5090203@cogentembedded.com>
 <51689488.7040109@cogentembedded.com>
Message-ID: <87mwsydklg.wl%kuninori.morimoto.gx@renesas.com>


Hi Sergei

> >>>      I'm going to post R8A7778/BOCK-W series following this one, and 
> >>> all the
> >>> patches in 1st series should additionally be tested on BOCK-W. Well, I
> >>> probably can hold up posting version 3 until I have the second 
> >>> series verified.
> >>>      BTW, about R8A7778/BOCK-W, R-Car M1A user manual talks about a 
> >>> ferrite
> >>> bead in 49.4.1 (3) Setting USB-PHY. Do you know for sure if it's 
> >>> used or not
> >>> on BOCK-W board? PHY initialization seems to work with either 
> >>> settings...
> >> I can ask it to HW team if you want me.
> 
>     Yes, ask them please.

Now, I'm asking it to HW team
Please wait

Best regards
---
Kuninori Morimoto


From xiechao.mail at gmail.com  Tue Apr 16 21:22:36 2013
From: xiechao.mail at gmail.com (Chao Xie)
Date: Wed, 17 Apr 2013 09:22:36 +0800
Subject: [V9 PATCH 00/12] mv-usb phy driver
In-Reply-To: <CADApbeg4BSUubbTw8tC-fuQ06JrRtAW9+rOdg=3rP_0Dr=LwkQ@mail.gmail.com>
References: <1365330586-649-1-git-send-email-chao.xie@marvell.com>
 <CADApbeg4BSUubbTw8tC-fuQ06JrRtAW9+rOdg=3rP_0Dr=LwkQ@mail.gmail.com>
Message-ID: <CADApbeg33WqVqG1o9Dp34t_Riia5HNg4xhz+Tk3MDPoVwxb3Mg@mail.gmail.com>

On Wed, Apr 17, 2013 at 9:17 AM, Chao Xie <xiechao.mail at gmail.com> wrote:
>
> On Sun, Apr 7, 2013 at 6:29 PM, Chao Xie <chao.xie at marvell.com> wrote:
>>
>> The patches create the mv-usb phy driver
>>
>>
>>   directly use devm_usb_get_phy_dev return value for error return.
>>
>> v9->v8
>>   Remove u2o_xxx.
>>   Add prefix for register definition
>>   Move mutex to common PHY layer
>>   Use module_platform_driver() to register driver
>>   Use usleep_range to replace udelay
>>
>> Chao Xie (12):
>>   usb: phy: protect phy init and shutdown for mutiple deivces
>>   usb: phy: mv_usb2: add PHY driver for marvell usb2 controller
>>   usb: gadget: mv_udc: use PHY driver for udc
>>   usb: ehci: ehci-mv: use PHY driver for ehci
>>   usb: phy: phy-mv-usb: use USB2 PHY driver for otg
>>   usb: mv_u3d: usb phy drivers for phy operation
>>   arm: mmp2: change the defintion of usb devices
>>   arm: pxa910: change the defintion of usb devices
>>   arm: ttc_dkb: modify usb support
>>   arm: mmp: remove unused usb devices
>>   arm: brownstone: add usb support for the board
>>   usb: mv_usb: remove the phy callbacks in pdata
>>
>>  arch/arm/mach-mmp/brownstone.c          |   56 +++++
>>  arch/arm/mach-mmp/include/mach/mmp2.h   |    4 +
>>  arch/arm/mach-mmp/include/mach/pxa910.h |    7 +-
>>  arch/arm/mach-mmp/mmp2.c                |    4 +
>>  arch/arm/mach-mmp/pxa910.c              |    4 +
>>  arch/arm/mach-mmp/ttc_dkb.c             |   39 +++-
>>  drivers/usb/gadget/mv_u3d.h             |    3 +-
>>  drivers/usb/gadget/mv_u3d_core.c        |   54 ++---
>>  drivers/usb/gadget/mv_udc.h             |    2 +-
>>  drivers/usb/gadget/mv_udc_core.c        |   50 ++---
>>  drivers/usb/host/ehci-mv.c              |   49 ++---
>>  drivers/usb/phy/Kconfig                 |    6 +
>>  drivers/usb/phy/Makefile                |    1 +
>>  drivers/usb/phy/phy-mv-usb.c            |   53 ++---
>>  drivers/usb/phy/phy-mv-usb.h            |    2 +-
>>  drivers/usb/phy/phy-mv-usb2.c           |  380
>> +++++++++++++++++++++++++++++++
>>  drivers/usb/phy/phy.c                   |    6 +
>>  include/linux/platform_data/mv_usb.h    |    3 -
>>  include/linux/usb/mv_usb2.h             |   29 +++
>>  include/linux/usb/phy.h                 |   22 ++-
>>  20 files changed, 624 insertions(+), 150 deletions(-)
>>  create mode 100644 drivers/usb/phy/phy-mv-usb2.c
>>  create mode 100644 include/linux/usb/mv_usb2.h
>>
>> --
>> 1.7.4.1
>>
>>
>
hi, balbi
You have given many valuable comments and suggestions for previous version.
So i modified the driver based on your review feedback. Can you help to
review the new version? Thanks.


From robertcnelson at gmail.com  Tue Apr 16 21:30:42 2013
From: robertcnelson at gmail.com (Robert Nelson)
Date: Tue, 16 Apr 2013 20:30:42 -0500
Subject: [PATCH] ARM: dts: omap3-beagle-xm: Add USB Host support for Rev
 Ax/Bx
In-Reply-To: <20130417005232.GV10155@atomide.com>
References: <1366029306-1824-1-git-send-email-rogerq@ti.com>
 <516BF4F3.5060904@ti.com> <20130417005232.GV10155@atomide.com>
Message-ID: <CAOCHtYgFnCy5Qn2LeJOK96_NdwzxzVe8Vrb8cL=K9AdzPUtQow@mail.gmail.com>

On Tue, Apr 16, 2013 at 7:52 PM, Tony Lindgren <tony at atomide.com> wrote:
> * Roger Quadros <rogerq at ti.com> [130415 05:44]:
>> On 04/15/2013 03:35 PM, Roger Quadros wrote:
>> > Provide RESET and Power regulators for the USB PHY,
>> > the USB Host port mode and the PHY device.
>> >
>> > Also provide pin multiplexer information for USB host
>> > pins.
>> >
>> > This will not work for Rev Cx boards because of reversed logic
>> > for USB_POWER_Enable.
>> >
>> > CC: Beno?t Cousson <b-cousson at ti.com>
>> > Signed-off-by: Roger Quadros <rogerq at ti.com>
>> > ---
>> >  arch/arm/boot/dts/omap3-beagle-xm.dts |   62 +++++++++++++++++++++++++++++++++
>> >  1 files changed, 62 insertions(+), 0 deletions(-)
>> >
>> > diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts b/arch/arm/boot/dts/omap3-beagle-xm.dts
>> > index 5a31964..d394c51 100644
>> > --- a/arch/arm/boot/dts/omap3-beagle-xm.dts
>> > +++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
>> > @@ -57,6 +57,60 @@
>> >             ti,mcbsp = <&mcbsp2>;
>> >             ti,codec = <&twl_audio>;
>> >     };
>> > +
>> > +   /* HS USB Port 2 RESET */
>> > +   hsusb2_reset: hsusb2_reset_reg {
>> > +           compatible = "regulator-fixed";
>> > +           regulator-name = "hsusb2_reset";
>> > +           regulator-min-microvolt = <3300000>;
>> > +           regulator-max-microvolt = <3300000>;
>> > +           gpio = <&gpio5 19 0>;   /* gpio_147 */
>> > +           startup-delay-us = <70000>;
>> > +           enable-active-high;
>> > +   };
>> > +
>> > +   /* HS USB Port 2 Power */
>> > +   hsusb2_power: hsusb2_power_reg {
>> > +           compatible = "regulator-fixed";
>> > +           regulator-name = "hsusb2_vbus";
>> > +           regulator-min-microvolt = <3300000>;
>> > +           regulator-max-microvolt = <3300000>;
>> > +           gpio = <&twl_gpio 18 0>;        /* GPIO LEDA */
>> > +           startup-delay-us = <70000>;
>> > +           enable-active-high;     /* FIXME: active-low for Rev. C */
>>
>> Benoit & Tony,
>>
>> Any ideas how to tackle the reversed logic for Rev. C boards?
>
> Sounds like we need a shared omap3-beage.dtsi, then omap3-beagle-xm.dts
> and omap3-beagle-rev-c.dts. Then xm and rev-c can both include the

Bike-sheding, but we might want to make that "omap3-beagle-xmc.dts" as
there is the "rev c" variant of the original beagle...

It's too bad we can't read the 3 gpio pin states in the device tree
and make a decision.

Regards,

-- 
Robert Nelson
http://www.rcn-ee.com/


From jon-hunter at ti.com  Tue Apr 16 22:00:15 2013
From: jon-hunter at ti.com (Jon Hunter)
Date: Tue, 16 Apr 2013 21:00:15 -0500
Subject: [PATCH 3/5] gpio/omap: Add DT support to GPIO driver
In-Reply-To: <CAAwP0s0-VNUoeSKaGbvoDeD7m7kZRdp5rCJ7iVpFoFAaQtXcmQ@mail.gmail.com>
References: <1329321854-24490-1-git-send-email-b-cousson@ti.com>
 <CACRpkdZmv-rAoKSQYpkHHSMzKJOn5TixVW_P3=m7ZNagBYCUPw@mail.gmail.com>
 <515319D5.20105@wwwdotorg.org>
 <CACRpkdYXVLgCz1Tyu-Ls2V2OTc4R3cGNJhfQJB6Hiz_K9dkZYQ@mail.gmail.com>
 <5155C902.7080207@wwwdotorg.org>
 <CACRpkdYbs4-uudpRUY8e+7icYYkZrfM0kReP3pLL5DMiURJ4dg@mail.gmail.com>
 <5165CB9D.1090202@wwwdotorg.org>
 <CACRpkdYirFNqmGhA4K9CL4ve4NYhs8Rd3SFt1iwW9vHBkrcz8g@mail.gmail.com>
 <51671D7B.5060303@wwwdotorg.org>
 <CACRpkdbf32Ef77GmXk9id9+RRjcDRTr7S+F4nznoeZU8y=BT_Q@mail.gmail.com>
 <51673D70.3010503@wwwdotorg.org>
 <CAAwP0s0e2x33jZQhFRY+Hoo61SFqYKRgWk=1mL2+DNxSDJHz+A@mail.gmail.com>
 <CACRpkda4h+qXTvsirPAS7E7sjXhMLE62q=VDy53W8UchsYjbNg@mail.gmail.com>
 <516C31C3.9040505@wwwdotorg.org> <516C7C43.3040105@wwwdotorg.org>
 <516C8760.2050500@ti.com> <516D9B05.1000501@wwwdotorg.org>
 <516DA60A.5070000@ti.com> <516DCCA8.3070108@wwwdotorg.org>
 <516DDB4D.9020500@ti.com>
 <CAAwP0s0-VNUoeSKaGbvoDeD7m7kZRdp5rCJ7iVpFoFAaQtXcmQ@mail.gmail.com>
Message-ID: <516E022F.5050708@ti.com>


On 04/16/2013 07:41 PM, Javier Martinez Canillas wrote:
> On Wed, Apr 17, 2013 at 1:14 AM, Jon Hunter <jon-hunter at ti.com> wrote:
>>
>> On 04/16/2013 05:11 PM, Stephen Warren wrote:
>>> On 04/16/2013 01:27 PM, Jon Hunter wrote:
>>>>
>>>> On 04/16/2013 01:40 PM, Stephen Warren wrote:
>>>>> On 04/15/2013 05:04 PM, Jon Hunter wrote:
>>> ...
>>>>>> If some driver is calling gpio_request() directly, then they will most
>>>>>> likely just call gpio_to_irq() when requesting the interrupt and so the
>>>>>> xlate function would not be called in this case (mmc drivers are a good
>>>>>> example). So I don't see that as being a problem. In fact that's the
>>>>>> benefit of this approach as AFAICT it solves this problem.
>>>>>
>>>>> Oh. That assumption seems very fragile. What about drivers that actually
>>>>> do have platform data (or DT bindings) that provide both the IRQ and
>>>>> GPIO IDs, and hence don't use gpio_to_irq()? That's entirely possible.
>>>>
>>>> Right. In the DT case though, if someone does provide the IRQ and GPIO
>>>> IDs then at least they would use a different xlate function. Another
>>>> option to consider would be defining the #interrupt-cells = <3> where we
>>>> would have ...
>>>>
>>>> cell-#1 --> IRQ domain ID
>>>> cell-#2 --> Trigger type
>>>> cell-#3 --> GPIO ID
>>>>
>>>> Then we could have a generic xlate for 3 cells that would also request
>>>> the GPIO. Again not sure if people are against a gpio being requested in
>>>> the xlate but just an idea. Or given that irq_of_parse_and_map() calls
>>>> the xlate, we could have this function call gpio_request() if the
>>>> interrupt controller is a gpio and there are 3 cells.
>>>
>>> I rather dislike this approach since:
>>>
>>> a) It requires changes to the DT bindings, which are already defined.
>>> Admittedly it's backwards-compatible, but still.
>>>
>>> b) There isn't really any need for the DT to represent this; the
>>> GPIO+IRQ driver itself already knows which IRQ ID is which GPIO ID and
>>> vice-versa (if the HW has such a concept), so there's no need for the DT
>>> to contain this information. This seems like pushing Linux's internal
>>> requirements into the design of the DT binding.
>>
>> Yes, so the only alternative is to use irq_to_gpio to avoid this.
>>
>>> c) I have the feeling that hooking the of_xlate function for this is a
>>> bit of an abuse of the function.
>>
>> I was wondering about that. So I was grep'ing through the various xlate
>> implementations and found this [1]. Also you may recall that in the
>> of_dma_simple_xlate() we call the dma_request_channel() to allocate the
>> channel, which is very similar. However, I don't wish to get a
>> reputation as abusing APIs so would be good to know if this really is
>> abuse or not ;-)
>>
>> Cheers
>> Jon
>>
>> [1] http://permalink.gmane.org/gmane.linux.ports.arm.kernel/195124
> 
> I was looking at [1] shared by Jon and come up with the following
> patch that does something similar for OMAP GPIO. This has the
> advantage that is local to gpio-omap instead changing gpiolib-of and
> also doesn't require DT changes
> 
> But I don't want to get a reputation for abusing APIs neither :-)
> 
> Best regards,
> Javier
> 
> From 23368eb72b125227fcf4b22be19ea70b4ab94556 Mon Sep 17 00:00:00 2001
> From: Javier Martinez Canillas <javier.martinez at collabora.co.uk>
> Date: Wed, 17 Apr 2013 02:03:08 +0200
> Subject: [PATCH 1/1] gpio/omap: add custom xlate function handler
> 
> Signed-off-by: Javier Martinez Canillas <javier.martinez at collabora.co.uk>
> ---
>  drivers/gpio/gpio-omap.c |   29 ++++++++++++++++++++++++++++-
>  1 files changed, 28 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
> index 8524ce5..77216f9 100644
> --- a/drivers/gpio/gpio-omap.c
> +++ b/drivers/gpio/gpio-omap.c
> @@ -1097,6 +1097,33 @@ static void omap_gpio_chip_init(struct gpio_bank *bank)
>  static const struct of_device_id omap_gpio_match[];
>  static void omap_gpio_init_context(struct gpio_bank *p);
> 
> +static int omap_gpio_irq_domain_xlate(struct irq_domain *d,
> +				      struct device_node *ctrlr,
> +				      const u32 *intspec, unsigned int intsize,
> +				      irq_hw_number_t *out_hwirq,
> +				      unsigned int *out_type)
> +{
> +	int ret;
> +	struct gpio_bank *bank = d->host_data;
> +	int gpio = bank->chip.base + intspec[0];
> +
> +	if (WARN_ON(intsize < 2))
> +		return -EINVAL;
> +
> +	ret = gpio_request_one(gpio, GPIOF_IN, ctrlr->full_name);
> +	if (ret)
> +		return ret;
> +
> +	*out_hwirq = intspec[0];
> +	*out_type = (intsize > 1) ? intspec[1] : IRQ_TYPE_NONE;
> +
> +	return 0;
> +}
> +
> +static struct irq_domain_ops omap_gpio_irq_ops = {
> +	.xlate	= omap_gpio_irq_domain_xlate,
> +};
> +
>  static int omap_gpio_probe(struct platform_device *pdev)
>  {
>  	struct device *dev = &pdev->dev;
> @@ -1144,7 +1171,7 @@ static int omap_gpio_probe(struct platform_device *pdev)
> 
> 
>  	bank->domain = irq_domain_add_linear(node, bank->width,
> -					     &irq_domain_simple_ops, NULL);
> +					     &omap_gpio_irq_ops, bank);
>  	if (!bank->domain)
>  		return -ENODEV;
> 

That would work for omap, in fact I posted pretty much the same thing a
day ago [1] ;-)

I was trying to see if we could find a common solution that everyone
could use as it seems that ideally we should all be requesting the gpio.

Cheers
Jon

[1] http://marc.info/?l=linux-arm-kernel&m=136606204823845&w=1


From horms at verge.net.au  Tue Apr 16 22:15:55 2013
From: horms at verge.net.au (Simon Horman)
Date: Wed, 17 Apr 2013 11:15:55 +0900
Subject: [PATCH v4 7/7] ARM: mach-shmobile: r8a7740: Setup the timer
 CMT10 using DT
In-Reply-To: <20130415035805.GE3070@verge.net.au>
References: <1365679443-25456-1-git-send-email-hechtb+renesas@gmail.com>
 <1365679443-25456-7-git-send-email-hechtb+renesas@gmail.com>
 <20130412012350.GA25941@verge.net.au>
 <CABYn4szS=dLwQbnWe4rY==yomeefoLc7NNCR+KfM8pO3L5ihmQ@mail.gmail.com>
 <20130415035805.GE3070@verge.net.au>
Message-ID: <20130417021553.GF16092@verge.net.au>

On Mon, Apr 15, 2013 at 12:58:05PM +0900, Simon Horman wrote:
> On Fri, Apr 12, 2013 at 02:46:15PM +0200, Bastian Hecht wrote:
> > Hello Simon,
> > 
> > 2013/4/12 Simon Horman <horms at verge.net.au>:
> > > On Thu, Apr 11, 2013 at 01:24:03PM +0200, Bastian Hecht wrote:
> > >> We can now use the Device Tree for bringing up our timer device CMT10 on
> > >> the SoC r8a7740.
> > >
> > > Hi Bastian,
> > >
> > > unfortunately with this patch the armaillo800eva no longer boots.
> > >
> > > I am testing  against renesas-next-20130411v2 with the other
> > > 6 patches in this series applied. I am using the armadillo800eva defconfig.
> > > The boot log is below.
> > 
> > Ouch, sorry! I checked the patches and somehow I missed a chunk in
> > 0007-... when I rebased the series to next. The part that actually
> > adds the DT info to r8a7740.dtsi. Further we need the GIC to be
> > present in the DT to make things work here (my old patch used the
> > INTCA as interrupt controller reference, but that has gone in the
> > meantime).
> > I want to repost my A1 reference code soon and in there I add the way
> > to set up the GIC via DT.
> > 
> > To accelerate things maybe we take 0001-0006 now and postpone 0007
> > until the GIC is in the DT?
> > I diffed the new patches against the v3 series, and the .dtsi chunk is
> > the only one that didn't make it, so I strongly believe the series is
> > fine now.
> 
> Ok, thanks. I'll see about queuing-up 0001-0006 and you can repost
> 0007 at a later date.

I have queued-up 0001-0006.


From shawn.guo at linaro.org  Tue Apr 16 23:15:15 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Wed, 17 Apr 2013 11:15:15 +0800
Subject: iMX28 DTS GPIO IRQ Definition
In-Reply-To: <CAGUvELcRFK9vjx3t69ccEfjLanPSnpZmSo83fxQN0yWvbjTX7w@mail.gmail.com>
References: <CAGUvELcRFK9vjx3t69ccEfjLanPSnpZmSo83fxQN0yWvbjTX7w@mail.gmail.com>
Message-ID: <20130417031512.GA3338@S2101-09.ap.freescale.net>

On Tue, Apr 16, 2013 at 11:47:57AM -0500, Ryan Bryngelson wrote:
> I don't see how I should define a node in the imx28-evk.dts that
> defines a GPIO that is an IRQ.  The "interrupts" in the dtsi file, 127
> in the example above, refer to the IRQ source in the ICOLL.  Where are
> the definitions of the interrupt-cells and gpio-cells at that are
> described in the gpio-mxs.txt documentation?

There is an example in arch/arm/boot/dts/imx28-cfa10049.dts.

pca9555: pca9555 at 20 {
	compatible = "nxp,pca9555";
	interrupt-parent = <&gpio2>;
	interrupts = <19 0x2>;
};

In this example, the device pca9555 uses GPIO2_19 as the IRQ line which
is high-to-low edge triggered.

Shawn



From robherring2 at gmail.com  Tue Apr 16 23:23:47 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Tue, 16 Apr 2013 22:23:47 -0500
Subject: 3.8+, PL310_ERRATA_769419 and highbank: borked reboot
In-Reply-To: <20130416165516.GA3097@luxor.wired.org>
References: <20130416165516.GA3097@luxor.wired.org>
Message-ID: <516E15C3.6090504@gmail.com>

On 04/16/2013 11:55 AM, Paolo Pisati wrote:
> Scenario:
> 
> 3.9-rc7 kernel, multiplatform support with highbank and imx6 selected, highbank
> node -> reboot doesn't work (actually it works 1 out of 10 times)
> 
> And playing around with the config i was able to track it down to
> PL310_ERRATA_769419.

Thanks for narrowing this down.

I see 3 cores in arch_spin_lock and core 1 is powered off. I suspect
this is the l2x0 spinlock, but don't have a backtrace. If I raise the
printk level to get all the console messages, then the problem goes
away. I'm guessing core 1 is releasing the spinlock and the lock is not
getting flushed out when the core is hotplugged. With some delay the of
the printks, then the other cores have time to shutdown before core 1
exits coherency. I'll try to figure out a fix tomorrow.

Rob

> -a config and kernel that reproduce the issue:
> 
> http://people.canonical.com/~ppisati/highbank_769419_reboot/config.brk
> 
> http://people.canonical.com/~ppisati/highbank_769419_reboot/zImage.brk
> 
> -a config and kernel that don't reproduce it: 
> 
> http://people.canonical.com/~ppisati/highbank_769419_reboot/0003-highbank-dbg-comment-out-PL310_ERRATA_769419.patch
> 
> http://people.canonical.com/~ppisati/highbank_769419_reboot/config.ok
> 
> http://people.canonical.com/~ppisati/highbank_769419_reboot/zImage.ok
> 
> If you are building pl330 support too, you need a patch like this one:
> 
> http://people.canonical.com/~ppisati/highbank_769419_reboot/0001-dma-of-dma-check-OF-pointer-property-before-derefere.patch
> 
> to avoid a NULL ptr oops during boot.
> 
> Same issue happens on 3.8, and due to my test environment (conserver
> on top of ipmi for 'serial over lan') i was unable to sysrq and give you a
> stacktrace, sorry.
> 



From rabryn at c2development.com  Tue Apr 16 23:41:40 2013
From: rabryn at c2development.com (Ryan Bryngelson)
Date: Tue, 16 Apr 2013 22:41:40 -0500
Subject: iMX28 DTS GPIO IRQ Definition
In-Reply-To: <20130417031512.GA3338@S2101-09.ap.freescale.net>
References: <CAGUvELcRFK9vjx3t69ccEfjLanPSnpZmSo83fxQN0yWvbjTX7w@mail.gmail.com>
 <20130417031512.GA3338@S2101-09.ap.freescale.net>
Message-ID: <CAGUvELcukT8Ei13HnrE2rxxkaV3+TW7W+ovP0sd=kGcBOtKgvQ@mail.gmail.com>

>
> There is an example in arch/arm/boot/dts/imx28-cfa10049.dts.
>
> pca9555: pca9555 at 20 {
>         compatible = "nxp,pca9555";
>         interrupt-parent = <&gpio2>;
>         interrupts = <19 0x2>;
> };
>
> In this example, the device pca9555 uses GPIO2_19 as the IRQ line which
> is high-to-low edge triggered.
>
> Shawn
>
Thanks for the information!  I see what you're referring to.  In the
latest imx28-cfa10049.dts I see the definition looks like this...

pca9555: pca9555 at 20 {
    compatible = "nxp,pca9555";
    interrupt-parent = <&gpio2>;
    interrupts = <19 0x2>;
    gpio-controller;
    #gpio-cells = <2>;
    interrupt-controller;
    #interrupt-cells = <2>;
    reg = <0x20>;
};

I'm learning about the device tree.  Is it correct to say "interrupts"
corresponds to "#interrupt-cells" and "gpios" corresponds to
"gpio-cells"?  If so, why is "gpios" missing from this definition?  I
see that GPIO2_19 is configured to have it's internal pull up enabled
in the hog_pins_cfa10049_pullup node.  What are "hog_pins"?

Thanks again for taking the time to respond.  I've been stuck with
these questions for a couple days now.  I can't seem to find any
resources online to learn about the device tree.

Ryan


From shawn.guo at linaro.org  Tue Apr 16 23:43:36 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Wed, 17 Apr 2013 11:43:36 +0800
Subject: iMX28 DTS GPIO IRQ Definition
In-Reply-To: <CAGUvELeMsm-HHdEaj8NbhRV+BuySq4STQNqbC_jcofY9uDQACQ@mail.gmail.com>
References: <CAGUvELcRFK9vjx3t69ccEfjLanPSnpZmSo83fxQN0yWvbjTX7w@mail.gmail.com>
 <20130417031512.GA3338@S2101-09.ap.freescale.net>
 <CAGUvELeMsm-HHdEaj8NbhRV+BuySq4STQNqbC_jcofY9uDQACQ@mail.gmail.com>
Message-ID: <20130417034334.GH11245@S2101-09.ap.freescale.net>

On Tue, Apr 16, 2013 at 10:28:52PM -0500, Ryan Bryngelson wrote:
> Thanks for the tip!  I'm using mainline kernel version 3.8.3.  I don't see the
> pca9555 definition you mention in the imx28-cfa10049.dts.  I looked back a few
> version and still no luck... am I missing something? 

Ah, I was looking at v3.9-rc.

Shawn



From shawn.guo at linaro.org  Wed Apr 17 00:41:26 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Wed, 17 Apr 2013 12:41:26 +0800
Subject: iMX28 DTS GPIO IRQ Definition
In-Reply-To: <CAGUvELcukT8Ei13HnrE2rxxkaV3+TW7W+ovP0sd=kGcBOtKgvQ@mail.gmail.com>
References: <CAGUvELcRFK9vjx3t69ccEfjLanPSnpZmSo83fxQN0yWvbjTX7w@mail.gmail.com>
 <20130417031512.GA3338@S2101-09.ap.freescale.net>
 <CAGUvELcukT8Ei13HnrE2rxxkaV3+TW7W+ovP0sd=kGcBOtKgvQ@mail.gmail.com>
Message-ID: <20130417044124.GI11245@S2101-09.ap.freescale.net>

On Tue, Apr 16, 2013 at 10:41:40PM -0500, Ryan Bryngelson wrote:
> pca9555: pca9555 at 20 {
>     compatible = "nxp,pca9555";
>     interrupt-parent = <&gpio2>;
>     interrupts = <19 0x2>;
>     gpio-controller;
>     #gpio-cells = <2>;
>     interrupt-controller;
>     #interrupt-cells = <2>;
>     reg = <0x20>;
> };
> 
> I'm learning about the device tree.  Is it correct to say "interrupts"
> corresponds to "#interrupt-cells" and "gpios" corresponds to
> "gpio-cells"?  If so, why is "gpios" missing from this definition?

#interrupt-cells and #gpio-cells are properties of interrupt controller
and gpio controller.  The reason you are seeing them in pca9555 is
because that the device acts as both a interrupt controller and a gpio
controller.  And that's why the node has properties "gpio-controller"
and interrupt-controller.  This is the same case as gpio device.  But
meanwhile pca9555 is also a interrupt client device of gpio2.  And
properties "interrupts" and "interrupt-parent" are used to tell that.

I should probably give you a simpler example firstly.  You may want to
look at "lan9220 at f4000000" node in arch/arm/boot/dts/imx53-ard.dts.
That's a pure interrupt client device.

> I
> see that GPIO2_19 is configured to have it's internal pull up enabled
> in the hog_pins_cfa10049_pullup node.  What are "hog_pins"?

We put the pins that do not have a clear owner device and should only be
configured for once on given board in "hog_pins".  And pinctrl core will
set up these pins during initialization.

Shawn



From camera10 at hshcctv.com  Wed Apr 17 01:01:42 2013
From: camera10 at hshcctv.com (camera)
Date: Wed, 17 Apr 2013 13:01:42 +0800
Subject: =?gb2312?B?c3BlY2lhbCBjYW1lcmE=?=
Message-ID: <381-2201343175142353@PC201301001>

Hi , my friend.

This is Roy Zhang from China ,and I know you want to buy some product about
camera and DVR in globalmarket .

Our company named SUNIVISION , it's in GUANGZHOU , and we have a factory to
production camera and DVR , we production camera includ bullet camera. dome
camera . box camera . mini camera and other camera  includ IPcamera . and we
pass the  IP 66 . ROHS . FCC .CE .... We production DVR includ 4/8/16/32
video input and includ the HVR .we have the high quality and low price in
the market .

Hope we can cooperation in the future and waiting you reply .

Thanks and Best regards .

Mr Roy 

> Sunivision Technology Development Co.,LTD
> ADD:Floor 3, Building B, Taoyuan Industrial Park, Huangpu East Development Zone, Guangzhou, China
> Tel:+86 020 32071803
> Mobile:+86 15521246030
> MSN :dvr10 at hshvision.com ( online for 24hours per day) 
> Skype:sunivision10
> Yahoo messiage: Royzhang411




From daniel.lezcano at linaro.org  Wed Apr 17 02:24:49 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Wed, 17 Apr 2013 08:24:49 +0200
Subject: [V3 patch 19/19] ARM: imx: cpuidle: use init/exit common routine
In-Reply-To: <1365770165-27096-20-git-send-email-daniel.lezcano@linaro.org>
References: <1365770165-27096-1-git-send-email-daniel.lezcano@linaro.org>
 <1365770165-27096-20-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <516E4031.3000906@linaro.org>

On 04/12/2013 02:36 PM, Daniel Lezcano wrote:
> The code intializes the cpuidle driver at different places.
> The cpuidle driver for :
>   * imx5 : is in the pm-imx5.c, the init function is in cpuidle.c
>   * imx6 : is in cpuidle-imx6q.c, the init function is in cpuidle.c
>            and cpuidle-imx6q.c
>
> Instead of having the cpuidle code spread across different files,
> let's create a driver for each SoC and use the common register function.
>
> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
> ---

Hi Sascha, Shawn,

are you ok with this patch ?

Thanks
-- Daniel


>  arch/arm/mach-imx/Makefile        |    2 +-
>  arch/arm/mach-imx/cpuidle-imx5.c  |   40 +++++++++++++++++++
>  arch/arm/mach-imx/cpuidle-imx6q.c |    2 +-
>  arch/arm/mach-imx/cpuidle.c       |   80 -------------------------------------
>  arch/arm/mach-imx/cpuidle.h       |   10 ++---
>  arch/arm/mach-imx/pm-imx5.c       |   29 +-------------
>  6 files changed, 47 insertions(+), 116 deletions(-)
>  create mode 100644 arch/arm/mach-imx/cpuidle-imx5.c
>  delete mode 100644 arch/arm/mach-imx/cpuidle.c
>
> diff --git a/arch/arm/mach-imx/Makefile b/arch/arm/mach-imx/Makefile
> index c4ce090..cb70961 100644
> --- a/arch/arm/mach-imx/Makefile
> +++ b/arch/arm/mach-imx/Makefile
> @@ -30,7 +30,7 @@ obj-$(CONFIG_MXC_DEBUG_BOARD) += 3ds_debugboard.o
>  obj-$(CONFIG_CPU_FREQ_IMX)    += cpufreq.o
>  
>  ifeq ($(CONFIG_CPU_IDLE),y)
> -obj-y += cpuidle.o
> +obj-$(CONFIG_SOC_IMX5) += cpuidle-imx5.o
>  obj-$(CONFIG_SOC_IMX6Q) += cpuidle-imx6q.o
>  endif
>  
> diff --git a/arch/arm/mach-imx/cpuidle-imx5.c b/arch/arm/mach-imx/cpuidle-imx5.c
> new file mode 100644
> index 0000000..ba4565f
> --- /dev/null
> +++ b/arch/arm/mach-imx/cpuidle-imx5.c
> @@ -0,0 +1,40 @@
> +/*
> + * Copyright (C) 2012 Freescale Semiconductor, Inc.
> + *
> + * 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/cpuidle.h>
> +#include <linux/module.h>
> +#include <asm/system_misc.h>
> +#include <asm/proc-fns.h>
> +
> +#include "hardware.h"
> +
> +static int imx5_cpuidle_enter(struct cpuidle_device *dev,
> +			      struct cpuidle_driver *drv, int index)
> +{
> +	arm_pm_idle();
> +	return index;
> +}
> +
> +static struct cpuidle_driver imx5_cpuidle_driver = {
> +	.name             = "imx5_cpuidle",
> +	.owner            = THIS_MODULE,
> +	.states[0] = {
> +		.enter            = imx5_cpuidle_enter,
> +		.exit_latency     = 2,
> +		.target_residency = 1,
> +		.flags            = CPUIDLE_FLAG_TIME_VALID,
> +		.name             = "IMX5 SRPG",
> +		.desc             = "CPU state retained,powered off",
> +	},
> +	.state_count = 1,
> +};
> +
> +int __init imx5_cpuidle_init(void)
> +{
> +	return cpuidle_register(&imx5_cpuidle_driver, NULL);
> +}
> diff --git a/arch/arm/mach-imx/cpuidle-imx6q.c b/arch/arm/mach-imx/cpuidle-imx6q.c
> index e2739ad..23ddfb6 100644
> --- a/arch/arm/mach-imx/cpuidle-imx6q.c
> +++ b/arch/arm/mach-imx/cpuidle-imx6q.c
> @@ -71,5 +71,5 @@ int __init imx6q_cpuidle_init(void)
>  	/* Set chicken bit to get a reliable WAIT mode support */
>  	imx6q_set_chicken_bit();
>  
> -	return imx_cpuidle_init(&imx6q_cpuidle_driver);
> +	return cpuidle_register(&imx6q_cpuidle_driver, NULL);
>  }
> diff --git a/arch/arm/mach-imx/cpuidle.c b/arch/arm/mach-imx/cpuidle.c
> deleted file mode 100644
> index d4cb511..0000000
> --- a/arch/arm/mach-imx/cpuidle.c
> +++ /dev/null
> @@ -1,80 +0,0 @@
> -/*
> - * Copyright 2012 Freescale Semiconductor, Inc.
> - * Copyright 2012 Linaro Ltd.
> - *
> - * The code contained herein is licensed under the GNU General Public
> - * License. You may obtain a copy of the GNU General Public License
> - * Version 2 or later at the following locations:
> - *
> - * http://www.opensource.org/licenses/gpl-license.html
> - * http://www.gnu.org/copyleft/gpl.html
> - */
> -
> -#include <linux/cpuidle.h>
> -#include <linux/err.h>
> -#include <linux/hrtimer.h>
> -#include <linux/io.h>
> -#include <linux/kernel.h>
> -#include <linux/slab.h>
> -
> -static struct cpuidle_device __percpu * imx_cpuidle_devices;
> -
> -static void __init imx_cpuidle_devices_uninit(void)
> -{
> -	int cpu_id;
> -	struct cpuidle_device *dev;
> -
> -	for_each_possible_cpu(cpu_id) {
> -		dev = per_cpu_ptr(imx_cpuidle_devices, cpu_id);
> -		cpuidle_unregister_device(dev);
> -	}
> -
> -	free_percpu(imx_cpuidle_devices);
> -}
> -
> -int __init imx_cpuidle_init(struct cpuidle_driver *drv)
> -{
> -	struct cpuidle_device *dev;
> -	int cpu_id, ret;
> -
> -	if (drv->state_count > CPUIDLE_STATE_MAX) {
> -		pr_err("%s: state_count exceeds maximum\n", __func__);
> -		return -EINVAL;
> -	}
> -
> -	ret = cpuidle_register_driver(drv);
> -	if (ret) {
> -		pr_err("%s: Failed to register cpuidle driver with error: %d\n",
> -			 __func__, ret);
> -		return ret;
> -	}
> -
> -	imx_cpuidle_devices = alloc_percpu(struct cpuidle_device);
> -	if (imx_cpuidle_devices == NULL) {
> -		ret = -ENOMEM;
> -		goto unregister_drv;
> -	}
> -
> -	/* initialize state data for each cpuidle_device */
> -	for_each_possible_cpu(cpu_id) {
> -		dev = per_cpu_ptr(imx_cpuidle_devices, cpu_id);
> -		dev->cpu = cpu_id;
> -		dev->state_count = drv->state_count;
> -
> -		ret = cpuidle_register_device(dev);
> -		if (ret) {
> -			pr_err("%s: Failed to register cpu %u, error: %d\n",
> -				__func__, cpu_id, ret);
> -			goto uninit;
> -		}
> -	}
> -
> -	return 0;
> -
> -uninit:
> -	imx_cpuidle_devices_uninit();
> -
> -unregister_drv:
> -	cpuidle_unregister_driver(drv);
> -	return ret;
> -}
> diff --git a/arch/arm/mach-imx/cpuidle.h b/arch/arm/mach-imx/cpuidle.h
> index e092d13..786f98e 100644
> --- a/arch/arm/mach-imx/cpuidle.h
> +++ b/arch/arm/mach-imx/cpuidle.h
> @@ -10,18 +10,16 @@
>   * http://www.gnu.org/copyleft/gpl.html
>   */
>  
> -#include <linux/cpuidle.h>
> -
>  #ifdef CONFIG_CPU_IDLE
> -extern int imx_cpuidle_init(struct cpuidle_driver *drv);
> +extern int imx5_cpuidle_init(void);
>  extern int imx6q_cpuidle_init(void);
>  #else
> -static inline int imx_cpuidle_init(struct cpuidle_driver *drv)
> +static inline int imx5_cpuidle_init(void)
>  {
> -	return -ENODEV;
> +	return 0;
>  }
>  static inline int imx6q_cpuidle_init(void)
>  {
> -	return -ENODEV;
> +	return 0;
>  }
>  #endif
> diff --git a/arch/arm/mach-imx/pm-imx5.c b/arch/arm/mach-imx/pm-imx5.c
> index 4b52b3e..82e79c6 100644
> --- a/arch/arm/mach-imx/pm-imx5.c
> +++ b/arch/arm/mach-imx/pm-imx5.c
> @@ -149,32 +149,6 @@ static void imx5_pm_idle(void)
>  	imx5_cpu_do_idle();
>  }
>  
> -static int imx5_cpuidle_enter(struct cpuidle_device *dev,
> -				struct cpuidle_driver *drv, int idx)
> -{
> -	int ret;
> -
> -	ret = imx5_cpu_do_idle();
> -	if (ret < 0)
> -		return ret;
> -
> -	return idx;
> -}
> -
> -static struct cpuidle_driver imx5_cpuidle_driver = {
> -	.name			= "imx5_cpuidle",
> -	.owner			= THIS_MODULE,
> -	.states[0]	= {
> -		.enter			= imx5_cpuidle_enter,
> -		.exit_latency		= 2,
> -		.target_residency	= 1,
> -		.flags			= CPUIDLE_FLAG_TIME_VALID,
> -		.name			= "IMX5 SRPG",
> -		.desc			= "CPU state retained,powered off",
> -	},
> -	.state_count		= 1,
> -};
> -
>  static int __init imx5_pm_common_init(void)
>  {
>  	int ret;
> @@ -192,8 +166,7 @@ static int __init imx5_pm_common_init(void)
>  	/* Set the registers to the default cpu idle state. */
>  	mx5_cpu_lp_set(IMX5_DEFAULT_CPU_IDLE_STATE);
>  
> -	imx_cpuidle_init(&imx5_cpuidle_driver);
> -	return 0;
> +	return imx5_cpuidle_init();
>  }
>  
>  void __init imx51_pm_init(void)


-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From daniel.lezcano at linaro.org  Wed Apr 17 02:28:57 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Wed, 17 Apr 2013 08:28:57 +0200
Subject: [V3 patch 06/19] cpuidle: make a single register function for all
In-Reply-To: <1365770165-27096-7-git-send-email-daniel.lezcano@linaro.org>
References: <1365770165-27096-1-git-send-email-daniel.lezcano@linaro.org>
 <1365770165-27096-7-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <516E4129.1090804@linaro.org>

On 04/12/2013 02:35 PM, Daniel Lezcano wrote:
> The usual scheme to initialize a cpuidle driver on a SMP is:
>
> 	cpuidle_register_driver(drv);
> 	for_each_possible_cpu(cpu) {
> 		device = &per_cpu(cpuidle_dev, cpu);
> 		cpuidle_register_device(device);
> 	}
>
> This code is duplicated in each cpuidle driver.
>
> On UP systems, it is done this way:
>
> 	cpuidle_register_driver(drv);
> 	device = &per_cpu(cpuidle_dev, cpu);
> 	cpuidle_register_device(device);
>
> On UP, the macro 'for_each_cpu' does one iteration:
>
> #define for_each_cpu(cpu, mask)                 \
>         for ((cpu) = 0; (cpu) < 1; (cpu)++, (void)mask)
>
> Hence, the initialization loop is the same for UP than SMP.
>
> Beside, we saw different bugs / mis-initialization / return code unchecked in
> the different drivers, the code is duplicated including bugs. After fixing all
> these ones, it appears the initialization pattern is the same for everyone.
>
> Please note, some drivers are doing dev->state_count = drv->state_count. This is
> not necessary because it is done by the cpuidle_enable_device function in the
> cpuidle framework. This is true, until you have the same states for all your
> devices. Otherwise, the 'low level' API should be used instead with the specific
> initialization for the driver.
>
> Let's add a wrapper function doing this initialization with a cpumask parameter
> for the coupled idle states and use it for all the drivers.
>
> That will save a lot of LOC, consolidate the code, and the modifications in the
> future could be done in a single place. Another benefit is the consolidation of
> the cpuidle_device variable which is now in the cpuidle framework and no longer
> spread accross the different arch specific drivers.
>
> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
> ---

Hi Rob, Andrew,

are you ok with this new version ?

Thanks
-- Daniel

>  Documentation/cpuidle/driver.txt |    6 ++++
>  drivers/cpuidle/cpuidle.c        |   72 ++++++++++++++++++++++++++++++++++++++
>  include/linux/cpuidle.h          |    9 +++--
>  3 files changed, 85 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/cpuidle/driver.txt b/Documentation/cpuidle/driver.txt
> index 7a9e09e..1b0d81d 100644
> --- a/Documentation/cpuidle/driver.txt
> +++ b/Documentation/cpuidle/driver.txt
> @@ -15,11 +15,17 @@ has mechanisms in place to support actual entry-exit into CPU idle states.
>  cpuidle driver initializes the cpuidle_device structure for each CPU device
>  and registers with cpuidle using cpuidle_register_device.
>  
> +If all the idle states are the same, the wrapper function cpuidle_register
> +could be used instead.
> +
>  It can also support the dynamic changes (like battery <-> AC), by using
>  cpuidle_pause_and_lock, cpuidle_disable_device and cpuidle_enable_device,
>  cpuidle_resume_and_unlock.
>  
>  Interfaces:
> +extern int cpuidle_register(struct cpuidle_driver *drv,
> +                            const struct cpumask *const coupled_cpus);
> +extern int cpuidle_unregister(struct cpuidle_driver *drv);
>  extern int cpuidle_register_driver(struct cpuidle_driver *drv);
>  extern void cpuidle_unregister_driver(struct cpuidle_driver *drv);
>  extern int cpuidle_register_device(struct cpuidle_device *dev);
> diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
> index 0da795b..49e8d30 100644
> --- a/drivers/cpuidle/cpuidle.c
> +++ b/drivers/cpuidle/cpuidle.c
> @@ -24,6 +24,7 @@
>  #include "cpuidle.h"
>  
>  DEFINE_PER_CPU(struct cpuidle_device *, cpuidle_devices);
> +DEFINE_PER_CPU(struct cpuidle_device, cpuidle_dev);
>  
>  DEFINE_MUTEX(cpuidle_lock);
>  LIST_HEAD(cpuidle_detected_devices);
> @@ -453,6 +454,77 @@ void cpuidle_unregister_device(struct cpuidle_device *dev)
>  
>  EXPORT_SYMBOL_GPL(cpuidle_unregister_device);
>  
> +/*
> + * cpuidle_unregister: unregister a driver and the devices. This function
> + * can be used only if the driver has been previously registered through
> + * the cpuidle_register function.
> + *
> + * @drv: a valid pointer to a struct cpuidle_driver
> + */
> +void cpuidle_unregister(struct cpuidle_driver *drv)
> +{
> +	int cpu;
> +	struct cpuidle_device *device;
> +
> +	for_each_possible_cpu(cpu) {
> +		device = &per_cpu(cpuidle_dev, cpu);
> +		cpuidle_unregister_device(device);
> +	}
> +
> +	cpuidle_unregister_driver(drv);
> +}
> +EXPORT_SYMBOL_GPL(cpuidle_unregister);
> +
> +/**
> + * cpuidle_register: registers the driver and the cpu devices with the
> + * coupled_cpus passed as parameter. This function is used for all common
> + * initialization pattern there are in the arch specific drivers. The
> + * devices is globally defined in this file.
> + *
> + * @drv         : a valid pointer to a struct cpuidle_driver
> + * @coupled_cpus: a cpumask for the coupled states
> + *
> + * Returns 0 on success, < 0 otherwise
> + */
> +int cpuidle_register(struct cpuidle_driver *drv,
> +		     const struct cpumask *const coupled_cpus)
> +{
> +	int ret, cpu;
> +	struct cpuidle_device *device;
> +
> +	ret = cpuidle_register_driver(drv);
> +	if (ret) {
> +		pr_err("failed to register cpuidle driver\n");
> +		return ret;
> +	}
> +
> +	for_each_possible_cpu(cpu) {
> +		device = &per_cpu(cpuidle_dev, cpu);
> +		device->cpu = cpu;
> +
> +#ifdef CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED
> +		/*
> +		 * On multiplatform for ARM, the coupled idle states could
> +		 * enabled in the kernel even if the cpuidle driver does not
> +		 * use it. Note, coupled_cpus is a struct copy.
> +		 */
> +		if (coupled_cpus)
> +			device->coupled_cpus = *coupled_cpus;
> +#endif
> +		ret = cpuidle_register_device(device);
> +		if (!ret)
> +			continue;
> +
> +		pr_err("Failed to register cpuidle device for cpu%d\n", cpu);
> +
> +		cpuidle_unregister(drv);
> +		break;
> +	}
> +
> +	return ret;
> +}
> +EXPORT_SYMBOL_GPL(cpuidle_register);
> +
>  #ifdef CONFIG_SMP
>  
>  static void smp_callback(void *v)
> diff --git a/include/linux/cpuidle.h b/include/linux/cpuidle.h
> index 79e3811..3c86faa 100644
> --- a/include/linux/cpuidle.h
> +++ b/include/linux/cpuidle.h
> @@ -123,7 +123,9 @@ extern void cpuidle_driver_unref(void);
>  extern void cpuidle_unregister_driver(struct cpuidle_driver *drv);
>  extern int cpuidle_register_device(struct cpuidle_device *dev);
>  extern void cpuidle_unregister_device(struct cpuidle_device *dev);
> -
> +extern int cpuidle_register(struct cpuidle_driver *drv,
> +			    const struct cpumask *const coupled_cpus);
> +extern void cpuidle_unregister(struct cpuidle_driver *drv);
>  extern void cpuidle_pause_and_lock(void);
>  extern void cpuidle_resume_and_unlock(void);
>  extern void cpuidle_pause(void);
> @@ -148,7 +150,10 @@ static inline void cpuidle_unregister_driver(struct cpuidle_driver *drv) { }
>  static inline int cpuidle_register_device(struct cpuidle_device *dev)
>  {return -ENODEV; }
>  static inline void cpuidle_unregister_device(struct cpuidle_device *dev) { }
> -
> +static inline int cpuidle_register(struct cpuidle_driver *drv,
> +				   const struct cpumask *const coupled_cpus)
> +{return -ENODEV; }
> +static inline void cpuidle_unregister(struct cpuidle_driver *drv) { }
>  static inline void cpuidle_pause_and_lock(void) { }
>  static inline void cpuidle_resume_and_unlock(void) { }
>  static inline void cpuidle_pause(void) { }


-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From prakash.pm at ti.com  Wed Apr 17 02:32:46 2013
From: prakash.pm at ti.com (Manjunathappa, Prakash)
Date: Wed, 17 Apr 2013 06:32:46 +0000
Subject: [PATCH 0/4] ARM: davinci: fix UART clock enabling
In-Reply-To: <1365510481-32129-1-git-send-email-prakash.pm@ti.com>
References: <1365510481-32129-1-git-send-email-prakash.pm@ti.com>
Message-ID: <A73F36158E33644199EB82C5EC81C7BC3EA4DCC9@DBDE01.ent.ti.com>

Hi Sekhar,

On Tue, Apr 09, 2013 at 17:57:57, Manjunathappa, Prakash wrote:
> Patch series addresses below issues:
> 1) Do clk_get on dev_id when there is single clock for a module
> 2) Fix garbled UART log with DT kernel on da850-evm.
> 

Could you please accept this series if you do not have review comments?

Thanks,
Prakash

> Applies on top of v3.9-rc9 of Linus's.
> Tested on da850-evm. Able to see proper bootup log and console on UART2.
> 
> Manjunathappa, Prakash (4):
>   ARM: davinci: uart: move to devid based clk_get
>   ARM: davinci: da850: override device name of UART in DT kernel
>   ARM: davinci: da850: do not specify clock_frequency for UART DT node
>   ARM: davinci: da8xx: remove da8xx_uart_clk_enable
> 
>  arch/arm/boot/dts/da850.dtsi                   |    3 -
>  arch/arm/mach-davinci/da830.c                  |    8 ++--
>  arch/arm/mach-davinci/da850.c                  |    8 ++--
>  arch/arm/mach-davinci/da8xx-dt.c               |   11 +----
>  arch/arm/mach-davinci/devices-da8xx.c          |   40 ++++++++++++++++---
>  arch/arm/mach-davinci/devices-tnetv107x.c      |   35 ++++++++++++++---
>  arch/arm/mach-davinci/dm355.c                  |   48 ++++++++++++++++++-----
>  arch/arm/mach-davinci/dm365.c                  |   35 ++++++++++++----
>  arch/arm/mach-davinci/dm644x.c                 |   48 ++++++++++++++++++-----
>  arch/arm/mach-davinci/dm646x.c                 |   49 +++++++++++++++++++-----
>  arch/arm/mach-davinci/include/mach/da8xx.h     |    2 +-
>  arch/arm/mach-davinci/include/mach/tnetv107x.h |    2 +-
>  arch/arm/mach-davinci/serial.c                 |   19 ++++++---
>  arch/arm/mach-davinci/tnetv107x.c              |    8 ++--
>  14 files changed, 233 insertions(+), 83 deletions(-)
> 
> --
> 1.7.4.1
> 
> 



From shawn.guo at linaro.org  Wed Apr 17 03:15:14 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Wed, 17 Apr 2013 15:15:14 +0800
Subject: [V3 patch 19/19] ARM: imx: cpuidle: use init/exit common routine
In-Reply-To: <1365770165-27096-20-git-send-email-daniel.lezcano@linaro.org>
References: <1365770165-27096-1-git-send-email-daniel.lezcano@linaro.org>
 <1365770165-27096-20-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <20130417071511.GB3338@S2101-09.ap.freescale.net>

Thanks for working on this, Daniel.

The imx6q change looks good to me.  But I have a comment on imx5 changes
below.

On Fri, Apr 12, 2013 at 02:36:05PM +0200, Daniel Lezcano wrote:
> diff --git a/arch/arm/mach-imx/cpuidle-imx5.c b/arch/arm/mach-imx/cpuidle-imx5.c
> new file mode 100644
> index 0000000..ba4565f
> --- /dev/null
> +++ b/arch/arm/mach-imx/cpuidle-imx5.c
> @@ -0,0 +1,40 @@
> +/*
> + * Copyright (C) 2012 Freescale Semiconductor, Inc.
> + *
> + * 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/cpuidle.h>
> +#include <linux/module.h>
> +#include <asm/system_misc.h>
> +#include <asm/proc-fns.h>
> +
> +#include "hardware.h"
> +
> +static int imx5_cpuidle_enter(struct cpuidle_device *dev,
> +			      struct cpuidle_driver *drv, int index)
> +{
> +	arm_pm_idle();

The existing imx5 cpuidle code has an tzic_enable_wake() call before
going to idle.  I think it's there for some reason.

Shawn

> +	return index;
> +}
> +
> +static struct cpuidle_driver imx5_cpuidle_driver = {
> +	.name             = "imx5_cpuidle",
> +	.owner            = THIS_MODULE,
> +	.states[0] = {
> +		.enter            = imx5_cpuidle_enter,
> +		.exit_latency     = 2,
> +		.target_residency = 1,
> +		.flags            = CPUIDLE_FLAG_TIME_VALID,
> +		.name             = "IMX5 SRPG",
> +		.desc             = "CPU state retained,powered off",
> +	},
> +	.state_count = 1,
> +};
> +
> +int __init imx5_cpuidle_init(void)
> +{
> +	return cpuidle_register(&imx5_cpuidle_driver, NULL);
> +}
> diff --git a/arch/arm/mach-imx/cpuidle-imx6q.c b/arch/arm/mach-imx/cpuidle-imx6q.c
> index e2739ad..23ddfb6 100644
> --- a/arch/arm/mach-imx/cpuidle-imx6q.c
> +++ b/arch/arm/mach-imx/cpuidle-imx6q.c
> @@ -71,5 +71,5 @@ int __init imx6q_cpuidle_init(void)
>  	/* Set chicken bit to get a reliable WAIT mode support */
>  	imx6q_set_chicken_bit();
>  
> -	return imx_cpuidle_init(&imx6q_cpuidle_driver);
> +	return cpuidle_register(&imx6q_cpuidle_driver, NULL);
>  }
> diff --git a/arch/arm/mach-imx/cpuidle.c b/arch/arm/mach-imx/cpuidle.c
> deleted file mode 100644
> index d4cb511..0000000
> --- a/arch/arm/mach-imx/cpuidle.c
> +++ /dev/null
> @@ -1,80 +0,0 @@
> -/*
> - * Copyright 2012 Freescale Semiconductor, Inc.
> - * Copyright 2012 Linaro Ltd.
> - *
> - * The code contained herein is licensed under the GNU General Public
> - * License. You may obtain a copy of the GNU General Public License
> - * Version 2 or later at the following locations:
> - *
> - * http://www.opensource.org/licenses/gpl-license.html
> - * http://www.gnu.org/copyleft/gpl.html
> - */
> -
> -#include <linux/cpuidle.h>
> -#include <linux/err.h>
> -#include <linux/hrtimer.h>
> -#include <linux/io.h>
> -#include <linux/kernel.h>
> -#include <linux/slab.h>
> -
> -static struct cpuidle_device __percpu * imx_cpuidle_devices;
> -
> -static void __init imx_cpuidle_devices_uninit(void)
> -{
> -	int cpu_id;
> -	struct cpuidle_device *dev;
> -
> -	for_each_possible_cpu(cpu_id) {
> -		dev = per_cpu_ptr(imx_cpuidle_devices, cpu_id);
> -		cpuidle_unregister_device(dev);
> -	}
> -
> -	free_percpu(imx_cpuidle_devices);
> -}
> -
> -int __init imx_cpuidle_init(struct cpuidle_driver *drv)
> -{
> -	struct cpuidle_device *dev;
> -	int cpu_id, ret;
> -
> -	if (drv->state_count > CPUIDLE_STATE_MAX) {
> -		pr_err("%s: state_count exceeds maximum\n", __func__);
> -		return -EINVAL;
> -	}
> -
> -	ret = cpuidle_register_driver(drv);
> -	if (ret) {
> -		pr_err("%s: Failed to register cpuidle driver with error: %d\n",
> -			 __func__, ret);
> -		return ret;
> -	}
> -
> -	imx_cpuidle_devices = alloc_percpu(struct cpuidle_device);
> -	if (imx_cpuidle_devices == NULL) {
> -		ret = -ENOMEM;
> -		goto unregister_drv;
> -	}
> -
> -	/* initialize state data for each cpuidle_device */
> -	for_each_possible_cpu(cpu_id) {
> -		dev = per_cpu_ptr(imx_cpuidle_devices, cpu_id);
> -		dev->cpu = cpu_id;
> -		dev->state_count = drv->state_count;
> -
> -		ret = cpuidle_register_device(dev);
> -		if (ret) {
> -			pr_err("%s: Failed to register cpu %u, error: %d\n",
> -				__func__, cpu_id, ret);
> -			goto uninit;
> -		}
> -	}
> -
> -	return 0;
> -
> -uninit:
> -	imx_cpuidle_devices_uninit();
> -
> -unregister_drv:
> -	cpuidle_unregister_driver(drv);
> -	return ret;
> -}
> diff --git a/arch/arm/mach-imx/cpuidle.h b/arch/arm/mach-imx/cpuidle.h
> index e092d13..786f98e 100644
> --- a/arch/arm/mach-imx/cpuidle.h
> +++ b/arch/arm/mach-imx/cpuidle.h
> @@ -10,18 +10,16 @@
>   * http://www.gnu.org/copyleft/gpl.html
>   */
>  
> -#include <linux/cpuidle.h>
> -
>  #ifdef CONFIG_CPU_IDLE
> -extern int imx_cpuidle_init(struct cpuidle_driver *drv);
> +extern int imx5_cpuidle_init(void);
>  extern int imx6q_cpuidle_init(void);
>  #else
> -static inline int imx_cpuidle_init(struct cpuidle_driver *drv)
> +static inline int imx5_cpuidle_init(void)
>  {
> -	return -ENODEV;
> +	return 0;
>  }
>  static inline int imx6q_cpuidle_init(void)
>  {
> -	return -ENODEV;
> +	return 0;
>  }
>  #endif
> diff --git a/arch/arm/mach-imx/pm-imx5.c b/arch/arm/mach-imx/pm-imx5.c
> index 4b52b3e..82e79c6 100644
> --- a/arch/arm/mach-imx/pm-imx5.c
> +++ b/arch/arm/mach-imx/pm-imx5.c
> @@ -149,32 +149,6 @@ static void imx5_pm_idle(void)
>  	imx5_cpu_do_idle();
>  }
>  
> -static int imx5_cpuidle_enter(struct cpuidle_device *dev,
> -				struct cpuidle_driver *drv, int idx)
> -{
> -	int ret;
> -
> -	ret = imx5_cpu_do_idle();
> -	if (ret < 0)
> -		return ret;
> -
> -	return idx;
> -}
> -
> -static struct cpuidle_driver imx5_cpuidle_driver = {
> -	.name			= "imx5_cpuidle",
> -	.owner			= THIS_MODULE,
> -	.states[0]	= {
> -		.enter			= imx5_cpuidle_enter,
> -		.exit_latency		= 2,
> -		.target_residency	= 1,
> -		.flags			= CPUIDLE_FLAG_TIME_VALID,
> -		.name			= "IMX5 SRPG",
> -		.desc			= "CPU state retained,powered off",
> -	},
> -	.state_count		= 1,
> -};
> -
>  static int __init imx5_pm_common_init(void)
>  {
>  	int ret;
> @@ -192,8 +166,7 @@ static int __init imx5_pm_common_init(void)
>  	/* Set the registers to the default cpu idle state. */
>  	mx5_cpu_lp_set(IMX5_DEFAULT_CPU_IDLE_STATE);
>  
> -	imx_cpuidle_init(&imx5_cpuidle_driver);
> -	return 0;
> +	return imx5_cpuidle_init();
>  }
>  
>  void __init imx51_pm_init(void)
> -- 
> 1.7.9.5
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pm" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



From daniel.lezcano at linaro.org  Wed Apr 17 03:23:02 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Wed, 17 Apr 2013 09:23:02 +0200
Subject: [V3 patch 19/19] ARM: imx: cpuidle: use init/exit common routine
In-Reply-To: <20130417071511.GB3338@S2101-09.ap.freescale.net>
References: <1365770165-27096-1-git-send-email-daniel.lezcano@linaro.org>
 <1365770165-27096-20-git-send-email-daniel.lezcano@linaro.org>
 <20130417071511.GB3338@S2101-09.ap.freescale.net>
Message-ID: <516E4DD6.2090900@linaro.org>

On 04/17/2013 09:15 AM, Shawn Guo wrote:
> Thanks for working on this, Daniel.
> 
> The imx6q change looks good to me.  But I have a comment on imx5 changes
> below.
> 
> On Fri, Apr 12, 2013 at 02:36:05PM +0200, Daniel Lezcano wrote:
>> diff --git a/arch/arm/mach-imx/cpuidle-imx5.c b/arch/arm/mach-imx/cpuidle-imx5.c
>> new file mode 100644
>> index 0000000..ba4565f
>> --- /dev/null
>> +++ b/arch/arm/mach-imx/cpuidle-imx5.c
>> @@ -0,0 +1,40 @@
>> +/*
>> + * Copyright (C) 2012 Freescale Semiconductor, Inc.
>> + *
>> + * 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/cpuidle.h>
>> +#include <linux/module.h>
>> +#include <asm/system_misc.h>
>> +#include <asm/proc-fns.h>
>> +
>> +#include "hardware.h"
>> +
>> +static int imx5_cpuidle_enter(struct cpuidle_device *dev,
>> +			      struct cpuidle_driver *drv, int index)
>> +{
>> +	arm_pm_idle();
> 
> The existing imx5 cpuidle code has an tzic_enable_wake() call before
> going to idle.  I think it's there for some reason.

The idle function for imx5 is untouched, it is called through
arm_pm_idle instead.

The arm_pm_idle is initialized in imx5_pm_common_init:

arm_pm_idle = imx5_pm_idle;

The imx5_pm_idle function calls imx5_do_pm_idle which in turns calls
tzic_enable_wake and cpu_do_idle.



[ ... ]

-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From shawn.guo at linaro.org  Wed Apr 17 03:39:04 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Wed, 17 Apr 2013 15:39:04 +0800
Subject: [V3 patch 19/19] ARM: imx: cpuidle: use init/exit common routine
In-Reply-To: <516E4DD6.2090900@linaro.org>
References: <1365770165-27096-1-git-send-email-daniel.lezcano@linaro.org>
 <1365770165-27096-20-git-send-email-daniel.lezcano@linaro.org>
 <20130417071511.GB3338@S2101-09.ap.freescale.net>
 <516E4DD6.2090900@linaro.org>
Message-ID: <20130417073902.GC3338@S2101-09.ap.freescale.net>

On Wed, Apr 17, 2013 at 09:23:02AM +0200, Daniel Lezcano wrote:
> On 04/17/2013 09:15 AM, Shawn Guo wrote:
> > Thanks for working on this, Daniel.
> > 
> > The imx6q change looks good to me.  But I have a comment on imx5 changes
> > below.
> > 
> > On Fri, Apr 12, 2013 at 02:36:05PM +0200, Daniel Lezcano wrote:
> >> diff --git a/arch/arm/mach-imx/cpuidle-imx5.c b/arch/arm/mach-imx/cpuidle-imx5.c
> >> new file mode 100644
> >> index 0000000..ba4565f
> >> --- /dev/null
> >> +++ b/arch/arm/mach-imx/cpuidle-imx5.c
> >> @@ -0,0 +1,40 @@
> >> +/*
> >> + * Copyright (C) 2012 Freescale Semiconductor, Inc.
> >> + *
> >> + * 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/cpuidle.h>
> >> +#include <linux/module.h>
> >> +#include <asm/system_misc.h>
> >> +#include <asm/proc-fns.h>
> >> +
> >> +#include "hardware.h"

This seems not needed.

> >> +
> >> +static int imx5_cpuidle_enter(struct cpuidle_device *dev,
> >> +			      struct cpuidle_driver *drv, int index)
> >> +{
> >> +	arm_pm_idle();
> > 
> > The existing imx5 cpuidle code has an tzic_enable_wake() call before
> > going to idle.  I think it's there for some reason.
> 
> The idle function for imx5 is untouched, it is called through
> arm_pm_idle instead.
> 
> The arm_pm_idle is initialized in imx5_pm_common_init:
> 
> arm_pm_idle = imx5_pm_idle;
> 
Ah, yes.  I missed that, sorry.

Acked-by: Shawn Guo <shawn.guo at linaro.org>

> The imx5_pm_idle function calls imx5_do_pm_idle which in turns calls
> tzic_enable_wake and cpu_do_idle.



From martinez.javier at gmail.com  Wed Apr 17 03:55:50 2013
From: martinez.javier at gmail.com (Javier Martinez Canillas)
Date: Wed, 17 Apr 2013 09:55:50 +0200
Subject: [PATCH 3/5] gpio/omap: Add DT support to GPIO driver
In-Reply-To: <516E022F.5050708@ti.com>
References: <1329321854-24490-1-git-send-email-b-cousson@ti.com>
 <CACRpkdZmv-rAoKSQYpkHHSMzKJOn5TixVW_P3=m7ZNagBYCUPw@mail.gmail.com>
 <515319D5.20105@wwwdotorg.org>
 <CACRpkdYXVLgCz1Tyu-Ls2V2OTc4R3cGNJhfQJB6Hiz_K9dkZYQ@mail.gmail.com>
 <5155C902.7080207@wwwdotorg.org>
 <CACRpkdYbs4-uudpRUY8e+7icYYkZrfM0kReP3pLL5DMiURJ4dg@mail.gmail.com>
 <5165CB9D.1090202@wwwdotorg.org>
 <CACRpkdYirFNqmGhA4K9CL4ve4NYhs8Rd3SFt1iwW9vHBkrcz8g@mail.gmail.com>
 <51671D7B.5060303@wwwdotorg.org>
 <CACRpkdbf32Ef77GmXk9id9+RRjcDRTr7S+F4nznoeZU8y=BT_Q@mail.gmail.com>
 <51673D70.3010503@wwwdotorg.org>
 <CAAwP0s0e2x33jZQhFRY+Hoo61SFqYKRgWk=1mL2+DNxSDJHz+A@mail.gmail.com>
 <CACRpkda4h+qXTvsirPAS7E7sjXhMLE62q=VDy53W8UchsYjbNg@mail.gmail.com>
 <516C31C3.9040505@wwwdotorg.org> <516C7C43.3040105@wwwdotorg.org>
 <516C8760.2050500@ti.com> <516D9B05.1000501@wwwdotorg.org>
 <516DA60A.5070000@ti.com> <516DCCA8.3070108@wwwdotorg.org>
 <516DDB4D.9020500@ti.com>
 <CAAwP0s0-VNUoeSKaGbvoDeD7m7kZRdp5rCJ7iVpFoFAaQtXcmQ@mail.gmail.com>
 <516E022F.5050708@ti.com>
Message-ID: <CAAwP0s2M2pnSydyDvh_rejFO=w8bCo4WE5PkxrYuk0HQDixc-Q@mail.gmail.com>

On Wed, Apr 17, 2013 at 4:00 AM, Jon Hunter <jon-hunter at ti.com> wrote:
>
> On 04/16/2013 07:41 PM, Javier Martinez Canillas wrote:
>> On Wed, Apr 17, 2013 at 1:14 AM, Jon Hunter <jon-hunter at ti.com> wrote:
>>>
>>> On 04/16/2013 05:11 PM, Stephen Warren wrote:
>>>> On 04/16/2013 01:27 PM, Jon Hunter wrote:
>>>>>
>>>>> On 04/16/2013 01:40 PM, Stephen Warren wrote:
>>>>>> On 04/15/2013 05:04 PM, Jon Hunter wrote:
>>>> ...
>>>>>>> If some driver is calling gpio_request() directly, then they will most
>>>>>>> likely just call gpio_to_irq() when requesting the interrupt and so the
>>>>>>> xlate function would not be called in this case (mmc drivers are a good
>>>>>>> example). So I don't see that as being a problem. In fact that's the
>>>>>>> benefit of this approach as AFAICT it solves this problem.
>>>>>>
>>>>>> Oh. That assumption seems very fragile. What about drivers that actually
>>>>>> do have platform data (or DT bindings) that provide both the IRQ and
>>>>>> GPIO IDs, and hence don't use gpio_to_irq()? That's entirely possible.
>>>>>
>>>>> Right. In the DT case though, if someone does provide the IRQ and GPIO
>>>>> IDs then at least they would use a different xlate function. Another
>>>>> option to consider would be defining the #interrupt-cells = <3> where we
>>>>> would have ...
>>>>>
>>>>> cell-#1 --> IRQ domain ID
>>>>> cell-#2 --> Trigger type
>>>>> cell-#3 --> GPIO ID
>>>>>
>>>>> Then we could have a generic xlate for 3 cells that would also request
>>>>> the GPIO. Again not sure if people are against a gpio being requested in
>>>>> the xlate but just an idea. Or given that irq_of_parse_and_map() calls
>>>>> the xlate, we could have this function call gpio_request() if the
>>>>> interrupt controller is a gpio and there are 3 cells.
>>>>
>>>> I rather dislike this approach since:
>>>>
>>>> a) It requires changes to the DT bindings, which are already defined.
>>>> Admittedly it's backwards-compatible, but still.
>>>>
>>>> b) There isn't really any need for the DT to represent this; the
>>>> GPIO+IRQ driver itself already knows which IRQ ID is which GPIO ID and
>>>> vice-versa (if the HW has such a concept), so there's no need for the DT
>>>> to contain this information. This seems like pushing Linux's internal
>>>> requirements into the design of the DT binding.
>>>
>>> Yes, so the only alternative is to use irq_to_gpio to avoid this.
>>>
>>>> c) I have the feeling that hooking the of_xlate function for this is a
>>>> bit of an abuse of the function.
>>>
>>> I was wondering about that. So I was grep'ing through the various xlate
>>> implementations and found this [1]. Also you may recall that in the
>>> of_dma_simple_xlate() we call the dma_request_channel() to allocate the
>>> channel, which is very similar. However, I don't wish to get a
>>> reputation as abusing APIs so would be good to know if this really is
>>> abuse or not ;-)
>>>
>>> Cheers
>>> Jon
>>>
>>> [1] http://permalink.gmane.org/gmane.linux.ports.arm.kernel/195124
>>
>> I was looking at [1] shared by Jon and come up with the following
>> patch that does something similar for OMAP GPIO. This has the
>> advantage that is local to gpio-omap instead changing gpiolib-of and
>> also doesn't require DT changes
>>
>> But I don't want to get a reputation for abusing APIs neither :-)
>>
>> Best regards,
>> Javier
>>
>> From 23368eb72b125227fcf4b22be19ea70b4ab94556 Mon Sep 17 00:00:00 2001
>> From: Javier Martinez Canillas <javier.martinez at collabora.co.uk>
>> Date: Wed, 17 Apr 2013 02:03:08 +0200
>> Subject: [PATCH 1/1] gpio/omap: add custom xlate function handler
>>
>> Signed-off-by: Javier Martinez Canillas <javier.martinez at collabora.co.uk>
>> ---
>>  drivers/gpio/gpio-omap.c |   29 ++++++++++++++++++++++++++++-
>>  1 files changed, 28 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
>> index 8524ce5..77216f9 100644
>> --- a/drivers/gpio/gpio-omap.c
>> +++ b/drivers/gpio/gpio-omap.c
>> @@ -1097,6 +1097,33 @@ static void omap_gpio_chip_init(struct gpio_bank *bank)
>>  static const struct of_device_id omap_gpio_match[];
>>  static void omap_gpio_init_context(struct gpio_bank *p);
>>
>> +static int omap_gpio_irq_domain_xlate(struct irq_domain *d,
>> +                                   struct device_node *ctrlr,
>> +                                   const u32 *intspec, unsigned int intsize,
>> +                                   irq_hw_number_t *out_hwirq,
>> +                                   unsigned int *out_type)
>> +{
>> +     int ret;
>> +     struct gpio_bank *bank = d->host_data;
>> +     int gpio = bank->chip.base + intspec[0];
>> +
>> +     if (WARN_ON(intsize < 2))
>> +             return -EINVAL;
>> +
>> +     ret = gpio_request_one(gpio, GPIOF_IN, ctrlr->full_name);
>> +     if (ret)
>> +             return ret;
>> +
>> +     *out_hwirq = intspec[0];
>> +     *out_type = (intsize > 1) ? intspec[1] : IRQ_TYPE_NONE;
>> +
>> +     return 0;
>> +}
>> +
>> +static struct irq_domain_ops omap_gpio_irq_ops = {
>> +     .xlate  = omap_gpio_irq_domain_xlate,
>> +};
>> +
>>  static int omap_gpio_probe(struct platform_device *pdev)
>>  {
>>       struct device *dev = &pdev->dev;
>> @@ -1144,7 +1171,7 @@ static int omap_gpio_probe(struct platform_device *pdev)
>>
>>
>>       bank->domain = irq_domain_add_linear(node, bank->width,
>> -                                          &irq_domain_simple_ops, NULL);
>> +                                          &omap_gpio_irq_ops, bank);
>>       if (!bank->domain)
>>               return -ENODEV;
>>
>
> That would work for omap, in fact I posted pretty much the same thing a
> day ago [1] ;-)
>

Hi Jon,

There are so many patches flying around in this thread that I missed it :-)

Sorry about that...

> I was trying to see if we could find a common solution that everyone
> could use as it seems that ideally we should all be requesting the gpio.
>
> Cheers
> Jon
>
> [1] http://marc.info/?l=linux-arm-kernel&m=136606204823845&w=1

btw, I shared the latest patch with only build testing it, but today I
gave a try and I found a problem with this approach. The .xlate
function is being called twice for each GPIO-IRQ so the first time
gpio_request_one() succeeds but the second time it fails returning
-EBUSY.

This raises a warning on drivers/of/platform.c
(WARN_ON(of_irq_to_resource_table(np, res, num_irq) != num_irq)):

    0.285308] ------------[ cut here ]------------
[    0.285369] WARNING: at drivers/of/platform.c:171
of_device_alloc+0x154/0x168()
[    0.285430] Modules linked in:
[    0.285491] [<c001a944>] (unwind_backtrace+0x0/0xf0) from
[<c0041edc>] (warn_slowpath_common+0x4c/0x68)
[    0.285552] [<c0041edc>] (warn_slowpath_common+0x4c/0x68) from
[<c0041f14>] (warn_slowpath_null+0x1c/0x24)
[    0.285614] [<c0041f14>] (warn_slowpath_null+0x1c/0x24) from
[<c041ac3c>] (of_device_alloc+0x154/0x168)
[    0.285675] [<c041ac3c>] (of_device_alloc+0x154/0x168) from
[<c041ac84>] (of_platform_device_create_pdata+0x34/0x80)
[    0.285736] [<c041ac84>]
(of_platform_device_create_pdata+0x34/0x80) from [<c0027364>]
(gpmc_probe_generic_child+0x180/0x240)
[    0.285827] [<c0027364>] (gpmc_probe_generic_child+0x180/0x240)
from [<c00278d8>] (gpmc_probe+0x4b4/0x614)
[    0.285888] [<c00278d8>] (gpmc_probe+0x4b4/0x614) from [<c0325514>]
(platform_drv_probe+0x18/0x1c)
[    0.285949] [<c0325514>] (platform_drv_probe+0x18/0x1c) from
[<c0324354>] (driver_probe_device+0x108/0x21c)
[    0.286010] [<c0324354>] (driver_probe_device+0x108/0x21c) from
[<c0322b2c>] (bus_for_each_drv+0x5c/0x88)
[    0.286071] [<c0322b2c>] (bus_for_each_drv+0x5c/0x88) from
[<c0324218>] (device_attach+0x78/0x90)
[    0.286132] [<c0324218>] (device_attach+0x78/0x90) from
[<c0323868>] (bus_probe_device+0x88/0xac)
[    0.286193] [<c0323868>] (bus_probe_device+0x88/0xac) from
[<c03220e8>] (device_add+0x4b0/0x584)
[    0.286254] [<c03220e8>] (device_add+0x4b0/0x584) from [<c041acac>]
(of_platform_device_create_pdata+0x5c/0x80)
[    0.286315] [<c041acac>]
(of_platform_device_create_pdata+0x5c/0x80) from [<c041ad9c>]
(of_platform_bus_create+0xcc/0x278)
[    0.286376] [<c041ad9c>] (of_platform_bus_create+0xcc/0x278) from
[<c041adfc>] (of_platform_bus_create+0x12c/0x278)
[    0.286468] [<c041adfc>] (of_platform_bus_create+0x12c/0x278) from
[<c041afa8>] (of_platform_populate+0x60/0x98)
[    0.286529] [<c041afa8>] (of_platform_populate+0x60/0x98) from
[<c070c5f8>] (omap_generic_init+0x24/0x60)
[    0.286590] [<c070c5f8>] (omap_generic_init+0x24/0x60) from
[<c06fe4c4>] (customize_machine+0x1c/0x28)
[    0.286651] [<c06fe4c4>] (customize_machine+0x1c/0x28) from
[<c00086a4>] (do_one_initcall+0x34/0x178)
[    0.286712] [<c00086a4>] (do_one_initcall+0x34/0x178) from
[<c06fb8f4>] (kernel_init_freeable+0xfc/0x1c8)
[    0.286804] [<c06fb8f4>] (kernel_init_freeable+0xfc/0x1c8) from
[<c04e4668>] (kernel_init+0x8/0xe4)
[    0.286865] [<c04e4668>] (kernel_init+0x8/0xe4) from [<c0013170>]
(ret_from_fork+0x14/0x24)
[    0.287139] ---[ end trace d49d2507892be205 ]---

I probably won't have time to dig further on this until later this
week but I wanted to share with you in case you know why is being
calling twice and if you thought about a solution.

It works if I don't check the return gpio_request_one() (or better if
we don't return on omap_gpio_irq_domain_xlate) but of course is not
the right solution.

Thanks a lot and best regards,
Javier


From grinberg at compulab.co.il  Wed Apr 17 03:56:07 2013
From: grinberg at compulab.co.il (Igor Grinberg)
Date: Wed, 17 Apr 2013 10:56:07 +0300
Subject: [PATCH] ARM: dts: omap3-beagle-xm: Add USB Host support for Rev
 Ax/Bx
In-Reply-To: <CAOCHtYgFnCy5Qn2LeJOK96_NdwzxzVe8Vrb8cL=K9AdzPUtQow@mail.gmail.com>
References: <1366029306-1824-1-git-send-email-rogerq@ti.com>
 <516BF4F3.5060904@ti.com> <20130417005232.GV10155@atomide.com>
 <CAOCHtYgFnCy5Qn2LeJOK96_NdwzxzVe8Vrb8cL=K9AdzPUtQow@mail.gmail.com>
Message-ID: <516E5597.7050801@compulab.co.il>

On 04/17/13 04:30, Robert Nelson wrote:
> On Tue, Apr 16, 2013 at 7:52 PM, Tony Lindgren <tony at atomide.com> wrote:
>> * Roger Quadros <rogerq at ti.com> [130415 05:44]:
>>> On 04/15/2013 03:35 PM, Roger Quadros wrote:
>>>> Provide RESET and Power regulators for the USB PHY,
>>>> the USB Host port mode and the PHY device.
>>>>
>>>> Also provide pin multiplexer information for USB host
>>>> pins.
>>>>
>>>> This will not work for Rev Cx boards because of reversed logic
>>>> for USB_POWER_Enable.
>>>>
>>>> CC: Beno?t Cousson <b-cousson at ti.com>
>>>> Signed-off-by: Roger Quadros <rogerq at ti.com>
>>>> ---
>>>>  arch/arm/boot/dts/omap3-beagle-xm.dts |   62 +++++++++++++++++++++++++++++++++
>>>>  1 files changed, 62 insertions(+), 0 deletions(-)
>>>>
>>>> diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts b/arch/arm/boot/dts/omap3-beagle-xm.dts
>>>> index 5a31964..d394c51 100644
>>>> --- a/arch/arm/boot/dts/omap3-beagle-xm.dts
>>>> +++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
>>>> @@ -57,6 +57,60 @@
>>>>             ti,mcbsp = <&mcbsp2>;
>>>>             ti,codec = <&twl_audio>;
>>>>     };
>>>> +
>>>> +   /* HS USB Port 2 RESET */
>>>> +   hsusb2_reset: hsusb2_reset_reg {
>>>> +           compatible = "regulator-fixed";
>>>> +           regulator-name = "hsusb2_reset";
>>>> +           regulator-min-microvolt = <3300000>;
>>>> +           regulator-max-microvolt = <3300000>;
>>>> +           gpio = <&gpio5 19 0>;   /* gpio_147 */
>>>> +           startup-delay-us = <70000>;
>>>> +           enable-active-high;
>>>> +   };
>>>> +
>>>> +   /* HS USB Port 2 Power */
>>>> +   hsusb2_power: hsusb2_power_reg {
>>>> +           compatible = "regulator-fixed";
>>>> +           regulator-name = "hsusb2_vbus";
>>>> +           regulator-min-microvolt = <3300000>;
>>>> +           regulator-max-microvolt = <3300000>;
>>>> +           gpio = <&twl_gpio 18 0>;        /* GPIO LEDA */
>>>> +           startup-delay-us = <70000>;
>>>> +           enable-active-high;     /* FIXME: active-low for Rev. C */
>>>
>>> Benoit & Tony,
>>>
>>> Any ideas how to tackle the reversed logic for Rev. C boards?
>>
>> Sounds like we need a shared omap3-beage.dtsi, then omap3-beagle-xm.dts
>> and omap3-beagle-rev-c.dts. Then xm and rev-c can both include the
> 
> Bike-sheding, but we might want to make that "omap3-beagle-xmc.dts" as
> there is the "rev c" variant of the original beagle...
> 
> It's too bad we can't read the 3 gpio pin states in the device tree
> and make a decision.

I would recommend to move the detection to the boot loader and
adjust the DT blob at run time (in the boot loader).
This way, we will not need to deal with all the (sub)revision stuff.


-- 
Regards,
Igor.


From andre.przywara at linaro.org  Wed Apr 17 04:01:56 2013
From: andre.przywara at linaro.org (Andre Przywara)
Date: Wed, 17 Apr 2013 10:01:56 +0200
Subject: [PATCH] ARM: KVM: iterate over all CPUs for CPU compatibility
 check
In-Reply-To: <CAEDV+gKbmbdg-xX2Zf5febaeJv5TzLdLZZ5ZrEX9xGc0zsdZQw@mail.gmail.com>
References: <1365771875-5788-1-git-send-email-andre.przywara@linaro.org>
 <51680AF9.7040109@arm.com>
 <CAEDV+g+E8PLc60vMRhq4O_AL2WjmYDLb6=Wh34ynhevh7uAGJA@mail.gmail.com>
 <1366071996.10931.15.camel@smoke>
 <CAEDV+gKbmbdg-xX2Zf5febaeJv5TzLdLZZ5ZrEX9xGc0zsdZQw@mail.gmail.com>
Message-ID: <516E56F4.1070705@linaro.org>

On 04/16/2013 06:24 PM, Christoffer Dall wrote:
> On Mon, Apr 15, 2013 at 5:26 PM, Geoff Levand <geoff at infradead.org> wrote:
>> On Sun, 2013-04-14 at 21:57 -0700, Christoffer Dall wrote:
>>> On Fri, Apr 12, 2013 at 6:24 AM, Marc Zyngier <marc.zyngier at arm.com> wrote:
>>> Nak. The fact that one of the CPUs seem to hang is a sure sign that
>>>> something is severely broken, and you definitely want to fix that issue,
>>>> instead of blindly ignoring it.
>>>>
>>>> Additionally, it seems you're just papering over the issue. You should
>>>> be able to exclude the A7 processors, but not completely deny KVM from
>>>> running on the hardware.
>>>>
>>> Marc, I disagree with this nak. If the current kernel breaks boot on a
>>> Big.Little system, we need to take care of that first, and the
>>> proposed patch is a quick way to do so, and it does not stand in the
>>> way of introducing proper Big.Little support in any way, which I'm
>>> sure is going to open up a lot of other interesting questions.
>>>
>>> I'm going to take this one.
>>
>> Since this problem will cause the 3.9 kernel to hang then a workaround
>> like this should go in.  There isn't enough time to do a proper fix for
>> 3.9, and even if it could be done I think it would be too intrusive to
>> get merged this late.
>>
> That's why I was inclined to take the patch, but as Marc pointed out
> the error message is incorrect, so that should be fixed at the very
> least. Also I don't think we need the counting logic, just bail out if
> we have any CPUs that are not supported.

The counting logic is just to prevent an erroneous hint message. If 
Cluster 0 is A7, the first CPU checked will fail, the counter is 0 and 
KVM outputs the "Target CPU not supported!" message.
But if at least one CPU already passed the test, we have a) a b.L system 
and b) restricting the number of CPUs with maxcpus= would help.
Thus the hint at this point.

But I am OK with removing both the hint message and the counting 
altogether, if you want to have an easier patch.

Regards,
Andre.

> Marc, since you're the strongest opponent of this patch, are you still
> opposed to making sure we don't try to run KVM on Big.Little until
> support is properly introduced?
>
> I also cannot see how we can fix the affinity issue easily from within
> the kernel, do you have a concrete approach in mind you can share?
>
> Note that this is irrespective of the boot delay issue that you guys
> are observing.
>
> -Christoffer
> _______________________________________________
> kvmarm mailing list
> kvmarm at lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
>



From andre.przywara at linaro.org  Wed Apr 17 04:08:12 2013
From: andre.przywara at linaro.org (Andre Przywara)
Date: Wed, 17 Apr 2013 10:08:12 +0200
Subject: [PATCH] ARM: KVM: iterate over all CPUs for CPU compatibility
 check
In-Reply-To: <32d532438f5b621e40679aea9f5888c7@localhost>
References: <51680AF9.7040109@arm.com>
 <CAEDV+g+E8PLc60vMRhq4O_AL2WjmYDLb6=Wh34ynhevh7uAGJA@mail.gmail.com>
 <d455f2823b9639af8d38d30f2c3234bd@localhost>
 <CAEDV+gJuFG49oQ=BEaCHcTP=nHVyX8ALw6076dR_C1s7TuyqXQ@mail.gmail.com>
 <d47697abd39a0d5d41f5ac110a40e261@localhost>
 <CAEDV+gK9==sXYxRVZ8JVFYPiw3_xgzZBbydEwPunmnocNLKXrQ@mail.gmail.com>
 <CAFEAcA-bPoa8YoPuHPmupzfUW+yR233XquK79eNorzcRpFiK=g@mail.gmail.com>
 <516BCAD0.9000708@linaro.org>
 <CAJRNFKJoBzgt4UhxsH65_LyhcGXPnzB_pg3q-zeYT2OVv59q4A@mail.gmail.com>
 <516BFD13.1000400@linaro.org>
 <20130415134837.GI9827@mudshark.cambridge.arm.com>
 <CAEDV+gJB7Bj9O7pftFqoYQ=goORjdurBnEfQVmC5arDuNJfpBg@mail.gmail.com>
 <32d532438f5b621e40679aea9f5888c7@localhost>
Message-ID: <516E586C.5030407@linaro.org>

On 04/16/2013 06:33 PM, Marc Zyngier wrote:
> On Tue, 16 Apr 2013 09:26:26 -0700, Christoffer Dall
> <cdall at cs.columbia.edu> wrote:
>> On Mon, Apr 15, 2013 at 6:48 AM, Will Deacon <will.deacon at arm.com>
> wrote:
>>> On Mon, Apr 15, 2013 at 02:13:55PM +0100, Andre Przywara wrote:
>>>> On 04/15/2013 11:52 AM, Alexander Spyridakis wrote:
>>>>> I've run on this problem before, while trying to run KVM guests on
> A7
>>>>> cores.
>>>>>
>>>>> For some reason the 3rd A7 hangs in arch/arm/kvm/init.S, on the
>>>>> instruction that updates HSCTLR between the two isbs on
> __do_hyp_init
>>>>> (mcr p15, 4, r0, c1, c0, 0). If you boot the system with maxcpus=4
>>>>> then
>>>>> init_hyp_mode() will not hang on the A7 cluster. Other than that
> from
>>>>> my
>>>>> limited testing KVM on A7 works on a usual linux guest. I also tried
>>>>> to
>>>>> only boot the 3rd A7 core to rule out any racing issues, but still
> the
>>>>> same behaviour applies.
>>>>
>>>> Could well be the same issue here. I chased it down till CPU 2 goes
> into
>>>> HYP mode to do the initialization.
>>>> I am running with maxcpus=3 (this increases the likelyhood that
>>>> kvm_target_cpu() runs on an A15), so CPU #2 is the only one A7.
>>>> As the HYP mode exception table is empty except for the HVC trap, it
> may
>>>> be looping here. I am trying now to get the PC of the faulty
>>>> instruction.
>>>
>>> Yes, it sounds like you're taking a recursive fault because the vectors
>>> aren't installed yet. Is there any chance you can find out what value
>>> you end
>>> up writing (or trying to write) to the HSCTLR please?
>>>
>> Actually I'm a little confused, wasn't Andre seeing a halt on an A15
>> cpu, not an A7? Or is the theory that an A7 locks up and the calling
>> A15 hangs on the SMP call to cpu_init_hyp_mode, waiting for the A7 to
>> complete?
>
> Yes, A15 hanging, not A7. That's why I'm strongly opposed to this patch.
> I'm pretty sure the A7s only have a side effect that triggers a kernel bug
> on the A15 side. Before taking *any* patch around this, we should
> understand the issue fully, and not start patching random stuff just
> because Linus is going to tag 3.9.

I think there is a misunderstanding. The RCU watchdog was complaining 
because the A15 wasn't making any progress. As Christoffer said, this is 
because it was waiting for CPU 2 to return from the SMP call. It is 
actually the A7 hanging inside HYP mode.
I tried some ways to get information out of there, but had no luck so 
far. The different mapping between HYP and SVC doesn't make it easy to 
dump some variables, but I am still working on it (but only half steam 
because I am home looking after my sick daughter). So for now I assume 
that it is the HSCTLR setting Alexander observed already.

Regards,
Andre.




From dirk.behme at de.bosch.com  Wed Apr 17 04:11:29 2013
From: dirk.behme at de.bosch.com (Dirk Behme)
Date: Wed, 17 Apr 2013 10:11:29 +0200
Subject: [PATCH] ARM i.MX6q: Fix periph_clk2_sel and periph2_clk2_sel
 clocks
In-Reply-To: <1365757419.5330.17.camel@pizza.hi.pengutronix.de>
References: <1365675812-21600-1-git-send-email-p.zabel@pengutronix.de>
 <20130412030228.GF16970@S2101-09.ap.freescale.net>
 <1365757419.5330.17.camel@pizza.hi.pengutronix.de>
Message-ID: <516E5931.5010904@de.bosch.com>

On 12.04.2013 11:03, Philipp Zabel wrote:
> Am Freitag, den 12.04.2013, 11:02 +0800 schrieb Shawn Guo:
>> On Thu, Apr 11, 2013 at 12:23:32PM +0200, Philipp Zabel wrote:
>>> The periph_clk2_sel mux can be set to pll3, pll1, or
>>> osc/pll2-bypass/pll2_burn_in_clk.
>> Looking at IMX6DQRM Rev. 0, 11/2012, I see
>>
>> 13?12 periph_clk2_sel: Selector for peripheral clk2 clock multiplexer
>>
>> 	00 derive clock from pll3_sw_clk
>> 	01 derive clock from pll1_ref_clk
>> 	10 derive clock from pll2_burn_in_clk (default)
>> 	11 reserved
>>
>> Are you sure pll1_ref_clk actually means pll1_sys?
> 
> No, pll1_sys indeed is pll1_sw_clk, not pll1_ref_clk.
> 
>> I searched the
>> document and word "pll1_ref_clk" occurs only once.  But Figure 18-5. BUS
>> clock generation on page 819 suggests it's OSC_CLK (24M).
> 
> This is consistent (24 MHz osc is the pll1 reference), and thus might be
> correct. I'll fix the patch to keep periph_clk2_sels[1] = "osc".

Any update on this?

Thanks

Dirk

> regards
> Philipp
> 
>>> The periph2_clk2_sel
>>> mux can be set to pll3 or pll2.
>>>
>>> Signed-off-by: Philipp Zabel <p.zabel at pengutronix.de>
>>> ---
>>>  arch/arm/mach-imx/clk-imx6q.c | 7 ++++---
>>>  1 file changed, 4 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-imx/clk-imx6q.c b/arch/arm/mach-imx/clk-imx6q.c
>>> index 65319d5..bdeddf3 100644
>>> --- a/arch/arm/mach-imx/clk-imx6q.c
>>> +++ b/arch/arm/mach-imx/clk-imx6q.c
>>> @@ -177,7 +177,8 @@ int imx6q_set_lpm(enum mxc_cpu_pwr_mode mode)
>>>  static const char *step_sels[]	= { "osc", "pll2_pfd2_396m", };
>>>  static const char *pll1_sw_sels[]	= { "pll1_sys", "step", };
>>>  static const char *periph_pre_sels[]	= { "pll2_bus", "pll2_pfd2_396m", "pll2_pfd0_352m", "pll2_198m", };
>>> -static const char *periph_clk2_sels[]	= { "pll3_usb_otg", "osc", };
>>> +static const char *periph_clk2_sels[]	= { "pll3_usb_otg", "pll1_sys", "osc", "dummy", };
>>> +static const char *periph2_clk2_sels[]	= { "pll3_usb_otg", "pll2_bus", };
>>>  static const char *periph_sels[]	= { "periph_pre", "periph_clk2", };
>>>  static const char *periph2_sels[]	= { "periph2_pre", "periph2_clk2", };
>>>  static const char *axi_sels[]		= { "periph", "pll2_pfd2_396m", "pll3_pfd1_540m", };
>>> @@ -369,8 +370,8 @@ int __init mx6q_clocks_init(void)
>>>  	clk[pll1_sw]          = imx_clk_mux("pll1_sw",	        base + 0xc,  2,  1, pll1_sw_sels,      ARRAY_SIZE(pll1_sw_sels));
>>>  	clk[periph_pre]       = imx_clk_mux("periph_pre",       base + 0x18, 18, 2, periph_pre_sels,   ARRAY_SIZE(periph_pre_sels));
>>>  	clk[periph2_pre]      = imx_clk_mux("periph2_pre",      base + 0x18, 21, 2, periph_pre_sels,   ARRAY_SIZE(periph_pre_sels));
>>> -	clk[periph_clk2_sel]  = imx_clk_mux("periph_clk2_sel",  base + 0x18, 12, 1, periph_clk2_sels,  ARRAY_SIZE(periph_clk2_sels));
>>> -	clk[periph2_clk2_sel] = imx_clk_mux("periph2_clk2_sel", base + 0x18, 20, 1, periph_clk2_sels,  ARRAY_SIZE(periph_clk2_sels));
>>> +	clk[periph_clk2_sel]  = imx_clk_mux("periph_clk2_sel",  base + 0x18, 12, 2, periph_clk2_sels,  ARRAY_SIZE(periph_clk2_sels));
>>> +	clk[periph2_clk2_sel] = imx_clk_mux("periph2_clk2_sel", base + 0x18, 20, 1, periph2_clk2_sels, ARRAY_SIZE(periph2_clk2_sels));
>>>  	clk[axi_sel]          = imx_clk_mux("axi_sel",          base + 0x14, 6,  2, axi_sels,          ARRAY_SIZE(axi_sels));
>>>  	clk[esai_sel]         = imx_clk_mux("esai_sel",         base + 0x20, 19, 2, audio_sels,        ARRAY_SIZE(audio_sels));
>>>  	clk[asrc_sel]         = imx_clk_mux("asrc_sel",         base + 0x30, 7,  2, audio_sels,        ARRAY_SIZE(audio_sels));
>>> -- 
>>> 1.8.2.rc2
>>>
>>


From marc.zyngier at arm.com  Wed Apr 17 04:16:55 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 17 Apr 2013 10:16:55 +0200
Subject: [PATCH] ARM: KVM: iterate over all CPUs for CPU compatibility
 check
In-Reply-To: <516E586C.5030407@linaro.org>
References: <51680AF9.7040109@arm.com>
 <CAEDV+g+E8PLc60vMRhq4O_AL2WjmYDLb6=Wh34ynhevh7uAGJA@mail.gmail.com>
 <d455f2823b9639af8d38d30f2c3234bd@localhost>
 <CAEDV+gJuFG49oQ=BEaCHcTP=nHVyX8ALw6076dR_C1s7TuyqXQ@mail.gmail.com>
 <d47697abd39a0d5d41f5ac110a40e261@localhost>
 <CAEDV+gK9==sXYxRVZ8JVFYPiw3_xgzZBbydEwPunmnocNLKXrQ@mail.gmail.com>
 <CAFEAcA-bPoa8YoPuHPmupzfUW+yR233XquK79eNorzcRpFiK=g@mail.gmail.com>
 <516BCAD0.9000708@linaro.org>
 <CAJRNFKJoBzgt4UhxsH65_LyhcGXPnzB_pg3q-zeYT2OVv59q4A@mail.gmail.com>
 <516BFD13.1000400@linaro.org>
 <20130415134837.GI9827@mudshark.cambridge.arm.com>
 <CAEDV+gJB7Bj9O7pftFqoYQ=goORjdurBnEfQVmC5arDuNJfpBg@mail.gmail.com>
 <32d532438f5b621e40679aea9f5888c7@localhost> <516E586C.5030407@linaro.org>
Message-ID: <8e0bda3fd84d1b0c5aa55161ca178a8e@localhost>

On Wed, 17 Apr 2013 10:08:12 +0200, Andre Przywara
<andre.przywara at linaro.org> wrote:
> On 04/16/2013 06:33 PM, Marc Zyngier wrote:
>> On Tue, 16 Apr 2013 09:26:26 -0700, Christoffer Dall
>> <cdall at cs.columbia.edu> wrote:
>>> On Mon, Apr 15, 2013 at 6:48 AM, Will Deacon <will.deacon at arm.com>
>> wrote:
>>>> On Mon, Apr 15, 2013 at 02:13:55PM +0100, Andre Przywara wrote:
>>>>> On 04/15/2013 11:52 AM, Alexander Spyridakis wrote:
>>>>>> I've run on this problem before, while trying to run KVM guests on
>> A7
>>>>>> cores.
>>>>>>
>>>>>> For some reason the 3rd A7 hangs in arch/arm/kvm/init.S, on the
>>>>>> instruction that updates HSCTLR between the two isbs on
>> __do_hyp_init
>>>>>> (mcr p15, 4, r0, c1, c0, 0). If you boot the system with maxcpus=4
>>>>>> then
>>>>>> init_hyp_mode() will not hang on the A7 cluster. Other than that
>> from
>>>>>> my
>>>>>> limited testing KVM on A7 works on a usual linux guest. I also
tried
>>>>>> to
>>>>>> only boot the 3rd A7 core to rule out any racing issues, but still
>> the
>>>>>> same behaviour applies.
>>>>>
>>>>> Could well be the same issue here. I chased it down till CPU 2 goes
>> into
>>>>> HYP mode to do the initialization.
>>>>> I am running with maxcpus=3 (this increases the likelyhood that
>>>>> kvm_target_cpu() runs on an A15), so CPU #2 is the only one A7.
>>>>> As the HYP mode exception table is empty except for the HVC trap, it
>> may
>>>>> be looping here. I am trying now to get the PC of the faulty
>>>>> instruction.
>>>>
>>>> Yes, it sounds like you're taking a recursive fault because the
vectors
>>>> aren't installed yet. Is there any chance you can find out what value
>>>> you end
>>>> up writing (or trying to write) to the HSCTLR please?
>>>>
>>> Actually I'm a little confused, wasn't Andre seeing a halt on an A15
>>> cpu, not an A7? Or is the theory that an A7 locks up and the calling
>>> A15 hangs on the SMP call to cpu_init_hyp_mode, waiting for the A7 to
>>> complete?
>>
>> Yes, A15 hanging, not A7. That's why I'm strongly opposed to this
patch.
>> I'm pretty sure the A7s only have a side effect that triggers a kernel
>> bug
>> on the A15 side. Before taking *any* patch around this, we should
>> understand the issue fully, and not start patching random stuff just
>> because Linus is going to tag 3.9.
> 
> I think there is a misunderstanding. The RCU watchdog was complaining 
> because the A15 wasn't making any progress. As Christoffer said, this is

> because it was waiting for CPU 2 to return from the SMP call. It is 
> actually the A7 hanging inside HYP mode.
> I tried some ways to get information out of there, but had no luck so 
> far. The different mapping between HYP and SVC doesn't make it easy to 
> dump some variables, but I am still working on it (but only half steam 

You could force a full mapping of the kernel text in HYP. Ugly, but should
work.

> because I am home looking after my sick daughter). So for now I assume 
> that it is the HSCTLR setting Alexander observed already.

I'll give it a go today or tomorrow, depending how quickly I can get rid
of my backlog after a couple of days off work.

Assuming this is an A7 handing on HSCTLR access, it should be pretty easy
to narrow down by booting only on the A7s, leaving the A15s held in reset.

        M.
-- 
Fast, cheap, reliable. Pick two.


From arnd at arndb.de  Mon Apr 15 17:20:28 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 15 Apr 2013 23:20:28 +0200
Subject: [GIT PULL] Timer clean-ups for 3.10, Part 2
In-Reply-To: <516C0257.8040103@gmail.com>
References: <516720B4.3000703@gmail.com>
 <20130413065056.GB14735@quad.lixom.net> <516C0257.8040103@gmail.com>
Message-ID: <201304152320.28401.arnd@arndb.de>

On Monday 15 April 2013, Rob Herring wrote:
> It is quite messed up because the mct timer changes are not based on
> arm-soc/clksrc/cleanup. Any timer changes adding CLKSRC_OF support need
> to be based on this. I've fixed it up in this branch (untested):
> 
> git://sources.calxeda.com/kernel/linux.git exynos-mct-merge
> 
> I merged with clksrc-cleanup-for-3.10-part2 and fixed it in the merge,
> but really either the mct branch should be rebased or some of the
> changes can be a preparatory commit before merging.

Note that I also merged the branches when pulling in the samsung changes,
and did a complex merge there. We should ensure that we use the same
merge here.

	Arnd


From rogerq at ti.com  Wed Apr 17 04:38:54 2013
From: rogerq at ti.com (Roger Quadros)
Date: Wed, 17 Apr 2013 11:38:54 +0300
Subject: [PATCH] ARM: dts: omap3-beagle-xm: Add USB Host support for Rev
 Ax/Bx
In-Reply-To: <516E5597.7050801@compulab.co.il>
References: <1366029306-1824-1-git-send-email-rogerq@ti.com>
 <516BF4F3.5060904@ti.com> <20130417005232.GV10155@atomide.com>
 <CAOCHtYgFnCy5Qn2LeJOK96_NdwzxzVe8Vrb8cL=K9AdzPUtQow@mail.gmail.com>
 <516E5597.7050801@compulab.co.il>
Message-ID: <516E5F9E.3050204@ti.com>

On 04/17/2013 10:56 AM, Igor Grinberg wrote:
> On 04/17/13 04:30, Robert Nelson wrote:
>> On Tue, Apr 16, 2013 at 7:52 PM, Tony Lindgren <tony at atomide.com> wrote:
>>> * Roger Quadros <rogerq at ti.com> [130415 05:44]:
>>>> On 04/15/2013 03:35 PM, Roger Quadros wrote:
>>>>> Provide RESET and Power regulators for the USB PHY,
>>>>> the USB Host port mode and the PHY device.
>>>>>
>>>>> Also provide pin multiplexer information for USB host
>>>>> pins.
>>>>>
>>>>> This will not work for Rev Cx boards because of reversed logic
>>>>> for USB_POWER_Enable.
>>>>>
>>>>> CC: Beno?t Cousson <b-cousson at ti.com>
>>>>> Signed-off-by: Roger Quadros <rogerq at ti.com>
>>>>> ---
>>>>>  arch/arm/boot/dts/omap3-beagle-xm.dts |   62 +++++++++++++++++++++++++++++++++
>>>>>  1 files changed, 62 insertions(+), 0 deletions(-)
>>>>>
>>>>> diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts b/arch/arm/boot/dts/omap3-beagle-xm.dts
>>>>> index 5a31964..d394c51 100644
>>>>> --- a/arch/arm/boot/dts/omap3-beagle-xm.dts
>>>>> +++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
>>>>> @@ -57,6 +57,60 @@
>>>>>             ti,mcbsp = <&mcbsp2>;
>>>>>             ti,codec = <&twl_audio>;
>>>>>     };
>>>>> +
>>>>> +   /* HS USB Port 2 RESET */
>>>>> +   hsusb2_reset: hsusb2_reset_reg {
>>>>> +           compatible = "regulator-fixed";
>>>>> +           regulator-name = "hsusb2_reset";
>>>>> +           regulator-min-microvolt = <3300000>;
>>>>> +           regulator-max-microvolt = <3300000>;
>>>>> +           gpio = <&gpio5 19 0>;   /* gpio_147 */
>>>>> +           startup-delay-us = <70000>;
>>>>> +           enable-active-high;
>>>>> +   };
>>>>> +
>>>>> +   /* HS USB Port 2 Power */
>>>>> +   hsusb2_power: hsusb2_power_reg {
>>>>> +           compatible = "regulator-fixed";
>>>>> +           regulator-name = "hsusb2_vbus";
>>>>> +           regulator-min-microvolt = <3300000>;
>>>>> +           regulator-max-microvolt = <3300000>;
>>>>> +           gpio = <&twl_gpio 18 0>;        /* GPIO LEDA */
>>>>> +           startup-delay-us = <70000>;
>>>>> +           enable-active-high;     /* FIXME: active-low for Rev. C */
>>>>
>>>> Benoit & Tony,
>>>>
>>>> Any ideas how to tackle the reversed logic for Rev. C boards?
>>>
>>> Sounds like we need a shared omap3-beage.dtsi, then omap3-beagle-xm.dts
>>> and omap3-beagle-rev-c.dts. Then xm and rev-c can both include the
>>
>> Bike-sheding, but we might want to make that "omap3-beagle-xmc.dts" as
>> there is the "rev c" variant of the original beagle...
>>
>> It's too bad we can't read the 3 gpio pin states in the device tree
>> and make a decision.
> 
> I would recommend to move the detection to the boot loader and
> adjust the DT blob at run time (in the boot loader).
> This way, we will not need to deal with all the (sub)revision stuff.
> 
> 
Moving the detection to bootloader is fine, but modifying the DT at
runtime would create a debug/maintenance issue. Instead it could just
pick one of the .DTBs and pass it to kernel.

Since most users will be using rev-c, I think we should keep the original
file 'omap3-beagle-xm.dts" as it is for rev-c boards.
I can just create a new dts file for Revisions A and B that will be
like so.

+++ b/arch/arm/boot/dts/omap3-beagle-xm-ab.dts
@@ -0,0 +1,6 @@
+/include/ "omap3-beagle-xm.dts"
+
+/* On Rev A/B USBHOST_PWR_EN is active high */
+&hsusb2_power {
+       enable-active-high;
+};

Since omap3-beagle and omap3-beagle-xm use different SoC versions and have
quite many differences, I don't think it is a good idea to create a common
file between the two.

cheers,
-roger


From fabio.porcedda at gmail.com  Wed Apr 17 04:39:46 2013
From: fabio.porcedda at gmail.com (Fabio Porcedda)
Date: Wed, 17 Apr 2013 10:39:46 +0200
Subject: [PATCH v2 0/7] pcmcia: at91_cf: clean up and add DT support
In-Reply-To: <cover.1363865228.git.nicolas.ferre@atmel.com>
References: <cover.1363865228.git.nicolas.ferre@atmel.com>
Message-ID: <CAHkwnC-aL=G9K9jttjD8Bk_ZKJ535vsGT26uCFbuFMeJUquYQw@mail.gmail.com>

On Thu, Mar 21, 2013 at 12:40 PM, Nicolas Ferre <nicolas.ferre at atmel.com> wrote:
> These patches clean up at91_cf a bit and add DT bindings.
> It is based on a previous series from Joachim Eastwood and other cleanup
> patches by Fabio and Laurent.
> I have collected them together as they are lying around for some time.
>
> Please tell me if It can go through PCMCIA tree or if Andrew or Greg can
> take them.
> Note that they are not bug fixes, so you can stack them for 3.10.
>
> Thanks for your help, best regards.
>
> v2: add 2 more cleanup patches:
>         - move to module_platform_driver_probe()
>         - little trivial indentation fix
>
> Fabio Porcedda (1):
>   pcmcia: at91_cf: use module_platform_driver_probe()
>
> Joachim Eastwood (5):
>   pcmcia: at91_cf: fix gpio_get_value in at91_cf_get_status
>   pcmcia: at91_cf: convert to dev_ print functions
>   pcmcia: at91_cf: use devm_ functions for allocations
>   pcmcia: at91_cf: clean up header includes
>   pcmcia: at91_cf: add support for DT
>
> Laurent Navet (1):
>   pcmcia/trivial: at91_cf: fix checkpatch error
>
>  .../devicetree/bindings/ata/atmel-at91_cf.txt      |  19 +++
>  drivers/pcmcia/Kconfig                             |   2 +-
>  drivers/pcmcia/at91_cf.c                           | 176 ++++++++++-----------
>  3 files changed, 108 insertions(+), 89 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/ata/atmel-at91_cf.txt
>
> --
> 1.8.0
>

Ping?

Regards
--
Fabio Porcedda


From nicolas.ferre at atmel.com  Wed Apr 17 04:51:23 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Wed, 17 Apr 2013 10:51:23 +0200
Subject: [PATCH v2 0/7] pcmcia: at91_cf: clean up and add DT support
In-Reply-To: <CAHkwnC-aL=G9K9jttjD8Bk_ZKJ535vsGT26uCFbuFMeJUquYQw@mail.gmail.com>
References: <cover.1363865228.git.nicolas.ferre@atmel.com>
 <CAHkwnC-aL=G9K9jttjD8Bk_ZKJ535vsGT26uCFbuFMeJUquYQw@mail.gmail.com>
Message-ID: <516E628B.1000104@atmel.com>

On 04/17/2013 10:39 AM, Fabio Porcedda :
> On Thu, Mar 21, 2013 at 12:40 PM, Nicolas Ferre <nicolas.ferre at atmel.com> wrote:
>> These patches clean up at91_cf a bit and add DT bindings.
>> It is based on a previous series from Joachim Eastwood and other cleanup
>> patches by Fabio and Laurent.
>> I have collected them together as they are lying around for some time.
>>
>> Please tell me if It can go through PCMCIA tree or if Andrew or Greg can
>> take them.
>> Note that they are not bug fixes, so you can stack them for 3.10.
>>
>> Thanks for your help, best regards.
>>
>> v2: add 2 more cleanup patches:
>>         - move to module_platform_driver_probe()
>>         - little trivial indentation fix
>>
>> Fabio Porcedda (1):
>>   pcmcia: at91_cf: use module_platform_driver_probe()
>>
>> Joachim Eastwood (5):
>>   pcmcia: at91_cf: fix gpio_get_value in at91_cf_get_status
>>   pcmcia: at91_cf: convert to dev_ print functions
>>   pcmcia: at91_cf: use devm_ functions for allocations
>>   pcmcia: at91_cf: clean up header includes
>>   pcmcia: at91_cf: add support for DT
>>
>> Laurent Navet (1):
>>   pcmcia/trivial: at91_cf: fix checkpatch error
>>
>>  .../devicetree/bindings/ata/atmel-at91_cf.txt      |  19 +++
>>  drivers/pcmcia/Kconfig                             |   2 +-
>>  drivers/pcmcia/at91_cf.c                           | 176 ++++++++++-----------
>>  3 files changed, 108 insertions(+), 89 deletions(-)
>>  create mode 100644 Documentation/devicetree/bindings/ata/atmel-at91_cf.txt
>>
>> --
>> 1.8.0
>>
> 
> Ping?

Andrew, Greg, can you please take this series?

Here is the post on lkml:
https://lkml.org/lkml/2013/3/21/246

Here is the first patch in patchwork (1/7):
https://patchwork.kernel.org/patch/2312691/

Tell me if I can do something else to make this applied upstream...

Best regards,
-- 
Nicolas Ferre


From gang.chen at asianux.com  Wed Apr 17 05:10:17 2013
From: gang.chen at asianux.com (Chen Gang)
Date: Wed, 17 Apr 2013 17:10:17 +0800
Subject: [Suggestion] ARM64:kernel: compiling issue for early_console.
In-Reply-To: <515C2808.70406@asianux.com>
References: <5152DB83.8080703@asianux.com>
 <20130327115509.GA1603@MacBook-Pro.local> <5152DFF1.2090000@asianux.com>
 <515BE49C.8040601@asianux.com> <515C14FD.4040703@codeaurora.org>
 <515C2808.70406@asianux.com>
Message-ID: <516E66F9.9070904@asianux.com>

On 2013?04?03? 21:00, Chen Gang wrote:
> On 2013?04?03? 19:39, Christopher Covington wrote:
>> Maybe somebody else does have a fix, but Catalin mentioned he was going on
>> vacation for two weeks on March 28th in "[GIT PULL] Preparatory GIC patches
>> for arm64 support".
>>
>   ok, I can wait.
> 

  could you have time to fix it ? (if have no time, I should fix it).


  thanks.


>>>>   if really no one fix it within this week, I should try (since I find it).
>> I'm sure a fix would be appreciated.
>>
> 
>   ok, thanks. I prefer to wait (at least for the end of Catalin's vacation).
> 
> 
>>>> On 2013?03?27? 20:02, Chen Gang wrote:
>>>>>> On 2013?03?27? 19:55, Catalin Marinas wrote:
>>>>>>>>
>>>>>>>> I saw some patches from tglx on unifying the various early printk
>>>>>>>> implementations, though not sure whether it's those patches causing it
>>>>>>>> (in which case arm64 needs to be updated as well).
>> I looked briefly and wasn't able to find this patchset.
> 
>   ok, thank for your results.
> 
> 


-- 
Chen Gang

Asianux Corporation


From mark.rutland at arm.com  Wed Apr 17 05:14:58 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Wed, 17 Apr 2013 10:14:58 +0100
Subject: [RFC PATCH 2/2] ARM: DT: kernel: DT cpu node bindings update
In-Reply-To: <516C544A.4090107@wwwdotorg.org>
References: <1366042402-8987-1-git-send-email-lorenzo.pieralisi@arm.com>
 <1366042402-8987-3-git-send-email-lorenzo.pieralisi@arm.com>
 <516C544A.4090107@wwwdotorg.org>
Message-ID: <20130417091457.GB5012@e106331-lin.cambridge.arm.com>

Hi Stephen,

> > +	- enable-method
> > +		Usage: required on ARM 64-bit systems, optional on ARM 32-bit
> > +		       systems
> > +		Value type: <string>
> > +		Definition: On ARM 64-bit systems must be "spin-table" [1].
> 
> Can that be an integer instead? with dtc+cpp support, that shouldn't
> hurt the eyes too much any more.

The "enable-method" property is described as a stringlist by ePAPR, and is
currently in use on arm64 as such. It *must* remain a string(list) for arm64.

Having it as an integer for arm is only going to cause us additional work,
makes it impossible to share a common dt between 64bit and 32bit, and goes
against the standard. I think it should be a stringlist for arm.

> 
> > +	- cpu-release-addr
> > +		Usage: required on ARM 64-bit systems, optional on ARM 32-bit
> > +		       systems
> > +		Value type: <prop-encoded-array>
> > +		Definition: On ARM 64-bit systems must be a two cell
> > +			    property identifying a 64-bit zero-initialised
> > +			    memory location [1].
> 
> Presumably that property is required, or not, based on the value of
> enable-method, not based on the ARM architecture or bit-size?

This should be required if the enable-method depends on it. In ePAPR, it's
specified it should be there if the enable-method is "spin-table". We have
(undocumented) PSCI support on arm64 which doesn't require a cpu-release-addr.

> 
> > +[1] ARM Linux kernel documentation
> > +    Documentation/devicetree/bindings/arm64/booting.txt
> 
> Is referencing Linux-specific documentation from a supposedly
> OS-agnostic DT binding definition a good idea?

Once we have the enable-method(s) and their required properties here, we can
invert the dependency and refer to the binding from the Linux documentation.

Mark.


From gang.chen at asianux.com  Wed Apr 17 05:25:34 2013
From: gang.chen at asianux.com (Chen Gang)
Date: Wed, 17 Apr 2013 17:25:34 +0800
Subject: [Suggestion] ARM:S5pv210: compiling issue for s5pv210 by using
 randconfig
In-Reply-To: <515C047A.9010906@asianux.com>
References: <514FB202.3040807@asianux.com> <515BFA8D.2000204@asianux.com>
 <20130403101018.GE11040@mudshark.cambridge.arm.com>
 <515C047A.9010906@asianux.com>
Message-ID: <516E6A8E.3000001@asianux.com>

On 2013?04?03? 18:29, Chen Gang wrote:
> On 2013?04?03? 18:10, Will Deacon wrote:
>> I think the main problem is that you've reported an issue created from a
>> randconfig, but you haven't made the config in question available.
> 
>   excuse me, my English is not quite well.
> 
>   I guess your meaning is :
>     I need also provide the related .config file in this mail.
>     so we can be more easier to find the root cause.
> 
>   is it correct ?
> 
> 
>   BTW:
>     unlucky, the original .config has been deleted.
>     I can try to reproduce it, so let us to fix it with more efficiency.
> 
>   thanks.
> 

Hello Will Deacon:

  I repeat it again (but it report another location), and put the config as attachment.

  when you have time, please help check (if you have no time, I should try)

  the below is the new related information:

  thanks.


  make:
    make V=1 EXTRA_CFLAGS=-W ARCH=arm randconfig
    make V=1 EXTRA_CFLAGS=-W ARCH=arm menuconfig
      set arm-linux-gnu-  for "Cross-compiler tool prefix"
      set "Samsung S5PV210/S5PC210" for "ARM system type"
    make V=1 EXTRA_CFLAGS=-W ARCH=arm


  compiling info:

arm-linux-gnu-gcc -Wp,-MD,arch/arm/vfp/.vfphw.o.d  -nostdinc -isystem /usr/lib/gcc/arm-linux-gnueabi/4.7.1/include -I/root/linux-next/arch/arm/include -Iarch/arm/include/generated  -Iinclude -I/root/linux-next/arch/arm/include/uapi -Iarch/arm/include/generated/uapi -I/root/linux-next/include/uapi -Iinclude/generated/uapi -include /root/linux-next/include/linux/kconfig.h -D__KERNEL__ -mlittle-endian -Iarch/arm/mach-s5pv210/include -Iarch/arm/plat-samsung/include  -D__ASSEMBLY__ -mabi=apcs-gnu -mno-thumb-interwork -marm -D__LINUX_ARM_ARCH__=4 -march=armv4t -mtune=arm9tdmi -include asm/unified.h -Wa,-mfpu=softvfp+vfp -mfloat-abi=soft        -c -o arch/arm/vfp/vfphw.o arch/arm/vfp/vfphw.S


  compiling err:

arch/arm/vfp/vfphw.S: Assembler messages:
arch/arm/vfp/vfphw.S:295: Error: selected processor does not support ARM mode `mrrc p11,3,r0,r1,c0'
arch/arm/vfp/vfphw.S:295: Error: selected processor does not support ARM mode `mrrc p11,3,r0,r1,c1'
arch/arm/vfp/vfphw.S:295: Error: selected processor does not support ARM mode `mrrc p11,3,r0,r1,c2'
arch/arm/vfp/vfphw.S:295: Error: selected processor does not support ARM mode `mrrc p11,3,r0,r1,c3'
arch/arm/vfp/vfphw.S:295: Error: selected processor does not support ARM mode `mrrc p11,3,r0,r1,c4'
arch/arm/vfp/vfphw.S:295: Error: selected processor does not support ARM mode `mrrc p11,3,r0,r1,c5'
arch/arm/vfp/vfphw.S:295: Error: selected processor does not support ARM mode `mrrc p11,3,r0,r1,c6'
arch/arm/vfp/vfphw.S:295: Error: selected processor does not support ARM mode `mrrc p11,3,r0,r1,c7'
arch/arm/vfp/vfphw.S:295: Error: selected processor does not support ARM mode `mrrc p11,3,r0,r1,c8'
arch/arm/vfp/vfphw.S:295: Error: selected processor does not support ARM mode `mrrc p11,3,r0,r1,c9'
arch/arm/vfp/vfphw.S:295: Error: selected processor does not support ARM mode `mrrc p11,3,r0,r1,c10'
arch/arm/vfp/vfphw.S:295: Error: selected processor does not support ARM mode `mrrc p11,3,r0,r1,c11'
arch/arm/vfp/vfphw.S:295: Error: selected processor does not support ARM mode `mrrc p11,3,r0,r1,c12'
arch/arm/vfp/vfphw.S:295: Error: selected processor does not support ARM mode `mrrc p11,3,r0,r1,c13'
arch/arm/vfp/vfphw.S:295: Error: selected processor does not support ARM mode `mrrc p11,3,r0,r1,c14'
arch/arm/vfp/vfphw.S:295: Error: selected processor does not support ARM mode `mrrc p11,3,r0,r1,c15'
arch/arm/vfp/vfphw.S:317: Error: selected processor does not support ARM mode `mcrr p11,3,r0,r1,c0'
arch/arm/vfp/vfphw.S:317: Error: selected processor does not support ARM mode `mcrr p11,3,r0,r1,c1'
arch/arm/vfp/vfphw.S:317: Error: selected processor does not support ARM mode `mcrr p11,3,r0,r1,c2'
arch/arm/vfp/vfphw.S:317: Error: selected processor does not support ARM mode `mcrr p11,3,r0,r1,c3'
arch/arm/vfp/vfphw.S:317: Error: selected processor does not support ARM mode `mcrr p11,3,r0,r1,c4'
arch/arm/vfp/vfphw.S:317: Error: selected processor does not support ARM mode `mcrr p11,3,r0,r1,c5'
arch/arm/vfp/vfphw.S:317: Error: selected processor does not support ARM mode `mcrr p11,3,r0,r1,c6'
arch/arm/vfp/vfphw.S:317: Error: selected processor does not support ARM mode `mcrr p11,3,r0,r1,c7'
arch/arm/vfp/vfphw.S:317: Error: selected processor does not support ARM mode `mcrr p11,3,r0,r1,c8'
arch/arm/vfp/vfphw.S:317: Error: selected processor does not support ARM mode `mcrr p11,3,r0,r1,c9'
arch/arm/vfp/vfphw.S:317: Error: selected processor does not support ARM mode `mcrr p11,3,r0,r1,c10'
arch/arm/vfp/vfphw.S:317: Error: selected processor does not support ARM mode `mcrr p11,3,r0,r1,c11'
arch/arm/vfp/vfphw.S:317: Error: selected processor does not support ARM mode `mcrr p11,3,r0,r1,c12'
arch/arm/vfp/vfphw.S:317: Error: selected processor does not support ARM mode `mcrr p11,3,r0,r1,c13'
arch/arm/vfp/vfphw.S:317: Error: selected processor does not support ARM mode `mcrr p11,3,r0,r1,c14'
arch/arm/vfp/vfphw.S:317: Error: selected processor does not support ARM mode `mcrr p11,3,r0,r1,c15'
make[1]: *** [arch/arm/vfp/vfphw.o] Error 1
make: *** [arch/arm/vfp] Error 2





-- 
Chen Gang

Asianux Corporation
-------------- next part --------------
#
# Automatically generated file; DO NOT EDIT.
# Linux/arm 3.9.0-rc7 Kernel Configuration
#
CONFIG_ARM=y
CONFIG_SYS_SUPPORTS_APM_EMULATION=y
CONFIG_HAVE_PROC_CPU=y
CONFIG_NO_IOPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_RWSEM_GENERIC_SPINLOCK=y
CONFIG_ARCH_HAS_CPUFREQ=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_VECTORS_BASE=0x00000000
CONFIG_NEED_MACH_GPIO_H=y
CONFIG_NEED_MACH_MEMORY_H=y
CONFIG_GENERIC_BUG=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y

#
# General setup
#
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE="arm-linux-gnu-"
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
# CONFIG_KERNEL_GZIP is not set
CONFIG_KERNEL_LZMA=y
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
# CONFIG_SYSVIPC is not set
CONFIG_POSIX_MQUEUE=y
# CONFIG_FHANDLE is not set
CONFIG_AUDIT=y
# CONFIG_AUDIT_LOGINUID_IMMUTABLE is not set
CONFIG_HAVE_GENERIC_HARDIRQS=y

#
# IRQ subsystem
#
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_HARDIRQS_SW_RESEND=y
CONFIG_GENERIC_IRQ_CHIP=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_DOMAIN_DEBUG=y
# CONFIG_ALWAYS_USE_PERSISTENT_CLOCK is not set
CONFIG_KTIME_SCALAR=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y

#
# Timers subsystem
#
CONFIG_PERIODIC_HZ=y
# CONFIG_NO_HZ_IDLE is not set
# CONFIG_HIGH_RES_TIMERS is not set

#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_BSD_PROCESS_ACCT is not set
CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
# CONFIG_TASK_XACCT is not set

#
# RCU Subsystem
#
CONFIG_TINY_RCU=y
# CONFIG_PREEMPT_RCU is not set
CONFIG_RCU_STALL_COMMON=y
# CONFIG_TREE_RCU_TRACE is not set
# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=17
CONFIG_CGROUPS=y
# CONFIG_CGROUP_DEBUG is not set
CONFIG_CGROUP_FREEZER=y
# CONFIG_CGROUP_DEVICE is not set
# CONFIG_CPUSETS is not set
# CONFIG_CGROUP_CPUACCT is not set
CONFIG_RESOURCE_COUNTERS=y
CONFIG_MEMCG=y
# CONFIG_CGROUP_PERF is not set
CONFIG_CGROUP_SCHED=y
CONFIG_FAIR_GROUP_SCHED=y
# CONFIG_CFS_BANDWIDTH is not set
CONFIG_RT_GROUP_SCHED=y
CONFIG_CHECKPOINT_RESTORE=y
# CONFIG_NAMESPACES is not set
CONFIG_UIDGID_CONVERTED=y
CONFIG_UIDGID_STRICT_TYPE_CHECKS=y
CONFIG_SCHED_AUTOGROUP=y
CONFIG_MM_OWNER=y
# CONFIG_SYSFS_DEPRECATED is not set
# CONFIG_RELAY is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_RD_GZIP=y
# CONFIG_RD_BZIP2 is not set
# CONFIG_RD_LZMA is not set
# CONFIG_RD_XZ is not set
CONFIG_RD_LZO=y
CONFIG_RD_LZ4=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_ANON_INODES=y
CONFIG_EXPERT=y
CONFIG_HAVE_UID16=y
CONFIG_UID16=y
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
# CONFIG_FUTEX is not set
# CONFIG_EPOLL is not set
# CONFIG_SIGNALFD is not set
# CONFIG_TIMERFD is not set
CONFIG_EVENTFD=y
# CONFIG_AIO is not set
# CONFIG_EMBEDDED is not set
CONFIG_HAVE_PERF_EVENTS=y
CONFIG_PERF_USE_VMALLOC=y

#
# Kernel Performance Events And Counters
#
CONFIG_PERF_EVENTS=y
# CONFIG_DEBUG_PERF_USE_VMALLOC is not set
# CONFIG_VM_EVENT_COUNTERS is not set
# CONFIG_COMPAT_BRK is not set
# CONFIG_SLAB is not set
# CONFIG_SLUB is not set
CONFIG_SLOB=y
# CONFIG_MMAP_ALLOW_UNINITIALIZED is not set
# CONFIG_PROFILING is not set
CONFIG_HAVE_OPROFILE=y
CONFIG_KPROBES=y
CONFIG_JUMP_LABEL=y
# CONFIG_HAVE_64BIT_ALIGNED_ACCESS is not set
CONFIG_KRETPROBES=y
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
CONFIG_HAVE_ARCH_TRACEHOOK=y
CONFIG_HAVE_DMA_ATTRS=y
CONFIG_GENERIC_SMP_IDLE_THREAD=y
CONFIG_GENERIC_IDLE_LOOP=y
CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y
CONFIG_HAVE_CLK=y
CONFIG_HAVE_DMA_API_DEBUG=y
CONFIG_HAVE_HW_BREAKPOINT=y
CONFIG_HAVE_ARCH_JUMP_LABEL=y
CONFIG_ARCH_WANT_IPC_PARSE_VERSION=y
CONFIG_HAVE_ARCH_SECCOMP_FILTER=y
CONFIG_HAVE_CONTEXT_TRACKING=y
CONFIG_MODULES_USE_ELF_REL=y
CONFIG_CLONE_BACKWARDS=y
CONFIG_OLD_SIGSUSPEND3=y
CONFIG_OLD_SIGACTION=y

#
# GCOV-based kernel profiling
#
# CONFIG_GCOV_KERNEL is not set
CONFIG_HAVE_GENERIC_DMA_COHERENT=y
CONFIG_RT_MUTEXES=y
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
CONFIG_MODULE_FORCE_LOAD=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
CONFIG_MODVERSIONS=y
CONFIG_MODULE_SRCVERSION_ALL=y
# CONFIG_MODULE_SIG is not set
# CONFIG_BLOCK is not set
CONFIG_UNINLINE_SPIN_UNLOCK=y
CONFIG_FREEZER=y

#
# System Type
#
# CONFIG_MMU is not set
# CONFIG_ARCH_INTEGRATOR is not set
# CONFIG_ARCH_REALVIEW is not set
# CONFIG_ARCH_VERSATILE is not set
# CONFIG_ARCH_AT91 is not set
# CONFIG_ARCH_CLPS711X is not set
# CONFIG_ARCH_GEMINI is not set
# CONFIG_ARCH_EBSA110 is not set
# CONFIG_ARCH_EP93XX is not set
# CONFIG_ARCH_FOOTBRIDGE is not set
# CONFIG_ARCH_NETX is not set
# CONFIG_ARCH_DOVE is not set
# CONFIG_ARCH_KIRKWOOD is not set
# CONFIG_ARCH_MV78XX0 is not set
# CONFIG_ARCH_KS8695 is not set
# CONFIG_ARCH_W90X900 is not set
# CONFIG_ARCH_LPC32XX is not set
# CONFIG_ARCH_MSM is not set
# CONFIG_ARCH_SHMOBILE is not set
# CONFIG_ARCH_RPC is not set
# CONFIG_ARCH_SA1100 is not set
# CONFIG_ARCH_S3C24XX is not set
# CONFIG_ARCH_S3C64XX is not set
# CONFIG_ARCH_S5P64X0 is not set
# CONFIG_ARCH_S5PC100 is not set
CONFIG_ARCH_S5PV210=y
# CONFIG_ARCH_EXYNOS is not set
# CONFIG_ARCH_SHARK is not set
# CONFIG_ARCH_DAVINCI is not set
# CONFIG_GPIO_PCA953X is not set
CONFIG_PLAT_SAMSUNG=y
CONFIG_PLAT_S5P=y

#
# Boot options
#
# CONFIG_S3C_BOOT_ERROR_RESET is not set
CONFIG_S3C_BOOT_UART_FORCE_FIFO=y
CONFIG_S3C_LOWLEVEL_UART_PORT=0
CONFIG_SAMSUNG_CLOCK=y
CONFIG_SAMSUNG_CLKSRC=y
CONFIG_S5P_CLOCK=y
CONFIG_SAMSUNG_IRQ_VIC_TIMER=y
CONFIG_S5P_IRQ=y
CONFIG_SAMSUNG_GPIOLIB_4BIT=y
CONFIG_S5P_GPIO_DRVSTR=y
CONFIG_SAMSUNG_GPIO_EXTRA=0
CONFIG_S3C_GPIO_SPACE=0
CONFIG_S3C_GPIO_TRACK=y
CONFIG_S5P_DEV_UART=y
# CONFIG_S3C_ADC is not set
# CONFIG_S3C24XX_PWM is not set

#
# Power management
#
# CONFIG_SAMSUNG_PM_DEBUG is not set
# CONFIG_SAMSUNG_PM_CHECK is not set
# CONFIG_PLAT_SPEAR is not set

#
# S5PC110 Machines
#
# CONFIG_MACH_AQUILA is not set
# CONFIG_MACH_GONI is not set
# CONFIG_MACH_SMDKC110 is not set

#
# S5PV210 Machines
#
# CONFIG_MACH_SMDKV210 is not set
# CONFIG_MACH_TORBRECK is not set

#
# Processor Type
#
CONFIG_CPU_ARM7TDMI=y
CONFIG_CPU_ARM9TDMI=y
CONFIG_CPU_V7=y
CONFIG_CPU_32v4T=y
CONFIG_CPU_32v6K=y
CONFIG_CPU_32v7=y
CONFIG_CPU_ABRT_NOMMU=y
CONFIG_CPU_ABRT_LV4T=y
CONFIG_CPU_ABRT_EV7=y
CONFIG_CPU_PABRT_LEGACY=y
CONFIG_CPU_PABRT_V7=y
CONFIG_CPU_CACHE_V4=y
CONFIG_CPU_CACHE_V7=y
CONFIG_CPU_CACHE_VIPT=y
CONFIG_CPU_CP15=y
CONFIG_CPU_CP15_MMU=y

#
# Processor Features
#
# CONFIG_ARCH_PHYS_ADDR_T_64BIT is not set
CONFIG_ARM_THUMB=y
# CONFIG_ARM_THUMBEE is not set
# CONFIG_SWP_EMULATE is not set
# CONFIG_CPU_HIGH_VECTOR is not set
CONFIG_CPU_ICACHE_DISABLE=y
# CONFIG_CPU_DCACHE_DISABLE is not set
# CONFIG_CPU_BPREDICT_DISABLE is not set
CONFIG_TLS_REG_EMUL=y
# CONFIG_CACHE_L2X0 is not set
CONFIG_ARM_L1_CACHE_SHIFT_6=y
CONFIG_ARM_L1_CACHE_SHIFT=6
CONFIG_ARM_DMA_MEM_BUFFERABLE=y
CONFIG_ARM_NR_BANKS=8
CONFIG_MULTI_IRQ_HANDLER=y
# CONFIG_SET_MEM_PARAM is not set
CONFIG_DRAM_BASE=0x00800000
CONFIG_DRAM_SIZE=0x00800000
CONFIG_FLASH_MEM_BASE=0x00400000
CONFIG_FLASH_SIZE=0x00400000
# CONFIG_ARM_ERRATA_430973 is not set
# CONFIG_ARM_ERRATA_458693 is not set
# CONFIG_ARM_ERRATA_460075 is not set
# CONFIG_ARM_ERRATA_720789 is not set
# CONFIG_ARM_ERRATA_743622 is not set
# CONFIG_ARM_ERRATA_751472 is not set
# CONFIG_ARM_ERRATA_754322 is not set
# CONFIG_ARM_ERRATA_775420 is not set

#
# Bus support
#
# CONFIG_PCI_SYSCALL is not set
# CONFIG_PCCARD is not set

#
# Kernel Features
#
# CONFIG_HAVE_ARM_ARCH_TIMER is not set
CONFIG_VMSPLIT_3G=y
# CONFIG_VMSPLIT_2G is not set
# CONFIG_VMSPLIT_1G is not set
CONFIG_PAGE_OFFSET=0xC0000000
# CONFIG_ARM_PSCI is not set
CONFIG_ARCH_NR_GPIO=0
# CONFIG_PREEMPT_NONE is not set
CONFIG_PREEMPT_VOLUNTARY=y
# CONFIG_PREEMPT is not set
CONFIG_HZ=200
# CONFIG_SCHED_HRTICK is not set
# CONFIG_THUMB2_KERNEL is not set
# CONFIG_AEABI is not set
CONFIG_ARCH_HAS_HOLES_MEMORYMODEL=y
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_SPARSEMEM_DEFAULT=y
CONFIG_ARCH_SELECT_MEMORY_MODEL=y
CONFIG_HAVE_ARCH_PFN_VALID=y
# CONFIG_HW_PERF_EVENTS is not set
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_SPARSEMEM_MANUAL=y
CONFIG_SPARSEMEM=y
CONFIG_HAVE_MEMORY_PRESENT=y
CONFIG_SPARSEMEM_EXTREME=y
CONFIG_HAVE_MEMBLOCK=y
# CONFIG_HAVE_BOOTMEM_INFO_NODE is not set
CONFIG_SPLIT_PTLOCK_CPUS=999999
# CONFIG_PHYS_ADDR_T_64BIT is not set
CONFIG_ZONE_DMA_FLAG=0
CONFIG_NOMMU_INITIAL_TRIM_EXCESS=1
CONFIG_NEED_PER_CPU_KM=y
CONFIG_CLEANCACHE=y
CONFIG_FORCE_MAX_ZONEORDER=11
CONFIG_ALIGNMENT_TRAP=y
# CONFIG_SECCOMP is not set
# CONFIG_CC_STACKPROTECTOR is not set

#
# Boot options
#
CONFIG_USE_OF=y
# CONFIG_ATAGS is not set
CONFIG_ZBOOT_ROM_TEXT=0
CONFIG_ZBOOT_ROM_BSS=0
# CONFIG_ARM_APPENDED_DTB is not set
CONFIG_CMDLINE=""
# CONFIG_XIP_KERNEL is not set
# CONFIG_KEXEC is not set
CONFIG_CRASH_DUMP=y
CONFIG_AUTO_ZRELADDR=y

#
# CPU Power Management
#

#
# CPU Frequency scaling
#
# CONFIG_CPU_FREQ is not set
# CONFIG_CPU_IDLE is not set
# CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED is not set

#
# Floating point emulation
#

#
# At least one emulation must be selected
#
# CONFIG_FPE_FASTFPE is not set
CONFIG_VFP=y
CONFIG_VFPv3=y
# CONFIG_NEON is not set

#
# Userspace binary formats
#
CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE=y
# CONFIG_BINFMT_SCRIPT is not set
CONFIG_BINFMT_FLAT=y
# CONFIG_BINFMT_ZFLAT is not set
CONFIG_BINFMT_SHARED_FLAT=y
CONFIG_HAVE_AOUT=y
# CONFIG_BINFMT_AOUT is not set
CONFIG_BINFMT_MISC=m
CONFIG_COREDUMP=y
# CONFIG_ARTHUR is not set

#
# Power management options
#
CONFIG_SUSPEND=y
CONFIG_SUSPEND_FREEZER=y
CONFIG_PM_SLEEP=y
CONFIG_PM_AUTOSLEEP=y
CONFIG_PM_WAKELOCKS=y
CONFIG_PM_WAKELOCKS_LIMIT=100
# CONFIG_PM_WAKELOCKS_GC is not set
# CONFIG_PM_RUNTIME is not set
CONFIG_PM=y
CONFIG_PM_DEBUG=y
# CONFIG_PM_ADVANCED_DEBUG is not set
CONFIG_PM_SLEEP_DEBUG=y
CONFIG_APM_EMULATION=m
CONFIG_PM_CLK=y
CONFIG_CPU_PM=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARM_CPU_SUSPEND=y
CONFIG_NET=y

#
# Networking options
#
# CONFIG_PACKET is not set
# CONFIG_UNIX is not set
CONFIG_XFRM=y
CONFIG_XFRM_ALGO=m
CONFIG_XFRM_USER=m
CONFIG_XFRM_SUB_POLICY=y
CONFIG_XFRM_MIGRATE=y
CONFIG_XFRM_STATISTICS=y
CONFIG_XFRM_IPCOMP=m
# CONFIG_NET_KEY is not set
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
# CONFIG_IP_ADVANCED_ROUTER is not set
# CONFIG_IP_PNP is not set
CONFIG_NET_IPIP=m
CONFIG_NET_IPGRE_DEMUX=m
CONFIG_NET_IP_TUNNEL=m
CONFIG_NET_IPGRE=m
CONFIG_NET_IPGRE_BROADCAST=y
# CONFIG_IP_MROUTE is not set
CONFIG_ARPD=y
CONFIG_SYN_COOKIES=y
CONFIG_NET_IPVTI=m
# CONFIG_INET_AH is not set
CONFIG_INET_ESP=m
CONFIG_INET_IPCOMP=m
CONFIG_INET_XFRM_TUNNEL=m
CONFIG_INET_TUNNEL=m
# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
CONFIG_INET_XFRM_MODE_TUNNEL=m
CONFIG_INET_XFRM_MODE_BEET=m
CONFIG_INET_LRO=m
# CONFIG_INET_DIAG is not set
CONFIG_TCP_CONG_ADVANCED=y
# CONFIG_TCP_CONG_BIC is not set
# CONFIG_TCP_CONG_CUBIC is not set
# CONFIG_TCP_CONG_WESTWOOD is not set
CONFIG_TCP_CONG_HTCP=m
CONFIG_TCP_CONG_HSTCP=m
# CONFIG_TCP_CONG_HYBLA is not set
CONFIG_TCP_CONG_VEGAS=m
# CONFIG_TCP_CONG_SCALABLE is not set
CONFIG_TCP_CONG_LP=m
CONFIG_TCP_CONG_VENO=m
# CONFIG_TCP_CONG_YEAH is not set
# CONFIG_TCP_CONG_ILLINOIS is not set
CONFIG_DEFAULT_RENO=y
CONFIG_DEFAULT_TCP_CONG="reno"
# CONFIG_TCP_MD5SIG is not set
CONFIG_IPV6=m
# CONFIG_IPV6_PRIVACY is not set
CONFIG_IPV6_ROUTER_PREF=y
CONFIG_IPV6_ROUTE_INFO=y
# CONFIG_IPV6_OPTIMISTIC_DAD is not set
# CONFIG_INET6_AH is not set
# CONFIG_INET6_ESP is not set
CONFIG_INET6_IPCOMP=m
CONFIG_IPV6_MIP6=m
CONFIG_INET6_XFRM_TUNNEL=m
CONFIG_INET6_TUNNEL=m
# CONFIG_INET6_XFRM_MODE_TRANSPORT is not set
CONFIG_INET6_XFRM_MODE_TUNNEL=m
# CONFIG_INET6_XFRM_MODE_BEET is not set
# CONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION is not set
# CONFIG_IPV6_SIT is not set
CONFIG_IPV6_TUNNEL=m
CONFIG_IPV6_GRE=m
# CONFIG_IPV6_MULTIPLE_TABLES is not set
# CONFIG_IPV6_MROUTE is not set
CONFIG_NETLABEL=y
CONFIG_NETWORK_SECMARK=y
CONFIG_NETWORK_PHY_TIMESTAMPING=y
# CONFIG_NETFILTER is not set
# CONFIG_IP_DCCP is not set
CONFIG_IP_SCTP=m
CONFIG_NET_SCTPPROBE=m
# CONFIG_SCTP_DBG_MSG is not set
# CONFIG_SCTP_DBG_OBJCNT is not set
CONFIG_SCTP_DEFAULT_COOKIE_HMAC_MD5=y
# CONFIG_SCTP_DEFAULT_COOKIE_HMAC_SHA1 is not set
# CONFIG_SCTP_DEFAULT_COOKIE_HMAC_NONE is not set
CONFIG_SCTP_COOKIE_HMAC_MD5=y
# CONFIG_SCTP_COOKIE_HMAC_SHA1 is not set
CONFIG_RDS=m
CONFIG_RDS_TCP=m
# CONFIG_RDS_DEBUG is not set
CONFIG_TIPC=m
CONFIG_TIPC_PORTS=8191
CONFIG_ATM=m
# CONFIG_ATM_CLIP is not set
CONFIG_ATM_LANE=m
CONFIG_ATM_MPOA=m
# CONFIG_ATM_BR2684 is not set
CONFIG_L2TP=m
CONFIG_L2TP_DEBUGFS=m
CONFIG_L2TP_V3=y
CONFIG_L2TP_IP=m
# CONFIG_L2TP_ETH is not set
# CONFIG_BRIDGE is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
CONFIG_X25=m
# CONFIG_LAPB is not set
# CONFIG_PHONET is not set
CONFIG_IEEE802154=m
CONFIG_IEEE802154_6LOWPAN=m
CONFIG_MAC802154=m
# CONFIG_NET_SCHED is not set
CONFIG_DCB=y
# CONFIG_DNS_RESOLVER is not set
# CONFIG_BATMAN_ADV is not set
CONFIG_OPENVSWITCH=m
# CONFIG_VSOCKETS is not set
# CONFIG_NETLINK_DIAG is not set
CONFIG_NETPRIO_CGROUP=m
CONFIG_BQL=y
CONFIG_BPF_JIT=y

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
CONFIG_NET_TCPPROBE=m
CONFIG_HAMRADIO=y

#
# Packet Radio protocols
#
CONFIG_AX25=m
# CONFIG_AX25_DAMA_SLAVE is not set
CONFIG_NETROM=m
CONFIG_ROSE=m

#
# AX.25 network device drivers
#
CONFIG_MKISS=m
# CONFIG_6PACK is not set
CONFIG_BPQETHER=m
CONFIG_BAYCOM_SER_FDX=m
CONFIG_BAYCOM_SER_HDX=m
# CONFIG_YAM is not set
# CONFIG_CAN is not set
CONFIG_IRDA=m

#
# IrDA protocols
#
# CONFIG_IRLAN is not set
CONFIG_IRCOMM=m
CONFIG_IRDA_ULTRA=y

#
# IrDA options
#
# CONFIG_IRDA_CACHE_LAST_LSAP is not set
# CONFIG_IRDA_FAST_RR is not set
# CONFIG_IRDA_DEBUG is not set

#
# Infrared-port device drivers
#

#
# SIR device drivers
#
CONFIG_IRTTY_SIR=m

#
# Dongle support
#
# CONFIG_DONGLE is not set

#
# FIR device drivers
#
CONFIG_BT=m
# CONFIG_BT_RFCOMM is not set
# CONFIG_BT_BNEP is not set
CONFIG_BT_HIDP=m

#
# Bluetooth device drivers
#
CONFIG_BT_HCIBTSDIO=m
# CONFIG_BT_HCIUART is not set
CONFIG_BT_HCIVHCI=m
CONFIG_BT_MRVL=m
# CONFIG_BT_MRVL_SDIO is not set
CONFIG_BT_WILINK=m
CONFIG_AF_RXRPC=m
# CONFIG_AF_RXRPC_DEBUG is not set
# CONFIG_RXKAD is not set
CONFIG_WIRELESS=y
# CONFIG_CFG80211 is not set
# CONFIG_LIB80211 is not set

#
# CFG80211 needs to be enabled for MAC80211
#
CONFIG_WIMAX=m
CONFIG_WIMAX_DEBUG_LEVEL=8
# CONFIG_RFKILL is not set
# CONFIG_NET_9P is not set
CONFIG_CAIF=m
CONFIG_CAIF_DEBUG=y
CONFIG_CAIF_NETDEV=m
CONFIG_CAIF_USB=m
# CONFIG_CEPH_LIB is not set
# CONFIG_NFC is not set
CONFIG_HAVE_BPF_JIT=y

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_UEVENT_HELPER_PATH=""
# CONFIG_DEVTMPFS is not set
# CONFIG_STANDALONE is not set
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=m
CONFIG_FIRMWARE_IN_KERNEL=y
CONFIG_EXTRA_FIRMWARE=""
# CONFIG_FW_LOADER_USER_HELPER is not set
# CONFIG_DEBUG_DRIVER is not set
# CONFIG_DEBUG_DEVRES is not set
# CONFIG_SYS_HYPERVISOR is not set
# CONFIG_GENERIC_CPU_DEVICES is not set
CONFIG_REGMAP=y
CONFIG_REGMAP_I2C=m
CONFIG_REGMAP_MMIO=m
CONFIG_REGMAP_IRQ=y
# CONFIG_DMA_SHARED_BUFFER is not set

#
# Bus devices
#
# CONFIG_CONNECTOR is not set
# CONFIG_MTD is not set
CONFIG_DTC=y
CONFIG_OF=y

#
# Device Tree and Open Firmware support
#
# CONFIG_PROC_DEVICETREE is not set
CONFIG_OF_SELFTEST=y
CONFIG_OF_FLATTREE=y
CONFIG_OF_EARLY_FLATTREE=y
CONFIG_OF_ADDRESS=y
CONFIG_OF_IRQ=y
CONFIG_OF_DEVICE=y
CONFIG_OF_I2C=m
# CONFIG_PARPORT is not set

#
# Misc devices
#
# CONFIG_SENSORS_LIS3LV02D is not set
CONFIG_AD525X_DPOT=m
# CONFIG_AD525X_DPOT_I2C is not set
# CONFIG_ATMEL_PWM is not set
# CONFIG_DUMMY_IRQ is not set
# CONFIG_ICS932S401 is not set
CONFIG_ATMEL_SSC=m
# CONFIG_ENCLOSURE_SERVICES is not set
# CONFIG_APDS9802ALS is not set
CONFIG_ISL29003=m
CONFIG_ISL29020=m
CONFIG_SENSORS_TSL2550=m
# CONFIG_SENSORS_BH1780 is not set
# CONFIG_SENSORS_BH1770 is not set
# CONFIG_SENSORS_APDS990X is not set
# CONFIG_HMC6352 is not set
CONFIG_DS1682=m
CONFIG_BMP085=y
CONFIG_BMP085_I2C=m
CONFIG_USB_SWITCH_FSA9480=m
# CONFIG_SRAM is not set
CONFIG_C2PORT=m

#
# EEPROM support
#
CONFIG_EEPROM_AT24=m
# CONFIG_EEPROM_LEGACY is not set
# CONFIG_EEPROM_MAX6875 is not set
CONFIG_EEPROM_93CX6=m

#
# Texas Instruments shared transport line discipline
#
CONFIG_TI_ST=m
# CONFIG_SENSORS_LIS3_I2C is not set

#
# Altera FPGA firmware download module
#
CONFIG_ALTERA_STAPL=m

#
# SCSI device support
#
CONFIG_SCSI_MOD=y
# CONFIG_SCSI_DMA is not set
# CONFIG_SCSI_NETLINK is not set
# CONFIG_NETDEVICES is not set

#
# Input device support
#
CONFIG_INPUT=m
CONFIG_INPUT_FF_MEMLESS=m
CONFIG_INPUT_POLLDEV=m
# CONFIG_INPUT_SPARSEKMAP is not set
# CONFIG_INPUT_MATRIXKMAP is not set

#
# Userland interfaces
#
# CONFIG_INPUT_MOUSEDEV is not set
# CONFIG_INPUT_JOYDEV is not set
# CONFIG_INPUT_EVDEV is not set
# CONFIG_INPUT_EVBUG is not set
# CONFIG_INPUT_APMPOWER is not set

#
# Input Device Drivers
#
# CONFIG_INPUT_KEYBOARD is not set
CONFIG_INPUT_MOUSE=y
# CONFIG_MOUSE_PS2 is not set
# CONFIG_MOUSE_SERIAL is not set
# CONFIG_MOUSE_CYAPA is not set
# CONFIG_MOUSE_VSXXXAA is not set
# CONFIG_MOUSE_GPIO is not set
CONFIG_MOUSE_SYNAPTICS_I2C=m
CONFIG_INPUT_JOYSTICK=y
# CONFIG_JOYSTICK_ANALOG is not set
# CONFIG_JOYSTICK_A3D is not set
# CONFIG_JOYSTICK_ADI is not set
CONFIG_JOYSTICK_COBRA=m
# CONFIG_JOYSTICK_GF2K is not set
CONFIG_JOYSTICK_GRIP=m
# CONFIG_JOYSTICK_GRIP_MP is not set
CONFIG_JOYSTICK_GUILLEMOT=m
CONFIG_JOYSTICK_INTERACT=m
# CONFIG_JOYSTICK_SIDEWINDER is not set
CONFIG_JOYSTICK_TMDC=m
CONFIG_JOYSTICK_IFORCE=m
# CONFIG_JOYSTICK_IFORCE_232 is not set
CONFIG_JOYSTICK_WARRIOR=m
# CONFIG_JOYSTICK_MAGELLAN is not set
CONFIG_JOYSTICK_SPACEORB=m
CONFIG_JOYSTICK_SPACEBALL=m
# CONFIG_JOYSTICK_STINGER is not set
CONFIG_JOYSTICK_TWIDJOY=m
CONFIG_JOYSTICK_ZHENHUA=m
# CONFIG_JOYSTICK_AS5011 is not set
# CONFIG_JOYSTICK_JOYDUMP is not set
CONFIG_INPUT_TABLET=y
CONFIG_INPUT_TOUCHSCREEN=y
# CONFIG_TOUCHSCREEN_AD7879 is not set
CONFIG_TOUCHSCREEN_ATMEL_MXT=m
# CONFIG_TOUCHSCREEN_AUO_PIXCIR is not set
CONFIG_TOUCHSCREEN_BU21013=m
# CONFIG_TOUCHSCREEN_CY8CTMG110 is not set
CONFIG_TOUCHSCREEN_CYTTSP_CORE=m
# CONFIG_TOUCHSCREEN_CYTTSP_I2C is not set
# CONFIG_TOUCHSCREEN_DYNAPRO is not set
CONFIG_TOUCHSCREEN_HAMPSHIRE=m
# CONFIG_TOUCHSCREEN_EETI is not set
CONFIG_TOUCHSCREEN_EGALAX=m
CONFIG_TOUCHSCREEN_FUJITSU=m
CONFIG_TOUCHSCREEN_ILI210X=m
CONFIG_TOUCHSCREEN_GUNZE=m
CONFIG_TOUCHSCREEN_ELO=m
CONFIG_TOUCHSCREEN_WACOM_W8001=m
# CONFIG_TOUCHSCREEN_WACOM_I2C is not set
# CONFIG_TOUCHSCREEN_MAX11801 is not set
# CONFIG_TOUCHSCREEN_MCS5000 is not set
# CONFIG_TOUCHSCREEN_MMS114 is not set
CONFIG_TOUCHSCREEN_MTOUCH=m
CONFIG_TOUCHSCREEN_INEXIO=m
# CONFIG_TOUCHSCREEN_MK712 is not set
CONFIG_TOUCHSCREEN_PENMOUNT=m
# CONFIG_TOUCHSCREEN_EDT_FT5X06 is not set
CONFIG_TOUCHSCREEN_TOUCHRIGHT=m
CONFIG_TOUCHSCREEN_TOUCHWIN=m
# CONFIG_TOUCHSCREEN_TI_AM335X_TSC is not set
CONFIG_TOUCHSCREEN_PIXCIR=m
CONFIG_TOUCHSCREEN_MC13783=m
# CONFIG_TOUCHSCREEN_TOUCHIT213 is not set
CONFIG_TOUCHSCREEN_TSC_SERIO=m
CONFIG_TOUCHSCREEN_TSC2007=m
# CONFIG_TOUCHSCREEN_W90X900 is not set
# CONFIG_TOUCHSCREEN_ST1232 is not set
# CONFIG_TOUCHSCREEN_TPS6507X is not set
CONFIG_INPUT_MISC=y
CONFIG_INPUT_AD714X=m
# CONFIG_INPUT_AD714X_I2C is not set
CONFIG_INPUT_BMA150=m
CONFIG_INPUT_MC13783_PWRBUTTON=m
# CONFIG_INPUT_MMA8450 is not set
# CONFIG_INPUT_MPU3050 is not set
# CONFIG_INPUT_GP2A is not set
CONFIG_INPUT_GPIO_TILT_POLLED=m
# CONFIG_INPUT_KXTJ9 is not set
# CONFIG_INPUT_RETU_PWRBUTTON is not set
# CONFIG_INPUT_UINPUT is not set
CONFIG_INPUT_PCF8574=m
CONFIG_INPUT_PWM_BEEPER=m
# CONFIG_INPUT_GPIO_ROTARY_ENCODER is not set
CONFIG_INPUT_ADXL34X=m
CONFIG_INPUT_ADXL34X_I2C=m
CONFIG_INPUT_CMA3000=m
CONFIG_INPUT_CMA3000_I2C=m

#
# Hardware I/O ports
#
CONFIG_SERIO=m
CONFIG_SERIO_SERPORT=m
# CONFIG_SERIO_LIBPS2 is not set
# CONFIG_SERIO_RAW is not set
# CONFIG_SERIO_ALTERA_PS2 is not set
CONFIG_SERIO_PS2MULT=m
# CONFIG_SERIO_ARC_PS2 is not set
CONFIG_SERIO_APBPS2=m
CONFIG_GAMEPORT=m
# CONFIG_GAMEPORT_NS558 is not set
# CONFIG_GAMEPORT_L4 is not set

#
# Character devices
#
CONFIG_TTY=y
# CONFIG_VT is not set
CONFIG_UNIX98_PTYS=y
# CONFIG_DEVPTS_MULTIPLE_INSTANCES is not set
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256
# CONFIG_SERIAL_NONSTANDARD is not set
CONFIG_N_GSM=m
# CONFIG_TRACE_ROUTER is not set
CONFIG_TRACE_SINK=m
CONFIG_DEVKMEM=y

#
# Serial drivers
#
CONFIG_SERIAL_8250=m
# CONFIG_SERIAL_8250_DEPRECATED_OPTIONS is not set
CONFIG_SERIAL_8250_NR_UARTS=4
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
# CONFIG_SERIAL_8250_EXTENDED is not set
CONFIG_SERIAL_8250_DW=m
# CONFIG_SERIAL_8250_EM is not set

#
# Non-8250 serial port support
#
# CONFIG_SERIAL_SAMSUNG is not set
CONFIG_SERIAL_SAMSUNG_UARTS_4=y
CONFIG_SERIAL_SAMSUNG_UARTS=4
CONFIG_SERIAL_CORE=m
CONFIG_SERIAL_OF_PLATFORM=m
# CONFIG_SERIAL_SCCNXP is not set
# CONFIG_SERIAL_TIMBERDALE is not set
# CONFIG_SERIAL_ALTERA_JTAGUART is not set
CONFIG_SERIAL_ALTERA_UART=m
CONFIG_SERIAL_ALTERA_UART_MAXPORTS=4
CONFIG_SERIAL_ALTERA_UART_BAUDRATE=115200
CONFIG_SERIAL_XILINX_PS_UART=m
# CONFIG_SERIAL_ARC is not set
# CONFIG_TTY_PRINTK is not set
CONFIG_HVC_DRIVER=y
CONFIG_HVC_DCC=y
CONFIG_VIRTIO_CONSOLE=m
# CONFIG_IPMI_HANDLER is not set
CONFIG_HW_RANDOM=m
# CONFIG_HW_RANDOM_TIMERIOMEM is not set
CONFIG_HW_RANDOM_ATMEL=m
# CONFIG_HW_RANDOM_VIRTIO is not set
# CONFIG_HW_RANDOM_EXYNOS is not set
# CONFIG_HW_RANDOM_TPM is not set
# CONFIG_R3964 is not set
CONFIG_TCG_TPM=y
CONFIG_TCG_TIS_I2C_INFINEON=m
CONFIG_TCG_ST33_I2C=m
CONFIG_I2C=m
CONFIG_I2C_BOARDINFO=y
# CONFIG_I2C_COMPAT is not set
# CONFIG_I2C_CHARDEV is not set
CONFIG_I2C_MUX=m

#
# Multiplexer I2C Chip support
#
# CONFIG_I2C_MUX_GPIO is not set
CONFIG_I2C_MUX_PCA9541=m
CONFIG_I2C_MUX_PCA954x=m
# CONFIG_I2C_HELPER_AUTO is not set
CONFIG_I2C_SMBUS=m

#
# I2C Algorithms
#
CONFIG_I2C_ALGOBIT=m
# CONFIG_I2C_ALGOPCF is not set
CONFIG_I2C_ALGOPCA=m

#
# I2C Hardware Bus support
#

#
# I2C system bus drivers (mostly embedded / system-on-chip)
#
# CONFIG_I2C_CBUS_GPIO is not set
CONFIG_I2C_DESIGNWARE_CORE=m
CONFIG_I2C_DESIGNWARE_PLATFORM=m
# CONFIG_I2C_GPIO is not set
# CONFIG_I2C_OCORES is not set
CONFIG_I2C_PCA_PLATFORM=m
# CONFIG_I2C_PXA_PCI is not set
CONFIG_HAVE_S3C2410_I2C=y
# CONFIG_I2C_S3C2410 is not set
CONFIG_I2C_SIMTEC=m
# CONFIG_I2C_XILINX is not set

#
# External I2C/SMBus adapter drivers
#
CONFIG_I2C_PARPORT_LIGHT=m
CONFIG_I2C_TAOS_EVM=m

#
# Other I2C/SMBus bus drivers
#
CONFIG_I2C_STUB=m
# CONFIG_I2C_DEBUG_CORE is not set
CONFIG_I2C_DEBUG_ALGO=y
CONFIG_I2C_DEBUG_BUS=y
# CONFIG_SPI is not set

#
# Qualcomm MSM SSBI bus support
#
# CONFIG_SSBI is not set
CONFIG_HSI=m
CONFIG_HSI_BOARDINFO=y

#
# HSI clients
#
# CONFIG_HSI_CHAR is not set

#
# PPS support
#
CONFIG_PPS=m
# CONFIG_PPS_DEBUG is not set
# CONFIG_NTP_PPS is not set

#
# PPS clients support
#
CONFIG_PPS_CLIENT_KTIMER=m
# CONFIG_PPS_CLIENT_LDISC is not set
CONFIG_PPS_CLIENT_GPIO=m

#
# PPS generators support
#

#
# PTP clock support
#
CONFIG_PTP_1588_CLOCK=m

#
# Enable PHYLIB and NETWORK_PHY_TIMESTAMPING to see the additional clocks.
#
CONFIG_PTP_1588_CLOCK_PCH=m
CONFIG_ARCH_HAVE_CUSTOM_GPIO_H=y
CONFIG_ARCH_REQUIRE_GPIOLIB=y
CONFIG_GPIO_DEVRES=y
CONFIG_GPIOLIB=y
CONFIG_OF_GPIO=y
# CONFIG_DEBUG_GPIO is not set
# CONFIG_GPIO_SYSFS is not set
CONFIG_GPIO_MAX730X=m

#
# Memory mapped GPIO drivers:
#
# CONFIG_GPIO_GENERIC_PLATFORM is not set
# CONFIG_GPIO_EM is not set
# CONFIG_GPIO_RCAR is not set
# CONFIG_GPIO_TS5500 is not set

#
# I2C GPIO expanders:
#
CONFIG_GPIO_MAX7300=m
CONFIG_GPIO_MAX732X=m
# CONFIG_GPIO_PCF857X is not set
# CONFIG_GPIO_ADP5588 is not set
CONFIG_GPIO_ADNP=m

#
# PCI GPIO expanders:
#

#
# SPI GPIO expanders:
#
# CONFIG_GPIO_MCP23S08 is not set

#
# AC97 GPIO expanders:
#

#
# MODULbus GPIO expanders:
#

#
# USB GPIO expanders:
#
CONFIG_W1=m

#
# 1-wire Bus Masters
#
CONFIG_W1_MASTER_DS2482=m
# CONFIG_W1_MASTER_DS1WM is not set
# CONFIG_W1_MASTER_GPIO is not set

#
# 1-wire Slaves
#
# CONFIG_W1_SLAVE_THERM is not set
CONFIG_W1_SLAVE_SMEM=m
CONFIG_W1_SLAVE_DS2408=m
# CONFIG_W1_SLAVE_DS2408_READBACK is not set
CONFIG_W1_SLAVE_DS2413=m
CONFIG_W1_SLAVE_DS2423=m
CONFIG_W1_SLAVE_DS2431=m
CONFIG_W1_SLAVE_DS2433=m
# CONFIG_W1_SLAVE_DS2433_CRC is not set
CONFIG_W1_SLAVE_DS2760=m
# CONFIG_W1_SLAVE_DS2780 is not set
CONFIG_W1_SLAVE_DS2781=m
CONFIG_W1_SLAVE_DS28E04=m
# CONFIG_W1_SLAVE_BQ27000 is not set
CONFIG_POWER_SUPPLY=y
# CONFIG_POWER_SUPPLY_DEBUG is not set
# CONFIG_PDA_POWER is not set
# CONFIG_APM_POWER is not set
# CONFIG_GENERIC_ADC_BATTERY is not set
CONFIG_TEST_POWER=m
# CONFIG_BATTERY_DS2760 is not set
# CONFIG_BATTERY_DS2780 is not set
CONFIG_BATTERY_DS2781=m
CONFIG_BATTERY_DS2782=m
# CONFIG_BATTERY_SBS is not set
# CONFIG_BATTERY_BQ27x00 is not set
CONFIG_BATTERY_MAX17040=m
# CONFIG_BATTERY_MAX17042 is not set
CONFIG_CHARGER_MAX8903=m
# CONFIG_CHARGER_LP8727 is not set
CONFIG_CHARGER_GPIO=m
CONFIG_CHARGER_BQ2415X=m
# CONFIG_CHARGER_SMB347 is not set
CONFIG_BATTERY_GOLDFISH=m
CONFIG_POWER_RESET=y
CONFIG_POWER_RESET_GPIO=y
CONFIG_POWER_RESET_RESTART=y
CONFIG_POWER_AVS=y
# CONFIG_HWMON is not set
CONFIG_THERMAL=m
# CONFIG_THERMAL_DEFAULT_GOV_STEP_WISE is not set
# CONFIG_THERMAL_DEFAULT_GOV_FAIR_SHARE is not set
CONFIG_THERMAL_DEFAULT_GOV_USER_SPACE=y
# CONFIG_THERMAL_GOV_FAIR_SHARE is not set
CONFIG_THERMAL_GOV_STEP_WISE=y
CONFIG_THERMAL_GOV_USER_SPACE=y
CONFIG_THERMAL_EMULATION=y
CONFIG_WATCHDOG=y
CONFIG_WATCHDOG_CORE=y
# CONFIG_WATCHDOG_NOWAYOUT is not set

#
# Watchdog Device Drivers
#
# CONFIG_SOFT_WATCHDOG is not set
CONFIG_HAVE_S3C2410_WATCHDOG=y
# CONFIG_S3C2410_WATCHDOG is not set
CONFIG_DW_WATCHDOG=m
CONFIG_MAX63XX_WATCHDOG=m
CONFIG_RETU_WATCHDOG=m
CONFIG_SSB_POSSIBLE=y

#
# Sonics Silicon Backplane
#
CONFIG_SSB=m
CONFIG_SSB_SDIOHOST_POSSIBLE=y
# CONFIG_SSB_SDIOHOST is not set
CONFIG_SSB_SILENT=y
CONFIG_SSB_DRIVER_GPIO=y
CONFIG_BCMA_POSSIBLE=y

#
# Broadcom specific AMBA
#
CONFIG_BCMA=m
CONFIG_BCMA_DRIVER_GMAC_CMN=y
# CONFIG_BCMA_DRIVER_GPIO is not set
# CONFIG_BCMA_DEBUG is not set

#
# Multifunction device drivers
#
CONFIG_MFD_CORE=y
CONFIG_MFD_CROS_EC=m
CONFIG_MFD_CROS_EC_I2C=m
CONFIG_MFD_ASIC3=y
CONFIG_MFD_MC13783=m
CONFIG_MFD_MC13XXX=m
CONFIG_MFD_MC13XXX_I2C=m
# CONFIG_HTC_EGPIO is not set
CONFIG_HTC_PASIC3=m
CONFIG_MFD_RETU=m
# CONFIG_MFD_PCF50633 is not set
# CONFIG_MFD_SM501 is not set
CONFIG_ABX500_CORE=y
# CONFIG_MFD_SYSCON is not set
CONFIG_MFD_TI_AM335X_TSCADC=m
# CONFIG_TPS6105X is not set
CONFIG_TPS65010=m
CONFIG_TPS6507X=m
CONFIG_MFD_TPS65217=m
CONFIG_MFD_TPS65912=y
CONFIG_MFD_WL1273_CORE=m
CONFIG_MFD_SI476X_CORE=m
# CONFIG_MFD_LM3533 is not set
CONFIG_MFD_TMIO=y
# CONFIG_MFD_T7L66XB is not set
CONFIG_MFD_TC6387XB=y
CONFIG_MFD_TC6393XB=y
# CONFIG_MFD_ARIZONA_I2C is not set
# CONFIG_REGULATOR is not set
# CONFIG_MEDIA_SUPPORT is not set

#
# Graphics support
#
# CONFIG_VGASTATE is not set
CONFIG_VIDEO_OUTPUT_CONTROL=m
CONFIG_FB=m
CONFIG_FIRMWARE_EDID=y
# CONFIG_FB_DDC is not set
# CONFIG_FB_BOOT_VESA_SUPPORT is not set
CONFIG_FB_CFB_FILLRECT=m
CONFIG_FB_CFB_COPYAREA=m
CONFIG_FB_CFB_IMAGEBLIT=m
# CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set
CONFIG_FB_SYS_FILLRECT=m
CONFIG_FB_SYS_COPYAREA=m
CONFIG_FB_SYS_IMAGEBLIT=m
CONFIG_FB_FOREIGN_ENDIAN=y
CONFIG_FB_BOTH_ENDIAN=y
# CONFIG_FB_BIG_ENDIAN is not set
# CONFIG_FB_LITTLE_ENDIAN is not set
CONFIG_FB_SYS_FOPS=m
CONFIG_FB_DEFERRED_IO=y
# CONFIG_FB_SVGALIB is not set
# CONFIG_FB_MACMODES is not set
# CONFIG_FB_BACKLIGHT is not set
CONFIG_FB_MODE_HELPERS=y
CONFIG_FB_TILEBLITTING=y

#
# Frame buffer hardware drivers
#
CONFIG_FB_S1D13XXX=m
# CONFIG_FB_TMIO is not set
# CONFIG_FB_S3C is not set
CONFIG_FB_GOLDFISH=m
# CONFIG_FB_VIRTUAL is not set
CONFIG_FB_METRONOME=m
# CONFIG_FB_BROADSHEET is not set
CONFIG_FB_AUO_K190X=m
# CONFIG_FB_AUO_K1900 is not set
# CONFIG_FB_AUO_K1901 is not set
# CONFIG_EXYNOS_VIDEO is not set
CONFIG_BACKLIGHT_LCD_SUPPORT=y
# CONFIG_LCD_CLASS_DEVICE is not set
CONFIG_BACKLIGHT_CLASS_DEVICE=m
# CONFIG_BACKLIGHT_GENERIC is not set
# CONFIG_BACKLIGHT_PWM is not set
CONFIG_BACKLIGHT_ADP8860=m
CONFIG_BACKLIGHT_ADP8870=m
CONFIG_BACKLIGHT_LM3630=m
CONFIG_BACKLIGHT_LM3639=m
# CONFIG_BACKLIGHT_LP855X is not set
CONFIG_BACKLIGHT_TPS65217=m
# CONFIG_LOGO is not set
CONFIG_FB_SSD1307=m
# CONFIG_SOUND is not set

#
# HID support
#
CONFIG_HID=m
CONFIG_HIDRAW=y
# CONFIG_UHID is not set
CONFIG_HID_GENERIC=m

#
# Special HID drivers
#
CONFIG_HID_A4TECH=m
CONFIG_HID_ACRUX=m
# CONFIG_HID_ACRUX_FF is not set
# CONFIG_HID_APPLE is not set
# CONFIG_HID_AUREAL is not set
CONFIG_HID_BELKIN=m
CONFIG_HID_CHERRY=m
CONFIG_HID_CHICONY=m
CONFIG_HID_CYPRESS=m
# CONFIG_HID_DRAGONRISE is not set
CONFIG_HID_EMS_FF=m
# CONFIG_HID_ELECOM is not set
# CONFIG_HID_EZKEY is not set
CONFIG_HID_KEYTOUCH=m
CONFIG_HID_KYE=m
CONFIG_HID_UCLOGIC=m
# CONFIG_HID_WALTOP is not set
# CONFIG_HID_GYRATION is not set
# CONFIG_HID_ICADE is not set
CONFIG_HID_TWINHAN=m
CONFIG_HID_KENSINGTON=m
CONFIG_HID_LCPOWER=m
# CONFIG_HID_LOGITECH is not set
CONFIG_HID_MAGICMOUSE=m
# CONFIG_HID_MICROSOFT is not set
# CONFIG_HID_MONTEREY is not set
CONFIG_HID_MULTITOUCH=m
CONFIG_HID_ORTEK=m
# CONFIG_HID_PANTHERLORD is not set
CONFIG_HID_PETALYNX=m
CONFIG_HID_PICOLCD=m
# CONFIG_HID_PICOLCD_FB is not set
# CONFIG_HID_PICOLCD_BACKLIGHT is not set
# CONFIG_HID_PICOLCD_LEDS is not set
# CONFIG_HID_PRIMAX is not set
CONFIG_HID_PS3REMOTE=m
# CONFIG_HID_SAITEK is not set
CONFIG_HID_SAMSUNG=m
# CONFIG_HID_SPEEDLINK is not set
CONFIG_HID_STEELSERIES=m
CONFIG_HID_SUNPLUS=m
CONFIG_HID_GREENASIA=m
CONFIG_GREENASIA_FF=y
# CONFIG_HID_SMARTJOYPLUS is not set
CONFIG_HID_TIVO=m
# CONFIG_HID_TOPSEED is not set
# CONFIG_HID_THINGM is not set
CONFIG_HID_THRUSTMASTER=m
# CONFIG_THRUSTMASTER_FF is not set
CONFIG_HID_WACOM=m
# CONFIG_HID_WIIMOTE is not set
CONFIG_HID_ZEROPLUS=m
CONFIG_ZEROPLUS_FF=y
CONFIG_HID_ZYDACRON=m
CONFIG_HID_SENSOR_HUB=m

#
# I2C HID support
#
CONFIG_I2C_HID=m
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB_ARCH_HAS_EHCI=y
# CONFIG_USB_ARCH_HAS_XHCI is not set
# CONFIG_USB_SUPPORT is not set
CONFIG_MMC=m
# CONFIG_MMC_DEBUG is not set
# CONFIG_MMC_UNSAFE_RESUME is not set
CONFIG_MMC_CLKGATE=y

#
# MMC/SD/SDIO Card Drivers
#
CONFIG_SDIO_UART=m
CONFIG_MMC_TEST=m

#
# MMC/SD/SDIO Host Controller Drivers
#
CONFIG_MMC_SDHCI=m
CONFIG_MMC_SDHCI_PLTFM=m
# CONFIG_MMC_SDHCI_S3C is not set
CONFIG_MMC_SDHCI_PXAV3=m
# CONFIG_MMC_SDHCI_PXAV2 is not set
CONFIG_MMC_TMIO_CORE=m
CONFIG_MMC_TMIO=m
CONFIG_MMC_DW=m
# CONFIG_MMC_DW_IDMAC is not set
CONFIG_MMC_DW_PLTFM=m
CONFIG_MMC_DW_EXYNOS=m
CONFIG_MEMSTICK=m
CONFIG_MEMSTICK_DEBUG=y

#
# MemoryStick drivers
#
CONFIG_MEMSTICK_UNSAFE_RESUME=y

#
# MemoryStick Host Controller Drivers
#
CONFIG_NEW_LEDS=y
CONFIG_LEDS_CLASS=y

#
# LED drivers
#
CONFIG_LEDS_LM3530=m
# CONFIG_LEDS_LM3642 is not set
CONFIG_LEDS_PCA9532=m
CONFIG_LEDS_PCA9532_GPIO=y
CONFIG_LEDS_GPIO=m
CONFIG_LEDS_LP3944=m
CONFIG_LEDS_LP55XX_COMMON=m
# CONFIG_LEDS_LP5521 is not set
CONFIG_LEDS_LP5523=m
CONFIG_LEDS_LP5562=m
# CONFIG_LEDS_PCA955X is not set
# CONFIG_LEDS_PCA9633 is not set
CONFIG_LEDS_PWM=m
# CONFIG_LEDS_BD2802 is not set
CONFIG_LEDS_LT3593=m
# CONFIG_LEDS_MC13783 is not set
CONFIG_LEDS_ASIC3=y
CONFIG_LEDS_RENESAS_TPU=y
CONFIG_LEDS_TCA6507=m
CONFIG_LEDS_LM355x=m
# CONFIG_LEDS_OT200 is not set
# CONFIG_LEDS_BLINKM is not set

#
# LED Triggers
#
CONFIG_LEDS_TRIGGERS=y
CONFIG_LEDS_TRIGGER_TIMER=m
CONFIG_LEDS_TRIGGER_ONESHOT=m
# CONFIG_LEDS_TRIGGER_HEARTBEAT is not set
CONFIG_LEDS_TRIGGER_BACKLIGHT=m
CONFIG_LEDS_TRIGGER_CPU=y
# CONFIG_LEDS_TRIGGER_GPIO is not set
# CONFIG_LEDS_TRIGGER_DEFAULT_ON is not set

#
# iptables trigger is under Netfilter config (LED target)
#
CONFIG_LEDS_TRIGGER_TRANSIENT=m
CONFIG_LEDS_TRIGGER_CAMERA=m
# CONFIG_ACCESSIBILITY is not set
# CONFIG_EDAC is not set
CONFIG_RTC_LIB=y
# CONFIG_RTC_CLASS is not set
# CONFIG_DMADEVICES is not set
# CONFIG_AUXDISPLAY is not set
CONFIG_UIO=m
CONFIG_UIO_PDRV=m
CONFIG_UIO_PDRV_GENIRQ=m
CONFIG_UIO_DMEM_GENIRQ=m
CONFIG_VIRT_DRIVERS=y
CONFIG_VIRTIO=m

#
# Virtio drivers
#
# CONFIG_VIRTIO_BALLOON is not set
# CONFIG_VIRTIO_MMIO is not set

#
# Microsoft Hyper-V guest support
#
# CONFIG_STAGING is not set
CONFIG_CLKDEV_LOOKUP=y

#
# Hardware Spinlock drivers
#
CONFIG_CLKSRC_MMIO=y
# CONFIG_MAILBOX is not set
# CONFIG_IOMMU_SUPPORT is not set

#
# Remoteproc drivers
#
CONFIG_REMOTEPROC=m
CONFIG_STE_MODEM_RPROC=m

#
# Rpmsg drivers
#
CONFIG_PM_DEVFREQ=y

#
# DEVFREQ Governors
#
CONFIG_DEVFREQ_GOV_SIMPLE_ONDEMAND=m
CONFIG_DEVFREQ_GOV_PERFORMANCE=m
CONFIG_DEVFREQ_GOV_POWERSAVE=m
CONFIG_DEVFREQ_GOV_USERSPACE=m

#
# DEVFREQ Drivers
#
# CONFIG_EXTCON is not set
# CONFIG_MEMORY is not set
CONFIG_IIO=m
CONFIG_IIO_BUFFER=y
# CONFIG_IIO_BUFFER_CB is not set
CONFIG_IIO_KFIFO_BUF=m
CONFIG_IIO_TRIGGERED_BUFFER=m
CONFIG_IIO_TRIGGER=y
CONFIG_IIO_CONSUMERS_PER_TRIGGER=2

#
# Accelerometers
#
# CONFIG_HID_SENSOR_ACCEL_3D is not set
# CONFIG_IIO_ST_ACCEL_3AXIS is not set

#
# Analog to digital converters
#
CONFIG_EXYNOS_ADC=y
CONFIG_MAX1363=m
# CONFIG_TI_ADC081C is not set
CONFIG_TI_AM335X_ADC=m

#
# Amplifiers
#

#
# Hid Sensor IIO Common
#
CONFIG_HID_SENSOR_IIO_COMMON=m
CONFIG_HID_SENSOR_IIO_TRIGGER=m
# CONFIG_HID_SENSOR_ENUM_BASE_QUIRKS is not set
CONFIG_IIO_ST_SENSORS_I2C=m
CONFIG_IIO_ST_SENSORS_CORE=m

#
# Digital to analog converters
#
CONFIG_AD5064=m
CONFIG_AD5380=m
CONFIG_AD5446=m
# CONFIG_MAX517 is not set
# CONFIG_MCP4725 is not set

#
# Frequency Synthesizers DDS/PLL
#

#
# Clock Generator/Distribution
#

#
# Phase-Locked Loop (PLL) frequency synthesizers
#

#
# Digital gyroscope sensors
#
CONFIG_HID_SENSOR_GYRO_3D=m
CONFIG_IIO_ST_GYRO_3AXIS=m
CONFIG_IIO_ST_GYRO_I2C_3AXIS=m
# CONFIG_ITG3200 is not set

#
# Inertial measurement units
#
CONFIG_INV_MPU6050_IIO=m

#
# Light sensors
#
# CONFIG_ADJD_S311 is not set
# CONFIG_SENSORS_TSL2563 is not set
CONFIG_VCNL4000=m
# CONFIG_HID_SENSOR_ALS is not set

#
# Magnetometer sensors
#
CONFIG_AK8975=m
# CONFIG_HID_SENSOR_MAGNETOMETER_3D is not set
# CONFIG_IIO_ST_MAGN_3AXIS is not set
CONFIG_PWM=y
# CONFIG_PWM_SAMSUNG is not set
CONFIG_IRQCHIP=y
CONFIG_ARM_VIC=y
CONFIG_ARM_VIC_NR=4
# CONFIG_IPACK_BUS is not set
CONFIG_RESET_CONTROLLER=y

#
# File systems
#
# CONFIG_FS_POSIX_ACL is not set
CONFIG_FILE_LOCKING=y
CONFIG_FSNOTIFY=y
CONFIG_DNOTIFY=y
# CONFIG_INOTIFY_USER is not set
# CONFIG_FANOTIFY is not set
# CONFIG_QUOTA is not set
# CONFIG_QUOTACTL is not set
# CONFIG_AUTOFS4_FS is not set
CONFIG_FUSE_FS=m
CONFIG_CUSE=m

#
# Caches
#
CONFIG_FSCACHE=m
CONFIG_FSCACHE_STATS=y
CONFIG_FSCACHE_HISTOGRAM=y
# CONFIG_FSCACHE_DEBUG is not set
# CONFIG_FSCACHE_OBJECT_LIST is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_VMCORE=y
# CONFIG_PROC_SYSCTL is not set
CONFIG_SYSFS=y
# CONFIG_HUGETLB_PAGE is not set
CONFIG_CONFIGFS_FS=m
# CONFIG_MISC_FILESYSTEMS is not set
# CONFIG_NETWORK_FILESYSTEMS is not set
# CONFIG_NLS is not set
CONFIG_DLM=m
# CONFIG_DLM_DEBUG is not set

#
# Kernel hacking
#
# CONFIG_PRINTK_TIME is not set
CONFIG_DEFAULT_MESSAGE_LOGLEVEL=4
# CONFIG_ENABLE_WARN_DEPRECATED is not set
CONFIG_ENABLE_MUST_CHECK=y
CONFIG_FRAME_WARN=1024
# CONFIG_MAGIC_SYSRQ is not set
CONFIG_STRIP_ASM_SYMS=y
CONFIG_READABLE_ASM=y
CONFIG_UNUSED_SYMBOLS=y
CONFIG_DEBUG_FS=y
CONFIG_HEADERS_CHECK=y
CONFIG_DEBUG_SECTION_MISMATCH=y
CONFIG_DEBUG_KERNEL=y
# CONFIG_DEBUG_SHIRQ is not set
# CONFIG_LOCKUP_DETECTOR is not set
# CONFIG_PANIC_ON_OOPS is not set
CONFIG_PANIC_ON_OOPS_VALUE=0
# CONFIG_DETECT_HUNG_TASK is not set
CONFIG_SCHED_DEBUG=y
CONFIG_SCHEDSTATS=y
CONFIG_TIMER_STATS=y
CONFIG_DEBUG_OBJECTS=y
CONFIG_DEBUG_OBJECTS_SELFTEST=y
CONFIG_DEBUG_OBJECTS_FREE=y
# CONFIG_DEBUG_OBJECTS_TIMERS is not set
# CONFIG_DEBUG_OBJECTS_WORK is not set
CONFIG_DEBUG_OBJECTS_RCU_HEAD=y
CONFIG_DEBUG_OBJECTS_PERCPU_COUNTER=y
CONFIG_DEBUG_OBJECTS_ENABLE_DEFAULT=1
CONFIG_HAVE_DEBUG_KMEMLEAK=y
# CONFIG_DEBUG_KMEMLEAK is not set
CONFIG_DEBUG_RT_MUTEXES=y
CONFIG_DEBUG_PI_LIST=y
# CONFIG_RT_MUTEX_TESTER is not set
CONFIG_DEBUG_SPINLOCK=y
CONFIG_DEBUG_MUTEXES=y
CONFIG_DEBUG_LOCK_ALLOC=y
# CONFIG_PROVE_LOCKING is not set
CONFIG_LOCKDEP=y
CONFIG_LOCK_STAT=y
# CONFIG_DEBUG_LOCKDEP is not set
# CONFIG_DEBUG_ATOMIC_SLEEP is not set
CONFIG_DEBUG_LOCKING_API_SELFTESTS=y
CONFIG_STACKTRACE=y
# CONFIG_DEBUG_STACK_USAGE is not set
# CONFIG_DEBUG_KOBJECT is not set
CONFIG_DEBUG_BUGVERBOSE=y
# CONFIG_DEBUG_INFO is not set
# CONFIG_DEBUG_VM is not set
CONFIG_DEBUG_NOMMU_REGIONS=y
CONFIG_DEBUG_WRITECOUNT=y
# CONFIG_DEBUG_MEMORY_INIT is not set
# CONFIG_DEBUG_LIST is not set
CONFIG_TEST_LIST_SORT=y
# CONFIG_DEBUG_SG is not set
CONFIG_DEBUG_NOTIFIERS=y
CONFIG_DEBUG_CREDENTIALS=y
CONFIG_FRAME_POINTER=y
CONFIG_BOOT_PRINTK_DELAY=y

#
# RCU Debugging
#
CONFIG_SPARSE_RCU_POINTER=y
# CONFIG_RCU_TORTURE_TEST is not set
CONFIG_RCU_CPU_STALL_TIMEOUT=21
CONFIG_RCU_TRACE=y
CONFIG_KPROBES_SANITY_TEST=y
CONFIG_BACKTRACE_SELF_TEST=m
CONFIG_DEBUG_FORCE_WEAK_PER_CPU=y
CONFIG_NOTIFIER_ERROR_INJECTION=m
# CONFIG_PM_NOTIFIER_ERROR_INJECT is not set
# CONFIG_FAULT_INJECTION is not set
CONFIG_LATENCYTOP=y
# CONFIG_DEBUG_PAGEALLOC is not set
CONFIG_HAVE_FUNCTION_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y
CONFIG_HAVE_DYNAMIC_FTRACE=y
CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y
CONFIG_HAVE_SYSCALL_TRACEPOINTS=y
CONFIG_HAVE_C_RECORDMCOUNT=y
CONFIG_TRACE_CLOCK=y
CONFIG_TRACING_SUPPORT=y
# CONFIG_FTRACE is not set
# CONFIG_RBTREE_TEST is not set
# CONFIG_INTERVAL_TREE_TEST is not set
# CONFIG_BUILD_DOCSRC is not set
CONFIG_DYNAMIC_DEBUG=y
CONFIG_DMA_API_DEBUG=y
CONFIG_ATOMIC64_SELFTEST=y
CONFIG_SAMPLES=y
CONFIG_SAMPLE_KOBJECT=m
CONFIG_SAMPLE_KPROBES=m
# CONFIG_SAMPLE_KRETPROBES is not set
# CONFIG_SAMPLE_HW_BREAKPOINT is not set
# CONFIG_SAMPLE_KFIFO is not set
CONFIG_HAVE_ARCH_KGDB=y
# CONFIG_KGDB is not set
CONFIG_TEST_KSTRTOX=m
# CONFIG_DEBUG_USER is not set
CONFIG_DEBUG_LL=y
# CONFIG_DEBUG_S3C_UART0 is not set
# CONFIG_DEBUG_S3C_UART1 is not set
# CONFIG_DEBUG_S3C_UART2 is not set
CONFIG_DEBUG_LL_UART_NONE=y
# CONFIG_DEBUG_ICEDCC is not set
# CONFIG_DEBUG_SEMIHOSTING is not set
CONFIG_DEBUG_LL_INCLUDE="mach/debug-macro.S"
CONFIG_UNCOMPRESS_INCLUDE="mach/uncompress.h"
# CONFIG_EARLY_PRINTK is not set
# CONFIG_ARM_KPROBES_TEST is not set

#
# Security options
#
CONFIG_KEYS=y
# CONFIG_TRUSTED_KEYS is not set
CONFIG_ENCRYPTED_KEYS=y
# CONFIG_KEYS_DEBUG_PROC_KEYS is not set
# CONFIG_SECURITY_DMESG_RESTRICT is not set
CONFIG_SECURITY=y
CONFIG_SECURITYFS=y
CONFIG_SECURITY_NETWORK=y
# CONFIG_SECURITY_NETWORK_XFRM is not set
CONFIG_SECURITY_PATH=y
# CONFIG_SECURITY_SELINUX is not set
CONFIG_SECURITY_SMACK=y
# CONFIG_SECURITY_TOMOYO is not set
CONFIG_SECURITY_APPARMOR=y
CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE=1
CONFIG_SECURITY_YAMA=y
# CONFIG_SECURITY_YAMA_STACKED is not set
CONFIG_INTEGRITY=y
# CONFIG_INTEGRITY_SIGNATURE is not set
CONFIG_IMA=y
CONFIG_IMA_MEASURE_PCR_IDX=10
# CONFIG_IMA_AUDIT is not set
CONFIG_IMA_LSM_RULES=y
CONFIG_IMA_APPRAISE=y
CONFIG_EVM=y
CONFIG_EVM_HMAC_VERSION=2
# CONFIG_DEFAULT_SECURITY_SMACK is not set
CONFIG_DEFAULT_SECURITY_APPARMOR=y
# CONFIG_DEFAULT_SECURITY_YAMA is not set
# CONFIG_DEFAULT_SECURITY_DAC is not set
CONFIG_DEFAULT_SECURITY="apparmor"
CONFIG_CRYPTO=y

#
# Crypto core or helper
#
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_ALGAPI2=y
CONFIG_CRYPTO_AEAD=m
CONFIG_CRYPTO_AEAD2=y
CONFIG_CRYPTO_BLKCIPHER=y
CONFIG_CRYPTO_BLKCIPHER2=y
CONFIG_CRYPTO_HASH=y
CONFIG_CRYPTO_HASH2=y
CONFIG_CRYPTO_RNG=y
CONFIG_CRYPTO_RNG2=y
CONFIG_CRYPTO_PCOMP2=y
CONFIG_CRYPTO_MANAGER=y
CONFIG_CRYPTO_MANAGER2=y
# CONFIG_CRYPTO_USER is not set
# CONFIG_CRYPTO_MANAGER_DISABLE_TESTS is not set
CONFIG_CRYPTO_GF128MUL=m
# CONFIG_CRYPTO_NULL is not set
CONFIG_CRYPTO_WORKQUEUE=y
# CONFIG_CRYPTO_CRYPTD is not set
CONFIG_CRYPTO_AUTHENC=m
# CONFIG_CRYPTO_TEST is not set

#
# Authenticated Encryption with Associated Data
#
CONFIG_CRYPTO_CCM=m
# CONFIG_CRYPTO_GCM is not set
CONFIG_CRYPTO_SEQIV=m

#
# Block modes
#
CONFIG_CRYPTO_CBC=y
CONFIG_CRYPTO_CTR=m
# CONFIG_CRYPTO_CTS is not set
CONFIG_CRYPTO_ECB=m
# CONFIG_CRYPTO_LRW is not set
# CONFIG_CRYPTO_PCBC is not set
# CONFIG_CRYPTO_XTS is not set

#
# Hash modes
#
CONFIG_CRYPTO_CMAC=m
CONFIG_CRYPTO_HMAC=y
CONFIG_CRYPTO_XCBC=m
# CONFIG_CRYPTO_VMAC is not set

#
# Digest
#
CONFIG_CRYPTO_CRC32C=m
CONFIG_CRYPTO_CRC32=m
# CONFIG_CRYPTO_GHASH is not set
CONFIG_CRYPTO_MD4=m
CONFIG_CRYPTO_MD5=y
CONFIG_CRYPTO_MICHAEL_MIC=m
# CONFIG_CRYPTO_RMD128 is not set
# CONFIG_CRYPTO_RMD160 is not set
# CONFIG_CRYPTO_RMD256 is not set
CONFIG_CRYPTO_RMD320=m
CONFIG_CRYPTO_SHA1=y
CONFIG_CRYPTO_SHA1_ARM=m
CONFIG_CRYPTO_SHA256=y
# CONFIG_CRYPTO_SHA512 is not set
CONFIG_CRYPTO_TGR192=m
CONFIG_CRYPTO_WP512=m

#
# Ciphers
#
CONFIG_CRYPTO_AES=y
CONFIG_CRYPTO_AES_ARM=m
CONFIG_CRYPTO_ANUBIS=m
CONFIG_CRYPTO_ARC4=m
CONFIG_CRYPTO_BLOWFISH=m
CONFIG_CRYPTO_BLOWFISH_COMMON=m
CONFIG_CRYPTO_CAMELLIA=m
CONFIG_CRYPTO_CAST_COMMON=m
CONFIG_CRYPTO_CAST5=m
# CONFIG_CRYPTO_CAST6 is not set
CONFIG_CRYPTO_DES=m
# CONFIG_CRYPTO_FCRYPT is not set
# CONFIG_CRYPTO_KHAZAD is not set
# CONFIG_CRYPTO_SALSA20 is not set
# CONFIG_CRYPTO_SEED is not set
CONFIG_CRYPTO_SERPENT=m
CONFIG_CRYPTO_TEA=m
CONFIG_CRYPTO_TWOFISH=m
CONFIG_CRYPTO_TWOFISH_COMMON=m

#
# Compression
#
CONFIG_CRYPTO_DEFLATE=m
# CONFIG_CRYPTO_ZLIB is not set
# CONFIG_CRYPTO_LZO is not set
# CONFIG_CRYPTO_LZ4 is not set
# CONFIG_CRYPTO_LZ4HC is not set

#
# Random Number Generation
#
# CONFIG_CRYPTO_ANSI_CPRNG is not set
CONFIG_CRYPTO_USER_API=m
# CONFIG_CRYPTO_USER_API_HASH is not set
CONFIG_CRYPTO_USER_API_SKCIPHER=m
# CONFIG_CRYPTO_HW is not set
CONFIG_ASYMMETRIC_KEY_TYPE=m
CONFIG_ASYMMETRIC_PUBLIC_KEY_SUBTYPE=m
# CONFIG_PUBLIC_KEY_ALGO_RSA is not set
# CONFIG_X509_CERTIFICATE_PARSER is not set
# CONFIG_BINARY_PRINTF is not set

#
# Library routines
#
CONFIG_BITREVERSE=m
CONFIG_GENERIC_STRNCPY_FROM_USER=y
CONFIG_GENERIC_STRNLEN_USER=y
CONFIG_GENERIC_PCI_IOMAP=y
CONFIG_GENERIC_IO=y
CONFIG_CRC_CCITT=m
CONFIG_CRC16=m
CONFIG_CRC_T10DIF=m
CONFIG_CRC_ITU_T=m
CONFIG_CRC32=m
# CONFIG_CRC32_SELFTEST is not set
# CONFIG_CRC32_SLICEBY8 is not set
# CONFIG_CRC32_SLICEBY4 is not set
CONFIG_CRC32_SARWATE=y
# CONFIG_CRC32_BIT is not set
CONFIG_CRC7=m
CONFIG_LIBCRC32C=m
# CONFIG_CRC8 is not set
CONFIG_AUDIT_GENERIC=y
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=m
CONFIG_LZO_COMPRESS=y
CONFIG_LZO_DECOMPRESS=y
CONFIG_LZ4_DECOMPRESS=y
CONFIG_XZ_DEC=m
CONFIG_XZ_DEC_X86=y
# CONFIG_XZ_DEC_POWERPC is not set
CONFIG_XZ_DEC_IA64=y
CONFIG_XZ_DEC_ARM=y
CONFIG_XZ_DEC_ARMTHUMB=y
CONFIG_XZ_DEC_SPARC=y
CONFIG_XZ_DEC_BCJ=y
CONFIG_XZ_DEC_TEST=m
CONFIG_DECOMPRESS_GZIP=y
CONFIG_DECOMPRESS_LZO=y
CONFIG_DECOMPRESS_LZ4=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_DMA=y
CONFIG_DQL=y
CONFIG_NLATTR=y
CONFIG_GENERIC_ATOMIC64=y
CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE=y
CONFIG_AVERAGE=y
CONFIG_CLZ_TAB=y
CONFIG_CORDIC=m
CONFIG_DDR=y
CONFIG_MPILIB=m
CONFIG_VIRTUALIZATION=y

#
# Virtio drivers
#

From nicolas.ferre at atmel.com  Wed Apr 17 05:35:24 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Wed, 17 Apr 2013 11:35:24 +0200
Subject: [RFC PATCH 2/2] ARM: DT: kernel: DT cpu node bindings update
In-Reply-To: <1366042402-8987-3-git-send-email-lorenzo.pieralisi@arm.com>
References: <1366042402-8987-1-git-send-email-lorenzo.pieralisi@arm.com>
 <1366042402-8987-3-git-send-email-lorenzo.pieralisi@arm.com>
Message-ID: <516E6CDC.9010005@atmel.com>

On 04/15/2013 06:13 PM, Lorenzo Pieralisi :
> In order to extend the current cpu nodes bindings to newer CPUs
> inclusive of AArch64 and to update support for older ARM CPUs this
> patch updates device tree documentation for the cpu nodes bindings.
> 
> Main changes:
> 
> - adds 64-bit bindings (inclusive of cpus node #address-cells updates)
> - defines behaviour on pre and post v7 uniprocessor systems
> - adds ARM 11MPcore specific reg property definition
> 
> DT cpu map parsing code must be made compliant with the latest bindings
> updates, hence this patch also updates the arm_dt_init_cpu_maps() function
> with checks and additional parsing rules.
> 
> Uniprocessor systems predating v7 do not parse the cpus node at all
> since the reg property is meaningless on those systems.
> 
> Device trees for 64-bit systems can be taken as device tree input also
> for 64-bit CPUs running in 32-bit mode. The code checks that the reg entries
> are zeroed as required in the respective fields and detects automatically
> the cpus node #address-cells value so that device tree written for
> 64-bit ARM platforms (cpus #address-cells == 2) can still be taken as
> input. The correct device tree entries are to be set up by the boot
> loader, kernel code just checks that device tree entries in the cpus
> node are as expected for a 32-bit CPU (reg[63:24] == 0).
> 
> cpu node entries with invalid reg property or containing duplicates are
> ignored and the device tree parsing is not stopped anymore when such
> entries are encountered, the device tree cpu entry is just skipped.
> 
> A device tree with cpu nodes missing the boot CPU MPIDR is considered a
> hard error and the kernel flags this up as a bug to force firmware updates.
> 
> The updates to cpus/cpu node bindings for ARM require all in-kernel dts files
> present in the mainline to be made compliant to the latest specification.
> 
> This patch also updates ARM in-kernel non-compliant dts files to the latest
> cpus/cpu nodes bindings specification.
> 
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
> ---
>  Documentation/devicetree/bindings/arm/cpus.txt | 335 +++++++++++++++++++++----
>  arch/arm/boot/dts/exynos5440.dtsi              |   7 +
>  arch/arm/boot/dts/omap3.dtsi                   |   4 +
>  arch/arm/boot/dts/omap4.dtsi                   |   5 +
>  arch/arm/boot/dts/omap5.dtsi                   |   5 +
>  arch/arm/boot/dts/r8a7740.dtsi                 |   3 +
>  arch/arm/boot/dts/sh7372.dtsi                  |   4 +
>  arch/arm/boot/dts/sunxi.dtsi                   |   4 +

Hi,

If it can be done easily, can you please consider the upcoming (3.10)
cortex-a5 SoC:

arch/arm/boot/dts/sama5d3.dtsi

It is in linux-next through arm-soc/at91/at91/soc


>  arch/arm/kernel/devtree.c                      |  82 +++---
>  9 files changed, 377 insertions(+), 72 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt
> index f32494d..b1ef3d8 100644
> --- a/Documentation/devicetree/bindings/arm/cpus.txt
> +++ b/Documentation/devicetree/bindings/arm/cpus.txt
> @@ -1,4 +1,6 @@
> -* ARM CPUs binding description
> +=============================
> +ARM CPUs bindings description
> +=============================
>  
>  The device tree allows to describe the layout of CPUs in a system through
>  the "cpus" node, which in turn contains a number of subnodes (ie "cpu")
> @@ -8,70 +10,317 @@ Bindings for CPU nodes follow the ePAPR standard, available from:
>  
>  http://devicetree.org
>  
> -For the ARM architecture every CPU node must contain the following properties:
> -
> -- device_type:	must be "cpu"
> -- reg:		property matching the CPU MPIDR[23:0] register bits
> -		reg[31:24] bits must be set to 0
> -- compatible:	should be one of:
> -		"arm,arm1020"
> -		"arm,arm1020e"
> -		"arm,arm1022"
> -		"arm,arm1026"
> -		"arm,arm720"
> -		"arm,arm740"
> -		"arm,arm7tdmi"
> -		"arm,arm920"

Here we have: "arm,arm920t" for at91rm9200.dtsi

> -		"arm,arm922"
> -		"arm,arm925"
> -		"arm,arm926"

Oh, I missed this one: the strange thing is that *all* arm926 variants
have a compatible string of this form: "arm,arm926ejs"

(using: git grep "arm,arm9" next/master)

Should we change? Is there a rule for this naming?

> -		"arm,arm940"
> -		"arm,arm946"
> -		"arm,arm9tdmi"
> -		"arm,cortex-a5"
> -		"arm,cortex-a7"
> -		"arm,cortex-a8"
> -		"arm,cortex-a9"
> -		"arm,cortex-a15"
> -		"arm,arm1136"
> -		"arm,arm1156"
> -		"arm,arm1176"
> -		"arm,arm11mpcore"
> -		"faraday,fa526"
> -		"intel,sa110"
> -		"intel,sa1100"
> -		"marvell,feroceon"
> -		"marvell,mohawk"
> -		"marvell,xsc3"
> -		"marvell,xscale"

[..]

Thanks, best regards,
-- 
Nicolas Ferre


From will.deacon at arm.com  Wed Apr 17 05:48:29 2013
From: will.deacon at arm.com (Will Deacon)
Date: Wed, 17 Apr 2013 10:48:29 +0100
Subject: [PATCH] Report double word access atomicity on LPAE enabled
 targets through AUXV
In-Reply-To: <20130416172258.GE3770@mudshark.cambridge.arm.com>
References: <C3FF039D-7DE3-4A99-8317-789094095D8B@oracle.com>
 <20130408142406.GL17995@n2100.arm.linux.org.uk>
 <20130408155749.GS17476@mudshark.cambridge.arm.com>
 <CD54D5A4-2E19-49D9-B6E7-051F36AB5DF8@oracle.com>
 <20130416172258.GE3770@mudshark.cambridge.arm.com>
Message-ID: <20130417094829.GA19492@mudshark.cambridge.arm.com>

On Tue, Apr 16, 2013 at 06:22:58PM +0100, Will Deacon wrote:
> Patch below...

[...]

> +#define HWCAP_LPAE     (1 << 20)

[...]

> @@ -875,6 +880,7 @@ static const char *hwcap_str[] = {
>         "vfpv4",
>         "idiva",
>         "idivt",
> +       "atomicd",
>         NULL
>  };

You can tell I was in two minds about this, but that string should read
"lpae".

Will


From arnd at arndb.de  Wed Apr 17 05:48:56 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed, 17 Apr 2013 11:48:56 +0200
Subject: [RFC PATCH 2/2] ARM: DT: kernel: DT cpu node bindings update
In-Reply-To: <1366042402-8987-3-git-send-email-lorenzo.pieralisi@arm.com>
References: <1366042402-8987-1-git-send-email-lorenzo.pieralisi@arm.com>
 <1366042402-8987-3-git-send-email-lorenzo.pieralisi@arm.com>
Message-ID: <201304171148.57146.arnd@arndb.de>

On Monday 15 April 2013, Lorenzo Pieralisi wrote:
> -               "arm,cortex-a9"
> -               "arm,cortex-a15"
> -               "arm,arm1136"
> -               "arm,arm1156"
> -               "arm,arm1176"
> -               "arm,arm11mpcore"
> -               "faraday,fa526"
> -               "intel,sa110"
> -               "intel,sa1100"
> -               "marvell,feroceon"
> -               "marvell,mohawk"
> -               "marvell,xsc3"
> -               "marvell,xscale"

> +                           "arm,cortex-a9"
> +                           "arm,cortex-a15"
> +                           "arm,cortex-a57"
> +                           "arm,arm1136"
> +                           "arm,arm1156"
> +                           "arm,arm1176"
> +                           "arm,arm11mpcore"
> +                           "faraday,fa526"
> +                           "intel,sa110"
> +                           "intel,sa1100"
> +                           "marvell,feroceon"
> +                           "marvell,mohawk"
> +                           "marvell,xsc3"
> +                           "marvell,xscale"

I see you are adding cortex-a57 here, but there are actually a couple
of other cores that we could add here. It also makes sense to sort these
alphanumerically I think, and move arm10 after arm9, as well as arm11
before cortex.

The ones that I find missing but actually used are:

	"arm,cortex-a53"
	"arm,cortex-m0"
	"arm,cortex-m0+"
	"arm,cortex-m1"
	"arm,cortex-m3"
	"arm,cortex-m4"
	"arm,cortex-r4"
	"arm,cortex-r5"
	"arm,cortex-r7"
	"marvell,pj4"
	"qcom,scorpion"
	"qcom,krait"

There are also a number of faraday cores that we don't support in
Linux (fa626, fa626te, fa726te, ...), not sure if we should attempt to
list them all here. The only one that is being worked on at the moment
is based on fa526.

There are also a number of 64 bit cores that other companies have announced,
but I'm not sure if the names are final yet.

	Arnd


From will.deacon at arm.com  Wed Apr 17 06:01:36 2013
From: will.deacon at arm.com (Will Deacon)
Date: Wed, 17 Apr 2013 11:01:36 +0100
Subject: [Suggestion] ARM:S5pv210: compiling issue for s5pv210 by using
 randconfig
In-Reply-To: <516E6A8E.3000001@asianux.com>
References: <514FB202.3040807@asianux.com> <515BFA8D.2000204@asianux.com>
 <20130403101018.GE11040@mudshark.cambridge.arm.com>
 <515C047A.9010906@asianux.com> <516E6A8E.3000001@asianux.com>
Message-ID: <20130417100136.GB19492@mudshark.cambridge.arm.com>

[adding Arnd, as he plays with randconfig too]

On Wed, Apr 17, 2013 at 10:25:34AM +0100, Chen Gang wrote:
> On 2013?04?03? 18:29, Chen Gang wrote:
>   I repeat it again (but it report another location), and put the config as attachment.

Thanks.

>   when you have time, please help check (if you have no time, I should try)
> 
>   the below is the new related information:

[...]

> arm-linux-gnu-gcc -Wp,-MD,arch/arm/vfp/.vfphw.o.d  -nostdinc -isystem /usr/lib/gcc/arm-linux-gnueabi/4.7.1/include -I/root/linux-next/arch/arm/include -Iarch/arm/include/generated  -Iinclude -I/root/linux-next/arch/arm/include/uapi -Iarch/arm/include/generated/uapi -I/root/linux-next/include/uapi -Iinclude/generated/uapi -include /root/linux-next/include/linux/kconfig.h -D__KERNEL__ -mlittle-endian -Iarch/arm/mach-s5pv210/include -Iarch/arm/plat-samsung/include  -D__ASSEMBLY__ -mabi=apcs-gnu -mno-thumb-interwork -marm -D__LINUX_ARM_ARCH__=4 -march=armv4t -mtune=arm9tdmi -include asm/unified.h -Wa,-mfpu=softvfp+vfp -mfloat-abi=soft        -c -o arch/arm/vfp/vfphw.o arch/arm/vfp/vfphw.S
> 
> 
>   compiling err:
> 
> arch/arm/vfp/vfphw.S: Assembler messages:
> arch/arm/vfp/vfphw.S:295: Error: selected processor does not support ARM mode `mrrc p11,3,r0,r1,c0'
> arch/arm/vfp/vfphw.S:295: Error: selected processor does not support ARM mode `mrrc p11,3,r0,r1,c1'

The problem here is that you've ended up targetting a platform (s5pv210)
that selects CPU_V7. VFP is then subsequently selected, but CONFIG_MMU=n, so
7TDMI and 9TDMI (v4 CPUs, no VFP) are selectable. Selecting either of those,
causes these warnings.

Unfortunately, I'm not sure how best to fix this. Most of the !MMU CPUs are
tied to a particular board (lots of `if ARCH_INTEGRATOR' predicates), but we
don't want to do that for 7tdmi.

If we could enforce the strict exclusion of {<= ARMv5} and {ARMv6+} in the
Kconfig, that would solve your problem.

Will


From p.zabel at pengutronix.de  Wed Apr 17 06:05:58 2013
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Wed, 17 Apr 2013 12:05:58 +0200
Subject: [PATCH v2] ARM i.MX6q: Fix periph_clk2_sel and periph2_clk2_sel clocks
Message-ID: <1366193158-10098-1-git-send-email-p.zabel@pengutronix.de>

The periph_clk2_sel mux can be set to pll3, osc/pll1_ref_clk, or osc/
pll2_burn_in_clk. The periph2_clk2_sel mux can be set to pll3 or pll2.

Signed-off-by: Philipp Zabel <p.zabel at pengutronix.de>
---
 arch/arm/mach-imx/clk-imx6q.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-imx/clk-imx6q.c b/arch/arm/mach-imx/clk-imx6q.c
index 1512590..ca17171 100644
--- a/arch/arm/mach-imx/clk-imx6q.c
+++ b/arch/arm/mach-imx/clk-imx6q.c
@@ -177,7 +177,8 @@ int imx6q_set_lpm(enum mxc_cpu_pwr_mode mode)
 static const char *step_sels[]	= { "osc", "pll2_pfd2_396m", };
 static const char *pll1_sw_sels[]	= { "pll1_sys", "step", };
 static const char *periph_pre_sels[]	= { "pll2_bus", "pll2_pfd2_396m", "pll2_pfd0_352m", "pll2_198m", };
-static const char *periph_clk2_sels[]	= { "pll3_usb_otg", "osc", };
+static const char *periph_clk2_sels[]	= { "pll3_usb_otg", "osc", "osc", "dummy", };
+static const char *periph2_clk2_sels[]	= { "pll3_usb_otg", "pll2_bus", };
 static const char *periph_sels[]	= { "periph_pre", "periph_clk2", };
 static const char *periph2_sels[]	= { "periph2_pre", "periph2_clk2", };
 static const char *axi_sels[]		= { "periph", "pll2_pfd2_396m", "pll3_pfd1_540m", };
@@ -369,8 +370,8 @@ int __init mx6q_clocks_init(void)
 	clk[pll1_sw]          = imx_clk_mux("pll1_sw",	        base + 0xc,  2,  1, pll1_sw_sels,      ARRAY_SIZE(pll1_sw_sels));
 	clk[periph_pre]       = imx_clk_mux("periph_pre",       base + 0x18, 18, 2, periph_pre_sels,   ARRAY_SIZE(periph_pre_sels));
 	clk[periph2_pre]      = imx_clk_mux("periph2_pre",      base + 0x18, 21, 2, periph_pre_sels,   ARRAY_SIZE(periph_pre_sels));
-	clk[periph_clk2_sel]  = imx_clk_mux("periph_clk2_sel",  base + 0x18, 12, 1, periph_clk2_sels,  ARRAY_SIZE(periph_clk2_sels));
-	clk[periph2_clk2_sel] = imx_clk_mux("periph2_clk2_sel", base + 0x18, 20, 1, periph_clk2_sels,  ARRAY_SIZE(periph_clk2_sels));
+	clk[periph_clk2_sel]  = imx_clk_mux("periph_clk2_sel",  base + 0x18, 12, 2, periph_clk2_sels,  ARRAY_SIZE(periph_clk2_sels));
+	clk[periph2_clk2_sel] = imx_clk_mux("periph2_clk2_sel", base + 0x18, 20, 1, periph2_clk2_sels, ARRAY_SIZE(periph2_clk2_sels));
 	clk[axi_sel]          = imx_clk_mux("axi_sel",          base + 0x14, 6,  2, axi_sels,          ARRAY_SIZE(axi_sels));
 	clk[esai_sel]         = imx_clk_mux("esai_sel",         base + 0x20, 19, 2, audio_sels,        ARRAY_SIZE(audio_sels));
 	clk[asrc_sel]         = imx_clk_mux("asrc_sel",         base + 0x30, 7,  2, audio_sels,        ARRAY_SIZE(audio_sels));
-- 
1.8.2.rc2



From linux at arm.linux.org.uk  Wed Apr 17 06:02:43 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Wed, 17 Apr 2013 11:02:43 +0100
Subject: [Suggestion] ARM:S5pv210: compiling issue for s5pv210 by using
 randconfig
In-Reply-To: <516E6A8E.3000001@asianux.com>
References: <514FB202.3040807@asianux.com> <515BFA8D.2000204@asianux.com>
 <20130403101018.GE11040@mudshark.cambridge.arm.com>
 <515C047A.9010906@asianux.com> <516E6A8E.3000001@asianux.com>
Message-ID: <20130417100243.GV14496@n2100.arm.linux.org.uk>

On Wed, Apr 17, 2013 at 05:25:34PM +0800, Chen Gang wrote:
> CONFIG_CPU_ARM7TDMI=y
> CONFIG_CPU_ARM9TDMI=y
> CONFIG_CPU_V7=y
> CONFIG_CPU_32v4T=y
> CONFIG_CPU_32v6K=y
> CONFIG_CPU_32v7=y

This is an invalid configuration.  A single kernel can not support ARMv7
and ARMv4T simultaneously.

The problem is caused by MMU=n, which exposes the CPU_ARM7TDMI and
CPU_ARM9TDMI options, which in turn select 32v4T.  This is in turn
caused by the incomplete integration of uclinux.

I think the only thing which can be done is to remove the ARM9TDMI
support code, which doesn't seem to be used by anything, and adjust
ARM7TDMI so that it isn't visible, but is selected by ARCH_AT91X40
(which seems to be its only user.)

Here's the slightly smaller version of that:

diff --git a/arch/arm/mach-at91/Kconfig.non_dt b/arch/arm/mach-at91/Kconfig.non_dt
index 6c24985..dc972e1 100644
--- a/arch/arm/mach-at91/Kconfig.non_dt
+++ b/arch/arm/mach-at91/Kconfig.non_dt
@@ -47,6 +47,7 @@ config ARCH_AT91X40
 	select ARCH_USES_GETTIMEOFFSET
 	select MULTI_IRQ_HANDLER
 	select SPARSE_IRQ
+	select CPU_ARM7TDMI
 
 endchoice
 
diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
index cb812a1..deb6c6a 100644
--- a/arch/arm/mm/Kconfig
+++ b/arch/arm/mm/Kconfig
@@ -6,7 +6,7 @@ comment "Processor Type"
 
 # ARM7TDMI
 config CPU_ARM7TDMI
-	bool "Support ARM7TDMI processor"
+	bool
 	depends on !MMU
 	select CPU_32v4T
 	select CPU_ABRT_LV4T
@@ -56,7 +56,7 @@ config CPU_ARM740T
 
 # ARM9TDMI
 config CPU_ARM9TDMI
-	bool "Support ARM9TDMI processor"
+	bool
 	depends on !MMU
 	select CPU_32v4T
 	select CPU_ABRT_NOMMU



From p.zabel at pengutronix.de  Wed Apr 17 06:06:19 2013
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Wed, 17 Apr 2013 12:06:19 +0200
Subject: [PATCH] ARM i.MX6q: Fix periph_clk2_sel and periph2_clk2_sel
 clocks
In-Reply-To: <516E5931.5010904@de.bosch.com>
References: <1365675812-21600-1-git-send-email-p.zabel@pengutronix.de>
 <20130412030228.GF16970@S2101-09.ap.freescale.net>
 <1365757419.5330.17.camel@pizza.hi.pengutronix.de>
 <516E5931.5010904@de.bosch.com>
Message-ID: <1366193179.4389.1.camel@pizza.hi.pengutronix.de>

Am Mittwoch, den 17.04.2013, 10:11 +0200 schrieb Dirk Behme:
> On 12.04.2013 11:03, Philipp Zabel wrote:
> > Am Freitag, den 12.04.2013, 11:02 +0800 schrieb Shawn Guo:
> >> On Thu, Apr 11, 2013 at 12:23:32PM +0200, Philipp Zabel wrote:
> >>> The periph_clk2_sel mux can be set to pll3, pll1, or
> >>> osc/pll2-bypass/pll2_burn_in_clk.
> >> Looking at IMX6DQRM Rev. 0, 11/2012, I see
> >>
> >> 13?12 periph_clk2_sel: Selector for peripheral clk2 clock multiplexer
> >>
> >> 	00 derive clock from pll3_sw_clk
> >> 	01 derive clock from pll1_ref_clk
> >> 	10 derive clock from pll2_burn_in_clk (default)
> >> 	11 reserved
> >>
> >> Are you sure pll1_ref_clk actually means pll1_sys?
> > 
> > No, pll1_sys indeed is pll1_sw_clk, not pll1_ref_clk.
> > 
> >> I searched the
> >> document and word "pll1_ref_clk" occurs only once.  But Figure 18-5. BUS
> >> clock generation on page 819 suggests it's OSC_CLK (24M).
> > 
> > This is consistent (24 MHz osc is the pll1 reference), and thus might be
> > correct. I'll fix the patch to keep periph_clk2_sels[1] = "osc".
> 
> Any update on this?

Thank you for the reminder, I've sent v2.

regards
Philipp



From linux at arm.linux.org.uk  Wed Apr 17 06:10:17 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Wed, 17 Apr 2013 11:10:17 +0100
Subject: [PATCH] ARM: shmobile: BOCK-W: enable CONFIG_PM_RUNTIME in
 defconfig
In-Reply-To: <201304170303.46193.sergei.shtylyov@cogentembedded.com>
References: <201304170303.46193.sergei.shtylyov@cogentembedded.com>
Message-ID: <20130417101017.GW14496@n2100.arm.linux.org.uk>

On Wed, Apr 17, 2013 at 03:03:45AM +0400, Sergei Shtylyov wrote:
> From: Vladimir Barinov <vladimir.barinov at cogentembedded.com>
> 
> Enable CONFIG_PM_RUNTIME in 'bockw_defconfig' -- it's already used by TMU, SCI,
> I2C, and Ether drivers to control the clocks...
> 
> Signed-off-by: Vladimir Barinov <vladimir.barinov at cogentembedded.com>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
> 
> ---
> The patch is atop of Simon's 'renesas.git' tree, 'renesas-next-20130416' tag.

Maybe you should send it to Simon rather than me for initial merging, who
would presumably know if this is the right thing for this bockw platform?


From gang.chen at asianux.com  Wed Apr 17 06:11:36 2013
From: gang.chen at asianux.com (Chen Gang)
Date: Wed, 17 Apr 2013 18:11:36 +0800
Subject: [Suggestion] ARM:S5pv210: compiling issue for s5pv210 by using
 randconfig
In-Reply-To: <20130417100136.GB19492@mudshark.cambridge.arm.com>
References: <514FB202.3040807@asianux.com> <515BFA8D.2000204@asianux.com>
 <20130403101018.GE11040@mudshark.cambridge.arm.com>
 <515C047A.9010906@asianux.com> <516E6A8E.3000001@asianux.com>
 <20130417100136.GB19492@mudshark.cambridge.arm.com>
Message-ID: <516E7558.4080005@asianux.com>

On 2013?04?17? 18:01, Will Deacon wrote:
> The problem here is that you've ended up targetting a platform (s5pv210)
> that selects CPU_V7. VFP is then subsequently selected, but CONFIG_MMU=n, so
> 7TDMI and 9TDMI (v4 CPUs, no VFP) are selectable. Selecting either of those,
> causes these warnings.
> 
> Unfortunately, I'm not sure how best to fix this. Most of the !MMU CPUs are
> tied to a particular board (lots of `if ARCH_INTEGRATOR' predicates), but we
> don't want to do that for 7tdmi.
> 
> If we could enforce the strict exclusion of {<= ARMv5} and {ARMv6+} in the
> Kconfig, that would solve your problem.

  thank you very much for your analysing.

  :-)

-- 
Chen Gang

Asianux Corporation


From nsekhar at ti.com  Wed Apr 17 06:15:12 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Wed, 17 Apr 2013 15:45:12 +0530
Subject: [PATCH 0/4] ARM: davinci: fix UART clock enabling
In-Reply-To: <A73F36158E33644199EB82C5EC81C7BC3EA4DCC9@DBDE01.ent.ti.com>
References: <1365510481-32129-1-git-send-email-prakash.pm@ti.com>
 <A73F36158E33644199EB82C5EC81C7BC3EA4DCC9@DBDE01.ent.ti.com>
Message-ID: <516E7630.7020906@ti.com>



On 4/17/2013 12:02 PM, Manjunathappa, Prakash wrote:
> Hi Sekhar,
> 
> On Tue, Apr 09, 2013 at 17:57:57, Manjunathappa, Prakash wrote:
>> Patch series addresses below issues:
>> 1) Do clk_get on dev_id when there is single clock for a module
>> 2) Fix garbled UART log with DT kernel on da850-evm.
>>
> 
> Could you please accept this series if you do not have review comments?

I have not yet gotten to reviewing this. Its unlikely it will get
reviewed and accepted for v3.10 so this will have to wait for v3.11.

Thanks,
Sekhar


From gang.chen at asianux.com  Wed Apr 17 06:17:32 2013
From: gang.chen at asianux.com (Chen Gang)
Date: Wed, 17 Apr 2013 18:17:32 +0800
Subject: [Suggestion] ARM:S5pv210: compiling issue for s5pv210 by using
 randconfig
In-Reply-To: <20130417100243.GV14496@n2100.arm.linux.org.uk>
References: <514FB202.3040807@asianux.com> <515BFA8D.2000204@asianux.com>
 <20130403101018.GE11040@mudshark.cambridge.arm.com>
 <515C047A.9010906@asianux.com> <516E6A8E.3000001@asianux.com>
 <20130417100243.GV14496@n2100.arm.linux.org.uk>
Message-ID: <516E76BC.7090704@asianux.com>

On 2013?04?17? 18:02, Russell King - ARM Linux wrote:
> On Wed, Apr 17, 2013 at 05:25:34PM +0800, Chen Gang wrote:
>> > CONFIG_CPU_ARM7TDMI=y
>> > CONFIG_CPU_ARM9TDMI=y
>> > CONFIG_CPU_V7=y
>> > CONFIG_CPU_32v4T=y
>> > CONFIG_CPU_32v6K=y
>> > CONFIG_CPU_32v7=y
> This is an invalid configuration.  A single kernel can not support ARMv7
> and ARMv4T simultaneously.
> 
> The problem is caused by MMU=n, which exposes the CPU_ARM7TDMI and
> CPU_ARM9TDMI options, which in turn select 32v4T.  This is in turn
> caused by the incomplete integration of uclinux.
> 
> I think the only thing which can be done is to remove the ARM9TDMI
> support code, which doesn't seem to be used by anything, and adjust
> ARM7TDMI so that it isn't visible, but is selected by ARCH_AT91X40
> (which seems to be its only user.)
> 
> Here's the slightly smaller version of that:
> 

  thank you very much for your analysing.

  should I do something for it next ?
    (at least, I should learn the information both of yours)
    is it suitable to integrate the patch below to next-* tree ?
      if it it suitable, need I do something for it ?

  thanks.

  :-)


> diff --git a/arch/arm/mach-at91/Kconfig.non_dt b/arch/arm/mach-at91/Kconfig.non_dt
> index 6c24985..dc972e1 100644
> --- a/arch/arm/mach-at91/Kconfig.non_dt
> +++ b/arch/arm/mach-at91/Kconfig.non_dt
> @@ -47,6 +47,7 @@ config ARCH_AT91X40
>  	select ARCH_USES_GETTIMEOFFSET
>  	select MULTI_IRQ_HANDLER
>  	select SPARSE_IRQ
> +	select CPU_ARM7TDMI
>  
>  endchoice
>  
> diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
> index cb812a1..deb6c6a 100644
> --- a/arch/arm/mm/Kconfig
> +++ b/arch/arm/mm/Kconfig
> @@ -6,7 +6,7 @@ comment "Processor Type"
>  
>  # ARM7TDMI
>  config CPU_ARM7TDMI
> -	bool "Support ARM7TDMI processor"
> +	bool
>  	depends on !MMU
>  	select CPU_32v4T
>  	select CPU_ABRT_LV4T
> @@ -56,7 +56,7 @@ config CPU_ARM740T
>  
>  # ARM9TDMI
>  config CPU_ARM9TDMI
> -	bool "Support ARM9TDMI processor"
> +	bool
>  	depends on !MMU
>  	select CPU_32v4T
>  	select CPU_ABRT_NOMMU
> 
> 
> 


-- 
Chen Gang

Asianux Corporation


From linux at arm.linux.org.uk  Wed Apr 17 06:19:06 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Wed, 17 Apr 2013 11:19:06 +0100
Subject: [PATCH] ARM: KVM: iterate over all CPUs for CPU compatibility
 check
In-Reply-To: <516810F7.7040601@arm.com>
References: <1365771875-5788-1-git-send-email-andre.przywara@linaro.org>
 <51680AF9.7040109@arm.com>
 <CAFEAcA-1HAG0pY-j-rqU=QmSoep3Di-KNPATvuou8ghRn3SaqA@mail.gmail.com>
 <516810F7.7040601@arm.com>
Message-ID: <20130417101906.GX14496@n2100.arm.linux.org.uk>

On Fri, Apr 12, 2013 at 02:49:43PM +0100, Marc Zyngier wrote:
> On 12/04/13 14:40, Peter Maydell wrote:
> > On 12 April 2013 14:24, Marc Zyngier <marc.zyngier at arm.com> wrote:
> >> Nak. The fact that one of the CPUs seem to hang is a sure sign that
> >> something is severely broken, and you definitely want to fix that issue,
> >> instead of blindly ignoring it.
> >>
> >> Additionally, it seems you're just papering over the issue. You should
> >> be able to exclude the A7 processors, but not completely deny KVM from
> >> running on the hardware.
> > 
> > Well that might be nice, as would fully supporting big.LITTLE
> > systems. But until somebody actually does that work it seems
> > like a better idea to fail gracefully rather than having a 50%
> > chance of failing gracefully and a 50% chance of going weird.
> 
> Nothing prevents the kernel (or even the user) from forcing the affinity
> of the CPU threads to the A15s. I'm not saying we should ignore the
> problem either. Just that the proposed approach is wrong.

But nothing guarantees that you get that affinity.  If you offline all
A15 CPUs, then you will find those threads running on whatever is left.
Affinity is just a hint, nothing more.


From girishks2000 at gmail.com  Wed Apr 17 06:22:23 2013
From: girishks2000 at gmail.com (Girish KS)
Date: Wed, 17 Apr 2013 15:52:23 +0530
Subject: [PATCH V4 2/5] spi: s3c64xx: added support for polling mode
In-Reply-To: <20130416121255.GA15878@sirena.org.uk>
References: <1366015230-18243-1-git-send-email-ks.giri@samsung.com>
 <20130416112035.GD26958@opensource.wolfsonmicro.com>
 <CAKrE-Kd4Vis0-V_n8zEzqJVBbEYvTiYS8hY_7s7AnUqaK2tFCQ@mail.gmail.com>
 <20130416121255.GA15878@sirena.org.uk>
Message-ID: <CAKrE-KfEetVCE7Q2OyA7dBtFNv71ydX_bNXxMTJK4dSdstoi_A@mail.gmail.com>

On Tue, Apr 16, 2013 at 5:42 PM, Mark Brown <broonie at kernel.org> wrote:
> On Tue, Apr 16, 2013 at 04:58:47PM +0530, Girish KS wrote:
>> On Tue, Apr 16, 2013 at 4:50 PM, Mark Brown <broonie at kernel.org> wrote:
>
>> > I'm missing patch 1 of this series.
>
>> its already  merged to stable tree after your review
>
> The patch numbering should reflect what you're posting.  If you're only
> sending four patches they should be numbered 1-4, otherwise it looks
> like there's something missing.  The goal with the numbers is to help
> people get the patches in the right order, the name should be enough to
> associate with other versions of the same patch.

OK. I will submit a new series ignoring the already merged patch.


From dave.martin at linaro.org  Wed Apr 17 06:30:07 2013
From: dave.martin at linaro.org (Dave Martin)
Date: Wed, 17 Apr 2013 11:30:07 +0100
Subject: [PATCH 3/3] ARM: tegra: make sure the pointer on 4 byte align
 when THUMB2_KERNEL enabled
In-Reply-To: <516D7A3B.9030404@wwwdotorg.org>
References: <1366066255-18192-1-git-send-email-swarren@wwwdotorg.org>
 <1366066255-18192-3-git-send-email-swarren@wwwdotorg.org>
 <20130416141252.GA2229@linaro.org> <516D7A3B.9030404@wwwdotorg.org>
Message-ID: <20130417102957.GA2249@linaro.org>

On Tue, Apr 16, 2013 at 10:20:11AM -0600, Stephen Warren wrote:
> On 04/16/2013 08:13 AM, Dave Martin wrote:
> > On Mon, Apr 15, 2013 at 04:50:55PM -0600, Stephen Warren wrote:
> >> From: Joseph Lo <josephl at nvidia.com>
> >>
> >> When building kernel with CONFIG_THUMB2_KERNEL, the data pointer in the
> >> assembly may not on the 4 byte alignment. Then causing a data abort when
> >> accessing the pointer. This patch add a ".align" flag in the head of the
> >> pointer. And always using 32-bit ADR Thumb instruction to make sure it
> >> won't build failure.
> >>
> >> Signed-off-by: Joseph Lo <josephl at nvidia.com>
> >> Signed-off-by: Stephen Warren <swarren at nvidia.com>
> >> ---
> >>  arch/arm/mach-tegra/reset-handler.S |    1 +
> >>  arch/arm/mach-tegra/sleep.h         |    3 ++-
> >>  2 files changed, 3 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/arch/arm/mach-tegra/reset-handler.S b/arch/arm/mach-tegra/reset-handler.S
> >> index e6de88a..519a8c5 100644
> >> --- a/arch/arm/mach-tegra/reset-handler.S
> >> +++ b/arch/arm/mach-tegra/reset-handler.S
> >> @@ -83,6 +83,7 @@ ENDPROC(tegra_resume)
> >>  
> >>  #ifdef CONFIG_CACHE_L2X0
> >>  	.globl	l2x0_saved_regs_addr
> >> +	.align
> >>  l2x0_saved_regs_addr:
> >>  	.long	0
> >>  #endif
> >> diff --git a/arch/arm/mach-tegra/sleep.h b/arch/arm/mach-tegra/sleep.h
> >> index 4ffae54..8e9b6af 100644
> >> --- a/arch/arm/mach-tegra/sleep.h
> >> +++ b/arch/arm/mach-tegra/sleep.h
> >> @@ -92,7 +92,8 @@
> >>  
> >>  #ifdef CONFIG_CACHE_L2X0
> >>  .macro l2_cache_resume, tmp1, tmp2, tmp3, phys_l2x0_saved_regs
> >> -	adr	\tmp1, \phys_l2x0_saved_regs
> >> + ARM(	adr	\tmp1, \phys_l2x0_saved_regs )
> >> + THUMB(	adr.w	\tmp1, \phys_l2x0_saved_regs )
> > 
> > Can you give an example of the assembler error you get without this?
> 
> arch/arm/mach-tegra/reset-handler.S: Assembler messages:
> arch/arm/mach-tegra/reset-handler.S:78: Error: invalid immediate for
> address calculation (value = 0x00000004)

The immediate in the 16-bit form of ADR is alignment-sensitive, and
can't address anything that's not on a word boundary.  What if you just
have the .align, without adr.w?

> This is with gcc-4.5.3, as:
> GNU assembler (crosstool-NG hg_unknown at 20110628.165246) 2.20.1.20100303
> 
> > The target symbol is local and the assembler can see where it is,
> > so it should choose the correct variant for the adr instruction
> > with no need for the ".w" suffix.
> > 
> > If not, it could mean that there is a bug in the version of the
> > assembler you're using.
> 
> True. Switching to the Ubuntu-packaged ARM cross-compiler that ships
> with Ubuntu 12.10, I do not see this problem.
> 
> Still, many people probably still use older compilers.
> 
> > If it's definitely needed, you can append a Thumb-only .w suffix with
> > 
> > 	W(adr)	\tmp1, \phys_l2x0_saved_regs
> > 
> > ...which is slightly neater.
> 
> Yes, that certainly works too, even without the .align change in
> reset-handler.S.

Sure, although the unaligned access is not such a good idea anyway.

Keeping the adr fix is harmless, I just wanted to understand why it's
needed.

Cheers
---Dave


From marc.zyngier at arm.com  Wed Apr 17 06:35:10 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 17 Apr 2013 11:35:10 +0100
Subject: [PATCH] ARM: KVM: iterate over all CPUs for CPU compatibility
 check
In-Reply-To: <20130417101906.GX14496@n2100.arm.linux.org.uk>
References: <1365771875-5788-1-git-send-email-andre.przywara@linaro.org>
 <51680AF9.7040109@arm.com>
 <CAFEAcA-1HAG0pY-j-rqU=QmSoep3Di-KNPATvuou8ghRn3SaqA@mail.gmail.com>
 <516810F7.7040601@arm.com> <20130417101906.GX14496@n2100.arm.linux.org.uk>
Message-ID: <516E7ADE.5090601@arm.com>

On 17/04/13 11:19, Russell King - ARM Linux wrote:
> On Fri, Apr 12, 2013 at 02:49:43PM +0100, Marc Zyngier wrote:
>> On 12/04/13 14:40, Peter Maydell wrote:
>>> On 12 April 2013 14:24, Marc Zyngier <marc.zyngier at arm.com> wrote:
>>>> Nak. The fact that one of the CPUs seem to hang is a sure sign that
>>>> something is severely broken, and you definitely want to fix that issue,
>>>> instead of blindly ignoring it.
>>>>
>>>> Additionally, it seems you're just papering over the issue. You should
>>>> be able to exclude the A7 processors, but not completely deny KVM from
>>>> running on the hardware.
>>>
>>> Well that might be nice, as would fully supporting big.LITTLE
>>> systems. But until somebody actually does that work it seems
>>> like a better idea to fail gracefully rather than having a 50%
>>> chance of failing gracefully and a 50% chance of going weird.
>>
>> Nothing prevents the kernel (or even the user) from forcing the affinity
>> of the CPU threads to the A15s. I'm not saying we should ignore the
>> problem either. Just that the proposed approach is wrong.
> 
> But nothing guarantees that you get that affinity.  If you offline all
> A15 CPUs, then you will find those threads running on whatever is left.
> Affinity is just a hint, nothing more.

I completely agree with you. But if we're left with only CPUs we can't
run on, we're screwed and must abort.

It's the same story as the RealView PB-X, where only one of the two A9
has NEON. If the NEON-capable core is down, any process using NEON is
virtually dead.

Should that be a reason to completely disable the HW (in this case the 3
A7s)? I'm not sure...

	M.
-- 
Jazz is not dead. It just smells funny...



From andre.przywara at linaro.org  Wed Apr 17 06:52:01 2013
From: andre.przywara at linaro.org (Andre Przywara)
Date: Wed, 17 Apr 2013 12:52:01 +0200
Subject: [PATCH] ARM: KVM: iterate over all CPUs for CPU compatibility check
Message-ID: <1366195921-28053-1-git-send-email-andre.przywara@linaro.org>

kvm_target_cpus() checks the compatibility of the used CPU with
KVM, which is currently limited to ARM Cortex-A15 cores.
However by calling it only once on any random CPU it assumes that
all cores are the same, which is not true for big.LITTLE parts.

After doing about 40 boots on a TC-2 core tile, I found it running
in all but one case on one of the A7 cores (which correctly denied
KVM initialization). On the 39th boot however the code ran on
an A15, leading to a hang after returning success:

...
TCP: reno registered
UDP hash table entries: 512 (order: 2, 16384 bytes)
UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
NET: Registered protocol family 1
kvm_target_cpu() on CPU #1, part is c0f0
 ... (pause for a while) ...
INFO: rcu_sched self-detected stall on CPUINFO: rcu_sched detected stalls on CPU
s/tasks: { 1} (detected by 0, t=6002 jiffies, g=4294966999, c=4294966998, q=15)
Task dump for CPU 1:
swapper/0       R running      0     1      0 0x00000002

It turned out that this core is waiting for the first A7 to complete
initialization, but this one hangs in HYP for a yet unknown reason.

To avoid this, iterate over every CPU to correctly determine the
capability of the system to run the current KVM implementation.

If users want to use KVM anyway, it will probably help to restrict
Linux to the A15 CPUs by giving an appropriate maxcpus= on the
kernel command line.

v2 change: remove potentially misleading hint message

Please push this still into 3.9.

Signed-off-by: Andre Przywara <andre.przywara at linaro.org>
---
 arch/arm/kvm/arm.c | 12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index c1fe498..74513e8 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -1129,19 +1129,29 @@ out_err:
 	return err;
 }
 
+static void check_kvm_target_cpu(void *ret)
+{
+	*(int*)ret = kvm_target_cpu();
+}
+
 /**
  * Initialize Hyp-mode and memory mappings on all CPUs.
  */
 int kvm_arch_init(void *opaque)
 {
 	int err;
+	int ret, cpu;
 
 	if (!is_hyp_mode_available()) {
 		kvm_err("HYP mode not available\n");
 		return -ENODEV;
 	}
 
-	if (kvm_target_cpu() < 0) {
+	for_each_online_cpu(cpu) {
+		smp_call_function_single(cpu, check_kvm_target_cpu, &ret, 1);
+		if (ret >= 0)
+			continue;
+
 		kvm_err("Target CPU not supported!\n");
 		return -ENODEV;
 	}
-- 
1.7.12.1



From arnd at arndb.de  Wed Apr 17 06:53:20 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed, 17 Apr 2013 12:53:20 +0200
Subject: [Suggestion] ARM:S5pv210: compiling issue for s5pv210 by using
 randconfig
In-Reply-To: <20130417100136.GB19492@mudshark.cambridge.arm.com>
References: <514FB202.3040807@asianux.com> <516E6A8E.3000001@asianux.com>
 <20130417100136.GB19492@mudshark.cambridge.arm.com>
Message-ID: <201304171253.20284.arnd@arndb.de>

On Wednesday 17 April 2013, Will Deacon wrote:
> > arm-linux-gnu-gcc -Wp,-MD,arch/arm/vfp/.vfphw.o.d  -nostdinc -isystem /usr/lib/gcc/arm-linux-gnueabi/4.7.1/include -I/root/linux-next/arch/arm/include -Iarch/arm/include/generated  -Iinclude -I/root/linux-next/arch/arm/include/uapi -Iarch/arm/include/generated/uapi -I/root/linux-next/include/uapi -Iinclude/generated/uapi -include /root/linux-next/include/linux/kconfig.h -D__KERNEL__ -mlittle-endian -Iarch/arm/mach-s5pv210/include -Iarch/arm/plat-samsung/include  -D__ASSEMBLY__ -mabi=apcs-gnu -mno-thumb-interwork -marm -D__LINUX_ARM_ARCH__=4 -march=armv4t -mtune=arm9tdmi -include asm/unified.h -Wa,-mfpu=softvfp+vfp -mfloat-abi=soft        -c -o arch/arm/vfp/vfphw.o arch/arm/vfp/vfphw.S
> > 
> > 
> >   compiling err:
> > 
> > arch/arm/vfp/vfphw.S: Assembler messages:
> > arch/arm/vfp/vfphw.S:295: Error: selected processor does not support ARM mode `mrrc p11,3,r0,r1,c0'
> > arch/arm/vfp/vfphw.S:295: Error: selected processor does not support ARM mode `mrrc p11,3,r0,r1,c1'
> 
> The problem here is that you've ended up targetting a platform (s5pv210)
> that selects CPU_V7. VFP is then subsequently selected, but CONFIG_MMU=n, so
> 7TDMI and 9TDMI (v4 CPUs, no VFP) are selectable. Selecting either of those,
> causes these warnings.
> 
> Unfortunately, I'm not sure how best to fix this. Most of the !MMU CPUs are
> tied to a particular board (lots of `if ARCH_INTEGRATOR' predicates), but we
> don't want to do that for 7tdmi.
> 
> If we could enforce the strict exclusion of {<= ARMv5} and {ARMv6+} in the
> Kconfig, that would solve your problem.

I have not tried to get no-MMU kernels to build in general. I think the way
it should be done is to not offer any user-selectable CPU types at all but
always select the CPU from the board.

For randconfig tests, I would recommend turning on CONFIG_MMU unconditionally
using an appropriate KCONFIG_ALLCONFIG= file.

The alternative is to use the patch below, but it may be incomplete: I could
not find anything other than AT91x40 in the kernel that actually has an
ARM7TDMI or ARM9TDMI.

	Arnd

diff --git a/arch/arm/mach-at91/Kconfig.non_dt b/arch/arm/mach-at91/Kconfig.non_dt
index 6c24985..dc972e1 100644
--- a/arch/arm/mach-at91/Kconfig.non_dt
+++ b/arch/arm/mach-at91/Kconfig.non_dt
@@ -47,6 +47,7 @@ config ARCH_AT91X40
 	select ARCH_USES_GETTIMEOFFSET
 	select MULTI_IRQ_HANDLER
 	select SPARSE_IRQ
+	select CPU_ARM7TDMI
 
 endchoice
 
diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
index 84af266..c5e4ef0 100644
--- a/arch/arm/mm/Kconfig
+++ b/arch/arm/mm/Kconfig
@@ -6,7 +6,6 @@ comment "Processor Type"
 
 # ARM7TDMI
 config CPU_ARM7TDMI
-	bool "Support ARM7TDMI processor"
 	depends on !MMU
 	select CPU_32v4T
 	select CPU_ABRT_LV4T
@@ -56,7 +55,6 @@ config CPU_ARM740T
 
 # ARM9TDMI
 config CPU_ARM9TDMI
-	bool "Support ARM9TDMI processor"
 	depends on !MMU
 	select CPU_32v4T
 	select CPU_ABRT_NOMMU


From lorenzo.pieralisi at arm.com  Wed Apr 17 07:02:04 2013
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Wed, 17 Apr 2013 12:02:04 +0100
Subject: [RFC PATCH 2/2] ARM: DT: kernel: DT cpu node bindings update
In-Reply-To: <201304171148.57146.arnd@arndb.de>
References: <1366042402-8987-1-git-send-email-lorenzo.pieralisi@arm.com>
 <1366042402-8987-3-git-send-email-lorenzo.pieralisi@arm.com>
 <201304171148.57146.arnd@arndb.de>
Message-ID: <20130417110203.GB29188@e102568-lin.cambridge.arm.com>

On Wed, Apr 17, 2013 at 10:48:56AM +0100, Arnd Bergmann wrote:
> On Monday 15 April 2013, Lorenzo Pieralisi wrote:
> > -               "arm,cortex-a9"
> > -               "arm,cortex-a15"
> > -               "arm,arm1136"
> > -               "arm,arm1156"
> > -               "arm,arm1176"
> > -               "arm,arm11mpcore"
> > -               "faraday,fa526"
> > -               "intel,sa110"
> > -               "intel,sa1100"
> > -               "marvell,feroceon"
> > -               "marvell,mohawk"
> > -               "marvell,xsc3"
> > -               "marvell,xscale"
> 
> > +                           "arm,cortex-a9"
> > +                           "arm,cortex-a15"
> > +                           "arm,cortex-a57"
> > +                           "arm,arm1136"
> > +                           "arm,arm1156"
> > +                           "arm,arm1176"
> > +                           "arm,arm11mpcore"
> > +                           "faraday,fa526"
> > +                           "intel,sa110"
> > +                           "intel,sa1100"
> > +                           "marvell,feroceon"
> > +                           "marvell,mohawk"
> > +                           "marvell,xsc3"
> > +                           "marvell,xscale"
> 
> I see you are adding cortex-a57 here, but there are actually a couple
> of other cores that we could add here. It also makes sense to sort these
> alphanumerically I think, and move arm10 after arm9, as well as arm11
> before cortex.

Ok, I will do that.

> The ones that I find missing but actually used are:
> 
> 	"arm,cortex-a53"
> 	"arm,cortex-m0"
> 	"arm,cortex-m0+"
> 	"arm,cortex-m1"
> 	"arm,cortex-m3"
> 	"arm,cortex-m4"
> 	"arm,cortex-r4"
> 	"arm,cortex-r5"
> 	"arm,cortex-r7"
> 	"marvell,pj4"
> 	"qcom,scorpion"
> 	"qcom,krait"

Ok, I will add them, but we should probably enforce a policy regulating
how this binding should be updated in the future.

> 
> There are also a number of faraday cores that we don't support in
> Linux (fa626, fa626te, fa726te, ...), not sure if we should attempt to
> list them all here. The only one that is being worked on at the moment
> is based on fa526.

That's why it is the only one in the list, not sure what we should do either.

> There are also a number of 64 bit cores that other companies have announced,
> but I'm not sure if the names are final yet.

On a side note, as far as the in-kernel dts updates are concerned, how would
you like me to split them ? per-mach ? per-SoC ?

Thank you very much,
Lorenzo



From plagnioj at jcrosoft.com  Wed Apr 17 07:02:33 2013
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Wed, 17 Apr 2013 13:02:33 +0200
Subject: [Suggestion] ARM:S5pv210: compiling issue for s5pv210 by using
 randconfig
In-Reply-To: <201304171253.20284.arnd@arndb.de>
References: <514FB202.3040807@asianux.com> <516E6A8E.3000001@asianux.com>
 <20130417100136.GB19492@mudshark.cambridge.arm.com>
 <201304171253.20284.arnd@arndb.de>
Message-ID: <20130417110233.GD4998@game.jcrosoft.org>

On 12:53 Wed 17 Apr     , Arnd Bergmann wrote:
> On Wednesday 17 April 2013, Will Deacon wrote:
> > > arm-linux-gnu-gcc -Wp,-MD,arch/arm/vfp/.vfphw.o.d  -nostdinc -isystem /usr/lib/gcc/arm-linux-gnueabi/4.7.1/include -I/root/linux-next/arch/arm/include -Iarch/arm/include/generated  -Iinclude -I/root/linux-next/arch/arm/include/uapi -Iarch/arm/include/generated/uapi -I/root/linux-next/include/uapi -Iinclude/generated/uapi -include /root/linux-next/include/linux/kconfig.h -D__KERNEL__ -mlittle-endian -Iarch/arm/mach-s5pv210/include -Iarch/arm/plat-samsung/include  -D__ASSEMBLY__ -mabi=apcs-gnu -mno-thumb-interwork -marm -D__LINUX_ARM_ARCH__=4 -march=armv4t -mtune=arm9tdmi -include asm/unified.h -Wa,-mfpu=softvfp+vfp -mfloat-abi=soft        -c -o arch/arm/vfp/vfphw.o arch/arm/vfp/vfphw.S
> > > 
> > > 
> > >   compiling err:
> > > 
> > > arch/arm/vfp/vfphw.S: Assembler messages:
> > > arch/arm/vfp/vfphw.S:295: Error: selected processor does not support ARM mode `mrrc p11,3,r0,r1,c0'
> > > arch/arm/vfp/vfphw.S:295: Error: selected processor does not support ARM mode `mrrc p11,3,r0,r1,c1'
> > 
> > The problem here is that you've ended up targetting a platform (s5pv210)
> > that selects CPU_V7. VFP is then subsequently selected, but CONFIG_MMU=n, so
> > 7TDMI and 9TDMI (v4 CPUs, no VFP) are selectable. Selecting either of those,
> > causes these warnings.
> > 
> > Unfortunately, I'm not sure how best to fix this. Most of the !MMU CPUs are
> > tied to a particular board (lots of `if ARCH_INTEGRATOR' predicates), but we
> > don't want to do that for 7tdmi.
> > 
> > If we could enforce the strict exclusion of {<= ARMv5} and {ARMv6+} in the
> > Kconfig, that would solve your problem.
> 
> I have not tried to get no-MMU kernels to build in general. I think the way
> it should be done is to not offer any user-selectable CPU types at all but
> always select the CPU from the board.
> 
> For randconfig tests, I would recommend turning on CONFIG_MMU unconditionally
> using an appropriate KCONFIG_ALLCONFIG= file.
> 
> The alternative is to use the patch below, but it may be incomplete: I could
> not find anything other than AT91x40 in the kernel that actually has an
> ARM7TDMI or ARM9TDMI.
> 
> 	Arnd
> 
> diff --git a/arch/arm/mach-at91/Kconfig.non_dt b/arch/arm/mach-at91/Kconfig.non_dt
> index 6c24985..dc972e1 100644
> --- a/arch/arm/mach-at91/Kconfig.non_dt
> +++ b/arch/arm/mach-at91/Kconfig.non_dt
> @@ -47,6 +47,7 @@ config ARCH_AT91X40
>  	select ARCH_USES_GETTIMEOFFSET
>  	select MULTI_IRQ_HANDLER
>  	select SPARSE_IRQ
> +	select CPU_ARM7TDMI
>  
>  endchoice
>  
> diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
> index 84af266..c5e4ef0 100644
> --- a/arch/arm/mm/Kconfig
> +++ b/arch/arm/mm/Kconfig
> @@ -6,7 +6,6 @@ comment "Processor Type"
>  
>  # ARM7TDMI
>  config CPU_ARM7TDMI
> -	bool "Support ARM7TDMI processor"
whith the bool type at least
>  	depends on !MMU
>  	select CPU_32v4T
>  	select CPU_ABRT_LV4T
> @@ -56,7 +55,6 @@ config CPU_ARM740T
>  
>  # ARM9TDMI
>  config CPU_ARM9TDMI
> -	bool "Support ARM9TDMI processor"
>  	depends on !MMU
>  	select CPU_32v4T
>  	select CPU_ABRT_NOMMU
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From cdall at cs.columbia.edu  Wed Apr 17 07:07:56 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Wed, 17 Apr 2013 04:07:56 -0700
Subject: [PATCH] ARM: KVM: iterate over all CPUs for CPU compatibility
 check
In-Reply-To: <516E7ADE.5090601@arm.com>
References: <1365771875-5788-1-git-send-email-andre.przywara@linaro.org>
 <51680AF9.7040109@arm.com>
 <CAFEAcA-1HAG0pY-j-rqU=QmSoep3Di-KNPATvuou8ghRn3SaqA@mail.gmail.com>
 <516810F7.7040601@arm.com>
 <20130417101906.GX14496@n2100.arm.linux.org.uk>
 <516E7ADE.5090601@arm.com>
Message-ID: <CAEDV+gK3nitpN+8ZePRY7n+bsc2t4XbWrz6fbdz0Wjq_kTgM4g@mail.gmail.com>

On Wed, Apr 17, 2013 at 3:35 AM, Marc Zyngier <marc.zyngier at arm.com> wrote:
> On 17/04/13 11:19, Russell King - ARM Linux wrote:
>> On Fri, Apr 12, 2013 at 02:49:43PM +0100, Marc Zyngier wrote:
>>> On 12/04/13 14:40, Peter Maydell wrote:
>>>> On 12 April 2013 14:24, Marc Zyngier <marc.zyngier at arm.com> wrote:
>>>>> Nak. The fact that one of the CPUs seem to hang is a sure sign that
>>>>> something is severely broken, and you definitely want to fix that issue,
>>>>> instead of blindly ignoring it.
>>>>>
>>>>> Additionally, it seems you're just papering over the issue. You should
>>>>> be able to exclude the A7 processors, but not completely deny KVM from
>>>>> running on the hardware.
>>>>
>>>> Well that might be nice, as would fully supporting big.LITTLE
>>>> systems. But until somebody actually does that work it seems
>>>> like a better idea to fail gracefully rather than having a 50%
>>>> chance of failing gracefully and a 50% chance of going weird.
>>>
>>> Nothing prevents the kernel (or even the user) from forcing the affinity
>>> of the CPU threads to the A15s. I'm not saying we should ignore the
>>> problem either. Just that the proposed approach is wrong.
>>
>> But nothing guarantees that you get that affinity.  If you offline all
>> A15 CPUs, then you will find those threads running on whatever is left.
>> Affinity is just a hint, nothing more.
>
> I completely agree with you. But if we're left with only CPUs we can't
> run on, we're screwed and must abort.
>
> It's the same story as the RealView PB-X, where only one of the two A9
> has NEON. If the NEON-capable core is down, any process using NEON is
> virtually dead.
>
> Should that be a reason to completely disable the HW (in this case the 3
> A7s)? I'm not sure...
>
But we're not talking about disabling the A7's, we're talking about
disabling KVM/ARM, a quite new feature, on a system where it's not
well-tested and may cause boot problems or other issues that we
haven't investigated in depth yet.


From gang.chen at asianux.com  Wed Apr 17 07:07:40 2013
From: gang.chen at asianux.com (Chen Gang)
Date: Wed, 17 Apr 2013 19:07:40 +0800
Subject: [Suggestion] ARM:S5pv210: compiling issue for s5pv210 by using
 randconfig
In-Reply-To: <201304171253.20284.arnd@arndb.de>
References: <514FB202.3040807@asianux.com> <516E6A8E.3000001@asianux.com>
 <20130417100136.GB19492@mudshark.cambridge.arm.com>
 <201304171253.20284.arnd@arndb.de>
Message-ID: <516E827C.3050807@asianux.com>

On 2013?04?17? 18:53, Arnd Bergmann wrote:
> On Wednesday 17 April 2013, Will Deacon wrote:
>>> > > arm-linux-gnu-gcc -Wp,-MD,arch/arm/vfp/.vfphw.o.d  -nostdinc -isystem /usr/lib/gcc/arm-linux-gnueabi/4.7.1/include -I/root/linux-next/arch/arm/include -Iarch/arm/include/generated  -Iinclude -I/root/linux-next/arch/arm/include/uapi -Iarch/arm/include/generated/uapi -I/root/linux-next/include/uapi -Iinclude/generated/uapi -include /root/linux-next/include/linux/kconfig.h -D__KERNEL__ -mlittle-endian -Iarch/arm/mach-s5pv210/include -Iarch/arm/plat-samsung/include  -D__ASSEMBLY__ -mabi=apcs-gnu -mno-thumb-interwork -marm -D__LINUX_ARM_ARCH__=4 -march=armv4t -mtune=arm9tdmi -include asm/unified.h -Wa,-mfpu=softvfp+vfp -mfloat-abi=soft        -c -o arch/arm/vfp/vfphw.o arch/arm/vfp/vfphw.S
>>> > > 
>>> > > 
>>> > >   compiling err:
>>> > > 
>>> > > arch/arm/vfp/vfphw.S: Assembler messages:
>>> > > arch/arm/vfp/vfphw.S:295: Error: selected processor does not support ARM mode `mrrc p11,3,r0,r1,c0'
>>> > > arch/arm/vfp/vfphw.S:295: Error: selected processor does not support ARM mode `mrrc p11,3,r0,r1,c1'
>> > 
>> > The problem here is that you've ended up targetting a platform (s5pv210)
>> > that selects CPU_V7. VFP is then subsequently selected, but CONFIG_MMU=n, so
>> > 7TDMI and 9TDMI (v4 CPUs, no VFP) are selectable. Selecting either of those,
>> > causes these warnings.
>> > 
>> > Unfortunately, I'm not sure how best to fix this. Most of the !MMU CPUs are
>> > tied to a particular board (lots of `if ARCH_INTEGRATOR' predicates), but we
>> > don't want to do that for 7tdmi.
>> > 
>> > If we could enforce the strict exclusion of {<= ARMv5} and {ARMv6+} in the
>> > Kconfig, that would solve your problem.
> I have not tried to get no-MMU kernels to build in general. I think the way
> it should be done is to not offer any user-selectable CPU types at all but
> always select the CPU from the board.
> 
> For randconfig tests, I would recommend turning on CONFIG_MMU unconditionally
> using an appropriate KCONFIG_ALLCONFIG= file.
> 
> The alternative is to use the patch below, but it may be incomplete: I could
> not find anything other than AT91x40 in the kernel that actually has an
> ARM7TDMI or ARM9TDMI.
> 
> 	Arnd

  it seems we really need think of the design carefully.

  I think we can assume that the crazy users (e.g. me) want to let
randconfig on each arm platform (scan one by one) to intend to make issues.

  :-)

gchen.

> 
> diff --git a/arch/arm/mach-at91/Kconfig.non_dt b/arch/arm/mach-at91/Kconfig.non_dt
> index 6c24985..dc972e1 100644
> --- a/arch/arm/mach-at91/Kconfig.non_dt
> +++ b/arch/arm/mach-at91/Kconfig.non_dt
> @@ -47,6 +47,7 @@ config ARCH_AT91X40
>  	select ARCH_USES_GETTIMEOFFSET
>  	select MULTI_IRQ_HANDLER
>  	select SPARSE_IRQ
> +	select CPU_ARM7TDMI
>  
>  endchoice
>  
> diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
> index 84af266..c5e4ef0 100644
> --- a/arch/arm/mm/Kconfig
> +++ b/arch/arm/mm/Kconfig
> @@ -6,7 +6,6 @@ comment "Processor Type"
>  
>  # ARM7TDMI
>  config CPU_ARM7TDMI
> -	bool "Support ARM7TDMI processor"
>  	depends on !MMU
>  	select CPU_32v4T
>  	select CPU_ABRT_LV4T
> @@ -56,7 +55,6 @@ config CPU_ARM740T
>  
>  # ARM9TDMI
>  config CPU_ARM9TDMI
> -	bool "Support ARM9TDMI processor"
>  	depends on !MMU
>  	select CPU_32v4T
>  	select CPU_ABRT_NOMMU
> 
> 


-- 
Chen Gang

Asianux Corporation


From marc.zyngier at arm.com  Wed Apr 17 07:30:25 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 17 Apr 2013 12:30:25 +0100
Subject: [PATCH] ARM: KVM: iterate over all CPUs for CPU compatibility
 check
In-Reply-To: <CAEDV+gK3nitpN+8ZePRY7n+bsc2t4XbWrz6fbdz0Wjq_kTgM4g@mail.gmail.com>
References: <1365771875-5788-1-git-send-email-andre.przywara@linaro.org>
 <51680AF9.7040109@arm.com>
 <CAFEAcA-1HAG0pY-j-rqU=QmSoep3Di-KNPATvuou8ghRn3SaqA@mail.gmail.com>
 <516810F7.7040601@arm.com>	<20130417101906.GX14496@n2100.arm.linux.org.uk>
 <516E7ADE.5090601@arm.com>
 <CAEDV+gK3nitpN+8ZePRY7n+bsc2t4XbWrz6fbdz0Wjq_kTgM4g@mail.gmail.com>
Message-ID: <516E87D1.5000109@arm.com>

On 17/04/13 12:07, Christoffer Dall wrote:
> On Wed, Apr 17, 2013 at 3:35 AM, Marc Zyngier <marc.zyngier at arm.com> wrote:
>> On 17/04/13 11:19, Russell King - ARM Linux wrote:
>>> On Fri, Apr 12, 2013 at 02:49:43PM +0100, Marc Zyngier wrote:
>>>> On 12/04/13 14:40, Peter Maydell wrote:
>>>>> On 12 April 2013 14:24, Marc Zyngier <marc.zyngier at arm.com> wrote:
>>>>>> Nak. The fact that one of the CPUs seem to hang is a sure sign that
>>>>>> something is severely broken, and you definitely want to fix that issue,
>>>>>> instead of blindly ignoring it.
>>>>>>
>>>>>> Additionally, it seems you're just papering over the issue. You should
>>>>>> be able to exclude the A7 processors, but not completely deny KVM from
>>>>>> running on the hardware.
>>>>>
>>>>> Well that might be nice, as would fully supporting big.LITTLE
>>>>> systems. But until somebody actually does that work it seems
>>>>> like a better idea to fail gracefully rather than having a 50%
>>>>> chance of failing gracefully and a 50% chance of going weird.
>>>>
>>>> Nothing prevents the kernel (or even the user) from forcing the affinity
>>>> of the CPU threads to the A15s. I'm not saying we should ignore the
>>>> problem either. Just that the proposed approach is wrong.
>>>
>>> But nothing guarantees that you get that affinity.  If you offline all
>>> A15 CPUs, then you will find those threads running on whatever is left.
>>> Affinity is just a hint, nothing more.
>>
>> I completely agree with you. But if we're left with only CPUs we can't
>> run on, we're screwed and must abort.
>>
>> It's the same story as the RealView PB-X, where only one of the two A9
>> has NEON. If the NEON-capable core is down, any process using NEON is
>> virtually dead.
>>
>> Should that be a reason to completely disable the HW (in this case the 3
>> A7s)? I'm not sure...
>>
> But we're not talking about disabling the A7's, we're talking about
> disabling KVM/ARM, a quite new feature, on a system where it's not
> well-tested and may cause boot problems or other issues that we
> haven't investigated in depth yet.

Well, it's a choice between disabling KVM or the A7s. Cheese or dessert?
Black death or cholera?

And I go back to my earlier argument: we don't know what's going wrong.
It could be a bug in our init code, it could be the bootloader that
fails to correctly initialize the A7s in HYP mode, it could be something
else.

By disabling the problematic configuration, we just bury our head in the
sand and pretend everything is fine. Yes, this is a new feature. But by
saying "not a supported configuration", while the code *should* support
it, we're only fooling ourselves.

	M.
-- 
Jazz is not dead. It just smells funny...



From cdall at cs.columbia.edu  Wed Apr 17 07:38:58 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Wed, 17 Apr 2013 04:38:58 -0700
Subject: [PATCH] ARM: KVM: iterate over all CPUs for CPU compatibility
 check
In-Reply-To: <516E87D1.5000109@arm.com>
References: <1365771875-5788-1-git-send-email-andre.przywara@linaro.org>
 <51680AF9.7040109@arm.com>
 <CAFEAcA-1HAG0pY-j-rqU=QmSoep3Di-KNPATvuou8ghRn3SaqA@mail.gmail.com>
 <516810F7.7040601@arm.com>
 <20130417101906.GX14496@n2100.arm.linux.org.uk>
 <516E7ADE.5090601@arm.com>
 <CAEDV+gK3nitpN+8ZePRY7n+bsc2t4XbWrz6fbdz0Wjq_kTgM4g@mail.gmail.com>
 <516E87D1.5000109@arm.com>
Message-ID: <CAEDV+gKuJZi4XV+UpmOuCiCxW_Yz2MbmS6tJDn2O=tL2b-52iw@mail.gmail.com>

On Wed, Apr 17, 2013 at 4:30 AM, Marc Zyngier <marc.zyngier at arm.com> wrote:
> On 17/04/13 12:07, Christoffer Dall wrote:
>> On Wed, Apr 17, 2013 at 3:35 AM, Marc Zyngier <marc.zyngier at arm.com> wrote:
>>> On 17/04/13 11:19, Russell King - ARM Linux wrote:
>>>> On Fri, Apr 12, 2013 at 02:49:43PM +0100, Marc Zyngier wrote:
>>>>> On 12/04/13 14:40, Peter Maydell wrote:
>>>>>> On 12 April 2013 14:24, Marc Zyngier <marc.zyngier at arm.com> wrote:
>>>>>>> Nak. The fact that one of the CPUs seem to hang is a sure sign that
>>>>>>> something is severely broken, and you definitely want to fix that issue,
>>>>>>> instead of blindly ignoring it.
>>>>>>>
>>>>>>> Additionally, it seems you're just papering over the issue. You should
>>>>>>> be able to exclude the A7 processors, but not completely deny KVM from
>>>>>>> running on the hardware.
>>>>>>
>>>>>> Well that might be nice, as would fully supporting big.LITTLE
>>>>>> systems. But until somebody actually does that work it seems
>>>>>> like a better idea to fail gracefully rather than having a 50%
>>>>>> chance of failing gracefully and a 50% chance of going weird.
>>>>>
>>>>> Nothing prevents the kernel (or even the user) from forcing the affinity
>>>>> of the CPU threads to the A15s. I'm not saying we should ignore the
>>>>> problem either. Just that the proposed approach is wrong.
>>>>
>>>> But nothing guarantees that you get that affinity.  If you offline all
>>>> A15 CPUs, then you will find those threads running on whatever is left.
>>>> Affinity is just a hint, nothing more.
>>>
>>> I completely agree with you. But if we're left with only CPUs we can't
>>> run on, we're screwed and must abort.
>>>
>>> It's the same story as the RealView PB-X, where only one of the two A9
>>> has NEON. If the NEON-capable core is down, any process using NEON is
>>> virtually dead.
>>>
>>> Should that be a reason to completely disable the HW (in this case the 3
>>> A7s)? I'm not sure...
>>>
>> But we're not talking about disabling the A7's, we're talking about
>> disabling KVM/ARM, a quite new feature, on a system where it's not
>> well-tested and may cause boot problems or other issues that we
>> haven't investigated in depth yet.
>
> Well, it's a choice between disabling KVM or the A7s. Cheese or dessert?
> Black death or cholera?
>
> And I go back to my earlier argument: we don't know what's going wrong.
> It could be a bug in our init code, it could be the bootloader that
> fails to correctly initialize the A7s in HYP mode, it could be something
> else.
>
> By disabling the problematic configuration, we just bury our head in the
> sand and pretend everything is fine. Yes, this is a new feature. But by
> saying "not a supported configuration", while the code *should* support
> it, we're only fooling ourselves.
>
I agree completely that we shouldn't hide some unknown bug by taking a
wild guess, I'm obviously not arguing for this.

However, we didn't verify that things should work on Big.Little, and
we don't have any code to support A7's. We've written the code
specifically with the idea that we emulate the underlying hardware and
we expect that the target_cpu function will return something valid,
which it does not for an A7, so no, it there is no expectation that
things should work on Big.Little or an A7. Again, I stress that this
is an orthogonal point to the specific issue that Andre/Alex are
seeing on Big.Little.


From peter.maydell at linaro.org  Wed Apr 17 07:38:43 2013
From: peter.maydell at linaro.org (Peter Maydell)
Date: Wed, 17 Apr 2013 12:38:43 +0100
Subject: [PATCH] ARM: KVM: iterate over all CPUs for CPU compatibility
 check
In-Reply-To: <516E87D1.5000109@arm.com>
References: <1365771875-5788-1-git-send-email-andre.przywara@linaro.org>
 <51680AF9.7040109@arm.com>
 <CAFEAcA-1HAG0pY-j-rqU=QmSoep3Di-KNPATvuou8ghRn3SaqA@mail.gmail.com>
 <516810F7.7040601@arm.com> <20130417101906.GX14496@n2100.arm.linux.org.uk>
 <516E7ADE.5090601@arm.com>
 <CAEDV+gK3nitpN+8ZePRY7n+bsc2t4XbWrz6fbdz0Wjq_kTgM4g@mail.gmail.com>
 <516E87D1.5000109@arm.com>
Message-ID: <CAFEAcA8oE+2BRRgoeA4-0PzOQkxzGwDT5qunudzg7RBA9aWCgQ@mail.gmail.com>

On 17 April 2013 12:30, Marc Zyngier <marc.zyngier at arm.com> wrote:
> By disabling the problematic configuration, we just bury our head in the
> sand and pretend everything is fine. Yes, this is a new feature. But by
> saying "not a supported configuration", while the code *should* support
> it, we're only fooling ourselves.

Who says the code should support running on big.LITTLE? I think
it's very clear that the only thing it should support at the
moment is A15 guest CPUs on an all-A15 host CPU system.

-- PMM


From agraf at suse.de  Wed Apr 17 07:42:10 2013
From: agraf at suse.de (Alexander Graf)
Date: Wed, 17 Apr 2013 13:42:10 +0200
Subject: [PATCH] ARM: KVM: iterate over all CPUs for CPU compatibility
 check
In-Reply-To: <CAFEAcA8oE+2BRRgoeA4-0PzOQkxzGwDT5qunudzg7RBA9aWCgQ@mail.gmail.com>
References: <1365771875-5788-1-git-send-email-andre.przywara@linaro.org>
 <51680AF9.7040109@arm.com>
 <CAFEAcA-1HAG0pY-j-rqU=QmSoep3Di-KNPATvuou8ghRn3SaqA@mail.gmail.com>
 <516810F7.7040601@arm.com> <20130417101906.GX14496@n2100.arm.linux.org.uk>
 <516E7ADE.5090601@arm.com>
 <CAEDV+gK3nitpN+8ZePRY7n+bsc2t4XbWrz6fbdz0Wjq_kTgM4g@mail.gmail.com>
 <516E87D1.5000109@arm.com>
 <CAFEAcA8oE+2BRRgoeA4-0PzOQkxzGwDT5qunudzg7RBA9aWCgQ@mail.gmail.com>
Message-ID: <9EDD532A-1EEB-450A-A68C-E8EE64C2ECA6@suse.de>


On 17.04.2013, at 13:38, Peter Maydell wrote:

> On 17 April 2013 12:30, Marc Zyngier <marc.zyngier at arm.com> wrote:
>> By disabling the problematic configuration, we just bury our head in the
>> sand and pretend everything is fine. Yes, this is a new feature. But by
>> saying "not a supported configuration", while the code *should* support
>> it, we're only fooling ourselves.
> 
> Who says the code should support running on big.LITTLE? I think
> it's very clear that the only thing it should support at the
> moment is A15 guest CPUs on an all-A15 host CPU system.

Is anyone going to run this code on big.LITTLE systems before 3.10 is out?

Just fix it for real with 3.10 and everyone's happy. If need be, you can always CC the fixes to stable to have them in 3.9.


Alex



From lorenzo.pieralisi at arm.com  Wed Apr 17 07:44:27 2013
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Wed, 17 Apr 2013 12:44:27 +0100
Subject: [RFC PATCH 2/2] ARM: DT: kernel: DT cpu node bindings update
In-Reply-To: <516E6CDC.9010005@atmel.com>
References: <1366042402-8987-1-git-send-email-lorenzo.pieralisi@arm.com>
 <1366042402-8987-3-git-send-email-lorenzo.pieralisi@arm.com>
 <516E6CDC.9010005@atmel.com>
Message-ID: <20130417114427.GC29188@e102568-lin.cambridge.arm.com>

On Wed, Apr 17, 2013 at 10:35:24AM +0100, Nicolas Ferre wrote:
> On 04/15/2013 06:13 PM, Lorenzo Pieralisi :
> > In order to extend the current cpu nodes bindings to newer CPUs
> > inclusive of AArch64 and to update support for older ARM CPUs this
> > patch updates device tree documentation for the cpu nodes bindings.
> > 
> > Main changes:
> > 
> > - adds 64-bit bindings (inclusive of cpus node #address-cells updates)
> > - defines behaviour on pre and post v7 uniprocessor systems
> > - adds ARM 11MPcore specific reg property definition
> > 
> > DT cpu map parsing code must be made compliant with the latest bindings
> > updates, hence this patch also updates the arm_dt_init_cpu_maps() function
> > with checks and additional parsing rules.
> > 
> > Uniprocessor systems predating v7 do not parse the cpus node at all
> > since the reg property is meaningless on those systems.
> > 
> > Device trees for 64-bit systems can be taken as device tree input also
> > for 64-bit CPUs running in 32-bit mode. The code checks that the reg entries
> > are zeroed as required in the respective fields and detects automatically
> > the cpus node #address-cells value so that device tree written for
> > 64-bit ARM platforms (cpus #address-cells == 2) can still be taken as
> > input. The correct device tree entries are to be set up by the boot
> > loader, kernel code just checks that device tree entries in the cpus
> > node are as expected for a 32-bit CPU (reg[63:24] == 0).
> > 
> > cpu node entries with invalid reg property or containing duplicates are
> > ignored and the device tree parsing is not stopped anymore when such
> > entries are encountered, the device tree cpu entry is just skipped.
> > 
> > A device tree with cpu nodes missing the boot CPU MPIDR is considered a
> > hard error and the kernel flags this up as a bug to force firmware updates.
> > 
> > The updates to cpus/cpu node bindings for ARM require all in-kernel dts files
> > present in the mainline to be made compliant to the latest specification.
> > 
> > This patch also updates ARM in-kernel non-compliant dts files to the latest
> > cpus/cpu nodes bindings specification.
> > 
> > Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
> > ---
> >  Documentation/devicetree/bindings/arm/cpus.txt | 335 +++++++++++++++++++++----
> >  arch/arm/boot/dts/exynos5440.dtsi              |   7 +
> >  arch/arm/boot/dts/omap3.dtsi                   |   4 +
> >  arch/arm/boot/dts/omap4.dtsi                   |   5 +
> >  arch/arm/boot/dts/omap5.dtsi                   |   5 +
> >  arch/arm/boot/dts/r8a7740.dtsi                 |   3 +
> >  arch/arm/boot/dts/sh7372.dtsi                  |   4 +
> >  arch/arm/boot/dts/sunxi.dtsi                   |   4 +
> 
> Hi,
> 
> If it can be done easily, can you please consider the upcoming (3.10)
> cortex-a5 SoC:
> 
> arch/arm/boot/dts/sama5d3.dtsi
> 
> It is in linux-next through arm-soc/at91/at91/soc

I will do that at the same time this set gets merged.

> >  arch/arm/kernel/devtree.c                      |  82 +++---
> >  9 files changed, 377 insertions(+), 72 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt
> > index f32494d..b1ef3d8 100644
> > --- a/Documentation/devicetree/bindings/arm/cpus.txt
> > +++ b/Documentation/devicetree/bindings/arm/cpus.txt
> > @@ -1,4 +1,6 @@
> > -* ARM CPUs binding description
> > +=============================
> > +ARM CPUs bindings description
> > +=============================
> >  
> >  The device tree allows to describe the layout of CPUs in a system through
> >  the "cpus" node, which in turn contains a number of subnodes (ie "cpu")
> > @@ -8,70 +10,317 @@ Bindings for CPU nodes follow the ePAPR standard, available from:
> >  
> >  http://devicetree.org
> >  
> > -For the ARM architecture every CPU node must contain the following properties:
> > -
> > -- device_type:	must be "cpu"
> > -- reg:		property matching the CPU MPIDR[23:0] register bits
> > -		reg[31:24] bits must be set to 0
> > -- compatible:	should be one of:
> > -		"arm,arm1020"
> > -		"arm,arm1020e"
> > -		"arm,arm1022"
> > -		"arm,arm1026"
> > -		"arm,arm720"
> > -		"arm,arm740"
> > -		"arm,arm7tdmi"
> > -		"arm,arm920"
> 
> Here we have: "arm,arm920t" for at91rm9200.dtsi

I will update it.

> > -		"arm,arm922"
> > -		"arm,arm925"
> > -		"arm,arm926"
> 
> Oh, I missed this one: the strange thing is that *all* arm926 variants
> have a compatible string of this form: "arm,arm926ejs"
> 
> (using: git grep "arm,arm9" next/master)
> 
> Should we change? Is there a rule for this naming?

We decided to keep the compatible property as the base processor
names, leaving out variants, so I think answer is: the rule for the
naming is this document, and yes we should change it, if we all agree
on the approach.

Lorenzo



From cdall at cs.columbia.edu  Wed Apr 17 07:45:32 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Wed, 17 Apr 2013 04:45:32 -0700
Subject: [PATCH] ARM: KVM: iterate over all CPUs for CPU compatibility
 check
In-Reply-To: <9EDD532A-1EEB-450A-A68C-E8EE64C2ECA6@suse.de>
References: <1365771875-5788-1-git-send-email-andre.przywara@linaro.org>
 <51680AF9.7040109@arm.com>
 <CAFEAcA-1HAG0pY-j-rqU=QmSoep3Di-KNPATvuou8ghRn3SaqA@mail.gmail.com>
 <516810F7.7040601@arm.com>
 <20130417101906.GX14496@n2100.arm.linux.org.uk>
 <516E7ADE.5090601@arm.com>
 <CAEDV+gK3nitpN+8ZePRY7n+bsc2t4XbWrz6fbdz0Wjq_kTgM4g@mail.gmail.com>
 <516E87D1.5000109@arm.com>
 <CAFEAcA8oE+2BRRgoeA4-0PzOQkxzGwDT5qunudzg7RBA9aWCgQ@mail.gmail.com>
 <9EDD532A-1EEB-450A-A68C-E8EE64C2ECA6@suse.de>
Message-ID: <CAEDV+g+81HwHHyneYkRTF+KV12POPuLb7OjCHA1TwcxYT_6TMw@mail.gmail.com>

On Wed, Apr 17, 2013 at 4:42 AM, Alexander Graf <agraf at suse.de> wrote:
>
> On 17.04.2013, at 13:38, Peter Maydell wrote:
>
>> On 17 April 2013 12:30, Marc Zyngier <marc.zyngier at arm.com> wrote:
>>> By disabling the problematic configuration, we just bury our head in the
>>> sand and pretend everything is fine. Yes, this is a new feature. But by
>>> saying "not a supported configuration", while the code *should* support
>>> it, we're only fooling ourselves.
>>
>> Who says the code should support running on big.LITTLE? I think
>> it's very clear that the only thing it should support at the
>> moment is A15 guest CPUs on an all-A15 host CPU system.
>
> Is anyone going to run this code on big.LITTLE systems before 3.10 is out?
>

Apparently yes, otherwise we would not be having this discussion in
the first place.

> Just fix it for real with 3.10 and everyone's happy. If need be, you can always CC the fixes to stable to have them in 3.9.
>
>
That's really an added feature set, which I don't think is appropriate
for stable. Currently we *do not support big.little* but we pretend
that we do, and even worse, we pretend that we can emulate an A15 on
an A7 for example, which we obviously cannot, and nobody looked at
what kind of damage that can cause. Therefore, the "fix" for the
current supported features is to bail out on something as funky as a
big.little, and I honestly don't see what the big problem with that
is. And, such a fix is what should go in stable.


From hechtb at gmail.com  Wed Apr 17 06:56:30 2013
From: hechtb at gmail.com (Bastian Hecht)
Date: Wed, 17 Apr 2013 12:56:30 +0200
Subject: [PATCH v3 2/2] ARM: shmobile: r8a7740: Add CPUIdle
In-Reply-To: <1366196190-14011-1-git-send-email-hechtb+renesas@gmail.com>
References: <1366196190-14011-1-git-send-email-hechtb+renesas@gmail.com>
Message-ID: <1366196190-14011-2-git-send-email-hechtb+renesas@gmail.com>

We make use of the r8a7740 Suspend To Ram code to plug together a
CPUIdle driver.

Signed-off-by: Bastian Hecht <hechtb+renesas at gmail.com>
Acked-by: Daniel Lezcano <daniel.lezcano at linaro.org>
---
v3: same

 arch/arm/mach-shmobile/Makefile               |    2 +-
 arch/arm/mach-shmobile/cpuidle-r8a7740.c      |   62 +++++++++++++++++++++++++
 arch/arm/mach-shmobile/include/mach/r8a7740.h |    1 +
 arch/arm/mach-shmobile/pm-r8a7740.c           |    1 +
 4 files changed, 65 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/mach-shmobile/cpuidle-r8a7740.c

diff --git a/arch/arm/mach-shmobile/Makefile b/arch/arm/mach-shmobile/Makefile
index 0568894..2852dcf 100644
--- a/arch/arm/mach-shmobile/Makefile
+++ b/arch/arm/mach-shmobile/Makefile
@@ -30,7 +30,7 @@ obj-$(CONFIG_SUSPEND)		+= suspend.o
 obj-$(CONFIG_CPU_IDLE)		+= cpuidle.o
 obj-$(CONFIG_ARCH_SHMOBILE)	+= pm-rmobile.o
 obj-$(CONFIG_ARCH_SH7372)	+= pm-sh7372.o sleep-sh7372.o
-obj-$(CONFIG_ARCH_R8A7740)	+= pm-r8a7740.o sleep-r8a7740.o
+obj-$(CONFIG_ARCH_R8A7740)	+= pm-r8a7740.o sleep-r8a7740.o cpuidle-r8a7740.o
 obj-$(CONFIG_ARCH_R8A7779)	+= pm-r8a7779.o
 obj-$(CONFIG_ARCH_SH73A0)	+= pm-sh73a0.o
 
diff --git a/arch/arm/mach-shmobile/cpuidle-r8a7740.c b/arch/arm/mach-shmobile/cpuidle-r8a7740.c
new file mode 100644
index 0000000..48c7a6c
--- /dev/null
+++ b/arch/arm/mach-shmobile/cpuidle-r8a7740.c
@@ -0,0 +1,62 @@
+/*
+ * CPUIdle code for SoC r8a7740
+ *
+ * Copyright (C) 2013 Bastian Hecht
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License.  See the file "COPYING" in the main directory of this archive
+ * for more details.
+ */
+#include <linux/cpuidle.h>
+#include <linux/module.h>
+#include <asm/cpuidle.h>
+#include <mach/common.h>
+#include <mach/r8a7740.h>
+
+#if defined(CONFIG_SUSPEND) && defined(CONFIG_CPU_IDLE)
+static int r8a7740_enter_a3sm_pll_on(struct cpuidle_device *dev,
+					struct cpuidle_driver *drv, int index)
+{
+	r8a7740_enter_a3sm_common(1);
+	return 1;
+}
+
+static int r8a7740_enter_a3sm_pll_off(struct cpuidle_device *dev,
+					struct cpuidle_driver *drv, int index)
+{
+	r8a7740_enter_a3sm_common(0);
+	return 2;
+}
+
+static struct cpuidle_driver r8a7740_cpuidle_driver = {
+	.name			= "r8a7740_cpuidle",
+	.owner			= THIS_MODULE,
+	.en_core_tk_irqen	= 1,
+	.state_count		= 3,
+	.safe_state_index	= 0, /* C1 */
+	.states[0] = ARM_CPUIDLE_WFI_STATE,
+	.states[1] = {
+		.name = "C2",
+		.desc = "A3SM PLL ON",
+		.exit_latency = 40,
+		.target_residency = 30 + 40,
+		.flags = CPUIDLE_FLAG_TIME_VALID,
+		.enter = r8a7740_enter_a3sm_pll_on,
+	},
+	.states[2] = {
+		.name = "C3",
+		.desc = "A3SM PLL OFF",
+		.exit_latency = 120,
+		.target_residency = 30 + 120,
+		.flags = CPUIDLE_FLAG_TIME_VALID,
+		.enter = r8a7740_enter_a3sm_pll_off,
+	},
+};
+
+void r8a7740_cpuidle_init(void)
+{
+	shmobile_cpuidle_set_driver(&r8a7740_cpuidle_driver);
+}
+#else
+void r8a7740_cpuidle_init(void) {}
+#endif
diff --git a/arch/arm/mach-shmobile/include/mach/r8a7740.h b/arch/arm/mach-shmobile/include/mach/r8a7740.h
index 05551ee..5c3361a 100644
--- a/arch/arm/mach-shmobile/include/mach/r8a7740.h
+++ b/arch/arm/mach-shmobile/include/mach/r8a7740.h
@@ -542,6 +542,7 @@ extern void r8a7740_pinmux_init(void);
 extern void r8a7740_pm_init(void);
 extern void r8a7740_resume(void);
 extern void r8a7740_shutdown(void);
+extern void r8a7740_cpuidle_init(void);
 extern void r8a7740_enter_a3sm_common(int);
 
 #ifdef CONFIG_PM
diff --git a/arch/arm/mach-shmobile/pm-r8a7740.c b/arch/arm/mach-shmobile/pm-r8a7740.c
index b9ca44b..2319aa5 100644
--- a/arch/arm/mach-shmobile/pm-r8a7740.c
+++ b/arch/arm/mach-shmobile/pm-r8a7740.c
@@ -237,4 +237,5 @@ static void r8a7740_suspend_init(void) {}
 void __init r8a7740_pm_init(void)
 {
 	r8a7740_suspend_init();
+	r8a7740_cpuidle_init();
 }
-- 
1.7.9.5



From hechtb at gmail.com  Wed Apr 17 06:56:29 2013
From: hechtb at gmail.com (Bastian Hecht)
Date: Wed, 17 Apr 2013 12:56:29 +0200
Subject: [PATCH v3 1/2] ARM: shmobile: r8a7740: Add Suspend-To-RAM A3SM
Message-ID: <1366196190-14011-1-git-send-email-hechtb+renesas@gmail.com>

We add 2 Suspend to RAM modes:
- A3SM PLL0 on/off:     Power domain A3SM that contains the ARM core
                        and the 2nd level cache with either PLL0 on
                        or off

As the suspend to memory mechanism we use A3SM PLL off. A3SM PLL on
is included here too, so CPUIdle can use both power down modes (not
included in this patch).

The setup of the SYSC regarding the external IRQs is taken from
pm-sh7372.c from Magnus Damm.

Signed-off-by: Bastian Hecht <hechtb+renesas at gmail.com>
---
v3:

We now stubbornly loop until the SoC really shuts down when we issue
the WFI command.

 arch/arm/mach-shmobile/Makefile               |    2 +-
 arch/arm/mach-shmobile/include/mach/r8a7740.h |    3 +
 arch/arm/mach-shmobile/pm-r8a7740.c           |  164 ++++++++++++++++++++++++-
 arch/arm/mach-shmobile/sleep-r8a7740.S        |   57 +++++++++
 4 files changed, 222 insertions(+), 4 deletions(-)
 create mode 100644 arch/arm/mach-shmobile/sleep-r8a7740.S

diff --git a/arch/arm/mach-shmobile/Makefile b/arch/arm/mach-shmobile/Makefile
index 068f1da..0568894 100644
--- a/arch/arm/mach-shmobile/Makefile
+++ b/arch/arm/mach-shmobile/Makefile
@@ -30,7 +30,7 @@ obj-$(CONFIG_SUSPEND)		+= suspend.o
 obj-$(CONFIG_CPU_IDLE)		+= cpuidle.o
 obj-$(CONFIG_ARCH_SHMOBILE)	+= pm-rmobile.o
 obj-$(CONFIG_ARCH_SH7372)	+= pm-sh7372.o sleep-sh7372.o
-obj-$(CONFIG_ARCH_R8A7740)	+= pm-r8a7740.o
+obj-$(CONFIG_ARCH_R8A7740)	+= pm-r8a7740.o sleep-r8a7740.o
 obj-$(CONFIG_ARCH_R8A7779)	+= pm-r8a7779.o
 obj-$(CONFIG_ARCH_SH73A0)	+= pm-sh73a0.o
 
diff --git a/arch/arm/mach-shmobile/include/mach/r8a7740.h b/arch/arm/mach-shmobile/include/mach/r8a7740.h
index abdc4d4..05551ee 100644
--- a/arch/arm/mach-shmobile/include/mach/r8a7740.h
+++ b/arch/arm/mach-shmobile/include/mach/r8a7740.h
@@ -540,6 +540,9 @@ extern void r8a7740_add_standard_devices(void);
 extern void r8a7740_clock_init(u8 md_ck);
 extern void r8a7740_pinmux_init(void);
 extern void r8a7740_pm_init(void);
+extern void r8a7740_resume(void);
+extern void r8a7740_shutdown(void);
+extern void r8a7740_enter_a3sm_common(int);
 
 #ifdef CONFIG_PM
 extern void __init r8a7740_init_pm_domains(void);
diff --git a/arch/arm/mach-shmobile/pm-r8a7740.c b/arch/arm/mach-shmobile/pm-r8a7740.c
index 40b87aa..b9ca44b 100644
--- a/arch/arm/mach-shmobile/pm-r8a7740.c
+++ b/arch/arm/mach-shmobile/pm-r8a7740.c
@@ -8,10 +8,52 @@
  * License.  See the file "COPYING" in the main directory of this archive
  * for more details.
  */
+#include <linux/bitrev.h>
 #include <linux/console.h>
+#include <linux/module.h>
 #include <linux/suspend.h>
+#include <linux/io.h>
+#include <asm/suspend.h>
+#include <asm/cacheflush.h>
+#include <asm/hardware/cache-l2x0.h>
 #include <mach/pm-rmobile.h>
 #include <mach/common.h>
+#include <mach/r8a7740.h>
+
+/* CPGA */
+#define PLLC01STPCR	IOMEM(0xe61500c8)
+#define SYSTBCR		IOMEM(0xe6150024)
+
+/* SYSC */
+#define STBCHR		IOMEM(0xe6180000)
+#define STBCHRB		IOMEM(0xe6180040)
+#define SPDCR		IOMEM(0xe6180008)
+#define SBAR		IOMEM(0xe6180020)
+#define SRSTFR		IOMEM(0xe61800B4)
+#define WUPSMSK		IOMEM(0xe618002c)
+#define WUPSMSK2	IOMEM(0xe6180048)
+#define WUPSFAC		IOMEM(0xe6180098)
+#define IRQCR		IOMEM(0xe618022c)
+#define IRQCR2		IOMEM(0xe6180238)
+#define IRQCR3		IOMEM(0xe6180244)
+#define IRQCR4		IOMEM(0xe6180248)
+
+/* SRSTFR flags */
+#define RAMST		(1 << 19)
+#define RCLNKA		(1 << 7)
+#define RCPRES		(1 << 5)
+#define RCWD1		(1 << 4)
+#define RPF		(1 << 0)
+
+/* INTC */
+#define ICR1A		IOMEM(0xe6900000)
+#define ICR2A		IOMEM(0xe6900004)
+#define ICR3A		IOMEM(0xe6900008)
+#define ICR4A		IOMEM(0xe690000c)
+#define INTMSK00A	IOMEM(0xe6900040)
+#define INTMSK10A	IOMEM(0xe6900044)
+#define INTMSK20A	IOMEM(0xe6900048)
+#define INTMSK30A	IOMEM(0xe690004c)
 
 #ifdef CONFIG_PM
 static int r8a7740_pd_a4s_suspend(void)
@@ -58,13 +100,129 @@ void __init r8a7740_init_pm_domains(void)
 	rmobile_init_domains(r8a7740_pm_domains, ARRAY_SIZE(r8a7740_pm_domains));
 	pm_genpd_add_subdomain_names("A4S", "A3SP");
 }
-
 #endif /* CONFIG_PM */
 
 #ifdef CONFIG_SUSPEND
+static void r8a7740_set_reset_vector(unsigned long address)
+{
+	__raw_writel(address, SBAR);
+}
+
+static void r8a7740_icr_to_irqcr(unsigned long icr, u16 *irqcr1p, u16 *irqcr2p)
+{
+	u16 tmp, irqcr1, irqcr2;
+	int k;
+
+	irqcr1 = 0;
+	irqcr2 = 0;
+
+	/* convert INTCA ICR register layout to SYSC IRQCR+IRQCR2 */
+	for (k = 0; k <= 7; k++) {
+		tmp = (icr >> ((7 - k) * 4)) & 0xf;
+		irqcr1 |= (tmp & 0x03) << (k * 2);
+		irqcr2 |= (tmp >> 2) << (k * 2);
+	}
+
+	*irqcr1p = irqcr1;
+	*irqcr2p = irqcr2;
+}
+
+static void r8a7740_setup_sysc(unsigned long msk, unsigned long msk2)
+{
+	u16 irqcrx_low, irqcrx_high, irqcry_low, irqcry_high;
+	unsigned long tmp;
+
+	/* read IRQ0A -> IRQ15A mask */
+	tmp = bitrev8(__raw_readb(INTMSK00A));
+	tmp |= bitrev8(__raw_readb(INTMSK10A)) << 8;
+
+	/* setup WUPSMSK from clocks and external IRQ mask */
+	msk = (~msk & 0xc030000f) | (tmp << 4);
+	__raw_writel(msk, WUPSMSK);
+
+	/* propage level/edge trigger for external IRQ 0->15 */
+	r8a7740_icr_to_irqcr(__raw_readl(ICR1A), &irqcrx_low, &irqcry_low);
+	r8a7740_icr_to_irqcr(__raw_readl(ICR2A), &irqcrx_high, &irqcry_high);
+	__raw_writel((irqcrx_high << 16) | irqcrx_low, IRQCR);
+	__raw_writel((irqcry_high << 16) | irqcry_low, IRQCR2);
+
+	/* read IRQ16A -> IRQ31A mask */
+	tmp = bitrev8(__raw_readb(INTMSK20A));
+	tmp |= bitrev8(__raw_readb(INTMSK30A)) << 8;
+
+	/* setup WUPSMSK2 from clocks and external IRQ mask */
+	msk2 = (~msk2 & 0x00030000) | tmp;
+	__raw_writel(msk2, WUPSMSK2);
+
+	/* propage level/edge trigger for external IRQ 16->31 */
+	r8a7740_icr_to_irqcr(__raw_readl(ICR3A), &irqcrx_low, &irqcry_low);
+	r8a7740_icr_to_irqcr(__raw_readl(ICR4A), &irqcrx_high, &irqcry_high);
+	__raw_writel((irqcrx_high << 16) | irqcrx_low, IRQCR3);
+	__raw_writel((irqcry_high << 16) | irqcry_low, IRQCR4);
+}
+
+static void r8a7740_prepare_wakeup(void)
+{
+	/* clear all flags that lead to a cold boot */
+	__raw_writel(~(RAMST | RCLNKA | RCPRES | RCWD1 | RPF), SRSTFR);
+	/* indicate warm boot */
+	__raw_writel(0x80000000, STBCHRB);
+	/* clear other flags checked by internal ROM boot loader */
+	__raw_writel(0x00000000, STBCHR);
+}
+
+static int r8a7740_do_suspend(unsigned long unused)
+{
+	/*
+	 * cpu_suspend() guarantees that all data made it to the L2.
+	 * Flush it out now and disable the cache controller.
+	 */
+	outer_flush_all();
+	outer_disable();
+
+	r8a7740_shutdown();
+
+	return 0;
+}
+
+void r8a7740_enter_a3sm_common(int pllc0_on)
+{
+	u32 reg32;
+
+	if (pllc0_on)
+		__raw_writel(0, PLLC01STPCR);
+	else
+		__raw_writel(1 << 28, PLLC01STPCR);
+
+	r8a7740_set_reset_vector(__pa(r8a7740_resume));
+	r8a7740_prepare_wakeup();
+	r8a7740_setup_sysc(1 << 0, 0);
+
+	/* Activate delayed shutdown of A3SM */
+	reg32 = __raw_readl(SPDCR);
+	reg32 |= (1 << 31) | (1 << 12);
+	__raw_writel(reg32, SPDCR);
+
+	/* We activate CPU Core Standby as well here */
+	reg32 = __raw_readl(SYSTBCR);
+	reg32 |= (1 << 4);
+	__raw_writel(reg32, SYSTBCR);
+
+	/* Clear Wakeup Factors and do suspend */
+	reg32 = __raw_readl(WUPSFAC);
+	cpu_suspend(0, r8a7740_do_suspend);
+	outer_resume();
+	reg32 = __raw_readl(WUPSFAC);
+
+	/* Clear CPU Core Standby flag for other WFI instructions */
+	reg32 &= ~(1 << 4);
+	__raw_writel(reg32, SYSTBCR);
+
+}
+
 static int r8a7740_enter_suspend(suspend_state_t suspend_state)
 {
-	cpu_do_idle();
+	r8a7740_enter_a3sm_common(0);
 	return 0;
 }
 
@@ -74,7 +232,7 @@ static void r8a7740_suspend_init(void)
 }
 #else
 static void r8a7740_suspend_init(void) {}
-#endif
+#endif /* CONFIG_SUSPEND */
 
 void __init r8a7740_pm_init(void)
 {
diff --git a/arch/arm/mach-shmobile/sleep-r8a7740.S b/arch/arm/mach-shmobile/sleep-r8a7740.S
new file mode 100644
index 0000000..435531b
--- /dev/null
+++ b/arch/arm/mach-shmobile/sleep-r8a7740.S
@@ -0,0 +1,57 @@
+/*
+ * Low level sleep code for the SoC r8a7740
+ *
+ * Copyright (C) 2013 Bastian Hecht
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License.  See the file "COPYING" in the main directory of this archive
+ * for more details.
+ */
+
+#include <linux/linkage.h>
+#include <linux/init.h>
+#include <asm/memory.h>
+
+#ifdef CONFIG_SUSPEND
+
+/* r8a7740_shutdown expects L2 to be flushed */
+	.text
+ENTRY(r8a7740_shutdown)
+	/*
+	 * Clear the SCTLR.C bit to prevent further data cache
+	 * allocation. Clearing SCTLR.C would make all the data accesses
+	 * strongly ordered and would not hit the cache.
+	 */
+	mrc	p15, 0, r0, c1, c0, 0
+	bic	r0, r0, #(1 << 2)		@ Disable the C bit
+	mcr	p15, 0, r0, c1, c0, 0
+	isb
+
+	bl      v7_flush_dcache_all
+
+wfi_loop:
+	bl	cpu_v7_do_idle
+	b wfi_loop
+ENDPROC(r8a7740)
+
+	.text
+ENTRY(v7_cpu_resume)
+	bl	v7_invalidate_l1
+	b	cpu_resume
+ENDPROC(v7_cpu_resume)
+
+/*
+ * The entry point of a warm reboot, used by wakeup scenarios
+ *
+ * The CPU jumps in this case to (0xfffff000 & SBAR), so we need
+ * to align this function properly.
+ * We use a long jump into the text segment and use the physical
+ * address as the MMU is still turned off.
+ */
+	.align	12
+	.text
+ENTRY(r8a7740_resume)
+	ldr	pc, 1f
+1:	.long	v7_cpu_resume - PAGE_OFFSET + PLAT_PHYS_OFFSET
+ENDPROC(r8a7740_resume_core_standby)
+#endif
-- 
1.7.9.5



From sergei.shtylyov at cogentembedded.com  Wed Apr 17 08:00:57 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Wed, 17 Apr 2013 16:00:57 +0400
Subject: [PATCH] ARM: shmobile: BOCK-W: enable CONFIG_PM_RUNTIME in
 defconfig
In-Reply-To: <20130417101017.GW14496@n2100.arm.linux.org.uk>
References: <201304170303.46193.sergei.shtylyov@cogentembedded.com>
 <20130417101017.GW14496@n2100.arm.linux.org.uk>
Message-ID: <516E8EF9.8030600@cogentembedded.com>

Hello.

On 17-04-2013 14:10, Russell King - ARM Linux wrote:

>> From: Vladimir Barinov <vladimir.barinov at cogentembedded.com>

>> Enable CONFIG_PM_RUNTIME in 'bockw_defconfig' -- it's already used by TMU, SCI,
>> I2C, and Ether drivers to control the clocks...

>> Signed-off-by: Vladimir Barinov <vladimir.barinov at cogentembedded.com>
>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

>> ---
>> The patch is atop of Simon's 'renesas.git' tree, 'renesas-next-20130416' tag.

> Maybe you should send it to Simon rather than me for initial merging, who
> would presumably know if this is the right thing for this bockw platform?

    Blame scripts/get_maintainer.pl.
    I think Simion will see the patch on the list anyway.

WBR, Sergei



From hechtb at gmail.com  Wed Apr 17 08:06:20 2013
From: hechtb at gmail.com (Bastian Hecht)
Date: Wed, 17 Apr 2013 14:06:20 +0200
Subject: [PATCH] ARM: shmobile: r8a7740: Add Suspend-To-RAM modes and
 CPUIdle
In-Reply-To: <20130412002535.GB24461@verge.net.au>
References: <1365609107-14290-1-git-send-email-hechtb+renesas@gmail.com>
 <5165E929.9030309@linaro.org>
 <CABYn4sxEOvQhZP7GnS5-AgNjkvJJXyv4n1UjVGBjXbVq0N+9_A@mail.gmail.com>
 <51667D68.7070804@linaro.org> <20130412002535.GB24461@verge.net.au>
Message-ID: <CABYn4szC5XE5GV_y40h0h8rdemtnhEMeHTdtOm=JyoPYFzviAw@mail.gmail.com>

Hello Simon,

2013/4/12 Simon Horman <horms at verge.net.au>:
> On Thu, Apr 11, 2013 at 11:07:52AM +0200, Daniel Lezcano wrote:
>> On 04/11/2013 09:07 AM, Bastian Hecht wrote:
>> > Hello Daniel,
>> >
>> > thanks for the consolidation efforts.
>> >
>> > 2013/4/11 Daniel Lezcano <daniel.lezcano at linaro.org>:
>> >> On 04/10/2013 05:51 PM, Bastian Hecht wrote:
>> >>> We add 2 sleep modes and register a CPUIdle driver that uses them.
>> >>>
>> >>> - A3SM PLL0 on/off:     Power domain A3SM that contains the ARM core
>> >>>                         and the 2nd level cache with either PLL0 on
>> >>>                       or off
>> >>>
>> >>> As the suspend to memory mechanism we use A3SM PLL off.
>> >>>
>> >>> The setup of the SYSC regarding the external IRQs is taken from
>> >>> pm-sh7372.c from Magnus Damm.
>> >>>
>> >>> Signed-off-by: Bastian Hecht <hechtb+renesas at gmail.com>
>> >>> ---
>> >>> Ok I need to add some remarks here:
>> >>>
>> >>> First this patch relies on a fix I've sent out today:
>> >>> "ARM: hw_breakpoint: Do not use __cpuinitdata for dbg_cpu_pm_nb"
>> >>> Without it we can't use suspend at all without a kernel panic.
>> >>>
>> >>> Next you can test this in two ways:
>> >>> Either add IRQF_NO_SUSPEND to the touchscreen driver st1232 at IRQ registration
>> >>> (hack) or extend the irqpin driver to support wakeup devices properly, meaning
>> >>> adding suspend and resume callbacks that handle it (proper way). Or you can add
>> >>> no_console_suspend to the boot options in r8a7740-armadillo800eva.dts. This way
>> >>> you can use the serial console as wakeup device.
>> >>>
>> >>>
>> >>>  arch/arm/mach-shmobile/Makefile               |    2 +-
>> >>>  arch/arm/mach-shmobile/include/mach/r8a7740.h |    2 +
>> >>>  arch/arm/mach-shmobile/pm-r8a7740.c           |  220 ++++++++++++++++++++++++-
>> >>>  arch/arm/mach-shmobile/sleep-r8a7740.S        |   68 ++++++++
>> >>>  4 files changed, 289 insertions(+), 3 deletions(-)
>> >>>  create mode 100644 arch/arm/mach-shmobile/sleep-r8a7740.S
>> >>>
>> >>> diff --git a/arch/arm/mach-shmobile/Makefile b/arch/arm/mach-shmobile/Makefile
>> >>> index 068f1da..0568894 100644
>> >>> --- a/arch/arm/mach-shmobile/Makefile
>> >>> +++ b/arch/arm/mach-shmobile/Makefile
>> >>> @@ -30,7 +30,7 @@ obj-$(CONFIG_SUSPEND)               += suspend.o
>> >>>  obj-$(CONFIG_CPU_IDLE)               += cpuidle.o
>> >>>  obj-$(CONFIG_ARCH_SHMOBILE)  += pm-rmobile.o
>> >>>  obj-$(CONFIG_ARCH_SH7372)    += pm-sh7372.o sleep-sh7372.o
>> >>> -obj-$(CONFIG_ARCH_R8A7740)   += pm-r8a7740.o
>> >>> +obj-$(CONFIG_ARCH_R8A7740)   += pm-r8a7740.o sleep-r8a7740.o
>> >>>  obj-$(CONFIG_ARCH_R8A7779)   += pm-r8a7779.o
>> >>>  obj-$(CONFIG_ARCH_SH73A0)    += pm-sh73a0.o
>> >>>
>> >>> diff --git a/arch/arm/mach-shmobile/include/mach/r8a7740.h b/arch/arm/mach-shmobile/include/mach/r8a7740.h
>> >>> index abdc4d4..ba4707b 100644
>> >>> --- a/arch/arm/mach-shmobile/include/mach/r8a7740.h
>> >>> +++ b/arch/arm/mach-shmobile/include/mach/r8a7740.h
>> >>> @@ -540,6 +540,8 @@ extern void r8a7740_add_standard_devices(void);
>> >>>  extern void r8a7740_clock_init(u8 md_ck);
>> >>>  extern void r8a7740_pinmux_init(void);
>> >>>  extern void r8a7740_pm_init(void);
>> >>> +extern void r8a7740_resume(void);
>> >>> +extern void r8a7740_shutdown(void);
>> >>>
>> >>>  #ifdef CONFIG_PM
>> >>>  extern void __init r8a7740_init_pm_domains(void);
>> >>> diff --git a/arch/arm/mach-shmobile/pm-r8a7740.c b/arch/arm/mach-shmobile/pm-r8a7740.c
>> >>> index 40b87aa..d4613f0 100644
>> >>> --- a/arch/arm/mach-shmobile/pm-r8a7740.c
>> >>> +++ b/arch/arm/mach-shmobile/pm-r8a7740.c
>> >>> @@ -8,10 +8,54 @@
>> >>>   * License.  See the file "COPYING" in the main directory of this archive
>> >>>   * for more details.
>> >>>   */
>> >>> +#include <linux/bitrev.h>
>> >>>  #include <linux/console.h>
>> >>> +#include <linux/cpuidle.h>
>> >>> +#include <linux/module.h>
>> >>>  #include <linux/suspend.h>
>> >>> +#include <linux/io.h>
>> >>> +#include <asm/suspend.h>
>> >>> +#include <asm/cacheflush.h>
>> >>> +#include <asm/cpuidle.h>
>> >>> +#include <asm/hardware/cache-l2x0.h>
>> >>>  #include <mach/pm-rmobile.h>
>> >>>  #include <mach/common.h>
>> >>> +#include <mach/r8a7740.h>
>> >>> +
>> >>> +/* CPGA */
>> >>> +#define PLLC01STPCR  IOMEM(0xe61500c8)
>> >>> +#define SYSTBCR              IOMEM(0xe6150024)
>> >>> +
>> >>> +/* SYSC */
>> >>> +#define STBCHR               IOMEM(0xe6180000)
>> >>> +#define STBCHRB              IOMEM(0xe6180040)
>> >>> +#define SPDCR                IOMEM(0xe6180008)
>> >>> +#define SBAR         IOMEM(0xe6180020)
>> >>> +#define SRSTFR               IOMEM(0xe61800B4)
>> >>> +#define WUPSMSK              IOMEM(0xe618002c)
>> >>> +#define WUPSMSK2     IOMEM(0xe6180048)
>> >>> +#define WUPSFAC              IOMEM(0xe6180098)
>> >>> +#define IRQCR                IOMEM(0xe618022c)
>> >>> +#define IRQCR2               IOMEM(0xe6180238)
>> >>> +#define IRQCR3               IOMEM(0xe6180244)
>> >>> +#define IRQCR4               IOMEM(0xe6180248)
>> >>> +
>> >>> +/* SRSTFR flags */
>> >>> +#define RAMST                (1 << 19)
>> >>> +#define RCLNKA               (1 << 7)
>> >>> +#define RCPRES               (1 << 5)
>> >>> +#define RCWD1                (1 << 4)
>> >>> +#define RPF          (1 << 0)
>> >>> +
>> >>> +/* INTC */
>> >>> +#define ICR1A                IOMEM(0xe6900000)
>> >>> +#define ICR2A                IOMEM(0xe6900004)
>> >>> +#define ICR3A                IOMEM(0xe6900008)
>> >>> +#define ICR4A                IOMEM(0xe690000c)
>> >>> +#define INTMSK00A    IOMEM(0xe6900040)
>> >>> +#define INTMSK10A    IOMEM(0xe6900044)
>> >>> +#define INTMSK20A    IOMEM(0xe6900048)
>> >>> +#define INTMSK30A    IOMEM(0xe690004c)
>> >>>
>> >>>  #ifdef CONFIG_PM
>> >>>  static int r8a7740_pd_a4s_suspend(void)
>> >>> @@ -58,12 +102,183 @@ void __init r8a7740_init_pm_domains(void)
>> >>>       rmobile_init_domains(r8a7740_pm_domains, ARRAY_SIZE(r8a7740_pm_domains));
>> >>>       pm_genpd_add_subdomain_names("A4S", "A3SP");
>> >>>  }
>> >>> -
>> >>>  #endif /* CONFIG_PM */
>> >>>
>> >>> +#if defined(CONFIG_SUSPEND) || defined(CONFIG_CPU_IDLE)
>> >>> +static void r8a7740_set_reset_vector(unsigned long address)
>> >>> +{
>> >>> +     __raw_writel(address, SBAR);
>> >>> +}
>> >>> +
>> >>> +static void r8a7740_icr_to_irqcr(unsigned long icr, u16 *irqcr1p, u16 *irqcr2p)
>> >>> +{
>> >>> +     u16 tmp, irqcr1, irqcr2;
>> >>> +     int k;
>> >>> +
>> >>> +     irqcr1 = 0;
>> >>> +     irqcr2 = 0;
>> >>> +
>> >>> +     /* convert INTCA ICR register layout to SYSC IRQCR+IRQCR2 */
>> >>> +     for (k = 0; k <= 7; k++) {
>> >>> +             tmp = (icr >> ((7 - k) * 4)) & 0xf;
>> >>> +             irqcr1 |= (tmp & 0x03) << (k * 2);
>> >>> +             irqcr2 |= (tmp >> 2) << (k * 2);
>> >>> +     }
>> >>> +
>> >>> +     *irqcr1p = irqcr1;
>> >>> +     *irqcr2p = irqcr2;
>> >>> +}
>> >>> +
>> >>> +static void r8a7740_setup_sysc(unsigned long msk, unsigned long msk2)
>> >>> +{
>> >>> +     u16 irqcrx_low, irqcrx_high, irqcry_low, irqcry_high;
>> >>> +     unsigned long tmp;
>> >>> +
>> >>> +     /* read IRQ0A -> IRQ15A mask */
>> >>> +     tmp = bitrev8(__raw_readb(INTMSK00A));
>> >>> +     tmp |= bitrev8(__raw_readb(INTMSK10A)) << 8;
>> >>> +
>> >>> +     /* setup WUPSMSK from clocks and external IRQ mask */
>> >>> +     msk = (~msk & 0xc030000f) | (tmp << 4);
>> >>> +     __raw_writel(msk, WUPSMSK);
>> >>> +
>> >>> +     /* propage level/edge trigger for external IRQ 0->15 */
>> >>> +     r8a7740_icr_to_irqcr(__raw_readl(ICR1A), &irqcrx_low, &irqcry_low);
>> >>> +     r8a7740_icr_to_irqcr(__raw_readl(ICR2A), &irqcrx_high, &irqcry_high);
>> >>> +     __raw_writel((irqcrx_high << 16) | irqcrx_low, IRQCR);
>> >>> +     __raw_writel((irqcry_high << 16) | irqcry_low, IRQCR2);
>> >>> +
>> >>> +     /* read IRQ16A -> IRQ31A mask */
>> >>> +     tmp = bitrev8(__raw_readb(INTMSK20A));
>> >>> +     tmp |= bitrev8(__raw_readb(INTMSK30A)) << 8;
>> >>> +
>> >>> +     /* setup WUPSMSK2 from clocks and external IRQ mask */
>> >>> +     msk2 = (~msk2 & 0x00030000) | tmp;
>> >>> +     __raw_writel(msk2, WUPSMSK2);
>> >>> +
>> >>> +     /* propage level/edge trigger for external IRQ 16->31 */
>> >>> +     r8a7740_icr_to_irqcr(__raw_readl(ICR3A), &irqcrx_low, &irqcry_low);
>> >>> +     r8a7740_icr_to_irqcr(__raw_readl(ICR4A), &irqcrx_high, &irqcry_high);
>> >>> +     __raw_writel((irqcrx_high << 16) | irqcrx_low, IRQCR3);
>> >>> +     __raw_writel((irqcry_high << 16) | irqcry_low, IRQCR4);
>> >>> +}
>> >>> +
>> >>> +static void r8a7740_prepare_wakeup(void)
>> >>> +{
>> >>> +     /* clear all flags that lead to a cold boot */
>> >>> +     __raw_writel(~(RAMST | RCLNKA | RCPRES | RCWD1 | RPF), SRSTFR);
>> >>> +     /* indicate warm boot */
>> >>> +     __raw_writel(0x80000000, STBCHRB);
>> >>> +     /* clear other flags checked by internal ROM boot loader */
>> >>> +     __raw_writel(0x00000000, STBCHR);
>> >>> +}
>> >>> +
>> >>> +static int r8a7740_do_suspend(unsigned long unused)
>> >>> +{
>> >>> +     /*
>> >>> +      * cpu_suspend() guarantees that all data made it to the L2.
>> >>> +      * Flush it out now and disable the cache controller.
>> >>> +      */
>> >>> +     outer_flush_all();
>> >>> +     outer_disable();
>> >>> +
>> >>> +     r8a7740_shutdown();
>> >>> +
>> >>> +     /* in case WFI fails to enter the low power state, restore things */
>> >>> +     outer_resume();
>> >>> +
>> >>> +     return 0;
>> >>> +}
>> >>> +
>> >>> +static void r8a7740_enter_a3sm_common(int pllc0_on)
>> >>> +{
>> >>> +     u32 reg32;
>> >>> +
>> >>> +     if (pllc0_on)
>> >>> +             __raw_writel(0, PLLC01STPCR);
>> >>> +     else
>> >>> +             __raw_writel(1 << 28, PLLC01STPCR);
>> >>> +
>> >>> +     r8a7740_set_reset_vector(__pa(r8a7740_resume));
>> >>> +     r8a7740_prepare_wakeup();
>> >>> +     r8a7740_setup_sysc(1 << 0, 0);
>> >>> +
>> >>> +     /* Activate delayed shutdown of A3SM */
>> >>> +     reg32 = __raw_readl(SPDCR);
>> >>> +     reg32 |= (1 << 31) | (1 << 12);
>> >>> +     __raw_writel(reg32, SPDCR);
>> >>> +
>> >>> +     /* We activate CPU Core Standby as well here */
>> >>> +     reg32 = __raw_readl(SYSTBCR);
>> >>> +     reg32 |= (1 << 4);
>> >>> +     __raw_writel(reg32, SYSTBCR);
>> >>> +
>> >>> +     /* Clear Wakeup Factors and do suspend */
>> >>> +     reg32 = __raw_readl(WUPSFAC);
>> >>> +     cpu_suspend(0, r8a7740_do_suspend);
>> >>> +     outer_resume();
>> >>> +     reg32 = __raw_readl(WUPSFAC);
>> >>> +
>> >>> +     /* Clear CPU Core Standby flag for other WFI instructions */
>> >>> +     reg32 &= ~(1 << 4);
>> >>> +     __raw_writel(reg32, SYSTBCR);
>> >>> +
>> >>> +}
>> >>> +#endif /* CONFIG_SUSPEND || CONFIG_CPU_IDLE */
>> >>> +
>> >>> +#ifdef CONFIG_CPU_IDLE
>> >>> +static int r8a7740_enter_a3sm_pll_on(struct cpuidle_device *dev,
>> >>> +                                     struct cpuidle_driver *drv, int index)
>> >>> +{
>> >>> +     r8a7740_enter_a3sm_common(1);
>> >>> +     return 1;
>> >>> +}
>> >>> +
>> >>> +static int r8a7740_enter_a3sm_pll_off(struct cpuidle_device *dev,
>> >>> +                                     struct cpuidle_driver *drv, int index)
>> >>> +{
>> >>> +     r8a7740_enter_a3sm_common(0);
>> >>> +     return 2;
>> >>> +}
>> >>> +
>> >>> +static struct cpuidle_driver r8a7740_cpuidle_driver = {
>> >>> +     .name                   = "r8a7740_cpuidle",
>> >>> +     .owner                  = THIS_MODULE,
>> >>> +     .en_core_tk_irqen       = 1,
>> >>> +     .state_count            = 3,
>> >>> +     .safe_state_index       = 0, /* C1 */
>> >>> +     .states[0] = ARM_CPUIDLE_WFI_STATE,
>> >>> +     .states[0].enter = shmobile_enter_wfi,
>> >>
>> >> The WFI macro already set a simple enter function doing cpu_do_idle.
>> >
>> > Oh yes, I'll remove it.
>> >
>> >> We are trying to consolidate the cpuidle drivers across the different
>> >> platforms [1]. One of the objective is to move the cpuidle drivers to
>> >> drivers/cpuidle, a place where they belong to.
>> >>
>> >> Do you think it is possible you split your code to have one part with
>> >> the cpuidle driver and another part with the PM code ?
>> >
>> > Hmm. The CPUIdle part is enclosed in the #ifdef CONFIG_CPU_IDLE part anyway.
>> > The other part (CONFIG_SUSPEND | CONFIG_CPU_IDLE) contains the part
>> > that actually does drive down the hardware and is needed as soon as
>> > SUSPEND or CPUIdle is used.
>> >
>> > So is it split well enough already or does it help if I split my patch
>> > into 2, first adding suspend and then CPUIdle to the same file? But
>> > the outcome will be the same I think.
>>
>>
>> Well, if you can convert the pm functions into ops used in the cpuidle
>> driver and then create a file eg. cpuidle-r8a7740.c with the cpuidle
>> code calling the ops that will separate clearly the cpuidle code from
>> the pm code and make easier to move the cpuidle driver to the
>> drivers/cpuidle directory. Also, I think that will help to consolidate
>> the other shmobile cpuidle drivers, maybe into a single one.
>
> I wonder if that is an appropriate pre-requisite for adding
> r8a7940 cpuidle support. My preference, which may well be compatible
> with your comments, is to bring support for that SoC up to the same level
> as support for other shmobile SoCs and to treat consolidation as a
> an area of work that is undertaken in parallel.

I just realize that I've overlooked this comment. Sorry for that. I
thought about the same:
The advantages of Daniel's way vs the temporary cluttering of our
arch/arm/mach-shmobile tree.
I'm really open for both ways - I think the extra cpuidle file doesn't
hurt too much and it would be OK to go with it, but I can merge the 2
patches if you strongly prefer the other way.

Cheers,

 Bastian


From marc.zyngier at arm.com  Wed Apr 17 08:24:06 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 17 Apr 2013 13:24:06 +0100
Subject: [PATCH] ARM: KVM: iterate over all CPUs for CPU compatibility
 check
In-Reply-To: <CAFEAcA8oE+2BRRgoeA4-0PzOQkxzGwDT5qunudzg7RBA9aWCgQ@mail.gmail.com>
References: <1365771875-5788-1-git-send-email-andre.przywara@linaro.org>
 <51680AF9.7040109@arm.com>
 <CAFEAcA-1HAG0pY-j-rqU=QmSoep3Di-KNPATvuou8ghRn3SaqA@mail.gmail.com>
 <516810F7.7040601@arm.com> <20130417101906.GX14496@n2100.arm.linux.org.uk>
 <516E7ADE.5090601@arm.com>
 <CAEDV+gK3nitpN+8ZePRY7n+bsc2t4XbWrz6fbdz0Wjq_kTgM4g@mail.gmail.com>
 <516E87D1.5000109@arm.com>
 <CAFEAcA8oE+2BRRgoeA4-0PzOQkxzGwDT5qunudzg7RBA9aWCgQ@mail.gmail.com>
Message-ID: <516E9466.2070805@arm.com>

On 17/04/13 12:38, Peter Maydell wrote:
> On 17 April 2013 12:30, Marc Zyngier <marc.zyngier at arm.com> wrote:
>> By disabling the problematic configuration, we just bury our head in the
>> sand and pretend everything is fine. Yes, this is a new feature. But by
>> saying "not a supported configuration", while the code *should* support
>> it, we're only fooling ourselves.
> 
> Who says the code should support running on big.LITTLE?

I do. The host code definitely should. If it doesn't, then lets fix that
bug, as it probably means the support is also broken on A15.

As I said in another email, guest support is a separate issue.

	M.
-- 
Jazz is not dead. It just smells funny...



From peter.maydell at linaro.org  Wed Apr 17 08:25:41 2013
From: peter.maydell at linaro.org (Peter Maydell)
Date: Wed, 17 Apr 2013 13:25:41 +0100
Subject: [PATCH] ARM: KVM: iterate over all CPUs for CPU compatibility
 check
In-Reply-To: <516E9466.2070805@arm.com>
References: <1365771875-5788-1-git-send-email-andre.przywara@linaro.org>
 <51680AF9.7040109@arm.com>
 <CAFEAcA-1HAG0pY-j-rqU=QmSoep3Di-KNPATvuou8ghRn3SaqA@mail.gmail.com>
 <516810F7.7040601@arm.com> <20130417101906.GX14496@n2100.arm.linux.org.uk>
 <516E7ADE.5090601@arm.com>
 <CAEDV+gK3nitpN+8ZePRY7n+bsc2t4XbWrz6fbdz0Wjq_kTgM4g@mail.gmail.com>
 <516E87D1.5000109@arm.com>
 <CAFEAcA8oE+2BRRgoeA4-0PzOQkxzGwDT5qunudzg7RBA9aWCgQ@mail.gmail.com>
 <516E9466.2070805@arm.com>
Message-ID: <CAFEAcA8ty-hWUZtjiEvZDNNDCwkT6NhsuF0wneSTuugWDB3uHQ@mail.gmail.com>

On 17 April 2013 13:24, Marc Zyngier <marc.zyngier at arm.com> wrote:
> On 17/04/13 12:38, Peter Maydell wrote
>> Who says the code should support running on big.LITTLE?
>
> I do. The host code definitely should. If it doesn't, then lets fix that
> bug, as it probably means the support is also broken on A15.

Last time I looked we weren't intercepting ID and feature
registers. That's broken if the host isn't A15.

-- PMM


From grinberg at compulab.co.il  Wed Apr 17 08:26:34 2013
From: grinberg at compulab.co.il (Igor Grinberg)
Date: Wed, 17 Apr 2013 15:26:34 +0300
Subject: [PATCH] ARM: dts: omap3-beagle-xm: Add USB Host support for Rev
 Ax/Bx
In-Reply-To: <516E5F9E.3050204@ti.com>
References: <1366029306-1824-1-git-send-email-rogerq@ti.com>
 <516BF4F3.5060904@ti.com> <20130417005232.GV10155@atomide.com>
 <CAOCHtYgFnCy5Qn2LeJOK96_NdwzxzVe8Vrb8cL=K9AdzPUtQow@mail.gmail.com>
 <516E5597.7050801@compulab.co.il> <516E5F9E.3050204@ti.com>
Message-ID: <516E94FA.9060606@compulab.co.il>

On 04/17/13 11:38, Roger Quadros wrote:
> On 04/17/2013 10:56 AM, Igor Grinberg wrote:
>> On 04/17/13 04:30, Robert Nelson wrote:
>>> On Tue, Apr 16, 2013 at 7:52 PM, Tony Lindgren <tony at atomide.com> wrote:
>>>> * Roger Quadros <rogerq at ti.com> [130415 05:44]:
>>>>> On 04/15/2013 03:35 PM, Roger Quadros wrote:
>>>>>> Provide RESET and Power regulators for the USB PHY,
>>>>>> the USB Host port mode and the PHY device.
>>>>>>
>>>>>> Also provide pin multiplexer information for USB host
>>>>>> pins.
>>>>>>
>>>>>> This will not work for Rev Cx boards because of reversed logic
>>>>>> for USB_POWER_Enable.
>>>>>>
>>>>>> CC: Beno?t Cousson <b-cousson at ti.com>
>>>>>> Signed-off-by: Roger Quadros <rogerq at ti.com>
>>>>>> ---
>>>>>>  arch/arm/boot/dts/omap3-beagle-xm.dts |   62 +++++++++++++++++++++++++++++++++
>>>>>>  1 files changed, 62 insertions(+), 0 deletions(-)
>>>>>>
>>>>>> diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts b/arch/arm/boot/dts/omap3-beagle-xm.dts
>>>>>> index 5a31964..d394c51 100644
>>>>>> --- a/arch/arm/boot/dts/omap3-beagle-xm.dts
>>>>>> +++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
>>>>>> @@ -57,6 +57,60 @@
>>>>>>             ti,mcbsp = <&mcbsp2>;
>>>>>>             ti,codec = <&twl_audio>;
>>>>>>     };
>>>>>> +
>>>>>> +   /* HS USB Port 2 RESET */
>>>>>> +   hsusb2_reset: hsusb2_reset_reg {
>>>>>> +           compatible = "regulator-fixed";
>>>>>> +           regulator-name = "hsusb2_reset";
>>>>>> +           regulator-min-microvolt = <3300000>;
>>>>>> +           regulator-max-microvolt = <3300000>;
>>>>>> +           gpio = <&gpio5 19 0>;   /* gpio_147 */
>>>>>> +           startup-delay-us = <70000>;
>>>>>> +           enable-active-high;
>>>>>> +   };
>>>>>> +
>>>>>> +   /* HS USB Port 2 Power */
>>>>>> +   hsusb2_power: hsusb2_power_reg {
>>>>>> +           compatible = "regulator-fixed";
>>>>>> +           regulator-name = "hsusb2_vbus";
>>>>>> +           regulator-min-microvolt = <3300000>;
>>>>>> +           regulator-max-microvolt = <3300000>;
>>>>>> +           gpio = <&twl_gpio 18 0>;        /* GPIO LEDA */
>>>>>> +           startup-delay-us = <70000>;
>>>>>> +           enable-active-high;     /* FIXME: active-low for Rev. C */
>>>>>
>>>>> Benoit & Tony,
>>>>>
>>>>> Any ideas how to tackle the reversed logic for Rev. C boards?
>>>>
>>>> Sounds like we need a shared omap3-beage.dtsi, then omap3-beagle-xm.dts
>>>> and omap3-beagle-rev-c.dts. Then xm and rev-c can both include the
>>>
>>> Bike-sheding, but we might want to make that "omap3-beagle-xmc.dts" as
>>> there is the "rev c" variant of the original beagle...
>>>
>>> It's too bad we can't read the 3 gpio pin states in the device tree
>>> and make a decision.
>>
>> I would recommend to move the detection to the boot loader and
>> adjust the DT blob at run time (in the boot loader).
>> This way, we will not need to deal with all the (sub)revision stuff.
>>
>>
> Moving the detection to bootloader is fine, but modifying the DT at
> runtime would create a debug/maintenance issue. Instead it could just
> pick one of the .DTBs and pass it to kernel.

Like this will not create create any debug/maintenance issues.... ;-)
We have no problem with debug, as all the DT nodes can be seen in
both U-Boot (with fdt commands) and Linux through procfs...

I've just dropped my 2 cents and I don't really insist...

> 
> Since most users will be using rev-c, I think we should keep the original
> file 'omap3-beagle-xm.dts" as it is for rev-c boards.
> I can just create a new dts file for Revisions A and B that will be
> like so.
> 
> +++ b/arch/arm/boot/dts/omap3-beagle-xm-ab.dts
> @@ -0,0 +1,6 @@
> +/include/ "omap3-beagle-xm.dts"
> +
> +/* On Rev A/B USBHOST_PWR_EN is active high */
> +&hsusb2_power {
> +       enable-active-high;
> +};
> 
> Since omap3-beagle and omap3-beagle-xm use different SoC versions and have
> quite many differences, I don't think it is a good idea to create a common
> file between the two.
> 
> cheers,
> -roger
> 

-- 
Regards,
Igor.


From bevenson at melinkcorp.com  Wed Apr 17 08:25:10 2013
From: bevenson at melinkcorp.com (Bryan Evenson)
Date: Wed, 17 Apr 2013 08:25:10 -0400
Subject: at91:  DT for MAC EEPROM?
Message-ID: <91586D499ADFD74FBCFB8425266A5DE40139FD848A18@pluto.melinkcorp.local>

I have a AT91SAM9G25 based board that has a I2C MAC EEPROM chip (Microchip 24AA02E48).  Our board is based on the SAM9G25-EK with the 24AA02E48 replacing the I2C EEPROM on the SAM9G25-EK.  I have some questions with integrating the MAC EEPROM with the latest device tree setup and the Ethernet driver.

1.  The 24AA02E48 uses the same I2C messaging protocol and the same address as the I2C EEPROM used on the SAM9G25-EK.  Is there any need to replace the device tree info in the dts files for my setup?

2.  Is there any Ethernet related device tree setup that I need that is related to the MAC address?

3.  I am planning on removing U-Boot from our production setup and having the AT91 Bootstrap boot the Linux kernel.  Is there anything device tree (or non-device tree) related that I need to add so that the kernel finds the MAC address that is on the EERPOM?

Thanks,
Bryan Evenson


From marc.zyngier at arm.com  Wed Apr 17 08:28:59 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 17 Apr 2013 13:28:59 +0100
Subject: [PATCH] ARM: KVM: iterate over all CPUs for CPU compatibility
 check
In-Reply-To: <CAFEAcA8ty-hWUZtjiEvZDNNDCwkT6NhsuF0wneSTuugWDB3uHQ@mail.gmail.com>
References: <1365771875-5788-1-git-send-email-andre.przywara@linaro.org>
 <51680AF9.7040109@arm.com>
 <CAFEAcA-1HAG0pY-j-rqU=QmSoep3Di-KNPATvuou8ghRn3SaqA@mail.gmail.com>
 <516810F7.7040601@arm.com> <20130417101906.GX14496@n2100.arm.linux.org.uk>
 <516E7ADE.5090601@arm.com>
 <CAEDV+gK3nitpN+8ZePRY7n+bsc2t4XbWrz6fbdz0Wjq_kTgM4g@mail.gmail.com>
 <516E87D1.5000109@arm.com>
 <CAFEAcA8oE+2BRRgoeA4-0PzOQkxzGwDT5qunudzg7RBA9aWCgQ@mail.gmail.com>
 <516E9466.2070805@arm.com>
 <CAFEAcA8ty-hWUZtjiEvZDNNDCwkT6NhsuF0wneSTuugWDB3uHQ@mail.gmail.com>
Message-ID: <516E958B.7080300@arm.com>

On 17/04/13 13:25, Peter Maydell wrote:
> On 17 April 2013 13:24, Marc Zyngier <marc.zyngier at arm.com> wrote:
>> On 17/04/13 12:38, Peter Maydell wrote
>>> Who says the code should support running on big.LITTLE?
>>
>> I do. The host code definitely should. If it doesn't, then lets fix that
>> bug, as it probably means the support is also broken on A15.
> 
> Last time I looked we weren't intercepting ID and feature
> registers. That's broken if the host isn't A15.

Would you please look at the sentence that follows the one you've
quoted? It says "guest support is a separate issue". As in "orthogonal
problem".

	M.
-- 
Jazz is not dead. It just smells funny...



From peter.maydell at linaro.org  Wed Apr 17 08:38:09 2013
From: peter.maydell at linaro.org (Peter Maydell)
Date: Wed, 17 Apr 2013 13:38:09 +0100
Subject: [PATCH] ARM: KVM: iterate over all CPUs for CPU compatibility
 check
In-Reply-To: <516E958B.7080300@arm.com>
References: <1365771875-5788-1-git-send-email-andre.przywara@linaro.org>
 <51680AF9.7040109@arm.com>
 <CAFEAcA-1HAG0pY-j-rqU=QmSoep3Di-KNPATvuou8ghRn3SaqA@mail.gmail.com>
 <516810F7.7040601@arm.com> <20130417101906.GX14496@n2100.arm.linux.org.uk>
 <516E7ADE.5090601@arm.com>
 <CAEDV+gK3nitpN+8ZePRY7n+bsc2t4XbWrz6fbdz0Wjq_kTgM4g@mail.gmail.com>
 <516E87D1.5000109@arm.com>
 <CAFEAcA8oE+2BRRgoeA4-0PzOQkxzGwDT5qunudzg7RBA9aWCgQ@mail.gmail.com>
 <516E9466.2070805@arm.com>
 <CAFEAcA8ty-hWUZtjiEvZDNNDCwkT6NhsuF0wneSTuugWDB3uHQ@mail.gmail.com>
 <516E958B.7080300@arm.com>
Message-ID: <CAFEAcA_FdUwFCmxm9yEF5fP1SGyfh=RG8RqEx51k95PRMeQPAw@mail.gmail.com>

On 17 April 2013 13:28, Marc Zyngier <marc.zyngier at arm.com> wrote:
> On 17/04/13 13:25, Peter Maydell wrote:
>> On 17 April 2013 13:24, Marc Zyngier <marc.zyngier at arm.com> wrote:
>>> On 17/04/13 12:38, Peter Maydell wrote
>>>> Who says the code should support running on big.LITTLE?
>>>
>>> I do. The host code definitely should. If it doesn't, then lets fix that
>>> bug, as it probably means the support is also broken on A15.
>>
>> Last time I looked we weren't intercepting ID and feature
>> registers. That's broken if the host isn't A15.
>
> Would you please look at the sentence that follows the one you've
> quoted? It says "guest support is a separate issue". As in "orthogonal
> problem".

I'm confused now, because I thought the whole point of this
patch was that we don't support guests on big.LITTLE but
we're not locking them out (the way we would for an all-A7
system). That is, we're fixing a bug in the check code.

Obviously it seems worth investigating exactly what is
happening on the A7s when we try to run the init code,
but it seems to me like that's the orthogonal issue,
because we shouldn't be running that code in the first
place.

-- PMM


From marc.zyngier at arm.com  Wed Apr 17 09:00:03 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 17 Apr 2013 14:00:03 +0100
Subject: [PATCH] ARM: KVM: iterate over all CPUs for CPU compatibility
 check
In-Reply-To: <CAFEAcA_FdUwFCmxm9yEF5fP1SGyfh=RG8RqEx51k95PRMeQPAw@mail.gmail.com>
References: <1365771875-5788-1-git-send-email-andre.przywara@linaro.org>
 <51680AF9.7040109@arm.com>
 <CAFEAcA-1HAG0pY-j-rqU=QmSoep3Di-KNPATvuou8ghRn3SaqA@mail.gmail.com>
 <516810F7.7040601@arm.com> <20130417101906.GX14496@n2100.arm.linux.org.uk>
 <516E7ADE.5090601@arm.com>
 <CAEDV+gK3nitpN+8ZePRY7n+bsc2t4XbWrz6fbdz0Wjq_kTgM4g@mail.gmail.com>
 <516E87D1.5000109@arm.com>
 <CAFEAcA8oE+2BRRgoeA4-0PzOQkxzGwDT5qunudzg7RBA9aWCgQ@mail.gmail.com>
 <516E9466.2070805@arm.com>
 <CAFEAcA8ty-hWUZtjiEvZDNNDCwkT6NhsuF0wneSTuugWDB3uHQ@mail.gmail.com>
 <516E958B.7080300@arm.com>
 <CAFEAcA_FdUwFCmxm9yEF5fP1SGyfh=RG8RqEx51k95PRMeQPAw@mail.gmail.com>
Message-ID: <516E9CD3.40909@arm.com>

On 17/04/13 13:38, Peter Maydell wrote:
> On 17 April 2013 13:28, Marc Zyngier <marc.zyngier at arm.com> wrote:
>> On 17/04/13 13:25, Peter Maydell wrote:
>>> On 17 April 2013 13:24, Marc Zyngier <marc.zyngier at arm.com> wrote:
>>>> On 17/04/13 12:38, Peter Maydell wrote
>>>>> Who says the code should support running on big.LITTLE?
>>>>
>>>> I do. The host code definitely should. If it doesn't, then lets fix that
>>>> bug, as it probably means the support is also broken on A15.
>>>
>>> Last time I looked we weren't intercepting ID and feature
>>> registers. That's broken if the host isn't A15.
>>
>> Would you please look at the sentence that follows the one you've
>> quoted? It says "guest support is a separate issue". As in "orthogonal
>> problem".
> 
> I'm confused now, because I thought the whole point of this
> patch was that we don't support guests on big.LITTLE but
> we're not locking them out (the way we would for an all-A7
> system). That is, we're fixing a bug in the check code.
> 
> Obviously it seems worth investigating exactly what is
> happening on the A7s when we try to run the init code,
> but it seems to me like that's the orthogonal issue,
> because we shouldn't be running that code in the first
> place.

Turns out that init code was designed to run unchanged on both A15 and
A7. If that code isn't properly working on a HYP-aware CPU, then we're
in trouble.

I don't give a damn about full BL support in KVM at that stage. All I
want is a clear description of *why* that code is failing, and possibly
a way to run guests on the A15 side of a BL platform, without having to
give away half of the cores.

I think I've already spent too much time arguing about this. Hopefully
someone will be interested enough in BL to revert this patch and fix the
code (whether it is in the kernel or bootloader).

	M.
-- 
Jazz is not dead. It just smells funny...



From broonie at kernel.org  Wed Apr 17 09:06:10 2013
From: broonie at kernel.org (Mark Brown)
Date: Wed, 17 Apr 2013 14:06:10 +0100
Subject: [PATCH v5 3/6] gpio: samsung: Skip legacy GPIO registration if
 pinctrl-s3c64xx is present
In-Reply-To: <22399020.Z89v9QS8su@flatron>
References: <1366060483-20342-1-git-send-email-tomasz.figa@gmail.com>
 <1366060483-20342-4-git-send-email-tomasz.figa@gmail.com>
 <20130416162750.GO26958@opensource.wolfsonmicro.com>
 <22399020.Z89v9QS8su@flatron>
Message-ID: <20130417130609.GA13687@opensource.wolfsonmicro.com>

On Wed, Apr 17, 2013 at 12:35:58AM +0200, Tomasz Figa wrote:
> On Tuesday 16 of April 2013 17:27:50 Mark Brown wrote:

> > Strictly speaking this is a separate bug fix (though I see that's
> > already in -next separately anyway so whatever).

> Right. But this fix is so small that I thought it would be a major waste 
> of mail server processing power to send it as a separate patch.

There's reviewer bandwidth too - one of the things people check for is
that the change is doing what it's supposed to do, extra stuff in there
is usually a red flag.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130417/67479e82/attachment.sig>

From broonie at kernel.org  Wed Apr 17 09:08:24 2013
From: broonie at kernel.org (Mark Brown)
Date: Wed, 17 Apr 2013 14:08:24 +0100
Subject: [PATCH v5 0/6] Initial Device Tree support for S3C64xx
In-Reply-To: <1366060483-20342-1-git-send-email-tomasz.figa@gmail.com>
References: <1366060483-20342-1-git-send-email-tomasz.figa@gmail.com>
Message-ID: <20130417130824.GB13687@opensource.wolfsonmicro.com>

On Mon, Apr 15, 2013 at 11:14:37PM +0200, Tomasz Figa wrote:
> This series adds Device Tree support for Samsung S3C64xx SoC series.
> 
> It fixes several problems preventing from booting an S3C64xx-based system
> using Device Tree, adds all the infrastructure for Device Tree-based board
> support, including mach-s3c64xx-dt and dts include files for S3C64xx SoCs,
> and basic device tree source for FriendlyARM Mini6410 board.

Tested-by: Mark Brown <broonie at opensource.wolfsonmicro.com>

in the non-DT case :P
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130417/7ec00e05/attachment.sig>

From jon-hunter at ti.com  Wed Apr 17 09:25:05 2013
From: jon-hunter at ti.com (Jon Hunter)
Date: Wed, 17 Apr 2013 08:25:05 -0500
Subject: [PATCH 3/5] gpio/omap: Add DT support to GPIO driver
In-Reply-To: <CAAwP0s2M2pnSydyDvh_rejFO=w8bCo4WE5PkxrYuk0HQDixc-Q@mail.gmail.com>
References: <1329321854-24490-1-git-send-email-b-cousson@ti.com>
 <CACRpkdYXVLgCz1Tyu-Ls2V2OTc4R3cGNJhfQJB6Hiz_K9dkZYQ@mail.gmail.com>
 <5155C902.7080207@wwwdotorg.org>
 <CACRpkdYbs4-uudpRUY8e+7icYYkZrfM0kReP3pLL5DMiURJ4dg@mail.gmail.com>
 <5165CB9D.1090202@wwwdotorg.org>
 <CACRpkdYirFNqmGhA4K9CL4ve4NYhs8Rd3SFt1iwW9vHBkrcz8g@mail.gmail.com>
 <51671D7B.5060303@wwwdotorg.org>
 <CACRpkdbf32Ef77GmXk9id9+RRjcDRTr7S+F4nznoeZU8y=BT_Q@mail.gmail.com>
 <51673D70.3010503@wwwdotorg.org>
 <CAAwP0s0e2x33jZQhFRY+Hoo61SFqYKRgWk=1mL2+DNxSDJHz+A@mail.gmail.com>
 <CACRpkda4h+qXTvsirPAS7E7sjXhMLE62q=VDy53W8UchsYjbNg@mail.gmail.com>
 <516C31C3.9040505@wwwdotorg.org> <516C7C43.3040105@wwwdotorg.org>
 <516C8760.2050500@ti.com> <516D9B05.1000501@wwwdotorg.org>
 <516DA60A.5070000@ti.com> <516DCCA8.3070108@wwwdotorg.org>
 <516DDB4D.9020500@ti.com>
 <CAAwP0s0-VNUoeSKaGbvoDeD7m7kZRdp5rCJ7iVpFoFAaQtXcmQ@mail.gmail.com>
 <516E022F.5050708@ti.com>
 <CAAwP0s2M2pnSydyDvh_rejFO=w8bCo4WE5PkxrYuk0HQDixc-Q@mail.gmail.com>
Message-ID: <516EA2B1.3070201@ti.com>


On 04/17/2013 02:55 AM, Javier Martinez Canillas wrote:

...

> There are so many patches flying around in this thread that I missed it :-)
> 
> Sorry about that...

No problem.

>> I was trying to see if we could find a common solution that everyone
>> could use as it seems that ideally we should all be requesting the gpio.
>>
>> Cheers
>> Jon
>>
>> [1] http://marc.info/?l=linux-arm-kernel&m=136606204823845&w=1
> 
> btw, I shared the latest patch with only build testing it, but today I
> gave a try and I found a problem with this approach. The .xlate
> function is being called twice for each GPIO-IRQ so the first time
> gpio_request_one() succeeds but the second time it fails returning
> -EBUSY.

I tried it and I did not see that. I don't see the below warning either.

> This raises a warning on drivers/of/platform.c
> (WARN_ON(of_irq_to_resource_table(np, res, num_irq) != num_irq)):
> 
>     0.285308] ------------[ cut here ]------------
> [    0.285369] WARNING: at drivers/of/platform.c:171
> of_device_alloc+0x154/0x168()
> [    0.285430] Modules linked in:
> [    0.285491] [<c001a944>] (unwind_backtrace+0x0/0xf0) from
> [<c0041edc>] (warn_slowpath_common+0x4c/0x68)
> [    0.285552] [<c0041edc>] (warn_slowpath_common+0x4c/0x68) from
> [<c0041f14>] (warn_slowpath_null+0x1c/0x24)
> [    0.285614] [<c0041f14>] (warn_slowpath_null+0x1c/0x24) from
> [<c041ac3c>] (of_device_alloc+0x154/0x168)
> [    0.285675] [<c041ac3c>] (of_device_alloc+0x154/0x168) from
> [<c041ac84>] (of_platform_device_create_pdata+0x34/0x80)
> [    0.285736] [<c041ac84>]
> (of_platform_device_create_pdata+0x34/0x80) from [<c0027364>]
> (gpmc_probe_generic_child+0x180/0x240)
> [    0.285827] [<c0027364>] (gpmc_probe_generic_child+0x180/0x240)
> from [<c00278d8>] (gpmc_probe+0x4b4/0x614)
> [    0.285888] [<c00278d8>] (gpmc_probe+0x4b4/0x614) from [<c0325514>]
> (platform_drv_probe+0x18/0x1c)
> [    0.285949] [<c0325514>] (platform_drv_probe+0x18/0x1c) from
> [<c0324354>] (driver_probe_device+0x108/0x21c)

Any chance you have still have some additional code in your dts to
request the gpio? I recall you made some hacks to make this work before.

> I probably won't have time to dig further on this until later this
> week but I wanted to share with you in case you know why is being
> calling twice and if you thought about a solution.

Care to post your dts file?

> It works if I don't check the return gpio_request_one() (or better if
> we don't return on omap_gpio_irq_domain_xlate) but of course is not
> the right solution.

Yes we need to check the return value.

Cheers
Jon


From lee.jones at linaro.org  Wed Apr 17 09:32:14 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Wed, 17 Apr 2013 14:32:14 +0100
Subject: [PATCH] mmc: mmci: Allow MMCI to request channels with information
 acquired from DT
Message-ID: <1366205534-25079-1-git-send-email-lee.jones@linaro.org>

Currently, if DMA information isn't passed from platform data, then DMA
will not be used. This patch allows DMA information obtained though Device
Tree to be used as well.

Cc: Russell King <linux at arm.linux.org.uk>
Cc: Chris Ball <cjb at laptop.org>
Cc: linux-mmc at vger.kernel.org
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 drivers/mmc/host/mmci.c |   43 +++++++++++++++++++++++++++++++------------
 1 file changed, 31 insertions(+), 12 deletions(-)

diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index 372e921..42e8fec 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -298,15 +298,32 @@ static void mmci_init_sg(struct mmci_host *host, struct mmc_data *data)
  * no custom DMA interfaces are supported.
  */
 #ifdef CONFIG_DMA_ENGINE
-static void mmci_dma_setup(struct mmci_host *host)
+static void mmci_dma_setup(struct amba_device *dev,
+			   struct mmci_host *host)
 {
+	struct device_node *np = dev->dev.of_node;
 	struct mmci_platform_data *plat = host->plat;
 	const char *rxname, *txname;
 	dma_cap_mask_t mask;
+	const char *chan_name;
+	int count, i;
+	bool do_tx = false, do_rx = false;
 
 	if (!plat || !plat->dma_filter) {
-		dev_info(mmc_dev(host->mmc), "no DMA platform data\n");
-		return;
+		if (np) {
+			count = of_property_count_strings(np, "dma-names");
+			for (i = 0; i < count; i++) {
+				of_property_read_string_index(np, "dma-names",
+							      i, &chan_name);
+				if (strcmp(chan_name, "tx"))
+					do_tx = true;
+				else if (strcmp(chan_name, "rx"))
+					do_rx = true;
+			}
+		} else {
+			dev_info(mmc_dev(host->mmc), "no DMA platform data\n");
+			return;
+		}
 	}
 
 	/* initialize pre request cookie */
@@ -321,19 +338,21 @@ static void mmci_dma_setup(struct mmci_host *host)
 	 * attempt to use it bidirectionally, however if it is
 	 * is specified but cannot be located, DMA will be disabled.
 	 */
-	if (plat->dma_rx_param) {
-		host->dma_rx_channel = dma_request_channel(mask,
-							   plat->dma_filter,
-							   plat->dma_rx_param);
+	if (plat->dma_rx_param || do_rx) {
+		host->dma_rx_channel = dma_request_slave_channel_compat(mask,
+					(plat) ? plat->dma_filter : NULL,
+					(plat) ? plat->dma_rx_param : NULL,
+					&dev->dev, "rx");
 		/* E.g if no DMA hardware is present */
 		if (!host->dma_rx_channel)
 			dev_err(mmc_dev(host->mmc), "no RX DMA channel\n");
 	}
 
-	if (plat->dma_tx_param) {
-		host->dma_tx_channel = dma_request_channel(mask,
-							   plat->dma_filter,
-							   plat->dma_tx_param);
+	if (plat->dma_tx_param || do_tx) {
+		host->dma_tx_channel = dma_request_slave_channel_compat(mask,
+					(plat) ? plat->dma_filter : NULL,
+					(plat) ? plat->dma_tx_param : NULL,
+					&dev->dev, "tx");
 		if (!host->dma_tx_channel)
 			dev_warn(mmc_dev(host->mmc), "no TX DMA channel\n");
 	} else {
@@ -1538,7 +1557,7 @@ static int mmci_probe(struct amba_device *dev,
 		 amba_rev(dev), (unsigned long long)dev->res.start,
 		 dev->irq[0], dev->irq[1]);
 
-	mmci_dma_setup(host);
+	mmci_dma_setup(dev, host);
 
 	pm_runtime_set_autosuspend_delay(&dev->dev, 50);
 	pm_runtime_use_autosuspend(&dev->dev);
-- 
1.7.10.4



From robherring2 at gmail.com  Wed Apr 17 09:40:08 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Wed, 17 Apr 2013 08:40:08 -0500
Subject: [GIT PULL] Timer clean-ups for 3.10, Part 2
In-Reply-To: <516DEC68.8030101@codeaurora.org>
References: <516720B4.3000703@gmail.com> <516DEC68.8030101@codeaurora.org>
Message-ID: <516EA638.1060800@gmail.com>

On 04/16/2013 07:27 PM, Stephen Boyd wrote:
> On 04/11/13 13:44, Rob Herring wrote:
>>
>> Rob Herring (13):
>>       ARM: sched_clock: allow changing to higher frequency counter
>>       ARM: make sched_clock just call a function pointer
>>       ARM: arch_timer: use full 64-bit counter for sched_clock
> 
> If I leave my system in the bootloader for a while this seems to cause
> my sched_clock timestamps to jump once the sched_clock is setup. It also
> sets up a sched_clock twice because read_sched_clock ==
> jiffy_sched_clock_read.
> 
> [    0.000000] Switching to timer-based delay loop
> [    0.000000] sched_clock: ARM arch timer >56 bits at 19200kHz,
> resolution 52ns
> [    0.000000] sched_clock: 32 bits at 100 Hz, resolution 10000000ns,
> wraps every 4294967286ms
> [    0.000000] Console: colour dummy device 80x30
> [16645.193054] Calibrating delay loop (skipped), value calculated using
> timer frequency.. 38.40 BogoMIPS (lpj=192000)
> 
> I suspect it's because we don't do any cyc_to_sched_clock() stuff in the
> arm architected timer case. Instead we just return the value from the
> counter when we really should do some sort of subtraction from the first
> value we read.
>
> I'm also curious how this is going to work for suspend/resume because it
> doesn't look like we're going to stop sched_clock on arm architected
> timer systems. See 6a4dae5e138a3 (ARM: 7565/1: sched: stop sched_clock()
> during suspend, 2012-10-23) for why we need to do this.


Well, I think arm64 is broken in both ways too. So we should fix this
for both.

I think this can be handled in a much more simple way than the 32-bit
code since we don't need to deal with wrapping.

Maintain a cycle offset that starts as the cycle count at init time.
This offset can be subtracted from the current count. On suspend and
resume, we need to calculate the cycle count delta while in suspend and
then add this to the cycle offset.

> 
> Finally, looks like this is unused now...

Yes, but that's unrelated to anything I did.

Rob

> 
> ---8<----
> 
> diff --git a/arch/arm/kernel/sched_clock.c b/arch/arm/kernel/sched_clock.c
> index 8805848..48ab64a 100644
> --- a/arch/arm/kernel/sched_clock.c
> +++ b/arch/arm/kernel/sched_clock.c
> @@ -24,7 +24,6 @@ struct clock_data {
>         u32 mult;
>         u32 shift;
>         bool suspended;
> -       bool needs_suspend;
>  };
>  
>  static void sched_clock_poll(unsigned long wrap_ticks);
> 



From martinez.javier at gmail.com  Wed Apr 17 09:42:39 2013
From: martinez.javier at gmail.com (Javier Martinez Canillas)
Date: Wed, 17 Apr 2013 15:42:39 +0200
Subject: [PATCH 3/5] gpio/omap: Add DT support to GPIO driver
In-Reply-To: <516EA2B1.3070201@ti.com>
References: <1329321854-24490-1-git-send-email-b-cousson@ti.com>
 <CACRpkdYXVLgCz1Tyu-Ls2V2OTc4R3cGNJhfQJB6Hiz_K9dkZYQ@mail.gmail.com>
 <5155C902.7080207@wwwdotorg.org>
 <CACRpkdYbs4-uudpRUY8e+7icYYkZrfM0kReP3pLL5DMiURJ4dg@mail.gmail.com>
 <5165CB9D.1090202@wwwdotorg.org>
 <CACRpkdYirFNqmGhA4K9CL4ve4NYhs8Rd3SFt1iwW9vHBkrcz8g@mail.gmail.com>
 <51671D7B.5060303@wwwdotorg.org>
 <CACRpkdbf32Ef77GmXk9id9+RRjcDRTr7S+F4nznoeZU8y=BT_Q@mail.gmail.com>
 <51673D70.3010503@wwwdotorg.org>
 <CAAwP0s0e2x33jZQhFRY+Hoo61SFqYKRgWk=1mL2+DNxSDJHz+A@mail.gmail.com>
 <CACRpkda4h+qXTvsirPAS7E7sjXhMLE62q=VDy53W8UchsYjbNg@mail.gmail.com>
 <516C31C3.9040505@wwwdotorg.org> <516C7C43.3040105@wwwdotorg.org>
 <516C8760.2050500@ti.com> <516D9B05.1000501@wwwdotorg.org>
 <516DA60A.5070000@ti.com> <516DCCA8.3070108@wwwdotorg.org>
 <516DDB4D.9020500@ti.com>
 <CAAwP0s0-VNUoeSKaGbvoDeD7m7kZRdp5rCJ7iVpFoFAaQtXcmQ@mail.gmail.com>
 <516E022F.5050708@ti.com>
 <CAAwP0s2M2pnSydyDvh_rejFO=w8bCo4WE5PkxrYuk0HQDixc-Q@mail.gmail.com>
 <516EA2B1.3070201@ti.com>
Message-ID: <CAAwP0s2DsJAWuXWvPAkzCT0T0AG_OvMEw2sADW6LqSi1Ofd_Zw@mail.gmail.com>

On Wed, Apr 17, 2013 at 3:25 PM, Jon Hunter <jon-hunter at ti.com> wrote:
>
> On 04/17/2013 02:55 AM, Javier Martinez Canillas wrote:
>
> ...
>
>> There are so many patches flying around in this thread that I missed it :-)
>>
>> Sorry about that...
>
> No problem.
>
>>> I was trying to see if we could find a common solution that everyone
>>> could use as it seems that ideally we should all be requesting the gpio.
>>>
>>> Cheers
>>> Jon
>>>
>>> [1] http://marc.info/?l=linux-arm-kernel&m=136606204823845&w=1
>>
>> btw, I shared the latest patch with only build testing it, but today I
>> gave a try and I found a problem with this approach. The .xlate
>> function is being called twice for each GPIO-IRQ so the first time
>> gpio_request_one() succeeds but the second time it fails returning
>> -EBUSY.
>
> I tried it and I did not see that. I don't see the below warning either.
>

weird, I wonder what's different here.

I'll try tonight to test using another branch based on your
omap-daily-testing branch.

>> This raises a warning on drivers/of/platform.c
>> (WARN_ON(of_irq_to_resource_table(np, res, num_irq) != num_irq)):
>>
>>     0.285308] ------------[ cut here ]------------
>> [    0.285369] WARNING: at drivers/of/platform.c:171
>> of_device_alloc+0x154/0x168()
>> [    0.285430] Modules linked in:
>> [    0.285491] [<c001a944>] (unwind_backtrace+0x0/0xf0) from
>> [<c0041edc>] (warn_slowpath_common+0x4c/0x68)
>> [    0.285552] [<c0041edc>] (warn_slowpath_common+0x4c/0x68) from
>> [<c0041f14>] (warn_slowpath_null+0x1c/0x24)
>> [    0.285614] [<c0041f14>] (warn_slowpath_null+0x1c/0x24) from
>> [<c041ac3c>] (of_device_alloc+0x154/0x168)
>> [    0.285675] [<c041ac3c>] (of_device_alloc+0x154/0x168) from
>> [<c041ac84>] (of_platform_device_create_pdata+0x34/0x80)
>> [    0.285736] [<c041ac84>]
>> (of_platform_device_create_pdata+0x34/0x80) from [<c0027364>]
>> (gpmc_probe_generic_child+0x180/0x240)
>> [    0.285827] [<c0027364>] (gpmc_probe_generic_child+0x180/0x240)
>> from [<c00278d8>] (gpmc_probe+0x4b4/0x614)
>> [    0.285888] [<c00278d8>] (gpmc_probe+0x4b4/0x614) from [<c0325514>]
>> (platform_drv_probe+0x18/0x1c)
>> [    0.285949] [<c0325514>] (platform_drv_probe+0x18/0x1c) from
>> [<c0324354>] (driver_probe_device+0x108/0x21c)
>
> Any chance you have still have some additional code in your dts to
> request the gpio? I recall you made some hacks to make this work before.
>

Yes, but I remove all those hacks from my DT and gpmc driver. Is the
first thing I thought and I already doble checked that.

>> I probably won't have time to dig further on this until later this
>> week but I wanted to share with you in case you know why is being
>> calling twice and if you thought about a solution.
>
> Care to post your dts file?
>

I'm using the following patch to add smsc ethernet support to my board
+ adding 'ranges = <5 0 0x2c000000 0x1000000>;' to the gpmc device
node on omap3.dtsi:

>From 4fe26a40229e6e97c2ab3b80865c9f24e8ff3424 Mon Sep 17 00:00:00 2001
From: Javier Martinez Canillas <javier.martinez at collabora.co.uk>
Date: Wed, 27 Feb 2013 02:59:29 +0100
Subject: [PATCH 2/2] ARM: dts: omap3-igep0020: Add SMSC911x LAN chip support

The IGEPv2 board has an SMSC LAN9221i ethernet chip connected to
the OMAP3 processor though the General-Purpose Memory Controller.

This patch adds a device node for the ethernet chip as a GPMC child
and all its requirements (regulators, GPIO and pin muxs).

Signed-off-by: Javier Martinez Canillas <javier.martinez at collabora.co.uk>
---
 arch/arm/boot/dts/omap3-igep.dtsi    |    6 ++++
 arch/arm/boot/dts/omap3-igep0020.dts |   52 ++++++++++++++++++++++++++++++++++
 2 files changed, 58 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-igep.dtsi
b/arch/arm/boot/dts/omap3-igep.dtsi
index f8fe3b7..d5cd504 100644
--- a/arch/arm/boot/dts/omap3-igep.dtsi
+++ b/arch/arm/boot/dts/omap3-igep.dtsi
@@ -62,6 +62,12 @@
 			0x126 0x0100	/* sdmmc1_dat7.sdmmc1_dat7 INPUT | MODE 0 */
 		>;
 	};
+
+	smsc911x_pins: pinmux_smsc911x_pins {
+		pinctrl-single,pins = <
+                        0x1a2 0x0104    /* mcspi1_cs2.gpio_176 INPUT | MODE4 */
+		>;
+	};
 };

 &i2c1 {
diff --git a/arch/arm/boot/dts/omap3-igep0020.dts
b/arch/arm/boot/dts/omap3-igep0020.dts
index e2b9849..32a59df 100644
--- a/arch/arm/boot/dts/omap3-igep0020.dts
+++ b/arch/arm/boot/dts/omap3-igep0020.dts
@@ -40,6 +40,18 @@
 			gpios = <&twl_gpio 19 1>;
 		};
 	};
+
+	vddvario: regulator-vddvario {
+		  compatible = "regulator-fixed";
+		  regulator-name = "vddvario";
+		  regulator-always-on;
+	};
+
+	vdd33a: regulator-vdd33a {
+		compatible = "regulator-fixed";
+		regulator-name = "vdd33a";
+		regulator-always-on;
+	};
 };

 &i2c3 {
@@ -54,3 +66,43 @@
 		reg = <0x50>;
 	};
 };
+
+&gpmc {
+	ethernet at 5,0 {
+		pinctrl-names = "default";
+		pinctrl-0 = <&smsc911x_pins>;
+		compatible = "smsc,lan9221", "smsc,lan9115";
+		reg = <5 0 0xff>;
+		bank-width = <2>;
+
+		gpmc,mux-add-data;
+		gpmc,cs-on-ns = <0>;
+		gpmc,cs-rd-off-ns = <186>;
+		gpmc,cs-wr-off-ns = <186>;
+		gpmc,adv-on-ns = <12>;
+		gpmc,adv-rd-off-ns = <48>;
+		gpmc,adv-wr-off-ns = <48>;
+		gpmc,oe-on-ns = <54>;
+		gpmc,oe-off-ns = <168>;
+		gpmc,we-on-ns = <54>;
+		gpmc,we-off-ns = <168>;
+		gpmc,rd-cycle-ns = <186>;
+		gpmc,wr-cycle-ns = <186>;
+		gpmc,access-ns = <114>;
+		gpmc,page-burst-access-ns = <6>;
+		gpmc,bus-turnaround-ns = <12>;
+		gpmc,cycle2cycle-delay-ns = <18>;
+		gpmc,wr-data-mux-bus-ns = <90>;
+		gpmc,wr-access-ns = <186>;
+		gpmc,cycle2cycle-samecsen;
+		gpmc,cycle2cycle-diffcsen;
+
+		interrupt-parent = <&gpio6>;
+		interrupts = <16 8>;
+		vmmc-supply = <&vddvario>;
+		vmmc_aux-supply = <&vdd33a>;
+		reg-io-width = <4>;
+
+		smsc,save-mac-address;
+	};
+};
-- 
1.7.7.6

>> It works if I don't check the return gpio_request_one() (or better if
>> we don't return on omap_gpio_irq_domain_xlate) but of course is not
>> the right solution.
>
> Yes we need to check the return value.
>

I know, I was just pointing out that the fact that gpio_request_one()
was failing is what propagates the error to drivers/of/platform.c

> Cheers
> Jon

Thanks a lot and best regards,
Javier


From arnd at arndb.de  Wed Apr 17 09:50:55 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed, 17 Apr 2013 15:50:55 +0200
Subject: [PATCH] mmc: mmci: Allow MMCI to request channels with
 information acquired from DT
In-Reply-To: <1366205534-25079-1-git-send-email-lee.jones@linaro.org>
References: <1366205534-25079-1-git-send-email-lee.jones@linaro.org>
Message-ID: <201304171550.56037.arnd@arndb.de>

On Wednesday 17 April 2013, Lee Jones wrote:

>  #ifdef CONFIG_DMA_ENGINE
> -static void mmci_dma_setup(struct mmci_host *host)
> +static void mmci_dma_setup(struct amba_device *dev,
> +			   struct mmci_host *host)
>  {
> +	struct device_node *np = dev->dev.of_node;
>  	struct mmci_platform_data *plat = host->plat;
>  	const char *rxname, *txname;
>  	dma_cap_mask_t mask;
> +	const char *chan_name;
> +	int count, i;
> +	bool do_tx = false, do_rx = false;
>  
>  	if (!plat || !plat->dma_filter) {
> -		dev_info(mmc_dev(host->mmc), "no DMA platform data\n");
> -		return;
> +		if (np) {
> +			count = of_property_count_strings(np, "dma-names");
> +			for (i = 0; i < count; i++) {
> +				of_property_read_string_index(np, "dma-names",
> +							      i, &chan_name);
> +				if (strcmp(chan_name, "tx"))
> +					do_tx = true;
> +				else if (strcmp(chan_name, "rx"))
> +					do_rx = true;
> +			}
> +		} else {
> +			dev_info(mmc_dev(host->mmc), "no DMA platform data\n");
> +			return;
> +		}
>  	}

This looks unnecessarily complex.

>  	/* initialize pre request cookie */
> @@ -321,19 +338,21 @@ static void mmci_dma_setup(struct mmci_host *host)
>  	 * attempt to use it bidirectionally, however if it is
>  	 * is specified but cannot be located, DMA will be disabled.
>  	 */
> -	if (plat->dma_rx_param) {
> -		host->dma_rx_channel = dma_request_channel(mask,
> -							   plat->dma_filter,
> -							   plat->dma_rx_param);
> +	if (plat->dma_rx_param || do_rx) {
> +		host->dma_rx_channel = dma_request_slave_channel_compat(mask,
> +					(plat) ? plat->dma_filter : NULL,
> +					(plat) ? plat->dma_rx_param : NULL,
> +					&dev->dev, "rx");
>  		/* E.g if no DMA hardware is present */
>  		if (!host->dma_rx_channel)
>  			dev_err(mmc_dev(host->mmc), "no RX DMA channel\n");
>  	}

Why not just do dma_request_slave_channel_compat() unconditionally here?
It's not an error for MMCI if that fails. If you want to keep the warning
in the case dma_rx_channel is provided by not working, you can do it like

	host->dma_rx_channel = dma_request_slave_channel(dev, "rx");
	if (!host->dma_rx_channel && plat->dma_rx_param) {
		host->dma_rx_channel = dma_request_channel(mask,
							   plat->dma_filter,
							   plat->dma_rx_param);
		...
	}

	Arnd


From jon-hunter at ti.com  Wed Apr 17 09:52:55 2013
From: jon-hunter at ti.com (Jon Hunter)
Date: Wed, 17 Apr 2013 08:52:55 -0500
Subject: [PATCH 3/5] gpio/omap: Add DT support to GPIO driver
In-Reply-To: <CAAwP0s2DsJAWuXWvPAkzCT0T0AG_OvMEw2sADW6LqSi1Ofd_Zw@mail.gmail.com>
References: <1329321854-24490-1-git-send-email-b-cousson@ti.com>
 <CACRpkdYbs4-uudpRUY8e+7icYYkZrfM0kReP3pLL5DMiURJ4dg@mail.gmail.com>
 <5165CB9D.1090202@wwwdotorg.org>
 <CACRpkdYirFNqmGhA4K9CL4ve4NYhs8Rd3SFt1iwW9vHBkrcz8g@mail.gmail.com>
 <51671D7B.5060303@wwwdotorg.org>
 <CACRpkdbf32Ef77GmXk9id9+RRjcDRTr7S+F4nznoeZU8y=BT_Q@mail.gmail.com>
 <51673D70.3010503@wwwdotorg.org>
 <CAAwP0s0e2x33jZQhFRY+Hoo61SFqYKRgWk=1mL2+DNxSDJHz+A@mail.gmail.com>
 <CACRpkda4h+qXTvsirPAS7E7sjXhMLE62q=VDy53W8UchsYjbNg@mail.gmail.com>
 <516C31C3.9040505@wwwdotorg.org> <516C7C43.3040105@wwwdotorg.org>
 <516C8760.2050500@ti.com> <516D9B05.1000501@wwwdotorg.org>
 <516DA60A.5070000@ti.com> <516DCCA8.3070108@wwwdotorg.org>
 <516DDB4D.9020500@ti.com>
 <CAAwP0s0-VNUoeSKaGbvoDeD7m7kZRdp5rCJ7iVpFoFAaQtXcmQ@mail.gmail.com>
 <516E022F.5050708@ti.com>
 <CAAwP0s2M2pnSydyDvh_rejFO=w8bCo4WE5PkxrYuk0HQDixc-Q@mail.gmail.com>
 <516EA2B1.3070201@ti.com>
 <CAAwP0s2DsJAWuXWvPAkzCT0T0AG_OvMEw2sADW6LqSi1Ofd_Zw@mail.gmail.com>
Message-ID: <516EA937.8060201@ti.com>


On 04/17/2013 08:42 AM, Javier Martinez Canillas wrote:
> On Wed, Apr 17, 2013 at 3:25 PM, Jon Hunter <jon-hunter at ti.com> wrote:
>>
>> On 04/17/2013 02:55 AM, Javier Martinez Canillas wrote:
>>
>> ...
>>
>>> There are so many patches flying around in this thread that I missed it :-)
>>>
>>> Sorry about that...
>>
>> No problem.
>>
>>>> I was trying to see if we could find a common solution that everyone
>>>> could use as it seems that ideally we should all be requesting the gpio.
>>>>
>>>> Cheers
>>>> Jon
>>>>
>>>> [1] http://marc.info/?l=linux-arm-kernel&m=136606204823845&w=1
>>>
>>> btw, I shared the latest patch with only build testing it, but today I
>>> gave a try and I found a problem with this approach. The .xlate
>>> function is being called twice for each GPIO-IRQ so the first time
>>> gpio_request_one() succeeds but the second time it fails returning
>>> -EBUSY.
>>
>> I tried it and I did not see that. I don't see the below warning either.
>>
> 
> weird, I wonder what's different here.

I am testing on an omap4-sdp which uses a spi based ethernet device.
However, I could try with the omap3430-sdp which uses gpmc.

Cheers
Jon


From lee.jones at linaro.org  Wed Apr 17 10:02:10 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Wed, 17 Apr 2013 15:02:10 +0100
Subject: [PATCH] dw_dmac: Couple of small fixups;
 use of '_' over '-' and a cell-num typo
Message-ID: <1366207330-1727-1-git-send-email-lee.jones@linaro.org>

In Device Tree '-' is always preferred over '_'. This is corrected in
code as well as in the documentation. Also, there are one too many
populated cells in the dmas example. Let's remove one of them to aid
with clarity.

Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 Documentation/devicetree/bindings/dma/snps-dma.txt |    4 ++--
 drivers/dma/dw_dmac.c                              |    2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/dma/snps-dma.txt b/Documentation/devicetree/bindings/dma/snps-dma.txt
index d58675e..aaccb9d 100644
--- a/Documentation/devicetree/bindings/dma/snps-dma.txt
+++ b/Documentation/devicetree/bindings/dma/snps-dma.txt
@@ -20,7 +20,7 @@ Required properties:
 Optional properties:
 - interrupt-parent: Should be the phandle for the interrupt controller
   that services interrupts for this device
-- is_private: The device channels should be marked as private and not for by the
+- is-private: The device channels should be marked as private and not for by the
   general purpose DMA channel allocator. False if not passed.
 
 Example:
@@ -58,6 +58,6 @@ Example:
 		interrupts = <0 35 0x4>;
 		status = "disabled";
 		dmas = <&dmahost 12 0 1>,
-			<&dmahost 13 0 1 0>;
+			<&dmahost 13 0 1>;
 		dma-names = "rx", "rx";
 	};
diff --git a/drivers/dma/dw_dmac.c b/drivers/dma/dw_dmac.c
index c599558..3448819 100644
--- a/drivers/dma/dw_dmac.c
+++ b/drivers/dma/dw_dmac.c
@@ -1592,7 +1592,7 @@ dw_dma_parse_dt(struct platform_device *pdev)
 	if (of_property_read_u32(np, "dma-channels", &pdata->nr_channels))
 		return NULL;
 
-	if (of_property_read_bool(np, "is_private"))
+	if (of_property_read_bool(np, "is-private"))
 		pdata->is_private = true;
 
 	if (!of_property_read_u32(np, "chan_allocation_order", &tmp))
-- 
1.7.10.4



From jason at lakedaemon.net  Wed Apr 17 10:08:17 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Wed, 17 Apr 2013 10:08:17 -0400
Subject: [PATCHv8 07/19] arm: pci: add a align_resource hook
In-Reply-To: <20130415163609.GJ28693@titan.lakedaemon.net>
References: <1365541601-14095-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1365541601-14095-8-git-send-email-thomas.petazzoni@free-electrons.com>
 <20130415163609.GJ28693@titan.lakedaemon.net>
Message-ID: <20130417140817.GE28693@titan.lakedaemon.net>

Russell,

I saw you were back online this morning, could you please consider the
following request?

On Mon, Apr 15, 2013 at 12:36:09PM -0400, Jason Cooper wrote:
> Russell,
> 
> Thanks for applying this patch (7683/1) to your tree.  I see it's in
> your for-next, which I understand *isn't* stable.
> 
>   029baf1 ARM: 7683/1: pci: add a align_resource hook
> 
> Is there a stable branch I could depend on for the rest of this series
> (particularly, patch 10)?  It looks like you applied it to your misc
> branch, but that's not currently available.

I'd really like to get this in for v3.10.  As Thomas has mentioned
before, the series has had plenty of review on the list.

thx,

Jason.

> On Tue, Apr 09, 2013 at 11:06:28PM +0200, Thomas Petazzoni wrote:
> > The PCI specifications says that an I/O region must be aligned on a 4
> > KB boundary, and a memory region aligned on a 1 MB boundary.
> > 
> > However, the Marvell PCIe interfaces rely on address decoding windows
> > (which allow to associate a range of physical addresses with a given
> > device). For PCIe memory windows, those windows are defined with a 1
> > MB granularity (which matches the PCI specs), but PCIe I/O windows can
> > only be defined with a 64 KB granularity, so they have to be 64 KB
> > aligned. We therefore need to tell the PCI core about this special
> > alignement requirement.
> > 
> > The PCI core already calls pcibios_align_resource() in the ARM PCI
> > core, specifically for such purposes. So this patch extends the ARM
> > PCI core so that it calls a ->align_resource() hook registered by the
> > PCI driver, exactly like the existing ->map_irq() and ->swizzle()
> > hooks.
> > 
> > A particular PCI driver can register a align_resource() hook, and do
> > its own specific alignement, depending on the specific constraints of
> > the underlying hardware.
> > 
> > Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> > Cc: Russell King <linux at arm.linux.org.uk>
> > ---
> >  arch/arm/include/asm/mach/pci.h |   11 +++++++++++
> >  arch/arm/kernel/bios32.c        |    6 ++++++
> >  2 files changed, 17 insertions(+)
> > 
> > diff --git a/arch/arm/include/asm/mach/pci.h b/arch/arm/include/asm/mach/pci.h
> > index 5cf2e97..7d2c3c8 100644
> > --- a/arch/arm/include/asm/mach/pci.h
> > +++ b/arch/arm/include/asm/mach/pci.h
> > @@ -30,6 +30,11 @@ struct hw_pci {
> >  	void		(*postinit)(void);
> >  	u8		(*swizzle)(struct pci_dev *dev, u8 *pin);
> >  	int		(*map_irq)(const struct pci_dev *dev, u8 slot, u8 pin);
> > +	resource_size_t (*align_resource)(struct pci_dev *dev,
> > +					  const struct resource *res,
> > +					  resource_size_t start,
> > +					  resource_size_t size,
> > +					  resource_size_t align);
> >  };
> >  
> >  /*
> > @@ -51,6 +56,12 @@ struct pci_sys_data {
> >  	u8		(*swizzle)(struct pci_dev *, u8 *);
> >  					/* IRQ mapping				*/
> >  	int		(*map_irq)(const struct pci_dev *, u8, u8);
> > +					/* Resource alignement requirements	*/
> > +	resource_size_t (*align_resource)(struct pci_dev *dev,
> > +					  const struct resource *res,
> > +					  resource_size_t start,
> > +					  resource_size_t size,
> > +					  resource_size_t align);
> >  	void		*private_data;	/* platform controller private data	*/
> >  };
> >  
> > diff --git a/arch/arm/kernel/bios32.c b/arch/arm/kernel/bios32.c
> > index a1f73b5..b2ed73c 100644
> > --- a/arch/arm/kernel/bios32.c
> > +++ b/arch/arm/kernel/bios32.c
> > @@ -462,6 +462,7 @@ static void pcibios_init_hw(struct hw_pci *hw, struct list_head *head)
> >  		sys->busnr   = busnr;
> >  		sys->swizzle = hw->swizzle;
> >  		sys->map_irq = hw->map_irq;
> > +		sys->align_resource = hw->align_resource;
> >  		INIT_LIST_HEAD(&sys->resources);
> >  
> >  		if (hw->private_data)
> > @@ -574,6 +575,8 @@ char * __init pcibios_setup(char *str)
> >  resource_size_t pcibios_align_resource(void *data, const struct resource *res,
> >  				resource_size_t size, resource_size_t align)
> >  {
> > +	struct pci_dev *dev = data;
> > +	struct pci_sys_data *sys = dev->sysdata;
> >  	resource_size_t start = res->start;
> >  
> >  	if (res->flags & IORESOURCE_IO && start & 0x300)
> > @@ -581,6 +584,9 @@ resource_size_t pcibios_align_resource(void *data, const struct resource *res,
> >  
> >  	start = (start + align - 1) & ~(align - 1);
> >  
> > +	if (sys->align_resource)
> > +		return sys->align_resource(dev, res, start, size, align);
> > +
> >  	return start;
> >  }
> >  
> > -- 
> > 1.7.9.5
> > 
> > 
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From broonie at kernel.org  Wed Apr 17 10:12:03 2013
From: broonie at kernel.org (Mark Brown)
Date: Wed, 17 Apr 2013 15:12:03 +0100
Subject: [PATCH v3 00/15] ASoC: fsl-ssi: ac97-slave support
In-Reply-To: <1365939779-4507-1-git-send-email-mpa@pengutronix.de>
References: <1365939779-4507-1-git-send-email-mpa@pengutronix.de>
Message-ID: <20130417141202.GT13687@opensource.wolfsonmicro.com>

On Sun, Apr 14, 2013 at 01:42:44PM +0200, Markus Pargmann wrote:

> This series adds DT support for phycore-ac97. It is now based on the pcm dma
> cleanups from Lars. Beside ac97 support, the series adds fsl-ssi imx-pcm-fiq
> and generic DMA binding handling.

I've now merged the core and i.MX bits of that into topic/dma so if you
could check what actually went in and then respin?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130417/a1b6da93/attachment.sig>

From shawn.guo at linaro.org  Wed Apr 17 10:13:47 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Wed, 17 Apr 2013 22:13:47 +0800
Subject: [PATCH v2] ARM i.MX6q: Fix periph_clk2_sel and periph2_clk2_sel
 clocks
In-Reply-To: <1366193158-10098-1-git-send-email-p.zabel@pengutronix.de>
References: <1366193158-10098-1-git-send-email-p.zabel@pengutronix.de>
Message-ID: <20130417141346.GB20563@S2101-09.ap.freescale.net>

On Wed, Apr 17, 2013 at 12:05:58PM +0200, Philipp Zabel wrote:
> The periph_clk2_sel mux can be set to pll3, osc/pll1_ref_clk, or osc/
> pll2_burn_in_clk. The periph2_clk2_sel mux can be set to pll3 or pll2.
> 
> Signed-off-by: Philipp Zabel <p.zabel at pengutronix.de>

Applied, thanks.



From nsekhar at ti.com  Wed Apr 17 10:15:40 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Wed, 17 Apr 2013 19:45:40 +0530
Subject: [GIT PULL 2/3] ARM: davinci: SoC updates for v3.10 (part 2)
In-Reply-To: <20130416164838.GE4918@quad.lixom.net>
References: <1366046599-6590-1-git-send-email-nsekhar@ti.com>
 <1366046599-6590-2-git-send-email-nsekhar@ti.com>
 <20130415201835.GA24600@quad.lixom.net> <516CEBCF.60507@ti.com>
 <20130416164838.GE4918@quad.lixom.net>
Message-ID: <516EAE8C.1070204@ti.com>


On 4/16/2013 10:18 PM, Olof Johansson wrote:
> On Tue, Apr 16, 2013 at 11:42:31AM +0530, Sekhar Nori wrote:
>> On 4/16/2013 1:48 AM, Olof Johansson wrote:
>>> On Mon, Apr 15, 2013 at 10:53:18PM +0530, Sekhar Nori wrote:
>>>> Hi Arnd, Olof,
>>>>
>>>> Can you please the following SoC updates for DaVinci.
>>>> The branch depends on (and merges) an immutable branch
>>>> from Ohad adding DA8XX rempote proc driver.
>>>
>>> Hi,
>>>
>>> Where is this branch from? Git URL and branch name, please -- we prefer to pull
>>> these in as separate branches under depends/* as well to document it.
>>
>> Here is the repo and branch:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/ohad/remoteproc.git for-next
> 
> Oh! Looking at that branch, and the new branch from you, I don't actually see
> a dependency between them. Sure, the Davinci mach-side code registers a new
> device, but until the driver has the corresponding changes, there's no breakage
> caused by the new registration. There are no new data structures introduced
> either, so there's no build-time dependency added.

That's right! I can swear there was some platform data that the driver
needed at some stage which caused the dependency. Whatever that was, its
gone now (and I failed to notice it) so there is no real need of merging
the remoteproc branch.

> So it would be just as easy to just merge this as a nondependent branch. When
> both sides of the change land, remoteproc will work. But until then, nothing
> existing will be broken.
> 
> Sound ok? If so, please just rebase your 4 patches on top of the old SoC branch
> without the dependency and send a fresh pull request, please. :)

Okay, I will rebase and send updated pull request. I will have to update
the board support pull request too.

Thanks,
Sekhar


From martinez.javier at gmail.com  Wed Apr 17 10:21:58 2013
From: martinez.javier at gmail.com (Javier Martinez Canillas)
Date: Wed, 17 Apr 2013 16:21:58 +0200
Subject: [PATCH 3/5] gpio/omap: Add DT support to GPIO driver
In-Reply-To: <516EA937.8060201@ti.com>
References: <1329321854-24490-1-git-send-email-b-cousson@ti.com>
 <CACRpkdYbs4-uudpRUY8e+7icYYkZrfM0kReP3pLL5DMiURJ4dg@mail.gmail.com>
 <5165CB9D.1090202@wwwdotorg.org>
 <CACRpkdYirFNqmGhA4K9CL4ve4NYhs8Rd3SFt1iwW9vHBkrcz8g@mail.gmail.com>
 <51671D7B.5060303@wwwdotorg.org>
 <CACRpkdbf32Ef77GmXk9id9+RRjcDRTr7S+F4nznoeZU8y=BT_Q@mail.gmail.com>
 <51673D70.3010503@wwwdotorg.org>
 <CAAwP0s0e2x33jZQhFRY+Hoo61SFqYKRgWk=1mL2+DNxSDJHz+A@mail.gmail.com>
 <CACRpkda4h+qXTvsirPAS7E7sjXhMLE62q=VDy53W8UchsYjbNg@mail.gmail.com>
 <516C31C3.9040505@wwwdotorg.org> <516C7C43.3040105@wwwdotorg.org>
 <516C8760.2050500@ti.com> <516D9B05.1000501@wwwdotorg.org>
 <516DA60A.5070000@ti.com> <516DCCA8.3070108@wwwdotorg.org>
 <516DDB4D.9020500@ti.com>
 <CAAwP0s0-VNUoeSKaGbvoDeD7m7kZRdp5rCJ7iVpFoFAaQtXcmQ@mail.gmail.com>
 <516E022F.5050708@ti.com>
 <CAAwP0s2M2pnSydyDvh_rejFO=w8bCo4WE5PkxrYuk0HQDixc-Q@mail.gmail.com>
 <516EA2B1.3070201@ti.com>
 <CAAwP0s2DsJAWuXWvPAkzCT0T0AG_OvMEw2sADW6LqSi1Ofd_Zw@mail.gmail.com>
 <516EA937.8060201@ti.com>
Message-ID: <CAAwP0s2xDCxvbXbyQ7td5axqBfV0xFEX2a-CNSw0NONG3b0XRg@mail.gmail.com>

On Wed, Apr 17, 2013 at 3:52 PM, Jon Hunter <jon-hunter at ti.com> wrote:
>
> On 04/17/2013 08:42 AM, Javier Martinez Canillas wrote:
>> On Wed, Apr 17, 2013 at 3:25 PM, Jon Hunter <jon-hunter at ti.com> wrote:
>>>
>>> On 04/17/2013 02:55 AM, Javier Martinez Canillas wrote:
>>>
>>> ...
>>>
>>>> There are so many patches flying around in this thread that I missed it :-)
>>>>
>>>> Sorry about that...
>>>
>>> No problem.
>>>
>>>>> I was trying to see if we could find a common solution that everyone
>>>>> could use as it seems that ideally we should all be requesting the gpio.
>>>>>
>>>>> Cheers
>>>>> Jon
>>>>>
>>>>> [1] http://marc.info/?l=linux-arm-kernel&m=136606204823845&w=1
>>>>
>>>> btw, I shared the latest patch with only build testing it, but today I
>>>> gave a try and I found a problem with this approach. The .xlate
>>>> function is being called twice for each GPIO-IRQ so the first time
>>>> gpio_request_one() succeeds but the second time it fails returning
>>>> -EBUSY.
>>>
>>> I tried it and I did not see that. I don't see the below warning either.
>>>
>>
>> weird, I wonder what's different here.
>
> I am testing on an omap4-sdp which uses a spi based ethernet device.
> However, I could try with the omap3430-sdp which uses gpmc.
>

Thanks, that would be great and it could be a difference.

But don't worry I'll to test it more extensively when I have some free
time. I just shared here in case you had the same issue.

> Cheers
> Jon

Thanks a lot for your help,
Jaiver


From laurent.meunier at st.com  Wed Apr 17 10:33:27 2013
From: laurent.meunier at st.com (Laurent MEUNIER)
Date: Wed, 17 Apr 2013 16:33:27 +0200
Subject: [PATCH v2] pinctrl/pinconfig: add debug interface
In-Reply-To: <515DEC92.9010602@wwwdotorg.org>
References: <1365018447-28062-1-git-send-email-linus.walleij@stericsson.com>
 <515DEC92.9010602@wwwdotorg.org>
Message-ID: <516EB2B7.30607@st.com>

On 04/04/2013 11:11 PM, Stephen Warren wrote:
> On 04/03/2013 01:47 PM, Linus Walleij wrote:
>> From: Laurent Meunier <laurent.meunier at st.com>
>>
>> This update adds a debugfs interface to modify a pin configuration
>> for a given state in the pinctrl map. This allows to modify the
>> configuration for a non-active state, typically sleep state.
>> This configuration is not applied right away, but only when the state
>> will be entered.
>>
>> This solution is mandated for us by HW validation: in order
>> to test and verify several pin configurations during sleep without
>> recompiling the software.
>>
>> diff --git a/drivers/pinctrl/pinconf.c b/drivers/pinctrl/pinconf.c
>> +enum pinconf_dbg_request_type {
>> +	PINCONF_DBG_REQ_TYPE_INVALID,
>> +	PINCONF_DBG_REQ_TYPE_MODIFY,
>> +};
> I'm not sure why that really needs an enum yet, since only one operation
> is supported.
I agree the enum does not bring a lot of added value, for now.
It is there following one earlier comment that the debugfs
could be later extended to support ADD / DELETE. This is
a preparation step to this, so I've kept it in in my V3.
Hope this is fine.

>> +struct dbg_cfg {
>> +	enum pinconf_dbg_request_type req_type;
>> +	enum pinctrl_map_type map_type;
>> +	char dev_name[MAX_NAME_LEN+1];
>> +	char state_name[MAX_NAME_LEN+1];
>> +	char pin_name[MAX_NAME_LEN+1];
>> +	char config[MAX_NAME_LEN+1];
>> +};
> Many of those fields are only used internally to
> pinconf_dbg_config_write(). Can't they be stored on the stack there
> rather than globally.
I'd like to get the context as a global to share it between _print()
and _write() functions. I find it quite useful in practice
basically when using the debugfs, after the write request,
you can simply cat pinconf-config and check the status of
what you've last written to. This is the rationale at least.

>> +/**
>> + * pinconf_dbg_config_print() - display the pinctrl config from the pinctrl
>> + * map, of a pin/state pair based on pinname and state that have been
>> + * selected with the debugfs entries pinconf-name and pinconf-state
>> + * @s: contains the 32bits config to be written
>> + * @d: not used
>> + */
> This comment seems stale; I don't believe there are any pinconf-name and
> pinconf-state files; aren't they part of the data written to the one
> debugfs file each time?
Right. Comment definitely needs update.
>
>> +static int pinconf_dbg_config_print(struct seq_file *s, void *d)
>> +		if (strncmp(map->dev_name, dbg->dev_name, MAX_NAME_LEN) != 0)
> Wouldn't it be simpler to always ensure dbg->dev_name was
> NULL-terminated, and just use !strcmp() here? Same for dbg->state_name
> below. Same comment for the other function below.
Yes that looks better.
>> +	mutex_unlock(&pinctrl_mutex);
> Don't you need the lock held to call confops->xxx() below, to make sure
> that the driver isn't unregistered between finding it, and calling the
> confops function?
Right as well.
>
>> +	if (!found) {
>> +		seq_printf(s, "No config found for dev/state/pin, expected:\n");
>> +		seq_printf(s, "modify config_pins devname " \
>> +			   "state pinname value\n");
>> +	}
> Hmmm. At least including the parsed values that were being searched for
> might be useful?
Right as well.
>
>> +		confops->pin_config_config_dbg_show(pctldev,
>> +						    s, config);
> I think that function name is wrong; two "config_" in a row. Does this
> compile?
Yes it compiles. The pinconf_ops contains an operation named
  like this (pin_config_config_dbg_show) and I think this is the one we 
need here.
>
>> +/**
>> + * pinconf_dbg_config_write() - overwrite the pinctrl config in the pinctrl
>> + * map, of a pin/state pair based on pinname and state that have been
>> + * selected with the debugfs entries pinconf-name and pinconf-state
> Similar stale comment.
Yes, right.
>
>> + * @user_buf: contains 'modify configs_pin devicename state pinname newvalue'
> It might be useful to say which parts of that are literal strings and
> which are variables/values to be changed?
Yes also part of update needed in the comment
>
>> +static int pinconf_dbg_config_write(struct file *file,
>> +	const char __user *user_buf, size_t count, loff_t *ppos)
>> +	/* Get arg: 'modify' */
>> +	if (!strncmp(b, "modify ", strlen("modify "))) {
>> +		dbg->req_type = PINCONF_DBG_REQ_TYPE_MODIFY;
>> +		b += strlen("modify ");
>> +	} else {
>> +		return -EINVAL;
>> +	}
> There's rather a lot of duplication of strings and strlen calls there.
> Why not:
>
> a) Start using strsep() for the very first fields too, so everything is
> consistent.
>
> b) Put the error-path first.
>
> In other words:
>
> 	token = strsep(&b, " ");
> 	if (!token)
> 		return -EINVAL;
> 	if (!strcmp(token, "modify"))
> 		return -EINVAL;
Thanks for the proposal, code looks indeed better like this
>> +	/* Get arg type: "config_pin" type supported so far */
>> +	if (!strncmp(b, "config_pins ", strlen("config_pins "))) {
>> +		dbg->map_type = PIN_MAP_TYPE_CONFIGS_PIN;
>> +		b += strlen("config_pins ");
>> +	} else {
>> +		return -EINVAL;
>> +	}
> That could be transformed the same way.
>
>> +	/* get arg 'device_name' */
>> +	token = strsep(&b, " ");
>> +	if (token == NULL)
>> +		return -EINVAL;
>> +	if (strlen(token) < MAX_NAME_LEN)
>> +		sscanf(token, "%s", dbg->dev_name);
>> +	else
>> +		return -EINVAL;
> It might make sense to put the error-handling first, and why sscanf not
> strcpy? So:
>
> 	token = strsep(&b, " ");
> 	if (token == NULL)
> 		return -EINVAL;
> 	if (strlen(token) >= MAX_NAME_LEN)
> 		return -EINVAL;
> 	strcpy(dbg->dev_name, token);
>
> (or even just use strncpy followed by explicit NULL termination and
> truncate text that's too long, or kstrdup() it to avoid limits?)
Same here. Looks better
>
>> +	if (confops && confops->pin_config_dbg_parse) {
>> +		for (i = 0; i < configs->num_configs; i++) {
>> +			confops->pin_config_dbg_parse(pctldev,
>> +						    dbg->config,
>> +						    &configs->configs[i]);
> I assume that "parse" function is intended to actually write the new
> result into configs->configs[i]. That's more than parsing.
> s/dbg_parse/dbg_modify/ perhaps to make this more explicit, and also
> mention this in the kerneldoc for the confops structure in the header?
I ended up with ->pin_config_dbg_parse_modify(). Hope this is ok.
Linus will post a V3 version including above needed updates.

From broonie at kernel.org  Wed Apr 17 10:46:37 2013
From: broonie at kernel.org (Mark Brown)
Date: Wed, 17 Apr 2013 15:46:37 +0100
Subject: [PATCH v2] spi: s3c64xx: move to generic dmaengine API
In-Reply-To: <201304112242.03252.arnd@arndb.de>
References: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
 <1365638712-1028578-30-git-send-email-arnd@arndb.de>
 <20130411165536.GO9243@opensource.wolfsonmicro.com>
 <201304112242.03252.arnd@arndb.de>
Message-ID: <20130417144637.GW13687@opensource.wolfsonmicro.com>

On Thu, Apr 11, 2013 at 10:42:03PM +0200, Arnd Bergmann wrote:
> The spi-s3c64xx uses a Samsung proprietary interface for
> talking to the DMA engine, which does not work with
> multiplatform kernels.

Actually it seems that this patch is causing issues for bulk SPI
transfers on s3c64xx, especially when they're driven quickly one after
another.  I've only just found the problem so I've not been able to
debug yet but a revert fixes it...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130417/c9f3d942/attachment.sig>

From lee.jones at linaro.org  Wed Apr 17 11:04:37 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Wed, 17 Apr 2013 16:04:37 +0100
Subject: [PATCH] mmc: mmci: Allow MMCI to request channels with
 information acquired from DT
In-Reply-To: <201304171550.56037.arnd@arndb.de>
References: <1366205534-25079-1-git-send-email-lee.jones@linaro.org>
 <201304171550.56037.arnd@arndb.de>
Message-ID: <20130417150437.GA3137@gmail.com>

> This looks unnecessarily complex.

That thought did cross my mind.

> Why not just do dma_request_slave_channel_compat() unconditionally here?

So how about something like this instead, as it keeps the current
semantics, and only differs in the case of DT.

diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index 372e921..1fd212a 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -298,14 +298,16 @@ static void mmci_init_sg(struct mmci_host *host, struct mmc_data *data)
  * no custom DMA interfaces are supported.
  */
 #ifdef CONFIG_DMA_ENGINE
-static void mmci_dma_setup(struct mmci_host *host)
+static void mmci_dma_setup(struct amba_device *dev,
+			   struct mmci_host *host)
 {
+	struct device_node *np = dev->dev.of_node;
 	struct mmci_platform_data *plat = host->plat;
 	const char *rxname, *txname;
 	dma_cap_mask_t mask;
 
-	if (!plat || !plat->dma_filter) {
-		dev_info(mmc_dev(host->mmc), "no DMA platform data\n");
+	if (!(plat && plat->dma_filter) && !np) {
+		dev_info(mmc_dev(host->mmc), "no DMA platform data or DT\n");
 		return;
 	}
 
@@ -321,19 +323,21 @@ static void mmci_dma_setup(struct mmci_host *host)
 	 * attempt to use it bidirectionally, however if it is
 	 * is specified but cannot be located, DMA will be disabled.
 	 */
-	if (plat->dma_rx_param) {
-		host->dma_rx_channel = dma_request_channel(mask,
-							   plat->dma_filter,
-							   plat->dma_rx_param);
+	if ((plat && plat->dma_rx_param) || np) {
+		host->dma_rx_channel = dma_request_slave_channel_compat(mask,
+					(plat) ? plat->dma_filter : NULL,
+					(plat) ? plat->dma_rx_param : NULL,
+					&dev->dev, "rx");
 		/* E.g if no DMA hardware is present */
 		if (!host->dma_rx_channel)
 			dev_err(mmc_dev(host->mmc), "no RX DMA channel\n");
 	}
 
-	if (plat->dma_tx_param) {
-		host->dma_tx_channel = dma_request_channel(mask,
-							   plat->dma_filter,
-							   plat->dma_tx_param);
+	if ((plat && plat->dma_tx_param) || np) {
+		host->dma_tx_channel = dma_request_slave_channel_compat(mask,
+					(plat) ? plat->dma_filter : NULL,
+					(plat) ? plat->dma_tx_param : NULL,
+					&dev->dev, "tx");
 		if (!host->dma_tx_channel)
 			dev_warn(mmc_dev(host->mmc), "no TX DMA channel\n");
 	} else {
@@ -1538,7 +1542,7 @@ static int mmci_probe(struct amba_device *dev,
 		 amba_rev(dev), (unsigned long long)dev->res.start,
 		 dev->irq[0], dev->irq[1]);
 
-	mmci_dma_setup(host);
+	mmci_dma_setup(dev, host);
 
 	pm_runtime_set_autosuspend_delay(&dev->dev, 50);
 	pm_runtime_use_autosuspend(&dev->dev);

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From swarren at wwwdotorg.org  Wed Apr 17 11:14:46 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Wed, 17 Apr 2013 09:14:46 -0600
Subject: [RFC PATCH 2/2] ARM: DT: kernel: DT cpu node bindings update
In-Reply-To: <20130417091457.GB5012@e106331-lin.cambridge.arm.com>
References: <1366042402-8987-1-git-send-email-lorenzo.pieralisi@arm.com>
 <1366042402-8987-3-git-send-email-lorenzo.pieralisi@arm.com>
 <516C544A.4090107@wwwdotorg.org>
 <20130417091457.GB5012@e106331-lin.cambridge.arm.com>
Message-ID: <516EBC66.20508@wwwdotorg.org>

On 04/17/2013 03:14 AM, Mark Rutland wrote:
> Hi Stephen,
> 
>>> +	- enable-method
>>> +		Usage: required on ARM 64-bit systems, optional on ARM 32-bit
>>> +		       systems
>>> +		Value type: <string>
>>> +		Definition: On ARM 64-bit systems must be "spin-table" [1].
>>
>> Can that be an integer instead? with dtc+cpp support, that shouldn't
>> hurt the eyes too much any more.
> 
> The "enable-method" property is described as a stringlist by ePAPR, and is
> currently in use on arm64 as such. It *must* remain a string(list) for arm64.
> 
> Having it as an integer for arm is only going to cause us additional work,
> makes it impossible to share a common dt between 64bit and 32bit, and goes
> against the standard. I think it should be a stringlist for arm.

OK, that's a great reason for this case.

I hope we don't introduce any more standards that use strings, but that
may just be my personal preference...


From maxime.ripard at free-electrons.com  Wed Apr 17 11:15:48 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Wed, 17 Apr 2013 17:15:48 +0200
Subject: MXS framebuffer driver and 18bits display
Message-ID: <516EBCA4.1020609@free-electrons.com>

Hi,

We noticed a strange bug with the 18 bits display found in the
iMX28 CFA-10049, but it should not be specific to it.

Like I said, we have a small 18-bits LCD panel. When further testing
it, it displayed horrible colors with standard jpg images used together
with tools such as fbv, applications written in Qt, etc.

Digging a bit into it, it looks like the mxsfb driver accepts devices
with 18bits interfaces.

However, in such case, the driver registers as a 32bits framebuffer
device, sets up the controller as a 24 bits display, and is actually
asking the controller to drop the 2 upper bits of each color by setting
the DATA_FORMAT_24_BIT bit in the HW_LCDIF_CTRL register.

So basically, applications feed to the framebuffer something like:

+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| R7| R6| R5| R4| R3| R2| R1| R0| G7| G6| G5| G4| G3| G2| G1| G0| B7| B6| B5| B4| B3| B2| B1| B0|
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

And what is being sent to the LCD is:

+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| R5| R4| R3| R2| R1| R0| G5| G4| G3| G2| G1| G0| B5| B4| B3| B2| B1| B0|
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

And thus, results in colors being horrible because the MSB are dropped.

What I believe the controller should send in theory should be :

+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| R7| R6| R5| R4| R3| R2| G7| G6| G5| G4| G3| G2| B7| B6| B5| B4| B3| B2|
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

Thus dropping the 2 LSB for each color. However, it doesn't seem that
the controller can be setup that way.

We thought of several solutions for this:
  - Switching to "real" 18 bits color depth
    * It is definitely not a good solution, since it requires the
      applications to handle the 18 bits color depth case, which only a
      few of them do.
  - Using the SHIFT_NUM_BITS bits in the HW_LCDIF_CTRL register
    * It doesn't look like a good solution either, since it seems to be
      shifting the whole 24 bits, and not each color independently, so
      the result will only be worse.
  - Use a 16 bits color depth
    * It doesn't seem possible either, since the 16 bits will be packed
      on two bytes, while the controller expects the 18 bits not to be
      packed.

Do you see a solution for this?

Thanks,
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


From pawel.moll at arm.com  Wed Apr 17 11:17:12 2013
From: pawel.moll at arm.com (Pawel Moll)
Date: Wed, 17 Apr 2013 16:17:12 +0100
Subject: [RFC 00/10] Versatile Express CLCD DVI output support
Message-ID: <1366211842-21497-1-git-send-email-pawel.moll@arm.com>

Hello All,

This series implements support for the Versatile Express
video output pipeline, which is not the simplest one available...

It is meant as a RFC only and I'm hoping to attract all possible
feedback (*including* naming ;-).

The VE's "MultiMedia Bus" [1] comprises three video signal sources
(motherboard's CLCD cell and a implementation-specific driver
on each of the daugtherboards) and a FPGA multiplexer routing
data from one of the sources to DVI/HDMI formatter chip (Sii9022).

+-----+
| DB1 |>--+                         DVI connector
+-----+   |   +------+                   +--+
          +-->|      |                   |oo|
+-----+       | mux  |    +---------+    |oo|
| DB2 |>----->|      |>-->| sii9022 |>-->|oo|
+-----+       | FPGA |    +---------+    |oo|
          +-->|      |                   |oo|
+-----+   |   +------+                   +--+
| MB  |>--+
+-----+

The series is based on Laurent Pinchart's Common Display Framework
patch (not in mainline yet, v2 discussed here: [2]) and extends it
by adding DT bindings and basic support for TFT panels.

The CLCD driver has been adapted to work with the framework and
the Device Tree information.

Also a set of drivers for the VE-specific components is included
(note that the sii9022 is now driven via the moterboard firmware;
this is intended to be replaced by a proper I2C driver for the
chip).

It is worth mentioning that the CDF caters for both fbdev and DRM
so the solution should be suitable for all potential DRM-driven
display controllers.

[1] http://infocenter.arm.com/help/topic/com.arm.doc.dui0447h/CHDEHEAA.html#CACGIGGC
[2] http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/57298


Laurent Pinchart (1):
  video: Add generic display entity core

Pawel Moll (9):
  video: display: Update the display with the video mode data
  video: display: Add Device Tree bindings
  video: display: Add generic TFT display type
  fbmon: Add extra video helper
  video: ARM CLCD: Add DT & CDF support
  mfd: vexpress: Allow external drivers to parse site ids
  video: Versatile Express MUXFPGA driver
  video: Versatile Express DVI mode driver
  ARM: vexpress: Add CLCD Device Tree properties

 .../testing/sysfs-driver-video-vexpress-muxfpga    |    5 +
 .../devicetree/bindings/video/arm,pl11x.txt        |   35 ++
 .../devicetree/bindings/video/display-bindings.txt |   75 ++++
 arch/arm/boot/dts/vexpress-v2m-rs1.dtsi            |   17 +-
 arch/arm/boot/dts/vexpress-v2m.dtsi                |   17 +-
 arch/arm/boot/dts/vexpress-v2p-ca9.dts             |    5 +
 drivers/mfd/vexpress-sysreg.c                      |    5 +
 drivers/video/Kconfig                              |    2 +
 drivers/video/Makefile                             |    5 +
 drivers/video/amba-clcd.c                          |  244 +++++++++++
 drivers/video/display/Kconfig                      |    4 +
 drivers/video/display/Makefile                     |    1 +
 drivers/video/display/display-core.c               |  447 ++++++++++++++++++++
 drivers/video/fbmon.c                              |   29 ++
 drivers/video/vexpress-dvimode.c                   |  158 +++++++
 drivers/video/vexpress-muxfpga.c                   |  228 ++++++++++
 include/linux/amba/clcd.h                          |    2 +
 include/linux/fb.h                                 |    3 +
 include/linux/vexpress.h                           |    2 +
 include/video/display.h                            |  172 ++++++++
 20 files changed, 1448 insertions(+), 8 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-driver-video-vexpress-muxfpga
 create mode 100644 Documentation/devicetree/bindings/video/arm,pl11x.txt
 create mode 100644 Documentation/devicetree/bindings/video/display-bindings.txt
 create mode 100644 drivers/video/display/Kconfig
 create mode 100644 drivers/video/display/Makefile
 create mode 100644 drivers/video/display/display-core.c
 create mode 100644 drivers/video/vexpress-dvimode.c
 create mode 100644 drivers/video/vexpress-muxfpga.c
 create mode 100644 include/video/display.h

-- 
1.7.10.4




From linus.walleij at linaro.org  Wed Apr 17 11:20:48 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Wed, 17 Apr 2013 17:20:48 +0200
Subject: [PATCH v4] pinctrl: Add pinctrl-s3c24xx driver
In-Reply-To: <201304140138.40142.heiko@sntech.de>
References: <201304140138.40142.heiko@sntech.de>
Message-ID: <CACRpkdYaKpDtWM5N1NNnWch5m+KYB-2HQgNNddTYiiF1pQ4S_A@mail.gmail.com>

On Sun, Apr 14, 2013 at 1:38 AM, Heiko St?bner <heiko at sntech.de> wrote:

> The s3c24xx pins follow a similar pattern as the other Samsung SoCs and
> can therefore reuse the already introduced infrastructure.
>
> The s3c24xx SoCs have one design oddity in that the first 4 external
> interrupts do not reside in the eint pending register but in the main
> interrupt controller instead. We solve this by forwarding the external
> interrupt from the main controller into the irq domain of the pin bank.
> The masking/acking of these interrupts is handled in the same way.
>
> Furthermore the S3C2412/2413 SoCs contain another oddity in that they
> keep the same 4 eints in the main interrupt controller and eintpend
> register and requiring ack operations to happen in both. This is solved
> by using different compatible properties for the wakeup eint node which
> set a property accordingly.
>
> Signed-off-by: Heiko Stuebner <heiko at sntech.de>
> Reviewed-by: Tomasz Figa <t.figa at samsung.com>
> Reviewed-by: Sylwester Nawrocki <s.nawrocki at samsung.com>

Looking good, Acked-by: Linus Walleij <linus.walleij at linaro.org>

I prefer this:

#include <linux/bitops.h>

int foo = BIT(7);

over

int foo = (1 << 7);

But no big deal.

Are you taking this through the Samsung tree?

Yours,
Linus Walleij


From swarren at wwwdotorg.org  Wed Apr 17 11:21:30 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Wed, 17 Apr 2013 09:21:30 -0600
Subject: [PATCH v2] pinctrl/pinconfig: add debug interface
In-Reply-To: <516EB2B7.30607@st.com>
References: <1365018447-28062-1-git-send-email-linus.walleij@stericsson.com>
 <515DEC92.9010602@wwwdotorg.org> <516EB2B7.30607@st.com>
Message-ID: <516EBDFA.90201@wwwdotorg.org>

On 04/17/2013 08:33 AM, Laurent MEUNIER wrote:
> On 04/04/2013 11:11 PM, Stephen Warren wrote:
>> On 04/03/2013 01:47 PM, Linus Walleij wrote:
>>> From: Laurent Meunier <laurent.meunier at st.com>
>>>
>>> This update adds a debugfs interface to modify a pin configuration
>>> for a given state in the pinctrl map. This allows to modify the
>>> configuration for a non-active state, typically sleep state.
>>> This configuration is not applied right away, but only when the state
>>> will be entered.
>>>
>>> This solution is mandated for us by HW validation: in order
>>> to test and verify several pin configurations during sleep without
>>> recompiling the software.
>>>
>>> diff --git a/drivers/pinctrl/pinconf.c b/drivers/pinctrl/pinconf.c
>>> +enum pinconf_dbg_request_type {
>>> +	PINCONF_DBG_REQ_TYPE_INVALID,
>>> +	PINCONF_DBG_REQ_TYPE_MODIFY,
>>> +};
>> I'm not sure why that really needs an enum yet, since only one operation
>> is supported.
>
> I agree the enum does not bring a lot of added value, for now.
> It is there following one earlier comment that the debugfs
> could be later extended to support ADD / DELETE. This is
> a preparation step to this, so I've kept it in in my V3.
> Hope this is fine.

That seems like something that could easily be added later. right now,
it's just dead code. I'll let LinusW make the call though.

>>> +struct dbg_cfg {
>>> +	enum pinconf_dbg_request_type req_type;
>>> +	enum pinctrl_map_type map_type;
>>> +	char dev_name[MAX_NAME_LEN+1];
>>> +	char state_name[MAX_NAME_LEN+1];
>>> +	char pin_name[MAX_NAME_LEN+1];
>>> +	char config[MAX_NAME_LEN+1];
>>> +};
>
>> Many of those fields are only used internally to
>> pinconf_dbg_config_write(). Can't they be stored on the stack there
>> rather than globally.
>
> I'd like to get the context as a global to share it between _print()
> and _write() functions. I find it quite useful in practice
> basically when using the debugfs, after the write request,
> you can simply cat pinconf-config and check the status of
> what you've last written to. This is the rationale at least.

Data that truly is shared between print() and write() would have to be
global. My point is that many of those fields are not shared, and hence
there's no point making them global.


From linus.walleij at linaro.org  Wed Apr 17 11:24:18 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Wed, 17 Apr 2013 17:24:18 +0200
Subject: [PATCH v2] UCB1400: Pass ucb1400-gpio data through ac97 bus
In-Reply-To: <1365964548-4193-1-git-send-email-marex@denx.de>
References: <CACRpkdZ+ku_-SBTXwwwRDh7F2TXzpgpAF3k+Ksn98BNYXximXw@mail.gmail.com>
 <1365964548-4193-1-git-send-email-marex@denx.de>
Message-ID: <CACRpkdb6tkyB2GWhkywY7gOG=MCBVGNaYy40kNo=LEe_shhbWg@mail.gmail.com>

On Sun, Apr 14, 2013 at 8:35 PM, Marek Vasut <marex at denx.de> wrote:

> Cc: Linus Walleij <linus.walleij at linaro.org>
> Cc: Jean Delvare <jdelvare at suse.de>
> Cc: Samuel Ortiz <sameo at linux.intel.com>
> Cc: Mark Brown <broonie at opensource.wolfsonmicro.com>
> Cc: Guenter Roeck <linux at roeck-us.net>
> Cc: linux-kernel <linux-kernel at vger.kernel.org>
> Cc: Grant Likely <grant.likely at secretlab.ca>
> Signed-off-by: Marek Vasut <marex at denx.de>

Acked-by: Linus Walleij <linus.walleij at linaro.org>

Sam, please pick it up if you're also OK with this.

Yours,
Linus Walleij


From arnd at arndb.de  Wed Apr 17 11:31:56 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed, 17 Apr 2013 17:31:56 +0200
Subject: [PATCH] mmc: mmci: Allow MMCI to request channels with
 information acquired from DT
In-Reply-To: <20130417150437.GA3137@gmail.com>
References: <1366205534-25079-1-git-send-email-lee.jones@linaro.org>
 <201304171550.56037.arnd@arndb.de> <20130417150437.GA3137@gmail.com>
Message-ID: <201304171731.56292.arnd@arndb.de>

On Wednesday 17 April 2013, Lee Jones wrote:
> > This looks unnecessarily complex.
> 
> That thought did cross my mind.
> 
> > Why not just do dma_request_slave_channel_compat() unconditionally here?
> 
> So how about something like this instead, as it keeps the current
> semantics, and only differs in the case of DT.

Yes, looks better.

> @@ -298,14 +298,16 @@ static void mmci_init_sg(struct mmci_host *host, struct mmc_data *data)
>   * no custom DMA interfaces are supported.
>   */
>  #ifdef CONFIG_DMA_ENGINE
> -static void mmci_dma_setup(struct mmci_host *host)
> +static void mmci_dma_setup(struct amba_device *dev,
> +			   struct mmci_host *host)
>  {
> +	struct device_node *np = dev->dev.of_node;
>  	struct mmci_platform_data *plat = host->plat;
>  	const char *rxname, *txname;
>  	dma_cap_mask_t mask;
>  
> -	if (!plat || !plat->dma_filter) {
> -		dev_info(mmc_dev(host->mmc), "no DMA platform data\n");
> +	if (!(plat && plat->dma_filter) && !np) {
> +		dev_info(mmc_dev(host->mmc), "no DMA platform data or DT\n");
>  		return;
>  	}

I think you can further simplify this, given that in the DT case we always
allocate a zeroed mmci_platform_data for host->plat, so !plat cannot happen
when we get here.

> @@ -321,19 +323,21 @@ static void mmci_dma_setup(struct mmci_host *host)
>  	 * attempt to use it bidirectionally, however if it is
>  	 * is specified but cannot be located, DMA will be disabled.
>  	 */
> -	if (plat->dma_rx_param) {
> -		host->dma_rx_channel = dma_request_channel(mask,
> -							   plat->dma_filter,
> -							   plat->dma_rx_param);
> +	if ((plat && plat->dma_rx_param) || np) {
> +		host->dma_rx_channel = dma_request_slave_channel_compat(mask,
> +					(plat) ? plat->dma_filter : NULL,
> +					(plat) ? plat->dma_rx_param : NULL,
> +					&dev->dev, "rx");
>  		/* E.g if no DMA hardware is present */
>  		if (!host->dma_rx_channel)
>  			dev_err(mmc_dev(host->mmc), "no RX DMA channel\n");

And based on that, you can unconditionally pass plat->dma_filter and
plat->dma_rx_param here. In case of DT, they will be NULL, and they
will not be used either.

	Arnd


From swarren at wwwdotorg.org  Wed Apr 17 11:41:35 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Wed, 17 Apr 2013 09:41:35 -0600
Subject: [PATCH 3/5] gpio/omap: Add DT support to GPIO driver
In-Reply-To: <516DDB4D.9020500@ti.com>
References: <1329321854-24490-1-git-send-email-b-cousson@ti.com>
 <514CE0AB.6060207@ti.com>
 <CACRpkdZmv-rAoKSQYpkHHSMzKJOn5TixVW_P3=m7ZNagBYCUPw@mail.gmail.com>
 <515319D5.20105@wwwdotorg.org>
 <CACRpkdYXVLgCz1Tyu-Ls2V2OTc4R3cGNJhfQJB6Hiz_K9dkZYQ@mail.gmail.com>
 <5155C902.7080207@wwwdotorg.org>
 <CACRpkdYbs4-uudpRUY8e+7icYYkZrfM0kReP3pLL5DMiURJ4dg@mail.gmail.com>
 <5165CB9D.1090202@wwwdotorg.org>
 <CACRpkdYirFNqmGhA4K9CL4ve4NYhs8Rd3SFt1iwW9vHBkrcz8g@mail.gmail.com>
 <51671D7B.5060303@wwwdotorg.org>
 <CACRpkdbf32Ef77GmXk9id9+RRjcDRTr7S+F4nznoeZU8y=BT_Q@mail.gmail.com>
 <51673D70.3010503@wwwdotorg.org>
 <CAAwP0s0e2x33jZQhFRY+Hoo61SFqYKRgWk=1mL2+DNxSDJHz+A@mail.gmail.com>
 <CACRpkda4h+qXTvsirPAS7E7sjXhMLE62q=VDy53W8UchsYjbNg@mail.gmail.com>
 <516C31C3.9040505@wwwdotorg.org> <516C73C6.5050409@ti.co m>
 <516C7C43.3040105@wwwdotorg.org> <516C8760.2050500@ti.com>
 <516D9B05.1000501@wwwdotorg.org> <516DA60A.5070000@ti.com>
 <516DCCA8.3070108@wwwdotorg.org> <516DDB4D.9020500@ti.com>
Message-ID: <516EC2AF.9090905@wwwdotorg.org>

On 04/16/2013 05:14 PM, Jon Hunter wrote:
> 
> On 04/16/2013 05:11 PM, Stephen Warren wrote:
>> On 04/16/2013 01:27 PM, Jon Hunter wrote:
>>>
>>> On 04/16/2013 01:40 PM, Stephen Warren wrote:
>>>> On 04/15/2013 05:04 PM, Jon Hunter wrote:
>> ...
>>>>> If some driver is calling gpio_request() directly, then they will most
>>>>> likely just call gpio_to_irq() when requesting the interrupt and so the
>>>>> xlate function would not be called in this case (mmc drivers are a good
>>>>> example). So I don't see that as being a problem. In fact that's the
>>>>> benefit of this approach as AFAICT it solves this problem.
>>>>
>>>> Oh. That assumption seems very fragile. What about drivers that actually
>>>> do have platform data (or DT bindings) that provide both the IRQ and
>>>> GPIO IDs, and hence don't use gpio_to_irq()? That's entirely possible.
>>>
>>> Right. In the DT case though, if someone does provide the IRQ and GPIO
>>> IDs then at least they would use a different xlate function. Another
>>> option to consider would be defining the #interrupt-cells = <3> where we
>>> would have ...
>>>
>>> cell-#1 --> IRQ domain ID
>>> cell-#2 --> Trigger type
>>> cell-#3 --> GPIO ID
>>>
>>> Then we could have a generic xlate for 3 cells that would also request
>>> the GPIO. Again not sure if people are against a gpio being requested in
>>> the xlate but just an idea. Or given that irq_of_parse_and_map() calls
>>> the xlate, we could have this function call gpio_request() if the
>>> interrupt controller is a gpio and there are 3 cells.
>>
>> I rather dislike this approach since:
>>
>> a) It requires changes to the DT bindings, which are already defined.
>> Admittedly it's backwards-compatible, but still.
>>
>> b) There isn't really any need for the DT to represent this; the
>> GPIO+IRQ driver itself already knows which IRQ ID is which GPIO ID and
>> vice-versa (if the HW has such a concept), so there's no need for the DT
>> to contain this information. This seems like pushing Linux's internal
>> requirements into the design of the DT binding.
> 
> Yes, so the only alternative is to use irq_to_gpio to avoid this.
> 
>> c) I have the feeling that hooking the of_xlate function for this is a
>> bit of an abuse of the function.
> 
> I was wondering about that. So I was grep'ing through the various xlate
> implementations and found this [1]. Also you may recall that in the
> of_dma_simple_xlate() we call the dma_request_channel() to allocate the
> channel, which is very similar. However, I don't wish to get a
> reputation as abusing APIs so would be good to know if this really is
> abuse or not ;-)
> 
> Cheers
> Jon
> 
> [1] http://permalink.gmane.org/gmane.linux.ports.arm.kernel/195124
> 

Interesting.

This is really something that the core DT and GPIO and IRQ maintainers
should weigh in on. Hence, changing them from Cc: to To: in this message
and/or adding them.


From linus.walleij at linaro.org  Wed Apr 17 11:42:48 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Wed, 17 Apr 2013 17:42:48 +0200
Subject: [PATCH v7 3/3] of/pci: mips: convert to common of_pci_range_parser
In-Reply-To: <1366107508-12672-4-git-send-email-Andrew.Murray@arm.com>
References: <1366107508-12672-1-git-send-email-Andrew.Murray@arm.com>
 <1366107508-12672-4-git-send-email-Andrew.Murray@arm.com>
Message-ID: <CACRpkdbBaT1OKr5t8HW4+8y_wSDmGxmewAyVMekx8S-K9s3K8Q@mail.gmail.com>

On Tue, Apr 16, 2013 at 12:18 PM, Andrew Murray <Andrew.Murray at arm.com> wrote:

> This patch converts the pci_load_of_ranges function to use the new common
> of_pci_range_parser.
>
> Signed-off-by: Andrew Murray <Andrew.Murray at arm.com>
> Signed-off-by: Liviu Dudau <Liviu.Dudau at arm.com>
> Reviewed-by: Rob Herring <rob.herring at calxeda.com>

Tested-by: Linus Walleij <linus.walleij at linaro.org>

Yours,
Linus Walleij


From robherring2 at gmail.com  Wed Apr 17 11:46:52 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Wed, 17 Apr 2013 10:46:52 -0500
Subject: [PATCH] ARM: highbank: fix cache flush ordering for cpu hotplug
Message-ID: <1366213612-13526-1-git-send-email-robherring2@gmail.com>

From: Rob Herring <rob.herring at calxeda.com>

The L1 data cache flush needs to be after highbank_set_cpu_jump call which
pollutes the cache with the l2x0_lock. This causes other cores to deadlock
waiting for the l2x0_lock. Moving the flush of the entire data cache after
highbank_set_cpu_jump fixes the problem. Use flush_cache_louis instead of
flush_cache_all are that is sufficient to flush only the L1 data cache.
flush_cache_louis did not exist when highbank_cpu_die was originally
written.

With PL310 errata 769419 enabled, a wmb is inserted into idle which takes
the l2x0_lock. This makes the problem much more easily hit and causes
reset to hang.

Reported-by: Paolo Pisati <p.pisati at gmail.com>
Signed-off-by: Rob Herring <rob.herring at calxeda.com>
---
Olof, Arnd,

If you have any more 3.9 fixes, please send this in. Otherwise, it can
wait for 3.10 and mark for stable.

Rob

 arch/arm/mach-highbank/hotplug.c |   10 ++++------
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-highbank/hotplug.c b/arch/arm/mach-highbank/hotplug.c
index f30c528..890cae2 100644
--- a/arch/arm/mach-highbank/hotplug.c
+++ b/arch/arm/mach-highbank/hotplug.c
@@ -28,13 +28,11 @@ extern void secondary_startup(void);
  */
 void __ref highbank_cpu_die(unsigned int cpu)
 {
-	flush_cache_all();
-
 	highbank_set_cpu_jump(cpu, phys_to_virt(0));
-	highbank_set_core_pwr();
 
-	cpu_do_idle();
+	flush_cache_louis();
+	highbank_set_core_pwr();
 
-	/* We should never return from idle */
-	panic("highbank: cpu %d unexpectedly exit from shutdown\n", cpu);
+	while (1)
+		cpu_do_idle();
 }
-- 
1.7.10.4



From grant.likely at secretlab.ca  Wed Apr 17 12:00:15 2013
From: grant.likely at secretlab.ca (Grant Likely)
Date: Wed, 17 Apr 2013 17:00:15 +0100
Subject: [PATCH v7 1/3] of/pci: Unify pci_process_bridge_OF_ranges from
 Microblaze and PowerPC
In-Reply-To: <20130416103005.GB12726@arm.com>
References: <1366107508-12672-1-git-send-email-Andrew.Murray@arm.com>
 <1366107508-12672-2-git-send-email-Andrew.Murray@arm.com>
 <20130416103005.GB12726@arm.com>
Message-ID: <20130417160015.777453E2B73@localhost>

On Tue, 16 Apr 2013 11:30:06 +0100, Andrew Murray <andrew.murray at arm.com> wrote:
> On Tue, Apr 16, 2013 at 11:18:26AM +0100, Andrew Murray wrote:
> > The pci_process_bridge_OF_ranges function, used to parse the "ranges"
> > property of a PCI host device, is found in both Microblaze and PowerPC
> > architectures. These implementations are nearly identical. This patch
> > moves this common code to a common place.
> > 
> > Signed-off-by: Andrew Murray <Andrew.Murray at arm.com>
> > Signed-off-by: Liviu Dudau <Liviu.Dudau at arm.com>
> > Reviewed-by: Rob Herring <rob.herring at calxeda.com>
> > Tested-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> > Tested-by: Linus Walleij <linus.walleij at linaro.org>
> > Acked-by: Michal Simek <monstr at monstr.eu>
> > ---
> >  arch/microblaze/include/asm/pci-bridge.h |    5 +-
> >  arch/microblaze/pci/pci-common.c         |  192 ----------------------------
> >  arch/powerpc/include/asm/pci-bridge.h    |    5 +-
> >  arch/powerpc/kernel/pci-common.c         |  192 ----------------------------
> 
> Is there anyone on linuxppc-dev/linux-mips that can help test this patchset?
> 
> I've tested that it builds on powerpc with a variety of configs (some which
> include fsl_pci.c implementation). Though I don't have hardware to verify that
> it works.
> 
> I haven't tested this builds or runs on MIPS.
> 
> You shouldn't see any difference in behaviour or new warnings and PCI devices
> should continue to operate as before.

I've got through a line-by-line comparison between powerpc, microblaze,
and then new code. The differences are purely cosmetic, so I have
absolutely no concerns about this patch. I've applied it to my tree.

g.



From nicolas.pitre at linaro.org  Wed Apr 17 12:02:31 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Wed, 17 Apr 2013 12:02:31 -0400 (EDT)
Subject: [RFC PATCH 2/2] ARM: DT: kernel: DT cpu node bindings update
In-Reply-To: <516EBC66.20508@wwwdotorg.org>
References: <1366042402-8987-1-git-send-email-lorenzo.pieralisi@arm.com>
 <1366042402-8987-3-git-send-email-lorenzo.pieralisi@arm.com>
 <516C544A.4090107@wwwdotorg.org>
 <20130417091457.GB5012@e106331-lin.cambridge.arm.com>
 <516EBC66.20508@wwwdotorg.org>
Message-ID: <alpine.LFD.2.03.1304171146530.17375@syhkavp.arg>

On Wed, 17 Apr 2013, Stephen Warren wrote:

> On 04/17/2013 03:14 AM, Mark Rutland wrote:
> > Hi Stephen,
> > 
> >>> +	- enable-method
> >>> +		Usage: required on ARM 64-bit systems, optional on ARM 32-bit
> >>> +		       systems
> >>> +		Value type: <string>
> >>> +		Definition: On ARM 64-bit systems must be "spin-table" [1].
> >>
> >> Can that be an integer instead? with dtc+cpp support, that shouldn't
> >> hurt the eyes too much any more.
> > 
> > The "enable-method" property is described as a stringlist by ePAPR, and is
> > currently in use on arm64 as such. It *must* remain a string(list) for arm64.
> > 
> > Having it as an integer for arm is only going to cause us additional work,
> > makes it impossible to share a common dt between 64bit and 32bit, and goes
> > against the standard. I think it should be a stringlist for arm.
> 
> OK, that's a great reason for this case.
> 
> I hope we don't introduce any more standards that use strings, but that
> may just be my personal preference...

I think in any standard, strings are far easier to deal with.  
Especially with config stuff which is far from being performance 
critical. Strings are much less prone to conflicts.  It is too easy to 
"extend" a standard by assigning meanings to free numerical values just 
to discover that someone else did use the same numbers for other 
meanings.

In order to avoid this issue, a central authority has to be established 
to assign numbers out while strings are fine without that most of the 
time.

Not that I advocate for everyone to go wild and create their own 
strings, but if they do it anyway this won't be a catastrophy like 
conflicting numbers are.


Nicolas


From u.kleine-koenig at pengutronix.de  Wed Apr 17 12:02:20 2013
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Wed, 17 Apr 2013 18:02:20 +0200
Subject: [PATCH v3] irqchip: Add support for ARMv7-M's NVIC
Message-ID: <1366214540-31166-1-git-send-email-u.kleine-koenig@pengutronix.de>

This interrupt controller is found on Cortex-M3 and Cortex-M4 machines.

Support for this controller appeared in Catalin's Cortex tree based on
2.6.33 but was nearly completely rewritten.

Signed-off-by: Catalin Marinas <catalin.marinas at arm.com>
Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---

Notes:
    Changes since v2, sent with
    Message-id:1363612826-15623-1-git-send-email-u.kleine-koenig at pengutronix.de:
    
     - drop superflous check for node != NULL in init function
     - rework for linear irq domain
     - drop seperate function for non-dt init

This patch triggers two checkpatch warnings:

	WARNING: Avoid CamelCase: <nvic_do_IRQ>
	WARNING: Avoid CamelCase: <handle_IRQ>

but I think they are OK for consistency?!
Moreover sparse tells me:

	drivers/irqchip/irq-nvic.c:58:1: warning: symbol 'nvic_do_IRQ' was not declared. Should it be static?

nvic_do_IRQ is called from assembler only, so a declaration couldn't be
shared and I couldn't find a nice place for a declaration. Suggestions
welcome.

Thanks
Uwe

 drivers/irqchip/Kconfig    |   4 ++
 drivers/irqchip/Makefile   |   1 +
 drivers/irqchip/irq-nvic.c | 154 +++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 159 insertions(+)
 create mode 100644 drivers/irqchip/irq-nvic.c

diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index a350969..18657fd 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -10,6 +10,10 @@ config ARM_GIC
 config GIC_NON_BANKED
 	bool
 
+config ARM_NVIC
+	bool
+	select IRQ_DOMAIN
+
 config ARM_VIC
 	bool
 	select IRQ_DOMAIN
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index 98e3b87..7227c5f 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -7,5 +7,6 @@ obj-$(CONFIG_METAG_PERFCOUNTER_IRQS)	+= irq-metag.o
 obj-$(CONFIG_ARCH_SUNXI)		+= irq-sunxi.o
 obj-$(CONFIG_ARCH_SPEAR3XX)		+= spear-shirq.o
 obj-$(CONFIG_ARM_GIC)			+= irq-gic.o
+obj-$(CONFIG_ARM_NVIC)			+= irq-nvic.o
 obj-$(CONFIG_ARM_VIC)			+= irq-vic.o
 obj-$(CONFIG_VERSATILE_FPGA_IRQ)	+= irq-versatile-fpga.o
diff --git a/drivers/irqchip/irq-nvic.c b/drivers/irqchip/irq-nvic.c
new file mode 100644
index 0000000..6e9ca8a
--- /dev/null
+++ b/drivers/irqchip/irq-nvic.c
@@ -0,0 +1,154 @@
+/*
+ * drivers/irq/irq-nvic.c
+ *
+ * Copyright (C) 2008 ARM Limited, All Rights Reserved.
+ * Copyright (C) 2013 Pengutronix
+ *
+ * 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.
+ *
+ * Support for the Nested Vectored Interrupt Controller found on the
+ * ARMv7-M CPUs (Cortex-M3/M4)
+ */
+#define pr_fmt(fmt)	KBUILD_MODNAME ": " fmt
+
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/export.h>
+#include <linux/slab.h>
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/irq.h>
+#include <linux/irqdomain.h>
+
+#include <asm/v7m.h>
+#include <asm/exception.h>
+
+#include "irqchip.h"
+
+#define NVIC_ISER			0x000
+#define NVIC_ICER			0x080
+#define NVIC_IPR			0x300
+
+#define NVIC_MAX_BANKS		16
+/*
+ * Each bank handles 32 irqs. Only the 16th (= last) bank handles only
+ * 16 irqs.
+ */
+#define NVIC_MAX_IRQ		((NVIC_MAX_BANKS - 1) * 32 + 16)
+
+struct nvic_bank_data {
+	/*
+	 * For irq i base holds nvic_base + 4 * i / 32. So you can access the
+	 * right ISER register (i.e ISER[i / 32]) by just taking base + ISER.
+	 * Ditto for ICER.
+	 */
+	void __iomem *base;
+};
+
+static struct nvic_chip_data {
+	struct irq_domain *domain;
+	struct nvic_bank_data bdata[NVIC_MAX_BANKS];
+} nvic_chip_data;
+
+asmlinkage void __exception_irq_entry
+nvic_do_IRQ(irq_hw_number_t hwirq, struct pt_regs *regs)
+{
+	unsigned int irq = irq_linear_revmap(nvic_chip_data.domain, hwirq);
+
+	handle_IRQ(irq, regs);
+}
+
+static inline void __iomem *nvic_bank_base(struct irq_data *d)
+{
+	struct nvic_bank_data *bank_data = irq_data_get_irq_chip_data(d);
+	return bank_data->base;
+}
+
+static void nvic_mask_irq(struct irq_data *d)
+{
+	u32 mask = 1 << (d->hwirq % 32);
+
+	writel_relaxed(mask, nvic_bank_base(d) + NVIC_ICER);
+}
+
+static void nvic_unmask_irq(struct irq_data *d)
+{
+	u32 mask = 1 << (d->hwirq % 32);
+
+	writel_relaxed(mask, nvic_bank_base(d) + NVIC_ISER);
+}
+
+static void nvic_eoi(struct irq_data *d)
+{
+	/*
+	 * This is a no-op as end of interrupt is signaled by the exception
+	 * return sequence.
+	 */
+}
+
+static struct irq_chip nvic_chip = {
+	.name = "NVIC",
+	.irq_mask = nvic_mask_irq,
+	.irq_unmask = nvic_unmask_irq,
+	.irq_eoi = nvic_eoi,
+};
+
+static int nvic_irq_domain_map(struct irq_domain *domain, unsigned int virq,
+			       irq_hw_number_t hw)
+{
+	irq_set_chip_and_handler(virq, &nvic_chip,
+				 handle_fasteoi_irq);
+	irq_set_chip_data(virq, nvic_chip_data.bdata + hw / 32);
+	set_irq_flags(virq, IRQF_VALID | IRQF_PROBE);
+
+	return 0;
+}
+
+static struct irq_domain_ops nvic_irq_domain_ops = {
+	.xlate = irq_domain_xlate_onetwocell,
+	.map = nvic_irq_domain_map,
+};
+
+static int __init nvic_of_init(struct device_node *node,
+			       struct device_node *parent)
+{
+	void __iomem *nvic_base;
+	unsigned int irqs, i;
+	unsigned numbanks = (readl_relaxed(V7M_SCS_ICTR) &
+			     V7M_SCS_ICTR_INTLINESNUM_MASK) + 1;
+
+	nvic_base = of_iomap(node, 0);
+	if (!nvic_base) {
+		pr_warn("unable to map nvic registers\n");
+		return -ENOMEM;
+	}
+
+	irqs = numbanks * 32;
+	if (irqs > NVIC_MAX_IRQ)
+		irqs = NVIC_MAX_IRQ;
+
+	for (i = 0; i < numbanks; ++i)
+		nvic_chip_data.bdata[i].base = nvic_base + 4 * i;
+
+	nvic_chip_data.domain =
+		irq_domain_add_linear(node, irqs, &nvic_irq_domain_ops, NULL);
+	if (!nvic_chip_data.domain) {
+		pr_warn("Failed to allocate irq domain\n");
+		return -ENOMEM;
+	}
+
+	/* Disable all interrupts */
+	for (i = 0; i < irqs; i += 32)
+		writel_relaxed(~0, nvic_base + NVIC_ICER + i * 4 / 32);
+
+	/* Set priority on all interrupts */
+	for (i = 0; i < irqs; i += 4)
+		writel_relaxed(0, nvic_base + NVIC_IPR + i);
+
+	return 0;
+}
+IRQCHIP_DECLARE(armv7m_nvic, "arm,armv7m-nvic", nvic_of_init);
-- 
1.8.2.rc3



From jason at lakedaemon.net  Wed Apr 17 12:10:36 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Wed, 17 Apr 2013 12:10:36 -0400
Subject: [PATCH v7 1/3] of/pci: Unify pci_process_bridge_OF_ranges from
 Microblaze and PowerPC
In-Reply-To: <20130417160015.777453E2B73@localhost>
References: <1366107508-12672-1-git-send-email-Andrew.Murray@arm.com>
 <1366107508-12672-2-git-send-email-Andrew.Murray@arm.com>
 <20130416103005.GB12726@arm.com>
 <20130417160015.777453E2B73@localhost>
Message-ID: <20130417161036.GB27197@titan.lakedaemon.net>

On Wed, Apr 17, 2013 at 05:00:15PM +0100, Grant Likely wrote:
> On Tue, 16 Apr 2013 11:30:06 +0100, Andrew Murray <andrew.murray at arm.com> wrote:
> > On Tue, Apr 16, 2013 at 11:18:26AM +0100, Andrew Murray wrote:
> > > The pci_process_bridge_OF_ranges function, used to parse the "ranges"
> > > property of a PCI host device, is found in both Microblaze and PowerPC
> > > architectures. These implementations are nearly identical. This patch
> > > moves this common code to a common place.
> > > 
> > > Signed-off-by: Andrew Murray <Andrew.Murray at arm.com>
> > > Signed-off-by: Liviu Dudau <Liviu.Dudau at arm.com>
> > > Reviewed-by: Rob Herring <rob.herring at calxeda.com>
> > > Tested-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> > > Tested-by: Linus Walleij <linus.walleij at linaro.org>
> > > Acked-by: Michal Simek <monstr at monstr.eu>
> > > ---
> > >  arch/microblaze/include/asm/pci-bridge.h |    5 +-
> > >  arch/microblaze/pci/pci-common.c         |  192 ----------------------------
> > >  arch/powerpc/include/asm/pci-bridge.h    |    5 +-
> > >  arch/powerpc/kernel/pci-common.c         |  192 ----------------------------
> > 
> > Is there anyone on linuxppc-dev/linux-mips that can help test this patchset?
> > 
> > I've tested that it builds on powerpc with a variety of configs (some which
> > include fsl_pci.c implementation). Though I don't have hardware to verify that
> > it works.
> > 
> > I haven't tested this builds or runs on MIPS.
> > 
> > You shouldn't see any difference in behaviour or new warnings and PCI devices
> > should continue to operate as before.
> 
> I've got through a line-by-line comparison between powerpc, microblaze,
> and then new code. The differences are purely cosmetic, so I have
> absolutely no concerns about this patch. I've applied it to my tree.

oops.  Due to the number of dependencies the mvebu-pcie series has (this
being one of them, we (arm-soc/mvebu) asked if we could take this
through our tree.  Rob Herring agreed to this several days ago.  Is this
a problem for you?

It would truly (dogs and cats living together) upset the apple cart for
us at this stage to pipe these through a different tree...

thx,

Jason.


From u.kleine-koenig at pengutronix.de  Wed Apr 17 12:14:56 2013
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Wed, 17 Apr 2013 18:14:56 +0200
Subject: [PATCH v11 0/3] Another round of ARMv7-M patches
Message-ID: <1366215299-31969-1-git-send-email-u.kleine-koenig@pengutronix.de>

Hello,

the changes since v10 are small:

 - Jonny noticed an inconsitency in arch/arm/mm/proc-v7m.S
 - changes to account for review comments to my nvic driver (v3 just
   sent out)

I put these three patches in my for-next branch so they should make it
into the next next. The tree merges fine into current Linus' master and
next-20130417.

Russell, what are your thoughts about the series? Would you take it for
v3.10? Or v3.11?

Catalin Marinas (1):
  ARM: Add base support for ARMv7-M

Uwe Kleine-K?nig (2):
  ARM: ARMv7-M: Add support for exception handling
  ARM: ARMv7-M: Allow the building of new kernel port

 arch/arm/Kconfig                   |   4 +-
 arch/arm/Kconfig-nommu             |   2 +-
 arch/arm/Makefile                  |   1 +
 arch/arm/include/asm/assembler.h   |  17 +++-
 arch/arm/include/asm/cputype.h     |  12 ++-
 arch/arm/include/asm/glue-cache.h  |  27 +++++++
 arch/arm/include/asm/glue-df.h     |   8 ++
 arch/arm/include/asm/glue-proc.h   |   9 +++
 arch/arm/include/asm/irqflags.h    |  22 ++++--
 arch/arm/include/asm/ptrace.h      |   4 +
 arch/arm/include/asm/system_info.h |   1 +
 arch/arm/include/asm/v7m.h         |  44 +++++++++++
 arch/arm/include/uapi/asm/ptrace.h |  35 +++++++--
 arch/arm/kernel/Makefile           |   8 +-
 arch/arm/kernel/entry-common.S     |   4 +
 arch/arm/kernel/entry-header.S     | 124 +++++++++++++++++++++++++++++
 arch/arm/kernel/entry-v7m.S        | 143 +++++++++++++++++++++++++++++++++
 arch/arm/kernel/head-nommu.S       |  10 ++-
 arch/arm/kernel/setup.c            |  17 +++-
 arch/arm/kernel/traps.c            |   8 ++
 arch/arm/mm/Kconfig                |  21 ++++-
 arch/arm/mm/Makefile               |   2 +
 arch/arm/mm/cache-nop.S            |  50 ++++++++++++
 arch/arm/mm/nommu.c                |   7 ++
 arch/arm/mm/proc-v7m.S             | 157 +++++++++++++++++++++++++++++++++++++
 25 files changed, 711 insertions(+), 26 deletions(-)
 create mode 100644 arch/arm/include/asm/v7m.h
 create mode 100644 arch/arm/kernel/entry-v7m.S
 create mode 100644 arch/arm/mm/cache-nop.S
 create mode 100644 arch/arm/mm/proc-v7m.S

-- 
1.8.2.rc3



From u.kleine-koenig at pengutronix.de  Wed Apr 17 12:14:57 2013
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Wed, 17 Apr 2013 18:14:57 +0200
Subject: [PATCH v11 1/3] ARM: Add base support for ARMv7-M
In-Reply-To: <1366215299-31969-1-git-send-email-u.kleine-koenig@pengutronix.de>
References: <1366215299-31969-1-git-send-email-u.kleine-koenig@pengutronix.de>
Message-ID: <1366215299-31969-2-git-send-email-u.kleine-koenig@pengutronix.de>

From: Catalin Marinas <catalin.marinas at arm.com>

This patch adds the base support for the ARMv7-M
architecture. It consists of the corresponding arch/arm/mm/ files and
various #ifdef's around the kernel. Exception handling is implemented by
a subsequent patch.

[ukleinek: squash in some changes originating from commit

b5717ba (Cortex-M3: Add support for the Microcontroller Prototyping System)

from the v2.6.33-arm1 patch stack, port to post 3.6, drop zImage
support, drop reorganisation of pt_regs, assert CONFIG_V7M doesn't leak
into installed headers and a few cosmetic changes]

Signed-off-by: Catalin Marinas <catalin.marinas at arm.com>
Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---

Notes:
    Changes since v9, sent with
    Message-id:1363901310-9474-2-git-send-email-u.kleine-koenig at pengutronix.de:
    
     - use relative offsets for V7M_SCB
     - drop unused constants for EXC_RET_... and add a comment instead
     - several new and expanded comments
     - drop HWCAP_SWP and HWCAP_EDSP, add HWCAP_IDIVT
    
    Changes since v10, sent with
    Message-id:1364381692-7955-2-git-send-email-u.kleine-koenig at pengutronix.de:
    
     - drop unneeded #includes from cache-nop.S
     - use define_processor_functions instead of hand coding it. This fixes a
       mismatch between struct processor and v7m_processor_functions. Noticed by
       Jonathan Austin.

 arch/arm/include/asm/assembler.h   |  17 +++-
 arch/arm/include/asm/cputype.h     |  12 ++-
 arch/arm/include/asm/glue-cache.h  |  27 +++++++
 arch/arm/include/asm/glue-df.h     |   8 ++
 arch/arm/include/asm/glue-proc.h   |   9 +++
 arch/arm/include/asm/irqflags.h    |  22 ++++--
 arch/arm/include/asm/ptrace.h      |   4 +
 arch/arm/include/asm/system_info.h |   1 +
 arch/arm/include/asm/v7m.h         |  44 +++++++++++
 arch/arm/include/uapi/asm/ptrace.h |  35 +++++++--
 arch/arm/kernel/head-nommu.S       |  10 ++-
 arch/arm/kernel/setup.c            |  17 +++-
 arch/arm/kernel/traps.c            |   8 ++
 arch/arm/mm/cache-nop.S            |  50 ++++++++++++
 arch/arm/mm/nommu.c                |   7 ++
 arch/arm/mm/proc-v7m.S             | 157 +++++++++++++++++++++++++++++++++++++
 16 files changed, 407 insertions(+), 21 deletions(-)
 create mode 100644 arch/arm/include/asm/v7m.h
 create mode 100644 arch/arm/mm/cache-nop.S
 create mode 100644 arch/arm/mm/proc-v7m.S

diff --git a/arch/arm/include/asm/assembler.h b/arch/arm/include/asm/assembler.h
index 05ee9ee..a5fef71 100644
--- a/arch/arm/include/asm/assembler.h
+++ b/arch/arm/include/asm/assembler.h
@@ -136,7 +136,11 @@
  * assumes FIQs are enabled, and that the processor is in SVC mode.
  */
 	.macro	save_and_disable_irqs, oldcpsr
+#ifdef CONFIG_CPU_V7M
+	mrs	\oldcpsr, primask
+#else
 	mrs	\oldcpsr, cpsr
+#endif
 	disable_irq
 	.endm
 
@@ -150,7 +154,11 @@
  * guarantee that this will preserve the flags.
  */
 	.macro	restore_irqs_notrace, oldcpsr
+#ifdef CONFIG_CPU_V7M
+	msr	primask, \oldcpsr
+#else
 	msr	cpsr_c, \oldcpsr
+#endif
 	.endm
 
 	.macro restore_irqs, oldcpsr
@@ -229,7 +237,14 @@
 #endif
 	.endm
 
-#ifdef CONFIG_THUMB2_KERNEL
+#if defined(CONFIG_CPU_V7M)
+	/*
+	 * setmode is used to assert to be in svc mode during boot. For v7-M
+	 * this is done in __v7m_setup, so setmode can be empty here.
+	 */
+	.macro	setmode, mode, reg
+	.endm
+#elif defined(CONFIG_THUMB2_KERNEL)
 	.macro	setmode, mode, reg
 	mov	\reg, #\mode
 	msr	cpsr_c, \reg
diff --git a/arch/arm/include/asm/cputype.h b/arch/arm/include/asm/cputype.h
index 7652712..4eb94a3 100644
--- a/arch/arm/include/asm/cputype.h
+++ b/arch/arm/include/asm/cputype.h
@@ -106,7 +106,17 @@ static inline unsigned int __attribute_const__ read_cpuid_id(void)
 	return read_cpuid(CPUID_ID);
 }
 
-#else /* ifdef CONFIG_CPU_CP15 */
+#elif defined(CONFIG_CPU_V7M)
+
+#include <asm/io.h>
+#include <asm/v7m.h>
+
+static inline unsigned int __attribute_const__ read_cpuid_id(void)
+{
+	return readl(BASEADDR_V7M_SCB + V7M_SCB_CPUID);
+}
+
+#else /* ifdef CONFIG_CPU_CP15 / elif defined(CONFIG_CPU_V7M) */
 
 static inline unsigned int __attribute_const__ read_cpuid_id(void)
 {
diff --git a/arch/arm/include/asm/glue-cache.h b/arch/arm/include/asm/glue-cache.h
index cca9f15..65c9faf 100644
--- a/arch/arm/include/asm/glue-cache.h
+++ b/arch/arm/include/asm/glue-cache.h
@@ -125,10 +125,37 @@
 # endif
 #endif
 
+#if defined(CONFIG_CPU_V7M)
+# ifdef _CACHE
+#  define MULTI_CACHE 1
+# else
+#  define _CACHE nop
+# endif
+#endif
+
 #if !defined(_CACHE) && !defined(MULTI_CACHE)
 #error Unknown cache maintenance model
 #endif
 
+#ifndef __ASSEMBLER__
+extern inline void nop_flush_icache_all(void) { }
+extern inline void nop_flush_kern_cache_all(void) { }
+extern inline void nop_flush_kern_cache_louis(void) { }
+extern inline void nop_flush_user_cache_all(void) { }
+extern inline void nop_flush_user_cache_range(unsigned long a,
+		unsigned long b, unsigned int c) { }
+
+extern inline void nop_coherent_kern_range(unsigned long a, unsigned long b) { }
+extern inline int nop_coherent_user_range(unsigned long a,
+		unsigned long b) { return 0; }
+extern inline void nop_flush_kern_dcache_area(void *a, size_t s) { }
+
+extern inline void nop_dma_flush_range(const void *a, const void *b) { }
+
+extern inline void nop_dma_map_area(const void *s, size_t l, int f) { }
+extern inline void nop_dma_unmap_area(const void *s, size_t l, int f) { }
+#endif
+
 #ifndef MULTI_CACHE
 #define __cpuc_flush_icache_all		__glue(_CACHE,_flush_icache_all)
 #define __cpuc_flush_kern_all		__glue(_CACHE,_flush_kern_cache_all)
diff --git a/arch/arm/include/asm/glue-df.h b/arch/arm/include/asm/glue-df.h
index b6e9f2c..6b70f1b 100644
--- a/arch/arm/include/asm/glue-df.h
+++ b/arch/arm/include/asm/glue-df.h
@@ -95,6 +95,14 @@
 # endif
 #endif
 
+#ifdef CONFIG_CPU_ABRT_NOMMU
+# ifdef CPU_DABORT_HANDLER
+#  define MULTI_DABORT 1
+# else
+#  define CPU_DABORT_HANDLER nommu_early_abort
+# endif
+#endif
+
 #ifndef CPU_DABORT_HANDLER
 #error Unknown data abort handler type
 #endif
diff --git a/arch/arm/include/asm/glue-proc.h b/arch/arm/include/asm/glue-proc.h
index ac1dd54..f2f39bc 100644
--- a/arch/arm/include/asm/glue-proc.h
+++ b/arch/arm/include/asm/glue-proc.h
@@ -230,6 +230,15 @@
 # endif
 #endif
 
+#ifdef CONFIG_CPU_V7M
+# ifdef CPU_NAME
+#  undef  MULTI_CPU
+#  define MULTI_CPU
+# else
+#  define CPU_NAME cpu_v7m
+# endif
+#endif
+
 #ifndef MULTI_CPU
 #define cpu_proc_init			__glue(CPU_NAME,_proc_init)
 #define cpu_proc_fin			__glue(CPU_NAME,_proc_fin)
diff --git a/arch/arm/include/asm/irqflags.h b/arch/arm/include/asm/irqflags.h
index 1e6cca5..3b763d6 100644
--- a/arch/arm/include/asm/irqflags.h
+++ b/arch/arm/include/asm/irqflags.h
@@ -8,6 +8,16 @@
 /*
  * CPU interrupt mask handling.
  */
+#ifdef CONFIG_CPU_V7M
+#define IRQMASK_REG_NAME_R "primask"
+#define IRQMASK_REG_NAME_W "primask"
+#define IRQMASK_I_BIT	1
+#else
+#define IRQMASK_REG_NAME_R "cpsr"
+#define IRQMASK_REG_NAME_W "cpsr_c"
+#define IRQMASK_I_BIT	PSR_I_BIT
+#endif
+
 #if __LINUX_ARM_ARCH__ >= 6
 
 static inline unsigned long arch_local_irq_save(void)
@@ -15,7 +25,7 @@ static inline unsigned long arch_local_irq_save(void)
 	unsigned long flags;
 
 	asm volatile(
-		"	mrs	%0, cpsr	@ arch_local_irq_save\n"
+		"	mrs	%0, " IRQMASK_REG_NAME_R "	@ arch_local_irq_save\n"
 		"	cpsid	i"
 		: "=r" (flags) : : "memory", "cc");
 	return flags;
@@ -129,7 +139,7 @@ static inline unsigned long arch_local_save_flags(void)
 {
 	unsigned long flags;
 	asm volatile(
-		"	mrs	%0, cpsr	@ local_save_flags"
+		"	mrs	%0, " IRQMASK_REG_NAME_R "	@ local_save_flags"
 		: "=r" (flags) : : "memory", "cc");
 	return flags;
 }
@@ -140,7 +150,7 @@ static inline unsigned long arch_local_save_flags(void)
 static inline void arch_local_irq_restore(unsigned long flags)
 {
 	asm volatile(
-		"	msr	cpsr_c, %0	@ local_irq_restore"
+		"	msr	" IRQMASK_REG_NAME_W ", %0	@ local_irq_restore"
 		:
 		: "r" (flags)
 		: "memory", "cc");
@@ -148,8 +158,8 @@ static inline void arch_local_irq_restore(unsigned long flags)
 
 static inline int arch_irqs_disabled_flags(unsigned long flags)
 {
-	return flags & PSR_I_BIT;
+	return flags & IRQMASK_I_BIT;
 }
 
-#endif
-#endif
+#endif /* ifdef __KERNEL__ */
+#endif /* ifndef __ASM_ARM_IRQFLAGS_H */
diff --git a/arch/arm/include/asm/ptrace.h b/arch/arm/include/asm/ptrace.h
index 3d52ee1..04c99f3 100644
--- a/arch/arm/include/asm/ptrace.h
+++ b/arch/arm/include/asm/ptrace.h
@@ -45,6 +45,7 @@ struct pt_regs {
  */
 static inline int valid_user_regs(struct pt_regs *regs)
 {
+#ifndef CONFIG_CPU_V7M
 	unsigned long mode = regs->ARM_cpsr & MODE_MASK;
 
 	/*
@@ -67,6 +68,9 @@ static inline int valid_user_regs(struct pt_regs *regs)
 		regs->ARM_cpsr |= USR_MODE;
 
 	return 0;
+#else /* ifndef CONFIG_CPU_V7M */
+	return 1;
+#endif
 }
 
 static inline long regs_return_value(struct pt_regs *regs)
diff --git a/arch/arm/include/asm/system_info.h b/arch/arm/include/asm/system_info.h
index dfd386d..720ea03 100644
--- a/arch/arm/include/asm/system_info.h
+++ b/arch/arm/include/asm/system_info.h
@@ -11,6 +11,7 @@
 #define CPU_ARCH_ARMv5TEJ	7
 #define CPU_ARCH_ARMv6		8
 #define CPU_ARCH_ARMv7		9
+#define CPU_ARCH_ARMv7M		10
 
 #ifndef __ASSEMBLY__
 
diff --git a/arch/arm/include/asm/v7m.h b/arch/arm/include/asm/v7m.h
new file mode 100644
index 0000000..fa88d09
--- /dev/null
+++ b/arch/arm/include/asm/v7m.h
@@ -0,0 +1,44 @@
+/*
+ * Common defines for v7m cpus
+ */
+#define V7M_SCS_ICTR			IOMEM(0xe000e004)
+#define V7M_SCS_ICTR_INTLINESNUM_MASK		0x0000000f
+
+#define BASEADDR_V7M_SCB		IOMEM(0xe000ed00)
+
+#define V7M_SCB_CPUID			0x00
+
+#define V7M_SCB_ICSR			0x04
+#define V7M_SCB_ICSR_PENDSVSET			(1 << 28)
+#define V7M_SCB_ICSR_PENDSVCLR			(1 << 27)
+#define V7M_SCB_ICSR_RETTOBASE			(1 << 11)
+
+#define V7M_SCB_VTOR			0x08
+
+#define V7M_SCB_SCR			0x10
+#define V7M_SCB_SCR_SLEEPDEEP			(1 << 2)
+
+#define V7M_SCB_CCR			0x14
+#define V7M_SCB_CCR_STKALIGN			(1 << 9)
+
+#define V7M_SCB_SHPR2			0x1c
+#define V7M_SCB_SHPR3			0x20
+
+#define V7M_SCB_SHCSR			0x24
+#define V7M_SCB_SHCSR_USGFAULTENA		(1 << 18)
+#define V7M_SCB_SHCSR_BUSFAULTENA		(1 << 17)
+#define V7M_SCB_SHCSR_MEMFAULTENA		(1 << 16)
+
+#define V7M_xPSR_FRAMEPTRALIGN			0x00000200
+#define V7M_xPSR_EXCEPTIONNO			0x000001ff
+
+/*
+ * When branching to an address that has bits [31:28] == 0xf an exception return
+ * occurs. Bits [27:5] are reserved (SBOP). If the processor implements the FP
+ * extension Bit [4] defines if the exception frame has space allocated for FP
+ * state information, SBOP otherwise. Bit [3] defines the mode that is returned
+ * to (0 -> handler mode; 1 -> thread mode). Bit [2] defines which sp is used
+ * (0 -> msp; 1 -> psp). Bits [1:0] are fixed to 0b01.
+ */
+#define EXC_RET_STACK_MASK			0x00000004
+#define EXC_RET_THREADMODE_PROCESSSTACK		0xfffffffd
diff --git a/arch/arm/include/uapi/asm/ptrace.h b/arch/arm/include/uapi/asm/ptrace.h
index 96ee092..5af0ed1 100644
--- a/arch/arm/include/uapi/asm/ptrace.h
+++ b/arch/arm/include/uapi/asm/ptrace.h
@@ -34,28 +34,47 @@
 
 /*
  * PSR bits
+ * Note on V7M there is no mode contained in the PSR
  */
 #define USR26_MODE	0x00000000
 #define FIQ26_MODE	0x00000001
 #define IRQ26_MODE	0x00000002
 #define SVC26_MODE	0x00000003
+#if defined(__KERNEL__) && defined(CONFIG_CPU_V7M)
+/*
+ * Use 0 here to get code right that creates a userspace
+ * or kernel space thread.
+ */
+#define USR_MODE	0x00000000
+#define SVC_MODE	0x00000000
+#else
 #define USR_MODE	0x00000010
+#define SVC_MODE	0x00000013
+#endif
 #define FIQ_MODE	0x00000011
 #define IRQ_MODE	0x00000012
-#define SVC_MODE	0x00000013
 #define ABT_MODE	0x00000017
 #define HYP_MODE	0x0000001a
 #define UND_MODE	0x0000001b
 #define SYSTEM_MODE	0x0000001f
 #define MODE32_BIT	0x00000010
 #define MODE_MASK	0x0000001f
-#define PSR_T_BIT	0x00000020
-#define PSR_F_BIT	0x00000040
-#define PSR_I_BIT	0x00000080
-#define PSR_A_BIT	0x00000100
-#define PSR_E_BIT	0x00000200
-#define PSR_J_BIT	0x01000000
-#define PSR_Q_BIT	0x08000000
+
+#define V4_PSR_T_BIT	0x00000020	/* >= V4T, but not V7M */
+#define V7M_PSR_T_BIT	0x01000000
+#if defined(__KERNEL__) && defined(CONFIG_CPU_V7M)
+#define PSR_T_BIT	V7M_PSR_T_BIT
+#else
+/* for compatibility */
+#define PSR_T_BIT	V4_PSR_T_BIT
+#endif
+
+#define PSR_F_BIT	0x00000040	/* >= V4, but not V7M */
+#define PSR_I_BIT	0x00000080	/* >= V4, but not V7M */
+#define PSR_A_BIT	0x00000100	/* >= V6, but not V7M */
+#define PSR_E_BIT	0x00000200	/* >= V6, but not V7M */
+#define PSR_J_BIT	0x01000000	/* >= V5J, but not V7M */
+#define PSR_Q_BIT	0x08000000	/* >= V5E, including V7M */
 #define PSR_V_BIT	0x10000000
 #define PSR_C_BIT	0x20000000
 #define PSR_Z_BIT	0x40000000
diff --git a/arch/arm/kernel/head-nommu.S b/arch/arm/kernel/head-nommu.S
index 6a2e09c..8812ce8 100644
--- a/arch/arm/kernel/head-nommu.S
+++ b/arch/arm/kernel/head-nommu.S
@@ -19,6 +19,7 @@
 #include <asm/asm-offsets.h>
 #include <asm/cp15.h>
 #include <asm/thread_info.h>
+#include <asm/v7m.h>
 
 /*
  * Kernel startup entry point.
@@ -50,10 +51,13 @@ ENTRY(stext)
 
 	setmode	PSR_F_BIT | PSR_I_BIT | SVC_MODE, r9 @ ensure svc mode
 						@ and irqs disabled
-#ifndef CONFIG_CPU_CP15
-	ldr	r9, =CONFIG_PROCESSOR_ID
-#else
+#if defined(CONFIG_CPU_CP15)
 	mrc	p15, 0, r9, c0, c0		@ get processor id
+#elif defined(CONFIG_CPU_V7M)
+	ldr	r9, =BASEADDR_V7M_SCB
+	ldr	r9, [r9, V7M_SCB_CPUID]
+#else
+	ldr	r9, =CONFIG_PROCESSOR_ID
 #endif
 	bl	__lookup_processor_type		@ r5=procinfo r9=cpuid
 	movs	r10, r5				@ invalid processor (r5=0)?
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 1cc9e17..8291245 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -128,7 +128,9 @@ struct stack {
 	u32 und[3];
 } ____cacheline_aligned;
 
+#ifndef CONFIG_CPU_V7M
 static struct stack stacks[NR_CPUS];
+#endif
 
 char elf_platform[ELF_PLATFORM_SIZE];
 EXPORT_SYMBOL(elf_platform);
@@ -207,7 +209,7 @@ static const char *proc_arch[] = {
 	"5TEJ",
 	"6TEJ",
 	"7",
-	"?(11)",
+	"7M",
 	"?(12)",
 	"?(13)",
 	"?(14)",
@@ -216,6 +218,12 @@ static const char *proc_arch[] = {
 	"?(17)",
 };
 
+#ifdef CONFIG_CPU_V7M
+static int __get_cpu_architecture(void)
+{
+	return CPU_ARCH_ARMv7M;
+}
+#else
 static int __get_cpu_architecture(void)
 {
 	int cpu_arch;
@@ -248,6 +256,7 @@ static int __get_cpu_architecture(void)
 
 	return cpu_arch;
 }
+#endif
 
 int __pure cpu_architecture(void)
 {
@@ -293,7 +302,9 @@ static void __init cacheid_init(void)
 {
 	unsigned int arch = cpu_architecture();
 
-	if (arch >= CPU_ARCH_ARMv6) {
+	if (arch == CPU_ARCH_ARMv7M) {
+		cacheid = 0;
+	} else if (arch >= CPU_ARCH_ARMv6) {
 		unsigned int cachetype = read_cpuid_cachetype();
 		if ((cachetype & (7 << 29)) == 4 << 29) {
 			/* ARMv7 register format */
@@ -375,6 +386,7 @@ static void __init feat_v6_fixup(void)
  */
 void cpu_init(void)
 {
+#ifndef CONFIG_CPU_V7M
 	unsigned int cpu = smp_processor_id();
 	struct stack *stk = &stacks[cpu];
 
@@ -425,6 +437,7 @@ void cpu_init(void)
 	      "I" (offsetof(struct stack, und[0])),
 	      PLC (PSR_F_BIT | PSR_I_BIT | SVC_MODE)
 	    : "r14");
+#endif
 }
 
 int __cpu_logical_map[NR_CPUS];
diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
index 1c08911..ec645714 100644
--- a/arch/arm/kernel/traps.c
+++ b/arch/arm/kernel/traps.c
@@ -819,6 +819,7 @@ static void __init kuser_get_tls_init(unsigned long vectors)
 
 void __init early_trap_init(void *vectors_base)
 {
+#ifndef CONFIG_CPU_V7M
 	unsigned long vectors = (unsigned long)vectors_base;
 	extern char __stubs_start[], __stubs_end[];
 	extern char __vectors_start[], __vectors_end[];
@@ -850,4 +851,11 @@ void __init early_trap_init(void *vectors_base)
 
 	flush_icache_range(vectors, vectors + PAGE_SIZE);
 	modify_domain(DOMAIN_USER, DOMAIN_CLIENT);
+#else /* ifndef CONFIG_CPU_V7M */
+	/*
+	 * on V7-M there is no need to copy the vector table to a dedicated
+	 * memory area. The address is configurable and so a table in the kernel
+	 * image can be used.
+	 */
+#endif
 }
diff --git a/arch/arm/mm/cache-nop.S b/arch/arm/mm/cache-nop.S
new file mode 100644
index 0000000..8e12ddc
--- /dev/null
+++ b/arch/arm/mm/cache-nop.S
@@ -0,0 +1,50 @@
+/*
+ * 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/linkage.h>
+#include <linux/init.h>
+
+#include "proc-macros.S"
+
+ENTRY(nop_flush_icache_all)
+	mov	pc, lr
+ENDPROC(nop_flush_icache_all)
+
+	.globl nop_flush_kern_cache_all
+	.equ nop_flush_kern_cache_all, nop_flush_icache_all
+
+	.globl nop_flush_kern_cache_louis
+	.equ nop_flush_kern_cache_louis, nop_flush_icache_all
+
+	.globl nop_flush_user_cache_all
+	.equ nop_flush_user_cache_all, nop_flush_icache_all
+
+	.globl nop_flush_user_cache_range
+	.equ nop_flush_user_cache_range, nop_flush_icache_all
+
+	.globl nop_coherent_kern_range
+	.equ nop_coherent_kern_range, nop_flush_icache_all
+
+ENTRY(nop_coherent_user_range)
+	mov	r0, 0
+	mov	pc, lr
+ENDPROC(nop_coherent_user_range)
+
+	.globl nop_flush_kern_dcache_area
+	.equ nop_flush_kern_dcache_area, nop_flush_icache_all
+
+	.globl nop_dma_flush_range
+	.equ nop_dma_flush_range, nop_flush_icache_all
+
+	.globl nop_dma_map_area
+	.equ nop_dma_map_area, nop_flush_icache_all
+
+	.globl nop_dma_unmap_area
+	.equ nop_dma_unmap_area, nop_flush_icache_all
+
+	__INITDATA
+
+	@ define struct cpu_cache_fns (see <asm/cacheflush.h> and proc-macros.S)
+	define_cache_functions nop
diff --git a/arch/arm/mm/nommu.c b/arch/arm/mm/nommu.c
index d51225f..dd3a6c6 100644
--- a/arch/arm/mm/nommu.c
+++ b/arch/arm/mm/nommu.c
@@ -20,12 +20,19 @@
 
 void __init arm_mm_memblock_reserve(void)
 {
+#ifndef CONFIG_CPU_V7M
 	/*
 	 * Register the exception vector page.
 	 * some architectures which the DRAM is the exception vector to trap,
 	 * alloc_page breaks with error, although it is not NULL, but "0."
 	 */
 	memblock_reserve(CONFIG_VECTORS_BASE, PAGE_SIZE);
+#else /* ifndef CONFIG_CPU_V7M */
+	/*
+	 * There is no dedicated vector page on V7-M. So nothing needs to be
+	 * reserved here.
+	 */
+#endif
 }
 
 void __init sanity_check_meminfo(void)
diff --git a/arch/arm/mm/proc-v7m.S b/arch/arm/mm/proc-v7m.S
new file mode 100644
index 0000000..000499c
--- /dev/null
+++ b/arch/arm/mm/proc-v7m.S
@@ -0,0 +1,157 @@
+/*
+ *  linux/arch/arm/mm/proc-v7m.S
+ *
+ *  Copyright (C) 2008 ARM Ltd.
+ *  Copyright (C) 2001 Deep Blue Solutions Ltd.
+ *
+ * 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.
+ *
+ *  This is the "shell" of the ARMv7-M processor support.
+ */
+#include <linux/linkage.h>
+#include <asm/assembler.h>
+#include <asm/v7m.h>
+#include "proc-macros.S"
+
+ENTRY(cpu_v7m_proc_init)
+	mov	pc, lr
+ENDPROC(cpu_v7m_proc_init)
+
+ENTRY(cpu_v7m_proc_fin)
+	mov	pc, lr
+ENDPROC(cpu_v7m_proc_fin)
+
+/*
+ *	cpu_v7m_reset(loc)
+ *
+ *	Perform a soft reset of the system.  Put the CPU into the
+ *	same state as it would be if it had been reset, and branch
+ *	to what would be the reset vector.
+ *
+ *	- loc   - location to jump to for soft reset
+ */
+	.align	5
+ENTRY(cpu_v7m_reset)
+	mov	pc, r0
+ENDPROC(cpu_v7m_reset)
+
+/*
+ *	cpu_v7m_do_idle()
+ *
+ *	Idle the processor (eg, wait for interrupt).
+ *
+ *	IRQs are already disabled.
+ */
+ENTRY(cpu_v7m_do_idle)
+	wfi
+	mov	pc, lr
+ENDPROC(cpu_v7m_do_idle)
+
+ENTRY(cpu_v7m_dcache_clean_area)
+	mov	pc, lr
+ENDPROC(cpu_v7m_dcache_clean_area)
+
+/*
+ * There is no MMU, so here is nothing to do.
+ */
+ENTRY(cpu_v7m_switch_mm)
+	mov	pc, lr
+ENDPROC(cpu_v7m_switch_mm)
+
+.globl	cpu_v7m_suspend_size
+.equ	cpu_v7m_suspend_size, 0
+
+#ifdef CONFIG_ARM_CPU_SUSPEND
+ENTRY(cpu_v7m_do_suspend)
+	mov	pc, lr
+ENDPROC(cpu_v7m_do_suspend)
+
+ENTRY(cpu_v7m_do_resume)
+	mov	pc, lr
+ENDPROC(cpu_v7m_do_resume)
+#endif
+
+	.section ".text.init", #alloc, #execinstr
+
+/*
+ *	__v7m_setup
+ *
+ *	This should be able to cover all ARMv7-M cores.
+ */
+__v7m_setup:
+	@ Configure the vector table base address
+	ldr	r0, =BASEADDR_V7M_SCB
+	ldr	r12, =vector_table
+	str	r12, [r0, V7M_SCB_VTOR]
+
+	@ enable UsageFault, BusFault and MemManage fault.
+	ldr	r5, [r0, #V7M_SCB_SHCSR]
+	orr	r5, #(V7M_SCB_SHCSR_USGFAULTENA | V7M_SCB_SHCSR_BUSFAULTENA | V7M_SCB_SHCSR_MEMFAULTENA)
+	str	r5, [r0, #V7M_SCB_SHCSR]
+
+	@ Lower the priority of the SVC and PendSV exceptions
+	mov	r5, #0x80000000
+	str	r5, [r0, V7M_SCB_SHPR2]	@ set SVC priority
+	mov	r5, #0x00800000
+	str	r5, [r0, V7M_SCB_SHPR3]	@ set PendSV priority
+
+	@ SVC to run the kernel in this mode
+	adr	r1, BSYM(1f)
+	ldr	r5, [r12, #11 * 4]	@ read the SVC vector entry
+	str	r1, [r12, #11 * 4]	@ write the temporary SVC vector entry
+	mov	r6, lr			@ save LR
+	mov	r7, sp			@ save SP
+	ldr	sp, =__v7m_setup_stack_top
+	cpsie	i
+	svc	#0
+1:	cpsid	i
+	str	r5, [r12, #11 * 4]	@ restore the original SVC vector entry
+	mov	lr, r6			@ restore LR
+	mov	sp, r7			@ restore SP
+
+	@ Special-purpose control register
+	mov	r1, #1
+	msr	control, r1		@ Thread mode has unpriviledged access
+
+	@ Configure the System Control Register to ensure 8-byte stack alignment
+	@ Note the STKALIGN bit is either RW or RAO.
+	ldr	r12, [r0, V7M_SCB_CCR]	@ system control register
+	orr	r12, #V7M_SCB_CCR_STKALIGN
+	str	r12, [r0, V7M_SCB_CCR]
+	mov	pc, lr
+ENDPROC(__v7m_setup)
+
+	define_processor_functions v7m, dabort=nommu_early_abort, pabort=legacy_pabort, nommu=1
+
+	.section ".rodata"
+	string cpu_arch_name, "armv7m"
+	string cpu_elf_name "v7m"
+	string cpu_v7m_name "ARMv7-M"
+
+	.section ".proc.info.init", #alloc, #execinstr
+
+	/*
+	 * Match any ARMv7-M processor core.
+	 */
+	.type	__v7m_proc_info, #object
+__v7m_proc_info:
+	.long	0x000f0000		@ Required ID value
+	.long	0x000f0000		@ Mask for ID
+	.long   0			@ proc_info_list.__cpu_mm_mmu_flags
+	.long   0			@ proc_info_list.__cpu_io_mmu_flags
+	b	__v7m_setup		@ proc_info_list.__cpu_flush
+	.long	cpu_arch_name
+	.long	cpu_elf_name
+	.long	HWCAP_HALF|HWCAP_THUMB|HWCAP_FAST_MULT|HWCAP_IDIVT
+	.long	cpu_v7m_name
+	.long	v7m_processor_functions	@ proc_info_list.proc
+	.long	0			@ proc_info_list.tlb
+	.long	0			@ proc_info_list.user
+	.long	nop_cache_fns		@ proc_info_list.cache
+	.size	__v7m_proc_info, . - __v7m_proc_info
+
+__v7m_setup_stack:
+	.space	4 * 8				@ 8 registers
+__v7m_setup_stack_top:
-- 
1.8.2.rc3



From u.kleine-koenig at pengutronix.de  Wed Apr 17 12:14:58 2013
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Wed, 17 Apr 2013 18:14:58 +0200
Subject: [PATCH v11 2/3] ARM: ARMv7-M: Add support for exception handling
In-Reply-To: <1366215299-31969-1-git-send-email-u.kleine-koenig@pengutronix.de>
References: <1366215299-31969-1-git-send-email-u.kleine-koenig@pengutronix.de>
Message-ID: <1366215299-31969-3-git-send-email-u.kleine-koenig@pengutronix.de>

This patch implements the exception handling for the ARMv7-M
architecture (pretty different from the A or R profiles).

It bases on work done earlier by Catalin for 2.6.33 but was nearly
completely rewritten to use a pt_regs layout compatible to the A
profile.

Signed-off-by: Catalin Marinas <catalin.marinas at arm.com>
Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---

Notes:
    Changes since v9, sent with
    Message-id:1363901310-9474-3-git-send-email-u.kleine-koenig at pengutronix.de:
    
     - s/V7M_xPSR_FPALIGN/V7M_xPSR_FRAMEPTRALIGN/
     - expand comments
     - drop XXX item about clrex
     - make 0x1ff a #define
     - followup changes for changes in previous
    
    Changes since v10, sent with
    Message-id:1364381692-7955-3-git-send-email-u.kleine-koenig at pengutronix.de:
    
     - Adaptions for changes in the irq-nvic driver

 arch/arm/kernel/entry-common.S |   4 ++
 arch/arm/kernel/entry-header.S | 124 +++++++++++++++++++++++++++++++++++
 arch/arm/kernel/entry-v7m.S    | 143 +++++++++++++++++++++++++++++++++++++++++
 3 files changed, 271 insertions(+)
 create mode 100644 arch/arm/kernel/entry-v7m.S

diff --git a/arch/arm/kernel/entry-common.S b/arch/arm/kernel/entry-common.S
index 3248cde..c45e002 100644
--- a/arch/arm/kernel/entry-common.S
+++ b/arch/arm/kernel/entry-common.S
@@ -339,6 +339,9 @@ ENDPROC(ftrace_stub)
 
 	.align	5
 ENTRY(vector_swi)
+#ifdef CONFIG_CPU_V7M
+	v7m_exception_entry
+#else
 	sub	sp, sp, #S_FRAME_SIZE
 	stmia	sp, {r0 - r12}			@ Calling r0 - r12
  ARM(	add	r8, sp, #S_PC		)
@@ -349,6 +352,7 @@ ENTRY(vector_swi)
 	str	lr, [sp, #S_PC]			@ Save calling PC
 	str	r8, [sp, #S_PSR]		@ Save CPSR
 	str	r0, [sp, #S_OLD_R0]		@ Save OLD_R0
+#endif
 	zero_fp
 
 	/*
diff --git a/arch/arm/kernel/entry-header.S b/arch/arm/kernel/entry-header.S
index 9a8531e..b02e139 100644
--- a/arch/arm/kernel/entry-header.S
+++ b/arch/arm/kernel/entry-header.S
@@ -5,6 +5,7 @@
 #include <asm/asm-offsets.h>
 #include <asm/errno.h>
 #include <asm/thread_info.h>
+#include <asm/v7m.h>
 
 @ Bad Abort numbers
 @ -----------------
@@ -44,6 +45,116 @@
 #endif
 	.endm
 
+#ifdef CONFIG_CPU_V7M
+/*
+ * ARMv7-M exception entry/exit macros.
+ *
+ * xPSR, ReturnAddress(), LR (R14), R12, R3, R2, R1, and R0 are
+ * automatically saved on the current stack (32 words) before
+ * switching to the exception stack (SP_main).
+ *
+ * If exception is taken while in user mode, SP_main is
+ * empty. Otherwise, SP_main is aligned to 64 bit automatically
+ * (CCR.STKALIGN set).
+ *
+ * Linux assumes that the interrupts are disabled when entering an
+ * exception handler and it may BUG if this is not the case. Interrupts
+ * are disabled during entry and reenabled in the exit macro.
+ *
+ * v7m_exception_slow_exit is used when returning from SVC or PendSV.
+ * When returning to kernel mode, we don't return from exception.
+ */
+	.macro	v7m_exception_entry
+	@ determine the location of the registers saved by the core during
+	@ exception entry. Depending on the mode the cpu was in when the
+	@ exception happend that is either on the main or the process stack.
+	@ Bit 2 of EXC_RETURN stored in the lr register specifies which stack
+	@ was used.
+	tst	lr, #EXC_RET_STACK_MASK
+	mrsne	r12, psp
+	moveq	r12, sp
+
+	@ we cannot rely on r0-r3 and r12 matching the value saved in the
+	@ exception frame because of tail-chaining. So these have to be
+	@ reloaded.
+	ldmia	r12!, {r0-r3}
+
+	@ Linux expects to have irqs off. Do it here before taking stack space
+	cpsid	i
+
+	sub	sp, #S_FRAME_SIZE-S_IP
+	stmdb	sp!, {r0-r11}
+
+	@ load saved r12, lr, return address and xPSR.
+	@ r0-r7 are used for signals and never touched from now on. Clobbering
+	@ r8-r12 is OK.
+	mov	r9, r12
+	ldmia	r9!, {r8, r10-r12}
+
+	@ calculate the original stack pointer value.
+	@ r9 currently points to the memory location just above the auto saved
+	@ xPSR.
+	@ The cpu might automatically 8-byte align the stack. Bit 9
+	@ of the saved xPSR specifies if stack aligning took place. In this case
+	@ another 32-bit value is included in the stack.
+
+	tst	r12, V7M_xPSR_FRAMEPTRALIGN
+	addne	r9, r9, #4
+
+	@ store saved r12 using str to have a register to hold the base for stm
+	str	r8, [sp, #S_IP]
+	add	r8, sp, #S_SP
+	@ store r13-r15, xPSR
+	stmia	r8!, {r9-r12}
+	@ store old_r0
+	str	r0, [r8]
+	.endm
+
+        /*
+	 * PENDSV and SVCALL are configured to have the same exception
+	 * priorities. As a kernel thread runs at SVCALL execution priority it
+	 * can never be preempted and so we will never have to return to a
+	 * kernel thread here.
+         */
+	.macro	v7m_exception_slow_exit ret_r0
+	cpsid	i
+	ldr	lr, =EXC_RET_THREADMODE_PROCESSSTACK
+
+	@ read original r12, sp, lr, pc and xPSR
+	add	r12, sp, #S_IP
+	ldmia	r12, {r1-r5}
+
+	@ an exception frame is always 8-byte aligned. To tell the hardware if
+	@ the sp to be restored is aligned or not set bit 9 of the saved xPSR
+	@ accordingly.
+	tst	r2, #4
+	subne	r2, r2, #4
+	orrne	r5, V7M_xPSR_FRAMEPTRALIGN
+	biceq	r5, V7M_xPSR_FRAMEPTRALIGN
+
+	@ write basic exception frame
+	stmdb	r2!, {r1, r3-r5}
+	ldmia	sp, {r1, r3-r5}
+	.if	\ret_r0
+	stmdb	r2!, {r0, r3-r5}
+	.else
+	stmdb	r2!, {r1, r3-r5}
+	.endif
+
+	@ restore process sp
+	msr	psp, r2
+
+	@ restore original r4-r11
+	ldmia	sp!, {r0-r11}
+
+	@ restore main sp
+	add	sp, sp, #S_FRAME_SIZE-S_IP
+
+	cpsie	i
+	bx	lr
+	.endm
+#endif	/* CONFIG_CPU_V7M */
+
 	@
 	@ Store/load the USER SP and LR registers by switching to the SYS
 	@ mode. Useful in Thumb-2 mode where "stm/ldm rd, {sp, lr}^" is not
@@ -131,6 +242,18 @@
 	rfeia	sp!
 	.endm
 
+#ifdef CONFIG_CPU_V7M
+	/*
+	 * Note we don't need to do clrex here as clearing the local monitor is
+	 * part of each exception entry and exit sequence.
+	 */
+	.macro	restore_user_regs, fast = 0, offset = 0
+	.if	\offset
+	add	sp, #\offset
+	.endif
+	v7m_exception_slow_exit ret_r0 = \fast
+	.endm
+#else	/* ifdef CONFIG_CPU_V7M */
 	.macro	restore_user_regs, fast = 0, offset = 0
 	clrex					@ clear the exclusive monitor
 	mov	r2, sp
@@ -147,6 +270,7 @@
 	add	sp, sp, #S_FRAME_SIZE - S_SP
 	movs	pc, lr				@ return & move spsr_svc into cpsr
 	.endm
+#endif	/* ifdef CONFIG_CPU_V7M / else */
 
 	.macro	get_thread_info, rd
 	mov	\rd, sp
diff --git a/arch/arm/kernel/entry-v7m.S b/arch/arm/kernel/entry-v7m.S
new file mode 100644
index 0000000..e00621f
--- /dev/null
+++ b/arch/arm/kernel/entry-v7m.S
@@ -0,0 +1,143 @@
+/*
+ * linux/arch/arm/kernel/entry-v7m.S
+ *
+ * Copyright (C) 2008 ARM Ltd.
+ *
+ * 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.
+ *
+ * Low-level vector interface routines for the ARMv7-M architecture
+ */
+#include <asm/memory.h>
+#include <asm/glue.h>
+#include <asm/thread_notify.h>
+#include <asm/v7m.h>
+
+#include <mach/entry-macro.S>
+
+#include "entry-header.S"
+
+#ifdef CONFIG_TRACE_IRQFLAGS
+#error "CONFIG_TRACE_IRQFLAGS not supported on the current ARMv7M implementation"
+#endif
+
+__invalid_entry:
+	v7m_exception_entry
+	adr	r0, strerr
+	mrs	r1, ipsr
+	mov	r2, lr
+	bl	printk
+	mov	r0, sp
+	bl	show_regs
+1:	b	1b
+ENDPROC(__invalid_entry)
+
+strerr:	.asciz	"\nUnhandled exception: IPSR = %08lx LR = %08lx\n"
+
+	.align	2
+__irq_entry:
+	v7m_exception_entry
+
+	@
+	@ Invoke the IRQ handler
+	@
+	mrs	r0, ipsr
+	ldr	r1, =V7M_xPSR_EXCEPTIONNO
+	and	r0, r1
+	sub	r0, #16
+	mov	r1, sp
+	stmdb	sp!, {lr}
+	@ routine called with r0 = irq number, r1 = struct pt_regs *
+	bl	nvic_do_IRQ
+
+	pop	{lr}
+	@
+	@ Check for any pending work if returning to user
+	@
+	ldr	r1, =BASEADDR_V7M_SCB
+	ldr	r0, [r1, V7M_SCB_ICSR]
+	tst	r0, V7M_SCB_ICSR_RETTOBASE
+	beq	2f
+
+	get_thread_info tsk
+	ldr	r2, [tsk, #TI_FLAGS]
+	tst	r2, #_TIF_WORK_MASK
+	beq	2f			@ no work pending
+	mov	r0, #V7M_SCB_ICSR_PENDSVSET
+	str	r0, [r1, V7M_SCB_ICSR]	@ raise PendSV
+
+2:
+	@ registers r0-r3 and r12 are automatically restored on exception
+	@ return. r4-r7 were not clobbered in v7m_exception_entry so for
+	@ correctness they don't need to be restored. So only r8-r11 must be
+	@ restored here. The easiest way to do so is to restore r0-r7, too.
+	ldmia	sp!, {r0-r11}
+	add	sp, #S_FRAME_SIZE-S_IP
+	cpsie	i
+	bx	lr
+ENDPROC(__irq_entry)
+
+__pendsv_entry:
+	v7m_exception_entry
+
+	ldr	r1, =BASEADDR_V7M_SCB
+	mov	r0, #V7M_SCB_ICSR_PENDSVCLR
+	str	r0, [r1, V7M_SCB_ICSR]	@ clear PendSV
+
+	@ execute the pending work, including reschedule
+	get_thread_info tsk
+	mov	why, #0
+	b	ret_to_user
+ENDPROC(__pendsv_entry)
+
+/*
+ * Register switch for ARMv7-M processors.
+ * r0 = previous task_struct, r1 = previous thread_info, r2 = next thread_info
+ * previous and next are guaranteed not to be the same.
+ */
+ENTRY(__switch_to)
+	.fnstart
+	.cantunwind
+	add	ip, r1, #TI_CPU_SAVE
+	stmia	ip!, {r4 - r11}		@ Store most regs on stack
+	str	sp, [ip], #4
+	str	lr, [ip], #4
+	mov	r5, r0
+	add	r4, r2, #TI_CPU_SAVE
+	ldr	r0, =thread_notify_head
+	mov	r1, #THREAD_NOTIFY_SWITCH
+	bl	atomic_notifier_call_chain
+	mov	ip, r4
+	mov	r0, r5
+	ldmia	ip!, {r4 - r11}		@ Load all regs saved previously
+	ldr	sp, [ip]
+	ldr	pc, [ip, #4]!
+	.fnend
+ENDPROC(__switch_to)
+
+	.data
+	.align	8
+/*
+ * Vector table (64 words => 256 bytes natural alignment)
+ */
+ENTRY(vector_table)
+	.long	0			@ 0 - Reset stack pointer
+	.long	__invalid_entry		@ 1 - Reset
+	.long	__invalid_entry		@ 2 - NMI
+	.long	__invalid_entry		@ 3 - HardFault
+	.long	__invalid_entry		@ 4 - MemManage
+	.long	__invalid_entry		@ 5 - BusFault
+	.long	__invalid_entry		@ 6 - UsageFault
+	.long	__invalid_entry		@ 7 - Reserved
+	.long	__invalid_entry		@ 8 - Reserved
+	.long	__invalid_entry		@ 9 - Reserved
+	.long	__invalid_entry		@ 10 - Reserved
+	.long	vector_swi		@ 11 - SVCall
+	.long	__invalid_entry		@ 12 - Debug Monitor
+	.long	__invalid_entry		@ 13 - Reserved
+	.long	__pendsv_entry		@ 14 - PendSV
+	.long	__invalid_entry		@ 15 - SysTick
+	.rept	64 - 16
+	.long	__irq_entry		@ 16..64 - External Interrupts
+	.endr
-- 
1.8.2.rc3



From u.kleine-koenig at pengutronix.de  Wed Apr 17 12:14:59 2013
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Wed, 17 Apr 2013 18:14:59 +0200
Subject: [PATCH v11 3/3] ARM: ARMv7-M: Allow the building of new kernel port
In-Reply-To: <1366215299-31969-1-git-send-email-u.kleine-koenig@pengutronix.de>
References: <1366215299-31969-1-git-send-email-u.kleine-koenig@pengutronix.de>
Message-ID: <1366215299-31969-4-git-send-email-u.kleine-koenig@pengutronix.de>

This patch modifies the required Kconfig and Makefile files to allow the
building of kernel for Cortex-M3.

Signed-off-by: Catalin Marinas <catalin.marinas at arm.com>
Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---

Notes:
    Changes since v9, sent with
    Message-id:1363901310-9474-4-git-send-email-u.kleine-koenig at pengutronix.de:
    
     - drop selecting CPU_CACHE_VIPT
    
    No changes since v10, sent with
    Message-id:1364381692-7955-4-git-send-email-u.kleine-koenig at pengutronix.de

 arch/arm/Kconfig         |  4 ++--
 arch/arm/Kconfig-nommu   |  2 +-
 arch/arm/Makefile        |  1 +
 arch/arm/kernel/Makefile |  8 +++++++-
 arch/arm/mm/Kconfig      | 21 ++++++++++++++++++++-
 arch/arm/mm/Makefile     |  2 ++
 6 files changed, 33 insertions(+), 5 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index dedf02b..7c8c607 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -9,7 +9,7 @@ config ARM
 	select BUILDTIME_EXTABLE_SORT if MMU
 	select CPU_PM if (SUSPEND || CPU_IDLE)
 	select DCACHE_WORD_ACCESS if (CPU_V6 || CPU_V6K || CPU_V7) && !CPU_BIG_ENDIAN && MMU
-	select GENERIC_ATOMIC64 if (CPU_V6 || !CPU_32v6K || !AEABI)
+	select GENERIC_ATOMIC64 if (CPU_V7M || CPU_V6 || !CPU_32v6K || !AEABI)
 	select GENERIC_CLOCKEVENTS_BROADCAST if SMP
 	select GENERIC_IRQ_PROBE
 	select GENERIC_IRQ_SHOW
@@ -1685,7 +1685,7 @@ config SCHED_HRTICK
 
 config THUMB2_KERNEL
 	bool "Compile the kernel in Thumb-2 mode" if !CPU_THUMBONLY
-	depends on CPU_V7 && !CPU_V6 && !CPU_V6K
+	depends on (CPU_V7 || CPU_V7M) && !CPU_V6 && !CPU_V6K
 	default y if CPU_THUMBONLY
 	select AEABI
 	select ARM_ASM_UNIFIED
diff --git a/arch/arm/Kconfig-nommu b/arch/arm/Kconfig-nommu
index 2cef8e1..c859495 100644
--- a/arch/arm/Kconfig-nommu
+++ b/arch/arm/Kconfig-nommu
@@ -28,7 +28,7 @@ config FLASH_SIZE
 config PROCESSOR_ID
 	hex 'Hard wire the processor ID'
 	default 0x00007700
-	depends on !CPU_CP15
+	depends on !(CPU_CP15 || CPU_V7M)
 	help
 	  If processor has no CP15 register, this processor ID is
 	  used instead of the auto-probing which utilizes the register.
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index ee4605f..f11b8da 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -59,6 +59,7 @@ comma = ,
 # Note that GCC does not numerically define an architecture version
 # macro, but instead defines a whole series of macros which makes
 # testing for a specific architecture or later rather impossible.
+arch-$(CONFIG_CPU_32v7M)	:=-D__LINUX_ARM_ARCH__=7 -march=armv7-m -Wa,-march=armv7-m
 arch-$(CONFIG_CPU_32v7)		:=-D__LINUX_ARM_ARCH__=7 $(call cc-option,-march=armv7-a,-march=armv5t -Wa$(comma)-march=armv7-a)
 arch-$(CONFIG_CPU_32v6)		:=-D__LINUX_ARM_ARCH__=6 $(call cc-option,-march=armv6,-march=armv5t -Wa$(comma)-march=armv6)
 # Only override the compiler option if ARMv6. The ARMv6K extensions are
diff --git a/arch/arm/kernel/Makefile b/arch/arm/kernel/Makefile
index 5f3338e..00d703c 100644
--- a/arch/arm/kernel/Makefile
+++ b/arch/arm/kernel/Makefile
@@ -15,7 +15,7 @@ CFLAGS_REMOVE_return_address.o = -pg
 
 # Object file lists.
 
-obj-y		:= elf.o entry-armv.o entry-common.o irq.o opcodes.o \
+obj-y		:= elf.o entry-common.o irq.o opcodes.o \
 		   process.o ptrace.o return_address.o sched_clock.o \
 		   setup.o signal.o stacktrace.o sys_arm.o time.o traps.o
 
@@ -23,6 +23,12 @@ obj-$(CONFIG_ATAGS)		+= atags_parse.o
 obj-$(CONFIG_ATAGS_PROC)	+= atags_proc.o
 obj-$(CONFIG_DEPRECATED_PARAM_STRUCT) += atags_compat.o
 
+ifeq ($(CONFIG_CPU_V7M),y)
+obj-y		+= entry-v7m.o
+else
+obj-y		+= entry-armv.o
+endif
+
 obj-$(CONFIG_OC_ETM)		+= etm.o
 obj-$(CONFIG_CPU_IDLE)		+= cpuidle.o
 obj-$(CONFIG_ISA_DMA_API)	+= dma.o
diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
index cb812a1..cce78b0 100644
--- a/arch/arm/mm/Kconfig
+++ b/arch/arm/mm/Kconfig
@@ -397,6 +397,15 @@ config CPU_V7
 	select CPU_PABRT_V7
 	select CPU_TLB_V7 if MMU
 
+# ARMv7M
+config CPU_V7M
+	bool
+	select CPU_32v7M
+	select CPU_ABRT_NOMMU
+	select CPU_CACHE_NOP
+	select CPU_PABRT_LEGACY
+	select CPU_THUMBONLY
+
 config CPU_THUMBONLY
 	bool
 	# There are no CPUs available with MMU that don't implement an ARM ISA:
@@ -441,6 +450,9 @@ config CPU_32v6K
 config CPU_32v7
 	bool
 
+config CPU_32v7M
+	bool
+
 # The abort model
 config CPU_ABRT_NOMMU
 	bool
@@ -494,6 +506,9 @@ config CPU_CACHE_V6
 config CPU_CACHE_V7
 	bool
 
+config CPU_CACHE_NOP
+	bool
+
 config CPU_CACHE_VIVT
 	bool
 
@@ -616,7 +631,11 @@ config ARCH_DMA_ADDR_T_64BIT
 
 config ARM_THUMB
 	bool "Support Thumb user binaries" if !CPU_THUMBONLY
-	depends on CPU_ARM720T || CPU_ARM740T || CPU_ARM920T || CPU_ARM922T || CPU_ARM925T || CPU_ARM926T || CPU_ARM940T || CPU_ARM946E || CPU_ARM1020 || CPU_ARM1020E || CPU_ARM1022 || CPU_ARM1026 || CPU_XSCALE || CPU_XSC3 || CPU_MOHAWK || CPU_V6 || CPU_V6K || CPU_V7 || CPU_FEROCEON
+	depends on CPU_ARM720T || CPU_ARM740T || CPU_ARM920T || CPU_ARM922T || \
+		CPU_ARM925T || CPU_ARM926T || CPU_ARM940T || CPU_ARM946E || \
+		CPU_ARM1020 || CPU_ARM1020E || CPU_ARM1022 || CPU_ARM1026 || \
+		CPU_XSCALE || CPU_XSC3 || CPU_MOHAWK || CPU_V6 || CPU_V6K || \
+		CPU_V7 || CPU_FEROCEON || CPU_V7M
 	default y
 	help
 	  Say Y if you want to include kernel support for running user space
diff --git a/arch/arm/mm/Makefile b/arch/arm/mm/Makefile
index 4e333fa..317b575 100644
--- a/arch/arm/mm/Makefile
+++ b/arch/arm/mm/Makefile
@@ -40,6 +40,7 @@ obj-$(CONFIG_CPU_CACHE_V4WB)	+= cache-v4wb.o
 obj-$(CONFIG_CPU_CACHE_V6)	+= cache-v6.o
 obj-$(CONFIG_CPU_CACHE_V7)	+= cache-v7.o
 obj-$(CONFIG_CPU_CACHE_FA)	+= cache-fa.o
+obj-$(CONFIG_CPU_CACHE_NOP)	+= cache-nop.o
 
 AFLAGS_cache-v6.o	:=-Wa,-march=armv6
 AFLAGS_cache-v7.o	:=-Wa,-march=armv7-a
@@ -88,6 +89,7 @@ obj-$(CONFIG_CPU_FEROCEON)	+= proc-feroceon.o
 obj-$(CONFIG_CPU_V6)		+= proc-v6.o
 obj-$(CONFIG_CPU_V6K)		+= proc-v6.o
 obj-$(CONFIG_CPU_V7)		+= proc-v7.o
+obj-$(CONFIG_CPU_V7M)		+= proc-v7m.o
 
 AFLAGS_proc-v6.o	:=-Wa,-march=armv6
 AFLAGS_proc-v7.o	:=-Wa,-march=armv7-a
-- 
1.8.2.rc3



From grant.likely at secretlab.ca  Wed Apr 17 12:17:48 2013
From: grant.likely at secretlab.ca (Grant Likely)
Date: Wed, 17 Apr 2013 17:17:48 +0100
Subject: [PATCH v7 1/3] of/pci: Unify pci_process_bridge_OF_ranges from
 Microblaze and PowerPC
In-Reply-To: <20130417161036.GB27197@titan.lakedaemon.net>
References: <1366107508-12672-1-git-send-email-Andrew.Murray@arm.com>
 <1366107508-12672-2-git-send-email-Andrew.Murray@arm.com>
 <20130416103005.GB12726@arm.com>
 <20130417160015.777453E2B73@localhost>
 <20130417161036.GB27197@titan.lakedaemon.net>
Message-ID: <CACxGe6sNk=wNinTcMHbJa5o-56Tyh=0CnFSEW+Hk-ujpjeg2gQ@mail.gmail.com>

On Wed, Apr 17, 2013 at 5:10 PM, Jason Cooper <jason at lakedaemon.net> wrote:
> On Wed, Apr 17, 2013 at 05:00:15PM +0100, Grant Likely wrote:
>> On Tue, 16 Apr 2013 11:30:06 +0100, Andrew Murray <andrew.murray at arm.com> wrote:
>> > On Tue, Apr 16, 2013 at 11:18:26AM +0100, Andrew Murray wrote:
>> > > The pci_process_bridge_OF_ranges function, used to parse the "ranges"
>> > > property of a PCI host device, is found in both Microblaze and PowerPC
>> > > architectures. These implementations are nearly identical. This patch
>> > > moves this common code to a common place.
>> > >
>> > > Signed-off-by: Andrew Murray <Andrew.Murray at arm.com>
>> > > Signed-off-by: Liviu Dudau <Liviu.Dudau at arm.com>
>> > > Reviewed-by: Rob Herring <rob.herring at calxeda.com>
>> > > Tested-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
>> > > Tested-by: Linus Walleij <linus.walleij at linaro.org>
>> > > Acked-by: Michal Simek <monstr at monstr.eu>
>> > > ---
>> > >  arch/microblaze/include/asm/pci-bridge.h |    5 +-
>> > >  arch/microblaze/pci/pci-common.c         |  192 ----------------------------
>> > >  arch/powerpc/include/asm/pci-bridge.h    |    5 +-
>> > >  arch/powerpc/kernel/pci-common.c         |  192 ----------------------------
>> >
>> > Is there anyone on linuxppc-dev/linux-mips that can help test this patchset?
>> >
>> > I've tested that it builds on powerpc with a variety of configs (some which
>> > include fsl_pci.c implementation). Though I don't have hardware to verify that
>> > it works.
>> >
>> > I haven't tested this builds or runs on MIPS.
>> >
>> > You shouldn't see any difference in behaviour or new warnings and PCI devices
>> > should continue to operate as before.
>>
>> I've got through a line-by-line comparison between powerpc, microblaze,
>> and then new code. The differences are purely cosmetic, so I have
>> absolutely no concerns about this patch. I've applied it to my tree.
>
> oops.  Due to the number of dependencies the mvebu-pcie series has (this
> being one of them, we (arm-soc/mvebu) asked if we could take this
> through our tree.  Rob Herring agreed to this several days ago.  Is this
> a problem for you?
>
> It would truly (dogs and cats living together) upset the apple cart for
> us at this stage to pipe these through a different tree...

Not a problem at all. I'll drop it.

g.


From martinez.javier at gmail.com  Wed Apr 17 12:18:01 2013
From: martinez.javier at gmail.com (Javier Martinez Canillas)
Date: Wed, 17 Apr 2013 18:18:01 +0200
Subject: [PATCH 3/5] gpio/omap: Add DT support to GPIO driver
In-Reply-To: <516EA937.8060201@ti.com>
References: <1329321854-24490-1-git-send-email-b-cousson@ti.com>
 <CACRpkdYbs4-uudpRUY8e+7icYYkZrfM0kReP3pLL5DMiURJ4dg@mail.gmail.com>
 <5165CB9D.1090202@wwwdotorg.org>
 <CACRpkdYirFNqmGhA4K9CL4ve4NYhs8Rd3SFt1iwW9vHBkrcz8g@mail.gmail.com>
 <51671D7B.5060303@wwwdotorg.org>
 <CACRpkdbf32Ef77GmXk9id9+RRjcDRTr7S+F4nznoeZU8y=BT_Q@mail.gmail.com>
 <51673D70.3010503@wwwdotorg.org>
 <CAAwP0s0e2x33jZQhFRY+Hoo61SFqYKRgWk=1mL2+DNxSDJHz+A@mail.gmail.com>
 <CACRpkda4h+qXTvsirPAS7E7sjXhMLE62q=VDy53W8UchsYjbNg@mail.gmail.com>
 <516C31C3.9040505@wwwdotorg.org> <516C7C43.3040105@wwwdotorg.org>
 <516C8760.2050500@ti.com> <516D9B05.1000501@wwwdotorg.org>
 <516DA60A.5070000@ti.com> <516DCCA8.3070108@wwwdotorg.org>
 <516DDB4D.9020500@ti.com>
 <CAAwP0s0-VNUoeSKaGbvoDeD7m7kZRdp5rCJ7iVpFoFAaQtXcmQ@mail.gmail.com>
 <516E022F.5050708@ti.com>
 <CAAwP0s2M2pnSydyDvh_rejFO=w8bCo4WE5PkxrYuk0HQDixc-Q@mail.gmail.com>
 <516EA2B1.3070201@ti.com>
 <CAAwP0s2DsJAWuXWvPAkzCT0T0AG_OvMEw2sADW6LqSi1Ofd_Zw@mail.gmail.com>
 <516EA937.8060201@ti.com>
Message-ID: <CAAwP0s3xqfkT4bA9A_7ZWZ2C5dXYp8NunhhRp33he-uK-iW9hw@mail.gmail.com>

On Wed, Apr 17, 2013 at 3:52 PM, Jon Hunter <jon-hunter at ti.com> wrote:
>
> On 04/17/2013 08:42 AM, Javier Martinez Canillas wrote:
>> On Wed, Apr 17, 2013 at 3:25 PM, Jon Hunter <jon-hunter at ti.com> wrote:
>>>
>>> On 04/17/2013 02:55 AM, Javier Martinez Canillas wrote:
>>>
>>> ...
>>>
>>>> There are so many patches flying around in this thread that I missed it :-)
>>>>
>>>> Sorry about that...
>>>
>>> No problem.
>>>
>>>>> I was trying to see if we could find a common solution that everyone
>>>>> could use as it seems that ideally we should all be requesting the gpio.
>>>>>
>>>>> Cheers
>>>>> Jon
>>>>>
>>>>> [1] http://marc.info/?l=linux-arm-kernel&m=136606204823845&w=1
>>>>
>>>> btw, I shared the latest patch with only build testing it, but today I
>>>> gave a try and I found a problem with this approach. The .xlate
>>>> function is being called twice for each GPIO-IRQ so the first time
>>>> gpio_request_one() succeeds but the second time it fails returning
>>>> -EBUSY.
>>>
>>> I tried it and I did not see that. I don't see the below warning either.
>>>
>>
>> weird, I wonder what's different here.
>
> I am testing on an omap4-sdp which uses a spi based ethernet device.
> However, I could try with the omap3430-sdp which uses gpmc.
>
> Cheers
> Jon

Hi Jon,

I just created a new branch using your omap-daily-testing as a base
and cherry-picked all the required patches and the .xlate function is
working correctly. I don't see the WARN anymore neither is called
twice.

Sorry for the noise..

Best regards,
Javier


From swarren at wwwdotorg.org  Wed Apr 17 12:22:02 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Wed, 17 Apr 2013 10:22:02 -0600
Subject: [PATCH 3/3] ARM: tegra: make sure the pointer on 4 byte align
 when THUMB2_KERNEL enabled
In-Reply-To: <20130417102957.GA2249@linaro.org>
References: <1366066255-18192-1-git-send-email-swarren@wwwdotorg.org>
 <1366066255-18192-3-git-send-email-swarren@wwwdotorg.org>
 <20130416141252.GA2229@linaro.org> <516D7A3B.9030404@wwwdotorg.org>
 <20130417102957.GA2249@linaro.org>
Message-ID: <516ECC2A.1060308@wwwdotorg.org>

On 04/17/2013 04:30 AM, Dave Martin wrote:
> On Tue, Apr 16, 2013 at 10:20:11AM -0600, Stephen Warren wrote:
>> On 04/16/2013 08:13 AM, Dave Martin wrote:
>>> On Mon, Apr 15, 2013 at 04:50:55PM -0600, Stephen Warren wrote:
>>>> From: Joseph Lo <josephl at nvidia.com>
>>>>
>>>> When building kernel with CONFIG_THUMB2_KERNEL, the data pointer in the
>>>> assembly may not on the 4 byte alignment. Then causing a data abort when
>>>> accessing the pointer. This patch add a ".align" flag in the head of the
>>>> pointer. And always using 32-bit ADR Thumb instruction to make sure it
>>>> won't build failure.
>>>>
>>>> Signed-off-by: Joseph Lo <josephl at nvidia.com>
>>>> Signed-off-by: Stephen Warren <swarren at nvidia.com>
>>>> ---
>>>>  arch/arm/mach-tegra/reset-handler.S |    1 +
>>>>  arch/arm/mach-tegra/sleep.h         |    3 ++-
>>>>  2 files changed, 3 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/arch/arm/mach-tegra/reset-handler.S b/arch/arm/mach-tegra/reset-handler.S
>>>> index e6de88a..519a8c5 100644
>>>> --- a/arch/arm/mach-tegra/reset-handler.S
>>>> +++ b/arch/arm/mach-tegra/reset-handler.S
>>>> @@ -83,6 +83,7 @@ ENDPROC(tegra_resume)
>>>>  
>>>>  #ifdef CONFIG_CACHE_L2X0
>>>>  	.globl	l2x0_saved_regs_addr
>>>> +	.align
>>>>  l2x0_saved_regs_addr:
>>>>  	.long	0
>>>>  #endif
>>>> diff --git a/arch/arm/mach-tegra/sleep.h b/arch/arm/mach-tegra/sleep.h
>>>> index 4ffae54..8e9b6af 100644
>>>> --- a/arch/arm/mach-tegra/sleep.h
>>>> +++ b/arch/arm/mach-tegra/sleep.h
>>>> @@ -92,7 +92,8 @@
>>>>  
>>>>  #ifdef CONFIG_CACHE_L2X0
>>>>  .macro l2_cache_resume, tmp1, tmp2, tmp3, phys_l2x0_saved_regs
>>>> -	adr	\tmp1, \phys_l2x0_saved_regs
>>>> + ARM(	adr	\tmp1, \phys_l2x0_saved_regs )
>>>> + THUMB(	adr.w	\tmp1, \phys_l2x0_saved_regs )
>>>
>>> Can you give an example of the assembler error you get without this?
>>
>> arch/arm/mach-tegra/reset-handler.S: Assembler messages:
>> arch/arm/mach-tegra/reset-handler.S:78: Error: invalid immediate for
>> address calculation (value = 0x00000004)
> 
> The immediate in the 16-bit form of ADR is alignment-sensitive, and
> can't address anything that's not on a word boundary.  What if you just
> have the .align, without adr.w?
> 
>> This is with gcc-4.5.3, as:
>> GNU assembler (crosstool-NG hg_unknown at 20110628.165246) 2.20.1.20100303
>>
>>> The target symbol is local and the assembler can see where it is,
>>> so it should choose the correct variant for the adr instruction
>>> with no need for the ".w" suffix.
>>>
>>> If not, it could mean that there is a bug in the version of the
>>> assembler you're using.
>>
>> True. Switching to the Ubuntu-packaged ARM cross-compiler that ships
>> with Ubuntu 12.10, I do not see this problem.
>>
>> Still, many people probably still use older compilers.
>>
>>> If it's definitely needed, you can append a Thumb-only .w suffix with
>>>
>>> 	W(adr)	\tmp1, \phys_l2x0_saved_regs
>>>
>>> ...which is slightly neater.
>>
>> Yes, that certainly works too, even without the .align change in
>> reset-handler.S.
> 
> Sure, although the unaligned access is not such a good idea anyway.
> 
> Keeping the adr fix is harmless, I just wanted to understand why it's
> needed.

With just the following, and no adr.w:

> diff --git a/arch/arm/mach-tegra/reset-handler.S b/arch/arm/mach-tegra/reset-handler.S
> index e6de88a..519a8c5 100644
> --- a/arch/arm/mach-tegra/reset-handler.S
> +++ b/arch/arm/mach-tegra/reset-handler.S
> @@ -83,6 +83,7 @@ ENDPROC(tegra_resume)
>  
>  #ifdef CONFIG_CACHE_L2X0
>         .globl  l2x0_saved_regs_addr
> +       .align
>  l2x0_saved_regs_addr:
>         .long   0
>  #endif

I still get:

> arch/arm/mach-tegra/reset-handler.S: Assembler messages:
> arch/arm/mach-tegra/reset-handler.S:78: Error: invalid immediate for address calculation (value = 0x00000004)

That's with GNU assembler (crosstool-NG hg_unknown at 20110628.165246)
2.20.1.20100303.

BTW, I'm on vacation for the next 2 weeks starting this afternoon.
Hopefully Joseph can keep this thread alive while I'm gone if needed.


From jason at lakedaemon.net  Wed Apr 17 12:22:23 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Wed, 17 Apr 2013 12:22:23 -0400
Subject: [PATCH v7 1/3] of/pci: Unify pci_process_bridge_OF_ranges from
 Microblaze and PowerPC
In-Reply-To: <CACxGe6sNk=wNinTcMHbJa5o-56Tyh=0CnFSEW+Hk-ujpjeg2gQ@mail.gmail.com>
References: <1366107508-12672-1-git-send-email-Andrew.Murray@arm.com>
 <1366107508-12672-2-git-send-email-Andrew.Murray@arm.com>
 <20130416103005.GB12726@arm.com>
 <20130417160015.777453E2B73@localhost>
 <20130417161036.GB27197@titan.lakedaemon.net>
 <CACxGe6sNk=wNinTcMHbJa5o-56Tyh=0CnFSEW+Hk-ujpjeg2gQ@mail.gmail.com>
Message-ID: <20130417162223.GC27197@titan.lakedaemon.net>

On Wed, Apr 17, 2013 at 05:17:48PM +0100, Grant Likely wrote:
> On Wed, Apr 17, 2013 at 5:10 PM, Jason Cooper <jason at lakedaemon.net> wrote:
> > On Wed, Apr 17, 2013 at 05:00:15PM +0100, Grant Likely wrote:
> >> On Tue, 16 Apr 2013 11:30:06 +0100, Andrew Murray <andrew.murray at arm.com> wrote:
> >> > On Tue, Apr 16, 2013 at 11:18:26AM +0100, Andrew Murray wrote:
> >> > > The pci_process_bridge_OF_ranges function, used to parse the "ranges"
> >> > > property of a PCI host device, is found in both Microblaze and PowerPC
> >> > > architectures. These implementations are nearly identical. This patch
> >> > > moves this common code to a common place.
> >> > >
> >> > > Signed-off-by: Andrew Murray <Andrew.Murray at arm.com>
> >> > > Signed-off-by: Liviu Dudau <Liviu.Dudau at arm.com>
> >> > > Reviewed-by: Rob Herring <rob.herring at calxeda.com>
> >> > > Tested-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> >> > > Tested-by: Linus Walleij <linus.walleij at linaro.org>
> >> > > Acked-by: Michal Simek <monstr at monstr.eu>
> >> > > ---
> >> > >  arch/microblaze/include/asm/pci-bridge.h |    5 +-
> >> > >  arch/microblaze/pci/pci-common.c         |  192 ----------------------------
> >> > >  arch/powerpc/include/asm/pci-bridge.h    |    5 +-
> >> > >  arch/powerpc/kernel/pci-common.c         |  192 ----------------------------
> >> >
> >> > Is there anyone on linuxppc-dev/linux-mips that can help test this patchset?
> >> >
> >> > I've tested that it builds on powerpc with a variety of configs (some which
> >> > include fsl_pci.c implementation). Though I don't have hardware to verify that
> >> > it works.
> >> >
> >> > I haven't tested this builds or runs on MIPS.
> >> >
> >> > You shouldn't see any difference in behaviour or new warnings and PCI devices
> >> > should continue to operate as before.
> >>
> >> I've got through a line-by-line comparison between powerpc, microblaze,
> >> and then new code. The differences are purely cosmetic, so I have
> >> absolutely no concerns about this patch. I've applied it to my tree.
> >
> > oops.  Due to the number of dependencies the mvebu-pcie series has (this
> > being one of them, we (arm-soc/mvebu) asked if we could take this
> > through our tree.  Rob Herring agreed to this several days ago.  Is this
> > a problem for you?
> >
> > It would truly (dogs and cats living together) upset the apple cart for
> > us at this stage to pipe these through a different tree...
> 
> Not a problem at all. I'll drop it.

Great!  Thanks.

Jason.


From swarren at wwwdotorg.org  Wed Apr 17 12:23:38 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Wed, 17 Apr 2013 10:23:38 -0600
Subject: [RFC PATCH 2/2] ARM: DT: kernel: DT cpu node bindings update
In-Reply-To: <alpine.LFD.2.03.1304171146530.17375@syhkavp.arg>
References: <1366042402-8987-1-git-send-email-lorenzo.pieralisi@arm.com>
 <1366042402-8987-3-git-send-email-lorenzo.pieralisi@arm.com>
 <516C544A.4090107@wwwdotorg.org>
 <20130417091457.GB5012@e106331-lin.cambridge.arm.com>
 <516EBC66.20508@wwwdotorg.org>
 <alpine.LFD.2.03.1304171146530.17375@syhkavp.arg>
Message-ID: <516ECC8A.2070508@wwwdotorg.org>

On 04/17/2013 10:02 AM, Nicolas Pitre wrote:
> On Wed, 17 Apr 2013, Stephen Warren wrote:
> 
>> On 04/17/2013 03:14 AM, Mark Rutland wrote:
>>> Hi Stephen,
>>>
>>>>> +	- enable-method
>>>>> +		Usage: required on ARM 64-bit systems, optional on ARM 32-bit
>>>>> +		       systems
>>>>> +		Value type: <string>
>>>>> +		Definition: On ARM 64-bit systems must be "spin-table" [1].
>>>>
>>>> Can that be an integer instead? with dtc+cpp support, that shouldn't
>>>> hurt the eyes too much any more.
>>>
>>> The "enable-method" property is described as a stringlist by ePAPR, and is
>>> currently in use on arm64 as such. It *must* remain a string(list) for arm64.
>>>
>>> Having it as an integer for arm is only going to cause us additional work,
>>> makes it impossible to share a common dt between 64bit and 32bit, and goes
>>> against the standard. I think it should be a stringlist for arm.
>>
>> OK, that's a great reason for this case.
>>
>> I hope we don't introduce any more standards that use strings, but that
>> may just be my personal preference...
> 
> I think in any standard, strings are far easier to deal with.  
> Especially with config stuff which is far from being performance 
> critical. Strings are much less prone to conflicts.  It is too easy to 
> "extend" a standard by assigning meanings to free numerical values just 
> to discover that someone else did use the same numbers for other 
> meanings.
> 
> In order to avoid this issue, a central authority has to be established 
> to assign numbers out while strings are fine without that most of the 
> time.

For DT, all strings or numbers must always be documented in the DT
binding, so there's no risk of conflict there.



From benh at kernel.crashing.org  Wed Apr 17 12:24:09 2013
From: benh at kernel.crashing.org (Benjamin Herrenschmidt)
Date: Wed, 17 Apr 2013 18:24:09 +0200
Subject: [RFC PATCH 2/2] ARM: DT: kernel: DT cpu node bindings update
In-Reply-To: <516EBC66.20508@wwwdotorg.org>
References: <1366042402-8987-1-git-send-email-lorenzo.pieralisi@arm.com>
 <1366042402-8987-3-git-send-email-lorenzo.pieralisi@arm.com>
 <516C544A.4090107@wwwdotorg.org>
 <20130417091457.GB5012@e106331-lin.cambridge.arm.com>
 <516EBC66.20508@wwwdotorg.org>
Message-ID: <1366215849.24994.70.camel@pasglop>

On Wed, 2013-04-17 at 09:14 -0600, Stephen Warren wrote:
> On 04/17/2013 03:14 AM, Mark Rutland wrote:
> > Hi Stephen,
> > 
> >>> +	- enable-method
> >>> +		Usage: required on ARM 64-bit systems, optional on ARM 32-bit
> >>> +		       systems
> >>> +		Value type: <string>
> >>> +		Definition: On ARM 64-bit systems must be "spin-table" [1].
> >>
> >> Can that be an integer instead? with dtc+cpp support, that shouldn't
> >> hurt the eyes too much any more.
> > 
> > The "enable-method" property is described as a stringlist by ePAPR, and is
> > currently in use on arm64 as such. It *must* remain a string(list) for arm64.
> > 
> > Having it as an integer for arm is only going to cause us additional work,
> > makes it impossible to share a common dt between 64bit and 32bit, and goes
> > against the standard. I think it should be a stringlist for arm.
> 
> OK, that's a great reason for this case.
> 
> I hope we don't introduce any more standards that use strings, but that
> may just be my personal preference...

I happen to have the exact opposite opinion :-)

Cheers,
Ben.




From nicolas.pitre at linaro.org  Wed Apr 17 12:36:08 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Wed, 17 Apr 2013 12:36:08 -0400 (EDT)
Subject: [RFC PATCH 2/2] ARM: DT: kernel: DT cpu node bindings update
In-Reply-To: <516ECC8A.2070508@wwwdotorg.org>
References: <1366042402-8987-1-git-send-email-lorenzo.pieralisi@arm.com>
 <1366042402-8987-3-git-send-email-lorenzo.pieralisi@arm.com>
 <516C544A.4090107@wwwdotorg.org>
 <20130417091457.GB5012@e106331-lin.cambridge.arm.com>
 <516EBC66.20508@wwwdotorg.org>
 <alpine.LFD.2.03.1304171146530.17375@syhkavp.arg>
 <516ECC8A.2070508@wwwdotorg.org>
Message-ID: <alpine.LFD.2.03.1304171231130.17375@syhkavp.arg>

On Wed, 17 Apr 2013, Stephen Warren wrote:

> On 04/17/2013 10:02 AM, Nicolas Pitre wrote:
> > On Wed, 17 Apr 2013, Stephen Warren wrote:
> > 
> >> On 04/17/2013 03:14 AM, Mark Rutland wrote:
> >>> Hi Stephen,
> >>>
> >>>>> +	- enable-method
> >>>>> +		Usage: required on ARM 64-bit systems, optional on ARM 32-bit
> >>>>> +		       systems
> >>>>> +		Value type: <string>
> >>>>> +		Definition: On ARM 64-bit systems must be "spin-table" [1].
> >>>>
> >>>> Can that be an integer instead? with dtc+cpp support, that shouldn't
> >>>> hurt the eyes too much any more.
> >>>
> >>> The "enable-method" property is described as a stringlist by ePAPR, and is
> >>> currently in use on arm64 as such. It *must* remain a string(list) for arm64.
> >>>
> >>> Having it as an integer for arm is only going to cause us additional work,
> >>> makes it impossible to share a common dt between 64bit and 32bit, and goes
> >>> against the standard. I think it should be a stringlist for arm.
> >>
> >> OK, that's a great reason for this case.
> >>
> >> I hope we don't introduce any more standards that use strings, but that
> >> may just be my personal preference...
> > 
> > I think in any standard, strings are far easier to deal with.  
> > Especially with config stuff which is far from being performance 
> > critical. Strings are much less prone to conflicts.  It is too easy to 
> > "extend" a standard by assigning meanings to free numerical values just 
> > to discover that someone else did use the same numbers for other 
> > meanings.
> > 
> > In order to avoid this issue, a central authority has to be established 
> > to assign numbers out while strings are fine without that most of the 
> > time.
> 
> For DT, all strings or numbers must always be documented in the DT
> binding, so there's no risk of conflict there.

No, that's not good enough.  Most of the time, DT properties are created 
during development way earlier than any publication of them.  Picking a 
random number is just creating trouble whereas a string might just be 
right from the start.

Furthermore, what's the point to obfuscate a property name behind a 
numerical indirection?  If what you want to describe is a number then 
just use a number.  But if you want to describe a property, a method, or 
any other attribute with no direct relation to a number except for the 
only purpose of enumeration then there is just no point not to use a 
string up front.


Nicolas


From dave.martin at linaro.org  Wed Apr 17 12:56:09 2013
From: dave.martin at linaro.org (Dave Martin)
Date: Wed, 17 Apr 2013 17:56:09 +0100
Subject: [RFC PATCH 2/2] ARM: DT: kernel: DT cpu node bindings update
In-Reply-To: <alpine.LFD.2.03.1304171231130.17375@syhkavp.arg>
References: <1366042402-8987-1-git-send-email-lorenzo.pieralisi@arm.com>
 <1366042402-8987-3-git-send-email-lorenzo.pieralisi@arm.com>
 <516C544A.4090107@wwwdotorg.org>
 <20130417091457.GB5012@e106331-lin.cambridge.arm.com>
 <516EBC66.20508@wwwdotorg.org>
 <alpine.LFD.2.03.1304171146530.17375@syhkavp.arg>
 <516ECC8A.2070508@wwwdotorg.org>
 <alpine.LFD.2.03.1304171231130.17375@syhkavp.arg>
Message-ID: <20130417165609.GB2249@linaro.org>

On Wed, Apr 17, 2013 at 12:36:08PM -0400, Nicolas Pitre wrote:
> On Wed, 17 Apr 2013, Stephen Warren wrote:
> 
> > On 04/17/2013 10:02 AM, Nicolas Pitre wrote:
> > > On Wed, 17 Apr 2013, Stephen Warren wrote:
> > > 
> > >> On 04/17/2013 03:14 AM, Mark Rutland wrote:
> > >>> Hi Stephen,
> > >>>
> > >>>>> +	- enable-method
> > >>>>> +		Usage: required on ARM 64-bit systems, optional on ARM 32-bit
> > >>>>> +		       systems
> > >>>>> +		Value type: <string>
> > >>>>> +		Definition: On ARM 64-bit systems must be "spin-table" [1].
> > >>>>
> > >>>> Can that be an integer instead? with dtc+cpp support, that shouldn't
> > >>>> hurt the eyes too much any more.
> > >>>
> > >>> The "enable-method" property is described as a stringlist by ePAPR, and is
> > >>> currently in use on arm64 as such. It *must* remain a string(list) for arm64.
> > >>>
> > >>> Having it as an integer for arm is only going to cause us additional work,
> > >>> makes it impossible to share a common dt between 64bit and 32bit, and goes
> > >>> against the standard. I think it should be a stringlist for arm.
> > >>
> > >> OK, that's a great reason for this case.
> > >>
> > >> I hope we don't introduce any more standards that use strings, but that
> > >> may just be my personal preference...
> > > 
> > > I think in any standard, strings are far easier to deal with.  
> > > Especially with config stuff which is far from being performance 
> > > critical. Strings are much less prone to conflicts.  It is too easy to 
> > > "extend" a standard by assigning meanings to free numerical values just 
> > > to discover that someone else did use the same numbers for other 
> > > meanings.
> > > 
> > > In order to avoid this issue, a central authority has to be established 
> > > to assign numbers out while strings are fine without that most of the 
> > > time.
> > 
> > For DT, all strings or numbers must always be documented in the DT
> > binding, so there's no risk of conflict there.
> 
> No, that's not good enough.  Most of the time, DT properties are created 
> during development way earlier than any publication of them.  Picking a 
> random number is just creating trouble whereas a string might just be 
> right from the start.
> 
> Furthermore, what's the point to obfuscate a property name behind a 
> numerical indirection?  If what you want to describe is a number then 
> just use a number.  But if you want to describe a property, a method, or 
> any other attribute with no direct relation to a number except for the 
> only purpose of enumeration then there is just no point not to use a 
> string up front.

I also fear that vendors will follow the precedent and avoid publishing
any symbolic names ... or bindings, or headers ... for enumerated
choices in their non-upstream product trees.  Using the source -- if
you can find it -- will be the only hope for guessing what such entries
in an FDT could possibly mean.  This just makes life unnecessarily hard
for developers.

There is no foolproof way to prevent this, but conventions which
encourage transparency over crypticness at least discourage that
sort of behaviour.

Cheers
---Dave


From dave.martin at linaro.org  Wed Apr 17 12:57:22 2013
From: dave.martin at linaro.org (Dave Martin)
Date: Wed, 17 Apr 2013 17:57:22 +0100
Subject: [PATCH 3/3] ARM: tegra: make sure the pointer on 4 byte align
 when THUMB2_KERNEL enabled
In-Reply-To: <516ECC2A.1060308@wwwdotorg.org>
References: <1366066255-18192-1-git-send-email-swarren@wwwdotorg.org>
 <1366066255-18192-3-git-send-email-swarren@wwwdotorg.org>
 <20130416141252.GA2229@linaro.org> <516D7A3B.9030404@wwwdotorg.org>
 <20130417102957.GA2249@linaro.org> <516ECC2A.1060308@wwwdotorg.org>
Message-ID: <20130417165722.GC2249@linaro.org>

On Wed, Apr 17, 2013 at 10:22:02AM -0600, Stephen Warren wrote:
> On 04/17/2013 04:30 AM, Dave Martin wrote:
> > On Tue, Apr 16, 2013 at 10:20:11AM -0600, Stephen Warren wrote:
> >> On 04/16/2013 08:13 AM, Dave Martin wrote:
> >>> On Mon, Apr 15, 2013 at 04:50:55PM -0600, Stephen Warren wrote:
> >>>> From: Joseph Lo <josephl at nvidia.com>
> >>>>
> >>>> When building kernel with CONFIG_THUMB2_KERNEL, the data pointer in the
> >>>> assembly may not on the 4 byte alignment. Then causing a data abort when
> >>>> accessing the pointer. This patch add a ".align" flag in the head of the
> >>>> pointer. And always using 32-bit ADR Thumb instruction to make sure it
> >>>> won't build failure.
> >>>>
> >>>> Signed-off-by: Joseph Lo <josephl at nvidia.com>
> >>>> Signed-off-by: Stephen Warren <swarren at nvidia.com>
> >>>> ---
> >>>>  arch/arm/mach-tegra/reset-handler.S |    1 +
> >>>>  arch/arm/mach-tegra/sleep.h         |    3 ++-
> >>>>  2 files changed, 3 insertions(+), 1 deletion(-)
> >>>>
> >>>> diff --git a/arch/arm/mach-tegra/reset-handler.S b/arch/arm/mach-tegra/reset-handler.S
> >>>> index e6de88a..519a8c5 100644
> >>>> --- a/arch/arm/mach-tegra/reset-handler.S
> >>>> +++ b/arch/arm/mach-tegra/reset-handler.S
> >>>> @@ -83,6 +83,7 @@ ENDPROC(tegra_resume)
> >>>>  
> >>>>  #ifdef CONFIG_CACHE_L2X0
> >>>>  	.globl	l2x0_saved_regs_addr
> >>>> +	.align
> >>>>  l2x0_saved_regs_addr:
> >>>>  	.long	0
> >>>>  #endif
> >>>> diff --git a/arch/arm/mach-tegra/sleep.h b/arch/arm/mach-tegra/sleep.h
> >>>> index 4ffae54..8e9b6af 100644
> >>>> --- a/arch/arm/mach-tegra/sleep.h
> >>>> +++ b/arch/arm/mach-tegra/sleep.h
> >>>> @@ -92,7 +92,8 @@
> >>>>  
> >>>>  #ifdef CONFIG_CACHE_L2X0
> >>>>  .macro l2_cache_resume, tmp1, tmp2, tmp3, phys_l2x0_saved_regs
> >>>> -	adr	\tmp1, \phys_l2x0_saved_regs
> >>>> + ARM(	adr	\tmp1, \phys_l2x0_saved_regs )
> >>>> + THUMB(	adr.w	\tmp1, \phys_l2x0_saved_regs )
> >>>
> >>> Can you give an example of the assembler error you get without this?
> >>
> >> arch/arm/mach-tegra/reset-handler.S: Assembler messages:
> >> arch/arm/mach-tegra/reset-handler.S:78: Error: invalid immediate for
> >> address calculation (value = 0x00000004)
> > 
> > The immediate in the 16-bit form of ADR is alignment-sensitive, and
> > can't address anything that's not on a word boundary.  What if you just
> > have the .align, without adr.w?
> > 
> >> This is with gcc-4.5.3, as:
> >> GNU assembler (crosstool-NG hg_unknown at 20110628.165246) 2.20.1.20100303
> >>
> >>> The target symbol is local and the assembler can see where it is,
> >>> so it should choose the correct variant for the adr instruction
> >>> with no need for the ".w" suffix.
> >>>
> >>> If not, it could mean that there is a bug in the version of the
> >>> assembler you're using.
> >>
> >> True. Switching to the Ubuntu-packaged ARM cross-compiler that ships
> >> with Ubuntu 12.10, I do not see this problem.
> >>
> >> Still, many people probably still use older compilers.
> >>
> >>> If it's definitely needed, you can append a Thumb-only .w suffix with
> >>>
> >>> 	W(adr)	\tmp1, \phys_l2x0_saved_regs
> >>>
> >>> ...which is slightly neater.
> >>
> >> Yes, that certainly works too, even without the .align change in
> >> reset-handler.S.
> > 
> > Sure, although the unaligned access is not such a good idea anyway.
> > 
> > Keeping the adr fix is harmless, I just wanted to understand why it's
> > needed.
> 
> With just the following, and no adr.w:
> 
> > diff --git a/arch/arm/mach-tegra/reset-handler.S b/arch/arm/mach-tegra/reset-handler.S
> > index e6de88a..519a8c5 100644
> > --- a/arch/arm/mach-tegra/reset-handler.S
> > +++ b/arch/arm/mach-tegra/reset-handler.S
> > @@ -83,6 +83,7 @@ ENDPROC(tegra_resume)
> >  
> >  #ifdef CONFIG_CACHE_L2X0
> >         .globl  l2x0_saved_regs_addr
> > +       .align
> >  l2x0_saved_regs_addr:
> >         .long   0
> >  #endif
> 
> I still get:
> 
> > arch/arm/mach-tegra/reset-handler.S: Assembler messages:
> > arch/arm/mach-tegra/reset-handler.S:78: Error: invalid immediate for address calculation (value = 0x00000004)
> 
> That's with GNU assembler (crosstool-NG hg_unknown at 20110628.165246)
> 2.20.1.20100303.
> 
> BTW, I'm on vacation for the next 2 weeks starting this afternoon.
> Hopefully Joseph can keep this thread alive while I'm gone if needed.

OK.  I'm happy to go with the W() so long definitely fixes something :)

Cheers
---Dave


From olof at lixom.net  Wed Apr 17 12:57:42 2013
From: olof at lixom.net (Olof Johansson)
Date: Wed, 17 Apr 2013 09:57:42 -0700
Subject: [GIT PULL] Timer clean-ups for 3.10, Part 2
In-Reply-To: <201304152320.28401.arnd@arndb.de>
References: <516720B4.3000703@gmail.com>
 <20130413065056.GB14735@quad.lixom.net>
 <516C0257.8040103@gmail.com> <201304152320.28401.arnd@arndb.de>
Message-ID: <20130417165742.GB8730@quad.lixom.net>

On Mon, Apr 15, 2013 at 11:20:28PM +0200, Arnd Bergmann wrote:
> On Monday 15 April 2013, Rob Herring wrote:
> > It is quite messed up because the mct timer changes are not based on
> > arm-soc/clksrc/cleanup. Any timer changes adding CLKSRC_OF support need
> > to be based on this. I've fixed it up in this branch (untested):
> > 
> > git://sources.calxeda.com/kernel/linux.git exynos-mct-merge
> > 
> > I merged with clksrc-cleanup-for-3.10-part2 and fixed it in the merge,
> > but really either the mct branch should be rebased or some of the
> > changes can be a preparatory commit before merging.
> 
> Note that I also merged the branches when pulling in the samsung changes,
> and did a complex merge there. We should ensure that we use the same
> merge here.

Hrm, this is now a total mess. I can pick up Rob's preferred resolution,
but merging that in on top of the exynos branches causes lots of conflicts
there as well.

I might just have to rebuild the next/ branches in question to resolve
this.  Either that or bring the late/clksrc stuff into the same branch
as the exynos timer patches.


-Olof


From dave.martin at linaro.org  Wed Apr 17 12:59:27 2013
From: dave.martin at linaro.org (Dave Martin)
Date: Wed, 17 Apr 2013 17:59:27 +0100
Subject: [PATCH 3/3] ARM: tegra: make sure the pointer on 4 byte align
 when THUMB2_KERNEL enabled
In-Reply-To: <1366066255-18192-3-git-send-email-swarren@wwwdotorg.org>
References: <1366066255-18192-1-git-send-email-swarren@wwwdotorg.org>
 <1366066255-18192-3-git-send-email-swarren@wwwdotorg.org>
Message-ID: <20130417165927.GD2249@linaro.org>

On Mon, Apr 15, 2013 at 04:50:55PM -0600, Stephen Warren wrote:
> From: Joseph Lo <josephl at nvidia.com>
> 
> When building kernel with CONFIG_THUMB2_KERNEL, the data pointer in the
> assembly may not on the 4 byte alignment. Then causing a data abort when
> accessing the pointer. This patch add a ".align" flag in the head of the
> pointer. And always using 32-bit ADR Thumb instruction to make sure it
> won't build failure.
> 
> Signed-off-by: Joseph Lo <josephl at nvidia.com>
> Signed-off-by: Stephen Warren <swarren at nvidia.com>

With the change to W(adr), Reviewed-by: Dave Martin <dave.martin at linaro.org>

> ---
>  arch/arm/mach-tegra/reset-handler.S |    1 +
>  arch/arm/mach-tegra/sleep.h         |    3 ++-
>  2 files changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-tegra/reset-handler.S b/arch/arm/mach-tegra/reset-handler.S
> index e6de88a..519a8c5 100644
> --- a/arch/arm/mach-tegra/reset-handler.S
> +++ b/arch/arm/mach-tegra/reset-handler.S
> @@ -83,6 +83,7 @@ ENDPROC(tegra_resume)
>  
>  #ifdef CONFIG_CACHE_L2X0
>  	.globl	l2x0_saved_regs_addr
> +	.align
>  l2x0_saved_regs_addr:
>  	.long	0
>  #endif
> diff --git a/arch/arm/mach-tegra/sleep.h b/arch/arm/mach-tegra/sleep.h
> index 4ffae54..8e9b6af 100644
> --- a/arch/arm/mach-tegra/sleep.h
> +++ b/arch/arm/mach-tegra/sleep.h
> @@ -92,7 +92,8 @@
>  
>  #ifdef CONFIG_CACHE_L2X0
>  .macro l2_cache_resume, tmp1, tmp2, tmp3, phys_l2x0_saved_regs
> -	adr	\tmp1, \phys_l2x0_saved_regs
> + ARM(	adr	\tmp1, \phys_l2x0_saved_regs )
> + THUMB(	adr.w	\tmp1, \phys_l2x0_saved_regs )
>  	ldr	\tmp1, [\tmp1]
>  	ldr	\tmp2, [\tmp1, #L2X0_R_PHY_BASE]
>  	ldr	\tmp3, [\tmp2, #L2X0_CTRL]
> -- 
> 1.7.10.4
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From dave.martin at linaro.org  Wed Apr 17 13:00:49 2013
From: dave.martin at linaro.org (Dave Martin)
Date: Wed, 17 Apr 2013 18:00:49 +0100
Subject: [PATCH 1/3] ARM: tegra: fix build error when THUMB2_KERNEL enabled
In-Reply-To: <1366066255-18192-1-git-send-email-swarren@wwwdotorg.org>
References: <1366066255-18192-1-git-send-email-swarren@wwwdotorg.org>
Message-ID: <20130417170049.GE2249@linaro.org>

On Mon, Apr 15, 2013 at 04:50:53PM -0600, Stephen Warren wrote:
> From: Joseph Lo <josephl at nvidia.com>
> 
> This patch fix the build failure when CONFIG_THUBM2_KERNEL enabled. You
> clould see the error message below:
> 
> arch/arm/mach-tegra/sleep-tegra30.S:69: Error: shift must be constant --
> `orr r12,r12,r4,lsl r3'
> 
> Reported-by: Arnd Bergmann <arnd at arndb.de>
> Signed-off-by: Joseph Lo <josephl at nvidia.com>
> Signed-off-by: Stephen Warren <swarren at nvidia.com>

FWIW, Reviewed-by: Dave Martin <dave.martin at linaro.org>

> ---
> Arnd, Olof, here are 3 fixes from Joseph for some Tegra build issues,
> mostly exposed by multi-platform enablement and/or related randconfig
> testing.
> 
> Can you please apply these to arm-soc? For reference, I tested applying
> them to Tegra's for-3.10/fixes branch and they apply there fine, and
> merge with the other Tegra for-3.10 branches at least, without any issue.
> 
> Note: patch 3 triggers checkpatch, but I can't work out why; the code
> seems to be formatted the same as patch 1 and 2, and is consistent with
> other usage of ARM() and THUMB() macros in arch/arm/.
> 
>  arch/arm/mach-tegra/sleep-tegra30.S |    4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-tegra/sleep-tegra30.S b/arch/arm/mach-tegra/sleep-tegra30.S
> index 63a15bd..d29dfcc 100644
> --- a/arch/arm/mach-tegra/sleep-tegra30.S
> +++ b/arch/arm/mach-tegra/sleep-tegra30.S
> @@ -66,7 +66,9 @@ ENTRY(tegra30_cpu_shutdown)
>  		FLOW_CTRL_CSR_INTR_FLAG | FLOW_CTRL_CSR_EVENT_FLAG | \
>  		FLOW_CTRL_CSR_ENABLE
>  	mov	r4, #(1 << 4)
> -	orr	r12, r12, r4, lsl r3
> + ARM(	orr	r12, r12, r4, lsl r3	)
> + THUMB(	lsl	r4, r4, r3		)
> + THUMB(	orr	r12, r12, r4		)
>  	str	r12, [r1]
>  
>  	/* Halt this CPU. */
> -- 
> 1.7.10.4
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From dave.martin at linaro.org  Wed Apr 17 13:01:14 2013
From: dave.martin at linaro.org (Dave Martin)
Date: Wed, 17 Apr 2013 18:01:14 +0100
Subject: [PATCH 2/3] ARM: tegra: fix relocation truncated error when
 THUMB2_KERNEL enabled
In-Reply-To: <1366066255-18192-2-git-send-email-swarren@wwwdotorg.org>
References: <1366066255-18192-1-git-send-email-swarren@wwwdotorg.org>
 <1366066255-18192-2-git-send-email-swarren@wwwdotorg.org>
Message-ID: <20130417170114.GF2249@linaro.org>

On Mon, Apr 15, 2013 at 04:50:54PM -0600, Stephen Warren wrote:
> From: Joseph Lo <josephl at nvidia.com>
> 
> The conditional branch instruction in Thumb2 only available to short range.
> The linker will fail when the conditional branch over the range. Then
> resulting in link error when generating kernel image. e.g.:
> 
> arch/arm/mach-tegra/reset-handler.S:47:(.text+0xf8e):
> relocation truncated to fit: R_ARM_THM_JUMP19 against symbol
> `cpu_resume' defined in .data section in arch/arm/kernel/built-in.o
> 
> This patch using a Thumb2 instruction IT (if-then) to have a longer branch
> range.
> 
> Reported-by: Arnd Bergmann <arnd at arndb.de>
> Signed-off-by: Joseph Lo <josephl at nvidia.com>
> Signed-off-by: Stephen Warren <swarren at nvidia.com>

FWIW, Reviewed-by: Dave Martin <dave.martin at linaro.org>

> ---
>  arch/arm/mach-tegra/reset-handler.S |    1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/mach-tegra/reset-handler.S b/arch/arm/mach-tegra/reset-handler.S
> index 1676aba..e6de88a 100644
> --- a/arch/arm/mach-tegra/reset-handler.S
> +++ b/arch/arm/mach-tegra/reset-handler.S
> @@ -44,6 +44,7 @@ ENTRY(tegra_resume)
>  
>  	cpu_id	r0
>  	cmp	r0, #0				@ CPU0?
> + THUMB(	it	ne )
>  	bne	cpu_resume			@ no
>  
>  #ifdef CONFIG_ARCH_TEGRA_3x_SOC
> -- 
> 1.7.10.4
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From tony at atomide.com  Wed Apr 17 13:11:32 2013
From: tony at atomide.com (Tony Lindgren)
Date: Wed, 17 Apr 2013 10:11:32 -0700
Subject: [PATCH] ARM: dts: omap3-beagle-xm: Add USB Host support for
 Rev Ax/Bx
In-Reply-To: <516E94FA.9060606@compulab.co.il>
References: <1366029306-1824-1-git-send-email-rogerq@ti.com>
 <516BF4F3.5060904@ti.com> <20130417005232.GV10155@atomide.com>
 <CAOCHtYgFnCy5Qn2LeJOK96_NdwzxzVe8Vrb8cL=K9AdzPUtQow@mail.gmail.com>
 <516E5597.7050801@compulab.co.il> <516E5F9E.3050204@ti.com>
 <516E94FA.9060606@compulab.co.il>
Message-ID: <20130417171132.GY10155@atomide.com>

* Igor Grinberg <grinberg at compulab.co.il> [130417 05:31]:
> On 04/17/13 11:38, Roger Quadros wrote:
> > On 04/17/2013 10:56 AM, Igor Grinberg wrote:
> >> On 04/17/13 04:30, Robert Nelson wrote:
> >>> On Tue, Apr 16, 2013 at 7:52 PM, Tony Lindgren <tony at atomide.com> wrote:
> >>>> * Roger Quadros <rogerq at ti.com> [130415 05:44]:
> >>>>> On 04/15/2013 03:35 PM, Roger Quadros wrote:
> >>>>>> Provide RESET and Power regulators for the USB PHY,
> >>>>>> the USB Host port mode and the PHY device.
> >>>>>>
> >>>>>> Also provide pin multiplexer information for USB host
> >>>>>> pins.
> >>>>>>
> >>>>>> This will not work for Rev Cx boards because of reversed logic
> >>>>>> for USB_POWER_Enable.
> >>>>>>
> >>>>>> CC: Beno?t Cousson <b-cousson at ti.com>
> >>>>>> Signed-off-by: Roger Quadros <rogerq at ti.com>
> >>>>>> ---
> >>>>>>  arch/arm/boot/dts/omap3-beagle-xm.dts |   62 +++++++++++++++++++++++++++++++++
> >>>>>>  1 files changed, 62 insertions(+), 0 deletions(-)
> >>>>>>
> >>>>>> diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts b/arch/arm/boot/dts/omap3-beagle-xm.dts
> >>>>>> index 5a31964..d394c51 100644
> >>>>>> --- a/arch/arm/boot/dts/omap3-beagle-xm.dts
> >>>>>> +++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
> >>>>>> @@ -57,6 +57,60 @@
> >>>>>>             ti,mcbsp = <&mcbsp2>;
> >>>>>>             ti,codec = <&twl_audio>;
> >>>>>>     };
> >>>>>> +
> >>>>>> +   /* HS USB Port 2 RESET */
> >>>>>> +   hsusb2_reset: hsusb2_reset_reg {
> >>>>>> +           compatible = "regulator-fixed";
> >>>>>> +           regulator-name = "hsusb2_reset";
> >>>>>> +           regulator-min-microvolt = <3300000>;
> >>>>>> +           regulator-max-microvolt = <3300000>;
> >>>>>> +           gpio = <&gpio5 19 0>;   /* gpio_147 */
> >>>>>> +           startup-delay-us = <70000>;
> >>>>>> +           enable-active-high;
> >>>>>> +   };
> >>>>>> +
> >>>>>> +   /* HS USB Port 2 Power */
> >>>>>> +   hsusb2_power: hsusb2_power_reg {
> >>>>>> +           compatible = "regulator-fixed";
> >>>>>> +           regulator-name = "hsusb2_vbus";
> >>>>>> +           regulator-min-microvolt = <3300000>;
> >>>>>> +           regulator-max-microvolt = <3300000>;
> >>>>>> +           gpio = <&twl_gpio 18 0>;        /* GPIO LEDA */
> >>>>>> +           startup-delay-us = <70000>;
> >>>>>> +           enable-active-high;     /* FIXME: active-low for Rev. C */
> >>>>>
> >>>>> Benoit & Tony,
> >>>>>
> >>>>> Any ideas how to tackle the reversed logic for Rev. C boards?
> >>>>
> >>>> Sounds like we need a shared omap3-beage.dtsi, then omap3-beagle-xm.dts
> >>>> and omap3-beagle-rev-c.dts. Then xm and rev-c can both include the
> >>>
> >>> Bike-sheding, but we might want to make that "omap3-beagle-xmc.dts" as
> >>> there is the "rev c" variant of the original beagle...
> >>>
> >>> It's too bad we can't read the 3 gpio pin states in the device tree
> >>> and make a decision.
> >>
> >> I would recommend to move the detection to the boot loader and
> >> adjust the DT blob at run time (in the boot loader).
> >> This way, we will not need to deal with all the (sub)revision stuff.
> >>
> >>
> > Moving the detection to bootloader is fine, but modifying the DT at
> > runtime would create a debug/maintenance issue. Instead it could just
> > pick one of the .DTBs and pass it to kernel.
> 
> Like this will not create create any debug/maintenance issues.... ;-)
> We have no problem with debug, as all the DT nodes can be seen in
> both U-Boot (with fdt commands) and Linux through procfs...
> 
> I've just dropped my 2 cents and I don't really insist...

The dynamic configuration from the bootloader can also be done too, I
don't think they are mutually exclusive. 
 
> > Since most users will be using rev-c, I think we should keep the original
> > file 'omap3-beagle-xm.dts" as it is for rev-c boards.
> > I can just create a new dts file for Revisions A and B that will be
> > like so.
> > 
> > +++ b/arch/arm/boot/dts/omap3-beagle-xm-ab.dts
> > @@ -0,0 +1,6 @@
> > +/include/ "omap3-beagle-xm.dts"
> > +
> > +/* On Rev A/B USBHOST_PWR_EN is active high */
> > +&hsusb2_power {
> > +       enable-active-high;
> > +};
> > 
> > Since omap3-beagle and omap3-beagle-xm use different SoC versions and have
> > quite many differences, I don't think it is a good idea to create a common
> > file between the two.

Sounds good to me. But please also add the revision info to the compatible
flags for both .dts files.

Regards,

Tony


From jason at lakedaemon.net  Wed Apr 17 13:38:10 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Wed, 17 Apr 2013 13:38:10 -0400
Subject: [PATCHv3 00/10] Use the mvebu PCIe driver on Kirkwood
In-Reply-To: <1365865005-26653-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1365865005-26653-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <20130417173810.GD27197@titan.lakedaemon.net>

Thomas, et al.

I applied this series to an experimental branch mvebu-late/pcie.  Please
check that everything is kosher.  I had to add mvebu/boards as a
dependency since there is a patch in there alphabetizing kirkwood's
Kconfig (and thus _defconfig).

*If* rmk creates a stable branch in time, or drops the patch so we can
take it, this branch will be rebased to fix that.  Currently, it depends
on rmk/for-next, which is *not* stable.  This is the only public rmk
branch that has the needed patch.  :-(

Assuming the above happens, I'll send two PRs, one for the mvebu-pcie
stuff, then one for the kirkwood-pcie stuff.

If the stars align, we're ready.  Otherwise, we have everything set to
go into arm-soc early for the next round.

thx,

Jason.


On Sat, Apr 13, 2013 at 04:56:35PM +0200, Thomas Petazzoni wrote:
> Hello,
> 
> Here is a set of patches that migrates adds support for Kirkwood
> platforms to use the mvebu PCIe driver. All the Kirkwood platforms
> that have already been converted to the Device Tree are converted to
> use the new driver, and the DB-88F6281 evaluation board from Marvell
> is also converted to the Device Tree and the usage of the new PCIe
> driver.
> 
> Only non-DT platforms continue to use the legacy code in
> arch/arm/mach-kirkwood/pcie.c.
> 
> This branch depends on the mvebu-mbus driver and the mvebu-pcie
> driver. I have pushed this branch to the following Git repository for
> easier testing:
> 
>   https://github.com/MISL-EBU-System-SW/mainline-public/tree/kirkwood-pcie-dt-v3
> 
> # /usr/sbin/lspci
> 00:01.0 PCI bridge: Marvell Technology Group Ltd. Device 7846
> 00:02.0 PCI bridge: Marvell Technology Group Ltd. Device 7846
> 01:00.0 SCSI storage controller: Marvell Technology Group Ltd. 88SX7042 PCI-e 4-port SATA-II (rev 02)
> 02:00.0 Ethernet controller: Intel Corporation 82572EI Gigabit Ethernet Controller (Copper) (rev 06)
> 
> # cat /proc/cpuinfo | grep ^Hardware
> Hardware	: Marvell Kirkwood (Flattened Device Tree)
> 
> I've tested both the e1000e NIC card and the SATA 4 ports card and
> they work fine.
> 
> Changes between v2 and v3:
> 
>  * Integrate a replacement patch from Andrew Lunn for the QNAP changes
>    after he tested on his hardware platform.
> 
>  * Add Andrew Lunn Tested-by tags on the appropriate patches.
> 
> Changes between v1 and v2:
> 
>  * Remove the 'needs_pcie_win' logic, and instead move the static
>    initialization of PCIe windows into the legacy PCIe code, for the
>    platforms that will still be using it. Platforms that will use the
>    new PCIe driver benefit directly from dynamic allocation of PCIe
>    windows.
> 
>  * Move the PCIe interface definitions from kirkwood.dtsi to
>    kirkwood-6281.dtsi and kirkwood-6282.dtsi to take into account the
>    fact that the 6281 has one PCIe interface, and the 6282 has two of
>    them.
> 
>  * Convert all DT-platforms that were initializing PCIe using the
>    legacy driver to use the DT to initialize the PCIe interface. This
>    includes the Iomega Iconnect, the MPL CEC4, the ZyXEL NSA310and the
>    QNAP TS219.
> 
>  * Fix the conversion to the Device Tree of the DB-88F6181/6282
>    board. We now have two Device Trees, one for the 6281 variant of
>    the board (one PCIe interface) and another for the 6282 variant of
>    the board (two PCIe interfaces).
> 
>  * Update the defconfig with PCIe driver enabled and some board
>    updates.
> 
> Best regards,
> 
> Thomas
> 
> Thomas Petazzoni (10):
>   pci: mvebu: enable driver usage on Kirkwood
>   bus: mvebu: fix mistake in PCIe window target attribute for Kirkwood
>   arm: kirkwood: move PCIe window init to legacy driver
>   arm: kirkwood: add SoC-level Device Tree data for PCIe interfaces
>   arm: kirkwood: convert Iomega Iconnect to use DT for the PCIe
>     interface
>   arm: kirkwood: convert MPL CEC4 to use DT for the PCIe interface
>   arm: kirkwood: convert ZyXEL NSA310 to use DT for the PCIe interface
>   arm: kirkwood: convert QNAP TS219 to use DT for the PCIe interface
>   arm: kirkwood: convert db-88f6281 to the Device Tree
>   arm: kirkwood: update defconfig with PCIe driver and board updates
> 
>  .../devicetree/bindings/pci/mvebu-pci.txt          |    1 +
>  arch/arm/boot/dts/Makefile                         |    5 +-
>  arch/arm/boot/dts/kirkwood-6281.dtsi               |   31 ++++++
>  arch/arm/boot/dts/kirkwood-6282.dtsi               |   48 +++++++++
>  arch/arm/boot/dts/kirkwood-db-88f6281.dts          |   30 ++++++
>  arch/arm/boot/dts/kirkwood-db-88f6282.dts          |   34 ++++++
>  arch/arm/boot/dts/kirkwood-db.dtsi                 |   89 ++++++++++++++++
>  arch/arm/boot/dts/kirkwood-iconnect.dts            |    8 ++
>  arch/arm/boot/dts/kirkwood-mplcec4.dts             |    8 ++
>  arch/arm/boot/dts/kirkwood-nsa310.dts              |    8 ++
>  arch/arm/boot/dts/kirkwood-ts219-6281.dts          |    3 +-
>  arch/arm/boot/dts/kirkwood-ts219-6282.dts          |    3 +-
>  arch/arm/boot/dts/kirkwood-ts219.dtsi              |    9 +-
>  arch/arm/boot/dts/kirkwood.dtsi                    |    1 +
>  arch/arm/configs/kirkwood_defconfig                |    6 +-
>  arch/arm/mach-kirkwood/Kconfig                     |   21 ++--
>  arch/arm/mach-kirkwood/Makefile                    |    3 +-
>  arch/arm/mach-kirkwood/board-db88f6281-bp.c        |   26 +++++
>  arch/arm/mach-kirkwood/board-dt.c                  |    2 +
>  arch/arm/mach-kirkwood/board-iconnect.c            |    8 --
>  arch/arm/mach-kirkwood/board-mplcec4.c             |    1 -
>  arch/arm/mach-kirkwood/board-nsa310.c              |   25 -----
>  arch/arm/mach-kirkwood/board-ts219.c               |   10 --
>  arch/arm/mach-kirkwood/common.c                    |   24 -----
>  arch/arm/mach-kirkwood/common.h                    |    6 ++
>  arch/arm/mach-kirkwood/db88f6281-bp-setup.c        |  108 --------------------
>  arch/arm/mach-kirkwood/pcie.c                      |   22 ++++
>  drivers/bus/mvebu-mbus.c                           |    2 +-
>  drivers/pci/host/Kconfig                           |    2 +-
>  drivers/pci/host/pci-mvebu.c                       |    1 +
>  30 files changed, 343 insertions(+), 202 deletions(-)
>  create mode 100644 arch/arm/boot/dts/kirkwood-db-88f6281.dts
>  create mode 100644 arch/arm/boot/dts/kirkwood-db-88f6282.dts
>  create mode 100644 arch/arm/boot/dts/kirkwood-db.dtsi
>  create mode 100644 arch/arm/mach-kirkwood/board-db88f6281-bp.c
>  delete mode 100644 arch/arm/mach-kirkwood/board-nsa310.c
>  delete mode 100644 arch/arm/mach-kirkwood/db88f6281-bp-setup.c
> 
> -- 
> 1.7.9.5
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From jonathan.austin at arm.com  Wed Apr 17 13:41:46 2013
From: jonathan.austin at arm.com (Jonathan Austin)
Date: Wed, 17 Apr 2013 18:41:46 +0100
Subject: [PATCH v11 0/3] Another round of ARMv7-M patches
In-Reply-To: <1366215299-31969-1-git-send-email-u.kleine-koenig@pengutronix.de>
References: <1366215299-31969-1-git-send-email-u.kleine-koenig@pengutronix.de>
Message-ID: <516EDEDA.1000108@arm.com>

Hi Uwe,

Nice! I'd love to see these in mainline and they look good now...

On 17/04/13 17:14, Uwe Kleine-K?nig wrote:
> Hello,
>
> the changes since v10 are small:
>
>   - Jonny noticed an inconsitency in arch/arm/mm/proc-v7m.S
>   - changes to account for review comments to my nvic driver (v3 just
>     sent out)
>
> I put these three patches in my for-next branch so they should make it
> into the next next. The tree merges fine into current Linus' master and
> next-20130417.
>

The only comment I have left is that I'd really like the 
BASEADDRESS_V7M_SCB namespaced like the rest of the V7M defines

With that said, please feel free to add for the series:

Reviewed-by: Jonathan Austin <jonathan.austin at arm.com>
Tested-by: Jonathan Austin <jonathan.austin at arm.com

Jonny

> Russell, what are your thoughts about the series? Would you take it for
> v3.10? Or v3.11?
>
> Catalin Marinas (1):
>    ARM: Add base support for ARMv7-M
>
> Uwe Kleine-K?nig (2):
>    ARM: ARMv7-M: Add support for exception handling
>    ARM: ARMv7-M: Allow the building of new kernel port
>
>   arch/arm/Kconfig                   |   4 +-
>   arch/arm/Kconfig-nommu             |   2 +-
>   arch/arm/Makefile                  |   1 +
>   arch/arm/include/asm/assembler.h   |  17 +++-
>   arch/arm/include/asm/cputype.h     |  12 ++-
>   arch/arm/include/asm/glue-cache.h  |  27 +++++++
>   arch/arm/include/asm/glue-df.h     |   8 ++
>   arch/arm/include/asm/glue-proc.h   |   9 +++
>   arch/arm/include/asm/irqflags.h    |  22 ++++--
>   arch/arm/include/asm/ptrace.h      |   4 +
>   arch/arm/include/asm/system_info.h |   1 +
>   arch/arm/include/asm/v7m.h         |  44 +++++++++++
>   arch/arm/include/uapi/asm/ptrace.h |  35 +++++++--
>   arch/arm/kernel/Makefile           |   8 +-
>   arch/arm/kernel/entry-common.S     |   4 +
>   arch/arm/kernel/entry-header.S     | 124 +++++++++++++++++++++++++++++
>   arch/arm/kernel/entry-v7m.S        | 143 +++++++++++++++++++++++++++++++++
>   arch/arm/kernel/head-nommu.S       |  10 ++-
>   arch/arm/kernel/setup.c            |  17 +++-
>   arch/arm/kernel/traps.c            |   8 ++
>   arch/arm/mm/Kconfig                |  21 ++++-
>   arch/arm/mm/Makefile               |   2 +
>   arch/arm/mm/cache-nop.S            |  50 ++++++++++++
>   arch/arm/mm/nommu.c                |   7 ++
>   arch/arm/mm/proc-v7m.S             | 157 +++++++++++++++++++++++++++++++++++++
>   25 files changed, 711 insertions(+), 26 deletions(-)
>   create mode 100644 arch/arm/include/asm/v7m.h
>   create mode 100644 arch/arm/kernel/entry-v7m.S
>   create mode 100644 arch/arm/mm/cache-nop.S
>   create mode 100644 arch/arm/mm/proc-v7m.S
>




From nsekhar at ti.com  Wed Apr 17 13:45:56 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Wed, 17 Apr 2013 23:15:56 +0530
Subject: [GIT PULL v2 1/3] ARM: davinci: DT updates for v3.10 (part 2)
Message-ID: <1366220758-23373-1-git-send-email-nsekhar@ti.com>

Hi Arnd, Olof,

Can you please pull these DaVinci DT updates for v3.10?
The change in v2 is that Grant's acks on SPI patches
have been added.

Thanks,
Sekhar

The following changes since commit db4c8fa7c0214c83cbbc990ba630b3b613fcf7c5:

  ARM: davinci: da850: override mmc DT node device name (2013-04-04 16:58:10 +0530)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-for-v3.10/dt-2-v2

for you to fetch changes up to 4f4d9d4dc55814bd98e6a580e55e0a0855feb5cf:

  ARM: davinci: da850-evm: add SPI flash support (2013-04-17 22:19:55 +0530)

----------------------------------------------------------------
v3.10 DT updates for DaVinci

This set of patches adds support for PWMs and SPI
controller present on DA850 and for SPI flash present on
DA850 EVM.

----------------------------------------------------------------
Manjunathappa, Prakash (4):
      spi/davinci: no wildcards in DT compatible property
      ARM: davinci: da850: add SPI1 DT node
      ARM: davinci: da850: override SPI DT node device name
      ARM: davinci: da850-evm: add SPI flash support

Murali Karicheri (1):
      spi/davinci: add DT binding documentation

Philip Avinash (1):
      ARM: davinci: da850: add EHRPWM & ECAP DT node

 .../devicetree/bindings/spi/spi-davinci.txt        |   51 +++++++++++
 arch/arm/boot/dts/da850-evm.dts                    |   40 +++++++++
 arch/arm/boot/dts/da850.dtsi                       |   94 ++++++++++++++++++++
 arch/arm/mach-davinci/da8xx-dt.c                   |    6 ++
 drivers/spi/spi-davinci.c                          |    4 +-
 5 files changed, 193 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/spi/spi-davinci.txt


From nsekhar at ti.com  Wed Apr 17 13:45:57 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Wed, 17 Apr 2013 23:15:57 +0530
Subject: [GIT PULL v2 2/3] ARM: davinci: SoC updates for v3.10 (part 2)
In-Reply-To: <1366220758-23373-1-git-send-email-nsekhar@ti.com>
References: <1366220758-23373-1-git-send-email-nsekhar@ti.com>
Message-ID: <1366220758-23373-2-git-send-email-nsekhar@ti.com>

Hi Arnd, Olof,

Can you please pull the following SoC updates for DaVinci.
Change in v2 is that merge of Ohad's remoteproc branch
has been dropped.

Thanks,
Sekhar

The following changes since commit 93bd65150e4ee783b7366fd0e8172f347515df61:

  ARM: davinci: remove test for undefined Kconfig macro (2013-04-03 09:43:08 +0530)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-for-v3.10/soc-2-v2

for you to fetch changes up to 215a084dc5cb8d814aeb7a2b5192af20aec8209f:

  ARM: davinci: ensure global variables are declared (2013-04-17 19:26:41 +0530)

----------------------------------------------------------------
v3.10 SoC updates for DaVinci

This set of patches add support for remoteproc
used to control the DSP and also fix sparse
errors existing for quite some time.

----------------------------------------------------------------
Robert Tivy (1):
      ARM: davinci: da8xx: add remoteproc support

Sekhar Nori (3):
      ARM: davinci: da8xx dt: make file local symbols static
      ARM: davinci: sram.c: fix incorrect type in assignment
      ARM: davinci: ensure global variables are declared

 Documentation/kernel-parameters.txt        |    6 ++
 arch/arm/mach-davinci/da8xx-dt.c           |    4 +-
 arch/arm/mach-davinci/devices-da8xx.c      |   88 +++++++++++++++++++++++++++-
 arch/arm/mach-davinci/include/mach/da8xx.h |    4 ++
 arch/arm/mach-davinci/pm.c                 |    1 +
 arch/arm/mach-davinci/sram.c               |    4 +-
 arch/arm/mach-davinci/usb.c                |    1 +
 7 files changed, 103 insertions(+), 5 deletions(-)


From nsekhar at ti.com  Wed Apr 17 13:45:58 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Wed, 17 Apr 2013 23:15:58 +0530
Subject: [GIT PULL v2 3/3] ARM: davinci: board updates for v3.10 (part 2)
In-Reply-To: <1366220758-23373-1-git-send-email-nsekhar@ti.com>
References: <1366220758-23373-1-git-send-email-nsekhar@ti.com>
Message-ID: <1366220758-23373-3-git-send-email-nsekhar@ti.com>

Hi Arnd, Olof,

Please pull the following board updates for v3.10. This
depends on SoC updates in previous request.

Thanks,
Sekhar

The following changes since commit 215a084dc5cb8d814aeb7a2b5192af20aec8209f:

  ARM: davinci: ensure global variables are declared (2013-04-17 19:26:41 +0530)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-for-v3.10/board-2-v2

for you to fetch changes up to 58b6c5a133297e0154a085cc73e832222c57729c:

  ARM: davinci: da850 evm: fix const qualifier placement (2013-04-17 22:00:09 +0530)

----------------------------------------------------------------
v3.10 board updates for DaVinci

This set of patches enables remoteproc support
on DA850 EVM and fixes some sparse warnings for
the same board.

----------------------------------------------------------------
Robert Tivy (1):
      ARM: davinci: da850 board: add remoteproc support

Sekhar Nori (1):
      ARM: davinci: da850 evm: fix const qualifier placement

 arch/arm/mach-davinci/board-da850-evm.c     |   10 ++++++++--
 arch/arm/mach-davinci/board-omapl138-hawk.c |    6 ++++++
 2 files changed, 14 insertions(+), 2 deletions(-)


From robherring2 at gmail.com  Wed Apr 17 13:46:43 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Wed, 17 Apr 2013 12:46:43 -0500
Subject: [PATCH v5 5/6] ARM: dts: Add basic dts include files for Samsung
 S3C64xx SoCs
In-Reply-To: <1829212.6niSeTsyIU@amdc1227>
References: <1366060483-20342-1-git-send-email-tomasz.figa@gmail.com>
 <1366060483-20342-6-git-send-email-tomasz.figa@gmail.com>
 <516D4D76.2010409@gmail.com> <1829212.6niSeTsyIU@amdc1227>
Message-ID: <CAL_JsqL_i-5SDCsGZCrsxMehLVMGoLO1s_V3R-H6Oa5ff16dEQ@mail.gmail.com>

On Tue, Apr 16, 2013 at 8:19 AM, Tomasz Figa <t.figa at samsung.com> wrote:
> On Tuesday 16 of April 2013 08:09:10 Rob Herring wrote:
>> On 04/15/2013 04:14 PM, Tomasz Figa wrote:
>> > This patch adds basic device tree definitions for Samsung S3C64xx SoCs.
>> >
>> > Since all the SoCs in the series are very similar, the files are created
>> > hierarchically - one file for the whole series and then separate files
>> > for particular SoCs including the common one.
>> >
>> > Signed-off-by: Tomasz Figa <tomasz.figa at gmail.com>
>> > ---
>> >
>> >  arch/arm/boot/dts/s3c6400.dtsi         |  33 ++
>> >  arch/arm/boot/dts/s3c6410.dtsi         |  33 ++
>> >  arch/arm/boot/dts/s3c64xx-pinctrl.dtsi | 683
>> >  +++++++++++++++++++++++++++++++++ arch/arm/boot/dts/s3c64xx.dtsi
>> >  | 136 +++++++
>> >  4 files changed, 885 insertions(+)
>> >  create mode 100644 arch/arm/boot/dts/s3c6400.dtsi
>> >  create mode 100644 arch/arm/boot/dts/s3c6410.dtsi
>> >  create mode 100644 arch/arm/boot/dts/s3c64xx-pinctrl.dtsi
>> >  create mode 100644 arch/arm/boot/dts/s3c64xx.dtsi
>>
>> [...]
>>
>> > +
>> > +   vic0: interrupt-controller at 71200000 {
>>
>> These nodes should be off a "simple-bus" node.
>
> Hmm, is there any reason behind it?
>
> I thought simple bus was just a convenient helper to represent hierarchical
> bus structures if one has a need to do so.

No. The DT should reflect the bus structure of the chip. How
accurately it is done is up to you and the information available, but
you have to have a bus of some sort.

There's obvious examples that don't follow this, but I'd like to not have more.

Rob


From sboyd at codeaurora.org  Wed Apr 17 14:22:34 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Wed, 17 Apr 2013 11:22:34 -0700
Subject: [GIT PULL] Timer clean-ups for 3.10, Part 2
In-Reply-To: <516EA638.1060800@gmail.com>
References: <516720B4.3000703@gmail.com> <516DEC68.8030101@codeaurora.org>
 <516EA638.1060800@gmail.com>
Message-ID: <516EE86A.9070003@codeaurora.org>

On 04/17/13 06:40, Rob Herring wrote:
> On 04/16/2013 07:27 PM, Stephen Boyd wrote:
>> On 04/11/13 13:44, Rob Herring wrote:
>>> Rob Herring (13):
>>>       ARM: sched_clock: allow changing to higher frequency counter
>>>       ARM: make sched_clock just call a function pointer
>>>       ARM: arch_timer: use full 64-bit counter for sched_clock
>> If I leave my system in the bootloader for a while this seems to cause
>> my sched_clock timestamps to jump once the sched_clock is setup. It also
>> sets up a sched_clock twice because read_sched_clock ==
>> jiffy_sched_clock_read.
>>
>> [    0.000000] Switching to timer-based delay loop
>> [    0.000000] sched_clock: ARM arch timer >56 bits at 19200kHz,
>> resolution 52ns
>> [    0.000000] sched_clock: 32 bits at 100 Hz, resolution 10000000ns,
>> wraps every 4294967286ms
>> [    0.000000] Console: colour dummy device 80x30
>> [16645.193054] Calibrating delay loop (skipped), value calculated using
>> timer frequency.. 38.40 BogoMIPS (lpj=192000)
>>
>> I suspect it's because we don't do any cyc_to_sched_clock() stuff in the
>> arm architected timer case. Instead we just return the value from the
>> counter when we really should do some sort of subtraction from the first
>> value we read.
>>
>> I'm also curious how this is going to work for suspend/resume because it
>> doesn't look like we're going to stop sched_clock on arm architected
>> timer systems. See 6a4dae5e138a3 (ARM: 7565/1: sched: stop sched_clock()
>> during suspend, 2012-10-23) for why we need to do this.
>
> Well, I think arm64 is broken in both ways too. So we should fix this
> for both.
>
> I think this can be handled in a much more simple way than the 32-bit
> code since we don't need to deal with wrapping.
>
> Maintain a cycle offset that starts as the cycle count at init time.
> This offset can be subtracted from the current count. On suspend and
> resume, we need to calculate the cycle count delta while in suspend and
> then add this to the cycle offset.

Agreed. It looks like we're missing out on the irq time accounting stuff
because enable_sched_clock_irqtime() is never called too.

>
>> Finally, looks like this is unused now...
> Yes, but that's unrelated to anything I did.

Yes,  I didn't mean to say it was anything you did.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation



From thomas.petazzoni at free-electrons.com  Wed Apr 17 14:29:31 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Wed, 17 Apr 2013 20:29:31 +0200
Subject: [PATCHv3 00/10] Use the mvebu PCIe driver on Kirkwood
In-Reply-To: <20130417173810.GD27197@titan.lakedaemon.net>
References: <1365865005-26653-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <20130417173810.GD27197@titan.lakedaemon.net>
Message-ID: <20130417202931.1caa78ba@skate>

Dear Jason Cooper,

On Wed, 17 Apr 2013 13:38:10 -0400, Jason Cooper wrote:

> I applied this series to an experimental branch mvebu-late/pcie.  Please
> check that everything is kosher.  I had to add mvebu/boards as a
> dependency since there is a patch in there alphabetizing kirkwood's
> Kconfig (and thus _defconfig).
> 
> *If* rmk creates a stable branch in time, or drops the patch so we can
> take it, this branch will be rebased to fix that.  Currently, it depends
> on rmk/for-next, which is *not* stable.  This is the only public rmk
> branch that has the needed patch.  :-(
> 
> Assuming the above happens, I'll send two PRs, one for the mvebu-pcie
> stuff, then one for the kirkwood-pcie stuff.
> 
> If the stars align, we're ready.  Otherwise, we have everything set to
> go into arm-soc early for the next round.

Awesome, thanks a lot for all your work! I'm pretty sure Russell will
soon put the patch in a branch somewhere and it will unblock the
situation.

Thanks again,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From festevam at gmail.com  Wed Apr 17 14:43:02 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Wed, 17 Apr 2013 15:43:02 -0300
Subject: [PATCH] ARM: mach-imx6q: Remove code for setting up cko clock
Message-ID: <1366224182-29285-1-git-send-email-festevam@gmail.com>

From: Fabio Estevam <fabio.estevam at freescale.com>

Let the bootloader setup the cko clock that drives the audio codec.

This simplifies a lot the code and when a new board needs to add audio support,
it will not have to add all this amount of code again. 

Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
---
 arch/arm/mach-imx/mach-imx6q.c |   25 -------------------------
 1 file changed, 25 deletions(-)

diff --git a/arch/arm/mach-imx/mach-imx6q.c b/arch/arm/mach-imx/mach-imx6q.c
index 5536fd8..fe896a8 100644
--- a/arch/arm/mach-imx/mach-imx6q.c
+++ b/arch/arm/mach-imx/mach-imx6q.c
@@ -113,36 +113,11 @@ static int ksz9021rn_phy_fixup(struct phy_device *phydev)
 	return 0;
 }
 
-static void __init imx6q_sabrelite_cko1_setup(void)
-{
-	struct clk *cko1_sel, *ahb, *cko1;
-	unsigned long rate;
-
-	cko1_sel = clk_get_sys(NULL, "cko1_sel");
-	ahb = clk_get_sys(NULL, "ahb");
-	cko1 = clk_get_sys(NULL, "cko1");
-	if (IS_ERR(cko1_sel) || IS_ERR(ahb) || IS_ERR(cko1)) {
-		pr_err("cko1 setup failed!\n");
-		goto put_clk;
-	}
-	clk_set_parent(cko1_sel, ahb);
-	rate = clk_round_rate(cko1, 16000000);
-	clk_set_rate(cko1, rate);
-put_clk:
-	if (!IS_ERR(cko1_sel))
-		clk_put(cko1_sel);
-	if (!IS_ERR(ahb))
-		clk_put(ahb);
-	if (!IS_ERR(cko1))
-		clk_put(cko1);
-}
-
 static void __init imx6q_sabrelite_init(void)
 {
 	if (IS_BUILTIN(CONFIG_PHYLIB))
 		phy_register_fixup_for_uid(PHY_ID_KSZ9021, MICREL_PHY_ID_MASK,
 				ksz9021rn_phy_fixup);
-	imx6q_sabrelite_cko1_setup();
 }
 
 static void __init imx6q_1588_init(void)
-- 
1.7.9.5



From sergei.shtylyov at cogentembedded.com  Wed Apr 17 14:42:27 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Wed, 17 Apr 2013 22:42:27 +0400
Subject: [PATCH 0/2] Add I2C support to R8A7778/BOCK-W
Message-ID: <201304172242.27671.sergei.shtylyov@cogentembedded.com>

Hello.

   Here's the set of 2 patches against the Simon Horman's 'renesas.git' repo,
'renesas-next-20130417' tag and my recent yet unapplied patches. Here we
add I2C support to the R8A7778 platform code and enable I2C driver on BOCK-W
board. This will be important in the future for the VIN driver since the video
sensor chip is controller via I2C bus #0 on BOCK-W. 

[1/2] ARM: shmobile: r8a7778: add I2C support
[2/2] ARM: shmobile: BOCK-W: enable I2C in defconfig

WBR, Sergei


From sergei.shtylyov at cogentembedded.com  Wed Apr 17 14:44:58 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Wed, 17 Apr 2013 22:44:58 +0400
Subject: [PATCH 1/2] ARM: shmobile: r8a7778: add I2C support
In-Reply-To: <201304172242.27671.sergei.shtylyov@cogentembedded.com>
References: <201304172242.27671.sergei.shtylyov@cogentembedded.com>
Message-ID: <201304172244.59435.sergei.shtylyov@cogentembedded.com>

From: Vladimir Barinov <vladimir.barinov at cogentembedded.com>

Add I2C clocks and platform devices for R8A7778 SoC.
Don't forget to also add the peripheral clock which the I2C driver uses.

Signed-off-by: Vladimir Barinov <vladimir.barinov at cogentembedded.com>
[Sergei: changed the registration function to platform_device_register_simple()]
Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

---
 arch/arm/mach-shmobile/clock-r8a7778.c |   12 ++++++++++++
 arch/arm/mach-shmobile/setup-r8a7778.c |   32 ++++++++++++++++++++++++++++++++
 2 files changed, 44 insertions(+)

Index: renesas/arch/arm/mach-shmobile/clock-r8a7778.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/clock-r8a7778.c
+++ renesas/arch/arm/mach-shmobile/clock-r8a7778.c
@@ -3,6 +3,7 @@
  *
  * Copyright (C) 2013  Renesas Solutions Corp.
  * Copyright (C) 2013  Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
+ * Copyright (C) 2013  Cogent Embedded, Inc.
  *
  * based on r8a7779
  *
@@ -105,6 +106,7 @@ static struct clk *main_clks[] = {
 enum {
 	MSTP114,
 	MSTP100,
+	MSTP030, MSTP029, MSTP028, MSTP027,
 	MSTP026, MSTP025, MSTP024, MSTP023, MSTP022, MSTP021,
 	MSTP016, MSTP015,
 	MSTP_NR };
@@ -112,6 +114,10 @@ enum {
 static struct clk mstp_clks[MSTP_NR] = {
 	[MSTP114] = SH_CLK_MSTP32(&p_clk, MSTPCR1, 14, 0), /* Ether */
 	[MSTP100] = SH_CLK_MSTP32(&p_clk, MSTPCR1,  0, 0), /* USB0/1 */
+	[MSTP030] = SH_CLK_MSTP32(&p_clk, MSTPCR0, 30, 0), /* I2C0 */
+	[MSTP029] = SH_CLK_MSTP32(&p_clk, MSTPCR0, 29, 0), /* I2C1 */
+	[MSTP028] = SH_CLK_MSTP32(&p_clk, MSTPCR0, 28, 0), /* I2C2 */
+	[MSTP027] = SH_CLK_MSTP32(&p_clk, MSTPCR0, 27, 0), /* I2C3 */
 	[MSTP026] = SH_CLK_MSTP32(&p_clk, MSTPCR0, 26, 0), /* SCIF0 */
 	[MSTP025] = SH_CLK_MSTP32(&p_clk, MSTPCR0, 25, 0), /* SCIF1 */
 	[MSTP024] = SH_CLK_MSTP32(&p_clk, MSTPCR0, 24, 0), /* SCIF2 */
@@ -123,10 +129,16 @@ static struct clk mstp_clks[MSTP_NR] = {
 };
 
 static struct clk_lookup lookups[] = {
+	CLKDEV_CON_ID("peripheral_clk", &p_clk),
+
 	/* MSTP32 clocks */
 	CLKDEV_DEV_ID("sh-eth",	&mstp_clks[MSTP114]), /* Ether */
 	CLKDEV_DEV_ID("ehci-platform", &mstp_clks[MSTP100]), /* USB EHCI port0/1 */
 	CLKDEV_DEV_ID("ohci-platform", &mstp_clks[MSTP100]), /* USB OHCI port0/1 */
+	CLKDEV_DEV_ID("i2c-rcar.0", &mstp_clks[MSTP030]), /* I2C0 */
+	CLKDEV_DEV_ID("i2c-rcar.1", &mstp_clks[MSTP029]), /* I2C1 */
+	CLKDEV_DEV_ID("i2c-rcar.2", &mstp_clks[MSTP028]), /* I2C2 */
+	CLKDEV_DEV_ID("i2c-rcar.3", &mstp_clks[MSTP027]), /* I2C3 */
 	CLKDEV_DEV_ID("sh-sci.0", &mstp_clks[MSTP026]), /* SCIF0 */
 	CLKDEV_DEV_ID("sh-sci.1", &mstp_clks[MSTP025]), /* SCIF1 */
 	CLKDEV_DEV_ID("sh-sci.2", &mstp_clks[MSTP024]), /* SCIF2 */
Index: renesas/arch/arm/mach-shmobile/setup-r8a7778.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/setup-r8a7778.c
+++ renesas/arch/arm/mach-shmobile/setup-r8a7778.c
@@ -94,6 +94,33 @@ static struct sh_timer_config sh_tmu1_pl
 		&sh_tmu##idx##_platform_data,		\
 		sizeof(sh_tmu##idx##_platform_data))
 
+/* I2C */
+static struct resource i2c0_resources[] = {
+	DEFINE_RES_MEM(0xffc70000, 0x1000),
+	DEFINE_RES_IRQ(gic_iid(0x63)),
+};
+
+static struct resource i2c1_resources[] = {
+	DEFINE_RES_MEM(0xffc71000, 0x1000),
+	DEFINE_RES_IRQ(gic_iid(0x6e)),
+};
+
+static struct resource i2c2_resources[] = {
+	DEFINE_RES_MEM(0xffc72000, 0x1000),
+	DEFINE_RES_IRQ(gic_iid(0x6c)),
+};
+
+static struct resource i2c3_resources[] = {
+	DEFINE_RES_MEM(0xffc73000, 0x1000),
+	DEFINE_RES_IRQ(gic_iid(0x6d)),
+};
+
+#define r8a7778_register_i2c(idx)			\
+	platform_device_register_simple(		\
+		"i2c-rcar", idx,			\
+		i2c##idx##_resources,			\
+		ARRAY_SIZE(i2c##idx##_resources))
+
 /* USB PHY */
 static struct resource usb_phy_resources[] = {
 	DEFINE_RES_MEM(0xffe70800, 0x100),
@@ -236,6 +263,11 @@ void __init r8a7778_add_standard_devices
 
 	r8a7778_register_tmu(0);
 	r8a7778_register_tmu(1);
+
+	r8a7778_register_i2c(0);
+	r8a7778_register_i2c(1);
+	r8a7778_register_i2c(2);
+	r8a7778_register_i2c(3);
 }
 
 void __init r8a7778_init_late(void)



From sergei.shtylyov at cogentembedded.com  Wed Apr 17 14:47:27 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Wed, 17 Apr 2013 22:47:27 +0400
Subject: [PATCH 2/2] ARM: shmobile: BOCK-W: enable I2C in defconfig
In-Reply-To: <201304172242.27671.sergei.shtylyov@cogentembedded.com>
References: <201304172242.27671.sergei.shtylyov@cogentembedded.com>
Message-ID: <201304172247.28311.sergei.shtylyov@cogentembedded.com>

From: Vladimir Barinov <vladimir.barinov at cogentembedded.com>

Enable I2C driver in 'bockw_defconfig'.

Signed-off-by: Vladimir Barinov <vladimir.barinov at cogentembedded.com>
Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

---
 arch/arm/configs/bockw_defconfig |    2 ++
 1 file changed, 2 insertions(+)

Index: renesas/arch/arm/configs/bockw_defconfig
===================================================================
--- renesas.orig/arch/arm/configs/bockw_defconfig
+++ renesas/arch/arm/configs/bockw_defconfig
@@ -73,6 +73,8 @@ CONFIG_SERIAL_SH_SCI_NR_UARTS=6
 CONFIG_SERIAL_SH_SCI_CONSOLE=y
 # CONFIG_HW_RANDOM is not set
 # CONFIG_HWMON is not set
+CONFIG_I2C=y
+CONFIG_I2C_RCAR=y
 CONFIG_USB=y
 CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
 CONFIG_USB_EHCI_HCD=y


From olof at lixom.net  Wed Apr 17 14:48:27 2013
From: olof at lixom.net (Olof Johansson)
Date: Wed, 17 Apr 2013 11:48:27 -0700
Subject: [GIT PULL] Timer clean-ups for 3.10, Part 2
In-Reply-To: <20130417165742.GB8730@quad.lixom.net>
References: <516720B4.3000703@gmail.com>
 <20130413065056.GB14735@quad.lixom.net>
 <516C0257.8040103@gmail.com> <201304152320.28401.arnd@arndb.de>
 <20130417165742.GB8730@quad.lixom.net>
Message-ID: <20130417184827.GA22799@quad.lixom.net>

On Wed, Apr 17, 2013 at 09:57:42AM -0700, Olof Johansson wrote:
> On Mon, Apr 15, 2013 at 11:20:28PM +0200, Arnd Bergmann wrote:
> > On Monday 15 April 2013, Rob Herring wrote:
> > > It is quite messed up because the mct timer changes are not based on
> > > arm-soc/clksrc/cleanup. Any timer changes adding CLKSRC_OF support need
> > > to be based on this. I've fixed it up in this branch (untested):
> > > 
> > > git://sources.calxeda.com/kernel/linux.git exynos-mct-merge
> > > 
> > > I merged with clksrc-cleanup-for-3.10-part2 and fixed it in the merge,
> > > but really either the mct branch should be rebased or some of the
> > > changes can be a preparatory commit before merging.
> > 
> > Note that I also merged the branches when pulling in the samsung changes,
> > and did a complex merge there. We should ensure that we use the same
> > merge here.
> 
> Hrm, this is now a total mess. I can pick up Rob's preferred resolution,
> but merging that in on top of the exynos branches causes lots of conflicts
> there as well.
> 
> I might just have to rebuild the next/ branches in question to resolve
> this.  Either that or bring the late/clksrc stuff into the same branch
> as the exynos timer patches.

Ok, given the complex merge fixup by Arnd (I'm not sure it's a great
idea to add the new code in the merge commit like that, by the way),
I've chosen to go with that as a base for late/clksrc instead, and I've
pushed a new rebased late/clksrc that contains Arnd's version of the
resolutions instead of Rob's. Let me know if further fixups are needed,
in particular on exynos4 since I lack hardware to test that side.


-Olof


From olof at lixom.net  Wed Apr 17 15:01:42 2013
From: olof at lixom.net (Olof Johansson)
Date: Wed, 17 Apr 2013 12:01:42 -0700
Subject: [PATCH] ARM: shmobile: add missing include of of.h
Message-ID: <1366225302-23150-1-git-send-email-olof@lixom.net>

Fixes the following build warnings:

In file included from arch/arm/mach-shmobile/setup-r8a7779.c:25:0:
include/linux/of_platform.h:107:13: warning: 'struct of_device_id' declared inside parameter list [enabled by default]
include/linux/of_platform.h:107:13: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default]
include/linux/of_platform.h:107:13: warning: 'struct device_node' declared inside parameter list [enabled by default]

Signed-off-by: Olof Johansson <olof at lixom.net>
---

Hi Simon,

I'll just apply this directly if it's OK with you?



-Olof

 arch/arm/mach-shmobile/setup-r8a7779.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-shmobile/setup-r8a7779.c b/arch/arm/mach-shmobile/setup-r8a7779.c
index b0b3948..7413fc0 100644
--- a/arch/arm/mach-shmobile/setup-r8a7779.c
+++ b/arch/arm/mach-shmobile/setup-r8a7779.c
@@ -22,6 +22,7 @@
 #include <linux/init.h>
 #include <linux/interrupt.h>
 #include <linux/irq.h>
+#include <linux/of.h>
 #include <linux/of_platform.h>
 #include <linux/platform_data/gpio-rcar.h>
 #include <linux/platform_device.h>
-- 
1.8.1.192.gc4361b8



From linux at arm.linux.org.uk  Wed Apr 17 15:05:19 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Wed, 17 Apr 2013 20:05:19 +0100
Subject: [PATCH v11 1/3] ARM: Add base support for ARMv7-M
In-Reply-To: <1366215299-31969-2-git-send-email-u.kleine-koenig@pengutronix.de>
References: <1366215299-31969-1-git-send-email-u.kleine-koenig@pengutronix.de>
 <1366215299-31969-2-git-send-email-u.kleine-koenig@pengutronix.de>
Message-ID: <20130417190519.GC14496@n2100.arm.linux.org.uk>

On Wed, Apr 17, 2013 at 06:14:57PM +0200, Uwe Kleine-K?nig wrote:
> From: Catalin Marinas <catalin.marinas at arm.com>
> 
> This patch adds the base support for the ARMv7-M
> architecture. It consists of the corresponding arch/arm/mm/ files and
> various #ifdef's around the kernel. Exception handling is implemented by
> a subsequent patch.
> 
> [ukleinek: squash in some changes originating from commit
> 
> b5717ba (Cortex-M3: Add support for the Microcontroller Prototyping System)
> 
> from the v2.6.33-arm1 patch stack, port to post 3.6, drop zImage
> support, drop reorganisation of pt_regs, assert CONFIG_V7M doesn't leak
> into installed headers and a few cosmetic changes]

ITYM CONFIG_CPU_V7M.  Apart from that, it looks fine.


From linux at arm.linux.org.uk  Wed Apr 17 15:08:29 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Wed, 17 Apr 2013 20:08:29 +0100
Subject: [PATCH v11 0/3] Another round of ARMv7-M patches
In-Reply-To: <1366215299-31969-1-git-send-email-u.kleine-koenig@pengutronix.de>
References: <1366215299-31969-1-git-send-email-u.kleine-koenig@pengutronix.de>
Message-ID: <20130417190829.GD14496@n2100.arm.linux.org.uk>

On Wed, Apr 17, 2013 at 06:14:56PM +0200, Uwe Kleine-K?nig wrote:
> Russell, what are your thoughts about the series? Would you take it for
> v3.10? Or v3.11?

On the whole, I think I'm fairly happy with this.  Has it been in -next
at all yet?


From dmurphy at ti.com  Wed Apr 17 15:09:37 2013
From: dmurphy at ti.com (Dan Murphy)
Date: Wed, 17 Apr 2013 14:09:37 -0500
Subject: [PATCH] Fix omap4 panda LED definitions
Message-ID: <1366225778-6083-1-git-send-email-dmurphy@ti.com>

The LED GPIOs between the 4430 (a1-a4) and 4460 (es) panda boards
are different.  This patch abstracts the LED definitions into the 
respective board files.



From dmurphy at ti.com  Wed Apr 17 15:09:38 2013
From: dmurphy at ti.com (Dan Murphy)
Date: Wed, 17 Apr 2013 14:09:38 -0500
Subject: [PATCH] ARM: dts: omap4-panda: Add LED support into the panda DTS
 files
In-Reply-To: <1366225778-6083-1-git-send-email-dmurphy@ti.com>
References: <1366225778-6083-1-git-send-email-dmurphy@ti.com>
Message-ID: <1366225778-6083-2-git-send-email-dmurphy@ti.com>

The GPIO for LED D1 on the omap4-panda a1-a3 rev and the omap4-panda-es
are different.

Abstract away the pinmux and the LED definitions for the two boards.

Signed-off-by: Dan Murphy <dmurphy at ti.com>
---
 arch/arm/boot/dts/omap4-panda-es.dts |   33 +++++++++++++++++++++++++++++++++
 arch/arm/boot/dts/omap4-panda.dts    |   22 +++++++++++++++++++++-
 2 files changed, 54 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/omap4-panda-es.dts b/arch/arm/boot/dts/omap4-panda-es.dts
index 73bc1a6..42fdd86 100644
--- a/arch/arm/boot/dts/omap4-panda-es.dts
+++ b/arch/arm/boot/dts/omap4-panda-es.dts
@@ -31,3 +31,36 @@
 		0x5e 0x100	/* hdmi_sda.hdmi_sda INPUT | MODE 0 */
 		>;
 };
+
+&leds {
+	compatible = "gpio-leds";
+	heartbeat {
+		label = "pandaboard::status1";
+		gpios = <&gpio4 14 0>;
+		linux,default-trigger = "heartbeat";
+	};
+	mmc {
+		label = "pandaboard::status2";
+		gpios = <&gpio1 8 0>;
+		linux,default-trigger = "gpio";
+	};
+};
+
+&led_gpio_pins {
+	pinctrl-single,pins = <
+		0xb6 0x3	/* gpio_110 OUTPUT | MODE 3 */
+	>;
+};
+
+&omap4_pmx_wkup {
+	pinctrl-names = "default";
+	pinctrl-0 = <
+		&led_wkgpio_pins
+	>;
+
+	led_wkgpio_pins: pinmux_leds_wkpins {
+		pinctrl-single,pins = <
+			0x1c 0x3	/* gpio_wk8 OUTPUT | MODE 3 */
+		>;
+	};
+};
diff --git a/arch/arm/boot/dts/omap4-panda.dts b/arch/arm/boot/dts/omap4-panda.dts
index 4122efe..465c4b0b8 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -19,7 +19,7 @@
 		reg = <0x80000000 0x40000000>; /* 1 GB */
 	};
 
-	leds {
+	leds: leds{
 		compatible = "gpio-leds";
 		heartbeat {
 			label = "pandaboard::status1";
@@ -67,6 +67,7 @@
 			&mcbsp1_pins
 			&dss_hdmi_pins
 			&tpd12s015_pins
+			&led_gpio_pins
 	>;
 
 	twl6040_pins: pinmux_twl6040_pins {
@@ -110,6 +111,25 @@
 			0x58 0x10b	/* hdmi_hpd.gpio_63 INPUT PULLDOWN | MODE3 */
 		>;
 	};
+
+	led_gpio_pins: pinmux_leds_pins {
+		pinctrl-single,pins = <
+		>;
+	};
+};
+
+&omap4_pmx_wkup {
+	pinctrl-names = "default";
+	pinctrl-0 = <
+		&led_wkgpio_pins
+	>;
+
+	led_wkgpio_pins: pinmux_leds_wkpins {
+		pinctrl-single,pins = <
+			0x1a 0x3	/* gpio_wk7 OUTPUT | MODE 3 */
+			0x1c 0x3	/* gpio_wk8 OUTPUT | MODE 3 */
+		>;
+	};
 };
 
 &i2c1 {
-- 
1.7.9.5



From jon-hunter at ti.com  Wed Apr 17 15:18:54 2013
From: jon-hunter at ti.com (Jon Hunter)
Date: Wed, 17 Apr 2013 14:18:54 -0500
Subject: [PATCH] ARM: dts: omap4-panda: Add LED support into the panda
 DTS files
In-Reply-To: <1366225778-6083-2-git-send-email-dmurphy@ti.com>
References: <1366225778-6083-1-git-send-email-dmurphy@ti.com>
 <1366225778-6083-2-git-send-email-dmurphy@ti.com>
Message-ID: <516EF59E.3090907@ti.com>


On 04/17/2013 02:09 PM, Dan Murphy wrote:
> The GPIO for LED D1 on the omap4-panda a1-a3 rev and the omap4-panda-es
> are different.
> 
> Abstract away the pinmux and the LED definitions for the two boards.

Just a heads-up but you should base this upon Benoit's for_3.10 branch
[1] as there is now a omap4-panda-common.dtsi where the led stuff
currently resides.

Cheers
Jon

[1]
http://git.kernel.org/cgit/linux/kernel/git/bcousson/linux-omap-dt.git/log/?h=for_3.10/dts


From cdall at cs.columbia.edu  Wed Apr 17 15:28:42 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Wed, 17 Apr 2013 12:28:42 -0700
Subject: [PATCH] ARM: KVM: iterate over all CPUs for CPU compatibility
 check
In-Reply-To: <516E9CD3.40909@arm.com>
References: <1365771875-5788-1-git-send-email-andre.przywara@linaro.org>
 <51680AF9.7040109@arm.com>
 <CAFEAcA-1HAG0pY-j-rqU=QmSoep3Di-KNPATvuou8ghRn3SaqA@mail.gmail.com>
 <516810F7.7040601@arm.com>
 <20130417101906.GX14496@n2100.arm.linux.org.uk>
 <516E7ADE.5090601@arm.com>
 <CAEDV+gK3nitpN+8ZePRY7n+bsc2t4XbWrz6fbdz0Wjq_kTgM4g@mail.gmail.com>
 <516E87D1.5000109@arm.com>
 <CAFEAcA8oE+2BRRgoeA4-0PzOQkxzGwDT5qunudzg7RBA9aWCgQ@mail.gmail.com>
 <516E9466.2070805@arm.com>
 <CAFEAcA8ty-hWUZtjiEvZDNNDCwkT6NhsuF0wneSTuugWDB3uHQ@mail.gmail.com>
 <516E958B.7080300@arm.com>
 <CAFEAcA_FdUwFCmxm9yEF5fP1SGyfh=RG8RqEx51k95PRMeQPAw@mail.gmail.com>
 <516E9CD3.40909@arm.com>
Message-ID: <CAEDV+gJwdcRkr6xjhKu_rvoGLT6KHRg7HQzbEBh3uJNVvgeUfg@mail.gmail.com>

On Wed, Apr 17, 2013 at 6:00 AM, Marc Zyngier <marc.zyngier at arm.com> wrote:
> On 17/04/13 13:38, Peter Maydell wrote:
>> On 17 April 2013 13:28, Marc Zyngier <marc.zyngier at arm.com> wrote:
>>> On 17/04/13 13:25, Peter Maydell wrote:
>>>> On 17 April 2013 13:24, Marc Zyngier <marc.zyngier at arm.com> wrote:
>>>>> On 17/04/13 12:38, Peter Maydell wrote
>>>>>> Who says the code should support running on big.LITTLE?
>>>>>
>>>>> I do. The host code definitely should. If it doesn't, then lets fix that
>>>>> bug, as it probably means the support is also broken on A15.
>>>>
>>>> Last time I looked we weren't intercepting ID and feature
>>>> registers. That's broken if the host isn't A15.
>>>
>>> Would you please look at the sentence that follows the one you've
>>> quoted? It says "guest support is a separate issue". As in "orthogonal
>>> problem".
>>
>> I'm confused now, because I thought the whole point of this
>> patch was that we don't support guests on big.LITTLE but
>> we're not locking them out (the way we would for an all-A7
>> system). That is, we're fixing a bug in the check code.
>>
>> Obviously it seems worth investigating exactly what is
>> happening on the A7s when we try to run the init code,
>> but it seems to me like that's the orthogonal issue,
>> because we shouldn't be running that code in the first
>> place.
>
> Turns out that init code was designed to run unchanged on both A15 and
> A7. If that code isn't properly working on a HYP-aware CPU, then we're
> in trouble.
>

yes yes, we agree here, but it's a separate issue.

> I don't give a damn about full BL support in KVM at that stage. All I
> want is a clear description of *why* that code is failing, and possibly
> a way to run guests on the A15 side of a BL platform, without having to
> give away half of the cores.
>
> I think I've already spent too much time arguing about this. Hopefully
> someone will be interested enough in BL to revert this patch and fix the
> code (whether it is in the kernel or bootloader).
>

Currently we only support A15s, and that's explicit.

You're arguing that we should pretend like we support other systems as
well, should we then also just remove the check all together and let
KVM run on a krait, on an A42 [1], and on foo, and hope for the best?
Or should we be nice and tell the rest of the system, sorry this is
not supported yet? I think the latter.

Seriously, I don't think it sounds like a quick fix to make the code
run only on A15s on BL, but if you do, please send the patch, and I'll
be happy to review and merge that code.

-Christoffer

[1]: Made this up.


From u.kleine-koenig at pengutronix.de  Wed Apr 17 15:30:28 2013
From: u.kleine-koenig at pengutronix.de (Uwe =?iso-8859-1?Q?Kleine-K=F6nig?=)
Date: Wed, 17 Apr 2013 21:30:28 +0200
Subject: [PATCH v11 0/3] Another round of ARMv7-M patches
In-Reply-To: <20130417190829.GD14496@n2100.arm.linux.org.uk>
References: <1366215299-31969-1-git-send-email-u.kleine-koenig@pengutronix.de>
 <20130417190829.GD14496@n2100.arm.linux.org.uk>
Message-ID: <20130417193028.GQ30416@pengutronix.de>

Hello Russell,

On Wed, Apr 17, 2013 at 08:08:29PM +0100, Russell King - ARM Linux wrote:
> On Wed, Apr 17, 2013 at 06:14:56PM +0200, Uwe Kleine-K?nig wrote:
> > Russell, what are your thoughts about the series? Would you take it for
> > v3.10? Or v3.11?
> 
> On the whole, I think I'm fairly happy with this.  Has it been in -next
> at all yet?
An earlier version was, but I guess that doesn't count. Still it makes
me expect not to break too much :-)

This version (based on a commit in your devel-stable) (+ a fix for the
typo you pointed out) should be picked up for the next next. 

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |


From cdall at cs.columbia.edu  Wed Apr 17 15:37:00 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Wed, 17 Apr 2013 12:37:00 -0700
Subject: [PATCH v4 3/7] ARM: KVM: move to a KVM provided HYP idmap
In-Reply-To: <1365790327-2138-4-git-send-email-marc.zyngier@arm.com>
References: <1365790327-2138-1-git-send-email-marc.zyngier@arm.com>
 <1365790327-2138-4-git-send-email-marc.zyngier@arm.com>
Message-ID: <CAEDV+gK=4VwBQUNkAWSmo3j1A2GwewXctNno3NBpyOFG0C8YFw@mail.gmail.com>

On Fri, Apr 12, 2013 at 11:12 AM, Marc Zyngier <marc.zyngier at arm.com> wrote:
> After the HYP page table rework, it is pretty easy to let the KVM
> code provide its own idmap, rather than expecting the kernel to
> provide it. It takes actually less code to do so.
>
> Acked-by: Will Deacon <will.deacon at arm.com>
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> ---
>  arch/arm/include/asm/idmap.h   |  1 -
>  arch/arm/include/asm/kvm_mmu.h |  1 -
>  arch/arm/kvm/mmu.c             | 24 +++++++++++++++++++++++-
>  arch/arm/mm/idmap.c            | 32 +-------------------------------
>  4 files changed, 24 insertions(+), 34 deletions(-)
>
> diff --git a/arch/arm/include/asm/idmap.h b/arch/arm/include/asm/idmap.h
> index 1a66f907..bf863ed 100644
> --- a/arch/arm/include/asm/idmap.h
> +++ b/arch/arm/include/asm/idmap.h
> @@ -8,7 +8,6 @@
>  #define __idmap __section(.idmap.text) noinline notrace
>
>  extern pgd_t *idmap_pgd;
> -extern pgd_t *hyp_pgd;
>
>  void setup_mm_for_reboot(void);
>
> diff --git a/arch/arm/include/asm/kvm_mmu.h b/arch/arm/include/asm/kvm_mmu.h
> index 970f3b5..3c71a1d 100644
> --- a/arch/arm/include/asm/kvm_mmu.h
> +++ b/arch/arm/include/asm/kvm_mmu.h
> @@ -21,7 +21,6 @@
>
>  #include <asm/cacheflush.h>
>  #include <asm/pgalloc.h>
> -#include <asm/idmap.h>
>
>  /*
>   * We directly use the kernel VA for the HYP, as we can directly share
> diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
> index 96d61da..bfc5927 100644
> --- a/arch/arm/kvm/mmu.c
> +++ b/arch/arm/kvm/mmu.c
> @@ -32,6 +32,7 @@
>
>  extern char  __hyp_idmap_text_start[], __hyp_idmap_text_end[];
>
> +static pgd_t *hyp_pgd;
>  static DEFINE_MUTEX(kvm_hyp_pgd_mutex);
>
>  static void kvm_tlb_flush_vmid_ipa(struct kvm *kvm, phys_addr_t ipa)
> @@ -715,12 +716,33 @@ phys_addr_t kvm_mmu_get_httbr(void)
>
>  int kvm_mmu_init(void)
>  {
> +       unsigned long hyp_idmap_start = virt_to_phys(__hyp_idmap_text_start);
> +       unsigned long hyp_idmap_end = virt_to_phys(__hyp_idmap_text_end);
> +       int err;
> +
> +       hyp_pgd = kzalloc(PTRS_PER_PGD * sizeof(pgd_t), GFP_KERNEL);
>         if (!hyp_pgd) {
>                 kvm_err("Hyp mode PGD not allocated\n");
> -               return -ENOMEM;
> +               err = -ENOMEM;
> +               goto out;
> +       }
> +
> +       /* Create the idmap in the boot page tables */
> +       err =   __create_hyp_mappings(boot_hyp_pgd,
> +                                     hyp_idmap_start, hyp_idmap_end,
> +                                     __phys_to_pfn(hyp_idmap_start),
> +                                     PAGE_HYP);
> +
> +       if (err) {
> +               kvm_err("Failed to idmap %lx-%lx\n",
> +                       hyp_idmap_start, hyp_idmap_end);
> +               goto out;
>         }
>
>         return 0;
> +out:
> +       kfree(hyp_pgd);
> +       return err;
>  }
>
>  /**
> diff --git a/arch/arm/mm/idmap.c b/arch/arm/mm/idmap.c
> index 5ee505c..83cb3ac 100644
> --- a/arch/arm/mm/idmap.c
> +++ b/arch/arm/mm/idmap.c
> @@ -8,7 +8,6 @@
>  #include <asm/pgtable.h>
>  #include <asm/sections.h>
>  #include <asm/system_info.h>
> -#include <asm/virt.h>
>
>  pgd_t *idmap_pgd;
>
> @@ -83,37 +82,10 @@ static void identity_mapping_add(pgd_t *pgd, const char *text_start,
>         } while (pgd++, addr = next, addr != end);
>  }
>
> -#if defined(CONFIG_ARM_VIRT_EXT) && defined(CONFIG_ARM_LPAE)
> -pgd_t *hyp_pgd;
> -
> -extern char  __hyp_idmap_text_start[], __hyp_idmap_text_end[];
> -
> -static int __init init_static_idmap_hyp(void)
> -{
> -       hyp_pgd = kzalloc(PTRS_PER_PGD * sizeof(pgd_t), GFP_KERNEL);
> -       if (!hyp_pgd)
> -               return -ENOMEM;
> -
> -       pr_info("Setting up static HYP identity map for 0x%p - 0x%p\n",
> -               __hyp_idmap_text_start, __hyp_idmap_text_end);
> -       identity_mapping_add(hyp_pgd, __hyp_idmap_text_start,
> -                            __hyp_idmap_text_end, PMD_SECT_AP1);
> -
> -       return 0;
> -}
> -#else
> -static int __init init_static_idmap_hyp(void)
> -{
> -       return 0;
> -}
> -#endif
> -
>  extern char  __idmap_text_start[], __idmap_text_end[];
>
>  static int __init init_static_idmap(void)
>  {
> -       int ret;
> -
>         idmap_pgd = pgd_alloc(&init_mm);
>         if (!idmap_pgd)
>                 return -ENOMEM;
> @@ -123,12 +95,10 @@ static int __init init_static_idmap(void)
>         identity_mapping_add(idmap_pgd, __idmap_text_start,
>                              __idmap_text_end, 0);
>
> -       ret = init_static_idmap_hyp();
> -
>         /* Flush L1 for the hardware to see this page table content */
>         flush_cache_louis();
>
> -       return ret;
> +       return 0;
>  }
>  early_initcall(init_static_idmap);
>
> --
> 1.8.1.4
>

Russell,

I would appreciate your ack on this one so we can merge this through
the KVM tree, or alternatively let us know if this needs to go your
tree, so we can plan accordingly for the next merge window.

Thanks a bunch,
-Christoffer


From u.kleine-koenig at pengutronix.de  Wed Apr 17 15:37:46 2013
From: u.kleine-koenig at pengutronix.de (Uwe =?iso-8859-1?Q?Kleine-K=F6nig?=)
Date: Wed, 17 Apr 2013 21:37:46 +0200
Subject: [PATCH v11 0/3] Another round of ARMv7-M patches
In-Reply-To: <516EDEDA.1000108@arm.com>
References: <1366215299-31969-1-git-send-email-u.kleine-koenig@pengutronix.de>
 <516EDEDA.1000108@arm.com>
Message-ID: <20130417193746.GR30416@pengutronix.de>

Hello,

On Wed, Apr 17, 2013 at 06:41:46PM +0100, Jonathan Austin wrote:
> The only comment I have left is that I'd really like the
> BASEADDRESS_V7M_SCB namespaced like the rest of the V7M defines
The idea behind this naming is that V7M_SCB_BASEADDRESS is in the same
namespace as V7M_SCB_CPUID so I opened a new namespace for base
addresses. Don't you like it only because it's new? Do others have
thoughts here?

> With that said, please feel free to add for the series:
> 
> Reviewed-by: Jonathan Austin <jonathan.austin at arm.com>
> Tested-by: Jonathan Austin <jonathan.austin at arm.com
Thanks
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |


From dmurphy at ti.com  Wed Apr 17 15:46:58 2013
From: dmurphy at ti.com (Dan Murphy)
Date: Wed, 17 Apr 2013 14:46:58 -0500
Subject: [PATCH] ARM: dts: omap4-panda: Add LED support into the panda
 DTS files
In-Reply-To: <516EF59E.3090907@ti.com>
References: <1366225778-6083-1-git-send-email-dmurphy@ti.com>
 <1366225778-6083-2-git-send-email-dmurphy@ti.com> <516EF59E.3090907@ti.com>
Message-ID: <516EFC32.6030005@ti.com>

On 04/17/2013 02:18 PM, Jon Hunter wrote:
> On 04/17/2013 02:09 PM, Dan Murphy wrote:
>> The GPIO for LED D1 on the omap4-panda a1-a3 rev and the omap4-panda-es
>> are different.
>>
>> Abstract away the pinmux and the LED definitions for the two boards.
> Just a heads-up but you should base this upon Benoit's for_3.10 branch
> [1] as there is now a omap4-panda-common.dtsi where the led stuff
> currently resides.
>
> Cheers
> Jon
>
> [1]
> http://git.kernel.org/cgit/linux/kernel/git/bcousson/linux-omap-dt.git/log/?h=for_3.10/dts
Thanks Jon.  Will resend against Benoit's tree.

Dan

-- 
----------------------------------------------
Dan Murphy



From ezequiel.garcia at free-electrons.com  Wed Apr 17 15:51:34 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Wed, 17 Apr 2013 16:51:34 -0300
Subject: [PATCH] ARM: mvebu: Add support for USB storage class in
 mvebu_defconfig
Message-ID: <1366228294-24437-1-git-send-email-ezequiel.garcia@free-electrons.com>

Some boards can have built-in USB storage class controllers so
it's better to have this option included by default.

Currently this option is needed to support built-in USB MMC controller
found in Globalscale Mirabox board.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
---
This is not important and can be delayed for v3.11 if it's already
too late for v3.10. The change is harmless in any case.

 arch/arm/configs/mvebu_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/mvebu_defconfig b/arch/arm/configs/mvebu_defconfig
index f3e8ae0..0837829 100644
--- a/arch/arm/configs/mvebu_defconfig
+++ b/arch/arm/configs/mvebu_defconfig
@@ -60,6 +60,7 @@ CONFIG_USB_SUPPORT=y
 CONFIG_USB=y
 CONFIG_USB_EHCI_HCD=y
 CONFIG_USB_EHCI_ROOT_HUB_TT=y
+CONFIG_USB_STORAGE=y
 CONFIG_MMC=y
 CONFIG_MMC_MVSDIO=y
 CONFIG_NEW_LEDS=y
-- 
1.8.1.5



From s.hauer at pengutronix.de  Wed Apr 17 15:57:44 2013
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Wed, 17 Apr 2013 21:57:44 +0200
Subject: [PATCH] ARM: mach-imx6q: Remove code for setting up cko clock
In-Reply-To: <1366224182-29285-1-git-send-email-festevam@gmail.com>
References: <1366224182-29285-1-git-send-email-festevam@gmail.com>
Message-ID: <20130417195744.GX1906@pengutronix.de>

On Wed, Apr 17, 2013 at 03:43:02PM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam at freescale.com>
> 
> Let the bootloader setup the cko clock that drives the audio codec.
> 

I really don't like such stuff. Where is documented what's expected from
the bootloader? Which versions of which bootloader do implement this?

The code you remove is not particularly nice, but just removing it is no
solution to the problem.


> This simplifies a lot the code and when a new board needs to add audio support,
> it will not have to add all this amount of code again. 

It shouldn't be necessary to duplicate the code for each board.

Sascha

> 
> Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
> ---
>  arch/arm/mach-imx/mach-imx6q.c |   25 -------------------------
>  1 file changed, 25 deletions(-)
> 
> diff --git a/arch/arm/mach-imx/mach-imx6q.c b/arch/arm/mach-imx/mach-imx6q.c
> index 5536fd8..fe896a8 100644
> --- a/arch/arm/mach-imx/mach-imx6q.c
> +++ b/arch/arm/mach-imx/mach-imx6q.c
> @@ -113,36 +113,11 @@ static int ksz9021rn_phy_fixup(struct phy_device *phydev)
>  	return 0;
>  }
>  
> -static void __init imx6q_sabrelite_cko1_setup(void)
> -{
> -	struct clk *cko1_sel, *ahb, *cko1;
> -	unsigned long rate;
> -
> -	cko1_sel = clk_get_sys(NULL, "cko1_sel");
> -	ahb = clk_get_sys(NULL, "ahb");
> -	cko1 = clk_get_sys(NULL, "cko1");
> -	if (IS_ERR(cko1_sel) || IS_ERR(ahb) || IS_ERR(cko1)) {
> -		pr_err("cko1 setup failed!\n");
> -		goto put_clk;
> -	}
> -	clk_set_parent(cko1_sel, ahb);
> -	rate = clk_round_rate(cko1, 16000000);
> -	clk_set_rate(cko1, rate);
> -put_clk:
> -	if (!IS_ERR(cko1_sel))
> -		clk_put(cko1_sel);
> -	if (!IS_ERR(ahb))
> -		clk_put(ahb);
> -	if (!IS_ERR(cko1))
> -		clk_put(cko1);
> -}
> -
>  static void __init imx6q_sabrelite_init(void)
>  {
>  	if (IS_BUILTIN(CONFIG_PHYLIB))
>  		phy_register_fixup_for_uid(PHY_ID_KSZ9021, MICREL_PHY_ID_MASK,
>  				ksz9021rn_phy_fixup);
> -	imx6q_sabrelite_cko1_setup();
>  }
>  
>  static void __init imx6q_1588_init(void)
> -- 
> 1.7.9.5
> 
> 

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From arnd at arndb.de  Wed Apr 17 16:05:35 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed, 17 Apr 2013 22:05:35 +0200
Subject: [PATCH 29/30] spi: s3c64xx: move to generic dmaengine API
In-Reply-To: <1365638712-1028578-30-git-send-email-arnd@arndb.de>
References: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
 <1365638712-1028578-30-git-send-email-arnd@arndb.de>
Message-ID: <201304172205.35526.arnd@arndb.de>

On Thursday 11 April 2013, Arnd Bergmann wrote:
> @@ -713,9 +836,9 @@ static int s3c64xx_spi_transfer_one_message(struct spi_master *master,
>                 }
>  
>                 /* Polling method for xfers not bigger than FIFO capacity */
> -               if (xfer->len <= ((FIFO_LVL_MASK(sdd) >> 1) + 1))
> -                       use_dma = 0;
> -               else
> +               use_dma = 0;
> +               if (sdd->rx_dma.ch && sdd->tx_dma.ch &&
> +                   (xfer->len > ((FIFO_LVL_MASK(sdd) >> 1) + 1)))
>                         use_dma = 1;
>  
>                 spin_lock_irqsave(&sdd->lock, flags);

Can you try just reverting this hunk? It's actually not required and
comes from an earlier version of the patch. I assumed it was harmless,
but it's the only think I see that should actually make a difference
in my patch for the case of !CONFIG_SAMSUNG_DMADEV.

	Arnd


From sboyd at codeaurora.org  Wed Apr 17 16:09:15 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Wed, 17 Apr 2013 13:09:15 -0700
Subject: [PATCH v11 1/3] ARM: Add base support for ARMv7-M
In-Reply-To: <1366215299-31969-2-git-send-email-u.kleine-koenig@pengutronix.de>
References: <1366215299-31969-1-git-send-email-u.kleine-koenig@pengutronix.de>
 <1366215299-31969-2-git-send-email-u.kleine-koenig@pengutronix.de>
Message-ID: <516F016B.30603@codeaurora.org>

On 04/17/13 09:14, Uwe Kleine-K?nig wrote:
> +__v7m_proc_info:
> +	.long	0x000f0000		@ Required ID value
> +	.long	0x000f0000		@ Mask for ID
> +	.long   0			@ proc_info_list.__cpu_mm_mmu_flags
> +	.long   0			@ proc_info_list.__cpu_io_mmu_flags
> +	b	__v7m_setup		@ proc_info_list.__cpu_flush
> +	.long	cpu_arch_name
> +	.long	cpu_elf_name
> +	.long	HWCAP_HALF|HWCAP_THUMB|HWCAP_FAST_MULT|HWCAP_IDIVT

Mainline is detecting HWCAP_IDIVT for v7 processors so you should be
able to leave that part out.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation



From dmurphy at ti.com  Wed Apr 17 16:16:00 2013
From: dmurphy at ti.com (Dan Murphy)
Date: Wed, 17 Apr 2013 15:16:00 -0500
Subject: [PATCHv2] ARM:dts:omap4-panda:Update the LED support for the panda DTS
Message-ID: <1366229760-4808-1-git-send-email-dmurphy@ti.com>

The GPIO for LED D1 on the omap4-panda a1-a3 rev and the omap4-panda-es
are different.

A1-A3 = gpio_wk7
ES = gpio_110

There is no change to LED D2

Abstract away the pinmux and the LED definitions for the two boards into
the respective DTS files.

Signed-off-by: Dan Murphy <dmurphy at ti.com>
---
 arch/arm/boot/dts/omap4-panda-common.dtsi |   22 ++++++++++++++++++-
 arch/arm/boot/dts/omap4-panda-es.dts      |   33 +++++++++++++++++++++++++++++
 2 files changed, 54 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 03bd60d..0c48f6b 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -16,7 +16,7 @@
 		reg = <0x80000000 0x40000000>; /* 1 GB */
 	};
 
-	leds {
+	leds: leds {
 		compatible = "gpio-leds";
 		heartbeat {
 			label = "pandaboard::status1";
@@ -64,6 +64,7 @@
 			&mcbsp1_pins
 			&dss_hdmi_pins
 			&tpd12s015_pins
+			&led_gpio_pins
 	>;
 
 	twl6040_pins: pinmux_twl6040_pins {
@@ -135,6 +136,25 @@
 			0xf0 0x118     /* i2c4_sda PULLUP | INPUTENABLE | MODE0 */
 		>;
 	};
+
+	led_gpio_pins: pinmux_leds_pins {
+		pinctrl-single,pins = <
+		>;
+	};
+};
+
+&omap4_pmx_wkup {
+	pinctrl-names = "default";
+	pinctrl-0 = <
+		&led_wkgpio_pins
+	>;
+
+	led_wkgpio_pins: pinmux_leds_wkpins {
+		pinctrl-single,pins = <
+			0x1a 0x3	/* gpio_wk7 OUTPUT | MODE 3 */
+			0x1c 0x3	/* gpio_wk8 OUTPUT | MODE 3 */
+		>;
+	};
 };
 
 &i2c1 {
diff --git a/arch/arm/boot/dts/omap4-panda-es.dts b/arch/arm/boot/dts/omap4-panda-es.dts
index f1d8c21..565d37e 100644
--- a/arch/arm/boot/dts/omap4-panda-es.dts
+++ b/arch/arm/boot/dts/omap4-panda-es.dts
@@ -34,3 +34,36 @@
 		0x5e 0x100	/* hdmi_sda.hdmi_sda INPUT | MODE 0 */
 		>;
 };
+
+&leds {
+	compatible = "gpio-leds";
+	heartbeat {
+		label = "pandaboard::status1";
+		gpios = <&gpio4 14 0>;
+		linux,default-trigger = "heartbeat";
+	};
+	mmc {
+		label = "pandaboard::status2";
+		gpios = <&gpio1 8 0>;
+		linux,default-trigger = "gpio";
+	};
+};
+
+&led_gpio_pins {
+	pinctrl-single,pins = <
+		0xb6 0x3	/* gpio_110 OUTPUT | MODE 3 */
+	>;
+};
+
+&omap4_pmx_wkup {
+	pinctrl-names = "default";
+	pinctrl-0 = <
+		&led_wkgpio_pins
+	>;
+
+	led_wkgpio_pins: pinmux_leds_wkpins {
+		pinctrl-single,pins = <
+			0x1c 0x3	/* gpio_wk8 OUTPUT | MODE 3 */
+		>;
+	};
+};
-- 
1.7.9.5



From festevam at gmail.com  Wed Apr 17 16:21:25 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Wed, 17 Apr 2013 17:21:25 -0300
Subject: [PATCH] ARM: mach-imx6q: Remove code for setting up cko clock
In-Reply-To: <20130417195744.GX1906@pengutronix.de>
References: <1366224182-29285-1-git-send-email-festevam@gmail.com>
 <20130417195744.GX1906@pengutronix.de>
Message-ID: <CAOMZO5AynVOfSq_duGrAkaUtwyx1XjGQQY4558b4GOoMqa7TiQ@mail.gmail.com>

Hi Sascha,

On Wed, Apr 17, 2013 at 4:57 PM, Sascha Hauer <s.hauer at pengutronix.de> wrote:
> On Wed, Apr 17, 2013 at 03:43:02PM -0300, Fabio Estevam wrote:
>> From: Fabio Estevam <fabio.estevam at freescale.com>
>>
>> Let the bootloader setup the cko clock that drives the audio codec.
>>
>
> I really don't like such stuff. Where is documented what's expected from
> the bootloader? Which versions of which bootloader do implement this?

As far as I know such documentation does not exist. It would be nice
to have it, especially now that
we are recently moving some ARM errata stuff out of the multi plaform kernel.

I sent patches today for enabling CLKO for sabrelite in Barebox and U-boot.

> The code you remove is not particularly nice, but just removing it is no
> solution to the problem.

Please let me know what is your preferred solution then.

There was some discussion here:
https://patchwork.kernel.org/patch/2303011/

,but I didn't see this come into any conclusion of what is the
preferred way to handle this.

>
>> This simplifies a lot the code and when a new board needs to add audio support,
>> it will not have to add all this amount of code again.
>
> It shouldn't be necessary to duplicate the code for each board.

Yes, some code could be factored out, but every time we need to add
audio support for a new board we would need to keep polluting
arch/arm/mach-imx/mach-imx6q.c with things like:

if (of_machine_is_compatible("fsl,imx6q-xxx"))
    cko_setup()

Regards,

Fabio Estevam


From arnd at arndb.de  Wed Apr 17 16:23:43 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed, 17 Apr 2013 22:23:43 +0200
Subject: [PATCH v3] irqchip: Add support for ARMv7-M's NVIC
In-Reply-To: <1366214540-31166-1-git-send-email-u.kleine-koenig@pengutronix.de>
References: <1366214540-31166-1-git-send-email-u.kleine-koenig@pengutronix.de>
Message-ID: <201304172223.43707.arnd@arndb.de>

On Wednesday 17 April 2013, Uwe Kleine-K?nig wrote:

> This patch triggers two checkpatch warnings:
> 
> 	WARNING: Avoid CamelCase: <nvic_do_IRQ>
> 	WARNING: Avoid CamelCase: <handle_IRQ>
> 
> but I think they are OK for consistency?!

You obviously have no choice for handle_IRQ, but I think the common way to
name the first-level interrupt handler would be "nvic_handle_irq" here.

> Moreover sparse tells me:
> 
> 	drivers/irqchip/irq-nvic.c:58:1: warning: symbol 'nvic_do_IRQ' was not declared. Should it be static?
> 
> nvic_do_IRQ is called from assembler only, so a declaration couldn't be
> shared and I couldn't find a nice place for a declaration. Suggestions
> welcome.

Can't you make it static and call set_handle_irq() on it from the
probe function?

> + * Each bank handles 32 irqs. Only the 16th (= last) bank handles only
> + * 16 irqs.
> + */
> +#define NVIC_MAX_IRQ		((NVIC_MAX_BANKS - 1) * 32 + 16)

Is this actually inherent to the hardware design, or is the number of irqs
actually customizable? Also, why do you care about the maximum? You only
use it to check against the device tree provided value, but I suppose
you could just as well trust that property to be correct.


	Arnd


From u.kleine-koenig at pengutronix.de  Wed Apr 17 16:28:42 2013
From: u.kleine-koenig at pengutronix.de (Uwe =?iso-8859-1?Q?Kleine-K=F6nig?=)
Date: Wed, 17 Apr 2013 22:28:42 +0200
Subject: [PATCH v11 1/3] ARM: Add base support for ARMv7-M
In-Reply-To: <516F016B.30603@codeaurora.org>
References: <1366215299-31969-1-git-send-email-u.kleine-koenig@pengutronix.de>
 <1366215299-31969-2-git-send-email-u.kleine-koenig@pengutronix.de>
 <516F016B.30603@codeaurora.org>
Message-ID: <20130417202842.GS30416@pengutronix.de>

Hello Stephen,

On Wed, Apr 17, 2013 at 01:09:15PM -0700, Stephen Boyd wrote:
> On 04/17/13 09:14, Uwe Kleine-K?nig wrote:
> > +__v7m_proc_info:
> > +	.long	0x000f0000		@ Required ID value
> > +	.long	0x000f0000		@ Mask for ID
> > +	.long   0			@ proc_info_list.__cpu_mm_mmu_flags
> > +	.long   0			@ proc_info_list.__cpu_io_mmu_flags
> > +	b	__v7m_setup		@ proc_info_list.__cpu_flush
> > +	.long	cpu_arch_name
> > +	.long	cpu_elf_name
> > +	.long	HWCAP_HALF|HWCAP_THUMB|HWCAP_FAST_MULT|HWCAP_IDIVT
> 
> Mainline is detecting HWCAP_IDIVT for v7 processors so you should be
> able to leave that part out.
I cannot confirm that. If I drop HWCAP_IDIVT here, /proc/cpuinfo changes
as follows:

-Features	: half thumb fastmult idivt 
+Features	: half thumb fastmult

Maybe I missed to call the respective function to autodetect that? I
don't consider that an issue big enough to justify another round for
this series. For me letting v11 hit mainline and fix detection later is
ok. I'll take a note to look into this, but if you want to come up with
a patch, don't hesitate :-)

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |


From eduardo.valentin at ti.com  Wed Apr 17 16:29:32 2013
From: eduardo.valentin at ti.com (Eduardo Valentin)
Date: Wed, 17 Apr 2013 16:29:32 -0400
Subject: [PATCH 1/3] arm: dts: introduce config HAS_BANDGAP
In-Reply-To: <1366230574-31547-1-git-send-email-eduardo.valentin@ti.com>
References: <1366230574-31547-1-git-send-email-eduardo.valentin@ti.com>
Message-ID: <1366230574-31547-2-git-send-email-eduardo.valentin@ti.com>

Introduce HAS_BANDGAP config entry. This config is a
boolean value so that arch code can flag is they
feature a bandgap device.

Cc: Russell King <linux at arm.linux.org.uk>
Cc: Tony Lindgren <tony at atomide.com>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-omap at vger.kernel.org
Cc: linux-kernel at vger.kernel.org
Signed-off-by: Eduardo Valentin <eduardo.valentin at ti.com>
---
 arch/arm/Kconfig            | 3 +++
 arch/arm/mach-omap2/Kconfig | 1 +
 2 files changed, 4 insertions(+)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index abf4467..04abc7c 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -179,6 +179,9 @@ config ARCH_HAS_CPUFREQ
 	  and that the relevant menu configurations are displayed for
 	  it.
 
+config ARCH_HAS_BANDGAP
+	bool
+
 config GENERIC_HWEIGHT
 	bool
 	default y
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 9ef5e9e..c36b0e7 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -4,6 +4,7 @@ config ARCH_OMAP
 config ARCH_OMAP2PLUS
 	bool "TI OMAP2/3/4/5 SoCs with device tree support" if (ARCH_MULTI_V6 || ARCH_MULTI_V7)
 	select ARCH_HAS_CPUFREQ
+	select ARCH_HAS_BANDGAP
 	select ARCH_HAS_HOLES_MEMORYMODEL
 	select ARCH_OMAP
 	select ARCH_REQUIRE_GPIOLIB
-- 
1.8.2.1.342.gfa7285d



From eduardo.valentin at ti.com  Wed Apr 17 16:29:33 2013
From: eduardo.valentin at ti.com (Eduardo Valentin)
Date: Wed, 17 Apr 2013 16:29:33 -0400
Subject: [PATCH 2/3] arm: dts: add bandgap entry for OMAP443x devices
In-Reply-To: <1366230574-31547-1-git-send-email-eduardo.valentin@ti.com>
References: <1366230574-31547-1-git-send-email-eduardo.valentin@ti.com>
Message-ID: <1366230574-31547-3-git-send-email-eduardo.valentin@ti.com>

This patch add the bandgap entry for OMAP4430 devices.

Cc: "Beno?t Cousson" <b-cousson at ti.com>
Cc: Tony Lindgren <tony at atomide.com>
Cc: Russell King <linux at arm.linux.org.uk>
Cc: linux-omap at vger.kernel.org
Cc: devicetree-discuss at lists.ozlabs.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
Signed-off-by: Eduardo Valentin <eduardo.valentin at ti.com>
---
 arch/arm/boot/dts/omap443x.dtsi | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/omap443x.dtsi b/arch/arm/boot/dts/omap443x.dtsi
index cccf39a..8d6c968 100644
--- a/arch/arm/boot/dts/omap443x.dtsi
+++ b/arch/arm/boot/dts/omap443x.dtsi
@@ -24,4 +24,8 @@
 			clock-latency = <300000>; /* From legacy driver */
 		};
 	};
+	bandgap {
+		reg = <0x4a002260 0x4 0x4a00232C 0x4>;
+		compatible = "ti,omap4430-bandgap";
+	};
 };
-- 
1.8.2.1.342.gfa7285d



From eduardo.valentin at ti.com  Wed Apr 17 16:29:34 2013
From: eduardo.valentin at ti.com (Eduardo Valentin)
Date: Wed, 17 Apr 2013 16:29:34 -0400
Subject: [PATCH 3/3] arm: add bandgap entry for OMAP4460 devices
In-Reply-To: <1366230574-31547-1-git-send-email-eduardo.valentin@ti.com>
References: <1366230574-31547-1-git-send-email-eduardo.valentin@ti.com>
Message-ID: <1366230574-31547-4-git-send-email-eduardo.valentin@ti.com>

Include bandgap devices for OMAP4460 devices.

Cc: "Beno?t Cousson" <b-cousson at ti.com>
Cc: Tony Lindgren <tony at atomide.com>
Cc: Russell King <linux at arm.linux.org.uk>
Cc: linux-omap at vger.kernel.org
Cc: devicetree-discuss at lists.ozlabs.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
Signed-off-by: Eduardo Valentin <eduardo.valentin at ti.com>
---
 arch/arm/boot/dts/omap4460.dtsi | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/boot/dts/omap4460.dtsi b/arch/arm/boot/dts/omap4460.dtsi
index 7c2c23c..3808b5c 100644
--- a/arch/arm/boot/dts/omap4460.dtsi
+++ b/arch/arm/boot/dts/omap4460.dtsi
@@ -29,4 +29,13 @@
 			     <0 55 0x4>;
 		ti,hwmods = "debugss";
 	};
+
+	bandgap {
+		reg = <0x4a002260 0x4
+			0x4a00232C 0x4
+			0x4a002378 0x18>;
+		compatible = "ti,omap4460-bandgap";
+		interrupts = <0 126 4>; /* talert */
+		ti,tshut-gpio = <86>;
+	};
 };
-- 
1.8.2.1.342.gfa7285d



From jon-hunter at ti.com  Wed Apr 17 16:31:47 2013
From: jon-hunter at ti.com (Jon Hunter)
Date: Wed, 17 Apr 2013 15:31:47 -0500
Subject: [PATCH] gpio/omap: ensure gpio context is initialised
Message-ID: <1366230707-32681-1-git-send-email-jon-hunter@ti.com>

Commit a2797be (gpio/omap: force restore if context loss is not
detectable) broke gpio support for OMAP when booting with device-tree
because a restore of the gpio context being performed without ever
initialising the gpio context. In other words, the context restored was
bad.

This problem could also occur in the non device-tree case, however, it
is much less likely because when booting without device-tree we can
detect context loss via a platform specific API and so context restore
is performed less often.

Nevertheless we should ensure that the gpio context is initialised
during the probe for gpio banks that could lose their state regardless
of whether we are booting with device-tree or not.

Reported-by: Tony Lindgren <tony at atomide.com>
Signed-off-by: Jon Hunter <jon-hunter at ti.com>
Tested-by: Tony Lindgren <tony at atomide.com>
---
 drivers/gpio/gpio-omap.c |   53 +++++++++++++++++++++++++++++++++++++---------
 1 file changed, 43 insertions(+), 10 deletions(-)

diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 0557529..0ba5cb9 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -70,6 +70,7 @@ struct gpio_bank {
 	bool is_mpuio;
 	bool dbck_flag;
 	bool loses_context;
+	bool context_valid;
 	int stride;
 	u32 width;
 	int context_loss_count;
@@ -1085,6 +1086,7 @@ static void omap_gpio_chip_init(struct gpio_bank *bank)
 }
 
 static const struct of_device_id omap_gpio_match[];
+static void omap_gpio_init_context(struct gpio_bank *p);
 
 static int omap_gpio_probe(struct platform_device *pdev)
 {
@@ -1179,8 +1181,10 @@ static int omap_gpio_probe(struct platform_device *pdev)
 	omap_gpio_chip_init(bank);
 	omap_gpio_show_rev(bank);
 
-	if (bank->loses_context)
+	if (bank->loses_context) {
 		bank->get_context_loss_count = pdata->get_context_loss_count;
+		omap_gpio_init_context(bank);
+	}
 
 	pm_runtime_put(bank->dev);
 
@@ -1269,6 +1273,14 @@ static int omap_gpio_runtime_resume(struct device *dev)
 	int c;
 
 	spin_lock_irqsave(&bank->lock, flags);
+
+	/*
+	 * On the first resume during the probe, the context has not
+	 * been initialised and so if the context is not valid return.
+	 */
+	if (!bank->context_valid)
+		goto done;
+
 	_gpio_dbck_enable(bank);
 
 	/*
@@ -1287,19 +1299,15 @@ static int omap_gpio_runtime_resume(struct device *dev)
 			omap_gpio_restore_context(bank);
 		} else {
 			c = bank->get_context_loss_count(bank->dev);
-			if (c != bank->context_loss_count) {
+			if (c != bank->context_loss_count)
 				omap_gpio_restore_context(bank);
-			} else {
-				spin_unlock_irqrestore(&bank->lock, flags);
-				return 0;
-			}
+			else
+				goto done;
 		}
 	}
 
-	if (!bank->workaround_enabled) {
-		spin_unlock_irqrestore(&bank->lock, flags);
-		return 0;
-	}
+	if (!bank->workaround_enabled)
+		goto done;
 
 	l = __raw_readl(bank->base + bank->regs->datain);
 
@@ -1352,6 +1360,7 @@ static int omap_gpio_runtime_resume(struct device *dev)
 	}
 
 	bank->workaround_enabled = false;
+done:
 	spin_unlock_irqrestore(&bank->lock, flags);
 
 	return 0;
@@ -1385,6 +1394,29 @@ void omap2_gpio_resume_after_idle(void)
 }
 
 #if defined(CONFIG_PM_RUNTIME)
+static void omap_gpio_init_context(struct gpio_bank *p)
+{
+	struct omap_gpio_reg_offs *regs = p->regs;
+	void __iomem *base = p->base;
+
+	p->context.ctrl		= __raw_readl(base + regs->ctrl);
+	p->context.oe		= __raw_readl(base + regs->direction);
+	p->context.wake_en	= __raw_readl(base + regs->wkup_en);
+	p->context.leveldetect0	= __raw_readl(base + regs->leveldetect0);
+	p->context.leveldetect1	= __raw_readl(base + regs->leveldetect1);
+	p->context.risingdetect	= __raw_readl(base + regs->risingdetect);
+	p->context.fallingdetect = __raw_readl(base + regs->fallingdetect);
+	p->context.irqenable1	= __raw_readl(base + regs->irqenable);
+	p->context.irqenable2	= __raw_readl(base + regs->irqenable2);
+
+	if (regs->set_dataout && p->regs->clr_dataout)
+		p->context.dataout = __raw_readl(base + regs->set_dataout);
+	else
+		p->context.dataout = __raw_readl(base + regs->dataout);
+
+	p->context_valid = true;
+}
+
 static void omap_gpio_restore_context(struct gpio_bank *bank)
 {
 	__raw_writel(bank->context.wake_en,
@@ -1422,6 +1454,7 @@ static void omap_gpio_restore_context(struct gpio_bank *bank)
 #else
 #define omap_gpio_runtime_suspend NULL
 #define omap_gpio_runtime_resume NULL
+static void omap_gpio_init_context(struct gpio_bank *p) {}
 #endif
 
 static const struct dev_pm_ops gpio_pm_ops = {
-- 
1.7.10.4



From eduardo.valentin at ti.com  Wed Apr 17 16:35:59 2013
From: eduardo.valentin at ti.com (Eduardo Valentin)
Date: Wed, 17 Apr 2013 16:35:59 -0400
Subject: [PATCH 0/3] arm: omap: add ti bandap device on DT entries
Message-ID: <1366230959-31694-1-git-send-email-eduardo.valentin@ti.com>

Benoit, Tony,

This is a small series, based on linux-next, that adds
ti bandgap device. This is based on previous reviews this
driver got.

The driver is still under staging, I believe it is in a good
shape to be enabled and start broader tests.

I have tested this driver on OMAP4430/60 and OMAP5430.

This series will contain only the part that is required to
add its device tree node entry.

All best,

Eduardo Valentin (3):
  arm: dts: introduce config HAS_BANDGAP
  arm: dts: add bandgap entry for OMAP443x devices
  arm: add bandgap entry for OMAP4460 devices

 arch/arm/Kconfig                | 3 +++
 arch/arm/boot/dts/omap443x.dtsi | 4 ++++
 arch/arm/boot/dts/omap4460.dtsi | 9 +++++++++
 arch/arm/mach-omap2/Kconfig     | 1 +
 4 files changed, 17 insertions(+)

-- 
1.8.2.1.342.gfa7285d



From jason at lakedaemon.net  Wed Apr 17 16:38:06 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Wed, 17 Apr 2013 16:38:06 -0400
Subject: [PATCH] ARM: Orion: Remove redundent init_dma_coherent_pool_size()
In-Reply-To: <1352655079-1005-1-git-send-email-andrew@lunn.ch>
References: <1352356737-14413-1-git-send-email-m.szyprowski@samsung.com>
 <1352655079-1005-1-git-send-email-andrew@lunn.ch>
Message-ID: <20130417203806.GE27197@titan.lakedaemon.net>

Andrew,

Now that we finally have Soren Moch's (sp? sorry) cache exhaustion
solved, can we respin this for v3.11?  I'd like to include mvebu as well
if possible.

thx,

Jason.

On Sun, Nov 11, 2012 at 06:31:19PM +0100, Andrew Lunn wrote:
> The patch:
> 
> mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
> 
> makes these calls on Kirkword and Orion5x redundent. The drivers are
> not making atomic requests for coherent memory and hence the default
> pool size is now sufficient.
> 
> Signed-off-by: Andrew Lunn <andrew at lunn.ch>
> ---
>  arch/arm/mach-kirkwood/common.c |    7 -------
>  arch/arm/mach-orion5x/common.c  |    7 -------
>  2 files changed, 14 deletions(-)
> 
> diff --git a/arch/arm/mach-kirkwood/common.c b/arch/arm/mach-kirkwood/common.c
> index 2c6c218..8080ceb 100644
> --- a/arch/arm/mach-kirkwood/common.c
> +++ b/arch/arm/mach-kirkwood/common.c
> @@ -505,13 +505,6 @@ void __init kirkwood_wdt_init(void)
>  void __init kirkwood_init_early(void)
>  {
>  	orion_time_set_base(TIMER_VIRT_BASE);
> -
> -	/*
> -	 * Some Kirkwood devices allocate their coherent buffers from atomic
> -	 * context. Increase size of atomic coherent pool to make sure such
> -	 * the allocations won't fail.
> -	 */
> -	init_dma_coherent_pool_size(SZ_1M);
>  }
>  
>  int kirkwood_tclk;
> diff --git a/arch/arm/mach-orion5x/common.c b/arch/arm/mach-orion5x/common.c
> index b3eb3da..3e07f52 100644
> --- a/arch/arm/mach-orion5x/common.c
> +++ b/arch/arm/mach-orion5x/common.c
> @@ -194,13 +194,6 @@ void __init orion5x_wdt_init(void)
>  void __init orion5x_init_early(void)
>  {
>  	orion_time_set_base(TIMER_VIRT_BASE);
> -
> -	/*
> -	 * Some Orion5x devices allocate their coherent buffers from atomic
> -	 * context. Increase size of atomic coherent pool to make sure such
> -	 * the allocations won't fail.
> -	 */
> -	init_dma_coherent_pool_size(SZ_1M);
>  }
>  
>  int orion5x_tclk;
> -- 
> 1.7.10.4
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From sboyd at codeaurora.org  Wed Apr 17 16:40:07 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Wed, 17 Apr 2013 13:40:07 -0700
Subject: [PATCH v11 1/3] ARM: Add base support for ARMv7-M
In-Reply-To: <20130417202842.GS30416@pengutronix.de>
References: <1366215299-31969-1-git-send-email-u.kleine-koenig@pengutronix.de>
 <1366215299-31969-2-git-send-email-u.kleine-koenig@pengutronix.de>
 <516F016B.30603@codeaurora.org> <20130417202842.GS30416@pengutronix.de>
Message-ID: <516F08A7.8030009@codeaurora.org>

On 04/17/13 13:28, Uwe Kleine-K?nig wrote:
> Hello Stephen,
>
> On Wed, Apr 17, 2013 at 01:09:15PM -0700, Stephen Boyd wrote:
>> On 04/17/13 09:14, Uwe Kleine-K?nig wrote:
>>> +__v7m_proc_info:
>>> +	.long	0x000f0000		@ Required ID value
>>> +	.long	0x000f0000		@ Mask for ID
>>> +	.long   0			@ proc_info_list.__cpu_mm_mmu_flags
>>> +	.long   0			@ proc_info_list.__cpu_io_mmu_flags
>>> +	b	__v7m_setup		@ proc_info_list.__cpu_flush
>>> +	.long	cpu_arch_name
>>> +	.long	cpu_elf_name
>>> +	.long	HWCAP_HALF|HWCAP_THUMB|HWCAP_FAST_MULT|HWCAP_IDIVT
>> Mainline is detecting HWCAP_IDIVT for v7 processors so you should be
>> able to leave that part out.
> I cannot confirm that. If I drop HWCAP_IDIVT here, /proc/cpuinfo changes
> as follows:
>
> -Features	: half thumb fastmult idivt 
> +Features	: half thumb fastmult
>
> Maybe I missed to call the respective function to autodetect that? I
> don't consider that an issue big enough to justify another round for
> this series. For me letting v11 hit mainline and fix detection later is
> ok. I'll take a note to look into this, but if you want to come up with
> a patch, don't hesitate :-)

The patch that introduces the detection is
8164f7af88d9ad3a757bd14f634b23997ee77f6b. Sorry I should have read this
patch more closely. I seem to recall that M profile doesn't have the
CPUID registers in a coprocessor so it won't work. Probably easier to
leave it as is for now.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation



From cedric at precidata.com  Wed Apr 17 16:42:51 2013
From: cedric at precidata.com (Cedric Berger)
Date: Wed, 17 Apr 2013 22:42:51 +0200 (CEST)
Subject: [PATCH 3/10] LPC32XX: 003-mmc.1: Don't access private fields in MMC
 controller
Message-ID: <mailman.12.1366231384.1198.linux-arm-kernel@lists.infradead.org>

Signed-off-by: Gabriele Mondada <gabriele at precidata.com>
---
The mmci_set_clkreg() function violates its general contract by accessing
directly private host->mmc fields. This prevents us from implementing a MUX
on top of this driver. Fix that by changing slightly the function prototype.

Index: drivers/mmc/host/mmci.c
===================================================================
--- drivers/mmc/host/mmci.c	(revision 1726)
+++ drivers/mmc/host/mmci.c	(revision 1727)
@@ -207,10 +207,11 @@
 /*
  * This must be called with host->lock held
  */
-static void mmci_set_clkreg(struct mmci_host *host, unsigned int desired)
+static void mmci_set_clkreg(struct mmci_host *host, struct mmc_ios *ios)
 {
 	struct variant_data *variant = host->variant;
 	u32 clk = variant->clkreg;
+	unsigned int desired = ios->clock;
 
 	if (desired) {
 		if (desired >= host->mclk) {
@@ -246,12 +247,12 @@
 		/* clk |= MCI_CLK_PWRSAVE; */
 	}
 
-	if (host->mmc->ios.bus_width == MMC_BUS_WIDTH_4)
+	if (ios->bus_width == MMC_BUS_WIDTH_4)
 		clk |= MCI_4BIT_BUS;
-	if (host->mmc->ios.bus_width == MMC_BUS_WIDTH_8)
+	if (ios->bus_width == MMC_BUS_WIDTH_8)
 		clk |= MCI_ST_8BIT_BUS;
 
-	if (host->mmc->ios.timing == MMC_TIMING_UHS_DDR50)
+	if (ios->timing == MMC_TIMING_UHS_DDR50)
 		clk |= MCI_ST_UX500_NEG_EDGE;
 
 	mmci_write_clkreg(host, clk);
@@ -1319,7 +1320,7 @@
 
 	spin_lock_irqsave(&host->lock, flags);
 
-	mmci_set_clkreg(host, ios->clock);
+	mmci_set_clkreg(host, ios);
 	mmci_write_pwrreg(host, pwr);
 
 	spin_unlock_irqrestore(&host->lock, flags);


From cedric at precidata.com  Wed Apr 17 16:42:49 2013
From: cedric at precidata.com (Cedric Berger)
Date: Wed, 17 Apr 2013 22:42:49 +0200 (CEST)
Subject: [PATCH 1/10] LPC32XX: 001-mmc.1: Define + Implement DMA_FORCE_BURST
 for pl032
Message-ID: <mailman.13.1366231399.1198.linux-arm-kernel@lists.infradead.org>

Signed-off-by: Gabriele Mondada <gabriele at precidata.com>
---
To implement the MMC driver on LPC32xx, we need a way to force a DMA burst by
software. This patch defines a new DMA_FORCE_BURST hook and implements it for
the pl08x.c

Index: include/linux/dmaengine.h
===================================================================
--- include/linux/dmaengine.h	(revision 1688)
+++ include/linux/dmaengine.h	(revision 1736)
@@ -208,6 +208,7 @@
  * argument of struct dma_slave_config must be passed in with this
  * command.
  * @FSLDMA_EXTERNAL_START: this command will put the Freescale DMA controller
+ * @DMA_FORCE_BURST: force DMA burst
  * into external start mode.
  */
 enum dma_ctrl_cmd {
@@ -216,6 +217,7 @@
 	DMA_RESUME,
 	DMA_SLAVE_CONFIG,
 	FSLDMA_EXTERNAL_START,
+	DMA_FORCE_BURST,
 };
 
 /**
Index: drivers/dma/amba-pl08x.c
===================================================================
--- drivers/dma/amba-pl08x.c	(revision 1688)
+++ drivers/dma/amba-pl08x.c	(revision 1736)
@@ -448,6 +448,19 @@
 	writel(1 << ch->id, pl08x->base + PL080_TC_CLEAR);
 }
 
+/*
+ * simulate a DMA request by software, generating a burst transfer
+ */
+static void pl08x_force_burst(struct pl08x_dma_chan *plchan)
+{
+	struct pl08x_driver_data *pl08x = plchan->host;
+
+	dev_dbg(&pl08x->adev->dev, "force burst signal=%d plchan=%p\n",
+		plchan->signal, plchan);
+	if (plchan->signal >= 0)
+		writel(1 << plchan->signal, pl08x->base + PL080_SOFT_BREQ);
+}
+
 static inline u32 get_bytes_in_cctl(u32 cctl)
 {
 	/* The source width defines the number of bytes */
@@ -1574,6 +1587,9 @@
 		pl08x_resume_phy_chan(plchan->phychan);
 		plchan->state = PL08X_CHAN_RUNNING;
 		break;
+	case DMA_FORCE_BURST:
+		pl08x_force_burst(plchan);
+		break;
 	default:
 		/* Unknown command */
 		ret = -ENXIO;


From cedric at precidata.com  Wed Apr 17 16:42:48 2013
From: cedric at precidata.com (Cedric Berger)
Date: Wed, 17 Apr 2013 22:42:48 +0200 (CEST)
Subject: [PATCH 0/10] LPC32XX: Various patches and improvements
Message-ID: <mailman.14.1366231411.1198.linux-arm-kernel@lists.infradead.org>

Hello,

Here is a patchset that improve support for various features of the
LPC32XX on linux. The most important are the first two patches, which
enable MMC+DMA on that controller. These patches have been tested
against 3.9rc7 on our LPC32XX board, but should benefit most boards
using the LPC32XX.

Cedric Berger
cedric at precidata.com


From cedric at precidata.com  Wed Apr 17 16:42:52 2013
From: cedric at precidata.com (Cedric Berger)
Date: Wed, 17 Apr 2013 22:42:52 +0200 (CEST)
Subject: [PATCH 4/10] LPC32XX: 004-mmc.1: Enable dma for Phytec board
Message-ID: <mailman.15.1366231423.1198.linux-arm-kernel@lists.infradead.org>

Signed-off-by: Gabriele Mondada <gabriele at precidata.com>
---
Enable DMA for phy3250. Without that, the mmc driver is unusable.

Index: arch/arm/mach-lpc32xx/phy3250.c
===================================================================
--- arch/arm/mach-lpc32xx/phy3250.c	(revision 1732)
+++ arch/arm/mach-lpc32xx/phy3250.c	(revision 1733)
@@ -168,6 +168,12 @@
 		.max_signal = 12,
 		.periph_buses = PL08X_AHB1,
 	},
+	{
+		.bus_id = "mmc",
+		.min_signal = 4,
+		.max_signal = 4,
+		.periph_buses = PL08X_AHB1,
+	},
 };
 
 static int pl08x_get_signal(const struct pl08x_channel_data *cd)
@@ -202,9 +208,13 @@
 	.ocr_mask	= MMC_VDD_30_31 | MMC_VDD_31_32 |
 			  MMC_VDD_32_33 | MMC_VDD_33_34,
 	.ios_handler	= mmc_handle_ios,
-	.dma_filter	= NULL,
-	/* No DMA for now since AMBA PL080 dmaengine driver only does scatter
-	 * gather, and the MMCI driver doesn't do it this way */
+	.dma_filter	= pl08x_filter_id,
+	.dma_rx_param	= "mmc",
+	/*
+	 * When not defined, tx channel is the same as rx.
+	 * Defining dma_tx_param with the same value as dma_rx_param does not
+	 * work.
+	 */
 };
 
 static struct lpc32xx_slc_platform_data lpc32xx_slc_data = {



From cedric at precidata.com  Wed Apr 17 16:42:54 2013
From: cedric at precidata.com (Cedric Berger)
Date: Wed, 17 Apr 2013 22:42:54 +0200 (CEST)
Subject: [PATCH 6/10] LPC32XX: 006-clock.1: Fully enable SSP devices
Message-ID: <mailman.16.1366231434.1198.linux-arm-kernel@lists.infradead.org>

Signed-off-by: Cedric Berger <cedric at precidata.com>
---
The current code forget to enable various MUXes on the LPCw32xx silicon when
SSP0 and SSP1 controllers are used, making them unusable.
Enable the MUXes when their clock is enabled.

Index: arch/arm/mach-lpc32xx/clock.c
===================================================================
--- arch/arm/mach-lpc32xx/clock.c	(revision 1725)
+++ arch/arm/mach-lpc32xx/clock.c	(revision 1726)
@@ -568,6 +568,51 @@
 	return 0;
 }
 
+static int ssp_onoff_enable(struct clk *clk, int enable, int pmask, int dmask)
+{
+	u32 pin, pin0, dma, dma0;
+
+	pin = pin0 = __raw_readl(LPC32XX_GPIO_P_MUX_SET);
+	dma = dma0 = __raw_readl(LPC32XX_CLKPWR_SSP_CLK_CTRL);
+	if (enable) {
+		pin |= pmask;
+		dma |= dmask;
+	} else {
+		pin &= ~pmask;
+		dma &= ~dmask;
+	}
+	if (pin != pin0) {
+		pr_debug("LPC32XX_GPIO_P_MUX_SET: %08x => %08x\n", pin0, pin);
+		__raw_writel(pin, LPC32XX_GPIO_P_MUX_SET);
+	}
+	if (dma != dma0) {
+		pr_debug("LPC32XX_CLKPWR_SSP_CLK_CTRL: %08x => %08x\n", dma0,
+		    dma);
+		__raw_writel(dma, LPC32XX_CLKPWR_SSP_CLK_CTRL);
+	}
+	return local_onoff_enable(clk, enable);
+}
+
+static int ssp0_onoff_enable(struct clk *clk, int enable)
+{
+	return ssp_onoff_enable(clk, enable,
+		BIT(9) |				/* select ssp0:MOSI */
+		BIT(10) |				/* select ssp0:MISO */
+		BIT(12),				/* select ssp0:SCK */
+		LPC32XX_CLKPWR_SSPCTRL_DMA_SSP0RX |
+		LPC32XX_CLKPWR_SSPCTRL_DMA_SSP0TX);
+}
+
+static int ssp1_onoff_enable(struct clk *clk, int enable)
+{
+	return ssp_onoff_enable(clk, enable,
+		BIT(5) |				/* select ssp1:MOSI */
+		BIT(6) |				/* select ssp1:MISO */
+		BIT(8),					/* select ssp1:SCK */
+		LPC32XX_CLKPWR_SSPCTRL_DMA_SSP1RX |
+		LPC32XX_CLKPWR_SSPCTRL_DMA_SSP1TX);
+}
+
 /* Peripheral clock sources */
 static struct clk clk_timer0 = {
 	.parent		= &clk_pclk,
@@ -697,7 +742,7 @@
 
 static struct clk clk_ssp0 = {
 	.parent		= &clk_hclk,
-	.enable		= local_onoff_enable,
+	.enable		= ssp0_onoff_enable,
 	.enable_reg	= LPC32XX_CLKPWR_SSP_CLK_CTRL,
 	.enable_mask	= LPC32XX_CLKPWR_SSPCTRL_SSPCLK0_EN,
 	.get_rate	= local_return_parent_rate,
@@ -705,7 +750,7 @@
 
 static struct clk clk_ssp1 = {
 	.parent		= &clk_hclk,
-	.enable		= local_onoff_enable,
+	.enable		= ssp1_onoff_enable,
 	.enable_reg	= LPC32XX_CLKPWR_SSP_CLK_CTRL,
 	.enable_mask	= LPC32XX_CLKPWR_SSPCTRL_SSPCLK1_EN,
 	.get_rate	= local_return_parent_rate,


From cedric at precidata.com  Wed Apr 17 16:42:55 2013
From: cedric at precidata.com (Cedric Berger)
Date: Wed, 17 Apr 2013 22:42:55 +0200 (CEST)
Subject: [PATCH 7/10] LPC32XX: 007-pl022.1: Add start_control board hook
Message-ID: <mailman.17.1366231445.1198.linux-arm-kernel@lists.infradead.org>

Signed-off-by: Cedric Berger <cedric at precidata.com>
---
For our platform, we must delay the start of SPI frames at a specific later
time, controlled by a FIQ interrupt. To implement this mechanism without
messing too much with the pl022 driver, we need a board hook on the SSP start
signal.

Index: include/linux/amba/pl022.h
===================================================================
--- include/linux/amba/pl022.h	(revision 1703)
+++ include/linux/amba/pl022.h	(revision 1704)
@@ -276,6 +276,8 @@
  * before sampling the incoming line
  * @cs_control: function pointer to board-specific function to
  * assert/deassert I/O port to control HW generation of devices chip-select.
+ * @start_control: function pointer to board-specific function to
+ * start the SPI controller.
  */
 struct pl022_config_chip {
 	enum ssp_interface iface;
@@ -290,6 +292,7 @@
 	enum ssp_duplex duplex;
 	enum ssp_clkdelay clkdelay;
 	void (*cs_control) (u32 control);
+	void (*start_control) (void);
 };
 
 #endif /* _SSP_PL022_H */
Index: drivers/spi/spi-pl022.c
===================================================================
--- drivers/spi/spi-pl022.c	(revision 1703)
+++ drivers/spi/spi-pl022.c	(revision 1704)
@@ -430,6 +430,7 @@
 	enum ssp_reading read;
 	enum ssp_writing write;
 	void (*cs_control) (u32 command);
+	void (*start_control) (void);
 	int xfer_type;
 };
 
@@ -1417,8 +1418,11 @@
 	}
 err_config_dma:
 	/* Enable SSP, turn on interrupts */
-	writew((readw(SSP_CR1(pl022->virtbase)) | SSP_CR1_MASK_SSE),
-	       SSP_CR1(pl022->virtbase));
+	if (pl022->cur_chip->start_control)
+		pl022->cur_chip->start_control();
+	else
+		writew((readw(SSP_CR1(pl022->virtbase)) | SSP_CR1_MASK_SSE),
+		       SSP_CR1(pl022->virtbase));
 	writew(irqflags, SSP_IMSC(pl022->virtbase));
 }
 
@@ -1888,6 +1892,7 @@
 				 "invalid chip select\n");
 	} else
 		chip->cs_control = chip_info->cs_control;
+	chip->start_control = chip_info->start_control;
 
 	/* Check bits per word with vendor specific range */
 	if ((bits <= 3) || (bits > pl022->vendor->max_bpw)) {
@@ -1934,7 +1939,7 @@
 		SSP_WRITE_BITS(chip->dmacr, SSP_DMA_DISABLED,
 			       SSP_DMACR_MASK_TXDMAE, 1);
 	}
-
+	chip->start_control = chip_info->start_control;
 	chip->cpsr = clk_freq.cpsdvsr;
 
 	/* Special setup for the ST micro extended control registers */


From cedric at precidata.com  Wed Apr 17 16:42:57 2013
From: cedric at precidata.com (Cedric Berger)
Date: Wed, 17 Apr 2013 22:42:57 +0200 (CEST)
Subject: [PATCH 9/10] LPC32XX: 009-plat.1: lpc23xx => lpc32xx in LPC32xx
 platform code
Message-ID: <mailman.18.1366231457.1198.linux-arm-kernel@lists.infradead.org>

Signed-off-by: Cedric Berger <cedric at precidata.com>
---
This is the lpc32xx, not the lpc23xx.

Index: arch/arm/mach-lpc32xx/phy3250.c
===================================================================
--- arch/arm/mach-lpc32xx/phy3250.c	(revision 1711)
+++ arch/arm/mach-lpc32xx/phy3250.c	(revision 1712)
@@ -266,5 +266,5 @@
 	.init_time	= lpc32xx_timer_init,
 	.init_machine	= lpc3250_machine_init,
 	.dt_compat	= lpc32xx_dt_compat,
-	.restart	= lpc23xx_restart,
+	.restart	= lpc32xx_restart,
 MACHINE_END
Index: arch/arm/mach-lpc32xx/common.c
===================================================================
--- arch/arm/mach-lpc32xx/common.c	(revision 1711)
+++ arch/arm/mach-lpc32xx/common.c	(revision 1712)
@@ -230,7 +230,7 @@
 	iotable_init(lpc32xx_io_desc, ARRAY_SIZE(lpc32xx_io_desc));
 }
 
-void lpc23xx_restart(char mode, const char *cmd)
+void lpc32xx_restart(char mode, const char *cmd)
 {
 	switch (mode) {
 	case 's':
Index: arch/arm/mach-lpc32xx/common.h
===================================================================
--- arch/arm/mach-lpc32xx/common.h	(revision 1711)
+++ arch/arm/mach-lpc32xx/common.h	(revision 1712)
@@ -29,7 +29,7 @@
 extern void __init lpc32xx_init_irq(void);
 extern void __init lpc32xx_map_io(void);
 extern void __init lpc32xx_serial_init(void);
-extern void lpc23xx_restart(char, const char *);
+extern void lpc32xx_restart(char, const char *);
 
 
 /*


From cedric at precidata.com  Wed Apr 17 16:42:50 2013
From: cedric at precidata.com (Cedric Berger)
Date: Wed, 17 Apr 2013 22:42:50 +0200 (CEST)
Subject: [PATCH 2/10] LPC32XX: 002-mmc.1: Workaround for MMC+DMA on LPC32xx
Message-ID: <mailman.19.1366231470.1198.linux-arm-kernel@lists.infradead.org>

Signed-off-by: Gabriele Mondada <gabriele at precidata.com>
---
the connection between the MMC controller and the DMA on NXP LPC32xx has
silicon bugs. NXP did a patch to workaround this, but it has not been commited
on the main branch. This is a rework of that patch for 3.9 kernel.

Index: mmci.c
===================================================================
--- drivers/mmc/host/mmci.c	(revision 1688)
+++ drivers/mmc/host/mmci.c	(working copy)
@@ -3,6 +3,7 @@
  *
  *  Copyright (C) 2003 Deep Blue Solutions, Ltd, All Rights Reserved.
  *  Copyright (C) 2010 ST-Ericsson SA
+ *  Copyright (C) 2013 Precidata Sarl, Gabriele Mondada
  *
  * 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
@@ -44,6 +45,16 @@
 
 #define DRIVER_NAME "mmci-pl18x"
 
+#define COOKIE_PREP	0x00000001
+#define COOKIE_SINGLE	0x00000002
+#define COOKIE_ID_MASK	0xFF000000
+#define COOKIE_ID_SHIFT	24
+#define COOKIE_ID(n)	(COOKIE_ID_MASK & ((n) << COOKIE_ID_SHIFT))
+
+#ifdef CONFIG_ARCH_LPC32XX
+#define DMA_TX_SIZE SZ_64K
+#endif
+
 static unsigned int fmax = 515633;
 
 /**
@@ -303,15 +314,40 @@
 	struct mmci_platform_data *plat = host->plat;
 	const char *rxname, *txname;
 	dma_cap_mask_t mask;
+#ifdef CONFIG_ARCH_LPC32XX
+	int i;
+#endif
 
 	if (!plat || !plat->dma_filter) {
 		dev_info(mmc_dev(host->mmc), "no DMA platform data\n");
 		return;
 	}
 
-	/* initialize pre request cookie */
-	host->next_data.cookie = 1;
+#ifdef CONFIG_ARCH_LPC32XX
+	/*
+	 * The LPC32XX do not support sg on TX DMA. So
+	 * a temporary bounce buffer is used if more than 1 sg segment
+	 * is passed in the data request. The bounce buffer will get a
+	 * contiguous copy of the TX data and it will be used instead.
+	 */
+	for (i = 0; i < 2; i++) {
+		host->bounce_buf_pool[i].dma_v_tx = dma_alloc_coherent(
+			mmc_dev(host->mmc), DMA_TX_SIZE,
+			&host->bounce_buf_pool[i].dma_p_tx, GFP_KERNEL);
+		if (host->bounce_buf_pool[i].dma_v_tx == NULL) {
+			dev_err(mmc_dev(host->mmc),
+				"error getting DMA region\n");
+			return;
+		}
+		dev_info(mmc_dev(host->mmc), "DMA buffer: phy:%p, virt:%p\n",
+			(void *)host->bounce_buf_pool[i].dma_p_tx,
+			 host->bounce_buf_pool[i].dma_v_tx);
+	}
 
+	host->bounce_buf = &host->bounce_buf_pool[0];
+	host->next_data.bounce_buf = &host->bounce_buf_pool[1];
+#endif
+
 	/* Try to acquire a generic DMA engine slave channel */
 	dma_cap_zero(mask);
 	dma_cap_set(DMA_SLAVE, mask);
@@ -380,12 +416,27 @@
 static inline void mmci_dma_release(struct mmci_host *host)
 {
 	struct mmci_platform_data *plat = host->plat;
+#ifdef CONFIG_ARCH_LPC32XX
+	int i;
+#endif
 
 	if (host->dma_rx_channel)
 		dma_release_channel(host->dma_rx_channel);
 	if (host->dma_tx_channel && plat->dma_tx_param)
 		dma_release_channel(host->dma_tx_channel);
 	host->dma_rx_channel = host->dma_tx_channel = NULL;
+
+#ifdef CONFIG_ARCH_LPC32XX
+	for (i = 0; i < 2; i++) {
+		if (host->bounce_buf_pool[i].dma_v_tx == NULL)
+			continue;
+		dma_free_coherent(mmc_dev(host->mmc), DMA_TX_SIZE,
+			host->bounce_buf_pool[i].dma_v_tx,
+			host->bounce_buf_pool[i].dma_p_tx);
+		host->bounce_buf_pool[i].dma_v_tx = NULL;
+		host->bounce_buf_pool[i].dma_p_tx = 0;
+	}
+#endif
 }
 
 static void mmci_dma_data_error(struct mmci_host *host)
@@ -394,7 +445,6 @@
 	dmaengine_terminate_all(host->dma_current);
 	host->dma_current = NULL;
 	host->dma_desc_current = NULL;
-	host->data->host_cookie = 0;
 }
 
 static void mmci_dma_unmap(struct mmci_host *host, struct mmc_data *data)
@@ -410,7 +460,9 @@
 		chan = host->dma_tx_channel;
 	}
 
-	dma_unmap_sg(chan->device->dev, data->sg, data->sg_len, dir);
+	if (!(data->host_cookie & COOKIE_SINGLE))
+		dma_unmap_sg(chan->device->dev, data->sg, data->sg_len, dir);
+	data->host_cookie = 0;
 }
 
 static void mmci_dma_finalize(struct mmci_host *host, struct mmc_data *data)
@@ -457,7 +509,8 @@
 /* prepares DMA channel and DMA descriptor, returns non-zero on failure */
 static int __mmci_dma_prep_data(struct mmci_host *host, struct mmc_data *data,
 				struct dma_chan **dma_chan,
-				struct dma_async_tx_descriptor **dma_desc)
+				struct dma_async_tx_descriptor **dma_desc,
+				struct mmci_bounce_buf *bounce_buf)
 {
 	struct variant_data *variant = host->variant;
 	struct dma_slave_config conf = {
@@ -474,7 +527,11 @@
 	struct dma_async_tx_descriptor *desc;
 	enum dma_data_direction buffer_dirn;
 	int nr_sg;
+	bool single = bounce_buf && (data->flags & MMC_DATA_WRITE) &&
+			(data->sg_len > 1);
 
+	WARN_ON(data->host_cookie);
+
 	if (data->flags & MMC_DATA_READ) {
 		conf.direction = DMA_DEV_TO_MEM;
 		buffer_dirn = DMA_FROM_DEVICE;
@@ -483,6 +540,9 @@
 		conf.direction = DMA_MEM_TO_DEV;
 		buffer_dirn = DMA_TO_DEVICE;
 		chan = host->dma_tx_channel;
+#ifdef CONFIG_ARCH_LPC32XX
+		conf.device_fc = true;
+#endif
 	}
 
 	/* If there's no DMA channel, fall back to PIO */
@@ -494,23 +554,58 @@
 		return -EINVAL;
 
 	device = chan->device;
-	nr_sg = dma_map_sg(device->dev, data->sg, data->sg_len, buffer_dirn);
-	if (nr_sg == 0)
-		return -EINVAL;
+	dmaengine_slave_config(chan, &conf);
 
-	dmaengine_slave_config(chan, &conf);
-	desc = dmaengine_prep_slave_sg(chan, data->sg, nr_sg,
-					    conf.direction, DMA_CTRL_ACK);
+	if (single) {
+		int i;
+		unsigned char *dst = bounce_buf->dma_v_tx;
+		size_t len = 0;
+
+		dev_dbg(mmc_dev(host->mmc), "use bounce buffer\n");
+
+		/* Move data to contiguous buffer first, then transfer it */
+		for (i = 0; i < data->sg_len; i++) {
+			unsigned long flags;
+			struct scatterlist *sg = &data->sg[i];
+			void *src;
+
+			/* Map the current scatter buffer, copy data, unmap */
+			local_irq_save(flags);
+			src = (unsigned char *)kmap_atomic(sg_page(sg)) +
+							   sg->offset;
+			memcpy(dst + len, src, sg->length);
+			len += sg->length;
+			kunmap_atomic(src);
+			local_irq_restore(flags);
+		}
+
+		desc = dmaengine_prep_slave_single(chan, bounce_buf->dma_p_tx,
+						len, buffer_dirn, DMA_CTRL_ACK);
+	} else {
+		nr_sg = dma_map_sg(device->dev, data->sg, data->sg_len,
+				   buffer_dirn);
+		if (nr_sg == 0)
+			return -EINVAL;
+
+		desc = dmaengine_prep_slave_sg(chan, data->sg, nr_sg,
+					       conf.direction, DMA_CTRL_ACK);
+	}
+
 	if (!desc)
 		goto unmap_exit;
 
 	*dma_chan = chan;
 	*dma_desc = desc;
 
+	data->host_cookie = COOKIE_PREP;
+	if (single)
+		data->host_cookie |= COOKIE_SINGLE;
+
 	return 0;
 
  unmap_exit:
-	dma_unmap_sg(device->dev, data->sg, data->sg_len, buffer_dirn);
+	if (!single)
+		dma_unmap_sg(device->dev, data->sg, data->sg_len, buffer_dirn);
 	return -ENOMEM;
 }
 
@@ -523,14 +618,20 @@
 
 	/* No job were prepared thus do it now. */
 	return __mmci_dma_prep_data(host, data, &host->dma_current,
-				    &host->dma_desc_current);
+				    &host->dma_desc_current,
+				    host->bounce_buf);
 }
 
 static inline int mmci_dma_prep_next(struct mmci_host *host,
 				     struct mmc_data *data)
 {
 	struct mmci_host_next *nd = &host->next_data;
-	return __mmci_dma_prep_data(host, data, &nd->dma_chan, &nd->dma_desc);
+	int rv;
+	rv = __mmci_dma_prep_data(host, data, &nd->dma_chan, &nd->dma_desc,
+				    nd->bounce_buf);
+	if (!rv)
+		data->host_cookie |= COOKIE_ID(++host->next_data.cookie_cnt);
+	return rv;
 }
 
 static int mmci_dma_start_data(struct mmci_host *host, unsigned int datactrl)
@@ -567,14 +668,24 @@
 static void mmci_get_next_data(struct mmci_host *host, struct mmc_data *data)
 {
 	struct mmci_host_next *next = &host->next_data;
+#ifdef CONFIG_ARCH_LPC32XX
+	struct mmci_bounce_buf *tmp;
+#endif
 
-	WARN_ON(data->host_cookie && data->host_cookie != next->cookie);
+	WARN_ON(data->host_cookie && ((data->host_cookie & COOKIE_ID_MASK) !=
+					COOKIE_ID(next->cookie_cnt)));
 	WARN_ON(!data->host_cookie && (next->dma_desc || next->dma_chan));
 
 	host->dma_desc_current = next->dma_desc;
 	host->dma_current = next->dma_chan;
 	next->dma_desc = NULL;
 	next->dma_chan = NULL;
+
+#ifdef CONFIG_ARCH_LPC32XX
+	tmp = host->next_data.bounce_buf;
+	host->next_data.bounce_buf = host->bounce_buf;
+	host->bounce_buf = tmp;
+#endif
 }
 
 static void mmci_pre_request(struct mmc_host *mmc, struct mmc_request *mrq,
@@ -582,7 +693,6 @@
 {
 	struct mmci_host *host = mmc_priv(mmc);
 	struct mmc_data *data = mrq->data;
-	struct mmci_host_next *nd = &host->next_data;
 
 	if (!data)
 		return;
@@ -592,8 +702,7 @@
 	if (mmci_validate_data(host, data))
 		return;
 
-	if (!mmci_dma_prep_next(host, data))
-		data->host_cookie = ++nd->cookie < 0 ? 1 : nd->cookie;
+	mmci_dma_prep_next(host, data);
 }
 
 static void mmci_post_request(struct mmc_host *mmc, struct mmc_request *mrq,
@@ -834,6 +943,16 @@
 		dev_err(mmc_dev(host->mmc), "stray MCI_DATABLOCKEND interrupt\n");
 
 	if (status & MCI_DATAEND || data->error) {
+#ifdef CONFIG_ARCH_LPC32XX
+		/*
+		 * On LPC32XX, there is a problem with the DMA flow control and
+		 * the last burst transfer is not performed. So we force the
+		 * transfer programmatically here.
+		 */
+		if ((data->flags & MMC_DATA_READ) && host->dma_rx_channel)
+			dmaengine_device_control(host->dma_rx_channel,
+			    DMA_FORCE_BURST, 0);
+#endif
 		if (dma_inprogress(host))
 			mmci_dma_finalize(host, data);
 		mmci_stop_data(host);
Index: mmci.h
===================================================================
--- drivers/mmc/host/mmci.h	(revision 1688)
+++ drivers/mmc/host/mmci.h	(working copy)
@@ -158,10 +158,20 @@
 struct variant_data;
 struct dma_chan;
 
+struct mmci_bounce_buf {
+	void				*dma_v_tx;
+	dma_addr_t			dma_p_tx;
+};
+
 struct mmci_host_next {
 	struct dma_async_tx_descriptor	*dma_desc;
 	struct dma_chan			*dma_chan;
-	s32				cookie;
+	struct mmci_bounce_buf		*bounce_buf;
+	s32				cookie_cnt;
+#ifdef CONFIG_ARCH_LPC32XX
+	void				*dma_v_tx;
+	dma_addr_t			dma_p_tx;
+#endif
 };
 
 struct mmci_host {
@@ -208,6 +218,9 @@
 	struct dma_async_tx_descriptor	*dma_desc_current;
 	struct mmci_host_next	next_data;
 
+	struct mmci_bounce_buf  *bounce_buf;
+	struct mmci_bounce_buf	bounce_buf_pool[2];
+
 #define dma_inprogress(host)	((host)->dma_current)
 #else
 #define dma_inprogress(host)	(0)


From cedric at precidata.com  Wed Apr 17 16:42:57 2013
From: cedric at precidata.com (Cedric Berger)
Date: Wed, 17 Apr 2013 22:42:57 +0200 (CEST)
Subject: [PATCH 10/10] LPC32XX: 010-fiq.1: Enable FIQ interrupts for the
 LPC32xx controllers
Message-ID: <mailman.20.1366231479.1198.linux-arm-kernel@lists.infradead.org>

Signed-off-by: Gabriele Mondada <gabriele at precidata.com>
---
The LPC32xx controller has fully-working FIQ interrupts, enable then.

Index: arch/arm/Kconfig
===================================================================
--- arch/arm/Kconfig	(revision 1688)
+++ arch/arm/Kconfig	(revision 1736)
@@ -658,6 +658,7 @@
 	select HAVE_PWM
 	select USB_ARCH_HAS_OHCI
 	select USE_OF
+	select FIQ
 	help
 	  Support for the NXP LPC32XX family of processors
 
Index: arch/arm/mach-lpc32xx/irq.c
===================================================================
--- arch/arm/mach-lpc32xx/irq.c	(revision 1688)
+++ arch/arm/mach-lpc32xx/irq.c	(revision 1736)
@@ -374,6 +374,9 @@
 {
 	unsigned long ints = __raw_readl(LPC32XX_INTC_STAT(LPC32XX_SIC1_BASE));
 
+	/* ignore irqs which are in FIQ mode */
+	ints &= ~__raw_readl(LPC32XX_INTC_TYPE(LPC32XX_SIC1_BASE));
+
 	while (ints != 0) {
 		int irqno = fls(ints) - 1;
 
@@ -387,6 +390,9 @@
 {
 	unsigned long ints = __raw_readl(LPC32XX_INTC_STAT(LPC32XX_SIC2_BASE));
 
+	/* ignore irqs which are in FIQ mode */
+	ints &= ~__raw_readl(LPC32XX_INTC_TYPE(LPC32XX_SIC2_BASE));
+
 	while (ints != 0) {
 		int irqno = fls(ints) - 1;
 
Index: arch/arm/mach-lpc32xx/include/mach/entry-macro.S
===================================================================
--- arch/arm/mach-lpc32xx/include/mach/entry-macro.S	(revision 1688)
+++ arch/arm/mach-lpc32xx/include/mach/entry-macro.S	(revision 1736)
@@ -20,6 +20,7 @@
 #include <mach/platform.h>
 
 #define LPC32XX_INTC_MASKED_STATUS_OFS	0x8
+#define LPC32XX_INTC_FIQ_MASK		0x14
 
 	.macro  get_irqnr_preamble, base, tmp
 	ldr	\base, =IO_ADDRESS(LPC32XX_MIC_BASE)
@@ -31,6 +32,11 @@
  */
 	.macro	get_irqnr_and_base, irqnr, irqstat, base, tmp
 	ldr	\irqstat, [\base, #LPC32XX_INTC_MASKED_STATUS_OFS]
+
+	/* ignore irqs which are in FIQ mode */
+	ldr	\irqnr, [\base, #LPC32XX_INTC_FIQ_MASK]
+	bic	\irqstat, \irqstat, \irqnr
+
 	clz	\irqnr, \irqstat
 	rsb	\irqnr, \irqnr, #31
 	teq	\irqstat, #0


From cedric at precidata.com  Wed Apr 17 16:42:53 2013
From: cedric at precidata.com (Cedric Berger)
Date: Wed, 17 Apr 2013 22:42:53 +0200 (CEST)
Subject: [PATCH 5/10] LPC32XX: 005-clock.1: Allows clock input other than
 13MHz for lpc32xx
Message-ID: <mailman.21.1366231489.1198.linux-arm-kernel@lists.infradead.org>

Signed-off-by: Cedric Berger <cedric at precidata.com>
---
The lpc32xx platform is currently compiled for a fixed 13MHz main clock
input. Unfortunately, our board use a different (12MHz) main clock.
This patch replace the #define by a variable, which can be overriden by
plaform specific code.

Index: arch/arm/mach-lpc32xx/timer.c
===================================================================
--- arch/arm/mach-lpc32xx/timer.c	(revision 1690)
+++ arch/arm/mach-lpc32xx/timer.c	(revision 1691)
@@ -31,6 +31,8 @@
 #include <mach/platform.h>
 #include "common.h"
 
+int lpc32xx_main_osc_freq = LPC32XX_MAIN_OSC_FREQ_DEFAULT;
+
 static int lpc32xx_clkevt_next_event(unsigned long delta,
     struct clock_event_device *dev)
 {
@@ -115,7 +117,7 @@
 	 * timer rates. This rate is needed to compute the tick rate.
 	 */
 	if (clk_is_sysclk_mainosc() != 0)
-		clkrate = LPC32XX_MAIN_OSC_FREQ;
+		clkrate = lpc32xx_main_osc_freq;
 	else
 		clkrate = 397 * LPC32XX_CLOCK_OSC_FREQ;
 
Index: arch/arm/mach-lpc32xx/include/mach/platform.h
===================================================================
--- arch/arm/mach-lpc32xx/include/mach/platform.h	(revision 1690)
+++ arch/arm/mach-lpc32xx/include/mach/platform.h	(revision 1691)
@@ -121,7 +121,7 @@
 /*
  * Clock and crystal information
  */
-#define LPC32XX_MAIN_OSC_FREQ			13000000
+#define LPC32XX_MAIN_OSC_FREQ_DEFAULT		13000000
 #define LPC32XX_CLOCK_OSC_FREQ			32768
 
 /*
Index: arch/arm/mach-lpc32xx/include/mach/board.h
===================================================================
--- arch/arm/mach-lpc32xx/include/mach/board.h	(revision 1690)
+++ arch/arm/mach-lpc32xx/include/mach/board.h	(revision 1691)
@@ -21,4 +21,7 @@
 
 extern u32 lpc32xx_return_iram_size(void);
 
+/* main oscillator frequency, 13MHz (default) or board-specific */
+extern int lpc32xx_main_osc_freq;
+
 #endif  /* __ASM_ARCH_BOARD_H */
Index: arch/arm/mach-lpc32xx/clock.c
===================================================================
--- arch/arm/mach-lpc32xx/clock.c	(revision 1690)
+++ arch/arm/mach-lpc32xx/clock.c	(revision 1691)
@@ -196,8 +196,8 @@
 
 static struct clk osc_main = {
 	.enable		= local_oscmain_enable,
-	.rate		= LPC32XX_MAIN_OSC_FREQ,
 	.get_rate	= local_return_parent_rate,
+	/* .rate is set in clk_init() */
 };
 
 static struct clk clk_sys;
@@ -1240,6 +1240,8 @@
 {
 	int i;
 
+	osc_main.rate = lpc32xx_main_osc_freq;
+
 	for (i = 0; i < ARRAY_SIZE(lookups); i++)
 		clkdev_add(&lookups[i]);
 
Index: drivers/tty/serial/lpc32xx_hs.c
===================================================================
--- drivers/tty/serial/lpc32xx_hs.c	(revision 1690)
+++ drivers/tty/serial/lpc32xx_hs.c	(revision 1691)
@@ -34,6 +34,7 @@
 #include <linux/irq.h>
 #include <linux/gpio.h>
 #include <linux/of.h>
+#include <mach/board.h>
 #include <mach/platform.h>
 #include <mach/hardware.h>
 
@@ -705,7 +706,7 @@
 	}
 
 	p->port.iotype = UPIO_MEM32;
-	p->port.uartclk = LPC32XX_MAIN_OSC_FREQ;
+	p->port.uartclk = lpc32xx_main_osc_freq;
 	p->port.regshift = 2;
 	p->port.flags = UPF_BOOT_AUTOCONF | UPF_FIXED_PORT | UPF_IOREMAP;
 	p->port.dev = &pdev->dev;


From cedric at precidata.com  Wed Apr 17 16:42:56 2013
From: cedric at precidata.com (Cedric Berger)
Date: Wed, 17 Apr 2013 22:42:56 +0200 (CEST)
Subject: [PATCH 8/10] LPC32XX: 008-pl022.1: Supports is_dma_mapped for pl022
Message-ID: <mailman.22.1366231494.1198.linux-arm-kernel@lists.infradead.org>

Signed-off-by: Cedric Berger <cedric at precidata.com>
---
Supports the is_dma_mapped message flag for the pl022

Index: drivers/spi/spi-pl022.c
===================================================================
--- drivers/spi/spi-pl022.c	(revision 1709)
+++ drivers/spi/spi-pl022.c	(revision 1710)
@@ -780,12 +780,16 @@
 static void unmap_free_dma_scatter(struct pl022 *pl022)
 {
 	/* Unmap and free the SG tables */
-	dma_unmap_sg(pl022->dma_tx_channel->device->dev, pl022->sgt_tx.sgl,
-		     pl022->sgt_tx.nents, DMA_TO_DEVICE);
-	dma_unmap_sg(pl022->dma_rx_channel->device->dev, pl022->sgt_rx.sgl,
-		     pl022->sgt_rx.nents, DMA_FROM_DEVICE);
-	sg_free_table(&pl022->sgt_rx);
-	sg_free_table(&pl022->sgt_tx);
+	if (pl022->sgt_tx.sgl) {
+		dma_unmap_sg(pl022->dma_tx_channel->device->dev,
+		     pl022->sgt_tx.sgl, pl022->sgt_tx.nents, DMA_TO_DEVICE);
+		sg_free_table(&pl022->sgt_tx);
+	}
+	if (pl022->sgt_rx.sgl) {
+		dma_unmap_sg(pl022->dma_rx_channel->device->dev,
+		     pl022->sgt_rx.sgl, pl022->sgt_rx.nents, DMA_FROM_DEVICE);
+		sg_free_table(&pl022->sgt_rx);
+	}
 }
 
 static void dma_callback(void *data)
@@ -793,8 +797,6 @@
 	struct pl022 *pl022 = data;
 	struct spi_message *msg = pl022->cur_msg;
 
-	BUG_ON(!pl022->sgt_rx.sgl);
-
 #ifdef VERBOSE_DEBUG
 	/*
 	 * Optionally dump out buffers to inspect contents, this is
@@ -802,7 +804,7 @@
 	 * read/write contents are the same, when adopting to a new
 	 * DMA engine.
 	 */
-	{
+	if (!msg->is_dma_mapped) {
 		struct scatterlist *sg;
 		unsigned int i;
 
@@ -897,6 +899,120 @@
 }
 
 /**
+ * configure_dma_mappings_single - configure mappings for dma-capable buffers
+ * @pl022: SSP driver's private data structure
+ */
+static int configure_dma_mappings_single(struct pl022 *pl022,
+		struct dma_async_tx_descriptor **prxdesc,
+		struct dma_async_tx_descriptor **ptxdesc)
+{
+	*prxdesc = dmaengine_prep_slave_single(
+			pl022->dma_rx_channel,
+			pl022->cur_transfer->rx_dma,
+			pl022->cur_transfer->len,
+			DMA_DEV_TO_MEM,
+			DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
+	if (!*prxdesc)
+		goto err_rxdesc;
+
+	*ptxdesc = dmaengine_prep_slave_single(
+			pl022->dma_tx_channel,
+			pl022->cur_transfer->tx_dma,
+			pl022->cur_transfer->len,
+			DMA_MEM_TO_DEV,
+			DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
+	if (!*ptxdesc)
+		goto err_txdesc;
+
+	return 0;
+
+err_txdesc:
+	dmaengine_terminate_all(pl022->dma_tx_channel);
+err_rxdesc:
+	dmaengine_terminate_all(pl022->dma_rx_channel);
+	return -ENOMEM;
+}
+
+/*
+ * configure_dma_mappings_sg - configure mappings for non-dma-capable buffers
+ * @pl022: SSP driver's private data structure
+ */
+static int configure_dma_mappings_sg(struct pl022 *pl022,
+		struct dma_async_tx_descriptor **prxdesc,
+		struct dma_async_tx_descriptor **ptxdesc)
+{
+	struct dma_chan *rxchan = pl022->dma_rx_channel;
+	struct dma_chan *txchan = pl022->dma_tx_channel;
+	unsigned int pages;
+	int ret;
+	int rx_sglen, tx_sglen;
+
+	/* Create sglists for the transfers */
+	pages = DIV_ROUND_UP(pl022->cur_transfer->len, PAGE_SIZE);
+	dev_dbg(&pl022->adev->dev, "using %d pages for transfer\n", pages);
+
+	ret = sg_alloc_table(&pl022->sgt_rx, pages, GFP_ATOMIC);
+	if (ret)
+		goto err_alloc_rx_sg;
+
+	ret = sg_alloc_table(&pl022->sgt_tx, pages, GFP_ATOMIC);
+	if (ret)
+		goto err_alloc_tx_sg;
+
+	/* Fill in the scatterlists for the RX+TX buffers */
+	setup_dma_scatter(pl022, pl022->rx,
+			  pl022->cur_transfer->len, &pl022->sgt_rx);
+	setup_dma_scatter(pl022, pl022->tx,
+			  pl022->cur_transfer->len, &pl022->sgt_tx);
+
+	/* Map DMA buffers */
+	rx_sglen = dma_map_sg(rxchan->device->dev, pl022->sgt_rx.sgl,
+			   pl022->sgt_rx.nents, DMA_FROM_DEVICE);
+	if (!rx_sglen)
+		goto err_rx_sgmap;
+
+	tx_sglen = dma_map_sg(txchan->device->dev, pl022->sgt_tx.sgl,
+			   pl022->sgt_tx.nents, DMA_TO_DEVICE);
+	if (!tx_sglen)
+		goto err_tx_sgmap;
+
+	/* Send both scatterlists */
+	*prxdesc = dmaengine_prep_slave_sg(rxchan,
+				      pl022->sgt_rx.sgl,
+				      rx_sglen,
+				      DMA_DEV_TO_MEM,
+				      DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
+	if (!*prxdesc)
+		goto err_rxdesc;
+
+	*ptxdesc = dmaengine_prep_slave_sg(txchan,
+				      pl022->sgt_tx.sgl,
+				      tx_sglen,
+				      DMA_MEM_TO_DEV,
+				      DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
+	if (!*ptxdesc)
+		goto err_txdesc;
+	return 0;
+
+err_txdesc:
+	dmaengine_terminate_all(pl022->dma_tx_channel);
+err_rxdesc:
+	dmaengine_terminate_all(pl022->dma_rx_channel);
+	dma_unmap_sg(txchan->device->dev, pl022->sgt_tx.sgl,
+		     pl022->sgt_tx.nents, DMA_TO_DEVICE);
+err_tx_sgmap:
+	dma_unmap_sg(rxchan->device->dev, pl022->sgt_rx.sgl,
+		     pl022->sgt_tx.nents, DMA_FROM_DEVICE);
+err_rx_sgmap:
+	sg_free_table(&pl022->sgt_tx);
+err_alloc_tx_sg:
+	sg_free_table(&pl022->sgt_rx);
+err_alloc_rx_sg:
+	return -ENOMEM;
+}
+
+
+/**
  * configure_dma - configures the channels for the next transfer
  * @pl022: SSP driver's private data structure
  */
@@ -912,9 +1028,7 @@
 		.direction = DMA_MEM_TO_DEV,
 		.device_fc = false,
 	};
-	unsigned int pages;
 	int ret;
-	int rx_sglen, tx_sglen;
 	struct dma_chan *rxchan = pl022->dma_rx_channel;
 	struct dma_chan *txchan = pl022->dma_tx_channel;
 	struct dma_async_tx_descriptor *rxdesc;
@@ -1014,52 +1128,13 @@
 	dmaengine_slave_config(rxchan, &rx_conf);
 	dmaengine_slave_config(txchan, &tx_conf);
 
-	/* Create sglists for the transfers */
-	pages = DIV_ROUND_UP(pl022->cur_transfer->len, PAGE_SIZE);
-	dev_dbg(&pl022->adev->dev, "using %d pages for transfer\n", pages);
-
-	ret = sg_alloc_table(&pl022->sgt_rx, pages, GFP_ATOMIC);
+	if (pl022->cur_msg->is_dma_mapped)
+		ret = configure_dma_mappings_single(pl022, &rxdesc, &txdesc);
+	else
+		ret = configure_dma_mappings_sg(pl022, &rxdesc, &txdesc);
 	if (ret)
-		goto err_alloc_rx_sg;
+		return ret;
 
-	ret = sg_alloc_table(&pl022->sgt_tx, pages, GFP_ATOMIC);
-	if (ret)
-		goto err_alloc_tx_sg;
-
-	/* Fill in the scatterlists for the RX+TX buffers */
-	setup_dma_scatter(pl022, pl022->rx,
-			  pl022->cur_transfer->len, &pl022->sgt_rx);
-	setup_dma_scatter(pl022, pl022->tx,
-			  pl022->cur_transfer->len, &pl022->sgt_tx);
-
-	/* Map DMA buffers */
-	rx_sglen = dma_map_sg(rxchan->device->dev, pl022->sgt_rx.sgl,
-			   pl022->sgt_rx.nents, DMA_FROM_DEVICE);
-	if (!rx_sglen)
-		goto err_rx_sgmap;
-
-	tx_sglen = dma_map_sg(txchan->device->dev, pl022->sgt_tx.sgl,
-			   pl022->sgt_tx.nents, DMA_TO_DEVICE);
-	if (!tx_sglen)
-		goto err_tx_sgmap;
-
-	/* Send both scatterlists */
-	rxdesc = dmaengine_prep_slave_sg(rxchan,
-				      pl022->sgt_rx.sgl,
-				      rx_sglen,
-				      DMA_DEV_TO_MEM,
-				      DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
-	if (!rxdesc)
-		goto err_rxdesc;
-
-	txdesc = dmaengine_prep_slave_sg(txchan,
-				      pl022->sgt_tx.sgl,
-				      tx_sglen,
-				      DMA_MEM_TO_DEV,
-				      DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
-	if (!txdesc)
-		goto err_txdesc;
-
 	/* Put the callback on the RX transfer only, that should finish last */
 	rxdesc->callback = dma_callback;
 	rxdesc->callback_param = pl022;
@@ -1072,22 +1147,6 @@
 	pl022->dma_running = true;
 
 	return 0;
-
-err_txdesc:
-	dmaengine_terminate_all(txchan);
-err_rxdesc:
-	dmaengine_terminate_all(rxchan);
-	dma_unmap_sg(txchan->device->dev, pl022->sgt_tx.sgl,
-		     pl022->sgt_tx.nents, DMA_TO_DEVICE);
-err_tx_sgmap:
-	dma_unmap_sg(rxchan->device->dev, pl022->sgt_rx.sgl,
-		     pl022->sgt_tx.nents, DMA_FROM_DEVICE);
-err_rx_sgmap:
-	sg_free_table(&pl022->sgt_tx);
-err_alloc_tx_sg:
-	sg_free_table(&pl022->sgt_rx);
-err_alloc_rx_sg:
-	return -ENOMEM;
 }
 
 static int pl022_dma_probe(struct pl022 *pl022)



From sboyd at codeaurora.org  Wed Apr 17 16:44:26 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Wed, 17 Apr 2013 13:44:26 -0700
Subject: [PATCHv4 00/11] Remove ARM local timer API
In-Reply-To: <1365456453-16297-1-git-send-email-sboyd@codeaurora.org>
References: <1365456453-16297-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <516F09AA.2000902@codeaurora.org>

Thomas,

Would you be able to pick up patches 1 and 2 from this series and
publish it as a stable branch? Preferably based on rc5 but I can always
merge it to rc5 and apply the rest of the patches.

Arnd/Olof,

Would you be able to merge in the rest of the patches to arm-soc? I can
provide a branch on 3.9-rc5 and a merge resolution with for-next in
arm-soc that you can pull to look at.

If not I will have to resend the series.

Thanks,
Stephen

On 04/08/13 14:27, Stephen Boyd wrote:
> In light of Mark Rutland's recent work on divorcing the ARM architected
> timers from the ARM local timer API and introducing a generic arch hook for
> broadcast it seems that we should remove the local timer API entirely.
> Doing so will reduce the architecture dependencies of our timer drivers,
> reduce code in ARM core, and simplify timer drivers because they no longer
> go through an architecture layer that is essentially a hotplug notifier.
>
> Previous attempts have been made[1] unsuccessfully. I'm hoping this can
> be accepted now so that we can clean up the timer drivers that are
> used in both UP and SMP situations. Right now these drivers have to ignore
> the timer setup callback on the boot CPU to avoid registering clockevents
> twice. This is not very symmetric and causes convuluted code that does
> the same thing in two places.
>
> Patches based on v3.9-rc5. I'm still looking for Acks/Tested-by
> on EXYNOS and PRIMA2.
>
> [1] http://article.gmane.org/gmane.linux.ports.arm.kernel/145705
>
> Note: A hotplug notifier is used by both x86 for the apb_timer (see 
> apbt_cpuhp_notify) and by metag (see arch_timer_cpu_notify in
> metag_generic.c) so this is not new.
>
> Changes since v3:
>  * New patch to fix SMP with dummy timers registered after a global timer
>  * Push this_cpu_ptr lower to avoid preemptible false positive warnings
>  * Collected acks/tested-bys
>
> Changes since v2:
>  * Bug fixes in smp_twd from Tony Lindgren's testing
>  * Move smp_twd to use late_time_init hook
>  * Collected Acks
>
> Changes since v1:
>  * Picked up Mark's generic dummy timer driver
>  * Split out omap changes into new patch
>
> Mark Rutland (1):
>   clocksource: add generic dummy timer driver
>
> Stephen Boyd (10):
>   clockevents: Prefer CPU local devices over global devices
>   ARM: smp: Remove duplicate dummy timer implementation
>   ARM: smp_twd: Divorce smp_twd from local timer API
>   ARM: OMAP2+: Divorce from local timer API
>   ARM: EXYNOS4: Divorce mct from local timer API
>   ARM: PRIMA2: Divorce timer-marco from local timer API
>   ARM: msm: Divorce msm_timer from local timer API
>   clocksource: time-armada-370-xp: Fix sparse warning
>   clocksource: time-armada-370-xp: Divorce from local timer API
>   ARM: smp: Remove local timer API
>
>  arch/arm/Kconfig                         |  12 +--
>  arch/arm/include/asm/localtimer.h        |  34 ---------
>  arch/arm/kernel/smp.c                    |  87 ---------------------
>  arch/arm/kernel/smp_twd.c                |  64 +++++++++++-----
>  arch/arm/mach-exynos/mct.c               |  60 ++++++++++-----
>  arch/arm/mach-msm/timer.c                | 127 +++++++++++++++++--------------
>  arch/arm/mach-omap2/Kconfig              |   1 -
>  arch/arm/mach-omap2/timer.c              |   7 --
>  arch/arm/mach-prima2/timer-marco.c       | 100 +++++++++++++-----------
>  drivers/clocksource/Makefile             |   1 +
>  drivers/clocksource/dummy_timer.c        |  69 +++++++++++++++++
>  drivers/clocksource/time-armada-370-xp.c |  92 +++++++++++-----------
>  include/linux/time-armada-370-xp.h       |   4 +-
>  kernel/time/tick-common.c                |   5 +-
>  14 files changed, 327 insertions(+), 336 deletions(-)
>  delete mode 100644 arch/arm/include/asm/localtimer.h
>  create mode 100644 drivers/clocksource/dummy_timer.c
>


-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation



From gregory.clement at free-electrons.com  Wed Apr 17 16:49:53 2013
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Wed, 17 Apr 2013 22:49:53 +0200
Subject: [PATCH] ARM: Orion: Remove redundent init_dma_coherent_pool_size()
In-Reply-To: <20130417203806.GE27197@titan.lakedaemon.net>
References: <1352356737-14413-1-git-send-email-m.szyprowski@samsung.com>
 <1352655079-1005-1-git-send-email-andrew@lunn.ch>
 <20130417203806.GE27197@titan.lakedaemon.net>
Message-ID: <516F0AF1.2090905@free-electrons.com>

On 04/17/2013 10:38 PM, Jason Cooper wrote:
> Andrew,
> 
> Now that we finally have Soren Moch's (sp? sorry) cache exhaustion
> solved, can we respin this for v3.11?  I'd like to include mvebu as well
> if possible.

For mvebu, I can do a follow-up patch, or Andrew can directly add it to his
patch.

Regards,

> 
> thx,
> 
> Jason.
> 
> On Sun, Nov 11, 2012 at 06:31:19PM +0100, Andrew Lunn wrote:
>> The patch:
>>
>> mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
>>
>> makes these calls on Kirkword and Orion5x redundent. The drivers are
>> not making atomic requests for coherent memory and hence the default
>> pool size is now sufficient.
>>
>> Signed-off-by: Andrew Lunn <andrew at lunn.ch>
>> ---
>>  arch/arm/mach-kirkwood/common.c |    7 -------
>>  arch/arm/mach-orion5x/common.c  |    7 -------
>>  2 files changed, 14 deletions(-)
>>
>> diff --git a/arch/arm/mach-kirkwood/common.c b/arch/arm/mach-kirkwood/common.c
>> index 2c6c218..8080ceb 100644
>> --- a/arch/arm/mach-kirkwood/common.c
>> +++ b/arch/arm/mach-kirkwood/common.c
>> @@ -505,13 +505,6 @@ void __init kirkwood_wdt_init(void)
>>  void __init kirkwood_init_early(void)
>>  {
>>  	orion_time_set_base(TIMER_VIRT_BASE);
>> -
>> -	/*
>> -	 * Some Kirkwood devices allocate their coherent buffers from atomic
>> -	 * context. Increase size of atomic coherent pool to make sure such
>> -	 * the allocations won't fail.
>> -	 */
>> -	init_dma_coherent_pool_size(SZ_1M);
>>  }
>>  
>>  int kirkwood_tclk;
>> diff --git a/arch/arm/mach-orion5x/common.c b/arch/arm/mach-orion5x/common.c
>> index b3eb3da..3e07f52 100644
>> --- a/arch/arm/mach-orion5x/common.c
>> +++ b/arch/arm/mach-orion5x/common.c
>> @@ -194,13 +194,6 @@ void __init orion5x_wdt_init(void)
>>  void __init orion5x_init_early(void)
>>  {
>>  	orion_time_set_base(TIMER_VIRT_BASE);
>> -
>> -	/*
>> -	 * Some Orion5x devices allocate their coherent buffers from atomic
>> -	 * context. Increase size of atomic coherent pool to make sure such
>> -	 * the allocations won't fail.
>> -	 */
>> -	init_dma_coherent_pool_size(SZ_1M);
>>  }
>>  
>>  int orion5x_tclk;
>> -- 
>> 1.7.10.4
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From stern at rowland.harvard.edu  Wed Apr 17 16:57:03 2013
From: stern at rowland.harvard.edu (Alan Stern)
Date: Wed, 17 Apr 2013 16:57:03 -0400 (EDT)
Subject: [PATCH V5 6/6] USB: OHCI: avoid conflicting platform drivers
In-Reply-To: <1364919844-1726-7-git-send-email-arnd@arndb.de>
Message-ID: <Pine.LNX.4.44L0.1304171655170.1623-100000@iolanthe.rowland.org>

On Tue, 2 Apr 2013, Arnd Bergmann wrote:

> Like the EHCI driver, OHCI supports a large number of different platform
> glue drivers by directly including them, which causes problems with
> conflicting macro definitions in some cases. As more ARM architecture
> specific back-ends are required to coexist in a single build, we should
> split those out into separate drivers. Unfortunately, the infrastructure
> for that is still under development, so to give us more time, this uses
> a separate *_PLATFORM_DRIVER macro for each ARM specific OHCI backend,
> just like we already do on PowerPC and some of the other ARM platforms.
> 
> In linux-3.10, only the SPEAr and CNS3xxx back-ends would actually conflict
> without this patch, but over time we would get more of them, so this
> is a way to avoid having to patch the driver every time it breaks. We
> should still split out all back-ends into separate loadable modules,
> but that work is only needed to improve code size and cleanliness after
> this patch, not for correctness.
> 
> While we're here, this fixes the incorrectly sorted error path
> for the OMAP1 and OMAP3 backends to ensure we always unregister
> the exact set of drivers that were registered before erroring out.
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>

I finally had a chance to look through this carefully.  It is fine.

Acked-by: Alan Stern <stern at rowland.harvard.edu>



From akpm at linux-foundation.org  Wed Apr 17 17:56:28 2013
From: akpm at linux-foundation.org (Andrew Morton)
Date: Wed, 17 Apr 2013 14:56:28 -0700
Subject: [PATCH V2 1/3] seccomp: add generic code for jitted seccomp
 filters.
In-Reply-To: <1363618233-6375-2-git-send-email-nschichan@freebox.fr>
References: <1363618233-6375-1-git-send-email-nschichan@freebox.fr>
 <1363618233-6375-2-git-send-email-nschichan@freebox.fr>
Message-ID: <20130417145628.88058f0f3104ab9ae551ddd3@linux-foundation.org>

On Mon, 18 Mar 2013 15:50:30 +0100 Nicolas Schichan <nschichan at freebox.fr> wrote:

> Architecture must select HAVE_SECCOMP_FILTER_JIT and implement
> seccomp_jit_compile() and seccomp_jit_free() if they intend to support
> jitted seccomp filters.
> 
> struct seccomp_filter has been moved to <linux/seccomp.h> to make its
> content available to the jit compilation code.
> 
> In a way similar to the net BPF, the jit compilation code is expected
> to updates struct seccomp_filter.bpf_func pointer to the generated
> code.
> 

This patch is killing me.

> --- a/include/linux/seccomp.h
> +++ b/include/linux/seccomp.h
> @@ -6,6 +6,7 @@
>  #ifdef CONFIG_SECCOMP
>  
>  #include <linux/thread_info.h>
> +#include <linux/filter.h>
>  #include <asm/seccomp.h>

In file included from include/linux/compat.h:18,
                 from include/linux/filter.h:9,
                 from include/linux/seccomp.h:9,
                 from include/linux/sched.h:39,
                 from arch/x86/kernel/asm-offsets.c:9:
/usr/src/25/arch/x86/include/asm/compat.h: In function 'arch_compat_alloc_user_space':
/usr/src/25/arch/x86/include/asm/compat.h:301: error: dereferencing pointer to incomplete type

Problem is, compat.h's arch_compat_alloc_user_space() needs sched.h for
task_struct but as you can see from the above include tree, sched.h
includes seccomp.h and everything falls over.  The preprocessed code
contains the definition of arch_compat_alloc_user_space() *before* the
definition of task_struct.

This is a basic x86_64 "make clean; make allmodconfig; make".

I had a few slashes at fixing it but got all frustrated.



From sergei.shtylyov at cogentembedded.com  Wed Apr 17 18:06:38 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Thu, 18 Apr 2013 02:06:38 +0400
Subject: [PATCH 0/4] R-Car VIN driver with R8A7779/Marzen support
Message-ID: <201304180206.39465.sergei.shtylyov@cogentembedded.com>

Hello.

   Here's the set of 4 patches against the Simon Horman's 'renesas.git' repo,
'renesas-next-20130417' tag and my recent yet unapplied patches. Here we
add the VIN (Video In) driver and its platform code working on the R8A7779/
Marzen with ADV7180 I2C camera sensor. The driver patch also applies without
issues to Mauro's 'media_tree.git'...

[1/4] V4L2: soc_camera: Renesas R-Car VIN driver
[2/4] ARM: shmobile: r8a7779: add VIN support
[3/4] ARM: shmobile: Marzen: add VIN and ADV7180 support
[4/4] ARM: shmobile: Marzen: enable VIN and ADV7180 in defconfig

WBR, Sergei


From sergei.shtylyov at cogentembedded.com  Wed Apr 17 18:13:14 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Thu, 18 Apr 2013 02:13:14 +0400
Subject: [PATCH 2/4] ARM: shmobile: r8a7779: add VIN support
In-Reply-To: <201304180206.39465.sergei.shtylyov@cogentembedded.com>
References: <201304180206.39465.sergei.shtylyov@cogentembedded.com>
Message-ID: <201304180213.15118.sergei.shtylyov@cogentembedded.com>

From: Vladimir Barinov <vladimir.barinov at cogentembedded.com>

Add VIN clocks and platform devices for R8A7779 SoC; add function to register
the VIN platform devices.

Signed-off-by: Vladimir Barinov <vladimir.barinov at cogentembedded.com>
[Sergei: renamed some variables]
Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

---
 arch/arm/mach-shmobile/clock-r8a7779.c        |   10 +++++++
 arch/arm/mach-shmobile/include/mach/r8a7779.h |    3 ++
 arch/arm/mach-shmobile/setup-r8a7779.c        |   36 ++++++++++++++++++++++++++
 3 files changed, 49 insertions(+)

Index: renesas/arch/arm/mach-shmobile/clock-r8a7779.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/clock-r8a7779.c
+++ renesas/arch/arm/mach-shmobile/clock-r8a7779.c
@@ -112,7 +112,9 @@ static struct clk *main_clks[] = {
 };
 
 enum { MSTP323, MSTP322, MSTP321, MSTP320,
+	MSTP120,
 	MSTP116, MSTP115, MSTP114,
+	MSTP110, MSTP109, MSTP108,
 	MSTP103, MSTP101, MSTP100,
 	MSTP030,
 	MSTP029, MSTP028, MSTP027, MSTP026, MSTP025, MSTP024, MSTP023, MSTP022, MSTP021,
@@ -125,9 +127,13 @@ static struct clk mstp_clks[MSTP_NR] = {
 	[MSTP322] = SH_CLK_MSTP32(&clkp_clk, MSTPCR3, 22, 0), /* SDHI1 */
 	[MSTP321] = SH_CLK_MSTP32(&clkp_clk, MSTPCR3, 21, 0), /* SDHI2 */
 	[MSTP320] = SH_CLK_MSTP32(&clkp_clk, MSTPCR3, 20, 0), /* SDHI3 */
+	[MSTP120] = SH_CLK_MSTP32(&clks_clk, MSTPCR1, 20, 0), /* VIN3 */
 	[MSTP116] = SH_CLK_MSTP32(&clkp_clk, MSTPCR1, 16, 0), /* PCIe */
 	[MSTP115] = SH_CLK_MSTP32(&clkp_clk, MSTPCR1, 15, 0), /* SATA */
 	[MSTP114] = SH_CLK_MSTP32(&clkp_clk, MSTPCR1, 14, 0), /* Ether */
+	[MSTP110] = SH_CLK_MSTP32(&clks_clk, MSTPCR1, 10, 0), /* VIN0 */
+	[MSTP109] = SH_CLK_MSTP32(&clks_clk, MSTPCR1,  9, 0), /* VIN1 */
+	[MSTP108] = SH_CLK_MSTP32(&clks_clk, MSTPCR1,  8, 0), /* VIN2 */
 	[MSTP103] = SH_CLK_MSTP32(&clks_clk, MSTPCR1,  3, 0), /* DU */
 	[MSTP101] = SH_CLK_MSTP32(&clkp_clk, MSTPCR1,  1, 0), /* USB2 */
 	[MSTP100] = SH_CLK_MSTP32(&clkp_clk, MSTPCR1,  0, 0), /* USB0/1 */
@@ -162,10 +168,14 @@ static struct clk_lookup lookups[] = {
 	CLKDEV_CON_ID("peripheral_clk",	&clkp_clk),
 
 	/* MSTP32 clocks */
+	CLKDEV_DEV_ID("rcar_vin.3", &mstp_clks[MSTP120]), /* VIN3 */
 	CLKDEV_DEV_ID("rcar-pcie", &mstp_clks[MSTP116]), /* PCIe */
 	CLKDEV_DEV_ID("sata_rcar", &mstp_clks[MSTP115]), /* SATA */
 	CLKDEV_DEV_ID("fc600000.sata", &mstp_clks[MSTP115]), /* SATA w/DT */
 	CLKDEV_DEV_ID("sh-eth", &mstp_clks[MSTP114]), /* Ether */
+	CLKDEV_DEV_ID("rcar_vin.0", &mstp_clks[MSTP110]), /* VIN0 */
+	CLKDEV_DEV_ID("rcar_vin.1", &mstp_clks[MSTP109]), /* VIN1 */
+	CLKDEV_DEV_ID("rcar_vin.2", &mstp_clks[MSTP108]), /* VIN2 */
 	CLKDEV_DEV_ID("ehci-platform.1", &mstp_clks[MSTP101]), /* USB EHCI port2 */
 	CLKDEV_DEV_ID("ohci-platform.1", &mstp_clks[MSTP101]), /* USB OHCI port2 */
 	CLKDEV_DEV_ID("ehci-platform.0", &mstp_clks[MSTP100]), /* USB EHCI port0/1 */
Index: renesas/arch/arm/mach-shmobile/include/mach/r8a7779.h
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/include/mach/r8a7779.h
+++ renesas/arch/arm/mach-shmobile/include/mach/r8a7779.h
@@ -5,6 +5,7 @@
 #include <linux/pm_domain.h>
 #include <linux/sh_eth.h>
 #include <linux/usb/rcar-phy.h>
+#include <linux/platform_data/camera-rcar.h>
 
 struct platform_device;
 
@@ -35,6 +36,8 @@ extern void r8a7779_add_standard_devices
 extern void r8a7779_add_standard_devices_dt(void);
 extern void r8a7779_add_ether_device(struct sh_eth_plat_data *pdata);
 extern void r8a7779_add_usb_phy_device(struct rcar_phy_platform_data *pdata);
+extern void r8a7779_add_vin_device(int idx,
+				   struct rcar_vin_platform_data *pdata);
 extern void r8a7779_init_late(void);
 extern void r8a7779_clock_init(void);
 extern void r8a7779_pinmux_init(void);
Index: renesas/arch/arm/mach-shmobile/setup-r8a7779.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/setup-r8a7779.c
+++ renesas/arch/arm/mach-shmobile/setup-r8a7779.c
@@ -559,6 +559,33 @@ static struct resource ether_resources[]
 	},
 };
 
+#define R8A7779_VIN(idx) \
+static struct resource vin##idx##_resources[] = {		\
+	DEFINE_RES_MEM(0xffc50000 + 0x1000 * (idx), 0x1000),	\
+	DEFINE_RES_IRQ(gic_iid(0x5f + (idx))),			\
+};								\
+								\
+static struct platform_device_info vin##idx##_info = {		\
+	.parent		= &platform_bus,			\
+	.name		= "rcar_vin",				\
+	.id		= idx,					\
+	.res		= vin##idx##_resources,			\
+	.num_res	= ARRAY_SIZE(vin##idx##_resources),	\
+	.dma_mask	= DMA_BIT_MASK(32),			\
+}
+
+R8A7779_VIN(0);
+R8A7779_VIN(1);
+R8A7779_VIN(2);
+R8A7779_VIN(3);
+
+static struct platform_device_info *vin_info_table[] __initdata = {
+	&vin0_info,
+	&vin1_info,
+	&vin2_info,
+	&vin3_info,
+};
+
 static struct platform_device *r8a7779_devices_dt[] __initdata = {
 	&scif0_device,
 	&scif1_device,
@@ -610,6 +637,15 @@ void __init r8a7779_add_usb_phy_device(s
 					  pdata, sizeof(*pdata));
 }
 
+void __init r8a7779_add_vin_device(int id,
+				   struct rcar_vin_platform_data *pdata)
+{
+	vin_info_table[id]->data = pdata;
+	vin_info_table[id]->size_data = sizeof(struct rcar_vin_platform_data);
+
+	platform_device_register_full(vin_info_table[id]);
+}
+
 /* do nothing for !CONFIG_SMP or !CONFIG_HAVE_TWD */
 void __init __weak r8a7779_register_twd(void) { }
 


From sergei.shtylyov at cogentembedded.com  Wed Apr 17 18:15:00 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Thu, 18 Apr 2013 02:15:00 +0400
Subject: [PATCH 3/4] ARM: shmobile: Marzen: add VIN and ADV7180 support
In-Reply-To: <201304180206.39465.sergei.shtylyov@cogentembedded.com>
References: <201304180206.39465.sergei.shtylyov@cogentembedded.com>
Message-ID: <201304180215.01218.sergei.shtylyov@cogentembedded.com>

From: Vladimir Barinov <vladimir.barinov at cogentembedded.com>

Add ADV7180 platform devices on the Marzen board, configure VIN1/3 pins, and
register VIN1/3 devices with the ADV7180 specific platform data.

Signed-off-by: Vladimir Barinov <vladimir.barinov at cogentembedded.com>
Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

---
 arch/arm/mach-shmobile/board-marzen.c |   55 ++++++++++++++++++++++++++++++++++
 1 file changed, 55 insertions(+)

Index: renesas/arch/arm/mach-shmobile/board-marzen.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/board-marzen.c
+++ renesas/arch/arm/mach-shmobile/board-marzen.c
@@ -37,6 +37,7 @@
 #include <linux/mmc/host.h>
 #include <linux/mmc/sh_mobile_sdhi.h>
 #include <linux/mfd/tmio.h>
+#include <media/soc_camera.h>
 #include <mach/hardware.h>
 #include <mach/r8a7779.h>
 #include <mach/common.h>
@@ -178,12 +179,54 @@ static struct platform_device leds_devic
 	},
 };
 
+static struct rcar_vin_platform_data vin_platform_data = {
+	.flags	= RCAR_VIN_BT656,
+};
+
+static struct i2c_board_info i2c_camera[] = {
+	{
+		I2C_BOARD_INFO("adv7180", 0x20),
+	}, {
+		I2C_BOARD_INFO("adv7180", 0x21),
+	},
+};
+
+static struct soc_camera_link iclink_adv7180[] = {
+	{
+		.bus_id		= 1,
+		.i2c_adapter_id	= 0,
+		.board_info	= &i2c_camera[0],
+	}, {
+		.bus_id		= 3,
+		.i2c_adapter_id	= 0,
+		.board_info	= &i2c_camera[1],
+	}
+};
+
+static struct platform_device camera0_device = {
+	.name	= "soc-camera-pdrv",
+	.id	= 0,
+	.dev	= {
+		.platform_data	= &iclink_adv7180[0],
+	},
+};
+
+static struct platform_device camera1_device = {
+	.name	= "soc-camera-pdrv",
+	.id	= 1,
+	.dev	= {
+		.platform_data	= &iclink_adv7180[1],
+	},
+};
+
 static struct platform_device *marzen_devices[] __initdata = {
 	&eth_device,
 	&sdhi0_device,
 	&thermal_device,
 	&hspi_device,
 	&leds_device,
+	&camera0_device,
+	&camera1_device,
 };
 
 static const struct pinctrl_map marzen_pinctrl_map[] = {
@@ -219,6 +262,16 @@ static const struct pinctrl_map marzen_p
 	/* USB2 */
 	PIN_MAP_MUX_GROUP_DEFAULT("ehci-platform.1", "pfc-r8a7779",
 				  "usb2", "usb2"),
+	/* VIN1 */
+	PIN_MAP_MUX_GROUP_DEFAULT("rcar_vin.1", "pfc-r8a7779",
+				  "vin1_clk", "vin1"),
+	PIN_MAP_MUX_GROUP_DEFAULT("rcar_vin.1", "pfc-r8a7779",
+				  "vin1_data8", "vin1"),
+	/* VIN3 */
+	PIN_MAP_MUX_GROUP_DEFAULT("rcar_vin.3", "pfc-r8a7779",
+				  "vin3_clk", "vin3"),
+	PIN_MAP_MUX_GROUP_DEFAULT("rcar_vin.3", "pfc-r8a7779",
+				  "vin3_data8", "vin3"),
 };
 
 static void __init marzen_init(void)
@@ -234,6 +287,8 @@ static void __init marzen_init(void)
 
 	r8a7779_add_standard_devices();
 	r8a7779_add_usb_phy_device(&usb_phy_platform_data);
+	r8a7779_add_vin_device(1, &vin_platform_data);
+	r8a7779_add_vin_device(3, &vin_platform_data);
 	platform_add_devices(marzen_devices, ARRAY_SIZE(marzen_devices));
 }
 


From sergei.shtylyov at cogentembedded.com  Wed Apr 17 18:17:27 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Thu, 18 Apr 2013 02:17:27 +0400
Subject: [PATCH 4/4] ARM: shmobile: Marzen: enable VIN and ADV7180 in defconfig
In-Reply-To: <201304180206.39465.sergei.shtylyov@cogentembedded.com>
References: <201304180206.39465.sergei.shtylyov@cogentembedded.com>
Message-ID: <201304180217.28176.sergei.shtylyov@cogentembedded.com>

From: Vladimir Barinov <vladimir.barinov at cogentembedded.com>

Add the VIN and ADV7180 drivers to 'marzen_defconfig'.

Signed-off-by: Vladimir Barinov <vladimir.barinov at cogentembedded.com>
Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

---
 arch/arm/configs/marzen_defconfig |    7 +++++++
 1 file changed, 7 insertions(+)

Index: renesas/arch/arm/configs/marzen_defconfig
===================================================================
--- renesas.orig/arch/arm/configs/marzen_defconfig
+++ renesas/arch/arm/configs/marzen_defconfig
@@ -84,6 +84,13 @@ CONFIG_GPIO_RCAR=y
 CONFIG_THERMAL=y
 CONFIG_RCAR_THERMAL=y
 CONFIG_SSB=y
+CONFIG_MEDIA_SUPPORT=y
+CONFIG_MEDIA_CAMERA_SUPPORT=y
+CONFIG_V4L_PLATFORM_DRIVERS=y
+CONFIG_SOC_CAMERA=y
+CONFIG_VIDEO_RCAR_VIN=y
+# CONFIG_MEDIA_SUBDRV_AUTOSELECT is not set
+CONFIG_VIDEO_ADV7180=y
 CONFIG_USB=y
 CONFIG_USB_RCAR_PHY=y
 CONFIG_MMC=y


From mturquette at linaro.org  Wed Apr 17 18:26:30 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Wed, 17 Apr 2013 15:26:30 -0700
Subject: [PATCH] clk: vexpress: Add separate SP810 driver
In-Reply-To: <1363358409-5693-1-git-send-email-pawel.moll@arm.com>
References: <1363358409-5693-1-git-send-email-pawel.moll@arm.com>
Message-ID: <20130417222630.19887.75481@quantum>

Quoting Pawel Moll (2013-03-15 07:40:09)
> +static int clk_sp810_timerclken_prepare(struct clk_hw *hw)
> +{
> +       struct clk_sp810_timerclken *timerclken = to_clk_sp810_timerclken(hw);
> +       struct clk_sp810 *sp810 = timerclken->sp810;
> +       struct clk *refclk = of_clk_get(sp810->node, sp810->refclk_index);
> +       struct clk *timclk = of_clk_get(sp810->node, sp810->timclk_index);
> +       struct clk *old_parent = __clk_get_parent(hw->clk);
> +       struct clk *new_parent = old_parent;
> +       int new_parent_index;
> +
> +       if (WARN_ON(IS_ERR(refclk) || IS_ERR(timclk)))
> +               return -ENOENT;
> +
> +       /* Select "better" (faster) parent */
> +       if (__clk_get_rate(refclk) > __clk_get_rate(timclk)) {
> +               new_parent = refclk;
> +               new_parent_index = 0;
> +       } else {
> +               new_parent = timclk;
> +               new_parent_index = 1;
> +       }
> +
> +       /* Switch the parent if necessary */
> +       if (old_parent != new_parent) {
> +               __clk_prepare(new_parent);
> +               clk_sp810_timerclken_set_parent(hw, new_parent_index);
> +               __clk_reparent(hw->clk, new_parent);
> +               __clk_unprepare(old_parent);
> +       }

The reentrancy patch makes some of this less messy.  I have a re-worked
patch below demonstrating this.

> +
> +       return 0;
> +}
> +
> +static const struct clk_ops clk_sp810_timerclken_ops = {
> +       .prepare = clk_sp810_timerclken_prepare,
> +       .get_parent = clk_sp810_timerclken_get_parent,
> +       .set_parent = clk_sp810_timerclken_set_parent,
> +};

I dislike these one-off clk_prepare hacks.  Any time I see a .prepare
callback and not a matching .unprepare callback I know something is
wrong.  At a minimum you should be calling clk_put for the clocks you
"get" from of_clk_get.

In this case you are using clk_prepare for one-time configuration.  I
agree that no alternative exists yet, but there have been discussions
recently about using DT for configuration details that are not strictly
descriptions of the hardware.  I've added a comment block in the patch
below which notes this with a FIXME since there isn't a graceful
alternative to using clk_prepare for ont-time configuration.

Can you test the patch below against the latest clk-next and let me know
if it working on your platform?

Regards,
Mike



From e3f11f34d4f7d3c6c89c43c2100f246d3b91e903 Mon Sep 17 00:00:00 2001
From: Pawel Moll <pawel.moll at arm.com>
Date: Fri, 15 Mar 2013 14:40:09 +0000
Subject: [PATCH] clk: vexpress: Add separate SP810 driver

Factor out the SP810 clocking code into a separate driver,
selecting better (faster) parent at clk_prepare() time.
This is to avoid problems with clocking infrastructure
initialisation order, in particular to avoid dependency
of fixed clock being initialized before SP810. It also
makes vexpress platform OF-based clock initialisation code
unnecessary.

Signed-off-by: Pawel Moll <pawel.moll at arm.com>
Tested-by: Catalin Marinas <catalin.marinas at arm.com>
Signed-off-by: Mike Turquette <mturquette at linaro.org>
[mturquette at linaro.org: add .unprepare, FIXME comment, cleaned up code]
---
 arch/arm/mach-vexpress/v2m.c         |    8 +-
 drivers/clk/versatile/Makefile       |    2 +-
 drivers/clk/versatile/clk-sp810.c    |  186 ++++++++++++++++++++++++++++++++++
 drivers/clk/versatile/clk-vexpress.c |   49 ---------
 4 files changed, 194 insertions(+), 51 deletions(-)
 create mode 100644 drivers/clk/versatile/clk-sp810.c

diff --git a/arch/arm/mach-vexpress/v2m.c b/arch/arm/mach-vexpress/v2m.c
index 915683c..c5e20b5 100644
--- a/arch/arm/mach-vexpress/v2m.c
+++ b/arch/arm/mach-vexpress/v2m.c
@@ -21,6 +21,8 @@
 #include <linux/regulator/fixed.h>
 #include <linux/regulator/machine.h>
 #include <linux/vexpress.h>
+#include <linux/clk-provider.h>
+#include <linux/clkdev.h>
 
 #include <asm/arch_timer.h>
 #include <asm/mach-types.h>
@@ -433,7 +435,7 @@ static void __init v2m_dt_timer_init(void)
 {
 	struct device_node *node = NULL;
 
-	vexpress_clk_of_init();
+	of_clk_init(NULL);
 
 	do {
 		node = of_find_compatible_node(node, NULL, "arm,sp804");
@@ -441,6 +443,10 @@ static void __init v2m_dt_timer_init(void)
 	if (node) {
 		pr_info("Using SP804 '%s' as a clock & events source\n",
 				node->full_name);
+		WARN_ON(clk_register_clkdev(of_clk_get_by_name(node,
+				"timclken1"), "v2m-timer0", "sp804"));
+		WARN_ON(clk_register_clkdev(of_clk_get_by_name(node,
+				"timclken2"), "v2m-timer1", "sp804"));
 		v2m_sp804_init(of_iomap(node, 0),
 				irq_of_parse_and_map(node, 0));
 	}
diff --git a/drivers/clk/versatile/Makefile b/drivers/clk/versatile/Makefile
index ec3b88f..c16ca78 100644
--- a/drivers/clk/versatile/Makefile
+++ b/drivers/clk/versatile/Makefile
@@ -3,5 +3,5 @@ obj-$(CONFIG_ICST)		+= clk-icst.o
 obj-$(CONFIG_ARCH_INTEGRATOR)	+= clk-integrator.o
 obj-$(CONFIG_INTEGRATOR_IMPD1)	+= clk-impd1.o
 obj-$(CONFIG_ARCH_REALVIEW)	+= clk-realview.o
-obj-$(CONFIG_ARCH_VEXPRESS)	+= clk-vexpress.o
+obj-$(CONFIG_ARCH_VEXPRESS)	+= clk-vexpress.o clk-sp810.o
 obj-$(CONFIG_VEXPRESS_CONFIG)	+= clk-vexpress-osc.o
diff --git a/drivers/clk/versatile/clk-sp810.c b/drivers/clk/versatile/clk-sp810.c
new file mode 100644
index 0000000..295375a
--- /dev/null
+++ b/drivers/clk/versatile/clk-sp810.c
@@ -0,0 +1,186 @@
+/*
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Copyright (C) 2013 ARM Limited
+ */
+
+#include <linux/amba/sp810.h>
+#include <linux/clkdev.h>
+#include <linux/clk-provider.h>
+#include <linux/err.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+
+#define to_clk_sp810_timerclken(_hw) \
+		container_of(_hw, struct clk_sp810_timerclken, hw)
+
+struct clk_sp810;
+
+struct clk_sp810_timerclken {
+	struct clk_hw hw;
+	struct clk *clk;
+	struct clk_sp810 *sp810;
+	int channel;
+};
+
+struct clk_sp810 {
+	struct device_node *node;
+	int refclk_index, timclk_index;
+	void __iomem *base;
+	spinlock_t lock;
+	struct clk_sp810_timerclken timerclken[4];
+	struct clk *refclk;
+	struct clk *timclk;
+};
+
+static u8 clk_sp810_timerclken_get_parent(struct clk_hw *hw)
+{
+	struct clk_sp810_timerclken *timerclken = to_clk_sp810_timerclken(hw);
+	u32 val = readl(timerclken->sp810->base + SCCTRL);
+
+	return !!(val & (1 << SCCTRL_TIMERENnSEL_SHIFT(timerclken->channel)));
+}
+
+static int clk_sp810_timerclken_set_parent(struct clk_hw *hw, u8 index)
+{
+	struct clk_sp810_timerclken *timerclken = to_clk_sp810_timerclken(hw);
+	struct clk_sp810 *sp810 = timerclken->sp810;
+	u32 val, shift = SCCTRL_TIMERENnSEL_SHIFT(timerclken->channel);
+	unsigned long flags = 0;
+
+	if (WARN_ON(index > 1))
+		return -EINVAL;
+
+	spin_lock_irqsave(&sp810->lock, flags);
+
+	val = readl(sp810->base + SCCTRL);
+	val &= ~(1 << shift);
+	val |= index << shift;
+	writel(val, sp810->base + SCCTRL);
+
+	spin_unlock_irqrestore(&sp810->lock, flags);
+
+	return 0;
+}
+
+/*
+ * FIXME - setting the parent every time .prepare is invoked is inefficient.
+ * This is better handled by a dedicated clock tree configuration mechanism at
+ * init-time.  Revisit this later when such a mechanism exists
+ */
+static int clk_sp810_timerclken_prepare(struct clk_hw *hw)
+{
+	struct clk_sp810_timerclken *timerclken = to_clk_sp810_timerclken(hw);
+	struct clk_sp810 *sp810 = timerclken->sp810;
+	struct clk *old_parent = __clk_get_parent(hw->clk);
+	struct clk *new_parent;
+
+	if (!sp810->refclk)
+		sp810->refclk = of_clk_get(sp810->node, sp810->refclk_index);
+
+	if (!sp810->timclk)
+		sp810->timclk = of_clk_get(sp810->node, sp810->timclk_index);
+
+	if (WARN_ON(IS_ERR(sp810->refclk) || IS_ERR(sp810->timclk)))
+		return -ENOENT;
+
+	/* Select fastest parent */
+	if (clk_get_rate(sp810->refclk) > clk_get_rate(sp810->timclk)) {
+		new_parent = sp810->refclk;
+	} else {
+		new_parent = sp810->timclk;
+	}
+
+	/* Switch the parent if necessary */
+	if (old_parent != new_parent)
+		clk_set_parent(hw->clk, new_parent);
+
+	return 0;
+}
+
+static void clk_sp810_timerclken_unprepare(struct clk_hw *hw)
+{
+	struct clk_sp810_timerclken *timerclken = to_clk_sp810_timerclken(hw);
+	struct clk_sp810 *sp810 = timerclken->sp810;
+
+	clk_put(sp810->timclk);
+	clk_put(sp810->refclk);
+}
+
+static const struct clk_ops clk_sp810_timerclken_ops = {
+	.prepare = clk_sp810_timerclken_prepare,
+	.unprepare = clk_sp810_timerclken_unprepare,
+	.get_parent = clk_sp810_timerclken_get_parent,
+	.set_parent = clk_sp810_timerclken_set_parent,
+};
+
+struct clk *clk_sp810_timerclken_of_get(struct of_phandle_args *clkspec,
+		void *data)
+{
+	struct clk_sp810 *sp810 = data;
+
+	if (WARN_ON(clkspec->args_count != 1 || clkspec->args[0] >
+			ARRAY_SIZE(sp810->timerclken)))
+		return NULL;
+
+	return sp810->timerclken[clkspec->args[0]].clk;
+}
+
+void __init clk_sp810_of_setup(struct device_node *node)
+{
+	struct clk_sp810 *sp810 = kzalloc(sizeof(*sp810), GFP_KERNEL);
+	const char *parent_names[2];
+	char name[12];
+	struct clk_init_data init;
+	int i;
+
+	if (!sp810) {
+		pr_err("Failed to allocate memory for SP810!\n");
+		return;
+	}
+
+	sp810->refclk_index = of_property_match_string(node, "clock-names",
+			"refclk");
+	parent_names[0] = of_clk_get_parent_name(node, sp810->refclk_index);
+
+	sp810->timclk_index = of_property_match_string(node, "clock-names",
+			"timclk");
+	parent_names[1] = of_clk_get_parent_name(node, sp810->timclk_index);
+
+	if (parent_names[0] <= 0 || parent_names[1] <= 0) {
+		pr_warn("Failed to obtain parent clocks for SP810!\n");
+		return;
+	}
+
+	sp810->node = node;
+	sp810->base = of_iomap(node, 0);
+	spin_lock_init(&sp810->lock);
+
+	init.name = name;
+	init.ops = &clk_sp810_timerclken_ops;
+	init.flags = CLK_IS_BASIC;
+	init.parent_names = parent_names;
+	init.num_parents = ARRAY_SIZE(parent_names);
+
+	for (i = 0; i < ARRAY_SIZE(sp810->timerclken); i++) {
+		snprintf(name, ARRAY_SIZE(name), "timerclken%d", i);
+
+		sp810->timerclken[i].sp810 = sp810;
+		sp810->timerclken[i].channel = i;
+		sp810->timerclken[i].hw.init = &init;
+
+		sp810->timerclken[i].clk = clk_register(NULL,
+				&sp810->timerclken[i].hw);
+		WARN_ON(IS_ERR(sp810->timerclken[i].clk));
+	}
+
+	of_clk_add_provider(node, clk_sp810_timerclken_of_get, sp810);
+}
+CLK_OF_DECLARE(sp810, "arm,sp810", clk_sp810_of_setup);
diff --git a/drivers/clk/versatile/clk-vexpress.c b/drivers/clk/versatile/clk-vexpress.c
index 82b45aa..a4a728d 100644
--- a/drivers/clk/versatile/clk-vexpress.c
+++ b/drivers/clk/versatile/clk-vexpress.c
@@ -15,8 +15,6 @@
 #include <linux/clkdev.h>
 #include <linux/clk-provider.h>
 #include <linux/err.h>
-#include <linux/of.h>
-#include <linux/of_address.h>
 #include <linux/vexpress.h>
 
 static struct clk *vexpress_sp810_timerclken[4];
@@ -86,50 +84,3 @@ void __init vexpress_clk_init(void __iomem *sp810_base)
 	WARN_ON(clk_register_clkdev(vexpress_sp810_timerclken[1],
 				"v2m-timer1", "sp804"));
 }
-
-#if defined(CONFIG_OF)
-
-struct clk *vexpress_sp810_of_get(struct of_phandle_args *clkspec, void *data)
-{
-	if (WARN_ON(clkspec->args_count != 1 || clkspec->args[0] >
-			ARRAY_SIZE(vexpress_sp810_timerclken)))
-		return NULL;
-
-	return vexpress_sp810_timerclken[clkspec->args[0]];
-}
-
-void __init vexpress_clk_of_init(void)
-{
-	struct device_node *node;
-	struct clk *clk;
-	struct clk *refclk, *timclk;
-
-	of_clk_init(NULL);
-
-	node = of_find_compatible_node(NULL, NULL, "arm,sp810");
-	vexpress_sp810_init(of_iomap(node, 0));
-	of_clk_add_provider(node, vexpress_sp810_of_get, NULL);
-
-	/* Select "better" (faster) parent for SP804 timers */
-	refclk = of_clk_get_by_name(node, "refclk");
-	timclk = of_clk_get_by_name(node, "timclk");
-	if (!WARN_ON(IS_ERR(refclk) || IS_ERR(timclk))) {
-		int i = 0;
-
-		if (clk_get_rate(refclk) > clk_get_rate(timclk))
-			clk = refclk;
-		else
-			clk = timclk;
-
-		for (i = 0; i < ARRAY_SIZE(vexpress_sp810_timerclken); i++)
-			WARN_ON(clk_set_parent(vexpress_sp810_timerclken[i],
-					clk));
-	}
-
-	WARN_ON(clk_register_clkdev(vexpress_sp810_timerclken[0],
-				"v2m-timer0", "sp804"));
-	WARN_ON(clk_register_clkdev(vexpress_sp810_timerclken[1],
-				"v2m-timer1", "sp804"));
-}
-
-#endif
-- 
1.7.10.4



From sergei.shtylyov at cogentembedded.com  Wed Apr 17 18:29:16 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Thu, 18 Apr 2013 02:29:16 +0400
Subject: [PATCH 3/4] ARM: shmobile: Marzen: add VIN and ADV7180 support
In-Reply-To: <201304180215.01218.sergei.shtylyov@cogentembedded.com>
References: <201304180206.39465.sergei.shtylyov@cogentembedded.com>
 <201304180215.01218.sergei.shtylyov@cogentembedded.com>
Message-ID: <516F223C.2010704@cogentembedded.com>

Hello.

On 04/18/2013 02:15 AM, Sergei Shtylyov wrote:

> From: Vladimir Barinov <vladimir.barinov at cogentembedded.com>
>
> Add ADV7180 platform devices on the Marzen board, configure VIN1/3 pins, and
> register VIN1/3 devices with the ADV7180 specific platform data.
>
> Signed-off-by: Vladimir Barinov <vladimir.barinov at cogentembedded.com>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
>
> ---
>   arch/arm/mach-shmobile/board-marzen.c |   55 ++++++++++++++++++++++++++++++++++
>   1 file changed, 55 insertions(+)

    Oops, should have updated copyrights on this file. :-/
    Well, this is probably not the last version of the patchset 
anyway... :-)

WBR, Sergei



From matt at genesi-usa.com  Wed Apr 17 18:52:01 2013
From: matt at genesi-usa.com (Matt Sealey)
Date: Wed, 17 Apr 2013 17:52:01 -0500
Subject: [PATCH] ARM: mach-imx6q: Remove code for setting up cko clock
In-Reply-To: <CAKGA1bnMUBhXdsfOsBOm2T2VA=FHDWHthbPcXqA7eHX1DPJvkw@mail.gmail.com>
References: <1366224182-29285-1-git-send-email-festevam@gmail.com>
 <20130417195744.GX1906@pengutronix.de>
 <CAKGA1bnMUBhXdsfOsBOm2T2VA=FHDWHthbPcXqA7eHX1DPJvkw@mail.gmail.com>
Message-ID: <CAKGA1bk7Eek4h8_6HAerOthB7Bh80U4gC181qevr496ooXTk1g@mail.gmail.com>

Resending to LAKML in plaintext (Google ARGH..), apologies for anyone
receiving it twice..

--
Matt Sealey <matt at genesi-usa.com>
Product Development Analyst, Genesi USA, Inc.

On Wed, Apr 17, 2013 at 5:29 PM, Matt Sealey <matt at genesi-usa.com> wrote:
> On Wed, Apr 17, 2013 at 2:57 PM, Sascha Hauer <s.hauer at pengutronix.de>
> wrote:
>>
>> On Wed, Apr 17, 2013 at 03:43:02PM -0300, Fabio Estevam wrote:
>> > From: Fabio Estevam <fabio.estevam at freescale.com>
>> >
>> > Let the bootloader setup the cko clock that drives the audio codec.
>> >
>>
>> I really don't like such stuff. Where is documented what's expected from
>> the bootloader?
>
>
> Schematics for the board - and basically a flat-out recommendation that all
> clocks that need to be set to something other than power-on defaults need to
> be set to their expected parents and rates at bootloader time even if
> they're not used by the bootloader, unless they can be confirmed totally
> unused (in which case, they needn't even be in the device tree and Linux
> will just never know they even exist).
>
> This is a fact of life.. I don't see why Linux should end up with a bunch of
> board-specific hacks to work around broken bootloaders when we're talking
> about DT-supported boards. In this case, probably everyone has to go get a
> new U-Boot anyway to even boot a kernel that would show this problem (no
> Freescale board ever shipped before 2012 with a dt-capable U-Boot, so unless
> you're using DTB_APPEND..).
>
>> Which versions of which bootloader do implement this?
>>
>> The code you remove is not particularly nice, but just removing it is no
>> solution to the problem.
>>
>>
>> > This simplifies a lot the code and when a new board needs to add audio
>> > support,
>> > it will not have to add all this amount of code again.
>>
>> It shouldn't be necessary to duplicate the code for each board.
>
>
>
> But it usually is - even if there is a generic "set up clko" routine where
> you pass a parent and a desired rate, a bunch of boards will end up calling
> it, and in the end it's basically a workaround for the fact that the
> bootloader did NOT set this up (when it should!)
>
> For an audio codec, this rate is basically nearly always fixed (and where it
> isn't.. it's up to the codec driver to set_rate on it's specified clock when
> it needs to). Since it isn't possible to dictate clock frequency in the
> device tree right now, and I at least would prefer that we didn't store "yet
> to be configured, please assure this" kind of directives in device tree, the
> bootloader is the best place.
>
> There's similar code in MX5 platforms right now which reparents the USB PHY
> clock to one that can actually can generate desired rates for USB PHYs
> (which is coordinated with some other code which sets the USB PHY rate
> inside the PHY). In any case here, all MX5 chips boot with an "impossible"
> USB PHY configuration (there is no clock parent that can give it that rate,
> it must be changed), and it is not possible to use the default parent to
> generate two of the other rates either. This is a bootloader thing for sure.
> Linux should not be working around this. There's also code that sets parents
> for eSDHC controllers; this is global code run on every board, and only
> works because every board designer - so far - didn't bother to do something
> different (as it stands, the eSDHC gets a reaaaally weird rate because of
> it, and it is surprising nobody noticed..)
>
> Even if we had such directives in DT, 99.9% of it would be reproduction of
> clock setting code in bootloader being dumped into the device tree and
> re-set by Linux yet again. That can cause glitches which can cause devices
> like codecs to basically go into indeterminate states (and some of these
> devices simply don't have resets, so they stay in those states unless
> powered off and on again, and sometimes the regulators aren't configurable -
> all this is in the schematics for the board if they're available).
>
> When your Linux kernel warns (and it should warn in each driver that detects
> a weirdo clock scenario that can detect it) that you may need a new
> bootloader, then updating the bootloader is necessary. For boards where the
> developers don't like you to update the bootloader, well.. ours are a couple
> of those, and to be honest, I will happily ship firmware updates when
> there's some platform support for our board, which I've still not gotten
> round to doing yet (busy...)
>
> The usual scenario here is that there was a lazy port of BSP code to
> mainline U-Boot and you're running that instead of the BSP version
> (*ahemlinarocough*), someone coded bootloader support but assumed Linux will
> just set it up (*ahemfreescalecough*) or someone hacked up support for a
> board which has no public schematics (GK802/Richtechie MT-500A comes to
> mind) and no open-sourced board support (which is illegal by any means in
> the aforementioned case) - basically fixable (Linaro usually recommends
> using a Linaro U-Boot for example), fixable (someone may need to align board
> support mainline U-Boot and mainline Linux at some point), and no reason to
> ever bother with criminals - respectively.
>
> What we're discussing here is basically "it used to work and now Fabio broke
> Linux" - actually, Fabio is removing an egregious hack that should never
> have been there in the first place, Linux works fine ("as always"), and the
> bootloader is broken.. it would never have passed QA for consumer
> electronics. Since these are developer boards, we can be forgiving up to a
> point...
>
> --
> Matt Sealey <matt at genesi-usa.com>
> Product Development Analyst, Genesi USA, Inc.
>


From robherring2 at gmail.com  Wed Apr 17 19:18:23 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Wed, 17 Apr 2013 18:18:23 -0500
Subject: [GIT PULL] Timer clean-ups for 3.10, Part 2
In-Reply-To: <516EE86A.9070003@codeaurora.org>
References: <516720B4.3000703@gmail.com> <516DEC68.8030101@codeaurora.org>
 <516EA638.1060800@gmail.com> <516EE86A.9070003@codeaurora.org>
Message-ID: <516F2DBF.30401@gmail.com>

On 04/17/2013 01:22 PM, Stephen Boyd wrote:
> On 04/17/13 06:40, Rob Herring wrote:
>> On 04/16/2013 07:27 PM, Stephen Boyd wrote:
>>> On 04/11/13 13:44, Rob Herring wrote:
>>>> Rob Herring (13):
>>>>       ARM: sched_clock: allow changing to higher frequency counter
>>>>       ARM: make sched_clock just call a function pointer
>>>>       ARM: arch_timer: use full 64-bit counter for sched_clock
>>> If I leave my system in the bootloader for a while this seems to cause
>>> my sched_clock timestamps to jump once the sched_clock is setup. It also
>>> sets up a sched_clock twice because read_sched_clock ==
>>> jiffy_sched_clock_read.
>>>
>>> [    0.000000] Switching to timer-based delay loop
>>> [    0.000000] sched_clock: ARM arch timer >56 bits at 19200kHz,
>>> resolution 52ns
>>> [    0.000000] sched_clock: 32 bits at 100 Hz, resolution 10000000ns,
>>> wraps every 4294967286ms
>>> [    0.000000] Console: colour dummy device 80x30
>>> [16645.193054] Calibrating delay loop (skipped), value calculated using
>>> timer frequency.. 38.40 BogoMIPS (lpj=192000)
>>>
>>> I suspect it's because we don't do any cyc_to_sched_clock() stuff in the
>>> arm architected timer case. Instead we just return the value from the
>>> counter when we really should do some sort of subtraction from the first
>>> value we read.
>>>
>>> I'm also curious how this is going to work for suspend/resume because it
>>> doesn't look like we're going to stop sched_clock on arm architected
>>> timer systems. See 6a4dae5e138a3 (ARM: 7565/1: sched: stop sched_clock()
>>> during suspend, 2012-10-23) for why we need to do this.
>>
>> Well, I think arm64 is broken in both ways too. So we should fix this
>> for both.
>>
>> I think this can be handled in a much more simple way than the 32-bit
>> code since we don't need to deal with wrapping.
>>
>> Maintain a cycle offset that starts as the cycle count at init time.
>> This offset can be subtracted from the current count. On suspend and
>> resume, we need to calculate the cycle count delta while in suspend and
>> then add this to the cycle offset.
> 
> Agreed. It looks like we're missing out on the irq time accounting stuff
> because enable_sched_clock_irqtime() is never called too.
> 

Yes, but until ARM selects HAVE_IRQ_TIME_ACCOUNTING that doesn't matter.
Looks like adding that was forgotten.

Rob



From sboyd at codeaurora.org  Wed Apr 17 19:26:18 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Wed, 17 Apr 2013 16:26:18 -0700
Subject: [PATCH/RESEND] ARM: arch_timer: Silence debug preempt warnings
Message-ID: <1366241178-16626-1-git-send-email-sboyd@codeaurora.org>

Hot-plugging with CONFIG_DEBUG_PREEMPT=y on a device with arm
architected timers causes a slew of "using smp_processor_id() in
preemptible" warnings:

  BUG: using smp_processor_id() in preemptible [00000000] code: sh/111
  caller is arch_timer_cpu_notify+0x14/0xc8

This happens because sometimes the cpu notifier,
arch_timer_cpu_notify(), is called in preemptible context and
other times in non-preemptible context but we use this_cpu_ptr()
to retrieve the clockevent in all cases. We're only going to
actually use the pointer in non-preemptible context though, so
push the this_cpu_ptr() access down into the cases to force the
checks to occur only in non-preemptible contexts.

Cc: John Stultz <john.stultz at linaro.org>
Cc: Thomas Gleixner <tglx at linutronix.de>
Cc: Mark Rutland <mark.rutland at arm.com>
Acked-by: Marc Zyngier <Marc.Zyngier at arm.com>
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---

Resending to arm-soc maintainers instead of timekeeping maintainers. Who
maintains this driver?

 drivers/clocksource/arm_arch_timer.c | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
index d7ad425..a65a710 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -248,14 +248,16 @@ static void __cpuinit arch_timer_stop(struct clock_event_device *clk)
 static int __cpuinit arch_timer_cpu_notify(struct notifier_block *self,
 					   unsigned long action, void *hcpu)
 {
-	struct clock_event_device *evt = this_cpu_ptr(arch_timer_evt);
-
+	/*
+	 * Grab cpu pointer in each case to avoid spurious
+	 * preemptible warnings
+	 */
 	switch (action & ~CPU_TASKS_FROZEN) {
 	case CPU_STARTING:
-		arch_timer_setup(evt);
+		arch_timer_setup(this_cpu_ptr(arch_timer_evt));
 		break;
 	case CPU_DYING:
-		arch_timer_stop(evt);
+		arch_timer_stop(this_cpu_ptr(arch_timer_evt));
 		break;
 	}
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sfr at canb.auug.org.au  Wed Apr 17 19:39:06 2013
From: sfr at canb.auug.org.au (Stephen Rothwell)
Date: Thu, 18 Apr 2013 09:39:06 +1000
Subject: linux-next: useless merges
Message-ID: <20130418093906.f965a1e17bcbe1be6ecfa50c@canb.auug.org.au>

Hi guys,

The only change in the arm-soc tree since yesterday (3035229f89dc), is to
merge a merge that just merges two branches that were already merged into
arm-soc some time ago!

Please be a bit more careful, this just complicates the tree for no
reason.

-- 
Cheers,
Stephen Rothwell                    sfr at canb.auug.org.au
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130418/1c757896/attachment.sig>

From olof at lixom.net  Wed Apr 17 19:47:19 2013
From: olof at lixom.net (Olof Johansson)
Date: Wed, 17 Apr 2013 16:47:19 -0700
Subject: linux-next: useless merges
In-Reply-To: <20130418093906.f965a1e17bcbe1be6ecfa50c@canb.auug.org.au>
References: <20130418093906.f965a1e17bcbe1be6ecfa50c@canb.auug.org.au>
Message-ID: <CAOesGMj1FBbYkByXAjOL3Op_LmpinjkKzdrjwY99QKDs8Wk-eg@mail.gmail.com>

Yeah, that's my fault. I rebuilt one of the branches and merged in the
new version which ended up being a NULL operation.

It'll go away when we rebuild for-next (we don't send our aggregated
for-next branch to Linus, just the individual branches that are part
of it).


-Olof

On Wed, Apr 17, 2013 at 4:39 PM, Stephen Rothwell <sfr at canb.auug.org.au> wrote:
> Hi guys,
>
> The only change in the arm-soc tree since yesterday (3035229f89dc), is to
> merge a merge that just merges two branches that were already merged into
> arm-soc some time ago!
>
> Please be a bit more careful, this just complicates the tree for no
> reason.
>
> --
> Cheers,
> Stephen Rothwell                    sfr at canb.auug.org.au


From jon-hunter at ti.com  Wed Apr 17 19:56:06 2013
From: jon-hunter at ti.com (Jon Hunter)
Date: Wed, 17 Apr 2013 18:56:06 -0500
Subject: [PATCH 1/2] ARM: dts: OMAP5: add PWM capability to timer nodes
 missing it
In-Reply-To: <1366240995-53538-1-git-send-email-s-anna@ti.com>
References: <1366240995-53538-1-git-send-email-s-anna@ti.com>
Message-ID: <516F3696.9080008@ti.com>


On 04/17/2013 06:23 PM, Suman Anna wrote:
> OMAP5 has 6 timers (GPTimers 5, 6, 8 to 11) that are capable of PWM.
> The PWM capability property is missing from the node definitions of
> couple of timers, and this has been fixed.
> 
> Signed-off-by: Suman Anna <s-anna at ti.com>
> ---
>  arch/arm/boot/dts/omap5.dtsi | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
> index 790bb2a..0d155f5 100644
> --- a/arch/arm/boot/dts/omap5.dtsi
> +++ b/arch/arm/boot/dts/omap5.dtsi
> @@ -422,6 +422,7 @@
>  			interrupts = <0 41 0x4>;
>  			ti,hwmods = "timer5";
>  			ti,timer-dsp;
> +			ti,timer-pwm;
>  		};
>  
>  		timer6: timer at 4013a000 {
> @@ -458,6 +459,7 @@
>  			reg = <0x4803e000 0x80>;
>  			interrupts = <0 45 0x4>;
>  			ti,hwmods = "timer9";
> +			ti,timer-pwm;
>  		};
>  
>  		timer10: timer at 48086000 {
> @@ -465,6 +467,7 @@
>  			reg = <0x48086000 0x80>;
>  			interrupts = <0 46 0x4>;
>  			ti,hwmods = "timer10";
> +			ti,timer-pwm;
>  		};
>  
>  		timer11: timer at 48088000 {

Make sure you copy the linux-arm and device-tree mailing lists.

Acked-by: Jon Hunter <jon-hunter at ti.com>

Thanks!
Jon



From sboyd at codeaurora.org  Wed Apr 17 20:34:45 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Wed, 17 Apr 2013 17:34:45 -0700
Subject: [PATCH] ARM: sched_clock: Add more notrace to prevent recursion
In-Reply-To: <5151DC75.7030606@codeaurora.org>
References: <1363306086-23501-1-git-send-email-sboyd@codeaurora.org>
 <514B483F.7000304@codeaurora.org> <5151DC75.7030606@codeaurora.org>
Message-ID: <516F3FA5.8070307@codeaurora.org>

On 03/26/13 10:35, Stephen Boyd wrote:
> On 03/21/13 10:49, Stephen Boyd wrote:
>> On 03/14/13 17:08, Stephen Boyd wrote:
>>> cyc_to_sched_clock() is called by sched_clock() and cyc_to_ns()
>>> is called by cyc_to_sched_clock(). I suspect that some compilers
>>> inline both of these functions into sched_clock() and so we've
>>> been getting away without having a notrace marking. It seems that
>>> my compiler isn't inlining cyc_to_sched_clock() though, so I'm
>>> hitting a recursion bug when I enable the function graph tracer,
>>> causing my system to crash. Marking these functions notrace fixes
>>> it. Technically cyc_to_ns() doesn't need the notrace because it's
>>> already marked inline, but let's just add it so that if we ever
>>> remove inline from that function it doesn't blow up.
>> Anyone else seeing this problem?
> Russell, should I put this into the patch tracker?

I'll throw this into the patch tracker tomorrow if nobody complains.

>>> Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
>>> ---
>>>  arch/arm/kernel/sched_clock.c | 4 ++--
>>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/arch/arm/kernel/sched_clock.c b/arch/arm/kernel/sched_clock.c
>>> index bd6f56b..59d2adb 100644
>>> --- a/arch/arm/kernel/sched_clock.c
>>> +++ b/arch/arm/kernel/sched_clock.c
>>> @@ -45,12 +45,12 @@ static u32 notrace jiffy_sched_clock_read(void)
>>>  
>>>  static u32 __read_mostly (*read_sched_clock)(void) = jiffy_sched_clock_read;
>>>  
>>> -static inline u64 cyc_to_ns(u64 cyc, u32 mult, u32 shift)
>>> +static inline u64 notrace cyc_to_ns(u64 cyc, u32 mult, u32 shift)
>>>  {
>>>  	return (cyc * mult) >> shift;
>>>  }
>>>  
>>> -static unsigned long long cyc_to_sched_clock(u32 cyc, u32 mask)
>>> +static unsigned long long notrace cyc_to_sched_clock(u32 cyc, u32 mask)
>>>  {
>>>  	u64 epoch_ns;
>>>  	u32 epoch_cyc;
>


-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation



From kuninori.morimoto.gx at renesas.com  Wed Apr 17 20:44:55 2013
From: kuninori.morimoto.gx at renesas.com (Kuninori Morimoto)
Date: Wed, 17 Apr 2013 17:44:55 -0700 (PDT)
Subject: [PATCH 0/2] Add I2C support to R8A7778/BOCK-W
In-Reply-To: <201304172242.27671.sergei.shtylyov@cogentembedded.com>
References: <201304172242.27671.sergei.shtylyov@cogentembedded.com>
Message-ID: <87sj2osm4b.wl%kuninori.morimoto.gx@renesas.com>


Hi

>    Here's the set of 2 patches against the Simon Horman's 'renesas.git' repo,
> 'renesas-next-20130417' tag and my recent yet unapplied patches. Here we
> add I2C support to the R8A7778 platform code and enable I2C driver on BOCK-W
> board. This will be important in the future for the VIN driver since the video
> sensor chip is controller via I2C bus #0 on BOCK-W. 
> 
> [1/2] ARM: shmobile: r8a7778: add I2C support
> [2/2] ARM: shmobile: BOCK-W: enable I2C in defconfig

For all patches

Acked-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>

Best regards
---
Kuninori Morimoto


From kuninori.morimoto.gx at renesas.com  Wed Apr 17 20:48:05 2013
From: kuninori.morimoto.gx at renesas.com (Kuninori Morimoto)
Date: Wed, 17 Apr 2013 17:48:05 -0700 (PDT)
Subject: [PATCH 2/4] ARM: shmobile: r8a7779: add VIN support
In-Reply-To: <201304180213.15118.sergei.shtylyov@cogentembedded.com>
References: <201304180206.39465.sergei.shtylyov@cogentembedded.com>
 <201304180213.15118.sergei.shtylyov@cogentembedded.com>
Message-ID: <87r4i8slz2.wl%kuninori.morimoto.gx@renesas.com>


Hi Sergei

> From: Vladimir Barinov <vladimir.barinov at cogentembedded.com>
> 
> Add VIN clocks and platform devices for R8A7779 SoC; add function to register
> the VIN platform devices.
> 
> Signed-off-by: Vladimir Barinov <vladimir.barinov at cogentembedded.com>
> [Sergei: renamed some variables]
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
(snip)
> +void __init r8a7779_add_vin_device(int id,
> +				   struct rcar_vin_platform_data *pdata)
> +{
> +	vin_info_table[id]->data = pdata;
> +	vin_info_table[id]->size_data = sizeof(struct rcar_vin_platform_data);
> +
> +	platform_device_register_full(vin_info_table[id]);
> +}

Can you add "id" check here ?

BUG_ON(id < 0 || id >= ARRAY_SIZE(vin_info_table));
or similar

Best regards
---
Kuninori Morimoto


From horms at verge.net.au  Wed Apr 17 21:09:22 2013
From: horms at verge.net.au (Simon Horman)
Date: Thu, 18 Apr 2013 10:09:22 +0900
Subject: [PATCH] ARM: shmobile: add missing include of of.h
In-Reply-To: <1366225302-23150-1-git-send-email-olof@lixom.net>
References: <1366225302-23150-1-git-send-email-olof@lixom.net>
Message-ID: <20130418010922.GB4511@verge.net.au>

On Wed, Apr 17, 2013 at 12:01:42PM -0700, Olof Johansson wrote:
> Fixes the following build warnings:
> 
> In file included from arch/arm/mach-shmobile/setup-r8a7779.c:25:0:
> include/linux/of_platform.h:107:13: warning: 'struct of_device_id' declared inside parameter list [enabled by default]
> include/linux/of_platform.h:107:13: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default]
> include/linux/of_platform.h:107:13: warning: 'struct device_node' declared inside parameter list [enabled by default]
> 
> Signed-off-by: Olof Johansson <olof at lixom.net>
> ---
> 
> Hi Simon,
> 
> I'll just apply this directly if it's OK with you?

Its ok with me.

Acked-by: Simon Horman <horms+renesas at verge.net.au>


> 
> 
> 
> -Olof
> 
>  arch/arm/mach-shmobile/setup-r8a7779.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/mach-shmobile/setup-r8a7779.c b/arch/arm/mach-shmobile/setup-r8a7779.c
> index b0b3948..7413fc0 100644
> --- a/arch/arm/mach-shmobile/setup-r8a7779.c
> +++ b/arch/arm/mach-shmobile/setup-r8a7779.c
> @@ -22,6 +22,7 @@
>  #include <linux/init.h>
>  #include <linux/interrupt.h>
>  #include <linux/irq.h>
> +#include <linux/of.h>
>  #include <linux/of_platform.h>
>  #include <linux/platform_data/gpio-rcar.h>
>  #include <linux/platform_device.h>
> -- 
> 1.8.1.192.gc4361b8
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 


From weiyj.lk at gmail.com  Wed Apr 17 23:18:19 2013
From: weiyj.lk at gmail.com (Wei Yongjun)
Date: Thu, 18 Apr 2013 11:18:19 +0800
Subject: [PATCH -next] [media] s5p-mfc: fix error return code in
 s5p_mfc_probe()
Message-ID: <CAPgLHd_TwmtoaE7T7e3fRKh4NTGhOYjQZv0G7nt-iSVMLz3XEQ@mail.gmail.com>

From: Wei Yongjun <yongjun_wei at trendmicro.com.cn>

Fix to return a negative error code from the error handling
case instead of 0, as returned elsewhere in this function.

Signed-off-by: Wei Yongjun <yongjun_wei at trendmicro.com.cn>
---
 drivers/media/platform/s5p-mfc/s5p_mfc.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index e810b1a..a5853fa 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -1110,7 +1110,8 @@ static int s5p_mfc_probe(struct platform_device *pdev)
 	}
 
 	if (pdev->dev.of_node) {
-		if (s5p_mfc_alloc_memdevs(dev) < 0)
+		ret = s5p_mfc_alloc_memdevs(dev);
+		if (ret < 0)
 			goto err_res;
 	} else {
 		dev->mem_dev_l = device_find_child(&dev->plat_dev->dev,



From tony at atomide.com  Wed Apr 17 23:39:37 2013
From: tony at atomide.com (Tony Lindgren)
Date: Wed, 17 Apr 2013 20:39:37 -0700
Subject: [GIT PULL] omap dss board clean-up for v3.10 merge window
Message-ID: <20130418033936.GC10155@atomide.com>

The following changes since commit 07961ac7c0ee8b546658717034fe692fd12eefa9:

  Linux 3.9-rc5 (2013-03-31 15:12:43 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.10/dss-signed

for you to fetch changes up to 4de2a2b4aeabe5c8b11ab8655ad59c55b3d91962:

  Merge branch '3.10-lo/board-cleanup' of git://gitorious.org/linux-omap-dss2/linux into omap-for-v3.10/dss (2013-04-17 17:09:04 -0700)

----------------------------------------------------------------

Display related clean-up from Tomi Valkeinen.

These were separated from the DSS driver changes to leave out
a dependency between the driver and arch/arm related code.

As agreed on the mailing lists, these are based on Tomi's
platform_data header branch at:

git://gitorious.org/linux-omap-dss2/linux.git 3.10/0-dss-headers

Note that these patches have already been in Linux next via
Tomi's tree. As Tomi's driver changes are getting merged via
the drm tree because of another dependency, these should get
merged via the ARM SoC tree.

Apologies for the late pull request on this one, this dependency
should have been cleared away earlier.

----------------------------------------------------------------
Archit Taneja (14):
      OMAPDSS: panels: keep platform data of all panels in a single header
      arm: omap: board-2430: use generic dpi panel's gpio handling
      arm: omap: board-devkit8000: use generic dpi panel's gpio handling
      arm: omap: board-am3517: use generic dpi panel's gpio handling
      arm: omap: board-ldp: use generic dpi panel's gpio handling
      arm: omap: board-overo: use lb035q02 dpi panel's gpio handling
      arm: omap: board-omap3evm: use sharp panel's gpio handling
      arm: omap: board-sdp3430: use sharp panel's gpio handling
      arm: omap: board-rx-51: use acx565akm panel's gpio handling
      arm: omap: board-zoom: use NEC panel's gpio handling
      arm: omap: board-omap3pandora: use tpo panel's gpio handling
      arm: omap: dss-common: use picodlp panel's gpio handling
      arm: omap boards: Remove unnecessary platform_enable/disable callbacks for VENC devices
      arm: dss-common: don't use reset_gpio from omap4_panda_dvi_device

Peter Ujfalusi (1):
      ARM: OMAP: zoom: Use pwm stack for lcd and keyboard backlight

Tomi Valkeinen (2):
      OMAPDSS: add fields to panels' platform data
      arm: omap: board-cm-t35: use generic dpi panel's gpio handling

Tony Lindgren (1):
      Merge branch '3.10-lo/board-cleanup' of git://gitorious.org/linux-omap-dss2/linux into omap-for-v3.10/dss

 arch/arm/mach-omap2/board-2430sdp.c              |  45 ++-----
 arch/arm/mach-omap2/board-3430sdp.c              |  55 +++-----
 arch/arm/mach-omap2/board-am3517evm.c            |  77 ++----------
 arch/arm/mach-omap2/board-cm-t35.c               |  63 ++--------
 arch/arm/mach-omap2/board-devkit8000.c           |  30 +----
 arch/arm/mach-omap2/board-h4.c                   |   2 +-
 arch/arm/mach-omap2/board-igep0020.c             |   2 +-
 arch/arm/mach-omap2/board-ldp.c                  |  63 ++--------
 arch/arm/mach-omap2/board-omap3beagle.c          |   2 +-
 arch/arm/mach-omap2/board-omap3evm.c             |  72 ++++-------
 arch/arm/mach-omap2/board-omap3pandora.c         |   7 +-
 arch/arm/mach-omap2/board-omap3stalker.c         |  14 +--
 arch/arm/mach-omap2/board-overo.c                |  61 +++------
 arch/arm/mach-omap2/board-rx51-video.c           |  26 ++--
 arch/arm/mach-omap2/board-zoom-display.c         |  94 ++------------
 arch/arm/mach-omap2/board-zoom-peripherals.c     |  53 +++++++-
 arch/arm/mach-omap2/dss-common.c                 |  58 +++------
 drivers/video/omap2/displays/panel-generic-dpi.c |   2 +-
 drivers/video/omap2/displays/panel-n8x0.c        |   2 +-
 drivers/video/omap2/displays/panel-picodlp.c     |   2 +-
 drivers/video/omap2/displays/panel-taal.c        |   2 +-
 drivers/video/omap2/displays/panel-tfp410.c      |   2 +-
 include/video/omap-panel-data.h                  | 152 +++++++++++++++++++++++
 include/video/omap-panel-generic-dpi.h           |  37 ------
 include/video/omap-panel-n8x0.h                  |  15 ---
 include/video/omap-panel-nokia-dsi.h             |  32 -----
 include/video/omap-panel-picodlp.h               |  23 ----
 include/video/omap-panel-tfp410.h                |  35 ------
 28 files changed, 349 insertions(+), 679 deletions(-)
 create mode 100644 include/video/omap-panel-data.h
 delete mode 100644 include/video/omap-panel-generic-dpi.h
 delete mode 100644 include/video/omap-panel-n8x0.h
 delete mode 100644 include/video/omap-panel-nokia-dsi.h
 delete mode 100644 include/video/omap-panel-picodlp.h
 delete mode 100644 include/video/omap-panel-tfp410.h


From hvaibhav at ti.com  Thu Apr 18 00:49:37 2013
From: hvaibhav at ti.com (Hiremath, Vaibhav)
Date: Thu, 18 Apr 2013 04:49:37 +0000
Subject: [GIT PULL] ARM: OMAP5: hwmod, prm/cm data files and updates for
 3.10
In-Reply-To: <516B9C14.5070406@ti.com>
References: <1363768852-18125-1-git-send-email-santosh.shilimkar@ti.com>
 <20130401170539.GK10155@atomide.com> <515BA76D.3000302@ti.com>
 <alpine.DEB.2.00.1304031146230.2616@utopia.booyaka.com>
 <515D6020.2030103@ti.com> <20130404165208.GI10155@atomide.com>
 <515DB110.9000503@ti.com> <515F00B8.3000501@ti.com>
 <79CD15C6BA57404B839C016229A409A83EC4A81D@DBDE01.ent.ti.com>
 <51654DC5.2040909@ti.com>
 <79CD15C6BA57404B839C016229A409A83EC55521@DBDE01.ent.ti.com>
 <516B9C14.5070406@ti.com>
Message-ID: <79CD15C6BA57404B839C016229A409A83EC57E9E@DBDE01.ent.ti.com>

> -----Original Message-----
> From: Shilimkar, Santosh
> Sent: Monday, April 15, 2013 11:50 AM
> To: Hiremath, Vaibhav
> Cc: Tony Lindgren; Paul Walmsley; linux-omap at vger.kernel.org; linux-
> arm-kernel at lists.infradead.org; Kristo, Tero; Menon, Nishanth; Nayak,
> Rajendra; Valentin, Eduardo; Anna, Suman; Bedia, Vaibhav
> Subject: Re: [GIT PULL] ARM: OMAP5: hwmod, prm/cm data files and
> updates for 3.10
> 
> On Monday 15 April 2013 10:36 AM, Hiremath, Vaibhav wrote:
> >
> >> -----Original Message-----
> >> From: Shilimkar, Santosh
> >> Sent: Wednesday, April 10, 2013 5:02 PM
> 
> [..]
> 
<snip>
> Yes :-)
> It will be great if you take the patch forward and update it
> based on the discussion.
> 

I have cleanup the AM33xx hwmod data file and below is the patch for your reference.
Feel free to include it into your next version of patch-series -


>From 72d96c8736cc8c7bd983b758f2e2288ca604a084 Mon Sep 17 00:00:00 2001
From: Vaibhav Hiremath <hvaibhav at ti.com>
Date: Tue, 16 Apr 2013 13:34:56 +0530
Subject: [PATCH] ARM: AM33XX: hwmod data: irq, dma and addr info clean up

AM33XX only supports DT boot mode and with addition of
extracting module resources like, irq, dma and address space
from DT block, so now we can remove duplicate information from
hwmod data file.

This patch cleanups-up/deletes,

     - All references to "omap_hwmod_irq_info" data.
     - All references to "omap_hwmod_dma_info" data.
     - References to "omap_hwmod_addr_space" of the modules
       for which DT node is available with required address
       space information.
     - For the modules where "sysc" field is not applicable,
       we don't need module address space, so remove them as well.
     - The hwmod like firewall etc which are not useful are also
       deleted.

This cleanup gets us around ~1100 LOC of negative diff.
Patch is boot tested on AM335x-EVM along with below modules -
	- Matrix-keypad
	- Volume up/down keys
	- Ethernet
	- RTC
	- WDT

Signed-off-by: Vaibhav Hiremath <hvaibhav at ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
Signed-off-by: Sricharan R <r.sricharan at ti.com>
---
 arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 1067 ----------------------------
 1 files changed, 0 insertions(+), 1067 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index 01d8f32..a44d37d 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -35,29 +35,6 @@
  */
 
 /*
- * 'emif_fw' class
- * instance(s): emif_fw
- */
-static struct omap_hwmod_class am33xx_emif_fw_hwmod_class = {
-	.name		= "emif_fw",
-};
-
-/* emif_fw */
-static struct omap_hwmod am33xx_emif_fw_hwmod = {
-	.name		= "emif_fw",
-	.class		= &am33xx_emif_fw_hwmod_class,
-	.clkdm_name	= "l4fw_clkdm",
-	.main_clk	= "l4fw_gclk",
-	.flags		= (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET),
-	.prcm		= {
-		.omap4	= {
-			.clkctrl_offs	= AM33XX_CM_PER_EMIF_FW_CLKCTRL_OFFSET,
-			.modulemode	= MODULEMODE_SWCTRL,
-		},
-	},
-};
-
-/*
  * 'emif' class
  * instance(s): emif
  */
@@ -70,18 +47,12 @@ static struct omap_hwmod_class am33xx_emif_hwmod_class = {
 	.sysc		= &am33xx_emif_sysc,
 };
 
-static struct omap_hwmod_irq_info am33xx_emif_irqs[] = {
-	{ .name = "ddrerr0", .irq = 101 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
 /* emif */
 static struct omap_hwmod am33xx_emif_hwmod = {
 	.name		= "emif",
 	.class		= &am33xx_emif_hwmod_class,
 	.clkdm_name	= "l3_clkdm",
 	.flags		= (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET),
-	.mpu_irqs	= am33xx_emif_irqs,
 	.main_clk	= "dpll_ddr_m2_div2_ck",
 	.prcm		= {
 		.omap4	= {
@@ -99,19 +70,11 @@ static struct omap_hwmod_class am33xx_l3_hwmod_class = {
 	.name		= "l3",
 };
 
-/* l3_main (l3_fast) */
-static struct omap_hwmod_irq_info am33xx_l3_main_irqs[] = {
-	{ .name = "l3debug", .irq = 9 + OMAP_INTC_START, },
-	{ .name = "l3appint", .irq = 10 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
 static struct omap_hwmod am33xx_l3_main_hwmod = {
 	.name		= "l3_main",
 	.class		= &am33xx_l3_hwmod_class,
 	.clkdm_name	= "l3_clkdm",
 	.flags		= (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET),
-	.mpu_irqs	= am33xx_l3_main_irqs,
 	.main_clk	= "l3_gclk",
 	.prcm		= {
 		.omap4	= {
@@ -196,20 +159,6 @@ static struct omap_hwmod am33xx_l4_wkup_hwmod = {
 	},
 };
 
-/* l4_fw */
-static struct omap_hwmod am33xx_l4_fw_hwmod = {
-	.name		= "l4_fw",
-	.class		= &am33xx_l4_hwmod_class,
-	.clkdm_name	= "l4fw_clkdm",
-	.flags		= (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET),
-	.prcm		= {
-		.omap4	= {
-			.clkctrl_offs	= AM33XX_CM_PER_L4FW_CLKCTRL_OFFSET,
-			.modulemode	= MODULEMODE_SWCTRL,
-		},
-	},
-};
-
 /*
  * 'mpu' class
  */
@@ -217,21 +166,11 @@ static struct omap_hwmod_class am33xx_mpu_hwmod_class = {
 	.name	= "mpu",
 };
 
-/* mpu */
-static struct omap_hwmod_irq_info am33xx_mpu_irqs[] = {
-	{ .name = "emuint", .irq = 0 + OMAP_INTC_START, },
-	{ .name = "commtx", .irq = 1 + OMAP_INTC_START, },
-	{ .name = "commrx", .irq = 2 + OMAP_INTC_START, },
-	{ .name = "bench", .irq = 3 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
 static struct omap_hwmod am33xx_mpu_hwmod = {
 	.name		= "mpu",
 	.class		= &am33xx_mpu_hwmod_class,
 	.clkdm_name	= "mpu_clkdm",
 	.flags		= (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET),
-	.mpu_irqs	= am33xx_mpu_irqs,
 	.main_clk	= "dpll_mpu_m2_ck",
 	.prcm		= {
 		.omap4	= {
@@ -253,11 +192,6 @@ static struct omap_hwmod_rst_info am33xx_wkup_m3_resets[] = {
 	{ .name = "wkup_m3", .rst_shift = 3, .st_shift = 5 },
 };
 
-static struct omap_hwmod_irq_info am33xx_wkup_m3_irqs[] = {
-	{ .name = "txev", .irq = 78 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
 /* wkup_m3  */
 static struct omap_hwmod am33xx_wkup_m3_hwmod = {
 	.name		= "wkup_m3",
@@ -265,7 +199,6 @@ static struct omap_hwmod am33xx_wkup_m3_hwmod = {
 	.clkdm_name	= "l4_wkup_aon_clkdm",
 	/* Keep hardreset asserted */
 	.flags		= HWMOD_INIT_NO_RESET | HWMOD_NO_IDLEST,
-	.mpu_irqs	= am33xx_wkup_m3_irqs,
 	.main_clk	= "dpll_core_m4_div2_ck",
 	.prcm		= {
 		.omap4	= {
@@ -291,25 +224,12 @@ static struct omap_hwmod_rst_info am33xx_pruss_resets[] = {
 	{ .name = "pruss", .rst_shift = 1 },
 };
 
-static struct omap_hwmod_irq_info am33xx_pruss_irqs[] = {
-	{ .name = "evtout0", .irq = 20 + OMAP_INTC_START, },
-	{ .name = "evtout1", .irq = 21 + OMAP_INTC_START, },
-	{ .name = "evtout2", .irq = 22 + OMAP_INTC_START, },
-	{ .name = "evtout3", .irq = 23 + OMAP_INTC_START, },
-	{ .name = "evtout4", .irq = 24 + OMAP_INTC_START, },
-	{ .name = "evtout5", .irq = 25 + OMAP_INTC_START, },
-	{ .name = "evtout6", .irq = 26 + OMAP_INTC_START, },
-	{ .name = "evtout7", .irq = 27 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
 /* pru-icss */
 /* Pseudo hwmod for reset control purpose only */
 static struct omap_hwmod am33xx_pruss_hwmod = {
 	.name		= "pruss",
 	.class		= &am33xx_pruss_hwmod_class,
 	.clkdm_name	= "pruss_ocp_clkdm",
-	.mpu_irqs	= am33xx_pruss_irqs,
 	.main_clk	= "pruss_ocp_gclk",
 	.prcm		= {
 		.omap4	= {
@@ -332,16 +252,10 @@ static struct omap_hwmod_rst_info am33xx_gfx_resets[] = {
 	{ .name = "gfx", .rst_shift = 0 },
 };
 
-static struct omap_hwmod_irq_info am33xx_gfx_irqs[] = {
-	{ .name = "gfxint", .irq = 37 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
 static struct omap_hwmod am33xx_gfx_hwmod = {
 	.name		= "gfx",
 	.class		= &am33xx_gfx_hwmod_class,
 	.clkdm_name	= "gfx_l3_clkdm",
-	.mpu_irqs	= am33xx_gfx_irqs,
 	.main_clk	= "gfx_fck_div_ck",
 	.prcm		= {
 		.omap4	= {
@@ -387,16 +301,10 @@ static struct omap_hwmod_class am33xx_adc_tsc_hwmod_class = {
 	.sysc		= &am33xx_adc_tsc_sysc,
 };
 
-static struct omap_hwmod_irq_info am33xx_adc_tsc_irqs[] = {
-	{ .irq = 16 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
 static struct omap_hwmod am33xx_adc_tsc_hwmod = {
 	.name		= "adc_tsc",
 	.class		= &am33xx_adc_tsc_hwmod_class,
 	.clkdm_name	= "l4_wkup_clkdm",
-	.mpu_irqs	= am33xx_adc_tsc_irqs,
 	.main_clk	= "adc_tsc_fck",
 	.prcm		= {
 		.omap4	= {
@@ -515,23 +423,10 @@ static struct omap_hwmod_class am33xx_aes0_hwmod_class = {
 	.sysc		= &am33xx_aes0_sysc,
 };
 
-static struct omap_hwmod_irq_info am33xx_aes0_irqs[] = {
-	{ .irq = 103 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
-static struct omap_hwmod_dma_info am33xx_aes0_edma_reqs[] = {
-	{ .name = "tx", .dma_req = 6, },
-	{ .name = "rx", .dma_req = 5, },
-	{ .dma_req = -1 }
-};
-
 static struct omap_hwmod am33xx_aes0_hwmod = {
 	.name		= "aes",
 	.class		= &am33xx_aes0_hwmod_class,
 	.clkdm_name	= "l3_clkdm",
-	.mpu_irqs	= am33xx_aes0_irqs,
-	.sdma_reqs	= am33xx_aes0_edma_reqs,
 	.main_clk	= "aes0_fck",
 	.prcm		= {
 		.omap4	= {
@@ -554,22 +449,10 @@ static struct omap_hwmod_class am33xx_sha0_hwmod_class = {
 	.sysc		= &am33xx_sha0_sysc,
 };
 
-static struct omap_hwmod_irq_info am33xx_sha0_irqs[] = {
-	{ .irq = 109 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
-static struct omap_hwmod_dma_info am33xx_sha0_edma_reqs[] = {
-	{ .name = "rx", .dma_req = 36, },
-	{ .dma_req = -1 }
-};
-
 static struct omap_hwmod am33xx_sha0_hwmod = {
 	.name		= "sham",
 	.class		= &am33xx_sha0_hwmod_class,
 	.clkdm_name	= "l3_clkdm",
-	.mpu_irqs	= am33xx_sha0_irqs,
-	.sdma_reqs	= am33xx_sha0_edma_reqs,
 	.main_clk	= "l3_gclk",
 	.prcm		= {
 		.omap4	= {
@@ -604,16 +487,10 @@ static struct omap_hwmod_class am33xx_smartreflex_hwmod_class = {
 };
 
 /* smartreflex0 */
-static struct omap_hwmod_irq_info am33xx_smartreflex0_irqs[] = {
-	{ .irq = 120 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
 static struct omap_hwmod am33xx_smartreflex0_hwmod = {
 	.name		= "smartreflex0",
 	.class		= &am33xx_smartreflex_hwmod_class,
 	.clkdm_name	= "l4_wkup_clkdm",
-	.mpu_irqs	= am33xx_smartreflex0_irqs,
 	.main_clk	= "smartreflex0_fck",
 	.prcm		= {
 		.omap4	= {
@@ -624,16 +501,10 @@ static struct omap_hwmod am33xx_smartreflex0_hwmod = {
 };
 
 /* smartreflex1 */
-static struct omap_hwmod_irq_info am33xx_smartreflex1_irqs[] = {
-	{ .irq = 121 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
 static struct omap_hwmod am33xx_smartreflex1_hwmod = {
 	.name		= "smartreflex1",
 	.class		= &am33xx_smartreflex_hwmod_class,
 	.clkdm_name	= "l4_wkup_clkdm",
-	.mpu_irqs	= am33xx_smartreflex1_irqs,
 	.main_clk	= "smartreflex1_fck",
 	.prcm		= {
 		.omap4	= {
@@ -650,17 +521,11 @@ static struct omap_hwmod_class am33xx_control_hwmod_class = {
 	.name		= "control",
 };
 
-static struct omap_hwmod_irq_info am33xx_control_irqs[] = {
-	{ .irq = 8 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
 static struct omap_hwmod am33xx_control_hwmod = {
 	.name		= "control",
 	.class		= &am33xx_control_hwmod_class,
 	.clkdm_name	= "l4_wkup_clkdm",
 	.flags		= (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET),
-	.mpu_irqs	= am33xx_control_irqs,
 	.main_clk	= "dpll_core_m4_div2_ck",
 	.prcm		= {
 		.omap4	= {
@@ -690,20 +555,11 @@ static struct omap_hwmod_class am33xx_cpgmac0_hwmod_class = {
 	.sysc		= &am33xx_cpgmac_sysc,
 };
 
-static struct omap_hwmod_irq_info am33xx_cpgmac0_irqs[] = {
-	{ .name = "c0_rx_thresh_pend", .irq = 40 + OMAP_INTC_START, },
-	{ .name = "c0_rx_pend", .irq = 41 + OMAP_INTC_START, },
-	{ .name = "c0_tx_pend", .irq = 42 + OMAP_INTC_START, },
-	{ .name = "c0_misc_pend", .irq = 43 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
 static struct omap_hwmod am33xx_cpgmac0_hwmod = {
 	.name		= "cpgmac0",
 	.class		= &am33xx_cpgmac0_hwmod_class,
 	.clkdm_name	= "cpsw_125mhz_clkdm",
 	.flags		= (HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY),
-	.mpu_irqs	= am33xx_cpgmac0_irqs,
 	.main_clk	= "cpsw_125mhz_gclk",
 	.prcm		= {
 		.omap4	= {
@@ -735,17 +591,10 @@ static struct omap_hwmod_class am33xx_dcan_hwmod_class = {
 };
 
 /* dcan0 */
-static struct omap_hwmod_irq_info am33xx_dcan0_irqs[] = {
-	{ .name = "d_can_ms", .irq = 52 + OMAP_INTC_START, },
-	{ .name = "d_can_mo", .irq = 53 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
 static struct omap_hwmod am33xx_dcan0_hwmod = {
 	.name		= "d_can0",
 	.class		= &am33xx_dcan_hwmod_class,
 	.clkdm_name	= "l4ls_clkdm",
-	.mpu_irqs	= am33xx_dcan0_irqs,
 	.main_clk	= "dcan0_fck",
 	.prcm		= {
 		.omap4	= {
@@ -756,16 +605,10 @@ static struct omap_hwmod am33xx_dcan0_hwmod = {
 };
 
 /* dcan1 */
-static struct omap_hwmod_irq_info am33xx_dcan1_irqs[] = {
-	{ .name = "d_can_ms", .irq = 55 + OMAP_INTC_START, },
-	{ .name = "d_can_mo", .irq = 56 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
 static struct omap_hwmod am33xx_dcan1_hwmod = {
 	.name		= "d_can1",
 	.class		= &am33xx_dcan_hwmod_class,
 	.clkdm_name	= "l4ls_clkdm",
-	.mpu_irqs	= am33xx_dcan1_irqs,
 	.main_clk	= "dcan1_fck",
 	.prcm		= {
 		.omap4	= {
@@ -792,16 +635,10 @@ static struct omap_hwmod_class am33xx_elm_hwmod_class = {
 	.sysc		= &am33xx_elm_sysc,
 };
 
-static struct omap_hwmod_irq_info am33xx_elm_irqs[] = {
-	{ .irq = 4 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
 static struct omap_hwmod am33xx_elm_hwmod = {
 	.name		= "elm",
 	.class		= &am33xx_elm_hwmod_class,
 	.clkdm_name	= "l4ls_clkdm",
-	.mpu_irqs	= am33xx_elm_irqs,
 	.main_clk	= "l4ls_gclk",
 	.prcm		= {
 		.omap4	= {
@@ -854,45 +691,26 @@ static struct omap_hwmod am33xx_epwmss0_hwmod = {
 };
 
 /* ecap0 */
-static struct omap_hwmod_irq_info am33xx_ecap0_irqs[] = {
-	{ .irq = 31 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
 static struct omap_hwmod am33xx_ecap0_hwmod = {
 	.name		= "ecap0",
 	.class		= &am33xx_ecap_hwmod_class,
 	.clkdm_name	= "l4ls_clkdm",
-	.mpu_irqs	= am33xx_ecap0_irqs,
 	.main_clk	= "l4ls_gclk",
 };
 
 /* eqep0 */
-static struct omap_hwmod_irq_info am33xx_eqep0_irqs[] = {
-	{ .irq = 79 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
 static struct omap_hwmod am33xx_eqep0_hwmod = {
 	.name		= "eqep0",
 	.class		= &am33xx_eqep_hwmod_class,
 	.clkdm_name	= "l4ls_clkdm",
-	.mpu_irqs	= am33xx_eqep0_irqs,
 	.main_clk	= "l4ls_gclk",
 };
 
 /* ehrpwm0 */
-static struct omap_hwmod_irq_info am33xx_ehrpwm0_irqs[] = {
-	{ .name = "int", .irq = 86 + OMAP_INTC_START, },
-	{ .name = "tzint", .irq = 58 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
 static struct omap_hwmod am33xx_ehrpwm0_hwmod = {
 	.name		= "ehrpwm0",
 	.class		= &am33xx_ehrpwm_hwmod_class,
 	.clkdm_name	= "l4ls_clkdm",
-	.mpu_irqs	= am33xx_ehrpwm0_irqs,
 	.main_clk	= "l4ls_gclk",
 };
 
@@ -911,45 +729,26 @@ static struct omap_hwmod am33xx_epwmss1_hwmod = {
 };
 
 /* ecap1 */
-static struct omap_hwmod_irq_info am33xx_ecap1_irqs[] = {
-	{ .irq = 47 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
 static struct omap_hwmod am33xx_ecap1_hwmod = {
 	.name		= "ecap1",
 	.class		= &am33xx_ecap_hwmod_class,
 	.clkdm_name	= "l4ls_clkdm",
-	.mpu_irqs	= am33xx_ecap1_irqs,
 	.main_clk	= "l4ls_gclk",
 };
 
 /* eqep1 */
-static struct omap_hwmod_irq_info am33xx_eqep1_irqs[] = {
-	{ .irq = 88 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
 static struct omap_hwmod am33xx_eqep1_hwmod = {
 	.name		= "eqep1",
 	.class		= &am33xx_eqep_hwmod_class,
 	.clkdm_name	= "l4ls_clkdm",
-	.mpu_irqs	= am33xx_eqep1_irqs,
 	.main_clk	= "l4ls_gclk",
 };
 
 /* ehrpwm1 */
-static struct omap_hwmod_irq_info am33xx_ehrpwm1_irqs[] = {
-	{ .name = "int", .irq = 87 + OMAP_INTC_START, },
-	{ .name = "tzint", .irq = 59 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
 static struct omap_hwmod am33xx_ehrpwm1_hwmod = {
 	.name		= "ehrpwm1",
 	.class		= &am33xx_ehrpwm_hwmod_class,
 	.clkdm_name	= "l4ls_clkdm",
-	.mpu_irqs	= am33xx_ehrpwm1_irqs,
 	.main_clk	= "l4ls_gclk",
 };
 
@@ -968,45 +767,26 @@ static struct omap_hwmod am33xx_epwmss2_hwmod = {
 };
 
 /* ecap2 */
-static struct omap_hwmod_irq_info am33xx_ecap2_irqs[] = {
-	{ .irq = 61 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
 static struct omap_hwmod am33xx_ecap2_hwmod = {
 	.name		= "ecap2",
 	.class		= &am33xx_ecap_hwmod_class,
 	.clkdm_name	= "l4ls_clkdm",
-	.mpu_irqs	= am33xx_ecap2_irqs,
 	.main_clk	= "l4ls_gclk",
 };
 
 /* eqep2 */
-static struct omap_hwmod_irq_info am33xx_eqep2_irqs[] = {
-	{ .irq = 89 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
 static struct omap_hwmod am33xx_eqep2_hwmod = {
 	.name		= "eqep2",
 	.class		= &am33xx_eqep_hwmod_class,
 	.clkdm_name	= "l4ls_clkdm",
-	.mpu_irqs	= am33xx_eqep2_irqs,
 	.main_clk	= "l4ls_gclk",
 };
 
 /* ehrpwm2 */
-static struct omap_hwmod_irq_info am33xx_ehrpwm2_irqs[] = {
-	{ .name = "int", .irq = 39 + OMAP_INTC_START, },
-	{ .name = "tzint", .irq = 60 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
 static struct omap_hwmod am33xx_ehrpwm2_hwmod = {
 	.name		= "ehrpwm2",
 	.class		= &am33xx_ehrpwm_hwmod_class,
 	.clkdm_name	= "l4ls_clkdm",
-	.mpu_irqs	= am33xx_ehrpwm2_irqs,
 	.main_clk	= "l4ls_gclk",
 };
 
@@ -1041,17 +821,11 @@ static struct omap_hwmod_opt_clk gpio0_opt_clks[] = {
 	{ .role = "dbclk", .clk = "gpio0_dbclk" },
 };
 
-static struct omap_hwmod_irq_info am33xx_gpio0_irqs[] = {
-	{ .irq = 96 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
 static struct omap_hwmod am33xx_gpio0_hwmod = {
 	.name		= "gpio1",
 	.class		= &am33xx_gpio_hwmod_class,
 	.clkdm_name	= "l4_wkup_clkdm",
 	.flags		= HWMOD_CONTROL_OPT_CLKS_IN_RESET,
-	.mpu_irqs	= am33xx_gpio0_irqs,
 	.main_clk	= "dpll_core_m4_div2_ck",
 	.prcm		= {
 		.omap4	= {
@@ -1065,11 +839,6 @@ static struct omap_hwmod am33xx_gpio0_hwmod = {
 };
 
 /* gpio1 */
-static struct omap_hwmod_irq_info am33xx_gpio1_irqs[] = {
-	{ .irq = 98 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
 static struct omap_hwmod_opt_clk gpio1_opt_clks[] = {
 	{ .role = "dbclk", .clk = "gpio1_dbclk" },
 };
@@ -1079,7 +848,6 @@ static struct omap_hwmod am33xx_gpio1_hwmod = {
 	.class		= &am33xx_gpio_hwmod_class,
 	.clkdm_name	= "l4ls_clkdm",
 	.flags		= HWMOD_CONTROL_OPT_CLKS_IN_RESET,
-	.mpu_irqs	= am33xx_gpio1_irqs,
 	.main_clk	= "l4ls_gclk",
 	.prcm		= {
 		.omap4	= {
@@ -1093,11 +861,6 @@ static struct omap_hwmod am33xx_gpio1_hwmod = {
 };
 
 /* gpio2 */
-static struct omap_hwmod_irq_info am33xx_gpio2_irqs[] = {
-	{ .irq = 32 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
 static struct omap_hwmod_opt_clk gpio2_opt_clks[] = {
 	{ .role = "dbclk", .clk = "gpio2_dbclk" },
 };
@@ -1107,7 +870,6 @@ static struct omap_hwmod am33xx_gpio2_hwmod = {
 	.class		= &am33xx_gpio_hwmod_class,
 	.clkdm_name	= "l4ls_clkdm",
 	.flags		= HWMOD_CONTROL_OPT_CLKS_IN_RESET,
-	.mpu_irqs	= am33xx_gpio2_irqs,
 	.main_clk	= "l4ls_gclk",
 	.prcm		= {
 		.omap4	= {
@@ -1121,11 +883,6 @@ static struct omap_hwmod am33xx_gpio2_hwmod = {
 };
 
 /* gpio3 */
-static struct omap_hwmod_irq_info am33xx_gpio3_irqs[] = {
-	{ .irq = 62 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
 static struct omap_hwmod_opt_clk gpio3_opt_clks[] = {
 	{ .role = "dbclk", .clk = "gpio3_dbclk" },
 };
@@ -1135,7 +892,6 @@ static struct omap_hwmod am33xx_gpio3_hwmod = {
 	.class		= &am33xx_gpio_hwmod_class,
 	.clkdm_name	= "l4ls_clkdm",
 	.flags		= HWMOD_CONTROL_OPT_CLKS_IN_RESET,
-	.mpu_irqs	= am33xx_gpio3_irqs,
 	.main_clk	= "l4ls_gclk",
 	.prcm		= {
 		.omap4	= {
@@ -1164,17 +920,11 @@ static struct omap_hwmod_class am33xx_gpmc_hwmod_class = {
 	.sysc		= &gpmc_sysc,
 };
 
-static struct omap_hwmod_irq_info am33xx_gpmc_irqs[] = {
-	{ .irq = 100 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
 static struct omap_hwmod am33xx_gpmc_hwmod = {
 	.name		= "gpmc",
 	.class		= &am33xx_gpmc_hwmod_class,
 	.clkdm_name	= "l3s_clkdm",
 	.flags		= (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET),
-	.mpu_irqs	= am33xx_gpmc_irqs,
 	.main_clk	= "l3s_gclk",
 	.prcm		= {
 		.omap4	= {
@@ -1208,23 +958,10 @@ static struct omap_i2c_dev_attr i2c_dev_attr = {
 };
 
 /* i2c1 */
-static struct omap_hwmod_irq_info i2c1_mpu_irqs[] = {
-	{ .irq = 70 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
-static struct omap_hwmod_dma_info i2c1_edma_reqs[] = {
-	{ .name = "tx", .dma_req = 0, },
-	{ .name = "rx", .dma_req = 0, },
-	{ .dma_req = -1 }
-};
-
 static struct omap_hwmod am33xx_i2c1_hwmod = {
 	.name		= "i2c1",
 	.class		= &i2c_class,
 	.clkdm_name	= "l4_wkup_clkdm",
-	.mpu_irqs	= i2c1_mpu_irqs,
-	.sdma_reqs	= i2c1_edma_reqs,
 	.flags		= HWMOD_16BIT_REG | HWMOD_SET_DEFAULT_CLOCKACT,
 	.main_clk	= "dpll_per_m2_div4_wkupdm_ck",
 	.prcm		= {
@@ -1237,23 +974,10 @@ static struct omap_hwmod am33xx_i2c1_hwmod = {
 };
 
 /* i2c1 */
-static struct omap_hwmod_irq_info i2c2_mpu_irqs[] = {
-	{ .irq = 71 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
-static struct omap_hwmod_dma_info i2c2_edma_reqs[] = {
-	{ .name = "tx", .dma_req = 0, },
-	{ .name = "rx", .dma_req = 0, },
-	{ .dma_req = -1 }
-};
-
 static struct omap_hwmod am33xx_i2c2_hwmod = {
 	.name		= "i2c2",
 	.class		= &i2c_class,
 	.clkdm_name	= "l4ls_clkdm",
-	.mpu_irqs	= i2c2_mpu_irqs,
-	.sdma_reqs	= i2c2_edma_reqs,
 	.flags		= HWMOD_16BIT_REG | HWMOD_SET_DEFAULT_CLOCKACT,
 	.main_clk	= "dpll_per_m2_div4_ck",
 	.prcm		= {
@@ -1266,23 +990,10 @@ static struct omap_hwmod am33xx_i2c2_hwmod = {
 };
 
 /* i2c3 */
-static struct omap_hwmod_dma_info i2c3_edma_reqs[] = {
-	{ .name = "tx", .dma_req = 0, },
-	{ .name = "rx", .dma_req = 0, },
-	{ .dma_req = -1 }
-};
-
-static struct omap_hwmod_irq_info i2c3_mpu_irqs[] = {
-	{ .irq = 30 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
 static struct omap_hwmod am33xx_i2c3_hwmod = {
 	.name		= "i2c3",
 	.class		= &i2c_class,
 	.clkdm_name	= "l4ls_clkdm",
-	.mpu_irqs	= i2c3_mpu_irqs,
-	.sdma_reqs	= i2c3_edma_reqs,
 	.flags		= HWMOD_16BIT_REG | HWMOD_SET_DEFAULT_CLOCKACT,
 	.main_clk	= "dpll_per_m2_div4_ck",
 	.prcm		= {
@@ -1309,16 +1020,10 @@ static struct omap_hwmod_class am33xx_lcdc_hwmod_class = {
 	.sysc		= &lcdc_sysc,
 };
 
-static struct omap_hwmod_irq_info am33xx_lcdc_irqs[] = {
-	{ .irq = 36 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
 static struct omap_hwmod am33xx_lcdc_hwmod = {
 	.name		= "lcdc",
 	.class		= &am33xx_lcdc_hwmod_class,
 	.clkdm_name	= "lcdc_clkdm",
-	.mpu_irqs	= am33xx_lcdc_irqs,
 	.flags		= HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY,
 	.main_clk	= "lcd_gclk",
 	.prcm		= {
@@ -1348,16 +1053,10 @@ static struct omap_hwmod_class am33xx_mailbox_hwmod_class = {
 	.sysc	= &am33xx_mailbox_sysc,
 };
 
-static struct omap_hwmod_irq_info am33xx_mailbox_irqs[] = {
-	{ .irq = 77 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
 static struct omap_hwmod am33xx_mailbox_hwmod = {
 	.name		= "mailbox",
 	.class		= &am33xx_mailbox_hwmod_class,
 	.clkdm_name	= "l4ls_clkdm",
-	.mpu_irqs	= am33xx_mailbox_irqs,
 	.main_clk	= "l4ls_gclk",
 	.prcm = {
 		.omap4 = {
@@ -1384,24 +1083,10 @@ static struct omap_hwmod_class am33xx_mcasp_hwmod_class = {
 };
 
 /* mcasp0 */
-static struct omap_hwmod_irq_info am33xx_mcasp0_irqs[] = {
-	{ .name = "ax", .irq = 80 + OMAP_INTC_START, },
-	{ .name = "ar", .irq = 81 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
-static struct omap_hwmod_dma_info am33xx_mcasp0_edma_reqs[] = {
-	{ .name = "tx", .dma_req = 8, },
-	{ .name = "rx", .dma_req = 9, },
-	{ .dma_req = -1 }
-};
-
 static struct omap_hwmod am33xx_mcasp0_hwmod = {
 	.name		= "mcasp0",
 	.class		= &am33xx_mcasp_hwmod_class,
 	.clkdm_name	= "l3s_clkdm",
-	.mpu_irqs	= am33xx_mcasp0_irqs,
-	.sdma_reqs	= am33xx_mcasp0_edma_reqs,
 	.main_clk	= "mcasp0_fck",
 	.prcm		= {
 		.omap4	= {
@@ -1412,24 +1097,10 @@ static struct omap_hwmod am33xx_mcasp0_hwmod = {
 };
 
 /* mcasp1 */
-static struct omap_hwmod_irq_info am33xx_mcasp1_irqs[] = {
-	{ .name = "ax", .irq = 82 + OMAP_INTC_START, },
-	{ .name = "ar", .irq = 83 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
-static struct omap_hwmod_dma_info am33xx_mcasp1_edma_reqs[] = {
-	{ .name = "tx", .dma_req = 10, },
-	{ .name = "rx", .dma_req = 11, },
-	{ .dma_req = -1 }
-};
-
 static struct omap_hwmod am33xx_mcasp1_hwmod = {
 	.name		= "mcasp1",
 	.class		= &am33xx_mcasp_hwmod_class,
 	.clkdm_name	= "l3s_clkdm",
-	.mpu_irqs	= am33xx_mcasp1_irqs,
-	.sdma_reqs	= am33xx_mcasp1_edma_reqs,
 	.main_clk	= "mcasp1_fck",
 	.prcm		= {
 		.omap4	= {
@@ -1457,17 +1128,6 @@ static struct omap_hwmod_class am33xx_mmc_hwmod_class = {
 };
 
 /* mmc0 */
-static struct omap_hwmod_irq_info am33xx_mmc0_irqs[] = {
-	{ .irq = 64 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
-static struct omap_hwmod_dma_info am33xx_mmc0_edma_reqs[] = {
-	{ .name = "tx", .dma_req = 24, },
-	{ .name = "rx", .dma_req = 25, },
-	{ .dma_req = -1 }
-};
-
 static struct omap_mmc_dev_attr am33xx_mmc0_dev_attr = {
 	.flags		= OMAP_HSMMC_SUPPORTS_DUAL_VOLT,
 };
@@ -1476,8 +1136,6 @@ static struct omap_hwmod am33xx_mmc0_hwmod = {
 	.name		= "mmc1",
 	.class		= &am33xx_mmc_hwmod_class,
 	.clkdm_name	= "l4ls_clkdm",
-	.mpu_irqs	= am33xx_mmc0_irqs,
-	.sdma_reqs	= am33xx_mmc0_edma_reqs,
 	.main_clk	= "mmc_clk",
 	.prcm		= {
 		.omap4	= {
@@ -1489,17 +1147,6 @@ static struct omap_hwmod am33xx_mmc0_hwmod = {
 };
 
 /* mmc1 */
-static struct omap_hwmod_irq_info am33xx_mmc1_irqs[] = {
-	{ .irq = 28 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
-static struct omap_hwmod_dma_info am33xx_mmc1_edma_reqs[] = {
-	{ .name = "tx", .dma_req = 2, },
-	{ .name = "rx", .dma_req = 3, },
-	{ .dma_req = -1 }
-};
-
 static struct omap_mmc_dev_attr am33xx_mmc1_dev_attr = {
 	.flags		= OMAP_HSMMC_SUPPORTS_DUAL_VOLT,
 };
@@ -1508,8 +1155,6 @@ static struct omap_hwmod am33xx_mmc1_hwmod = {
 	.name		= "mmc2",
 	.class		= &am33xx_mmc_hwmod_class,
 	.clkdm_name	= "l4ls_clkdm",
-	.mpu_irqs	= am33xx_mmc1_irqs,
-	.sdma_reqs	= am33xx_mmc1_edma_reqs,
 	.main_clk	= "mmc_clk",
 	.prcm		= {
 		.omap4	= {
@@ -1521,17 +1166,6 @@ static struct omap_hwmod am33xx_mmc1_hwmod = {
 };
 
 /* mmc2 */
-static struct omap_hwmod_irq_info am33xx_mmc2_irqs[] = {
-	{ .irq = 29 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
-static struct omap_hwmod_dma_info am33xx_mmc2_edma_reqs[] = {
-	{ .name = "tx", .dma_req = 64, },
-	{ .name = "rx", .dma_req = 65, },
-	{ .dma_req = -1 }
-};
-
 static struct omap_mmc_dev_attr am33xx_mmc2_dev_attr = {
 	.flags		= OMAP_HSMMC_SUPPORTS_DUAL_VOLT,
 };
@@ -1539,8 +1173,6 @@ static struct omap_hwmod am33xx_mmc2_hwmod = {
 	.name		= "mmc3",
 	.class		= &am33xx_mmc_hwmod_class,
 	.clkdm_name	= "l3s_clkdm",
-	.mpu_irqs	= am33xx_mmc2_irqs,
-	.sdma_reqs	= am33xx_mmc2_edma_reqs,
 	.main_clk	= "mmc_clk",
 	.prcm		= {
 		.omap4	= {
@@ -1569,17 +1201,10 @@ static struct omap_hwmod_class am33xx_rtc_hwmod_class = {
 	.sysc		= &am33xx_rtc_sysc,
 };
 
-static struct omap_hwmod_irq_info am33xx_rtc_irqs[] = {
-	{ .name = "rtcint", .irq = 75 + OMAP_INTC_START, },
-	{ .name = "rtcalarmint", .irq = 76 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
 static struct omap_hwmod am33xx_rtc_hwmod = {
 	.name		= "rtc",
 	.class		= &am33xx_rtc_hwmod_class,
 	.clkdm_name	= "l4_rtc_clkdm",
-	.mpu_irqs	= am33xx_rtc_irqs,
 	.main_clk	= "clk_32768_ck",
 	.prcm		= {
 		.omap4	= {
@@ -1608,19 +1233,6 @@ static struct omap_hwmod_class am33xx_spi_hwmod_class = {
 };
 
 /* spi0 */
-static struct omap_hwmod_irq_info am33xx_spi0_irqs[] = {
-	{ .irq = 65 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
-static struct omap_hwmod_dma_info am33xx_mcspi0_edma_reqs[] = {
-	{ .name = "rx0", .dma_req = 17 },
-	{ .name = "tx0", .dma_req = 16 },
-	{ .name = "rx1", .dma_req = 19 },
-	{ .name = "tx1", .dma_req = 18 },
-	{ .dma_req = -1 }
-};
-
 static struct omap2_mcspi_dev_attr mcspi_attrib = {
 	.num_chipselect	= 2,
 };
@@ -1628,8 +1240,6 @@ static struct omap_hwmod am33xx_spi0_hwmod = {
 	.name		= "spi0",
 	.class		= &am33xx_spi_hwmod_class,
 	.clkdm_name	= "l4ls_clkdm",
-	.mpu_irqs	= am33xx_spi0_irqs,
-	.sdma_reqs	= am33xx_mcspi0_edma_reqs,
 	.main_clk	= "dpll_per_m2_div4_ck",
 	.prcm		= {
 		.omap4	= {
@@ -1641,25 +1251,10 @@ static struct omap_hwmod am33xx_spi0_hwmod = {
 };
 
 /* spi1 */
-static struct omap_hwmod_irq_info am33xx_spi1_irqs[] = {
-	{ .irq = 125 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
-static struct omap_hwmod_dma_info am33xx_mcspi1_edma_reqs[] = {
-	{ .name = "rx0", .dma_req = 43 },
-	{ .name = "tx0", .dma_req = 42 },
-	{ .name = "rx1", .dma_req = 45 },
-	{ .name = "tx1", .dma_req = 44 },
-	{ .dma_req = -1 }
-};
-
 static struct omap_hwmod am33xx_spi1_hwmod = {
 	.name		= "spi1",
 	.class		= &am33xx_spi_hwmod_class,
 	.clkdm_name	= "l4ls_clkdm",
-	.mpu_irqs	= am33xx_spi1_irqs,
-	.sdma_reqs	= am33xx_mcspi1_edma_reqs,
 	.main_clk	= "dpll_per_m2_div4_ck",
 	.prcm		= {
 		.omap4	= {
@@ -1725,16 +1320,10 @@ static struct omap_hwmod_class am33xx_timer1ms_hwmod_class = {
 	.sysc		= &am33xx_timer1ms_sysc,
 };
 
-static struct omap_hwmod_irq_info am33xx_timer1_irqs[] = {
-	{ .irq = 67 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
 static struct omap_hwmod am33xx_timer1_hwmod = {
 	.name		= "timer1",
 	.class		= &am33xx_timer1ms_hwmod_class,
 	.clkdm_name	= "l4_wkup_clkdm",
-	.mpu_irqs	= am33xx_timer1_irqs,
 	.main_clk	= "timer1_fck",
 	.prcm		= {
 		.omap4	= {
@@ -1744,16 +1333,10 @@ static struct omap_hwmod am33xx_timer1_hwmod = {
 	},
 };
 
-static struct omap_hwmod_irq_info am33xx_timer2_irqs[] = {
-	{ .irq = 68 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
 static struct omap_hwmod am33xx_timer2_hwmod = {
 	.name		= "timer2",
 	.class		= &am33xx_timer_hwmod_class,
 	.clkdm_name	= "l4ls_clkdm",
-	.mpu_irqs	= am33xx_timer2_irqs,
 	.main_clk	= "timer2_fck",
 	.prcm		= {
 		.omap4	= {
@@ -1763,16 +1346,10 @@ static struct omap_hwmod am33xx_timer2_hwmod = {
 	},
 };
 
-static struct omap_hwmod_irq_info am33xx_timer3_irqs[] = {
-	{ .irq = 69 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
 static struct omap_hwmod am33xx_timer3_hwmod = {
 	.name		= "timer3",
 	.class		= &am33xx_timer_hwmod_class,
 	.clkdm_name	= "l4ls_clkdm",
-	.mpu_irqs	= am33xx_timer3_irqs,
 	.main_clk	= "timer3_fck",
 	.prcm		= {
 		.omap4	= {
@@ -1782,16 +1359,10 @@ static struct omap_hwmod am33xx_timer3_hwmod = {
 	},
 };
 
-static struct omap_hwmod_irq_info am33xx_timer4_irqs[] = {
-	{ .irq = 92 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
 static struct omap_hwmod am33xx_timer4_hwmod = {
 	.name		= "timer4",
 	.class		= &am33xx_timer_hwmod_class,
 	.clkdm_name	= "l4ls_clkdm",
-	.mpu_irqs	= am33xx_timer4_irqs,
 	.main_clk	= "timer4_fck",
 	.prcm		= {
 		.omap4	= {
@@ -1801,16 +1372,10 @@ static struct omap_hwmod am33xx_timer4_hwmod = {
 	},
 };
 
-static struct omap_hwmod_irq_info am33xx_timer5_irqs[] = {
-	{ .irq = 93 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
 static struct omap_hwmod am33xx_timer5_hwmod = {
 	.name		= "timer5",
 	.class		= &am33xx_timer_hwmod_class,
 	.clkdm_name	= "l4ls_clkdm",
-	.mpu_irqs	= am33xx_timer5_irqs,
 	.main_clk	= "timer5_fck",
 	.prcm		= {
 		.omap4	= {
@@ -1820,16 +1385,10 @@ static struct omap_hwmod am33xx_timer5_hwmod = {
 	},
 };
 
-static struct omap_hwmod_irq_info am33xx_timer6_irqs[] = {
-	{ .irq = 94 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
 static struct omap_hwmod am33xx_timer6_hwmod = {
 	.name		= "timer6",
 	.class		= &am33xx_timer_hwmod_class,
 	.clkdm_name	= "l4ls_clkdm",
-	.mpu_irqs	= am33xx_timer6_irqs,
 	.main_clk	= "timer6_fck",
 	.prcm		= {
 		.omap4	= {
@@ -1839,16 +1398,10 @@ static struct omap_hwmod am33xx_timer6_hwmod = {
 	},
 };
 
-static struct omap_hwmod_irq_info am33xx_timer7_irqs[] = {
-	{ .irq = 95 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
 static struct omap_hwmod am33xx_timer7_hwmod = {
 	.name		= "timer7",
 	.class		= &am33xx_timer_hwmod_class,
 	.clkdm_name	= "l4ls_clkdm",
-	.mpu_irqs	= am33xx_timer7_irqs,
 	.main_clk	= "timer7_fck",
 	.prcm		= {
 		.omap4	= {
@@ -1863,18 +1416,10 @@ static struct omap_hwmod_class am33xx_tpcc_hwmod_class = {
 	.name		= "tpcc",
 };
 
-static struct omap_hwmod_irq_info am33xx_tpcc_irqs[] = {
-	{ .name	= "edma0", .irq = 12 + OMAP_INTC_START, },
-	{ .name = "edma0_mperr", .irq = 13 + OMAP_INTC_START, },
-	{ .name	= "edma0_err", .irq = 14 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
 static struct omap_hwmod am33xx_tpcc_hwmod = {
 	.name		= "tpcc",
 	.class		= &am33xx_tpcc_hwmod_class,
 	.clkdm_name	= "l3_clkdm",
-	.mpu_irqs	= am33xx_tpcc_irqs,
 	.main_clk	= "l3_gclk",
 	.prcm		= {
 		.omap4	= {
@@ -1900,16 +1445,10 @@ static struct omap_hwmod_class am33xx_tptc_hwmod_class = {
 };
 
 /* tptc0 */
-static struct omap_hwmod_irq_info am33xx_tptc0_irqs[] = {
-	{ .irq = 112 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
 static struct omap_hwmod am33xx_tptc0_hwmod = {
 	.name		= "tptc0",
 	.class		= &am33xx_tptc_hwmod_class,
 	.clkdm_name	= "l3_clkdm",
-	.mpu_irqs	= am33xx_tptc0_irqs,
 	.flags		= HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY,
 	.main_clk	= "l3_gclk",
 	.prcm		= {
@@ -1921,16 +1460,10 @@ static struct omap_hwmod am33xx_tptc0_hwmod = {
 };
 
 /* tptc1 */
-static struct omap_hwmod_irq_info am33xx_tptc1_irqs[] = {
-	{ .irq = 113 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
 static struct omap_hwmod am33xx_tptc1_hwmod = {
 	.name		= "tptc1",
 	.class		= &am33xx_tptc_hwmod_class,
 	.clkdm_name	= "l3_clkdm",
-	.mpu_irqs	= am33xx_tptc1_irqs,
 	.flags		= (HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY),
 	.main_clk	= "l3_gclk",
 	.prcm		= {
@@ -1942,16 +1475,10 @@ static struct omap_hwmod am33xx_tptc1_hwmod = {
 };
 
 /* tptc2 */
-static struct omap_hwmod_irq_info am33xx_tptc2_irqs[] = {
-	{ .irq = 114 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
 static struct omap_hwmod am33xx_tptc2_hwmod = {
 	.name		= "tptc2",
 	.class		= &am33xx_tptc_hwmod_class,
 	.clkdm_name	= "l3_clkdm",
-	.mpu_irqs	= am33xx_tptc2_irqs,
 	.flags		= (HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY),
 	.main_clk	= "l3_gclk",
 	.prcm		= {
@@ -1980,23 +1507,10 @@ static struct omap_hwmod_class uart_class = {
 };
 
 /* uart1 */
-static struct omap_hwmod_dma_info uart1_edma_reqs[] = {
-	{ .name = "tx",	.dma_req = 26, },
-	{ .name = "rx",	.dma_req = 27, },
-	{ .dma_req = -1 }
-};
-
-static struct omap_hwmod_irq_info am33xx_uart1_irqs[] = {
-	{ .irq = 72 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
 static struct omap_hwmod am33xx_uart1_hwmod = {
 	.name		= "uart1",
 	.class		= &uart_class,
 	.clkdm_name	= "l4_wkup_clkdm",
-	.mpu_irqs	= am33xx_uart1_irqs,
-	.sdma_reqs	= uart1_edma_reqs,
 	.main_clk	= "dpll_per_m2_div4_wkupdm_ck",
 	.prcm		= {
 		.omap4	= {
@@ -2006,17 +1520,10 @@ static struct omap_hwmod am33xx_uart1_hwmod = {
 	},
 };
 
-static struct omap_hwmod_irq_info am33xx_uart2_irqs[] = {
-	{ .irq = 73 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
 static struct omap_hwmod am33xx_uart2_hwmod = {
 	.name		= "uart2",
 	.class		= &uart_class,
 	.clkdm_name	= "l4ls_clkdm",
-	.mpu_irqs	= am33xx_uart2_irqs,
-	.sdma_reqs	= uart1_edma_reqs,
 	.main_clk	= "dpll_per_m2_div4_ck",
 	.prcm		= {
 		.omap4	= {
@@ -2027,23 +1534,10 @@ static struct omap_hwmod am33xx_uart2_hwmod = {
 };
 
 /* uart3 */
-static struct omap_hwmod_dma_info uart3_edma_reqs[] = {
-	{ .name = "tx",	.dma_req = 30, },
-	{ .name = "rx",	.dma_req = 31, },
-	{ .dma_req = -1 }
-};
-
-static struct omap_hwmod_irq_info am33xx_uart3_irqs[] = {
-	{ .irq = 74 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
 static struct omap_hwmod am33xx_uart3_hwmod = {
 	.name		= "uart3",
 	.class		= &uart_class,
 	.clkdm_name	= "l4ls_clkdm",
-	.mpu_irqs	= am33xx_uart3_irqs,
-	.sdma_reqs	= uart3_edma_reqs,
 	.main_clk	= "dpll_per_m2_div4_ck",
 	.prcm		= {
 		.omap4	= {
@@ -2053,17 +1547,10 @@ static struct omap_hwmod am33xx_uart3_hwmod = {
 	},
 };
 
-static struct omap_hwmod_irq_info am33xx_uart4_irqs[] = {
-	{ .irq = 44 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
 static struct omap_hwmod am33xx_uart4_hwmod = {
 	.name		= "uart4",
 	.class		= &uart_class,
 	.clkdm_name	= "l4ls_clkdm",
-	.mpu_irqs	= am33xx_uart4_irqs,
-	.sdma_reqs	= uart1_edma_reqs,
 	.main_clk	= "dpll_per_m2_div4_ck",
 	.prcm		= {
 		.omap4	= {
@@ -2073,17 +1560,10 @@ static struct omap_hwmod am33xx_uart4_hwmod = {
 	},
 };
 
-static struct omap_hwmod_irq_info am33xx_uart5_irqs[] = {
-	{ .irq = 45 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
 static struct omap_hwmod am33xx_uart5_hwmod = {
 	.name		= "uart5",
 	.class		= &uart_class,
 	.clkdm_name	= "l4ls_clkdm",
-	.mpu_irqs	= am33xx_uart5_irqs,
-	.sdma_reqs	= uart1_edma_reqs,
 	.main_clk	= "dpll_per_m2_div4_ck",
 	.prcm		= {
 		.omap4	= {
@@ -2093,17 +1573,10 @@ static struct omap_hwmod am33xx_uart5_hwmod = {
 	},
 };
 
-static struct omap_hwmod_irq_info am33xx_uart6_irqs[] = {
-	{ .irq = 46 + OMAP_INTC_START, },
-	{ .irq = -1 },
-};
-
 static struct omap_hwmod am33xx_uart6_hwmod = {
 	.name		= "uart6",
 	.class		= &uart_class,
 	.clkdm_name	= "l4ls_clkdm",
-	.mpu_irqs	= am33xx_uart6_irqs,
-	.sdma_reqs	= uart1_edma_reqs,
 	.main_clk	= "dpll_per_m2_div4_ck",
 	.prcm		= {
 		.omap4	= {
@@ -2167,18 +1640,10 @@ static struct omap_hwmod_class am33xx_usbotg_class = {
 	.sysc		= &am33xx_usbhsotg_sysc,
 };
 
-static struct omap_hwmod_irq_info am33xx_usbss_mpu_irqs[] = {
-	{ .name = "usbss-irq", .irq = 17 + OMAP_INTC_START, },
-	{ .name = "musb0-irq", .irq = 18 + OMAP_INTC_START, },
-	{ .name = "musb1-irq", .irq = 19 + OMAP_INTC_START, },
-	{ .irq = -1, },
-};
-
 static struct omap_hwmod am33xx_usbss_hwmod = {
 	.name		= "usb_otg_hs",
 	.class		= &am33xx_usbotg_class,
 	.clkdm_name	= "l3s_clkdm",
-	.mpu_irqs	= am33xx_usbss_mpu_irqs,
 	.flags		= HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY,
 	.main_clk	= "usbotg_fck",
 	.prcm		= {
@@ -2194,14 +1659,6 @@ static struct omap_hwmod am33xx_usbss_hwmod = {
  * Interfaces
  */
 
-/* l4 fw -> emif fw */
-static struct omap_hwmod_ocp_if am33xx_l4_fw__emif_fw = {
-	.master		= &am33xx_l4_fw_hwmod,
-	.slave		= &am33xx_emif_fw_hwmod,
-	.clk		= "l4fw_gclk",
-	.user		= OCP_USER_MPU,
-};
-
 static struct omap_hwmod_addr_space am33xx_emif_addrs[] = {
 	{
 		.pa_start	= 0x4c000000,
@@ -2259,14 +1716,6 @@ static struct omap_hwmod_ocp_if am33xx_l3_s__l4_wkup = {
 	.user		= OCP_USER_MPU | OCP_USER_SDMA,
 };
 
-/* l3 s -> l4 fw */
-static struct omap_hwmod_ocp_if am33xx_l3_s__l4_fw = {
-	.master		= &am33xx_l3_s_hwmod,
-	.slave		= &am33xx_l4_fw_hwmod,
-	.clk		= "l3s_gclk",
-	.user		= OCP_USER_MPU | OCP_USER_SDMA,
-};
-
 /* l3 main -> l3 instr */
 static struct omap_hwmod_ocp_if am33xx_l3_main__l3_instr = {
 	.master		= &am33xx_l3_main_hwmod,
@@ -2316,261 +1765,114 @@ static struct omap_hwmod_ocp_if am33xx_gfx__l3_main = {
 };
 
 /* l4 wkup -> wkup m3 */
-static struct omap_hwmod_addr_space am33xx_wkup_m3_addrs[] = {
-	{
-		.name		= "umem",
-		.pa_start	= 0x44d00000,
-		.pa_end		= 0x44d00000 + SZ_16K - 1,
-		.flags		= ADDR_TYPE_RT
-	},
-	{
-		.name		= "dmem",
-		.pa_start	= 0x44d80000,
-		.pa_end		= 0x44d80000 + SZ_8K - 1,
-		.flags		= ADDR_TYPE_RT
-	},
-	{ }
-};
-
 static struct omap_hwmod_ocp_if am33xx_l4_wkup__wkup_m3 = {
 	.master		= &am33xx_l4_wkup_hwmod,
 	.slave		= &am33xx_wkup_m3_hwmod,
 	.clk		= "dpll_core_m4_div2_ck",
-	.addr		= am33xx_wkup_m3_addrs,
 	.user		= OCP_USER_MPU | OCP_USER_SDMA,
 };
 
 /* l4 hs -> pru-icss */
-static struct omap_hwmod_addr_space am33xx_pruss_addrs[] = {
-	{
-		.pa_start	= 0x4a300000,
-		.pa_end		= 0x4a300000 + SZ_512K - 1,
-		.flags		= ADDR_TYPE_RT
-	},
-	{ }
-};
-
 static struct omap_hwmod_ocp_if am33xx_l4_hs__pruss = {
 	.master		= &am33xx_l4_hs_hwmod,
 	.slave		= &am33xx_pruss_hwmod,
 	.clk		= "dpll_core_m4_ck",
-	.addr		= am33xx_pruss_addrs,
 	.user		= OCP_USER_MPU | OCP_USER_SDMA,
 };
 
 /* l3 main -> gfx */
-static struct omap_hwmod_addr_space am33xx_gfx_addrs[] = {
-	{
-		.pa_start	= 0x56000000,
-		.pa_end		= 0x56000000 + SZ_16M - 1,
-		.flags		= ADDR_TYPE_RT
-	},
-	{ }
-};
-
 static struct omap_hwmod_ocp_if am33xx_l3_main__gfx = {
 	.master		= &am33xx_l3_main_hwmod,
 	.slave		= &am33xx_gfx_hwmod,
 	.clk		= "dpll_core_m4_ck",
-	.addr		= am33xx_gfx_addrs,
 	.user		= OCP_USER_MPU | OCP_USER_SDMA,
 };
 
 /* l4 wkup -> smartreflex0 */
-static struct omap_hwmod_addr_space am33xx_smartreflex0_addrs[] = {
-	{
-		.pa_start	= 0x44e37000,
-		.pa_end		= 0x44e37000 + SZ_4K - 1,
-		.flags		= ADDR_TYPE_RT
-	},
-	{ }
-};
-
 static struct omap_hwmod_ocp_if am33xx_l4_wkup__smartreflex0 = {
 	.master		= &am33xx_l4_wkup_hwmod,
 	.slave		= &am33xx_smartreflex0_hwmod,
 	.clk		= "dpll_core_m4_div2_ck",
-	.addr		= am33xx_smartreflex0_addrs,
 	.user		= OCP_USER_MPU,
 };
 
 /* l4 wkup -> smartreflex1 */
-static struct omap_hwmod_addr_space am33xx_smartreflex1_addrs[] = {
-	{
-		.pa_start	= 0x44e39000,
-		.pa_end		= 0x44e39000 + SZ_4K - 1,
-		.flags		= ADDR_TYPE_RT
-	},
-	{ }
-};
-
 static struct omap_hwmod_ocp_if am33xx_l4_wkup__smartreflex1 = {
 	.master		= &am33xx_l4_wkup_hwmod,
 	.slave		= &am33xx_smartreflex1_hwmod,
 	.clk		= "dpll_core_m4_div2_ck",
-	.addr		= am33xx_smartreflex1_addrs,
 	.user		= OCP_USER_MPU,
 };
 
 /* l4 wkup -> control */
-static struct omap_hwmod_addr_space am33xx_control_addrs[] = {
-	{
-		.pa_start	= 0x44e10000,
-		.pa_end		= 0x44e10000 + SZ_8K - 1,
-		.flags		= ADDR_TYPE_RT
-	},
-	{ }
-};
-
 static struct omap_hwmod_ocp_if am33xx_l4_wkup__control = {
 	.master		= &am33xx_l4_wkup_hwmod,
 	.slave		= &am33xx_control_hwmod,
 	.clk		= "dpll_core_m4_div2_ck",
-	.addr		= am33xx_control_addrs,
 	.user		= OCP_USER_MPU,
 };
 
 /* l4 wkup -> rtc */
-static struct omap_hwmod_addr_space am33xx_rtc_addrs[] = {
-	{
-		.pa_start	= 0x44e3e000,
-		.pa_end		= 0x44e3e000 + SZ_4K - 1,
-		.flags		= ADDR_TYPE_RT
-	},
-	{ }
-};
-
 static struct omap_hwmod_ocp_if am33xx_l4_wkup__rtc = {
 	.master		= &am33xx_l4_wkup_hwmod,
 	.slave		= &am33xx_rtc_hwmod,
 	.clk		= "clkdiv32k_ick",
-	.addr		= am33xx_rtc_addrs,
 	.user		= OCP_USER_MPU,
 };
 
 /* l4 per/ls -> DCAN0 */
-static struct omap_hwmod_addr_space am33xx_dcan0_addrs[] = {
-	{
-		.pa_start	= 0x481CC000,
-		.pa_end		= 0x481CC000 + SZ_4K - 1,
-		.flags		= ADDR_TYPE_RT
-	},
-	{ }
-};
-
 static struct omap_hwmod_ocp_if am33xx_l4_per__dcan0 = {
 	.master		= &am33xx_l4_ls_hwmod,
 	.slave		= &am33xx_dcan0_hwmod,
 	.clk		= "l4ls_gclk",
-	.addr		= am33xx_dcan0_addrs,
 	.user		= OCP_USER_MPU | OCP_USER_SDMA,
 };
 
 /* l4 per/ls -> DCAN1 */
-static struct omap_hwmod_addr_space am33xx_dcan1_addrs[] = {
-	{
-		.pa_start	= 0x481D0000,
-		.pa_end		= 0x481D0000 + SZ_4K - 1,
-		.flags		= ADDR_TYPE_RT
-	},
-	{ }
-};
-
 static struct omap_hwmod_ocp_if am33xx_l4_per__dcan1 = {
 	.master		= &am33xx_l4_ls_hwmod,
 	.slave		= &am33xx_dcan1_hwmod,
 	.clk		= "l4ls_gclk",
-	.addr		= am33xx_dcan1_addrs,
 	.user		= OCP_USER_MPU | OCP_USER_SDMA,
 };
 
 /* l4 per/ls -> GPIO2 */
-static struct omap_hwmod_addr_space am33xx_gpio1_addrs[] = {
-	{
-		.pa_start	= 0x4804C000,
-		.pa_end		= 0x4804C000 + SZ_4K - 1,
-		.flags		= ADDR_TYPE_RT,
-	},
-	{ }
-};
-
 static struct omap_hwmod_ocp_if am33xx_l4_per__gpio1 = {
 	.master		= &am33xx_l4_ls_hwmod,
 	.slave		= &am33xx_gpio1_hwmod,
 	.clk		= "l4ls_gclk",
-	.addr		= am33xx_gpio1_addrs,
 	.user		= OCP_USER_MPU | OCP_USER_SDMA,
 };
 
 /* l4 per/ls -> gpio3 */
-static struct omap_hwmod_addr_space am33xx_gpio2_addrs[] = {
-	{
-		.pa_start	= 0x481AC000,
-		.pa_end		= 0x481AC000 + SZ_4K - 1,
-		.flags		= ADDR_TYPE_RT,
-	},
-	{ }
-};
-
 static struct omap_hwmod_ocp_if am33xx_l4_per__gpio2 = {
 	.master		= &am33xx_l4_ls_hwmod,
 	.slave		= &am33xx_gpio2_hwmod,
 	.clk		= "l4ls_gclk",
-	.addr		= am33xx_gpio2_addrs,
 	.user		= OCP_USER_MPU | OCP_USER_SDMA,
 };
 
 /* l4 per/ls -> gpio4 */
-static struct omap_hwmod_addr_space am33xx_gpio3_addrs[] = {
-	{
-		.pa_start	= 0x481AE000,
-		.pa_end		= 0x481AE000 + SZ_4K - 1,
-		.flags		= ADDR_TYPE_RT,
-	},
-	{ }
-};
-
 static struct omap_hwmod_ocp_if am33xx_l4_per__gpio3 = {
 	.master		= &am33xx_l4_ls_hwmod,
 	.slave		= &am33xx_gpio3_hwmod,
 	.clk		= "l4ls_gclk",
-	.addr		= am33xx_gpio3_addrs,
 	.user		= OCP_USER_MPU | OCP_USER_SDMA,
 };
 
 /* L4 WKUP -> I2C1 */
-static struct omap_hwmod_addr_space am33xx_i2c1_addr_space[] = {
-	{
-		.pa_start	= 0x44E0B000,
-		.pa_end		= 0x44E0B000 + SZ_4K - 1,
-		.flags		= ADDR_TYPE_RT,
-	},
-	{ }
-};
-
 static struct omap_hwmod_ocp_if am33xx_l4_wkup__i2c1 = {
 	.master		= &am33xx_l4_wkup_hwmod,
 	.slave		= &am33xx_i2c1_hwmod,
 	.clk		= "dpll_core_m4_div2_ck",
-	.addr		= am33xx_i2c1_addr_space,
 	.user		= OCP_USER_MPU,
 };
 
 /* L4 WKUP -> GPIO1 */
-static struct omap_hwmod_addr_space am33xx_gpio0_addrs[] = {
-	{
-		.pa_start	= 0x44E07000,
-		.pa_end		= 0x44E07000 + SZ_4K - 1,
-		.flags		= ADDR_TYPE_RT,
-	},
-	{ }
-};
-
 static struct omap_hwmod_ocp_if am33xx_l4_wkup__gpio0 = {
 	.master		= &am33xx_l4_wkup_hwmod,
 	.slave		= &am33xx_gpio0_hwmod,
 	.clk		= "dpll_core_m4_div2_ck",
-	.addr		= am33xx_gpio0_addrs,
 	.user		= OCP_USER_MPU | OCP_USER_SDMA,
 };
 
@@ -2592,41 +1894,16 @@ static struct omap_hwmod_ocp_if am33xx_l4_wkup__adc_tsc = {
 	.user		= OCP_USER_MPU,
 };
 
-static struct omap_hwmod_addr_space am33xx_cpgmac0_addr_space[] = {
-	/* cpsw ss */
-	{
-		.pa_start	= 0x4a100000,
-		.pa_end		= 0x4a100000 + SZ_2K - 1,
-	},
-	/* cpsw wr */
-	{
-		.pa_start	= 0x4a101200,
-		.pa_end		= 0x4a101200 + SZ_256 - 1,
-		.flags		= ADDR_TYPE_RT,
-	},
-	{ }
-};
-
 static struct omap_hwmod_ocp_if am33xx_l4_hs__cpgmac0 = {
 	.master		= &am33xx_l4_hs_hwmod,
 	.slave		= &am33xx_cpgmac0_hwmod,
 	.clk		= "cpsw_125mhz_gclk",
-	.addr		= am33xx_cpgmac0_addr_space,
 	.user		= OCP_USER_MPU,
 };
 
-static struct omap_hwmod_addr_space am33xx_mdio_addr_space[] = {
-	{
-		.pa_start	= 0x4A101000,
-		.pa_end		= 0x4A101000 + SZ_256 - 1,
-	},
-	{ }
-};
-
 static struct omap_hwmod_ocp_if am33xx_cpgmac0__mdio = {
 	.master		= &am33xx_cpgmac0_hwmod,
 	.slave		= &am33xx_mdio_hwmod,
-	.addr		= am33xx_mdio_addr_space,
 	.user		= OCP_USER_MPU,
 };
 
@@ -2664,51 +1941,24 @@ static struct omap_hwmod_ocp_if am33xx_l4_ls__epwmss0 = {
 	.user		= OCP_USER_MPU,
 };
 
-static struct omap_hwmod_addr_space am33xx_ecap0_addr_space[] = {
-	{
-		.pa_start	= 0x48300100,
-		.pa_end		= 0x48300100 + SZ_128 - 1,
-	},
-	{ }
-};
-
 static struct omap_hwmod_ocp_if am33xx_epwmss0__ecap0 = {
 	.master		= &am33xx_epwmss0_hwmod,
 	.slave		= &am33xx_ecap0_hwmod,
 	.clk		= "l4ls_gclk",
-	.addr		= am33xx_ecap0_addr_space,
 	.user		= OCP_USER_MPU,
 };
 
-static struct omap_hwmod_addr_space am33xx_eqep0_addr_space[] = {
-	{
-		.pa_start	= 0x48300180,
-		.pa_end		= 0x48300180 + SZ_128 - 1,
-	},
-	{ }
-};
-
 static struct omap_hwmod_ocp_if am33xx_epwmss0__eqep0 = {
 	.master		= &am33xx_epwmss0_hwmod,
 	.slave		= &am33xx_eqep0_hwmod,
 	.clk		= "l4ls_gclk",
-	.addr		= am33xx_eqep0_addr_space,
 	.user		= OCP_USER_MPU,
 };
 
-static struct omap_hwmod_addr_space am33xx_ehrpwm0_addr_space[] = {
-	{
-		.pa_start	= 0x48300200,
-		.pa_end		= 0x48300200 + SZ_128 - 1,
-	},
-	{ }
-};
-
 static struct omap_hwmod_ocp_if am33xx_epwmss0__ehrpwm0 = {
 	.master		= &am33xx_epwmss0_hwmod,
 	.slave		= &am33xx_ehrpwm0_hwmod,
 	.clk		= "l4ls_gclk",
-	.addr		= am33xx_ehrpwm0_addr_space,
 	.user		= OCP_USER_MPU,
 };
 
@@ -2730,51 +1980,24 @@ static struct omap_hwmod_ocp_if am33xx_l4_ls__epwmss1 = {
 	.user		= OCP_USER_MPU,
 };
 
-static struct omap_hwmod_addr_space am33xx_ecap1_addr_space[] = {
-	{
-		.pa_start	= 0x48302100,
-		.pa_end		= 0x48302100 + SZ_128 - 1,
-	},
-	{ }
-};
-
 static struct omap_hwmod_ocp_if am33xx_epwmss1__ecap1 = {
 	.master		= &am33xx_epwmss1_hwmod,
 	.slave		= &am33xx_ecap1_hwmod,
 	.clk		= "l4ls_gclk",
-	.addr		= am33xx_ecap1_addr_space,
 	.user		= OCP_USER_MPU,
 };
 
-static struct omap_hwmod_addr_space am33xx_eqep1_addr_space[] = {
-	{
-		.pa_start	= 0x48302180,
-		.pa_end		= 0x48302180 + SZ_128 - 1,
-	},
-	{ }
-};
-
 static struct omap_hwmod_ocp_if am33xx_epwmss1__eqep1 = {
 	.master		= &am33xx_epwmss1_hwmod,
 	.slave		= &am33xx_eqep1_hwmod,
 	.clk		= "l4ls_gclk",
-	.addr		= am33xx_eqep1_addr_space,
 	.user		= OCP_USER_MPU,
 };
 
-static struct omap_hwmod_addr_space am33xx_ehrpwm1_addr_space[] = {
-	{
-		.pa_start	= 0x48302200,
-		.pa_end		= 0x48302200 + SZ_128 - 1,
-	},
-	{ }
-};
-
 static struct omap_hwmod_ocp_if am33xx_epwmss1__ehrpwm1 = {
 	.master		= &am33xx_epwmss1_hwmod,
 	.slave		= &am33xx_ehrpwm1_hwmod,
 	.clk		= "l4ls_gclk",
-	.addr		= am33xx_ehrpwm1_addr_space,
 	.user		= OCP_USER_MPU,
 };
 
@@ -2795,51 +2018,24 @@ static struct omap_hwmod_ocp_if am33xx_l4_ls__epwmss2 = {
 	.user		= OCP_USER_MPU,
 };
 
-static struct omap_hwmod_addr_space am33xx_ecap2_addr_space[] = {
-	{
-		.pa_start	= 0x48304100,
-		.pa_end		= 0x48304100 + SZ_128 - 1,
-	},
-	{ }
-};
-
 static struct omap_hwmod_ocp_if am33xx_epwmss2__ecap2 = {
 	.master		= &am33xx_epwmss2_hwmod,
 	.slave		= &am33xx_ecap2_hwmod,
 	.clk		= "l4ls_gclk",
-	.addr		= am33xx_ecap2_addr_space,
 	.user		= OCP_USER_MPU,
 };
 
-static struct omap_hwmod_addr_space am33xx_eqep2_addr_space[] = {
-	{
-		.pa_start	= 0x48304180,
-		.pa_end		= 0x48304180 + SZ_128 - 1,
-	},
-	{ }
-};
-
 static struct omap_hwmod_ocp_if am33xx_epwmss2__eqep2 = {
 	.master		= &am33xx_epwmss2_hwmod,
 	.slave		= &am33xx_eqep2_hwmod,
 	.clk		= "l4ls_gclk",
-	.addr		= am33xx_eqep2_addr_space,
 	.user		= OCP_USER_MPU,
 };
 
-static struct omap_hwmod_addr_space am33xx_ehrpwm2_addr_space[] = {
-	{
-		.pa_start	= 0x48304200,
-		.pa_end		= 0x48304200 + SZ_128 - 1,
-	},
-	{ }
-};
-
 static struct omap_hwmod_ocp_if am33xx_epwmss2__ehrpwm2 = {
 	.master		= &am33xx_epwmss2_hwmod,
 	.slave		= &am33xx_ehrpwm2_hwmod,
 	.clk		= "l4ls_gclk",
-	.addr		= am33xx_ehrpwm2_addr_space,
 	.user		= OCP_USER_MPU,
 };
 
@@ -2862,37 +2058,17 @@ static struct omap_hwmod_ocp_if am33xx_l3_s__gpmc = {
 };
 
 /* i2c2 */
-static struct omap_hwmod_addr_space am33xx_i2c2_addr_space[] = {
-	{
-		.pa_start	= 0x4802A000,
-		.pa_end		= 0x4802A000 + SZ_4K - 1,
-		.flags		= ADDR_TYPE_RT,
-	},
-	{ }
-};
-
 static struct omap_hwmod_ocp_if am33xx_l4_per__i2c2 = {
 	.master		= &am33xx_l4_ls_hwmod,
 	.slave		= &am33xx_i2c2_hwmod,
 	.clk		= "l4ls_gclk",
-	.addr		= am33xx_i2c2_addr_space,
 	.user		= OCP_USER_MPU,
 };
 
-static struct omap_hwmod_addr_space am33xx_i2c3_addr_space[] = {
-	{
-		.pa_start	= 0x4819C000,
-		.pa_end		= 0x4819C000 + SZ_4K - 1,
-		.flags		= ADDR_TYPE_RT
-	},
-	{ }
-};
-
 static struct omap_hwmod_ocp_if am33xx_l4_per__i2c3 = {
 	.master		= &am33xx_l4_ls_hwmod,
 	.slave		= &am33xx_i2c3_hwmod,
 	.clk		= "l4ls_gclk",
-	.addr		= am33xx_i2c3_addr_space,
 	.user		= OCP_USER_MPU,
 };
 
@@ -2932,20 +2108,10 @@ static struct omap_hwmod_ocp_if am33xx_l4_per__mailbox = {
 };
 
 /* l4 ls -> spinlock */
-static struct omap_hwmod_addr_space am33xx_spinlock_addrs[] = {
-	{
-		.pa_start	= 0x480Ca000,
-		.pa_end		= 0x480Ca000 + SZ_4K - 1,
-		.flags		= ADDR_TYPE_RT
-	},
-	{ }
-};
-
 static struct omap_hwmod_ocp_if am33xx_l4_ls__spinlock = {
 	.master		= &am33xx_l4_ls_hwmod,
 	.slave		= &am33xx_spinlock_hwmod,
 	.clk		= "l4ls_gclk",
-	.addr		= am33xx_spinlock_addrs,
 	.user		= OCP_USER_MPU,
 };
 
@@ -2967,24 +2133,6 @@ static struct omap_hwmod_ocp_if am33xx_l4_ls__mcasp0 = {
 	.user		= OCP_USER_MPU,
 };
 
-/* l3 s -> mcasp0 data */
-static struct omap_hwmod_addr_space am33xx_mcasp0_data_addr_space[] = {
-	{
-		.pa_start	= 0x46000000,
-		.pa_end		= 0x46000000 + SZ_4M - 1,
-		.flags		= ADDR_TYPE_RT
-	},
-	{ }
-};
-
-static struct omap_hwmod_ocp_if am33xx_l3_s__mcasp0_data = {
-	.master		= &am33xx_l3_s_hwmod,
-	.slave		= &am33xx_mcasp0_hwmod,
-	.clk		= "l3s_gclk",
-	.addr		= am33xx_mcasp0_data_addr_space,
-	.user		= OCP_USER_SDMA,
-};
-
 /* l4 ls -> mcasp1 */
 static struct omap_hwmod_addr_space am33xx_mcasp1_addr_space[] = {
 	{
@@ -3003,24 +2151,6 @@ static struct omap_hwmod_ocp_if am33xx_l4_ls__mcasp1 = {
 	.user		= OCP_USER_MPU,
 };
 
-/* l3 s -> mcasp1 data */
-static struct omap_hwmod_addr_space am33xx_mcasp1_data_addr_space[] = {
-	{
-		.pa_start	= 0x46400000,
-		.pa_end		= 0x46400000 + SZ_4M - 1,
-		.flags		= ADDR_TYPE_RT
-	},
-	{ }
-};
-
-static struct omap_hwmod_ocp_if am33xx_l3_s__mcasp1_data = {
-	.master		= &am33xx_l3_s_hwmod,
-	.slave		= &am33xx_mcasp1_hwmod,
-	.clk		= "l3s_gclk",
-	.addr		= am33xx_mcasp1_data_addr_space,
-	.user		= OCP_USER_SDMA,
-};
-
 /* l4 ls -> mmc0 */
 static struct omap_hwmod_addr_space am33xx_mmc0_addr_space[] = {
 	{
@@ -3076,182 +2206,82 @@ static struct omap_hwmod_ocp_if am33xx_l3_s__mmc2 = {
 };
 
 /* l4 ls -> mcspi0 */
-static struct omap_hwmod_addr_space am33xx_mcspi0_addr_space[] = {
-	{
-		.pa_start	= 0x48030000,
-		.pa_end		= 0x48030000 + SZ_1K - 1,
-		.flags		= ADDR_TYPE_RT,
-	},
-	{ }
-};
-
 static struct omap_hwmod_ocp_if am33xx_l4_ls__mcspi0 = {
 	.master		= &am33xx_l4_ls_hwmod,
 	.slave		= &am33xx_spi0_hwmod,
 	.clk		= "l4ls_gclk",
-	.addr		= am33xx_mcspi0_addr_space,
 	.user		= OCP_USER_MPU,
 };
 
 /* l4 ls -> mcspi1 */
-static struct omap_hwmod_addr_space am33xx_mcspi1_addr_space[] = {
-	{
-		.pa_start	= 0x481A0000,
-		.pa_end		= 0x481A0000 + SZ_1K - 1,
-		.flags		= ADDR_TYPE_RT,
-	},
-	{ }
-};
-
 static struct omap_hwmod_ocp_if am33xx_l4_ls__mcspi1 = {
 	.master		= &am33xx_l4_ls_hwmod,
 	.slave		= &am33xx_spi1_hwmod,
 	.clk		= "l4ls_gclk",
-	.addr		= am33xx_mcspi1_addr_space,
 	.user		= OCP_USER_MPU,
 };
 
 /* l4 wkup -> timer1 */
-static struct omap_hwmod_addr_space am33xx_timer1_addr_space[] = {
-	{
-		.pa_start	= 0x44E31000,
-		.pa_end		= 0x44E31000 + SZ_1K - 1,
-		.flags		= ADDR_TYPE_RT
-	},
-	{ }
-};
-
 static struct omap_hwmod_ocp_if am33xx_l4_wkup__timer1 = {
 	.master		= &am33xx_l4_wkup_hwmod,
 	.slave		= &am33xx_timer1_hwmod,
 	.clk		= "dpll_core_m4_div2_ck",
-	.addr		= am33xx_timer1_addr_space,
 	.user		= OCP_USER_MPU,
 };
 
 /* l4 per -> timer2 */
-static struct omap_hwmod_addr_space am33xx_timer2_addr_space[] = {
-	{
-		.pa_start	= 0x48040000,
-		.pa_end		= 0x48040000 + SZ_1K - 1,
-		.flags		= ADDR_TYPE_RT
-	},
-	{ }
-};
-
 static struct omap_hwmod_ocp_if am33xx_l4_ls__timer2 = {
 	.master		= &am33xx_l4_ls_hwmod,
 	.slave		= &am33xx_timer2_hwmod,
 	.clk		= "l4ls_gclk",
-	.addr		= am33xx_timer2_addr_space,
 	.user		= OCP_USER_MPU,
 };
 
 /* l4 per -> timer3 */
-static struct omap_hwmod_addr_space am33xx_timer3_addr_space[] = {
-	{
-		.pa_start	= 0x48042000,
-		.pa_end		= 0x48042000 + SZ_1K - 1,
-		.flags		= ADDR_TYPE_RT
-	},
-	{ }
-};
-
 static struct omap_hwmod_ocp_if am33xx_l4_ls__timer3 = {
 	.master		= &am33xx_l4_ls_hwmod,
 	.slave		= &am33xx_timer3_hwmod,
 	.clk		= "l4ls_gclk",
-	.addr		= am33xx_timer3_addr_space,
 	.user		= OCP_USER_MPU,
 };
 
 /* l4 per -> timer4 */
-static struct omap_hwmod_addr_space am33xx_timer4_addr_space[] = {
-	{
-		.pa_start	= 0x48044000,
-		.pa_end		= 0x48044000 + SZ_1K - 1,
-		.flags		= ADDR_TYPE_RT
-	},
-	{ }
-};
-
 static struct omap_hwmod_ocp_if am33xx_l4_ls__timer4 = {
 	.master		= &am33xx_l4_ls_hwmod,
 	.slave		= &am33xx_timer4_hwmod,
 	.clk		= "l4ls_gclk",
-	.addr		= am33xx_timer4_addr_space,
 	.user		= OCP_USER_MPU,
 };
 
 /* l4 per -> timer5 */
-static struct omap_hwmod_addr_space am33xx_timer5_addr_space[] = {
-	{
-		.pa_start	= 0x48046000,
-		.pa_end		= 0x48046000 + SZ_1K - 1,
-		.flags		= ADDR_TYPE_RT
-	},
-	{ }
-};
-
 static struct omap_hwmod_ocp_if am33xx_l4_ls__timer5 = {
 	.master		= &am33xx_l4_ls_hwmod,
 	.slave		= &am33xx_timer5_hwmod,
 	.clk		= "l4ls_gclk",
-	.addr		= am33xx_timer5_addr_space,
 	.user		= OCP_USER_MPU,
 };
 
 /* l4 per -> timer6 */
-static struct omap_hwmod_addr_space am33xx_timer6_addr_space[] = {
-	{
-		.pa_start	= 0x48048000,
-		.pa_end		= 0x48048000 + SZ_1K - 1,
-		.flags		= ADDR_TYPE_RT
-	},
-	{ }
-};
-
 static struct omap_hwmod_ocp_if am33xx_l4_ls__timer6 = {
 	.master		= &am33xx_l4_ls_hwmod,
 	.slave		= &am33xx_timer6_hwmod,
 	.clk		= "l4ls_gclk",
-	.addr		= am33xx_timer6_addr_space,
 	.user		= OCP_USER_MPU,
 };
 
 /* l4 per -> timer7 */
-static struct omap_hwmod_addr_space am33xx_timer7_addr_space[] = {
-	{
-		.pa_start	= 0x4804A000,
-		.pa_end		= 0x4804A000 + SZ_1K - 1,
-		.flags		= ADDR_TYPE_RT
-	},
-	{ }
-};
-
 static struct omap_hwmod_ocp_if am33xx_l4_ls__timer7 = {
 	.master		= &am33xx_l4_ls_hwmod,
 	.slave		= &am33xx_timer7_hwmod,
 	.clk		= "l4ls_gclk",
-	.addr		= am33xx_timer7_addr_space,
 	.user		= OCP_USER_MPU,
 };
 
 /* l3 main -> tpcc */
-static struct omap_hwmod_addr_space am33xx_tpcc_addr_space[] = {
-	{
-		.pa_start	= 0x49000000,
-		.pa_end		= 0x49000000 + SZ_32K - 1,
-		.flags		= ADDR_TYPE_RT
-	},
-	{ }
-};
-
 static struct omap_hwmod_ocp_if am33xx_l3_main__tpcc = {
 	.master		= &am33xx_l3_main_hwmod,
 	.slave		= &am33xx_tpcc_hwmod,
 	.clk		= "l3_gclk",
-	.addr		= am33xx_tpcc_addr_space,
 	.user		= OCP_USER_MPU,
 };
 
@@ -3310,160 +2340,67 @@ static struct omap_hwmod_ocp_if am33xx_l3_main__tptc2 = {
 };
 
 /* l4 wkup -> uart1 */
-static struct omap_hwmod_addr_space am33xx_uart1_addr_space[] = {
-	{
-		.pa_start	= 0x44E09000,
-		.pa_end		= 0x44E09000 + SZ_8K - 1,
-		.flags		= ADDR_TYPE_RT,
-	},
-	{ }
-};
-
 static struct omap_hwmod_ocp_if am33xx_l4_wkup__uart1 = {
 	.master		= &am33xx_l4_wkup_hwmod,
 	.slave		= &am33xx_uart1_hwmod,
 	.clk		= "dpll_core_m4_div2_ck",
-	.addr		= am33xx_uart1_addr_space,
 	.user		= OCP_USER_MPU,
 };
 
 /* l4 ls -> uart2 */
-static struct omap_hwmod_addr_space am33xx_uart2_addr_space[] = {
-	{
-		.pa_start	= 0x48022000,
-		.pa_end		= 0x48022000 + SZ_8K - 1,
-		.flags		= ADDR_TYPE_RT,
-	},
-	{ }
-};
-
 static struct omap_hwmod_ocp_if am33xx_l4_ls__uart2 = {
 	.master		= &am33xx_l4_ls_hwmod,
 	.slave		= &am33xx_uart2_hwmod,
 	.clk		= "l4ls_gclk",
-	.addr		= am33xx_uart2_addr_space,
 	.user		= OCP_USER_MPU,
 };
 
 /* l4 ls -> uart3 */
-static struct omap_hwmod_addr_space am33xx_uart3_addr_space[] = {
-	{
-		.pa_start	= 0x48024000,
-		.pa_end		= 0x48024000 + SZ_8K - 1,
-		.flags		= ADDR_TYPE_RT,
-	},
-	{ }
-};
-
 static struct omap_hwmod_ocp_if am33xx_l4_ls__uart3 = {
 	.master		= &am33xx_l4_ls_hwmod,
 	.slave		= &am33xx_uart3_hwmod,
 	.clk		= "l4ls_gclk",
-	.addr		= am33xx_uart3_addr_space,
 	.user		= OCP_USER_MPU,
 };
 
 /* l4 ls -> uart4 */
-static struct omap_hwmod_addr_space am33xx_uart4_addr_space[] = {
-	{
-		.pa_start	= 0x481A6000,
-		.pa_end		= 0x481A6000 + SZ_8K - 1,
-		.flags		= ADDR_TYPE_RT,
-	},
-	{ }
-};
-
 static struct omap_hwmod_ocp_if am33xx_l4_ls__uart4 = {
 	.master		= &am33xx_l4_ls_hwmod,
 	.slave		= &am33xx_uart4_hwmod,
 	.clk		= "l4ls_gclk",
-	.addr		= am33xx_uart4_addr_space,
 	.user		= OCP_USER_MPU,
 };
 
 /* l4 ls -> uart5 */
-static struct omap_hwmod_addr_space am33xx_uart5_addr_space[] = {
-	{
-		.pa_start	= 0x481A8000,
-		.pa_end		= 0x481A8000 + SZ_8K - 1,
-		.flags		= ADDR_TYPE_RT,
-	},
-	{ }
-};
-
 static struct omap_hwmod_ocp_if am33xx_l4_ls__uart5 = {
 	.master		= &am33xx_l4_ls_hwmod,
 	.slave		= &am33xx_uart5_hwmod,
 	.clk		= "l4ls_gclk",
-	.addr		= am33xx_uart5_addr_space,
 	.user		= OCP_USER_MPU,
 };
 
 /* l4 ls -> uart6 */
-static struct omap_hwmod_addr_space am33xx_uart6_addr_space[] = {
-	{
-		.pa_start	= 0x481aa000,
-		.pa_end		= 0x481aa000 + SZ_8K - 1,
-		.flags		= ADDR_TYPE_RT,
-	},
-	{ }
-};
-
 static struct omap_hwmod_ocp_if am33xx_l4_ls__uart6 = {
 	.master		= &am33xx_l4_ls_hwmod,
 	.slave		= &am33xx_uart6_hwmod,
 	.clk		= "l4ls_gclk",
-	.addr		= am33xx_uart6_addr_space,
 	.user		= OCP_USER_MPU,
 };
 
 /* l4 wkup -> wd_timer1 */
-static struct omap_hwmod_addr_space am33xx_wd_timer1_addrs[] = {
-	{
-		.pa_start	= 0x44e35000,
-		.pa_end		= 0x44e35000 + SZ_4K - 1,
-		.flags		= ADDR_TYPE_RT
-	},
-	{ }
-};
-
 static struct omap_hwmod_ocp_if am33xx_l4_wkup__wd_timer1 = {
 	.master		= &am33xx_l4_wkup_hwmod,
 	.slave		= &am33xx_wd_timer1_hwmod,
 	.clk		= "dpll_core_m4_div2_ck",
-	.addr		= am33xx_wd_timer1_addrs,
 	.user		= OCP_USER_MPU,
 };
 
 /* usbss */
 /* l3 s -> USBSS interface */
-static struct omap_hwmod_addr_space am33xx_usbss_addr_space[] = {
-	{
-		.name		= "usbss",
-		.pa_start	= 0x47400000,
-		.pa_end		= 0x47400000 + SZ_4K - 1,
-		.flags		= ADDR_TYPE_RT
-	},
-	{
-		.name		= "musb0",
-		.pa_start	= 0x47401000,
-		.pa_end		= 0x47401000 + SZ_2K - 1,
-		.flags		= ADDR_TYPE_RT
-	},
-	{
-		.name		= "musb1",
-		.pa_start	= 0x47401800,
-		.pa_end		= 0x47401800 + SZ_2K - 1,
-		.flags		= ADDR_TYPE_RT
-	},
-	{ }
-};
-
 static struct omap_hwmod_ocp_if am33xx_l3_s__usbss = {
 	.master		= &am33xx_l3_s_hwmod,
 	.slave		= &am33xx_usbss_hwmod,
 	.clk		= "l3s_gclk",
-	.addr		= am33xx_usbss_addr_space,
 	.user		= OCP_USER_MPU,
 	.flags		= OCPIF_SWSUP_IDLE,
 };
@@ -3512,13 +2449,11 @@ static struct omap_hwmod_ocp_if am33xx_l3_main__aes0 = {
 };
 
 static struct omap_hwmod_ocp_if *am33xx_hwmod_ocp_ifs[] __initdata = {
-	&am33xx_l4_fw__emif_fw,
 	&am33xx_l3_main__emif,
 	&am33xx_mpu__l3_main,
 	&am33xx_mpu__prcm,
 	&am33xx_l3_s__l4_ls,
 	&am33xx_l3_s__l4_wkup,
-	&am33xx_l3_s__l4_fw,
 	&am33xx_l3_main__l4_hs,
 	&am33xx_l3_main__l3_s,
 	&am33xx_l3_main__l3_instr,
@@ -3548,9 +2483,7 @@ static struct omap_hwmod_ocp_if *am33xx_hwmod_ocp_ifs[] __initdata = {
 	&am33xx_l4_per__i2c3,
 	&am33xx_l4_per__mailbox,
 	&am33xx_l4_ls__mcasp0,
-	&am33xx_l3_s__mcasp0_data,
 	&am33xx_l4_ls__mcasp1,
-	&am33xx_l3_s__mcasp1_data,
 	&am33xx_l4_ls__mmc0,
 	&am33xx_l4_ls__mmc1,
 	&am33xx_l3_s__mmc2,
-- 
1.7.0.4


Thanks,
Vaibhav


From olof at lixom.net  Thu Apr 18 01:29:33 2013
From: olof at lixom.net (Olof Johansson)
Date: Wed, 17 Apr 2013 22:29:33 -0700
Subject: [GIT PULL 2/4] mvebu soc for v3.10
In-Reply-To: <20130415183605.GO28693@titan.lakedaemon.net>
References: <20130415183605.GO28693@titan.lakedaemon.net>
Message-ID: <20130418052933.GA12816@quad.lixom.net>

On Mon, Apr 15, 2013 at 02:36:05PM -0400, Jason Cooper wrote:
> 
> The following changes since commit 8bb9660418e05bb1845ac1a2428444d78e322cc7:
> 
>   Linux 3.9-rc4 (2013-03-23 16:52:44 -0700)
> 
> are available in the git repository at:
> 
>   git://git.infradead.org/users/jcooper/linux.git tags/soc_for_v3.10
> 
> for you to fetch changes up to da497f6fbaa190d34907ecc9dd85cfc62ba9f5a2:
> 
>   ARM: mvebu: Align the internal registers virtual base to support LPAE (2013-04-15 14:06:59 +0000)
> 
> ----------------------------------------------------------------
> mvebu soc changes for v3.10
> 
>  - use the mvebu-mbus driver
>  - prep for LPAE support
> 
> Depends:
>  - mvebu/cleanup (tags/cleanup_for_v3.10)
>  - mvebu/drivers (tags/drivers_for_v3.10)
> 
> ----------------------------------------------------------------
> Gregory CLEMENT (1):
>       ARM: mvebu: Limit the DMA zone when LPAE is selected
> 
> Jason Cooper (2):
>       Merge tag 'tags/cleanup_for_v3.10' into mvebu/soc
>       Merge tag 'tags/drivers_for_v3.10' into mvebu/soc
> 
> Lior Amsalem (1):
>       ARM: mvebu: Align the internal registers virtual base to support LPAE
> 
> Neil Greatorex (1):
>       bus: mvebu-mbus: Restore checking for coherency fabric hardware
> 
> Simon Guinot (1):
>       ARM: Orion: add dbg_show function to gpio-orion driver
> 
> Thomas Petazzoni (11):
>       arm: plat-orion: only build addr-map.c when needed
>       arm: plat-orion: use mv_mbus_dram_info() in PCIe code
>       arm: mach-orion5x: use mv_mbus_dram_info() in PCI code
>       bus: introduce an Marvell EBU MBus driver
>       bus: mvebu: fix mistake in PCIe window target attribute for Kirkwood
>       arm: mach-mvebu: convert to use mvebu-mbus driver
>       arm: mach-kirkwood: convert to use mvebu-mbus driver
>       arm: mach-dove: convert to use mvebu-mbus driver
>       arm: mach-orion5x: convert to use mvebu-mbus driver
>       arm: mach-mv78xx0: convert to use the mvebu-mbus driver
>       arm: plat-orion: remove addr-map code
> 
>  arch/arm/Kconfig                               |   4 +
>  arch/arm/boot/dts/armada-370-xp.dtsi           |   5 -
>  arch/arm/include/debug/mvebu.S                 |   2 +-
>  arch/arm/mach-dove/Makefile                    |   2 +-
>  arch/arm/mach-dove/addr-map.c                  | 125 ----
>  arch/arm/mach-dove/board-dt.c                  |   2 +-
>  arch/arm/mach-dove/common.c                    |  39 +-
>  arch/arm/mach-dove/common.h                    |   2 +-
>  arch/arm/mach-dove/include/mach/dove.h         |   5 +
>  arch/arm/mach-kirkwood/Makefile                |   2 +-
>  arch/arm/mach-kirkwood/addr-map.c              |  91 ---
>  arch/arm/mach-kirkwood/board-dt.c              |   2 +-
>  arch/arm/mach-kirkwood/common.c                |  38 +-
>  arch/arm/mach-kirkwood/common.h                |   2 +-
>  arch/arm/mach-kirkwood/include/mach/kirkwood.h |   7 +-
>  arch/arm/mach-kirkwood/pcie.c                  |   1 -
>  arch/arm/mach-mv78xx0/Makefile                 |   2 +-
>  arch/arm/mach-mv78xx0/addr-map.c               |  93 ---
>  arch/arm/mach-mv78xx0/common.c                 |  10 +-
>  arch/arm/mach-mv78xx0/include/mach/mv78xx0.h   |   9 +-
>  arch/arm/mach-mv78xx0/pcie.c                   |  21 +-
>  arch/arm/mach-mvebu/Kconfig                    |   2 +
>  arch/arm/mach-mvebu/Makefile                   |   2 +-
>  arch/arm/mach-mvebu/addr-map.c                 | 137 ----
>  arch/arm/mach-mvebu/armada-370-xp.c            |  18 +
>  arch/arm/mach-mvebu/armada-370-xp.h            |   8 +-
>  arch/arm/mach-mvebu/platsmp.c                  |   2 +
>  arch/arm/mach-orion5x/Makefile                 |   2 +-
>  arch/arm/mach-orion5x/addr-map.c               | 155 -----
>  arch/arm/mach-orion5x/board-dt.c               |   2 +-
>  arch/arm/mach-orion5x/common.c                 |  49 +-
>  arch/arm/mach-orion5x/common.h                 |  13 +-
>  arch/arm/mach-orion5x/d2net-setup.c            |   4 +-
>  arch/arm/mach-orion5x/db88f5281-setup.c        |  13 +-
>  arch/arm/mach-orion5x/dns323-setup.c           |   3 +-
>  arch/arm/mach-orion5x/edmini_v2-setup.c        |   4 +-
>  arch/arm/mach-orion5x/include/mach/orion5x.h   |   6 +-
>  arch/arm/mach-orion5x/kurobox_pro-setup.c      |   8 +-
>  arch/arm/mach-orion5x/ls-chl-setup.c           |   4 +-
>  arch/arm/mach-orion5x/ls_hgl-setup.c           |   4 +-
>  arch/arm/mach-orion5x/lsmini-setup.c           |   4 +-
>  arch/arm/mach-orion5x/mss2-setup.c             |   3 +-
>  arch/arm/mach-orion5x/mv2120-setup.c           |   3 +-
>  arch/arm/mach-orion5x/net2big-setup.c          |   4 +-
>  arch/arm/mach-orion5x/pci.c                    |  14 +-
>  arch/arm/mach-orion5x/rd88f5181l-fxo-setup.c   |   4 +-
>  arch/arm/mach-orion5x/rd88f5181l-ge-setup.c    |   4 +-
>  arch/arm/mach-orion5x/rd88f5182-setup.c        |   7 +-
>  arch/arm/mach-orion5x/terastation_pro2-setup.c |   4 +-
>  arch/arm/mach-orion5x/ts209-setup.c            |   4 +-
>  arch/arm/mach-orion5x/ts409-setup.c            |   4 +-
>  arch/arm/mach-orion5x/wnr854t-setup.c          |   4 +-
>  arch/arm/mach-orion5x/wrt350n-v2-setup.c       |   4 +-
>  arch/arm/plat-orion/Makefile                   |   2 -
>  arch/arm/plat-orion/addr-map.c                 | 178 -----
>  arch/arm/plat-orion/gpio.c                     |  59 ++
>  arch/arm/plat-orion/pcie.c                     |  10 +-
>  drivers/bus/Kconfig                            |   7 +
>  drivers/bus/Makefile                           |   1 +
>  drivers/bus/mvebu-mbus.c                       | 870 +++++++++++++++++++++++++
>  include/linux/mbus.h                           |  27 +-
>  61 files changed, 1234 insertions(+), 883 deletions(-)
>  delete mode 100644 arch/arm/mach-dove/addr-map.c
>  delete mode 100644 arch/arm/mach-kirkwood/addr-map.c
>  delete mode 100644 arch/arm/mach-mv78xx0/addr-map.c
>  delete mode 100644 arch/arm/mach-mvebu/addr-map.c
>  delete mode 100644 arch/arm/mach-orion5x/addr-map.c
>  delete mode 100644 arch/arm/plat-orion/addr-map.c
>  create mode 100644 drivers/bus/mvebu-mbus.c

This diffstat seems to contain some of the dependencies as well, not just
the new code in this branch. I know it can be awkward to generate this
correctly, but getting it right helps us sanity-check the pull request.

Easiest is probably to do a test merge at your side (first merge the
dependencies, then the new branch), then do a diff --stat -M HEAD~. It's
similar to how I generate the pull requests when we send code to Linus.


-Olof


From olof at lixom.net  Thu Apr 18 01:30:02 2013
From: olof at lixom.net (Olof Johansson)
Date: Wed, 17 Apr 2013 22:30:02 -0700
Subject: [GIT PULL V2 1/4] mvebu driver changes for v3.10
In-Reply-To: <20130416150416.GB28693@titan.lakedaemon.net>
References: <20130415182824.GN28693@titan.lakedaemon.net>
 <20130416150416.GB28693@titan.lakedaemon.net>
Message-ID: <20130418053002.GB12816@quad.lixom.net>

On Tue, Apr 16, 2013 at 11:04:16AM -0400, Jason Cooper wrote:
> 
> The following changes since commit 8bb9660418e05bb1845ac1a2428444d78e322cc7:
> 
>   Linux 3.9-rc4 (2013-03-23 16:52:44 -0700)
> 
> are available in the git repository at:
> 
>   git://git.infradead.org/users/jcooper/linux.git tags/drivers-3.10-2
> 
> for you to fetch changes up to ac7b07ec369324063e52c37b3fb0ad1a1814d879:
> 
>   clk: mvebu: add more PCIe clocks for Armada XP (2013-04-16 14:47:01 +0000)

Pulled, thanks.


-Olof


From olof at lixom.net  Thu Apr 18 01:30:19 2013
From: olof at lixom.net (Olof Johansson)
Date: Wed, 17 Apr 2013 22:30:19 -0700
Subject: [GIT PULL 2/4] mvebu soc for v3.10
In-Reply-To: <20130415183605.GO28693@titan.lakedaemon.net>
References: <20130415183605.GO28693@titan.lakedaemon.net>
Message-ID: <20130418053019.GC12816@quad.lixom.net>

On Mon, Apr 15, 2013 at 02:36:05PM -0400, Jason Cooper wrote:
> 
> The following changes since commit 8bb9660418e05bb1845ac1a2428444d78e322cc7:
> 
>   Linux 3.9-rc4 (2013-03-23 16:52:44 -0700)
> 
> are available in the git repository at:
> 
>   git://git.infradead.org/users/jcooper/linux.git tags/soc_for_v3.10
> 
> for you to fetch changes up to da497f6fbaa190d34907ecc9dd85cfc62ba9f5a2:
> 
>   ARM: mvebu: Align the internal registers virtual base to support LPAE (2013-04-15 14:06:59 +0000)


Pulled, thanks.


-Olof


From pranavkumar at linaro.org  Thu Apr 18 01:52:24 2013
From: pranavkumar at linaro.org (PranavkumarSawargaonkar)
Date: Thu, 18 Apr 2013 11:22:24 +0530
Subject: [RFC] arm64: Early printk support for virtio-mmio console devices.
Message-ID: <1366264344-28025-1-git-send-email-pranavkumar@linaro.org>

From: Pranavkumar Sawargaonkar <pranavkumar at linaro.org>

This patch implements early printk support for virtio-mmio console devices without using any hypercalls.

The current virtio early printk code in kernel expects that hypervisor will provide some mechanism generally a hypercall to support early printk. This patch does not break existing hypercall based early print support.

This implementation adds:
1. Early read-write register named early_rw in virtio console's config space.
2. Two host feature flags namely VIRTIO_CONSOLE_F_EARLY_READ and VIRTIO_CONSOLE_F_EARLY_WRITE for telling guest about early-read and early-write capability in console device.

Early write mechanism:
1. When a guest wants to out some character, it has to simply write the character to early_rw register in config space of virtio console device.

Early read mechanism:
1. When a guest wants to in some character, it has to simply read the early_rw register in config space of virtio console device. Lets say we get 32-bit value X.
2. If most significant bit of X is set (i.e. X & 0x80000000 == 0x80000000) then least significant 8 bits of X represents input charaacter else guest need to try again reading early_rw register.

Note: This patch only includes kernel side changes for early printk, the host/hypervisor side emulation of early_rw register is out of scope here.

Signed-off-by: Anup Patel <anup.patel at linaro.org>
---
 arch/arm64/kernel/early_printk.c    |   24 ++++++++++++++++++++++++
 include/uapi/linux/virtio_console.h |    4 ++++
 2 files changed, 28 insertions(+)

diff --git a/arch/arm64/kernel/early_printk.c b/arch/arm64/kernel/early_printk.c
index ac974f4..a82b5aa 100644
--- a/arch/arm64/kernel/early_printk.c
+++ b/arch/arm64/kernel/early_printk.c
@@ -25,6 +25,9 @@
 
 #include <linux/amba/serial.h>
 #include <linux/serial_reg.h>
+#include <linux/virtio_ids.h>
+#include <linux/virtio_mmio.h>
+#include <linux/virtio_console.h>
 
 static void __iomem *early_base;
 static void (*printch)(char ch);
@@ -53,6 +56,26 @@ static void smh_printch(char ch)
 }
 
 /*
+ * VIRTIO MMIO based debug console.
+ */
+static void virtio_console_early_printch(char ch)
+{
+	u32 tmp;
+	struct virtio_console_config *p = early_base + VIRTIO_MMIO_CONFIG;
+
+	tmp = readl_relaxed(early_base + VIRTIO_MMIO_DEVICE_ID);
+	if (tmp != VIRTIO_ID_CONSOLE) {
+		return;
+	}
+
+	tmp = readl_relaxed(early_base + VIRTIO_MMIO_HOST_FEATURES);
+	if (!(tmp & (1 << VIRTIO_CONSOLE_F_EARLY_WRITE))) {
+		return;
+	}
+	writeb_relaxed(ch, &p->early_rw);
+}
+
+/*
  * 8250/16550 (8-bit aligned registers) single character TX.
  */
 static void uart8250_8bit_printch(char ch)
@@ -82,6 +105,7 @@ static const struct earlycon_match earlycon_match[] __initconst = {
 	{ .name = "smh", .printch = smh_printch, },
 	{ .name = "uart8250-8bit", .printch = uart8250_8bit_printch, },
 	{ .name = "uart8250-32bit", .printch = uart8250_32bit_printch, },
+	{ .name = "virtio-console", .printch = virtio_console_early_printch, },
 	{}
 };
 
diff --git a/include/uapi/linux/virtio_console.h b/include/uapi/linux/virtio_console.h
index ee13ab6..1171cb4 100644
--- a/include/uapi/linux/virtio_console.h
+++ b/include/uapi/linux/virtio_console.h
@@ -38,6 +38,8 @@
 /* Feature bits */
 #define VIRTIO_CONSOLE_F_SIZE	0	/* Does host provide console size? */
 #define VIRTIO_CONSOLE_F_MULTIPORT 1	/* Does host provide multiple ports? */
+#define VIRTIO_CONSOLE_F_EARLY_READ 2	/* Does host support early read? */
+#define VIRTIO_CONSOLE_F_EARLY_WRITE 3	/* Does host support early write? */
 
 #define VIRTIO_CONSOLE_BAD_ID		(~(u32)0)
 
@@ -48,6 +50,8 @@ struct virtio_console_config {
 	__u16 rows;
 	/* max. number of ports this device can hold */
 	__u32 max_nr_ports;
+	/* early read/write register */
+	__u32 early_rw;
 } __attribute__((packed));
 
 /*
-- 
1.7.9.5



From s.hauer at pengutronix.de  Thu Apr 18 01:58:02 2013
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Thu, 18 Apr 2013 07:58:02 +0200
Subject: [PATCH] ARM: mach-imx6q: Remove code for setting up cko clock
In-Reply-To: <CAOMZO5AynVOfSq_duGrAkaUtwyx1XjGQQY4558b4GOoMqa7TiQ@mail.gmail.com>
References: <1366224182-29285-1-git-send-email-festevam@gmail.com>
 <20130417195744.GX1906@pengutronix.de>
 <CAOMZO5AynVOfSq_duGrAkaUtwyx1XjGQQY4558b4GOoMqa7TiQ@mail.gmail.com>
Message-ID: <20130418055802.GY1906@pengutronix.de>

On Wed, Apr 17, 2013 at 05:21:25PM -0300, Fabio Estevam wrote:
> Hi Sascha,
> 
> On Wed, Apr 17, 2013 at 4:57 PM, Sascha Hauer <s.hauer at pengutronix.de> wrote:
> > On Wed, Apr 17, 2013 at 03:43:02PM -0300, Fabio Estevam wrote:
> >> From: Fabio Estevam <fabio.estevam at freescale.com>
> >>
> >> Let the bootloader setup the cko clock that drives the audio codec.
> >>
> >
> > I really don't like such stuff. Where is documented what's expected from
> > the bootloader? Which versions of which bootloader do implement this?
> 
> As far as I know such documentation does not exist. It would be nice
> to have it, especially now that
> we are recently moving some ARM errata stuff out of the multi plaform kernel.

Yes, that's another thing that should be documented. Without even
documenting it we go into an area where things happen to work in certain
combinations and we won't have good answers when somebody asks on the
list why something doesn't work for him (other than: update your
bootloader and see if that helps)

> 
> I sent patches today for enabling CLKO for sabrelite in Barebox and U-boot.
> 
> > The code you remove is not particularly nice, but just removing it is no
> > solution to the problem.
> 
> Please let me know what is your preferred solution then.
> 
> There was some discussion here:
> https://patchwork.kernel.org/patch/2303011/
> 
> ,but I didn't see this come into any conclusion of what is the
> preferred way to handle this.

It may seemed like I bashed upon putting configuration data in the
devicetree. This wasn't really my intention, I more hoped that there
would be some more discussion about this topic.

I still think that it's a bad idea to just mix the configuration data
with the hardware description, because the hardware doesn't change, but
the confguration data is a matter of usecase and sometimes even personal
taste.
I also think that the devicetree format as such is a good format to
describe such (hardware specific) configuration data.

I'm perfectly fine with having configuration data in the devicetree, but
there should be some strict rules:

- configuration data should be in a separate source dts
- configuration data should be in a separate subtree (/chosen)
- configuration data should *not* be in the board dts files in the
  kernel.
- ideally it should be possible to distribute configuration data and
  hardware description separately. hardware description doesn't change
  (as long as we don't change the bindings of course), but configuration
  data often changes with the usecase or kernel version.

Particularly currently the dts files in the Kernel often enforce a
partition layout for mtd devices. Such things shouldn't happen.

> 
> >
> >> This simplifies a lot the code and when a new board needs to add audio support,
> >> it will not have to add all this amount of code again.
> >
> > It shouldn't be necessary to duplicate the code for each board.
> 
> Yes, some code could be factored out, but every time we need to add
> audio support for a new board we would need to keep polluting
> arch/arm/mach-imx/mach-imx6q.c with things like:
> 
> if (of_machine_is_compatible("fsl,imx6q-xxx"))
>     cko_setup()

We already have the necessary bindings to encode that the SGTL5000 clock
parent is the CLKO pin. That's hardware description and nobody would
object to that. That would only leave the problem of finding the correct
parent.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From olof at lixom.net  Thu Apr 18 02:25:39 2013
From: olof at lixom.net (Olof Johansson)
Date: Wed, 17 Apr 2013 23:25:39 -0700
Subject: [GIT PULL 4/4] mvebu dt for v3.10
In-Reply-To: <20130415185018.GR28693@titan.lakedaemon.net>
References: <20130415185018.GR28693@titan.lakedaemon.net>
Message-ID: <20130418062539.GD12816@quad.lixom.net>

On Mon, Apr 15, 2013 at 02:50:18PM -0400, Jason Cooper wrote:
> 
> The following changes since commit c3117edec5f92cce39f2d220c62f76675397af8d:
> 
>   Dove: Thermal: Add DT node and enable in defconfig (2013-03-12 11:33:22 +0000)
> 
> are available in the git repository at:
> 
>   git://git.infradead.org/users/jcooper/linux.git tags/dt-3.10-3
> 


Pulled, thanks.


-Olof


From olof at lixom.net  Thu Apr 18 02:30:30 2013
From: olof at lixom.net (Olof Johansson)
Date: Wed, 17 Apr 2013 23:30:30 -0700
Subject: [GIT PULL] mvebu dt (LPAE) for v3.10
In-Reply-To: <20130415190019.GS28693@titan.lakedaemon.net>
References: <20130415190019.GS28693@titan.lakedaemon.net>
Message-ID: <20130418063030.GE12816@quad.lixom.net>

On Mon, Apr 15, 2013 at 03:00:19PM -0400, Jason Cooper wrote:
> 
> The following changes since commit b757f17e9184b65428c48a281d82f9acb3e96f0e:
> 
>   Merge tag 'tags/soc_for_v3.10' into mvebu/dt (2013-04-15 14:55:23 +0000)
> 
> are available in the git repository at:
> 
> 
>   git://git.infradead.org/users/jcooper/linux.git tags/dt-3.10-4
> 
> for you to fetch changes up to 74898364e717c6bd939bb88d95049fc91d2b4950:
> 
>   ARM: dts: mvebu: Convert mvebu device tree files to 64 bits (2013-04-15 15:00:29 +0000)
> 
> ----------------------------------------------------------------
> mvebu dt for v3.10 round 4
> 
>  - mvebu LPAE 64bit dts file changes
> 
> Depends:
>  - mvebu/fixes (tags/mvebu_fixes_for_v3.9_round3)
>  - mvebu/soc (tags/soc_for_v3.10)

Pulled, thanks.


-Olof


From shawn.guo at linaro.org  Thu Apr 18 02:30:59 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Thu, 18 Apr 2013 14:30:59 +0800
Subject: [PATCH V2] ARM: i.MX5: Allow DT clock providers
In-Reply-To: <20130415080741.20173.70704.stgit@localhost>
References: <20130415080741.20173.70704.stgit@localhost>
Message-ID: <20130418063056.GA20566@S2101-09.ap.freescale.net>

On Mon, Apr 15, 2013 at 10:07:41AM +0200, Martin Fuzzey wrote:
> Currently clock providers defined in the DT are not registered
> on i.MX5 platforms since of_clk_init() is not called.
> 
> This is not a problem for the SOC's own clocks, which are registered
> in code,  but prevents the DT being used to define clocks for external
> hardware.
> 
> Fix this by calling of_clk_init() and actually using the DT to obtain
> the 4 SOC fixed clocks.
> These are already defined in the DT but were previously just used to
> manually obtain the rate.
> 
> Fall back to the old scheme for non DT platforms.
> 
> Signed-off-by: Martin Fuzzey <mfuzzey at parkeon.com>
> 
> ---
> Changelog:
> V2: Applied comments from Sashca Hauer:
> 	* Use kasprintf instead of scnprintf to avoid length limit
> 	* Avoid use of IS_ERR_OR_NULL
> ---
>  arch/arm/mach-imx/clk-imx51-imx53.c |   79 ++++++++++++++++++++---------------
>  1 files changed, 45 insertions(+), 34 deletions(-)
> 
> diff --git a/arch/arm/mach-imx/clk-imx51-imx53.c b/arch/arm/mach-imx/clk-imx51-imx53.c
> index 3228b4e..4b28cfc 100644
> --- a/arch/arm/mach-imx/clk-imx51-imx53.c
> +++ b/arch/arm/mach-imx/clk-imx51-imx53.c
> @@ -117,17 +117,56 @@ enum imx5_clks {
>  static struct clk *clk[clk_max];
>  static struct clk_onecell_data clk_data;
>  
> +
> +static struct clk * __init mx5_obtain_fixed_clock_from_dt(const char *name)
> +{
> +#ifdef CONFIG_OF

We have selected USE_OF at the sub-architecture level, so the ifdef
plays nothing here.

> +	struct of_phandle_args phandle = {0};
> +	struct clk *clk = ERR_PTR(-ENODEV);
> +	char *compatible;
> +
> +	compatible = kasprintf(GFP_KERNEL, "fsl,imx-%s", name);

What about finding the node by path as below?

	path = kasprintf(GFP_KERNEL, "/clocks/%s", name);
	phandle.np = of_find_node_by_path(path);

I have to admit that those imx custom compatibles for fixed-clock
shouldn't necessarily be there at all.  Let's stop spreading the use.

Shawn

> +	if (!compatible)
> +		return ERR_PTR(-ENOMEM);
> +
> +	phandle.np = of_find_compatible_node(NULL, NULL, compatible);
> +	kfree(compatible);
> +	if (phandle.np) {
> +		clk = of_clk_get_from_provider(&phandle);
> +		of_node_put(phandle.np);
> +	}
> +	return clk;
> +#else
> +	return ERR_PTR(-ENODEV);
> +#endif
> +}
> +
> +static struct clk * __init mx5_obtain_fixed_clock(
> +			const char *name, unsigned long rate)
> +{
> +	struct clk *clk;
> +
> +	clk = mx5_obtain_fixed_clock_from_dt(name);
> +	if (IS_ERR(clk))
> +		clk = imx_clk_fixed(name, rate);
> +	return clk;
> +}
> +
>  static void __init mx5_clocks_common_init(unsigned long rate_ckil,
>  		unsigned long rate_osc, unsigned long rate_ckih1,
>  		unsigned long rate_ckih2)
>  {
>  	int i;
>  
> +#ifdef CONFIG_OF
> +	of_clk_init(NULL);
> +#endif
> +
>  	clk[dummy] = imx_clk_fixed("dummy", 0);
> -	clk[ckil] = imx_clk_fixed("ckil", rate_ckil);
> -	clk[osc] = imx_clk_fixed("osc", rate_osc);
> -	clk[ckih1] = imx_clk_fixed("ckih1", rate_ckih1);
> -	clk[ckih2] = imx_clk_fixed("ckih2", rate_ckih2);
> +	clk[ckil] = mx5_obtain_fixed_clock("ckil", rate_ckil);
> +	clk[osc] = mx5_obtain_fixed_clock("osc", rate_osc);
> +	clk[ckih1] = mx5_obtain_fixed_clock("ckih1", rate_ckih1);
> +	clk[ckih2] = mx5_obtain_fixed_clock("ckih2", rate_ckih2);
>  
>  	clk[lp_apm] = imx_clk_mux("lp_apm", MXC_CCM_CCSR, 9, 1,
>  				lp_apm_sel, ARRAY_SIZE(lp_apm_sel));
> @@ -540,41 +579,13 @@ int __init mx53_clocks_init(unsigned long rate_ckil, unsigned long rate_osc,
>  }
>  
>  #ifdef CONFIG_OF
> -static void __init clk_get_freq_dt(unsigned long *ckil, unsigned long *osc,
> -				   unsigned long *ckih1, unsigned long *ckih2)
> -{
> -	struct device_node *np;
> -
> -	/* retrieve the freqency of fixed clocks from device tree */
> -	for_each_compatible_node(np, NULL, "fixed-clock") {
> -		u32 rate;
> -		if (of_property_read_u32(np, "clock-frequency", &rate))
> -			continue;
> -
> -		if (of_device_is_compatible(np, "fsl,imx-ckil"))
> -			*ckil = rate;
> -		else if (of_device_is_compatible(np, "fsl,imx-osc"))
> -			*osc = rate;
> -		else if (of_device_is_compatible(np, "fsl,imx-ckih1"))
> -			*ckih1 = rate;
> -		else if (of_device_is_compatible(np, "fsl,imx-ckih2"))
> -			*ckih2 = rate;
> -	}
> -}
> -
>  int __init mx51_clocks_init_dt(void)
>  {
> -	unsigned long ckil, osc, ckih1, ckih2;
> -
> -	clk_get_freq_dt(&ckil, &osc, &ckih1, &ckih2);
> -	return mx51_clocks_init(ckil, osc, ckih1, ckih2);
> +	return mx51_clocks_init(0, 0, 0, 0);
>  }
>  
>  int __init mx53_clocks_init_dt(void)
>  {
> -	unsigned long ckil, osc, ckih1, ckih2;
> -
> -	clk_get_freq_dt(&ckil, &osc, &ckih1, &ckih2);
> -	return mx53_clocks_init(ckil, osc, ckih1, ckih2);
> +	return mx53_clocks_init(0, 0, 0, 0);
>  }
>  #endif
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel



From olof at lixom.net  Thu Apr 18 02:42:17 2013
From: olof at lixom.net (Olof Johansson)
Date: Wed, 17 Apr 2013 23:42:17 -0700
Subject: [GIT PULL] mvebu irqchip for v3.10
In-Reply-To: <20130415195245.GU28693@titan.lakedaemon.net>
References: <20130415195245.GU28693@titan.lakedaemon.net>
Message-ID: <20130418064217.GF12816@quad.lixom.net>

On Mon, Apr 15, 2013 at 03:52:45PM -0400, Jason Cooper wrote:
> 
> The following changes since commit 31880c37c11e28cb81c70757e38392b42e695dc6:
> 
>   Linux 3.9-rc6 (2013-04-07 20:49:54 -0700)
> 
> are available in the git repository at:
> 
>   git://git.infradead.org/users/jcooper/linux.git tags/irqchip-3.10
> 
> for you to fetch changes up to 5ec69017cc944f3ed88362d4b60818713a45e616:
> 
>   irqchip: armada-370-xp: slightly cleanup irq controller driver (2013-04-15 19:35:17 +0000)
> 
> ----------------------------------------------------------------
> mvebu driver irqchip for v3.10
> 
>  - move the armada irqchip driver to drivers/irqchip/
> 
> Note:
>  - I asked tglx if it was ok to take this series on 10 Apr due to it's complex
>    dependencies.  5+ days have passed with no objection.
>  - I put this driver in a separate mvebu branch in case tglx or others object,
>    it can be dropped with minimal impact to other work.


Hi,

These notes are useful to include in the pull request, but not in the
git tag -- they don't really hold much permanent value.

This branch also seems to have a few internal conflicts on mbus
changes. Not a big deal, I fixed it up, but you might as well have based
this on the other branch as well.

Merged as a late/cleanup branch.


-Olof


From maz at misterjones.org  Thu Apr 18 02:49:33 2013
From: maz at misterjones.org (Marc Zyngier)
Date: Thu, 18 Apr 2013 08:49:33 +0200
Subject: [RFC] arm64: Early printk support for virtio-mmio console devices.
In-Reply-To: <1366264344-28025-1-git-send-email-pranavkumar@linaro.org>
References: <1366264344-28025-1-git-send-email-pranavkumar@linaro.org>
Message-ID: <ede8ee08bb2616c2ed642200e3357367@localhost>

Hi Pranavkumar,

On Thu, 18 Apr 2013 11:22:24 +0530, PranavkumarSawargaonkar
<pranavkumar at linaro.org> wrote:
> From: Pranavkumar Sawargaonkar <pranavkumar at linaro.org>
> 
> This patch implements early printk support for virtio-mmio console
devices
> without using any hypercalls.
> 
> The current virtio early printk code in kernel expects that hypervisor
> will provide some mechanism generally a hypercall to support early
printk.
> This patch does not break existing hypercall based early print support.
> 
> This implementation adds:
> 1. Early read-write register named early_rw in virtio console's config
> space.
> 2. Two host feature flags namely VIRTIO_CONSOLE_F_EARLY_READ and
> VIRTIO_CONSOLE_F_EARLY_WRITE for telling guest about early-read and
> early-write capability in console device.
> 
> Early write mechanism:
> 1. When a guest wants to out some character, it has to simply write the
> character to early_rw register in config space of virtio console device.
> 
> Early read mechanism:
> 1. When a guest wants to in some character, it has to simply read the
> early_rw register in config space of virtio console device. Lets say we
get
> 32-bit value X.
> 2. If most significant bit of X is set (i.e. X & 0x80000000 ==
0x80000000)
> then least significant 8 bits of X represents input charaacter else
guest
> need to try again reading early_rw register.
> 
> Note: This patch only includes kernel side changes for early printk, the
> host/hypervisor side emulation of early_rw register is out of scope
here.

Well, that's unfortunate, as it makes it quite difficult to understand the
impact of this patch.
Has the virtio side been posted somewhere? I expect you've implemented
something in kvmtool...

> Signed-off-by: Anup Patel <anup.patel at linaro.org>
> ---
>  arch/arm64/kernel/early_printk.c    |   24 ++++++++++++++++++++++++
>  include/uapi/linux/virtio_console.h |    4 ++++
>  2 files changed, 28 insertions(+)
> 
> diff --git a/arch/arm64/kernel/early_printk.c
> b/arch/arm64/kernel/early_printk.c
> index ac974f4..a82b5aa 100644
> --- a/arch/arm64/kernel/early_printk.c
> +++ b/arch/arm64/kernel/early_printk.c
> @@ -25,6 +25,9 @@
>  
>  #include <linux/amba/serial.h>
>  #include <linux/serial_reg.h>
> +#include <linux/virtio_ids.h>
> +#include <linux/virtio_mmio.h>
> +#include <linux/virtio_console.h>
>  
>  static void __iomem *early_base;
>  static void (*printch)(char ch);
> @@ -53,6 +56,26 @@ static void smh_printch(char ch)
>  }
>  
>  /*
> + * VIRTIO MMIO based debug console.
> + */
> +static void virtio_console_early_printch(char ch)
> +{
> +	u32 tmp;
> +	struct virtio_console_config *p = early_base + VIRTIO_MMIO_CONFIG;
> +
> +	tmp = readl_relaxed(early_base + VIRTIO_MMIO_DEVICE_ID);
> +	if (tmp != VIRTIO_ID_CONSOLE) {
> +		return;
> +	}
> +
> +	tmp = readl_relaxed(early_base + VIRTIO_MMIO_HOST_FEATURES);
> +	if (!(tmp & (1 << VIRTIO_CONSOLE_F_EARLY_WRITE))) {
> +		return;
> +	}
> +	writeb_relaxed(ch, &p->early_rw);

So here, you end up trapping 3 times per character being output on the
console. Surely there's a better way. How about remembering the result of
these tests in a static variable?

> +}
> +
> +/*
>   * 8250/16550 (8-bit aligned registers) single character TX.
>   */
>  static void uart8250_8bit_printch(char ch)
> @@ -82,6 +105,7 @@ static const struct earlycon_match earlycon_match[]
> __initconst = {
>  	{ .name = "smh", .printch = smh_printch, },
>  	{ .name = "uart8250-8bit", .printch = uart8250_8bit_printch, },
>  	{ .name = "uart8250-32bit", .printch = uart8250_32bit_printch, },
> +	{ .name = "virtio-console", .printch = virtio_console_early_printch,
},
>  	{}
>  };
>  
> diff --git a/include/uapi/linux/virtio_console.h
> b/include/uapi/linux/virtio_console.h
> index ee13ab6..1171cb4 100644
> --- a/include/uapi/linux/virtio_console.h
> +++ b/include/uapi/linux/virtio_console.h
> @@ -38,6 +38,8 @@
>  /* Feature bits */
>  #define VIRTIO_CONSOLE_F_SIZE	0	/* Does host provide console size? */
>  #define VIRTIO_CONSOLE_F_MULTIPORT 1	/* Does host provide multiple
ports?
>  */
> +#define VIRTIO_CONSOLE_F_EARLY_READ 2	/* Does host support early read?
*/
> +#define VIRTIO_CONSOLE_F_EARLY_WRITE 3	/* Does host support early
write?
> */
>  
>  #define VIRTIO_CONSOLE_BAD_ID		(~(u32)0)
>  
> @@ -48,6 +50,8 @@ struct virtio_console_config {
>  	__u16 rows;
>  	/* max. number of ports this device can hold */
>  	__u32 max_nr_ports;
> +	/* early read/write register */
> +	__u32 early_rw;
>  } __attribute__((packed));
>  
>  /*

So that bit is clearly a spec change. How does it work with PCI, or any
other virtio transport?

Overall, I'm a bit concerned with adding features that don't really match
the way virtio is supposed to work. The whole goal of virtio is to minimize
the amount of trapping, and here you end up trapping on each and every
access.

If you need an early console, why not simply wire the 8250 emulation in
kvmtool to be useable from the MMIO bus? I reckon this would solve your
problem in a more elegant way...

Cheers,

        M.
-- 
Who you jivin' with that Cosmik Debris?


From olof at lixom.net  Thu Apr 18 02:52:33 2013
From: olof at lixom.net (Olof Johansson)
Date: Wed, 17 Apr 2013 23:52:33 -0700
Subject: [GIT PULL v2 1/3] ARM: davinci: DT updates for v3.10 (part 2)
In-Reply-To: <1366220758-23373-1-git-send-email-nsekhar@ti.com>
References: <1366220758-23373-1-git-send-email-nsekhar@ti.com>
Message-ID: <20130418065233.GH12816@quad.lixom.net>

On Wed, Apr 17, 2013 at 11:15:56PM +0530, Sekhar Nori wrote:
> Hi Arnd, Olof,
> 
> Can you please pull these DaVinci DT updates for v3.10?
> The change in v2 is that Grant's acks on SPI patches
> have been added.
> 
> Thanks,
> Sekhar
> 
> The following changes since commit db4c8fa7c0214c83cbbc990ba630b3b613fcf7c5:
> 
>   ARM: davinci: da850: override mmc DT node device name (2013-04-04 16:58:10 +0530)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-for-v3.10/dt-2-v2
> 


Pulled into next/dt2.


Thanks

-Olof


From rusty at rustcorp.com.au  Thu Apr 18 02:51:47 2013
From: rusty at rustcorp.com.au (Rusty Russell)
Date: Thu, 18 Apr 2013 16:21:47 +0930
Subject: [RFC] arm64: Early printk support for virtio-mmio console devices.
In-Reply-To: <1366264344-28025-1-git-send-email-pranavkumar@linaro.org>
References: <1366264344-28025-1-git-send-email-pranavkumar@linaro.org>
Message-ID: <87wqs02uws.fsf@rustcorp.com.au>

PranavkumarSawargaonkar <pranavkumar at linaro.org> writes:
> From: Pranavkumar Sawargaonkar <pranavkumar at linaro.org>
>
> This patch implements early printk support for virtio-mmio console devices without using any hypercalls.

This makes some sense, though not sure that early console *read* makes
much sense.  I can see the PCI version of this being useful as well.

The spec definition for this will be interesting, because it can be used
before the device is initialized (something which is generally
verboten).

Cheers,
Rusty.


From olof at lixom.net  Thu Apr 18 02:56:30 2013
From: olof at lixom.net (Olof Johansson)
Date: Wed, 17 Apr 2013 23:56:30 -0700
Subject: [GIT PULL v2 3/3] ARM: davinci: board updates for v3.10 (part 2)
In-Reply-To: <1366220758-23373-3-git-send-email-nsekhar@ti.com>
References: <1366220758-23373-1-git-send-email-nsekhar@ti.com>
 <1366220758-23373-3-git-send-email-nsekhar@ti.com>
Message-ID: <20130418065630.GI12816@quad.lixom.net>

On Wed, Apr 17, 2013 at 11:15:58PM +0530, Sekhar Nori wrote:
> Hi Arnd, Olof,
> 
> Please pull the following board updates for v3.10. This
> depends on SoC updates in previous request.
> 
> Thanks,
> Sekhar
> 
> The following changes since commit 215a084dc5cb8d814aeb7a2b5192af20aec8209f:
> 
>   ARM: davinci: ensure global variables are declared (2013-04-17 19:26:41 +0530)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-for-v3.10/board-2-v2


Pulled, thanks.


-Olof


From marc.zyngier at arm.com  Thu Apr 18 03:13:10 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu, 18 Apr 2013 09:13:10 +0200
Subject: [PATCH v3 5/7] ARM: KVM: rework HYP page table freeing
In-Reply-To: <CAEDV+gJtHT7vyNLK1gNbNEzks0=ojZ7RoLGu3vW0CqVZreUnVg@mail.gmail.com>
References: <1365779932-20322-1-git-send-email-marc.zyngier@arm.com>
 <1365779932-20322-6-git-send-email-marc.zyngier@arm.com>
 <CAEDV+gJAUOsi3yjwp3hmBPbLkaL_0PaUNGFLLZN0nOzya7BA-A@mail.gmail.com>
 <89815b00ef8a11e6fc7bc03497b9668a@localhost>
 <CAEDV+gJtHT7vyNLK1gNbNEzks0=ojZ7RoLGu3vW0CqVZreUnVg@mail.gmail.com>
Message-ID: <f6de41fe392f15eb44e24d690c4a5ca4@localhost>

On Wed, 17 Apr 2013 22:23:21 -0700, Christoffer Dall
<cdall at cs.columbia.edu> wrote:
> On Mon, Apr 15, 2013 at 1:00 AM, Marc Zyngier <marc.zyngier at arm.com>
wrote:
> 
>> On Sun, 14 Apr 2013 23:51:55 -0700, Christoffer Dall
>> <cdall at cs.columbia.edu> wrote:
>> > On Fri, Apr 12, 2013 at 8:18 AM, Marc Zyngier <marc.zyngier at arm.com>
>> wrote:
>> >> There is no point in freeing HYP page tables differently from
Stage-2.
>> >> They now have the same requirements, and should be dealt with the
same
>> >> way.
>> >>
>> >> Promote unmap_stage2_range to be The One True Way, and get rid of a
>> >> number
>> >> of nasty bugs in the process (goo thing we never actually called
>> >> free_hyp_pmds
>> >
>> > could you remind me, did you already point out these nasty bugs
>> > somewhere or did we discuss them in an older thread?
>>
>> No, I decided it wasn't worth the hassle when I spotted them (specially
>> as
>> we're moving away from section mapped idmap)... But for the record:
>>
>> <quote>
>> static void free_hyp_pgd_entry(pgd_t *pgdp, unsigned long addr)
>> {
>>         pgd_t *pgd;
>>         pud_t *pud;
>>         pmd_t *pmd;
>>
>>         pgd = pgdp + pgd_index(addr);
>>         pud = pud_offset(pgd, addr);
>>
>>         if (pud_none(*pud))
>>                 return;
>>         BUG_ON(pud_bad(*pud));
>>
>>         pmd = pmd_offset(pud, addr);
>>         free_ptes(pmd, addr);
>>         pmd_free(NULL, pmd);
>>         ^^^^^^^^^^^^^^^^^^^^<-- BUG_ON(pmd not page aligned)
>>
> 
> This would never be non-page-aligned for Hyp page tables where PMDs are
> always 4K in size, that was the assumption.

Well, look at the pmd variable. As the result of pmd_offset(), it gives
you a pointer to a PMD *entry*, not to a PMD *page*. This entry can be
anywhere in that page, depending on the 2M section in a 1GB table.

> 
>>         pud_clear(pud);
>> }
>> </quote>
>>
>> Now, if you decide to fix the above by forcing the page alignment:
>>
>> <quote>
>> static void free_ptes(pmd_t *pmd, unsigned long addr)
>> {
>>         pte_t *pte;
>>         unsigned int i;
>>
>>         for (i = 0; i < PTRS_PER_PMD; i++, addr += PMD_SIZE) {
>>              ^^^^^^^^^^^^^<-- start freeing memory outside of the
>> (unaligned) pmd...
>>
> 
> freeing what outside the pmd? I don't see this.

Remember the above (PMD entry vs PMD page)? This code assumes it gets a
PMD page. To work properly, it would read:
           for (i = pmd_index(addr); i < PTRS_PER_PMDs; ....

> 
>>                 if (!pmd_none(*pmd) && pmd_table(*pmd)) {
>>                         pte = pte_offset_kernel(pmd, addr);
>>                         pte_free_kernel(NULL, pte);
>>                 }
>>                 pmd++;
>>         }
>> }
>> </quote>
>>
>> Once you've fixed that as well, you end up noticing that if you have
PTEs
>> pointed to by the same PMD, you need to introduce some refcounting if
you
>> need to free one PTE and not the others.
>>
> 
> huh? the code always freed all the hyp tables and there would be no
sharing
> of ptes across multiple pmds. I'm confused.

Not anymore. In non HOTPLUG_CPU case, we free the trampoline page from the
runtime HYP page tables (it is worth it if we had to use a bounce page). If
you free an entire PMD, odds are you'll also unmap some of the HYP code
(been there...).

> For the record, I like your patch and we should definitely only have one
> path of allocating and freeing the tables, but if my code was buggy I
want
> to learn from my mistakes and know exactly what went bad.

Well, I hope I made clear what the problem was. The main reason we didn't
notice this is because this code was only called on the error path, which
is mostly untested.

>>
>> At this point, I had enough, and decided to reuse what we already had
>> instead of reinventing the wheel.
> 
> 
>> > nit: s/goo/good/
>> >
>> >> before...).
>>
>> Will fix.
>>
> 
> I made the adjustment in my queue so you don't need to send out a new
> series, unless you want to do that for other reasons.

No particular reason, no. Unless people have additional comments that
would require a new version of the series.

Thanks,

        M.
-- 
Fast, cheap, reliable. Pick two.


From pranavkumar at linaro.org  Thu Apr 18 03:24:50 2013
From: pranavkumar at linaro.org (Pranavkumar Sawargaonkar)
Date: Thu, 18 Apr 2013 12:54:50 +0530
Subject: [RFC] arm64: Early printk support for virtio-mmio console devices.
In-Reply-To: <ede8ee08bb2616c2ed642200e3357367@localhost>
References: <1366264344-28025-1-git-send-email-pranavkumar@linaro.org>
 <ede8ee08bb2616c2ed642200e3357367@localhost>
Message-ID: <CAAHg+HhMmu5VZi=mhqgwBHGE=i+DsC8eA=iMzkNorB4LrTHBjQ@mail.gmail.com>

Hi Marc,

On 18 April 2013 12:19, Marc Zyngier <maz at misterjones.org> wrote:
> Hi Pranavkumar,
>
> On Thu, 18 Apr 2013 11:22:24 +0530, PranavkumarSawargaonkar
> <pranavkumar at linaro.org> wrote:
>> From: Pranavkumar Sawargaonkar <pranavkumar at linaro.org>
>>
>> This patch implements early printk support for virtio-mmio console
> devices
>> without using any hypercalls.
>>
>> The current virtio early printk code in kernel expects that hypervisor
>> will provide some mechanism generally a hypercall to support early
> printk.
>> This patch does not break existing hypercall based early print support.
>>
>> This implementation adds:
>> 1. Early read-write register named early_rw in virtio console's config
>> space.
>> 2. Two host feature flags namely VIRTIO_CONSOLE_F_EARLY_READ and
>> VIRTIO_CONSOLE_F_EARLY_WRITE for telling guest about early-read and
>> early-write capability in console device.
>>
>> Early write mechanism:
>> 1. When a guest wants to out some character, it has to simply write the
>> character to early_rw register in config space of virtio console device.
>>
>> Early read mechanism:
>> 1. When a guest wants to in some character, it has to simply read the
>> early_rw register in config space of virtio console device. Lets say we
> get
>> 32-bit value X.
>> 2. If most significant bit of X is set (i.e. X & 0x80000000 ==
> 0x80000000)
>> then least significant 8 bits of X represents input charaacter else
> guest
>> need to try again reading early_rw register.
>>
>> Note: This patch only includes kernel side changes for early printk, the
>> host/hypervisor side emulation of early_rw register is out of scope
> here.
>
> Well, that's unfortunate, as it makes it quite difficult to understand the
> impact of this patch.
> Has the virtio side been posted somewhere? I expect you've implemented
> something in kvmtool...

Yes i have implemented kvmtool side also and code change is really
small (not really a clean code currently)
I can post it also but since it is specific to kvmtool i have not
posted it with rfc.

>
>> Signed-off-by: Anup Patel <anup.patel at linaro.org>
>> ---
>>  arch/arm64/kernel/early_printk.c    |   24 ++++++++++++++++++++++++
>>  include/uapi/linux/virtio_console.h |    4 ++++
>>  2 files changed, 28 insertions(+)
>>
>> diff --git a/arch/arm64/kernel/early_printk.c
>> b/arch/arm64/kernel/early_printk.c
>> index ac974f4..a82b5aa 100644
>> --- a/arch/arm64/kernel/early_printk.c
>> +++ b/arch/arm64/kernel/early_printk.c
>> @@ -25,6 +25,9 @@
>>
>>  #include <linux/amba/serial.h>
>>  #include <linux/serial_reg.h>
>> +#include <linux/virtio_ids.h>
>> +#include <linux/virtio_mmio.h>
>> +#include <linux/virtio_console.h>
>>
>>  static void __iomem *early_base;
>>  static void (*printch)(char ch);
>> @@ -53,6 +56,26 @@ static void smh_printch(char ch)
>>  }
>>
>>  /*
>> + * VIRTIO MMIO based debug console.
>> + */
>> +static void virtio_console_early_printch(char ch)
>> +{
>> +     u32 tmp;
>> +     struct virtio_console_config *p = early_base + VIRTIO_MMIO_CONFIG;
>> +
>> +     tmp = readl_relaxed(early_base + VIRTIO_MMIO_DEVICE_ID);
>> +     if (tmp != VIRTIO_ID_CONSOLE) {
>> +             return;
>> +     }
>> +
>> +     tmp = readl_relaxed(early_base + VIRTIO_MMIO_HOST_FEATURES);
>> +     if (!(tmp & (1 << VIRTIO_CONSOLE_F_EARLY_WRITE))) {
>> +             return;
>> +     }
>> +     writeb_relaxed(ch, &p->early_rw);
>
> So here, you end up trapping 3 times per character being output on the
> console. Surely there's a better way. How about remembering the result of
> these tests in a static variable?

Yeah surely it is a better idea to remember using static variable, so
that after initialize once, it will trap only one time.

>
>> +}
>> +
>> +/*
>>   * 8250/16550 (8-bit aligned registers) single character TX.
>>   */
>>  static void uart8250_8bit_printch(char ch)
>> @@ -82,6 +105,7 @@ static const struct earlycon_match earlycon_match[]
>> __initconst = {
>>       { .name = "smh", .printch = smh_printch, },
>>       { .name = "uart8250-8bit", .printch = uart8250_8bit_printch, },
>>       { .name = "uart8250-32bit", .printch = uart8250_32bit_printch, },
>> +     { .name = "virtio-console", .printch = virtio_console_early_printch,
> },
>>       {}
>>  };
>>
>> diff --git a/include/uapi/linux/virtio_console.h
>> b/include/uapi/linux/virtio_console.h
>> index ee13ab6..1171cb4 100644
>> --- a/include/uapi/linux/virtio_console.h
>> +++ b/include/uapi/linux/virtio_console.h
>> @@ -38,6 +38,8 @@
>>  /* Feature bits */
>>  #define VIRTIO_CONSOLE_F_SIZE        0       /* Does host provide console size? */
>>  #define VIRTIO_CONSOLE_F_MULTIPORT 1 /* Does host provide multiple
> ports?
>>  */
>> +#define VIRTIO_CONSOLE_F_EARLY_READ 2        /* Does host support early read?
> */
>> +#define VIRTIO_CONSOLE_F_EARLY_WRITE 3       /* Does host support early
> write?
>> */
>>
>>  #define VIRTIO_CONSOLE_BAD_ID                (~(u32)0)
>>
>> @@ -48,6 +50,8 @@ struct virtio_console_config {
>>       __u16 rows;
>>       /* max. number of ports this device can hold */
>>       __u32 max_nr_ports;
>> +     /* early read/write register */
>> +     __u32 early_rw;
>>  } __attribute__((packed));
>>
>>  /*
>
> So that bit is clearly a spec change. How does it work with PCI, or any
> other virtio transport?
>
> Overall, I'm a bit concerned with adding features that don't really match
> the way virtio is supposed to work. The whole goal of virtio is to minimize
> the amount of trapping, and here you end up trapping on each and every
> access.
>
> If you need an early console, why not simply wire the 8250 emulation in
> kvmtool to be useable from the MMIO bus? I reckon this would solve your
> problem in a more elegant way...
>
Emulation will solve the issue but having a virtio early read or write
has one more advantage i.e.
In case of mach-virt we might need early read-write support for virtio
console to see if kernel is not panic before actual virtio drivers
takes control.
Also if someone wants to have UEFI or uboot running on mach-virt then
we also need early input facility in virtio console.

> Cheers,
>
>         M.
> --
> Who you jivin' with that Cosmik Debris?

Thanks,
Pranav


From pranavkumar at linaro.org  Thu Apr 18 03:32:40 2013
From: pranavkumar at linaro.org (Pranavkumar Sawargaonkar)
Date: Thu, 18 Apr 2013 13:02:40 +0530
Subject: [RFC] arm64: Early printk support for virtio-mmio console devices.
In-Reply-To: <87wqs02uws.fsf@rustcorp.com.au>
References: <1366264344-28025-1-git-send-email-pranavkumar@linaro.org>
 <87wqs02uws.fsf@rustcorp.com.au>
Message-ID: <CAAHg+HiHKV+8hBT1QWe4hSxocCX6wpRd3bCPWB7zU8jVFmPuAA@mail.gmail.com>

On 18 April 2013 12:21, Rusty Russell <rusty at rustcorp.com.au> wrote:
>
> PranavkumarSawargaonkar <pranavkumar at linaro.org> writes:
> > From: Pranavkumar Sawargaonkar <pranavkumar at linaro.org>
> >
> > This patch implements early printk support for virtio-mmio console devices without using any hypercalls.
>
> This makes some sense, though not sure that early console *read* makes
> much sense.  I can see the PCI version of this being useful as well.

Read can be useful for "mach-virt" which will have only virtio console
as a console device. Then if someone wants to have UEFI or any other
boot-loader emulation, which expects user to input few things, in that
case read might become handy.
>
>
> The spec definition for this will be interesting, because it can be used
> before the device is initialized (something which is generally
> verboten).
>
> Cheers,
> Rusty.

Thanks,
Pranav


From marc.zyngier at arm.com  Thu Apr 18 03:36:12 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu, 18 Apr 2013 09:36:12 +0200
Subject: [RFC] arm64: Early printk support for virtio-mmio console devices.
In-Reply-To: <CAAHg+HhajHFC=1nh6YQNgpf=Na2FqcsYJ=t+ag9QiTg6TxUz9w@mail.gmail.com>
References: <1366264344-28025-1-git-send-email-pranavkumar@linaro.org>
 <ede8ee08bb2616c2ed642200e3357367@localhost>
 <CAAHg+HhajHFC=1nh6YQNgpf=Na2FqcsYJ=t+ag9QiTg6TxUz9w@mail.gmail.com>
Message-ID: <bb1193983de3ea9f4df1a570441df34c@localhost>

On Thu, 18 Apr 2013 12:47:18 +0530, Pranavkumar Sawargaonkar
<pranavkumar at linaro.org> wrote:
> Hi Marc,
> 
> On 18 April 2013 12:19, Marc Zyngier <maz at misterjones.org> wrote:
> 
>> Hi Pranavkumar,
>>
>> On Thu, 18 Apr 2013 11:22:24 +0530, PranavkumarSawargaonkar
>> <pranavkumar at linaro.org> wrote:
>> > From: Pranavkumar Sawargaonkar <pranavkumar at linaro.org>
>> >
>> > This patch implements early printk support for virtio-mmio console
>> devices
>> > without using any hypercalls.
>> >
>> > The current virtio early printk code in kernel expects that
hypervisor
>> > will provide some mechanism generally a hypercall to support early
>> printk.
>> > This patch does not break existing hypercall based early print
support.
>> >
>> > This implementation adds:
>> > 1. Early read-write register named early_rw in virtio console's
config
>> > space.
>> > 2. Two host feature flags namely VIRTIO_CONSOLE_F_EARLY_READ and
>> > VIRTIO_CONSOLE_F_EARLY_WRITE for telling guest about early-read and
>> > early-write capability in console device.
>> >
>> > Early write mechanism:
>> > 1. When a guest wants to out some character, it has to simply write
the
>> > character to early_rw register in config space of virtio console
>> > device.
>> >
>> > Early read mechanism:
>> > 1. When a guest wants to in some character, it has to simply read the
>> > early_rw register in config space of virtio console device. Lets say
we
>> get
>> > 32-bit value X.
>> > 2. If most significant bit of X is set (i.e. X & 0x80000000 ==
>> 0x80000000)
>> > then least significant 8 bits of X represents input charaacter else
>> guest
>> > need to try again reading early_rw register.
>> >
>> > Note: This patch only includes kernel side changes for early printk,
>> > the
>> > host/hypervisor side emulation of early_rw register is out of scope
>> here.
>>
>> Well, that's unfortunate, as it makes it quite difficult to understand
>> the
>> impact of this patch.
>> Has the virtio side been posted somewhere? I expect you've implemented
>> something in kvmtool...
>>
> 
> Yes i have implemented kvmtool side also and code change is really small
> (not really a clean code currently)
> I can post it also but since it is specific to kvmtool i have not posted
it
> with rfc.

Doesn't really if the code needs some rework at this point (I expect the
patch to be fairly small indeed). Any chance you could post it to the KVM
list?

>>
>> > Signed-off-by: Anup Patel <anup.patel at linaro.org>
>> > ---
>> >  arch/arm64/kernel/early_printk.c    |   24 ++++++++++++++++++++++++
>> >  include/uapi/linux/virtio_console.h |    4 ++++
>> >  2 files changed, 28 insertions(+)
>> >
>> > diff --git a/arch/arm64/kernel/early_printk.c
>> > b/arch/arm64/kernel/early_printk.c
>> > index ac974f4..a82b5aa 100644
>> > --- a/arch/arm64/kernel/early_printk.c
>> > +++ b/arch/arm64/kernel/early_printk.c
>> > @@ -25,6 +25,9 @@
>> >
>> >  #include <linux/amba/serial.h>
>> >  #include <linux/serial_reg.h>
>> > +#include <linux/virtio_ids.h>
>> > +#include <linux/virtio_mmio.h>
>> > +#include <linux/virtio_console.h>
>> >
>> >  static void __iomem *early_base;
>> >  static void (*printch)(char ch);
>> > @@ -53,6 +56,26 @@ static void smh_printch(char ch)
>> >  }
>> >
>> >  /*
>> > + * VIRTIO MMIO based debug console.
>> > + */
>> > +static void virtio_console_early_printch(char ch)
>> > +{
>> > +     u32 tmp;
>> > +     struct virtio_console_config *p = early_base +
>> > VIRTIO_MMIO_CONFIG;
>> > +
>> > +     tmp = readl_relaxed(early_base + VIRTIO_MMIO_DEVICE_ID);
>> > +     if (tmp != VIRTIO_ID_CONSOLE) {
>> > +             return;
>> > +     }
>> > +
>> > +     tmp = readl_relaxed(early_base + VIRTIO_MMIO_HOST_FEATURES);
>> > +     if (!(tmp & (1 << VIRTIO_CONSOLE_F_EARLY_WRITE))) {
>> > +             return;
>> > +     }
>> > +     writeb_relaxed(ch, &p->early_rw);
>>
>> So here, you end up trapping 3 times per character being output on the
>> console. Surely there's a better way. How about remembering the result
of
>> these tests in a static variable?
>>
> Yeah surely it is a better idea to remember using static variable, so
that
> after initialize once, it will trap only one time.

Also, would it be possible to directly get the base address from DT? It
would save having to pass the address (which is not known before runtime in
the case of kvmtool). Not sure if it is available that early though...

>>
>> > +}
>> > +
>> > +/*
>> >   * 8250/16550 (8-bit aligned registers) single character TX.
>> >   */
>> >  static void uart8250_8bit_printch(char ch)
>> > @@ -82,6 +105,7 @@ static const struct earlycon_match
earlycon_match[]
>> > __initconst = {
>> >       { .name = "smh", .printch = smh_printch, },
>> >       { .name = "uart8250-8bit", .printch = uart8250_8bit_printch, },
>> >       { .name = "uart8250-32bit", .printch = uart8250_32bit_printch,
},
>> > +     { .name = "virtio-console", .printch =
>> virtio_console_early_printch,
>> },
>> >       {}
>> >  };
>> >
>> > diff --git a/include/uapi/linux/virtio_console.h
>> > b/include/uapi/linux/virtio_console.h
>> > index ee13ab6..1171cb4 100644
>> > --- a/include/uapi/linux/virtio_console.h
>> > +++ b/include/uapi/linux/virtio_console.h
>> > @@ -38,6 +38,8 @@
>> >  /* Feature bits */
>> >  #define VIRTIO_CONSOLE_F_SIZE        0       /* Does host provide
>> console size? */
>> >  #define VIRTIO_CONSOLE_F_MULTIPORT 1 /* Does host provide multiple
>> ports?
>> >  */
>> > +#define VIRTIO_CONSOLE_F_EARLY_READ 2        /* Does host support
>> > early
>> read?
>> */
>> > +#define VIRTIO_CONSOLE_F_EARLY_WRITE 3       /* Does host support
>> > early
>> write?
>> > */
>> >
>> >  #define VIRTIO_CONSOLE_BAD_ID                (~(u32)0)
>> >
>> > @@ -48,6 +50,8 @@ struct virtio_console_config {
>> >       __u16 rows;
>> >       /* max. number of ports this device can hold */
>> >       __u32 max_nr_ports;
>> > +     /* early read/write register */
>> > +     __u32 early_rw;
>> >  } __attribute__((packed));
>> >
>> >  /*
>>
>> So that bit is clearly a spec change. How does it work with PCI, or any
>> other virtio transport?
>>
> I am not sure about PCI hence just posted for MMIO.
> 
>>
>> Overall, I'm a bit concerned with adding features that don't really
match
>> the way virtio is supposed to work. The whole goal of virtio is to
>> minimize
>> the amount of trapping, and here you end up trapping on each and every
>> access.
>>
>> If you need an early console, why not simply wire the 8250 emulation in
>> kvmtool to be useable from the MMIO bus? I reckon this would solve your
>> problem in a more elegant way...
>>
> Emulation will solve the issue but having a virtio early read or write
has
> one more advantage i.e.
> In case of mach-virt we might need early read-write support for virtio
> console to see if kernel is not panic before actual virtio drivers takes
> control.
> Also if someone wants to have UEFI or uboot running on mach-virt then we
> also need early input facility in virtio console.

That's exactly why I was suggesting using the 8250 emulation. It is
supported by everything under the sun. I do not immediately see what the
gain is with this virtio approach, as compared to 8250 emulation.

Don't misunderstand me, I like the idea of having a virtio-only system,
specially if we can make it work with other transports. I just want to
outline that there may be a simpler way for your particular use case.

Thanks,

        M.
-- 
Fast, cheap, reliable. Pick two.


From nicolas.ferre at atmel.com  Thu Apr 18 03:52:59 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Thu, 18 Apr 2013 09:52:59 +0200
Subject: [PATCH for 3.9-final] dmaengine: at_hdmac: fix race condition in
 atc_advance_work()
In-Reply-To: <1366112974-32043-1-git-send-email-nicolas.ferre@atmel.com>
References: <1366112974-32043-1-git-send-email-nicolas.ferre@atmel.com>
Message-ID: <1366271579-30248-1-git-send-email-nicolas.ferre@atmel.com>

From: Ludovic Desroches <ludovic.desroches at atmel.com>

The BUG_ON() directive is triggered probably due to a latency modification
following inclusion of c10d736 (softirq: reduce latencies).
This condition has not been met before 3.9-rc1 and doesn't trigger without
this patch.

We now make sure that DMA channel is idle before calling atc_complete_all()
which makes the BUG_ON() "protection" useless.

Signed-off-by: Ludovic Desroches <ludovic.desroches at atmel.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre at atmel.com>
Acked-by: Vinod Koul <vinod.koul at intel.com>
---
Linus,

I re-send the patch with Vinod's acknowledgement and a little "for 3.9-final"
tag to make sure that you see it before the 3.9 release.

We have identified a race condition on the Atmel ARM-based AT91 DMA controller
driver that leads to hitting a BUG_ON() directive.
This error, only triggered after the inclusion of a patch that reduces the
softirq latency, is affecting several AT91 SoCs and can be seen
as a regression by people using the dmaengine driver (on NAND flash
accesses for instance).

I know that it is late in the development cycle but can you please consider
including it in your tree before 3.9-final?

Thanks a lot, best regards,

Nicolas Ferre


 drivers/dma/at_hdmac.c | 9 ++++-----
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/dma/at_hdmac.c b/drivers/dma/at_hdmac.c
index 6e13f26..88cfc61 100644
--- a/drivers/dma/at_hdmac.c
+++ b/drivers/dma/at_hdmac.c
@@ -310,8 +310,6 @@ static void atc_complete_all(struct at_dma_chan *atchan)
 
 	dev_vdbg(chan2dev(&atchan->chan_common), "complete all\n");
 
-	BUG_ON(atc_chan_is_enabled(atchan));
-
 	/*
 	 * Submit queued descriptors ASAP, i.e. before we go through
 	 * the completed ones.
@@ -368,6 +366,9 @@ static void atc_advance_work(struct at_dma_chan *atchan)
 {
 	dev_vdbg(chan2dev(&atchan->chan_common), "advance_work\n");
 
+	if (atc_chan_is_enabled(atchan))
+		return;
+
 	if (list_empty(&atchan->active_list) ||
 	    list_is_singular(&atchan->active_list)) {
 		atc_complete_all(atchan);
@@ -1078,9 +1079,7 @@ static void atc_issue_pending(struct dma_chan *chan)
 		return;
 
 	spin_lock_irqsave(&atchan->lock, flags);
-	if (!atc_chan_is_enabled(atchan)) {
-		atc_advance_work(atchan);
-	}
+	atc_advance_work(atchan);
 	spin_unlock_irqrestore(&atchan->lock, flags);
 }
 
-- 
1.8.0



From nicolas.ferre at atmel.com  Thu Apr 18 03:59:10 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Thu, 18 Apr 2013 09:59:10 +0200
Subject: [PATCH 1/1] ARM: at91sam9260: dt: uart1 fix pinctrl typo
In-Reply-To: <1366141672-10302-1-git-send-email-plagnioj@jcrosoft.com>
References: <1366141672-10302-1-git-send-email-plagnioj@jcrosoft.com>
Message-ID: <516FA7CE.7030109@atmel.com>

On 04/16/2013 09:47 PM, Jean-Christophe PLAGNIOL-VILLARD :
> it's bank B not C

Already seen by Douglas Gilbert and queued for 3.10 in arm-soc/at91/dt3

Thanks anyway, bye.

> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
> Cc: Nicolas Ferre <nicolas.ferre at atmel.com>
> Reported-by: Adam Porter <porter.adam at gmail.com>
> ---
>  arch/arm/boot/dts/at91sam9260.dtsi |    4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/at91sam9260.dtsi b/arch/arm/boot/dts/at91sam9260.dtsi
> index 367a604..6980ed1 100644
> --- a/arch/arm/boot/dts/at91sam9260.dtsi
> +++ b/arch/arm/boot/dts/at91sam9260.dtsi
> @@ -220,8 +220,8 @@
>  				uart1 {
>  					pinctrl_uart1: uart1-0 {
>  						atmel,pins =
> -							<2 12 0x1 0x1	/* PB12 periph A with pullup */
> -							 2 13 0x1 0x0>;	/* PB13 periph A */
> +							<1 12 0x1 0x1	/* PB12 periph A with pullup */
> +							 1 13 0x1 0x0>;	/* PB13 periph A */
>  					};
>  				};
>  
> 


-- 
Nicolas Ferre


From lee.jones at linaro.org  Thu Apr 18 04:02:38 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Thu, 18 Apr 2013 09:02:38 +0100
Subject: [PATCH] mmc: mmci: Allow MMCI to request channels with
 information acquired from DT
In-Reply-To: <201304171731.56292.arnd@arndb.de>
References: <1366205534-25079-1-git-send-email-lee.jones@linaro.org>
 <201304171550.56037.arnd@arndb.de>
 <20130417150437.GA3137@gmail.com>
 <201304171731.56292.arnd@arndb.de>
Message-ID: <20130418080238.GB3137@gmail.com>

> I think you can further simplify this, given that in the DT case we always
> allocate a zeroed mmci_platform_data for host->plat, so !plat cannot happen
> when we get here.

Okay, third time lucky. :)

diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index 372e921..3260ab4 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -298,14 +298,16 @@ static void mmci_init_sg(struct mmci_host *host, struct mmc_data *data)
  * no custom DMA interfaces are supported.
  */
 #ifdef CONFIG_DMA_ENGINE
-static void mmci_dma_setup(struct mmci_host *host)
+static void mmci_dma_setup(struct amba_device *dev,
+			   struct mmci_host *host)
 {
+	struct device_node *np = dev->dev.of_node;
 	struct mmci_platform_data *plat = host->plat;
 	const char *rxname, *txname;
 	dma_cap_mask_t mask;
 
-	if (!plat || !plat->dma_filter) {
-		dev_info(mmc_dev(host->mmc), "no DMA platform data\n");
+	if (!(plat->dma_filter || np)) {
+		dev_info(mmc_dev(host->mmc), "no DMA platform data or DT\n");
 		return;
 	}
 
@@ -321,19 +323,21 @@ static void mmci_dma_setup(struct mmci_host *host)
 	 * attempt to use it bidirectionally, however if it is
 	 * is specified but cannot be located, DMA will be disabled.
 	 */
-	if (plat->dma_rx_param) {
-		host->dma_rx_channel = dma_request_channel(mask,
-							   plat->dma_filter,
-							   plat->dma_rx_param);
+	if (plat->dma_rx_param || np) {
+		host->dma_rx_channel = dma_request_slave_channel_compat(mask,
+								plat->dma_filter,
+								plat->dma_rx_param,
+								&dev->dev, "rx");
 		/* E.g if no DMA hardware is present */
 		if (!host->dma_rx_channel)
 			dev_err(mmc_dev(host->mmc), "no RX DMA channel\n");
 	}
 
-	if (plat->dma_tx_param) {
-		host->dma_tx_channel = dma_request_channel(mask,
-							   plat->dma_filter,
-							   plat->dma_tx_param);
+	if (plat->dma_tx_param || np) {
+		host->dma_tx_channel = dma_request_slave_channel_compat(mask,
+								plat->dma_filter,
+								plat->dma_tx_param,
+								&dev->dev, "tx");
 		if (!host->dma_tx_channel)
 			dev_warn(mmc_dev(host->mmc), "no TX DMA channel\n");
 	} else {
@@ -1538,7 +1542,7 @@ static int mmci_probe(struct amba_device *dev,
 		 amba_rev(dev), (unsigned long long)dev->res.start,
 		 dev->irq[0], dev->irq[1]);
 
-	mmci_dma_setup(host);
+	mmci_dma_setup(dev, host);
 
 	pm_runtime_set_autosuspend_delay(&dev->dev, 50);
 	pm_runtime_use_autosuspend(&dev->dev);

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From lee.jones at linaro.org  Thu Apr 18 04:14:16 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Thu, 18 Apr 2013 09:14:16 +0100
Subject: [PATCH v2] serial: pl011: Add Device Tree support to request DMA
 channels
Message-ID: <1366272857-14038-1-git-send-email-lee.jones@linaro.org>

The new DMA API is operational. It is now possible to request DMA
channels from information passed via Device Tree.

Cc: Russell King <linux at arm.linux.org.uk>
Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
Cc: Jiri Slaby <jslaby at suse.cz>
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 drivers/tty/serial/amba-pl011.c |   19 +++++++++++++------
 1 file changed, 13 insertions(+), 6 deletions(-)

diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
index 3ea5408..1b39f58 100644
--- a/drivers/tty/serial/amba-pl011.c
+++ b/drivers/tty/serial/amba-pl011.c
@@ -249,6 +249,7 @@ static void pl011_dma_probe_initcall(struct uart_amba_port *uap)
 {
 	/* DMA is the sole user of the platform data right now */
 	struct amba_pl011_data *plat = uap->port.dev->platform_data;
+	struct device_node *np = uap->port.dev->of_node;
 	struct dma_slave_config tx_conf = {
 		.dst_addr = uap->port.mapbase + UART01x_DR,
 		.dst_addr_width = DMA_SLAVE_BUSWIDTH_1_BYTE,
@@ -259,9 +260,9 @@ static void pl011_dma_probe_initcall(struct uart_amba_port *uap)
 	struct dma_chan *chan;
 	dma_cap_mask_t mask;
 
-	/* We need platform data */
-	if (!plat || !plat->dma_filter) {
-		dev_info(uap->port.dev, "no DMA platform data\n");
+	/* We need platform data or DT */
+	if (!(plat && plat->dma_filter) && !np) {
+		dev_info(uap->port.dev, "no DMA platform data or DT\n");
 		return;
 	}
 
@@ -269,7 +270,10 @@ static void pl011_dma_probe_initcall(struct uart_amba_port *uap)
 	dma_cap_zero(mask);
 	dma_cap_set(DMA_SLAVE, mask);
 
-	chan = dma_request_channel(mask, plat->dma_filter, plat->dma_tx_param);
+	chan = dma_request_slave_channel_compat(mask,
+				(plat) ? plat->dma_filter : NULL,
+				(plat) ? plat->dma_tx_param : NULL,
+				uap->port.dev, "tx");
 	if (!chan) {
 		dev_err(uap->port.dev, "no TX DMA channel!\n");
 		return;
@@ -282,7 +286,7 @@ static void pl011_dma_probe_initcall(struct uart_amba_port *uap)
 		 dma_chan_name(uap->dmatx.chan));
 
 	/* Optionally make use of an RX channel as well */
-	if (plat->dma_rx_param) {
+	if ((plat && plat->dma_rx_param) || np) {
 		struct dma_slave_config rx_conf = {
 			.src_addr = uap->port.mapbase + UART01x_DR,
 			.src_addr_width = DMA_SLAVE_BUSWIDTH_1_BYTE,
@@ -291,7 +295,10 @@ static void pl011_dma_probe_initcall(struct uart_amba_port *uap)
 			.device_fc = false,
 		};
 
-		chan = dma_request_channel(mask, plat->dma_filter, plat->dma_rx_param);
+		chan = dma_request_slave_channel_compat(mask,
+					(plat) ? plat->dma_filter : NULL,
+					(plat) ? plat->dma_rx_param : NULL,
+					uap->port.dev, "rx");
 		if (!chan) {
 			dev_err(uap->port.dev, "no RX DMA channel!\n");
 			return;
-- 
1.7.10.4



From u.kleine-koenig at pengutronix.de  Thu Apr 18 04:15:55 2013
From: u.kleine-koenig at pengutronix.de (Uwe =?iso-8859-1?Q?Kleine-K=F6nig?=)
Date: Thu, 18 Apr 2013 10:15:55 +0200
Subject: [PATCH v3] irqchip: Add support for ARMv7-M's NVIC
In-Reply-To: <201304172223.43707.arnd@arndb.de>
References: <1366214540-31166-1-git-send-email-u.kleine-koenig@pengutronix.de>
 <201304172223.43707.arnd@arndb.de>
Message-ID: <20130418081555.GV30416@pengutronix.de>

On Wed, Apr 17, 2013 at 10:23:43PM +0200, Arnd Bergmann wrote:
> On Wednesday 17 April 2013, Uwe Kleine-K?nig wrote:
> 
> > This patch triggers two checkpatch warnings:
> > 
> > 	WARNING: Avoid CamelCase: <nvic_do_IRQ>
> > 	WARNING: Avoid CamelCase: <handle_IRQ>
> > 
> > but I think they are OK for consistency?!
> 
> You obviously have no choice for handle_IRQ, but I think the common way to
> name the first-level interrupt handler would be "nvic_handle_irq" here.
The function I called before is asm_do_IRQ which is another instance of
this naming scheme. But I agree that nvic_handle_irq is nicer and will
change to nvic_handle_irq in the next iteration.
 
> > Moreover sparse tells me:
> > 
> > 	drivers/irqchip/irq-nvic.c:58:1: warning: symbol 'nvic_do_IRQ' was not declared. Should it be static?
> > 
> > nvic_do_IRQ is called from assembler only, so a declaration couldn't be
> > shared and I couldn't find a nice place for a declaration. Suggestions
> > welcome.
> 
> Can't you make it static and call set_handle_irq() on it from the
> probe function?
Yeah that works. Then nvic_handle_irq needs to determine the irq itself
which is currently done in the entry code.

> > + * Each bank handles 32 irqs. Only the 16th (= last) bank handles only
> > + * 16 irqs.
> > + */
> > +#define NVIC_MAX_IRQ		((NVIC_MAX_BANKS - 1) * 32 + 16)
> 
> Is this actually inherent to the hardware design, or is the number of irqs
> actually customizable? Also, why do you care about the maximum? You only
> use it to check against the device tree provided value, but I suppose
> you could just as well trust that property to be correct.
I don't provide a value for the number of irqs in the device tree. There
is only the value INTLINESNUM in the V7M_SCS_ICTR register that is used
to determine the number of interrupt banks.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |


From linux at arm.linux.org.uk  Thu Apr 18 04:15:49 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Thu, 18 Apr 2013 09:15:49 +0100
Subject: [PATCH] mmc: mmci: Allow MMCI to request channels with
 information acquired from DT
In-Reply-To: <20130418080238.GB3137@gmail.com>
References: <1366205534-25079-1-git-send-email-lee.jones@linaro.org>
 <201304171550.56037.arnd@arndb.de> <20130417150437.GA3137@gmail.com>
 <201304171731.56292.arnd@arndb.de> <20130418080238.GB3137@gmail.com>
Message-ID: <20130418081549.GE14496@n2100.arm.linux.org.uk>

On Thu, Apr 18, 2013 at 09:02:38AM +0100, Lee Jones wrote:
> @@ -321,19 +323,21 @@ static void mmci_dma_setup(struct mmci_host *host)
>  	 * attempt to use it bidirectionally, however if it is
>  	 * is specified but cannot be located, DMA will be disabled.
>  	 */
> -	if (plat->dma_rx_param) {
> -		host->dma_rx_channel = dma_request_channel(mask,
> -							   plat->dma_filter,
> -							   plat->dma_rx_param);
> +	if (plat->dma_rx_param || np) {
> +		host->dma_rx_channel = dma_request_slave_channel_compat(mask,
> +								plat->dma_filter,
> +								plat->dma_rx_param,
> +								&dev->dev, "rx");
>  		/* E.g if no DMA hardware is present */
>  		if (!host->dma_rx_channel)
>  			dev_err(mmc_dev(host->mmc), "no RX DMA channel\n");

I don't think this is right - I think Arnd has been leading you up the
garden path saying that this can be simplified.  Why?

If you look at what this code does, the DMA channels are optional.  If
they're not provided, then you don't get an error or a warning printk from
the code.  However, after your conversion, if you use DT and avoid giving
the DMA information (which you have to avoid on the majority of ARM
platforms) then "np" will be non-NULL, and
dma_request_slave_channel_compat() will return NULL, causing the error
and/or warning to be printed.

So, we really need to know whether the DMA channel information has been
provided in DT in the upper level "if" statement, and _not_ use
dma_request_slave_channel_compat().


From linux at arm.linux.org.uk  Thu Apr 18 04:18:12 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Thu, 18 Apr 2013 09:18:12 +0100
Subject: [PATCH v2] serial: pl011: Add Device Tree support to request
 DMA channels
In-Reply-To: <1366272857-14038-1-git-send-email-lee.jones@linaro.org>
References: <1366272857-14038-1-git-send-email-lee.jones@linaro.org>
Message-ID: <20130418081811.GF14496@n2100.arm.linux.org.uk>

On Thu, Apr 18, 2013 at 09:14:16AM +0100, Lee Jones wrote:
> @@ -269,7 +270,10 @@ static void pl011_dma_probe_initcall(struct uart_amba_port *uap)
>  	dma_cap_zero(mask);
>  	dma_cap_set(DMA_SLAVE, mask);
>  
> -	chan = dma_request_channel(mask, plat->dma_filter, plat->dma_tx_param);
> +	chan = dma_request_slave_channel_compat(mask,
> +				(plat) ? plat->dma_filter : NULL,
> +				(plat) ? plat->dma_tx_param : NULL,
> +				uap->port.dev, "tx");
>  	if (!chan) {
>  		dev_err(uap->port.dev, "no TX DMA channel!\n");
>  		return;

This suffers the same problem with your MMCI patch.  If you're using DT and
don't provide the DMA information, you get errors printed.  That's not on
for an optional driver feature, especially when that feature causes
functional difficulties on various platforms and so is _purposely_ omitted.


From santosh.shilimkar at ti.com  Thu Apr 18 04:22:32 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Thu, 18 Apr 2013 13:52:32 +0530
Subject: [PATCH] gpio/omap: ensure gpio context is initialised
In-Reply-To: <1366230707-32681-1-git-send-email-jon-hunter@ti.com>
References: <1366230707-32681-1-git-send-email-jon-hunter@ti.com>
Message-ID: <516FAD48.4020304@ti.com>

On Thursday 18 April 2013 02:01 AM, Jon Hunter wrote:
> Commit a2797be (gpio/omap: force restore if context loss is not
> detectable) broke gpio support for OMAP when booting with device-tree
> because a restore of the gpio context being performed without ever
> initialising the gpio context. In other words, the context restored was
> bad.
> 
> This problem could also occur in the non device-tree case, however, it
> is much less likely because when booting without device-tree we can
> detect context loss via a platform specific API and so context restore
> is performed less often.
> 
> Nevertheless we should ensure that the gpio context is initialised
> during the probe for gpio banks that could lose their state regardless
> of whether we are booting with device-tree or not.
> 
> Reported-by: Tony Lindgren <tony at atomide.com>
> Signed-off-by: Jon Hunter <jon-hunter at ti.com>
> Tested-by: Tony Lindgren <tony at atomide.com>
> ---
>  drivers/gpio/gpio-omap.c |   53 +++++++++++++++++++++++++++++++++++++---------
>  1 file changed, 43 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
> index 0557529..0ba5cb9 100644
> --- a/drivers/gpio/gpio-omap.c
> +++ b/drivers/gpio/gpio-omap.c
> @@ -70,6 +70,7 @@ struct gpio_bank {
>  	bool is_mpuio;
>  	bool dbck_flag;
>  	bool loses_context;
> +	bool context_valid;
>  	int stride;
>  	u32 width;
>  	int context_loss_count;
> @@ -1085,6 +1086,7 @@ static void omap_gpio_chip_init(struct gpio_bank *bank)
>  }
>  
>  static const struct of_device_id omap_gpio_match[];
> +static void omap_gpio_init_context(struct gpio_bank *p);
>  
>  static int omap_gpio_probe(struct platform_device *pdev)
>  {
> @@ -1179,8 +1181,10 @@ static int omap_gpio_probe(struct platform_device *pdev)
>  	omap_gpio_chip_init(bank);
>  	omap_gpio_show_rev(bank);
>  
> -	if (bank->loses_context)
> +	if (bank->loses_context) {
>  		bank->get_context_loss_count = pdata->get_context_loss_count;
> +		omap_gpio_init_context(bank);
> +	}
>  
>  	pm_runtime_put(bank->dev);
>  
> @@ -1269,6 +1273,14 @@ static int omap_gpio_runtime_resume(struct device *dev)
>  	int c;
>  
>  	spin_lock_irqsave(&bank->lock, flags);
> +
> +	/*
> +	 * On the first resume during the probe, the context has not
> +	 * been initialised and so if the context is not valid return.
> +	 */
> +	if (!bank->context_valid)
> +		goto done;
> +
The use of 'context_valid' is just for the probe resume case and hence
adding a state variable for GPIO bank structures looks bit too much.
Ideally gpio_init_context() should make the first callback successful
as well if ordered correctly but then you need clocks for that
to happen which are enabled in runtime pm calls. 

Do you really need that "context_valid" flag per bank ? I mean
every gpio bank which can "loses_context", probe time context
validity is an issue, right ? In that case, won't just an
__init static variable do for all banks which can loose
context?

Regards,
Santosh




From ulf.hansson at linaro.org  Thu Apr 18 04:21:14 2013
From: ulf.hansson at linaro.org (Ulf Hansson)
Date: Thu, 18 Apr 2013 10:21:14 +0200
Subject: [PATCH] mmc: mmci: Allow MMCI to request channels with
 information acquired from DT
In-Reply-To: <20130418080238.GB3137@gmail.com>
References: <1366205534-25079-1-git-send-email-lee.jones@linaro.org>
 <201304171550.56037.arnd@arndb.de>
 <20130417150437.GA3137@gmail.com>
 <201304171731.56292.arnd@arndb.de>
 <20130418080238.GB3137@gmail.com>
Message-ID: <CAPDyKFqHBYRRNFqKMdw4H73_o-v_sQ5ybGg3jZHqgNDg4zyB5w@mail.gmail.com>

On 18 April 2013 10:02, Lee Jones <lee.jones at linaro.org> wrote:
>> I think you can further simplify this, given that in the DT case we always
>> allocate a zeroed mmci_platform_data for host->plat, so !plat cannot happen
>> when we get here.
>
> Okay, third time lucky. :)
>
> diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
> index 372e921..3260ab4 100644
> --- a/drivers/mmc/host/mmci.c
> +++ b/drivers/mmc/host/mmci.c
> @@ -298,14 +298,16 @@ static void mmci_init_sg(struct mmci_host *host, struct mmc_data *data)
>   * no custom DMA interfaces are supported.
>   */
>  #ifdef CONFIG_DMA_ENGINE
> -static void mmci_dma_setup(struct mmci_host *host)
> +static void mmci_dma_setup(struct amba_device *dev,
> +                          struct mmci_host *host)

Hi Lee,

You don't need to pass the amba_device, this can be fetched from the
mmci_host. Check how other functions converts the mmci host it in this
driver.

Kind regards
Ulf Hansson

>  {
> +       struct device_node *np = dev->dev.of_node;
>         struct mmci_platform_data *plat = host->plat;
>         const char *rxname, *txname;
>         dma_cap_mask_t mask;
>
> -       if (!plat || !plat->dma_filter) {
> -               dev_info(mmc_dev(host->mmc), "no DMA platform data\n");
> +       if (!(plat->dma_filter || np)) {
> +               dev_info(mmc_dev(host->mmc), "no DMA platform data or DT\n");
>                 return;
>         }
>
> @@ -321,19 +323,21 @@ static void mmci_dma_setup(struct mmci_host *host)
>          * attempt to use it bidirectionally, however if it is
>          * is specified but cannot be located, DMA will be disabled.
>          */
> -       if (plat->dma_rx_param) {
> -               host->dma_rx_channel = dma_request_channel(mask,
> -                                                          plat->dma_filter,
> -                                                          plat->dma_rx_param);
> +       if (plat->dma_rx_param || np) {
> +               host->dma_rx_channel = dma_request_slave_channel_compat(mask,
> +                                                               plat->dma_filter,
> +                                                               plat->dma_rx_param,
> +                                                               &dev->dev, "rx");
>                 /* E.g if no DMA hardware is present */
>                 if (!host->dma_rx_channel)
>                         dev_err(mmc_dev(host->mmc), "no RX DMA channel\n");
>         }
>
> -       if (plat->dma_tx_param) {
> -               host->dma_tx_channel = dma_request_channel(mask,
> -                                                          plat->dma_filter,
> -                                                          plat->dma_tx_param);
> +       if (plat->dma_tx_param || np) {
> +               host->dma_tx_channel = dma_request_slave_channel_compat(mask,
> +                                                               plat->dma_filter,
> +                                                               plat->dma_tx_param,
> +                                                               &dev->dev, "tx");
>                 if (!host->dma_tx_channel)
>                         dev_warn(mmc_dev(host->mmc), "no TX DMA channel\n");
>         } else {
> @@ -1538,7 +1542,7 @@ static int mmci_probe(struct amba_device *dev,
>                  amba_rev(dev), (unsigned long long)dev->res.start,
>                  dev->irq[0], dev->irq[1]);
>
> -       mmci_dma_setup(host);
> +       mmci_dma_setup(dev, host);
>
>         pm_runtime_set_autosuspend_delay(&dev->dev, 50);
>         pm_runtime_use_autosuspend(&dev->dev);
>
> --
> Lee Jones
> Linaro ST-Ericsson Landing Team Lead
> Linaro.org ? Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


From santosh.shilimkar at ti.com  Thu Apr 18 04:27:24 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Thu, 18 Apr 2013 13:57:24 +0530
Subject: [V3 patch 03/19] ARM: OMAP3: remove cpuidle_wrap_enter
In-Reply-To: <1365770165-27096-4-git-send-email-daniel.lezcano@linaro.org>
References: <1365770165-27096-1-git-send-email-daniel.lezcano@linaro.org>
 <1365770165-27096-4-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <516FAE6C.3050002@ti.com>

On Friday 12 April 2013 06:05 PM, Daniel Lezcano wrote:
> In a previous commit the en_core_tk_irqen flag has been added but we missed
> the cpuidle_wrap_enter which was doing the job to measure the time for the
> 'omap3_enter_idle' function.
> 
> Actually, I don't see any reason to use this wrapper in the code. In the better
> case, the time computation is not correctly done because of the different
> operations done in omap3_enter_idle_bm which were not taken into account
> before the en_core_tk_irqen flag was set.
> 
> As the time is reflected for the state overridden by the omap3_enter_idle_bm,
> using the wrapper is pointless now, so removing it.
> 
> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
> ---
Acked-by: Santosh Shilimkar <santosh.shilimkar at ti.com>



From santosh.shilimkar at ti.com  Thu Apr 18 04:28:30 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Thu, 18 Apr 2013 13:58:30 +0530
Subject: [V3 patch 01/19] ARM: shmobile: cpuidle: remove shmobile_enter_wfi
 function
In-Reply-To: <1365770165-27096-2-git-send-email-daniel.lezcano@linaro.org>
References: <1365770165-27096-1-git-send-email-daniel.lezcano@linaro.org>
 <1365770165-27096-2-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <516FAEAE.1060201@ti.com>

On Friday 12 April 2013 06:05 PM, Daniel Lezcano wrote:
> Remove the shmobile_enter_wfi function which is the same as the
> common WFI enter function from the arm cpuidle driver defined
> with the ARM_CPUIDLE_WFI_STATE macro.
> 
> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
> ---
Acked-by: Santosh Shilimkar <santosh.shilimkar at ti.com>



From santosh.shilimkar at ti.com  Thu Apr 18 04:30:32 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Thu, 18 Apr 2013 14:00:32 +0530
Subject: [V3 patch 02/19] ARM: shmobile: cpuidle: remove shmobile_enter_wfi
 prototype
In-Reply-To: <1365770165-27096-3-git-send-email-daniel.lezcano@linaro.org>
References: <1365770165-27096-1-git-send-email-daniel.lezcano@linaro.org>
 <1365770165-27096-3-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <516FAF28.80002@ti.com>

On Friday 12 April 2013 06:05 PM, Daniel Lezcano wrote:
> Commit 688036b538974de32ce55be8b0e013b003992abc removed the function
> 'shmobile_enter_wfi' but we forgot to remove the definition in the header file.
> 
> Note this function is just an alias to 'cpu_do_idle()' wrapped into a cpuidle
> function callback prototype which already exists with the default WFI state
> and the arm_simple_enter function.
> 
> Remove the function prototype.
> 
> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
> ---
You can actually fold this into 1/19. No strong opinion though.




From peter.maydell at linaro.org  Thu Apr 18 04:30:52 2013
From: peter.maydell at linaro.org (Peter Maydell)
Date: Thu, 18 Apr 2013 09:30:52 +0100
Subject: [RFC] arm64: Early printk support for virtio-mmio console devices.
In-Reply-To: <ede8ee08bb2616c2ed642200e3357367@localhost>
References: <1366264344-28025-1-git-send-email-pranavkumar@linaro.org>
 <ede8ee08bb2616c2ed642200e3357367@localhost>
Message-ID: <CAFEAcA-38=zx-s3NaBAu-yvDNRbt=KcTs-3c1QJR3COB3G1n2A@mail.gmail.com>

On 18 April 2013 07:49, Marc Zyngier <maz at misterjones.org> wrote:
> If you need an early console, why not simply wire the 8250 emulation in
> kvmtool to be useable from the MMIO bus? I reckon this would solve your
> problem in a more elegant way...

The other approach I thought of would be something involving
defining a hypercall interface for console I/O, in the same
way that we have hypercalls for "start cpu"/"stop cpu"/etc.
Is there any mileage in considering that approach, or is it
a non-starter?

thanks
-- PMM


From santosh.shilimkar at ti.com  Thu Apr 18 04:38:12 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Thu, 18 Apr 2013 14:08:12 +0530
Subject: [V3 patch 05/19] ARM: ux500: cpuidle: replace for_each_online_cpu
 by for_each_possible_cpu
In-Reply-To: <1365770165-27096-6-git-send-email-daniel.lezcano@linaro.org>
References: <1365770165-27096-1-git-send-email-daniel.lezcano@linaro.org>
 <1365770165-27096-6-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <516FB0F4.5020109@ti.com>

On Friday 12 April 2013 06:05 PM, Daniel Lezcano wrote:
> All the drivers are using, in their initialization function, the
> for_each_possible_cpu macro.
> 
> Using for_each_online_cpu means the driver must handle the initialization
> of the cpuidle device when a cpu is up which is not the case here.
> 
> Change the macro to for_each_possible_cpu as that fix the hotplug
> initialization and make the initialization routine consistent with the
> rest of the code in the different drivers.
> 
> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
> ---
>  arch/arm/mach-ux500/cpuidle.c |    4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/mach-ux500/cpuidle.c b/arch/arm/mach-ux500/cpuidle.c
> index c29c1bf..5657d4a 100644
> --- a/arch/arm/mach-ux500/cpuidle.c
> +++ b/arch/arm/mach-ux500/cpuidle.c
> @@ -125,7 +125,7 @@ int __init ux500_idle_init(void)
>  		return ret;
>  	}
>  
> -	for_each_online_cpu(cpu) {
> +	for_each_possible(cpu) {
There should no problem with online_cpu() usage
as well as long as one is not limmiting number of
boot CPUs using the max_cpus option.

But I agree making possible_cpu() would take care
of that case as well.

Regards,
Santosh



From mfuzzey at parkeon.com  Thu Apr 18 04:36:53 2013
From: mfuzzey at parkeon.com (Martin Fuzzey)
Date: Thu, 18 Apr 2013 10:36:53 +0200
Subject: [PATCH V2] ARM: i.MX5: Allow DT clock providers
In-Reply-To: <20130418063056.GA20566@S2101-09.ap.freescale.net>
References: <20130415080741.20173.70704.stgit@localhost>
 <20130418063056.GA20566@S2101-09.ap.freescale.net>
Message-ID: <516FB0A5.9050903@parkeon.com>

On 18/04/13 08:30, Shawn Guo wrote:
> +static struct clk * __init mx5_obtain_fixed_clock_from_dt(const char *name)
> +{
> +#ifdef CONFIG_OF
> We have selected USE_OF at the sub-architecture level, so the ifdef
> plays nothing here.
Ah ok so what happens on non DT platforms (looks like Babbage)
Does this mean that there is an empty DT in that case?

I was going by the existing code which already has this #ifdef

>> +	struct of_phandle_args phandle = {0};
>> +	struct clk *clk = ERR_PTR(-ENODEV);
>> +	char *compatible;
>> +
>> +	compatible = kasprintf(GFP_KERNEL, "fsl,imx-%s", name);
> What about finding the node by path as below?
>
> 	path = kasprintf(GFP_KERNEL, "/clocks/%s", name);
> 	phandle.np = of_find_node_by_path(path);
>
> I have to admit that those imx custom compatibles for fixed-clock
> shouldn't necessarily be there at all.  Let's stop spreading the use.
I can't find anything in the DT binding documentation that says the 
clocks have to be
under /clocks  (but then again the fsl,imx- compatible string isn't 
documented either).

My understanding of DT is that the absolute node path is generally 
unimportant with
the exception of a few special nodes like /, /memory, /chosen

But I don't have a strong opinion on this - if the consensus is that 
path based lookup
is better I'll do that.

Regards,

Martin



From lee.jones at linaro.org  Thu Apr 18 04:39:22 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Thu, 18 Apr 2013 09:39:22 +0100
Subject: [PATCH v2] serial: pl011: Add Device Tree support to request DMA
 channels
In-Reply-To: <20130418081811.GF14496@n2100.arm.linux.org.uk>
References: <1366272857-14038-1-git-send-email-lee.jones@linaro.org>
 <20130418081811.GF14496@n2100.arm.linux.org.uk>
Message-ID: <20130418083922.GC3137@gmail.com>

On Thu, 18 Apr 2013, Russell King - ARM Linux wrote:

> On Thu, Apr 18, 2013 at 09:14:16AM +0100, Lee Jones wrote:
> > @@ -269,7 +270,10 @@ static void pl011_dma_probe_initcall(struct uart_amba_port *uap)
> >  	dma_cap_zero(mask);
> >  	dma_cap_set(DMA_SLAVE, mask);
> >  
> > -	chan = dma_request_channel(mask, plat->dma_filter, plat->dma_tx_param);
> > +	chan = dma_request_slave_channel_compat(mask,
> > +				(plat) ? plat->dma_filter : NULL,
> > +				(plat) ? plat->dma_tx_param : NULL,
> > +				uap->port.dev, "tx");
> >  	if (!chan) {
> >  		dev_err(uap->port.dev, "no TX DMA channel!\n");
> >  		return;
> 
> This suffers the same problem with your MMCI patch.  If you're using DT and
> don't provide the DMA information, you get errors printed.  That's not on
> for an optional driver feature, especially when that feature causes
> functional difficulties on various platforms and so is _purposely_ omitted.

How does that differ from using pdata and not passing DMA information?

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From agraf at suse.de  Thu Apr 18 04:44:32 2013
From: agraf at suse.de (Alexander Graf)
Date: Thu, 18 Apr 2013 10:44:32 +0200
Subject: [RFC] arm64: Early printk support for virtio-mmio console devices.
In-Reply-To: <CAAHg+HiHKV+8hBT1QWe4hSxocCX6wpRd3bCPWB7zU8jVFmPuAA@mail.gmail.com>
References: <1366264344-28025-1-git-send-email-pranavkumar@linaro.org>
 <87wqs02uws.fsf@rustcorp.com.au>
 <CAAHg+HiHKV+8hBT1QWe4hSxocCX6wpRd3bCPWB7zU8jVFmPuAA@mail.gmail.com>
Message-ID: <47354634-CA37-47E3-99D2-D4DDB08A9870@suse.de>



Am 18.04.2013 um 09:32 schrieb Pranavkumar Sawargaonkar <pranavkumar at linaro.org>:

> On 18 April 2013 12:21, Rusty Russell <rusty at rustcorp.com.au> wrote:
>> 
>> PranavkumarSawargaonkar <pranavkumar at linaro.org> writes:
>>> From: Pranavkumar Sawargaonkar <pranavkumar at linaro.org>
>>> 
>>> This patch implements early printk support for virtio-mmio console devices without using any hypercalls.
>> 
>> This makes some sense, though not sure that early console *read* makes
>> much sense.  I can see the PCI version of this being useful as well.
> 
> Read can be useful for "mach-virt" which will have only virtio console
> as a console device. Then if someone wants to have UEFI or any other
> boot-loader emulation, which expects user to input few things, in that
> case read might become handy.

A boot loader should easily be able to implement virtio-console for real.

In fact, you should be able to do a simple virtio-console implementation for early printk too, that polls the host for acks rather than use interrupts. Check out my s390-zipl code for reference. I use that there.

The advantage to that would be that no host changes are required whatsoever and the interface strictly stays as it is.


Alex



From santosh.shilimkar at ti.com  Thu Apr 18 04:48:29 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Thu, 18 Apr 2013 14:18:29 +0530
Subject: [V3 patch 06/19] cpuidle: make a single register function for all
In-Reply-To: <1365770165-27096-7-git-send-email-daniel.lezcano@linaro.org>
References: <1365770165-27096-1-git-send-email-daniel.lezcano@linaro.org>
 <1365770165-27096-7-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <516FB35D.7000303@ti.com>

On Friday 12 April 2013 06:05 PM, Daniel Lezcano wrote:
> The usual scheme to initialize a cpuidle driver on a SMP is:
> 
> 	cpuidle_register_driver(drv);
> 	for_each_possible_cpu(cpu) {
> 		device = &per_cpu(cpuidle_dev, cpu);
> 		cpuidle_register_device(device);
> 	}
> 
Not exactly related to $subject patch but the driver should
be registered after all devices has been registered to avoid
devices start using the idle state data as soon as it is
registered. In multi CPU system, this race can easily happen.

Current CPUIDLE core layer is also written with the assumption
that driver will be registered first and then the devices which
is not mandatory as per typical drive/device model.

May be you can fix that part while you are creating this common
wrapper.

> This code is duplicated in each cpuidle driver.
> 
> On UP systems, it is done this way:
> 
> 	cpuidle_register_driver(drv);
> 	device = &per_cpu(cpuidle_dev, cpu);
> 	cpuidle_register_device(device);
> 
> On UP, the macro 'for_each_cpu' does one iteration:
> 
> #define for_each_cpu(cpu, mask)                 \
>         for ((cpu) = 0; (cpu) < 1; (cpu)++, (void)mask)
> 
> Hence, the initialization loop is the same for UP than SMP.
> 
> Beside, we saw different bugs / mis-initialization / return code unchecked in
> the different drivers, the code is duplicated including bugs. After fixing all
> these ones, it appears the initialization pattern is the same for everyone.
> 
> Please note, some drivers are doing dev->state_count = drv->state_count. This is
> not necessary because it is done by the cpuidle_enable_device function in the
> cpuidle framework. This is true, until you have the same states for all your
> devices. Otherwise, the 'low level' API should be used instead with the specific
> initialization for the driver.
> 
> Let's add a wrapper function doing this initialization with a cpumask parameter
> for the coupled idle states and use it for all the drivers.
> 
> That will save a lot of LOC, consolidate the code, and the modifications in the
> future could be done in a single place. Another benefit is the consolidation of
> the cpuidle_device variable which is now in the cpuidle framework and no longer
> spread accross the different arch specific drivers.
> 
s/accross/across

> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
> ---
>  Documentation/cpuidle/driver.txt |    6 ++++
>  drivers/cpuidle/cpuidle.c        |   72 ++++++++++++++++++++++++++++++++++++++
>  include/linux/cpuidle.h          |    9 +++--
>  3 files changed, 85 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/cpuidle/driver.txt b/Documentation/cpuidle/driver.txt
> index 7a9e09e..1b0d81d 100644
> --- a/Documentation/cpuidle/driver.txt
> +++ b/Documentation/cpuidle/driver.txt
> @@ -15,11 +15,17 @@ has mechanisms in place to support actual entry-exit into CPU idle states.
>  cpuidle driver initializes the cpuidle_device structure for each CPU device
>  and registers with cpuidle using cpuidle_register_device.
>  
> +If all the idle states are the same, the wrapper function cpuidle_register
> +could be used instead.
> +
>  It can also support the dynamic changes (like battery <-> AC), by using
>  cpuidle_pause_and_lock, cpuidle_disable_device and cpuidle_enable_device,
>  cpuidle_resume_and_unlock.
>  
>  Interfaces:
> +extern int cpuidle_register(struct cpuidle_driver *drv,
> +                            const struct cpumask *const coupled_cpus);
> +extern int cpuidle_unregister(struct cpuidle_driver *drv);
>  extern int cpuidle_register_driver(struct cpuidle_driver *drv);
>  extern void cpuidle_unregister_driver(struct cpuidle_driver *drv);
>  extern int cpuidle_register_device(struct cpuidle_device *dev);
> diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
> index 0da795b..49e8d30 100644
> --- a/drivers/cpuidle/cpuidle.c
> +++ b/drivers/cpuidle/cpuidle.c
> @@ -24,6 +24,7 @@
>  #include "cpuidle.h"
>  
>  DEFINE_PER_CPU(struct cpuidle_device *, cpuidle_devices);
> +DEFINE_PER_CPU(struct cpuidle_device, cpuidle_dev);
>  
>  DEFINE_MUTEX(cpuidle_lock);
>  LIST_HEAD(cpuidle_detected_devices);
> @@ -453,6 +454,77 @@ void cpuidle_unregister_device(struct cpuidle_device *dev)
>  
>  EXPORT_SYMBOL_GPL(cpuidle_unregister_device);
>  
> +/*
s/*/**
> + * cpuidle_unregister: unregister a driver and the devices. This function
> + * can be used only if the driver has been previously registered through
> + * the cpuidle_register function.
> + *
> + * @drv: a valid pointer to a struct cpuidle_driver
> + */
> +void cpuidle_unregister(struct cpuidle_driver *drv)
> +{
> +	int cpu;
> +	struct cpuidle_device *device;
> +
> +	for_each_possible_cpu(cpu) {
> +		device = &per_cpu(cpuidle_dev, cpu);
> +		cpuidle_unregister_device(device);
> +	}
> +
> +	cpuidle_unregister_driver(drv);
> +}
> +EXPORT_SYMBOL_GPL(cpuidle_unregister);
> +
> +/**
> + * cpuidle_register: registers the driver and the cpu devices with the
> + * coupled_cpus passed as parameter. This function is used for all common
> + * initialization pattern there are in the arch specific drivers. The
> + * devices is globally defined in this file.
> + *
> + * @drv         : a valid pointer to a struct cpuidle_driver
> + * @coupled_cpus: a cpumask for the coupled states
> + *
> + * Returns 0 on success, < 0 otherwise
> + */
> +int cpuidle_register(struct cpuidle_driver *drv,
> +		     const struct cpumask *const coupled_cpus)
> +{
> +	int ret, cpu;
> +	struct cpuidle_device *device;
> +
> +	ret = cpuidle_register_driver(drv);
> +	if (ret) {
> +		pr_err("failed to register cpuidle driver\n");
> +		return ret;
> +	}
> +
> +	for_each_possible_cpu(cpu) {
> +		device = &per_cpu(cpuidle_dev, cpu);
> +		device->cpu = cpu;
> +
> +#ifdef CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED
> +		/*
> +		 * On multiplatform for ARM, the coupled idle states could
> +		 * enabled in the kernel even if the cpuidle driver does not
> +		 * use it. Note, coupled_cpus is a struct copy.
> +		 */
> +		if (coupled_cpus)
> +			device->coupled_cpus = *coupled_cpus;
> +#endif
Can we get rid off the need of wrapping the code under CONFIG
marco in middle of function ?

> +		ret = cpuidle_register_device(device);
> +		if (!ret)
> +			continue;
> +
> +		pr_err("Failed to register cpuidle device for cpu%d\n", cpu);
> +
> +		cpuidle_unregister(drv);
> +		break;
> +	}
> +
> +	return ret;
> +}
> +EXPORT_SYMBOL_GPL(cpuidle_register);
> +
>  #ifdef CONFIG_SMP
>  
>  static void smp_callback(void *v)
> diff --git a/include/linux/cpuidle.h b/include/linux/cpuidle.h
> index 79e3811..3c86faa 100644
> --- a/include/linux/cpuidle.h
> +++ b/include/linux/cpuidle.h
> @@ -123,7 +123,9 @@ extern void cpuidle_driver_unref(void);
>  extern void cpuidle_unregister_driver(struct cpuidle_driver *drv);
>  extern int cpuidle_register_device(struct cpuidle_device *dev);
>  extern void cpuidle_unregister_device(struct cpuidle_device *dev);
> -
> +extern int cpuidle_register(struct cpuidle_driver *drv,
> +			    const struct cpumask *const coupled_cpus);
> +extern void cpuidle_unregister(struct cpuidle_driver *drv);
>  extern void cpuidle_pause_and_lock(void);
>  extern void cpuidle_resume_and_unlock(void);
>  extern void cpuidle_pause(void);
> @@ -148,7 +150,10 @@ static inline void cpuidle_unregister_driver(struct cpuidle_driver *drv) { }
>  static inline int cpuidle_register_device(struct cpuidle_device *dev)
>  {return -ENODEV; }
>  static inline void cpuidle_unregister_device(struct cpuidle_device *dev) { }
> -
> +static inline int cpuidle_register(struct cpuidle_driver *drv,
> +				   const struct cpumask *const coupled_cpus)
> +{return -ENODEV; }
> +static inline void cpuidle_unregister(struct cpuidle_driver *drv) { }
>  static inline void cpuidle_pause_and_lock(void) { }
>  static inline void cpuidle_resume_and_unlock(void) { }
>  static inline void cpuidle_pause(void) { }
> 



From santosh.shilimkar at ti.com  Thu Apr 18 04:49:57 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Thu, 18 Apr 2013 14:19:57 +0530
Subject: [V3 patch 09/19] ARM: OMAP3: cpuidle: use init/exit common routine
In-Reply-To: <1365770165-27096-10-git-send-email-daniel.lezcano@linaro.org>
References: <1365770165-27096-1-git-send-email-daniel.lezcano@linaro.org>
 <1365770165-27096-10-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <516FB3B5.8050908@ti.com>

On Friday 12 April 2013 06:05 PM, Daniel Lezcano wrote:
> Remove the duplicated code and use the cpuidle common code for initialization.
> 
> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
> ---
Acked-by: Santosh Shilimkar <santosh.shilimkar at ti.com>



From santosh.shilimkar at ti.com  Thu Apr 18 04:50:42 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Thu, 18 Apr 2013 14:20:42 +0530
Subject: [V3 patch 13/19] ARM: OMAP4: cpuidle: use init/exit common routine
In-Reply-To: <1365770165-27096-14-git-send-email-daniel.lezcano@linaro.org>
References: <1365770165-27096-1-git-send-email-daniel.lezcano@linaro.org>
 <1365770165-27096-14-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <516FB3E2.30106@ti.com>

On Friday 12 April 2013 06:05 PM, Daniel Lezcano wrote:
> Remove the duplicated code and use the cpuidle common code for initialization.
> 
> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
> ---
Acked-by: Santosh Shilimkar <santosh.shilimkar at ti.com>



From pranavkumar at linaro.org  Thu Apr 18 04:48:49 2013
From: pranavkumar at linaro.org (Pranavkumar Sawargaonkar)
Date: Thu, 18 Apr 2013 14:18:49 +0530
Subject: [RFC] arm64: Early printk support for virtio-mmio console devices.
In-Reply-To: <bb1193983de3ea9f4df1a570441df34c@localhost>
References: <1366264344-28025-1-git-send-email-pranavkumar@linaro.org>
 <ede8ee08bb2616c2ed642200e3357367@localhost>
 <CAAHg+HhajHFC=1nh6YQNgpf=Na2FqcsYJ=t+ag9QiTg6TxUz9w@mail.gmail.com>
 <bb1193983de3ea9f4df1a570441df34c@localhost>
Message-ID: <CAAHg+HhtCorArCmx=ha0=64+SJZiizzrDUKSPLV=N+OzO8zAxQ@mail.gmail.com>

Hi Marc,

On 18 April 2013 13:06, Marc Zyngier <marc.zyngier at arm.com> wrote:
> On Thu, 18 Apr 2013 12:47:18 +0530, Pranavkumar Sawargaonkar
> <pranavkumar at linaro.org> wrote:
>> Hi Marc,
>>
>> On 18 April 2013 12:19, Marc Zyngier <maz at misterjones.org> wrote:
>>
>>> Hi Pranavkumar,
>>>
>>> On Thu, 18 Apr 2013 11:22:24 +0530, PranavkumarSawargaonkar
>>> <pranavkumar at linaro.org> wrote:
>>> > From: Pranavkumar Sawargaonkar <pranavkumar at linaro.org>
>>> >
>>> > This patch implements early printk support for virtio-mmio console
>>> devices
>>> > without using any hypercalls.
>>> >
>>> > The current virtio early printk code in kernel expects that
> hypervisor
>>> > will provide some mechanism generally a hypercall to support early
>>> printk.
>>> > This patch does not break existing hypercall based early print
> support.
>>> >
>>> > This implementation adds:
>>> > 1. Early read-write register named early_rw in virtio console's
> config
>>> > space.
>>> > 2. Two host feature flags namely VIRTIO_CONSOLE_F_EARLY_READ and
>>> > VIRTIO_CONSOLE_F_EARLY_WRITE for telling guest about early-read and
>>> > early-write capability in console device.
>>> >
>>> > Early write mechanism:
>>> > 1. When a guest wants to out some character, it has to simply write
> the
>>> > character to early_rw register in config space of virtio console
>>> > device.
>>> >
>>> > Early read mechanism:
>>> > 1. When a guest wants to in some character, it has to simply read the
>>> > early_rw register in config space of virtio console device. Lets say
> we
>>> get
>>> > 32-bit value X.
>>> > 2. If most significant bit of X is set (i.e. X & 0x80000000 ==
>>> 0x80000000)
>>> > then least significant 8 bits of X represents input charaacter else
>>> guest
>>> > need to try again reading early_rw register.
>>> >
>>> > Note: This patch only includes kernel side changes for early printk,
>>> > the
>>> > host/hypervisor side emulation of early_rw register is out of scope
>>> here.
>>>
>>> Well, that's unfortunate, as it makes it quite difficult to understand
>>> the
>>> impact of this patch.
>>> Has the virtio side been posted somewhere? I expect you've implemented
>>> something in kvmtool...
>>>
>>
>> Yes i have implemented kvmtool side also and code change is really small
>> (not really a clean code currently)
>> I can post it also but since it is specific to kvmtool i have not posted
> it
>> with rfc.
>
> Doesn't really if the code needs some rework at this point (I expect the
> patch to be fairly small indeed). Any chance you could post it to the KVM
> list?
Yeah patch is very small, i will post it on kvm list. I have tested
patch on foundation model.
>
>>>
>>> > Signed-off-by: Anup Patel <anup.patel at linaro.org>
>>> > ---
>>> >  arch/arm64/kernel/early_printk.c    |   24 ++++++++++++++++++++++++
>>> >  include/uapi/linux/virtio_console.h |    4 ++++
>>> >  2 files changed, 28 insertions(+)
>>> >
>>> > diff --git a/arch/arm64/kernel/early_printk.c
>>> > b/arch/arm64/kernel/early_printk.c
>>> > index ac974f4..a82b5aa 100644
>>> > --- a/arch/arm64/kernel/early_printk.c
>>> > +++ b/arch/arm64/kernel/early_printk.c
>>> > @@ -25,6 +25,9 @@
>>> >
>>> >  #include <linux/amba/serial.h>
>>> >  #include <linux/serial_reg.h>
>>> > +#include <linux/virtio_ids.h>
>>> > +#include <linux/virtio_mmio.h>
>>> > +#include <linux/virtio_console.h>
>>> >
>>> >  static void __iomem *early_base;
>>> >  static void (*printch)(char ch);
>>> > @@ -53,6 +56,26 @@ static void smh_printch(char ch)
>>> >  }
>>> >
>>> >  /*
>>> > + * VIRTIO MMIO based debug console.
>>> > + */
>>> > +static void virtio_console_early_printch(char ch)
>>> > +{
>>> > +     u32 tmp;
>>> > +     struct virtio_console_config *p = early_base +
>>> > VIRTIO_MMIO_CONFIG;
>>> > +
>>> > +     tmp = readl_relaxed(early_base + VIRTIO_MMIO_DEVICE_ID);
>>> > +     if (tmp != VIRTIO_ID_CONSOLE) {
>>> > +             return;
>>> > +     }
>>> > +
>>> > +     tmp = readl_relaxed(early_base + VIRTIO_MMIO_HOST_FEATURES);
>>> > +     if (!(tmp & (1 << VIRTIO_CONSOLE_F_EARLY_WRITE))) {
>>> > +             return;
>>> > +     }
>>> > +     writeb_relaxed(ch, &p->early_rw);
>>>
>>> So here, you end up trapping 3 times per character being output on the
>>> console. Surely there's a better way. How about remembering the result
> of
>>> these tests in a static variable?
>>>
>> Yeah surely it is a better idea to remember using static variable, so
> that
>> after initialize once, it will trap only one time.
>
> Also, would it be possible to directly get the base address from DT? It
> would save having to pass the address (which is not known before runtime in
> the case of kvmtool). Not sure if it is available that early though...

Early printk code initializes earlier (from  parse_early_param in
arch/arm64/setup.c) than fdt un-flattened call (unflatten_device_tree)
. Hence using dts to pass this is not possible for passing the
address.

>
>>>
>>> > +}
>>> > +
>>> > +/*
>>> >   * 8250/16550 (8-bit aligned registers) single character TX.
>>> >   */
>>> >  static void uart8250_8bit_printch(char ch)
>>> > @@ -82,6 +105,7 @@ static const struct earlycon_match
> earlycon_match[]
>>> > __initconst = {
>>> >       { .name = "smh", .printch = smh_printch, },
>>> >       { .name = "uart8250-8bit", .printch = uart8250_8bit_printch, },
>>> >       { .name = "uart8250-32bit", .printch = uart8250_32bit_printch,
> },
>>> > +     { .name = "virtio-console", .printch =
>>> virtio_console_early_printch,
>>> },
>>> >       {}
>>> >  };
>>> >
>>> > diff --git a/include/uapi/linux/virtio_console.h
>>> > b/include/uapi/linux/virtio_console.h
>>> > index ee13ab6..1171cb4 100644
>>> > --- a/include/uapi/linux/virtio_console.h
>>> > +++ b/include/uapi/linux/virtio_console.h
>>> > @@ -38,6 +38,8 @@
>>> >  /* Feature bits */
>>> >  #define VIRTIO_CONSOLE_F_SIZE        0       /* Does host provide
>>> console size? */
>>> >  #define VIRTIO_CONSOLE_F_MULTIPORT 1 /* Does host provide multiple
>>> ports?
>>> >  */
>>> > +#define VIRTIO_CONSOLE_F_EARLY_READ 2        /* Does host support
>>> > early
>>> read?
>>> */
>>> > +#define VIRTIO_CONSOLE_F_EARLY_WRITE 3       /* Does host support
>>> > early
>>> write?
>>> > */
>>> >
>>> >  #define VIRTIO_CONSOLE_BAD_ID                (~(u32)0)
>>> >
>>> > @@ -48,6 +50,8 @@ struct virtio_console_config {
>>> >       __u16 rows;
>>> >       /* max. number of ports this device can hold */
>>> >       __u32 max_nr_ports;
>>> > +     /* early read/write register */
>>> > +     __u32 early_rw;
>>> >  } __attribute__((packed));
>>> >
>>> >  /*
>>>
>>> So that bit is clearly a spec change. How does it work with PCI, or any
>>> other virtio transport?
>>>
>> I am not sure about PCI hence just posted for MMIO.
>>
>>>
>>> Overall, I'm a bit concerned with adding features that don't really
> match
>>> the way virtio is supposed to work. The whole goal of virtio is to
>>> minimize
>>> the amount of trapping, and here you end up trapping on each and every
>>> access.
>>>
>>> If you need an early console, why not simply wire the 8250 emulation in
>>> kvmtool to be useable from the MMIO bus? I reckon this would solve your
>>> problem in a more elegant way...
>>>
>> Emulation will solve the issue but having a virtio early read or write
> has
>> one more advantage i.e.
>> In case of mach-virt we might need early read-write support for virtio
>> console to see if kernel is not panic before actual virtio drivers takes
>> control.
>> Also if someone wants to have UEFI or uboot running on mach-virt then we
>> also need early input facility in virtio console.
>
> That's exactly why I was suggesting using the 8250 emulation. It is
> supported by everything under the sun. I do not immediately see what the
> gain is with this virtio approach, as compared to 8250 emulation.
>
> Don't misunderstand me, I like the idea of having a virtio-only system,
Definitely not.
> specially if we can make it work with other transports. I just want to
> outline that there may be a simpler way for your particular use case.

Actually i thought adding a config register will be easier to add a
code than writing entire emulation as 8250 emulation will require to
deal with dealing with more registers and more code.

Thanks,
Pranav

>
> Thanks,
>
>         M.
> --
> Fast, cheap, reliable. Pick two.


From agraf at suse.de  Thu Apr 18 04:51:14 2013
From: agraf at suse.de (Alexander Graf)
Date: Thu, 18 Apr 2013 10:51:14 +0200
Subject: [RFC] arm64: Early printk support for virtio-mmio console devices.
In-Reply-To: <CAFEAcA-38=zx-s3NaBAu-yvDNRbt=KcTs-3c1QJR3COB3G1n2A@mail.gmail.com>
References: <1366264344-28025-1-git-send-email-pranavkumar@linaro.org>
 <ede8ee08bb2616c2ed642200e3357367@localhost>
 <CAFEAcA-38=zx-s3NaBAu-yvDNRbt=KcTs-3c1QJR3COB3G1n2A@mail.gmail.com>
Message-ID: <7C17A12D-F7C5-48ED-8D2F-22D8A7F289E3@suse.de>



Am 18.04.2013 um 10:30 schrieb Peter Maydell <peter.maydell at linaro.org>:

> On 18 April 2013 07:49, Marc Zyngier <maz at misterjones.org> wrote:
>> If you need an early console, why not simply wire the 8250 emulation in
>> kvmtool to be useable from the MMIO bus? I reckon this would solve your
>> problem in a more elegant way...
> 
> The other approach I thought of would be something involving
> defining a hypercall interface for console I/O, in the same
> way that we have hypercalls for "start cpu"/"stop cpu"/etc.
> Is there any mileage in considering that approach, or is it
> a non-starter?

It's exactly what we had for the s390-virtio machine. Virtio-console as console device plus a hypercall for early printk.

It was a mess.

Trying to inject character output that lands in machine context, where hypercalls get handled, inside of a specific virtio-console device, which owns the char output, is hard. We haven't found any good solution in qemu to layer this properly.

The closest approach to something workable was to create 2 char outputs and mux them together, like you usually would mus monitor and serial. Good luck muxing that one again with the monitor :).

I'd rather spare you guys from going through the same pain.


Alex



From marc.zyngier at arm.com  Thu Apr 18 04:51:43 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu, 18 Apr 2013 10:51:43 +0200
Subject: [RFC] arm64: Early printk support for virtio-mmio console devices.
In-Reply-To: <CAFEAcA-38=zx-s3NaBAu-yvDNRbt=KcTs-3c1QJR3COB3G1n2A@mail.gmail.com>
References: <1366264344-28025-1-git-send-email-pranavkumar@linaro.org>
 <ede8ee08bb2616c2ed642200e3357367@localhost>
 <CAFEAcA-38=zx-s3NaBAu-yvDNRbt=KcTs-3c1QJR3COB3G1n2A@mail.gmail.com>
Message-ID: <b67c5c681ce96942c3cc3bd05b8c80d2@localhost>

On Thu, 18 Apr 2013 09:30:52 +0100, Peter Maydell
<peter.maydell at linaro.org> wrote:
> On 18 April 2013 07:49, Marc Zyngier <maz at misterjones.org> wrote:
>> If you need an early console, why not simply wire the 8250 emulation in
>> kvmtool to be useable from the MMIO bus? I reckon this would solve your
>> problem in a more elegant way...
> 
> The other approach I thought of would be something involving
> defining a hypercall interface for console I/O, in the same
> way that we have hypercalls for "start cpu"/"stop cpu"/etc.
> Is there any mileage in considering that approach, or is it
> a non-starter?

That's always possible, but that becomes architecture dependent, which
means code duplication across architectures. I'd rather use the MMIO
infrastructure, which has some commonalities across the board.

        M.
-- 
Fast, cheap, reliable. Pick two.


From agraf at suse.de  Thu Apr 18 04:53:58 2013
From: agraf at suse.de (Alexander Graf)
Date: Thu, 18 Apr 2013 10:53:58 +0200
Subject: [RFC] arm64: Early printk support for virtio-mmio console devices.
In-Reply-To: <CAAHg+HhtCorArCmx=ha0=64+SJZiizzrDUKSPLV=N+OzO8zAxQ@mail.gmail.com>
References: <1366264344-28025-1-git-send-email-pranavkumar@linaro.org>
 <ede8ee08bb2616c2ed642200e3357367@localhost>
 <CAAHg+HhajHFC=1nh6YQNgpf=Na2FqcsYJ=t+ag9QiTg6TxUz9w@mail.gmail.com>
 <bb1193983de3ea9f4df1a570441df34c@localhost>
 <CAAHg+HhtCorArCmx=ha0=64+SJZiizzrDUKSPLV=N+OzO8zAxQ@mail.gmail.com>
Message-ID: <96D4393D-E2FF-4967-A608-FCEBD169D77D@suse.de>



Am 18.04.2013 um 10:48 schrieb Pranavkumar Sawargaonkar <pranavkumar at linaro.org>:

> Hi Marc,
> 
> On 18 April 2013 13:06, Marc Zyngier <marc.zyngier at arm.com> wrote:
>> On Thu, 18 Apr 2013 12:47:18 +0530, Pranavkumar Sawargaonkar
>> <pranavkumar at linaro.org> wrote:
>>> Hi Marc,
>>> 
>>> On 18 April 2013 12:19, Marc Zyngier <maz at misterjones.org> wrote:
>>> 
>>>> Hi Pranavkumar,
>>>> 
>>>> On Thu, 18 Apr 2013 11:22:24 +0530, PranavkumarSawargaonkar
>>>> <pranavkumar at linaro.org> wrote:
>>>>> From: Pranavkumar Sawargaonkar <pranavkumar at linaro.org>
>>>>> 
>>>>> This patch implements early printk support for virtio-mmio console
>>>> devices
>>>>> without using any hypercalls.
>>>>> 
>>>>> The current virtio early printk code in kernel expects that
>> hypervisor
>>>>> will provide some mechanism generally a hypercall to support early
>>>> printk.
>>>>> This patch does not break existing hypercall based early print
>> support.
>>>>> 
>>>>> This implementation adds:
>>>>> 1. Early read-write register named early_rw in virtio console's
>> config
>>>>> space.
>>>>> 2. Two host feature flags namely VIRTIO_CONSOLE_F_EARLY_READ and
>>>>> VIRTIO_CONSOLE_F_EARLY_WRITE for telling guest about early-read and
>>>>> early-write capability in console device.
>>>>> 
>>>>> Early write mechanism:
>>>>> 1. When a guest wants to out some character, it has to simply write
>> the
>>>>> character to early_rw register in config space of virtio console
>>>>> device.
>>>>> 
>>>>> Early read mechanism:
>>>>> 1. When a guest wants to in some character, it has to simply read the
>>>>> early_rw register in config space of virtio console device. Lets say
>> we
>>>> get
>>>>> 32-bit value X.
>>>>> 2. If most significant bit of X is set (i.e. X & 0x80000000 ==
>>>> 0x80000000)
>>>>> then least significant 8 bits of X represents input charaacter else
>>>> guest
>>>>> need to try again reading early_rw register.
>>>>> 
>>>>> Note: This patch only includes kernel side changes for early printk,
>>>>> the
>>>>> host/hypervisor side emulation of early_rw register is out of scope
>>>> here.
>>>> 
>>>> Well, that's unfortunate, as it makes it quite difficult to understand
>>>> the
>>>> impact of this patch.
>>>> Has the virtio side been posted somewhere? I expect you've implemented
>>>> something in kvmtool...
>>> 
>>> Yes i have implemented kvmtool side also and code change is really small
>>> (not really a clean code currently)
>>> I can post it also but since it is specific to kvmtool i have not posted
>> it
>>> with rfc.
>> 
>> Doesn't really if the code needs some rework at this point (I expect the
>> patch to be fairly small indeed). Any chance you could post it to the KVM
>> list?
> Yeah patch is very small, i will post it on kvm list. I have tested
> patch on foundation model.
>> 
>>>> 
>>>>> Signed-off-by: Anup Patel <anup.patel at linaro.org>
>>>>> ---
>>>>> arch/arm64/kernel/early_printk.c    |   24 ++++++++++++++++++++++++
>>>>> include/uapi/linux/virtio_console.h |    4 ++++
>>>>> 2 files changed, 28 insertions(+)
>>>>> 
>>>>> diff --git a/arch/arm64/kernel/early_printk.c
>>>>> b/arch/arm64/kernel/early_printk.c
>>>>> index ac974f4..a82b5aa 100644
>>>>> --- a/arch/arm64/kernel/early_printk.c
>>>>> +++ b/arch/arm64/kernel/early_printk.c
>>>>> @@ -25,6 +25,9 @@
>>>>> 
>>>>> #include <linux/amba/serial.h>
>>>>> #include <linux/serial_reg.h>
>>>>> +#include <linux/virtio_ids.h>
>>>>> +#include <linux/virtio_mmio.h>
>>>>> +#include <linux/virtio_console.h>
>>>>> 
>>>>> static void __iomem *early_base;
>>>>> static void (*printch)(char ch);
>>>>> @@ -53,6 +56,26 @@ static void smh_printch(char ch)
>>>>> }
>>>>> 
>>>>> /*
>>>>> + * VIRTIO MMIO based debug console.
>>>>> + */
>>>>> +static void virtio_console_early_printch(char ch)
>>>>> +{
>>>>> +     u32 tmp;
>>>>> +     struct virtio_console_config *p = early_base +
>>>>> VIRTIO_MMIO_CONFIG;
>>>>> +
>>>>> +     tmp = readl_relaxed(early_base + VIRTIO_MMIO_DEVICE_ID);
>>>>> +     if (tmp != VIRTIO_ID_CONSOLE) {
>>>>> +             return;
>>>>> +     }
>>>>> +
>>>>> +     tmp = readl_relaxed(early_base + VIRTIO_MMIO_HOST_FEATURES);
>>>>> +     if (!(tmp & (1 << VIRTIO_CONSOLE_F_EARLY_WRITE))) {
>>>>> +             return;
>>>>> +     }
>>>>> +     writeb_relaxed(ch, &p->early_rw);
>>>> 
>>>> So here, you end up trapping 3 times per character being output on the
>>>> console. Surely there's a better way. How about remembering the result
>> of
>>>> these tests in a static variable?
>>> Yeah surely it is a better idea to remember using static variable, so
>> that
>>> after initialize once, it will trap only one time.
>> 
>> Also, would it be possible to directly get the base address from DT? It
>> would save having to pass the address (which is not known before runtime in
>> the case of kvmtool). Not sure if it is available that early though...
> 
> Early printk code initializes earlier (from  parse_early_param in
> arch/arm64/setup.c) than fdt un-flattened call (unflatten_device_tree)
> . Hence using dts to pass this is not possible for passing the
> address.

Then don't print anything until the fdt is unflattened?

Alex

> 
>> 
>>>> 
>>>>> +}
>>>>> +
>>>>> +/*
>>>>>  * 8250/16550 (8-bit aligned registers) single character TX.
>>>>>  */
>>>>> static void uart8250_8bit_printch(char ch)
>>>>> @@ -82,6 +105,7 @@ static const struct earlycon_match
>> earlycon_match[]
>>>>> __initconst = {
>>>>>      { .name = "smh", .printch = smh_printch, },
>>>>>      { .name = "uart8250-8bit", .printch = uart8250_8bit_printch, },
>>>>>      { .name = "uart8250-32bit", .printch = uart8250_32bit_printch,
>> },
>>>>> +     { .name = "virtio-console", .printch =
>>>> virtio_console_early_printch,
>>>> },
>>>>>      {}
>>>>> };
>>>>> 
>>>>> diff --git a/include/uapi/linux/virtio_console.h
>>>>> b/include/uapi/linux/virtio_console.h
>>>>> index ee13ab6..1171cb4 100644
>>>>> --- a/include/uapi/linux/virtio_console.h
>>>>> +++ b/include/uapi/linux/virtio_console.h
>>>>> @@ -38,6 +38,8 @@
>>>>> /* Feature bits */
>>>>> #define VIRTIO_CONSOLE_F_SIZE        0       /* Does host provide
>>>> console size? */
>>>>> #define VIRTIO_CONSOLE_F_MULTIPORT 1 /* Does host provide multiple
>>>> ports?
>>>>> */
>>>>> +#define VIRTIO_CONSOLE_F_EARLY_READ 2        /* Does host support
>>>>> early
>>>> read?
>>>> */
>>>>> +#define VIRTIO_CONSOLE_F_EARLY_WRITE 3       /* Does host support
>>>>> early
>>>> write?
>>>>> */
>>>>> 
>>>>> #define VIRTIO_CONSOLE_BAD_ID                (~(u32)0)
>>>>> 
>>>>> @@ -48,6 +50,8 @@ struct virtio_console_config {
>>>>>      __u16 rows;
>>>>>      /* max. number of ports this device can hold */
>>>>>      __u32 max_nr_ports;
>>>>> +     /* early read/write register */
>>>>> +     __u32 early_rw;
>>>>> } __attribute__((packed));
>>>>> 
>>>>> /*
>>>> 
>>>> So that bit is clearly a spec change. How does it work with PCI, or any
>>>> other virtio transport?
>>> I am not sure about PCI hence just posted for MMIO.
>>> 
>>>> 
>>>> Overall, I'm a bit concerned with adding features that don't really
>> match
>>>> the way virtio is supposed to work. The whole goal of virtio is to
>>>> minimize
>>>> the amount of trapping, and here you end up trapping on each and every
>>>> access.
>>>> 
>>>> If you need an early console, why not simply wire the 8250 emulation in
>>>> kvmtool to be useable from the MMIO bus? I reckon this would solve your
>>>> problem in a more elegant way...
>>> Emulation will solve the issue but having a virtio early read or write
>> has
>>> one more advantage i.e.
>>> In case of mach-virt we might need early read-write support for virtio
>>> console to see if kernel is not panic before actual virtio drivers takes
>>> control.
>>> Also if someone wants to have UEFI or uboot running on mach-virt then we
>>> also need early input facility in virtio console.
>> 
>> That's exactly why I was suggesting using the 8250 emulation. It is
>> supported by everything under the sun. I do not immediately see what the
>> gain is with this virtio approach, as compared to 8250 emulation.
>> 
>> Don't misunderstand me, I like the idea of having a virtio-only system,
> Definitely not.
>> specially if we can make it work with other transports. I just want to
>> outline that there may be a simpler way for your particular use case.
> 
> Actually i thought adding a config register will be easier to add a
> code than writing entire emulation as 8250 emulation will require to
> deal with dealing with more registers and more code.
> 
> Thanks,
> Pranav
> 
>> 
>> Thanks,
>> 
>>        M.
>> --
>> Fast, cheap, reliable. Pick two.
> _______________________________________________
> kvmarm mailing list
> kvmarm at lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm


From pranavkumar at linaro.org  Thu Apr 18 04:55:02 2013
From: pranavkumar at linaro.org (Pranavkumar Sawargaonkar)
Date: Thu, 18 Apr 2013 14:25:02 +0530
Subject: [RFC] arm64: Early printk support for virtio-mmio console devices.
In-Reply-To: <47354634-CA37-47E3-99D2-D4DDB08A9870@suse.de>
References: <1366264344-28025-1-git-send-email-pranavkumar@linaro.org>
 <87wqs02uws.fsf@rustcorp.com.au>
 <CAAHg+HiHKV+8hBT1QWe4hSxocCX6wpRd3bCPWB7zU8jVFmPuAA@mail.gmail.com>
 <47354634-CA37-47E3-99D2-D4DDB08A9870@suse.de>
Message-ID: <CAAHg+Hhp840YXQCWKfSbmHZee206ijqdzuGTZzeX-Kf=krh7TA@mail.gmail.com>

Hi,

On 18 April 2013 14:14, Alexander Graf <agraf at suse.de> wrote:
>
>
> Am 18.04.2013 um 09:32 schrieb Pranavkumar Sawargaonkar <pranavkumar at linaro.org>:
>
>> On 18 April 2013 12:21, Rusty Russell <rusty at rustcorp.com.au> wrote:
>>>
>>> PranavkumarSawargaonkar <pranavkumar at linaro.org> writes:
>>>> From: Pranavkumar Sawargaonkar <pranavkumar at linaro.org>
>>>>
>>>> This patch implements early printk support for virtio-mmio console devices without using any hypercalls.
>>>
>>> This makes some sense, though not sure that early console *read* makes
>>> much sense.  I can see the PCI version of this being useful as well.
>>
>> Read can be useful for "mach-virt" which will have only virtio console
>> as a console device. Then if someone wants to have UEFI or any other
>> boot-loader emulation, which expects user to input few things, in that
>> case read might become handy.
>
> A boot loader should easily be able to implement virtio-console for real.
>
> In fact, you should be able to do a simple virtio-console implementation for early printk too, that polls the host for acks rather than use interrupts. Check out my s390-zipl code for reference. I use that there.

At the time of early printk we do not have virtio queues initialized
so even if we use poll for ack than interrupt, without queues being
set how that is possible ?  Hence we have added simple config register
which can be polled without setting up queues.
>
> The advantage to that would be that no host changes are required whatsoever and the interface strictly stays as it is.
>
>
> Alex
>
Thanks,
Pranav


From daniel.lezcano at linaro.org  Thu Apr 18 04:56:08 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Thu, 18 Apr 2013 10:56:08 +0200
Subject: [V3 patch 02/19] ARM: shmobile: cpuidle: remove shmobile_enter_wfi
 prototype
In-Reply-To: <516FAF28.80002@ti.com>
References: <1365770165-27096-1-git-send-email-daniel.lezcano@linaro.org>
 <1365770165-27096-3-git-send-email-daniel.lezcano@linaro.org>
 <516FAF28.80002@ti.com>
Message-ID: <516FB528.90006@linaro.org>

On 04/18/2013 10:30 AM, Santosh Shilimkar wrote:
> On Friday 12 April 2013 06:05 PM, Daniel Lezcano wrote:
>> Commit 688036b538974de32ce55be8b0e013b003992abc removed the function
>> 'shmobile_enter_wfi' but we forgot to remove the definition in the header file.
>>
>> Note this function is just an alias to 'cpu_do_idle()' wrapped into a cpuidle
>> function callback prototype which already exists with the default WFI state
>> and the arm_simple_enter function.
>>
>> Remove the function prototype.
>>
>> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
>> ---
> You can actually fold this into 1/19. No strong opinion though.

Initially it was folded but Simon wanted to split it in two, thus 1/19
and 2/19.


-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From linux at arm.linux.org.uk  Thu Apr 18 05:00:09 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Thu, 18 Apr 2013 10:00:09 +0100
Subject: [PATCH v2] serial: pl011: Add Device Tree support to request
 DMA channels
In-Reply-To: <20130418083922.GC3137@gmail.com>
References: <1366272857-14038-1-git-send-email-lee.jones@linaro.org>
 <20130418081811.GF14496@n2100.arm.linux.org.uk>
 <20130418083922.GC3137@gmail.com>
Message-ID: <20130418090008.GG14496@n2100.arm.linux.org.uk>

On Thu, Apr 18, 2013 at 09:39:22AM +0100, Lee Jones wrote:
> On Thu, 18 Apr 2013, Russell King - ARM Linux wrote:
> > This suffers the same problem with your MMCI patch.  If you're using DT and
> > don't provide the DMA information, you get errors printed.  That's not on
> > for an optional driver feature, especially when that feature causes
> > functional difficulties on various platforms and so is _purposely_ omitted.
> 
> How does that differ from using pdata and not passing DMA information?

If you have pdata but no DMA information then, this gets triggered:

        if (!plat || !plat->dma_filter) {
                dev_info(uap->port.dev, "no DMA platform data\n");
                return;
        }

However, with your change, this becomes:

	if (!(plat && plat->dma_filter) && !np) {
		dev_info(uap->port.dev, "no DMA platform data or DT\n");
		return;
	}

wihch means it is _unconditionally_ bypassed if there is a DT node.  So,
if the MMC device has been created from DT, we will drop through to the
following code irrespective of whether there is any DMA data passed.
Hence, we get to here unconditionally in the DT case:

	chan = dma_request_slave_channel_compat(mask,
				(plat) ? plat->dma_filter : NULL,
				(plat) ? plat->dma_tx_param : NULL,
				uap->port.dev, "tx");
	if (!chan) {
		dev_err(uap->port.dev, "no TX DMA channel!\n");
		return;

and if the DT transmit DMA information is not provided, chan will be NULL,
which means we produce an error level "no TX DMA channel!" message.  That
message is supposed to indicate only when it has not been possible to
request the channel, not when there has been no DMA information provided.

This is where AMBA drivers differ from the majority of other drivers -
DMA is *strictly* optional for them, and that must remain the case as long
as we have platforms where AMBA devices are not hooked up to DMA engines
or where the DMA engines they are hooked up to are buggy, or the entire
DMA design (PL08x connected to PL18x) is buggy.


From arnd at arndb.de  Thu Apr 18 05:01:13 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 18 Apr 2013 11:01:13 +0200
Subject: [PATCH v3] irqchip: Add support for ARMv7-M's NVIC
In-Reply-To: <20130418081555.GV30416@pengutronix.de>
References: <1366214540-31166-1-git-send-email-u.kleine-koenig@pengutronix.de>
 <201304172223.43707.arnd@arndb.de> <20130418081555.GV30416@pengutronix.de>
Message-ID: <201304181101.13644.arnd@arndb.de>

On Thursday 18 April 2013, Uwe Kleine-K?nig wrote:
> > > + * Each bank handles 32 irqs. Only the 16th (= last) bank handles only
> > > + * 16 irqs.
> > > + */
> > > +#define NVIC_MAX_IRQ               ((NVIC_MAX_BANKS - 1) * 32 + 16)
> > 
> > Is this actually inherent to the hardware design, or is the number of irqs
> > actually customizable? Also, why do you care about the maximum? You only
> > use it to check against the device tree provided value, but I suppose
> > you could just as well trust that property to be correct.
> I don't provide a value for the number of irqs in the device tree. There
> is only the value INTLINESNUM in the V7M_SCS_ICTR register that is used
> to determine the number of interrupt banks.

Ah, right. But do you have any reason to believe it could be wrong?

	Arnd


From nicolas.ferre at atmel.com  Thu Apr 18 05:01:37 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Thu, 18 Apr 2013 11:01:37 +0200
Subject: [PATCH v3] ARM: at91: add Acme Systems Aria G25 board
In-Reply-To: <515DB248.6070105@interlog.com>
References: <20130402184947.GA8015@quad.lixom.net>
 <1365090153-1807-1-git-send-email-nicolas.ferre@atmel.com>
 <515DB248.6070105@interlog.com>
Message-ID: <516FB671.2030706@atmel.com>

On 04/04/2013 07:03 PM, Douglas Gilbert :
> On 13-04-04 11:42 AM, Nicolas Ferre wrote:
>> From: Douglas Gilbert <dgilbert at interlog.com>
>>
>> Signed-off-by: Douglas Gilbert <dgilbert at interlog.com>
>> Signed-off-by: Nicolas Ferre <nicolas.ferre at atmel.com>
>> ---
>> Hi all,
>>
>> Here is the third revision of this patch. I plan to include it in a
>> pull-request real-soon-now!
>>
>> v3: - move to "at91-" prefix for .dts[i] files
>>      - remove the rtc activation code because of the ongoing discussions
>>        about this IP and its DT binding.
>>
> 
> Nicolas,
> It's a pity that the rtc activation code is removed.
> At worst:
>                         rtc at fffffeb0 {
>                                 status = "okay";
>                         };

I try to re-enalbe it when the at91sam9x5.dtsi exposes a compatibility
sting != at91rm9200-rtc

will soon appear on mailing-list.

> does nothing. Also it is unlikely to be changed by any
> movement on the rtc-at91rm9200 front.
> 
> 
> The lack of use of uart1 is for my own, private reasons.
> I think it would be more generally useful to show uart1's
> definition and disable it as shown in the attached patch
> fragment.

Well, if uart1 is available on Aria board, I should enable it! If you do
not want it on your own design, you must modify the .dts yourself. So I
plan to have an "okay" status on it (and move the definition itself to
the generic .dtsi).


> I also note that my date line was removed. I like dates,
> so when I add comments like "the i2c-at91 driver is broken
> for the SAM9G20 ** and use the i2c-gpio driver instead" then
> this is not taken as an eternal truth.

Yep, I see, but I try to cleanup the patch as much as I can. If you want
it untouched, provide me a standard formated patch.

> It worked in the
> past and hopefully it will work again in the future.
> 
> While on the subject of I2C, I'm getting tired of seeing
> this oft-copied line:
>    i2c-gpio,delay-us = <2>;        /* ~100 kHz */
> 
> It is the clock half period in microseconds and for the 100 kHz
> (standard) I2C clock speed, it should be 5. Due to rounding
> (up) that gives a measured clock speed of around 88 kHz on
> my equipment. Crappy I2C devices *** seem to cope better
> with 12% below the standard clock frequency than 80% above
> it.

Makes sense: I keep it in mind. In parallel, it can be interesting if
you can send me a patch with all these mistakes corrected ;-)

Bye,
-- 
Nicolas Ferre


From will.deacon at arm.com  Thu Apr 18 05:08:26 2013
From: will.deacon at arm.com (Will Deacon)
Date: Thu, 18 Apr 2013 10:08:26 +0100
Subject: [PATCH v4 3/7] ARM: KVM: move to a KVM provided HYP idmap
In-Reply-To: <CAEDV+gK=4VwBQUNkAWSmo3j1A2GwewXctNno3NBpyOFG0C8YFw@mail.gmail.com>
References: <1365790327-2138-1-git-send-email-marc.zyngier@arm.com>
 <1365790327-2138-4-git-send-email-marc.zyngier@arm.com>
 <CAEDV+gK=4VwBQUNkAWSmo3j1A2GwewXctNno3NBpyOFG0C8YFw@mail.gmail.com>
Message-ID: <20130418090826.GB28942@mudshark.cambridge.arm.com>

On Wed, Apr 17, 2013 at 08:37:00PM +0100, Christoffer Dall wrote:
> On Fri, Apr 12, 2013 at 11:12 AM, Marc Zyngier <marc.zyngier at arm.com> wrote:
> > After the HYP page table rework, it is pretty easy to let the KVM
> > code provide its own idmap, rather than expecting the kernel to
> > provide it. It takes actually less code to do so.
> >
> > Acked-by: Will Deacon <will.deacon at arm.com>
> > Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> > ---
> >  arch/arm/include/asm/idmap.h   |  1 -
> >  arch/arm/include/asm/kvm_mmu.h |  1 -
> >  arch/arm/kvm/mmu.c             | 24 +++++++++++++++++++++++-
> >  arch/arm/mm/idmap.c            | 32 +-------------------------------
> >  4 files changed, 24 insertions(+), 34 deletions(-)

[...]

> Russell,
> 
> I would appreciate your ack on this one so we can merge this through
> the KVM tree, or alternatively let us know if this needs to go your
> tree, so we can plan accordingly for the next merge window.

The core ARM part of this is basically just deleting code that KVM doesn't
require any more. I'm not aware of any other patches in this area at the
moment so, unless Russell objects, I don't think there would be a problem
with this going via the kvm tree providing that it sits in -next until it's
in mainline.

Will


From u.kleine-koenig at pengutronix.de  Thu Apr 18 05:10:19 2013
From: u.kleine-koenig at pengutronix.de (Uwe =?iso-8859-1?Q?Kleine-K=F6nig?=)
Date: Thu, 18 Apr 2013 11:10:19 +0200
Subject: [PATCHv2 2/3] ARM: Detect support for SDIV/UDIV from ISAR0
 register
In-Reply-To: <1363631337-13816-3-git-send-email-sboyd@codeaurora.org>
References: <1363631337-13816-1-git-send-email-sboyd@codeaurora.org>
 <1363631337-13816-3-git-send-email-sboyd@codeaurora.org>
Message-ID: <20130418091019.GA21099@pengutronix.de>

Hello Stephen,

On Mon, Mar 18, 2013 at 11:28:56AM -0700, Stephen Boyd wrote:
> The ISAR0 register indicates support for the SDIV and UDIV
> instructions in both the Thumb and ARM instruction set. Read the
> register to detect the supported instructions and update the
> elf_hwcap mask as appropriate. This is better than adding more
> and more cpuid checks in proc-v7.S for each new cpu variant that
> supports these instructions.
you pointed out yesterday that this could work on v7-m, too. As I based
my patches on 3.9-rc1 this patch (8164f7af88) wasn't included. When
updating this results in a warning, because I have

	6ebd4d0 (ARM: stub out read_cpuid and read_cpuid_ext for CPU_CP15=n)

from rmk's devel-stable branch.
 
> Acked-by: Will Deacon <will.deacon at arm.com>
> Cc: Stepan Moskovchenko <stepanm at codeaurora.org>
> Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
> ---
>  arch/arm/kernel/setup.c | 20 ++++++++++++++++++++
>  arch/arm/mm/proc-v7.S   |  4 ++--
>  2 files changed, 22 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> index e2c8bbf..f3ac13f 100644
> --- a/arch/arm/kernel/setup.c
> +++ b/arch/arm/kernel/setup.c
> @@ -353,6 +353,23 @@ void __init early_print(const char *str, ...)
>  	printk("%s", buf);
>  }
>  
> +static void __init cpuid_init_hwcaps(void)
> +{
> +	unsigned int divide_instrs;
> +
> +	if (cpu_architecture() < CPU_ARCH_ARMv7)
> +		return;
> +
> +	divide_instrs = (read_cpuid_ext(CPUID_EXT_ISAR0) & 0x0f000000) >> 24;
The problem is that read_cpuid_ext is called which doesn't map to
something useful for v7-m. So maybe add a check:

	if (!IS_ENABLED(CONFIG_CPU_CP15))
		return;

?

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |


From linux at arm.linux.org.uk  Thu Apr 18 05:20:32 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Thu, 18 Apr 2013 10:20:32 +0100
Subject: [PATCH] ARM: sched_clock: Add more notrace to prevent recursion
In-Reply-To: <516F3FA5.8070307@codeaurora.org>
References: <1363306086-23501-1-git-send-email-sboyd@codeaurora.org>
 <514B483F.7000304@codeaurora.org> <5151DC75.7030606@codeaurora.org>
 <516F3FA5.8070307@codeaurora.org>
Message-ID: <20130418092031.GH14496@n2100.arm.linux.org.uk>

On Wed, Apr 17, 2013 at 05:34:45PM -0700, Stephen Boyd wrote:
> On 03/26/13 10:35, Stephen Boyd wrote:
> > On 03/21/13 10:49, Stephen Boyd wrote:
> >> On 03/14/13 17:08, Stephen Boyd wrote:
> >>> cyc_to_sched_clock() is called by sched_clock() and cyc_to_ns()
> >>> is called by cyc_to_sched_clock(). I suspect that some compilers
> >>> inline both of these functions into sched_clock() and so we've
> >>> been getting away without having a notrace marking. It seems that
> >>> my compiler isn't inlining cyc_to_sched_clock() though, so I'm
> >>> hitting a recursion bug when I enable the function graph tracer,
> >>> causing my system to crash. Marking these functions notrace fixes
> >>> it. Technically cyc_to_ns() doesn't need the notrace because it's
> >>> already marked inline, but let's just add it so that if we ever
> >>> remove inline from that function it doesn't blow up.
> >> Anyone else seeing this problem?
> > Russell, should I put this into the patch tracker?
> 
> I'll throw this into the patch tracker tomorrow if nobody complains.

Or you could do so today.


From u.kleine-koenig at pengutronix.de  Thu Apr 18 05:24:36 2013
From: u.kleine-koenig at pengutronix.de (Uwe =?iso-8859-1?Q?Kleine-K=F6nig?=)
Date: Thu, 18 Apr 2013 11:24:36 +0200
Subject: [PATCH v3] irqchip: Add support for ARMv7-M's NVIC
In-Reply-To: <201304181101.13644.arnd@arndb.de>
References: <1366214540-31166-1-git-send-email-u.kleine-koenig@pengutronix.de>
 <201304172223.43707.arnd@arndb.de>
 <20130418081555.GV30416@pengutronix.de>
 <201304181101.13644.arnd@arndb.de>
Message-ID: <20130418092436.GB21099@pengutronix.de>

On Thu, Apr 18, 2013 at 11:01:13AM +0200, Arnd Bergmann wrote:
> On Thursday 18 April 2013, Uwe Kleine-K?nig wrote:
> > > > + * Each bank handles 32 irqs. Only the 16th (= last) bank handles only
> > > > + * 16 irqs.
> > > > + */
> > > > +#define NVIC_MAX_IRQ               ((NVIC_MAX_BANKS - 1) * 32 + 16)
> > > 
> > > Is this actually inherent to the hardware design, or is the number of irqs
> > > actually customizable? Also, why do you care about the maximum? You only
> > > use it to check against the device tree provided value, but I suppose
> > > you could just as well trust that property to be correct.
> > I don't provide a value for the number of irqs in the device tree. There
> > is only the value INTLINESNUM in the V7M_SCS_ICTR register that is used
> > to determine the number of interrupt banks.
> 
> Ah, right. But do you have any reason to believe it could be wrong?
No it's just that the mapping isn't linear in the end.

	INTLINESNUM | number of irqs
	      0     |     32
	      1     |     64
	      2     |     96
	      3     |    128
	      4     |    160
	      5     |    192
	      6     |    224
	      7     |    256
	      8     |    288
	      9     |    320
	     10     |    352
	     11     |    384
	     12     |    416
	     13     |    448
	     14     |    480
	     15     |    496

That is, there are (INTLINESNUM + 1) * 32 irqs for INTLINESNUM < 15. For
INTLINESNUM == 15 there are only 496 and not 16 * 32 == 512. That's the
same on the gic (just with bigger numbers).

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |


From maxime.ripard at free-electrons.com  Thu Apr 18 05:23:52 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Thu, 18 Apr 2013 11:23:52 +0200
Subject: [PATCH] video: mxsfb: Fix colors display on lower color depth
In-Reply-To: <516EBCA4.1020609@free-electrons.com>
References: <516EBCA4.1020609@free-electrons.com>
Message-ID: <1366277032-671-1-git-send-email-maxime.ripard@free-electrons.com>

The current code always registers as a 32 bits display, and uses the
hardware to drop the MSB of each color to abjust to the interface width
used by the panel.

This results on 18 bits (and probably 16 bits display as well) in colors
being displayed poorly, because the MSB are obviously the most important
bits for each color definition.

The default controller behaviour when using an interface width smaller
than the color depth is to drop the LSBs of each color, which makes more
sense because you lose the least important part of the color definition.

So, to fix the colors display, just get back to the default controller
behaviour.

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 drivers/video/mxsfb.c |    5 -----
 1 file changed, 5 deletions(-)

diff --git a/drivers/video/mxsfb.c b/drivers/video/mxsfb.c
index 755556c..2cfaf8b 100644
--- a/drivers/video/mxsfb.c
+++ b/drivers/video/mxsfb.c
@@ -424,11 +424,6 @@ static int mxsfb_set_par(struct fb_info *fb_info)
 			return -EINVAL;
 		case STMLCDIF_16BIT:
 		case STMLCDIF_18BIT:
-			/* 24 bit to 18 bit mapping */
-			ctrl |= CTRL_DF24; /* ignore the upper 2 bits in
-					    *  each colour component
-					    */
-			break;
 		case STMLCDIF_24BIT:
 			/* real 24 bit */
 			break;
-- 
1.7.10.4



From arnd at arndb.de  Thu Apr 18 05:25:44 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 18 Apr 2013 11:25:44 +0200
Subject: [PATCH] mmc: mmci: Allow MMCI to request channels with
 information acquired from DT
In-Reply-To: <20130418081549.GE14496@n2100.arm.linux.org.uk>
References: <1366205534-25079-1-git-send-email-lee.jones@linaro.org>
 <20130418080238.GB3137@gmail.com>
 <20130418081549.GE14496@n2100.arm.linux.org.uk>
Message-ID: <201304181125.44983.arnd@arndb.de>

On Thursday 18 April 2013, Russell King - ARM Linux wrote:
> On Thu, Apr 18, 2013 at 09:02:38AM +0100, Lee Jones wrote:
> > @@ -321,19 +323,21 @@ static void mmci_dma_setup(struct mmci_host *host)
> >        * attempt to use it bidirectionally, however if it is
> >        * is specified but cannot be located, DMA will be disabled.
> >        */
> > -     if (plat->dma_rx_param) {
> > -             host->dma_rx_channel = dma_request_channel(mask,
> > -                                                        plat->dma_filter,
> > -                                                        plat->dma_rx_param);
> > +     if (plat->dma_rx_param || np) {
> > +             host->dma_rx_channel = dma_request_slave_channel_compat(mask,
> > +                                                             plat->dma_filter,
> > +                                                             plat->dma_rx_param,
> > +                                                             &dev->dev, "rx");
> >               /* E.g if no DMA hardware is present */
> >               if (!host->dma_rx_channel)
> >                       dev_err(mmc_dev(host->mmc), "no RX DMA channel\n");
> 
> I don't think this is right - I think Arnd has been leading you up the
> garden path saying that this can be simplified.  Why?
> 
> If you look at what this code does, the DMA channels are optional.  If
> they're not provided, then you don't get an error or a warning printk from
> the code.  However, after your conversion, if you use DT and avoid giving
> the DMA information (which you have to avoid on the majority of ARM
> platforms) then "np" will be non-NULL, and
> dma_request_slave_channel_compat() will return NULL, causing the error
> and/or warning to be printed.

Right, so I guess we should print the warning only if plat->dma_filter
is non-NULL, or we don't use dma_request_slave_channel_compat, which
does not actually simplify the code here.

	Arnd

diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index 375c109..c97bc92 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -298,20 +298,11 @@ static void mmci_init_sg(struct mmci_host *host, struct mmc_data *data)
  * no custom DMA interfaces are supported.
  */
 #ifdef CONFIG_DMA_ENGINE
-static void mmci_dma_setup(struct mmci_host *host)
+static int mmci_dma_plat_setup(struct mmci_host *host)
 {
 	struct mmci_platform_data *plat = host->plat;
-	const char *rxname, *txname;
 	dma_cap_mask_t mask;
 
-	if (!plat || !plat->dma_filter) {
-		dev_info(mmc_dev(host->mmc), "no DMA platform data\n");
-		return;
-	}
-
-	/* initialize pre request cookie */
-	host->next_data.cookie = 1;
-
 	/* Try to acquire a generic DMA engine slave channel */
 	dma_cap_zero(mask);
 	dma_cap_set(DMA_SLAVE, mask);
@@ -339,6 +330,25 @@ static void mmci_dma_setup(struct mmci_host *host)
 	} else {
 		host->dma_tx_channel = host->dma_rx_channel;
 	}
+}
+
+static void mmci_dma_setup(struct device *dev, struct mmci_host *host)
+{
+	const char *rxname, *txname;
+
+	host->dma_rx_channel = dma_request_slave_channel(dev, "rx");
+	host->dma_tx_channel = dma_request_slave_channel(dev, "tx");
+
+	if (!host->dma_rx_channel && !host->dma_tx_channel) {
+		if (host->plat && host->plat->dma_filter)
+			mmci_dma_plat_setup(host);
+		else
+			dev_info(mmc_dev(host->mmc), "no DMA platform data\n");
+			return;
+	}
+
+	/* initialize pre request cookie */
+	host->next_data.cookie = 1;
 
 	if (host->dma_rx_channel)
 		rxname = dma_chan_name(host->dma_rx_channel);


From v-stehle at ti.com  Thu Apr 18 05:30:00 2013
From: v-stehle at ti.com (=?ISO-8859-1?Q?Vincent_Stehl=E9?=)
Date: Thu, 18 Apr 2013 11:30:00 +0200
Subject: [PATCHv2] ARM:dts:omap4-panda:Update the LED support for the
 panda DTS
In-Reply-To: <1366229760-4808-1-git-send-email-dmurphy@ti.com>
References: <1366229760-4808-1-git-send-email-dmurphy@ti.com>
Message-ID: <516FBD18.3060501@ti.com>

On 04/17/2013 10:16 PM, Dan Murphy wrote:
> The GPIO for LED D1 on the omap4-panda a1-a3 rev and the omap4-panda-es
> are different.
(..)
> diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi b/arch/arm/boot/dts/omap4-panda-common.dtsi
> index 03bd60d..0c48f6b 100644
> --- a/arch/arm/boot/dts/omap4-panda-common.dtsi
> +++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
(..)
> @@ -135,6 +136,25 @@
>  			0xf0 0x118     /* i2c4_sda PULLUP | INPUTENABLE | MODE0 */
>  		>;
>  	};
> +
> +	led_gpio_pins: pinmux_leds_pins {
> +		pinctrl-single,pins = <
> +		>;
> +	};
> +};

Hi,

FYI, there was a recent discussion precisely on this topic, where Tomy
suggested to remove the empty section:
http://marc.info/?l=linux-omap&m=136546635409232&w=2

Apart from that, I just tested your patch on top of Tomy's
omap-for-v3.10/dt branch and it is working fine for me on PandaBoards
EA3, A4 and ES.

Tested-by: Vincent Stehl? <v-stehle at ti.com>

Best regards,

V.



From linux at arm.linux.org.uk  Thu Apr 18 05:30:12 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Thu, 18 Apr 2013 10:30:12 +0100
Subject: [PATCH] mmc: mmci: Allow MMCI to request channels with
 information acquired from DT
In-Reply-To: <201304181125.44983.arnd@arndb.de>
References: <1366205534-25079-1-git-send-email-lee.jones@linaro.org>
 <20130418080238.GB3137@gmail.com>
 <20130418081549.GE14496@n2100.arm.linux.org.uk>
 <201304181125.44983.arnd@arndb.de>
Message-ID: <20130418093012.GI14496@n2100.arm.linux.org.uk>

On Thu, Apr 18, 2013 at 11:25:44AM +0200, Arnd Bergmann wrote:
> +static void mmci_dma_setup(struct device *dev, struct mmci_host *host)
> +{
> +	const char *rxname, *txname;
> +
> +	host->dma_rx_channel = dma_request_slave_channel(dev, "rx");
> +	host->dma_tx_channel = dma_request_slave_channel(dev, "tx");
> +
> +	if (!host->dma_rx_channel && !host->dma_tx_channel) {
> +		if (host->plat && host->plat->dma_filter)
> +			mmci_dma_plat_setup(host);
> +		else
> +			dev_info(mmc_dev(host->mmc), "no DMA platform data\n");
> +			return;

You may like to fix the sillies in this patch... but yes, the above
would be better.


From tglx at linutronix.de  Thu Apr 18 05:35:22 2013
From: tglx at linutronix.de (Thomas Gleixner)
Date: Thu, 18 Apr 2013 11:35:22 +0200 (CEST)
Subject: [PATCH v3] irqchip: Add support for ARMv7-M's NVIC
In-Reply-To: <1366214540-31166-1-git-send-email-u.kleine-koenig@pengutronix.de>
References: <1366214540-31166-1-git-send-email-u.kleine-koenig@pengutronix.de>
Message-ID: <alpine.LFD.2.02.1304180947070.21884@ionos>

On Wed, 17 Apr 2013, Uwe Kleine-K?nig wrote:
> +struct nvic_bank_data {
> +	/*
> +	 * For irq i base holds nvic_base + 4 * i / 32. So you can access the
> +	 * right ISER register (i.e ISER[i / 32]) by just taking base + ISER.
> +	 * Ditto for ICER.
> +	 */
> +	void __iomem *base;
> +};

What's the point of a struct with a single member? Why not having an
array of base pointers ?

> +static struct nvic_chip_data {
> +	struct irq_domain *domain;
> +	struct nvic_bank_data bdata[NVIC_MAX_BANKS];
> +} nvic_chip_data;
> +
> +asmlinkage void __exception_irq_entry
> +nvic_do_IRQ(irq_hw_number_t hwirq, struct pt_regs *regs)
> +{
> +	unsigned int irq = irq_linear_revmap(nvic_chip_data.domain, hwirq);
> +
> +	handle_IRQ(irq, regs);
> +}
> +
> +static inline void __iomem *nvic_bank_base(struct irq_data *d)
> +{
> +	struct nvic_bank_data *bank_data = irq_data_get_irq_chip_data(d);
> +	return bank_data->base;
> +}
> +
> +static void nvic_mask_irq(struct irq_data *d)
> +{
> +	u32 mask = 1 << (d->hwirq % 32);
> +
> +	writel_relaxed(mask, nvic_bank_base(d) + NVIC_ICER);
> +}
> +
> +static void nvic_unmask_irq(struct irq_data *d)
> +{
> +	u32 mask = 1 << (d->hwirq % 32);
> +
> +	writel_relaxed(mask, nvic_bank_base(d) + NVIC_ISER);
> +}

How is that different from what the generic irq chip implementation
does? The only difference is that mask is generated by d->hwirq and
not by d->irq. And due to the fact, that you use a full linear mapping
between hwirq and virq the generic code simply works.

Even if it would not work, it would be trivial to extend the generic
chip with that functionality instead of hacking another slightly
different copy of the same thing.

Thanks,

	tglx


From arnd at arndb.de  Thu Apr 18 05:38:13 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 18 Apr 2013 11:38:13 +0200
Subject: [PATCH v3] irqchip: Add support for ARMv7-M's NVIC
In-Reply-To: <20130418092436.GB21099@pengutronix.de>
References: <1366214540-31166-1-git-send-email-u.kleine-koenig@pengutronix.de>
 <201304181101.13644.arnd@arndb.de> <20130418092436.GB21099@pengutronix.de>
Message-ID: <201304181138.13599.arnd@arndb.de>

On Thursday 18 April 2013, Uwe Kleine-K?nig wrote:
> That is, there are (INTLINESNUM + 1) * 32 irqs for INTLINESNUM < 15. For
> INTLINESNUM == 15 there are only 496 and not 16 * 32 == 512. That's the
> same on the gic (just with bigger numbers).

Ok, but since you are now using a linear domain, it doesn't actually hurt
to register 512 in that special case, right?

	Arnd


From thomas.petazzoni at free-electrons.com  Thu Apr 18 05:47:19 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Thu, 18 Apr 2013 11:47:19 +0200
Subject: [GIT PULL] mvebu irqchip for v3.10
In-Reply-To: <20130418064217.GF12816@quad.lixom.net>
References: <20130415195245.GU28693@titan.lakedaemon.net>
 <20130418064217.GF12816@quad.lixom.net>
Message-ID: <20130418114719.01e9f375@skate>

Olof, Jason,

On Wed, 17 Apr 2013 23:42:17 -0700, Olof Johansson wrote:

> > The following changes since commit
> > 31880c37c11e28cb81c70757e38392b42e695dc6:
> > 
> >   Linux 3.9-rc6 (2013-04-07 20:49:54 -0700)
> > 
> > are available in the git repository at:
> > 
> >   git://git.infradead.org/users/jcooper/linux.git tags/irqchip-3.10
> > 
> > for you to fetch changes up to
> > 5ec69017cc944f3ed88362d4b60818713a45e616:
> > 
> >   irqchip: armada-370-xp: slightly cleanup irq controller driver
> > (2013-04-15 19:35:17 +0000)
> > 
> > ----------------------------------------------------------------
> > mvebu driver irqchip for v3.10
> > 
> >  - move the armada irqchip driver to drivers/irqchip/
> > 
> > Note:
> >  - I asked tglx if it was ok to take this series on 10 Apr due to
> > it's complex dependencies.  5+ days have passed with no objection.
> >  - I put this driver in a separate mvebu branch in case tglx or
> > others object, it can be dropped with minimal impact to other work.
> 
> 
> Hi,
> 
> These notes are useful to include in the pull request, but not in the
> git tag -- they don't really hold much permanent value.
> 
> This branch also seems to have a few internal conflicts on mbus
> changes. Not a big deal, I fixed it up, but you might as well have
> based this on the other branch as well.
> 
> Merged as a late/cleanup branch.

I just tested arm-soc/for-next, and it seems like there was a merge
conflict that was not properly resolved. The
arch/arm/mach-mvebu/Makefile still references irq-armada-370-xp.c, even
though it has been moved to drivers/irqchip/ as per the pull request of
this e-mail. The fix is:

diff --git a/arch/arm/mach-mvebu/Makefile b/arch/arm/mach-mvebu/Makefile
index ca3b43f..90be143 100644
--- a/arch/arm/mach-mvebu/Makefile
+++ b/arch/arm/mach-mvebu/Makefile
@@ -6,6 +6,6 @@ AFLAGS_coherency_ll.o           := -Wa,-march=armv7-a
 obj-y                           += system-controller.o
 obj-$(CONFIG_MACH_ARMADA_370_XP) += armada-370-xp.o
 obj-$(CONFIG_ARCH_MVEBU)        += coherency.o coherency_ll.o
-obj-$(CONFIG_ARCH_MVEBU)        += pmsu.o irq-armada-370-xp.o
+obj-$(CONFIG_ARCH_MVEBU)        += pmsu.o
 obj-$(CONFIG_SMP)                += platsmp.o headsmp.o
 obj-$(CONFIG_HOTPLUG_CPU)        += hotplug.o

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From linux at arm.linux.org.uk  Thu Apr 18 05:48:55 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Thu, 18 Apr 2013 10:48:55 +0100
Subject: [PATCH 1/10] LPC32XX: 001-mmc.1: Define + Implement
 DMA_FORCE_BURST for pl032
In-Reply-To: <E1USZCP-0006Pl-UO@merlin.infradead.org>
References: <E1USZCP-0006Pl-UO@merlin.infradead.org>
Message-ID: <20130418094855.GJ14496@n2100.arm.linux.org.uk>

On Wed, Apr 17, 2013 at 10:42:49PM +0200, Cedric Berger wrote:
> Signed-off-by: Gabriele Mondada <gabriele at precidata.com>
> ---
> To implement the MMC driver on LPC32xx, we need a way to force a DMA burst by
> software. This patch defines a new DMA_FORCE_BURST hook and implements it for
> the pl08x.c

The above should be in the commit comments.  Also, consider copying Vinod
as this augments the DMA engine interface.


From linux at arm.linux.org.uk  Thu Apr 18 05:56:50 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Thu, 18 Apr 2013 10:56:50 +0100
Subject: [PATCH 2/10] LPC32XX: 002-mmc.1: Workaround for MMC+DMA on LPC32xx
In-Reply-To: <E1USZDI-0006T8-MV@merlin.infradead.org>
References: <E1USZDI-0006T8-MV@merlin.infradead.org>
Message-ID: <20130418095650.GK14496@n2100.arm.linux.org.uk>

On Wed, Apr 17, 2013 at 10:42:50PM +0200, Cedric Berger wrote:
> Signed-off-by: Gabriele Mondada <gabriele at precidata.com>
> ---
> the connection between the MMC controller and the DMA on NXP LPC32xx has
> silicon bugs. NXP did a patch to workaround this, but it has not been commited
> on the main branch. This is a rework of that patch for 3.9 kernel.

Again, this should be in the commit description.

> +#ifdef CONFIG_ARCH_LPC32XX
> +	/*
> +	 * The LPC32XX do not support sg on TX DMA. So
> +	 * a temporary bounce buffer is used if more than 1 sg segment
> +	 * is passed in the data request. The bounce buffer will get a
> +	 * contiguous copy of the TX data and it will be used instead.
> +	 */

I don't think this is a silicon bug.  If you read the PL08x and PL18x
manuals carefully, you will come to the realisation that the whole thing
is a buggered up design - the PL08x will ignore the individual segment
lengths when using flow control, and rely on the PL18x to tell it when
to move to the next DMA segment, but the PL18x will only signal that at
the end of the transfer.

Someone in ARM Ltd did not have their head screwed on properly when they
designed this.  I decided to totally scrap the idea of getting this crap
working on ARMs evaluation boards because of this - but if we have real
platforms with this problem, we shouldn't limit it to just those
platforms.

However, the problem affects both transmit and receive sides when flow
control is used - I don't remember if FC is supposed to be used with
receive with the PL18x though.


From plagnioj at jcrosoft.com  Thu Apr 18 06:01:32 2013
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Thu, 18 Apr 2013 12:01:32 +0200
Subject: [RFC] arm64: Early printk support for virtio-mmio console devices.
In-Reply-To: <CAAHg+HiHKV+8hBT1QWe4hSxocCX6wpRd3bCPWB7zU8jVFmPuAA@mail.gmail.com>
References: <1366264344-28025-1-git-send-email-pranavkumar@linaro.org>
 <87wqs02uws.fsf@rustcorp.com.au>
 <CAAHg+HiHKV+8hBT1QWe4hSxocCX6wpRd3bCPWB7zU8jVFmPuAA@mail.gmail.com>
Message-ID: <20130418100132.GE4998@game.jcrosoft.org>

On 13:02 Thu 18 Apr     , Pranavkumar Sawargaonkar wrote:
> On 18 April 2013 12:21, Rusty Russell <rusty at rustcorp.com.au> wrote:
> >
> > PranavkumarSawargaonkar <pranavkumar at linaro.org> writes:
> > > From: Pranavkumar Sawargaonkar <pranavkumar at linaro.org>
> > >
> > > This patch implements early printk support for virtio-mmio console devices without using any hypercalls.
> >
> > This makes some sense, though not sure that early console *read* makes
> > much sense.  I can see the PCI version of this being useful as well.
> 
> Read can be useful for "mach-virt" which will have only virtio console
> as a console device. Then if someone wants to have UEFI or any other
> boot-loader emulation, which expects user to input few things, in that
> case read might become handy.

yes I'm adding barebox on arm64 and will need it for virt target

Best Regards,
J.
> >
> >
> > The spec definition for this will be interesting, because it can be used
> > before the device is initialized (something which is generally
> > verboten).
> >
> > Cheers,
> > Rusty.
> 
> Thanks,
> Pranav
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From lee.jones at linaro.org  Thu Apr 18 06:11:42 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Thu, 18 Apr 2013 11:11:42 +0100
Subject: [PATCH 00/32] dmaengine: Refactor the DMA40 driver
Message-ID: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>

The aim of this patch-set is to refactor the DMA40 and its clients to
use the DMA APIs in the correct manor. It also encompasses a few
cleanups along the way.

When a client requests a channel, the driver should only do very basic
channel configuration, as the information passed from clients is very
limited at this stage. Instead, channels should be configured during a
separate call which is invoked after a channel number has been assigned.
This patch-set ensures that only the basic amount of configuration is
attempted at allocation time. By doing this, we're also allowing DMA
configuration to originate from Device Tree.

This process is ongoing, as there is still one outstanding client
waiting to be converted. The MSP (Audio) driver's DMA routines have
recently been adapted to this new way of doing things. Some patches
have been accepted, others are still on the lists. Once they have
all been applied, I can continue the refactoring process.

Ideally, I'd like this patch-set to go in order, as a full patch-set.
As to which tree it should go though, I don't have any strong
preference.

 Documentation/devicetree/bindings/dma/ste-dma40.txt |   66 ++++++++++++++++
 arch/arm/boot/dts/dbx5x0.dtsi                       |   46 ++++++++++-
 arch/arm/mach-ux500/board-mop500-audio.c            |   56 ++------------
 arch/arm/mach-ux500/board-mop500-sdi.c              |   40 ++--------
 arch/arm/mach-ux500/board-mop500.c                  |   49 +++---------
 arch/arm/mach-ux500/board-mop500.h                  |    1 +
 arch/arm/mach-ux500/cpu-db8500.c                    |   60 +++++----------
 arch/arm/mach-ux500/devices-db8500.c                |  163 +++++++++++++++------------------------
 arch/arm/mach-ux500/ste-dma40-db8500.h              |  193 ++++++++++++++++------------------------------
 arch/arm/mach-ux500/usb.c                           |   10 +--
 drivers/dma/ste_dma40.c                             |  376 ++++++++++++++++++++++++++++++++++++++++++++++++++++++------------------------------------
 drivers/dma/ste_dma40_ll.c                          |  112 +++++++++++++--------------
 drivers/dma/ste_dma40_ll.h                          |    5 +-
 include/linux/platform_data/dma-ste-dma40.h         |   16 +---
 14 files changed, 574 insertions(+), 619 deletions(-)






From lee.jones at linaro.org  Thu Apr 18 06:11:43 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Thu, 18 Apr 2013 11:11:43 +0100
Subject: [PATCH 01/32] dmaengine: ste_dma40: Assign memcpy channels in the
 driver
In-Reply-To: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1366279934-30761-2-git-send-email-lee.jones@linaro.org>

The channels reserved for memcpy are the same for all currently
supported platforms. With this in mind, we can ease the platform
data passing requirement by moving these assignments out from
platform code and place them directly into the driver.

Cc: Vinod Koul <vinod.koul at intel.com>
Cc: Dan Williams <djbw at fb.com>
Cc: Per Forlin <per.forlin at stericsson.com>
Cc: Rabin Vincent <rabin at rab.in>
Acked-by: Arnd Bergmann <arnd at arndb.de>
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/mach-ux500/devices-db8500.c        |   12 ------------
 drivers/dma/ste_dma40.c                     |   12 +++++++-----
 include/linux/platform_data/dma-ste-dma40.h |    4 ----
 3 files changed, 7 insertions(+), 21 deletions(-)

diff --git a/arch/arm/mach-ux500/devices-db8500.c b/arch/arm/mach-ux500/devices-db8500.c
index afa5b04..9b09683 100644
--- a/arch/arm/mach-ux500/devices-db8500.c
+++ b/arch/arm/mach-ux500/devices-db8500.c
@@ -146,22 +146,10 @@ static const dma_addr_t dma40_rx_map[DB8500_DMA_NR_DEV] = {
 	[DB8500_DMA_DEV48_CAC1_RX] = U8500_CRYP1_BASE + CRYP1_RX_REG_OFFSET,
 };
 
-/* Reserved event lines for memcpy only */
-static int dma40_memcpy_event[] = {
-	DB8500_DMA_MEMCPY_TX_0,
-	DB8500_DMA_MEMCPY_TX_1,
-	DB8500_DMA_MEMCPY_TX_2,
-	DB8500_DMA_MEMCPY_TX_3,
-	DB8500_DMA_MEMCPY_TX_4,
-	DB8500_DMA_MEMCPY_TX_5,
-};
-
 static struct stedma40_platform_data dma40_plat_data = {
 	.dev_len = DB8500_DMA_NR_DEV,
 	.dev_rx = dma40_rx_map,
 	.dev_tx = dma40_tx_map,
-	.memcpy = dma40_memcpy_event,
-	.memcpy_len = ARRAY_SIZE(dma40_memcpy_event),
 	.memcpy_conf_phy = &dma40_memcpy_conf_phy,
 	.memcpy_conf_log = &dma40_memcpy_conf_log,
 	.disabled_channels = {-1},
diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index 1734fee..12de79e 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -55,6 +55,9 @@
 
 #define MAX(a, b) (((a) < (b)) ? (b) : (a))
 
+/* Reserved event lines for memcpy only. */
+static int dma40_memcpy_channels[] = { 56, 57, 58, 59, 60 };
+
 /**
  * enum 40_command - The different commands and/or statuses.
  *
@@ -2014,8 +2017,7 @@ static int d40_config_memcpy(struct d40_chan *d40c)
 	if (dma_has_cap(DMA_MEMCPY, cap) && !dma_has_cap(DMA_SLAVE, cap)) {
 		d40c->dma_cfg = *d40c->base->plat_data->memcpy_conf_log;
 		d40c->dma_cfg.src_dev_type = STEDMA40_DEV_SRC_MEMORY;
-		d40c->dma_cfg.dst_dev_type = d40c->base->plat_data->
-			memcpy[d40c->chan.chan_id];
+		d40c->dma_cfg.dst_dev_type = dma40_memcpy_channels[d40c->chan.chan_id];
 
 	} else if (dma_has_cap(DMA_MEMCPY, cap) &&
 		   dma_has_cap(DMA_SLAVE, cap)) {
@@ -2927,7 +2929,7 @@ static int __init d40_dmaengine_init(struct d40_base *base,
 	}
 
 	d40_chan_init(base, &base->dma_memcpy, base->log_chans,
-		      base->num_log_chans, base->plat_data->memcpy_len);
+		      base->num_log_chans, ARRAY_SIZE(dma40_memcpy_channels));
 
 	dma_cap_zero(base->dma_memcpy.cap_mask);
 	dma_cap_set(DMA_MEMCPY, base->dma_memcpy.cap_mask);
@@ -3215,7 +3217,7 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
 			num_log_chans++;
 
 	base = kzalloc(ALIGN(sizeof(struct d40_base), 4) +
-		       (num_phy_chans + num_log_chans + plat_data->memcpy_len) *
+		       (num_phy_chans + num_log_chans + ARRAY_SIZE(dma40_memcpy_channels)) *
 		       sizeof(struct d40_chan), GFP_KERNEL);
 
 	if (base == NULL) {
@@ -3276,7 +3278,7 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
 	if (!base->lookup_phy_chans)
 		goto failure;
 
-	if (num_log_chans + plat_data->memcpy_len) {
+	if (num_log_chans + ARRAY_SIZE(dma40_memcpy_channels)) {
 		/*
 		 * The max number of logical channels are event lines for all
 		 * src devices and dst devices
diff --git a/include/linux/platform_data/dma-ste-dma40.h b/include/linux/platform_data/dma-ste-dma40.h
index 4b78101..a808784 100644
--- a/include/linux/platform_data/dma-ste-dma40.h
+++ b/include/linux/platform_data/dma-ste-dma40.h
@@ -141,8 +141,6 @@ struct stedma40_chan_cfg {
  * @dev_len: length of dev_tx and dev_rx
  * @dev_tx: mapping between destination event line and io address
  * @dev_rx: mapping between source event line and io address
- * @memcpy: list of memcpy event lines
- * @memcpy_len: length of memcpy
  * @memcpy_conf_phy: default configuration of physical channel memcpy
  * @memcpy_conf_log: default configuration of logical channel memcpy
  * @disabled_channels: A vector, ending with -1, that marks physical channels
@@ -162,8 +160,6 @@ struct stedma40_platform_data {
 	u32				 dev_len;
 	const dma_addr_t		*dev_tx;
 	const dma_addr_t		*dev_rx;
-	int				*memcpy;
-	u32				 memcpy_len;
 	struct stedma40_chan_cfg	*memcpy_conf_phy;
 	struct stedma40_chan_cfg	*memcpy_conf_log;
 	int				 disabled_channels[STEDMA40_MAX_PHYS];
-- 
1.7.10.4



From lee.jones at linaro.org  Thu Apr 18 06:11:44 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Thu, 18 Apr 2013 11:11:44 +0100
Subject: [PATCH 02/32] dmaengine: ste_dma40: Move default memcpy configs into
 the driver
In-Reply-To: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1366279934-30761-3-git-send-email-lee.jones@linaro.org>

There are only two default memcpy configurations used for the DMA40
driver; one for physical memcpy and one for logical memcpy. Instead
of invariably passing the same configurations though platform data,
we're moving them into the driver instead.

Cc: Vinod Koul <vinod.koul at intel.com>
Cc: Dan Williams <djbw at fb.com>
Cc: Per Forlin <per.forlin at stericsson.com>
Cc: Rabin Vincent <rabin at rab.in>
Acked-by: Arnd Bergmann <arnd at arndb.de>
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/mach-ux500/devices-db8500.c        |   28 -----------------------
 drivers/dma/ste_dma40.c                     |   32 +++++++++++++++++++++++++--
 include/linux/platform_data/dma-ste-dma40.h |    4 ----
 3 files changed, 30 insertions(+), 34 deletions(-)

diff --git a/arch/arm/mach-ux500/devices-db8500.c b/arch/arm/mach-ux500/devices-db8500.c
index 9b09683..5b1f1f7 100644
--- a/arch/arm/mach-ux500/devices-db8500.c
+++ b/arch/arm/mach-ux500/devices-db8500.c
@@ -42,32 +42,6 @@ static struct resource dma40_resources[] = {
 	}
 };
 
-/* Default configuration for physcial memcpy */
-struct stedma40_chan_cfg dma40_memcpy_conf_phy = {
-	.mode = STEDMA40_MODE_PHYSICAL,
-	.dir = STEDMA40_MEM_TO_MEM,
-
-	.src_info.data_width = STEDMA40_BYTE_WIDTH,
-	.src_info.psize = STEDMA40_PSIZE_PHY_1,
-	.src_info.flow_ctrl = STEDMA40_NO_FLOW_CTRL,
-
-	.dst_info.data_width = STEDMA40_BYTE_WIDTH,
-	.dst_info.psize = STEDMA40_PSIZE_PHY_1,
-	.dst_info.flow_ctrl = STEDMA40_NO_FLOW_CTRL,
-};
-/* Default configuration for logical memcpy */
-struct stedma40_chan_cfg dma40_memcpy_conf_log = {
-	.dir = STEDMA40_MEM_TO_MEM,
-
-	.src_info.data_width = STEDMA40_BYTE_WIDTH,
-	.src_info.psize = STEDMA40_PSIZE_LOG_1,
-	.src_info.flow_ctrl = STEDMA40_NO_FLOW_CTRL,
-
-	.dst_info.data_width = STEDMA40_BYTE_WIDTH,
-	.dst_info.psize = STEDMA40_PSIZE_LOG_1,
-	.dst_info.flow_ctrl = STEDMA40_NO_FLOW_CTRL,
-};
-
 /*
  * Mapping between destination event lines and physical device address.
  * The event line is tied to a device and therefore the address is constant.
@@ -150,8 +124,6 @@ static struct stedma40_platform_data dma40_plat_data = {
 	.dev_len = DB8500_DMA_NR_DEV,
 	.dev_rx = dma40_rx_map,
 	.dev_tx = dma40_tx_map,
-	.memcpy_conf_phy = &dma40_memcpy_conf_phy,
-	.memcpy_conf_log = &dma40_memcpy_conf_log,
 	.disabled_channels = {-1},
 };
 
diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index 12de79e..3b83dee 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -58,6 +58,34 @@
 /* Reserved event lines for memcpy only. */
 static int dma40_memcpy_channels[] = { 56, 57, 58, 59, 60 };
 
+/* Default configuration for physcial memcpy */
+struct stedma40_chan_cfg dma40_memcpy_conf_phy = {
+	.mode = STEDMA40_MODE_PHYSICAL,
+	.dir = STEDMA40_MEM_TO_MEM,
+
+	.src_info.data_width = STEDMA40_BYTE_WIDTH,
+	.src_info.psize = STEDMA40_PSIZE_PHY_1,
+	.src_info.flow_ctrl = STEDMA40_NO_FLOW_CTRL,
+
+	.dst_info.data_width = STEDMA40_BYTE_WIDTH,
+	.dst_info.psize = STEDMA40_PSIZE_PHY_1,
+	.dst_info.flow_ctrl = STEDMA40_NO_FLOW_CTRL,
+};
+
+/* Default configuration for logical memcpy */
+struct stedma40_chan_cfg dma40_memcpy_conf_log = {
+	.mode = STEDMA40_MODE_LOGICAL,
+	.dir = STEDMA40_MEM_TO_MEM,
+
+	.src_info.data_width = STEDMA40_BYTE_WIDTH,
+	.src_info.psize = STEDMA40_PSIZE_LOG_1,
+	.src_info.flow_ctrl = STEDMA40_NO_FLOW_CTRL,
+
+	.dst_info.data_width = STEDMA40_BYTE_WIDTH,
+	.dst_info.psize = STEDMA40_PSIZE_LOG_1,
+	.dst_info.flow_ctrl = STEDMA40_NO_FLOW_CTRL,
+};
+
 /**
  * enum 40_command - The different commands and/or statuses.
  *
@@ -2015,13 +2043,13 @@ static int d40_config_memcpy(struct d40_chan *d40c)
 	dma_cap_mask_t cap = d40c->chan.device->cap_mask;
 
 	if (dma_has_cap(DMA_MEMCPY, cap) && !dma_has_cap(DMA_SLAVE, cap)) {
-		d40c->dma_cfg = *d40c->base->plat_data->memcpy_conf_log;
+		d40c->dma_cfg = dma40_memcpy_conf_log;
 		d40c->dma_cfg.src_dev_type = STEDMA40_DEV_SRC_MEMORY;
 		d40c->dma_cfg.dst_dev_type = dma40_memcpy_channels[d40c->chan.chan_id];
 
 	} else if (dma_has_cap(DMA_MEMCPY, cap) &&
 		   dma_has_cap(DMA_SLAVE, cap)) {
-		d40c->dma_cfg = *d40c->base->plat_data->memcpy_conf_phy;
+		d40c->dma_cfg = dma40_memcpy_conf_phy;
 	} else {
 		chan_err(d40c, "No memcpy\n");
 		return -EINVAL;
diff --git a/include/linux/platform_data/dma-ste-dma40.h b/include/linux/platform_data/dma-ste-dma40.h
index a808784..869c571 100644
--- a/include/linux/platform_data/dma-ste-dma40.h
+++ b/include/linux/platform_data/dma-ste-dma40.h
@@ -141,8 +141,6 @@ struct stedma40_chan_cfg {
  * @dev_len: length of dev_tx and dev_rx
  * @dev_tx: mapping between destination event line and io address
  * @dev_rx: mapping between source event line and io address
- * @memcpy_conf_phy: default configuration of physical channel memcpy
- * @memcpy_conf_log: default configuration of logical channel memcpy
  * @disabled_channels: A vector, ending with -1, that marks physical channels
  * that are for different reasons not available for the driver.
  * @soft_lli_chans: A vector, that marks physical channels will use LLI by SW
@@ -160,8 +158,6 @@ struct stedma40_platform_data {
 	u32				 dev_len;
 	const dma_addr_t		*dev_tx;
 	const dma_addr_t		*dev_rx;
-	struct stedma40_chan_cfg	*memcpy_conf_phy;
-	struct stedma40_chan_cfg	*memcpy_conf_log;
 	int				 disabled_channels[STEDMA40_MAX_PHYS];
 	int				*soft_lli_chans;
 	int				 num_of_soft_lli_chans;
-- 
1.7.10.4



From lee.jones at linaro.org  Thu Apr 18 06:11:45 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Thu, 18 Apr 2013 11:11:45 +0100
Subject: [PATCH 03/32] dmaengine: ste_dma40: Use the BIT macro to replace ugly
 '(1 << x)'s
In-Reply-To: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1366279934-30761-4-git-send-email-lee.jones@linaro.org>

The aim is to make the code that little more readable.

Cc: Vinod Koul <vinod.koul at intel.com>
Cc: Dan Williams <djbw at fb.com>
Cc: Per Forlin <per.forlin at stericsson.com>
Cc: Rabin Vincent <rabin at rab.in>
Acked-by: Arnd Bergmann <arnd at arndb.de>
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 drivers/dma/ste_dma40.c |   34 +++++++++++++++++-----------------
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index 3b83dee..121c46b 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -49,9 +49,9 @@
 #define MAX_LCLA_ALLOC_ATTEMPTS 256
 
 /* Bit markings for allocation map */
-#define D40_ALLOC_FREE		(1 << 31)
-#define D40_ALLOC_PHY		(1 << 30)
-#define D40_ALLOC_LOG_FREE	0
+#define D40_ALLOC_FREE		BIT(31)
+#define D40_ALLOC_PHY		BIT(30)
+#define D40_ALLOC_LOG_FREE	BIT(0)
 
 #define MAX(a, b) (((a) < (b)) ? (b) : (a))
 
@@ -993,12 +993,12 @@ static int d40_size_2_dmalen(int size, u32 data_width1, u32 data_width2)
 	int dmalen;
 	u32 max_w = max(data_width1, data_width2);
 	u32 min_w = min(data_width1, data_width2);
-	u32 seg_max = ALIGN(STEDMA40_MAX_SEG_SIZE << min_w, 1 << max_w);
+	u32 seg_max = ALIGN(STEDMA40_MAX_SEG_SIZE << min_w, BIT(max_w));
 
 	if (seg_max > STEDMA40_MAX_SEG_SIZE)
-		seg_max -= (1 << max_w);
+		seg_max -= BIT(max_w);
 
-	if (!IS_ALIGNED(size, 1 << max_w))
+	if (!IS_ALIGNED(size, BIT(max_w)))
 		return -EINVAL;
 
 	if (size <= seg_max)
@@ -1448,7 +1448,7 @@ static u32 d40_residue(struct d40_chan *d40c)
 			  >> D40_SREG_ELEM_PHY_ECNT_POS;
 	}
 
-	return num_elt * (1 << d40c->dma_cfg.dst_info.data_width);
+	return num_elt * BIT(d40c->dma_cfg.dst_info.data_width);
 }
 
 static bool d40_tx_is_linked(struct d40_chan *d40c)
@@ -1722,7 +1722,7 @@ static irqreturn_t d40_handle_interrupt(int irq, void *data)
 		}
 
 		/* ACK interrupt */
-		writel(1 << idx, base->virtbase + il[row].clr);
+		writel(BIT(idx), base->virtbase + il[row].clr);
 
 		spin_lock(&d40c->lock);
 
@@ -1804,9 +1804,9 @@ static int d40_validate_conf(struct d40_chan *d40c,
 	}
 
 	if (d40_psize_2_burst_size(is_log, conf->src_info.psize) *
-	    (1 << conf->src_info.data_width) !=
+	    BIT(conf->src_info.data_width) !=
 	    d40_psize_2_burst_size(is_log, conf->dst_info.psize) *
-	    (1 << conf->dst_info.data_width)) {
+	    BIT(conf->dst_info.data_width)) {
 		/*
 		 * The DMAC hardware only supports
 		 * src (burst x width) == dst (burst x width)
@@ -1848,8 +1848,8 @@ static bool d40_alloc_mask_set(struct d40_phy_res *phy,
 		if (phy->allocated_src == D40_ALLOC_FREE)
 			phy->allocated_src = D40_ALLOC_LOG_FREE;
 
-		if (!(phy->allocated_src & (1 << log_event_line))) {
-			phy->allocated_src |= 1 << log_event_line;
+		if (!(phy->allocated_src & BIT(log_event_line))) {
+			phy->allocated_src |= BIT(log_event_line);
 			goto found;
 		} else
 			goto not_found;
@@ -1860,8 +1860,8 @@ static bool d40_alloc_mask_set(struct d40_phy_res *phy,
 		if (phy->allocated_dst == D40_ALLOC_FREE)
 			phy->allocated_dst = D40_ALLOC_LOG_FREE;
 
-		if (!(phy->allocated_dst & (1 << log_event_line))) {
-			phy->allocated_dst |= 1 << log_event_line;
+		if (!(phy->allocated_dst & BIT(log_event_line))) {
+			phy->allocated_dst |= BIT(log_event_line);
 			goto found;
 		} else
 			goto not_found;
@@ -1891,11 +1891,11 @@ static bool d40_alloc_mask_free(struct d40_phy_res *phy, bool is_src,
 
 	/* Logical channel */
 	if (is_src) {
-		phy->allocated_src &= ~(1 << log_event_line);
+		phy->allocated_src &= ~BIT(log_event_line);
 		if (phy->allocated_src == D40_ALLOC_LOG_FREE)
 			phy->allocated_src = D40_ALLOC_FREE;
 	} else {
-		phy->allocated_dst &= ~(1 << log_event_line);
+		phy->allocated_dst &= ~BIT(log_event_line);
 		if (phy->allocated_dst == D40_ALLOC_LOG_FREE)
 			phy->allocated_dst = D40_ALLOC_FREE;
 	}
@@ -2394,7 +2394,7 @@ static void __d40_set_prio_rt(struct d40_chan *d40c, int dev_type, bool src)
 	u32 rtreg;
 	u32 event = D40_TYPE_TO_EVENT(dev_type);
 	u32 group = D40_TYPE_TO_GROUP(dev_type);
-	u32 bit = 1 << event;
+	u32 bit = BIT(event);
 	u32 prioreg;
 	struct d40_gen_dmac *dmac = &d40c->base->gen_dmac;
 
-- 
1.7.10.4



From lee.jones at linaro.org  Thu Apr 18 06:11:47 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Thu, 18 Apr 2013 11:11:47 +0100
Subject: [PATCH 05/32] dmaengine: ste_dma40: Supply macros to resolve 'src'
 and 'dst' directions
In-Reply-To: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1366279934-30761-6-git-send-email-lee.jones@linaro.org>

There are lots of lengthy if() statements located sporadically up and
down the driver. This simple macro should make many of them a little
simpler to decipher. The remainder have to stay in place, as they
detail slightly more specific settings.

Cc: Vinod Koul <vinod.koul at intel.com>
Cc: Dan Williams <djbw at fb.com>
Cc: Per Forlin <per.forlin at stericsson.com>
Cc: Rabin Vincent <rabin at rab.in>
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 drivers/dma/ste_dma40.c |   38 ++++++++++++++++++++------------------
 1 file changed, 20 insertions(+), 18 deletions(-)

diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index e50354d..b21a8a3 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -55,6 +55,10 @@
 
 #define MAX(a, b) (((a) < (b)) ? (b) : (a))
 
+#define D40_IS_SRC(dir)  ((dir == STEDMA40_PERIPH_TO_MEM) ? true : false)
+#define D40_IS_DST(dir) (((dir == STEDMA40_MEM_TO_PERIPH) || \
+			  (dir == STEDMA40_MEM_TO_MEM)) ? true : false)
+
 /* Reserved event lines for memcpy only. */
 static int dma40_memcpy_channels[] = { 56, 57, 58, 59, 60 };
 
@@ -823,7 +827,7 @@ static void d40_log_lli_to_lcxa(struct d40_chan *chan, struct d40_desc *desc)
 		 * that uses linked lists.
 		 */
 		if (!(chan->phy_chan->use_soft_lli &&
-			chan->dma_cfg.dir == STEDMA40_PERIPH_TO_MEM))
+		      D40_IS_SRC(chan->dma_cfg.dir)))
 			curr_lcla = d40_lcla_alloc_one(chan, desc);
 
 		first_lcla = curr_lcla;
@@ -1291,12 +1295,12 @@ static void d40_config_set_event(struct d40_chan *d40c,
 	u32 event = D40_TYPE_TO_EVENT(d40c->dma_cfg.dev_type);
 
 	/* Enable event line connected to device (or memcpy) */
-	if ((d40c->dma_cfg.dir ==  STEDMA40_PERIPH_TO_MEM) ||
+	if (D40_IS_SRC(d40c->dma_cfg.dir) ||
 	    (d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_PERIPH))
 		__d40_config_set_event(d40c, event_type, event,
 				       D40_CHAN_REG_SSLNK);
 
-	if (d40c->dma_cfg.dir !=  STEDMA40_PERIPH_TO_MEM)
+	if (!D40_IS_SRC(d40c->dma_cfg.dir))
 		__d40_config_set_event(d40c, event_type, event,
 				       D40_CHAN_REG_SDLNK);
 }
@@ -1762,7 +1766,7 @@ static int d40_validate_conf(struct d40_chan *d40c,
 		res = -EINVAL;
 	}
 
-	if (conf->dir == STEDMA40_PERIPH_TO_MEM &&
+	if (D40_IS_SRC(conf->dir) &&
 	    d40c->base->plat_data->dev_rx[conf->dev_type] == 0 &&
 	    d40c->runtime_addr == 0) {
 		chan_err(d40c, "Invalid RX channel address (%d)\n",
@@ -1895,17 +1899,17 @@ static int d40_allocate_channel(struct d40_chan *d40c, bool *first_phy_user)
 	int j;
 	int log_num;
 	int num_phy_chans;
+	int dir = d40c->dma_cfg.dir;
 	bool is_src;
 	bool is_log = d40c->dma_cfg.mode == STEDMA40_MODE_LOGICAL;
 
 	phys = d40c->base->phy_res;
 	num_phy_chans = d40c->base->num_phy_chans;
 
-	if (d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_MEM) {
+	if (D40_IS_SRC(dir)) {
 		log_num = 2 * dev_type;
 		is_src = true;
-	} else if (d40c->dma_cfg.dir == STEDMA40_MEM_TO_PERIPH ||
-		   d40c->dma_cfg.dir == STEDMA40_MEM_TO_MEM) {
+	} else if (D40_IS_DST(dir)) {
 		/* dst event lines are used for logical memcpy */
 		log_num = 2 * dev_type + 1;
 		is_src = false;
@@ -1916,7 +1920,7 @@ static int d40_allocate_channel(struct d40_chan *d40c, bool *first_phy_user)
 	event_line = D40_TYPE_TO_EVENT(dev_type);
 
 	if (!is_log) {
-		if (d40c->dma_cfg.dir == STEDMA40_MEM_TO_MEM) {
+		if (dir == STEDMA40_MEM_TO_MEM) {
 			/* Find physical half channel */
 			if (d40c->dma_cfg.use_fixed_channel) {
 				i = d40c->dma_cfg.phy_channel;
@@ -2053,11 +2057,10 @@ static int d40_free_dma(struct d40_chan *d40c)
 		return -EINVAL;
 	}
 
-	if (d40c->dma_cfg.dir == STEDMA40_MEM_TO_PERIPH ||
-	    d40c->dma_cfg.dir == STEDMA40_MEM_TO_MEM)
-		is_src = false;
-	else if (d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_MEM)
+	if (D40_IS_SRC(d40c->dma_cfg.dir))
 		is_src = true;
+	else if (D40_IS_DST(d40c->dma_cfg.dir))
+		is_src = false;
 	else {
 		chan_err(d40c, "Unknown direction\n");
 		return -EINVAL;
@@ -2118,12 +2121,11 @@ static bool d40_is_paused(struct d40_chan *d40c)
 		goto _exit;
 	}
 
-	if (d40c->dma_cfg.dir == STEDMA40_MEM_TO_PERIPH ||
-	    d40c->dma_cfg.dir == STEDMA40_MEM_TO_MEM) {
-		status = readl(chanbase + D40_CHAN_REG_SDLNK);
-	} else if (d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_MEM) {
+	if (D40_IS_SRC(d40c->dma_cfg.dir))
 		status = readl(chanbase + D40_CHAN_REG_SSLNK);
-	} else {
+	else if (D40_IS_DST(d40c->dma_cfg.dir))
+		status = readl(chanbase + D40_CHAN_REG_SDLNK);
+	else {
 		chan_err(d40c, "Unknown direction\n");
 		goto _exit;
 	}
@@ -2394,7 +2396,7 @@ static void d40_set_prio_realtime(struct d40_chan *d40c)
 	if (d40c->base->rev < 3)
 		return;
 
-	if ((d40c->dma_cfg.dir ==  STEDMA40_PERIPH_TO_MEM) ||
+	if (D40_IS_SRC(d40c->dma_cfg.dir) ||
 	    (d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_PERIPH))
 		__d40_set_prio_rt(d40c, d40c->dma_cfg.dev_type, true);
 
-- 
1.7.10.4



From lee.jones at linaro.org  Thu Apr 18 06:11:48 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Thu, 18 Apr 2013 11:11:48 +0100
Subject: [PATCH 06/32] ARM: ux500: Strip out duplicate USB DMA configuration
In-Reply-To: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1366279934-30761-7-git-send-email-lee.jones@linaro.org>

For the moment at least, the TX and RX channels for DB8500 USB are
identical, so this patch generalises them into a single structure
and passes it twice. Once as the TX and again for the RX configuration.
We're keeping the infrastructure the same i.e. passing the TX and RX
separately in case they start to differ on latter incarnations of the
platform.

Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/mach-ux500/cpu-db8500.c |   17 +++--------------
 1 file changed, 3 insertions(+), 14 deletions(-)

diff --git a/arch/arm/mach-ux500/cpu-db8500.c b/arch/arm/mach-ux500/cpu-db8500.c
index f72cc9b..a15678d 100644
--- a/arch/arm/mach-ux500/cpu-db8500.c
+++ b/arch/arm/mach-ux500/cpu-db8500.c
@@ -166,18 +166,7 @@ static void __init db8500_add_gpios(struct device *parent)
 	dbx500_add_pinctrl(parent, "pinctrl-db8500", U8500_PRCMU_BASE);
 }
 
-static int usb_db8500_rx_dma_cfg[] = {
-	DB8500_DMA_DEV38_USB_OTG_IEP_AND_OEP_1_9,
-	DB8500_DMA_DEV37_USB_OTG_IEP_AND_OEP_2_10,
-	DB8500_DMA_DEV36_USB_OTG_IEP_AND_OEP_3_11,
-	DB8500_DMA_DEV19_USB_OTG_IEP_AND_OEP_4_12,
-	DB8500_DMA_DEV18_USB_OTG_IEP_AND_OEP_5_13,
-	DB8500_DMA_DEV17_USB_OTG_IEP_AND_OEP_6_14,
-	DB8500_DMA_DEV16_USB_OTG_IEP_AND_OEP_7_15,
-	DB8500_DMA_DEV39_USB_OTG_IEP_AND_OEP_8
-};
-
-static int usb_db8500_tx_dma_cfg[] = {
+static int usb_db8500_dma_cfg[] = {
 	DB8500_DMA_DEV38_USB_OTG_IEP_AND_OEP_1_9,
 	DB8500_DMA_DEV37_USB_OTG_IEP_AND_OEP_2_10,
 	DB8500_DMA_DEV36_USB_OTG_IEP_AND_OEP_3_11,
@@ -219,7 +208,7 @@ struct device * __init u8500_init_devices(struct ab8500_platform_data *ab8500)
 
 	db8500_add_rtc(parent);
 	db8500_add_gpios(parent);
-	db8500_add_usb(parent, usb_db8500_rx_dma_cfg, usb_db8500_tx_dma_cfg);
+	db8500_add_usb(parent, usb_db8500_dma_cfg, usb_db8500_dma_cfg);
 
 	for (i = 0; i < ARRAY_SIZE(platform_devs); i++)
 		platform_devs[i]->dev.parent = parent;
@@ -238,7 +227,7 @@ static struct device * __init u8500_of_init_devices(void)
 {
 	struct device *parent = db8500_soc_device_init();
 
-	db8500_add_usb(parent, usb_db8500_rx_dma_cfg, usb_db8500_tx_dma_cfg);
+	db8500_add_usb(parent, usb_db8500_dma_cfg, usb_db8500_dma_cfg);
 
 	u8500_dma40_device.dev.parent = parent;
 
-- 
1.7.10.4



From lee.jones at linaro.org  Thu Apr 18 06:11:49 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Thu, 18 Apr 2013 11:11:49 +0100
Subject: [PATCH 07/32] ARM: ux500: Supply address location names for the DMA40
 DMA controller
In-Reply-To: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1366279934-30761-8-git-send-email-lee.jones@linaro.org>

The DMA40 controller uses two sets of base addresses. In order to have
them automatically setup as resources by the Open Format framework we
have to set names for them. The names have to be the same as the ones
used to fetch them back out of the resource structure.

Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/boot/dts/dbx5x0.dtsi |    1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/dbx5x0.dtsi b/arch/arm/boot/dts/dbx5x0.dtsi
index aaa63d0..0f462b7 100644
--- a/arch/arm/boot/dts/dbx5x0.dtsi
+++ b/arch/arm/boot/dts/dbx5x0.dtsi
@@ -186,6 +186,7 @@
 			compatible = "stericsson,db8500-dma40",
 					"stericsson,dma40";
 			reg = <0x801C0000 0x1000 0x40010000 0x800>;
+			reg-names = "base", "lcpa";
 			interrupts = <0 25 0x4>;
 		};
 
-- 
1.7.10.4



From lee.jones at linaro.org  Thu Apr 18 06:11:56 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Thu, 18 Apr 2013 11:11:56 +0100
Subject: [PATCH 14/32] dmaengine: ste_dma40: Remove 'always true' checking
In-Reply-To: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1366279934-30761-15-git-send-email-lee.jones@linaro.org>

Before allocating memory for logical channels, the current driver
checks to see if there are any. Well as the dma40_memcpy_channels[]
array is always populated, the check is always true. Best to
remove the check.

Cc: Vinod Koul <vinod.koul at intel.com>
Cc: Dan Williams <djbw at fb.com>
Cc: Per Forlin <per.forlin at stericsson.com>
Cc: Rabin Vincent <rabin at rab.in>
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 drivers/dma/ste_dma40.c |   16 +++++-----------
 1 file changed, 5 insertions(+), 11 deletions(-)

diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index a39ef74..ec0d6ab 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -3273,17 +3273,11 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
 	if (!base->lookup_phy_chans)
 		goto failure;
 
-	if (num_log_chans + ARRAY_SIZE(dma40_memcpy_channels)) {
-		/*
-		 * The max number of logical channels are event lines for all
-		 * src devices and dst devices
-		 */
-		base->lookup_log_chans = kzalloc(num_log_chans *
-						 sizeof(struct d40_chan *),
-						 GFP_KERNEL);
-		if (!base->lookup_log_chans)
-			goto failure;
-	}
+	base->lookup_log_chans = kzalloc(num_log_chans *
+					 sizeof(struct d40_chan *),
+					 GFP_KERNEL);
+	if (!base->lookup_log_chans)
+		goto failure;
 
 	base->reg_val_backup_chan = kmalloc(base->num_phy_chans *
 					    sizeof(d40_backup_regs_chan),
-- 
1.7.10.4



From lee.jones at linaro.org  Thu Apr 18 06:11:50 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Thu, 18 Apr 2013 11:11:50 +0100
Subject: [PATCH 08/32] dmaengine: ste_dma40: Optimise local MAX() macro
In-Reply-To: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1366279934-30761-9-git-send-email-lee.jones@linaro.org>

The current implementation of the DMA40's local MAX() macro evaluates
its arguments more times than is necessary. This patch strips it
optimises it to only evaluate what's appropriate.

Cc: Vinod Koul <vinod.koul at intel.com>
Cc: Dan Williams <djbw at fb.com>
Cc: Per Forlin <per.forlin at stericsson.com>
Cc: Rabin Vincent <rabin at rab.in>
Reported-by: Harvey Harrison <harvey.harrison at gmail.com>
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 drivers/dma/ste_dma40.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index b21a8a3..7b451b2 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -53,7 +53,7 @@
 #define D40_ALLOC_PHY		BIT(30)
 #define D40_ALLOC_LOG_FREE	BIT(0)
 
-#define MAX(a, b) (((a) < (b)) ? (b) : (a))
+#define MAX(a, b) ((a > b) ? a : b)
 
 #define D40_IS_SRC(dir)  ((dir == STEDMA40_PERIPH_TO_MEM) ? true : false)
 #define D40_IS_DST(dir) (((dir == STEDMA40_MEM_TO_PERIPH) || \
-- 
1.7.10.4



From lee.jones at linaro.org  Thu Apr 18 06:11:51 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Thu, 18 Apr 2013 11:11:51 +0100
Subject: [PATCH 09/32] ARM: ux500: Remove unused 'data_width' attributes from
 SDI DMA configs
In-Reply-To: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1366279934-30761-10-git-send-email-lee.jones@linaro.org>

DMA configuration data is now allocated in the MMCI driver, so these
are just ignored.

Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/mach-ux500/board-mop500-sdi.c |   16 ----------------
 1 file changed, 16 deletions(-)

diff --git a/arch/arm/mach-ux500/board-mop500-sdi.c b/arch/arm/mach-ux500/board-mop500-sdi.c
index 5c28216..553ace6 100644
--- a/arch/arm/mach-ux500/board-mop500-sdi.c
+++ b/arch/arm/mach-ux500/board-mop500-sdi.c
@@ -65,16 +65,12 @@ struct stedma40_chan_cfg mop500_sdi0_dma_cfg_rx = {
 	.mode = STEDMA40_MODE_LOGICAL,
 	.dir = STEDMA40_PERIPH_TO_MEM,
 	.dev_type = DB8500_DMA_DEV29_SD_MM0,
-	.src_info.data_width = STEDMA40_WORD_WIDTH,
-	.dst_info.data_width = STEDMA40_WORD_WIDTH,
 };
 
 static struct stedma40_chan_cfg mop500_sdi0_dma_cfg_tx = {
 	.mode = STEDMA40_MODE_LOGICAL,
 	.dir = STEDMA40_MEM_TO_PERIPH,
 	.dev_type = DB8500_DMA_DEV29_SD_MM0,
-	.src_info.data_width = STEDMA40_WORD_WIDTH,
-	.dst_info.data_width = STEDMA40_WORD_WIDTH,
 };
 #endif
 
@@ -134,16 +130,12 @@ static struct stedma40_chan_cfg sdi1_dma_cfg_rx = {
 	.mode = STEDMA40_MODE_LOGICAL,
 	.dir = STEDMA40_PERIPH_TO_MEM,
 	.dev_type = DB8500_DMA_DEV32_SD_MM1,
-	.src_info.data_width = STEDMA40_WORD_WIDTH,
-	.dst_info.data_width = STEDMA40_WORD_WIDTH,
 };
 
 static struct stedma40_chan_cfg sdi1_dma_cfg_tx = {
 	.mode = STEDMA40_MODE_LOGICAL,
 	.dir = STEDMA40_MEM_TO_PERIPH,
 	.dev_type = DB8500_DMA_DEV32_SD_MM1,
-	.src_info.data_width = STEDMA40_WORD_WIDTH,
-	.dst_info.data_width = STEDMA40_WORD_WIDTH,
 };
 #endif
 
@@ -169,16 +161,12 @@ struct stedma40_chan_cfg mop500_sdi2_dma_cfg_rx = {
 	.mode = STEDMA40_MODE_LOGICAL,
 	.dir = STEDMA40_PERIPH_TO_MEM,
 	.dev_type =  DB8500_DMA_DEV28_SD_MM2,
-	.src_info.data_width = STEDMA40_WORD_WIDTH,
-	.dst_info.data_width = STEDMA40_WORD_WIDTH,
 };
 
 static struct stedma40_chan_cfg mop500_sdi2_dma_cfg_tx = {
 	.mode = STEDMA40_MODE_LOGICAL,
 	.dir = STEDMA40_MEM_TO_PERIPH,
 	.dev_type = DB8500_DMA_DEV28_SD_MM2,
-	.src_info.data_width = STEDMA40_WORD_WIDTH,
-	.dst_info.data_width = STEDMA40_WORD_WIDTH,
 };
 #endif
 
@@ -205,16 +193,12 @@ struct stedma40_chan_cfg mop500_sdi4_dma_cfg_rx = {
 	.mode = STEDMA40_MODE_LOGICAL,
 	.dir = STEDMA40_PERIPH_TO_MEM,
 	.dev_type =  DB8500_DMA_DEV42_SD_MM4,
-	.src_info.data_width = STEDMA40_WORD_WIDTH,
-	.dst_info.data_width = STEDMA40_WORD_WIDTH,
 };
 
 static struct stedma40_chan_cfg mop500_sdi4_dma_cfg_tx = {
 	.mode = STEDMA40_MODE_LOGICAL,
 	.dir = STEDMA40_MEM_TO_PERIPH,
 	.dev_type = DB8500_DMA_DEV42_SD_MM4,
-	.src_info.data_width = STEDMA40_WORD_WIDTH,
-	.dst_info.data_width = STEDMA40_WORD_WIDTH,
 };
 #endif
 
-- 
1.7.10.4



From lee.jones at linaro.org  Thu Apr 18 06:11:55 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Thu, 18 Apr 2013 11:11:55 +0100
Subject: [PATCH 13/32] dmaengine: ste_dma40: Calculate number of logical
 channels from physical ones
In-Reply-To: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1366279934-30761-14-git-send-email-lee.jones@linaro.org>

This change will cost ~25KB of memory, but it's worth the trade-off,
as it removes a great deal of overhead. It means that instead of only
allocating memory for the logical channels in use, it does so for all
available ones, which is 32 per physical channel. However, this now
means we can remove some platform data and we don't have to worry
about adding vendor specific variables to Device Tree.

Cc: Vinod Koul <vinod.koul at intel.com>
Cc: Dan Williams <djbw at fb.com>
Cc: Per Forlin <per.forlin at stericsson.com>
Cc: Rabin Vincent <rabin at rab.in>
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/mach-ux500/devices-db8500.c        |    1 -
 drivers/dma/ste_dma40.c                     |   16 ++++++----------
 include/linux/platform_data/dma-ste-dma40.h |    2 --
 3 files changed, 6 insertions(+), 13 deletions(-)

diff --git a/arch/arm/mach-ux500/devices-db8500.c b/arch/arm/mach-ux500/devices-db8500.c
index 03efd4c1..2fcb8c2 100644
--- a/arch/arm/mach-ux500/devices-db8500.c
+++ b/arch/arm/mach-ux500/devices-db8500.c
@@ -121,7 +121,6 @@ static const dma_addr_t dma40_rx_map[DB8500_DMA_NR_DEV] = {
 };
 
 static struct stedma40_platform_data dma40_plat_data = {
-	.dev_len = DB8500_DMA_NR_DEV,
 	.dev_rx = dma40_rx_map,
 	.dev_tx = dma40_tx_map,
 	.disabled_channels = {-1},
diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index 7b451b2..a39ef74 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -45,6 +45,9 @@
 #define D40_LCLA_LINK_PER_EVENT_GRP 128
 #define D40_LCLA_END D40_LCLA_LINK_PER_EVENT_GRP
 
+/* Max number of logical channels per physical channel */
+#define D40_MAX_LOG_CHAN_PER_PHY 32
+
 /* Attempts before giving up to trying to get pages that are aligned */
 #define MAX_LCLA_ALLOC_ATTEMPTS 256
 
@@ -3197,6 +3200,8 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
 	else
 		num_phy_chans = 4 * (readl(virtbase + D40_DREG_ICFG) & 0x7) + 4;
 
+	num_log_chans = num_phy_chans * D40_MAX_LOG_CHAN_PER_PHY;
+
 	dev_info(&pdev->dev, "hardware revision: %d @ 0x%x with %d physical channels\n",
 		 rev, res->start, num_phy_chans);
 
@@ -3206,15 +3211,6 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
 		goto failure;
 	}
 
-	/* Count the number of logical channels in use */
-	for (i = 0; i < plat_data->dev_len; i++)
-		if (plat_data->dev_rx[i] != 0)
-			num_log_chans++;
-
-	for (i = 0; i < plat_data->dev_len; i++)
-		if (plat_data->dev_tx[i] != 0)
-			num_log_chans++;
-
 	base = kzalloc(ALIGN(sizeof(struct d40_base), 4) +
 		       (num_phy_chans + num_log_chans + ARRAY_SIZE(dma40_memcpy_channels)) *
 		       sizeof(struct d40_chan), GFP_KERNEL);
@@ -3282,7 +3278,7 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
 		 * The max number of logical channels are event lines for all
 		 * src devices and dst devices
 		 */
-		base->lookup_log_chans = kzalloc(plat_data->dev_len * 2 *
+		base->lookup_log_chans = kzalloc(num_log_chans *
 						 sizeof(struct d40_chan *),
 						 GFP_KERNEL);
 		if (!base->lookup_log_chans)
diff --git a/include/linux/platform_data/dma-ste-dma40.h b/include/linux/platform_data/dma-ste-dma40.h
index 9e42a67..c54af61 100644
--- a/include/linux/platform_data/dma-ste-dma40.h
+++ b/include/linux/platform_data/dma-ste-dma40.h
@@ -136,7 +136,6 @@ struct stedma40_chan_cfg {
 /**
  * struct stedma40_platform_data - Configuration struct for the dma device.
  *
- * @dev_len: length of dev_tx and dev_rx
  * @dev_tx: mapping between destination event line and io address
  * @dev_rx: mapping between source event line and io address
  * @disabled_channels: A vector, ending with -1, that marks physical channels
@@ -153,7 +152,6 @@ struct stedma40_chan_cfg {
  * for 'multiple of 4' channels, like 8.
  */
 struct stedma40_platform_data {
-	u32				 dev_len;
 	const dma_addr_t		*dev_tx;
 	const dma_addr_t		*dev_rx;
 	int				 disabled_channels[STEDMA40_MAX_PHYS];
-- 
1.7.10.4



From lee.jones at linaro.org  Thu Apr 18 06:11:58 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Thu, 18 Apr 2013 11:11:58 +0100
Subject: [PATCH 16/32] dmaengine: ste_dma40: Remove unnecessary call to
 d40_phy_cfg()
In-Reply-To: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1366279934-30761-17-git-send-email-lee.jones@linaro.org>

All configuration left in d40_phy_cfg() is runtime configurable and
there is already a call into it from d40_runtime_config(), so let's
rely on that.

Cc: Vinod Koul <vinod.koul at intel.com>
Cc: Dan Williams <djbw at fb.com>
Cc: Per Forlin <per.forlin at stericsson.com>
Cc: Rabin Vincent <rabin at rab.in>
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 drivers/dma/ste_dma40.c |    3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index 178a03c..1c570b6 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -2437,9 +2437,6 @@ static int d40_alloc_chan_resources(struct dma_chan *chan)
 	}
 
 	pm_runtime_get_sync(d40c->base->dev);
-	/* Fill in basic CFG register values */
-	d40_phy_cfg(&d40c->dma_cfg, &d40c->src_def_cfg,
-		    &d40c->dst_def_cfg, chan_is_logical(d40c));
 
 	d40_set_prio_realtime(d40c);
 
-- 
1.7.10.4



From lee.jones at linaro.org  Thu Apr 18 06:11:57 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Thu, 18 Apr 2013 11:11:57 +0100
Subject: [PATCH 15/32] dmaengine: ste_dma40: Separate Logical Global Interrupt
 Mask (GIM) unmasking
In-Reply-To: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1366279934-30761-16-git-send-email-lee.jones@linaro.org>

During the initial setup of a logical channel, it is necessary to unmask
the GIM in order to receive generated terminal count and error interrupts.
We're separating out this required code so it will be possible to move
the remaining code in d40_phy_cfg(), which is mostly runtime configuration
into the runtime_config() routine.

Cc: Vinod Koul <vinod.koul at intel.com>
Cc: Dan Williams <djbw at fb.com>
Cc: Per Forlin <per.forlin at stericsson.com>
Cc: Rabin Vincent <rabin at rab.in>
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 drivers/dma/ste_dma40.c    |    3 +++
 drivers/dma/ste_dma40_ll.c |   11 ++++++-----
 drivers/dma/ste_dma40_ll.h |    2 ++
 3 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index ec0d6ab..178a03c 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -2456,6 +2456,9 @@ static int d40_alloc_chan_resources(struct dma_chan *chan)
 				D40_LCPA_CHAN_SIZE + D40_LCPA_CHAN_DST_DELTA;
 	}
 
+	if (chan_is_logical(d40c))
+		d40_log_gim_unmask(&d40c->src_def_cfg, &d40c->dst_def_cfg);
+
 	dev_dbg(chan2dev(d40c), "allocated %s channel (phy %d%s)\n",
 		 chan_is_logical(d40c) ? "logical" : "physical",
 		 d40c->phy_chan->num,
diff --git a/drivers/dma/ste_dma40_ll.c b/drivers/dma/ste_dma40_ll.c
index 5eb6c10..b72d3e2 100644
--- a/drivers/dma/ste_dma40_ll.c
+++ b/drivers/dma/ste_dma40_ll.c
@@ -50,6 +50,12 @@ void d40_log_cfg(struct stedma40_chan_cfg *cfg,
 
 }
 
+void d40_log_gim_unmask(u32 *src_cfg, u32 *dst_cfg) {
+
+	*src_cfg |= 1 << D40_SREG_CFG_LOG_GIM_POS;
+	*dst_cfg |= 1 << D40_SREG_CFG_LOG_GIM_POS;
+}
+
 /* Sets up SRC and DST CFG register for both logical and physical channels */
 void d40_phy_cfg(struct stedma40_chan_cfg *cfg,
 		 u32 *src_cfg, u32 *dst_cfg, bool is_log)
@@ -107,11 +113,6 @@ void d40_phy_cfg(struct stedma40_chan_cfg *cfg,
 			src |= 1 << D40_SREG_CFG_PRI_POS;
 			dst |= 1 << D40_SREG_CFG_PRI_POS;
 		}
-
-	} else {
-		/* Logical channel */
-		dst |= 1 << D40_SREG_CFG_LOG_GIM_POS;
-		src |= 1 << D40_SREG_CFG_LOG_GIM_POS;
 	}
 
 	if (cfg->src_info.big_endian)
diff --git a/drivers/dma/ste_dma40_ll.h b/drivers/dma/ste_dma40_ll.h
index fdde8ef..8aad679 100644
--- a/drivers/dma/ste_dma40_ll.h
+++ b/drivers/dma/ste_dma40_ll.h
@@ -430,6 +430,8 @@ enum d40_lli_flags {
 	LLI_LAST_LINK	= 1 << 3,
 };
 
+void d40_log_gim_unmask(u32 *src_cfg, u32 *dst_cfg);
+
 void d40_phy_cfg(struct stedma40_chan_cfg *cfg,
 		 u32 *src_cfg,
 		 u32 *dst_cfg,
-- 
1.7.10.4



From lee.jones at linaro.org  Thu Apr 18 06:11:46 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Thu, 18 Apr 2013 11:11:46 +0100
Subject: [PATCH 04/32] dmaengine: ste_dma40: Amalgamate DMA source and
 destination channel numbers
In-Reply-To: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1366279934-30761-5-git-send-email-lee.jones@linaro.org>

Devices which utilise DMA tend to use the same channel numbers for
transmitting and receiving. For this reason and the fact that it'll
decrease the burden of platform data passed to each device, we're
amalgamating source and destination device types.

Cc: Vinod Koul <vinod.koul at intel.com>
Cc: Dan Williams <djbw at fb.com>
Cc: Per Forlin <per.forlin at stericsson.com>
Cc: Rabin Vincent <rabin at rab.in>
Acked-by: Arnd Bergmann <arnd at arndb.de>
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/mach-ux500/board-mop500-audio.c    |   18 +--
 arch/arm/mach-ux500/board-mop500-sdi.c      |   24 ++--
 arch/arm/mach-ux500/board-mop500.c          |   33 ++---
 arch/arm/mach-ux500/cpu-db8500.c            |   32 ++---
 arch/arm/mach-ux500/devices-db8500.c        |  120 ++++++++---------
 arch/arm/mach-ux500/ste-dma40-db8500.h      |  193 ++++++++++-----------------
 arch/arm/mach-ux500/usb.c                   |   10 +-
 drivers/dma/ste_dma40.c                     |   89 ++++--------
 drivers/dma/ste_dma40_ll.c                  |    4 +-
 include/linux/platform_data/dma-ste-dma40.h |    6 +-
 10 files changed, 205 insertions(+), 324 deletions(-)

diff --git a/arch/arm/mach-ux500/board-mop500-audio.c b/arch/arm/mach-ux500/board-mop500-audio.c
index 7209db7..f012cfa 100644
--- a/arch/arm/mach-ux500/board-mop500-audio.c
+++ b/arch/arm/mach-ux500/board-mop500-audio.c
@@ -24,8 +24,7 @@ static struct stedma40_chan_cfg msp0_dma_rx = {
 	.high_priority = true,
 	.dir = STEDMA40_PERIPH_TO_MEM,
 
-	.src_dev_type = DB8500_DMA_DEV31_MSP0_RX_SLIM0_CH0_RX,
-	.dst_dev_type = STEDMA40_DEV_DST_MEMORY,
+	.dev_type = DB8500_DMA_DEV31_MSP0_SLIM0_CH0,
 
 	.src_info.psize = STEDMA40_PSIZE_LOG_4,
 	.dst_info.psize = STEDMA40_PSIZE_LOG_4,
@@ -37,8 +36,7 @@ static struct stedma40_chan_cfg msp0_dma_tx = {
 	.high_priority = true,
 	.dir = STEDMA40_MEM_TO_PERIPH,
 
-	.src_dev_type = STEDMA40_DEV_DST_MEMORY,
-	.dst_dev_type = DB8500_DMA_DEV31_MSP0_TX_SLIM0_CH0_TX,
+	.dev_type = DB8500_DMA_DEV31_MSP0_SLIM0_CH0,
 
 	.src_info.psize = STEDMA40_PSIZE_LOG_4,
 	.dst_info.psize = STEDMA40_PSIZE_LOG_4,
@@ -56,8 +54,7 @@ static struct stedma40_chan_cfg msp1_dma_rx = {
 	.high_priority = true,
 	.dir = STEDMA40_PERIPH_TO_MEM,
 
-	.src_dev_type = DB8500_DMA_DEV30_MSP3_RX,
-	.dst_dev_type = STEDMA40_DEV_DST_MEMORY,
+	.dev_type = DB8500_DMA_DEV30_MSP3,
 
 	.src_info.psize = STEDMA40_PSIZE_LOG_4,
 	.dst_info.psize = STEDMA40_PSIZE_LOG_4,
@@ -69,8 +66,7 @@ static struct stedma40_chan_cfg msp1_dma_tx = {
 	.high_priority = true,
 	.dir = STEDMA40_MEM_TO_PERIPH,
 
-	.src_dev_type = STEDMA40_DEV_DST_MEMORY,
-	.dst_dev_type = DB8500_DMA_DEV30_MSP1_TX,
+	.dev_type = DB8500_DMA_DEV30_MSP1,
 
 	.src_info.psize = STEDMA40_PSIZE_LOG_4,
 	.dst_info.psize = STEDMA40_PSIZE_LOG_4,
@@ -88,8 +84,7 @@ static struct stedma40_chan_cfg msp2_dma_rx = {
 	.high_priority = true,
 	.dir = STEDMA40_PERIPH_TO_MEM,
 
-	.src_dev_type = DB8500_DMA_DEV14_MSP2_RX,
-	.dst_dev_type = STEDMA40_DEV_DST_MEMORY,
+	.dev_type = DB8500_DMA_DEV14_MSP2,
 
 	/* MSP2 DMA doesn't work with PSIZE == 4 on DB8500v2 */
 	.src_info.psize = STEDMA40_PSIZE_LOG_1,
@@ -102,8 +97,7 @@ static struct stedma40_chan_cfg msp2_dma_tx = {
 	.high_priority = true,
 	.dir = STEDMA40_MEM_TO_PERIPH,
 
-	.src_dev_type = STEDMA40_DEV_DST_MEMORY,
-	.dst_dev_type = DB8500_DMA_DEV14_MSP2_TX,
+	.dev_type = DB8500_DMA_DEV14_MSP2,
 
 	.src_info.psize = STEDMA40_PSIZE_LOG_4,
 	.dst_info.psize = STEDMA40_PSIZE_LOG_4,
diff --git a/arch/arm/mach-ux500/board-mop500-sdi.c b/arch/arm/mach-ux500/board-mop500-sdi.c
index 7f2cb6c..5c28216 100644
--- a/arch/arm/mach-ux500/board-mop500-sdi.c
+++ b/arch/arm/mach-ux500/board-mop500-sdi.c
@@ -64,8 +64,7 @@ static int mop500_sdi0_ios_handler(struct device *dev, struct mmc_ios *ios)
 struct stedma40_chan_cfg mop500_sdi0_dma_cfg_rx = {
 	.mode = STEDMA40_MODE_LOGICAL,
 	.dir = STEDMA40_PERIPH_TO_MEM,
-	.src_dev_type = DB8500_DMA_DEV29_SD_MM0_RX,
-	.dst_dev_type = STEDMA40_DEV_DST_MEMORY,
+	.dev_type = DB8500_DMA_DEV29_SD_MM0,
 	.src_info.data_width = STEDMA40_WORD_WIDTH,
 	.dst_info.data_width = STEDMA40_WORD_WIDTH,
 };
@@ -73,8 +72,7 @@ struct stedma40_chan_cfg mop500_sdi0_dma_cfg_rx = {
 static struct stedma40_chan_cfg mop500_sdi0_dma_cfg_tx = {
 	.mode = STEDMA40_MODE_LOGICAL,
 	.dir = STEDMA40_MEM_TO_PERIPH,
-	.src_dev_type = STEDMA40_DEV_SRC_MEMORY,
-	.dst_dev_type = DB8500_DMA_DEV29_SD_MM0_TX,
+	.dev_type = DB8500_DMA_DEV29_SD_MM0,
 	.src_info.data_width = STEDMA40_WORD_WIDTH,
 	.dst_info.data_width = STEDMA40_WORD_WIDTH,
 };
@@ -135,8 +133,7 @@ void mop500_sdi_tc35892_init(struct device *parent)
 static struct stedma40_chan_cfg sdi1_dma_cfg_rx = {
 	.mode = STEDMA40_MODE_LOGICAL,
 	.dir = STEDMA40_PERIPH_TO_MEM,
-	.src_dev_type = DB8500_DMA_DEV32_SD_MM1_RX,
-	.dst_dev_type = STEDMA40_DEV_DST_MEMORY,
+	.dev_type = DB8500_DMA_DEV32_SD_MM1,
 	.src_info.data_width = STEDMA40_WORD_WIDTH,
 	.dst_info.data_width = STEDMA40_WORD_WIDTH,
 };
@@ -144,8 +141,7 @@ static struct stedma40_chan_cfg sdi1_dma_cfg_rx = {
 static struct stedma40_chan_cfg sdi1_dma_cfg_tx = {
 	.mode = STEDMA40_MODE_LOGICAL,
 	.dir = STEDMA40_MEM_TO_PERIPH,
-	.src_dev_type = STEDMA40_DEV_SRC_MEMORY,
-	.dst_dev_type = DB8500_DMA_DEV32_SD_MM1_TX,
+	.dev_type = DB8500_DMA_DEV32_SD_MM1,
 	.src_info.data_width = STEDMA40_WORD_WIDTH,
 	.dst_info.data_width = STEDMA40_WORD_WIDTH,
 };
@@ -172,8 +168,7 @@ struct mmci_platform_data mop500_sdi1_data = {
 struct stedma40_chan_cfg mop500_sdi2_dma_cfg_rx = {
 	.mode = STEDMA40_MODE_LOGICAL,
 	.dir = STEDMA40_PERIPH_TO_MEM,
-	.src_dev_type =  DB8500_DMA_DEV28_SD_MM2_RX,
-	.dst_dev_type = STEDMA40_DEV_DST_MEMORY,
+	.dev_type =  DB8500_DMA_DEV28_SD_MM2,
 	.src_info.data_width = STEDMA40_WORD_WIDTH,
 	.dst_info.data_width = STEDMA40_WORD_WIDTH,
 };
@@ -181,8 +176,7 @@ struct stedma40_chan_cfg mop500_sdi2_dma_cfg_rx = {
 static struct stedma40_chan_cfg mop500_sdi2_dma_cfg_tx = {
 	.mode = STEDMA40_MODE_LOGICAL,
 	.dir = STEDMA40_MEM_TO_PERIPH,
-	.src_dev_type = STEDMA40_DEV_SRC_MEMORY,
-	.dst_dev_type = DB8500_DMA_DEV28_SD_MM2_TX,
+	.dev_type = DB8500_DMA_DEV28_SD_MM2,
 	.src_info.data_width = STEDMA40_WORD_WIDTH,
 	.dst_info.data_width = STEDMA40_WORD_WIDTH,
 };
@@ -210,8 +204,7 @@ struct mmci_platform_data mop500_sdi2_data = {
 struct stedma40_chan_cfg mop500_sdi4_dma_cfg_rx = {
 	.mode = STEDMA40_MODE_LOGICAL,
 	.dir = STEDMA40_PERIPH_TO_MEM,
-	.src_dev_type =  DB8500_DMA_DEV42_SD_MM4_RX,
-	.dst_dev_type = STEDMA40_DEV_DST_MEMORY,
+	.dev_type =  DB8500_DMA_DEV42_SD_MM4,
 	.src_info.data_width = STEDMA40_WORD_WIDTH,
 	.dst_info.data_width = STEDMA40_WORD_WIDTH,
 };
@@ -219,8 +212,7 @@ struct stedma40_chan_cfg mop500_sdi4_dma_cfg_rx = {
 static struct stedma40_chan_cfg mop500_sdi4_dma_cfg_tx = {
 	.mode = STEDMA40_MODE_LOGICAL,
 	.dir = STEDMA40_MEM_TO_PERIPH,
-	.src_dev_type = STEDMA40_DEV_SRC_MEMORY,
-	.dst_dev_type = DB8500_DMA_DEV42_SD_MM4_TX,
+	.dev_type = DB8500_DMA_DEV42_SD_MM4,
 	.src_info.data_width = STEDMA40_WORD_WIDTH,
 	.dst_info.data_width = STEDMA40_WORD_WIDTH,
 };
diff --git a/arch/arm/mach-ux500/board-mop500.c b/arch/arm/mach-ux500/board-mop500.c
index 87d2d7b..a8b3ad9 100644
--- a/arch/arm/mach-ux500/board-mop500.c
+++ b/arch/arm/mach-ux500/board-mop500.c
@@ -452,8 +452,7 @@ void mop500_snowball_ethernet_clock_enable(void)
 static struct cryp_platform_data u8500_cryp1_platform_data = {
 		.mem_to_engine = {
 				.dir = STEDMA40_MEM_TO_PERIPH,
-				.src_dev_type = STEDMA40_DEV_SRC_MEMORY,
-				.dst_dev_type = DB8500_DMA_DEV48_CAC1_TX,
+				.dev_type = DB8500_DMA_DEV48_CAC1,
 				.src_info.data_width = STEDMA40_WORD_WIDTH,
 				.dst_info.data_width = STEDMA40_WORD_WIDTH,
 				.mode = STEDMA40_MODE_LOGICAL,
@@ -462,8 +461,7 @@ static struct cryp_platform_data u8500_cryp1_platform_data = {
 		},
 		.engine_to_mem = {
 				.dir = STEDMA40_PERIPH_TO_MEM,
-				.src_dev_type = DB8500_DMA_DEV48_CAC1_RX,
-				.dst_dev_type = STEDMA40_DEV_DST_MEMORY,
+				.dev_type = DB8500_DMA_DEV48_CAC1,
 				.src_info.data_width = STEDMA40_WORD_WIDTH,
 				.dst_info.data_width = STEDMA40_WORD_WIDTH,
 				.mode = STEDMA40_MODE_LOGICAL,
@@ -474,8 +472,7 @@ static struct cryp_platform_data u8500_cryp1_platform_data = {
 
 static struct stedma40_chan_cfg u8500_hash_dma_cfg_tx = {
 		.dir = STEDMA40_MEM_TO_PERIPH,
-		.src_dev_type = STEDMA40_DEV_SRC_MEMORY,
-		.dst_dev_type = DB8500_DMA_DEV50_HAC1_TX,
+		.dev_type = DB8500_DMA_DEV50_HAC1_TX,
 		.src_info.data_width = STEDMA40_WORD_WIDTH,
 		.dst_info.data_width = STEDMA40_WORD_WIDTH,
 		.mode = STEDMA40_MODE_LOGICAL,
@@ -497,8 +494,7 @@ static struct platform_device *mop500_platform_devs[] __initdata = {
 static struct stedma40_chan_cfg ssp0_dma_cfg_rx = {
 	.mode = STEDMA40_MODE_LOGICAL,
 	.dir = STEDMA40_PERIPH_TO_MEM,
-	.src_dev_type =  DB8500_DMA_DEV8_SSP0_RX,
-	.dst_dev_type = STEDMA40_DEV_DST_MEMORY,
+	.dev_type = DB8500_DMA_DEV8_SSP0,
 	.src_info.data_width = STEDMA40_BYTE_WIDTH,
 	.dst_info.data_width = STEDMA40_BYTE_WIDTH,
 };
@@ -506,8 +502,7 @@ static struct stedma40_chan_cfg ssp0_dma_cfg_rx = {
 static struct stedma40_chan_cfg ssp0_dma_cfg_tx = {
 	.mode = STEDMA40_MODE_LOGICAL,
 	.dir = STEDMA40_MEM_TO_PERIPH,
-	.src_dev_type = STEDMA40_DEV_SRC_MEMORY,
-	.dst_dev_type = DB8500_DMA_DEV8_SSP0_TX,
+	.dev_type = DB8500_DMA_DEV8_SSP0,
 	.src_info.data_width = STEDMA40_BYTE_WIDTH,
 	.dst_info.data_width = STEDMA40_BYTE_WIDTH,
 };
@@ -538,8 +533,7 @@ static void __init mop500_spi_init(struct device *parent)
 static struct stedma40_chan_cfg uart0_dma_cfg_rx = {
 	.mode = STEDMA40_MODE_LOGICAL,
 	.dir = STEDMA40_PERIPH_TO_MEM,
-	.src_dev_type =  DB8500_DMA_DEV13_UART0_RX,
-	.dst_dev_type = STEDMA40_DEV_DST_MEMORY,
+	.dev_type = DB8500_DMA_DEV13_UART0,
 	.src_info.data_width = STEDMA40_BYTE_WIDTH,
 	.dst_info.data_width = STEDMA40_BYTE_WIDTH,
 };
@@ -547,8 +541,7 @@ static struct stedma40_chan_cfg uart0_dma_cfg_rx = {
 static struct stedma40_chan_cfg uart0_dma_cfg_tx = {
 	.mode = STEDMA40_MODE_LOGICAL,
 	.dir = STEDMA40_MEM_TO_PERIPH,
-	.src_dev_type = STEDMA40_DEV_SRC_MEMORY,
-	.dst_dev_type = DB8500_DMA_DEV13_UART0_TX,
+	.dev_type = DB8500_DMA_DEV13_UART0,
 	.src_info.data_width = STEDMA40_BYTE_WIDTH,
 	.dst_info.data_width = STEDMA40_BYTE_WIDTH,
 };
@@ -556,8 +549,7 @@ static struct stedma40_chan_cfg uart0_dma_cfg_tx = {
 static struct stedma40_chan_cfg uart1_dma_cfg_rx = {
 	.mode = STEDMA40_MODE_LOGICAL,
 	.dir = STEDMA40_PERIPH_TO_MEM,
-	.src_dev_type =  DB8500_DMA_DEV12_UART1_RX,
-	.dst_dev_type = STEDMA40_DEV_DST_MEMORY,
+	.dev_type = DB8500_DMA_DEV12_UART1,
 	.src_info.data_width = STEDMA40_BYTE_WIDTH,
 	.dst_info.data_width = STEDMA40_BYTE_WIDTH,
 };
@@ -565,8 +557,7 @@ static struct stedma40_chan_cfg uart1_dma_cfg_rx = {
 static struct stedma40_chan_cfg uart1_dma_cfg_tx = {
 	.mode = STEDMA40_MODE_LOGICAL,
 	.dir = STEDMA40_MEM_TO_PERIPH,
-	.src_dev_type = STEDMA40_DEV_SRC_MEMORY,
-	.dst_dev_type = DB8500_DMA_DEV12_UART1_TX,
+	.dev_type = DB8500_DMA_DEV12_UART1,
 	.src_info.data_width = STEDMA40_BYTE_WIDTH,
 	.dst_info.data_width = STEDMA40_BYTE_WIDTH,
 };
@@ -574,8 +565,7 @@ static struct stedma40_chan_cfg uart1_dma_cfg_tx = {
 static struct stedma40_chan_cfg uart2_dma_cfg_rx = {
 	.mode = STEDMA40_MODE_LOGICAL,
 	.dir = STEDMA40_PERIPH_TO_MEM,
-	.src_dev_type =  DB8500_DMA_DEV11_UART2_RX,
-	.dst_dev_type = STEDMA40_DEV_DST_MEMORY,
+	.dev_type = DB8500_DMA_DEV11_UART2,
 	.src_info.data_width = STEDMA40_BYTE_WIDTH,
 	.dst_info.data_width = STEDMA40_BYTE_WIDTH,
 };
@@ -583,8 +573,7 @@ static struct stedma40_chan_cfg uart2_dma_cfg_rx = {
 static struct stedma40_chan_cfg uart2_dma_cfg_tx = {
 	.mode = STEDMA40_MODE_LOGICAL,
 	.dir = STEDMA40_MEM_TO_PERIPH,
-	.src_dev_type = STEDMA40_DEV_SRC_MEMORY,
-	.dst_dev_type = DB8500_DMA_DEV11_UART2_TX,
+	.dev_type = DB8500_DMA_DEV11_UART2,
 	.src_info.data_width = STEDMA40_BYTE_WIDTH,
 	.dst_info.data_width = STEDMA40_BYTE_WIDTH,
 };
diff --git a/arch/arm/mach-ux500/cpu-db8500.c b/arch/arm/mach-ux500/cpu-db8500.c
index e027865..f72cc9b 100644
--- a/arch/arm/mach-ux500/cpu-db8500.c
+++ b/arch/arm/mach-ux500/cpu-db8500.c
@@ -167,25 +167,25 @@ static void __init db8500_add_gpios(struct device *parent)
 }
 
 static int usb_db8500_rx_dma_cfg[] = {
-	DB8500_DMA_DEV38_USB_OTG_IEP_1_9,
-	DB8500_DMA_DEV37_USB_OTG_IEP_2_10,
-	DB8500_DMA_DEV36_USB_OTG_IEP_3_11,
-	DB8500_DMA_DEV19_USB_OTG_IEP_4_12,
-	DB8500_DMA_DEV18_USB_OTG_IEP_5_13,
-	DB8500_DMA_DEV17_USB_OTG_IEP_6_14,
-	DB8500_DMA_DEV16_USB_OTG_IEP_7_15,
-	DB8500_DMA_DEV39_USB_OTG_IEP_8
+	DB8500_DMA_DEV38_USB_OTG_IEP_AND_OEP_1_9,
+	DB8500_DMA_DEV37_USB_OTG_IEP_AND_OEP_2_10,
+	DB8500_DMA_DEV36_USB_OTG_IEP_AND_OEP_3_11,
+	DB8500_DMA_DEV19_USB_OTG_IEP_AND_OEP_4_12,
+	DB8500_DMA_DEV18_USB_OTG_IEP_AND_OEP_5_13,
+	DB8500_DMA_DEV17_USB_OTG_IEP_AND_OEP_6_14,
+	DB8500_DMA_DEV16_USB_OTG_IEP_AND_OEP_7_15,
+	DB8500_DMA_DEV39_USB_OTG_IEP_AND_OEP_8
 };
 
 static int usb_db8500_tx_dma_cfg[] = {
-	DB8500_DMA_DEV38_USB_OTG_OEP_1_9,
-	DB8500_DMA_DEV37_USB_OTG_OEP_2_10,
-	DB8500_DMA_DEV36_USB_OTG_OEP_3_11,
-	DB8500_DMA_DEV19_USB_OTG_OEP_4_12,
-	DB8500_DMA_DEV18_USB_OTG_OEP_5_13,
-	DB8500_DMA_DEV17_USB_OTG_OEP_6_14,
-	DB8500_DMA_DEV16_USB_OTG_OEP_7_15,
-	DB8500_DMA_DEV39_USB_OTG_OEP_8
+	DB8500_DMA_DEV38_USB_OTG_IEP_AND_OEP_1_9,
+	DB8500_DMA_DEV37_USB_OTG_IEP_AND_OEP_2_10,
+	DB8500_DMA_DEV36_USB_OTG_IEP_AND_OEP_3_11,
+	DB8500_DMA_DEV19_USB_OTG_IEP_AND_OEP_4_12,
+	DB8500_DMA_DEV18_USB_OTG_IEP_AND_OEP_5_13,
+	DB8500_DMA_DEV17_USB_OTG_IEP_AND_OEP_6_14,
+	DB8500_DMA_DEV16_USB_OTG_IEP_AND_OEP_7_15,
+	DB8500_DMA_DEV39_USB_OTG_IEP_AND_OEP_8
 };
 
 static const char *db8500_read_soc_id(void)
diff --git a/arch/arm/mach-ux500/devices-db8500.c b/arch/arm/mach-ux500/devices-db8500.c
index 5b1f1f7..03efd4c1 100644
--- a/arch/arm/mach-ux500/devices-db8500.c
+++ b/arch/arm/mach-ux500/devices-db8500.c
@@ -50,74 +50,74 @@ static struct resource dma40_resources[] = {
  */
 static const dma_addr_t dma40_tx_map[DB8500_DMA_NR_DEV] = {
 	/* MUSB - these will be runtime-reconfigured */
-	[DB8500_DMA_DEV39_USB_OTG_OEP_8] = -1,
-	[DB8500_DMA_DEV16_USB_OTG_OEP_7_15] = -1,
-	[DB8500_DMA_DEV17_USB_OTG_OEP_6_14] = -1,
-	[DB8500_DMA_DEV18_USB_OTG_OEP_5_13] = -1,
-	[DB8500_DMA_DEV19_USB_OTG_OEP_4_12] = -1,
-	[DB8500_DMA_DEV36_USB_OTG_OEP_3_11] = -1,
-	[DB8500_DMA_DEV37_USB_OTG_OEP_2_10] = -1,
-	[DB8500_DMA_DEV38_USB_OTG_OEP_1_9] = -1,
+	[DB8500_DMA_DEV39_USB_OTG_IEP_AND_OEP_8] = -1,
+	[DB8500_DMA_DEV16_USB_OTG_IEP_AND_OEP_7_15] = -1,
+	[DB8500_DMA_DEV17_USB_OTG_IEP_AND_OEP_6_14] = -1,
+	[DB8500_DMA_DEV18_USB_OTG_IEP_AND_OEP_5_13] = -1,
+	[DB8500_DMA_DEV19_USB_OTG_IEP_AND_OEP_4_12] = -1,
+	[DB8500_DMA_DEV36_USB_OTG_IEP_AND_OEP_3_11] = -1,
+	[DB8500_DMA_DEV37_USB_OTG_IEP_AND_OEP_2_10] = -1,
+	[DB8500_DMA_DEV38_USB_OTG_IEP_AND_OEP_1_9] = -1,
 	/* PrimeCells - run-time configured */
-	[DB8500_DMA_DEV0_SPI0_TX] = -1,
-	[DB8500_DMA_DEV1_SD_MMC0_TX] = -1,
-	[DB8500_DMA_DEV2_SD_MMC1_TX] = -1,
-	[DB8500_DMA_DEV3_SD_MMC2_TX] = -1,
-	[DB8500_DMA_DEV8_SSP0_TX] = -1,
-	[DB8500_DMA_DEV9_SSP1_TX] = -1,
-	[DB8500_DMA_DEV11_UART2_TX] = -1,
-	[DB8500_DMA_DEV12_UART1_TX] = -1,
-	[DB8500_DMA_DEV13_UART0_TX] = -1,
-	[DB8500_DMA_DEV28_SD_MM2_TX] = -1,
-	[DB8500_DMA_DEV29_SD_MM0_TX] = -1,
-	[DB8500_DMA_DEV32_SD_MM1_TX] = -1,
-	[DB8500_DMA_DEV33_SPI2_TX] = -1,
-	[DB8500_DMA_DEV35_SPI1_TX] = -1,
-	[DB8500_DMA_DEV40_SPI3_TX] = -1,
-	[DB8500_DMA_DEV41_SD_MM3_TX] = -1,
-	[DB8500_DMA_DEV42_SD_MM4_TX] = -1,
-	[DB8500_DMA_DEV43_SD_MM5_TX] = -1,
-	[DB8500_DMA_DEV14_MSP2_TX] = U8500_MSP2_BASE + MSP_TX_RX_REG_OFFSET,
-	[DB8500_DMA_DEV30_MSP1_TX] = U8500_MSP1_BASE + MSP_TX_RX_REG_OFFSET,
-	[DB8500_DMA_DEV31_MSP0_TX_SLIM0_CH0_TX] = U8500_MSP0_BASE + MSP_TX_RX_REG_OFFSET,
-	[DB8500_DMA_DEV48_CAC1_TX] = U8500_CRYP1_BASE + CRYP1_TX_REG_OFFSET,
+	[DB8500_DMA_DEV0_SPI0] = -1,
+	[DB8500_DMA_DEV1_SD_MMC0] = -1,
+	[DB8500_DMA_DEV2_SD_MMC1] = -1,
+	[DB8500_DMA_DEV3_SD_MMC2] = -1,
+	[DB8500_DMA_DEV8_SSP0] = -1,
+	[DB8500_DMA_DEV9_SSP1] = -1,
+	[DB8500_DMA_DEV11_UART2] = -1,
+	[DB8500_DMA_DEV12_UART1] = -1,
+	[DB8500_DMA_DEV13_UART0] = -1,
+	[DB8500_DMA_DEV28_SD_MM2] = -1,
+	[DB8500_DMA_DEV29_SD_MM0] = -1,
+	[DB8500_DMA_DEV32_SD_MM1] = -1,
+	[DB8500_DMA_DEV33_SPI2] = -1,
+	[DB8500_DMA_DEV35_SPI1] = -1,
+	[DB8500_DMA_DEV40_SPI3] = -1,
+	[DB8500_DMA_DEV41_SD_MM3] = -1,
+	[DB8500_DMA_DEV42_SD_MM4] = -1,
+	[DB8500_DMA_DEV43_SD_MM5] = -1,
+	[DB8500_DMA_DEV14_MSP2] = U8500_MSP2_BASE + MSP_TX_RX_REG_OFFSET,
+	[DB8500_DMA_DEV30_MSP1] = U8500_MSP1_BASE + MSP_TX_RX_REG_OFFSET,
+	[DB8500_DMA_DEV31_MSP0_SLIM0_CH0] = U8500_MSP0_BASE + MSP_TX_RX_REG_OFFSET,
+	[DB8500_DMA_DEV48_CAC1] = U8500_CRYP1_BASE + CRYP1_TX_REG_OFFSET,
 	[DB8500_DMA_DEV50_HAC1_TX] = U8500_HASH1_BASE + HASH1_TX_REG_OFFSET,
 };
 
 /* Mapping between source event lines and physical device address */
 static const dma_addr_t dma40_rx_map[DB8500_DMA_NR_DEV] = {
 	/* MUSB - these will be runtime-reconfigured */
-	[DB8500_DMA_DEV39_USB_OTG_IEP_8] = -1,
-	[DB8500_DMA_DEV16_USB_OTG_IEP_7_15] = -1,
-	[DB8500_DMA_DEV17_USB_OTG_IEP_6_14] = -1,
-	[DB8500_DMA_DEV18_USB_OTG_IEP_5_13] = -1,
-	[DB8500_DMA_DEV19_USB_OTG_IEP_4_12] = -1,
-	[DB8500_DMA_DEV36_USB_OTG_IEP_3_11] = -1,
-	[DB8500_DMA_DEV37_USB_OTG_IEP_2_10] = -1,
-	[DB8500_DMA_DEV38_USB_OTG_IEP_1_9] = -1,
+	[DB8500_DMA_DEV39_USB_OTG_IEP_AND_OEP_8] = -1,
+	[DB8500_DMA_DEV16_USB_OTG_IEP_AND_OEP_7_15] = -1,
+	[DB8500_DMA_DEV17_USB_OTG_IEP_AND_OEP_6_14] = -1,
+	[DB8500_DMA_DEV18_USB_OTG_IEP_AND_OEP_5_13] = -1,
+	[DB8500_DMA_DEV19_USB_OTG_IEP_AND_OEP_4_12] = -1,
+	[DB8500_DMA_DEV36_USB_OTG_IEP_AND_OEP_3_11] = -1,
+	[DB8500_DMA_DEV37_USB_OTG_IEP_AND_OEP_2_10] = -1,
+	[DB8500_DMA_DEV38_USB_OTG_IEP_AND_OEP_1_9] = -1,
 	/* PrimeCells */
-	[DB8500_DMA_DEV0_SPI0_RX] = -1,
-	[DB8500_DMA_DEV1_SD_MMC0_RX] = -1,
-	[DB8500_DMA_DEV2_SD_MMC1_RX] = -1,
-	[DB8500_DMA_DEV3_SD_MMC2_RX] = -1,
-	[DB8500_DMA_DEV8_SSP0_RX] = -1,
-	[DB8500_DMA_DEV9_SSP1_RX] = -1,
-	[DB8500_DMA_DEV11_UART2_RX] = -1,
-	[DB8500_DMA_DEV12_UART1_RX] = -1,
-	[DB8500_DMA_DEV13_UART0_RX] = -1,
-	[DB8500_DMA_DEV28_SD_MM2_RX] = -1,
-	[DB8500_DMA_DEV29_SD_MM0_RX] = -1,
-	[DB8500_DMA_DEV32_SD_MM1_RX] = -1,
-	[DB8500_DMA_DEV33_SPI2_RX] = -1,
-	[DB8500_DMA_DEV35_SPI1_RX] = -1,
-	[DB8500_DMA_DEV40_SPI3_RX] = -1,
-	[DB8500_DMA_DEV41_SD_MM3_RX] = -1,
-	[DB8500_DMA_DEV42_SD_MM4_RX] = -1,
-	[DB8500_DMA_DEV43_SD_MM5_RX] = -1,
-	[DB8500_DMA_DEV14_MSP2_RX] = U8500_MSP2_BASE + MSP_TX_RX_REG_OFFSET,
-	[DB8500_DMA_DEV30_MSP3_RX] = U8500_MSP3_BASE + MSP_TX_RX_REG_OFFSET,
-	[DB8500_DMA_DEV31_MSP0_RX_SLIM0_CH0_RX] = U8500_MSP0_BASE + MSP_TX_RX_REG_OFFSET,
-	[DB8500_DMA_DEV48_CAC1_RX] = U8500_CRYP1_BASE + CRYP1_RX_REG_OFFSET,
+	[DB8500_DMA_DEV0_SPI0] = -1,
+	[DB8500_DMA_DEV1_SD_MMC0] = -1,
+	[DB8500_DMA_DEV2_SD_MMC1] = -1,
+	[DB8500_DMA_DEV3_SD_MMC2] = -1,
+	[DB8500_DMA_DEV8_SSP0] = -1,
+	[DB8500_DMA_DEV9_SSP1] = -1,
+	[DB8500_DMA_DEV11_UART2] = -1,
+	[DB8500_DMA_DEV12_UART1] = -1,
+	[DB8500_DMA_DEV13_UART0] = -1,
+	[DB8500_DMA_DEV28_SD_MM2] = -1,
+	[DB8500_DMA_DEV29_SD_MM0] = -1,
+	[DB8500_DMA_DEV32_SD_MM1] = -1,
+	[DB8500_DMA_DEV33_SPI2] = -1,
+	[DB8500_DMA_DEV35_SPI1] = -1,
+	[DB8500_DMA_DEV40_SPI3] = -1,
+	[DB8500_DMA_DEV41_SD_MM3] = -1,
+	[DB8500_DMA_DEV42_SD_MM4] = -1,
+	[DB8500_DMA_DEV43_SD_MM5] = -1,
+	[DB8500_DMA_DEV14_MSP2] = U8500_MSP2_BASE + MSP_TX_RX_REG_OFFSET,
+	[DB8500_DMA_DEV30_MSP3] = U8500_MSP3_BASE + MSP_TX_RX_REG_OFFSET,
+	[DB8500_DMA_DEV31_MSP0_SLIM0_CH0] = U8500_MSP0_BASE + MSP_TX_RX_REG_OFFSET,
+	[DB8500_DMA_DEV48_CAC1] = U8500_CRYP1_BASE + CRYP1_RX_REG_OFFSET,
 };
 
 static struct stedma40_platform_data dma40_plat_data = {
diff --git a/arch/arm/mach-ux500/ste-dma40-db8500.h b/arch/arm/mach-ux500/ste-dma40-db8500.h
index a616419..0296ae5 100644
--- a/arch/arm/mach-ux500/ste-dma40-db8500.h
+++ b/arch/arm/mach-ux500/ste-dma40-db8500.h
@@ -12,133 +12,74 @@
 
 #define DB8500_DMA_NR_DEV 64
 
-enum dma_src_dev_type {
-	DB8500_DMA_DEV0_SPI0_RX = 0,
-	DB8500_DMA_DEV1_SD_MMC0_RX = 1,
-	DB8500_DMA_DEV2_SD_MMC1_RX = 2,
-	DB8500_DMA_DEV3_SD_MMC2_RX = 3,
-	DB8500_DMA_DEV4_I2C1_RX = 4,
-	DB8500_DMA_DEV5_I2C3_RX = 5,
-	DB8500_DMA_DEV6_I2C2_RX = 6,
-	DB8500_DMA_DEV7_I2C4_RX = 7, /* Only on V1 and later */
-	DB8500_DMA_DEV8_SSP0_RX = 8,
-	DB8500_DMA_DEV9_SSP1_RX = 9,
-	DB8500_DMA_DEV10_MCDE_RX = 10,
-	DB8500_DMA_DEV11_UART2_RX = 11,
-	DB8500_DMA_DEV12_UART1_RX = 12,
-	DB8500_DMA_DEV13_UART0_RX = 13,
-	DB8500_DMA_DEV14_MSP2_RX = 14,
-	DB8500_DMA_DEV15_I2C0_RX = 15,
-	DB8500_DMA_DEV16_USB_OTG_IEP_7_15 = 16,
-	DB8500_DMA_DEV17_USB_OTG_IEP_6_14 = 17,
-	DB8500_DMA_DEV18_USB_OTG_IEP_5_13 = 18,
-	DB8500_DMA_DEV19_USB_OTG_IEP_4_12 = 19,
-	DB8500_DMA_DEV20_SLIM0_CH0_RX_HSI_RX_CH0 = 20,
-	DB8500_DMA_DEV21_SLIM0_CH1_RX_HSI_RX_CH1 = 21,
-	DB8500_DMA_DEV22_SLIM0_CH2_RX_HSI_RX_CH2 = 22,
-	DB8500_DMA_DEV23_SLIM0_CH3_RX_HSI_RX_CH3 = 23,
-	DB8500_DMA_DEV24_SRC_SXA0_RX_TX = 24,
-	DB8500_DMA_DEV25_SRC_SXA1_RX_TX = 25,
-	DB8500_DMA_DEV26_SRC_SXA2_RX_TX = 26,
-	DB8500_DMA_DEV27_SRC_SXA3_RX_TX = 27,
-	DB8500_DMA_DEV28_SD_MM2_RX = 28,
-	DB8500_DMA_DEV29_SD_MM0_RX = 29,
-	DB8500_DMA_DEV30_MSP1_RX = 30,
+/*
+ * Unless otherwise specified, all channels numbers are used for
+ * TX & RX, and can be used for either source or destination
+ * channels.
+ */
+enum dma_dev_type {
+	DB8500_DMA_DEV0_SPI0 = 0,
+	DB8500_DMA_DEV1_SD_MMC0 = 1,
+	DB8500_DMA_DEV2_SD_MMC1 = 2,
+	DB8500_DMA_DEV3_SD_MMC2 = 3,
+	DB8500_DMA_DEV4_I2C1 = 4,
+	DB8500_DMA_DEV5_I2C3 = 5,
+	DB8500_DMA_DEV6_I2C2 = 6,
+	DB8500_DMA_DEV7_I2C4 = 7,			/* Only on V1 and later */
+	DB8500_DMA_DEV8_SSP0 = 8,
+	DB8500_DMA_DEV9_SSP1 = 9,
+	DB8500_DMA_DEV10_MCDE_RX = 10,			/* RX only */
+	DB8500_DMA_DEV11_UART2 = 11,
+	DB8500_DMA_DEV12_UART1 = 12,
+	DB8500_DMA_DEV13_UART0 = 13,
+	DB8500_DMA_DEV14_MSP2 = 14,
+	DB8500_DMA_DEV15_I2C0 = 15,
+	DB8500_DMA_DEV16_USB_OTG_IEP_AND_OEP_7_15 = 16,
+	DB8500_DMA_DEV17_USB_OTG_IEP_AND_OEP_6_14 = 17,
+	DB8500_DMA_DEV18_USB_OTG_IEP_AND_OEP_5_13 = 18,
+	DB8500_DMA_DEV19_USB_OTG_IEP_AND_OEP_4_12 = 19,
+	DB8500_DMA_DEV20_SLIM0_CH0_HSI_CH0 = 20,
+	DB8500_DMA_DEV21_SLIM0_CH1_HSI_CH1 = 21,
+	DB8500_DMA_DEV22_SLIM0_CH2_HSI_CH2 = 22,
+	DB8500_DMA_DEV23_SLIM0_CH3_HSI_CH3 = 23,
+	DB8500_DMA_DEV24_SXA0 = 24,
+	DB8500_DMA_DEV25_SXA1 = 25,
+	DB8500_DMA_DEV26_SXA2 = 26,
+	DB8500_DMA_DEV27_SXA3 = 27,
+	DB8500_DMA_DEV28_SD_MM2 = 28,
+	DB8500_DMA_DEV29_SD_MM0 = 29,
+	DB8500_DMA_DEV30_MSP1 = 30,
 	/* On DB8500v2, MSP3 RX replaces MSP1 RX */
-	DB8500_DMA_DEV30_MSP3_RX = 30,
-	DB8500_DMA_DEV31_MSP0_RX_SLIM0_CH0_RX = 31,
-	DB8500_DMA_DEV32_SD_MM1_RX = 32,
-	DB8500_DMA_DEV33_SPI2_RX = 33,
-	DB8500_DMA_DEV34_I2C3_RX2 = 34,
-	DB8500_DMA_DEV35_SPI1_RX = 35,
-	DB8500_DMA_DEV36_USB_OTG_IEP_3_11 = 36,
-	DB8500_DMA_DEV37_USB_OTG_IEP_2_10 = 37,
-	DB8500_DMA_DEV38_USB_OTG_IEP_1_9 = 38,
-	DB8500_DMA_DEV39_USB_OTG_IEP_8 = 39,
-	DB8500_DMA_DEV40_SPI3_RX = 40,
-	DB8500_DMA_DEV41_SD_MM3_RX = 41,
-	DB8500_DMA_DEV42_SD_MM4_RX = 42,
-	DB8500_DMA_DEV43_SD_MM5_RX = 43,
-	DB8500_DMA_DEV44_SRC_SXA4_RX_TX = 44,
-	DB8500_DMA_DEV45_SRC_SXA5_RX_TX = 45,
-	DB8500_DMA_DEV46_SLIM0_CH8_RX_SRC_SXA6_RX_TX = 46,
-	DB8500_DMA_DEV47_SLIM0_CH9_RX_SRC_SXA7_RX_TX = 47,
-	DB8500_DMA_DEV48_CAC1_RX = 48,
-	/* 49, 50 and 51 are not used */
-	DB8500_DMA_DEV52_SLIM0_CH4_RX_HSI_RX_CH4 = 52,
-	DB8500_DMA_DEV53_SLIM0_CH5_RX_HSI_RX_CH5 = 53,
-	DB8500_DMA_DEV54_SLIM0_CH6_RX_HSI_RX_CH6 = 54,
-	DB8500_DMA_DEV55_SLIM0_CH7_RX_HSI_RX_CH7 = 55,
-	/* 56, 57, 58, 59 and 60 are not used */
-	DB8500_DMA_DEV61_CAC0_RX = 61,
-	/* 62 and 63 are not used */
-};
-
-enum dma_dest_dev_type {
-	DB8500_DMA_DEV0_SPI0_TX = 0,
-	DB8500_DMA_DEV1_SD_MMC0_TX = 1,
-	DB8500_DMA_DEV2_SD_MMC1_TX = 2,
-	DB8500_DMA_DEV3_SD_MMC2_TX = 3,
-	DB8500_DMA_DEV4_I2C1_TX = 4,
-	DB8500_DMA_DEV5_I2C3_TX = 5,
-	DB8500_DMA_DEV6_I2C2_TX = 6,
-	DB8500_DMA_DEV7_I2C4_TX = 7, /* Only on V1 and later */
-	DB8500_DMA_DEV8_SSP0_TX = 8,
-	DB8500_DMA_DEV9_SSP1_TX = 9,
-	/* 10 is not used*/
-	DB8500_DMA_DEV11_UART2_TX = 11,
-	DB8500_DMA_DEV12_UART1_TX = 12,
-	DB8500_DMA_DEV13_UART0_TX = 13,
-	DB8500_DMA_DEV14_MSP2_TX = 14,
-	DB8500_DMA_DEV15_I2C0_TX = 15,
-	DB8500_DMA_DEV16_USB_OTG_OEP_7_15 = 16,
-	DB8500_DMA_DEV17_USB_OTG_OEP_6_14 = 17,
-	DB8500_DMA_DEV18_USB_OTG_OEP_5_13 = 18,
-	DB8500_DMA_DEV19_USB_OTG_OEP_4_12 = 19,
-	DB8500_DMA_DEV20_SLIM0_CH0_TX_HSI_TX_CH0 = 20,
-	DB8500_DMA_DEV21_SLIM0_CH1_TX_HSI_TX_CH1 = 21,
-	DB8500_DMA_DEV22_SLIM0_CH2_TX_HSI_TX_CH2 = 22,
-	DB8500_DMA_DEV23_SLIM0_CH3_TX_HSI_TX_CH3 = 23,
-	DB8500_DMA_DEV24_DST_SXA0_RX_TX = 24,
-	DB8500_DMA_DEV25_DST_SXA1_RX_TX = 25,
-	DB8500_DMA_DEV26_DST_SXA2_RX_TX = 26,
-	DB8500_DMA_DEV27_DST_SXA3_RX_TX = 27,
-	DB8500_DMA_DEV28_SD_MM2_TX = 28,
-	DB8500_DMA_DEV29_SD_MM0_TX = 29,
-	DB8500_DMA_DEV30_MSP1_TX = 30,
-	DB8500_DMA_DEV31_MSP0_TX_SLIM0_CH0_TX = 31,
-	DB8500_DMA_DEV32_SD_MM1_TX = 32,
-	DB8500_DMA_DEV33_SPI2_TX = 33,
-	DB8500_DMA_DEV34_I2C3_TX2 = 34,
-	DB8500_DMA_DEV35_SPI1_TX = 35,
-	DB8500_DMA_DEV36_USB_OTG_OEP_3_11 = 36,
-	DB8500_DMA_DEV37_USB_OTG_OEP_2_10 = 37,
-	DB8500_DMA_DEV38_USB_OTG_OEP_1_9 = 38,
-	DB8500_DMA_DEV39_USB_OTG_OEP_8 = 39,
-	DB8500_DMA_DEV40_SPI3_TX = 40,
-	DB8500_DMA_DEV41_SD_MM3_TX = 41,
-	DB8500_DMA_DEV42_SD_MM4_TX = 42,
-	DB8500_DMA_DEV43_SD_MM5_TX = 43,
-	DB8500_DMA_DEV44_DST_SXA4_RX_TX = 44,
-	DB8500_DMA_DEV45_DST_SXA5_RX_TX = 45,
-	DB8500_DMA_DEV46_SLIM0_CH8_TX_DST_SXA6_RX_TX = 46,
-	DB8500_DMA_DEV47_SLIM0_CH9_TX_DST_SXA7_RX_TX = 47,
-	DB8500_DMA_DEV48_CAC1_TX  = 48,
-	DB8500_DMA_DEV49_CAC1_TX_HAC1_TX = 49,
-	DB8500_DMA_DEV50_HAC1_TX = 50,
-	DB8500_DMA_MEMCPY_TX_0 = 51,
-	DB8500_DMA_DEV52_SLIM1_CH4_TX_HSI_TX_CH4 = 52,
-	DB8500_DMA_DEV53_SLIM1_CH5_TX_HSI_TX_CH5 = 53,
-	DB8500_DMA_DEV54_SLIM1_CH6_TX_HSI_TX_CH6 = 54,
-	DB8500_DMA_DEV55_SLIM1_CH7_TX_HSI_TX_CH7 = 55,
-	DB8500_DMA_MEMCPY_TX_1 = 56,
-	DB8500_DMA_MEMCPY_TX_2 = 57,
-	DB8500_DMA_MEMCPY_TX_3 = 58,
-	DB8500_DMA_MEMCPY_TX_4 = 59,
-	DB8500_DMA_MEMCPY_TX_5 = 60,
-	DB8500_DMA_DEV61_CAC0_TX = 61,
-	DB8500_DMA_DEV62_CAC0_TX_HAC0_TX = 62,
-	DB8500_DMA_DEV63_HAC0_TX = 63,
+	DB8500_DMA_DEV30_MSP3 = 30,
+	DB8500_DMA_DEV31_MSP0_SLIM0_CH0 = 31,
+	DB8500_DMA_DEV32_SD_MM1 = 32,
+	DB8500_DMA_DEV33_SPI2 = 33,
+	DB8500_DMA_DEV34_I2C3_RX2_TX2 = 34,
+	DB8500_DMA_DEV35_SPI1 = 35,
+	DB8500_DMA_DEV36_USB_OTG_IEP_AND_OEP_3_11 = 36,
+	DB8500_DMA_DEV37_USB_OTG_IEP_AND_OEP_2_10 = 37,
+	DB8500_DMA_DEV38_USB_OTG_IEP_AND_OEP_1_9 = 38,
+	DB8500_DMA_DEV39_USB_OTG_IEP_AND_OEP_8 = 39,
+	DB8500_DMA_DEV40_SPI3 = 40,
+	DB8500_DMA_DEV41_SD_MM3 = 41,
+	DB8500_DMA_DEV42_SD_MM4 = 42,
+	DB8500_DMA_DEV43_SD_MM5 = 43,
+	DB8500_DMA_DEV44_SXA4 = 44,
+	DB8500_DMA_DEV45_SXA5 = 45,
+	DB8500_DMA_DEV46_SLIM0_CH8_SRC_SXA6 = 46,
+	DB8500_DMA_DEV47_SLIM0_CH9_SRC_SXA7 = 47,
+	DB8500_DMA_DEV48_CAC1 = 48,
+	DB8500_DMA_DEV49_CAC1_TX_HAC1_TX = 49,		/* TX only */
+	DB8500_DMA_DEV50_HAC1_TX = 50,			/* TX only */
+	DB8500_DMA_MEMCPY_TX_0 = 51,			/* TX only */
+	DB8500_DMA_DEV52_SLIM0_CH4_HSI_CH4 = 52,
+	DB8500_DMA_DEV53_SLIM0_CH5_HSI_CH5 = 53,
+	DB8500_DMA_DEV54_SLIM0_CH6_HSI_CH6 = 54,
+	DB8500_DMA_DEV55_SLIM0_CH7_HSI_CH7 = 55,
+	/* 56 -> 60 are channels reserved for memcpy only */
+	DB8500_DMA_DEV61_CAC0 = 61,
+	DB8500_DMA_DEV62_CAC0_TX_HAC0_TX = 62,		/* TX only */
+	DB8500_DMA_DEV63_HAC0_TX = 63,			/* TX only */
 };
 
 #endif
diff --git a/arch/arm/mach-ux500/usb.c b/arch/arm/mach-ux500/usb.c
index 78ac65f..e0ea490 100644
--- a/arch/arm/mach-ux500/usb.c
+++ b/arch/arm/mach-ux500/usb.c
@@ -15,7 +15,6 @@
 #define MUSB_DMA40_RX_CH { \
 		.mode = STEDMA40_MODE_LOGICAL, \
 		.dir = STEDMA40_PERIPH_TO_MEM, \
-		.dst_dev_type = STEDMA40_DEV_DST_MEMORY, \
 		.src_info.data_width = STEDMA40_WORD_WIDTH, \
 		.dst_info.data_width = STEDMA40_WORD_WIDTH, \
 		.src_info.psize = STEDMA40_PSIZE_LOG_16, \
@@ -25,7 +24,6 @@
 #define MUSB_DMA40_TX_CH { \
 		.mode = STEDMA40_MODE_LOGICAL, \
 		.dir = STEDMA40_MEM_TO_PERIPH, \
-		.src_dev_type = STEDMA40_DEV_SRC_MEMORY, \
 		.src_info.data_width = STEDMA40_WORD_WIDTH, \
 		.dst_info.data_width = STEDMA40_WORD_WIDTH, \
 		.src_info.psize = STEDMA40_PSIZE_LOG_16, \
@@ -125,20 +123,20 @@ struct platform_device ux500_musb_device = {
 	.resource = usb_resources,
 };
 
-static inline void ux500_usb_dma_update_rx_ch_config(int *src_dev_type)
+static inline void ux500_usb_dma_update_rx_ch_config(int *dev_type)
 {
 	u32 idx;
 
 	for (idx = 0; idx < UX500_MUSB_DMA_NUM_RX_CHANNELS; idx++)
-		musb_dma_rx_ch[idx].src_dev_type = src_dev_type[idx];
+		musb_dma_rx_ch[idx].dev_type = dev_type[idx];
 }
 
-static inline void ux500_usb_dma_update_tx_ch_config(int *dst_dev_type)
+static inline void ux500_usb_dma_update_tx_ch_config(int *dev_type)
 {
 	u32 idx;
 
 	for (idx = 0; idx < UX500_MUSB_DMA_NUM_TX_CHANNELS; idx++)
-		musb_dma_tx_ch[idx].dst_dev_type = dst_dev_type[idx];
+		musb_dma_tx_ch[idx].dev_type = dev_type[idx];
 }
 
 void ux500_add_usb(struct device *parent, resource_size_t base, int irq,
diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index 121c46b..e50354d 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -1288,21 +1288,17 @@ static void __d40_config_set_event(struct d40_chan *d40c,
 static void d40_config_set_event(struct d40_chan *d40c,
 				 enum d40_events event_type)
 {
+	u32 event = D40_TYPE_TO_EVENT(d40c->dma_cfg.dev_type);
+
 	/* Enable event line connected to device (or memcpy) */
 	if ((d40c->dma_cfg.dir ==  STEDMA40_PERIPH_TO_MEM) ||
-	    (d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_PERIPH)) {
-		u32 event = D40_TYPE_TO_EVENT(d40c->dma_cfg.src_dev_type);
-
+	    (d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_PERIPH))
 		__d40_config_set_event(d40c, event_type, event,
 				       D40_CHAN_REG_SSLNK);
-	}
-
-	if (d40c->dma_cfg.dir !=  STEDMA40_PERIPH_TO_MEM) {
-		u32 event = D40_TYPE_TO_EVENT(d40c->dma_cfg.dst_dev_type);
 
+	if (d40c->dma_cfg.dir !=  STEDMA40_PERIPH_TO_MEM)
 		__d40_config_set_event(d40c, event_type, event,
 				       D40_CHAN_REG_SDLNK);
-	}
 }
 
 static u32 d40_chan_has_events(struct d40_chan *d40c)
@@ -1744,8 +1740,6 @@ static int d40_validate_conf(struct d40_chan *d40c,
 			     struct stedma40_chan_cfg *conf)
 {
 	int res = 0;
-	u32 dst_event_group = D40_TYPE_TO_GROUP(conf->dst_dev_type);
-	u32 src_event_group = D40_TYPE_TO_GROUP(conf->src_dev_type);
 	bool is_log = conf->mode == STEDMA40_MODE_LOGICAL;
 
 	if (!conf->dir) {
@@ -1753,44 +1747,26 @@ static int d40_validate_conf(struct d40_chan *d40c,
 		res = -EINVAL;
 	}
 
-	if (conf->dst_dev_type != STEDMA40_DEV_DST_MEMORY &&
-	    d40c->base->plat_data->dev_tx[conf->dst_dev_type] == 0 &&
-	    d40c->runtime_addr == 0) {
-
-		chan_err(d40c, "Invalid TX channel address (%d)\n",
-			 conf->dst_dev_type);
-		res = -EINVAL;
-	}
-
-	if (conf->src_dev_type != STEDMA40_DEV_SRC_MEMORY &&
-	    d40c->base->plat_data->dev_rx[conf->src_dev_type] == 0 &&
-	    d40c->runtime_addr == 0) {
-		chan_err(d40c, "Invalid RX channel address (%d)\n",
-			conf->src_dev_type);
+	if ((is_log && conf->dev_type > d40c->base->num_log_chans)  ||
+	    (!is_log && conf->dev_type > d40c->base->num_phy_chans) ||
+	    (conf->dev_type < 0)) {
+		chan_err(d40c, "Invalid device type (%d)\n", conf->dev_type);
 		res = -EINVAL;
 	}
 
 	if (conf->dir == STEDMA40_MEM_TO_PERIPH &&
-	    dst_event_group == STEDMA40_DEV_DST_MEMORY) {
-		chan_err(d40c, "Invalid dst\n");
+	    d40c->base->plat_data->dev_tx[conf->dev_type] == 0 &&
+	    d40c->runtime_addr == 0) {
+		chan_err(d40c, "Invalid TX channel address (%d)\n",
+			 conf->dev_type);
 		res = -EINVAL;
 	}
 
 	if (conf->dir == STEDMA40_PERIPH_TO_MEM &&
-	    src_event_group == STEDMA40_DEV_SRC_MEMORY) {
-		chan_err(d40c, "Invalid src\n");
-		res = -EINVAL;
-	}
-
-	if (src_event_group == STEDMA40_DEV_SRC_MEMORY &&
-	    dst_event_group == STEDMA40_DEV_DST_MEMORY && is_log) {
-		chan_err(d40c, "No event line\n");
-		res = -EINVAL;
-	}
-
-	if (conf->dir == STEDMA40_PERIPH_TO_PERIPH &&
-	    (src_event_group != dst_event_group)) {
-		chan_err(d40c, "Invalid event group\n");
+	    d40c->base->plat_data->dev_rx[conf->dev_type] == 0 &&
+	    d40c->runtime_addr == 0) {
+		chan_err(d40c, "Invalid RX channel address (%d)\n",
+			 conf->dev_type);
 		res = -EINVAL;
 	}
 
@@ -1911,7 +1887,7 @@ out:
 
 static int d40_allocate_channel(struct d40_chan *d40c, bool *first_phy_user)
 {
-	int dev_type;
+	int dev_type = d40c->dma_cfg.dev_type;
 	int event_group;
 	int event_line;
 	struct d40_phy_res *phys;
@@ -1926,13 +1902,11 @@ static int d40_allocate_channel(struct d40_chan *d40c, bool *first_phy_user)
 	num_phy_chans = d40c->base->num_phy_chans;
 
 	if (d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_MEM) {
-		dev_type = d40c->dma_cfg.src_dev_type;
 		log_num = 2 * dev_type;
 		is_src = true;
 	} else if (d40c->dma_cfg.dir == STEDMA40_MEM_TO_PERIPH ||
 		   d40c->dma_cfg.dir == STEDMA40_MEM_TO_MEM) {
 		/* dst event lines are used for logical memcpy */
-		dev_type = d40c->dma_cfg.dst_dev_type;
 		log_num = 2 * dev_type + 1;
 		is_src = false;
 	} else
@@ -2044,8 +2018,7 @@ static int d40_config_memcpy(struct d40_chan *d40c)
 
 	if (dma_has_cap(DMA_MEMCPY, cap) && !dma_has_cap(DMA_SLAVE, cap)) {
 		d40c->dma_cfg = dma40_memcpy_conf_log;
-		d40c->dma_cfg.src_dev_type = STEDMA40_DEV_SRC_MEMORY;
-		d40c->dma_cfg.dst_dev_type = dma40_memcpy_channels[d40c->chan.chan_id];
+		d40c->dma_cfg.dev_type = dma40_memcpy_channels[d40c->chan.chan_id];
 
 	} else if (dma_has_cap(DMA_MEMCPY, cap) &&
 		   dma_has_cap(DMA_SLAVE, cap)) {
@@ -2062,7 +2035,7 @@ static int d40_free_dma(struct d40_chan *d40c)
 {
 
 	int res = 0;
-	u32 event;
+	u32 event = D40_TYPE_TO_EVENT(d40c->dma_cfg.dev_type);
 	struct d40_phy_res *phy = d40c->phy_chan;
 	bool is_src;
 
@@ -2081,13 +2054,11 @@ static int d40_free_dma(struct d40_chan *d40c)
 	}
 
 	if (d40c->dma_cfg.dir == STEDMA40_MEM_TO_PERIPH ||
-	    d40c->dma_cfg.dir == STEDMA40_MEM_TO_MEM) {
-		event = D40_TYPE_TO_EVENT(d40c->dma_cfg.dst_dev_type);
+	    d40c->dma_cfg.dir == STEDMA40_MEM_TO_MEM)
 		is_src = false;
-	} else if (d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_MEM) {
-		event = D40_TYPE_TO_EVENT(d40c->dma_cfg.src_dev_type);
+	else if (d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_MEM)
 		is_src = true;
-	} else {
+	else {
 		chan_err(d40c, "Unknown direction\n");
 		return -EINVAL;
 	}
@@ -2128,7 +2099,7 @@ static bool d40_is_paused(struct d40_chan *d40c)
 	unsigned long flags;
 	void __iomem *active_reg;
 	u32 status;
-	u32 event;
+	u32 event = D40_TYPE_TO_EVENT(d40c->dma_cfg.dev_type);
 
 	spin_lock_irqsave(&d40c->lock, flags);
 
@@ -2149,10 +2120,8 @@ static bool d40_is_paused(struct d40_chan *d40c)
 
 	if (d40c->dma_cfg.dir == STEDMA40_MEM_TO_PERIPH ||
 	    d40c->dma_cfg.dir == STEDMA40_MEM_TO_MEM) {
-		event = D40_TYPE_TO_EVENT(d40c->dma_cfg.dst_dev_type);
 		status = readl(chanbase + D40_CHAN_REG_SDLNK);
 	} else if (d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_MEM) {
-		event = D40_TYPE_TO_EVENT(d40c->dma_cfg.src_dev_type);
 		status = readl(chanbase + D40_CHAN_REG_SSLNK);
 	} else {
 		chan_err(d40c, "Unknown direction\n");
@@ -2294,9 +2263,9 @@ d40_get_dev_addr(struct d40_chan *chan, enum dma_transfer_direction direction)
 		return chan->runtime_addr;
 
 	if (direction == DMA_DEV_TO_MEM)
-		addr = plat->dev_rx[cfg->src_dev_type];
+		addr = plat->dev_rx[cfg->dev_type];
 	else if (direction == DMA_MEM_TO_DEV)
-		addr = plat->dev_tx[cfg->dst_dev_type];
+		addr = plat->dev_tx[cfg->dev_type];
 
 	return addr;
 }
@@ -2427,11 +2396,11 @@ static void d40_set_prio_realtime(struct d40_chan *d40c)
 
 	if ((d40c->dma_cfg.dir ==  STEDMA40_PERIPH_TO_MEM) ||
 	    (d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_PERIPH))
-		__d40_set_prio_rt(d40c, d40c->dma_cfg.src_dev_type, true);
+		__d40_set_prio_rt(d40c, d40c->dma_cfg.dev_type, true);
 
 	if ((d40c->dma_cfg.dir ==  STEDMA40_MEM_TO_PERIPH) ||
 	    (d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_PERIPH))
-		__d40_set_prio_rt(d40c, d40c->dma_cfg.dst_dev_type, false);
+		__d40_set_prio_rt(d40c, d40c->dma_cfg.dev_type, false);
 }
 
 /* DMA ENGINE functions */
@@ -2741,7 +2710,7 @@ static int d40_set_runtime_config(struct dma_chan *chan,
 
 	if (config->direction == DMA_DEV_TO_MEM) {
 		dma_addr_t dev_addr_rx =
-			d40c->base->plat_data->dev_rx[cfg->src_dev_type];
+			d40c->base->plat_data->dev_rx[cfg->dev_type];
 
 		config_addr = config->src_addr;
 		if (dev_addr_rx)
@@ -2764,7 +2733,7 @@ static int d40_set_runtime_config(struct dma_chan *chan,
 
 	} else if (config->direction == DMA_MEM_TO_DEV) {
 		dma_addr_t dev_addr_tx =
-			d40c->base->plat_data->dev_tx[cfg->dst_dev_type];
+			d40c->base->plat_data->dev_tx[cfg->dev_type];
 
 		config_addr = config->dst_addr;
 		if (dev_addr_tx)
diff --git a/drivers/dma/ste_dma40_ll.c b/drivers/dma/ste_dma40_ll.c
index 7180e0d..5eb6c10 100644
--- a/drivers/dma/ste_dma40_ll.c
+++ b/drivers/dma/ste_dma40_ll.c
@@ -63,7 +63,7 @@ void d40_phy_cfg(struct stedma40_chan_cfg *cfg,
 		    (cfg->dir == STEDMA40_PERIPH_TO_PERIPH)) {
 			/* Set master port to 1 */
 			src |= 1 << D40_SREG_CFG_MST_POS;
-			src |= D40_TYPE_TO_EVENT(cfg->src_dev_type);
+			src |= D40_TYPE_TO_EVENT(cfg->dev_type);
 
 			if (cfg->src_info.flow_ctrl == STEDMA40_NO_FLOW_CTRL)
 				src |= 1 << D40_SREG_CFG_PHY_TM_POS;
@@ -74,7 +74,7 @@ void d40_phy_cfg(struct stedma40_chan_cfg *cfg,
 		    (cfg->dir == STEDMA40_PERIPH_TO_PERIPH)) {
 			/* Set master port to 1 */
 			dst |= 1 << D40_SREG_CFG_MST_POS;
-			dst |= D40_TYPE_TO_EVENT(cfg->dst_dev_type);
+			dst |= D40_TYPE_TO_EVENT(cfg->dev_type);
 
 			if (cfg->dst_info.flow_ctrl == STEDMA40_NO_FLOW_CTRL)
 				dst |= 1 << D40_SREG_CFG_PHY_TM_POS;
diff --git a/include/linux/platform_data/dma-ste-dma40.h b/include/linux/platform_data/dma-ste-dma40.h
index 869c571..9e42a67 100644
--- a/include/linux/platform_data/dma-ste-dma40.h
+++ b/include/linux/platform_data/dma-ste-dma40.h
@@ -109,8 +109,7 @@ struct stedma40_half_channel_info {
  * version 3+, i.e DB8500v2+
  * @mode: channel mode: physical, logical, or operation
  * @mode_opt: options for the chosen channel mode
- * @src_dev_type: Src device type
- * @dst_dev_type: Dst device type
+ * @dev_type: src/dst device type (driver uses dir to figure out which)
  * @src_info: Parameters for dst half channel
  * @dst_info: Parameters for dst half channel
  * @use_fixed_channel: if true, use physical channel specified by phy_channel
@@ -126,8 +125,7 @@ struct stedma40_chan_cfg {
 	bool					 realtime;
 	enum stedma40_mode			 mode;
 	enum stedma40_mode_opt			 mode_opt;
-	int					 src_dev_type;
-	int					 dst_dev_type;
+	int					 dev_type;
 	struct stedma40_half_channel_info	 src_info;
 	struct stedma40_half_channel_info	 dst_info;
 
-- 
1.7.10.4



From lee.jones at linaro.org  Thu Apr 18 06:12:00 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Thu, 18 Apr 2013 11:12:00 +0100
Subject: [PATCH 18/32] dmaengine: ste_dma40: Don't configure runtime
 configurable setup during allocate
In-Reply-To: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1366279934-30761-19-git-send-email-lee.jones@linaro.org>

Using the dmaengine API, allocating and configuring a channel are two
separate actions. Here we're removing logical channel configuration from
the channel allocating routines.

Cc: Vinod Koul <vinod.koul at intel.com>
Cc: Dan Williams <djbw at fb.com>
Cc: Per Forlin <per.forlin at stericsson.com>
Cc: Rabin Vincent <rabin at rab.in>
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 drivers/dma/ste_dma40.c |    3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index ff41972..04cc75f 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -2441,9 +2441,6 @@ static int d40_alloc_chan_resources(struct dma_chan *chan)
 	d40_set_prio_realtime(d40c);
 
 	if (chan_is_logical(d40c)) {
-		d40_log_cfg(&d40c->dma_cfg,
-			    &d40c->log_def.lcsp1, &d40c->log_def.lcsp3);
-
 		if (d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_MEM)
 			d40c->lcpa = d40c->base->lcpa_base +
 				d40c->dma_cfg.src_dev_type * D40_LCPA_CHAN_SIZE;
-- 
1.7.10.4



From lee.jones at linaro.org  Thu Apr 18 06:11:59 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Thu, 18 Apr 2013 11:11:59 +0100
Subject: [PATCH 17/32] dmaengine: ste_dma40: Remove redundant argument from
 d40_phy_cfg()
In-Reply-To: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1366279934-30761-18-git-send-email-lee.jones@linaro.org>

d40_phy_cfg is now only ever called to configure physical channels, so
there's no requirement to pass though an argument describing the type
of channel and to subsequently test for it.

Cc: Vinod Koul <vinod.koul at intel.com>
Cc: Dan Williams <djbw at fb.com>
Cc: Per Forlin <per.forlin at stericsson.com>
Cc: Rabin Vincent <rabin at rab.in>
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 drivers/dma/ste_dma40.c    |    3 +-
 drivers/dma/ste_dma40_ll.c |  101 +++++++++++++++++++++-----------------------
 drivers/dma/ste_dma40_ll.h |    3 +-
 3 files changed, 50 insertions(+), 57 deletions(-)

diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index 1c570b6..ff41972 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -2799,8 +2799,7 @@ static int d40_set_runtime_config(struct dma_chan *chan,
 	if (chan_is_logical(d40c))
 		d40_log_cfg(cfg, &d40c->log_def.lcsp1, &d40c->log_def.lcsp3);
 	else
-		d40_phy_cfg(cfg, &d40c->src_def_cfg,
-			    &d40c->dst_def_cfg, false);
+		d40_phy_cfg(cfg, &d40c->src_def_cfg, &d40c->dst_def_cfg);
 
 	/* These settings will take precedence later */
 	d40c->runtime_addr = config_addr;
diff --git a/drivers/dma/ste_dma40_ll.c b/drivers/dma/ste_dma40_ll.c
index b72d3e2..9ab9dff 100644
--- a/drivers/dma/ste_dma40_ll.c
+++ b/drivers/dma/ste_dma40_ll.c
@@ -56,63 +56,58 @@ void d40_log_gim_unmask(u32 *src_cfg, u32 *dst_cfg) {
 	*dst_cfg |= 1 << D40_SREG_CFG_LOG_GIM_POS;
 }
 
-/* Sets up SRC and DST CFG register for both logical and physical channels */
-void d40_phy_cfg(struct stedma40_chan_cfg *cfg,
-		 u32 *src_cfg, u32 *dst_cfg, bool is_log)
+void d40_phy_cfg(struct stedma40_chan_cfg *cfg, u32 *src_cfg, u32 *dst_cfg)
 {
 	u32 src = 0;
 	u32 dst = 0;
 
-	if (!is_log) {
-		/* Physical channel */
-		if ((cfg->dir ==  STEDMA40_PERIPH_TO_MEM) ||
-		    (cfg->dir == STEDMA40_PERIPH_TO_PERIPH)) {
-			/* Set master port to 1 */
-			src |= 1 << D40_SREG_CFG_MST_POS;
-			src |= D40_TYPE_TO_EVENT(cfg->dev_type);
-
-			if (cfg->src_info.flow_ctrl == STEDMA40_NO_FLOW_CTRL)
-				src |= 1 << D40_SREG_CFG_PHY_TM_POS;
-			else
-				src |= 3 << D40_SREG_CFG_PHY_TM_POS;
-		}
-		if ((cfg->dir ==  STEDMA40_MEM_TO_PERIPH) ||
-		    (cfg->dir == STEDMA40_PERIPH_TO_PERIPH)) {
-			/* Set master port to 1 */
-			dst |= 1 << D40_SREG_CFG_MST_POS;
-			dst |= D40_TYPE_TO_EVENT(cfg->dev_type);
-
-			if (cfg->dst_info.flow_ctrl == STEDMA40_NO_FLOW_CTRL)
-				dst |= 1 << D40_SREG_CFG_PHY_TM_POS;
-			else
-				dst |= 3 << D40_SREG_CFG_PHY_TM_POS;
-		}
-		/* Interrupt on end of transfer for destination */
-		dst |= 1 << D40_SREG_CFG_TIM_POS;
-
-		/* Generate interrupt on error */
-		src |= 1 << D40_SREG_CFG_EIM_POS;
-		dst |= 1 << D40_SREG_CFG_EIM_POS;
-
-		/* PSIZE */
-		if (cfg->src_info.psize != STEDMA40_PSIZE_PHY_1) {
-			src |= 1 << D40_SREG_CFG_PHY_PEN_POS;
-			src |= cfg->src_info.psize << D40_SREG_CFG_PSIZE_POS;
-		}
-		if (cfg->dst_info.psize != STEDMA40_PSIZE_PHY_1) {
-			dst |= 1 << D40_SREG_CFG_PHY_PEN_POS;
-			dst |= cfg->dst_info.psize << D40_SREG_CFG_PSIZE_POS;
-		}
-
-		/* Element size */
-		src |= cfg->src_info.data_width << D40_SREG_CFG_ESIZE_POS;
-		dst |= cfg->dst_info.data_width << D40_SREG_CFG_ESIZE_POS;
-
-		/* Set the priority bit to high for the physical channel */
-		if (cfg->high_priority) {
-			src |= 1 << D40_SREG_CFG_PRI_POS;
-			dst |= 1 << D40_SREG_CFG_PRI_POS;
-		}
+	if ((cfg->dir ==  STEDMA40_PERIPH_TO_MEM) ||
+	    (cfg->dir == STEDMA40_PERIPH_TO_PERIPH)) {
+		/* Set master port to 1 */
+		src |= 1 << D40_SREG_CFG_MST_POS;
+		src |= D40_TYPE_TO_EVENT(cfg->dev_type);
+
+		if (cfg->src_info.flow_ctrl == STEDMA40_NO_FLOW_CTRL)
+			src |= 1 << D40_SREG_CFG_PHY_TM_POS;
+		else
+			src |= 3 << D40_SREG_CFG_PHY_TM_POS;
+	}
+	if ((cfg->dir ==  STEDMA40_MEM_TO_PERIPH) ||
+	    (cfg->dir == STEDMA40_PERIPH_TO_PERIPH)) {
+		/* Set master port to 1 */
+		dst |= 1 << D40_SREG_CFG_MST_POS;
+		dst |= D40_TYPE_TO_EVENT(cfg->dev_type);
+
+		if (cfg->dst_info.flow_ctrl == STEDMA40_NO_FLOW_CTRL)
+			dst |= 1 << D40_SREG_CFG_PHY_TM_POS;
+		else
+			dst |= 3 << D40_SREG_CFG_PHY_TM_POS;
+	}
+	/* Interrupt on end of transfer for destination */
+	dst |= 1 << D40_SREG_CFG_TIM_POS;
+
+	/* Generate interrupt on error */
+	src |= 1 << D40_SREG_CFG_EIM_POS;
+	dst |= 1 << D40_SREG_CFG_EIM_POS;
+
+	/* PSIZE */
+	if (cfg->src_info.psize != STEDMA40_PSIZE_PHY_1) {
+		src |= 1 << D40_SREG_CFG_PHY_PEN_POS;
+		src |= cfg->src_info.psize << D40_SREG_CFG_PSIZE_POS;
+	}
+	if (cfg->dst_info.psize != STEDMA40_PSIZE_PHY_1) {
+		dst |= 1 << D40_SREG_CFG_PHY_PEN_POS;
+		dst |= cfg->dst_info.psize << D40_SREG_CFG_PSIZE_POS;
+	}
+
+	/* Element size */
+	src |= cfg->src_info.data_width << D40_SREG_CFG_ESIZE_POS;
+	dst |= cfg->dst_info.data_width << D40_SREG_CFG_ESIZE_POS;
+
+	/* Set the priority bit to high for the physical channel */
+	if (cfg->high_priority) {
+		src |= 1 << D40_SREG_CFG_PRI_POS;
+		dst |= 1 << D40_SREG_CFG_PRI_POS;
 	}
 
 	if (cfg->src_info.big_endian)
diff --git a/drivers/dma/ste_dma40_ll.h b/drivers/dma/ste_dma40_ll.h
index 8aad679..e54df09 100644
--- a/drivers/dma/ste_dma40_ll.h
+++ b/drivers/dma/ste_dma40_ll.h
@@ -434,8 +434,7 @@ void d40_log_gim_unmask(u32 *src_cfg, u32 *dst_cfg);
 
 void d40_phy_cfg(struct stedma40_chan_cfg *cfg,
 		 u32 *src_cfg,
-		 u32 *dst_cfg,
-		 bool is_log);
+		 u32 *dst_cfg);
 
 void d40_log_cfg(struct stedma40_chan_cfg *cfg,
 		 u32 *lcsp1,
-- 
1.7.10.4



From lee.jones at linaro.org  Thu Apr 18 06:12:01 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Thu, 18 Apr 2013 11:12:01 +0100
Subject: [PATCH 19/32] dmaengine: ste_dma40: Move more setup into the
 configuration routines
In-Reply-To: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1366279934-30761-20-git-send-email-lee.jones@linaro.org>

The less configuration we can do during the allocation of a channel the
better. As this will mean the likelihood of requiring extra information
which isn't normally passed through the dma_request_channel() is lessened.

Cc: Vinod Koul <vinod.koul at intel.com>
Cc: Dan Williams <djbw at fb.com>
Cc: Per Forlin <per.forlin at stericsson.com>
Cc: Rabin Vincent <rabin at rab.in>
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 drivers/dma/ste_dma40.c |   22 ++++++++++------------
 1 file changed, 10 insertions(+), 12 deletions(-)

diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index 04cc75f..28fe153 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -2440,16 +2440,6 @@ static int d40_alloc_chan_resources(struct dma_chan *chan)
 
 	d40_set_prio_realtime(d40c);
 
-	if (chan_is_logical(d40c)) {
-		if (d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_MEM)
-			d40c->lcpa = d40c->base->lcpa_base +
-				d40c->dma_cfg.src_dev_type * D40_LCPA_CHAN_SIZE;
-		else
-			d40c->lcpa = d40c->base->lcpa_base +
-				d40c->dma_cfg.dst_dev_type *
-				D40_LCPA_CHAN_SIZE + D40_LCPA_CHAN_DST_DELTA;
-	}
-
 	if (chan_is_logical(d40c))
 		d40_log_gim_unmask(&d40c->src_def_cfg, &d40c->dst_def_cfg);
 
@@ -2793,9 +2783,17 @@ static int d40_set_runtime_config(struct dma_chan *chan,
 		return ret;
 
 	/* Fill in register values */
-	if (chan_is_logical(d40c))
+	if (chan_is_logical(d40c)) {
+		if (d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_MEM)
+			d40c->lcpa = d40c->base->lcpa_base +
+				d40c->dma_cfg.dev_type * D40_LCPA_CHAN_SIZE;
+		else
+			d40c->lcpa = d40c->base->lcpa_base +
+				d40c->dma_cfg.dev_type *
+				D40_LCPA_CHAN_SIZE + D40_LCPA_CHAN_DST_DELTA;
+
 		d40_log_cfg(cfg, &d40c->log_def.lcsp1, &d40c->log_def.lcsp3);
-	else
+	} else
 		d40_phy_cfg(cfg, &d40c->src_def_cfg, &d40c->dst_def_cfg);
 
 	/* These settings will take precedence later */
-- 
1.7.10.4



From lee.jones at linaro.org  Thu Apr 18 06:12:02 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Thu, 18 Apr 2013 11:12:02 +0100
Subject: [PATCH 20/32] dmaengine: ste_dma40: Move rev error-check up to
 revision acquisition
In-Reply-To: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1366279934-30761-21-git-send-email-lee.jones@linaro.org>

At the moment we fetch the hardware revision, then do some stuff, then
check whether the revision is correct and return in error if it's not.
Well we may as well check it as soon as we know what it is, so let's
move the check right up underneath where we acquire the version.

Cc: Vinod Koul <vinod.koul at intel.com>
Cc: Dan Williams <djbw at fb.com>
Cc: Per Forlin <per.forlin at stericsson.com>
Cc: Rabin Vincent <rabin at rab.in>
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 drivers/dma/ste_dma40.c |   10 ++++------
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index 28fe153..282dd59 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -3185,6 +3185,10 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
 	 * DB8540v1 has revision 4
 	 */
 	rev = AMBA_REV_BITS(pid);
+	if (rev < 2) {
+		d40_err(&pdev->dev, "hardware revision: %d is not supported", rev);
+		goto failure;
+	}
 
 	plat_data = pdev->dev.platform_data;
 
@@ -3199,12 +3203,6 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
 	dev_info(&pdev->dev, "hardware revision: %d @ 0x%x with %d physical channels\n",
 		 rev, res->start, num_phy_chans);
 
-	if (rev < 2) {
-		d40_err(&pdev->dev, "hardware revision: %d is not supported",
-			rev);
-		goto failure;
-	}
-
 	base = kzalloc(ALIGN(sizeof(struct d40_base), 4) +
 		       (num_phy_chans + num_log_chans + ARRAY_SIZE(dma40_memcpy_channels)) *
 		       sizeof(struct d40_chan), GFP_KERNEL);
-- 
1.7.10.4



From lee.jones at linaro.org  Thu Apr 18 06:12:08 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Thu, 18 Apr 2013 11:12:08 +0100
Subject: [PATCH 26/32] ARM: ux500: Supply UART's DMA configuration via Device
 Tree
In-Reply-To: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1366279934-30761-27-git-send-email-lee.jones@linaro.org>

When requesting a channel, a DMA client needs to pass some pieces of
information such as; request channel, device type, channel type and
direction etc. Normally we do this in the form of platform data, but
when DT is enabled we need to pass it using the driver's bindings
instead.

Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/boot/dts/dbx5x0.dtsi |   17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/arch/arm/boot/dts/dbx5x0.dtsi b/arch/arm/boot/dts/dbx5x0.dtsi
index e2fa20f..bd0fe5f 100644
--- a/arch/arm/boot/dts/dbx5x0.dtsi
+++ b/arch/arm/boot/dts/dbx5x0.dtsi
@@ -569,18 +569,35 @@
 			compatible = "arm,pl011", "arm,primecell";
 			reg = <0x80120000 0x1000>;
 			interrupts = <0 11 0x4>;
+
+			dmas = <&dma 0 13 0x8>, /* Logical - DevToMem */
+			       <&dma 0 13 0x4>; /* Logical - MemToDev */
+			dma-names = "rx", "tx";
+
 			status = "disabled";
 		};
+
 		uart at 80121000 {
 			compatible = "arm,pl011", "arm,primecell";
 			reg = <0x80121000 0x1000>;
 			interrupts = <0 19 0x4>;
+
+			dmas = <&dma 0 12 0x8>, /* Logical - DevToMem */
+			       <&dma 0 12 0x4>; /* Logical - MemToDev */
+			dma-names = "rx", "tx";
+
 			status = "disabled";
 		};
+
 		uart at 80007000 {
 			compatible = "arm,pl011", "arm,primecell";
 			reg = <0x80007000 0x1000>;
 			interrupts = <0 26 0x4>;
+
+			dmas = <&dma 0 11 0x8>, /* Logical - DevToMem */
+			       <&dma 0 11 0x4>; /* Logical - MemToDev */
+			dma-names = "rx", "tx";
+
 			status = "disabled";
 		};
 
-- 
1.7.10.4



From lee.jones at linaro.org  Thu Apr 18 06:11:52 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Thu, 18 Apr 2013 11:11:52 +0100
Subject: [PATCH 10/32] ARM: ux500: Remove unused 'data_width' attributes from
 SSP DMA configs
In-Reply-To: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1366279934-30761-11-git-send-email-lee.jones@linaro.org>

DMA configuration data is now allocated in the SSP driver, so these
are just ignored.

Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/mach-ux500/board-mop500.c |    4 ----
 1 file changed, 4 deletions(-)

diff --git a/arch/arm/mach-ux500/board-mop500.c b/arch/arm/mach-ux500/board-mop500.c
index a8b3ad9..35fd82f 100644
--- a/arch/arm/mach-ux500/board-mop500.c
+++ b/arch/arm/mach-ux500/board-mop500.c
@@ -495,16 +495,12 @@ static struct stedma40_chan_cfg ssp0_dma_cfg_rx = {
 	.mode = STEDMA40_MODE_LOGICAL,
 	.dir = STEDMA40_PERIPH_TO_MEM,
 	.dev_type = DB8500_DMA_DEV8_SSP0,
-	.src_info.data_width = STEDMA40_BYTE_WIDTH,
-	.dst_info.data_width = STEDMA40_BYTE_WIDTH,
 };
 
 static struct stedma40_chan_cfg ssp0_dma_cfg_tx = {
 	.mode = STEDMA40_MODE_LOGICAL,
 	.dir = STEDMA40_MEM_TO_PERIPH,
 	.dev_type = DB8500_DMA_DEV8_SSP0,
-	.src_info.data_width = STEDMA40_BYTE_WIDTH,
-	.dst_info.data_width = STEDMA40_BYTE_WIDTH,
 };
 #endif
 
-- 
1.7.10.4



From lee.jones at linaro.org  Thu Apr 18 06:11:53 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Thu, 18 Apr 2013 11:11:53 +0100
Subject: [PATCH 11/32] ARM: ux500: Remove unused 'data_width' attributes from
 UART DMA configs
In-Reply-To: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1366279934-30761-12-git-send-email-lee.jones@linaro.org>

DMA configuration data is now allocated in the UART driver, so these
are just ignored.

Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/mach-ux500/board-mop500.c |   12 ------------
 1 file changed, 12 deletions(-)

diff --git a/arch/arm/mach-ux500/board-mop500.c b/arch/arm/mach-ux500/board-mop500.c
index 35fd82f..883dc66 100644
--- a/arch/arm/mach-ux500/board-mop500.c
+++ b/arch/arm/mach-ux500/board-mop500.c
@@ -530,48 +530,36 @@ static struct stedma40_chan_cfg uart0_dma_cfg_rx = {
 	.mode = STEDMA40_MODE_LOGICAL,
 	.dir = STEDMA40_PERIPH_TO_MEM,
 	.dev_type = DB8500_DMA_DEV13_UART0,
-	.src_info.data_width = STEDMA40_BYTE_WIDTH,
-	.dst_info.data_width = STEDMA40_BYTE_WIDTH,
 };
 
 static struct stedma40_chan_cfg uart0_dma_cfg_tx = {
 	.mode = STEDMA40_MODE_LOGICAL,
 	.dir = STEDMA40_MEM_TO_PERIPH,
 	.dev_type = DB8500_DMA_DEV13_UART0,
-	.src_info.data_width = STEDMA40_BYTE_WIDTH,
-	.dst_info.data_width = STEDMA40_BYTE_WIDTH,
 };
 
 static struct stedma40_chan_cfg uart1_dma_cfg_rx = {
 	.mode = STEDMA40_MODE_LOGICAL,
 	.dir = STEDMA40_PERIPH_TO_MEM,
 	.dev_type = DB8500_DMA_DEV12_UART1,
-	.src_info.data_width = STEDMA40_BYTE_WIDTH,
-	.dst_info.data_width = STEDMA40_BYTE_WIDTH,
 };
 
 static struct stedma40_chan_cfg uart1_dma_cfg_tx = {
 	.mode = STEDMA40_MODE_LOGICAL,
 	.dir = STEDMA40_MEM_TO_PERIPH,
 	.dev_type = DB8500_DMA_DEV12_UART1,
-	.src_info.data_width = STEDMA40_BYTE_WIDTH,
-	.dst_info.data_width = STEDMA40_BYTE_WIDTH,
 };
 
 static struct stedma40_chan_cfg uart2_dma_cfg_rx = {
 	.mode = STEDMA40_MODE_LOGICAL,
 	.dir = STEDMA40_PERIPH_TO_MEM,
 	.dev_type = DB8500_DMA_DEV11_UART2,
-	.src_info.data_width = STEDMA40_BYTE_WIDTH,
-	.dst_info.data_width = STEDMA40_BYTE_WIDTH,
 };
 
 static struct stedma40_chan_cfg uart2_dma_cfg_tx = {
 	.mode = STEDMA40_MODE_LOGICAL,
 	.dir = STEDMA40_MEM_TO_PERIPH,
 	.dev_type = DB8500_DMA_DEV11_UART2,
-	.src_info.data_width = STEDMA40_BYTE_WIDTH,
-	.dst_info.data_width = STEDMA40_BYTE_WIDTH,
 };
 #endif
 
-- 
1.7.10.4



From lee.jones at linaro.org  Thu Apr 18 06:11:54 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Thu, 18 Apr 2013 11:11:54 +0100
Subject: [PATCH 12/32] ARM: ux500: Remove superfluous 'psize' attribute from
 Audio platform data
In-Reply-To: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1366279934-30761-13-git-send-email-lee.jones@linaro.org>

'psize' is used to calculate the maximum DMA burst size. However it
is only taken into consideration when editing the DMA channel's
configuration. The Audio DMA platform data is only used to allocate
a channel, not configure it. That will be done at a later date within
the MSP driver.

We're also removing comments which are no longer required, as
'data_width' is no longer set in any device's platform data period.

Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/mach-ux500/board-mop500-audio.c |   38 ------------------------------
 1 file changed, 38 deletions(-)

diff --git a/arch/arm/mach-ux500/board-mop500-audio.c b/arch/arm/mach-ux500/board-mop500-audio.c
index f012cfa..972bec0 100644
--- a/arch/arm/mach-ux500/board-mop500-audio.c
+++ b/arch/arm/mach-ux500/board-mop500-audio.c
@@ -23,25 +23,13 @@
 static struct stedma40_chan_cfg msp0_dma_rx = {
 	.high_priority = true,
 	.dir = STEDMA40_PERIPH_TO_MEM,
-
 	.dev_type = DB8500_DMA_DEV31_MSP0_SLIM0_CH0,
-
-	.src_info.psize = STEDMA40_PSIZE_LOG_4,
-	.dst_info.psize = STEDMA40_PSIZE_LOG_4,
-
-	/* data_width is set during configuration */
 };
 
 static struct stedma40_chan_cfg msp0_dma_tx = {
 	.high_priority = true,
 	.dir = STEDMA40_MEM_TO_PERIPH,
-
 	.dev_type = DB8500_DMA_DEV31_MSP0_SLIM0_CH0,
-
-	.src_info.psize = STEDMA40_PSIZE_LOG_4,
-	.dst_info.psize = STEDMA40_PSIZE_LOG_4,
-
-	/* data_width is set during configuration */
 };
 
 struct msp_i2s_platform_data msp0_platform_data = {
@@ -53,25 +41,13 @@ struct msp_i2s_platform_data msp0_platform_data = {
 static struct stedma40_chan_cfg msp1_dma_rx = {
 	.high_priority = true,
 	.dir = STEDMA40_PERIPH_TO_MEM,
-
 	.dev_type = DB8500_DMA_DEV30_MSP3,
-
-	.src_info.psize = STEDMA40_PSIZE_LOG_4,
-	.dst_info.psize = STEDMA40_PSIZE_LOG_4,
-
-	/* data_width is set during configuration */
 };
 
 static struct stedma40_chan_cfg msp1_dma_tx = {
 	.high_priority = true,
 	.dir = STEDMA40_MEM_TO_PERIPH,
-
 	.dev_type = DB8500_DMA_DEV30_MSP1,
-
-	.src_info.psize = STEDMA40_PSIZE_LOG_4,
-	.dst_info.psize = STEDMA40_PSIZE_LOG_4,
-
-	/* data_width is set during configuration */
 };
 
 struct msp_i2s_platform_data msp1_platform_data = {
@@ -83,29 +59,15 @@ struct msp_i2s_platform_data msp1_platform_data = {
 static struct stedma40_chan_cfg msp2_dma_rx = {
 	.high_priority = true,
 	.dir = STEDMA40_PERIPH_TO_MEM,
-
 	.dev_type = DB8500_DMA_DEV14_MSP2,
-
-	/* MSP2 DMA doesn't work with PSIZE == 4 on DB8500v2 */
-	.src_info.psize = STEDMA40_PSIZE_LOG_1,
-	.dst_info.psize = STEDMA40_PSIZE_LOG_1,
-
-	/* data_width is set during configuration */
 };
 
 static struct stedma40_chan_cfg msp2_dma_tx = {
 	.high_priority = true,
 	.dir = STEDMA40_MEM_TO_PERIPH,
-
 	.dev_type = DB8500_DMA_DEV14_MSP2,
-
-	.src_info.psize = STEDMA40_PSIZE_LOG_4,
-	.dst_info.psize = STEDMA40_PSIZE_LOG_4,
-
 	.use_fixed_channel = true,
 	.phy_channel = 1,
-
-	/* data_width is set during configuration */
 };
 
 static struct platform_device *db8500_add_msp_i2s(struct device *parent,
-- 
1.7.10.4



From lee.jones at linaro.org  Thu Apr 18 06:12:05 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Thu, 18 Apr 2013 11:12:05 +0100
Subject: [PATCH 23/32] dmaengine: ste_dma40: Allow driver to be probe()able
 when DT is enabled
In-Reply-To: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1366279934-30761-24-git-send-email-lee.jones@linaro.org>

When booting using Device Tree, devices aren't registered in the normal
way. Instead, they need to be provided with a compatible string which is
held in an OF Match Table for comparison during start-up. Here we provide
the compatible string and prepare the driver to not receive a platform
data pointer.

Cc: Vinod Koul <vinod.koul at intel.com>
Cc: Dan Williams <djbw at fb.com>
Cc: Per Forlin <per.forlin at stericsson.com>
Cc: Rabin Vincent <rabin at rab.in>
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 drivers/dma/ste_dma40.c |   42 ++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 40 insertions(+), 2 deletions(-)

diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index 6f9f801..4782ee7 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -17,6 +17,7 @@
 #include <linux/pm.h>
 #include <linux/pm_runtime.h>
 #include <linux/err.h>
+#include <linux/of.h>
 #include <linux/amba/bus.h>
 #include <linux/regulator/consumer.h>
 #include <linux/platform_data/dma-ste-dma40.h>
@@ -3452,17 +3453,48 @@ failure:
 	return ret;
 }
 
+static int __init d40_of_probe(struct platform_device *pdev,
+			       struct device_node *np)
+{
+	/*
+	 * FIXME: Fill in this routine as more support is added.
+	 * First platform enabled (u8500) doens't need any extra
+	 * properties to run, so this is fairly sparce currently.
+	 */
+	pdev->dev.platform_data =
+		devm_kzalloc(&pdev->dev,
+			     sizeof(struct stedma40_platform_data),
+			     GFP_KERNEL);
+	if (!pdev->dev.platform_data)
+		return -ENOMEM;
+
+	return 0;
+}
+
 static int __init d40_probe(struct platform_device *pdev)
 {
+	struct stedma40_platform_data *plat_data = pdev->dev.platform_data;
+	struct device_node *np = pdev->dev.of_node;
 	int err;
 	int ret = -ENOENT;
-	struct d40_base *base;
+	struct d40_base *base = NULL;
 	struct resource *res = NULL;
 	int num_reserved_chans;
 	u32 val;
 
-	base = d40_hw_detect_init(pdev);
+	if (!plat_data) {
+		if (np) {
+			if(d40_of_probe(pdev, np)) {
+				ret = -ENOMEM;
+				goto failure;
+			}
+		} else {
+			d40_err(&pdev->dev, "No pdata or Device Tree provided\n");
+			goto failure;
+		}
+	}
 
+	base = d40_hw_detect_init(pdev);
 	if (!base)
 		goto failure;
 
@@ -3636,11 +3668,17 @@ failure:
 	return ret;
 }
 
+static const struct of_device_id d40_match[] = {
+        { .compatible = "stericsson,dma40", },
+        {}
+};
+
 static struct platform_driver d40_driver = {
 	.driver = {
 		.owner = THIS_MODULE,
 		.name  = D40_NAME,
 		.pm = DMA40_PM_OPS,
+		.of_match_table = d40_match,
 	},
 };
 
-- 
1.7.10.4



From lee.jones at linaro.org  Thu Apr 18 06:12:03 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Thu, 18 Apr 2013 11:12:03 +0100
Subject: [PATCH 21/32] dmaengine: ste_dma40: Also report the number of logical
 channels
In-Reply-To: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1366279934-30761-22-git-send-email-lee.jones@linaro.org>

Now we know the total of physical and logical channels, we may as
well report them within the information log.

Before:
dma40 dma40.0: hardware revision: 3 @ 0x801c0000 with 8 physical channels

After:
<as above ...> and 256 logical channels

Cc: Vinod Koul <vinod.koul at intel.com>
Cc: Dan Williams <djbw at fb.com>
Cc: Per Forlin <per.forlin at stericsson.com>
Cc: Rabin Vincent <rabin at rab.in>
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 drivers/dma/ste_dma40.c |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index 282dd59..805049c 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -3200,8 +3200,9 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
 
 	num_log_chans = num_phy_chans * D40_MAX_LOG_CHAN_PER_PHY;
 
-	dev_info(&pdev->dev, "hardware revision: %d @ 0x%x with %d physical channels\n",
-		 rev, res->start, num_phy_chans);
+	dev_info(&pdev->dev, "hardware revision: %d @ 0x%x with "
+		"%d physical channels and %d logical channels\n",
+		rev, res->start, num_phy_chans, num_log_chans);
 
 	base = kzalloc(ALIGN(sizeof(struct d40_base), 4) +
 		       (num_phy_chans + num_log_chans + ARRAY_SIZE(dma40_memcpy_channels)) *
-- 
1.7.10.4



From lee.jones at linaro.org  Thu Apr 18 06:12:07 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Thu, 18 Apr 2013 11:12:07 +0100
Subject: [PATCH 25/32] ARM: ux500: Setup the DMA40 driver's DT node using the
 new DMA API
In-Reply-To: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1366279934-30761-26-git-send-email-lee.jones@linaro.org>

The new DMA is now available, so let's use it to setup ST-Ericsson's
DMA40 driver when Device Tree is enabled.

Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/boot/dts/dbx5x0.dtsi |    8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/dbx5x0.dtsi b/arch/arm/boot/dts/dbx5x0.dtsi
index 0f462b7..e2fa20f 100644
--- a/arch/arm/boot/dts/dbx5x0.dtsi
+++ b/arch/arm/boot/dts/dbx5x0.dtsi
@@ -182,12 +182,14 @@
 			interrupts = <0 23 0x4>;
 		};
 
-		dma-controller at 801C0000 {
-			compatible = "stericsson,db8500-dma40",
-					"stericsson,dma40";
+		dma: dma-controller at 801C0000 {
+			compatible = "stericsson,db8500-dma40", "stericsson,dma40";
 			reg = <0x801C0000 0x1000 0x40010000 0x800>;
 			reg-names = "base", "lcpa";
 			interrupts = <0 25 0x4>;
+
+			#dma-cells = <3>;
+			dma-channels = <0>; /* Zero means read from H/W. */
 		};
 
 		prcmu: prcmu at 80157000 {
-- 
1.7.10.4



From lee.jones at linaro.org  Thu Apr 18 06:12:10 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Thu, 18 Apr 2013 11:12:10 +0100
Subject: [PATCH 28/32] ARM: ux500: Pass remnant platform data though to DMA40
 driver
In-Reply-To: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1366279934-30761-29-git-send-email-lee.jones@linaro.org>

Ironically, in order to remove lots of the auxdata assignments, we have
to add just one more. A lot of them require DMA information to be passed
into clients for DMA channel allocation, but we now have this capability
in Device Tree. However, the DMA40 driver still relies on a reverse table
look-up to obtain DMA addresses. Until all of the clients are converted,
over to the new API, we're stuck with this.

Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/mach-ux500/board-mop500.h   |    1 +
 arch/arm/mach-ux500/cpu-db8500.c     |    3 +++
 arch/arm/mach-ux500/devices-db8500.c |    2 +-
 3 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-ux500/board-mop500.h b/arch/arm/mach-ux500/board-mop500.h
index d38951b..2c5139d 100644
--- a/arch/arm/mach-ux500/board-mop500.h
+++ b/arch/arm/mach-ux500/board-mop500.h
@@ -93,6 +93,7 @@ extern struct amba_pl011_data uart0_plat;
 extern struct amba_pl011_data uart1_plat;
 extern struct amba_pl011_data uart2_plat;
 extern struct pl022_ssp_controller ssp0_plat;
+extern struct stedma40_platform_data dma40_plat_data;
 
 extern void mop500_sdi_init(struct device *parent);
 extern void snowball_sdi_init(struct device *parent);
diff --git a/arch/arm/mach-ux500/cpu-db8500.c b/arch/arm/mach-ux500/cpu-db8500.c
index eae3e3a..b216233 100644
--- a/arch/arm/mach-ux500/cpu-db8500.c
+++ b/arch/arm/mach-ux500/cpu-db8500.c
@@ -273,6 +273,9 @@ static struct of_dev_auxdata u8500_auxdata_lookup[] __initdata = {
 		"ux500-msp-i2s.2", &msp2_platform_data),
 	OF_DEV_AUXDATA("stericsson,ux500-msp-i2s", 0x80125000,
 		"ux500-msp-i2s.3", &msp3_platform_data),
+	/* Requires clock name bindings and channel address lookup table. */
+	OF_DEV_AUXDATA("stericsson,db8500-dma40", 0x801C0000,
+		       "dma40.0", &dma40_plat_data),
 	{},
 };
 
diff --git a/arch/arm/mach-ux500/devices-db8500.c b/arch/arm/mach-ux500/devices-db8500.c
index 2fcb8c2..3e4993e 100644
--- a/arch/arm/mach-ux500/devices-db8500.c
+++ b/arch/arm/mach-ux500/devices-db8500.c
@@ -120,7 +120,7 @@ static const dma_addr_t dma40_rx_map[DB8500_DMA_NR_DEV] = {
 	[DB8500_DMA_DEV48_CAC1] = U8500_CRYP1_BASE + CRYP1_RX_REG_OFFSET,
 };
 
-static struct stedma40_platform_data dma40_plat_data = {
+struct stedma40_platform_data dma40_plat_data = {
 	.dev_rx = dma40_rx_map,
 	.dev_tx = dma40_tx_map,
 	.disabled_channels = {-1},
-- 
1.7.10.4



From lee.jones at linaro.org  Thu Apr 18 06:12:11 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Thu, 18 Apr 2013 11:12:11 +0100
Subject: [PATCH 29/32] ARM: ux500: Stop passing UART's platform data for
 Device Tree boots
In-Reply-To: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1366279934-30761-30-git-send-email-lee.jones@linaro.org>

It was required to pass DMA channel configuration information to the
UART driver before the new DMA API was in place. Now that it is, and
is fully compatible with Device Tree we can stop doing that.

Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/mach-ux500/cpu-db8500.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-ux500/cpu-db8500.c b/arch/arm/mach-ux500/cpu-db8500.c
index b216233..27d75c8 100644
--- a/arch/arm/mach-ux500/cpu-db8500.c
+++ b/arch/arm/mach-ux500/cpu-db8500.c
@@ -236,9 +236,9 @@ static struct of_dev_auxdata u8500_auxdata_lookup[] __initdata = {
 	/* Requires call-back bindings. */
 	OF_DEV_AUXDATA("arm,cortex-a9-pmu", 0, "arm-pmu", &db8500_pmu_platdata),
 	/* Requires DMA bindings. */
-	OF_DEV_AUXDATA("arm,pl011", 0x80120000, "uart0", &uart0_plat),
-	OF_DEV_AUXDATA("arm,pl011", 0x80121000, "uart1", &uart1_plat),
-	OF_DEV_AUXDATA("arm,pl011", 0x80007000, "uart2", &uart2_plat),
+	OF_DEV_AUXDATA("arm,pl011", 0x80120000, "uart0", NULL),
+	OF_DEV_AUXDATA("arm,pl011", 0x80121000, "uart1", NULL),
+	OF_DEV_AUXDATA("arm,pl011", 0x80007000, "uart2", NULL),
 	OF_DEV_AUXDATA("arm,pl022", 0x80002000, "ssp0",  &ssp0_plat),
 	OF_DEV_AUXDATA("arm,pl18x", 0x80126000, "sdi0",  &mop500_sdi0_data),
 	OF_DEV_AUXDATA("arm,pl18x", 0x80118000, "sdi1",  &mop500_sdi1_data),
-- 
1.7.10.4



From lee.jones at linaro.org  Thu Apr 18 06:12:12 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Thu, 18 Apr 2013 11:12:12 +0100
Subject: [PATCH 30/32] ARM: ux500: Supply MMC DMA configuration via Device Tree
In-Reply-To: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1366279934-30761-31-git-send-email-lee.jones@linaro.org>

When requesting a channel, a DMA client needs to pass some pieces of
information such as; request channel, device type, channel type and
direction etc. Normally we do this in the form of platform data, but
when DT is enabled we need to pass it using the driver's bindings
instead.

Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/boot/dts/dbx5x0.dtsi |   20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/arch/arm/boot/dts/dbx5x0.dtsi b/arch/arm/boot/dts/dbx5x0.dtsi
index bd0fe5f..c064a9a 100644
--- a/arch/arm/boot/dts/dbx5x0.dtsi
+++ b/arch/arm/boot/dts/dbx5x0.dtsi
@@ -605,6 +605,11 @@
 			compatible = "arm,pl18x", "arm,primecell";
 			reg = <0x80126000 0x1000>;
 			interrupts = <0 60 0x4>;
+
+			dmas = <&dma 0 29 0x8>, /* Logical - DevToMem */
+			       <&dma 0 29 0x4>; /* Logical - MemToDev */
+			dma-names = "rx", "tx";
+
 			status = "disabled";
 		};
 
@@ -612,6 +617,11 @@
 			compatible = "arm,pl18x", "arm,primecell";
 			reg = <0x80118000 0x1000>;
 			interrupts = <0 50 0x4>;
+
+			dmas = <&dma 0 32 0x8>, /* Logical - DevToMem */
+			       <&dma 0 32 0x4>; /* Logical - MemToDev */
+			dma-names = "rx", "tx";
+
 			status = "disabled";
 		};
 
@@ -619,6 +629,11 @@
 			compatible = "arm,pl18x", "arm,primecell";
 			reg = <0x80005000 0x1000>;
 			interrupts = <0 41 0x4>;
+
+			dmas = <&dma 0 28 0x8>, /* Logical - DevToMem */
+			       <&dma 0 28 0x4>; /* Logical - MemToDev */
+			dma-names = "rx", "tx";
+
 			status = "disabled";
 		};
 
@@ -633,6 +648,11 @@
 			compatible = "arm,pl18x", "arm,primecell";
 			reg = <0x80114000 0x1000>;
 			interrupts = <0 99 0x4>;
+
+			dmas = <&dma 0 42 0x8>, /* Logical - DevToMem */
+			       <&dma 0 42 0x4>; /* Logical - MemToDev */
+			dma-names = "rx", "tx";
+
 			status = "disabled";
 		};
 
-- 
1.7.10.4



From lee.jones at linaro.org  Thu Apr 18 06:12:13 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Thu, 18 Apr 2013 11:12:13 +0100
Subject: [PATCH 31/32] ARM: ux500: Stop passing MMC's platform data for Device
 Tree boots
In-Reply-To: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1366279934-30761-32-git-send-email-lee.jones@linaro.org>

It was required to pass DMA channel configuration information to the
MMC driver before the new DMA API was in place. Now that it is, and
is fully compatible with Device Tree we can stop doing that.

Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/mach-ux500/cpu-db8500.c |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-ux500/cpu-db8500.c b/arch/arm/mach-ux500/cpu-db8500.c
index 27d75c8..501281c 100644
--- a/arch/arm/mach-ux500/cpu-db8500.c
+++ b/arch/arm/mach-ux500/cpu-db8500.c
@@ -240,10 +240,10 @@ static struct of_dev_auxdata u8500_auxdata_lookup[] __initdata = {
 	OF_DEV_AUXDATA("arm,pl011", 0x80121000, "uart1", NULL),
 	OF_DEV_AUXDATA("arm,pl011", 0x80007000, "uart2", NULL),
 	OF_DEV_AUXDATA("arm,pl022", 0x80002000, "ssp0",  &ssp0_plat),
-	OF_DEV_AUXDATA("arm,pl18x", 0x80126000, "sdi0",  &mop500_sdi0_data),
-	OF_DEV_AUXDATA("arm,pl18x", 0x80118000, "sdi1",  &mop500_sdi1_data),
-	OF_DEV_AUXDATA("arm,pl18x", 0x80005000, "sdi2",  &mop500_sdi2_data),
-	OF_DEV_AUXDATA("arm,pl18x", 0x80114000, "sdi4",  &mop500_sdi4_data),
+	OF_DEV_AUXDATA("arm,pl18x", 0x80126000, "sdi0",  NULL),
+	OF_DEV_AUXDATA("arm,pl18x", 0x80118000, "sdi1",  NULL),
+	OF_DEV_AUXDATA("arm,pl18x", 0x80005000, "sdi2",  NULL),
+	OF_DEV_AUXDATA("arm,pl18x", 0x80114000, "sdi4",  NULL),
 	/* Requires clock name bindings. */
 	OF_DEV_AUXDATA("st,nomadik-gpio", 0x8012e000, "gpio.0", NULL),
 	OF_DEV_AUXDATA("st,nomadik-gpio", 0x8012e080, "gpio.1", NULL),
-- 
1.7.10.4



From lee.jones at linaro.org  Thu Apr 18 06:12:14 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Thu, 18 Apr 2013 11:12:14 +0100
Subject: [PATCH 32/32] ARM: ux500: Move SDI (MMC) and UART devices under more
 descriptive heading
In-Reply-To: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1366279934-30761-33-git-send-email-lee.jones@linaro.org>

Now DMA DT bindings exist and are in use by he MMC and UART drivers, it
should be possible to remove them from the auxdata structure. However,
after doing so the drivers fail. Something must be reliant on the dev
name applied by using auxdata; probably common clk.

Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/mach-ux500/cpu-db8500.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-ux500/cpu-db8500.c b/arch/arm/mach-ux500/cpu-db8500.c
index 501281c..f56e2da0 100644
--- a/arch/arm/mach-ux500/cpu-db8500.c
+++ b/arch/arm/mach-ux500/cpu-db8500.c
@@ -236,15 +236,15 @@ static struct of_dev_auxdata u8500_auxdata_lookup[] __initdata = {
 	/* Requires call-back bindings. */
 	OF_DEV_AUXDATA("arm,cortex-a9-pmu", 0, "arm-pmu", &db8500_pmu_platdata),
 	/* Requires DMA bindings. */
+	OF_DEV_AUXDATA("arm,pl022", 0x80002000, "ssp0",  &ssp0_plat),
+	/* Requires clock name bindings. */
 	OF_DEV_AUXDATA("arm,pl011", 0x80120000, "uart0", NULL),
 	OF_DEV_AUXDATA("arm,pl011", 0x80121000, "uart1", NULL),
 	OF_DEV_AUXDATA("arm,pl011", 0x80007000, "uart2", NULL),
-	OF_DEV_AUXDATA("arm,pl022", 0x80002000, "ssp0",  &ssp0_plat),
 	OF_DEV_AUXDATA("arm,pl18x", 0x80126000, "sdi0",  NULL),
 	OF_DEV_AUXDATA("arm,pl18x", 0x80118000, "sdi1",  NULL),
 	OF_DEV_AUXDATA("arm,pl18x", 0x80005000, "sdi2",  NULL),
 	OF_DEV_AUXDATA("arm,pl18x", 0x80114000, "sdi4",  NULL),
-	/* Requires clock name bindings. */
 	OF_DEV_AUXDATA("st,nomadik-gpio", 0x8012e000, "gpio.0", NULL),
 	OF_DEV_AUXDATA("st,nomadik-gpio", 0x8012e080, "gpio.1", NULL),
 	OF_DEV_AUXDATA("st,nomadik-gpio", 0x8000e000, "gpio.2", NULL),
-- 
1.7.10.4



From lee.jones at linaro.org  Thu Apr 18 06:12:06 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Thu, 18 Apr 2013 11:12:06 +0100
Subject: [PATCH 24/32] dmaengine: ste_dma40: Supply full Device Tree parsing
 support
In-Reply-To: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1366279934-30761-25-git-send-email-lee.jones@linaro.org>

Using the new DMA DT bindings and API, we can register the DMA40 driver
as Device Tree capable. Now, when a client attempts to allocate a
channel using the DMA DT bindings via its own node, we are able to parse
the request and allocate a channel in the correct manor.

Cc: Vinod Koul <vinod.koul at intel.com>
Cc: Dan Williams <djbw at fb.com>
Cc: Per Forlin <per.forlin at stericsson.com>
Cc: Rabin Vincent <rabin at rab.in>
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 .../devicetree/bindings/dma/ste-dma40.txt          |   66 ++++++++++++++++++++
 drivers/dma/ste_dma40.c                            |   58 +++++++++++++++++
 2 files changed, 124 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/dma/ste-dma40.txt

diff --git a/Documentation/devicetree/bindings/dma/ste-dma40.txt b/Documentation/devicetree/bindings/dma/ste-dma40.txt
new file mode 100644
index 0000000..1eb7958
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/ste-dma40.txt
@@ -0,0 +1,66 @@
+* DMA40 DMA Controller
+
+Required properties:
+- compatible: "stericsson,dma40"
+- reg: Address range of the DMAC registers
+- interrupt: Should contain the DMAC interrupt number
+- dma-channels: Number of channels supported by hardware
+- #dma-cells: must be <3>
+
+Optional properties:
+- interrupt-parent: Should be the phandle for the interrupt controller
+  that services interrupts for this device
+
+Example:
+
+	dma: dma-controller at 801C0000 {
+		compatible = "stericsson,db8500-dma40", "stericsson,dma40";
+		reg = <0x801C0000 0x1000>;
+		reg-names = "base";
+		interrupt-parent = <&intc>;
+		interrupts = <0 25 0x4>;
+
+		#dma-cells = <2>;
+		dma-channels = <0>; /* Zero means read from H/W. */
+	};
+
+Clients
+Required properties:
+- dmas: Comma seperated list of dma channel requests
+- dma-names: Names of the aforementioned requested channels
+
+Each dmas request consists of 4 cells:
+  1. A phandle pointing to the DMA controller
+  2. The DMA request line number (only when 'use fixed channel' is set)
+  3. Device Type
+  4. A 32bit mask specifying; mode, direction and endianess [NB: This list will grow]
+        bits 1-2: Mode:
+          00: Logical
+          01: Physical
+          10: Operation
+          11: Undefined - will most likely return an error
+        bits 3-4: Direction:
+          00: Mem to Mem
+          01: Mem to Dev
+          10: Dev to Mem
+          11: Dev to Dev
+        bit 5: Endianess:
+           0: Little endian
+           1: Big endian
+        bit 6: Use fixed channel:
+           0: Use automatic channel selection
+           1: Use DMA request line number
+
+Example:
+
+	uart at 80120000 {
+		compatible = "arm,pl011", "arm,primecell";
+		reg = <0x80120000 0x1000>;
+		interrupts = <0 11 0x4>;
+
+		dmas = <&dma 0 13 0x8>, /* Logical - DevToMem */
+		       <&dma 0 13 0x4>; /* Logical - MemToDev */
+		dma-names = "rx", "rx";
+
+		status = "disabled";
+	};
diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index 4782ee7..9115c0e 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -18,6 +18,7 @@
 #include <linux/pm_runtime.h>
 #include <linux/err.h>
 #include <linux/of.h>
+#include <linux/of_dma.h>
 #include <linux/amba/bus.h>
 #include <linux/regulator/consumer.h>
 #include <linux/platform_data/dma-ste-dma40.h>
@@ -2409,6 +2410,56 @@ static void d40_set_prio_realtime(struct d40_chan *d40c)
 		__d40_set_prio_rt(d40c, d40c->dma_cfg.dev_type, false);
 }
 
+#define D40_DT_FLAGS_MODE(flags)       ((flags >> 0) & 0x3)
+#define D40_DT_FLAGS_DIR(flags)        ((flags >> 2) & 0x3)
+#define D40_DT_FLAGS_BIG_ENDIAN(flags) ((flags >> 4) & 0x1)
+#define D40_DT_FLAGS_FIXED_CHAN(flags) ((flags >> 5) & 0x1)
+
+static struct dma_chan *d40_xlate(struct of_phandle_args *dma_spec,
+				  struct of_dma *ofdma)
+{
+	struct stedma40_chan_cfg cfg;
+	dma_cap_mask_t cap;
+	u32 flags;
+
+	memset(&cfg, 0, sizeof(struct stedma40_chan_cfg));
+
+	dma_cap_zero(cap);
+	dma_cap_set(DMA_SLAVE, cap);
+
+	cfg.dev_type = dma_spec->args[1];
+	flags = dma_spec->args[2];
+
+	switch (D40_DT_FLAGS_MODE(flags)) {
+	case 0: cfg.mode = STEDMA40_MODE_LOGICAL; break;
+	case 1: cfg.mode = STEDMA40_MODE_PHYSICAL; break;
+	case 2: cfg.mode = STEDMA40_MODE_OPERATION; break;
+	default:
+		pr_err("dma40: Unknown mode read from DT (%d)\n",
+		       D40_DT_FLAGS_MODE(flags));
+		return NULL;
+	}
+
+	switch (D40_DT_FLAGS_DIR(flags)) {
+	case 0: cfg.dir = STEDMA40_MEM_TO_MEM; break;
+	case 1: cfg.dir = STEDMA40_MEM_TO_PERIPH; break;
+	case 2: cfg.dir = STEDMA40_PERIPH_TO_MEM; break;
+	case 3: cfg.dir = STEDMA40_PERIPH_TO_PERIPH; break;
+	}
+
+	if (cfg.dir == STEDMA40_PERIPH_TO_MEM)
+		cfg.src_info.big_endian = D40_DT_FLAGS_BIG_ENDIAN(flags);
+	if (cfg.dir == STEDMA40_MEM_TO_PERIPH)
+		cfg.dst_info.big_endian = D40_DT_FLAGS_BIG_ENDIAN(flags);
+
+	if (D40_DT_FLAGS_FIXED_CHAN(flags)) {
+		cfg.phy_channel = dma_spec->args[0];
+		cfg.use_fixed_channel = true;
+	}
+
+	return dma_request_channel(cap, stedma40_filter, &cfg);
+}
+
 /* DMA ENGINE functions */
 static int d40_alloc_chan_resources(struct dma_chan *chan)
 {
@@ -3615,6 +3666,13 @@ static int __init d40_probe(struct platform_device *pdev)
 
 	d40_hw_init(base);
 
+	if (np) {
+		err = of_dma_controller_register(np, d40_xlate, NULL);
+		if (err && err != -ENODEV)
+			dev_err(&pdev->dev,
+				"could not register of_dma_controller\n");
+	}
+
 	dev_info(base->dev, "initialized\n");
 	return 0;
 
-- 
1.7.10.4



From lee.jones at linaro.org  Thu Apr 18 06:12:04 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Thu, 18 Apr 2013 11:12:04 +0100
Subject: [PATCH 22/32] dmaengine: ste_dma40: Allocate plat_data on declaration
In-Reply-To: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1366279934-30761-23-git-send-email-lee.jones@linaro.org>

It's the way that most other drivers do it.

Very trivial clean-up which reduces line count and simplifies code.

Cc: Vinod Koul <vinod.koul at intel.com>
Cc: Dan Williams <djbw at fb.com>
Cc: Per Forlin <per.forlin at stericsson.com>
Cc: Rabin Vincent <rabin at rab.in>
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 drivers/dma/ste_dma40.c |    4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index 805049c..6f9f801 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -3119,7 +3119,7 @@ static int __init d40_phy_res_init(struct d40_base *base)
 
 static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
 {
-	struct stedma40_platform_data *plat_data;
+	struct stedma40_platform_data *plat_data = pdev->dev.platform_data;
 	struct clk *clk = NULL;
 	void __iomem *virtbase = NULL;
 	struct resource *res = NULL;
@@ -3190,8 +3190,6 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
 		goto failure;
 	}
 
-	plat_data = pdev->dev.platform_data;
-
 	/* The number of physical channels on this HW */
 	if (plat_data->num_of_phy_chans)
 		num_phy_chans = plat_data->num_of_phy_chans;
-- 
1.7.10.4



From nicolas.ferre at atmel.com  Thu Apr 18 06:13:06 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Thu, 18 Apr 2013 12:13:06 +0200
Subject: [PATCH v3] ARM: at91: add Acme Systems Aria G25 board
In-Reply-To: <516FB671.2030706@atmel.com>
References: <20130402184947.GA8015@quad.lixom.net>
 <1365090153-1807-1-git-send-email-nicolas.ferre@atmel.com>
 <515DB248.6070105@interlog.com> <516FB671.2030706@atmel.com>
Message-ID: <516FC732.9080109@atmel.com>

On 04/18/2013 11:01 AM, Nicolas Ferre :
> On 04/04/2013 07:03 PM, Douglas Gilbert :

[..]

>> The lack of use of uart1 is for my own, private reasons.
>> I think it would be more generally useful to show uart1's
>> definition and disable it as shown in the attached patch
>> fragment.
> 
> Well, if uart1 is available on Aria board, I should enable it! If you do
> not want it on your own design, you must modify the .dts yourself. So I
> plan to have an "okay" status on it (and move the definition itself to
> the generic .dtsi).

Update: I have just checked the ACME website and both UART0 and UART1
pins are expected to be used as GPIOs. So maybe we should mark them as
"disabled":

+                       /*
+                        * UART1 pins are marked as GPIO on Aria
+                        * documentation: change to "okay" if you need
+                        * an additional serial port
+                        */
+                       uart0: serial at f8040000 {
+                               status = "disabled";
+                       };
+
+                       uart1: serial at f8044000 {
+                               status = "disabled";
+                       };

(uart0 definition moved to at91sam9x5.dtsi)
What do you think?

[..]

Bye,
-- 
Nicolas Ferre


From lee.jones at linaro.org  Thu Apr 18 06:12:09 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Thu, 18 Apr 2013 11:12:09 +0100
Subject: [PATCH 27/32] ARM: ux500: Stop registering DMA40 from platform data
 when DT is enabled
In-Reply-To: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1366279934-30761-28-git-send-email-lee.jones@linaro.org>

Now the DMA40 has been DT:ed, there's no requirement to register it
using traditional methods. This is the penultimate device to be DT:ed.

Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/mach-ux500/cpu-db8500.c |   10 ----------
 1 file changed, 10 deletions(-)

diff --git a/arch/arm/mach-ux500/cpu-db8500.c b/arch/arm/mach-ux500/cpu-db8500.c
index a15678d..eae3e3a 100644
--- a/arch/arm/mach-ux500/cpu-db8500.c
+++ b/arch/arm/mach-ux500/cpu-db8500.c
@@ -229,16 +229,6 @@ static struct device * __init u8500_of_init_devices(void)
 
 	db8500_add_usb(parent, usb_db8500_dma_cfg, usb_db8500_dma_cfg);
 
-	u8500_dma40_device.dev.parent = parent;
-
-	/*
-	 * Devices to be DT:ed:
-	 *   u8500_dma40_device  = todo
-	 *   db8500_pmu_device   = done
-	 *   db8500_prcmu_device = done
-	 */
-	platform_device_register(&u8500_dma40_device);
-
 	return parent;
 }
 
-- 
1.7.10.4



From lee.jones at linaro.org  Thu Apr 18 06:26:56 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Thu, 18 Apr 2013 11:26:56 +0100
Subject: [PATCH 0/9] Fix ux500 crypto drivers and init DMA in the correct way 
Message-ID: <1366280825-31136-1-git-send-email-lee.jones@linaro.org>

These drivers haven't been touched in a while. They didn't even compile
or probe successfully. After these changes, both drivers run just fine.

We also split DMA channel allocation and configuration into separate
invocations, as the API expects.

 arch/arm/mach-ux500/board-mop500.c    |   14 ++------------
 drivers/crypto/ux500/cryp/cryp.h      |    7 ++++++-
 drivers/crypto/ux500/cryp/cryp_core.c |   27 +++++++++++++++++++++++----
 drivers/crypto/ux500/hash/hash_alg.h  |    5 ++++-
 drivers/crypto/ux500/hash/hash_core.c |   20 +++++++++++++++-----
 5 files changed, 50 insertions(+), 23 deletions(-)



From lee.jones at linaro.org  Thu Apr 18 06:26:57 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Thu, 18 Apr 2013 11:26:57 +0100
Subject: [PATCH 1/9] crypto: ux500/hash - Prepare clock before enabling it
In-Reply-To: <1366280825-31136-1-git-send-email-lee.jones@linaro.org>
References: <1366280825-31136-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1366280825-31136-2-git-send-email-lee.jones@linaro.org>

If we fail to prepare the ux500-hash clock before enabling it the
platform will fail to boot. Here we insure this happens.

Cc: Herbert Xu <herbert at gondor.apana.org.au>
Cc: David S. Miller <davem at davemloft.net>
Cc: Andreas Westin <andreas.westin at stericsson.com>
Cc: linux-crypto at vger.kernel.org
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 drivers/crypto/ux500/hash/hash_core.c |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/crypto/ux500/hash/hash_core.c b/drivers/crypto/ux500/hash/hash_core.c
index 632c333..118386a 100644
--- a/drivers/crypto/ux500/hash/hash_core.c
+++ b/drivers/crypto/ux500/hash/hash_core.c
@@ -308,10 +308,10 @@ static int hash_disable_power(
 		device_data->restore_dev_state = true;
 	}
 
-	clk_disable(device_data->clk);
+	clk_disable_unprepare(device_data->clk);
 	ret = regulator_disable(device_data->regulator);
 	if (ret)
-		dev_err(dev, "[%s] regulator_disable() failed!", __func__);
+		dev_err(dev, "[%s] regulator_disable_unprepare() failed!", __func__);
 
 	device_data->power_state = false;
 
@@ -344,9 +344,9 @@ static int hash_enable_power(
 					__func__);
 			goto out;
 		}
-		ret = clk_enable(device_data->clk);
+		ret = clk_prepare_enable(device_data->clk);
 		if (ret) {
-			dev_err(dev, "[%s]: clk_enable() failed!",
+			dev_err(dev, "[%s]: clk_prepare_enable() failed!",
 					__func__);
 			ret = regulator_disable(
 					device_data->regulator);
-- 
1.7.10.4



From lee.jones at linaro.org  Thu Apr 18 06:26:59 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Thu, 18 Apr 2013 11:26:59 +0100
Subject: [PATCH 3/9] ARM: ux500: Stop passing Hash DMA channel config
 information though pdata
In-Reply-To: <1366280825-31136-1-git-send-email-lee.jones@linaro.org>
References: <1366280825-31136-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1366280825-31136-4-git-send-email-lee.jones@linaro.org>

DMA channel configuration information should be setup in the driver.
The Ux500 Hash driver now does this, so there's no need to send it
though here too.

Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/mach-ux500/board-mop500.c |    4 ----
 1 file changed, 4 deletions(-)

diff --git a/arch/arm/mach-ux500/board-mop500.c b/arch/arm/mach-ux500/board-mop500.c
index 883dc66..cb7ae23 100644
--- a/arch/arm/mach-ux500/board-mop500.c
+++ b/arch/arm/mach-ux500/board-mop500.c
@@ -473,11 +473,7 @@ static struct cryp_platform_data u8500_cryp1_platform_data = {
 static struct stedma40_chan_cfg u8500_hash_dma_cfg_tx = {
 		.dir = STEDMA40_MEM_TO_PERIPH,
 		.dev_type = DB8500_DMA_DEV50_HAC1_TX,
-		.src_info.data_width = STEDMA40_WORD_WIDTH,
-		.dst_info.data_width = STEDMA40_WORD_WIDTH,
 		.mode = STEDMA40_MODE_LOGICAL,
-		.src_info.psize = STEDMA40_PSIZE_LOG_16,
-		.dst_info.psize = STEDMA40_PSIZE_LOG_16,
 };
 
 static struct hash_platform_data u8500_hash1_platform_data = {
-- 
1.7.10.4



From lee.jones at linaro.org  Thu Apr 18 06:26:58 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Thu, 18 Apr 2013 11:26:58 +0100
Subject: [PATCH 2/9] crypto: ux500/hash - Set DMA configuration though
 dma_slave_config()
In-Reply-To: <1366280825-31136-1-git-send-email-lee.jones@linaro.org>
References: <1366280825-31136-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1366280825-31136-3-git-send-email-lee.jones@linaro.org>

The DMA controller currently takes configuration information from
information passed though dma_channel_request(), but it shouldn't.
Using the API, the DMA channel should only be configured during
a dma_slave_config() call.

Cc: Herbert Xu <herbert at gondor.apana.org.au>
Cc: David S. Miller <davem at davemloft.net>
Cc: Andreas Westin <andreas.westin at stericsson.com>
Cc: linux-crypto at vger.kernel.org
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 drivers/crypto/ux500/hash/hash_alg.h  |    5 ++++-
 drivers/crypto/ux500/hash/hash_core.c |   10 ++++++++++
 2 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/drivers/crypto/ux500/hash/hash_alg.h b/drivers/crypto/ux500/hash/hash_alg.h
index cd9351c..be6eb54 100644
--- a/drivers/crypto/ux500/hash/hash_alg.h
+++ b/drivers/crypto/ux500/hash/hash_alg.h
@@ -11,6 +11,7 @@
 #include <linux/bitops.h>
 
 #define HASH_BLOCK_SIZE			64
+#define HASH_DMA_FIFO			4
 #define HASH_DMA_ALIGN_SIZE		4
 #define HASH_DMA_PERFORMANCE_MIN_SIZE	1024
 #define HASH_BYTES_PER_WORD		4
@@ -347,7 +348,8 @@ struct hash_req_ctx {
 
 /**
  * struct hash_device_data - structure for a hash device.
- * @base:		Pointer to the hardware base address.
+ * @base:		Pointer to virtual base address of the hash device.
+ * @phybase:		Pointer to physical memory location of the hash device.
  * @list_node:		For inclusion in klist.
  * @dev:		Pointer to the device dev structure.
  * @ctx_lock:		Spinlock for current_ctx.
@@ -361,6 +363,7 @@ struct hash_req_ctx {
  */
 struct hash_device_data {
 	struct hash_register __iomem	*base;
+	phys_addr_t             phybase;
 	struct klist_node	list_node;
 	struct device		*dev;
 	struct spinlock		ctx_lock;
diff --git a/drivers/crypto/ux500/hash/hash_core.c b/drivers/crypto/ux500/hash/hash_core.c
index 118386a..f9126f4 100644
--- a/drivers/crypto/ux500/hash/hash_core.c
+++ b/drivers/crypto/ux500/hash/hash_core.c
@@ -123,6 +123,13 @@ static void hash_dma_setup_channel(struct hash_device_data *device_data,
 				struct device *dev)
 {
 	struct hash_platform_data *platform_data = dev->platform_data;
+	struct dma_slave_config conf = {
+		.direction = DMA_MEM_TO_DEV,
+		.dst_addr = device_data->phybase + HASH_DMA_FIFO,
+		.dst_addr_width = DMA_SLAVE_BUSWIDTH_2_BYTES,
+		.dst_maxburst = 16,
+        };
+
 	dma_cap_zero(device_data->dma.mask);
 	dma_cap_set(DMA_SLAVE, device_data->dma.mask);
 
@@ -132,6 +139,8 @@ static void hash_dma_setup_channel(struct hash_device_data *device_data,
 				platform_data->dma_filter,
 				device_data->dma.cfg_mem2hash);
 
+	dmaengine_slave_config(device_data->dma.chan_mem2hash, &conf);
+
 	init_completion(&device_data->dma.complete);
 }
 
@@ -1700,6 +1709,7 @@ static int ux500_hash_probe(struct platform_device *pdev)
 		goto out_kfree;
 	}
 
+	device_data->phybase = res->start;
 	device_data->base = ioremap(res->start, resource_size(res));
 	if (!device_data->base) {
 		dev_err(dev, "[%s] ioremap() failed!",
-- 
1.7.10.4



From lee.jones at linaro.org  Thu Apr 18 06:27:00 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Thu, 18 Apr 2013 11:27:00 +0100
Subject: [PATCH 4/9] crypto: ux500/cryp - Prepare clock before enabling it
In-Reply-To: <1366280825-31136-1-git-send-email-lee.jones@linaro.org>
References: <1366280825-31136-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1366280825-31136-5-git-send-email-lee.jones@linaro.org>

If we fail to prepare the ux500-cryp clock before enabling it the
platform will fail to boot. Here we insure this happens.

Cc: Herbert Xu <herbert at gondor.apana.org.au>
Cc: David S. Miller <davem at davemloft.net>
Cc: Andreas Westin <andreas.westin at stericsson.com>
Cc: linux-crypto at vger.kernel.org
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 drivers/crypto/ux500/cryp/cryp_core.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/crypto/ux500/cryp/cryp_core.c b/drivers/crypto/ux500/cryp/cryp_core.c
index 8bc5fef..a56cbc4 100644
--- a/drivers/crypto/ux500/cryp/cryp_core.c
+++ b/drivers/crypto/ux500/cryp/cryp_core.c
@@ -670,7 +670,7 @@ static int cryp_disable_power(struct device *dev,
 	}
 	spin_unlock(&device_data->ctx_lock);
 
-	clk_disable(device_data->clk);
+	clk_disable_unprepare(device_data->clk);
 	ret = regulator_disable(device_data->pwr_regulator);
 	if (ret)
 		dev_err(dev, "[%s]: "
@@ -703,9 +703,9 @@ static int cryp_enable_power(
 			goto out;
 		}
 
-		ret = clk_enable(device_data->clk);
+		ret = clk_prepare_enable(device_data->clk);
 		if (ret) {
-			dev_err(dev, "[%s]: clk_enable() failed!",
+			dev_err(dev, "[%s]: clk_prepare_enable() failed!",
 					__func__);
 			regulator_disable(device_data->pwr_regulator);
 			goto out;
-- 
1.7.10.4



From lee.jones at linaro.org  Thu Apr 18 06:27:01 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Thu, 18 Apr 2013 11:27:01 +0100
Subject: [PATCH 5/9] crypto: ux500/cryp - Fix compile error
In-Reply-To: <1366280825-31136-1-git-send-email-lee.jones@linaro.org>
References: <1366280825-31136-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1366280825-31136-6-git-send-email-lee.jones@linaro.org>

Clearly this driver hasn't been tested, or even enabled in a while.

drivers/crypto/ux500/cryp/cryp_core.c:1771:3:
	error: request for member ?pm? in something not a structure or union

Cc: Herbert Xu <herbert at gondor.apana.org.au>
Cc: David S. Miller <davem at davemloft.net>
Cc: Andreas Westin <andreas.westin at stericsson.com>
Cc: linux-crypto at vger.kernel.org
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 drivers/crypto/ux500/cryp/cryp_core.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/crypto/ux500/cryp/cryp_core.c b/drivers/crypto/ux500/cryp/cryp_core.c
index a56cbc4..444deaf 100644
--- a/drivers/crypto/ux500/cryp/cryp_core.c
+++ b/drivers/crypto/ux500/cryp/cryp_core.c
@@ -1750,7 +1750,7 @@ static struct platform_driver cryp_driver = {
 	.shutdown = ux500_cryp_shutdown,
 	.driver = {
 		.owner = THIS_MODULE,
-		.name  = "cryp1"
+		.name  = "cryp1",
 		.pm    = &ux500_cryp_pm,
 	}
 };
-- 
1.7.10.4



From lee.jones at linaro.org  Thu Apr 18 06:27:02 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Thu, 18 Apr 2013 11:27:02 +0100
Subject: [PATCH 6/9] crypto: ux500/cryp - Set DMA configuration though
 dma_slave_config()
In-Reply-To: <1366280825-31136-1-git-send-email-lee.jones@linaro.org>
References: <1366280825-31136-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1366280825-31136-7-git-send-email-lee.jones@linaro.org>

The DMA controller currently takes configuration information from
information passed though dma_channel_request(), but it shouldn't.
Using the API, the DMA channel should only be configured during
a dma_slave_config() call.

Cc: Herbert Xu <herbert at gondor.apana.org.au>
Cc: David S. Miller <davem at davemloft.net>
Cc: Andreas Westin <andreas.westin at stericsson.com>
Cc: linux-crypto at vger.kernel.org
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 drivers/crypto/ux500/cryp/cryp.h      |    7 ++++++-
 drivers/crypto/ux500/cryp/cryp_core.c |   17 +++++++++++++++++
 2 files changed, 23 insertions(+), 1 deletion(-)

diff --git a/drivers/crypto/ux500/cryp/cryp.h b/drivers/crypto/ux500/cryp/cryp.h
index 14cfd05..49b2095 100644
--- a/drivers/crypto/ux500/cryp/cryp.h
+++ b/drivers/crypto/ux500/cryp/cryp.h
@@ -114,6 +114,9 @@ enum cryp_status_id {
 };
 
 /* Cryp DMA interface */
+#define HASH_DMA_TX_FIFO	0x08
+#define HASH_DMA_RX_FIFO	0x10
+
 enum cryp_dma_req_type {
 	CRYP_DMA_DISABLE_BOTH,
 	CRYP_DMA_ENABLE_IN_DATA,
@@ -217,7 +220,8 @@ struct cryp_dma {
 
 /**
  * struct cryp_device_data - structure for a cryp device.
- * @base: Pointer to the hardware base address.
+ * @base: Pointer to virtual base address of the cryp device.
+ * @phybase: Pointer to physical memory location of the cryp device.
  * @dev: Pointer to the devices dev structure.
  * @clk: Pointer to the device's clock control.
  * @pwr_regulator: Pointer to the device's power control.
@@ -232,6 +236,7 @@ struct cryp_dma {
  */
 struct cryp_device_data {
 	struct cryp_register __iomem *base;
+	phys_addr_t phybase;
 	struct device *dev;
 	struct clk *clk;
 	struct regulator *pwr_regulator;
diff --git a/drivers/crypto/ux500/cryp/cryp_core.c b/drivers/crypto/ux500/cryp/cryp_core.c
index 444deaf..6c4f872 100644
--- a/drivers/crypto/ux500/cryp/cryp_core.c
+++ b/drivers/crypto/ux500/cryp/cryp_core.c
@@ -476,6 +476,19 @@ static int cryp_get_device_data(struct cryp_ctx *ctx,
 static void cryp_dma_setup_channel(struct cryp_device_data *device_data,
 				   struct device *dev)
 {
+	struct dma_slave_config mem2cryp = {
+		.direction = DMA_MEM_TO_DEV,
+		.dst_addr = device_data->phybase + HASH_DMA_TX_FIFO,
+		.dst_addr_width = DMA_SLAVE_BUSWIDTH_2_BYTES,
+		.dst_maxburst = 4,
+        };
+	struct dma_slave_config cryp2mem = {
+		.direction = DMA_DEV_TO_MEM,
+		.src_addr = device_data->phybase + HASH_DMA_RX_FIFO,
+		.src_addr_width = DMA_SLAVE_BUSWIDTH_2_BYTES,
+		.src_maxburst = 4,
+        };
+
 	dma_cap_zero(device_data->dma.mask);
 	dma_cap_set(DMA_SLAVE, device_data->dma.mask);
 
@@ -491,6 +504,9 @@ static void cryp_dma_setup_channel(struct cryp_device_data *device_data,
 				    stedma40_filter,
 				    device_data->dma.cfg_cryp2mem);
 
+	dmaengine_slave_config(device_data->dma.chan_mem2cryp, &mem2cryp);
+	dmaengine_slave_config(device_data->dma.chan_cryp2mem, &cryp2mem);
+
 	init_completion(&device_data->dma.cryp_dma_complete);
 }
 
@@ -1432,6 +1448,7 @@ static int ux500_cryp_probe(struct platform_device *pdev)
 		goto out_kfree;
 	}
 
+	device_data->phybase = res->start;
 	device_data->base = ioremap(res->start, resource_size(res));
 	if (!device_data->base) {
 		dev_err(dev, "[%s]: ioremap failed!", __func__);
-- 
1.7.10.4



From lee.jones at linaro.org  Thu Apr 18 06:27:03 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Thu, 18 Apr 2013 11:27:03 +0100
Subject: [PATCH 7/9] ARM: ux500: Stop passing Cryp DMA channel config
 information though pdata
In-Reply-To: <1366280825-31136-1-git-send-email-lee.jones@linaro.org>
References: <1366280825-31136-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1366280825-31136-8-git-send-email-lee.jones@linaro.org>

DMA channel configuration information should be setup in the driver.
The Ux500 Cryp driver now does this, so there's no need to send it
though here too.

Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/mach-ux500/board-mop500.c |    8 --------
 1 file changed, 8 deletions(-)

diff --git a/arch/arm/mach-ux500/board-mop500.c b/arch/arm/mach-ux500/board-mop500.c
index cb7ae23..7f756cc 100644
--- a/arch/arm/mach-ux500/board-mop500.c
+++ b/arch/arm/mach-ux500/board-mop500.c
@@ -453,20 +453,12 @@ static struct cryp_platform_data u8500_cryp1_platform_data = {
 		.mem_to_engine = {
 				.dir = STEDMA40_MEM_TO_PERIPH,
 				.dev_type = DB8500_DMA_DEV48_CAC1,
-				.src_info.data_width = STEDMA40_WORD_WIDTH,
-				.dst_info.data_width = STEDMA40_WORD_WIDTH,
 				.mode = STEDMA40_MODE_LOGICAL,
-				.src_info.psize = STEDMA40_PSIZE_LOG_4,
-				.dst_info.psize = STEDMA40_PSIZE_LOG_4,
 		},
 		.engine_to_mem = {
 				.dir = STEDMA40_PERIPH_TO_MEM,
 				.dev_type = DB8500_DMA_DEV48_CAC1,
-				.src_info.data_width = STEDMA40_WORD_WIDTH,
-				.dst_info.data_width = STEDMA40_WORD_WIDTH,
 				.mode = STEDMA40_MODE_LOGICAL,
-				.src_info.psize = STEDMA40_PSIZE_LOG_4,
-				.dst_info.psize = STEDMA40_PSIZE_LOG_4,
 		}
 };
 
-- 
1.7.10.4



From lee.jones at linaro.org  Thu Apr 18 06:27:04 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Thu, 18 Apr 2013 11:27:04 +0100
Subject: [PATCH 8/9] crypto: ux500/[cryp|hash] - Show successful start-up in
 the bootlog
In-Reply-To: <1366280825-31136-1-git-send-email-lee.jones@linaro.org>
References: <1366280825-31136-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1366280825-31136-9-git-send-email-lee.jones@linaro.org>

The Cryp driver is currently silent and the Hash driver prints the
name of its probe function unnecessarily. Let's just put a nice
descriptive one-liner there instead.

Cc: Herbert Xu <herbert at gondor.apana.org.au>
Cc: David S. Miller <davem at davemloft.net>
Cc: Andreas Westin <andreas.westin at stericsson.com>
Cc: linux-crypto at vger.kernel.org
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 drivers/crypto/ux500/cryp/cryp_core.c |    2 ++
 drivers/crypto/ux500/hash/hash_core.c |    2 +-
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/crypto/ux500/cryp/cryp_core.c b/drivers/crypto/ux500/cryp/cryp_core.c
index 6c4f872..7366910 100644
--- a/drivers/crypto/ux500/cryp/cryp_core.c
+++ b/drivers/crypto/ux500/cryp/cryp_core.c
@@ -1536,6 +1536,8 @@ static int ux500_cryp_probe(struct platform_device *pdev)
 		goto out_power;
 	}
 
+	dev_info(dev, "successfully registered\n");
+
 	return 0;
 
 out_power:
diff --git a/drivers/crypto/ux500/hash/hash_core.c b/drivers/crypto/ux500/hash/hash_core.c
index f9126f4..d3cbf5d 100644
--- a/drivers/crypto/ux500/hash/hash_core.c
+++ b/drivers/crypto/ux500/hash/hash_core.c
@@ -1767,7 +1767,7 @@ static int ux500_hash_probe(struct platform_device *pdev)
 		goto out_power;
 	}
 
-	dev_info(dev, "[%s] successfully probed\n", __func__);
+	dev_info(dev, "successfully registered\n");
 	return 0;
 
 out_power:
-- 
1.7.10.4



From lee.jones at linaro.org  Thu Apr 18 06:27:05 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Thu, 18 Apr 2013 11:27:05 +0100
Subject: [PATCH 9/9] ARM: ux500: Register Cyrp and Hash platform drivers on
 Snowball
In-Reply-To: <1366280825-31136-1-git-send-email-lee.jones@linaro.org>
References: <1366280825-31136-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1366280825-31136-10-git-send-email-lee.jones@linaro.org>

These drivers are now operational and even use the latest common clk
and DMA APIs. There's no reason why we shouldn't start them up now.

Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/mach-ux500/board-mop500.c |    2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/mach-ux500/board-mop500.c b/arch/arm/mach-ux500/board-mop500.c
index 7f756cc..3866fa8 100644
--- a/arch/arm/mach-ux500/board-mop500.c
+++ b/arch/arm/mach-ux500/board-mop500.c
@@ -656,6 +656,8 @@ static void __init snowball_init_machine(void)
 
 	mop500_snowball_ethernet_clock_enable();
 
+	u8500_cryp1_hash1_init(parent);
+
 	/* This board has full regulator constraints */
 	regulator_has_full_constraints();
 }
-- 
1.7.10.4



From linux at arm.linux.org.uk  Thu Apr 18 06:24:44 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Thu, 18 Apr 2013 11:24:44 +0100
Subject: [RFC 06/10] video: ARM CLCD: Add DT & CDF support
In-Reply-To: <1366211842-21497-7-git-send-email-pawel.moll@arm.com>
References: <1366211842-21497-1-git-send-email-pawel.moll@arm.com>
 <1366211842-21497-7-git-send-email-pawel.moll@arm.com>
Message-ID: <20130418102444.GL14496@n2100.arm.linux.org.uk>

On Wed, Apr 17, 2013 at 04:17:18PM +0100, Pawel Moll wrote:
> +#if defined(CONFIG_OF)
> +static int clcdfb_of_get_tft_parallel_panel(struct clcd_panel *panel,
> +		struct display_entity_interface_params *params)
> +{
> +	int r = params->p.tft_parallel.r_bits;
> +	int g = params->p.tft_parallel.g_bits;
> +	int b = params->p.tft_parallel.b_bits;
> +
> +	/* Bypass pixel clock divider, data output on the falling edge */
> +	panel->tim2 = TIM2_BCD | TIM2_IPC;
> +
> +	/* TFT display, vert. comp. interrupt at the start of the back porch */
> +	panel->cntl |= CNTL_LCDTFT | CNTL_LCDVCOMP(1);
> +
> +	if (params->p.tft_parallel.r_b_swapped)
> +		panel->cntl |= CNTL_BGR;

NAK.  Do not set this explicitly.  Note the driver talks about this being
"the old way" - this should not be used with the panel capabilities - and
in fact it will be overwritten.

Instead, you need to encode this into the capabilities by masking the
below with CLCD_CAP_RGB or CLCD_CAP_BGR depending on the ordering.


From linus.walleij at stericsson.com  Thu Apr 18 06:35:14 2013
From: linus.walleij at stericsson.com (Linus Walleij)
Date: Thu, 18 Apr 2013 12:35:14 +0200
Subject: [PATCH v3] pinctrl/pinconfig: add debug interface
Message-ID: <1366281314-14613-1-git-send-email-linus.walleij@stericsson.com>

From: Laurent Meunier <laurent.meunier at st.com>

This update adds a debugfs interface to modify a pin configuration
for a given state in the pinctrl map. This allows to modify the
configuration for a non-active state, typically sleep state.
This configuration is not applied right away, but only when the state
will be entered.

This solution is mandated for us by HW validation: in order
to test and verify several pin configurations during sleep without
recompiling the software.

Change log in this patch set;
Take into account latest feedback from Stephen Warren:
- stale comments update
- improved code efficiency and readibility
- limit size of global variable pinconf_dbg_conf
- remove req_type as it can easily be added later when
add/delete requests support is implemented

Signed-off-by: Laurent Meunier <laurent.meunier at st.com>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 drivers/pinctrl/pinconf.c       | 232 ++++++++++++++++++++++++++++++++++++++++
 include/linux/pinctrl/pinconf.h |   6 ++
 2 files changed, 238 insertions(+)

diff --git a/drivers/pinctrl/pinconf.c b/drivers/pinctrl/pinconf.c
index baee2cc..1b6047d 100644
--- a/drivers/pinctrl/pinconf.c
+++ b/drivers/pinctrl/pinconf.c
@@ -17,6 +17,7 @@
 #include <linux/slab.h>
 #include <linux/debugfs.h>
 #include <linux/seq_file.h>
+#include <linux/uaccess.h>
 #include <linux/pinctrl/machine.h>
 #include <linux/pinctrl/pinctrl.h>
 #include <linux/pinctrl/pinconf.h>
@@ -574,6 +575,235 @@ static const struct file_operations pinconf_groups_ops = {
 	.release	= single_release,
 };
 
+#define MAX_NAME_LEN 15
+
+struct dbg_cfg {
+	enum pinctrl_map_type map_type;
+	char dev_name[MAX_NAME_LEN+1];
+	char state_name[MAX_NAME_LEN+1];
+	char pin_name[MAX_NAME_LEN+1];
+};
+
+/*
+ * Goal is to keep this structure as global in order to simply read the
+ * pinconf-config file after a write to check config is as expected
+ */
+static struct dbg_cfg pinconf_dbg_conf;
+
+/**
+ * pinconf_dbg_config_print() - display the pinctrl config from the pinctrl
+ * map, of the dev/pin/state that was last written to pinconf-config file.
+ * @s: string filled in  with config description
+ * @d: not used
+ */
+static int pinconf_dbg_config_print(struct seq_file *s, void *d)
+{
+	struct pinctrl_maps *maps_node;
+	const struct pinctrl_map *map;
+	struct pinctrl_dev *pctldev = NULL;
+	const struct pinconf_ops *confops = NULL;
+	const struct pinctrl_map_configs *configs;
+	struct dbg_cfg *dbg = &pinconf_dbg_conf;
+	int i, j;
+	bool found = false;
+	unsigned long config;
+
+	mutex_lock(&pinctrl_mutex);
+
+	/* Parse the pinctrl map and look for the elected pin/state */
+	for_each_maps(maps_node, i, map) {
+		if (map->type != dbg->map_type)
+			continue;
+		if (!!strcmp(map->dev_name, dbg->dev_name))
+			continue;
+		if (!!strcmp(map->name, dbg->state_name))
+			continue;
+
+		for (j = 0; j < map->data.configs.num_configs; j++) {
+			if (!strcmp(map->data.configs.group_or_pin,
+					dbg->pin_name)) {
+				/*
+				 * We found the right pin / state, read the
+				 * config and he pctldev for later use
+				 */
+				configs = &map->data.configs;
+				pctldev = get_pinctrl_dev_from_devname
+					(map->ctrl_dev_name);
+				found = true;
+				break;
+			}
+		}
+	}
+
+	if (!found) {
+		seq_printf(s, "No config found for dev/state/pin, expected:\n");
+		seq_printf(s, "Searched dev:%s\n", dbg->dev_name);
+		seq_printf(s, "Searched state:%s\n", dbg->state_name);
+		seq_printf(s, "Searched pin:%s\n", dbg->pin_name);
+		seq_printf(s, "Use: modify config_pin <devname> "\
+				"<state> <pinname> <value>\n");
+		goto exit;
+	}
+
+	config = *(configs->configs);
+	seq_printf(s, "Dev %s has config of %s in state %s: 0x%08lX\n",
+			dbg->dev_name, dbg->pin_name,
+			dbg->state_name, config);
+
+	if (pctldev)
+		confops = pctldev->desc->confops;
+
+	if (confops && confops->pin_config_config_dbg_show)
+		confops->pin_config_config_dbg_show(pctldev, s, config);
+
+exit:
+	mutex_unlock(&pinctrl_mutex);
+
+	return 0;
+}
+
+/**
+ * pinconf_dbg_config_write() - modify the pinctrl config in the pinctrl
+ * map, of a dev/pin/state entry based on user entries to pinconf-config
+ * @user_buf: contains the modification request with expected format:
+ *     modify config_pin <devicename> <state> <pinname> <newvalue>
+ * modify is literal string, alternatives like add/delete not supported yet
+ * config_pin is literal, alternatives like config_mux not supported yet
+ * <devicename> <state> <pinname> are values that should match the pinctrl-maps
+ * <newvalue> reflects the new config and is driver dependant
+ */
+static int pinconf_dbg_config_write(struct file *file,
+	const char __user *user_buf, size_t count, loff_t *ppos)
+{
+	struct pinctrl_maps *maps_node;
+	const struct pinctrl_map *map;
+	struct pinctrl_dev *pctldev = NULL;
+	const struct pinconf_ops *confops = NULL;
+	struct dbg_cfg *dbg = &pinconf_dbg_conf;
+	const struct pinctrl_map_configs *configs;
+	char config[MAX_NAME_LEN+1];
+	bool found = false;
+	char buf[128];
+	char *b = &buf[0];
+	int buf_size;
+	char *token;
+	int i;
+
+	/* Get userspace string and assure termination */
+	buf_size = min(count, (sizeof(buf)-1));
+	if (copy_from_user(buf, user_buf, buf_size))
+		return -EFAULT;
+	buf[buf_size] = 0;
+
+	/*
+	 * need to parse entry and extract parameters:
+	 * modify configs_pin devicename state pinname newvalue
+	 */
+
+	/* Get arg: 'modify' */
+	token = strsep(&b, " ");
+	if (!token)
+		return -EINVAL;
+	if (!!strcmp(token, "modify"))
+		return -EINVAL;
+
+	/* Get arg type: "config_pin" type supported so far */
+	token = strsep(&b, " ");
+	if (!token)
+		return -EINVAL;
+	if (!!strcmp(token, "config_pin"))
+		return -EINVAL;
+	dbg->map_type = PIN_MAP_TYPE_CONFIGS_PIN;
+
+	/* get arg 'device_name' */
+	token = strsep(&b, " ");
+	if (token == NULL)
+		return -EINVAL;
+	if (strlen(token) >= MAX_NAME_LEN)
+		return -EINVAL;
+	strncpy(dbg->dev_name, token, MAX_NAME_LEN);
+
+	/* get arg 'state_name' */
+	token = strsep(&b, " ");
+	if (token == NULL)
+		return -EINVAL;
+	if (strlen(token) >= MAX_NAME_LEN)
+		return -EINVAL;
+	strncpy(dbg->state_name, token, MAX_NAME_LEN);
+
+	/* get arg 'pin_name' */
+	token = strsep(&b, " ");
+	if (token == NULL)
+		return -EINVAL;
+	if (strlen(token) >= MAX_NAME_LEN)
+		return -EINVAL;
+	strncpy(dbg->pin_name, token, MAX_NAME_LEN);
+
+	/* get new_value of config' */
+	token = strsep(&b, " ");
+	if (token == NULL)
+		return -EINVAL;
+	if (strlen(token) >= MAX_NAME_LEN)
+		return -EINVAL;
+	strncpy(config, token, MAX_NAME_LEN);
+
+	mutex_lock(&pinctrl_mutex);
+
+	/* Parse the pinctrl map and look for the selected dev/state/pin */
+	for_each_maps(maps_node, i, map) {
+		if (!!strcmp(map->dev_name, dbg->dev_name))
+			continue;
+		if (map->type != dbg->map_type)
+			continue;
+		if (!!strcmp(map->name, dbg->state_name))
+			continue;
+
+		/*  we found the right pin / state, so overwrite config */
+		if (!strcmp(map->data.configs.group_or_pin, dbg->pin_name)) {
+			found = true;
+			pctldev = get_pinctrl_dev_from_devname(
+					map->ctrl_dev_name);
+			configs = &map->data.configs;
+			break;
+		}
+	}
+
+	if (!found) {
+		goto exit;
+		count = -EINVAL;
+	}
+
+	if (pctldev)
+		confops = pctldev->desc->confops;
+
+	if (confops && confops->pin_config_dbg_parse_modify) {
+		for (i = 0; i < configs->num_configs; i++) {
+			confops->pin_config_dbg_parse_modify(pctldev,
+						     config,
+						     &configs->configs[i]);
+		}
+	}
+
+exit:
+	mutex_unlock(&pinctrl_mutex);
+
+	return count;
+}
+
+static int pinconf_dbg_config_open(struct inode *inode, struct file *file)
+{
+	return single_open(file, pinconf_dbg_config_print, inode->i_private);
+}
+
+static const struct file_operations pinconf_dbg_pinconfig_fops = {
+	.open = pinconf_dbg_config_open,
+	.write = pinconf_dbg_config_write,
+	.read = seq_read,
+	.llseek = seq_lseek,
+	.release = single_release,
+	.owner = THIS_MODULE,
+};
+
 void pinconf_init_device_debugfs(struct dentry *devroot,
 			 struct pinctrl_dev *pctldev)
 {
@@ -581,6 +811,8 @@ void pinconf_init_device_debugfs(struct dentry *devroot,
 			    devroot, pctldev, &pinconf_pins_ops);
 	debugfs_create_file("pinconf-groups", S_IFREG | S_IRUGO,
 			    devroot, pctldev, &pinconf_groups_ops);
+	debugfs_create_file("pinconf-config",  (S_IRUGO | S_IWUSR | S_IWGRP),
+			    devroot, pctldev, &pinconf_dbg_pinconfig_fops);
 }
 
 #endif
diff --git a/include/linux/pinctrl/pinconf.h b/include/linux/pinctrl/pinconf.h
index e7a7201..1ad4f31 100644
--- a/include/linux/pinctrl/pinconf.h
+++ b/include/linux/pinctrl/pinconf.h
@@ -14,6 +14,8 @@
 
 #ifdef CONFIG_PINCONF
 
+#include <linux/pinctrl/machine.h>
+
 struct pinctrl_dev;
 struct seq_file;
 
@@ -28,6 +30,7 @@ struct seq_file;
  * @pin_config_set: configure an individual pin
  * @pin_config_group_get: get configurations for an entire pin group
  * @pin_config_group_set: configure all pins in a group
+ * @pin_config_group_dbg_set: optional debugfs to modify a pin configuration
  * @pin_config_dbg_show: optional debugfs display hook that will provide
  *	per-device info for a certain pin in debugfs
  * @pin_config_group_dbg_show: optional debugfs display hook that will provide
@@ -51,6 +54,9 @@ struct pinconf_ops {
 	int (*pin_config_group_set) (struct pinctrl_dev *pctldev,
 				     unsigned selector,
 				     unsigned long config);
+	int (*pin_config_dbg_parse_modify) (struct pinctrl_dev *pctldev,
+					   const char *arg,
+					   unsigned long *config);
 	void (*pin_config_dbg_show) (struct pinctrl_dev *pctldev,
 				     struct seq_file *s,
 				     unsigned offset);
-- 
1.7.11.3



From linux at arm.linux.org.uk  Thu Apr 18 06:43:38 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Thu, 18 Apr 2013 11:43:38 +0100
Subject: [PATCH 03/32] dmaengine: ste_dma40: Use the BIT macro to
 replace ugly '(1 << x)'s
In-Reply-To: <1366279934-30761-4-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-4-git-send-email-lee.jones@linaro.org>
Message-ID: <20130418104338.GM14496@n2100.arm.linux.org.uk>

On Thu, Apr 18, 2013 at 11:11:45AM +0100, Lee Jones wrote:
> The aim is to make the code that little more readable.

Maybe we should also invent the MULT() macro too, because a * b is just
too ugly as well?  Maybe ADD(), SUB() and DIV() macros as well...  Think
of all those extra parens you could use! :)

> @@ -1448,7 +1448,7 @@ static u32 d40_residue(struct d40_chan *d40c)
>  			  >> D40_SREG_ELEM_PHY_ECNT_POS;
>  	}
>  
> -	return num_elt * (1 << d40c->dma_cfg.dst_info.data_width);
> +	return num_elt * BIT(d40c->dma_cfg.dst_info.data_width);

This should be:
	return num_elt << d40c->dma_cfg.dst_info.data_width;


From arnd at arndb.de  Thu Apr 18 06:44:23 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 18 Apr 2013 12:44:23 +0200
Subject: [PATCH 0/9] Fix ux500 crypto drivers and init DMA in the correct
 way
In-Reply-To: <1366280825-31136-1-git-send-email-lee.jones@linaro.org>
References: <1366280825-31136-1-git-send-email-lee.jones@linaro.org>
Message-ID: <201304181244.24036.arnd@arndb.de>

On Thursday 18 April 2013, Lee Jones wrote:
> These drivers haven't been touched in a while. They didn't even compile
> or probe successfully. After these changes, both drivers run just fine.
> 
> We also split DMA channel allocation and configuration into separate
> invocations, as the API expects.

Very nice series!

Acked-by: Arnd Bergmann <arnd at arndb.de>


From linux at arm.linux.org.uk  Thu Apr 18 06:45:23 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Thu, 18 Apr 2013 11:45:23 +0100
Subject: [PATCH 15/32] dmaengine: ste_dma40: Separate Logical Global
 Interrupt Mask (GIM) unmasking
In-Reply-To: <1366279934-30761-16-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-16-git-send-email-lee.jones@linaro.org>
Message-ID: <20130418104523.GN14496@n2100.arm.linux.org.uk>

On Thu, Apr 18, 2013 at 11:11:57AM +0100, Lee Jones wrote:
> +void d40_log_gim_unmask(u32 *src_cfg, u32 *dst_cfg) {
> +
> +	*src_cfg |= 1 << D40_SREG_CFG_LOG_GIM_POS;
> +	*dst_cfg |= 1 << D40_SREG_CFG_LOG_GIM_POS;

So, in patch 3, you started using the BIT() macro.  But here it's fine
not to because... ?

Use one notation or the other, don't mix them together.


From arnd at arndb.de  Thu Apr 18 06:46:03 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 18 Apr 2013 12:46:03 +0200
Subject: [PATCH 08/32] dmaengine: ste_dma40: Optimise local MAX() macro
In-Reply-To: <1366279934-30761-9-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-9-git-send-email-lee.jones@linaro.org>
Message-ID: <201304181246.03357.arnd@arndb.de>

On Thursday 18 April 2013, Lee Jones wrote:
> The current implementation of the DMA40's local MAX() macro evaluates
> its arguments more times than is necessary. This patch strips it
> optimises it to only evaluate what's appropriate.

No, it does not.

> index b21a8a3..7b451b2 100644
> --- a/drivers/dma/ste_dma40.c
> +++ b/drivers/dma/ste_dma40.c
> @@ -53,7 +53,7 @@
>  #define D40_ALLOC_PHY          BIT(30)
>  #define D40_ALLOC_LOG_FREE     BIT(0)
>  
> -#define MAX(a, b) (((a) < (b)) ? (b) : (a))
> +#define MAX(a, b) ((a > b) ? a : b)

This just makes the macro worse in case you pass a complex expression
in, which can now have additional unwanted effects. Just drop this patch.

	Arnd


From arnd at arndb.de  Thu Apr 18 06:48:36 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 18 Apr 2013 12:48:36 +0200
Subject: [PATCH 07/32] ARM: ux500: Supply address location names for the
 DMA40 DMA controller
In-Reply-To: <1366279934-30761-8-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-8-git-send-email-lee.jones@linaro.org>
Message-ID: <201304181248.36597.arnd@arndb.de>

On Thursday 18 April 2013, Lee Jones wrote:
> The DMA40 controller uses two sets of base addresses. In order to have
> them automatically setup as resources by the Open Format framework we
> have to set names for them. The names have to be the same as the ones
> used to fetch them back out of the resource structure.
> 
> Signed-off-by: Lee Jones <lee.jones at linaro.org>

Typo: s/Open Format/Open Firmware/

To be more specific, just write of_platform framework. Note that we
still get resources without passing the names, they are just not
named in that case and have to be retrieved by index.

You should also document the strings in the binding document.

	ARnd


From arnd at arndb.de  Thu Apr 18 06:50:50 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 18 Apr 2013 12:50:50 +0200
Subject: [PATCH 05/32] dmaengine: ste_dma40: Supply macros to resolve
 'src' and 'dst' directions
In-Reply-To: <1366279934-30761-6-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-6-git-send-email-lee.jones@linaro.org>
Message-ID: <201304181250.50647.arnd@arndb.de>

On Thursday 18 April 2013, Lee Jones wrote:
> +#define D40_IS_SRC(dir)  ((dir == STEDMA40_PERIPH_TO_MEM) ? true : false)
> +#define D40_IS_DST(dir) (((dir == STEDMA40_MEM_TO_PERIPH) || \
> +                         (dir == STEDMA40_MEM_TO_MEM)) ? true : false)
> +

The redundant "? true : false" part is redundant. ;-)

Otherwise the patch looks good.

Acked-by: Arnd Bergmann <arnd at arndb.de>

	Arnd


From arnd at arndb.de  Thu Apr 18 06:51:44 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 18 Apr 2013 12:51:44 +0200
Subject: [PATCH 06/32] ARM: ux500: Strip out duplicate USB DMA
 configuration
In-Reply-To: <1366279934-30761-7-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-7-git-send-email-lee.jones@linaro.org>
Message-ID: <201304181251.44758.arnd@arndb.de>

On Thursday 18 April 2013, Lee Jones wrote:
> For the moment at least, the TX and RX channels for DB8500 USB are
> identical, so this patch generalises them into a single structure
> and passes it twice. Once as the TX and again for the RX configuration.
> We're keeping the infrastructure the same i.e. passing the TX and RX
> separately in case they start to differ on latter incarnations of the
> platform.
> 
> Signed-off-by: Lee Jones <lee.jones at linaro.org>

Acked-by: Arnd Bergmann <arnd at arndb.de>


From linux at arm.linux.org.uk  Thu Apr 18 06:52:46 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Thu, 18 Apr 2013 11:52:46 +0100
Subject: [PATCH v3] pinctrl/pinconfig: add debug interface
In-Reply-To: <1366281314-14613-1-git-send-email-linus.walleij@stericsson.com>
References: <1366281314-14613-1-git-send-email-linus.walleij@stericsson.com>
Message-ID: <20130418105246.GO14496@n2100.arm.linux.org.uk>

On Thu, Apr 18, 2013 at 12:35:14PM +0200, Linus Walleij wrote:
> +		if (map->type != dbg->map_type)
> +			continue;
> +		if (!!strcmp(map->dev_name, dbg->dev_name))

!! is pointless in this context - if() evaluates any non-zero value as
true, so there's no point making the code more complicated by trying to
convert it to a false/true value first.


From rnayak at ti.com  Thu Apr 18 06:53:07 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Thu, 18 Apr 2013 16:23:07 +0530
Subject: [PATCH 2/8] ARM: OMAP2+: hwmod: Cleanup sidle/mstandby programming
In-Reply-To: <515947D3.50904@ti.com>
References: <1361354272-18089-1-git-send-email-santosh.shilimkar@ti.com>
 <1361354272-18089-3-git-send-email-santosh.shilimkar@ti.com>
 <alpine.DEB.2.00.1303310053351.6436@utopia.booyaka.com>
 <515947D3.50904@ti.com>
Message-ID: <516FD093.1020607@ti.com>

Hi Paul,

>>> _enable_wakeup() and _disable_wakeup() are expected to program the
>>> OCP_SYSCONFIG.ENAWAKEUP bit.
>>
>> These functions were originally intended to take care of everything needed 
>> for the IP block to wake up the chip, including the PRCM WKEN programming.  
>> ENAWAKEUP is simply one part of that.
>>
>>> Get rid of the additional sidle/mstandby programming in them, as its 
>>> confusing (this is expected to be handled elsewhere as part of 
>>> _enable_sysc()/__idle_sysc())
>>
>> Sorry, why does the expectation exist for the code to enable and disable 
>> device wakeup to be part of _enable_sysc()/_idle_sysc(), rather than in 
>> functions called by _enable_sysc()/_idle_sysc()?
> 
> It all comes down to if SIDLE_SMART_WKUP/MSTANDBY_SMART_WKUP programming
> be considered as 'idlemode' programming or 'enwakeup' programming.
> If you consider these are being part of 'enwakeup' progrmming, these should
> certainly be handled as part of _enable_wakeup() and _disable_wakeup().
> 
> Today, in some cases, these are *also* handled as part of _enable_sysc()
> and _idle_sysc(). The way _enable_wakeup() is invoked from _enable_sysc()
> is also very inconsistent. For instance, for any IP which supports
> SYSC_HAS_MIDLEMODE and SYSC_HAS_ENAWAKEUP, we invoke _enable_wakeup()
> regardless of the MIDLEMODE programmmed.
> While in case of the IP supporting SYSC_HAS_SIDLEMODE, _enable_wakeup() is
> invoked only when the SIDLEMODE programmed is SMART or SMART_WKUP.
> 
> I understand the cleanups you are suggesting below as part of the movement
> of some of these things outside of mach-omap2.
> I was more looking at fixing the existing piece so its readable and does
> things more consistently.

Do you have any further thoughts on how we should do about this?

regards,
Rajendra

> 
> regards,
> Rajendra
> 
>>
>>> and unnecessary.
>>
>> So here's part of the reason why the module wakeup control functions 
>> should remain separate.  When the kernel boots, all the PM features should 
>> be disabled.  Then mach-omap2/pm*.c should enables PM features where 
>> they're needed.
>>
>> Right now, mach-omap2/pm34xx.c sets module WKEN bits.  (These direct 
>> register accesses need to be moved as part of the cleanup work, of moving 
>> the PM/PRM/CM code into drivers.)  But the list of IP blocks that 
>> should be allowed to wake the system is board-dependent.
>>
>> So really, what mach-omap2/pm34xx.c should do is to call into the hwmod 
>> enable-wakeups code to enable MPU wakeups for all the IP blocks that have 
>> some DT property set, something like 'enable-wakeups'.  Then the hwmod 
>> code should ensure that the PRM wakeup-enable and GRPSEL bits are 
>> programmed (by calling into the PRM driver code) and should then either 
>> set the ENAWAKEUP bits or put the module into smart_wkup MSTANDBY/MIDLE.
>>
>> Similarly, when the PM driver is unloaded, it should set no-idle on all 
>> the IP blocks that were marked as wakeup-capable and disable the PRCM 
>> wakeup control bits, by calling some hwmod disable-wakeups code.
>>
>>> Well, the _enable_sysc()/_idle_sysc() handled only the mstandby modes
>>> correctly. So fix them so they also handle the midle modes correctly
>>
>> If there's a fix here, please split that out into a separate patch.
>>
>>
>> - Paul
>>
> 



From arnd at arndb.de  Thu Apr 18 06:53:33 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 18 Apr 2013 12:53:33 +0200
Subject: [PATCH 14/32] dmaengine: ste_dma40: Remove 'always true' checking
In-Reply-To: <1366279934-30761-15-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-15-git-send-email-lee.jones@linaro.org>
Message-ID: <201304181253.33762.arnd@arndb.de>

On Thursday 18 April 2013, Lee Jones wrote:
> Before allocating memory for logical channels, the current driver
> checks to see if there are any. Well as the dma40_memcpy_channels[]
> array is always populated, the check is always true. Best to
> remove the check.
> 
> Cc: Vinod Koul <vinod.koul at intel.com>
> Cc: Dan Williams <djbw at fb.com>
> Cc: Per Forlin <per.forlin at stericsson.com>
> Cc: Rabin Vincent <rabin at rab.in>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>

Acked-by: Arnd Bergmann <arnd at arndb.de>


From arnd at arndb.de  Thu Apr 18 06:54:57 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 18 Apr 2013 12:54:57 +0200
Subject: [PATCH 15/32] dmaengine: ste_dma40: Separate Logical Global
 Interrupt Mask (GIM) unmasking
In-Reply-To: <1366279934-30761-16-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-16-git-send-email-lee.jones@linaro.org>
Message-ID: <201304181254.57776.arnd@arndb.de>

On Thursday 18 April 2013, Lee Jones wrote:
> During the initial setup of a logical channel, it is necessary to unmask
> the GIM in order to receive generated terminal count and error interrupts.
> We're separating out this required code so it will be possible to move
> the remaining code in d40_phy_cfg(), which is mostly runtime configuration
> into the runtime_config() routine.
> 
> Cc: Vinod Koul <vinod.koul at intel.com>
> Cc: Dan Williams <djbw at fb.com>
> Cc: Per Forlin <per.forlin at stericsson.com>
> Cc: Rabin Vincent <rabin at rab.in>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>

Acked-by: Arnd Bergmann <arnd at arndb.de>


From arnd at arndb.de  Thu Apr 18 06:55:44 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 18 Apr 2013 12:55:44 +0200
Subject: [PATCH 16/32] dmaengine: ste_dma40: Remove unnecessary call to
 d40_phy_cfg()
In-Reply-To: <1366279934-30761-17-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-17-git-send-email-lee.jones@linaro.org>
Message-ID: <201304181255.44950.arnd@arndb.de>

On Thursday 18 April 2013, Lee Jones wrote:
> All configuration left in d40_phy_cfg() is runtime configurable and
> there is already a call into it from d40_runtime_config(), so let's
> rely on that.
> 
> Cc: Vinod Koul <vinod.koul at intel.com>
> Cc: Dan Williams <djbw at fb.com>
> Cc: Per Forlin <per.forlin at stericsson.com>
> Cc: Rabin Vincent <rabin at rab.in>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>

Acked-by: Arnd Bergmann <arnd at arndb.de>


From arnd at arndb.de  Thu Apr 18 06:58:04 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 18 Apr 2013 12:58:04 +0200
Subject: [PATCH 23/32] dmaengine: ste_dma40: Allow driver to be
 probe()able when DT is enabled
In-Reply-To: <1366279934-30761-24-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-24-git-send-email-lee.jones@linaro.org>
Message-ID: <201304181258.04477.arnd@arndb.de>

On Thursday 18 April 2013, Lee Jones wrote:
> When booting using Device Tree, devices aren't registered in the normal
> way. Instead, they need to be provided with a compatible string which is
> held in an OF Match Table for comparison during start-up. Here we provide
> the compatible string and prepare the driver to not receive a platform
> data pointer.
> 
> Cc: Vinod Koul <vinod.koul at intel.com>
> Cc: Dan Williams <djbw at fb.com>
> Cc: Per Forlin <per.forlin at stericsson.com>
> Cc: Rabin Vincent <rabin at rab.in>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>

Acked-by: Arnd Bergmann <arnd at arndb.de>


From nicolas.ferre at atmel.com  Thu Apr 18 06:59:42 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Thu, 18 Apr 2013 12:59:42 +0200
Subject: [PATCH 1/6] at_hdmac: move to generic DMA binding
In-Reply-To: <1366117390-24686-2-git-send-email-ludovic.desroches@atmel.com>
References: <1366117390-24686-1-git-send-email-ludovic.desroches@atmel.com>
 <1366117390-24686-2-git-send-email-ludovic.desroches@atmel.com>
Message-ID: <516FD21E.7070807@atmel.com>

On 04/16/2013 03:03 PM, ludovic.desroches at atmel.com :
> From: Ludovic Desroches <ludovic.desroches at atmel.com>
> 
> Update at_hdmac driver to support generic DMA device tree binding. Devices
> can still request channel with dma_request_channel() then it doesn't break
> DMA for non DT boards.
> 
> Signed-off-by: Ludovic Desroches <ludovic.desroches at atmel.com>
> Acked-by: Nicolas Ferre <nicolas.ferre at atmel.com>
> Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>

I plan to make this whole series go forward for 3.10 because of the
sensitive nature of DMA bindings and the expectations of everybody on
this topic ;-)

Arnd,
Do you feel like giving your "Acked-by" to this patch? I think that you
were pretty in line with Ludovic's RFC, so it may be interesting to have
your support on this...

Vinod,
This series touches several sub-systems, I plan to split it so everyone
can take its corresponding code. Does it seem sensible to send you this
patch alone, extracted from this series, when it is ready?

Thanks, best regards.


> ---
>  .../devicetree/bindings/dma/atmel-dma.txt          | 35 ++++++--
>  drivers/dma/at_hdmac.c                             | 93 ++++++++++++++++++++--
>  drivers/dma/at_hdmac_regs.h                        |  4 +
>  3 files changed, 121 insertions(+), 11 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/dma/atmel-dma.txt b/Documentation/devicetree/bindings/dma/atmel-dma.txt
> index 3c046ee..c80e8a3 100644
> --- a/Documentation/devicetree/bindings/dma/atmel-dma.txt
> +++ b/Documentation/devicetree/bindings/dma/atmel-dma.txt
> @@ -1,14 +1,39 @@
>  * Atmel Direct Memory Access Controller (DMA)
>  
>  Required properties:
> -- compatible: Should be "atmel,<chip>-dma"
> -- reg: Should contain DMA registers location and length
> -- interrupts: Should contain DMA interrupt
> +- compatible: Should be "atmel,<chip>-dma".
> +- reg: Should contain DMA registers location and length.
> +- interrupts: Should contain DMA interrupt.
> +- #dma-cells: Must be <2>, used to represent the number of integer cells in
> +the dmas property of client devices.
>  
> -Examples:
> +Example:
>  
> -dma at ffffec00 {
> +dma0: dma at ffffec00 {
>  	compatible = "atmel,at91sam9g45-dma";
>  	reg = <0xffffec00 0x200>;
>  	interrupts = <21>;
> +	#dma-cells = <2>;
> +};
> +
> +DMA clients connected to the Atmel DMA controller must use the format
> +described in the dma.txt file, using a three-cell specifier for each channel:
> +a phandle plus two interger cells.
> +The three cells in order are:
> +
> +1. A phandle pointing to the DMA controller.
> +2. The memory interface (16 most significant bits), the peripheral interface
> +(16 less significant bits).
> +3. The peripheral identifier for the hardware handshaking interface. The
> +identifier can be different for tx and rx.
> +
> +Example:
> +
> +i2c0 at i2c@f8010000 {
> +	compatible = "atmel,at91sam9x5-i2c";
> +	reg = <0xf8010000 0x100>;
> +	interrupts = <9 4 6>;
> +	dmas = <&dma0 1 7>,
> +	       <&dma0 1 8>;
> +	dma-names = "tx", "rx";
>  };
> diff --git a/drivers/dma/at_hdmac.c b/drivers/dma/at_hdmac.c
> index de4e930..2a63dbe 100644
> --- a/drivers/dma/at_hdmac.c
> +++ b/drivers/dma/at_hdmac.c
> @@ -24,6 +24,7 @@
>  #include <linux/slab.h>
>  #include <linux/of.h>
>  #include <linux/of_device.h>
> +#include <linux/of_dma.h>
>  
>  #include "at_hdmac_regs.h"
>  #include "dmaengine.h"
> @@ -677,7 +678,7 @@ atc_prep_slave_sg(struct dma_chan *chan, struct scatterlist *sgl,
>  		ctrlb |=  ATC_DST_ADDR_MODE_FIXED
>  			| ATC_SRC_ADDR_MODE_INCR
>  			| ATC_FC_MEM2PER
> -			| ATC_SIF(AT_DMA_MEM_IF) | ATC_DIF(AT_DMA_PER_IF);
> +			| ATC_SIF(atchan->mem_if) | ATC_DIF(atchan->per_if);
>  		reg = sconfig->dst_addr;
>  		for_each_sg(sgl, sg, sg_len, i) {
>  			struct at_desc	*desc;
> @@ -716,7 +717,7 @@ atc_prep_slave_sg(struct dma_chan *chan, struct scatterlist *sgl,
>  		ctrlb |=  ATC_DST_ADDR_MODE_INCR
>  			| ATC_SRC_ADDR_MODE_FIXED
>  			| ATC_FC_PER2MEM
> -			| ATC_SIF(AT_DMA_PER_IF) | ATC_DIF(AT_DMA_MEM_IF);
> +			| ATC_SIF(atchan->per_if) | ATC_DIF(atchan->mem_if);
>  
>  		reg = sconfig->src_addr;
>  		for_each_sg(sgl, sg, sg_len, i) {
> @@ -822,8 +823,8 @@ atc_dma_cyclic_fill_desc(struct dma_chan *chan, struct at_desc *desc,
>  		desc->lli.ctrlb = ATC_DST_ADDR_MODE_FIXED
>  				| ATC_SRC_ADDR_MODE_INCR
>  				| ATC_FC_MEM2PER
> -				| ATC_SIF(AT_DMA_MEM_IF)
> -				| ATC_DIF(AT_DMA_PER_IF);
> +				| ATC_SIF(atchan->mem_if)
> +				| ATC_DIF(atchan->per_if);
>  		break;
>  
>  	case DMA_DEV_TO_MEM:
> @@ -833,8 +834,8 @@ atc_dma_cyclic_fill_desc(struct dma_chan *chan, struct at_desc *desc,
>  		desc->lli.ctrlb = ATC_DST_ADDR_MODE_INCR
>  				| ATC_SRC_ADDR_MODE_FIXED
>  				| ATC_FC_PER2MEM
> -				| ATC_SIF(AT_DMA_PER_IF)
> -				| ATC_DIF(AT_DMA_MEM_IF);
> +				| ATC_SIF(atchan->per_if)
> +				| ATC_DIF(atchan->mem_if);
>  		break;
>  
>  	default:
> @@ -1190,6 +1191,67 @@ static void atc_free_chan_resources(struct dma_chan *chan)
>  	dev_vdbg(chan2dev(chan), "free_chan_resources: done\n");
>  }
>  
> +static bool at_dma_filter(struct dma_chan *chan, void *slave)
> +{
> +	struct at_dma_slave *atslave = slave;
> +
> +	if (atslave->dma_dev == chan->device->dev) {
> +		chan->private = atslave;
> +		return true;
> +	} else {
> +		return false;
> +	}
> +}
> +
> +#ifdef CONFIG_OF
> +static struct dma_chan *at_dma_xlate(struct of_phandle_args *dma_spec,
> +				     struct of_dma *of_dma)
> +{
> +	struct dma_chan *chan;
> +	struct at_dma_chan *atchan;
> +	struct at_dma_slave *atslave;
> +	dma_cap_mask_t mask;
> +	unsigned int per_id;
> +	struct platform_device *dmac_pdev;
> +
> +	if (dma_spec->args_count != 2)
> +		return NULL;
> +
> +	dmac_pdev = of_find_device_by_node(dma_spec->np);
> +
> +	dma_cap_zero(mask);
> +	dma_cap_set(DMA_SLAVE, mask);
> +
> +	atslave = devm_kzalloc(&dmac_pdev->dev, sizeof(*atslave), GFP_KERNEL);
> +	if (!atslave)
> +		return NULL;
> +	/*
> +	 * We can fill both SRC_PER and DST_PER, one of these fields will be
> +	 * ignored depending on DMA transfer direction.
> +	 */
> +	per_id = dma_spec->args[1];
> +	atslave->cfg = ATC_FIFOCFG_HALFFIFO | ATC_DST_H2SEL_HW
> +		      | ATC_SRC_H2SEL_HW | ATC_DST_PER(per_id)
> +		      | ATC_SRC_PER(per_id);
> +	atslave->dma_dev = &dmac_pdev->dev;
> +
> +	chan = dma_request_channel(mask, at_dma_filter, atslave);
> +	if (!chan)
> +		return NULL;
> +
> +	atchan = to_at_dma_chan(chan);
> +	atchan->per_if = dma_spec->args[0] & 0xff;
> +	atchan->mem_if = (dma_spec->args[0] >> 16) & 0xff;
> +
> +	return chan;
> +}
> +#else
> +static struct dma_chan *at_dma_xlate(struct of_phandle_args *dma_spec,
> +				     struct of_dma *of_dma)
> +{
> +	return NULL;
> +}
> +#endif
>  
>  /*--  Module Management  -----------------------------------------------*/
>  
> @@ -1344,6 +1406,8 @@ static int __init at_dma_probe(struct platform_device *pdev)
>  	for (i = 0; i < plat_dat->nr_channels; i++) {
>  		struct at_dma_chan	*atchan = &atdma->chan[i];
>  
> +		atchan->mem_if = AT_DMA_MEM_IF;
> +		atchan->per_if = AT_DMA_PER_IF;
>  		atchan->chan_common.device = &atdma->dma_common;
>  		dma_cookie_init(&atchan->chan_common);
>  		list_add_tail(&atchan->chan_common.device_node,
> @@ -1390,8 +1454,25 @@ static int __init at_dma_probe(struct platform_device *pdev)
>  
>  	dma_async_device_register(&atdma->dma_common);
>  
> +	/*
> +	 * Do not return an error if the dmac node is not present in order to
> +	 * not break the existing way of requesting channel with
> +	 * dma_request_channel().
> +	 */
> +	if (pdev->dev.of_node) {
> +		err = of_dma_controller_register(pdev->dev.of_node,
> +						 at_dma_xlate, atdma);
> +		if (err) {
> +			dev_err(&pdev->dev, "could not register of_dma_controller\n");
> +			goto err_of_dma_controller_register;
> +		}
> +	}
> +
>  	return 0;
>  
> +err_of_dma_controller_register:
> +	dma_async_device_unregister(&atdma->dma_common);
> +	dma_pool_destroy(atdma->dma_desc_pool);
>  err_pool_create:
>  	platform_set_drvdata(pdev, NULL);
>  	free_irq(platform_get_irq(pdev, 0), atdma);
> diff --git a/drivers/dma/at_hdmac_regs.h b/drivers/dma/at_hdmac_regs.h
> index 0eb3c13..c604d26 100644
> --- a/drivers/dma/at_hdmac_regs.h
> +++ b/drivers/dma/at_hdmac_regs.h
> @@ -220,6 +220,8 @@ enum atc_status {
>   * @device: parent device
>   * @ch_regs: memory mapped register base
>   * @mask: channel index in a mask
> + * @per_if: peripheral interface
> + * @mem_if: memory interface
>   * @status: transmit status information from irq/prep* functions
>   *                to tasklet (use atomic operations)
>   * @tasklet: bottom half to finish transaction work
> @@ -238,6 +240,8 @@ struct at_dma_chan {
>  	struct at_dma		*device;
>  	void __iomem		*ch_regs;
>  	u8			mask;
> +	u8			per_if;
> +	u8			mem_if;
>  	unsigned long		status;
>  	struct tasklet_struct	tasklet;
>  	u32			save_cfg;
> 


-- 
Nicolas Ferre


From lee.jones at linaro.org  Thu Apr 18 07:00:09 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Thu, 18 Apr 2013 12:00:09 +0100
Subject: [PATCH 03/32] dmaengine: ste_dma40: Use the BIT macro to replace
 ugly '(1 << x)'s
In-Reply-To: <20130418104338.GM14496@n2100.arm.linux.org.uk>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-4-git-send-email-lee.jones@linaro.org>
 <20130418104338.GM14496@n2100.arm.linux.org.uk>
Message-ID: <20130418110009.GA27903@gmail.com>

On Thu, 18 Apr 2013, Russell King - ARM Linux wrote:

> On Thu, Apr 18, 2013 at 11:11:45AM +0100, Lee Jones wrote:
> > The aim is to make the code that little more readable.
> 
> Maybe we should also invent the MULT() macro too, because a * b is just
> too ugly as well?  Maybe ADD(), SUB() and DIV() macros as well...  Think
> of all those extra parens you could use! :)

Very amusing. :)

I just happen to like this macro.

It's more for tidiness than readability to be honest, but still.

> > @@ -1448,7 +1448,7 @@ static u32 d40_residue(struct d40_chan *d40c)
> >  			  >> D40_SREG_ELEM_PHY_ECNT_POS;
> >  	}
> >  
> > -	return num_elt * (1 << d40c->dma_cfg.dst_info.data_width);
> > +	return num_elt * BIT(d40c->dma_cfg.dst_info.data_width);
> 
> This should be:
> 	return num_elt << d40c->dma_cfg.dst_info.data_width;

Thanks. I'll fixup.

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From linux at arm.linux.org.uk  Thu Apr 18 07:00:24 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Thu, 18 Apr 2013 12:00:24 +0100
Subject: [PATCH 08/32] dmaengine: ste_dma40: Optimise local MAX() macro
In-Reply-To: <201304181246.03357.arnd@arndb.de>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-9-git-send-email-lee.jones@linaro.org>
 <201304181246.03357.arnd@arndb.de>
Message-ID: <20130418110024.GP14496@n2100.arm.linux.org.uk>

On Thu, Apr 18, 2013 at 12:46:03PM +0200, Arnd Bergmann wrote:
> On Thursday 18 April 2013, Lee Jones wrote:
> > The current implementation of the DMA40's local MAX() macro evaluates
> > its arguments more times than is necessary. This patch strips it
> > optimises it to only evaluate what's appropriate.
> 
> No, it does not.
> 
> > index b21a8a3..7b451b2 100644
> > --- a/drivers/dma/ste_dma40.c
> > +++ b/drivers/dma/ste_dma40.c
> > @@ -53,7 +53,7 @@
> >  #define D40_ALLOC_PHY          BIT(30)
> >  #define D40_ALLOC_LOG_FREE     BIT(0)
> >  
> > -#define MAX(a, b) (((a) < (b)) ? (b) : (a))
> > +#define MAX(a, b) ((a > b) ? a : b)
> 
> This just makes the macro worse in case you pass a complex expression
> in, which can now have additional unwanted effects. Just drop this patch.

Never got the original patch...

A much better idea is to get rid of that buggy MAX() macro altogether
and use the macros already provided by the kernel, which are safe from
side effects - but more importantly are _type_ _safe_.  The above goes
wrong when you consider 'a' and 'b' may have different signed-ness.

Consider:

	int val_in = -5;
	unsigned val = MAX(val_in, 5U);

The resulting value is (unsigned)-5, not (unsigned)5.

Best use the kernel's max() or max_t() _everywhere_.


From lee.jones at linaro.org  Thu Apr 18 07:01:24 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Thu, 18 Apr 2013 12:01:24 +0100
Subject: [PATCH 07/32] ARM: ux500: Supply address location names for the
 DMA40 DMA controller
In-Reply-To: <201304181248.36597.arnd@arndb.de>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-8-git-send-email-lee.jones@linaro.org>
 <201304181248.36597.arnd@arndb.de>
Message-ID: <20130418110124.GB27903@gmail.com>

On Thu, 18 Apr 2013, Arnd Bergmann wrote:

> On Thursday 18 April 2013, Lee Jones wrote:
> > The DMA40 controller uses two sets of base addresses. In order to have
> > them automatically setup as resources by the Open Format framework we
> > have to set names for them. The names have to be the same as the ones
> > used to fetch them back out of the resource structure.
> > 
> > Signed-off-by: Lee Jones <lee.jones at linaro.org>
> 
> Typo: s/Open Format/Open Firmware/
> 
> To be more specific, just write of_platform framework. Note that we
> still get resources without passing the names, they are just not
> named in that case and have to be retrieved by index.

Okay, I'll fixup.

> You should also document the strings in the binding document.

I'll do that, thanks.

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From arnd at arndb.de  Thu Apr 18 07:06:34 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 18 Apr 2013 13:06:34 +0200
Subject: [PATCH 24/32] dmaengine: ste_dma40: Supply full Device Tree
 parsing support
In-Reply-To: <1366279934-30761-25-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-25-git-send-email-lee.jones@linaro.org>
Message-ID: <201304181306.34835.arnd@arndb.de>

On Thursday 18 April 2013, Lee Jones wrote:
> Using the new DMA DT bindings and API, we can register the DMA40 driver
> as Device Tree capable. Now, when a client attempts to allocate a
> channel using the DMA DT bindings via its own node, we are able to parse
> the request and allocate a channel in the correct manor.

s/manor/manner/ ?

> +Optional properties:
> +- interrupt-parent: Should be the phandle for the interrupt controller
> +  that services interrupts for this device

I would not bother listing the interrupt-parent.

> +Clients
> +Required properties:
> +- dmas: Comma seperated list of dma channel requests
> +- dma-names: Names of the aforementioned requested channels
> +
> +Each dmas request consists of 4 cells:
> +  1. A phandle pointing to the DMA controller
> +  2. The DMA request line number (only when 'use fixed channel' is set)
> +  3. Device Type
> +  4. A 32bit mask specifying; mode, direction and endianess [NB: This list will grow]
> +        bits 1-2: Mode:
> +          00: Logical
> +          01: Physical
> +          10: Operation
> +          11: Undefined - will most likely return an error

The statement "will most likely return an error" is not very
specification-like. ;-) Maybe better call it "reserved".

What is actually an "Operation" channel? Do we need it for slaves?


> +        bits 3-4: Direction:
> +          00: Mem to Mem
> +          01: Mem to Dev
> +          10: Dev to Mem
> +          11: Dev to Dev

For slave channels, we only need mem-to-dev and dev-to-mem, so I would
use only one bit here.

> +        bit 5: Endianess:
> +           0: Little endian
> +           1: Big endian
> +        bit 6: Use fixed channel:
> +           0: Use automatic channel selection
> +           1: Use DMA request line number

I think you have mixed up the "device type" and "request line number".

The request line is what identifies the slave device (which you call
the device type), and I would put that number first.

	Arnd



From arnd at arndb.de  Thu Apr 18 07:07:38 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 18 Apr 2013 13:07:38 +0200
Subject: [PATCH 24/32] dmaengine: ste_dma40: Supply full Device Tree
 parsing support
In-Reply-To: <1366279934-30761-25-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-25-git-send-email-lee.jones@linaro.org>
Message-ID: <201304181307.39002.arnd@arndb.de>

On Thursday 18 April 2013, Lee Jones wrote:
> +               dma-channels = <0>; /* Zero means read from H/W. */

One more thing: I would not make this a magic value. Better make the property
optional and require it to be correct if present and autodetected if absent.

	Arnd


From arnd at arndb.de  Thu Apr 18 07:08:02 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 18 Apr 2013 13:08:02 +0200
Subject: [PATCH 25/32] ARM: ux500: Setup the DMA40 driver's DT node using
 the new DMA API
In-Reply-To: <1366279934-30761-26-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-26-git-send-email-lee.jones@linaro.org>
Message-ID: <201304181308.03130.arnd@arndb.de>

On Thursday 18 April 2013, Lee Jones wrote:
> The new DMA is now available, so let's use it to setup ST-Ericsson's
> DMA40 driver when Device Tree is enabled.
> 
> Signed-off-by: Lee Jones <lee.jones at linaro.org>

Acked-by: Arnd Bergmann <arnd at arndb.de>


From lee.jones at linaro.org  Thu Apr 18 07:09:18 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Thu, 18 Apr 2013 12:09:18 +0100
Subject: [PATCH 07/32] ARM: ux500: Supply address location names for the
 DMA40 DMA controller
In-Reply-To: <201304181248.36597.arnd@arndb.de>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-8-git-send-email-lee.jones@linaro.org>
 <201304181248.36597.arnd@arndb.de>
Message-ID: <20130418110918.GC27903@gmail.com>

On Thu, 18 Apr 2013, Arnd Bergmann wrote:

> On Thursday 18 April 2013, Lee Jones wrote:
> > The DMA40 controller uses two sets of base addresses. In order to have
> > them automatically setup as resources by the Open Format framework we
> > have to set names for them. The names have to be the same as the ones
> > used to fetch them back out of the resource structure.
> > 
> > Signed-off-by: Lee Jones <lee.jones at linaro.org>
> 
> Typo: s/Open Format/Open Firmware/
> 
> To be more specific, just write of_platform framework. Note that we
> still get resources without passing the names, they are just not
> named in that case and have to be retrieved by index.

Changed to:

The DMA40 controller uses two sets of base addresses. In order to have
the resources setup by the of_platform framework so they are searchable
by name instead of index, we have to set names for them. The names have
to be the same as the ones used to fetch them back out of the resource
structure.

> You should also document the strings in the binding document.

Done.

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From arnd at arndb.de  Thu Apr 18 07:11:21 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 18 Apr 2013 13:11:21 +0200
Subject: [PATCH 28/32] ARM: ux500: Pass remnant platform data though to
 DMA40 driver
In-Reply-To: <1366279934-30761-29-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-29-git-send-email-lee.jones@linaro.org>
Message-ID: <201304181311.21863.arnd@arndb.de>

On Thursday 18 April 2013, Lee Jones wrote:
> Ironically, in order to remove lots of the auxdata assignments, we have
> to add just one more. A lot of them require DMA information to be passed
> into clients for DMA channel allocation, but we now have this capability
> in Device Tree. However, the DMA40 driver still relies on a reverse table
> look-up to obtain DMA addresses. Until all of the clients are converted,
> over to the new API, we're stuck with this.
> 
> Signed-off-by: Lee Jones <lee.jones at linaro.org>

Acked-by: Arnd Bergmann <arnd at arndb.de>

but please fold this together with patch 27, since applying one without the
other breaks booting.

	Arnd


From jason at lakedaemon.net  Thu Apr 18 07:16:08 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Thu, 18 Apr 2013 07:16:08 -0400
Subject: [PATCH V3 2/2] ARM: Handle user space mapped pages in
 flush_kernel_dcache_page
In-Reply-To: <20121118211005.GW22106@titan.lakedaemon.net>
References: <1349609352-6408-1-git-send-email-gmbnomis@gmail.com>
 <1349609352-6408-3-git-send-email-gmbnomis@gmail.com>
 <20121008174428.GB3204@arm.com>
 <20121008200216.GA14167@schnuecks.de>
 <20121008202040.GC4625@n2100.arm.linux.org.uk>
 <20121008230733.GA17819@schnuecks.de>
 <20121118211005.GW22106@titan.lakedaemon.net>
Message-ID: <20130418111608.GF27197@titan.lakedaemon.net>

Russell, Catalin, Simon,

I'm digging through my 'onice' mail folder and found this.  I've
personally experienced this bug in the past (workaround: don't use LVM
on ARM systems :-( ).

Is there any interest in reviving this series?  I can dig up the patches
if needed.

thx,

Jason.


On Sun, Nov 18, 2012 at 04:10:05PM -0500, Jason Cooper wrote:
> Russell, Catalin, Simon,
> 
> Any progress on this?  At worst, I'd like to see this in fixes for v3.8.
> Assuming, of course, we've gotten to the bottom of it.


-- Here's the original thread:

> On Tue, Oct 09, 2012 at 01:07:34AM +0200, Simon Baatz wrote:
> > Hi Russell,
> > 
> > On Mon, Oct 08, 2012 at 09:20:40PM +0100, Russell King - ARM Linux wrote:
> > > On Mon, Oct 08, 2012 at 10:02:16PM +0200, Simon Baatz wrote:
> > > > Hi Catalin,
> > > > 
> > > > On Mon, Oct 08, 2012 at 06:44:28PM +0100, Catalin Marinas wrote:
> > > > > On Sun, Oct 07, 2012 at 12:29:12PM +0100, Simon Baatz wrote:
> > > > > > Commit f8b63c1 made flush_kernel_dcache_page() a no-op assuming that
> > > > > > the pages it needs to handle are kernel mapped only.  However, for
> > > > > > example when doing direct I/O, pages with user space mappings may
> > > > > > occur.
> > > > > > 
> > > > > > Thus, do lazy flushing like in flush_dcache_page() if there are no user
> > > > > > space mappings.  Otherwise, flush the kernel cache lines directly.
> > > > > 
> > > > > Do you need to fix the VIPT non-aliasing case as well? Does
> > > > > flush_kernel_dcache_page() need to handle I-cache?
> > > > 
> > > > Good question. My previous version of the patch did not handle it,
> > > > but after our discussion on the arm64 case, I came to the conclusion
> > > > that we probably need to handle it.
> > > > 
> > > > flush_dcache_page() and flush_kernel_dcache_page() are both used when
> > > > a page was modified via its kernel mapping.  For example,
> > > > crypto/scatterwalk.c uses flush_dcache_page() whereas
> > > > lib/scatterlist.c uses flush_kernel_dcache_page().  
> > > 
> > > It's likely that this stuff is incredibly buggy - and where we suspect
> > > there's problems (like using the wrong flush_dcache_page() vs
> > > flush_kernel_dcache_page() call) that needs to be fixed.
> > > 
> > > I suspect crypto/scatterwalk.c was created long before
> > > flush_kernel_dcache_page() came into existence, and it probably needs
> > > to be fixed.
> > >
> > > > Thus, the reasoning is that if flush_dcache_page() needs to handle
> > > > I-cache in the case there is no hook later (already user-mapped page
> > > > cache page) then flush_kernel_dcache_page() needs to do the same. 
> > > 
> > > This sounds like we're heading in the direction that flush_kernel_dcache_page()
> > > and flush_dcache_page() end up being virtually identical.  This isn't
> > > supposed to be - they _are_ supposed to be different.  Again, maybe
> > > that's because the users have chosen the wrong function.
> > > ...
> > 
> > Yes, it is a mess and may be incredibly buggy. 
> > 
> > According to documentation flush_kernel_dcache_page() is supposed to
> > handle user pages.  It can assume that potential user mappings have
> > been flushed.  However, the documentation does not mention the case
> > of page cache pages with no user mappings explicitly.
> > 
> > flush_dcache_page() is supposed to deal with the user and kernel
> > mappings. However, the documentation does explicitly state that it is
> > not supposed to handle anon pages (but the arm implementation does
> > flush the kernel mapping).
> > 
> > Now, what should crypto/scatterwalk.c do? In the write to page path,
> > it can see page cache pages with and without user mappings and anon
> > pages.  If there are user mappings, it can assume that they have been
> > flushed.  I would argue it should use flush_kernel_dcache_page(). 
> > But if so, our current implementation does not handle two of these
> > three cases at all.
> > 
> > And the proposed flush_kernel_dcache_page() is different. It only
> > flushes the kernel mapping in the relevant cases whereas
> > flush_dcache_page() needs to care about user mappings as well. 
> > According to documentation we could remove the anon page case in
> > flush_dcache_page(), but uses like in crypto/scatterwalk.c currently
> > prevent that.
> > 
> > > > With respect to clearing the flag in the VIPT non-aliasing case with
> > > > anon pages: Declaring the pages dirty by default may already be
> > > > sufficient in this case, at least that is what the current
> > > > implementation assumes.
> > > 
> > > PG_arch_1 has no meaning what so ever for anon pages.  Don't even try
> > > to make it have meaning there, it will cause lots of pain if you do.
> > > The reason is that anon pages have no mapping, and so trying to do the
> > > PG_arch_1 trick will result in most places deciding "there is no
> > > userspace mapping we can skip that".
> > 
> > Hmm, now that you say it, it's quite obvious. There is the following
> > in __sync_icache_dcache():
> > 
> >         if (cache_is_vipt_aliasing())
> >                 mapping = page_mapping(page);
> >         else
> >                 mapping = NULL;
> > 
> >         if (!test_and_set_bit(PG_dcache_clean, &page->flags))
> >                 __flush_dcache_page(mapping, page);
> > 
> >         if (pte_exec(pteval))
> >                 __flush_icache_all();
> > 
> > At least this looks strange to me given that PG_dcache_clean has no
> > meaning for anon pages.  Is this correct?
> > 
> > - Simon
> > 
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From arnd at arndb.de  Thu Apr 18 07:15:11 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 18 Apr 2013 13:15:11 +0200
Subject: [PATCH 1/6] at_hdmac: move to generic DMA binding
In-Reply-To: <516FD21E.7070807@atmel.com>
References: <1366117390-24686-1-git-send-email-ludovic.desroches@atmel.com>
 <1366117390-24686-2-git-send-email-ludovic.desroches@atmel.com>
 <516FD21E.7070807@atmel.com>
Message-ID: <201304181315.11212.arnd@arndb.de>

On Thursday 18 April 2013, Nicolas Ferre wrote:
> Arnd,
> Do you feel like giving your "Acked-by" to this patch? I think that you
> were pretty in line with Ludovic's RFC, so it may be interesting to have
> your support on this...

Yes, it's fine.

Acked-by: Arnd Bergmann <arnd at arndb.de>


From arnd at arndb.de  Thu Apr 18 07:19:49 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 18 Apr 2013 13:19:49 +0200
Subject: [PATCH 08/32] dmaengine: ste_dma40: Optimise local MAX() macro
In-Reply-To: <20130418110024.GP14496@n2100.arm.linux.org.uk>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <201304181246.03357.arnd@arndb.de>
 <20130418110024.GP14496@n2100.arm.linux.org.uk>
Message-ID: <201304181319.49737.arnd@arndb.de>

On Thursday 18 April 2013, Russell King - ARM Linux wrote:
> Never got the original patch...
> 
> A much better idea is to get rid of that buggy MAX() macro altogether
> and use the macros already provided by the kernel, which are safe from
> side effects - but more importantly are type _safe_.  The above goes
> wrong when you consider 'a' and 'b' may have different signed-ness.

Yes, that's what was suggested before.

> Consider:
> 
>         int val_in = -5;
>         unsigned val = MAX(val_in, 5U);
> 
> The resulting value is (unsigned)-5, not (unsigned)5.
> 
> Best use the kernel's max() or max_t() _everywhere_.

Unfortunately, the (only) use of this macro is in a structure declaration
where you cannot use the syntax of max():

struct d40_base {
	...
        u32    reg_val_backup_v4[MAX(BACKUP_REGS_SZ_V4A, BACKUP_REGS_SZ_V4B)];
	...
};

My preferred solution would be to remove the MAX macro here and
define a new constant

#define BACKUP_REGS_SZ ((BACKUP_REGS_SZ_V4A > BACKUP_REGS_SZ_V4B) ? \
			 BACKUP_REGS_SZ_V4A : BACKUP_REGS_SZ_V4B)

But I don't see it as much of an improvement over what is currently
there.

	Arnd


From linux at arm.linux.org.uk  Thu Apr 18 07:22:01 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Thu, 18 Apr 2013 12:22:01 +0100
Subject: [PATCH V3 2/2] ARM: Handle user space mapped pages in
 flush_kernel_dcache_page
In-Reply-To: <20130418111608.GF27197@titan.lakedaemon.net>
References: <1349609352-6408-1-git-send-email-gmbnomis@gmail.com>
 <1349609352-6408-3-git-send-email-gmbnomis@gmail.com>
 <20121008174428.GB3204@arm.com> <20121008200216.GA14167@schnuecks.de>
 <20121008202040.GC4625@n2100.arm.linux.org.uk>
 <20121008230733.GA17819@schnuecks.de>
 <20121118211005.GW22106@titan.lakedaemon.net>
 <20130418111608.GF27197@titan.lakedaemon.net>
Message-ID: <20130418112201.GQ14496@n2100.arm.linux.org.uk>

On Thu, Apr 18, 2013 at 07:16:08AM -0400, Jason Cooper wrote:
> Russell, Catalin, Simon,
> 
> I'm digging through my 'onice' mail folder and found this.  I've
> personally experienced this bug in the past (workaround: don't use LVM
> on ARM systems :-( ).
> 
> Is there any interest in reviving this series?  I can dig up the patches
> if needed.

None what so ever.  flush_kernel_dcache_page() is not supposed to touch
userspace pages.

  void flush_kernel_dcache_page(struct page *page)
        When the kernel needs to modify a user page is has obtained
        with kmap, it calls this function after all modifications are
        complete (but before kunmapping it) to bring the underlying
        page up to date.  It is assumed here that the user has no
                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        incoherent cached copies (i.e. the original page was obtained
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        from a mechanism like get_user_pages()).  The default
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        implementation is a nop and should remain so on all coherent
        architectures.  On incoherent architectures, this should flush
                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        the kernel cache for page (using page_address(page)).
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

The first underlined sentence means that it's assumed that something _else_
has already dealt with the userspace aliases (in other words, get_user_pages()
via flush_dcache_page() or flush_anon_page()).  The second is absolutely
clear that _only_ the kernel side should be flushed.

flush_kernel_dcache_page() was invented explicitly to separate out the
kernel side flushing from flush_dcache_page(), as a lighter weight version
for block drivers to use.

Also see the commit text, which explicitly states that this is a lighter
weight API, and that this _only_ touches the kernel view of the page:

commit 5a3a5a98b6422d05c39eaa32c8b3f83840c7b768
Author: James Bottomley <James.Bottomley at SteelEye.com>
Date:   Sun Mar 26 01:36:59 2006 -0800

    [PATCH] Add flush_kernel_dcache_page() API

    We have a problem in a lot of emulated storage in that it takes a page from
    get_user_pages() and does something like

    kmap_atomic(page)
    modify page
    kunmap_atomic(page)

    However, nothing has flushed the kernel cache view of the page before the
    kunmap.  We need a lightweight API to do this, so this new API would
    specifically be for flushing the kernel cache view of a user page which the
    kernel has modified.  The driver would need to add
    flush_kernel_dcache_page(page) before the final kunmap.

    Signed-off-by: James Bottomley <James.Bottomley at SteelEye.com>
    Cc: Russell King <rmk at arm.linux.org.uk>
    Cc: "David S. Miller" <davem at davemloft.net>
    Signed-off-by: Andrew Morton <akpm at osdl.org>
    Signed-off-by: Linus Torvalds <torvalds at osdl.org>


From lee.jones at linaro.org  Thu Apr 18 07:31:38 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Thu, 18 Apr 2013 12:31:38 +0100
Subject: [PATCH 24/32] dmaengine: ste_dma40: Supply full Device Tree
 parsing support
In-Reply-To: <201304181306.34835.arnd@arndb.de>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-25-git-send-email-lee.jones@linaro.org>
 <201304181306.34835.arnd@arndb.de>
Message-ID: <20130418113138.GD27903@gmail.com>

On Thu, 18 Apr 2013, Arnd Bergmann wrote:

> On Thursday 18 April 2013, Lee Jones wrote:
> > Using the new DMA DT bindings and API, we can register the DMA40 driver
> > as Device Tree capable. Now, when a client attempts to allocate a
> > channel using the DMA DT bindings via its own node, we are able to parse
> > the request and allocate a channel in the correct manor.
> 
> s/manor/manner/ ?
> 
> > +Optional properties:
> > +- interrupt-parent: Should be the phandle for the interrupt controller
> > +  that services interrupts for this device
> 
> I would not bother listing the interrupt-parent.
> 
> > +Clients
> > +Required properties:
> > +- dmas: Comma seperated list of dma channel requests
> > +- dma-names: Names of the aforementioned requested channels
> > +
> > +Each dmas request consists of 4 cells:
> > +  1. A phandle pointing to the DMA controller
> > +  2. The DMA request line number (only when 'use fixed channel' is set)
> > +  3. Device Type
> > +  4. A 32bit mask specifying; mode, direction and endianess [NB: This list will grow]
> > +        bits 1-2: Mode:
> > +          00: Logical
> > +          01: Physical
> > +          10: Operation
> > +          11: Undefined - will most likely return an error
> 
> The statement "will most likely return an error" is not very
> specification-like. ;-) Maybe better call it "reserved".

Actually, I wrote this before I wrote the code.

It definitely does return an error. :)

I'll fixup as you requested anyway.

> What is actually an "Operation" channel? Do we need it for slaves?

No idea. It was in the header file, so I thought I'd better reserve a
bit for it early in case it comes in handy later. 

> > +        bits 3-4: Direction:
> > +          00: Mem to Mem
> > +          01: Mem to Dev
> > +          10: Dev to Mem
> > +          11: Dev to Dev
> 
> For slave channels, we only need mem-to-dev and dev-to-mem, so I would
> use only one bit here.

Okay.

> > +        bit 5: Endianess:
> > +           0: Little endian
> > +           1: Big endian
> > +        bit 6: Use fixed channel:
> > +           0: Use automatic channel selection
> > +           1: Use DMA request line number
> 
> I think you have mixed up the "device type" and "request line number".
> 
> The request line is what identifies the slave device (which you call
> the device type)

You're right, I am a little confused by them.

I call them 'device type' because that's what they're called already.
Grep for 'dma_dev_type'. This is the number which gets split into
event group and line, like this:

	event_group = D40_TYPE_TO_GROUP(dev_type);
	event_line = D40_TYPE_TO_EVENT(dev_type);

> and I would put that number first.

So you want me to switch that round so it looks like:

	dmas = <<phandle> <dev_type> <fixed_chan> <flags>;

Instead of what I have at the moment:

	dmas = <<phandle> <fixed_chan> <dev_type> <flags>;

Correct?

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From arnd at arndb.de  Thu Apr 18 07:37:32 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 18 Apr 2013 13:37:32 +0200
Subject: [PATCH 24/32] dmaengine: ste_dma40: Supply full Device Tree
 parsing support
In-Reply-To: <20130418113138.GD27903@gmail.com>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <201304181306.34835.arnd@arndb.de> <20130418113138.GD27903@gmail.com>
Message-ID: <201304181337.32700.arnd@arndb.de>

On Thursday 18 April 2013, Lee Jones wrote:
> You're right, I am a little confused by them.
> 
> I call them 'device type' because that's what they're called already.
> Grep for 'dma_dev_type'. This is the number which gets split into
> event group and line, like this:
> 
>         event_group = D40_TYPE_TO_GROUP(dev_type);
>         event_line = D40_TYPE_TO_EVENT(dev_type);
> 
> > and I would put that number first.
> 
> So you want me to switch that round so it looks like:
> 
>         dmas = <<phandle> <dev_type> <fixed_chan> <flags>;
> 
> Instead of what I have at the moment:
> 
>         dmas = <<phandle> <fixed_chan> <dev_type> <flags>;
> 
> Correct?

Yes, that's probably better and more in line with what the other
drivers do. You could also put the fixed_chan last if that helps.

I would still like to get a confirmation that we actually still
require the fixed channel assignment, since it's just used
in one driver, and that might only be needed for some buggy
hardware revision if we're lucky.

	Arnd


From jason at lakedaemon.net  Thu Apr 18 07:40:16 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Thu, 18 Apr 2013 07:40:16 -0400
Subject: [PATCH V3 2/2] ARM: Handle user space mapped pages in
 flush_kernel_dcache_page
In-Reply-To: <20130418112201.GQ14496@n2100.arm.linux.org.uk>
References: <1349609352-6408-1-git-send-email-gmbnomis@gmail.com>
 <1349609352-6408-3-git-send-email-gmbnomis@gmail.com>
 <20121008174428.GB3204@arm.com>
 <20121008200216.GA14167@schnuecks.de>
 <20121008202040.GC4625@n2100.arm.linux.org.uk>
 <20121008230733.GA17819@schnuecks.de>
 <20121118211005.GW22106@titan.lakedaemon.net>
 <20130418111608.GF27197@titan.lakedaemon.net>
 <20130418112201.GQ14496@n2100.arm.linux.org.uk>
Message-ID: <20130418114016.GG27197@titan.lakedaemon.net>

On Thu, Apr 18, 2013 at 12:22:01PM +0100, Russell King - ARM Linux wrote:
> On Thu, Apr 18, 2013 at 07:16:08AM -0400, Jason Cooper wrote:
> > Russell, Catalin, Simon,
> > 
> > I'm digging through my 'onice' mail folder and found this.  I've
> > personally experienced this bug in the past (workaround: don't use LVM
> > on ARM systems :-( ).
> > 
> > Is there any interest in reviving this series?  I can dig up the patches
> > if needed.
> 
> None what so ever.  flush_kernel_dcache_page() is not supposed to touch
> userspace pages.
> 
>   void flush_kernel_dcache_page(struct page *page)
>         When the kernel needs to modify a user page is has obtained
>         with kmap, it calls this function after all modifications are
>         complete (but before kunmapping it) to bring the underlying
>         page up to date.  It is assumed here that the user has no
>                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>         incoherent cached copies (i.e. the original page was obtained
>         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>         from a mechanism like get_user_pages()).  The default
>         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>         implementation is a nop and should remain so on all coherent
>         architectures.  On incoherent architectures, this should flush
>                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>         the kernel cache for page (using page_address(page)).
>         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> The first underlined sentence means that it's assumed that something _else_
> has already dealt with the userspace aliases (in other words, get_user_pages()
> via flush_dcache_page() or flush_anon_page()).  The second is absolutely
> clear that _only_ the kernel side should be flushed.
> 
> flush_kernel_dcache_page() was invented explicitly to separate out the
> kernel side flushing from flush_dcache_page(), as a lighter weight version
> for block drivers to use.
> 
> Also see the commit text, which explicitly states that this is a lighter
> weight API, and that this _only_ touches the kernel view of the page:
> 
> commit 5a3a5a98b6422d05c39eaa32c8b3f83840c7b768
> Author: James Bottomley <James.Bottomley at SteelEye.com>
> Date:   Sun Mar 26 01:36:59 2006 -0800
> 
>     [PATCH] Add flush_kernel_dcache_page() API
> 
>     We have a problem in a lot of emulated storage in that it takes a page from
>     get_user_pages() and does something like
> 
>     kmap_atomic(page)
>     modify page
>     kunmap_atomic(page)
> 
>     However, nothing has flushed the kernel cache view of the page before the
>     kunmap.  We need a lightweight API to do this, so this new API would
>     specifically be for flushing the kernel cache view of a user page which the
>     kernel has modified.  The driver would need to add
>     flush_kernel_dcache_page(page) before the final kunmap.
> 
>     Signed-off-by: James Bottomley <James.Bottomley at SteelEye.com>
>     Cc: Russell King <rmk at arm.linux.org.uk>
>     Cc: "David S. Miller" <davem at davemloft.net>
>     Signed-off-by: Andrew Morton <akpm at osdl.org>
>     Signed-off-by: Linus Torvalds <torvalds at osdl.org>

Ok, got it.  I should have been more explicit.  LVM doesn't work on ARM.
iirc, Simon had a demo of dm-crypt also faulting on ARM.  This patch was
not the correct approach.  Is there an interest (particularly Simon) in
fixing the problem?

I'm willing to take a look at it, but LVM on ARM is a "nice to have" for
me, not a critical need.  The job would be easier if Simon was willing
to assist and lend his experience with the issue.

thx,

Jason.


From rogerq at ti.com  Thu Apr 18 07:44:33 2013
From: rogerq at ti.com (Roger Quadros)
Date: Thu, 18 Apr 2013 14:44:33 +0300
Subject: [PATCH v2 1/2] ARM: dts: omap3-beagle-xm: Add USB Host support
Message-ID: <1366285474-19967-1-git-send-email-rogerq@ti.com>

Provide RESET and Power regulators for the USB PHY,
the USB Host port mode and the PHY device.

Also provide pin multiplexer information for USB host
pins.

CC: Beno?t Cousson <b-cousson at ti.com>
Signed-off-by: Roger Quadros <rogerq at ti.com>
---
 arch/arm/boot/dts/omap3-beagle-xm.dts |   61 +++++++++++++++++++++++++++++++++
 1 files changed, 61 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts b/arch/arm/boot/dts/omap3-beagle-xm.dts
index 5a31964..04376a6 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -57,6 +57,59 @@
 		ti,mcbsp = <&mcbsp2>;
 		ti,codec = <&twl_audio>;
 	};
+
+	/* HS USB Port 2 RESET */
+	hsusb2_reset: hsusb2_reset_reg {
+		compatible = "regulator-fixed";
+		regulator-name = "hsusb2_reset";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		gpio = <&gpio5 19 0>;	/* gpio_147 */
+		startup-delay-us = <70000>;
+		enable-active-high;
+	};
+
+	/* HS USB Port 2 Power */
+	hsusb2_power: hsusb2_power_reg {
+		compatible = "regulator-fixed";
+		regulator-name = "hsusb2_vbus";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		gpio = <&twl_gpio 18 0>;	/* GPIO LEDA */
+		startup-delay-us = <70000>;
+	};
+
+	/* HS USB Host PHY on PORT 2 */
+	hsusb2_phy: hsusb2_phy {
+		compatible = "usb-nop-xceiv";
+		reset-supply = <&hsusb2_reset>;
+		vcc-supply = <&hsusb2_power>;
+	};
+
+};
+
+&omap3_pmx_core {
+	pinctrl-names = "default";
+	pinctrl-0 = <
+			&hsusbb2_pins
+	>;
+
+	hsusbb2_pins: pinmux_hsusbb2_pins {
+		pinctrl-single,pins = <
+			0x5c0 0x3  /* USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_clk OUTPUT */
+			0x5c2 0x3  /* USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_stp OUTPUT */
+			0x5c4 0x10b  /* USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dir INPUT | PULLDOWN */
+			0x5c6 0x10b  /* USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_nxt INPUT | PULLDOWN */
+			0x5c8 0x10b  /* USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat0 INPUT | PULLDOWN */
+			0x5cA 0x10b  /* USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat1 INPUT | PULLDOWN */
+			0x1a4 0x10b  /* USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat2 INPUT | PULLDOWN */
+			0x1a6 0x10b  /* USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat3 INPUT | PULLDOWN */
+			0x1a8 0x10b  /* USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat4 INPUT | PULLDOWN */
+			0x1aa 0x10b  /* USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat5 INPUT | PULLDOWN */
+			0x1ac 0x10b  /* USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat6 INPUT | PULLDOWN */
+			0x1ae 0x10b  /* USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat7 INPUT | PULLDOWN */
+		>;
+	};
 };
 
 &i2c1 {
@@ -125,3 +178,11 @@
 	mode = <3>;
 	power = <50>;
 };
+
+&usbhshost {
+	port2-mode = "ehci-phy";
+};
+
+&usbhsehci {
+	phys = <0 &hsusb2_phy>;
+};
-- 
1.7.4.1



From rogerq at ti.com  Thu Apr 18 07:44:34 2013
From: rogerq at ti.com (Roger Quadros)
Date: Thu, 18 Apr 2013 14:44:34 +0300
Subject: [PATCH v2 2/2] ARM: dts: omap3-beagle-xm: Add USB host supprot for
 Rev. Ax/Bx
In-Reply-To: <1366285474-19967-1-git-send-email-rogerq@ti.com>
References: <1366285474-19967-1-git-send-email-rogerq@ti.com>
Message-ID: <1366285474-19967-2-git-send-email-rogerq@ti.com>

Rev. Ax/Bx boards have reversed polarity for USBHOST_PWR_ENable
signal when compared to Rev. C boards.

We create a new dts file for Ax/Bx boards.

Also update model and compatible flags for Rev. C board.

CC: Beno?t Cousson <b-cousson at ti.com>
Signed-off-by: Roger Quadros <rogerq at ti.com>
---
 arch/arm/boot/dts/omap3-beagle-xm-ab.dts |   19 +++++++++++++++++++
 arch/arm/boot/dts/omap3-beagle-xm.dts    |    4 ++--
 2 files changed, 21 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm/boot/dts/omap3-beagle-xm-ab.dts

diff --git a/arch/arm/boot/dts/omap3-beagle-xm-ab.dts b/arch/arm/boot/dts/omap3-beagle-xm-ab.dts
new file mode 100644
index 0000000..041b40e
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-beagle-xm-ab.dts
@@ -0,0 +1,19 @@
+/*
+ * Copyright (C) 2013 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/ "omap3-beagle-xm.dts"
+
+/ {
+        model = "TI OMAP3 BeagleBoard xM Rev: Ax/Bx";
+        compatible = "ti,omap3-beagle-xm-ab", "ti,omap3-beagle", "ti,omap3";
+};
+
+/* On Rev A/B USBHOST_PWR_EN is active high */
+&hsusb2_power {
+	enable-active-high;
+};
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts b/arch/arm/boot/dts/omap3-beagle-xm.dts
index 04376a6..8a46dc5 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -10,8 +10,8 @@
 /include/ "omap36xx.dtsi"
 
 / {
-	model = "TI OMAP3 BeagleBoard xM";
-	compatible = "ti,omap3-beagle-xm, ti,omap3-beagle", "ti,omap3";
+	model = "TI OMAP3 BeagleBoard xM Rev: C";
+	compatible = "ti,omap3-beagle-xm-c", "ti,omap3-beagle", "ti,omap3";
 
 	cpus {
 		cpu at 0 {
-- 
1.7.4.1



From lee.jones at linaro.org  Thu Apr 18 07:47:56 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Thu, 18 Apr 2013 12:47:56 +0100
Subject: [PATCH 24/32] dmaengine: ste_dma40: Supply full Device Tree
 parsing support
In-Reply-To: <201304181337.32700.arnd@arndb.de>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <201304181306.34835.arnd@arndb.de>
 <20130418113138.GD27903@gmail.com>
 <201304181337.32700.arnd@arndb.de>
Message-ID: <20130418114756.GE27903@gmail.com>

On Thu, 18 Apr 2013, Arnd Bergmann wrote:

> On Thursday 18 April 2013, Lee Jones wrote:
> > You're right, I am a little confused by them.
> > 
> > I call them 'device type' because that's what they're called already.
> > Grep for 'dma_dev_type'. This is the number which gets split into
> > event group and line, like this:
> > 
> >         event_group = D40_TYPE_TO_GROUP(dev_type);
> >         event_line = D40_TYPE_TO_EVENT(dev_type);
> > 
> > > and I would put that number first.
> > 
> > So you want me to switch that round so it looks like:
> > 
> >         dmas = <<phandle> <dev_type> <fixed_chan> <flags>;
> > 
> > Instead of what I have at the moment:
> > 
> >         dmas = <<phandle> <fixed_chan> <dev_type> <flags>;
> > 
> > Correct?
> 
> Yes, that's probably better and more in line with what the other
> drivers do. You could also put the fixed_chan last if that helps.

I'd rather keep the flags as the final cell if it's all the same to you?

> I would still like to get a confirmation that we actually still
> require the fixed channel assignment, since it's just used
> in one driver, and that might only be needed for some buggy
> hardware revision if we're lucky.

Unfortunately not:

`git grep "\.use_fixed_channel" <internal_kernel> | grep true | wc -l`
8

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From lee.jones at linaro.org  Thu Apr 18 08:12:53 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Thu, 18 Apr 2013 13:12:53 +0100
Subject: [PATCH 24/32 v2] dmaengine: ste_dma40: Supply full Device Tree
 parsing support
In-Reply-To: <1366279934-30761-25-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-25-git-send-email-lee.jones@linaro.org>
Message-ID: <20130418121253.GF27903@gmail.com>

Using the new DMA DT bindings and API, we can register the DMA40 driver
as Device Tree capable. Now, when a client attempts to allocate a
channel using the DMA DT bindings via its own node, we are able to parse
the request and allocate a channel in the correct manner.

Cc: Vinod Koul <vinod.koul at intel.com>
Cc: Dan Williams <djbw at fb.com>
Cc: Per Forlin <per.forlin at stericsson.com>
Cc: Rabin Vincent <rabin at rab.in>
Signed-off-by: Lee Jones <lee.jones at linaro.org>

diff --git a/Documentation/devicetree/bindings/dma/ste-dma40.txt b/Documentation/devicetree/bindings/dma/ste-dma40.txt
new file mode 100644
index 0000000..0aca55f
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/ste-dma40.txt
@@ -0,0 +1,62 @@
+* DMA40 DMA Controller
+
+Required properties:
+- compatible: "stericsson,dma40"
+- reg: Address range of the DMAC registers
+- reg-names: Names of the above areas to use during resource look-up
+- interrupt: Should contain the DMAC interrupt number
+- #dma-cells: must be <3>
+
+Optional properties:
+- dma-channels: Number of channels supported by hardware - if not present
+		the driver will attempt to obtain the information from H/W
+
+Example:
+
+	dma: dma-controller at 801C0000 {
+		compatible = "stericsson,db8500-dma40", "stericsson,dma40";
+		reg = <0x801C0000 0x1000  0x40010000 0x800>;
+		reg-names = "base", "lcpa";
+		interrupt-parent = <&intc>;
+		interrupts = <0 25 0x4>;
+
+		#dma-cells = <2>;
+		dma-channels = <8>;
+	};
+
+Clients
+Required properties:
+- dmas: Comma separated list of dma channel requests
+- dma-names: Names of the aforementioned requested channels
+
+Each dmas request consists of 4 cells:
+  1. A phandle pointing to the DMA controller
+  2. Device Type
+  3. The DMA request line number (only when 'use fixed channel' is set)
+  4. A 32bit mask specifying; mode, direction and endianess [NB: This list will grow]
+        bit 1: Mode:
+           0: Logical
+           1: Physical
+        bit 2: Direction:
+           0: Mem to Mem
+           1: Mem to Dev
+        bit 3: Endianess:
+           0: Little endian
+           1: Big endian
+        bit 4: Use fixed channel:
+           0: Use automatic channel selection
+           1: Use DMA request line number
+
+Example:
+
+	uart at 80120000 {
+		compatible = "arm,pl011", "arm,primecell";
+		reg = <0x80120000 0x1000>;
+		interrupts = <0 11 0x4>;
+
+		dmas = <&dma 13 0 0x8>, /* Logical - DevToMem */
+		       <&dma 13 0 0x4>; /* Logical - MemToDev */
+		dma-names = "rx", "rx";
+
+		status = "disabled";
+	};
diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index c70660d..f551b27 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -18,6 +18,7 @@
 #include <linux/pm_runtime.h>
 #include <linux/err.h>
 #include <linux/of.h>
+#include <linux/of_dma.h>
 #include <linux/amba/bus.h>
 #include <linux/regulator/consumer.h>
 #include <linux/platform_data/dma-ste-dma40.h>
@@ -2409,6 +2410,53 @@ static void d40_set_prio_realtime(struct d40_chan *d40c)
 		__d40_set_prio_rt(d40c, d40c->dma_cfg.dev_type, false);
 }
 
+#define D40_DT_FLAGS_MODE(flags)       ((flags >> 0) & 0x1)
+#define D40_DT_FLAGS_DIR(flags)        ((flags >> 1) & 0x1)
+#define D40_DT_FLAGS_BIG_ENDIAN(flags) ((flags >> 2) & 0x1)
+#define D40_DT_FLAGS_FIXED_CHAN(flags) ((flags >> 3) & 0x1)
+
+static struct dma_chan *d40_xlate(struct of_phandle_args *dma_spec,
+				  struct of_dma *ofdma)
+{
+	struct stedma40_chan_cfg cfg;
+	dma_cap_mask_t cap;
+	u32 flags;
+
+	memset(&cfg, 0, sizeof(struct stedma40_chan_cfg));
+
+	dma_cap_zero(cap);
+	dma_cap_set(DMA_SLAVE, cap);
+
+	cfg.dev_type = dma_spec->args[0];
+	flags = dma_spec->args[2];
+
+	switch (D40_DT_FLAGS_MODE(flags)) {
+	case 0: cfg.mode = STEDMA40_MODE_LOGICAL; break;
+	case 1: cfg.mode = STEDMA40_MODE_PHYSICAL; break;
+	default:
+		pr_err("dma40: Unknown mode read from DT (%d)\n",
+		       D40_DT_FLAGS_MODE(flags));
+		return NULL;
+	}
+
+	switch (D40_DT_FLAGS_DIR(flags)) {
+	case 0: cfg.dir = STEDMA40_MEM_TO_MEM; break;
+	case 1: cfg.dir = STEDMA40_MEM_TO_PERIPH; break;
+	}
+
+	if (cfg.dir == STEDMA40_PERIPH_TO_MEM)
+		cfg.src_info.big_endian = D40_DT_FLAGS_BIG_ENDIAN(flags);
+	if (cfg.dir == STEDMA40_MEM_TO_PERIPH)
+		cfg.dst_info.big_endian = D40_DT_FLAGS_BIG_ENDIAN(flags);
+
+	if (D40_DT_FLAGS_FIXED_CHAN(flags)) {
+		cfg.phy_channel = dma_spec->args[1];
+		cfg.use_fixed_channel = true;
+	}
+
+	return dma_request_channel(cap, stedma40_filter, &cfg);
+}
+
 /* DMA ENGINE functions */
 static int d40_alloc_chan_resources(struct dma_chan *chan)
 {
@@ -3615,6 +3663,13 @@ static int __init d40_probe(struct platform_device *pdev)
 
 	d40_hw_init(base);
 
+	if (np) {
+		err = of_dma_controller_register(np, d40_xlate, NULL);
+		if (err && err != -ENODEV)
+			dev_err(&pdev->dev,
+				"could not register of_dma_controller\n");
+	}
+
 	dev_info(base->dev, "initialized\n");
 	return 0;


From lee.jones at linaro.org  Thu Apr 18 08:16:37 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Thu, 18 Apr 2013 13:16:37 +0100
Subject: [PATCH 03/32 v2] dmaengine: ste_dma40: Use the BIT macro to replace
 ugly '(1 << x)'s
In-Reply-To: <1366279934-30761-4-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-4-git-send-email-lee.jones@linaro.org>
Message-ID: <20130418121637.GG27903@gmail.com>

The aim is to make the code that little more readable.

Cc: Vinod Koul <vinod.koul at intel.com>
Cc: Dan Williams <djbw at fb.com>
Cc: Per Forlin <per.forlin at stericsson.com>
Cc: Rabin Vincent <rabin at rab.in>
Acked-by: Arnd Bergmann <arnd at arndb.de>
Signed-off-by: Lee Jones <lee.jones at linaro.org>

diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index 3b83dee..ddf5ff1 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -49,9 +49,9 @@
 #define MAX_LCLA_ALLOC_ATTEMPTS 256
 
 /* Bit markings for allocation map */
-#define D40_ALLOC_FREE		(1 << 31)
-#define D40_ALLOC_PHY		(1 << 30)
-#define D40_ALLOC_LOG_FREE	0
+#define D40_ALLOC_FREE		BIT(31)
+#define D40_ALLOC_PHY		BIT(30)
+#define D40_ALLOC_LOG_FREE	BIT(0)
 
 #define MAX(a, b) (((a) < (b)) ? (b) : (a))
 
@@ -993,12 +993,12 @@ static int d40_size_2_dmalen(int size, u32 data_width1, u32 data_width2)
 	int dmalen;
 	u32 max_w = max(data_width1, data_width2);
 	u32 min_w = min(data_width1, data_width2);
-	u32 seg_max = ALIGN(STEDMA40_MAX_SEG_SIZE << min_w, 1 << max_w);
+	u32 seg_max = ALIGN(STEDMA40_MAX_SEG_SIZE << min_w, BIT(max_w));
 
 	if (seg_max > STEDMA40_MAX_SEG_SIZE)
-		seg_max -= (1 << max_w);
+		seg_max -= BIT(max_w);
 
-	if (!IS_ALIGNED(size, 1 << max_w))
+	if (!IS_ALIGNED(size, BIT(max_w)))
 		return -EINVAL;
 
 	if (size <= seg_max)
@@ -1448,7 +1448,7 @@ static u32 d40_residue(struct d40_chan *d40c)
 			  >> D40_SREG_ELEM_PHY_ECNT_POS;
 	}
 
-	return num_elt * (1 << d40c->dma_cfg.dst_info.data_width);
+	return num_elt << d40c->dma_cfg.dst_info.data_width;
 }
 
 static bool d40_tx_is_linked(struct d40_chan *d40c)
@@ -1722,7 +1722,7 @@ static irqreturn_t d40_handle_interrupt(int irq, void *data)
 		}
 
 		/* ACK interrupt */
-		writel(1 << idx, base->virtbase + il[row].clr);
+		writel(BIT(idx), base->virtbase + il[row].clr);
 
 		spin_lock(&d40c->lock);
 
@@ -1804,9 +1804,9 @@ static int d40_validate_conf(struct d40_chan *d40c,
 	}
 
 	if (d40_psize_2_burst_size(is_log, conf->src_info.psize) *
-	    (1 << conf->src_info.data_width) !=
+	    BIT(conf->src_info.data_width) !=
 	    d40_psize_2_burst_size(is_log, conf->dst_info.psize) *
-	    (1 << conf->dst_info.data_width)) {
+	    BIT(conf->dst_info.data_width)) {
 		/*
 		 * The DMAC hardware only supports
 		 * src (burst x width) == dst (burst x width)
@@ -1848,8 +1848,8 @@ static bool d40_alloc_mask_set(struct d40_phy_res *phy,
 		if (phy->allocated_src == D40_ALLOC_FREE)
 			phy->allocated_src = D40_ALLOC_LOG_FREE;
 
-		if (!(phy->allocated_src & (1 << log_event_line))) {
-			phy->allocated_src |= 1 << log_event_line;
+		if (!(phy->allocated_src & BIT(log_event_line))) {
+			phy->allocated_src |= BIT(log_event_line);
 			goto found;
 		} else
 			goto not_found;
@@ -1860,8 +1860,8 @@ static bool d40_alloc_mask_set(struct d40_phy_res *phy,
 		if (phy->allocated_dst == D40_ALLOC_FREE)
 			phy->allocated_dst = D40_ALLOC_LOG_FREE;
 
-		if (!(phy->allocated_dst & (1 << log_event_line))) {
-			phy->allocated_dst |= 1 << log_event_line;
+		if (!(phy->allocated_dst & BIT(log_event_line))) {
+			phy->allocated_dst |= BIT(log_event_line);
 			goto found;
 		} else
 			goto not_found;
@@ -1891,11 +1891,11 @@ static bool d40_alloc_mask_free(struct d40_phy_res *phy, bool is_src,
 
 	/* Logical channel */
 	if (is_src) {
-		phy->allocated_src &= ~(1 << log_event_line);
+		phy->allocated_src &= ~BIT(log_event_line);
 		if (phy->allocated_src == D40_ALLOC_LOG_FREE)
 			phy->allocated_src = D40_ALLOC_FREE;
 	} else {
-		phy->allocated_dst &= ~(1 << log_event_line);
+		phy->allocated_dst &= ~BIT(log_event_line);
 		if (phy->allocated_dst == D40_ALLOC_LOG_FREE)
 			phy->allocated_dst = D40_ALLOC_FREE;
 	}
@@ -2394,7 +2394,7 @@ static void __d40_set_prio_rt(struct d40_chan *d40c, int dev_type, bool src)
 	u32 rtreg;
 	u32 event = D40_TYPE_TO_EVENT(dev_type);
 	u32 group = D40_TYPE_TO_GROUP(dev_type);
-	u32 bit = 1 << event;
+	u32 bit = BIT(event);
 	u32 prioreg;
 	struct d40_gen_dmac *dmac = &d40c->base->gen_dmac;


From martinez.javier at gmail.com  Thu Apr 18 08:17:32 2013
From: martinez.javier at gmail.com (Javier Martinez Canillas)
Date: Thu, 18 Apr 2013 14:17:32 +0200
Subject: [PATCH 1/1] of/irq: store IRQ trigger/level in struct resource
 flags
In-Reply-To: <516380D7.3060000@gmail.com>
References: <1365148088-11175-1-git-send-email-javier.martinez@collabora.co.uk>
 <51633F26.7000400@gmail.com> <516341AF.7030207@wwwdotorg.org>
 <51634B1F.4030408@collabora.co.uk> <516380D7.3060000@gmail.com>
Message-ID: <CAAwP0s2pvCgQALJb_XcNo3HE_zS9mOjB-ZnGR4yPYR1-ESpaVg@mail.gmail.com>

On Tue, Apr 9, 2013 at 4:45 AM, Rob Herring <robherring2 at gmail.com> wrote:
> On 04/08/2013 05:56 PM, Javier Martinez Canillas wrote:
>> On 04/09/2013 12:16 AM, Stephen Warren wrote:
>>> On 04/08/2013 04:05 PM, Rob Herring wrote:
>>>> On 04/05/2013 02:48 AM, Javier Martinez Canillas wrote:
>>>>> According to Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
>>>>> the "#interrupt-cells" property of an "interrupt-controller" is used
>>>>> to define the number of cells needed to specify a single interrupt.
>>> ...
>>>>> But the type is never returned so it can't be saved on the IRQ struct
>>>>> resource flags member.
>>>>>
>>>>> This means that drivers that need the IRQ type/level flags defined in
>>>>> the DT won't be able to get it.
>>>>
>>>> But the interrupt controllers that need the information should be able
>>>> to get to it via irqd_get_trigger_type. What problem exactly are you
>>>> trying to fix? What driver would use this?
>>>
>>> FYI, that is indeed what I did in sound/soc/codecs/wm8903.c. Thinking
>>> back, I'm not sure if that was the right thing or whether I should have
>>> sent this same patch:-)
>>>
>>
>> Hi Stephen,
>>
>> I'm glad you agree :-)
>>
>> I could change drivers/net/ethernet/smsc/smsc911x.c to get the type flags for
>> the IRQ with irqd_get_trigger_type() but I prefer $subject because:
>
> irqd_get_trigger_type probably is not meant for outside of irqchips.
> Creating an irq_get_irq_type function which takes an irq number would be
> the right function as that does not expose struct irq_data.
>

Hi Rob,

I sent a patch-set a few days ago that adds an irq_get_irq_type()
function [1] as you suggested and this function is used on the
smsc911x driver probe function to get the edge/level flags [2].

It would be great if I can get your feedback on this.

Thanks a lot and best regards,
Javier

[1]: http://permalink.gmane.org/gmane.linux.ports.arm.omap/97117
[2]: http://permalink.gmane.org/gmane.linux.network/265587


From arnd at arndb.de  Thu Apr 18 08:23:38 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 18 Apr 2013 14:23:38 +0200
Subject: [PATCH 24/32] dmaengine: ste_dma40: Supply full Device Tree
 parsing support
In-Reply-To: <20130418114756.GE27903@gmail.com>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <201304181337.32700.arnd@arndb.de> <20130418114756.GE27903@gmail.com>
Message-ID: <201304181423.38900.arnd@arndb.de>

On Thursday 18 April 2013, Lee Jones wrote:
> > Yes, that's probably better and more in line with what the other
> > drivers do. You could also put the fixed_chan last if that helps.
> 
> I'd rather keep the flags as the final cell if it's all the same to you?

Ok, no problem.

> > I would still like to get a confirmation that we actually still
> > require the fixed channel assignment, since it's just used
> > in one driver, and that might only be needed for some buggy
> > hardware revision if we're lucky.
> 
> Unfortunately not:
> 
> `git grep "\.use_fixed_channel" <internal_kernel> | grep true | wc -l`
> 8

I see.

	Arnd


From arnd at arndb.de  Thu Apr 18 08:32:11 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 18 Apr 2013 14:32:11 +0200
Subject: [PATCH 24/32 v2] dmaengine: ste_dma40: Supply full Device Tree
 parsing support
In-Reply-To: <20130418121253.GF27903@gmail.com>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-25-git-send-email-lee.jones@linaro.org>
 <20130418121253.GF27903@gmail.com>
Message-ID: <201304181432.11503.arnd@arndb.de>

On Thursday 18 April 2013, Lee Jones wrote:
> +Clients
> +Required properties:
> +- dmas: Comma separated list of dma channel requests
> +- dma-names: Names of the aforementioned requested channels
> +
> +Each dmas request consists of 4 cells:
> +  1. A phandle pointing to the DMA controller
> +  2. Device Type
> +  3. The DMA request line number (only when 'use fixed channel' is set)
> +  4. A 32bit mask specifying; mode, direction and endianess [NB: This list will grow]
> +        bit 1: Mode:
> +           0: Logical
> +           1: Physical
> +        bit 2: Direction:
> +           0: Mem to Mem
> +           1: Mem to Dev

You probably mean 

		0: Dev to mem

Related to this, I would recommend not listing bit numbers like this, since there
is some amount of confusion regarding how they are counted: zero-based on one-based
and LSB-to-MSB or MSB-to-LSB

You can completely avoid this problem by listing them as bit masks:

	0x00000002:
		Logical channel when unset
		Physical channel when set
	0x00000004:
		Direction from device when unset
		Direction to device when unset
	... 

> +		dmas = <&dma 13 0 0x8>, /* Logical - DevToMem */
> +		       <&dma 13 0 0x4>; /* Logical - MemToDev */

The bit in the example no longer matches the description.

> +
> +	switch (D40_DT_FLAGS_DIR(flags)) {
> +	case 0: cfg.dir = STEDMA40_MEM_TO_MEM; break;
> +	case 1: cfg.dir = STEDMA40_MEM_TO_PERIPH; break;
> +	}

Same typo above.

> +	if (cfg.dir == STEDMA40_PERIPH_TO_MEM)
> +		cfg.src_info.big_endian = D40_DT_FLAGS_BIG_ENDIAN(flags);
> +	if (cfg.dir == STEDMA40_MEM_TO_PERIPH)
> +		cfg.dst_info.big_endian = D40_DT_FLAGS_BIG_ENDIAN(flags);

You can fold these two into the switch statement above.

	Arnd


From mpa at pengutronix.de  Thu Apr 18 08:33:39 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Thu, 18 Apr 2013 14:33:39 +0200
Subject: [PATCH v4 05/10] ASoC: fsl-ssi: Use generic DMA bindings if possible
In-Reply-To: <1366288424-7660-1-git-send-email-mpa@pengutronix.de>
References: <1366288424-7660-1-git-send-email-mpa@pengutronix.de>
Message-ID: <1366288424-7660-6-git-send-email-mpa@pengutronix.de>

There may be some platforms using fsl-ssi that do not have a DMA driver
with generic DMA bindings. So this patch adds support for the generic
DMA bindings, while still using the old "fsl,dma-events" property if
"dmas" is not found.

Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
---

Notes:
    Changes in v4:
     - Change TODO comment to a FIXME, to remove the old dma-events property as soon
       as all dma drivers support the generic DMA bindings.

 sound/soc/fsl/fsl_ssi.c | 26 ++++++++++++++++----------
 1 file changed, 16 insertions(+), 10 deletions(-)

diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index 5165d41..d2afda1 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -796,15 +796,19 @@ static int fsl_ssi_probe(struct platform_device *pdev)
 			&ssi_private->filter_data_tx;
 		ssi_private->dma_params_rx.filter_data =
 			&ssi_private->filter_data_rx;
-		/*
-		 * TODO: This is a temporary solution and should be changed
-		 * to use generic DMA binding later when the helplers get in.
-		 */
-		ret = of_property_read_u32_array(pdev->dev.of_node,
+		if (!of_property_read_bool(pdev->dev.of_node, "dmas") &&
+				ssi_private->use_dma) {
+			/*
+			 * FIXME: This is a temporary solution until all
+			 * necessary dma drivers support the generic dma
+			 * bindings.
+			 */
+			ret = of_property_read_u32_array(pdev->dev.of_node,
 					"fsl,ssi-dma-events", dma_events, 2);
-		if (ret && !ssi_private->use_dma) {
-			dev_err(&pdev->dev, "could not get dma events\n");
-			goto error_clk;
+			if (ret && ssi_private->use_dma) {
+				dev_err(&pdev->dev, "could not get dma events but fsl-ssi is configured to use DMA\n");
+				goto error_clk;
+			}
 		}
 
 		shared = of_device_is_compatible(of_get_parent(np),
@@ -875,8 +879,10 @@ static int fsl_ssi_probe(struct platform_device *pdev)
 			}
 		} else {
 			ssi_private->imx_pcm_pdev =
-				platform_device_register_simple("imx-pcm-audio",
-							-1, NULL, 0);
+				platform_device_register_data(&pdev->dev,
+						"imx-pcm-audio", -1,
+						pdev->dev.of_node,
+						sizeof(*pdev->dev.of_node));
 			if (IS_ERR(ssi_private->imx_pcm_pdev)) {
 				ret = PTR_ERR(ssi_private->imx_pcm_pdev);
 				goto error_dev;
-- 
1.8.1.5



From mpa at pengutronix.de  Thu Apr 18 08:33:44 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Thu, 18 Apr 2013 14:33:44 +0200
Subject: [PATCH v4 10/10] ASoC: fsl: Update fsl-ssi binding doc
In-Reply-To: <1366288424-7660-1-git-send-email-mpa@pengutronix.de>
References: <1366288424-7660-1-git-send-email-mpa@pengutronix.de>
Message-ID: <1366288424-7660-11-git-send-email-mpa@pengutronix.de>

Update the fsl-ssi bindings. DMA is no required property anymore and
uses the generic DMA bindings. imx-fiq is a new alternative to DMA

Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
---

Notes:
    Changes in v4:
     - Add a comment about hardware bugs for imx-pcm-fiq
    
    Changes in v3:
     - In previous versions, I removed fsl,playback-dma and capture-dma. But they
       are still in use by fsl_dma.c, so I added them again.

 Documentation/devicetree/bindings/sound/fsl,ssi.txt | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/Documentation/devicetree/bindings/sound/fsl,ssi.txt b/Documentation/devicetree/bindings/sound/fsl,ssi.txt
index 5ff76c9..0375ee0 100644
--- a/Documentation/devicetree/bindings/sound/fsl,ssi.txt
+++ b/Documentation/devicetree/bindings/sound/fsl,ssi.txt
@@ -43,10 +43,20 @@ Required properties:
                     together.  This would still allow different sample sizes,
                     but not different sample rates.
 
+Note that either dmas, dma-names or fsl,imx-fiq are required.
+
 Optional properties:
 - codec-handle:     Phandle to a 'codec' node that defines an audio
                     codec connected to this SSI.  This node is typically
                     a child of an I2C or other control node.
+- dmas:		    Generic dma devicetree binding as described in
+		    Documentation/devicetree/bindings/dma/dma.txt.
+- dma-names:	    Two dmas have to be defined, "tx" and "rx", if fsl,imx-fiq
+		    is not defined.
+- fsl,imx-fiq:	    Bool property. Use imx-pcm-fiq instead of imx-pcm-dma.
+  		    Only necessary for some boards with incompatible
+		    codec. imx-pcm-fiq will manually filter some data from
+		    the codec. It is a workaround for a hardware bug.
 
 Child 'codec' node required properties:
 - compatible:       Compatible list, contains the name of the codec
-- 
1.8.1.5



From mpa at pengutronix.de  Thu Apr 18 08:33:41 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Thu, 18 Apr 2013 14:33:41 +0200
Subject: [PATCH v4 07/10] ASoC: fsl-ssi: imx ac97 support
In-Reply-To: <1366288424-7660-1-git-send-email-mpa@pengutronix.de>
References: <1366288424-7660-1-git-send-email-mpa@pengutronix.de>
Message-ID: <1366288424-7660-8-git-send-email-mpa@pengutronix.de>

This patch copies some parts from imx-ssi to support AC97 on
imx27-pca100 and imx27-pcm043. This is a implementation of the
ac97-slave mode.

For ac97, the registers have to be setup earlier than for other ssi
modes because there is some communication with the external device
before actual streaming. So this patch introduces a fsl_ssi_setup
function to setup the registers at different times.

This patch was tested with imx27-pca100.

Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
---

Notes:
    Changes in v3:
     - Cleanup ac97 code by adding a fsl_ssi_setup function for initial register
       setup. For ac97 the registers have to be setup earlier than in normal
       mode.

 sound/soc/fsl/fsl_ssi.c | 412 +++++++++++++++++++++++++++++++++++++++---------
 1 file changed, 340 insertions(+), 72 deletions(-)

diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index d2afda1..5cb7533 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -141,6 +141,7 @@ struct fsl_ssi_private {
 
 	bool new_binding;
 	bool ssi_on_imx;
+	bool imx_ac97;
 	bool use_dma;
 	struct clk *clk;
 	struct platform_device *imx_pcm_pdev;
@@ -150,6 +151,9 @@ struct fsl_ssi_private {
 	struct imx_dma_data filter_data_rx;
 	struct imx_pcm_fiq_params fiq_params;
 
+	void (*ac97_reset) (struct snd_ac97 *ac97);
+	void (*ac97_warm_reset)(struct snd_ac97 *ac97);
+
 	struct {
 		unsigned int rfrc;
 		unsigned int tfrc;
@@ -321,6 +325,124 @@ static irqreturn_t fsl_ssi_isr(int irq, void *dev_id)
 	return ret;
 }
 
+static int fsl_ssi_setup(struct fsl_ssi_private *ssi_private)
+{
+	struct ccsr_ssi __iomem *ssi = ssi_private->ssi;
+	u8 i2s_mode;
+	u8 wm;
+	int synchronous = ssi_private->cpu_dai_drv.symmetric_rates;
+
+	if (ssi_private->imx_ac97)
+		i2s_mode = CCSR_SSI_SCR_I2S_MODE_NORMAL | CCSR_SSI_SCR_NET;
+	else
+		i2s_mode = CCSR_SSI_SCR_I2S_MODE_SLAVE;
+
+	/*
+	 * Section 16.5 of the MPC8610 reference manual says that the SSI needs
+	 * to be disabled before updating the registers we set here.
+	 */
+	write_ssi_mask(&ssi->scr, CCSR_SSI_SCR_SSIEN, 0);
+
+	/*
+	 * Program the SSI into I2S Slave Non-Network Synchronous mode. Also
+	 * enable the transmit and receive FIFO.
+	 *
+	 * FIXME: Little-endian samples require a different shift dir
+	 */
+	write_ssi_mask(&ssi->scr,
+		CCSR_SSI_SCR_I2S_MODE_MASK | CCSR_SSI_SCR_SYN,
+		CCSR_SSI_SCR_TFR_CLK_DIS |
+		i2s_mode |
+		(synchronous ? CCSR_SSI_SCR_SYN : 0));
+
+	write_ssi(CCSR_SSI_STCR_TXBIT0 | CCSR_SSI_STCR_TFEN0 |
+		 CCSR_SSI_STCR_TFSI | CCSR_SSI_STCR_TEFS |
+		 CCSR_SSI_STCR_TSCKP, &ssi->stcr);
+
+	write_ssi(CCSR_SSI_SRCR_RXBIT0 | CCSR_SSI_SRCR_RFEN0 |
+		 CCSR_SSI_SRCR_RFSI | CCSR_SSI_SRCR_REFS |
+		 CCSR_SSI_SRCR_RSCKP, &ssi->srcr);
+	/*
+	 * The DC and PM bits are only used if the SSI is the clock master.
+	 */
+
+	/*
+	 * Set the watermark for transmit FIFI 0 and receive FIFO 0. We don't
+	 * use FIFO 1. We program the transmit water to signal a DMA transfer
+	 * if there are only two (or fewer) elements left in the FIFO. Two
+	 * elements equals one frame (left channel, right channel). This value,
+	 * however, depends on the depth of the transmit buffer.
+	 *
+	 * We set the watermark on the same level as the DMA burstsize.  For
+	 * fiq it is probably better to use the biggest possible watermark
+	 * size.
+	 */
+	if (ssi_private->use_dma)
+		wm = ssi_private->fifo_depth - 2;
+	else
+		wm = ssi_private->fifo_depth;
+
+	write_ssi(CCSR_SSI_SFCSR_TFWM0(wm) | CCSR_SSI_SFCSR_RFWM0(wm) |
+		CCSR_SSI_SFCSR_TFWM1(wm) | CCSR_SSI_SFCSR_RFWM1(wm),
+		&ssi->sfcsr);
+
+	/*
+	 * For non-ac97 setups, we keep the SSI disabled because if we enable
+	 * it, then the DMA controller will start. It's not supposed to start
+	 * until the SCR.TE (or SCR.RE) bit is set, but it does anyway. The DMA
+	 * controller will transfer one "BWC" of data (i.e. the amount of data
+	 * that the MR.BWC bits are set to). The reason this is bad is because
+	 * at this point, the PCM driver has not finished initializing the DMA
+	 * controller.
+	 */
+
+
+	/*
+	 * For ac97 interrupts are enabled with the startup of the substream
+	 * because it is also running without an active substream. Normally SSI
+	 * is only enabled when there is a substream.
+	 */
+	if (!ssi_private->imx_ac97) {
+		/* Enable the interrupts and DMA requests */
+		if (ssi_private->use_dma)
+			write_ssi(SIER_FLAGS, &ssi->sier);
+		else
+			write_ssi(CCSR_SSI_SIER_TIE | CCSR_SSI_SIER_TFE0_EN |
+					CCSR_SSI_SIER_RIE |
+					CCSR_SSI_SIER_RFF0_EN, &ssi->sier);
+	} else {
+		/*
+		 * Setup the clock control register
+		 */
+		write_ssi(CCSR_SSI_SxCCR_WL(17) | CCSR_SSI_SxCCR_DC(13),
+				&ssi->stccr);
+		write_ssi(CCSR_SSI_SxCCR_WL(17) | CCSR_SSI_SxCCR_DC(13),
+				&ssi->srccr);
+
+		/*
+		 * Enable AC97 mode and startup the SSI
+		 */
+		write_ssi(CCSR_SSI_SACNT_AC97EN | CCSR_SSI_SACNT_FV,
+				&ssi->sacnt);
+		write_ssi(0xff, &ssi->saccdis);
+		write_ssi(0x300, &ssi->saccen);
+
+		/*
+		 * Enable SSI
+		 */
+		write_ssi_mask(&ssi->scr, 0, CCSR_SSI_SCR_SSIEN);
+		write_ssi(CCSR_SSI_SOR_WAIT(3), &ssi->sor);
+
+		/*
+		 * Enable Transmit and Receive
+		 */
+		write_ssi_mask(&ssi->scr, 0, CCSR_SSI_SCR_TE | CCSR_SSI_SCR_RE);
+	}
+
+	return 0;
+}
+
+
 /**
  * fsl_ssi_startup: create a new substream
  *
@@ -342,75 +464,14 @@ static int fsl_ssi_startup(struct snd_pcm_substream *substream,
 	 * and initialize the SSI registers.
 	 */
 	if (!ssi_private->first_stream) {
-		struct ccsr_ssi __iomem *ssi = ssi_private->ssi;
-
 		ssi_private->first_stream = substream;
 
 		/*
-		 * Section 16.5 of the MPC8610 reference manual says that the
-		 * SSI needs to be disabled before updating the registers we set
-		 * here.
-		 */
-		write_ssi_mask(&ssi->scr, CCSR_SSI_SCR_SSIEN, 0);
-
-		/*
-		 * Program the SSI into I2S Slave Non-Network Synchronous mode.
-		 * Also enable the transmit and receive FIFO.
-		 *
-		 * FIXME: Little-endian samples require a different shift dir
-		 */
-		write_ssi_mask(&ssi->scr,
-			CCSR_SSI_SCR_I2S_MODE_MASK | CCSR_SSI_SCR_SYN,
-			CCSR_SSI_SCR_TFR_CLK_DIS | CCSR_SSI_SCR_I2S_MODE_SLAVE
-			| (synchronous ? CCSR_SSI_SCR_SYN : 0));
-
-		write_ssi(CCSR_SSI_STCR_TXBIT0 | CCSR_SSI_STCR_TFEN0 |
-			 CCSR_SSI_STCR_TFSI | CCSR_SSI_STCR_TEFS |
-			 CCSR_SSI_STCR_TSCKP, &ssi->stcr);
-
-		write_ssi(CCSR_SSI_SRCR_RXBIT0 | CCSR_SSI_SRCR_RFEN0 |
-			 CCSR_SSI_SRCR_RFSI | CCSR_SSI_SRCR_REFS |
-			 CCSR_SSI_SRCR_RSCKP, &ssi->srcr);
-
-		/*
-		 * The DC and PM bits are only used if the SSI is the clock
-		 * master.
-		 */
-
-		/* Enable the interrupts and DMA requests */
-		if (ssi_private->use_dma)
-			write_ssi(SIER_FLAGS, &ssi->sier);
-		else
-			write_ssi(CCSR_SSI_SIER_TIE | CCSR_SSI_SIER_TFE0_EN |
-					CCSR_SSI_SIER_RIE |
-					CCSR_SSI_SIER_RFF0_EN, &ssi->sier);
-
-		/*
-		 * Set the watermark for transmit FIFI 0 and receive FIFO 0. We
-		 * don't use FIFO 1.  We program the transmit water to signal a
-		 * DMA transfer if there are only two (or fewer) elements left
-		 * in the FIFO.  Two elements equals one frame (left channel,
-		 * right channel).  This value, however, depends on the depth of
-		 * the transmit buffer.
-		 *
-		 * We program the receive FIFO to notify us if at least two
-		 * elements (one frame) have been written to the FIFO.  We could
-		 * make this value larger (and maybe we should), but this way
-		 * data will be written to memory as soon as it's available.
-		 */
-		write_ssi(CCSR_SSI_SFCSR_TFWM0(ssi_private->fifo_depth - 2) |
-			CCSR_SSI_SFCSR_RFWM0(ssi_private->fifo_depth - 2),
-			&ssi->sfcsr);
-
-		/*
-		 * We keep the SSI disabled because if we enable it, then the
-		 * DMA controller will start.  It's not supposed to start until
-		 * the SCR.TE (or SCR.RE) bit is set, but it does anyway.  The
-		 * DMA controller will transfer one "BWC" of data (i.e. the
-		 * amount of data that the MR.BWC bits are set to).  The reason
-		 * this is bad is because at this point, the PCM driver has not
-		 * finished initializing the DMA controller.
+		 * fsl_ssi_setup was already called by ac97_init earlier if
+		 * the driver is in ac97 mode.
 		 */
+		if (!ssi_private->imx_ac97)
+			fsl_ssi_setup(ssi_private);
 	} else {
 		if (synchronous) {
 			struct snd_pcm_runtime *first_runtime =
@@ -565,8 +626,9 @@ static void fsl_ssi_shutdown(struct snd_pcm_substream *substream,
 
 	/*
 	 * If this is the last active substream, disable the SSI.
+	 * If AC97 is active, we don't want to disable SSI.
 	 */
-	if (!ssi_private->first_stream) {
+	if (!ssi_private->first_stream && !ssi_private->imx_ac97) {
 		struct ccsr_ssi __iomem *ssi = ssi_private->ssi;
 
 		write_ssi_mask(&ssi->scr, CCSR_SSI_SCR_SSIEN, 0);
@@ -615,6 +677,176 @@ static const struct snd_soc_component_driver fsl_ssi_component = {
 	.name		= "fsl-ssi",
 };
 
+/**
+ * fsl_ssi_ac97_trigger: start and stop the AC97 receive/transmit.
+ *
+ * This function is called by ALSA to start, stop, pause, and resume the
+ * transfer of data.
+ */
+static int fsl_ssi_ac97_trigger(struct snd_pcm_substream *substream, int cmd,
+			   struct snd_soc_dai *dai)
+{
+	struct snd_soc_pcm_runtime *rtd = substream->private_data;
+	struct fsl_ssi_private *ssi_private = snd_soc_dai_get_drvdata(rtd->cpu_dai);
+	struct ccsr_ssi __iomem *ssi = ssi_private->ssi;
+
+	switch (cmd) {
+	case SNDRV_PCM_TRIGGER_START:
+	case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
+		if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
+			write_ssi_mask(&ssi->sier, 0, CCSR_SSI_SIER_TIE |
+					CCSR_SSI_SIER_TFE0_EN);
+		else
+			write_ssi_mask(&ssi->sier, 0, CCSR_SSI_SIER_RIE |
+					CCSR_SSI_SIER_RFF0_EN);
+		break;
+
+	case SNDRV_PCM_TRIGGER_STOP:
+	case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
+		if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
+			write_ssi_mask(&ssi->sier, CCSR_SSI_SIER_TIE |
+					CCSR_SSI_SIER_TFE0_EN, 0);
+		else
+			write_ssi_mask(&ssi->sier, CCSR_SSI_SIER_RIE |
+					CCSR_SSI_SIER_RFF0_EN, 0);
+		break;
+
+	default:
+		return -EINVAL;
+	}
+
+	if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
+		write_ssi(CCSR_SSI_SOR_TX_CLR, &ssi->sor);
+	else
+		write_ssi(CCSR_SSI_SOR_RX_CLR, &ssi->sor);
+
+	return 0;
+}
+
+static const struct snd_soc_dai_ops fsl_ssi_ac97_dai_ops = {
+	.startup	= fsl_ssi_startup,
+	.shutdown	= fsl_ssi_shutdown,
+	.trigger	= fsl_ssi_ac97_trigger,
+};
+
+static struct snd_soc_dai_driver fsl_ssi_ac97_dai = {
+	.ac97_control = 1,
+	.playback = {
+		.stream_name = "AC97 Playback",
+		.channels_min = 2,
+		.channels_max = 2,
+		.rates = SNDRV_PCM_RATE_8000_48000,
+		.formats = SNDRV_PCM_FMTBIT_S16_LE,
+	},
+	.capture = {
+		.stream_name = "AC97 Capture",
+		.channels_min = 2,
+		.channels_max = 2,
+		.rates = SNDRV_PCM_RATE_48000,
+		.formats = SNDRV_PCM_FMTBIT_S16_LE,
+	},
+	.ops = &fsl_ssi_ac97_dai_ops,
+};
+
+
+static struct fsl_ssi_private *fsl_ac97_data;
+
+static void fsl_ssi_ac97_init(void)
+{
+	fsl_ssi_setup(fsl_ac97_data);
+}
+
+static void fsl_ssi_ac97_write(struct snd_ac97 *ac97, unsigned short reg,
+		unsigned short val)
+{
+	struct ccsr_ssi *ssi = fsl_ac97_data->ssi;
+	unsigned int lreg;
+	unsigned int lval;
+
+	if (reg > 0x7f)
+		return;
+
+
+	lreg = reg <<  12;
+	write_ssi(lreg, &ssi->sacadd);
+
+	lval = val << 4;
+	write_ssi(lval , &ssi->sacdat);
+
+	write_ssi_mask(&ssi->sacnt, CCSR_SSI_SACNT_RDWR_MASK,
+			CCSR_SSI_SACNT_WR);
+	udelay(100);
+}
+
+static unsigned short fsl_ssi_ac97_read(struct snd_ac97 *ac97,
+		unsigned short reg)
+{
+	struct ccsr_ssi *ssi = fsl_ac97_data->ssi;
+
+	unsigned short val = -1;
+	unsigned int lreg;
+
+	lreg = (reg & 0x7f) <<  12 ;
+	write_ssi(lreg, &ssi->sacadd);
+	write_ssi_mask(&ssi->sacnt, CCSR_SSI_SACNT_RDWR_MASK,
+			CCSR_SSI_SACNT_RD);
+
+	udelay(100);
+
+	val = (read_ssi(&ssi->sacdat) >> 4) & 0xffff;
+
+	return val;
+}
+
+static void fsl_ssi_ac97_reset(struct snd_ac97 *ac97)
+{
+	struct fsl_ssi_private *ssi_private = fsl_ac97_data;
+
+	if (ssi_private->ac97_reset)
+		ssi_private->ac97_reset(ac97);
+	/* First read sometimes fails, do a dummy read */
+	fsl_ssi_ac97_read(ac97, 0);
+}
+
+static void fsl_ssi_ac97_warm_reset(struct snd_ac97 *ac97)
+{
+	struct fsl_ssi_private *ssi_private = fsl_ac97_data;
+
+	if (ssi_private->ac97_warm_reset)
+		ssi_private->ac97_warm_reset(ac97);
+
+	/* First read sometimes fails, do a dummy read */
+	fsl_ssi_ac97_read(ac97, 0);
+}
+
+struct snd_ac97_bus_ops soc_ac97_ops = {
+	.read		= fsl_ssi_ac97_read,
+	.write		= fsl_ssi_ac97_write,
+	.reset		= fsl_ssi_ac97_reset,
+	.warm_reset	= fsl_ssi_ac97_warm_reset
+};
+EXPORT_SYMBOL_GPL(soc_ac97_ops);
+
+/*
+ * Pointer to AC97 reset functions for specific boards
+ */
+#if IS_ENABLED(CONFIG_MACH_PCA100)
+extern void pca100_ac97_cold_reset(struct snd_ac97 *ac97);
+extern void pca100_ac97_warm_reset(struct snd_ac97 *ac97);
+#else
+void pca100_ac97_cold_reset(struct snd_ac97 *ac97) { }
+void pca100_ac97_warm_reset(struct snd_ac97 *ac97) { }
+#endif
+
+#if IS_ENABLED(CONFIG_MACH_PCM043)
+extern void pcm043_ac97_cold_reset(struct snd_ac97 *ac97);
+extern void pcm043_ac97_warm_reset(struct snd_ac97 *ac97);
+#else
+void pcm043_ac97_cold_reset(struct snd_ac97 *ac97) { }
+void pcm043_ac97_warm_reset(struct snd_ac97 *ac97) { }
+#endif
+
+
 /* Show the statistics of a flag only if its interrupt is enabled.  The
  * compiler will optimze this code to a no-op if the interrupt is not
  * enabled.
@@ -691,6 +923,7 @@ static int fsl_ssi_probe(struct platform_device *pdev)
 	struct resource res;
 	char name[64];
 	bool shared;
+	bool ac97 = false;
 
 	/* SSIs that are not connected on the board should have a
 	 *      status = "disabled"
@@ -701,7 +934,13 @@ static int fsl_ssi_probe(struct platform_device *pdev)
 
 	/* We only support the SSI in "I2S Slave" mode */
 	sprop = of_get_property(np, "fsl,mode", NULL);
-	if (!sprop || strcmp(sprop, "i2s-slave")) {
+	if (!sprop) {
+		dev_err(&pdev->dev, "fsl,mode property is necessary\n");
+		return -EINVAL;
+	}
+	if (!strcmp(sprop, "ac97-slave")) {
+		ac97 = true;
+	} else if (strcmp(sprop, "i2s-slave")) {
 		dev_notice(&pdev->dev, "mode %s is unsupported\n", sprop);
 		return -ENODEV;
 	}
@@ -717,13 +956,39 @@ static int fsl_ssi_probe(struct platform_device *pdev)
 
 	strcpy(ssi_private->name, p);
 
-	/* Initialize this copy of the CPU DAI driver structure */
-	memcpy(&ssi_private->cpu_dai_drv, &fsl_ssi_dai_template,
-	       sizeof(fsl_ssi_dai_template));
-	ssi_private->cpu_dai_drv.name = ssi_private->name;
-
 	ssi_private->use_dma = !of_property_read_bool(np, "fsl,imx-fiq");
 
+	if (ac97) {
+		sprop = of_get_property(of_find_node_by_path("/"), "compatible",
+				NULL);
+		p = strrchr(sprop, ',');
+		if (p)
+			sprop = p + 1;
+
+		if (!strcmp(sprop, "imx27-pca100")) {
+			ssi_private->ac97_reset = pca100_ac97_cold_reset;
+			ssi_private->ac97_warm_reset = pca100_ac97_warm_reset;
+		} else if (!strcmp(sprop, "imx27-pcm043")) {
+			ssi_private->ac97_reset = pcm043_ac97_cold_reset;
+			ssi_private->ac97_warm_reset = pcm043_ac97_warm_reset;
+		} else {
+			dev_err(&pdev->dev, "Failed to enable ssi AC97 mode, unknown board.\n");
+			ret = -EINVAL;
+			goto error_kmalloc;
+		}
+
+		memcpy(&ssi_private->cpu_dai_drv, &fsl_ssi_ac97_dai,
+				sizeof(fsl_ssi_ac97_dai));
+
+		fsl_ac97_data = ssi_private;
+		ssi_private->imx_ac97 = true;
+	} else {
+		/* Initialize this copy of the CPU DAI driver structure */
+		memcpy(&ssi_private->cpu_dai_drv, &fsl_ssi_dai_template,
+		       sizeof(fsl_ssi_dai_template));
+	}
+	ssi_private->cpu_dai_drv.name = ssi_private->name;
+
 	/* Get the addresses and IRQ */
 	ret = of_address_to_resource(np, 0, &res);
 	if (ret) {
@@ -922,6 +1187,9 @@ static int fsl_ssi_probe(struct platform_device *pdev)
 	}
 
 done:
+	if (ssi_private->imx_ac97)
+		fsl_ssi_ac97_init();
+
 	return 0;
 
 error_dai:
-- 
1.8.1.5



From mpa at pengutronix.de  Thu Apr 18 08:33:40 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Thu, 18 Apr 2013 14:33:40 +0200
Subject: [PATCH v4 06/10] ARM: imx: Export ac97 reset functions
In-Reply-To: <1366288424-7660-1-git-send-email-mpa@pengutronix.de>
References: <1366288424-7660-1-git-send-email-mpa@pengutronix.de>
Message-ID: <1366288424-7660-7-git-send-email-mpa@pengutronix.de>

Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
---
 arch/arm/mach-imx/mach-pca100.c | 7 +++++--
 arch/arm/mach-imx/mach-pcm043.c | 7 +++++--
 2 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-imx/mach-pca100.c b/arch/arm/mach-imx/mach-pca100.c
index b8b15bb..68badf8 100644
--- a/arch/arm/mach-imx/mach-pca100.c
+++ b/arch/arm/mach-imx/mach-pca100.c
@@ -22,6 +22,7 @@
 #include <linux/i2c.h>
 #include <linux/i2c/at24.h>
 #include <linux/dma-mapping.h>
+#include <linux/export.h>
 #include <linux/spi/spi.h>
 #include <linux/spi/eeprom.h>
 #include <linux/irq.h>
@@ -208,7 +209,7 @@ static const struct spi_imx_master pca100_spi0_data __initconst = {
 	.num_chipselect = ARRAY_SIZE(pca100_spi_cs),
 };
 
-static void pca100_ac97_warm_reset(struct snd_ac97 *ac97)
+void pca100_ac97_warm_reset(struct snd_ac97 *ac97)
 {
 	mxc_gpio_mode(GPIO_PORTC | 20 | GPIO_GPIO | GPIO_OUT);
 	gpio_set_value(GPIO_PORTC + 20, 1);
@@ -217,8 +218,9 @@ static void pca100_ac97_warm_reset(struct snd_ac97 *ac97)
 	mxc_gpio_mode(PC20_PF_SSI1_FS);
 	msleep(2);
 }
+EXPORT_SYMBOL(pca100_ac97_warm_reset);
 
-static void pca100_ac97_cold_reset(struct snd_ac97 *ac97)
+void pca100_ac97_cold_reset(struct snd_ac97 *ac97)
 {
 	mxc_gpio_mode(GPIO_PORTC | 20 | GPIO_GPIO | GPIO_OUT);  /* FS */
 	gpio_set_value(GPIO_PORTC + 20, 0);
@@ -232,6 +234,7 @@ static void pca100_ac97_cold_reset(struct snd_ac97 *ac97)
 	mxc_gpio_mode(PC22_PF_SSI1_TXD);
 	msleep(2);
 }
+EXPORT_SYMBOL(pca100_ac97_cold_reset);
 
 static const struct imx_ssi_platform_data pca100_ssi_pdata __initconst = {
 	.ac97_reset		= pca100_ac97_cold_reset,
diff --git a/arch/arm/mach-imx/mach-pcm043.c b/arch/arm/mach-imx/mach-pcm043.c
index 8ed533f..4f318ca 100644
--- a/arch/arm/mach-imx/mach-pcm043.c
+++ b/arch/arm/mach-imx/mach-pcm043.c
@@ -27,6 +27,7 @@
 #include <linux/i2c/at24.h>
 #include <linux/usb/otg.h>
 #include <linux/usb/ulpi.h>
+#include <linux/export.h>
 
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
@@ -217,7 +218,7 @@ static iomux_v3_cfg_t pcm043_pads[] = {
 #define SD1_GPIO_WP	IMX_GPIO_NR(2, 23)
 #define SD1_GPIO_CD	IMX_GPIO_NR(2, 24)
 
-static void pcm043_ac97_warm_reset(struct snd_ac97 *ac97)
+void pcm043_ac97_warm_reset(struct snd_ac97 *ac97)
 {
 	iomux_v3_cfg_t txfs_gpio = MX35_PAD_STXFS4__GPIO2_31;
 	iomux_v3_cfg_t txfs = MX35_PAD_STXFS4__AUDMUX_AUD4_TXFS;
@@ -239,8 +240,9 @@ static void pcm043_ac97_warm_reset(struct snd_ac97 *ac97)
 	gpio_free(AC97_GPIO_TXFS);
 	mxc_iomux_v3_setup_pad(txfs);
 }
+EXPORT_SYMBOL(pcm043_ac97_warm_reset);
 
-static void pcm043_ac97_cold_reset(struct snd_ac97 *ac97)
+void pcm043_ac97_cold_reset(struct snd_ac97 *ac97)
 {
 	iomux_v3_cfg_t txfs_gpio = MX35_PAD_STXFS4__GPIO2_31;
 	iomux_v3_cfg_t txfs = MX35_PAD_STXFS4__AUDMUX_AUD4_TXFS;
@@ -286,6 +288,7 @@ err1:
 		printk("%s failed with %d\n", __func__, ret);
 	mdelay(1);
 }
+EXPORT_SYMBOL(pcm043_ac97_cold_reset);
 
 static const struct imx_ssi_platform_data pcm043_ssi_pdata __initconst = {
 	.ac97_reset = pcm043_ac97_cold_reset,
-- 
1.8.1.5



From mpa at pengutronix.de  Thu Apr 18 08:33:42 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Thu, 18 Apr 2013 14:33:42 +0200
Subject: [PATCH v4 08/10] ASoC: fsl: Kconfig: Use fsl-ssi for phycore-ac97
In-Reply-To: <1366288424-7660-1-git-send-email-mpa@pengutronix.de>
References: <1366288424-7660-1-git-send-email-mpa@pengutronix.de>
Message-ID: <1366288424-7660-9-git-send-email-mpa@pengutronix.de>

Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
---
 sound/soc/fsl/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig
index 3843a18..28af843 100644
--- a/sound/soc/fsl/Kconfig
+++ b/sound/soc/fsl/Kconfig
@@ -153,7 +153,7 @@ config SND_SOC_PHYCORE_AC97
 	select SND_SOC_WM9712
 	select SND_SOC_IMX_PCM_FIQ
 	select SND_SOC_IMX_AUDMUX
-	select SND_SOC_IMX_SSI
+	select SND_SOC_FSL_SSI
 	help
 	  Say Y if you want to add support for SoC audio on Phytec phyCORE
 	  and phyCARD boards in AC97 mode
-- 
1.8.1.5



From mpa at pengutronix.de  Thu Apr 18 08:33:37 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Thu, 18 Apr 2013 14:33:37 +0200
Subject: [PATCH v4 03/10] ASoC: imx-pcm-fiq: Introduce pcm-fiq-params
In-Reply-To: <1366288424-7660-1-git-send-email-mpa@pengutronix.de>
References: <1366288424-7660-1-git-send-email-mpa@pengutronix.de>
Message-ID: <1366288424-7660-4-git-send-email-mpa@pengutronix.de>

Cleaner parameter passing for imx-pcm-fiq. Create a seperated fiq-params
struct to pass all arguments.

Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
---

Notes:
    Changes in v3:
     - Using snd_dmaengine_dai_dma_data for dma_params after rebasing onto
       dmaengine cleanups.

 sound/soc/fsl/imx-pcm-fiq.c | 16 +++++++++-------
 sound/soc/fsl/imx-pcm.h     |  9 +++++++++
 sound/soc/fsl/imx-ssi.c     |  7 ++++++-
 sound/soc/fsl/imx-ssi.h     |  1 +
 4 files changed, 25 insertions(+), 8 deletions(-)

diff --git a/sound/soc/fsl/imx-pcm-fiq.c b/sound/soc/fsl/imx-pcm-fiq.c
index 670b96b..c3fdb2f 100644
--- a/sound/soc/fsl/imx-pcm-fiq.c
+++ b/sound/soc/fsl/imx-pcm-fiq.c
@@ -22,6 +22,7 @@
 #include <linux/slab.h>
 
 #include <sound/core.h>
+#include <sound/dmaengine_pcm.h>
 #include <sound/initval.h>
 #include <sound/pcm.h>
 #include <sound/pcm_params.h>
@@ -32,6 +33,7 @@
 #include <linux/platform_data/asoc-imx-ssi.h>
 
 #include "imx-ssi.h"
+#include "imx-pcm.h"
 
 struct imx_pcm_runtime_data {
 	unsigned int period;
@@ -283,7 +285,7 @@ static struct snd_soc_platform_driver imx_soc_platform_fiq = {
 
 int imx_pcm_fiq_init(struct platform_device *pdev)
 {
-	struct imx_ssi *ssi = platform_get_drvdata(pdev);
+	struct imx_pcm_fiq_params *params = platform_get_drvdata(pdev);
 	int ret;
 
 	ret = claim_fiq(&fh);
@@ -292,15 +294,15 @@ int imx_pcm_fiq_init(struct platform_device *pdev)
 		return ret;
 	}
 
-	mxc_set_irq_fiq(ssi->irq, 1);
-	ssi_irq = ssi->irq;
+	mxc_set_irq_fiq(params->irq, 1);
+	ssi_irq = params->irq;
 
-	imx_pcm_fiq = ssi->irq;
+	imx_pcm_fiq = params->irq;
 
-	imx_ssi_fiq_base = (unsigned long)ssi->base;
+	imx_ssi_fiq_base = (unsigned long)params->base;
 
-	ssi->dma_params_tx.maxburst = 4;
-	ssi->dma_params_rx.maxburst = 6;
+	params->dma_params_tx->maxburst = 4;
+	params->dma_params_rx->maxburst = 6;
 
 	ret = snd_soc_register_platform(&pdev->dev, &imx_soc_platform_fiq);
 	if (ret)
diff --git a/sound/soc/fsl/imx-pcm.h b/sound/soc/fsl/imx-pcm.h
index b7fa0d7..f592f23 100644
--- a/sound/soc/fsl/imx-pcm.h
+++ b/sound/soc/fsl/imx-pcm.h
@@ -32,6 +32,15 @@ imx_pcm_dma_params_init_data(struct imx_dma_data *dma_data,
 		dma_data->peripheral_type = IMX_DMATYPE_SSI;
 }
 
+struct imx_pcm_fiq_params {
+	int irq;
+	void __iomem *base;
+
+	/* Pointer to original ssi driver to setup tx rx sizes */
+	struct snd_dmaengine_dai_dma_data *dma_params_rx;
+	struct snd_dmaengine_dai_dma_data *dma_params_tx;
+};
+
 int snd_imx_pcm_mmap(struct snd_pcm_substream *substream,
 		     struct vm_area_struct *vma);
 int imx_pcm_new(struct snd_soc_pcm_runtime *rtd);
diff --git a/sound/soc/fsl/imx-ssi.c b/sound/soc/fsl/imx-ssi.c
index 902fab0..f80f4c7 100644
--- a/sound/soc/fsl/imx-ssi.c
+++ b/sound/soc/fsl/imx-ssi.c
@@ -601,7 +601,12 @@ static int imx_ssi_probe(struct platform_device *pdev)
 		goto failed_pdev_fiq_alloc;
 	}
 
-	platform_set_drvdata(ssi->soc_platform_pdev_fiq, ssi);
+	ssi->fiq_params.irq = ssi->irq;
+	ssi->fiq_params.base = ssi->base;
+	ssi->fiq_params.dma_params_rx = &ssi->dma_params_rx;
+	ssi->fiq_params.dma_params_tx = &ssi->dma_params_tx;
+
+	platform_set_drvdata(ssi->soc_platform_pdev_fiq, &ssi->fiq_params);
 	ret = platform_device_add(ssi->soc_platform_pdev_fiq);
 	if (ret) {
 		dev_err(&pdev->dev, "failed to add platform device\n");
diff --git a/sound/soc/fsl/imx-ssi.h b/sound/soc/fsl/imx-ssi.h
index bb6b3db..20ce7ca 100644
--- a/sound/soc/fsl/imx-ssi.h
+++ b/sound/soc/fsl/imx-ssi.h
@@ -209,6 +209,7 @@ struct imx_ssi {
 	struct snd_dmaengine_dai_dma_data dma_params_tx;
 	struct imx_dma_data filter_data_tx;
 	struct imx_dma_data filter_data_rx;
+	struct imx_pcm_fiq_params fiq_params;
 
 	int enabled;
 
-- 
1.8.1.5



From mpa at pengutronix.de  Thu Apr 18 08:33:43 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Thu, 18 Apr 2013 14:33:43 +0200
Subject: [PATCH v4 09/10] ASoC: fsl: Move fsl-ssi binding doc to sound/
In-Reply-To: <1366288424-7660-1-git-send-email-mpa@pengutronix.de>
References: <1366288424-7660-1-git-send-email-mpa@pengutronix.de>
Message-ID: <1366288424-7660-10-git-send-email-mpa@pengutronix.de>

fsl-ssi was located in powerpc/fsl/ssi.txt. This is no powerpc specific
device, so it should be moved to sound/ as it connects to differen audio
codecs.

Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
---
 .../devicetree/bindings/powerpc/fsl/ssi.txt        | 73 ----------------------
 .../devicetree/bindings/sound/fsl,ssi.txt          | 73 ++++++++++++++++++++++
 2 files changed, 73 insertions(+), 73 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/powerpc/fsl/ssi.txt
 create mode 100644 Documentation/devicetree/bindings/sound/fsl,ssi.txt

diff --git a/Documentation/devicetree/bindings/powerpc/fsl/ssi.txt b/Documentation/devicetree/bindings/powerpc/fsl/ssi.txt
deleted file mode 100644
index 5ff76c9..0000000
--- a/Documentation/devicetree/bindings/powerpc/fsl/ssi.txt
+++ /dev/null
@@ -1,73 +0,0 @@
-Freescale Synchronous Serial Interface
-
-The SSI is a serial device that communicates with audio codecs.  It can
-be programmed in AC97, I2S, left-justified, or right-justified modes.
-
-Required properties:
-- compatible:       Compatible list, contains "fsl,ssi".
-- cell-index:       The SSI, <0> = SSI1, <1> = SSI2, and so on.
-- reg:              Offset and length of the register set for the device.
-- 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.  This should be
-                    encoded based on the information in section 2)
-                    depending on the type of interrupt controller you
-                    have.
-- interrupt-parent: The phandle for the interrupt controller that
-                    services interrupts for this device.
-- fsl,mode:         The operating mode for the SSI interface.
-                    "i2s-slave" - I2S mode, SSI is clock slave
-                    "i2s-master" - I2S mode, SSI is clock master
-                    "lj-slave" - left-justified mode, SSI is clock slave
-                    "lj-master" - l.j. mode, SSI is clock master
-                    "rj-slave" - right-justified mode, SSI is clock slave
-                    "rj-master" - r.j., SSI is clock master
-                    "ac97-slave" - AC97 mode, SSI is clock slave
-                    "ac97-master" - AC97 mode, SSI is clock master
-- fsl,playback-dma: Phandle to a node for the DMA channel to use for
-                    playback of audio.  This is typically dictated by SOC
-                    design.  See the notes below.
-- fsl,capture-dma:  Phandle to a node for the DMA channel to use for
-                    capture (recording) of audio.  This is typically dictated
-                    by SOC design.  See the notes below.
-- fsl,fifo-depth:   The number of elements in the transmit and receive FIFOs.
-                    This number is the maximum allowed value for SFCSR[TFWM0].
-- fsl,ssi-asynchronous:
-                    If specified, the SSI is to be programmed in asynchronous
-                    mode.  In this mode, pins SRCK, STCK, SRFS, and STFS must
-                    all be connected to valid signals.  In synchronous mode,
-                    SRCK and SRFS are ignored.  Asynchronous mode allows
-                    playback and capture to use different sample sizes and
-                    sample rates.  Some drivers may require that SRCK and STCK
-                    be connected together, and SRFS and STFS be connected
-                    together.  This would still allow different sample sizes,
-                    but not different sample rates.
-
-Optional properties:
-- codec-handle:     Phandle to a 'codec' node that defines an audio
-                    codec connected to this SSI.  This node is typically
-                    a child of an I2C or other control node.
-
-Child 'codec' node required properties:
-- compatible:       Compatible list, contains the name of the codec
-
-Child 'codec' node optional properties:
-- clock-frequency:  The frequency of the input clock, which typically comes
-                    from an on-board dedicated oscillator.
-
-Notes on fsl,playback-dma and fsl,capture-dma:
-
-On SOCs that have an SSI, specific DMA channels are hard-wired for playback
-and capture.  On the MPC8610, for example, SSI1 must use DMA channel 0 for
-playback and DMA channel 1 for capture.  SSI2 must use DMA channel 2 for
-playback and DMA channel 3 for capture.  The developer can choose which
-DMA controller to use, but the channels themselves are hard-wired.  The
-purpose of these two properties is to represent this hardware design.
-
-The device tree nodes for the DMA channels that are referenced by
-"fsl,playback-dma" and "fsl,capture-dma" must be marked as compatible with
-"fsl,ssi-dma-channel".  The SOC-specific compatible string (e.g.
-"fsl,mpc8610-dma-channel") can remain.  If these nodes are left as
-"fsl,elo-dma-channel" or "fsl,eloplus-dma-channel", then the generic Elo DMA
-drivers (fsldma) will attempt to use them, and it will conflict with the
-sound drivers.
diff --git a/Documentation/devicetree/bindings/sound/fsl,ssi.txt b/Documentation/devicetree/bindings/sound/fsl,ssi.txt
new file mode 100644
index 0000000..5ff76c9
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/fsl,ssi.txt
@@ -0,0 +1,73 @@
+Freescale Synchronous Serial Interface
+
+The SSI is a serial device that communicates with audio codecs.  It can
+be programmed in AC97, I2S, left-justified, or right-justified modes.
+
+Required properties:
+- compatible:       Compatible list, contains "fsl,ssi".
+- cell-index:       The SSI, <0> = SSI1, <1> = SSI2, and so on.
+- reg:              Offset and length of the register set for the device.
+- 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.  This should be
+                    encoded based on the information in section 2)
+                    depending on the type of interrupt controller you
+                    have.
+- interrupt-parent: The phandle for the interrupt controller that
+                    services interrupts for this device.
+- fsl,mode:         The operating mode for the SSI interface.
+                    "i2s-slave" - I2S mode, SSI is clock slave
+                    "i2s-master" - I2S mode, SSI is clock master
+                    "lj-slave" - left-justified mode, SSI is clock slave
+                    "lj-master" - l.j. mode, SSI is clock master
+                    "rj-slave" - right-justified mode, SSI is clock slave
+                    "rj-master" - r.j., SSI is clock master
+                    "ac97-slave" - AC97 mode, SSI is clock slave
+                    "ac97-master" - AC97 mode, SSI is clock master
+- fsl,playback-dma: Phandle to a node for the DMA channel to use for
+                    playback of audio.  This is typically dictated by SOC
+                    design.  See the notes below.
+- fsl,capture-dma:  Phandle to a node for the DMA channel to use for
+                    capture (recording) of audio.  This is typically dictated
+                    by SOC design.  See the notes below.
+- fsl,fifo-depth:   The number of elements in the transmit and receive FIFOs.
+                    This number is the maximum allowed value for SFCSR[TFWM0].
+- fsl,ssi-asynchronous:
+                    If specified, the SSI is to be programmed in asynchronous
+                    mode.  In this mode, pins SRCK, STCK, SRFS, and STFS must
+                    all be connected to valid signals.  In synchronous mode,
+                    SRCK and SRFS are ignored.  Asynchronous mode allows
+                    playback and capture to use different sample sizes and
+                    sample rates.  Some drivers may require that SRCK and STCK
+                    be connected together, and SRFS and STFS be connected
+                    together.  This would still allow different sample sizes,
+                    but not different sample rates.
+
+Optional properties:
+- codec-handle:     Phandle to a 'codec' node that defines an audio
+                    codec connected to this SSI.  This node is typically
+                    a child of an I2C or other control node.
+
+Child 'codec' node required properties:
+- compatible:       Compatible list, contains the name of the codec
+
+Child 'codec' node optional properties:
+- clock-frequency:  The frequency of the input clock, which typically comes
+                    from an on-board dedicated oscillator.
+
+Notes on fsl,playback-dma and fsl,capture-dma:
+
+On SOCs that have an SSI, specific DMA channels are hard-wired for playback
+and capture.  On the MPC8610, for example, SSI1 must use DMA channel 0 for
+playback and DMA channel 1 for capture.  SSI2 must use DMA channel 2 for
+playback and DMA channel 3 for capture.  The developer can choose which
+DMA controller to use, but the channels themselves are hard-wired.  The
+purpose of these two properties is to represent this hardware design.
+
+The device tree nodes for the DMA channels that are referenced by
+"fsl,playback-dma" and "fsl,capture-dma" must be marked as compatible with
+"fsl,ssi-dma-channel".  The SOC-specific compatible string (e.g.
+"fsl,mpc8610-dma-channel") can remain.  If these nodes are left as
+"fsl,elo-dma-channel" or "fsl,eloplus-dma-channel", then the generic Elo DMA
+drivers (fsldma) will attempt to use them, and it will conflict with the
+sound drivers.
-- 
1.8.1.5



From mpa at pengutronix.de  Thu Apr 18 08:33:36 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Thu, 18 Apr 2013 14:33:36 +0200
Subject: [PATCH v4 02/10] ASoC: imx-pcm-dma: DT support
In-Reply-To: <1366288424-7660-1-git-send-email-mpa@pengutronix.de>
References: <1366288424-7660-1-git-send-email-mpa@pengutronix.de>
Message-ID: <1366288424-7660-3-git-send-email-mpa@pengutronix.de>

This patch adds the possibility to pass a of_node as platform_data which
is used by generic-pcm-dma to request a DMA slave channel.

Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
---
 sound/soc/fsl/imx-pcm-dma.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/sound/soc/fsl/imx-pcm-dma.c b/sound/soc/fsl/imx-pcm-dma.c
index c246fb5..8945d22 100644
--- a/sound/soc/fsl/imx-pcm-dma.c
+++ b/sound/soc/fsl/imx-pcm-dma.c
@@ -62,9 +62,11 @@ static const struct snd_dmaengine_pcm_config imx_dmaengine_pcm_config = {
 
 int imx_pcm_dma_init(struct platform_device *pdev)
 {
+	if (pdev->dev.platform_data)
+		pdev->dev.of_node = pdev->dev.platform_data;
+
 	return snd_dmaengine_pcm_register(&pdev->dev, &imx_dmaengine_pcm_config,
 		SND_DMAENGINE_PCM_FLAG_NO_RESIDUE |
-		SND_DMAENGINE_PCM_FLAG_NO_DT |
 		SND_DMAENGINE_PCM_FLAG_COMPAT);
 }
 
-- 
1.8.1.5



From mpa at pengutronix.de  Thu Apr 18 08:33:38 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Thu, 18 Apr 2013 14:33:38 +0200
Subject: [PATCH v4 04/10] ASoC: fsl-ssi: Add support for imx-pcm-fiq
In-Reply-To: <1366288424-7660-1-git-send-email-mpa@pengutronix.de>
References: <1366288424-7660-1-git-send-email-mpa@pengutronix.de>
Message-ID: <1366288424-7660-5-git-send-email-mpa@pengutronix.de>

Add support for non-dma pcm for imx platforms with imx-pcm-fiq support.
Instead of imx-pcm-audio, in this case imx-pcm-fiq-audio device is added
and the SIER flags are set differently.

We need imx-pcm-fiq for some boards that use an incompatible codec.
imx-pcm-fiq handles those codecs differently and allows to operate with
them. DMA is not possible because some data sent by the codecs, e.g.
wm9712, is not in the datastream. Also some data is mixed up in the
fifos, so that we need to sort them out manually.

Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
---

Notes:
    Changes in v4:
     - Add a comment about the reason why we add a imx-pcm-fiq device.
     - Change commit message to include information about the usage of imx-pcm-fiq
    
    Changes in v3:
     - Rename bool "dma" to "use_dma"

 sound/soc/fsl/fsl_ssi.c | 94 +++++++++++++++++++++++++++++++++++++++++--------
 1 file changed, 80 insertions(+), 14 deletions(-)

diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index 0f0bed6..5165d41 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -8,6 +8,26 @@
  * 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.
+ *
+ *
+ * Some notes why imx-pcm-fiq is used instead of DMA on some boards:
+ *
+ * The i.MX SSI core has some nasty limitations in AC97 mode. While most
+ * sane processor vendors have a FIFO per AC97 slot, the i.MX has only
+ * one FIFO which combines all valid receive slots. We cannot even select
+ * which slots we want to receive. The WM9712 with which this driver
+ * was developed with always sends GPIO status data in slot 12 which
+ * we receive in our (PCM-) data stream. The only chance we have is to
+ * manually skip this data in the FIQ handler. With sampling rates different
+ * from 48000Hz not every frame has valid receive data, so the ratio
+ * between pcm data and GPIO status data changes. Our FIQ handler is not
+ * able to handle this, hence this driver only works with 48000Hz sampling
+ * rate.
+ * Reading and writing AC97 registers is another challenge. The core
+ * provides us status bits when the read register is updated with *another*
+ * value. When we read the same register two times (and the register still
+ * contains the same value) these status bits are not set. We work
+ * around this by not polling these bits but only wait a fixed delay.
  */
 
 #include <linux/init.h>
@@ -121,12 +141,14 @@ struct fsl_ssi_private {
 
 	bool new_binding;
 	bool ssi_on_imx;
+	bool use_dma;
 	struct clk *clk;
 	struct platform_device *imx_pcm_pdev;
 	struct snd_dmaengine_dai_dma_data dma_params_tx;
 	struct snd_dmaengine_dai_dma_data dma_params_rx;
 	struct imx_dma_data filter_data_tx;
 	struct imx_dma_data filter_data_rx;
+	struct imx_pcm_fiq_params fiq_params;
 
 	struct {
 		unsigned int rfrc;
@@ -356,7 +378,12 @@ static int fsl_ssi_startup(struct snd_pcm_substream *substream,
 		 */
 
 		/* Enable the interrupts and DMA requests */
-		write_ssi(SIER_FLAGS, &ssi->sier);
+		if (ssi_private->use_dma)
+			write_ssi(SIER_FLAGS, &ssi->sier);
+		else
+			write_ssi(CCSR_SSI_SIER_TIE | CCSR_SSI_SIER_TFE0_EN |
+					CCSR_SSI_SIER_RIE |
+					CCSR_SSI_SIER_RFF0_EN, &ssi->sier);
 
 		/*
 		 * Set the watermark for transmit FIFI 0 and receive FIFO 0. We
@@ -550,7 +577,7 @@ static int fsl_ssi_dai_probe(struct snd_soc_dai *dai)
 {
 	struct fsl_ssi_private *ssi_private = snd_soc_dai_get_drvdata(dai);
 
-	if (ssi_private->ssi_on_imx) {
+	if (ssi_private->ssi_on_imx && ssi_private->use_dma) {
 		dai->playback_dma_data = &ssi_private->dma_params_tx;
 		dai->capture_dma_data = &ssi_private->dma_params_rx;
 	}
@@ -695,6 +722,8 @@ static int fsl_ssi_probe(struct platform_device *pdev)
 	       sizeof(fsl_ssi_dai_template));
 	ssi_private->cpu_dai_drv.name = ssi_private->name;
 
+	ssi_private->use_dma = !of_property_read_bool(np, "fsl,imx-fiq");
+
 	/* Get the addresses and IRQ */
 	ret = of_address_to_resource(np, 0, &res);
 	if (ret) {
@@ -716,12 +745,15 @@ static int fsl_ssi_probe(struct platform_device *pdev)
 		goto error_iomap;
 	}
 
-	/* The 'name' should not have any slashes in it. */
-	ret = request_irq(ssi_private->irq, fsl_ssi_isr, 0, ssi_private->name,
-			  ssi_private);
-	if (ret < 0) {
-		dev_err(&pdev->dev, "could not claim irq %u\n", ssi_private->irq);
-		goto error_irqmap;
+	if (ssi_private->use_dma) {
+		/* The 'name' should not have any slashes in it. */
+		ret = request_irq(ssi_private->irq, fsl_ssi_isr, 0,
+				ssi_private->name, ssi_private);
+		if (ret < 0) {
+			dev_err(&pdev->dev, "could not claim irq %u\n",
+					ssi_private->irq);
+			goto error_irqmap;
+		}
 	}
 
 	/* Are the RX and the TX clocks locked? */
@@ -770,7 +802,7 @@ static int fsl_ssi_probe(struct platform_device *pdev)
 		 */
 		ret = of_property_read_u32_array(pdev->dev.of_node,
 					"fsl,ssi-dma-events", dma_events, 2);
-		if (ret) {
+		if (ret && !ssi_private->use_dma) {
 			dev_err(&pdev->dev, "could not get dma events\n");
 			goto error_clk;
 		}
@@ -809,12 +841,46 @@ static int fsl_ssi_probe(struct platform_device *pdev)
 	}
 
 	if (ssi_private->ssi_on_imx) {
-		ssi_private->imx_pcm_pdev =
-			platform_device_register_simple("imx-pcm-audio",
+		if (!ssi_private->use_dma) {
+
+			/*
+			 * Some boards use an incompatible codec. To get it
+			 * working, we are using imx-fiq-pcm-audio, that
+			 * can handle those codecs. DMA is not possible in this
+			 * situation.
+			 */
+
+			ssi_private->imx_pcm_pdev = platform_device_alloc(
+							"imx-fiq-pcm-audio",
+							pdev->id);
+			if (!ssi_private->imx_pcm_pdev) {
+				ret = -ENOMEM;
+				goto error_dev;
+			}
+
+			ssi_private->fiq_params.irq = ssi_private->irq;
+			ssi_private->fiq_params.base = ssi_private->ssi;
+			ssi_private->fiq_params.dma_params_rx =
+				&ssi_private->dma_params_rx;
+			ssi_private->fiq_params.dma_params_tx =
+				&ssi_private->dma_params_tx;
+
+			platform_set_drvdata(ssi_private->imx_pcm_pdev,
+					&ssi_private->fiq_params);
+			ret = platform_device_add(ssi_private->imx_pcm_pdev);
+			if (ret) {
+				dev_err(&pdev->dev, "Failed to add imx-fiq-pcm-audio device\n");
+				platform_device_put(ssi_private->imx_pcm_pdev);
+				goto error_dev;
+			}
+		} else {
+			ssi_private->imx_pcm_pdev =
+				platform_device_register_simple("imx-pcm-audio",
 							-1, NULL, 0);
-		if (IS_ERR(ssi_private->imx_pcm_pdev)) {
-			ret = PTR_ERR(ssi_private->imx_pcm_pdev);
-			goto error_dev;
+			if (IS_ERR(ssi_private->imx_pcm_pdev)) {
+				ret = PTR_ERR(ssi_private->imx_pcm_pdev);
+				goto error_dev;
+			}
 		}
 	}
 
-- 
1.8.1.5



From mpa at pengutronix.de  Thu Apr 18 08:33:35 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Thu, 18 Apr 2013 14:33:35 +0200
Subject: [PATCH v4 01/10] ASoC: phycore-ac97: Add DT support
In-Reply-To: <1366288424-7660-1-git-send-email-mpa@pengutronix.de>
References: <1366288424-7660-1-git-send-email-mpa@pengutronix.de>
Message-ID: <1366288424-7660-2-git-send-email-mpa@pengutronix.de>

Add devicetree support for this audio soc fabric driver.

DT initialized drivers do not have real device ids, so
imx-pcm-fiq-audio.0 is used without '.0'.

This patch also simplifies the way audmux ports are configured. Before
there was knowledge about the used board. As the audmux driver knows the
used board, we know use the returned errorcodes to correctly set the
audmux port. So this driver does not have to know which board it is
running on.

Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
---

Notes:
    Changes in v4:
     - New property phytec,audmux to check which audmux setup should be
       executed. Checking for fsl,imx21-audmux and fsl,imx31-audmux.
    
    Changes in v3:
     - Add some more information in the commit message.
    
    Changes in v2:
     - Simplify the driver, by combining audmux port configurations. The
       audmux driver actually knows on which platform he is running and
       will return the appropriate error code if we use functions for
       another platform. So we don't need to have the knowledge about it
       in phycore-ac97 and can try both functions. This removes the need
       of different compatibilities and renames it to phycore-ac97.
     - Use a phandle for the cpu_dai link.
     - Add devicetree binding documentation.
     - Rename binding to phytec,phycore-ac97 and fsl,ssi to phytec,ssi
    
    Changes in v2:
     - Simplify the driver, by combining audmux port configurations. The
       audmux driver actually knows on which platform he is running and
       will return the appropriate error code if we use functions for
       another platform. So we don't need to have the knowledge about it
       in phycore-ac97 and can try both functions. This removes the need
       of different compatibilities and renames it to imx27-ac97.
     - Use a phandle for the cpu_dai link.
     - Add devicetree binding documentation.
     - Rename binding to phytec,phycore-ac97 and fsl,ssi to phytec,ssi

 .../bindings/sound/phytec,phycore-ac97.txt         |  14 ++
 sound/soc/fsl/phycore-ac97.c                       | 166 ++++++++++++++++++---
 2 files changed, 158 insertions(+), 22 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/sound/phytec,phycore-ac97.txt

diff --git a/Documentation/devicetree/bindings/sound/phytec,phycore-ac97.txt b/Documentation/devicetree/bindings/sound/phytec,phycore-ac97.txt
new file mode 100644
index 0000000..41201ff
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/phytec,phycore-ac97.txt
@@ -0,0 +1,14 @@
+Phytec phycore AC97
+
+Required properties:
+- compatible: "phytec,phycore-ac97"
+- phytec,ssi: A phandle to the ssi device that is connected to ac97.
+- phytec,audmux: A phandle to the audmux device.
+
+Example:
+
+sound {
+	compatible = "phytec,phycore-ac97";
+	phytec,ssi = <&ssi1>;
+	phytec,audmux = <&audmux>;
+};
diff --git a/sound/soc/fsl/phycore-ac97.c b/sound/soc/fsl/phycore-ac97.c
index f8da6dd..d9f3ac7 100644
--- a/sound/soc/fsl/phycore-ac97.c
+++ b/sound/soc/fsl/phycore-ac97.c
@@ -21,7 +21,10 @@
 
 #include "imx-audmux.h"
 
+#define DRV_NAME "phycore-audio-fabric"
+
 static struct snd_soc_card imx_phycore;
+static struct device_node *phycore_dai_cpu_node;
 
 static struct snd_soc_ops imx_phycore_hifi_ops = {
 };
@@ -32,8 +35,12 @@ static struct snd_soc_dai_link imx_phycore_dai_ac97[] = {
 		.stream_name	= "HiFi",
 		.codec_dai_name		= "wm9712-hifi",
 		.codec_name	= "wm9712-codec",
+#ifdef CONFIG_MACH_IMX27_DT
+		.platform_name	= "imx-fiq-pcm-audio",
+#else
 		.cpu_dai_name	= "imx-ssi.0",
 		.platform_name	= "imx-fiq-pcm-audio.0",
+#endif
 		.ops		= &imx_phycore_hifi_ops,
 	},
 };
@@ -45,35 +52,48 @@ static struct snd_soc_card imx_phycore = {
 	.num_links	= ARRAY_SIZE(imx_phycore_dai_ac97),
 };
 
-static struct platform_device *imx_phycore_snd_ac97_device;
+static void phycore_ac97_imx21_audmux(void)
+{
+	imx_audmux_v1_configure_port(MX27_AUDMUX_HPCR1_SSI0,
+		IMX_AUDMUX_V1_PCR_SYN | /* 4wire mode */
+		IMX_AUDMUX_V1_PCR_TFCSEL(3) |
+		IMX_AUDMUX_V1_PCR_TCLKDIR | /* clock is output */
+		IMX_AUDMUX_V1_PCR_RXDSEL(3));
+	imx_audmux_v1_configure_port(3,
+		IMX_AUDMUX_V1_PCR_SYN | /* 4wire mode */
+		IMX_AUDMUX_V1_PCR_TFCSEL(0) |
+		IMX_AUDMUX_V1_PCR_TFSDIR |
+		IMX_AUDMUX_V1_PCR_RXDSEL(0));
+}
+
+static void phycore_ac97_imx31_audmux(void)
+{
+	imx_audmux_v2_configure_port(3,
+		IMX_AUDMUX_V2_PTCR_SYN | /* 4wire mode */
+		IMX_AUDMUX_V2_PTCR_TFSEL(0) |
+		IMX_AUDMUX_V2_PTCR_TFSDIR,
+		IMX_AUDMUX_V2_PDCR_RXDSEL(0));
+	imx_audmux_v2_configure_port(0,
+		IMX_AUDMUX_V2_PTCR_SYN | /* 4wire mode */
+		IMX_AUDMUX_V2_PTCR_TCSEL(3) |
+		IMX_AUDMUX_V2_PTCR_TCLKDIR, /* clock is output */
+		IMX_AUDMUX_V2_PDCR_RXDSEL(3));
+}
+
 static struct platform_device *imx_phycore_snd_device;
 
+#ifndef CONFIG_MACH_IMX27_DT
+
+static struct platform_device *imx_phycore_snd_ac97_device;
+
 static int __init imx_phycore_init(void)
 {
 	int ret;
 
 	if (machine_is_pca100()) {
-		imx_audmux_v1_configure_port(MX27_AUDMUX_HPCR1_SSI0,
-			IMX_AUDMUX_V1_PCR_SYN | /* 4wire mode */
-			IMX_AUDMUX_V1_PCR_TFCSEL(3) |
-			IMX_AUDMUX_V1_PCR_TCLKDIR | /* clock is output */
-			IMX_AUDMUX_V1_PCR_RXDSEL(3));
-		imx_audmux_v1_configure_port(3,
-			IMX_AUDMUX_V1_PCR_SYN | /* 4wire mode */
-			IMX_AUDMUX_V1_PCR_TFCSEL(0) |
-			IMX_AUDMUX_V1_PCR_TFSDIR |
-			IMX_AUDMUX_V1_PCR_RXDSEL(0));
+		phycore_ac97_imx21_audmux();
 	} else if (machine_is_pcm043()) {
-		imx_audmux_v2_configure_port(3,
-			IMX_AUDMUX_V2_PTCR_SYN | /* 4wire mode */
-			IMX_AUDMUX_V2_PTCR_TFSEL(0) |
-			IMX_AUDMUX_V2_PTCR_TFSDIR,
-			IMX_AUDMUX_V2_PDCR_RXDSEL(0));
-		imx_audmux_v2_configure_port(0,
-			IMX_AUDMUX_V2_PTCR_SYN | /* 4wire mode */
-			IMX_AUDMUX_V2_PTCR_TCSEL(3) |
-			IMX_AUDMUX_V2_PTCR_TCLKDIR, /* clock is output */
-			IMX_AUDMUX_V2_PDCR_RXDSEL(3));
+		phycore_ac97_imx31_audmux();
 	} else {
 		/* return happy. We might run on a totally different machine */
 		return 0;
@@ -120,6 +140,108 @@ static void __exit imx_phycore_exit(void)
 late_initcall(imx_phycore_init);
 module_exit(imx_phycore_exit);
 
+#else  /* !CONFIG_MACH_IMX27_DT */
+
+static const struct of_device_id imx_phycore_ac97_of_dev_id[] = {
+	{
+		.compatible = "phytec,phycore-ac97",
+	}, {
+		/* sentinel */
+	}
+};
+MODULE_DEVICE_TABLE(of, imx_phycore_ac97_of_dev_id);
+
+static int phycore_ac97_setup_devices(struct platform_device *pdev)
+{
+	int ret;
+
+	imx_phycore_snd_device = platform_device_alloc("wm9712-codec", -1);
+	if (!imx_phycore_snd_device)
+		return -ENOMEM;
+
+	ret = platform_device_add(imx_phycore_snd_device);
+	if (ret) {
+		dev_err(&pdev->dev, "ASoC: Platform device allocation failed\n");
+		goto fail1;
+	}
+
+	ret = snd_soc_register_card(&imx_phycore);
+	if (ret) {
+		dev_err(&pdev->dev, "ASoC: soc card registration failed\n");
+		goto fail2;
+	}
+	return 0;
+
+fail2:
+	platform_device_del(imx_phycore_snd_device);
+fail1:
+	platform_device_put(imx_phycore_snd_device);
+	return ret;
+}
+
+static int imx_phycore_ac97_probe(struct platform_device *pdev)
+{
+	int ret;
+	struct device_node *ssi_np;
+	struct device_node *audmux_np;
+
+	imx_phycore.dev = &pdev->dev;
+
+	audmux_np = of_parse_phandle(pdev->dev.of_node, "phytec,audmux", 0);
+	if (!audmux_np) {
+		dev_err(&pdev->dev, "Failed to parse phytec,audmux phandle\n");
+		return -EINVAL;
+	}
+
+	if (of_device_is_compatible(audmux_np, "fsl,imx21-audmux")) {
+		phycore_ac97_imx21_audmux();
+	} else if (of_device_is_compatible(audmux_np, "fsl,imx31-audmux")) {
+		phycore_ac97_imx31_audmux();
+	} else {
+		dev_err(&pdev->dev, "Unknown audmux, failed to setup audmux\n");
+		of_node_put(audmux_np);
+		return -EINVAL;
+	}
+	of_node_put(audmux_np);
+
+	ssi_np = of_parse_phandle(pdev->dev.of_node, "phytec,ssi", 0);
+	if (!ssi_np) {
+		dev_err(&pdev->dev, "No valid ssi phandle found\n");
+		return -EINVAL;
+	}
+
+	imx_phycore_dai_ac97[0].cpu_of_node = ssi_np;
+	phycore_dai_cpu_node = ssi_np;
+
+
+	ret = phycore_ac97_setup_devices(pdev);
+	if (ret)
+		of_node_put(phycore_dai_cpu_node);
+
+	return ret;
+}
+
+static int imx_phycore_ac97_remove(struct platform_device *pdev)
+{
+	of_node_put(phycore_dai_cpu_node);
+	platform_device_unregister(imx_phycore_snd_device);
+	return 0;
+}
+
+static struct platform_driver imx_phycore_ac97_driver = {
+	.probe		= imx_phycore_ac97_probe,
+	.remove		= imx_phycore_ac97_remove,
+	.driver		= {
+		.name	= DRV_NAME,
+		.owner	= THIS_MODULE,
+		.of_match_table = imx_phycore_ac97_of_dev_id,
+	},
+};
+
+module_platform_driver(imx_phycore_ac97_driver);
+
+#endif  /* CONFIG_MACH_IMX27_DT */
+
 MODULE_AUTHOR("Sascha Hauer <s.hauer at pengutronix.de>");
-MODULE_DESCRIPTION("PhyCORE ALSA SoC driver");
+MODULE_DESCRIPTION(DRV_NAME ": PhyCORE ALSA SoC fabric driver");
 MODULE_LICENSE("GPL");
-- 
1.8.1.5



From mpa at pengutronix.de  Thu Apr 18 08:33:34 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Thu, 18 Apr 2013 14:33:34 +0200
Subject: [PATCH v4 00/10] ASoC: fsl-ssi: ac97-slave support
Message-ID: <1366288424-7660-1-git-send-email-mpa@pengutronix.de>

Hi,

This series adds DT support for phycore-ac97. It is now based on the pcm dma
cleanups from Lars. Beside ac97 support, the series adds fsl-ssi imx-pcm-fiq
and generic DMA binding handling.

Regards,

Markus

Changes in v4:
 - phycore-ac97 uses the iomux functions based on audmux phandle now.
 - fsl-ssi imx-pcm-fiq got some new comments about problems with imx-ssi and
   incompatible codecs

Changes in v3:
 - Rebased onto pcm dma cleanup patches
 - A lot of cleanups for the fsl-ssi ac97 integration
 - Some small changes which are listed in the notes of the patches.

Markus Pargmann (10):
      ASoC: phycore-ac97: Add DT support
      ASoC: imx-pcm-dma: DT support
      ASoC: imx-pcm-fiq: Introduce pcm-fiq-params
      ASoC: fsl-ssi: Add support for imx-pcm-fiq
      ASoC: fsl-ssi: Use generic DMA bindings if possible
      ARM: imx: Export ac97 reset functions
      ASoC: fsl-ssi: imx ac97 support
      ASoC: fsl: Kconfig: Use fsl-ssi for phycore-ac97
      ASoC: fsl: Move fsl-ssi binding doc to sound/
      ASoC: fsl: Update fsl-ssi binding doc

 Documentation/devicetree/bindings/{powerpc/fsl/ssi.txt => sound/fsl,ssi.txt} |  10 ++
 Documentation/devicetree/bindings/sound/phytec,phycore-ac97.txt              |  14 ++
 arch/arm/mach-imx/mach-pca100.c                                              |   7 +-
 arch/arm/mach-imx/mach-pcm043.c                                              |   7 +-
 sound/soc/fsl/Kconfig                                                        |   2 +-
 sound/soc/fsl/fsl_ssi.c                                                      | 512 ++++++++++++++++++++++++++++++++++++++++++++++++----------
 sound/soc/fsl/imx-pcm-dma.c                                                  |   4 +-
 sound/soc/fsl/imx-pcm-fiq.c                                                  |  16 +-
 sound/soc/fsl/imx-pcm.h                                                      |   9 ++
 sound/soc/fsl/imx-ssi.c                                                      |   7 +-
 sound/soc/fsl/imx-ssi.h                                                      |   1 +
 sound/soc/fsl/phycore-ac97.c                                                 | 166 ++++++++++++++++---
 12 files changed, 633 insertions(+), 122 deletions(-)
 rename Documentation/devicetree/bindings/{powerpc/fsl/ssi.txt => sound/fsl,ssi.txt} (88%)
 create mode 100644 Documentation/devicetree/bindings/sound/phytec,phycore-ac97.txt



From linux at arm.linux.org.uk  Thu Apr 18 08:39:31 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Thu, 18 Apr 2013 13:39:31 +0100
Subject: [PATCH 1/2] Allow constructor name selection by architecture.
In-Reply-To: <CAE1uF8dCy3m3TO4xa6Cc3i-CM3QYUFADZH_6o+hgy6MSPEWnyQ@mail.gmail.com>
References: <1338230018-31052-1-git-send-email-vincent.sanders@collabora.co.uk>
 <1338230018-31052-2-git-send-email-vincent.sanders@collabora.co.uk>
 <20120528203005.GA20560@merkur.ravnborg.org>
 <20120529090614.GD12217@n2100.arm.linux.org.uk>
 <20120606101253.GM8262@n2100.arm.linux.org.uk>
 <87F2CC87-0FAF-49CB-AE70-423FB063A0E5@mvista.com>
 <20130401215834.GA5972@merkur.ravnborg.org>
 <CAE1uF8dCy3m3TO4xa6Cc3i-CM3QYUFADZH_6o+hgy6MSPEWnyQ@mail.gmail.com>
Message-ID: <20130418123931.GR14496@n2100.arm.linux.org.uk>

Looks to me like this has died again.  Unless Sam responds shortly,
I'm going to ask for this to be put into the patch system and I'll
just apply it for 3.10 and be done with it.

On Mon, Apr 01, 2013 at 06:21:51PM -0400, George G. Davis wrote:
> On Mon, Apr 1, 2013 at 5:58 PM, Sam Ravnborg <sam at ravnborg.org> wrote:
> > On Mon, Apr 01, 2013 at 05:47:38PM -0400, George G. Davis wrote:
> >> On Jun 6, 2012, at 6:12 AM, Russell King - ARM Linux wrote:
> >> > On Tue, May 29, 2012 at 10:06:14AM +0100, Russell King - ARM Linux wrote:
> >> >> On Mon, May 28, 2012 at 10:30:05PM +0200, Sam Ravnborg wrote:
> >> >>> On Mon, May 28, 2012 at 07:33:37PM +0100, Vincent Sanders wrote:
> >> >>>> From: Vincent Sanders <vince at collabora.co.uk>
> >> >>>>
> >> >>>> The constructor symbol name is different between platforms. Allow this
> >> >>>> to be selected by configuration and set suitable default values.
> >> >>>>
> >> >>>> Signed-off-by: Vincent Sanders <vincent.sanders at collabora.co.uk>
> >> >>>> ---
> >> >>>> include/asm-generic/vmlinux.lds.h |    6 +++---
> >> >>>> init/Kconfig                      |    6 ++++++
> >> >>>> kernel/module.c                   |    2 +-
> >> >>>> 3 files changed, 10 insertions(+), 4 deletions(-)
> >> >>>>
> >> >>>> diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
> >> >>>> index 8aeadf6..fd34808 100644
> >> >>>> --- a/include/asm-generic/vmlinux.lds.h
> >> >>>> +++ b/include/asm-generic/vmlinux.lds.h
> >> >>>> @@ -471,9 +471,9 @@
> >> >>>>  }
> >> >>>>
> >> >>>> #ifdef CONFIG_CONSTRUCTORS
> >> >>>> -#define KERNEL_CTORS()  . = ALIGN(8);                      \
> >> >>>> -                        VMLINUX_SYMBOL(__ctors_start) = .; \
> >> >>>> -                        *(.ctors)                          \
> >> >>>> +#define KERNEL_CTORS()  . = ALIGN(8);                                   \
> >> >>>> +                        VMLINUX_SYMBOL(__ctors_start) = .;              \
> >> >>>> +                        *(CONFIG_CONSTRUCTORS_NAME)                     \
> >> >>>>                  VMLINUX_SYMBOL(__ctors_end) = .;
> >> >>>
> >> >>> What is wrong with adding both "standard" names for ctors uncnditionally?
> >> >>> Like this:
> >> >>>>                  *(.ctors)                          \
> >> >>>> +                        *(.init_array)                     \
> >> >>
> >> >> That doesn't get rid of CONFIG_CONSTRUCTORS_NAME, because it's needed
> >> >> in the module code.  Do you have a suggestion to solve that as well?
> >> >
> >> > Ping.
> >>
> >> Pinging this back to life.  I'd like to see GCOV for ARM eABI finally make it upstream.
> >> So, any objections to this?  Should it be resubmitted?
> >
> > Why is CONFIG_CONSTRUCTORS_NAME needed in module code?
> 
> Because ARM eABI uses the .init_array section for C++ constructors,
> rather than .ctors.
> So the patch defined CONFIG_CONSTRUCTORS_NAME to set the correct section name
> for ARM eABI while leaving non-ARM-eABI as before, .ctors.  Here are the changes
> from the patch for reference:
> 
> diff --git a/init/Kconfig b/init/Kconfig
> index 6cfd71d..52181a1 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -20,6 +20,12 @@ config CONSTRUCTORS
>         bool
>         depends on !UML
> 
> +config CONSTRUCTORS_NAME
> +       string
> +       depends on CONSTRUCTORS
> +       default ".init_array" if ARM && AEABI
> +       default ".ctors"
> +
>  config HAVE_IRQ_WORK
>         bool
> 
> diff --git a/kernel/module.c b/kernel/module.c
> index 78ac6ec..e5fad5e 100644
> --- a/kernel/module.c
> +++ b/kernel/module.c
> @@ -2600,7 +2600,7 @@ static void find_module_sections(struct module
> *mod, struct load_info *info)
>         mod->unused_gpl_crcs = section_addr(info, "__kcrctab_unused_gpl");
>  #endif
>  #ifdef CONFIG_CONSTRUCTORS
> -       mod->ctors = section_objs(info, ".ctors",
> +       mod->ctors = section_objs(info, CONFIG_CONSTRUCTORS_NAME,
>                                   sizeof(*mod->ctors), &mod->num_ctors);
>  #endif
> 
> W/o the above, GCOV does not work on ARM eABI for kernel modules.
> Meanwhile, it still works as before for non-ARM-eABI kernel modules.
> 
> Thanks!
> 
> --
> Regards,
> George


From grant.likely at secretlab.ca  Thu Apr 18 08:40:21 2013
From: grant.likely at secretlab.ca (Grant Likely)
Date: Thu, 18 Apr 2013 13:40:21 +0100
Subject: [RFC PATCH 2/2] ARM: DT: kernel: DT cpu node bindings update
In-Reply-To: <516EBC66.20508@wwwdotorg.org>
References: <1366042402-8987-1-git-send-email-lorenzo.pieralisi@arm.com>
 <1366042402-8987-3-git-send-email-lorenzo.pieralisi@arm.com>
 <516C544A.4090107@wwwdotorg.org>
 <20130417091457.GB5012@e106331-lin.cambridge.arm.com>
 <516EBC66.20508@wwwdotorg.org>
Message-ID: <20130418124021.DE4C63E118C@localhost>

On Wed, 17 Apr 2013 09:14:46 -0600, Stephen Warren <swarren at wwwdotorg.org> wrote:
> On 04/17/2013 03:14 AM, Mark Rutland wrote:
> > Hi Stephen,
> > 
> >>> +	- enable-method
> >>> +		Usage: required on ARM 64-bit systems, optional on ARM 32-bit
> >>> +		       systems
> >>> +		Value type: <string>
> >>> +		Definition: On ARM 64-bit systems must be "spin-table" [1].
> >>
> >> Can that be an integer instead? with dtc+cpp support, that shouldn't
> >> hurt the eyes too much any more.
> > 
> > The "enable-method" property is described as a stringlist by ePAPR, and is
> > currently in use on arm64 as such. It *must* remain a string(list) for arm64.
> > 
> > Having it as an integer for arm is only going to cause us additional work,
> > makes it impossible to share a common dt between 64bit and 32bit, and goes
> > against the standard. I think it should be a stringlist for arm.
> 
> OK, that's a great reason for this case.
> 
> I hope we don't introduce any more standards that use strings, but that
> may just be my personal preference...

We've got lots of bindings using strings like this. I don't really see any problem with it.

g.



From grant.likely at secretlab.ca  Thu Apr 18 08:48:32 2013
From: grant.likely at secretlab.ca (Grant Likely)
Date: Thu, 18 Apr 2013 13:48:32 +0100
Subject: [PATCH v7 1/3] of/pci: Unify pci_process_bridge_OF_ranges from
 Microblaze and PowerPC
In-Reply-To: <20130417162223.GC27197@titan.lakedaemon.net>
References: <1366107508-12672-1-git-send-email-Andrew.Murray@arm.com>
 <1366107508-12672-2-git-send-email-Andrew.Murray@arm.com>
 <20130416103005.GB12726@arm.com> <20130417160015.777453E2B73@localhost>
 <20130417161036.GB27197@titan.lakedaemon.net>
 <CACxGe6sNk=wNinTcMHbJa5o-56Tyh=0CnFSEW+Hk-ujpjeg2gQ@mail.gmail.com>
 <20130417162223.GC27197@titan.lakedaemon.net>
Message-ID: <20130418124832.D2C733E118C@localhost>

On Wed, 17 Apr 2013 12:22:23 -0400, Jason Cooper <jason at lakedaemon.net> wrote:
> On Wed, Apr 17, 2013 at 05:17:48PM +0100, Grant Likely wrote:
> > On Wed, Apr 17, 2013 at 5:10 PM, Jason Cooper <jason at lakedaemon.net> wrote:
> > > On Wed, Apr 17, 2013 at 05:00:15PM +0100, Grant Likely wrote:
> > >> On Tue, 16 Apr 2013 11:30:06 +0100, Andrew Murray <andrew.murray at arm.com> wrote:
> > >> > On Tue, Apr 16, 2013 at 11:18:26AM +0100, Andrew Murray wrote:
> > >> > > The pci_process_bridge_OF_ranges function, used to parse the "ranges"
> > >> > > property of a PCI host device, is found in both Microblaze and PowerPC
> > >> > > architectures. These implementations are nearly identical. This patch
> > >> > > moves this common code to a common place.
> > >> > >
> > >> > > Signed-off-by: Andrew Murray <Andrew.Murray at arm.com>
> > >> > > Signed-off-by: Liviu Dudau <Liviu.Dudau at arm.com>
> > >> > > Reviewed-by: Rob Herring <rob.herring at calxeda.com>
> > >> > > Tested-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> > >> > > Tested-by: Linus Walleij <linus.walleij at linaro.org>
> > >> > > Acked-by: Michal Simek <monstr at monstr.eu>
> > >> > > ---
> > >> > >  arch/microblaze/include/asm/pci-bridge.h |    5 +-
> > >> > >  arch/microblaze/pci/pci-common.c         |  192 ----------------------------
> > >> > >  arch/powerpc/include/asm/pci-bridge.h    |    5 +-
> > >> > >  arch/powerpc/kernel/pci-common.c         |  192 ----------------------------
> > >> >
> > >> > Is there anyone on linuxppc-dev/linux-mips that can help test this patchset?
> > >> >
> > >> > I've tested that it builds on powerpc with a variety of configs (some which
> > >> > include fsl_pci.c implementation). Though I don't have hardware to verify that
> > >> > it works.
> > >> >
> > >> > I haven't tested this builds or runs on MIPS.
> > >> >
> > >> > You shouldn't see any difference in behaviour or new warnings and PCI devices
> > >> > should continue to operate as before.
> > >>
> > >> I've got through a line-by-line comparison between powerpc, microblaze,
> > >> and then new code. The differences are purely cosmetic, so I have
> > >> absolutely no concerns about this patch. I've applied it to my tree.
> > >
> > > oops.  Due to the number of dependencies the mvebu-pcie series has (this
> > > being one of them, we (arm-soc/mvebu) asked if we could take this
> > > through our tree.  Rob Herring agreed to this several days ago.  Is this
> > > a problem for you?
> > >
> > > It would truly (dogs and cats living together) upset the apple cart for
> > > us at this stage to pipe these through a different tree...
> > 
> > Not a problem at all. I'll drop it.
> 
> Great!  Thanks.

You can add my Acked-by: Grant Likely <grant.likely at linaro.org> to the
first patch. I've not reviewed out the second or third patches yet.

None of this appears to be in linux-next yet. I've boot tested on
PowerPC, but that isn't the same as an ack by the PowerPC maintainers.
It is probably too late for the whole now since we're after -rc7.
However, if you ask me to, I have absolutely no problem putting the
first patch into my tree for v3.10 merging. I went over the patch
line-by-line and am convinced that it is functionally identical.

Let me know if you need me to do this.

g.



From andrew.murray at arm.com  Thu Apr 18 08:59:10 2013
From: andrew.murray at arm.com (Andrew Murray)
Date: Thu, 18 Apr 2013 13:59:10 +0100
Subject: [PATCH v7 3/3] of/pci: mips: convert to common of_pci_range_parser
In-Reply-To: <CACRpkdbBaT1OKr5t8HW4+8y_wSDmGxmewAyVMekx8S-K9s3K8Q@mail.gmail.com>
References: <1366107508-12672-1-git-send-email-Andrew.Murray@arm.com>
 <1366107508-12672-4-git-send-email-Andrew.Murray@arm.com>
 <CACRpkdbBaT1OKr5t8HW4+8y_wSDmGxmewAyVMekx8S-K9s3K8Q@mail.gmail.com>
Message-ID: <20130418125910.GA17128@arm.com>

On Wed, Apr 17, 2013 at 04:42:48PM +0100, Linus Walleij wrote:
> On Tue, Apr 16, 2013 at 12:18 PM, Andrew Murray <Andrew.Murray at arm.com> wrote:
> 
> > This patch converts the pci_load_of_ranges function to use the new common
> > of_pci_range_parser.
> >
> > Signed-off-by: Andrew Murray <Andrew.Murray at arm.com>
> > Signed-off-by: Liviu Dudau <Liviu.Dudau at arm.com>
> > Reviewed-by: Rob Herring <rob.herring at calxeda.com>
> 
> Tested-by: Linus Walleij <linus.walleij at linaro.org>

Jason - you may not have seen this, but here (Linus Walleij) is another Tested-by
to add to this patch in your tree (if you can).

Andrew Murray


From nicolas.ferre at atmel.com  Thu Apr 18 09:01:08 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Thu, 18 Apr 2013 15:01:08 +0200
Subject: [PATCH 0/5] ARM: at91: some more DT enhancements
Message-ID: <cover.1366289869.git.nicolas.ferre@atmel.com>

Addition of the Acme systems Fox G20 board and some additions to the
at91sam9x5 DT and Aria board.

Douglas Gilbert (1):
  ARM: at91: add Acme Systems Fox G20 board

Nicolas Ferre (4):
  ARM: at91: at91sam9x5 RTC is not compatible with at91rm9200 one
  ARM: at91/at91-ariag25.dts: add RTC node
  ARM: at91/at91sam9x5.dtsi: add UART0/1 nodes
  ARM: at91/at91-ariag25.dts: UART0/1 nodes are disabled

 arch/arm/boot/dts/Makefile         |   1 +
 arch/arm/boot/dts/at91-ariag25.dts |  21 +++--
 arch/arm/boot/dts/at91-foxg20.dts  | 166 +++++++++++++++++++++++++++++++++++++
 arch/arm/boot/dts/at91sam9x5.dtsi  |  20 ++++-
 4 files changed, 201 insertions(+), 7 deletions(-)
 create mode 100644 arch/arm/boot/dts/at91-foxg20.dts

-- 
1.8.0



From nicolas.ferre at atmel.com  Thu Apr 18 09:01:09 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Thu, 18 Apr 2013 15:01:09 +0200
Subject: [PATCH 1/5] ARM: at91: at91sam9x5 RTC is not compatible with
 at91rm9200 one
In-Reply-To: <cover.1366289869.git.nicolas.ferre@atmel.com>
References: <cover.1366289869.git.nicolas.ferre@atmel.com>
Message-ID: <864f10566b35864d469f6ff2913b9afaa0c69350.1366289869.git.nicolas.ferre@atmel.com>

Due to a bug with RTC IMR, we cannot consider at91sam9x5 RTC compatible
with the previous one. Modify DT compatibility string, even if the driver
is not yet modified to take it into account.

Signed-off-by: Nicolas Ferre <nicolas.ferre at atmel.com>
---
 arch/arm/boot/dts/at91sam9x5.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/at91sam9x5.dtsi b/arch/arm/boot/dts/at91sam9x5.dtsi
index a3d4464..58747f3 100644
--- a/arch/arm/boot/dts/at91sam9x5.dtsi
+++ b/arch/arm/boot/dts/at91sam9x5.dtsi
@@ -564,7 +564,7 @@
 			};
 
 			rtc at fffffeb0 {
-				compatible = "atmel,at91rm9200-rtc";
+				compatible = "atmel,at91sam9x5-rtc";
 				reg = <0xfffffeb0 0x40>;
 				interrupts = <1 4 7>;
 				status = "disabled";
-- 
1.8.0



From nicolas.ferre at atmel.com  Thu Apr 18 09:01:10 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Thu, 18 Apr 2013 15:01:10 +0200
Subject: [PATCH 2/5] ARM: at91/at91-ariag25.dts: add RTC node
In-Reply-To: <cover.1366289869.git.nicolas.ferre@atmel.com>
References: <cover.1366289869.git.nicolas.ferre@atmel.com>
Message-ID: <e9b6608c125ef499d095a65e6b2f7c8b06d3f469.1366289869.git.nicolas.ferre@atmel.com>

Reported-by: Douglas Gilbert <dgilbert at interlog.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre at atmel.com>
---
 arch/arm/boot/dts/at91-ariag25.dts | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/at91-ariag25.dts b/arch/arm/boot/dts/at91-ariag25.dts
index c7aebba..1de619c 100644
--- a/arch/arm/boot/dts/at91-ariag25.dts
+++ b/arch/arm/boot/dts/at91-ariag25.dts
@@ -138,6 +138,10 @@
 					};
 				};
 			};
+
+			rtc at fffffeb0 {
+				status = "okay";
+			};
 		};
 
 		usb0: ohci at 00600000 {
-- 
1.8.0



From nicolas.ferre at atmel.com  Thu Apr 18 09:01:11 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Thu, 18 Apr 2013 15:01:11 +0200
Subject: [PATCH 3/5] ARM: at91/at91sam9x5.dtsi: add UART0/1 nodes
In-Reply-To: <cover.1366289869.git.nicolas.ferre@atmel.com>
References: <cover.1366289869.git.nicolas.ferre@atmel.com>
Message-ID: <0209fb2e06ac4a81f614c8c3b8d7b154c52e8419.1366289869.git.nicolas.ferre@atmel.com>

Reported-by: Douglas Gilbert <dgilbert at interlog.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre at atmel.com>
---
 arch/arm/boot/dts/at91sam9x5.dtsi | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/arch/arm/boot/dts/at91sam9x5.dtsi b/arch/arm/boot/dts/at91sam9x5.dtsi
index 58747f3..2cc33fb 100644
--- a/arch/arm/boot/dts/at91sam9x5.dtsi
+++ b/arch/arm/boot/dts/at91sam9x5.dtsi
@@ -522,6 +522,24 @@
 				status = "disabled";
 			};
 
+			uart0: serial at f8040000 {
+				compatible = "atmel,at91sam9260-usart";
+				reg = <0xf8040000 0x200>;
+				interrupts = <15 4 5>;
+				pinctrl-names = "default";
+				pinctrl-0 = <&pinctrl_uart0>;
+				status = "disabled";
+			};
+
+			uart1: serial at f8044000 {
+				compatible = "atmel,at91sam9260-usart";
+				reg = <0xf8044000 0x200>;
+				interrupts = <16 4 5>;
+				pinctrl-names = "default";
+				pinctrl-0 = <&pinctrl_uart1>;
+				status = "disabled";
+			};
+
 			adc0: adc at f804c000 {
 				compatible = "atmel,at91sam9260-adc";
 				reg = <0xf804c000 0x100>;
-- 
1.8.0



From nicolas.ferre at atmel.com  Thu Apr 18 09:01:12 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Thu, 18 Apr 2013 15:01:12 +0200
Subject: [PATCH 4/5] ARM: at91/at91-ariag25.dts: UART0/1 nodes are disabled
In-Reply-To: <cover.1366289869.git.nicolas.ferre@atmel.com>
References: <cover.1366289869.git.nicolas.ferre@atmel.com>
Message-ID: <280be558b85a251913a51c7c24824c2a8b3d7eba.1366289869.git.nicolas.ferre@atmel.com>

UART0 is moved to generic at91sam9x5.dtsi file.
Both uarts are "disabled" as the corresponding pins on
Aria documentation are shown as GPIOs.

Signed-off-by: Nicolas Ferre <nicolas.ferre at atmel.com>
---
 arch/arm/boot/dts/at91-ariag25.dts | 17 +++++++++++------
 1 file changed, 11 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/at91-ariag25.dts b/arch/arm/boot/dts/at91-ariag25.dts
index 1de619c..5b07380 100644
--- a/arch/arm/boot/dts/at91-ariag25.dts
+++ b/arch/arm/boot/dts/at91-ariag25.dts
@@ -21,6 +21,7 @@
 		serial3 = &usart2;
 		serial4 = &usart3;
 		serial5 = &uart0;
+		serial6 = &uart1;
 	};
 
 	chosen {
@@ -112,13 +113,17 @@
 				status = "okay";
 			};
 
+			/*
+			 * UART0/1 pins are marked as GPIO on
+			 * Aria documentation.
+			 * Change to "okay" if you need additional serial ports
+			 */
 			uart0: serial at f8040000 {
-				compatible = "atmel,at91sam9260-usart";
-				reg = <0xf8040000 0x200>;
-				interrupts = <15 4 5>;
-				pinctrl-names = "default";
-				pinctrl-0 = <&pinctrl_uart0>;
-				status = "okay";
+				status = "disabled";
+			};
+
+			uart1: serial at f8044000 {
+				status = "disabled";
 			};
 
 			adc0: adc at f804c000 {
-- 
1.8.0



From nicolas.ferre at atmel.com  Thu Apr 18 09:01:13 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Thu, 18 Apr 2013 15:01:13 +0200
Subject: [PATCH 5/5] ARM: at91: add Acme Systems Fox G20 board
In-Reply-To: <cover.1366289869.git.nicolas.ferre@atmel.com>
References: <cover.1366289869.git.nicolas.ferre@atmel.com>
Message-ID: <a647ac59d50fdee9a0e9e87f362febe1ad2b1264.1366289869.git.nicolas.ferre@atmel.com>

From: Douglas Gilbert <dgilbert at interlog.com>

Signed-off-by: Douglas Gilbert <dgilbert at interlog.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre at atmel.com>
---
 arch/arm/boot/dts/Makefile        |   1 +
 arch/arm/boot/dts/at91-foxg20.dts | 166 ++++++++++++++++++++++++++++++++++++++
 2 files changed, 167 insertions(+)
 create mode 100644 arch/arm/boot/dts/at91-foxg20.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index b07f162..914fe65 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -16,6 +16,7 @@ dtb-$(CONFIG_ARCH_AT91) += at91sam9263ek.dtb
 dtb-$(CONFIG_ARCH_AT91) += tny_a9263.dtb
 dtb-$(CONFIG_ARCH_AT91) += usb_a9263.dtb
 # sam9g20
+dtb-$(CONFIG_ARCH_AT91) += at91-foxg20.dtb
 dtb-$(CONFIG_ARCH_AT91) += at91sam9g20ek.dtb
 dtb-$(CONFIG_ARCH_AT91) += at91sam9g20ek_2mmc.dtb
 dtb-$(CONFIG_ARCH_AT91) += kizbox.dtb
diff --git a/arch/arm/boot/dts/at91-foxg20.dts b/arch/arm/boot/dts/at91-foxg20.dts
new file mode 100644
index 0000000..7d24ef7
--- /dev/null
+++ b/arch/arm/boot/dts/at91-foxg20.dts
@@ -0,0 +1,166 @@
+/*
+ * at91-foxg20.dts - Device Tree file for Acme Systems FoxG20 board
+ *
+ * Based on DT files for at91sam9g20ek evaluation board (AT91SAM9G20 SoC)
+ *
+ * Copyright (C) 2013 Douglas Gilbert <dgilbert at interlog.com>
+ *
+ * Licensed under GPLv2 or later.
+ */
+/dts-v1/;
+/include/ "at91sam9g20.dtsi"
+
+/ {
+	model = "Acme Systems FoxG20";
+	compatible = "acme,foxg20", "atmel,at91sam9g20", "atmel,at91sam9";
+
+	chosen {
+		bootargs = "console=ttyS0,115200 root=/dev/mmcblk0p2 rw rootwait";
+	};
+
+	memory {
+		reg = <0x20000000 0x4000000>;
+	};
+
+	clocks {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges;
+
+		main_clock: clock at 0 {
+			compatible = "atmel,osc", "fixed-clock";
+			clock-frequency = <18432000>;
+		};
+	};
+
+	ahb {
+		apb {
+			usb1: gadget at fffa4000 {
+				atmel,vbus-gpio = <&pioC 6 0>;
+				status = "okay";
+			};
+
+			mmc0: mmc at fffa8000 {
+				pinctrl-0 = <
+					&pinctrl_mmc0_clk
+					&pinctrl_mmc0_slot1_cmd_dat0
+					&pinctrl_mmc0_slot1_dat1_3>;
+				status = "okay";
+				slot at 1 {
+					reg = <1>;
+					bus-width = <4>;
+				};
+			};
+
+			usart0: serial at fffb0000 {
+				pinctrl-0 =
+					<&pinctrl_usart0
+					 &pinctrl_usart0_rts
+					 &pinctrl_usart0_cts
+					>;
+				status = "okay";
+			};
+
+			usart1: serial at fffb4000 {
+				status = "okay";
+			};
+
+			usart2: serial at fffb8000 {
+				status = "okay";
+			};
+
+			macb0: ethernet at fffc4000 {
+				phy-mode = "rmii";
+				status = "okay";
+			};
+
+			spi0: spi at fffc8000 {
+				cs-gpios = <0>, <&pioC 11 0>, <0>, <0>;
+				mtd_dataflash at 0 {
+					compatible = "atmel,at45", "atmel,dataflash";
+					spi-max-frequency = <50000000>;
+					reg = <1>;
+				};
+				status = "disabled";
+			};
+
+			usart3: serial at fffd0000 {
+				status = "okay";
+			};
+
+			uart0: serial at fffd4000 {
+				status = "okay";
+			};
+
+			uart1: serial at fffd8000 {
+				status = "okay";
+			};
+
+			dbgu: serial at fffff200 {
+				status = "okay";
+			};
+
+			pinctrl at fffff400 {
+				board {
+					pinctrl_pck0_as_mck: pck0_as_mck {
+						atmel,pins =
+							<2 1 0x2 0x0>;	/* PC1 periph B */
+					};
+				};
+
+				mmc0_slot1 {
+					pinctrl_board_mmc0_slot1: mmc0_slot1-board {
+						atmel,pins =
+							<2 9 0x0 0x5>;	/* PC9 gpio CD pin pull up and deglitch */
+					};
+				};
+
+				i2c0 {
+					pinctrl_i2c0: i2c0-0 {
+						atmel,pins =
+							<0 23 0x1 0x2	/* TWD (SDA) PA23 periph A, open drain */
+							 0 24 0x1 0x2>;	/* TWCK (SCL) PA24 periph A, open drain */
+					};
+				};
+			};
+
+			watchdog at fffffd40 {
+				status = "okay";
+			};
+		};
+
+		usb0: ohci at 00500000 {
+			num-ports = <2>;
+			status = "okay";
+		};
+	};
+
+	i2c at 0 {
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_i2c0>;
+		i2c-gpio,delay-us = <5>;	/* ~85 kHz */
+		status = "okay";
+	};
+
+	leds {
+		compatible = "gpio-leds";
+
+		/* red LED marked "PC7" near mini USB (device) receptacle */
+		user_led {
+			label = "user_led";
+			gpios = <&pioC 7 0>;	/* PC7 */
+			linux,default-trigger = "heartbeat";
+		};
+	};
+
+	gpio_keys {
+		compatible = "gpio-keys";
+
+		btn {
+			label = "Button";
+			gpios = <&pioC 4 1>;
+			linux,code = <0x103>;
+			gpio-key,wakeup;
+		};
+	};
+};
-- 
1.8.0



From mpa at pengutronix.de  Thu Apr 18 09:03:02 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Thu, 18 Apr 2013 15:03:02 +0200
Subject: [PATCH v4 1/2] imxfb: Set alpha value of the framebuffer
In-Reply-To: <1366290183-367-1-git-send-email-mpa@pengutronix.de>
References: <1366290183-367-1-git-send-email-mpa@pengutronix.de>
Message-ID: <1366290183-367-2-git-send-email-mpa@pengutronix.de>

From: Christian Hemp <c.hemp at phytec.de>

Based on Sascha Hauer's patch i.MX27 clock: Do not disable lcd clocks during
startup.
This patch gives a interface to chance the alphavalue of the framebuffer.

Signed-off-by: Christian Hemp <c.hemp at phytec.de>

rebased to 3.7
Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
---
 drivers/video/imxfb.c                     | 35 +++++++++++++++++++++++++++++++
 include/linux/platform_data/video-imxfb.h |  3 +++
 2 files changed, 38 insertions(+)

diff --git a/drivers/video/imxfb.c b/drivers/video/imxfb.c
index 0abf2bf..ef2b587 100644
--- a/drivers/video/imxfb.c
+++ b/drivers/video/imxfb.c
@@ -31,6 +31,7 @@
 #include <linux/dma-mapping.h>
 #include <linux/io.h>
 #include <linux/math64.h>
+#include <linux/uaccess.h>
 
 #include <linux/platform_data/video-imxfb.h>
 
@@ -112,6 +113,10 @@
 #define LCDISR_EOF	(1<<1)
 #define LCDISR_BOF	(1<<0)
 
+#define LCDC_LGWCR	0x64
+#define LGWCR_GWAV(alpha)	(((alpha) & 0xff) << 24)
+#define LGWCR_GWE	(1 << 22)
+
 /* Used fb-mode. Can be set on kernel command line, therefore file-static. */
 static const char *fb_mode;
 
@@ -610,6 +615,35 @@ static int imxfb_blank(int blank, struct fb_info *info)
 	return 0;
 }
 
+static int imxfb_ioctl(struct fb_info *info, unsigned int cmd,
+			unsigned long arg)
+{
+	struct imxfb_info *fbi = info->par;
+	int alpha, ret = 0;
+	unsigned int tmp;
+
+	switch (cmd) {
+	case IMXFB_ALPHA:
+		if (get_user(alpha, (int __user *)arg)) {
+			ret = -EFAULT;
+		} else {
+			tmp = readl(fbi->regs + LCDC_LGWCR);
+			tmp &= ~LGWCR_GWAV(0xff);
+			tmp |= LGWCR_GWAV(alpha);
+			if (!alpha)
+				tmp &= ~LGWCR_GWE;
+			else
+				tmp |= LGWCR_GWE;
+			writel(tmp , fbi->regs + LCDC_LGWCR);
+		}
+		break;
+	default:
+		ret = -EINVAL;
+	}
+
+	return ret;
+}
+
 static struct fb_ops imxfb_ops = {
 	.owner		= THIS_MODULE,
 	.fb_check_var	= imxfb_check_var,
@@ -619,6 +653,7 @@ static struct fb_ops imxfb_ops = {
 	.fb_copyarea	= cfb_copyarea,
 	.fb_imageblit	= cfb_imageblit,
 	.fb_blank	= imxfb_blank,
+	.fb_ioctl	= imxfb_ioctl,
 };
 
 /*
diff --git a/include/linux/platform_data/video-imxfb.h b/include/linux/platform_data/video-imxfb.h
index 9de8f06..ce3875f 100644
--- a/include/linux/platform_data/video-imxfb.h
+++ b/include/linux/platform_data/video-imxfb.h
@@ -51,6 +51,9 @@
 #define DMACR_HM(x)	(((x) & 0xf) << 16)
 #define DMACR_TM(x)	((x) & 0xf)
 
+#define IMXFB_IOW(num, dtype)	_IOW('I', num, dtype)
+#define IMXFB_ALPHA		IMXFB_IOW(31, int)
+
 struct imx_fb_videomode {
 	struct fb_videomode mode;
 	u32 pcr;
-- 
1.8.1.5



From mpa at pengutronix.de  Thu Apr 18 09:03:03 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Thu, 18 Apr 2013 15:03:03 +0200
Subject: [PATCH v4 2/2] video: imxfb: Add DT support
In-Reply-To: <1366290183-367-1-git-send-email-mpa@pengutronix.de>
References: <1366290183-367-1-git-send-email-mpa@pengutronix.de>
Message-ID: <1366290183-367-3-git-send-email-mpa@pengutronix.de>

Add devicetree support for imx framebuffer driver. It uses the generic
display bindings and helper functions.

Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
Cc: Fabio Estevam <festevam at gmail.com>
Cc: Mark Rutland <mark.rutland at arm.com>
---

Notes:
    Changes in v4:
    - Remove eukrea specific dmacr property.
    - Add optional dmacr property. If not present, the dmacr reset value is not
      changed.
    
    Changes in v3:
    - Fix returncodes of of_read_mode function and print error messages
    - Introduce a lower bound check for bits per pixel
    - Calculate correct bytes per pixel value before using it for the calculation of
    	memory size
    - Change DT property names
    
    Changes in v2:
    - Removed pwmr register property
    - Cleanup of devicetree binding documentation
    - Use default values for pwmr and lscr1

 .../devicetree/bindings/video/fsl,imx-fb.txt       |  51 ++++++
 drivers/video/imxfb.c                              | 194 +++++++++++++++++----
 2 files changed, 210 insertions(+), 35 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/video/fsl,imx-fb.txt

diff --git a/Documentation/devicetree/bindings/video/fsl,imx-fb.txt b/Documentation/devicetree/bindings/video/fsl,imx-fb.txt
new file mode 100644
index 0000000..aff16a4
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/fsl,imx-fb.txt
@@ -0,0 +1,51 @@
+Freescale imx21 Framebuffer
+
+This framebuffer driver supports devices imx1, imx21, imx25, and imx27.
+
+Required properties:
+- compatible : "fsl,<chip>-fb", chip should be imx1 or imx21
+- reg : Should contain 1 register ranges(address and length)
+- interrupts : One interrupt of the fb dev
+
+Required nodes:
+- display: Phandle to a display node as described in
+	Documentation/devicetree/bindings/video/display-timing.txt
+	Additional, the display node has to define properties:
+	- fsl,bpp: Bits per pixel
+	- fsl,pcr: LCDC PCR value
+
+Optional properties:
+- fsl,dmacr: DMA Control Register value. This is optional. By default, the
+	register is not modified as recommended by the datasheet.
+- fsl,lscr1: LCDC Sharp Configuration Register value.
+
+Example:
+
+	imxfb: fb at 10021000 {
+		compatible = "fsl,imx27-fb", "fsl,imx21-fb";
+		interrupts = <61>;
+		reg = <0x10021000 0x1000>;
+		display = <&display0>;
+	};
+
+	...
+
+	display0: display0 {
+		model = "Primeview-PD050VL1";
+		native-mode = <&timing_disp0>;
+		fsl,bpp = <16>;		/* non-standard but required */
+		fsl,pcr = <0xf0c88080>;	/* non-standard but required */
+		display-timings {
+			timing_disp0: 640x480 {
+				hactive = <640>;
+				vactive = <480>;
+				hback-porch = <112>;
+				hfront-porch = <36>;
+				hsync-len = <32>;
+				vback-porch = <33>;
+				vfront-porch = <33>;
+				vsync-len = <2>;
+				clock-frequency = <25000000>;
+			};
+		};
+	};
diff --git a/drivers/video/imxfb.c b/drivers/video/imxfb.c
index ef2b587..e0230f8 100644
--- a/drivers/video/imxfb.c
+++ b/drivers/video/imxfb.c
@@ -32,6 +32,12 @@
 #include <linux/io.h>
 #include <linux/math64.h>
 #include <linux/uaccess.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+
+#include <video/of_display_timing.h>
+#include <video/of_videomode.h>
+#include <video/videomode.h>
 
 #include <linux/platform_data/video-imxfb.h>
 
@@ -117,10 +123,11 @@
 #define LGWCR_GWAV(alpha)	(((alpha) & 0xff) << 24)
 #define LGWCR_GWE	(1 << 22)
 
+#define IMXFB_LSCR1_DEFAULT 0x00120300
+
 /* Used fb-mode. Can be set on kernel command line, therefore file-static. */
 static const char *fb_mode;
 
-
 /*
  * These are the bitfields for each
  * display depth that we support.
@@ -192,6 +199,19 @@ static struct platform_device_id imxfb_devtype[] = {
 };
 MODULE_DEVICE_TABLE(platform, imxfb_devtype);
 
+static struct of_device_id imxfb_of_dev_id[] = {
+	{
+		.compatible = "fsl,imx1-fb",
+		.data = &imxfb_devtype[IMX1_FB],
+	}, {
+		.compatible = "fsl,imx21-fb",
+		.data = &imxfb_devtype[IMX21_FB],
+	}, {
+		/* sentinel */
+	}
+};
+MODULE_DEVICE_TABLE(of, imxfb_of_dev_id);
+
 static inline int is_imx1_fb(struct imxfb_info *fbi)
 {
 	return fbi->devtype == IMX1_FB;
@@ -324,6 +344,9 @@ static const struct imx_fb_videomode *imxfb_find_mode(struct imxfb_info *fbi)
 	struct imx_fb_videomode *m;
 	int i;
 
+	if (!fb_mode)
+		return &fbi->mode[0];
+
 	for (i = 0, m = &fbi->mode[0]; i < fbi->num_modes; i++, m++) {
 		if (!strcmp(m->mode.name, fb_mode))
 			return m;
@@ -479,6 +502,9 @@ static int imxfb_bl_update_status(struct backlight_device *bl)
 	struct imxfb_info *fbi = bl_get_data(bl);
 	int brightness = bl->props.brightness;
 
+	if (!fbi->pwmr)
+		return 0;
+
 	if (bl->props.power != FB_BLANK_UNBLANK)
 		brightness = 0;
 	if (bl->props.fb_blank != FB_BLANK_UNBLANK)
@@ -719,10 +745,14 @@ static int imxfb_activate_var(struct fb_var_screeninfo *var, struct fb_info *inf
 
 	writel(fbi->pcr, fbi->regs + LCDC_PCR);
 #ifndef PWMR_BACKLIGHT_AVAILABLE
-	writel(fbi->pwmr, fbi->regs + LCDC_PWMR);
+	if (fbi->pwmr)
+		writel(fbi->pwmr, fbi->regs + LCDC_PWMR);
 #endif
 	writel(fbi->lscr1, fbi->regs + LCDC_LSCR1);
-	writel(fbi->dmacr, fbi->regs + LCDC_DMACR);
+
+	/* dmacr = 0 is no valid value, as we need DMA control marks. */
+	if (fbi->dmacr)
+		writel(fbi->dmacr, fbi->regs + LCDC_DMACR);
 
 	return 0;
 }
@@ -758,13 +788,12 @@ static int imxfb_resume(struct platform_device *dev)
 #define imxfb_resume	NULL
 #endif
 
-static int __init imxfb_init_fbinfo(struct platform_device *pdev)
+static int imxfb_init_fbinfo(struct platform_device *pdev)
 {
 	struct imx_fb_platform_data *pdata = pdev->dev.platform_data;
 	struct fb_info *info = dev_get_drvdata(&pdev->dev);
 	struct imxfb_info *fbi = info->par;
-	struct imx_fb_videomode *m;
-	int i;
+	struct device_node *np;
 
 	pr_debug("%s\n",__func__);
 
@@ -795,41 +824,95 @@ static int __init imxfb_init_fbinfo(struct platform_device *pdev)
 	info->fbops			= &imxfb_ops;
 	info->flags			= FBINFO_FLAG_DEFAULT |
 					  FBINFO_READS_FAST;
-	info->var.grayscale		= pdata->cmap_greyscale;
-	fbi->cmap_inverse		= pdata->cmap_inverse;
-	fbi->cmap_static		= pdata->cmap_static;
-	fbi->lscr1			= pdata->lscr1;
-	fbi->dmacr			= pdata->dmacr;
-	fbi->pwmr			= pdata->pwmr;
-	fbi->lcd_power			= pdata->lcd_power;
-	fbi->backlight_power		= pdata->backlight_power;
-
-	for (i = 0, m = &pdata->mode[0]; i < pdata->num_modes; i++, m++)
-		info->fix.smem_len = max_t(size_t, info->fix.smem_len,
-				m->mode.xres * m->mode.yres * m->bpp / 8);
+	if (pdata) {
+		info->var.grayscale		= pdata->cmap_greyscale;
+		fbi->cmap_inverse		= pdata->cmap_inverse;
+		fbi->cmap_static		= pdata->cmap_static;
+		fbi->lscr1			= pdata->lscr1;
+		fbi->dmacr			= pdata->dmacr;
+		fbi->pwmr			= pdata->pwmr;
+		fbi->lcd_power			= pdata->lcd_power;
+		fbi->backlight_power		= pdata->backlight_power;
+	} else {
+		np = pdev->dev.of_node;
+		info->var.grayscale = of_property_read_bool(np,
+						"cmap-greyscale");
+		fbi->cmap_inverse = of_property_read_bool(np, "cmap-inverse");
+		fbi->cmap_static = of_property_read_bool(np, "cmap-static");
+
+		fbi->lscr1 = IMXFB_LSCR1_DEFAULT;
+		of_property_read_u32(np, "fsl,lscr1", &fbi->lscr1);
+
+		of_property_read_u32(np, "fsl,dmacr", &fbi->dmacr);
+
+		/* These two function pointers could be used by some specific
+		 * platforms. */
+		fbi->lcd_power = NULL;
+		fbi->backlight_power = NULL;
+	}
+
+	return 0;
+}
+
+static int imxfb_of_read_mode(struct device *dev, struct device_node *np,
+		struct imx_fb_videomode *imxfb_mode)
+{
+	int ret;
+	struct fb_videomode *of_mode = &imxfb_mode->mode;
+	u32 bpp;
+	u32 pcr;
+
+	ret = of_property_read_string(np, "model", &of_mode->name);
+	if (ret)
+		of_mode->name = NULL;
+
+	ret = of_get_fb_videomode(np, of_mode, OF_USE_NATIVE_MODE);
+	if (ret) {
+		dev_err(dev, "Failed to get videomode from DT\n");
+		return ret;
+	}
+
+	ret = of_property_read_u32(np, "fsl,bpp", &bpp);
+	ret |= of_property_read_u32(np, "fsl,pcr", &pcr);
+
+	if (ret) {
+		dev_err(dev, "Failed to read bpp and pcr from DT\n");
+		return -EINVAL;
+	}
+
+	if (bpp < 1 || bpp > 255) {
+		dev_err(dev, "Bits per pixel have to be between 1 and 255\n");
+		return -EINVAL;
+	}
+
+	imxfb_mode->bpp = bpp;
+	imxfb_mode->pcr = pcr;
 
 	return 0;
 }
 
-static int __init imxfb_probe(struct platform_device *pdev)
+static int imxfb_probe(struct platform_device *pdev)
 {
 	struct imxfb_info *fbi;
 	struct fb_info *info;
 	struct imx_fb_platform_data *pdata;
 	struct resource *res;
+	struct imx_fb_videomode *m;
+	const struct of_device_id *of_id;
 	int ret, i;
+	int bytes_per_pixel;
 
 	dev_info(&pdev->dev, "i.MX Framebuffer driver\n");
 
+	of_id = of_match_device(imxfb_of_dev_id, &pdev->dev);
+	if (of_id)
+		pdev->id_entry = of_id->data;
+
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 	if (!res)
 		return -ENODEV;
 
 	pdata = pdev->dev.platform_data;
-	if (!pdata) {
-		dev_err(&pdev->dev,"No platform_data available\n");
-		return -ENOMEM;
-	}
 
 	info = framebuffer_alloc(sizeof(struct imxfb_info), &pdev->dev);
 	if (!info)
@@ -837,15 +920,55 @@ static int __init imxfb_probe(struct platform_device *pdev)
 
 	fbi = info->par;
 
-	if (!fb_mode)
-		fb_mode = pdata->mode[0].mode.name;
-
 	platform_set_drvdata(pdev, info);
 
 	ret = imxfb_init_fbinfo(pdev);
 	if (ret < 0)
 		goto failed_init;
 
+	if (pdata) {
+		if (!fb_mode)
+			fb_mode = pdata->mode[0].mode.name;
+
+		fbi->mode = pdata->mode;
+		fbi->num_modes = pdata->num_modes;
+	} else {
+		struct device_node *display_np;
+		fb_mode = NULL;
+
+		display_np = of_parse_phandle(pdev->dev.of_node, "display", 0);
+		if (!display_np) {
+			dev_err(&pdev->dev, "No display defined in devicetree\n");
+			ret = -EINVAL;
+			goto failed_of_parse;
+		}
+
+		/*
+		 * imxfb does not support more modes, we choose only the native
+		 * mode.
+		 */
+		fbi->num_modes = 1;
+
+		fbi->mode = devm_kzalloc(&pdev->dev,
+				sizeof(struct imx_fb_videomode), GFP_KERNEL);
+		if (!fbi->mode) {
+			ret = -ENOMEM;
+			goto failed_of_parse;
+		}
+
+		ret = imxfb_of_read_mode(&pdev->dev, display_np, fbi->mode);
+		if (ret)
+			goto failed_of_parse;
+	}
+
+	/* Calculate maximum bytes used per pixel. In most cases this should
+	 * be the same as m->bpp/8 */
+	m = &fbi->mode[0];
+	bytes_per_pixel = (m->bpp + 7) / 8;
+	for (i = 0; i < fbi->num_modes; i++, m++)
+		info->fix.smem_len = max_t(size_t, info->fix.smem_len,
+				m->mode.xres * m->mode.yres * bytes_per_pixel);
+
 	res = request_mem_region(res->start, resource_size(res),
 				DRIVER_NAME);
 	if (!res) {
@@ -878,7 +1001,8 @@ static int __init imxfb_probe(struct platform_device *pdev)
 		goto failed_ioremap;
 	}
 
-	if (!pdata->fixed_screen_cpu) {
+	/* Seems not being used by anyone, so no support for oftree */
+	if (!pdata || !pdata->fixed_screen_cpu) {
 		fbi->map_size = PAGE_ALIGN(info->fix.smem_len);
 		fbi->map_cpu = dma_alloc_writecombine(&pdev->dev,
 				fbi->map_size, &fbi->map_dma, GFP_KERNEL);
@@ -903,18 +1027,16 @@ static int __init imxfb_probe(struct platform_device *pdev)
 		info->fix.smem_start = fbi->screen_dma;
 	}
 
-	if (pdata->init) {
+	if (pdata && pdata->init) {
 		ret = pdata->init(fbi->pdev);
 		if (ret)
 			goto failed_platform_init;
 	}
 
-	fbi->mode = pdata->mode;
-	fbi->num_modes = pdata->num_modes;
 
 	INIT_LIST_HEAD(&info->modelist);
-	for (i = 0; i < pdata->num_modes; i++)
-		fb_add_videomode(&pdata->mode[i].mode, &info->modelist);
+	for (i = 0; i < fbi->num_modes; i++)
+		fb_add_videomode(&fbi->mode[i].mode, &info->modelist);
 
 	/*
 	 * This makes sure that our colour bitfield
@@ -944,10 +1066,10 @@ static int __init imxfb_probe(struct platform_device *pdev)
 failed_register:
 	fb_dealloc_cmap(&info->cmap);
 failed_cmap:
-	if (pdata->exit)
+	if (pdata && pdata->exit)
 		pdata->exit(fbi->pdev);
 failed_platform_init:
-	if (!pdata->fixed_screen_cpu)
+	if (pdata && !pdata->fixed_screen_cpu)
 		dma_free_writecombine(&pdev->dev,fbi->map_size,fbi->map_cpu,
 			fbi->map_dma);
 failed_map:
@@ -956,6 +1078,7 @@ failed_ioremap:
 failed_getclock:
 	release_mem_region(res->start, resource_size(res));
 failed_req:
+failed_of_parse:
 	kfree(info->pseudo_palette);
 failed_init:
 	platform_set_drvdata(pdev, NULL);
@@ -980,7 +1103,7 @@ static int imxfb_remove(struct platform_device *pdev)
 	unregister_framebuffer(info);
 
 	pdata = pdev->dev.platform_data;
-	if (pdata->exit)
+	if (pdata && pdata->exit)
 		pdata->exit(fbi->pdev);
 
 	fb_dealloc_cmap(&info->cmap);
@@ -1009,6 +1132,7 @@ static struct platform_driver imxfb_driver = {
 	.shutdown	= imxfb_shutdown,
 	.driver		= {
 		.name	= DRIVER_NAME,
+		.of_match_table = imxfb_of_dev_id,
 	},
 	.id_table	= imxfb_devtype,
 };
-- 
1.8.1.5



From mpa at pengutronix.de  Thu Apr 18 09:03:01 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Thu, 18 Apr 2013 15:03:01 +0200
Subject: [PATCH v4 0/2] video: imxfb DT support
Message-ID: <1366290183-367-1-git-send-email-mpa@pengutronix.de>

Hi,

This series adds DT support for imxfb. Changes are listed in the notes section
of each patch.

Regards,

Markus


Christian Hemp (1):
      imxfb: Set alpha value of the framebuffer

Markus Pargmann (1):
      video: imxfb: Add DT support

 Documentation/devicetree/bindings/video/fsl,imx-fb.txt |  51 ++++++++++++++++++
 drivers/video/imxfb.c                                  | 229 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-------------
 include/linux/platform_data/video-imxfb.h              |   3 ++
 3 files changed, 248 insertions(+), 35 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/video/fsl,imx-fb.txt



From jason at lakedaemon.net  Thu Apr 18 09:06:55 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Thu, 18 Apr 2013 09:06:55 -0400
Subject: [PATCH v7 1/3] of/pci: Unify pci_process_bridge_OF_ranges from
 Microblaze and PowerPC
In-Reply-To: <20130418124832.D2C733E118C@localhost>
References: <1366107508-12672-1-git-send-email-Andrew.Murray@arm.com>
 <1366107508-12672-2-git-send-email-Andrew.Murray@arm.com>
 <20130416103005.GB12726@arm.com>
 <20130417160015.777453E2B73@localhost>
 <20130417161036.GB27197@titan.lakedaemon.net>
 <CACxGe6sNk=wNinTcMHbJa5o-56Tyh=0CnFSEW+Hk-ujpjeg2gQ@mail.gmail.com>
 <20130417162223.GC27197@titan.lakedaemon.net>
 <20130418124832.D2C733E118C@localhost>
Message-ID: <20130418130655.GH27197@titan.lakedaemon.net>

On Thu, Apr 18, 2013 at 01:48:32PM +0100, Grant Likely wrote:
> On Wed, 17 Apr 2013 12:22:23 -0400, Jason Cooper <jason at lakedaemon.net> wrote:
> > On Wed, Apr 17, 2013 at 05:17:48PM +0100, Grant Likely wrote:
> > > On Wed, Apr 17, 2013 at 5:10 PM, Jason Cooper <jason at lakedaemon.net> wrote:
> > > > On Wed, Apr 17, 2013 at 05:00:15PM +0100, Grant Likely wrote:
> > > >> On Tue, 16 Apr 2013 11:30:06 +0100, Andrew Murray <andrew.murray at arm.com> wrote:
> > > >> > On Tue, Apr 16, 2013 at 11:18:26AM +0100, Andrew Murray wrote:
> > > >> > > The pci_process_bridge_OF_ranges function, used to parse the "ranges"
> > > >> > > property of a PCI host device, is found in both Microblaze and PowerPC
> > > >> > > architectures. These implementations are nearly identical. This patch
> > > >> > > moves this common code to a common place.
> > > >> > >
> > > >> > > Signed-off-by: Andrew Murray <Andrew.Murray at arm.com>
> > > >> > > Signed-off-by: Liviu Dudau <Liviu.Dudau at arm.com>
> > > >> > > Reviewed-by: Rob Herring <rob.herring at calxeda.com>
> > > >> > > Tested-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> > > >> > > Tested-by: Linus Walleij <linus.walleij at linaro.org>
> > > >> > > Acked-by: Michal Simek <monstr at monstr.eu>
> > > >> > > ---
> > > >> > >  arch/microblaze/include/asm/pci-bridge.h |    5 +-
> > > >> > >  arch/microblaze/pci/pci-common.c         |  192 ----------------------------
> > > >> > >  arch/powerpc/include/asm/pci-bridge.h    |    5 +-
> > > >> > >  arch/powerpc/kernel/pci-common.c         |  192 ----------------------------
> > > >> >
> > > >> > Is there anyone on linuxppc-dev/linux-mips that can help test this patchset?
> > > >> >
> > > >> > I've tested that it builds on powerpc with a variety of configs (some which
> > > >> > include fsl_pci.c implementation). Though I don't have hardware to verify that
> > > >> > it works.
> > > >> >
> > > >> > I haven't tested this builds or runs on MIPS.
> > > >> >
> > > >> > You shouldn't see any difference in behaviour or new warnings and PCI devices
> > > >> > should continue to operate as before.
> > > >>
> > > >> I've got through a line-by-line comparison between powerpc, microblaze,
> > > >> and then new code. The differences are purely cosmetic, so I have
> > > >> absolutely no concerns about this patch. I've applied it to my tree.
> > > >
> > > > oops.  Due to the number of dependencies the mvebu-pcie series has (this
> > > > being one of them, we (arm-soc/mvebu) asked if we could take this
> > > > through our tree.  Rob Herring agreed to this several days ago.  Is this
> > > > a problem for you?
> > > >
> > > > It would truly (dogs and cats living together) upset the apple cart for
> > > > us at this stage to pipe these through a different tree...
> > > 
> > > Not a problem at all. I'll drop it.
> > 
> > Great!  Thanks.
> 
> You can add my Acked-by: Grant Likely <grant.likely at linaro.org> to the
> first patch. I've not reviewed out the second or third patches yet.
> 
> None of this appears to be in linux-next yet. I've boot tested on
> PowerPC, but that isn't the same as an ack by the PowerPC maintainers.
> It is probably too late for the whole now since we're after -rc7.
> However, if you ask me to, I have absolutely no problem putting the
> first patch into my tree for v3.10 merging. I went over the patch
> line-by-line and am convinced that it is functionally identical.
> 
> Let me know if you need me to do this.

Thanks for the offer, Olof just pulled the branch last night (my PRs
were a little late trying to sort all this out), so it should be in
shortly.

FYI:

  65ee348 of/pci: Unify pci_process_bridge_OF_ranges from Microblaze and PowerPC

is in arm-soc/mvebu/drivers as well as arm-soc/next/drivers (and
arm-soc/for-next if you want to test merging everything...)

thx,

Jason.


From jason at lakedaemon.net  Thu Apr 18 09:09:19 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Thu, 18 Apr 2013 09:09:19 -0400
Subject: [PATCH v7 3/3] of/pci: mips: convert to common of_pci_range_parser
In-Reply-To: <20130418125910.GA17128@arm.com>
References: <1366107508-12672-1-git-send-email-Andrew.Murray@arm.com>
 <1366107508-12672-4-git-send-email-Andrew.Murray@arm.com>
 <CACRpkdbBaT1OKr5t8HW4+8y_wSDmGxmewAyVMekx8S-K9s3K8Q@mail.gmail.com>
 <20130418125910.GA17128@arm.com>
Message-ID: <20130418130919.GI27197@titan.lakedaemon.net>

On Thu, Apr 18, 2013 at 01:59:10PM +0100, Andrew Murray wrote:
> On Wed, Apr 17, 2013 at 04:42:48PM +0100, Linus Walleij wrote:
> > On Tue, Apr 16, 2013 at 12:18 PM, Andrew Murray <Andrew.Murray at arm.com> wrote:
> > 
> > > This patch converts the pci_load_of_ranges function to use the new common
> > > of_pci_range_parser.
> > >
> > > Signed-off-by: Andrew Murray <Andrew.Murray at arm.com>
> > > Signed-off-by: Liviu Dudau <Liviu.Dudau at arm.com>
> > > Reviewed-by: Rob Herring <rob.herring at calxeda.com>
> > 
> > Tested-by: Linus Walleij <linus.walleij at linaro.org>
> 
> Jason - you may not have seen this, but here (Linus Walleij) is another Tested-by
> to add to this patch in your tree (if you can).

Thanks, I saw it.  Unfortunately, the PR was already sent, and the branch
is now pulled into arm-soc.

thx,

Jason.


From cb at sgoc.de  Thu Apr 18 09:13:55 2013
From: cb at sgoc.de (Christoph)
Date: Thu, 18 Apr 2013 15:13:55 +0200 (CEST)
Subject: Problem porting driver for OTP cells on Freescale i.MX28
Message-ID: <2001207140.384354.1366290836027.open-xchange@email.1und1.de>

Hello list,

currently I'm porting some drivers from the Freescale SDK based on 2.6.35 for
the i.MX28 to 3.7+ .
Working on the OTP eFuses I ran into a problem concerning clock sources. The OTP
driver requires to change the clock frequency of some logic blocks when writing
to OTP cells. In the original code from Freescale it requested "hclk" via
clk_get(). As this seems to be named "hbus" in the vanilla kernels I changed
this, but still clk_get() fails.
My patch can be found at http://www.sgoc.de/Downloads/fsl-otp.patch (NOTE: It
contains some printk for debugging and as stated above writing does not work).
Are there any hints on the clock API?



Regards,
Christoph Baumann


From cb at sgoc.de  Thu Apr 18 09:17:09 2013
From: cb at sgoc.de (Christoph)
Date: Thu, 18 Apr 2013 15:17:09 +0200 (CEST)
Subject: =?UTF-8?Q?Patch_for_Crypto-Cop=E2=80=8Brocesor?=
 =?UTF-8?Q?_(DCP)_on_Freescale=E2=80=8B_i.MX28=E2=80=8B?=
Message-ID: <1368909273.384531.1366291029932.open-xchange@email.1und1.de>

Hello,

maybe some know that Freescale released a SDK for the i.MX28 SoC based on Linux
2.6.35.3 with a plethora of patches.
Most features made it to more recent kernels. So I switched development to the
then recent 3.7.
One thing I missed in 3.7 was support for the Crypto-Coprocessor (DCP). So I
ported the driver from Freescale to 3.7. The patch here
http://www.sgoc.de/Downloads/fsl-dcp.patch should also be applicable on recent
versions like 3.9.

I hope this is the right place to share this.



Regards,
Christoph Bauman


From mpa at pengutronix.de  Thu Apr 18 09:21:38 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Thu, 18 Apr 2013 15:21:38 +0200
Subject: [PATCH RESEND v5 2/2] DMA: imx-dma: imxdma->dev used uninitialized
In-Reply-To: <1366291298-30004-1-git-send-email-mpa@pengutronix.de>
References: <1366291298-30004-1-git-send-email-mpa@pengutronix.de>
Message-ID: <1366291298-30004-3-git-send-email-mpa@pengutronix.de>

imxdma->dev is used for dev_warn before it was set.

Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
---
 drivers/dma/imx-dma.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dma/imx-dma.c b/drivers/dma/imx-dma.c
index 8849d03..0d42d0a 100644
--- a/drivers/dma/imx-dma.c
+++ b/drivers/dma/imx-dma.c
@@ -1067,6 +1067,7 @@ static int __init imxdma_probe(struct platform_device *pdev)
 	if (!imxdma)
 		return -ENOMEM;
 
+	imxdma->dev = &pdev->dev;
 	imxdma->devtype = pdev->id_entry->driver_data;
 
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -1171,7 +1172,6 @@ static int __init imxdma_probe(struct platform_device *pdev)
 			      &imxdma->dma_device.channels);
 	}
 
-	imxdma->dev = &pdev->dev;
 	imxdma->dma_device.dev = &pdev->dev;
 
 	imxdma->dma_device.device_alloc_chan_resources = imxdma_alloc_chan_resources;
-- 
1.8.1.5



From mpa at pengutronix.de  Thu Apr 18 09:21:37 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Thu, 18 Apr 2013 15:21:37 +0200
Subject: [PATCH RESEND v5 1/2] dma: imx-dma: Add oftree support
In-Reply-To: <1366291298-30004-1-git-send-email-mpa@pengutronix.de>
References: <1366291298-30004-1-git-send-email-mpa@pengutronix.de>
Message-ID: <1366291298-30004-2-git-send-email-mpa@pengutronix.de>

Adding devicetree support for imx-dma driver. Use driver name for
function 'imx_dma_is_general_purpose' because the devicename for
devicetree initialized devices is different.

Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
Reviewed-by: Arnd Bergmann <arnd at arndb.de>
---

Notes:
    Changes in V5:
    - Style fix
    - Documentation reference
    
    Changes in V4:
    - Directly use "imxdma_channel" as proposed by Arnd. This removes the
    allocation of imx_dma_data.
    - Simplify function imx_dma_is_general_purpose using driver names.
    
    Changes in V3:
    - Create a imxdma translate function to pass the device object into the
    filter function.
    
    Changes in V2:
    - Change the driver to use generic DMA DT bindings.
    - Add a imx-dma filter function that sets the dma request line in
      private data.

 .../devicetree/bindings/dma/fsl-imx-dma.txt        | 48 ++++++++++++++
 drivers/dma/imx-dma.c                              | 74 ++++++++++++++++++++++
 include/linux/platform_data/dma-imx.h              |  6 +-
 3 files changed, 124 insertions(+), 4 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/dma/fsl-imx-dma.txt

diff --git a/Documentation/devicetree/bindings/dma/fsl-imx-dma.txt b/Documentation/devicetree/bindings/dma/fsl-imx-dma.txt
new file mode 100644
index 0000000..2717ecb
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/fsl-imx-dma.txt
@@ -0,0 +1,48 @@
+* Freescale Direct Memory Access (DMA) Controller for i.MX
+
+This document will only describe differences to the generic DMA Controller and
+DMA request bindings as described in dma/dma.txt .
+
+* DMA controller
+
+Required properties:
+- compatible : Should be "fsl,<chip>-dma". chip can be imx1, imx21 or imx27
+- reg : Should contain DMA registers location and length
+- interrupts : First item should be DMA interrupt, second one is optional and
+    should contain DMA Error interrupt
+- #dma-cells : Has to be 1. imx-dma does not support anything else.
+
+Optional properties:
+- #dma-channels : Number of DMA channels supported. Should be 16.
+- #dma-requests : Number of DMA requests supported.
+
+Example:
+
+	dma: dma at 10001000 {
+		compatible = "fsl,imx27-dma";
+		reg = <0x10001000 0x1000>;
+		interrupts = <32 33>;
+		#dma-cells = <1>;
+		#dma-channels = <16>;
+	};
+
+
+* DMA client
+
+Clients have to specify the DMA requests with phandles in a list.
+
+Required properties:
+- dmas: List of one or more DMA request specifiers. One DMA request specifier
+    consists of a phandle to the DMA controller followed by the integer
+    specifiying the request line.
+- dma-names: List of string identifiers for the DMA requests. For the correct
+    names, have a look at the specific client driver.
+
+Example:
+
+	sdhci1: sdhci at 10013000 {
+		...
+		dmas = <&dma 7>;
+		dma-names = "rx-tx";
+		...
+	};
diff --git a/drivers/dma/imx-dma.c b/drivers/dma/imx-dma.c
index 70b8975..8849d03 100644
--- a/drivers/dma/imx-dma.c
+++ b/drivers/dma/imx-dma.c
@@ -27,6 +27,8 @@
 #include <linux/clk.h>
 #include <linux/dmaengine.h>
 #include <linux/module.h>
+#include <linux/of_device.h>
+#include <linux/of_dma.h>
 
 #include <asm/irq.h>
 #include <linux/platform_data/dma-imx.h>
@@ -186,6 +188,11 @@ struct imxdma_engine {
 	enum imx_dma_type		devtype;
 };
 
+struct imxdma_filter_data {
+	struct imxdma_engine	*imxdma;
+	int			 request;
+};
+
 static struct platform_device_id imx_dma_devtype[] = {
 	{
 		.name = "imx1-dma",
@@ -202,6 +209,22 @@ static struct platform_device_id imx_dma_devtype[] = {
 };
 MODULE_DEVICE_TABLE(platform, imx_dma_devtype);
 
+static const struct of_device_id imx_dma_of_dev_id[] = {
+	{
+		.compatible = "fsl,imx1-dma",
+		.data = &imx_dma_devtype[IMX1_DMA],
+	}, {
+		.compatible = "fsl,imx21-dma",
+		.data = &imx_dma_devtype[IMX21_DMA],
+	}, {
+		.compatible = "fsl,imx27-dma",
+		.data = &imx_dma_devtype[IMX27_DMA],
+	}, {
+		/* sentinel */
+	}
+};
+MODULE_DEVICE_TABLE(of, imx_dma_of_dev_id);
+
 static inline int is_imx1_dma(struct imxdma_engine *imxdma)
 {
 	return imxdma->devtype == IMX1_DMA;
@@ -997,13 +1020,49 @@ static void imxdma_issue_pending(struct dma_chan *chan)
 	spin_unlock_irqrestore(&imxdma->lock, flags);
 }
 
+static bool imxdma_filter_fn(struct dma_chan *chan, void *param)
+{
+	struct imxdma_filter_data *fdata = param;
+	struct imxdma_channel *imxdma_chan = to_imxdma_chan(chan);
+
+	if (chan->device->dev != fdata->imxdma->dev)
+		return false;
+
+	imxdma_chan->dma_request = fdata->request;
+	chan->private = NULL;
+
+	return true;
+}
+
+static struct dma_chan *imxdma_xlate(struct of_phandle_args *dma_spec,
+						struct of_dma *ofdma)
+{
+	int count = dma_spec->args_count;
+	struct imxdma_engine *imxdma = ofdma->of_dma_data;
+	struct imxdma_filter_data fdata = {
+		.imxdma = imxdma,
+		.request = *(unsigned *)&dma_spec->args[0],
+	};
+
+	if (count != 1)
+		return NULL;
+
+	return dma_request_channel(imxdma->dma_device.cap_mask,
+					imxdma_filter_fn, &fdata);
+}
+
 static int __init imxdma_probe(struct platform_device *pdev)
 	{
 	struct imxdma_engine *imxdma;
 	struct resource *res;
+	const struct of_device_id *of_id;
 	int ret, i;
 	int irq, irq_err;
 
+	of_id = of_match_device(imx_dma_of_dev_id, &pdev->dev);
+	if (of_id)
+		pdev->id_entry = of_id->data;
+
 	imxdma = devm_kzalloc(&pdev->dev, sizeof(*imxdma), GFP_KERNEL);
 	if (!imxdma)
 		return -ENOMEM;
@@ -1137,8 +1196,19 @@ static int __init imxdma_probe(struct platform_device *pdev)
 		goto err;
 	}
 
+	if (pdev->dev.of_node) {
+		ret = of_dma_controller_register(pdev->dev.of_node,
+				imxdma_xlate, imxdma);
+		if (ret) {
+			dev_err(&pdev->dev, "unable to register of_dma_controller\n");
+			goto err_of_dma_controller;
+		}
+	}
+
 	return 0;
 
+err_of_dma_controller:
+	dma_async_device_unregister(&imxdma->dma_device);
 err:
 	clk_disable_unprepare(imxdma->dma_ipg);
 	clk_disable_unprepare(imxdma->dma_ahb);
@@ -1151,6 +1221,9 @@ static int __exit imxdma_remove(struct platform_device *pdev)
 
         dma_async_device_unregister(&imxdma->dma_device);
 
+	if (pdev->dev.of_node)
+		of_dma_controller_free(pdev->dev.of_node);
+
 	clk_disable_unprepare(imxdma->dma_ipg);
 	clk_disable_unprepare(imxdma->dma_ahb);
 
@@ -1160,6 +1233,7 @@ static int __exit imxdma_remove(struct platform_device *pdev)
 static struct platform_driver imxdma_driver = {
 	.driver		= {
 		.name	= "imx-dma",
+		.of_match_table = imx_dma_of_dev_id,
 	},
 	.id_table	= imx_dma_devtype,
 	.remove		= __exit_p(imxdma_remove),
diff --git a/include/linux/platform_data/dma-imx.h b/include/linux/platform_data/dma-imx.h
index f6d30cc..beac6b8 100644
--- a/include/linux/platform_data/dma-imx.h
+++ b/include/linux/platform_data/dma-imx.h
@@ -60,10 +60,8 @@ static inline int imx_dma_is_ipu(struct dma_chan *chan)
 
 static inline int imx_dma_is_general_purpose(struct dma_chan *chan)
 {
-	return strstr(dev_name(chan->device->dev), "sdma") ||
-		!strcmp(dev_name(chan->device->dev), "imx1-dma") ||
-		!strcmp(dev_name(chan->device->dev), "imx21-dma") ||
-		!strcmp(dev_name(chan->device->dev), "imx27-dma");
+	return !strcmp(chan->device->dev->driver->name, "imx-sdma") ||
+		!strcmp(chan->device->dev->driver->name, "imx-dma");
 }
 
 #endif
-- 
1.8.1.5



From mpa at pengutronix.de  Thu Apr 18 09:21:36 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Thu, 18 Apr 2013 15:21:36 +0200
Subject: [PATCH RESEND v5 0/2] dma: imx-dma: OFTree support
Message-ID: <1366291298-30004-1-git-send-email-mpa@pengutronix.de>

Hi,

this series adds support for the generic DMA DT bindings.

Regards,

Markus


Markus Pargmann (2):
      dma: imx-dma: Add oftree support
      DMA: imx-dma: imxdma->dev used uninitialized

 Documentation/devicetree/bindings/dma/fsl-imx-dma.txt | 48 ++++++++++++++++++++++++++++++++++++++++++++++++
 drivers/dma/imx-dma.c                                 | 76 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
 include/linux/platform_data/dma-imx.h                 |  6 ++----
 3 files changed, 125 insertions(+), 5 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/dma/fsl-imx-dma.txt



From horms at verge.net.au  Thu Apr 18 09:27:24 2013
From: horms at verge.net.au (Simon Horman)
Date: Thu, 18 Apr 2013 22:27:24 +0900
Subject: [PATCH 2/2] ARM: shmobile: BOCK-W: enable I2C in defconfig
In-Reply-To: <201304172247.28311.sergei.shtylyov@cogentembedded.com>
References: <201304172242.27671.sergei.shtylyov@cogentembedded.com>
 <201304172247.28311.sergei.shtylyov@cogentembedded.com>
Message-ID: <20130418132724.GC20929@verge.net.au>

On Wed, Apr 17, 2013 at 10:47:27PM +0400, Sergei Shtylyov wrote:
> From: Vladimir Barinov <vladimir.barinov at cogentembedded.com>
> 
> Enable I2C driver in 'bockw_defconfig'.
> 
> Signed-off-by: Vladimir Barinov <vladimir.barinov at cogentembedded.com>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
> 
> ---
>  arch/arm/configs/bockw_defconfig |    2 ++
>  1 file changed, 2 insertions(+)
> 
> Index: renesas/arch/arm/configs/bockw_defconfig
> ===================================================================
> --- renesas.orig/arch/arm/configs/bockw_defconfig
> +++ renesas/arch/arm/configs/bockw_defconfig
> @@ -73,6 +73,8 @@ CONFIG_SERIAL_SH_SCI_NR_UARTS=6
>  CONFIG_SERIAL_SH_SCI_CONSOLE=y
>  # CONFIG_HW_RANDOM is not set
>  # CONFIG_HWMON is not set
> +CONFIG_I2C=y
> +CONFIG_I2C_RCAR=y
>  CONFIG_USB=y
>  CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
>  CONFIG_USB_EHCI_HCD=y

I have applied the following after resolving conflicts
(I don't see CONFIG_USB=y in my tree). Please let me
know if I made an error.

I have queued-up the change for v3.11 in the defconfig-bockw branch
and will push is shortly.


commit 6a3fbcf1ced08f9f423944fefcbc372ec72fa4e7
Author: Vladimir Barinov <vladimir.barinov at cogentembedded.com>
Date:   Wed Apr 17 22:47:27 2013 +0400

    ARM: shmobile: BOCK-W: enable I2C in defconfig
    
    Enable I2C driver in 'bockw_defconfig'.
    
    Signed-off-by: Vladimir Barinov <vladimir.barinov at cogentembedded.com>
    Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
    Acked-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
    [ horms+renesas at verge.net.au: resolved trivial conflicts ]
    Signed-off-by: Simon Horman <horms+renesas at verge.net.au>

diff --git a/arch/arm/configs/bockw_defconfig b/arch/arm/configs/bockw_defconfig
index b74a4d4..2c3f34e 100644
--- a/arch/arm/configs/bockw_defconfig
+++ b/arch/arm/configs/bockw_defconfig
@@ -71,6 +71,8 @@ CONFIG_SERIAL_SH_SCI_NR_UARTS=6
 CONFIG_SERIAL_SH_SCI_CONSOLE=y
 # CONFIG_HW_RANDOM is not set
 # CONFIG_HWMON is not set
+CONFIG_I2C=y
+CONFIG_I2C_RCAR=y
 # CONFIG_USB_SUPPORT is not set
 CONFIG_MMC=y
 CONFIG_MMC_SDHI=y


From horms at verge.net.au  Thu Apr 18 09:30:22 2013
From: horms at verge.net.au (Simon Horman)
Date: Thu, 18 Apr 2013 22:30:22 +0900
Subject: [PATCH 4/4] ARM: shmobile: Marzen: enable VIN and ADV7180 in
 defconfig
In-Reply-To: <201304180217.28176.sergei.shtylyov@cogentembedded.com>
References: <201304180206.39465.sergei.shtylyov@cogentembedded.com>
 <201304180217.28176.sergei.shtylyov@cogentembedded.com>
Message-ID: <20130418133022.GD20929@verge.net.au>

On Thu, Apr 18, 2013 at 02:17:27AM +0400, Sergei Shtylyov wrote:
> From: Vladimir Barinov <vladimir.barinov at cogentembedded.com>
> 
> Add the VIN and ADV7180 drivers to 'marzen_defconfig'.
> 
> Signed-off-by: Vladimir Barinov <vladimir.barinov at cogentembedded.com>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
> 
> ---
>  arch/arm/configs/marzen_defconfig |    7 +++++++
>  1 file changed, 7 insertions(+)

Thanks, queued-up for v3.11 in the defconfig-marzen branch.


From sergei.shtylyov at cogentembedded.com  Thu Apr 18 09:30:09 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Thu, 18 Apr 2013 17:30:09 +0400
Subject: [PATCH 2/2] ARM: shmobile: BOCK-W: enable I2C in defconfig
In-Reply-To: <20130418132724.GC20929@verge.net.au>
References: <201304172242.27671.sergei.shtylyov@cogentembedded.com>
 <201304172247.28311.sergei.shtylyov@cogentembedded.com>
 <20130418132724.GC20929@verge.net.au>
Message-ID: <516FF561.5040801@cogentembedded.com>

Hello.

On 18-04-2013 17:27, Simon Horman wrote:

>> From: Vladimir Barinov <vladimir.barinov at cogentembedded.com>

>> Enable I2C driver in 'bockw_defconfig'.

>> Signed-off-by: Vladimir Barinov <vladimir.barinov at cogentembedded.com>
>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

>> ---
>>   arch/arm/configs/bockw_defconfig |    2 ++
>>   1 file changed, 2 insertions(+)

>> Index: renesas/arch/arm/configs/bockw_defconfig
>> ===================================================================
>> --- renesas.orig/arch/arm/configs/bockw_defconfig
>> +++ renesas/arch/arm/configs/bockw_defconfig
>> @@ -73,6 +73,8 @@ CONFIG_SERIAL_SH_SCI_NR_UARTS=6
>>   CONFIG_SERIAL_SH_SCI_CONSOLE=y
>>   # CONFIG_HW_RANDOM is not set
>>   # CONFIG_HWMON is not set
>> +CONFIG_I2C=y
>> +CONFIG_I2C_RCAR=y
>>   CONFIG_USB=y
>>   CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
>>   CONFIG_USB_EHCI_HCD=y

> I have applied the following after resolving conflicts
> (I don't see CONFIG_USB=y in my tree). Please let me
> know if I made an error.

    I wrote in [0/2] that the patch is atop of my unaccepted USB patches.

> I have queued-up the change for v3.11 in the defconfig-bockw branch
> and will push is shortly.

    Have you also queued patch #1? The patch #2 doesn't make much sense 
without it.

WBR, Sergei



From linux at arm.linux.org.uk  Thu Apr 18 09:31:41 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Thu, 18 Apr 2013 14:31:41 +0100
Subject: Removal of NWFPE in its entirety, and VFP emulation code
In-Reply-To: <20130410104002.GF14496@n2100.arm.linux.org.uk>
References: <20130410104002.GF14496@n2100.arm.linux.org.uk>
Message-ID: <20130418133141.GS14496@n2100.arm.linux.org.uk>

On Wed, Apr 10, 2013 at 11:40:02AM +0100, Russell King - ARM Linux wrote:
> I have just committed a patch to remove the arch/arm/nwfpe code from
> the kernel, and the VFP code emulating the FP operations.

It's time for a status update on this.

There appears to be some confusion over the license under which *our*
version of the softfloat code is licensed under.

The first point to ensure that everyone understands is that the license
which applies to any code is the applicable license at the point the code
was obtained, not *any* subsequent license updates.  If the license is
changed on a code base, it creates a license "fork" - new copies of the
code base are licensed under the new license terms, but older copies
obtained before the fork point remain under the old license terms.

Our version of softfloat was integrated into the kernel a long time ago,
maybe back in December 2000 - it was certainly in mainline in kernel
version 2.2.19.  This work was done as part of Corel's Netwinder team,
hence the name "nw-fpe" or "netwinder fpe".

This version was derived from the version which could be found at:
	http://HTTP.CS.Berkeley.EDU/~jhauser/arithmetic/softfloat.html
which was licensed as per the documentation within the files you find
in your kernel source today.  Indeed, the license header in these
softfloat files remained untouched until commit 50a23e6eec6f20d55 -
more on that below.

Sometime later, softfloat moved to a different URL:
	http://www.jhauser.us/arithmetic/SoftFloat-2b/SoftFloat-source.txt
and the original URL became invalid.  It is not clear when this happened,
but dates on the new site suggest 2010.  Also, the softfloat license was
changed (maybe around the same time), with the addition of an
indemnification clause.  This indemnification clause *may* make the new
license incompatible with the GPLv2.  However, this clause only applies
to a new copy of the code, and can not be applied retrospectively to
older versions - even though the text of the code may in fact be
identical.

However, certain folk who like to ensure that all URLs in the kernel point
at valid sites decided to fix any broken URLs - including the softfloat
URLs.  So, commit 50a23e6eec6f20d55 (Update broken web addresses in arch
directory.) changed the URLs in our softfloat files to point at the new
URL.  This, on the face of it, is not a problem.  However, the version it
now points at has a different license.

As our version pre-dates the version at the new URL and the license change,
the license under which *our* version remains is the original license which
does *not* have the indemnification cause, and thus our copy of the code
remains GPLv2 compatible.

Therefore, there is no need to remove this softfloat code from the kernel;
there is no license conflict.


From lee.jones at linaro.org  Thu Apr 18 09:43:16 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Thu, 18 Apr 2013 14:43:16 +0100
Subject: [PATCH 24/32 v2] dmaengine: ste_dma40: Supply full Device Tree
 parsing support
In-Reply-To: <201304181432.11503.arnd@arndb.de>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-25-git-send-email-lee.jones@linaro.org>
 <20130418121253.GF27903@gmail.com>
 <201304181432.11503.arnd@arndb.de>
Message-ID: <20130418134316.GA3959@gmail.com>

On Thu, 18 Apr 2013, Arnd Bergmann wrote:

> On Thursday 18 April 2013, Lee Jones wrote:
> > +Clients
> > +Required properties:
> > +- dmas: Comma separated list of dma channel requests
> > +- dma-names: Names of the aforementioned requested channels
> > +
> > +Each dmas request consists of 4 cells:
> > +  1. A phandle pointing to the DMA controller
> > +  2. Device Type
> > +  3. The DMA request line number (only when 'use fixed channel' is set)
> > +  4. A 32bit mask specifying; mode, direction and endianess [NB: This list will grow]
> > +        bit 1: Mode:
> > +           0: Logical
> > +           1: Physical
> > +        bit 2: Direction:
> > +           0: Mem to Mem
> > +           1: Mem to Dev
> 
> You probably mean 
> 
> 		0: Dev to mem
> 
> Related to this, I would recommend not listing bit numbers like this, since there
> is some amount of confusion regarding how they are counted: zero-based on one-based
> and LSB-to-MSB or MSB-to-LSB
> 
> You can completely avoid this problem by listing them as bit masks:
> 
> 	0x00000002:
> 		Logical channel when unset
> 		Physical channel when set
> 	0x00000004:
> 		Direction from device when unset
> 		Direction to device when unset
> 	... 
> 
> > +		dmas = <&dma 13 0 0x8>, /* Logical - DevToMem */
> > +		       <&dma 13 0 0x4>; /* Logical - MemToDev */
> 
> The bit in the example no longer matches the description.
> 
> > +
> > +	switch (D40_DT_FLAGS_DIR(flags)) {
> > +	case 0: cfg.dir = STEDMA40_MEM_TO_MEM; break;
> > +	case 1: cfg.dir = STEDMA40_MEM_TO_PERIPH; break;
> > +	}
> 
> Same typo above.
> 
> > +	if (cfg.dir == STEDMA40_PERIPH_TO_MEM)
> > +		cfg.src_info.big_endian = D40_DT_FLAGS_BIG_ENDIAN(flags);
> > +	if (cfg.dir == STEDMA40_MEM_TO_PERIPH)
> > +		cfg.dst_info.big_endian = D40_DT_FLAGS_BIG_ENDIAN(flags);
> 
> You can fold these two into the switch statement above.

This is what happens when you rush a fixup. :)

I'll do it properly now.

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From horms at verge.net.au  Thu Apr 18 09:43:50 2013
From: horms at verge.net.au (Simon Horman)
Date: Thu, 18 Apr 2013 22:43:50 +0900
Subject: [PATCH] ARM: shmobile: r8a7740: Add Suspend-To-RAM modes and
 CPUIdle
In-Reply-To: <CABYn4szC5XE5GV_y40h0h8rdemtnhEMeHTdtOm=JyoPYFzviAw@mail.gmail.com>
References: <1365609107-14290-1-git-send-email-hechtb+renesas@gmail.com>
 <5165E929.9030309@linaro.org>
 <CABYn4sxEOvQhZP7GnS5-AgNjkvJJXyv4n1UjVGBjXbVq0N+9_A@mail.gmail.com>
 <51667D68.7070804@linaro.org> <20130412002535.GB24461@verge.net.au>
 <CABYn4szC5XE5GV_y40h0h8rdemtnhEMeHTdtOm=JyoPYFzviAw@mail.gmail.com>
Message-ID: <20130418134350.GI20929@verge.net.au>

On Wed, Apr 17, 2013 at 02:06:20PM +0200, Bastian Hecht wrote:
> Hello Simon,
> 
> 2013/4/12 Simon Horman <horms at verge.net.au>:
> > On Thu, Apr 11, 2013 at 11:07:52AM +0200, Daniel Lezcano wrote:
> >> On 04/11/2013 09:07 AM, Bastian Hecht wrote:
> >> > Hello Daniel,
> >> >
> >> > thanks for the consolidation efforts.
> >> >
> >> > 2013/4/11 Daniel Lezcano <daniel.lezcano at linaro.org>:
> >> >> On 04/10/2013 05:51 PM, Bastian Hecht wrote:
> >> >>> We add 2 sleep modes and register a CPUIdle driver that uses them.
> >> >>>
> >> >>> - A3SM PLL0 on/off:     Power domain A3SM that contains the ARM core
> >> >>>                         and the 2nd level cache with either PLL0 on
> >> >>>                       or off
> >> >>>
> >> >>> As the suspend to memory mechanism we use A3SM PLL off.
> >> >>>
> >> >>> The setup of the SYSC regarding the external IRQs is taken from
> >> >>> pm-sh7372.c from Magnus Damm.
> >> >>>
> >> >>> Signed-off-by: Bastian Hecht <hechtb+renesas at gmail.com>
> >> >>> ---
> >> >>> Ok I need to add some remarks here:
> >> >>>
> >> >>> First this patch relies on a fix I've sent out today:
> >> >>> "ARM: hw_breakpoint: Do not use __cpuinitdata for dbg_cpu_pm_nb"
> >> >>> Without it we can't use suspend at all without a kernel panic.
> >> >>>
> >> >>> Next you can test this in two ways:
> >> >>> Either add IRQF_NO_SUSPEND to the touchscreen driver st1232 at IRQ registration
> >> >>> (hack) or extend the irqpin driver to support wakeup devices properly, meaning
> >> >>> adding suspend and resume callbacks that handle it (proper way). Or you can add
> >> >>> no_console_suspend to the boot options in r8a7740-armadillo800eva.dts. This way
> >> >>> you can use the serial console as wakeup device.
> >> >>>
> >> >>>
> >> >>>  arch/arm/mach-shmobile/Makefile               |    2 +-
> >> >>>  arch/arm/mach-shmobile/include/mach/r8a7740.h |    2 +
> >> >>>  arch/arm/mach-shmobile/pm-r8a7740.c           |  220 ++++++++++++++++++++++++-
> >> >>>  arch/arm/mach-shmobile/sleep-r8a7740.S        |   68 ++++++++
> >> >>>  4 files changed, 289 insertions(+), 3 deletions(-)
> >> >>>  create mode 100644 arch/arm/mach-shmobile/sleep-r8a7740.S
> >> >>>
> >> >>> diff --git a/arch/arm/mach-shmobile/Makefile b/arch/arm/mach-shmobile/Makefile
> >> >>> index 068f1da..0568894 100644
> >> >>> --- a/arch/arm/mach-shmobile/Makefile
> >> >>> +++ b/arch/arm/mach-shmobile/Makefile
> >> >>> @@ -30,7 +30,7 @@ obj-$(CONFIG_SUSPEND)               += suspend.o
> >> >>>  obj-$(CONFIG_CPU_IDLE)               += cpuidle.o
> >> >>>  obj-$(CONFIG_ARCH_SHMOBILE)  += pm-rmobile.o
> >> >>>  obj-$(CONFIG_ARCH_SH7372)    += pm-sh7372.o sleep-sh7372.o
> >> >>> -obj-$(CONFIG_ARCH_R8A7740)   += pm-r8a7740.o
> >> >>> +obj-$(CONFIG_ARCH_R8A7740)   += pm-r8a7740.o sleep-r8a7740.o
> >> >>>  obj-$(CONFIG_ARCH_R8A7779)   += pm-r8a7779.o
> >> >>>  obj-$(CONFIG_ARCH_SH73A0)    += pm-sh73a0.o
> >> >>>
> >> >>> diff --git a/arch/arm/mach-shmobile/include/mach/r8a7740.h b/arch/arm/mach-shmobile/include/mach/r8a7740.h
> >> >>> index abdc4d4..ba4707b 100644
> >> >>> --- a/arch/arm/mach-shmobile/include/mach/r8a7740.h
> >> >>> +++ b/arch/arm/mach-shmobile/include/mach/r8a7740.h
> >> >>> @@ -540,6 +540,8 @@ extern void r8a7740_add_standard_devices(void);
> >> >>>  extern void r8a7740_clock_init(u8 md_ck);
> >> >>>  extern void r8a7740_pinmux_init(void);
> >> >>>  extern void r8a7740_pm_init(void);
> >> >>> +extern void r8a7740_resume(void);
> >> >>> +extern void r8a7740_shutdown(void);
> >> >>>
> >> >>>  #ifdef CONFIG_PM
> >> >>>  extern void __init r8a7740_init_pm_domains(void);
> >> >>> diff --git a/arch/arm/mach-shmobile/pm-r8a7740.c b/arch/arm/mach-shmobile/pm-r8a7740.c
> >> >>> index 40b87aa..d4613f0 100644
> >> >>> --- a/arch/arm/mach-shmobile/pm-r8a7740.c
> >> >>> +++ b/arch/arm/mach-shmobile/pm-r8a7740.c
> >> >>> @@ -8,10 +8,54 @@
> >> >>>   * License.  See the file "COPYING" in the main directory of this archive
> >> >>>   * for more details.
> >> >>>   */
> >> >>> +#include <linux/bitrev.h>
> >> >>>  #include <linux/console.h>
> >> >>> +#include <linux/cpuidle.h>
> >> >>> +#include <linux/module.h>
> >> >>>  #include <linux/suspend.h>
> >> >>> +#include <linux/io.h>
> >> >>> +#include <asm/suspend.h>
> >> >>> +#include <asm/cacheflush.h>
> >> >>> +#include <asm/cpuidle.h>
> >> >>> +#include <asm/hardware/cache-l2x0.h>
> >> >>>  #include <mach/pm-rmobile.h>
> >> >>>  #include <mach/common.h>
> >> >>> +#include <mach/r8a7740.h>
> >> >>> +
> >> >>> +/* CPGA */
> >> >>> +#define PLLC01STPCR  IOMEM(0xe61500c8)
> >> >>> +#define SYSTBCR              IOMEM(0xe6150024)
> >> >>> +
> >> >>> +/* SYSC */
> >> >>> +#define STBCHR               IOMEM(0xe6180000)
> >> >>> +#define STBCHRB              IOMEM(0xe6180040)
> >> >>> +#define SPDCR                IOMEM(0xe6180008)
> >> >>> +#define SBAR         IOMEM(0xe6180020)
> >> >>> +#define SRSTFR               IOMEM(0xe61800B4)
> >> >>> +#define WUPSMSK              IOMEM(0xe618002c)
> >> >>> +#define WUPSMSK2     IOMEM(0xe6180048)
> >> >>> +#define WUPSFAC              IOMEM(0xe6180098)
> >> >>> +#define IRQCR                IOMEM(0xe618022c)
> >> >>> +#define IRQCR2               IOMEM(0xe6180238)
> >> >>> +#define IRQCR3               IOMEM(0xe6180244)
> >> >>> +#define IRQCR4               IOMEM(0xe6180248)
> >> >>> +
> >> >>> +/* SRSTFR flags */
> >> >>> +#define RAMST                (1 << 19)
> >> >>> +#define RCLNKA               (1 << 7)
> >> >>> +#define RCPRES               (1 << 5)
> >> >>> +#define RCWD1                (1 << 4)
> >> >>> +#define RPF          (1 << 0)
> >> >>> +
> >> >>> +/* INTC */
> >> >>> +#define ICR1A                IOMEM(0xe6900000)
> >> >>> +#define ICR2A                IOMEM(0xe6900004)
> >> >>> +#define ICR3A                IOMEM(0xe6900008)
> >> >>> +#define ICR4A                IOMEM(0xe690000c)
> >> >>> +#define INTMSK00A    IOMEM(0xe6900040)
> >> >>> +#define INTMSK10A    IOMEM(0xe6900044)
> >> >>> +#define INTMSK20A    IOMEM(0xe6900048)
> >> >>> +#define INTMSK30A    IOMEM(0xe690004c)
> >> >>>
> >> >>>  #ifdef CONFIG_PM
> >> >>>  static int r8a7740_pd_a4s_suspend(void)
> >> >>> @@ -58,12 +102,183 @@ void __init r8a7740_init_pm_domains(void)
> >> >>>       rmobile_init_domains(r8a7740_pm_domains, ARRAY_SIZE(r8a7740_pm_domains));
> >> >>>       pm_genpd_add_subdomain_names("A4S", "A3SP");
> >> >>>  }
> >> >>> -
> >> >>>  #endif /* CONFIG_PM */
> >> >>>
> >> >>> +#if defined(CONFIG_SUSPEND) || defined(CONFIG_CPU_IDLE)
> >> >>> +static void r8a7740_set_reset_vector(unsigned long address)
> >> >>> +{
> >> >>> +     __raw_writel(address, SBAR);
> >> >>> +}
> >> >>> +
> >> >>> +static void r8a7740_icr_to_irqcr(unsigned long icr, u16 *irqcr1p, u16 *irqcr2p)
> >> >>> +{
> >> >>> +     u16 tmp, irqcr1, irqcr2;
> >> >>> +     int k;
> >> >>> +
> >> >>> +     irqcr1 = 0;
> >> >>> +     irqcr2 = 0;
> >> >>> +
> >> >>> +     /* convert INTCA ICR register layout to SYSC IRQCR+IRQCR2 */
> >> >>> +     for (k = 0; k <= 7; k++) {
> >> >>> +             tmp = (icr >> ((7 - k) * 4)) & 0xf;
> >> >>> +             irqcr1 |= (tmp & 0x03) << (k * 2);
> >> >>> +             irqcr2 |= (tmp >> 2) << (k * 2);
> >> >>> +     }
> >> >>> +
> >> >>> +     *irqcr1p = irqcr1;
> >> >>> +     *irqcr2p = irqcr2;
> >> >>> +}
> >> >>> +
> >> >>> +static void r8a7740_setup_sysc(unsigned long msk, unsigned long msk2)
> >> >>> +{
> >> >>> +     u16 irqcrx_low, irqcrx_high, irqcry_low, irqcry_high;
> >> >>> +     unsigned long tmp;
> >> >>> +
> >> >>> +     /* read IRQ0A -> IRQ15A mask */
> >> >>> +     tmp = bitrev8(__raw_readb(INTMSK00A));
> >> >>> +     tmp |= bitrev8(__raw_readb(INTMSK10A)) << 8;
> >> >>> +
> >> >>> +     /* setup WUPSMSK from clocks and external IRQ mask */
> >> >>> +     msk = (~msk & 0xc030000f) | (tmp << 4);
> >> >>> +     __raw_writel(msk, WUPSMSK);
> >> >>> +
> >> >>> +     /* propage level/edge trigger for external IRQ 0->15 */
> >> >>> +     r8a7740_icr_to_irqcr(__raw_readl(ICR1A), &irqcrx_low, &irqcry_low);
> >> >>> +     r8a7740_icr_to_irqcr(__raw_readl(ICR2A), &irqcrx_high, &irqcry_high);
> >> >>> +     __raw_writel((irqcrx_high << 16) | irqcrx_low, IRQCR);
> >> >>> +     __raw_writel((irqcry_high << 16) | irqcry_low, IRQCR2);
> >> >>> +
> >> >>> +     /* read IRQ16A -> IRQ31A mask */
> >> >>> +     tmp = bitrev8(__raw_readb(INTMSK20A));
> >> >>> +     tmp |= bitrev8(__raw_readb(INTMSK30A)) << 8;
> >> >>> +
> >> >>> +     /* setup WUPSMSK2 from clocks and external IRQ mask */
> >> >>> +     msk2 = (~msk2 & 0x00030000) | tmp;
> >> >>> +     __raw_writel(msk2, WUPSMSK2);
> >> >>> +
> >> >>> +     /* propage level/edge trigger for external IRQ 16->31 */
> >> >>> +     r8a7740_icr_to_irqcr(__raw_readl(ICR3A), &irqcrx_low, &irqcry_low);
> >> >>> +     r8a7740_icr_to_irqcr(__raw_readl(ICR4A), &irqcrx_high, &irqcry_high);
> >> >>> +     __raw_writel((irqcrx_high << 16) | irqcrx_low, IRQCR3);
> >> >>> +     __raw_writel((irqcry_high << 16) | irqcry_low, IRQCR4);
> >> >>> +}
> >> >>> +
> >> >>> +static void r8a7740_prepare_wakeup(void)
> >> >>> +{
> >> >>> +     /* clear all flags that lead to a cold boot */
> >> >>> +     __raw_writel(~(RAMST | RCLNKA | RCPRES | RCWD1 | RPF), SRSTFR);
> >> >>> +     /* indicate warm boot */
> >> >>> +     __raw_writel(0x80000000, STBCHRB);
> >> >>> +     /* clear other flags checked by internal ROM boot loader */
> >> >>> +     __raw_writel(0x00000000, STBCHR);
> >> >>> +}
> >> >>> +
> >> >>> +static int r8a7740_do_suspend(unsigned long unused)
> >> >>> +{
> >> >>> +     /*
> >> >>> +      * cpu_suspend() guarantees that all data made it to the L2.
> >> >>> +      * Flush it out now and disable the cache controller.
> >> >>> +      */
> >> >>> +     outer_flush_all();
> >> >>> +     outer_disable();
> >> >>> +
> >> >>> +     r8a7740_shutdown();
> >> >>> +
> >> >>> +     /* in case WFI fails to enter the low power state, restore things */
> >> >>> +     outer_resume();
> >> >>> +
> >> >>> +     return 0;
> >> >>> +}
> >> >>> +
> >> >>> +static void r8a7740_enter_a3sm_common(int pllc0_on)
> >> >>> +{
> >> >>> +     u32 reg32;
> >> >>> +
> >> >>> +     if (pllc0_on)
> >> >>> +             __raw_writel(0, PLLC01STPCR);
> >> >>> +     else
> >> >>> +             __raw_writel(1 << 28, PLLC01STPCR);
> >> >>> +
> >> >>> +     r8a7740_set_reset_vector(__pa(r8a7740_resume));
> >> >>> +     r8a7740_prepare_wakeup();
> >> >>> +     r8a7740_setup_sysc(1 << 0, 0);
> >> >>> +
> >> >>> +     /* Activate delayed shutdown of A3SM */
> >> >>> +     reg32 = __raw_readl(SPDCR);
> >> >>> +     reg32 |= (1 << 31) | (1 << 12);
> >> >>> +     __raw_writel(reg32, SPDCR);
> >> >>> +
> >> >>> +     /* We activate CPU Core Standby as well here */
> >> >>> +     reg32 = __raw_readl(SYSTBCR);
> >> >>> +     reg32 |= (1 << 4);
> >> >>> +     __raw_writel(reg32, SYSTBCR);
> >> >>> +
> >> >>> +     /* Clear Wakeup Factors and do suspend */
> >> >>> +     reg32 = __raw_readl(WUPSFAC);
> >> >>> +     cpu_suspend(0, r8a7740_do_suspend);
> >> >>> +     outer_resume();
> >> >>> +     reg32 = __raw_readl(WUPSFAC);
> >> >>> +
> >> >>> +     /* Clear CPU Core Standby flag for other WFI instructions */
> >> >>> +     reg32 &= ~(1 << 4);
> >> >>> +     __raw_writel(reg32, SYSTBCR);
> >> >>> +
> >> >>> +}
> >> >>> +#endif /* CONFIG_SUSPEND || CONFIG_CPU_IDLE */
> >> >>> +
> >> >>> +#ifdef CONFIG_CPU_IDLE
> >> >>> +static int r8a7740_enter_a3sm_pll_on(struct cpuidle_device *dev,
> >> >>> +                                     struct cpuidle_driver *drv, int index)
> >> >>> +{
> >> >>> +     r8a7740_enter_a3sm_common(1);
> >> >>> +     return 1;
> >> >>> +}
> >> >>> +
> >> >>> +static int r8a7740_enter_a3sm_pll_off(struct cpuidle_device *dev,
> >> >>> +                                     struct cpuidle_driver *drv, int index)
> >> >>> +{
> >> >>> +     r8a7740_enter_a3sm_common(0);
> >> >>> +     return 2;
> >> >>> +}
> >> >>> +
> >> >>> +static struct cpuidle_driver r8a7740_cpuidle_driver = {
> >> >>> +     .name                   = "r8a7740_cpuidle",
> >> >>> +     .owner                  = THIS_MODULE,
> >> >>> +     .en_core_tk_irqen       = 1,
> >> >>> +     .state_count            = 3,
> >> >>> +     .safe_state_index       = 0, /* C1 */
> >> >>> +     .states[0] = ARM_CPUIDLE_WFI_STATE,
> >> >>> +     .states[0].enter = shmobile_enter_wfi,
> >> >>
> >> >> The WFI macro already set a simple enter function doing cpu_do_idle.
> >> >
> >> > Oh yes, I'll remove it.
> >> >
> >> >> We are trying to consolidate the cpuidle drivers across the different
> >> >> platforms [1]. One of the objective is to move the cpuidle drivers to
> >> >> drivers/cpuidle, a place where they belong to.
> >> >>
> >> >> Do you think it is possible you split your code to have one part with
> >> >> the cpuidle driver and another part with the PM code ?
> >> >
> >> > Hmm. The CPUIdle part is enclosed in the #ifdef CONFIG_CPU_IDLE part anyway.
> >> > The other part (CONFIG_SUSPEND | CONFIG_CPU_IDLE) contains the part
> >> > that actually does drive down the hardware and is needed as soon as
> >> > SUSPEND or CPUIdle is used.
> >> >
> >> > So is it split well enough already or does it help if I split my patch
> >> > into 2, first adding suspend and then CPUIdle to the same file? But
> >> > the outcome will be the same I think.
> >>
> >>
> >> Well, if you can convert the pm functions into ops used in the cpuidle
> >> driver and then create a file eg. cpuidle-r8a7740.c with the cpuidle
> >> code calling the ops that will separate clearly the cpuidle code from
> >> the pm code and make easier to move the cpuidle driver to the
> >> drivers/cpuidle directory. Also, I think that will help to consolidate
> >> the other shmobile cpuidle drivers, maybe into a single one.
> >
> > I wonder if that is an appropriate pre-requisite for adding
> > r8a7940 cpuidle support. My preference, which may well be compatible
> > with your comments, is to bring support for that SoC up to the same level
> > as support for other shmobile SoCs and to treat consolidation as a
> > an area of work that is undertaken in parallel.
> 
> I just realize that I've overlooked this comment. Sorry for that. I
> thought about the same:
> The advantages of Daniel's way vs the temporary cluttering of our
> arch/arm/mach-shmobile tree.
> I'm really open for both ways - I think the extra cpuidle file doesn't
> hurt too much and it would be OK to go with it, but I can merge the 2
> patches if you strongly prefer the other way.

I believe that I prefer 2 patches.


From grant.likely at secretlab.ca  Thu Apr 18 09:44:01 2013
From: grant.likely at secretlab.ca (Grant Likely)
Date: Thu, 18 Apr 2013 14:44:01 +0100
Subject: [PATCH v7 2/3] of/pci: Provide support for parsing PCI DT ranges
 property
In-Reply-To: <1366107508-12672-3-git-send-email-Andrew.Murray@arm.com>
References: <1366107508-12672-1-git-send-email-Andrew.Murray@arm.com>
 <1366107508-12672-3-git-send-email-Andrew.Murray@arm.com>
Message-ID: <20130418134401.84AEE3E1319@localhost>

On Tue, 16 Apr 2013 11:18:27 +0100, Andrew Murray <Andrew.Murray at arm.com> wrote:
> This patch factors out common implementation patterns to reduce overall kernel
> code and provide a means for host bridge drivers to directly obtain struct
> resources from the DT's ranges property without relying on architecture specific
> DT handling. This will make it easier to write archiecture independent host bridge
> drivers and mitigate against further duplication of DT parsing code.
> 
> This patch can be used in the following way:
> 
> 	struct of_pci_range_parser parser;
> 	struct of_pci_range range;
> 
> 	if (of_pci_range_parser(&parser, np))
> 		; //no ranges property
> 
> 	for_each_of_pci_range(&parser, &range) {
> 
> 		/*
> 			directly access properties of the address range, e.g.:
> 			range.pci_space, range.pci_addr, range.cpu_addr,
> 			range.size, range.flags
> 
> 			alternatively obtain a struct resource, e.g.:
> 			struct resource res;
> 			of_pci_range_to_resource(&range, np, &res);
> 		*/
> 	}
> 
> Additionally the implementation takes care of adjacent ranges and merges them
> into a single range (as was the case with powerpc and microblaze).
> 
> Signed-off-by: Andrew Murray <Andrew.Murray at arm.com>
> Signed-off-by: Liviu Dudau <Liviu.Dudau at arm.com>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> Reviewed-by: Rob Herring <rob.herring at calxeda.com>
> Tested-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> Tested-by: Linus Walleij <linus.walleij at linaro.org>

Acked-by: Grant Likely <grant.likely at secretlab.ca>

But comments below...

> ---
>  drivers/of/address.c       |   67 ++++++++++++++++++++++++++
>  drivers/of/of_pci.c        |  113 ++++++++++++++++----------------------------
>  include/linux/of_address.h |   46 ++++++++++++++++++
>  3 files changed, 154 insertions(+), 72 deletions(-)
> 
> diff --git a/drivers/of/address.c b/drivers/of/address.c
> index 04da786..6eec70c 100644
> --- a/drivers/of/address.c
> +++ b/drivers/of/address.c
> @@ -227,6 +227,73 @@ int of_pci_address_to_resource(struct device_node *dev, int bar,
>  	return __of_address_to_resource(dev, addrp, size, flags, NULL, r);
>  }
>  EXPORT_SYMBOL_GPL(of_pci_address_to_resource);
> +
> +int of_pci_range_parser(struct of_pci_range_parser *parser,
> +			struct device_node *node)
> +{
> +	const int na = 3, ns = 2;
> +	int rlen;
> +
> +	parser->node = node;
> +	parser->pna = of_n_addr_cells(node);
> +	parser->np = parser->pna + na + ns;
> +
> +	parser->range = of_get_property(node, "ranges", &rlen);
> +	if (parser->range == NULL)
> +		return -ENOENT;
> +
> +	parser->end = parser->range + rlen / sizeof(__be32);
> +
> +	return 0;
> +}
> +EXPORT_SYMBOL_GPL(of_pci_range_parser);

"of_pci_range_parser_init" would be a clearer name

> +struct of_pci_range *of_pci_process_ranges(struct of_pci_range_parser *parser,
> +						struct of_pci_range *range)

Similarly, "of_pci_range_parser_one" would be more consistent.

> +{
> +	const int na = 3, ns = 2;
> +
> +	if (!range)
> +		return NULL;
> +
> +	if (!parser->range || parser->range + parser->np > parser->end)
> +		return NULL;
> +
> +	range->pci_space = parser->range[0];
> +	range->flags = of_bus_pci_get_flags(parser->range);
> +	range->pci_addr = of_read_number(parser->range + 1, ns);
> +	range->cpu_addr = of_translate_address(parser->node,
> +				parser->range + na);
> +	range->size = of_read_number(parser->range + parser->pna + na, ns);
> +
> +	parser->range += parser->np;
> +
> +	/* Now consume following elements while they are contiguous */
> +	while (parser->range + parser->np <= parser->end) {
> +		u32 flags, pci_space;
> +		u64 pci_addr, cpu_addr, size;
> +
> +		pci_space = be32_to_cpup(parser->range);
> +		flags = of_bus_pci_get_flags(parser->range);
> +		pci_addr = of_read_number(parser->range + 1, ns);
> +		cpu_addr = of_translate_address(parser->node,
> +				parser->range + na);
> +		size = of_read_number(parser->range + parser->pna + na, ns);
> +
> +		if (flags != range->flags)
> +			break;
> +		if (pci_addr != range->pci_addr + range->size ||
> +		    cpu_addr != range->cpu_addr + range->size)
> +			break;
> +
> +		range->size += size;
> +		parser->range += parser->np;
> +	}
> +
> +	return range;
> +}
> +EXPORT_SYMBOL_GPL(of_pci_process_ranges);
> +
>  #endif /* CONFIG_PCI */
>  
>  /*
> diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
> index 1626172..e5ab604 100644
> --- a/drivers/of/of_pci.c
> +++ b/drivers/of/of_pci.c
> @@ -2,6 +2,7 @@
>  #include <linux/export.h>
>  #include <linux/of.h>
>  #include <linux/of_pci.h>
> +#include <linux/of_address.h>
>  #include <asm/prom.h>
>  
>  #if defined(CONFIG_PPC32) || defined(CONFIG_PPC64) || defined(CONFIG_MICROBLAZE)
> @@ -82,67 +83,43 @@ EXPORT_SYMBOL_GPL(of_pci_find_child_device);
>  void pci_process_bridge_OF_ranges(struct pci_controller *hose,
>  				  struct device_node *dev, int primary)
>  {
> -	const u32 *ranges;
> -	int rlen;
> -	int pna = of_n_addr_cells(dev);
> -	int np = pna + 5;
>  	int memno = 0, isa_hole = -1;
> -	u32 pci_space;
> -	unsigned long long pci_addr, cpu_addr, pci_next, cpu_next, size;
>  	unsigned long long isa_mb = 0;
>  	struct resource *res;
> +	struct of_pci_range range;
> +	struct of_pci_range_parser parser;
> +	u32 res_type;
>  
>  	pr_info("PCI host bridge %s %s ranges:\n",
>  	       dev->full_name, primary ? "(primary)" : "");
>  
> -	/* Get ranges property */
> -	ranges = of_get_property(dev, "ranges", &rlen);
> -	if (ranges == NULL)
> +	/* Check for ranges property */
> +	if (of_pci_range_parser(&parser, dev))
>  		return;
>  
> -	/* Parse it */
>  	pr_debug("Parsing ranges property...\n");
> -	while ((rlen -= np * 4) >= 0) {
> +	for_each_of_pci_range(&parser, &range) {
>  		/* Read next ranges element */
> -		pci_space = ranges[0];
> -		pci_addr = of_read_number(ranges + 1, 2);
> -		cpu_addr = of_translate_address(dev, ranges + 3);
> -		size = of_read_number(ranges + pna + 3, 2);

Tip: the diff on this function would be a whole lot simpler if the
above locals were kept, but updated from the ranges structure. Not at
all a big problem, but it is something that makes changes like this
easier to review. The removal of the locals could also be split into a
separate patch to end up with the same result.

> -
> -		pr_debug("pci_space: 0x%08x pci_addr:0x%016llx ",
> -				pci_space, pci_addr);
> -		pr_debug("cpu_addr:0x%016llx size:0x%016llx\n",
> -					cpu_addr, size);
> -
> -		ranges += np;
> +		pr_debug("pci_space: 0x%08x pci_addr: 0x%016llx ",
> +				range.pci_space, range.pci_addr);
> +		pr_debug("cpu_addr: 0x%016llx size: 0x%016llx\n",
> +				range.cpu_addr, range.size);

Nit: the patch changed whitespace on the pr_debug() statements, so even
though the first line of each is identical, they look different in the
patch.

>  
>  		/* If we failed translation or got a zero-sized region
>  		 * (some FW try to feed us with non sensical zero sized regions
>  		 * such as power3 which look like some kind of attempt
>  		 * at exposing the VGA memory hole)
>  		 */
> -		if (cpu_addr == OF_BAD_ADDR || size == 0)
> +		if (range.cpu_addr == OF_BAD_ADDR || range.size == 0)
>  			continue;

Can this also be rolled into the parsing iterator?

>  
> -		/* Now consume following elements while they are contiguous */
> -		for (; rlen >= np * sizeof(u32);
> -		     ranges += np, rlen -= np * 4) {
> -			if (ranges[0] != pci_space)
> -				break;
> -			pci_next = of_read_number(ranges + 1, 2);
> -			cpu_next = of_translate_address(dev, ranges + 3);
> -			if (pci_next != pci_addr + size ||
> -			    cpu_next != cpu_addr + size)
> -				break;
> -			size += of_read_number(ranges + pna + 3, 2);
> -		}
> -
>  		/* Act based on address space type */
>  		res = NULL;
> -		switch ((pci_space >> 24) & 0x3) {
> -		case 1:		/* PCI IO space */
> +		res_type = range.flags & IORESOURCE_TYPE_BITS;
> +		if (res_type == IORESOURCE_IO) {

Why the change from switch() to an if/else if sequence?

But those are mostly nitpicks. If this is deferred to v3.10 then I would
suggest fixing them up and posting for another round of review.

g.


From nicolas.ferre at atmel.com  Thu Apr 18 09:45:32 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Thu, 18 Apr 2013 15:45:32 +0200
Subject: [PATCH 18/19] ARM: at91: suspend both memory controllers on
 at91sam9263
In-Reply-To: <1359153858-31992-19-git-send-email-arnd@arndb.de>
References: <1359123276-15833-1-git-send-email-arnd@arndb.de>
 <1359153858-31992-1-git-send-email-arnd@arndb.de>
 <1359153858-31992-19-git-send-email-arnd@arndb.de>
Message-ID: <516FF8FC.7070901@atmel.com>

I come back to this for AT91


On 01/25/2013 11:44 PM, Arnd Bergmann :
> For the past three years, we have had a #warning in
> mach-at91 about the sdram_selfrefresh_enable or
> at91sam9_standby functions possibly not working on
> at91sam9263. In the meantime a function was added
> to do the right thing on at91sam9g45, which looks like
> it should also work on '9263.
> 
> This patch blindly removes the warning and changes the
> at91sam9263 to use the same code at at91sam9g45, which
> may or may not be the right solution. If it is not,
> maybe someone could provide a better fix.

Maybe you can remove this paragraph: now you are using the proper fix
with proper RAM type.

> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Cc: Nicolas Ferre <nicolas.ferre at atmel.com>

Acked-by: Nicolas Ferre <nicolas.ferre at atmel.com>

What is the future of this patch series: do you want us to take this
patch separately or to you want to apply the whole series on the arm-soc
tree?


> Cc: Jean-Christophe Plagniol-Villard <plagnioj at jcrosoft.com>
> Cc: Andrew Victor <linux at maxim.org.za>
> Cc: Albin Tonnerre <albin.tonnerre at free-electrons.com>
> Cc: Daniel Lezcano <daniel.lezcano at linaro.org>

Moreover, this patch my conflict with Daniel's current initiative to
move cpuidle driver to its own directory: how do we coordinate with each
other?

Arnd,
Thanks a lot for having taking care of this old warning...


Best regards,

> ---
>  arch/arm/mach-at91/cpuidle.c |  2 ++
>  arch/arm/mach-at91/pm.c      |  2 ++
>  arch/arm/mach-at91/pm.h      | 30 ++++++++++++++++++++++++------
>  3 files changed, 28 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/arm/mach-at91/cpuidle.c b/arch/arm/mach-at91/cpuidle.c
> index 0c63815..4c67946 100644
> --- a/arch/arm/mach-at91/cpuidle.c
> +++ b/arch/arm/mach-at91/cpuidle.c
> @@ -38,6 +38,8 @@ static int at91_enter_idle(struct cpuidle_device *dev,
>  		at91rm9200_standby();
>  	else if (cpu_is_at91sam9g45())
>  		at91sam9g45_standby();
> +	else if (cpu_is_at91sam9263())
> +		at91sam9263_standby();
>  	else
>  		at91sam9_standby();
>  
> diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
> index adb6db8..b8017c1 100644
> --- a/arch/arm/mach-at91/pm.c
> +++ b/arch/arm/mach-at91/pm.c
> @@ -267,6 +267,8 @@ static int at91_pm_enter(suspend_state_t state)
>  				at91rm9200_standby();
>  			else if (cpu_is_at91sam9g45())
>  				at91sam9g45_standby();
> +			else if (cpu_is_at91sam9263())
> +				at91sam9263_standby();
>  			else
>  				at91sam9_standby();
>  			break;
> diff --git a/arch/arm/mach-at91/pm.h b/arch/arm/mach-at91/pm.h
> index 38f467c..2f5908f 100644
> --- a/arch/arm/mach-at91/pm.h
> +++ b/arch/arm/mach-at91/pm.h
> @@ -70,13 +70,31 @@ static inline void at91sam9g45_standby(void)
>  	at91_ramc_write(1, AT91_DDRSDRC_LPR, saved_lpr1);
>  }
>  
> -#ifdef CONFIG_SOC_AT91SAM9263
> -/*
> - * FIXME either or both the SDRAM controllers (EB0, EB1) might be in use;
> - * handle those cases both here and in the Suspend-To-RAM support.
> +/* We manage both DDRAM/SDRAM controllers, we need more than one value to
> + * remember.
>   */
> -#warning Assuming EB1 SDRAM controller is *NOT* used
> -#endif
> +static inline void at91sam9263_standby(void)
> +{
> +	u32 lpr0, lpr1;
> +	u32 saved_lpr0, saved_lpr1;
> +
> +	saved_lpr1 = at91_ramc_read(1, AT91_SDRAMC_LPR);
> +	lpr1 = saved_lpr1 & ~AT91_SDRAMC_LPCB;
> +	lpr1 |= AT91_SDRAMC_LPCB_SELF_REFRESH;
> +
> +	saved_lpr0 = at91_ramc_read(0, AT91_SDRAMC_LPR);
> +	lpr0 = saved_lpr0 & ~AT91_SDRAMC_LPCB;
> +	lpr0 |= AT91_SDRAMC_LPCB_SELF_REFRESH;
> +
> +	/* self-refresh mode now */
> +	at91_ramc_write(0, AT91_SDRAMC_LPR, lpr0);
> +	at91_ramc_write(1, AT91_SDRAMC_LPR, lpr1);
> +
> +	cpu_do_idle();
> +
> +	at91_ramc_write(0, AT91_SDRAMC_LPR, saved_lpr0);
> +	at91_ramc_write(1, AT91_SDRAMC_LPR, saved_lpr1);
> +}
>  
>  static inline void at91sam9_standby(void)
>  {
> 


-- 
Nicolas Ferre


From grant.likely at secretlab.ca  Thu Apr 18 09:45:35 2013
From: grant.likely at secretlab.ca (Grant Likely)
Date: Thu, 18 Apr 2013 14:45:35 +0100
Subject: [PATCH v7 3/3] of/pci: mips: convert to common of_pci_range_parser
In-Reply-To: <1366107508-12672-4-git-send-email-Andrew.Murray@arm.com>
References: <1366107508-12672-1-git-send-email-Andrew.Murray@arm.com>
 <1366107508-12672-4-git-send-email-Andrew.Murray@arm.com>
Message-ID: <20130418134535.5189E3E1319@localhost>

On Tue, 16 Apr 2013 11:18:28 +0100, Andrew Murray <Andrew.Murray at arm.com> wrote:
> This patch converts the pci_load_of_ranges function to use the new common
> of_pci_range_parser.
> 
> Signed-off-by: Andrew Murray <Andrew.Murray at arm.com>
> Signed-off-by: Liviu Dudau <Liviu.Dudau at arm.com>
> Reviewed-by: Rob Herring <rob.herring at calxeda.com>

Looks okay to me, and thank you very much for doing the legwork to merge
the common code.

Reviewed-by: Grant Likely <grant.likely at secretlab.ca>



From horms at verge.net.au  Thu Apr 18 09:45:46 2013
From: horms at verge.net.au (Simon Horman)
Date: Thu, 18 Apr 2013 22:45:46 +0900
Subject: [PATCH 2/2] ARM: shmobile: BOCK-W: enable I2C in defconfig
In-Reply-To: <516FF561.5040801@cogentembedded.com>
References: <201304172242.27671.sergei.shtylyov@cogentembedded.com>
 <201304172247.28311.sergei.shtylyov@cogentembedded.com>
 <20130418132724.GC20929@verge.net.au>
 <516FF561.5040801@cogentembedded.com>
Message-ID: <20130418134546.GJ20929@verge.net.au>

On Thu, Apr 18, 2013 at 05:30:09PM +0400, Sergei Shtylyov wrote:
> Hello.
> 
> On 18-04-2013 17:27, Simon Horman wrote:
> 
> >>From: Vladimir Barinov <vladimir.barinov at cogentembedded.com>
> 
> >>Enable I2C driver in 'bockw_defconfig'.
> 
> >>Signed-off-by: Vladimir Barinov <vladimir.barinov at cogentembedded.com>
> >>Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
> 
> >>---
> >>  arch/arm/configs/bockw_defconfig |    2 ++
> >>  1 file changed, 2 insertions(+)
> 
> >>Index: renesas/arch/arm/configs/bockw_defconfig
> >>===================================================================
> >>--- renesas.orig/arch/arm/configs/bockw_defconfig
> >>+++ renesas/arch/arm/configs/bockw_defconfig
> >>@@ -73,6 +73,8 @@ CONFIG_SERIAL_SH_SCI_NR_UARTS=6
> >>  CONFIG_SERIAL_SH_SCI_CONSOLE=y
> >>  # CONFIG_HW_RANDOM is not set
> >>  # CONFIG_HWMON is not set
> >>+CONFIG_I2C=y
> >>+CONFIG_I2C_RCAR=y
> >>  CONFIG_USB=y
> >>  CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
> >>  CONFIG_USB_EHCI_HCD=y
> 
> >I have applied the following after resolving conflicts
> >(I don't see CONFIG_USB=y in my tree). Please let me
> >know if I made an error.
> 
>    I wrote in [0/2] that the patch is atop of my unaccepted USB patches.
> 
> >I have queued-up the change for v3.11 in the defconfig-bockw branch
> >and will push is shortly.
> 
>    Have you also queued patch #1? The patch #2 doesn't make much
> sense without it.

No, I was going to ask for it to be rebased, but I'm happy for it
to wait until your USB changes go in if you are happy to wait.

As for not making much sense, I'm happy with pre-emptively applying
defconfig changes as they are somewhat orthogonal and live in a different
branch.


From marcio at netopen.com.br  Thu Apr 18 08:47:17 2013
From: marcio at netopen.com.br (Marcio Campos de Lima)
Date: Thu, 18 Apr 2013 10:47:17 -0200
Subject: AT91SAM9M10: Problem porting driver for MT9P031 sensor
In-Reply-To: <2001207140.384354.1366290836027.open-xchange@email.1und1.de>
Message-ID: <CD957E83.AF12%marcio@netopen.com.br>


Hi

I am porting the MT9P031 sensor device driver for a custom designed board
based at the AT91SAM9M45-EK development board and Linux 3.6.9.
The driver detects the sensor but does not create /dev/video1. I cannot
even see /dev/video0 that usually is created by default.

Can anybody help me?
Thanks
MArcio




From horms at verge.net.au  Thu Apr 18 09:51:31 2013
From: horms at verge.net.au (Simon Horman)
Date: Thu, 18 Apr 2013 22:51:31 +0900
Subject: [PATCH v5 2/3] ARM: shmobile: kzm9g-reference: add AS3711 and
 CPUFreq DT bindings
In-Reply-To: <1365156038-12467-3-git-send-email-g.liakhovetski@gmx.de>
References: <1365156038-12467-1-git-send-email-g.liakhovetski@gmx.de>
 <1365156038-12467-3-git-send-email-g.liakhovetski@gmx.de>
Message-ID: <20130418135131.GK20929@verge.net.au>

On Fri, Apr 05, 2013 at 12:00:37PM +0200, Guennadi Liakhovetski wrote:
> This adds DT bindings for an AS3711 PMIC, used for supplying power to the
> CPU, some peripherals and the backlight, as well as extends the cpu0 DT
> node with OPPs and a reference to the PMIC to support the CPUFreq and
> CPU DVFS functions.
> 
> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas at gmail.com>
> ---
> 
> v5: make the sd1 regulator immediately suitable for CPUFreq instead of
> postponing it to an incremental patch.
> 
>  arch/arm/boot/dts/sh73a0-kzm9g-reference.dts |   86 ++++++++++++++++++++++++++
>  1 files changed, 86 insertions(+), 0 deletions(-)

Thanks, queued-up for v3.11 in the boards-kzm9g branch.


From catalin.marinas at arm.com  Thu Apr 18 09:51:04 2013
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Thu, 18 Apr 2013 14:51:04 +0100
Subject: [PATCH V3 2/2] ARM: Handle user space mapped pages in
 flush_kernel_dcache_page
In-Reply-To: <20130418114016.GG27197@titan.lakedaemon.net>
References: <1349609352-6408-1-git-send-email-gmbnomis@gmail.com>
 <1349609352-6408-3-git-send-email-gmbnomis@gmail.com>
 <20121008174428.GB3204@arm.com>
 <20121008200216.GA14167@schnuecks.de>
 <20121008202040.GC4625@n2100.arm.linux.org.uk>
 <20121008230733.GA17819@schnuecks.de>
 <20121118211005.GW22106@titan.lakedaemon.net>
 <20130418111608.GF27197@titan.lakedaemon.net>
 <20130418112201.GQ14496@n2100.arm.linux.org.uk>
 <20130418114016.GG27197@titan.lakedaemon.net>
Message-ID: <20130418135104.GA18616@arm.com>

On Thu, Apr 18, 2013 at 12:40:16PM +0100, Jason Cooper wrote:
> Ok, got it.  I should have been more explicit.  LVM doesn't work on ARM.
> iirc, Simon had a demo of dm-crypt also faulting on ARM.  This patch was
> not the correct approach.  Is there an interest (particularly Simon) in
> fixing the problem?

I think fixing this for ARM is useful but I don't have any time to
allocate. I think I acked the first patch in the series but I don't
fully remember the details behind the second one.

As Russell said, flush_kernel_dcache_page() is not the right API.
flush_dcache_page() is not supposed to be used on anonymous pages. What
we have for such pages is flush_anon_page() which is a no-op for VIPT
non-aliasing pages. I can see that __get_user_pages() calls both
flush_anon_page() flush_dcache_page().

Is the problem that you have related to I-D cache coherency? Is
flush_anon_page() the right place for this?

-- 
Catalin


From horms at verge.net.au  Thu Apr 18 09:52:12 2013
From: horms at verge.net.au (Simon Horman)
Date: Thu, 18 Apr 2013 22:52:12 +0900
Subject: [PATCH v5 3/3] ARM: shmobile: sh73a0: add CPUFreq support
In-Reply-To: <1365156038-12467-4-git-send-email-g.liakhovetski@gmx.de>
References: <1365156038-12467-1-git-send-email-g.liakhovetski@gmx.de>
 <1365156038-12467-4-git-send-email-g.liakhovetski@gmx.de>
Message-ID: <20130418135212.GL20929@verge.net.au>

On Fri, Apr 05, 2013 at 12:00:38PM +0200, Guennadi Liakhovetski wrote:
> This patch enables the use of the generic cpufreq-cpu0 driver on sh73a0.
> Providing a regulator, a list of OPPs in DT, combined with a virtual
> cpufreq-cpu0 platform device and a clock, attached to it is everything,
> the cpufreq-cpu0 driver needs. The first sh73a0 platform, implementing
> such CPUFreq support is kzm9g-reference.
> 
> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas at gmail.com>
> ---
> 
> v5: remove sh73a0-kzm9g-reference.dts hunk, it's now merged into patch 2/3
> 
>  arch/arm/mach-shmobile/Kconfig        |    2 ++
>  arch/arm/mach-shmobile/setup-sh73a0.c |    5 +++++
>  2 files changed, 7 insertions(+), 0 deletions(-)

Thanks, queued-up for v3.11 in the soc-sh73a0 branch.


From horms at verge.net.au  Thu Apr 18 09:52:21 2013
From: horms at verge.net.au (Simon Horman)
Date: Thu, 18 Apr 2013 22:52:21 +0900
Subject: [PATCH v5 1/3] ARM: shmobile: sh73a0: add support for adjusting
 CPU frequency
In-Reply-To: <1365156038-12467-2-git-send-email-g.liakhovetski@gmx.de>
References: <1365156038-12467-1-git-send-email-g.liakhovetski@gmx.de>
 <1365156038-12467-2-git-send-email-g.liakhovetski@gmx.de>
Message-ID: <20130418135221.GM20929@verge.net.au>

On Fri, Apr 05, 2013 at 12:00:36PM +0200, Guennadi Liakhovetski wrote:
> On SH73A0 the output of PLL0 is supplied to two dividers, feeding clock to
> the CPU core and SGX. Lower CPU frequencies allow the use of lower supply
> voltages and thus reduce power consumption.
> 
> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas at gmail.com>
> ---
> 
> v5: not based on MSTP-waiting rework, it needs more work
> 
>  arch/arm/mach-shmobile/clock-sh73a0.c |   95 ++++++++++++++++++++++++++++++++-
>  1 files changed, 93 insertions(+), 2 deletions(-)

Thanks, queued-up for v3.11 in the soc-sh73a0 branch. 


From horms at verge.net.au  Thu Apr 18 10:00:25 2013
From: horms at verge.net.au (Simon Horman)
Date: Thu, 18 Apr 2013 23:00:25 +0900
Subject: [PATCH] ARM: shmobile: BOCK-W: enable CONFIG_PM_RUNTIME in
 defconfig
In-Reply-To: <516E8EF9.8030600@cogentembedded.com>
References: <201304170303.46193.sergei.shtylyov@cogentembedded.com>
 <20130417101017.GW14496@n2100.arm.linux.org.uk>
 <516E8EF9.8030600@cogentembedded.com>
Message-ID: <20130418140025.GN20929@verge.net.au>

On Wed, Apr 17, 2013 at 04:00:57PM +0400, Sergei Shtylyov wrote:
> Hello.
> 
> On 17-04-2013 14:10, Russell King - ARM Linux wrote:
> 
> >>From: Vladimir Barinov <vladimir.barinov at cogentembedded.com>
> 
> >>Enable CONFIG_PM_RUNTIME in 'bockw_defconfig' -- it's already used by TMU, SCI,
> >>I2C, and Ether drivers to control the clocks...
> 
> >>Signed-off-by: Vladimir Barinov <vladimir.barinov at cogentembedded.com>
> >>Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
> 
> >>---
> >>The patch is atop of Simon's 'renesas.git' tree, 'renesas-next-20130416' tag.
> 
> >Maybe you should send it to Simon rather than me for initial merging, who
> >would presumably know if this is the right thing for this bockw platform?
> 
>    Blame scripts/get_maintainer.pl.
>    I think Simion will see the patch on the list anyway.

Somehow I missed it, but thanks to patchwork I now have it.
I will queue it up for v3.11.


From marex at denx.de  Thu Apr 18 10:00:27 2013
From: marex at denx.de (Marek Vasut)
Date: Thu, 18 Apr 2013 16:00:27 +0200
Subject: [PATCH] video: mxsfb: Fix colors display on lower color depth
In-Reply-To: <1366277032-671-1-git-send-email-maxime.ripard@free-electrons.com>
References: <516EBCA4.1020609@free-electrons.com>
 <1366277032-671-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <201304181600.27813.marex@denx.de>

Dear Maxime Ripard,

> The current code always registers as a 32 bits display, and uses the
> hardware to drop the MSB of each color to abjust to the interface width
> used by the panel.
> 
> This results on 18 bits (and probably 16 bits display as well) in colors
> being displayed poorly, because the MSB are obviously the most important
> bits for each color definition.
> 
> The default controller behaviour when using an interface width smaller
> than the color depth is to drop the LSBs of each color, which makes more
> sense because you lose the least important part of the color definition.
> 
> So, to fix the colors display, just get back to the default controller
> behaviour.
> 
> Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>

Isn't this what M28EVK is doing already? This was last tested on 3.9-rc3 I 
think:

bits-per-pixel = <16>;
bus-width = <18>;

But it's also true we have all 24 data lines routed to the LCD.

Best regards,
Marek Vasut


From horms at verge.net.au  Thu Apr 18 10:05:52 2013
From: horms at verge.net.au (Simon Horman)
Date: Thu, 18 Apr 2013 23:05:52 +0900
Subject: [PATCH v3 4/4] ARM: shmobile: BOCK-W: enable USB in defconfig
In-Reply-To: <201304170135.10251.sergei.shtylyov@cogentembedded.com>
References: <201304170135.10251.sergei.shtylyov@cogentembedded.com>
Message-ID: <20130418140552.GO20929@verge.net.au>

On Wed, Apr 17, 2013 at 01:35:09AM +0400, Sergei Shtylyov wrote:
> Enable USB platform EHCI/OHCI and common PHY drivers in 'bockw_defconfig'.
> Enable USB storage driver and SCSI disk driver that it needs as well...
> 
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

I realise that this is not going to be useful until the rest
of the series has been merged. But regardless I have pre-emptively
queued it up for v3.11 in the defconfig-bockw branch.
> 
> ---
>  arch/arm/configs/bockw_defconfig |   11 ++++++++++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
> 
> Index: renesas/arch/arm/configs/bockw_defconfig
> ===================================================================
> --- renesas.orig/arch/arm/configs/bockw_defconfig
> +++ renesas/arch/arm/configs/bockw_defconfig
> @@ -48,6 +48,8 @@ CONFIG_DEVTMPFS_MOUNT=y
>  # CONFIG_STANDALONE is not set
>  # CONFIG_PREVENT_FIRMWARE_BUILD is not set
>  # CONFIG_FW_LOADER is not set
> +CONFIG_SCSI=y
> +CONFIG_BLK_DEV_SD=y
>  CONFIG_NETDEVICES=y
>  # CONFIG_NET_CADENCE is not set
>  # CONFIG_NET_VENDOR_BROADCOM is not set
> @@ -71,7 +73,14 @@ CONFIG_SERIAL_SH_SCI_NR_UARTS=6
>  CONFIG_SERIAL_SH_SCI_CONSOLE=y
>  # CONFIG_HW_RANDOM is not set
>  # CONFIG_HWMON is not set
> -# CONFIG_USB_SUPPORT is not set
> +CONFIG_USB=y
> +CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
> +CONFIG_USB_EHCI_HCD=y
> +CONFIG_USB_OHCI_HCD=y
> +CONFIG_USB_OHCI_HCD_PLATFORM=y
> +CONFIG_USB_EHCI_HCD_PLATFORM=y
> +CONFIG_USB_STORAGE=y
> +CONFIG_USB_RCAR_PHY=y
>  CONFIG_UIO=y
>  CONFIG_UIO_PDRV_GENIRQ=y
>  # CONFIG_IOMMU_SUPPORT is not set
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


From jonathan.austin at arm.com  Thu Apr 18 10:10:42 2013
From: jonathan.austin at arm.com (Jonathan Austin)
Date: Thu, 18 Apr 2013 15:10:42 +0100
Subject: [PATCH v11 0/3] Another round of ARMv7-M patches
In-Reply-To: <20130417193746.GR30416@pengutronix.de>
References: <1366215299-31969-1-git-send-email-u.kleine-koenig@pengutronix.de>
 <516EDEDA.1000108@arm.com> <20130417193746.GR30416@pengutronix.de>
Message-ID: <516FFEE2.1070304@arm.com>

Hi,

On 17/04/13 20:37, Uwe Kleine-K?nig wrote:
> Hello,
>
> On Wed, Apr 17, 2013 at 06:41:46PM +0100, Jonathan Austin wrote:
>> The only comment I have left is that I'd really like the
>> BASEADDRESS_V7M_SCB namespaced like the rest of the V7M defines
> The idea behind this naming is that V7M_SCB_BASEADDRESS is in the same

Do you mean is *not* in?

> namespace as V7M_SCB_CPUID so I opened a new namespace for base
> addresses. Don't you like it only because it's new?

I think because
readl(V7M_SCB_BASEADDRESS + V7M_SCB_CPUID)

reads more cleanly than

readl(BASEADDRESS_V7M_SCB + V7M_SCB_CPUID)

But it isn't a big enough issue to delay merging these - more a 
preference/style issue. As you ask: does anyone else have any thoughts?

Jonny
> Do others have
> thoughts here?
>
>> With that said, please feel free to add for the series:
>>
>> Reviewed-by: Jonathan Austin <jonathan.austin at arm.com>
>> Tested-by: Jonathan Austin <jonathan.austin at arm.com
> Thanks
> Uwe
>




From linux at arm.linux.org.uk  Thu Apr 18 10:13:59 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Thu, 18 Apr 2013 15:13:59 +0100
Subject: [PATCH 1/9] ARM: cpuidle: remove useless declaration
In-Reply-To: <515C1F3B.5040008@linaro.org>
References: <1364991322-20585-1-git-send-email-daniel.lezcano@linaro.org>
 <515C1F3B.5040008@linaro.org>
Message-ID: <20130418141359.GT14496@n2100.arm.linux.org.uk>

On Wed, Apr 03, 2013 at 02:23:23PM +0200, Daniel Lezcano wrote:
> On 04/03/2013 02:15 PM, Daniel Lezcano wrote:
> > The noop functions code is not necessary because the header file is
> > included in files which are compiled when CONFIG_CPU_IDLE is on.
> >
> > Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
> 
> I have been involved in the development of this file. I know Rob is no
> longer working on this neither monitoring the code.
> 
> Russell are you ok with this patch ? Rafael needs your ack to take this
> patch into its tree.

I don't know - the description doesn't make it clear.  Surely, what you
checked was that this file is _not_ included in any file which is built
when CONFIG_CPU_IDLE is disabled.  In other words, when CONFIG_CPU_IDLE
is not defined, arm_cpuidle_simple_enter() is never referenced.

If that is the case, then it's just that the patch description is the
opposite of what it should be for this patch - and then the patch and
description match and I don't see any reason to say no to it.

Then comes the issue of who takes the patch.  It looks like Rafael
would like me to.  I'm fine with that, but it will need to go into the
patch system as I'm rather busy catching up with email, and I expect
to be catching up for at least the rest of this month.


From arnd at arndb.de  Thu Apr 18 10:15:20 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 18 Apr 2013 16:15:20 +0200
Subject: [PATCH 18/19] ARM: at91: suspend both memory controllers on
 at91sam9263
In-Reply-To: <516FF8FC.7070901@atmel.com>
References: <1359123276-15833-1-git-send-email-arnd@arndb.de>
 <1359153858-31992-19-git-send-email-arnd@arndb.de>
 <516FF8FC.7070901@atmel.com>
Message-ID: <201304181615.20542.arnd@arndb.de>

On Thursday 18 April 2013, Nicolas Ferre wrote:

> > This patch blindly removes the warning and changes the
> > at91sam9263 to use the same code at at91sam9g45, which
> > may or may not be the right solution. If it is not,
> > maybe someone could provide a better fix.
> 
> Maybe you can remove this paragraph: now you are using the proper fix
> with proper RAM type.
> 
> > Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> > Cc: Nicolas Ferre <nicolas.ferre at atmel.com>
> 
> Acked-by: Nicolas Ferre <nicolas.ferre at atmel.com>
> 
> What is the future of this patch series: do you want us to take this
> patch separately or to you want to apply the whole series on the arm-soc
> tree?

I'd prefer if you could just apply or forward it to an appropriate tree.

Most of the other patches have found their way into mainline by now.

> > Cc: Jean-Christophe Plagniol-Villard <plagnioj at jcrosoft.com>
> > Cc: Andrew Victor <linux at maxim.org.za>
> > Cc: Albin Tonnerre <albin.tonnerre at free-electrons.com>
> > Cc: Daniel Lezcano <daniel.lezcano at linaro.org>
> 
> Moreover, this patch my conflict with Daniel's current initiative to
> move cpuidle driver to its own directory: how do we coordinate with each
> other?

Maybe you can make sure it actually works and send it to Daniel to apply on
top of his other patches?

	Arnd


From lee.jones at linaro.org  Thu Apr 18 10:17:52 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Thu, 18 Apr 2013 15:17:52 +0100
Subject: [PATCH 24/32 v3] dmaengine: ste_dma40: Supply full Device Tree
 parsing support
In-Reply-To: <20130418121253.GF27903@gmail.com>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-25-git-send-email-lee.jones@linaro.org>
 <20130418121253.GF27903@gmail.com>
Message-ID: <20130418141752.GC3959@gmail.com>

Using the new DMA DT bindings and API, we can register the DMA40 driver
as Device Tree capable. Now, when a client attempts to allocate a
channel using the DMA DT bindings via its own node, we are able to parse
the request and allocate a channel in the correct manner.

Cc: Vinod Koul <vinod.koul at intel.com>
Cc: Dan Williams <djbw at fb.com>
Cc: Per Forlin <per.forlin at stericsson.com>
Cc: Rabin Vincent <rabin at rab.in>
Signed-off-by: Lee Jones <lee.jones at linaro.org>

diff --git a/Documentation/devicetree/bindings/dma/ste-dma40.txt b/Documentation/devicetree/bindings/dma/ste-dma40.txt
new file mode 100644
index 0000000..2679a87
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/ste-dma40.txt
@@ -0,0 +1,62 @@
+* DMA40 DMA Controller
+
+Required properties:
+- compatible: "stericsson,dma40"
+- reg: Address range of the DMAC registers
+- reg-names: Names of the above areas to use during resource look-up
+- interrupt: Should contain the DMAC interrupt number
+- #dma-cells: must be <3>
+
+Optional properties:
+- dma-channels: Number of channels supported by hardware - if not present
+		the driver will attempt to obtain the information from H/W
+
+Example:
+
+	dma: dma-controller at 801C0000 {
+		compatible = "stericsson,db8500-dma40", "stericsson,dma40";
+		reg = <0x801C0000 0x1000  0x40010000 0x800>;
+		reg-names = "base", "lcpa";
+		interrupt-parent = <&intc>;
+		interrupts = <0 25 0x4>;
+
+		#dma-cells = <2>;
+		dma-channels = <8>;
+	};
+
+Clients
+Required properties:
+- dmas: Comma separated list of dma channel requests
+- dma-names: Names of the aforementioned requested channels
+
+Each dmas request consists of 4 cells:
+  1. A phandle pointing to the DMA controller
+  2. Device Type
+  3. The DMA request line number (only when 'use fixed channel' is set)
+  4. A 32bit mask specifying; mode, direction and endianess [NB: This list will grow]
+        0x00000001: Mode:
+                Logical channel when unset
+                Physical channel when set
+        0x00000002: Direction:
+                Memory to Device when unset
+                Device to Memory when set
+        0x00000004: Endianess:
+                Little endian when unset
+                Big endian when set
+        0x00000008: Use fixed channel:
+                Use automatic channel selection when unset
+                Use DMA request line number when set
+
+Example:
+
+	uart at 80120000 {
+		compatible = "arm,pl011", "arm,primecell";
+		reg = <0x80120000 0x1000>;
+		interrupts = <0 11 0x4>;
+
+		dmas = <&dma 13 0 0x2>, /* Logical - DevToMem */
+		       <&dma 13 0 0x0>; /* Logical - MemToDev */
+		dma-names = "rx", "rx";
+
+		status = "disabled";
+	};
diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index bad8753..94d0edb 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -18,6 +18,7 @@
 #include <linux/pm_runtime.h>
 #include <linux/err.h>
 #include <linux/of.h>
+#include <linux/of_dma.h>
 #include <linux/amba/bus.h>
 #include <linux/regulator/consumer.h>
 #include <linux/platform_data/dma-ste-dma40.h>
@@ -2409,6 +2410,50 @@ static void d40_set_prio_realtime(struct d40_chan *d40c)
 		__d40_set_prio_rt(d40c, d40c->dma_cfg.dev_type, false);
 }
 
+#define D40_DT_FLAGS_MODE(flags)       ((flags >> 0) & 0x1)
+#define D40_DT_FLAGS_DIR(flags)        ((flags >> 1) & 0x1)
+#define D40_DT_FLAGS_BIG_ENDIAN(flags) ((flags >> 2) & 0x1)
+#define D40_DT_FLAGS_FIXED_CHAN(flags) ((flags >> 3) & 0x1)
+
+static struct dma_chan *d40_xlate(struct of_phandle_args *dma_spec,
+				  struct of_dma *ofdma)
+{
+	struct stedma40_chan_cfg cfg;
+	dma_cap_mask_t cap;
+	u32 flags;
+
+	memset(&cfg, 0, sizeof(struct stedma40_chan_cfg));
+
+	dma_cap_zero(cap);
+	dma_cap_set(DMA_SLAVE, cap);
+
+	cfg.dev_type = dma_spec->args[0];
+	flags = dma_spec->args[2];
+
+	switch (D40_DT_FLAGS_MODE(flags)) {
+	case 0: cfg.mode = STEDMA40_MODE_LOGICAL; break;
+	case 1: cfg.mode = STEDMA40_MODE_PHYSICAL; break;
+	}
+
+	switch (D40_DT_FLAGS_DIR(flags)) {
+	case 0:
+		cfg.dir = STEDMA40_MEM_TO_PERIPH;
+		cfg.dst_info.big_endian = D40_DT_FLAGS_BIG_ENDIAN(flags);
+		break;
+	case 1:
+		cfg.dir = STEDMA40_PERIPH_TO_MEM;
+		cfg.src_info.big_endian = D40_DT_FLAGS_BIG_ENDIAN(flags);
+		break;
+	}
+
+	if (D40_DT_FLAGS_FIXED_CHAN(flags)) {
+		cfg.phy_channel = dma_spec->args[1];
+		cfg.use_fixed_channel = true;
+	}
+
+	return dma_request_channel(cap, stedma40_filter, &cfg);
+}
+
 /* DMA ENGINE functions */
 static int d40_alloc_chan_resources(struct dma_chan *chan)
 {
@@ -3615,6 +3660,13 @@ static int __init d40_probe(struct platform_device *pdev)
 
 	d40_hw_init(base);
 
+	if (np) {
+		err = of_dma_controller_register(np, d40_xlate, NULL);
+		if (err && err != -ENODEV)
+			dev_err(&pdev->dev,
+				"could not register of_dma_controller\n");
+	}
+
 	dev_info(base->dev, "initialized\n");
 	return 0;


From linux at arm.linux.org.uk  Thu Apr 18 10:19:52 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Thu, 18 Apr 2013 15:19:52 +0100
Subject: [PATCH 1/3] ARM: also support TWD clock, instantiated from
 platform data
In-Reply-To: <1365005636-17526-2-git-send-email-g.liakhovetski@gmx.de>
References: <1365005636-17526-1-git-send-email-g.liakhovetski@gmx.de>
 <1365005636-17526-2-git-send-email-g.liakhovetski@gmx.de>
Message-ID: <20130418141952.GU14496@n2100.arm.linux.org.uk>

On Wed, Apr 03, 2013 at 06:13:54PM +0200, Guennadi Liakhovetski wrote:
> While gradually switching clock initialisation to DT some architectures
> can have TWD device in DT, but supplying clock initialised from platform
> data. This patch adds support for such configurations to ARM.

Why can't you fix the clock problem at the same time - or sort out the
clock problem first and then add a DT description for TWD?


From nicolas.ferre at atmel.com  Thu Apr 18 10:19:49 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Thu, 18 Apr 2013 16:19:49 +0200
Subject: [PATCH 18/19] ARM: at91: suspend both memory controllers on
 at91sam9263
In-Reply-To: <201304181615.20542.arnd@arndb.de>
References: <1359123276-15833-1-git-send-email-arnd@arndb.de>
 <1359153858-31992-19-git-send-email-arnd@arndb.de>
 <516FF8FC.7070901@atmel.com> <201304181615.20542.arnd@arndb.de>
Message-ID: <51700105.9080802@atmel.com>

On 04/18/2013 04:15 PM, Arnd Bergmann :
> On Thursday 18 April 2013, Nicolas Ferre wrote:
> 
>>> This patch blindly removes the warning and changes the
>>> at91sam9263 to use the same code at at91sam9g45, which
>>> may or may not be the right solution. If it is not,
>>> maybe someone could provide a better fix.
>>
>> Maybe you can remove this paragraph: now you are using the proper fix
>> with proper RAM type.
>>
>>> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
>>> Cc: Nicolas Ferre <nicolas.ferre at atmel.com>
>>
>> Acked-by: Nicolas Ferre <nicolas.ferre at atmel.com>
>>
>> What is the future of this patch series: do you want us to take this
>> patch separately or to you want to apply the whole series on the arm-soc
>> tree?
> 
> I'd prefer if you could just apply or forward it to an appropriate tree.
> 
> Most of the other patches have found their way into mainline by now.
> 
>>> Cc: Jean-Christophe Plagniol-Villard <plagnioj at jcrosoft.com>
>>> Cc: Andrew Victor <linux at maxim.org.za>
>>> Cc: Albin Tonnerre <albin.tonnerre at free-electrons.com>
>>> Cc: Daniel Lezcano <daniel.lezcano at linaro.org>
>>
>> Moreover, this patch my conflict with Daniel's current initiative to
>> move cpuidle driver to its own directory: how do we coordinate with each
>> other?
> 
> Maybe you can make sure it actually works and send it to Daniel to apply on
> top of his other patches?

Well, as Daniel's patches are still under construction, I stack this one
on the at91-3.10-soc branch and let Daniel rebase his work on top of a
3.10-rc1-ish tree...

Best regards,
-- 
Nicolas Ferre


From sergei.shtylyov at cogentembedded.com  Thu Apr 18 10:21:12 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Thu, 18 Apr 2013 18:21:12 +0400
Subject: [PATCH 4/4] ARM: shmobile: Marzen: enable VIN and ADV7180 in
 defconfig
In-Reply-To: <20130418133022.GD20929@verge.net.au>
References: <201304180206.39465.sergei.shtylyov@cogentembedded.com>
 <201304180217.28176.sergei.shtylyov@cogentembedded.com>
 <20130418133022.GD20929@verge.net.au>
Message-ID: <51700158.101@cogentembedded.com>

On 18-04-2013 17:30, Simon Horman wrote:

>> From: Vladimir Barinov <vladimir.barinov at cogentembedded.com>

>> Add the VIN and ADV7180 drivers to 'marzen_defconfig'.

>> Signed-off-by: Vladimir Barinov <vladimir.barinov at cogentembedded.com>
>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

>> ---
>>   arch/arm/configs/marzen_defconfig |    7 +++++++
>>   1 file changed, 7 insertions(+)

> Thanks, queued-up for v3.11 in the defconfig-marzen branch.

    That seems somewhat premature as CONFIG_VIDEO_RCAR_VIN is not defined yet 
(it's defined in the patch #1 of this series).

WBR, Sergei



From arnd at arndb.de  Thu Apr 18 10:20:42 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 18 Apr 2013 16:20:42 +0200
Subject: [PATCH 18/19] ARM: at91: suspend both memory controllers on
 at91sam9263
In-Reply-To: <51700105.9080802@atmel.com>
References: <1359123276-15833-1-git-send-email-arnd@arndb.de>
 <201304181615.20542.arnd@arndb.de> <51700105.9080802@atmel.com>
Message-ID: <201304181620.42940.arnd@arndb.de>

On Thursday 18 April 2013, Nicolas Ferre wrote:
> > Maybe you can make sure it actually works and send it to Daniel to apply on
> > top of his other patches?
> 
> Well, as Daniel's patches are still under construction, I stack this one
> on the at91-3.10-soc branch and let Daniel rebase his work on top of a
> 3.10-rc1-ish tree...

Ok, sounds fine too.

	Arnd


From gregory.clement at free-electrons.com  Thu Apr 18 10:23:39 2013
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Thu, 18 Apr 2013 16:23:39 +0200
Subject: [PATCH RFC] ARM: don't allow to register the early_console twice
In-Reply-To: <1366295019-30335-1-git-send-email-gregory.clement@free-electrons.com>
References: <1366295019-30335-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1366295019-30335-2-git-send-email-gregory.clement@free-electrons.com>

If on the kernel command line the parameter "earlyprintk" is written
twice, then setup_early_printk is called twice. This can happen for
example with the option CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND is
selected, and the "earlyprintk" is passed from the ATAG_CMDLINE and
from the dtb.

This lead to an infinite loop on the message "Booting Linux on
physical CPU 0" displayed from smp_setup_processor_id() in
arch/arm/kernel/setup.c. This behavior as been reproduced on ARMv7
architecture (Armada XP and Armada 370), and on a ARMv5 one
(AT91SAMG35 thanks to Richard Genoud), with and with CONFIG_SMP
selected.

This patch simply doesn't allow to call twice register_console() with
the early_console.

Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
---
 arch/arm/kernel/early_printk.c |    6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/arm/kernel/early_printk.c b/arch/arm/kernel/early_printk.c
index 85aa2b2..435577a 100644
--- a/arch/arm/kernel/early_printk.c
+++ b/arch/arm/kernel/early_printk.c
@@ -50,7 +50,11 @@ asmlinkage void early_printk(const char *fmt, ...)
 
 static int __init setup_early_printk(char *buf)
 {
-	register_console(&early_console);
+	static int done;
+	if (!done) {
+		register_console(&early_console);
+		done = 1;
+	}
 	return 0;
 }
 
-- 
1.7.9.5



From gregory.clement at free-electrons.com  Thu Apr 18 10:23:38 2013
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Thu, 18 Apr 2013 16:23:38 +0200
Subject: [PATCH RFC] Fix bug if earlyprintk is called twice
Message-ID: <1366295019-30335-1-git-send-email-gregory.clement@free-electrons.com>

Hello,

If on the kernel command line the parameter "earlyprintk" is written
twice, then setup_early_printk is called twice. This can happen for
example with the option CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND is
selected, and the "earlyprintk" is passed from the ATAG_CMDLINE and
from the dtb.

This lead to an infinite loop on the message "Booting Linux on
physical CPU 0" displayed from smp_setup_processor_id() in
arch/arm/kernel/setup.c. This behavior as been reproduced on ARMv7
architecture (Armada XP and Armada 370), and on a ARMv5 one
(AT91SAMG35 thanks to Richard Genoud), with and with CONFIG_SMP
selected.

After some investigation I found that the problem happened when the
early_console is register for the second time in file kernel/printk.c
on line 2310 when the function console_lock() is called, and in this
function I managed to have traces until the call to down(&console_sem)
one line 1922. Keep in mind that I had this information using printk
so maybe it was not the best way to debug the console!

I didn't had other platform that ARM one for testing this behavior, so
I don't know if this bug is specific to ARM. If you think it is
something specific to ARM then I propose the patch in the following
email.

Any feedback on this issue would be welcome

Thanks,

Gregory CLEMENT (1):
  ARM: don't allow to register the early_console twice

 arch/arm/kernel/early_printk.c |    6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

-- 
1.7.9.5



From andrew.murray at arm.com  Thu Apr 18 10:24:34 2013
From: andrew.murray at arm.com (Andrew Murray)
Date: Thu, 18 Apr 2013 15:24:34 +0100
Subject: [PATCH v7 2/3] of/pci: Provide support for parsing PCI DT
 ranges property
In-Reply-To: <20130418134401.84AEE3E1319@localhost>
References: <1366107508-12672-1-git-send-email-Andrew.Murray@arm.com>
 <1366107508-12672-3-git-send-email-Andrew.Murray@arm.com>
 <20130418134401.84AEE3E1319@localhost>
Message-ID: <20130418142434.GA18881@arm.com>

On Thu, Apr 18, 2013 at 02:44:01PM +0100, Grant Likely wrote:
> On Tue, 16 Apr 2013 11:18:27 +0100, Andrew Murray <Andrew.Murray at arm.com> wrote:
> > This patch factors out common implementation patterns to reduce overall kernel
> > code and provide a means for host bridge drivers to directly obtain struct
> > resources from the DT's ranges property without relying on architecture specific
> > DT handling. This will make it easier to write archiecture independent host bridge
> > drivers and mitigate against further duplication of DT parsing code.
> > 
> > This patch can be used in the following way:
> > 
> > 	struct of_pci_range_parser parser;
> > 	struct of_pci_range range;
> > 
> > 	if (of_pci_range_parser(&parser, np))
> > 		; //no ranges property
> > 
> > 	for_each_of_pci_range(&parser, &range) {
> > 
> > 		/*
> > 			directly access properties of the address range, e.g.:
> > 			range.pci_space, range.pci_addr, range.cpu_addr,
> > 			range.size, range.flags
> > 
> > 			alternatively obtain a struct resource, e.g.:
> > 			struct resource res;
> > 			of_pci_range_to_resource(&range, np, &res);
> > 		*/
> > 	}
> > 
> > Additionally the implementation takes care of adjacent ranges and merges them
> > into a single range (as was the case with powerpc and microblaze).
> > 
> > Signed-off-by: Andrew Murray <Andrew.Murray at arm.com>
> > Signed-off-by: Liviu Dudau <Liviu.Dudau at arm.com>
> > Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> > Reviewed-by: Rob Herring <rob.herring at calxeda.com>
> > Tested-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> > Tested-by: Linus Walleij <linus.walleij at linaro.org>
> 
> Acked-by: Grant Likely <grant.likely at secretlab.ca>
> 
> But comments below...
> 
> > ---
> >  drivers/of/address.c       |   67 ++++++++++++++++++++++++++
> >  drivers/of/of_pci.c        |  113 ++++++++++++++++----------------------------
> >  include/linux/of_address.h |   46 ++++++++++++++++++
> >  3 files changed, 154 insertions(+), 72 deletions(-)
> > 
> > diff --git a/drivers/of/address.c b/drivers/of/address.c
> > index 04da786..6eec70c 100644
> > --- a/drivers/of/address.c
> > +++ b/drivers/of/address.c
> > @@ -227,6 +227,73 @@ int of_pci_address_to_resource(struct device_node *dev, int bar,
> >  	return __of_address_to_resource(dev, addrp, size, flags, NULL, r);
> >  }
> >  EXPORT_SYMBOL_GPL(of_pci_address_to_resource);
> > +
> > +int of_pci_range_parser(struct of_pci_range_parser *parser,
> > +			struct device_node *node)
> > +{
> > +	const int na = 3, ns = 2;
> > +	int rlen;
> > +
> > +	parser->node = node;
> > +	parser->pna = of_n_addr_cells(node);
> > +	parser->np = parser->pna + na + ns;
> > +
> > +	parser->range = of_get_property(node, "ranges", &rlen);
> > +	if (parser->range == NULL)
> > +		return -ENOENT;
> > +
> > +	parser->end = parser->range + rlen / sizeof(__be32);
> > +
> > +	return 0;
> > +}
> > +EXPORT_SYMBOL_GPL(of_pci_range_parser);
> 
> "of_pci_range_parser_init" would be a clearer name
> 
> > +struct of_pci_range *of_pci_process_ranges(struct of_pci_range_parser *parser,
> > +						struct of_pci_range *range)
> 
> Similarly, "of_pci_range_parser_one" would be more consistent.
> 
> > +{
> > +	const int na = 3, ns = 2;
> > +
> > +	if (!range)
> > +		return NULL;
> > +
> > +	if (!parser->range || parser->range + parser->np > parser->end)
> > +		return NULL;
> > +
> > +	range->pci_space = parser->range[0];
> > +	range->flags = of_bus_pci_get_flags(parser->range);
> > +	range->pci_addr = of_read_number(parser->range + 1, ns);
> > +	range->cpu_addr = of_translate_address(parser->node,
> > +				parser->range + na);
> > +	range->size = of_read_number(parser->range + parser->pna + na, ns);
> > +
> > +	parser->range += parser->np;
> > +
> > +	/* Now consume following elements while they are contiguous */
> > +	while (parser->range + parser->np <= parser->end) {
> > +		u32 flags, pci_space;
> > +		u64 pci_addr, cpu_addr, size;
> > +
> > +		pci_space = be32_to_cpup(parser->range);
> > +		flags = of_bus_pci_get_flags(parser->range);
> > +		pci_addr = of_read_number(parser->range + 1, ns);
> > +		cpu_addr = of_translate_address(parser->node,
> > +				parser->range + na);
> > +		size = of_read_number(parser->range + parser->pna + na, ns);
> > +
> > +		if (flags != range->flags)
> > +			break;
> > +		if (pci_addr != range->pci_addr + range->size ||
> > +		    cpu_addr != range->cpu_addr + range->size)
> > +			break;
> > +
> > +		range->size += size;
> > +		parser->range += parser->np;
> > +	}
> > +
> > +	return range;
> > +}
> > +EXPORT_SYMBOL_GPL(of_pci_process_ranges);
> > +
> >  #endif /* CONFIG_PCI */
> >  
> >  /*
> > diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
> > index 1626172..e5ab604 100644
> > --- a/drivers/of/of_pci.c
> > +++ b/drivers/of/of_pci.c
> > @@ -2,6 +2,7 @@
> >  #include <linux/export.h>
> >  #include <linux/of.h>
> >  #include <linux/of_pci.h>
> > +#include <linux/of_address.h>
> >  #include <asm/prom.h>
> >  
> >  #if defined(CONFIG_PPC32) || defined(CONFIG_PPC64) || defined(CONFIG_MICROBLAZE)
> > @@ -82,67 +83,43 @@ EXPORT_SYMBOL_GPL(of_pci_find_child_device);
> >  void pci_process_bridge_OF_ranges(struct pci_controller *hose,
> >  				  struct device_node *dev, int primary)
> >  {
> > -	const u32 *ranges;
> > -	int rlen;
> > -	int pna = of_n_addr_cells(dev);
> > -	int np = pna + 5;
> >  	int memno = 0, isa_hole = -1;
> > -	u32 pci_space;
> > -	unsigned long long pci_addr, cpu_addr, pci_next, cpu_next, size;
> >  	unsigned long long isa_mb = 0;
> >  	struct resource *res;
> > +	struct of_pci_range range;
> > +	struct of_pci_range_parser parser;
> > +	u32 res_type;
> >  
> >  	pr_info("PCI host bridge %s %s ranges:\n",
> >  	       dev->full_name, primary ? "(primary)" : "");
> >  
> > -	/* Get ranges property */
> > -	ranges = of_get_property(dev, "ranges", &rlen);
> > -	if (ranges == NULL)
> > +	/* Check for ranges property */
> > +	if (of_pci_range_parser(&parser, dev))
> >  		return;
> >  
> > -	/* Parse it */
> >  	pr_debug("Parsing ranges property...\n");
> > -	while ((rlen -= np * 4) >= 0) {
> > +	for_each_of_pci_range(&parser, &range) {
> >  		/* Read next ranges element */
> > -		pci_space = ranges[0];
> > -		pci_addr = of_read_number(ranges + 1, 2);
> > -		cpu_addr = of_translate_address(dev, ranges + 3);
> > -		size = of_read_number(ranges + pna + 3, 2);
> 
> Tip: the diff on this function would be a whole lot simpler if the
> above locals were kept, but updated from the ranges structure. Not at
> all a big problem, but it is something that makes changes like this
> easier to review. The removal of the locals could also be split into a
> separate patch to end up with the same result.
> 
> > -
> > -		pr_debug("pci_space: 0x%08x pci_addr:0x%016llx ",
> > -				pci_space, pci_addr);
> > -		pr_debug("cpu_addr:0x%016llx size:0x%016llx\n",
> > -					cpu_addr, size);
> > -
> > -		ranges += np;
> > +		pr_debug("pci_space: 0x%08x pci_addr: 0x%016llx ",
> > +				range.pci_space, range.pci_addr);
> > +		pr_debug("cpu_addr: 0x%016llx size: 0x%016llx\n",
> > +				range.cpu_addr, range.size);
> 
> Nit: the patch changed whitespace on the pr_debug() statements, so even
> though the first line of each is identical, they look different in the
> patch.
> 
> >  
> >  		/* If we failed translation or got a zero-sized region
> >  		 * (some FW try to feed us with non sensical zero sized regions
> >  		 * such as power3 which look like some kind of attempt
> >  		 * at exposing the VGA memory hole)
> >  		 */
> > -		if (cpu_addr == OF_BAD_ADDR || size == 0)
> > +		if (range.cpu_addr == OF_BAD_ADDR || range.size == 0)
> >  			continue;
> 
> Can this also be rolled into the parsing iterator?
> 

Yes I think that would make sense.

> >  
> > -		/* Now consume following elements while they are contiguous */
> > -		for (; rlen >= np * sizeof(u32);
> > -		     ranges += np, rlen -= np * 4) {
> > -			if (ranges[0] != pci_space)
> > -				break;
> > -			pci_next = of_read_number(ranges + 1, 2);
> > -			cpu_next = of_translate_address(dev, ranges + 3);
> > -			if (pci_next != pci_addr + size ||
> > -			    cpu_next != cpu_addr + size)
> > -				break;
> > -			size += of_read_number(ranges + pna + 3, 2);
> > -		}
> > -
> >  		/* Act based on address space type */
> >  		res = NULL;
> > -		switch ((pci_space >> 24) & 0x3) {
> > -		case 1:		/* PCI IO space */
> > +		res_type = range.flags & IORESOURCE_TYPE_BITS;
> > +		if (res_type == IORESOURCE_IO) {
> 
> Why the change from switch() to an if/else if sequence?

Russell King suggested this change - see 
https://patchwork.kernel.org/patch/2323941/

> 
> But those are mostly nitpicks. If this is deferred to v3.10 then I would
> suggest fixing them up and posting for another round of review.

Thanks for the feedback. I'll update the patch in the future.

Andrew Murray


From elezegarcia at gmail.com  Thu Apr 18 10:26:10 2013
From: elezegarcia at gmail.com (Ezequiel Garcia)
Date: Thu, 18 Apr 2013 11:26:10 -0300
Subject: AT91SAM9M10: Problem porting driver for MT9P031 sensor
In-Reply-To: <CD957E83.AF12%marcio@netopen.com.br>
References: <2001207140.384354.1366290836027.open-xchange@email.1und1.de>
 <CD957E83.AF12%marcio@netopen.com.br>
Message-ID: <CALF0-+UxFVOeMCEXaw3fUL2_NU=19+hXh3Ad8V9DVAUNtaSWtQ@mail.gmail.com>

Hi Marcio,

On Thu, Apr 18, 2013 at 9:47 AM, Marcio Campos de Lima
<marcio at netopen.com.br> wrote:
>
> I am porting the MT9P031 sensor device driver for a custom designed board
> based at the AT91SAM9M45-EK development board and Linux 3.6.9.
> The driver detects the sensor but does not create /dev/video1. I cannot
> even see /dev/video0 that usually is created by default.
>

You might get better luck if you push your code somewhere
so people can take a look at it.

Also, IMHO the arm mailing list is not the best place to ask
try asking the media ML: linux-media _at_ vger.kernel.org
and #v4l at freenode IRC.

Good luck!
-- 
    Ezequiel


From sergei.shtylyov at cogentembedded.com  Thu Apr 18 10:25:11 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Thu, 18 Apr 2013 18:25:11 +0400
Subject: [PATCH 3/4] ARM: shmobile: Marzen: add VIN and ADV7180 support
In-Reply-To: <201304180215.01218.sergei.shtylyov@cogentembedded.com>
References: <201304180206.39465.sergei.shtylyov@cogentembedded.com>
 <201304180215.01218.sergei.shtylyov@cogentembedded.com>
Message-ID: <51700247.2000905@cogentembedded.com>

On 18-04-2013 2:15, I wrote:

> From: Vladimir Barinov <vladimir.barinov at cogentembedded.com>

> Add ADV7180 platform devices on the Marzen board, configure VIN1/3 pins, and
> register VIN1/3 devices with the ADV7180 specific platform data.

> Signed-off-by: Vladimir Barinov <vladimir.barinov at cogentembedded.com>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

    I'm going to repost this patch recasted using a macro for camera sensor data.

WBR, Sergei



From andrew.murray at arm.com  Thu Apr 18 10:26:35 2013
From: andrew.murray at arm.com (Andrew Murray)
Date: Thu, 18 Apr 2013 15:26:35 +0100
Subject: [PATCH v7 3/3] of/pci: mips: convert to common of_pci_range_parser
In-Reply-To: <20130418134535.5189E3E1319@localhost>
References: <1366107508-12672-1-git-send-email-Andrew.Murray@arm.com>
 <1366107508-12672-4-git-send-email-Andrew.Murray@arm.com>
 <20130418134535.5189E3E1319@localhost>
Message-ID: <20130418142635.GB18881@arm.com>

On Thu, Apr 18, 2013 at 02:45:35PM +0100, Grant Likely wrote:
> On Tue, 16 Apr 2013 11:18:28 +0100, Andrew Murray <Andrew.Murray at arm.com> wrote:
> > This patch converts the pci_load_of_ranges function to use the new common
> > of_pci_range_parser.
> > 
> > Signed-off-by: Andrew Murray <Andrew.Murray at arm.com>
> > Signed-off-by: Liviu Dudau <Liviu.Dudau at arm.com>
> > Reviewed-by: Rob Herring <rob.herring at calxeda.com>
> 
> Looks okay to me, and thank you very much for doing the legwork to merge
> the common code.

No problem, though I think there is more than can be done in this area -
there is a lot of similar PCI code floating about.

> 
> Reviewed-by: Grant Likely <grant.likely at secretlab.ca>

Thanks for the review.

Andrew Murray


From daniel.lezcano at linaro.org  Thu Apr 18 10:31:43 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Thu, 18 Apr 2013 16:31:43 +0200
Subject: [PATCH 1/9] ARM: cpuidle: remove useless declaration
In-Reply-To: <20130418141359.GT14496@n2100.arm.linux.org.uk>
References: <1364991322-20585-1-git-send-email-daniel.lezcano@linaro.org>
 <515C1F3B.5040008@linaro.org> <20130418141359.GT14496@n2100.arm.linux.org.uk>
Message-ID: <517003CF.5090106@linaro.org>

On 04/18/2013 04:13 PM, Russell King - ARM Linux wrote:
> On Wed, Apr 03, 2013 at 02:23:23PM +0200, Daniel Lezcano wrote:
>> On 04/03/2013 02:15 PM, Daniel Lezcano wrote:
>>> The noop functions code is not necessary because the header file is
>>> included in files which are compiled when CONFIG_CPU_IDLE is on.
>>>
>>> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
>>
>> I have been involved in the development of this file. I know Rob is no
>> longer working on this neither monitoring the code.
>>
>> Russell are you ok with this patch ? Rafael needs your ack to take this
>> patch into its tree.
> 
> I don't know - the description doesn't make it clear.  Surely, what you
> checked was that this file is _not_ included in any file which is built
> when CONFIG_CPU_IDLE is disabled.  In other words, when CONFIG_CPU_IDLE
> is not defined, arm_cpuidle_simple_enter() is never referenced.
> 
> If that is the case, then it's just that the patch description is the
> opposite of what it should be for this patch - and then the patch and
> description match and I don't see any reason to say no to it.
> 
> Then comes the issue of who takes the patch.  It looks like Rafael
> would like me to.

Actually Rafael was willing to take the patch if you ack it.


-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From daniel.lezcano at linaro.org  Thu Apr 18 10:32:26 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Thu, 18 Apr 2013 16:32:26 +0200
Subject: [PATCH 18/19] ARM: at91: suspend both memory controllers on
 at91sam9263
In-Reply-To: <51700105.9080802@atmel.com>
References: <1359123276-15833-1-git-send-email-arnd@arndb.de>
 <1359153858-31992-19-git-send-email-arnd@arndb.de>
 <516FF8FC.7070901@atmel.com> <201304181615.20542.arnd@arndb.de>
 <51700105.9080802@atmel.com>
Message-ID: <517003FA.4000509@linaro.org>

On 04/18/2013 04:19 PM, Nicolas Ferre wrote:
> On 04/18/2013 04:15 PM, Arnd Bergmann :
>> On Thursday 18 April 2013, Nicolas Ferre wrote:
>>
>>>> This patch blindly removes the warning and changes the
>>>> at91sam9263 to use the same code at at91sam9g45, which
>>>> may or may not be the right solution. If it is not,
>>>> maybe someone could provide a better fix.
>>>
>>> Maybe you can remove this paragraph: now you are using the proper fix
>>> with proper RAM type.
>>>
>>>> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
>>>> Cc: Nicolas Ferre <nicolas.ferre at atmel.com>
>>>
>>> Acked-by: Nicolas Ferre <nicolas.ferre at atmel.com>
>>>
>>> What is the future of this patch series: do you want us to take this
>>> patch separately or to you want to apply the whole series on the arm-soc
>>> tree?
>>
>> I'd prefer if you could just apply or forward it to an appropriate tree.
>>
>> Most of the other patches have found their way into mainline by now.
>>
>>>> Cc: Jean-Christophe Plagniol-Villard <plagnioj at jcrosoft.com>
>>>> Cc: Andrew Victor <linux at maxim.org.za>
>>>> Cc: Albin Tonnerre <albin.tonnerre at free-electrons.com>
>>>> Cc: Daniel Lezcano <daniel.lezcano at linaro.org>
>>>
>>> Moreover, this patch my conflict with Daniel's current initiative to
>>> move cpuidle driver to its own directory: how do we coordinate with each
>>> other?
>>
>> Maybe you can make sure it actually works and send it to Daniel to apply on
>> top of his other patches?
> 
> Well, as Daniel's patches are still under construction, I stack this one
> on the at91-3.10-soc branch and let Daniel rebase his work on top of a
> 3.10-rc1-ish tree...

No problem.

Thanks
  -- Daniel


-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From shawn.guo at linaro.org  Thu Apr 18 10:44:29 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Thu, 18 Apr 2013 22:44:29 +0800
Subject: [PATCH RESEND v5 0/2] dma: imx-dma: OFTree support
In-Reply-To: <1366291298-30004-1-git-send-email-mpa@pengutronix.de>
References: <1366291298-30004-1-git-send-email-mpa@pengutronix.de>
Message-ID: <20130418144428.GB2222@S2101-09.ap.freescale.net>

On Thu, Apr 18, 2013 at 03:21:36PM +0200, Markus Pargmann wrote:
> Markus Pargmann (2):
>       dma: imx-dma: Add oftree support
>       DMA: imx-dma: imxdma->dev used uninitialized

Both,

Reviewed-by: Shawn Guo <shawn.guo at linaro.org>



From lars at metafoo.de  Thu Apr 18 10:43:43 2013
From: lars at metafoo.de (Lars-Peter Clausen)
Date: Thu, 18 Apr 2013 16:43:43 +0200
Subject: [alsa-devel] [PATCH v4 02/10] ASoC: imx-pcm-dma: DT support
In-Reply-To: <1366288424-7660-3-git-send-email-mpa@pengutronix.de>
References: <1366288424-7660-1-git-send-email-mpa@pengutronix.de>
 <1366288424-7660-3-git-send-email-mpa@pengutronix.de>
Message-ID: <5170069F.4030200@metafoo.de>

On 04/18/2013 02:33 PM, Markus Pargmann wrote:
> This patch adds the possibility to pass a of_node as platform_data which
> is used by generic-pcm-dma to request a DMA slave channel.
> 
> Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
> ---
>  sound/soc/fsl/imx-pcm-dma.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/sound/soc/fsl/imx-pcm-dma.c b/sound/soc/fsl/imx-pcm-dma.c
> index c246fb5..8945d22 100644
> --- a/sound/soc/fsl/imx-pcm-dma.c
> +++ b/sound/soc/fsl/imx-pcm-dma.c
> @@ -62,9 +62,11 @@ static const struct snd_dmaengine_pcm_config imx_dmaengine_pcm_config = {
>  
>  int imx_pcm_dma_init(struct platform_device *pdev)
>  {
> +	if (pdev->dev.platform_data)
> +		pdev->dev.of_node = pdev->dev.platform_data;

In my opinion it's better to use pdev->dev.parent->of_node here. In the ssi
driver you use platform_device_register_data, which will create a copy of
the of_node you pass in as platform data. I'm not quite sure how well this
will work. If you want to continue to use platform_data you should at least
change the code in the ssi driver to not make a copy of the of_node.

- Lars

> +
>  	return snd_dmaengine_pcm_register(&pdev->dev, &imx_dmaengine_pcm_config,
>  		SND_DMAENGINE_PCM_FLAG_NO_RESIDUE |
> -		SND_DMAENGINE_PCM_FLAG_NO_DT |
>  		SND_DMAENGINE_PCM_FLAG_COMPAT);
>  }
>  



From shawn.guo at linaro.org  Thu Apr 18 10:47:38 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Thu, 18 Apr 2013 22:47:38 +0800
Subject: MXS framebuffer driver and 18bits display
In-Reply-To: <516EBCA4.1020609@free-electrons.com>
References: <516EBCA4.1020609@free-electrons.com>
Message-ID: <20130418144736.GC2222@S2101-09.ap.freescale.net>

Copy Sascha who is the author of the driver to see he has any comment on
that.

Shawn

On Wed, Apr 17, 2013 at 05:15:48PM +0200, Maxime Ripard wrote:
> Hi,
> 
> We noticed a strange bug with the 18 bits display found in the
> iMX28 CFA-10049, but it should not be specific to it.
> 
> Like I said, we have a small 18-bits LCD panel. When further testing
> it, it displayed horrible colors with standard jpg images used together
> with tools such as fbv, applications written in Qt, etc.
> 
> Digging a bit into it, it looks like the mxsfb driver accepts devices
> with 18bits interfaces.
> 
> However, in such case, the driver registers as a 32bits framebuffer
> device, sets up the controller as a 24 bits display, and is actually
> asking the controller to drop the 2 upper bits of each color by setting
> the DATA_FORMAT_24_BIT bit in the HW_LCDIF_CTRL register.
> 
> So basically, applications feed to the framebuffer something like:
> 
> +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
> | R7| R6| R5| R4| R3| R2| R1| R0| G7| G6| G5| G4| G3| G2| G1| G0| B7| B6| B5| B4| B3| B2| B1| B0|
> +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
> 
> And what is being sent to the LCD is:
> 
> +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
> | R5| R4| R3| R2| R1| R0| G5| G4| G3| G2| G1| G0| B5| B4| B3| B2| B1| B0|
> +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
> 
> And thus, results in colors being horrible because the MSB are dropped.
> 
> What I believe the controller should send in theory should be :
> 
> +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
> | R7| R6| R5| R4| R3| R2| G7| G6| G5| G4| G3| G2| B7| B6| B5| B4| B3| B2|
> +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
> 
> Thus dropping the 2 LSB for each color. However, it doesn't seem that
> the controller can be setup that way.
> 
> We thought of several solutions for this:
>   - Switching to "real" 18 bits color depth
>     * It is definitely not a good solution, since it requires the
>       applications to handle the 18 bits color depth case, which only a
>       few of them do.
>   - Using the SHIFT_NUM_BITS bits in the HW_LCDIF_CTRL register
>     * It doesn't look like a good solution either, since it seems to be
>       shifting the whole 24 bits, and not each color independently, so
>       the result will only be worse.
>   - Use a 16 bits color depth
>     * It doesn't seem possible either, since the 16 bits will be packed
>       on two bytes, while the controller expects the 18 bits not to be
>       packed.
> 
> Do you see a solution for this?
> 
> Thanks,
> Maxime
> 
> -- 
> Maxime Ripard, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com



From shawn.guo at linaro.org  Thu Apr 18 10:48:39 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Thu, 18 Apr 2013 22:48:39 +0800
Subject: [PATCH] video: mxsfb: Fix colors display on lower color depth
In-Reply-To: <1366277032-671-1-git-send-email-maxime.ripard@free-electrons.com>
References: <516EBCA4.1020609@free-electrons.com>
 <1366277032-671-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <20130418144838.GD2222@S2101-09.ap.freescale.net>

Copy Sascha.

Shawn

On Thu, Apr 18, 2013 at 11:23:52AM +0200, Maxime Ripard wrote:
> The current code always registers as a 32 bits display, and uses the
> hardware to drop the MSB of each color to abjust to the interface width
> used by the panel.
> 
> This results on 18 bits (and probably 16 bits display as well) in colors
> being displayed poorly, because the MSB are obviously the most important
> bits for each color definition.
> 
> The default controller behaviour when using an interface width smaller
> than the color depth is to drop the LSBs of each color, which makes more
> sense because you lose the least important part of the color definition.
> 
> So, to fix the colors display, just get back to the default controller
> behaviour.
> 
> Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
> ---
>  drivers/video/mxsfb.c |    5 -----
>  1 file changed, 5 deletions(-)
> 
> diff --git a/drivers/video/mxsfb.c b/drivers/video/mxsfb.c
> index 755556c..2cfaf8b 100644
> --- a/drivers/video/mxsfb.c
> +++ b/drivers/video/mxsfb.c
> @@ -424,11 +424,6 @@ static int mxsfb_set_par(struct fb_info *fb_info)
>  			return -EINVAL;
>  		case STMLCDIF_16BIT:
>  		case STMLCDIF_18BIT:
> -			/* 24 bit to 18 bit mapping */
> -			ctrl |= CTRL_DF24; /* ignore the upper 2 bits in
> -					    *  each colour component
> -					    */
> -			break;
>  		case STMLCDIF_24BIT:
>  			/* real 24 bit */
>  			break;
> -- 
> 1.7.10.4
> 



From stefano.stabellini at eu.citrix.com  Thu Apr 18 10:49:01 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Thu, 18 Apr 2013 15:49:01 +0100
Subject: [PATCH v3 0/5] xen/arm: move to mach-virt and support SMP
Message-ID: <alpine.DEB.2.02.1304181538160.7254@kaball.uk.xensource.com>

Hi all,
this patch series, based on 3.9-rc3, moves xenvm to mach-virt and
implements SMP support in Xen on ARM.


Changes from v2:
- dropped the RFC patch from the series: PSCI related changes are going
to be handled by a separate series.

Changes from v1:
- move the percpu variable argument fix in xen_init_events to a separate
  patch;
- remove unused variable in xen_init_events;
- add an RFC patch to initialize PSCI from smp_set_ops and use it if
  available.


Stefano Stabellini (5):
      xen/arm: actually pass a non-NULL percpu pointer to request_percpu_irq
      xen/arm: SMP support
      xen: move the xenvm machine to mach-virt
      xen/arm: implement HYPERVISOR_vcpu_op
      xenvm: add a simple PSCI node and a second cpu

 arch/arm/boot/dts/xenvm-4.2.dts      |   12 ++++++++++
 arch/arm/include/asm/xen/hypercall.h |    1 +
 arch/arm/mach-vexpress/v2m.c         |    1 -
 arch/arm/mach-virt/virt.c            |    1 +
 arch/arm/xen/enlighten.c             |   41 ++++++++++++++++++++++++++++++++-
 arch/arm/xen/hypercall.S             |    1 +
 6 files changed, 54 insertions(+), 3 deletions(-)


git://git.kernel.org/pub/scm/linux/kernel/git/sstabellini/xen.git 3.9-rc3-smp-3-tag

Cheers,

Stefano


From stefano.stabellini at eu.citrix.com  Thu Apr 18 10:50:42 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Thu, 18 Apr 2013 15:50:42 +0100
Subject: [PATCH v3 1/5] xen/arm: actually pass a non-NULL percpu pointer to
 request_percpu_irq
In-Reply-To: <alpine.DEB.2.02.1304181538160.7254@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1304181538160.7254@kaball.uk.xensource.com>
Message-ID: <1366296646-12215-1-git-send-email-stefano.stabellini@eu.citrix.com>

Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
---
 arch/arm/xen/enlighten.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 8dc0605..99ce189 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -239,7 +239,7 @@ static int __init xen_init_events(void)
 	xen_init_IRQ();
 
 	if (request_percpu_irq(xen_events_irq, xen_arm_callback,
-			"events", xen_vcpu)) {
+			"events", &xen_vcpu)) {
 		pr_err("Error requesting IRQ %d\n", xen_events_irq);
 		return -EINVAL;
 	}
-- 
1.7.2.5



From stefano.stabellini at eu.citrix.com  Thu Apr 18 10:50:44 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Thu, 18 Apr 2013 15:50:44 +0100
Subject: [PATCH v3 3/5] xen: move the xenvm machine to mach-virt
In-Reply-To: <alpine.DEB.2.02.1304181538160.7254@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1304181538160.7254@kaball.uk.xensource.com>
Message-ID: <1366296646-12215-3-git-send-email-stefano.stabellini@eu.citrix.com>

xenvm is based on mach-vexpress, move it to mach-virt.

Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
Acked-by: Marc Zyngier <marc.zyngier at arm.com>
CC: will.deacon at arm.com
CC: arnd at arndb.de
CC: rob.herring at calxeda.com
---
 arch/arm/mach-vexpress/v2m.c |    1 -
 arch/arm/mach-virt/virt.c    |    1 +
 2 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-vexpress/v2m.c b/arch/arm/mach-vexpress/v2m.c
index 915683c..c43ec78 100644
--- a/arch/arm/mach-vexpress/v2m.c
+++ b/arch/arm/mach-vexpress/v2m.c
@@ -469,7 +469,6 @@ static void __init v2m_dt_init(void)
 
 static const char * const v2m_dt_match[] __initconst = {
 	"arm,vexpress",
-	"xen,xenvm",
 	NULL,
 };
 
diff --git a/arch/arm/mach-virt/virt.c b/arch/arm/mach-virt/virt.c
index 31666f6..528c05e 100644
--- a/arch/arm/mach-virt/virt.c
+++ b/arch/arm/mach-virt/virt.c
@@ -40,6 +40,7 @@ static void __init virt_timer_init(void)
 
 static const char *virt_dt_match[] = {
 	"linux,dummy-virt",
+	"xen,xenvm",
 	NULL
 };
 
-- 
1.7.2.5



From stefano.stabellini at eu.citrix.com  Thu Apr 18 10:50:45 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Thu, 18 Apr 2013 15:50:45 +0100
Subject: [PATCH v3 4/5] xen/arm: implement HYPERVISOR_vcpu_op
In-Reply-To: <alpine.DEB.2.02.1304181538160.7254@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1304181538160.7254@kaball.uk.xensource.com>
Message-ID: <1366296646-12215-4-git-send-email-stefano.stabellini@eu.citrix.com>

Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
---
 arch/arm/include/asm/xen/hypercall.h |    1 +
 arch/arm/xen/enlighten.c             |    1 +
 arch/arm/xen/hypercall.S             |    1 +
 3 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/arm/include/asm/xen/hypercall.h b/arch/arm/include/asm/xen/hypercall.h
index 8a82325..799f42e 100644
--- a/arch/arm/include/asm/xen/hypercall.h
+++ b/arch/arm/include/asm/xen/hypercall.h
@@ -46,6 +46,7 @@ int HYPERVISOR_event_channel_op(int cmd, void *arg);
 unsigned long HYPERVISOR_hvm_op(int op, void *arg);
 int HYPERVISOR_memory_op(unsigned int cmd, void *arg);
 int HYPERVISOR_physdev_op(int cmd, void *arg);
+int HYPERVISOR_vcpu_op(int cmd, int vcpuid, void *extra_args);
 
 static inline void
 MULTI_update_va_mapping(struct multicall_entry *mcl, unsigned long va,
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 94bbf3b..b002822 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -295,4 +295,5 @@ EXPORT_SYMBOL_GPL(HYPERVISOR_sched_op);
 EXPORT_SYMBOL_GPL(HYPERVISOR_hvm_op);
 EXPORT_SYMBOL_GPL(HYPERVISOR_memory_op);
 EXPORT_SYMBOL_GPL(HYPERVISOR_physdev_op);
+EXPORT_SYMBOL_GPL(HYPERVISOR_vcpu_op);
 EXPORT_SYMBOL_GPL(privcmd_call);
diff --git a/arch/arm/xen/hypercall.S b/arch/arm/xen/hypercall.S
index 71f7239..199cb2d 100644
--- a/arch/arm/xen/hypercall.S
+++ b/arch/arm/xen/hypercall.S
@@ -87,6 +87,7 @@ HYPERCALL2(event_channel_op);
 HYPERCALL2(hvm_op);
 HYPERCALL2(memory_op);
 HYPERCALL2(physdev_op);
+HYPERCALL3(vcpu_op);
 
 ENTRY(privcmd_call)
 	stmdb sp!, {r4}
-- 
1.7.2.5



From stefano.stabellini at eu.citrix.com  Thu Apr 18 10:50:46 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Thu, 18 Apr 2013 15:50:46 +0100
Subject: [PATCH v3 5/5] xenvm: add a simple PSCI node and a second cpu
In-Reply-To: <alpine.DEB.2.02.1304181538160.7254@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1304181538160.7254@kaball.uk.xensource.com>
Message-ID: <1366296646-12215-5-git-send-email-stefano.stabellini@eu.citrix.com>

Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
Acked-by: Marc Zyngier <marc.zyngier at arm.com>
CC: rob.herring at calxeda.com
CC: will.deacon at arm.com
CC: arnd at arndb.de
---
 arch/arm/boot/dts/xenvm-4.2.dts |   12 ++++++++++++
 1 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/xenvm-4.2.dts b/arch/arm/boot/dts/xenvm-4.2.dts
index ec3f952..9441156 100644
--- a/arch/arm/boot/dts/xenvm-4.2.dts
+++ b/arch/arm/boot/dts/xenvm-4.2.dts
@@ -29,6 +29,18 @@
 			compatible = "arm,cortex-a15";
 			reg = <0>;
 		};
+
+		cpu at 1 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a15";
+			reg = <1>;
+		};
+	};
+
+	psci {
+		compatible      = "arm,psci";
+		method          = "hvc";
+		cpu_on          = <2>;
 	};
 
 	memory at 80000000 {
-- 
1.7.2.5



From stefano.stabellini at eu.citrix.com  Thu Apr 18 10:50:43 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Thu, 18 Apr 2013 15:50:43 +0100
Subject: [PATCH v3 2/5] xen/arm: SMP support
In-Reply-To: <alpine.DEB.2.02.1304181538160.7254@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1304181538160.7254@kaball.uk.xensource.com>
Message-ID: <1366296646-12215-2-git-send-email-stefano.stabellini@eu.citrix.com>

Map vcpu_info using VCPUOP_register_vcpu_info on secondary cpus.

Call enable_percpu_irq on every cpu.

Changed in v2:
- move the percpu variable argument fix to a separate patch;
- remove unused variable.

Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
---
 arch/arm/xen/enlighten.c |   38 +++++++++++++++++++++++++++++++++++++-
 1 files changed, 37 insertions(+), 1 deletions(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 99ce189..94bbf3b 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -2,6 +2,7 @@
 #include <xen/events.h>
 #include <xen/grant_table.h>
 #include <xen/hvm.h>
+#include <xen/interface/vcpu.h>
 #include <xen/interface/xen.h>
 #include <xen/interface/memory.h>
 #include <xen/interface/hvm/params.h>
@@ -32,6 +33,7 @@ struct shared_info xen_dummy_shared_info;
 struct shared_info *HYPERVISOR_shared_info = (void *)&xen_dummy_shared_info;
 
 DEFINE_PER_CPU(struct vcpu_info *, xen_vcpu);
+DEFINE_PER_CPU(struct vcpu_info, xen_vcpu_info);
 
 /* These are unused until we support booting "pre-ballooned" */
 unsigned long xen_released_pages;
@@ -148,6 +150,32 @@ int xen_unmap_domain_mfn_range(struct vm_area_struct *vma,
 }
 EXPORT_SYMBOL_GPL(xen_unmap_domain_mfn_range);
 
+static int __init xen_secondary_init(unsigned int cpu)
+{
+	struct vcpu_register_vcpu_info info;
+	struct vcpu_info *vcpup;
+	int err;
+
+	if (cpu == 0)
+		return 0;
+
+	pr_info("Xen: initializing cpu%d\n", cpu);
+	vcpup = &per_cpu(xen_vcpu_info, cpu);
+
+	info.mfn = __pa(vcpup) >> PAGE_SHIFT;
+	info.offset = offset_in_page(vcpup);
+
+	err = HYPERVISOR_vcpu_op(VCPUOP_register_vcpu_info, cpu, &info);
+	if (err) {
+		pr_debug("register_vcpu_info failed: err=%d\n", err);
+	} else {
+		/* This cpu is using the registered vcpu info, even if
+		   later ones fail to. */
+		per_cpu(xen_vcpu, cpu) = vcpup;
+	}
+	return 0;
+}
+
 /*
  * see Documentation/devicetree/bindings/arm/xen.txt for the
  * documentation of the Xen Device Tree format.
@@ -163,6 +191,7 @@ static int __init xen_guest_init(void)
 	const char *version = NULL;
 	const char *xen_prefix = "xen,xen-";
 	struct resource res;
+	int i;
 
 	node = of_find_compatible_node(NULL, NULL, "xen,xen");
 	if (!node) {
@@ -216,6 +245,8 @@ static int __init xen_guest_init(void)
 	 * is required to use VCPUOP_register_vcpu_info to place vcpu info
 	 * for secondary CPUs as they are brought up. */
 	per_cpu(xen_vcpu, 0) = &HYPERVISOR_shared_info->vcpu_info[0];
+	for_each_online_cpu(i)
+		xen_secondary_init(i);
 
 	gnttab_init();
 	if (!xen_initial_domain())
@@ -231,6 +262,11 @@ static irqreturn_t xen_arm_callback(int irq, void *arg)
 	return IRQ_HANDLED;
 }
 
+static __init void xen_percpu_enable_events(void *unused)
+{
+	enable_percpu_irq(xen_events_irq, 0);
+}
+
 static int __init xen_init_events(void)
 {
 	if (!xen_domain() || xen_events_irq < 0)
@@ -244,7 +280,7 @@ static int __init xen_init_events(void)
 		return -EINVAL;
 	}
 
-	enable_percpu_irq(xen_events_irq, 0);
+	on_each_cpu(xen_percpu_enable_events, NULL, 0);
 
 	return 0;
 }
-- 
1.7.2.5



From nicolas.ferre at atmel.com  Thu Apr 18 10:51:42 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Thu, 18 Apr 2013 16:51:42 +0200
Subject: [GIT PULL] at91: soc for 3.10 #3
Message-ID: <1366296702-26436-1-git-send-email-nicolas.ferre@atmel.com>

Arnd, Olof,

Third pull-request for AT91 SoC support based on material that you already have
in your arm-soc/at91/soc branch.
Not very core changes here but interesting enhancements.

Thanks, best regards,

The following changes since commit 471c9e786596c4f028c67c7e9de0703b49cab2a9:

  ARM: at91: add defconfig for SAMA5 (2013-03-26 12:18:05 +0100)

are available in the git repository at:

  git://github.com/at91linux/linux-at91.git tags/at91-soc

for you to fetch changes up to f5fa4098c3fcc0e504fbc0682dccd331dbbcf197:

  ARM: at91: suspend both memory controllers on at91sam9263 (2013-04-18 16:31:02 +0200)

----------------------------------------------------------------
Little modification in SoC presentation in kernel log.
Removing of a long-standing warning in sam9263 PM code.

----------------------------------------------------------------
Arnd Bergmann (1):
      ARM: at91: suspend both memory controllers on at91sam9263

Nicolas Ferre (1):
      ARM: at91: change "Unknown" qualifier SoC subtype handling

 arch/arm/mach-at91/cpuidle.c          |  2 ++
 arch/arm/mach-at91/include/mach/cpu.h |  9 ++++++---
 arch/arm/mach-at91/pm.c               |  2 ++
 arch/arm/mach-at91/pm.h               | 30 ++++++++++++++++++++++++------
 arch/arm/mach-at91/setup.c            | 22 +++++++++++++++-------
 5 files changed, 49 insertions(+), 16 deletions(-)

-- 
Nicolas Ferre


From broonie at kernel.org  Thu Apr 18 10:56:02 2013
From: broonie at kernel.org (Mark Brown)
Date: Thu, 18 Apr 2013 15:56:02 +0100
Subject: [alsa-devel] [PATCH v4 02/10] ASoC: imx-pcm-dma: DT support
In-Reply-To: <5170069F.4030200@metafoo.de>
References: <1366288424-7660-1-git-send-email-mpa@pengutronix.de>
 <1366288424-7660-3-git-send-email-mpa@pengutronix.de>
 <5170069F.4030200@metafoo.de>
Message-ID: <20130418145602.GL13687@opensource.wolfsonmicro.com>

On Thu, Apr 18, 2013 at 04:43:43PM +0200, Lars-Peter Clausen wrote:
> On 04/18/2013 02:33 PM, Markus Pargmann wrote:

> > +	if (pdev->dev.platform_data)
> > +		pdev->dev.of_node = pdev->dev.platform_data;

> In my opinion it's better to use pdev->dev.parent->of_node here. In the ssi
> driver you use platform_device_register_data, which will create a copy of
> the of_node you pass in as platform data. I'm not quite sure how well this
> will work. If you want to continue to use platform_data you should at least
> change the code in the ssi driver to not make a copy of the of_node.

If nothing else the above code just looks wrong and confusing.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130418/2fc43ee6/attachment-0001.sig>

From richard.genoud at gmail.com  Thu Apr 18 11:04:32 2013
From: richard.genoud at gmail.com (Richard GENOUD)
Date: Thu, 18 Apr 2013 17:04:32 +0200
Subject: [PATCH RFC] ARM: don't allow to register the early_console twice
In-Reply-To: <1366295019-30335-2-git-send-email-gregory.clement@free-electrons.com>
References: <1366295019-30335-1-git-send-email-gregory.clement@free-electrons.com>
 <1366295019-30335-2-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <20130418150430.GA19382@lnx-rg>

On [jeu., 18.04.2013 16:23:39], Gregory CLEMENT wrote:
> If on the kernel command line the parameter "earlyprintk" is written
> twice, then setup_early_printk is called twice. This can happen for
> example with the option CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND is
> selected, and the "earlyprintk" is passed from the ATAG_CMDLINE and
> from the dtb.
> 
> This lead to an infinite loop on the message "Booting Linux on
> physical CPU 0" displayed from smp_setup_processor_id() in
> arch/arm/kernel/setup.c. This behavior as been reproduced on ARMv7
> architecture (Armada XP and Armada 370), and on a ARMv5 one
> (AT91SAMG35 thanks to Richard Genoud), with and with CONFIG_SMP
> selected.
> 
> This patch simply doesn't allow to call twice register_console() with
> the early_console.
> 
> Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
> ---
>  arch/arm/kernel/early_printk.c |    6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/kernel/early_printk.c b/arch/arm/kernel/early_printk.c
> index 85aa2b2..435577a 100644
> --- a/arch/arm/kernel/early_printk.c
> +++ b/arch/arm/kernel/early_printk.c
> @@ -50,7 +50,11 @@ asmlinkage void early_printk(const char *fmt, ...)
>  
>  static int __init setup_early_printk(char *buf)
>  {
> -	register_console(&early_console);
> +	static int done;
> +	if (!done) {
> +		register_console(&early_console);
> +		done = 1;
> +	}
>  	return 0;
>  }
>  
> -- 
> 1.7.9.5
Tested on at91sam9g35-ek kernel 3.9-rc7 +custom patches

Tested-by: Richard Genoud <richard.genoud at gmail.com>



From stefano.stabellini at eu.citrix.com  Thu Apr 18 11:04:44 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Thu, 18 Apr 2013 16:04:44 +0100
Subject: [PATCH 0/3 v7] arm: introduce psci_smp_ops
Message-ID: <alpine.DEB.2.02.1304181556210.7254@kaball.uk.xensource.com>

Hi all,
this is the seventh version of the patch series to move virt_smp_ops out
of mach-virt and make it a generic set of reusable PSCI based smp_ops.
psci_smp_ops are preferred over the platform smp_ops.
The last patch introduces smp_init.

I removed the patch that makes use of smp_init in Xen, because it
depends on other Xen changes. I'll send it separately.
This version of the series is independent of other changes.


Jon Medhurst (1):
      ARM: Enable selection of SMP operations at boot time

Stefano Stabellini (2):
      arm: introduce psci_smp_ops
      arm: prefer psci_smp_ops over mdesc->smp

 arch/arm/include/asm/mach/arch.h |    3 ++
 arch/arm/include/asm/psci.h      |   29 ++++++++++++++++
 arch/arm/kernel/Makefile         |    5 ++-
 arch/arm/kernel/psci.c           |    7 ++--
 arch/arm/kernel/psci_smp.c       |   67 ++++++++++++++++++++++++++++++++++++++
 arch/arm/kernel/setup.c          |    9 ++++-
 arch/arm/mach-virt/Makefile      |    1 -
 arch/arm/mach-virt/platsmp.c     |   58 --------------------------------
 arch/arm/mach-virt/virt.c        |    3 --
 9 files changed, 114 insertions(+), 68 deletions(-)


git://git.kernel.org/pub/scm/linux/kernel/git/sstabellini/xen.git 3.9-rc3-psci-ops-7-tag

Cheers,

Stefano


From stefano.stabellini at eu.citrix.com  Thu Apr 18 11:05:29 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Thu, 18 Apr 2013 16:05:29 +0100
Subject: [PATCH v7 2/3] arm: prefer psci_smp_ops over mdesc->smp
In-Reply-To: <alpine.DEB.2.02.1304181556210.7254@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1304181556210.7254@kaball.uk.xensource.com>
Message-ID: <1366297530-12497-2-git-send-email-stefano.stabellini@eu.citrix.com>

If PSCI is available on the platform, prefer psci_smp_ops over the
platform smp_ops.

Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
Acked-by: Nicolas Pitre <nico at linaro.org>
---
 arch/arm/kernel/setup.c |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 341efaa..dad3048 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -770,10 +770,10 @@ void __init setup_arch(char **cmdline_p)
 	psci_init();
 #ifdef CONFIG_SMP
 	if (is_smp()) {
-		if (mdesc->smp)
-			smp_set_ops(mdesc->smp);
-		else if (psci_smp_available())
+		if (psci_smp_available())
 			smp_set_ops(&psci_smp_ops);
+		else if (mdesc->smp)
+			smp_set_ops(mdesc->smp);
 		smp_init_cpus();
 	}
 #endif
-- 
1.7.2.5



From stefano.stabellini at eu.citrix.com  Thu Apr 18 11:05:30 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Thu, 18 Apr 2013 16:05:30 +0100
Subject: [PATCH v7 3/3] ARM: Enable selection of SMP operations at boot time
In-Reply-To: <alpine.DEB.2.02.1304181556210.7254@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1304181556210.7254@kaball.uk.xensource.com>
Message-ID: <1366297530-12497-3-git-send-email-stefano.stabellini@eu.citrix.com>

From: Jon Medhurst <tixy at linaro.org>

Add a new 'smp_init' hook to machine_desc so platforms can specify a
function to be used to setup smp ops instead of having a statically
defined value.  The hook must return true when smp_ops are initialized.
If false the static mdesc->smp_ops will be used by default.

Signed-off-by: Jon Medhurst <tixy at linaro.org>
Signed-off-by: Nicolas Pitre <nicolas.pitre at linaro.org>
Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
Reviewed-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
---
 arch/arm/include/asm/mach/arch.h |    3 +++
 arch/arm/kernel/setup.c          |   10 ++++++----
 2 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/arch/arm/include/asm/mach/arch.h b/arch/arm/include/asm/mach/arch.h
index 308ad7d..af8c54c 100644
--- a/arch/arm/include/asm/mach/arch.h
+++ b/arch/arm/include/asm/mach/arch.h
@@ -16,8 +16,10 @@ struct pt_regs;
 struct smp_operations;
 #ifdef CONFIG_SMP
 #define smp_ops(ops) (&(ops))
+#define smp_init_ops(ops) (&(ops))
 #else
 #define smp_ops(ops) (struct smp_operations *)NULL
+#define smp_init_ops(ops) (bool (*)(void))NULL
 #endif
 
 struct machine_desc {
@@ -41,6 +43,7 @@ struct machine_desc {
 	unsigned char		reserve_lp2 :1;	/* never has lp2	*/
 	char			restart_mode;	/* default restart mode	*/
 	struct smp_operations	*smp;		/* SMP operations	*/
+	bool			(*smp_init)(void);
 	void			(*fixup)(struct tag *, char **,
 					 struct meminfo *);
 	void			(*reserve)(void);/* reserve mem blocks	*/
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index dad3048..22cc863 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -770,10 +770,12 @@ void __init setup_arch(char **cmdline_p)
 	psci_init();
 #ifdef CONFIG_SMP
 	if (is_smp()) {
-		if (psci_smp_available())
-			smp_set_ops(&psci_smp_ops);
-		else if (mdesc->smp)
-			smp_set_ops(mdesc->smp);
+		if (!mdesc->smp_init || !mdesc->smp_init()) {
+			if (psci_smp_available())
+				smp_set_ops(&psci_smp_ops);
+			else if (mdesc->smp)
+				smp_set_ops(mdesc->smp);
+		}
 		smp_init_cpus();
 	}
 #endif
-- 
1.7.2.5



From stefano.stabellini at eu.citrix.com  Thu Apr 18 11:05:28 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Thu, 18 Apr 2013 16:05:28 +0100
Subject: [PATCH v7 1/3] arm: introduce psci_smp_ops
In-Reply-To: <alpine.DEB.2.02.1304181556210.7254@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1304181556210.7254@kaball.uk.xensource.com>
Message-ID: <1366297530-12497-1-git-send-email-stefano.stabellini@eu.citrix.com>

Rename virt_smp_ops to psci_smp_ops and move them to arch/arm/kernel/psci_smp.c.
Remove mach-virt/platsmp.c, now unused.
Compile psci_smp if CONFIG_ARM_PSCI and CONFIG_SMP.

Add a cpu_die smp_op based on psci_ops.cpu_off.

Initialize PSCI before setting smp_ops in setup_arch.
Use psci_smp_ops if the platform doesn't provide its own smp_ops.

Changes in v6:
- fixed return values for psci_smp_available and psci_init ifndef
CONFIG_ARM_PSCI.

Changes in v5:
- document psci_operations;
- psci_init returns NULL.

Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
Acked-by: Nicolas Pitre <nico at linaro.org>
Acked-by: Rob Herring <rob.herring at calxeda.com>
Reviewed-by: Will Deacon <will.deacon at arm.com>

CC: will.deacon at arm.com
CC: arnd at arndb.de
CC: marc.zyngier at arm.com
CC: linux at arm.linux.org.uk
CC: nico at linaro.org
---
 arch/arm/include/asm/psci.h  |   29 ++++++++++++++++++
 arch/arm/kernel/Makefile     |    5 ++-
 arch/arm/kernel/psci.c       |    7 ++--
 arch/arm/kernel/psci_smp.c   |   67 ++++++++++++++++++++++++++++++++++++++++++
 arch/arm/kernel/setup.c      |    7 ++++-
 arch/arm/mach-virt/Makefile  |    1 -
 arch/arm/mach-virt/platsmp.c |   58 ------------------------------------
 arch/arm/mach-virt/virt.c    |    3 --
 8 files changed, 109 insertions(+), 68 deletions(-)
 create mode 100644 arch/arm/kernel/psci_smp.c
 delete mode 100644 arch/arm/mach-virt/platsmp.c

diff --git a/arch/arm/include/asm/psci.h b/arch/arm/include/asm/psci.h
index ce0dbe7..fa44417 100644
--- a/arch/arm/include/asm/psci.h
+++ b/arch/arm/include/asm/psci.h
@@ -23,6 +23,26 @@ struct psci_power_state {
 	u8	affinity_level;
 };
 
+/*
+ * cpu_suspend   Suspend the execution on a CPU
+ * @state        we don't currently describe affinity levels, so just pass 0.
+ * @entry_point  the first instruction to be executed on return
+ * returns 0  success, < 0 on failure
+ *
+ * cpu_off       Power down a CPU
+ * @state        we don't currently describe affinity levels, so just pass 0.
+ * no return on successful call
+ *
+ * cpu_on        Power up a CPU
+ * @cpuid        cpuid of target CPU, as from MPIDR
+ * @entry_point  the first instruction to be executed on return
+ * returns 0  success, < 0 on failure
+ *
+ * migrate       Migrate the context to a different CPU
+ * @cpuid        cpuid of target CPU, as from MPIDR
+ * returns 0  success, < 0 on failure
+ *
+ */
 struct psci_operations {
 	int (*cpu_suspend)(struct psci_power_state state,
 			   unsigned long entry_point);
@@ -32,5 +52,14 @@ struct psci_operations {
 };
 
 extern struct psci_operations psci_ops;
+extern struct smp_operations psci_smp_ops;
+
+#ifdef CONFIG_ARM_PSCI
+void psci_init(void);
+bool psci_smp_available(void);
+#else
+static inline void psci_init(void) { }
+static inline bool psci_smp_available(void) { return false; }
+#endif
 
 #endif /* __ASM_ARM_PSCI_H */
diff --git a/arch/arm/kernel/Makefile b/arch/arm/kernel/Makefile
index 5f3338e..dd9d90a 100644
--- a/arch/arm/kernel/Makefile
+++ b/arch/arm/kernel/Makefile
@@ -82,6 +82,9 @@ obj-$(CONFIG_DEBUG_LL)	+= debug.o
 obj-$(CONFIG_EARLY_PRINTK)	+= early_printk.o
 
 obj-$(CONFIG_ARM_VIRT_EXT)	+= hyp-stub.o
-obj-$(CONFIG_ARM_PSCI)		+= psci.o
+ifeq ($(CONFIG_ARM_PSCI),y)
+obj-y				+= psci.o
+obj-$(CONFIG_SMP)		+= psci_smp.o
+endif
 
 extra-y := $(head-y) vmlinux.lds
diff --git a/arch/arm/kernel/psci.c b/arch/arm/kernel/psci.c
index 3653164..4693188 100644
--- a/arch/arm/kernel/psci.c
+++ b/arch/arm/kernel/psci.c
@@ -158,7 +158,7 @@ static const struct of_device_id psci_of_match[] __initconst = {
 	{},
 };
 
-static int __init psci_init(void)
+void __init psci_init(void)
 {
 	struct device_node *np;
 	const char *method;
@@ -166,7 +166,7 @@ static int __init psci_init(void)
 
 	np = of_find_matching_node(NULL, psci_of_match);
 	if (!np)
-		return 0;
+		return;
 
 	pr_info("probing function IDs from device-tree\n");
 
@@ -206,6 +206,5 @@ static int __init psci_init(void)
 
 out_put_node:
 	of_node_put(np);
-	return 0;
+	return;
 }
-early_initcall(psci_init);
diff --git a/arch/arm/kernel/psci_smp.c b/arch/arm/kernel/psci_smp.c
new file mode 100644
index 0000000..66b0f77
--- /dev/null
+++ b/arch/arm/kernel/psci_smp.c
@@ -0,0 +1,67 @@
+/*
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Copyright (C) 2012 ARM Limited
+ *
+ * Author: Will Deacon <will.deacon at arm.com>
+ */
+
+#include <linux/init.h>
+#include <linux/irqchip/arm-gic.h>
+#include <linux/smp.h>
+#include <linux/of.h>
+
+#include <asm/psci.h>
+#include <asm/smp_plat.h>
+
+extern void secondary_startup(void);
+
+static int __cpuinit psci_boot_secondary(unsigned int cpu,
+					 struct task_struct *idle)
+{
+	if (psci_ops.cpu_on)
+		return psci_ops.cpu_on(cpu_logical_map(cpu),
+				       __pa(secondary_startup));
+	return -ENODEV;
+}
+
+static void __cpuinit psci_secondary_init(unsigned int cpu)
+{
+	gic_secondary_init(0);
+}
+
+#ifdef CONFIG_HOTPLUG_CPU
+void __ref psci_cpu_die(unsigned int cpu)
+{
+       const struct psci_power_state ps = {
+               .type = PSCI_POWER_STATE_TYPE_POWER_DOWN,
+       };
+
+       if (psci_ops.cpu_off)
+               psci_ops.cpu_off(ps);
+
+       /* We should never return */
+       panic("psci: cpu %d failed to shutdown\n", cpu);
+}
+#else
+#define psci_cpu_die NULL
+#endif
+
+bool __init psci_smp_available(void)
+{
+	/* is cpu_on available at least? */
+	return (psci_ops.cpu_on != NULL);
+}
+
+struct smp_operations __initdata psci_smp_ops = {
+	.smp_secondary_init	= psci_secondary_init,
+	.smp_boot_secondary	= psci_boot_secondary,
+	.cpu_die		= psci_cpu_die,
+};
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 3f6cbb2..341efaa 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -36,6 +36,7 @@
 #include <asm/cputype.h>
 #include <asm/elf.h>
 #include <asm/procinfo.h>
+#include <asm/psci.h>
 #include <asm/sections.h>
 #include <asm/setup.h>
 #include <asm/smp_plat.h>
@@ -766,9 +767,13 @@ void __init setup_arch(char **cmdline_p)
 	unflatten_device_tree();
 
 	arm_dt_init_cpu_maps();
+	psci_init();
 #ifdef CONFIG_SMP
 	if (is_smp()) {
-		smp_set_ops(mdesc->smp);
+		if (mdesc->smp)
+			smp_set_ops(mdesc->smp);
+		else if (psci_smp_available())
+			smp_set_ops(&psci_smp_ops);
 		smp_init_cpus();
 	}
 #endif
diff --git a/arch/arm/mach-virt/Makefile b/arch/arm/mach-virt/Makefile
index 042afc1..7ddbfa6 100644
--- a/arch/arm/mach-virt/Makefile
+++ b/arch/arm/mach-virt/Makefile
@@ -3,4 +3,3 @@
 #
 
 obj-y					:= virt.o
-obj-$(CONFIG_SMP)			+= platsmp.o
diff --git a/arch/arm/mach-virt/platsmp.c b/arch/arm/mach-virt/platsmp.c
deleted file mode 100644
index 8badaab..0000000
--- a/arch/arm/mach-virt/platsmp.c
+++ /dev/null
@@ -1,58 +0,0 @@
-/*
- * Dummy Virtual Machine - does what it says on the tin.
- *
- * Copyright (C) 2012 ARM Ltd
- * Author: Will Deacon <will.deacon at arm.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.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program.  If not, see <http://www.gnu.org/licenses/>.
- */
-
-#include <linux/init.h>
-#include <linux/smp.h>
-#include <linux/of.h>
-
-#include <linux/irqchip/arm-gic.h>
-
-#include <asm/psci.h>
-#include <asm/smp_plat.h>
-
-extern void secondary_startup(void);
-
-static void __init virt_smp_init_cpus(void)
-{
-}
-
-static void __init virt_smp_prepare_cpus(unsigned int max_cpus)
-{
-}
-
-static int __cpuinit virt_boot_secondary(unsigned int cpu,
-					 struct task_struct *idle)
-{
-	if (psci_ops.cpu_on)
-		return psci_ops.cpu_on(cpu_logical_map(cpu),
-				       __pa(secondary_startup));
-	return -ENODEV;
-}
-
-static void __cpuinit virt_secondary_init(unsigned int cpu)
-{
-	gic_secondary_init(0);
-}
-
-struct smp_operations __initdata virt_smp_ops = {
-	.smp_init_cpus		= virt_smp_init_cpus,
-	.smp_prepare_cpus	= virt_smp_prepare_cpus,
-	.smp_secondary_init	= virt_secondary_init,
-	.smp_boot_secondary	= virt_boot_secondary,
-};
diff --git a/arch/arm/mach-virt/virt.c b/arch/arm/mach-virt/virt.c
index 31666f6..4438ed0 100644
--- a/arch/arm/mach-virt/virt.c
+++ b/arch/arm/mach-virt/virt.c
@@ -43,12 +43,9 @@ static const char *virt_dt_match[] = {
 	NULL
 };
 
-extern struct smp_operations virt_smp_ops;
-
 DT_MACHINE_START(VIRT, "Dummy Virtual Machine")
 	.init_irq	= irqchip_init,
 	.init_time	= virt_timer_init,
 	.init_machine	= virt_init,
-	.smp		= smp_ops(virt_smp_ops),
 	.dt_compat	= virt_dt_match,
 MACHINE_END
-- 
1.7.2.5



From shawn.guo at linaro.org  Thu Apr 18 11:15:29 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Thu, 18 Apr 2013 23:15:29 +0800
Subject: [PATCH V2] ARM: i.MX5: Allow DT clock providers
In-Reply-To: <516FB0A5.9050903@parkeon.com>
References: <20130415080741.20173.70704.stgit@localhost>
 <20130418063056.GA20566@S2101-09.ap.freescale.net>
 <516FB0A5.9050903@parkeon.com>
Message-ID: <20130418151527.GF2222@S2101-09.ap.freescale.net>

On Thu, Apr 18, 2013 at 10:36:53AM +0200, Martin Fuzzey wrote:
> On 18/04/13 08:30, Shawn Guo wrote:
> >+static struct clk * __init mx5_obtain_fixed_clock_from_dt(const char *name)
> >+{
> >+#ifdef CONFIG_OF
> >We have selected USE_OF at the sub-architecture level, so the ifdef
> >plays nothing here.
> Ah ok so what happens on non DT platforms (looks like Babbage)
> Does this mean that there is an empty DT in that case?
> 
I think function of_find_* will return NULL for non-DT boot, so
ERR_PTR(-ENODEV) will just be returned from
mx5_obtain_fixed_clock_from_dt().

> I was going by the existing code which already has this #ifdef
> 
Right.  We just haven't got the chance to clean them up.

> >>+	struct of_phandle_args phandle = {0};
> >>+	struct clk *clk = ERR_PTR(-ENODEV);
> >>+	char *compatible;
> >>+
> >>+	compatible = kasprintf(GFP_KERNEL, "fsl,imx-%s", name);
> >What about finding the node by path as below?
> >
> >	path = kasprintf(GFP_KERNEL, "/clocks/%s", name);
> >	phandle.np = of_find_node_by_path(path);
> >
> >I have to admit that those imx custom compatibles for fixed-clock
> >shouldn't necessarily be there at all.  Let's stop spreading the use.
> I can't find anything in the DT binding documentation that says the
> clocks have to be
> under /clocks  (but then again the fsl,imx- compatible string isn't
> documented either).
> 
> My understanding of DT is that the absolute node path is generally
> unimportant with
> the exception of a few special nodes like /, /memory, /chosen
> 
I think the function of_find_node_by_path() is created not only for
finding these special nodes.

> But I don't have a strong opinion on this - if the consensus is that
> path based lookup
> is better I'll do that.
> 
We just want to save the custom compatible string which are there only
for finding a fixed-clock, while node name/path can be used for
searching.

Shawn



From lars at metafoo.de  Thu Apr 18 11:14:37 2013
From: lars at metafoo.de (Lars-Peter Clausen)
Date: Thu, 18 Apr 2013 17:14:37 +0200
Subject: [PATCH RESEND v5 1/2] dma: imx-dma: Add oftree support
In-Reply-To: <1366291298-30004-2-git-send-email-mpa@pengutronix.de>
References: <1366291298-30004-1-git-send-email-mpa@pengutronix.de>
 <1366291298-30004-2-git-send-email-mpa@pengutronix.de>
Message-ID: <51700DDD.1060801@metafoo.de>

Hi,

On 04/18/2013 03:21 PM, Markus Pargmann wrote:
[...]
> +static struct dma_chan *imxdma_xlate(struct of_phandle_args *dma_spec,
> +						struct of_dma *ofdma)
> +{
> +	int count = dma_spec->args_count;
> +	struct imxdma_engine *imxdma = ofdma->of_dma_data;
> +	struct imxdma_filter_data fdata = {
> +		.imxdma = imxdma,
> +		.request = *(unsigned *)&dma_spec->args[0],

This cast looks rather bogus and shouldn't be necessary.

> +	};
> +
> +	if (count != 1)
> +		return NULL;

I think you need to check count before you access dma_spec->args[0]

> +
> +	return dma_request_channel(imxdma->dma_device.cap_mask,
> +					imxdma_filter_fn, &fdata);
> +}
> +
[...]



From stefano.stabellini at eu.citrix.com  Thu Apr 18 11:16:07 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Thu, 18 Apr 2013 16:16:07 +0100
Subject: [PATCH] xen/arm: introduce xen_early_init, use PSCI on xen
Message-ID: <1366298167-12755-1-git-send-email-stefano.stabellini@eu.citrix.com>

Split xen_guest_init in two functions, one of them (xen_early_init) is
going to be called very early from setup_arch.

Change machine_desc->smp_init to xen_smp_init if Xen is present on the
platform. xen_smp_init just sets smp_ops to psci_smp_ops.

XEN selects ARM_PSCI.


This patch is based on "xen/arm: move to mach-virt and support SMP"
(http://marc.info/?l=linux-kernel&m=136629656432231&w=2)
and "arm: introduce psci_smp_ops"
(http://marc.info/?l=linux-kernel&m=136629750732674&w=2).
A git tag for this patch is available here:

git://git.kernel.org/pub/scm/linux/kernel/git/sstabellini/xen.git 3.9-rc3-psci-xen-1-tag


Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
CC: xen-devel at lists.xensource.com
CC: linux-kernel at vger.kernel.org
CC: linux-arm-kernel at lists.infradead.org
CC: will.deacon at arm.com
CC: arnd at arndb.de
CC: nicolas.pitre at linaro.org
CC: rob.herring at calxeda.com
CC: linux at arm.linux.org.uk
CC: olof at lixom.net
---
 arch/arm/Kconfig                      |    1 +
 arch/arm/include/asm/xen/hypervisor.h |    6 +++++
 arch/arm/kernel/setup.c               |    3 ++
 arch/arm/xen/enlighten.c              |   39 ++++++++++++++++++++++++++------
 4 files changed, 41 insertions(+), 8 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 2c3bdce..344e299 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1892,6 +1892,7 @@ config XEN
 	depends on ARM && AEABI && OF
 	depends on CPU_V7 && !CPU_V6
 	depends on !GENERIC_ATOMIC64
+	select ARM_PSCI
 	help
 	  Say Y if you want to run Linux in a Virtual Machine on Xen on ARM.
 
diff --git a/arch/arm/include/asm/xen/hypervisor.h b/arch/arm/include/asm/xen/hypervisor.h
index d7ab99a..17b3ea2 100644
--- a/arch/arm/include/asm/xen/hypervisor.h
+++ b/arch/arm/include/asm/xen/hypervisor.h
@@ -16,4 +16,10 @@ static inline enum paravirt_lazy_mode paravirt_get_lazy_mode(void)
 	return PARAVIRT_LAZY_NONE;
 }
 
+#ifdef CONFIG_XEN
+void xen_early_init(void);
+#else
+static inline void xen_early_init(void) { return; }
+#endif
+
 #endif /* _ASM_ARM_XEN_HYPERVISOR_H */
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 22cc863..3dcd357 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -55,6 +55,8 @@
 #include <asm/unwind.h>
 #include <asm/memblock.h>
 #include <asm/virt.h>
+#include <asm/xen/hypervisor.h>
+#include <xen/xen.h>
 
 #include "atags.h"
 #include "tcm.h"
@@ -768,6 +770,7 @@ void __init setup_arch(char **cmdline_p)
 
 	arm_dt_init_cpu_maps();
 	psci_init();
+	xen_early_init();
 #ifdef CONFIG_SMP
 	if (is_smp()) {
 		if (!mdesc->smp_init || !mdesc->smp_init()) {
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index b002822..3006de4 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -11,6 +11,8 @@
 #include <xen/xenbus.h>
 #include <xen/page.h>
 #include <xen/xen-ops.h>
+#include <asm/mach/arch.h>
+#include <asm/psci.h>
 #include <asm/xen/hypervisor.h>
 #include <asm/xen/hypercall.h>
 #include <linux/interrupt.h>
@@ -176,11 +178,36 @@ static int __init xen_secondary_init(unsigned int cpu)
 	return 0;
 }
 
+static bool __init xen_smp_init(void)
+{
+#ifdef CONFIG_SMP
+	/* If we are running on Xen, use PSCI if available.
+	 * In any case do not try to use the native smp_ops. */
+	if (psci_smp_available())
+		smp_set_ops(&psci_smp_ops);
+	return true;
+#endif
+}
+
 /*
  * see Documentation/devicetree/bindings/arm/xen.txt for the
  * documentation of the Xen Device Tree format.
  */
 #define GRANT_TABLE_PHYSADDR 0
+void __init xen_early_init(void)
+{
+	struct device_node *node;
+
+	node = of_find_compatible_node(NULL, NULL, "xen,xen");
+	if (!node) {
+		pr_debug("No Xen support\n");
+		return;
+	}
+
+	xen_domain_type = XEN_HVM_DOMAIN;
+	machine_desc->smp_init = xen_smp_init;
+}
+
 static int __init xen_guest_init(void)
 {
 	struct xen_add_to_physmap xatp;
@@ -194,25 +221,21 @@ static int __init xen_guest_init(void)
 	int i;
 
 	node = of_find_compatible_node(NULL, NULL, "xen,xen");
-	if (!node) {
-		pr_debug("No Xen support\n");
-		return 0;
-	}
+
 	s = of_get_property(node, "compatible", &len);
 	if (strlen(xen_prefix) + 3  < len &&
 			!strncmp(xen_prefix, s, strlen(xen_prefix)))
 		version = s + strlen(xen_prefix);
 	if (version == NULL) {
-		pr_debug("Xen version not found\n");
-		return 0;
+		pr_warn("Xen version not found\n");
+		return -EINVAL;
 	}
 	if (of_address_to_resource(node, GRANT_TABLE_PHYSADDR, &res))
-		return 0;
+		return -EINVAL;
 	xen_hvm_resume_frames = res.start >> PAGE_SHIFT;
 	xen_events_irq = irq_of_parse_and_map(node, 0);
 	pr_info("Xen %s support found, events_irq=%d gnttab_frame_pfn=%lx\n",
 			version, xen_events_irq, xen_hvm_resume_frames);
-	xen_domain_type = XEN_HVM_DOMAIN;
 
 	xen_setup_features();
 	if (xen_feature(XENFEAT_dom0))
-- 
1.7.2.5



From cov at codeaurora.org  Thu Apr 18 11:25:56 2013
From: cov at codeaurora.org (Christopher Covington)
Date: Thu, 18 Apr 2013 11:25:56 -0400
Subject: [RFC] arm64: Early printk support for virtio-mmio console devices.
In-Reply-To: <1366264344-28025-1-git-send-email-pranavkumar@linaro.org>
References: <1366264344-28025-1-git-send-email-pranavkumar@linaro.org>
Message-ID: <51701084.5050706@codeaurora.org>

Hi Pranavkumar,

On 04/18/2013 01:52 AM, PranavkumarSawargaonkar wrote:
> From: Pranavkumar Sawargaonkar <pranavkumar at linaro.org>
> 
> This patch implements early printk support for virtio-mmio console devices 
> without using any hypercalls.

Is it possible that using DCC might be an easier solution?

[...]

Regards,
Christopher

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by the Linux Foundation.


From andrew.murray at arm.com  Thu Apr 18 11:27:48 2013
From: andrew.murray at arm.com (Andrew Murray)
Date: Thu, 18 Apr 2013 16:27:48 +0100
Subject: I/O and multiple PCI buses
Message-ID: <20130418152747.GA19258@arm.com>

I'm trying to understand PCI I/O addressing in the kernel... (again)

I understand that ideally you want to give PCI bus addresses to PCI devices in
the range of 0K to 64K. This seems to be achieved in pcibios_init_resources in
arm's kernel/bios32.c implementation.

What happens if you want to add another root bus? In this implementation the
start address of the io_res is now 64K and as sys->io_offset is set to 0 the
bus addresses under this second root bus will be 64K-128K - which I assume may
break some things.

Am I correct that for ARM there are no implementations where subsequent root
buses allocate I/O starting from 0?

And to allow subsequent busses to use I/O starting from 0, you'd have to set
sys->io_offset to 64K*nr and adapt functions such as pci_iomap to use the
offset?

Are there any other archiectures that do give I/O ranges starting from 0 in
subsequent root busses? Or am I missing something here?

Andrew Murray


From grant.likely at secretlab.ca  Thu Apr 18 11:29:54 2013
From: grant.likely at secretlab.ca (Grant Likely)
Date: Thu, 18 Apr 2013 16:29:54 +0100
Subject: [PATCH v7 2/3] of/pci: Provide support for parsing PCI DT ranges
 property
In-Reply-To: <20130418142434.GA18881@arm.com>
References: <1366107508-12672-1-git-send-email-Andrew.Murray@arm.com>
 <1366107508-12672-3-git-send-email-Andrew.Murray@arm.com>
 <20130418134401.84AEE3E1319@localhost>
 <20130418142434.GA18881@arm.com>
Message-ID: <CACxGe6u7yoecyTR2r-EzpcRxLuSw-p9KC7jA12wEQZs4of3vFA@mail.gmail.com>

On Thu, Apr 18, 2013 at 3:24 PM, Andrew Murray <andrew.murray at arm.com> wrote:
> On Thu, Apr 18, 2013 at 02:44:01PM +0100, Grant Likely wrote:
>> On Tue, 16 Apr 2013 11:18:27 +0100, Andrew Murray <Andrew.Murray at arm.com> wrote:
>> >             /* Act based on address space type */
>> >             res = NULL;
>> > -           switch ((pci_space >> 24) & 0x3) {
>> > -           case 1:         /* PCI IO space */
>> > +           res_type = range.flags & IORESOURCE_TYPE_BITS;
>> > +           if (res_type == IORESOURCE_IO) {
>>
>> Why the change from switch() to an if/else if sequence?
>
> Russell King suggested this change - see
> https://patchwork.kernel.org/patch/2323941/

Umm, that isn't what that link shows. That link shows the patch
already changing to an if/else if construct, and rmk is commenting on
that.

g.


From linux at arm.linux.org.uk  Thu Apr 18 11:30:03 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Thu, 18 Apr 2013 16:30:03 +0100
Subject: [PATCH 1/2] ARM: EXYNOS: Add a platform bus notifier to set
 dma masks for Exynos5440
In-Reply-To: <1365072704-4568-1-git-send-email-kgene.kim@samsung.com>
References: <1365072704-4568-1-git-send-email-kgene.kim@samsung.com>
Message-ID: <20130418153003.GW14496@n2100.arm.linux.org.uk>

On Thu, Apr 04, 2013 at 07:51:43PM +0900, Kukjin Kim wrote:
> +static u64 dma_mask64 = DMA_BIT_MASK(64);
...
> +	if (event != BUS_NOTIFY_ADD_DEVICE)
> +		return NOTIFY_DONE;
> +
> +	dev->dma_mask = &dma_mask64;

Sharing the dma mask in this way is a potential issue should you have a
device driver use dma_set_mask() - which can write to this value.

A better solution would be:

diff --git a/arch/arm/include/asm/device.h b/arch/arm/include/asm/device.h
index dc662fc..51bb740 100644
--- a/arch/arm/include/asm/device.h
+++ b/arch/arm/include/asm/device.h
@@ -22,6 +22,7 @@ struct dev_archdata {
 struct omap_device;
 
 struct pdev_archdata {
+	u64 dma_mask;
 #ifdef CONFIG_ARCH_OMAP
 	struct omap_device *od;
 #endif

and then in your function do:

	struct platform_device *pdev = to_platform_device(dev);
...
	pdev->dev.dma_mask = &pdev->arch_data.dma_mask;
	pdev->arch_data.dma_mask = DMA_BIT_MASK(64);

However... are all your devices really DMA capable?  Normally on a SoC,
it's only the DMA engine which is DMA capable and everything else is not,
and in that case you really only want to set the DMA masks up for the
DMA capable devices.


From mpa at pengutronix.de  Thu Apr 18 11:35:12 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Thu, 18 Apr 2013 17:35:12 +0200
Subject: [alsa-devel] [PATCH v4 02/10] ASoC: imx-pcm-dma: DT support
In-Reply-To: <5170069F.4030200@metafoo.de>
References: <1366288424-7660-1-git-send-email-mpa@pengutronix.de>
 <1366288424-7660-3-git-send-email-mpa@pengutronix.de>
 <5170069F.4030200@metafoo.de>
Message-ID: <20130418153512.GA4307@pengutronix.de>

On Thu, Apr 18, 2013 at 04:43:43PM +0200, Lars-Peter Clausen wrote:
> On 04/18/2013 02:33 PM, Markus Pargmann wrote:
> > This patch adds the possibility to pass a of_node as platform_data which
> > is used by generic-pcm-dma to request a DMA slave channel.
> > 
> > Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
> > ---
> >  sound/soc/fsl/imx-pcm-dma.c | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> > 
> > diff --git a/sound/soc/fsl/imx-pcm-dma.c b/sound/soc/fsl/imx-pcm-dma.c
> > index c246fb5..8945d22 100644
> > --- a/sound/soc/fsl/imx-pcm-dma.c
> > +++ b/sound/soc/fsl/imx-pcm-dma.c
> > @@ -62,9 +62,11 @@ static const struct snd_dmaengine_pcm_config imx_dmaengine_pcm_config = {
> >  
> >  int imx_pcm_dma_init(struct platform_device *pdev)
> >  {
> > +	if (pdev->dev.platform_data)
> > +		pdev->dev.of_node = pdev->dev.platform_data;
> 
> In my opinion it's better to use pdev->dev.parent->of_node here. In the ssi
> driver you use platform_device_register_data, which will create a copy of
> the of_node you pass in as platform data. I'm not quite sure how well this
> will work. If you want to continue to use platform_data you should at least
> change the code in the ssi driver to not make a copy of the of_node.

Thanks, I did not think about using the parent, that is much easier. I
changed it for the next version.

Regards,

Markus

> 
> - Lars
> 
> > +
> >  	return snd_dmaengine_pcm_register(&pdev->dev, &imx_dmaengine_pcm_config,
> >  		SND_DMAENGINE_PCM_FLAG_NO_RESIDUE |
> > -		SND_DMAENGINE_PCM_FLAG_NO_DT |
> >  		SND_DMAENGINE_PCM_FLAG_COMPAT);
> >  }
> >  
> 
> 

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From linux at arm.linux.org.uk  Thu Apr 18 11:36:11 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Thu, 18 Apr 2013 16:36:11 +0100
Subject: [PATCH v2 1/2] ARM: shmobile: R8A7779: add Ether support
In-Reply-To: <201304042253.50662.sergei.shtylyov@cogentembedded.com>
References: <201304042253.50662.sergei.shtylyov@cogentembedded.com>
Message-ID: <20130418153611.GX14496@n2100.arm.linux.org.uk>

On Thu, Apr 04, 2013 at 10:53:50PM +0400, Sergei Shtylyov wrote:
> +/* Ether */
> +static struct resource ether_resources[] = {
> +	{
> +		.start	= 0xfde00000,
> +		.end	= 0xfde003ff,
> +		.flags	= IORESOURCE_MEM,
> +	}, {
> +		.start	= gic_iid(0xb4),
> +		.flags	= IORESOURCE_IRQ,
> +	},

There are macros for initializing these which have been around for a
few years now.  Please consider using them in future.


From cdall at cs.columbia.edu  Thu Apr 18 11:37:37 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Thu, 18 Apr 2013 08:37:37 -0700
Subject: [PATCH v3 5/7] ARM: KVM: rework HYP page table freeing
In-Reply-To: <f6de41fe392f15eb44e24d690c4a5ca4@localhost>
References: <1365779932-20322-1-git-send-email-marc.zyngier@arm.com>
 <1365779932-20322-6-git-send-email-marc.zyngier@arm.com>
 <CAEDV+gJAUOsi3yjwp3hmBPbLkaL_0PaUNGFLLZN0nOzya7BA-A@mail.gmail.com>
 <89815b00ef8a11e6fc7bc03497b9668a@localhost>
 <CAEDV+gJtHT7vyNLK1gNbNEzks0=ojZ7RoLGu3vW0CqVZreUnVg@mail.gmail.com>
 <f6de41fe392f15eb44e24d690c4a5ca4@localhost>
Message-ID: <CAEDV+gKnv8uu63-DHDSG10LWWFLojmEtf=NV-jOZ5YQhfeQYgQ@mail.gmail.com>

On Thu, Apr 18, 2013 at 12:13 AM, Marc Zyngier <marc.zyngier at arm.com> wrote:
> On Wed, 17 Apr 2013 22:23:21 -0700, Christoffer Dall
> <cdall at cs.columbia.edu> wrote:
>> On Mon, Apr 15, 2013 at 1:00 AM, Marc Zyngier <marc.zyngier at arm.com>
> wrote:
>>
>>> On Sun, 14 Apr 2013 23:51:55 -0700, Christoffer Dall
>>> <cdall at cs.columbia.edu> wrote:
>>> > On Fri, Apr 12, 2013 at 8:18 AM, Marc Zyngier <marc.zyngier at arm.com>
>>> wrote:
>>> >> There is no point in freeing HYP page tables differently from
> Stage-2.
>>> >> They now have the same requirements, and should be dealt with the
> same
>>> >> way.
>>> >>
>>> >> Promote unmap_stage2_range to be The One True Way, and get rid of a
>>> >> number
>>> >> of nasty bugs in the process (goo thing we never actually called
>>> >> free_hyp_pmds
>>> >
>>> > could you remind me, did you already point out these nasty bugs
>>> > somewhere or did we discuss them in an older thread?
>>>
>>> No, I decided it wasn't worth the hassle when I spotted them (specially
>>> as
>>> we're moving away from section mapped idmap)... But for the record:
>>>
>>> <quote>
>>> static void free_hyp_pgd_entry(pgd_t *pgdp, unsigned long addr)
>>> {
>>>         pgd_t *pgd;
>>>         pud_t *pud;
>>>         pmd_t *pmd;
>>>
>>>         pgd = pgdp + pgd_index(addr);
>>>         pud = pud_offset(pgd, addr);
>>>
>>>         if (pud_none(*pud))
>>>                 return;
>>>         BUG_ON(pud_bad(*pud));
>>>
>>>         pmd = pmd_offset(pud, addr);
>>>         free_ptes(pmd, addr);
>>>         pmd_free(NULL, pmd);
>>>         ^^^^^^^^^^^^^^^^^^^^<-- BUG_ON(pmd not page aligned)
>>>
>>
>> This would never be non-page-aligned for Hyp page tables where PMDs are
>> always 4K in size, that was the assumption.
>
> Well, look at the pmd variable. As the result of pmd_offset(), it gives
> you a pointer to a PMD *entry*, not to a PMD *page*. This entry can be
> anywhere in that page, depending on the 2M section in a 1GB table.
>
>>
>>>         pud_clear(pud);
>>> }
>>> </quote>
>>>
>>> Now, if you decide to fix the above by forcing the page alignment:
>>>
>>> <quote>
>>> static void free_ptes(pmd_t *pmd, unsigned long addr)
>>> {
>>>         pte_t *pte;
>>>         unsigned int i;
>>>
>>>         for (i = 0; i < PTRS_PER_PMD; i++, addr += PMD_SIZE) {
>>>              ^^^^^^^^^^^^^<-- start freeing memory outside of the
>>> (unaligned) pmd...
>>>
>>
>> freeing what outside the pmd? I don't see this.
>
> Remember the above (PMD entry vs PMD page)? This code assumes it gets a
> PMD page. To work properly, it would read:
>            for (i = pmd_index(addr); i < PTRS_PER_PMDs; ....
>

ok, but prior to the whole trampoline stuff it was never called that
way. But this code was definitely written to be called in a much too
specific situation.

>>
>>>                 if (!pmd_none(*pmd) && pmd_table(*pmd)) {
>>>                         pte = pte_offset_kernel(pmd, addr);
>>>                         pte_free_kernel(NULL, pte);
>>>                 }
>>>                 pmd++;
>>>         }
>>> }
>>> </quote>
>>>
>>> Once you've fixed that as well, you end up noticing that if you have
> PTEs
>>> pointed to by the same PMD, you need to introduce some refcounting if
> you
>>> need to free one PTE and not the others.
>>>
>>
>> huh? the code always freed all the hyp tables and there would be no
> sharing
>> of ptes across multiple pmds. I'm confused.
>
> Not anymore. In non HOTPLUG_CPU case, we free the trampoline page from the
> runtime HYP page tables (it is worth it if we had to use a bounce page). If
> you free an entire PMD, odds are you'll also unmap some of the HYP code
> (been there...).
>

yes, that was not supported before, it was merely a teardown mechanism
for the error path (and module unloading back when we had that).

>> For the record, I like your patch and we should definitely only have one
>> path of allocating and freeing the tables, but if my code was buggy I
> want
>> to learn from my mistakes and know exactly what went bad.
>
> Well, I hope I made clear what the problem was. The main reason we didn't
> notice this is because this code was only called on the error path, which
> is mostly untested.
>

I think it actually worked in the way we were calling it, certainly
when I was using kvm/arm as a module and unloading the module things
worked just fine.  But yeah, way too fragile.

Thanks for taking the time to explain.

>>>
>>> At this point, I had enough, and decided to reuse what we already had
>>> instead of reinventing the wheel.
>>
>>
>>> > nit: s/goo/good/
>>> >
>>> >> before...).
>>>
>>> Will fix.
>>>
>>
>> I made the adjustment in my queue so you don't need to send out a new
>> series, unless you want to do that for other reasons.
>
> No particular reason, no. Unless people have additional comments that
> would require a new version of the series.
>
> Thanks,
>
>         M.
> --
> Fast, cheap, reliable. Pick two.


From andrew.murray at arm.com  Thu Apr 18 11:38:03 2013
From: andrew.murray at arm.com (Andrew Murray)
Date: Thu, 18 Apr 2013 16:38:03 +0100
Subject: [PATCH v7 2/3] of/pci: Provide support for parsing PCI DT
 ranges property
In-Reply-To: <CACxGe6u7yoecyTR2r-EzpcRxLuSw-p9KC7jA12wEQZs4of3vFA@mail.gmail.com>
References: <1366107508-12672-1-git-send-email-Andrew.Murray@arm.com>
 <1366107508-12672-3-git-send-email-Andrew.Murray@arm.com>
 <20130418134401.84AEE3E1319@localhost>
 <20130418142434.GA18881@arm.com>
 <CACxGe6u7yoecyTR2r-EzpcRxLuSw-p9KC7jA12wEQZs4of3vFA@mail.gmail.com>
Message-ID: <20130418153803.GA19373@arm.com>

On Thu, Apr 18, 2013 at 04:29:54PM +0100, Grant Likely wrote:
> On Thu, Apr 18, 2013 at 3:24 PM, Andrew Murray <andrew.murray at arm.com> wrote:
> > On Thu, Apr 18, 2013 at 02:44:01PM +0100, Grant Likely wrote:
> >> On Tue, 16 Apr 2013 11:18:27 +0100, Andrew Murray <Andrew.Murray at arm.com> wrote:
> >> >             /* Act based on address space type */
> >> >             res = NULL;
> >> > -           switch ((pci_space >> 24) & 0x3) {
> >> > -           case 1:         /* PCI IO space */
> >> > +           res_type = range.flags & IORESOURCE_TYPE_BITS;
> >> > +           if (res_type == IORESOURCE_IO) {
> >>
> >> Why the change from switch() to an if/else if sequence?
> >
> > Russell King suggested this change - see
> > https://patchwork.kernel.org/patch/2323941/
> 
> Umm, that isn't what that link shows. That link shows the patch
> already changing to an if/else if construct, and rmk is commenting on
> that.

Arh yes sorry about that. I can't find or remember any good reason why I
changed it from a switch to an if/else :\

Andrew Murray


From alexandre.belloni at free-electrons.com  Thu Apr 18 11:38:53 2013
From: alexandre.belloni at free-electrons.com (Alexandre Belloni)
Date: Thu, 18 Apr 2013 17:38:53 +0200
Subject: [PATCH 0/3] Add support for the Nuvoton NAU7802 ADC to the cfa10049
Message-ID: <1366299536-18353-1-git-send-email-alexandre.belloni@free-electrons.com>

Hi,

This patchset adds support for the 3 Nuvoton NAU7802 ADCs presetn on the
CFA-10049 board from Crystalfontz. The first patch adds the driver, the next
ones are adding them in the DT after switching the second i2c bus to bitbanging
following a lot of timeout issues we have on that bus.

Regards,

Alexandre Belloni (1):
  iio: Add Nuvoton NAU7802 ADC driver

Maxime Ripard (2):
  ARM: mxs: cfa10049: Switch bus i2c1 to bitbanging
  ARM: mxs: cfa10049: Add NAU7802 ADCs to the device tree

 .../bindings/iio/adc/nuvoton-nau7802.txt           |   17 +
 arch/arm/boot/dts/imx28-cfa10049.dts               |  126 ++--
 drivers/iio/adc/Kconfig                            |    9 +
 drivers/iio/adc/Makefile                           |    1 +
 drivers/iio/adc/nau7802.c                          |  644 ++++++++++++++++++++
 5 files changed, 754 insertions(+), 43 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/iio/adc/nuvoton-nau7802.txt
 create mode 100644 drivers/iio/adc/nau7802.c

-- 
1.7.10.4



From alexandre.belloni at free-electrons.com  Thu Apr 18 11:38:55 2013
From: alexandre.belloni at free-electrons.com (Alexandre Belloni)
Date: Thu, 18 Apr 2013 17:38:55 +0200
Subject: [PATCH 2/3] ARM: mxs: cfa10049: Switch bus i2c1 to bitbanging
In-Reply-To: <1366299536-18353-1-git-send-email-alexandre.belloni@free-electrons.com>
References: <1366299536-18353-1-git-send-email-alexandre.belloni@free-electrons.com>
Message-ID: <1366299536-18353-3-git-send-email-alexandre.belloni@free-electrons.com>

From: Maxime Ripard <maxime.ripard at free-electrons.com>

The ADCs connected to this bus have been experiencing some timeout
issues when using the iMX28 i2c controller. Switching back to bitbanging
solves this.

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 arch/arm/boot/dts/imx28-cfa10049.dts |  108 ++++++++++++++++++++--------------
 1 file changed, 65 insertions(+), 43 deletions(-)

diff --git a/arch/arm/boot/dts/imx28-cfa10049.dts b/arch/arm/boot/dts/imx28-cfa10049.dts
index 79a2007..a333dbf 100644
--- a/arch/arm/boot/dts/imx28-cfa10049.dts
+++ b/arch/arm/boot/dts/imx28-cfa10049.dts
@@ -138,6 +138,17 @@
 					fsl,voltage = <1>;
 					fsl,pull-up = <0>; /* 0 will enable the keeper */
 				};
+
+				i2c1_pins_cfa10049: i2c1 at 0 {
+					reg = <0>;
+					fsl,pinmux-ids = <
+						0x3103 /* MX28_PAD_PWM0__GPIO */
+						0x3113 /* MX28_PAD_PWM1__I2C1_SDA */
+					>;
+					fsl,drive-strength = <1>;
+					fsl,voltage = <1>;
+					fsl,pull-up = <1>;
+				};
 			};
 
 			lcdif at 80030000 {
@@ -155,49 +166,6 @@
 				status = "okay";
 			};
 
-			i2c1: i2c at 8005a000 {
-				pinctrl-names = "default";
-				pinctrl-0 = <&i2c1_pins_a>;
-				status = "okay";
-			};
-
-			i2cmux {
-				compatible = "i2c-mux-gpio";
-				#address-cells = <1>;
-				#size-cells = <0>;
-				mux-gpios = <&gpio1 22 0 &gpio1 23 0>;
-				i2c-parent = <&i2c1>;
-
-				i2c at 0 {
-					reg = <0>;
-				};
-
-				i2c at 1 {
-					reg = <1>;
-				};
-
-				i2c at 2 {
-					reg = <2>;
-				};
-
-				i2c at 3 {
-					reg = <3>;
-					#address-cells = <1>;
-					#size-cells = <0>;
-
-					pca9555: pca9555 at 20 {
-						compatible = "nxp,pca9555";
-						interrupt-parent = <&gpio2>;
-						interrupts = <19 0x2>;
-						gpio-controller;
-						#gpio-cells = <2>;
-						interrupt-controller;
-						#interrupt-cells = <2>;
-						reg = <0x20>;
-					};
-				};
-			};
-
 			usbphy1: usbphy at 8007e000 {
 				status = "okay";
 			};
@@ -322,6 +290,60 @@
 		rotary-encoder,relative-axis;
 	};
 
+	i2c1gpio: i2c at 0 {
+		compatible = "i2c-gpio";
+		pinctrl-0 = <&i2c1_pins_cfa10049>;
+		pinctrl-names = "default";
+		gpios = <
+			&gpio3 17 0 /* sda */
+			&gpio3 16 0 /* scl */
+			 >;
+		i2c-gpio,delay-us = <2>;	/* ~100 kHz */
+	};
+
+	i2cmux {
+		compatible = "i2c-mux-gpio";
+		#address-cells = <1>;
+		#size-cells = <0>;
+		mux-gpios = <&gpio1 22 0 &gpio1 23 0>;
+		i2c-parent = <&i2c1gpio>;
+
+		i2c at 0 {
+			reg = <0>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+
+		i2c at 1 {
+			reg = <1>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+
+		i2c at 2 {
+			reg = <2>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+
+		i2c at 3 {
+			reg = <3>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			pca9555: pca9555 at 20 {
+				compatible = "nxp,pca9555";
+				interrupt-parent = <&gpio2>;
+				interrupts = <19 0x2>;
+				gpio-controller;
+				#gpio-cells = <2>;
+				interrupt-controller;
+				#interrupt-cells = <2>;
+				reg = <0x20>;
+			};
+		};
+	};
+
 	backlight {
 		compatible = "pwm-backlight";
 		pwms = <&pwm 3 5000000>;
-- 
1.7.10.4



From alexandre.belloni at free-electrons.com  Thu Apr 18 11:38:56 2013
From: alexandre.belloni at free-electrons.com (Alexandre Belloni)
Date: Thu, 18 Apr 2013 17:38:56 +0200
Subject: [PATCH 3/3] ARM: mxs: cfa10049: Add NAU7802 ADCs to the device tree
In-Reply-To: <1366299536-18353-1-git-send-email-alexandre.belloni@free-electrons.com>
References: <1366299536-18353-1-git-send-email-alexandre.belloni@free-electrons.com>
Message-ID: <1366299536-18353-4-git-send-email-alexandre.belloni@free-electrons.com>

From: Maxime Ripard <maxime.ripard at free-electrons.com>

Since these ADCs share the same non-configurable address on the I2C bus,
they have to be put behind a muxer.

Signed-off-by: Alexandre Belloni <alexandre.belloni at free-electrons.com>
Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 arch/arm/boot/dts/imx28-cfa10049.dts |   18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/arch/arm/boot/dts/imx28-cfa10049.dts b/arch/arm/boot/dts/imx28-cfa10049.dts
index a333dbf..23166d9 100644
--- a/arch/arm/boot/dts/imx28-cfa10049.dts
+++ b/arch/arm/boot/dts/imx28-cfa10049.dts
@@ -312,18 +312,36 @@
 			reg = <0>;
 			#address-cells = <1>;
 			#size-cells = <0>;
+
+			adc0: nau7802 at 2a {
+				compatible = "nuvoton,nau7802";
+				reg = <0x2a>;
+				nuvoton,vldo = <3000>;
+			};
 		};
 
 		i2c at 1 {
 			reg = <1>;
 			#address-cells = <1>;
 			#size-cells = <0>;
+
+			adc1: nau7802 at 2a {
+				compatible = "nuvoton,nau7802";
+				reg = <0x2a>;
+				nuvoton,vldo = <3000>;
+			};
 		};
 
 		i2c at 2 {
 			reg = <2>;
 			#address-cells = <1>;
 			#size-cells = <0>;
+
+			adc2: nau7802 at 2a {
+				compatible = "nuvoton,nau7802";
+				reg = <0x2a>;
+				nuvoton,vldo = <3000>;
+			};
 		};
 
 		i2c at 3 {
-- 
1.7.10.4



From alexandre.belloni at free-electrons.com  Thu Apr 18 11:38:54 2013
From: alexandre.belloni at free-electrons.com (Alexandre Belloni)
Date: Thu, 18 Apr 2013 17:38:54 +0200
Subject: [PATCH 1/3] iio: Add Nuvoton NAU7802 ADC driver
In-Reply-To: <1366299536-18353-1-git-send-email-alexandre.belloni@free-electrons.com>
References: <1366299536-18353-1-git-send-email-alexandre.belloni@free-electrons.com>
Message-ID: <1366299536-18353-2-git-send-email-alexandre.belloni@free-electrons.com>

The Nuvoton NAU7802 ADC is a 24-bit 2-channels I2C ADC, with adjustable
gain and sampling rates.

Signed-off-by: Alexandre Belloni <alexandre.belloni at free-electrons.com>
Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 .../bindings/iio/adc/nuvoton-nau7802.txt           |   17 +
 drivers/iio/adc/Kconfig                            |    9 +
 drivers/iio/adc/Makefile                           |    1 +
 drivers/iio/adc/nau7802.c                          |  644 ++++++++++++++++++++
 4 files changed, 671 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iio/adc/nuvoton-nau7802.txt
 create mode 100644 drivers/iio/adc/nau7802.c

diff --git a/Documentation/devicetree/bindings/iio/adc/nuvoton-nau7802.txt b/Documentation/devicetree/bindings/iio/adc/nuvoton-nau7802.txt
new file mode 100644
index 0000000..9bc4218
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/nuvoton-nau7802.txt
@@ -0,0 +1,17 @@
+* Nuvoton NAU7802 Analog to Digital Converter (ADC)
+
+Required properties:
+  - compatible: Should be "nuvoton,nau7802"
+  - reg: Should contain the ADC I2C address
+
+Optional properties:
+  - nuvoton,vldo: Reference voltage in millivolts (integer)
+  - interrupts: IRQ line for the ADC. If not used the driver will use
+    polling.
+
+Example:
+adc2: nau7802 at 2a {
+	compatible = "nuvoton,nau7802";
+	reg = <0x2a>;
+	nuvoton,vldo = <3000>;
+};
diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index e372257..ed3059a 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -113,6 +113,15 @@ config MAX1363
 	  max11646, max11647) Provides direct access via sysfs and buffered
 	  data via the iio dev interface.
 
+config NAU7802
+	tristate "Nuvoton NAU7802 ADC driver"
+	depends on I2C
+	help
+	  Say yes here to build support for Nuvoton NAU7802 ADC.
+
+	  To compile this driver as a module, choose M here: the
+	  module will be called nau7802.
+
 config TI_ADC081C
 	tristate "Texas Instruments ADC081C021/027"
 	depends on I2C
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index 2d5f100..a02150d 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_AD7887) += ad7887.o
 obj-$(CONFIG_AT91_ADC) += at91_adc.o
 obj-$(CONFIG_LP8788_ADC) += lp8788_adc.o
 obj-$(CONFIG_MAX1363) += max1363.o
+obj-$(CONFIG_NAU7802) += nau7802.o
 obj-$(CONFIG_TI_ADC081C) += ti-adc081c.o
 obj-$(CONFIG_TI_AM335X_ADC) += ti_am335x_adc.o
 obj-$(CONFIG_VIPERBOARD_ADC) += viperboard_adc.o
diff --git a/drivers/iio/adc/nau7802.c b/drivers/iio/adc/nau7802.c
new file mode 100644
index 0000000..0148fd8
--- /dev/null
+++ b/drivers/iio/adc/nau7802.c
@@ -0,0 +1,644 @@
+/*
+ * Driver for the Nuvoton NAU7802 ADC
+ *
+ * Copyright 2013 Free Electrons
+ *
+ * Licensed under the GPLv2 or later.
+ */
+
+#include <linux/delay.h>
+#include <linux/i2c.h>
+#include <linux/interrupt.h>
+#include <linux/module.h>
+#include <linux/wait.h>
+#include <linux/of_irq.h>
+#include <linux/log2.h>
+
+#include <linux/iio/iio.h>
+#include <linux/iio/sysfs.h>
+
+#define NAU7802_REG_PUCTRL	0x00
+#define NAU7802_PUCTRL_RR(x)		(x << 0)
+#define NAU7802_PUCTRL_RR_BIT		NAU7802_PUCTRL_RR(1)
+#define NAU7802_PUCTRL_PUD(x)		(x << 1)
+#define NAU7802_PUCTRL_PUD_BIT		NAU7802_PUCTRL_PUD(1)
+#define NAU7802_PUCTRL_PUA(x)		(x << 2)
+#define NAU7802_PUCTRL_PUA_BIT		NAU7802_PUCTRL_PUA(1)
+#define NAU7802_PUCTRL_PUR(x)		(x << 3)
+#define NAU7802_PUCTRL_PUR_BIT		NAU7802_PUCTRL_PUR(1)
+#define NAU7802_PUCTRL_CS(x)		(x << 4)
+#define NAU7802_PUCTRL_CS_BIT		NAU7802_PUCTRL_CS(1)
+#define NAU7802_PUCTRL_CR(x)		(x << 5)
+#define NAU7802_PUCTRL_CR_BIT		NAU7802_PUCTRL_CR(1)
+#define NAU7802_PUCTRL_AVDDS(x)		(x << 7)
+#define NAU7802_PUCTRL_AVDDS_BIT	NAU7802_PUCTRL_AVDDS(1)
+#define NAU7802_REG_CTRL1	0x01
+#define NAU7802_CTRL1_VLDO(x)		(x << 3)
+#define NAU7802_CTRL1_GAINS(x)		(x)
+#define NAU7802_CTRL1_GAINS_BITS	0x07
+#define NAU7802_REG_CTRL2	0x02
+#define NAU7802_CTRL2_CHS(x)		(x << 7)
+#define NAU7802_CTRL2_CRS(x)		(x << 4)
+#define NAU7802_CTRL2_CHS_BIT		NAU7802_CTRL2_CHS(1)
+#define NAU7802_REG_ADC_B2	0x12
+#define NAU7802_REG_ADC_B1	0x13
+#define NAU7802_REG_ADC_B0	0x14
+#define NAU7802_REG_ADC_CTRL	0x15
+
+struct nau7802_state {
+	struct i2c_client	*client;
+	s32			last_value;
+	struct mutex		lock;
+	struct mutex		data_lock;
+	u32			vref_mv;
+	u32			conversion_count;
+	u32			min_conversions;
+	u8			sample_rate;
+	struct completion	value_ok;
+};
+
+static int nau7802_i2c_read(struct nau7802_state *st, u8 reg, u8 *data)
+{
+	int ret = 0;
+
+	ret = i2c_smbus_read_byte_data(st->client, reg);
+	if (ret < 0) {
+		dev_err(&st->client->dev, "failed to read from I2C\n");
+		return ret;
+	}
+
+	*data = ret;
+
+	return 0;
+}
+
+static int nau7802_i2c_write(struct nau7802_state *st, u8 reg, u8 data)
+{
+	return i2c_smbus_write_byte_data(st->client, reg, data);
+}
+
+static const u16 nau7802_sample_freq_avail[] = {10, 20, 40, 80,
+						10, 10, 10, 320};
+
+static ssize_t nau7802_sysfs_set_sampling_frequency(struct device *dev,
+		struct device_attribute *attr,
+		const char *buf,
+		size_t len)
+{
+	struct iio_dev *idev = dev_to_iio_dev(dev);
+	struct nau7802_state *st = iio_priv(idev);
+	u32 val;
+	int ret, i;
+
+	ret = kstrtouint(buf, 10, &val);
+	if (ret)
+		return ret;
+
+	ret = -EINVAL;
+	for (i = 0; i < 8; i++)
+		if (val == nau7802_sample_freq_avail[i]) {
+			mutex_lock(&st->lock);
+			st->sample_rate = i;
+			st->conversion_count = 0;
+			nau7802_i2c_write(st, NAU7802_REG_CTRL2,
+					NAU7802_CTRL2_CRS(st->sample_rate));
+			mutex_unlock(&st->lock);
+			ret = len;
+			break;
+		}
+	return ret;
+}
+
+static ssize_t nau7802_sysfs_get_sampling_frequency(struct device *dev,
+		struct device_attribute *attr,
+		char *buf)
+{
+	struct iio_dev *idev = dev_to_iio_dev(dev);
+	struct nau7802_state *st = iio_priv(idev);
+
+	return sprintf(buf, "%d\n",
+	       nau7802_sample_freq_avail[st->sample_rate]);
+}
+
+static IIO_DEV_ATTR_SAMP_FREQ(S_IWUSR | S_IRUGO,
+		nau7802_sysfs_get_sampling_frequency,
+		nau7802_sysfs_set_sampling_frequency);
+
+static IIO_CONST_ATTR_SAMP_FREQ_AVAIL("10 40 80 320");
+
+static IIO_CONST_ATTR(gain_available, "1 2 4 8 16 32 64 128");
+
+static ssize_t nau7802_sysfs_set_gain(struct device *dev,
+		struct device_attribute *attr,
+		const char *buf,
+		size_t len)
+{
+	struct iio_dev *idev = dev_to_iio_dev(dev);
+	struct nau7802_state *st = iio_priv(idev);
+	u32 val;
+	u8 data;
+	int ret;
+
+	ret = kstrtouint(buf, 10, &val);
+	if (ret)
+		return ret;
+
+	if (val < 1 || val > 128 || !is_power_of_2(val))
+		return -EINVAL;
+
+	mutex_lock(&st->lock);
+	st->conversion_count = 0;
+
+	ret = nau7802_i2c_read(st, NAU7802_REG_CTRL1, &data);
+	if (ret < 0)
+		goto nau7802_sysfs_set_gain_out;
+	ret = nau7802_i2c_write(st, NAU7802_REG_CTRL1,
+			(data & (~NAU7802_CTRL1_GAINS_BITS)) | ilog2(val));
+nau7802_sysfs_set_gain_out:
+	mutex_unlock(&st->lock);
+	return ret ? ret : len;
+}
+
+static ssize_t nau7802_sysfs_get_gain(struct device *dev,
+		struct device_attribute *attr,
+		char *buf)
+{
+	struct iio_dev *idev = dev_to_iio_dev(dev);
+	struct nau7802_state *st = iio_priv(idev);
+	u8 data;
+	int ret;
+
+	ret = nau7802_i2c_read(st, NAU7802_REG_CTRL1, &data);
+	if (ret < 0)
+		return ret;
+
+	return sprintf(buf, "%d\n", 1 << (data & NAU7802_CTRL1_GAINS_BITS));
+}
+
+static IIO_DEVICE_ATTR(gain, S_IWUSR | S_IRUGO,
+		nau7802_sysfs_get_gain,
+		nau7802_sysfs_set_gain, 0);
+
+static ssize_t nau7802_sysfs_set_min_conversions(struct device *dev,
+		struct device_attribute *attr,
+		const char *buf,
+		size_t len)
+{
+	struct iio_dev *idev = dev_to_iio_dev(dev);
+	struct nau7802_state *st = iio_priv(idev);
+	u32 val;
+	int ret;
+
+	ret = kstrtouint(buf, 10, &val);
+	if (ret)
+		return ret;
+
+	mutex_lock(&st->lock);
+	st->min_conversions = val;
+	st->conversion_count = 0;
+	mutex_unlock(&st->lock);
+	return len;
+}
+
+static ssize_t nau7802_sysfs_get_min_conversions(struct device *dev,
+		struct device_attribute *attr,
+		char *buf)
+{
+	struct iio_dev *idev = dev_to_iio_dev(dev);
+	struct nau7802_state *st = iio_priv(idev);
+
+	return sprintf(buf, "%d\n", st->min_conversions);
+}
+
+static IIO_DEVICE_ATTR(min_conversions, S_IWUSR | S_IRUGO,
+		nau7802_sysfs_get_min_conversions,
+		nau7802_sysfs_set_min_conversions, 0);
+
+static struct attribute *nau7802_attributes[] = {
+	&iio_dev_attr_sampling_frequency.dev_attr.attr,
+	&iio_const_attr_sampling_frequency_available.dev_attr.attr,
+	&iio_dev_attr_gain.dev_attr.attr,
+	&iio_const_attr_gain_available.dev_attr.attr,
+	&iio_dev_attr_min_conversions.dev_attr.attr,
+	NULL
+};
+
+static const struct attribute_group nau7802_attribute_group = {
+	.attrs = nau7802_attributes,
+};
+
+static int nau7802_read_conversion(struct nau7802_state *st)
+{
+	int ret;
+	u8 data;
+
+	mutex_lock(&st->data_lock);
+	ret = nau7802_i2c_read(st, NAU7802_REG_ADC_B2, &data);
+	if (ret)
+		goto nau7802_read_conversion_out;
+	st->last_value = data << 24;
+
+	ret = nau7802_i2c_read(st, NAU7802_REG_ADC_B1, &data);
+	if (ret)
+		goto nau7802_read_conversion_out;
+	st->last_value |= data << 16;
+
+	ret = nau7802_i2c_read(st, NAU7802_REG_ADC_B0, &data);
+	if (ret)
+		goto nau7802_read_conversion_out;
+	st->last_value |= data << 8;
+
+	st->last_value >>= 8;
+
+nau7802_read_conversion_out:
+	mutex_unlock(&st->data_lock);
+	return ret;
+}
+
+static int nau7802_sync(struct nau7802_state *st)
+{
+	int ret;
+	u8 data;
+
+	ret = nau7802_i2c_read(st, NAU7802_REG_PUCTRL, &data);
+	if (ret)
+		return ret;
+	ret = nau7802_i2c_write(st, NAU7802_REG_PUCTRL,
+				data | NAU7802_PUCTRL_CS_BIT);
+	return ret;
+}
+
+static irqreturn_t nau7802_eoc_trigger(int irq, void *private)
+{
+	struct iio_dev *idev = private;
+	struct nau7802_state *st = iio_priv(idev);
+	u8 status;
+	int ret;
+
+	ret = nau7802_i2c_read(st, NAU7802_REG_PUCTRL, &status);
+	if (ret)
+		return IRQ_HANDLED;
+
+	if (!(status & NAU7802_PUCTRL_CR_BIT))
+		return IRQ_NONE;
+
+	if (nau7802_read_conversion(st))
+		return IRQ_HANDLED;
+
+	/* wait for enough conversions before getting a stable value when
+	 * changing channels */
+	if (st->conversion_count < st->min_conversions)
+		st->conversion_count++;
+	if (st->conversion_count >= st->min_conversions)
+		complete_all(&st->value_ok);
+	return IRQ_HANDLED;
+}
+
+static int nau7802_read_irq(struct iio_dev *idev,
+			struct iio_chan_spec const *chan,
+			int *val)
+{
+	struct nau7802_state *st = iio_priv(idev);
+	int ret;
+
+	INIT_COMPLETION(st->value_ok);
+	enable_irq(st->client->irq);
+
+	nau7802_sync(st);
+
+	/* read registers to ensure we flush everything */
+	ret = nau7802_read_conversion(st);
+	if (ret)
+		goto read_chan_info_failure;
+
+	/* Wait for a conversion to finish */
+	ret = wait_for_completion_interruptible_timeout(&st->value_ok,
+			msecs_to_jiffies(1000));
+	if (ret == 0)
+		ret = -ETIMEDOUT;
+
+	if (ret < 0)
+		goto read_chan_info_failure;
+
+	disable_irq(st->client->irq);
+
+	*val = st->last_value;
+	return IIO_VAL_INT;
+
+read_chan_info_failure:
+	disable_irq(st->client->irq);
+	return ret;
+}
+
+static int nau7802_read_poll(struct iio_dev *idev,
+			struct iio_chan_spec const *chan,
+			int *val)
+{
+	struct nau7802_state *st = iio_priv(idev);
+	int ret;
+	u8 data;
+
+	nau7802_sync(st);
+
+	/* read registers to ensure we flush everything */
+	ret = nau7802_read_conversion(st);
+	if (ret)
+		return ret;
+
+	do {
+		nau7802_i2c_read(st, NAU7802_REG_PUCTRL, &data);
+		if (ret)
+			return ret;
+		while (!(data & NAU7802_PUCTRL_CR_BIT)) {
+			if (st->sample_rate != 0x07)
+				msleep(20);
+			else
+				mdelay(4);
+			nau7802_i2c_read(st, NAU7802_REG_PUCTRL, &data);
+			if (ret)
+				return ret;
+		}
+
+		nau7802_read_conversion(st);
+		if (ret)
+			return ret;
+		if (st->conversion_count < st->min_conversions)
+			st->conversion_count++;
+	} while (st->conversion_count < st->min_conversions);
+
+	*val = st->last_value;
+	return IIO_VAL_INT;
+}
+
+static int nau7802_read_raw(struct iio_dev *idev,
+			    struct iio_chan_spec const *chan,
+			    int *val, int *val2, long mask)
+{
+	struct nau7802_state *st = iio_priv(idev);
+	u8 data;
+	int ret;
+
+	switch (mask) {
+	case IIO_CHAN_INFO_RAW:
+		mutex_lock(&st->lock);
+		/*
+		 * Select the channel to use
+		 *   - Channel 1 is value 0 in the CHS register
+		 *   - Channel 2 is value 1 in the CHS register
+		 */
+		ret = nau7802_i2c_read(st, NAU7802_REG_CTRL2, &data);
+		if (ret < 0)
+			return ret;
+		if (((data & NAU7802_CTRL2_CHS_BIT) && !chan->channel) ||
+				(!(data & NAU7802_CTRL2_CHS_BIT) &&
+				 chan->channel)) {
+			st->conversion_count = 0;
+			ret = nau7802_i2c_write(st, NAU7802_REG_CTRL2,
+					NAU7802_CTRL2_CHS(chan->channel) |
+					NAU7802_CTRL2_CRS(st->sample_rate));
+			if (ret < 0)
+				return ret;
+		}
+
+		if (st->client->irq)
+			ret = nau7802_read_irq(idev, chan, val);
+		else
+			ret = nau7802_read_poll(idev, chan, val);
+
+		mutex_unlock(&st->lock);
+		return ret;
+	case IIO_CHAN_INFO_SCALE:
+		ret = nau7802_i2c_read(st, NAU7802_REG_CTRL1, &data);
+		if (ret < 0)
+			return ret;
+
+		*val = 0;
+		*val2 = (((u64)st->vref_mv) * 1000000000ULL) >>
+			(chan->scan_type.realbits +
+			 (data & NAU7802_CTRL1_GAINS_BITS));
+		return IIO_VAL_INT_PLUS_MICRO;
+	default:
+		break;
+	}
+	return -EINVAL;
+}
+
+static const struct iio_info nau7802_info = {
+	.driver_module = THIS_MODULE,
+	.read_raw = &nau7802_read_raw,
+	.attrs = &nau7802_attribute_group,
+};
+
+static int nau7802_channel_init(struct iio_dev *idev)
+{
+	struct iio_chan_spec *chan_array;
+	int i;
+
+	idev->num_channels = 2;
+
+	chan_array = devm_kzalloc(&idev->dev,
+				  sizeof(*chan_array) * idev->num_channels,
+				  GFP_KERNEL);
+
+	for (i = 0; i < idev->num_channels; i++) {
+		struct iio_chan_spec *chan = chan_array + i;
+
+		chan->type = IIO_VOLTAGE;
+		chan->indexed = 1;
+		chan->channel = i;
+		chan->scan_index = i;
+		chan->scan_type.sign = 's';
+		chan->scan_type.realbits = 23;
+		chan->scan_type.storagebits = 24;
+		chan->info_mask = IIO_CHAN_INFO_SCALE_SHARED_BIT |
+			IIO_CHAN_INFO_RAW_SEPARATE_BIT;
+	}
+	idev->channels = chan_array;
+
+	return idev->num_channels;
+}
+
+static int nau7802_probe(struct i2c_client *client,
+			const struct i2c_device_id *id)
+{
+	struct iio_dev *idev;
+	struct nau7802_state *st;
+	struct device_node *np = client->dev.of_node;
+	int ret;
+	u8 data;
+	u32 tmp;
+
+	if (!client->dev.of_node) {
+		dev_err(&client->dev, "No device tree node available.\n");
+		return -EINVAL;
+	}
+
+	/*
+	 * If we have some interrupts declared, use them, if not, fall back
+	 * on polling.
+	 */
+	if (of_find_property(np, "interrupts", NULL)) {
+		if (client->irq <= 0) {
+			client->irq = irq_of_parse_and_map(np, 0);
+			if (client->irq <= 0)
+				return -EPROBE_DEFER;
+		}
+	} else
+		client->irq = 0;
+
+	idev = iio_device_alloc(sizeof(struct nau7802_state));
+	if (idev == NULL)
+		return -ENOMEM;
+
+	st = iio_priv(idev);
+
+	i2c_set_clientdata(client, idev);
+
+	idev->dev.parent = &client->dev;
+	idev->name = dev_name(&client->dev);
+	idev->modes = INDIO_DIRECT_MODE;
+	idev->info = &nau7802_info;
+
+	st->client = client;
+
+	/* Reset the device */
+	nau7802_i2c_write(st, NAU7802_REG_PUCTRL, NAU7802_PUCTRL_RR_BIT);
+
+	/* Enter normal operation mode */
+	nau7802_i2c_write(st, NAU7802_REG_PUCTRL, NAU7802_PUCTRL_PUD_BIT);
+
+	/*
+	 * After about 200 usecs, the device should be ready and then
+	 * the Power Up bit will be set to 1. If not, wait for it.
+	 */
+	do {
+		udelay(200);
+		ret = nau7802_i2c_read(st, NAU7802_REG_PUCTRL, &data);
+		if (ret)
+			return -ENODEV;
+	} while (!(data & NAU7802_PUCTRL_PUR_BIT));
+
+	of_property_read_u32(np, "nuvoton,vldo", &tmp);
+	st->vref_mv = tmp;
+
+	data = NAU7802_PUCTRL_PUD_BIT | NAU7802_PUCTRL_PUA_BIT |
+		NAU7802_PUCTRL_CS_BIT;
+	if (tmp >= 2400)
+		data |= NAU7802_PUCTRL_AVDDS_BIT;
+
+	nau7802_i2c_write(st, NAU7802_REG_PUCTRL, data);
+	nau7802_i2c_write(st, NAU7802_REG_ADC_CTRL, 0x30);
+
+	if (tmp >= 2400) {
+		data = NAU7802_CTRL1_VLDO((4500 - tmp) / 300);
+		nau7802_i2c_write(st, NAU7802_REG_CTRL1, data);
+	}
+
+	st->min_conversions = 6;
+
+	/*
+	 * The ADC fires continuously and we can't do anything about
+	 * it. So we need to have the IRQ disabled by default, and we
+	 * will enable them back when we will need them..
+	 */
+	if (client->irq) {
+		irq_set_status_flags(client->irq, IRQ_NOAUTOEN);
+		ret = request_threaded_irq(client->irq,
+				NULL,
+				nau7802_eoc_trigger,
+				IRQF_TRIGGER_HIGH | IRQF_ONESHOT,
+				client->dev.driver->name,
+				idev);
+		if (ret) {
+			/*
+			 * What may happen here is that our IRQ controller is
+			 * not able to get level interrupt but this is required
+			 * by this ADC as when going over 40 sample per second,
+			 * the interrupt line may stay high between conversions.
+			 * So, we continue no matter what but we switch to
+			 * polling mode.
+			 */
+			dev_info(&client->dev,
+				"Failed to allocate IRQ, using polling mode\n");
+			client->irq = 0;
+			/*
+			 * We are polling, use the fastest sample rate by
+			 * default
+			 */
+			st->sample_rate = 0x7;
+			nau7802_i2c_write(st, NAU7802_REG_CTRL2,
+					NAU7802_CTRL2_CRS(st->sample_rate));
+		}
+	}
+
+	/* Setup the ADC channels available on the board */
+	ret = nau7802_channel_init(idev);
+	if (ret < 0) {
+		dev_err(&client->dev, "Couldn't initialize the channels.\n");
+		goto error_channel_init;
+	}
+
+	init_completion(&st->value_ok);
+	mutex_init(&st->lock);
+	mutex_init(&st->data_lock);
+
+	ret = iio_device_register(idev);
+	if (ret < 0) {
+		dev_err(&client->dev, "Couldn't register the device.\n");
+		goto error_device_register;
+	}
+
+	return 0;
+
+error_device_register:
+	mutex_destroy(&st->lock);
+error_channel_init:
+	if (client->irq)
+		free_irq(client->irq, idev);
+	iio_device_free(idev);
+	return ret;
+}
+
+static int nau7802_remove(struct i2c_client *client)
+{
+	struct iio_dev *idev = i2c_get_clientdata(client);
+	struct nau7802_state *st = iio_priv(idev);
+
+	iio_device_unregister(idev);
+	mutex_destroy(&st->lock);
+	mutex_destroy(&st->data_lock);
+	if (client->irq)
+		free_irq(client->irq, idev);
+	iio_device_free(idev);
+
+	return 0;
+}
+
+static const struct i2c_device_id nau7802_i2c_id[] = {
+	{ "nau7802", 0 },
+	{ }
+};
+MODULE_DEVICE_TABLE(i2c, nau7802_i2c_id);
+
+static const struct of_device_id nau7802_dt_ids[] = {
+	{ .compatible = "nuvoton,nau7802" },
+	{},
+};
+MODULE_DEVICE_TABLE(of, nau7802_dt_ids);
+
+static struct i2c_driver nau7802_driver = {
+	.probe = nau7802_probe,
+	.remove = nau7802_remove,
+	.id_table = nau7802_i2c_id,
+	.driver = {
+		   .name = "nau7802",
+		   .of_match_table = of_match_ptr(nau7802_dt_ids),
+	},
+};
+
+module_i2c_driver(nau7802_driver);
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("Nuvoton NAU7802 ADC Driver");
+MODULE_AUTHOR("Maxime Ripard <maxime.ripard at free-electrons.com>");
+MODULE_AUTHOR("Alexandre Belloni <alexandre.belloni at free-electrons.com>");
-- 
1.7.10.4



From linux at arm.linux.org.uk  Thu Apr 18 11:44:25 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Thu, 18 Apr 2013 16:44:25 +0100
Subject: [PATCH 1/8] ARM: shmobile:Marzen: move USB EHCI, OHCI, and PHY
 devices to R8A7779 code
In-Reply-To: <201304050257.00799.sergei.shtylyov@cogentembedded.com>
References: <201304050257.00799.sergei.shtylyov@cogentembedded.com>
Message-ID: <20130418154425.GZ14496@n2100.arm.linux.org.uk>

On Fri, Apr 05, 2013 at 02:57:00AM +0400, Sergei Shtylyov wrote:
> +/* USB PHY */
> +static struct resource usb_phy_resources[] = {
> +	[0] = {
> +		.start		= 0xffe70000,
> +		.end		= 0xffe70900 - 1,
> +		.flags		= IORESOURCE_MEM,
> +	},
> +	[1] = {
> +		.start		= 0xfff70000,
> +		.end		= 0xfff70900 - 1,
> +		.flags		= IORESOURCE_MEM,
> +	},

Please consider using the macros for these initialisers.

> +static struct resource ehci0_resources[] = {
> +	[0] = {
> +		.start	= 0xffe70000,
> +		.end	= 0xffe70400 - 1,
> +		.flags	= IORESOURCE_MEM,
> +	},
> +	[1] = {
> +		.start	= gic_iid(0x4c),
> +		.flags	= IORESOURCE_IRQ,
> +	},

Ditto.

> +static struct resource ehci1_resources[] = {
> +	[0] = {
> +		.start	= 0xfff70000,
> +		.end	= 0xfff70400 - 1,
> +		.flags	= IORESOURCE_MEM,
> +	},
> +	[1] = {
> +		.start	= gic_iid(0x4d),
> +		.flags	= IORESOURCE_IRQ,
> +	},

Ditto.

> +static struct resource ohci0_resources[] = {
> +	[0] = {
> +		.start	= 0xffe70400,
> +		.end	= 0xffe70800 - 1,
> +		.flags	= IORESOURCE_MEM,
> +	},
> +	[1] = {
> +		.start	= gic_iid(0x4c),
> +		.flags	= IORESOURCE_IRQ,
> +	},

Ditto.

> +static struct resource ohci1_resources[] = {
> +	[0] = {
> +		.start	= 0xfff70400,
> +		.end	= 0xfff70800 - 1,
> +		.flags	= IORESOURCE_MEM,
> +	},
> +	[1] = {
> +		.start	= gic_iid(0x4d),
> +		.flags	= IORESOURCE_IRQ,
> +	},

Ditto.


From linux at arm.linux.org.uk  Thu Apr 18 11:42:36 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Thu, 18 Apr 2013 16:42:36 +0100
Subject: [PATCH 1/9] ARM: cpuidle: remove useless declaration
In-Reply-To: <517003CF.5090106@linaro.org>
References: <1364991322-20585-1-git-send-email-daniel.lezcano@linaro.org>
 <515C1F3B.5040008@linaro.org> <20130418141359.GT14496@n2100.arm.linux.org.uk>
 <517003CF.5090106@linaro.org>
Message-ID: <20130418154236.GY14496@n2100.arm.linux.org.uk>

On Thu, Apr 18, 2013 at 04:31:43PM +0200, Daniel Lezcano wrote:
> On 04/18/2013 04:13 PM, Russell King - ARM Linux wrote:
> > On Wed, Apr 03, 2013 at 02:23:23PM +0200, Daniel Lezcano wrote:
> >> On 04/03/2013 02:15 PM, Daniel Lezcano wrote:
> >>> The noop functions code is not necessary because the header file is
> >>> included in files which are compiled when CONFIG_CPU_IDLE is on.
> >>>
> >>> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
> >>
> >> I have been involved in the development of this file. I know Rob is no
> >> longer working on this neither monitoring the code.
> >>
> >> Russell are you ok with this patch ? Rafael needs your ack to take this
> >> patch into its tree.
> > 
> > I don't know - the description doesn't make it clear.  Surely, what you
> > checked was that this file is _not_ included in any file which is built
> > when CONFIG_CPU_IDLE is disabled.  In other words, when CONFIG_CPU_IDLE
> > is not defined, arm_cpuidle_simple_enter() is never referenced.
> > 
> > If that is the case, then it's just that the patch description is the
> > opposite of what it should be for this patch - and then the patch and
> > description match and I don't see any reason to say no to it.
> > 
> > Then comes the issue of who takes the patch.  It looks like Rafael
> > would like me to.
> 
> Actually Rafael was willing to take the patch if you ack it.

Well, I want to see a proper description on the patch which describes
what it _is_ doing before I ack it.  The existing description is just
plain confusing.


From stefano.stabellini at eu.citrix.com  Thu Apr 18 11:44:58 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Thu, 18 Apr 2013 16:44:58 +0100
Subject: [PATCH] xen/arm: introduce xen_early_init, use PSCI on xen
In-Reply-To: <1366298167-12755-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <1366298167-12755-1-git-send-email-stefano.stabellini@eu.citrix.com>
Message-ID: <alpine.DEB.2.02.1304181644060.7254@kaball.uk.xensource.com>

On Thu, 18 Apr 2013, Stefano Stabellini wrote:
> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> index b002822..3006de4 100644
> --- a/arch/arm/xen/enlighten.c
> +++ b/arch/arm/xen/enlighten.c
> @@ -176,11 +178,36 @@ static int __init xen_secondary_init(unsigned int cpu)
>  	return 0;
>  }
>  
> +static bool __init xen_smp_init(void)
> +{
> +#ifdef CONFIG_SMP
> +	/* If we are running on Xen, use PSCI if available.
> +	 * In any case do not try to use the native smp_ops. */
> +	if (psci_smp_available())
> +		smp_set_ops(&psci_smp_ops);
> +	return true;
> +#endif
> +}

Small mistake here: ifndef CONFIG_SMP, xen_smp_init won't have a return
value.
I'll fix and resend.


From olof at lixom.net  Thu Apr 18 11:46:00 2013
From: olof at lixom.net (Olof Johansson)
Date: Thu, 18 Apr 2013 08:46:00 -0700
Subject: [GIT PULL] mvebu irqchip for v3.10
In-Reply-To: <20130418114719.01e9f375@skate>
References: <20130415195245.GU28693@titan.lakedaemon.net>
 <20130418064217.GF12816@quad.lixom.net>
 <20130418114719.01e9f375@skate>
Message-ID: <CAOesGMgrAqZuECENV0pZGTxsOY2yTKjpMtTsgwDAN=qwsRv6RQ@mail.gmail.com>

Yeah, sorry -- my fault for doing merges late at night and not
sanity-checking a build before pushing. Fixed now.


-Olof

On Thu, Apr 18, 2013 at 2:47 AM, Thomas Petazzoni
<thomas.petazzoni at free-electrons.com> wrote:
> Olof, Jason,
>
> On Wed, 17 Apr 2013 23:42:17 -0700, Olof Johansson wrote:
>
>> > The following changes since commit
>> > 31880c37c11e28cb81c70757e38392b42e695dc6:
>> >
>> >   Linux 3.9-rc6 (2013-04-07 20:49:54 -0700)
>> >
>> > are available in the git repository at:
>> >
>> >   git://git.infradead.org/users/jcooper/linux.git tags/irqchip-3.10
>> >
>> > for you to fetch changes up to
>> > 5ec69017cc944f3ed88362d4b60818713a45e616:
>> >
>> >   irqchip: armada-370-xp: slightly cleanup irq controller driver
>> > (2013-04-15 19:35:17 +0000)
>> >
>> > ----------------------------------------------------------------
>> > mvebu driver irqchip for v3.10
>> >
>> >  - move the armada irqchip driver to drivers/irqchip/
>> >
>> > Note:
>> >  - I asked tglx if it was ok to take this series on 10 Apr due to
>> > it's complex dependencies.  5+ days have passed with no objection.
>> >  - I put this driver in a separate mvebu branch in case tglx or
>> > others object, it can be dropped with minimal impact to other work.
>>
>>
>> Hi,
>>
>> These notes are useful to include in the pull request, but not in the
>> git tag -- they don't really hold much permanent value.
>>
>> This branch also seems to have a few internal conflicts on mbus
>> changes. Not a big deal, I fixed it up, but you might as well have
>> based this on the other branch as well.
>>
>> Merged as a late/cleanup branch.
>
> I just tested arm-soc/for-next, and it seems like there was a merge
> conflict that was not properly resolved. The
> arch/arm/mach-mvebu/Makefile still references irq-armada-370-xp.c, even
> though it has been moved to drivers/irqchip/ as per the pull request of
> this e-mail. The fix is:
>
> diff --git a/arch/arm/mach-mvebu/Makefile b/arch/arm/mach-mvebu/Makefile
> index ca3b43f..90be143 100644
> --- a/arch/arm/mach-mvebu/Makefile
> +++ b/arch/arm/mach-mvebu/Makefile
> @@ -6,6 +6,6 @@ AFLAGS_coherency_ll.o           := -Wa,-march=armv7-a
>  obj-y                           += system-controller.o
>  obj-$(CONFIG_MACH_ARMADA_370_XP) += armada-370-xp.o
>  obj-$(CONFIG_ARCH_MVEBU)        += coherency.o coherency_ll.o
> -obj-$(CONFIG_ARCH_MVEBU)        += pmsu.o irq-armada-370-xp.o
> +obj-$(CONFIG_ARCH_MVEBU)        += pmsu.o
>  obj-$(CONFIG_SMP)                += platsmp.o headsmp.o
>  obj-$(CONFIG_HOTPLUG_CPU)        += hotplug.o
>
> Thomas
> --
> Thomas Petazzoni, Free Electrons
> Kernel, drivers, real-time and embedded Linux
> development, consulting, training and support.
> http://free-electrons.com


From daniel.lezcano at linaro.org  Thu Apr 18 11:47:05 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Thu, 18 Apr 2013 17:47:05 +0200
Subject: [PATCH 1/9] ARM: cpuidle: remove useless declaration
In-Reply-To: <20130418154236.GY14496@n2100.arm.linux.org.uk>
References: <1364991322-20585-1-git-send-email-daniel.lezcano@linaro.org>
 <515C1F3B.5040008@linaro.org> <20130418141359.GT14496@n2100.arm.linux.org.uk>
 <517003CF.5090106@linaro.org> <20130418154236.GY14496@n2100.arm.linux.org.uk>
Message-ID: <51701579.1040603@linaro.org>

On 04/18/2013 05:42 PM, Russell King - ARM Linux wrote:
> On Thu, Apr 18, 2013 at 04:31:43PM +0200, Daniel Lezcano wrote:
>> On 04/18/2013 04:13 PM, Russell King - ARM Linux wrote:
>>> On Wed, Apr 03, 2013 at 02:23:23PM +0200, Daniel Lezcano wrote:
>>>> On 04/03/2013 02:15 PM, Daniel Lezcano wrote:
>>>>> The noop functions code is not necessary because the header file is
>>>>> included in files which are compiled when CONFIG_CPU_IDLE is on.
>>>>>
>>>>> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
>>>>
>>>> I have been involved in the development of this file. I know Rob is no
>>>> longer working on this neither monitoring the code.
>>>>
>>>> Russell are you ok with this patch ? Rafael needs your ack to take this
>>>> patch into its tree.
>>>
>>> I don't know - the description doesn't make it clear.  Surely, what you
>>> checked was that this file is _not_ included in any file which is built
>>> when CONFIG_CPU_IDLE is disabled.  In other words, when CONFIG_CPU_IDLE
>>> is not defined, arm_cpuidle_simple_enter() is never referenced.
>>>
>>> If that is the case, then it's just that the patch description is the
>>> opposite of what it should be for this patch - and then the patch and
>>> description match and I don't see any reason to say no to it.
>>>
>>> Then comes the issue of who takes the patch.  It looks like Rafael
>>> would like me to.
>>
>> Actually Rafael was willing to take the patch if you ack it.
> 
> Well, I want to see a proper description on the patch which describes
> what it _is_ doing before I ack it.  The existing description is just
> plain confusing.

Ok, I will resend.

Thanks
  -- Daniel


-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From mfuzzey at parkeon.com  Thu Apr 18 11:55:10 2013
From: mfuzzey at parkeon.com (Martin Fuzzey)
Date: Thu, 18 Apr 2013 17:55:10 +0200
Subject: [PATCH V3] ARM: i.MX5: Allow DT clock providers
Message-ID: <20130418155510.26908.61334.stgit@localhost>

Currently clock providers defined in the DT are not registered
on i.MX5 platforms since of_clk_init() is not called.

This is not a problem for the SOC's own clocks, which are registered
in code,  but prevents the DT being used to define clocks for external
hardware.

Fix this by calling of_clk_init() and actually using the DT to obtain
the 4 SOC fixed clocks.
These are already defined in the DT but were previously just used to
manually obtain the rate.

Fall back to the old scheme for non DT platforms.

Signed-off-by: Martin Fuzzey <mfuzzey at parkeon.com>

---
Changelog:
V2: Applied comments from Sascha Hauer:
	* Use kasprintf instead of scnprintf to avoid length limit
	* Avoid use of IS_ERR_OR_NULL

V3: Applied comments from Shawn Guo:
	* Find clocks by path rather than compatible string
	* Remove unnecessary #ifdef CONFIG_OF
---
 arch/arm/mach-imx/clk-imx51-imx53.c |   76 ++++++++++++++++++-----------------
 1 files changed, 40 insertions(+), 36 deletions(-)

diff --git a/arch/arm/mach-imx/clk-imx51-imx53.c b/arch/arm/mach-imx/clk-imx51-imx53.c
index 3228b4e..606c679 100644
--- a/arch/arm/mach-imx/clk-imx51-imx53.c
+++ b/arch/arm/mach-imx/clk-imx51-imx53.c
@@ -117,17 +117,51 @@ enum imx5_clks {
 static struct clk *clk[clk_max];
 static struct clk_onecell_data clk_data;
 
+
+static struct clk * __init mx5_obtain_fixed_clock_from_dt(const char *name)
+{
+	struct of_phandle_args phandle = {0};
+	struct clk *clk = ERR_PTR(-ENODEV);
+	char *path;
+
+	path = kasprintf(GFP_KERNEL, "/clocks/%s", name);
+	if (!path)
+		return ERR_PTR(-ENOMEM);
+
+	phandle.np = of_find_node_by_path(path);
+	kfree(path);
+
+	if (phandle.np) {
+		clk = of_clk_get_from_provider(&phandle);
+		of_node_put(phandle.np);
+	}
+	return clk;
+}
+
+static struct clk * __init mx5_obtain_fixed_clock(
+			const char *name, unsigned long rate)
+{
+	struct clk *clk;
+
+	clk = mx5_obtain_fixed_clock_from_dt(name);
+	if (IS_ERR(clk))
+		clk = imx_clk_fixed(name, rate);
+	return clk;
+}
+
 static void __init mx5_clocks_common_init(unsigned long rate_ckil,
 		unsigned long rate_osc, unsigned long rate_ckih1,
 		unsigned long rate_ckih2)
 {
 	int i;
 
+	of_clk_init(NULL);
+
 	clk[dummy] = imx_clk_fixed("dummy", 0);
-	clk[ckil] = imx_clk_fixed("ckil", rate_ckil);
-	clk[osc] = imx_clk_fixed("osc", rate_osc);
-	clk[ckih1] = imx_clk_fixed("ckih1", rate_ckih1);
-	clk[ckih2] = imx_clk_fixed("ckih2", rate_ckih2);
+	clk[ckil] = mx5_obtain_fixed_clock("ckil", rate_ckil);
+	clk[osc] = mx5_obtain_fixed_clock("osc", rate_osc);
+	clk[ckih1] = mx5_obtain_fixed_clock("ckih1", rate_ckih1);
+	clk[ckih2] = mx5_obtain_fixed_clock("ckih2", rate_ckih2);
 
 	clk[lp_apm] = imx_clk_mux("lp_apm", MXC_CCM_CCSR, 9, 1,
 				lp_apm_sel, ARRAY_SIZE(lp_apm_sel));
@@ -539,42 +573,12 @@ int __init mx53_clocks_init(unsigned long rate_ckil, unsigned long rate_osc,
 	return of_clk_configure();
 }
 
-#ifdef CONFIG_OF
-static void __init clk_get_freq_dt(unsigned long *ckil, unsigned long *osc,
-				   unsigned long *ckih1, unsigned long *ckih2)
-{
-	struct device_node *np;
-
-	/* retrieve the freqency of fixed clocks from device tree */
-	for_each_compatible_node(np, NULL, "fixed-clock") {
-		u32 rate;
-		if (of_property_read_u32(np, "clock-frequency", &rate))
-			continue;
-
-		if (of_device_is_compatible(np, "fsl,imx-ckil"))
-			*ckil = rate;
-		else if (of_device_is_compatible(np, "fsl,imx-osc"))
-			*osc = rate;
-		else if (of_device_is_compatible(np, "fsl,imx-ckih1"))
-			*ckih1 = rate;
-		else if (of_device_is_compatible(np, "fsl,imx-ckih2"))
-			*ckih2 = rate;
-	}
-}
-
 int __init mx51_clocks_init_dt(void)
 {
-	unsigned long ckil, osc, ckih1, ckih2;
-
-	clk_get_freq_dt(&ckil, &osc, &ckih1, &ckih2);
-	return mx51_clocks_init(ckil, osc, ckih1, ckih2);
+	return mx51_clocks_init(0, 0, 0, 0);
 }
 
 int __init mx53_clocks_init_dt(void)
 {
-	unsigned long ckil, osc, ckih1, ckih2;
-
-	clk_get_freq_dt(&ckil, &osc, &ckih1, &ckih2);
-	return mx53_clocks_init(ckil, osc, ckih1, ckih2);
+	return mx53_clocks_init(0, 0, 0, 0);
 }
-#endif



From linux at arm.linux.org.uk  Thu Apr 18 11:54:04 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Thu, 18 Apr 2013 16:54:04 +0100
Subject: [PATCH 6/7] ARM: KVM: switch to a dual-step HYP init code
In-Reply-To: <515E9474.2070100@arm.com>
References: <1364909115-3810-1-git-send-email-marc.zyngier@arm.com>
 <1364909115-3810-7-git-send-email-marc.zyngier@arm.com>
 <1365113453.24496.26.camel@smoke> <515E9474.2070100@arm.com>
Message-ID: <20130418155404.GA14496@n2100.arm.linux.org.uk>

On Fri, Apr 05, 2013 at 10:08:04AM +0100, Marc Zyngier wrote:
> On 04/04/13 23:10, Geoff Levand wrote:
> > Hi,
> > 
> > On Tue, 2013-04-02 at 14:25 +0100, Marc Zyngier wrote:
> >> +	@ Jump to the trampoline page
> >> +	ldr	r2, =#PAGE_MASK
> >> +	adr	r3, target
> >> +	bic	r3, r3, r2
> >> +	ldr	r2, =#TRAMPOLINE_VA
> >> +	add	r3, r3, r2
> >> +	mov	pc, r3
> > 
> > I guess you need 'ldr r2, =PAGE_MASK'.
> > 
> >   arch/arm/kvm/init.S:114: Error: bad expression -- `ldr r2,=#(~((1<<12)-1))'
> >   arch/arm/kvm/init.S:117: Error: bad expression -- `ldr r2,=#0xffff0000'
> 
> Oddly enough, this code compiles perfectly fine on my box.
> What's your compiler/binutils versions?

The standard format for this is:
	ldr	rd, =value

without a '#' and has been that way for as long as I remember binutils
accepting that format.  It's entirely possible that later binutils has
decided to be a bit more flexible by allowing the '#' in there, but
that's something which will be incompatible with older versions.

Best loose the '#' in there.


From marc.zyngier at arm.com  Thu Apr 18 11:59:43 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu, 18 Apr 2013 17:59:43 +0200
Subject: [RFC] arm64: Early printk support for virtio-mmio console devices.
In-Reply-To: <51701084.5050706@codeaurora.org>
References: <1366264344-28025-1-git-send-email-pranavkumar@linaro.org>
 <51701084.5050706@codeaurora.org>
Message-ID: <217a4f2dd017af16204391012751e9f9@localhost>

On Thu, 18 Apr 2013 11:25:56 -0400, Christopher Covington
<cov at codeaurora.org> wrote:
> Hi Pranavkumar,
> 
> On 04/18/2013 01:52 AM, PranavkumarSawargaonkar wrote:
>> From: Pranavkumar Sawargaonkar <pranavkumar at linaro.org>
>> 
>> This patch implements early printk support for virtio-mmio console
>> devices
>> without using any hypercalls.
> 
> Is it possible that using DCC might be an easier solution?

You would end up with the exact same problem as with a hypercall based
solution: once you're in the hypervisor, what do you do with the data? You
end up having to invent another channel to forward it down to your platform
emulation in order to have it printed where the user expects it.

Using a MMIO based solution is probably the best solution, as it uses the
existing infrastructure.

        M.
-- 
Fast, cheap, reliable. Pick two.


From marc.zyngier at arm.com  Thu Apr 18 12:01:33 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu, 18 Apr 2013 17:01:33 +0100
Subject: [PATCH 6/7] ARM: KVM: switch to a dual-step HYP init code
In-Reply-To: <20130418155404.GA14496@n2100.arm.linux.org.uk>
References: <1364909115-3810-1-git-send-email-marc.zyngier@arm.com>
 <1364909115-3810-7-git-send-email-marc.zyngier@arm.com>
 <1365113453.24496.26.camel@smoke> <515E9474.2070100@arm.com>
 <20130418155404.GA14496@n2100.arm.linux.org.uk>
Message-ID: <517018DD.7070300@arm.com>

On 18/04/13 16:54, Russell King - ARM Linux wrote:
> On Fri, Apr 05, 2013 at 10:08:04AM +0100, Marc Zyngier wrote:
>> On 04/04/13 23:10, Geoff Levand wrote:
>>> Hi,
>>>
>>> On Tue, 2013-04-02 at 14:25 +0100, Marc Zyngier wrote:
>>>> +	@ Jump to the trampoline page
>>>> +	ldr	r2, =#PAGE_MASK
>>>> +	adr	r3, target
>>>> +	bic	r3, r3, r2
>>>> +	ldr	r2, =#TRAMPOLINE_VA
>>>> +	add	r3, r3, r2
>>>> +	mov	pc, r3
>>>
>>> I guess you need 'ldr r2, =PAGE_MASK'.
>>>
>>>   arch/arm/kvm/init.S:114: Error: bad expression -- `ldr r2,=#(~((1<<12)-1))'
>>>   arch/arm/kvm/init.S:117: Error: bad expression -- `ldr r2,=#0xffff0000'
>>
>> Oddly enough, this code compiles perfectly fine on my box.
>> What's your compiler/binutils versions?
> 
> The standard format for this is:
> 	ldr	rd, =value
> 
> without a '#' and has been that way for as long as I remember binutils
> accepting that format.  It's entirely possible that later binutils has
> decided to be a bit more flexible by allowing the '#' in there, but
> that's something which will be incompatible with older versions.
> 
> Best loose the '#' in there.

Indeed. I've fixed the code in a later version of the patch.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...



From mpfj-list at newflow.co.uk  Thu Apr 18 12:01:42 2013
From: mpfj-list at newflow.co.uk (Mark Jackson)
Date: Thu, 18 Apr 2013 17:01:42 +0100
Subject: [PATCH 0/3] Dual EMAC mode implementation of CPSW
In-Reply-To: <516C3A0D.70903@ti.com>
References: <1360612340-9266-1-git-send-email-mugunthanvnm@ti.com>
 <516B0098.4040809@mimc.co.uk> <516C33D2.4050105@ti.com>
 <516C38B9.50904@mimc.co.uk> <516C3A0D.70903@ti.com>
Message-ID: <517018E6.6080108@newflow.co.uk>

On 15/04/13 18:34, Mugunthan V N wrote:
> On 4/15/2013 10:58 PM, Mark Jackson wrote:
>> On 15/04/13 18:07, Mugunthan V N wrote:
>>> On 4/15/2013 12:46 AM, Mark Jackson wrote:
>>
>> <snip>
>>
>>>>
>>>> Notice that at the end, the nfs link appears to come back "ok", but
>>>> the "ps" command never completes.
>>>>
>>>> Any ideas of what's going on ?
>>>
>>> I have tried ping on both the interface fine. Will verify with ps again
>>> later in this week.
>>> Can you provide below details details
>>> - Are you using EVMsk or custom build EVM?
>>
>> This is a custom board (based on the BeagleBone design) with dual
>> Ethernet, NAND, NOR and FRAM.
>>
>> The dual emac thing is (one of) the last things to get signed off, so
>> I'm willing to assist in tracking this down.
> 
> After testing the scenario i may be able to send you an update later in
> this week.

I have made some progress ... I realised I was missing a (clearly rather
important !!) item in my .config file, namely CONFIG_TI_DAVINCI_EMAC.

I am now able to ping from our board to other systems on the network
(again, I've only tested eth0 at the moment).

However, I am unable to ping everything I should be able to !!

Here's my setup ...

# cat /etc/network/interfaces
# Configure Loopback
auto lo eth0 eth1
iface lo inet loopback
iface eth1 inet static
address 10.1.101.111
netmask 255.255.0.0
gateway 10.1.0.1
iface eth0 inet static
address 10.0.101.111
netmask 255.255.0.0
gateway 10.0.0.1

# ifconfig
eth0      Link encap:Ethernet  HWaddr C2:21:5E:B4:06:5E
          inet addr:10.0.101.111  Bcast:0.0.0.0  Mask:255.255.0.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:67 errors:0 dropped:0 overruns:0 frame:0
          TX packets:62 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:8848 (8.6 KiB)  TX bytes:4290 (4.1 KiB)
          Interrupt:56

eth1      Link encap:Ethernet  HWaddr D6:2F:CF:39:22:4E
          inet addr:10.1.101.111  Bcast:0.0.0.0  Mask:255.255.0.0
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:38 errors:0 dropped:0 overruns:0 frame:0
          TX packets:38 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:4022 (3.9 KiB)  TX bytes:4022 (3.9 KiB)

# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use
Iface
0.0.0.0         10.0.0.1        0.0.0.0         UG    0      0        0 eth0
10.0.0.0        0.0.0.0         255.255.0.0     U     0      0        0 eth0
10.1.0.0        0.0.0.0         255.255.0.0     U     0      0        0 eth1

I can ping a couple of units on 10.0.0.x ...

# ping 10.0.0.120
PING 10.0.0.120 (10.0.0.120): 56 data bytes
64 bytes from 10.0.0.120: seq=0 ttl=64 time=0.955 ms
64 bytes from 10.0.0.120: seq=1 ttl=64 time=0.676 ms
64 bytes from 10.0.0.120: seq=2 ttl=64 time=0.732 ms
64 bytes from 10.0.0.120: seq=3 ttl=64 time=0.762 ms

--- 10.0.0.120 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 0.676/0.781/0.955 ms
# ping 10.0.0.5
PING 10.0.0.5 (10.0.0.5): 56 data bytes
64 bytes from 10.0.0.5: seq=0 ttl=64 time=1.815 ms
64 bytes from 10.0.0.5: seq=1 ttl=64 time=0.458 ms
64 bytes from 10.0.0.5: seq=2 ttl=64 time=0.474 ms
64 bytes from 10.0.0.5: seq=3 ttl=64 time=0.345 ms
64 bytes from 10.0.0.5: seq=4 ttl=64 time=0.329 ms

--- 10.0.0.5 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 0.329/0.684/1.815 ms

But *not* my router on the same subnet ...

# ping 10.0.0.1
PING 10.0.0.1 (10.0.0.1): 56 data bytes

--- 10.0.0.1 ping statistics ---
15 packets transmitted, 0 packets received, 100% packet loss

I am also unable to ping other equipment that exists:-

# ping 10.0.101.2
PING 10.0.101.2 (10.0.101.2): 56 data bytes

--- 10.0.101.2 ping statistics ---
6 packets transmitted, 0 packets received, 100% packet loss

# ping 10.0.200.2
PING 10.0.200.2 (10.0.200.2): 56 data bytes

--- 10.0.200.2 ping statistics ---
5 packets transmitted, 0 packets received, 100% packet loss

Just to prove these other item do exist, here's me pinging them from
another Linux VM (working off the same physical switch):-

mpfj at mpfj-nanobone:~/linux/linux-2.6$ ifconfig
eth0      Link encap:Ethernet  HWaddr 08:00:27:1e:0d:f5
          inet addr:10.0.0.120  Bcast:10.0.255.255  Mask:255.255.0.0
          inet6 addr: fe80::a00:27ff:fe1e:df5/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:135935 errors:0 dropped:0 overruns:0 frame:0
          TX packets:172692 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:109340858 (109.3 MB)  TX bytes:177519151 (177.5 MB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:3771 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3771 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:294818 (294.8 KB)  TX bytes:294818 (294.8 KB)

mpfj at mpfj-nanobone:~/linux/linux-2.6$ ping 10.0.0.1
PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data.
64 bytes from 10.0.0.1: icmp_req=1 ttl=255 time=0.453 ms
64 bytes from 10.0.0.1: icmp_req=2 ttl=255 time=0.445 ms
64 bytes from 10.0.0.1: icmp_req=3 ttl=255 time=0.488 ms
64 bytes from 10.0.0.1: icmp_req=4 ttl=255 time=0.471 ms
64 bytes from 10.0.0.1: icmp_req=5 ttl=255 time=0.460 ms
^C
--- 10.0.0.1 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 3998ms
rtt min/avg/max/mdev = 0.445/0.463/0.488/0.024 ms
mpfj at mpfj-nanobone:~/linux/linux-2.6$ ping 10.0.200.2
PING 10.0.200.2 (10.0.200.2) 56(84) bytes of data.
64 bytes from 10.0.200.2: icmp_req=1 ttl=64 time=2.09 ms
64 bytes from 10.0.200.2: icmp_req=2 ttl=64 time=1.17 ms
64 bytes from 10.0.200.2: icmp_req=3 ttl=64 time=0.994 ms
64 bytes from 10.0.200.2: icmp_req=4 ttl=64 time=0.920 ms
^C
--- 10.0.200.2 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 0.920/1.296/2.095/0.471 ms
mpfj at mpfj-nanobone:~/linux/linux-2.6$ ping 10.0.101.2
PING 10.0.101.2 (10.0.101.2) 56(84) bytes of data.
64 bytes from 10.0.101.2: icmp_req=1 ttl=64 time=1.48 ms
64 bytes from 10.0.101.2: icmp_req=2 ttl=64 time=0.939 ms
64 bytes from 10.0.101.2: icmp_req=3 ttl=64 time=0.946 ms
64 bytes from 10.0.101.2: icmp_req=4 ttl=64 time=1.04 ms
^C
--- 10.0.101.2 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 0.939/1.104/1.483/0.223 ms

When the pings fail, I am unable to see *any* activity on the network
(using wireshark).

Is there anything else I should try ?

Cheers
Mark J.


From mpa at pengutronix.de  Thu Apr 18 12:02:08 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Thu, 18 Apr 2013 18:02:08 +0200
Subject: [PATCH RESEND v5 1/2] dma: imx-dma: Add oftree support
In-Reply-To: <51700DDD.1060801@metafoo.de>
References: <1366291298-30004-1-git-send-email-mpa@pengutronix.de>
 <1366291298-30004-2-git-send-email-mpa@pengutronix.de>
 <51700DDD.1060801@metafoo.de>
Message-ID: <20130418160208.GB4307@pengutronix.de>

On Thu, Apr 18, 2013 at 05:14:37PM +0200, Lars-Peter Clausen wrote:
> Hi,
> 
> On 04/18/2013 03:21 PM, Markus Pargmann wrote:
> [...]
> > +static struct dma_chan *imxdma_xlate(struct of_phandle_args *dma_spec,
> > +						struct of_dma *ofdma)
> > +{
> > +	int count = dma_spec->args_count;
> > +	struct imxdma_engine *imxdma = ofdma->of_dma_data;
> > +	struct imxdma_filter_data fdata = {
> > +		.imxdma = imxdma,
> > +		.request = *(unsigned *)&dma_spec->args[0],
> 
> This cast looks rather bogus and shouldn't be necessary.

Ah right, I was assuming "args" is void*.

> 
> > +	};
> > +
> > +	if (count != 1)
> > +		return NULL;
> 
> I think you need to check count before you access dma_spec->args[0]

dma_spec->args is actually a static array of size MAX_PHANDLE_ARGS.
However it is probably cleaner after the check, so I changed both.

Thanks,

Markus

> 
> > +
> > +	return dma_request_channel(imxdma->dma_device.cap_mask,
> > +					imxdma_filter_fn, &fdata);
> > +}
> > +
> [...]
> 
> 

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From stefano.stabellini at eu.citrix.com  Thu Apr 18 12:03:58 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Thu, 18 Apr 2013 17:03:58 +0100
Subject: [PATCH v2] xen/arm: introduce xen_early_init, use PSCI on xen
Message-ID: <1366301038-13433-1-git-send-email-stefano.stabellini@eu.citrix.com>

Split xen_guest_init in two functions, one of them (xen_early_init) is
going to be called very early from setup_arch.

Change machine_desc->smp_init to xen_smp_init if Xen is present on the
platform. xen_smp_init just sets smp_ops to psci_smp_ops.

XEN selects ARM_PSCI.

This patch is based on "xen/arm: move to mach-virt and support SMP"
(http://marc.info/?l=linux-kernel&m=136629656432231&w=2)
and "arm: introduce psci_smp_ops"
(http://marc.info/?l=linux-kernel&m=136629750732674&w=2).

Changes in v2:
- fix missing return value for xen_smp_init ifndef CONFIG_SMP.

A git tag for this patch is available here:

git://git.kernel.org/pub/scm/linux/kernel/git/sstabellini/xen.git 3.9-rc3-psci-xen-2-tag


Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
CC: xen-devel at lists.xensource.com
CC: linux-kernel at vger.kernel.org
CC: linux-arm-kernel at lists.infradead.org
CC: will.deacon at arm.com
CC: arnd at arndb.de
CC: nicolas.pitre at linaro.org
CC: rob.herring at calxeda.com
CC: linux at arm.linux.org.uk
CC: olof at lixom.net

Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
---
 arch/arm/Kconfig                      |    1 +
 arch/arm/include/asm/xen/hypervisor.h |    6 +++++
 arch/arm/kernel/setup.c               |    3 ++
 arch/arm/xen/enlighten.c              |   39 ++++++++++++++++++++++++++------
 4 files changed, 41 insertions(+), 8 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 2c3bdce..344e299 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1892,6 +1892,7 @@ config XEN
 	depends on ARM && AEABI && OF
 	depends on CPU_V7 && !CPU_V6
 	depends on !GENERIC_ATOMIC64
+	select ARM_PSCI
 	help
 	  Say Y if you want to run Linux in a Virtual Machine on Xen on ARM.
 
diff --git a/arch/arm/include/asm/xen/hypervisor.h b/arch/arm/include/asm/xen/hypervisor.h
index d7ab99a..17b3ea2 100644
--- a/arch/arm/include/asm/xen/hypervisor.h
+++ b/arch/arm/include/asm/xen/hypervisor.h
@@ -16,4 +16,10 @@ static inline enum paravirt_lazy_mode paravirt_get_lazy_mode(void)
 	return PARAVIRT_LAZY_NONE;
 }
 
+#ifdef CONFIG_XEN
+void xen_early_init(void);
+#else
+static inline void xen_early_init(void) { return; }
+#endif
+
 #endif /* _ASM_ARM_XEN_HYPERVISOR_H */
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 22cc863..3dcd357 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -55,6 +55,8 @@
 #include <asm/unwind.h>
 #include <asm/memblock.h>
 #include <asm/virt.h>
+#include <asm/xen/hypervisor.h>
+#include <xen/xen.h>
 
 #include "atags.h"
 #include "tcm.h"
@@ -768,6 +770,7 @@ void __init setup_arch(char **cmdline_p)
 
 	arm_dt_init_cpu_maps();
 	psci_init();
+	xen_early_init();
 #ifdef CONFIG_SMP
 	if (is_smp()) {
 		if (!mdesc->smp_init || !mdesc->smp_init()) {
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index b002822..c1fe6f3 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -11,6 +11,8 @@
 #include <xen/xenbus.h>
 #include <xen/page.h>
 #include <xen/xen-ops.h>
+#include <asm/mach/arch.h>
+#include <asm/psci.h>
 #include <asm/xen/hypervisor.h>
 #include <asm/xen/hypercall.h>
 #include <linux/interrupt.h>
@@ -176,11 +178,36 @@ static int __init xen_secondary_init(unsigned int cpu)
 	return 0;
 }
 
+static bool __init xen_smp_init(void)
+{
+#ifdef CONFIG_SMP
+	/* If we are running on Xen, use PSCI if available.
+	 * In any case do not try to use the native smp_ops. */
+	if (psci_smp_available())
+		smp_set_ops(&psci_smp_ops);
+#endif
+	return true;
+}
+
 /*
  * see Documentation/devicetree/bindings/arm/xen.txt for the
  * documentation of the Xen Device Tree format.
  */
 #define GRANT_TABLE_PHYSADDR 0
+void __init xen_early_init(void)
+{
+	struct device_node *node;
+
+	node = of_find_compatible_node(NULL, NULL, "xen,xen");
+	if (!node) {
+		pr_debug("No Xen support\n");
+		return;
+	}
+
+	xen_domain_type = XEN_HVM_DOMAIN;
+	machine_desc->smp_init = xen_smp_init;
+}
+
 static int __init xen_guest_init(void)
 {
 	struct xen_add_to_physmap xatp;
@@ -194,25 +221,21 @@ static int __init xen_guest_init(void)
 	int i;
 
 	node = of_find_compatible_node(NULL, NULL, "xen,xen");
-	if (!node) {
-		pr_debug("No Xen support\n");
-		return 0;
-	}
+
 	s = of_get_property(node, "compatible", &len);
 	if (strlen(xen_prefix) + 3  < len &&
 			!strncmp(xen_prefix, s, strlen(xen_prefix)))
 		version = s + strlen(xen_prefix);
 	if (version == NULL) {
-		pr_debug("Xen version not found\n");
-		return 0;
+		pr_warn("Xen version not found\n");
+		return -EINVAL;
 	}
 	if (of_address_to_resource(node, GRANT_TABLE_PHYSADDR, &res))
-		return 0;
+		return -EINVAL;
 	xen_hvm_resume_frames = res.start >> PAGE_SHIFT;
 	xen_events_irq = irq_of_parse_and_map(node, 0);
 	pr_info("Xen %s support found, events_irq=%d gnttab_frame_pfn=%lx\n",
 			version, xen_events_irq, xen_hvm_resume_frames);
-	xen_domain_type = XEN_HVM_DOMAIN;
 
 	xen_setup_features();
 	if (xen_feature(XENFEAT_dom0))
-- 
1.7.2.5



From plagnioj at jcrosoft.com  Thu Apr 18 12:06:14 2013
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Thu, 18 Apr 2013 18:06:14 +0200
Subject: [PATCH v4 2/2] video: imxfb: Add DT support
In-Reply-To: <1366290183-367-3-git-send-email-mpa@pengutronix.de>
References: <1366290183-367-1-git-send-email-mpa@pengutronix.de>
 <1366290183-367-3-git-send-email-mpa@pengutronix.de>
Message-ID: <20130418160614.GF4998@game.jcrosoft.org>

On 15:03 Thu 18 Apr     , Markus Pargmann wrote:
> Add devicetree support for imx framebuffer driver. It uses the generic
> display bindings and helper functions.
> 
> Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
> Cc: Fabio Estevam <festevam at gmail.com>
> Cc: Mark Rutland <mark.rutland at arm.com>
> ---
> 
> Notes:
>     Changes in v4:
>     - Remove eukrea specific dmacr property.
>     - Add optional dmacr property. If not present, the dmacr reset value is not
>       changed.
>     
>     Changes in v3:
>     - Fix returncodes of of_read_mode function and print error messages
>     - Introduce a lower bound check for bits per pixel
>     - Calculate correct bytes per pixel value before using it for the calculation of
>     	memory size
>     - Change DT property names
>     
>     Changes in v2:
>     - Removed pwmr register property
>     - Cleanup of devicetree binding documentation
>     - Use default values for pwmr and lscr1
> 
>  .../devicetree/bindings/video/fsl,imx-fb.txt       |  51 ++++++
>  drivers/video/imxfb.c                              | 194 +++++++++++++++++----
>  2 files changed, 210 insertions(+), 35 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/video/fsl,imx-fb.txt
> 
> diff --git a/Documentation/devicetree/bindings/video/fsl,imx-fb.txt b/Documentation/devicetree/bindings/video/fsl,imx-fb.txt
> new file mode 100644
> index 0000000..aff16a4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/fsl,imx-fb.txt
> @@ -0,0 +1,51 @@
> +Freescale imx21 Framebuffer
> +
> +This framebuffer driver supports devices imx1, imx21, imx25, and imx27.
> +
> +Required properties:
> +- compatible : "fsl,<chip>-fb", chip should be imx1 or imx21
> +- reg : Should contain 1 register ranges(address and length)
> +- interrupts : One interrupt of the fb dev
> +
> +Required nodes:
> +- display: Phandle to a display node as described in
> +	Documentation/devicetree/bindings/video/display-timing.txt
> +	Additional, the display node has to define properties:
> +	- fsl,bpp: Bits per pixel
> +	- fsl,pcr: LCDC PCR value
> +
> +Optional properties:
> +- fsl,dmacr: DMA Control Register value. This is optional. By default, the
> +	register is not modified as recommended by the datasheet.
> +- fsl,lscr1: LCDC Sharp Configuration Register value.
> +
> +Example:
> +
> +	imxfb: fb at 10021000 {
> +		compatible = "fsl,imx27-fb", "fsl,imx21-fb";
you put both when in the doc you request one
> +		interrupts = <61>;
> +		reg = <0x10021000 0x1000>;
> +		display = <&display0>;
> +	};
> +
> +	...
> +
> +	display0: display0 {
> +		model = "Primeview-PD050VL1";
> +		native-mode = <&timing_disp0>;
> +		fsl,bpp = <16>;		/* non-standard but required */
there is a generic binding bit-per-pixel use a cross other IP
> +		fsl,pcr = <0xf0c88080>;	/* non-standard but required */
> +		display-timings {
> +			timing_disp0: 640x480 {
> +				hactive = <640>;
> +				vactive = <480>;
> +				hback-porch = <112>;
> +				hfront-porch = <36>;
> +				hsync-len = <32>;
> +				vback-porch = <33>;
> +				vfront-porch = <33>;
> +				vsync-len = <2>;
> +				clock-frequency = <25000000>;
> +			};
> +		};
> +	};
> diff --git a/drivers/video/imxfb.c b/drivers/video/imxfb.c
> index ef2b587..e0230f8 100644
> --- a/drivers/video/imxfb.c
> +++ b/drivers/video/imxfb.c
> @@ -32,6 +32,12 @@
>  #include <linux/io.h>
>  #include <linux/math64.h>
>  #include <linux/uaccess.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>
> +
> +#include <video/of_display_timing.h>
> +#include <video/of_videomode.h>
> +#include <video/videomode.h>
>  
>  #include <linux/platform_data/video-imxfb.h>
>  
> @@ -117,10 +123,11 @@
>  #define LGWCR_GWAV(alpha)	(((alpha) & 0xff) << 24)
>  #define LGWCR_GWE	(1 << 22)
>  
> +#define IMXFB_LSCR1_DEFAULT 0x00120300
> +
>  /* Used fb-mode. Can be set on kernel command line, therefore file-static. */
>  static const char *fb_mode;
>  
> -
>  /*
>   * These are the bitfields for each
>   * display depth that we support.
> @@ -192,6 +199,19 @@ static struct platform_device_id imxfb_devtype[] = {
>  };
>  MODULE_DEVICE_TABLE(platform, imxfb_devtype);
>  
> +static struct of_device_id imxfb_of_dev_id[] = {
> +	{
> +		.compatible = "fsl,imx1-fb",
> +		.data = &imxfb_devtype[IMX1_FB],
> +	}, {
> +		.compatible = "fsl,imx21-fb",
> +		.data = &imxfb_devtype[IMX21_FB],
> +	}, {
> +		/* sentinel */
> +	}
> +};
> +MODULE_DEVICE_TABLE(of, imxfb_of_dev_id);
> +
>  static inline int is_imx1_fb(struct imxfb_info *fbi)
>  {
>  	return fbi->devtype == IMX1_FB;
> @@ -324,6 +344,9 @@ static const struct imx_fb_videomode *imxfb_find_mode(struct imxfb_info *fbi)
>  	struct imx_fb_videomode *m;
>  	int i;
>  
> +	if (!fb_mode)
> +		return &fbi->mode[0];
> +
>  	for (i = 0, m = &fbi->mode[0]; i < fbi->num_modes; i++, m++) {
>  		if (!strcmp(m->mode.name, fb_mode))
>  			return m;
> @@ -479,6 +502,9 @@ static int imxfb_bl_update_status(struct backlight_device *bl)
>  	struct imxfb_info *fbi = bl_get_data(bl);
>  	int brightness = bl->props.brightness;
>  
> +	if (!fbi->pwmr)
> +		return 0;
> +
>  	if (bl->props.power != FB_BLANK_UNBLANK)
>  		brightness = 0;
>  	if (bl->props.fb_blank != FB_BLANK_UNBLANK)
> @@ -719,10 +745,14 @@ static int imxfb_activate_var(struct fb_var_screeninfo *var, struct fb_info *inf
>  
>  	writel(fbi->pcr, fbi->regs + LCDC_PCR);
>  #ifndef PWMR_BACKLIGHT_AVAILABLE
> -	writel(fbi->pwmr, fbi->regs + LCDC_PWMR);
> +	if (fbi->pwmr)
> +		writel(fbi->pwmr, fbi->regs + LCDC_PWMR);
>  #endif
>  	writel(fbi->lscr1, fbi->regs + LCDC_LSCR1);
> -	writel(fbi->dmacr, fbi->regs + LCDC_DMACR);
> +
> +	/* dmacr = 0 is no valid value, as we need DMA control marks. */
> +	if (fbi->dmacr)
> +		writel(fbi->dmacr, fbi->regs + LCDC_DMACR);
>  
>  	return 0;
>  }
> @@ -758,13 +788,12 @@ static int imxfb_resume(struct platform_device *dev)
>  #define imxfb_resume	NULL
>  #endif
>  
> -static int __init imxfb_init_fbinfo(struct platform_device *pdev)
> +static int imxfb_init_fbinfo(struct platform_device *pdev)
>  {
>  	struct imx_fb_platform_data *pdata = pdev->dev.platform_data;
>  	struct fb_info *info = dev_get_drvdata(&pdev->dev);
>  	struct imxfb_info *fbi = info->par;
> -	struct imx_fb_videomode *m;
> -	int i;
> +	struct device_node *np;
>  
>  	pr_debug("%s\n",__func__);
>  
> @@ -795,41 +824,95 @@ static int __init imxfb_init_fbinfo(struct platform_device *pdev)
>  	info->fbops			= &imxfb_ops;
>  	info->flags			= FBINFO_FLAG_DEFAULT |
>  					  FBINFO_READS_FAST;
> -	info->var.grayscale		= pdata->cmap_greyscale;
> -	fbi->cmap_inverse		= pdata->cmap_inverse;
> -	fbi->cmap_static		= pdata->cmap_static;
> -	fbi->lscr1			= pdata->lscr1;
> -	fbi->dmacr			= pdata->dmacr;
> -	fbi->pwmr			= pdata->pwmr;
> -	fbi->lcd_power			= pdata->lcd_power;
> -	fbi->backlight_power		= pdata->backlight_power;
> -
> -	for (i = 0, m = &pdata->mode[0]; i < pdata->num_modes; i++, m++)
> -		info->fix.smem_len = max_t(size_t, info->fix.smem_len,
> -				m->mode.xres * m->mode.yres * m->bpp / 8);
> +	if (pdata) {
> +		info->var.grayscale		= pdata->cmap_greyscale;
> +		fbi->cmap_inverse		= pdata->cmap_inverse;
> +		fbi->cmap_static		= pdata->cmap_static;
> +		fbi->lscr1			= pdata->lscr1;
> +		fbi->dmacr			= pdata->dmacr;
> +		fbi->pwmr			= pdata->pwmr;
> +		fbi->lcd_power			= pdata->lcd_power;
> +		fbi->backlight_power		= pdata->backlight_power;
> +	} else {
> +		np = pdev->dev.of_node;
> +		info->var.grayscale = of_property_read_bool(np,
> +						"cmap-greyscale");
> +		fbi->cmap_inverse = of_property_read_bool(np, "cmap-inverse");
> +		fbi->cmap_static = of_property_read_bool(np, "cmap-static");
> +
> +		fbi->lscr1 = IMXFB_LSCR1_DEFAULT;
> +		of_property_read_u32(np, "fsl,lscr1", &fbi->lscr1);
> +
> +		of_property_read_u32(np, "fsl,dmacr", &fbi->dmacr);
> +
> +		/* These two function pointers could be used by some specific
> +		 * platforms. */
> +		fbi->lcd_power = NULL;
> +		fbi->backlight_power = NULL;
> +	}
> +
> +	return 0;
> +}
> +
> +static int imxfb_of_read_mode(struct device *dev, struct device_node *np,
> +		struct imx_fb_videomode *imxfb_mode)
> +{
> +	int ret;
> +	struct fb_videomode *of_mode = &imxfb_mode->mode;
> +	u32 bpp;
> +	u32 pcr;
> +
> +	ret = of_property_read_string(np, "model", &of_mode->name);
> +	if (ret)
> +		of_mode->name = NULL;
> +
> +	ret = of_get_fb_videomode(np, of_mode, OF_USE_NATIVE_MODE);
> +	if (ret) {
> +		dev_err(dev, "Failed to get videomode from DT\n");
> +		return ret;
> +	}
> +
> +	ret = of_property_read_u32(np, "fsl,bpp", &bpp);
> +	ret |= of_property_read_u32(np, "fsl,pcr", &pcr);
> +
> +	if (ret) {
> +		dev_err(dev, "Failed to read bpp and pcr from DT\n");
> +		return -EINVAL;
> +	}
> +
> +	if (bpp < 1 || bpp > 255) {
> +		dev_err(dev, "Bits per pixel have to be between 1 and 255\n");
> +		return -EINVAL;
> +	}
> +
> +	imxfb_mode->bpp = bpp;
> +	imxfb_mode->pcr = pcr;
>  
>  	return 0;
>  }
>  
> -static int __init imxfb_probe(struct platform_device *pdev)
> +static int imxfb_probe(struct platform_device *pdev)
>  {
>  	struct imxfb_info *fbi;
>  	struct fb_info *info;
>  	struct imx_fb_platform_data *pdata;
>  	struct resource *res;
> +	struct imx_fb_videomode *m;
> +	const struct of_device_id *of_id;
>  	int ret, i;
> +	int bytes_per_pixel;
>  
>  	dev_info(&pdev->dev, "i.MX Framebuffer driver\n");
>  
> +	of_id = of_match_device(imxfb_of_dev_id, &pdev->dev);
> +	if (of_id)
> +		pdev->id_entry = of_id->data;
> +
>  	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>  	if (!res)
>  		return -ENODEV;
>  
>  	pdata = pdev->dev.platform_data;
> -	if (!pdata) {
> -		dev_err(&pdev->dev,"No platform_data available\n");
> -		return -ENOMEM;
> -	}
>  
>  	info = framebuffer_alloc(sizeof(struct imxfb_info), &pdev->dev);
>  	if (!info)
> @@ -837,15 +920,55 @@ static int __init imxfb_probe(struct platform_device *pdev)
>  
>  	fbi = info->par;
>  
> -	if (!fb_mode)
> -		fb_mode = pdata->mode[0].mode.name;
> -
>  	platform_set_drvdata(pdev, info);
>  
>  	ret = imxfb_init_fbinfo(pdev);
>  	if (ret < 0)
>  		goto failed_init;
>  
> +	if (pdata) {
> +		if (!fb_mode)
> +			fb_mode = pdata->mode[0].mode.name;
> +
> +		fbi->mode = pdata->mode;
> +		fbi->num_modes = pdata->num_modes;
> +	} else {
> +		struct device_node *display_np;
> +		fb_mode = NULL;
> +
> +		display_np = of_parse_phandle(pdev->dev.of_node, "display", 0);
> +		if (!display_np) {
> +			dev_err(&pdev->dev, "No display defined in devicetree\n");
> +			ret = -EINVAL;
> +			goto failed_of_parse;
> +		}
> +
> +		/*
> +		 * imxfb does not support more modes, we choose only the native
> +		 * mode.
> +		 */
> +		fbi->num_modes = 1;
> +
> +		fbi->mode = devm_kzalloc(&pdev->dev,
> +				sizeof(struct imx_fb_videomode), GFP_KERNEL);
> +		if (!fbi->mode) {
> +			ret = -ENOMEM;
> +			goto failed_of_parse;
> +		}
> +
> +		ret = imxfb_of_read_mode(&pdev->dev, display_np, fbi->mode);
> +		if (ret)
> +			goto failed_of_parse;
> +	}
> +
> +	/* Calculate maximum bytes used per pixel. In most cases this should
> +	 * be the same as m->bpp/8 */
> +	m = &fbi->mode[0];
> +	bytes_per_pixel = (m->bpp + 7) / 8;
> +	for (i = 0; i < fbi->num_modes; i++, m++)
> +		info->fix.smem_len = max_t(size_t, info->fix.smem_len,
> +				m->mode.xres * m->mode.yres * bytes_per_pixel);
> +
>  	res = request_mem_region(res->start, resource_size(res),
>  				DRIVER_NAME);
>  	if (!res) {
> @@ -878,7 +1001,8 @@ static int __init imxfb_probe(struct platform_device *pdev)
>  		goto failed_ioremap;
>  	}
>  
> -	if (!pdata->fixed_screen_cpu) {
> +	/* Seems not being used by anyone, so no support for oftree */
> +	if (!pdata || !pdata->fixed_screen_cpu) {
>  		fbi->map_size = PAGE_ALIGN(info->fix.smem_len);
>  		fbi->map_cpu = dma_alloc_writecombine(&pdev->dev,
>  				fbi->map_size, &fbi->map_dma, GFP_KERNEL);
> @@ -903,18 +1027,16 @@ static int __init imxfb_probe(struct platform_device *pdev)
>  		info->fix.smem_start = fbi->screen_dma;
>  	}
>  
> -	if (pdata->init) {
> +	if (pdata && pdata->init) {
>  		ret = pdata->init(fbi->pdev);
>  		if (ret)
>  			goto failed_platform_init;
>  	}
>  
> -	fbi->mode = pdata->mode;
> -	fbi->num_modes = pdata->num_modes;
>  
>  	INIT_LIST_HEAD(&info->modelist);
> -	for (i = 0; i < pdata->num_modes; i++)
> -		fb_add_videomode(&pdata->mode[i].mode, &info->modelist);
> +	for (i = 0; i < fbi->num_modes; i++)
> +		fb_add_videomode(&fbi->mode[i].mode, &info->modelist);
>  
>  	/*
>  	 * This makes sure that our colour bitfield
> @@ -944,10 +1066,10 @@ static int __init imxfb_probe(struct platform_device *pdev)
>  failed_register:
>  	fb_dealloc_cmap(&info->cmap);
>  failed_cmap:
> -	if (pdata->exit)
> +	if (pdata && pdata->exit)
>  		pdata->exit(fbi->pdev);
>  failed_platform_init:
> -	if (!pdata->fixed_screen_cpu)
> +	if (pdata && !pdata->fixed_screen_cpu)
>  		dma_free_writecombine(&pdev->dev,fbi->map_size,fbi->map_cpu,
>  			fbi->map_dma);
>  failed_map:
> @@ -956,6 +1078,7 @@ failed_ioremap:
>  failed_getclock:
>  	release_mem_region(res->start, resource_size(res));
>  failed_req:
> +failed_of_parse:
>  	kfree(info->pseudo_palette);
>  failed_init:
>  	platform_set_drvdata(pdev, NULL);
> @@ -980,7 +1103,7 @@ static int imxfb_remove(struct platform_device *pdev)
>  	unregister_framebuffer(info);
>  
>  	pdata = pdev->dev.platform_data;
> -	if (pdata->exit)
> +	if (pdata && pdata->exit)
>  		pdata->exit(fbi->pdev);
>  
>  	fb_dealloc_cmap(&info->cmap);
> @@ -1009,6 +1132,7 @@ static struct platform_driver imxfb_driver = {
>  	.shutdown	= imxfb_shutdown,
>  	.driver		= {
>  		.name	= DRIVER_NAME,
> +		.of_match_table = imxfb_of_dev_id,
>  	},
>  	.id_table	= imxfb_devtype,
>  };
> -- 
> 1.8.1.5
> 


From linux at arm.linux.org.uk  Thu Apr 18 12:13:42 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Thu, 18 Apr 2013 17:13:42 +0100
Subject: [PATCH v6 1/4] arm: introduce psci_smp_ops
In-Reply-To: <1365167495-18508-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1304031239550.5078@kaball.uk.xensource.com>
 <1365167495-18508-1-git-send-email-stefano.stabellini@eu.citrix.com>
Message-ID: <20130418161341.GB14496@n2100.arm.linux.org.uk>

On Fri, Apr 05, 2013 at 02:11:32PM +0100, Stefano Stabellini wrote:
> +	psci_init();
>  #ifdef CONFIG_SMP
>  	if (is_smp()) {
> -		smp_set_ops(mdesc->smp);
> +		if (mdesc->smp)
> +			smp_set_ops(mdesc->smp);
> +		else if (psci_smp_available())
> +			smp_set_ops(&psci_smp_ops);

So, I have a vague recollection that the ordering of the above got discussed
but I can't find it amongst the 21k of messages so far this year.

The above looks weird to me.  Surely this should be:

		if (psci_smp_available())
			smp_set_ops(&psci_smp_ops);
		else if (mdesc->smp)
			smp_set_ops(mdesc->ops);

This means that if PSCI is available, and provides a set of operations,
we override whatever the platform has statically provided.

Remember, we're trying to move away from using "mdesc"s for platform
stuff, relying on things like DT and such like.  We really should not
be going for mdesc-overriding-newstuff but newstuff-overriding-mdesc.

Now, if the psci stuff can't be relied upon to provide the correct
functionality, then that's a separate problem which needs addressing
differently.

This should allow the Xen problem to be resolved, because Xen will
provide the PSCI operations, and it's correct in that case to override
the platform's SMP operations.


From s.hauer at pengutronix.de  Thu Apr 18 12:14:24 2013
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Thu, 18 Apr 2013 18:14:24 +0200
Subject: [PATCH V3] ARM: i.MX5: Allow DT clock providers
In-Reply-To: <20130418155510.26908.61334.stgit@localhost>
References: <20130418155510.26908.61334.stgit@localhost>
Message-ID: <20130418161424.GI1906@pengutronix.de>

On Thu, Apr 18, 2013 at 05:55:10PM +0200, Martin Fuzzey wrote:
> Currently clock providers defined in the DT are not registered
> on i.MX5 platforms since of_clk_init() is not called.
> 
> This is not a problem for the SOC's own clocks, which are registered
> in code,  but prevents the DT being used to define clocks for external
> hardware.
> 
> Fix this by calling of_clk_init() and actually using the DT to obtain
> the 4 SOC fixed clocks.
> These are already defined in the DT but were previously just used to
> manually obtain the rate.
> 
> Fall back to the old scheme for non DT platforms.
> 
> Signed-off-by: Martin Fuzzey <mfuzzey at parkeon.com>
> 
> ---
> Changelog:
> V2: Applied comments from Sascha Hauer:
> 	* Use kasprintf instead of scnprintf to avoid length limit
> 	* Avoid use of IS_ERR_OR_NULL
> 
> V3: Applied comments from Shawn Guo:
> 	* Find clocks by path rather than compatible string
> 	* Remove unnecessary #ifdef CONFIG_OF
> ---
>  arch/arm/mach-imx/clk-imx51-imx53.c |   76 ++++++++++++++++++-----------------
>  1 files changed, 40 insertions(+), 36 deletions(-)
> 
> diff --git a/arch/arm/mach-imx/clk-imx51-imx53.c b/arch/arm/mach-imx/clk-imx51-imx53.c
> index 3228b4e..606c679 100644
> --- a/arch/arm/mach-imx/clk-imx51-imx53.c
> +++ b/arch/arm/mach-imx/clk-imx51-imx53.c
> @@ -117,17 +117,51 @@ enum imx5_clks {
>  static struct clk *clk[clk_max];
>  static struct clk_onecell_data clk_data;
>  
> +
> +static struct clk * __init mx5_obtain_fixed_clock_from_dt(const char *name)
> +{
> +	struct of_phandle_args phandle = {0};
> +	struct clk *clk = ERR_PTR(-ENODEV);
> +	char *path;
> +
> +	path = kasprintf(GFP_KERNEL, "/clocks/%s", name);
> +	if (!path)
> +		return ERR_PTR(-ENOMEM);
> +
> +	phandle.np = of_find_node_by_path(path);
> +	kfree(path);
> +
> +	if (phandle.np) {
> +		clk = of_clk_get_from_provider(&phandle);
> +		of_node_put(phandle.np);
> +	}
> +	return clk;
> +}
> +
> +static struct clk * __init mx5_obtain_fixed_clock(
> +			const char *name, unsigned long rate)
> +{
> +	struct clk *clk;
> +
> +	clk = mx5_obtain_fixed_clock_from_dt(name);
> +	if (IS_ERR(clk))
> +		clk = imx_clk_fixed(name, rate);
> +	return clk;
> +}

I just realized that this is useful for other i.MX aswell. How about
renaming it to imx_obtain_fixed_clk() and move it to
arch/arm/mach-imx/clk.c?

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From stefano.stabellini at eu.citrix.com  Thu Apr 18 12:20:23 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Thu, 18 Apr 2013 17:20:23 +0100
Subject: [PATCH v6 1/4] arm: introduce psci_smp_ops
In-Reply-To: <20130418161341.GB14496@n2100.arm.linux.org.uk>
References: <alpine.DEB.2.02.1304031239550.5078@kaball.uk.xensource.com>
 <1365167495-18508-1-git-send-email-stefano.stabellini@eu.citrix.com>
 <20130418161341.GB14496@n2100.arm.linux.org.uk>
Message-ID: <alpine.DEB.2.02.1304181714560.7254@kaball.uk.xensource.com>

On Thu, 18 Apr 2013, Russell King - ARM Linux wrote:
> On Fri, Apr 05, 2013 at 02:11:32PM +0100, Stefano Stabellini wrote:
> > +	psci_init();
> >  #ifdef CONFIG_SMP
> >  	if (is_smp()) {
> > -		smp_set_ops(mdesc->smp);
> > +		if (mdesc->smp)
> > +			smp_set_ops(mdesc->smp);
> > +		else if (psci_smp_available())
> > +			smp_set_ops(&psci_smp_ops);
> 
> So, I have a vague recollection that the ordering of the above got discussed
> but I can't find it amongst the 21k of messages so far this year.
> 
> The above looks weird to me.  Surely this should be:
> 
> 		if (psci_smp_available())
> 			smp_set_ops(&psci_smp_ops);
> 		else if (mdesc->smp)
> 			smp_set_ops(mdesc->ops);
> 
> This means that if PSCI is available, and provides a set of operations,
> we override whatever the platform has statically provided.
> 
> Remember, we're trying to move away from using "mdesc"s for platform
> stuff, relying on things like DT and such like.  We really should not
> be going for mdesc-overriding-newstuff but newstuff-overriding-mdesc.

That's correct, in fact if you look at the next patch you'll see that it
changes the order.

I introduced the mechanism first and changed the priority later - it
should help bisectability.
I can fold the two patches into one if you prefer.


> Now, if the psci stuff can't be relied upon to provide the correct
> functionality, then that's a separate problem which needs addressing
> differently.
> 
> This should allow the Xen problem to be resolved, because Xen will
> provide the PSCI operations, and it's correct in that case to override
> the platform's SMP operations.

Yes, increasing the priority of PSCI helps Xen a lot.
In order to completely solve the issue for Xen though, another patch is
needed (http://marc.info/?l=linux-kernel&m=136630106201968&w=2) because
of the introduction of smp_init.



From tixy at linaro.org  Thu Apr 18 12:20:46 2013
From: tixy at linaro.org (Jon Medhurst (Tixy))
Date: Thu, 18 Apr 2013 17:20:46 +0100
Subject: [PATCH] ARM: make cpu_init() notrace
Message-ID: <1366302046.3388.8.camel@linaro1.home>

On resume from CPU power down any trace hooks enabled in cpu_init()
will get called before that function has done set_my_cpu_offset(),
so any use of per-cpu variables by trace hook code will cause bad
things to happen. Prevent this by marking the function notrace.

This fixes lockups/crashes seen when enabling function tracer on TC2
with the not yet mainlined cpuidle driver.

Signed-off-by: Jon Medhurst <tixy at linaro.org>
---
 arch/arm/kernel/setup.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index d343a6c..943cbf0 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -390,7 +390,7 @@ static void __init feat_v6_fixup(void)
  *
  * cpu_init sets up the per-CPU stacks.
  */
-void cpu_init(void)
+void notrace cpu_init(void)
 {
 	unsigned int cpu = smp_processor_id();
 	struct stack *stk = &stacks[cpu];
-- 
1.7.10.4




From catalin.marinas at arm.com  Thu Apr 18 12:22:33 2013
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Thu, 18 Apr 2013 17:22:33 +0100
Subject: [PATCH] Report double word access atomicity on LPAE enabled
 targets through AUXV
In-Reply-To: <20130416172258.GE3770@mudshark.cambridge.arm.com>
References: <C3FF039D-7DE3-4A99-8317-789094095D8B@oracle.com>
 <20130408142406.GL17995@n2100.arm.linux.org.uk>
 <20130408155749.GS17476@mudshark.cambridge.arm.com>
 <CD54D5A4-2E19-49D9-B6E7-051F36AB5DF8@oracle.com>
 <20130416172258.GE3770@mudshark.cambridge.arm.com>
Message-ID: <20130418162232.GB23112@arm.com>

On Tue, Apr 16, 2013 at 06:22:59PM +0100, Will Deacon wrote:
> On Fri, Apr 12, 2013 at 09:58:43PM +0100, Vladimir Danushevsky wrote:
> > On Apr 8, 2013, at 11:57 AM, Will Deacon wrote:
> > > Actually, it's not just the presence of those instructions -- it's their
> > > behaviour wrt atomicity. They are only guaranteed to be atomic if the CPU in
> > > question supports LPAE. We could call it "lpae" but it might be set even
> > > when the kernel is using the short-descriptor format.
> > 
> > I also think that ATOMICD would describe the intended behavior better.
> 
> I started having second thoughts about the name, on the offchance that some
> other feature introduced with LPAE is found to be useful to userspace. Then
> userspace would end up checking ATOMICD in order to determine something
> different, which is counter-intuitive.
> 
> Maybe there is no other `killer feature' for userspace with LPAE, but at
> least we'd be reporting what the hardware says, rather than the small bit
> which we're interested in.
> 
> Patch below...
> 
> Will
> 
> --->8
> 
> commit c6eaaa758c7956b18aa0cfabe9500ef73514b319
> Author: Will Deacon <will.deacon at arm.com>
> Date:   Mon Apr 8 17:13:12 2013 +0100
> 
>     ARM: elf: add new hwcap for identifying atomic ldrd/strd instructions
>     
>     CPUs implementing LPAE have atomic ldrd/strd instructions, meaning that
>     userspace software can avoid having to use the exclusive variants of
>     these instructions if they wish.
>     
>     This patch advertises the atomicity of these instructions via the
>     hwcaps, so userspace can detect this CPU feature.
>     
>     Signed-off-by: Will Deacon <will.deacon at arm.com>
> 
> diff --git a/arch/arm/include/uapi/asm/hwcap.h b/arch/arm/include/uapi/asm/hwcap.h
> index 3688fd1..6d34d08 100644
> --- a/arch/arm/include/uapi/asm/hwcap.h
> +++ b/arch/arm/include/uapi/asm/hwcap.h
> @@ -25,6 +25,6 @@
>  #define HWCAP_IDIVT    (1 << 18)
>  #define HWCAP_VFPD32   (1 << 19)       /* set if VFP has 32 regs (not 16) */
>  #define HWCAP_IDIV     (HWCAP_IDIVA | HWCAP_IDIVT)
> -
> +#define HWCAP_LPAE     (1 << 20)

I would rather add individual entries like atomicd. User space does not
need to know whether LPAE is supported or not.

-- 
Catalin


From olof at lixom.net  Thu Apr 18 12:25:45 2013
From: olof at lixom.net (Olof Johansson)
Date: Thu, 18 Apr 2013 09:25:45 -0700
Subject: [GIT PULL 4/4] ARM: imx: device tree changes for 3.10
In-Reply-To: <1365520775-28478-4-git-send-email-shawn.guo@linaro.org>
References: <1365520775-28478-1-git-send-email-shawn.guo@linaro.org>
 <1365520775-28478-4-git-send-email-shawn.guo@linaro.org>
Message-ID: <20130418162545.GA7083@quad.lixom.net>

Hi,

On Tue, Apr 09, 2013 at 11:19:35PM +0800, Shawn Guo wrote:
> Hi Arnd, Olof,
> 
> It's based on imx-cleanup-3.10 and Stephen Warren's "[GIT PULL] dt:
> run C pre-processor on *.dts, create some standard headers" to resolve
> dependency and conflicts.
> 

That's not adequate description of a dependency. We need to know what git
branch, not what patch posting, this is based on. And we need to make sure that
said git branch will never be rebased on the way up to Linus. That's
a three-way handshake between you, us and the maintainer with that dependency
in his tree.

> The following changes since commit 8b9ad9f67d094efd2c2765d82cc1866bee9052c2:
> 
>   Merge remote-tracking branch 'swarren/for-3.10/dtc-cpp-chroot-std-headers' into imx/dt (2013-04-09 22:52:42 +0800)
> 
> are available in the git repository at:
> 
>   git://git.linaro.org/people/shawnguo/linux-2.6.git tags/imx-dt-3.10
> 

Pulled, after finding Rob Herring's tree and finding him on irc to make sure he
doesn't rebase that branch.


-Olof


From grygorii.strashko at ti.com  Thu Apr 18 12:29:35 2013
From: grygorii.strashko at ti.com (Grygorii Strashko)
Date: Thu, 18 Apr 2013 19:29:35 +0300
Subject: [RFC v1] regulator: core: introduce regulator chain locking scheme
In-Reply-To: <20130415164018.GA14064@sirena.org.uk>
References: <1366031015-17073-1-git-send-email-grygorii.strashko@ti.com>
 <1366031015-17073-2-git-send-email-grygorii.strashko@ti.com>
 <20130415155040.GD15837@opensource.wolfsonmicro.com>
 <516C2905.8000200@ti.com> <20130415164018.GA14064@sirena.org.uk>
Message-ID: <51701F6F.7070206@ti.com>

On 04/15/2013 07:40 PM, Mark Brown wrote:
> On Mon, Apr 15, 2013 at 07:21:25PM +0300, Andrii Tseglytskyi wrote:
>> On 04/15/2013 06:50 PM, Mark Brown wrote:
>>>> In addition, such locking scheme allows to have access to the supplier
>>>> regulator API from inside child's (consumer) regulator API.
>>> I've still not seen any use case articulated for doing this...
>> Use case is introduced in ABB series:
> Sorry, I meant any sensible use case.
Hi Mark,

Thanks for you comments. I'll split it to 3 patches:
- abstract locking out into helper functions;
- introduce regulator chain locking scheme
- allow reentrant calls into the regulator framework (with hope that is 
has future,
may be can enable/disable it through constraints)

I understand that Regulator FW is common and wide used and we should 
very careful here.

Regards,
- grygorii


From olof at lixom.net  Thu Apr 18 12:32:13 2013
From: olof at lixom.net (Olof Johansson)
Date: Thu, 18 Apr 2013 09:32:13 -0700
Subject: [PATCH 2/3] ARM: tegra: fix relocation truncated error when
 THUMB2_KERNEL enabled
In-Reply-To: <1366066255-18192-2-git-send-email-swarren@wwwdotorg.org>
References: <1366066255-18192-1-git-send-email-swarren@wwwdotorg.org>
 <1366066255-18192-2-git-send-email-swarren@wwwdotorg.org>
Message-ID: <20130418163213.GC7083@quad.lixom.net>

On Mon, Apr 15, 2013 at 04:50:54PM -0600, Stephen Warren wrote:
> From: Joseph Lo <josephl at nvidia.com>
> 
> The conditional branch instruction in Thumb2 only available to short range.
> The linker will fail when the conditional branch over the range. Then
> resulting in link error when generating kernel image. e.g.:
> 
> arch/arm/mach-tegra/reset-handler.S:47:(.text+0xf8e):
> relocation truncated to fit: R_ARM_THM_JUMP19 against symbol
> `cpu_resume' defined in .data section in arch/arm/kernel/built-in.o
> 
> This patch using a Thumb2 instruction IT (if-then) to have a longer branch
> range.
> 
> Reported-by: Arnd Bergmann <arnd at arndb.de>
> Signed-off-by: Joseph Lo <josephl at nvidia.com>
> Signed-off-by: Stephen Warren <swarren at nvidia.com>


Applied to fixes-non-critical.


-Olof


From olof at lixom.net  Thu Apr 18 12:32:52 2013
From: olof at lixom.net (Olof Johansson)
Date: Thu, 18 Apr 2013 09:32:52 -0700
Subject: [PATCH 3/3] ARM: tegra: make sure the pointer on 4 byte align
 when THUMB2_KERNEL enabled
In-Reply-To: <516D7A3B.9030404@wwwdotorg.org>
References: <1366066255-18192-1-git-send-email-swarren@wwwdotorg.org>
 <1366066255-18192-3-git-send-email-swarren@wwwdotorg.org>
 <20130416141252.GA2229@linaro.org> <516D7A3B.9030404@wwwdotorg.org>
Message-ID: <20130418163252.GD7083@quad.lixom.net>

On Tue, Apr 16, 2013 at 10:20:11AM -0600, Stephen Warren wrote:
> Arnd, Olof, I guess let's drop this once patch from this series, but
> apply the other two, and I'll send an updated version of this one patch.
> Thanks.

Ok.


From nicolas.ferre at atmel.com  Thu Apr 18 12:34:41 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Thu, 18 Apr 2013 18:34:41 +0200
Subject: [PATCH 5/5] ARM: at91: add Acme Systems Fox G20 board
In-Reply-To: <a647ac59d50fdee9a0e9e87f362febe1ad2b1264.1366289869.git.nicolas.ferre@atmel.com>
References: <cover.1366289869.git.nicolas.ferre@atmel.com>
 <a647ac59d50fdee9a0e9e87f362febe1ad2b1264.1366289869.git.nicolas.ferre@atmel.com>
Message-ID: <517020A1.3070504@atmel.com>

On 04/18/2013 03:01 PM, Nicolas Ferre :
> From: Douglas Gilbert <dgilbert at interlog.com>
> 
> Signed-off-by: Douglas Gilbert <dgilbert at interlog.com>
> Signed-off-by: Nicolas Ferre <nicolas.ferre at atmel.com>
> ---
>  arch/arm/boot/dts/Makefile        |   1 +
>  arch/arm/boot/dts/at91-foxg20.dts | 166 ++++++++++++++++++++++++++++++++++++++

FYI: I have to review this one: error while compiling.

>  2 files changed, 167 insertions(+)
>  create mode 100644 arch/arm/boot/dts/at91-foxg20.dts
> 
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index b07f162..914fe65 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -16,6 +16,7 @@ dtb-$(CONFIG_ARCH_AT91) += at91sam9263ek.dtb
>  dtb-$(CONFIG_ARCH_AT91) += tny_a9263.dtb
>  dtb-$(CONFIG_ARCH_AT91) += usb_a9263.dtb
>  # sam9g20
> +dtb-$(CONFIG_ARCH_AT91) += at91-foxg20.dtb
>  dtb-$(CONFIG_ARCH_AT91) += at91sam9g20ek.dtb
>  dtb-$(CONFIG_ARCH_AT91) += at91sam9g20ek_2mmc.dtb
>  dtb-$(CONFIG_ARCH_AT91) += kizbox.dtb
> diff --git a/arch/arm/boot/dts/at91-foxg20.dts b/arch/arm/boot/dts/at91-foxg20.dts
> new file mode 100644
> index 0000000..7d24ef7
> --- /dev/null
> +++ b/arch/arm/boot/dts/at91-foxg20.dts
> @@ -0,0 +1,166 @@
> +/*
> + * at91-foxg20.dts - Device Tree file for Acme Systems FoxG20 board
> + *
> + * Based on DT files for at91sam9g20ek evaluation board (AT91SAM9G20 SoC)
> + *
> + * Copyright (C) 2013 Douglas Gilbert <dgilbert at interlog.com>
> + *
> + * Licensed under GPLv2 or later.
> + */
> +/dts-v1/;
> +/include/ "at91sam9g20.dtsi"
> +
> +/ {
> +	model = "Acme Systems FoxG20";
> +	compatible = "acme,foxg20", "atmel,at91sam9g20", "atmel,at91sam9";
> +
> +	chosen {
> +		bootargs = "console=ttyS0,115200 root=/dev/mmcblk0p2 rw rootwait";
> +	};
> +
> +	memory {
> +		reg = <0x20000000 0x4000000>;
> +	};
> +
> +	clocks {
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +		ranges;
> +
> +		main_clock: clock at 0 {
> +			compatible = "atmel,osc", "fixed-clock";
> +			clock-frequency = <18432000>;
> +		};
> +	};
> +
> +	ahb {
> +		apb {
> +			usb1: gadget at fffa4000 {
> +				atmel,vbus-gpio = <&pioC 6 0>;
> +				status = "okay";
> +			};
> +
> +			mmc0: mmc at fffa8000 {
> +				pinctrl-0 = <
> +					&pinctrl_mmc0_clk
> +					&pinctrl_mmc0_slot1_cmd_dat0
> +					&pinctrl_mmc0_slot1_dat1_3>;
> +				status = "okay";
> +				slot at 1 {
> +					reg = <1>;
> +					bus-width = <4>;
> +				};
> +			};
> +
> +			usart0: serial at fffb0000 {
> +				pinctrl-0 =
> +					<&pinctrl_usart0
> +					 &pinctrl_usart0_rts
> +					 &pinctrl_usart0_cts
> +					>;
> +				status = "okay";
> +			};
> +
> +			usart1: serial at fffb4000 {
> +				status = "okay";
> +			};
> +
> +			usart2: serial at fffb8000 {
> +				status = "okay";
> +			};
> +
> +			macb0: ethernet at fffc4000 {
> +				phy-mode = "rmii";
> +				status = "okay";
> +			};
> +
> +			spi0: spi at fffc8000 {
> +				cs-gpios = <0>, <&pioC 11 0>, <0>, <0>;
> +				mtd_dataflash at 0 {
> +					compatible = "atmel,at45", "atmel,dataflash";
> +					spi-max-frequency = <50000000>;
> +					reg = <1>;
> +				};
> +				status = "disabled";
> +			};
> +
> +			usart3: serial at fffd0000 {
> +				status = "okay";
> +			};
> +
> +			uart0: serial at fffd4000 {
> +				status = "okay";
> +			};
> +
> +			uart1: serial at fffd8000 {
> +				status = "okay";
> +			};
> +
> +			dbgu: serial at fffff200 {
> +				status = "okay";
> +			};
> +
> +			pinctrl at fffff400 {
> +				board {
> +					pinctrl_pck0_as_mck: pck0_as_mck {
> +						atmel,pins =
> +							<2 1 0x2 0x0>;	/* PC1 periph B */
> +					};
> +				};
> +
> +				mmc0_slot1 {
> +					pinctrl_board_mmc0_slot1: mmc0_slot1-board {
> +						atmel,pins =
> +							<2 9 0x0 0x5>;	/* PC9 gpio CD pin pull up and deglitch */
> +					};
> +				};
> +
> +				i2c0 {
> +					pinctrl_i2c0: i2c0-0 {
> +						atmel,pins =
> +							<0 23 0x1 0x2	/* TWD (SDA) PA23 periph A, open drain */
> +							 0 24 0x1 0x2>;	/* TWCK (SCL) PA24 periph A, open drain */
> +					};
> +				};
> +			};
> +
> +			watchdog at fffffd40 {
> +				status = "okay";
> +			};
> +		};
> +
> +		usb0: ohci at 00500000 {
> +			num-ports = <2>;
> +			status = "okay";
> +		};
> +	};
> +
> +	i2c at 0 {
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&pinctrl_i2c0>;
> +		i2c-gpio,delay-us = <5>;	/* ~85 kHz */
> +		status = "okay";
> +	};
> +
> +	leds {
> +		compatible = "gpio-leds";
> +
> +		/* red LED marked "PC7" near mini USB (device) receptacle */
> +		user_led {
> +			label = "user_led";
> +			gpios = <&pioC 7 0>;	/* PC7 */
> +			linux,default-trigger = "heartbeat";
> +		};
> +	};
> +
> +	gpio_keys {
> +		compatible = "gpio-keys";
> +
> +		btn {
> +			label = "Button";
> +			gpios = <&pioC 4 1>;
> +			linux,code = <0x103>;
> +			gpio-key,wakeup;
> +		};
> +	};
> +};
> 


-- 
Nicolas Ferre


From olof at lixom.net  Thu Apr 18 12:35:02 2013
From: olof at lixom.net (Olof Johansson)
Date: Thu, 18 Apr 2013 09:35:02 -0700
Subject: [PATCH] ARM: tegra: pm: fix build error w/o PM_SLEEP
In-Reply-To: <1366066385-18246-1-git-send-email-swarren@wwwdotorg.org>
References: <1366066385-18246-1-git-send-email-swarren@wwwdotorg.org>
Message-ID: <20130418163502.GE7083@quad.lixom.net>

On Mon, Apr 15, 2013 at 04:53:05PM -0600, Stephen Warren wrote:
> From: Joseph Lo <josephl at nvidia.com>
> 
> This fixes the building error when the PM_SLEEP is disabled. The fucntional
> defintion of "tegra_pm_validate_suspend_mode" without "static inline"
> would become a multiple definition error.
> 
> Reported-by: Rhyland Klein <rklein at nvidia.com>
> Signed-off-by: Joseph Lo <josephl at nvidia.com>
> Signed-off-by: Stephen Warren <swarren at nvidia.com>
> ---
> Arnd, Olof, can you please apply this to arm-soc too.

Applied.


-Olof


From nicolas.pitre at linaro.org  Thu Apr 18 12:35:57 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Thu, 18 Apr 2013 12:35:57 -0400 (EDT)
Subject: [PATCH v6 1/4] arm: introduce psci_smp_ops
In-Reply-To: <alpine.DEB.2.02.1304181714560.7254@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1304031239550.5078@kaball.uk.xensource.com>
 <1365167495-18508-1-git-send-email-stefano.stabellini@eu.citrix.com>
 <20130418161341.GB14496@n2100.arm.linux.org.uk>
 <alpine.DEB.2.02.1304181714560.7254@kaball.uk.xensource.com>
Message-ID: <alpine.LFD.2.03.1304181233580.17375@syhkavp.arg>

On Thu, 18 Apr 2013, Stefano Stabellini wrote:

> On Thu, 18 Apr 2013, Russell King - ARM Linux wrote:
> > On Fri, Apr 05, 2013 at 02:11:32PM +0100, Stefano Stabellini wrote:
> > > +	psci_init();
> > >  #ifdef CONFIG_SMP
> > >  	if (is_smp()) {
> > > -		smp_set_ops(mdesc->smp);
> > > +		if (mdesc->smp)
> > > +			smp_set_ops(mdesc->smp);
> > > +		else if (psci_smp_available())
> > > +			smp_set_ops(&psci_smp_ops);
> > 
> > So, I have a vague recollection that the ordering of the above got discussed
> > but I can't find it amongst the 21k of messages so far this year.
> > 
> > The above looks weird to me.  Surely this should be:
> > 
> > 		if (psci_smp_available())
> > 			smp_set_ops(&psci_smp_ops);
> > 		else if (mdesc->smp)
> > 			smp_set_ops(mdesc->ops);
> > 
> > This means that if PSCI is available, and provides a set of operations,
> > we override whatever the platform has statically provided.
> > 
> > Remember, we're trying to move away from using "mdesc"s for platform
> > stuff, relying on things like DT and such like.  We really should not
> > be going for mdesc-overriding-newstuff but newstuff-overriding-mdesc.
> 
> That's correct, in fact if you look at the next patch you'll see that it
> changes the order.
> 
> I introduced the mechanism first and changed the priority later - it
> should help bisectability.
> I can fold the two patches into one if you prefer.

Please let's keep the order as we discussed.  Otherwise this is just too 
confusing (Russell's comment is a good example of that).


Nicolas


From bhelgaas at google.com  Thu Apr 18 12:35:45 2013
From: bhelgaas at google.com (Bjorn Helgaas)
Date: Thu, 18 Apr 2013 10:35:45 -0600
Subject: I/O and multiple PCI buses
In-Reply-To: <20130418152747.GA19258@arm.com>
References: <20130418152747.GA19258@arm.com>
Message-ID: <CAErSpo5PnUC4h2Eg7BPUOvUUPQmpUPwZGO89PVJu4qw5ysGX6A@mail.gmail.com>

On Thu, Apr 18, 2013 at 9:27 AM, Andrew Murray <andrew.murray at arm.com> wrote:
> I'm trying to understand PCI I/O addressing in the kernel... (again)
>
> I understand that ideally you want to give PCI bus addresses to PCI devices in
> the range of 0K to 64K. This seems to be achieved in pcibios_init_resources in
> arm's kernel/bios32.c implementation.
>
> What happens if you want to add another root bus? In this implementation the
> start address of the io_res is now 64K and as sys->io_offset is set to 0 the
> bus addresses under this second root bus will be 64K-128K - which I assume may
> break some things.
>
> Am I correct that for ARM there are no implementations where subsequent root
> buses allocate I/O starting from 0?
>
> And to allow subsequent busses to use I/O starting from 0, you'd have to set
> sys->io_offset to 64K*nr and adapt functions such as pci_iomap to use the
> offset?
>
> Are there any other archiectures that do give I/O ranges starting from 0 in
> subsequent root busses? Or am I missing something here?

I don't know the details about ARM, but there are ia64 systems with
many host bridges, and often they're set up so the I/O port addresses
on the PCI bus are always between 0-64K, e.g.,

pci_root HWP0002:00: host bridge window [io  0x0000-0x0fff]
pci_root HWP0002:01: host bridge window [io  0x1000-0x1fff]
pci_root HWP0002:02: host bridge window [io  0x2000-0x3fff]
pci_root HWP0002:03: host bridge window [io  0x4000-0x5fff]
pci_root HWP0002:04: host bridge window [io  0x6000-0x7fff]
pci_root HWP0002:05: host bridge window [io  0x8000-0x9fff]
pci_root HWP0002:06: host bridge window [io  0xa000-0xbfff]
pci_root HWP0002:07: host bridge window [io  0xc000-0xdfff]
pci_root HWP0002:08: host bridge window [io  0xe000-0xffff]
pci_root HWP0002:09: host bridge window [io  0x1000000-0x1000fff] (PCI
address [0x0-0xfff])
pci_root HWP0002:0a: host bridge window [io  0x1001000-0x1001fff] (PCI
address [0x1000-0x1fff])
pci_root HWP0002:0b: host bridge window [io  0x1002000-0x1003fff] (PCI
address [0x2000-0x3fff])
pci_root HWP0002:0c: host bridge window [io  0x1004000-0x1005fff] (PCI
address [0x4000-0x5fff])
pci_root HWP0002:0d: host bridge window [io  0x1006000-0x1007fff] (PCI
address [0x6000-0x7fff])
pci_root HWP0002:0e: host bridge window [io  0x1008000-0x1009fff] (PCI
address [0x8000-0x9fff])
pci_root HWP0002:0f: host bridge window [io  0x100a000-0x100bfff] (PCI
address [0xa000-0xbfff])
pci_root HWP0002:10: host bridge window [io  0x100c000-0x100dfff] (PCI
address [0xc000-0xdfff])
pci_root HWP0002:11: host bridge window [io  0x100e000-0x100ffff] (PCI
address [0xe000-0xffff])

In this case, host bridges HWP0002:00 - HWP0002:08 all share one 64K
I/O port space, and HWP0002:09 - HWP0002:11 share a separate one.
There's no requirement that they share any space -- each host bridge
*could* have its own 64K I/O port space, but we just use the
configuration done by the firmware.

Note that for HWP0002:00 and HWP0002:09, for example, the addresses on
PCI are the same (0x0-0xfff), but the CPU addresses in the struct
resource are different.  The CPU addresses are what drivers see, and
what they pass to inb(), etc., and it's possible there are drivers
that assume these port addresses fit in a u16, and those drivers would
break.  But as far as the hardware PCI device is concerned, it should
be fine because it sees only bus addresses in the 0-64K range.

There's some gunk in arch/ia64/include/asm/io.h to make
"inb(0x1000000)" work and generate a bus access to I/O port 0 on the
correct root bus.

Bjorn


From olof at lixom.net  Thu Apr 18 12:36:11 2013
From: olof at lixom.net (Olof Johansson)
Date: Thu, 18 Apr 2013 09:36:11 -0700
Subject: [PATCH] ARM: tegra: solve adr range issue with THUMB2_KERNEL
 enabled
In-Reply-To: <1366132149-17294-1-git-send-email-swarren@wwwdotorg.org>
References: <1366132149-17294-1-git-send-email-swarren@wwwdotorg.org>
Message-ID: <20130418163611.GF7083@quad.lixom.net>

On Tue, Apr 16, 2013 at 11:09:09AM -0600, Stephen Warren wrote:
> From: Stephen Warren <swarren at nvidia.com>
> 
> When building the kernel with CONFIG_THUMB2_KERNEL enabled, older
> assemblers may emit the following error:
> 
> reset-handler.S:78: Error: invalid immediate for address calculation (value = 0x00000004)
> 
> Using an explicit adr.w instruction will solve this. Newer assemblers do
> this automatically. Use the W() macro to do this under Thumb mode only.
> 
> Inspired-by: Joseph Lo <josephl at nvidia.com>
> Suggested-by: Dave Martin <dave.martin at linaro.org>
> Signed-off-by: Stephen Warren <swarren at nvidia.com>
> ---
> Olof, Arnd,
> 
> Can you please apply this directly to arm-soc. Thanks.
> 
> This patch replaces patch 3/3 "ARM: tegra: make sure the pointer on 4
> byte align when THUMB2_KERNEL enabled" which I forwarded yesterday. It
> can be applied to wherever Tegra's for-3.10/fixes branch was applied,
> and doesn't cause any conflicts/merge-issues with any other Tegra patches
> this cycle.


Applied.


-Olof


From olof at lixom.net  Thu Apr 18 12:38:23 2013
From: olof at lixom.net (Olof Johansson)
Date: Thu, 18 Apr 2013 09:38:23 -0700
Subject: [PATCH] ARM: highbank: fix cache flush ordering for cpu hotplug
In-Reply-To: <1366213612-13526-1-git-send-email-robherring2@gmail.com>
References: <1366213612-13526-1-git-send-email-robherring2@gmail.com>
Message-ID: <20130418163823.GG7083@quad.lixom.net>

On Wed, Apr 17, 2013 at 10:46:52AM -0500, Rob Herring wrote:
> From: Rob Herring <rob.herring at calxeda.com>
> 
> The L1 data cache flush needs to be after highbank_set_cpu_jump call which
> pollutes the cache with the l2x0_lock. This causes other cores to deadlock
> waiting for the l2x0_lock. Moving the flush of the entire data cache after
> highbank_set_cpu_jump fixes the problem. Use flush_cache_louis instead of
> flush_cache_all are that is sufficient to flush only the L1 data cache.
> flush_cache_louis did not exist when highbank_cpu_die was originally
> written.
> 
> With PL310 errata 769419 enabled, a wmb is inserted into idle which takes
> the l2x0_lock. This makes the problem much more easily hit and causes
> reset to hang.
> 
> Reported-by: Paolo Pisati <p.pisati at gmail.com>
> Signed-off-by: Rob Herring <rob.herring at calxeda.com>
> ---
> Olof, Arnd,
> 
> If you have any more 3.9 fixes, please send this in. Otherwise, it can
> wait for 3.10 and mark for stable.

Applied to fixes.


-Olof


From olof at lixom.net  Thu Apr 18 12:39:09 2013
From: olof at lixom.net (Olof Johansson)
Date: Thu, 18 Apr 2013 09:39:09 -0700
Subject: [PATCHv4 00/11] Remove ARM local timer API
In-Reply-To: <516F09AA.2000902@codeaurora.org>
References: <1365456453-16297-1-git-send-email-sboyd@codeaurora.org>
 <516F09AA.2000902@codeaurora.org>
Message-ID: <20130418163909.GH7083@quad.lixom.net>

On Wed, Apr 17, 2013 at 01:44:26PM -0700, Stephen Boyd wrote:
> Thomas,
> 
> Would you be able to pick up patches 1 and 2 from this series and
> publish it as a stable branch? Preferably based on rc5 but I can always
> merge it to rc5 and apply the rest of the patches.
> 
> Arnd/Olof,
> 
> Would you be able to merge in the rest of the patches to arm-soc? I can
> provide a branch on 3.9-rc5 and a merge resolution with for-next in
> arm-soc that you can pull to look at.
> 
> If not I will have to resend the series.

Hi,

I think this is 3.11 material at this point, so please send a fresh pull
request (or re-ask us to apply it) after -rc1.


-Olof


From nicolas.pitre at linaro.org  Thu Apr 18 12:40:05 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Thu, 18 Apr 2013 12:40:05 -0400 (EDT)
Subject: [PATCH v6 1/4] arm: introduce psci_smp_ops
In-Reply-To: <alpine.DEB.2.02.1304181714560.7254@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1304031239550.5078@kaball.uk.xensource.com>
 <1365167495-18508-1-git-send-email-stefano.stabellini@eu.citrix.com>
 <20130418161341.GB14496@n2100.arm.linux.org.uk>
 <alpine.DEB.2.02.1304181714560.7254@kaball.uk.xensource.com>
Message-ID: <alpine.LFD.2.03.1304181237480.17375@syhkavp.arg>

On Thu, 18 Apr 2013, Stefano Stabellini wrote:

> On Thu, 18 Apr 2013, Russell King - ARM Linux wrote:
> > This should allow the Xen problem to be resolved, because Xen will
> > provide the PSCI operations, and it's correct in that case to override
> > the platform's SMP operations.
> 
> Yes, increasing the priority of PSCI helps Xen a lot.
> In order to completely solve the issue for Xen though, another patch is
> needed (http://marc.info/?l=linux-kernel&m=136630106201968&w=2) because
> of the introduction of smp_init.

Please look at the latest smp_init patch version I sent to you.  It 
shouldn't conflict with Xen any longer.  It now returns a bool result 
depending on whether it did set up smp_ops or not.


Nicolas


From olof at lixom.net  Thu Apr 18 12:31:58 2013
From: olof at lixom.net (Olof Johansson)
Date: Thu, 18 Apr 2013 09:31:58 -0700
Subject: [PATCH 1/3] ARM: tegra: fix build error when THUMB2_KERNEL enabled
In-Reply-To: <1366066255-18192-1-git-send-email-swarren@wwwdotorg.org>
References: <1366066255-18192-1-git-send-email-swarren@wwwdotorg.org>
Message-ID: <20130418163158.GB7083@quad.lixom.net>

On Mon, Apr 15, 2013 at 04:50:53PM -0600, Stephen Warren wrote:
> From: Joseph Lo <josephl at nvidia.com>
> 
> This patch fix the build failure when CONFIG_THUBM2_KERNEL enabled. You
> clould see the error message below:
> 
> arch/arm/mach-tegra/sleep-tegra30.S:69: Error: shift must be constant --
> `orr r12,r12,r4,lsl r3'
> 
> Reported-by: Arnd Bergmann <arnd at arndb.de>
> Signed-off-by: Joseph Lo <josephl at nvidia.com>
> Signed-off-by: Stephen Warren <swarren at nvidia.com>
> ---
> Arnd, Olof, here are 3 fixes from Joseph for some Tegra build issues,
> mostly exposed by multi-platform enablement and/or related randconfig
> testing.
> 
> Can you please apply these to arm-soc? For reference, I tested applying
> them to Tegra's for-3.10/fixes branch and they apply there fine, and
> merge with the other Tegra for-3.10 branches at least, without any issue.
> 
> Note: patch 3 triggers checkpatch, but I can't work out why; the code
> seems to be formatted the same as patch 1 and 2, and is consistent with
> other usage of ARM() and THUMB() macros in arch/arm/.


Applied to fixes-non-critical.


-Olof


From jon-hunter at ti.com  Thu Apr 18 12:46:07 2013
From: jon-hunter at ti.com (Jon Hunter)
Date: Thu, 18 Apr 2013 11:46:07 -0500
Subject: [PATCH] gpio/omap: ensure gpio context is initialised
In-Reply-To: <516FAD48.4020304@ti.com>
References: <1366230707-32681-1-git-send-email-jon-hunter@ti.com>
 <516FAD48.4020304@ti.com>
Message-ID: <5170234F.7010707@ti.com>


On 04/18/2013 03:22 AM, Santosh Shilimkar wrote:
> On Thursday 18 April 2013 02:01 AM, Jon Hunter wrote:
>> Commit a2797be (gpio/omap: force restore if context loss is not
>> detectable) broke gpio support for OMAP when booting with device-tree
>> because a restore of the gpio context being performed without ever
>> initialising the gpio context. In other words, the context restored was
>> bad.
>>
>> This problem could also occur in the non device-tree case, however, it
>> is much less likely because when booting without device-tree we can
>> detect context loss via a platform specific API and so context restore
>> is performed less often.
>>
>> Nevertheless we should ensure that the gpio context is initialised
>> during the probe for gpio banks that could lose their state regardless
>> of whether we are booting with device-tree or not.
>>
>> Reported-by: Tony Lindgren <tony at atomide.com>
>> Signed-off-by: Jon Hunter <jon-hunter at ti.com>
>> Tested-by: Tony Lindgren <tony at atomide.com>
>> ---
>>  drivers/gpio/gpio-omap.c |   53 +++++++++++++++++++++++++++++++++++++---------
>>  1 file changed, 43 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
>> index 0557529..0ba5cb9 100644
>> --- a/drivers/gpio/gpio-omap.c
>> +++ b/drivers/gpio/gpio-omap.c
>> @@ -70,6 +70,7 @@ struct gpio_bank {
>>  	bool is_mpuio;
>>  	bool dbck_flag;
>>  	bool loses_context;
>> +	bool context_valid;
>>  	int stride;
>>  	u32 width;
>>  	int context_loss_count;
>> @@ -1085,6 +1086,7 @@ static void omap_gpio_chip_init(struct gpio_bank *bank)
>>  }
>>  
>>  static const struct of_device_id omap_gpio_match[];
>> +static void omap_gpio_init_context(struct gpio_bank *p);
>>  
>>  static int omap_gpio_probe(struct platform_device *pdev)
>>  {
>> @@ -1179,8 +1181,10 @@ static int omap_gpio_probe(struct platform_device *pdev)
>>  	omap_gpio_chip_init(bank);
>>  	omap_gpio_show_rev(bank);
>>  
>> -	if (bank->loses_context)
>> +	if (bank->loses_context) {
>>  		bank->get_context_loss_count = pdata->get_context_loss_count;
>> +		omap_gpio_init_context(bank);
>> +	}
>>  
>>  	pm_runtime_put(bank->dev);
>>  
>> @@ -1269,6 +1273,14 @@ static int omap_gpio_runtime_resume(struct device *dev)
>>  	int c;
>>  
>>  	spin_lock_irqsave(&bank->lock, flags);
>> +
>> +	/*
>> +	 * On the first resume during the probe, the context has not
>> +	 * been initialised and so if the context is not valid return.
>> +	 */
>> +	if (!bank->context_valid)
>> +		goto done;
>> +
> The use of 'context_valid' is just for the probe resume case and hence
> adding a state variable for GPIO bank structures looks bit too much.

Yes it is not ideal. However, it is safe.

> Ideally gpio_init_context() should make the first callback successful
> as well if ordered correctly but then you need clocks for that
> to happen which are enabled in runtime pm calls. 

Right.

> Do you really need that "context_valid" flag per bank ? I mean
> every gpio bank which can "loses_context", probe time context
> validity is an issue, right ? In that case, won't just an
> __init static variable do for all banks which can loose
> context?

I think that it would be fragile to have a global for all banks. What
happens if one bank failed during the probe? Probably unlikely but still.

The best solution would be to be able to plug the pm-runtime
resume/suspend handlers at the end of the probe or be able to enable the
module without the callback handlers being calling during the probe. I
am not sure if there is a way to do this. May be Kevin knows.

Another option is to move the initialisation of the bank->loses_context
to after the call to pm_runtime_get_sync() in the probe. This would
prevent the context restore occurring during the initial runtime resume.
However, if you look at the runtime resume function there are still some
register writes that do occur (which is basically what happens today).
This works but it is a little fragile, however, we can do that if
preferred. May be I could add a comment to the probe to say why we
initialise bank->loses_context after the pm_runtime_get_sync() so no one
moves this in the future (and more importantly I don't forget!).

Cheers
Jon


From broonie at kernel.org  Thu Apr 18 12:46:42 2013
From: broonie at kernel.org (Mark Brown)
Date: Thu, 18 Apr 2013 17:46:42 +0100
Subject: [PATCH 29/30] spi: s3c64xx: move to generic dmaengine API
In-Reply-To: <201304172205.35526.arnd@arndb.de>
References: <1365638712-1028578-1-git-send-email-arnd@arndb.de>
 <1365638712-1028578-30-git-send-email-arnd@arndb.de>
 <201304172205.35526.arnd@arndb.de>
Message-ID: <20130418164642.GM13687@opensource.wolfsonmicro.com>

On Wed, Apr 17, 2013 at 10:05:35PM +0200, Arnd Bergmann wrote:
> On Thursday 11 April 2013, Arnd Bergmann wrote:

> > +               use_dma = 0;
> > +               if (sdd->rx_dma.ch && sdd->tx_dma.ch &&
> > +                   (xfer->len > ((FIFO_LVL_MASK(sdd) >> 1) + 1)))
> >                         use_dma = 1;

> Can you try just reverting this hunk? It's actually not required and
> comes from an earlier version of the patch. I assumed it was harmless,
> but it's the only think I see that should actually make a difference
> in my patch for the case of !CONFIG_SAMSUNG_DMADEV.

That's not it, the checks are now needed - otherwise we get a null
pointer dereference in prepare_dma() instead.  What's actually gone
wrong is that your ifdefs are for SAMSUNG_DMADEV instead of S3C_DMA
so s3c64xx is trying to use dmaengine.  The driver doesn't actually
check to see if it failed to get the channels so it then tries to do the
transfer with a missing channel which unsurprisingly fails.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130418/2458eed6/attachment-0001.sig>

From stefano.stabellini at eu.citrix.com  Thu Apr 18 12:49:21 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Thu, 18 Apr 2013 17:49:21 +0100
Subject: [PATCH v6 1/4] arm: introduce psci_smp_ops
In-Reply-To: <alpine.LFD.2.03.1304181233580.17375@syhkavp.arg>
References: <alpine.DEB.2.02.1304031239550.5078@kaball.uk.xensource.com>
 <1365167495-18508-1-git-send-email-stefano.stabellini@eu.citrix.com>
 <20130418161341.GB14496@n2100.arm.linux.org.uk>
 <alpine.DEB.2.02.1304181714560.7254@kaball.uk.xensource.com>
 <alpine.LFD.2.03.1304181233580.17375@syhkavp.arg>
Message-ID: <alpine.DEB.2.02.1304181748010.7254@kaball.uk.xensource.com>

On Thu, 18 Apr 2013, Nicolas Pitre wrote:
> On Thu, 18 Apr 2013, Stefano Stabellini wrote:
> 
> > On Thu, 18 Apr 2013, Russell King - ARM Linux wrote:
> > > On Fri, Apr 05, 2013 at 02:11:32PM +0100, Stefano Stabellini wrote:
> > > > +	psci_init();
> > > >  #ifdef CONFIG_SMP
> > > >  	if (is_smp()) {
> > > > -		smp_set_ops(mdesc->smp);
> > > > +		if (mdesc->smp)
> > > > +			smp_set_ops(mdesc->smp);
> > > > +		else if (psci_smp_available())
> > > > +			smp_set_ops(&psci_smp_ops);
> > > 
> > > So, I have a vague recollection that the ordering of the above got discussed
> > > but I can't find it amongst the 21k of messages so far this year.
> > > 
> > > The above looks weird to me.  Surely this should be:
> > > 
> > > 		if (psci_smp_available())
> > > 			smp_set_ops(&psci_smp_ops);
> > > 		else if (mdesc->smp)
> > > 			smp_set_ops(mdesc->ops);
> > > 
> > > This means that if PSCI is available, and provides a set of operations,
> > > we override whatever the platform has statically provided.
> > > 
> > > Remember, we're trying to move away from using "mdesc"s for platform
> > > stuff, relying on things like DT and such like.  We really should not
> > > be going for mdesc-overriding-newstuff but newstuff-overriding-mdesc.
> > 
> > That's correct, in fact if you look at the next patch you'll see that it
> > changes the order.
> > 
> > I introduced the mechanism first and changed the priority later - it
> > should help bisectability.
> > I can fold the two patches into one if you prefer.
> 
> Please let's keep the order as we discussed.  Otherwise this is just too 
> confusing (Russell's comment is a good example of that).

You are right, it is confusing.
By "keep the order as we discussed", do you mean merge the second patch
into the first one, correct?


From stefano.stabellini at eu.citrix.com  Thu Apr 18 13:01:14 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Thu, 18 Apr 2013 18:01:14 +0100
Subject: [PATCH v6 1/4] arm: introduce psci_smp_ops
In-Reply-To: <alpine.LFD.2.03.1304181237480.17375@syhkavp.arg>
References: <alpine.DEB.2.02.1304031239550.5078@kaball.uk.xensource.com>
 <1365167495-18508-1-git-send-email-stefano.stabellini@eu.citrix.com>
 <20130418161341.GB14496@n2100.arm.linux.org.uk>
 <alpine.DEB.2.02.1304181714560.7254@kaball.uk.xensource.com>
 <alpine.LFD.2.03.1304181237480.17375@syhkavp.arg>
Message-ID: <alpine.DEB.2.02.1304181749260.7254@kaball.uk.xensource.com>

On Thu, 18 Apr 2013, Nicolas Pitre wrote:
> On Thu, 18 Apr 2013, Stefano Stabellini wrote:
> 
> > On Thu, 18 Apr 2013, Russell King - ARM Linux wrote:
> > > This should allow the Xen problem to be resolved, because Xen will
> > > provide the PSCI operations, and it's correct in that case to override
> > > the platform's SMP operations.
> > 
> > Yes, increasing the priority of PSCI helps Xen a lot.
> > In order to completely solve the issue for Xen though, another patch is
> > needed (http://marc.info/?l=linux-kernel&m=136630106201968&w=2) because
> > of the introduction of smp_init.
> 
> Please look at the latest smp_init patch version I sent to you.  It 
> shouldn't conflict with Xen any longer.  It now returns a bool result 
> depending on whether it did set up smp_ops or not.

CPUs are virtualized by Xen and do not reflect or expose the underlying
SMP hardware and firmware features, so an hardware specific smp_init
cannot run.

So the smp_init patch still breaks Xen because even if smp_init can fail
graciously, executing a platform specific smp_init function that tries
to access registers and memory regions that are not present is going to
cause an undefined behaviour.

Under Xen, smp_init won't have a chance to return any value because it
is going to crash first.


From linux at arm.linux.org.uk  Thu Apr 18 13:18:01 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Thu, 18 Apr 2013 18:18:01 +0100
Subject: [PATCH] ARM: smp: call platform's cpu_die in ipi_cpu_stop
In-Reply-To: <1365251824-4852-2-git-send-email-kevin@bracey.fi>
References: <1365251824-4852-1-git-send-email-kevin@bracey.fi>
 <1365251824-4852-2-git-send-email-kevin@bracey.fi>
Message-ID: <20130418171801.GC14496@n2100.arm.linux.org.uk>

On Sat, Apr 06, 2013 at 03:37:04PM +0300, Kevin Bracey wrote:
> When hotplugging out, both cpu_kill and cpu_die have always been called.
> But when smp_send_stop was used in machine_shutdown or panic, only
> cpu_kill was called.
> 
> This causes problems for co-ordination between cpu_kill and cpu_die, as
> attempted by shmobile. So add cpu_die call to ipi_cpu_stop, to ensure
> that cpu_kill and cpu_die calls always occur together.

Actually, I'd prefer to pull more code out of the platforms.  Now
that we have flush_cache_louis(), we can flush the L1 cache for the
CPU going down in cpu_die() itself.  We just need to be careful
with that complete() call to ensure that becomes visible to other
cores before power is cut to the L1 cache.

That's fine though - because it must become visible for __cpu_die()
to continue (otherwise it will time out).

That should render shmobile's cpu_dead thing unnecessary, because the
platform independent code will do the required synchronisation.


From sboyd at codeaurora.org  Thu Apr 18 13:20:48 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Thu, 18 Apr 2013 10:20:48 -0700
Subject: [RFC PATCH] drivers: bus: add ARM CCI support
In-Reply-To: <1365691679-28674-2-git-send-email-lorenzo.pieralisi@arm.com>
References: <1365691679-28674-1-git-send-email-lorenzo.pieralisi@arm.com>
 <1365691679-28674-2-git-send-email-lorenzo.pieralisi@arm.com>
Message-ID: <51702B70.9000908@codeaurora.org>

On 04/11/13 07:47, Lorenzo Pieralisi wrote:
> diff --git a/drivers/bus/arm-cci.c b/drivers/bus/arm-cci.c
> new file mode 100644
> index 0000000..81953de
> --- /dev/null
> +++ b/drivers/bus/arm-cci.c
[...]
> +static void notrace cci_port_control(unsigned int port, bool enable)
> +{
> +	void __iomem *base = ports[port].base;
> +
> +	if (!base)
> +		return;
> +
> +	writel_relaxed(enable, base + CCI_PORT_CTRL);
> +	while (readl_relaxed(cci_ctrl_base + CCI_CTRL_STATUS) & 0x1)
> +			;

cpu_relax()?

> +}
[...]
> +int notrace __cci_control_port_by_device(struct device_node *np, bool enable)
> +{
> +	int port = cci_ace_lite_port(np);
> +	if (WARN_ONCE(port < 0,
> +		      "ACE lite port look-up failure, node %p\n", np))
> +		return -ENODEV;
> +	cci_port_control(port, enable);
> +	return 0;
> +}
> +EXPORT_SYMBOL_GPL(__cci_control_port_by_device);
> +
> +static const struct of_device_id arm_cci_matches[];

Why not just put the definition here then?

> +
> +static int __init cci_driver_probe(struct platform_device *pdev)

You probably want to drop the __init considering device hotplug is not
optional anymore.

> +{
> +	const struct of_device_id *match;
> +	struct cci_nb_ports const *cci_config;
> +	int ret, j, i, nb_ace = 0, nb_ace_lite = 0;
> +	struct device_node *np, *cp;
> +	const char *match_str;
> +
> +	match = of_match_device(arm_cci_matches, &pdev->dev);
> +
> +	if (!match)
> +		return -ENODEV;

It would be nice if we could get the data field from the of_device_id
without doing the search again. Can we update the of_platform code to
assign some field that you can get from the platform device?

> +
> +	cci_config = (struct cci_nb_ports const *)match->data;
> +	nb_cci_ports = cci_config->nb_ace + cci_config->nb_ace_lite;
> +	ports = kzalloc(sizeof(*ports) * nb_cci_ports, GFP_KERNEL);

kcalloc()?

> +	if (!ports)
> +		return -ENOMEM;
> +
> +	np = pdev->dev.of_node;
> +	cci_ctrl_base = of_iomap(np, 0);

This is a platform driver so we should use non-of functions to map,
platform_get_resource()/ioremap(), etc.

> +}
> +
> +static int __exit cci_driver_remove(struct platform_device *pdev)
> +{

You probably want to drop the __exit here too.


> diff --git a/include/linux/arm-cci.h b/include/linux/arm-cci.h
> new file mode 100644
> index 0000000..e9514a2
> --- /dev/null
> +++ b/include/linux/arm-cci.h
> @@ -0,0 +1,44 @@
> +
> +#ifndef __LINUX_ARM_CCI_H
> +#define __LINUX_ARM_CCI_H
> +
> +#include <linux/errno.h>
> +#include <linux/of.h>
> +#include <linux/types.h>

You can declare

struct device_node;

here to avoid including linux/of.h. Less includes means less circular
dependencies.

> +
> +#ifdef CONFIG_ARM_CCI
> +extern int cci_disable_port_by_cpu(u64 mpidr);
> +extern int __cci_control_port_by_device(struct device_node *np, bool enable);
> +#else
> +static inline int cci_disable_port_by_cpu(u64 mpidr) { return -ENODEV; }
> +static inline int __cci_control_port_by_device(struct device_node *np,
> +						bool enable)
> +{
> +	return -ENODEV;
> +}
>
-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation



From pawel.moll at arm.com  Thu Apr 18 13:23:22 2013
From: pawel.moll at arm.com (Pawel Moll)
Date: Thu, 18 Apr 2013 18:23:22 +0100
Subject: [PATCH] clk: vexpress: Add separate SP810 driver
In-Reply-To: <20130417222630.19887.75481@quantum>
References: <1363358409-5693-1-git-send-email-pawel.moll@arm.com>
 <20130417222630.19887.75481@quantum>
Message-ID: <1366305802.3077.37.camel@hornet>

On Wed, 2013-04-17 at 23:26 +0100, Mike Turquette wrote:
> In this case you are using clk_prepare for one-time configuration.  I
> agree that no alternative exists yet, but there have been discussions
> recently about using DT for configuration details that are not strictly
> descriptions of the hardware.  I've added a comment block in the patch
> below which notes this with a FIXME since there isn't a graceful
> alternative to using clk_prepare for ont-time configuration.

Fair enough.

> Can you test the patch below against the latest clk-next and let me know
> if it working on your platform?

It wasn't:

WARNING: at [...]/drivers/clk/clk.c:808 __clk_enable+0x94/0xa0()

because the new parent is not prepared automagically. This simple change
heals the problem and now everything is just fine:

        /* Switch the parent if necessary */
-       if (old_parent != new_parent)
+       if (old_parent != new_parent) {
+               clk_prepare(new_parent);
                clk_set_parent(hw->clk, new_parent);
+               clk_unprepare(old_parent);
+       }

So, to summarize, the patch that works for me is below.

Thanks for you help!

Pawel

8<--------------------------------
>From 58807cc1930edd092f1bc54b2ec381ddc9209671 Mon Sep 17 00:00:00 2001
From: Pawel Moll <pawel.moll at arm.com>
Date: Thu, 18 Apr 2013 18:20:54 +0100
Subject: [PATCH] clk: vexpress: Add separate SP810 driver

Factor out the SP810 clocking code into a separate driver,
selecting better (faster) parent at clk_prepare() time.
This is to avoid problems with clocking infrastructure
initialisation order, in particular to avoid dependency
of fixed clock being initialized before SP810. It also
makes vexpress platform OF-based clock initialisation code
unnecessary.

Signed-off-by: Pawel Moll <pawel.moll at arm.com>
Tested-by: Catalin Marinas <catalin.marinas at arm.com>
Signed-off-by: Mike Turquette <mturquette at linaro.org>
[mturquette at linaro.org: add .unprepare, FIXME comment, cleaned up code]
---
 arch/arm/mach-vexpress/v2m.c         |    8 +-
 drivers/clk/versatile/Makefile       |    2 +-
 drivers/clk/versatile/clk-sp810.c    |  188 ++++++++++++++++++++++++++++++++++
 drivers/clk/versatile/clk-vexpress.c |   49 ---------
 4 files changed, 196 insertions(+), 51 deletions(-)
 create mode 100644 drivers/clk/versatile/clk-sp810.c

diff --git a/arch/arm/mach-vexpress/v2m.c b/arch/arm/mach-vexpress/v2m.c
index 915683c..c5e20b5 100644
--- a/arch/arm/mach-vexpress/v2m.c
+++ b/arch/arm/mach-vexpress/v2m.c
@@ -21,6 +21,8 @@
 #include <linux/regulator/fixed.h>
 #include <linux/regulator/machine.h>
 #include <linux/vexpress.h>
+#include <linux/clk-provider.h>
+#include <linux/clkdev.h>
 
 #include <asm/arch_timer.h>
 #include <asm/mach-types.h>
@@ -433,7 +435,7 @@ static void __init v2m_dt_timer_init(void)
 {
 	struct device_node *node = NULL;
 
-	vexpress_clk_of_init();
+	of_clk_init(NULL);
 
 	do {
 		node = of_find_compatible_node(node, NULL, "arm,sp804");
@@ -441,6 +443,10 @@ static void __init v2m_dt_timer_init(void)
 	if (node) {
 		pr_info("Using SP804 '%s' as a clock & events source\n",
 				node->full_name);
+		WARN_ON(clk_register_clkdev(of_clk_get_by_name(node,
+				"timclken1"), "v2m-timer0", "sp804"));
+		WARN_ON(clk_register_clkdev(of_clk_get_by_name(node,
+				"timclken2"), "v2m-timer1", "sp804"));
 		v2m_sp804_init(of_iomap(node, 0),
 				irq_of_parse_and_map(node, 0));
 	}
diff --git a/drivers/clk/versatile/Makefile b/drivers/clk/versatile/Makefile
index ec3b88f..c16ca78 100644
--- a/drivers/clk/versatile/Makefile
+++ b/drivers/clk/versatile/Makefile
@@ -3,5 +3,5 @@ obj-$(CONFIG_ICST)		+= clk-icst.o
 obj-$(CONFIG_ARCH_INTEGRATOR)	+= clk-integrator.o
 obj-$(CONFIG_INTEGRATOR_IMPD1)	+= clk-impd1.o
 obj-$(CONFIG_ARCH_REALVIEW)	+= clk-realview.o
-obj-$(CONFIG_ARCH_VEXPRESS)	+= clk-vexpress.o
+obj-$(CONFIG_ARCH_VEXPRESS)	+= clk-vexpress.o clk-sp810.o
 obj-$(CONFIG_VEXPRESS_CONFIG)	+= clk-vexpress-osc.o
diff --git a/drivers/clk/versatile/clk-sp810.c b/drivers/clk/versatile/clk-sp810.c
new file mode 100644
index 0000000..bf9b15a
--- /dev/null
+++ b/drivers/clk/versatile/clk-sp810.c
@@ -0,0 +1,188 @@
+/*
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Copyright (C) 2013 ARM Limited
+ */
+
+#include <linux/amba/sp810.h>
+#include <linux/clkdev.h>
+#include <linux/clk-provider.h>
+#include <linux/err.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+
+#define to_clk_sp810_timerclken(_hw) \
+		container_of(_hw, struct clk_sp810_timerclken, hw)
+
+struct clk_sp810;
+
+struct clk_sp810_timerclken {
+	struct clk_hw hw;
+	struct clk *clk;
+	struct clk_sp810 *sp810;
+	int channel;
+};
+
+struct clk_sp810 {
+	struct device_node *node;
+	int refclk_index, timclk_index;
+	void __iomem *base;
+	spinlock_t lock;
+	struct clk_sp810_timerclken timerclken[4];
+	struct clk *refclk;
+	struct clk *timclk;
+};
+
+static u8 clk_sp810_timerclken_get_parent(struct clk_hw *hw)
+{
+	struct clk_sp810_timerclken *timerclken = to_clk_sp810_timerclken(hw);
+	u32 val = readl(timerclken->sp810->base + SCCTRL);
+
+	return !!(val & (1 << SCCTRL_TIMERENnSEL_SHIFT(timerclken->channel)));
+}
+
+static int clk_sp810_timerclken_set_parent(struct clk_hw *hw, u8 index)
+{
+	struct clk_sp810_timerclken *timerclken = to_clk_sp810_timerclken(hw);
+	struct clk_sp810 *sp810 = timerclken->sp810;
+	u32 val, shift = SCCTRL_TIMERENnSEL_SHIFT(timerclken->channel);
+	unsigned long flags = 0;
+
+	if (WARN_ON(index > 1))
+		return -EINVAL;
+
+	spin_lock_irqsave(&sp810->lock, flags);
+
+	val = readl(sp810->base + SCCTRL);
+	val &= ~(1 << shift);
+	val |= index << shift;
+	writel(val, sp810->base + SCCTRL);
+
+	spin_unlock_irqrestore(&sp810->lock, flags);
+
+	return 0;
+}
+
+/*
+ * FIXME - setting the parent every time .prepare is invoked is inefficient.
+ * This is better handled by a dedicated clock tree configuration mechanism at
+ * init-time.  Revisit this later when such a mechanism exists
+ */
+static int clk_sp810_timerclken_prepare(struct clk_hw *hw)
+{
+	struct clk_sp810_timerclken *timerclken = to_clk_sp810_timerclken(hw);
+	struct clk_sp810 *sp810 = timerclken->sp810;
+	struct clk *old_parent = __clk_get_parent(hw->clk);
+	struct clk *new_parent;
+
+	if (!sp810->refclk)
+		sp810->refclk = of_clk_get(sp810->node, sp810->refclk_index);
+
+	if (!sp810->timclk)
+		sp810->timclk = of_clk_get(sp810->node, sp810->timclk_index);
+
+	if (WARN_ON(IS_ERR(sp810->refclk) || IS_ERR(sp810->timclk)))
+		return -ENOENT;
+
+	/* Select fastest parent */
+	if (clk_get_rate(sp810->refclk) > clk_get_rate(sp810->timclk))
+		new_parent = sp810->refclk;
+	else
+		new_parent = sp810->timclk;
+
+	/* Switch the parent if necessary */
+	if (old_parent != new_parent) {
+		clk_prepare(new_parent);
+		clk_set_parent(hw->clk, new_parent);
+		clk_unprepare(old_parent);
+	}
+
+	return 0;
+}
+
+static void clk_sp810_timerclken_unprepare(struct clk_hw *hw)
+{
+	struct clk_sp810_timerclken *timerclken = to_clk_sp810_timerclken(hw);
+	struct clk_sp810 *sp810 = timerclken->sp810;
+
+	clk_put(sp810->timclk);
+	clk_put(sp810->refclk);
+}
+
+static const struct clk_ops clk_sp810_timerclken_ops = {
+	.prepare = clk_sp810_timerclken_prepare,
+	.unprepare = clk_sp810_timerclken_unprepare,
+	.get_parent = clk_sp810_timerclken_get_parent,
+	.set_parent = clk_sp810_timerclken_set_parent,
+};
+
+struct clk *clk_sp810_timerclken_of_get(struct of_phandle_args *clkspec,
+		void *data)
+{
+	struct clk_sp810 *sp810 = data;
+
+	if (WARN_ON(clkspec->args_count != 1 || clkspec->args[0] >
+			ARRAY_SIZE(sp810->timerclken)))
+		return NULL;
+
+	return sp810->timerclken[clkspec->args[0]].clk;
+}
+
+void __init clk_sp810_of_setup(struct device_node *node)
+{
+	struct clk_sp810 *sp810 = kzalloc(sizeof(*sp810), GFP_KERNEL);
+	const char *parent_names[2];
+	char name[12];
+	struct clk_init_data init;
+	int i;
+
+	if (!sp810) {
+		pr_err("Failed to allocate memory for SP810!\n");
+		return;
+	}
+
+	sp810->refclk_index = of_property_match_string(node, "clock-names",
+			"refclk");
+	parent_names[0] = of_clk_get_parent_name(node, sp810->refclk_index);
+
+	sp810->timclk_index = of_property_match_string(node, "clock-names",
+			"timclk");
+	parent_names[1] = of_clk_get_parent_name(node, sp810->timclk_index);
+
+	if (parent_names[0] <= 0 || parent_names[1] <= 0) {
+		pr_warn("Failed to obtain parent clocks for SP810!\n");
+		return;
+	}
+
+	sp810->node = node;
+	sp810->base = of_iomap(node, 0);
+	spin_lock_init(&sp810->lock);
+
+	init.name = name;
+	init.ops = &clk_sp810_timerclken_ops;
+	init.flags = CLK_IS_BASIC;
+	init.parent_names = parent_names;
+	init.num_parents = ARRAY_SIZE(parent_names);
+
+	for (i = 0; i < ARRAY_SIZE(sp810->timerclken); i++) {
+		snprintf(name, ARRAY_SIZE(name), "timerclken%d", i);
+
+		sp810->timerclken[i].sp810 = sp810;
+		sp810->timerclken[i].channel = i;
+		sp810->timerclken[i].hw.init = &init;
+
+		sp810->timerclken[i].clk = clk_register(NULL,
+				&sp810->timerclken[i].hw);
+		WARN_ON(IS_ERR(sp810->timerclken[i].clk));
+	}
+
+	of_clk_add_provider(node, clk_sp810_timerclken_of_get, sp810);
+}
+CLK_OF_DECLARE(sp810, "arm,sp810", clk_sp810_of_setup);
diff --git a/drivers/clk/versatile/clk-vexpress.c b/drivers/clk/versatile/clk-vexpress.c
index 82b45aa..a4a728d 100644
--- a/drivers/clk/versatile/clk-vexpress.c
+++ b/drivers/clk/versatile/clk-vexpress.c
@@ -15,8 +15,6 @@
 #include <linux/clkdev.h>
 #include <linux/clk-provider.h>
 #include <linux/err.h>
-#include <linux/of.h>
-#include <linux/of_address.h>
 #include <linux/vexpress.h>
 
 static struct clk *vexpress_sp810_timerclken[4];
@@ -86,50 +84,3 @@ void __init vexpress_clk_init(void __iomem *sp810_base)
 	WARN_ON(clk_register_clkdev(vexpress_sp810_timerclken[1],
 				"v2m-timer1", "sp804"));
 }
-
-#if defined(CONFIG_OF)
-
-struct clk *vexpress_sp810_of_get(struct of_phandle_args *clkspec, void *data)
-{
-	if (WARN_ON(clkspec->args_count != 1 || clkspec->args[0] >
-			ARRAY_SIZE(vexpress_sp810_timerclken)))
-		return NULL;
-
-	return vexpress_sp810_timerclken[clkspec->args[0]];
-}
-
-void __init vexpress_clk_of_init(void)
-{
-	struct device_node *node;
-	struct clk *clk;
-	struct clk *refclk, *timclk;
-
-	of_clk_init(NULL);
-
-	node = of_find_compatible_node(NULL, NULL, "arm,sp810");
-	vexpress_sp810_init(of_iomap(node, 0));
-	of_clk_add_provider(node, vexpress_sp810_of_get, NULL);
-
-	/* Select "better" (faster) parent for SP804 timers */
-	refclk = of_clk_get_by_name(node, "refclk");
-	timclk = of_clk_get_by_name(node, "timclk");
-	if (!WARN_ON(IS_ERR(refclk) || IS_ERR(timclk))) {
-		int i = 0;
-
-		if (clk_get_rate(refclk) > clk_get_rate(timclk))
-			clk = refclk;
-		else
-			clk = timclk;
-
-		for (i = 0; i < ARRAY_SIZE(vexpress_sp810_timerclken); i++)
-			WARN_ON(clk_set_parent(vexpress_sp810_timerclken[i],
-					clk));
-	}
-
-	WARN_ON(clk_register_clkdev(vexpress_sp810_timerclken[0],
-				"v2m-timer0", "sp804"));
-	WARN_ON(clk_register_clkdev(vexpress_sp810_timerclken[1],
-				"v2m-timer1", "sp804"));
-}
-
-#endif
-- 
1.7.10.4






From nicolas.pitre at linaro.org  Thu Apr 18 13:38:32 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Thu, 18 Apr 2013 13:38:32 -0400 (EDT)
Subject: [PATCH v6 1/4] arm: introduce psci_smp_ops
In-Reply-To: <alpine.DEB.2.02.1304181749260.7254@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1304031239550.5078@kaball.uk.xensource.com>
 <1365167495-18508-1-git-send-email-stefano.stabellini@eu.citrix.com>
 <20130418161341.GB14496@n2100.arm.linux.org.uk>
 <alpine.DEB.2.02.1304181714560.7254@kaball.uk.xensource.com>
 <alpine.LFD.2.03.1304181237480.17375@syhkavp.arg>
 <alpine.DEB.2.02.1304181749260.7254@kaball.uk.xensource.com>
Message-ID: <alpine.LFD.2.03.1304181336280.17375@syhkavp.arg>

On Thu, 18 Apr 2013, Stefano Stabellini wrote:

> On Thu, 18 Apr 2013, Nicolas Pitre wrote:
> > On Thu, 18 Apr 2013, Stefano Stabellini wrote:
> > 
> > > On Thu, 18 Apr 2013, Russell King - ARM Linux wrote:
> > > > This should allow the Xen problem to be resolved, because Xen will
> > > > provide the PSCI operations, and it's correct in that case to override
> > > > the platform's SMP operations.
> > > 
> > > Yes, increasing the priority of PSCI helps Xen a lot.
> > > In order to completely solve the issue for Xen though, another patch is
> > > needed (http://marc.info/?l=linux-kernel&m=136630106201968&w=2) because
> > > of the introduction of smp_init.
> > 
> > Please look at the latest smp_init patch version I sent to you.  It 
> > shouldn't conflict with Xen any longer.  It now returns a bool result 
> > depending on whether it did set up smp_ops or not.
> 
> CPUs are virtualized by Xen and do not reflect or expose the underlying
> SMP hardware and firmware features, so an hardware specific smp_init
> cannot run.
> 
> So the smp_init patch still breaks Xen because even if smp_init can fail
> graciously, executing a platform specific smp_init function that tries
> to access registers and memory regions that are not present is going to
> cause an undefined behaviour.

It won't access hardware but just look into the DT and return false if 
nothing interesting is found.  At which point the next attempt in the 
priority list is PSCI by default.


Nicolas


From sergei.shtylyov at cogentembedded.com  Thu Apr 18 13:38:54 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Thu, 18 Apr 2013 21:38:54 +0400
Subject: [PATCH v2 1/2] ARM: shmobile: R8A7779: add Ether support
In-Reply-To: <20130418153611.GX14496@n2100.arm.linux.org.uk>
References: <201304042253.50662.sergei.shtylyov@cogentembedded.com>
 <20130418153611.GX14496@n2100.arm.linux.org.uk>
Message-ID: <51702FAE.4040104@cogentembedded.com>

Hello.

On 18-04-2013 19:36, Russell King - ARM Linux wrote:

>> +/* Ether */
>> +static struct resource ether_resources[] = {
>> +	{
>> +		.start	= 0xfde00000,
>> +		.end	= 0xfde003ff,
>> +		.flags	= IORESOURCE_MEM,
>> +	}, {
>> +		.start	= gic_iid(0xb4),
>> +		.flags	= IORESOURCE_IRQ,
>> +	},

> There are macros for initializing these which have been around for a
> few years now.

    I know, I know, just didn't know they're that old.

> Please consider using them in future.

    This file uses the old style resource intializers generally, it just needs 
wholesale conversion.

WBR, Sergei



From nicolas.pitre at linaro.org  Thu Apr 18 13:40:26 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Thu, 18 Apr 2013 13:40:26 -0400 (EDT)
Subject: [PATCH v6 1/4] arm: introduce psci_smp_ops
In-Reply-To: <alpine.DEB.2.02.1304181748010.7254@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1304031239550.5078@kaball.uk.xensource.com>
 <1365167495-18508-1-git-send-email-stefano.stabellini@eu.citrix.com>
 <20130418161341.GB14496@n2100.arm.linux.org.uk>
 <alpine.DEB.2.02.1304181714560.7254@kaball.uk.xensource.com>
 <alpine.LFD.2.03.1304181233580.17375@syhkavp.arg>
 <alpine.DEB.2.02.1304181748010.7254@kaball.uk.xensource.com>
Message-ID: <alpine.LFD.2.03.1304181339510.17375@syhkavp.arg>

On Thu, 18 Apr 2013, Stefano Stabellini wrote:

> On Thu, 18 Apr 2013, Nicolas Pitre wrote:
> > On Thu, 18 Apr 2013, Stefano Stabellini wrote:
> > 
> > > On Thu, 18 Apr 2013, Russell King - ARM Linux wrote:
> > > > On Fri, Apr 05, 2013 at 02:11:32PM +0100, Stefano Stabellini wrote:
> > > > > +	psci_init();
> > > > >  #ifdef CONFIG_SMP
> > > > >  	if (is_smp()) {
> > > > > -		smp_set_ops(mdesc->smp);
> > > > > +		if (mdesc->smp)
> > > > > +			smp_set_ops(mdesc->smp);
> > > > > +		else if (psci_smp_available())
> > > > > +			smp_set_ops(&psci_smp_ops);
> > > > 
> > > > So, I have a vague recollection that the ordering of the above got discussed
> > > > but I can't find it amongst the 21k of messages so far this year.
> > > > 
> > > > The above looks weird to me.  Surely this should be:
> > > > 
> > > > 		if (psci_smp_available())
> > > > 			smp_set_ops(&psci_smp_ops);
> > > > 		else if (mdesc->smp)
> > > > 			smp_set_ops(mdesc->ops);
> > > > 
> > > > This means that if PSCI is available, and provides a set of operations,
> > > > we override whatever the platform has statically provided.
> > > > 
> > > > Remember, we're trying to move away from using "mdesc"s for platform
> > > > stuff, relying on things like DT and such like.  We really should not
> > > > be going for mdesc-overriding-newstuff but newstuff-overriding-mdesc.
> > > 
> > > That's correct, in fact if you look at the next patch you'll see that it
> > > changes the order.
> > > 
> > > I introduced the mechanism first and changed the priority later - it
> > > should help bisectability.
> > > I can fold the two patches into one if you prefer.
> > 
> > Please let's keep the order as we discussed.  Otherwise this is just too 
> > confusing (Russell's comment is a good example of that).
> 
> You are right, it is confusing.
> By "keep the order as we discussed", do you mean merge the second patch
> into the first one, correct?

Correct.  And merge the commit log message too.


Nicolas


From jgunthorpe at obsidianresearch.com  Thu Apr 18 13:41:12 2013
From: jgunthorpe at obsidianresearch.com (Jason Gunthorpe)
Date: Thu, 18 Apr 2013 11:41:12 -0600
Subject: I/O and multiple PCI buses
In-Reply-To: <20130418152747.GA19258@arm.com>
References: <20130418152747.GA19258@arm.com>
Message-ID: <20130418174112.GA1127@obsidianresearch.com>

On Thu, Apr 18, 2013 at 04:27:48PM +0100, Andrew Murray wrote:
> I'm trying to understand PCI I/O addressing in the kernel... (again)
> 
> I understand that ideally you want to give PCI bus addresses to PCI
> devices in the range of 0K to 64K. This seems to be achieved in
> pcibios_init_resources in arm's kernel/bios32.c implementation.

The ideal world (for small scale systems) is to have only one PCI host
bridge, and multiple root port bridges. This way the 0->64k range can
be shared between all the ports and this problem doesn't come up. Look
at how the new tegra and marvell work in this regard.

There are two motivations to use the low space.. Firstly some HW is
just broken with 32 bit IO because x86 doesn't use it. Secondly, the
legacy ISA 'no-BAR' or subtractive decode IO addresses are fixed (eg
0x3bx is VGA related) and the HW needs to be able to route them to the
VGA card, independently of the PCI compliant BAR based IO routing.

> What happens if you want to add another root bus? In this
> implementation the start address of the io_res is now 64K and as
> sys->io_offset is set to 0 the bus addresses under this second root
> bus will be 64K-128K - which I assume may break some things.

In this case you want to set io_offset for each host bridge to
translate 64k*nr -> 0 (ie, don't set it to 0) and IO map the right 64k
of MMIO space to 64k*nr to make this work.

The translation should look like:
  Linux driver does IO to 64k+1
  ARM io port wrapper translates 64k+1 to (IO base + 64k+1) virtual address
  TLB translates (IO base + 64k+1) to physical X+1
  HW converts physical X+1 to PCI IO transaction with IO address 1

The io_offset, which impacts pci_add_resource_offset, is used to tell
the Linux PCI core that BAR address 1, is actually seen in Linux as
IO 64k+1.

But, if you do this, I really recommend using separate PCI domains. It
is very wonky to see a single PCI bus hierarchy with overlapping
BAR addresses. Using proper bridges and sharing the space like x86
does is vastly preferred, IMHO.

> And to allow subsequent busses to use I/O starting from 0, you'd have to set
> sys->io_offset to 64K*nr and adapt functions such as pci_iomap to use the
> offset?

I think all the support is already there? The translation happens in
the PCI core when working with BARs, the Linux struct resource layer
already has io_offset included. The only impact the offset has is in
how the PCI core deals with BARs.

Regards,
Jason


From sergei.shtylyov at cogentembedded.com  Thu Apr 18 13:40:43 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Thu, 18 Apr 2013 21:40:43 +0400
Subject: [PATCH 1/8] ARM: shmobile:Marzen: move USB EHCI, OHCI, and PHY
 devices to R8A7779 code
In-Reply-To: <20130418154425.GZ14496@n2100.arm.linux.org.uk>
References: <201304050257.00799.sergei.shtylyov@cogentembedded.com>
 <20130418154425.GZ14496@n2100.arm.linux.org.uk>
Message-ID: <5170301B.3030306@cogentembedded.com>

Hello.

On 18-04-2013 19:44, Russell King - ARM Linux wrote:

>> +/* USB PHY */
>> +static struct resource usb_phy_resources[] = {
>> +	[0] = {
>> +		.start		= 0xffe70000,
>> +		.end		= 0xffe70900 - 1,
>> +		.flags		= IORESOURCE_MEM,
>> +	},
>> +	[1] = {
>> +		.start		= 0xfff70000,
>> +		.end		= 0xfff70900 - 1,
>> +		.flags		= IORESOURCE_MEM,
>> +	},

> Please consider using the macros for these initialisers.

    I'm just moving the code as is here. The destination file still uses old 
style initializers, and probably needs the wholesale conversion patch in the 
future.

WBR, Sergei



From nicolas.pitre at linaro.org  Thu Apr 18 13:54:04 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Thu, 18 Apr 2013 13:54:04 -0400 (EDT)
Subject: [RFC PATCH] drivers: bus: add ARM CCI support
In-Reply-To: <51702B70.9000908@codeaurora.org>
References: <1365691679-28674-1-git-send-email-lorenzo.pieralisi@arm.com>
 <1365691679-28674-2-git-send-email-lorenzo.pieralisi@arm.com>
 <51702B70.9000908@codeaurora.org>
Message-ID: <alpine.LFD.2.03.1304181341020.17375@syhkavp.arg>

On Thu, 18 Apr 2013, Stephen Boyd wrote:

> On 04/11/13 07:47, Lorenzo Pieralisi wrote:
> > diff --git a/drivers/bus/arm-cci.c b/drivers/bus/arm-cci.c
> > new file mode 100644
> > index 0000000..81953de
> > --- /dev/null
> > +++ b/drivers/bus/arm-cci.c
> [...]
> > +static void notrace cci_port_control(unsigned int port, bool enable)
> > +{
> > +	void __iomem *base = ports[port].base;
> > +
> > +	if (!base)
> > +		return;
> > +
> > +	writel_relaxed(enable, base + CCI_PORT_CTRL);
> > +	while (readl_relaxed(cci_ctrl_base + CCI_CTRL_STATUS) & 0x1)
> > +			;
> 
> cpu_relax()?

In some cases there is no more cache coherence when this is called and 
the hardware might not be in a good state to cope with whatever action 
people might be tempted to insert into cpu_relax().  After the CCI is 
disabled it is important to keep a low profile and not touch anything 
global. With some early hardware revision, even a DMB here was harmful.


Nicolas


From tony at atomide.com  Thu Apr 18 13:54:25 2013
From: tony at atomide.com (Tony Lindgren)
Date: Thu, 18 Apr 2013 10:54:25 -0700
Subject: [PATCH 0/3] few omap randconfig fixes for v3.10
Message-ID: <20130418175303.7436.75241.stgit@muffinssi.local>

Few trivial fixes for randconfig found issues.

Regards,

Tony

---

Tony Lindgren (3):
      ARM: OMAP2+: Fix unmet direct dependencies for SERIAL_OMAP
      ARM: OMAP2+: Fix unused variable warning for am3517 crane
      ARM: OMAP2+: Fix is_gpmc_muxed warning for H4


 arch/arm/configs/omap2plus_defconfig    |    2 ++
 arch/arm/mach-omap2/Kconfig             |    2 --
 arch/arm/mach-omap2/board-am3517crane.c |    2 --
 arch/arm/mach-omap2/board-h4.c          |    4 ++--
 4 files changed, 4 insertions(+), 6 deletions(-)

-- 
Signature


From tony at atomide.com  Thu Apr 18 13:54:33 2013
From: tony at atomide.com (Tony Lindgren)
Date: Thu, 18 Apr 2013 10:54:33 -0700
Subject: [PATCH 2/3] ARM: OMAP2+: Fix unused variable warning for am3517 crane
In-Reply-To: <20130418175303.7436.75241.stgit@muffinssi.local>
References: <20130418175303.7436.75241.stgit@muffinssi.local>
Message-ID: <20130418175433.7436.18512.stgit@muffinssi.local>

Fix the following by removing the unused variable:

arch/arm/mach-omap2/board-am3517crane.c: In function ?am3517_crane_init?:
arch/arm/mach-omap2/board-am3517crane.c:113: warning: unused variable ?ret?

Signed-off-by: Tony Lindgren <tony at atomide.com>
---
 arch/arm/mach-omap2/board-am3517crane.c |    2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/arm/mach-omap2/board-am3517crane.c b/arch/arm/mach-omap2/board-am3517crane.c
index fc53911..0d499a1 100644
--- a/arch/arm/mach-omap2/board-am3517crane.c
+++ b/arch/arm/mach-omap2/board-am3517crane.c
@@ -110,8 +110,6 @@ static void __init am3517_crane_i2c_init(void)
 
 static void __init am3517_crane_init(void)
 {
-	int ret;
-
 	omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
 	omap_serial_init();
 	omap_sdrc_init(NULL, NULL);



From tony at atomide.com  Thu Apr 18 13:54:29 2013
From: tony at atomide.com (Tony Lindgren)
Date: Thu, 18 Apr 2013 10:54:29 -0700
Subject: [PATCH 1/3] ARM: OMAP2+: Fix unmet direct dependencies for SERIAL_OMAP
In-Reply-To: <20130418175303.7436.75241.stgit@muffinssi.local>
References: <20130418175303.7436.75241.stgit@muffinssi.local>
Message-ID: <20130418175428.7436.87525.stgit@muffinssi.local>

Commit 8a6201b9 (ARM: OMAP2+: Fix unmet direct dependencies for zoom
for 8250 serial) fixed unmet direct dependencies for 8250, but failed
to do the same for omap serial. This can cause the following warning:

warning: (ARCH_OMAP2PLUS_TYPICAL) selects SERIAL_OMAP which has
unmet direct dependencies (TTY && HAS_IOMEM && GENERIC_HARDIRQS &&
ARCH_OMAP2PLUS).

We should not select drivers, they should be selected by the
user. Fix the issue by removing the select and adding them to
omap2plus_defconfig instead.

Signed-off-by: Tony Lindgren <tony at atomide.com>
---
 arch/arm/configs/omap2plus_defconfig |    2 ++
 arch/arm/mach-omap2/Kconfig          |    2 --
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig
index 33903ca..51a20a4 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -137,6 +137,8 @@ CONFIG_SERIAL_8250_DETECT_IRQ=y
 CONFIG_SERIAL_8250_RSA=y
 CONFIG_SERIAL_AMBA_PL011=y
 CONFIG_SERIAL_AMBA_PL011_CONSOLE=y
+CONFIG_SERIAL_OMAP=y
+CONFIG_SERIAL_OMAP_CONSOLE=y
 CONFIG_HW_RANDOM=y
 CONFIG_I2C_CHARDEV=y
 CONFIG_SPI=y
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index a897b44..03b0b27 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -37,8 +37,6 @@ config ARCH_OMAP2PLUS_TYPICAL
 	select NEON if ARCH_OMAP3 || ARCH_OMAP4 || SOC_OMAP5
 	select PM_RUNTIME
 	select REGULATOR
-	select SERIAL_OMAP
-	select SERIAL_OMAP_CONSOLE
 	select TWL4030_CORE if ARCH_OMAP3 || ARCH_OMAP4
 	select TWL4030_POWER if ARCH_OMAP3 || ARCH_OMAP4
 	select VFP



From tony at atomide.com  Thu Apr 18 13:54:35 2013
From: tony at atomide.com (Tony Lindgren)
Date: Thu, 18 Apr 2013 10:54:35 -0700
Subject: [PATCH 3/3] ARM: OMAP2+: Fix is_gpmc_muxed warning for H4
In-Reply-To: <20130418175303.7436.75241.stgit@muffinssi.local>
References: <20130418175303.7436.75241.stgit@muffinssi.local>
Message-ID: <20130418175435.7436.60372.stgit@muffinssi.local>

Fix the following error by moving the function to be within
the smc91x related ifdef as that's the only user:

arch/arm/mach-omap2/board-h4.c:238: warning: ?is_gpmc_muxed? defined but not used

Signed-off-by: Tony Lindgren <tony at atomide.com>
---
 arch/arm/mach-omap2/board-h4.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/board-h4.c b/arch/arm/mach-omap2/board-h4.c
index 69c0acf..f745cae 100644
--- a/arch/arm/mach-omap2/board-h4.c
+++ b/arch/arm/mach-omap2/board-h4.c
@@ -229,6 +229,8 @@ static u32 get_sysboot_value(void)
 		 OMAP2_SYSBOOT_1_MASK | OMAP2_SYSBOOT_0_MASK));
 }
 
+#if IS_ENABLED(CONFIG_SMC91X)
+
 /* H4-2420's always used muxed mode, H4-2422's always use non-muxed
  *
  * Note: OMAP-GIT doesn't correctly do is_cpu_omap2422 and is_cpu_omap2423
@@ -246,8 +248,6 @@ static u32 is_gpmc_muxed(void)
 		return 0;
 }
 
-#if IS_ENABLED(CONFIG_SMC91X)
-
 static struct omap_smc91x_platform_data board_smc91x_data = {
 	.cs		= 1,
 	.gpio_irq	= 92,



From sboyd at codeaurora.org  Thu Apr 18 14:11:53 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Thu, 18 Apr 2013 11:11:53 -0700
Subject: [RFC PATCH] drivers: bus: add ARM CCI support
In-Reply-To: <alpine.LFD.2.03.1304181341020.17375@syhkavp.arg>
References: <1365691679-28674-1-git-send-email-lorenzo.pieralisi@arm.com>
 <1365691679-28674-2-git-send-email-lorenzo.pieralisi@arm.com>
 <51702B70.9000908@codeaurora.org>
 <alpine.LFD.2.03.1304181341020.17375@syhkavp.arg>
Message-ID: <51703769.10908@codeaurora.org>

On 04/18/13 10:54, Nicolas Pitre wrote:
> On Thu, 18 Apr 2013, Stephen Boyd wrote:
>
>> On 04/11/13 07:47, Lorenzo Pieralisi wrote:
>>> diff --git a/drivers/bus/arm-cci.c b/drivers/bus/arm-cci.c
>>> new file mode 100644
>>> index 0000000..81953de
>>> --- /dev/null
>>> +++ b/drivers/bus/arm-cci.c
>> [...]
>>> +static void notrace cci_port_control(unsigned int port, bool enable)
>>> +{
>>> +	void __iomem *base = ports[port].base;
>>> +
>>> +	if (!base)
>>> +		return;
>>> +
>>> +	writel_relaxed(enable, base + CCI_PORT_CTRL);
>>> +	while (readl_relaxed(cci_ctrl_base + CCI_CTRL_STATUS) & 0x1)
>>> +			;
>> cpu_relax()?
> In some cases there is no more cache coherence when this is called and 
> the hardware might not be in a good state to cope with whatever action 
> people might be tempted to insert into cpu_relax().  After the CCI is 
> disabled it is important to keep a low profile and not touch anything 
> global. With some early hardware revision, even a DMB here was harmful.

Fair enough. Perhaps the code could use a comment to that effect.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation



From linux at arm.linux.org.uk  Thu Apr 18 14:25:34 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Thu, 18 Apr 2013 19:25:34 +0100
Subject: [PATCH] ARM: smp: call platform's cpu_die in ipi_cpu_stop
In-Reply-To: <20130418171801.GC14496@n2100.arm.linux.org.uk>
References: <1365251824-4852-1-git-send-email-kevin@bracey.fi>
 <1365251824-4852-2-git-send-email-kevin@bracey.fi>
 <20130418171801.GC14496@n2100.arm.linux.org.uk>
Message-ID: <20130418182534.GD14496@n2100.arm.linux.org.uk>

On Thu, Apr 18, 2013 at 06:18:01PM +0100, Russell King - ARM Linux wrote:
> On Sat, Apr 06, 2013 at 03:37:04PM +0300, Kevin Bracey wrote:
> > When hotplugging out, both cpu_kill and cpu_die have always been called.
> > But when smp_send_stop was used in machine_shutdown or panic, only
> > cpu_kill was called.
> > 
> > This causes problems for co-ordination between cpu_kill and cpu_die, as
> > attempted by shmobile. So add cpu_die call to ipi_cpu_stop, to ensure
> > that cpu_kill and cpu_die calls always occur together.
> 
> Actually, I'd prefer to pull more code out of the platforms.  Now
> that we have flush_cache_louis(), we can flush the L1 cache for the
> CPU going down in cpu_die() itself.  We just need to be careful
> with that complete() call to ensure that becomes visible to other
> cores before power is cut to the L1 cache.
> 
> That's fine though - because it must become visible for __cpu_die()
> to continue (otherwise it will time out).
> 
> That should render shmobile's cpu_dead thing unnecessary, because the
> platform independent code will do the required synchronisation.

So, something like the below (which is a combined patch of three).  The
key points here being that:

1. We flush the L1 cache in cpu_die(), which pushes any dirty cache lines
   out of the L1 cache and invalidates it.  At the point this function
   completes, any data in the L1 cache has been pushed out and all
   cache lines are invalid.
2. We complete(), which allows __cpu_die() to proceed and call
   platform_cpu_kill().  This may create dirty cache lines which this
   CPU exclusively owns, but the CPU in __cpu_die() will gain those
   cache lines before wait_for_completion() can return - not only the
   completion counter but also the spinlock, which this CPU will have
   ended up reading and writing - and so can no longer be owned by the
   dying CPU.
3. The following mb() is belt and braces to ensure that the completion
   is visible.  It isn't strictly required because the spinlocks will
   do the necessary stuff to ensure this.
4. Any dirtying of the cache after this rellay doesn't matter _if_ only
   the stack is touched, or other data is only read.
5. I've left those platforms which disable the L1 cache, then flush
   alone; that _should_ be removable with this patch as well, but as
   a separate patch.

Now, with this patch applied, we guarantee that we push out any data
that matters from the dying CPU before platform_cpu_kill() is called.
That should mean that shmobile can remove that whole cpu_dead thing.

I've tested this on OMAP, and it appears to work from a simple test of
CPU hotplug.  This patch(set) also kills the cpu_disable() that tegra
has which is just a copy of the generic version.

 arch/arm/kernel/smp.c               |    4 ++++
 arch/arm/mach-exynos/hotplug.c      |    1 -
 arch/arm/mach-highbank/hotplug.c    |    4 ----
 arch/arm/mach-imx/hotplug.c         |    2 --
 arch/arm/mach-msm/hotplug.c         |    4 ----
 arch/arm/mach-omap2/omap-hotplug.c  |    3 ---
 arch/arm/mach-prima2/hotplug.c      |    3 ---
 arch/arm/mach-realview/hotplug.c    |    2 --
 arch/arm/mach-shmobile/smp-sh73a0.c |    8 --------
 arch/arm/mach-spear13xx/hotplug.c   |    2 --
 arch/arm/mach-tegra/common.h        |    1 -
 arch/arm/mach-tegra/hotplug.c       |   10 ----------
 arch/arm/mach-tegra/platsmp.c       |    1 -
 arch/arm/mach-ux500/hotplug.c       |    3 ---
 arch/arm/mach-vexpress/hotplug.c    |    2 --
 15 files changed, 4 insertions(+), 46 deletions(-)

diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
index 1f2cccc..d0cb2e1 100644
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -230,10 +230,14 @@ void __ref cpu_die(void)
 	idle_task_exit();
 
 	local_irq_disable();
+
+	/* Flush the data out of the L1 cache for this CPU. */
+	flush_cache_louis();
 	mb();
 
 	/* Tell __cpu_die() that this CPU is now safe to dispose of */
 	RCU_NONIDLE(complete(&cpu_died));
+	mb();
 
 	/*
 	 * actual CPU shutdown procedure is at least platform (if not
diff --git a/arch/arm/mach-exynos/hotplug.c b/arch/arm/mach-exynos/hotplug.c
index c3f825b..af90cfa 100644
--- a/arch/arm/mach-exynos/hotplug.c
+++ b/arch/arm/mach-exynos/hotplug.c
@@ -28,7 +28,6 @@ static inline void cpu_enter_lowpower_a9(void)
 {
 	unsigned int v;
 
-	flush_cache_all();
 	asm volatile(
 	"	mcr	p15, 0, %1, c7, c5, 0\n"
 	"	mcr	p15, 0, %1, c7, c10, 4\n"
diff --git a/arch/arm/mach-highbank/hotplug.c b/arch/arm/mach-highbank/hotplug.c
index f30c528..35dd42e 100644
--- a/arch/arm/mach-highbank/hotplug.c
+++ b/arch/arm/mach-highbank/hotplug.c
@@ -15,8 +15,6 @@
  */
 #include <linux/kernel.h>
 
-#include <asm/cacheflush.h>
-
 #include "core.h"
 #include "sysregs.h"
 
@@ -28,8 +26,6 @@ extern void secondary_startup(void);
  */
 void __ref highbank_cpu_die(unsigned int cpu)
 {
-	flush_cache_all();
-
 	highbank_set_cpu_jump(cpu, phys_to_virt(0));
 	highbank_set_core_pwr();
 
diff --git a/arch/arm/mach-imx/hotplug.c b/arch/arm/mach-imx/hotplug.c
index 361a253..5e91112 100644
--- a/arch/arm/mach-imx/hotplug.c
+++ b/arch/arm/mach-imx/hotplug.c
@@ -11,7 +11,6 @@
  */
 
 #include <linux/errno.h>
-#include <asm/cacheflush.h>
 #include <asm/cp15.h>
 
 #include "common.h"
@@ -20,7 +19,6 @@ static inline void cpu_enter_lowpower(void)
 {
 	unsigned int v;
 
-	flush_cache_all();
 	asm volatile(
 		"mcr	p15, 0, %1, c7, c5, 0\n"
 	"	mcr	p15, 0, %1, c7, c10, 4\n"
diff --git a/arch/arm/mach-msm/hotplug.c b/arch/arm/mach-msm/hotplug.c
index 750446f..326a872 100644
--- a/arch/arm/mach-msm/hotplug.c
+++ b/arch/arm/mach-msm/hotplug.c
@@ -10,16 +10,12 @@
 #include <linux/errno.h>
 #include <linux/smp.h>
 
-#include <asm/cacheflush.h>
 #include <asm/smp_plat.h>
 
 #include "common.h"
 
 static inline void cpu_enter_lowpower(void)
 {
-	/* Just flush the cache. Changing the coherency is not yet
-	 * available on msm. */
-	flush_cache_all();
 }
 
 static inline void cpu_leave_lowpower(void)
diff --git a/arch/arm/mach-omap2/omap-hotplug.c b/arch/arm/mach-omap2/omap-hotplug.c
index e712d17..ceb30a5 100644
--- a/arch/arm/mach-omap2/omap-hotplug.c
+++ b/arch/arm/mach-omap2/omap-hotplug.c
@@ -35,9 +35,6 @@ void __ref omap4_cpu_die(unsigned int cpu)
 	unsigned int boot_cpu = 0;
 	void __iomem *base = omap_get_wakeupgen_base();
 
-	flush_cache_all();
-	dsb();
-
 	/*
 	 * we're ready for shutdown now, so do it
 	 */
diff --git a/arch/arm/mach-prima2/hotplug.c b/arch/arm/mach-prima2/hotplug.c
index f4b17cb..0ab2f8b 100644
--- a/arch/arm/mach-prima2/hotplug.c
+++ b/arch/arm/mach-prima2/hotplug.c
@@ -10,13 +10,10 @@
 #include <linux/errno.h>
 #include <linux/smp.h>
 
-#include <asm/cacheflush.h>
 #include <asm/smp_plat.h>
 
 static inline void platform_do_lowpower(unsigned int cpu)
 {
-	flush_cache_all();
-
 	/* we put the platform to just WFI */
 	for (;;) {
 		__asm__ __volatile__("dsb\n\t" "wfi\n\t"
diff --git a/arch/arm/mach-realview/hotplug.c b/arch/arm/mach-realview/hotplug.c
index 53818e5..ac22dd4 100644
--- a/arch/arm/mach-realview/hotplug.c
+++ b/arch/arm/mach-realview/hotplug.c
@@ -12,7 +12,6 @@
 #include <linux/errno.h>
 #include <linux/smp.h>
 
-#include <asm/cacheflush.h>
 #include <asm/cp15.h>
 #include <asm/smp_plat.h>
 
@@ -20,7 +19,6 @@ static inline void cpu_enter_lowpower(void)
 {
 	unsigned int v;
 
-	flush_cache_all();
 	asm volatile(
 	"	mcr	p15, 0, %1, c7, c5, 0\n"
 	"	mcr	p15, 0, %1, c7, c10, 4\n"
diff --git a/arch/arm/mach-shmobile/smp-sh73a0.c b/arch/arm/mach-shmobile/smp-sh73a0.c
index acb46a9..2f1ef1b 100644
--- a/arch/arm/mach-shmobile/smp-sh73a0.c
+++ b/arch/arm/mach-shmobile/smp-sh73a0.c
@@ -119,14 +119,6 @@ static int sh73a0_cpu_kill(unsigned int cpu)
 
 static void sh73a0_cpu_die(unsigned int cpu)
 {
-	/*
-	 * The ARM MPcore does not issue a cache coherency request for the L1
-	 * cache when powering off single CPUs. We must take care of this and
-	 * further caches.
-	 */
-	dsb();
-	flush_cache_all();
-
 	/* Set power off mode. This takes the CPU out of the MP cluster */
 	scu_power_mode(scu_base_addr(), SCU_PM_POWEROFF);
 
diff --git a/arch/arm/mach-spear13xx/hotplug.c b/arch/arm/mach-spear13xx/hotplug.c
index a7d2dd1..d97749c 100644
--- a/arch/arm/mach-spear13xx/hotplug.c
+++ b/arch/arm/mach-spear13xx/hotplug.c
@@ -13,7 +13,6 @@
 #include <linux/kernel.h>
 #include <linux/errno.h>
 #include <linux/smp.h>
-#include <asm/cacheflush.h>
 #include <asm/cp15.h>
 #include <asm/smp_plat.h>
 
@@ -21,7 +20,6 @@ static inline void cpu_enter_lowpower(void)
 {
 	unsigned int v;
 
-	flush_cache_all();
 	asm volatile(
 	"	mcr	p15, 0, %1, c7, c5, 0\n"
 	"	dsb\n"
diff --git a/arch/arm/mach-tegra/common.h b/arch/arm/mach-tegra/common.h
index 32f8eb3..5900cc4 100644
--- a/arch/arm/mach-tegra/common.h
+++ b/arch/arm/mach-tegra/common.h
@@ -2,4 +2,3 @@ extern struct smp_operations tegra_smp_ops;
 
 extern int tegra_cpu_kill(unsigned int cpu);
 extern void tegra_cpu_die(unsigned int cpu);
-extern int tegra_cpu_disable(unsigned int cpu);
diff --git a/arch/arm/mach-tegra/hotplug.c b/arch/arm/mach-tegra/hotplug.c
index a599f6e..e8323bc 100644
--- a/arch/arm/mach-tegra/hotplug.c
+++ b/arch/arm/mach-tegra/hotplug.c
@@ -12,7 +12,6 @@
 #include <linux/smp.h>
 #include <linux/clk/tegra.h>
 
-#include <asm/cacheflush.h>
 #include <asm/smp_plat.h>
 
 #include "sleep.h"
@@ -47,15 +46,6 @@ void __ref tegra_cpu_die(unsigned int cpu)
 	BUG();
 }
 
-int tegra_cpu_disable(unsigned int cpu)
-{
-	/*
-	 * we don't allow CPU 0 to be shutdown (it is still too special
-	 * e.g. clock tick interrupts)
-	 */
-	return cpu == 0 ? -EPERM : 0;
-}
-
 #ifdef CONFIG_ARCH_TEGRA_2x_SOC
 extern void tegra20_hotplug_shutdown(void);
 void __init tegra20_hotplug_init(void)
diff --git a/arch/arm/mach-tegra/platsmp.c b/arch/arm/mach-tegra/platsmp.c
index 2c6b3d5..ec33ec8 100644
--- a/arch/arm/mach-tegra/platsmp.c
+++ b/arch/arm/mach-tegra/platsmp.c
@@ -192,6 +192,5 @@ struct smp_operations tegra_smp_ops __initdata = {
 #ifdef CONFIG_HOTPLUG_CPU
 	.cpu_kill		= tegra_cpu_kill,
 	.cpu_die		= tegra_cpu_die,
-	.cpu_disable		= tegra_cpu_disable,
 #endif
 };
diff --git a/arch/arm/mach-ux500/hotplug.c b/arch/arm/mach-ux500/hotplug.c
index 2f6af25..1c55a55 100644
--- a/arch/arm/mach-ux500/hotplug.c
+++ b/arch/arm/mach-ux500/hotplug.c
@@ -12,7 +12,6 @@
 #include <linux/errno.h>
 #include <linux/smp.h>
 
-#include <asm/cacheflush.h>
 #include <asm/smp_plat.h>
 
 #include <mach/setup.h>
@@ -24,8 +23,6 @@
  */
 void __ref ux500_cpu_die(unsigned int cpu)
 {
-	flush_cache_all();
-
 	/* directly enter low power state, skipping secure registers */
 	for (;;) {
 		__asm__ __volatile__("dsb\n\t" "wfi\n\t"
diff --git a/arch/arm/mach-vexpress/hotplug.c b/arch/arm/mach-vexpress/hotplug.c
index a141b98..f0ce6b8 100644
--- a/arch/arm/mach-vexpress/hotplug.c
+++ b/arch/arm/mach-vexpress/hotplug.c
@@ -12,7 +12,6 @@
 #include <linux/errno.h>
 #include <linux/smp.h>
 
-#include <asm/cacheflush.h>
 #include <asm/smp_plat.h>
 #include <asm/cp15.h>
 
@@ -20,7 +19,6 @@ static inline void cpu_enter_lowpower(void)
 {
 	unsigned int v;
 
-	flush_cache_all();
 	asm volatile(
 		"mcr	p15, 0, %1, c7, c5, 0\n"
 	"	mcr	p15, 0, %1, c7, c10, 4\n"



From dmurphy at ti.com  Thu Apr 18 14:31:11 2013
From: dmurphy at ti.com (Dan Murphy)
Date: Thu, 18 Apr 2013 13:31:11 -0500
Subject: [PATCHv2] ARM:dts:omap4-panda:Update the LED support for the
 panda DTS
In-Reply-To: <516FBD18.3060501@ti.com>
References: <1366229760-4808-1-git-send-email-dmurphy@ti.com>
 <516FBD18.3060501@ti.com>
Message-ID: <51703BEF.6050804@ti.com>

On 04/18/2013 04:30 AM, Vincent Stehl? wrote:
> On 04/17/2013 10:16 PM, Dan Murphy wrote:
>> The GPIO for LED D1 on the omap4-panda a1-a3 rev and the omap4-panda-es
>> are different.
> (..)
>> diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi b/arch/arm/boot/dts/omap4-panda-common.dtsi
>> index 03bd60d..0c48f6b 100644
>> --- a/arch/arm/boot/dts/omap4-panda-common.dtsi
>> +++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
> (..)
>> @@ -135,6 +136,25 @@
>>   			0xf0 0x118     /* i2c4_sda PULLUP | INPUTENABLE | MODE0 */
>>   		>;
>>   	};
>> +
>> +	led_gpio_pins: pinmux_leds_pins {
>> +		pinctrl-single,pins = <
>> +		>;
>> +	};
>> +};
> Hi,
>
> FYI, there was a recent discussion precisely on this topic, where Tomy
> suggested to remove the empty section:
> http://marc.info/?l=linux-omap&m=136546635409232&w=2
>
> Apart from that, I just tested your patch on top of Tomy's
> omap-for-v3.10/dt branch and it is working fine for me on PandaBoards
> EA3, A4 and ES.
>
> Tested-by: Vincent Stehl? <v-stehle at ti.com>
>
> Best regards,
>
> V.
>
Thanks for testing Vincent

Is there a way to append the data to an already existing node?
I do not see a clean way.

Dan

-- 
----------------------------------------------
Dan Murphy



From pranavkumar at linaro.org  Thu Apr 18 14:59:35 2013
From: pranavkumar at linaro.org (Pranavkumar Sawargaonkar)
Date: Fri, 19 Apr 2013 00:29:35 +0530
Subject: [RFC] arm64: Early printk support for virtio-mmio console devices.
In-Reply-To: <217a4f2dd017af16204391012751e9f9@localhost>
References: <1366264344-28025-1-git-send-email-pranavkumar@linaro.org>
 <51701084.5050706@codeaurora.org>
 <217a4f2dd017af16204391012751e9f9@localhost>
Message-ID: <CAAHg+HhMOfQbjLoCCY3eB2_bWn_GRUS7c=VcH1k0oEQVuUR_PQ@mail.gmail.com>

On 18 April 2013 21:29, Marc Zyngier <marc.zyngier at arm.com> wrote:
> On Thu, 18 Apr 2013 11:25:56 -0400, Christopher Covington
> <cov at codeaurora.org> wrote:
>> Hi Pranavkumar,
>>
>> On 04/18/2013 01:52 AM, PranavkumarSawargaonkar wrote:
>>> From: Pranavkumar Sawargaonkar <pranavkumar at linaro.org>
>>>
>>> This patch implements early printk support for virtio-mmio console
>>> devices
>>> without using any hypercalls.
>>
>> Is it possible that using DCC might be an easier solution?
>
> You would end up with the exact same problem as with a hypercall based
> solution: once you're in the hypervisor, what do you do with the data? You
> end up having to invent another channel to forward it down to your platform
> emulation in order to have it printed where the user expects it.
>
> Using a MMIO based solution is probably the best solution, as it uses the
> existing infrastructure.

Completely agree with Marc that instead of writing hypercalls (which
will have hypervisor and arch specific implementation) use of existing
MMIO and virtio console layer is easier and good option.

-
Pranav
>
>         M.
> --
> Fast, cheap, reliable. Pick two.


From gmbnomis at gmail.com  Thu Apr 18 15:00:28 2013
From: gmbnomis at gmail.com (Simon Baatz)
Date: Thu, 18 Apr 2013 21:00:28 +0200
Subject: [PATCH V3 2/2] ARM: Handle user space mapped pages in
 flush_kernel_dcache_page
In-Reply-To: <20130418112201.GQ14496@n2100.arm.linux.org.uk>
References: <1349609352-6408-1-git-send-email-gmbnomis@gmail.com>
 <1349609352-6408-3-git-send-email-gmbnomis@gmail.com>
 <20121008174428.GB3204@arm.com>
 <20121008200216.GA14167@schnuecks.de>
 <20121008202040.GC4625@n2100.arm.linux.org.uk>
 <20121008230733.GA17819@schnuecks.de>
 <20121118211005.GW22106@titan.lakedaemon.net>
 <20130418111608.GF27197@titan.lakedaemon.net>
 <20130418112201.GQ14496@n2100.arm.linux.org.uk>
Message-ID: <20130418190027.GA2778@schnuecks.de>

Hi Russel,

On Thu, Apr 18, 2013 at 12:22:01PM +0100, Russell King - ARM Linux wrote:
> On Thu, Apr 18, 2013 at 07:16:08AM -0400, Jason Cooper wrote:
> > Russell, Catalin, Simon,
> > 
> > I'm digging through my 'onice' mail folder and found this.  I've
> > personally experienced this bug in the past (workaround: don't use LVM
> > on ARM systems :-( ).
> > 
> > Is there any interest in reviving this series?  I can dig up the patches
> > if needed.
> 
> None what so ever.  flush_kernel_dcache_page() is not supposed to touch
> userspace pages.

I don't know if we have a wording issue here. The header of the patch
says "user space mapped pages".  Thus, pages for which a user space
mapping exists.  As the documentation you cite below states, these
pages ("user pages") should be handled by flush_kernel_dcache_page(). 
Of course, flush_kernel_dcache_page() has only to care about the
dirty kernel mapping, but this is what the proposed patches do.  I
never proposed to touch the user space mappings.
 
>   void flush_kernel_dcache_page(struct page *page)
>         When the kernel needs to modify a user page is has obtained
>         with kmap, it calls this function after all modifications are
>         complete (but before kunmapping it) to bring the underlying
>         page up to date.  It is assumed here that the user has no
>                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>         incoherent cached copies (i.e. the original page was obtained
>         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>         from a mechanism like get_user_pages()).  The default
>         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>         implementation is a nop and should remain so on all coherent
>         architectures.  On incoherent architectures, this should flush
>                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>         the kernel cache for page (using page_address(page)).
>         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> The first underlined sentence means that it's assumed that something _else_
> has already dealt with the userspace aliases (in other words, get_user_pages()
> via flush_dcache_page() or flush_anon_page()).  The second is absolutely
> clear that _only_ the kernel side should be flushed.
> 
> flush_kernel_dcache_page() was invented explicitly to separate out the
> kernel side flushing from flush_dcache_page(), as a lighter weight version
> for block drivers to use.

Yes, exactly. Apart from one thing: flush_kernel_dcache_page() is
supposed to handle all user pages. Thus, it is a more lightweight
version of flush_dcache_page() and flush_anon_page().

But the current implementation only handles page cache pages without a
user mapping (it's a nop because we can do lazy flushing here). It
does not handle page cache pages with a user space mapping and anon
pages.

My first patch (see [1]) was the "minimalistic" approach to do this. Just
flush the _kernel_ mapping if we have user space mappings. Continue to
be lazy otherwise.

But then the question is, whether this is enough. Let's take commit
65b6ecc:

+++ b/kernel/events/uprobes.c
@@ -1199,6 +1199,11 @@ static unsigned long xol_get_insn_slot(struct uprobe *uprobe, unsigned long slot
        vaddr = kmap_atomic(area->page);
        memcpy(vaddr + offset, uprobe->arch.insn, MAX_UINSN_BYTES);
        kunmap_atomic(vaddr);
+       /*
+        * We probably need flush_icache_user_range() but it needs
vma.
+        * This should work on supported architectures too.
+        */
+       flush_dcache_page(area->page);

Wouldn't that be a use for flush_kernel_dcache_page() (before
kunmap())?  But then, we need to care about I/D-cache coherency, i.e. 
flush_kernel_dcache_page() very much looks like flush_dcache_page()
but without the "flush user mappings" part.  That's the idea behind
the second version (see [2]).  If that's not a relevant case, I am
more than happy to go back to [1].

The third version combined this with a slight optimization, but this
had problems as you pointed out at the time and we can forget about
that one for the time being.  Still, I consider the older versions
[1] or [2] to be relevant.

- Simon

[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2012-May/101794.html
[2] http://lists.infradead.org/pipermail/linux-arm-kernel/2012-September/122874.html


From will.deacon at arm.com  Thu Apr 18 15:01:31 2013
From: will.deacon at arm.com (Will Deacon)
Date: Thu, 18 Apr 2013 20:01:31 +0100
Subject: [PATCH] documentation: iommu: add description of ARM System MMU
 binding
In-Reply-To: <516D9602.2010404@codeaurora.org>
References: <1365094259-24847-1-git-send-email-will.deacon@arm.com>
 <515F37C1.4000109@codeaurora.org>
 <20130408092535.GA17476@mudshark.cambridge.arm.com>
 <5162F87A.7070409@codeaurora.org>
 <20130410173732.GQ26992@mudshark.cambridge.arm.com>
 <5169C7D1.8070300@codeaurora.org>
 <20130415131341.GG9827@mudshark.cambridge.arm.com>
 <516D9602.2010404@codeaurora.org>
Message-ID: <20130418190131.GA12344@mudshark.cambridge.arm.com>

Hi Olav,

On Tue, Apr 16, 2013 at 07:18:42PM +0100, Olav Haugan wrote:
> On 4/15/2013 6:13 AM, Will Deacon wrote:
> > If so, doesn't that strongly tie your video driver to the SMMU?
> 
> Isn't this more or less what you are doing in DT where you associate
> specific devices with an IOMMU (mmu-masters)?

No. The device-tree describes the *hardware*, as per usual. The StreamIDs
are fixed properties of the SoC and we can't change them from Linux, so we
describe all of the StreamIDs upstream of each SMMU so that we can program
the thing. There's no way to generic way to discover them.

> > This seems to be where we differ. My anticipated use-case is that a domain
> > is allocated, which defines an empty address space. Masters are then
> > attached to the domain by passing their struct device, so this may
> > correspond to a DMA controller or a video core, in your case. The context
> > bank is allocated dynamically when the first device is added to the
> > domain, and then it is subsequently shared between all the masters in that
> > domain.
> 
> I feel that there are some limitation with this. Maybe you can address
> the following:
> 
> 1) What if you want two context banks in one domain (shared page table)?

Why would a page table shared between devices require multiple context
banks? Multiple SMRs and S2CRs, sure, but they would ultimately point at the
same context bank (and hence same address space).

> 2) What if a master (device) needs to use 2 or more context banks?

If a master needs to be in two address spaces at once, then it will need to
attach it's StreamIDs to different domains. You can't place a single
StreamID in two address spaces (this is an architectural constraint).

> > Perhaps, but I don't think it's worth complicating the binding based on a
> > potential nice-to-have fault message.
> > 
> 
> However, global register space (including Stream Match Registers [SMR])
> needs to be programmed by the secure environment for security or by
> hyper-visor if you are in such an environment.

Of course, but that's not Linux (and KVM would likely have some additional
code if it wanted to do device passthrough, for example).

Will


From pranavkumar at linaro.org  Thu Apr 18 15:06:46 2013
From: pranavkumar at linaro.org (Pranavkumar Sawargaonkar)
Date: Fri, 19 Apr 2013 00:36:46 +0530
Subject: [RFC] arm64: Early printk support for virtio-mmio console devices.
In-Reply-To: <bb1193983de3ea9f4df1a570441df34c@localhost>
References: <1366264344-28025-1-git-send-email-pranavkumar@linaro.org>
 <ede8ee08bb2616c2ed642200e3357367@localhost>
 <CAAHg+HhajHFC=1nh6YQNgpf=Na2FqcsYJ=t+ag9QiTg6TxUz9w@mail.gmail.com>
 <bb1193983de3ea9f4df1a570441df34c@localhost>
Message-ID: <CAAHg+Hj4HB20FDYLZ+NdjF3+2xp7E0-PNm41d74K4WB8OfB4fg@mail.gmail.com>

On 18 April 2013 13:06, Marc Zyngier <marc.zyngier at arm.com> wrote:
> On Thu, 18 Apr 2013 12:47:18 +0530, Pranavkumar Sawargaonkar
> <pranavkumar at linaro.org> wrote:
>> Hi Marc,
>>
>> On 18 April 2013 12:19, Marc Zyngier <maz at misterjones.org> wrote:
>>
>>> Hi Pranavkumar,
>>>
>>> On Thu, 18 Apr 2013 11:22:24 +0530, PranavkumarSawargaonkar
>>> <pranavkumar at linaro.org> wrote:
>>> > From: Pranavkumar Sawargaonkar <pranavkumar at linaro.org>
>>> >
>>> > This patch implements early printk support for virtio-mmio console
>>> devices
>>> > without using any hypercalls.
>>> >
>>> > The current virtio early printk code in kernel expects that
> hypervisor
>>> > will provide some mechanism generally a hypercall to support early
>>> printk.
>>> > This patch does not break existing hypercall based early print
> support.
>>> >
>>> > This implementation adds:
>>> > 1. Early read-write register named early_rw in virtio console's
> config
>>> > space.
>>> > 2. Two host feature flags namely VIRTIO_CONSOLE_F_EARLY_READ and
>>> > VIRTIO_CONSOLE_F_EARLY_WRITE for telling guest about early-read and
>>> > early-write capability in console device.
>>> >
>>> > Early write mechanism:
>>> > 1. When a guest wants to out some character, it has to simply write
> the
>>> > character to early_rw register in config space of virtio console
>>> > device.
>>> >
>>> > Early read mechanism:
>>> > 1. When a guest wants to in some character, it has to simply read the
>>> > early_rw register in config space of virtio console device. Lets say
> we
>>> get
>>> > 32-bit value X.
>>> > 2. If most significant bit of X is set (i.e. X & 0x80000000 ==
>>> 0x80000000)
>>> > then least significant 8 bits of X represents input charaacter else
>>> guest
>>> > need to try again reading early_rw register.
>>> >
>>> > Note: This patch only includes kernel side changes for early printk,
>>> > the
>>> > host/hypervisor side emulation of early_rw register is out of scope
>>> here.
>>>
>>> Well, that's unfortunate, as it makes it quite difficult to understand
>>> the
>>> impact of this patch.
>>> Has the virtio side been posted somewhere? I expect you've implemented
>>> something in kvmtool...
>>>
>>
>> Yes i have implemented kvmtool side also and code change is really small
>> (not really a clean code currently)
>> I can post it also but since it is specific to kvmtool i have not posted
> it
>> with rfc.
>
> Doesn't really if the code needs some rework at this point (I expect the
> patch to be fairly small indeed). Any chance you could post it to the KVM
> list?

I have posted kvmtool side changes on kvmarm list.
[RFC] KVMTOOL: Early printk support for virtio-mmio console.
Patch has an implementation of early_rw config register to print early writes.
I have successfully booted a guest on armv8 foundation model throwing
early printks before actual virtio driver takes control.

Thanks,
Pranav

>
>>>
>>> > Signed-off-by: Anup Patel <anup.patel at linaro.org>
>>> > ---
>>> >  arch/arm64/kernel/early_printk.c    |   24 ++++++++++++++++++++++++
>>> >  include/uapi/linux/virtio_console.h |    4 ++++
>>> >  2 files changed, 28 insertions(+)
>>> >
>>> > diff --git a/arch/arm64/kernel/early_printk.c
>>> > b/arch/arm64/kernel/early_printk.c
>>> > index ac974f4..a82b5aa 100644
>>> > --- a/arch/arm64/kernel/early_printk.c
>>> > +++ b/arch/arm64/kernel/early_printk.c
>>> > @@ -25,6 +25,9 @@
>>> >
>>> >  #include <linux/amba/serial.h>
>>> >  #include <linux/serial_reg.h>
>>> > +#include <linux/virtio_ids.h>
>>> > +#include <linux/virtio_mmio.h>
>>> > +#include <linux/virtio_console.h>
>>> >
>>> >  static void __iomem *early_base;
>>> >  static void (*printch)(char ch);
>>> > @@ -53,6 +56,26 @@ static void smh_printch(char ch)
>>> >  }
>>> >
>>> >  /*
>>> > + * VIRTIO MMIO based debug console.
>>> > + */
>>> > +static void virtio_console_early_printch(char ch)
>>> > +{
>>> > +     u32 tmp;
>>> > +     struct virtio_console_config *p = early_base +
>>> > VIRTIO_MMIO_CONFIG;
>>> > +
>>> > +     tmp = readl_relaxed(early_base + VIRTIO_MMIO_DEVICE_ID);
>>> > +     if (tmp != VIRTIO_ID_CONSOLE) {
>>> > +             return;
>>> > +     }
>>> > +
>>> > +     tmp = readl_relaxed(early_base + VIRTIO_MMIO_HOST_FEATURES);
>>> > +     if (!(tmp & (1 << VIRTIO_CONSOLE_F_EARLY_WRITE))) {
>>> > +             return;
>>> > +     }
>>> > +     writeb_relaxed(ch, &p->early_rw);
>>>
>>> So here, you end up trapping 3 times per character being output on the
>>> console. Surely there's a better way. How about remembering the result
> of
>>> these tests in a static variable?
>>>
>> Yeah surely it is a better idea to remember using static variable, so
> that
>> after initialize once, it will trap only one time.
>
> Also, would it be possible to directly get the base address from DT? It
> would save having to pass the address (which is not known before runtime in
> the case of kvmtool). Not sure if it is available that early though...
>
>>>
>>> > +}
>>> > +
>>> > +/*
>>> >   * 8250/16550 (8-bit aligned registers) single character TX.
>>> >   */
>>> >  static void uart8250_8bit_printch(char ch)
>>> > @@ -82,6 +105,7 @@ static const struct earlycon_match
> earlycon_match[]
>>> > __initconst = {
>>> >       { .name = "smh", .printch = smh_printch, },
>>> >       { .name = "uart8250-8bit", .printch = uart8250_8bit_printch, },
>>> >       { .name = "uart8250-32bit", .printch = uart8250_32bit_printch,
> },
>>> > +     { .name = "virtio-console", .printch =
>>> virtio_console_early_printch,
>>> },
>>> >       {}
>>> >  };
>>> >
>>> > diff --git a/include/uapi/linux/virtio_console.h
>>> > b/include/uapi/linux/virtio_console.h
>>> > index ee13ab6..1171cb4 100644
>>> > --- a/include/uapi/linux/virtio_console.h
>>> > +++ b/include/uapi/linux/virtio_console.h
>>> > @@ -38,6 +38,8 @@
>>> >  /* Feature bits */
>>> >  #define VIRTIO_CONSOLE_F_SIZE        0       /* Does host provide
>>> console size? */
>>> >  #define VIRTIO_CONSOLE_F_MULTIPORT 1 /* Does host provide multiple
>>> ports?
>>> >  */
>>> > +#define VIRTIO_CONSOLE_F_EARLY_READ 2        /* Does host support
>>> > early
>>> read?
>>> */
>>> > +#define VIRTIO_CONSOLE_F_EARLY_WRITE 3       /* Does host support
>>> > early
>>> write?
>>> > */
>>> >
>>> >  #define VIRTIO_CONSOLE_BAD_ID                (~(u32)0)
>>> >
>>> > @@ -48,6 +50,8 @@ struct virtio_console_config {
>>> >       __u16 rows;
>>> >       /* max. number of ports this device can hold */
>>> >       __u32 max_nr_ports;
>>> > +     /* early read/write register */
>>> > +     __u32 early_rw;
>>> >  } __attribute__((packed));
>>> >
>>> >  /*
>>>
>>> So that bit is clearly a spec change. How does it work with PCI, or any
>>> other virtio transport?
>>>
>> I am not sure about PCI hence just posted for MMIO.
>>
>>>
>>> Overall, I'm a bit concerned with adding features that don't really
> match
>>> the way virtio is supposed to work. The whole goal of virtio is to
>>> minimize
>>> the amount of trapping, and here you end up trapping on each and every
>>> access.
>>>
>>> If you need an early console, why not simply wire the 8250 emulation in
>>> kvmtool to be useable from the MMIO bus? I reckon this would solve your
>>> problem in a more elegant way...
>>>
>> Emulation will solve the issue but having a virtio early read or write
> has
>> one more advantage i.e.
>> In case of mach-virt we might need early read-write support for virtio
>> console to see if kernel is not panic before actual virtio drivers takes
>> control.
>> Also if someone wants to have UEFI or uboot running on mach-virt then we
>> also need early input facility in virtio console.
>
> That's exactly why I was suggesting using the 8250 emulation. It is
> supported by everything under the sun. I do not immediately see what the
> gain is with this virtio approach, as compared to 8250 emulation.
>
> Don't misunderstand me, I like the idea of having a virtio-only system,
> specially if we can make it work with other transports. I just want to
> outline that there may be a simpler way for your particular use case.
>
> Thanks,
>
>         M.
> --
> Fast, cheap, reliable. Pick two.


From linux at arm.linux.org.uk  Thu Apr 18 15:09:23 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Thu, 18 Apr 2013 20:09:23 +0100
Subject: [PATCH] ARM: smp: call platform's cpu_die in ipi_cpu_stop
In-Reply-To: <20130418182534.GD14496@n2100.arm.linux.org.uk>
References: <1365251824-4852-1-git-send-email-kevin@bracey.fi>
 <1365251824-4852-2-git-send-email-kevin@bracey.fi>
 <20130418171801.GC14496@n2100.arm.linux.org.uk>
 <20130418182534.GD14496@n2100.arm.linux.org.uk>
Message-ID: <20130418190923.GE14496@n2100.arm.linux.org.uk>

On Thu, Apr 18, 2013 at 07:25:34PM +0100, Russell King - ARM Linux wrote:
> On Thu, Apr 18, 2013 at 06:18:01PM +0100, Russell King - ARM Linux wrote:
> > On Sat, Apr 06, 2013 at 03:37:04PM +0300, Kevin Bracey wrote:
> > > When hotplugging out, both cpu_kill and cpu_die have always been called.
> > > But when smp_send_stop was used in machine_shutdown or panic, only
> > > cpu_kill was called.
> > > 
> > > This causes problems for co-ordination between cpu_kill and cpu_die, as
> > > attempted by shmobile. So add cpu_die call to ipi_cpu_stop, to ensure
> > > that cpu_kill and cpu_die calls always occur together.
> > 
> > Actually, I'd prefer to pull more code out of the platforms.  Now
> > that we have flush_cache_louis(), we can flush the L1 cache for the
> > CPU going down in cpu_die() itself.  We just need to be careful
> > with that complete() call to ensure that becomes visible to other
> > cores before power is cut to the L1 cache.
> > 
> > That's fine though - because it must become visible for __cpu_die()
> > to continue (otherwise it will time out).
> > 
> > That should render shmobile's cpu_dead thing unnecessary, because the
> > platform independent code will do the required synchronisation.
> 
> So, something like the below (which is a combined patch of three).  The
> key points here being that:
> 
> 1. We flush the L1 cache in cpu_die(), which pushes any dirty cache lines
>    out of the L1 cache and invalidates it.  At the point this function
>    completes, any data in the L1 cache has been pushed out and all
>    cache lines are invalid.
> 2. We complete(), which allows __cpu_die() to proceed and call
>    platform_cpu_kill().  This may create dirty cache lines which this
>    CPU exclusively owns, but the CPU in __cpu_die() will gain those
>    cache lines before wait_for_completion() can return - not only the
>    completion counter but also the spinlock, which this CPU will have
>    ended up reading and writing - and so can no longer be owned by the
>    dying CPU.
> 3. The following mb() is belt and braces to ensure that the completion
>    is visible.  It isn't strictly required because the spinlocks will
>    do the necessary stuff to ensure this.
> 4. Any dirtying of the cache after this rellay doesn't matter _if_ only
>    the stack is touched, or other data is only read.
> 5. I've left those platforms which disable the L1 cache, then flush
>    alone; that _should_ be removable with this patch as well, but as
>    a separate patch.
> 
> Now, with this patch applied, we guarantee that we push out any data
> that matters from the dying CPU before platform_cpu_kill() is called.
> That should mean that shmobile can remove that whole cpu_dead thing.
> 
> I've tested this on OMAP, and it appears to work from a simple test of
> CPU hotplug.  This patch(set) also kills the cpu_disable() that tegra
> has which is just a copy of the generic version.

Okay, last version for tonight, with additional comments too, and a
hole plugged if the powering down is done by the platform via
cpu_die().

 arch/arm/kernel/smp.c               |   42 +++++++++++++++++++++++++++++++---
 arch/arm/mach-exynos/hotplug.c      |    1 -
 arch/arm/mach-highbank/hotplug.c    |    4 ---
 arch/arm/mach-imx/hotplug.c         |    2 -
 arch/arm/mach-msm/hotplug.c         |    4 ---
 arch/arm/mach-omap2/omap-hotplug.c  |    3 --
 arch/arm/mach-prima2/hotplug.c      |    3 --
 arch/arm/mach-realview/hotplug.c    |    2 -
 arch/arm/mach-shmobile/smp-sh73a0.c |    8 ------
 arch/arm/mach-spear13xx/hotplug.c   |    2 -
 arch/arm/mach-tegra/common.h        |    1 -
 arch/arm/mach-tegra/hotplug.c       |   10 --------
 arch/arm/mach-tegra/platsmp.c       |    1 -
 arch/arm/mach-ux500/hotplug.c       |    3 --
 arch/arm/mach-vexpress/hotplug.c    |    2 -
 15 files changed, 38 insertions(+), 50 deletions(-)

diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
index 1f2cccc..4231034 100644
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -211,6 +211,13 @@ void __cpuinit __cpu_die(unsigned int cpu)
 	}
 	printk(KERN_NOTICE "CPU%u: shutdown\n", cpu);
 
+	/*
+	 * platform_cpu_kill() is generally expected to do the powering off
+	 * and/or cutting of clocks to the dying CPU.  Optionally, this may
+	 * be done by the CPU which is dying in preference to supporting
+	 * this call, but that means there is _no_ synchronisation between
+	 * the requesting CPU and the dying CPU actually losing power.
+	 */
 	if (!platform_cpu_kill(cpu))
 		printk("CPU%u: unable to kill\n", cpu);
 }
@@ -230,14 +237,41 @@ void __ref cpu_die(void)
 	idle_task_exit();
 
 	local_irq_disable();
-	mb();
 
-	/* Tell __cpu_die() that this CPU is now safe to dispose of */
+	/*
+	 * Flush the data out of the L1 cache for this CPU.  This must be
+	 * before the completion to ensure that data is safely written out
+	 * before platform_cpu_kill() gets called - which may disable
+	 * *this* CPU and power down its cache.
+	 */
+	flush_cache_louis();
+
+	/*
+	 * Tell __cpu_die() that this CPU is now safe to dispose of.  Once
+	 * this returns, power and/or clocks can be removed at any point
+	 * from this CPU and its cache by platform_cpu_kill().
+	 */
 	RCU_NONIDLE(complete(&cpu_died));
 
 	/*
-	 * actual CPU shutdown procedure is at least platform (if not
-	 * CPU) specific.
+	 * Ensure that the cache lines associated with that completion are
+	 * written out.  This covers the case where _this_ CPU is doing the
+	 * powering down, to ensure that the completion is visible to the
+	 * CPU waiting for this one.
+	 */
+	flush_cache_louis();
+
+	/*
+	 * The actual CPU shutdown procedure is at least platform (if not
+	 * CPU) specific.  This may remove power, or it may simply spin.
+	 *
+	 * Platforms are generally expected *NOT* to return from this call,
+	 * although there are some which do because they have no way to
+	 * power down the CPU.  These platforms are the _only_ reason we
+	 * have a return path which uses the fragment of assembly below.
+	 *
+	 * The return path should not be used for platforms which can
+	 * power off the CPU.
 	 */
 	if (smp_ops.cpu_die)
 		smp_ops.cpu_die(cpu);
diff --git a/arch/arm/mach-exynos/hotplug.c b/arch/arm/mach-exynos/hotplug.c
index c3f825b..af90cfa 100644
--- a/arch/arm/mach-exynos/hotplug.c
+++ b/arch/arm/mach-exynos/hotplug.c
@@ -28,7 +28,6 @@ static inline void cpu_enter_lowpower_a9(void)
 {
 	unsigned int v;
 
-	flush_cache_all();
 	asm volatile(
 	"	mcr	p15, 0, %1, c7, c5, 0\n"
 	"	mcr	p15, 0, %1, c7, c10, 4\n"
diff --git a/arch/arm/mach-highbank/hotplug.c b/arch/arm/mach-highbank/hotplug.c
index f30c528..35dd42e 100644
--- a/arch/arm/mach-highbank/hotplug.c
+++ b/arch/arm/mach-highbank/hotplug.c
@@ -15,8 +15,6 @@
  */
 #include <linux/kernel.h>
 
-#include <asm/cacheflush.h>
-
 #include "core.h"
 #include "sysregs.h"
 
@@ -28,8 +26,6 @@ extern void secondary_startup(void);
  */
 void __ref highbank_cpu_die(unsigned int cpu)
 {
-	flush_cache_all();
-
 	highbank_set_cpu_jump(cpu, phys_to_virt(0));
 	highbank_set_core_pwr();
 
diff --git a/arch/arm/mach-imx/hotplug.c b/arch/arm/mach-imx/hotplug.c
index 361a253..5e91112 100644
--- a/arch/arm/mach-imx/hotplug.c
+++ b/arch/arm/mach-imx/hotplug.c
@@ -11,7 +11,6 @@
  */
 
 #include <linux/errno.h>
-#include <asm/cacheflush.h>
 #include <asm/cp15.h>
 
 #include "common.h"
@@ -20,7 +19,6 @@ static inline void cpu_enter_lowpower(void)
 {
 	unsigned int v;
 
-	flush_cache_all();
 	asm volatile(
 		"mcr	p15, 0, %1, c7, c5, 0\n"
 	"	mcr	p15, 0, %1, c7, c10, 4\n"
diff --git a/arch/arm/mach-msm/hotplug.c b/arch/arm/mach-msm/hotplug.c
index 750446f..326a872 100644
--- a/arch/arm/mach-msm/hotplug.c
+++ b/arch/arm/mach-msm/hotplug.c
@@ -10,16 +10,12 @@
 #include <linux/errno.h>
 #include <linux/smp.h>
 
-#include <asm/cacheflush.h>
 #include <asm/smp_plat.h>
 
 #include "common.h"
 
 static inline void cpu_enter_lowpower(void)
 {
-	/* Just flush the cache. Changing the coherency is not yet
-	 * available on msm. */
-	flush_cache_all();
 }
 
 static inline void cpu_leave_lowpower(void)
diff --git a/arch/arm/mach-omap2/omap-hotplug.c b/arch/arm/mach-omap2/omap-hotplug.c
index e712d17..ceb30a5 100644
--- a/arch/arm/mach-omap2/omap-hotplug.c
+++ b/arch/arm/mach-omap2/omap-hotplug.c
@@ -35,9 +35,6 @@ void __ref omap4_cpu_die(unsigned int cpu)
 	unsigned int boot_cpu = 0;
 	void __iomem *base = omap_get_wakeupgen_base();
 
-	flush_cache_all();
-	dsb();
-
 	/*
 	 * we're ready for shutdown now, so do it
 	 */
diff --git a/arch/arm/mach-prima2/hotplug.c b/arch/arm/mach-prima2/hotplug.c
index f4b17cb..0ab2f8b 100644
--- a/arch/arm/mach-prima2/hotplug.c
+++ b/arch/arm/mach-prima2/hotplug.c
@@ -10,13 +10,10 @@
 #include <linux/errno.h>
 #include <linux/smp.h>
 
-#include <asm/cacheflush.h>
 #include <asm/smp_plat.h>
 
 static inline void platform_do_lowpower(unsigned int cpu)
 {
-	flush_cache_all();
-
 	/* we put the platform to just WFI */
 	for (;;) {
 		__asm__ __volatile__("dsb\n\t" "wfi\n\t"
diff --git a/arch/arm/mach-realview/hotplug.c b/arch/arm/mach-realview/hotplug.c
index 53818e5..ac22dd4 100644
--- a/arch/arm/mach-realview/hotplug.c
+++ b/arch/arm/mach-realview/hotplug.c
@@ -12,7 +12,6 @@
 #include <linux/errno.h>
 #include <linux/smp.h>
 
-#include <asm/cacheflush.h>
 #include <asm/cp15.h>
 #include <asm/smp_plat.h>
 
@@ -20,7 +19,6 @@ static inline void cpu_enter_lowpower(void)
 {
 	unsigned int v;
 
-	flush_cache_all();
 	asm volatile(
 	"	mcr	p15, 0, %1, c7, c5, 0\n"
 	"	mcr	p15, 0, %1, c7, c10, 4\n"
diff --git a/arch/arm/mach-shmobile/smp-sh73a0.c b/arch/arm/mach-shmobile/smp-sh73a0.c
index acb46a9..2f1ef1b 100644
--- a/arch/arm/mach-shmobile/smp-sh73a0.c
+++ b/arch/arm/mach-shmobile/smp-sh73a0.c
@@ -119,14 +119,6 @@ static int sh73a0_cpu_kill(unsigned int cpu)
 
 static void sh73a0_cpu_die(unsigned int cpu)
 {
-	/*
-	 * The ARM MPcore does not issue a cache coherency request for the L1
-	 * cache when powering off single CPUs. We must take care of this and
-	 * further caches.
-	 */
-	dsb();
-	flush_cache_all();
-
 	/* Set power off mode. This takes the CPU out of the MP cluster */
 	scu_power_mode(scu_base_addr(), SCU_PM_POWEROFF);
 
diff --git a/arch/arm/mach-spear13xx/hotplug.c b/arch/arm/mach-spear13xx/hotplug.c
index a7d2dd1..d97749c 100644
--- a/arch/arm/mach-spear13xx/hotplug.c
+++ b/arch/arm/mach-spear13xx/hotplug.c
@@ -13,7 +13,6 @@
 #include <linux/kernel.h>
 #include <linux/errno.h>
 #include <linux/smp.h>
-#include <asm/cacheflush.h>
 #include <asm/cp15.h>
 #include <asm/smp_plat.h>
 
@@ -21,7 +20,6 @@ static inline void cpu_enter_lowpower(void)
 {
 	unsigned int v;
 
-	flush_cache_all();
 	asm volatile(
 	"	mcr	p15, 0, %1, c7, c5, 0\n"
 	"	dsb\n"
diff --git a/arch/arm/mach-tegra/common.h b/arch/arm/mach-tegra/common.h
index 32f8eb3..5900cc4 100644
--- a/arch/arm/mach-tegra/common.h
+++ b/arch/arm/mach-tegra/common.h
@@ -2,4 +2,3 @@ extern struct smp_operations tegra_smp_ops;
 
 extern int tegra_cpu_kill(unsigned int cpu);
 extern void tegra_cpu_die(unsigned int cpu);
-extern int tegra_cpu_disable(unsigned int cpu);
diff --git a/arch/arm/mach-tegra/hotplug.c b/arch/arm/mach-tegra/hotplug.c
index a599f6e..e8323bc 100644
--- a/arch/arm/mach-tegra/hotplug.c
+++ b/arch/arm/mach-tegra/hotplug.c
@@ -12,7 +12,6 @@
 #include <linux/smp.h>
 #include <linux/clk/tegra.h>
 
-#include <asm/cacheflush.h>
 #include <asm/smp_plat.h>
 
 #include "sleep.h"
@@ -47,15 +46,6 @@ void __ref tegra_cpu_die(unsigned int cpu)
 	BUG();
 }
 
-int tegra_cpu_disable(unsigned int cpu)
-{
-	/*
-	 * we don't allow CPU 0 to be shutdown (it is still too special
-	 * e.g. clock tick interrupts)
-	 */
-	return cpu == 0 ? -EPERM : 0;
-}
-
 #ifdef CONFIG_ARCH_TEGRA_2x_SOC
 extern void tegra20_hotplug_shutdown(void);
 void __init tegra20_hotplug_init(void)
diff --git a/arch/arm/mach-tegra/platsmp.c b/arch/arm/mach-tegra/platsmp.c
index 2c6b3d5..ec33ec8 100644
--- a/arch/arm/mach-tegra/platsmp.c
+++ b/arch/arm/mach-tegra/platsmp.c
@@ -192,6 +192,5 @@ struct smp_operations tegra_smp_ops __initdata = {
 #ifdef CONFIG_HOTPLUG_CPU
 	.cpu_kill		= tegra_cpu_kill,
 	.cpu_die		= tegra_cpu_die,
-	.cpu_disable		= tegra_cpu_disable,
 #endif
 };
diff --git a/arch/arm/mach-ux500/hotplug.c b/arch/arm/mach-ux500/hotplug.c
index 2f6af25..1c55a55 100644
--- a/arch/arm/mach-ux500/hotplug.c
+++ b/arch/arm/mach-ux500/hotplug.c
@@ -12,7 +12,6 @@
 #include <linux/errno.h>
 #include <linux/smp.h>
 
-#include <asm/cacheflush.h>
 #include <asm/smp_plat.h>
 
 #include <mach/setup.h>
@@ -24,8 +23,6 @@
  */
 void __ref ux500_cpu_die(unsigned int cpu)
 {
-	flush_cache_all();
-
 	/* directly enter low power state, skipping secure registers */
 	for (;;) {
 		__asm__ __volatile__("dsb\n\t" "wfi\n\t"
diff --git a/arch/arm/mach-vexpress/hotplug.c b/arch/arm/mach-vexpress/hotplug.c
index a141b98..f0ce6b8 100644
--- a/arch/arm/mach-vexpress/hotplug.c
+++ b/arch/arm/mach-vexpress/hotplug.c
@@ -12,7 +12,6 @@
 #include <linux/errno.h>
 #include <linux/smp.h>
 
-#include <asm/cacheflush.h>
 #include <asm/smp_plat.h>
 #include <asm/cp15.h>
 
@@ -20,7 +19,6 @@ static inline void cpu_enter_lowpower(void)
 {
 	unsigned int v;
 
-	flush_cache_all();
 	asm volatile(
 		"mcr	p15, 0, %1, c7, c5, 0\n"
 	"	mcr	p15, 0, %1, c7, c10, 4\n"


From robherring2 at gmail.com  Thu Apr 18 15:30:10 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Thu, 18 Apr 2013 14:30:10 -0500
Subject: [PATCH 2/2] clocksource: arm_arch_timer: add boot and suspend
 sched_clock offset
In-Reply-To: <1366313410-16692-1-git-send-email-robherring2@gmail.com>
References: <1366313410-16692-1-git-send-email-robherring2@gmail.com>
Message-ID: <1366313410-16692-2-git-send-email-robherring2@gmail.com>

From: Rob Herring <rob.herring at calxeda.com>

Commit 023796b (ARM: arch_timer: use full 64-bit counter for sched_clock)
fails to ensure sched_clock always starts at time 0 and counting is
suspended during suspend. arm64 sched_clock support also has the same
issues. This fixes all architected timer users by maintaining an initial
offset which is updated on resume.

Signed-off-by: Rob Herring <rob.herring at calxeda.com>
Cc: Russell King <linux at arm.linux.org.uk>
Cc: John Stultz <john.stultz at linaro.org>
Cc: Thomas Gleixner <tglx at linutronix.de>
Cc: Catalin Marinas <catalin.marinas at arm.com>
Cc: Will Deacon <will.deacon at arm.com>
Cc: Stephen Boyd <sboyd at codeaurora.org>
---
 arch/arm/kernel/arch_timer.c         |    1 +
 drivers/clocksource/arm_arch_timer.c |   26 +++++++++++++++++++++++++-
 2 files changed, 26 insertions(+), 1 deletion(-)

diff --git a/arch/arm/kernel/arch_timer.c b/arch/arm/kernel/arch_timer.c
index df6825e..9a517fe 100644
--- a/arch/arm/kernel/arch_timer.c
+++ b/arch/arm/kernel/arch_timer.c
@@ -42,5 +42,6 @@ int __init arch_timer_arch_init(void)
 	arch_timer_delay_timer_register();
 
 	sched_clock_func = arch_timer_sched_clock;
+
 	return 0;
 }
diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
index 17ed8e4..cc0bd67 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -17,6 +17,7 @@
 #include <linux/interrupt.h>
 #include <linux/of_irq.h>
 #include <linux/io.h>
+#include <linux/syscore_ops.h>
 
 #include <asm/arch_timer.h>
 #include <asm/virt.h>
@@ -267,14 +268,34 @@ static struct notifier_block arch_timer_cpu_nb __cpuinitdata = {
 };
 
 static u64 sched_clock_mult __read_mostly;
+static u64 arch_timer_suspend_cyc;
+static u64 arch_timer_sched_clock_offset;
 
 unsigned long long notrace arch_timer_sched_clock(void)
 {
-	return arch_timer_read_counter() * sched_clock_mult;
+	u64 cyc = arch_timer_read_counter() - arch_timer_sched_clock_offset;
+	return cyc * sched_clock_mult;
 }
 unsigned long long sched_clock(void) \
 	__attribute__((weak, alias("arch_timer_sched_clock")));
 
+static int arch_timer_suspend(void)
+{
+	arch_timer_suspend_cyc = arch_timer_read_counter();
+	return 0;
+}
+
+static void arch_timer_resume(void)
+{
+	arch_timer_sched_clock_offset +=
+		arch_timer_read_counter() - arch_timer_suspend_cyc;
+}
+
+static struct syscore_ops arch_timer_ops = {
+	.suspend = arch_timer_suspend,
+	.resume = arch_timer_resume,
+};
+
 static int __init arch_timer_register(void)
 {
 	int err;
@@ -332,6 +353,9 @@ static int __init arch_timer_register(void)
 	pr_info("sched_clock: ARM arch timer >56 bits at %ukHz, resolution %lluns\n",
 		arch_timer_rate / 1000, sched_clock_mult);
 
+	arch_timer_sched_clock_offset = arch_timer_read_counter();
+	register_syscore_ops(&arch_timer_ops);
+
 	return 0;
 
 out_free_irq:
-- 
1.7.10.4



From robherring2 at gmail.com  Thu Apr 18 15:30:09 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Thu, 18 Apr 2013 14:30:09 -0500
Subject: [PATCH 1/2] clocksource: arm_arch_timer: unify sched_clock init
Message-ID: <1366313410-16692-1-git-send-email-robherring2@gmail.com>

From: Rob Herring <rob.herring at calxeda.com>

In preparation to fix initial time and suspend/resume handling, unify
the sched_clock init and implementation for arch timer on arm and arm64.

Signed-off-by: Rob Herring <rob.herring at calxeda.com>
Cc: Russell King <linux at arm.linux.org.uk>
Cc: Catalin Marinas <catalin.marinas at arm.com>
Cc: Will Deacon <will.deacon at arm.com>
Cc: John Stultz <john.stultz at linaro.org>
Cc: Thomas Gleixner <tglx at linutronix.de>
Cc: Stephen Boyd <sboyd at codeaurora.org>
---
 arch/arm/kernel/arch_timer.c         |   12 ------------
 arch/arm64/kernel/time.c             |   10 ----------
 drivers/clocksource/arm_arch_timer.c |   14 ++++++++++++++
 include/clocksource/arm_arch_timer.h |    1 +
 4 files changed, 15 insertions(+), 22 deletions(-)

diff --git a/arch/arm/kernel/arch_timer.c b/arch/arm/kernel/arch_timer.c
index 59dcdce..df6825e 100644
--- a/arch/arm/kernel/arch_timer.c
+++ b/arch/arm/kernel/arch_timer.c
@@ -22,13 +22,6 @@ static unsigned long arch_timer_read_counter_long(void)
 	return arch_timer_read_counter();
 }
 
-static u32 sched_clock_mult __read_mostly;
-
-static unsigned long long notrace arch_timer_sched_clock(void)
-{
-	return arch_timer_read_counter() * sched_clock_mult;
-}
-
 static struct delay_timer arch_delay_timer;
 
 static void __init arch_timer_delay_timer_register(void)
@@ -48,11 +41,6 @@ int __init arch_timer_arch_init(void)
 
 	arch_timer_delay_timer_register();
 
-	/* Cache the sched_clock multiplier to save a divide in the hot path. */
-	sched_clock_mult = NSEC_PER_SEC / arch_timer_rate;
 	sched_clock_func = arch_timer_sched_clock;
-	pr_info("sched_clock: ARM arch timer >56 bits at %ukHz, resolution %uns\n",
-		arch_timer_rate / 1000, sched_clock_mult);
-
 	return 0;
 }
diff --git a/arch/arm64/kernel/time.c b/arch/arm64/kernel/time.c
index a551f88..3a369aa 100644
--- a/arch/arm64/kernel/time.c
+++ b/arch/arm64/kernel/time.c
@@ -61,13 +61,6 @@ unsigned long profile_pc(struct pt_regs *regs)
 EXPORT_SYMBOL(profile_pc);
 #endif
 
-static u64 sched_clock_mult __read_mostly;
-
-unsigned long long notrace sched_clock(void)
-{
-	return arch_timer_read_counter() * sched_clock_mult;
-}
-
 int read_current_timer(unsigned long *timer_value)
 {
 	*timer_value = arch_timer_read_counter();
@@ -84,9 +77,6 @@ void __init time_init(void)
 	if (!arch_timer_rate)
 		panic("Unable to initialise architected timer.\n");
 
-	/* Cache the sched_clock multiplier to save a divide in the hot path. */
-	sched_clock_mult = NSEC_PER_SEC / arch_timer_rate;
-
 	/* Calibrate the delay loop directly */
 	lpj_fine = arch_timer_rate / HZ;
 }
diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
index 122ff05..17ed8e4 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -266,6 +266,15 @@ static struct notifier_block arch_timer_cpu_nb __cpuinitdata = {
 	.notifier_call = arch_timer_cpu_notify,
 };
 
+static u64 sched_clock_mult __read_mostly;
+
+unsigned long long notrace arch_timer_sched_clock(void)
+{
+	return arch_timer_read_counter() * sched_clock_mult;
+}
+unsigned long long sched_clock(void) \
+	__attribute__((weak, alias("arch_timer_sched_clock")));
+
 static int __init arch_timer_register(void)
 {
 	int err;
@@ -318,6 +327,11 @@ static int __init arch_timer_register(void)
 	/* Immediately configure the timer on the boot CPU */
 	arch_timer_setup(this_cpu_ptr(arch_timer_evt));
 
+	/* Cache the sched_clock multiplier to save a divide in the hot path. */
+	sched_clock_mult = NSEC_PER_SEC / arch_timer_rate;
+	pr_info("sched_clock: ARM arch timer >56 bits at %ukHz, resolution %lluns\n",
+		arch_timer_rate / 1000, sched_clock_mult);
+
 	return 0;
 
 out_free_irq:
diff --git a/include/clocksource/arm_arch_timer.h b/include/clocksource/arm_arch_timer.h
index e6c9c4c..ded7c77 100644
--- a/include/clocksource/arm_arch_timer.h
+++ b/include/clocksource/arm_arch_timer.h
@@ -34,6 +34,7 @@
 extern u32 arch_timer_get_rate(void);
 extern u64 (*arch_timer_read_counter)(void);
 extern struct timecounter *arch_timer_get_timecounter(void);
+extern unsigned long long notrace arch_timer_sched_clock(void);
 
 #else
 
-- 
1.7.10.4



From gmbnomis at gmail.com  Thu Apr 18 15:39:57 2013
From: gmbnomis at gmail.com (Simon Baatz)
Date: Thu, 18 Apr 2013 21:39:57 +0200
Subject: [PATCH V3 2/2] ARM: Handle user space mapped pages in
 flush_kernel_dcache_page
In-Reply-To: <20130418114016.GG27197@titan.lakedaemon.net>
References: <1349609352-6408-1-git-send-email-gmbnomis@gmail.com>
 <1349609352-6408-3-git-send-email-gmbnomis@gmail.com>
 <20121008174428.GB3204@arm.com>
 <20121008200216.GA14167@schnuecks.de>
 <20121008202040.GC4625@n2100.arm.linux.org.uk>
 <20121008230733.GA17819@schnuecks.de>
 <20121118211005.GW22106@titan.lakedaemon.net>
 <20130418111608.GF27197@titan.lakedaemon.net>
 <20130418112201.GQ14496@n2100.arm.linux.org.uk>
 <20130418114016.GG27197@titan.lakedaemon.net>
Message-ID: <20130418193957.GB2778@schnuecks.de>

Hi Jason,

On Thu, Apr 18, 2013 at 07:40:16AM -0400, Jason Cooper wrote:
> On Thu, Apr 18, 2013 at 12:22:01PM +0100, Russell King - ARM Linux wrote:
> > On Thu, Apr 18, 2013 at 07:16:08AM -0400, Jason Cooper wrote:
> > > Russell, Catalin, Simon,
> > > 
> > > I'm digging through my 'onice' mail folder and found this.  I've
> > > personally experienced this bug in the past (workaround: don't use LVM
> > > on ARM systems :-( ).
> > > 
> > > Is there any interest in reviving this series?  I can dig up the patches
> > > if needed.
...
> 
> Ok, got it.  I should have been more explicit.  LVM doesn't work on ARM.
> iirc, Simon had a demo of dm-crypt also faulting on ARM.  This patch was
> not the correct approach.  Is there an interest (particularly Simon) in
> fixing the problem?
> 
> I'm willing to take a look at it, but LVM on ARM is a "nice to have" for
> me, not a critical need.  The job would be easier if Simon was willing
> to assist and lend his experience with the issue.

Just to be precise here, the problem is much more specific: Drivers
which use flush_kernel_dcache_page() on VIVT or aliasing VIPT ARM
architectures may have problems with direct I/O.

In general, LVM should work perfectly fine on ARM. But if you have
this particular combination (in my case Kirkwood ARMv5 with VIVT
D-Cache and the mv_cesa driver), you can't put a physical volume on
such a device.  LVM user space tools will just read garbage when
trying to read from the device using direct I/O.

- Simon


From kevin at bracey.fi  Thu Apr 18 15:44:49 2013
From: kevin at bracey.fi (Kevin Bracey)
Date: Thu, 18 Apr 2013 22:44:49 +0300
Subject: [PATCH] ARM: smp: call platform's cpu_die in ipi_cpu_stop
In-Reply-To: <20130418182534.GD14496@n2100.arm.linux.org.uk>
References: <1365251824-4852-1-git-send-email-kevin@bracey.fi>
 <1365251824-4852-2-git-send-email-kevin@bracey.fi>
 <20130418171801.GC14496@n2100.arm.linux.org.uk>
 <20130418182534.GD14496@n2100.arm.linux.org.uk>
Message-ID: <51704D31.10808@bracey.fi>

On 18/04/2013 21:25, Russell King - ARM Linux wrote:
> Now, with this patch applied, we guarantee that we push out any data 
> that matters from the dying CPU before platform_cpu_kill() is called. 
> That should mean that shmobile can remove that whole cpu_dead thing.

Patch looks supremely sensible. Clearly there is more centralisation 
needed for the generic cache issue, and that addresses the currently 
upstream shmobile stuff.

But I had also been intending to have "post-kill" co-ordination for 
power control and error reporting. Something along the lines of:

1) cpu_die tells the power hardware to shut down the core on next 
STANDBYWFI assertion, then does the final chip-specific clear-up, then WFI.

2) cpu_kill waits for the power hardware to report shutdown of that 
core, and reports success, or failure after timeout.

That seemed logical, but it just doesn't fly when cpu_kill routinely 
occurs without cpu_die. We again end up timing out (once per CPU) in 
that case, which can add a significant time to panic/shutdown.

Am I on the right lines here, or misunderstanding? It seems like a 
pretty natural thing to attempt. And it would have worked fine before 
the die-less kill was added to smp_send_stop.

If anyone ever has both die and kill implemented and doing something in 
a platform, they will have to have some sort of co-ordination, as 
there's a race for kill running before die is finished. (Although it 
could be that what they do is so simple/fast that die is "guaranteed" to 
win the race). This patch takes the slow cache clean out, so solves it 
for that, but the essential race problem remains for anything 
platform-specific in cpu_die. So I still think every kill needs a die. 
Unless you expect each platform to use only one of the hooks.

Alternatively, I guess you could just pass a parameter to cpu_kill to 
tell it "I'm not sending a die request". (I've not figured out a way to 
deduce it). In which case, cpu_kill would just become a NOP in that case 
for me. Although wasn't the original motivation for it being added to 
smp_send_stop that it would do the necessary to power down the core for 
a kexec restart? So it wouldn't achieve that.

Kevin



From linux at arm.linux.org.uk  Thu Apr 18 15:57:35 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Thu, 18 Apr 2013 20:57:35 +0100
Subject: [PATCH] ARM: smp: call platform's cpu_die in ipi_cpu_stop
In-Reply-To: <51704D31.10808@bracey.fi>
References: <1365251824-4852-1-git-send-email-kevin@bracey.fi>
 <1365251824-4852-2-git-send-email-kevin@bracey.fi>
 <20130418171801.GC14496@n2100.arm.linux.org.uk>
 <20130418182534.GD14496@n2100.arm.linux.org.uk> <51704D31.10808@bracey.fi>
Message-ID: <20130418195735.GF14496@n2100.arm.linux.org.uk>

On Thu, Apr 18, 2013 at 10:44:49PM +0300, Kevin Bracey wrote:
> On 18/04/2013 21:25, Russell King - ARM Linux wrote:
>> Now, with this patch applied, we guarantee that we push out any data  
>> that matters from the dying CPU before platform_cpu_kill() is called.  
>> That should mean that shmobile can remove that whole cpu_dead thing.
>
> Patch looks supremely sensible. Clearly there is more centralisation  
> needed for the generic cache issue, and that addresses the currently  
> upstream shmobile stuff.
>
> But I had also been intending to have "post-kill" co-ordination for  
> power control and error reporting. Something along the lines of:
>
> 1) cpu_die tells the power hardware to shut down the core on next  
> STANDBYWFI assertion, then does the final chip-specific clear-up, then 
> WFI.
>
> 2) cpu_kill waits for the power hardware to report shutdown of that  
> core, and reports success, or failure after timeout.
>
> That seemed logical, but it just doesn't fly when cpu_kill routinely  
> occurs without cpu_die. We again end up timing out (once per CPU) in  
> that case, which can add a significant time to panic/shutdown.
>
> Am I on the right lines here, or misunderstanding? It seems like a  
> pretty natural thing to attempt. And it would have worked fine before  
> the die-less kill was added to smp_send_stop.

Well, the idea as far as hotplug CPU is concerned is that we guarantee
in core code that platform_cpu_kill() will not be called until it is
safe for the dying CPU to be powered off - so the synchronisation is
done by the core code.  That's always been what the completion stuff
is about in arch/arm/kernel/smp.c.

It was missing the cache bits because (a) the ARM development platforms
don't actually take the CPUs offline, and (b) we never really had an
API at the time hotplug CPU was designed to flush just the local CPUs
L1 cache.

Now, practically, most platforms which cut power/clocks to the CPU do
it in one of two ways.  Either they do it in their cpu_die() callback,
via WFI, or they do it from a running CPU via the cpu_kill() callback.

Either way, platforms are not expected to have any further
synchronisation.  Once that complete() call has returned, the dying
CPU is expected to become dead very shortly after that point - whether
that be as a result of cpu_kill() or cpu_die().

> If anyone ever has both die and kill implemented and doing something in  
> a platform, they will have to have some sort of co-ordination, as  
> there's a race for kill running before die is finished. (Although it  
> could be that what they do is so simple/fast that die is "guaranteed" to  
> win the race). This patch takes the slow cache clean out, so solves it  
> for that, but the essential race problem remains for anything  
> platform-specific in cpu_die. So I still think every kill needs a die.  
> Unless you expect each platform to use only one of the hooks.

The whole point is to stop platforms having to implement synchronisation
in these callbacks, with all the bugs that will cause.  The patch I
posted took about an hour of thought and walking through, and discussion
with Will to make sure that all issues had been covered.  Taking a CPU
offline safely is far from trivial, and the less code that a platform
has to do the better.

Now, as for the stop IPI, what we do there is debatable, because that
gets used for several purposes, which includes a bringing the machine
to a halt after a kernel panic.  In those situations, doing the
synchronisation is not appropriate, because we may be panicing because
something has gone wrong in the scheduler.  So, solving that part
safely is going to be far from trivial.

The whole idea there at the _moment_ is that it's safer to make the CPU
core spin, and _maybe_ have it powered down by the kill stuff than it
is to try and call out to platform code.  But that's not what kexec
needs - that needs the CPU cores thrown back into a state as if the
system was first booting.  Some platforms can do that, others have
absolutely no way to do that.  This is _very_ hit and miss on what's
possible.


From tony at atomide.com  Thu Apr 18 16:09:36 2013
From: tony at atomide.com (Tony Lindgren)
Date: Thu, 18 Apr 2013 13:09:36 -0700
Subject: [PATCH] ARM: dts: omap4-panda: Add USB Host support
In-Reply-To: <1366015721-25608-1-git-send-email-rogerq@ti.com>
References: <1366015721-25608-1-git-send-email-rogerq@ti.com>
Message-ID: <20130418200935.GD10155@atomide.com>

* Roger Quadros <rogerq at ti.com> [130415 01:53]:
> Provide the RESET and Power regulators for the USB PHY,
> the USB Host port mode and the PHY device.
> 
> The USB PHY needs AUXCLK3 to operate. Provide this information
> as well.
> 
> Also provide pin multiplexer information for the USB host
> pins.
> 
> This patch depends on OMAP clock binding introduced in
> https://lkml.org/lkml/2013/4/12/407

Cool looks like EHCI works with this on my panda with linux
next booting with DT. One comment below.

Regards,

Tony

 
> CC: Beno?t Cousson <b-cousson at ti.com>
> Signed-off-by: Roger Quadros <rogerq at ti.com>
> ---
>  arch/arm/boot/dts/omap4-panda-common.dtsi |   58 +++++++++++++++++++++++++++++
>  arch/arm/boot/dts/omap4.dtsi              |    5 ++
>  2 files changed, 63 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi b/arch/arm/boot/dts/omap4-panda-common.dtsi
> index 03bd60d..628f744 100644
> --- a/arch/arm/boot/dts/omap4-panda-common.dtsi
> +++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
> @@ -54,6 +54,38 @@
>  			"AFML", "Line In",
>  			"AFMR", "Line In";
>  	};
> +
> +	/* HS USB Port 1 RESET */
> +	hsusb1_reset: hsusb1_reset_reg {
> +		compatible = "regulator-fixed";
> +		regulator-name = "hsusb1_reset";
> +		regulator-min-microvolt = <3300000>;
> +		regulator-max-microvolt = <3300000>;
> +		gpio = <&gpio2 30 0>;	/* gpio_62 */
> +		startup-delay-us = <70000>;
> +		enable-active-high;
> +	};
> +
> +	/* HS USB Port 1 Power */
> +	hsusb1_power: hsusb1_power_reg {
> +		compatible = "regulator-fixed";
> +		regulator-name = "hsusb1_vbus";
> +		regulator-min-microvolt = <3300000>;
> +		regulator-max-microvolt = <3300000>;
> +		gpio = <&gpio1 1 0>;	/* gpio_1 */
> +		startup-delay-us = <70000>;
> +		enable-active-high;
> +	};
> +
> +	/* HS USB Host PHY on PORT 1 */
> +	hsusb1_phy: hsusb1_phy {
> +		compatible = "usb-nop-xceiv";
> +		reset-supply = <&hsusb1_reset>;
> +		vcc-supply = <&hsusb1_power>;
> +		clocks = <&auxclk3>;
> +		clock-names = "main_clk";
> +		clock-frequency = <19200000>;
> +	};
>  };
>  
>  &omap4_pmx_core {
> @@ -64,6 +96,7 @@
>  			&mcbsp1_pins
>  			&dss_hdmi_pins
>  			&tpd12s015_pins
> +			&hsusbb1_pins
>  	>;
>  
>  	twl6040_pins: pinmux_twl6040_pins {
> @@ -108,6 +141,23 @@
>  		>;
>  	};
>  
> +	hsusbb1_pins: pinmux_hsusbb1_pins {
> +		pinctrl-single,pins = <
> +			0x82 0x10C	/* USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_clk INPUT | PULLDOWN */
> +			0x84 0x4	/* USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_stp OUTPUT */
> +			0x86 0x104	/* USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dir INPUT | PULLDOWN */
> +			0x88 0x104	/* USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_nxt INPUT | PULLDOWN */
> +			0x8a 0x104	/* USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat0 INPUT | PULLDOWN */
> +			0x8c 0x104	/* USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat1 INPUT | PULLDOWN */
> +			0x8e 0x104	/* USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat2 INPUT | PULLDOWN */
> +			0x90 0x104	/* USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat3 INPUT | PULLDOWN */
> +			0x92 0x104	/* USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat4 INPUT | PULLDOWN */
> +			0x94 0x104	/* USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat5 INPUT | PULLDOWN */
> +			0x96 0x104	/* USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat6 INPUT | PULLDOWN */
> +			0x98 0x104	/* USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat7 INPUT | PULLDOWN */
> +		>;
> +	};
> +
>  	i2c1_pins: pinmux_i2c1_pins {
>  		pinctrl-single,pins = <
>  			0xe2 0x118        /* i2c1_scl PULLUP | INPUTENABLE | MODE0 */

Looks like your comments are wrong above, it's not PULLDOWN? Also
the naming should be mode0name.modename to be consistent. Here's
what I dumped out, please check and replace spaces with tabs:

                        0x82 0x10c      /* usbb1_ulpitll_clk.usbb1_ulpiphy_clk gpio84 INPUT_PULLDOWN | MODE4 */
                        0x84 0x4        /* usbb1_ulpitll_stp.usbb1_ulpiphy_stp gpio85 OUTPUT | MODE4 */
                        0x86 0x104      /* usbb1_ulpitll_dir.usbb1_ulpiphy_dir gpio86 INPUT | MODE4 */
                        0x88 0x104      /* usbb1_ulpitll_nxt.usbb1_ulpiphy_nxt gpio87 INPUT | MODE4 */
                        0x8a 0x104      /* usbb1_ulpitll_dat0.usbb1_ulpiphy_dat0 gpio88 INPUT | MODE4 */
                        0x8c 0x104      /* usbb1_ulpitll_dat1.usbb1_ulpiphy_dat1 gpio89 INPUT | MODE4 */
                        0x8e 0x104      /* usbb1_ulpitll_dat2.usbb1_ulpiphy_dat2 gpio90 INPUT | MODE4 */
                        0x90 0x104      /* usbb1_ulpitll_dat3.usbb1_ulpiphy_dat3 gpio91 INPUT | MODE4 */
                        0x92 0x104      /* usbb1_ulpitll_dat4.usbb1_ulpiphy_dat4 gpio92 INPUT | MODE4 */
                        0x94 0x104      /* usbb1_ulpitll_dat5.usbb1_ulpiphy_dat5 gpio93 INPUT | MODE4 */
                        0x96 0x104      /* usbb1_ulpitll_dat6.usbb1_ulpiphy_dat6 gpio94 INPUT | MODE4 */
                        0x98 0x104      /* usbb1_ulpitll_dat7.usbb1_ulpiphy_dat7 gpio95 INPUT | MODE4 */

Then at some point soon we can just replace the mode value with DT
preprocessor automatically.

> @@ -249,3 +299,11 @@
>  	mode = <3>;
>  	power = <50>;
>  };
> +
> +&usbhshost {
> +	port1-mode = "ehci-phy";
> +};
> +
> +&usbhsehci {
> +	phys = <&hsusb1_phy>;
> +};
> diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
> index 2a56428..bd6036e 100644
> --- a/arch/arm/boot/dts/omap4.dtsi
> +++ b/arch/arm/boot/dts/omap4.dtsi
> @@ -660,5 +660,10 @@
>  			ram-bits = <12>;
>  			ti,has-mailbox;
>  		};
> +
> +		auxclk3: auxclk3 {
> +			#clock-cells = <0>;
> +			compatible = "ti,omap-clock";
> +		};
>  	};
>  };
> -- 
> 1.7.4.1
> 


From mturquette at linaro.org  Thu Apr 18 16:22:10 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Thu, 18 Apr 2013 13:22:10 -0700
Subject: [PATCH] clk: vexpress: Add separate SP810 driver
In-Reply-To: <1366305802.3077.37.camel@hornet>
References: <1363358409-5693-1-git-send-email-pawel.moll@arm.com>
 <20130417222630.19887.75481@quantum> <1366305802.3077.37.camel@hornet>
Message-ID: <20130418202210.22729.13362@quantum>

Quoting Pawel Moll (2013-04-18 10:23:22)
> On Wed, 2013-04-17 at 23:26 +0100, Mike Turquette wrote:
> > In this case you are using clk_prepare for one-time configuration.  I
> > agree that no alternative exists yet, but there have been discussions
> > recently about using DT for configuration details that are not strictly
> > descriptions of the hardware.  I've added a comment block in the patch
> > below which notes this with a FIXME since there isn't a graceful
> > alternative to using clk_prepare for ont-time configuration.
> 
> Fair enough.
> 
> > Can you test the patch below against the latest clk-next and let me know
> > if it working on your platform?
> 
> It wasn't:
> 
> WARNING: at [...]/drivers/clk/clk.c:808 __clk_enable+0x94/0xa0()
> 
> because the new parent is not prepared automagically. This simple change
> heals the problem and now everything is just fine:
> 
>         /* Switch the parent if necessary */
> -       if (old_parent != new_parent)
> +       if (old_parent != new_parent) {
> +               clk_prepare(new_parent);
>                 clk_set_parent(hw->clk, new_parent);
> +               clk_unprepare(old_parent);
> +       }
> 
> So, to summarize, the patch that works for me is below.
> 

Ah yes, that's a bit tricky.  All of the parents of the sp810 clk will
have prepare_count >= 1, but not the sp810 clk itself when this code is
executed.  Otherwise clk_set_prepare would have migrated the
prepare_count(s) over automagically.  Another reason to revisit this
code some day.

I've gone ahead and merged the patch below.

Thanks!
Mike

> Thanks for you help!
> 
> Pawel
> 
> 8<--------------------------------
> From 58807cc1930edd092f1bc54b2ec381ddc9209671 Mon Sep 17 00:00:00 2001
> From: Pawel Moll <pawel.moll at arm.com>
> Date: Thu, 18 Apr 2013 18:20:54 +0100
> Subject: [PATCH] clk: vexpress: Add separate SP810 driver
> 
> Factor out the SP810 clocking code into a separate driver,
> selecting better (faster) parent at clk_prepare() time.
> This is to avoid problems with clocking infrastructure
> initialisation order, in particular to avoid dependency
> of fixed clock being initialized before SP810. It also
> makes vexpress platform OF-based clock initialisation code
> unnecessary.
> 
> Signed-off-by: Pawel Moll <pawel.moll at arm.com>
> Tested-by: Catalin Marinas <catalin.marinas at arm.com>
> Signed-off-by: Mike Turquette <mturquette at linaro.org>
> [mturquette at linaro.org: add .unprepare, FIXME comment, cleaned up code]
> ---
>  arch/arm/mach-vexpress/v2m.c         |    8 +-
>  drivers/clk/versatile/Makefile       |    2 +-
>  drivers/clk/versatile/clk-sp810.c    |  188 ++++++++++++++++++++++++++++++++++
>  drivers/clk/versatile/clk-vexpress.c |   49 ---------
>  4 files changed, 196 insertions(+), 51 deletions(-)
>  create mode 100644 drivers/clk/versatile/clk-sp810.c
> 
> diff --git a/arch/arm/mach-vexpress/v2m.c b/arch/arm/mach-vexpress/v2m.c
> index 915683c..c5e20b5 100644
> --- a/arch/arm/mach-vexpress/v2m.c
> +++ b/arch/arm/mach-vexpress/v2m.c
> @@ -21,6 +21,8 @@
>  #include <linux/regulator/fixed.h>
>  #include <linux/regulator/machine.h>
>  #include <linux/vexpress.h>
> +#include <linux/clk-provider.h>
> +#include <linux/clkdev.h>
>  
>  #include <asm/arch_timer.h>
>  #include <asm/mach-types.h>
> @@ -433,7 +435,7 @@ static void __init v2m_dt_timer_init(void)
>  {
>         struct device_node *node = NULL;
>  
> -       vexpress_clk_of_init();
> +       of_clk_init(NULL);
>  
>         do {
>                 node = of_find_compatible_node(node, NULL, "arm,sp804");
> @@ -441,6 +443,10 @@ static void __init v2m_dt_timer_init(void)
>         if (node) {
>                 pr_info("Using SP804 '%s' as a clock & events source\n",
>                                 node->full_name);
> +               WARN_ON(clk_register_clkdev(of_clk_get_by_name(node,
> +                               "timclken1"), "v2m-timer0", "sp804"));
> +               WARN_ON(clk_register_clkdev(of_clk_get_by_name(node,
> +                               "timclken2"), "v2m-timer1", "sp804"));
>                 v2m_sp804_init(of_iomap(node, 0),
>                                 irq_of_parse_and_map(node, 0));
>         }
> diff --git a/drivers/clk/versatile/Makefile b/drivers/clk/versatile/Makefile
> index ec3b88f..c16ca78 100644
> --- a/drivers/clk/versatile/Makefile
> +++ b/drivers/clk/versatile/Makefile
> @@ -3,5 +3,5 @@ obj-$(CONFIG_ICST)              += clk-icst.o
>  obj-$(CONFIG_ARCH_INTEGRATOR)  += clk-integrator.o
>  obj-$(CONFIG_INTEGRATOR_IMPD1) += clk-impd1.o
>  obj-$(CONFIG_ARCH_REALVIEW)    += clk-realview.o
> -obj-$(CONFIG_ARCH_VEXPRESS)    += clk-vexpress.o
> +obj-$(CONFIG_ARCH_VEXPRESS)    += clk-vexpress.o clk-sp810.o
>  obj-$(CONFIG_VEXPRESS_CONFIG)  += clk-vexpress-osc.o
> diff --git a/drivers/clk/versatile/clk-sp810.c b/drivers/clk/versatile/clk-sp810.c
> new file mode 100644
> index 0000000..bf9b15a
> --- /dev/null
> +++ b/drivers/clk/versatile/clk-sp810.c
> @@ -0,0 +1,188 @@
> +/*
> + * 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.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * Copyright (C) 2013 ARM Limited
> + */
> +
> +#include <linux/amba/sp810.h>
> +#include <linux/clkdev.h>
> +#include <linux/clk-provider.h>
> +#include <linux/err.h>
> +#include <linux/of.h>
> +#include <linux/of_address.h>
> +
> +#define to_clk_sp810_timerclken(_hw) \
> +               container_of(_hw, struct clk_sp810_timerclken, hw)
> +
> +struct clk_sp810;
> +
> +struct clk_sp810_timerclken {
> +       struct clk_hw hw;
> +       struct clk *clk;
> +       struct clk_sp810 *sp810;
> +       int channel;
> +};
> +
> +struct clk_sp810 {
> +       struct device_node *node;
> +       int refclk_index, timclk_index;
> +       void __iomem *base;
> +       spinlock_t lock;
> +       struct clk_sp810_timerclken timerclken[4];
> +       struct clk *refclk;
> +       struct clk *timclk;
> +};
> +
> +static u8 clk_sp810_timerclken_get_parent(struct clk_hw *hw)
> +{
> +       struct clk_sp810_timerclken *timerclken = to_clk_sp810_timerclken(hw);
> +       u32 val = readl(timerclken->sp810->base + SCCTRL);
> +
> +       return !!(val & (1 << SCCTRL_TIMERENnSEL_SHIFT(timerclken->channel)));
> +}
> +
> +static int clk_sp810_timerclken_set_parent(struct clk_hw *hw, u8 index)
> +{
> +       struct clk_sp810_timerclken *timerclken = to_clk_sp810_timerclken(hw);
> +       struct clk_sp810 *sp810 = timerclken->sp810;
> +       u32 val, shift = SCCTRL_TIMERENnSEL_SHIFT(timerclken->channel);
> +       unsigned long flags = 0;
> +
> +       if (WARN_ON(index > 1))
> +               return -EINVAL;
> +
> +       spin_lock_irqsave(&sp810->lock, flags);
> +
> +       val = readl(sp810->base + SCCTRL);
> +       val &= ~(1 << shift);
> +       val |= index << shift;
> +       writel(val, sp810->base + SCCTRL);
> +
> +       spin_unlock_irqrestore(&sp810->lock, flags);
> +
> +       return 0;
> +}
> +
> +/*
> + * FIXME - setting the parent every time .prepare is invoked is inefficient.
> + * This is better handled by a dedicated clock tree configuration mechanism at
> + * init-time.  Revisit this later when such a mechanism exists
> + */
> +static int clk_sp810_timerclken_prepare(struct clk_hw *hw)
> +{
> +       struct clk_sp810_timerclken *timerclken = to_clk_sp810_timerclken(hw);
> +       struct clk_sp810 *sp810 = timerclken->sp810;
> +       struct clk *old_parent = __clk_get_parent(hw->clk);
> +       struct clk *new_parent;
> +
> +       if (!sp810->refclk)
> +               sp810->refclk = of_clk_get(sp810->node, sp810->refclk_index);
> +
> +       if (!sp810->timclk)
> +               sp810->timclk = of_clk_get(sp810->node, sp810->timclk_index);
> +
> +       if (WARN_ON(IS_ERR(sp810->refclk) || IS_ERR(sp810->timclk)))
> +               return -ENOENT;
> +
> +       /* Select fastest parent */
> +       if (clk_get_rate(sp810->refclk) > clk_get_rate(sp810->timclk))
> +               new_parent = sp810->refclk;
> +       else
> +               new_parent = sp810->timclk;
> +
> +       /* Switch the parent if necessary */
> +       if (old_parent != new_parent) {
> +               clk_prepare(new_parent);
> +               clk_set_parent(hw->clk, new_parent);
> +               clk_unprepare(old_parent);
> +       }
> +
> +       return 0;
> +}
> +
> +static void clk_sp810_timerclken_unprepare(struct clk_hw *hw)
> +{
> +       struct clk_sp810_timerclken *timerclken = to_clk_sp810_timerclken(hw);
> +       struct clk_sp810 *sp810 = timerclken->sp810;
> +
> +       clk_put(sp810->timclk);
> +       clk_put(sp810->refclk);
> +}
> +
> +static const struct clk_ops clk_sp810_timerclken_ops = {
> +       .prepare = clk_sp810_timerclken_prepare,
> +       .unprepare = clk_sp810_timerclken_unprepare,
> +       .get_parent = clk_sp810_timerclken_get_parent,
> +       .set_parent = clk_sp810_timerclken_set_parent,
> +};
> +
> +struct clk *clk_sp810_timerclken_of_get(struct of_phandle_args *clkspec,
> +               void *data)
> +{
> +       struct clk_sp810 *sp810 = data;
> +
> +       if (WARN_ON(clkspec->args_count != 1 || clkspec->args[0] >
> +                       ARRAY_SIZE(sp810->timerclken)))
> +               return NULL;
> +
> +       return sp810->timerclken[clkspec->args[0]].clk;
> +}
> +
> +void __init clk_sp810_of_setup(struct device_node *node)
> +{
> +       struct clk_sp810 *sp810 = kzalloc(sizeof(*sp810), GFP_KERNEL);
> +       const char *parent_names[2];
> +       char name[12];
> +       struct clk_init_data init;
> +       int i;
> +
> +       if (!sp810) {
> +               pr_err("Failed to allocate memory for SP810!\n");
> +               return;
> +       }
> +
> +       sp810->refclk_index = of_property_match_string(node, "clock-names",
> +                       "refclk");
> +       parent_names[0] = of_clk_get_parent_name(node, sp810->refclk_index);
> +
> +       sp810->timclk_index = of_property_match_string(node, "clock-names",
> +                       "timclk");
> +       parent_names[1] = of_clk_get_parent_name(node, sp810->timclk_index);
> +
> +       if (parent_names[0] <= 0 || parent_names[1] <= 0) {
> +               pr_warn("Failed to obtain parent clocks for SP810!\n");
> +               return;
> +       }
> +
> +       sp810->node = node;
> +       sp810->base = of_iomap(node, 0);
> +       spin_lock_init(&sp810->lock);
> +
> +       init.name = name;
> +       init.ops = &clk_sp810_timerclken_ops;
> +       init.flags = CLK_IS_BASIC;
> +       init.parent_names = parent_names;
> +       init.num_parents = ARRAY_SIZE(parent_names);
> +
> +       for (i = 0; i < ARRAY_SIZE(sp810->timerclken); i++) {
> +               snprintf(name, ARRAY_SIZE(name), "timerclken%d", i);
> +
> +               sp810->timerclken[i].sp810 = sp810;
> +               sp810->timerclken[i].channel = i;
> +               sp810->timerclken[i].hw.init = &init;
> +
> +               sp810->timerclken[i].clk = clk_register(NULL,
> +                               &sp810->timerclken[i].hw);
> +               WARN_ON(IS_ERR(sp810->timerclken[i].clk));
> +       }
> +
> +       of_clk_add_provider(node, clk_sp810_timerclken_of_get, sp810);
> +}
> +CLK_OF_DECLARE(sp810, "arm,sp810", clk_sp810_of_setup);
> diff --git a/drivers/clk/versatile/clk-vexpress.c b/drivers/clk/versatile/clk-vexpress.c
> index 82b45aa..a4a728d 100644
> --- a/drivers/clk/versatile/clk-vexpress.c
> +++ b/drivers/clk/versatile/clk-vexpress.c
> @@ -15,8 +15,6 @@
>  #include <linux/clkdev.h>
>  #include <linux/clk-provider.h>
>  #include <linux/err.h>
> -#include <linux/of.h>
> -#include <linux/of_address.h>
>  #include <linux/vexpress.h>
>  
>  static struct clk *vexpress_sp810_timerclken[4];
> @@ -86,50 +84,3 @@ void __init vexpress_clk_init(void __iomem *sp810_base)
>         WARN_ON(clk_register_clkdev(vexpress_sp810_timerclken[1],
>                                 "v2m-timer1", "sp804"));
>  }
> -
> -#if defined(CONFIG_OF)
> -
> -struct clk *vexpress_sp810_of_get(struct of_phandle_args *clkspec, void *data)
> -{
> -       if (WARN_ON(clkspec->args_count != 1 || clkspec->args[0] >
> -                       ARRAY_SIZE(vexpress_sp810_timerclken)))
> -               return NULL;
> -
> -       return vexpress_sp810_timerclken[clkspec->args[0]];
> -}
> -
> -void __init vexpress_clk_of_init(void)
> -{
> -       struct device_node *node;
> -       struct clk *clk;
> -       struct clk *refclk, *timclk;
> -
> -       of_clk_init(NULL);
> -
> -       node = of_find_compatible_node(NULL, NULL, "arm,sp810");
> -       vexpress_sp810_init(of_iomap(node, 0));
> -       of_clk_add_provider(node, vexpress_sp810_of_get, NULL);
> -
> -       /* Select "better" (faster) parent for SP804 timers */
> -       refclk = of_clk_get_by_name(node, "refclk");
> -       timclk = of_clk_get_by_name(node, "timclk");
> -       if (!WARN_ON(IS_ERR(refclk) || IS_ERR(timclk))) {
> -               int i = 0;
> -
> -               if (clk_get_rate(refclk) > clk_get_rate(timclk))
> -                       clk = refclk;
> -               else
> -                       clk = timclk;
> -
> -               for (i = 0; i < ARRAY_SIZE(vexpress_sp810_timerclken); i++)
> -                       WARN_ON(clk_set_parent(vexpress_sp810_timerclken[i],
> -                                       clk));
> -       }
> -
> -       WARN_ON(clk_register_clkdev(vexpress_sp810_timerclken[0],
> -                               "v2m-timer0", "sp804"));
> -       WARN_ON(clk_register_clkdev(vexpress_sp810_timerclken[1],
> -                               "v2m-timer1", "sp804"));
> -}
> -
> -#endif
> -- 
> 1.7.10.4


From khilman at linaro.org  Thu Apr 18 17:34:00 2013
From: khilman at linaro.org (Kevin Hilman)
Date: Thu, 18 Apr 2013 14:34:00 -0700
Subject: [PATCH] gpio/omap: ensure gpio context is initialised
In-Reply-To: <1366230707-32681-1-git-send-email-jon-hunter@ti.com> (Jon
 Hunter's message of "Wed, 17 Apr 2013 15:31:47 -0500")
References: <1366230707-32681-1-git-send-email-jon-hunter@ti.com>
Message-ID: <871ua734mv.fsf@linaro.org>

Hi Jon,

Jon Hunter <jon-hunter at ti.com> writes:

> Commit a2797be (gpio/omap: force restore if context loss is not
> detectable) broke gpio support for OMAP when booting with device-tree
> because a restore of the gpio context being performed without ever
> initialising the gpio context. In other words, the context restored was
> bad.
>
> This problem could also occur in the non device-tree case, however, it
> is much less likely because when booting without device-tree we can
> detect context loss via a platform specific API and so context restore
> is performed less often.
>
> Nevertheless we should ensure that the gpio context is initialised
> during the probe for gpio banks that could lose their state regardless
> of whether we are booting with device-tree or not.
>
> Reported-by: Tony Lindgren <tony at atomide.com>
> Signed-off-by: Jon Hunter <jon-hunter at ti.com>
> Tested-by: Tony Lindgren <tony at atomide.com>
> ---
>  drivers/gpio/gpio-omap.c |   53 +++++++++++++++++++++++++++++++++++++---------
>  1 file changed, 43 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
> index 0557529..0ba5cb9 100644
> --- a/drivers/gpio/gpio-omap.c
> +++ b/drivers/gpio/gpio-omap.c
> @@ -70,6 +70,7 @@ struct gpio_bank {
>  	bool is_mpuio;
>  	bool dbck_flag;
>  	bool loses_context;
> +	bool context_valid;
>  	int stride;
>  	u32 width;
>  	int context_loss_count;
> @@ -1085,6 +1086,7 @@ static void omap_gpio_chip_init(struct gpio_bank *bank)
>  }
>  
>  static const struct of_device_id omap_gpio_match[];
> +static void omap_gpio_init_context(struct gpio_bank *p);
>  
>  static int omap_gpio_probe(struct platform_device *pdev)
>  {
> @@ -1179,8 +1181,10 @@ static int omap_gpio_probe(struct platform_device *pdev)
>  	omap_gpio_chip_init(bank);
>  	omap_gpio_show_rev(bank);
>  
> -	if (bank->loses_context)
> +	if (bank->loses_context) {
>  		bank->get_context_loss_count = pdata->get_context_loss_count;
> +		omap_gpio_init_context(bank);
> +	}
>  
>  	pm_runtime_put(bank->dev);
>  
> @@ -1269,6 +1273,14 @@ static int omap_gpio_runtime_resume(struct device *dev)
>  	int c;
>  
>  	spin_lock_irqsave(&bank->lock, flags);
> +
> +	/*
> +	 * On the first resume during the probe, the context has not
> +	 * been initialised and so if the context is not valid return.
> +	 */
> +	if (!bank->context_valid)
> +		goto done;

Not sure I follow the reason to separate it here and in probe.  

Also, this makes the first runtime_resume a special case and leaves
things in a strange semi-initialized state that is confusing IMO.

Why not just init context right here if bank->loses_context &&
!bank->context_valid?

Then the first resume can continue as expected, and everything is fully
initialized as expected also.  IMO, this is much more readable (and
maintainable, but that's your job now, so you can decide ;)

Kevin


From myron.stowe at gmail.com  Thu Apr 18 17:52:09 2013
From: myron.stowe at gmail.com (Myron Stowe)
Date: Thu, 18 Apr 2013 15:52:09 -0600
Subject: 2013 Linux Plumbers ACPI/PM,
 PCI Microconference proposal call for participaton
Message-ID: <CAL-B5D3mP-Eo7yzZb=ZJ_+GK5YGzKZV2p0SD05s3fXDR2BGorA@mail.gmail.com>

All:

We would like to hold a combined ACPI/PM, PCI focused microconference
as part of this year's Linux Plumbers conference but first we need to
show that there is enough interest and material that needs covered.

There is a lot of activity in these subsystems so please respond by
submitting presentation or discussion proposals that you would be
willing to cover for consideration (respond to this mail on the
linux-pci list for tracking purposes please).  You should also feel
free to submit ideas as proposals that others could cover.  This is
the "Plumbers" conference so topics concerning userspace interaction
with the kernel and not just topics concerning pure kernel subsystem
internals would be greatly welcomed.

The initial call[1] only produced two responses.  We understand that
everyone is busy but without proposals the program committee will not
be able to select this topic for approval - so please step up.


If approved by the program committee, we will give precedence to
proposals that bring up current issues that need attention, help, or
resolution.  We would like for the majority of the microconference to
be "working session discussions" in which a current issues in/with the
ACPI/PM and PCI subsystem space that needs solving are introduced and
then opened up for live discussion by attendees - much like what took
place last year during the Kernel Summit's PCI miniconf.

As a possible aid towards promoting topics for submissions we have
listed a few candidates that seem to meet the criteria in the
microconference proposals wiki located at
http://wiki.linuxplumbersconf.org/2013:pci_subsystem


Please feel free to forward this invitation on to any others, or
relevant lists, that seem appropriate.

Thanks,
  Len, Bjorn, Myron, Rafael


[1] https://lkml.org/lkml/2013/3/7/315


From arnd at arndb.de  Thu Apr 18 17:53:44 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 18 Apr 2013 23:53:44 +0200
Subject: [PATCH 24/32 v3] dmaengine: ste_dma40: Supply full Device Tree
 parsing support
In-Reply-To: <20130418141752.GC3959@gmail.com>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <20130418121253.GF27903@gmail.com> <20130418141752.GC3959@gmail.com>
Message-ID: <201304182353.45092.arnd@arndb.de>

On Thursday 18 April 2013, Lee Jones wrote:
> Using the new DMA DT bindings and API, we can register the DMA40 driver
> as Device Tree capable. Now, when a client attempts to allocate a
> channel using the DMA DT bindings via its own node, we are able to parse
> the request and allocate a channel in the correct manner.
> 
> Cc: Vinod Koul <vinod.koul at intel.com>
> Cc: Dan Williams <djbw at fb.com>
> Cc: Per Forlin <per.forlin at stericsson.com>
> Cc: Rabin Vincent <rabin at rab.in>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>
> 

Reviewed-by: Arnd Bergmann <arnd at arndb.de>


From arno at natisbad.org  Thu Apr 18 18:27:57 2013
From: arno at natisbad.org (Arnaud Ebalard)
Date: Fri, 19 Apr 2013 00:27:57 +0200
Subject: [RFC,PATCHv0 0/3] Add support for GMT G762/G763 PWM fan controller
Message-ID: <cover.1366322287.git.arno@natisbad.org>

Hi,

This series adds support for GMT G762/G763. This work is based on a
basic version for 2.6.31 kernel developed Olivier Mouchet (kept as
author for this reason in g762.c) for LaCie NAS. Updates have been
performed to run on recent kernels. Supported has been completed and
additional features added: ability to configure various characteristics
from .dts file, better initialization, alarms and error reporting
support, gear mode, polarity, fan pulse per revolution, fan startup
voltage control. The following detailed datasheet has been used as a
basis for this work:

  http://natisbad.org/NAS/refs/GMT_EDS-762_763-080710-0.2.pdf

The purpose for this v0 is to get some feedback on the mistakes I may
have made or missing things to get the patch accepted.

The patch was developed for and tested against the GMT G762 fan
controller used in a Netgear ReadyNAS Duo v2 (kirkwood 88F6282-based
NAS). This is the main reason for the device tree bindings provided in
first patch. The patches are against current ARM tree; tell me if you
need me to rebase it against something else.

Patch 2/3 provides documentation for DT bindings. Documentation for the
sysfs interface provided by the driver is available in patch 3/3.

As a side note, I found it difficult to extend g760a driver to add g762
features; hence the new g762.c file.

Comments welcome,

Cheers,

a+

Arnaud Ebalard (3):
  Add support for GMT G72/G763 PWM fan controller
  Add DT documentation for G762 PWM fan controller
  Add documentation for g762 driver

 Documentation/devicetree/bindings/hwmon/g762.txt |   37 +
 Documentation/hwmon/g762                         |   89 ++
 drivers/hwmon/Kconfig                            |   10 +
 drivers/hwmon/Makefile                           |    1 +
 drivers/hwmon/g762.c                             | 1159 ++++++++++++++++++++++
 5 files changed, 1296 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/hwmon/g762.txt
 create mode 100644 Documentation/hwmon/g762
 create mode 100644 drivers/hwmon/g762.c

-- 
1.7.10.4



From arno at natisbad.org  Thu Apr 18 18:28:21 2013
From: arno at natisbad.org (Arnaud Ebalard)
Date: Fri, 19 Apr 2013 00:28:21 +0200
Subject: [PATCH 1/3] Add support for GMT G72/G763 PWM fan controller
In-Reply-To: <cover.1366322287.git.arno@natisbad.org>
References: <cover.1366322287.git.arno@natisbad.org>
Message-ID: <4f4a821bbc61e2da28fd70553fd717ada255097d.1366322287.git.arno@natisbad.org>


Signed-off-by: Arnaud Ebalard <arno at natisbad.org>
Tested-by: Arnaud Ebalard <arno at natisbad.org>
---
 drivers/hwmon/Kconfig  |   10 +
 drivers/hwmon/Makefile |    1 +
 drivers/hwmon/g762.c   | 1159 ++++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 1170 insertions(+)
 create mode 100644 drivers/hwmon/g762.c

diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 89ac1cb..0c6ddee 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -423,6 +423,16 @@ config SENSORS_G760A
 	  This driver can also be built as a module.  If so, the module
 	  will be called g760a.
 
+config SENSORS_G762
+	tristate "GMT G762"
+	depends on I2C
+	help
+	  If you say yes here you get support for Global Mixed-mode
+	  Technology Inc G762 fan speed PWM controller chips.
+
+	  This driver can also be built as a module.  If so, the module
+	  will be called g762a.
+
 config SENSORS_GL518SM
 	tristate "Genesys Logic GL518SM"
 	depends on I2C
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index 8d6d97e..4b49504 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -57,6 +57,7 @@ obj-$(CONFIG_SENSORS_F75375S)	+= f75375s.o
 obj-$(CONFIG_SENSORS_FAM15H_POWER) += fam15h_power.o
 obj-$(CONFIG_SENSORS_FSCHMD)	+= fschmd.o
 obj-$(CONFIG_SENSORS_G760A)	+= g760a.o
+obj-$(CONFIG_SENSORS_G762)	+= g762.o
 obj-$(CONFIG_SENSORS_GL518SM)	+= gl518sm.o
 obj-$(CONFIG_SENSORS_GL520SM)	+= gl520sm.o
 obj-$(CONFIG_SENSORS_GPIO_FAN)	+= gpio-fan.o
diff --git a/drivers/hwmon/g762.c b/drivers/hwmon/g762.c
new file mode 100644
index 0000000..8c4cb39
--- /dev/null
+++ b/drivers/hwmon/g762.c
@@ -0,0 +1,1159 @@
+/*
+ * g762 - Driver for the Global Mixed-mode Technology Inc. fan speed PWM
+ *        controller chips from G762 family, i.e. G762 and G763
+ *
+ * Copyright (C) 2013, Arnaud EBALARD <arno at natisbad.org>
+ *
+ * This work is based on a basic version for 2.6.31 kernel developed
+ * by Olivier Mouchet for LaCie NAS. Updates have been performed to run
+ * on recent kernels. Supported has been completed and additional
+ * features added: ability to configure various characteristics from
+ * .dts file, better initialization, alarms and error reporting support,
+ * gear mode, polarity, fan pulse per revolution, fan startup voltage
+ * control. The following detailed datasheet has been used as a basis
+ * for this work:
+ *
+ *  http://natisbad.org/NAS/refs/GMT_EDS-762_763-080710-0.2.pdf
+ *
+ * Headers from previous developments have been kept below:
+ *
+ * Copyright (c) 2009 LaCie
+ *
+ * Author: Olivier Mouchet <olivier.mouchet at gmail.com>
+ *
+ * based on g760a code written by Herbert Valerio Riedel <hvr at gnu.org>
+ * Copyright (C) 2007  Herbert Valerio Riedel <hvr at gnu.org>
+ *
+ * g762: minimal datasheet available at:
+ *       http://www.gmt.com.tw/product/datasheet/EDS-762_3.pdf
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+
+#include <linux/device.h>
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/slab.h>
+#include <linux/jiffies.h>
+#include <linux/i2c.h>
+#include <linux/hwmon.h>
+#include <linux/hwmon-sysfs.h>
+#include <linux/err.h>
+#include <linux/mutex.h>
+#include <linux/kernel.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+
+#define DRVNAME "g762"
+
+static const struct i2c_device_id g762_id[] = {
+	{ DRVNAME, 0 },
+	{ }
+};
+MODULE_DEVICE_TABLE(i2c, g762_id);
+
+enum g762_regs {
+	G762_REG_SET_CNT  = 0x00,
+	G762_REG_ACT_CNT  = 0x01,
+	G762_REG_FAN_STA  = 0x02,
+	G762_REG_SET_OUT  = 0x03,
+	G762_REG_FAN_CMD1 = 0x04,
+	G762_REG_FAN_CMD2 = 0x05,
+};
+
+/* Config register bits */
+#define G762_REG_FAN_CMD1_DET_FAN_FAIL 	0x80 /* enable fan_fail signal */
+#define G762_REG_FAN_CMD1_DET_FAN_OOC 	0x40 /* enable fan_out_of_control */
+#define G762_REG_FAN_CMD1_OUT_MODE 	0x20 /* out mode, pwm or dac */
+#define G762_REG_FAN_CMD1_FAN_MODE 	0x10 /* fan mode: close or open loop */
+#define G762_REG_FAN_CMD1_CLK_DIV_ID1   0x08 /* clock divisor value */
+#define G762_REG_FAN_CMD1_CLK_DIV_ID0 	0x04
+#define G762_REG_FAN_CMD1_PWM_POLARITY	0x02 /* pwm polarity */
+#define G762_REG_FAN_CMD1_PULSE_PER_REV	0x01 /* pulse per fan revolution */
+
+#define G762_REG_FAN_CMD2_GEAR_MODE_1   0x08 /* fan gear mode */
+#define G762_REG_FAN_CMD2_GEAR_MODE_0   0x04
+#define G762_REG_FAN_CMD2_FAN_STARTV_1  0x02 /* fan startup voltage */
+#define G762_REG_FAN_CMD2_FAN_STARTV_0  0x01
+
+#define G762_REG_FAN_STA_FAIL           0x02 /* fan fail */
+#define G762_REG_FAN_STA_OOC            0x01 /* fan out of control */
+
+/* config register values */
+#define OUT_MODE_PWM 		1
+#define OUT_MODE_DAC 		0
+
+#define FAN_MODE_CLOSED_LOOP 	1
+#define FAN_MODE_OPEN_LOOP 	0
+
+/* g762 default values: it is assumed that the fan is set for a 32KHz clock
+ * source, a fan clock divisor of 1 and two pulses per revolution. Default
+ * fan driving mode is linear mode (g762 also supports PWM mode) */
+#define G762_DEFAULT_CLK 	    32768
+#define G762_DEFAULT_FAN_CLK_DIV    1
+#define G762_DEFAULT_PULSE_PER_REV  2
+#define G762_DEFAULT_OUT_MODE       0
+#define G762_DEFAULT_FAN_MODE       1
+
+/* register data is read (and cached) at most once per second */
+#define G762_UPDATE_INTERVAL (HZ)
+
+/* extract pulse count per fan revolution value (2 or 4) from given
+ * FAN_CMD1 register value */
+#define PULSE_FROM_REG(reg) \
+	(((reg & G762_REG_FAN_CMD1_PULSE_PER_REV)+1) << 1)
+
+/* extract fan clock divisor (1, 2, 4 or 8) from given FAN_CMD1
+ * register value */
+#define CLKDIV_FROM_REG(reg) \
+	(1 << ((reg & (G762_REG_FAN_CMD1_CLK_DIV_ID0 | \
+		       G762_REG_FAN_CMD1_CLK_DIV_ID1)) >> 2))
+
+/* extract fan gear mode value (0, 1 or 2) from given FAN_CMD2
+ * register value */
+#define GEARMODE_FROM_REG(reg) \
+	(1 << ((reg & (G762_REG_FAN_CMD2_GEAR_MODE_0 | \
+		       G762_REG_FAN_CMD2_GEAR_MODE_1)) >> 2))
+
+struct g762_data {
+	struct i2c_client *client;
+	struct device *hwmon_dev;
+
+	/* update mutex */
+	struct mutex update_lock;
+
+	/* board specific parameters. */
+	u32 clk; /* default 32kHz */
+
+	/* g762 register cache */
+	unsigned int valid:1;
+	unsigned long last_updated; /* in jiffies */
+
+	u8 set_cnt;  /* RPM cmd in close loop control */
+	u8 act_cnt;  /* formula: cnt = (CLK * 30)/(rpm * P) */
+	u8 fan_sta;  /* bit 0: set when actual fan speed is more than
+		      *        25% outside requested fan speed
+		      * bit 1: set when no transition occurs on fan
+                      *        pin for 0.7s */
+	u8 set_out;  /* output voltage/PWM duty in open loop control */
+	u8 fan_cmd1; /*   0: FG_PLS_ID0 FG pulses count per revolution
+		      *      0: 2 counts per revolution
+		      *      1: 4 counts per revolution
+		      *   1: PWM_POLARITY 1: negative_duty
+		      *                   0: positive_duty
+		      * 2,3: [FG_CLOCK_ID0, FG_CLK_ID1]
+		      * 	00: Divide fan clock by 1
+		      * 	01: Divide fan clock by 2
+		      * 	10: Divide fan clock by 4
+		      * 	11: Divide fan clock by 8
+		      *   4: FAN_MODE 1:close-loop, 0:open-loop
+		      *   5: OUT_MODE 1:PWM, 0:DAC
+		      *   6: DET_FAN_OOC enable "fan ooc" status
+		      *   7: DET_FAN_FAIL enable "fan fail" status */
+	u8 fan_cmd2; /* 0,1: FAN_STARTV 0,1,2,3 -> 0,32,64,96 dac_code
+		      * 2,3: FG_GEAR_MODE
+		      *         00: div = 1
+		      *         01: div = 2
+		      *         10: div = 4
+		      *   4: Mask ALERT# (g763 only) */
+};
+
+/* sysfs PWM interface uses value from 0 to 255 when g762 FAN_SET_CNT register
+ * uses values from 255 (off) to 0 (full speed). */
+#define PWM_FROM_CNT(cnt)	(0xff-(cnt))
+#define PWM_TO_CNT(pwm)		(0xff-(pwm))
+
+/* Convert count value from fan controller register into fan speed RPM value.
+ * Note that the datasheet documents a basic formula. Influence of additional
+ * parameters have been infered from examples in the datasheet and tests:
+ * fan clock divisor, fan gear mode. */
+static inline unsigned int rpm_from_cnt(u8 cnt,	u32 clk, u16 p,
+					u8 clk_div, u8 gear_mode)
+{
+	if (cnt == 0 || cnt == 0xff)
+		return 0;
+
+	return (clk*30*(gear_mode+1))/(cnt*p*clk_div);
+}
+
+/* Convert fan RPM value from sysfs into count value */
+static inline unsigned char cnt_from_rpm(u32 rpm, u32 clk, u16 p,
+					 u8 clk_div, u8 gear_mode)
+{
+	return (rpm == 0) ? 0xff : (clk*30*(gear_mode+1))/(rpm*p*clk_div);
+}
+
+#ifdef CONFIG_OF
+static struct of_device_id g762_dt_match[] = {
+	{ .compatible = "gmt,g762" },
+	{ .compatible = "gmt,g763" },
+	{ },
+};
+#endif
+
+static int g762_probe(struct i2c_client *client,
+		      const struct i2c_device_id *id);
+static int g762_remove(struct i2c_client *client);
+
+static struct i2c_driver g762_driver = {
+	.driver = {
+		.name = DRVNAME,
+		.owner = THIS_MODULE,
+		.of_match_table = of_match_ptr(g762_dt_match),
+	},
+	.probe	  = g762_probe,
+	.remove	  = g762_remove,
+	.id_table = g762_id,
+};
+
+static inline int g762_read_value(struct i2c_client *client,
+				  enum g762_regs reg)
+{
+	return i2c_smbus_read_byte_data(client, reg);
+}
+
+static inline int g762_write_value(struct i2c_client *client,
+				   enum g762_regs reg, u16 value)
+{
+	return i2c_smbus_write_byte_data(client, reg, value);
+}
+
+/*
+ * sysfs attributes
+ */
+
+/* helper to grab and cache data, at most one time per second */
+static struct g762_data *g762_update_client(struct device *dev)
+{
+	struct i2c_client *client = to_i2c_client(dev);
+	struct g762_data *data = i2c_get_clientdata(client);
+
+	mutex_lock(&data->update_lock);
+	if (time_after(jiffies, data->last_updated + G762_UPDATE_INTERVAL) ||
+	    unlikely(!data->valid)) {
+		data->set_cnt =  g762_read_value(client, G762_REG_SET_CNT);
+		data->act_cnt =  g762_read_value(client, G762_REG_ACT_CNT);
+		data->fan_sta =  g762_read_value(client, G762_REG_FAN_STA);
+		data->set_out =  g762_read_value(client, G762_REG_SET_OUT);
+		data->fan_cmd1 = g762_read_value(client, G762_REG_FAN_CMD1);
+		data->fan_cmd2 = g762_read_value(client, G762_REG_FAN_CMD2);
+
+		data->last_updated = jiffies;
+		data->valid = 1;
+	}
+	mutex_unlock(&data->update_lock);
+
+	return data;
+}
+
+/* Read function for fan1_input sysfs file. Return current fan RPM value, or
+ * 0 if fan is out of control */
+static ssize_t get_fan_rpm(struct device *dev, struct device_attribute *da,
+			   char *buf)
+{
+	struct g762_data *data = g762_update_client(dev);
+	unsigned int rpm = 0;
+
+	mutex_lock(&data->update_lock);
+	/* reverse logic: fan out of control reporting is enabled low */
+	if (data->fan_sta & G762_REG_FAN_STA_OOC) {
+		rpm = rpm_from_cnt(data->act_cnt, data->clk,
+				   PULSE_FROM_REG(data->fan_cmd1),
+				   CLKDIV_FROM_REG(data->fan_cmd1),
+				   GEARMODE_FROM_REG(data->fan_cmd2));
+	}
+	mutex_unlock(&data->update_lock);
+
+	return sprintf(buf, "%u\n", rpm);
+}
+
+/* Read function for pwm1_mode sysfs file. Get fan speed control
+ * mode i.e. pwm (1) or linear (0) */
+static ssize_t get_pwm_mode(struct device *dev, struct device_attribute *da,
+			    char *buf)
+{
+	struct g762_data *data = g762_update_client(dev);
+	int pwm_mode;
+
+	pwm_mode = (data->fan_cmd1 & G762_REG_FAN_CMD1_OUT_MODE) ? 1 : 0;
+
+	return sprintf(buf, "%d\n", pwm_mode);
+}
+
+static ssize_t do_set_pwm_mode(struct device *dev, u8 val)
+{
+	struct i2c_client *client = to_i2c_client(dev);
+	struct g762_data *data = g762_update_client(dev);
+
+	mutex_lock(&data->update_lock);
+	switch (val) {
+	case OUT_MODE_PWM:
+		data->fan_cmd1 |= G762_REG_FAN_CMD1_OUT_MODE;
+		break;
+	case OUT_MODE_DAC: /* i.e. linear */
+		data->fan_cmd1 &= (u8) ~G762_REG_FAN_CMD1_OUT_MODE;
+		break;
+	default:
+		mutex_unlock(&data->update_lock);
+		return -EINVAL;
+	}
+	g762_write_value(client, G762_REG_FAN_CMD1, data->fan_cmd1);
+	mutex_unlock(&data->update_lock);
+
+	return val;
+}
+
+/* Write function for pwm1_mode sysfs file. Set fan speed control
+ * mode as pwm (1) or linear (0) */
+static ssize_t set_pwm_mode(struct device *dev, struct device_attribute *da,
+			    const char *buf, size_t count)
+{
+	unsigned long val;
+	ssize_t ret;
+
+	if (kstrtoul(buf, 10, &val))
+		return -EINVAL;
+
+	ret = do_set_pwm_mode(dev, (u8)val);
+	if (ret < 0)
+		return -EINVAL;
+
+	return count;
+}
+
+/* Read function for pwm1_freq sysfs file. */
+static ssize_t get_pwm_freq(struct device *dev,
+			    struct device_attribute *da, char *buf)
+{
+	struct i2c_client *client = to_i2c_client(dev);
+	struct g762_data *data = i2c_get_clientdata(client);
+
+	return sprintf(buf, "%d\n", data->clk);
+}
+
+/* Write function for pwm1_freq sysfs file. */
+static ssize_t set_pwm_freq(struct device *dev,
+			    struct device_attribute *da,
+			    const char *buf, size_t count)
+{
+	struct i2c_client *client = to_i2c_client(dev);
+	struct g762_data *data = i2c_get_clientdata(client);
+	unsigned long val;
+
+	if (kstrtoul(buf, 10, &val) || !val)
+		return -EINVAL;
+
+	mutex_lock(&data->update_lock);
+	data->clk = val;
+	mutex_unlock(&data->update_lock);
+
+	return count;
+}
+
+/* Read function for fan1_div sysfs file. Get fan controller prescaler */
+static ssize_t get_fan_clk_div(struct device *dev,
+			       struct device_attribute *da, char *buf)
+{
+	struct g762_data *data = g762_update_client(dev);
+
+	return sprintf(buf, "%d\n", CLKDIV_FROM_REG(data->fan_cmd1));
+}
+
+static ssize_t do_set_fan_clk_div(struct device *dev, u8 val)
+{
+	struct i2c_client *client = to_i2c_client(dev);
+	struct g762_data *data = g762_update_client(dev);
+
+	mutex_lock(&data->update_lock);
+	switch (val) {
+	case 1:
+		data->fan_cmd1 &= (u8) ~G762_REG_FAN_CMD1_CLK_DIV_ID0;
+		data->fan_cmd1 &= (u8) ~G762_REG_FAN_CMD1_CLK_DIV_ID1;
+		break;
+	case 2:
+		data->fan_cmd1 |= G762_REG_FAN_CMD1_CLK_DIV_ID0;
+		data->fan_cmd1 &= (u8) ~G762_REG_FAN_CMD1_CLK_DIV_ID1;
+		break;
+	case 4:
+		data->fan_cmd1 &= (u8) ~G762_REG_FAN_CMD1_CLK_DIV_ID0;
+		data->fan_cmd1 |= G762_REG_FAN_CMD1_CLK_DIV_ID1;
+		break;
+	case 8:
+		data->fan_cmd1 |= G762_REG_FAN_CMD1_CLK_DIV_ID0;
+		data->fan_cmd1 |= G762_REG_FAN_CMD1_CLK_DIV_ID1;
+		break;
+	default:
+		mutex_unlock(&data->update_lock);
+		return -EINVAL;
+	}
+	g762_write_value(client, G762_REG_FAN_CMD1, (u16)data->fan_cmd1);
+	mutex_unlock(&data->update_lock);
+
+	return val;
+}
+
+/* Write function for fan1_div file. Set fan controller prescaler */
+static ssize_t set_fan_clk_div(struct device *dev,
+			       struct device_attribute *da,
+			       const char *buf, size_t count)
+{
+	unsigned long val;
+	ssize_t ret;
+
+	if (kstrtoul(buf, 10, &val))
+		return -EINVAL;
+
+	ret = do_set_fan_clk_div(dev, (u8) val);
+	if (ret < 0)
+		return -EINVAL;
+
+	return count;
+}
+
+/* Read function for fan1_gear_mode sysfs file. Get fan gear mode */
+static ssize_t get_fan_gear_mode(struct device *dev,
+				 struct device_attribute *da, char *buf)
+{
+	struct g762_data *data = g762_update_client(dev);
+	u8 fan_gear_mode;
+
+	fan_gear_mode = data->fan_cmd2 & (G762_REG_FAN_CMD2_GEAR_MODE_0 |
+					  G762_REG_FAN_CMD2_GEAR_MODE_1);
+	fan_gear_mode = fan_gear_mode >> 2;
+
+	return sprintf(buf, "%d\n", fan_gear_mode);
+}
+
+static ssize_t do_set_fan_gear_mode(struct device *dev, u8 val)
+{
+	struct i2c_client *client = to_i2c_client(dev);
+	struct g762_data *data = g762_update_client(dev);
+
+	mutex_lock(&data->update_lock);
+	switch (val) {
+	case 0:
+		data->fan_cmd2 &= (u8) ~G762_REG_FAN_CMD2_GEAR_MODE_0;
+		data->fan_cmd2 &= (u8) ~G762_REG_FAN_CMD2_GEAR_MODE_1;
+		break;
+	case 1:
+		data->fan_cmd2 |= G762_REG_FAN_CMD2_GEAR_MODE_0;
+		data->fan_cmd2 &= (u8) ~G762_REG_FAN_CMD2_GEAR_MODE_1;
+		break;
+	case 2:
+		data->fan_cmd2 &= (u8) ~G762_REG_FAN_CMD2_GEAR_MODE_0;
+		data->fan_cmd2 |= G762_REG_FAN_CMD2_GEAR_MODE_1;
+		break;
+	default:
+		mutex_unlock(&data->update_lock);
+		return -EINVAL;
+	}
+	g762_write_value(client, G762_REG_FAN_CMD2, (u16)data->fan_cmd2);
+	mutex_unlock(&data->update_lock);
+
+	return val;
+}
+
+/* Write function for fan1_gear_mode sysfs file. Write fan gear mode */
+static ssize_t set_fan_gear_mode(struct device *dev,
+				 struct device_attribute *da,
+				 const char *buf, size_t count)
+{
+	unsigned long val;
+	ssize_t ret;
+
+	if (kstrtoul(buf, 10, &val))
+		return -EINVAL;
+
+	ret = do_set_fan_gear_mode(dev, (u8) val);
+	if (ret < 0)
+		return -EINVAL;
+
+	return count;
+}
+
+/* Read function for fan1_pulses. Returns either 2 or 4 */
+static ssize_t get_fan_pulses(struct device *dev, struct device_attribute *da,
+			      char *buf)
+{
+	struct g762_data *data = g762_update_client(dev);
+
+	return sprintf(buf, "%d\n", PULSE_FROM_REG(data->fan_cmd1));
+}
+
+/* Set pulse per revolution value. Accepts either 2 or 4. */
+static ssize_t do_set_fan_pulses(struct device *dev, u8 val)
+{
+	struct i2c_client *client = to_i2c_client(dev);
+	struct g762_data *data = g762_update_client(dev);
+
+	mutex_lock(&data->update_lock);
+	switch (val) {
+	case 2:
+		data->fan_cmd1 &= (u8) ~G762_REG_FAN_CMD1_PULSE_PER_REV;
+		break;
+	case 4:
+		data->fan_cmd1 |= G762_REG_FAN_CMD1_PULSE_PER_REV;
+		break;
+	default:
+		mutex_unlock(&data->update_lock);
+		return -EINVAL;
+	}
+	g762_write_value(client, G762_REG_FAN_CMD1, (u16)data->fan_cmd1);
+	mutex_unlock(&data->update_lock);
+
+	return val;
+}
+
+/* Write function for fan1_pulses. Accepts either 2 or 4 */
+static ssize_t set_fan_pulses(struct device *dev, struct device_attribute *da,
+			      const char *buf, size_t count)
+{
+	unsigned long val;
+	ssize_t ret;
+
+	if (kstrtoul(buf, 10, &val) || (val != 2 && val != 4))
+		return -EINVAL;
+
+	ret = do_set_fan_pulses(dev, (u8) val);
+	if (ret < 0)
+		return -EINVAL;
+
+	return count;
+}
+
+/* Following documentation about hwmon's sysfs interface, a pwm1_enable node
+ * should accept followings:
+ *
+ *  0 : no fan speed control (i.e. fan at full speed)
+ *  1 : manual fan speed control enabled (use pwm[1-*]) (open-loop)
+ *  2+: automatic fan speed control enabled (use fan[1-*]_enable)(close-loop)
+ *
+ * but we do not accept 0 as "no-control" mode is not supported by g762,
+ * -EINVAL is returned in this case. */
+static ssize_t get_speed_control_mode(struct device *dev,
+				      struct device_attribute *da, char *buf)
+{
+	struct g762_data *data = g762_update_client(dev);
+	int fan_mode;
+
+	fan_mode = (data->fan_cmd1 & G762_REG_FAN_CMD1_FAN_MODE) ? 2 : 1;
+
+	return sprintf(buf, "%d\n", fan_mode);
+}
+
+static ssize_t do_set_speed_control_mode(struct device *dev, u8 val)
+{
+	struct i2c_client *client = to_i2c_client(dev);
+	struct g762_data *data = g762_update_client(dev);
+
+	if (!val)
+		return -EINVAL;
+	val -= 1;
+
+	mutex_lock(&data->update_lock);
+	switch (val) {
+	case FAN_MODE_CLOSED_LOOP:
+		data->fan_cmd1 |= G762_REG_FAN_CMD1_FAN_MODE;
+		break;
+	case FAN_MODE_OPEN_LOOP:
+		data->fan_cmd1 &= (u8) ~G762_REG_FAN_CMD1_FAN_MODE;
+		break;
+	default:
+		mutex_unlock(&data->update_lock);
+		return -EINVAL;
+	}
+
+	g762_write_value(client, G762_REG_FAN_CMD1, data->fan_cmd1);
+	mutex_unlock(&data->update_lock);
+
+	return val;
+}
+
+static ssize_t set_speed_control_mode(struct device *dev,
+				      struct device_attribute *da,
+				      const char *buf, size_t count)
+{
+	unsigned long val;
+	ssize_t ret;
+
+	if (kstrtoul(buf, 10, &val))
+		return -EINVAL;
+
+	ret = do_set_speed_control_mode(dev, val);
+	if (ret < 0)
+		return -EINVAL;
+
+	return count;
+}
+
+/* Read function for pwm1_polarity (0: negative duty, 1: positive duty) */
+static ssize_t get_pwm_polarity(struct device *dev, struct device_attribute *da,
+		       char *buf)
+{
+	struct g762_data *data = g762_update_client(dev);
+	u8 pwm_polarity;
+
+	pwm_polarity = (data->fan_cmd1 & G762_REG_FAN_CMD1_PWM_POLARITY) >> 1;
+
+	return sprintf(buf, "%d\n", pwm_polarity);
+}
+
+/* Write function for pwm1_polarity (0: negative duty, 1: positive duty) */
+static ssize_t set_pwm_polarity(struct device *dev, struct device_attribute *da,
+		       const char *buf, size_t count)
+{
+	struct i2c_client *client = to_i2c_client(dev);
+	struct g762_data *data = g762_update_client(dev);
+	unsigned long val;
+
+	if (kstrtoul(buf, 10, &val))
+		return -EINVAL;
+
+	mutex_lock(&data->update_lock);
+	switch (val) {
+	case 0: /* i.e. negative duty */
+		data->fan_cmd1 &= (u8) ~G762_REG_FAN_CMD1_PWM_POLARITY;
+		break;
+	case 1: /* i.e. positive duty */
+		data->fan_cmd1 |= G762_REG_FAN_CMD1_PWM_POLARITY;
+		break;
+	default:
+		mutex_unlock(&data->update_lock);
+		return -EINVAL;
+	}
+	g762_write_value(client, G762_REG_FAN_CMD1, data->fan_cmd1);
+	mutex_unlock(&data->update_lock);
+
+	return count;
+}
+
+/* Get/set the fan speed in open-loop mode using pwm1 sysfs file. Speed is
+ * given as a relative value from 0 to 255, where 255 is maximum speed. Note
+ * that this is done by writing directly to the chip's DAC, it won't change
+ * the closed loop speed set by fan1_target. Also note that due to rounding
+ * errors it is possible that you don't read back exactly the value you have
+ * set. */
+static ssize_t get_pwm(struct device *dev, struct device_attribute *da,
+		       char *buf)
+{
+	struct g762_data *data = g762_update_client(dev);
+	int val;
+
+	mutex_lock(&data->update_lock);
+	if (data->fan_cmd1 & G762_REG_FAN_CMD1_FAN_MODE) { /* closed-loop */
+		val = PWM_FROM_CNT(data->set_cnt);
+	} else {                                            /* open-loop */
+		val = data->set_out;
+	}
+	mutex_unlock(&data->update_lock);
+
+	return sprintf(buf, "%d\n", val);
+}
+
+static ssize_t do_set_pwm(struct device *dev, u8 val)
+{
+	struct i2c_client *client = to_i2c_client(dev);
+	struct g762_data *data = g762_update_client(dev);
+
+	mutex_lock(&data->update_lock);
+	if (data->fan_cmd1 & G762_REG_FAN_CMD1_FAN_MODE) { /* closed-loop */
+		val = PWM_TO_CNT(clamp_val(val, 0, 255));
+		data->set_cnt = val;
+		g762_write_value(client, G762_REG_SET_CNT, val);
+	} else {                                           /* open-loop */
+		data->set_out = val;
+		g762_write_value(client, G762_REG_SET_OUT, val);
+	}
+	mutex_unlock(&data->update_lock);
+
+	return val;
+}
+
+static ssize_t set_pwm(struct device *dev, struct device_attribute *da,
+		       const char *buf, size_t count)
+{
+	unsigned long val;
+	ssize_t ret;
+
+	if (kstrtoul(buf, 10, &val))
+		return -EINVAL;
+
+	ret = do_set_pwm(dev, (u8)val);
+	if (ret < 0)
+		return -EINVAL;
+
+	return count;
+}
+
+/* Get/set the fan speed in closed-loop mode using fan1_target sysfs file. Speed
+ * is given as a rpm value, then G762 will automatically regulate the fan speed
+ * using pulses from fan tachometer.
+ *
+ * Refer to rpm_from_cnt implementation to get info about count number
+ * calculation.
+ *
+ * Also note that due to rounding errors it is possible that you don't read
+ * back exactly the value you have set. */
+static ssize_t get_fan_target(struct device *dev, struct device_attribute *da,
+			      char *buf)
+{
+	struct g762_data *data = g762_update_client(dev);
+	unsigned int rpm;
+	ssize_t err;
+
+	mutex_lock(&data->update_lock);
+	if (data->fan_cmd1 & G762_REG_FAN_CMD1_FAN_MODE) { /* closed-loop */
+		rpm = rpm_from_cnt(data->set_cnt, data->clk,
+				   PULSE_FROM_REG(data->fan_cmd1),
+				   CLKDIV_FROM_REG(data->fan_cmd1),
+				   GEARMODE_FROM_REG(data->fan_cmd2));
+		err = sprintf(buf, "%u\n", rpm);
+	} else {                                           /* open-loop */
+		err = -EINVAL;
+	}
+	mutex_unlock(&data->update_lock);
+
+	return err;
+}
+
+static ssize_t do_set_fan_target(struct device *dev, unsigned int val)
+{
+	struct i2c_client *client = to_i2c_client(dev);
+	struct g762_data *data = g762_update_client(dev);
+	ssize_t err;
+
+	mutex_lock(&data->update_lock);
+	if (data->fan_cmd1 & G762_REG_FAN_CMD1_FAN_MODE) { /* closed-loop */
+		data->set_cnt = cnt_from_rpm(val, data->clk,
+					     PULSE_FROM_REG(data->fan_cmd1),
+					     CLKDIV_FROM_REG(data->fan_cmd1),
+					     GEARMODE_FROM_REG(data->fan_cmd2));
+		g762_write_value(client, G762_REG_SET_CNT, data->set_cnt);
+		err = val;
+	} else {
+		err = -EINVAL;
+	}
+	mutex_unlock(&data->update_lock);
+
+	return err;
+}
+
+static ssize_t set_fan_target(struct device *dev, struct device_attribute *da,
+			      const char *buf, size_t count)
+{
+	unsigned int val;
+	ssize_t ret;
+
+	if (sscanf(buf, "%u", &val) != 1)
+		return -EINVAL;
+
+	ret = do_set_fan_target(dev, val);
+	if (ret < 0)
+		return -EINVAL;
+
+	return count;
+}
+
+/* read function for 'fan1_fault_detection' sysfs file */
+static ssize_t get_fan_failure_detection(struct device *dev,
+					 struct device_attribute *da,
+					 char *buf)
+{
+	struct g762_data *data = g762_update_client(dev);
+	unsigned int enabled;
+
+	enabled = (data->fan_cmd1 & G762_REG_FAN_CMD1_DET_FAN_FAIL) ? 1 : 0;
+
+	return sprintf(buf, "%u\n", enabled);
+}
+
+/* enable (or disable) fan failure detection */
+static ssize_t do_fan_failure_detection_toggle(struct device *dev,
+					    unsigned int enable)
+{
+	struct i2c_client *client = to_i2c_client(dev);
+	struct g762_data *data = g762_update_client(dev);
+
+	mutex_lock(&data->update_lock);
+	switch (enable) {
+	case 0:
+		data->fan_cmd1 &= (u8) ~G762_REG_FAN_CMD1_DET_FAN_FAIL;
+		break;
+	case 1:
+		data->fan_cmd1 |= G762_REG_FAN_CMD1_DET_FAN_FAIL;
+		break;
+	default:
+		mutex_unlock(&data->update_lock);
+		return -EINVAL;
+	}
+	g762_write_value(client, G762_REG_FAN_CMD1, data->fan_cmd1);
+	mutex_unlock(&data->update_lock);
+
+	return enable;
+}
+
+/* write function for 'fan1_fault_detection' sysfs file */
+static ssize_t set_fan_failure_detection(struct device *dev,
+					 struct device_attribute *da,
+					 const char *buf, size_t count)
+{
+	unsigned int val;
+	ssize_t ret;
+
+	if (sscanf(buf, "%u", &val) != 1)
+		return -EINVAL;
+
+	ret = do_fan_failure_detection_toggle(dev, val);
+	if (ret < 0)
+		return -EINVAL;
+
+	return count;
+}
+
+/* read function for fan1_fault sysfs file. */
+static ssize_t get_fan_failure(struct device *dev, struct device_attribute *da,
+			       char *buf)
+{
+	struct g762_data *data = g762_update_client(dev);
+	unsigned int val;
+
+	val = (data->fan_sta & G762_REG_FAN_STA_FAIL) ? 1 : 0;
+
+	return sprintf(buf, "%u\n", val);
+}
+
+/* read function for 'fan1_alarm_detection' sysfs file */
+static ssize_t get_fan_ooc_detection(struct device *dev,
+				     struct device_attribute *da,
+				     char *buf)
+{
+	struct g762_data *data = g762_update_client(dev);
+	unsigned int enabled;
+
+	enabled = (data->fan_cmd1 & G762_REG_FAN_CMD1_DET_FAN_FAIL) ? 1 : 0;
+
+	return sprintf(buf, "%u\n", enabled);
+}
+
+/* enable (or disable) fan out of control detection */
+static ssize_t do_fan_ooc_detection_toggle(struct device *dev,
+					   unsigned int enable)
+{
+	struct i2c_client *client = to_i2c_client(dev);
+	struct g762_data *data = g762_update_client(dev);
+
+	mutex_lock(&data->update_lock);
+	switch (enable) {
+	case 0:
+		data->fan_cmd1 &= (u8) ~G762_REG_FAN_CMD1_DET_FAN_OOC;
+		break;
+	case 1:
+		data->fan_cmd1 |= G762_REG_FAN_CMD1_DET_FAN_OOC;
+		break;
+	default:
+		mutex_unlock(&data->update_lock);
+		return -EINVAL;
+	}
+	g762_write_value(client, G762_REG_FAN_CMD1, data->fan_cmd1);
+	mutex_unlock(&data->update_lock);
+
+	return enable;
+}
+
+/* write function for 'fan1_alarm_detection' sysfs file */
+static ssize_t set_fan_ooc_detection(struct device *dev,
+				     struct device_attribute *da,
+				     const char *buf, size_t count)
+{
+	unsigned int val;
+	ssize_t ret;
+
+	if (sscanf(buf, "%u", &val) != 1)
+		return -EINVAL;
+
+	ret = do_fan_ooc_detection_toggle(dev, val);
+	if (ret < 0)
+		return -EINVAL;
+
+	return count;
+}
+
+/* read function for fan1_alarm sysfs file. */
+static ssize_t get_fan_ooc(struct device *dev, struct device_attribute *da,
+			   char *buf)
+{
+	struct g762_data *data = g762_update_client(dev);
+	unsigned int val;
+
+	/* ooc condition is enabled low */
+	val = (data->fan_sta & G762_REG_FAN_STA_OOC) ? 0 : 1;
+
+	return sprintf(buf, "%u\n", val);
+}
+
+/* Read function for fan1_startup_voltage */
+static ssize_t get_fan_startup_voltage(struct device *dev,
+				       struct device_attribute *da,
+				       char *buf)
+{
+	struct g762_data *data = g762_update_client(dev);
+	u8 val;
+
+	val = data->fan_cmd2 & (G762_REG_FAN_CMD2_FAN_STARTV_1 |
+				G762_REG_FAN_CMD2_FAN_STARTV_0);
+
+	return sprintf(buf, "%d\n", val);
+}
+
+/* Write function for fan1_startup_voltage */
+static ssize_t set_fan_startup_voltage(struct device *dev,
+				       struct device_attribute *da,
+				       const char *buf, size_t count)
+{
+	struct i2c_client *client = to_i2c_client(dev);
+	struct g762_data *data = g762_update_client(dev);
+	unsigned long val;
+
+	if (kstrtoul(buf, 10, &val))
+		return -EINVAL;
+
+	mutex_lock(&data->update_lock);
+	switch (val) {
+	case 0:
+		data->fan_cmd2 &= (u8) ~G762_REG_FAN_CMD2_FAN_STARTV_0;
+		data->fan_cmd2 &= (u8) ~G762_REG_FAN_CMD2_FAN_STARTV_1;
+		break;
+	case 1:
+		data->fan_cmd2 |= G762_REG_FAN_CMD2_FAN_STARTV_0;
+		data->fan_cmd2 &= (u8) ~G762_REG_FAN_CMD2_FAN_STARTV_1;
+		break;
+	case 2:
+		data->fan_cmd2 &= (u8) ~G762_REG_FAN_CMD2_FAN_STARTV_0;
+		data->fan_cmd2 |= G762_REG_FAN_CMD2_FAN_STARTV_1;
+		break;
+	case 3:
+		data->fan_cmd2 |= G762_REG_FAN_CMD2_FAN_STARTV_0;
+		data->fan_cmd2 |= G762_REG_FAN_CMD2_FAN_STARTV_1;
+		break;
+	default:
+		mutex_unlock(&data->update_lock);
+		return -EINVAL;
+	}
+	g762_write_value(client, G762_REG_FAN_CMD2, (u16)data->fan_cmd2);
+	mutex_unlock(&data->update_lock);
+
+	return count;
+}
+
+static DEVICE_ATTR(pwm1, S_IWUSR | S_IRUGO, get_pwm, set_pwm);
+static DEVICE_ATTR(pwm1_polarity, S_IWUSR | S_IRUGO,
+		   get_pwm_polarity, set_pwm_polarity);
+static DEVICE_ATTR(pwm1_mode, S_IWUSR | S_IRUGO,
+		   get_pwm_mode, set_pwm_mode);
+static DEVICE_ATTR(pwm1_enable, S_IWUSR | S_IRUGO,
+		   get_speed_control_mode, set_speed_control_mode);
+static DEVICE_ATTR(pwm1_freq, S_IWUSR | S_IRUGO,
+		   get_pwm_freq, set_pwm_freq);
+
+static DEVICE_ATTR(fan1_input, S_IRUGO, get_fan_rpm, NULL);
+static DEVICE_ATTR(fan1_alarm, S_IRUGO, get_fan_ooc, NULL);
+static DEVICE_ATTR(fan1_alarm_detection, S_IWUSR | S_IRUGO,
+		   get_fan_ooc_detection, set_fan_ooc_detection);
+static DEVICE_ATTR(fan1_fault, S_IRUGO, get_fan_failure, NULL);
+static DEVICE_ATTR(fan1_fault_detection, S_IWUSR | S_IRUGO,
+		   get_fan_failure_detection, set_fan_failure_detection);
+static DEVICE_ATTR(fan1_target, S_IWUSR | S_IRUGO,
+		   get_fan_target, set_fan_target);
+static DEVICE_ATTR(fan1_pulses, S_IWUSR | S_IRUGO,
+		   get_fan_pulses, set_fan_pulses);
+static DEVICE_ATTR(fan1_div, S_IWUSR | S_IRUGO,
+		   get_fan_clk_div, set_fan_clk_div);
+static DEVICE_ATTR(fan1_gear_mode, S_IWUSR | S_IRUGO,
+		   get_fan_gear_mode, set_fan_gear_mode);
+static DEVICE_ATTR(fan1_startup_voltage, S_IWUSR | S_IRUGO,
+		   get_fan_startup_voltage, set_fan_startup_voltage);
+
+/* Driver data */
+static struct attribute *g762_attributes[] = {
+	&dev_attr_fan1_input.attr,
+	&dev_attr_fan1_alarm.attr,
+	&dev_attr_fan1_alarm_detection.attr,
+	&dev_attr_fan1_fault.attr,
+	&dev_attr_fan1_fault_detection.attr,
+	&dev_attr_fan1_target.attr,
+	&dev_attr_fan1_pulses.attr,
+	&dev_attr_fan1_div.attr,
+	&dev_attr_fan1_gear_mode.attr,
+	&dev_attr_fan1_startup_voltage.attr,
+	&dev_attr_pwm1.attr,
+	&dev_attr_pwm1_polarity.attr,
+	&dev_attr_pwm1_mode.attr,
+	&dev_attr_pwm1_enable.attr,
+	&dev_attr_pwm1_freq.attr,
+	NULL
+};
+
+static const struct attribute_group g762_group = {
+	.attrs = g762_attributes,
+};
+
+static int g762_probe(struct i2c_client *client, const struct i2c_device_id *id)
+{
+	u32 pwm_freq, fan_clk_div, fan_pulses, pwm_mode, fan_target, pwm_enable;
+	struct g762_data *data;
+	int err;
+
+	if (!i2c_check_functionality(client->adapter, I2C_FUNC_SMBUS_BYTE_DATA))
+		return -ENODEV;
+
+	data = devm_kzalloc(&client->dev, sizeof(struct g762_data), GFP_KERNEL);
+	if (!data)
+		return -ENOMEM;
+	i2c_set_clientdata(client, data);
+
+	data->client = client;
+	mutex_init(&data->update_lock);
+
+	/* Setup default configuration for now. Those may get modified below
+	 * in CONFIG_OF-protected block (via .dts file). Final values will
+	 * then be pushed to the device */
+	pwm_freq = G762_DEFAULT_CLK;
+	fan_clk_div = G762_DEFAULT_FAN_CLK_DIV;
+	fan_pulses = G762_DEFAULT_PULSE_PER_REV;
+	pwm_mode = G762_DEFAULT_OUT_MODE;
+	pwm_enable = G762_DEFAULT_FAN_MODE + 1; /* shift w/ sysfs interface */
+	fan_target = 0xffffffff; /* dummy value */
+
+	/* Enable fan protection and fan fail detection by default */
+	do_fan_ooc_detection_toggle(&client->dev, 1);
+	do_fan_failure_detection_toggle(&client->dev, 1);
+
+#ifdef CONFIG_OF
+	if (client->dev.of_node) {
+		const __be32 *prop;
+		int len;
+
+		prop = of_get_property(client->dev.of_node, "pwm_freq", &len);
+		if (prop && len == sizeof(u32)) {
+			pwm_freq = be32_to_cpu(prop[0]);
+			dev_info(&client->dev, "found pwm_freq (%d)\n", pwm_freq);
+		}
+
+		prop = of_get_property(client->dev.of_node, "fan_div", &len);
+		if (prop && len == sizeof(u32)) {
+			fan_clk_div = be32_to_cpu(prop[0]);
+			dev_info(&client->dev, "found fan_div (%d)\n",
+				 fan_clk_div);
+		}
+
+		prop = of_get_property(client->dev.of_node, "fan_pulses", &len);
+		if (prop && len == sizeof(u32)) {
+			fan_pulses = be32_to_cpu(prop[0]);
+			dev_info(&client->dev, "found fan_pulses (%d)\n",
+				 fan_pulses);
+		}
+
+		prop = of_get_property(client->dev.of_node, "pwm_mode", &len);
+		if (prop && len == sizeof(u32)) {
+			pwm_mode = be32_to_cpu(prop[0]);
+			dev_info(&client->dev, "found pwm_mode (%d)\n",
+				 pwm_mode);
+		}
+
+		prop = of_get_property(client->dev.of_node, "fan_target", &len);
+		if (prop && len == sizeof(u32)) {
+			fan_target = be32_to_cpu(prop[0]);
+			dev_info(&client->dev, "found fan_target (%d)\n",
+				 fan_target);
+		}
+
+		prop = of_get_property(client->dev.of_node, "pwm_enable", &len);
+		if (prop && len == sizeof(u32)) {
+			pwm_enable = be32_to_cpu(prop[0]);
+			dev_info(&client->dev, "found pwm_enable (%d)\n",
+				 pwm_enable);
+		}
+	}
+#endif
+
+	/* Now, let's set final fan out mode (pwm or linear), loop mode (closed
+	 * or open loop), clock freq, pulse per rev, fan clock div, fan target
+	 * value, and speed control method (closed or open loop) */
+	err = do_set_pwm_mode(&client->dev, pwm_mode);
+	if (err < 0) {
+		dev_info(&client->dev, "unable to set pwm_mode (%d)\n",
+			 pwm_mode);
+	}
+
+	err = do_set_speed_control_mode(&client->dev, pwm_enable);
+	if (err < 0) {
+		dev_info(&client->dev, "unable to set pwm_enable (%d)\n",
+			 pwm_enable);
+	}
+
+	err = do_set_fan_clk_div(&client->dev, fan_clk_div);
+	if (err < 0) {
+		dev_info(&client->dev, "unable to set fan_clk_div (%d)\n",
+			 fan_clk_div);
+	}
+
+	err = do_set_fan_pulses(&client->dev, fan_pulses);
+	if (err < 0) {
+		dev_info(&client->dev, "unable to set fan_pulses (%d)\n",
+			 fan_pulses);
+	}
+
+	data->clk = pwm_freq;
+
+	if (fan_target != 0xffffffff) {
+		err = do_set_fan_target(&client->dev, fan_target);
+		if (err < 0) {
+			dev_info(&client->dev, "unable to set fan_target (%d)\n",
+				 fan_target);
+		}
+	}
+
+	/* Register sysfs hooks */
+	err = sysfs_create_group(&client->dev.kobj, &g762_group);
+	if (err)
+		return err;
+	data->hwmon_dev = (struct device *)hwmon_device_register(&client->dev);
+	if (IS_ERR(data->hwmon_dev)) {
+		err = PTR_ERR(data->hwmon_dev);
+		sysfs_remove_group(&client->dev.kobj, &g762_group);
+		return err;
+	}
+
+	dev_info(&data->client->dev, "device successfully initialized\n");
+
+	return 0;
+}
+
+static int g762_remove(struct i2c_client *client)
+{
+	struct g762_data *data = i2c_get_clientdata(client);
+
+	hwmon_device_unregister(data->hwmon_dev);
+	sysfs_remove_group(&client->dev.kobj, &g762_group);
+
+	dev_info(&data->client->dev, "device successfully removed\n");
+	return 0;
+}
+
+module_i2c_driver(g762_driver);
+
+MODULE_AUTHOR("Olivier Mouchet <olivier.mouchet at gmail.com>");
+MODULE_DESCRIPTION("GMT G762 driver");
+MODULE_LICENSE("GPL");
-- 
1.7.10.4



From arno at natisbad.org  Thu Apr 18 18:28:39 2013
From: arno at natisbad.org (Arnaud Ebalard)
Date: Fri, 19 Apr 2013 00:28:39 +0200
Subject: [RFC,PATCHv0 2/3] Add DT documentation for G762 PWM fan controller
In-Reply-To: <cover.1366322287.git.arno@natisbad.org>
References: <cover.1366322287.git.arno@natisbad.org>
Message-ID: <3a1f8fa72e97a3dc8102bc3ba416c83160205355.1366322287.git.arno@natisbad.org>


Signed-off-by: Arnaud Ebalard <arno at natisbad.org>
---
 Documentation/devicetree/bindings/hwmon/g762.txt |   37 ++++++++++++++++++++++
 1 file changed, 37 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/hwmon/g762.txt

diff --git a/Documentation/devicetree/bindings/hwmon/g762.txt b/Documentation/devicetree/bindings/hwmon/g762.txt
new file mode 100644
index 0000000..9eee838
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/g762.txt
@@ -0,0 +1,37 @@
+GMT G762/G763 PWM Fan controller
+
+Required node properties:
+
+ - "compatible": must be either "gmt,g762" or "gmt,g763"
+ - "reg": I2C bus address of the device
+
+Optional properties:
+
+ - "pwm_mode": fan driving mode. 1 for PWM mode, 0 for linear. Default
+               value is 0, i.e. linear.
+ - "pwm_enable": fan speed control. 1 for open-loop, 2 for closed-loop.
+               Default value is 2, i.e. closed-loop.
+ - "pwm_freq": reference clock frequency for PWM mode in Hz. Default is
+               32768.
+ - "fan_pulses": number of pulses per fan revolution. Supported values
+               are 2 and 4. Default is 2.
+ - "fan_div": fan clock frequency divisor value. Supported values are
+              1, 2, 4 and 8. Default is 1.
+ - "fan_target": initial target fan speed in RPM. By default, current
+               value is not modified.
+
+Previous optional properties provides devicetree access to the entries
+described in Documentation/hwmon/g762
+
+Example g762 node:
+
+   g762: g762 at 3e {
+        compatible = "gmt,g762";
+   	reg = <0x3e>;
+   	pwm_mode = <1>;      /* closed-loop control */
+   	pwm_enable = <2>;    /* PWM mode */
+   	pwm_freq = <8192>;   /* PWM reference clock freq */
+   	fan_pulses = <2>;    /* 2 pulses per rev */
+   	fan_div = <2>;       /* fan clock divisor */
+   	fan_target = <2000>; /* target fan speed at 2000 RPM */
+   };
-- 
1.7.10.4



From arno at natisbad.org  Thu Apr 18 18:28:56 2013
From: arno at natisbad.org (Arnaud Ebalard)
Date: Fri, 19 Apr 2013 00:28:56 +0200
Subject: [PATCH 3/3] Add documentation for g762 driver
In-Reply-To: <cover.1366322287.git.arno@natisbad.org>
References: <cover.1366322287.git.arno@natisbad.org>
Message-ID: <e1cf59a510473a5596fb9be6fc2134bea9c367f2.1366322287.git.arno@natisbad.org>


Signed-off-by: Arnaud Ebalard <arno at natisbad.org>
---
 Documentation/hwmon/g762 |   89 ++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 89 insertions(+)
 create mode 100644 Documentation/hwmon/g762

diff --git a/Documentation/hwmon/g762 b/Documentation/hwmon/g762
new file mode 100644
index 0000000..f281b3d
--- /dev/null
+++ b/Documentation/hwmon/g762
@@ -0,0 +1,89 @@
+Kernel driver g762
+==================
+
+This documentation is based on G760a one, GMT G762 datasheet available
+at http://natisbad.org/NAS/ref/GMT_EDS-762_763-080710-0.2.pdf (used
+for the development of the driver) and sysfs bindings described in
+Documentation/hwmon/sysfs-interface.
+
+The GMT G762 Fan Speed PWM Controller is connected directly to a fan
+and performs closed-loop or open-loop control of the fan speed. Two
+modes - PWM or linear - are supported by the device.
+
+The following entries are available to the user in a subdirectory of
+/sys/bus/i2c/drivers/g762/ to control the operation of the device.
+Some of those can be used to fit operations of the controller to the
+characteristics of the system (reference clock value, fan gear mode,
+number of pulses per fan revolution, ...). Other more common
+parameters can be used to interact with the fan and control its speed
+(set a rotation speed and get current speed for instance). This can be
+done manually using the following entries but is usually done via a
+userland daemon like fancontrol.
+
+
+  fan1_target: set desired fan speed. This only makes sense in closed-loop
+            fan speed control (i.e. when pwm1_enable is set to 2).
+
+  fan1_input: provide current fan rotation value in RPM as reported by
+            the fan to the device.
+
+  fan1_pulses: number of tachometer pulses per fan revolution. Supported
+            values are 2 and 4. Default value is 2.
+
+  fan1_div: fan clock divisor. Supported value are 1, 2, 4 and 8. Default
+            value is 1.
+
+  fan1_gear_mode: fan gear mode. Supported values are 0, 1 and 2. Default
+            value is 0. The value is a characteristic of the system
+            and a higher value can be set for more precisely control
+            fans with a high rotation speed. Note that this affects the
+            measurable speed range, not the read value.
+
+  fan1_fault: reports fan failure, i.e. no transition on fan gear pin for
+            about 0.7s (if the fan is not voluntarily set off).
+
+  fan1_fault_detection: enable fan failure detection and reporting as
+            described above.
+
+  fan1_alarm: in closed-loop control mode, if fan RPM value is 25% out
+            of the programmed value for over 6 seconds 'fan1_alarm' is
+            set to 1.
+
+  fan1_alarm_detection: enable fan out of control detection and reporting
+            as described above.
+
+  fan1_startup_voltage: get or set fan startup voltage. Supported values
+            are 0, 1, 2, 3 (respectively for 1.0V, 1.5V, 2.0V and 2.5V).
+
+
+
+  pwm1: get or set PWM fan control value. This is an integer value
+            between 0 and 255. 0 stops the fan, 255 makes it run at
+            full speed.
+
+  pwm1_polarity: set or get the PWM polarity, 0 for positive duty, 1 for
+            negative duty
+
+  pwm1_enable: set current fan speed control mode i.e. 1 for manual fan
+            speed control (open-loop), 2 for automatic fan speed control
+            (closed-loop).
+
+  pwm1_mode: set or get fan driving mode: 1 for PWM mode, 0 for linear
+            mode. Default is linear mode.
+
+  pwm1_freq: set or get value of PWM reference clock frequency. Default
+            value is 32768 (Hz). This parameter only makes sense when
+            the device is set to operate in PWM mode (i.e. pwm1_mode
+            is 1).
+
+
+In PWM mode ('pwm1_mode' set to 1), the fan speed is programmed either by
+setting a value between 0 and 255 via 'pwm1' entry (0 stops the fan, 255
+makes it run at full speed). This can also be done by passing the
+expected RPM value via 'fan1_target'. Current fan speed value can be
+retrieved via 'fan1_input'. This fan speed value is computed based on
+the parameters associated with the physical characteristics of the
+system: a reference clock source frequency, a number of pulses per fan
+revolution, etc.
+
+Note that the driver will update its values at most once per second.
-- 
1.7.10.4



From sameo at linux.intel.com  Thu Apr 18 18:40:46 2013
From: sameo at linux.intel.com (Samuel Ortiz)
Date: Fri, 19 Apr 2013 00:40:46 +0200
Subject: [PATCH v2] UCB1400: Pass ucb1400-gpio data through ac97 bus
In-Reply-To: <1365964548-4193-1-git-send-email-marex@denx.de>
References: <CACRpkdZ+ku_-SBTXwwwRDh7F2TXzpgpAF3k+Ksn98BNYXximXw@mail.gmail.com>
 <1365964548-4193-1-git-send-email-marex@denx.de>
Message-ID: <20130418224046.GD8798@zurbaran>

On Sun, Apr 14, 2013 at 08:35:48PM +0200, Marek Vasut wrote:
> Cc: Linus Walleij <linus.walleij at linaro.org>
> Cc: Jean Delvare <jdelvare at suse.de>
> Cc: Samuel Ortiz <sameo at linux.intel.com>
> Cc: Mark Brown <broonie at opensource.wolfsonmicro.com>
> Cc: Guenter Roeck <linux at roeck-us.net>
> Cc: linux-kernel <linux-kernel at vger.kernel.org>
> Cc: Grant Likely <grant.likely at secretlab.ca>
> Signed-off-by: Marek Vasut <marex at denx.de>
> ---
>  drivers/gpio/gpio-ucb1400.c |   19 ++++++-------------
>  drivers/mfd/ucb1400_core.c  |    5 +++++
>  include/linux/ucb1400.h     |   18 ++++++------------
>  3 files changed, 17 insertions(+), 25 deletions(-)
Applied, thanks.

Cheers,
Samuel.

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


From sergei.shtylyov at cogentembedded.com  Thu Apr 18 18:50:05 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Fri, 19 Apr 2013 02:50:05 +0400
Subject: [PATCH v3 4/4] ARM: shmobile: BOCK-W: enable USB in defconfig
In-Reply-To: <20130418140552.GO20929@verge.net.au>
References: <201304170135.10251.sergei.shtylyov@cogentembedded.com>
 <20130418140552.GO20929@verge.net.au>
Message-ID: <5170789D.5020108@cogentembedded.com>

Hello.

On 04/18/2013 06:05 PM, Simon Horman wrote:

>
>> Enable USB platform EHCI/OHCI and common PHY drivers in 'bockw_defconfig'.
>> Enable USB storage driver and SCSI disk driver that it needs as well...
>>
>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
> I realise that this is not going to be useful until the rest
> of the series has been merged. But regardless I have pre-emptively
> queued it up for v3.11 in the defconfig-bockw branch.
>> ---
>>   arch/arm/configs/bockw_defconfig |   11 ++++++++++-
>>   1 file changed, 10 insertions(+), 1 deletion(-)
>>
>> Index: renesas/arch/arm/configs/bockw_defconfig
>> ===================================================================
>> --- renesas.orig/arch/arm/configs/bockw_defconfig
>> +++ renesas/arch/arm/configs/bockw_defconfig
>> @@ -48,6 +48,8 @@ CONFIG_DEVTMPFS_MOUNT=y
>>   # CONFIG_STANDALONE is not set
>>   # CONFIG_PREVENT_FIRMWARE_BUILD is not set
>>   # CONFIG_FW_LOADER is not set
>> +CONFIG_SCSI=y
>> +CONFIG_BLK_DEV_SD=y
>>   CONFIG_NETDEVICES=y
>>   # CONFIG_NET_CADENCE is not set
>>   # CONFIG_NET_VENDOR_BROADCOM is not set
>> @@ -71,7 +73,14 @@ CONFIG_SERIAL_SH_SCI_NR_UARTS=6
>>   CONFIG_SERIAL_SH_SCI_CONSOLE=y
>>   # CONFIG_HW_RANDOM is not set
>>   # CONFIG_HWMON is not set
>> -# CONFIG_USB_SUPPORT is not set
>> +CONFIG_USB=y
>> +CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
>> +CONFIG_USB_EHCI_HCD=y
>> +CONFIG_USB_OHCI_HCD=y
>> +CONFIG_USB_OHCI_HCD_PLATFORM=y
>> +CONFIG_USB_EHCI_HCD_PLATFORM=y
>> +CONFIG_USB_STORAGE=y
>> +CONFIG_USB_RCAR_PHY=y
>>

    Unfortunately, you've made a mistake in this last line of the patch:
you've truncated it to just "CONFIG_USB_RCAR". :-(
    Will you correct it?

WBR, Sergei



From jon-hunter at ti.com  Thu Apr 18 19:10:52 2013
From: jon-hunter at ti.com (Jon Hunter)
Date: Thu, 18 Apr 2013 18:10:52 -0500
Subject: [PATCH] gpio/omap: ensure gpio context is initialised
In-Reply-To: <871ua734mv.fsf@linaro.org>
References: <1366230707-32681-1-git-send-email-jon-hunter@ti.com>
 <871ua734mv.fsf@linaro.org>
Message-ID: <51707D7C.1050600@ti.com>

Hi Kevin,

On 04/18/2013 04:34 PM, Kevin Hilman wrote:
> Hi Jon,
> 
> Jon Hunter <jon-hunter at ti.com> writes:
> 
>> Commit a2797be (gpio/omap: force restore if context loss is not
>> detectable) broke gpio support for OMAP when booting with device-tree
>> because a restore of the gpio context being performed without ever
>> initialising the gpio context. In other words, the context restored was
>> bad.
>>
>> This problem could also occur in the non device-tree case, however, it
>> is much less likely because when booting without device-tree we can
>> detect context loss via a platform specific API and so context restore
>> is performed less often.
>>
>> Nevertheless we should ensure that the gpio context is initialised
>> during the probe for gpio banks that could lose their state regardless
>> of whether we are booting with device-tree or not.
>>
>> Reported-by: Tony Lindgren <tony at atomide.com>
>> Signed-off-by: Jon Hunter <jon-hunter at ti.com>
>> Tested-by: Tony Lindgren <tony at atomide.com>
>> ---
>>  drivers/gpio/gpio-omap.c |   53 +++++++++++++++++++++++++++++++++++++---------
>>  1 file changed, 43 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
>> index 0557529..0ba5cb9 100644
>> --- a/drivers/gpio/gpio-omap.c
>> +++ b/drivers/gpio/gpio-omap.c
>> @@ -70,6 +70,7 @@ struct gpio_bank {
>>  	bool is_mpuio;
>>  	bool dbck_flag;
>>  	bool loses_context;
>> +	bool context_valid;
>>  	int stride;
>>  	u32 width;
>>  	int context_loss_count;
>> @@ -1085,6 +1086,7 @@ static void omap_gpio_chip_init(struct gpio_bank *bank)
>>  }
>>  
>>  static const struct of_device_id omap_gpio_match[];
>> +static void omap_gpio_init_context(struct gpio_bank *p);
>>  
>>  static int omap_gpio_probe(struct platform_device *pdev)
>>  {
>> @@ -1179,8 +1181,10 @@ static int omap_gpio_probe(struct platform_device *pdev)
>>  	omap_gpio_chip_init(bank);
>>  	omap_gpio_show_rev(bank);
>>  
>> -	if (bank->loses_context)
>> +	if (bank->loses_context) {
>>  		bank->get_context_loss_count = pdata->get_context_loss_count;
>> +		omap_gpio_init_context(bank);
>> +	}
>>  
>>  	pm_runtime_put(bank->dev);
>>  
>> @@ -1269,6 +1273,14 @@ static int omap_gpio_runtime_resume(struct device *dev)
>>  	int c;
>>  
>>  	spin_lock_irqsave(&bank->lock, flags);
>> +
>> +	/*
>> +	 * On the first resume during the probe, the context has not
>> +	 * been initialised and so if the context is not valid return.
>> +	 */
>> +	if (!bank->context_valid)
>> +		goto done;
> 
> Not sure I follow the reason to separate it here and in probe.  
> 
> Also, this makes the first runtime_resume a special case and leaves
> things in a strange semi-initialized state that is confusing IMO.

The first resume has always been a special case. The
"bank->get_context_loss_count" is not initialised until after the first
resume (due to another issue we had found - 7b86cef gpio/omap: fix
invalid context restore of gpio bank-0). This should not leave things in
a strange semi-init'ed state, as on the first resume nothing is really
done anyway because there is no context loss.

> Why not just init context right here if bank->loses_context &&
> !bank->context_valid?

Thanks for the suggestion.

> Then the first resume can continue as expected, and everything is fully
> initialized as expected also.  IMO, this is much more readable (and
> maintainable, but that's your job now, so you can decide ;)

If the context has not been lost, which it has not on the first resume,
then resume really does nothing. That's why I had just returned.
However, I would agree that is not completely readable.

Cheers
Jon


From shawn.guo at linaro.org  Thu Apr 18 19:30:27 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Fri, 19 Apr 2013 07:30:27 +0800
Subject: [GIT PULL 4/4] ARM: imx: device tree changes for 3.10
In-Reply-To: <20130418162545.GA7083@quad.lixom.net>
References: <1365520775-28478-1-git-send-email-shawn.guo@linaro.org>
 <1365520775-28478-4-git-send-email-shawn.guo@linaro.org>
 <20130418162545.GA7083@quad.lixom.net>
Message-ID: <20130418233025.GA11103@S2101-09.ap.freescale.net>

On Thu, Apr 18, 2013 at 09:25:45AM -0700, Olof Johansson wrote:
> Hi,
> 
> On Tue, Apr 09, 2013 at 11:19:35PM +0800, Shawn Guo wrote:
> > Hi Arnd, Olof,
> > 
> > It's based on imx-cleanup-3.10 and Stephen Warren's "[GIT PULL] dt:
> > run C pre-processor on *.dts, create some standard headers" to resolve
> > dependency and conflicts.
> > 
> 
> That's not adequate description of a dependency. We need to know what git
> branch, not what patch posting, this is based on. And we need to make sure that
> said git branch will never be rebased on the way up to Linus. That's
> a three-way handshake between you, us and the maintainer with that dependency
> in his tree.

Ok, will do better in the future.

Shawn



From sboyd at codeaurora.org  Thu Apr 18 20:00:24 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Thu, 18 Apr 2013 17:00:24 -0700
Subject: [PATCH 1/2] clocksource: arm_arch_timer: unify sched_clock init
In-Reply-To: <1366313410-16692-1-git-send-email-robherring2@gmail.com>
References: <1366313410-16692-1-git-send-email-robherring2@gmail.com>
Message-ID: <51708918.1070501@codeaurora.org>

On 04/18/13 12:30, Rob Herring wrote:
> diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
> index 122ff05..17ed8e4 100644
> --- a/drivers/clocksource/arm_arch_timer.c
> +++ b/drivers/clocksource/arm_arch_timer.c
> @@ -266,6 +266,15 @@ static struct notifier_block arch_timer_cpu_nb __cpuinitdata = {
>  	.notifier_call = arch_timer_cpu_notify,
>  };
>  
> +static u64 sched_clock_mult __read_mostly;
> +
> +unsigned long long notrace arch_timer_sched_clock(void)
> +{
> +	return arch_timer_read_counter() * sched_clock_mult;
> +}
> +unsigned long long sched_clock(void) \
> +	__attribute__((weak, alias("arch_timer_sched_clock")));

I'm still lost, how does this prevent the timer in ARM's 32 bit
sched_clock code from getting setup in sched_clock_postinit()? That
print is still there right? Who owns sched_clock() in multi-target builds?

Why can't we play along with the sched_clock code that lives in arm?
Maybe we should resurrect those clocksource sched_clock patches again.
Or maybe we should add support for setup_sched_clock_64() in arm's sched
clock code.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation



From kuninori.morimoto.gx at renesas.com  Thu Apr 18 20:27:47 2013
From: kuninori.morimoto.gx at renesas.com (Kuninori Morimoto)
Date: Thu, 18 Apr 2013 17:27:47 -0700 (PDT)
Subject: [PATCH v2 0/9] Reorganize R8A7779/Marzen USB code
In-Reply-To: <87mwsydklg.wl%kuninori.morimoto.gx@renesas.com>
References: <201304090110.50154.sergei.shtylyov@cogentembedded.com>
 <87zjx89rfb.wl%kuninori.morimoto.gx@renesas.com>
 <51640D21.3090800@cogentembedded.com>
 <87txnfjhmu.wl%kuninori.morimoto.gx@renesas.com>
 <51689399.5090203@cogentembedded.com>
 <51689488.7040109@cogentembedded.com>
 <87mwsydklg.wl%kuninori.morimoto.gx@renesas.com>
Message-ID: <87a9ov74ao.wl%kuninori.morimoto.gx@renesas.com>


Hi Sergei

> > >>>      I'm going to post R8A7778/BOCK-W series following this one, and 
> > >>> all the
> > >>> patches in 1st series should additionally be tested on BOCK-W. Well, I
> > >>> probably can hold up posting version 3 until I have the second 
> > >>> series verified.
> > >>>      BTW, about R8A7778/BOCK-W, R-Car M1A user manual talks about a 
> > >>> ferrite
> > >>> bead in 49.4.1 (3) Setting USB-PHY. Do you know for sure if it's 
> > >>> used or not
> > >>> on BOCK-W board? PHY initialization seems to work with either 
> > >>> settings...
> > >> I can ask it to HW team if you want me.
> > 
> >     Yes, ask them please.
> 
> Now, I'm asking it to HW team
> Please wait

According to HW team,
this setting is for some kind of USB compliance test (?).
So, in general, we can use "No ferrite bead".

Best regards
---
Kuninori Morimoto


From jon-hunter at ti.com  Thu Apr 18 20:34:36 2013
From: jon-hunter at ti.com (Jon Hunter)
Date: Thu, 18 Apr 2013 19:34:36 -0500
Subject: [PATCH] gpio/omap: ensure gpio context is initialised
In-Reply-To: <51707D7C.1050600@ti.com>
References: <1366230707-32681-1-git-send-email-jon-hunter@ti.com>
 <871ua734mv.fsf@linaro.org> <51707D7C.1050600@ti.com>
Message-ID: <5170911C.6010507@ti.com>


On 04/18/2013 06:10 PM, Jon Hunter wrote:
> On 04/18/2013 04:34 PM, Kevin Hilman wrote:

...

>> Why not just init context right here if bank->loses_context &&
>> !bank->context_valid?

I really like this idea a lot. It can really clean-up the code
and really make it much more readable. Before we were playing 
some tricks with when we init'ed the get_context_loss_count()
function pointer. How about the below?

Tony, care to re-test?

Cheers
Jon

>From d7a940531d354e6be5e16ee50fa8344041df963a Mon Sep 17 00:00:00 2001
From: Jon Hunter <jon-hunter at ti.com>
Date: Mon, 15 Apr 2013 13:06:54 -0500
Subject: [PATCH] gpio/omap: ensure gpio context is initialised

Commit a2797be (gpio/omap: force restore if context loss is not
detectable) broke gpio support for OMAP when booting with device-tree
because a restore of the gpio context being performed without ever
initialising the gpio context. In other words, the context restored was
bad.

This problem could also occur in the non device-tree case, however, it
is much less likely because when booting without device-tree we can
detect context loss via a platform specific API and so context restore
is performed less often.

Nevertheless we should ensure that the gpio context is initialised
on the first pm-runtime resume for gpio banks that could lose their
state regardless of whether we are booting with device-tree or not.

The context loss count was being initialised on the first pm-runtime
suspend following a resume, by populating the get_count_loss_count()
function pointer after the first pm-runtime resume. To make the code
more readable and logical, initialise the context loss count on the
first pm-runtime resume if the context is not yet valid.

Reported-by: Tony Lindgren <tony at atomide.com>
Signed-off-by: Jon Hunter <jon-hunter at ti.com>
---
 drivers/gpio/gpio-omap.c |   45 ++++++++++++++++++++++++++++++++++++++++++---
 1 file changed, 42 insertions(+), 3 deletions(-)

diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 0557529..db3c732 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -70,6 +70,7 @@ struct gpio_bank {
 	bool is_mpuio;
 	bool dbck_flag;
 	bool loses_context;
+	bool context_valid;
 	int stride;
 	u32 width;
 	int context_loss_count;
@@ -1129,6 +1130,7 @@ static int omap_gpio_probe(struct platform_device *pdev)
 			bank->loses_context = true;
 	} else {
 		bank->loses_context = pdata->loses_context;
+		bank->get_context_loss_count = pdata->get_context_loss_count;
 	}
 
 
@@ -1179,9 +1181,6 @@ static int omap_gpio_probe(struct platform_device *pdev)
 	omap_gpio_chip_init(bank);
 	omap_gpio_show_rev(bank);
 
-	if (bank->loses_context)
-		bank->get_context_loss_count = pdata->get_context_loss_count;
-
 	pm_runtime_put(bank->dev);
 
 	list_add_tail(&bank->node, &omap_gpio_list);
@@ -1260,6 +1259,8 @@ update_gpio_context_count:
 	return 0;
 }
 
+static void omap_gpio_init_context(struct gpio_bank *p);
+
 static int omap_gpio_runtime_resume(struct device *dev)
 {
 	struct platform_device *pdev = to_platform_device(dev);
@@ -1269,6 +1270,20 @@ static int omap_gpio_runtime_resume(struct device *dev)
 	int c;
 
 	spin_lock_irqsave(&bank->lock, flags);
+
+	/*
+	 * On the first resume during the probe, the context has not
+	 * been initialised and so initialise it now. Also initialise
+	 * the context loss count.
+	 */
+	if (bank->loses_context && !bank->context_valid) {
+		omap_gpio_init_context(bank);
+
+		if (bank->get_context_loss_count)
+			bank->context_loss_count =
+				bank->get_context_loss_count(bank->dev);
+	}
+
 	_gpio_dbck_enable(bank);
 
 	/*
@@ -1385,6 +1400,29 @@ void omap2_gpio_resume_after_idle(void)
 }
 
 #if defined(CONFIG_PM_RUNTIME)
+static void omap_gpio_init_context(struct gpio_bank *p)
+{
+	struct omap_gpio_reg_offs *regs = p->regs;
+	void __iomem *base = p->base;
+
+	p->context.ctrl		= __raw_readl(base + regs->ctrl);
+	p->context.oe		= __raw_readl(base + regs->direction);
+	p->context.wake_en	= __raw_readl(base + regs->wkup_en);
+	p->context.leveldetect0	= __raw_readl(base + regs->leveldetect0);
+	p->context.leveldetect1	= __raw_readl(base + regs->leveldetect1);
+	p->context.risingdetect	= __raw_readl(base + regs->risingdetect);
+	p->context.fallingdetect = __raw_readl(base + regs->fallingdetect);
+	p->context.irqenable1	= __raw_readl(base + regs->irqenable);
+	p->context.irqenable2	= __raw_readl(base + regs->irqenable2);
+
+	if (regs->set_dataout && p->regs->clr_dataout)
+		p->context.dataout = __raw_readl(base + regs->set_dataout);
+	else
+		p->context.dataout = __raw_readl(base + regs->dataout);
+
+	p->context_valid = true;
+}
+
 static void omap_gpio_restore_context(struct gpio_bank *bank)
 {
 	__raw_writel(bank->context.wake_en,
@@ -1422,6 +1460,7 @@ static void omap_gpio_restore_context(struct gpio_bank *bank)
 #else
 #define omap_gpio_runtime_suspend NULL
 #define omap_gpio_runtime_resume NULL
+static void omap_gpio_init_context(struct gpio_bank *p) {}
 #endif
 
 static const struct dev_pm_ops gpio_pm_ops = {
-- 
1.7.10.4



From jon-hunter at ti.com  Thu Apr 18 20:49:29 2013
From: jon-hunter at ti.com (Jon Hunter)
Date: Thu, 18 Apr 2013 19:49:29 -0500
Subject: [PATCH] gpio/omap: ensure gpio context is initialised
In-Reply-To: <5170911C.6010507@ti.com>
References: <1366230707-32681-1-git-send-email-jon-hunter@ti.com>
 <871ua734mv.fsf@linaro.org> <51707D7C.1050600@ti.com>
 <5170911C.6010507@ti.com>
Message-ID: <51709499.8030208@ti.com>


On 04/18/2013 07:34 PM, Jon Hunter wrote:
> 
> On 04/18/2013 06:10 PM, Jon Hunter wrote:
>> On 04/18/2013 04:34 PM, Kevin Hilman wrote:
> 
> ...
> 
>>> Why not just init context right here if bank->loses_context &&
>>> !bank->context_valid?
> 
> I really like this idea a lot. It can really clean-up the code
> and really make it much more readable. Before we were playing 
> some tricks with when we init'ed the get_context_loss_count()
> function pointer. How about the below?
> 
> Tony, care to re-test?
> 
> Cheers
> Jon
> 
> From d7a940531d354e6be5e16ee50fa8344041df963a Mon Sep 17 00:00:00 2001
> From: Jon Hunter <jon-hunter at ti.com>
> Date: Mon, 15 Apr 2013 13:06:54 -0500
> Subject: [PATCH] gpio/omap: ensure gpio context is initialised
> 
> Commit a2797be (gpio/omap: force restore if context loss is not
> detectable) broke gpio support for OMAP when booting with device-tree
> because a restore of the gpio context being performed without ever
> initialising the gpio context. In other words, the context restored was
> bad.
> 
> This problem could also occur in the non device-tree case, however, it
> is much less likely because when booting without device-tree we can
> detect context loss via a platform specific API and so context restore
> is performed less often.
> 
> Nevertheless we should ensure that the gpio context is initialised
> on the first pm-runtime resume for gpio banks that could lose their
> state regardless of whether we are booting with device-tree or not.
> 
> The context loss count was being initialised on the first pm-runtime
> suspend following a resume, by populating the get_count_loss_count()
> function pointer after the first pm-runtime resume. To make the code
> more readable and logical, initialise the context loss count on the
> first pm-runtime resume if the context is not yet valid.
> 
> Reported-by: Tony Lindgren <tony at atomide.com>
> Signed-off-by: Jon Hunter <jon-hunter at ti.com>
> ---
>  drivers/gpio/gpio-omap.c |   45 ++++++++++++++++++++++++++++++++++++++++++---
>  1 file changed, 42 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
> index 0557529..db3c732 100644
> --- a/drivers/gpio/gpio-omap.c
> +++ b/drivers/gpio/gpio-omap.c
> @@ -70,6 +70,7 @@ struct gpio_bank {
>  	bool is_mpuio;
>  	bool dbck_flag;
>  	bool loses_context;
> +	bool context_valid;
>  	int stride;
>  	u32 width;
>  	int context_loss_count;
> @@ -1129,6 +1130,7 @@ static int omap_gpio_probe(struct platform_device *pdev)
>  			bank->loses_context = true;
>  	} else {
>  		bank->loses_context = pdata->loses_context;
> +		bank->get_context_loss_count = pdata->get_context_loss_count;

Still need to check loses_context for populating
get_context_loss_count here. Updated patch below.

Jon

>From d02ef7b7dfcf8e13bf019aedfdecb38ca3c6749f Mon Sep 17 00:00:00 2001
From: Jon Hunter <jon-hunter at ti.com>
Date: Mon, 15 Apr 2013 13:06:54 -0500
Subject: [PATCH] gpio/omap: ensure gpio context is initialised

Commit a2797be (gpio/omap: force restore if context loss is not
detectable) broke gpio support for OMAP when booting with device-tree
because a restore of the gpio context being performed without ever
initialising the gpio context. In other words, the context restored was
bad.

This problem could also occur in the non device-tree case, however, it
is much less likely because when booting without device-tree we can
detect context loss via a platform specific API and so context restore
is performed less often.

Nevertheless we should ensure that the gpio context is initialised
on the first pm-runtime resume for gpio banks that could lose their
state regardless of whether we are booting with device-tree or not.

The context loss count was being initialised on the first pm-runtime
suspend following a resume, by populating the get_count_loss_count()
function pointer after the first pm-runtime resume. To make the code
more readable and logical, initialise the context loss count on the
first pm-runtime resume if the context is not yet valid.

Reported-by: Tony Lindgren <tony at atomide.com>
Signed-off-by: Jon Hunter <jon-hunter at ti.com>
---
 drivers/gpio/gpio-omap.c |   48 +++++++++++++++++++++++++++++++++++++++++++---
 1 file changed, 45 insertions(+), 3 deletions(-)

diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 0557529..c3c3ffe 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -70,6 +70,7 @@ struct gpio_bank {
 	bool is_mpuio;
 	bool dbck_flag;
 	bool loses_context;
+	bool context_valid;
 	int stride;
 	u32 width;
 	int context_loss_count;
@@ -1129,6 +1130,10 @@ static int omap_gpio_probe(struct platform_device *pdev)
 			bank->loses_context = true;
 	} else {
 		bank->loses_context = pdata->loses_context;
+
+		if (bank->loses_context)
+			bank->get_context_loss_count =
+				pdata->get_context_loss_count;
 	}
 
 
@@ -1179,9 +1184,6 @@ static int omap_gpio_probe(struct platform_device *pdev)
 	omap_gpio_chip_init(bank);
 	omap_gpio_show_rev(bank);
 
-	if (bank->loses_context)
-		bank->get_context_loss_count = pdata->get_context_loss_count;
-
 	pm_runtime_put(bank->dev);
 
 	list_add_tail(&bank->node, &omap_gpio_list);
@@ -1260,6 +1262,8 @@ update_gpio_context_count:
 	return 0;
 }
 
+static void omap_gpio_init_context(struct gpio_bank *p);
+
 static int omap_gpio_runtime_resume(struct device *dev)
 {
 	struct platform_device *pdev = to_platform_device(dev);
@@ -1269,6 +1273,20 @@ static int omap_gpio_runtime_resume(struct device *dev)
 	int c;
 
 	spin_lock_irqsave(&bank->lock, flags);
+
+	/*
+	 * On the first resume during the probe, the context has not
+	 * been initialised and so initialise it now. Also initialise
+	 * the context loss count.
+	 */
+	if (bank->loses_context && !bank->context_valid) {
+		omap_gpio_init_context(bank);
+
+		if (bank->get_context_loss_count)
+			bank->context_loss_count =
+				bank->get_context_loss_count(bank->dev);
+	}
+
 	_gpio_dbck_enable(bank);
 
 	/*
@@ -1385,6 +1403,29 @@ void omap2_gpio_resume_after_idle(void)
 }
 
 #if defined(CONFIG_PM_RUNTIME)
+static void omap_gpio_init_context(struct gpio_bank *p)
+{
+	struct omap_gpio_reg_offs *regs = p->regs;
+	void __iomem *base = p->base;
+
+	p->context.ctrl		= __raw_readl(base + regs->ctrl);
+	p->context.oe		= __raw_readl(base + regs->direction);
+	p->context.wake_en	= __raw_readl(base + regs->wkup_en);
+	p->context.leveldetect0	= __raw_readl(base + regs->leveldetect0);
+	p->context.leveldetect1	= __raw_readl(base + regs->leveldetect1);
+	p->context.risingdetect	= __raw_readl(base + regs->risingdetect);
+	p->context.fallingdetect = __raw_readl(base + regs->fallingdetect);
+	p->context.irqenable1	= __raw_readl(base + regs->irqenable);
+	p->context.irqenable2	= __raw_readl(base + regs->irqenable2);
+
+	if (regs->set_dataout && p->regs->clr_dataout)
+		p->context.dataout = __raw_readl(base + regs->set_dataout);
+	else
+		p->context.dataout = __raw_readl(base + regs->dataout);
+
+	p->context_valid = true;
+}
+
 static void omap_gpio_restore_context(struct gpio_bank *bank)
 {
 	__raw_writel(bank->context.wake_en,
@@ -1422,6 +1463,7 @@ static void omap_gpio_restore_context(struct gpio_bank *bank)
 #else
 #define omap_gpio_runtime_suspend NULL
 #define omap_gpio_runtime_resume NULL
+static void omap_gpio_init_context(struct gpio_bank *p) {}
 #endif
 
 static const struct dev_pm_ops gpio_pm_ops = {
-- 
1.7.10.4


From robherring2 at gmail.com  Thu Apr 18 21:37:27 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Thu, 18 Apr 2013 20:37:27 -0500
Subject: [PATCH 1/2] clocksource: arm_arch_timer: unify sched_clock init
In-Reply-To: <51708918.1070501@codeaurora.org>
References: <1366313410-16692-1-git-send-email-robherring2@gmail.com>
 <51708918.1070501@codeaurora.org>
Message-ID: <51709FD7.8050408@gmail.com>

On 04/18/2013 07:00 PM, Stephen Boyd wrote:
> On 04/18/13 12:30, Rob Herring wrote:
>> diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
>> index 122ff05..17ed8e4 100644
>> --- a/drivers/clocksource/arm_arch_timer.c
>> +++ b/drivers/clocksource/arm_arch_timer.c
>> @@ -266,6 +266,15 @@ static struct notifier_block arch_timer_cpu_nb __cpuinitdata = {
>>  	.notifier_call = arch_timer_cpu_notify,
>>  };
>>  
>> +static u64 sched_clock_mult __read_mostly;
>> +
>> +unsigned long long notrace arch_timer_sched_clock(void)
>> +{
>> +	return arch_timer_read_counter() * sched_clock_mult;
>> +}
>> +unsigned long long sched_clock(void) \
>> +	__attribute__((weak, alias("arch_timer_sched_clock")));
> 
> I'm still lost, how does this prevent the timer in ARM's 32 bit
> sched_clock code from getting setup in sched_clock_postinit()? That
> print is still there right? Who owns sched_clock() in multi-target builds?

For arm64, it does not define sched_clock, so it will get
arch_timer_sched_clock.

For arm, sched_clock is defined in arch/arm/kernel/sched_clock.c and the
weak alias is not used. The arm sched_clock function just calls a
function pointer which defaults to sched_clock_32 (which is the original
arm sched_clock implementation). If the arch timer is present, then the
function pointer is set to arch_timer_sched_clock and any calls to
setup_sched_clock and the sched_clock_postinit have no effect.
Otherwise, the functionality is basically unchanged for <=32-bit
sched_clock implementations.

> Why can't we play along with the sched_clock code that lives in arm?
> Maybe we should resurrect those clocksource sched_clock patches again.
> Or maybe we should add support for setup_sched_clock_64() in arm's sched
> clock code.

That's what I originally had which Russell objected to. The needs for
the arch timer is a bit different since we don't need to deal with
wrapping. And we need the same boot time offset and suspend handling in
both arm and arm64.

Rob



From horms at verge.net.au  Thu Apr 18 22:14:14 2013
From: horms at verge.net.au (Simon Horman)
Date: Fri, 19 Apr 2013 11:14:14 +0900
Subject: [PATCH v3 4/4] ARM: shmobile: BOCK-W: enable USB in defconfig
In-Reply-To: <5170789D.5020108@cogentembedded.com>
References: <201304170135.10251.sergei.shtylyov@cogentembedded.com>
 <20130418140552.GO20929@verge.net.au>
 <5170789D.5020108@cogentembedded.com>
Message-ID: <20130419021414.GB25718@verge.net.au>

On Fri, Apr 19, 2013 at 02:50:05AM +0400, Sergei Shtylyov wrote:
> Hello.
> 
> On 04/18/2013 06:05 PM, Simon Horman wrote:
> 
> >
> >>Enable USB platform EHCI/OHCI and common PHY drivers in 'bockw_defconfig'.
> >>Enable USB storage driver and SCSI disk driver that it needs as well...
> >>
> >>Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
> >I realise that this is not going to be useful until the rest
> >of the series has been merged. But regardless I have pre-emptively
> >queued it up for v3.11 in the defconfig-bockw branch.
> >>---
> >>  arch/arm/configs/bockw_defconfig |   11 ++++++++++-
> >>  1 file changed, 10 insertions(+), 1 deletion(-)
> >>
> >>Index: renesas/arch/arm/configs/bockw_defconfig
> >>===================================================================
> >>--- renesas.orig/arch/arm/configs/bockw_defconfig
> >>+++ renesas/arch/arm/configs/bockw_defconfig
> >>@@ -48,6 +48,8 @@ CONFIG_DEVTMPFS_MOUNT=y
> >>  # CONFIG_STANDALONE is not set
> >>  # CONFIG_PREVENT_FIRMWARE_BUILD is not set
> >>  # CONFIG_FW_LOADER is not set
> >>+CONFIG_SCSI=y
> >>+CONFIG_BLK_DEV_SD=y
> >>  CONFIG_NETDEVICES=y
> >>  # CONFIG_NET_CADENCE is not set
> >>  # CONFIG_NET_VENDOR_BROADCOM is not set
> >>@@ -71,7 +73,14 @@ CONFIG_SERIAL_SH_SCI_NR_UARTS=6
> >>  CONFIG_SERIAL_SH_SCI_CONSOLE=y
> >>  # CONFIG_HW_RANDOM is not set
> >>  # CONFIG_HWMON is not set
> >>-# CONFIG_USB_SUPPORT is not set
> >>+CONFIG_USB=y
> >>+CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
> >>+CONFIG_USB_EHCI_HCD=y
> >>+CONFIG_USB_OHCI_HCD=y
> >>+CONFIG_USB_OHCI_HCD_PLATFORM=y
> >>+CONFIG_USB_EHCI_HCD_PLATFORM=y
> >>+CONFIG_USB_STORAGE=y
> >>+CONFIG_USB_RCAR_PHY=y
> >>
> 
>    Unfortunately, you've made a mistake in this last line of the patch:
> you've truncated it to just "CONFIG_USB_RCAR". :-(
>    Will you correct it?

Sorry about that, I will fix it.


From horms at verge.net.au  Thu Apr 18 22:15:30 2013
From: horms at verge.net.au (Simon Horman)
Date: Fri, 19 Apr 2013 11:15:30 +0900
Subject: [PATCH 4/4] ARM: shmobile: Marzen: enable VIN and ADV7180 in
 defconfig
In-Reply-To: <51700158.101@cogentembedded.com>
References: <201304180206.39465.sergei.shtylyov@cogentembedded.com>
 <201304180217.28176.sergei.shtylyov@cogentembedded.com>
 <20130418133022.GD20929@verge.net.au>
 <51700158.101@cogentembedded.com>
Message-ID: <20130419021530.GD25718@verge.net.au>

On Thu, Apr 18, 2013 at 06:21:12PM +0400, Sergei Shtylyov wrote:
> On 18-04-2013 17:30, Simon Horman wrote:
> 
> >>From: Vladimir Barinov <vladimir.barinov at cogentembedded.com>
> 
> >>Add the VIN and ADV7180 drivers to 'marzen_defconfig'.
> 
> >>Signed-off-by: Vladimir Barinov <vladimir.barinov at cogentembedded.com>
> >>Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
> 
> >>---
> >>  arch/arm/configs/marzen_defconfig |    7 +++++++
> >>  1 file changed, 7 insertions(+)
> 
> >Thanks, queued-up for v3.11 in the defconfig-marzen branch.
> 
>    That seems somewhat premature as CONFIG_VIDEO_RCAR_VIN is not
> defined yet (it's defined in the patch #1 of this series).

Sorry about that, I have dropped the patch.


From horms at verge.net.au  Thu Apr 18 22:16:30 2013
From: horms at verge.net.au (Simon Horman)
Date: Fri, 19 Apr 2013 11:16:30 +0900
Subject: [PATCH v2 1/2] ARM: shmobile: R8A7779: add Ether support
In-Reply-To: <51702FAE.4040104@cogentembedded.com>
References: <201304042253.50662.sergei.shtylyov@cogentembedded.com>
 <20130418153611.GX14496@n2100.arm.linux.org.uk>
 <51702FAE.4040104@cogentembedded.com>
Message-ID: <20130419021630.GE25718@verge.net.au>

On Thu, Apr 18, 2013 at 09:38:54PM +0400, Sergei Shtylyov wrote:
> Hello.
> 
> On 18-04-2013 19:36, Russell King - ARM Linux wrote:
> 
> >>+/* Ether */
> >>+static struct resource ether_resources[] = {
> >>+	{
> >>+		.start	= 0xfde00000,
> >>+		.end	= 0xfde003ff,
> >>+		.flags	= IORESOURCE_MEM,
> >>+	}, {
> >>+		.start	= gic_iid(0xb4),
> >>+		.flags	= IORESOURCE_IRQ,
> >>+	},
> 
> >There are macros for initializing these which have been around for a
> >few years now.
> 
>    I know, I know, just didn't know they're that old.
> 
> >Please consider using them in future.
> 
>    This file uses the old style resource intializers generally, it
> just needs wholesale conversion.

I'd be happy to review such a patch.


From horms at verge.net.au  Thu Apr 18 22:17:55 2013
From: horms at verge.net.au (Simon Horman)
Date: Fri, 19 Apr 2013 11:17:55 +0900
Subject: [PATCH 1/8] ARM: shmobile:Marzen: move USB EHCI, OHCI, and PHY
 devices to R8A7779 code
In-Reply-To: <5170301B.3030306@cogentembedded.com>
References: <201304050257.00799.sergei.shtylyov@cogentembedded.com>
 <20130418154425.GZ14496@n2100.arm.linux.org.uk>
 <5170301B.3030306@cogentembedded.com>
Message-ID: <20130419021755.GF25718@verge.net.au>

On Thu, Apr 18, 2013 at 09:40:43PM +0400, Sergei Shtylyov wrote:
> Hello.
> 
> On 18-04-2013 19:44, Russell King - ARM Linux wrote:
> 
> >>+/* USB PHY */
> >>+static struct resource usb_phy_resources[] = {
> >>+	[0] = {
> >>+		.start		= 0xffe70000,
> >>+		.end		= 0xffe70900 - 1,
> >>+		.flags		= IORESOURCE_MEM,
> >>+	},
> >>+	[1] = {
> >>+		.start		= 0xfff70000,
> >>+		.end		= 0xfff70900 - 1,
> >>+		.flags		= IORESOURCE_MEM,
> >>+	},
> 
> >Please consider using the macros for these initialisers.
> 
>    I'm just moving the code as is here. The destination file still
> uses old style initializers, and probably needs the wholesale
> conversion patch in the future.

My preference is for you to either convert these users in this patch or
provide a patch that makes a wholesale conversion.


From robherring2 at gmail.com  Thu Apr 18 23:06:46 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Thu, 18 Apr 2013 22:06:46 -0500
Subject: linux-next ARM multi-platform randconfig errors
Message-ID: <5170B4C6.1030300@gmail.com>

Current errors in linux-next for ARM multi-platform randconfig builds.

Rob

arch/arm/mach-omap2/built-in.o:dss-common.c:(.init.text+0x6830): more undefined references to `usb_bind_phy' follow
board-paz00.c:(.text+0x1ecc): undefined reference to `cpu_do_idle'
board-paz00.c:(.text+0x1f4c): undefined reference to `cpu_do_idle'
drivers/built-in.o:(.data+0x327b8): undefined reference to `cpufreq_freq_attr_scaling_available_freqs'
drivers/built-in.o:(.data+0x9ae0): undefined reference to `uart_console_device'
board-paz00.c:(.text+0x1ecc): undefined reference to `cpu_do_idle'
board-paz00.c:(.text+0x1f4c): undefined reference to `cpu_do_idle'
drivers/built-in.o:(.data+0x327b8): undefined reference to `cpufreq_freq_attr_scaling_available_freqs'
drivers/built-in.o:(.data+0x9ae0): undefined reference to `uart_console_device'
drivers/built-in.o:drivers/md/dm-cache-target.c:429: more undefined references to `__udivdi3' follow
dss-common.c:(.cpuinit.text+0x38): undefined reference to `omap_get_wakeupgen_base'
dss-common.c:(.cpuinit.text+0x48): undefined reference to `omap_secure_apis_support'
dss-common.c:(.init.text+0x3db0): undefined reference to `omap_get_wakeupgen_base'
dss-common.c:(.init.text+0x3dcc): undefined reference to `omap_secure_apis_support'
dss-common.c:(.init.text+0x61b8): undefined reference to `usb_bind_phy'
dss-common.c:(.init.text+0x6314): undefined reference to `usb_bind_phy'
dss-common.c:(.init.text+0x6488): undefined reference to `usb_bind_phy'
dss-common.c:(.init.text+0x65ac): undefined reference to `usb_bind_phy'
dss-common.c:(.ref.text+0x10): undefined reference to `omap_get_wakeupgen_base'
dss-common.c:(.ref.text+0x18): undefined reference to `omap_secure_apis_support'
dss-common.c:(.ref.text+0x54): undefined reference to `omap4_hotplug_cpu'
dss-common.c:(.ref.text+0x58): undefined reference to `omap_secure_apis_support'
dss-common.c:(.text+0x11b5c): undefined reference to `usb_bind_phy'
ERROR: "of_get_next_parent" [drivers/media/v4l2-core/videodev.ko] undefined!
extcon-class.c:(.text+0x4ac4): undefined reference to `abx500_mask_and_set_register_interruptible'
extcon-class.c:(.text+0x4b34): undefined reference to `abx500_mask_and_set_register_interruptible'
extcon-class.c:(.text+0x5164): undefined reference to `abx500_get_register_interruptible'
extcon-class.c:(.text+0x52b4): undefined reference to `abx500_mask_and_set_register_interruptible'
extcon-class.c:(.text+0x5304): undefined reference to `abx500_mask_and_set_register_interruptible'
extcon-class.c:(.text+0x57a4): undefined reference to `abx500_get_register_interruptible'
platform-spi_imx.c:(.init.text+0x4a20): undefined reference to `reset_controller_register'
platform-spi_imx.c:(.init.text+0x677c): undefined reference to `reset_controller_register'
platform-spi_imx.c:(.init.text+0x70c4): undefined reference to `reset_controller_register'
platform-spi_imx.c:(.init.text+0x825c): undefined reference to `reset_controller_register'
platform-spi_imx.c:(.text+0x1ff0): undefined reference to `otg_ulpi_create'
tegra30-mc.c:(.exit.text+0x144): undefined reference to `uart_unregister_driver'
tegra30-mc.c:(.init.text+0x1e4c): undefined reference to `uart_register_driver'
tegra30-mc.c:(.init.text+0x1e6c): undefined reference to `uart_unregister_driver'
tegra30-mc.c:(.init.text+0x1ee0): undefined reference to `uart_parse_options'
tegra30-mc.c:(.init.text+0x1f04): undefined reference to `uart_set_options'
tegra30-mc.c:(.text+0x309d8): undefined reference to `uart_resume_port'
tegra30-mc.c:(.text+0x309fc): undefined reference to `uart_suspend_port'
tegra30-mc.c:(.text+0x30a94): undefined reference to `uart_handle_dcd_change'
tegra30-mc.c:(.text+0x30aa8): undefined reference to `uart_handle_cts_change'
tegra30-mc.c:(.text+0x30e5c): undefined reference to `uart_console_write'
tegra30-mc.c:(.text+0x31008): undefined reference to `uart_remove_one_port'
tegra30-mc.c:(.text+0x315b0): undefined reference to `do_SAK'
tegra30-mc.c:(.text+0x3161c): undefined reference to `uart_insert_char'
tegra30-mc.c:(.text+0x317d0): undefined reference to `uart_get_baud_rate'
tegra30-mc.c:(.text+0x318bc): undefined reference to `uart_update_timeout'
tegra30-mc.c:(.text+0x32c94): undefined reference to `uart_add_one_port'
tegra30-mc.c:(.text+0x32e94): undefined reference to `uart_write_wakeup'
tegra30-mc.c:(.text+0x33008): undefined reference to `uart_insert_char'
tegra30-mc.c:(.text+0x33030): undefined reference to `tty_flip_buffer_push'
/var/lib/jenkins/jobs/linux-randconfig/workspace/arch/arm/include/asm/kvm_vgic.h:59:11: error: 'CONFIG_KVM_ARM_MAX_VCPUS' undeclared here (not in a function)
/var/lib/jenkins/jobs/linux-randconfig/workspace/arch/arm/mach-imx/src.c:144: undefined reference to `reset_controller_register'
/var/lib/jenkins/jobs/linux-randconfig/workspace/arch/arm/mach-omap2/gpio.c:133: undefined reference to `pwrdm_can_ever_lose_context'
/var/lib/jenkins/jobs/linux-randconfig/workspace/arch/arm/mach-omap2/omap-hotplug.c:33: undefined reference to `omap_get_wakeupgen_base'
/var/lib/jenkins/jobs/linux-randconfig/workspace/arch/arm/mach-omap2/omap-hotplug.c:38: undefined reference to `omap_secure_apis_support'
/var/lib/jenkins/jobs/linux-randconfig/workspace/arch/arm/mach-omap2/omap-hotplug.c:50: undefined reference to `omap4_hotplug_cpu'
/var/lib/jenkins/jobs/linux-randconfig/workspace/arch/arm/mach-omap2/omap-hotplug.c:52: undefined reference to `omap_secure_apis_support'
/var/lib/jenkins/jobs/linux-randconfig/workspace/arch/arm/mach-omap2/omap_hwmod.c:2145: undefined reference to `clkdm_in_hwsup'
/var/lib/jenkins/jobs/linux-randconfig/workspace/arch/arm/mach-omap2/omap_hwmod.c:2146: undefined reference to `clkdm_missing_idle_reporting'
/var/lib/jenkins/jobs/linux-randconfig/workspace/arch/arm/mach-omap2/omap_hwmod.c:2147: undefined reference to `clkdm_hwmod_enable'
/var/lib/jenkins/jobs/linux-randconfig/workspace/arch/arm/mach-omap2/omap_hwmod.c:2191: undefined reference to `clkdm_hwmod_disable'
/var/lib/jenkins/jobs/linux-randconfig/workspace/arch/arm/mach-omap2/omap_hwmod.c:2235: undefined reference to `clkdm_hwmod_disable'
/var/lib/jenkins/jobs/linux-randconfig/workspace/arch/arm/mach-omap2/omap_hwmod.c:2338: undefined reference to `clkdm_hwmod_disable'
/var/lib/jenkins/jobs/linux-randconfig/workspace/arch/arm/mach-omap2/omap_hwmod.c:4071: undefined reference to `pwrdm_get_context_loss_count'
/var/lib/jenkins/jobs/linux-randconfig/workspace/arch/arm/mach-omap2/omap_hwmod.c:691: undefined reference to `clkdm_add_sleepdep'
/var/lib/jenkins/jobs/linux-randconfig/workspace/arch/arm/mach-omap2/omap_hwmod.c:720: undefined reference to `clkdm_del_sleepdep'
/var/lib/jenkins/jobs/linux-randconfig/workspace/arch/arm/mach-omap2/omap-smp.c:204: undefined reference to `omap_get_wakeupgen_base'
/var/lib/jenkins/jobs/linux-randconfig/workspace/arch/arm/mach-omap2/omap-smp.c:224: undefined reference to `omap_secure_apis_support'
/var/lib/jenkins/jobs/linux-randconfig/workspace/arch/arm/mach-omap2/omap-smp.c:80: undefined reference to `omap_get_wakeupgen_base'
/var/lib/jenkins/jobs/linux-randconfig/workspace/arch/arm/mach-omap2/omap-smp.c:94: undefined reference to `omap_secure_apis_support'
/var/lib/jenkins/jobs/linux-randconfig/workspace/arch/arm/mach-omap2/pm.c:114: undefined reference to `clkdm_allow_idle'
/var/lib/jenkins/jobs/linux-randconfig/workspace/arch/arm/mach-omap2/pm.c:117: undefined reference to `clkdm_sleep'
/var/lib/jenkins/jobs/linux-randconfig/workspace/arch/arm/mach-omap2/pm.c:294: undefined reference to `omap_voltage_late_init'
/var/lib/jenkins/jobs/linux-randconfig/workspace/arch/arm/mach-omap2/pm-debug.c:102: undefined reference to `pwrdm_read_pwrst'
/var/lib/jenkins/jobs/linux-randconfig/workspace/arch/arm/mach-omap2/pm-debug.c:103: undefined reference to `pwrdm_read_pwrst'
/var/lib/jenkins/jobs/linux-randconfig/workspace/arch/arm/mach-omap2/pm-debug.c:132: undefined reference to `pwrdm_state_switch'
/var/lib/jenkins/jobs/linux-randconfig/workspace/arch/arm/mach-omap2/pm-debug.c:147: undefined reference to `pwrdm_for_each'
/var/lib/jenkins/jobs/linux-randconfig/workspace/arch/arm/mach-omap2/pm-debug.c:148: undefined reference to `clkdm_for_each'
/var/lib/jenkins/jobs/linux-randconfig/workspace/arch/arm/mach-omap2/pm-debug.c:155: undefined reference to `pwrdm_for_each'
/var/lib/jenkins/jobs/linux-randconfig/workspace/arch/arm/mach-omap2/pm-debug.c:272: undefined reference to `pwrdm_for_each'
/var/lib/jenkins/jobs/linux-randconfig/workspace/arch/arm/mach-spear/platsmp.c:111:58: error: 'SYS_LOCATION' undeclared (first use in this function)
/var/lib/jenkins/jobs/linux-randconfig/workspace/arch/arm/mach-spear/platsmp.c:25:33: error: 'VA_SCU_BASE' undeclared here (not in a function)
/var/lib/jenkins/jobs/linux-randconfig/workspace/arch/arm/mach-tegra/sleep-tegra20.S:200: undefined reference to `cpu_do_idle'
/var/lib/jenkins/jobs/linux-randconfig/workspace/arch/arm/mach-tegra/sleep-tegra30.S:69: Error: shift must be constant -- `orr r12,r12,r4,lsl r3'
/var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/clk/ux500/clk-prcc.c:145:13: error: conflicting types for 'clk_reg_prcc_pclk'
/var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/clk/ux500/clk-prcc.c:155:13: error: conflicting types for 'clk_reg_prcc_kclk'
/var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/cpufreq/arm_big_little.c:101:3: error: too few arguments to function 'cpufreq_notify_transition'
/var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/cpufreq/arm_big_little.c:234:2: error: unknown field 'have_multiple_policies' specified in initializer
/var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/cpufreq/arm_big_little.c:90:3: error: too few arguments to function 'cpufreq_notify_transition'
/var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/cpufreq/spear-cpufreq.c:120: undefined reference to `cpufreq_frequency_table_target'
/var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/cpufreq/spear-cpufreq.c:181: undefined reference to `cpufreq_frequency_table_cpuinfo'
/var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/cpufreq/spear-cpufreq.c:187: undefined reference to `cpufreq_frequency_table_get_attr'
/var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/cpufreq/spear-cpufreq.c:198: undefined reference to `cpufreq_frequency_table_put_attr'
/var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/cpufreq/spear-cpufreq.c:35: undefined reference to `cpufreq_frequency_table_verify'
/var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/md/dm-cache-target.c:429: undefined reference to `__udivdi3'
/var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/md/dm-cache-target.c:429: undefined reference to `__umoddi3'
/var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/mfd/ab8500-debugfs.c:95:23: fatal error: mach/irqs.h: No such file or directory
/var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/misc/spear13xx_pcie_gadget.c:23:23: fatal error: mach/pcie.h: No such file or directory
/var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/pinctrl/pinctrl-abx500.c:125: undefined reference to `abx500_get_register_interruptible'
/var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/pinctrl/pinctrl-abx500.c:146: undefined reference to `abx500_mask_and_set_register_interruptible'
/var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/pinctrl/pinctrl-abx500.c:209: undefined reference to `abx500_mask_and_set_register_interruptible'
/var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/pinctrl/pinctrl-abx500.c:730:24: error: storage size of 'param' isn't known
/var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/pinctrl/pinctrl-abx500.c:730:7: error: implicit declaration of function 'pinconf_to_config_param' [-Werror=implicit-function-declaration]
/var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/pinctrl/pinctrl-abx500.c:730:7: error: variable 'param' has initializer but incomplete type
/var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/pinctrl/pinctrl-abx500.c:731:24: error: storage size of 'argument' isn't known
/var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/pinctrl/pinctrl-abx500.c:731:7: error: implicit declaration of function 'pinconf_to_config_argument' [-Werror=implicit-function-declaration]
/var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/pinctrl/pinctrl-abx500.c:731:7: error: variable 'argument' has initializer but incomplete type
/var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/pinctrl/pinctrl-abx500.c:733:2: error: 'PIN_CONFIG_OUTPUT' undeclared (first use in this function)
/var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/pinctrl/pinctrl-abx500.c:742:7: error: 'PIN_CONFIG_BIAS_PULL_DOWN' undeclared (first use in this function)
/var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/staging/android/logger.c:316:4: error: incompatible type for argument 3 of 'get_next_entry_by_uid'
/var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/staging/android/logger.c:483:14: error: incompatible types when assigning to type 'uid_t' from type 'kuid_t'
/var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/staging/android/logger.c:631:4: error: incompatible type for argument 3 of 'get_next_entry_by_uid'
/var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/staging/android/logger.c:686:5: error: incompatible type for argument 3 of 'get_next_entry_by_uid'
/var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/tty/serial/omap-serial.c:1196:14: error: 'struct uart_port' has no member named 'sysrq'
/var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/usb/host/uhci-hcd.c:857:2: error: #error "missing bus glue for uhci-hcd"
/var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/usb/musb/tusb6010.c:1069: undefined reference to `usb_nop_xceiv_register'
/var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/usb/musb/tusb6010.c:1137: undefined reference to `usb_nop_xceiv_unregister'
/var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/usb/phy/phy-tegra-usb.c:638:32: error: 'ulpi_viewport_access_ops' undeclared (first use in this function)
/var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/video/omap2/dss/dpi.c:181:2: error: implicit declaration of function 'dsi_hsdiv_calc' [-Werror=implicit-function-declaration]
/var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/video/omap2/dss/dpi.c:201:2: error: implicit declaration of function 'dsi_get_pll_clkin' [-Werror=implicit-function-declaration]
/var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/video/omap2/dss/dpi.c:212:2: error: implicit declaration of function 'dsi_pll_calc' [-Werror=implicit-function-declaration]
/var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/xen/swiotlb-xen.c:105:2: error: implicit declaration of function 'mfn_to_local_pfn' [-Werror=implicit-function-declaration]
/var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/xen/swiotlb-xen.c:286:3: error: implicit declaration of function 'dma_alloc_coherent_mask' [-Werror=implicit-function-declaration]
/var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/xen/swiotlb-xen.c:352:2: error: implicit declaration of function 'dma_capable' [-Werror=implicit-function-declaration]
/var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/xen/swiotlb-xen.c:406:2: error: implicit declaration of function 'dma_mark_clean' [-Werror=implicit-function-declaration]
/var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/xen/swiotlb-xen.c:507:11: error: 'struct scatterlist' has no member named 'dma_length'
/var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/xen/swiotlb-xen.c:513:5: error: 'struct scatterlist' has no member named 'dma_length'
/var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/xen/swiotlb-xen.c:534:46: error: 'struct scatterlist' has no member named 'dma_length'
/var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/xen/swiotlb-xen.c:556:8: error: 'struct scatterlist' has no member named 'dma_length'
/var/lib/jenkins/jobs/linux-randconfig/workspace/include/linux/cpu_cooling.h:58:1: error: parameter name omitted
/var/lib/jenkins/jobs/linux-randconfig/workspace/include/linux/cpu_cooling.h:59:8: error: parameter name omitted
WARNING: vmlinux.o(.text+0x12b54): Section mismatch in reference from the function bcm_kona_smc_init() to the (unknown reference) .init.rodata:(unknown)

driversdrivers/md/dm-cache-target.c:429: more undefined references to `__udivdi3' follow
dss-common.c:(.cpuinit.text+0x38): undefined reference to `omap_get_wakeupgen_base'
dss-common.c:(.cpuinit.text+0x48): undefined reference to `omap_secure_apis_support'
dss-common.c:(.init.text+0x3db0): undefined reference to `omap_get_wakeupgen_base'
dss-common.c:(.init.text+0x3dcc): undefined reference to `omap_secure_apis_support'
dss-common.c:(.init.text+0x61b8): undefined reference to `usb_bind_phy'
dss-common.c:(.init.text+0x6314): undefined reference to `usb_bind_phy'
dss-common.c:(.init.text+0x6488): undefined reference to `usb_bind_phy'
dss-common.c:(.init.text+0x65ac): undefined reference to `usb_bind_phy'
dss-common.c:(.ref.text+0x10): undefined reference to `omap_get_wakeupgen_base'
dss-common.c:(.ref.text+0x18): undefined reference to `omap_secure_apis_support'
dss-common.c:(.ref.text+0x54): undefined reference to `omap4_hotplug_cpu'
dss-common.c:(.ref.text+0x58): undefined reference to `omap_secure_apis_support'
dss-common.c:(.text+0x11b5c): undefined reference to `usb_bind_phy'
ERROR: "of_get_next_parent" [drivers/media/v4l2-core/videodev.ko] undefined!
extcon-class.c:(.text+0x4ac4): undefined reference to `abx500_mask_and_set_register_interruptible'
extcon-class.c:(.text+0x4b34): undefined reference to `abx500_mask_and_set_register_interruptible'
extcon-class.c:(.text+0x5164): undefined reference to `abx500_get_register_interruptible'
extcon-class.c:(.text+0x52b4): undefined reference to `abx500_mask_and_set_register_interruptible'
extcon-class.c:(.text+0x5304): undefined reference to `abx500_mask_and_set_register_interruptible'
extcon-class.c:(.text+0x57a4): undefined reference to `abx500_get_register_interruptible'
platform-spi_imx.c:(.init.text+0x4a20): undefined reference to `reset_controller_register'
platform-spi_imx.c:(.init.text+0x677c): undefined reference to `reset_controller_register'
platform-spi_imx.c:(.init.text+0x70c4): undefined reference to `reset_controller_register'
platform-spi_imx.c:(.init.text+0x825c): undefined reference to `reset_controller_register'
platform-spi_imx.c:(.text+0x1ff0): undefined reference to `otg_ulpi_create'
tegra30-mc.c:(.exit.text+0x144): undefined reference to `uart_unregister_driver'
tegra30-mc.c:(.init.text+0x1e4c): undefined reference to `uart_register_driver'
tegra30-mc.c:(.init.text+0x1e6c): undefined reference to `uart_unregister_driver'
tegra30-mc.c:(.init.text+0x1ee0): undefined reference to `uart_parse_options'
tegra30-mc.c:(.init.text+0x1f04): undefined reference to `uart_set_options'
tegra30-mc.c:(.text+0x309d8): undefined reference to `uart_resume_port'
tegra30-mc.c:(.text+0x309fc): undefined reference to `uart_suspend_port'
tegra30-mc.c:(.text+0x30a94): undefined reference to `uart_handle_dcd_change'
tegra30-mc.c:(.text+0x30aa8): undefined reference to `uart_handle_cts_change'
tegra30-mc.c:(.text+0x30e5c): undefined reference to `uart_console_write'
tegra30-mc.c:(.text+0x31008): undefined reference to `uart_remove_one_port'
tegra30-mc.c:(.text+0x315b0): undefined reference to `do_SAK'
tegra30-mc.c:(.text+0x3161c): undefined reference to `uart_insert_char'
tegra30-mc.c:(.text+0x317d0): undefined reference to `uart_get_baud_rate'
tegra30-mc.c:(.text+0x318bc): undefined reference to `uart_update_timeout'
tegra30-mc.c:(.text+0x32c94): undefined reference to `uart_add_one_port'
tegra30-mc.c:(.text+0x32e94): undefined reference to `uart_write_wakeup'
tegra30-mc.c:(.text+0x33008): undefined reference to `uart_insert_char'
tegra30-mc.c:(.text+0x33030): undefined reference to `tty_flip_buffer_push'
arch/arm/include/asm/kvm_vgic.h:59:11: error: 'CONFIG_KVM_ARM_MAX_VCPUS' undeclared here (not in a function)
arch/arm/mach-imx/src.c:144: undefined reference to `reset_controller_register'
arch/arm/mach-omap2/gpio.c:133: undefined reference to `pwrdm_can_ever_lose_context'
arch/arm/mach-omap2/omap-hotplug.c:33: undefined reference to `omap_get_wakeupgen_base'
arch/arm/mach-omap2/omap-hotplug.c:38: undefined reference to `omap_secure_apis_support'
arch/arm/mach-omap2/omap-hotplug.c:50: undefined reference to `omap4_hotplug_cpu'
arch/arm/mach-omap2/omap-hotplug.c:52: undefined reference to `omap_secure_apis_support'
arch/arm/mach-omap2/omap_hwmod.c:2145: undefined reference to `clkdm_in_hwsup'
arch/arm/mach-omap2/omap_hwmod.c:2146: undefined reference to `clkdm_missing_idle_reporting'
arch/arm/mach-omap2/omap_hwmod.c:2147: undefined reference to `clkdm_hwmod_enable'
arch/arm/mach-omap2/omap_hwmod.c:2191: undefined reference to `clkdm_hwmod_disable'
arch/arm/mach-omap2/omap_hwmod.c:2235: undefined reference to `clkdm_hwmod_disable'
arch/arm/mach-omap2/omap_hwmod.c:2338: undefined reference to `clkdm_hwmod_disable'
arch/arm/mach-omap2/omap_hwmod.c:4071: undefined reference to `pwrdm_get_context_loss_count'
arch/arm/mach-omap2/omap_hwmod.c:691: undefined reference to `clkdm_add_sleepdep'
arch/arm/mach-omap2/omap_hwmod.c:720: undefined reference to `clkdm_del_sleepdep'
arch/arm/mach-omap2/omap-smp.c:204: undefined reference to `omap_get_wakeupgen_base'
arch/arm/mach-omap2/omap-smp.c:224: undefined reference to `omap_secure_apis_support'
arch/arm/mach-omap2/omap-smp.c:80: undefined reference to `omap_get_wakeupgen_base'
arch/arm/mach-omap2/omap-smp.c:94: undefined reference to `omap_secure_apis_support'
arch/arm/mach-omap2/pm.c:114: undefined reference to `clkdm_allow_idle'
arch/arm/mach-omap2/pm.c:117: undefined reference to `clkdm_sleep'
arch/arm/mach-omap2/pm.c:294: undefined reference to `omap_voltage_late_init'
arch/arm/mach-omap2/pm-debug.c:102: undefined reference to `pwrdm_read_pwrst'
arch/arm/mach-omap2/pm-debug.c:103: undefined reference to `pwrdm_read_pwrst'
arch/arm/mach-omap2/pm-debug.c:132: undefined reference to `pwrdm_state_switch'
arch/arm/mach-omap2/pm-debug.c:147: undefined reference to `pwrdm_for_each'
arch/arm/mach-omap2/pm-debug.c:148: undefined reference to `clkdm_for_each'
arch/arm/mach-omap2/pm-debug.c:155: undefined reference to `pwrdm_for_each'
arch/arm/mach-omap2/pm-debug.c:272: undefined reference to `pwrdm_for_each'
arch/arm/mach-spear/platsmp.c:111:58: error: 'SYS_LOCATION' undeclared (first use in this function)
arch/arm/mach-spear/platsmp.c:25:33: error: 'VA_SCU_BASE' undeclared here (not in a function)
arch/arm/mach-tegra/sleep-tegra20.S:200: undefined reference to `cpu_do_idle'
arch/arm/mach-tegra/sleep-tegra30.S:69: Error: shift must be constant -- `orr r12,r12,r4,lsl r3'
drivers/clk/ux500/clk-prcc.c:145:13: error: conflicting types for 'clk_reg_prcc_pclk'
drivers/clk/ux500/clk-prcc.c:155:13: error: conflicting types for 'clk_reg_prcc_kclk'
drivers/cpufreq/arm_big_little.c:101:3: error: too few arguments to function 'cpufreq_notify_transition'
drivers/cpufreq/arm_big_little.c:234:2: error: unknown field 'have_multiple_policies' specified in initializer
drivers/cpufreq/arm_big_little.c:90:3: error: too few arguments to function 'cpufreq_notify_transition'
drivers/cpufreq/spear-cpufreq.c:120: undefined reference to `cpufreq_frequency_table_target'
drivers/cpufreq/spear-cpufreq.c:181: undefined reference to `cpufreq_frequency_table_cpuinfo'
drivers/cpufreq/spear-cpufreq.c:187: undefined reference to `cpufreq_frequency_table_get_attr'
drivers/cpufreq/spear-cpufreq.c:198: undefined reference to `cpufreq_frequency_table_put_attr'
drivers/cpufreq/spear-cpufreq.c:35: undefined reference to `cpufreq_frequency_table_verify'
drivers/md/dm-cache-target.c:429: undefined reference to `__udivdi3'
drivers/md/dm-cache-target.c:429: undefined reference to `__umoddi3'
drivers/mfd/ab8500-debugfs.c:95:23: fatal error: mach/irqs.h: No such file or directory
drivers/misc/spear13xx_pcie_gadget.c:23:23: fatal error: mach/pcie.h: No such file or directory
drivers/pinctrl/pinctrl-abx500.c:125: undefined reference to `abx500_get_register_interruptible'
drivers/pinctrl/pinctrl-abx500.c:146: undefined reference to `abx500_mask_and_set_register_interruptible'
drivers/pinctrl/pinctrl-abx500.c:209: undefined reference to `abx500_mask_and_set_register_interruptible'
drivers/pinctrl/pinctrl-abx500.c:730:24: error: storage size of 'param' isn't known
drivers/pinctrl/pinctrl-abx500.c:730:7: error: implicit declaration of function 'pinconf_to_config_param' [-Werror=implicit-function-declaration]
drivers/pinctrl/pinctrl-abx500.c:730:7: error: variable 'param' has initializer but incomplete type
drivers/pinctrl/pinctrl-abx500.c:731:24: error: storage size of 'argument' isn't known
drivers/pinctrl/pinctrl-abx500.c:731:7: error: implicit declaration of function 'pinconf_to_config_argument' [-Werror=implicit-function-declaration]
drivers/pinctrl/pinctrl-abx500.c:731:7: error: variable 'argument' has initializer but incomplete type
drivers/pinctrl/pinctrl-abx500.c:733:2: error: 'PIN_CONFIG_OUTPUT' undeclared (first use in this function)
drivers/pinctrl/pinctrl-abx500.c:742:7: error: 'PIN_CONFIG_BIAS_PULL_DOWN' undeclared (first use in this function)
drivers/staging/android/logger.c:316:4: error: incompatible type for argument 3 of 'get_next_entry_by_uid'
drivers/staging/android/logger.c:483:14: error: incompatible types when assigning to type 'uid_t' from type 'kuid_t'
drivers/staging/android/logger.c:631:4: error: incompatible type for argument 3 of 'get_next_entry_by_uid'
drivers/staging/android/logger.c:686:5: error: incompatible type for argument 3 of 'get_next_entry_by_uid'
drivers/tty/serial/omap-serial.c:1196:14: error: 'struct uart_port' has no member named 'sysrq'
drivers/usb/host/uhci-hcd.c:857:2: error: #error "missing bus glue for uhci-hcd"
drivers/usb/musb/tusb6010.c:1069: undefined reference to `usb_nop_xceiv_register'
drivers/usb/musb/tusb6010.c:1137: undefined reference to `usb_nop_xceiv_unregister'
drivers/usb/phy/phy-tegra-usb.c:638:32: error: 'ulpi_viewport_access_ops' undeclared (first use in this function)
drivers/video/omap2/dss/dpi.c:181:2: error: implicit declaration of function 'dsi_hsdiv_calc' [-Werror=implicit-function-declaration]
drivers/video/omap2/dss/dpi.c:201:2: error: implicit declaration of function 'dsi_get_pll_clkin' [-Werror=implicit-function-declaration]
drivers/video/omap2/dss/dpi.c:212:2: error: implicit declaration of function 'dsi_pll_calc' [-Werror=implicit-function-declaration]
drivers/xen/swiotlb-xen.c:105:2: error: implicit declaration of function 'mfn_to_local_pfn' [-Werror=implicit-function-declaration]
drivers/xen/swiotlb-xen.c:286:3: error: implicit declaration of function 'dma_alloc_coherent_mask' [-Werror=implicit-function-declaration]
drivers/xen/swiotlb-xen.c:352:2: error: implicit declaration of function 'dma_capable' [-Werror=implicit-function-declaration]
drivers/xen/swiotlb-xen.c:406:2: error: implicit declaration of function 'dma_mark_clean' [-Werror=implicit-function-declaration]
drivers/xen/swiotlb-xen.c:507:11: error: 'struct scatterlist' has no member named 'dma_length'
drivers/xen/swiotlb-xen.c:513:5: error: 'struct scatterlist' has no member named 'dma_length'
drivers/xen/swiotlb-xen.c:534:46: error: 'struct scatterlist' has no member named 'dma_length'
drivers/xen/swiotlb-xen.c:556:8: error: 'struct scatterlist' has no member named 'dma_length'
include/linux/cpu_cooling.h:58:1: error: parameter name omitted
include/linux/cpu_cooling.h:59:8: error: parameter name omitted
WARNING: arch/arm/mach-bcm/built-in.o(.text+0x104): Section mismatch in reference from the function bcm_kona_smc_init() to the (unknown reference) .init.rodata:(unknown)



From festevam at gmail.com  Fri Apr 19 00:17:44 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Fri, 19 Apr 2013 01:17:44 -0300
Subject: [PATCH V3] ARM: i.MX5: Allow DT clock providers
In-Reply-To: <20130418161424.GI1906@pengutronix.de>
References: <20130418155510.26908.61334.stgit@localhost>
 <20130418161424.GI1906@pengutronix.de>
Message-ID: <CAOMZO5BKCvjOP6i7kcqqnd-TfSezWN3qQ942Bok8iW+3u5mwPA@mail.gmail.com>

On Thu, Apr 18, 2013 at 1:14 PM, Sascha Hauer <s.hauer at pengutronix.de> wrote:
> On Thu, Apr 18, 2013 at 05:55:10PM +0200, Martin Fuzzey wrote:
>> Currently clock providers defined in the DT are not registered
>> on i.MX5 platforms since of_clk_init() is not called.
>>
>> This is not a problem for the SOC's own clocks, which are registered
>> in code,  but prevents the DT being used to define clocks for external
>> hardware.
>>
>> Fix this by calling of_clk_init() and actually using the DT to obtain
>> the 4 SOC fixed clocks.
>> These are already defined in the DT but were previously just used to
>> manually obtain the rate.
>>
>> Fall back to the old scheme for non DT platforms.
>>
>> Signed-off-by: Martin Fuzzey <mfuzzey at parkeon.com>

On a mx51evk:

Tested-by: Fabio Estevam <fabio.estevam at freescale.com>

> I just realized that this is useful for other i.MX aswell. How about
> renaming it to imx_obtain_fixed_clk() and move it to
> arch/arm/mach-imx/clk.c?

Exactly. I was about to make the same suggestion.


From linux at roeck-us.net  Fri Apr 19 00:35:55 2013
From: linux at roeck-us.net (Guenter Roeck)
Date: Thu, 18 Apr 2013 21:35:55 -0700
Subject: [PATCH 1/3] Add support for GMT G72/G763 PWM fan controller
In-Reply-To: <4f4a821bbc61e2da28fd70553fd717ada255097d.1366322287.git.arno@natisbad.org>
References: <cover.1366322287.git.arno@natisbad.org>
 <4f4a821bbc61e2da28fd70553fd717ada255097d.1366322287.git.arno@natisbad.org>
Message-ID: <20130419043555.GA14124@roeck-us.net>

On Fri, Apr 19, 2013 at 12:28:21AM +0200, Arnaud Ebalard wrote:
> 
> Signed-off-by: Arnaud Ebalard <arno at natisbad.org>
> Tested-by: Arnaud Ebalard <arno at natisbad.org>
> ---
>  drivers/hwmon/Kconfig  |   10 +
>  drivers/hwmon/Makefile |    1 +
>  drivers/hwmon/g762.c   | 1159 ++++++++++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 1170 insertions(+)
>  create mode 100644 drivers/hwmon/g762.c
> 
checkpatch says:

total: 1 errors, 15 warnings, 0 checks, 1182 lines checked

Please fix those. Also, please make sure there are spaces around operators.

Additional comments inline. This is not a complete review; I gave up after
a while. Please fix the problems and resubmit.

> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
> index 89ac1cb..0c6ddee 100644
> --- a/drivers/hwmon/Kconfig
> +++ b/drivers/hwmon/Kconfig
> @@ -423,6 +423,16 @@ config SENSORS_G760A
>  	  This driver can also be built as a module.  If so, the module
>  	  will be called g760a.
>  
> +config SENSORS_G762
> +	tristate "GMT G762"
> +	depends on I2C
> +	help
> +	  If you say yes here you get support for Global Mixed-mode
> +	  Technology Inc G762 fan speed PWM controller chips.
> +
> +	  This driver can also be built as a module.  If so, the module
> +	  will be called g762a.
> +
>  config SENSORS_GL518SM
>  	tristate "Genesys Logic GL518SM"
>  	depends on I2C
> diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
> index 8d6d97e..4b49504 100644
> --- a/drivers/hwmon/Makefile
> +++ b/drivers/hwmon/Makefile
> @@ -57,6 +57,7 @@ obj-$(CONFIG_SENSORS_F75375S)	+= f75375s.o
>  obj-$(CONFIG_SENSORS_FAM15H_POWER) += fam15h_power.o
>  obj-$(CONFIG_SENSORS_FSCHMD)	+= fschmd.o
>  obj-$(CONFIG_SENSORS_G760A)	+= g760a.o
> +obj-$(CONFIG_SENSORS_G762)	+= g762.o
>  obj-$(CONFIG_SENSORS_GL518SM)	+= gl518sm.o
>  obj-$(CONFIG_SENSORS_GL520SM)	+= gl520sm.o
>  obj-$(CONFIG_SENSORS_GPIO_FAN)	+= gpio-fan.o
> diff --git a/drivers/hwmon/g762.c b/drivers/hwmon/g762.c
> new file mode 100644
> index 0000000..8c4cb39
> --- /dev/null
> +++ b/drivers/hwmon/g762.c
> @@ -0,0 +1,1159 @@
> +/*
> + * g762 - Driver for the Global Mixed-mode Technology Inc. fan speed PWM
> + *        controller chips from G762 family, i.e. G762 and G763
> + *
> + * Copyright (C) 2013, Arnaud EBALARD <arno at natisbad.org>
> + *
> + * This work is based on a basic version for 2.6.31 kernel developed
> + * by Olivier Mouchet for LaCie NAS. Updates have been performed to run
> + * on recent kernels. Supported has been completed and additional
> + * features added: ability to configure various characteristics from
> + * .dts file, better initialization, alarms and error reporting support,
> + * gear mode, polarity, fan pulse per revolution, fan startup voltage
> + * control. The following detailed datasheet has been used as a basis
> + * for this work:
> + *
> + *  http://natisbad.org/NAS/refs/GMT_EDS-762_763-080710-0.2.pdf
> + *
> + * Headers from previous developments have been kept below:
> + *
> + * Copyright (c) 2009 LaCie
> + *
> + * Author: Olivier Mouchet <olivier.mouchet at gmail.com>
> + *
> + * based on g760a code written by Herbert Valerio Riedel <hvr at gnu.org>
> + * Copyright (C) 2007  Herbert Valerio Riedel <hvr at gnu.org>
> + *
> + * g762: minimal datasheet available at:
> + *       http://www.gmt.com.tw/product/datasheet/EDS-762_3.pdf
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
> + */
> +
> +#include <linux/device.h>
> +#include <linux/module.h>
> +#include <linux/init.h>
> +#include <linux/slab.h>
> +#include <linux/jiffies.h>
> +#include <linux/i2c.h>
> +#include <linux/hwmon.h>
> +#include <linux/hwmon-sysfs.h>
> +#include <linux/err.h>
> +#include <linux/mutex.h>
> +#include <linux/kernel.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>
> +
> +#define DRVNAME "g762"
> +
> +static const struct i2c_device_id g762_id[] = {
> +	{ DRVNAME, 0 },
> +	{ }
> +};
> +MODULE_DEVICE_TABLE(i2c, g762_id);
> +
> +enum g762_regs {
> +	G762_REG_SET_CNT  = 0x00,
> +	G762_REG_ACT_CNT  = 0x01,
> +	G762_REG_FAN_STA  = 0x02,
> +	G762_REG_SET_OUT  = 0x03,
> +	G762_REG_FAN_CMD1 = 0x04,
> +	G762_REG_FAN_CMD2 = 0x05,
> +};
> +
> +/* Config register bits */
> +#define G762_REG_FAN_CMD1_DET_FAN_FAIL 	0x80 /* enable fan_fail signal */
> +#define G762_REG_FAN_CMD1_DET_FAN_OOC 	0x40 /* enable fan_out_of_control */
> +#define G762_REG_FAN_CMD1_OUT_MODE 	0x20 /* out mode, pwm or dac */
> +#define G762_REG_FAN_CMD1_FAN_MODE 	0x10 /* fan mode: close or open loop */
> +#define G762_REG_FAN_CMD1_CLK_DIV_ID1   0x08 /* clock divisor value */
> +#define G762_REG_FAN_CMD1_CLK_DIV_ID0 	0x04
> +#define G762_REG_FAN_CMD1_PWM_POLARITY	0x02 /* pwm polarity */
> +#define G762_REG_FAN_CMD1_PULSE_PER_REV	0x01 /* pulse per fan revolution */
> +
> +#define G762_REG_FAN_CMD2_GEAR_MODE_1   0x08 /* fan gear mode */
> +#define G762_REG_FAN_CMD2_GEAR_MODE_0   0x04
> +#define G762_REG_FAN_CMD2_FAN_STARTV_1  0x02 /* fan startup voltage */
> +#define G762_REG_FAN_CMD2_FAN_STARTV_0  0x01
> +
> +#define G762_REG_FAN_STA_FAIL           0x02 /* fan fail */
> +#define G762_REG_FAN_STA_OOC            0x01 /* fan out of control */
> +
> +/* config register values */
> +#define OUT_MODE_PWM 		1
> +#define OUT_MODE_DAC 		0
> +
> +#define FAN_MODE_CLOSED_LOOP 	1
> +#define FAN_MODE_OPEN_LOOP 	0
> +
> +/* g762 default values: it is assumed that the fan is set for a 32KHz clock
> + * source, a fan clock divisor of 1 and two pulses per revolution. Default
> + * fan driving mode is linear mode (g762 also supports PWM mode) */
> +#define G762_DEFAULT_CLK 	    32768
> +#define G762_DEFAULT_FAN_CLK_DIV    1
> +#define G762_DEFAULT_PULSE_PER_REV  2
> +#define G762_DEFAULT_OUT_MODE       0
> +#define G762_DEFAULT_FAN_MODE       1
> +
> +/* register data is read (and cached) at most once per second */
> +#define G762_UPDATE_INTERVAL (HZ)
> +
> +/* extract pulse count per fan revolution value (2 or 4) from given
> + * FAN_CMD1 register value */
> +#define PULSE_FROM_REG(reg) \
> +	(((reg & G762_REG_FAN_CMD1_PULSE_PER_REV)+1) << 1)

Always put ( ) around macro arguments.

> +
> +/* extract fan clock divisor (1, 2, 4 or 8) from given FAN_CMD1
> + * register value */
> +#define CLKDIV_FROM_REG(reg) \
> +	(1 << ((reg & (G762_REG_FAN_CMD1_CLK_DIV_ID0 | \
> +		       G762_REG_FAN_CMD1_CLK_DIV_ID1)) >> 2))
> +
> +/* extract fan gear mode value (0, 1 or 2) from given FAN_CMD2
> + * register value */
> +#define GEARMODE_FROM_REG(reg) \
> +	(1 << ((reg & (G762_REG_FAN_CMD2_GEAR_MODE_0 | \
> +		       G762_REG_FAN_CMD2_GEAR_MODE_1)) >> 2))
> +
> +struct g762_data {
> +	struct i2c_client *client;
> +	struct device *hwmon_dev;
> +
> +	/* update mutex */
> +	struct mutex update_lock;
> +
> +	/* board specific parameters. */
> +	u32 clk; /* default 32kHz */
> +
> +	/* g762 register cache */
> +	unsigned int valid:1;

Please use bool.

> +	unsigned long last_updated; /* in jiffies */
> +
> +	u8 set_cnt;  /* RPM cmd in close loop control */
> +	u8 act_cnt;  /* formula: cnt = (CLK * 30)/(rpm * P) */
> +	u8 fan_sta;  /* bit 0: set when actual fan speed is more than
> +		      *        25% outside requested fan speed
> +		      * bit 1: set when no transition occurs on fan
> +                      *        pin for 0.7s */

Extra line for */, please

> +	u8 set_out;  /* output voltage/PWM duty in open loop control */
> +	u8 fan_cmd1; /*   0: FG_PLS_ID0 FG pulses count per revolution
> +		      *      0: 2 counts per revolution
> +		      *      1: 4 counts per revolution
> +		      *   1: PWM_POLARITY 1: negative_duty
> +		      *                   0: positive_duty
> +		      * 2,3: [FG_CLOCK_ID0, FG_CLK_ID1]
> +		      * 	00: Divide fan clock by 1
> +		      * 	01: Divide fan clock by 2
> +		      * 	10: Divide fan clock by 4
> +		      * 	11: Divide fan clock by 8
> +		      *   4: FAN_MODE 1:close-loop, 0:open-loop
> +		      *   5: OUT_MODE 1:PWM, 0:DAC
> +		      *   6: DET_FAN_OOC enable "fan ooc" status
> +		      *   7: DET_FAN_FAIL enable "fan fail" status */
> +	u8 fan_cmd2; /* 0,1: FAN_STARTV 0,1,2,3 -> 0,32,64,96 dac_code
> +		      * 2,3: FG_GEAR_MODE
> +		      *         00: div = 1
> +		      *         01: div = 2
> +		      *         10: div = 4
> +		      *   4: Mask ALERT# (g763 only) */
> +};
> +
> +/* sysfs PWM interface uses value from 0 to 255 when g762 FAN_SET_CNT register
> + * uses values from 255 (off) to 0 (full speed). */
> +#define PWM_FROM_CNT(cnt)	(0xff-(cnt))
> +#define PWM_TO_CNT(pwm)		(0xff-(pwm))
> +
> +/* Convert count value from fan controller register into fan speed RPM value.
> + * Note that the datasheet documents a basic formula. Influence of additional
> + * parameters have been infered from examples in the datasheet and tests:
> + * fan clock divisor, fan gear mode. */

/*
 * Please follow CodingStyle for multi-line comments
 */

> +static inline unsigned int rpm_from_cnt(u8 cnt,	u32 clk, u16 p,

tab after cnt ?

> +					u8 clk_div, u8 gear_mode)
> +{
> +	if (cnt == 0 || cnt == 0xff)
> +		return 0;
> +
> +	return (clk*30*(gear_mode+1))/(cnt*p*clk_div);
> +}
> +
> +/* Convert fan RPM value from sysfs into count value */
> +static inline unsigned char cnt_from_rpm(u32 rpm, u32 clk, u16 p,
> +					 u8 clk_div, u8 gear_mode)
> +{
> +	return (rpm == 0) ? 0xff : (clk*30*(gear_mode+1))/(rpm*p*clk_div);
> +}
> +
> +#ifdef CONFIG_OF
> +static struct of_device_id g762_dt_match[] = {
> +	{ .compatible = "gmt,g762" },
> +	{ .compatible = "gmt,g763" },
> +	{ },
> +};
> +#endif
> +
> +static int g762_probe(struct i2c_client *client,
> +		      const struct i2c_device_id *id);
> +static int g762_remove(struct i2c_client *client);
> +
Please rearrange the code to not require forward declarations.

> +static struct i2c_driver g762_driver = {
> +	.driver = {
> +		.name = DRVNAME,
> +		.owner = THIS_MODULE,
> +		.of_match_table = of_match_ptr(g762_dt_match),
> +	},
> +	.probe	  = g762_probe,
> +	.remove	  = g762_remove,
> +	.id_table = g762_id,
> +};
> +
> +static inline int g762_read_value(struct i2c_client *client,
> +				  enum g762_regs reg)
> +{
> +	return i2c_smbus_read_byte_data(client, reg);
> +}
> +
> +static inline int g762_write_value(struct i2c_client *client,
> +				   enum g762_regs reg, u16 value)
> +{
> +	return i2c_smbus_write_byte_data(client, reg, value);
> +}
> +
> +/*
> + * sysfs attributes
> + */
> +
> +/* helper to grab and cache data, at most one time per second */
> +static struct g762_data *g762_update_client(struct device *dev)
> +{
> +	struct i2c_client *client = to_i2c_client(dev);
> +	struct g762_data *data = i2c_get_clientdata(client);
> +
> +	mutex_lock(&data->update_lock);
> +	if (time_after(jiffies, data->last_updated + G762_UPDATE_INTERVAL) ||
> +	    unlikely(!data->valid)) {
> +		data->set_cnt =  g762_read_value(client, G762_REG_SET_CNT);
> +		data->act_cnt =  g762_read_value(client, G762_REG_ACT_CNT);
> +		data->fan_sta =  g762_read_value(client, G762_REG_FAN_STA);
> +		data->set_out =  g762_read_value(client, G762_REG_SET_OUT);
> +		data->fan_cmd1 = g762_read_value(client, G762_REG_FAN_CMD1);
> +		data->fan_cmd2 = g762_read_value(client, G762_REG_FAN_CMD2);
> +
> +		data->last_updated = jiffies;
> +		data->valid = 1;
> +	}
> +	mutex_unlock(&data->update_lock);
> +
> +	return data;
> +}
> +
> +/* Read function for fan1_input sysfs file. Return current fan RPM value, or
> + * 0 if fan is out of control */
> +static ssize_t get_fan_rpm(struct device *dev, struct device_attribute *da,
> +			   char *buf)
> +{
> +	struct g762_data *data = g762_update_client(dev);
> +	unsigned int rpm = 0;
> +
> +	mutex_lock(&data->update_lock);
> +	/* reverse logic: fan out of control reporting is enabled low */
> +	if (data->fan_sta & G762_REG_FAN_STA_OOC) {
> +		rpm = rpm_from_cnt(data->act_cnt, data->clk,
> +				   PULSE_FROM_REG(data->fan_cmd1),
> +				   CLKDIV_FROM_REG(data->fan_cmd1),
> +				   GEARMODE_FROM_REG(data->fan_cmd2));
> +	}
> +	mutex_unlock(&data->update_lock);
> +
> +	return sprintf(buf, "%u\n", rpm);
> +}
> +
> +/* Read function for pwm1_mode sysfs file. Get fan speed control
> + * mode i.e. pwm (1) or linear (0) */
> +static ssize_t get_pwm_mode(struct device *dev, struct device_attribute *da,
> +			    char *buf)
> +{
> +	struct g762_data *data = g762_update_client(dev);
> +	int pwm_mode;
> +
> +	pwm_mode = (data->fan_cmd1 & G762_REG_FAN_CMD1_OUT_MODE) ? 1 : 0;
> +
> +	return sprintf(buf, "%d\n", pwm_mode);
> +}
> +
> +static ssize_t do_set_pwm_mode(struct device *dev, u8 val)

Why ssize_t ?

> +{
> +	struct i2c_client *client = to_i2c_client(dev);
> +	struct g762_data *data = g762_update_client(dev);
> +
> +	mutex_lock(&data->update_lock);
> +	switch (val) {
> +	case OUT_MODE_PWM:
> +		data->fan_cmd1 |= G762_REG_FAN_CMD1_OUT_MODE;
> +		break;
> +	case OUT_MODE_DAC: /* i.e. linear */
> +		data->fan_cmd1 &= (u8) ~G762_REG_FAN_CMD1_OUT_MODE;

Unnecessary typecast. Several times.

> +		break;
> +	default:
> +		mutex_unlock(&data->update_lock);
> +		return -EINVAL;
> +	}
> +	g762_write_value(client, G762_REG_FAN_CMD1, data->fan_cmd1);
> +	mutex_unlock(&data->update_lock);
> +
> +	return val;
> +}
> +
> +/* Write function for pwm1_mode sysfs file. Set fan speed control
> + * mode as pwm (1) or linear (0) */
> +static ssize_t set_pwm_mode(struct device *dev, struct device_attribute *da,
> +			    const char *buf, size_t count)
> +{
> +	unsigned long val;
> +	ssize_t ret;

Why ssize_t ?

> +
> +	if (kstrtoul(buf, 10, &val))
> +		return -EINVAL;
> +
> +	ret = do_set_pwm_mode(dev, (u8)val);

No overflow protection ? User writes 256, gets 0 ?

> +	if (ret < 0)
> +		return -EINVAL;
> +
> +	return count;
> +}
> +
> +/* Read function for pwm1_freq sysfs file. */
> +static ssize_t get_pwm_freq(struct device *dev,
> +			    struct device_attribute *da, char *buf)
> +{
> +	struct i2c_client *client = to_i2c_client(dev);
> +	struct g762_data *data = i2c_get_clientdata(client);
> +
> +	return sprintf(buf, "%d\n", data->clk);
> +}
> +
> +/* Write function for pwm1_freq sysfs file. */
> +static ssize_t set_pwm_freq(struct device *dev,
> +			    struct device_attribute *da,
> +			    const char *buf, size_t count)
> +{
> +	struct i2c_client *client = to_i2c_client(dev);
> +	struct g762_data *data = i2c_get_clientdata(client);
> +	unsigned long val;
> +
> +	if (kstrtoul(buf, 10, &val) || !val)
> +		return -EINVAL;
> +
No limits, no overflow protection ?

> +	mutex_lock(&data->update_lock);
> +	data->clk = val;
> +	mutex_unlock(&data->update_lock);

Now that lock is really unnecessary. What is clk for, anyway ? Doesn't it have
to be written into the chip ?

If it is a board specific constant, shouldn't it be provided with platform data
or device tree data instead ? What is the purpose of being able to write it at
runtime ?

> +
> +	return count;
> +}
> +
> +/* Read function for fan1_div sysfs file. Get fan controller prescaler */
> +static ssize_t get_fan_clk_div(struct device *dev,
> +			       struct device_attribute *da, char *buf)
> +{
> +	struct g762_data *data = g762_update_client(dev);
> +
> +	return sprintf(buf, "%d\n", CLKDIV_FROM_REG(data->fan_cmd1));
> +}
> +
> +static ssize_t do_set_fan_clk_div(struct device *dev, u8 val)

Why ssize_t ?

> +{
> +	struct i2c_client *client = to_i2c_client(dev);
> +	struct g762_data *data = g762_update_client(dev);
> +
> +	mutex_lock(&data->update_lock);
> +	switch (val) {
> +	case 1:
> +		data->fan_cmd1 &= (u8) ~G762_REG_FAN_CMD1_CLK_DIV_ID0;
> +		data->fan_cmd1 &= (u8) ~G762_REG_FAN_CMD1_CLK_DIV_ID1;

Unnecessary typecasts.

> +		break;
> +	case 2:
> +		data->fan_cmd1 |= G762_REG_FAN_CMD1_CLK_DIV_ID0;
> +		data->fan_cmd1 &= (u8) ~G762_REG_FAN_CMD1_CLK_DIV_ID1;
> +		break;
> +	case 4:
> +		data->fan_cmd1 &= (u8) ~G762_REG_FAN_CMD1_CLK_DIV_ID0;
> +		data->fan_cmd1 |= G762_REG_FAN_CMD1_CLK_DIV_ID1;
> +		break;
> +	case 8:
> +		data->fan_cmd1 |= G762_REG_FAN_CMD1_CLK_DIV_ID0;
> +		data->fan_cmd1 |= G762_REG_FAN_CMD1_CLK_DIV_ID1;
> +		break;
> +	default:
> +		mutex_unlock(&data->update_lock);
> +		return -EINVAL;
> +	}
> +	g762_write_value(client, G762_REG_FAN_CMD1, (u16)data->fan_cmd1);
> +	mutex_unlock(&data->update_lock);
> +
> +	return val;

What is the purpose of returning val here (instead of returning 0 for no error) ?

> +}
> +
> +/* Write function for fan1_div file. Set fan controller prescaler */
> +static ssize_t set_fan_clk_div(struct device *dev,
> +			       struct device_attribute *da,
> +			       const char *buf, size_t count)
> +{
> +	unsigned long val;
> +	ssize_t ret;

Why ssize_t ?

> +
> +	if (kstrtoul(buf, 10, &val))
> +		return -EINVAL;
> +
No overflow protection ?

> +	ret = do_set_fan_clk_div(dev, (u8) val);
> +	if (ret < 0)
> +		return -EINVAL;
> +
> +	return count;
> +}
> +
> +/* Read function for fan1_gear_mode sysfs file. Get fan gear mode */
> +static ssize_t get_fan_gear_mode(struct device *dev,
> +				 struct device_attribute *da, char *buf)
> +{
> +	struct g762_data *data = g762_update_client(dev);
> +	u8 fan_gear_mode;
> +
> +	fan_gear_mode = data->fan_cmd2 & (G762_REG_FAN_CMD2_GEAR_MODE_0 |
> +					  G762_REG_FAN_CMD2_GEAR_MODE_1);
> +	fan_gear_mode = fan_gear_mode >> 2;
> +
> +	return sprintf(buf, "%d\n", fan_gear_mode);
> +}
> +
> +static ssize_t do_set_fan_gear_mode(struct device *dev, u8 val)
> +{
> +	struct i2c_client *client = to_i2c_client(dev);
> +	struct g762_data *data = g762_update_client(dev);
> +
> +	mutex_lock(&data->update_lock);
> +	switch (val) {
> +	case 0:
> +		data->fan_cmd2 &= (u8) ~G762_REG_FAN_CMD2_GEAR_MODE_0;
> +		data->fan_cmd2 &= (u8) ~G762_REG_FAN_CMD2_GEAR_MODE_1;
> +		break;
> +	case 1:
> +		data->fan_cmd2 |= G762_REG_FAN_CMD2_GEAR_MODE_0;
> +		data->fan_cmd2 &= (u8) ~G762_REG_FAN_CMD2_GEAR_MODE_1;
> +		break;
> +	case 2:
> +		data->fan_cmd2 &= (u8) ~G762_REG_FAN_CMD2_GEAR_MODE_0;
> +		data->fan_cmd2 |= G762_REG_FAN_CMD2_GEAR_MODE_1;
> +		break;
> +	default:
> +		mutex_unlock(&data->update_lock);
> +		return -EINVAL;
> +	}
> +	g762_write_value(client, G762_REG_FAN_CMD2, (u16)data->fan_cmd2);
> +	mutex_unlock(&data->update_lock);
> +
> +	return val;
> +}
> +
> +/* Write function for fan1_gear_mode sysfs file. Write fan gear mode */
> +static ssize_t set_fan_gear_mode(struct device *dev,
> +				 struct device_attribute *da,
> +				 const char *buf, size_t count)
> +{
> +	unsigned long val;
> +	ssize_t ret;

Why ssize_t ?

> +
> +	if (kstrtoul(buf, 10, &val))
> +		return -EINVAL;
> +
> +	ret = do_set_fan_gear_mode(dev, (u8) val);
> +	if (ret < 0)
> +		return -EINVAL;
> +
> +	return count;
> +}
> +
> +/* Read function for fan1_pulses. Returns either 2 or 4 */
> +static ssize_t get_fan_pulses(struct device *dev, struct device_attribute *da,
> +			      char *buf)
> +{
> +	struct g762_data *data = g762_update_client(dev);
> +
> +	return sprintf(buf, "%d\n", PULSE_FROM_REG(data->fan_cmd1));
> +}
> +
> +/* Set pulse per revolution value. Accepts either 2 or 4. */
> +static ssize_t do_set_fan_pulses(struct device *dev, u8 val)
> +{
> +	struct i2c_client *client = to_i2c_client(dev);
> +	struct g762_data *data = g762_update_client(dev);
> +
> +	mutex_lock(&data->update_lock);
> +	switch (val) {
> +	case 2:
> +		data->fan_cmd1 &= (u8) ~G762_REG_FAN_CMD1_PULSE_PER_REV;
> +		break;
> +	case 4:
> +		data->fan_cmd1 |= G762_REG_FAN_CMD1_PULSE_PER_REV;
> +		break;
> +	default:
> +		mutex_unlock(&data->update_lock);
> +		return -EINVAL;
> +	}
> +	g762_write_value(client, G762_REG_FAN_CMD1, (u16)data->fan_cmd1);
> +	mutex_unlock(&data->update_lock);
> +
> +	return val;
> +}
> +
> +/* Write function for fan1_pulses. Accepts either 2 or 4 */
> +static ssize_t set_fan_pulses(struct device *dev, struct device_attribute *da,
> +			      const char *buf, size_t count)
> +{
> +	unsigned long val;
> +	ssize_t ret;

Why ssize_t ?

> +
> +	if (kstrtoul(buf, 10, &val) || (val != 2 && val != 4))
> +		return -EINVAL;
> +
> +	ret = do_set_fan_pulses(dev, (u8) val);
> +	if (ret < 0)
> +		return -EINVAL;
> +
> +	return count;
> +}
> +
> +/* Following documentation about hwmon's sysfs interface, a pwm1_enable node
> + * should accept followings:
> + *
> + *  0 : no fan speed control (i.e. fan at full speed)
> + *  1 : manual fan speed control enabled (use pwm[1-*]) (open-loop)
> + *  2+: automatic fan speed control enabled (use fan[1-*]_enable)(close-loop)
> + *
> + * but we do not accept 0 as "no-control" mode is not supported by g762,
> + * -EINVAL is returned in this case. */
> +static ssize_t get_speed_control_mode(struct device *dev,
> +				      struct device_attribute *da, char *buf)
> +{
> +	struct g762_data *data = g762_update_client(dev);
> +	int fan_mode;
> +
> +	fan_mode = (data->fan_cmd1 & G762_REG_FAN_CMD1_FAN_MODE) ? 2 : 1;
> +
> +	return sprintf(buf, "%d\n", fan_mode);
> +}
> +
> +static ssize_t do_set_speed_control_mode(struct device *dev, u8 val)

Why ssize_t ?

> +{
> +	struct i2c_client *client = to_i2c_client(dev);
> +	struct g762_data *data = g762_update_client(dev);
> +
> +	if (!val)
> +		return -EINVAL;
> +	val -= 1;
> +
> +	mutex_lock(&data->update_lock);
> +	switch (val) {
> +	case FAN_MODE_CLOSED_LOOP:
> +		data->fan_cmd1 |= G762_REG_FAN_CMD1_FAN_MODE;
> +		break;
> +	case FAN_MODE_OPEN_LOOP:
> +		data->fan_cmd1 &= (u8) ~G762_REG_FAN_CMD1_FAN_MODE;
> +		break;
> +	default:
> +		mutex_unlock(&data->update_lock);
> +		return -EINVAL;
> +	}
> +
> +	g762_write_value(client, G762_REG_FAN_CMD1, data->fan_cmd1);
> +	mutex_unlock(&data->update_lock);
> +
> +	return val;
> +}
> +
> +static ssize_t set_speed_control_mode(struct device *dev,
> +				      struct device_attribute *da,
> +				      const char *buf, size_t count)
> +{
> +	unsigned long val;
> +	ssize_t ret;

And again ...

> +
> +	if (kstrtoul(buf, 10, &val))
> +		return -EINVAL;
> +
> +	ret = do_set_speed_control_mode(dev, val);
> +	if (ret < 0)
> +		return -EINVAL;
> +
> +	return count;
> +}
> +
> +/* Read function for pwm1_polarity (0: negative duty, 1: positive duty) */
> +static ssize_t get_pwm_polarity(struct device *dev, struct device_attribute *da,
> +		       char *buf)
> +{
> +	struct g762_data *data = g762_update_client(dev);
> +	u8 pwm_polarity;
> +
> +	pwm_polarity = (data->fan_cmd1 & G762_REG_FAN_CMD1_PWM_POLARITY) >> 1;
> +
> +	return sprintf(buf, "%d\n", pwm_polarity);
> +}
> +
> +/* Write function for pwm1_polarity (0: negative duty, 1: positive duty) */
> +static ssize_t set_pwm_polarity(struct device *dev, struct device_attribute *da,
> +		       const char *buf, size_t count)
> +{
> +	struct i2c_client *client = to_i2c_client(dev);
> +	struct g762_data *data = g762_update_client(dev);
> +	unsigned long val;
> +
> +	if (kstrtoul(buf, 10, &val))
> +		return -EINVAL;
> +
> +	mutex_lock(&data->update_lock);
> +	switch (val) {
> +	case 0: /* i.e. negative duty */
> +		data->fan_cmd1 &= (u8) ~G762_REG_FAN_CMD1_PWM_POLARITY;
> +		break;
> +	case 1: /* i.e. positive duty */
> +		data->fan_cmd1 |= G762_REG_FAN_CMD1_PWM_POLARITY;
> +		break;
> +	default:
> +		mutex_unlock(&data->update_lock);
> +		return -EINVAL;
> +	}
> +	g762_write_value(client, G762_REG_FAN_CMD1, data->fan_cmd1);
> +	mutex_unlock(&data->update_lock);
> +
> +	return count;
> +}
> +
> +/* Get/set the fan speed in open-loop mode using pwm1 sysfs file. Speed is
> + * given as a relative value from 0 to 255, where 255 is maximum speed. Note
> + * that this is done by writing directly to the chip's DAC, it won't change
> + * the closed loop speed set by fan1_target. Also note that due to rounding
> + * errors it is possible that you don't read back exactly the value you have
> + * set. */
> +static ssize_t get_pwm(struct device *dev, struct device_attribute *da,
> +		       char *buf)
> +{
> +	struct g762_data *data = g762_update_client(dev);
> +	int val;
> +
> +	mutex_lock(&data->update_lock);
> +	if (data->fan_cmd1 & G762_REG_FAN_CMD1_FAN_MODE) { /* closed-loop */
> +		val = PWM_FROM_CNT(data->set_cnt);
> +	} else {                                            /* open-loop */
> +		val = data->set_out;
> +	}
> +	mutex_unlock(&data->update_lock);
> +
> +	return sprintf(buf, "%d\n", val);
> +}
> +
> +static ssize_t do_set_pwm(struct device *dev, u8 val)

and again.

> +{
> +	struct i2c_client *client = to_i2c_client(dev);
> +	struct g762_data *data = g762_update_client(dev);
> +
> +	mutex_lock(&data->update_lock);
> +	if (data->fan_cmd1 & G762_REG_FAN_CMD1_FAN_MODE) { /* closed-loop */
> +		val = PWM_TO_CNT(clamp_val(val, 0, 255));
> +		data->set_cnt = val;
> +		g762_write_value(client, G762_REG_SET_CNT, val);
> +	} else {                                           /* open-loop */
> +		data->set_out = val;
> +		g762_write_value(client, G762_REG_SET_OUT, val);
> +	}
> +	mutex_unlock(&data->update_lock);
> +
> +	return val;

Why return val ? Why return anything in the first place ?

> +}
> +
> +static ssize_t set_pwm(struct device *dev, struct device_attribute *da,
> +		       const char *buf, size_t count)
> +{
> +	unsigned long val;
> +	ssize_t ret;
> +
> +	if (kstrtoul(buf, 10, &val))
> +		return -EINVAL;
> +
> +	ret = do_set_pwm(dev, (u8)val);
> +	if (ret < 0)
> +		return -EINVAL;
> +
> +	return count;
> +}
> +
> +/* Get/set the fan speed in closed-loop mode using fan1_target sysfs file. Speed
> + * is given as a rpm value, then G762 will automatically regulate the fan speed
> + * using pulses from fan tachometer.
> + *
> + * Refer to rpm_from_cnt implementation to get info about count number
> + * calculation.
> + *
> + * Also note that due to rounding errors it is possible that you don't read
> + * back exactly the value you have set. */
> +static ssize_t get_fan_target(struct device *dev, struct device_attribute *da,
> +			      char *buf)
> +{
> +	struct g762_data *data = g762_update_client(dev);
> +	unsigned int rpm;
> +	ssize_t err;
> +
> +	mutex_lock(&data->update_lock);
> +	if (data->fan_cmd1 & G762_REG_FAN_CMD1_FAN_MODE) { /* closed-loop */
> +		rpm = rpm_from_cnt(data->set_cnt, data->clk,
> +				   PULSE_FROM_REG(data->fan_cmd1),
> +				   CLKDIV_FROM_REG(data->fan_cmd1),
> +				   GEARMODE_FROM_REG(data->fan_cmd2));
> +		err = sprintf(buf, "%u\n", rpm);
> +	} else {                                           /* open-loop */
> +		err = -EINVAL;
> +	}
> +	mutex_unlock(&data->update_lock);
> +
> +	return err;
> +}
> +
> +static ssize_t do_set_fan_target(struct device *dev, unsigned int val)

No longer commenting on ssize_t.

> +{
> +	struct i2c_client *client = to_i2c_client(dev);
> +	struct g762_data *data = g762_update_client(dev);
> +	ssize_t err;
> +
> +	mutex_lock(&data->update_lock);
> +	if (data->fan_cmd1 & G762_REG_FAN_CMD1_FAN_MODE) { /* closed-loop */
> +		data->set_cnt = cnt_from_rpm(val, data->clk,
> +					     PULSE_FROM_REG(data->fan_cmd1),
> +					     CLKDIV_FROM_REG(data->fan_cmd1),
> +					     GEARMODE_FROM_REG(data->fan_cmd2));
> +		g762_write_value(client, G762_REG_SET_CNT, data->set_cnt);
> +		err = val;
> +	} else {
> +		err = -EINVAL;
> +	}
> +	mutex_unlock(&data->update_lock);
> +
> +	return err;
> +}
> +
> +static ssize_t set_fan_target(struct device *dev, struct device_attribute *da,
> +			      const char *buf, size_t count)
> +{
> +	unsigned int val;
> +	ssize_t ret;
> +
> +	if (sscanf(buf, "%u", &val) != 1)
> +		return -EINVAL;
> +
> +	ret = do_set_fan_target(dev, val);
> +	if (ret < 0)
> +		return -EINVAL;
> +
> +	return count;
> +}
> +
> +/* read function for 'fan1_fault_detection' sysfs file */
> +static ssize_t get_fan_failure_detection(struct device *dev,
> +					 struct device_attribute *da,
> +					 char *buf)
> +{
> +	struct g762_data *data = g762_update_client(dev);
> +	unsigned int enabled;
> +
> +	enabled = (data->fan_cmd1 & G762_REG_FAN_CMD1_DET_FAN_FAIL) ? 1 : 0;
> +
> +	return sprintf(buf, "%u\n", enabled);
> +}
> +
> +/* enable (or disable) fan failure detection */
> +static ssize_t do_fan_failure_detection_toggle(struct device *dev,
> +					    unsigned int enable)
> +{
> +	struct i2c_client *client = to_i2c_client(dev);
> +	struct g762_data *data = g762_update_client(dev);
> +
> +	mutex_lock(&data->update_lock);
> +	switch (enable) {
> +	case 0:
> +		data->fan_cmd1 &= (u8) ~G762_REG_FAN_CMD1_DET_FAN_FAIL;
> +		break;
> +	case 1:
> +		data->fan_cmd1 |= G762_REG_FAN_CMD1_DET_FAN_FAIL;
> +		break;
> +	default:
> +		mutex_unlock(&data->update_lock);
> +		return -EINVAL;

CodingStyle: Single return point.

> +	}
> +	g762_write_value(client, G762_REG_FAN_CMD1, data->fan_cmd1);
> +	mutex_unlock(&data->update_lock);
> +
> +	return enable;
> +}
> +
> +/* write function for 'fan1_fault_detection' sysfs file */
> +static ssize_t set_fan_failure_detection(struct device *dev,
> +					 struct device_attribute *da,
> +					 const char *buf, size_t count)
> +{
> +	unsigned int val;
> +	ssize_t ret;
> +
> +	if (sscanf(buf, "%u", &val) != 1)
> +		return -EINVAL;
> +
> +	ret = do_fan_failure_detection_toggle(dev, val);
> +	if (ret < 0)
> +		return -EINVAL;
> +
> +	return count;
> +}
> +
> +/* read function for fan1_fault sysfs file. */
> +static ssize_t get_fan_failure(struct device *dev, struct device_attribute *da,
> +			       char *buf)
> +{
> +	struct g762_data *data = g762_update_client(dev);
> +	unsigned int val;
> +
> +	val = (data->fan_sta & G762_REG_FAN_STA_FAIL) ? 1 : 0;
> +
> +	return sprintf(buf, "%u\n", val);
> +}
> +
> +/* read function for 'fan1_alarm_detection' sysfs file */
> +static ssize_t get_fan_ooc_detection(struct device *dev,
> +				     struct device_attribute *da,
> +				     char *buf)
> +{
> +	struct g762_data *data = g762_update_client(dev);
> +	unsigned int enabled;
> +
> +	enabled = (data->fan_cmd1 & G762_REG_FAN_CMD1_DET_FAN_FAIL) ? 1 : 0;
> +
> +	return sprintf(buf, "%u\n", enabled);
> +}
> +
> +/* enable (or disable) fan out of control detection */
> +static ssize_t do_fan_ooc_detection_toggle(struct device *dev,
> +					   unsigned int enable)
> +{
> +	struct i2c_client *client = to_i2c_client(dev);
> +	struct g762_data *data = g762_update_client(dev);
> +
> +	mutex_lock(&data->update_lock);
> +	switch (enable) {
> +	case 0:
> +		data->fan_cmd1 &= (u8) ~G762_REG_FAN_CMD1_DET_FAN_OOC;
> +		break;
> +	case 1:
> +		data->fan_cmd1 |= G762_REG_FAN_CMD1_DET_FAN_OOC;
> +		break;
> +	default:
> +		mutex_unlock(&data->update_lock);
> +		return -EINVAL;

CodingStyle

> +	}
> +	g762_write_value(client, G762_REG_FAN_CMD1, data->fan_cmd1);
> +	mutex_unlock(&data->update_lock);
> +
> +	return enable;
> +}
> +
> +/* write function for 'fan1_alarm_detection' sysfs file */
> +static ssize_t set_fan_ooc_detection(struct device *dev,
> +				     struct device_attribute *da,
> +				     const char *buf, size_t count)
> +{
> +	unsigned int val;
> +	ssize_t ret;
> +
> +	if (sscanf(buf, "%u", &val) != 1)
> +		return -EINVAL;
> +
> +	ret = do_fan_ooc_detection_toggle(dev, val);
> +	if (ret < 0)
> +		return -EINVAL;
> +
> +	return count;
> +}
> +
> +/* read function for fan1_alarm sysfs file. */
> +static ssize_t get_fan_ooc(struct device *dev, struct device_attribute *da,
> +			   char *buf)
> +{
> +	struct g762_data *data = g762_update_client(dev);
> +	unsigned int val;
> +
> +	/* ooc condition is enabled low */
> +	val = (data->fan_sta & G762_REG_FAN_STA_OOC) ? 0 : 1;
> +
> +	return sprintf(buf, "%u\n", val);
> +}
> +
> +/* Read function for fan1_startup_voltage */
> +static ssize_t get_fan_startup_voltage(struct device *dev,
> +				       struct device_attribute *da,
> +				       char *buf)
> +{
> +	struct g762_data *data = g762_update_client(dev);
> +	u8 val;
> +
> +	val = data->fan_cmd2 & (G762_REG_FAN_CMD2_FAN_STARTV_1 |
> +				G762_REG_FAN_CMD2_FAN_STARTV_0);
> +
> +	return sprintf(buf, "%d\n", val);
> +}
> +
> +/* Write function for fan1_startup_voltage */
> +static ssize_t set_fan_startup_voltage(struct device *dev,
> +				       struct device_attribute *da,
> +				       const char *buf, size_t count)
> +{
> +	struct i2c_client *client = to_i2c_client(dev);
> +	struct g762_data *data = g762_update_client(dev);
> +	unsigned long val;
> +
> +	if (kstrtoul(buf, 10, &val))
> +		return -EINVAL;
> +
> +	mutex_lock(&data->update_lock);
> +	switch (val) {
> +	case 0:
> +		data->fan_cmd2 &= (u8) ~G762_REG_FAN_CMD2_FAN_STARTV_0;
> +		data->fan_cmd2 &= (u8) ~G762_REG_FAN_CMD2_FAN_STARTV_1;
> +		break;
> +	case 1:
> +		data->fan_cmd2 |= G762_REG_FAN_CMD2_FAN_STARTV_0;
> +		data->fan_cmd2 &= (u8) ~G762_REG_FAN_CMD2_FAN_STARTV_1;
> +		break;
> +	case 2:
> +		data->fan_cmd2 &= (u8) ~G762_REG_FAN_CMD2_FAN_STARTV_0;
> +		data->fan_cmd2 |= G762_REG_FAN_CMD2_FAN_STARTV_1;
> +		break;
> +	case 3:
> +		data->fan_cmd2 |= G762_REG_FAN_CMD2_FAN_STARTV_0;
> +		data->fan_cmd2 |= G762_REG_FAN_CMD2_FAN_STARTV_1;
> +		break;
> +	default:
> +		mutex_unlock(&data->update_lock);
> +		return -EINVAL;
> +	}
> +	g762_write_value(client, G762_REG_FAN_CMD2, (u16)data->fan_cmd2);
> +	mutex_unlock(&data->update_lock);
> +
> +	return count;
> +}
> +
> +static DEVICE_ATTR(pwm1, S_IWUSR | S_IRUGO, get_pwm, set_pwm);
> +static DEVICE_ATTR(pwm1_polarity, S_IWUSR | S_IRUGO,
> +		   get_pwm_polarity, set_pwm_polarity);
> +static DEVICE_ATTR(pwm1_mode, S_IWUSR | S_IRUGO,
> +		   get_pwm_mode, set_pwm_mode);
> +static DEVICE_ATTR(pwm1_enable, S_IWUSR | S_IRUGO,
> +		   get_speed_control_mode, set_speed_control_mode);
> +static DEVICE_ATTR(pwm1_freq, S_IWUSR | S_IRUGO,
> +		   get_pwm_freq, set_pwm_freq);
> +
> +static DEVICE_ATTR(fan1_input, S_IRUGO, get_fan_rpm, NULL);
> +static DEVICE_ATTR(fan1_alarm, S_IRUGO, get_fan_ooc, NULL);
> +static DEVICE_ATTR(fan1_alarm_detection, S_IWUSR | S_IRUGO,
> +		   get_fan_ooc_detection, set_fan_ooc_detection);

I don't know ... why not just enable it ? 

I would suggest to look through the non-standard attributes to see which ones
are really needed at runtime. Seems to me they can (and should) all be
configuration values, set either through devicetree or platform data.

> +static DEVICE_ATTR(fan1_fault, S_IRUGO, get_fan_failure, NULL);
> +static DEVICE_ATTR(fan1_fault_detection, S_IWUSR | S_IRUGO,
> +		   get_fan_failure_detection, set_fan_failure_detection);
> +static DEVICE_ATTR(fan1_target, S_IWUSR | S_IRUGO,
> +		   get_fan_target, set_fan_target);
> +static DEVICE_ATTR(fan1_pulses, S_IWUSR | S_IRUGO,
> +		   get_fan_pulses, set_fan_pulses);
> +static DEVICE_ATTR(fan1_div, S_IWUSR | S_IRUGO,
> +		   get_fan_clk_div, set_fan_clk_div);
> +static DEVICE_ATTR(fan1_gear_mode, S_IWUSR | S_IRUGO,
> +		   get_fan_gear_mode, set_fan_gear_mode);
> +static DEVICE_ATTR(fan1_startup_voltage, S_IWUSR | S_IRUGO,
> +		   get_fan_startup_voltage, set_fan_startup_voltage);
> +
> +/* Driver data */
> +static struct attribute *g762_attributes[] = {
> +	&dev_attr_fan1_input.attr,
> +	&dev_attr_fan1_alarm.attr,
> +	&dev_attr_fan1_alarm_detection.attr,
> +	&dev_attr_fan1_fault.attr,
> +	&dev_attr_fan1_fault_detection.attr,
> +	&dev_attr_fan1_target.attr,
> +	&dev_attr_fan1_pulses.attr,
> +	&dev_attr_fan1_div.attr,
> +	&dev_attr_fan1_gear_mode.attr,
> +	&dev_attr_fan1_startup_voltage.attr,
> +	&dev_attr_pwm1.attr,
> +	&dev_attr_pwm1_polarity.attr,
> +	&dev_attr_pwm1_mode.attr,
> +	&dev_attr_pwm1_enable.attr,
> +	&dev_attr_pwm1_freq.attr,
> +	NULL
> +};
> +
> +static const struct attribute_group g762_group = {
> +	.attrs = g762_attributes,
> +};
> +
> +static int g762_probe(struct i2c_client *client, const struct i2c_device_id *id)
> +{
> +	u32 pwm_freq, fan_clk_div, fan_pulses, pwm_mode, fan_target, pwm_enable;
> +	struct g762_data *data;
> +	int err;
> +
> +	if (!i2c_check_functionality(client->adapter, I2C_FUNC_SMBUS_BYTE_DATA))
> +		return -ENODEV;
> +
> +	data = devm_kzalloc(&client->dev, sizeof(struct g762_data), GFP_KERNEL);
> +	if (!data)
> +		return -ENOMEM;
> +	i2c_set_clientdata(client, data);
> +
> +	data->client = client;
> +	mutex_init(&data->update_lock);
> +
> +	/* Setup default configuration for now. Those may get modified below
> +	 * in CONFIG_OF-protected block (via .dts file). Final values will
> +	 * then be pushed to the device */
> +	pwm_freq = G762_DEFAULT_CLK;
> +	fan_clk_div = G762_DEFAULT_FAN_CLK_DIV;
> +	fan_pulses = G762_DEFAULT_PULSE_PER_REV;
> +	pwm_mode = G762_DEFAULT_OUT_MODE;
> +	pwm_enable = G762_DEFAULT_FAN_MODE + 1; /* shift w/ sysfs interface */
> +	fan_target = 0xffffffff; /* dummy value */
> +
> +	/* Enable fan protection and fan fail detection by default */
> +	do_fan_ooc_detection_toggle(&client->dev, 1);
> +	do_fan_failure_detection_toggle(&client->dev, 1);
> +
> +#ifdef CONFIG_OF

It would be better to have a separate function for this.

> +	if (client->dev.of_node) {
> +		const __be32 *prop;
> +		int len;
> +
> +		prop = of_get_property(client->dev.of_node, "pwm_freq", &len);
> +		if (prop && len == sizeof(u32)) {
> +			pwm_freq = be32_to_cpu(prop[0]);
> +			dev_info(&client->dev, "found pwm_freq (%d)\n", pwm_freq);
> +		}
> +
> +		prop = of_get_property(client->dev.of_node, "fan_div", &len);
> +		if (prop && len == sizeof(u32)) {
> +			fan_clk_div = be32_to_cpu(prop[0]);
> +			dev_info(&client->dev, "found fan_div (%d)\n",
> +				 fan_clk_div);
> +		}
> +
> +		prop = of_get_property(client->dev.of_node, "fan_pulses", &len);
> +		if (prop && len == sizeof(u32)) {
> +			fan_pulses = be32_to_cpu(prop[0]);
> +			dev_info(&client->dev, "found fan_pulses (%d)\n",
> +				 fan_pulses);
> +		}
> +
> +		prop = of_get_property(client->dev.of_node, "pwm_mode", &len);
> +		if (prop && len == sizeof(u32)) {
> +			pwm_mode = be32_to_cpu(prop[0]);
> +			dev_info(&client->dev, "found pwm_mode (%d)\n",
> +				 pwm_mode);
> +		}
> +
> +		prop = of_get_property(client->dev.of_node, "fan_target", &len);
> +		if (prop && len == sizeof(u32)) {
> +			fan_target = be32_to_cpu(prop[0]);
> +			dev_info(&client->dev, "found fan_target (%d)\n",
> +				 fan_target);
> +		}
> +
> +		prop = of_get_property(client->dev.of_node, "pwm_enable", &len);
> +		if (prop && len == sizeof(u32)) {
> +			pwm_enable = be32_to_cpu(prop[0]);
> +			dev_info(&client->dev, "found pwm_enable (%d)\n",
> +				 pwm_enable);
> +		}
> +	}
> +#endif
> +
> +	/* Now, let's set final fan out mode (pwm or linear), loop mode (closed
> +	 * or open loop), clock freq, pulse per rev, fan clock div, fan target
> +	 * value, and speed control method (closed or open loop) */
> +	err = do_set_pwm_mode(&client->dev, pwm_mode);
> +	if (err < 0) {
> +		dev_info(&client->dev, "unable to set pwm_mode (%d)\n",
> +			 pwm_mode);
> +	}
> +
> +	err = do_set_speed_control_mode(&client->dev, pwm_enable);
> +	if (err < 0) {
> +		dev_info(&client->dev, "unable to set pwm_enable (%d)\n",
> +			 pwm_enable);

None of those are errors ?

> +	}
> +
> +	err = do_set_fan_clk_div(&client->dev, fan_clk_div);
> +	if (err < 0) {
> +		dev_info(&client->dev, "unable to set fan_clk_div (%d)\n",
> +			 fan_clk_div);
> +	}
> +
> +	err = do_set_fan_pulses(&client->dev, fan_pulses);
> +	if (err < 0) {
> +		dev_info(&client->dev, "unable to set fan_pulses (%d)\n",
> +			 fan_pulses);
> +	}
> +
> +	data->clk = pwm_freq;
> +
> +	if (fan_target != 0xffffffff) {
> +		err = do_set_fan_target(&client->dev, fan_target);
> +		if (err < 0) {
> +			dev_info(&client->dev, "unable to set fan_target (%d)\n",
> +				 fan_target);
> +		}
> +	}
> +
> +	/* Register sysfs hooks */
> +	err = sysfs_create_group(&client->dev.kobj, &g762_group);
> +	if (err)
> +		return err;
> +	data->hwmon_dev = (struct device *)hwmon_device_register(&client->dev);

What is this typecast about ?

> +	if (IS_ERR(data->hwmon_dev)) {
> +		err = PTR_ERR(data->hwmon_dev);
> +		sysfs_remove_group(&client->dev.kobj, &g762_group);
> +		return err;
> +	}
> +
> +	dev_info(&data->client->dev, "device successfully initialized\n");
> +
> +	return 0;
> +}
> +
> +static int g762_remove(struct i2c_client *client)
> +{
> +	struct g762_data *data = i2c_get_clientdata(client);
> +
> +	hwmon_device_unregister(data->hwmon_dev);
> +	sysfs_remove_group(&client->dev.kobj, &g762_group);
> +
> +	dev_info(&data->client->dev, "device successfully removed\n");
> +	return 0;
> +}
> +
> +module_i2c_driver(g762_driver);
> +
> +MODULE_AUTHOR("Olivier Mouchet <olivier.mouchet at gmail.com>");
> +MODULE_DESCRIPTION("GMT G762 driver");
> +MODULE_LICENSE("GPL");
> -- 
> 1.7.10.4
> 
> 


From arno at natisbad.org  Fri Apr 19 01:34:48 2013
From: arno at natisbad.org (Arnaud Ebalard)
Date: Fri, 19 Apr 2013 07:34:48 +0200
Subject: [PATCH 1/3] Add support for GMT G72/G763 PWM fan controller
In-Reply-To: <20130419043555.GA14124@roeck-us.net> (Guenter Roeck's message of
 "Thu, 18 Apr 2013 21:35:55 -0700")
References: <cover.1366322287.git.arno@natisbad.org>
 <4f4a821bbc61e2da28fd70553fd717ada255097d.1366322287.git.arno@natisbad.org>
 <20130419043555.GA14124@roeck-us.net>
Message-ID: <877gjz9j7r.fsf@natisbad.org>

Hi,

Guenter Roeck <linux at roeck-us.net> writes:

> On Fri, Apr 19, 2013 at 12:28:21AM +0200, Arnaud Ebalard wrote:
>> 
>> Signed-off-by: Arnaud Ebalard <arno at natisbad.org>
>> Tested-by: Arnaud Ebalard <arno at natisbad.org>
>> ---
>>  drivers/hwmon/Kconfig  |   10 +
>>  drivers/hwmon/Makefile |    1 +
>>  drivers/hwmon/g762.c   | 1159 ++++++++++++++++++++++++++++++++++++++++++++++++
>>  3 files changed, 1170 insertions(+)
>>  create mode 100644 drivers/hwmon/g762.c
>> 
> checkpatch says:
>
> total: 1 errors, 15 warnings, 0 checks, 1182 lines checked
>
> Please fix those. Also, please make sure there are spaces around operators.
>
> Additional comments inline. This is not a complete review; I gave up after
> a while. Please fix the problems and resubmit.

Thanks for taking the time and sorry for some lame errors (missing
spaces around operators, spaces issues, unchecked overflow). Regarding
the ssize_t, I will replace it by an int where appropriate; basically
all the functions not returning a size value or an error (i.e. those not
using sprintf).

Will try and resubmit a v1 with all thoses fixed and additional review
done after the week end

Cheers,

a+


From andrew at lunn.ch  Fri Apr 19 01:50:54 2013
From: andrew at lunn.ch (Andrew Lunn)
Date: Fri, 19 Apr 2013 07:50:54 +0200
Subject: [PATCH 1/3] Add support for GMT G72/G763 PWM fan controller
In-Reply-To: <4f4a821bbc61e2da28fd70553fd717ada255097d.1366322287.git.arno@natisbad.org>
References: <cover.1366322287.git.arno@natisbad.org>
 <4f4a821bbc61e2da28fd70553fd717ada255097d.1366322287.git.arno@natisbad.org>
Message-ID: <20130419055054.GD18115@lunn.ch>

Hi Arnaud

> +static DEVICE_ATTR(pwm1, S_IWUSR | S_IRUGO, get_pwm, set_pwm);
> +static DEVICE_ATTR(pwm1_polarity, S_IWUSR | S_IRUGO,
> +		   get_pwm_polarity, set_pwm_polarity);
> +static DEVICE_ATTR(pwm1_mode, S_IWUSR | S_IRUGO,
> +		   get_pwm_mode, set_pwm_mode);
> +static DEVICE_ATTR(pwm1_enable, S_IWUSR | S_IRUGO,
> +		   get_speed_control_mode, set_speed_control_mode);
> +static DEVICE_ATTR(pwm1_freq, S_IWUSR | S_IRUGO,
> +		   get_pwm_freq, set_pwm_freq);
> +
> +static DEVICE_ATTR(fan1_input, S_IRUGO, get_fan_rpm, NULL);
> +static DEVICE_ATTR(fan1_alarm, S_IRUGO, get_fan_ooc, NULL);
> +static DEVICE_ATTR(fan1_alarm_detection, S_IWUSR | S_IRUGO,
> +		   get_fan_ooc_detection, set_fan_ooc_detection);
> +static DEVICE_ATTR(fan1_fault, S_IRUGO, get_fan_failure, NULL);
> +static DEVICE_ATTR(fan1_fault_detection, S_IWUSR | S_IRUGO,
> +		   get_fan_failure_detection, set_fan_failure_detection);
> +static DEVICE_ATTR(fan1_target, S_IWUSR | S_IRUGO,
> +		   get_fan_target, set_fan_target);
> +static DEVICE_ATTR(fan1_pulses, S_IWUSR | S_IRUGO,
> +		   get_fan_pulses, set_fan_pulses);
> +static DEVICE_ATTR(fan1_div, S_IWUSR | S_IRUGO,
> +		   get_fan_clk_div, set_fan_clk_div);
> +static DEVICE_ATTR(fan1_gear_mode, S_IWUSR | S_IRUGO,
> +		   get_fan_gear_mode, set_fan_gear_mode);
> +static DEVICE_ATTR(fan1_startup_voltage, S_IWUSR | S_IRUGO,
> +		   get_fan_startup_voltage, set_fan_startup_voltage);

It is normal to use SENSOR_ATTR, not DEVICE_ATTR. Take a look at the
existing fan drivers.

I also think a lot of these are not needed. They are fixed properties
of the board and cannot change dynamically. They are set once using DT
and user space does not need to care.

	 Andrew


From khali at linux-fr.org  Fri Apr 19 02:05:08 2013
From: khali at linux-fr.org (Jean Delvare)
Date: Fri, 19 Apr 2013 08:05:08 +0200
Subject: [PATCH 1/3] Add support for GMT G72/G763 PWM fan controller
In-Reply-To: <4f4a821bbc61e2da28fd70553fd717ada255097d.1366322287.git.arno@natisbad.org>
References: <cover.1366322287.git.arno@natisbad.org>
 <4f4a821bbc61e2da28fd70553fd717ada255097d.1366322287.git.arno@natisbad.org>
Message-ID: <20130419080508.4866db90@endymion.delvare>

Hi Arnaud,

Just a few things I noticed...

Typo in subject line: G762, not G72.

On Fri, 19 Apr 2013 00:28:21 +0200, Arnaud Ebalard wrote:
> 
> Signed-off-by: Arnaud Ebalard <arno at natisbad.org>
> Tested-by: Arnaud Ebalard <arno at natisbad.org>
> ---
>  drivers/hwmon/Kconfig  |   10 +
>  drivers/hwmon/Makefile |    1 +
>  drivers/hwmon/g762.c   | 1159 ++++++++++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 1170 insertions(+)
>  create mode 100644 drivers/hwmon/g762.c
> 
> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
> index 89ac1cb..0c6ddee 100644
> --- a/drivers/hwmon/Kconfig
> +++ b/drivers/hwmon/Kconfig
> @@ -423,6 +423,16 @@ config SENSORS_G760A
>  	  This driver can also be built as a module.  If so, the module
>  	  will be called g760a.
>  
> +config SENSORS_G762
> +	tristate "GMT G762"
> +	depends on I2C
> +	help
> +	  If you say yes here you get support for Global Mixed-mode
> +	  Technology Inc G762 fan speed PWM controller chips.

If your driver also supports the G763 it should be mentioned here.

> +
> +	  This driver can also be built as a module.  If so, the module
> +	  will be called g762a.

This is not how your driver is actually named.

> +
>  config SENSORS_GL518SM
>  	tristate "Genesys Logic GL518SM"
>  	depends on I2C
> diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
> index 8d6d97e..4b49504 100644
> --- a/drivers/hwmon/Makefile
> +++ b/drivers/hwmon/Makefile
> @@ -57,6 +57,7 @@ obj-$(CONFIG_SENSORS_F75375S)	+= f75375s.o
>  obj-$(CONFIG_SENSORS_FAM15H_POWER) += fam15h_power.o
>  obj-$(CONFIG_SENSORS_FSCHMD)	+= fschmd.o
>  obj-$(CONFIG_SENSORS_G760A)	+= g760a.o
> +obj-$(CONFIG_SENSORS_G762)	+= g762.o
>  obj-$(CONFIG_SENSORS_GL518SM)	+= gl518sm.o
>  obj-$(CONFIG_SENSORS_GL520SM)	+= gl520sm.o
>  obj-$(CONFIG_SENSORS_GPIO_FAN)	+= gpio-fan.o
> diff --git a/drivers/hwmon/g762.c b/drivers/hwmon/g762.c
> new file mode 100644
> index 0000000..8c4cb39
> --- /dev/null
> +++ b/drivers/hwmon/g762.c
> (...)
> +#define DRVNAME "g762"
> +
> +static const struct i2c_device_id g762_id[] = {
> +	{ DRVNAME, 0 },

No, this is a list of device names, nor driver names, so the use of
DRVNAME is inappropriate. Also, again, if your driver supports the g763
it should be listed here too.

> +	{ }
> +};
> +MODULE_DEVICE_TABLE(i2c, g762_id);

-- 
Jean Delvare


From sfr at canb.auug.org.au  Fri Apr 19 02:29:08 2013
From: sfr at canb.auug.org.au (Stephen Rothwell)
Date: Fri, 19 Apr 2013 16:29:08 +1000
Subject: linux-next: manual merge of the arm-soc tree with the gen-gpio tree
Message-ID: <20130419162908.69aa0cbccc708ea1ca563a11@canb.auug.org.au>

Hi all,

Today's linux-next merge of the arm-soc tree got a conflict in
arch/arm/plat-orion/Makefile between commit 43b426d6fae8 ("arm:
plat-orion: use GPIO driver on CONFIG_GPIOLIB") from the gen-gpio tree
and various commits from the arm-soc tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr at canb.auug.org.au

diff --cc arch/arm/plat-orion/Makefile
index bbc0d6b,2eca54b..0000000
--- a/arch/arm/plat-orion/Makefile
+++ b/arch/arm/plat-orion/Makefile
@@@ -3,8 -3,6 +3,6 @@@
  #
  ccflags-$(CONFIG_ARCH_MULTIPLATFORM) := -I$(srctree)/$(src)/include
  
- obj-y                             += addr-map.o
- 
 -orion-gpio-$(CONFIG_GENERIC_GPIO) += gpio.o
 +orion-gpio-$(CONFIG_GPIOLIB)      += gpio.o
  obj-$(CONFIG_PLAT_ORION_LEGACY)   += irq.o pcie.o time.o common.o mpp.o
  obj-$(CONFIG_PLAT_ORION_LEGACY)   += $(orion-gpio-y)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130419/57f3c14f/attachment.sig>

From santosh.shilimkar at ti.com  Fri Apr 19 02:32:14 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Fri, 19 Apr 2013 12:02:14 +0530
Subject: [PATCH] gpio/omap: ensure gpio context is initialised
In-Reply-To: <51709499.8030208@ti.com>
References: <1366230707-32681-1-git-send-email-jon-hunter@ti.com>
 <871ua734mv.fsf@linaro.org> <51707D7C.1050600@ti.com>
 <5170911C.6010507@ti.com> <51709499.8030208@ti.com>
Message-ID: <5170E4EE.7090100@ti.com>

On Friday 19 April 2013 06:19 AM, Jon Hunter wrote:
> 
> On 04/18/2013 07:34 PM, Jon Hunter wrote:
>>
>> On 04/18/2013 06:10 PM, Jon Hunter wrote:
>>> On 04/18/2013 04:34 PM, Kevin Hilman wrote:
>>
>> ...
>>
>>>> Why not just init context right here if bank->loses_context &&
>>>> !bank->context_valid?
>>
>> I really like this idea a lot. It can really clean-up the code
>> and really make it much more readable. Before we were playing 
>> some tricks with when we init'ed the get_context_loss_count()
>> function pointer. How about the below?
>>
>> Tony, care to re-test?
>>
>> Cheers
>> Jon
>>
>> From d7a940531d354e6be5e16ee50fa8344041df963a Mon Sep 17 00:00:00 2001
>> From: Jon Hunter <jon-hunter at ti.com>
>> Date: Mon, 15 Apr 2013 13:06:54 -0500
>> Subject: [PATCH] gpio/omap: ensure gpio context is initialised
>>
>> Commit a2797be (gpio/omap: force restore if context loss is not
>> detectable) broke gpio support for OMAP when booting with device-tree
>> because a restore of the gpio context being performed without ever
>> initialising the gpio context. In other words, the context restored was
>> bad.
>>
>> This problem could also occur in the non device-tree case, however, it
>> is much less likely because when booting without device-tree we can
>> detect context loss via a platform specific API and so context restore
>> is performed less often.
>>
>> Nevertheless we should ensure that the gpio context is initialised
>> on the first pm-runtime resume for gpio banks that could lose their
>> state regardless of whether we are booting with device-tree or not.
>>
>> The context loss count was being initialised on the first pm-runtime
>> suspend following a resume, by populating the get_count_loss_count()
>> function pointer after the first pm-runtime resume. To make the code
>> more readable and logical, initialise the context loss count on the
>> first pm-runtime resume if the context is not yet valid.
>>
>> Reported-by: Tony Lindgren <tony at atomide.com>
>> Signed-off-by: Jon Hunter <jon-hunter at ti.com>
>> ---
>>  drivers/gpio/gpio-omap.c |   45 ++++++++++++++++++++++++++++++++++++++++++---
>>  1 file changed, 42 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
>> index 0557529..db3c732 100644
>> --- a/drivers/gpio/gpio-omap.c
>> +++ b/drivers/gpio/gpio-omap.c
>> @@ -70,6 +70,7 @@ struct gpio_bank {
>>  	bool is_mpuio;
>>  	bool dbck_flag;
>>  	bool loses_context;
>> +	bool context_valid;
>>  	int stride;
>>  	u32 width;
>>  	int context_loss_count;
>> @@ -1129,6 +1130,7 @@ static int omap_gpio_probe(struct platform_device *pdev)
>>  			bank->loses_context = true;
>>  	} else {
>>  		bank->loses_context = pdata->loses_context;
>> +		bank->get_context_loss_count = pdata->get_context_loss_count;
> 
> Still need to check loses_context for populating
> get_context_loss_count here. Updated patch below.
> 
> Jon
> 
> From d02ef7b7dfcf8e13bf019aedfdecb38ca3c6749f Mon Sep 17 00:00:00 2001
> From: Jon Hunter <jon-hunter at ti.com>
> Date: Mon, 15 Apr 2013 13:06:54 -0500
> Subject: [PATCH] gpio/omap: ensure gpio context is initialised
> 
> Commit a2797be (gpio/omap: force restore if context loss is not
> detectable) broke gpio support for OMAP when booting with device-tree
> because a restore of the gpio context being performed without ever
> initialising the gpio context. In other words, the context restored was
> bad.
> 
> This problem could also occur in the non device-tree case, however, it
> is much less likely because when booting without device-tree we can
> detect context loss via a platform specific API and so context restore
> is performed less often.
> 
> Nevertheless we should ensure that the gpio context is initialised
> on the first pm-runtime resume for gpio banks that could lose their
> state regardless of whether we are booting with device-tree or not.
> 
> The context loss count was being initialised on the first pm-runtime
> suspend following a resume, by populating the get_count_loss_count()
> function pointer after the first pm-runtime resume. To make the code
> more readable and logical, initialise the context loss count on the
> first pm-runtime resume if the context is not yet valid.
> 
> Reported-by: Tony Lindgren <tony at atomide.com>
> Signed-off-by: Jon Hunter <jon-hunter at ti.com>
> ---
This version looks better than the first one for sure. I am still not
happy with per bank "context_valid" flag whose job just ends after
the probe. But then I do agree with you about the global flag might
be fragile and less maintainable.

So, FWIW,
Acked-by: Santosh Shilimkar<santosh.shilimkar at ti.com>



From sfr at canb.auug.org.au  Fri Apr 19 02:46:36 2013
From: sfr at canb.auug.org.au (Stephen Rothwell)
Date: Fri, 19 Apr 2013 16:46:36 +1000
Subject: linux-next: build failure after merge of the arm-soc tree
Message-ID: <20130419164636.0d2405ca5fd927f1ba31fe40@canb.auug.org.au>

Hi all,

After merging the arm-soc tree, today's linux-next build (powerpc ppc64_defconfig)
failed like this:

powerpc64-linux-ld: cannot find drivers/pci/host/built-in.o: No such file or directory

Caused by commit 9ecbe03ae85b ("pci: infrastructure to add drivers in
drivers/pci/host").

I have used the arm-soc tree from next-20130418 for today.
-- 
Cheers,
Stephen Rothwell                    sfr at canb.auug.org.au
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130419/02269d24/attachment-0001.sig>

From sfr at canb.auug.org.au  Fri Apr 19 02:59:31 2013
From: sfr at canb.auug.org.au (Stephen Rothwell)
Date: Fri, 19 Apr 2013 16:59:31 +1000
Subject: linux-next: manual merge of the renesas tree with the arm-soc tree
Message-ID: <20130419165931.740d243c82497664e6bd95b1@canb.auug.org.au>

Hi Simon,

Today's linux-next merge of the renesas tree got a conflict in
arch/arm/mach-shmobile/setup-r8a7740.c between commit 0583fe478a7d ("ARM:
convert arm/arm64 arch timer to use CLKSRC_OF init") from the arm-soc
tree and commit 74d6523995cc ("ARM: shmobile: r8a7740: Prepare for
reference DT setup") from the renesas tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr at canb.auug.org.au

diff --cc arch/arm/mach-shmobile/setup-r8a7740.c
index 326a4ab,00c5a70..0000000
--- a/arch/arm/mach-shmobile/setup-r8a7740.c
+++ b/arch/arm/mach-shmobile/setup-r8a7740.c
@@@ -1027,9 -1016,10 +1016,9 @@@ static const char *r8a7740_boards_compa
  
  DT_MACHINE_START(R8A7740_DT, "Generic R8A7740 (Flattened Device Tree)")
  	.map_io		= r8a7740_map_io,
- 	.init_early	= r8a7740_add_early_devices_dt,
- 	.init_irq	= r8a7740_init_irq,
- 	.init_machine	= r8a7740_add_standard_devices_dt,
+ 	.init_early	= r8a7740_init_delay,
+ 	.init_irq	= r8a7740_init_irq_of,
+ 	.init_machine	= r8a7740_generic_init,
 -	.init_time	= shmobile_timer_init,
  	.dt_compat	= r8a7740_boards_compat_dt,
  MACHINE_END
  
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130419/364f4f13/attachment.sig>

From juhosg at openwrt.org  Fri Apr 19 03:19:50 2013
From: juhosg at openwrt.org (Gabor Juhos)
Date: Fri, 19 Apr 2013 09:19:50 +0200
Subject: [PATCH v7 3/3] of/pci: mips: convert to common of_pci_range_parser
In-Reply-To: <20130418130919.GI27197@titan.lakedaemon.net>
References: <1366107508-12672-1-git-send-email-Andrew.Murray@arm.com>
 <1366107508-12672-4-git-send-email-Andrew.Murray@arm.com>
 <CACRpkdbBaT1OKr5t8HW4+8y_wSDmGxmewAyVMekx8S-K9s3K8Q@mail.gmail.com>
 <20130418125910.GA17128@arm.com>
 <20130418130919.GI27197@titan.lakedaemon.net>
Message-ID: <5170F016.6050502@openwrt.org>

2013.04.18. 15:09 keltez?ssel, Jason Cooper ?rta:
> On Thu, Apr 18, 2013 at 01:59:10PM +0100, Andrew Murray wrote:
>> On Wed, Apr 17, 2013 at 04:42:48PM +0100, Linus Walleij wrote:
>>> On Tue, Apr 16, 2013 at 12:18 PM, Andrew Murray <Andrew.Murray at arm.com> wrote:
>>>
>>>> This patch converts the pci_load_of_ranges function to use the new common
>>>> of_pci_range_parser.
>>>>
>>>> Signed-off-by: Andrew Murray <Andrew.Murray at arm.com>
>>>> Signed-off-by: Liviu Dudau <Liviu.Dudau at arm.com>
>>>> Reviewed-by: Rob Herring <rob.herring at calxeda.com>
>>>
>>> Tested-by: Linus Walleij <linus.walleij at linaro.org>
>>
>> Jason - you may not have seen this, but here (Linus Walleij) is another Tested-by
>> to add to this patch in your tree (if you can).
> 
> Thanks, I saw it.  Unfortunately, the PR was already sent, and the branch
> is now pulled into arm-soc.

Sorry I had no time earlier, but I have tested this now on MIPS. The patch
causes build errors unfortunately. Given the fact that this has been merged
already, I will send a fixup patch.

-Gabor


From sfr at canb.auug.org.au  Fri Apr 19 03:27:53 2013
From: sfr at canb.auug.org.au (Stephen Rothwell)
Date: Fri, 19 Apr 2013 17:27:53 +1000
Subject: linux-next: manual merge of the clk tree with the arm-soc tree
Message-ID: <20130419172753.0e604e9bad0b7a26a8b52787@canb.auug.org.au>

Hi Mike,

Today's linux-next merge of the clk tree got a conflict in
arch/arm/mach-vexpress/v2m.c between commit dabfd8fb84ab ("ARM: vexpress:
remove sp804 OF init") from the arm-soc tree and commit 6e973d2c4385
("clk: vexpress: Add separate SP810 driver") from the clk tree.

I fixed it up (I thnk - see below) and can carry the fix as necessary (no
action is required).

-- 
Cheers,
Stephen Rothwell                    sfr at canb.auug.org.au

diff --cc arch/arm/mach-vexpress/v2m.c
index d8e2954,c5e20b5..0000000
--- a/arch/arm/mach-vexpress/v2m.c
+++ b/arch/arm/mach-vexpress/v2m.c
@@@ -23,9 -21,13 +23,11 @@@
  #include <linux/regulator/fixed.h>
  #include <linux/regulator/machine.h>
  #include <linux/vexpress.h>
+ #include <linux/clk-provider.h>
+ #include <linux/clkdev.h>
  
 -#include <asm/arch_timer.h>
  #include <asm/mach-types.h>
  #include <asm/sizes.h>
 -#include <asm/smp_twd.h>
  #include <asm/mach/arch.h>
  #include <asm/mach/map.h>
  #include <asm/mach/time.h>
@@@ -425,11 -433,29 +427,11 @@@ void __init v2m_dt_init_early(void
  
  static void __init v2m_dt_timer_init(void)
  {
- 	vexpress_clk_of_init();
 -	struct device_node *node = NULL;
 -
+ 	of_clk_init(NULL);
  
 -	do {
 -		node = of_find_compatible_node(node, NULL, "arm,sp804");
 -	} while (node && vexpress_get_site_by_node(node) != VEXPRESS_SITE_MB);
 -	if (node) {
 -		pr_info("Using SP804 '%s' as a clock & events source\n",
 -				node->full_name);
 -		WARN_ON(clk_register_clkdev(of_clk_get_by_name(node,
 -				"timclken1"), "v2m-timer0", "sp804"));
 -		WARN_ON(clk_register_clkdev(of_clk_get_by_name(node,
 -				"timclken2"), "v2m-timer1", "sp804"));
 -		v2m_sp804_init(of_iomap(node, 0),
 -				irq_of_parse_and_map(node, 0));
 -	}
 -
 -	if (arch_timer_of_register() != 0)
 -		twd_local_timer_of_register();
 +	clocksource_of_init();
  
 -	if (arch_timer_sched_clock_init() != 0)
 -		versatile_sched_clock_init(vexpress_get_24mhz_clock_base(),
 +	versatile_sched_clock_init(vexpress_get_24mhz_clock_base(),
  				24000000);
  }
  
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130419/72b3722a/attachment.sig>

From rogerq at ti.com  Fri Apr 19 04:18:33 2013
From: rogerq at ti.com (Roger Quadros)
Date: Fri, 19 Apr 2013 11:18:33 +0300
Subject: [PATCH] ARM: dts: omap4-panda: Add USB Host support
In-Reply-To: <20130418200935.GD10155@atomide.com>
References: <1366015721-25608-1-git-send-email-rogerq@ti.com>
 <20130418200935.GD10155@atomide.com>
Message-ID: <5170FDD9.904@ti.com>

On 04/18/2013 11:09 PM, Tony Lindgren wrote:
> * Roger Quadros <rogerq at ti.com> [130415 01:53]:
>> Provide the RESET and Power regulators for the USB PHY,
>> the USB Host port mode and the PHY device.
>>
>> The USB PHY needs AUXCLK3 to operate. Provide this information
>> as well.
>>
>> Also provide pin multiplexer information for the USB host
>> pins.
>>
>> This patch depends on OMAP clock binding introduced in
>> https://lkml.org/lkml/2013/4/12/407
> 
> Cool looks like EHCI works with this on my panda with linux
> next booting with DT. One comment below.
> 
> Regards,
> 
> Tony
> 
>  
>> CC: Beno?t Cousson <b-cousson at ti.com>
>> Signed-off-by: Roger Quadros <rogerq at ti.com>
>> ---
>>  arch/arm/boot/dts/omap4-panda-common.dtsi |   58 +++++++++++++++++++++++++++++
>>  arch/arm/boot/dts/omap4.dtsi              |    5 ++
>>  2 files changed, 63 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi b/arch/arm/boot/dts/omap4-panda-common.dtsi
>> index 03bd60d..628f744 100644
>> --- a/arch/arm/boot/dts/omap4-panda-common.dtsi
>> +++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
>> @@ -54,6 +54,38 @@
>>  			"AFML", "Line In",
>>  			"AFMR", "Line In";
>>  	};
>> +
>> +	/* HS USB Port 1 RESET */
>> +	hsusb1_reset: hsusb1_reset_reg {
>> +		compatible = "regulator-fixed";
>> +		regulator-name = "hsusb1_reset";
>> +		regulator-min-microvolt = <3300000>;
>> +		regulator-max-microvolt = <3300000>;
>> +		gpio = <&gpio2 30 0>;	/* gpio_62 */
>> +		startup-delay-us = <70000>;
>> +		enable-active-high;
>> +	};
>> +
>> +	/* HS USB Port 1 Power */
>> +	hsusb1_power: hsusb1_power_reg {
>> +		compatible = "regulator-fixed";
>> +		regulator-name = "hsusb1_vbus";
>> +		regulator-min-microvolt = <3300000>;
>> +		regulator-max-microvolt = <3300000>;
>> +		gpio = <&gpio1 1 0>;	/* gpio_1 */
>> +		startup-delay-us = <70000>;
>> +		enable-active-high;
>> +	};
>> +
>> +	/* HS USB Host PHY on PORT 1 */
>> +	hsusb1_phy: hsusb1_phy {
>> +		compatible = "usb-nop-xceiv";
>> +		reset-supply = <&hsusb1_reset>;
>> +		vcc-supply = <&hsusb1_power>;
>> +		clocks = <&auxclk3>;
>> +		clock-names = "main_clk";
>> +		clock-frequency = <19200000>;
>> +	};
>>  };
>>  
>>  &omap4_pmx_core {
>> @@ -64,6 +96,7 @@
>>  			&mcbsp1_pins
>>  			&dss_hdmi_pins
>>  			&tpd12s015_pins
>> +			&hsusbb1_pins
>>  	>;
>>  
>>  	twl6040_pins: pinmux_twl6040_pins {
>> @@ -108,6 +141,23 @@
>>  		>;
>>  	};
>>  
>> +	hsusbb1_pins: pinmux_hsusbb1_pins {
>> +		pinctrl-single,pins = <
>> +			0x82 0x10C	/* USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_clk INPUT | PULLDOWN */
>> +			0x84 0x4	/* USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_stp OUTPUT */
>> +			0x86 0x104	/* USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dir INPUT | PULLDOWN */
>> +			0x88 0x104	/* USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_nxt INPUT | PULLDOWN */
>> +			0x8a 0x104	/* USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat0 INPUT | PULLDOWN */
>> +			0x8c 0x104	/* USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat1 INPUT | PULLDOWN */
>> +			0x8e 0x104	/* USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat2 INPUT | PULLDOWN */
>> +			0x90 0x104	/* USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat3 INPUT | PULLDOWN */
>> +			0x92 0x104	/* USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat4 INPUT | PULLDOWN */
>> +			0x94 0x104	/* USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat5 INPUT | PULLDOWN */
>> +			0x96 0x104	/* USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat6 INPUT | PULLDOWN */
>> +			0x98 0x104	/* USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat7 INPUT | PULLDOWN */
>> +		>;
>> +	};
>> +
>>  	i2c1_pins: pinmux_i2c1_pins {
>>  		pinctrl-single,pins = <
>>  			0xe2 0x118        /* i2c1_scl PULLUP | INPUTENABLE | MODE0 */
> 
> Looks like your comments are wrong above, it's not PULLDOWN? Also

right it's not.

> the naming should be mode0name.modename to be consistent. Here's
> what I dumped out, please check and replace spaces with tabs:
> 
>                         0x82 0x10c      /* usbb1_ulpitll_clk.usbb1_ulpiphy_clk gpio84 INPUT_PULLDOWN | MODE4 */
>                         0x84 0x4        /* usbb1_ulpitll_stp.usbb1_ulpiphy_stp gpio85 OUTPUT | MODE4 */
>                         0x86 0x104      /* usbb1_ulpitll_dir.usbb1_ulpiphy_dir gpio86 INPUT | MODE4 */
>                         0x88 0x104      /* usbb1_ulpitll_nxt.usbb1_ulpiphy_nxt gpio87 INPUT | MODE4 */
>                         0x8a 0x104      /* usbb1_ulpitll_dat0.usbb1_ulpiphy_dat0 gpio88 INPUT | MODE4 */
>                         0x8c 0x104      /* usbb1_ulpitll_dat1.usbb1_ulpiphy_dat1 gpio89 INPUT | MODE4 */
>                         0x8e 0x104      /* usbb1_ulpitll_dat2.usbb1_ulpiphy_dat2 gpio90 INPUT | MODE4 */
>                         0x90 0x104      /* usbb1_ulpitll_dat3.usbb1_ulpiphy_dat3 gpio91 INPUT | MODE4 */
>                         0x92 0x104      /* usbb1_ulpitll_dat4.usbb1_ulpiphy_dat4 gpio92 INPUT | MODE4 */
>                         0x94 0x104      /* usbb1_ulpitll_dat5.usbb1_ulpiphy_dat5 gpio93 INPUT | MODE4 */
>                         0x96 0x104      /* usbb1_ulpitll_dat6.usbb1_ulpiphy_dat6 gpio94 INPUT | MODE4 */
>                         0x98 0x104      /* usbb1_ulpitll_dat7.usbb1_ulpiphy_dat7 gpio95 INPUT | MODE4 */

I don't think gpioXX is necessary as we aren't using any of them as GPIOs.

cheers,
-roger


From k.debski at samsung.com  Fri Apr 19 04:44:29 2013
From: k.debski at samsung.com (Kamil Debski)
Date: Fri, 19 Apr 2013 10:44:29 +0200
Subject: [PATCH -next] [media] s5p-mfc: fix error return code in
 s5p_mfc_probe()
In-Reply-To: <CAPgLHd_TwmtoaE7T7e3fRKh4NTGhOYjQZv0G7nt-iSVMLz3XEQ@mail.gmail.com>
References: <CAPgLHd_TwmtoaE7T7e3fRKh4NTGhOYjQZv0G7nt-iSVMLz3XEQ@mail.gmail.com>
Message-ID: <015501ce3cda$1cdfa900$569efb00$%debski@samsung.com>

Hi Wei,

Thank you for your patch.

Best wishes,
Kamil Debski

> From: Wei Yongjun [mailto:weiyj.lk at gmail.com]
> Sent: Thursday, April 18, 2013 5:18 AM
> 
> From: Wei Yongjun <yongjun_wei at trendmicro.com.cn>
> 
> Fix to return a negative error code from the error handling case
> instead of 0, as returned elsewhere in this function.
> 
> Signed-off-by: Wei Yongjun <yongjun_wei at trendmicro.com.cn>

Acked-by: Kamil Debski <k.debski at samsung.com>

> ---
>  drivers/media/platform/s5p-mfc/s5p_mfc.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c
> b/drivers/media/platform/s5p-mfc/s5p_mfc.c
> index e810b1a..a5853fa 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
> @@ -1110,7 +1110,8 @@ static int s5p_mfc_probe(struct platform_device
> *pdev)
>  	}
> 
>  	if (pdev->dev.of_node) {
> -		if (s5p_mfc_alloc_memdevs(dev) < 0)
> +		ret = s5p_mfc_alloc_memdevs(dev);
> +		if (ret < 0)
>  			goto err_res;
>  	} else {
>  		dev->mem_dev_l = device_find_child(&dev->plat_dev->dev,




From nicolas.ferre at atmel.com  Fri Apr 19 04:49:07 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Fri, 19 Apr 2013 10:49:07 +0200
Subject: [PATCH 5/5] ARM: at91: add Acme Systems Fox G20 board
In-Reply-To: <517020A1.3070504@atmel.com>
References: <cover.1366289869.git.nicolas.ferre@atmel.com>
 <a647ac59d50fdee9a0e9e87f362febe1ad2b1264.1366289869.git.nicolas.ferre@atmel.com>
 <517020A1.3070504@atmel.com>
Message-ID: <51710503.7080309@atmel.com>

On 04/18/2013 06:34 PM, Nicolas Ferre :
> On 04/18/2013 03:01 PM, Nicolas Ferre :
>> From: Douglas Gilbert <dgilbert at interlog.com>
>>
>> Signed-off-by: Douglas Gilbert <dgilbert at interlog.com>
>> Signed-off-by: Nicolas Ferre <nicolas.ferre at atmel.com>
>> ---
>>  arch/arm/boot/dts/Makefile        |   1 +
>>  arch/arm/boot/dts/at91-foxg20.dts | 166 ++++++++++++++++++++++++++++++++++++++
> 
> FYI: I have to review this one: error while compiling.

Okay, corrected now: see below...

> 
>>  2 files changed, 167 insertions(+)
>>  create mode 100644 arch/arm/boot/dts/at91-foxg20.dts
>>
>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>> index b07f162..914fe65 100644
>> --- a/arch/arm/boot/dts/Makefile
>> +++ b/arch/arm/boot/dts/Makefile
>> @@ -16,6 +16,7 @@ dtb-$(CONFIG_ARCH_AT91) += at91sam9263ek.dtb
>>  dtb-$(CONFIG_ARCH_AT91) += tny_a9263.dtb
>>  dtb-$(CONFIG_ARCH_AT91) += usb_a9263.dtb
>>  # sam9g20
>> +dtb-$(CONFIG_ARCH_AT91) += at91-foxg20.dtb
>>  dtb-$(CONFIG_ARCH_AT91) += at91sam9g20ek.dtb
>>  dtb-$(CONFIG_ARCH_AT91) += at91sam9g20ek_2mmc.dtb
>>  dtb-$(CONFIG_ARCH_AT91) += kizbox.dtb
>> diff --git a/arch/arm/boot/dts/at91-foxg20.dts b/arch/arm/boot/dts/at91-foxg20.dts
>> new file mode 100644
>> index 0000000..7d24ef7
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/at91-foxg20.dts
>> @@ -0,0 +1,166 @@
>> +/*
>> + * at91-foxg20.dts - Device Tree file for Acme Systems FoxG20 board
>> + *
>> + * Based on DT files for at91sam9g20ek evaluation board (AT91SAM9G20 SoC)
>> + *
>> + * Copyright (C) 2013 Douglas Gilbert <dgilbert at interlog.com>
>> + *
>> + * Licensed under GPLv2 or later.
>> + */
>> +/dts-v1/;
>> +/include/ "at91sam9g20.dtsi"
>> +
>> +/ {
>> +	model = "Acme Systems FoxG20";
>> +	compatible = "acme,foxg20", "atmel,at91sam9g20", "atmel,at91sam9";
>> +
>> +	chosen {
>> +		bootargs = "console=ttyS0,115200 root=/dev/mmcblk0p2 rw rootwait";
>> +	};
>> +
>> +	memory {
>> +		reg = <0x20000000 0x4000000>;
>> +	};
>> +
>> +	clocks {
>> +		#address-cells = <1>;
>> +		#size-cells = <1>;
>> +		ranges;
>> +
>> +		main_clock: clock at 0 {
>> +			compatible = "atmel,osc", "fixed-clock";
>> +			clock-frequency = <18432000>;
>> +		};
>> +	};
>> +
>> +	ahb {
>> +		apb {
>> +			usb1: gadget at fffa4000 {
>> +				atmel,vbus-gpio = <&pioC 6 0>;
>> +				status = "okay";
>> +			};
>> +
>> +			mmc0: mmc at fffa8000 {
>> +				pinctrl-0 = <
>> +					&pinctrl_mmc0_clk
>> +					&pinctrl_mmc0_slot1_cmd_dat0
>> +					&pinctrl_mmc0_slot1_dat1_3>;
>> +				status = "okay";
>> +				slot at 1 {
>> +					reg = <1>;
>> +					bus-width = <4>;
>> +				};
>> +			};
>> +
>> +			usart0: serial at fffb0000 {
>> +				pinctrl-0 =
>> +					<&pinctrl_usart0
>> +					 &pinctrl_usart0_rts
>> +					 &pinctrl_usart0_cts
>> +					>;
>> +				status = "okay";
>> +			};
>> +
>> +			usart1: serial at fffb4000 {
>> +				status = "okay";
>> +			};
>> +
>> +			usart2: serial at fffb8000 {
>> +				status = "okay";
>> +			};
>> +
>> +			macb0: ethernet at fffc4000 {
>> +				phy-mode = "rmii";
>> +				status = "okay";
>> +			};
>> +
>> +			spi0: spi at fffc8000 {
>> +				cs-gpios = <0>, <&pioC 11 0>, <0>, <0>;
>> +				mtd_dataflash at 0 {
>> +					compatible = "atmel,at45", "atmel,dataflash";
>> +					spi-max-frequency = <50000000>;
>> +					reg = <1>;
>> +				};
>> +				status = "disabled";

No property after subnodes: moved upwards... but then, completely
removed: spi node is not defined in SoC .dtsi: it was even causing error
of cell definition... ==> we will add it later.

>> +			};
>> +
>> +			usart3: serial at fffd0000 {
>> +				status = "okay";
>> +			};
>> +
>> +			uart0: serial at fffd4000 {
>> +				status = "okay";
>> +			};
>> +
>> +			uart1: serial at fffd8000 {
>> +				status = "okay";
>> +			};
>> +
>> +			dbgu: serial at fffff200 {
>> +				status = "okay";
>> +			};
>> +
>> +			pinctrl at fffff400 {
>> +				board {
>> +					pinctrl_pck0_as_mck: pck0_as_mck {
>> +						atmel,pins =
>> +							<2 1 0x2 0x0>;	/* PC1 periph B */
>> +					};
>> +				};
>> +
>> +				mmc0_slot1 {
>> +					pinctrl_board_mmc0_slot1: mmc0_slot1-board {
>> +						atmel,pins =
>> +							<2 9 0x0 0x5>;	/* PC9 gpio CD pin pull up and deglitch */
>> +					};
>> +				};
>> +
>> +				i2c0 {
>> +					pinctrl_i2c0: i2c0-0 {
>> +						atmel,pins =
>> +							<0 23 0x1 0x2	/* TWD (SDA) PA23 periph A, open drain */
>> +							 0 24 0x1 0x2>;	/* TWCK (SCL) PA24 periph A, open drain */
>> +					};
>> +				};
>> +			};
>> +
>> +			watchdog at fffffd40 {
>> +				status = "okay";
>> +			};
>> +		};
>> +
>> +		usb0: ohci at 00500000 {
>> +			num-ports = <2>;
>> +			status = "okay";
>> +		};
>> +	};
>> +
>> +	i2c at 0 {
>> +		pinctrl-names = "default";
>> +		pinctrl-0 = <&pinctrl_i2c0>;
>> +		i2c-gpio,delay-us = <5>;	/* ~85 kHz */
>> +		status = "okay";
>> +	};
>> +
>> +	leds {
>> +		compatible = "gpio-leds";
>> +
>> +		/* red LED marked "PC7" near mini USB (device) receptacle */
>> +		user_led {
>> +			label = "user_led";
>> +			gpios = <&pioC 7 0>;	/* PC7 */
>> +			linux,default-trigger = "heartbeat";
>> +		};
>> +	};
>> +
>> +	gpio_keys {
>> +		compatible = "gpio-keys";
>> +
>> +		btn {
>> +			label = "Button";
>> +			gpios = <&pioC 4 1>;
>> +			linux,code = <0x103>;
>> +			gpio-key,wakeup;
>> +		};
>> +	};
>> +};
>>
> 
> 


-- 
Nicolas Ferre


From will.deacon at arm.com  Fri Apr 19 05:05:59 2013
From: will.deacon at arm.com (Will Deacon)
Date: Fri, 19 Apr 2013 10:05:59 +0100
Subject: [RFC] arm64: Early printk support for virtio-mmio console devices.
In-Reply-To: <CAAHg+HhtCorArCmx=ha0=64+SJZiizzrDUKSPLV=N+OzO8zAxQ@mail.gmail.com>
References: <1366264344-28025-1-git-send-email-pranavkumar@linaro.org>
 <ede8ee08bb2616c2ed642200e3357367@localhost>
 <CAAHg+HhajHFC=1nh6YQNgpf=Na2FqcsYJ=t+ag9QiTg6TxUz9w@mail.gmail.com>
 <bb1193983de3ea9f4df1a570441df34c@localhost>
 <CAAHg+HhtCorArCmx=ha0=64+SJZiizzrDUKSPLV=N+OzO8zAxQ@mail.gmail.com>
Message-ID: <20130419090558.GA13283@mudshark.cambridge.arm.com>

Hello,

On Thu, Apr 18, 2013 at 09:48:49AM +0100, Pranavkumar Sawargaonkar wrote:
> Actually i thought adding a config register will be easier to add a
> code than writing entire emulation as 8250 emulation will require to
> deal with dealing with more registers and more code.

kvmtool already has an 8250 emulation! All we need to do is hack together
something which will allow us to instantiate those ioport devices in a more
flexible manner (namely, inside the MMIO space for ARM). For earlyprintk, I
suspect we can get away without an interrupt too, which should simplify
things a bit to start with.

Regardless of the outcome of this discussion, I think getting the 8250
working on ARM is definitely something worth doing. If I get time, I'll take
a look.

Will


From grant.likely at secretlab.ca  Fri Apr 19 05:09:33 2013
From: grant.likely at secretlab.ca (Grant Likely)
Date: Fri, 19 Apr 2013 10:09:33 +0100
Subject: [PATCH v3 1/6] drivers: phy: add generic PHY framework
In-Reply-To: <516D255F.40604@ti.com>
References: <1363770725-13717-1-git-send-email-kishon@ti.com>
 <1363770725-13717-2-git-send-email-kishon@ti.com>
 <20130415113416.7C3943E0AA8@localhost> <516BF1E2.3020104@ti.com>
 <20130415195030.9F7E93E0AA8@localhost> <516D255F.40604@ti.com>
Message-ID: <20130419090933.AB4253E116D@localhost>

On Tue, 16 Apr 2013 15:48:07 +0530, Kishon Vijay Abraham I <kishon at ti.com> wrote:
> On Tuesday 16 April 2013 01:20 AM, Grant Likely wrote:
> > On Mon, 15 Apr 2013 17:56:10 +0530, Kishon Vijay Abraham I <kishon at ti.com> wrote:
> >> On Monday 15 April 2013 05:04 PM, Grant Likely wrote:
> >>> On Wed, 20 Mar 2013 14:42:00 +0530, Kishon Vijay Abraham I <kishon at ti.com> wrote:
> >> We have decided not to implement the PHY layer as a separate bus layer.
> >> The PHY provider can be part of any other bus. Making the PHY layer as a
> >> bus will make the PHY provider to be part of multiple buses which will
> >> lead to bad design. All we are trying to do here is keep the pool of PHY
> >> devices under PHY class in this layer and help any controller that wants
> >> to use the PHY to get it.
> >
> > If you're using a class, then you already have your list of registered
> > phy devices! :-) No need to create another global list that you need to
> > manage.
> 
> right. We already use _class_dev_iter_ for finding the phy device.
> .
> .
> +static struct phy *of_phy_lookup(struct device *dev, struct device_node 
> *node)
> +{
> +	struct phy *phy;
> +	struct class_dev_iter iter;
> +
> +	class_dev_iter_init(&iter, phy_class, NULL, NULL);
> +	while ((dev = class_dev_iter_next(&iter))) {
> +		phy = container_of(dev, struct phy, dev);
> +		if (node != phy->of_node)
> +			continue;
> +
> +		class_dev_iter_exit(&iter);
> +		return phy;
> +	}
> +
> +	class_dev_iter_exit(&iter);
> +	return ERR_PTR(-EPROBE_DEFER);
> +}
> .
> .
> 
> however we can't get rid of the other list (phy_bind_list) where we 
> maintain the phy binding information. It's used for the non-dt boot case.

Why? If you're using a class, then it is always there. Why would non-DT
and DT be different in this regard? (more below)

> >>> Since there is at most a 1:N relationship between host controllers and
> >>> PHYs, there shouldn't be any need for a separate structure to describe
> >>> binding. Put the inding data into the struct phy itself. Each host
> >>> controller can have a list of phys that it is bound to.
> >>
> >> No. Having the host controller to have a list of phys wont be a good
> >> idea IMHO. The host controller is just an IP and the PHY to which it
> >> will be connected can vary from board to board, platform to platform. So
> >> ideally this binding should come from platform initialization code/dt data.
> >
> > That is not what I mean. I mean the host controller instance should
> > contain a list of all the PHYs that are attached to it. There should not
> 
> Doesn't sound correct IMO. The host controller instance need not know 
> anything about the PHY instances that is connected to it. Think of it 
> similar to regulator, the controller wouldn't know which regulator it is 
> connected to, all it has to know is it just has a regulator connected to 
> it. It's up-to the regulator framework to give the controller the 
> correct regulator. It's similar here. It makes sense for me to keep a 
> list in the PHY framework in order for it to return the correct PHY (but 
> note that this list is not needed for dt boot).

With regulators and clocks it makes sense to have a global
registration place becase both implement an interconnected network
independent of the device that use them. (clocks depend on other clocks;
regulators depend on other regulators).

Phys are different. There is a 1:N relationship between host controllers
and phys, and you don't get a interconnected network of PHYs. Its a bad
idea to keep the binding data separate from the actual host controller
when there is nothing else that actually needs to use the data. It
creates a new set of data structures that need housekeeping to keep them
in sync with the actual device structures. It really is just a bad idea
and it becomes more difficult (in the non-DT case) to determine what
data is associated with a given host controller. You can't tell by
looking at the struct device.

Instead, for the non-DT case, do what we've always done for describing
connections. Put the phy reference into the host controllers
platform_data structure. That is what it is there for. That completely
eliminates the need to housekeep a new set of data structures.

g.


From ludovic.desroches at atmel.com  Fri Apr 19 05:11:17 2013
From: ludovic.desroches at atmel.com (ludovic.desroches at atmel.com)
Date: Fri, 19 Apr 2013 11:11:17 +0200
Subject: [PATCH v3 0/6] ARM: at91: move to generic DMA device tree binding
Message-ID: <1366362683-14496-1-git-send-email-ludovic.desroches@atmel.com>

From: Ludovic Desroches <ludovic.desroches at atmel.com>

Hi,

I resend the set of patches due to minor fixes. I think patches will go through
different subsytems.

Patch 1/6: dma subsystem
Patch 2/6, 4/6, 6/6: arm-soc
Patch 3/6: i2c subsystem, already taken by Wolfram, thx.
Patch 5/6: mmc subsystem

v3 changes:
- compile at_dma_filter function only if CONFIG_OF is set since it is only used
in at_dma_xlate
- remove trailing whitespaces in patch 5/6

v2 changes:
- update documentation about dma bindings according to Nicolas' comments
- put dtsi changes in a separate patch
- add dtb update for i2c and mci nodes

Ludovic Desroches (6):
  at_hdmac: move to generic DMA binding
  ARM: at91: dts: set #dma-cells to the correct value
  i2c: at91: convert to dma_request_slave_channel_compat()
  ARM: at91: dts: add i2c dma support
  mci: at91: convert to dma_request_slave_channel_compat()
  ARM: at91: dts: add MCI DMA support

 .../devicetree/bindings/dma/atmel-dma.txt          | 35 ++++++--
 arch/arm/boot/dts/at91sam9g45.dtsi                 |  5 ++
 arch/arm/boot/dts/at91sam9n12.dtsi                 |  9 +++
 arch/arm/boot/dts/at91sam9x5.dtsi                  | 15 ++++
 arch/arm/boot/dts/sama5d3.dtsi                     | 19 ++++-
 drivers/dma/at_hdmac.c                             | 93 ++++++++++++++++++++--
 drivers/dma/at_hdmac_regs.h                        |  4 +
 drivers/i2c/busses/i2c-at91.c                      | 49 ++++++------
 drivers/mmc/host/atmel-mci.c                       | 25 +++---
 9 files changed, 204 insertions(+), 50 deletions(-)

-- 
1.7.11.3



From ludovic.desroches at atmel.com  Fri Apr 19 05:11:18 2013
From: ludovic.desroches at atmel.com (ludovic.desroches at atmel.com)
Date: Fri, 19 Apr 2013 11:11:18 +0200
Subject: [PATCH v3 1/6] at_hdmac: move to generic DMA binding
In-Reply-To: <1366362683-14496-1-git-send-email-ludovic.desroches@atmel.com>
References: <1366362683-14496-1-git-send-email-ludovic.desroches@atmel.com>
Message-ID: <1366362683-14496-2-git-send-email-ludovic.desroches@atmel.com>

From: Ludovic Desroches <ludovic.desroches at atmel.com>

Update at_hdmac driver to support generic DMA device tree binding. Devices
can still request channel with dma_request_channel() then it doesn't break
DMA for non DT boards.

Signed-off-by: Ludovic Desroches <ludovic.desroches at atmel.com>
Acked-by: Nicolas Ferre <nicolas.ferre at atmel.com>
Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
Acked-by: Arnd Bergmann <arnd at arndb.de>
---
 .../devicetree/bindings/dma/atmel-dma.txt          | 35 ++++++--
 drivers/dma/at_hdmac.c                             | 93 ++++++++++++++++++++--
 drivers/dma/at_hdmac_regs.h                        |  4 +
 3 files changed, 121 insertions(+), 11 deletions(-)

diff --git a/Documentation/devicetree/bindings/dma/atmel-dma.txt b/Documentation/devicetree/bindings/dma/atmel-dma.txt
index 3c046ee..c80e8a3 100644
--- a/Documentation/devicetree/bindings/dma/atmel-dma.txt
+++ b/Documentation/devicetree/bindings/dma/atmel-dma.txt
@@ -1,14 +1,39 @@
 * Atmel Direct Memory Access Controller (DMA)
 
 Required properties:
-- compatible: Should be "atmel,<chip>-dma"
-- reg: Should contain DMA registers location and length
-- interrupts: Should contain DMA interrupt
+- compatible: Should be "atmel,<chip>-dma".
+- reg: Should contain DMA registers location and length.
+- interrupts: Should contain DMA interrupt.
+- #dma-cells: Must be <2>, used to represent the number of integer cells in
+the dmas property of client devices.
 
-Examples:
+Example:
 
-dma at ffffec00 {
+dma0: dma at ffffec00 {
 	compatible = "atmel,at91sam9g45-dma";
 	reg = <0xffffec00 0x200>;
 	interrupts = <21>;
+	#dma-cells = <2>;
+};
+
+DMA clients connected to the Atmel DMA controller must use the format
+described in the dma.txt file, using a three-cell specifier for each channel:
+a phandle plus two interger cells.
+The three cells in order are:
+
+1. A phandle pointing to the DMA controller.
+2. The memory interface (16 most significant bits), the peripheral interface
+(16 less significant bits).
+3. The peripheral identifier for the hardware handshaking interface. The
+identifier can be different for tx and rx.
+
+Example:
+
+i2c0 at i2c@f8010000 {
+	compatible = "atmel,at91sam9x5-i2c";
+	reg = <0xf8010000 0x100>;
+	interrupts = <9 4 6>;
+	dmas = <&dma0 1 7>,
+	       <&dma0 1 8>;
+	dma-names = "tx", "rx";
 };
diff --git a/drivers/dma/at_hdmac.c b/drivers/dma/at_hdmac.c
index de4e930..fda2661 100644
--- a/drivers/dma/at_hdmac.c
+++ b/drivers/dma/at_hdmac.c
@@ -24,6 +24,7 @@
 #include <linux/slab.h>
 #include <linux/of.h>
 #include <linux/of_device.h>
+#include <linux/of_dma.h>
 
 #include "at_hdmac_regs.h"
 #include "dmaengine.h"
@@ -677,7 +678,7 @@ atc_prep_slave_sg(struct dma_chan *chan, struct scatterlist *sgl,
 		ctrlb |=  ATC_DST_ADDR_MODE_FIXED
 			| ATC_SRC_ADDR_MODE_INCR
 			| ATC_FC_MEM2PER
-			| ATC_SIF(AT_DMA_MEM_IF) | ATC_DIF(AT_DMA_PER_IF);
+			| ATC_SIF(atchan->mem_if) | ATC_DIF(atchan->per_if);
 		reg = sconfig->dst_addr;
 		for_each_sg(sgl, sg, sg_len, i) {
 			struct at_desc	*desc;
@@ -716,7 +717,7 @@ atc_prep_slave_sg(struct dma_chan *chan, struct scatterlist *sgl,
 		ctrlb |=  ATC_DST_ADDR_MODE_INCR
 			| ATC_SRC_ADDR_MODE_FIXED
 			| ATC_FC_PER2MEM
-			| ATC_SIF(AT_DMA_PER_IF) | ATC_DIF(AT_DMA_MEM_IF);
+			| ATC_SIF(atchan->per_if) | ATC_DIF(atchan->mem_if);
 
 		reg = sconfig->src_addr;
 		for_each_sg(sgl, sg, sg_len, i) {
@@ -822,8 +823,8 @@ atc_dma_cyclic_fill_desc(struct dma_chan *chan, struct at_desc *desc,
 		desc->lli.ctrlb = ATC_DST_ADDR_MODE_FIXED
 				| ATC_SRC_ADDR_MODE_INCR
 				| ATC_FC_MEM2PER
-				| ATC_SIF(AT_DMA_MEM_IF)
-				| ATC_DIF(AT_DMA_PER_IF);
+				| ATC_SIF(atchan->mem_if)
+				| ATC_DIF(atchan->per_if);
 		break;
 
 	case DMA_DEV_TO_MEM:
@@ -833,8 +834,8 @@ atc_dma_cyclic_fill_desc(struct dma_chan *chan, struct at_desc *desc,
 		desc->lli.ctrlb = ATC_DST_ADDR_MODE_INCR
 				| ATC_SRC_ADDR_MODE_FIXED
 				| ATC_FC_PER2MEM
-				| ATC_SIF(AT_DMA_PER_IF)
-				| ATC_DIF(AT_DMA_MEM_IF);
+				| ATC_SIF(atchan->per_if)
+				| ATC_DIF(atchan->mem_if);
 		break;
 
 	default:
@@ -1190,6 +1191,67 @@ static void atc_free_chan_resources(struct dma_chan *chan)
 	dev_vdbg(chan2dev(chan), "free_chan_resources: done\n");
 }
 
+#ifdef CONFIG_OF
+static bool at_dma_filter(struct dma_chan *chan, void *slave)
+{
+	struct at_dma_slave *atslave = slave;
+
+	if (atslave->dma_dev == chan->device->dev) {
+		chan->private = atslave;
+		return true;
+	} else {
+		return false;
+	}
+}
+
+static struct dma_chan *at_dma_xlate(struct of_phandle_args *dma_spec,
+				     struct of_dma *of_dma)
+{
+	struct dma_chan *chan;
+	struct at_dma_chan *atchan;
+	struct at_dma_slave *atslave;
+	dma_cap_mask_t mask;
+	unsigned int per_id;
+	struct platform_device *dmac_pdev;
+
+	if (dma_spec->args_count != 2)
+		return NULL;
+
+	dmac_pdev = of_find_device_by_node(dma_spec->np);
+
+	dma_cap_zero(mask);
+	dma_cap_set(DMA_SLAVE, mask);
+
+	atslave = devm_kzalloc(&dmac_pdev->dev, sizeof(*atslave), GFP_KERNEL);
+	if (!atslave)
+		return NULL;
+	/*
+	 * We can fill both SRC_PER and DST_PER, one of these fields will be
+	 * ignored depending on DMA transfer direction.
+	 */
+	per_id = dma_spec->args[1];
+	atslave->cfg = ATC_FIFOCFG_HALFFIFO | ATC_DST_H2SEL_HW
+		      | ATC_SRC_H2SEL_HW | ATC_DST_PER(per_id)
+		      | ATC_SRC_PER(per_id);
+	atslave->dma_dev = &dmac_pdev->dev;
+
+	chan = dma_request_channel(mask, at_dma_filter, atslave);
+	if (!chan)
+		return NULL;
+
+	atchan = to_at_dma_chan(chan);
+	atchan->per_if = dma_spec->args[0] & 0xff;
+	atchan->mem_if = (dma_spec->args[0] >> 16) & 0xff;
+
+	return chan;
+}
+#else
+static struct dma_chan *at_dma_xlate(struct of_phandle_args *dma_spec,
+				     struct of_dma *of_dma)
+{
+	return NULL;
+}
+#endif
 
 /*--  Module Management  -----------------------------------------------*/
 
@@ -1344,6 +1406,8 @@ static int __init at_dma_probe(struct platform_device *pdev)
 	for (i = 0; i < plat_dat->nr_channels; i++) {
 		struct at_dma_chan	*atchan = &atdma->chan[i];
 
+		atchan->mem_if = AT_DMA_MEM_IF;
+		atchan->per_if = AT_DMA_PER_IF;
 		atchan->chan_common.device = &atdma->dma_common;
 		dma_cookie_init(&atchan->chan_common);
 		list_add_tail(&atchan->chan_common.device_node,
@@ -1390,8 +1454,25 @@ static int __init at_dma_probe(struct platform_device *pdev)
 
 	dma_async_device_register(&atdma->dma_common);
 
+	/*
+	 * Do not return an error if the dmac node is not present in order to
+	 * not break the existing way of requesting channel with
+	 * dma_request_channel().
+	 */
+	if (pdev->dev.of_node) {
+		err = of_dma_controller_register(pdev->dev.of_node,
+						 at_dma_xlate, atdma);
+		if (err) {
+			dev_err(&pdev->dev, "could not register of_dma_controller\n");
+			goto err_of_dma_controller_register;
+		}
+	}
+
 	return 0;
 
+err_of_dma_controller_register:
+	dma_async_device_unregister(&atdma->dma_common);
+	dma_pool_destroy(atdma->dma_desc_pool);
 err_pool_create:
 	platform_set_drvdata(pdev, NULL);
 	free_irq(platform_get_irq(pdev, 0), atdma);
diff --git a/drivers/dma/at_hdmac_regs.h b/drivers/dma/at_hdmac_regs.h
index 0eb3c13..c604d26 100644
--- a/drivers/dma/at_hdmac_regs.h
+++ b/drivers/dma/at_hdmac_regs.h
@@ -220,6 +220,8 @@ enum atc_status {
  * @device: parent device
  * @ch_regs: memory mapped register base
  * @mask: channel index in a mask
+ * @per_if: peripheral interface
+ * @mem_if: memory interface
  * @status: transmit status information from irq/prep* functions
  *                to tasklet (use atomic operations)
  * @tasklet: bottom half to finish transaction work
@@ -238,6 +240,8 @@ struct at_dma_chan {
 	struct at_dma		*device;
 	void __iomem		*ch_regs;
 	u8			mask;
+	u8			per_if;
+	u8			mem_if;
 	unsigned long		status;
 	struct tasklet_struct	tasklet;
 	u32			save_cfg;
-- 
1.7.11.3



From ludovic.desroches at atmel.com  Fri Apr 19 05:11:19 2013
From: ludovic.desroches at atmel.com (ludovic.desroches at atmel.com)
Date: Fri, 19 Apr 2013 11:11:19 +0200
Subject: [PATCH v3 2/6] ARM: at91: dts: set #dma-cells to the correct value
In-Reply-To: <1366362683-14496-1-git-send-email-ludovic.desroches@atmel.com>
References: <1366362683-14496-1-git-send-email-ludovic.desroches@atmel.com>
Message-ID: <1366362683-14496-3-git-send-email-ludovic.desroches@atmel.com>

From: Ludovic Desroches <ludovic.desroches at atmel.com>

Moving to generic DMA DT binding involves to set #dma-cells to 2.

Signed-off-by: Ludovic Desroches <ludovic.desroches at atmel.com>
---
 arch/arm/boot/dts/at91sam9g45.dtsi | 1 +
 arch/arm/boot/dts/at91sam9n12.dtsi | 1 +
 arch/arm/boot/dts/at91sam9x5.dtsi  | 2 ++
 arch/arm/boot/dts/sama5d3.dtsi     | 4 ++--
 4 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/at91sam9g45.dtsi b/arch/arm/boot/dts/at91sam9g45.dtsi
index 6b1d4ca..275e768 100644
--- a/arch/arm/boot/dts/at91sam9g45.dtsi
+++ b/arch/arm/boot/dts/at91sam9g45.dtsi
@@ -108,6 +108,7 @@
 				compatible = "atmel,at91sam9g45-dma";
 				reg = <0xffffec00 0x200>;
 				interrupts = <21 4 0>;
+				#dma-cells = <2>;
 			};
 
 			pinctrl at fffff200 {
diff --git a/arch/arm/boot/dts/at91sam9n12.dtsi b/arch/arm/boot/dts/at91sam9n12.dtsi
index 7750f98..acc4526 100644
--- a/arch/arm/boot/dts/at91sam9n12.dtsi
+++ b/arch/arm/boot/dts/at91sam9n12.dtsi
@@ -110,6 +110,7 @@
 				compatible = "atmel,at91sam9g45-dma";
 				reg = <0xffffec00 0x200>;
 				interrupts = <20 4 0>;
+				#dma-cells = <2>;
 			};
 
 			pinctrl at fffff400 {
diff --git a/arch/arm/boot/dts/at91sam9x5.dtsi b/arch/arm/boot/dts/at91sam9x5.dtsi
index 3870322..8e83d87 100644
--- a/arch/arm/boot/dts/at91sam9x5.dtsi
+++ b/arch/arm/boot/dts/at91sam9x5.dtsi
@@ -104,12 +104,14 @@
 				compatible = "atmel,at91sam9g45-dma";
 				reg = <0xffffec00 0x200>;
 				interrupts = <20 4 0>;
+				#dma-cells = <2>;
 			};
 
 			dma1: dma-controller at ffffee00 {
 				compatible = "atmel,at91sam9g45-dma";
 				reg = <0xffffee00 0x200>;
 				interrupts = <21 4 0>;
+				#dma-cells = <2>;
 			};
 
 			pinctrl at fffff400 {
diff --git a/arch/arm/boot/dts/sama5d3.dtsi b/arch/arm/boot/dts/sama5d3.dtsi
index 39b0458..95c00a3 100644
--- a/arch/arm/boot/dts/sama5d3.dtsi
+++ b/arch/arm/boot/dts/sama5d3.dtsi
@@ -348,14 +348,14 @@
 				compatible = "atmel,at91sam9g45-dma";
 				reg = <0xffffe600 0x200>;
 				interrupts = <30 4 0>;
-				#dma-cells = <1>;
+				#dma-cells = <2>;
 			};
 
 			dma1: dma-controller at ffffe800 {
 				compatible = "atmel,at91sam9g45-dma";
 				reg = <0xffffe800 0x200>;
 				interrupts = <31 4 0>;
-				#dma-cells = <1>;
+				#dma-cells = <2>;
 			};
 
 			ramc0: ramc at ffffea00 {
-- 
1.7.11.3



From ludovic.desroches at atmel.com  Fri Apr 19 05:11:20 2013
From: ludovic.desroches at atmel.com (ludovic.desroches at atmel.com)
Date: Fri, 19 Apr 2013 11:11:20 +0200
Subject: [PATCH v3 3/6] i2c: at91: convert to
 dma_request_slave_channel_compat()
In-Reply-To: <1366362683-14496-1-git-send-email-ludovic.desroches@atmel.com>
References: <1366362683-14496-1-git-send-email-ludovic.desroches@atmel.com>
Message-ID: <1366362683-14496-4-git-send-email-ludovic.desroches@atmel.com>

From: Ludovic Desroches <ludovic.desroches at atmel.com>

Use generic DMA DT helper. Platforms booting with or without DT populated are
both supported.

Signed-off-by: Ludovic Desroches <ludovic.desroches at atmel.com>
Acked-by: Nicolas Ferre <nicolas.ferre at atmel.com>
Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
---
 drivers/i2c/busses/i2c-at91.c | 49 ++++++++++++++++++++++---------------------
 1 file changed, 25 insertions(+), 24 deletions(-)

diff --git a/drivers/i2c/busses/i2c-at91.c b/drivers/i2c/busses/i2c-at91.c
index 75195e3..7ffd544 100644
--- a/drivers/i2c/busses/i2c-at91.c
+++ b/drivers/i2c/busses/i2c-at91.c
@@ -607,11 +607,16 @@ MODULE_DEVICE_TABLE(of, atmel_twi_dt_ids);
 #define atmel_twi_dt_ids NULL
 #endif
 
-static bool filter(struct dma_chan *chan, void *slave)
+static bool filter(struct dma_chan *chan, void *pdata)
 {
-	struct at_dma_slave *sl = slave;
+	struct at91_twi_pdata *sl_pdata = pdata;
+	struct at_dma_slave *sl;
 
-	if (sl->dma_dev == chan->device->dev) {
+	if (!sl_pdata)
+		return false;
+
+	sl = &sl_pdata->dma_slave;
+	if (sl && (sl->dma_dev == chan->device->dev)) {
 		chan->private = sl;
 		return true;
 	} else {
@@ -622,11 +627,10 @@ static bool filter(struct dma_chan *chan, void *slave)
 static int at91_twi_configure_dma(struct at91_twi_dev *dev, u32 phy_addr)
 {
 	int ret = 0;
-	struct at_dma_slave *sdata;
+	struct at91_twi_pdata *pdata = dev->pdata;
 	struct dma_slave_config slave_config;
 	struct at91_twi_dma *dma = &dev->dma;
-
-	sdata = &dev->pdata->dma_slave;
+	dma_cap_mask_t mask;
 
 	memset(&slave_config, 0, sizeof(slave_config));
 	slave_config.src_addr = (dma_addr_t)phy_addr + AT91_TWI_RHR;
@@ -637,25 +641,22 @@ static int at91_twi_configure_dma(struct at91_twi_dev *dev, u32 phy_addr)
 	slave_config.dst_maxburst = 1;
 	slave_config.device_fc = false;
 
-	if (sdata && sdata->dma_dev) {
-		dma_cap_mask_t mask;
+	dma_cap_zero(mask);
+	dma_cap_set(DMA_SLAVE, mask);
 
-		dma_cap_zero(mask);
-		dma_cap_set(DMA_SLAVE, mask);
-		dma->chan_tx = dma_request_channel(mask, filter, sdata);
-		if (!dma->chan_tx) {
-			dev_err(dev->dev, "no DMA channel available for tx\n");
-			ret = -EBUSY;
-			goto error;
-		}
-		dma->chan_rx = dma_request_channel(mask, filter, sdata);
-		if (!dma->chan_rx) {
-			dev_err(dev->dev, "no DMA channel available for rx\n");
-			ret = -EBUSY;
-			goto error;
-		}
-	} else {
-		ret = -EINVAL;
+	dma->chan_tx = dma_request_slave_channel_compat(mask, filter, pdata,
+							dev->dev, "tx");
+	if (!dma->chan_tx) {
+		dev_err(dev->dev, "can't get a DMA channel for tx\n");
+		ret = -EBUSY;
+		goto error;
+	}
+
+	dma->chan_rx = dma_request_slave_channel_compat(mask, filter, pdata,
+							dev->dev, "rx");
+	if (!dma->chan_rx) {
+		dev_err(dev->dev, "can't get a DMA channel for rx\n");
+		ret = -EBUSY;
 		goto error;
 	}
 
-- 
1.7.11.3



From ludovic.desroches at atmel.com  Fri Apr 19 05:11:22 2013
From: ludovic.desroches at atmel.com (ludovic.desroches at atmel.com)
Date: Fri, 19 Apr 2013 11:11:22 +0200
Subject: [PATCH v3 5/6] mci: at91: convert to
 dma_request_slave_channel_compat()
In-Reply-To: <1366362683-14496-1-git-send-email-ludovic.desroches@atmel.com>
References: <1366362683-14496-1-git-send-email-ludovic.desroches@atmel.com>
Message-ID: <1366362683-14496-6-git-send-email-ludovic.desroches@atmel.com>

From: Ludovic Desroches <ludovic.desroches at atmel.com>

Use generic DMA DT helper. Platforms booting with or without DT populated are
both supported.

Signed-off-by: Ludovic Desroches <ludovic.desroches at atmel.com>
Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
Acked-by: Nicolas Ferre <nicolas.ferre at atmel.com>
---
 drivers/mmc/host/atmel-mci.c | 25 ++++++++++++-------------
 1 file changed, 12 insertions(+), 13 deletions(-)

diff --git a/drivers/mmc/host/atmel-mci.c b/drivers/mmc/host/atmel-mci.c
index 10f8b73..ffbd0d3 100644
--- a/drivers/mmc/host/atmel-mci.c
+++ b/drivers/mmc/host/atmel-mci.c
@@ -2224,10 +2224,15 @@ static void __exit atmci_cleanup_slot(struct atmel_mci_slot *slot,
 	mmc_free_host(slot->mmc);
 }
 
-static bool atmci_filter(struct dma_chan *chan, void *slave)
+static bool atmci_filter(struct dma_chan *chan, void *pdata)
 {
-	struct mci_dma_data	*sl = slave;
+	struct mci_platform_data *sl_pdata = pdata;
+	struct mci_dma_data *sl;
 
+	if (!sl_pdata)
+		return false;
+
+	sl = sl_pdata->dma_slave;
 	if (sl && find_slave_dev(sl) == chan->device->dev) {
 		chan->private = slave_data_ptr(sl);
 		return true;
@@ -2239,24 +2244,18 @@ static bool atmci_filter(struct dma_chan *chan, void *slave)
 static bool atmci_configure_dma(struct atmel_mci *host)
 {
 	struct mci_platform_data	*pdata;
+	dma_cap_mask_t mask;
 
 	if (host == NULL)
 		return false;
 
 	pdata = host->pdev->dev.platform_data;
 
-	if (!pdata)
-		return false;
+	dma_cap_zero(mask);
+	dma_cap_set(DMA_SLAVE, mask);
 
-	if (pdata->dma_slave && find_slave_dev(pdata->dma_slave)) {
-		dma_cap_mask_t mask;
-
-		/* Try to grab a DMA channel */
-		dma_cap_zero(mask);
-		dma_cap_set(DMA_SLAVE, mask);
-		host->dma.chan =
-			dma_request_channel(mask, atmci_filter, pdata->dma_slave);
-	}
+	host->dma.chan = dma_request_slave_channel_compat(mask, atmci_filter, pdata,
+							  &host->pdev->dev, "rxtx");
 	if (!host->dma.chan) {
 		dev_warn(&host->pdev->dev, "no DMA channel available\n");
 		return false;
-- 
1.7.11.3



From ludovic.desroches at atmel.com  Fri Apr 19 05:11:23 2013
From: ludovic.desroches at atmel.com (ludovic.desroches at atmel.com)
Date: Fri, 19 Apr 2013 11:11:23 +0200
Subject: [PATCH v3 6/6] ARM: at91: dts: add MCI DMA support
In-Reply-To: <1366362683-14496-1-git-send-email-ludovic.desroches@atmel.com>
References: <1366362683-14496-1-git-send-email-ludovic.desroches@atmel.com>
Message-ID: <1366362683-14496-7-git-send-email-ludovic.desroches@atmel.com>

From: Ludovic Desroches <ludovic.desroches at atmel.com>

Add DMA resources to MCI nodes.

Signed-off-by: Ludovic Desroches <ludovic.desroches at atmel.com>
---
 arch/arm/boot/dts/at91sam9g45.dtsi | 4 ++++
 arch/arm/boot/dts/at91sam9n12.dtsi | 2 ++
 arch/arm/boot/dts/at91sam9x5.dtsi  | 4 ++++
 arch/arm/boot/dts/sama5d3.dtsi     | 6 ++++++
 4 files changed, 16 insertions(+)

diff --git a/arch/arm/boot/dts/at91sam9g45.dtsi b/arch/arm/boot/dts/at91sam9g45.dtsi
index 275e768..de2abc0 100644
--- a/arch/arm/boot/dts/at91sam9g45.dtsi
+++ b/arch/arm/boot/dts/at91sam9g45.dtsi
@@ -513,6 +513,8 @@
 				compatible = "atmel,hsmci";
 				reg = <0xfff80000 0x600>;
 				interrupts = <11 4 0>;
+				dmas = <&dma0 1 0>;
+				dma-names = "rxtx";
 				#address-cells = <1>;
 				#size-cells = <0>;
 				status = "disabled";
@@ -522,6 +524,8 @@
 				compatible = "atmel,hsmci";
 				reg = <0xfffd0000 0x600>;
 				interrupts = <29 4 0>;
+				dmas = <&dma0 1 13>;
+				dma-names = "rxtx";
 				#address-cells = <1>;
 				#size-cells = <0>;
 				status = "disabled";
diff --git a/arch/arm/boot/dts/at91sam9n12.dtsi b/arch/arm/boot/dts/at91sam9n12.dtsi
index f912124..0b61c41 100644
--- a/arch/arm/boot/dts/at91sam9n12.dtsi
+++ b/arch/arm/boot/dts/at91sam9n12.dtsi
@@ -89,6 +89,8 @@
 				compatible = "atmel,hsmci";
 				reg = <0xf0008000 0x600>;
 				interrupts = <12 4 0>;
+				dmas = <&dma0 1 0>
+				dma-names = "rxtx";
 				#address-cells = <1>;
 				#size-cells = <0>;
 				status = "disabled";
diff --git a/arch/arm/boot/dts/at91sam9x5.dtsi b/arch/arm/boot/dts/at91sam9x5.dtsi
index 16c9b81..5f42e7a 100644
--- a/arch/arm/boot/dts/at91sam9x5.dtsi
+++ b/arch/arm/boot/dts/at91sam9x5.dtsi
@@ -449,6 +449,8 @@
 				compatible = "atmel,hsmci";
 				reg = <0xf0008000 0x600>;
 				interrupts = <12 4 0>;
+				dmas = <&dma0 1 0>;
+				dma-names = "rxtx";
 				#address-cells = <1>;
 				#size-cells = <0>;
 				status = "disabled";
@@ -458,6 +460,8 @@
 				compatible = "atmel,hsmci";
 				reg = <0xf000c000 0x600>;
 				interrupts = <26 4 0>;
+				dmas = <&dma1 1 0>;
+				dma-names = "rxtx";
 				#address-cells = <1>;
 				#size-cells = <0>;
 				status = "disabled";
diff --git a/arch/arm/boot/dts/sama5d3.dtsi b/arch/arm/boot/dts/sama5d3.dtsi
index 8e87277..2e643ea 100644
--- a/arch/arm/boot/dts/sama5d3.dtsi
+++ b/arch/arm/boot/dts/sama5d3.dtsi
@@ -60,6 +60,8 @@
 				compatible = "atmel,hsmci";
 				reg = <0xf0000000 0x600>;
 				interrupts = <21 4 0>;
+				dmas = <&dma0 2 0>;
+				dma-names = "rxtx";
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_mmc0_clk_cmd_dat0 &pinctrl_mmc0_dat1_3 &pinctrl_mmc0_dat4_7>;
 				status = "disabled";
@@ -173,6 +175,8 @@
 				compatible = "atmel,hsmci";
 				reg = <0xf8000000 0x600>;
 				interrupts = <22 4 0>;
+				dmas = <&dma1 2 0>;
+				dma-names = "rxtx";
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_mmc1_clk_cmd_dat0 &pinctrl_mmc1_dat1_3>;
 				status = "disabled";
@@ -184,6 +188,8 @@
 				compatible = "atmel,hsmci";
 				reg = <0xf8004000 0x600>;
 				interrupts = <23 4 0>;
+				dmas = <&dma1 2 1>;
+				dma-names = "rxtx";
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_mmc2_clk_cmd_dat0 &pinctrl_mmc2_dat1_3>;
 				status = "disabled";
-- 
1.7.11.3



From ludovic.desroches at atmel.com  Fri Apr 19 05:11:21 2013
From: ludovic.desroches at atmel.com (ludovic.desroches at atmel.com)
Date: Fri, 19 Apr 2013 11:11:21 +0200
Subject: [PATCH v3 4/6] ARM: at91: dts: add i2c dma support
In-Reply-To: <1366362683-14496-1-git-send-email-ludovic.desroches@atmel.com>
References: <1366362683-14496-1-git-send-email-ludovic.desroches@atmel.com>
Message-ID: <1366362683-14496-5-git-send-email-ludovic.desroches@atmel.com>

From: Ludovic Desroches <ludovic.desroches at atmel.com>

Add DMA resources to i2c nodes.

Signed-off-by: Ludovic Desroches <ludovic.desroches at atmel.com>
---
 arch/arm/boot/dts/at91sam9n12.dtsi | 6 ++++++
 arch/arm/boot/dts/at91sam9x5.dtsi  | 9 +++++++++
 arch/arm/boot/dts/sama5d3.dtsi     | 9 +++++++++
 3 files changed, 24 insertions(+)

diff --git a/arch/arm/boot/dts/at91sam9n12.dtsi b/arch/arm/boot/dts/at91sam9n12.dtsi
index acc4526..f912124 100644
--- a/arch/arm/boot/dts/at91sam9n12.dtsi
+++ b/arch/arm/boot/dts/at91sam9n12.dtsi
@@ -361,6 +361,9 @@
 				compatible = "atmel,at91sam9x5-i2c";
 				reg = <0xf8010000 0x100>;
 				interrupts = <9 4 6>;
+				dmas = <&dma0 1 13>,
+				       <&dma0 1 14>;
+				dma-names = "tx", "rx";
 				#address-cells = <1>;
 				#size-cells = <0>;
 				status = "disabled";
@@ -370,6 +373,9 @@
 				compatible = "atmel,at91sam9x5-i2c";
 				reg = <0xf8014000 0x100>;
 				interrupts = <10 4 6>;
+				dmas = <&dma0 1 15>,
+				       <&dma0 1 16>;
+				dma-names = "tx", "rx";
 				#address-cells = <1>;
 				#size-cells = <0>;
 				status = "disabled";
diff --git a/arch/arm/boot/dts/at91sam9x5.dtsi b/arch/arm/boot/dts/at91sam9x5.dtsi
index 8e83d87..16c9b81 100644
--- a/arch/arm/boot/dts/at91sam9x5.dtsi
+++ b/arch/arm/boot/dts/at91sam9x5.dtsi
@@ -519,6 +519,9 @@
 				compatible = "atmel,at91sam9x5-i2c";
 				reg = <0xf8010000 0x100>;
 				interrupts = <9 4 6>;
+				dmas = <&dma0 1 7>,
+				       <&dma0 1 8>;
+				dma-names = "tx", "rx";
 				#address-cells = <1>;
 				#size-cells = <0>;
 				pinctrl-names = "default";
@@ -530,6 +533,9 @@
 				compatible = "atmel,at91sam9x5-i2c";
 				reg = <0xf8014000 0x100>;
 				interrupts = <10 4 6>;
+				dmas = <&dma1 1 5>,
+				       <&dma1 1 6>;
+				dma-names = "tx", "rx";
 				#address-cells = <1>;
 				#size-cells = <0>;
 				pinctrl-names = "default";
@@ -541,6 +547,9 @@
 				compatible = "atmel,at91sam9x5-i2c";
 				reg = <0xf8018000 0x100>;
 				interrupts = <11 4 6>;
+				dmas = <&dma0 1 9>,
+				       <&dma0 1 10>;
+				dma-names = "tx", "rx";
 				#address-cells = <1>;
 				#size-cells = <0>;
 				pinctrl-names = "default";
diff --git a/arch/arm/boot/dts/sama5d3.dtsi b/arch/arm/boot/dts/sama5d3.dtsi
index 95c00a3..8e87277 100644
--- a/arch/arm/boot/dts/sama5d3.dtsi
+++ b/arch/arm/boot/dts/sama5d3.dtsi
@@ -111,6 +111,9 @@
 				compatible = "atmel,at91sam9x5-i2c";
 				reg = <0xf0014000 0x4000>;
 				interrupts = <18 4 6>;
+				dmas = <&dma0 2 7>,
+				       <&dma0 2 8>;
+				dma-names = "tx", "rx";
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_i2c0>;
 				#address-cells = <1>;
@@ -122,6 +125,9 @@
 				compatible = "atmel,at91sam9x5-i2c";
 				reg = <0xf0018000 0x4000>;
 				interrupts = <19 4 6>;
+				dmas = <&dma0 2 9>,
+				       <&dma0 2 10>;
+				dma-names = "tx", "rx";
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_i2c1>;
 				#address-cells = <1>;
@@ -294,6 +300,9 @@
 				compatible = "atmel,at91sam9x5-i2c";
 				reg = <0xf801c000 0x4000>;
 				interrupts = <20 4 6>;
+				dmas = <&dma1 2 11>,
+				       <&dma1 2 12>;
+				dma-names = "tx", "rx";
 				#address-cells = <1>;
 				#size-cells = <0>;
 				status = "disabled";
-- 
1.7.11.3



From pranavkumar at linaro.org  Fri Apr 19 05:25:35 2013
From: pranavkumar at linaro.org (Pranavkumar Sawargaonkar)
Date: Fri, 19 Apr 2013 14:55:35 +0530
Subject: [RFC] arm64: Early printk support for virtio-mmio console devices.
In-Reply-To: <20130419090558.GA13283@mudshark.cambridge.arm.com>
References: <1366264344-28025-1-git-send-email-pranavkumar@linaro.org>
 <ede8ee08bb2616c2ed642200e3357367@localhost>
 <CAAHg+HhajHFC=1nh6YQNgpf=Na2FqcsYJ=t+ag9QiTg6TxUz9w@mail.gmail.com>
 <bb1193983de3ea9f4df1a570441df34c@localhost>
 <CAAHg+HhtCorArCmx=ha0=64+SJZiizzrDUKSPLV=N+OzO8zAxQ@mail.gmail.com>
 <20130419090558.GA13283@mudshark.cambridge.arm.com>
Message-ID: <CAAHg+HipCX2ma6brxj9Kgc3ew39b5e30grLwyun9CViif-5wZQ@mail.gmail.com>

Hi Will,
On 19 April 2013 14:35, Will Deacon <will.deacon at arm.com> wrote:
> Hello,
>
> On Thu, Apr 18, 2013 at 09:48:49AM +0100, Pranavkumar Sawargaonkar wrote:
>> Actually i thought adding a config register will be easier to add a
>> code than writing entire emulation as 8250 emulation will require to
>> deal with dealing with more registers and more code.
>
> kvmtool already has an 8250 emulation! All we need to do is hack together
> something which will allow us to instantiate those ioport devices in a more
> flexible manner (namely, inside the MMIO space for ARM). For earlyprintk, I
> suspect we can get away without an interrupt too, which should simplify
> things a bit to start with.
>
> Regardless of the outcome of this discussion, I think getting the 8250
> working on ARM is definitely something worth doing. If I get time, I'll take
> a look.

I am not against using 8250 emulation (as far as it solves printk
issues for kernel booting logs), but my point is why not to add early
read-write support for virtio console, which also can be useful in
emulation less mach-virt environment also ?

Thanks,
Pranav

>
> Will


From will.deacon at arm.com  Fri Apr 19 05:27:52 2013
From: will.deacon at arm.com (Will Deacon)
Date: Fri, 19 Apr 2013 10:27:52 +0100
Subject: [RFC] arm64: Early printk support for virtio-mmio console devices.
In-Reply-To: <CAAHg+HipCX2ma6brxj9Kgc3ew39b5e30grLwyun9CViif-5wZQ@mail.gmail.com>
References: <1366264344-28025-1-git-send-email-pranavkumar@linaro.org>
 <ede8ee08bb2616c2ed642200e3357367@localhost>
 <CAAHg+HhajHFC=1nh6YQNgpf=Na2FqcsYJ=t+ag9QiTg6TxUz9w@mail.gmail.com>
 <bb1193983de3ea9f4df1a570441df34c@localhost>
 <CAAHg+HhtCorArCmx=ha0=64+SJZiizzrDUKSPLV=N+OzO8zAxQ@mail.gmail.com>
 <20130419090558.GA13283@mudshark.cambridge.arm.com>
 <CAAHg+HipCX2ma6brxj9Kgc3ew39b5e30grLwyun9CViif-5wZQ@mail.gmail.com>
Message-ID: <20130419092752.GB13283@mudshark.cambridge.arm.com>

On Fri, Apr 19, 2013 at 10:25:35AM +0100, Pranavkumar Sawargaonkar wrote:
> On 19 April 2013 14:35, Will Deacon <will.deacon at arm.com> wrote:
> > On Thu, Apr 18, 2013 at 09:48:49AM +0100, Pranavkumar Sawargaonkar wrote:
> >> Actually i thought adding a config register will be easier to add a
> >> code than writing entire emulation as 8250 emulation will require to
> >> deal with dealing with more registers and more code.
> >
> > kvmtool already has an 8250 emulation! All we need to do is hack together
> > something which will allow us to instantiate those ioport devices in a more
> > flexible manner (namely, inside the MMIO space for ARM). For earlyprintk, I
> > suspect we can get away without an interrupt too, which should simplify
> > things a bit to start with.
> >
> > Regardless of the outcome of this discussion, I think getting the 8250
> > working on ARM is definitely something worth doing. If I get time, I'll take
> > a look.
> 
> I am not against using 8250 emulation (as far as it solves printk
> issues for kernel booting logs), but my point is why not to add early
> read-write support for virtio console, which also can be useful in
> emulation less mach-virt environment also ?

We can have both, but only one of those requires a change to the virtio
specification.

Will


From peter.maydell at linaro.org  Fri Apr 19 05:30:40 2013
From: peter.maydell at linaro.org (Peter Maydell)
Date: Fri, 19 Apr 2013 10:30:40 +0100
Subject: [RFC] arm64: Early printk support for virtio-mmio console devices.
In-Reply-To: <20130419092752.GB13283@mudshark.cambridge.arm.com>
References: <1366264344-28025-1-git-send-email-pranavkumar@linaro.org>
 <ede8ee08bb2616c2ed642200e3357367@localhost>
 <CAAHg+HhajHFC=1nh6YQNgpf=Na2FqcsYJ=t+ag9QiTg6TxUz9w@mail.gmail.com>
 <bb1193983de3ea9f4df1a570441df34c@localhost>
 <CAAHg+HhtCorArCmx=ha0=64+SJZiizzrDUKSPLV=N+OzO8zAxQ@mail.gmail.com>
 <20130419090558.GA13283@mudshark.cambridge.arm.com>
 <CAAHg+HipCX2ma6brxj9Kgc3ew39b5e30grLwyun9CViif-5wZQ@mail.gmail.com>
 <20130419092752.GB13283@mudshark.cambridge.arm.com>
Message-ID: <CAFEAcA8j124G=vaHObJ_w5wOhUiS3KYKbjMnigbnr6mgwFxZUg@mail.gmail.com>

On 19 April 2013 10:27, Will Deacon <will.deacon at arm.com> wrote:
> On Fri, Apr 19, 2013 at 10:25:35AM +0100, Pranavkumar Sawargaonkar wrote:
>> I am not against using 8250 emulation (as far as it solves printk
>> issues for kernel booting logs), but my point is why not to add early
>> read-write support for virtio console, which also can be useful in
>> emulation less mach-virt environment also ?
>
> We can have both, but only one of those requires a change to the virtio
> specification.

I don't think avoiding writing a spec is necessarily a good reason
for insisting on emulation of a lump of hardware 95% of whose
capabilities you aren't going to use...

-- PMM


From pranavkumar at linaro.org  Fri Apr 19 05:34:56 2013
From: pranavkumar at linaro.org (Pranavkumar Sawargaonkar)
Date: Fri, 19 Apr 2013 15:04:56 +0530
Subject: [RFC] arm64: Early printk support for virtio-mmio console devices.
In-Reply-To: <CAFEAcA8j124G=vaHObJ_w5wOhUiS3KYKbjMnigbnr6mgwFxZUg@mail.gmail.com>
References: <1366264344-28025-1-git-send-email-pranavkumar@linaro.org>
 <ede8ee08bb2616c2ed642200e3357367@localhost>
 <CAAHg+HhajHFC=1nh6YQNgpf=Na2FqcsYJ=t+ag9QiTg6TxUz9w@mail.gmail.com>
 <bb1193983de3ea9f4df1a570441df34c@localhost>
 <CAAHg+HhtCorArCmx=ha0=64+SJZiizzrDUKSPLV=N+OzO8zAxQ@mail.gmail.com>
 <20130419090558.GA13283@mudshark.cambridge.arm.com>
 <CAAHg+HipCX2ma6brxj9Kgc3ew39b5e30grLwyun9CViif-5wZQ@mail.gmail.com>
 <20130419092752.GB13283@mudshark.cambridge.arm.com>
 <CAFEAcA8j124G=vaHObJ_w5wOhUiS3KYKbjMnigbnr6mgwFxZUg@mail.gmail.com>
Message-ID: <CAAHg+Hg=t97SJ0JPZYgrZaL+zimo-wbezwaj1BQvHqE-vf4VDA@mail.gmail.com>

On 19 April 2013 15:00, Peter Maydell <peter.maydell at linaro.org> wrote:
> On 19 April 2013 10:27, Will Deacon <will.deacon at arm.com> wrote:
>> On Fri, Apr 19, 2013 at 10:25:35AM +0100, Pranavkumar Sawargaonkar wrote:
>>> I am not against using 8250 emulation (as far as it solves printk
>>> issues for kernel booting logs), but my point is why not to add early
>>> read-write support for virtio console, which also can be useful in
>>> emulation less mach-virt environment also ?
>>
>> We can have both, but only one of those requires a change to the virtio
>> specification.
>
> I don't think avoiding writing a spec is necessarily a good reason
> for insisting on emulation of a lump of hardware 95% of whose
> capabilities you aren't going to use...

True.
Also 8250 will require emulation of registers, and i am not sure about
if mach-virt will have any emulation of real hw ?

Thanks,
Pranav

>
> -- PMM


From nicolas.ferre at atmel.com  Fri Apr 19 05:35:29 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Fri, 19 Apr 2013 11:35:29 +0200
Subject: [PATCH] ARM: at91/sama5d34ek.dts: remove not needed compatibility
 string
Message-ID: <1366364129-15974-1-git-send-email-nicolas.ferre@atmel.com>

"atmel,sama5ek" compatibility sting does not correspond to a
useful board configuration. This d35ek.dts is the only sama5d3
.dts file affected.

Reported-by: Josh Wu <josh.wu at atmel.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre at atmel.com>
---
 arch/arm/boot/dts/sama5d34ek.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/sama5d34ek.dts b/arch/arm/boot/dts/sama5d34ek.dts
index d2739f8..6bebfcd 100644
--- a/arch/arm/boot/dts/sama5d34ek.dts
+++ b/arch/arm/boot/dts/sama5d34ek.dts
@@ -12,7 +12,7 @@
 
 / {
 	model = "Atmel SAMA5D34-EK";
-	compatible = "atmel,sama5d34ek", "atmel,sama5ek", "atmel,sama5d3xmb", "atmel,sama5d3xcm", "atmel,sama5d3", "atmel,sama5";
+	compatible = "atmel,sama5d34ek", "atmel,sama5d3xmb", "atmel,sama5d3xcm", "atmel,sama5d3", "atmel,sama5";
 
 	ahb {
 		apb {
-- 
1.8.0



From will.deacon at arm.com  Fri Apr 19 05:36:24 2013
From: will.deacon at arm.com (Will Deacon)
Date: Fri, 19 Apr 2013 10:36:24 +0100
Subject: [RFC] arm64: Early printk support for virtio-mmio console devices.
In-Reply-To: <CAFEAcA8j124G=vaHObJ_w5wOhUiS3KYKbjMnigbnr6mgwFxZUg@mail.gmail.com>
References: <1366264344-28025-1-git-send-email-pranavkumar@linaro.org>
 <ede8ee08bb2616c2ed642200e3357367@localhost>
 <CAAHg+HhajHFC=1nh6YQNgpf=Na2FqcsYJ=t+ag9QiTg6TxUz9w@mail.gmail.com>
 <bb1193983de3ea9f4df1a570441df34c@localhost>
 <CAAHg+HhtCorArCmx=ha0=64+SJZiizzrDUKSPLV=N+OzO8zAxQ@mail.gmail.com>
 <20130419090558.GA13283@mudshark.cambridge.arm.com>
 <CAAHg+HipCX2ma6brxj9Kgc3ew39b5e30grLwyun9CViif-5wZQ@mail.gmail.com>
 <20130419092752.GB13283@mudshark.cambridge.arm.com>
 <CAFEAcA8j124G=vaHObJ_w5wOhUiS3KYKbjMnigbnr6mgwFxZUg@mail.gmail.com>
Message-ID: <20130419093624.GC13283@mudshark.cambridge.arm.com>

On Fri, Apr 19, 2013 at 10:30:40AM +0100, Peter Maydell wrote:
> On 19 April 2013 10:27, Will Deacon <will.deacon at arm.com> wrote:
> > On Fri, Apr 19, 2013 at 10:25:35AM +0100, Pranavkumar Sawargaonkar wrote:
> >> I am not against using 8250 emulation (as far as it solves printk
> >> issues for kernel booting logs), but my point is why not to add early
> >> read-write support for virtio console, which also can be useful in
> >> emulation less mach-virt environment also ?
> >
> > We can have both, but only one of those requires a change to the virtio
> > specification.
> 
> I don't think avoiding writing a spec is necessarily a good reason
> for insisting on emulation of a lump of hardware 95% of whose
> capabilities you aren't going to use...

Don't get me wrong; I'm in favour of having earlyprintk over virtio console
too, I'm just pointing out that we can also plug in the 8250 emulation that
we already have with very little effort. I'm not insisting on anything.

Will


From nicolas.ferre at atmel.com  Fri Apr 19 05:37:58 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Fri, 19 Apr 2013 11:37:58 +0200
Subject: [PATCH] ARM: at91/sama5d34ek.dts: remove not needed compatibility
 string
In-Reply-To: <1366364129-15974-1-git-send-email-nicolas.ferre@atmel.com>
References: <1366364129-15974-1-git-send-email-nicolas.ferre@atmel.com>
Message-ID: <51711076.7000503@atmel.com>

On 04/19/2013 11:35 AM, Nicolas Ferre :
> "atmel,sama5ek" compatibility sting does not correspond to a
> useful board configuration. This d35ek.dts is the only sama5d3

s/d35/d34/

sorry.

> .dts file affected.
> 
> Reported-by: Josh Wu <josh.wu at atmel.com>
> Signed-off-by: Nicolas Ferre <nicolas.ferre at atmel.com>
> ---
>  arch/arm/boot/dts/sama5d34ek.dts | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/sama5d34ek.dts b/arch/arm/boot/dts/sama5d34ek.dts
> index d2739f8..6bebfcd 100644
> --- a/arch/arm/boot/dts/sama5d34ek.dts
> +++ b/arch/arm/boot/dts/sama5d34ek.dts
> @@ -12,7 +12,7 @@
>  
>  / {
>  	model = "Atmel SAMA5D34-EK";
> -	compatible = "atmel,sama5d34ek", "atmel,sama5ek", "atmel,sama5d3xmb", "atmel,sama5d3xcm", "atmel,sama5d3", "atmel,sama5";
> +	compatible = "atmel,sama5d34ek", "atmel,sama5d3xmb", "atmel,sama5d3xcm", "atmel,sama5d3", "atmel,sama5";
>  
>  	ahb {
>  		apb {
> 


-- 
Nicolas Ferre


From nicolas.ferre at atmel.com  Fri Apr 19 05:39:45 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Fri, 19 Apr 2013 11:39:45 +0200
Subject: [PATCH v3 2/6] ARM: at91: dts: set #dma-cells to the correct value
In-Reply-To: <1366362683-14496-3-git-send-email-ludovic.desroches@atmel.com>
References: <1366362683-14496-1-git-send-email-ludovic.desroches@atmel.com>
 <1366362683-14496-3-git-send-email-ludovic.desroches@atmel.com>
Message-ID: <517110E1.70804@atmel.com>

On 04/19/2013 11:11 AM, ludovic.desroches at atmel.com :
> From: Ludovic Desroches <ludovic.desroches at atmel.com>
> 
> Moving to generic DMA DT binding involves to set #dma-cells to 2.
> 
> Signed-off-by: Ludovic Desroches <ludovic.desroches at atmel.com>

Acked-by: Nicolas Ferre <nicolas.ferre at atmel.com>

And stacked in at91-3.10-soc.

thanks,

> ---
>  arch/arm/boot/dts/at91sam9g45.dtsi | 1 +
>  arch/arm/boot/dts/at91sam9n12.dtsi | 1 +
>  arch/arm/boot/dts/at91sam9x5.dtsi  | 2 ++
>  arch/arm/boot/dts/sama5d3.dtsi     | 4 ++--
>  4 files changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/at91sam9g45.dtsi b/arch/arm/boot/dts/at91sam9g45.dtsi
> index 6b1d4ca..275e768 100644
> --- a/arch/arm/boot/dts/at91sam9g45.dtsi
> +++ b/arch/arm/boot/dts/at91sam9g45.dtsi
> @@ -108,6 +108,7 @@
>  				compatible = "atmel,at91sam9g45-dma";
>  				reg = <0xffffec00 0x200>;
>  				interrupts = <21 4 0>;
> +				#dma-cells = <2>;
>  			};
>  
>  			pinctrl at fffff200 {
> diff --git a/arch/arm/boot/dts/at91sam9n12.dtsi b/arch/arm/boot/dts/at91sam9n12.dtsi
> index 7750f98..acc4526 100644
> --- a/arch/arm/boot/dts/at91sam9n12.dtsi
> +++ b/arch/arm/boot/dts/at91sam9n12.dtsi
> @@ -110,6 +110,7 @@
>  				compatible = "atmel,at91sam9g45-dma";
>  				reg = <0xffffec00 0x200>;
>  				interrupts = <20 4 0>;
> +				#dma-cells = <2>;
>  			};
>  
>  			pinctrl at fffff400 {
> diff --git a/arch/arm/boot/dts/at91sam9x5.dtsi b/arch/arm/boot/dts/at91sam9x5.dtsi
> index 3870322..8e83d87 100644
> --- a/arch/arm/boot/dts/at91sam9x5.dtsi
> +++ b/arch/arm/boot/dts/at91sam9x5.dtsi
> @@ -104,12 +104,14 @@
>  				compatible = "atmel,at91sam9g45-dma";
>  				reg = <0xffffec00 0x200>;
>  				interrupts = <20 4 0>;
> +				#dma-cells = <2>;
>  			};
>  
>  			dma1: dma-controller at ffffee00 {
>  				compatible = "atmel,at91sam9g45-dma";
>  				reg = <0xffffee00 0x200>;
>  				interrupts = <21 4 0>;
> +				#dma-cells = <2>;
>  			};
>  
>  			pinctrl at fffff400 {
> diff --git a/arch/arm/boot/dts/sama5d3.dtsi b/arch/arm/boot/dts/sama5d3.dtsi
> index 39b0458..95c00a3 100644
> --- a/arch/arm/boot/dts/sama5d3.dtsi
> +++ b/arch/arm/boot/dts/sama5d3.dtsi
> @@ -348,14 +348,14 @@
>  				compatible = "atmel,at91sam9g45-dma";
>  				reg = <0xffffe600 0x200>;
>  				interrupts = <30 4 0>;
> -				#dma-cells = <1>;
> +				#dma-cells = <2>;
>  			};
>  
>  			dma1: dma-controller at ffffe800 {
>  				compatible = "atmel,at91sam9g45-dma";
>  				reg = <0xffffe800 0x200>;
>  				interrupts = <31 4 0>;
> -				#dma-cells = <1>;
> +				#dma-cells = <2>;
>  			};
>  
>  			ramc0: ramc at ffffea00 {
> 


-- 
Nicolas Ferre


From will.deacon at arm.com  Fri Apr 19 05:39:53 2013
From: will.deacon at arm.com (Will Deacon)
Date: Fri, 19 Apr 2013 10:39:53 +0100
Subject: [RFC] arm64: Early printk support for virtio-mmio console devices.
In-Reply-To: <CAAHg+Hg=t97SJ0JPZYgrZaL+zimo-wbezwaj1BQvHqE-vf4VDA@mail.gmail.com>
References: <1366264344-28025-1-git-send-email-pranavkumar@linaro.org>
 <ede8ee08bb2616c2ed642200e3357367@localhost>
 <CAAHg+HhajHFC=1nh6YQNgpf=Na2FqcsYJ=t+ag9QiTg6TxUz9w@mail.gmail.com>
 <bb1193983de3ea9f4df1a570441df34c@localhost>
 <CAAHg+HhtCorArCmx=ha0=64+SJZiizzrDUKSPLV=N+OzO8zAxQ@mail.gmail.com>
 <20130419090558.GA13283@mudshark.cambridge.arm.com>
 <CAAHg+HipCX2ma6brxj9Kgc3ew39b5e30grLwyun9CViif-5wZQ@mail.gmail.com>
 <20130419092752.GB13283@mudshark.cambridge.arm.com>
 <CAFEAcA8j124G=vaHObJ_w5wOhUiS3KYKbjMnigbnr6mgwFxZUg@mail.gmail.com>
 <CAAHg+Hg=t97SJ0JPZYgrZaL+zimo-wbezwaj1BQvHqE-vf4VDA@mail.gmail.com>
Message-ID: <20130419093953.GD13283@mudshark.cambridge.arm.com>

On Fri, Apr 19, 2013 at 10:34:56AM +0100, Pranavkumar Sawargaonkar wrote:
> On 19 April 2013 15:00, Peter Maydell <peter.maydell at linaro.org> wrote:
> > On 19 April 2013 10:27, Will Deacon <will.deacon at arm.com> wrote:
> >> On Fri, Apr 19, 2013 at 10:25:35AM +0100, Pranavkumar Sawargaonkar wrote:
> >>> I am not against using 8250 emulation (as far as it solves printk
> >>> issues for kernel booting logs), but my point is why not to add early
> >>> read-write support for virtio console, which also can be useful in
> >>> emulation less mach-virt environment also ?
> >>
> >> We can have both, but only one of those requires a change to the virtio
> >> specification.
> >
> > I don't think avoiding writing a spec is necessarily a good reason
> > for insisting on emulation of a lump of hardware 95% of whose
> > capabilities you aren't going to use...
> 
> True.
> Also 8250 will require emulation of registers, and i am not sure about
> if mach-virt will have any emulation of real hw ?

The point of mach-virt is that it is completely parameterised. So, if you're
not emulating an 8250, then don't tell the kernel that you have one!
Similarly, if you *do* emulate it, then either create a device-tree node for
it or pass the appropriate earlyprintk= string on the command line.

As far as kvmtool is concerned, we'd probably have a new command-line option
for arm64, allowing you to specify the early console device.

Will


From stefano.stabellini at eu.citrix.com  Fri Apr 19 05:40:34 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Fri, 19 Apr 2013 10:40:34 +0100
Subject: [PATCH v6 1/4] arm: introduce psci_smp_ops
In-Reply-To: <alpine.LFD.2.03.1304181336280.17375@syhkavp.arg>
References: <alpine.DEB.2.02.1304031239550.5078@kaball.uk.xensource.com>
 <1365167495-18508-1-git-send-email-stefano.stabellini@eu.citrix.com>
 <20130418161341.GB14496@n2100.arm.linux.org.uk>
 <alpine.DEB.2.02.1304181714560.7254@kaball.uk.xensource.com>
 <alpine.LFD.2.03.1304181237480.17375@syhkavp.arg>
 <alpine.DEB.2.02.1304181749260.7254@kaball.uk.xensource.com>
 <alpine.LFD.2.03.1304181336280.17375@syhkavp.arg>
Message-ID: <alpine.DEB.2.02.1304191035360.7254@kaball.uk.xensource.com>

On Thu, 18 Apr 2013, Nicolas Pitre wrote:
> On Thu, 18 Apr 2013, Stefano Stabellini wrote:
> 
> > On Thu, 18 Apr 2013, Nicolas Pitre wrote:
> > > On Thu, 18 Apr 2013, Stefano Stabellini wrote:
> > > 
> > > > On Thu, 18 Apr 2013, Russell King - ARM Linux wrote:
> > > > > This should allow the Xen problem to be resolved, because Xen will
> > > > > provide the PSCI operations, and it's correct in that case to override
> > > > > the platform's SMP operations.
> > > > 
> > > > Yes, increasing the priority of PSCI helps Xen a lot.
> > > > In order to completely solve the issue for Xen though, another patch is
> > > > needed (http://marc.info/?l=linux-kernel&m=136630106201968&w=2) because
> > > > of the introduction of smp_init.
> > > 
> > > Please look at the latest smp_init patch version I sent to you.  It 
> > > shouldn't conflict with Xen any longer.  It now returns a bool result 
> > > depending on whether it did set up smp_ops or not.
> > 
> > CPUs are virtualized by Xen and do not reflect or expose the underlying
> > SMP hardware and firmware features, so an hardware specific smp_init
> > cannot run.
> > 
> > So the smp_init patch still breaks Xen because even if smp_init can fail
> > graciously, executing a platform specific smp_init function that tries
> > to access registers and memory regions that are not present is going to
> > cause an undefined behaviour.
> 
> It won't access hardware but just look into the DT and return false if 
> nothing interesting is found.  At which point the next attempt in the 
> priority list is PSCI by default.

OK, that should work.
I am going to drop "xen/arm: introduce xen_early_init, use PSCI on xen".

We'll have to be careful enforcing that future smp_init implementations
use DT rather than probing registers. Maybe I should add a comment to
the smp_init patch to clarify that?


From nicolas.ferre at atmel.com  Fri Apr 19 05:43:32 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Fri, 19 Apr 2013 11:43:32 +0200
Subject: [PATCH v3 6/6] ARM: at91: dts: add MCI DMA support
In-Reply-To: <1366362683-14496-7-git-send-email-ludovic.desroches@atmel.com>
References: <1366362683-14496-1-git-send-email-ludovic.desroches@atmel.com>
 <1366362683-14496-7-git-send-email-ludovic.desroches@atmel.com>
Message-ID: <517111C4.3090808@atmel.com>

On 04/19/2013 11:11 AM, ludovic.desroches at atmel.com :
> From: Ludovic Desroches <ludovic.desroches at atmel.com>
> 
> Add DMA resources to MCI nodes.
> 
> Signed-off-by: Ludovic Desroches <ludovic.desroches at atmel.com>

I have made little corrections, but do not bother, it is already in my tree:

[nicolas.ferre at atmel.com: correct 9g45, 9n12 dma phandle name]
Acked-by: Nicolas Ferre <nicolas.ferre at atmel.com>

And stacked in at91-3.10-soc.

thanks,

> ---
>  arch/arm/boot/dts/at91sam9g45.dtsi | 4 ++++
>  arch/arm/boot/dts/at91sam9n12.dtsi | 2 ++
>  arch/arm/boot/dts/at91sam9x5.dtsi  | 4 ++++
>  arch/arm/boot/dts/sama5d3.dtsi     | 6 ++++++
>  4 files changed, 16 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/at91sam9g45.dtsi b/arch/arm/boot/dts/at91sam9g45.dtsi
> index 275e768..de2abc0 100644
> --- a/arch/arm/boot/dts/at91sam9g45.dtsi
> +++ b/arch/arm/boot/dts/at91sam9g45.dtsi
> @@ -513,6 +513,8 @@
>  				compatible = "atmel,hsmci";
>  				reg = <0xfff80000 0x600>;
>  				interrupts = <11 4 0>;
> +				dmas = <&dma0 1 0>;

single dma controller in 9g45:
s/dma0/dma/


> +				dma-names = "rxtx";
>  				#address-cells = <1>;
>  				#size-cells = <0>;
>  				status = "disabled";
> @@ -522,6 +524,8 @@
>  				compatible = "atmel,hsmci";
>  				reg = <0xfffd0000 0x600>;
>  				interrupts = <29 4 0>;
> +				dmas = <&dma0 1 13>;

Ditto

> +				dma-names = "rxtx";
>  				#address-cells = <1>;
>  				#size-cells = <0>;
>  				status = "disabled";
> diff --git a/arch/arm/boot/dts/at91sam9n12.dtsi b/arch/arm/boot/dts/at91sam9n12.dtsi
> index f912124..0b61c41 100644
> --- a/arch/arm/boot/dts/at91sam9n12.dtsi
> +++ b/arch/arm/boot/dts/at91sam9n12.dtsi
> @@ -89,6 +89,8 @@
>  				compatible = "atmel,hsmci";
>  				reg = <0xf0008000 0x600>;
>  				interrupts = <12 4 0>;
> +				dmas = <&dma0 1 0>

single dma controller in 9n12:
s/dma0/dma/
+ do not forget the tailing ";"

> +				dma-names = "rxtx";
>  				#address-cells = <1>;
>  				#size-cells = <0>;
>  				status = "disabled";
> diff --git a/arch/arm/boot/dts/at91sam9x5.dtsi b/arch/arm/boot/dts/at91sam9x5.dtsi
> index 16c9b81..5f42e7a 100644
> --- a/arch/arm/boot/dts/at91sam9x5.dtsi
> +++ b/arch/arm/boot/dts/at91sam9x5.dtsi
> @@ -449,6 +449,8 @@
>  				compatible = "atmel,hsmci";
>  				reg = <0xf0008000 0x600>;
>  				interrupts = <12 4 0>;
> +				dmas = <&dma0 1 0>;
> +				dma-names = "rxtx";
>  				#address-cells = <1>;
>  				#size-cells = <0>;
>  				status = "disabled";
> @@ -458,6 +460,8 @@
>  				compatible = "atmel,hsmci";
>  				reg = <0xf000c000 0x600>;
>  				interrupts = <26 4 0>;
> +				dmas = <&dma1 1 0>;
> +				dma-names = "rxtx";
>  				#address-cells = <1>;
>  				#size-cells = <0>;
>  				status = "disabled";
> diff --git a/arch/arm/boot/dts/sama5d3.dtsi b/arch/arm/boot/dts/sama5d3.dtsi
> index 8e87277..2e643ea 100644
> --- a/arch/arm/boot/dts/sama5d3.dtsi
> +++ b/arch/arm/boot/dts/sama5d3.dtsi
> @@ -60,6 +60,8 @@
>  				compatible = "atmel,hsmci";
>  				reg = <0xf0000000 0x600>;
>  				interrupts = <21 4 0>;
> +				dmas = <&dma0 2 0>;
> +				dma-names = "rxtx";
>  				pinctrl-names = "default";
>  				pinctrl-0 = <&pinctrl_mmc0_clk_cmd_dat0 &pinctrl_mmc0_dat1_3 &pinctrl_mmc0_dat4_7>;
>  				status = "disabled";
> @@ -173,6 +175,8 @@
>  				compatible = "atmel,hsmci";
>  				reg = <0xf8000000 0x600>;
>  				interrupts = <22 4 0>;
> +				dmas = <&dma1 2 0>;
> +				dma-names = "rxtx";
>  				pinctrl-names = "default";
>  				pinctrl-0 = <&pinctrl_mmc1_clk_cmd_dat0 &pinctrl_mmc1_dat1_3>;
>  				status = "disabled";
> @@ -184,6 +188,8 @@
>  				compatible = "atmel,hsmci";
>  				reg = <0xf8004000 0x600>;
>  				interrupts = <23 4 0>;
> +				dmas = <&dma1 2 1>;
> +				dma-names = "rxtx";
>  				pinctrl-names = "default";
>  				pinctrl-0 = <&pinctrl_mmc2_clk_cmd_dat0 &pinctrl_mmc2_dat1_3>;
>  				status = "disabled";
> 


-- 
Nicolas Ferre


From nicolas.ferre at atmel.com  Fri Apr 19 05:43:38 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Fri, 19 Apr 2013 11:43:38 +0200
Subject: [PATCH v3 4/6] ARM: at91: dts: add i2c dma support
In-Reply-To: <1366362683-14496-5-git-send-email-ludovic.desroches@atmel.com>
References: <1366362683-14496-1-git-send-email-ludovic.desroches@atmel.com>
 <1366362683-14496-5-git-send-email-ludovic.desroches@atmel.com>
Message-ID: <517111CA.4030403@atmel.com>

On 04/19/2013 11:11 AM, ludovic.desroches at atmel.com :
> From: Ludovic Desroches <ludovic.desroches at atmel.com>
> 
> Add DMA resources to i2c nodes.
> 
> Signed-off-by: Ludovic Desroches <ludovic.desroches at atmel.com>



I have made little corrections, but do not bother, it is already in my tree:

[nicolas.ferre at atmel.com: correct 9n12 dma phandle name]
Acked-by: Nicolas Ferre <nicolas.ferre at atmel.com>

And stacked in at91-3.10-soc.

thanks,


> ---
>  arch/arm/boot/dts/at91sam9n12.dtsi | 6 ++++++
>  arch/arm/boot/dts/at91sam9x5.dtsi  | 9 +++++++++
>  arch/arm/boot/dts/sama5d3.dtsi     | 9 +++++++++
>  3 files changed, 24 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/at91sam9n12.dtsi b/arch/arm/boot/dts/at91sam9n12.dtsi
> index acc4526..f912124 100644
> --- a/arch/arm/boot/dts/at91sam9n12.dtsi
> +++ b/arch/arm/boot/dts/at91sam9n12.dtsi
> @@ -361,6 +361,9 @@
>  				compatible = "atmel,at91sam9x5-i2c";
>  				reg = <0xf8010000 0x100>;
>  				interrupts = <9 4 6>;
> +				dmas = <&dma0 1 13>,
> +				       <&dma0 1 14>;

single dma controller in 9n12:
s/dma0/dma/

> +				dma-names = "tx", "rx";
>  				#address-cells = <1>;
>  				#size-cells = <0>;
>  				status = "disabled";
> @@ -370,6 +373,9 @@
>  				compatible = "atmel,at91sam9x5-i2c";
>  				reg = <0xf8014000 0x100>;
>  				interrupts = <10 4 6>;
> +				dmas = <&dma0 1 15>,
> +				       <&dma0 1 16>;

Ditto

> +				dma-names = "tx", "rx";
>  				#address-cells = <1>;
>  				#size-cells = <0>;
>  				status = "disabled";
> diff --git a/arch/arm/boot/dts/at91sam9x5.dtsi b/arch/arm/boot/dts/at91sam9x5.dtsi
> index 8e83d87..16c9b81 100644
> --- a/arch/arm/boot/dts/at91sam9x5.dtsi
> +++ b/arch/arm/boot/dts/at91sam9x5.dtsi
> @@ -519,6 +519,9 @@
>  				compatible = "atmel,at91sam9x5-i2c";
>  				reg = <0xf8010000 0x100>;
>  				interrupts = <9 4 6>;
> +				dmas = <&dma0 1 7>,
> +				       <&dma0 1 8>;
> +				dma-names = "tx", "rx";
>  				#address-cells = <1>;
>  				#size-cells = <0>;
>  				pinctrl-names = "default";
> @@ -530,6 +533,9 @@
>  				compatible = "atmel,at91sam9x5-i2c";
>  				reg = <0xf8014000 0x100>;
>  				interrupts = <10 4 6>;
> +				dmas = <&dma1 1 5>,
> +				       <&dma1 1 6>;
> +				dma-names = "tx", "rx";
>  				#address-cells = <1>;
>  				#size-cells = <0>;
>  				pinctrl-names = "default";
> @@ -541,6 +547,9 @@
>  				compatible = "atmel,at91sam9x5-i2c";
>  				reg = <0xf8018000 0x100>;
>  				interrupts = <11 4 6>;
> +				dmas = <&dma0 1 9>,
> +				       <&dma0 1 10>;
> +				dma-names = "tx", "rx";
>  				#address-cells = <1>;
>  				#size-cells = <0>;
>  				pinctrl-names = "default";
> diff --git a/arch/arm/boot/dts/sama5d3.dtsi b/arch/arm/boot/dts/sama5d3.dtsi
> index 95c00a3..8e87277 100644
> --- a/arch/arm/boot/dts/sama5d3.dtsi
> +++ b/arch/arm/boot/dts/sama5d3.dtsi
> @@ -111,6 +111,9 @@
>  				compatible = "atmel,at91sam9x5-i2c";
>  				reg = <0xf0014000 0x4000>;
>  				interrupts = <18 4 6>;
> +				dmas = <&dma0 2 7>,
> +				       <&dma0 2 8>;
> +				dma-names = "tx", "rx";
>  				pinctrl-names = "default";
>  				pinctrl-0 = <&pinctrl_i2c0>;
>  				#address-cells = <1>;
> @@ -122,6 +125,9 @@
>  				compatible = "atmel,at91sam9x5-i2c";
>  				reg = <0xf0018000 0x4000>;
>  				interrupts = <19 4 6>;
> +				dmas = <&dma0 2 9>,
> +				       <&dma0 2 10>;
> +				dma-names = "tx", "rx";
>  				pinctrl-names = "default";
>  				pinctrl-0 = <&pinctrl_i2c1>;
>  				#address-cells = <1>;
> @@ -294,6 +300,9 @@
>  				compatible = "atmel,at91sam9x5-i2c";
>  				reg = <0xf801c000 0x4000>;
>  				interrupts = <20 4 6>;
> +				dmas = <&dma1 2 11>,
> +				       <&dma1 2 12>;
> +				dma-names = "tx", "rx";
>  				#address-cells = <1>;
>  				#size-cells = <0>;
>  				status = "disabled";
> 


-- 
Nicolas Ferre


From pawel.moll at arm.com  Fri Apr 19 05:47:56 2013
From: pawel.moll at arm.com (Pawel Moll)
Date: Fri, 19 Apr 2013 10:47:56 +0100
Subject: linux-next: manual merge of the clk tree with the arm-soc tree
In-Reply-To: <20130419172753.0e604e9bad0b7a26a8b52787@canb.auug.org.au>
References: <20130419172753.0e604e9bad0b7a26a8b52787@canb.auug.org.au>
Message-ID: <1366364876.3077.51.camel@hornet>

On Fri, 2013-04-19 at 08:27 +0100, Stephen Rothwell wrote:
> Hi Mike,
> 
> Today's linux-next merge of the clk tree got a conflict in
> arch/arm/mach-vexpress/v2m.c between commit dabfd8fb84ab ("ARM: vexpress:
> remove sp804 OF init") from the arm-soc tree and commit 6e973d2c4385
> ("clk: vexpress: Add separate SP810 driver") from the clk tree.
> 
> I fixed it up (I thnk - see below) and can carry the fix as necessary (no
> action is required).

Yep, this merge is fine, thanks!

Pawe?




From Ian.Campbell at citrix.com  Fri Apr 19 05:52:31 2013
From: Ian.Campbell at citrix.com (Ian Campbell)
Date: Fri, 19 Apr 2013 10:52:31 +0100
Subject: [Xen-devel] [PATCH v6 1/4] arm: introduce psci_smp_ops
In-Reply-To: <alpine.LFD.2.03.1304181336280.17375@syhkavp.arg>
References: <alpine.DEB.2.02.1304031239550.5078@kaball.uk.xensource.com>
 <1365167495-18508-1-git-send-email-stefano.stabellini@eu.citrix.com>
 <20130418161341.GB14496@n2100.arm.linux.org.uk>
 <alpine.DEB.2.02.1304181714560.7254@kaball.uk.xensource.com>
 <alpine.LFD.2.03.1304181237480.17375@syhkavp.arg>
 <alpine.DEB.2.02.1304181749260.7254@kaball.uk.xensource.com>
 <alpine.LFD.2.03.1304181336280.17375@syhkavp.arg>
Message-ID: <1366365151.19111.80.camel@zakaz.uk.xensource.com>

On Thu, 2013-04-18 at 18:38 +0100, Nicolas Pitre wrote:
> On Thu, 18 Apr 2013, Stefano Stabellini wrote:
> 
> > On Thu, 18 Apr 2013, Nicolas Pitre wrote:
> > > On Thu, 18 Apr 2013, Stefano Stabellini wrote:
> > > 
> > > > On Thu, 18 Apr 2013, Russell King - ARM Linux wrote:
> > > > > This should allow the Xen problem to be resolved, because Xen will
> > > > > provide the PSCI operations, and it's correct in that case to override
> > > > > the platform's SMP operations.
> > > > 
> > > > Yes, increasing the priority of PSCI helps Xen a lot.
> > > > In order to completely solve the issue for Xen though, another patch is
> > > > needed (http://marc.info/?l=linux-kernel&m=136630106201968&w=2) because
> > > > of the introduction of smp_init.
> > > 
> > > Please look at the latest smp_init patch version I sent to you.  It 
> > > shouldn't conflict with Xen any longer.  It now returns a bool result 
> > > depending on whether it did set up smp_ops or not.
> > 
> > CPUs are virtualized by Xen and do not reflect or expose the underlying
> > SMP hardware and firmware features, so an hardware specific smp_init
> > cannot run.
> > 
> > So the smp_init patch still breaks Xen because even if smp_init can fail
> > graciously, executing a platform specific smp_init function that tries
> > to access registers and memory regions that are not present is going to
> > cause an undefined behaviour.
> 
> It won't access hardware but just look into the DT and return false if 
> nothing interesting is found.  At which point the next attempt in the 
> priority list is PSCI by default.

I think there might be some confusion about the semantics of smp_init,
since it is in mdesc I had interpreted it as a per-platform hook to
allow "magic" SMP setup, which I at least had assumed would (be
permitted to) involve hardware specific frobbing, including touching
platform specific devices etc.

Is that not the case?

Can we guarantee that this hook won't be used by hardware platforms to
e.g. probe NVRAM for SMP topology information or other activities which
touch hardware?

If it isn't hardware specific then does this hook really belong in
mdesc? Or if it is purely driven by DT can we not implement it in terms
of DT at the top level rather than abstracting via a hardware specific
hook?

Ian.



From linux at arm.linux.org.uk  Fri Apr 19 05:54:45 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Fri, 19 Apr 2013 10:54:45 +0100
Subject: [RFC PATCH 1/3] pstore-ram: use write-combine mappings
In-Reply-To: <CAMbhsRSvQPbzJ7Nt=OSSYE_A1e+eaUjO7XY+qRppJ5_gfWmW4A@mail.gmail.com>
References: <1365563297-12480-1-git-send-email-robherring2@gmail.com>
 <CAMbhsRSvQPbzJ7Nt=OSSYE_A1e+eaUjO7XY+qRppJ5_gfWmW4A@mail.gmail.com>
Message-ID: <20130419095445.GG14496@n2100.arm.linux.org.uk>

On Tue, Apr 09, 2013 at 08:53:18PM -0700, Colin Cross wrote:
> On Tue, Apr 9, 2013 at 8:08 PM, Rob Herring <robherring2 at gmail.com> wrote:
> > -       return ioremap(start, size);
> > +       return ioremap_wc(start, size);
> 
> ioremap_wc corresponds to MT_DEVICE_WC, which is still device memory,
> so I don't see how this helps solve the problem in the commit message.

In reality it isn't, because there's no such thing as "write combining
device memory" in the ARM memory model.

There are three major memory types: strongly ordered, device and normal
memory.  Only normal memory can be cached in any way, which includes
using write combining.

#define ioremap_wc(cookie,size) __arm_ioremap((cookie), (size), MT_DEVICE_WC)

        [MT_DEVICE_WC] = {      /* ioremap_wc */
                .prot_pte       = PROT_PTE_DEVICE | L_PTE_MT_DEV_WC,

         *                      n       TR      IR      OR
         *   BUFFERABLE         001     10      00      00
         *   DEV_WC             001     10
(see arch/arm/mm/proc-v7-2level.S for the rest of the table and its
description.)

So, DEV_WC is an alias for BUFFERABLE, which is normal memory,
uncacheable in both inner and outer caches.  This means that at the
moment, ioremap_wc() memory has the same properties as system memory
- with all the out of ordering effects you get there.

I don't put any guarantee on this though - we may end up having to
change it if we find a SoC needing this to really be device memory...


From grant.likely at secretlab.ca  Fri Apr 19 06:01:32 2013
From: grant.likely at secretlab.ca (Grant Likely)
Date: Fri, 19 Apr 2013 11:01:32 +0100
Subject: [PATCH V2 1/7] kbuild: create an "include chroot" for DT bindings
In-Reply-To: <1365032098-22825-1-git-send-email-swarren@wwwdotorg.org>
References: <1365032098-22825-1-git-send-email-swarren@wwwdotorg.org>
Message-ID: <20130419100132.72DD23E116D@localhost>

On Wed,  3 Apr 2013 17:34:52 -0600, Stephen Warren <swarren at wwwdotorg.org> wrote:
> Grant, Rob, Michal, I'm hoping for acks or comments from you so this
> series can be placed into a topic branch in the arm-soc repo, for others
> to build on during the 3.10 kernel cycle. Thanks.

Thanks for doing all this work Stephen. It looks really good.

g.


From peter.maydell at linaro.org  Fri Apr 19 06:05:47 2013
From: peter.maydell at linaro.org (Peter Maydell)
Date: Fri, 19 Apr 2013 11:05:47 +0100
Subject: [RFC] arm64: Early printk support for virtio-mmio console devices.
In-Reply-To: <20130419093953.GD13283@mudshark.cambridge.arm.com>
References: <1366264344-28025-1-git-send-email-pranavkumar@linaro.org>
 <ede8ee08bb2616c2ed642200e3357367@localhost>
 <CAAHg+HhajHFC=1nh6YQNgpf=Na2FqcsYJ=t+ag9QiTg6TxUz9w@mail.gmail.com>
 <bb1193983de3ea9f4df1a570441df34c@localhost>
 <CAAHg+HhtCorArCmx=ha0=64+SJZiizzrDUKSPLV=N+OzO8zAxQ@mail.gmail.com>
 <20130419090558.GA13283@mudshark.cambridge.arm.com>
 <CAAHg+HipCX2ma6brxj9Kgc3ew39b5e30grLwyun9CViif-5wZQ@mail.gmail.com>
 <20130419092752.GB13283@mudshark.cambridge.arm.com>
 <CAFEAcA8j124G=vaHObJ_w5wOhUiS3KYKbjMnigbnr6mgwFxZUg@mail.gmail.com>
 <CAAHg+Hg=t97SJ0JPZYgrZaL+zimo-wbezwaj1BQvHqE-vf4VDA@mail.gmail.com>
 <20130419093953.GD13283@mudshark.cambridge.arm.com>
Message-ID: <CAFEAcA_WfYpyvq54rZqS8JZkmDF5JXB+CNHFH5CnrhKun52uzA@mail.gmail.com>

On 19 April 2013 10:39, Will Deacon <will.deacon at arm.com> wrote:
> The point of mach-virt is that it is completely parameterised. So, if you're
> not emulating an 8250, then don't tell the kernel that you have one!
> Similarly, if you *do* emulate it, then either create a device-tree node for
> it or pass the appropriate earlyprintk= string on the command line.
>
> As far as kvmtool is concerned, we'd probably have a new command-line option
> for arm64, allowing you to specify the early console device.

Please make the kernel pick the device out of the device tree
blob. The whole point of device tree is that it's how to tell
the kernel where things live -- making kvmtool/QEMU and/or the
user also have to mess with the kernel command line is awkward
and annoying.

-- PMM


From linux at arm.linux.org.uk  Fri Apr 19 06:11:31 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Fri, 19 Apr 2013 11:11:31 +0100
Subject: [PATCH v4] mmc: dw_mmc: let device core setup the default pin
 configuration
In-Reply-To: <CAD=FV=UddWM=yc5N9=jwbMDpZ7Bpg7o3Z714CnBSg=iHhmPxWw@mail.gmail.com>
References: <1365487186-4587-1-git-send-email-thomas.abraham@linaro.org>
 <CAD=FV=VJ-ykDNqYKQ=fqxeOD6bRNLW02VT4bjsRHRAuXLcCpQQ@mail.gmail.com>
 <CAJuYYwQT=povqiutVHXkF5jxTAnjpwTMQ5G0Z6xKGnnM7qYADQ@mail.gmail.com>
 <CAD=FV=UddWM=yc5N9=jwbMDpZ7Bpg7o3Z714CnBSg=iHhmPxWw@mail.gmail.com>
Message-ID: <20130419101131.GH14496@n2100.arm.linux.org.uk>

On Wed, Apr 10, 2013 at 06:56:48AM -0700, Doug Anderson wrote:
> Thomas,
> 
> On Wed, Apr 10, 2013 at 5:48 AM, Thomas Abraham
> <thomas.abraham at linaro.org> wrote:
> > The call to regulator_enable() is prior to the call to mmc_add_host().
> > Hence, call to mmc_fre_host is not required in this case. So the above
> > change should be right.
> 
> Are you sure that mmc_free_host() is the opposite of mmc_add_host()
> and not mmc_alloc_host()?

mmc_free_host() undoes mmc_alloc_host().  mmc_remove_host() undoes
mmc_add_host().

alloc
add
remove
free

is pretty standard terminology, standard ordering.  If add fails, then
free is the right thing to call to clean up after the alloc.


From linux at arm.linux.org.uk  Fri Apr 19 06:21:42 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Fri, 19 Apr 2013 11:21:42 +0100
Subject: v7_flush_kern_cache_louis flushes up to L2?
In-Reply-To: <51656A89.9090600@arm.com>
References: <CABYn4sxUCoWhC_4qydzbCtZdQdetqFZ_u5WtXsghprQget9f5g@mail.gmail.com>
 <51655248.7000401@arm.com>
 <CABYn4swK_FB+nPO4vKZM8khp+mjaPwkAv_GF+XDg5SYz0VLf0Q@mail.gmail.com>
 <51656A89.9090600@arm.com>
Message-ID: <20130419102142.GI14496@n2100.arm.linux.org.uk>

On Wed, Apr 10, 2013 at 02:35:05PM +0100, Jonathan Austin wrote:
> Note that on SMP, you would also need to clean/flush again after turning  
> off the caches, as read-speculation could have sucked dirty data from  
> another cache in to your cache, which would need to be written back  
> before sleeping.

Err, no.  If you read data into a cache, it is always populated in a clean
state.  You never suck dirty data out of one cache, remove it there and
place it immediately in a dirty state in an upper level cache.

So, if we start from the idea that reads will populate the upper level
cache with clean data, that cache is populated merely with a _copy_ of
the data held elsewhere in the system.

In that case, there is no need to clean or flush that cache after turning
it off - if the cache only contains _copies_ of data elsewhere in the
system, then it's perfectly fine for that data to be discarded in any
way - be that by turning the power off to the cache or invalidating it.

There is a step further in this: if the cache is being dirtied by the
local CPU, and that data will only ever be used by the local CPU, again,
in the CPU shutdown path, you really do not need to write that data out -
because the only CPU which cares about it is the local CPU which is going
to be shutdown.  So, loss of that data is not a problem.

In other words, shutdown of a CPU is a process which involves pushing out
data which the rest of the system requires (that's done by an initial
flush).  Once that flush is done, provided the dying CPU does not _write_
to any shared data (this includes spinlocks and such like too), there is
no need to flush the cache anymore.


From nicolas.ferre at atmel.com  Fri Apr 19 06:40:46 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Fri, 19 Apr 2013 12:40:46 +0200
Subject: [PATCH 5/5 v2] ARM: at91: add Acme Systems Fox G20 board
In-Reply-To: <a647ac59d50fdee9a0e9e87f362febe1ad2b1264.1366289869.git.nicolas.ferre@atmel.com>
References: <a647ac59d50fdee9a0e9e87f362febe1ad2b1264.1366289869.git.nicolas.ferre@atmel.com>
Message-ID: <1366368046-16758-1-git-send-email-nicolas.ferre@atmel.com>

From: Douglas Gilbert <dgilbert at interlog.com>

Signed-off-by: Douglas Gilbert <dgilbert at interlog.com>
[nicolas.ferre at atmel.com: re-arranging nodes, removing nodes and some comments]
Signed-off-by: Nicolas Ferre <nicolas.ferre at atmel.com>
---
v2: - removed the SPI node

 arch/arm/boot/dts/Makefile        |   1 +
 arch/arm/boot/dts/at91-foxg20.dts | 157 ++++++++++++++++++++++++++++++++++++++
 2 files changed, 158 insertions(+)
 create mode 100644 arch/arm/boot/dts/at91-foxg20.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index b07f162..914fe65 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -16,6 +16,7 @@ dtb-$(CONFIG_ARCH_AT91) += at91sam9263ek.dtb
 dtb-$(CONFIG_ARCH_AT91) += tny_a9263.dtb
 dtb-$(CONFIG_ARCH_AT91) += usb_a9263.dtb
 # sam9g20
+dtb-$(CONFIG_ARCH_AT91) += at91-foxg20.dtb
 dtb-$(CONFIG_ARCH_AT91) += at91sam9g20ek.dtb
 dtb-$(CONFIG_ARCH_AT91) += at91sam9g20ek_2mmc.dtb
 dtb-$(CONFIG_ARCH_AT91) += kizbox.dtb
diff --git a/arch/arm/boot/dts/at91-foxg20.dts b/arch/arm/boot/dts/at91-foxg20.dts
new file mode 100644
index 0000000..f5e0427
--- /dev/null
+++ b/arch/arm/boot/dts/at91-foxg20.dts
@@ -0,0 +1,157 @@
+/*
+ * at91-foxg20.dts - Device Tree file for Acme Systems FoxG20 board
+ *
+ * Based on DT files for at91sam9g20ek evaluation board (AT91SAM9G20 SoC)
+ *
+ * Copyright (C) 2013 Douglas Gilbert <dgilbert at interlog.com>
+ *
+ * Licensed under GPLv2 or later.
+ */
+/dts-v1/;
+/include/ "at91sam9g20.dtsi"
+
+/ {
+	model = "Acme Systems FoxG20";
+	compatible = "acme,foxg20", "atmel,at91sam9g20", "atmel,at91sam9";
+
+	chosen {
+		bootargs = "console=ttyS0,115200 root=/dev/mmcblk0p2 rw rootwait";
+	};
+
+	memory {
+		reg = <0x20000000 0x4000000>;
+	};
+
+	clocks {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges;
+
+		main_clock: clock at 0 {
+			compatible = "atmel,osc", "fixed-clock";
+			clock-frequency = <18432000>;
+		};
+	};
+
+	ahb {
+		apb {
+			usb1: gadget at fffa4000 {
+				atmel,vbus-gpio = <&pioC 6 0>;
+				status = "okay";
+			};
+
+			mmc0: mmc at fffa8000 {
+				pinctrl-0 = <
+					&pinctrl_mmc0_clk
+					&pinctrl_mmc0_slot1_cmd_dat0
+					&pinctrl_mmc0_slot1_dat1_3>;
+				status = "okay";
+
+				slot at 1 {
+					reg = <1>;
+					bus-width = <4>;
+				};
+			};
+
+			usart0: serial at fffb0000 {
+				pinctrl-0 =
+					<&pinctrl_usart0
+					 &pinctrl_usart0_rts
+					 &pinctrl_usart0_cts
+					>;
+				status = "okay";
+			};
+
+			usart1: serial at fffb4000 {
+				status = "okay";
+			};
+
+			usart2: serial at fffb8000 {
+				status = "okay";
+			};
+
+			macb0: ethernet at fffc4000 {
+				phy-mode = "rmii";
+				status = "okay";
+			};
+
+			usart3: serial at fffd0000 {
+				status = "okay";
+			};
+
+			uart0: serial at fffd4000 {
+				status = "okay";
+			};
+
+			uart1: serial at fffd8000 {
+				status = "okay";
+			};
+
+			dbgu: serial at fffff200 {
+				status = "okay";
+			};
+
+			pinctrl at fffff400 {
+				board {
+					pinctrl_pck0_as_mck: pck0_as_mck {
+						atmel,pins =
+							<2 1 0x2 0x0>;	/* PC1 periph B */
+					};
+				};
+
+				mmc0_slot1 {
+					pinctrl_board_mmc0_slot1: mmc0_slot1-board {
+						atmel,pins =
+							<2 9 0x0 0x5>;	/* PC9 gpio CD pin pull up and deglitch */
+					};
+				};
+
+				i2c0 {
+					pinctrl_i2c0: i2c0-0 {
+						atmel,pins =
+							<0 23 0x1 0x2	/* TWD (SDA) PA23 periph A, open drain */
+							 0 24 0x1 0x2>;	/* TWCK (SCL) PA24 periph A, open drain */
+					};
+				};
+			};
+
+			watchdog at fffffd40 {
+				status = "okay";
+			};
+		};
+
+		usb0: ohci at 00500000 {
+			num-ports = <2>;
+			status = "okay";
+		};
+	};
+
+	i2c at 0 {
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_i2c0>;
+		i2c-gpio,delay-us = <5>;	/* ~85 kHz */
+		status = "okay";
+	};
+
+	leds {
+		compatible = "gpio-leds";
+
+		/* red LED marked "PC7" near mini USB (device) receptacle */
+		user_led {
+			label = "user_led";
+			gpios = <&pioC 7 0>;	/* PC7 */
+			linux,default-trigger = "heartbeat";
+		};
+	};
+
+	gpio_keys {
+		compatible = "gpio-keys";
+
+		btn {
+			label = "Button";
+			gpios = <&pioC 4 1>;
+			linux,code = <0x103>;
+			gpio-key,wakeup;
+		};
+	};
+};
-- 
1.8.0



From haojian.zhuang at linaro.org  Fri Apr 19 06:49:23 2013
From: haojian.zhuang at linaro.org (Haojian Zhuang)
Date: Fri, 19 Apr 2013 18:49:23 +0800
Subject: [PATCH 1/5] ARM: debug: support debug ll on hisilicon soc
Message-ID: <1366368567-17322-1-git-send-email-haojian.zhuang@linaro.org>

Support UART0 debug ll on hisilicon Hi3620 SoC.

Signed-off-by: Haojian Zhuang <haojian.zhuang at linaro.org>
---
 arch/arm/Kconfig.debug             |   15 +++++++++++++++
 arch/arm/include/debug/hisilicon.S |   30 ++++++++++++++++++++++++++++++
 2 files changed, 45 insertions(+)
 create mode 100644 arch/arm/include/debug/hisilicon.S

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index acdddda..fd658db 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -240,6 +240,20 @@ choice
 		  Say Y here if you want kernel low-level debugging support
 		  on i.MX6Q.
 
+	config DEBUG_HI3620_UART
+		bool "Hisilicon HI3620 Debug UART"
+		depends on ARCH_HI3xxx
+		help
+		  Say Y here if you want kernel low-level debugging support
+		  on HI3620 UART.
+
+	config DEBUG_HI3716_UART
+		bool "Hisilicon Hi3716 Debug UART"
+		depends on ARCH_HI3xxx
+		help
+		  Say Y here if you want kernel low-level debugging support
+		  on HI3716 UART.
+
 	config DEBUG_MMP_UART2
 		bool "Kernel low-level debugging message via MMP UART2"
 		depends on ARCH_MMP
@@ -589,6 +603,7 @@ config DEBUG_LL_INCLUDE
 				 DEBUG_IMX53_UART ||\
 				 DEBUG_IMX6Q_UART
 	default "debug/highbank.S" if DEBUG_HIGHBANK_UART
+	default "debug/hisilicon.S" if DEBUG_HI3620_UART || DEBUG_HI3716_UART
 	default "debug/mvebu.S" if DEBUG_MVEBU_UART
 	default "debug/omap2plus.S" if DEBUG_OMAP2PLUS_UART
 	default "debug/picoxcell.S" if DEBUG_PICOXCELL_UART
diff --git a/arch/arm/include/debug/hisilicon.S b/arch/arm/include/debug/hisilicon.S
new file mode 100644
index 0000000..47ad019
--- /dev/null
+++ b/arch/arm/include/debug/hisilicon.S
@@ -0,0 +1,30 @@
+/*
+ * Early serial output macro for Hisilicon SoC
+ *
+ * Copyright (C) 2012-2013 Hisilicon Technologies Co., Ltd.
+ * Copyright (C) 2012-2013 Linaro Ltd.
+ *
+ * Author: Haojian Zhuang <haojian.zhuang at linaro.org>
+ *
+ * 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.
+*/
+
+#if defined(CONFIG_DEBUG_HI3620_UART)
+#define HS_UART_PHYS_BASE	0xfcb00000
+#define HS_UART_VIRT_BASE	0xfeb00000
+#elif defined(CONFIG_DEBUG_HI3716_UART)
+#define HS_UART_PHYS_BASE	0xf8b00000
+#define HS_UART_VIRT_BASE	0xfeb00000
+#endif
+
+#if defined(CONFIG_DEBUG_HI3620_UART) || defined(CONFIG_DEBUG_HI3716_UART)
+		.macro	addruart,rp,rv,tmp
+		ldr	\rp, =HS_UART_PHYS_BASE
+		ldr	\rv, =HS_UART_VIRT_BASE
+		.endm
+
+#include <asm/hardware/debug-pl01x.S>
+
+#endif
-- 
1.7.10.4



From haojian.zhuang at linaro.org  Fri Apr 19 06:49:24 2013
From: haojian.zhuang at linaro.org (Haojian Zhuang)
Date: Fri, 19 Apr 2013 18:49:24 +0800
Subject: [PATCH 2/5] clk: hi3xxx: add clock support
In-Reply-To: <1366368567-17322-1-git-send-email-haojian.zhuang@linaro.org>
References: <1366368567-17322-1-git-send-email-haojian.zhuang@linaro.org>
Message-ID: <1366368567-17322-2-git-send-email-haojian.zhuang@linaro.org>

Add clock support with device tree on Hisilicon SoC.

Signed-off-by: Haojian Zhuang <haojian.zhuang at linaro.org>
Cc: Mike Turquette <mturquette at linaro.org>
---
 .../devicetree/bindings/clock/hisilicon.txt        |   73 +++
 drivers/clk/Makefile                               |    1 +
 drivers/clk/clk-hi3xxx.c                           |  641 ++++++++++++++++++++
 3 files changed, 715 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/hisilicon.txt
 create mode 100644 drivers/clk/clk-hi3xxx.c

diff --git a/Documentation/devicetree/bindings/clock/hisilicon.txt b/Documentation/devicetree/bindings/clock/hisilicon.txt
new file mode 100644
index 0000000..49ed081
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/hisilicon.txt
@@ -0,0 +1,73 @@
+Device Tree Clock bindings for arch-hi3xxx
+
+This binding uses the common clock binding[1].
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties for mux clocks:
+ - compatible : Shall be "hisilicon,hi3620-clk-mux".
+ - clocks : shall be the input parent clock phandle for the clock. This should
+	be the reference clock.
+ - clock-output-names : shall be reference name.
+ - #clock-cells : from common clock binding; shall be set to 0.
+ - hisilicon,hi3620-mux : array of mux register offset & mask bits
+
+Required properties for Hi3620 gate clocks:
+ - compatible : Shall be "hisilicon,hi3620-clk-gate".
+ - clocks : shall be the input parent clock phandle for the clock. This should
+	be the reference clock.
+ - clock-output-names : shall be reference name.
+ - #clock-cells : from common clock binding; shall be set to 0.
+ - hisilicon,hi3620-clkgate : array of enable register offset & enable bits
+ - hisilicon,hi3620-clkreset : array of reset register offset & enable bits
+
+Required properties for clock divider:
+ - compatible : Shall be "hisilicon,hi3620-clk-div".
+ - clocks : shall be the input parent clock phandle for the clock. This should
+	be the reference clock.
+ - clock-output-names : shall be reference name.
+ - #clock-cells : from common clock binding; shall be set to 0.
+ - #hisilicon,clkdiv-table-cells : the number of parameters after phandle in
+   hisilicon,clkdiv-table property.
+ - hisilicon,clkdiv-table : list of value that are used to configure clock
+   divider. They're value of phandle, index & divider value.
+ - hisilicon,clkdiv : array of divider register offset & mask bits.
+
+Required properties for gate clocks:
+ - compatible : Shall be "hisilicon,clk-gate".
+ - clocks : shall be the input parent clock phandle for the clock. This should
+	be the reference clock.
+ - clock-output-names : shall be reference name.
+ - #clock-cells : from common clock binding; shall be set to 0.
+ - hisilicon,clkgate-inverted : bool value. True means that set-to-disable.
+
+Required properties for clock fixed factor divider:
+ - compatible : Shall be "hisilicon,fixed-factor".
+ - clocks : shall be the input parent clock phandle for the clock. This should
+	be the reference clock.
+ - clock-output-names : shall be reference name.
+ - #clock-cells : from common clock binding; shall be set to 0.
+ - hisilicon,fixed-factor : array of multiplier & divider.
+
+For example:
+	timclk1: clkgate at 38 {
+		compatible = "hisilicon,clk-gate";
+		#clock-cells = <0>;
+		clocks = <&refclk_timer1>;
+		clock-output-names = "timclk1";
+		hisilicon,clkgate-inverted;
+		hisilicon,clkgate = <0 18>;
+	};
+
+	dtable: clkdiv at 0 {
+		#hisilicon,clkdiv-table-cells = <2>;
+	};
+
+	div_cfgaxi: clkdiv at 2 {
+		compatible = "hisilicon,hi3620-clk-div";
+		#clock-cells = <0>;
+		clocks = <&div_shareaxi>;
+		clock-output-names = "cfgAXI_div";
+		hisilicon,clkdiv-table = <&dtable 0x01 2>;
+		hisilicon,clkdiv = <0x100 0x60>;
+	};
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 300d477..852e5c2 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_COMMON_CLK)	+= clk-mux.o
 # SoCs specific
 obj-$(CONFIG_ARCH_BCM2835)	+= clk-bcm2835.o
 obj-$(CONFIG_ARCH_NOMADIK)	+= clk-nomadik.o
+obj-$(CONFIG_ARCH_HI3xxx)	+= clk-hi3xxx.o
 obj-$(CONFIG_ARCH_HIGHBANK)	+= clk-highbank.o
 obj-$(CONFIG_ARCH_MXS)		+= mxs/
 obj-$(CONFIG_ARCH_SOCFPGA)	+= socfpga/
diff --git a/drivers/clk/clk-hi3xxx.c b/drivers/clk/clk-hi3xxx.c
new file mode 100644
index 0000000..e93e583
--- /dev/null
+++ b/drivers/clk/clk-hi3xxx.c
@@ -0,0 +1,641 @@
+/*
+ * Hisilicon clock driver
+ *
+ * Copyright (c) 2012-2013 Hisilicon Limited.
+ * Copyright (c) 2012-2013 Linaro Limited.
+ *
+ * Author: Haojian Zhuang <haojian.zhuang at linaro.org>
+ *	   Xin Li <li.xin at linaro.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+ *
+ */
+
+#include <linux/kernel.h>
+#include <linux/clk-provider.h>
+#include <linux/clk-private.h>
+#include <linux/clkdev.h>
+#include <linux/delay.h>
+#include <linux/io.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_device.h>
+#include <linux/slab.h>
+#include <linux/clk.h>
+
+#define HI3620_DISABLE_OFF		0x4
+#define HI3620_STATUS_OFF		0x8
+
+#define WIDTH_TO_MASK(width)	((1 << (width)) - 1)
+
+/*
+ * The reverse of DIV_ROUND_UP: The maximum number which
+ * divided by m is r
+ */
+#define MULT_ROUND_UP(r, m) ((r) * (m) + (m) - 1)
+
+struct hi3620_periclk {
+	struct clk_hw	hw;
+	void __iomem	*enable;	/* enable register */
+	void __iomem	*reset;		/* reset register */
+	u32		ebits;		/* bits in enable/disable register */
+	u32		rbits;		/* bits in reset/unreset register */
+	spinlock_t	*lock;
+};
+
+struct hi3620_muxclk {
+	struct clk_hw	hw;
+	void __iomem	*reg;		/* mux register */
+	u8		shift;
+	u8		width;
+	u32		mbits;		/* mask bits in mux register */
+	spinlock_t	*lock;
+};
+
+struct hi3620_divclk {
+	struct clk_hw	hw;
+	void __iomem	*reg;		/* divider register */
+	u8		shift;
+	u8		width;
+	u32		mbits;		/* mask bits in divider register */
+	const struct clk_div_table	*table;
+	spinlock_t	*lock;
+};
+
+struct hs_clk {
+	void __iomem	*pmctrl;
+	void __iomem	*sctrl;
+	spinlock_t	lock;
+};
+
+static struct hs_clk hs_clk;
+
+static void __init hs_init_clocks(void)
+{
+	struct device_node *node = NULL;
+
+	if (!hs_clk.pmctrl) {
+		/* map pmctrl registers */
+		node = of_find_compatible_node(NULL, NULL, "hisilicon,pmctrl");
+		hs_clk.pmctrl = of_iomap(node, 0);
+		WARN_ON(!hs_clk.pmctrl);
+	}
+
+	if (!hs_clk.sctrl) {
+		node = of_find_compatible_node(NULL, NULL, "hisilicon,sctrl");
+		hs_clk.sctrl = of_iomap(node, 0);
+	}
+}
+
+static int hi3620_clkgate_prepare(struct clk_hw *hw)
+{
+	struct hi3620_periclk *pclk;
+	unsigned long flags = 0;
+
+	pclk = container_of(hw, struct hi3620_periclk, hw);
+
+	if (pclk->lock)
+		spin_lock_irqsave(pclk->lock, flags);
+	writel_relaxed(pclk->ebits, pclk->enable + HI3620_DISABLE_OFF);
+	writel_relaxed(pclk->rbits, pclk->reset + HI3620_DISABLE_OFF);
+	readl_relaxed(pclk->reset + HI3620_STATUS_OFF);
+	if (pclk->lock)
+		spin_unlock_irqrestore(pclk->lock, flags);
+	return 0;
+}
+
+static int hi3620_clkgate_enable(struct clk_hw *hw)
+{
+	struct hi3620_periclk *pclk;
+	unsigned long flags = 0;
+
+	pclk = container_of(hw, struct hi3620_periclk, hw);
+	if (pclk->lock)
+		spin_lock_irqsave(pclk->lock, flags);
+	writel_relaxed(pclk->ebits, pclk->enable);
+	readl_relaxed(pclk->enable + HI3620_STATUS_OFF);
+	if (pclk->lock)
+		spin_unlock_irqrestore(pclk->lock, flags);
+	return 0;
+}
+
+static void hi3620_clkgate_disable(struct clk_hw *hw)
+{
+	struct hi3620_periclk *pclk;
+	unsigned long flags = 0;
+
+	pclk = container_of(hw, struct hi3620_periclk, hw);
+	if (pclk->lock)
+		spin_lock_irqsave(pclk->lock, flags);
+	writel_relaxed(pclk->ebits, pclk->enable + HI3620_DISABLE_OFF);
+	readl_relaxed(pclk->enable + HI3620_STATUS_OFF);
+	if (pclk->lock)
+		spin_unlock_irqrestore(pclk->lock, flags);
+}
+
+static struct clk_ops hi3620_clkgate_ops = {
+	.prepare	= hi3620_clkgate_prepare,
+	.enable		= hi3620_clkgate_enable,
+	.disable	= hi3620_clkgate_disable,
+};
+
+static void __init hi3620_clkgate_setup(struct device_node *np)
+{
+	struct hi3620_periclk *pclk;
+	struct clk_init_data *init;
+	struct clk *clk;
+	const char *clk_name, *name, **parent_names;
+	u32 rdata[2], gdata[2];
+
+	if (!hs_clk.sctrl)
+		return;
+
+	if (of_property_read_string(np, "clock-output-names", &clk_name))
+		return;
+	if (of_property_read_u32_array(np, "hisilicon,hi3620-clkreset",
+				       &rdata[0], 2))
+		return;
+	if (of_property_read_u32_array(np, "hisilicon,hi3620-clkgate",
+				       &gdata[0], 2))
+		return;
+
+	/* gate only has the fixed parent */
+	parent_names = kzalloc(sizeof(char *), GFP_KERNEL);
+	if (!parent_names)
+		return;
+	parent_names[0] = of_clk_get_parent_name(np, 0);
+
+	pclk = kzalloc(sizeof(*pclk), GFP_KERNEL);
+	if (!pclk)
+		goto err_pclk;
+
+	init = kzalloc(sizeof(*init), GFP_KERNEL);
+	if (!init)
+		goto err_init;
+	init->name = kstrdup(clk_name, GFP_KERNEL);
+	init->ops = &hi3620_clkgate_ops;
+	init->flags = CLK_SET_RATE_PARENT;
+	init->parent_names = parent_names;
+	init->num_parents = 1;
+
+	pclk->reset = hs_clk.sctrl + rdata[0];
+	pclk->rbits = rdata[1];
+	pclk->enable = hs_clk.sctrl + gdata[0];
+	pclk->ebits = gdata[1];
+	pclk->lock = &hs_clk.lock;
+	pclk->hw.init = init;
+
+	clk = clk_register(NULL, &pclk->hw);
+	if (IS_ERR(clk))
+		goto err_clk;
+	if (!of_property_read_string(np, "clock-names", &name))
+		clk_register_clkdev(clk, name, NULL);
+	of_clk_add_provider(np, of_clk_src_simple_get, clk);
+	return;
+err_clk:
+	kfree(init);
+err_init:
+	kfree(pclk);
+err_pclk:
+	kfree(parent_names);
+}
+
+static u8 hi3620_clk_get_parent(struct clk_hw *hw)
+{
+	struct hi3620_muxclk *mclk;
+	u32 data;
+	unsigned long flags = 0;
+
+	mclk = container_of(hw, struct hi3620_muxclk, hw);
+
+	if (mclk->lock)
+		spin_lock_irqsave(mclk->lock, flags);
+
+	data = readl_relaxed(mclk->reg) >> mclk->shift;
+	data &= WIDTH_TO_MASK(mclk->width);
+
+	if (mclk->lock)
+		spin_unlock_irqrestore(mclk->lock, flags);
+
+	if (data >= __clk_get_num_parents(hw->clk))
+		return -EINVAL;
+
+	return (u8)data;
+}
+
+static int hi3620_clk_set_parent(struct clk_hw *hw, u8 index)
+{
+	struct hi3620_muxclk *mclk;
+	u32 data;
+	unsigned long flags = 0;
+
+	mclk = container_of(hw, struct hi3620_muxclk, hw);
+
+	if (mclk->lock)
+		spin_lock_irqsave(mclk->lock, flags);
+
+	data = readl_relaxed(mclk->reg);
+	data &= ~(WIDTH_TO_MASK(mclk->width) << mclk->shift);
+	data |= index << mclk->shift;
+	writel_relaxed(data, mclk->reg);
+	/* set mask enable bits */
+	data |= mclk->mbits;
+	writel_relaxed(data, mclk->reg);
+
+	if (mclk->lock)
+		spin_unlock_irqrestore(mclk->lock, flags);
+
+	return 0;
+}
+
+static struct clk_ops hi3620_clkmux_ops = {
+	.get_parent	= hi3620_clk_get_parent,
+	.set_parent	= hi3620_clk_set_parent,
+};
+
+static void __init hi3620_clkmux_setup(struct device_node *np)
+{
+	struct hi3620_muxclk *mclk;
+	struct clk_init_data *init;
+	struct clk *clk;
+	const char *clk_name, **parent_names;
+	u32 rdata[2];
+	u8 num_parents;
+	int i;
+
+	hs_init_clocks();
+	if (!hs_clk.sctrl)
+		return;
+
+	if (of_property_read_string(np, "clock-output-names", &clk_name))
+		return;
+	if (of_property_read_u32_array(np, "hisilicon,hi3620-clkmux",
+				       &rdata[0], 2))
+		return;
+	/* get the count of items in mux */
+	for (i = 0; ; i++) {
+		/* parent's #clock-cells property is always 0 */
+		if (!of_parse_phandle(np, "clocks", i))
+			break;
+	}
+	parent_names = kzalloc(sizeof(char *) * i, GFP_KERNEL);
+	if (!parent_names)
+		return;
+
+	for (num_parents = i, i = 0; i < num_parents; i++)
+		parent_names[i] = of_clk_get_parent_name(np, i);
+
+	mclk = kzalloc(sizeof(*mclk), GFP_KERNEL);
+	if (!mclk)
+		goto err_mclk;
+	init = kzalloc(sizeof(*init), GFP_KERNEL);
+	if (!init)
+		goto err_init;
+	init->name = kstrdup(clk_name, GFP_KERNEL);
+	init->ops = &hi3620_clkmux_ops;
+	init->flags = CLK_SET_RATE_PARENT;
+	init->parent_names = parent_names;
+	init->num_parents = num_parents;
+
+	mclk->reg = hs_clk.sctrl + rdata[0];
+	/* enable_mask bits are in higher 16bits */
+	mclk->mbits = rdata[1] << 16;
+	mclk->shift = ffs(rdata[1]) - 1;
+	mclk->width = fls(rdata[1]) - ffs(rdata[1]) + 1;
+	mclk->lock = &hs_clk.lock;
+	mclk->hw.init = init;
+
+	clk = clk_register(NULL, &mclk->hw);
+	if (IS_ERR(clk))
+		goto err_clk;
+	of_clk_add_provider(np, of_clk_src_simple_get, clk);
+
+	return;
+err_clk:
+	kfree(init);
+err_init:
+	kfree(mclk);
+err_mclk:
+	kfree(parent_names);
+}
+
+static void __init hs_clkgate_setup(struct device_node *np)
+{
+	struct clk *clk;
+	const char *clk_name, **parent_names, *name;
+	unsigned long flags = 0;
+	u32 data[2];
+
+	hs_init_clocks();
+	if (!hs_clk.sctrl)
+		return;
+	if (of_property_read_string(np, "clock-output-names", &clk_name))
+		return;
+	if (of_property_read_u32_array(np, "hisilicon,clkgate",
+				       &data[0], 2))
+		return;
+	if (of_property_read_bool(np, "hisilicon,clkgate-inverted"))
+		flags = CLK_GATE_SET_TO_DISABLE;
+	/* gate only has the fixed parent */
+	parent_names = kzalloc(sizeof(char *), GFP_KERNEL);
+	if (!parent_names)
+		return;
+	parent_names[0] = of_clk_get_parent_name(np, 0);
+
+	clk = clk_register_gate(NULL, clk_name, parent_names[0], 0,
+				hs_clk.sctrl + data[0], (u8)data[1], flags,
+				&hs_clk.lock);
+	if (IS_ERR(clk))
+		goto err;
+	if (!of_property_read_string(np, "clock-names", &name))
+		clk_register_clkdev(clk, name, NULL);
+	of_clk_add_provider(np, of_clk_src_simple_get, clk);
+	return;
+err:
+	kfree(parent_names);
+}
+
+void __init hs_fixed_factor_setup(struct device_node *np)
+{
+	struct clk *clk;
+	const char *clk_name, **parent_names;
+	u32 data[2];
+
+	if (of_property_read_string(np, "clock-output-names", &clk_name))
+		return;
+	if (of_property_read_u32_array(np, "hisilicon,fixed-factor",
+				       data, 2))
+		return ;
+	/* gate only has the fixed parent */
+	parent_names = kzalloc(sizeof(char *), GFP_KERNEL);
+	if (!parent_names)
+		return;
+	parent_names[0] = of_clk_get_parent_name(np, 0);
+
+	clk = clk_register_fixed_factor(NULL, clk_name, parent_names[0], 0,
+					data[0], data[1]);
+	if (IS_ERR(clk))
+		goto err;
+	of_clk_add_provider(np, of_clk_src_simple_get, clk);
+	return;
+err:
+	kfree(parent_names);
+}
+
+static unsigned int hi3620_get_table_maxdiv(const struct clk_div_table *table)
+{
+	unsigned int maxdiv = 0;
+	const struct clk_div_table *clkt;
+
+	for (clkt = table; clkt->div; clkt++)
+		if (clkt->div > maxdiv)
+			maxdiv = clkt->div;
+	return maxdiv;
+}
+
+static unsigned int hi3620_get_table_div(const struct clk_div_table *table,
+							unsigned int val)
+{
+	const struct clk_div_table *clkt;
+
+	for (clkt = table; clkt->div; clkt++)
+		if (clkt->val == val)
+			return clkt->div;
+	return 0;
+}
+
+static unsigned int hi3620_get_table_val(const struct clk_div_table *table,
+					 unsigned int div)
+{
+	const struct clk_div_table *clkt;
+
+	for (clkt = table; clkt->div; clkt++)
+		if (clkt->div == div)
+			return clkt->val;
+	return 0;
+}
+
+static unsigned long hi3620_clkdiv_recalc_rate(struct clk_hw *hw,
+					       unsigned long parent_rate)
+{
+	struct hi3620_divclk *dclk = container_of(hw, struct hi3620_divclk, hw);
+	unsigned int div, val;
+
+	val = readl_relaxed(dclk->reg) >> dclk->shift;
+	val &= WIDTH_TO_MASK(dclk->width);
+
+	div = hi3620_get_table_div(dclk->table, val);
+	if (!div) {
+		pr_warning("%s: Invalid divisor for clock %s\n", __func__,
+			   __clk_get_name(hw->clk));
+		return parent_rate;
+	}
+
+	return parent_rate / div;
+}
+
+static bool hi3620_is_valid_table_div(const struct clk_div_table *table,
+				      unsigned int div)
+{
+	const struct clk_div_table *clkt;
+
+	for (clkt = table; clkt->div; clkt++)
+		if (clkt->div == div)
+			return true;
+	return false;
+}
+
+static int hi3620_clkdiv_bestdiv(struct clk_hw *hw, unsigned long rate,
+				 unsigned long *best_parent_rate)
+{
+	struct hi3620_divclk *dclk = container_of(hw, struct hi3620_divclk, hw);
+	struct clk *clk_parent = __clk_get_parent(hw->clk);
+	int i, bestdiv = 0;
+	unsigned long parent_rate, best = 0, now, maxdiv;
+
+	maxdiv = hi3620_get_table_maxdiv(dclk->table);
+
+	if (!(__clk_get_flags(hw->clk) & CLK_SET_RATE_PARENT)) {
+		parent_rate = *best_parent_rate;
+		bestdiv = DIV_ROUND_UP(parent_rate, rate);
+		bestdiv = bestdiv == 0 ? 1 : bestdiv;
+		bestdiv = bestdiv > maxdiv ? maxdiv : bestdiv;
+		return bestdiv;
+	}
+
+	/*
+	 * The maximum divider we can use without overflowing
+	 * unsigned long in rate * i below
+	 */
+	maxdiv = min(ULONG_MAX / rate, maxdiv);
+
+	for (i = 1; i <= maxdiv; i++) {
+		if (!hi3620_is_valid_table_div(dclk->table, i))
+			continue;
+		parent_rate = __clk_round_rate(clk_parent,
+					       MULT_ROUND_UP(rate, i));
+		now = parent_rate / i;
+		if (now <= rate && now > best) {
+			bestdiv = i;
+			best = now;
+			*best_parent_rate = parent_rate;
+		}
+	}
+
+	if (!bestdiv) {
+		bestdiv = hi3620_get_table_maxdiv(dclk->table);
+		*best_parent_rate = __clk_round_rate(clk_parent, 1);
+	}
+
+	return bestdiv;
+}
+
+static long hi3620_clkdiv_round_rate(struct clk_hw *hw, unsigned long rate,
+				     unsigned long *prate)
+{
+	int div;
+
+	if (!rate)
+		rate = 1;
+	div = hi3620_clkdiv_bestdiv(hw, rate, prate);
+
+	return *prate / div;
+}
+
+static int hi3620_clkdiv_set_rate(struct clk_hw *hw, unsigned long rate,
+				  unsigned long parent_rate)
+{
+	struct hi3620_divclk *dclk = container_of(hw, struct hi3620_divclk, hw);
+	unsigned int div, value;
+	unsigned long flags = 0;
+	u32 data;
+
+	div = parent_rate / rate;
+	value = hi3620_get_table_val(dclk->table, div);
+
+	if (value > WIDTH_TO_MASK(dclk->width))
+		value = WIDTH_TO_MASK(dclk->width);
+
+	if (dclk->lock)
+		spin_lock_irqsave(dclk->lock, flags);
+
+	data = readl_relaxed(dclk->reg);
+	data &= ~(WIDTH_TO_MASK(dclk->width) << dclk->shift);
+	data |= value << dclk->shift;
+	data |= dclk->mbits;
+	writel_relaxed(data, dclk->reg);
+
+	if (dclk->lock)
+		spin_unlock_irqrestore(dclk->lock, flags);
+
+	return 0;
+}
+
+static struct clk_ops hi3620_clkdiv_ops = {
+	.recalc_rate = hi3620_clkdiv_recalc_rate,
+	.round_rate = hi3620_clkdiv_round_rate,
+	.set_rate = hi3620_clkdiv_set_rate,
+};
+
+void __init hi3620_clkdiv_setup(struct device_node *np)
+{
+	struct clk *clk;
+	const char *clk_name, **parent_names;
+	struct clk_init_data *init;
+	struct clk_div_table *table;
+	struct hi3620_divclk *dclk;
+	unsigned int table_num;
+	int i;
+	u32 data[2];
+	const char *propname = "hisilicon,clkdiv-table";
+	const char *cellname = "#hisilicon,clkdiv-table-cells";
+	struct of_phandle_args div_table;
+
+	hs_init_clocks();
+	if (!hs_clk.sctrl)
+		return;
+
+	if (of_property_read_string(np, "clock-output-names", &clk_name))
+		return;
+	if (of_property_read_u32_array(np, "hisilicon,clkdiv",
+				       &data[0], 2))
+		return;
+
+	/*process the div_table*/
+	for (i = 0; ; i++) {
+		if (of_parse_phandle_with_args(np, propname, cellname,
+					       i, &div_table))
+			break;
+	}
+
+	/*table ends with <0, 0>, so plus one to table_num*/
+	table_num = i + 1;
+
+	table = kzalloc(sizeof(struct clk_div_table) * table_num, GFP_KERNEL);
+	if (!table)
+		return ;
+
+	for (i = 0; ; i++) {
+		if (of_parse_phandle_with_args(np, propname, cellname,
+					       i, &div_table))
+			break;
+
+		table[i].val = div_table.args[0];
+		table[i].div = div_table.args[1];
+	}
+
+	/* gate only has the fixed parent */
+	parent_names = kzalloc(sizeof(char *), GFP_KERNEL);
+	if (!parent_names)
+		goto err_par;
+	parent_names[0] = of_clk_get_parent_name(np, 0);
+
+	dclk = kzalloc(sizeof(*dclk), GFP_KERNEL);
+	if (!dclk)
+		goto err_dclk;
+	init = kzalloc(sizeof(*init), GFP_KERNEL);
+	if (!init)
+		goto err_init;
+	init->name = kstrdup(clk_name, GFP_KERNEL);
+	init->ops = &hi3620_clkdiv_ops;
+	init->parent_names = parent_names;
+	init->num_parents = 1;
+
+	dclk->reg = hs_clk.sctrl + data[0];
+	dclk->shift = ffs(data[1]) - 1;
+	dclk->width = fls(data[1]) - ffs(data[1]) + 1;
+	dclk->mbits = data[1] << 16;
+	dclk->lock = &hs_clk.lock;
+	dclk->hw.init = init;
+	dclk->table = table;
+	clk = clk_register(NULL, &dclk->hw);
+	if (IS_ERR(clk))
+		goto err_clk;
+	of_clk_add_provider(np, of_clk_src_simple_get, clk);
+	return;
+err_clk:
+	kfree(init);
+err_init:
+	kfree(dclk);
+err_dclk:
+	kfree(parent_names);
+err_par:
+	kfree(table);
+}
+CLK_OF_DECLARE(hi3620_mux, "hisilicon,hi3620-clk-mux", hi3620_clkmux_setup)
+CLK_OF_DECLARE(hi3620_gate, "hisilicon,hi3620-clk-gate", hi3620_clkgate_setup)
+CLK_OF_DECLARE(hi3620_div, "hisilicon,hi3620-clk-div", hi3620_clkdiv_setup)
+CLK_OF_DECLARE(hs_gate, "hisilicon,clk-gate", hs_clkgate_setup)
+CLK_OF_DECLARE(hs_fixed, "hisilicon,clk-fixed-factor", hs_fixed_factor_setup)
-- 
1.7.10.4



From haojian.zhuang at linaro.org  Fri Apr 19 06:49:25 2013
From: haojian.zhuang at linaro.org (Haojian Zhuang)
Date: Fri, 19 Apr 2013 18:49:25 +0800
Subject: [PATCH 3/5] ARM: hi3xxx: add board support with device tree
In-Reply-To: <1366368567-17322-1-git-send-email-haojian.zhuang@linaro.org>
References: <1366368567-17322-1-git-send-email-haojian.zhuang@linaro.org>
Message-ID: <1366368567-17322-3-git-send-email-haojian.zhuang@linaro.org>

Add board support with device tree for Hisilicon Hi36xx/Hi37xx platform.

Signed-off-by: Haojian Zhuang <haojian.zhuang at linaro.org>
---
 .../bindings/arm/hisilicon/hisilicon.txt           |   10 +++++
 arch/arm/Kconfig                                   |    2 +
 arch/arm/Makefile                                  |    1 +
 arch/arm/mach-hi3xxx/Kconfig                       |   13 ++++++
 arch/arm/mach-hi3xxx/Makefile                      |    5 +++
 arch/arm/mach-hi3xxx/hi3xxx.c                      |   45 ++++++++++++++++++++
 6 files changed, 76 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
 create mode 100644 arch/arm/mach-hi3xxx/Kconfig
 create mode 100644 arch/arm/mach-hi3xxx/Makefile
 create mode 100644 arch/arm/mach-hi3xxx/hi3xxx.c

diff --git a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
new file mode 100644
index 0000000..3be60c8
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
@@ -0,0 +1,10 @@
+Hisilicon Platforms Device Tree Bindings
+----------------------------------------------------
+
+Hi3716 Development Board
+Required root node properties:
+	- compatible = "hisilicon,hi3716-dkb";
+
+Hi4511 Board
+Required root node properties:
+	- compatible = "hisilicon,hi3620-hi4511";
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 10e3053..ba3c11b 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1053,6 +1053,8 @@ source "arch/arm/mach-gemini/Kconfig"
 
 source "arch/arm/mach-h720x/Kconfig"
 
+source "arch/arm/mach-hi3xxx/Kconfig"
+
 source "arch/arm/mach-highbank/Kconfig"
 
 source "arch/arm/mach-integrator/Kconfig"
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index ee4605f..4b0de9e 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -148,6 +148,7 @@ machine-$(CONFIG_ARCH_EBSA110)		+= ebsa110
 machine-$(CONFIG_ARCH_EP93XX)		+= ep93xx
 machine-$(CONFIG_ARCH_GEMINI)		+= gemini
 machine-$(CONFIG_ARCH_H720X)		+= h720x
+machine-$(CONFIG_ARCH_HI3xxx)		+= hi3xxx
 machine-$(CONFIG_ARCH_HIGHBANK)		+= highbank
 machine-$(CONFIG_ARCH_INTEGRATOR)	+= integrator
 machine-$(CONFIG_ARCH_IOP13XX)		+= iop13xx
diff --git a/arch/arm/mach-hi3xxx/Kconfig b/arch/arm/mach-hi3xxx/Kconfig
new file mode 100644
index 0000000..a991dee
--- /dev/null
+++ b/arch/arm/mach-hi3xxx/Kconfig
@@ -0,0 +1,13 @@
+config ARCH_HI3xxx
+	bool "Hisilicon Hi36xx/Hi37xx family" if ARCH_MULTI_V7
+	select ARM_AMBA
+	select ARM_GIC
+	select CACHE_L2X0
+	select CACHE_PL310
+	select CLKSRC_OF
+	select PINCTRL
+	select PINCTRL_SINGLE
+	select SERIAL_AMBA_PL011
+	select SERIAL_AMBA_PL011_CONSOLE
+	help
+	  Support for Hisilicon Hi36xx/Hi37xx processor family
diff --git a/arch/arm/mach-hi3xxx/Makefile b/arch/arm/mach-hi3xxx/Makefile
new file mode 100644
index 0000000..d68ebb3
--- /dev/null
+++ b/arch/arm/mach-hi3xxx/Makefile
@@ -0,0 +1,5 @@
+#
+# Makefile for Hisilicon Hi36xx/Hi37xx processors line
+#
+
+obj-y	+= hi3xxx.o
diff --git a/arch/arm/mach-hi3xxx/hi3xxx.c b/arch/arm/mach-hi3xxx/hi3xxx.c
new file mode 100644
index 0000000..df0a472
--- /dev/null
+++ b/arch/arm/mach-hi3xxx/hi3xxx.c
@@ -0,0 +1,45 @@
+/*
+ * (Hisilicon's Hi36xx/Hi37xx SoC based) flattened device tree enabled machine
+ *
+ * Copyright (c) 2012-2013 Hisilicon Ltd.
+ * Copyright (c) 2012-2013 Linaro Ltd.
+ *
+ * Author: Haojian Zhuang <haojian.zhuang at linaro.org>
+ *
+ * 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/clk-provider.h>
+#include <linux/clocksource.h>
+#include <linux/irqchip.h>
+#include <linux/of_platform.h>
+
+#include <asm/mach/arch.h>
+#include <asm/mach/map.h>
+
+static void __init hi3xxx_timer_init(void)
+{
+	of_clk_init(NULL);
+	clocksource_of_init();
+}
+
+static void __init hs_init(void)
+{
+	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
+}
+
+static const char *hs_compat[] __initdata = {
+	"hisilicon,hi3620-hi4511",
+	NULL,
+};
+
+DT_MACHINE_START(HI3xxx, "Hisilicon Hi36xx/Hi37xx (Flattened Device Tree)")
+	/* Maintainer: Haojian Zhuang <haojian.zhuang at linaro.org> */
+	.map_io		= debug_ll_io_init,
+	.init_irq	= irqchip_init,
+	.init_time	= hi3xxx_timer_init,
+	.init_machine	= hs_init,
+	.dt_compat	= hs_compat,
+MACHINE_END
-- 
1.7.10.4



From haojian.zhuang at linaro.org  Fri Apr 19 06:49:26 2013
From: haojian.zhuang at linaro.org (Haojian Zhuang)
Date: Fri, 19 Apr 2013 18:49:26 +0800
Subject: [PATCH 4/5] ARM: hi3xxx: enable hi4511 with device tree
In-Reply-To: <1366368567-17322-1-git-send-email-haojian.zhuang@linaro.org>
References: <1366368567-17322-1-git-send-email-haojian.zhuang@linaro.org>
Message-ID: <1366368567-17322-4-git-send-email-haojian.zhuang@linaro.org>

Enable Hisilicon Hi4511 development platform with device tree support.

Signed-off-by: Haojian Zhuang <haojian.zhuang at linaro.org>
---
 arch/arm/boot/dts/Makefile    |    1 +
 arch/arm/boot/dts/hi3620.dtsi | 1155 +++++++++++++++++++++++++++++++++++++++++
 arch/arm/boot/dts/hi4511.dts  |  738 ++++++++++++++++++++++++++
 3 files changed, 1894 insertions(+)
 create mode 100644 arch/arm/boot/dts/hi3620.dtsi
 create mode 100644 arch/arm/boot/dts/hi4511.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 08d298d..742920d 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -46,6 +46,7 @@ dtb-$(CONFIG_ARCH_EXYNOS) += exynos4210-origen.dtb \
 	exynos5250-smdk5250.dtb \
 	exynos5250-snow.dtb \
 	exynos5440-ssdk5440.dtb
+dtb-$(CONFIG_ARCH_HI3xxx) += hi4511.dtb
 dtb-$(CONFIG_ARCH_HIGHBANK) += highbank.dtb \
 	ecx-2000.dtb
 dtb-$(CONFIG_ARCH_INTEGRATOR) += integratorap.dtb \
diff --git a/arch/arm/boot/dts/hi3620.dtsi b/arch/arm/boot/dts/hi3620.dtsi
new file mode 100644
index 0000000..e33fe7f
--- /dev/null
+++ b/arch/arm/boot/dts/hi3620.dtsi
@@ -0,0 +1,1155 @@
+/*
+ * Hisilicon Ltd. Hi3620 SoC
+ *
+ * Copyright (C) 2012-2013 Hisilicon Ltd.
+ * Copyright (C) 2012-2013 Linaro Ltd.
+ *
+ * Author: Haojian Zhuang <haojian.zhuang at linaro.org>
+ *
+ * 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
+ * publishhed by the Free Software Foundation.
+ */
+
+/include/ "skeleton.dtsi"
+
+/ {
+	aliases {
+		serial0 = &uart0;
+		serial1 = &uart1;
+		serial2 = &uart2;
+		serial3 = &uart3;
+		serial4 = &uart4;
+	};
+
+	osc32k: osc at 0 {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <32768>;
+		clock-output-names = "osc32khz";
+	};
+	osc26m: osc at 1 {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <26000000>;
+		clock-output-names = "osc26mhz";
+	};
+	pclk: clk at 0 {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <26000000>;
+		clock-output-names = "apb_pclk";
+	};
+	pll_arm0: clk at 1 {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <1600000000>;
+		clock-output-names = "armpll0";
+	};
+	pll_arm1: clk at 2 {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <1600000000>;
+		clock-output-names = "armpll1";
+	};
+	pll_peri: clk at 3 {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <1440000000>;
+		clock-output-names = "armpll2";
+	};
+	pll_usb: clk at 4 {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <1440000000>;
+		clock-output-names = "armpll3";
+	};
+	pll_hdmi: clk at 5 {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <1188000000>;
+		clock-output-names = "armpll4";
+	};
+	pll_gpu: clk at 6 {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <1300000000>;
+		clock-output-names = "armpll5";
+	};
+
+	amba {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		compatible = "arm,amba-bus";
+		interrupt-parent = <&intc>;
+		ranges;
+
+		pmctrl: pmctrl at fca08000 {
+			compatible = "hisilicon,pmctrl";
+			reg = <0xfca08000 0x1000>;
+ 		};
+
+		sctrl: sctrl at fc802000 {
+			compatible = "hisilicon,sctrl";
+			reg = <0xfc802000 0x1000>;
+
+			refclk_uart0: refclk at 0 {
+				compatible = "hisilicon,hi3620-clk-mux";
+				#clock-cells = <0>;
+				clocks = <&osc26m &pclk>;
+				clock-output-names = "rclk_uart0";
+				/* each item value */
+				/* reg_offset, enable_bits */
+				hisilicon,hi3620-clkmux = <0x100 0x80>;
+			};
+			refclk_uart1: refclk at 1 {
+				compatible = "hisilicon,hi3620-clk-mux";
+				#clock-cells = <0>;
+				clocks = <&osc26m &pclk>;
+				clock-output-names = "rclk_uart1";
+				hisilicon,hi3620-clkmux = <0x100 0x100>;
+			};
+			refclk_uart2: refclk at 2 {
+				compatible = "hisilicon,hi3620-clk-mux";
+				#clock-cells = <0>;
+				clocks = <&osc26m &pclk>;
+				clock-output-names = "rclk_uart2";
+				hisilicon,hi3620-clkmux = <0x100 0x200>;
+			};
+			refclk_uart3: refclk at 3 {
+				compatible = "hisilicon,hi3620-clk-mux";
+				#clock-cells = <0>;
+				clocks = <&osc26m &pclk>;
+				clock-output-names = "rclk_uart3";
+				hisilicon,hi3620-clkmux = <0x100 0x400>;
+			};
+			refclk_uart4: refclk at 4 {
+				compatible = "hisilicon,hi3620-clk-mux";
+				#clock-cells = <0>;
+				clocks = <&osc26m &pclk>;
+				clock-output-names = "rclk_uart4";
+				hisilicon,hi3620-clkmux = <0x100 0x800>;
+			};
+			refclk_cfgaxi: refclk at 5 {
+				compatible = "hisilicon,clk-fixed-factor";
+				#clock-cells = <0>;
+				clocks = <&pll_peri>;
+				clock-output-names = "rclk_cfgaxi";
+				/*mult, div*/
+				hisilicon,fixed-factor = <1 30>;
+			};
+			refclk_spi0: refclk at 6 {
+				compatible = "hisilicon,hi3620-clk-mux";
+				#clock-cells = <0>;
+				clocks = <&osc26m &refclk_cfgaxi>;
+				clock-output-names = "rclk_spi0";
+				hisilicon,hi3620-clkmux = <0x100 0x1000>;
+			};
+			refclk_spi1: refclk at 7 {
+				compatible = "hisilicon,hi3620-clk-mux";
+				#clock-cells = <0>;
+				clocks = <&osc26m &refclk_cfgaxi>;
+				clock-output-names = "rclk_spi1";
+				hisilicon,hi3620-clkmux = <0x100 0x2000>;
+			};
+			refclk_spi2: refclk at 8 {
+				compatible = "hisilicon,hi3620-clk-mux";
+				#clock-cells = <0>;
+				clocks = <&osc26m &refclk_cfgaxi>;
+				clock-output-names = "rclk_spi2";
+				hisilicon,hi3620-clkmux = <0x100 0x4000>;
+			};
+			refclk_pwm0: refclk at 9 {
+				compatible = "hisilicon,hi3620-clk-mux";
+				#clock-cells = <0>;
+				clocks = <&osc32k &osc26m>;
+				clock-output-names = "rclk_pwm0";
+				hisilicon,hi3620-clkmux = <0x104 0x400>;
+			};
+			refclk_pwm1: refclk at 10 {
+				compatible = "hisilicon,hi3620-clk-mux";
+				#clock-cells = <0>;
+				clocks = <&osc32k &osc26m>;
+				clock-output-names = "rclk_pwm1";
+				hisilicon,hi3620-clkmux = <0x104 0x800>;
+			};
+			refclk_tcxo: refclk at 11 {
+				compatible = "hisilicon,clk-fixed-factor";
+				#clock-cells = <0>;
+				clocks = <&osc26m>;
+				clock-output-names = "rclk_tcxo";
+				hisilicon,fixed-factor = <1 4>;
+			};
+			refclk_timer0: refclk at 12 {
+				compatible = "hisilicon,hi3620-clk-mux";
+				#clock-cells = <0>;
+				clocks = <&osc32k &timerclk01>;
+				clock-output-names = "rclk_tim0";
+				hisilicon,hi3620-clkmux = <0 0x8000>;
+			};
+			refclk_timer1: refclk at 13 {
+				compatible = "hisilicon,hi3620-clk-mux";
+				#clock-cells = <0>;
+				clocks = <&osc32k &timerclk01>;
+				clock-output-names = "rclk_tim1";
+				hisilicon,hi3620-clkmux = <0 0x20000>;
+			};
+			refclk_timer2: refclk at 14 {
+				compatible = "hisilicon,hi3620-clk-mux";
+				#clock-cells = <0>;
+				clocks = <&osc32k &timerclk23>;
+				clock-output-names = "rclk_tim2";
+				hisilicon,hi3620-clkmux = <0 0x80000>;
+			};
+			refclk_timer3: refclk at 15 {
+				compatible = "hisilicon,hi3620-clk-mux";
+				#clock-cells = <0>;
+				clocks = <&osc32k &timerclk23>;
+				clock-output-names = "rclk_tim3";
+				hisilicon,hi3620-clkmux = <0 0x200000>;
+			};
+			refclk_timer4: refclk at 16 {
+				compatible = "hisilicon,hi3620-clk-mux";
+				#clock-cells = <0>;
+				clocks = <&osc32k &timerclk45>;
+				clock-output-names = "rclk_tim4";
+				hisilicon,hi3620-clkmux = <0x18 0x1>;
+			};
+			refclk_timer5: refclk at 17 {
+				compatible = "hisilicon,hi3620-clk-mux";
+				#clock-cells = <0>;
+				clocks = <&osc32k &timerclk45>;
+				clock-output-names = "rclk_tim5";
+				hisilicon,hi3620-clkmux = <0x18 0x4>;
+			};
+			refclk_timer6: refclk at 18 {
+				compatible = "hisilicon,hi3620-clk-mux";
+				#clock-cells = <0>;
+				clocks = <&osc32k &timerclk67>;
+				clock-output-names = "rclk_tim6";
+				hisilicon,hi3620-clkmux = <0x18 0x10>;
+			};
+			refclk_timer7: refclk at 19 {
+				compatible = "hisilicon,hi3620-clk-mux";
+				#clock-cells = <0>;
+				clocks = <&osc32k &timerclk67>;
+				clock-output-names = "rclk_tim7";
+				hisilicon,hi3620-clkmux = <0x18 0x40>;
+			};
+			refclk_timer8: refclk at 20 {
+				compatible = "hisilicon,hi3620-clk-mux";
+				#clock-cells = <0>;
+				clocks = <&osc32k &timerclk89>;
+				clock-output-names = "rclk_tim8";
+				hisilicon,hi3620-clkmux = <0x18 0x100>;
+			};
+			refclk_timer9: refclk at 21 {
+				compatible = "hisilicon,hi3620-clk-mux";
+				#clock-cells = <0>;
+				clocks = <&osc32k &timerclk89>;
+				clock-output-names = "rclk_tim9";
+				hisilicon,hi3620-clkmux = <0x18 0x400>;
+			};
+			refclk_shareAXI: refclk at 22 {
+				compatible = "hisilicon,hi3620-clk-mux";
+				#clock-cells = <0>;
+				clocks = <&pll_usb &pll_peri>;
+				clock-output-names = "rclk_shareAXI";
+				hisilicon,hi3620-clkmux = <0x24 0x8000>;
+			};
+			uartclk0: clkgate at 0 {
+				compatible = "hisilicon,hi3620-clk-gate";
+				#clock-cells = <0>;
+				clocks = <&refclk_uart0>;
+				clock-output-names = "uartclk0";
+				hisilicon,hi3620-clkreset = <0x98 0x10000>;
+				hisilicon,hi3620-clkgate = <0x40 0x10000>;
+			};
+			uartclk1: clkgate at 1 {
+				compatible = "hisilicon,hi3620-clk-gate";
+				#clock-cells = <0>;
+				clocks = <&refclk_uart1>;
+				clock-output-names = "uartclk1";
+				hisilicon,hi3620-clkreset = <0x98 0x20000>;
+				hisilicon,hi3620-clkgate = <0x40 0x20000>;
+			};
+			uartclk2: clkgate at 2 {
+				compatible = "hisilicon,hi3620-clk-gate";
+				#clock-cells = <0>;
+				clocks = <&refclk_uart2>;
+				clock-output-names = "uartclk2";
+				hisilicon,hi3620-clkreset = <0x98 0x40000>;
+				hisilicon,hi3620-clkgate = <0x40 0x40000>;
+			};
+			uartclk3: clkgate at 3 {
+				compatible = "hisilicon,hi3620-clk-gate";
+				#clock-cells = <0>;
+				clocks = <&refclk_uart3>;
+				clock-output-names = "uartclk3";
+				hisilicon,hi3620-clkreset = <0x98 0x80000>;
+				hisilicon,hi3620-clkgate = <0x40 0x80000>;
+			};
+			uartclk4: clkgate at 4 {
+				compatible = "hisilicon,hi3620-clk-gate";
+				#clock-cells = <0>;
+				clocks = <&refclk_uart4>;
+				clock-output-names = "uartclk4";
+				hisilicon,hi3620-clkreset = <0x98 0x100000>;
+				hisilicon,hi3620-clkgate = <0x40 0x100000>;
+			};
+			gpioclk0: clkgate at 5 {
+				compatible = "hisilicon,hi3620-clk-gate";
+				#clock-cells = <0>;
+				clocks = <&pclk>;
+				clock-output-names = "gpioclk0";
+				hisilicon,hi3620-clkreset = <0x80 0x100>;
+				hisilicon,hi3620-clkgate = <0x20 0x100>;
+			};
+			gpioclk1: clkgate at 6 {
+				compatible = "hisilicon,hi3620-clk-gate";
+				#clock-cells = <0>;
+				clocks = <&pclk>;
+				clock-output-names = "gpioclk1";
+				hisilicon,hi3620-clkreset = <0x80 0x200>;
+				hisilicon,hi3620-clkgate = <0x20 0x200>;
+			};
+			gpioclk2: clkgate at 7 {
+				compatible = "hisilicon,hi3620-clk-gate";
+				#clock-cells = <0>;
+				clocks = <&pclk>;
+				clock-output-names = "gpioclk2";
+				hisilicon,hi3620-clkreset = <0x80 0x400>;
+				hisilicon,hi3620-clkgate = <0x20 0x400>;
+			};
+			gpioclk3: clkgate at 8 {
+				compatible = "hisilicon,hi3620-clk-gate";
+				#clock-cells = <0>;
+				clocks = <&pclk>;
+				clock-output-names = "gpioclk3";
+				hisilicon,hi3620-clkreset = <0x80 0x800>;
+				hisilicon,hi3620-clkgate = <0x20 0x800>;
+			};
+			gpioclk4: clkgate at 9 {
+				compatible = "hisilicon,hi3620-clk-gate";
+				#clock-cells = <0>;
+				clocks = <&pclk>;
+				clock-output-names = "gpioclk4";
+				hisilicon,hi3620-clkreset = <0x80 0x1000>;
+				hisilicon,hi3620-clkgate = <0x20 0x1000>;
+			};
+			gpioclk5: clkgate at 10 {
+				compatible = "hisilicon,hi3620-clk-gate";
+				#clock-cells = <0>;
+				clocks = <&pclk>;
+				clock-output-names = "gpioclk5";
+				hisilicon,hi3620-clkreset = <0x80 0x2000>;
+				hisilicon,hi3620-clkgate = <0x20 0x2000>;
+			};
+			gpioclk6: clkgate at 11 {
+				compatible = "hisilicon,hi3620-clk-gate";
+				#clock-cells = <0>;
+				clocks = <&pclk>;
+				clock-output-names = "gpioclk6";
+				hisilicon,hi3620-clkreset = <0x80 0x4000>;
+				hisilicon,hi3620-clkgate = <0x20 0x4000>;
+			};
+			gpioclk7: clkgate at 12 {
+				compatible = "hisilicon,hi3620-clk-gate";
+				#clock-cells = <0>;
+				clocks = <&pclk>;
+				clock-output-names = "gpioclk7";
+				hisilicon,hi3620-clkreset = <0x80 0x8000>;
+				hisilicon,hi3620-clkgate = <0x20 0x8000>;
+			};
+			gpioclk8: clkgate at 13 {
+				compatible = "hisilicon,hi3620-clk-gate";
+				#clock-cells = <0>;
+				clocks = <&pclk>;
+				clock-output-names = "gpioclk8";
+				hisilicon,hi3620-clkreset = <0x80 0x10000>;
+				hisilicon,hi3620-clkgate = <0x20 0x10000>;
+			};
+			gpioclk9: clkgate at 14 {
+				compatible = "hisilicon,hi3620-clk-gate";
+				#clock-cells = <0>;
+				clocks = <&pclk>;
+				clock-output-names = "gpioclk9";
+				hisilicon,hi3620-clkreset = <0x80 0x20000>;
+				hisilicon,hi3620-clkgate = <0x20 0x20000>;
+			};
+			gpioclk10: clkgate at 15 {
+				compatible = "hisilicon,hi3620-clk-gate";
+				#clock-cells = <0>;
+				clocks = <&pclk>;
+				clock-output-names = "gpioclk10";
+				hisilicon,hi3620-clkreset = <0x80 0x40000>;
+				hisilicon,hi3620-clkgate = <0x20 0x40000>;
+			};
+			gpioclk11: clkgate at 16 {
+				compatible = "hisilicon,hi3620-clk-gate";
+				#clock-cells = <0>;
+				clocks = <&pclk>;
+				clock-output-names = "gpioclk11";
+				hisilicon,hi3620-clkreset = <0x80 0x80000>;
+				hisilicon,hi3620-clkgate = <0x20 0x80000>;
+			};
+			gpioclk12: clkgate at 17 {
+				compatible = "hisilicon,hi3620-clk-gate";
+				#clock-cells = <0>;
+				clocks = <&pclk>;
+				clock-output-names = "gpioclk12";
+				hisilicon,hi3620-clkreset = <0x80 0x100000>;
+				hisilicon,hi3620-clkgate = <0x20 0x100000>;
+			};
+			gpioclk13: clkgate at 18 {
+				compatible = "hisilicon,hi3620-clk-gate";
+				#clock-cells = <0>;
+				clocks = <&pclk>;
+				clock-output-names = "gpioclk13";
+				hisilicon,hi3620-clkreset = <0x80 0x200000>;
+				hisilicon,hi3620-clkgate = <0x20 0x200000>;
+			};
+			gpioclk14: clkgate at 19 {
+				compatible = "hisilicon,hi3620-clk-gate";
+				#clock-cells = <0>;
+				clocks = <&pclk>;
+				clock-output-names = "gpioclk14";
+				hisilicon,hi3620-clkreset = <0x80 0x400000>;
+				hisilicon,hi3620-clkgate = <0x20 0x400000>;
+			};
+			gpioclk15: clkgate at 20 {
+				compatible = "hisilicon,hi3620-clk-gate";
+				#clock-cells = <0>;
+				clocks = <&pclk>;
+				clock-output-names = "gpioclk15";
+				hisilicon,hi3620-clkreset = <0x80 0x800000>;
+				hisilicon,hi3620-clkgate = <0x20 0x800000>;
+			};
+			gpioclk16: clkgate at 21 {
+				compatible = "hisilicon,hi3620-clk-gate";
+				#clock-cells = <0>;
+				clocks = <&pclk>;
+				clock-output-names = "gpioclk16";
+				hisilicon,hi3620-clkreset = <0x80 0x1000000>;
+				hisilicon,hi3620-clkgate = <0x20 0x1000000>;
+			};
+			gpioclk17: clkgate at 22 {
+				compatible = "hisilicon,hi3620-clk-gate";
+				#clock-cells = <0>;
+				clocks = <&pclk>;
+				clock-output-names = "gpioclk17";
+				hisilicon,hi3620-clkreset = <0x80 0x2000000>;
+				hisilicon,hi3620-clkgate = <0x20 0x2000000>;
+			};
+			gpioclk18: clkgate at 23 {
+				compatible = "hisilicon,hi3620-clk-gate";
+				#clock-cells = <0>;
+				clocks = <&pclk>;
+				clock-output-names = "gpioclk18";
+				hisilicon,hi3620-clkreset = <0x80 0x4000000>;
+				hisilicon,hi3620-clkgate = <0x20 0x4000000>;
+			};
+			gpioclk19: clkgate at 24 {
+				compatible = "hisilicon,hi3620-clk-gate";
+				#clock-cells = <0>;
+				clocks = <&pclk>;
+				clock-output-names = "gpioclk19";
+				hisilicon,hi3620-clkreset = <0x80 0x8000000>;
+				hisilicon,hi3620-clkgate = <0x20 0x8000000>;
+			};
+			gpioclk20: clkgate at 25 {
+				compatible = "hisilicon,hi3620-clk-gate";
+				#clock-cells = <0>;
+				clocks = <&pclk>;
+				clock-output-names = "gpioclk20";
+				hisilicon,hi3620-clkreset = <0x80 0x10000000>;
+				hisilicon,hi3620-clkgate = <0x20 0x10000000>;
+			};
+			gpioclk21: clkgate at 26 {
+				compatible = "hisilicon,hi3620-clk-gate";
+				#clock-cells = <0>;
+				clocks = <&pclk>;
+				clock-output-names = "gpioclk21";
+				hisilicon,hi3620-clkreset = <0x80 0x20000000>;
+				hisilicon,hi3620-clkgate = <0x20 0x20000000>;
+			};
+			spiclk0: clkgate at 27 {
+				compatible = "hisilicon,hi3620-clk-gate";
+				#clock-cells = <0>;
+				clocks = <&refclk_spi0>;
+				clock-output-names = "spiclk0";
+				hisilicon,hi3620-clkreset = <0x98 0x200000>;
+				hisilicon,hi3620-clkgate = <0x40 0x200000>;
+			};
+			spiclk1: clkgate at 28 {
+				compatible = "hisilicon,hi3620-clk-gate";
+				#clock-cells = <0>;
+				clocks = <&refclk_spi1>;
+				clock-output-names = "spiclk1";
+				hisilicon,hi3620-clkreset = <0x98 0x400000>;
+				hisilicon,hi3620-clkgate = <0x40 0x400000>;
+			};
+			spiclk2: clkgate at 29 {
+				compatible = "hisilicon,hi3620-clk-gate";
+				#clock-cells = <0>;
+				clocks = <&refclk_spi2>;
+				clock-output-names = "spiclk2";
+				hisilicon,hi3620-clkreset = <0x98 0x800000>;
+				hisilicon,hi3620-clkgate = <0x40 0x800000>;
+			};
+			pwmclk0: clkgate at 30 {
+				compatible = "hisilicon,hi3620-clk-gate";
+				#clock-cells = <0>;
+				clocks = <&refclk_pwm0>;
+				clock-output-names = "pwmclk0";
+				hisilicon,hi3620-clkreset = <0x98 0x80>;
+				hisilicon,hi3620-clkgate = <0x40 0x80>;
+			};
+			pwmclk1: clkgate at 31 {
+				compatible = "hisilicon,hi3620-clk-gate";
+				#clock-cells = <0>;
+				clocks = <&refclk_pwm1>;
+				clock-output-names = "pwmclk1";
+				hisilicon,hi3620-clkreset = <0x98 0x100>;
+				hisilicon,hi3620-clkgate = <0x40 0x100>;
+			};
+			timerclk01: clkgate at 32 {
+				compatible = "hisilicon,hi3620-clk-gate";
+				#clock-cells = <0>;
+				clocks = <&refclk_tcxo>;
+				clock-output-names = "timerclk01";
+				hisilicon,hi3620-clkreset = <0x80 0x1>;
+				hisilicon,hi3620-clkgate = <0x20 0x3>;
+			};
+			timerclk23: clkgate at 33 {
+				compatible = "hisilicon,hi3620-clk-gate";
+				#clock-cells = <0>;
+				clocks = <&refclk_tcxo>;
+				clock-output-names = "timerclk23";
+				hisilicon,hi3620-clkreset = <0x80 0x2>;
+				hisilicon,hi3620-clkgate = <0x20 0xc>;
+			};
+			timerclk45: clkgate at 34 {
+				compatible = "hisilicon,hi3620-clk-gate";
+				#clock-cells = <0>;
+				clocks = <&refclk_tcxo>;
+				clock-output-names = "timerclk45";
+				hisilicon,hi3620-clkreset = <0x98 0x8>;
+				hisilicon,hi3620-clkgate = <0x40 0x8>;
+			};
+			timerclk67: clkgate at 35 {
+				compatible = "hisilicon,hi3620-clk-gate";
+				#clock-cells = <0>;
+				clocks = <&refclk_tcxo>;
+				clock-output-names = "timerclk67";
+				hisilicon,hi3620-clkreset = <0x98 0x10>;
+				hisilicon,hi3620-clkgate = <0x40 0x10>;
+			};
+			timerclk89: clkgate at 36 {
+				compatible = "hisilicon,hi3620-clk-gate";
+				#clock-cells = <0>;
+				clocks = <&refclk_tcxo>;
+				clock-output-names = "timerclk89";
+				hisilicon,hi3620-clkreset = <0x98 0x20>;
+				hisilicon,hi3620-clkgate = <0x40 0x20>;
+			};
+			timclk0: clkgate at 37 {
+				compatible = "hisilicon,clk-gate";
+				#clock-cells = <0>;
+				clocks = <&refclk_timer0>;
+				clock-output-names = "timclk0";
+				hisilicon,clkgate-inverted;
+				hisilicon,clkgate = <0 16>;
+			};
+			timclk1: clkgate at 38 {
+				compatible = "hisilicon,clk-gate";
+				#clock-cells = <0>;
+				clocks = <&refclk_timer1>;
+				clock-output-names = "timclk1";
+				hisilicon,clkgate-inverted;
+				hisilicon,clkgate = <0 18>;
+			};
+			timclk2: clkgate at 39 {
+				compatible = "hisilicon,clk-gate";
+				#clock-cells = <0>;
+				clocks = <&refclk_timer2>;
+				clock-output-names = "timclk2";
+				hisilicon,clkgate-inverted;
+				hisilicon,clkgate = <0 20>;
+			};
+			timclk3: clkgate at 40 {
+				compatible = "hisilicon,clk-gate";
+				#clock-cells = <0>;
+				clocks = <&refclk_timer3>;
+				clock-output-names = "timclk3";
+				hisilicon,clkgate-inverted;
+				hisilicon,clkgate = <0 22>;
+			};
+			timclk4: clkgate at 41 {
+				compatible = "hisilicon,clk-gate";
+				#clock-cells = <0>;
+				clocks = <&refclk_timer4>;
+				clock-output-names = "timclk4";
+				hisilicon,clkgate-inverted;
+				hisilicon,clkgate = <0x18 0>;
+			};
+			timclk5: clkgate at 42 {
+				compatible = "hisilicon,clk-gate";
+				#clock-cells = <0>;
+				clocks = <&refclk_timer5>;
+				clock-output-names = "timclk5";
+				hisilicon,clkgate-inverted;
+				hisilicon,clkgate = <0x18 2>;
+			};
+			timclk6: clkgate at 43 {
+				compatible = "hisilicon,clk-gate";
+				#clock-cells = <0>;
+				clocks = <&refclk_timer6>;
+				clock-output-names = "timclk6";
+				hisilicon,clkgate-inverted;
+				hisilicon,clkgate = <0x18 4>;
+			};
+			timclk7: clkgate at 44 {
+				compatible = "hisilicon,clk-gate";
+				#clock-cells = <0>;
+				clocks = <&refclk_timer7>;
+				clock-output-names = "timclk7";
+				hisilicon,clkgate-inverted;
+				hisilicon,clkgate = <0x18 6>;
+			};
+			timclk8: clkgate at 45 {
+				compatible = "hisilicon,clk-gate";
+				#clock-cells = <0>;
+				clocks = <&refclk_timer8>;
+				clock-output-names = "timclk8";
+				hisilicon,clkgate-inverted;
+				hisilicon,clkgate = <0x18 8>;
+			};
+			timclk9: clkgate at 46 {
+				compatible = "hisilicon,clk-gate";
+				#clock-cells = <0>;
+				clocks = <&refclk_timer9>;
+				clock-output-names = "timclk9";
+				hisilicon,clkgate-inverted;
+				hisilicon,clkgate = <0x18 10>;
+			};
+			dtable: clkdiv at 0 {
+				#hisilicon,clkdiv-table-cells = <2>;
+			};
+			div_shareaxi: clkdiv at 1 {
+				compatible = "hisilicon,hi3620-clk-div";
+				#clock-cells = <0>;
+				clocks = <&refclk_shareAXI>;
+				clock-output-names = "shareAXI_div";
+				hisilicon,clkdiv-table = <
+					&dtable 0 1 &dtable 1 2 &dtable 2 3 &dtable 3 4
+					&dtable 4 5 &dtable 5 6 &dtable 6 7 &dtable 7 8
+					&dtable 8 9 &dtable 9 10 &dtable 10 11 &dtable 11 12
+					&dtable 12 13 &dtable 13 14 &dtable 14 15 &dtable 15 16
+					&dtable 16 17 &dtable 17 18 &dtable 18 19 &dtable 19 20
+					&dtable 20 21 &dtable 21 22 &dtable 22 23 &dtable 23 24
+					&dtable 24 25 &dtable 25 26 &dtable 26 27 &dtable 27 28
+					&dtable 28 29 &dtable 29 30 &dtable 30 31 &dtable 31 32>;
+				/* divider register offset, mask */
+				hisilicon,clkdiv = <0x100 0x1f>;
+			};
+			div_cfgaxi: clkdiv at 2 {
+				compatible = "hisilicon,hi3620-clk-div";
+				#clock-cells = <0>;
+				clocks = <&div_shareaxi>;
+				clock-output-names = "cfgAXI_div";
+				hisilicon,clkdiv-table = <&dtable 0x01 2>;
+				hisilicon,clkdiv = <0x100 0x60>;
+			};
+ 		};
+
+		l2: l2-cache {
+			compatible = "arm,pl310-cache";
+			reg = <0xfc10000 0x100000>;
+			interrupts = <0 15 4>;
+			cache-unified;
+			cache-level = <2>;
+		};
+
+		intc: interrupt-controller at fc001000 {
+			compatible = "arm,cortex-a9-gic";
+			#interrupt-cells = <3>;
+			#address-cells = <0>;
+			interrupt-controller;
+			/* gic dist base, gic cpu base */
+			reg = <0xfc001000 0x1000>, <0xfc000100 0x100>;
+		};
+
+		timer0: timer at fc800000 {
+			compatible = "arm,sp804", "arm,primecell";
+			reg = <0xfc800000 0x1000>;
+			/* timer00 & timer01 */
+			interrupts = <0 0 4>, <0 1 4>;
+			clocks = <&timclk0 &timclk1>;
+			clock-names = "apb_pclk";
+			status = "disabled";
+		};
+
+		timer1: timer at fc801000 {
+			compatible = "arm,sp804", "arm,primecell";
+			reg = <0xfc801000 0x1000>;
+			/* timer10 & timer11 */
+			interrupts = <0 2 4>, <0 3 4>;
+			clocks = <&timclk2 &timclk3>;
+			clock-names = "apb_pclk";
+			status = "disabled";
+		};
+
+		timer2: timer at fca01000 {
+			compatible = "arm,sp804", "arm,primecell";
+			reg = <0xfca01000 0x1000>;
+			/* timer20 & timer21 */
+			interrupts = <0 4 4>, <0 5 4>;
+			clocks = <&timclk4 &timclk5>;
+			clock-names = "apb_pclk";
+			status = "disabled";
+		};
+
+		timer3: timer at fca02000 {
+			compatible = "arm,sp804", "arm,primecell";
+			reg = <0xfca02000 0x1000>;
+			/* timer30 & timer31 */
+			interrupts = <0 6 4>, <0 7 4>;
+			clocks = <&timclk6 &timclk7>;
+			clock-names = "apb_pclk";
+			status = "disabled";
+		};
+
+		timer4: timer at fca03000 {
+			compatible = "arm,sp804", "arm,primecell";
+			reg = <0xfca03000 0x1000>;
+			/* timer40 & timer41 */
+			interrupts = <0 96 4>, <0 97 4>;
+			clocks = <&timclk8 &timclk9>;
+			clock-names = "apb_pclk";
+			status = "disabled";
+		};
+
+		uart0: uart at fcb00000 {
+			compatible = "arm,pl011", "arm,primecell";
+			reg = <0xfcb00000 0x1000>;
+			interrupts = <0 20 4>;
+			clocks = <&uartclk0>;
+			clock-names = "apb_pclk";
+			status = "disabled";
+		};
+
+		uart1: uart at fcb01000 {
+			compatible = "arm,pl011", "arm,primecell";
+			reg = <0xfcb01000 0x1000>;
+			interrupts = <0 21 4>;
+			clocks = <&uartclk1>;
+			clock-names = "apb_pclk";
+			status = "disabled";
+		};
+
+		uart2: uart at fcb02000 {
+			compatible = "arm,pl011", "arm,primecell";
+			reg = <0xfcb02000 0x1000>;
+			interrupts = <0 22 4>;
+			clocks = <&uartclk2>;
+			clock-names = "apb_pclk";
+			status = "disabled";
+		};
+
+		uart3: uart at fcb03000 {
+			compatible = "arm,pl011", "arm,primecell";
+			reg = <0xfcb03000 0x1000>;
+			interrupts = <0 23 4>;
+			clocks = <&uartclk3>;
+			clock-names = "apb_pclk";
+			status = "disabled";
+		};
+
+		uart4: uart at fcb04000 {
+			compatible = "arm,pl011", "arm,primecell";
+			reg = <0xfcb04000 0x1000>;
+			interrupts = <0 24 4>;
+			clocks = <&uartclk4>;
+			clock-names = "apb_pclk";
+			status = "disabled";
+		};
+
+		gpio0: gpio at fc806000 {
+			compatible = "arm,pl061", "arm,primecell";
+			reg = <0xfc806000 0x1000>;
+			interrupts = <0 64 0x4>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			gpio-ranges = <	&pmx0 2 0 1 &pmx0 3 0 1 &pmx0 4 0 1
+					&pmx0 5 0 1 &pmx0 6 1 1 &pmx0 7 2 1>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			clocks = <&gpioclk0>;
+			clock-names = "apb_pclk";
+			status = "disable";
+		};
+
+		gpio1: gpio at fc807000 {
+			compatible = "arm,pl061", "arm,primecell";
+			reg = <0xfc807000 0x1000>;
+			interrupts = <0 65 0x4>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			gpio-ranges = <	&pmx0 0 3 1 &pmx0 1 3 1 &pmx0 2 3 1
+					&pmx0 3 3 1 &pmx0 4 3 1 &pmx0 5 4 1
+					&pmx0 6 5 1 &pmx0 7 6 1>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			clocks = <&gpioclk1>;
+			clock-names = "apb_pclk";
+			status = "disable";
+		};
+
+		gpio2: gpio at fc808000 {
+			compatible = "arm,pl061", "arm,primecell";
+			reg = <0xfc808000 0x1000>;
+			interrupts = <0 66 0x4>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			gpio-ranges = <	&pmx0 0 7 1 &pmx0 1 8 1 &pmx0 2 9 1
+					&pmx0 3 10 1 &pmx0 4 3 1 &pmx0 5 3 1
+					&pmx0 6 3 1 &pmx0 7 3 1>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			clocks = <&gpioclk2>;
+			clock-names = "apb_pclk";
+			status = "disable";
+		};
+
+		gpio3: gpio at fc809000 {
+			compatible = "arm,pl061", "arm,primecell";
+			reg = <0xfc809000 0x1000>;
+			interrupts = <0 67 0x4>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			gpio-ranges = <	&pmx0 0 3 1 &pmx0 1 3 1 &pmx0 2 3 1
+					&pmx0 3 3 1 &pmx0 4 11 1 &pmx0 5 11 1
+					&pmx0 6 11 1 &pmx0 7 11 1>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			clocks = <&gpioclk3>;
+			clock-names = "apb_pclk";
+			status = "disable";
+		};
+
+		gpio4: gpio at fc80a000 {
+			compatible = "arm,pl061", "arm,primecell";
+			reg = <0xfc80a000 0x1000>;
+			interrupts = <0 68 0x4>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			gpio-ranges = <	&pmx0 0 11 1 &pmx0 1 11 1 &pmx0 2 11 1
+					&pmx0 3 11 1 &pmx0 4 12 1 &pmx0 5 12 1
+					&pmx0 6 13 1 &pmx0 7 13 1>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			clocks = <&gpioclk4>;
+			clock-names = "apb_pclk";
+			status = "disable";
+		};
+
+		gpio5: gpio at fc80b000 {
+			compatible = "arm,pl061", "arm,primecell";
+			reg = <0xfc80b000 0x1000>;
+			interrupts = <0 69 0x4>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			gpio-ranges = <	&pmx0 0 14 1 &pmx0 1 15 1 &pmx0 2 16 1
+					&pmx0 3 16 1 &pmx0 4 16 1 &pmx0 5 16 1
+					&pmx0 6 16 1 &pmx0 7 16 1>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			clocks = <&gpioclk5>;
+			clock-names = "apb_pclk";
+			status = "disable";
+		};
+
+		gpio6: gpio at fc80c000 {
+			compatible = "arm,pl061", "arm,primecell";
+			reg = <0xfc80c000 0x1000>;
+			interrupts = <0 70 0x4>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			gpio-ranges = <	&pmx0 0 16 1 &pmx0 1 16 1 &pmx0 2 17 1
+					&pmx0 3 17 1 &pmx0 4 18 1 &pmx0 5 18 1
+					&pmx0 6 18 1 &pmx0 7 19 1>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			clocks = <&gpioclk6>;
+			clock-names = "apb_pclk";
+			status = "disable";
+		};
+
+		gpio7: gpio at fc80d000 {
+			compatible = "arm,pl061", "arm,primecell";
+			reg = <0xfc80d000 0x1000>;
+			interrupts = <0 71 0x4>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			gpio-ranges = <	&pmx0 0 19 1 &pmx0 1 20 1 &pmx0 2 21 1
+					&pmx0 3 22 1 &pmx0 4 23 1 &pmx0 5 24 1
+					&pmx0 6 25 1 &pmx0 7 26 1>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			clocks = <&gpioclk7>;
+			clock-names = "apb_pclk";
+			status = "disable";
+		};
+
+		gpio8: gpio at fc80e000 {
+			compatible = "arm,pl061", "arm,primecell";
+			reg = <0xfc80e000 0x1000>;
+			interrupts = <0 72 0x4>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			gpio-ranges = <	&pmx0 0 27 1 &pmx0 1 28 1 &pmx0 2 29 1
+					&pmx0 3 30 1 &pmx0 4 31 1 &pmx0 5 32 1
+					&pmx0 6 33 1 &pmx0 7 34 1>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			clocks = <&gpioclk8>;
+			clock-names = "apb_pclk";
+			status = "disable";
+		};
+
+		gpio9: gpio at fc80f000 {
+			compatible = "arm,pl061", "arm,primecell";
+			reg = <0xfc80f000 0x1000>;
+			interrupts = <0 73 0x4>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			gpio-ranges = <	&pmx0 0 35 1 &pmx0 1 36 1 &pmx0 2 37 1
+					&pmx0 3 38 1 &pmx0 4 39 1 &pmx0 5 40 1
+					&pmx0 6 41 1>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			clocks = <&gpioclk9>;
+			clock-names = "apb_pclk";
+			status = "disable";
+		};
+
+		gpio10: gpio at fc810000 {
+			compatible = "arm,pl061", "arm,primecell";
+			reg = <0xfc810000 0x1000>;
+			interrupts = <0 74 0x4>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			gpio-ranges = <	&pmx0 2 43 1 &pmx0 3 44 1 &pmx0 4 45 1
+					&pmx0 5 45 1 &pmx0 6 46 1 &pmx0 7 46 1>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			clocks = <&gpioclk10>;
+			clock-names = "apb_pclk";
+			status = "disable";
+		};
+
+		gpio11: gpio at fc811000 {
+			compatible = "arm,pl061", "arm,primecell";
+			reg = <0xfc811000 0x1000>;
+			interrupts = <0 75 0x4>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			gpio-ranges = <	&pmx0 0 47 1 &pmx0 1 47 1 &pmx0 2 47 1
+					&pmx0 3 47 1 &pmx0 4 47 1 &pmx0 5 48 1
+					&pmx0 6 49 1 &pmx0 7 49 1>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			clocks = <&gpioclk11>;
+			clock-names = "apb_pclk";
+			status = "disable";
+		};
+
+		gpio12: gpio at fc812000 {
+			compatible = "arm,pl061", "arm,primecell";
+			reg = <0xfc812000 0x1000>;
+			interrupts = <0 76 0x4>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			gpio-ranges = <	&pmx0 0 49 1 &pmx0 1 50 1 &pmx0 2 49 1
+					&pmx0 3 49 1 &pmx0 4 51 1 &pmx0 5 51 1
+					&pmx0 6 51 1 &pmx0 7 52 1>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			clocks = <&gpioclk12>;
+			clock-names = "apb_pclk";
+			status = "disable";
+		};
+
+		gpio13: gpio at fc813000 {
+			compatible = "arm,pl061", "arm,primecell";
+			reg = <0xfc813000 0x1000>;
+			interrupts = <0 77 0x4>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			gpio-ranges = <	&pmx0 0 51 1 &pmx0 1 51 1 &pmx0 2 53 1
+					&pmx0 3 53 1 &pmx0 4 53 1 &pmx0 5 54 1
+					&pmx0 6 55 1 &pmx0 7 56 1>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			clocks = <&gpioclk13>;
+			clock-names = "apb_pclk";
+			status = "disable";
+		};
+
+		gpio14: gpio at fc814000 {
+			compatible = "arm,pl061", "arm,primecell";
+			reg = <0xfc814000 0x1000>;
+			interrupts = <0 78 0x4>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			gpio-ranges = <	&pmx0 0 57 1 &pmx0 1 97 1 &pmx0 2 97 1
+					&pmx0 3 58 1 &pmx0 4 59 1 &pmx0 5 60 1
+					&pmx0 6 60 1 &pmx0 7 61 1>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			clocks = <&gpioclk14>;
+			clock-names = "apb_pclk";
+			status = "disable";
+		};
+
+		gpio15: gpio at fc815000 {
+			compatible = "arm,pl061", "arm,primecell";
+			reg = <0xfc815000 0x1000>;
+			interrupts = <0 79 0x4>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			gpio-ranges = <	&pmx0 0 61 1 &pmx0 1 62 1 &pmx0 2 62 1
+					&pmx0 3 63 1 &pmx0 4 63 1 &pmx0 5 64 1
+					&pmx0 6 64 1 &pmx0 7 65 1>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			clocks = <&gpioclk15>;
+			clock-names = "apb_pclk";
+			status = "disable";
+		};
+
+		gpio16: gpio at fc816000 {
+			compatible = "arm,pl061", "arm,primecell";
+			reg = <0xfc816000 0x1000>;
+			interrupts = <0 80 0x4>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			gpio-ranges = <	&pmx0 0 66 1 &pmx0 1 67 1 &pmx0 2 68 1
+					&pmx0 3 69 1 &pmx0 4 70 1 &pmx0 5 71 1
+					&pmx0 6 72 1 &pmx0 7 73 1>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			clocks = <&gpioclk16>;
+			clock-names = "apb_pclk";
+			status = "disable";
+		};
+
+		gpio17: gpio at fc817000 {
+			compatible = "arm,pl061", "arm,primecell";
+			reg = <0xfc817000 0x1000>;
+			interrupts = <0 81 0x4>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			gpio-ranges = <	&pmx0 0 74 1 &pmx0 1 75 1 &pmx0 2 76 1
+					&pmx0 3 77 1 &pmx0 4 78 1 &pmx0 5 79 1
+					&pmx0 6 80 1 &pmx0 7 81 1>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			clocks = <&gpioclk17>;
+			clock-names = "apb_pclk";
+			status = "disable";
+		};
+
+		gpio18: gpio at fc818000 {
+			compatible = "arm,pl061", "arm,primecell";
+			reg = <0xfc818000 0x1000>;
+			interrupts = <0 82 0x4>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			gpio-ranges = <	&pmx0 0 82 1 &pmx0 1 83 1 &pmx0 2 83 1
+					&pmx0 3 84 1 &pmx0 4 84 1 &pmx0 5 85 1
+					&pmx0 6 86 1 &pmx0 7 87 1>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			clocks = <&gpioclk18>;
+			clock-names = "apb_pclk";
+			status = "disable";
+		};
+
+		gpio19: gpio at fc819000 {
+			compatible = "arm,pl061", "arm,primecell";
+			reg = <0xfc819000 0x1000>;
+			interrupts = <0 83 0x4>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			gpio-ranges = <	&pmx0 0 87 1 &pmx0 1 87 1 &pmx0 2 88 1
+					&pmx0 3 88 1>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			clocks = <&gpioclk19>;
+			clock-names = "apb_pclk";
+			status = "disable";
+		};
+
+		gpio20: gpio at fc81a000 {
+			compatible = "arm,pl061", "arm,primecell";
+			reg = <0xfc81a000 0x1000>;
+			interrupts = <0 84 0x4>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			gpio-ranges = <	&pmx0 0 89 1 &pmx0 1 89 1 &pmx0 2 90 1
+					&pmx0 3 90 1 &pmx0 4 91 1 &pmx0 5 92 1>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			clocks = <&gpioclk20>;
+			clock-names = "apb_pclk";
+			status = "disable";
+		};
+
+		gpio21: gpio at fc81b000 {
+			compatible = "arm,pl061", "arm,primecell";
+			reg = <0xfc81b000 0x1000>;
+			interrupts = <0 85 0x4>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			gpio-ranges = <	&pmx0 3 94 1 &pmx0 7 96 1>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			clocks = <&gpioclk21>;
+			clock-names = "apb_pclk";
+			status = "disable";
+		};
+
+		pmx0: pinmux at fc803000 {
+			compatible = "pinctrl-single";
+			reg = <0xfc803000 0x188>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			#gpio-range-cells = <3>;
+			ranges;
+
+			pinctrl-single,register-width = <32>;
+			pinctrl-single,function-mask = <7>;
+			/* pin base, nr pins & gpio function */
+			pinctrl-single,gpio-range = <&range 0 3 0 &range 3 9 1
+						&range 12 1 0 &range 13 29 1
+						&range 43 1 0 &range 44 49 1
+						&range 94 1 1 &range 96 2 1>;
+
+			range: gpio-range {
+				#pinctrl-single,gpio-range-cells = <3>;
+			};
+		};
+
+		pmx1: pinmux at fc803800 {
+			compatible = "pinconf-single";
+			reg = <0xfc803800 0x2dc>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			ranges;
+
+			pinctrl-single,register-width = <32>;
+		};
+	};
+};
diff --git a/arch/arm/boot/dts/hi4511.dts b/arch/arm/boot/dts/hi4511.dts
new file mode 100644
index 0000000..861a98a
--- /dev/null
+++ b/arch/arm/boot/dts/hi4511.dts
@@ -0,0 +1,738 @@
+/*
+ *  Copyright (C) 2012-2013 Linaro Ltd.
+ *  Author: Haojian Zhuang <haojian.zhuang at linaro.org>
+ *
+ *  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
+ *  publishhed by the Free Software Foundation.
+ */
+
+/dts-v1/;
+/include/ "hi3620.dtsi"
+
+/ {
+	model = "Hisilicon Hi4511 Development Board";
+	compatible = "hisilicon,hi3620-hi4511";
+
+	chosen {
+		bootargs = "console=ttyAMA0,115200 root=/dev/nfs nfsroot=192.168.1.100:/nfsroot/ ip=192.168.1.101:192.168.1.100::255.255.255.0::eth0:on mem=512m earlyprintk";
+	};
+
+	memory {
+		reg = <0x00000000 0x20000000>;
+	};
+
+	amba {
+		timer0: timer at fc800000 {
+			status = "ok";
+		};
+
+		uart0: uart at fcb00000 {	/* console */
+/*
+			pinctrl-names = "default", "idle";
+			pinctrl-0 = <&uart0_pmx_func &uart0_cfg_func>;
+			pinctrl-1 = <&uart0_pmx_idle &uart0_cfg_idle>;
+*/
+			status = "ok";
+		};
+
+		uart1: uart at fcb01000 { /* modem */
+			pinctrl-names = "default", "idle";
+			pinctrl-0 = <&uart1_pmx_func &uart1_cfg_func>;
+			pinctrl-1 = <&uart1_pmx_idle &uart1_cfg_idle>;
+			status = "ok";
+		};
+
+		uart2: uart at fcb02000 { /* audience */
+			pinctrl-names = "default", "idle";
+			pinctrl-0 = <&uart2_pmx_func &uart2_cfg_func>;
+			pinctrl-1 = <&uart2_pmx_idle &uart2_cfg_idle>;
+			status = "ok";
+		};
+
+		uart3: uart at fcb03000 {
+			pinctrl-names = "default", "idle";
+			pinctrl-0 = <&uart3_pmx_func &uart3_cfg_func>;
+			pinctrl-1 = <&uart3_pmx_idle &uart3_cfg_idle>;
+			status = "ok";
+		};
+
+		uart4: uart at fcb04000 {
+			pinctrl-names = "default", "idle";
+			pinctrl-0 = <&uart4_pmx_func &uart4_cfg_func>;
+			pinctrl-1 = <&uart4_pmx_idle &uart4_cfg_func>;
+			status = "ok";
+		};
+
+		gpio0: gpio at fc806000 {
+			status = "ok";
+		};
+
+		gpio1: gpio at fc807000 {
+			status = "ok";
+		};
+
+		gpio2: gpio at fc808000 {
+			status = "ok";
+		};
+
+		gpio3: gpio at fc809000 {
+			status = "ok";
+		};
+
+		gpio4: gpio at fc80a000 {
+			status = "ok";
+		};
+
+		gpio5: gpio at fc80b000 {
+			status = "ok";
+		};
+
+		gpio6: gpio at fc80c000 {
+			status = "ok";
+		};
+
+		gpio7: gpio at fc80d000 {
+			status = "ok";
+		};
+
+		gpio8: gpio at fc80e000 {
+			status = "ok";
+		};
+
+		gpio9: gpio at fc80f000 {
+			status = "ok";
+		};
+
+		gpio10: gpio at fc810000 {
+			status = "ok";
+		};
+
+		gpio11: gpio at fc811000 {
+			status = "ok";
+		};
+
+		gpio12: gpio at fc812000 {
+			status = "ok";
+		};
+
+		gpio13: gpio at fc813000 {
+			status = "ok";
+		};
+
+		gpio14: gpio at fc814000 {
+			status = "ok";
+		};
+
+		gpio15: gpio at fc815000 {
+			status = "ok";
+		};
+
+		gpio16: gpio at fc816000 {
+			status = "ok";
+		};
+
+		gpio17: gpio at fc817000 {
+			status = "ok";
+		};
+
+		gpio18: gpio at fc818000 {
+			status = "ok";
+		};
+
+		gpio19: gpio at fc819000 {
+			status = "ok";
+		};
+
+		gpio20: gpio at fc81a000 {
+			status = "ok";
+		};
+
+		gpio21: gpio at fc81b000 {
+			status = "ok";
+		};
+
+		gpio-keys {
+			compatible = "gpio-keys";
+
+			call {
+				label = "call";
+				gpios = <&gpio17 2 0>;
+				linux,code = <169>;	/* KEY_PHONE */
+			};
+		};
+
+		pmx0: pinmux at fc803000 {
+			pinctrl-names = "default";
+			pinctrl-0 = <&i2c0_pmx_func>;
+
+			board_pmx_pins: board_pmx_pins {
+				pinctrl-single,pins = <
+					0x008 0x0	/* GPIO -- eFUSE_DOUT */
+					0x100 0x0	/* USIM_CLK & USIM_DATA (IOMG63) */
+					0x104 0x0	/* USIM_RST (IOMG96) */
+				>;
+			};
+			uart0_pmx_func: uart0_pmx_func {
+				pinctrl-single,pins = <
+					0x0f0 0x0
+					0x0f4 0x0	/* UART0_RX & UART0_TX */
+				>;
+			};
+			uart0_pmx_idle: uart0_pmx_idle {
+				pinctrl-single,pins = <
+					/*0x0f0 0x1*/	/* UART0_CTS & UART0_RTS */
+					0x0f4 0x1	/* UART0_RX & UART0_TX */
+				>;
+			};
+			uart1_pmx_func: uart1_pmx_func {
+				pinctrl-single,pins = <
+					0x0f8 0x0	/* UART1_CTS & UART1_RTS (IOMG61) */
+					0x0fc 0x0	/* UART1_RX & UART1_TX (IOMG62) */
+				>;
+			};
+			uart1_pmx_idle: uart1_pmx_idle {
+				pinctrl-single,pins = <
+					0x0f8 0x1	/* GPIO (IOMG61) */
+					0x0fc 0x1	/* GPIO (IOMG62) */
+				>;
+			};
+			uart2_pmx_func: uart2_pmx_func {
+				pinctrl-single,pins = <
+					0x104 0x2	/* UART2_RXD (IOMG96) */
+					0x108 0x2	/* UART2_TXD (IOMG64) */
+				>;
+			};
+			uart2_pmx_idle: uart2_pmx_idle {
+				pinctrl-single,pins = <
+					0x104 0x1	/* GPIO (IOMG96) */
+					0x108 0x1	/* GPIO (IOMG64) */
+				>;
+			};
+			uart3_pmx_func: uart3_pmx_func {
+				pinctrl-single,pins = <
+					0x160 0x2	/* UART3_CTS & UART3_RTS (IOMG85) */
+					0x164 0x2	/* UART3_RXD & UART3_TXD (IOMG86) */
+				>;
+			};
+			uart3_pmx_idle: uart3_pmx_idle {
+				pinctrl-single,pins = <
+					0x160 0x1	/* GPIO (IOMG85) */
+					0x164 0x1	/* GPIO (IOMG86) */
+				>;
+			};
+			uart4_pmx_func: uart4_pmx_func {
+				pinctrl-single,pins = <
+					0x168 0x0	/* UART4_CTS & UART4_RTS (IOMG87) */
+					0x16c 0x0	/* UART4_RXD (IOMG88) */
+					0x170 0x0	/* UART4_TXD (IOMG93) */
+				>;
+			};
+			uart4_pmx_idle: uart4_pmx_idle {
+				pinctrl-single,pins = <
+					0x168 0x1	/* GPIO (IOMG87) */
+					0x16c 0x1	/* GPIO (IOMG88) */
+					0x170 0x1	/* GPIO (IOMG93) */
+				>;
+			};
+			i2c0_pmx_func: i2c0_pmx_func {
+				pinctrl-single,pins = <
+					0x0b4 0x0	/* I2C0_SCL & I2C0_SDA (IOMG45) */
+				>;
+			};
+			i2c0_pmx_idle: i2c0_pmx_idle {
+				pinctrl-single,pins = <
+					0x0b4 0x1	/* GPIO (IOMG45) */
+				>;
+			};
+			i2c1_pmx_func: i2c1_pmx_func {
+				pinctrl-single,pins = <
+					0x0b8 0x0	/* I2C1_SCL & I2C1_SDA (IOMG46) */
+				>;
+			};
+			i2c1_pmx_idle: i2c1_pmx_idle {
+				pinctrl-single,pins = <
+					0x0b8 0x1	/* GPIO (IOMG46) */
+				>;
+			};
+			i2c2_pmx_func: i2c2_pmx_func {
+				pinctrl-single,pins = <
+					0x068 0x0	/* I2C2_SCL (IOMG26) */
+					0x06c 0x0	/* I2C2_SDA (IOMG27) */
+				>;
+			};
+			i2c2_pmx_idle: i2c2_pmx_idle {
+				pinctrl-single,pins = <
+					0x068 0x1	/* GPIO (IOMG26) */
+					0x06c 0x1	/* GPIO (IOMG27) */
+				>;
+			};
+			i2c3_pmx_func: i2c3_pmx_func {
+				pinctrl-single,pins = <
+					0x050 0x2	/* I2C3_SCL (IOMG20) */
+					0x054 0x2	/* I2C3_SDA (IOMG21) */
+				>;
+			};
+			i2c3_pmx_idle: i2c3_pmx_idle {
+				pinctrl-single,pins = <
+					0x050 0x1	/* GPIO (IOMG20) */
+					0x054 0x1	/* GPIO (IOMG21) */
+				>;
+			};
+			spi0_pmx_func: spi0_pmx_func {
+				pinctrl-single,pins = <
+					0x0d4 0x0	/* SPI0_CLK/SPI0_DI/SPI0_DO (IOMG53) */
+					0x0d8 0x0	/* SPI0_CS0 (IOMG54) */
+					0x0dc 0x0	/* SPI0_CS1 (IOMG55) */
+					0x0e0 0x0	/* SPI0_CS2 (IOMG56) */
+					0x0e4 0x0	/* SPI0_CS3 (IOMG57) */
+				>;
+			};
+			spi0_pmx_idle: spi0_pmx_idle {
+				pinctrl-single,pins = <
+					0x0d4 0x1	/* GPIO (IOMG53) */
+					0x0d8 0x1	/* GPIO (IOMG54) */
+					0x0dc 0x1	/* GPIO (IOMG55) */
+					0x0e0 0x1	/* GPIO (IOMG56) */
+					0x0e4 0x1	/* GPIO (IOMG57) */
+				>;
+			};
+			spi1_pmx_func: spi1_pmx_func {
+				pinctrl-single,pins = <
+					0x184 0x0	/* SPI1_CLK/SPI1_DI (IOMG98) */
+					0x0e8 0x0	/* SPI1_DO (IOMG58) */
+					0x0ec 0x0	/* SPI1_CS (IOMG95) */
+				>;
+			};
+			spi1_pmx_idle: spi1_pmx_idle {
+				pinctrl-single,pins = <
+					0x184 0x1	/* GPIO (IOMG98) */
+					0x0e8 0x1	/* GPIO (IOMG58) */
+					0x0ec 0x1	/* GPIO (IOMG95) */
+				>;
+			};
+			kpc_pmx_func: kpc_pmx_func {
+				pinctrl-single,pins = <
+					0x12c 0x0	/* KEY_IN0 (IOMG73) */
+					0x130 0x0	/* KEY_IN1 (IOMG74) */
+					0x134 0x0	/* KEY_IN2 (IOMG75) */
+					0x10c 0x0	/* KEY_OUT0 (IOMG65) */
+					0x110 0x0	/* KEY_OUT1 (IOMG66) */
+					0x114 0x0	/* KEY_OUT2 (IOMG67) */
+				>;
+			};
+			kpc_pmx_idle: kpc_pmx_idle {
+				pinctrl-single,pins = <
+					0x12c 0x1	/* GPIO (IOMG73) */
+					0x130 0x1	/* GPIO (IOMG74) */
+					0x134 0x1	/* GPIO (IOMG75) */
+					0x10c 0x1	/* GPIO (IOMG65) */
+					0x110 0x1	/* GPIO (IOMG66) */
+					0x114 0x1	/* GPIO (IOMG67) */
+				>;
+			};
+			gpio_key_func: gpio_key_func {
+				pinctrl-single,pins = <
+					0x10c 0x1	/* KEY_OUT0/GPIO (IOMG65) */
+					0x130 0x1	/* KEY_IN1/GPIO (IOMG74) */
+				>;
+			};
+			emmc_pmx_func: emmc_pmx_func {
+				pinctrl-single,pins = <
+					0x030 0x2	/* eMMC_CMD/eMMC_CLK (IOMG12) */
+					0x018 0x0	/* NAND_CS3_N (IOMG6) */
+					0x024 0x0	/* NAND_BUSY2_N (IOMG8) */
+					0x028 0x0	/* NAND_BUSY3_N (IOMG9) */
+					0x02c 0x2	/* eMMC_DATA[0:7] (IOMG10) */
+				>;
+			};
+			emmc_pmx_idle: emmc_pmx_idle {
+				pinctrl-single,pins = <
+					0x030 0x0	/* GPIO (IOMG12) */
+					0x018 0x1	/* GPIO (IOMG6) */
+					0x024 0x1	/* GPIO (IOMG8) */
+					0x028 0x1	/* GPIO (IOMG9) */
+					0x02c 0x1	/* GPIO (IOMG10) */
+				>;
+			};
+			sd_pmx_func: sd_pmx_func {
+				pinctrl-single,pins = <
+					0x0bc 0x0	/* SD_CLK/SD_CMD/SD_DATA0/SD_DATA1/SD_DATA2 (IOMG47) */
+					0x0c0 0x0	/* SD_DATA3 (IOMG48) */
+				>;
+			};
+			sd_pmx_idle: sd_pmx_idle {
+				pinctrl-single,pins = <
+					0x0bc 0x1	/* GPIO (IOMG47) */
+					0x0c0 0x1	/* GPIO (IOMG48) */
+				>;
+			};
+			nand_pmx_func: nand_pmx_func {
+				pinctrl-single,pins = <
+					0x00c 0x0	/* NAND_ALE/NAND_CLE/.../NAND_DATA[0:7] (IOMG3) */
+					0x010 0x0	/* NAND_CS1_N (IOMG4) */
+					0x014 0x0	/* NAND_CS2_N (IOMG5) */
+					0x018 0x0	/* NAND_CS3_N (IOMG6) */
+					0x01c 0x0	/* NAND_BUSY0_N (IOMG94) */
+					0x020 0x0	/* NAND_BUSY1_N (IOMG7) */
+					0x024 0x0	/* NAND_BUSY2_N (IOMG8) */
+					0x028 0x0	/* NAND_BUSY3_N (IOMG9) */
+					0x02c 0x0	/* NAND_DATA[8:15] (IOMG10) */
+				>;
+			};
+			nand_pmx_idle: nand_pmx_idle {
+				pinctrl-single,pins = <
+					0x00c 0x1	/* GPIO (IOMG3) */
+					0x010 0x1	/* GPIO (IOMG4) */
+					0x014 0x1	/* GPIO (IOMG5) */
+					0x018 0x1	/* GPIO (IOMG6) */
+					0x01c 0x1	/* GPIO (IOMG94) */
+					0x020 0x1	/* GPIO (IOMG7) */
+					0x024 0x1	/* GPIO (IOMG8) */
+					0x028 0x1	/* GPIO (IOMG9) */
+					0x02c 0x1	/* GPIO (IOMG10) */
+				>;
+			};
+			sdio_pmx_func: sdio_pmx_func {
+				pinctrl-single,pins = <
+					0x0c4 0x0	/* SDIO_CLK/SDIO_CMD/SDIO_DATA[0:3] (IOMG49) */
+				>;
+			};
+			sdio_pmx_idle: sdio_pmx_idle {
+				pinctrl-single,pins = <
+					0x0c4 0x1	/* GPIO (IOMG49) */
+				>;
+			};
+			audio_out_pmx_func: audio_out_pmx_func {
+				pinctrl-single,pins = <
+					0x0f0 0x1	/* GPIO (IOMG59), audio spk & earphone */
+				>;
+			};
+		};
+
+		pmx1: pinmux at fc803800 {
+			pinctrl-names = "default";
+			pinctrl-0 = <	&board_pu_pins &board_pd_pins &board_pd_ps_pins
+					&board_np_pins &board_ps_pins &kpc_cfg_func
+					&audio_out_cfg_func>;
+			board_pu_pins: board_pu_pins {
+				pinctrl-single,pins = <
+					0x014 0		/* GPIO_158 (IOCFG2) */
+					0x018 0		/* GPIO_159 (IOCFG3) */
+					0x01c 0		/* BOOT_MODE0 (IOCFG4) */
+					0x020 0		/* BOOT_MODE1 (IOCFG5) */
+				>;
+				pinctrl-single,bias-pulldown = <0 2 0 2>;
+				pinctrl-single,bias-pullup = <1 1 0 1>;
+			};
+			board_pd_pins: board_pd_pins {
+				pinctrl-single,pins = <
+					0x038 0		/* eFUSE_DOUT (IOCFG11) */
+					0x150 0		/* ISP_GPIO8 (IOCFG93) */
+					0x154 0		/* ISP_GPIO9 (IOCFG94) */
+				>;
+				pinctrl-single,bias-pulldown = <2 2 0 2>;
+				pinctrl-single,bias-pullup = <0 1 0 1>;
+			};
+			board_pd_ps_pins: board_pd_ps_pins {
+				pinctrl-single,pins = <
+					0x2d8 0		/* CLK_OUT0 (IOCFG190) */
+					0x004 0		/* PMU_SPI_DATA (IOCFG192) */
+				>;
+				pinctrl-single,bias-pulldown = <2 2 0 2>;
+				pinctrl-single,bias-pullup = <0 1 0 1>;
+				pinctrl-single,drive-strength = <0x30 0xf0>;
+			};
+			board_np_pins: board_np_pins {
+				pinctrl-single,pins = <
+					0x24c 0		/* KEYPAD_OUT7 (IOCFG155) */
+				>;
+				pinctrl-single,bias-pulldown = <0 2 0 2>;
+				pinctrl-single,bias-pullup = <0 1 0 1>;
+			};
+			board_ps_pins: board_ps_pins {
+				pinctrl-single,pins = <
+					0x000 0		/* PMU_SPI_CLK (IOCFG191) */
+					0x008 0		/* PMU_SPI_CS_N (IOCFG193) */
+				>;
+				pinctrl-single,drive-strength = <0x30 0xf0>;
+			};
+			uart0_cfg_func: uart0_cfg_func {
+				pinctrl-single,pins = <
+					0x208 0		/* UART0_RXD (IOCFG138) */
+					0x20c 0		/* UART0_TXD (IOCFG139) */
+				>;
+				pinctrl-single,bias-pulldown = <0 2 0 2>;
+				pinctrl-single,bias-pullup = <0 1 0 1>;
+			};
+			uart0_cfg_idle: uart0_cfg_idle {
+				pinctrl-single,pins = <
+					0x208 0		/* UART0_RXD (IOCFG138) */
+					0x20c 0		/* UART0_TXD (IOCFG139) */
+				>;
+				pinctrl-single,bias-pulldown = <2 2 0 2>;
+				pinctrl-single,bias-pullup = <0 1 0 1>;
+			};
+			uart1_cfg_func: uart1_cfg_func {
+				pinctrl-single,pins = <
+					0x210 0		/* UART1_CTS (IOCFG140) */
+					0x214 0		/* UART1_RTS (IOCFG141) */
+					0x218 0		/* UART1_RXD (IOCFG142) */
+					0x21c 0		/* UART1_TXD (IOCFG143) */
+				>;
+				pinctrl-single,bias-pulldown = <0 2 0 2>;
+				pinctrl-single,bias-pullup = <0 1 0 1>;
+			};
+			uart1_cfg_idle: uart1_cfg_idle {
+				pinctrl-single,pins = <
+					0x210 0		/* UART1_CTS (IOCFG140) */
+					0x214 0		/* UART1_RTS (IOCFG141) */
+					0x218 0		/* UART1_RXD (IOCFG142) */
+					0x21c 0		/* UART1_TXD (IOCFG143) */
+				>;
+				pinctrl-single,bias-pulldown = <2 2 0 2>;
+				pinctrl-single,bias-pullup = <0 1 0 1>;
+			};
+			uart2_cfg_func: uart2_cfg_func {
+				pinctrl-single,pins = <
+					0x220 0		/* UART2_CTS (IOCFG144) */
+					0x224 0		/* UART2_RTS (IOCFG145) */
+					0x228 0		/* UART2_RXD (IOCFG146) */
+					0x22c 0		/* UART2_TXD (IOCFG147) */
+				>;
+				pinctrl-single,bias-pulldown = <0 2 0 2>;
+				pinctrl-single,bias-pullup = <0 1 0 1>;
+			};
+			uart2_cfg_idle: uart2_cfg_idle {
+				pinctrl-single,pins = <
+					0x220 0		/* GPIO (IOCFG144) */
+					0x224 0		/* GPIO (IOCFG145) */
+					0x228 0		/* GPIO (IOCFG146) */
+					0x22c 0		/* GPIO (IOCFG147) */
+				>;
+				pinctrl-single,bias-pulldown = <2 2 0 2>;
+				pinctrl-single,bias-pullup = <0 1 0 1>;
+			};
+			uart3_cfg_func: uart3_cfg_func {
+				pinctrl-single,pins = <
+					0x294 0		/* UART3_CTS (IOCFG173) */
+					0x298 0		/* UART3_RTS (IOCFG174) */
+					0x29c 0		/* UART3_RXD (IOCFG175) */
+					0x2a0 0		/* UART3_TXD (IOCFG176) */
+				>;
+				pinctrl-single,bias-pulldown = <0 2 0 2>;
+				pinctrl-single,bias-pullup = <0 1 0 1>;
+			};
+			uart3_cfg_idle: uart3_cfg_idle {
+				pinctrl-single,pins = <
+					0x294 0		/* UART3_CTS (IOCFG173) */
+					0x298 0		/* UART3_RTS (IOCFG174) */
+					0x29c 0		/* UART3_RXD (IOCFG175) */
+					0x2a0 0		/* UART3_TXD (IOCFG176) */
+				>;
+				pinctrl-single,bias-pulldown = <2 2 0 2>;
+				pinctrl-single,bias-pullup = <0 1 0 1>;
+			};
+			uart4_cfg_func: uart4_cfg_func {
+				pinctrl-single,pins = <
+					0x2a4 0		/* UART4_CTS (IOCFG177) */
+					0x2a8 0		/* UART4_RTS (IOCFG178) */
+					0x2ac 0		/* UART4_RXD (IOCFG179) */
+					0x2b0 0		/* UART4_TXD (IOCFG180) */
+				>;
+				pinctrl-single,bias-pulldown = <0 2 0 2>;
+				pinctrl-single,bias-pullup = <0 1 0 1>;
+			};
+			i2c0_cfg_func: i2c0_cfg_func {
+				pinctrl-single,pins = <
+					0x17c 0		/* I2C0_SCL (IOCFG103) */
+					0x180 0		/* I2C0_SDA (IOCFG104) */
+				>;
+				pinctrl-single,bias-pulldown = <0 2 0 2>;
+				pinctrl-single,bias-pullup = <0 1 0 1>;
+				pinctrl-single,drive-strength = <0x30 0xf0>;
+			};
+			i2c1_cfg_func: i2c1_cfg_func {
+				pinctrl-single,pins = <
+					0x184 0		/* I2C1_SCL (IOCFG105) */
+					0x188 0		/* I2C1_SDA (IOCFG106) */
+				>;
+				pinctrl-single,bias-pulldown = <0 2 0 2>;
+				pinctrl-single,bias-pullup = <0 1 0 1>;
+				pinctrl-single,drive-strength = <0x30 0xf0>;
+			};
+			i2c2_cfg_func: i2c2_cfg_func {
+				pinctrl-single,pins = <
+					0x118 0		/* I2C2_SCL (IOCFG79) */
+					0x11c 0		/* I2C2_SDA (IOCFG80) */
+				>;
+				pinctrl-single,bias-pulldown = <0 2 0 2>;
+				pinctrl-single,bias-pullup = <0 1 0 1>;
+				pinctrl-single,drive-strength = <0x30 0xf0>;
+			};
+			i2c3_cfg_func: i2c3_cfg_func {
+				pinctrl-single,pins = <
+					0x100 0		/* I2C3_SCL (IOCFG73) */
+					0x104 0		/* I2C3_SDA (IOCFG74) */
+				>;
+				pinctrl-single,bias-pulldown = <0 2 0 2>;
+				pinctrl-single,bias-pullup = <0 1 0 1>;
+				pinctrl-single,drive-strength = <0x30 0xf0>;
+			};
+			spi0_cfg_func1: spi0_cfg_func1 {
+				pinctrl-single,pins = <
+					0x1d4 0		/* SPI0_CLK (IOCFG125) */
+					0x1d8 0		/* SPI0_DI (IOCFG126) */
+					0x1dc 0		/* SPI0_DO (IOCFG127) */
+				>;
+				pinctrl-single,bias-pulldown = <2 2 0 2>;
+				pinctrl-single,bias-pullup = <0 1 0 1>;
+				pinctrl-single,drive-strength = <0x30 0xf0>;
+			};
+			spi0_cfg_func2: spi0_cfg_func2 {
+				pinctrl-single,pins = <
+					0x1e0 0		/* SPI0_CS0 (IOCFG128) */
+					0x1e4 0		/* SPI0_CS1 (IOCFG129) */
+					0x1e8 0		/* SPI0_CS2 (IOCFG130 */
+					0x1ec 0		/* SPI0_CS3 (IOCFG131) */
+				>;
+				pinctrl-single,bias-pulldown = <0 2 0 2>;
+				pinctrl-single,bias-pullup = <1 1 0 1>;
+				pinctrl-single,drive-strength = <0x30 0xf0>;
+			};
+			spi1_cfg_func1: spi1_cfg_func1 {
+				pinctrl-single,pins = <
+					0x1f0 0		/* SPI1_CLK (IOCFG132) */
+					0x1f4 0		/* SPI1_DI (IOCFG133) */
+					0x1f8 0		/* SPI1_DO (IOCFG134) */
+				>;
+				pinctrl-single,bias-pulldown = <2 2 0 2>;
+				pinctrl-single,bias-pullup = <0 1 0 1>;
+				pinctrl-single,drive-strength = <0x30 0xf0>;
+			};
+			spi1_cfg_func2: spi1_cfg_func2 {
+				pinctrl-single,pins = <
+					0x1fc 0		/* SPI1_CS (IOCFG135) */
+				>;
+				pinctrl-single,bias-pulldown = <0 2 0 2>;
+				pinctrl-single,bias-pullup = <1 1 0 1>;
+				pinctrl-single,drive-strength = <0x30 0xf0>;
+			};
+			kpc_cfg_func: kpc_cfg_func {
+				pinctrl-single,pins = <
+					0x250 0		/* KEY_IN0 (IOCFG156) */
+					0x254 0		/* KEY_IN1 (IOCFG157) */
+					0x258 0		/* KEY_IN2 (IOCFG158) */
+					0x230 0		/* KEY_OUT0 (IOCFG148) */
+					0x234 0		/* KEY_OUT1 (IOCFG149) */
+					0x238 0		/* KEY_OUT2 (IOCFG150) */
+				>;
+				pinctrl-single,bias-pulldown = <2 2 0 2>;
+				pinctrl-single,bias-pullup = <0 1 0 1>;
+			};
+			emmc_cfg_func: emmc_cfg_func {
+				pinctrl-single,pins = <
+					0x0ac 0		/* eMMC_CMD (IOCFG40) */
+					0x0b0 0		/* eMMC_CLK (IOCFG41) */
+					0x058 0		/* NAND_CS3_N (IOCFG19) */
+					0x064 0		/* NAND_BUSY2_N (IOCFG22) */
+					0x068 0		/* NAND_BUSY3_N (IOCFG23) */
+					0x08c 0		/* NAND_DATA8 (IOCFG32) */
+					0x090 0		/* NAND_DATA9 (IOCFG33) */
+					0x094 0		/* NAND_DATA10 (IOCFG34) */
+					0x098 0		/* NAND_DATA11 (IOCFG35) */
+					0x09c 0		/* NAND_DATA12 (IOCFG36) */
+					0x0a0 0		/* NAND_DATA13 (IOCFG37) */
+					0x0a4 0		/* NAND_DATA14 (IOCFG38) */
+					0x0a8 0		/* NAND_DATA15 (IOCFG39) */
+				>;
+				pinctrl-single,bias-pulldown = <0 2 0 2>;
+				pinctrl-single,bias-pullup = <1 1 0 1>;
+				pinctrl-single,drive-strength = <0x30 0xf0>;
+			};
+			sd_cfg_func1: sd_cfg_func1 {
+				pinctrl-single,pins = <
+					0x18c 0		/* SD_CLK (IOCFG107) */
+					0x190 0		/* SD_CMD (IOCFG108) */
+				>;
+				pinctrl-single,bias-pulldown = <2 2 0 2>;
+				pinctrl-single,bias-pullup = <0 1 0 1>;
+				pinctrl-single,drive-strength = <0x30 0xf0>;
+			};
+			sd_cfg_func2: sd_cfg_func2 {
+				pinctrl-single,pins = <
+					0x194 0		/* SD_DATA0 (IOCFG109) */
+					0x198 0		/* SD_DATA1 (IOCFG110) */
+					0x19c 0		/* SD_DATA2 (IOCFG111) */
+					0x1a0 0		/* SD_DATA3 (IOCFG112) */
+				>;
+				pinctrl-single,bias-pulldown = <2 2 0 2>;
+				pinctrl-single,bias-pullup = <0 1 0 1>;
+				pinctrl-single,drive-strength = <0x70 0xf0>;
+			};
+			nand_cfg_func1: nand_cfg_func1 {
+				pinctrl-single,pins = <
+					0x03c 0		/* NAND_ALE (IOCFG12) */
+					0x040 0		/* NAND_CLE (IOCFG13) */
+					0x06c 0		/* NAND_DATA0 (IOCFG24) */
+					0x070 0		/* NAND_DATA1 (IOCFG25) */
+					0x074 0		/* NAND_DATA2 (IOCFG26) */
+					0x078 0		/* NAND_DATA3 (IOCFG27) */
+					0x07c 0		/* NAND_DATA4 (IOCFG28) */
+					0x080 0		/* NAND_DATA5 (IOCFG29) */
+					0x084 0		/* NAND_DATA6 (IOCFG30) */
+					0x088 0		/* NAND_DATA7 (IOCFG31) */
+					0x08c 0		/* NAND_DATA8 (IOCFG32) */
+					0x090 0		/* NAND_DATA9 (IOCFG33) */
+					0x094 0		/* NAND_DATA10 (IOCFG34) */
+					0x098 0		/* NAND_DATA11 (IOCFG35) */
+					0x09c 0		/* NAND_DATA12 (IOCFG36) */
+					0x0a0 0		/* NAND_DATA13 (IOCFG37) */
+					0x0a4 0		/* NAND_DATA14 (IOCFG38) */
+					0x0a8 0		/* NAND_DATA15 (IOCFG39) */
+				>;
+				pinctrl-single,bias-pulldown = <2 2 0 2>;
+				pinctrl-single,bias-pullup = <0 1 0 1>;
+				pinctrl-single,drive-strength = <0x30 0xf0>;
+			};
+			nand_cfg_func2: nand_cfg_func2 {
+				pinctrl-single,pins = <
+					0x044 0		/* NAND_RE_N (IOCFG14) */
+					0x048 0		/* NAND_WE_N (IOCFG15) */
+					0x04c 0		/* NAND_CS0_N (IOCFG16) */
+					0x050 0		/* NAND_CS1_N (IOCFG17) */
+					0x054 0		/* NAND_CS2_N (IOCFG18) */
+					0x058 0		/* NAND_CS3_N (IOCFG19) */
+					0x05c 0		/* NAND_BUSY0_N (IOCFG20) */
+					0x060 0		/* NAND_BUSY1_N (IOCFG21) */
+					0x064 0		/* NAND_BUSY2_N (IOCFG22) */
+					0x068 0		/* NAND_BUSY3_N (IOCFG23) */
+				>;
+				pinctrl-single,bias-pulldown = <0 2 0 2>;
+				pinctrl-single,bias-pullup = <1 1 0 1>;
+				pinctrl-single,drive-strength = <0x30 0xf0>;
+			};
+			sdio_cfg_func: sdio_cfg_func {
+				pinctrl-single,pins = <
+					0x1a4 0		/* SDIO0_CLK (IOCG113) */
+					0x1a8 0		/* SDIO0_CMD (IOCG114) */
+					0x1ac 0		/* SDIO0_DATA0 (IOCG115) */
+					0x1b0 0		/* SDIO0_DATA1 (IOCG116) */
+					0x1b4 0		/* SDIO0_DATA2 (IOCG117) */
+					0x1b8 0		/* SDIO0_DATA3 (IOCG118) */
+				>;
+				pinctrl-single,bias-pulldown = <2 2 0 2>;
+				pinctrl-single,bias-pullup = <0 1 0 1>;
+				pinctrl-single,drive-strength = <0x30 0xf0>;
+			};
+			audio_out_cfg_func: audio_out_cfg_func {
+				pinctrl-single,pins = <
+					0x200 0		/* GPIO (IOCFG136) */
+					0x204 0		/* GPIO (IOCFG137) */
+				>;
+				pinctrl-single,bias-pulldown = <2 2 0 2>;
+				pinctrl-single,bias-pullup = <0 1 0 1>;
+			};
+		};
+	};
+};
-- 
1.7.10.4



From haojian.zhuang at linaro.org  Fri Apr 19 06:49:27 2013
From: haojian.zhuang at linaro.org (Haojian Zhuang)
Date: Fri, 19 Apr 2013 18:49:27 +0800
Subject: [PATCH 5/5] ARM: config: append arch hi3xxx into multi defconfig
In-Reply-To: <1366368567-17322-1-git-send-email-haojian.zhuang@linaro.org>
References: <1366368567-17322-1-git-send-email-haojian.zhuang@linaro.org>
Message-ID: <1366368567-17322-5-git-send-email-haojian.zhuang@linaro.org>

Append ARCH_HI3xxx (Hisilicon SoC) into multi_v7_defconfig.

Signed-off-by: Haojian Zhuang <haojian.zhuang at linaro.org>
---
 arch/arm/configs/multi_v7_defconfig |    1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index e31d442..1891611 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -5,6 +5,7 @@ CONFIG_ARCH_MVEBU=y
 CONFIG_MACH_ARMADA_370=y
 CONFIG_MACH_ARMADA_XP=y
 CONFIG_ARCH_HIGHBANK=y
+CONFIG_ARCH_HI3xxx=y
 CONFIG_ARCH_SOCFPGA=y
 CONFIG_ARCH_SUNXI=y
 # CONFIG_ARCH_VEXPRESS_CORTEX_A5_A9_ERRATA is not set
-- 
1.7.10.4



From linux at arm.linux.org.uk  Fri Apr 19 06:48:10 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Fri, 19 Apr 2013 11:48:10 +0100
Subject: v7_flush_kern_cache_louis flushes up to L2?
In-Reply-To: <20130419102142.GI14496@n2100.arm.linux.org.uk>
References: <CABYn4sxUCoWhC_4qydzbCtZdQdetqFZ_u5WtXsghprQget9f5g@mail.gmail.com>
 <51655248.7000401@arm.com>
 <CABYn4swK_FB+nPO4vKZM8khp+mjaPwkAv_GF+XDg5SYz0VLf0Q@mail.gmail.com>
 <51656A89.9090600@arm.com> <20130419102142.GI14496@n2100.arm.linux.org.uk>
Message-ID: <20130419104810.GJ14496@n2100.arm.linux.org.uk>

On Fri, Apr 19, 2013 at 11:21:42AM +0100, Russell King - ARM Linux wrote:
> On Wed, Apr 10, 2013 at 02:35:05PM +0100, Jonathan Austin wrote:
> > Note that on SMP, you would also need to clean/flush again after turning  
> > off the caches, as read-speculation could have sucked dirty data from  
> > another cache in to your cache, which would need to be written back  
> > before sleeping.
> 
> Err, no.  If you read data into a cache, it is always populated in a clean
> state.  You never suck dirty data out of one cache, remove it there and
> place it immediately in a dirty state in an upper level cache.
> 
> So, if we start from the idea that reads will populate the upper level
> cache with clean data, that cache is populated merely with a _copy_ of
> the data held elsewhere in the system.

Hmm, Will tells me that later ARM cores can migrate dirty cache lines up
the cache tree, which means that we're potentially into deep problems
with CPU hotplug and suspend paths, because it means there's potentially
no way to ensure that we cleanly push data out the caches and shut the
caches down before the CPU goes down.

Combine this cache behaviour with the implementation specific details
about SCTRL.C (whether caches are just prevented from being allocated,
or whether it also affects the caches being searched) and you have a
recipe for multiple chunks of complex platform specific and CPU
specific code - especially when combined with things like removal of
CPU power and synchronisation of that in the hotplug case.

I do hope that ARM Ltd have thought about this, and have a way that we
can shut CPU caches down sanely, but I'm fearing that they haven't
really considered that to be something anyone really wants to do in a
generic way.


From kgene.kim at samsung.com  Fri Apr 19 06:52:16 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Fri, 19 Apr 2013 19:52:16 +0900
Subject: [GIT PULL] Timer clean-ups for 3.10, Part 2
In-Reply-To: <20130417184827.GA22799@quad.lixom.net>
References: <516720B4.3000703@gmail.com>
 <20130413065056.GB14735@quad.lixom.net> <516C0257.8040103@gmail.com>
 <201304152320.28401.arnd@arndb.de> <20130417165742.GB8730@quad.lixom.net>
 <20130417184827.GA22799@quad.lixom.net>
Message-ID: <064301ce3ceb$f731a4d0$e594ee70$%kim@samsung.com>

Olof Johansson wrote:
> 

[...]

> > Hrm, this is now a total mess. I can pick up Rob's preferred resolution,
> > but merging that in on top of the exynos branches causes lots of
> conflicts
> > there as well.
> >
> > I might just have to rebuild the next/ branches in question to resolve
> > this.  Either that or bring the late/clksrc stuff into the same branch
> > as the exynos timer patches.
> 
> Ok, given the complex merge fixup by Arnd (I'm not sure it's a great
> idea to add the new code in the merge commit like that, by the way),
> I've chosen to go with that as a base for late/clksrc instead, and I've
> pushed a new rebased late/clksrc that contains Arnd's version of the
> resolutions instead of Rob's. Let me know if further fixups are needed,
> in particular on exynos4 since I lack hardware to test that side.
> 
Let me test it on exynos4 in this weekend then I'll let you know.

I hope it will not be late for you.

Thanks.

- Kukjin



From nsekhar at ti.com  Fri Apr 19 06:52:56 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Fri, 19 Apr 2013 16:22:56 +0530
Subject: [PATCH v3 0/6] Generic PHY Framework
In-Reply-To: <1363770725-13717-1-git-send-email-kishon@ti.com>
References: <1363770725-13717-1-git-send-email-kishon@ti.com>
Message-ID: <51712208.5090403@ti.com>

Hi Kishon,

On 3/20/2013 2:41 PM, Kishon Vijay Abraham I wrote:
> Added a generic PHY framework that provides a set of APIs for the PHY drivers
> to create/destroy a PHY and APIs for the PHY users to obtain a reference to
> the PHY with or without using phandle. To obtain a reference to the PHY
> without using phandle, the platform specfic intialization code (say from board
> file) should have already called phy_bind with the binding information. The
> binding information consists of phy's device name, phy user device name and an
> index. The index is used when the same phy user binds to mulitple phys.
> 
> This framework will be of use only to devices that uses external PHY (PHY
> functionality is not embedded within the controller).

>From a top level what you are doing looks closely related to External
connector (extcon).

I understand a connector is not the same as a phy, but it will still be
useful to know why extcon framework (or some extension of it) will not
suffice your needs.

You can probably note it in the cover-letter so folks like me get their
answer.

Thanks,
Sekhar


From gang.chen at asianux.com  Fri Apr 19 06:53:07 2013
From: gang.chen at asianux.com (Chen Gang)
Date: Fri, 19 Apr 2013 18:53:07 +0800
Subject: [PATCH] ARM64: kernel: compiling issue,
 duplicate definition of early_console
In-Reply-To: <516E66F9.9070904@asianux.com>
References: <5152DB83.8080703@asianux.com>
 <20130327115509.GA1603@MacBook-Pro.local> <5152DFF1.2090000@asianux.com>
 <515BE49C.8040601@asianux.com> <515C14FD.4040703@codeaurora.org>
 <515C2808.70406@asianux.com> <516E66F9.9070904@asianux.com>
Message-ID: <51712213.4060607@asianux.com>


  when compiling with allmodconfig.
    early_console is already defined as an extern global pointer.

  need let it point to the object which we intend to (like ARM32 done).


Signed-off-by: Chen Gang <gang.chen at asianux.com>
---
 arch/arm64/kernel/early_printk.c |    5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/kernel/early_printk.c
b/arch/arm64/kernel/early_printk.c
index ac974f4..fbb6e18 100644
--- a/arch/arm64/kernel/early_printk.c
+++ b/arch/arm64/kernel/early_printk.c
@@ -95,7 +95,7 @@ static void early_write(struct console *con, const
char *s, unsigned n)
 	}
 }

-static struct console early_console = {
+static struct console early_console_dev = {
 	.name =		"earlycon",
 	.write =	early_write,
 	.flags =	CON_PRINTBUFFER | CON_BOOT,
@@ -145,7 +145,8 @@ static int __init setup_early_printk(char *buf)
 		early_base = early_io_map(paddr, EARLYCON_IOBASE);

 	printch = match->printch;
-	register_console(&early_console);
+	early_console = &early_console_dev;
+	register_console(&early_console_dev);

 	return 0;
 }
-- 
1.7.7.6


From kgene.kim at samsung.com  Fri Apr 19 06:59:57 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Fri, 19 Apr 2013 19:59:57 +0900
Subject: linux-next: manual merge of the arm-soc tree with the pm tree
In-Reply-To: <20130411083702.GE31465@quad.lixom.net>
References: <20130410171743.2ffa67388b330991228a6775@canb.auug.org.au>
 <30ad01ce35c6$8b13cb10$a13b6130$%kim@samsung.com>
 <20130411083702.GE31465@quad.lixom.net>
Message-ID: <064401ce3ced$07bd3840$1737a8c0$%kim@samsung.com>

Olof Johansson wrote:
> 
> On Wed, Apr 10, 2013 at 05:36:49PM +0900, Kukjin Kim wrote:
> > Stephen Rothwell wrote:
> > >
> > > Hi all,
> > >
> > Hi,
> >
> > > Today's linux-next merge of the arm-soc tree got a conflict in
> > > arch/arm/mach-s3c24xx/Kconfig between commit 785f40040874 ("cpufreq:
> > > s3c24xx: move cpufreq driver to drivers/cpufreq") from the pm tree and
> >
> > As I know, Rafael will drop it in his tree.
> > http://lists-archives.com/linux-kernel/27815851-cpufreq-s3c24xx-move-
> cpufreq
> > -driver-to-drivers-cpufreq.html
> >
> > > commits fb278af74b28 ("ARM: S3C24XX: Removed unneeded dependency on
> > > CPU_S3C2410") and a4e4d22c6f53 ("ARM: S3C24XX: Removed unneeded
> > > dependency on CPU_S3C2412") from the arm-soc tree.
> > >
> > > I fixed it up by removing the sections from arch/arm/mach-
> s3c24xx/Kconfig
> > > and can carry thefix as necessary (no action is required).
> > >
> > Thanks.
> >
> > > P.S. those arm-soc tree commits have a bad Author email address ...
> >
> > Oops :-( it's my fault due to e-mail client problem...
> >
> > Arnd, it happened in next/dt-exynos, next/mct-exynos and
> > next/cleanup-samsung branches in my tree.
> >
> > And I sorted out in my local just now. Could you please re-pull them
> into
> > arm-soc? Then, I will push forced. Sorry about that.
> 
> Given that it's "just" formatting errors, I would prefer not repulling and
> rebuilding just because of it. For someone reading the information it's

Hmm...if possible, I'm still hoping, you could replace previous branches
which including 'wrong format' for author e-mail :-) But up to you.

> pretty
> obvious what the valid email address would be. Please try to be mindful of
> it

OK.

> in the future though (and we'll try to double-check these things too).
> 
BTW, if you don't want to pull, I need to re-send for '[GIT PULL 4/4]
dt-exynos 2 for v3.10'...

But I'm not sure it's possible...

Anyway, sorry for noise.

- Kukjin



From lorenzo.pieralisi at arm.com  Fri Apr 19 07:21:45 2013
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Fri, 19 Apr 2013 12:21:45 +0100
Subject: [RFC PATCH] drivers: bus: add ARM CCI support
In-Reply-To: <51702B70.9000908@codeaurora.org>
References: <1365691679-28674-1-git-send-email-lorenzo.pieralisi@arm.com>
 <1365691679-28674-2-git-send-email-lorenzo.pieralisi@arm.com>
 <51702B70.9000908@codeaurora.org>
Message-ID: <20130419112145.GB8719@e102568-lin.cambridge.arm.com>

Thanks for the review Stephen.

On Thu, Apr 18, 2013 at 06:20:48PM +0100, Stephen Boyd wrote:
> On 04/11/13 07:47, Lorenzo Pieralisi wrote:
> > diff --git a/drivers/bus/arm-cci.c b/drivers/bus/arm-cci.c
> > new file mode 100644
> > index 0000000..81953de
> > --- /dev/null
> > +++ b/drivers/bus/arm-cci.c
> [...]
> > +static void notrace cci_port_control(unsigned int port, bool enable)
> > +{
> > +	void __iomem *base = ports[port].base;
> > +
> > +	if (!base)
> > +		return;
> > +
> > +	writel_relaxed(enable, base + CCI_PORT_CTRL);
> > +	while (readl_relaxed(cci_ctrl_base + CCI_CTRL_STATUS) & 0x1)
> > +			;
> 
> cpu_relax()?

Nico explained the reason why I did not add a cpu_relax() here, actually
having this function in C is already a moot point.

> > +}
> [...]
> > +int notrace __cci_control_port_by_device(struct device_node *np, bool enable)
> > +{
> > +	int port = cci_ace_lite_port(np);
> > +	if (WARN_ONCE(port < 0,
> > +		      "ACE lite port look-up failure, node %p\n", np))
> > +		return -ENODEV;
> > +	cci_port_control(port, enable);
> > +	return 0;
> > +}
> > +EXPORT_SYMBOL_GPL(__cci_control_port_by_device);
> > +
> > +static const struct of_device_id arm_cci_matches[];
> 
> Why not just put the definition here then?

Bah, absolutely.

> > +
> > +static int __init cci_driver_probe(struct platform_device *pdev)
> 
> You probably want to drop the __init considering device hotplug is not
> optional anymore.

I will rework the driver to make it non-hotpluggable compliant (ie use
platform_driver_probe()) honestly hotplug should be strictly prohibited
for CCI, it is a bus tied to CPU clusters I can hardly see any reason to
allow that.

> > +{
> > +	const struct of_device_id *match;
> > +	struct cci_nb_ports const *cci_config;
> > +	int ret, j, i, nb_ace = 0, nb_ace_lite = 0;
> > +	struct device_node *np, *cp;
> > +	const char *match_str;
> > +
> > +	match = of_match_device(arm_cci_matches, &pdev->dev);
> > +
> > +	if (!match)
> > +		return -ENODEV;
> 
> It would be nice if we could get the data field from the of_device_id
> without doing the search again. Can we update the of_platform code to
> assign some field that you can get from the platform device?

I guess there is a reason why it has not been implemented, I will have
a look to check that though.

> > +
> > +	cci_config = (struct cci_nb_ports const *)match->data;
> > +	nb_cci_ports = cci_config->nb_ace + cci_config->nb_ace_lite;
> > +	ports = kzalloc(sizeof(*ports) * nb_cci_ports, GFP_KERNEL);
> 
> kcalloc()?

Absolutely.

> > +	if (!ports)
> > +		return -ENOMEM;
> > +
> > +	np = pdev->dev.of_node;
> > +	cci_ctrl_base = of_iomap(np, 0);
> 
> This is a platform driver so we should use non-of functions to map,
> platform_get_resource()/ioremap(), etc.

Well, it has a strict dependency on DT though. Point taken anyway, I
will think about this.

> > +}
> > +
> > +static int __exit cci_driver_remove(struct platform_device *pdev)
> > +{
> 
> You probably want to drop the __exit here too.

See above.

> > diff --git a/include/linux/arm-cci.h b/include/linux/arm-cci.h
> > new file mode 100644
> > index 0000000..e9514a2
> > --- /dev/null
> > +++ b/include/linux/arm-cci.h
> > @@ -0,0 +1,44 @@
> > +
> > +#ifndef __LINUX_ARM_CCI_H
> > +#define __LINUX_ARM_CCI_H
> > +
> > +#include <linux/errno.h>
> > +#include <linux/of.h>
> > +#include <linux/types.h>
> 
> You can declare
> 
> struct device_node;
> 
> here to avoid including linux/of.h. Less includes means less circular
> dependencies.

Ok.

Thanks,
Lorenzo



From gang.chen at asianux.com  Fri Apr 19 07:24:37 2013
From: gang.chen at asianux.com (Chen Gang)
Date: Fri, 19 Apr 2013 19:24:37 +0800
Subject: [PATCH] ARM64: kernel: compiling issue: need define readq and writeq
 for driver module using.
Message-ID: <51712975.8030104@asianux.com>


  when compiling with allmodconfig, CONFIG_64BIT=y
    the file drivers/base/regmap/regmap-mmio.c will use readq and writeq.

  so we need implement these functions.

BTW:
  the coding style can not pass ./scripts/checkpatch.pl.
  it seems better to provide additional patch for beautifying code.

Signed-off-by: Chen Gang <gang.chen at asianux.com>
---
 arch/arm64/include/asm/io.h |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
index 57f12c9..2e12258 100644
--- a/arch/arm64/include/asm/io.h
+++ b/arch/arm64/include/asm/io.h
@@ -92,10 +92,12 @@ static inline u64 __raw_readq(const volatile void __iomem *addr)
 #define readb_relaxed(c)	({ u8  __v = __raw_readb(c); __v; })
 #define readw_relaxed(c)	({ u16 __v = le16_to_cpu((__force __le16)__raw_readw(c)); __v; })
 #define readl_relaxed(c)	({ u32 __v = le32_to_cpu((__force __le32)__raw_readl(c)); __v; })
+#define readq_relaxed(c)	({ u64 __v = le64_to_cpu((__force __le64)__raw_readq(c)); __v; })
 
 #define writeb_relaxed(v,c)	((void)__raw_writeb((v),(c)))
 #define writew_relaxed(v,c)	((void)__raw_writew((__force u16)cpu_to_le16(v),(c)))
 #define writel_relaxed(v,c)	((void)__raw_writel((__force u32)cpu_to_le32(v),(c)))
+#define writeq_relaxed(v,c)	((void)__raw_writeq((__force u64)cpu_to_le64(v),(c)))
 
 /*
  * I/O memory access primitives. Reads are ordered relative to any
@@ -105,10 +107,12 @@ static inline u64 __raw_readq(const volatile void __iomem *addr)
 #define readb(c)		({ u8  __v = readb_relaxed(c); __iormb(); __v; })
 #define readw(c)		({ u16 __v = readw_relaxed(c); __iormb(); __v; })
 #define readl(c)		({ u32 __v = readl_relaxed(c); __iormb(); __v; })
+#define readq(c)		({ u64 __v = readq_relaxed(c); __iormb(); __v; })
 
 #define writeb(v,c)		({ __iowmb(); writeb_relaxed((v),(c)); })
 #define writew(v,c)		({ __iowmb(); writew_relaxed((v),(c)); })
 #define writel(v,c)		({ __iowmb(); writel_relaxed((v),(c)); })
+#define writeq(v,c)		({ __iowmb(); writeq_relaxed((v),(c)); })
 
 /*
  *  I/O port access primitives.
-- 
1.7.7.6


From arno at natisbad.org  Fri Apr 19 07:30:51 2013
From: arno at natisbad.org (Arnaud Ebalard)
Date: Fri, 19 Apr 2013 13:30:51 +0200
Subject: [PATCH 1/3] Add support for GMT G72/G763 PWM fan controller
References: <cover.1366322287.git.arno@natisbad.org>
 <4f4a821bbc61e2da28fd70553fd717ada255097d.1366322287.git.arno@natisbad.org>
 <20130419055054.GD18115@lunn.ch>
Message-ID: <87y5ceahas.fsf@natisbad.org>

Hi,

Andrew Lunn <andrew at lunn.ch> writes:

> Hi Arnaud
>
>> +static DEVICE_ATTR(pwm1, S_IWUSR | S_IRUGO, get_pwm, set_pwm);
>> +static DEVICE_ATTR(pwm1_polarity, S_IWUSR | S_IRUGO,
>> +		   get_pwm_polarity, set_pwm_polarity);
>> +static DEVICE_ATTR(pwm1_mode, S_IWUSR | S_IRUGO,
>> +		   get_pwm_mode, set_pwm_mode);
>> +static DEVICE_ATTR(pwm1_enable, S_IWUSR | S_IRUGO,
>> +		   get_speed_control_mode, set_speed_control_mode);
>> +static DEVICE_ATTR(pwm1_freq, S_IWUSR | S_IRUGO,
>> +		   get_pwm_freq, set_pwm_freq);
>> +
>> +static DEVICE_ATTR(fan1_input, S_IRUGO, get_fan_rpm, NULL);
>> +static DEVICE_ATTR(fan1_alarm, S_IRUGO, get_fan_ooc, NULL);
>> +static DEVICE_ATTR(fan1_alarm_detection, S_IWUSR | S_IRUGO,
>> +		   get_fan_ooc_detection, set_fan_ooc_detection);
>> +static DEVICE_ATTR(fan1_fault, S_IRUGO, get_fan_failure, NULL);
>> +static DEVICE_ATTR(fan1_fault_detection, S_IWUSR | S_IRUGO,
>> +		   get_fan_failure_detection, set_fan_failure_detection);
>> +static DEVICE_ATTR(fan1_target, S_IWUSR | S_IRUGO,
>> +		   get_fan_target, set_fan_target);
>> +static DEVICE_ATTR(fan1_pulses, S_IWUSR | S_IRUGO,
>> +		   get_fan_pulses, set_fan_pulses);
>> +static DEVICE_ATTR(fan1_div, S_IWUSR | S_IRUGO,
>> +		   get_fan_clk_div, set_fan_clk_div);
>> +static DEVICE_ATTR(fan1_gear_mode, S_IWUSR | S_IRUGO,
>> +		   get_fan_gear_mode, set_fan_gear_mode);
>> +static DEVICE_ATTR(fan1_startup_voltage, S_IWUSR | S_IRUGO,
>> +		   get_fan_startup_voltage, set_fan_startup_voltage);
>
> It is normal to use SENSOR_ATTR, not DEVICE_ATTR. Take a look at the
> existing fan drivers.

I will take a look and use SENSOR_ATTR if it is the expected way. For
the records, the g760a.c which I used as basis uses DEVICE_ATTR ;-)

> I also think a lot of these are not needed. They are fixed properties
> of the board and cannot change dynamically. They are set once using DT
> and user space does not need to care.

I added those knobs for a simple reason: I don't have all the various
characteristics of the target platform I am working on (Netgear
ReadyNAS Duo v2) and needed to be able to test various values w/o
rebooting to get those rights. I thought this knobs would be useful for
people with the same issue (for instance, the new ReadyNAS 102 also has
a G762) and would not hurt.

Anyway, I will split the patch in two parts and keep the useless knobs
on my side.

Thanks for your feedback,

Cheers,

a+


From arno at natisbad.org  Fri Apr 19 07:31:15 2013
From: arno at natisbad.org (Arnaud Ebalard)
Date: Fri, 19 Apr 2013 13:31:15 +0200
Subject: [PATCH 1/3] Add support for GMT G72/G763 PWM fan controller
References: <cover.1366322287.git.arno@natisbad.org>
 <4f4a821bbc61e2da28fd70553fd717ada255097d.1366322287.git.arno@natisbad.org>
 <20130419080508.4866db90@endymion.delvare>
Message-ID: <87r4i6aha4.fsf@natisbad.org>

Hi,

Jean Delvare <khali at linux-fr.org> writes:

> Just a few things I noticed...

Ack. Will be fixed in next round. Thanks

Cheers,

a+


From sergei.shtylyov at cogentembedded.com  Fri Apr 19 07:44:46 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Fri, 19 Apr 2013 15:44:46 +0400
Subject: [PATCH 1/8] ARM: shmobile:Marzen: move USB EHCI, OHCI, and PHY
 devices to R8A7779 code
In-Reply-To: <20130419021755.GF25718@verge.net.au>
References: <201304050257.00799.sergei.shtylyov@cogentembedded.com>
 <20130418154425.GZ14496@n2100.arm.linux.org.uk>
 <5170301B.3030306@cogentembedded.com> <20130419021755.GF25718@verge.net.au>
Message-ID: <51712E2E.8040105@cogentembedded.com>

Hello.

On 19-04-2013 6:17, Simon Horman wrote:

>>>> +/* USB PHY */
>>>> +static struct resource usb_phy_resources[] = {
>>>> +	[0] = {
>>>> +		.start		= 0xffe70000,
>>>> +		.end		= 0xffe70900 - 1,
>>>> +		.flags		= IORESOURCE_MEM,
>>>> +	},
>>>> +	[1] = {
>>>> +		.start		= 0xfff70000,
>>>> +		.end		= 0xfff70900 - 1,
>>>> +		.flags		= IORESOURCE_MEM,
>>>> +	},

>>> Please consider using the macros for these initialisers.

>>     I'm just moving the code as is here. The destination file still
>> uses old style initializers, and probably needs the wholesale
>> conversion patch in the future.

> My preference is for you to either convert these users in this patch or
> provide a patch that makes a wholesale conversion.

    I'll try to do the latter but my load is currently very high, so that
may take some time.

WBR, Sergei



From gang.chen at asianux.com  Fri Apr 19 07:45:34 2013
From: gang.chen at asianux.com (Chen Gang)
Date: Fri, 19 Apr 2013 19:45:34 +0800
Subject: [Suggestion] ARM64: kernel: compiling issue, need implement cmpxchg64
 with assembler language.
Message-ID: <51712E5E.2020809@asianux.com>


in arch/arm64/include/asm, not define the function cmpxchg64

  when compiling with allmodconfig,
    drivers/block/blockconsole.c will need this function.

  I am not quite familiar with ARM64 (neither ARM64 assembler)

  can any member helps to send related patch ?
    if no one have time to send related patch, I should try.
    and I am glad to try, but need additional time resources,
    if I try, I should finish it within this month (2013-4-30).

  welcome any suggestions or completions.

  thanks.


gchen.


From yuvaraj.cd at gmail.com  Fri Apr 19 07:56:23 2013
From: yuvaraj.cd at gmail.com (Yuvaraj Kumar C D)
Date: Fri, 19 Apr 2013 17:26:23 +0530
Subject: [PATCH] I2C: EXYNOS: High speed mode clock setting for HSI2C
Message-ID: <1366372583-7584-1-git-send-email-yuvaraj.cd@samsung.com>

This patch configure the High speed mode timing register using the
clock speed mentioned in the dts file.Also it configure the MASTER_ID
for High speed i2c transfer.
For i2c high speed transaction, tarnsaction initially starts with the
fast mode i,e 400Kbits/sec and then switches to high speed mode.For this
purpose it requires to set up timing value for fast mode and high speed
mode.

Signed-off-by: Yuvaraj Kumar C D <yuvaraj.cd at samsung.com>
---
 drivers/i2c/busses/i2c-exynos5.c |   85 ++++++++++++++++++++++++++------------
 1 file changed, 58 insertions(+), 27 deletions(-)

diff --git a/drivers/i2c/busses/i2c-exynos5.c b/drivers/i2c/busses/i2c-exynos5.c
index 968c34f..ef7155f 100644
--- a/drivers/i2c/busses/i2c-exynos5.c
+++ b/drivers/i2c/busses/i2c-exynos5.c
@@ -139,12 +139,14 @@
 #define HSI2C_SLV_ADDR_SLV(x)			((x & 0x3ff) << 0)
 #define HSI2C_SLV_ADDR_MAS(x)			((x & 0x3ff) << 10)
 #define HSI2C_MASTER_ID(x)			((x & 0xff) << 24)
+#define MASTER_ID(x)				((x & 0x7) + 0x08)
 
 /* Controller operating frequency, timing values for operation
  * are calculated against this frequency
  */
 #define HSI2C_HS_TX_CLOCK	1000000
-#define HSI2C_FS_TX_CLOCK	1000000
+/*HSI2C supports upto 400 kb/s in FAST Mode and 3.4 Mb/s in High Speed Mode*/
+#define HSI2C_FS_TX_CLOCK	 400000
 #define HSI2C_HIGH_SPD		1
 #define HSI2C_FAST_SPD		0
 
@@ -173,7 +175,8 @@ struct exynos5_i2c {
 	int			gpios[2];
 
 	/* Controller operating frequency */
-	unsigned int		clock;
+	unsigned int		fs_clock;
+	unsigned int		hs_clock;
 	unsigned int		clk_cycle;
 	unsigned int		clk_div;
 
@@ -182,6 +185,7 @@ struct exynos5_i2c {
 	 * 2. Fast speed upto 1Mbps
 	 */
 	int			speed_mode;
+	int			current_mode;
 };
 
 static const struct of_device_id exynos5_i2c_match[] = {
@@ -222,10 +226,11 @@ static void exynos5_i2c_clr_pend_irq(struct exynos5_i2c *i2c)
  */
 static int exynos5_i2c_clock_info(struct exynos5_i2c *i2c)
 {
-	unsigned int op_clk = i2c->clock;
 	unsigned int clkin = clk_get_rate(i2c->clk);
-	unsigned int i, utemp0 = 0, utemp1 = 0;
+	unsigned int div, utemp0 = 0, utemp1 = 0;
 	unsigned int t_ftl_cycle;
+	unsigned int op_clk = (i2c->current_mode == HSI2C_HIGH_SPD) ?
+					i2c->hs_clock : i2c->fs_clock;
 
 	/* FPCLK / FI2C =
 	 * (CLK_DIV + 1) * (TSCLK_L + TSCLK_H + 2) + 8 + 2 * FLT_CYCLE
@@ -236,8 +241,8 @@ static int exynos5_i2c_clock_info(struct exynos5_i2c *i2c)
 	utemp0 = (clkin / op_clk) - 8 - 2 * t_ftl_cycle;
 
 	/* CLK_DIV max is 256 */
-	for (i = 0; i < 256; i++) {
-		utemp1 = utemp0 / (i + 1);
+	for (div = 0; div < 256; div++) {
+		utemp1 = utemp0 / (div + 1);
 
 		/* SCL_L and SCL_H each has max value of 255
 		 * Hence, For the clk_cycle to the have right value
@@ -245,7 +250,7 @@ static int exynos5_i2c_clock_info(struct exynos5_i2c *i2c)
 		 */
 		if ((utemp1 < 512) && (utemp1 > 4)) {
 			i2c->clk_cycle = utemp1 - 2;
-			i2c->clk_div = i;
+			i2c->clk_div = div;
 			return 0;
 		}
 	}
@@ -297,7 +302,7 @@ static void exynos5_i2c_set_timing(struct exynos5_i2c *i2c)
 		n_clkdiv, t_sr_release);
 	dev_dbg(i2c->dev, "tDATA_HD: %X\n", t_data_hd);
 
-	if (i2c->speed_mode == HSI2C_HIGH_SPD) {
+	if (i2c->current_mode == HSI2C_HIGH_SPD) {
 		writel(i2c_timing_s1, i2c->regs + HSI2C_TIMING_HS1);
 		writel(i2c_timing_s2, i2c->regs + HSI2C_TIMING_HS2);
 		writel(i2c_timing_s3, i2c->regs + HSI2C_TIMING_HS3);
@@ -309,25 +314,52 @@ static void exynos5_i2c_set_timing(struct exynos5_i2c *i2c)
 	writel(i2c_timing_sla, i2c->regs + HSI2C_TIMING_SLA);
 }
 
+static int exynos5_hsi2c_clock_setup(struct exynos5_i2c *i2c)
+{
+
+	if (exynos5_i2c_clock_info(i2c)) {
+		dev_err(i2c->dev, "HSI2C FS Clock set up failed\n");
+		return -EINVAL;
+	}
+	exynos5_i2c_set_timing(i2c);
+/*If controller supports High Speed configure the High speed timing value*/
+	if (i2c->speed_mode == HSI2C_HIGH_SPD) {
+		i2c->current_mode = HSI2C_HIGH_SPD;
+		if (exynos5_i2c_clock_info(i2c)) {
+			dev_err(i2c->dev, "HSI2C HS Clock set up failed\n");
+			return -EINVAL;
+		}
+	exynos5_i2c_set_timing(i2c);
+	}
+	return 0;
+}
+
 /* exynos5_i2c_init: configures the controller for I2C functionality
  * Programs I2C controller for Master mode operation
  *
  * Note: Currently, supports AUTO mode of operation.
  */
-static void exynos5_i2c_init(struct exynos5_i2c *i2c)
+static int exynos5_i2c_init(struct exynos5_i2c *i2c)
 {
+	int id = 0, ret;
 	u32 i2c_conf = readl(i2c->regs + HSI2C_CONF);
 
+	if (i2c->adap.dev.of_node)
+		id = of_alias_get_id(i2c->adap.dev.of_node, "hsi2c");
 	writel((HSI2C_FUNC_MODE_I2C | HSI2C_MASTER),
 					i2c->regs + HSI2C_CTL);
 	writel(HSI2C_TRAILING_COUNT, i2c->regs + HSI2C_TRAILIG_CTL);
+	ret = exynos5_hsi2c_clock_setup(i2c);
+	if (ret < 0)
+		return ret;
 
-	exynos5_i2c_set_timing(i2c);
 
-	if (i2c->speed_mode == HSI2C_HIGH_SPD)
+	if (i2c->speed_mode == HSI2C_HIGH_SPD) {
+		writel(HSI2C_MASTER_ID(MASTER_ID(id)), i2c->regs + HSI2C_ADDR);
 		i2c_conf |= HSI2C_HS_MODE;
-
+	}
 	writel(i2c_conf | HSI2C_AUTO_MODE, i2c->regs + HSI2C_CONF);
+	return ret;
 }
 
 static void exynos5_i2c_reset(struct exynos5_i2c *i2c)
@@ -372,7 +404,6 @@ static irqreturn_t exynos5_i2c_irq(int irqno, void *dev_id)
 
 	int_status = readl(i2c->regs + HSI2C_INT_STATUS);
 	fifo_status = readl(i2c->regs + HSI2C_FIFO_STATUS);
-
 	if (int_status & HSI2C_INT_I2C) {
 		trans_status = readl(i2c->regs + HSI2C_TRANS_STATUS);
 		if (trans_status & HSI2C_NO_DEV_ACK) {
@@ -500,7 +531,6 @@ static void exynos5_i2c_message_start(struct exynos5_i2c *i2c, int stop)
 
 	i2c_ctl = readl(i2c->regs + HSI2C_CTL);
 	i2c_ctl &= ~(HSI2C_TXCHON | HSI2C_RXCHON);
-
 	if (i2c->msg->flags & I2C_M_RD) {
 		i2c_ctl |= HSI2C_RXCHON;
 
@@ -731,14 +761,15 @@ static int exynos5_i2c_probe(struct platform_device *pdev)
 
 	/* Mode of operation High/Fast Speed mode */
 	if (of_get_property(np, "samsung,hs-mode", NULL)) {
-		i2c->speed_mode = 1;
-		if (of_property_read_u32(np, "samsung,hs-clock", &i2c->clock))
-			i2c->clock = HSI2C_HS_TX_CLOCK;
-	} else {
-		i2c->speed_mode = 0;
-		if (of_property_read_u32(np, "samsung,fs-clock", &i2c->clock))
-			i2c->clock = HSI2C_FS_TX_CLOCK;
+		i2c->speed_mode = HSI2C_HIGH_SPD;
+		if (of_property_read_u32(np, "samsung,hs-clock",
+						&i2c->hs_clock))
+			i2c->hs_clock = HSI2C_HS_TX_CLOCK;
 	}
+	if (of_property_read_u32(np, "samsung,fs-clock", &i2c->fs_clock))
+		i2c->fs_clock = HSI2C_FS_TX_CLOCK;
+	/*High Speed mode initially starts with Fast mode*/
+	i2c->current_mode = HSI2C_FAST_SPD;
 
 	strlcpy(i2c->adap.name, "exynos5-i2c", sizeof(i2c->adap.name));
 	i2c->adap.owner   = THIS_MODULE;
@@ -773,12 +804,6 @@ static int exynos5_i2c_probe(struct platform_device *pdev)
 	/* Clear pending interrupts from u-boot or misc causes */
 	exynos5_i2c_clr_pend_irq(i2c);
 
-	ret = exynos5_i2c_clock_info(i2c);
-	if (ret)
-		goto err_iomap;
-
-	exynos5_i2c_init(i2c);
-
 	init_completion(&i2c->msg_complete);
 
 	i2c->irq = ret = irq_of_parse_and_map(np, 0);
@@ -811,6 +836,12 @@ static int exynos5_i2c_probe(struct platform_device *pdev)
 	i2c->adap.nr = -1;
 	i2c->adap.dev.of_node = np;
 
+	ret = exynos5_i2c_init(i2c);
+	if (ret < 0) {
+		dev_err(&pdev->dev, "failed to init HSI2C Controller\n");
+		goto err_pm;
+	}
+
 	ret = i2c_add_numbered_adapter(&i2c->adap);
 	if (ret < 0) {
 		dev_err(&pdev->dev, "failed to add bus to i2c core\n");
-- 
1.7.9.5



From gang.chen at asianux.com  Fri Apr 19 07:56:56 2013
From: gang.chen at asianux.com (Chen Gang)
Date: Fri, 19 Apr 2013 19:56:56 +0800
Subject: [Suggestion] ARM:S5pv210: compiling issue for s5pv210 by using
 randconfig
In-Reply-To: <20130417110233.GD4998@game.jcrosoft.org>
References: <514FB202.3040807@asianux.com> <516E6A8E.3000001@asianux.com>
 <20130417100136.GB19492@mudshark.cambridge.arm.com>
 <201304171253.20284.arnd@arndb.de> <20130417110233.GD4998@game.jcrosoft.org>
Message-ID: <51713108.5010804@asianux.com>

On 2013?04?17? 19:02, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 12:53 Wed 17 Apr     , Arnd Bergmann wrote:
>> On Wednesday 17 April 2013, Will Deacon wrote:
>>>> arm-linux-gnu-gcc -Wp,-MD,arch/arm/vfp/.vfphw.o.d  -nostdinc -isystem /usr/lib/gcc/arm-linux-gnueabi/4.7.1/include -I/root/linux-next/arch/arm/include -Iarch/arm/include/generated  -Iinclude -I/root/linux-next/arch/arm/include/uapi -Iarch/arm/include/generated/uapi -I/root/linux-next/include/uapi -Iinclude/generated/uapi -include /root/linux-next/include/linux/kconfig.h -D__KERNEL__ -mlittle-endian -Iarch/arm/mach-s5pv210/include -Iarch/arm/plat-samsung/include  -D__ASSEMBLY__ -mabi=apcs-gnu -mno-thumb-interwork -marm -D__LINUX_ARM_ARCH__=4 -march=armv4t -mtune=arm9tdmi -include asm/unified.h -Wa,-mfpu=softvfp+vfp -mfloat-abi=soft        -c -o arch/arm/vfp/vfphw.o arch/arm/vfp/vfphw.S
>>>>
>>>>
>>>>   compiling err:
>>>>
>>>> arch/arm/vfp/vfphw.S: Assembler messages:
>>>> arch/arm/vfp/vfphw.S:295: Error: selected processor does not support ARM mode `mrrc p11,3,r0,r1,c0'
>>>> arch/arm/vfp/vfphw.S:295: Error: selected processor does not support ARM mode `mrrc p11,3,r0,r1,c1'
>>>
>>> The problem here is that you've ended up targetting a platform (s5pv210)
>>> that selects CPU_V7. VFP is then subsequently selected, but CONFIG_MMU=n, so
>>> 7TDMI and 9TDMI (v4 CPUs, no VFP) are selectable. Selecting either of those,
>>> causes these warnings.
>>>
>>> Unfortunately, I'm not sure how best to fix this. Most of the !MMU CPUs are
>>> tied to a particular board (lots of `if ARCH_INTEGRATOR' predicates), but we
>>> don't want to do that for 7tdmi.
>>>
>>> If we could enforce the strict exclusion of {<= ARMv5} and {ARMv6+} in the
>>> Kconfig, that would solve your problem.
>>
>> I have not tried to get no-MMU kernels to build in general. I think the way
>> it should be done is to not offer any user-selectable CPU types at all but
>> always select the CPU from the board.
>>
>> For randconfig tests, I would recommend turning on CONFIG_MMU unconditionally
>> using an appropriate KCONFIG_ALLCONFIG= file.
>>
>> The alternative is to use the patch below, but it may be incomplete: I could
>> not find anything other than AT91x40 in the kernel that actually has an
>> ARM7TDMI or ARM9TDMI.
>>
>> 	Arnd
>>
>> diff --git a/arch/arm/mach-at91/Kconfig.non_dt b/arch/arm/mach-at91/Kconfig.non_dt
>> index 6c24985..dc972e1 100644
>> --- a/arch/arm/mach-at91/Kconfig.non_dt
>> +++ b/arch/arm/mach-at91/Kconfig.non_dt
>> @@ -47,6 +47,7 @@ config ARCH_AT91X40
>>  	select ARCH_USES_GETTIMEOFFSET
>>  	select MULTI_IRQ_HANDLER
>>  	select SPARSE_IRQ
>> +	select CPU_ARM7TDMI
>>  
>>  endchoice
>>  
>> diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
>> index 84af266..c5e4ef0 100644
>> --- a/arch/arm/mm/Kconfig
>> +++ b/arch/arm/mm/Kconfig
>> @@ -6,7 +6,6 @@ comment "Processor Type"
>>  
>>  # ARM7TDMI
>>  config CPU_ARM7TDMI
>> -	bool "Support ARM7TDMI processor"
> whith the bool type at least
>>  	depends on !MMU
>>  	select CPU_32v4T
>>  	select CPU_ABRT_LV4T
>> @@ -56,7 +55,6 @@ config CPU_ARM740T
>>  
>>  # ARM9TDMI
>>  config CPU_ARM9TDMI
>> -	bool "Support ARM9TDMI processor"
>>  	depends on !MMU
>>  	select CPU_32v4T
>>  	select CPU_ABRT_NOMMU
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 
> 

  thank you for your all valuable information.

  if no one have time to continue to try, I should try (glad to try)

  if I try, I think I should:
    a. make a related patch according to all of you said.
    b. make menuconfig with the original .config
         save directly, and exit the menuconfig.
    c. check the related CONFIG_* value in new .config
    d. build
    e. ...
    z. I should fix this issue within this month.


  welcome any suggestions or completions.

  thanks.


-- 
Chen Gang

Asianux Corporation


From arnd at arndb.de  Fri Apr 19 08:12:54 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 19 Apr 2013 14:12:54 +0200
Subject: [Suggestion] ARM64: kernel: compiling issue,
 need implement cmpxchg64 with assembler language.
In-Reply-To: <51712E5E.2020809@asianux.com>
References: <51712E5E.2020809@asianux.com>
Message-ID: <201304191412.54601.arnd@arndb.de>

On Friday 19 April 2013, Chen Gang wrote:
> in arch/arm64/include/asm, not define the function cmpxchg64
> 
>   when compiling with allmodconfig,
>     drivers/block/blockconsole.c will need this function.
> 
>   I am not quite familiar with ARM64 (neither ARM64 assembler)
> 
>   can any member helps to send related patch ?
>     if no one have time to send related patch, I should try.
>     and I am glad to try, but need additional time resources,
>     if I try, I should finish it within this month (2013-4-30).
> 
>   welcome any suggestions or completions.

cmpxchg64 is the same as cmpxchg on 64-bit platforms, can't the
driver be changed to use the latter?

	Arnd


From arnd at arndb.de  Fri Apr 19 08:13:57 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 19 Apr 2013 14:13:57 +0200
Subject: [PATCH] ARM64: kernel: compiling issue: need define readq and
 writeq for driver module using.
In-Reply-To: <51712975.8030104@asianux.com>
References: <51712975.8030104@asianux.com>
Message-ID: <201304191413.57424.arnd@arndb.de>

On Friday 19 April 2013, Chen Gang wrote:
>   when compiling with allmodconfig, CONFIG_64BIT=y
>     the file drivers/base/regmap/regmap-mmio.c will use readq and writeq.
> 
>   so we need implement these functions.
> 
> BTW:
>   the coding style can not pass ./scripts/checkpatch.pl.
>   it seems better to provide additional patch for beautifying code.
> 
> Signed-off-by: Chen Gang <gang.chen at asianux.com>

Acked-by: Arnd Bergmann <arnd at arndb.de>


From arnd at arndb.de  Fri Apr 19 08:15:31 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 19 Apr 2013 14:15:31 +0200
Subject: [PATCH] ARM64: kernel: compiling issue,
 duplicate definition of early_console
In-Reply-To: <51712213.4060607@asianux.com>
References: <5152DB83.8080703@asianux.com> <516E66F9.9070904@asianux.com>
 <51712213.4060607@asianux.com>
Message-ID: <201304191415.31986.arnd@arndb.de>

On Friday 19 April 2013, Chen Gang wrote:
>   when compiling with allmodconfig.
>     early_console is already defined as an extern global pointer.
> 
>   need let it point to the object which we intend to (like ARM32 done).
> 
> 
> Signed-off-by: Chen Gang <gang.chen at asianux.com>

Acked-by: Arnd Bergmann <arnd at arndb.de>


From linux at arm.linux.org.uk  Fri Apr 19 08:16:52 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Fri, 19 Apr 2013 13:16:52 +0100
Subject: [RFC PATCHv2 arm: initial TI-Nspire support]
In-Reply-To: <8E071E2D-4FF3-487E-A53B-B6A7C427E421@gmail.com>
References: <8E071E2D-4FF3-487E-A53B-B6A7C427E421@gmail.com>
Message-ID: <20130419121652.GK14496@n2100.arm.linux.org.uk>

On Thu, Apr 11, 2013 at 09:51:43PM +1000, Daniel Tang wrote:
> +	.cntl		= (CNTL_BGR | CNTL_LCDTFT | CNTL_LCDVCOMP(1) |
> +				CNTL_LCDBPP16_565),

NAK.  Use the panel capabilities instead.


From lee.jones at linaro.org  Fri Apr 19 08:22:26 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Fri, 19 Apr 2013 13:22:26 +0100
Subject: [PATCH 4/9 v2] crypto: ux500/cryp - Prepare clock before enabling it
In-Reply-To: <1366280825-31136-5-git-send-email-lee.jones@linaro.org>
References: <1366280825-31136-1-git-send-email-lee.jones@linaro.org>
 <1366280825-31136-5-git-send-email-lee.jones@linaro.org>
Message-ID: <20130419122226.GB3432@gmail.com>

Slight change of plan for v2.

Now we're doing a seperate clk_prepare(), as the clk_enable() in the
previous patch turned out to be called inside a spin_lock().

Arnd, can you confirm your Ack please?

----

crypto: ux500/cryp - Prepare clock before enabling it
    
If we fail to prepare the ux500-cryp clock before enabling it the
platform will fail to boot. Here we insure this happens.
    
Cc: Herbert Xu <herbert at gondor.apana.org.au>
Cc: David S. Miller <davem at davemloft.net>
Cc: Andreas Westin <andreas.westin at stericsson.com>
Cc: linux-crypto at vger.kernel.org
Acked-by: Arnd Bergmann <arnd at arndb.de>
Signed-off-by: Lee Jones <lee.jones at linaro.org>

diff --git a/drivers/crypto/ux500/cryp/cryp_core.c b/drivers/crypto/ux500/cryp/cryp_core.c
index 22c9063..bf78d60 100644
--- a/drivers/crypto/ux500/cryp/cryp_core.c
+++ b/drivers/crypto/ux500/cryp/cryp_core.c
@@ -1459,11 +1459,17 @@ static int ux500_cryp_probe(struct platform_device *pdev)
 		goto out_regulator;
 	}
 
+	ret = clk_prepare(device_data->clk);
+	if (ret) {
+		dev_err(dev, "[%s]: clk_prepare() failed!", __func__);
+		goto out_clk;
+	}
+
 	/* Enable device power (and clock) */
 	ret = cryp_enable_power(device_data->dev, device_data, false);
 	if (ret) {
 		dev_err(dev, "[%s]: cryp_enable_power() failed!", __func__);
-		goto out_clk;
+		goto out_clk_unprepare;
 	}
 
 	cryp_error = cryp_check(device_data);
@@ -1524,6 +1530,9 @@ static int ux500_cryp_probe(struct platform_device *pdev)
 out_power:
 	cryp_disable_power(device_data->dev, device_data, false);
 
+out_clk_unprepare:
+	clk_unprepare(device_data->clk);
+
 out_clk:
 	clk_put(device_data->clk);
 
@@ -1594,6 +1603,7 @@ static int ux500_cryp_remove(struct platform_device *pdev)
 		dev_err(&pdev->dev, "[%s]: cryp_disable_power() failed",
 			__func__);
 
+	clk_unprepare(device_data->clk);
 	clk_put(device_data->clk);
 	regulator_put(device_data->pwr_regulator);


From arnd at arndb.de  Fri Apr 19 08:23:57 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 19 Apr 2013 14:23:57 +0200
Subject: [PATCH 4/9 v2] crypto: ux500/cryp - Prepare clock before enabling
 it
In-Reply-To: <20130419122226.GB3432@gmail.com>
References: <1366280825-31136-1-git-send-email-lee.jones@linaro.org>
 <1366280825-31136-5-git-send-email-lee.jones@linaro.org>
 <20130419122226.GB3432@gmail.com>
Message-ID: <201304191423.57261.arnd@arndb.de>

On Friday 19 April 2013, Lee Jones wrote:
> Slight change of plan for v2.
> 
> Now we're doing a seperate clk_prepare(), as the clk_enable() in the
> previous patch turned out to be called inside a spin_lock().
> 
> Arnd, can you confirm your Ack please?
> 

Acked-by: Arnd Bergmann <arnd at arndb.de>


From lee.jones at linaro.org  Fri Apr 19 08:24:28 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Fri, 19 Apr 2013 13:24:28 +0100
Subject: [PATCH 1/9 v2] crypto: ux500/hash - Prepare clock before enabling it
In-Reply-To: <1366280825-31136-2-git-send-email-lee.jones@linaro.org>
References: <1366280825-31136-1-git-send-email-lee.jones@linaro.org>
 <1366280825-31136-2-git-send-email-lee.jones@linaro.org>
Message-ID: <20130419122428.GC3432@gmail.com>

Slight change of plan for v2.

Now we're doing a seperate clk_prepare(), as the clk_enable() in the
previous patch turned out to be called inside a spin_lock().

Arnd, can you confirm your Ack please?

---

crypto: ux500/hash - Prepare clock before enabling it

If we fail to prepare the ux500-hash clock before enabling it the
platform will fail to boot. Here we insure this happens.

Cc: Herbert Xu <herbert at gondor.apana.org.au>
Cc: David S. Miller <davem at davemloft.net>
Cc: Andreas Westin <andreas.westin at stericsson.com>
Cc: linux-crypto at vger.kernel.org
Acked-by: Arnd Bergmann <arnd at arndb.de>
Signed-off-by: Lee Jones <lee.jones at linaro.org>

diff --git a/drivers/crypto/ux500/hash/hash_core.c b/drivers/crypto/ux500/hash/hash_core.c
index 632c333..1e8b2f3 100644
--- a/drivers/crypto/ux500/hash/hash_core.c
+++ b/drivers/crypto/ux500/hash/hash_core.c
@@ -1727,11 +1727,17 @@ static int ux500_hash_probe(struct platform_device *pdev)
 		goto out_regulator;
 	}
 
+	ret = clk_prepare(device_data->clk);
+	if (ret) {
+		dev_err(dev, "[%s] clk_prepare() failed!", __func__);
+		goto out_clk;
+	}
+
 	/* Enable device power (and clock) */
 	ret = hash_enable_power(device_data, false);
 	if (ret) {
 		dev_err(dev, "[%s]: hash_enable_power() failed!", __func__);
-		goto out_clk;
+		goto out_clk_unprepare;
 	}
 
 	ret = hash_check_hw(device_data);
@@ -1763,6 +1769,9 @@ static int ux500_hash_probe(struct platform_device *pdev)
 out_power:
 	hash_disable_power(device_data, false);
 
+out_clk_unprepare:
+	clk_unprepare(device_data->clk);
+
 out_clk:
 	clk_put(device_data->clk);
 
@@ -1827,6 +1836,7 @@ static int ux500_hash_remove(struct platform_device *pdev)
 		dev_err(dev, "[%s]: hash_disable_power() failed",
 			__func__);
 
+	clk_unprepare(device_data->clk);
 	clk_put(device_data->clk);
 	regulator_put(device_data->regulator);


From arnd at arndb.de  Fri Apr 19 08:26:37 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 19 Apr 2013 14:26:37 +0200
Subject: [PATCH 1/9 v2] crypto: ux500/hash - Prepare clock before enabling
 it
In-Reply-To: <20130419122428.GC3432@gmail.com>
References: <1366280825-31136-1-git-send-email-lee.jones@linaro.org>
 <1366280825-31136-2-git-send-email-lee.jones@linaro.org>
 <20130419122428.GC3432@gmail.com>
Message-ID: <201304191426.37408.arnd@arndb.de>

On Friday 19 April 2013, Lee Jones wrote:
> Slight change of plan for v2.
> 
> Now we're doing a seperate clk_prepare(), as the clk_enable() in the
> previous patch turned out to be called inside a spin_lock().
> 
> Arnd, can you confirm your Ack please?
> 

Acked-by: Arnd Bergmann <arnd at arndb.de>


From catalin.marinas at arm.com  Fri Apr 19 08:31:50 2013
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Fri, 19 Apr 2013 13:31:50 +0100
Subject: [PATCH] ARM64: kernel: compiling issue, duplicate definition
 of early_console
In-Reply-To: <51712213.4060607@asianux.com>
References: <5152DB83.8080703@asianux.com>
 <20130327115509.GA1603@MacBook-Pro.local>
 <5152DFF1.2090000@asianux.com> <515BE49C.8040601@asianux.com>
 <515C14FD.4040703@codeaurora.org> <515C2808.70406@asianux.com>
 <516E66F9.9070904@asianux.com> <51712213.4060607@asianux.com>
Message-ID: <20130419123150.GA18443@arm.com>

On Fri, Apr 19, 2013 at 11:53:07AM +0100, Chen Gang wrote:
>   when compiling with allmodconfig.
>     early_console is already defined as an extern global pointer.
> 
>   need let it point to the object which we intend to (like ARM32 done).
> 
> 
> Signed-off-by: Chen Gang <gang.chen at asianux.com>

Thanks for the patch.

-- 
Catalin


From catalin.marinas at arm.com  Fri Apr 19 08:35:13 2013
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Fri, 19 Apr 2013 13:35:13 +0100
Subject: [PATCH] ARM64: kernel: compiling issue: need define readq and
 writeq for driver module using.
In-Reply-To: <51712975.8030104@asianux.com>
References: <51712975.8030104@asianux.com>
Message-ID: <20130419123513.GB18443@arm.com>

On Fri, Apr 19, 2013 at 12:24:37PM +0100, Chen Gang wrote:
> 
>   when compiling with allmodconfig, CONFIG_64BIT=y
>     the file drivers/base/regmap/regmap-mmio.c will use readq and writeq.
> 
>   so we need implement these functions.
> 
> BTW:
>   the coding style can not pass ./scripts/checkpatch.pl.
>   it seems better to provide additional patch for beautifying code.

If it complains about long lines, just ignore it. I wouldn't worry too
much about checkpatch.pl and coding style warnings ;)

> Signed-off-by: Chen Gang <gang.chen at asianux.com>

Thanks.

-- 
Catalin


From andre.przywara at linaro.org  Fri Apr 19 08:58:57 2013
From: andre.przywara at linaro.org (Andre Przywara)
Date: Fri, 19 Apr 2013 14:58:57 +0200
Subject: [PATCH] ARM: KVM: iterate over all CPUs for CPU compatibility
 check
In-Reply-To: <CAEDV+g+3nkdvbLdj0m-ZdDKt0JY2vgzhP2AQA2nf=R3h4yTQmQ@mail.gmail.com>
References: <51680AF9.7040109@arm.com>
 <CAEDV+g+E8PLc60vMRhq4O_AL2WjmYDLb6=Wh34ynhevh7uAGJA@mail.gmail.com>
 <d455f2823b9639af8d38d30f2c3234bd@localhost>
 <CAEDV+gJuFG49oQ=BEaCHcTP=nHVyX8ALw6076dR_C1s7TuyqXQ@mail.gmail.com>
 <d47697abd39a0d5d41f5ac110a40e261@localhost>
 <CAEDV+gK9==sXYxRVZ8JVFYPiw3_xgzZBbydEwPunmnocNLKXrQ@mail.gmail.com>
 <CAFEAcA-bPoa8YoPuHPmupzfUW+yR233XquK79eNorzcRpFiK=g@mail.gmail.com>
 <516BCAD0.9000708@linaro.org>
 <CAJRNFKJoBzgt4UhxsH65_LyhcGXPnzB_pg3q-zeYT2OVv59q4A@mail.gmail.com>
 <516BFD13.1000400@linaro.org>
 <20130415134837.GI9827@mudshark.cambridge.arm.com>
 <CAEDV+gJB7Bj9O7pftFqoYQ=goORjdurBnEfQVmC5arDuNJfpBg@mail.gmail.com>
 <32d532438f5b621e40679aea9f5888c7@localhost> <516E586C.5030407@linaro.org>
 <8e0bda3fd84d1b0c5aa55161ca178a8e@localhost>
 <CAEDV+g+3nkdvbLdj0m-ZdDKt0JY2vgzhP2AQA2nf=R3h4yTQmQ@mail.gmail.com>
Message-ID: <51713F91.5080102@linaro.org>

On 04/17/2013 11:12 AM, Christoffer Dall wrote:
>
>
>
> On Wed, Apr 17, 2013 at 1:16 AM, Marc Zyngier <marc.zyngier at arm.com
> <mailto:marc.zyngier at arm.com>> wrote:
>
>     On Wed, 17 Apr 2013 10:08:12 +0200, Andre Przywara
>     <andre.przywara at linaro.org <mailto:andre.przywara at linaro.org>> wrote:
>      > On 04/16/2013 06:33 PM, Marc Zyngier wrote:
>      >> On Tue, 16 Apr 2013 09:26:26 -0700, Christoffer Dall
>      >> <cdall at cs.columbia.edu <mailto:cdall at cs.columbia.edu>> wrote:
>      >>> On Mon, Apr 15, 2013 at 6:48 AM, Will Deacon
>     <will.deacon at arm.com <mailto:will.deacon at arm.com>>
>      >> wrote:
>      >>>> On Mon, Apr 15, 2013 at 02:13:55PM +0100, Andre Przywara wrote:
>      >>>>> On 04/15/2013 11:52 AM, Alexander Spyridakis wrote:
>      >>>>>> I've run on this problem before, while trying to run KVM
>     guests on
>      >> A7
>      >>>>>> cores.
>      >>>>>>
>      >>>>>> For some reason the 3rd A7 hangs in arch/arm/kvm/init.S, on the
>      >>>>>> instruction that updates HSCTLR between the two isbs on
>      >> __do_hyp_init
>      >>>>>> (mcr p15, 4, r0, c1, c0, 0). If you boot the system with
>     maxcpus=4
>      >>>>>> then
>      >>>>>> init_hyp_mode() will not hang on the A7 cluster. Other than that
>      >> from
>      >>>>>> my
>      >>>>>> limited testing KVM on A7 works on a usual linux guest. I also
>     tried
>      >>>>>> to
>      >>>>>> only boot the 3rd A7 core to rule out any racing issues, but
>     still
>      >> the
>      >>>>>> same behaviour applies.
>      >>>>>
>      >>>>> Could well be the same issue here. I chased it down till CPU
>     2 goes
>      >> into
>      >>>>> HYP mode to do the initialization.
>      >>>>> I am running with maxcpus=3 (this increases the likelyhood that
>      >>>>> kvm_target_cpu() runs on an A15), so CPU #2 is the only one A7.
>      >>>>> As the HYP mode exception table is empty except for the HVC
>     trap, it
>      >> may
>      >>>>> be looping here. I am trying now to get the PC of the faulty
>      >>>>> instruction.
>      >>>>
>      >>>> Yes, it sounds like you're taking a recursive fault because the
>     vectors
>      >>>> aren't installed yet. Is there any chance you can find out
>     what value
>      >>>> you end
>      >>>> up writing (or trying to write) to the HSCTLR please?
>      >>>>
>      >>> Actually I'm a little confused, wasn't Andre seeing a halt on
>     an A15
>      >>> cpu, not an A7? Or is the theory that an A7 locks up and the
>     calling
>      >>> A15 hangs on the SMP call to cpu_init_hyp_mode, waiting for the
>     A7 to
>      >>> complete?
>      >>
>      >> Yes, A15 hanging, not A7. That's why I'm strongly opposed to this
>     patch.
>      >> I'm pretty sure the A7s only have a side effect that triggers a
>     kernel
>      >> bug
>      >> on the A15 side. Before taking *any* patch around this, we should
>      >> understand the issue fully, and not start patching random stuff just
>      >> because Linus is going to tag 3.9.
>      >
>      > I think there is a misunderstanding. The RCU watchdog was complaining
>      > because the A15 wasn't making any progress. As Christoffer said,
>     this is
>
>      > because it was waiting for CPU 2 to return from the SMP call. It is
>      > actually the A7 hanging inside HYP mode.
>      > I tried some ways to get information out of there, but had no luck so
>      > far. The different mapping between HYP and SVC doesn't make it
>     easy to
>      > dump some variables, but I am still working on it (but only half
>     steam
>
>     You could force a full mapping of the kernel text in HYP. Ugly, but
>     should
>     work.
>
>      > because I am home looking after my sick daughter). So for now I
>     assume
>      > that it is the HSCTLR setting Alexander observed already.
>
>     I'll give it a go today or tomorrow, depending how quickly I can get rid
>     of my backlog after a couple of days off work.
>
>     Assuming this is an A7 handing on HSCTLR access, it should be pretty
>     easy
>     to narrow down by booting only on the A7s, leaving the A15s held in
>     reset.
>
>
> You could also try installing a vector handler early and detect faults,
> and add an alternative return path from the init function with some
> error reporting value in r0 or something like that, just for debugging,
> naturally, but that could be a way to detect if we really are taking
> recursive faults here.

OK, I added code to return earlier on CPUs not from cluster 0.
Indeed it hangs in the HSCR write. The two A15s pass this instruction, 
writing 0x30c5187F into the register.
This means all the fixed bits for A15 correctly, C,A,M and I set and 
WXN, EE, TE cleared. FI was also cleared
The A7 wanted to write the very same value. I tried to set bit 21, which 
kind of the A7 TRM hints to do: but no change.
Before the HSCLTR write, the register reads 0x30c50878, with SCTLR being 
0x30c5387d.
So the code wants to set M, A, C and I in HSCLTR. Interestingly SCTLR 
has the V bits set, could that be an issue?

Regards,
Andre.



From linux at arm.linux.org.uk  Fri Apr 19 09:06:59 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Fri, 19 Apr 2013 14:06:59 +0100
Subject: [PATCH] ARM: pci: pass a parent to pci_common_init()
In-Reply-To: <201304121501.48866.arnd@arndb.de>
References: <1365719096-11639-1-git-send-email-linus.walleij@linaro.org>
 <201304121326.56030.arnd@arndb.de> <20130412120538.GA32488@arm.com>
 <201304121501.48866.arnd@arndb.de>
Message-ID: <20130419130659.GM14496@n2100.arm.linux.org.uk>

On Fri, Apr 12, 2013 at 03:01:48PM +0200, Arnd Bergmann wrote:
> On Friday 12 April 2013, Andrew Murray wrote:
> > I would also be happy with this. Though alternatively could you
> > not just add a struct device to hw_pci? Then change pcibios_init_hw
> > to use hw->device instead of NULL?
> > 
> 
> I think struct hw_pci is meant to be statically defined, so that would
> not work if you need the same hw_pci for two host bridge devices.

The hw_pci structure is only referenced by the setup functions, and
never referred to again.  Anything of any relevance that is needed
later is copied out of that structure into others (like pci_sys_data).


From itooo at itooo.com  Fri Apr 19 09:07:40 2013
From: itooo at itooo.com (Greg)
Date: Fri, 19 Apr 2013 15:07:40 +0200
Subject: MVEBU and MVNETA driver
Message-ID: <5171419C.2090003@itooo.com>

Hello All,

This is my first post there, let me introduce myself: I am an embedded 
systems designer working in a French ISP. My goal is to design devices 
with a minimalistic software package installed that system/software 
engineers can use as a base for their work. Said in a few words : I'm 
not the kernel expert but I have some knowledge of it.

That being said, I'm currently working with a Marvell ArmadaXP SoC and 
I'm performing the transition from Marvell "Linux Support Package" to 
MVEBU in the 3.8.8 Vanilla.
Having the system up and running was actually quite easy, Thomas 
Petazzoni and his team did a very good job!

I'm facing a problem with ethernet transmission (reception -seems- to be 
fine), at best is it slow (~90Mbps), at worst the kernel OOPSes at 
various locations dealing with memory (tcp_v4_destroy_sock, free_block 
and skb_put seen so far) and ends up crashing right after.
I'm simply using iperf to generate traffic and the system has been 
stable for a while with Marvell's LSP so I can say with confidence the 
hardware is pretty stable.

My question is fairly simple : before complaining about the network 
driver (which might not even be involved in this), what is the starting 
point to gather more information about this problem and what data should 
I provide you to help you advising me ?

Thank you very much!


From w at 1wt.eu  Fri Apr 19 09:12:37 2013
From: w at 1wt.eu (Willy Tarreau)
Date: Fri, 19 Apr 2013 15:12:37 +0200
Subject: MVEBU and MVNETA driver
In-Reply-To: <5171419C.2090003@itooo.com>
References: <5171419C.2090003@itooo.com>
Message-ID: <20130419131237.GC22440@1wt.eu>

Hi Greg,

On Fri, Apr 19, 2013 at 03:07:40PM +0200, Greg wrote:
> Hello All,
> 
> This is my first post there, let me introduce myself: I am an embedded 
> systems designer working in a French ISP. My goal is to design devices 
> with a minimalistic software package installed that system/software 
> engineers can use as a base for their work. Said in a few words : I'm 
> not the kernel expert but I have some knowledge of it.
> 
> That being said, I'm currently working with a Marvell ArmadaXP SoC and 
> I'm performing the transition from Marvell "Linux Support Package" to 
> MVEBU in the 3.8.8 Vanilla.
> Having the system up and running was actually quite easy, Thomas 
> Petazzoni and his team did a very good job!
> 
> I'm facing a problem with ethernet transmission (reception -seems- to be 
> fine), at best is it slow (~90Mbps), at worst the kernel OOPSes at 
> various locations dealing with memory (tcp_v4_destroy_sock, free_block 
> and skb_put seen so far) and ends up crashing right after.
> I'm simply using iperf to generate traffic and the system has been 
> stable for a while with Marvell's LSP so I can say with confidence the 
> hardware is pretty stable.
> 
> My question is fairly simple : before complaining about the network 
> driver (which might not even be involved in this), what is the starting 
> point to gather more information about this problem and what data should 
> I provide you to help you advising me ?

You need to get the following commit from mainline to fix this issue :

   ee40a116ebf139f900c3d2e6febb8388738e96d0

Cheers,
Willy

PS: is it indiscrete to ask what board this is ?




From linux at arm.linux.org.uk  Fri Apr 19 09:19:17 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Fri, 19 Apr 2013 14:19:17 +0100
Subject: [PATCH] ARM: pci: pass a parent to pci_common_init()
In-Reply-To: <20130412134811.GA26188@arm.com>
References: <1365719096-11639-1-git-send-email-linus.walleij@linaro.org>
 <201304121326.56030.arnd@arndb.de> <20130412120538.GA32488@arm.com>
 <201304121501.48866.arnd@arndb.de> <20130412134811.GA26188@arm.com>
Message-ID: <20130419131917.GN14496@n2100.arm.linux.org.uk>

On Fri, Apr 12, 2013 at 02:48:11PM +0100, Andrew Murray wrote:
> Yes, though the new PCIe host/bridge drivers with DT support all seem to call
> pci_common_init at probe with a non-statically defined hw_pci with the
> nr_controllers always set to 1 (meaning that pci_common_init can be called
> multiple times). Also hw_pci now has a field for private_data anyway which
> breaks this assumption...
> 
> Is there an argument for removing hw_pci or at least .nr_controllers and call
> pci_common_init multiple times (as is potential current use case for DT PCI
> drivers)?

Well, I notice that there's bunches of code which have been introduced
post my cleanup of the PCI stuff which insist on doing their stuff using
the pre-cleanup ways...  I guess I need to go through and fix peoples
stuff up again in this area when I finish reading the mail backlog...

The idea behind bios32.c is that all buses get scanned and _then_ setup,
rather than each get scanned and setup in sequence.  This allows for
a variety of setups where the buses may share a space - it allows the
scan to be done, then the postinit hook to be called which can then do
any post-processing prior to resources being setup.


From linux at arm.linux.org.uk  Fri Apr 19 09:28:49 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Fri, 19 Apr 2013 14:28:49 +0100
Subject: [PATCH 1/2] ARM: default machine descriptor for multiplatform
In-Reply-To: <1365779468-116419-1-git-send-email-arnd@arndb.de>
References: <1365779468-116419-1-git-send-email-arnd@arndb.de>
Message-ID: <20130419132848.GO14496@n2100.arm.linux.org.uk>

On Fri, Apr 12, 2013 at 05:11:07PM +0200, Arnd Bergmann wrote:
> @@ -752,7 +761,7 @@ void __init setup_arch(char **cmdline_p)
>  
>  	setup_processor();
>  	mdesc = setup_machine_fdt(__atags_pointer);
> -	if (!mdesc)
> +	if (!mdesc && __machine_arch_type != ~0)
>  		mdesc = setup_machine_tags(__atags_pointer, __machine_arch_type);
>  	machine_desc = mdesc;
>  	machine_name = mdesc->name;

If mdesc is NULL and __machine_arch_type is ~0, then mdesc remains NULL.
That means machine_desc is NULL (which is probably very bad), and the
initialization of machine_name causes a NULL pointer dereference.

This is clearly wrong.  mdesc must never be NULL if you're using FDT
here, so the original code should be fine.


From linux at arm.linux.org.uk  Fri Apr 19 09:34:03 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Fri, 19 Apr 2013 14:34:03 +0100
Subject: [PATCH v3 4/7] ARM: KVM: enforce maximum size for identity
 mapped code
In-Reply-To: <1365779932-20322-5-git-send-email-marc.zyngier@arm.com>
References: <1365779932-20322-1-git-send-email-marc.zyngier@arm.com>
 <1365779932-20322-5-git-send-email-marc.zyngier@arm.com>
Message-ID: <20130419133403.GP14496@n2100.arm.linux.org.uk>

On Fri, Apr 12, 2013 at 04:18:49PM +0100, Marc Zyngier wrote:
> We're about to move to an init procedure where we rely on the
> fact that the init code fits in a single page. Make sure we
> align the idmap text on a vector alignment, and that the code is
> not bigger than a single page.
> 
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> ---
>  arch/arm/kernel/vmlinux.lds.S | 7 ++++++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
> index b571484..a871b8e 100644
> --- a/arch/arm/kernel/vmlinux.lds.S
> +++ b/arch/arm/kernel/vmlinux.lds.S
> @@ -20,7 +20,7 @@
>  	VMLINUX_SYMBOL(__idmap_text_start) = .;				\
>  	*(.idmap.text)							\
>  	VMLINUX_SYMBOL(__idmap_text_end) = .;				\
> -	ALIGN_FUNCTION();						\
> +	. = ALIGN(32);							\

It would be a good idea to document what this 32 is.


From arnd at arndb.de  Fri Apr 19 09:36:17 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 19 Apr 2013 15:36:17 +0200
Subject: [PATCH v3 00/10] ARM: exynos multiplatform series, part 1
In-Reply-To: <1365716245-99231-1-git-send-email-arnd@arndb.de>
References: <1365716245-99231-1-git-send-email-arnd@arndb.de>
Message-ID: <201304191536.17796.arnd@arndb.de>

On Thursday 11 April 2013, Arnd Bergmann wrote:
> These are the patches that I would like to apply directly to
> the arm-soc next/multiplatform branch, unless you have any
> objections. This would get all the simple stuff out of the
> way, and I don't think there is a big risk of introducing
> regressions with these.
> 
> A lot of the other patches have already been merged into
> subsystem trees. After this series in in arm-soc, what is
> left comes down to
> 
> * The ASoC conversion to dmaengine won't make it unless someone
>   who knows that code better steps up to do it right away. This
>   means that we won't have audio in a 3.10 multiplatform kernel
>   on Exynos, but it will still work for users that don't enable
>   multiplatform.
> 
> * The irqchip (combiner), clk and clksource patches are all based
>   on top   of other changesets we pulled in from your trees, so I
>   would not make them part of the next/multiplatform branch. We can
>   apply them on top of the next/drivers branch once they are
>   tested successfully.
> 
> * A trivial patch is needed in the end to actually make
>   CONFIG_ARCH_EXYNOS visible in multiplatform configurations.
>   We will do that as a separate patch once everything else is
>   there.
> 
> Please provide an ACK so I can put this into arm-soc, or let
> me know if I screwed up somewhere.

No reply?

I'm putting them into the next/multiplatform branch now, with
the exception of the i2c patch that is already in the i2c
tree.

I've tested this on the Arndale board and am putting it into
the next/multiplatform branch now as a stepping stone for
part two, which will be a late branch at best, if we decide
to merge it in 3.10.

	Arnd


From linux at arm.linux.org.uk  Fri Apr 19 09:36:58 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Fri, 19 Apr 2013 14:36:58 +0100
Subject: [PATCH v3 6/7] ARM: KVM: switch to a dual-step HYP init code
In-Reply-To: <1365779932-20322-7-git-send-email-marc.zyngier@arm.com>
References: <1365779932-20322-1-git-send-email-marc.zyngier@arm.com>
 <1365779932-20322-7-git-send-email-marc.zyngier@arm.com>
Message-ID: <20130419133658.GQ14496@n2100.arm.linux.org.uk>

On Fri, Apr 12, 2013 at 04:18:51PM +0100, Marc Zyngier wrote:
> @@ -247,7 +265,11 @@ static int __create_hyp_mappings(pgd_t *pgdp,
>  				goto out;
>  			}
>  			pud_populate(NULL, pud, pmd);
> +<<<<<<< HEAD
>  			get_page(virt_to_page(pud));
> +=======
> +			kvm_flush_dcache_to_poc(pud, sizeof(*pud));
> +>>>>>>> 180de35... ARM: KVM: switch to a dual-step HYP init code

I don't think you want this in your patch... and as no one else spotted
this, has anyone looked at this patch set yet?


From linux at roeck-us.net  Fri Apr 19 09:37:28 2013
From: linux at roeck-us.net (Guenter Roeck)
Date: Fri, 19 Apr 2013 06:37:28 -0700
Subject: [PATCH 1/3] Add support for GMT G72/G763 PWM fan controller
In-Reply-To: <87y5ceahas.fsf@natisbad.org>
References: <cover.1366322287.git.arno@natisbad.org>
 <4f4a821bbc61e2da28fd70553fd717ada255097d.1366322287.git.arno@natisbad.org>
 <20130419055054.GD18115@lunn.ch> <87y5ceahas.fsf@natisbad.org>
Message-ID: <20130419133728.GA8445@roeck-us.net>

On Fri, Apr 19, 2013 at 01:30:51PM +0200, Arnaud Ebalard wrote:
> Hi,
> 
> Andrew Lunn <andrew at lunn.ch> writes:
> 
> > Hi Arnaud
> >
> >> +static DEVICE_ATTR(pwm1, S_IWUSR | S_IRUGO, get_pwm, set_pwm);
> >> +static DEVICE_ATTR(pwm1_polarity, S_IWUSR | S_IRUGO,
> >> +		   get_pwm_polarity, set_pwm_polarity);
> >> +static DEVICE_ATTR(pwm1_mode, S_IWUSR | S_IRUGO,
> >> +		   get_pwm_mode, set_pwm_mode);
> >> +static DEVICE_ATTR(pwm1_enable, S_IWUSR | S_IRUGO,
> >> +		   get_speed_control_mode, set_speed_control_mode);
> >> +static DEVICE_ATTR(pwm1_freq, S_IWUSR | S_IRUGO,
> >> +		   get_pwm_freq, set_pwm_freq);
> >> +
> >> +static DEVICE_ATTR(fan1_input, S_IRUGO, get_fan_rpm, NULL);
> >> +static DEVICE_ATTR(fan1_alarm, S_IRUGO, get_fan_ooc, NULL);
> >> +static DEVICE_ATTR(fan1_alarm_detection, S_IWUSR | S_IRUGO,
> >> +		   get_fan_ooc_detection, set_fan_ooc_detection);
> >> +static DEVICE_ATTR(fan1_fault, S_IRUGO, get_fan_failure, NULL);
> >> +static DEVICE_ATTR(fan1_fault_detection, S_IWUSR | S_IRUGO,
> >> +		   get_fan_failure_detection, set_fan_failure_detection);
> >> +static DEVICE_ATTR(fan1_target, S_IWUSR | S_IRUGO,
> >> +		   get_fan_target, set_fan_target);
> >> +static DEVICE_ATTR(fan1_pulses, S_IWUSR | S_IRUGO,
> >> +		   get_fan_pulses, set_fan_pulses);
> >> +static DEVICE_ATTR(fan1_div, S_IWUSR | S_IRUGO,
> >> +		   get_fan_clk_div, set_fan_clk_div);
> >> +static DEVICE_ATTR(fan1_gear_mode, S_IWUSR | S_IRUGO,
> >> +		   get_fan_gear_mode, set_fan_gear_mode);
> >> +static DEVICE_ATTR(fan1_startup_voltage, S_IWUSR | S_IRUGO,
> >> +		   get_fan_startup_voltage, set_fan_startup_voltage);
> >
> > It is normal to use SENSOR_ATTR, not DEVICE_ATTR. Take a look at the
> > existing fan drivers.
> 
> I will take a look and use SENSOR_ATTR if it is the expected way. For
> the records, the g760a.c which I used as basis uses DEVICE_ATTR ;-)
> 
You only need SENSOR_ATTR if you have an index parameter. Otherwise DEVICE_ATTR
is just fine. I would actually reject the patch if I notice that it uses
SENSOR_ATTR without need for a parameter. Besides, in the context used,
it would probably be SENSOR_DEVICE_ATTR.

> > I also think a lot of these are not needed. They are fixed properties
> > of the board and cannot change dynamically. They are set once using DT
> > and user space does not need to care.
> 
> I added those knobs for a simple reason: I don't have all the various
> characteristics of the target platform I am working on (Netgear
> ReadyNAS Duo v2) and needed to be able to test various values w/o
> rebooting to get those rights. I thought this knobs would be useful for
> people with the same issue (for instance, the new ReadyNAS 102 also has
> a G762) and would not hurt.
> 
Testing is not a reason to add non-standard attributes.

Thanks,
Guenter

> Anyway, I will split the patch in two parts and keep the useless knobs
> on my side.
> 
> Thanks for your feedback,
> 
> Cheers,
> 
> a+
> 


From linus.walleij at linaro.org  Fri Apr 19 09:47:48 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Fri, 19 Apr 2013 15:47:48 +0200
Subject: [PATCH v3] pinctrl/pinconfig: add debug interface
In-Reply-To: <20130418105246.GO14496@n2100.arm.linux.org.uk>
References: <1366281314-14613-1-git-send-email-linus.walleij@stericsson.com>
 <20130418105246.GO14496@n2100.arm.linux.org.uk>
Message-ID: <CACRpkdbEuuy62h+szbyFiFkFBiHx21oSDYBMtkzWkv7PJ32+xQ@mail.gmail.com>

On Thu, Apr 18, 2013 at 12:52 PM, Russell King - ARM Linux
<linux at arm.linux.org.uk> wrote:
> On Thu, Apr 18, 2013 at 12:35:14PM +0200, Linus Walleij wrote:
>> +             if (map->type != dbg->map_type)
>> +                     continue;
>> +             if (!!strcmp(map->dev_name, dbg->dev_name))
>
> !! is pointless in this context - if() evaluates any non-zero value as
> true, so there's no point making the code more complicated by trying to
> convert it to a false/true value first.

I fixed this up and applied it since there are no further comments.

Thanks!
Linus Walleij


From u.kleine-koenig at pengutronix.de  Fri Apr 19 09:51:07 2013
From: u.kleine-koenig at pengutronix.de (Uwe =?iso-8859-1?Q?Kleine-K=F6nig?=)
Date: Fri, 19 Apr 2013 15:51:07 +0200
Subject: [PATCH v3] irqchip: Add support for ARMv7-M's NVIC
In-Reply-To: <201304181138.13599.arnd@arndb.de>
References: <1366214540-31166-1-git-send-email-u.kleine-koenig@pengutronix.de>
 <201304181101.13644.arnd@arndb.de>
 <20130418092436.GB21099@pengutronix.de>
 <201304181138.13599.arnd@arndb.de>
Message-ID: <20130419135107.GD15233@pengutronix.de>

On Thu, Apr 18, 2013 at 11:38:13AM +0200, Arnd Bergmann wrote:
> On Thursday 18 April 2013, Uwe Kleine-K?nig wrote:
> > That is, there are (INTLINESNUM + 1) * 32 irqs for INTLINESNUM < 15. For
> > INTLINESNUM == 15 there are only 496 and not 16 * 32 == 512. That's the
> > same on the gic (just with bigger numbers).
> 
> Ok, but since you are now using a linear domain, it doesn't actually hurt
> to register 512 in that special case, right?
Well, it depends if allocating space for 16 unused unsigned ints hurts
(maybe not). And it makes mapping some irqs successfull while the irq
doesn't really exist. But probably this doesn't hurt either because the
problem already exists.

I don't care much. Is there another advantage beside saving a few source
lines/instructions?

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |


From s.nawrocki at samsung.com  Fri Apr 19 09:51:36 2013
From: s.nawrocki at samsung.com (Sylwester Nawrocki)
Date: Fri, 19 Apr 2013 15:51:36 +0200
Subject: [PATCH v3 00/10] ARM: exynos multiplatform series, part 1
In-Reply-To: <201304191536.17796.arnd@arndb.de>
References: <1365716245-99231-1-git-send-email-arnd@arndb.de>
 <201304191536.17796.arnd@arndb.de>
Message-ID: <51714BE8.8000401@samsung.com>

On 04/19/2013 03:36 PM, Arnd Bergmann wrote:
> On Thursday 11 April 2013, Arnd Bergmann wrote:
>> These are the patches that I would like to apply directly to
>> the arm-soc next/multiplatform branch, unless you have any
>> objections. This would get all the simple stuff out of the
>> way, and I don't think there is a big risk of introducing
>> regressions with these.
>>
>> A lot of the other patches have already been merged into
>> subsystem trees. After this series in in arm-soc, what is
>> left comes down to
>>
>> * The ASoC conversion to dmaengine won't make it unless someone
>>   who knows that code better steps up to do it right away. This
>>   means that we won't have audio in a 3.10 multiplatform kernel
>>   on Exynos, but it will still work for users that don't enable
>>   multiplatform.
>>
>> * The irqchip (combiner), clk and clksource patches are all based
>>   on top   of other changesets we pulled in from your trees, so I
>>   would not make them part of the next/multiplatform branch. We can
>>   apply them on top of the next/drivers branch once they are
>>   tested successfully.
>>
>> * A trivial patch is needed in the end to actually make
>>   CONFIG_ARCH_EXYNOS visible in multiplatform configurations.
>>   We will do that as a separate patch once everything else is
>>   there.
>>
>> Please provide an ACK so I can put this into arm-soc, or let
>> me know if I screwed up somewhere.
> 
> No reply?
> 
> I'm putting them into the next/multiplatform branch now, with
> the exception of the i2c patch that is already in the i2c
> tree.
> 
> I've tested this on the Arndale board and am putting it into
> the next/multiplatform branch now as a stepping stone for
> part two, which will be a late branch at best, if we decide
> to merge it in 3.10.

I've reviewed this patch series and nothing concerning jumps.
Please feel free to add

Reviewed-by: Sylwester Nawrocki <s.nawrocki at samsung.com>

if still possible.

Thanks.

Sylwester


From sergei.shtylyov at cogentembedded.com  Fri Apr 19 09:53:56 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Fri, 19 Apr 2013 17:53:56 +0400
Subject: [PATCH 1/5] ARM: at91: at91sam9x5 RTC is not compatible with
 at91rm9200 one
In-Reply-To: <864f10566b35864d469f6ff2913b9afaa0c69350.1366289869.git.nicolas.ferre@atmel.com>
References: <cover.1366289869.git.nicolas.ferre@atmel.com>
 <864f10566b35864d469f6ff2913b9afaa0c69350.1366289869.git.nicolas.ferre@atmel.com>
Message-ID: <51714C74.2030907@cogentembedded.com>

Hello.

On 18-04-2013 17:01, Nicolas Ferre wrote:

> Due to a bug with RTC IMR, we cannot consider at91sam9x5 RTC compatible
> with the previous one. Modify DT compatibility string, even if the driver
> is not yet modified to take it into account.

> Signed-off-by: Nicolas Ferre <nicolas.ferre at atmel.com>
> ---
>   arch/arm/boot/dts/at91sam9x5.dtsi | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)

> diff --git a/arch/arm/boot/dts/at91sam9x5.dtsi b/arch/arm/boot/dts/at91sam9x5.dtsi
> index a3d4464..58747f3 100644
> --- a/arch/arm/boot/dts/at91sam9x5.dtsi
> +++ b/arch/arm/boot/dts/at91sam9x5.dtsi
> @@ -564,7 +564,7 @@
>   			};
>
>   			rtc at fffffeb0 {
> -				compatible = "atmel,at91rm9200-rtc";
> +				compatible = "atmel,at91sam9x5-rtc";

    Do not use wildcards in the "compatible" prop values (I guess 'x' is a 
wildcard).

WBR, Sergei



From olof at lixom.net  Fri Apr 19 10:01:28 2013
From: olof at lixom.net (Olof Johansson)
Date: Fri, 19 Apr 2013 07:01:28 -0700
Subject: linux-next: build failure after merge of the arm-soc tree
In-Reply-To: <20130419164636.0d2405ca5fd927f1ba31fe40@canb.auug.org.au>
References: <20130419164636.0d2405ca5fd927f1ba31fe40@canb.auug.org.au>
Message-ID: <CAOesGMhUTyPdNo=yaRqEv+Zhf7ga8e-R0asbnuje_LioWbqsgg@mail.gmail.com>

On Thu, Apr 18, 2013 at 11:46 PM, Stephen Rothwell <sfr at canb.auug.org.au> wrote:
> Hi all,
>
> After merging the arm-soc tree, today's linux-next build (powerpc ppc64_defconfig)
> failed like this:
>
> powerpc64-linux-ld: cannot find drivers/pci/host/built-in.o: No such file or directory
>
> Caused by commit 9ecbe03ae85b ("pci: infrastructure to add drivers in
> drivers/pci/host").
>
> I have used the arm-soc tree from next-20130418 for today.

Sorry about that, I'll drop the branch that brought in the of_pci
consolidation from our repo.


-Olof


From linux at arm.linux.org.uk  Fri Apr 19 10:03:57 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Fri, 19 Apr 2013 15:03:57 +0100
Subject: [PATCH 1/2] GPIO: clps711x: Rewrite driver for using generic
 GPIO code
In-Reply-To: <1365826900-30136-1-git-send-email-shc_work@mail.ru>
References: <1365826900-30136-1-git-send-email-shc_work@mail.ru>
Message-ID: <20130419140357.GR14496@n2100.arm.linux.org.uk>

On Sat, Apr 13, 2013 at 08:21:39AM +0400, Alexander Shiyan wrote:
> +static void __init clps711x_add_gpio(void)
> +{
> +	const struct resource clps711x_gpio0_res[] = {
> +		DEFINE_RES_MEM(PADR, SZ_1),
> +		DEFINE_RES_MEM(PADDR, SZ_1),
> +	};
> +	const struct resource clps711x_gpio1_res[] = {
> +		DEFINE_RES_MEM(PBDR, SZ_1),
> +		DEFINE_RES_MEM(PBDDR, SZ_1),
> +	};
> +	const struct resource clps711x_gpio2_res[] = {
> +		DEFINE_RES_MEM(PCDR, SZ_1),
> +		DEFINE_RES_MEM(PCDDR, SZ_1),
> +	};
> +	const struct resource clps711x_gpio3_res[] = {
> +		DEFINE_RES_MEM(PDDR, SZ_1),
> +		DEFINE_RES_MEM(PDDDR, SZ_1),
> +	};
> +	const struct resource clps711x_gpio4_res[] = {
> +		DEFINE_RES_MEM(PEDR, SZ_1),
> +		DEFINE_RES_MEM(PEDDR, SZ_1),
> +	};

Don't do this - this is incredibly wasteful.

C lesson 1: do not put unmodified initialised structures onto the stack.

What the C compiler will do with the above is exactly the same as this
for each structure:

static const struct resource private_clps711x_gpio4_res[] = {
	DEFINE_RES_MEM(PEDR, SZ_1),
	DEFINE_RES_MEM(PEDDR, SZ_1),
};

static void __init clps711x_add_gpio(void)
{
	const struct resource clps711x_gpio4_res[] = private_clps711x_gpio4_res;
	...

which will in itself be a call out to memcpy, or an inlined memcpy.  Now
do you see why it's wasteful?  You might as well write the thing in that
way to start with and safe the additional code to copy the structures.

The other way to do this, which will probably be far more space efficient:

static phys_addr_t gpio_addrs[][2] = {
	{ PADR, PADDR },
	{ PBDR, PBDDR },
...
};

static void __init clps711x_add_gpio(void)
{
	struct resource gpio_res[2];
	unsigned i;

	gpio_res[0].flags = IORESOURCE_MEM;
	gpio_res[1].flags = IORESOURCE_MEM;

	for (i = 0; i < ARRAY_SIZE(gpio_addrs); i++) {
		gpio_res[0].start = gpio_addrs[i][0];
		gpio_res[0].end = gpio_res[0].start;
		gpio_res[1].start = gpio_addrs[i][1];
		gpio_res[1].end = gpio_res[1].start;

		platform_device_register_simple("clps711x-gpio", i,
					gpio_res, ARRAY_SIZE(gpio_res));
	}
}

which results in smaller storage and most probably also smaller code size
too.


From khilman at linaro.org  Fri Apr 19 10:05:52 2013
From: khilman at linaro.org (Kevin Hilman)
Date: Fri, 19 Apr 2013 07:05:52 -0700
Subject: [PATCH] gpio/omap: ensure gpio context is initialised
In-Reply-To: <5170E4EE.7090100@ti.com> (Santosh Shilimkar's message of "Fri,
 19 Apr 2013 12:02:14 +0530")
References: <1366230707-32681-1-git-send-email-jon-hunter@ti.com>
 <871ua734mv.fsf@linaro.org> <51707D7C.1050600@ti.com>
 <5170911C.6010507@ti.com> <51709499.8030208@ti.com>
 <5170E4EE.7090100@ti.com>
Message-ID: <87sj2mzkcf.fsf@linaro.org>

Santosh Shilimkar <santosh.shilimkar at ti.com> writes:

> On Friday 19 April 2013 06:19 AM, Jon Hunter wrote:
>> 
>> On 04/18/2013 07:34 PM, Jon Hunter wrote:
>>>
>>> On 04/18/2013 06:10 PM, Jon Hunter wrote:
>>>> On 04/18/2013 04:34 PM, Kevin Hilman wrote:
>>>
>>> ...
>>>
>>>>> Why not just init context right here if bank->loses_context &&
>>>>> !bank->context_valid?
>>>
>>> I really like this idea a lot. It can really clean-up the code
>>> and really make it much more readable. Before we were playing 
>>> some tricks with when we init'ed the get_context_loss_count()
>>> function pointer. How about the below?
>>>
>>> Tony, care to re-test?
>>>
>>> Cheers
>>> Jon
>>>
>>> From d7a940531d354e6be5e16ee50fa8344041df963a Mon Sep 17 00:00:00 2001
>>> From: Jon Hunter <jon-hunter at ti.com>
>>> Date: Mon, 15 Apr 2013 13:06:54 -0500
>>> Subject: [PATCH] gpio/omap: ensure gpio context is initialised
>>>
>>> Commit a2797be (gpio/omap: force restore if context loss is not
>>> detectable) broke gpio support for OMAP when booting with device-tree
>>> because a restore of the gpio context being performed without ever
>>> initialising the gpio context. In other words, the context restored was
>>> bad.
>>>
>>> This problem could also occur in the non device-tree case, however, it
>>> is much less likely because when booting without device-tree we can
>>> detect context loss via a platform specific API and so context restore
>>> is performed less often.
>>>
>>> Nevertheless we should ensure that the gpio context is initialised
>>> on the first pm-runtime resume for gpio banks that could lose their
>>> state regardless of whether we are booting with device-tree or not.
>>>
>>> The context loss count was being initialised on the first pm-runtime
>>> suspend following a resume, by populating the get_count_loss_count()
>>> function pointer after the first pm-runtime resume. To make the code
>>> more readable and logical, initialise the context loss count on the
>>> first pm-runtime resume if the context is not yet valid.
>>>
>>> Reported-by: Tony Lindgren <tony at atomide.com>
>>> Signed-off-by: Jon Hunter <jon-hunter at ti.com>
>>> ---
>>>  drivers/gpio/gpio-omap.c |   45 ++++++++++++++++++++++++++++++++++++++++++---
>>>  1 file changed, 42 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
>>> index 0557529..db3c732 100644
>>> --- a/drivers/gpio/gpio-omap.c
>>> +++ b/drivers/gpio/gpio-omap.c
>>> @@ -70,6 +70,7 @@ struct gpio_bank {
>>>  	bool is_mpuio;
>>>  	bool dbck_flag;
>>>  	bool loses_context;
>>> +	bool context_valid;
>>>  	int stride;
>>>  	u32 width;
>>>  	int context_loss_count;
>>> @@ -1129,6 +1130,7 @@ static int omap_gpio_probe(struct platform_device *pdev)
>>>  			bank->loses_context = true;
>>>  	} else {
>>>  		bank->loses_context = pdata->loses_context;
>>> +		bank->get_context_loss_count = pdata->get_context_loss_count;
>> 
>> Still need to check loses_context for populating
>> get_context_loss_count here. Updated patch below.
>> 
>> Jon
>> 
>> From d02ef7b7dfcf8e13bf019aedfdecb38ca3c6749f Mon Sep 17 00:00:00 2001
>> From: Jon Hunter <jon-hunter at ti.com>
>> Date: Mon, 15 Apr 2013 13:06:54 -0500
>> Subject: [PATCH] gpio/omap: ensure gpio context is initialised
>> 
>> Commit a2797be (gpio/omap: force restore if context loss is not
>> detectable) broke gpio support for OMAP when booting with device-tree
>> because a restore of the gpio context being performed without ever
>> initialising the gpio context. In other words, the context restored was
>> bad.
>> 
>> This problem could also occur in the non device-tree case, however, it
>> is much less likely because when booting without device-tree we can
>> detect context loss via a platform specific API and so context restore
>> is performed less often.
>> 
>> Nevertheless we should ensure that the gpio context is initialised
>> on the first pm-runtime resume for gpio banks that could lose their
>> state regardless of whether we are booting with device-tree or not.
>> 
>> The context loss count was being initialised on the first pm-runtime
>> suspend following a resume, by populating the get_count_loss_count()
>> function pointer after the first pm-runtime resume. To make the code
>> more readable and logical, initialise the context loss count on the
>> first pm-runtime resume if the context is not yet valid.
>> 
>> Reported-by: Tony Lindgren <tony at atomide.com>
>> Signed-off-by: Jon Hunter <jon-hunter at ti.com>
>> ---
> This version looks better than the first one for sure. I am still not
> happy with per bank "context_valid" flag whose job just ends after
> the probe. 

Assuming this driver could become a module someday (not terribly likely,
I know), but context_valid would have meaning for each module reload.

> But then I do agree with you about the global flag might
> be fragile and less maintainable.
>
> So, FWIW,
> Acked-by: Santosh Shilimkar<santosh.shilimkar at ti.com>

Yes, this version is more readable.  Thanks for the update.

Reviewed-by: Kevin Hilman <khilman at linaro.org>


From nicolas.ferre at atmel.com  Fri Apr 19 10:05:59 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Fri, 19 Apr 2013 16:05:59 +0200
Subject: [PATCH 1/5] ARM: at91: at91sam9x5 RTC is not compatible with
 at91rm9200 one
In-Reply-To: <51714C74.2030907@cogentembedded.com>
References: <cover.1366289869.git.nicolas.ferre@atmel.com>
 <864f10566b35864d469f6ff2913b9afaa0c69350.1366289869.git.nicolas.ferre@atmel.com>
 <51714C74.2030907@cogentembedded.com>
Message-ID: <51714F47.5040006@atmel.com>

On 04/19/2013 03:53 PM, Sergei Shtylyov :
> Hello.
> 
> On 18-04-2013 17:01, Nicolas Ferre wrote:
> 
>> Due to a bug with RTC IMR, we cannot consider at91sam9x5 RTC compatible
>> with the previous one. Modify DT compatibility string, even if the driver
>> is not yet modified to take it into account.
> 
>> Signed-off-by: Nicolas Ferre <nicolas.ferre at atmel.com>
>> ---
>>   arch/arm/boot/dts/at91sam9x5.dtsi | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
>> diff --git a/arch/arm/boot/dts/at91sam9x5.dtsi
>> b/arch/arm/boot/dts/at91sam9x5.dtsi
>> index a3d4464..58747f3 100644
>> --- a/arch/arm/boot/dts/at91sam9x5.dtsi
>> +++ b/arch/arm/boot/dts/at91sam9x5.dtsi
>> @@ -564,7 +564,7 @@
>>               };
>>
>>               rtc at fffffeb0 {
>> -                compatible = "atmel,at91rm9200-rtc";
>> +                compatible = "atmel,at91sam9x5-rtc";
> 
>    Do not use wildcards in the "compatible" prop values (I guess 'x' is
> a wildcard).

Well, it is for naming a series of hardware, not for giving a generic
name that could cover different hardware.

In the sense of Atmel it is our way to call the at91sam9x5 series of
SoC: you will see that the code that covers these SoCs is always named
like this.
In fact, the hardware contained in these SoC cannot be different from
one flavor of the family to the other.

Best regards,
-- 
Nicolas Ferre


From linux at arm.linux.org.uk  Fri Apr 19 10:06:33 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Fri, 19 Apr 2013 15:06:33 +0100
Subject: [PATCH v3] ARM: pci: create pci_common_init_dev()
In-Reply-To: <20130413102929.GB30758@avionic-0098.mockup.avionic-design.de>
References: <1365788748-7908-1-git-send-email-linus.walleij@linaro.org>
 <20130413102929.GB30758@avionic-0098.mockup.avionic-design.de>
Message-ID: <20130419140633.GS14496@n2100.arm.linux.org.uk>

On Sat, Apr 13, 2013 at 12:29:29PM +0200, Thierry Reding wrote:
> On Fri, Apr 12, 2013 at 07:45:48PM +0200, Linus Walleij wrote:
> [...]
> > +static inline void pci_common_init(struct hw_pci *hw) {
> 
> I think that the CodingStyle rule for putting the opening brace on a
> line by itself also applies to inline functions.
> 
> Aside from that nit:
> 
> Reviewed-by: Thierry Reding <thierry.reding at avionic-design.de>

Strangely the patch never came through the mailing list.  Where can it
be found?  Obviously this is core ARM code which is being touched so
it should've been copied to me.


From marc.zyngier at arm.com  Fri Apr 19 10:07:12 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Fri, 19 Apr 2013 15:07:12 +0100
Subject: [PATCH v3 6/7] ARM: KVM: switch to a dual-step HYP init code
In-Reply-To: <20130419133658.GQ14496@n2100.arm.linux.org.uk>
References: <1365779932-20322-1-git-send-email-marc.zyngier@arm.com>
 <1365779932-20322-7-git-send-email-marc.zyngier@arm.com>
 <20130419133658.GQ14496@n2100.arm.linux.org.uk>
Message-ID: <51714F90.6060705@arm.com>

On 19/04/13 14:36, Russell King - ARM Linux wrote:
> On Fri, Apr 12, 2013 at 04:18:51PM +0100, Marc Zyngier wrote:
>> @@ -247,7 +265,11 @@ static int __create_hyp_mappings(pgd_t *pgdp,
>>  				goto out;
>>  			}
>>  			pud_populate(NULL, pud, pmd);
>> +<<<<<<< HEAD
>>  			get_page(virt_to_page(pud));
>> +=======
>> +			kvm_flush_dcache_to_poc(pud, sizeof(*pud));
>> +>>>>>>> 180de35... ARM: KVM: switch to a dual-step HYP init code
> 
> I don't think you want this in your patch... and as no one else spotted
> this, has anyone looked at this patch set yet?

I posted a revised version within minutes of posting this crap.

As far as I know, Christoffer has reviewed it.

	M.
-- 
Jazz is not dead. It just smells funny...



From marc.zyngier at arm.com  Fri Apr 19 10:07:40 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Fri, 19 Apr 2013 15:07:40 +0100
Subject: [PATCH v3 4/7] ARM: KVM: enforce maximum size for identity mapped
 code
In-Reply-To: <20130419133403.GP14496@n2100.arm.linux.org.uk>
References: <1365779932-20322-1-git-send-email-marc.zyngier@arm.com>
 <1365779932-20322-5-git-send-email-marc.zyngier@arm.com>
 <20130419133403.GP14496@n2100.arm.linux.org.uk>
Message-ID: <51714FAC.1010708@arm.com>

On 19/04/13 14:34, Russell King - ARM Linux wrote:
> On Fri, Apr 12, 2013 at 04:18:49PM +0100, Marc Zyngier wrote:
>> We're about to move to an init procedure where we rely on the
>> fact that the init code fits in a single page. Make sure we
>> align the idmap text on a vector alignment, and that the code is
>> not bigger than a single page.
>>
>> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
>> ---
>>  arch/arm/kernel/vmlinux.lds.S | 7 ++++++-
>>  1 file changed, 6 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
>> index b571484..a871b8e 100644
>> --- a/arch/arm/kernel/vmlinux.lds.S
>> +++ b/arch/arm/kernel/vmlinux.lds.S
>> @@ -20,7 +20,7 @@
>>  	VMLINUX_SYMBOL(__idmap_text_start) = .;				\
>>  	*(.idmap.text)							\
>>  	VMLINUX_SYMBOL(__idmap_text_end) = .;				\
>> -	ALIGN_FUNCTION();						\
>> +	. = ALIGN(32);							\
> 
> It would be a good idea to document what this 32 is.

Good point. I'll update this.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...



From olof at lixom.net  Fri Apr 19 10:09:40 2013
From: olof at lixom.net (Olof Johansson)
Date: Fri, 19 Apr 2013 07:09:40 -0700
Subject: [GIT PULL V2 1/4] mvebu driver changes for v3.10
In-Reply-To: <20130418053002.GB12816@quad.lixom.net>
References: <20130415182824.GN28693@titan.lakedaemon.net>
 <20130416150416.GB28693@titan.lakedaemon.net>
 <20130418053002.GB12816@quad.lixom.net>
Message-ID: <CAOesGMjD-VAZW-zL-jm65xSJkFLpzbYOdvN6-5pV1OW_vJDCWg@mail.gmail.com>

On Wed, Apr 17, 2013 at 10:30 PM, Olof Johansson <olof at lixom.net> wrote:
> On Tue, Apr 16, 2013 at 11:04:16AM -0400, Jason Cooper wrote:
>>
>> The following changes since commit 8bb9660418e05bb1845ac1a2428444d78e322cc7:
>>
>>   Linux 3.9-rc4 (2013-03-23 16:52:44 -0700)
>>
>> are available in the git repository at:
>>
>>   git://git.infradead.org/users/jcooper/linux.git tags/drivers-3.10-2
>>
>> for you to fetch changes up to ac7b07ec369324063e52c37b3fb0ad1a1814d879:
>>
>>   clk: mvebu: add more PCIe clocks for Armada XP (2013-04-16 14:47:01 +0000)
>
> Pulled, thanks.

Dropped due to build errors on powerpc64. 3.11 material now.


-Olof


From linux at arm.linux.org.uk  Fri Apr 19 10:09:38 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Fri, 19 Apr 2013 15:09:38 +0100
Subject: [PATCH 4/4] ARM: mmp: add SMP support for pxa988
In-Reply-To: <CAN1soZxCX1oUg69MTy0ZAL2vH8SOywDBaZHJ7wgnwgasxPAPdQ@mail.gmail.com>
References: <1365651547-11583-1-git-send-email-zhangwm@marvell.com>
 <CAN1soZxCX1oUg69MTy0ZAL2vH8SOywDBaZHJ7wgnwgasxPAPdQ@mail.gmail.com>
Message-ID: <20130419140938.GT14496@n2100.arm.linux.org.uk>

On Sat, Apr 13, 2013 at 09:08:12PM +0800, Haojian Zhuang wrote:
> On Thu, Apr 11, 2013 at 11:39 AM, Neil Zhang <zhangwm at marvell.com> wrote:
> > +       /*
> > +        * Synchronise with the boot thread.
> > +        */
> > +       spin_lock(&boot_lock);
> > +       spin_unlock(&boot_lock);
> Lock & unlock without protecting anything. If so, you can remove this.

... which means you don't understand what is going on in this code,
and probably didn't read the comment above this fragment.  The above
is to synchronise with the code below - again, read the comment at
the spin unlock in this function, remembering that the above code
and the code below runs concurrently on two different CPUs:

> > +static int __cpuinit mmp_boot_secondary(unsigned int cpu, struct task_struct *idle)
> > +{
> > +       unsigned long timeout;
> > +
> > +       /*
> > +        * Avoid timer calibration on slave cpus. Use the value calibrated
> > +        * on master cpu. Referenced from tegra3
> > +        */
> > +       preset_lpj = loops_per_jiffy;
> > +
> > +       /*
> > +        * set synchronisation state between this boot processor
> > +        * and the secondary one
> > +        */
> > +
> > +       spin_lock(&boot_lock);
> > +
> > +       /*
> > +        * The secondary processor is waiting to be released from
> > +        * the holding pen - release it, then wait for it to flag
> > +        * that it has been released by resetting pen_release.
> > +        *
> > +        * Note that "pen_release" is the hardware CPU ID, whereas
> > +        * "cpu" is Linux's internal ID.
> > +        */
> > +       write_pen_release(cpu);
> > +
> > +       /* reset the cpu, let it branch to the kernel entry */
> > +       mmp_cpu_power_up(cpu);
> > +
> > +       timeout = jiffies + (1 * HZ);
> > +       while (time_before(jiffies, timeout)) {
> > +               smp_rmb();
> > +               if (pen_release == -1)
> > +                       break;
> > +
> > +               udelay(10);
> > +       }
> > +
> > +       /*
> > +        * now the secondary core is starting up let it run its
> > +        * calibrations, then wait for it to finish
> > +        */
> > +       spin_unlock(&boot_lock);
> > +
> > +       return pen_release != -1 ? -ENOSYS : 0;
> > +}


From itooo at itooo.com  Fri Apr 19 10:13:19 2013
From: itooo at itooo.com (Greg)
Date: Fri, 19 Apr 2013 16:13:19 +0200
Subject: MVEBU and MVNETA driver
In-Reply-To: <20130419131237.GC22440@1wt.eu>
References: <5171419C.2090003@itooo.com> <20130419131237.GC22440@1wt.eu>
Message-ID: <517150FF.9010806@itooo.com>

Le 19/04/2013 15:12, Willy Tarreau a ?crit :
> Hi Greg,
>
> On Fri, Apr 19, 2013 at 03:07:40PM +0200, Greg wrote:
>> I'm facing a problem with ethernet transmission (reception -seems- to be
>> fine), at best is it slow (~90Mbps), at worst the kernel OOPSes at
>> various locations dealing with memory (tcp_v4_destroy_sock, free_block
>> and skb_put seen so far) and ends up crashing right after.
>> I'm simply using iperf to generate traffic and the system has been
>> stable for a while with Marvell's LSP so I can say with confidence the
>> hardware is pretty stable.
>>
> You need to get the following commit from mainline to fix this issue :
>
>     ee40a116ebf139f900c3d2e6febb8388738e96d0
>
Willy, thanks for your fast an accurate answer, this seems to solve the 
stability issue but not the performance issue.

Please look at this strange behavior : 1 iperf will only transmit at 
~100Mbps, 100 parallel iperf will transmit at ~950Mb. Reception is not 
an issue.
I'm thinking of a socket <-> txQ relationship that would limit 
transmission rate, but I have no idea on how this is implemented.

> PS: is it indiscrete to ask what board this is ?
I designed the board myself, if you already heard about it I'd be glad 
to know you told you about it ;-)

Cheers,


From arnd at arndb.de  Fri Apr 19 10:14:19 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 19 Apr 2013 16:14:19 +0200
Subject: [PATCH v3] irqchip: Add support for ARMv7-M's NVIC
In-Reply-To: <20130419135107.GD15233@pengutronix.de>
References: <1366214540-31166-1-git-send-email-u.kleine-koenig@pengutronix.de>
 <201304181138.13599.arnd@arndb.de> <20130419135107.GD15233@pengutronix.de>
Message-ID: <201304191614.19821.arnd@arndb.de>

On Friday 19 April 2013, Uwe Kleine-K?nig wrote:
> On Thu, Apr 18, 2013 at 11:38:13AM +0200, Arnd Bergmann wrote:
> > On Thursday 18 April 2013, Uwe Kleine-K?nig wrote:
> > > That is, there are (INTLINESNUM + 1) * 32 irqs for INTLINESNUM < 15. For
> > > INTLINESNUM == 15 there are only 496 and not 16 * 32 == 512. That's the
> > > same on the gic (just with bigger numbers).
> > 
> > Ok, but since you are now using a linear domain, it doesn't actually hurt
> > to register 512 in that special case, right?
> Well, it depends if allocating space for 16 unused unsigned ints hurts
> (maybe not).

As long as SPARSE_IRQ is enabled, the space won't actually be allocated.

> And it makes mapping some irqs successfull while the irq
> doesn't really exist. But probably this doesn't hurt either because the
> problem already exists.
> 
> I don't care much. Is there another advantage beside saving a few source
> lines/instructions?

It just feels strange to read the value from hardware and then override
it anyway. But I agree it's not important either way.

	Arnd


From arnd at arndb.de  Fri Apr 19 10:21:54 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 19 Apr 2013 16:21:54 +0200
Subject: [PATCH 1/2] ARM: default machine descriptor for multiplatform
In-Reply-To: <20130419132848.GO14496@n2100.arm.linux.org.uk>
References: <1365779468-116419-1-git-send-email-arnd@arndb.de>
 <20130419132848.GO14496@n2100.arm.linux.org.uk>
Message-ID: <201304191621.54681.arnd@arndb.de>

On Friday 19 April 2013, Russell King - ARM Linux wrote:
> On Fri, Apr 12, 2013 at 05:11:07PM +0200, Arnd Bergmann wrote:
> > @@ -752,7 +761,7 @@ void __init setup_arch(char **cmdline_p)
> >  
> >       setup_processor();
> >       mdesc = setup_machine_fdt(__atags_pointer);
> > -     if (!mdesc)
> > +     if (!mdesc && __machine_arch_type != ~0)
> >               mdesc = setup_machine_tags(__atags_pointer, __machine_arch_type);
> >       machine_desc = mdesc;
> >       machine_name = mdesc->name;
> 
> If mdesc is NULL and __machine_arch_type is ~0, then mdesc remains NULL.
> That means machine_desc is NULL (which is probably very bad), and the
> initialization of machine_name causes a NULL pointer dereference.
> 
> This is clearly wrong.  mdesc must never be NULL if you're using FDT
> here, so the original code should be fine.

Ah, right. I think was a leftover from an earlier version of the
patch where I only assigned the default platform after this.

There is also a related mistake in setup_machine_fdt, the second
change is not needed there either AFAICT.

Thanks for taking a look!

	Arnd


From mario.smarduch at huawei.com  Fri Apr 19 10:25:12 2013
From: mario.smarduch at huawei.com (Mario Smarduch)
Date: Fri, 19 Apr 2013 16:25:12 +0200
Subject: [RFC PATCH] Device/Interrupt Passthrough - 3.9rc5
Message-ID: <517153C8.9000409@huawei.com>


Sorry for the lengthy email, it covers both the patch submitted
here and high-level approach for Device Passthrough.

For the overall Device Passthrough approach please scroll down.

The Patch
=========
This patch by itself does not serve much purpose without the additional
QEMU/KVM support, the patch has been tested with those features working
Those patches will be rolled out soon. Given this patch touches critical
GIC code required by Device Passthrough it needs to go in first.

The interrupt pass-through patch supports priority drop/deactivation. This is
a first patch intended to facilitate overall device (interrupt) passthrough to
guest.

ARM GICv2 describes recommended way to handle interrupt pass-through
(5.2.2 - 1., 2.) - this patch sets Host GICC_CTLR.EOImodeNS=1 and for
injecting interrupts GICH_LRn.HW=1. Guest sets its CTLR.EOImodeNS=0
executing without changes.

New config param is defined (arm/kvm/Kconfig' KVM_ARM_INT_PRIO_DROP)
which is enabled only if Virtualization && KVM_ARM_VGIC && OF are enabled.

If the parameter is enabled, an IRQ can be marked for pass-through, in
that case host writes to EOIR to lower IRQ priority and Guest EOIR deactivates
the IRQ. For host interrupts writes to both EOIR/DIR are done. If the config
param is diabled then nothing changes.

The patch is strictly intended for Virtualization & KVM device
passthrough, there may be other uses for IRQ prio drop/deactivation they're
not obvious or considered at this time.

Currently the patch assumes if primary CPU has HYP mode enabled and if
PRIO_DROP is defined EOImodeNS is set. It might turn out that subsequent CPU(s)
may not boot in HYP mode in that case all CPUs will be configured to
execute in PRIO DROP mode which practically has no overhead.

What's been tested -
 - we pass-through sp804 timer and event devices from guest to host,
   this tests QEMU, kernel, ARM-KVM memory and interrupt passthrough.
   We're working on lan 911x passthrough and then Arndale NIC
   passthrough
 - all combinations of host and guest have been tested,
   i.e. Host Virt=on/off, PrioDrop=on/off; Guest virt=on/of, PD=on/off
   Any combination of Guest/Host config is supported.

DEVICE PASSTHROUGH overall Architecture
---------------------------------------

To pass through a device following data is required:
 o Host - Device HPA, Size, Perms (r; r/w), Attr (dev, mem), host irq -
   [optional: CPU IRQ affinity, vCPU affinity -  dynamic affiniy although
    affinity for RT/performance a require option] - these values come from
    Device Tree and command line parameters.
 o Guest - Device GPA, IRQ - at run-time select memory and IRQ from
   range predefined for Device passthrough for the emulated machine model and
   patch guest DT. The ranges should be predefined to prevent future conflicts
   between MMIO and devices passed through.

Overall Device Passthrough Design summary - simple usage -
     "-device kvm-device-assign,host="device name" -
device as known in DT.  Although passing all the parameters is also supported.

- This patch being first to lay the groundwork and given it touches
  generic GIC code we would like early feedback.
- Device I/O or Memory Passthrough - combination of new QEMU
  (kvm-device-assign) device and ARM KVM ioctl hooks to map device in
  2nd stage tables. Dynamic discovery and/or allocation of resources.
  With SMMU availability this should be where you map/pin the Guest.
- Interrupt passthrough - reuse current ioctl QEMU/KVM ioctl
  infrastracture in combination with this patch KVM Guest can
  mark a device for interrupt passthrough. Both host/guest IRQs run-time
  discovered/allocated.
  o eventual run-time IRQ -> CPU -> vCPU framework support, although CPU/vCPU
    affinity for some applications is useful as well.
- Support for 1:1 memory mapping to support DMA with no IOMMU. Eventually with
  SMMU secure DMA will be supported until then - provide contiguous memory to
  guest and map 1:1 2nd stage tables - Guest IPA == HPA. This approach
  has some merits and has been utilized by propriotary solutions
  primarily in Wireless where guests are trusted (some devices like SEC
  engines may not be behind SMMU and DMA to memory look-aside crypto).

	Mario.

Signed-off-by: Mario Smarduch <mario.smarduch at huawei.com>
---
 arch/arm/kvm/Kconfig            |   14 ++++
 drivers/irqchip/irq-gic.c       |  148 ++++++++++++++++++++++++++++++++++++++-
 include/linux/irqchip/arm-gic.h |    6 ++
 3 files changed, 165 insertions(+), 3 deletions(-)

diff --git a/arch/arm/kvm/Kconfig b/arch/arm/kvm/Kconfig
index 49dd64e..3fcc18e 100644
--- a/arch/arm/kvm/Kconfig
+++ b/arch/arm/kvm/Kconfig
@@ -59,6 +59,20 @@ config KVM_ARM_VGIC
 	---help---
 	  Adds support for a hardware assisted, in-kernel GIC emulation.

+config KVM_ARM_INT_PRIO_DROP
+	bool "KVM support for Interrupt pass-through"
+	depends on KVM_ARM_VGIC && OF
+	default n
+	---help---
+	  Seperates interrupt priority drop and deactivation to enable device
+	  pass-through to Guests. Enabling this config seperates priority drop
+	  from deactivation of the interrupt (active->inactive or pending).
+	  This requires write to EOIR and DIR registers. For interrupts passed
+	  through to Guest, the host does the EOIR and Guest EOIR deactivates
+	  the interrupt. For interrupts not passed through. The host writes to
+	  EOIR and DIR registers. For host to access the DIR reg additional
+	  page must be mapped for GICC (i.e. 2 pages total)
+
 config KVM_ARM_TIMER
 	bool "KVM support for Architected Timers"
 	depends on KVM_ARM_VGIC && ARM_ARCH_TIMER
diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
index a32e0d5..71ce01e 100644
--- a/drivers/irqchip/irq-gic.c
+++ b/drivers/irqchip/irq-gic.c
@@ -39,11 +39,14 @@
 #include <linux/percpu.h>
 #include <linux/slab.h>
 #include <linux/irqchip/arm-gic.h>
+#include <linux/irqflags.h>
+#include <linux/bitops.h>

 #include <asm/irq.h>
 #include <asm/exception.h>
 #include <asm/smp_plat.h>
 #include <asm/mach/irq.h>
+#include <asm/virt.h>

 #include "irqchip.h"

@@ -98,6 +101,20 @@ struct irq_chip gic_arch_extn = {

 static struct gic_chip_data gic_data[MAX_GIC_NR] __read_mostly;

+#ifdef CONFIG_KVM_ARM_INT_PRIO_DROP
+/*
+ * Priority drop/deactivation bit map, 1st 16 bits used for SGIs, this bit map
+ * is shared by several guests. If bit is set only execute EOI which drops
+ * current priority but not deactivation.
+ */
+static u32  gic_irq_prio_drop[DIV_ROUND_UP(1020, 32)] __read_mostly;
+static void gic_eoi_irq_priodrop(struct irq_data *);
+#endif
+
+static void gic_enable_gicc(void __iomem *);
+static void gic_eoi_sgi(u32, void __iomem *);
+static void gic_priodrop_remap_eoi(struct irq_chip *);
+
 #ifdef CONFIG_GIC_NON_BANKED
 static void __iomem *gic_get_percpu_base(union gic_base *base)
 {
@@ -294,7 +311,7 @@ static asmlinkage void __exception_irq_entry gic_handle_irq(struct pt_regs *regs
 			continue;
 		}
 		if (irqnr < 16) {
-			writel_relaxed(irqstat, cpu_base + GIC_CPU_EOI);
+			gic_eoi_sgi(irqstat, cpu_base);
 #ifdef CONFIG_SMP
 			handle_IPI(irqnr, regs);
 #endif
@@ -448,7 +465,7 @@ static void __cpuinit gic_cpu_init(struct gic_chip_data *gic)
 		writel_relaxed(0xa0a0a0a0, dist_base + GIC_DIST_PRI + i * 4 / 4);

 	writel_relaxed(0xf0, base + GIC_CPU_PRIMASK);
-	writel_relaxed(1, base + GIC_CPU_CTRL);
+	gic_enable_gicc(base);
 }

 #ifdef CONFIG_CPU_PM
@@ -583,7 +600,7 @@ static void gic_cpu_restore(unsigned int gic_nr)
 		writel_relaxed(0xa0a0a0a0, dist_base + GIC_DIST_PRI + i * 4);

 	writel_relaxed(0xf0, cpu_base + GIC_CPU_PRIMASK);
-	writel_relaxed(1, cpu_base + GIC_CPU_CTRL);
+	gic_enable_gicc(cpu_base);
 }

 static int gic_notifier(struct notifier_block *self, unsigned long cmd,	void *v)
@@ -664,6 +681,7 @@ void gic_raise_softirq(const struct cpumask *mask, unsigned int irq)
 static int gic_irq_domain_map(struct irq_domain *d, unsigned int irq,
 				irq_hw_number_t hw)
 {
+	gic_priodrop_remap_eoi(&gic_chip);
 	if (hw < 32) {
 		irq_set_percpu_devid(irq);
 		irq_set_chip_and_handler(irq, &gic_chip,
@@ -843,3 +861,127 @@ IRQCHIP_DECLARE(msm_8660_qgic, "qcom,msm-8660-qgic", gic_of_init);
 IRQCHIP_DECLARE(msm_qgic2, "qcom,msm-qgic2", gic_of_init);

 #endif
+
+#ifdef CONFIG_KVM_ARM_INT_PRIO_DROP
+/* If HYP mode enabled and PRIO DROP set EOIR function to handle PRIO DROP */
+static inline void gic_priodrop_remap_eoi(struct irq_chip *chip)
+{
+	if (is_hyp_mode_available())
+		chip->irq_eoi = gic_eoi_irq_priodrop;
+}
+
+/* If HYP mode set enable interrupt priority drop/deactivation, and mark
+ * SGIs to deactive through writes to GCICC_DIR. For Guest only enable normal
+ * mode.
+ */
+static void gic_enable_gicc(void __iomem *gicc_base)
+{
+	if (is_hyp_mode_available()) {
+		/* Allow Priority Drop in host, but not in Guest */
+		gic_irq_prio_drop[0] = (u32) (1 << 16) - 1;
+		writel_relaxed(0x201, gicc_base + GIC_CPU_CTRL);
+	} else {
+		writel_relaxed(1, gicc_base + GIC_CPU_CTRL);
+	}
+}
+
+/* If Host write to EOIR and DIR to drop priority and deactivate, Guest
+ * only write to EOIR.
+ */
+static void gic_eoi_sgi(u32 irqstat, void __iomem *gicc_base)
+{
+	unsigned long flags;
+	if (unlikely(gic_irq_prio_drop[0] & (1<<((irqstat & ~0x1c00) % 16)))) {
+		raw_local_irq_save(flags);
+		writel_relaxed(irqstat, gicc_base + GIC_CPU_EOI);
+		writel_relaxed(irqstat, gicc_base + GIC_CPU_DIR);
+		raw_local_irq_restore(flags);
+		return;
+	}
+	writel_relaxed(irqstat, gicc_base + GIC_CPU_EOI);
+}
+
+/* EOIR handler to manage PRIO DROP, if interrupt passed-through only write to
+ * EOIR the Guest will deactivate it through its write to EOIR. Otherwise for
+ * non pass-through write to EOIR and DIR. GICC_DIR _must_ be mapped.
+ */
+static void gic_eoi_irq_priodrop(struct irq_data *d)
+{
+	if (gic_arch_extn.irq_eoi) {
+		raw_spin_lock(&irq_controller_lock);
+		gic_arch_extn.irq_eoi(d);
+		raw_spin_unlock(&irq_controller_lock);
+	}
+
+	/* Set from KVM device passthrough to determine which interrupts
+	 * must be deactivated by the Guest.
+	 */
+	if (unlikely(gic_spi_get_priodrop(gic_irq(d)))) {
+		/* IRQ marked for priority drop, deactivation is deferred
+		 * in this case the Guest deactivates the interrupt, or regular
+		 * path if GCTLR.EOImodeNS=0 or not suppored.
+		 */
+		 writel_relaxed(gic_irq(d), gic_cpu_base(d) + GIC_CPU_EOI);
+	} else {
+		/* De-prioritize/de-activate interrupt, disable interrupts
+		 * so lower priority interrupt does not stall this one.
+		 */
+		unsigned long flags;
+		raw_local_irq_save(flags);
+		writel_relaxed(gic_irq(d), gic_cpu_base(d) + GIC_CPU_EOI);
+		writel_relaxed(gic_irq(d), gic_cpu_base(d) + GIC_CPU_DIR);
+		raw_local_irq_restore(flags);
+	}
+}
+
+/* Priority Drop access functions, serialization must be handled in KVM
+ * when passing device through. The EOI handler reads the state for the
+ * associate SPI without any locking. This requires orderly installation
+ * and teardown of devices passed through.
+ */
+
+/* Set the IRQ for pass-through to Guest */
+void gic_spi_set_priodrop(int irq)
+{
+	if (likely(irq >= 32 && irq <= 1019))
+		set_bit(irq % 32, (void *) &gic_irq_prio_drop[irq/32]);
+}
+
+/* Clear the IRQ from pass-through to Guest */
+void gic_spi_clr_priodrop(int irq)
+{
+	if (likely(irq >= 32 && irq < 1019))
+		clear_bit(irq % 32, (void *) &gic_irq_prio_drop[irq/32]);
+}
+
+/* Get IRQ pass-through status */
+int gic_spi_get_priodrop(int irq)
+{
+	if (likely(irq >= 32 && irq <= 1019))
+		return gic_irq_prio_drop[irq/32] & (1 << (irq % 32));
+
+	return 0;
+}
+#else
+static inline void gic_priodrop_remap_eoi(struct irq_chip *gic_chip)
+{
+}
+static inline void gic_enable_gicc(void __iomem *gicc_base)
+{
+	writel_relaxed(1, gicc_base + GIC_CPU_CTRL);
+}
+static void gic_eoi_sgi(u32 irqstat, void __iomem *gicc_base)
+{
+	writel_relaxed(irqstat, gicc_base + GIC_CPU_EOI);
+}
+void gic_spi_set_priodrop(int irq)
+{
+}
+void gic_spi_clr_priodrop(int irq)
+{
+}
+int gic_spi_get_priodrop(int irq)
+{
+	return 0;
+}
+#endif
diff --git a/include/linux/irqchip/arm-gic.h b/include/linux/irqchip/arm-gic.h
index 3fd8e42..5d387ce 100644
--- a/include/linux/irqchip/arm-gic.h
+++ b/include/linux/irqchip/arm-gic.h
@@ -17,6 +17,7 @@
 #define GIC_CPU_EOI			0x10
 #define GIC_CPU_RUNNINGPRI		0x14
 #define GIC_CPU_HIGHPRI			0x18
+#define GIC_CPU_DIR                     0x1000

 #define GIC_DIST_CTRL			0x000
 #define GIC_DIST_CTR			0x004
@@ -74,6 +75,11 @@ static inline void gic_init(unsigned int nr, int start,
 	gic_init_bases(nr, start, dist, cpu, 0, NULL);
 }

+/* Functions to manage interrupt pass-through */
+void gic_spi_set_priodrop(int);
+void gic_spi_clr_priodrop(int);
+int gic_spi_get_priodrop(int);
+
 #endif /* __ASSEMBLY */

 #endif
-- 
1.7.9.5



From linux at arm.linux.org.uk  Fri Apr 19 10:33:31 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Fri, 19 Apr 2013 15:33:31 +0100
Subject: [PATCHv8 07/19] arm: pci: add a align_resource hook
In-Reply-To: <20130415163609.GJ28693@titan.lakedaemon.net>
References: <1365541601-14095-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1365541601-14095-8-git-send-email-thomas.petazzoni@free-electrons.com>
 <20130415163609.GJ28693@titan.lakedaemon.net>
Message-ID: <20130419143331.GV14496@n2100.arm.linux.org.uk>

On Mon, Apr 15, 2013 at 12:36:09PM -0400, Jason Cooper wrote:
> Russell,
> 
> Thanks for applying this patch (7683/1) to your tree.  I see it's in
> your for-next, which I understand *isn't* stable.

That is correct.

>   029baf1 ARM: 7683/1: pci: add a align_resource hook
> 
> Is there a stable branch I could depend on for the rest of this series
> (particularly, patch 10)?  It looks like you applied it to your misc
> branch, but that's not currently available.

I will have to look at that; as I'm still catching up with mail three
days after having returned and there's still quite an amount outstanding,
it's going to be a while before I can look at this.  Given that we're at
-rc7 and the amount of outstanding mail, it's likely that may happen
after the merge window has opened.



From gregory.clement at free-electrons.com  Fri Apr 19 10:34:38 2013
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Fri, 19 Apr 2013 16:34:38 +0200
Subject: [GIT PULL V2 1/4] mvebu driver changes for v3.10
In-Reply-To: <CAOesGMjD-VAZW-zL-jm65xSJkFLpzbYOdvN6-5pV1OW_vJDCWg@mail.gmail.com>
References: <20130415182824.GN28693@titan.lakedaemon.net>
 <20130416150416.GB28693@titan.lakedaemon.net>
 <20130418053002.GB12816@quad.lixom.net>
 <CAOesGMjD-VAZW-zL-jm65xSJkFLpzbYOdvN6-5pV1OW_vJDCWg@mail.gmail.com>
Message-ID: <517155FE.30406@free-electrons.com>

On 04/19/2013 04:09 PM, Olof Johansson wrote:
> On Wed, Apr 17, 2013 at 10:30 PM, Olof Johansson <olof at lixom.net> wrote:
>> On Tue, Apr 16, 2013 at 11:04:16AM -0400, Jason Cooper wrote:
>>>
>>> The following changes since commit 8bb9660418e05bb1845ac1a2428444d78e322cc7:
>>>
>>>   Linux 3.9-rc4 (2013-03-23 16:52:44 -0700)
>>>
>>> are available in the git repository at:
>>>
>>>   git://git.infradead.org/users/jcooper/linux.git tags/drivers-3.10-2
>>>
>>> for you to fetch changes up to ac7b07ec369324063e52c37b3fb0ad1a1814d879:
>>>
>>>   clk: mvebu: add more PCIe clocks for Armada XP (2013-04-16 14:47:01 +0000)
>>
>> Pulled, thanks.
> 
> Dropped due to build errors on powerpc64. 3.11 material now.
> 

Wait! That means dropping _all_ the change done in mvebu for 3.10 just
for one patch in the of/pci part?

Jason, did you take the accurate patch? Because according to Grant
Likely, the build didn't fail on ppc, see:

http://www.spinics.net/lists/arm-kernel/msg238517.html


> 
> -Olof
> 


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From santosh.shilimkar at ti.com  Fri Apr 19 10:40:50 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Fri, 19 Apr 2013 20:10:50 +0530
Subject: [PATCH] gpio/omap: ensure gpio context is initialised
In-Reply-To: <87sj2mzkcf.fsf@linaro.org>
References: <1366230707-32681-1-git-send-email-jon-hunter@ti.com>
 <871ua734mv.fsf@linaro.org> <51707D7C.1050600@ti.com>
 <5170911C.6010507@ti.com> <51709499.8030208@ti.com> <5170E4EE.7090100@ti.com>
 <87sj2mzkcf.fsf@linaro.org>
Message-ID: <51715772.9020003@ti.com>

On Friday 19 April 2013 07:35 PM, Kevin Hilman wrote:
> Santosh Shilimkar <santosh.shilimkar at ti.com> writes:
> 
>> On Friday 19 April 2013 06:19 AM, Jon Hunter wrote:
>>>
>>> On 04/18/2013 07:34 PM, Jon Hunter wrote:
>>>>
>>>> On 04/18/2013 06:10 PM, Jon Hunter wrote:
>>>>> On 04/18/2013 04:34 PM, Kevin Hilman wrote:
>>>>
>>>> ...
>>>>
>>>>>> Why not just init context right here if bank->loses_context &&
>>>>>> !bank->context_valid?
>>>>
>>>> I really like this idea a lot. It can really clean-up the code
>>>> and really make it much more readable. Before we were playing 
>>>> some tricks with when we init'ed the get_context_loss_count()
>>>> function pointer. How about the below?
>>>>
>>>> Tony, care to re-test?
>>>>
>>>> Cheers
>>>> Jon
>>>>
>>>> From d7a940531d354e6be5e16ee50fa8344041df963a Mon Sep 17 00:00:00 2001
>>>> From: Jon Hunter <jon-hunter at ti.com>
>>>> Date: Mon, 15 Apr 2013 13:06:54 -0500
>>>> Subject: [PATCH] gpio/omap: ensure gpio context is initialised
>>>>
>>>> Commit a2797be (gpio/omap: force restore if context loss is not
>>>> detectable) broke gpio support for OMAP when booting with device-tree
>>>> because a restore of the gpio context being performed without ever
>>>> initialising the gpio context. In other words, the context restored was
>>>> bad.
>>>>
>>>> This problem could also occur in the non device-tree case, however, it
>>>> is much less likely because when booting without device-tree we can
>>>> detect context loss via a platform specific API and so context restore
>>>> is performed less often.
>>>>
>>>> Nevertheless we should ensure that the gpio context is initialised
>>>> on the first pm-runtime resume for gpio banks that could lose their
>>>> state regardless of whether we are booting with device-tree or not.
>>>>
>>>> The context loss count was being initialised on the first pm-runtime
>>>> suspend following a resume, by populating the get_count_loss_count()
>>>> function pointer after the first pm-runtime resume. To make the code
>>>> more readable and logical, initialise the context loss count on the
>>>> first pm-runtime resume if the context is not yet valid.
>>>>
>>>> Reported-by: Tony Lindgren <tony at atomide.com>
>>>> Signed-off-by: Jon Hunter <jon-hunter at ti.com>
>>>> ---
>>>>  drivers/gpio/gpio-omap.c |   45 ++++++++++++++++++++++++++++++++++++++++++---
>>>>  1 file changed, 42 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
>>>> index 0557529..db3c732 100644
>>>> --- a/drivers/gpio/gpio-omap.c
>>>> +++ b/drivers/gpio/gpio-omap.c
>>>> @@ -70,6 +70,7 @@ struct gpio_bank {
>>>>  	bool is_mpuio;
>>>>  	bool dbck_flag;
>>>>  	bool loses_context;
>>>> +	bool context_valid;
>>>>  	int stride;
>>>>  	u32 width;
>>>>  	int context_loss_count;
>>>> @@ -1129,6 +1130,7 @@ static int omap_gpio_probe(struct platform_device *pdev)
>>>>  			bank->loses_context = true;
>>>>  	} else {
>>>>  		bank->loses_context = pdata->loses_context;
>>>> +		bank->get_context_loss_count = pdata->get_context_loss_count;
>>>
>>> Still need to check loses_context for populating
>>> get_context_loss_count here. Updated patch below.
>>>
>>> Jon
>>>
>>> From d02ef7b7dfcf8e13bf019aedfdecb38ca3c6749f Mon Sep 17 00:00:00 2001
>>> From: Jon Hunter <jon-hunter at ti.com>
>>> Date: Mon, 15 Apr 2013 13:06:54 -0500
>>> Subject: [PATCH] gpio/omap: ensure gpio context is initialised
>>>
>>> Commit a2797be (gpio/omap: force restore if context loss is not
>>> detectable) broke gpio support for OMAP when booting with device-tree
>>> because a restore of the gpio context being performed without ever
>>> initialising the gpio context. In other words, the context restored was
>>> bad.
>>>
>>> This problem could also occur in the non device-tree case, however, it
>>> is much less likely because when booting without device-tree we can
>>> detect context loss via a platform specific API and so context restore
>>> is performed less often.
>>>
>>> Nevertheless we should ensure that the gpio context is initialised
>>> on the first pm-runtime resume for gpio banks that could lose their
>>> state regardless of whether we are booting with device-tree or not.
>>>
>>> The context loss count was being initialised on the first pm-runtime
>>> suspend following a resume, by populating the get_count_loss_count()
>>> function pointer after the first pm-runtime resume. To make the code
>>> more readable and logical, initialise the context loss count on the
>>> first pm-runtime resume if the context is not yet valid.
>>>
>>> Reported-by: Tony Lindgren <tony at atomide.com>
>>> Signed-off-by: Jon Hunter <jon-hunter at ti.com>
>>> ---
>> This version looks better than the first one for sure. I am still not
>> happy with per bank "context_valid" flag whose job just ends after
>> the probe. 
> 
> Assuming this driver could become a module someday (not terribly likely,
> I know), but context_valid would have meaning for each module reload.
> 
I don't think GPIO can ever be a module(at least on OMAP) considering the way
it is used in many SOCs and hence the objection on that flag. GPIO is really
an infrastructure driver which is needed to be always available for the
client drivers to work. 

Regards,
Santosh


From arnd at arndb.de  Fri Apr 19 10:40:31 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 19 Apr 2013 16:40:31 +0200
Subject: [PATCH v3] ARM: default machine descriptor for multiplatform
In-Reply-To: <201304191621.54681.arnd@arndb.de>
References: <1365779468-116419-1-git-send-email-arnd@arndb.de>
 <20130419132848.GO14496@n2100.arm.linux.org.uk>
 <201304191621.54681.arnd@arndb.de>
Message-ID: <201304191640.32139.arnd@arndb.de>

Since we now have default implementations for init_time and init_irq,
the init_machine callback is the only one that is not yet optional,
but since simple DT based platforms all have the same
of_platform_populate function call in there, we can consolidate them
as well, and then actually boot with a completely empty machine_desc.
Unofortunately we cannot just default to an empty init_machine: We
cannot call of_platform_populate before init_machine because that
does not work in case of auxdata, and we cannot call it after
init_machine either because the machine might need to run code
after adding the devices.

To take the final step, this adds support for booting without defining
any machine_desc whatsoever.

For the case that CONFIG_MULTIPLATFORM is enabled, it adds a
global machine descriptor that never matches any machine but is
used as a fallback if nothing else matches. We assume that without
CONFIG_MULTIPLATFORM, we only want to boot on the systems that the kernel
is built for, so we still retain the build-time warning for missing
machine descriptors and the run-time warning when the platform does not
match in that case.

In the case that we run on a multiplatform kernel and the machine
provides a fully populated device tree, we attempt to keep booting,
hoping that no machine specific callbacks are necessary.

Finally, this also removes the misguided "select ARCH_VEXPRESS" that
was only added to avoid a build error for allnoconfig kernels.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Acked-by: Nicolas Pitre <nico at linaro.org>
Acked-by: Olof Johansson <olof at lixom.net>
Cc: "Russell King - ARM Linux" <linux at arm.linux.org.uk>
Cc: Rob Herring <robherring2 at gmail.com>

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 1cacda4..e67d49d 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1014,7 +1014,6 @@ config ARCH_MULTI_V7
 	bool "ARMv7 based platforms (Cortex-A, PJ4, Scorpion, Krait)"
 	default y
 	select ARCH_MULTI_V6_V7
-	select ARCH_VEXPRESS
 	select CPU_V7
 
 config ARCH_MULTI_V6_V7
diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
index 70f1bde..9038c9f 100644
--- a/arch/arm/kernel/devtree.c
+++ b/arch/arm/kernel/devtree.c
@@ -180,6 +180,13 @@ struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys)
 	unsigned long dt_root;
 	const char *model;
 
+	if (IS_ENABLED(CONFIG_ARCH_MULTIPLATFORM)) {
+		DT_MACHINE_START(GENERIC_DT, "Generic DT based system")
+		MACHINE_END
+
+		mdesc_best = (struct machine_desc *)&__mach_desc_GENERIC_DT;
+	}
+
 	if (!dt_phys)
 		return NULL;
 
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index d343a6c..9e0f43d 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -18,6 +18,7 @@
 #include <linux/bootmem.h>
 #include <linux/seq_file.h>
 #include <linux/screen_info.h>
+#include <linux/of_platform.h>
 #include <linux/init.h>
 #include <linux/kexec.h>
 #include <linux/of_fdt.h>
@@ -660,9 +661,17 @@ struct screen_info screen_info = {
 
 static int __init customize_machine(void)
 {
-	/* customizes platform devices, or adds new ones */
+	/*
+	 * customizes platform devices, or adds new ones
+	 * On DT based machines, we fall back to populating the
+	 * machine from the device tree, if no callback is provided,
+	 * otherwise we would always need an init_machine callback.
+	 */
 	if (machine_desc->init_machine)
 		machine_desc->init_machine();
+	else
+		of_platform_populate(NULL, of_default_bus_match_table,
+					NULL, NULL);
 	return 0;
 }
 arch_initcall(customize_machine);


From w at 1wt.eu  Fri Apr 19 10:43:24 2013
From: w at 1wt.eu (Willy Tarreau)
Date: Fri, 19 Apr 2013 16:43:24 +0200
Subject: MVEBU and MVNETA driver
In-Reply-To: <517150FF.9010806@itooo.com>
References: <5171419C.2090003@itooo.com> <20130419131237.GC22440@1wt.eu>
 <517150FF.9010806@itooo.com>
Message-ID: <20130419144324.GD22440@1wt.eu>

On Fri, Apr 19, 2013 at 04:13:19PM +0200, Greg wrote:
> Willy, thanks for your fast an accurate answer, this seems to solve the 
> stability issue but not the performance issue.

OK.

> Please look at this strange behavior : 1 iperf will only transmit at 
> ~100Mbps, 100 parallel iperf will transmit at ~950Mb. Reception is not 
> an issue.
> I'm thinking of a socket <-> txQ relationship that would limit 
> transmission rate, but I have no idea on how this is implemented.

Strange, I have not experienced this. Yes a socket size limit could be
the reason. Have you tried with netcat or any simple TCP server instead ?

> >PS: is it indiscrete to ask what board this is ?
> I designed the board myself, if you already heard about it I'd be glad 
> to know you told you about it ;-)

Wow, impressed !

Willy



From catalin.marinas at arm.com  Fri Apr 19 10:45:30 2013
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Fri, 19 Apr 2013 15:45:30 +0100
Subject: [PATCH 1/2] clocksource: arm_arch_timer: unify sched_clock init
In-Reply-To: <1366313410-16692-1-git-send-email-robherring2@gmail.com>
References: <1366313410-16692-1-git-send-email-robherring2@gmail.com>
Message-ID: <20130419144529.GB4855@localhost.cambridge.arm.com>

On Thu, Apr 18, 2013 at 08:30:09PM +0100, Rob Herring wrote:
> From: Rob Herring <rob.herring at calxeda.com>
> 
> In preparation to fix initial time and suspend/resume handling, unify
> the sched_clock init and implementation for arch timer on arm and arm64.
> 
> Signed-off-by: Rob Herring <rob.herring at calxeda.com>
> Cc: Russell King <linux at arm.linux.org.uk>
> Cc: Catalin Marinas <catalin.marinas at arm.com>
> Cc: Will Deacon <will.deacon at arm.com>
> Cc: John Stultz <john.stultz at linaro.org>
> Cc: Thomas Gleixner <tglx at linutronix.de>
> Cc: Stephen Boyd <sboyd at codeaurora.org>

For arm64:

Acked-by: Catalin Marinas <catalin.marinas at arm.com>


From catalin.marinas at arm.com  Fri Apr 19 10:46:01 2013
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Fri, 19 Apr 2013 15:46:01 +0100
Subject: [PATCH 2/2] clocksource: arm_arch_timer: add boot and suspend
 sched_clock offset
In-Reply-To: <1366313410-16692-2-git-send-email-robherring2@gmail.com>
References: <1366313410-16692-1-git-send-email-robherring2@gmail.com>
 <1366313410-16692-2-git-send-email-robherring2@gmail.com>
Message-ID: <20130419144601.GC4855@localhost.cambridge.arm.com>

On Thu, Apr 18, 2013 at 08:30:10PM +0100, Rob Herring wrote:
> From: Rob Herring <rob.herring at calxeda.com>
> 
> Commit 023796b (ARM: arch_timer: use full 64-bit counter for sched_clock)
> fails to ensure sched_clock always starts at time 0 and counting is
> suspended during suspend. arm64 sched_clock support also has the same
> issues. This fixes all architected timer users by maintaining an initial
> offset which is updated on resume.
> 
> Signed-off-by: Rob Herring <rob.herring at calxeda.com>
> Cc: Russell King <linux at arm.linux.org.uk>
> Cc: John Stultz <john.stultz at linaro.org>
> Cc: Thomas Gleixner <tglx at linutronix.de>
> Cc: Catalin Marinas <catalin.marinas at arm.com>
> Cc: Will Deacon <will.deacon at arm.com>
> Cc: Stephen Boyd <sboyd at codeaurora.org>

For arm64:

Acked-by: Catalin Marinas <catalin.marinas at arm.com>


From sergei.shtylyov at cogentembedded.com  Fri Apr 19 10:49:44 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Fri, 19 Apr 2013 18:49:44 +0400
Subject: [PATCH 1/5] ARM: at91: at91sam9x5 RTC is not compatible with
 at91rm9200 one
In-Reply-To: <51714F47.5040006@atmel.com>
References: <cover.1366289869.git.nicolas.ferre@atmel.com>
 <864f10566b35864d469f6ff2913b9afaa0c69350.1366289869.git.nicolas.ferre@atmel.com>
 <51714C74.2030907@cogentembedded.com> <51714F47.5040006@atmel.com>
Message-ID: <51715988.9060606@cogentembedded.com>

On 19-04-2013 18:05, Nicolas Ferre wrote:

>>> Due to a bug with RTC IMR, we cannot consider at91sam9x5 RTC compatible
>>> with the previous one. Modify DT compatibility string, even if the driver
>>> is not yet modified to take it into account.

>>> Signed-off-by: Nicolas Ferre <nicolas.ferre at atmel.com>
>>> ---
>>>    arch/arm/boot/dts/at91sam9x5.dtsi | 2 +-
>>>    1 file changed, 1 insertion(+), 1 deletion(-)

>>> diff --git a/arch/arm/boot/dts/at91sam9x5.dtsi
>>> b/arch/arm/boot/dts/at91sam9x5.dtsi
>>> index a3d4464..58747f3 100644
>>> --- a/arch/arm/boot/dts/at91sam9x5.dtsi
>>> +++ b/arch/arm/boot/dts/at91sam9x5.dtsi
>>> @@ -564,7 +564,7 @@
>>>                };
>>>
>>>                rtc at fffffeb0 {
>>> -                compatible = "atmel,at91rm9200-rtc";
>>> +                compatible = "atmel,at91sam9x5-rtc";

>>     Do not use wildcards in the "compatible" prop values (I guess 'x' is
>> a wildcard).

> Well, it is for naming a series of hardware, not for giving a generic
> name that could cover different hardware.

> In the sense of Atmel it is our way to call the at91sam9x5 series of
> SoC: you will see that the code that covers these SoCs is always named
> like this.
> In fact, the hardware contained in these SoC cannot be different from
> one flavor of the family to the other.

    Nevertheless, the wildcards shouldn't be used. Use the name of e.g. the 
first member of the family.

> Best regards,

WBR, Sergei



From steve.capper at linaro.org  Fri Apr 19 10:49:31 2013
From: steve.capper at linaro.org (Steve Capper)
Date: Fri, 19 Apr 2013 15:49:31 +0100
Subject: [PATCH] ARM64: mm: Correct show_pte behaviour.
Message-ID: <1366382971-12682-1-git-send-email-steve.capper@linaro.org>

show_pte makes use of the *_none_or_clear_bad style functions. If a
pgd, pud or pmd is identified as being bad, it will then be cleared.

As show_pte appears to be called from either the user or kernel
fault handlers this side effect can lead to unpredictable behaviour;
especially as TLB entries are not invalidated.

This patch removes the page table sanitisation from show_pte. If a
bad pgd, pud or pmd is encountered it is left unmodified.

Signed-off-by: Steve Capper <steve.capper at linaro.org>
---
 arch/arm64/mm/fault.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index afadae6..5263817 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -57,16 +57,16 @@ void show_pte(struct mm_struct *mm, unsigned long addr)
 		pmd_t *pmd;
 		pte_t *pte;
 
-		if (pgd_none_or_clear_bad(pgd))
+		if (pgd_none(*pgd) || pgd_bad(*pgd))
 			break;
 
 		pud = pud_offset(pgd, addr);
-		if (pud_none_or_clear_bad(pud))
+		if (pud_none(*pud) || pud_bad(*pud))
 			break;
 
 		pmd = pmd_offset(pud, addr);
 		printk(", *pmd=%016llx", pmd_val(*pmd));
-		if (pmd_none_or_clear_bad(pmd))
+		if (pmd_none(*pmd) || pmd_bad(*pmd))
 			break;
 
 		pte = pte_offset_map(pmd, addr);
-- 
1.8.1.4



From gregory.clement at free-electrons.com  Fri Apr 19 10:59:19 2013
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Fri, 19 Apr 2013 16:59:19 +0200
Subject: MVEBU and MVNETA driver
In-Reply-To: <20130419144324.GD22440@1wt.eu>
References: <5171419C.2090003@itooo.com> <20130419131237.GC22440@1wt.eu>
 <517150FF.9010806@itooo.com> <20130419144324.GD22440@1wt.eu>
Message-ID: <51715BC7.3040906@free-electrons.com>

On 04/19/2013 04:43 PM, Willy Tarreau wrote:
> On Fri, Apr 19, 2013 at 04:13:19PM +0200, Greg wrote:
>> Willy, thanks for your fast an accurate answer, this seems to solve the 
>> stability issue but not the performance issue.
> 
> OK.
> 
>> Please look at this strange behavior : 1 iperf will only transmit at 
>> ~100Mbps, 100 parallel iperf will transmit at ~950Mb. Reception is not 
>> an issue.
>> I'm thinking of a socket <-> txQ relationship that would limit 
>> transmission rate, but I have no idea on how this is implemented.
> 
> Strange, I have not experienced this. Yes a socket size limit could be
> the reason. Have you tried with netcat or any simple TCP server instead ?
> 

I also have this behavior:
iperf -c 192.168.0.19 -d
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
------------------------------------------------------------
Client connecting to 192.168.0.19, TCP port 5001
TCP window size: 20.7 KByte (default)
------------------------------------------------------------
[  5] local 192.168.0.37 port 48473 connected with 192.168.0.19 port 5001
[  4] local 192.168.0.37 port 5001 connected with 192.168.0.19 port 36987
[ ID] Interval       Transfer     Bandwidth
[  5]  0.0-10.0 sec   128 MBytes   107 Mbits/sec
[  4]  0.0-10.0 sec  1.07 GBytes   919 Mbits/sec

but I only need 10 thread in iperf to be close to the Gb
------------------------------------------------------------
Client connecting to 192.168.0.19, TCP port 5001
TCP window size: 20.7 KByte (default)
------------------------------------------------------------
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-10.0 sec   117 MBytes  98.2 Mbits/sec
[ 12]  0.0-10.0 sec  42.5 MBytes  35.6 Mbits/sec
[  8]  0.0-10.0 sec   131 MBytes   110 Mbits/sec
[  5]  0.0-10.0 sec   127 MBytes   107 Mbits/sec
[  3]  0.0-10.0 sec   118 MBytes  98.4 Mbits/sec
[ 10]  0.0-10.0 sec   130 MBytes   109 Mbits/sec
[  7]  0.0-10.0 sec   128 MBytes   107 Mbits/sec
[  9]  0.0-10.0 sec  83.2 MBytes  69.7 Mbits/sec
[  6]  0.0-10.0 sec   110 MBytes  92.5 Mbits/sec
[ 11]  0.0-10.0 sec   132 MBytes   110 Mbits/sec
[SUM]  0.0-10.0 sec  1.09 GBytes   936 Mbits/sec

I am not a network expert and until now we didn't try to
have the best performance the hardware can offer. We mainly
focused on features.

Regards,
-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From plagnioj at jcrosoft.com  Fri Apr 19 10:57:12 2013
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Fri, 19 Apr 2013 16:57:12 +0200
Subject: [PATCH 1/5] ARM: at91: at91sam9x5 RTC is not compatible with
 at91rm9200 one
In-Reply-To: <51715988.9060606@cogentembedded.com>
References: <cover.1366289869.git.nicolas.ferre@atmel.com>
 <864f10566b35864d469f6ff2913b9afaa0c69350.1366289869.git.nicolas.ferre@atmel.com>
 <51714C74.2030907@cogentembedded.com> <51714F47.5040006@atmel.com>
 <51715988.9060606@cogentembedded.com>
Message-ID: <20130419145712.GG4998@game.jcrosoft.org>

On 18:49 Fri 19 Apr     , Sergei Shtylyov wrote:
> On 19-04-2013 18:05, Nicolas Ferre wrote:
> 
> >>>Due to a bug with RTC IMR, we cannot consider at91sam9x5 RTC compatible
> >>>with the previous one. Modify DT compatibility string, even if the driver
> >>>is not yet modified to take it into account.
> 
> >>>Signed-off-by: Nicolas Ferre <nicolas.ferre at atmel.com>
> >>>---
> >>>   arch/arm/boot/dts/at91sam9x5.dtsi | 2 +-
> >>>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> >>>diff --git a/arch/arm/boot/dts/at91sam9x5.dtsi
> >>>b/arch/arm/boot/dts/at91sam9x5.dtsi
> >>>index a3d4464..58747f3 100644
> >>>--- a/arch/arm/boot/dts/at91sam9x5.dtsi
> >>>+++ b/arch/arm/boot/dts/at91sam9x5.dtsi
> >>>@@ -564,7 +564,7 @@
> >>>               };
> >>>
> >>>               rtc at fffffeb0 {
> >>>-                compatible = "atmel,at91rm9200-rtc";
> >>>+                compatible = "atmel,at91sam9x5-rtc";
> 
> >>    Do not use wildcards in the "compatible" prop values (I guess 'x' is
> >>a wildcard).
> 
> >Well, it is for naming a series of hardware, not for giving a generic
> >name that could cover different hardware.
> 
> >In the sense of Atmel it is our way to call the at91sam9x5 series of
> >SoC: you will see that the code that covers these SoCs is always named
> >like this.
> >In fact, the hardware contained in these SoC cannot be different from
> >one flavor of the family to the other.
> 
>    Nevertheless, the wildcards shouldn't be used. Use the name of
> e.g. the first member of the family.
we use this across others bindings

at91sam9x5 is the name of the Family

Best Regards,
J.


From eric at eukrea.com  Fri Apr 19 11:05:06 2013
From: eric at eukrea.com (=?UTF-8?q?Eric=20B=C3=A9nard?=)
Date: Fri, 19 Apr 2013 17:05:06 +0200
Subject: [PATCH] ARM: mx28: add dma channels for all auarts
Message-ID: <1366383906-25747-1-git-send-email-eric@eukrea.com>

Only auart0 was filled.
Tested on a custom i.MX283 board for ttyAPP1/2/3/4.

Signed-off-by: Eric B?nard <eric at eukrea.com>
---
 arch/arm/boot/dts/imx28.dtsi | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
index 25f2243..15933ed 100644
--- a/arch/arm/boot/dts/imx28.dtsi
+++ b/arch/arm/boot/dts/imx28.dtsi
@@ -886,6 +886,7 @@
 				compatible = "fsl,imx28-auart", "fsl,imx23-auart";
 				reg = <0x8006c000 0x2000>;
 				interrupts = <113 72 73>;
+				fsl,auart-dma-channel = <10 11>;
 				clocks = <&clks 45>;
 				status = "disabled";
 			};
@@ -894,6 +895,7 @@
 				compatible = "fsl,imx28-auart", "fsl,imx23-auart";
 				reg = <0x8006e000 0x2000>;
 				interrupts = <114 74 75>;
+				fsl,auart-dma-channel = <12 13>;
 				clocks = <&clks 45>;
 				status = "disabled";
 			};
@@ -902,6 +904,7 @@
 				compatible = "fsl,imx28-auart", "fsl,imx23-auart";
 				reg = <0x80070000 0x2000>;
 				interrupts = <115 76 77>;
+				fsl,auart-dma-channel = <14 15>;
 				clocks = <&clks 45>;
 				status = "disabled";
 			};
@@ -910,6 +913,7 @@
 				compatible = "fsl,imx28-auart", "fsl,imx23-auart";
 				reg = <0x80072000 0x2000>;
 				interrupts = <116 78 79>;
+				fsl,auart-dma-channel = <0 1>;
 				clocks = <&clks 45>;
 				status = "disabled";
 			};
-- 
1.7.11.7



From nicolas.ferre at atmel.com  Fri Apr 19 11:05:38 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Fri, 19 Apr 2013 17:05:38 +0200
Subject: [PATCH 1/5] ARM: at91: at91sam9x5 RTC is not compatible with
 at91rm9200 one
In-Reply-To: <51715988.9060606@cogentembedded.com>
References: <cover.1366289869.git.nicolas.ferre@atmel.com>
 <864f10566b35864d469f6ff2913b9afaa0c69350.1366289869.git.nicolas.ferre@atmel.com>
 <51714C74.2030907@cogentembedded.com> <51714F47.5040006@atmel.com>
 <51715988.9060606@cogentembedded.com>
Message-ID: <51715D42.5040706@atmel.com>

On 04/19/2013 04:49 PM, Sergei Shtylyov :
> On 19-04-2013 18:05, Nicolas Ferre wrote:
> 
>>>> Due to a bug with RTC IMR, we cannot consider at91sam9x5 RTC compatible
>>>> with the previous one. Modify DT compatibility string, even if the
>>>> driver
>>>> is not yet modified to take it into account.
> 
>>>> Signed-off-by: Nicolas Ferre <nicolas.ferre at atmel.com>
>>>> ---
>>>>    arch/arm/boot/dts/at91sam9x5.dtsi | 2 +-
>>>>    1 file changed, 1 insertion(+), 1 deletion(-)
> 
>>>> diff --git a/arch/arm/boot/dts/at91sam9x5.dtsi
>>>> b/arch/arm/boot/dts/at91sam9x5.dtsi
>>>> index a3d4464..58747f3 100644
>>>> --- a/arch/arm/boot/dts/at91sam9x5.dtsi
>>>> +++ b/arch/arm/boot/dts/at91sam9x5.dtsi
>>>> @@ -564,7 +564,7 @@
>>>>                };
>>>>
>>>>                rtc at fffffeb0 {
>>>> -                compatible = "atmel,at91rm9200-rtc";
>>>> +                compatible = "atmel,at91sam9x5-rtc";
> 
>>>     Do not use wildcards in the "compatible" prop values (I guess 'x' is
>>> a wildcard).
> 
>> Well, it is for naming a series of hardware, not for giving a generic
>> name that could cover different hardware.
> 
>> In the sense of Atmel it is our way to call the at91sam9x5 series of
>> SoC: you will see that the code that covers these SoCs is always named
>> like this.
>> In fact, the hardware contained in these SoC cannot be different from
>> one flavor of the family to the other.
> 
>    Nevertheless, the wildcards shouldn't be used. Use the name of e.g.
> the first member of the family.

There is not "first" there is no "last" they are all the same from a
hardware perspective. The only difference is activation of peripherals.

So, no, we will not change this.

Cf:
find arch/arm/boot/dts/ | xargs grep compatible | grep at91sam9x5

Best regards,
-- 
Nicolas Ferre


From u.kleine-koenig at pengutronix.de  Fri Apr 19 11:09:27 2013
From: u.kleine-koenig at pengutronix.de (Uwe =?iso-8859-1?Q?Kleine-K=F6nig?=)
Date: Fri, 19 Apr 2013 17:09:27 +0200
Subject: [PATCH v3] irqchip: Add support for ARMv7-M's NVIC
In-Reply-To: <alpine.LFD.2.02.1304180947070.21884@ionos>
References: <1366214540-31166-1-git-send-email-u.kleine-koenig@pengutronix.de>
 <alpine.LFD.2.02.1304180947070.21884@ionos>
Message-ID: <20130419150927.GE15233@pengutronix.de>

On Thu, Apr 18, 2013 at 11:35:22AM +0200, Thomas Gleixner wrote:
> On Wed, 17 Apr 2013, Uwe Kleine-K?nig wrote:
> > +struct nvic_bank_data {
> > +	/*
> > +	 * For irq i base holds nvic_base + 4 * i / 32. So you can access the
> > +	 * right ISER register (i.e ISER[i / 32]) by just taking base + ISER.
> > +	 * Ditto for ICER.
> > +	 */
> > +	void __iomem *base;
> > +};
> 
> What's the point of a struct with a single member? Why not having an
> array of base pointers ?
It gives a name to that single member and maybe makes future changes
easier. Obviously you could argue ...

When switching to generic irq chip this struct probably goes away, so I
suggest to postpone this discussion.

> > +static struct nvic_chip_data {
> > +	struct irq_domain *domain;
> > +	struct nvic_bank_data bdata[NVIC_MAX_BANKS];
> > +} nvic_chip_data;
> > +
> > +asmlinkage void __exception_irq_entry
> > +nvic_do_IRQ(irq_hw_number_t hwirq, struct pt_regs *regs)
> > +{
> > +	unsigned int irq = irq_linear_revmap(nvic_chip_data.domain, hwirq);
> > +
> > +	handle_IRQ(irq, regs);
> > +}
> > +
> > +static inline void __iomem *nvic_bank_base(struct irq_data *d)
> > +{
> > +	struct nvic_bank_data *bank_data = irq_data_get_irq_chip_data(d);
> > +	return bank_data->base;
> > +}
> > +
> > +static void nvic_mask_irq(struct irq_data *d)
> > +{
> > +	u32 mask = 1 << (d->hwirq % 32);
> > +
> > +	writel_relaxed(mask, nvic_bank_base(d) + NVIC_ICER);
> > +}
> > +
> > +static void nvic_unmask_irq(struct irq_data *d)
> > +{
> > +	u32 mask = 1 << (d->hwirq % 32);
> > +
> > +	writel_relaxed(mask, nvic_bank_base(d) + NVIC_ISER);
> > +}
> 
> How is that different from what the generic irq chip implementation
> does? The only difference is that mask is generated by d->hwirq and
> not by d->irq. And due to the fact, that you use a full linear mapping
> between hwirq and virq the generic code simply works.
I'm not sure what you mean when you say "full linear mapping". AFAICT
using irq_domain_add_linear doesn't imply that two consecutive hardware
irq numbers get consecutive Linux irq numbers, so using d->irq won't work.
 
> Even if it would not work, it would be trivial to extend the generic
> chip with that functionality instead of hacking another slightly
> different copy of the same thing.
I will try that and report back.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |


From tony at atomide.com  Fri Apr 19 11:21:17 2013
From: tony at atomide.com (Tony Lindgren)
Date: Fri, 19 Apr 2013 08:21:17 -0700
Subject: [PATCH] ARM: dts: omap4-panda: Add USB Host support
In-Reply-To: <5170FDD9.904@ti.com>
References: <1366015721-25608-1-git-send-email-rogerq@ti.com>
 <20130418200935.GD10155@atomide.com> <5170FDD9.904@ti.com>
Message-ID: <20130419152117.GE10155@atomide.com>

* Roger Quadros <rogerq at ti.com> [130419 01:23]:
> On 04/18/2013 11:09 PM, Tony Lindgren wrote:
> 
> > the naming should be mode0name.modename to be consistent. Here's
> > what I dumped out, please check and replace spaces with tabs:
> > 
> >                         0x82 0x10c      /* usbb1_ulpitll_clk.usbb1_ulpiphy_clk gpio84 INPUT_PULLDOWN | MODE4 */
> >                         0x84 0x4        /* usbb1_ulpitll_stp.usbb1_ulpiphy_stp gpio85 OUTPUT | MODE4 */
> >                         0x86 0x104      /* usbb1_ulpitll_dir.usbb1_ulpiphy_dir gpio86 INPUT | MODE4 */
> >                         0x88 0x104      /* usbb1_ulpitll_nxt.usbb1_ulpiphy_nxt gpio87 INPUT | MODE4 */
> >                         0x8a 0x104      /* usbb1_ulpitll_dat0.usbb1_ulpiphy_dat0 gpio88 INPUT | MODE4 */
> >                         0x8c 0x104      /* usbb1_ulpitll_dat1.usbb1_ulpiphy_dat1 gpio89 INPUT | MODE4 */
> >                         0x8e 0x104      /* usbb1_ulpitll_dat2.usbb1_ulpiphy_dat2 gpio90 INPUT | MODE4 */
> >                         0x90 0x104      /* usbb1_ulpitll_dat3.usbb1_ulpiphy_dat3 gpio91 INPUT | MODE4 */
> >                         0x92 0x104      /* usbb1_ulpitll_dat4.usbb1_ulpiphy_dat4 gpio92 INPUT | MODE4 */
> >                         0x94 0x104      /* usbb1_ulpitll_dat5.usbb1_ulpiphy_dat5 gpio93 INPUT | MODE4 */
> >                         0x96 0x104      /* usbb1_ulpitll_dat6.usbb1_ulpiphy_dat6 gpio94 INPUT | MODE4 */
> >                         0x98 0x104      /* usbb1_ulpitll_dat7.usbb1_ulpiphy_dat7 gpio95 INPUT | MODE4 */
> 
> I don't think gpioXX is necessary as we aren't using any of them as GPIOs.

Oops sorry yeah please check as that's something I just dumped
from the system. The gpio numbering is just data for debugging
that you can leave out. Also check please check I dumped the right
pins, I just grepped for usbb1.

Regards,

Tony


From festevam at gmail.com  Fri Apr 19 11:26:33 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Fri, 19 Apr 2013 12:26:33 -0300
Subject: [PATCH] ARM: mx28: add dma channels for all auarts
In-Reply-To: <1366383906-25747-1-git-send-email-eric@eukrea.com>
References: <1366383906-25747-1-git-send-email-eric@eukrea.com>
Message-ID: <CAOMZO5B9mL9rzYc9zHjJ_994u=HVerHGa+C+Lqc8VJmse8ak2Q@mail.gmail.com>

Hi Eric,

On Fri, Apr 19, 2013 at 12:05 PM, Eric B?nard <eric at eukrea.com> wrote:
> Only auart0 was filled.
> Tested on a custom i.MX283 board for ttyAPP1/2/3/4.
>
> Signed-off-by: Eric B?nard <eric at eukrea.com>
> ---
>  arch/arm/boot/dts/imx28.dtsi | 4 ++++
>  1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
> index 25f2243..15933ed 100644
> --- a/arch/arm/boot/dts/imx28.dtsi
> +++ b/arch/arm/boot/dts/imx28.dtsi
> @@ -886,6 +886,7 @@
>                                 compatible = "fsl,imx28-auart", "fsl,imx23-auart";
>                                 reg = <0x8006c000 0x2000>;
>                                 interrupts = <113 72 73>;
> +                               fsl,auart-dma-channel = <10 11>;

Now we use the generic 'dmas' binding to passing such information.

If you look at linux-next tree these UART dma channels are already
been passed via the new 'dmas' method:

			auart1: serial at 8006c000 {
				compatible = "fsl,imx28-auart", "fsl,imx23-auart";
				reg = <0x8006c000 0x2000>;
				interrupts = <113 72 73>;
				dmas = <&dma_apbx 10>, <&dma_apbx 11>;
				dma-names = "rx", "tx";
				clocks = <&clks 45>;
				status = "disabled";
			};


From tony at atomide.com  Fri Apr 19 11:36:14 2013
From: tony at atomide.com (Tony Lindgren)
Date: Fri, 19 Apr 2013 08:36:14 -0700
Subject: [PATCH] gpio/omap: ensure gpio context is initialised
In-Reply-To: <51715772.9020003@ti.com>
References: <1366230707-32681-1-git-send-email-jon-hunter@ti.com>
 <871ua734mv.fsf@linaro.org> <51707D7C.1050600@ti.com>
 <5170911C.6010507@ti.com> <51709499.8030208@ti.com>
 <5170E4EE.7090100@ti.com> <87sj2mzkcf.fsf@linaro.org>
 <51715772.9020003@ti.com>
Message-ID: <20130419153614.GF10155@atomide.com>

* Santosh Shilimkar <santosh.shilimkar at ti.com> [130419 07:43]:
> On Friday 19 April 2013 07:35 PM, Kevin Hilman wrote:
> > Santosh Shilimkar <santosh.shilimkar at ti.com> writes:
> > 
> >> On Friday 19 April 2013 06:19 AM, Jon Hunter wrote:
> >>>
> >>> On 04/18/2013 07:34 PM, Jon Hunter wrote:
> >>>>
> >>>> On 04/18/2013 06:10 PM, Jon Hunter wrote:
> >>>>> On 04/18/2013 04:34 PM, Kevin Hilman wrote:
> >>>>
> >>>> ...
> >>>>
> >>>>>> Why not just init context right here if bank->loses_context &&
> >>>>>> !bank->context_valid?
> >>>>
> >>>> I really like this idea a lot. It can really clean-up the code
> >>>> and really make it much more readable. Before we were playing 
> >>>> some tricks with when we init'ed the get_context_loss_count()
> >>>> function pointer. How about the below?
> >>>>
> >>>> Tony, care to re-test?

Still works thanks:

Tested-by: Tony Lindgren <tony at atomide.com>

> > Assuming this driver could become a module someday (not terribly likely,
> > I know), but context_valid would have meaning for each module reload.
> > 
> I don't think GPIO can ever be a module(at least on OMAP) considering the way
> it is used in many SOCs and hence the objection on that flag. GPIO is really
> an infrastructure driver which is needed to be always available for the
> client drivers to work. 

Not really related to this fix.. But when booting with initramfs, we should
be able to make everything into loadable modules except things that are related
to enabling timers and interrupts. This is important for distros to be able
do generic kernels. Surely for mounting non-initramfs root GPIO is most
likely needed though :)

Regards,

Tony


From haojian.zhuang at gmail.com  Fri Apr 19 11:42:53 2013
From: haojian.zhuang at gmail.com (Haojian Zhuang)
Date: Fri, 19 Apr 2013 23:42:53 +0800
Subject: [PATCH 4/4] ARM: mmp: add SMP support for pxa988
In-Reply-To: <20130419140938.GT14496@n2100.arm.linux.org.uk>
References: <1365651547-11583-1-git-send-email-zhangwm@marvell.com>
 <CAN1soZxCX1oUg69MTy0ZAL2vH8SOywDBaZHJ7wgnwgasxPAPdQ@mail.gmail.com>
 <20130419140938.GT14496@n2100.arm.linux.org.uk>
Message-ID: <CAN1soZwsC6yjH3nG7zUvRf9x9SLuEC4b9DtqsTGWQhacu78EbQ@mail.gmail.com>

On Fri, Apr 19, 2013 at 10:09 PM, Russell King - ARM Linux
<linux at arm.linux.org.uk> wrote:
> On Sat, Apr 13, 2013 at 09:08:12PM +0800, Haojian Zhuang wrote:
>> On Thu, Apr 11, 2013 at 11:39 AM, Neil Zhang <zhangwm at marvell.com> wrote:
>> > +       /*
>> > +        * Synchronise with the boot thread.
>> > +        */
>> > +       spin_lock(&boot_lock);
>> > +       spin_unlock(&boot_lock);
>> Lock & unlock without protecting anything. If so, you can remove this.
>
> ... which means you don't understand what is going on in this code,
> and probably didn't read the comment above this fragment.  The above
> is to synchronise with the code below - again, read the comment at
> the spin unlock in this function, remembering that the above code
> and the code below runs concurrently on two different CPUs:
>
Yes, I misunderstood it. Thanks for your correction.

Regards
Haojian


From nicolas.pitre at linaro.org  Fri Apr 19 11:47:27 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Fri, 19 Apr 2013 11:47:27 -0400 (EDT)
Subject: [PATCH v6 1/4] arm: introduce psci_smp_ops
In-Reply-To: <alpine.DEB.2.02.1304191035360.7254@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1304031239550.5078@kaball.uk.xensource.com>
 <1365167495-18508-1-git-send-email-stefano.stabellini@eu.citrix.com>
 <20130418161341.GB14496@n2100.arm.linux.org.uk>
 <alpine.DEB.2.02.1304181714560.7254@kaball.uk.xensource.com>
 <alpine.LFD.2.03.1304181237480.17375@syhkavp.arg>
 <alpine.DEB.2.02.1304181749260.7254@kaball.uk.xensource.com>
 <alpine.LFD.2.03.1304181336280.17375@syhkavp.arg>
 <alpine.DEB.2.02.1304191035360.7254@kaball.uk.xensource.com>
Message-ID: <alpine.LFD.2.03.1304191146230.17375@syhkavp.arg>

On Fri, 19 Apr 2013, Stefano Stabellini wrote:

> On Thu, 18 Apr 2013, Nicolas Pitre wrote:
> > On Thu, 18 Apr 2013, Stefano Stabellini wrote:
> > 
> > > On Thu, 18 Apr 2013, Nicolas Pitre wrote:
> > > > On Thu, 18 Apr 2013, Stefano Stabellini wrote:
> > > > 
> > > > > On Thu, 18 Apr 2013, Russell King - ARM Linux wrote:
> > > > > > This should allow the Xen problem to be resolved, because Xen will
> > > > > > provide the PSCI operations, and it's correct in that case to override
> > > > > > the platform's SMP operations.
> > > > > 
> > > > > Yes, increasing the priority of PSCI helps Xen a lot.
> > > > > In order to completely solve the issue for Xen though, another patch is
> > > > > needed (http://marc.info/?l=linux-kernel&m=136630106201968&w=2) because
> > > > > of the introduction of smp_init.
> > > > 
> > > > Please look at the latest smp_init patch version I sent to you.  It 
> > > > shouldn't conflict with Xen any longer.  It now returns a bool result 
> > > > depending on whether it did set up smp_ops or not.
> > > 
> > > CPUs are virtualized by Xen and do not reflect or expose the underlying
> > > SMP hardware and firmware features, so an hardware specific smp_init
> > > cannot run.
> > > 
> > > So the smp_init patch still breaks Xen because even if smp_init can fail
> > > graciously, executing a platform specific smp_init function that tries
> > > to access registers and memory regions that are not present is going to
> > > cause an undefined behaviour.
> > 
> > It won't access hardware but just look into the DT and return false if 
> > nothing interesting is found.  At which point the next attempt in the 
> > priority list is PSCI by default.
> 
> OK, that should work.
> I am going to drop "xen/arm: introduce xen_early_init, use PSCI on xen".
> 
> We'll have to be careful enforcing that future smp_init implementations
> use DT rather than probing registers. Maybe I should add a comment to
> the smp_init patch to clarify that?

No one should be probing registers without making sure it is safe to do 
so.  Even on non virtualized hardware this can be a dangerous thing to 
do.


Nicolas


From nerv at dawncrow.de  Fri Apr 19 11:54:35 2013
From: nerv at dawncrow.de (=?ISO-8859-15?Q?Andr=E9_Hentschel?=)
Date: Fri, 19 Apr 2013 17:54:35 +0200
Subject: [PATCHv2] arm: Preserve TPIDRURW on context switch
Message-ID: <517168BB.3070903@dawncrow.de>

From: =?UTF-8?q?Andr=C3=A9=20Hentschel?= <nerv at dawncrow.de>

There are more and more applications coming to WinRT, Wine could support them,
but mostly they expect to have the thread environment block (TEB) in TPIDRURW.
This register must be preserved per thread instead of being cleared.

Signed-off-by: Andr? Hentschel <nerv at dawncrow.de>

---
This patch is against a86d52667d8eda5de39393ce737794403bdce1eb

I could only test it with kernel 3.4.6

 arch/arm/include/asm/thread_info.h |    2 +-
 arch/arm/include/asm/tls.h         |   32 +++++++++++++++++++-------------
 arch/arm/kernel/entry-armv.S       |    9 ++++-----
 arch/arm/kernel/process.c          |    2 +-
 arch/arm/kernel/ptrace.c           |    2 +-
 arch/arm/kernel/traps.c            |    4 ++--
 6 files changed, 28 insertions(+), 23 deletions(-)

diff --git a/arch/arm/include/asm/thread_info.h b/arch/arm/include/asm/thread_info.h
index cddda1f..bb5b48d 100644
--- a/arch/arm/include/asm/thread_info.h
+++ b/arch/arm/include/asm/thread_info.h
@@ -58,7 +58,7 @@ struct thread_info {
 	struct cpu_context_save	cpu_context;	/* cpu context */
 	__u32			syscall;	/* syscall number */
 	__u8			used_cp[16];	/* thread used copro */
-	unsigned long		tp_value;
+	unsigned long		tp_value[2];
 #ifdef CONFIG_CRUNCH
 	struct crunch_state	crunchstate;
 #endif
diff --git a/arch/arm/include/asm/tls.h b/arch/arm/include/asm/tls.h
index 73409e6..ea0189e 100644
--- a/arch/arm/include/asm/tls.h
+++ b/arch/arm/include/asm/tls.h
@@ -2,29 +2,35 @@
 #define __ASMARM_TLS_H
 
 #ifdef __ASSEMBLY__
-	.macro set_tls_none, tp, tmp1, tmp2
+	.macro set_tls_none, ntp, ptp, tmp1, tmp2
 	.endm
 
-	.macro set_tls_v6k, tp, tmp1, tmp2
-	mcr	p15, 0, \tp, c13, c0, 3		@ set TLS register
-	mov	\tmp1, #0
-	mcr	p15, 0, \tmp1, c13, c0, 2	@ clear user r/w TLS register
+	.macro set_tls_v6k, ntp, ptp, tmp1, tmp2
+	mrc	p15, 0, \tmp2, c13, c0, 2		@ get user r/w TLS register
+	str	\tmp2, [\ptp, #4]
+	ldrd	\tmp1, \tmp2, [\ntp]
+	mcr	p15, 0, \tmp1, c13, c0, 3	@ set user r/o TLS register
+	mcr	p15, 0, \tmp2, c13, c0, 2	@ set user r/w TLS register
 	.endm
 
-	.macro set_tls_v6, tp, tmp1, tmp2
+	.macro set_tls_v6, ntp, ptp, tmp1, tmp2
 	ldr	\tmp1, =elf_hwcap
 	ldr	\tmp1, [\tmp1, #0]
 	mov	\tmp2, #0xffff0fff
 	tst	\tmp1, #HWCAP_TLS		@ hardware TLS available?
-	mcrne	p15, 0, \tp, c13, c0, 3		@ yes, set TLS register
-	movne	\tmp1, #0
-	mcrne	p15, 0, \tmp1, c13, c0, 2	@ clear user r/w TLS register
-	streq	\tp, [\tmp2, #-15]		@ set TLS value at 0xffff0ff0
+	mrcne	p15, 0, \tmp2, c13, c0, 2		@ get user r/w TLS register
+	strne	\tmp2, [\ptp, #4]
+	ldrdne	\tmp1, \tmp2, [\ntp]
+	ldreq	\tmp1, [\ntp]
+	mcrne	p15, 0, \tmp1, c13, c0, 3	@ yes, set user r/o TLS register
+	mcrne	p15, 0, \tmp2, c13, c0, 2	@ set user r/w TLS register
+	streq	\tmp1, [\tmp2, #-15]		@ set TLS value at 0xffff0ff0
 	.endm
 
-	.macro set_tls_software, tp, tmp1, tmp2
-	mov	\tmp1, #0xffff0fff
-	str	\tp, [\tmp1, #-15]		@ set TLS value at 0xffff0ff0
+	.macro set_tls_software, ntp, ptp, tmp1, tmp2
+	ldr	\tmp1, [\ntp]
+	mov	\tmp2, #0xffff0fff
+	str	\tmp1, [\tmp2, #-15]		@ set TLS value at 0xffff0ff0
 	.endm
 #endif
 
diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
index 0f82098..78ce1c6 100644
--- a/arch/arm/kernel/entry-armv.S
+++ b/arch/arm/kernel/entry-armv.S
@@ -728,21 +728,20 @@ ENTRY(__switch_to)
  UNWIND(.fnstart	)
  UNWIND(.cantunwind	)
 	add	ip, r1, #TI_CPU_SAVE
-	ldr	r3, [r2, #TI_TP_VALUE]
  ARM(	stmia	ip!, {r4 - sl, fp, sp, lr} )	@ Store most regs on stack
  THUMB(	stmia	ip!, {r4 - sl, fp}	   )	@ Store most regs on stack
  THUMB(	str	sp, [ip], #4		   )
  THUMB(	str	lr, [ip], #4		   )
-#ifdef CONFIG_CPU_USE_DOMAINS
-	ldr	r6, [r2, #TI_CPU_DOMAIN]
-#endif
-	set_tls	r3, r4, r5
+	add	r3, r2, #TI_TP_VALUE
+	add	r4, r1, #TI_TP_VALUE
+	set_tls	r3, r4, r6, r7
 #if defined(CONFIG_CC_STACKPROTECTOR) && !defined(CONFIG_SMP)
 	ldr	r7, [r2, #TI_TASK]
 	ldr	r8, =__stack_chk_guard
 	ldr	r7, [r7, #TSK_STACK_CANARY]
 #endif
 #ifdef CONFIG_CPU_USE_DOMAINS
+	ldr	r6, [r2, #TI_CPU_DOMAIN]
 	mcr	p15, 0, r6, c3, c0, 0		@ Set domain register
 #endif
 	mov	r5, r0
diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c
index 047d3e4..b3171c4 100644
--- a/arch/arm/kernel/process.c
+++ b/arch/arm/kernel/process.c
@@ -395,7 +395,7 @@ copy_thread(unsigned long clone_flags, unsigned long stack_start,
 	clear_ptrace_hw_breakpoint(p);
 
 	if (clone_flags & CLONE_SETTLS)
-		thread->tp_value = childregs->ARM_r3;
+		thread->tp_value[0] = childregs->ARM_r3;
 
 	thread_notify(THREAD_NOTIFY_COPY, thread);
 
diff --git a/arch/arm/kernel/ptrace.c b/arch/arm/kernel/ptrace.c
index 03deeff..2bc1514 100644
--- a/arch/arm/kernel/ptrace.c
+++ b/arch/arm/kernel/ptrace.c
@@ -849,7 +849,7 @@ long arch_ptrace(struct task_struct *child, long request,
 #endif
 
 		case PTRACE_GET_THREAD_AREA:
-			ret = put_user(task_thread_info(child)->tp_value,
+			ret = put_user(task_thread_info(child)->tp_value[0],
 				       datap);
 			break;
 
diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
index 1c08911..f9d6259 100644
--- a/arch/arm/kernel/traps.c
+++ b/arch/arm/kernel/traps.c
@@ -588,7 +588,7 @@ asmlinkage int arm_syscall(int no, struct pt_regs *regs)
 		return regs->ARM_r0;
 
 	case NR(set_tls):
-		thread->tp_value = regs->ARM_r0;
+		thread->tp_value[0] = regs->ARM_r0;
 		if (tls_emu)
 			return 0;
 		if (has_tls_reg) {
@@ -706,7 +706,7 @@ static int get_tp_trap(struct pt_regs *regs, unsigned int instr)
 	int reg = (instr >> 12) & 15;
 	if (reg == 15)
 		return 1;
-	regs->uregs[reg] = current_thread_info()->tp_value;
+	regs->uregs[reg] = current_thread_info()->tp_value[0];
 	regs->ARM_pc += 4;
 	return 0;
 }
-- 
1.7.10.4




From itooo at itooo.com  Fri Apr 19 12:02:19 2013
From: itooo at itooo.com (Greg)
Date: Fri, 19 Apr 2013 18:02:19 +0200
Subject: MVEBU and MVNETA driver
In-Reply-To: <51715BC7.3040906@free-electrons.com>
References: <5171419C.2090003@itooo.com> <20130419131237.GC22440@1wt.eu>
 <517150FF.9010806@itooo.com> <20130419144324.GD22440@1wt.eu>
 <51715BC7.3040906@free-electrons.com>
Message-ID: <51716A8B.9080903@itooo.com>

Le 19/04/2013 16:59, Gregory CLEMENT a ?crit :
> On 04/19/2013 04:43 PM, Willy Tarreau wrote:
>> On Fri, Apr 19, 2013 at 04:13:19PM +0200, Greg wrote:
>>> Willy, thanks for your fast an accurate answer, this seems to solve the
>>> stability issue but not the performance issue.
>> OK.
>>
>>> Please look at this strange behavior : 1 iperf will only transmit at
>>> ~100Mbps, 100 parallel iperf will transmit at ~950Mb. Reception is not
>>> an issue.
>>> I'm thinking of a socket <-> txQ relationship that would limit
>>> transmission rate, but I have no idea on how this is implemented.
>> Strange, I have not experienced this. Yes a socket size limit could be
>> the reason. Have you tried with netcat or any simple TCP server instead ?
>>
> I also have this behavior:
> iperf -c 192.168.0.19 -d
> ------------------------------------------------------------
> Server listening on TCP port 5001
> TCP window size: 85.3 KByte (default)
> ------------------------------------------------------------
> ------------------------------------------------------------
> Client connecting to 192.168.0.19, TCP port 5001
> TCP window size: 20.7 KByte (default)
> ------------------------------------------------------------
> [  5] local 192.168.0.37 port 48473 connected with 192.168.0.19 port 5001
> [  4] local 192.168.0.37 port 5001 connected with 192.168.0.19 port 36987
> [ ID] Interval       Transfer     Bandwidth
> [  5]  0.0-10.0 sec   128 MBytes   107 Mbits/sec
> [  4]  0.0-10.0 sec  1.07 GBytes   919 Mbits/sec
>
> but I only need 10 thread in iperf to be close to the Gb
> ------------------------------------------------------------
> Client connecting to 192.168.0.19, TCP port 5001
> TCP window size: 20.7 KByte (default)
> ------------------------------------------------------------
> [ ID] Interval       Transfer     Bandwidth
> [  4]  0.0-10.0 sec   117 MBytes  98.2 Mbits/sec
> [ 12]  0.0-10.0 sec  42.5 MBytes  35.6 Mbits/sec
> [  8]  0.0-10.0 sec   131 MBytes   110 Mbits/sec
> [  5]  0.0-10.0 sec   127 MBytes   107 Mbits/sec
> [  3]  0.0-10.0 sec   118 MBytes  98.4 Mbits/sec
> [ 10]  0.0-10.0 sec   130 MBytes   109 Mbits/sec
> [  7]  0.0-10.0 sec   128 MBytes   107 Mbits/sec
> [  9]  0.0-10.0 sec  83.2 MBytes  69.7 Mbits/sec
> [  6]  0.0-10.0 sec   110 MBytes  92.5 Mbits/sec
> [ 11]  0.0-10.0 sec   132 MBytes   110 Mbits/sec
> [SUM]  0.0-10.0 sec  1.09 GBytes   936 Mbits/sec
>
> I am not a network expert and until now we didn't try to
> have the best performance the hardware can offer. We mainly
> focused on features.
>
I've got the same numbers here.
A simple tool like netcat shows ~470Mbps but this limited by the CPU.
Iperf isn't CPU limited

The same test with Marvell LSP shows ~940Mbps in both directions.

Regards,


From eric at eukrea.com  Fri Apr 19 12:11:34 2013
From: eric at eukrea.com (Eric =?UTF-8?B?QsOpbmFyZA==?=)
Date: Fri, 19 Apr 2013 18:11:34 +0200
Subject: [PATCH] ARM: mx28: add dma channels for all auarts
In-Reply-To: <CAOMZO5B9mL9rzYc9zHjJ_994u=HVerHGa+C+Lqc8VJmse8ak2Q@mail.gmail.com>
References: <1366383906-25747-1-git-send-email-eric@eukrea.com>
 <CAOMZO5B9mL9rzYc9zHjJ_994u=HVerHGa+C+Lqc8VJmse8ak2Q@mail.gmail.com>
Message-ID: <20130419181134.06eded8f@e6520eb>

Hi Fabio,

Le Fri, 19 Apr 2013 12:26:33 -0300,
Fabio Estevam <festevam at gmail.com> a ?crit :
> On Fri, Apr 19, 2013 at 12:05 PM, Eric B?nard <eric at eukrea.com> wrote:
> > Only auart0 was filled.
> > Tested on a custom i.MX283 board for ttyAPP1/2/3/4.
> >
> > Signed-off-by: Eric B?nard <eric at eukrea.com>
> > ---
> >  arch/arm/boot/dts/imx28.dtsi | 4 ++++
> >  1 file changed, 4 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
> > index 25f2243..15933ed 100644
> > --- a/arch/arm/boot/dts/imx28.dtsi
> > +++ b/arch/arm/boot/dts/imx28.dtsi
> > @@ -886,6 +886,7 @@
> >                                 compatible = "fsl,imx28-auart", "fsl,imx23-auart";
> >                                 reg = <0x8006c000 0x2000>;
> >                                 interrupts = <113 72 73>;
> > +                               fsl,auart-dma-channel = <10 11>;
> 
> Now we use the generic 'dmas' binding to passing such information.
> 
> If you look at linux-next tree these UART dma channels are already
> been passed via the new 'dmas' method:
> 
> 			auart1: serial at 8006c000 {
> 				compatible = "fsl,imx28-auart", "fsl,imx23-auart";
> 				reg = <0x8006c000 0x2000>;
> 				interrupts = <113 72 73>;
> 				dmas = <&dma_apbx 10>, <&dma_apbx 11>;
> 				dma-names = "rx", "tx";
> 				clocks = <&clks 45>;
> 				status = "disabled";
> 			};

OK so forget my patch it was against 3.9-rc

Eric


From catalin.marinas at arm.com  Fri Apr 19 12:12:01 2013
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Fri, 19 Apr 2013 17:12:01 +0100
Subject: [RFC] arm64: Early printk support for virtio-mmio console devices.
In-Reply-To: <CAFEAcA_WfYpyvq54rZqS8JZkmDF5JXB+CNHFH5CnrhKun52uzA@mail.gmail.com>
References: <CAAHg+HhajHFC=1nh6YQNgpf=Na2FqcsYJ=t+ag9QiTg6TxUz9w@mail.gmail.com>
 <bb1193983de3ea9f4df1a570441df34c@localhost>
 <CAAHg+HhtCorArCmx=ha0=64+SJZiizzrDUKSPLV=N+OzO8zAxQ@mail.gmail.com>
 <20130419090558.GA13283@mudshark.cambridge.arm.com>
 <CAAHg+HipCX2ma6brxj9Kgc3ew39b5e30grLwyun9CViif-5wZQ@mail.gmail.com>
 <20130419092752.GB13283@mudshark.cambridge.arm.com>
 <CAFEAcA8j124G=vaHObJ_w5wOhUiS3KYKbjMnigbnr6mgwFxZUg@mail.gmail.com>
 <CAAHg+Hg=t97SJ0JPZYgrZaL+zimo-wbezwaj1BQvHqE-vf4VDA@mail.gmail.com>
 <20130419093953.GD13283@mudshark.cambridge.arm.com>
 <CAFEAcA_WfYpyvq54rZqS8JZkmDF5JXB+CNHFH5CnrhKun52uzA@mail.gmail.com>
Message-ID: <20130419161201.GA5383@localhost.cambridge.arm.com>

On Fri, Apr 19, 2013 at 11:05:47AM +0100, Peter Maydell wrote:
> On 19 April 2013 10:39, Will Deacon <will.deacon at arm.com> wrote:
> > The point of mach-virt is that it is completely parameterised. So, if you're
> > not emulating an 8250, then don't tell the kernel that you have one!
> > Similarly, if you *do* emulate it, then either create a device-tree node for
> > it or pass the appropriate earlyprintk= string on the command line.
> >
> > As far as kvmtool is concerned, we'd probably have a new command-line option
> > for arm64, allowing you to specify the early console device.
> 
> Please make the kernel pick the device out of the device tree
> blob. The whole point of device tree is that it's how to tell
> the kernel where things live -- making kvmtool/QEMU and/or the
> user also have to mess with the kernel command line is awkward
> and annoying.

For a normal console device, it indeed needs to get it from the DT. For
early console, you want it earlier than DT parsing so we pass it on the
kernel command line via the earlyprintk= parameter.

arm64 earlyprintk support for 8250 is already queued for 3.10 (and in
-next).

-- 
Catalin


From gregory.clement at free-electrons.com  Fri Apr 19 12:12:09 2013
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Fri, 19 Apr 2013 18:12:09 +0200
Subject: [GIT PULL V2 1/4] mvebu driver changes for v3.10
In-Reply-To: <517155FE.30406@free-electrons.com>
References: <20130415182824.GN28693@titan.lakedaemon.net>
 <20130416150416.GB28693@titan.lakedaemon.net>
 <20130418053002.GB12816@quad.lixom.net>
 <CAOesGMjD-VAZW-zL-jm65xSJkFLpzbYOdvN6-5pV1OW_vJDCWg@mail.gmail.com>
 <517155FE.30406@free-electrons.com>
Message-ID: <51716CD9.4030901@free-electrons.com>

On 04/19/2013 04:34 PM, Gregory CLEMENT wrote:
> On 04/19/2013 04:09 PM, Olof Johansson wrote:
>> On Wed, Apr 17, 2013 at 10:30 PM, Olof Johansson <olof at lixom.net> wrote:
>>> On Tue, Apr 16, 2013 at 11:04:16AM -0400, Jason Cooper wrote:
>>>>
>>>> The following changes since commit 8bb9660418e05bb1845ac1a2428444d78e322cc7:
>>>>
>>>>   Linux 3.9-rc4 (2013-03-23 16:52:44 -0700)
>>>>
>>>> are available in the git repository at:
>>>>
>>>>   git://git.infradead.org/users/jcooper/linux.git tags/drivers-3.10-2
>>>>
>>>> for you to fetch changes up to ac7b07ec369324063e52c37b3fb0ad1a1814d879:
>>>>
>>>>   clk: mvebu: add more PCIe clocks for Armada XP (2013-04-16 14:47:01 +0000)
>>>
>>> Pulled, thanks.
>>
>> Dropped due to build errors on powerpc64. 3.11 material now.
>>
> 
> Wait! That means dropping _all_ the change done in mvebu for 3.10 just
> for one patch in the of/pci part?
> 
> Jason, did you take the accurate patch? Because according to Grant
> Likely, the build didn't fail on ppc, see:
> 
> http://www.spinics.net/lists/arm-kernel/msg238517.html

I investigated it a little more and my first assumption was wrong,
the faulty commit was not the one I think. I didn't work directly
on the PCIe part, and Thomas who did it is currently in the plane.

So instead of throwing everything, could you just remove the
offending commit, AFAIK we don't need it yet, (the patch
depending of this one are located in the mvebu-late/pcie branch):

9ecbe03 pci: infrastructure to add drivers in drivers/pci/host

Thanks!

> 
> 
>>
>> -Olof
>>
> 
> 


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From tony at atomide.com  Fri Apr 19 12:12:57 2013
From: tony at atomide.com (Tony Lindgren)
Date: Fri, 19 Apr 2013 09:12:57 -0700
Subject: linux-next ARM multi-platform randconfig errors
In-Reply-To: <5170B4C6.1030300@gmail.com>
References: <5170B4C6.1030300@gmail.com>
Message-ID: <20130419161257.GI10155@atomide.com>

* Rob Herring <robherring2 at gmail.com> [130418 20:11]:
> Current errors in linux-next for ARM multi-platform randconfig builds.
> 
> Rob
> 
> arch/arm/mach-omap2/built-in.o:dss-common.c:(.init.text+0x6830): more undefined references to `usb_bind_phy' follow

Felipe & Roger, can you guys take a look at the usb_bind_phy issue
in linux next? I have not seen that in the multiplatform randconfigs
I've built, but I have had some omap2+ specific things enabled there.

> board-paz00.c:(.text+0x1ecc): undefined reference to `cpu_do_idle'
> board-paz00.c:(.text+0x1f4c): undefined reference to `cpu_do_idle'
> drivers/built-in.o:(.data+0x327b8): undefined reference to `cpufreq_freq_attr_scaling_available_freqs'
> drivers/built-in.o:(.data+0x9ae0): undefined reference to `uart_console_device'
> board-paz00.c:(.text+0x1ecc): undefined reference to `cpu_do_idle'
> board-paz00.c:(.text+0x1f4c): undefined reference to `cpu_do_idle'
> drivers/built-in.o:(.data+0x327b8): undefined reference to `cpufreq_freq_attr_scaling_available_freqs'
> drivers/built-in.o:(.data+0x9ae0): undefined reference to `uart_console_device'
> drivers/built-in.o:drivers/md/dm-cache-target.c:429: more undefined references to `__udivdi3' follow
> dss-common.c:(.cpuinit.text+0x38): undefined reference to `omap_get_wakeupgen_base'
> dss-common.c:(.cpuinit.text+0x48): undefined reference to `omap_secure_apis_support'
> dss-common.c:(.init.text+0x3db0): undefined reference to `omap_get_wakeupgen_base'
> dss-common.c:(.init.text+0x3dcc): undefined reference to `omap_secure_apis_support'
> dss-common.c:(.init.text+0x61b8): undefined reference to `usb_bind_phy'
> dss-common.c:(.init.text+0x6314): undefined reference to `usb_bind_phy'
> dss-common.c:(.init.text+0x6488): undefined reference to `usb_bind_phy'
> dss-common.c:(.init.text+0x65ac): undefined reference to `usb_bind_phy'
> dss-common.c:(.ref.text+0x10): undefined reference to `omap_get_wakeupgen_base'
> dss-common.c:(.ref.text+0x18): undefined reference to `omap_secure_apis_support'
> dss-common.c:(.ref.text+0x54): undefined reference to `omap4_hotplug_cpu'
> dss-common.c:(.ref.text+0x58): undefined reference to `omap_secure_apis_support'
> dss-common.c:(.text+0x11b5c): undefined reference to `usb_bind_phy'

Tomi, can you take a look at the dss-common.c one? That should be
reproducable with omap2plus_defconfig and modifying some options
there.

> ERROR: "of_get_next_parent" [drivers/media/v4l2-core/videodev.ko] undefined!
> extcon-class.c:(.text+0x4ac4): undefined reference to `abx500_mask_and_set_register_interruptible'
> extcon-class.c:(.text+0x4b34): undefined reference to `abx500_mask_and_set_register_interruptible'
> extcon-class.c:(.text+0x5164): undefined reference to `abx500_get_register_interruptible'
> extcon-class.c:(.text+0x52b4): undefined reference to `abx500_mask_and_set_register_interruptible'
> extcon-class.c:(.text+0x5304): undefined reference to `abx500_mask_and_set_register_interruptible'
> extcon-class.c:(.text+0x57a4): undefined reference to `abx500_get_register_interruptible'
> platform-spi_imx.c:(.init.text+0x4a20): undefined reference to `reset_controller_register'
> platform-spi_imx.c:(.init.text+0x677c): undefined reference to `reset_controller_register'
> platform-spi_imx.c:(.init.text+0x70c4): undefined reference to `reset_controller_register'
> platform-spi_imx.c:(.init.text+0x825c): undefined reference to `reset_controller_register'
> platform-spi_imx.c:(.text+0x1ff0): undefined reference to `otg_ulpi_create'
> tegra30-mc.c:(.exit.text+0x144): undefined reference to `uart_unregister_driver'
> tegra30-mc.c:(.init.text+0x1e4c): undefined reference to `uart_register_driver'
> tegra30-mc.c:(.init.text+0x1e6c): undefined reference to `uart_unregister_driver'
> tegra30-mc.c:(.init.text+0x1ee0): undefined reference to `uart_parse_options'
> tegra30-mc.c:(.init.text+0x1f04): undefined reference to `uart_set_options'
> tegra30-mc.c:(.text+0x309d8): undefined reference to `uart_resume_port'
> tegra30-mc.c:(.text+0x309fc): undefined reference to `uart_suspend_port'
> tegra30-mc.c:(.text+0x30a94): undefined reference to `uart_handle_dcd_change'
> tegra30-mc.c:(.text+0x30aa8): undefined reference to `uart_handle_cts_change'
> tegra30-mc.c:(.text+0x30e5c): undefined reference to `uart_console_write'
> tegra30-mc.c:(.text+0x31008): undefined reference to `uart_remove_one_port'
> tegra30-mc.c:(.text+0x315b0): undefined reference to `do_SAK'
> tegra30-mc.c:(.text+0x3161c): undefined reference to `uart_insert_char'
> tegra30-mc.c:(.text+0x317d0): undefined reference to `uart_get_baud_rate'
> tegra30-mc.c:(.text+0x318bc): undefined reference to `uart_update_timeout'
> tegra30-mc.c:(.text+0x32c94): undefined reference to `uart_add_one_port'
> tegra30-mc.c:(.text+0x32e94): undefined reference to `uart_write_wakeup'
> tegra30-mc.c:(.text+0x33008): undefined reference to `uart_insert_char'
> tegra30-mc.c:(.text+0x33030): undefined reference to `tty_flip_buffer_push'
> /var/lib/jenkins/jobs/linux-randconfig/workspace/arch/arm/include/asm/kvm_vgic.h:59:11: error: 'CONFIG_KVM_ARM_MAX_VCPUS' undeclared here (not in a function)
> /var/lib/jenkins/jobs/linux-randconfig/workspace/arch/arm/mach-imx/src.c:144: undefined reference to `reset_controller_register'
> /var/lib/jenkins/jobs/linux-randconfig/workspace/arch/arm/mach-omap2/gpio.c:133: undefined reference to `pwrdm_can_ever_lose_context'
> /var/lib/jenkins/jobs/linux-randconfig/workspace/arch/arm/mach-omap2/omap-hotplug.c:33: undefined reference to `omap_get_wakeupgen_base'
> /var/lib/jenkins/jobs/linux-randconfig/workspace/arch/arm/mach-omap2/omap-hotplug.c:38: undefined reference to `omap_secure_apis_support'
> /var/lib/jenkins/jobs/linux-randconfig/workspace/arch/arm/mach-omap2/omap-hotplug.c:50: undefined reference to `omap4_hotplug_cpu'
> /var/lib/jenkins/jobs/linux-randconfig/workspace/arch/arm/mach-omap2/omap-hotplug.c:52: undefined reference to `omap_secure_apis_support'
> /var/lib/jenkins/jobs/linux-randconfig/workspace/arch/arm/mach-omap2/omap_hwmod.c:2145: undefined reference to `clkdm_in_hwsup'
> /var/lib/jenkins/jobs/linux-randconfig/workspace/arch/arm/mach-omap2/omap_hwmod.c:2146: undefined reference to `clkdm_missing_idle_reporting'
> /var/lib/jenkins/jobs/linux-randconfig/workspace/arch/arm/mach-omap2/omap_hwmod.c:2147: undefined reference to `clkdm_hwmod_enable'
> /var/lib/jenkins/jobs/linux-randconfig/workspace/arch/arm/mach-omap2/omap_hwmod.c:2191: undefined reference to `clkdm_hwmod_disable'
> /var/lib/jenkins/jobs/linux-randconfig/workspace/arch/arm/mach-omap2/omap_hwmod.c:2235: undefined reference to `clkdm_hwmod_disable'
> /var/lib/jenkins/jobs/linux-randconfig/workspace/arch/arm/mach-omap2/omap_hwmod.c:2338: undefined reference to `clkdm_hwmod_disable'
> /var/lib/jenkins/jobs/linux-randconfig/workspace/arch/arm/mach-omap2/omap_hwmod.c:4071: undefined reference to `pwrdm_get_context_loss_count'
> /var/lib/jenkins/jobs/linux-randconfig/workspace/arch/arm/mach-omap2/omap_hwmod.c:691: undefined reference to `clkdm_add_sleepdep'
> /var/lib/jenkins/jobs/linux-randconfig/workspace/arch/arm/mach-omap2/omap_hwmod.c:720: undefined reference to `clkdm_del_sleepdep'
> /var/lib/jenkins/jobs/linux-randconfig/workspace/arch/arm/mach-omap2/omap-smp.c:204: undefined reference to `omap_get_wakeupgen_base'
> /var/lib/jenkins/jobs/linux-randconfig/workspace/arch/arm/mach-omap2/omap-smp.c:224: undefined reference to `omap_secure_apis_support'
> /var/lib/jenkins/jobs/linux-randconfig/workspace/arch/arm/mach-omap2/omap-smp.c:80: undefined reference to `omap_get_wakeupgen_base'
> /var/lib/jenkins/jobs/linux-randconfig/workspace/arch/arm/mach-omap2/omap-smp.c:94: undefined reference to `omap_secure_apis_support'
> /var/lib/jenkins/jobs/linux-randconfig/workspace/arch/arm/mach-omap2/pm.c:114: undefined reference to `clkdm_allow_idle'
> /var/lib/jenkins/jobs/linux-randconfig/workspace/arch/arm/mach-omap2/pm.c:117: undefined reference to `clkdm_sleep'
> /var/lib/jenkins/jobs/linux-randconfig/workspace/arch/arm/mach-omap2/pm.c:294: undefined reference to `omap_voltage_late_init'
> /var/lib/jenkins/jobs/linux-randconfig/workspace/arch/arm/mach-omap2/pm-debug.c:102: undefined reference to `pwrdm_read_pwrst'
> /var/lib/jenkins/jobs/linux-randconfig/workspace/arch/arm/mach-omap2/pm-debug.c:103: undefined reference to `pwrdm_read_pwrst'
> /var/lib/jenkins/jobs/linux-randconfig/workspace/arch/arm/mach-omap2/pm-debug.c:132: undefined reference to `pwrdm_state_switch'
> /var/lib/jenkins/jobs/linux-randconfig/workspace/arch/arm/mach-omap2/pm-debug.c:147: undefined reference to `pwrdm_for_each'
> /var/lib/jenkins/jobs/linux-randconfig/workspace/arch/arm/mach-omap2/pm-debug.c:148: undefined reference to `clkdm_for_each'
> /var/lib/jenkins/jobs/linux-randconfig/workspace/arch/arm/mach-omap2/pm-debug.c:155: undefined reference to `pwrdm_for_each'
> /var/lib/jenkins/jobs/linux-randconfig/workspace/arch/arm/mach-omap2/pm-debug.c:272: undefined reference to `pwrdm_for_each'
> /var/lib/jenkins/jobs/linux-randconfig/workspace/arch/arm/mach-spear/platsmp.c:111:58: error: 'SYS_LOCATION' undeclared (first use in this function)
> /var/lib/jenkins/jobs/linux-randconfig/workspace/arch/arm/mach-spear/platsmp.c:25:33: error: 'VA_SCU_BASE' undeclared here (not in a function)
> /var/lib/jenkins/jobs/linux-randconfig/workspace/arch/arm/mach-tegra/sleep-tegra20.S:200: undefined reference to `cpu_do_idle'
> /var/lib/jenkins/jobs/linux-randconfig/workspace/arch/arm/mach-tegra/sleep-tegra30.S:69: Error: shift must be constant -- `orr r12,r12,r4,lsl r3'
> /var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/clk/ux500/clk-prcc.c:145:13: error: conflicting types for 'clk_reg_prcc_pclk'
> /var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/clk/ux500/clk-prcc.c:155:13: error: conflicting types for 'clk_reg_prcc_kclk'
> /var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/cpufreq/arm_big_little.c:101:3: error: too few arguments to function 'cpufreq_notify_transition'
> /var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/cpufreq/arm_big_little.c:234:2: error: unknown field 'have_multiple_policies' specified in initializer
> /var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/cpufreq/arm_big_little.c:90:3: error: too few arguments to function 'cpufreq_notify_transition'
> /var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/cpufreq/spear-cpufreq.c:120: undefined reference to `cpufreq_frequency_table_target'
> /var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/cpufreq/spear-cpufreq.c:181: undefined reference to `cpufreq_frequency_table_cpuinfo'
> /var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/cpufreq/spear-cpufreq.c:187: undefined reference to `cpufreq_frequency_table_get_attr'
> /var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/cpufreq/spear-cpufreq.c:198: undefined reference to `cpufreq_frequency_table_put_attr'
> /var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/cpufreq/spear-cpufreq.c:35: undefined reference to `cpufreq_frequency_table_verify'
> /var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/md/dm-cache-target.c:429: undefined reference to `__udivdi3'
> /var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/md/dm-cache-target.c:429: undefined reference to `__umoddi3'
> /var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/mfd/ab8500-debugfs.c:95:23: fatal error: mach/irqs.h: No such file or directory
> /var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/misc/spear13xx_pcie_gadget.c:23:23: fatal error: mach/pcie.h: No such file or directory
> /var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/pinctrl/pinctrl-abx500.c:125: undefined reference to `abx500_get_register_interruptible'
> /var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/pinctrl/pinctrl-abx500.c:146: undefined reference to `abx500_mask_and_set_register_interruptible'
> /var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/pinctrl/pinctrl-abx500.c:209: undefined reference to `abx500_mask_and_set_register_interruptible'
> /var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/pinctrl/pinctrl-abx500.c:730:24: error: storage size of 'param' isn't known
> /var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/pinctrl/pinctrl-abx500.c:730:7: error: implicit declaration of function 'pinconf_to_config_param' [-Werror=implicit-function-declaration]
> /var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/pinctrl/pinctrl-abx500.c:730:7: error: variable 'param' has initializer but incomplete type
> /var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/pinctrl/pinctrl-abx500.c:731:24: error: storage size of 'argument' isn't known
> /var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/pinctrl/pinctrl-abx500.c:731:7: error: implicit declaration of function 'pinconf_to_config_argument' [-Werror=implicit-function-declaration]
> /var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/pinctrl/pinctrl-abx500.c:731:7: error: variable 'argument' has initializer but incomplete type
> /var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/pinctrl/pinctrl-abx500.c:733:2: error: 'PIN_CONFIG_OUTPUT' undeclared (first use in this function)
> /var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/pinctrl/pinctrl-abx500.c:742:7: error: 'PIN_CONFIG_BIAS_PULL_DOWN' undeclared (first use in this function)
> /var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/staging/android/logger.c:316:4: error: incompatible type for argument 3 of 'get_next_entry_by_uid'
> /var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/staging/android/logger.c:483:14: error: incompatible types when assigning to type 'uid_t' from type 'kuid_t'
> /var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/staging/android/logger.c:631:4: error: incompatible type for argument 3 of 'get_next_entry_by_uid'
> /var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/staging/android/logger.c:686:5: error: incompatible type for argument 3 of 'get_next_entry_by_uid'
> /var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/tty/serial/omap-serial.c:1196:14: error: 'struct uart_port' has no member named 'sysrq'
> /var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/usb/host/uhci-hcd.c:857:2: error: #error "missing bus glue for uhci-hcd"
> /var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/usb/musb/tusb6010.c:1069: undefined reference to `usb_nop_xceiv_register'
> /var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/usb/musb/tusb6010.c:1137: undefined reference to `usb_nop_xceiv_unregister'
> /var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/usb/phy/phy-tegra-usb.c:638:32: error: 'ulpi_viewport_access_ops' undeclared (first use in this function)
> /var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/video/omap2/dss/dpi.c:181:2: error: implicit declaration of function 'dsi_hsdiv_calc' [-Werror=implicit-function-declaration]
> /var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/video/omap2/dss/dpi.c:201:2: error: implicit declaration of function 'dsi_get_pll_clkin' [-Werror=implicit-function-declaration]
> /var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/video/omap2/dss/dpi.c:212:2: error: implicit declaration of function 'dsi_pll_calc' [-Werror=implicit-function-declaration]
> /var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/xen/swiotlb-xen.c:105:2: error: implicit declaration of function 'mfn_to_local_pfn' [-Werror=implicit-function-declaration]
> /var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/xen/swiotlb-xen.c:286:3: error: implicit declaration of function 'dma_alloc_coherent_mask' [-Werror=implicit-function-declaration]
> /var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/xen/swiotlb-xen.c:352:2: error: implicit declaration of function 'dma_capable' [-Werror=implicit-function-declaration]
> /var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/xen/swiotlb-xen.c:406:2: error: implicit declaration of function 'dma_mark_clean' [-Werror=implicit-function-declaration]
> /var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/xen/swiotlb-xen.c:507:11: error: 'struct scatterlist' has no member named 'dma_length'
> /var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/xen/swiotlb-xen.c:513:5: error: 'struct scatterlist' has no member named 'dma_length'
> /var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/xen/swiotlb-xen.c:534:46: error: 'struct scatterlist' has no member named 'dma_length'
> /var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/xen/swiotlb-xen.c:556:8: error: 'struct scatterlist' has no member named 'dma_length'
> /var/lib/jenkins/jobs/linux-randconfig/workspace/include/linux/cpu_cooling.h:58:1: error: parameter name omitted
> /var/lib/jenkins/jobs/linux-randconfig/workspace/include/linux/cpu_cooling.h:59:8: error: parameter name omitted
> WARNING: vmlinux.o(.text+0x12b54): Section mismatch in reference from the function bcm_kona_smc_init() to the (unknown reference) .init.rodata:(unknown)
> 
> driversdrivers/md/dm-cache-target.c:429: more undefined references to `__udivdi3' follow
> dss-common.c:(.cpuinit.text+0x38): undefined reference to `omap_get_wakeupgen_base'
> dss-common.c:(.cpuinit.text+0x48): undefined reference to `omap_secure_apis_support'
> dss-common.c:(.init.text+0x3db0): undefined reference to `omap_get_wakeupgen_base'
> dss-common.c:(.init.text+0x3dcc): undefined reference to `omap_secure_apis_support'
> dss-common.c:(.init.text+0x61b8): undefined reference to `usb_bind_phy'
> dss-common.c:(.init.text+0x6314): undefined reference to `usb_bind_phy'
> dss-common.c:(.init.text+0x6488): undefined reference to `usb_bind_phy'
> dss-common.c:(.init.text+0x65ac): undefined reference to `usb_bind_phy'
> dss-common.c:(.ref.text+0x10): undefined reference to `omap_get_wakeupgen_base'
> dss-common.c:(.ref.text+0x18): undefined reference to `omap_secure_apis_support'
> dss-common.c:(.ref.text+0x54): undefined reference to `omap4_hotplug_cpu'
> dss-common.c:(.ref.text+0x58): undefined reference to `omap_secure_apis_support'
> dss-common.c:(.text+0x11b5c): undefined reference to `usb_bind_phy'
> ERROR: "of_get_next_parent" [drivers/media/v4l2-core/videodev.ko] undefined!
> extcon-class.c:(.text+0x4ac4): undefined reference to `abx500_mask_and_set_register_interruptible'
> extcon-class.c:(.text+0x4b34): undefined reference to `abx500_mask_and_set_register_interruptible'
> extcon-class.c:(.text+0x5164): undefined reference to `abx500_get_register_interruptible'
> extcon-class.c:(.text+0x52b4): undefined reference to `abx500_mask_and_set_register_interruptible'
> extcon-class.c:(.text+0x5304): undefined reference to `abx500_mask_and_set_register_interruptible'
> extcon-class.c:(.text+0x57a4): undefined reference to `abx500_get_register_interruptible'
> platform-spi_imx.c:(.init.text+0x4a20): undefined reference to `reset_controller_register'
> platform-spi_imx.c:(.init.text+0x677c): undefined reference to `reset_controller_register'
> platform-spi_imx.c:(.init.text+0x70c4): undefined reference to `reset_controller_register'
> platform-spi_imx.c:(.init.text+0x825c): undefined reference to `reset_controller_register'
> platform-spi_imx.c:(.text+0x1ff0): undefined reference to `otg_ulpi_create'
> tegra30-mc.c:(.exit.text+0x144): undefined reference to `uart_unregister_driver'
> tegra30-mc.c:(.init.text+0x1e4c): undefined reference to `uart_register_driver'
> tegra30-mc.c:(.init.text+0x1e6c): undefined reference to `uart_unregister_driver'
> tegra30-mc.c:(.init.text+0x1ee0): undefined reference to `uart_parse_options'
> tegra30-mc.c:(.init.text+0x1f04): undefined reference to `uart_set_options'
> tegra30-mc.c:(.text+0x309d8): undefined reference to `uart_resume_port'
> tegra30-mc.c:(.text+0x309fc): undefined reference to `uart_suspend_port'
> tegra30-mc.c:(.text+0x30a94): undefined reference to `uart_handle_dcd_change'
> tegra30-mc.c:(.text+0x30aa8): undefined reference to `uart_handle_cts_change'
> tegra30-mc.c:(.text+0x30e5c): undefined reference to `uart_console_write'
> tegra30-mc.c:(.text+0x31008): undefined reference to `uart_remove_one_port'
> tegra30-mc.c:(.text+0x315b0): undefined reference to `do_SAK'
> tegra30-mc.c:(.text+0x3161c): undefined reference to `uart_insert_char'
> tegra30-mc.c:(.text+0x317d0): undefined reference to `uart_get_baud_rate'
> tegra30-mc.c:(.text+0x318bc): undefined reference to `uart_update_timeout'
> tegra30-mc.c:(.text+0x32c94): undefined reference to `uart_add_one_port'
> tegra30-mc.c:(.text+0x32e94): undefined reference to `uart_write_wakeup'
> tegra30-mc.c:(.text+0x33008): undefined reference to `uart_insert_char'
> tegra30-mc.c:(.text+0x33030): undefined reference to `tty_flip_buffer_push'
> arch/arm/include/asm/kvm_vgic.h:59:11: error: 'CONFIG_KVM_ARM_MAX_VCPUS' undeclared here (not in a function)
> arch/arm/mach-imx/src.c:144: undefined reference to `reset_controller_register'
> arch/arm/mach-omap2/gpio.c:133: undefined reference to `pwrdm_can_ever_lose_context'
> arch/arm/mach-omap2/omap-hotplug.c:33: undefined reference to `omap_get_wakeupgen_base'
> arch/arm/mach-omap2/omap-hotplug.c:38: undefined reference to `omap_secure_apis_support'
> arch/arm/mach-omap2/omap-hotplug.c:50: undefined reference to `omap4_hotplug_cpu'
> arch/arm/mach-omap2/omap-hotplug.c:52: undefined reference to `omap_secure_apis_support'
> arch/arm/mach-omap2/omap_hwmod.c:2145: undefined reference to `clkdm_in_hwsup'
> arch/arm/mach-omap2/omap_hwmod.c:2146: undefined reference to `clkdm_missing_idle_reporting'
> arch/arm/mach-omap2/omap_hwmod.c:2147: undefined reference to `clkdm_hwmod_enable'
> arch/arm/mach-omap2/omap_hwmod.c:2191: undefined reference to `clkdm_hwmod_disable'
> arch/arm/mach-omap2/omap_hwmod.c:2235: undefined reference to `clkdm_hwmod_disable'
> arch/arm/mach-omap2/omap_hwmod.c:2338: undefined reference to `clkdm_hwmod_disable'
> arch/arm/mach-omap2/omap_hwmod.c:4071: undefined reference to `pwrdm_get_context_loss_count'
> arch/arm/mach-omap2/omap_hwmod.c:691: undefined reference to `clkdm_add_sleepdep'
> arch/arm/mach-omap2/omap_hwmod.c:720: undefined reference to `clkdm_del_sleepdep'
> arch/arm/mach-omap2/omap-smp.c:204: undefined reference to `omap_get_wakeupgen_base'
> arch/arm/mach-omap2/omap-smp.c:224: undefined reference to `omap_secure_apis_support'
> arch/arm/mach-omap2/omap-smp.c:80: undefined reference to `omap_get_wakeupgen_base'
> arch/arm/mach-omap2/omap-smp.c:94: undefined reference to `omap_secure_apis_support'
> arch/arm/mach-omap2/pm.c:114: undefined reference to `clkdm_allow_idle'
> arch/arm/mach-omap2/pm.c:117: undefined reference to `clkdm_sleep'
> arch/arm/mach-omap2/pm.c:294: undefined reference to `omap_voltage_late_init'
> arch/arm/mach-omap2/pm-debug.c:102: undefined reference to `pwrdm_read_pwrst'
> arch/arm/mach-omap2/pm-debug.c:103: undefined reference to `pwrdm_read_pwrst'
> arch/arm/mach-omap2/pm-debug.c:132: undefined reference to `pwrdm_state_switch'
> arch/arm/mach-omap2/pm-debug.c:147: undefined reference to `pwrdm_for_each'
> arch/arm/mach-omap2/pm-debug.c:148: undefined reference to `clkdm_for_each'
> arch/arm/mach-omap2/pm-debug.c:155: undefined reference to `pwrdm_for_each'
> arch/arm/mach-omap2/pm-debug.c:272: undefined reference to `pwrdm_for_each'
> arch/arm/mach-spear/platsmp.c:111:58: error: 'SYS_LOCATION' undeclared (first use in this function)
> arch/arm/mach-spear/platsmp.c:25:33: error: 'VA_SCU_BASE' undeclared here (not in a function)
> arch/arm/mach-tegra/sleep-tegra20.S:200: undefined reference to `cpu_do_idle'
> arch/arm/mach-tegra/sleep-tegra30.S:69: Error: shift must be constant -- `orr r12,r12,r4,lsl r3'
> drivers/clk/ux500/clk-prcc.c:145:13: error: conflicting types for 'clk_reg_prcc_pclk'
> drivers/clk/ux500/clk-prcc.c:155:13: error: conflicting types for 'clk_reg_prcc_kclk'
> drivers/cpufreq/arm_big_little.c:101:3: error: too few arguments to function 'cpufreq_notify_transition'
> drivers/cpufreq/arm_big_little.c:234:2: error: unknown field 'have_multiple_policies' specified in initializer
> drivers/cpufreq/arm_big_little.c:90:3: error: too few arguments to function 'cpufreq_notify_transition'
> drivers/cpufreq/spear-cpufreq.c:120: undefined reference to `cpufreq_frequency_table_target'
> drivers/cpufreq/spear-cpufreq.c:181: undefined reference to `cpufreq_frequency_table_cpuinfo'
> drivers/cpufreq/spear-cpufreq.c:187: undefined reference to `cpufreq_frequency_table_get_attr'
> drivers/cpufreq/spear-cpufreq.c:198: undefined reference to `cpufreq_frequency_table_put_attr'
> drivers/cpufreq/spear-cpufreq.c:35: undefined reference to `cpufreq_frequency_table_verify'
> drivers/md/dm-cache-target.c:429: undefined reference to `__udivdi3'
> drivers/md/dm-cache-target.c:429: undefined reference to `__umoddi3'
> drivers/mfd/ab8500-debugfs.c:95:23: fatal error: mach/irqs.h: No such file or directory
> drivers/misc/spear13xx_pcie_gadget.c:23:23: fatal error: mach/pcie.h: No such file or directory
> drivers/pinctrl/pinctrl-abx500.c:125: undefined reference to `abx500_get_register_interruptible'
> drivers/pinctrl/pinctrl-abx500.c:146: undefined reference to `abx500_mask_and_set_register_interruptible'
> drivers/pinctrl/pinctrl-abx500.c:209: undefined reference to `abx500_mask_and_set_register_interruptible'
> drivers/pinctrl/pinctrl-abx500.c:730:24: error: storage size of 'param' isn't known
> drivers/pinctrl/pinctrl-abx500.c:730:7: error: implicit declaration of function 'pinconf_to_config_param' [-Werror=implicit-function-declaration]
> drivers/pinctrl/pinctrl-abx500.c:730:7: error: variable 'param' has initializer but incomplete type
> drivers/pinctrl/pinctrl-abx500.c:731:24: error: storage size of 'argument' isn't known
> drivers/pinctrl/pinctrl-abx500.c:731:7: error: implicit declaration of function 'pinconf_to_config_argument' [-Werror=implicit-function-declaration]
> drivers/pinctrl/pinctrl-abx500.c:731:7: error: variable 'argument' has initializer but incomplete type
> drivers/pinctrl/pinctrl-abx500.c:733:2: error: 'PIN_CONFIG_OUTPUT' undeclared (first use in this function)
> drivers/pinctrl/pinctrl-abx500.c:742:7: error: 'PIN_CONFIG_BIAS_PULL_DOWN' undeclared (first use in this function)
> drivers/staging/android/logger.c:316:4: error: incompatible type for argument 3 of 'get_next_entry_by_uid'
> drivers/staging/android/logger.c:483:14: error: incompatible types when assigning to type 'uid_t' from type 'kuid_t'
> drivers/staging/android/logger.c:631:4: error: incompatible type for argument 3 of 'get_next_entry_by_uid'
> drivers/staging/android/logger.c:686:5: error: incompatible type for argument 3 of 'get_next_entry_by_uid'
> drivers/tty/serial/omap-serial.c:1196:14: error: 'struct uart_port' has no member named 'sysrq'
> drivers/usb/host/uhci-hcd.c:857:2: error: #error "missing bus glue for uhci-hcd"
> drivers/usb/musb/tusb6010.c:1069: undefined reference to `usb_nop_xceiv_register'
> drivers/usb/musb/tusb6010.c:1137: undefined reference to `usb_nop_xceiv_unregister'
> drivers/usb/phy/phy-tegra-usb.c:638:32: error: 'ulpi_viewport_access_ops' undeclared (first use in this function)
> drivers/video/omap2/dss/dpi.c:181:2: error: implicit declaration of function 'dsi_hsdiv_calc' [-Werror=implicit-function-declaration]
> drivers/video/omap2/dss/dpi.c:201:2: error: implicit declaration of function 'dsi_get_pll_clkin' [-Werror=implicit-function-declaration]
> drivers/video/omap2/dss/dpi.c:212:2: error: implicit declaration of function 'dsi_pll_calc' [-Werror=implicit-function-declaration]
> drivers/xen/swiotlb-xen.c:105:2: error: implicit declaration of function 'mfn_to_local_pfn' [-Werror=implicit-function-declaration]
> drivers/xen/swiotlb-xen.c:286:3: error: implicit declaration of function 'dma_alloc_coherent_mask' [-Werror=implicit-function-declaration]
> drivers/xen/swiotlb-xen.c:352:2: error: implicit declaration of function 'dma_capable' [-Werror=implicit-function-declaration]
> drivers/xen/swiotlb-xen.c:406:2: error: implicit declaration of function 'dma_mark_clean' [-Werror=implicit-function-declaration]
> drivers/xen/swiotlb-xen.c:507:11: error: 'struct scatterlist' has no member named 'dma_length'
> drivers/xen/swiotlb-xen.c:513:5: error: 'struct scatterlist' has no member named 'dma_length'
> drivers/xen/swiotlb-xen.c:534:46: error: 'struct scatterlist' has no member named 'dma_length'
> drivers/xen/swiotlb-xen.c:556:8: error: 'struct scatterlist' has no member named 'dma_length'
> include/linux/cpu_cooling.h:58:1: error: parameter name omitted
> include/linux/cpu_cooling.h:59:8: error: parameter name omitted
> WARNING: arch/arm/mach-bcm/built-in.o(.text+0x104): Section mismatch in reference from the function bcm_kona_smc_init() to the (unknown reference) .init.rodata:(unknown)
> 


From cdall at cs.columbia.edu  Fri Apr 19 12:13:40 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Fri, 19 Apr 2013 09:13:40 -0700
Subject: [PATCH] ARM: KVM: iterate over all CPUs for CPU compatibility
 check
In-Reply-To: <51713F91.5080102@linaro.org>
References: <51680AF9.7040109@arm.com>
 <CAEDV+g+E8PLc60vMRhq4O_AL2WjmYDLb6=Wh34ynhevh7uAGJA@mail.gmail.com>
 <d455f2823b9639af8d38d30f2c3234bd@localhost>
 <CAEDV+gJuFG49oQ=BEaCHcTP=nHVyX8ALw6076dR_C1s7TuyqXQ@mail.gmail.com>
 <d47697abd39a0d5d41f5ac110a40e261@localhost>
 <CAEDV+gK9==sXYxRVZ8JVFYPiw3_xgzZBbydEwPunmnocNLKXrQ@mail.gmail.com>
 <CAFEAcA-bPoa8YoPuHPmupzfUW+yR233XquK79eNorzcRpFiK=g@mail.gmail.com>
 <516BCAD0.9000708@linaro.org>
 <CAJRNFKJoBzgt4UhxsH65_LyhcGXPnzB_pg3q-zeYT2OVv59q4A@mail.gmail.com>
 <516BFD13.1000400@linaro.org>
 <20130415134837.GI9827@mudshark.cambridge.arm.com>
 <CAEDV+gJB7Bj9O7pftFqoYQ=goORjdurBnEfQVmC5arDuNJfpBg@mail.gmail.com>
 <32d532438f5b621e40679aea9f5888c7@localhost>
 <516E586C.5030407@linaro.org>
 <8e0bda3fd84d1b0c5aa55161ca178a8e@localhost>
 <CAEDV+g+3nkdvbLdj0m-ZdDKt0JY2vgzhP2AQA2nf=R3h4yTQmQ@mail.gmail.com>
 <51713F91.5080102@linaro.org>
Message-ID: <CAEDV+gL=rbxxBRgYdHxBj_C9ZBFbuORaG0jcSzEUJ7pO9-Fqkg@mail.gmail.com>

On Fri, Apr 19, 2013 at 5:58 AM, Andre Przywara
<andre.przywara at linaro.org> wrote:
> On 04/17/2013 11:12 AM, Christoffer Dall wrote:
>>
>>
>>
>>
>> On Wed, Apr 17, 2013 at 1:16 AM, Marc Zyngier <marc.zyngier at arm.com
>> <mailto:marc.zyngier at arm.com>> wrote:
>>
>>     On Wed, 17 Apr 2013 10:08:12 +0200, Andre Przywara
>>     <andre.przywara at linaro.org <mailto:andre.przywara at linaro.org>> wrote:
>>      > On 04/16/2013 06:33 PM, Marc Zyngier wrote:
>>      >> On Tue, 16 Apr 2013 09:26:26 -0700, Christoffer Dall
>>      >> <cdall at cs.columbia.edu <mailto:cdall at cs.columbia.edu>> wrote:
>>      >>> On Mon, Apr 15, 2013 at 6:48 AM, Will Deacon
>>     <will.deacon at arm.com <mailto:will.deacon at arm.com>>
>>
>>      >> wrote:
>>      >>>> On Mon, Apr 15, 2013 at 02:13:55PM +0100, Andre Przywara wrote:
>>      >>>>> On 04/15/2013 11:52 AM, Alexander Spyridakis wrote:
>>      >>>>>> I've run on this problem before, while trying to run KVM
>>     guests on
>>      >> A7
>>      >>>>>> cores.
>>      >>>>>>
>>      >>>>>> For some reason the 3rd A7 hangs in arch/arm/kvm/init.S, on
>> the
>>      >>>>>> instruction that updates HSCTLR between the two isbs on
>>      >> __do_hyp_init
>>      >>>>>> (mcr p15, 4, r0, c1, c0, 0). If you boot the system with
>>     maxcpus=4
>>      >>>>>> then
>>      >>>>>> init_hyp_mode() will not hang on the A7 cluster. Other than
>> that
>>      >> from
>>      >>>>>> my
>>      >>>>>> limited testing KVM on A7 works on a usual linux guest. I also
>>     tried
>>      >>>>>> to
>>      >>>>>> only boot the 3rd A7 core to rule out any racing issues, but
>>     still
>>      >> the
>>      >>>>>> same behaviour applies.
>>      >>>>>
>>      >>>>> Could well be the same issue here. I chased it down till CPU
>>     2 goes
>>      >> into
>>      >>>>> HYP mode to do the initialization.
>>      >>>>> I am running with maxcpus=3 (this increases the likelyhood that
>>      >>>>> kvm_target_cpu() runs on an A15), so CPU #2 is the only one A7.
>>      >>>>> As the HYP mode exception table is empty except for the HVC
>>     trap, it
>>      >> may
>>      >>>>> be looping here. I am trying now to get the PC of the faulty
>>      >>>>> instruction.
>>      >>>>
>>      >>>> Yes, it sounds like you're taking a recursive fault because the
>>     vectors
>>      >>>> aren't installed yet. Is there any chance you can find out
>>     what value
>>      >>>> you end
>>      >>>> up writing (or trying to write) to the HSCTLR please?
>>      >>>>
>>      >>> Actually I'm a little confused, wasn't Andre seeing a halt on
>>     an A15
>>      >>> cpu, not an A7? Or is the theory that an A7 locks up and the
>>     calling
>>      >>> A15 hangs on the SMP call to cpu_init_hyp_mode, waiting for the
>>     A7 to
>>      >>> complete?
>>      >>
>>      >> Yes, A15 hanging, not A7. That's why I'm strongly opposed to this
>>     patch.
>>      >> I'm pretty sure the A7s only have a side effect that triggers a
>>     kernel
>>      >> bug
>>      >> on the A15 side. Before taking *any* patch around this, we should
>>      >> understand the issue fully, and not start patching random stuff
>> just
>>      >> because Linus is going to tag 3.9.
>>      >
>>      > I think there is a misunderstanding. The RCU watchdog was
>> complaining
>>      > because the A15 wasn't making any progress. As Christoffer said,
>>     this is
>>
>>      > because it was waiting for CPU 2 to return from the SMP call. It is
>>      > actually the A7 hanging inside HYP mode.
>>      > I tried some ways to get information out of there, but had no luck
>> so
>>      > far. The different mapping between HYP and SVC doesn't make it
>>     easy to
>>      > dump some variables, but I am still working on it (but only half
>>     steam
>>
>>     You could force a full mapping of the kernel text in HYP. Ugly, but
>>     should
>>     work.
>>
>>      > because I am home looking after my sick daughter). So for now I
>>     assume
>>      > that it is the HSCTLR setting Alexander observed already.
>>
>>     I'll give it a go today or tomorrow, depending how quickly I can get
>> rid
>>     of my backlog after a couple of days off work.
>>
>>     Assuming this is an A7 handing on HSCTLR access, it should be pretty
>>     easy
>>     to narrow down by booting only on the A7s, leaving the A15s held in
>>     reset.
>>
>>
>> You could also try installing a vector handler early and detect faults,
>> and add an alternative return path from the init function with some
>> error reporting value in r0 or something like that, just for debugging,
>> naturally, but that could be a way to detect if we really are taking
>> recursive faults here.
>
>
> OK, I added code to return earlier on CPUs not from cluster 0.
> Indeed it hangs in the HSCR write. The two A15s pass this instruction,
> writing 0x30c5187F into the register.
> This means all the fixed bits for A15 correctly, C,A,M and I set and WXN,
> EE, TE cleared. FI was also cleared
> The A7 wanted to write the very same value. I tried to set bit 21, which
> kind of the A7 TRM hints to do: but no change.
> Before the HSCLTR write, the register reads 0x30c50878, with SCTLR being
> 0x30c5387d.
> So the code wants to set M, A, C and I in HSCLTR. Interestingly SCTLR has
> the V bits set, could that be an issue?
>
Can you try writing 0x30c50879 into the register instead? Basically
check to see if enabling caches or alignment checks causes the issue,
or if it is indeed enabling the MMU that's the issue... If that works,
start a bisect on the remaining bits. Also, just for fun, could you
try flushing the entire I-cache before writing into the HSCLTR?

Why wouldn't the V bit be set in the SCTLR, Linus uses high vectors
(at 0xffff0000) for exception handling on ARM.

-Christoffer


From cdall at cs.columbia.edu  Fri Apr 19 12:14:48 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Fri, 19 Apr 2013 09:14:48 -0700
Subject: [PATCH v3 6/7] ARM: KVM: switch to a dual-step HYP init code
In-Reply-To: <51714F90.6060705@arm.com>
References: <1365779932-20322-1-git-send-email-marc.zyngier@arm.com>
 <1365779932-20322-7-git-send-email-marc.zyngier@arm.com>
 <20130419133658.GQ14496@n2100.arm.linux.org.uk>
 <51714F90.6060705@arm.com>
Message-ID: <CAEDV+gJZsRqjnH60Ed4ju1GxhSLoXd5r9S-fcv2D6na_JNQeYg@mail.gmail.com>

On Fri, Apr 19, 2013 at 7:07 AM, Marc Zyngier <marc.zyngier at arm.com> wrote:
> On 19/04/13 14:36, Russell King - ARM Linux wrote:
>> On Fri, Apr 12, 2013 at 04:18:51PM +0100, Marc Zyngier wrote:
>>> @@ -247,7 +265,11 @@ static int __create_hyp_mappings(pgd_t *pgdp,
>>>                              goto out;
>>>                      }
>>>                      pud_populate(NULL, pud, pmd);
>>> +<<<<<<< HEAD
>>>                      get_page(virt_to_page(pud));
>>> +=======
>>> +                    kvm_flush_dcache_to_poc(pud, sizeof(*pud));
>>> +>>>>>>> 180de35... ARM: KVM: switch to a dual-step HYP init code
>>
>> I don't think you want this in your patch... and as no one else spotted
>> this, has anyone looked at this patch set yet?
>
> I posted a revised version within minutes of posting this crap.
>
> As far as I know, Christoffer has reviewed it.
>
yes I did, but v4.

-Christoffer


From peter.maydell at linaro.org  Fri Apr 19 12:14:36 2013
From: peter.maydell at linaro.org (Peter Maydell)
Date: Fri, 19 Apr 2013 17:14:36 +0100
Subject: [RFC] arm64: Early printk support for virtio-mmio console devices.
In-Reply-To: <20130419161201.GA5383@localhost.cambridge.arm.com>
References: <CAAHg+HhajHFC=1nh6YQNgpf=Na2FqcsYJ=t+ag9QiTg6TxUz9w@mail.gmail.com>
 <bb1193983de3ea9f4df1a570441df34c@localhost>
 <CAAHg+HhtCorArCmx=ha0=64+SJZiizzrDUKSPLV=N+OzO8zAxQ@mail.gmail.com>
 <20130419090558.GA13283@mudshark.cambridge.arm.com>
 <CAAHg+HipCX2ma6brxj9Kgc3ew39b5e30grLwyun9CViif-5wZQ@mail.gmail.com>
 <20130419092752.GB13283@mudshark.cambridge.arm.com>
 <CAFEAcA8j124G=vaHObJ_w5wOhUiS3KYKbjMnigbnr6mgwFxZUg@mail.gmail.com>
 <CAAHg+Hg=t97SJ0JPZYgrZaL+zimo-wbezwaj1BQvHqE-vf4VDA@mail.gmail.com>
 <20130419093953.GD13283@mudshark.cambridge.arm.com>
 <CAFEAcA_WfYpyvq54rZqS8JZkmDF5JXB+CNHFH5CnrhKun52uzA@mail.gmail.com>
 <20130419161201.GA5383@localhost.cambridge.arm.com>
Message-ID: <CAFEAcA-F18kR4JihdxaLTm3qb4n51tsygG1RW4djwJ0u9+FQqw@mail.gmail.com>

On 19 April 2013 17:12, Catalin Marinas <catalin.marinas at arm.com> wrote:
> On Fri, Apr 19, 2013 at 11:05:47AM +0100, Peter Maydell wrote:
>> Please make the kernel pick the device out of the device tree
>> blob. The whole point of device tree is that it's how to tell
>> the kernel where things live -- making kvmtool/QEMU and/or the
>> user also have to mess with the kernel command line is awkward
>> and annoying.
>
> For a normal console device, it indeed needs to get it from the DT. For
> early console, you want it earlier than DT parsing so we pass it on the
> kernel command line via the earlyprintk= parameter.

You should fix your DT handling code so you can get at the info
when you need it rather than pushing the problem into bootloaders
and QEMU, please. DT is your data structure so feel free to
(re)design it so relevant information can be accessed early
if that's useful.

thanks
-- PMM


From Ian.Campbell at citrix.com  Fri Apr 19 12:16:06 2013
From: Ian.Campbell at citrix.com (Ian Campbell)
Date: Fri, 19 Apr 2013 17:16:06 +0100
Subject: [Xen-devel] [PATCH v6 1/4] arm: introduce psci_smp_ops
In-Reply-To: <alpine.LFD.2.03.1304191146230.17375@syhkavp.arg>
References: <alpine.DEB.2.02.1304031239550.5078@kaball.uk.xensource.com>
 <1365167495-18508-1-git-send-email-stefano.stabellini@eu.citrix.com>
 <20130418161341.GB14496@n2100.arm.linux.org.uk>
 <alpine.DEB.2.02.1304181714560.7254@kaball.uk.xensource.com>
 <alpine.LFD.2.03.1304181237480.17375@syhkavp.arg>
 <alpine.DEB.2.02.1304181749260.7254@kaball.uk.xensource.com>
 <alpine.LFD.2.03.1304181336280.17375@syhkavp.arg>
 <alpine.DEB.2.02.1304191035360.7254@kaball.uk.xensource.com>
 <alpine.LFD.2.03.1304191146230.17375@syhkavp.arg>
Message-ID: <1366388166.29403.2.camel@dagon.hellion.org.uk>

On Fri, 2013-04-19 at 16:47 +0100, Nicolas Pitre wrote:
> No one should be probing registers without making sure it is safe to do 
> so.  Even on non virtualized hardware this can be a dangerous thing to 
> do.

Won't people writing per machine code consider, not unreasonably, that
having been called through a mdesc machine specific hook constitutes
enough "making sure" that they think it is safe to touch registers which
are specific to that machine?

Ian.



From sboyd at codeaurora.org  Fri Apr 19 12:19:36 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Fri, 19 Apr 2013 09:19:36 -0700
Subject: [PATCHv5 02/11] clocksource: add generic dummy timer driver
In-Reply-To: <1366388385-30722-1-git-send-email-sboyd@codeaurora.org>
References: <1366388385-30722-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1366388385-30722-3-git-send-email-sboyd@codeaurora.org>

From: Mark Rutland <mark.rutland at arm.com>

Several architectures have a dummy timer driver tightly coupled with
their broadcast code to support machines without cpu-local timers (or
where there is a lack of driver support).

Since 12ad100046: "clockevents: Add generic timer broadcast function"
it's been possible to write broadcast-capable timer drivers decoupled
from the broadcast mechanism. We can use this functionality to implement
a generic dummy timer driver that can be shared by all architectures
with generic tick broadcast (ARCH_HAS_TICK_BROADCAST).

This patch implements a generic dummy timer using this facility.

Signed-off-by: Mark Rutland <mark.rutland at arm.com>
Cc: John Stultz <john.stultz at linaro.org>
[sboyd: Make percpu data static, use __this_cpu_ptr(), move to
        early_initcall to properly register on each CPU, only
	register if more than one CPU possible]
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 drivers/clocksource/Makefile      |  1 +
 drivers/clocksource/dummy_timer.c | 69 +++++++++++++++++++++++++++++++++++++++
 2 files changed, 70 insertions(+)
 create mode 100644 drivers/clocksource/dummy_timer.c

diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index b0400ff..2437363 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -28,3 +28,4 @@ obj-$(CONFIG_CLKSRC_EXYNOS_MCT)	+= exynos_mct.o
 
 obj-$(CONFIG_ARM_ARCH_TIMER)		+= arm_arch_timer.o
 obj-$(CONFIG_CLKSRC_METAG_GENERIC)	+= metag_generic.o
+obj-$(CONFIG_ARCH_HAS_TICK_BROADCAST)	+= dummy_timer.o
diff --git a/drivers/clocksource/dummy_timer.c b/drivers/clocksource/dummy_timer.c
new file mode 100644
index 0000000..1f55f96
--- /dev/null
+++ b/drivers/clocksource/dummy_timer.c
@@ -0,0 +1,69 @@
+/*
+ *  linux/drivers/clocksource/dummy_timer.c
+ *
+ *  Copyright (C) 2013 ARM Ltd.
+ *  All Rights Reserved
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include <linux/clockchips.h>
+#include <linux/cpu.h>
+#include <linux/init.h>
+#include <linux/percpu.h>
+#include <linux/cpumask.h>
+
+static DEFINE_PER_CPU(struct clock_event_device, dummy_timer_evt);
+
+static void dummy_timer_set_mode(enum clock_event_mode mode,
+			   struct clock_event_device *evt)
+{
+	/*
+	 * Core clockevents code will call this when exchanging timer devices.
+	 * We don't need to do anything here.
+	 */
+}
+
+static void __cpuinit dummy_timer_setup(void)
+{
+	int cpu = smp_processor_id();
+	struct clock_event_device *evt = __this_cpu_ptr(&dummy_timer_evt);
+
+	evt->name	= "dummy_timer";
+	evt->features	= CLOCK_EVT_FEAT_PERIODIC |
+			  CLOCK_EVT_FEAT_ONESHOT |
+			  CLOCK_EVT_FEAT_DUMMY;
+	evt->rating	= 100;
+	evt->set_mode	= dummy_timer_set_mode;
+	evt->cpumask	= cpumask_of(cpu);
+
+	clockevents_register_device(evt);
+}
+
+static int __cpuinit dummy_timer_cpu_notify(struct notifier_block *self,
+				      unsigned long action, void *hcpu)
+{
+	if ((action & ~CPU_TASKS_FROZEN) == CPU_STARTING)
+		dummy_timer_setup();
+
+	return NOTIFY_OK;
+}
+
+static struct notifier_block dummy_timer_cpu_nb __cpuinitdata = {
+	.notifier_call = dummy_timer_cpu_notify,
+};
+
+static int __init dummy_timer_register(void)
+{
+	int err = register_cpu_notifier(&dummy_timer_cpu_nb);
+	if (err)
+		return err;
+
+	/* We won't get a call on the boot CPU, so register immediately */
+	if (num_possible_cpus() > 1)
+		dummy_timer_setup();
+
+	return 0;
+}
+early_initcall(dummy_timer_register);
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Fri Apr 19 12:19:34 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Fri, 19 Apr 2013 09:19:34 -0700
Subject: [PATCHv5 00/11] Remove ARM local timer API
Message-ID: <1366388385-30722-1-git-send-email-sboyd@codeaurora.org>

In light of Mark Rutland's recent work on divorcing the ARM architected
timers from the ARM local timer API and introducing a generic arch hook for
broadcast it seems that we should remove the local timer API entirely.
Doing so will reduce the architecture dependencies of our timer drivers,
reduce code in ARM core, and simplify timer drivers because they no longer
go through an architecture layer that is essentially a hotplug notifier.

Previous attempts have been made[1] unsuccessfully. I'm hoping this can
be accepted now so that we can clean up the timer drivers that are
used in both UP and SMP situations. Right now these drivers have to ignore
the timer setup callback on the boot CPU to avoid registering clockevents
twice. This is not very symmetric and causes convuluted code that does
the same thing in two places.

Patches based on next-20130418

I'm still looking for Acks/Tested-by on EXYNOS and PRIMA2.

[1] http://article.gmane.org/gmane.linux.ports.arm.kernel/145705

Note: A hotplug notifier is used by both x86 for the apb_timer (see 
apbt_cpuhp_notify) and by metag (see arch_timer_cpu_notify in
metag_generic.c) so this is not new.

Changes since v4:
 * Rebased onto next-20130418
 * Rebase caused minor updates to mct patch and twd Kconfig

Changes since v3:
 * New patch to fix SMP with dummy timers registered after a global timer
 * Push this_cpu_ptr lower to avoid preemptible false positive warnings
 * Collected acks/tested-bys

Changes since v2:
 * Bug fixes in smp_twd from Tony Lindgren's testing
 * Move smp_twd to use late_time_init hook
 * Collected Acks

Changes since v1:
 * Picked up Mark's generic dummy timer driver
 * Split out omap changes into new patch


Mark Rutland (1):
  clocksource: add generic dummy timer driver

Stephen Boyd (10):
  clockevents: Prefer CPU local devices over global devices
  ARM: smp: Remove duplicate dummy timer implementation
  ARM: smp_twd: Divorce smp_twd from local timer API
  ARM: OMAP2+: Divorce from local timer API
  ARM: EXYNOS4: Divorce mct from local timer API
  ARM: PRIMA2: Divorce timer-marco from local timer API
  ARM: msm: Divorce msm_timer from local timer API
  clocksource: time-armada-370-xp: Fix sparse warning
  clocksource: time-armada-370-xp: Divorce from local timer API
  ARM: smp: Remove local timer API

 arch/arm/Kconfig                         |  12 +--
 arch/arm/include/asm/localtimer.h        |  34 ---------
 arch/arm/kernel/smp.c                    |  87 ----------------------
 arch/arm/kernel/smp_twd.c                |  64 ++++++++++------
 arch/arm/mach-highbank/Kconfig           |   2 +-
 arch/arm/mach-imx/Kconfig                |   2 +-
 arch/arm/mach-msm/timer.c                | 122 +++++++++++++++++--------------
 arch/arm/mach-omap2/Kconfig              |   3 +-
 arch/arm/mach-omap2/timer.c              |   7 --
 arch/arm/mach-realview/Kconfig           |   8 +-
 arch/arm/mach-spear/Kconfig              |   2 +-
 arch/arm/mach-tegra/Kconfig              |   2 +-
 arch/arm/mach-ux500/Kconfig              |   2 +-
 arch/arm/mach-vexpress/Kconfig           |   2 +-
 arch/arm/mach-zynq/Kconfig               |   2 +-
 drivers/clocksource/Makefile             |   1 +
 drivers/clocksource/dummy_timer.c        |  69 +++++++++++++++++
 drivers/clocksource/exynos_mct.c         |  61 +++++++++++-----
 drivers/clocksource/time-armada-370-xp.c |  92 +++++++++++------------
 drivers/clocksource/timer-marco.c        | 100 +++++++++++++------------
 include/linux/time-armada-370-xp.h       |   4 +-
 kernel/time/tick-common.c                |   5 +-
 22 files changed, 338 insertions(+), 345 deletions(-)
 delete mode 100644 arch/arm/include/asm/localtimer.h
 create mode 100644 drivers/clocksource/dummy_timer.c

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Fri Apr 19 12:19:35 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Fri, 19 Apr 2013 09:19:35 -0700
Subject: [PATCHv5 01/11] clockevents: Prefer CPU local devices over global
 devices
In-Reply-To: <1366388385-30722-1-git-send-email-sboyd@codeaurora.org>
References: <1366388385-30722-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1366388385-30722-2-git-send-email-sboyd@codeaurora.org>

On an SMP system with only one global clockevent and a dummy
clockevent per CPU we run into problems. We want the dummy
clockevents to be registered as the per CPU tick devices, but
we can only achieve that if we register the dummy clockevents
before the global clockevent or if we artificially inflate the
rating of the dummy clockevents to be higher than the rating
of the global clockevent. Failure to do so leads to boot
hangs when the dummy timers are registered on all other CPUs
besides the CPU that accepted the global clockevent as its tick
device and there is no broadcast timer to poke the dummy
devices.

If we're registering multiple clockevents and one clockevent is
global and the other is local to a particular CPU we should
choose to use the local clockevent regardless of the rating of
the device. This way, if the clockevent is a dummy it will take
the tick device duty as long as there isn't a higher rated tick
device and any global clockevent will be bumped out into
broadcast mode, fixing the problem described above.

Reported-by: Mark Rutland <mark.rutland at arm.com>
Tested-by: Mark Rutland <mark.rutland at arm.com>
Cc: John Stultz <john.stultz at linaro.org>
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 kernel/time/tick-common.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/kernel/time/tick-common.c b/kernel/time/tick-common.c
index 412bcef..d616eca 100644
--- a/kernel/time/tick-common.c
+++ b/kernel/time/tick-common.c
@@ -254,9 +254,10 @@ static int tick_check_new_device(struct clock_event_device *newdev)
 		    !(newdev->features & CLOCK_EVT_FEAT_ONESHOT))
 			goto out_bc;
 		/*
-		 * Check the rating
+		 * Check the rating, but prefer CPU local devices
 		 */
-		if (curdev->rating >= newdev->rating)
+		if (curdev->rating >= newdev->rating &&
+		    cpumask_equal(curdev->cpumask, newdev->cpumask))
 			goto out_bc;
 	}
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Fri Apr 19 12:19:39 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Fri, 19 Apr 2013 09:19:39 -0700
Subject: [PATCHv5 05/11] ARM: OMAP2+: Divorce from local timer API
In-Reply-To: <1366388385-30722-1-git-send-email-sboyd@codeaurora.org>
References: <1366388385-30722-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1366388385-30722-6-git-send-email-sboyd@codeaurora.org>

Now that the TWD doesn't rely on the local timer API, OMAP can
stop selecting it in Kconfig and relying on the config option to
decide if it should call smp_twd functions.

Acked-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
Acked-by: Tony Lindgren <tony at atomide.com>
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 arch/arm/mach-omap2/Kconfig | 1 -
 arch/arm/mach-omap2/timer.c | 7 -------
 2 files changed, 8 deletions(-)

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 568bb74..ff185ef 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -91,7 +91,6 @@ config ARCH_OMAP4
 	select HAVE_ARM_SCU if SMP
 	select HAVE_ARM_TWD if SMP
 	select HAVE_SMP
-	select LOCAL_TIMERS if SMP
 	select OMAP_INTERCONNECT
 	select PL310_ERRATA_588369
 	select PL310_ERRATA_727915
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index ce57228..7f2ef6c 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -600,7 +600,6 @@ static OMAP_SYS_32K_TIMER_INIT(4, 1, "timer_32k_ck", "ti,timer-alwon",
 #endif
 
 #ifdef CONFIG_ARCH_OMAP4
-#ifdef CONFIG_LOCAL_TIMERS
 static DEFINE_TWD_LOCAL_TIMER(twd_local_timer, OMAP44XX_LOCAL_TWD_BASE, 29);
 void __init omap4_local_timer_init(void)
 {
@@ -619,12 +618,6 @@ void __init omap4_local_timer_init(void)
 			pr_err("twd_local_timer_register failed %d\n", err);
 	}
 }
-#else /* CONFIG_LOCAL_TIMERS */
-void __init omap4_local_timer_init(void)
-{
-	omap4_sync32k_timer_init();
-}
-#endif /* CONFIG_LOCAL_TIMERS */
 #endif /* CONFIG_ARCH_OMAP4 */
 
 #ifdef CONFIG_SOC_OMAP5
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Fri Apr 19 12:19:37 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Fri, 19 Apr 2013 09:19:37 -0700
Subject: [PATCHv5 03/11] ARM: smp: Remove duplicate dummy timer implementation
In-Reply-To: <1366388385-30722-1-git-send-email-sboyd@codeaurora.org>
References: <1366388385-30722-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1366388385-30722-4-git-send-email-sboyd@codeaurora.org>

Drop ARM's version of the dummy timer now that we have a generic
implementation in drivers/clocksource.

Cc: Russell King <linux at arm.linux.org.uk>
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 arch/arm/kernel/smp.c | 22 ++--------------------
 1 file changed, 2 insertions(+), 20 deletions(-)

diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
index 4619177..806b84d 100644
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -469,24 +469,6 @@ void tick_broadcast(const struct cpumask *mask)
 }
 #endif
 
-static void broadcast_timer_set_mode(enum clock_event_mode mode,
-	struct clock_event_device *evt)
-{
-}
-
-static void __cpuinit broadcast_timer_setup(struct clock_event_device *evt)
-{
-	evt->name	= "dummy_timer";
-	evt->features	= CLOCK_EVT_FEAT_ONESHOT |
-			  CLOCK_EVT_FEAT_PERIODIC |
-			  CLOCK_EVT_FEAT_DUMMY;
-	evt->rating	= 100;
-	evt->mult	= 1;
-	evt->set_mode	= broadcast_timer_set_mode;
-
-	clockevents_register_device(evt);
-}
-
 static struct local_timer_ops *lt_ops;
 
 #ifdef CONFIG_LOCAL_TIMERS
@@ -510,8 +492,8 @@ static void __cpuinit percpu_timer_setup(void)
 
 	evt->cpumask = cpumask_of(cpu);
 
-	if (!lt_ops || lt_ops->setup(evt))
-		broadcast_timer_setup(evt);
+	if (lt_ops)
+		lt_ops->setup(evt);
 }
 
 #ifdef CONFIG_HOTPLUG_CPU
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Fri Apr 19 12:19:40 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Fri, 19 Apr 2013 09:19:40 -0700
Subject: [PATCHv5 06/11] ARM: EXYNOS4: Divorce mct from local timer API
In-Reply-To: <1366388385-30722-1-git-send-email-sboyd@codeaurora.org>
References: <1366388385-30722-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1366388385-30722-7-git-send-email-sboyd@codeaurora.org>

Separate the mct local timers from the local timer API. This will
allow us to remove ARM local timer support in the near future and
gets us closer to moving this driver to drivers/clocksource.

Cc: Kukjin Kim <kgene.kim at samsung.com>
Cc: Thomas Abraham <thomas.abraham at linaro.org>
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 drivers/clocksource/exynos_mct.c | 61 ++++++++++++++++++++++++++++------------
 1 file changed, 43 insertions(+), 18 deletions(-)

diff --git a/drivers/clocksource/exynos_mct.c b/drivers/clocksource/exynos_mct.c
index a5e9b48..ed4f463 100644
--- a/drivers/clocksource/exynos_mct.c
+++ b/drivers/clocksource/exynos_mct.c
@@ -16,6 +16,7 @@
 #include <linux/err.h>
 #include <linux/clk.h>
 #include <linux/clockchips.h>
+#include <linux/cpu.h>
 #include <linux/platform_device.h>
 #include <linux/delay.h>
 #include <linux/percpu.h>
@@ -24,8 +25,6 @@
 #include <linux/of_address.h>
 #include <linux/clocksource.h>
 
-#include <asm/localtimer.h>
-
 #include <plat/cpu.h>
 
 #include <mach/map.h>
@@ -85,7 +84,7 @@ static unsigned int mct_int_type;
 static int mct_irqs[MCT_NR_IRQS];
 
 struct mct_clock_event_device {
-	struct clock_event_device *evt;
+	struct clock_event_device evt;
 	unsigned long base;
 	char name[10];
 };
@@ -300,8 +299,6 @@ static void exynos4_clockevent_init(void)
 	setup_irq(mct_irqs[MCT_G0_IRQ], &mct_comp_event_irq);
 }
 
-#ifdef CONFIG_LOCAL_TIMERS
-
 static DEFINE_PER_CPU(struct mct_clock_event_device, percpu_mct_tick);
 
 /* Clock event handling */
@@ -374,7 +371,7 @@ static inline void exynos4_tick_set_mode(enum clock_event_mode mode,
 
 static int exynos4_mct_tick_clear(struct mct_clock_event_device *mevt)
 {
-	struct clock_event_device *evt = mevt->evt;
+	struct clock_event_device *evt = &mevt->evt;
 
 	/*
 	 * This is for supporting oneshot mode.
@@ -396,7 +393,7 @@ static int exynos4_mct_tick_clear(struct mct_clock_event_device *mevt)
 static irqreturn_t exynos4_mct_tick_isr(int irq, void *dev_id)
 {
 	struct mct_clock_event_device *mevt = dev_id;
-	struct clock_event_device *evt = mevt->evt;
+	struct clock_event_device *evt = &mevt->evt;
 
 	exynos4_mct_tick_clear(mevt);
 
@@ -422,8 +419,7 @@ static int __cpuinit exynos4_local_timer_setup(struct clock_event_device *evt)
 	struct mct_clock_event_device *mevt;
 	unsigned int cpu = smp_processor_id();
 
-	mevt = this_cpu_ptr(&percpu_mct_tick);
-	mevt->evt = evt;
+	mevt = container_of(evt, struct mct_clock_event_device, evt);
 
 	mevt->base = EXYNOS4_MCT_L_BASE(cpu);
 	sprintf(mevt->name, "mct_tick%d", cpu);
@@ -457,7 +453,7 @@ static int __cpuinit exynos4_local_timer_setup(struct clock_event_device *evt)
 	return 0;
 }
 
-static void exynos4_local_timer_stop(struct clock_event_device *evt)
+static void __cpuinit exynos4_local_timer_stop(struct clock_event_device *evt)
 {
 	unsigned int cpu = smp_processor_id();
 	evt->set_mode(CLOCK_EVT_MODE_UNUSED, evt);
@@ -470,14 +466,37 @@ static void exynos4_local_timer_stop(struct clock_event_device *evt)
 		disable_percpu_irq(mct_irqs[MCT_L0_IRQ]);
 }
 
-static struct local_timer_ops exynos4_mct_tick_ops __cpuinitdata = {
-	.setup	= exynos4_local_timer_setup,
-	.stop	= exynos4_local_timer_stop,
+static int __cpuinit exynos4_mct_cpu_notify(struct notifier_block *self,
+					   unsigned long action, void *hcpu)
+{
+	struct mct_clock_event_device *mevt;
+
+	/*
+	 * Grab cpu pointer in each case to avoid spurious
+	 * preemptible warnings
+	 */
+	switch (action & ~CPU_TASKS_FROZEN) {
+	case CPU_STARTING:
+		mevt = this_cpu_ptr(&percpu_mct_tick);
+		exynos4_local_timer_setup(&mevt->evt);
+		break;
+	case CPU_DYING:
+		mevt = this_cpu_ptr(&percpu_mct_tick);
+		exynos4_local_timer_stop(&mevt->evt);
+		break;
+	}
+
+	return NOTIFY_OK;
+}
+
+static struct notifier_block exynos4_mct_cpu_nb __cpuinitdata = {
+	.notifier_call = exynos4_mct_cpu_notify,
 };
-#endif /* CONFIG_LOCAL_TIMERS */
 
 static void __init exynos4_timer_resources(struct device_node *np, void __iomem *base)
 {
+	int err;
+	struct mct_clock_event_device *mevt = this_cpu_ptr(&percpu_mct_tick);
 	struct clk *mct_clk, *tick_clk;
 
 	tick_clk = np ? of_clk_get_by_name(np, "fin_pll") :
@@ -495,9 +514,7 @@ static void __init exynos4_timer_resources(struct device_node *np, void __iomem
 	if (!reg_base)
 		panic("%s: unable to ioremap mct address space\n", __func__);
 
-#ifdef CONFIG_LOCAL_TIMERS
 	if (mct_int_type == MCT_INT_PPI) {
-		int err;
 
 		err = request_percpu_irq(mct_irqs[MCT_L0_IRQ],
 					 exynos4_mct_tick_isr, "MCT",
@@ -506,8 +523,16 @@ static void __init exynos4_timer_resources(struct device_node *np, void __iomem
 		     mct_irqs[MCT_L0_IRQ], err);
 	}
 
-	local_timer_register(&exynos4_mct_tick_ops);
-#endif /* CONFIG_LOCAL_TIMERS */
+	err = register_cpu_notifier(&exynos4_mct_cpu_nb);
+	if (err)
+		goto out_irq;
+
+	/* Immediately configure the timer on the boot CPU */
+	exynos4_local_timer_setup(&mevt->evt);
+	return;
+
+out_irq:
+	free_percpu_irq(mct_irqs[MCT_L0_IRQ], &percpu_mct_tick);
 }
 
 void __init mct_init(void)
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Fri Apr 19 12:19:42 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Fri, 19 Apr 2013 09:19:42 -0700
Subject: [PATCHv5 08/11] ARM: msm: Divorce msm_timer from local timer API
In-Reply-To: <1366388385-30722-1-git-send-email-sboyd@codeaurora.org>
References: <1366388385-30722-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1366388385-30722-9-git-send-email-sboyd@codeaurora.org>

Separate the msm_timer from the local timer API. This will allow
us to remove ARM local timer support in the near future and gets
us closer to moving this driver to drivers/clocksource.

Acked-by: David Brown <davidb at codeaurora.org>
Cc: Daniel Walker <dwalker at fifo99.com>
Cc: Bryan Huntsman <bryanh at codeaurora.org>
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 arch/arm/mach-msm/timer.c | 122 ++++++++++++++++++++++++++--------------------
 1 file changed, 68 insertions(+), 54 deletions(-)

diff --git a/arch/arm/mach-msm/timer.c b/arch/arm/mach-msm/timer.c
index 284313f..02466d4 100644
--- a/arch/arm/mach-msm/timer.c
+++ b/arch/arm/mach-msm/timer.c
@@ -16,6 +16,7 @@
 
 #include <linux/clocksource.h>
 #include <linux/clockchips.h>
+#include <linux/cpu.h>
 #include <linux/init.h>
 #include <linux/interrupt.h>
 #include <linux/irq.h>
@@ -25,7 +26,6 @@
 #include <linux/of_irq.h>
 
 #include <asm/mach/time.h>
-#include <asm/localtimer.h>
 #include <asm/sched_clock.h>
 
 #include "common.h"
@@ -49,7 +49,7 @@ static void __iomem *sts_base;
 
 static irqreturn_t msm_timer_interrupt(int irq, void *dev_id)
 {
-	struct clock_event_device *evt = *(struct clock_event_device **)dev_id;
+	struct clock_event_device *evt = dev_id;
 	/* Stop the timer tick */
 	if (evt->mode == CLOCK_EVT_MODE_ONESHOT) {
 		u32 ctrl = readl_relaxed(event_base + TIMER_ENABLE);
@@ -101,18 +101,7 @@ static void msm_timer_set_mode(enum clock_event_mode mode,
 	writel_relaxed(ctrl, event_base + TIMER_ENABLE);
 }
 
-static struct clock_event_device msm_clockevent = {
-	.name		= "gp_timer",
-	.features	= CLOCK_EVT_FEAT_ONESHOT,
-	.rating		= 200,
-	.set_next_event	= msm_timer_set_next_event,
-	.set_mode	= msm_timer_set_mode,
-};
-
-static union {
-	struct clock_event_device *evt;
-	struct clock_event_device * __percpu *percpu_evt;
-} msm_evt;
+static struct clock_event_device __percpu *msm_evt;
 
 static void __iomem *source_base;
 
@@ -138,37 +127,65 @@ static struct clocksource msm_clocksource = {
 	.flags	= CLOCK_SOURCE_IS_CONTINUOUS,
 };
 
-#ifdef CONFIG_LOCAL_TIMERS
+static int msm_timer_irq;
+static int msm_timer_has_ppi;
+
 static int __cpuinit msm_local_timer_setup(struct clock_event_device *evt)
 {
-	/* Use existing clock_event for cpu 0 */
-	if (!smp_processor_id())
-		return 0;
+	int cpu = smp_processor_id();
+	int err;
 
-	evt->irq = msm_clockevent.irq;
+	evt->irq = msm_timer_irq;
 	evt->name = "local_timer";
-	evt->features = msm_clockevent.features;
-	evt->rating = msm_clockevent.rating;
+	evt->features = CLOCK_EVT_FEAT_ONESHOT;
+	evt->rating = 200;
 	evt->set_mode = msm_timer_set_mode;
 	evt->set_next_event = msm_timer_set_next_event;
+	evt->cpumask = cpumask_of(cpu);
+
+	clockevents_config_and_register(evt, GPT_HZ, 4, 0xffffffff);
+
+	if (msm_timer_has_ppi) {
+		enable_percpu_irq(evt->irq, IRQ_TYPE_EDGE_RISING);
+	} else {
+		err = request_irq(evt->irq, msm_timer_interrupt,
+				IRQF_TIMER | IRQF_NOBALANCING |
+				IRQF_TRIGGER_RISING, "gp_timer", evt);
+		if (err)
+			pr_err("request_irq failed\n");
+	}
 
-	*__this_cpu_ptr(msm_evt.percpu_evt) = evt;
-	clockevents_config_and_register(evt, GPT_HZ, 4, 0xf0000000);
-	enable_percpu_irq(evt->irq, IRQ_TYPE_EDGE_RISING);
 	return 0;
 }
 
-static void msm_local_timer_stop(struct clock_event_device *evt)
+static void __cpuinit msm_local_timer_stop(struct clock_event_device *evt)
 {
 	evt->set_mode(CLOCK_EVT_MODE_UNUSED, evt);
 	disable_percpu_irq(evt->irq);
 }
 
-static struct local_timer_ops msm_local_timer_ops __cpuinitdata = {
-	.setup	= msm_local_timer_setup,
-	.stop	= msm_local_timer_stop,
+static int __cpuinit msm_timer_cpu_notify(struct notifier_block *self,
+					   unsigned long action, void *hcpu)
+{
+	/*
+	 * Grab cpu pointer in each case to avoid spurious
+	 * preemptible warnings
+	 */
+	switch (action & ~CPU_TASKS_FROZEN) {
+	case CPU_STARTING:
+		msm_local_timer_setup(this_cpu_ptr(msm_evt));
+		break;
+	case CPU_DYING:
+		msm_local_timer_stop(this_cpu_ptr(msm_evt));
+		break;
+	}
+
+	return NOTIFY_OK;
+}
+
+static struct notifier_block msm_timer_cpu_nb __cpuinitdata = {
+	.notifier_call = msm_timer_cpu_notify,
 };
-#endif /* CONFIG_LOCAL_TIMERS */
 
 static notrace u32 msm_sched_clock_read(void)
 {
@@ -178,38 +195,35 @@ static notrace u32 msm_sched_clock_read(void)
 static void __init msm_timer_init(u32 dgt_hz, int sched_bits, int irq,
 				  bool percpu)
 {
-	struct clock_event_device *ce = &msm_clockevent;
 	struct clocksource *cs = &msm_clocksource;
-	int res;
+	int res = 0;
+
+	msm_timer_irq = irq;
+	msm_timer_has_ppi = percpu;
+
+	msm_evt = alloc_percpu(struct clock_event_device);
+	if (!msm_evt) {
+		pr_err("memory allocation failed for clockevents\n");
+		goto err;
+	}
 
-	ce->cpumask = cpumask_of(0);
-	ce->irq = irq;
+	if (percpu)
+		res = request_percpu_irq(irq, msm_timer_interrupt,
+					 "gp_timer", msm_evt);
 
-	clockevents_config_and_register(ce, GPT_HZ, 4, 0xffffffff);
-	if (percpu) {
-		msm_evt.percpu_evt = alloc_percpu(struct clock_event_device *);
-		if (!msm_evt.percpu_evt) {
-			pr_err("memory allocation failed for %s\n", ce->name);
+	if (res) {
+		pr_err("request_percpu_irq failed\n");
+	} else {
+		res = register_cpu_notifier(&msm_timer_cpu_nb);
+		if (res) {
+			free_percpu_irq(irq, msm_evt);
 			goto err;
 		}
-		*__this_cpu_ptr(msm_evt.percpu_evt) = ce;
-		res = request_percpu_irq(ce->irq, msm_timer_interrupt,
-					 ce->name, msm_evt.percpu_evt);
-		if (!res) {
-			enable_percpu_irq(ce->irq, IRQ_TYPE_EDGE_RISING);
-#ifdef CONFIG_LOCAL_TIMERS
-			local_timer_register(&msm_local_timer_ops);
-#endif
-		}
-	} else {
-		msm_evt.evt = ce;
-		res = request_irq(ce->irq, msm_timer_interrupt,
-				  IRQF_TIMER | IRQF_NOBALANCING |
-				  IRQF_TRIGGER_RISING, ce->name, &msm_evt.evt);
+
+		/* Immediately configure the timer on the boot CPU */
+		msm_local_timer_setup(__this_cpu_ptr(msm_evt));
 	}
 
-	if (res)
-		pr_err("request_irq failed for %s\n", ce->name);
 err:
 	writel_relaxed(TIMER_ENABLE_EN, source_base + TIMER_ENABLE);
 	res = clocksource_register_hz(cs, dgt_hz);
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Fri Apr 19 12:19:41 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Fri, 19 Apr 2013 09:19:41 -0700
Subject: [PATCHv5 07/11] ARM: PRIMA2: Divorce timer-marco from local timer API
In-Reply-To: <1366388385-30722-1-git-send-email-sboyd@codeaurora.org>
References: <1366388385-30722-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1366388385-30722-8-git-send-email-sboyd@codeaurora.org>

Separate the marco local timers from the local timer API. This
will allow us to remove ARM local timer support in the near future
and gets us closer to moving this driver to drivers/clocksource.

Cc: Barry Song <baohua.song at csr.com>
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 drivers/clocksource/timer-marco.c | 100 ++++++++++++++++++++------------------
 1 file changed, 54 insertions(+), 46 deletions(-)

diff --git a/drivers/clocksource/timer-marco.c b/drivers/clocksource/timer-marco.c
index 97738db..ba97bc1 100644
--- a/drivers/clocksource/timer-marco.c
+++ b/drivers/clocksource/timer-marco.c
@@ -10,6 +10,7 @@
 #include <linux/interrupt.h>
 #include <linux/clockchips.h>
 #include <linux/clocksource.h>
+#include <linux/cpu.h>
 #include <linux/bitops.h>
 #include <linux/irq.h>
 #include <linux/clk.h>
@@ -18,7 +19,6 @@
 #include <linux/of_irq.h>
 #include <linux/of_address.h>
 #include <asm/sched_clock.h>
-#include <asm/localtimer.h>
 #include <asm/mach/time.h>
 
 #define SIRFSOC_TIMER_32COUNTER_0_CTRL			0x0000
@@ -151,13 +151,7 @@ static void sirfsoc_clocksource_resume(struct clocksource *cs)
 		BIT(1) | BIT(0), sirfsoc_timer_base + SIRFSOC_TIMER_64COUNTER_CTRL);
 }
 
-static struct clock_event_device sirfsoc_clockevent = {
-	.name = "sirfsoc_clockevent",
-	.rating = 200,
-	.features = CLOCK_EVT_FEAT_ONESHOT,
-	.set_mode = sirfsoc_timer_set_mode,
-	.set_next_event = sirfsoc_timer_set_next_event,
-};
+static struct clock_event_device __percpu *sirfsoc_clockevent;
 
 static struct clocksource sirfsoc_clocksource = {
 	.name = "sirfsoc_clocksource",
@@ -173,11 +167,8 @@ static struct irqaction sirfsoc_timer_irq = {
 	.name = "sirfsoc_timer0",
 	.flags = IRQF_TIMER | IRQF_NOBALANCING,
 	.handler = sirfsoc_timer_interrupt,
-	.dev_id = &sirfsoc_clockevent,
 };
 
-#ifdef CONFIG_LOCAL_TIMERS
-
 static struct irqaction sirfsoc_timer1_irq = {
 	.name = "sirfsoc_timer1",
 	.flags = IRQF_TIMER | IRQF_NOBALANCING,
@@ -186,56 +177,77 @@ static struct irqaction sirfsoc_timer1_irq = {
 
 static int __cpuinit sirfsoc_local_timer_setup(struct clock_event_device *ce)
 {
-	/* Use existing clock_event for cpu 0 */
-	if (!smp_processor_id())
-		return 0;
+	int cpu = smp_processor_id();
+	struct irqaction *action;
+
+	if (cpu == 0)
+		action = &sirfsoc_timer_irq;
+	else
+		action = &sirfsoc_timer1_irq;
 
-	ce->irq = sirfsoc_timer1_irq.irq;
+	ce->irq = action->irq;
 	ce->name = "local_timer";
-	ce->features = sirfsoc_clockevent.features;
-	ce->rating = sirfsoc_clockevent.rating;
+	ce->features = CLOCK_EVT_FEAT_ONESHOT;
+	ce->rating = 200;
 	ce->set_mode = sirfsoc_timer_set_mode;
 	ce->set_next_event = sirfsoc_timer_set_next_event;
-	ce->shift = sirfsoc_clockevent.shift;
-	ce->mult = sirfsoc_clockevent.mult;
-	ce->max_delta_ns = sirfsoc_clockevent.max_delta_ns;
-	ce->min_delta_ns = sirfsoc_clockevent.min_delta_ns;
+	clockevents_calc_mult_shift(ce, CLOCK_TICK_RATE, 60);
+	ce->max_delta_ns = clockevent_delta2ns(-2, ce);
+	ce->min_delta_ns = clockevent_delta2ns(2, ce);
+	ce->cpumask = cpumask_of(cpu);
 
-	sirfsoc_timer1_irq.dev_id = ce;
-	BUG_ON(setup_irq(ce->irq, &sirfsoc_timer1_irq));
-	irq_set_affinity(sirfsoc_timer1_irq.irq, cpumask_of(1));
+	action->dev_id = ce;
+	BUG_ON(setup_irq(ce->irq, action));
+	irq_set_affinity(action->irq, cpumask_of(cpu));
 
 	clockevents_register_device(ce);
 	return 0;
 }
 
-static void sirfsoc_local_timer_stop(struct clock_event_device *ce)
+static void __cpuinit sirfsoc_local_timer_stop(struct clock_event_device *ce)
 {
+	int cpu = smp_processor_id();
+
 	sirfsoc_timer_count_disable(1);
 
-	remove_irq(sirfsoc_timer1_irq.irq, &sirfsoc_timer1_irq);
+	if (cpu == 0)
+		remove_irq(sirfsoc_timer_irq.irq, &sirfsoc_timer_irq);
+	else
+		remove_irq(sirfsoc_timer1_irq.irq, &sirfsoc_timer1_irq);
 }
 
-static struct local_timer_ops sirfsoc_local_timer_ops __cpuinitdata = {
-	.setup	= sirfsoc_local_timer_setup,
-	.stop	= sirfsoc_local_timer_stop,
+static int __cpuinit sirfsoc_cpu_notify(struct notifier_block *self,
+					   unsigned long action, void *hcpu)
+{
+	/*
+	 * Grab cpu pointer in each case to avoid spurious
+	 * preemptible warnings
+	 */
+	switch (action & ~CPU_TASKS_FROZEN) {
+	case CPU_STARTING:
+		sirfsoc_local_timer_setup(this_cpu_ptr(sirfsoc_clockevent));
+		break;
+	case CPU_DYING:
+		sirfsoc_local_timer_stop(this_cpu_ptr(sirfsoc_clockevent));
+		break;
+	}
+
+	return NOTIFY_OK;
+}
+
+static struct notifier_block sirfsoc_cpu_nb __cpuinitdata = {
+	.notifier_call = sirfsoc_cpu_notify,
 };
-#endif /* CONFIG_LOCAL_TIMERS */
 
 static void __init sirfsoc_clockevent_init(void)
 {
-	clockevents_calc_mult_shift(&sirfsoc_clockevent, CLOCK_TICK_RATE, 60);
-
-	sirfsoc_clockevent.max_delta_ns =
-		clockevent_delta2ns(-2, &sirfsoc_clockevent);
-	sirfsoc_clockevent.min_delta_ns =
-		clockevent_delta2ns(2, &sirfsoc_clockevent);
-
-	sirfsoc_clockevent.cpumask = cpumask_of(0);
-	clockevents_register_device(&sirfsoc_clockevent);
-#ifdef CONFIG_LOCAL_TIMERS
-	local_timer_register(&sirfsoc_local_timer_ops);
-#endif
+	sirfsoc_clockevent = alloc_percpu(struct clock_event_device);
+	BUG_ON(!sirfsoc_clockevent);
+
+	BUG_ON(register_cpu_notifier(&sirfsoc_cpu_nb));
+
+	/* Immediately configure the timer on the boot CPU */
+	sirfsoc_local_timer_setup(this_cpu_ptr(sirfsoc_clockevent));
 }
 
 /* initialize the kernel jiffy timer source */
@@ -273,8 +285,6 @@ static void __init sirfsoc_marco_timer_init(void)
 
 	BUG_ON(clocksource_register_hz(&sirfsoc_clocksource, CLOCK_TICK_RATE));
 
-	BUG_ON(setup_irq(sirfsoc_timer_irq.irq, &sirfsoc_timer_irq));
-
 	sirfsoc_clockevent_init();
 }
 
@@ -288,11 +298,9 @@ static void __init sirfsoc_of_timer_init(struct device_node *np)
 	if (!sirfsoc_timer_irq.irq)
 		panic("No irq passed for timer0 via DT\n");
 
-#ifdef CONFIG_LOCAL_TIMERS
 	sirfsoc_timer1_irq.irq = irq_of_parse_and_map(np, 1);
 	if (!sirfsoc_timer1_irq.irq)
 		panic("No irq passed for timer1 via DT\n");
-#endif
 
 	sirfsoc_marco_timer_init();
 }
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Fri Apr 19 12:19:44 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Fri, 19 Apr 2013 09:19:44 -0700
Subject: [PATCHv5 10/11] clocksource: time-armada-370-xp: Divorce from local
 timer API
In-Reply-To: <1366388385-30722-1-git-send-email-sboyd@codeaurora.org>
References: <1366388385-30722-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1366388385-30722-11-git-send-email-sboyd@codeaurora.org>

Separate the armada 370xp local timers from the local timer API.
This will allow us to remove ARM local timer support in the near
future and makes this driver multi-architecture friendly.

Acked-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
Tested-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 drivers/clocksource/time-armada-370-xp.c | 89 +++++++++++++++-----------------
 1 file changed, 41 insertions(+), 48 deletions(-)

diff --git a/drivers/clocksource/time-armada-370-xp.c b/drivers/clocksource/time-armada-370-xp.c
index efe4aef..4a31e86 100644
--- a/drivers/clocksource/time-armada-370-xp.c
+++ b/drivers/clocksource/time-armada-370-xp.c
@@ -19,6 +19,7 @@
 #include <linux/platform_device.h>
 #include <linux/kernel.h>
 #include <linux/clk.h>
+#include <linux/cpu.h>
 #include <linux/timer.h>
 #include <linux/clockchips.h>
 #include <linux/interrupt.h>
@@ -31,7 +32,6 @@
 #include <linux/time-armada-370-xp.h>
 
 #include <asm/sched_clock.h>
-#include <asm/localtimer.h>
 /*
  * Timer block registers.
  */
@@ -70,7 +70,7 @@ static bool timer25Mhz = true;
  */
 static u32 ticks_per_jiffy;
 
-static struct clock_event_device __percpu **percpu_armada_370_xp_evt;
+static struct clock_event_device __percpu *armada_370_xp_evt;
 
 static u32 notrace armada_370_xp_read_sched_clock(void)
 {
@@ -143,21 +143,14 @@ armada_370_xp_clkevt_mode(enum clock_event_mode mode,
 	}
 }
 
-static struct clock_event_device armada_370_xp_clkevt = {
-	.name		= "armada_370_xp_per_cpu_tick",
-	.features	= CLOCK_EVT_FEAT_ONESHOT | CLOCK_EVT_FEAT_PERIODIC,
-	.shift		= 32,
-	.rating		= 300,
-	.set_next_event	= armada_370_xp_clkevt_next_event,
-	.set_mode	= armada_370_xp_clkevt_mode,
-};
+static int armada_370_xp_clkevt_irq;
 
 static irqreturn_t armada_370_xp_timer_interrupt(int irq, void *dev_id)
 {
 	/*
 	 * ACK timer interrupt and call event handler.
 	 */
-	struct clock_event_device *evt = *(struct clock_event_device **)dev_id;
+	struct clock_event_device *evt = dev_id;
 
 	writel(TIMER0_CLR_MASK, local_base + LCL_TIMER_EVENTS_STATUS);
 	evt->event_handler(evt);
@@ -173,42 +166,55 @@ static int __cpuinit armada_370_xp_timer_setup(struct clock_event_device *evt)
 	u32 u;
 	int cpu = smp_processor_id();
 
-	/* Use existing clock_event for cpu 0 */
-	if (!smp_processor_id())
-		return 0;
-
 	u = readl(local_base + TIMER_CTRL_OFF);
 	if (timer25Mhz)
 		writel(u | TIMER0_25MHZ, local_base + TIMER_CTRL_OFF);
 	else
 		writel(u & ~TIMER0_25MHZ, local_base + TIMER_CTRL_OFF);
 
-	evt->name		= armada_370_xp_clkevt.name;
-	evt->irq		= armada_370_xp_clkevt.irq;
-	evt->features		= armada_370_xp_clkevt.features;
-	evt->shift		= armada_370_xp_clkevt.shift;
-	evt->rating		= armada_370_xp_clkevt.rating,
+	evt->name		= "armada_370_xp_per_cpu_tick",
+	evt->features		= CLOCK_EVT_FEAT_ONESHOT |
+				  CLOCK_EVT_FEAT_PERIODIC;
+	evt->shift		= 32,
+	evt->rating		= 300,
 	evt->set_next_event	= armada_370_xp_clkevt_next_event,
 	evt->set_mode		= armada_370_xp_clkevt_mode,
+	evt->irq		= armada_370_xp_clkevt_irq;
 	evt->cpumask		= cpumask_of(cpu);
 
-	*__this_cpu_ptr(percpu_armada_370_xp_evt) = evt;
-
 	clockevents_config_and_register(evt, timer_clk, 1, 0xfffffffe);
 	enable_percpu_irq(evt->irq, 0);
 
 	return 0;
 }
 
-static void  armada_370_xp_timer_stop(struct clock_event_device *evt)
+static void __cpuinit armada_370_xp_timer_stop(struct clock_event_device *evt)
 {
 	evt->set_mode(CLOCK_EVT_MODE_UNUSED, evt);
 	disable_percpu_irq(evt->irq);
 }
 
-static struct local_timer_ops armada_370_xp_local_timer_ops __cpuinitdata = {
-	.setup	= armada_370_xp_timer_setup,
-	.stop	=  armada_370_xp_timer_stop,
+static int __cpuinit armada_370_xp_timer_cpu_notify(struct notifier_block *self,
+					   unsigned long action, void *hcpu)
+{
+	/*
+	 * Grab cpu pointer in each case to avoid spurious
+	 * preemptible warnings
+	 */
+	switch (action & ~CPU_TASKS_FROZEN) {
+	case CPU_STARTING:
+		armada_370_xp_timer_setup(this_cpu_ptr(armada_370_xp_evt));
+		break;
+	case CPU_DYING:
+		armada_370_xp_timer_stop(this_cpu_ptr(armada_370_xp_evt));
+		break;
+	}
+
+	return NOTIFY_OK;
+}
+
+static struct notifier_block armada_370_xp_timer_cpu_nb __cpuinitdata = {
+	.notifier_call = armada_370_xp_timer_cpu_notify,
 };
 
 void __init armada_370_xp_timer_init(void)
@@ -224,9 +230,6 @@ void __init armada_370_xp_timer_init(void)
 
 	if (of_find_property(np, "marvell,timer-25Mhz", NULL)) {
 		/* The fixed 25MHz timer is available so let's use it */
-		u = readl(local_base + TIMER_CTRL_OFF);
-		writel(u | TIMER0_25MHZ,
-		       local_base + TIMER_CTRL_OFF);
 		u = readl(timer_base + TIMER_CTRL_OFF);
 		writel(u | TIMER0_25MHZ,
 		       timer_base + TIMER_CTRL_OFF);
@@ -236,9 +239,6 @@ void __init armada_370_xp_timer_init(void)
 		struct clk *clk = of_clk_get(np, 0);
 		WARN_ON(IS_ERR(clk));
 		rate =  clk_get_rate(clk);
-		u = readl(local_base + TIMER_CTRL_OFF);
-		writel(u & ~(TIMER0_25MHZ),
-		       local_base + TIMER_CTRL_OFF);
 
 		u = readl(timer_base + TIMER_CTRL_OFF);
 		writel(u & ~(TIMER0_25MHZ),
@@ -252,7 +252,7 @@ void __init armada_370_xp_timer_init(void)
 	 * We use timer 0 as clocksource, and private(local) timer 0
 	 * for clockevents
 	 */
-	armada_370_xp_clkevt.irq = irq_of_parse_and_map(np, 4);
+	armada_370_xp_clkevt_irq = irq_of_parse_and_map(np, 4);
 
 	ticks_per_jiffy = (timer_clk + HZ / 2) / HZ;
 
@@ -277,26 +277,19 @@ void __init armada_370_xp_timer_init(void)
 			      "armada_370_xp_clocksource",
 			      timer_clk, 300, 32, clocksource_mmio_readl_down);
 
-	/* Register the clockevent on the private timer of CPU 0 */
-	armada_370_xp_clkevt.cpumask = cpumask_of(0);
-	clockevents_config_and_register(&armada_370_xp_clkevt,
-					timer_clk, 1, 0xfffffffe);
+	register_cpu_notifier(&armada_370_xp_timer_cpu_nb);
 
-	percpu_armada_370_xp_evt = alloc_percpu(struct clock_event_device *);
+	armada_370_xp_evt = alloc_percpu(struct clock_event_device);
 
 
 	/*
 	 * Setup clockevent timer (interrupt-driven).
 	 */
-	*__this_cpu_ptr(percpu_armada_370_xp_evt) = &armada_370_xp_clkevt;
-	res = request_percpu_irq(armada_370_xp_clkevt.irq,
+	res = request_percpu_irq(armada_370_xp_clkevt_irq,
 				armada_370_xp_timer_interrupt,
-				armada_370_xp_clkevt.name,
-				percpu_armada_370_xp_evt);
-	if (!res) {
-		enable_percpu_irq(armada_370_xp_clkevt.irq, 0);
-#ifdef CONFIG_LOCAL_TIMERS
-		local_timer_register(&armada_370_xp_local_timer_ops);
-#endif
-	}
+				"armada_370_xp_per_cpu_tick",
+				armada_370_xp_evt);
+	/* Immediately configure the timer on the boot CPU */
+	if (!res)
+		armada_370_xp_timer_setup(this_cpu_ptr(armada_370_xp_evt));
 }
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Fri Apr 19 12:19:43 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Fri, 19 Apr 2013 09:19:43 -0700
Subject: [PATCHv5 09/11] clocksource: time-armada-370-xp: Fix sparse warning
In-Reply-To: <1366388385-30722-1-git-send-email-sboyd@codeaurora.org>
References: <1366388385-30722-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1366388385-30722-10-git-send-email-sboyd@codeaurora.org>

drivers/clocksource/time-armada-370-xp.c:217:13: warning: symbol
'armada_370_xp_timer_init' was not declared. Should it be static?

Also remove the __init marking in the prototype as it's
unnecessary and drop the init.h file.

Acked-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 drivers/clocksource/time-armada-370-xp.c | 3 ++-
 include/linux/time-armada-370-xp.h       | 4 +---
 2 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/clocksource/time-armada-370-xp.c b/drivers/clocksource/time-armada-370-xp.c
index 47a6730..efe4aef 100644
--- a/drivers/clocksource/time-armada-370-xp.c
+++ b/drivers/clocksource/time-armada-370-xp.c
@@ -27,10 +27,11 @@
 #include <linux/of_address.h>
 #include <linux/irq.h>
 #include <linux/module.h>
+#include <linux/percpu.h>
+#include <linux/time-armada-370-xp.h>
 
 #include <asm/sched_clock.h>
 #include <asm/localtimer.h>
-#include <linux/percpu.h>
 /*
  * Timer block registers.
  */
diff --git a/include/linux/time-armada-370-xp.h b/include/linux/time-armada-370-xp.h
index dfdfdc0..6fb0856 100644
--- a/include/linux/time-armada-370-xp.h
+++ b/include/linux/time-armada-370-xp.h
@@ -11,8 +11,6 @@
 #ifndef __TIME_ARMADA_370_XPPRCMU_H
 #define __TIME_ARMADA_370_XPPRCMU_H
 
-#include <linux/init.h>
-
-void __init armada_370_xp_timer_init(void);
+void armada_370_xp_timer_init(void);
 
 #endif
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Fri Apr 19 12:19:38 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Fri, 19 Apr 2013 09:19:38 -0700
Subject: [PATCHv5 04/11] ARM: smp_twd: Divorce smp_twd from local timer API
In-Reply-To: <1366388385-30722-1-git-send-email-sboyd@codeaurora.org>
References: <1366388385-30722-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1366388385-30722-5-git-send-email-sboyd@codeaurora.org>

Separate the smp_twd timers from the local timer API. This will
allow us to remove ARM local timer support in the near future and
gets us closer to moving this driver to drivers/clocksource.

Cc: Russell King <linux at arm.linux.org.uk>
Cc: Tony Lindgren <tony at atomide.com>
Tested-by: Mark Rutland <mark.rutland at arm.com>
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 arch/arm/Kconfig               |  2 +-
 arch/arm/kernel/smp_twd.c      | 64 ++++++++++++++++++++++++++++--------------
 arch/arm/mach-highbank/Kconfig |  2 +-
 arch/arm/mach-imx/Kconfig      |  2 +-
 arch/arm/mach-omap2/Kconfig    |  2 +-
 arch/arm/mach-realview/Kconfig |  8 +++---
 arch/arm/mach-spear/Kconfig    |  2 +-
 arch/arm/mach-tegra/Kconfig    |  2 +-
 arch/arm/mach-ux500/Kconfig    |  2 +-
 arch/arm/mach-vexpress/Kconfig |  2 +-
 arch/arm/mach-zynq/Kconfig     |  2 +-
 11 files changed, 56 insertions(+), 34 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 10c3466..14c0a3d 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -634,7 +634,7 @@ config ARCH_SHMOBILE
 	select CLKDEV_LOOKUP
 	select GENERIC_CLOCKEVENTS
 	select HAVE_ARM_SCU if SMP
-	select HAVE_ARM_TWD if LOCAL_TIMERS
+	select HAVE_ARM_TWD if SMP
 	select HAVE_CLK
 	select HAVE_MACH_CLKDEV
 	select HAVE_SMP
diff --git a/arch/arm/kernel/smp_twd.c b/arch/arm/kernel/smp_twd.c
index 90525d9..aac1495 100644
--- a/arch/arm/kernel/smp_twd.c
+++ b/arch/arm/kernel/smp_twd.c
@@ -11,6 +11,7 @@
 #include <linux/init.h>
 #include <linux/kernel.h>
 #include <linux/clk.h>
+#include <linux/cpu.h>
 #include <linux/delay.h>
 #include <linux/device.h>
 #include <linux/err.h>
@@ -24,7 +25,6 @@
 
 #include <asm/smp_plat.h>
 #include <asm/smp_twd.h>
-#include <asm/localtimer.h>
 
 /* set up by the platform code */
 static void __iomem *twd_base;
@@ -33,7 +33,7 @@ static struct clk *twd_clk;
 static unsigned long twd_timer_rate;
 static DEFINE_PER_CPU(bool, percpu_setup_called);
 
-static struct clock_event_device __percpu **twd_evt;
+static struct clock_event_device __percpu *twd_evt;
 static int twd_ppi;
 
 static void twd_set_mode(enum clock_event_mode mode,
@@ -90,8 +90,10 @@ static int twd_timer_ack(void)
 	return 0;
 }
 
-static void twd_timer_stop(struct clock_event_device *clk)
+static void twd_timer_stop(void)
 {
+	struct clock_event_device *clk = __this_cpu_ptr(twd_evt);
+
 	twd_set_mode(CLOCK_EVT_MODE_UNUSED, clk);
 	disable_percpu_irq(clk->irq);
 }
@@ -106,7 +108,7 @@ static void twd_update_frequency(void *new_rate)
 {
 	twd_timer_rate = *((unsigned long *) new_rate);
 
-	clockevents_update_freq(*__this_cpu_ptr(twd_evt), twd_timer_rate);
+	clockevents_update_freq(__this_cpu_ptr(twd_evt), twd_timer_rate);
 }
 
 static int twd_rate_change(struct notifier_block *nb,
@@ -132,7 +134,7 @@ static struct notifier_block twd_clk_nb = {
 
 static int twd_clk_init(void)
 {
-	if (twd_evt && *__this_cpu_ptr(twd_evt) && !IS_ERR(twd_clk))
+	if (twd_evt && __this_cpu_ptr(twd_evt) && !IS_ERR(twd_clk))
 		return clk_notifier_register(twd_clk, &twd_clk_nb);
 
 	return 0;
@@ -151,7 +153,7 @@ static void twd_update_frequency(void *data)
 {
 	twd_timer_rate = clk_get_rate(twd_clk);
 
-	clockevents_update_freq(*__this_cpu_ptr(twd_evt), twd_timer_rate);
+	clockevents_update_freq(__this_cpu_ptr(twd_evt), twd_timer_rate);
 }
 
 static int twd_cpufreq_transition(struct notifier_block *nb,
@@ -177,7 +179,7 @@ static struct notifier_block twd_cpufreq_nb = {
 
 static int twd_cpufreq_init(void)
 {
-	if (twd_evt && *__this_cpu_ptr(twd_evt) && !IS_ERR(twd_clk))
+	if (twd_evt && __this_cpu_ptr(twd_evt) && !IS_ERR(twd_clk))
 		return cpufreq_register_notifier(&twd_cpufreq_nb,
 			CPUFREQ_TRANSITION_NOTIFIER);
 
@@ -228,7 +230,7 @@ static void __cpuinit twd_calibrate_rate(void)
 
 static irqreturn_t twd_handler(int irq, void *dev_id)
 {
-	struct clock_event_device *evt = *(struct clock_event_device **)dev_id;
+	struct clock_event_device *evt = dev_id;
 
 	if (twd_timer_ack()) {
 		evt->event_handler(evt);
@@ -265,9 +267,9 @@ static void twd_get_clock(struct device_node *np)
 /*
  * Setup the local clock events for a CPU.
  */
-static int __cpuinit twd_timer_setup(struct clock_event_device *clk)
+static void __cpuinit twd_timer_setup(void)
 {
-	struct clock_event_device **this_cpu_clk;
+	struct clock_event_device *clk = __this_cpu_ptr(twd_evt);
 	int cpu = smp_processor_id();
 
 	/*
@@ -276,9 +278,9 @@ static int __cpuinit twd_timer_setup(struct clock_event_device *clk)
 	 */
 	if (per_cpu(percpu_setup_called, cpu)) {
 		__raw_writel(0, twd_base + TWD_TIMER_CONTROL);
-		clockevents_register_device(*__this_cpu_ptr(twd_evt));
+		clockevents_register_device(clk);
 		enable_percpu_irq(clk->irq, 0);
-		return 0;
+		return;
 	}
 	per_cpu(percpu_setup_called, cpu) = true;
 
@@ -297,27 +299,37 @@ static int __cpuinit twd_timer_setup(struct clock_event_device *clk)
 	clk->set_mode = twd_set_mode;
 	clk->set_next_event = twd_set_next_event;
 	clk->irq = twd_ppi;
-
-	this_cpu_clk = __this_cpu_ptr(twd_evt);
-	*this_cpu_clk = clk;
+	clk->cpumask = cpumask_of(cpu);
 
 	clockevents_config_and_register(clk, twd_timer_rate,
 					0xf, 0xffffffff);
 	enable_percpu_irq(clk->irq, 0);
+}
 
-	return 0;
+static int __cpuinit twd_timer_cpu_notify(struct notifier_block *self,
+					   unsigned long action, void *hcpu)
+{
+	switch (action & ~CPU_TASKS_FROZEN) {
+	case CPU_STARTING:
+		twd_timer_setup();
+		break;
+	case CPU_DYING:
+		twd_timer_stop();
+		break;
+	}
+
+	return NOTIFY_OK;
 }
 
-static struct local_timer_ops twd_lt_ops __cpuinitdata = {
-	.setup	= twd_timer_setup,
-	.stop	= twd_timer_stop,
+static struct notifier_block twd_timer_cpu_nb __cpuinitdata = {
+	.notifier_call = twd_timer_cpu_notify,
 };
 
 static int __init twd_local_timer_common_register(struct device_node *np)
 {
 	int err;
 
-	twd_evt = alloc_percpu(struct clock_event_device *);
+	twd_evt = alloc_percpu(struct clock_event_device);
 	if (!twd_evt) {
 		err = -ENOMEM;
 		goto out_free;
@@ -329,12 +341,22 @@ static int __init twd_local_timer_common_register(struct device_node *np)
 		goto out_free;
 	}
 
-	err = local_timer_register(&twd_lt_ops);
+	err = register_cpu_notifier(&twd_timer_cpu_nb);
 	if (err)
 		goto out_irq;
 
 	twd_get_clock(np);
 
+	/*
+	 * Immediately configure the timer on the boot CPU, unless we need
+	 * jiffies to be incrementing to calibrate the rate in which case
+	 * setup the timer in late_time_init.
+	 */
+	if (twd_timer_rate)
+		twd_timer_setup();
+	else
+		late_time_init = twd_timer_setup;
+
 	return 0;
 
 out_irq:
diff --git a/arch/arm/mach-highbank/Kconfig b/arch/arm/mach-highbank/Kconfig
index cd9fcb1..6acbdab 100644
--- a/arch/arm/mach-highbank/Kconfig
+++ b/arch/arm/mach-highbank/Kconfig
@@ -12,7 +12,7 @@ config ARCH_HIGHBANK
 	select CPU_V7
 	select GENERIC_CLOCKEVENTS
 	select HAVE_ARM_SCU
-	select HAVE_ARM_TWD if LOCAL_TIMERS
+	select HAVE_ARM_TWD if SMP
 	select HAVE_SMP
 	select MAILBOX
 	select PL320_MBOX
diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index 78f795d..bd5a922 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -801,7 +801,7 @@ config SOC_IMX6Q
 	select COMMON_CLK
 	select CPU_V7
 	select HAVE_ARM_SCU if SMP
-	select HAVE_ARM_TWD if LOCAL_TIMERS
+	select HAVE_ARM_TWD if SMP
 	select HAVE_CAN_FLEXCAN if CAN
 	select HAVE_IMX_ANATOP
 	select HAVE_IMX_GPC
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 9ef5e9e..568bb74 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -89,7 +89,7 @@ config ARCH_OMAP4
 	select CACHE_L2X0
 	select CPU_V7
 	select HAVE_ARM_SCU if SMP
-	select HAVE_ARM_TWD if LOCAL_TIMERS
+	select HAVE_ARM_TWD if SMP
 	select HAVE_SMP
 	select LOCAL_TIMERS if SMP
 	select OMAP_INTERCONNECT
diff --git a/arch/arm/mach-realview/Kconfig b/arch/arm/mach-realview/Kconfig
index d210c0f9..9db2029 100644
--- a/arch/arm/mach-realview/Kconfig
+++ b/arch/arm/mach-realview/Kconfig
@@ -13,7 +13,7 @@ config REALVIEW_EB_A9MP
 	depends on MACH_REALVIEW_EB
 	select CPU_V7
 	select HAVE_ARM_SCU if SMP
-	select HAVE_ARM_TWD if LOCAL_TIMERS
+	select HAVE_ARM_TWD if SMP
 	select HAVE_SMP
 	select MIGHT_HAVE_CACHE_L2X0
 	help
@@ -26,7 +26,7 @@ config REALVIEW_EB_ARM11MP
 	select ARCH_HAS_BARRIERS if SMP
 	select CPU_V6K
 	select HAVE_ARM_SCU if SMP
-	select HAVE_ARM_TWD if LOCAL_TIMERS
+	select HAVE_ARM_TWD if SMP
 	select HAVE_SMP
 	select MIGHT_HAVE_CACHE_L2X0
 	help
@@ -48,7 +48,7 @@ config MACH_REALVIEW_PB11MP
 	select ARM_GIC
 	select CPU_V6K
 	select HAVE_ARM_SCU if SMP
-	select HAVE_ARM_TWD if LOCAL_TIMERS
+	select HAVE_ARM_TWD if SMP
 	select HAVE_PATA_PLATFORM
 	select HAVE_SMP
 	select MIGHT_HAVE_CACHE_L2X0
@@ -92,7 +92,7 @@ config MACH_REALVIEW_PBX
 	select ARCH_SPARSEMEM_ENABLE if CPU_V7 && !REALVIEW_HIGH_PHYS_OFFSET
 	select ARM_GIC
 	select HAVE_ARM_SCU if SMP
-	select HAVE_ARM_TWD if LOCAL_TIMERS
+	select HAVE_ARM_TWD if SMP
 	select HAVE_PATA_PLATFORM
 	select HAVE_SMP
 	select MIGHT_HAVE_CACHE_L2X0
diff --git a/arch/arm/mach-spear/Kconfig b/arch/arm/mach-spear/Kconfig
index 442917e..df0d59a 100644
--- a/arch/arm/mach-spear/Kconfig
+++ b/arch/arm/mach-spear/Kconfig
@@ -23,7 +23,7 @@ config ARCH_SPEAR13XX
 	select CPU_V7
 	select GPIO_SPEAR_SPICS
 	select HAVE_ARM_SCU if SMP
-	select HAVE_ARM_TWD if LOCAL_TIMERS
+	select HAVE_ARM_TWD if SMP
 	select HAVE_SMP
 	select MIGHT_HAVE_CACHE_L2X0
 	select PINCTRL
diff --git a/arch/arm/mach-tegra/Kconfig b/arch/arm/mach-tegra/Kconfig
index 20c3b37..686d6b5 100644
--- a/arch/arm/mach-tegra/Kconfig
+++ b/arch/arm/mach-tegra/Kconfig
@@ -8,7 +8,7 @@ config ARCH_TEGRA
 	select COMMON_CLK
 	select GENERIC_CLOCKEVENTS
 	select HAVE_ARM_SCU if SMP
-	select HAVE_ARM_TWD if LOCAL_TIMERS
+	select HAVE_ARM_TWD if SMP
 	select HAVE_CLK
 	select HAVE_SMP
 	select MIGHT_HAVE_CACHE_L2X0
diff --git a/arch/arm/mach-ux500/Kconfig b/arch/arm/mach-ux500/Kconfig
index f66d7de..ed33ec1 100644
--- a/arch/arm/mach-ux500/Kconfig
+++ b/arch/arm/mach-ux500/Kconfig
@@ -8,7 +8,7 @@ config ARCH_U8500
 	select CPU_V7
 	select GENERIC_CLOCKEVENTS
 	select HAVE_ARM_SCU if SMP
-	select HAVE_ARM_TWD if LOCAL_TIMERS
+	select HAVE_ARM_TWD if SMP
 	select HAVE_SMP
 	select MIGHT_HAVE_CACHE_L2X0
 	help
diff --git a/arch/arm/mach-vexpress/Kconfig b/arch/arm/mach-vexpress/Kconfig
index 5907e10..5bfdd73 100644
--- a/arch/arm/mach-vexpress/Kconfig
+++ b/arch/arm/mach-vexpress/Kconfig
@@ -10,7 +10,7 @@ config ARCH_VEXPRESS
 	select CPU_V7
 	select GENERIC_CLOCKEVENTS
 	select HAVE_ARM_SCU if SMP
-	select HAVE_ARM_TWD if LOCAL_TIMERS
+	select HAVE_ARM_TWD if SMP
 	select HAVE_CLK
 	select HAVE_PATA_PLATFORM
 	select HAVE_SMP
diff --git a/arch/arm/mach-zynq/Kconfig b/arch/arm/mach-zynq/Kconfig
index c1d61f2..04f8a4a 100644
--- a/arch/arm/mach-zynq/Kconfig
+++ b/arch/arm/mach-zynq/Kconfig
@@ -6,7 +6,7 @@ config ARCH_ZYNQ
 	select CPU_V7
 	select GENERIC_CLOCKEVENTS
 	select HAVE_ARM_SCU if SMP
-	select HAVE_ARM_TWD if LOCAL_TIMERS
+	select HAVE_ARM_TWD if SMP
 	select ICST
 	select MIGHT_HAVE_CACHE_L2X0
 	select USE_OF
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Fri Apr 19 12:19:45 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Fri, 19 Apr 2013 09:19:45 -0700
Subject: [PATCHv5 11/11] ARM: smp: Remove local timer API
In-Reply-To: <1366388385-30722-1-git-send-email-sboyd@codeaurora.org>
References: <1366388385-30722-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1366388385-30722-12-git-send-email-sboyd@codeaurora.org>

There are no more users of this API, remove it.

Cc: Russell King <linux at arm.linux.org.uk>
Acked-by: Tony Lindgren <tony at atomide.com>
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 arch/arm/Kconfig                  | 10 ------
 arch/arm/include/asm/localtimer.h | 34 -------------------
 arch/arm/kernel/smp.c             | 69 ---------------------------------------
 3 files changed, 113 deletions(-)
 delete mode 100644 arch/arm/include/asm/localtimer.h

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 14c0a3d..96dc967 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1533,16 +1533,6 @@ config ARM_PSCI
 	  0022A ("Power State Coordination Interface System Software on
 	  ARM processors").
 
-config LOCAL_TIMERS
-	bool "Use local timer interrupts"
-	depends on SMP
-	default y
-	help
-	  Enable support for local timers on SMP platforms, rather then the
-	  legacy IPI broadcast method.  Local timers allows the system
-	  accounting to be spread across the timer interval, preventing a
-	  "thundering herd" at every timer tick.
-
 # The GPIO number here must be sorted by descending number. In case of
 # a multiplatform kernel, we just want the highest value required by the
 # selected platforms.
diff --git a/arch/arm/include/asm/localtimer.h b/arch/arm/include/asm/localtimer.h
deleted file mode 100644
index f77ffc1..0000000
--- a/arch/arm/include/asm/localtimer.h
+++ /dev/null
@@ -1,34 +0,0 @@
-/*
- *  arch/arm/include/asm/localtimer.h
- *
- *  Copyright (C) 2004-2005 ARM Ltd.
- *
- * 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.
- */
-#ifndef __ASM_ARM_LOCALTIMER_H
-#define __ASM_ARM_LOCALTIMER_H
-
-#include <linux/errno.h>
-
-struct clock_event_device;
-
-struct local_timer_ops {
-	int  (*setup)(struct clock_event_device *);
-	void (*stop)(struct clock_event_device *);
-};
-
-#ifdef CONFIG_LOCAL_TIMERS
-/*
- * Register a local timer driver
- */
-int local_timer_register(struct local_timer_ops *);
-#else
-static inline int local_timer_register(struct local_timer_ops *ops)
-{
-	return -ENXIO;
-}
-#endif
-
-#endif
diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
index 806b84d..6e653f5 100644
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -41,7 +41,6 @@
 #include <asm/sections.h>
 #include <asm/tlbflush.h>
 #include <asm/ptrace.h>
-#include <asm/localtimer.h>
 #include <asm/smp_plat.h>
 #include <asm/virt.h>
 #include <asm/mach/arch.h>
@@ -133,8 +132,6 @@ int __cpuinit boot_secondary(unsigned int cpu, struct task_struct *idle)
 }
 
 #ifdef CONFIG_HOTPLUG_CPU
-static void percpu_timer_stop(void);
-
 static int platform_cpu_kill(unsigned int cpu)
 {
 	if (smp_ops.cpu_kill)
@@ -178,11 +175,6 @@ int __cpuinit __cpu_disable(void)
 	migrate_irqs();
 
 	/*
-	 * Stop the local timer for this CPU.
-	 */
-	percpu_timer_stop();
-
-	/*
 	 * Flush user cache and TLB mappings, and then remove this CPU
 	 * from the vm mask set of all processes.
 	 *
@@ -269,8 +261,6 @@ static void __cpuinit smp_store_cpu_info(unsigned int cpuid)
 	store_cpu_topology(cpuid);
 }
 
-static void percpu_timer_setup(void);
-
 /*
  * This is the secondary CPU boot entry.  We're using this CPUs
  * idle thread stack, but a set of temporary page tables.
@@ -325,11 +315,6 @@ asmlinkage void __cpuinit secondary_start_kernel(void)
 	set_cpu_online(cpu, true);
 	complete(&cpu_running);
 
-	/*
-	 * Setup the percpu timer for this CPU.
-	 */
-	percpu_timer_setup();
-
 	local_irq_enable();
 	local_fiq_enable();
 
@@ -376,12 +361,6 @@ void __init smp_prepare_cpus(unsigned int max_cpus)
 		max_cpus = ncores;
 	if (ncores > 1 && max_cpus) {
 		/*
-		 * Enable the local timer or broadcast device for the
-		 * boot CPU, but only if we have more than one CPU.
-		 */
-		percpu_timer_setup();
-
-		/*
 		 * Initialise the present map, which describes the set of CPUs
 		 * actually populated at the present time. A platform should
 		 * re-initialize the map in the platforms smp_prepare_cpus()
@@ -457,11 +436,6 @@ u64 smp_irq_stat_cpu(unsigned int cpu)
 	return sum;
 }
 
-/*
- * Timer (local or broadcast) support
- */
-static DEFINE_PER_CPU(struct clock_event_device, percpu_clockevent);
-
 #ifdef CONFIG_GENERIC_CLOCKEVENTS_BROADCAST
 void tick_broadcast(const struct cpumask *mask)
 {
@@ -469,49 +443,6 @@ void tick_broadcast(const struct cpumask *mask)
 }
 #endif
 
-static struct local_timer_ops *lt_ops;
-
-#ifdef CONFIG_LOCAL_TIMERS
-int local_timer_register(struct local_timer_ops *ops)
-{
-	if (!is_smp() || !setup_max_cpus)
-		return -ENXIO;
-
-	if (lt_ops)
-		return -EBUSY;
-
-	lt_ops = ops;
-	return 0;
-}
-#endif
-
-static void __cpuinit percpu_timer_setup(void)
-{
-	unsigned int cpu = smp_processor_id();
-	struct clock_event_device *evt = &per_cpu(percpu_clockevent, cpu);
-
-	evt->cpumask = cpumask_of(cpu);
-
-	if (lt_ops)
-		lt_ops->setup(evt);
-}
-
-#ifdef CONFIG_HOTPLUG_CPU
-/*
- * The generic clock events code purposely does not stop the local timer
- * on CPU_DEAD/CPU_DEAD_FROZEN hotplug events, so we have to do it
- * manually here.
- */
-static void percpu_timer_stop(void)
-{
-	unsigned int cpu = smp_processor_id();
-	struct clock_event_device *evt = &per_cpu(percpu_clockevent, cpu);
-
-	if (lt_ops)
-		lt_ops->stop(evt);
-}
-#endif
-
 static DEFINE_RAW_SPINLOCK(stop_lock);
 
 /*
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From catalin.marinas at arm.com  Fri Apr 19 12:22:26 2013
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Fri, 19 Apr 2013 17:22:26 +0100
Subject: [RFC] arm64: Early printk support for virtio-mmio console devices.
In-Reply-To: <CAFEAcA-F18kR4JihdxaLTm3qb4n51tsygG1RW4djwJ0u9+FQqw@mail.gmail.com>
References: <CAAHg+HhtCorArCmx=ha0=64+SJZiizzrDUKSPLV=N+OzO8zAxQ@mail.gmail.com>
 <20130419090558.GA13283@mudshark.cambridge.arm.com>
 <CAAHg+HipCX2ma6brxj9Kgc3ew39b5e30grLwyun9CViif-5wZQ@mail.gmail.com>
 <20130419092752.GB13283@mudshark.cambridge.arm.com>
 <CAFEAcA8j124G=vaHObJ_w5wOhUiS3KYKbjMnigbnr6mgwFxZUg@mail.gmail.com>
 <CAAHg+Hg=t97SJ0JPZYgrZaL+zimo-wbezwaj1BQvHqE-vf4VDA@mail.gmail.com>
 <20130419093953.GD13283@mudshark.cambridge.arm.com>
 <CAFEAcA_WfYpyvq54rZqS8JZkmDF5JXB+CNHFH5CnrhKun52uzA@mail.gmail.com>
 <20130419161201.GA5383@localhost.cambridge.arm.com>
 <CAFEAcA-F18kR4JihdxaLTm3qb4n51tsygG1RW4djwJ0u9+FQqw@mail.gmail.com>
Message-ID: <20130419162226.GB5383@localhost.cambridge.arm.com>

On Fri, Apr 19, 2013 at 05:14:36PM +0100, Peter Maydell wrote:
> On 19 April 2013 17:12, Catalin Marinas <catalin.marinas at arm.com> wrote:
> > On Fri, Apr 19, 2013 at 11:05:47AM +0100, Peter Maydell wrote:
> >> Please make the kernel pick the device out of the device tree
> >> blob. The whole point of device tree is that it's how to tell
> >> the kernel where things live -- making kvmtool/QEMU and/or the
> >> user also have to mess with the kernel command line is awkward
> >> and annoying.
> >
> > For a normal console device, it indeed needs to get it from the DT. For
> > early console, you want it earlier than DT parsing so we pass it on the
> > kernel command line via the earlyprintk= parameter.
> 
> You should fix your DT handling code so you can get at the info
> when you need it rather than pushing the problem into bootloaders
> and QEMU, please. DT is your data structure so feel free to
> (re)design it so relevant information can be accessed early
> if that's useful.

earlyprintk is used for debugging early problems, like DT parsing. You
don't have to use it unless you are debugging something. Without
earlyprintk you just get a normal console during boot, based on the DT
description.

-- 
Catalin


From linux at arm.linux.org.uk  Fri Apr 19 12:27:02 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Fri, 19 Apr 2013 17:27:02 +0100
Subject: [PATCH v2 3/3] ARM: arch_timer: use full 64-bit counter for
 sched_clock
In-Reply-To: <1364849914-26420-4-git-send-email-robherring2@gmail.com>
References: <1364849914-26420-1-git-send-email-robherring2@gmail.com>
 <1364849914-26420-4-git-send-email-robherring2@gmail.com>
Message-ID: <20130419162702.GW14496@n2100.arm.linux.org.uk>

On Mon, Apr 01, 2013 at 03:58:34PM -0500, Rob Herring wrote:
> From: Rob Herring <rob.herring at calxeda.com>
> 
> Only 32-bits of the arch timer were being used and wrapping was needlessly
> being done in s/w. By using the full counter (56-64 bits), we don't need
> to deal with wrapping and can simplify the implementation when using
> arch timer.

Remember that you _must_ provide the full 64-bit nsec value to the
scheduler.  A 56-bit value will not do, it has to be the full 64-bits
of nsecs.  So:

> +static unsigned long long notrace arch_timer_sched_clock(void)
>  {
> -	return arch_timer_read_counter();
> +	return arch_timer_read_counter() * sched_clock_mult;
...
> +	/* Cache the sched_clock multiplier to save a divide in the hot path. */
> +	sched_clock_mult = NSEC_PER_SEC / arch_timer_rate;

If the counter is 56-bit and the multiplier is not larger than 255,
then you have a potential problem here.  That basically translates
into a clock rate of no more than 3.9MHz for the architected timer
if it is 56-bit.


From chf.fritz at googlemail.com  Fri Apr 19 12:29:41 2013
From: chf.fritz at googlemail.com (Christoph Fritz)
Date: Fri, 19 Apr 2013 18:29:41 +0200
Subject: [PATCH] ARM: OMAP2+: nand: reorganize gpmc timing values
In-Reply-To: <5171647B.9070108@ti.com>
References: <1366311829.4085.90.camel@mars>  <51704C05.4030200@ti.com>
 <1366316595.4085.113.camel@mars>  <5170738F.8050305@ti.com>
 <1366325282.4232.6.camel@lovely> <51708097.6070102@ti.com>
 <51708131.2040208@ti.com>  <1366362081.3928.18.camel@mars>
 <1366372957.3928.104.camel@mars>  <51714E0D.7020304@ti.com>
 <1366383208.3928.144.camel@mars>  <5171647B.9070108@ti.com>
Message-ID: <1366388981.3928.158.camel@mars>

This patch removes omap2_nand_gpmc_retime() which was used to quirk
some timing values before gpmc_cs_set_timings(). Due to recent changes,
gpmc_cs_set_timings() has evolved so that there is no more need for a
retime function.

To keep the gpmc configuration consistent for legacy board files, this
patch also adds oe_on and we_on to nand_default_timings[] as they
would be by the retime function.

Signed-off-by: Christoph Fritz <chf.fritz at googlemail.com>
---
 arch/arm/mach-omap2/board-flash.c |    3 +++
 arch/arm/mach-omap2/gpmc-nand.c   |   40 +------------------------------------
 2 files changed, 4 insertions(+), 39 deletions(-)

diff --git a/arch/arm/mach-omap2/board-flash.c b/arch/arm/mach-omap2/board-flash.c
index c33adea..fc20a61 100644
--- a/arch/arm/mach-omap2/board-flash.c
+++ b/arch/arm/mach-omap2/board-flash.c
@@ -112,6 +112,9 @@ struct gpmc_timings nand_default_timings[1] = {
 		.cs_rd_off = 36,
 		.cs_wr_off = 36,
 
+		.we_on = 6,
+		.oe_on = 6,
+
 		.adv_on = 6,
 		.adv_rd_off = 24,
 		.adv_wr_off = 36,
diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
index d9c2719..c8044b0 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -43,44 +43,6 @@ static struct platform_device gpmc_nand_device = {
 	.resource	= gpmc_nand_resource,
 };
 
-static int omap2_nand_gpmc_retime(
-				struct omap_nand_platform_data *gpmc_nand_data,
-				struct gpmc_timings *gpmc_t)
-{
-	struct gpmc_timings t;
-	int err;
-
-	memset(&t, 0, sizeof(t));
-	t.sync_clk = gpmc_t->sync_clk;
-	t.cs_on = gpmc_t->cs_on;
-	t.adv_on = gpmc_t->adv_on;
-
-	/* Read */
-	t.adv_rd_off = gpmc_t->adv_rd_off;
-	t.oe_on  = t.adv_on;
-	t.access = gpmc_t->access;
-	t.oe_off = gpmc_t->oe_off;
-	t.cs_rd_off = gpmc_t->cs_rd_off;
-	t.rd_cycle = gpmc_t->rd_cycle;
-
-	/* Write */
-	t.adv_wr_off = gpmc_t->adv_wr_off;
-	t.we_on  = t.oe_on;
-	if (cpu_is_omap34xx()) {
-		t.wr_data_mux_bus = gpmc_t->wr_data_mux_bus;
-		t.wr_access = gpmc_t->wr_access;
-	}
-	t.we_off = gpmc_t->we_off;
-	t.cs_wr_off = gpmc_t->cs_wr_off;
-	t.wr_cycle = gpmc_t->wr_cycle;
-
-	err = gpmc_cs_set_timings(gpmc_nand_data->cs, &t);
-	if (err)
-		return err;
-
-	return 0;
-}
-
 static bool gpmc_hwecc_bch_capable(enum omap_ecc ecc_opt)
 {
 	/* support only OMAP3 class */
@@ -131,7 +93,7 @@ int gpmc_nand_init(struct omap_nand_platform_data *gpmc_nand_data,
 				gpmc_get_client_irq(GPMC_IRQ_COUNT_EVENT);
 
 	if (gpmc_t) {
-		err = omap2_nand_gpmc_retime(gpmc_nand_data, gpmc_t);
+		err = gpmc_cs_set_timings(gpmc_nand_data->cs, gpmc_t);
 		if (err < 0) {
 			dev_err(dev, "Unable to set gpmc timings: %d\n", err);
 			return err;
-- 
1.7.10.4





From james.hogan at imgtec.com  Fri Apr 19 12:28:24 2013
From: james.hogan at imgtec.com (James Hogan)
Date: Fri, 19 Apr 2013 17:28:24 +0100
Subject: [PATCH v2 3/3] clk: clk-mux: implement remuxing on set_rate
In-Reply-To: <1366388904-13903-1-git-send-email-james.hogan@imgtec.com>
References: <1366388904-13903-1-git-send-email-james.hogan@imgtec.com>
Message-ID: <1366388904-13903-4-git-send-email-james.hogan@imgtec.com>

Add a new clock flag called CLK_SET_RATE_REMUX to indicate that the
clock can have it's parent changed automatically in response to a
set_rate.

Implement clk-mux remuxing if the CLK_SET_RATE_REMUX flag is set. This
implements determine_rate for clk-mux to propagate to each parent and to
choose the best one (like clk-divider this chooses the parent which
provides the fastest rate <= the requested rate).

The determine_rate op is implemented as a core helper function so that
it can be easily used by more complex clocks which incorporate muxes.

Signed-off-by: James Hogan <james.hogan at imgtec.com>
---
 drivers/clk/clk-mux.c        |  1 +
 drivers/clk/clk.c            | 49 ++++++++++++++++++++++++++++++++++++++++++++
 include/linux/clk-provider.h |  4 ++++
 3 files changed, 54 insertions(+)

diff --git a/drivers/clk/clk-mux.c b/drivers/clk/clk-mux.c
index 508c032..3a42b96 100644
--- a/drivers/clk/clk-mux.c
+++ b/drivers/clk/clk-mux.c
@@ -85,6 +85,7 @@ static int clk_mux_set_parent(struct clk_hw *hw, u8 index)
 const struct clk_ops clk_mux_ops = {
 	.get_parent = clk_mux_get_parent,
 	.set_parent = clk_mux_set_parent,
+	.determine_rate = __clk_mux_determine_rate,
 };
 EXPORT_SYMBOL_GPL(clk_mux_ops);
 
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index cc0e618..8c4b714 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -529,6 +529,55 @@ struct clk *__clk_lookup(const char *name)
 	return NULL;
 }
 
+/*
+ * Helper for finding best parent to provide a given frequency. This can be used
+ * directly as a determine_rate callback (e.g. for a mux), or from a more
+ * complex clock that may combine a mux with other operations.
+ */
+long __clk_mux_determine_rate(struct clk_hw *hw, unsigned long rate,
+			      unsigned long *best_parent_rate,
+			      struct clk **best_parent_p)
+{
+	struct clk *clk = hw->clk, *parent, *best_parent = NULL;
+	int i, num_parents;
+	unsigned long parent_rate, best = 0;
+
+	/* if remux flag not set, pass through to current parent */
+	if (!(clk->flags & CLK_SET_RATE_REMUX)) {
+		parent = clk->parent;
+		if (clk->flags & CLK_SET_RATE_PARENT)
+			best = __clk_round_rate(parent, rate);
+		else if (parent)
+			best = __clk_get_rate(parent);
+		else
+			best = __clk_get_rate(clk);
+		goto out;
+	}
+
+	/* find the parent that can provide the fastest rate <= rate */
+	num_parents = clk->num_parents;
+	for (i = 0; i < num_parents; i++) {
+		parent = __clk_get_parent_by_index(clk, i);
+		if (!parent)
+			continue;
+		if (clk->flags & CLK_SET_RATE_PARENT)
+			parent_rate = __clk_round_rate(parent, rate);
+		else
+			parent_rate = __clk_get_rate(parent);
+		if (parent_rate <= rate && parent_rate > best) {
+			best_parent = parent;
+			best = parent_rate;
+		}
+	}
+
+out:
+	if (best_parent_p && best_parent)
+		*best_parent_p = best_parent;
+	*best_parent_rate = best;
+
+	return best;
+}
+
 /***        clk api        ***/
 
 void __clk_unprepare(struct clk *clk)
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 5fe1d38..0eb4532 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -27,6 +27,7 @@
 #define CLK_IS_ROOT		BIT(4) /* root clk, has no parent */
 #define CLK_IS_BASIC		BIT(5) /* Basic clk, can't do a to_clk_foo() */
 #define CLK_GET_RATE_NOCACHE	BIT(6) /* do not use the cached clk rate */
+#define CLK_SET_RATE_REMUX	BIT(7) /* find best parent for rate change */
 
 struct clk_hw;
 
@@ -361,6 +362,9 @@ unsigned long __clk_get_rate(struct clk *clk);
 unsigned long __clk_get_flags(struct clk *clk);
 bool __clk_is_enabled(struct clk *clk);
 struct clk *__clk_lookup(const char *name);
+long __clk_mux_determine_rate(struct clk_hw *hw, unsigned long rate,
+			      unsigned long *best_parent_rate,
+			      struct clk **best_parent_p);
 
 /*
  * FIXME clock api without lock protection
-- 
1.8.1.2




From james.hogan at imgtec.com  Fri Apr 19 12:28:22 2013
From: james.hogan at imgtec.com (James Hogan)
Date: Fri, 19 Apr 2013 17:28:22 +0100
Subject: [PATCH v2 1/3] clk: abstract parent cache
In-Reply-To: <1366388904-13903-1-git-send-email-james.hogan@imgtec.com>
References: <1366388904-13903-1-git-send-email-james.hogan@imgtec.com>
Message-ID: <1366388904-13903-2-git-send-email-james.hogan@imgtec.com>

Abstract access to the clock parent cache by defining
__clk_get_parent_by_index(clk, index). This allows access to parent
clocks from clock drivers.

Signed-off-by: James Hogan <james.hogan at imgtec.com>
---
 drivers/clk/clk.c            | 21 ++++++++++++++-------
 include/linux/clk-provider.h |  1 +
 2 files changed, 15 insertions(+), 7 deletions(-)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index ed87b24..79d5deb 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -415,6 +415,19 @@ struct clk *__clk_get_parent(struct clk *clk)
 	return !clk ? NULL : clk->parent;
 }
 
+struct clk *__clk_get_parent_by_index(struct clk *clk, u8 index)
+{
+	if (!clk || index >= clk->num_parents)
+		return NULL;
+	else if (!clk->parents)
+		return __clk_lookup(clk->parent_names[index]);
+	else if (!clk->parents[index])
+		return clk->parents[index] =
+			__clk_lookup(clk->parent_names[index]);
+	else
+		return clk->parents[index];
+}
+
 unsigned int __clk_get_enable_count(struct clk *clk)
 {
 	return !clk ? 0 : clk->enable_count;
@@ -1150,13 +1163,7 @@ static struct clk *__clk_init_parent(struct clk *clk)
 			kzalloc((sizeof(struct clk*) * clk->num_parents),
 					GFP_KERNEL);
 
-	if (!clk->parents)
-		ret = __clk_lookup(clk->parent_names[index]);
-	else if (!clk->parents[index])
-		ret = clk->parents[index] =
-			__clk_lookup(clk->parent_names[index]);
-	else
-		ret = clk->parents[index];
+	ret = __clk_get_parent_by_index(clk, index);
 
 out:
 	return ret;
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 7f197d7..4e0b634 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -347,6 +347,7 @@ const char *__clk_get_name(struct clk *clk);
 struct clk_hw *__clk_get_hw(struct clk *clk);
 u8 __clk_get_num_parents(struct clk *clk);
 struct clk *__clk_get_parent(struct clk *clk);
+struct clk *__clk_get_parent_by_index(struct clk *clk, u8 index);
 unsigned int __clk_get_enable_count(struct clk *clk);
 unsigned int __clk_get_prepare_count(struct clk *clk);
 unsigned long __clk_get_rate(struct clk *clk);
-- 
1.8.1.2




From james.hogan at imgtec.com  Fri Apr 19 12:28:21 2013
From: james.hogan at imgtec.com (James Hogan)
Date: Fri, 19 Apr 2013 17:28:21 +0100
Subject: [PATCH v2 0/3] clk: implement remuxing during set_rate
Message-ID: <1366388904-13903-1-git-send-email-james.hogan@imgtec.com>

This patchset adds support for automatic selection of the best parent
for a clock mux, i.e. the one which can provide the closest clock rate
to that requested. It can be controlled by a new CLK_SET_RATE_REMUX flag
so that it doesn't happen unless explicitly allowed.

This works by way of adding a new op, determine_rate, similar to
round_rate but with an extra parameter to allow the clock driver to
optionally select a different parent clock. This is used in
clk_calc_new_rates to decide whether to initiate a set_parent operation.

Changes in v2:

I've moved the mux determine_rate implementation into a core helper, but
I haven't pushed it fully into the core, as I think it just wouldn't
work correctly for more complex clocks, e.g. if you (theoretically) had
a combined mux and divide, you'd want to intercept the determine_rate
and ask for a larger rate from the parent clocks, then return the
divided rate. This should be possible by wrapping the mux determine_rate
helper.

Patch 1 still exports the __clk_get_parent_by_index as it seems like it
might be a useful thing for clock implementations to have access to if
they ever wanted to do something more fancy with changing clock parents.

I haven't made any attempt to implement the atomic set_parent+set_rate
as I don't have hardware that could take proper advantage of it, but it
shouldn't be too difficult for others to implement if they wanted since
they're fairly close to one another (in clk_change_rate()).

* switched to using new determine_rate op rather than adding an argument
  to round_rate.
* moved mux implementation into a single helper which should be usable
  from more complex clocks which can mux.
* rewrite main implementation so that no changes are made until after
  the PRE notifications have been sent, and in a way that should ensure
  correct notifications without duplicates, and I think should be safe
  in the event of a notification failing.
* various tidy ups and fixes.

James Hogan (3):
  clk: abstract parent cache
  clk: add support for clock reparent on set_rate
  clk: clk-mux: implement remuxing on set_rate

 Documentation/clk.txt        |   4 +
 drivers/clk/clk-mux.c        |   1 +
 drivers/clk/clk.c            | 216 +++++++++++++++++++++++++++++++++----------
 include/linux/clk-private.h  |   2 +
 include/linux/clk-provider.h |  12 +++
 5 files changed, 185 insertions(+), 50 deletions(-)

-- 
1.8.1.2




From james.hogan at imgtec.com  Fri Apr 19 12:28:23 2013
From: james.hogan at imgtec.com (James Hogan)
Date: Fri, 19 Apr 2013 17:28:23 +0100
Subject: [PATCH v2 2/3] clk: add support for clock reparent on set_rate
In-Reply-To: <1366388904-13903-1-git-send-email-james.hogan@imgtec.com>
References: <1366388904-13903-1-git-send-email-james.hogan@imgtec.com>
Message-ID: <1366388904-13903-3-git-send-email-james.hogan@imgtec.com>

Add core support to allow clock implementations to select the best
parent clock when rounding a rate, e.g. the one which can provide the
closest clock rate to that requested. This is by way of adding a new
clock op, determine_rate(), which is like round_rate() but has an extra
parameter to allow the clock implementation to optionally select a
different parent clock. The core then takes care of reparenting the
clock when setting the rate.

The parent change takes place with the help of two new private data
members. struct clk::new_parent specifies a clock's new parent (NULL
indicates no change), and struct clk::new_child specifies a clock's new
child (whose new_parent member points back to it). The purpose of these
are to allow correct walking of the future tree for notifications prior
to actually reparenting any clocks, specifically to skip child clocks
who are being reparented to another clock (they will be notified via the
new parent), and to include any new child clock. These pointers are set
by clk_calc_subtree(), and the new_child pointer gets cleared when a
child is actually reparented to avoid duplicate POST_RATE_CHANGE
notifications.

Each place where round_rate() is called, determine_rate is checked first
and called in preference, passing NULL to the new parent argument if not
needed (e.g. in __clk_round_rate). This restructures a few of the call
sites to simplify the logic into if/else blocks.

A new __clk_set_parent_no_recalc() is created similar to
clk_set_parent() but without calling __clk_recalc_rates(). This is for
clk_change_rate() to use, where rate recalculation and notifications are
already handled.

Signed-off-by: James Hogan <james.hogan at imgtec.com>
---
 Documentation/clk.txt        |   4 ++
 drivers/clk/clk.c            | 146 ++++++++++++++++++++++++++++++-------------
 include/linux/clk-private.h  |   2 +
 include/linux/clk-provider.h |   7 +++
 4 files changed, 116 insertions(+), 43 deletions(-)

diff --git a/Documentation/clk.txt b/Documentation/clk.txt
index 1943fae..502c033 100644
--- a/Documentation/clk.txt
+++ b/Documentation/clk.txt
@@ -70,6 +70,10 @@ the operations defined in clk.h:
 						unsigned long parent_rate);
 		long		(*round_rate)(struct clk_hw *hw, unsigned long,
 						unsigned long *);
+		long		(*determine_rate)(struct clk_hw *hw,
+						unsigned long rate,
+						unsigned long *best_parent_rate,
+						struct clk **best_parent_clk);
 		int		(*set_parent)(struct clk_hw *hw, u8 index);
 		u8		(*get_parent)(struct clk_hw *hw);
 		int		(*set_rate)(struct clk_hw *hw, unsigned long);
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 79d5deb..cc0e618 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -27,6 +27,8 @@ static HLIST_HEAD(clk_root_list);
 static HLIST_HEAD(clk_orphan_list);
 static LIST_HEAD(clk_notifier_list);
 
+static int __clk_set_parent_no_recalc(struct clk *clk, struct clk *parent);
+
 /***        debugfs support        ***/
 
 #ifdef CONFIG_COMMON_CLK_DEBUG
@@ -727,17 +729,20 @@ unsigned long __clk_round_rate(struct clk *clk, unsigned long rate)
 	if (!clk)
 		return 0;
 
-	if (!clk->ops->round_rate) {
-		if (clk->flags & CLK_SET_RATE_PARENT)
-			return __clk_round_rate(clk->parent, rate);
-		else
-			return clk->rate;
-	}
 
 	if (clk->parent)
 		parent_rate = clk->parent->rate;
 
-	return clk->ops->round_rate(clk->hw, rate, &parent_rate);
+	if (clk->ops->determine_rate)
+		return clk->ops->determine_rate(clk->hw, rate, &parent_rate,
+						NULL);
+	else if (clk->ops->round_rate)
+		return clk->ops->round_rate(clk->hw, rate, &parent_rate);
+	else if (clk->flags & CLK_SET_RATE_PARENT)
+		return __clk_round_rate(clk->parent, rate);
+	else
+		return clk->rate;
+
 }
 
 /**
@@ -906,18 +911,23 @@ out:
 	return ret;
 }
 
-static void clk_calc_subtree(struct clk *clk, unsigned long new_rate)
+static void clk_calc_subtree(struct clk *clk, unsigned long new_rate,
+			     struct clk *new_parent)
 {
 	struct clk *child;
 
 	clk->new_rate = new_rate;
+	clk->new_parent = new_parent;
+	clk->new_child = NULL;
+	if (new_parent && new_parent != clk->parent)
+		new_parent->new_child = clk;
 
 	hlist_for_each_entry(child, &clk->children, child_node) {
 		if (child->ops->recalc_rate)
 			child->new_rate = child->ops->recalc_rate(child->hw, new_rate);
 		else
 			child->new_rate = new_rate;
-		clk_calc_subtree(child, child->new_rate);
+		clk_calc_subtree(child, child->new_rate, NULL);
 	}
 }
 
@@ -928,6 +938,7 @@ static void clk_calc_subtree(struct clk *clk, unsigned long new_rate)
 static struct clk *clk_calc_new_rates(struct clk *clk, unsigned long rate)
 {
 	struct clk *top = clk;
+	struct clk *old_parent, *parent;
 	unsigned long best_parent_rate = 0;
 	unsigned long new_rate;
 
@@ -936,42 +947,43 @@ static struct clk *clk_calc_new_rates(struct clk *clk, unsigned long rate)
 		return NULL;
 
 	/* save parent rate, if it exists */
-	if (clk->parent)
-		best_parent_rate = clk->parent->rate;
-
-	/* never propagate up to the parent */
-	if (!(clk->flags & CLK_SET_RATE_PARENT)) {
-		if (!clk->ops->round_rate) {
-			clk->new_rate = clk->rate;
-			return NULL;
-		}
-		new_rate = clk->ops->round_rate(clk->hw, rate, &best_parent_rate);
+	parent = old_parent = clk->parent;
+	if (parent)
+		best_parent_rate = parent->rate;
+
+	/* find the closest rate and parent clk/rate */
+	if (clk->ops->determine_rate) {
+		new_rate = clk->ops->determine_rate(clk->hw, rate,
+						    &best_parent_rate,
+						    &parent);
+	} else if (clk->ops->round_rate) {
+		new_rate = clk->ops->round_rate(clk->hw, rate,
+						&best_parent_rate);
+	} else if (!parent || !(clk->flags & CLK_SET_RATE_PARENT)) {
+		/* pass-through clock without adjustable parent */
+		clk->new_rate = clk->rate;
+		return NULL;
+	} else {
+		/* pass-through clock with adjustable parent */
+		top = clk_calc_new_rates(parent, rate);
+		new_rate = parent->new_rate;
 		goto out;
 	}
 
-	/* need clk->parent from here on out */
-	if (!clk->parent) {
-		pr_debug("%s: %s has NULL parent\n", __func__, clk->name);
+	/* some clocks must be gated to change parent */
+	if (parent != old_parent &&
+	    (clk->flags & CLK_SET_PARENT_GATE) && clk->prepare_count) {
+		pr_debug("%s: %s not gated but wants to reparent\n",
+			 __func__, clk->name);
 		return NULL;
 	}
 
-	if (!clk->ops->round_rate) {
-		top = clk_calc_new_rates(clk->parent, rate);
-		new_rate = clk->parent->new_rate;
-
-		goto out;
-	}
-
-	new_rate = clk->ops->round_rate(clk->hw, rate, &best_parent_rate);
-
-	if (best_parent_rate != clk->parent->rate) {
-		top = clk_calc_new_rates(clk->parent, best_parent_rate);
-
-		goto out;
-	}
+	if ((clk->flags & CLK_SET_RATE_PARENT) && parent &&
+	    best_parent_rate != parent->rate)
+		top = clk_calc_new_rates(parent, best_parent_rate);
 
 out:
-	clk_calc_subtree(clk, new_rate);
+	clk_calc_subtree(clk, new_rate, parent);
 
 	return top;
 }
@@ -983,7 +995,7 @@ out:
  */
 static struct clk *clk_propagate_rate_change(struct clk *clk, unsigned long event)
 {
-	struct clk *child, *fail_clk = NULL;
+	struct clk *child, *tmp_clk, *fail_clk = NULL;
 	int ret = NOTIFY_DONE;
 
 	if (clk->rate == clk->new_rate)
@@ -996,9 +1008,19 @@ static struct clk *clk_propagate_rate_change(struct clk *clk, unsigned long even
 	}
 
 	hlist_for_each_entry(child, &clk->children, child_node) {
-		clk = clk_propagate_rate_change(child, event);
-		if (clk)
-			fail_clk = clk;
+		/* Skip children who will be reparented to another clock */
+		if (child->new_parent && child->new_parent != clk)
+			continue;
+		tmp_clk = clk_propagate_rate_change(child, event);
+		if (tmp_clk)
+			fail_clk = tmp_clk;
+	}
+
+	/* handle the new child who might not be in clk->children yet */
+	if (clk->new_child) {
+		tmp_clk = clk_propagate_rate_change(clk->new_child, event);
+		if (tmp_clk)
+			fail_clk = tmp_clk;
 	}
 
 	return fail_clk;
@@ -1016,6 +1038,10 @@ static void clk_change_rate(struct clk *clk)
 
 	old_rate = clk->rate;
 
+	/* set parent */
+	if (clk->new_parent && clk->new_parent != clk->parent)
+		__clk_set_parent_no_recalc(clk, clk->new_parent);
+
 	if (clk->parent)
 		best_parent_rate = clk->parent->rate;
 
@@ -1030,8 +1056,15 @@ static void clk_change_rate(struct clk *clk)
 	if (clk->notifier_count && old_rate != clk->rate)
 		__clk_notify(clk, POST_RATE_CHANGE, old_rate, clk->rate);
 
-	hlist_for_each_entry(child, &clk->children, child_node)
+	hlist_for_each_entry(child, &clk->children, child_node) {
+		/* Skip children who will be reparented to another clock */
+		if (child->new_parent && child->new_parent != clk)
+			continue;
 		clk_change_rate(child);
+	}
+
+	if (clk->new_child)
+		clk_change_rate(clk->new_child);
 }
 
 /**
@@ -1169,7 +1202,7 @@ out:
 	return ret;
 }
 
-void __clk_reparent(struct clk *clk, struct clk *new_parent)
+void __clk_reparent_no_recalc(struct clk *clk, struct clk *new_parent)
 {
 #ifdef CONFIG_COMMON_CLK_DEBUG
 	struct dentry *d;
@@ -1179,6 +1212,9 @@ void __clk_reparent(struct clk *clk, struct clk *new_parent)
 	if (!clk || !new_parent)
 		return;
 
+	if (new_parent->new_child == clk)
+		new_parent->new_child = NULL;
+
 	hlist_del(&clk->child_node);
 
 	if (new_parent)
@@ -1206,6 +1242,11 @@ out:
 #endif
 
 	clk->parent = new_parent;
+}
+
+void __clk_reparent(struct clk *clk, struct clk *new_parent)
+{
+	__clk_reparent_no_recalc(clk, new_parent);
 
 	__clk_recalc_rates(clk, POST_RATE_CHANGE);
 }
@@ -1270,6 +1311,25 @@ out:
 	return ret;
 }
 
+static int __clk_set_parent_no_recalc(struct clk *clk, struct clk *parent)
+{
+	int ret = 0;
+
+	if (clk->parent == parent)
+		goto out;
+
+	/* only re-parent if the clock is not in use */
+	ret = __clk_set_parent(clk, parent);
+	if (ret)
+		goto out;
+
+	/* reparent, but don't propagate rate recalculation downstream */
+	__clk_reparent_no_recalc(clk, parent);
+
+out:
+	return ret;
+}
+
 /**
  * clk_set_parent - switch the parent of a mux clk
  * @clk: the mux clk whose input we are switching
diff --git a/include/linux/clk-private.h b/include/linux/clk-private.h
index 9c7f580..0826a60 100644
--- a/include/linux/clk-private.h
+++ b/include/linux/clk-private.h
@@ -35,6 +35,8 @@ struct clk {
 	u8			num_parents;
 	unsigned long		rate;
 	unsigned long		new_rate;
+	struct clk		*new_parent;
+	struct clk		*new_child;
 	unsigned long		flags;
 	unsigned int		enable_count;
 	unsigned int		prepare_count;
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 4e0b634..5fe1d38 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -71,6 +71,10 @@ struct clk_hw;
  * @round_rate:	Given a target rate as input, returns the closest rate actually
  * 		supported by the clock.
  *
+ * @determine_rate: Given a target rate as input, returns the closest rate
+ *		actually supported by the clock, and optionally the parent clock
+ *		that should be used to provide the clock rate.
+ *
  * @get_parent:	Queries the hardware to determine the parent of a clock.  The
  * 		return value is a u8 which specifies the index corresponding to
  * 		the parent clock.  This index can be applied to either the
@@ -116,6 +120,9 @@ struct clk_ops {
 					unsigned long parent_rate);
 	long		(*round_rate)(struct clk_hw *hw, unsigned long,
 					unsigned long *);
+	long		(*determine_rate)(struct clk_hw *hw, unsigned long rate,
+					unsigned long *best_parent_rate,
+					struct clk **best_parent_clk);
 	int		(*set_parent)(struct clk_hw *hw, u8 index);
 	u8		(*get_parent)(struct clk_hw *hw);
 	int		(*set_rate)(struct clk_hw *hw, unsigned long,
-- 
1.8.1.2




From linux at arm.linux.org.uk  Fri Apr 19 12:30:20 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Fri, 19 Apr 2013 17:30:20 +0100
Subject: [PATCH v2 04/13] ARM: timer-sp: convert to use CLKSRC_OF init
In-Reply-To: <1364854883-5961-5-git-send-email-robherring2@gmail.com>
References: <1364854883-5961-1-git-send-email-robherring2@gmail.com>
 <1364854883-5961-5-git-send-email-robherring2@gmail.com>
Message-ID: <20130419163019.GX14496@n2100.arm.linux.org.uk>

On Mon, Apr 01, 2013 at 05:21:14PM -0500, Rob Herring wrote:
> -void __init sp804_clockevents_init(void __iomem *base, unsigned int irq,
> -	const char *name)
> +void __init __sp804_clockevents_init(void __iomem *base, unsigned int irq, struct clk *clk, const char *name)

This line is really too long.  That's why the previous wrapped it.  Please
do the same with yours.



From nicolas.pitre at linaro.org  Fri Apr 19 12:33:22 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Fri, 19 Apr 2013 12:33:22 -0400 (EDT)
Subject: [Xen-devel] [PATCH v6 1/4] arm: introduce psci_smp_ops
In-Reply-To: <1366388166.29403.2.camel@dagon.hellion.org.uk>
References: <alpine.DEB.2.02.1304031239550.5078@kaball.uk.xensource.com>
 <1365167495-18508-1-git-send-email-stefano.stabellini@eu.citrix.com>
 <20130418161341.GB14496@n2100.arm.linux.org.uk>
 <alpine.DEB.2.02.1304181714560.7254@kaball.uk.xensource.com>
 <alpine.LFD.2.03.1304181237480.17375@syhkavp.arg>
 <alpine.DEB.2.02.1304181749260.7254@kaball.uk.xensource.com>
 <alpine.LFD.2.03.1304181336280.17375@syhkavp.arg>
 <alpine.DEB.2.02.1304191035360.7254@kaball.uk.xensource.com>
 <alpine.LFD.2.03.1304191146230.17375@syhkavp.arg>
 <1366388166.29403.2.camel@dagon.hellion.org.uk>
Message-ID: <alpine.LFD.2.03.1304191223280.17375@syhkavp.arg>

On Fri, 19 Apr 2013, Ian Campbell wrote:

> On Fri, 2013-04-19 at 16:47 +0100, Nicolas Pitre wrote:
> > No one should be probing registers without making sure it is safe to do 
> > so.  Even on non virtualized hardware this can be a dangerous thing to 
> > do.
> 
> Won't people writing per machine code consider, not unreasonably, that
> having been called through a mdesc machine specific hook constitutes
> enough "making sure" that they think it is safe to touch registers which
> are specific to that machine?

Remember that this hook was introduced to decide at run time between 
different possibilities for SMP ops on the _same_ machine configuration.  
That machine shouldn't do things which is not permitted on either 
possible alternatives already.  So far the actual usage of that hook 
only looks in the DT to make a decision.  But even if it were to touch 
the hardware, that means it has to be safe to do so on all the possible 
hardware variations this mdesc is associated to.

And if Xen wants to emulate one of those hardware alternatives, then it 
better be ready to emulate it properly, or manage for _another_ mdesc to 
be selected instead.  That's why mach-virt was introduced.

So in my opinion there is just no issue here.


Nicolas


From peter.maydell at linaro.org  Fri Apr 19 12:33:18 2013
From: peter.maydell at linaro.org (Peter Maydell)
Date: Fri, 19 Apr 2013 17:33:18 +0100
Subject: [RFC] arm64: Early printk support for virtio-mmio console devices.
In-Reply-To: <20130419162226.GB5383@localhost.cambridge.arm.com>
References: <CAAHg+HhtCorArCmx=ha0=64+SJZiizzrDUKSPLV=N+OzO8zAxQ@mail.gmail.com>
 <20130419090558.GA13283@mudshark.cambridge.arm.com>
 <CAAHg+HipCX2ma6brxj9Kgc3ew39b5e30grLwyun9CViif-5wZQ@mail.gmail.com>
 <20130419092752.GB13283@mudshark.cambridge.arm.com>
 <CAFEAcA8j124G=vaHObJ_w5wOhUiS3KYKbjMnigbnr6mgwFxZUg@mail.gmail.com>
 <CAAHg+Hg=t97SJ0JPZYgrZaL+zimo-wbezwaj1BQvHqE-vf4VDA@mail.gmail.com>
 <20130419093953.GD13283@mudshark.cambridge.arm.com>
 <CAFEAcA_WfYpyvq54rZqS8JZkmDF5JXB+CNHFH5CnrhKun52uzA@mail.gmail.com>
 <20130419161201.GA5383@localhost.cambridge.arm.com>
 <CAFEAcA-F18kR4JihdxaLTm3qb4n51tsygG1RW4djwJ0u9+FQqw@mail.gmail.com>
 <20130419162226.GB5383@localhost.cambridge.arm.com>
Message-ID: <CAFEAcA_vdXbtK=U2gauC=DsrB=_cSfcUTaNCiB0Ts4YOq_pXEg@mail.gmail.com>

On 19 April 2013 17:22, Catalin Marinas <catalin.marinas at arm.com> wrote:
> earlyprintk is used for debugging early problems, like DT parsing. You
> don't have to use it unless you are debugging something. Without
> earlyprintk you just get a normal console during boot, based on the DT
> description.

The command line lives in the DTB anyway so if you can't look
in the DTB you can't get at earlyprintk config either way.

-- PMM


From linux at arm.linux.org.uk  Fri Apr 19 12:40:30 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Fri, 19 Apr 2013 17:40:30 +0100
Subject: [RFC][PATCH] arm: highmem: Add support for flushing
 kmap_atomic mappings
In-Reply-To: <1365198171-8469-1-git-send-email-lauraa@codeaurora.org>
References: <1365198171-8469-1-git-send-email-lauraa@codeaurora.org>
Message-ID: <20130419164030.GY14496@n2100.arm.linux.org.uk>

On Fri, Apr 05, 2013 at 02:42:51PM -0700, Laura Abbott wrote:
> The highmem code provides kmap_flush_unused to ensure all kmap
> mappings are really removed if they are used. This code does not
> handle kmap_atomic mappings since they are managed separately.
> This prevents an issue for any code which relies on having absolutely
> no mappings for a particular page. Rather than pay the penalty of
> having CONFIG_DEBUG_HIGHMEM on all the time, add functionality
> to remove the kmap_atomic mappings in a similar way to kmap_flush_unused.

I get the feeling that there's something behind this which is pushing
for there only being no mappings for a particular page.  In a SMP
environment that sounds like a dodgy assumption.  Maybe you could
provide the background behind this patch?

> This is intended to be an RFC to make sure this approach is
> reasonable. The goal is to have kmap_atomic_flush_unused be a public
> API.

That implies that there's some callers which need it, which aren't
part of this patch - and a motivation for this outside of what we
can see here.  That needs to be explained.  Plus, unused APIs in
the mainline kernel don't tend ot stick around for long, so it really
needs a use case to be demonstrated before it can be merged.

> 
> Signed-off-by: Laura Abbott <lauraa at codeaurora.org>
> ---
>  arch/arm/mm/highmem.c |   51 +++++++++++++++++++++++++++++++++++++++++++++++++
>  1 files changed, 51 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/mm/highmem.c b/arch/arm/mm/highmem.c
> index 21b9e1b..f4c0466 100644
> --- a/arch/arm/mm/highmem.c
> +++ b/arch/arm/mm/highmem.c
> @@ -10,6 +10,7 @@
>   * published by the Free Software Foundation.
>   */
>  
> +#include <linux/cpu.h>
>  #include <linux/module.h>
>  #include <linux/highmem.h>
>  #include <linux/interrupt.h>
> @@ -135,3 +136,53 @@ struct page *kmap_atomic_to_page(const void *ptr)
>  
>  	return pte_page(get_top_pte(vaddr));
>  }
> +
> +static void kmap_remove_unused_cpu(int cpu)
> +{
> +	int start_idx, idx, type;
> +
> +	pagefault_disable();
> +	type = kmap_atomic_idx();
> +	start_idx = type + 1 + KM_TYPE_NR * cpu;
> +
> +	for (idx = start_idx; idx < KM_TYPE_NR + KM_TYPE_NR * cpu; idx++) {
> +		unsigned long vaddr = __fix_to_virt(FIX_KMAP_BEGIN + idx);
> +		set_top_pte(vaddr, __pte(0));
> +	}
> +	pagefault_enable();

Hmm.  Why are you using pagefault_disable() around this?  This code itself
should not cause any page faults.  Maybe you mean to disable preemption,
but that should already be disabled (if not the above is buggy.)  Maybe
interrupts - that would make more sense, but as soon as interrupts are
re-enabled, it's possible for drivers to start create kmap_atomic()
mappings again.

So... the question is... why this... for what use case?

At the moment it just feels like it's rather buggy and racy.

> +static int hotplug_kmap_atomic_callback(struct notifier_block *nfb,
> +                                unsigned long action, void *hcpu)
> +{
> +        switch (action & (~CPU_TASKS_FROZEN)) {

Parens around ~CPU_TASKS_FROZEN is not required.

> +        case CPU_DYING:
> +		kmap_remove_unused_cpu((int)hcpu);
> +                break;
> +        default:
> +                break;
> +        }
> +
> +        return NOTIFY_OK;

Please watch your indentation...

> +}
> +
> +static struct notifier_block hotplug_kmap_atomic_notifier = {
> +        .notifier_call = hotplug_kmap_atomic_callback,
> +};
> +
> +static int __init init_kmap_atomic(void)
> +{
> +

And this blank line isn't needed.


From james.hogan at imgtec.com  Fri Apr 19 12:41:00 2013
From: james.hogan at imgtec.com (James Hogan)
Date: Fri, 19 Apr 2013 17:41:00 +0100
Subject: [RFC PATCH v1 0/3] clk: implement remuxing during set_rate
In-Reply-To: <20130403213412.3383.84823@quantum>
References: <1363967031-22781-1-git-send-email-james.hogan@imgtec.com>
 <515B8EAD.8020109@codeaurora.org>
 <CAAG0J99i-AwbGoerTzQvJ+JC9yj-3Owm3e5+6xTijo4Gihcx-Q@mail.gmail.com>
 <20130403213412.3383.84823@quantum>
Message-ID: <5171739C.90707@imgtec.com>

Hi Mike,

On 03/04/13 22:34, Mike Turquette wrote:
> diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
> index 9fdfae7..1a19186 100644
> --- a/include/linux/clk-provider.h
> +++ b/include/linux/clk-provider.h
> @@ -126,6 +126,9 @@ struct clk_ops {
>  					unsigned long parent_rate);
>  	long		(*round_rate)(struct clk_hw *hw, unsigned long,
>  					unsigned long *);
> +	s64		(*determine_rate)(struct clk_hw *hw, unsigned long rate,
> +					unsigned long *best_parent_rate,
> +					struct clk *best_parent_clk);

Thanks for the comments. I've sent a new patchset based on this. I've
left the return value for determine_rate the same as round_rate though
(long rather than s64), figuring that introducing s64 would be a can of
worms, and if wanting to convert code to use s64, it should probably be
done together in a separate patchset.

Cheers
James



From tomi.valkeinen at ti.com  Fri Apr 19 12:41:36 2013
From: tomi.valkeinen at ti.com (Tomi Valkeinen)
Date: Fri, 19 Apr 2013 19:41:36 +0300
Subject: linux-next ARM multi-platform randconfig errors
In-Reply-To: <20130419161257.GI10155@atomide.com>
References: <5170B4C6.1030300@gmail.com> <20130419161257.GI10155@atomide.com>
Message-ID: <517173C0.6010902@ti.com>

On 2013-04-19 19:12, Tony Lindgren wrote:
> * Rob Herring <robherring2 at gmail.com> [130418 20:11]:

>> dss-common.c:(.cpuinit.text+0x38): undefined reference to `omap_get_wakeupgen_base'
>> dss-common.c:(.cpuinit.text+0x48): undefined reference to `omap_secure_apis_support'
>> dss-common.c:(.init.text+0x3db0): undefined reference to `omap_get_wakeupgen_base'
>> dss-common.c:(.init.text+0x3dcc): undefined reference to `omap_secure_apis_support'
>> dss-common.c:(.init.text+0x61b8): undefined reference to `usb_bind_phy'
>> dss-common.c:(.init.text+0x6314): undefined reference to `usb_bind_phy'
>> dss-common.c:(.init.text+0x6488): undefined reference to `usb_bind_phy'
>> dss-common.c:(.init.text+0x65ac): undefined reference to `usb_bind_phy'
>> dss-common.c:(.ref.text+0x10): undefined reference to `omap_get_wakeupgen_base'
>> dss-common.c:(.ref.text+0x18): undefined reference to `omap_secure_apis_support'
>> dss-common.c:(.ref.text+0x54): undefined reference to `omap4_hotplug_cpu'
>> dss-common.c:(.ref.text+0x58): undefined reference to `omap_secure_apis_support'
>> dss-common.c:(.text+0x11b5c): undefined reference to `usb_bind_phy'
> 
> Tomi, can you take a look at the dss-common.c one? That should be
> reproducable with omap2plus_defconfig and modifying some options
> there.

None of those functions are used by dss-common.c, so I don't really know
what that is about. Doesn't look correct errors to me... I can try to
reproduce.

Btw, there's also this:

>> drivers/video/omap2/dss/dpi.c:181:2: error: implicit declaration of function 'dsi_hsdiv_calc' [-Werror=implicit-function-declaration]
>> drivers/video/omap2/dss/dpi.c:201:2: error: implicit declaration of function 'dsi_get_pll_clkin' [-Werror=implicit-function-declaration]
>> drivers/video/omap2/dss/dpi.c:212:2: error: implicit declaration of function 'dsi_pll_calc' [-Werror=implicit-function-declaration]

I have a patch for that, not yet applied.

 Tomi


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130419/47680913/attachment-0001.sig>

From s.nawrocki at samsung.com  Fri Apr 19 12:51:47 2013
From: s.nawrocki at samsung.com (Sylwester Nawrocki)
Date: Fri, 19 Apr 2013 18:51:47 +0200
Subject: [PATCH] cpufreq: exynos: allow disabling cpufreq drivers
In-Reply-To: <201304191554.29679.arnd@arndb.de>
References: <201304191554.29679.arnd@arndb.de>
Message-ID: <51717623.2060709@samsung.com>

On 04/19/2013 03:54 PM, Arnd Bergmann wrote:
> Commit 6e6aac7590 "ARM: EXYNOS: Migrate clock support to common
> clock framework" broke support for the exynos cpufreq drivers.
> While we're waiting for a fix for this, let's get back to a state
> where the kernel builds again with the cpufreq subsystem enabled
> but ARM_EXYNOS_CPUFREQ disabled. I assume that this was the intention
> behind this Kconfig symbol anyway.
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Cc: Sylwester Nawrocki <s.nawrocki at samsung.com>
> Cc: Tomasz Figa <t.figa at samsung.com>
> Cc: Thomas Abraham <thomas.abraham at linaro.org>
> Cc: Kukjin Kim <kgene.kim at samsung.com>
> Cc: cpufreq at vger.kernel.org
> Cc: Rafael J. Wysocki <rjw at sisk.pl>
> ---
> Rafael, I'm putting this patch into the arm-soc tree now to avoid
> a bug based on a patch that I got from Kukjin. If you have any
> objections, please let me know so I can revert it again.
> 
> Everyone else: Why does 6e6aac7590 have your "Tested-by" and
> "Signed-off-by" tags on it when it's obviously broken? Who is
> fixing this? Having no working exynos cpufreq support in 3.10
> would be a serious regression.

Not sure what happened here, but my and Tomasz's Tested-by were given 
for v5 of the patch series including 6e6aac7590, while it seems v6 
has been applied. And the patch is not same in both series.

There could be some differences in the base tree I used when testing 
this [1] series, as it was hard to determine against what tag it was 
created exactly. Also I didn't test in on all platforms, only 
Exynos4412.

And the cpufreq really needs to get fixed, as it now modifies registers
which belong to the clock driver...

[1] http://www.spinics.net/lists/arm-kernel/msg214149.html

Thanks,
Sylwester


From linux at arm.linux.org.uk  Fri Apr 19 12:52:08 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Fri, 19 Apr 2013 17:52:08 +0100
Subject: [PATCH v4, part3 01/15] mm: fix build warnings caused by
 free_reserved_area()
In-Reply-To: <1365256509-29024-2-git-send-email-jiang.liu@huawei.com>
References: <1365256509-29024-1-git-send-email-jiang.liu@huawei.com>
 <1365256509-29024-2-git-send-email-jiang.liu@huawei.com>
Message-ID: <20130419165208.GZ14496@n2100.arm.linux.org.uk>

On Sat, Apr 06, 2013 at 09:54:55PM +0800, Jiang Liu wrote:
> Fix following build warnings cuased by free_reserved_area():
> 
> arch/arm/mm/init.c: In function 'mem_init':
> arch/arm/mm/init.c:603:2: warning: passing argument 1 of 'free_reserved_area' makes integer from pointer without a cast [enabled by default]
>   free_reserved_area(__va(PHYS_PFN_OFFSET), swapper_pg_dir, 0, NULL);
>   ^
> In file included from include/linux/mman.h:4:0,
>                  from arch/arm/mm/init.c:15:
> include/linux/mm.h:1301:22: note: expected 'long unsigned int' but argument is of type 'void *'
>  extern unsigned long free_reserved_area(unsigned long start, unsigned long end,
> 
>    mm/page_alloc.c: In function 'free_reserved_area':
> >> mm/page_alloc.c:5134:3: warning: passing argument 1 of 'virt_to_phys' makes pointer from integer without a cast [enabled by default]
>    In file included from arch/mips/include/asm/page.h:49:0,
>                     from include/linux/mmzone.h:20,
>                     from include/linux/gfp.h:4,
>                     from include/linux/mm.h:8,
>                     from mm/page_alloc.c:18:
>    arch/mips/include/asm/io.h:119:29: note: expected 'const volatile void *' but argument is of type 'long unsigned int'
>    mm/page_alloc.c: In function 'free_area_init_nodes':
>    mm/page_alloc.c:5030:34: warning: array subscript is below array bounds [-Warray-bounds]
> 
> Signed-off-by: Jiang Liu <jiang.liu at huawei.com>
> Reported-by: Arnd Bergmann <arnd at arndb.de>
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-kernel at vger.kernel.org
> Cc: linux-mm at kvack.org
> ---
>  arch/arm/mm/init.c |    6 ++++--
>  mm/page_alloc.c    |    2 +-
>  2 files changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
> index 9a5cdc0..7a82fcd 100644
> --- a/arch/arm/mm/init.c
> +++ b/arch/arm/mm/init.c
> @@ -600,7 +600,8 @@ void __init mem_init(void)
>  
>  #ifdef CONFIG_SA1111
>  	/* now that our DMA memory is actually so designated, we can free it */
> -	free_reserved_area(__va(PHYS_PFN_OFFSET), swapper_pg_dir, 0, NULL);
> +	free_reserved_area((unsigned long)__va(PHYS_PFN_OFFSET),
> +			   (unsigned long)swapper_pg_dir, 0, NULL);
>  #endif
>  
>  	free_highpages();
> @@ -728,7 +729,8 @@ void free_initmem(void)
>  	extern char __tcm_start, __tcm_end;
>  
>  	poison_init_mem(&__tcm_start, &__tcm_end - &__tcm_start);
> -	free_reserved_area(&__tcm_start, &__tcm_end, 0, "TCM link");
> +	free_reserved_area((unsigned long)&__tcm_start,
> +			   (unsigned long)&__tcm_end, 0, "TCM link");
>  #endif
>  
>  	poison_init_mem(__init_begin, __init_end - __init_begin);
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index e4923e9..8bf7956 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -5196,7 +5196,7 @@ unsigned long free_reserved_area(unsigned long start, unsigned long end,
>  	for (pages = 0; pos < end; pos += PAGE_SIZE, pages++) {
>  		if (poison)
>  			memset((void *)pos, poison, PAGE_SIZE);
> -		free_reserved_page(virt_to_page(pos));
> +		free_reserved_page(virt_to_page((void *)pos));

Don't all these casts suggest to you that you may have the type wrong
in the first place?


From linux at arm.linux.org.uk  Fri Apr 19 12:54:29 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Fri, 19 Apr 2013 17:54:29 +0100
Subject: [PATCH v4, part3 13/41] mm/ARM: prepare for removing
 num_physpages and simplify mem_init()
In-Reply-To: <1365258760-30821-14-git-send-email-jiang.liu@huawei.com>
References: <1365258760-30821-1-git-send-email-jiang.liu@huawei.com>
 <1365258760-30821-14-git-send-email-jiang.liu@huawei.com>
Message-ID: <20130419165429.GA14496@n2100.arm.linux.org.uk>

On Sat, Apr 06, 2013 at 10:32:12PM +0800, Jiang Liu wrote:
> Prepare for removing num_physpages and simplify mem_init().
> 
> Signed-off-by: Jiang Liu <jiang.liu at huawei.com>
> Cc: Russell King <linux at arm.linux.org.uk>
> Cc: Catalin Marinas <catalin.marinas at arm.com>
> Cc: Will Deacon <will.deacon at arm.com>
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-kernel at vger.kernel.org
> ---
>  arch/arm/mm/init.c |   47 ++---------------------------------------------
>  1 file changed, 2 insertions(+), 45 deletions(-)
> 
> diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
> index add4fcb..7a911d1 100644
> --- a/arch/arm/mm/init.c
> +++ b/arch/arm/mm/init.c
> @@ -582,9 +582,6 @@ static void __init free_highpages(void)
>   */
>  void __init mem_init(void)
>  {
> -	unsigned long reserved_pages, free_pages;
> -	struct memblock_region *reg;
> -	int i;
>  #ifdef CONFIG_HAVE_TCM
>  	/* These pointers are filled in on TCM detection */
>  	extern u32 dtcm_end;
> @@ -605,47 +602,7 @@ void __init mem_init(void)
>  
>  	free_highpages();
>  
> -	reserved_pages = free_pages = 0;
> -
> -	for_each_bank(i, &meminfo) {
> -		struct membank *bank = &meminfo.bank[i];
> -		unsigned int pfn1, pfn2;
> -		struct page *page, *end;
> -
> -		pfn1 = bank_pfn_start(bank);
> -		pfn2 = bank_pfn_end(bank);
> -
> -		page = pfn_to_page(pfn1);
> -		end  = pfn_to_page(pfn2 - 1) + 1;
> -
> -		do {
> -			if (PageReserved(page))
> -				reserved_pages++;
> -			else if (!page_count(page))
> -				free_pages++;
> -			page++;
> -		} while (page < end);
> -	}
> -
> -	/*
> -	 * Since our memory may not be contiguous, calculate the
> -	 * real number of pages we have in this system
> -	 */
> -	printk(KERN_INFO "Memory:");
> -	num_physpages = 0;
> -	for_each_memblock(memory, reg) {
> -		unsigned long pages = memblock_region_memory_end_pfn(reg) -
> -			memblock_region_memory_base_pfn(reg);
> -		num_physpages += pages;
> -		printk(" %ldMB", pages >> (20 - PAGE_SHIFT));
> -	}
> -	printk(" = %luMB total\n", num_physpages >> (20 - PAGE_SHIFT));
> -
> -	printk(KERN_NOTICE "Memory: %luk/%luk available, %luk reserved, %luK highmem\n",
> -		nr_free_pages() << (PAGE_SHIFT-10),
> -		free_pages << (PAGE_SHIFT-10),
> -		reserved_pages << (PAGE_SHIFT-10),
> -		totalhigh_pages << (PAGE_SHIFT-10));
> +	mem_init_print_info(NULL);

I'm concerned about this.  We explicitly do not use the memblock information
when walking the memory above for the reserved/free pages because memblock
merges the various banks of memory together - and those may cross sparsemem
boundaries.  Any crossing of the sparsemem boundaries needs the struct page
pointer to be re-evaluated because it can be part of a different array of
such things.

Where's the rest of the patches?


From stefano.stabellini at eu.citrix.com  Fri Apr 19 13:06:01 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Fri, 19 Apr 2013 18:06:01 +0100
Subject: [Xen-devel] [PATCH v6 1/4] arm: introduce psci_smp_ops
In-Reply-To: <alpine.LFD.2.03.1304191223280.17375@syhkavp.arg>
References: <alpine.DEB.2.02.1304031239550.5078@kaball.uk.xensource.com>
 <1365167495-18508-1-git-send-email-stefano.stabellini@eu.citrix.com>
 <20130418161341.GB14496@n2100.arm.linux.org.uk>
 <alpine.DEB.2.02.1304181714560.7254@kaball.uk.xensource.com>
 <alpine.LFD.2.03.1304181237480.17375@syhkavp.arg>
 <alpine.DEB.2.02.1304181749260.7254@kaball.uk.xensource.com>
 <alpine.LFD.2.03.1304181336280.17375@syhkavp.arg>
 <alpine.DEB.2.02.1304191035360.7254@kaball.uk.xensource.com>
 <alpine.LFD.2.03.1304191146230.17375@syhkavp.arg>
 <1366388166.29403.2.camel@dagon.hellion.org.uk>
 <alpine.LFD.2.03.1304191223280.17375@syhkavp.arg>
Message-ID: <alpine.DEB.2.02.1304191739120.7254@kaball.uk.xensource.com>

On Fri, 19 Apr 2013, Nicolas Pitre wrote:
> On Fri, 19 Apr 2013, Ian Campbell wrote:
> 
> > On Fri, 2013-04-19 at 16:47 +0100, Nicolas Pitre wrote:
> > > No one should be probing registers without making sure it is safe to do 
> > > so.  Even on non virtualized hardware this can be a dangerous thing to 
> > > do.
> > 
> > Won't people writing per machine code consider, not unreasonably, that
> > having been called through a mdesc machine specific hook constitutes
> > enough "making sure" that they think it is safe to touch registers which
> > are specific to that machine?
> 
> Remember that this hook was introduced to decide at run time between 
> different possibilities for SMP ops on the _same_ machine configuration.  
> That machine shouldn't do things which is not permitted on either 
> possible alternatives already.  So far the actual usage of that hook 
> only looks in the DT to make a decision.  But even if it were to touch 
> the hardware, that means it has to be safe to do so on all the possible 
> hardware variations this mdesc is associated to.

This last sentence is the key.

It is not guaranteed that being safe on "all the possible hardware
variations this mdesc is associated to" and being safe on Xen are the
same thing.

What if the same magic configuration register exists on all the possible
variations of the platform?
I understand that it is unlikely but I think it is a possibility.

If we don't take further precautions I'll be forced to regularly scan
the list for smp_init implementations and look for possible breakages,
pointing the unaware author of the patches to this conversation.
Honestly it is not my idea of fun.


> And if Xen wants to emulate one of those hardware alternatives, then it 
> better be ready to emulate it properly, or manage for _another_ mdesc to 
> be selected instead.  That's why mach-virt was introduced.

I don't mean to argue pointlessly here, but I thought that it was clear
that Xen does not emulate any hardware interfaces at all.

Of course when a convenient virtualization aware hardware interface is
available (the vGIC for example) Xen is going to use it, but other than
that no emulation is going to be done.


> So in my opinion there is just no issue here.

Not now, and maybe not even in the near future.
But I feel that we are taking an error prone approach.


From tony at atomide.com  Fri Apr 19 13:13:19 2013
From: tony at atomide.com (Tony Lindgren)
Date: Fri, 19 Apr 2013 10:13:19 -0700
Subject: Multiple issues with omap4 panda es in linux next
Message-ID: <20130419171318.GK10155@atomide.com>

Hi all,

Here's a list of breakage I've noticed so far while trying to
use linux next on my pandaboard es. Probably similar issues exist
on other boards as well.

Ideally we would not have any breakage by the merge window, so
let's try to get these fixed ASAP:

1. Serial console broken on panda es booting with DT

The symptoms are dmesg output stopping after few lines
and only continuing after pressing a key. Does not seem to
happen on blaze with DT for some reason. And does not happen
on panda es with legacy booting.

2. MUSB fails with legacy booting and DT on panda es

With both legacy and DT booting I get something like:

HS USB OTG: no transceiver configured
musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with status -517

3. DSS fails with DT booting

Works with legacy booting but fails with DT. I'm almost certain
the DT booting was working last week or so?

This is what I now get with DT booting:

omapdss DSI error: can't get VDDS_DSI regulator
omapdss HDMI error: can't get VDDA_HDMI_DAC regulator
omapdss HDMI error: device hdmi init failed: -517
omapdss CORE error: driver probe failed: -22
...

4. WLAN with wl12xx fails with both legacy and DT booting

No real output here with the legacy mode, just the usual
using pinctrl dummy state warning.

Regards,

Tony


From catalin.marinas at arm.com  Fri Apr 19 13:14:56 2013
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Fri, 19 Apr 2013 18:14:56 +0100
Subject: [RFC] arm64: Early printk support for virtio-mmio console devices.
In-Reply-To: <CAFEAcA_vdXbtK=U2gauC=DsrB=_cSfcUTaNCiB0Ts4YOq_pXEg@mail.gmail.com>
References: <CAAHg+HipCX2ma6brxj9Kgc3ew39b5e30grLwyun9CViif-5wZQ@mail.gmail.com>
 <20130419092752.GB13283@mudshark.cambridge.arm.com>
 <CAFEAcA8j124G=vaHObJ_w5wOhUiS3KYKbjMnigbnr6mgwFxZUg@mail.gmail.com>
 <CAAHg+Hg=t97SJ0JPZYgrZaL+zimo-wbezwaj1BQvHqE-vf4VDA@mail.gmail.com>
 <20130419093953.GD13283@mudshark.cambridge.arm.com>
 <CAFEAcA_WfYpyvq54rZqS8JZkmDF5JXB+CNHFH5CnrhKun52uzA@mail.gmail.com>
 <20130419161201.GA5383@localhost.cambridge.arm.com>
 <CAFEAcA-F18kR4JihdxaLTm3qb4n51tsygG1RW4djwJ0u9+FQqw@mail.gmail.com>
 <20130419162226.GB5383@localhost.cambridge.arm.com>
 <CAFEAcA_vdXbtK=U2gauC=DsrB=_cSfcUTaNCiB0Ts4YOq_pXEg@mail.gmail.com>
Message-ID: <20130419171455.GA43450@MacBook-Pro.local>

On Fri, Apr 19, 2013 at 05:33:18PM +0100, Peter Maydell wrote:
> On 19 April 2013 17:22, Catalin Marinas <catalin.marinas at arm.com> wrote:
> > earlyprintk is used for debugging early problems, like DT parsing. You
> > don't have to use it unless you are debugging something. Without
> > earlyprintk you just get a normal console during boot, based on the DT
> > description.
> 
> The command line lives in the DTB anyway so if you can't look
> in the DTB you can't get at earlyprintk config either way.

Linux indeed looks in the DT for the command line and that's what's
triggering the earlyprintk console but at that stage the DT is flat.
Unflattening the DT happens later (it requires slab allocator). I
initially thought about extracting the early console device from the DT
but when it is flat you can't parse the full hierarchy to get its
address.

-- 
Catalin


From amurray at embedded-bits.co.uk  Fri Apr 19 13:15:19 2013
From: amurray at embedded-bits.co.uk (Andrew Murray)
Date: Fri, 19 Apr 2013 18:15:19 +0100
Subject: [GIT PULL V2 1/4] mvebu driver changes for v3.10
In-Reply-To: <51716CD9.4030901@free-electrons.com>
References: <20130415182824.GN28693@titan.lakedaemon.net>
 <20130416150416.GB28693@titan.lakedaemon.net>
 <20130418053002.GB12816@quad.lixom.net>
 <CAOesGMjD-VAZW-zL-jm65xSJkFLpzbYOdvN6-5pV1OW_vJDCWg@mail.gmail.com>
 <517155FE.30406@free-electrons.com>
 <51716CD9.4030901@free-electrons.com>
Message-ID: <CAPcvp5Gq_K0w2QnmseX-D3x6Y765EabySeJfB51iXF-TXYMQDw@mail.gmail.com>

On 19 April 2013 17:12, Gregory CLEMENT
<gregory.clement at free-electrons.com> wrote:
> On 04/19/2013 04:34 PM, Gregory CLEMENT wrote:
>> On 04/19/2013 04:09 PM, Olof Johansson wrote:
>>> On Wed, Apr 17, 2013 at 10:30 PM, Olof Johansson <olof at lixom.net> wrote:
>>>> On Tue, Apr 16, 2013 at 11:04:16AM -0400, Jason Cooper wrote:
>>>>>
>>>>> The following changes since commit 8bb9660418e05bb1845ac1a2428444d78e322cc7:
>>>>>
>>>>>   Linux 3.9-rc4 (2013-03-23 16:52:44 -0700)
>>>>>
>>>>> are available in the git repository at:
>>>>>
>>>>>   git://git.infradead.org/users/jcooper/linux.git tags/drivers-3.10-2
>>>>>
>>>>> for you to fetch changes up to ac7b07ec369324063e52c37b3fb0ad1a1814d879:
>>>>>
>>>>>   clk: mvebu: add more PCIe clocks for Armada XP (2013-04-16 14:47:01 +0000)
>>>>
>>>> Pulled, thanks.
>>>
>>> Dropped due to build errors on powerpc64. 3.11 material now.
>>>
>>
>> Wait! That means dropping _all_ the change done in mvebu for 3.10 just
>> for one patch in the of/pci part?
>>
>> Jason, did you take the accurate patch? Because according to Grant
>> Likely, the build didn't fail on ppc, see:
>>
>> http://www.spinics.net/lists/arm-kernel/msg238517.html
>
> I investigated it a little more and my first assumption was wrong,
> the faulty commit was not the one I think. I didn't work directly
> on the PCIe part, and Thomas who did it is currently in the plane.

I thought the faulty commit with in the MIPS patch (last patch in the
set). And a patch to fix this was prepared by Gabor Juhos [2].

Or is there another faulty commit in my v7 set [1]? If you let me know
I can fix it

Andrew Murray

[1] http://www.spinics.net/lists/linux-pci/msg21708.html
[2] http://permalink.gmane.org/gmane.linux.ports.mips.general/37399

>
> So instead of throwing everything, could you just remove the
> offending commit, AFAIK we don't need it yet, (the patch
> depending of this one are located in the mvebu-late/pcie branch):
>
> 9ecbe03 pci: infrastructure to add drivers in drivers/pci/host
>
> Thanks!
>
>>
>>
>>>
>>> -Olof
>>>
>>
>>
>
>
> --
> Gregory Clement, Free Electrons
> Kernel, drivers, real-time and embedded Linux
> development, consulting, training and support.
> http://free-electrons.com
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From jason at lakedaemon.net  Fri Apr 19 13:21:35 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Fri, 19 Apr 2013 13:21:35 -0400
Subject: [GIT PULL V3 1/4] mvebu driver changes for v3.10
In-Reply-To: <51716CD9.4030901@free-electrons.com>
References: <20130415182824.GN28693@titan.lakedaemon.net>
 <20130416150416.GB28693@titan.lakedaemon.net>
 <20130418053002.GB12816@quad.lixom.net>
 <CAOesGMjD-VAZW-zL-jm65xSJkFLpzbYOdvN6-5pV1OW_vJDCWg@mail.gmail.com>
 <517155FE.30406@free-electrons.com>
 <51716CD9.4030901@free-electrons.com>
Message-ID: <20130419172135.GJ27197@titan.lakedaemon.net>


I have dropped:

  9ecbe03 pci: infrastructure to add drivers in drivers/pci/host

Since Gregory said they didn't need it.

thx,

Jason.

The following changes since commit 8bb9660418e05bb1845ac1a2428444d78e322cc7:

  Linux 3.9-rc4 (2013-03-23 16:52:44 -0700)

are available in the git repository at:

  git://git.infradead.org/users/jcooper/linux.git tags/drivers-3.10-2

for you to fetch changes up to a5eddfb24302b9cfb37ce5f0911f090681507fcb:

  clk: mvebu: add more PCIe clocks for Armada XP (2013-04-19 17:15:42 +0000)

----------------------------------------------------------------
mvebu drivers for v3.10 round 2

 - mvebu
    - device bus driver (Acked by gregkh to go through arm-soc)
    - PCIe prep work Acked by appropriate maintainers (of,pci,clk) for arm-soc

----------------------------------------------------------------
Andrew Murray (3):
      of/pci: Unify pci_process_bridge_OF_ranges from Microblaze and PowerPC
      of/pci: Provide support for parsing PCI DT ranges property
      of/pci: mips: convert to common of_pci_range_parser

Ezequiel Garcia (1):
      drivers: memory: Introduce Marvell EBU Device Bus driver

Neil Greatorex (1):
      bus: mvebu-mbus: Restore checking for coherency fabric hardware

Thierry Reding (2):
      of/pci: Add of_pci_get_devfn() function
      of/pci: Add of_pci_parse_bus_range() function

Thomas Petazzoni (4):
      bus: introduce an Marvell EBU MBus driver
      bus: mvebu: fix mistake in PCIe window target attribute for Kirkwood
      clk: mvebu: create parent-child relation for PCIe clocks on Armada 370
      clk: mvebu: add more PCIe clocks for Armada XP

 .../bindings/memory-controllers/mvebu-devbus.txt   | 156 ++++
 arch/microblaze/include/asm/pci-bridge.h           |   5 +-
 arch/microblaze/pci/pci-common.c                   | 192 -----
 arch/mips/pci/pci.c                                |  50 +-
 arch/powerpc/include/asm/pci-bridge.h              |   5 +-
 arch/powerpc/kernel/pci-common.c                   | 192 -----
 drivers/bus/Kconfig                                |   7 +
 drivers/bus/Makefile                               |   1 +
 drivers/bus/mvebu-mbus.c                           | 870 +++++++++++++++++++++
 drivers/clk/mvebu/clk-gating-ctrl.c                |  18 +-
 drivers/memory/Kconfig                             |  10 +
 drivers/memory/Makefile                            |   1 +
 drivers/memory/mvebu-devbus.c                      | 340 ++++++++
 drivers/of/address.c                               |  67 ++
 drivers/of/of_pci.c                                | 228 +++++-
 include/linux/mbus.h                               |  24 +-
 include/linux/of_address.h                         |  46 ++
 include/linux/of_pci.h                             |   6 +
 18 files changed, 1780 insertions(+), 438 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/memory-controllers/mvebu-devbus.txt
 create mode 100644 drivers/bus/mvebu-mbus.c
 create mode 100644 drivers/memory/mvebu-devbus.c




On Fri, Apr 19, 2013 at 06:12:09PM +0200, Gregory CLEMENT wrote:
> On 04/19/2013 04:34 PM, Gregory CLEMENT wrote:
> > On 04/19/2013 04:09 PM, Olof Johansson wrote:
> >> On Wed, Apr 17, 2013 at 10:30 PM, Olof Johansson <olof at lixom.net> wrote:
> >>> On Tue, Apr 16, 2013 at 11:04:16AM -0400, Jason Cooper wrote:
> >>>>
> >>>> The following changes since commit 8bb9660418e05bb1845ac1a2428444d78e322cc7:
> >>>>
> >>>>   Linux 3.9-rc4 (2013-03-23 16:52:44 -0700)
> >>>>
> >>>> are available in the git repository at:
> >>>>
> >>>>   git://git.infradead.org/users/jcooper/linux.git tags/drivers-3.10-2
> >>>>
> >>>> for you to fetch changes up to ac7b07ec369324063e52c37b3fb0ad1a1814d879:
> >>>>
> >>>>   clk: mvebu: add more PCIe clocks for Armada XP (2013-04-16 14:47:01 +0000)
> >>>
> >>> Pulled, thanks.
> >>
> >> Dropped due to build errors on powerpc64. 3.11 material now.
> >>
> > 
> > Wait! That means dropping _all_ the change done in mvebu for 3.10 just
> > for one patch in the of/pci part?
> > 
> > Jason, did you take the accurate patch? Because according to Grant
> > Likely, the build didn't fail on ppc, see:
> > 
> > http://www.spinics.net/lists/arm-kernel/msg238517.html
> 
> I investigated it a little more and my first assumption was wrong,
> the faulty commit was not the one I think. I didn't work directly
> on the PCIe part, and Thomas who did it is currently in the plane.
> 
> So instead of throwing everything, could you just remove the
> offending commit, AFAIK we don't need it yet, (the patch
> depending of this one are located in the mvebu-late/pcie branch):
> 
> 9ecbe03 pci: infrastructure to add drivers in drivers/pci/host
> 
> Thanks!
> 
> > 
> > 
> >>
> >> -Olof
> >>
> > 
> > 
> 
> 
> -- 
> Gregory Clement, Free Electrons
> Kernel, drivers, real-time and embedded Linux
> development, consulting, training and support.
> http://free-electrons.com


From olof at lixom.net  Fri Apr 19 13:24:15 2013
From: olof at lixom.net (Olof Johansson)
Date: Fri, 19 Apr 2013 10:24:15 -0700
Subject: [GIT PULL V3 1/4] mvebu driver changes for v3.10
In-Reply-To: <20130419172135.GJ27197@titan.lakedaemon.net>
References: <20130415182824.GN28693@titan.lakedaemon.net>
 <20130416150416.GB28693@titan.lakedaemon.net>
 <20130418053002.GB12816@quad.lixom.net>
 <CAOesGMjD-VAZW-zL-jm65xSJkFLpzbYOdvN6-5pV1OW_vJDCWg@mail.gmail.com>
 <517155FE.30406@free-electrons.com>
 <51716CD9.4030901@free-electrons.com>
 <20130419172135.GJ27197@titan.lakedaemon.net>
Message-ID: <CAOesGMiRbpfhnVS3DMtK5zkkA4_d4Ktd0Z9s-dg3h4DBNyxYFg@mail.gmail.com>

On Fri, Apr 19, 2013 at 10:21 AM, Jason Cooper <jason at lakedaemon.net> wrote:
>
> I have dropped:
>
>   9ecbe03 pci: infrastructure to add drivers in drivers/pci/host
>
> Since Gregory said they didn't need it.
>
> thx,
>
> Jason.
>
> The following changes since commit 8bb9660418e05bb1845ac1a2428444d78e322cc7:
>
>   Linux 3.9-rc4 (2013-03-23 16:52:44 -0700)
>
> are available in the git repository at:
>
>   git://git.infradead.org/users/jcooper/linux.git tags/drivers-3.10-2
>
> for you to fetch changes up to a5eddfb24302b9cfb37ce5f0911f090681507fcb:
>
>   clk: mvebu: add more PCIe clocks for Armada XP (2013-04-19 17:15:42 +0000)

Sorry, not pulling this for 3.10.

There will likely not be another linux-next before the merge window
opens, so there is no time for trial and error.

Please send a new pull request after -rc1.


Thanks,

-Olof


From tony at atomide.com  Fri Apr 19 13:23:55 2013
From: tony at atomide.com (Tony Lindgren)
Date: Fri, 19 Apr 2013 10:23:55 -0700
Subject: linux-next ARM multi-platform randconfig errors
In-Reply-To: <20130419161257.GI10155@atomide.com>
References: <5170B4C6.1030300@gmail.com> <20130419161257.GI10155@atomide.com>
Message-ID: <20130419172354.GL10155@atomide.com>

* Tony Lindgren <tony at atomide.com> [130419 09:21]:
> * Rob Herring <robherring2 at gmail.com> [130418 20:11]:
> > Current errors in linux-next for ARM multi-platform randconfig builds.
> > 
> > Rob
> > 
> > arch/arm/mach-omap2/built-in.o:dss-common.c:(.init.text+0x6830): more undefined references to `usb_bind_phy' follow
> 
> Felipe & Roger, can you guys take a look at the usb_bind_phy issue
> in linux next? I have not seen that in the multiplatform randconfigs
> I've built, but I have had some omap2+ specific things enabled there.

Oops yes those can be generated with at least the attached randconfig
generated .config:

drivers/usb/host/ohci-hcd.c:1203:2: error: #error "missing bus glue for ohci-hcd"
arch/arm/mach-imx/built-in.o: In function `imx_otg_ulpi_create':
platform-spi_imx.c:(.text+0x2444): undefined reference to `otg_ulpi_create'
arch/arm/mach-imx/built-in.o: In function `imx_src_init':
platform-spi_imx.c:(.init.text+0x8b6c): undefined reference to `reset_controller_register'
arch/arm/mach-omap2/built-in.o: In function `usbhs_init_phys':
dss-common.c:(.text+0x17170): undefined reference to `usb_bind_phy'
arch/arm/mach-omap2/built-in.o: In function `devkit8000_init':
dss-common.c:(.init.text+0x9b0c): undefined reference to `usb_bind_phy'
arch/arm/mach-omap2/built-in.o: In function `omap_ldp_init':
dss-common.c:(.init.text+0x9c68): undefined reference to `usb_bind_phy'
arch/arm/mach-omap2/built-in.o: In function `omap3logic_init':
dss-common.c:(.init.text+0x9dc4): undefined reference to `usb_bind_phy'
arch/arm/mach-omap2/built-in.o: In function `omap3_evm_init':
dss-common.c:(.init.text+0xa098): undefined reference to `usb_bind_phy'
drivers/usb/host/ohci-hcd.c:1203:2: error: #error "missing bus glue for ohci-hcd"

Regards,

Tony
-------------- next part --------------
#
# Automatically generated file; DO NOT EDIT.
# Linux/arm 3.9.0-rc7 Kernel Configuration
#
CONFIG_ARM=y
CONFIG_SYS_SUPPORTS_APM_EMULATION=y
CONFIG_HAVE_PROC_CPU=y
CONFIG_NO_IOPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_RWSEM_GENERIC_SPINLOCK=y
CONFIG_ARCH_HAS_CPUFREQ=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_VECTORS_BASE=0xffff0000
CONFIG_ARM_PATCH_PHYS_VIRT=y
CONFIG_GENERIC_BUG=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y

#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
# CONFIG_SYSVIPC is not set
CONFIG_FHANDLE=y
CONFIG_HAVE_GENERIC_HARDIRQS=y

#
# IRQ subsystem
#
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_HARDIRQS_SW_RESEND=y
CONFIG_GENERIC_IRQ_CHIP=y
CONFIG_IRQ_DOMAIN=y
# CONFIG_IRQ_DOMAIN_DEBUG is not set
CONFIG_SPARSE_IRQ=y
# CONFIG_ALWAYS_USE_PERSISTENT_CLOCK is not set
CONFIG_KTIME_SCALAR=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_ARCH_HAS_TICK_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y

#
# Timers subsystem
#
CONFIG_PERIODIC_HZ=y
# CONFIG_NO_HZ_IDLE is not set
# CONFIG_HIGH_RES_TIMERS is not set

#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set

#
# RCU Subsystem
#
CONFIG_TREE_RCU=y
# CONFIG_PREEMPT_RCU is not set
CONFIG_RCU_STALL_COMMON=y
# CONFIG_RCU_USER_QS is not set
CONFIG_RCU_FANOUT=32
CONFIG_RCU_FANOUT_LEAF=16
# CONFIG_RCU_FANOUT_EXACT is not set
# CONFIG_TREE_RCU_TRACE is not set
CONFIG_RCU_NOCB_CPU=y
CONFIG_RCU_NOCB_CPU_NONE=y
# CONFIG_RCU_NOCB_CPU_ZERO is not set
# CONFIG_RCU_NOCB_CPU_ALL is not set
CONFIG_IKCONFIG=m
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=17
CONFIG_CGROUPS=y
# CONFIG_CGROUP_DEBUG is not set
CONFIG_CGROUP_FREEZER=y
CONFIG_CGROUP_DEVICE=y
CONFIG_CPUSETS=y
# CONFIG_PROC_PID_CPUSET is not set
# CONFIG_CGROUP_CPUACCT is not set
CONFIG_RESOURCE_COUNTERS=y
# CONFIG_MEMCG is not set
# CONFIG_CGROUP_SCHED is not set
CONFIG_BLK_CGROUP=y
CONFIG_DEBUG_BLK_CGROUP=y
# CONFIG_CHECKPOINT_RESTORE is not set
CONFIG_NAMESPACES=y
CONFIG_UTS_NS=y
# CONFIG_PID_NS is not set
# CONFIG_SCHED_AUTOGROUP is not set
# CONFIG_SYSFS_DEPRECATED is not set
CONFIG_RELAY=y
# CONFIG_BLK_DEV_INITRD is not set
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
# CONFIG_EXPERT is not set
CONFIG_HAVE_UID16=y
CONFIG_UID16=y
# CONFIG_SYSCTL_SYSCALL is not set
CONFIG_KALLSYMS=y
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_AIO=y
# CONFIG_EMBEDDED is not set
CONFIG_HAVE_PERF_EVENTS=y
CONFIG_PERF_USE_VMALLOC=y

#
# Kernel Performance Events And Counters
#
# CONFIG_PERF_EVENTS is not set
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_SLUB_DEBUG=y
CONFIG_COMPAT_BRK=y
# CONFIG_SLAB is not set
CONFIG_SLUB=y
# CONFIG_PROFILING is not set
CONFIG_HAVE_OPROFILE=y
# CONFIG_KPROBES is not set
# CONFIG_JUMP_LABEL is not set
# CONFIG_HAVE_64BIT_ALIGNED_ACCESS is not set
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
CONFIG_HAVE_ARCH_TRACEHOOK=y
CONFIG_HAVE_DMA_ATTRS=y
CONFIG_HAVE_DMA_CONTIGUOUS=y
CONFIG_USE_GENERIC_SMP_HELPERS=y
CONFIG_GENERIC_SMP_IDLE_THREAD=y
CONFIG_GENERIC_IDLE_LOOP=y
CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y
CONFIG_HAVE_CLK=y
CONFIG_HAVE_DMA_API_DEBUG=y
CONFIG_HAVE_ARCH_JUMP_LABEL=y
CONFIG_ARCH_WANT_IPC_PARSE_VERSION=y
CONFIG_HAVE_ARCH_SECCOMP_FILTER=y
CONFIG_HAVE_CONTEXT_TRACKING=y
CONFIG_MODULES_USE_ELF_REL=y
CONFIG_CLONE_BACKWARDS=y
CONFIG_OLD_SIGSUSPEND3=y
CONFIG_OLD_SIGACTION=y

#
# GCOV-based kernel profiling
#
# CONFIG_GCOV_KERNEL is not set
CONFIG_HAVE_GENERIC_DMA_COHERENT=y
CONFIG_SLABINFO=y
CONFIG_RT_MUTEXES=y
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
CONFIG_MODULE_FORCE_LOAD=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
# CONFIG_MODVERSIONS is not set
CONFIG_MODULE_SRCVERSION_ALL=y
# CONFIG_MODULE_SIG is not set
CONFIG_STOP_MACHINE=y
CONFIG_BLOCK=y
# CONFIG_LBDAF is not set
CONFIG_BLK_DEV_BSG=y
# CONFIG_BLK_DEV_BSGLIB is not set
CONFIG_BLK_DEV_INTEGRITY=y
# CONFIG_BLK_DEV_THROTTLING is not set

#
# Partition Types
#
# CONFIG_PARTITION_ADVANCED is not set
CONFIG_MSDOS_PARTITION=y
CONFIG_EFI_PARTITION=y

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
# CONFIG_IOSCHED_DEADLINE is not set
CONFIG_IOSCHED_CFQ=m
# CONFIG_CFQ_GROUP_IOSCHED is not set
CONFIG_DEFAULT_NOOP=y
CONFIG_DEFAULT_IOSCHED="noop"
CONFIG_PADATA=y
CONFIG_INLINE_SPIN_UNLOCK_IRQ=y
CONFIG_INLINE_READ_UNLOCK=y
CONFIG_INLINE_READ_UNLOCK_IRQ=y
CONFIG_INLINE_WRITE_UNLOCK=y
CONFIG_INLINE_WRITE_UNLOCK_IRQ=y
CONFIG_MUTEX_SPIN_ON_OWNER=y
CONFIG_FREEZER=y

#
# System Type
#
CONFIG_MMU=y
CONFIG_ARCH_MULTIPLATFORM=y
# CONFIG_ARCH_INTEGRATOR is not set
# CONFIG_ARCH_REALVIEW is not set
# CONFIG_ARCH_VERSATILE is not set
# CONFIG_ARCH_AT91 is not set
# CONFIG_ARCH_CLPS711X is not set
# CONFIG_ARCH_GEMINI is not set
# CONFIG_ARCH_EBSA110 is not set
# CONFIG_ARCH_EP93XX is not set
# CONFIG_ARCH_FOOTBRIDGE is not set
# CONFIG_ARCH_NETX is not set
# CONFIG_ARCH_IOP13XX is not set
# CONFIG_ARCH_IOP32X is not set
# CONFIG_ARCH_IOP33X is not set
# CONFIG_ARCH_IXP4XX is not set
# CONFIG_ARCH_DOVE is not set
# CONFIG_ARCH_KIRKWOOD is not set
# CONFIG_ARCH_MV78XX0 is not set
# CONFIG_ARCH_ORION5X is not set
# CONFIG_ARCH_MMP is not set
# CONFIG_ARCH_KS8695 is not set
# CONFIG_ARCH_W90X900 is not set
# CONFIG_ARCH_LPC32XX is not set
# CONFIG_ARCH_PXA is not set
# CONFIG_ARCH_MSM is not set
# CONFIG_ARCH_SHMOBILE is not set
# CONFIG_ARCH_RPC is not set
# CONFIG_ARCH_SA1100 is not set
# CONFIG_ARCH_S3C24XX is not set
# CONFIG_ARCH_S3C64XX is not set
# CONFIG_ARCH_S5P64X0 is not set
# CONFIG_ARCH_S5PC100 is not set
# CONFIG_ARCH_S5PV210 is not set
# CONFIG_ARCH_EXYNOS is not set
# CONFIG_ARCH_SHARK is not set
# CONFIG_ARCH_U300 is not set
# CONFIG_ARCH_DAVINCI is not set
# CONFIG_ARCH_OMAP1 is not set

#
# Multiple platform selection
#

#
# CPU Core family selection
#
CONFIG_ARCH_MULTI_V6=y
CONFIG_ARCH_MULTI_V7=y
CONFIG_ARCH_MULTI_V6_V7=y
# CONFIG_ARCH_MULTI_CPU_AUTO is not set
CONFIG_ARCH_MVEBU=y

#
# Marvell SOC with device tree
#
CONFIG_MACH_ARMADA_370_XP=y
# CONFIG_MACH_ARMADA_370 is not set
CONFIG_MACH_ARMADA_XP=y
# CONFIG_ARCH_BCM is not set
# CONFIG_ARCH_BCM2835 is not set
# CONFIG_ARCH_CNS3XXX is not set
CONFIG_GPIO_PCA953X=m
CONFIG_KEYBOARD_GPIO_POLLED=m
CONFIG_ARCH_HIGHBANK=y
CONFIG_ARCH_MXC=y

#
# Freescale i.MX support
#
# CONFIG_MXC_IRQ_PRIOR is not set
CONFIG_MXC_TZIC=y
CONFIG_MXC_AVIC=y
CONFIG_MXC_DEBUG_BOARD=y
CONFIG_HAVE_EPIT=y
# CONFIG_MXC_USE_EPIT is not set
CONFIG_MXC_ULPI=y
CONFIG_ARCH_HAS_RNGA=y
CONFIG_HAVE_IMX_ANATOP=y
CONFIG_HAVE_IMX_GPC=y
CONFIG_HAVE_IMX_MMDC=y
CONFIG_HAVE_IMX_SRC=y
CONFIG_ARCH_MXC_IOMUX_V3=y
CONFIG_SOC_IMX31=y
CONFIG_SOC_IMX35=y
CONFIG_SOC_IMX5=y
CONFIG_SOC_IMX51=y

#
# MX31 platforms:
#
# CONFIG_MACH_MX31ADS is not set
# CONFIG_MACH_MX31LILLY is not set
CONFIG_MACH_MX31LITE=y
CONFIG_MACH_PCM037=y
CONFIG_MACH_PCM037_EET=y
CONFIG_MACH_MX31_3DS=y
CONFIG_MACH_MX31MOBOARD=y
# CONFIG_MACH_QONG is not set
CONFIG_MACH_ARMADILLO5X0=y
CONFIG_MACH_KZM_ARM11_01=y
CONFIG_MACH_BUG=y
# CONFIG_MACH_IMX31_DT is not set

#
# MX35 platforms:
#
# CONFIG_MACH_PCM043 is not set
# CONFIG_MACH_MX35_3DS is not set
CONFIG_MACH_EUKREA_CPUIMX35SD=y
CONFIG_MACH_EUKREA_MBIMXSD35_BASEBOARD=y
CONFIG_MACH_VPR200=y

#
# i.MX51 machines:
#
CONFIG_MACH_IMX51_DT=y
# CONFIG_MACH_MX51_BABBAGE is not set
# CONFIG_MACH_EUKREA_CPUIMX51SD is not set

#
# Device tree only
#
CONFIG_SOC_IMX53=y
CONFIG_SOC_IMX6Q=y
CONFIG_IMX_HAVE_PLATFORM_FEC=y
CONFIG_IMX_HAVE_PLATFORM_FLEXCAN=y
CONFIG_IMX_HAVE_PLATFORM_FSL_USB2_UDC=y
CONFIG_IMX_HAVE_PLATFORM_GPIO_KEYS=y
CONFIG_IMX_HAVE_PLATFORM_IMX2_WDT=y
CONFIG_IMX_HAVE_PLATFORM_IMX_I2C=y
CONFIG_IMX_HAVE_PLATFORM_IMX_KEYPAD=y
CONFIG_IMX_HAVE_PLATFORM_IMX_SSI=y
CONFIG_IMX_HAVE_PLATFORM_IMX_UART=y
CONFIG_IMX_HAVE_PLATFORM_IPU_CORE=y
CONFIG_IMX_HAVE_PLATFORM_MXC_EHCI=y
CONFIG_IMX_HAVE_PLATFORM_MXC_MMC=y
CONFIG_IMX_HAVE_PLATFORM_MXC_NAND=y
CONFIG_IMX_HAVE_PLATFORM_MXC_RNGA=y
CONFIG_IMX_HAVE_PLATFORM_MXC_RTC=y
CONFIG_IMX_HAVE_PLATFORM_MXC_W1=y
CONFIG_IMX_HAVE_PLATFORM_SDHCI_ESDHC_IMX=y
CONFIG_IMX_HAVE_PLATFORM_SPI_IMX=y

#
# TI OMAP Common Features
#

#
# OMAP Feature Selections
#
CONFIG_POWER_AVS_OMAP=y
# CONFIG_OMAP_RESET_CLOCKS is not set
CONFIG_OMAP_MUX=y
CONFIG_OMAP_MUX_DEBUG=y
CONFIG_OMAP_MUX_WARNINGS=y
CONFIG_OMAP_32K_TIMER=y
# CONFIG_OMAP3_L2_AUX_SECURE_SAVE_RESTORE is not set
CONFIG_OMAP_DM_TIMER=y
CONFIG_OMAP_PM_NOOP=y
# CONFIG_MACH_OMAP_GENERIC is not set
CONFIG_ARCH_OMAP=y
CONFIG_ARCH_OMAP2PLUS=y

#
# TI OMAP2/3/4 Specific Features
#
# CONFIG_ARCH_OMAP2PLUS_TYPICAL is not set
CONFIG_SOC_HAS_OMAP2_SDRC=y
CONFIG_ARCH_OMAP2=y
CONFIG_ARCH_OMAP3=y
CONFIG_ARCH_OMAP4=y
# CONFIG_SOC_OMAP5 is not set

#
# OMAP Core Type
#
# CONFIG_SOC_OMAP2420 is not set
CONFIG_SOC_OMAP2430=y
# CONFIG_SOC_OMAP3430 is not set
CONFIG_SOC_TI81XX=y
CONFIG_SOC_AM33XX=y
CONFIG_OMAP_PACKAGE_CBB=y
CONFIG_OMAP_PACKAGE_CUS=y
CONFIG_OMAP_PACKAGE_CBP=y

#
# OMAP Board Type
#
# CONFIG_MACH_OMAP_2430SDP is not set
# CONFIG_MACH_OMAP3_BEAGLE is not set
CONFIG_MACH_DEVKIT8000=y
CONFIG_MACH_OMAP_LDP=y
CONFIG_MACH_OMAP3530_LV_SOM=y
CONFIG_MACH_OMAP3_TORPEDO=y
# CONFIG_MACH_OVERO is not set
CONFIG_MACH_OMAP3EVM=y
# CONFIG_MACH_OMAP3517EVM is not set
CONFIG_MACH_CRANEBOARD=y
CONFIG_MACH_OMAP3_PANDORA=y
CONFIG_MACH_TOUCHBOOK=y
# CONFIG_MACH_OMAP_3430SDP is not set
CONFIG_MACH_NOKIA_RM680=y
# CONFIG_MACH_NOKIA_RX51 is not set
# CONFIG_MACH_OMAP_ZOOM2 is not set
CONFIG_MACH_OMAP_ZOOM3=y
# CONFIG_MACH_CM_T35 is not set
CONFIG_MACH_CM_T3517=y
CONFIG_MACH_IGEP0020=y
# CONFIG_MACH_IGEP0030 is not set
# CONFIG_MACH_SBC3530 is not set
CONFIG_MACH_OMAP_3630SDP=y
CONFIG_MACH_TI8168EVM=y
# CONFIG_MACH_TI8148EVM is not set
# CONFIG_MACH_OMAP_4430SDP is not set
# CONFIG_MACH_OMAP4_PANDA is not set
# CONFIG_OMAP3_EMU is not set
CONFIG_OMAP3_SDRC_AC_TIMING=y
# CONFIG_ARCH_PICOXCELL is not set
CONFIG_ARCH_SOCFPGA=y
# CONFIG_PLAT_SPEAR is not set
# CONFIG_ARCH_SUNXI is not set
# CONFIG_ARCH_SIRF is not set
# CONFIG_ARCH_TEGRA is not set
# CONFIG_ARCH_U8500 is not set
CONFIG_ARCH_VEXPRESS=y

#
# Versatile Express platform type
#
# CONFIG_ARCH_VEXPRESS_CORTEX_A5_A9_ERRATA is not set
# CONFIG_ARCH_VEXPRESS_CA9X4 is not set
CONFIG_PLAT_VERSATILE_CLCD=y
CONFIG_PLAT_VERSATILE_SCHED_CLOCK=y
CONFIG_ARCH_VIRT=y
CONFIG_ARCH_VT8500=y
CONFIG_ARCH_WM8750=y
CONFIG_ARCH_WM8850=y
CONFIG_ARCH_ZYNQ=y
CONFIG_PLAT_ORION=y
CONFIG_PLAT_VERSATILE=y
CONFIG_ARM_TIMER_SP804=y

#
# Processor Type
#
CONFIG_CPU_PJ4B=y
CONFIG_CPU_V6=y
CONFIG_CPU_V6K=y
CONFIG_CPU_V7=y
CONFIG_CPU_32v6=y
CONFIG_CPU_32v6K=y
CONFIG_CPU_32v7=y
CONFIG_CPU_ABRT_EV6=y
CONFIG_CPU_ABRT_EV7=y
CONFIG_CPU_PABRT_V6=y
CONFIG_CPU_PABRT_V7=y
CONFIG_CPU_CACHE_V6=y
CONFIG_CPU_CACHE_V7=y
CONFIG_CPU_CACHE_VIPT=y
CONFIG_CPU_COPY_V6=y
CONFIG_CPU_TLB_V6=y
CONFIG_CPU_TLB_V7=y
CONFIG_CPU_HAS_ASID=y
CONFIG_CPU_CP15=y
CONFIG_CPU_CP15_MMU=y
CONFIG_CPU_USE_DOMAINS=y

#
# Processor Features
#
# CONFIG_ARCH_PHYS_ADDR_T_64BIT is not set
CONFIG_ARM_THUMB=y
# CONFIG_ARM_THUMBEE is not set
CONFIG_ARM_VIRT_EXT=y
# CONFIG_CPU_ICACHE_DISABLE is not set
# CONFIG_CPU_DCACHE_DISABLE is not set
CONFIG_CPU_BPREDICT_DISABLE=y
CONFIG_DMA_CACHE_RWFO=y
CONFIG_OUTER_CACHE=y
CONFIG_OUTER_CACHE_SYNC=y
CONFIG_MIGHT_HAVE_CACHE_L2X0=y
CONFIG_CACHE_L2X0=y
CONFIG_ARM_L1_CACHE_SHIFT_6=y
CONFIG_ARM_L1_CACHE_SHIFT=6
CONFIG_ARM_DMA_MEM_BUFFERABLE=y
CONFIG_ARM_NR_BANKS=8
CONFIG_MULTI_IRQ_HANDLER=y
CONFIG_ARM_ERRATA_326103=y
CONFIG_ARM_ERRATA_411920=y
# CONFIG_ARM_ERRATA_430973 is not set
CONFIG_PL310_ERRATA_588369=y
CONFIG_ARM_ERRATA_720789=y
CONFIG_PL310_ERRATA_727915=y
CONFIG_ARM_ERRATA_754322=y
CONFIG_ARM_ERRATA_754327=y
CONFIG_ARM_ERRATA_764369=y
# CONFIG_PL310_ERRATA_769419 is not set
CONFIG_ARM_ERRATA_775420=y
CONFIG_ARM_ERRATA_798181=y
CONFIG_ICST=y

#
# Bus support
#
CONFIG_ARM_AMBA=y
# CONFIG_PCI_SYSCALL is not set
# CONFIG_PCCARD is not set

#
# Kernel Features
#
CONFIG_HAVE_SMP=y
CONFIG_SMP=y
CONFIG_SMP_ON_UP=y
# CONFIG_ARM_CPU_TOPOLOGY is not set
CONFIG_HAVE_ARM_SCU=y
CONFIG_HAVE_ARM_ARCH_TIMER=y
CONFIG_HAVE_ARM_TWD=y
CONFIG_VMSPLIT_3G=y
# CONFIG_VMSPLIT_2G is not set
# CONFIG_VMSPLIT_1G is not set
CONFIG_PAGE_OFFSET=0xC0000000
CONFIG_NR_CPUS=4
# CONFIG_HOTPLUG_CPU is not set
CONFIG_ARM_PSCI=y
CONFIG_LOCAL_TIMERS=y
CONFIG_ARCH_NR_GPIO=352
CONFIG_PREEMPT_NONE=y
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT is not set
CONFIG_HZ=100
# CONFIG_SCHED_HRTICK is not set
# CONFIG_AEABI is not set
CONFIG_ARCH_HAS_HOLES_MEMORYMODEL=y
# CONFIG_ARCH_SPARSEMEM_DEFAULT is not set
# CONFIG_ARCH_SELECT_MEMORY_MODEL is not set
CONFIG_HAVE_ARCH_PFN_VALID=y
CONFIG_HIGHMEM=y
CONFIG_HIGHPTE=y
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
CONFIG_HAVE_MEMBLOCK=y
# CONFIG_HAVE_BOOTMEM_INFO_NODE is not set
CONFIG_PAGEFLAGS_EXTENDED=y
CONFIG_SPLIT_PTLOCK_CPUS=4
# CONFIG_COMPACTION is not set
# CONFIG_PHYS_ADDR_T_64BIT is not set
CONFIG_ZONE_DMA_FLAG=0
CONFIG_BOUNCE=y
CONFIG_KSM=y
CONFIG_DEFAULT_MMAP_MIN_ADDR=4096
# CONFIG_CROSS_MEMORY_ATTACH is not set
# CONFIG_CLEANCACHE is not set
CONFIG_FRONTSWAP=y
CONFIG_FORCE_MAX_ZONEORDER=12
CONFIG_ALIGNMENT_TRAP=y
CONFIG_UACCESS_WITH_MEMCPY=y
CONFIG_SECCOMP=y
# CONFIG_CC_STACKPROTECTOR is not set

#
# Boot options
#
CONFIG_USE_OF=y
CONFIG_ATAGS=y
# CONFIG_DEPRECATED_PARAM_STRUCT is not set
CONFIG_ZBOOT_ROM_TEXT=0
CONFIG_ZBOOT_ROM_BSS=0
CONFIG_ARM_APPENDED_DTB=y
CONFIG_ARM_ATAG_DTB_COMPAT=y
CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER=y
# CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND is not set
CONFIG_CMDLINE=""
CONFIG_CRASH_DUMP=y
CONFIG_AUTO_ZRELADDR=y

#
# CPU Power Management
#

#
# CPU Frequency scaling
#
# CONFIG_CPU_FREQ is not set
CONFIG_CPU_IDLE=y
# CONFIG_CPU_IDLE_MULTIPLE_DRIVERS is not set
CONFIG_CPU_IDLE_GOV_LADDER=y
CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED=y
# CONFIG_CPU_IDLE_CALXEDA is not set

#
# Floating point emulation
#

#
# At least one emulation must be selected
#
# CONFIG_FPE_NWFPE is not set
# CONFIG_FPE_FASTFPE is not set
CONFIG_VFP=y
CONFIG_VFPv3=y
CONFIG_NEON=y

#
# Userspace binary formats
#
# CONFIG_BINFMT_ELF is not set
CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE=y
CONFIG_BINFMT_SCRIPT=m
CONFIG_HAVE_AOUT=y
# CONFIG_BINFMT_AOUT is not set
# CONFIG_BINFMT_MISC is not set
CONFIG_COREDUMP=y
CONFIG_ARTHUR=m

#
# Power management options
#
# CONFIG_SUSPEND is not set
CONFIG_PM_RUNTIME=y
CONFIG_PM=y
# CONFIG_PM_DEBUG is not set
# CONFIG_APM_EMULATION is not set
CONFIG_ARCH_HAS_OPP=y
CONFIG_PM_OPP=y
CONFIG_PM_CLK=y
CONFIG_CPU_PM=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARM_CPU_SUSPEND=y
# CONFIG_NET is not set
CONFIG_HAVE_BPF_JIT=y

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_UEVENT_HELPER_PATH=""
CONFIG_DEVTMPFS=y
# CONFIG_DEVTMPFS_MOUNT is not set
# CONFIG_STANDALONE is not set
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
CONFIG_FIRMWARE_IN_KERNEL=y
CONFIG_EXTRA_FIRMWARE=""
# CONFIG_FW_LOADER_USER_HELPER is not set
# CONFIG_SYS_HYPERVISOR is not set
# CONFIG_GENERIC_CPU_DEVICES is not set
CONFIG_SOC_BUS=y
CONFIG_REGMAP=y
CONFIG_REGMAP_I2C=m
CONFIG_REGMAP_SPI=y
CONFIG_REGMAP_MMIO=y
CONFIG_REGMAP_IRQ=y
# CONFIG_DMA_SHARED_BUFFER is not set
# CONFIG_CMA is not set

#
# Bus devices
#
# CONFIG_OMAP_OCP2SCP is not set
CONFIG_OMAP_INTERCONNECT=y
# CONFIG_MTD is not set
CONFIG_DTC=y
CONFIG_OF=y

#
# Device Tree and Open Firmware support
#
CONFIG_PROC_DEVICETREE=y
# CONFIG_OF_SELFTEST is not set
CONFIG_OF_FLATTREE=y
CONFIG_OF_EARLY_FLATTREE=y
CONFIG_OF_ADDRESS=y
CONFIG_OF_IRQ=y
CONFIG_OF_DEVICE=y
CONFIG_OF_I2C=m
CONFIG_PARPORT=m
# CONFIG_PARPORT_PC is not set
# CONFIG_PARPORT_GSC is not set
CONFIG_PARPORT_AX88796=m
CONFIG_PARPORT_1284=y
CONFIG_PARPORT_NOT_PC=y
CONFIG_BLK_DEV=y
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=m
CONFIG_BLK_DEV_LOOP_MIN_COUNT=8
# CONFIG_BLK_DEV_CRYPTOLOOP is not set

#
# DRBD disabled because PROC_FS or INET not selected
#
CONFIG_BLK_DEV_RAM=m
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=4096
# CONFIG_BLK_DEV_XIP is not set
CONFIG_CDROM_PKTCDVD=m
CONFIG_CDROM_PKTCDVD_BUFFERS=8
# CONFIG_CDROM_PKTCDVD_WCACHE is not set
# CONFIG_MG_DISK is not set
CONFIG_VIRTIO_BLK=m
# CONFIG_BLOCKCONSOLE is not set

#
# Misc devices
#
CONFIG_SENSORS_LIS3LV02D=m
CONFIG_AD525X_DPOT=m
CONFIG_AD525X_DPOT_I2C=m
# CONFIG_AD525X_DPOT_SPI is not set
# CONFIG_ATMEL_PWM is not set
CONFIG_DUMMY_IRQ=m
CONFIG_ICS932S401=m
# CONFIG_ATMEL_SSC is not set
# CONFIG_ENCLOSURE_SERVICES is not set
# CONFIG_APDS9802ALS is not set
CONFIG_ISL29003=m
# CONFIG_ISL29020 is not set
# CONFIG_SENSORS_TSL2550 is not set
# CONFIG_SENSORS_BH1780 is not set
CONFIG_SENSORS_BH1770=m
# CONFIG_SENSORS_APDS990X is not set
# CONFIG_HMC6352 is not set
CONFIG_DS1682=m
# CONFIG_TI_DAC7512 is not set
CONFIG_ARM_CHARLCD=y
CONFIG_BMP085=y
CONFIG_BMP085_I2C=m
CONFIG_BMP085_SPI=m
# CONFIG_USB_SWITCH_FSA9480 is not set
CONFIG_LATTICE_ECP3_CONFIG=m
# CONFIG_SRAM is not set
CONFIG_C2PORT=m

#
# EEPROM support
#
# CONFIG_EEPROM_AT24 is not set
CONFIG_EEPROM_AT25=m
CONFIG_EEPROM_LEGACY=m
CONFIG_EEPROM_MAX6875=m
CONFIG_EEPROM_93CX6=m
# CONFIG_EEPROM_93XX46 is not set

#
# Texas Instruments shared transport line discipline
#
# CONFIG_SENSORS_LIS3_SPI is not set
CONFIG_SENSORS_LIS3_I2C=m

#
# Altera FPGA firmware download module
#
CONFIG_ALTERA_STAPL=m

#
# SCSI device support
#
CONFIG_SCSI_MOD=m
# CONFIG_RAID_ATTRS is not set
CONFIG_SCSI=m
CONFIG_SCSI_DMA=y
# CONFIG_SCSI_TGT is not set
# CONFIG_SCSI_NETLINK is not set
CONFIG_SCSI_PROC_FS=y

#
# SCSI support type (disk, tape, CD-ROM)
#
# CONFIG_BLK_DEV_SD is not set
# CONFIG_CHR_DEV_ST is not set
CONFIG_CHR_DEV_OSST=m
# CONFIG_BLK_DEV_SR is not set
CONFIG_CHR_DEV_SG=m
CONFIG_CHR_DEV_SCH=m
CONFIG_SCSI_MULTI_LUN=y
CONFIG_SCSI_CONSTANTS=y
CONFIG_SCSI_LOGGING=y
CONFIG_SCSI_SCAN_ASYNC=y

#
# SCSI Transports
#
# CONFIG_SCSI_SPI_ATTRS is not set
# CONFIG_SCSI_FC_ATTRS is not set
CONFIG_SCSI_SAS_ATTRS=m
# CONFIG_SCSI_SAS_LIBSAS is not set
# CONFIG_SCSI_SRP_ATTRS is not set
# CONFIG_SCSI_LOWLEVEL is not set
CONFIG_SCSI_DH=m
CONFIG_SCSI_DH_RDAC=m
CONFIG_SCSI_DH_HP_SW=m
CONFIG_SCSI_DH_EMC=m
CONFIG_SCSI_DH_ALUA=m
# CONFIG_SCSI_OSD_INITIATOR is not set
CONFIG_HAVE_PATA_PLATFORM=y
CONFIG_ATA=m
# CONFIG_ATA_NONSTANDARD is not set
CONFIG_ATA_VERBOSE_ERROR=y
# CONFIG_SATA_PMP is not set

#
# Controllers with non-SFF native interface
#
# CONFIG_SATA_AHCI_PLATFORM is not set
# CONFIG_ATA_SFF is not set
CONFIG_MD=y
CONFIG_BLK_DEV_MD=m
# CONFIG_MD_LINEAR is not set
CONFIG_MD_RAID0=m
CONFIG_MD_RAID1=m
CONFIG_MD_RAID10=m
CONFIG_MD_RAID456=m
CONFIG_MD_MULTIPATH=m
# CONFIG_MD_FAULTY is not set
CONFIG_BCACHE=m
# CONFIG_BCACHE_DEBUG is not set
# CONFIG_BCACHE_EDEBUG is not set
CONFIG_BCACHE_CLOSURES_DEBUG=y
CONFIG_BLK_DEV_DM=m
# CONFIG_DM_DEBUG is not set
CONFIG_DM_BUFIO=m
CONFIG_DM_BIO_PRISON=m
CONFIG_DM_PERSISTENT_DATA=m
# CONFIG_DM_CRYPT is not set
CONFIG_DM_SNAPSHOT=m
# CONFIG_DM_THIN_PROVISIONING is not set
CONFIG_DM_CACHE=m
# CONFIG_DM_CACHE_MQ is not set
# CONFIG_DM_CACHE_CLEANER is not set
CONFIG_DM_MIRROR=m
# CONFIG_DM_RAID is not set
# CONFIG_DM_ZERO is not set
CONFIG_DM_MULTIPATH=m
CONFIG_DM_MULTIPATH_QL=m
# CONFIG_DM_MULTIPATH_ST is not set
# CONFIG_DM_DELAY is not set
CONFIG_DM_UEVENT=y
CONFIG_DM_FLAKEY=m
# CONFIG_DM_VERITY is not set
# CONFIG_TARGET_CORE is not set

#
# Input device support
#
CONFIG_INPUT=y
CONFIG_INPUT_FF_MEMLESS=m
CONFIG_INPUT_POLLDEV=m
# CONFIG_INPUT_SPARSEKMAP is not set
CONFIG_INPUT_MATRIXKMAP=m

#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
CONFIG_INPUT_JOYDEV=m
# CONFIG_INPUT_EVDEV is not set
# CONFIG_INPUT_EVBUG is not set

#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
# CONFIG_KEYBOARD_ADP5588 is not set
CONFIG_KEYBOARD_ADP5589=m
CONFIG_KEYBOARD_ATKBD=m
# CONFIG_KEYBOARD_QT1070 is not set
CONFIG_KEYBOARD_QT2160=m
CONFIG_KEYBOARD_LKKBD=m
# CONFIG_KEYBOARD_GPIO is not set
# CONFIG_KEYBOARD_TCA6416 is not set
CONFIG_KEYBOARD_TCA8418=m
CONFIG_KEYBOARD_MATRIX=m
# CONFIG_KEYBOARD_LM8333 is not set
# CONFIG_KEYBOARD_MAX7359 is not set
CONFIG_KEYBOARD_MCS=m
CONFIG_KEYBOARD_MPR121=m
# CONFIG_KEYBOARD_IMX is not set
CONFIG_KEYBOARD_NEWTON=m
CONFIG_KEYBOARD_OPENCORES=m
# CONFIG_KEYBOARD_SAMSUNG is not set
# CONFIG_KEYBOARD_STOWAWAY is not set
# CONFIG_KEYBOARD_SUNKBD is not set
CONFIG_KEYBOARD_OMAP4=m
CONFIG_KEYBOARD_XTKBD=m
CONFIG_KEYBOARD_CROS_EC=m
# CONFIG_INPUT_MOUSE is not set
CONFIG_INPUT_JOYSTICK=y
CONFIG_JOYSTICK_ANALOG=m
# CONFIG_JOYSTICK_A3D is not set
# CONFIG_JOYSTICK_ADI is not set
# CONFIG_JOYSTICK_COBRA is not set
CONFIG_JOYSTICK_GF2K=m
CONFIG_JOYSTICK_GRIP=m
# CONFIG_JOYSTICK_GRIP_MP is not set
# CONFIG_JOYSTICK_GUILLEMOT is not set
# CONFIG_JOYSTICK_INTERACT is not set
# CONFIG_JOYSTICK_SIDEWINDER is not set
CONFIG_JOYSTICK_TMDC=m
CONFIG_JOYSTICK_IFORCE=m
# CONFIG_JOYSTICK_IFORCE_USB is not set
# CONFIG_JOYSTICK_IFORCE_232 is not set
# CONFIG_JOYSTICK_WARRIOR is not set
CONFIG_JOYSTICK_MAGELLAN=m
CONFIG_JOYSTICK_SPACEORB=m
# CONFIG_JOYSTICK_SPACEBALL is not set
CONFIG_JOYSTICK_STINGER=m
# CONFIG_JOYSTICK_TWIDJOY is not set
CONFIG_JOYSTICK_ZHENHUA=m
CONFIG_JOYSTICK_DB9=m
# CONFIG_JOYSTICK_GAMECON is not set
# CONFIG_JOYSTICK_TURBOGRAFX is not set
# CONFIG_JOYSTICK_AS5011 is not set
# CONFIG_JOYSTICK_JOYDUMP is not set
CONFIG_JOYSTICK_XPAD=m
# CONFIG_JOYSTICK_XPAD_FF is not set
# CONFIG_INPUT_TABLET is not set
CONFIG_INPUT_TOUCHSCREEN=y
# CONFIG_TOUCHSCREEN_ADS7846 is not set
# CONFIG_TOUCHSCREEN_AD7877 is not set
CONFIG_TOUCHSCREEN_AD7879=m
CONFIG_TOUCHSCREEN_AD7879_I2C=m
# CONFIG_TOUCHSCREEN_AD7879_SPI is not set
# CONFIG_TOUCHSCREEN_ATMEL_MXT is not set
# CONFIG_TOUCHSCREEN_AUO_PIXCIR is not set
CONFIG_TOUCHSCREEN_BU21013=m
CONFIG_TOUCHSCREEN_CY8CTMG110=m
# CONFIG_TOUCHSCREEN_CYTTSP_CORE is not set
CONFIG_TOUCHSCREEN_DYNAPRO=m
# CONFIG_TOUCHSCREEN_HAMPSHIRE is not set
# CONFIG_TOUCHSCREEN_EETI is not set
CONFIG_TOUCHSCREEN_EGALAX=m
# CONFIG_TOUCHSCREEN_FUJITSU is not set
CONFIG_TOUCHSCREEN_ILI210X=m
CONFIG_TOUCHSCREEN_GUNZE=m
CONFIG_TOUCHSCREEN_ELO=m
# CONFIG_TOUCHSCREEN_WACOM_W8001 is not set
CONFIG_TOUCHSCREEN_WACOM_I2C=m
# CONFIG_TOUCHSCREEN_MAX11801 is not set
CONFIG_TOUCHSCREEN_MCS5000=m
# CONFIG_TOUCHSCREEN_MMS114 is not set
# CONFIG_TOUCHSCREEN_MTOUCH is not set
# CONFIG_TOUCHSCREEN_INEXIO is not set
# CONFIG_TOUCHSCREEN_MK712 is not set
# CONFIG_TOUCHSCREEN_PENMOUNT is not set
CONFIG_TOUCHSCREEN_EDT_FT5X06=m
CONFIG_TOUCHSCREEN_TOUCHRIGHT=m
CONFIG_TOUCHSCREEN_TOUCHWIN=m
CONFIG_TOUCHSCREEN_TI_AM335X_TSC=m
CONFIG_TOUCHSCREEN_PIXCIR=m
# CONFIG_TOUCHSCREEN_USB_COMPOSITE is not set
# CONFIG_TOUCHSCREEN_TOUCHIT213 is not set
# CONFIG_TOUCHSCREEN_TSC_SERIO is not set
CONFIG_TOUCHSCREEN_TSC2005=m
# CONFIG_TOUCHSCREEN_TSC2007 is not set
# CONFIG_TOUCHSCREEN_W90X900 is not set
# CONFIG_TOUCHSCREEN_ST1232 is not set
CONFIG_TOUCHSCREEN_TPS6507X=m
CONFIG_INPUT_MISC=y
# CONFIG_INPUT_AD714X is not set
# CONFIG_INPUT_BMA150 is not set
# CONFIG_INPUT_MMA8450 is not set
# CONFIG_INPUT_MPU3050 is not set
# CONFIG_INPUT_GP2A is not set
CONFIG_INPUT_GPIO_TILT_POLLED=m
CONFIG_INPUT_ATI_REMOTE2=m
# CONFIG_INPUT_KEYSPAN_REMOTE is not set
CONFIG_INPUT_KXTJ9=m
# CONFIG_INPUT_KXTJ9_POLLED_MODE is not set
# CONFIG_INPUT_POWERMATE is not set
# CONFIG_INPUT_YEALINK is not set
# CONFIG_INPUT_CM109 is not set
CONFIG_INPUT_UINPUT=m
# CONFIG_INPUT_PCF50633_PMU is not set
CONFIG_INPUT_PCF8574=m
CONFIG_INPUT_GPIO_ROTARY_ENCODER=m
CONFIG_INPUT_ADXL34X=m
CONFIG_INPUT_ADXL34X_I2C=m
CONFIG_INPUT_ADXL34X_SPI=m
# CONFIG_INPUT_CMA3000 is not set

#
# Hardware I/O ports
#
CONFIG_SERIO=m
# CONFIG_SERIO_SERPORT is not set
CONFIG_SERIO_PARKBD=m
# CONFIG_SERIO_AMBAKMI is not set
CONFIG_SERIO_LIBPS2=m
CONFIG_SERIO_RAW=m
CONFIG_SERIO_ALTERA_PS2=m
# CONFIG_SERIO_PS2MULT is not set
# CONFIG_SERIO_ARC_PS2 is not set
CONFIG_SERIO_APBPS2=m
CONFIG_GAMEPORT=m
CONFIG_GAMEPORT_NS558=m
CONFIG_GAMEPORT_L4=m

#
# Character devices
#
CONFIG_TTY=y
CONFIG_VT=y
CONFIG_CONSOLE_TRANSLATIONS=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
CONFIG_VT_HW_CONSOLE_BINDING=y
CONFIG_UNIX98_PTYS=y
# CONFIG_DEVPTS_MULTIPLE_INSTANCES is not set
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256
# CONFIG_SERIAL_NONSTANDARD is not set
# CONFIG_TRACE_SINK is not set
# CONFIG_DEVKMEM is not set

#
# Serial drivers
#
# CONFIG_SERIAL_8250 is not set

#
# Non-8250 serial port support
#
# CONFIG_SERIAL_AMBA_PL010 is not set
# CONFIG_SERIAL_AMBA_PL011 is not set
CONFIG_SERIAL_MAX3100=m
CONFIG_SERIAL_MAX310X=y
# CONFIG_SERIAL_IMX is not set
CONFIG_SERIAL_CORE=y
# CONFIG_SERIAL_VT8500 is not set
CONFIG_SERIAL_OMAP=m
CONFIG_SERIAL_SCCNXP=m
# CONFIG_SERIAL_TIMBERDALE is not set
CONFIG_SERIAL_ALTERA_JTAGUART=m
CONFIG_SERIAL_ALTERA_UART=m
CONFIG_SERIAL_ALTERA_UART_MAXPORTS=4
CONFIG_SERIAL_ALTERA_UART_BAUDRATE=115200
CONFIG_SERIAL_IFX6X60=m
CONFIG_SERIAL_XILINX_PS_UART=m
# CONFIG_SERIAL_ARC is not set
CONFIG_PRINTER=m
# CONFIG_LP_CONSOLE is not set
# CONFIG_PPDEV is not set
CONFIG_HVC_DRIVER=y
# CONFIG_HVC_DCC is not set
CONFIG_VIRTIO_CONSOLE=m
CONFIG_IPMI_HANDLER=m
# CONFIG_IPMI_PANIC_EVENT is not set
# CONFIG_IPMI_DEVICE_INTERFACE is not set
CONFIG_IPMI_SI=m
# CONFIG_IPMI_WATCHDOG is not set
CONFIG_IPMI_POWEROFF=m
# CONFIG_HW_RANDOM is not set
# CONFIG_NVRAM is not set
# CONFIG_R3964 is not set
# CONFIG_RAW_DRIVER is not set
CONFIG_TCG_TPM=y
# CONFIG_TCG_TIS_I2C_INFINEON is not set
# CONFIG_TCG_ST33_I2C is not set
CONFIG_I2C=m
CONFIG_I2C_BOARDINFO=y
# CONFIG_I2C_COMPAT is not set
CONFIG_I2C_CHARDEV=m
# CONFIG_I2C_MUX is not set
CONFIG_I2C_HELPER_AUTO=y
CONFIG_I2C_SMBUS=m
CONFIG_I2C_ALGOBIT=m

#
# I2C Hardware Bus support
#

#
# I2C system bus drivers (mostly embedded / system-on-chip)
#
CONFIG_I2C_CBUS_GPIO=m
# CONFIG_I2C_DESIGNWARE_PLATFORM is not set
# CONFIG_I2C_GPIO is not set
CONFIG_I2C_IMX=m
CONFIG_I2C_MV64XXX=m
CONFIG_I2C_NOMADIK=m
# CONFIG_I2C_OCORES is not set
CONFIG_I2C_OMAP=m
# CONFIG_I2C_PCA_PLATFORM is not set
# CONFIG_I2C_PXA_PCI is not set
CONFIG_I2C_SIMTEC=m
# CONFIG_I2C_VERSATILE is not set
# CONFIG_I2C_XILINX is not set

#
# External I2C/SMBus adapter drivers
#
# CONFIG_I2C_DIOLAN_U2C is not set
CONFIG_I2C_PARPORT=m
CONFIG_I2C_PARPORT_LIGHT=m
# CONFIG_I2C_TAOS_EVM is not set
CONFIG_I2C_TINY_USB=m
# CONFIG_I2C_VIPERBOARD is not set

#
# Other I2C/SMBus bus drivers
#
# CONFIG_I2C_STUB is not set
# CONFIG_I2C_DEBUG_CORE is not set
CONFIG_I2C_DEBUG_ALGO=y
CONFIG_I2C_DEBUG_BUS=y
CONFIG_SPI=y
CONFIG_SPI_MASTER=y

#
# SPI Master Controller Drivers
#
CONFIG_SPI_ALTERA=m
CONFIG_SPI_BITBANG=m
CONFIG_SPI_BUTTERFLY=m
CONFIG_SPI_GPIO=m
CONFIG_SPI_IMX=m
CONFIG_SPI_LM70_LLP=m
CONFIG_SPI_FSL_LIB=y
CONFIG_SPI_FSL_SPI=y
# CONFIG_SPI_OC_TINY is not set
CONFIG_SPI_OMAP24XX=m
# CONFIG_SPI_ORION is not set
# CONFIG_SPI_PL022 is not set
# CONFIG_SPI_PXA2XX_PCI is not set
CONFIG_SPI_SC18IS602=m
CONFIG_SPI_XCOMM=m
CONFIG_SPI_XILINX=m
# CONFIG_SPI_DESIGNWARE is not set

#
# SPI Protocol Masters
#
# CONFIG_SPI_SPIDEV is not set
# CONFIG_SPI_TLE62X0 is not set

#
# Qualcomm MSM SSBI bus support
#
CONFIG_SSBI=m
# CONFIG_HSI is not set

#
# PPS support
#
CONFIG_PPS=m
# CONFIG_PPS_DEBUG is not set
CONFIG_NTP_PPS=y

#
# PPS clients support
#
CONFIG_PPS_CLIENT_KTIMER=m
# CONFIG_PPS_CLIENT_LDISC is not set
# CONFIG_PPS_CLIENT_PARPORT is not set
CONFIG_PPS_CLIENT_GPIO=m

#
# PPS generators support
#

#
# PTP clock support
#
CONFIG_PTP_1588_CLOCK=m

#
# Enable PHYLIB and NETWORK_PHY_TIMESTAMPING to see the additional clocks.
#
# CONFIG_PTP_1588_CLOCK_PCH is not set
CONFIG_PINCTRL=y

#
# Pin controllers
#
CONFIG_PINMUX=y
CONFIG_PINCONF=y
CONFIG_GENERIC_PINCONF=y
CONFIG_PINCTRL_IMX=y
# CONFIG_PINCTRL_IMX35 is not set
CONFIG_PINCTRL_IMX51=y
CONFIG_PINCTRL_IMX53=y
CONFIG_PINCTRL_IMX6Q=y
CONFIG_PINCTRL_SINGLE=m
# CONFIG_PINCTRL_EXYNOS is not set
# CONFIG_PINCTRL_EXYNOS5440 is not set
CONFIG_PINCTRL_MVEBU=y
CONFIG_PINCTRL_ARMADA_XP=y
CONFIG_PINCTRL_WMT=y
CONFIG_PINCTRL_WM8750=y
# CONFIG_PINCTRL_WM8850 is not set
CONFIG_ARCH_HAVE_CUSTOM_GPIO_H=y
CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y
CONFIG_ARCH_REQUIRE_GPIOLIB=y
CONFIG_GPIO_DEVRES=y
CONFIG_GPIOLIB=y
CONFIG_OF_GPIO=y
# CONFIG_GPIO_SYSFS is not set
CONFIG_GPIO_GENERIC=y
CONFIG_GPIO_MAX730X=m

#
# Memory mapped GPIO drivers:
#
CONFIG_GPIO_GENERIC_PLATFORM=m
CONFIG_GPIO_EM=m
CONFIG_GPIO_MVEBU=y
CONFIG_GPIO_MXC=y
CONFIG_GPIO_PL061=y
# CONFIG_GPIO_RCAR is not set
# CONFIG_GPIO_TS5500 is not set

#
# I2C GPIO expanders:
#
CONFIG_GPIO_ARIZONA=m
CONFIG_GPIO_MAX7300=m
CONFIG_GPIO_MAX732X=m
CONFIG_GPIO_PCF857X=m
CONFIG_GPIO_TPS65912=m
# CONFIG_GPIO_ADP5588 is not set
CONFIG_GPIO_ADNP=m

#
# PCI GPIO expanders:
#

#
# SPI GPIO expanders:
#
CONFIG_GPIO_MAX7301=m
CONFIG_GPIO_MCP23S08=m
CONFIG_GPIO_MC33880=m
CONFIG_GPIO_74X164=m

#
# AC97 GPIO expanders:
#

#
# MODULbus GPIO expanders:
#

#
# USB GPIO expanders:
#
# CONFIG_GPIO_VIPERBOARD is not set
CONFIG_W1=m

#
# 1-wire Bus Masters
#
CONFIG_W1_MASTER_DS2490=m
CONFIG_W1_MASTER_DS2482=m
CONFIG_W1_MASTER_MXC=m
CONFIG_W1_MASTER_DS1WM=m
# CONFIG_W1_MASTER_GPIO is not set
# CONFIG_HDQ_MASTER_OMAP is not set

#
# 1-wire Slaves
#
# CONFIG_W1_SLAVE_THERM is not set
CONFIG_W1_SLAVE_SMEM=m
# CONFIG_W1_SLAVE_DS2408 is not set
CONFIG_W1_SLAVE_DS2413=m
CONFIG_W1_SLAVE_DS2423=m
# CONFIG_W1_SLAVE_DS2431 is not set
# CONFIG_W1_SLAVE_DS2433 is not set
# CONFIG_W1_SLAVE_DS2760 is not set
CONFIG_W1_SLAVE_DS2780=m
CONFIG_W1_SLAVE_DS2781=m
# CONFIG_W1_SLAVE_DS28E04 is not set
CONFIG_W1_SLAVE_BQ27000=m
CONFIG_POWER_SUPPLY=y
# CONFIG_POWER_SUPPLY_DEBUG is not set
CONFIG_PDA_POWER=m
CONFIG_TEST_POWER=m
CONFIG_BATTERY_DS2780=m
CONFIG_BATTERY_DS2781=m
# CONFIG_BATTERY_DS2782 is not set
CONFIG_BATTERY_SBS=m
CONFIG_BATTERY_BQ27x00=m
# CONFIG_BATTERY_BQ27X00_I2C is not set
# CONFIG_BATTERY_BQ27X00_PLATFORM is not set
# CONFIG_BATTERY_MAX17040 is not set
# CONFIG_BATTERY_MAX17042 is not set
# CONFIG_CHARGER_PCF50633 is not set
CONFIG_CHARGER_ISP1704=m
CONFIG_CHARGER_MAX8903=m
CONFIG_CHARGER_LP8727=m
CONFIG_CHARGER_GPIO=m
# CONFIG_CHARGER_MANAGER is not set
CONFIG_CHARGER_BQ2415X=m
# CONFIG_CHARGER_SMB347 is not set
# CONFIG_BATTERY_GOLDFISH is not set
CONFIG_POWER_RESET=y
# CONFIG_POWER_RESET_GPIO is not set
# CONFIG_POWER_RESET_QNAP is not set
CONFIG_POWER_RESET_RESTART=y
CONFIG_POWER_RESET_VEXPRESS=y
CONFIG_POWER_AVS=y
# CONFIG_HWMON is not set
# CONFIG_THERMAL is not set
# CONFIG_WATCHDOG is not set
CONFIG_SSB_POSSIBLE=y

#
# Sonics Silicon Backplane
#
CONFIG_SSB=m
CONFIG_SSB_DEBUG=y
# CONFIG_SSB_DRIVER_GPIO is not set
CONFIG_BCMA_POSSIBLE=y

#
# Broadcom specific AMBA
#
CONFIG_BCMA=m
# CONFIG_BCMA_DRIVER_GMAC_CMN is not set
CONFIG_BCMA_DRIVER_GPIO=y
CONFIG_BCMA_DEBUG=y

#
# Multifunction device drivers
#
CONFIG_MFD_CORE=y
CONFIG_MFD_CROS_EC=m
CONFIG_MFD_CROS_EC_I2C=m
# CONFIG_MFD_CROS_EC_SPI is not set
# CONFIG_MFD_ASIC3 is not set
# CONFIG_MFD_DA9052_SPI is not set
# CONFIG_MFD_MC13XXX_SPI is not set
# CONFIG_MFD_MC13XXX_I2C is not set
CONFIG_HTC_EGPIO=y
CONFIG_HTC_PASIC3=m
# CONFIG_EZX_PCAP is not set
CONFIG_MFD_VIPERBOARD=m
# CONFIG_MFD_RETU is not set
CONFIG_MFD_PCF50633=m
# CONFIG_PCF50633_ADC is not set
CONFIG_PCF50633_GPIO=m
CONFIG_MFD_SM501=m
CONFIG_MFD_SM501_GPIO=y
CONFIG_ABX500_CORE=y
# CONFIG_MFD_STMPE is not set
CONFIG_MFD_SYSCON=y
CONFIG_MFD_TI_AM335X_TSCADC=m
CONFIG_TPS6105X=m
CONFIG_TPS65010=m
# CONFIG_TPS6507X is not set
# CONFIG_MFD_TPS65217 is not set
CONFIG_MFD_TPS65912=y
CONFIG_MFD_TPS65912_SPI=y
# CONFIG_MFD_WL1273_CORE is not set
CONFIG_MFD_SI476X_CORE=m
CONFIG_MFD_LM3533=m
# CONFIG_MFD_TMIO is not set
# CONFIG_MFD_T7L66XB is not set
# CONFIG_MFD_TC6387XB is not set
# CONFIG_MFD_TC6393XB is not set
CONFIG_MFD_ARIZONA=y
# CONFIG_MFD_ARIZONA_I2C is not set
CONFIG_MFD_ARIZONA_SPI=m
CONFIG_MFD_WM5102=y
# CONFIG_MFD_WM5110 is not set
# CONFIG_MFD_WM831X_SPI is not set
CONFIG_VEXPRESS_CONFIG=y
CONFIG_REGULATOR=y
CONFIG_REGULATOR_DEBUG=y
CONFIG_REGULATOR_DUMMY=y
CONFIG_REGULATOR_FIXED_VOLTAGE=y
# CONFIG_REGULATOR_VIRTUAL_CONSUMER is not set
CONFIG_REGULATOR_USERSPACE_CONSUMER=m
CONFIG_REGULATOR_GPIO=m
CONFIG_REGULATOR_AD5398=m
CONFIG_REGULATOR_FAN53555=m
# CONFIG_REGULATOR_ANATOP is not set
CONFIG_REGULATOR_ISL6271A=m
CONFIG_REGULATOR_MAX1586=m
CONFIG_REGULATOR_MAX8649=m
# CONFIG_REGULATOR_MAX8660 is not set
CONFIG_REGULATOR_MAX8952=m
CONFIG_REGULATOR_MAX8973=m
# CONFIG_REGULATOR_LP3971 is not set
# CONFIG_REGULATOR_LP3972 is not set
CONFIG_REGULATOR_LP8755=m
CONFIG_REGULATOR_PCF50633=m
CONFIG_REGULATOR_TPS51632=m
CONFIG_REGULATOR_TPS6105X=m
# CONFIG_REGULATOR_TPS62360 is not set
CONFIG_REGULATOR_TPS65023=m
# CONFIG_REGULATOR_TPS6507X is not set
# CONFIG_REGULATOR_TPS6524X is not set
CONFIG_REGULATOR_TPS65912=m
# CONFIG_REGULATOR_VEXPRESS is not set
# CONFIG_MEDIA_SUPPORT is not set

#
# Graphics support
#
# CONFIG_DRM is not set
# CONFIG_VGASTATE is not set
# CONFIG_VIDEO_OUTPUT_CONTROL is not set
# CONFIG_FB is not set
# CONFIG_OMAP2_DSS is not set
# CONFIG_EXYNOS_VIDEO is not set
CONFIG_BACKLIGHT_LCD_SUPPORT=y
# CONFIG_LCD_CLASS_DEVICE is not set
CONFIG_BACKLIGHT_CLASS_DEVICE=m
# CONFIG_BACKLIGHT_GENERIC is not set
CONFIG_BACKLIGHT_LM3533=m
# CONFIG_BACKLIGHT_ADP8860 is not set
# CONFIG_BACKLIGHT_ADP8870 is not set
# CONFIG_BACKLIGHT_PCF50633 is not set
# CONFIG_BACKLIGHT_LM3630 is not set
# CONFIG_BACKLIGHT_LM3639 is not set
# CONFIG_BACKLIGHT_LP855X is not set

#
# Console display driver support
#
CONFIG_DUMMY_CONSOLE=y
CONFIG_SOUND=m
# CONFIG_SOUND_OSS_CORE is not set
CONFIG_SND=m
CONFIG_SND_TIMER=m
CONFIG_SND_PCM=m
CONFIG_SND_RAWMIDI=m
CONFIG_SND_SEQUENCER=m
CONFIG_SND_SEQ_DUMMY=m
# CONFIG_SND_MIXER_OSS is not set
# CONFIG_SND_PCM_OSS is not set
# CONFIG_SND_SEQUENCER_OSS is not set
# CONFIG_SND_DYNAMIC_MINORS is not set
# CONFIG_SND_SUPPORT_OLD_API is not set
CONFIG_SND_VERBOSE_PROCFS=y
# CONFIG_SND_VERBOSE_PRINTK is not set
# CONFIG_SND_DEBUG is not set
CONFIG_SND_RAWMIDI_SEQ=m
# CONFIG_SND_OPL3_LIB_SEQ is not set
# CONFIG_SND_OPL4_LIB_SEQ is not set
# CONFIG_SND_SBAWE_SEQ is not set
# CONFIG_SND_EMU10K1_SEQ is not set
CONFIG_SND_DRIVERS=y
CONFIG_SND_DUMMY=m
CONFIG_SND_ALOOP=m
CONFIG_SND_VIRMIDI=m
CONFIG_SND_MTPAV=m
# CONFIG_SND_MTS64 is not set
# CONFIG_SND_SERIAL_U16550 is not set
# CONFIG_SND_MPU401 is not set
CONFIG_SND_PORTMAN2X4=m
CONFIG_SND_ARM=y
# CONFIG_SND_ARMAACI is not set
# CONFIG_SND_SPI is not set
# CONFIG_SND_USB is not set
# CONFIG_SND_SOC is not set
# CONFIG_SOUND_PRIME is not set

#
# HID support
#
# CONFIG_HID is not set

#
# USB HID support
#
# CONFIG_USB_HID is not set
CONFIG_HID_PID=y

#
# I2C HID support
#
# CONFIG_I2C_HID is not set
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB_ARCH_HAS_EHCI=y
# CONFIG_USB_ARCH_HAS_XHCI is not set
CONFIG_USB_SUPPORT=y
CONFIG_USB_COMMON=m
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB=m
# CONFIG_USB_DEBUG is not set
CONFIG_USB_ANNOUNCE_NEW_DEVICES=y

#
# Miscellaneous USB options
#
CONFIG_USB_DEFAULT_PERSIST=y
CONFIG_USB_DYNAMIC_MINORS=y
CONFIG_USB_MON=m
CONFIG_USB_WUSB_CBAF=m
# CONFIG_USB_WUSB_CBAF_DEBUG is not set

#
# USB Host Controller Drivers
#
CONFIG_USB_C67X00_HCD=m
# CONFIG_USB_EHCI_HCD is not set
# CONFIG_USB_OXU210HP_HCD is not set
# CONFIG_USB_ISP116X_HCD is not set
# CONFIG_USB_ISP1760_HCD is not set
# CONFIG_USB_ISP1362_HCD is not set
CONFIG_USB_OHCI_HCD=m
# CONFIG_USB_OHCI_HCD_OMAP3 is not set
# CONFIG_USB_OHCI_HCD_SSB is not set
# CONFIG_USB_OHCI_HCD_PLATFORM is not set
# CONFIG_USB_OHCI_BIG_ENDIAN_DESC is not set
# CONFIG_USB_OHCI_BIG_ENDIAN_MMIO is not set
CONFIG_USB_OHCI_LITTLE_ENDIAN=y
# CONFIG_USB_UHCI_HCD is not set
CONFIG_USB_U132_HCD=m
CONFIG_USB_SL811_HCD=m
# CONFIG_USB_SL811_HCD_ISO is not set
# CONFIG_USB_R8A66597_HCD is not set
# CONFIG_USB_IMX21_HCD is not set
# CONFIG_USB_HCD_BCMA is not set
# CONFIG_USB_HCD_SSB is not set

#
# USB Device Class drivers
#
CONFIG_USB_ACM=m
# CONFIG_USB_PRINTER is not set
# CONFIG_USB_WDM is not set
# CONFIG_USB_TMC is not set

#
# NOTE: USB_STORAGE depends on SCSI but BLK_DEV_SD may
#

#
# also be needed; see USB_STORAGE Help for more info
#
CONFIG_USB_STORAGE=m
# CONFIG_USB_STORAGE_DEBUG is not set
# CONFIG_USB_STORAGE_REALTEK is not set
CONFIG_USB_STORAGE_DATAFAB=m
# CONFIG_USB_STORAGE_FREECOM is not set
# CONFIG_USB_STORAGE_ISD200 is not set
# CONFIG_USB_STORAGE_USBAT is not set
CONFIG_USB_STORAGE_SDDR09=m
# CONFIG_USB_STORAGE_SDDR55 is not set
CONFIG_USB_STORAGE_JUMPSHOT=m
CONFIG_USB_STORAGE_ALAUDA=m
# CONFIG_USB_STORAGE_ONETOUCH is not set
CONFIG_USB_STORAGE_KARMA=m
# CONFIG_USB_STORAGE_CYPRESS_ATACB is not set
CONFIG_USB_STORAGE_ENE_UB6250=m

#
# USB Imaging devices
#
# CONFIG_USB_MDC800 is not set
CONFIG_USB_MICROTEK=m
CONFIG_USB_DWC3=m
CONFIG_USB_DWC3_HOST=y
# CONFIG_USB_DWC3_DEBUG is not set
# CONFIG_USB_CHIPIDEA is not set

#
# USB port drivers
#
# CONFIG_USB_USS720 is not set
CONFIG_USB_SERIAL=m
# CONFIG_USB_SERIAL_GENERIC is not set
# CONFIG_USB_SERIAL_AIRCABLE is not set
CONFIG_USB_SERIAL_ARK3116=m
CONFIG_USB_SERIAL_BELKIN=m
CONFIG_USB_SERIAL_CH341=m
# CONFIG_USB_SERIAL_WHITEHEAT is not set
# CONFIG_USB_SERIAL_DIGI_ACCELEPORT is not set
CONFIG_USB_SERIAL_CP210X=m
# CONFIG_USB_SERIAL_CYPRESS_M8 is not set
CONFIG_USB_SERIAL_EMPEG=m
CONFIG_USB_SERIAL_FTDI_SIO=m
CONFIG_USB_SERIAL_FUNSOFT=m
CONFIG_USB_SERIAL_VISOR=m
# CONFIG_USB_SERIAL_IPAQ is not set
# CONFIG_USB_SERIAL_IR is not set
# CONFIG_USB_SERIAL_EDGEPORT is not set
# CONFIG_USB_SERIAL_EDGEPORT_TI is not set
CONFIG_USB_SERIAL_F81232=m
# CONFIG_USB_SERIAL_GARMIN is not set
CONFIG_USB_SERIAL_IPW=m
CONFIG_USB_SERIAL_IUU=m
CONFIG_USB_SERIAL_KEYSPAN_PDA=m
# CONFIG_USB_SERIAL_KEYSPAN is not set
CONFIG_USB_SERIAL_KLSI=m
CONFIG_USB_SERIAL_KOBIL_SCT=m
# CONFIG_USB_SERIAL_MCT_U232 is not set
# CONFIG_USB_SERIAL_METRO is not set
# CONFIG_USB_SERIAL_MOS7720 is not set
CONFIG_USB_SERIAL_MOS7840=m
CONFIG_USB_SERIAL_MOTOROLA=m
# CONFIG_USB_SERIAL_NAVMAN is not set
# CONFIG_USB_SERIAL_PL2303 is not set
# CONFIG_USB_SERIAL_OTI6858 is not set
CONFIG_USB_SERIAL_QCAUX=m
# CONFIG_USB_SERIAL_QUALCOMM is not set
# CONFIG_USB_SERIAL_SPCP8X5 is not set
# CONFIG_USB_SERIAL_HP4X is not set
# CONFIG_USB_SERIAL_SAFE is not set
CONFIG_USB_SERIAL_SIEMENS_MPI=m
# CONFIG_USB_SERIAL_SIERRAWIRELESS is not set
CONFIG_USB_SERIAL_SYMBOL=m
CONFIG_USB_SERIAL_TI=m
# CONFIG_USB_SERIAL_CYBERJACK is not set
CONFIG_USB_SERIAL_XIRCOM=m
CONFIG_USB_SERIAL_WWAN=m
# CONFIG_USB_SERIAL_OPTION is not set
# CONFIG_USB_SERIAL_OMNINET is not set
# CONFIG_USB_SERIAL_OPTICON is not set
# CONFIG_USB_SERIAL_VIVOPAY_SERIAL is not set
# CONFIG_USB_SERIAL_XSENS_MT is not set
# CONFIG_USB_SERIAL_ZIO is not set
# CONFIG_USB_SERIAL_WISHBONE is not set
CONFIG_USB_SERIAL_ZTE=m
# CONFIG_USB_SERIAL_SSU100 is not set
# CONFIG_USB_SERIAL_QT2 is not set
# CONFIG_USB_SERIAL_DEBUG is not set

#
# USB Miscellaneous drivers
#
# CONFIG_USB_EMI62 is not set
CONFIG_USB_EMI26=m
# CONFIG_USB_ADUTUX is not set
CONFIG_USB_SEVSEG=m
# CONFIG_USB_RIO500 is not set
# CONFIG_USB_LEGOTOWER is not set
CONFIG_USB_LCD=m
CONFIG_USB_LED=m
# CONFIG_USB_CYPRESS_CY7C63 is not set
# CONFIG_USB_CYTHERM is not set
CONFIG_USB_IDMOUSE=m
CONFIG_USB_FTDI_ELAN=m
# CONFIG_USB_APPLEDISPLAY is not set
CONFIG_USB_LD=m
CONFIG_USB_TRANCEVIBRATOR=m
# CONFIG_USB_IOWARRIOR is not set
# CONFIG_USB_TEST is not set
CONFIG_USB_ISIGHTFW=m
CONFIG_USB_YUREX=m
CONFIG_USB_EZUSB_FX2=m
CONFIG_USB_HSIC_USB3503=m
CONFIG_USB_PHY=m
CONFIG_NOP_USB_XCEIV=m
CONFIG_OMAP_CONTROL_USB=m
CONFIG_OMAP_USB2=m
CONFIG_OMAP_USB3=m
CONFIG_SAMSUNG_USBPHY=m
# CONFIG_SAMSUNG_USB2PHY is not set
# CONFIG_SAMSUNG_USB3PHY is not set
CONFIG_USB_GPIO_VBUS=m
# CONFIG_USB_ISP1301 is not set
# CONFIG_USB_MXS_PHY is not set
CONFIG_USB_RCAR_PHY=m
CONFIG_USB_ULPI=y
# CONFIG_USB_GADGET is not set
# CONFIG_MMC is not set
CONFIG_MEMSTICK=m
CONFIG_MEMSTICK_DEBUG=y

#
# MemoryStick drivers
#
CONFIG_MEMSTICK_UNSAFE_RESUME=y
CONFIG_MSPRO_BLOCK=m

#
# MemoryStick Host Controller Drivers
#
CONFIG_LEDS_GPIO_REGISTER=y
# CONFIG_NEW_LEDS is not set
CONFIG_ACCESSIBILITY=y
# CONFIG_EDAC is not set
CONFIG_RTC_LIB=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_HCTOSYS=y
CONFIG_RTC_SYSTOHC=y
CONFIG_RTC_HCTOSYS_DEVICE="rtc0"
CONFIG_RTC_DEBUG=y

#
# RTC interfaces
#
# CONFIG_RTC_INTF_SYSFS is not set
CONFIG_RTC_INTF_PROC=y
CONFIG_RTC_INTF_DEV=y
# CONFIG_RTC_INTF_DEV_UIE_EMUL is not set
CONFIG_RTC_DRV_TEST=m

#
# I2C RTC drivers
#
CONFIG_RTC_DRV_DS1307=m
CONFIG_RTC_DRV_DS1374=m
# CONFIG_RTC_DRV_DS1672 is not set
# CONFIG_RTC_DRV_DS3232 is not set
CONFIG_RTC_DRV_MAX6900=m
# CONFIG_RTC_DRV_RS5C372 is not set
# CONFIG_RTC_DRV_ISL1208 is not set
# CONFIG_RTC_DRV_ISL12022 is not set
CONFIG_RTC_DRV_X1205=m
# CONFIG_RTC_DRV_PCF8523 is not set
# CONFIG_RTC_DRV_PCF8563 is not set
CONFIG_RTC_DRV_PCF8583=m
# CONFIG_RTC_DRV_M41T80 is not set
CONFIG_RTC_DRV_BQ32K=m
# CONFIG_RTC_DRV_S35390A is not set
CONFIG_RTC_DRV_FM3130=m
CONFIG_RTC_DRV_RX8581=m
CONFIG_RTC_DRV_RX8025=m
# CONFIG_RTC_DRV_EM3027 is not set
# CONFIG_RTC_DRV_RV3029C2 is not set

#
# SPI RTC drivers
#
CONFIG_RTC_DRV_M41T93=m
# CONFIG_RTC_DRV_M41T94 is not set
CONFIG_RTC_DRV_DS1305=m
# CONFIG_RTC_DRV_DS1390 is not set
CONFIG_RTC_DRV_MAX6902=m
CONFIG_RTC_DRV_R9701=m
# CONFIG_RTC_DRV_RS5C348 is not set
CONFIG_RTC_DRV_DS3234=m
# CONFIG_RTC_DRV_PCF2123 is not set
CONFIG_RTC_DRV_RX4581=m

#
# Platform RTC drivers
#
CONFIG_RTC_DRV_CMOS=m
CONFIG_RTC_DRV_DS1286=m
CONFIG_RTC_DRV_DS1511=m
CONFIG_RTC_DRV_DS1553=m
# CONFIG_RTC_DRV_DS1742 is not set
# CONFIG_RTC_DRV_STK17TA8 is not set
CONFIG_RTC_DRV_M48T86=m
CONFIG_RTC_DRV_M48T35=m
CONFIG_RTC_DRV_M48T59=m
CONFIG_RTC_DRV_MSM6242=m
CONFIG_RTC_DRV_BQ4802=m
# CONFIG_RTC_DRV_RP5C01 is not set
CONFIG_RTC_DRV_V3020=m
# CONFIG_RTC_DRV_DS2404 is not set
# CONFIG_RTC_DRV_PCF50633 is not set

#
# on-CPU RTC drivers
#
# CONFIG_RTC_DRV_IMXDI is not set
CONFIG_RTC_DRV_OMAP=m
# CONFIG_RTC_DRV_PL030 is not set
# CONFIG_RTC_DRV_PL031 is not set
# CONFIG_RTC_DRV_VT8500 is not set
CONFIG_RTC_DRV_MV=m
CONFIG_RTC_DRV_MXC=m
CONFIG_RTC_DRV_SNVS=m

#
# HID Sensor RTC drivers
#
CONFIG_DMADEVICES=y
CONFIG_DMADEVICES_DEBUG=y
# CONFIG_DMADEVICES_VDEBUG is not set

#
# DMA Devices
#
CONFIG_AMBA_PL08X=y
# CONFIG_DW_DMAC is not set
# CONFIG_MV_XOR is not set
# CONFIG_MX3_IPU is not set
CONFIG_TIMB_DMA=m
# CONFIG_PL330_DMA is not set
# CONFIG_IMX_SDMA is not set
# CONFIG_IMX_DMA is not set
# CONFIG_MXS_DMA is not set
# CONFIG_DMA_OMAP is not set
CONFIG_DMA_ENGINE=y
CONFIG_DMA_VIRTUAL_CHANNELS=y
CONFIG_DMA_OF=y

#
# DMA Clients
#
CONFIG_ASYNC_TX_DMA=y
# CONFIG_DMATEST is not set
# CONFIG_AUXDISPLAY is not set
# CONFIG_UIO is not set
# CONFIG_VIRT_DRIVERS is not set
CONFIG_VIRTIO=m

#
# Virtio drivers
#
CONFIG_VIRTIO_BALLOON=m
CONFIG_VIRTIO_MMIO=m
# CONFIG_VIRTIO_MMIO_CMDLINE_DEVICES is not set

#
# Microsoft Hyper-V guest support
#
# CONFIG_STAGING is not set
CONFIG_CLKDEV_LOOKUP=y
CONFIG_HAVE_CLK_PREPARE=y
CONFIG_COMMON_CLK=y

#
# Common Clock Framework
#
# CONFIG_COMMON_CLK_DEBUG is not set
CONFIG_COMMON_CLK_VERSATILE=y
# CONFIG_COMMON_CLK_SI5351 is not set
CONFIG_COMMON_CLK_AXI_CLKGEN=m
CONFIG_MVEBU_CLK_CORE=y
CONFIG_MVEBU_CLK_CPU=y
CONFIG_MVEBU_CLK_GATING=y
CONFIG_HWSPINLOCK=m

#
# Hardware Spinlock drivers
#
CONFIG_HWSPINLOCK_OMAP=m
CONFIG_CLKSRC_OF=y
CONFIG_CLKSRC_MMIO=y
CONFIG_DW_APB_TIMER=y
CONFIG_DW_APB_TIMER_OF=y
CONFIG_ARMADA_370_XP_TIMER=y
CONFIG_VT8500_TIMER=y
CONFIG_CADENCE_TTC_TIMER=y
CONFIG_ARM_ARCH_TIMER=y
CONFIG_MAILBOX=y
CONFIG_PL320_MBOX=y
# CONFIG_OMAP2PLUS_MBOX is not set
CONFIG_MBOX_KFIFO_SIZE=256
CONFIG_MBOX_DATA_SIZE=4
# CONFIG_IOMMU_SUPPORT is not set

#
# Remoteproc drivers
#
CONFIG_REMOTEPROC=m
CONFIG_STE_MODEM_RPROC=m

#
# Rpmsg drivers
#
CONFIG_PM_DEVFREQ=y

#
# DEVFREQ Governors
#
CONFIG_DEVFREQ_GOV_SIMPLE_ONDEMAND=m
# CONFIG_DEVFREQ_GOV_PERFORMANCE is not set
# CONFIG_DEVFREQ_GOV_POWERSAVE is not set
# CONFIG_DEVFREQ_GOV_USERSPACE is not set

#
# DEVFREQ Drivers
#
# CONFIG_EXTCON is not set
CONFIG_MEMORY=y
CONFIG_TI_EMIF=m
# CONFIG_IIO is not set
# CONFIG_PWM is not set
CONFIG_IRQCHIP=y
CONFIG_ARM_GIC=y
# CONFIG_IPACK_BUS is not set
CONFIG_ARCH_HAS_RESET_CONTROLLER=y
# CONFIG_RESET_CONTROLLER is not set

#
# File systems
#
CONFIG_DCACHE_WORD_ACCESS=y
# CONFIG_EXT2_FS is not set
# CONFIG_EXT3_FS is not set
# CONFIG_EXT4_FS is not set
CONFIG_REISERFS_FS=m
# CONFIG_REISERFS_CHECK is not set
# CONFIG_REISERFS_PROC_INFO is not set
CONFIG_REISERFS_FS_XATTR=y
CONFIG_REISERFS_FS_POSIX_ACL=y
# CONFIG_REISERFS_FS_SECURITY is not set
CONFIG_JFS_FS=m
# CONFIG_JFS_POSIX_ACL is not set
# CONFIG_JFS_SECURITY is not set
CONFIG_JFS_DEBUG=y
CONFIG_JFS_STATISTICS=y
CONFIG_XFS_FS=m
# CONFIG_XFS_QUOTA is not set
CONFIG_XFS_POSIX_ACL=y
CONFIG_XFS_RT=y
CONFIG_XFS_DEBUG=y
# CONFIG_BTRFS_FS is not set
# CONFIG_NILFS2_FS is not set
CONFIG_FS_POSIX_ACL=y
CONFIG_EXPORTFS=y
CONFIG_FILE_LOCKING=y
CONFIG_FSNOTIFY=y
CONFIG_DNOTIFY=y
CONFIG_INOTIFY_USER=y
CONFIG_FANOTIFY=y
# CONFIG_FANOTIFY_ACCESS_PERMISSIONS is not set
# CONFIG_QUOTA is not set
# CONFIG_QUOTACTL is not set
# CONFIG_AUTOFS4_FS is not set
CONFIG_FUSE_FS=m
CONFIG_CUSE=m

#
# Caches
#
# CONFIG_FSCACHE is not set

#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=m
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
CONFIG_UDF_FS=m
CONFIG_UDF_NLS=y

#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=m
CONFIG_MSDOS_FS=m
# CONFIG_VFAT_FS is not set
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_NTFS_FS=m
CONFIG_NTFS_DEBUG=y
CONFIG_NTFS_RW=y

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
# CONFIG_PROC_VMCORE is not set
CONFIG_PROC_SYSCTL=y
CONFIG_PROC_PAGE_MONITOR=y
CONFIG_SYSFS=y
# CONFIG_TMPFS is not set
# CONFIG_HUGETLB_PAGE is not set
# CONFIG_CONFIGFS_FS is not set
# CONFIG_MISC_FILESYSTEMS is not set
CONFIG_NLS=m
CONFIG_NLS_DEFAULT="iso8859-1"
# CONFIG_NLS_CODEPAGE_437 is not set
CONFIG_NLS_CODEPAGE_737=m
CONFIG_NLS_CODEPAGE_775=m
CONFIG_NLS_CODEPAGE_850=m
CONFIG_NLS_CODEPAGE_852=m
CONFIG_NLS_CODEPAGE_855=m
CONFIG_NLS_CODEPAGE_857=m
CONFIG_NLS_CODEPAGE_860=m
CONFIG_NLS_CODEPAGE_861=m
# CONFIG_NLS_CODEPAGE_862 is not set
CONFIG_NLS_CODEPAGE_863=m
# CONFIG_NLS_CODEPAGE_864 is not set
CONFIG_NLS_CODEPAGE_865=m
# CONFIG_NLS_CODEPAGE_866 is not set
CONFIG_NLS_CODEPAGE_869=m
# CONFIG_NLS_CODEPAGE_936 is not set
CONFIG_NLS_CODEPAGE_950=m
# CONFIG_NLS_CODEPAGE_932 is not set
CONFIG_NLS_CODEPAGE_949=m
# CONFIG_NLS_CODEPAGE_874 is not set
CONFIG_NLS_ISO8859_8=m
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
CONFIG_NLS_ASCII=m
CONFIG_NLS_ISO8859_1=m
# CONFIG_NLS_ISO8859_2 is not set
CONFIG_NLS_ISO8859_3=m
CONFIG_NLS_ISO8859_4=m
CONFIG_NLS_ISO8859_5=m
CONFIG_NLS_ISO8859_6=m
CONFIG_NLS_ISO8859_7=m
CONFIG_NLS_ISO8859_9=m
# CONFIG_NLS_ISO8859_13 is not set
CONFIG_NLS_ISO8859_14=m
CONFIG_NLS_ISO8859_15=m
# CONFIG_NLS_KOI8_R is not set
CONFIG_NLS_KOI8_U=m
# CONFIG_NLS_MAC_ROMAN is not set
# CONFIG_NLS_MAC_CELTIC is not set
# CONFIG_NLS_MAC_CENTEURO is not set
# CONFIG_NLS_MAC_CROATIAN is not set
# CONFIG_NLS_MAC_CYRILLIC is not set
CONFIG_NLS_MAC_GAELIC=m
CONFIG_NLS_MAC_GREEK=m
CONFIG_NLS_MAC_ICELAND=m
# CONFIG_NLS_MAC_INUIT is not set
# CONFIG_NLS_MAC_ROMANIAN is not set
CONFIG_NLS_MAC_TURKISH=m
# CONFIG_NLS_UTF8 is not set

#
# Kernel hacking
#
CONFIG_PRINTK_TIME=y
CONFIG_DEFAULT_MESSAGE_LOGLEVEL=4
CONFIG_ENABLE_WARN_DEPRECATED=y
CONFIG_ENABLE_MUST_CHECK=y
CONFIG_FRAME_WARN=1024
CONFIG_MAGIC_SYSRQ=y
# CONFIG_STRIP_ASM_SYMS is not set
CONFIG_UNUSED_SYMBOLS=y
CONFIG_DEBUG_FS=y
CONFIG_HEADERS_CHECK=y
# CONFIG_DEBUG_SECTION_MISMATCH is not set
# CONFIG_DEBUG_KERNEL is not set
CONFIG_PANIC_ON_OOPS=y
CONFIG_PANIC_ON_OOPS_VALUE=1
CONFIG_SLUB_DEBUG_ON=y
CONFIG_SLUB_STATS=y
CONFIG_HAVE_DEBUG_KMEMLEAK=y
CONFIG_DEBUG_BUGVERBOSE=y
CONFIG_DEBUG_MEMORY_INIT=y
CONFIG_FRAME_POINTER=y

#
# RCU Debugging
#
CONFIG_SPARSE_RCU_POINTER=y
CONFIG_RCU_CPU_STALL_TIMEOUT=21
CONFIG_LKDTM=m
CONFIG_HAVE_FUNCTION_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y
CONFIG_HAVE_DYNAMIC_FTRACE=y
CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y
CONFIG_HAVE_SYSCALL_TRACEPOINTS=y
CONFIG_HAVE_C_RECORDMCOUNT=y
CONFIG_TRACING_SUPPORT=y
# CONFIG_FTRACE is not set
CONFIG_BUILD_DOCSRC=y
# CONFIG_DYNAMIC_DEBUG is not set
CONFIG_DMA_API_DEBUG=y
CONFIG_ATOMIC64_SELFTEST=y
CONFIG_ASYNC_RAID6_TEST=m
# CONFIG_SAMPLES is not set
CONFIG_HAVE_ARCH_KGDB=y
# CONFIG_TEST_STRING_HELPERS is not set
CONFIG_TEST_KSTRTOX=m
# CONFIG_STRICT_DEVMEM is not set
# CONFIG_DEBUG_USER is not set
CONFIG_DEBUG_IMX_UART_PORT=1
CONFIG_DEBUG_LL_INCLUDE="mach/debug-macro.S"
CONFIG_UNCOMPRESS_INCLUDE="debug/uncompress.h"
# CONFIG_OC_ETM is not set
CONFIG_PID_IN_CONTEXTIDR=y

#
# Security options
#
# CONFIG_KEYS is not set
CONFIG_SECURITY_DMESG_RESTRICT=y
CONFIG_SECURITY=y
CONFIG_SECURITYFS=y
# CONFIG_SECURITY_NETWORK is not set
CONFIG_SECURITY_PATH=y
CONFIG_SECURITY_YAMA=y
CONFIG_SECURITY_YAMA_STACKED=y
CONFIG_INTEGRITY=y
CONFIG_IMA=y
CONFIG_IMA_MEASURE_PCR_IDX=10
CONFIG_IMA_APPRAISE=y
CONFIG_DEFAULT_SECURITY_YAMA=y
# CONFIG_DEFAULT_SECURITY_DAC is not set
CONFIG_DEFAULT_SECURITY="yama"
CONFIG_XOR_BLOCKS=m
CONFIG_ASYNC_CORE=m
CONFIG_ASYNC_MEMCPY=m
CONFIG_ASYNC_XOR=m
CONFIG_ASYNC_PQ=m
CONFIG_ASYNC_RAID6_RECOV=m
CONFIG_CRYPTO=y

#
# Crypto core or helper
#
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_ALGAPI2=y
CONFIG_CRYPTO_AEAD=m
CONFIG_CRYPTO_AEAD2=y
CONFIG_CRYPTO_BLKCIPHER=m
CONFIG_CRYPTO_BLKCIPHER2=y
CONFIG_CRYPTO_HASH=y
CONFIG_CRYPTO_HASH2=y
CONFIG_CRYPTO_RNG=m
CONFIG_CRYPTO_RNG2=y
CONFIG_CRYPTO_PCOMP=m
CONFIG_CRYPTO_PCOMP2=y
CONFIG_CRYPTO_MANAGER=y
CONFIG_CRYPTO_MANAGER2=y
CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=y
CONFIG_CRYPTO_GF128MUL=m
# CONFIG_CRYPTO_NULL is not set
CONFIG_CRYPTO_PCRYPT=m
CONFIG_CRYPTO_WORKQUEUE=y
CONFIG_CRYPTO_CRYPTD=m
# CONFIG_CRYPTO_AUTHENC is not set
# CONFIG_CRYPTO_TEST is not set

#
# Authenticated Encryption with Associated Data
#
CONFIG_CRYPTO_CCM=m
# CONFIG_CRYPTO_GCM is not set
CONFIG_CRYPTO_SEQIV=m

#
# Block modes
#
CONFIG_CRYPTO_CBC=m
CONFIG_CRYPTO_CTR=m
# CONFIG_CRYPTO_CTS is not set
CONFIG_CRYPTO_ECB=m
CONFIG_CRYPTO_LRW=m
# CONFIG_CRYPTO_PCBC is not set
# CONFIG_CRYPTO_XTS is not set

#
# Hash modes
#
CONFIG_CRYPTO_CMAC=m
CONFIG_CRYPTO_HMAC=y
# CONFIG_CRYPTO_XCBC is not set
CONFIG_CRYPTO_VMAC=m

#
# Digest
#
CONFIG_CRYPTO_CRC32C=m
CONFIG_CRYPTO_CRC32=m
CONFIG_CRYPTO_GHASH=m
CONFIG_CRYPTO_MD4=m
CONFIG_CRYPTO_MD5=y
CONFIG_CRYPTO_MICHAEL_MIC=m
CONFIG_CRYPTO_RMD128=m
# CONFIG_CRYPTO_RMD160 is not set
CONFIG_CRYPTO_RMD256=m
# CONFIG_CRYPTO_RMD320 is not set
CONFIG_CRYPTO_SHA1=y
# CONFIG_CRYPTO_SHA1_ARM is not set
# CONFIG_CRYPTO_SHA256 is not set
CONFIG_CRYPTO_SHA512=m
CONFIG_CRYPTO_TGR192=m
CONFIG_CRYPTO_WP512=m

#
# Ciphers
#
CONFIG_CRYPTO_AES=m
# CONFIG_CRYPTO_AES_ARM is not set
CONFIG_CRYPTO_ANUBIS=m
CONFIG_CRYPTO_ARC4=m
# CONFIG_CRYPTO_BLOWFISH is not set
# CONFIG_CRYPTO_CAMELLIA is not set
# CONFIG_CRYPTO_CAST5 is not set
# CONFIG_CRYPTO_CAST6 is not set
# CONFIG_CRYPTO_DES is not set
# CONFIG_CRYPTO_FCRYPT is not set
CONFIG_CRYPTO_KHAZAD=m
# CONFIG_CRYPTO_SALSA20 is not set
# CONFIG_CRYPTO_SEED is not set
# CONFIG_CRYPTO_SERPENT is not set
# CONFIG_CRYPTO_TEA is not set
CONFIG_CRYPTO_TWOFISH=m
CONFIG_CRYPTO_TWOFISH_COMMON=m

#
# Compression
#
CONFIG_CRYPTO_DEFLATE=m
CONFIG_CRYPTO_ZLIB=m
# CONFIG_CRYPTO_LZO is not set
CONFIG_CRYPTO_LZ4=m
CONFIG_CRYPTO_LZ4HC=m

#
# Random Number Generation
#
CONFIG_CRYPTO_ANSI_CPRNG=m
CONFIG_CRYPTO_HW=y
# CONFIG_CRYPTO_DEV_MV_CESA is not set
# CONFIG_CRYPTO_DEV_OMAP_SHAM is not set
CONFIG_CRYPTO_DEV_OMAP_AES=m
# CONFIG_BINARY_PRINTF is not set

#
# Library routines
#
CONFIG_RAID6_PQ=m
CONFIG_BITREVERSE=y
CONFIG_GENERIC_STRNCPY_FROM_USER=y
CONFIG_GENERIC_STRNLEN_USER=y
CONFIG_GENERIC_PCI_IOMAP=y
CONFIG_GENERIC_IO=y
CONFIG_CRC_CCITT=m
CONFIG_CRC16=m
CONFIG_CRC_T10DIF=m
CONFIG_CRC_ITU_T=m
CONFIG_CRC32=y
# CONFIG_CRC32_SELFTEST is not set
CONFIG_CRC32_SLICEBY8=y
# CONFIG_CRC32_SLICEBY4 is not set
# CONFIG_CRC32_SARWATE is not set
# CONFIG_CRC32_BIT is not set
# CONFIG_CRC7 is not set
CONFIG_LIBCRC32C=m
CONFIG_CRC8=m
CONFIG_ZLIB_INFLATE=m
CONFIG_ZLIB_DEFLATE=m
CONFIG_LZO_COMPRESS=y
CONFIG_LZO_DECOMPRESS=y
CONFIG_LZ4_COMPRESS=m
CONFIG_LZ4HC_COMPRESS=m
CONFIG_LZ4_DECOMPRESS=m
# CONFIG_XZ_DEC is not set
# CONFIG_XZ_DEC_BCJ is not set
CONFIG_HAS_IOMEM=y
CONFIG_HAS_DMA=y
CONFIG_NLATTR=y
CONFIG_GENERIC_ATOMIC64=y
CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE=y
# CONFIG_AVERAGE is not set
CONFIG_CORDIC=m
CONFIG_DDR=y
# CONFIG_VIRTUALIZATION is not set

From sboyd at codeaurora.org  Fri Apr 19 13:34:15 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Fri, 19 Apr 2013 10:34:15 -0700
Subject: [PATCH 1/2] clocksource: arm_arch_timer: unify sched_clock init
In-Reply-To: <51709FD7.8050408@gmail.com>
References: <1366313410-16692-1-git-send-email-robherring2@gmail.com>
 <51708918.1070501@codeaurora.org> <51709FD7.8050408@gmail.com>
Message-ID: <51718017.3060405@codeaurora.org>

On 04/18/13 18:37, Rob Herring wrote:
> On 04/18/2013 07:00 PM, Stephen Boyd wrote:
>> On 04/18/13 12:30, Rob Herring wrote:
>>> diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
>>> index 122ff05..17ed8e4 100644
>>> --- a/drivers/clocksource/arm_arch_timer.c
>>> +++ b/drivers/clocksource/arm_arch_timer.c
>>> @@ -266,6 +266,15 @@ static struct notifier_block arch_timer_cpu_nb __cpuinitdata = {
>>>  	.notifier_call = arch_timer_cpu_notify,
>>>  };
>>>  
>>> +static u64 sched_clock_mult __read_mostly;
>>> +
>>> +unsigned long long notrace arch_timer_sched_clock(void)
>>> +{
>>> +	return arch_timer_read_counter() * sched_clock_mult;
>>> +}
>>> +unsigned long long sched_clock(void) \
>>> +	__attribute__((weak, alias("arch_timer_sched_clock")));
>> I'm still lost, how does this prevent the timer in ARM's 32 bit
>> sched_clock code from getting setup in sched_clock_postinit()? That
>> print is still there right? 

I still see this:

[    0.000000] sched_clock: ARM arch timer >56 bits at 19200kHz,
resolution 52ns
[    0.000000] Architected cp15 timer running at 19.20MHz (virt).
[    0.000000] Switching to timer-based delay loop
[    0.000000] sched_clock: 32 bits at 100 Hz, resolution 10000000ns,
wraps every 4294967286ms


>> Who owns sched_clock() in multi-target builds?
> For arm64, it does not define sched_clock, so it will get
> arch_timer_sched_clock.
>
> For arm, sched_clock is defined in arch/arm/kernel/sched_clock.c and the
> weak alias is not used. The arm sched_clock function just calls a
> function pointer which defaults to sched_clock_32 (which is the original
> arm sched_clock implementation). If the arch timer is present, then the
> function pointer is set to arch_timer_sched_clock and any calls to
> setup_sched_clock and the sched_clock_postinit have no effect.
> Otherwise, the functionality is basically unchanged for <=32-bit
> sched_clock implementations.

Ok. I was missing the part where the function pointer is assigned.

>
>> Why can't we play along with the sched_clock code that lives in arm?
>> Maybe we should resurrect those clocksource sched_clock patches again.
>> Or maybe we should add support for setup_sched_clock_64() in arm's sched
>> clock code.
> That's what I originally had which Russell objected to. The needs for
> the arch timer is a bit different since we don't need to deal with
> wrapping. And we need the same boot time offset and suspend handling in
> both arm and arm64.
>

I would much rather we play along with arm's sched_clock code. If we can
add support for 64 bits alongside the 32 bit stuff in the same file we
should be able to generalize the entire code to generic kernel code and
use it on even more arches. I'll try to put something together today.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation



From santosh.shilimkar at ti.com  Fri Apr 19 13:41:06 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Fri, 19 Apr 2013 23:11:06 +0530
Subject: Multiple issues with omap4 panda es in linux next
In-Reply-To: <20130419171318.GK10155@atomide.com>
References: <20130419171318.GK10155@atomide.com>
Message-ID: <517181B2.9070302@ti.com>

On Friday 19 April 2013 10:43 PM, Tony Lindgren wrote:
> Hi all,
> 
> Here's a list of breakage I've noticed so far while trying to
> use linux next on my pandaboard es. Probably similar issues exist
> on other boards as well.
> 
> Ideally we would not have any breakage by the merge window, so
> let's try to get these fixed ASAP:
> 
> 1. Serial console broken on panda es booting with DT
> 
> The symptoms are dmesg output stopping after few lines
> and only continuing after pressing a key. Does not seem to
> happen on blaze with DT for some reason. And does not happen
> on panda es with legacy booting.
> 
This one is known and reported on list along with fix patches and
later pull request [1].

Unfortunately with all the testing and everything and patches have
been on the list for quite some time, feedback on one of the patch
received was after pull request and then there was no further
clarification. That series address the same exact issue you have
mentioned above.

Regards,
Santosh
[1] http://patchwork.ozlabs.org/patch/229269/


From peter.maydell at linaro.org  Fri Apr 19 13:40:18 2013
From: peter.maydell at linaro.org (Peter Maydell)
Date: Fri, 19 Apr 2013 18:40:18 +0100
Subject: [RFC] arm64: Early printk support for virtio-mmio console devices.
In-Reply-To: <20130419171455.GA43450@MacBook-Pro.local>
References: <CAAHg+HipCX2ma6brxj9Kgc3ew39b5e30grLwyun9CViif-5wZQ@mail.gmail.com>
 <20130419092752.GB13283@mudshark.cambridge.arm.com>
 <CAFEAcA8j124G=vaHObJ_w5wOhUiS3KYKbjMnigbnr6mgwFxZUg@mail.gmail.com>
 <CAAHg+Hg=t97SJ0JPZYgrZaL+zimo-wbezwaj1BQvHqE-vf4VDA@mail.gmail.com>
 <20130419093953.GD13283@mudshark.cambridge.arm.com>
 <CAFEAcA_WfYpyvq54rZqS8JZkmDF5JXB+CNHFH5CnrhKun52uzA@mail.gmail.com>
 <20130419161201.GA5383@localhost.cambridge.arm.com>
 <CAFEAcA-F18kR4JihdxaLTm3qb4n51tsygG1RW4djwJ0u9+FQqw@mail.gmail.com>
 <20130419162226.GB5383@localhost.cambridge.arm.com>
 <CAFEAcA_vdXbtK=U2gauC=DsrB=_cSfcUTaNCiB0Ts4YOq_pXEg@mail.gmail.com>
 <20130419171455.GA43450@MacBook-Pro.local>
Message-ID: <CAFEAcA_Xhe2ggxUf=Ezrjozf2Y4h4BtCNPyVG=QD8b6kcqrUnQ@mail.gmail.com>

On 19 April 2013 18:14, Catalin Marinas <catalin.marinas at arm.com> wrote:
> On Fri, Apr 19, 2013 at 05:33:18PM +0100, Peter Maydell wrote:
>> The command line lives in the DTB anyway so if you can't look
>> in the DTB you can't get at earlyprintk config either way.
>
> Linux indeed looks in the DT for the command line and that's what's
> triggering the earlyprintk console but at that stage the DT is flat.
> Unflattening the DT happens later (it requires slab allocator). I
> initially thought about extracting the early console device from the DT
> but when it is flat you can't parse the full hierarchy to get its
> address.

So you could add a DT property that specifies the information in a
format that you can get at at the right time. That's annoying
duplication, but at least it's not in the command line (which is
a raw ascii string that QEMU &co shouldn't have to be parsing or
editing). "/console/type" and "/console/address" or something?

-- PMM


From gregory.clement at free-electrons.com  Fri Apr 19 13:41:52 2013
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Fri, 19 Apr 2013 19:41:52 +0200
Subject: [GIT PULL V3 1/4] mvebu driver changes for v3.10
In-Reply-To: <CAOesGMiRbpfhnVS3DMtK5zkkA4_d4Ktd0Z9s-dg3h4DBNyxYFg@mail.gmail.com>
References: <20130415182824.GN28693@titan.lakedaemon.net>
 <20130416150416.GB28693@titan.lakedaemon.net>
 <20130418053002.GB12816@quad.lixom.net>
 <CAOesGMjD-VAZW-zL-jm65xSJkFLpzbYOdvN6-5pV1OW_vJDCWg@mail.gmail.com>
 <517155FE.30406@free-electrons.com> <51716CD9.4030901@free-electrons.com>
 <20130419172135.GJ27197@titan.lakedaemon.net>
 <CAOesGMiRbpfhnVS3DMtK5zkkA4_d4Ktd0Z9s-dg3h4DBNyxYFg@mail.gmail.com>
Message-ID: <517181E0.7040203@free-electrons.com>

On 04/19/2013 07:24 PM, Olof Johansson wrote:
> On Fri, Apr 19, 2013 at 10:21 AM, Jason Cooper <jason at lakedaemon.net> wrote:
>>
>> I have dropped:
>>
>>   9ecbe03 pci: infrastructure to add drivers in drivers/pci/host
>>
>> Since Gregory said they didn't need it.
>>
>> thx,
>>
>> Jason.
>>
>> The following changes since commit 8bb9660418e05bb1845ac1a2428444d78e322cc7:
>>
>>   Linux 3.9-rc4 (2013-03-23 16:52:44 -0700)
>>
>> are available in the git repository at:
>>
>>   git://git.infradead.org/users/jcooper/linux.git tags/drivers-3.10-2
>>
>> for you to fetch changes up to a5eddfb24302b9cfb37ce5f0911f090681507fcb:
>>
>>   clk: mvebu: add more PCIe clocks for Armada XP (2013-04-19 17:15:42 +0000)
> 
> Sorry, not pulling this for 3.10.

I don't ask you to pull anything, just to revert this single
commit which have been identified to break the build.

However it would sound very strange to me to drop the dozen of
other commits which are not at all related to this one.


> 
> There will likely not be another linux-next before the merge window
> opens, so there is no time for trial and error.
> 
> Please send a new pull request after -rc1.
> 
> 
> Thanks,
> 
> -Olof
> 


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From tony at atomide.com  Fri Apr 19 13:44:55 2013
From: tony at atomide.com (Tony Lindgren)
Date: Fri, 19 Apr 2013 10:44:55 -0700
Subject: Multiple issues with omap4 panda es in linux next
In-Reply-To: <517181B2.9070302@ti.com>
References: <20130419171318.GK10155@atomide.com>
 <517181B2.9070302@ti.com>
Message-ID: <20130419174454.GM10155@atomide.com>

* Santosh Shilimkar <santosh.shilimkar at ti.com> [130419 10:43]:
> On Friday 19 April 2013 10:43 PM, Tony Lindgren wrote:
> > Hi all,
> > 
> > Here's a list of breakage I've noticed so far while trying to
> > use linux next on my pandaboard es. Probably similar issues exist
> > on other boards as well.
> > 
> > Ideally we would not have any breakage by the merge window, so
> > let's try to get these fixed ASAP:
> > 
> > 1. Serial console broken on panda es booting with DT
> > 
> > The symptoms are dmesg output stopping after few lines
> > and only continuing after pressing a key. Does not seem to
> > happen on blaze with DT for some reason. And does not happen
> > on panda es with legacy booting.
> > 
> This one is known and reported on list along with fix patches and
> later pull request [1].
> 
> Unfortunately with all the testing and everything and patches have
> been on the list for quite some time, feedback on one of the patch
> received was after pull request and then there was no further
> clarification. That series address the same exact issue you have
> mentioned above.

OK thanks. I think Paul picked some of those and the plan was
to update the branch? Which one(s) should go into v3.10 as fixes?

Regards,

Tony

> [1] http://patchwork.ozlabs.org/patch/229269/


From olof at lixom.net  Fri Apr 19 13:50:34 2013
From: olof at lixom.net (Olof Johansson)
Date: Fri, 19 Apr 2013 10:50:34 -0700
Subject: [GIT PULL V3 1/4] mvebu driver changes for v3.10
In-Reply-To: <517181E0.7040203@free-electrons.com>
References: <20130415182824.GN28693@titan.lakedaemon.net>
 <20130416150416.GB28693@titan.lakedaemon.net>
 <20130418053002.GB12816@quad.lixom.net>
 <CAOesGMjD-VAZW-zL-jm65xSJkFLpzbYOdvN6-5pV1OW_vJDCWg@mail.gmail.com>
 <517155FE.30406@free-electrons.com>
 <51716CD9.4030901@free-electrons.com>
 <20130419172135.GJ27197@titan.lakedaemon.net>
 <CAOesGMiRbpfhnVS3DMtK5zkkA4_d4Ktd0Z9s-dg3h4DBNyxYFg@mail.gmail.com>
 <517181E0.7040203@free-electrons.com>
Message-ID: <CAOesGMjAObvi6Zm5Wsrx136d0tH=Rx0iomsGYenYKaVQR3vhEg@mail.gmail.com>

On Fri, Apr 19, 2013 at 10:41 AM, Gregory CLEMENT
<gregory.clement at free-electrons.com> wrote:
> On 04/19/2013 07:24 PM, Olof Johansson wrote:
>> On Fri, Apr 19, 2013 at 10:21 AM, Jason Cooper <jason at lakedaemon.net> wrote:
>>>
>>> I have dropped:
>>>
>>>   9ecbe03 pci: infrastructure to add drivers in drivers/pci/host
>>>
>>> Since Gregory said they didn't need it.
>>>
>>> thx,
>>>
>>> Jason.
>>>
>>> The following changes since commit 8bb9660418e05bb1845ac1a2428444d78e322cc7:
>>>
>>>   Linux 3.9-rc4 (2013-03-23 16:52:44 -0700)
>>>
>>> are available in the git repository at:
>>>
>>>   git://git.infradead.org/users/jcooper/linux.git tags/drivers-3.10-2
>>>
>>> for you to fetch changes up to a5eddfb24302b9cfb37ce5f0911f090681507fcb:
>>>
>>>   clk: mvebu: add more PCIe clocks for Armada XP (2013-04-19 17:15:42 +0000)
>>
>> Sorry, not pulling this for 3.10.
>
> I don't ask you to pull anything, just to revert this single
> commit which have been identified to break the build.
>
> However it would sound very strange to me to drop the dozen of
> other commits which are not at all related to this one.

The granularity for us is branches, where we merge and drop them as
needed. If you want to start submitting patches for us to apply
instead, so we can apply and revert them as needed then that's
something we could consider, but it's definitely not something we do
for large platforms today.

I know this code has been posted for quite a while, and it's well past
due for going in, but the pull requests came in so late that it in all
honesty I shouldn't have picked them up in the first place. I tried to
do you a favor, and because of that Stephen Rothwell ended up
reverting back to the previous day's arm-soc contents for linux-next,
effectively dropping coverage for any other platform that I also
picked up code for.

Since that was likely the last linux-next before the merge window,
there's not much else to do at this point.


-Olof


From santosh.shilimkar at ti.com  Fri Apr 19 13:53:38 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Fri, 19 Apr 2013 23:23:38 +0530
Subject: Multiple issues with omap4 panda es in linux next
In-Reply-To: <20130419174454.GM10155@atomide.com>
References: <20130419171318.GK10155@atomide.com> <517181B2.9070302@ti.com>
 <20130419174454.GM10155@atomide.com>
Message-ID: <517184A2.9020908@ti.com>

On Friday 19 April 2013 11:14 PM, Tony Lindgren wrote:
> * Santosh Shilimkar <santosh.shilimkar at ti.com> [130419 10:43]:
>> On Friday 19 April 2013 10:43 PM, Tony Lindgren wrote:
>>> Hi all,
>>>
>>> Here's a list of breakage I've noticed so far while trying to
>>> use linux next on my pandaboard es. Probably similar issues exist
>>> on other boards as well.
>>>
>>> Ideally we would not have any breakage by the merge window, so
>>> let's try to get these fixed ASAP:
>>>
>>> 1. Serial console broken on panda es booting with DT
>>>
>>> The symptoms are dmesg output stopping after few lines
>>> and only continuing after pressing a key. Does not seem to
>>> happen on blaze with DT for some reason. And does not happen
>>> on panda es with legacy booting.
>>>
>> This one is known and reported on list along with fix patches and
>> later pull request [1].
>>
>> Unfortunately with all the testing and everything and patches have
>> been on the list for quite some time, feedback on one of the patch
>> received was after pull request and then there was no further
>> clarification. That series address the same exact issue you have
>> mentioned above.
> 
> OK thanks. I think Paul picked some of those and the plan was
> to update the branch? Which one(s) should go into v3.10 as fixes?
> 
Main in that series was to handle driver sysc handling withing hwmod
layer and that is where the series got stuck [2]. Without that support
other patches won't fix the issue.

> 
>> [1] http://patchwork.ozlabs.org/patch/229269/

[2] https://patchwork.kernel.org/patch/2166931/



From sergei.shtylyov at cogentembedded.com  Fri Apr 19 13:54:58 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Fri, 19 Apr 2013 21:54:58 +0400
Subject: [PATCH v2 0/9] Reorganize R8A7779/Marzen USB code
In-Reply-To: <87a9ov74ao.wl%kuninori.morimoto.gx@renesas.com>
References: <201304090110.50154.sergei.shtylyov@cogentembedded.com>
 <87zjx89rfb.wl%kuninori.morimoto.gx@renesas.com>
 <51640D21.3090800@cogentembedded.com>
 <87txnfjhmu.wl%kuninori.morimoto.gx@renesas.com>
 <51689399.5090203@cogentembedded.com> <51689488.7040109@cogentembedded.com>
 <87mwsydklg.wl%kuninori.morimoto.gx@renesas.com>
 <87a9ov74ao.wl%kuninori.morimoto.gx@renesas.com>
Message-ID: <517184F2.8070009@cogentembedded.com>

Hello.

On 04/19/2013 04:27 AM, Kuninori Morimoto wrote:

>>>>>>       I'm going to post R8A7778/BOCK-W series following this one, and
>>>>>> all the
>>>>>> patches in 1st series should additionally be tested on BOCK-W. Well, I
>>>>>> probably can hold up posting version 3 until I have the second
>>>>>> series verified.
>>>>>>       BTW, about R8A7778/BOCK-W, R-Car M1A user manual talks about a
>>>>>> ferrite
>>>>>> bead in 49.4.1 (3) Setting USB-PHY. Do you know for sure if it's
>>>>>> used or not
>>>>>> on BOCK-W board? PHY initialization seems to work with either
>>>>>> settings...
>>>>> I can ask it to HW team if you want me.
>>>      Yes, ask them please.
>> Now, I'm asking it to HW team
>> Please wait
> According to HW team,
> this setting is for some kind of USB compliance test (?).
> So, in general, we can use "No ferrite bead".

    Thanks, I'll change it.

WBR, Sergei



From olof at lixom.net  Fri Apr 19 13:59:48 2013
From: olof at lixom.net (Olof Johansson)
Date: Fri, 19 Apr 2013 10:59:48 -0700
Subject: [GIT PULL] ARM: arm-soc fixes for 3.9
Message-ID: <20130419175948.GA29547@quad.lixom.net>

Hi Linus,

The following changes since commit 71bd98aff05a644a2cfc3ac6ca848a586fa210b9:

  Merge tag 'mvebu_fixes_for_v3.9_round3' of git://git.infradead.org/users/jcooper/linux into fixes (2013-04-11 16:55:29 +0200)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/fixes-for-linus

for you to fetch changes up to 73053d973dd6f56472309cffa5a5d15a62dd6f96:

  ARM: highbank: fix cache flush ordering for cpu hotplug (2013-04-18 09:37:46 -0700)

----------------------------------------------------------------
ARM: arm-soc fixes for 3.9

Only one remaining fix for arm-soc platforms at this time, a small
bugfix for cpu hotplug on highbank platforms that has become much
easier to hit as of late. Details in the patch description, but it's
small and well-contained and definitely impacts users of the platform,
so 3.9 seems appropriate.

----------------------------------------------------------------
Rob Herring (1):
      ARM: highbank: fix cache flush ordering for cpu hotplug

 arch/arm/mach-highbank/hotplug.c | 10 ++++------
 1 file changed, 4 insertions(+), 6 deletions(-)


From ezequiel.garcia at free-electrons.com  Fri Apr 19 14:10:59 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Fri, 19 Apr 2013 15:10:59 -0300
Subject: [PATCH v7 1/5] drivers: memory: Introduce Marvell EBU Device Bus
 driver
In-Reply-To: <20130410194337.GA5681@kroah.com>
References: <1365620644-15790-1-git-send-email-ezequiel.garcia@free-electrons.com>
 <1365620644-15790-2-git-send-email-ezequiel.garcia@free-electrons.com>
 <20130410191641.GG28693@titan.lakedaemon.net>
 <20130410194337.GA5681@kroah.com>
Message-ID: <20130419181058.GA2243@localhost>

Hi Greg,

On Wed, Apr 10, 2013 at 12:43:37PM -0700, Greg KH wrote:
> > On Wed, Apr 10, 2013 at 04:04:00PM -0300, Ezequiel Garcia wrote:
> > > Marvell EBU SoCs such as Armada 370/XP, Orion5x (88f5xxx) and
> > > Discovery (mv78xx0) supports a Device Bus controller to access several
> > > kinds of memories and I/O devices (NOR, NAND, SRAM, FPGA).
> > > 
> > > This commit adds a driver to handle this controller. So far only
> > > Armada 370, Armada XP and Discovery SoCs are supported.
> > > 
> > > The driver must be registered through a device tree node;
> > > as explained in the binding document.
> > > 
> > > For each child node in the device tree, this driver will:
> > >   * set timing parameters
> > >   * register a child device
> > >   * setup an address decoding window, using the mbus driver
> > > 
> > > Keep in mind the address decoding window setup is only a temporary hack.
> > > This code will be removed from this devbus driver as soon as a proper device
> > > tree binding for the mbus driver is added.
> > > 
> > > Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
> > > Acked-by: Arnd Bergmann <arnd at arndb.de>
> > > ---
> > >  .../bindings/memory-controllers/mvebu-devbus.txt   | 156 ++++++++++
> > >  drivers/memory/Kconfig                             |  10 +
> > >  drivers/memory/Makefile                            |   1 +
> > >  drivers/memory/mvebu-devbus.c                      | 340 +++++++++++++++++++++
> > >  4 files changed, 507 insertions(+)
> > >  create mode 100644 Documentation/devicetree/bindings/memory-controllers/mvebu-devbus.txt
> > >  create mode 100644 drivers/memory/mvebu-devbus.c
> > 
> > As every commit to drivers/memory has been signed by you, would you like
> > to take this patch through your tree?  Or, I'll take it through arm-soc
> > with your Ack to keep the series together.
> 
> Sure, feel free to take this through your tree and add:
> 
> Acked-by: Greg Kroah-Hartman <gregkh at linuxfoundation.org>

Olof (in Cc) has just decided to drop the entire pull request from
Jason Cooper which contained this driver.
This means this patch will have to wait until v3.11.

The reasons for dropping the pull was because of a build error on powerpc64,
completely unrelated to this driver, the faulty commit was 9ecbe03ae85b
("pci: infrastructure to add drivers in drivers/pci/host").

Is it possible that you take this patch instead, so it can make it in v3.10?

Of course, assuming it's not already too late and this doesn't break any rule.

Thanks,
-- 
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com


From gregkh at linuxfoundation.org  Fri Apr 19 14:16:33 2013
From: gregkh at linuxfoundation.org (Greg KH)
Date: Fri, 19 Apr 2013 11:16:33 -0700
Subject: [PATCH v7 1/5] drivers: memory: Introduce Marvell EBU Device Bus
 driver
In-Reply-To: <20130419181058.GA2243@localhost>
References: <1365620644-15790-1-git-send-email-ezequiel.garcia@free-electrons.com>
 <1365620644-15790-2-git-send-email-ezequiel.garcia@free-electrons.com>
 <20130410191641.GG28693@titan.lakedaemon.net>
 <20130410194337.GA5681@kroah.com> <20130419181058.GA2243@localhost>
Message-ID: <20130419181633.GA31753@kroah.com>

On Fri, Apr 19, 2013 at 03:10:59PM -0300, Ezequiel Garcia wrote:
> Hi Greg,
> 
> On Wed, Apr 10, 2013 at 12:43:37PM -0700, Greg KH wrote:
> > > On Wed, Apr 10, 2013 at 04:04:00PM -0300, Ezequiel Garcia wrote:
> > > > Marvell EBU SoCs such as Armada 370/XP, Orion5x (88f5xxx) and
> > > > Discovery (mv78xx0) supports a Device Bus controller to access several
> > > > kinds of memories and I/O devices (NOR, NAND, SRAM, FPGA).
> > > > 
> > > > This commit adds a driver to handle this controller. So far only
> > > > Armada 370, Armada XP and Discovery SoCs are supported.
> > > > 
> > > > The driver must be registered through a device tree node;
> > > > as explained in the binding document.
> > > > 
> > > > For each child node in the device tree, this driver will:
> > > >   * set timing parameters
> > > >   * register a child device
> > > >   * setup an address decoding window, using the mbus driver
> > > > 
> > > > Keep in mind the address decoding window setup is only a temporary hack.
> > > > This code will be removed from this devbus driver as soon as a proper device
> > > > tree binding for the mbus driver is added.
> > > > 
> > > > Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
> > > > Acked-by: Arnd Bergmann <arnd at arndb.de>
> > > > ---
> > > >  .../bindings/memory-controllers/mvebu-devbus.txt   | 156 ++++++++++
> > > >  drivers/memory/Kconfig                             |  10 +
> > > >  drivers/memory/Makefile                            |   1 +
> > > >  drivers/memory/mvebu-devbus.c                      | 340 +++++++++++++++++++++
> > > >  4 files changed, 507 insertions(+)
> > > >  create mode 100644 Documentation/devicetree/bindings/memory-controllers/mvebu-devbus.txt
> > > >  create mode 100644 drivers/memory/mvebu-devbus.c
> > > 
> > > As every commit to drivers/memory has been signed by you, would you like
> > > to take this patch through your tree?  Or, I'll take it through arm-soc
> > > with your Ack to keep the series together.
> > 
> > Sure, feel free to take this through your tree and add:
> > 
> > Acked-by: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
> 
> Olof (in Cc) has just decided to drop the entire pull request from
> Jason Cooper which contained this driver.
> This means this patch will have to wait until v3.11.
> 
> The reasons for dropping the pull was because of a build error on powerpc64,
> completely unrelated to this driver, the faulty commit was 9ecbe03ae85b
> ("pci: infrastructure to add drivers in drivers/pci/host").
> 
> Is it possible that you take this patch instead, so it can make it in v3.10?

Sure, resend it to me today please.

thanks,

greg k-h


From tony at atomide.com  Fri Apr 19 14:18:26 2013
From: tony at atomide.com (Tony Lindgren)
Date: Fri, 19 Apr 2013 11:18:26 -0700
Subject: Multiple issues with omap4 panda es in linux next
In-Reply-To: <517184A2.9020908@ti.com>
References: <20130419171318.GK10155@atomide.com> <517181B2.9070302@ti.com>
 <20130419174454.GM10155@atomide.com> <517184A2.9020908@ti.com>
Message-ID: <20130419181825.GN10155@atomide.com>

* Santosh Shilimkar <santosh.shilimkar at ti.com> [130419 10:56]:
> On Friday 19 April 2013 11:14 PM, Tony Lindgren wrote:
> > * Santosh Shilimkar <santosh.shilimkar at ti.com> [130419 10:43]:
> >> On Friday 19 April 2013 10:43 PM, Tony Lindgren wrote:
> >>> Hi all,
> >>>
> >>> Here's a list of breakage I've noticed so far while trying to
> >>> use linux next on my pandaboard es. Probably similar issues exist
> >>> on other boards as well.
> >>>
> >>> Ideally we would not have any breakage by the merge window, so
> >>> let's try to get these fixed ASAP:
> >>>
> >>> 1. Serial console broken on panda es booting with DT
> >>>
> >>> The symptoms are dmesg output stopping after few lines
> >>> and only continuing after pressing a key. Does not seem to
> >>> happen on blaze with DT for some reason. And does not happen
> >>> on panda es with legacy booting.
> >>>
> >> This one is known and reported on list along with fix patches and
> >> later pull request [1].
> >>
> >> Unfortunately with all the testing and everything and patches have
> >> been on the list for quite some time, feedback on one of the patch
> >> received was after pull request and then there was no further
> >> clarification. That series address the same exact issue you have
> >> mentioned above.
> > 
> > OK thanks. I think Paul picked some of those and the plan was
> > to update the branch? Which one(s) should go into v3.10 as fixes?
> > 
> Main in that series was to handle driver sysc handling withing hwmod
> layer and that is where the series got stuck [2]. Without that support
> other patches won't fix the issue.

OK it seems that that is still ongoing discussion. For v3.10 we should
probably just disable PM for omap4 for DT booting so people can use
it for DT related development.

Regards,

Tony
 
> >> [1] http://patchwork.ozlabs.org/patch/229269/
> 
> [2] https://patchwork.kernel.org/patch/2166931/
> 


From wsa at the-dreams.de  Fri Apr 19 14:35:08 2013
From: wsa at the-dreams.de (Wolfram Sang)
Date: Fri, 19 Apr 2013 20:35:08 +0200
Subject: [PATCH] I2C: EXYNOS: High speed mode clock setting for HSI2C
In-Reply-To: <1366372583-7584-1-git-send-email-yuvaraj.cd@samsung.com>
References: <1366372583-7584-1-git-send-email-yuvaraj.cd@samsung.com>
Message-ID: <20130419183508.GC3702@the-dreams.de>

On Fri, Apr 19, 2013 at 05:26:23PM +0530, Yuvaraj Kumar C D wrote:
> This patch configure the High speed mode timing register using the
> clock speed mentioned in the dts file.Also it configure the MASTER_ID
> for High speed i2c transfer.
> For i2c high speed transaction, tarnsaction initially starts with the
> fast mode i,e 400Kbits/sec and then switches to high speed mode.For this
> purpose it requires to set up timing value for fast mode and high speed
> mode.
> 
> Signed-off-by: Yuvaraj Kumar C D <yuvaraj.cd at samsung.com>

Since the exynos5 driver needs to be resent anyhow, I assume this will
be included in the next version? Please note that I had comments
regarding the bindings of the bus speed. We have a generic binding for
that already.

Thanks,

   Wolfram



From olof at lixom.net  Fri Apr 19 14:45:18 2013
From: olof at lixom.net (Olof Johansson)
Date: Fri, 19 Apr 2013 11:45:18 -0700
Subject: [GIT PULL] omap dss board clean-up for v3.10 merge window
In-Reply-To: <20130418033936.GC10155@atomide.com>
References: <20130418033936.GC10155@atomide.com>
Message-ID: <20130419184518.GA30836@quad.lixom.net>

Hi,

On Wed, Apr 17, 2013 at 08:39:37PM -0700, Tony Lindgren wrote:
> The following changes since commit 07961ac7c0ee8b546658717034fe692fd12eefa9:
> 
>   Linux 3.9-rc5 (2013-03-31 15:12:43 -0700)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.10/dss-signed


Merged, but not happy about it.

As mentioned on IRC, I was going to let this one be until 3.11, but it sounds
like it will cause regressions in DSS if we don't merge it.

This is an indication that the work wasn't done right on the DSS rework.
Ideally the old configurations through platform_data should have been left in
for a release to give the boards a window to convert over without regressing
functionality. Tomi, please don't do it this way in the future since it's
painful for everybody to deal with.

I've queued this with late/cleanup. I noticed some conflicts with the previous
omap/fixes-non-critical and omap/boards branches that I brought in as a base so
I could fix it up in my merge instead of having it go all the way up to Linus
to resolve.


-Olof


From olof at lixom.net  Fri Apr 19 14:49:30 2013
From: olof at lixom.net (Olof Johansson)
Date: Fri, 19 Apr 2013 11:49:30 -0700
Subject: [GIT PULL] at91: soc for 3.10 #3
In-Reply-To: <1366296702-26436-1-git-send-email-nicolas.ferre@atmel.com>
References: <1366296702-26436-1-git-send-email-nicolas.ferre@atmel.com>
Message-ID: <20130419184930.GB30836@quad.lixom.net>

Hi Nicolas,

On Thu, Apr 18, 2013 at 04:51:42PM +0200, Nicolas Ferre wrote:
> Arnd, Olof,
> 
> Third pull-request for AT91 SoC support based on material that you already have
> in your arm-soc/at91/soc branch.
> Not very core changes here but interesting enhancements.
> 
> Thanks, best regards,
> 
> The following changes since commit 471c9e786596c4f028c67c7e9de0703b49cab2a9:
> 
>   ARM: at91: add defconfig for SAMA5 (2013-03-26 12:18:05 +0100)
> 
> are available in the git repository at:
> 
>   git://github.com/at91linux/linux-at91.git tags/at91-soc

The warning makes sense to pick up now, and the other patch seems well
contained and harmless.

I'll merge this branch into late/cleanup even though it is getting very
close to the merge window.


-Olof


From arnd at arndb.de  Fri Apr 19 14:59:38 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 19 Apr 2013 20:59:38 +0200
Subject: [PATCH] cpufreq: exynos: allow disabling cpufreq drivers
In-Reply-To: <51717623.2060709@samsung.com>
References: <201304191554.29679.arnd@arndb.de> <51717623.2060709@samsung.com>
Message-ID: <201304192059.38606.arnd@arndb.de>

On Friday 19 April 2013, Sylwester Nawrocki wrote:
> Not sure what happened here, but my and Tomasz's Tested-by were given 
> for v5 of the patch series including 6e6aac7590, while it seems v6 
> has been applied. And the patch is not same in both series.

I see.

> There could be some differences in the base tree I used when testing 
> this [1] series, as it was hard to determine against what tag it was 
> created exactly. Also I didn't test in on all platforms, only 
> Exynos4412.

Maybe you just didn't have CPUFREQ enabled? I also didn't notice this
bug at first because it is turned off in the defconfigs.

It could also be working by chance on EXYNOS4, since the register
definitions were not actually removed from the regs-clk.h header
for those.

	Arnd


From s.gottschall at dd-wrt.com  Fri Apr 19 14:07:15 2013
From: s.gottschall at dd-wrt.com (Sebastian Gottschall)
Date: Fri, 19 Apr 2013 20:07:15 +0200
Subject: arm: ARM_VIRT_EXT is not supported by all v7 platforms, so it should
 not be enabled by default
Message-ID: <kks14c$e4p$1@ger.gmane.org>

introduced in kernel 3.9 CONFIG_ARM_VIRT_EXT is default for all V7 arm 
cpu's. this is wrong and breaks smp support on BCM4708 for example.
so keep it optional since no all v7 cpu's seem to support it. BCM4708 
for instance is a arm cortex-a9. please merge this into one of the next 
patches.


Index: arch/arm/mm/Kconfig
===================================================================
--- arch/arm/mm/Kconfig     (revision 21211)
+++ arch/arm/mm/Kconfig     (working copy)
@@ -640,8 +640,7 @@

  config ARM_VIRT_EXT
         bool
-       depends on MMU
-       default y if CPU_V7
+       depends on MMU && CPU_V7
         help
           Enable the kernel to make use of the ARM Virtualization
           Extensions to install hypervisors without run-time firmware




From tony at atomide.com  Fri Apr 19 15:33:46 2013
From: tony at atomide.com (Tony Lindgren)
Date: Fri, 19 Apr 2013 12:33:46 -0700
Subject: [GIT PULL] omap dss board clean-up for v3.10 merge window
In-Reply-To: <20130419184518.GA30836@quad.lixom.net>
References: <20130418033936.GC10155@atomide.com>
 <20130419184518.GA30836@quad.lixom.net>
Message-ID: <20130419193346.GO10155@atomide.com>

* Olof Johansson <olof at lixom.net> [130419 11:50]:
> Hi,
> 
> On Wed, Apr 17, 2013 at 08:39:37PM -0700, Tony Lindgren wrote:
> > The following changes since commit 07961ac7c0ee8b546658717034fe692fd12eefa9:
> > 
> >   Linux 3.9-rc5 (2013-03-31 15:12:43 -0700)
> > 
> > are available in the git repository at:
> > 
> >   git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.10/dss-signed
> 
> 
> Merged, but not happy about it.
> 
> As mentioned on IRC, I was going to let this one be until 3.11, but it sounds
> like it will cause regressions in DSS if we don't merge it.
> 
> This is an indication that the work wasn't done right on the DSS rework.
> Ideally the old configurations through platform_data should have been left in
> for a release to give the boards a window to convert over without regressing
> functionality. Tomi, please don't do it this way in the future since it's
> painful for everybody to deal with.

Yes sorry this should have been done already few weeks ago when these
patches hit linux next via Tomi's tree. In the future, let's plan on doing
the shared branches early on between -rc2 and -rc4 so we don't all have to
scramble just before the merge window.

> I've queued this with late/cleanup. I noticed some conflicts with the previous
> omap/fixes-non-critical and omap/boards branches that I brought in as a base so
> I could fix it up in my merge instead of having it go all the way up to Linus
> to resolve.

OK thanks.

Tony


From tony at atomide.com  Fri Apr 19 15:43:24 2013
From: tony at atomide.com (Tony Lindgren)
Date: Fri, 19 Apr 2013 12:43:24 -0700
Subject: linux-next ARM multi-platform randconfig errors
In-Reply-To: <517173C0.6010902@ti.com>
References: <5170B4C6.1030300@gmail.com> <20130419161257.GI10155@atomide.com>
 <517173C0.6010902@ti.com>
Message-ID: <20130419194323.GP10155@atomide.com>

* Tomi Valkeinen <tomi.valkeinen at ti.com> [130419 09:46]:
> On 2013-04-19 19:12, Tony Lindgren wrote:
> > * Rob Herring <robherring2 at gmail.com> [130418 20:11]:
> 
> >> dss-common.c:(.cpuinit.text+0x38): undefined reference to `omap_get_wakeupgen_base'
> >> dss-common.c:(.cpuinit.text+0x48): undefined reference to `omap_secure_apis_support'
> >> dss-common.c:(.init.text+0x3db0): undefined reference to `omap_get_wakeupgen_base'
> >> dss-common.c:(.init.text+0x3dcc): undefined reference to `omap_secure_apis_support'
> >> dss-common.c:(.init.text+0x61b8): undefined reference to `usb_bind_phy'
> >> dss-common.c:(.init.text+0x6314): undefined reference to `usb_bind_phy'
> >> dss-common.c:(.init.text+0x6488): undefined reference to `usb_bind_phy'
> >> dss-common.c:(.init.text+0x65ac): undefined reference to `usb_bind_phy'
> >> dss-common.c:(.ref.text+0x10): undefined reference to `omap_get_wakeupgen_base'
> >> dss-common.c:(.ref.text+0x18): undefined reference to `omap_secure_apis_support'
> >> dss-common.c:(.ref.text+0x54): undefined reference to `omap4_hotplug_cpu'
> >> dss-common.c:(.ref.text+0x58): undefined reference to `omap_secure_apis_support'
> >> dss-common.c:(.text+0x11b5c): undefined reference to `usb_bind_phy'
> > 
> > Tomi, can you take a look at the dss-common.c one? That should be
> > reproducable with omap2plus_defconfig and modifying some options
> > there.
> 
> None of those functions are used by dss-common.c, so I don't really know
> what that is about. Doesn't look correct errors to me... I can try to
> reproduce.

This might happen when no SoC selected. There was a patch posted
by Arnd to always select 2420 if nothing else is selected as it's the
most minimal one. But Russell did not like that, so probably the way
to fix that would be to have bool OMAP_SOC and if not selected, don't
even try to build anything. I'll take a look at that.

> Btw, there's also this:
> 
> >> drivers/video/omap2/dss/dpi.c:181:2: error: implicit declaration of function 'dsi_hsdiv_calc' [-Werror=implicit-function-declaration]
> >> drivers/video/omap2/dss/dpi.c:201:2: error: implicit declaration of function 'dsi_get_pll_clkin' [-Werror=implicit-function-declaration]
> >> drivers/video/omap2/dss/dpi.c:212:2: error: implicit declaration of function 'dsi_pll_calc' [-Werror=implicit-function-declaration]
> 
> I have a patch for that, not yet applied.

OK thanks.

Tony
-------------- next part --------------
#
# Automatically generated file; DO NOT EDIT.
# Linux/arm 3.9.0-rc7 Kernel Configuration
#
CONFIG_ARM=y
CONFIG_SYS_SUPPORTS_APM_EMULATION=y
CONFIG_HAVE_TCM=y
CONFIG_HAVE_PROC_CPU=y
CONFIG_NO_IOPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_RWSEM_GENERIC_SPINLOCK=y
CONFIG_ARCH_HAS_CPUFREQ=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ZONE_DMA=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_VECTORS_BASE=0xffff0000
CONFIG_ARM_PATCH_PHYS_VIRT=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_CONSTRUCTORS=y
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y

#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
# CONFIG_SWAP is not set
# CONFIG_SYSVIPC is not set
# CONFIG_POSIX_MQUEUE is not set
CONFIG_FHANDLE=y
CONFIG_AUDIT=y
CONFIG_AUDITSYSCALL=y
CONFIG_AUDIT_WATCH=y
CONFIG_AUDIT_TREE=y
CONFIG_AUDIT_LOGINUID_IMMUTABLE=y
CONFIG_HAVE_GENERIC_HARDIRQS=y

#
# IRQ subsystem
#
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_HARDIRQS_SW_RESEND=y
CONFIG_GENERIC_IRQ_CHIP=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_DOMAIN_DEBUG=y
CONFIG_SPARSE_IRQ=y
# CONFIG_ALWAYS_USE_PERSISTENT_CLOCK is not set
CONFIG_KTIME_SCALAR=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_ARCH_HAS_TICK_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y

#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_PERIODIC_HZ=y
# CONFIG_NO_HZ_IDLE is not set
CONFIG_HIGH_RES_TIMERS=y

#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_BSD_PROCESS_ACCT is not set
CONFIG_TASKSTATS=y
# CONFIG_TASK_DELAY_ACCT is not set
CONFIG_TASK_XACCT=y
# CONFIG_TASK_IO_ACCOUNTING is not set

#
# RCU Subsystem
#
CONFIG_TREE_RCU=y
# CONFIG_PREEMPT_RCU is not set
CONFIG_RCU_STALL_COMMON=y
# CONFIG_RCU_USER_QS is not set
CONFIG_RCU_FANOUT=32
CONFIG_RCU_FANOUT_LEAF=16
# CONFIG_RCU_FANOUT_EXACT is not set
CONFIG_TREE_RCU_TRACE=y
CONFIG_RCU_NOCB_CPU=y
CONFIG_RCU_NOCB_CPU_NONE=y
# CONFIG_RCU_NOCB_CPU_ZERO is not set
# CONFIG_RCU_NOCB_CPU_ALL is not set
# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=17
CONFIG_CGROUPS=y
# CONFIG_CGROUP_DEBUG is not set
# CONFIG_CGROUP_FREEZER is not set
CONFIG_CGROUP_DEVICE=y
CONFIG_CPUSETS=y
CONFIG_PROC_PID_CPUSET=y
# CONFIG_CGROUP_CPUACCT is not set
# CONFIG_RESOURCE_COUNTERS is not set
# CONFIG_CGROUP_PERF is not set
CONFIG_CGROUP_SCHED=y
CONFIG_FAIR_GROUP_SCHED=y
CONFIG_CFS_BANDWIDTH=y
# CONFIG_RT_GROUP_SCHED is not set
CONFIG_BLK_CGROUP=y
CONFIG_DEBUG_BLK_CGROUP=y
# CONFIG_CHECKPOINT_RESTORE is not set
CONFIG_NAMESPACES=y
CONFIG_UTS_NS=y
CONFIG_PID_NS=y
# CONFIG_NET_NS is not set
CONFIG_SCHED_AUTOGROUP=y
CONFIG_SYSFS_DEPRECATED=y
# CONFIG_SYSFS_DEPRECATED_V2 is not set
# CONFIG_RELAY is not set
# CONFIG_BLK_DEV_INITRD is not set
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_ANON_INODES=y
CONFIG_EXPERT=y
CONFIG_HAVE_UID16=y
CONFIG_UID16=y
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
CONFIG_HOTPLUG=y
# CONFIG_PRINTK is not set
# CONFIG_BUG is not set
# CONFIG_BASE_FULL is not set
CONFIG_FUTEX=y
# CONFIG_EPOLL is not set
CONFIG_SIGNALFD=y
# CONFIG_TIMERFD is not set
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
# CONFIG_AIO is not set
CONFIG_EMBEDDED=y
CONFIG_HAVE_PERF_EVENTS=y
CONFIG_PERF_USE_VMALLOC=y

#
# Kernel Performance Events And Counters
#
CONFIG_PERF_EVENTS=y
CONFIG_DEBUG_PERF_USE_VMALLOC=y
# CONFIG_VM_EVENT_COUNTERS is not set
# CONFIG_SLUB_DEBUG is not set
CONFIG_COMPAT_BRK=y
# CONFIG_SLAB is not set
CONFIG_SLUB=y
# CONFIG_SLOB is not set
CONFIG_PROFILING=y
CONFIG_OPROFILE=y
CONFIG_HAVE_OPROFILE=y
CONFIG_JUMP_LABEL=y
# CONFIG_HAVE_64BIT_ALIGNED_ACCESS is not set
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
CONFIG_HAVE_ARCH_TRACEHOOK=y
CONFIG_HAVE_DMA_ATTRS=y
CONFIG_HAVE_DMA_CONTIGUOUS=y
CONFIG_USE_GENERIC_SMP_HELPERS=y
CONFIG_GENERIC_SMP_IDLE_THREAD=y
CONFIG_GENERIC_IDLE_LOOP=y
CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y
CONFIG_HAVE_CLK=y
CONFIG_HAVE_DMA_API_DEBUG=y
CONFIG_HAVE_HW_BREAKPOINT=y
CONFIG_HAVE_ARCH_JUMP_LABEL=y
CONFIG_ARCH_WANT_IPC_PARSE_VERSION=y
CONFIG_HAVE_ARCH_SECCOMP_FILTER=y
CONFIG_SECCOMP_FILTER=y
CONFIG_HAVE_CONTEXT_TRACKING=y
CONFIG_MODULES_USE_ELF_REL=y
CONFIG_CLONE_BACKWARDS=y
CONFIG_OLD_SIGSUSPEND3=y
CONFIG_OLD_SIGACTION=y

#
# GCOV-based kernel profiling
#
CONFIG_GCOV_KERNEL=y
CONFIG_HAVE_GENERIC_DMA_COHERENT=y
CONFIG_RT_MUTEXES=y
CONFIG_BASE_SMALL=1
# CONFIG_MODULES is not set
CONFIG_BLOCK=y
# CONFIG_LBDAF is not set
CONFIG_BLK_DEV_BSG=y
# CONFIG_BLK_DEV_BSGLIB is not set
CONFIG_BLK_DEV_INTEGRITY=y
# CONFIG_BLK_DEV_THROTTLING is not set

#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
CONFIG_OSF_PARTITION=y
CONFIG_AMIGA_PARTITION=y
CONFIG_ATARI_PARTITION=y
CONFIG_MAC_PARTITION=y
CONFIG_MSDOS_PARTITION=y
# CONFIG_BSD_DISKLABEL is not set
# CONFIG_MINIX_SUBPARTITION is not set
CONFIG_SOLARIS_X86_PARTITION=y
# CONFIG_UNIXWARE_DISKLABEL is not set
# CONFIG_LDM_PARTITION is not set
CONFIG_SGI_PARTITION=y
# CONFIG_ULTRIX_PARTITION is not set
CONFIG_SUN_PARTITION=y
# CONFIG_KARMA_PARTITION is not set
CONFIG_EFI_PARTITION=y
# CONFIG_SYSV68_PARTITION is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
# CONFIG_IOSCHED_DEADLINE is not set
CONFIG_IOSCHED_CFQ=y
CONFIG_CFQ_GROUP_IOSCHED=y
CONFIG_DEFAULT_CFQ=y
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="cfq"
CONFIG_PADATA=y
CONFIG_UNINLINE_SPIN_UNLOCK=y
# CONFIG_FREEZER is not set

#
# System Type
#
CONFIG_MMU=y
CONFIG_ARCH_MULTIPLATFORM=y
# CONFIG_ARCH_INTEGRATOR is not set
# CONFIG_ARCH_REALVIEW is not set
# CONFIG_ARCH_VERSATILE is not set
# CONFIG_ARCH_AT91 is not set
# CONFIG_ARCH_CLPS711X is not set
# CONFIG_ARCH_GEMINI is not set
# CONFIG_ARCH_EBSA110 is not set
# CONFIG_ARCH_EP93XX is not set
# CONFIG_ARCH_FOOTBRIDGE is not set
# CONFIG_ARCH_NETX is not set
# CONFIG_ARCH_IOP13XX is not set
# CONFIG_ARCH_IOP32X is not set
# CONFIG_ARCH_IOP33X is not set
# CONFIG_ARCH_IXP4XX is not set
# CONFIG_ARCH_DOVE is not set
# CONFIG_ARCH_KIRKWOOD is not set
# CONFIG_ARCH_MV78XX0 is not set
# CONFIG_ARCH_ORION5X is not set
# CONFIG_ARCH_MMP is not set
# CONFIG_ARCH_KS8695 is not set
# CONFIG_ARCH_W90X900 is not set
# CONFIG_ARCH_LPC32XX is not set
# CONFIG_ARCH_PXA is not set
# CONFIG_ARCH_MSM is not set
# CONFIG_ARCH_SHMOBILE is not set
# CONFIG_ARCH_RPC is not set
# CONFIG_ARCH_SA1100 is not set
# CONFIG_ARCH_S3C24XX is not set
# CONFIG_ARCH_S3C64XX is not set
# CONFIG_ARCH_S5P64X0 is not set
# CONFIG_ARCH_S5PC100 is not set
# CONFIG_ARCH_S5PV210 is not set
# CONFIG_ARCH_EXYNOS is not set
# CONFIG_ARCH_SHARK is not set
# CONFIG_ARCH_U300 is not set
# CONFIG_ARCH_DAVINCI is not set
# CONFIG_ARCH_OMAP1 is not set

#
# Multiple platform selection
#

#
# CPU Core family selection
#
CONFIG_ARCH_MULTI_V6=y
CONFIG_ARCH_MULTI_V7=y
CONFIG_ARCH_MULTI_V6_V7=y
# CONFIG_ARCH_MULTI_CPU_AUTO is not set
CONFIG_ARCH_MVEBU=y

#
# Marvell SOC with device tree
#
CONFIG_MACH_ARMADA_370_XP=y
CONFIG_MACH_ARMADA_370=y
# CONFIG_MACH_ARMADA_XP is not set
CONFIG_ARCH_BCM=y
# CONFIG_ARCH_BCM2835 is not set
# CONFIG_ARCH_CNS3XXX is not set
# CONFIG_GPIO_PCA953X is not set
CONFIG_ARCH_HIGHBANK=y
# CONFIG_ARCH_MXC is not set

#
# TI OMAP Common Features
#

#
# OMAP Feature Selections
#
# CONFIG_POWER_AVS_OMAP is not set
# CONFIG_OMAP_RESET_CLOCKS is not set
CONFIG_OMAP_MUX=y
CONFIG_OMAP_MUX_DEBUG=y
CONFIG_OMAP_MUX_WARNINGS=y
# CONFIG_OMAP_32K_TIMER is not set
# CONFIG_OMAP3_L2_AUX_SECURE_SAVE_RESTORE is not set
CONFIG_OMAP_DM_TIMER=y
CONFIG_OMAP_PM_NOOP=y
# CONFIG_MACH_OMAP_GENERIC is not set
CONFIG_ARCH_OMAP=y
CONFIG_ARCH_OMAP2PLUS=y

#
# TI OMAP2/3/4 Specific Features
#
CONFIG_ARCH_OMAP2PLUS_TYPICAL=y
CONFIG_SOC_HAS_OMAP2_SDRC=y
CONFIG_ARCH_OMAP2=y
CONFIG_ARCH_OMAP3=y
# CONFIG_ARCH_OMAP4 is not set
# CONFIG_SOC_OMAP5 is not set

#
# OMAP Core Type
#
# CONFIG_SOC_OMAP2420 is not set
# CONFIG_SOC_OMAP2430 is not set
CONFIG_SOC_OMAP3430=y
CONFIG_SOC_TI81XX=y
CONFIG_SOC_AM33XX=y
CONFIG_OMAP_PACKAGE_CBB=y
CONFIG_OMAP_PACKAGE_CUS=y
CONFIG_OMAP_PACKAGE_CBP=y

#
# OMAP Board Type
#
CONFIG_MACH_OMAP3_BEAGLE=y
CONFIG_MACH_DEVKIT8000=y
CONFIG_MACH_OMAP_LDP=y
CONFIG_MACH_OMAP3530_LV_SOM=y
CONFIG_MACH_OMAP3_TORPEDO=y
# CONFIG_MACH_OVERO is not set
# CONFIG_MACH_OMAP3EVM is not set
CONFIG_MACH_OMAP3517EVM=y
CONFIG_MACH_CRANEBOARD=y
# CONFIG_MACH_OMAP3_PANDORA is not set
CONFIG_MACH_TOUCHBOOK=y
CONFIG_MACH_OMAP_3430SDP=y
# CONFIG_MACH_NOKIA_RM680 is not set
# CONFIG_MACH_NOKIA_RX51 is not set
# CONFIG_MACH_OMAP_ZOOM2 is not set
CONFIG_MACH_OMAP_ZOOM3=y
CONFIG_MACH_CM_T35=y
# CONFIG_MACH_CM_T3517 is not set
CONFIG_MACH_CM_T3730=y
# CONFIG_MACH_IGEP0020 is not set
# CONFIG_MACH_IGEP0030 is not set
CONFIG_MACH_SBC3530=y
# CONFIG_MACH_OMAP_3630SDP is not set
# CONFIG_MACH_TI8168EVM is not set
CONFIG_MACH_TI8148EVM=y
CONFIG_OMAP3_EMU=y
# CONFIG_OMAP3_SDRC_AC_TIMING is not set
CONFIG_ARCH_PICOXCELL=y
CONFIG_ARCH_SOCFPGA=y
# CONFIG_PLAT_SPEAR is not set
CONFIG_ARCH_SUNXI=y
CONFIG_ARCH_SIRF=y

#
# CSR SiRF atlas6/primaII/Marco/Polo Specific Features
#
# CONFIG_ARCH_ATLAS6 is not set
CONFIG_ARCH_PRIMA2=y
CONFIG_ARCH_MARCO=y
CONFIG_SIRF_IRQ=y
# CONFIG_ARCH_TEGRA is not set
CONFIG_ARCH_U8500=y
CONFIG_UX500_SOC_COMMON=y
CONFIG_UX500_SOC_DB8500=y

#
# Ux500 target platform (boards)
#
CONFIG_MACH_MOP500=y
# CONFIG_MACH_HREFV60 is not set
# CONFIG_MACH_SNOWBALL is not set
CONFIG_UX500_AUTO_PLATFORM=y
# CONFIG_MACH_UX500_DT is not set
CONFIG_UX500_DEBUG_UART=2
CONFIG_ARCH_VEXPRESS=y

#
# Versatile Express platform type
#
CONFIG_ARCH_VEXPRESS_CORTEX_A5_A9_ERRATA=y
# CONFIG_ARCH_VEXPRESS_CA9X4 is not set
CONFIG_PLAT_VERSATILE_CLCD=y
CONFIG_PLAT_VERSATILE_SCHED_CLOCK=y
CONFIG_ARCH_VIRT=y
# CONFIG_ARCH_WM8750 is not set
# CONFIG_ARCH_WM8850 is not set
# CONFIG_ARCH_ZYNQ is not set
CONFIG_PLAT_ORION=y
CONFIG_PLAT_VERSATILE=y
CONFIG_ARM_TIMER_SP804=y

#
# Processor Type
#
CONFIG_CPU_PJ4B=y
CONFIG_CPU_V6=y
CONFIG_CPU_V6K=y
CONFIG_CPU_V7=y
CONFIG_CPU_32v6=y
CONFIG_CPU_32v6K=y
CONFIG_CPU_32v7=y
CONFIG_CPU_ABRT_EV6=y
CONFIG_CPU_ABRT_EV7=y
CONFIG_CPU_PABRT_V6=y
CONFIG_CPU_PABRT_V7=y
CONFIG_CPU_CACHE_V6=y
CONFIG_CPU_CACHE_V7=y
CONFIG_CPU_CACHE_VIPT=y
CONFIG_CPU_COPY_V6=y
CONFIG_CPU_TLB_V6=y
CONFIG_CPU_TLB_V7=y
CONFIG_CPU_HAS_ASID=y
CONFIG_CPU_CP15=y
CONFIG_CPU_CP15_MMU=y
CONFIG_CPU_USE_DOMAINS=y

#
# Processor Features
#
# CONFIG_ARCH_PHYS_ADDR_T_64BIT is not set
CONFIG_ARM_THUMB=y
CONFIG_ARM_THUMBEE=y
CONFIG_ARM_VIRT_EXT=y
# CONFIG_CPU_ICACHE_DISABLE is not set
CONFIG_CPU_DCACHE_DISABLE=y
CONFIG_CPU_BPREDICT_DISABLE=y
# CONFIG_DMA_CACHE_RWFO is not set
CONFIG_OUTER_CACHE=y
CONFIG_OUTER_CACHE_SYNC=y
CONFIG_MIGHT_HAVE_CACHE_L2X0=y
CONFIG_CACHE_L2X0=y
CONFIG_ARM_L1_CACHE_SHIFT_6=y
CONFIG_ARM_L1_CACHE_SHIFT=6
CONFIG_ARM_DMA_MEM_BUFFERABLE=y
CONFIG_ARM_NR_BANKS=8
CONFIG_MULTI_IRQ_HANDLER=y
CONFIG_ARM_ERRATA_326103=y
# CONFIG_ARM_ERRATA_411920 is not set
# CONFIG_ARM_ERRATA_430973 is not set
CONFIG_PL310_ERRATA_588369=y
CONFIG_ARM_ERRATA_720789=y
# CONFIG_PL310_ERRATA_727915 is not set
CONFIG_ARM_ERRATA_754322=y
# CONFIG_ARM_ERRATA_754327 is not set
CONFIG_ARM_ERRATA_764369=y
CONFIG_PL310_ERRATA_769419=y
CONFIG_ARM_ERRATA_775420=y
CONFIG_ARM_ERRATA_798181=y
CONFIG_ICST=y

#
# Bus support
#
CONFIG_ARM_AMBA=y
# CONFIG_PCI_SYSCALL is not set
# CONFIG_PCCARD is not set

#
# Kernel Features
#
CONFIG_HAVE_SMP=y
CONFIG_SMP=y
CONFIG_SMP_ON_UP=y
CONFIG_ARM_CPU_TOPOLOGY=y
# CONFIG_SCHED_MC is not set
# CONFIG_SCHED_SMT is not set
CONFIG_HAVE_ARM_SCU=y
CONFIG_HAVE_ARM_ARCH_TIMER=y
CONFIG_VMSPLIT_3G=y
# CONFIG_VMSPLIT_2G is not set
# CONFIG_VMSPLIT_1G is not set
CONFIG_PAGE_OFFSET=0xC0000000
CONFIG_NR_CPUS=4
# CONFIG_HOTPLUG_CPU is not set
CONFIG_ARM_PSCI=y
# CONFIG_LOCAL_TIMERS is not set
CONFIG_ARCH_NR_GPIO=392
CONFIG_PREEMPT_NONE=y
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT is not set
CONFIG_HZ=100
CONFIG_SCHED_HRTICK=y
CONFIG_AEABI=y
# CONFIG_OABI_COMPAT is not set
CONFIG_ARCH_HAS_HOLES_MEMORYMODEL=y
# CONFIG_ARCH_SPARSEMEM_DEFAULT is not set
# CONFIG_ARCH_SELECT_MEMORY_MODEL is not set
CONFIG_HAVE_ARCH_PFN_VALID=y
CONFIG_HIGHMEM=y
# CONFIG_HIGHPTE is not set
# CONFIG_HW_PERF_EVENTS is not set
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
CONFIG_HAVE_MEMBLOCK=y
# CONFIG_HAVE_BOOTMEM_INFO_NODE is not set
CONFIG_PAGEFLAGS_EXTENDED=y
CONFIG_SPLIT_PTLOCK_CPUS=999999
CONFIG_COMPACTION=y
CONFIG_MIGRATION=y
# CONFIG_PHYS_ADDR_T_64BIT is not set
CONFIG_ZONE_DMA_FLAG=1
CONFIG_BOUNCE=y
CONFIG_NEED_BOUNCE_POOL=y
# CONFIG_KSM is not set
CONFIG_DEFAULT_MMAP_MIN_ADDR=4096
# CONFIG_CROSS_MEMORY_ATTACH is not set
# CONFIG_CLEANCACHE is not set
CONFIG_FORCE_MAX_ZONEORDER=12
CONFIG_ALIGNMENT_TRAP=y
# CONFIG_UACCESS_WITH_MEMCPY is not set
CONFIG_SECCOMP=y
# CONFIG_CC_STACKPROTECTOR is not set

#
# Boot options
#
CONFIG_USE_OF=y
# CONFIG_ATAGS is not set
CONFIG_ZBOOT_ROM_TEXT=0
CONFIG_ZBOOT_ROM_BSS=0
CONFIG_ARM_APPENDED_DTB=y
CONFIG_ARM_ATAG_DTB_COMPAT=y
CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER=y
# CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND is not set
CONFIG_CMDLINE=""
CONFIG_CRASH_DUMP=y
CONFIG_AUTO_ZRELADDR=y

#
# CPU Power Management
#

#
# CPU Frequency scaling
#
# CONFIG_CPU_FREQ is not set
CONFIG_CPU_IDLE=y
CONFIG_CPU_IDLE_MULTIPLE_DRIVERS=y
CONFIG_CPU_IDLE_GOV_LADDER=y
# CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED is not set
# CONFIG_CPU_IDLE_CALXEDA is not set

#
# Floating point emulation
#

#
# At least one emulation must be selected
#
CONFIG_VFP=y
CONFIG_VFPv3=y
CONFIG_NEON=y

#
# Userspace binary formats
#
CONFIG_BINFMT_ELF=y
CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE=y
CONFIG_BINFMT_SCRIPT=y
CONFIG_HAVE_AOUT=y
# CONFIG_BINFMT_AOUT is not set
CONFIG_BINFMT_MISC=y
# CONFIG_COREDUMP is not set

#
# Power management options
#
# CONFIG_SUSPEND is not set
CONFIG_PM_RUNTIME=y
CONFIG_PM=y
# CONFIG_PM_DEBUG is not set
CONFIG_APM_EMULATION=y
CONFIG_ARCH_HAS_OPP=y
CONFIG_PM_OPP=y
CONFIG_PM_CLK=y
CONFIG_CPU_PM=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARM_CPU_SUSPEND=y
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
CONFIG_PACKET_DIAG=y
# CONFIG_UNIX is not set
# CONFIG_NET_KEY is not set
# CONFIG_INET is not set
# CONFIG_NETWORK_SECMARK is not set
# CONFIG_NETWORK_PHY_TIMESTAMPING is not set
# CONFIG_NETFILTER is not set
# CONFIG_ATM is not set
CONFIG_STP=y
CONFIG_GARP=y
CONFIG_MRP=y
CONFIG_BRIDGE=y
CONFIG_BRIDGE_VLAN_FILTERING=y
CONFIG_VLAN_8021Q=y
CONFIG_VLAN_8021Q_GVRP=y
CONFIG_VLAN_8021Q_MVRP=y
CONFIG_DECNET=y
# CONFIG_DECNET_ROUTER is not set
CONFIG_LLC=y
CONFIG_LLC2=y
CONFIG_IPX=y
# CONFIG_IPX_INTERN is not set
CONFIG_ATALK=y
# CONFIG_DEV_APPLETALK is not set
CONFIG_X25=y
# CONFIG_LAPB is not set
# CONFIG_PHONET is not set
# CONFIG_IEEE802154 is not set
# CONFIG_NET_SCHED is not set
CONFIG_DCB=y
CONFIG_BATMAN_ADV=y
# CONFIG_BATMAN_ADV_NC is not set
CONFIG_BATMAN_ADV_DEBUG=y
CONFIG_OPENVSWITCH=y
CONFIG_VSOCKETS=y
CONFIG_NETLINK_DIAG=y
CONFIG_RPS=y
CONFIG_RFS_ACCEL=y
CONFIG_XPS=y
# CONFIG_NETPRIO_CGROUP is not set
CONFIG_BQL=y

#
# Network testing
#
CONFIG_NET_PKTGEN=y
# CONFIG_HAMRADIO is not set
CONFIG_CAN=y
CONFIG_CAN_RAW=y
# CONFIG_CAN_BCM is not set
CONFIG_CAN_GW=y

#
# CAN Device Drivers
#
# CONFIG_CAN_VCAN is not set
# CONFIG_CAN_DEV is not set
CONFIG_CAN_DEBUG_DEVICES=y
# CONFIG_IRDA is not set
# CONFIG_BT is not set
# CONFIG_WIRELESS is not set
CONFIG_WIMAX=y
CONFIG_WIMAX_DEBUG_LEVEL=8
# CONFIG_RFKILL is not set
CONFIG_RFKILL_REGULATOR=y
# CONFIG_NET_9P is not set
# CONFIG_CAIF is not set
CONFIG_NFC=y
CONFIG_NFC_NCI=y
CONFIG_NFC_HCI=y
CONFIG_NFC_SHDLC=y
# CONFIG_NFC_LLCP is not set

#
# Near Field Communication (NFC) devices
#
CONFIG_NFC_PN533=y
CONFIG_NFC_PN544=y
# CONFIG_NFC_PN544_I2C is not set
# CONFIG_NFC_MICROREAD is not set
CONFIG_HAVE_BPF_JIT=y

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_UEVENT_HELPER_PATH=""
# CONFIG_DEVTMPFS is not set
# CONFIG_STANDALONE is not set
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
CONFIG_FIRMWARE_IN_KERNEL=y
CONFIG_EXTRA_FIRMWARE=""
CONFIG_FW_LOADER_USER_HELPER=y
CONFIG_DEBUG_DRIVER=y
# CONFIG_DEBUG_DEVRES is not set
# CONFIG_SYS_HYPERVISOR is not set
# CONFIG_GENERIC_CPU_DEVICES is not set
CONFIG_SOC_BUS=y
CONFIG_REGMAP=y
CONFIG_REGMAP_I2C=y
CONFIG_REGMAP_SPI=y
CONFIG_REGMAP_MMIO=y
CONFIG_REGMAP_IRQ=y
# CONFIG_DMA_SHARED_BUFFER is not set
# CONFIG_CMA is not set

#
# Bus devices
#
# CONFIG_OMAP_OCP2SCP is not set
CONFIG_OMAP_INTERCONNECT=y
CONFIG_CONNECTOR=y
CONFIG_PROC_EVENTS=y
# CONFIG_MTD is not set
CONFIG_DTC=y
CONFIG_OF=y

#
# Device Tree and Open Firmware support
#
CONFIG_PROC_DEVICETREE=y
CONFIG_OF_SELFTEST=y
CONFIG_OF_FLATTREE=y
CONFIG_OF_EARLY_FLATTREE=y
CONFIG_OF_ADDRESS=y
CONFIG_OF_IRQ=y
CONFIG_OF_DEVICE=y
CONFIG_OF_I2C=y
# CONFIG_PARPORT is not set
CONFIG_BLK_DEV=y
# CONFIG_BLK_DEV_COW_COMMON is not set
# CONFIG_BLK_DEV_LOOP is not set

#
# DRBD disabled because PROC_FS or INET not selected
#
CONFIG_BLK_DEV_NBD=y
# CONFIG_BLK_DEV_RAM is not set
# CONFIG_CDROM_PKTCDVD is not set
CONFIG_ATA_OVER_ETH=y
# CONFIG_MG_DISK is not set
# CONFIG_VIRTIO_BLK is not set
# CONFIG_BLOCKCONSOLE is not set

#
# Misc devices
#
# CONFIG_SENSORS_LIS3LV02D is not set
# CONFIG_AD525X_DPOT is not set
# CONFIG_ATMEL_PWM is not set
CONFIG_DUMMY_IRQ=y
CONFIG_ICS932S401=y
CONFIG_ATMEL_SSC=y
# CONFIG_ENCLOSURE_SERVICES is not set
CONFIG_APDS9802ALS=y
# CONFIG_ISL29003 is not set
CONFIG_ISL29020=y
CONFIG_SENSORS_TSL2550=y
CONFIG_SENSORS_BH1780=y
CONFIG_SENSORS_BH1770=y
CONFIG_SENSORS_APDS990X=y
# CONFIG_HMC6352 is not set
CONFIG_DS1682=y
CONFIG_TI_DAC7512=y
CONFIG_ARM_CHARLCD=y
CONFIG_BMP085=y
CONFIG_BMP085_I2C=y
# CONFIG_BMP085_SPI is not set
# CONFIG_USB_SWITCH_FSA9480 is not set
# CONFIG_LATTICE_ECP3_CONFIG is not set
CONFIG_SRAM=y
# CONFIG_C2PORT is not set

#
# EEPROM support
#
# CONFIG_EEPROM_AT24 is not set
CONFIG_EEPROM_AT25=y
# CONFIG_EEPROM_LEGACY is not set
# CONFIG_EEPROM_MAX6875 is not set
# CONFIG_EEPROM_93CX6 is not set
CONFIG_EEPROM_93XX46=y

#
# Texas Instruments shared transport line discipline
#
# CONFIG_SENSORS_LIS3_SPI is not set
# CONFIG_SENSORS_LIS3_I2C is not set

#
# Altera FPGA firmware download module
#
CONFIG_ALTERA_STAPL=y

#
# SCSI device support
#
CONFIG_SCSI_MOD=y
# CONFIG_RAID_ATTRS is not set
CONFIG_SCSI=y
CONFIG_SCSI_DMA=y
# CONFIG_SCSI_TGT is not set
CONFIG_SCSI_NETLINK=y
CONFIG_SCSI_PROC_FS=y

#
# SCSI support type (disk, tape, CD-ROM)
#
# CONFIG_BLK_DEV_SD is not set
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
CONFIG_BLK_DEV_SR=y
CONFIG_BLK_DEV_SR_VENDOR=y
CONFIG_CHR_DEV_SG=y
CONFIG_CHR_DEV_SCH=y
CONFIG_SCSI_MULTI_LUN=y
CONFIG_SCSI_CONSTANTS=y
CONFIG_SCSI_LOGGING=y
# CONFIG_SCSI_SCAN_ASYNC is not set

#
# SCSI Transports
#
# CONFIG_SCSI_SPI_ATTRS is not set
CONFIG_SCSI_FC_ATTRS=y
# CONFIG_SCSI_ISCSI_ATTRS is not set
CONFIG_SCSI_SAS_ATTRS=y
# CONFIG_SCSI_SAS_LIBSAS is not set
# CONFIG_SCSI_SRP_ATTRS is not set
# CONFIG_SCSI_LOWLEVEL is not set
CONFIG_SCSI_DH=y
# CONFIG_SCSI_DH_RDAC is not set
# CONFIG_SCSI_DH_HP_SW is not set
# CONFIG_SCSI_DH_EMC is not set
# CONFIG_SCSI_DH_ALUA is not set
CONFIG_SCSI_OSD_INITIATOR=y
# CONFIG_SCSI_OSD_ULD is not set
CONFIG_SCSI_OSD_DPRINT_SENSE=1
CONFIG_SCSI_OSD_DEBUG=y
CONFIG_HAVE_PATA_PLATFORM=y
CONFIG_ATA=y
# CONFIG_ATA_NONSTANDARD is not set
CONFIG_ATA_VERBOSE_ERROR=y
# CONFIG_SATA_PMP is not set

#
# Controllers with non-SFF native interface
#
CONFIG_SATA_AHCI_PLATFORM=y
CONFIG_ATA_SFF=y

#
# SFF controllers with custom DMA interface
#
# CONFIG_ATA_BMDMA is not set

#
# PIO-only SFF controllers
#
# CONFIG_PATA_PLATFORM is not set

#
# Generic fallback / legacy drivers
#
# CONFIG_MD is not set
CONFIG_TARGET_CORE=y
# CONFIG_TCM_IBLOCK is not set
CONFIG_TCM_FILEIO=y
# CONFIG_TCM_PSCSI is not set
# CONFIG_LOOPBACK_TARGET is not set
CONFIG_ISCSI_TARGET=y
# CONFIG_NETDEVICES is not set

#
# Input device support
#
CONFIG_INPUT=y
CONFIG_INPUT_FF_MEMLESS=y
CONFIG_INPUT_POLLDEV=y
# CONFIG_INPUT_SPARSEKMAP is not set
# CONFIG_INPUT_MATRIXKMAP is not set

#
# Userland interfaces
#
# CONFIG_INPUT_MOUSEDEV is not set
# CONFIG_INPUT_JOYDEV is not set
CONFIG_INPUT_EVDEV=y
# CONFIG_INPUT_EVBUG is not set
CONFIG_INPUT_APMPOWER=y

#
# Input Device Drivers
#
# CONFIG_INPUT_KEYBOARD is not set
# CONFIG_INPUT_MOUSE is not set
# CONFIG_INPUT_JOYSTICK is not set
CONFIG_INPUT_TABLET=y
CONFIG_TABLET_USB_ACECAD=y
CONFIG_TABLET_USB_AIPTEK=y
CONFIG_TABLET_USB_GTCO=y
# CONFIG_TABLET_USB_HANWANG is not set
CONFIG_TABLET_USB_KBTAB=y
# CONFIG_TABLET_USB_WACOM is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
# CONFIG_INPUT_MISC is not set

#
# Hardware I/O ports
#
CONFIG_SERIO=y
CONFIG_SERIO_AMBAKMI=y
CONFIG_SERIO_LIBPS2=y
# CONFIG_SERIO_RAW is not set
CONFIG_SERIO_ALTERA_PS2=y
CONFIG_SERIO_PS2MULT=y
CONFIG_SERIO_ARC_PS2=y
# CONFIG_SERIO_APBPS2 is not set
CONFIG_GAMEPORT=y
# CONFIG_GAMEPORT_NS558 is not set
# CONFIG_GAMEPORT_L4 is not set

#
# Character devices
#
# CONFIG_TTY is not set
# CONFIG_DEVKMEM is not set
CONFIG_SERIAL_OMAP=y
CONFIG_SERIAL_OMAP_CONSOLE=y
# CONFIG_IPMI_HANDLER is not set
CONFIG_HW_RANDOM=y
CONFIG_HW_RANDOM_TIMERIOMEM=y
CONFIG_HW_RANDOM_ATMEL=y
CONFIG_HW_RANDOM_OMAP=y
# CONFIG_HW_RANDOM_VIRTIO is not set
CONFIG_HW_RANDOM_EXYNOS=y
CONFIG_HW_RANDOM_TPM=y
# CONFIG_RAW_DRIVER is not set
CONFIG_TCG_TPM=y
CONFIG_TCG_TIS_I2C_INFINEON=y
CONFIG_TCG_ST33_I2C=y
CONFIG_I2C=y
CONFIG_I2C_BOARDINFO=y
# CONFIG_I2C_COMPAT is not set
# CONFIG_I2C_CHARDEV is not set
# CONFIG_I2C_MUX is not set
# CONFIG_I2C_HELPER_AUTO is not set
# CONFIG_I2C_SMBUS is not set

#
# I2C Algorithms
#
CONFIG_I2C_ALGOBIT=y
CONFIG_I2C_ALGOPCF=y
CONFIG_I2C_ALGOPCA=y

#
# I2C Hardware Bus support
#

#
# I2C system bus drivers (mostly embedded / system-on-chip)
#
CONFIG_I2C_CBUS_GPIO=y
CONFIG_I2C_DESIGNWARE_CORE=y
CONFIG_I2C_DESIGNWARE_PLATFORM=y
CONFIG_I2C_GPIO=y
# CONFIG_I2C_MV64XXX is not set
CONFIG_I2C_NOMADIK=y
# CONFIG_I2C_OCORES is not set
CONFIG_I2C_OMAP=y
# CONFIG_I2C_PCA_PLATFORM is not set
# CONFIG_I2C_PXA_PCI is not set
# CONFIG_I2C_SIMTEC is not set
CONFIG_I2C_SIRF=y
# CONFIG_I2C_VERSATILE is not set
# CONFIG_I2C_XILINX is not set

#
# External I2C/SMBus adapter drivers
#
# CONFIG_I2C_DIOLAN_U2C is not set
# CONFIG_I2C_PARPORT_LIGHT is not set
CONFIG_I2C_TINY_USB=y
# CONFIG_I2C_VIPERBOARD is not set

#
# Other I2C/SMBus bus drivers
#
CONFIG_I2C_DEBUG_CORE=y
CONFIG_I2C_DEBUG_ALGO=y
CONFIG_I2C_DEBUG_BUS=y
CONFIG_SPI=y
CONFIG_SPI_DEBUG=y
CONFIG_SPI_MASTER=y

#
# SPI Master Controller Drivers
#
CONFIG_SPI_ALTERA=y
CONFIG_SPI_BITBANG=y
CONFIG_SPI_GPIO=y
CONFIG_SPI_FSL_LIB=y
CONFIG_SPI_FSL_SPI=y
# CONFIG_SPI_OC_TINY is not set
CONFIG_SPI_OMAP24XX=y
CONFIG_SPI_ORION=y
# CONFIG_SPI_PL022 is not set
# CONFIG_SPI_PXA2XX_PCI is not set
CONFIG_SPI_SC18IS602=y
CONFIG_SPI_SIRF=y
CONFIG_SPI_XCOMM=y
# CONFIG_SPI_XILINX is not set
CONFIG_SPI_DESIGNWARE=y
# CONFIG_SPI_DW_MMIO is not set

#
# SPI Protocol Masters
#
CONFIG_SPI_SPIDEV=y
CONFIG_SPI_TLE62X0=y

#
# Qualcomm MSM SSBI bus support
#
CONFIG_SSBI=y
CONFIG_HSI=y
CONFIG_HSI_BOARDINFO=y

#
# HSI clients
#
CONFIG_HSI_CHAR=y

#
# PPS support
#
CONFIG_PPS=y
# CONFIG_PPS_DEBUG is not set
# CONFIG_NTP_PPS is not set

#
# PPS clients support
#
CONFIG_PPS_CLIENT_KTIMER=y
CONFIG_PPS_CLIENT_GPIO=y

#
# PPS generators support
#

#
# PTP clock support
#
CONFIG_PTP_1588_CLOCK=y

#
# Enable PHYLIB and NETWORK_PHY_TIMESTAMPING to see the additional clocks.
#
CONFIG_PTP_1588_CLOCK_PCH=y
CONFIG_PINCTRL=y

#
# Pin controllers
#
CONFIG_PINMUX=y
CONFIG_PINCONF=y
CONFIG_GENERIC_PINCONF=y
# CONFIG_DEBUG_PINCTRL is not set
CONFIG_PINCTRL_ABX500=y
CONFIG_PINCTRL_AB8500=y
CONFIG_PINCTRL_AB8540=y
CONFIG_PINCTRL_AB9540=y
CONFIG_PINCTRL_AB8505=y
CONFIG_PINCTRL_NOMADIK=y
CONFIG_PINCTRL_DB8500=y
CONFIG_PINCTRL_DB8540=y
CONFIG_PINCTRL_SINGLE=y
CONFIG_PINCTRL_SIRF=y
CONFIG_PINCTRL_SUNXI=y
CONFIG_PINCTRL_SAMSUNG=y
CONFIG_PINCTRL_EXYNOS=y
CONFIG_PINCTRL_EXYNOS5440=y
CONFIG_PINCTRL_MVEBU=y
CONFIG_PINCTRL_ARMADA_370=y
CONFIG_ARCH_HAVE_CUSTOM_GPIO_H=y
CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y
CONFIG_ARCH_REQUIRE_GPIOLIB=y
CONFIG_GPIO_DEVRES=y
CONFIG_GPIOLIB=y
CONFIG_OF_GPIO=y
# CONFIG_DEBUG_GPIO is not set
CONFIG_GPIO_SYSFS=y
CONFIG_GPIO_GENERIC=y
CONFIG_GPIO_MAX730X=y

#
# Memory mapped GPIO drivers:
#
CONFIG_GPIO_GENERIC_PLATFORM=y
# CONFIG_GPIO_EM is not set
CONFIG_GPIO_MVEBU=y
CONFIG_GPIO_PL061=y
CONFIG_GPIO_RCAR=y
CONFIG_GPIO_TS5500=y

#
# I2C GPIO expanders:
#
CONFIG_GPIO_ARIZONA=y
# CONFIG_GPIO_MAX7300 is not set
# CONFIG_GPIO_MAX732X is not set
CONFIG_GPIO_PCF857X=y
# CONFIG_GPIO_RC5T583 is not set
CONFIG_GPIO_SX150X=y
# CONFIG_GPIO_TC3589X is not set
CONFIG_GPIO_TWL4030=y
CONFIG_GPIO_TWL6040=y
# CONFIG_GPIO_WM831X is not set
CONFIG_GPIO_WM8994=y
CONFIG_GPIO_ADP5520=y
# CONFIG_GPIO_ADP5588 is not set
# CONFIG_GPIO_ADNP is not set

#
# PCI GPIO expanders:
#

#
# SPI GPIO expanders:
#
CONFIG_GPIO_MAX7301=y
CONFIG_GPIO_MCP23S08=y
CONFIG_GPIO_MC33880=y
CONFIG_GPIO_74X164=y

#
# AC97 GPIO expanders:
#

#
# MODULbus GPIO expanders:
#
# CONFIG_GPIO_PALMAS is not set
# CONFIG_GPIO_TPS6586X is not set
# CONFIG_GPIO_TPS65910 is not set

#
# USB GPIO expanders:
#
# CONFIG_GPIO_VIPERBOARD is not set
CONFIG_W1=y
CONFIG_W1_CON=y

#
# 1-wire Bus Masters
#
# CONFIG_W1_MASTER_DS2490 is not set
CONFIG_W1_MASTER_DS2482=y
# CONFIG_W1_MASTER_DS1WM is not set
# CONFIG_W1_MASTER_GPIO is not set
CONFIG_HDQ_MASTER_OMAP=y

#
# 1-wire Slaves
#
# CONFIG_W1_SLAVE_THERM is not set
# CONFIG_W1_SLAVE_SMEM is not set
# CONFIG_W1_SLAVE_DS2408 is not set
CONFIG_W1_SLAVE_DS2413=y
# CONFIG_W1_SLAVE_DS2423 is not set
# CONFIG_W1_SLAVE_DS2431 is not set
CONFIG_W1_SLAVE_DS2433=y
CONFIG_W1_SLAVE_DS2433_CRC=y
CONFIG_W1_SLAVE_DS2760=y
CONFIG_W1_SLAVE_DS2780=y
CONFIG_W1_SLAVE_DS2781=y
CONFIG_W1_SLAVE_DS28E04=y
# CONFIG_W1_SLAVE_BQ27000 is not set
CONFIG_POWER_SUPPLY=y
# CONFIG_POWER_SUPPLY_DEBUG is not set
CONFIG_PDA_POWER=y
CONFIG_APM_POWER=y
CONFIG_MAX8925_POWER=y
CONFIG_WM831X_BACKUP=y
# CONFIG_WM831X_POWER is not set
# CONFIG_TEST_POWER is not set
CONFIG_BATTERY_DS2760=y
# CONFIG_BATTERY_DS2780 is not set
CONFIG_BATTERY_DS2781=y
# CONFIG_BATTERY_DS2782 is not set
# CONFIG_BATTERY_SBS is not set
# CONFIG_BATTERY_BQ27x00 is not set
# CONFIG_BATTERY_MAX17040 is not set
# CONFIG_BATTERY_MAX17042 is not set
# CONFIG_CHARGER_PCF50633 is not set
# CONFIG_BATTERY_RX51 is not set
CONFIG_CHARGER_MAX8903=y
CONFIG_CHARGER_TWL4030=y
CONFIG_CHARGER_LP8727=y
# CONFIG_CHARGER_GPIO is not set
CONFIG_CHARGER_BQ2415X=y
# CONFIG_CHARGER_SMB347 is not set
# CONFIG_BATTERY_GOLDFISH is not set
CONFIG_POWER_RESET=y
# CONFIG_POWER_RESET_GPIO is not set
# CONFIG_POWER_RESET_QNAP is not set
# CONFIG_POWER_RESET_RESTART is not set
CONFIG_POWER_RESET_VEXPRESS=y
CONFIG_POWER_AVS=y
# CONFIG_HWMON is not set
# CONFIG_THERMAL is not set
CONFIG_WATCHDOG=y
CONFIG_WATCHDOG_CORE=y
# CONFIG_WATCHDOG_NOWAYOUT is not set

#
# Watchdog Device Drivers
#
CONFIG_SOFT_WATCHDOG=y
CONFIG_WM831X_WATCHDOG=y
# CONFIG_ARM_SP805_WATCHDOG is not set
# CONFIG_DW_WATCHDOG is not set
CONFIG_OMAP_WATCHDOG=y
# CONFIG_TWL4030_WATCHDOG is not set
# CONFIG_MAX63XX_WATCHDOG is not set
# CONFIG_UX500_WATCHDOG is not set

#
# USB-based Watchdog Cards
#
# CONFIG_USBPCWATCHDOG is not set
CONFIG_SSB_POSSIBLE=y

#
# Sonics Silicon Backplane
#
# CONFIG_SSB is not set
CONFIG_BCMA_POSSIBLE=y

#
# Broadcom specific AMBA
#
CONFIG_BCMA=y
CONFIG_BCMA_DRIVER_GMAC_CMN=y
# CONFIG_BCMA_DRIVER_GPIO is not set
# CONFIG_BCMA_DEBUG is not set

#
# Multifunction device drivers
#
CONFIG_MFD_CORE=y
CONFIG_MFD_AS3711=y
CONFIG_PMIC_ADP5520=y
# CONFIG_MFD_AAT2870_CORE is not set
# CONFIG_MFD_CROS_EC is not set
# CONFIG_MFD_ASIC3 is not set
# CONFIG_PMIC_DA903X is not set
# CONFIG_MFD_DA9052_SPI is not set
# CONFIG_MFD_DA9052_I2C is not set
# CONFIG_MFD_DA9055 is not set
CONFIG_MFD_MC13783=y
CONFIG_MFD_MC13XXX=y
CONFIG_MFD_MC13XXX_SPI=y
CONFIG_MFD_MC13XXX_I2C=y
# CONFIG_HTC_EGPIO is not set
CONFIG_HTC_PASIC3=y
CONFIG_HTC_I2CPLD=y
CONFIG_MFD_88PM800=y
# CONFIG_MFD_88PM805 is not set
# CONFIG_MFD_88PM860X is not set
CONFIG_MFD_MAX77686=y
# CONFIG_MFD_MAX77693 is not set
# CONFIG_MFD_MAX8907 is not set
CONFIG_MFD_MAX8925=y
# CONFIG_MFD_MAX8997 is not set
# CONFIG_MFD_MAX8998 is not set
CONFIG_EZX_PCAP=y
CONFIG_MFD_VIPERBOARD=y
# CONFIG_MFD_RETU is not set
CONFIG_MFD_PCF50633=y
# CONFIG_PCF50633_ADC is not set
# CONFIG_PCF50633_GPIO is not set
CONFIG_MFD_RC5T583=y
# CONFIG_MFD_SEC_CORE is not set
CONFIG_MFD_SM501=y
CONFIG_MFD_SM501_GPIO=y
# CONFIG_MFD_SMSC is not set
# CONFIG_ABX500_CORE is not set
CONFIG_MFD_DB8500_PRCMU=y
# CONFIG_MFD_STMPE is not set
CONFIG_MFD_SYSCON=y
# CONFIG_MFD_TI_AM335X_TSCADC is not set
# CONFIG_MFD_LP8788 is not set
CONFIG_MFD_PALMAS=y
# CONFIG_TPS6105X is not set
# CONFIG_TPS65010 is not set
CONFIG_TPS6507X=y
# CONFIG_MFD_TPS65090 is not set
# CONFIG_MFD_TPS65217 is not set
CONFIG_MFD_TPS6586X=y
CONFIG_MFD_TPS65910=y
# CONFIG_MFD_TPS65912 is not set
# CONFIG_MFD_TPS65912_I2C is not set
# CONFIG_MFD_TPS65912_SPI is not set
CONFIG_MFD_TPS80031=y
CONFIG_TWL4030_CORE=y
CONFIG_TWL4030_MADC=y
CONFIG_TWL4030_POWER=y
CONFIG_MFD_TWL4030_AUDIO=y
CONFIG_TWL6040_CORE=y
CONFIG_MENELAUS=y
# CONFIG_MFD_WL1273_CORE is not set
# CONFIG_MFD_SI476X_CORE is not set
# CONFIG_MFD_LM3533 is not set
CONFIG_MFD_TC3589X=y
# CONFIG_MFD_TMIO is not set
# CONFIG_MFD_T7L66XB is not set
# CONFIG_MFD_TC6387XB is not set
# CONFIG_MFD_TC6393XB is not set
CONFIG_MFD_ARIZONA=y
CONFIG_MFD_ARIZONA_I2C=y
CONFIG_MFD_ARIZONA_SPI=y
# CONFIG_MFD_WM5102 is not set
# CONFIG_MFD_WM5110 is not set
# CONFIG_MFD_WM8400 is not set
CONFIG_MFD_WM831X=y
CONFIG_MFD_WM831X_I2C=y
CONFIG_MFD_WM831X_SPI=y
# CONFIG_MFD_WM8350_I2C is not set
CONFIG_MFD_WM8994=y
CONFIG_VEXPRESS_CONFIG=y
CONFIG_REGULATOR=y
# CONFIG_REGULATOR_DEBUG is not set
# CONFIG_REGULATOR_DUMMY is not set
CONFIG_REGULATOR_FIXED_VOLTAGE=y
# CONFIG_REGULATOR_VIRTUAL_CONSUMER is not set
# CONFIG_REGULATOR_USERSPACE_CONSUMER is not set
# CONFIG_REGULATOR_GPIO is not set
# CONFIG_REGULATOR_AD5398 is not set
CONFIG_REGULATOR_FAN53555=y
# CONFIG_REGULATOR_ANATOP is not set
CONFIG_REGULATOR_MC13XXX_CORE=y
# CONFIG_REGULATOR_MC13783 is not set
CONFIG_REGULATOR_MC13892=y
CONFIG_REGULATOR_ISL6271A=y
CONFIG_REGULATOR_MAX1586=y
CONFIG_REGULATOR_MAX8649=y
# CONFIG_REGULATOR_MAX8660 is not set
# CONFIG_REGULATOR_MAX8925 is not set
# CONFIG_REGULATOR_MAX8952 is not set
CONFIG_REGULATOR_MAX8973=y
CONFIG_REGULATOR_MAX77686=y
# CONFIG_REGULATOR_PCAP is not set
# CONFIG_REGULATOR_LP3971 is not set
# CONFIG_REGULATOR_LP3972 is not set
CONFIG_REGULATOR_LP872X=y
# CONFIG_REGULATOR_LP8755 is not set
# CONFIG_REGULATOR_PCF50633 is not set
# CONFIG_REGULATOR_RC5T583 is not set
CONFIG_REGULATOR_DBX500_PRCMU=y
CONFIG_REGULATOR_DB8500_PRCMU=y
# CONFIG_REGULATOR_PALMAS is not set
# CONFIG_REGULATOR_TPS51632 is not set
CONFIG_REGULATOR_TPS62360=y
CONFIG_REGULATOR_TPS65023=y
# CONFIG_REGULATOR_TPS6507X is not set
# CONFIG_REGULATOR_TPS6524X is not set
CONFIG_REGULATOR_TPS6586X=y
CONFIG_REGULATOR_TPS65910=y
# CONFIG_REGULATOR_TPS80031 is not set
# CONFIG_REGULATOR_TWL4030 is not set
# CONFIG_REGULATOR_VEXPRESS is not set
CONFIG_REGULATOR_WM831X=y
# CONFIG_REGULATOR_WM8994 is not set
CONFIG_REGULATOR_AS3711=y
CONFIG_MEDIA_SUPPORT=y

#
# Multimedia core support
#
# CONFIG_MEDIA_CAMERA_SUPPORT is not set
CONFIG_MEDIA_ANALOG_TV_SUPPORT=y
# CONFIG_MEDIA_DIGITAL_TV_SUPPORT is not set
# CONFIG_MEDIA_RADIO_SUPPORT is not set
CONFIG_MEDIA_RC_SUPPORT=y
CONFIG_VIDEO_DEV=y
CONFIG_VIDEO_V4L2=y
CONFIG_VIDEO_ADV_DEBUG=y
# CONFIG_VIDEO_FIXED_MINOR_RANGES is not set
CONFIG_VIDEO_V4L2_INT_DEVICE=y
# CONFIG_TTPCI_EEPROM is not set

#
# Media drivers
#
CONFIG_RC_CORE=y
# CONFIG_RC_MAP is not set
CONFIG_RC_DECODERS=y
# CONFIG_LIRC is not set
CONFIG_IR_NEC_DECODER=y
# CONFIG_IR_RC5_DECODER is not set
# CONFIG_IR_RC6_DECODER is not set
# CONFIG_IR_JVC_DECODER is not set
# CONFIG_IR_SONY_DECODER is not set
CONFIG_IR_RC5_SZ_DECODER=y
# CONFIG_IR_SANYO_DECODER is not set
# CONFIG_IR_MCE_KBD_DECODER is not set
# CONFIG_RC_DEVICES is not set
# CONFIG_MEDIA_USB_SUPPORT is not set

#
# Supported MMC/SDIO adapters
#
CONFIG_CYPRESS_FIRMWARE=y

#
# Media ancillary drivers (tuners, sensors, i2c, frontends)
#
# CONFIG_MEDIA_SUBDRV_AUTOSELECT is not set
CONFIG_VIDEO_IR_I2C=y

#
# Encoders, decoders, sensors and other helper chips
#

#
# Audio decoders, processors and mixers
#
# CONFIG_VIDEO_TVAUDIO is not set
# CONFIG_VIDEO_TDA7432 is not set
# CONFIG_VIDEO_TDA9840 is not set
CONFIG_VIDEO_TEA6415C=y
# CONFIG_VIDEO_TEA6420 is not set
# CONFIG_VIDEO_MSP3400 is not set
# CONFIG_VIDEO_CS5345 is not set
CONFIG_VIDEO_CS53L32A=y
CONFIG_VIDEO_TLV320AIC23B=y
CONFIG_VIDEO_UDA1342=y
# CONFIG_VIDEO_WM8775 is not set
# CONFIG_VIDEO_WM8739 is not set
CONFIG_VIDEO_VP27SMPX=y
# CONFIG_VIDEO_SONY_BTF_MPX is not set

#
# RDS decoders
#
# CONFIG_VIDEO_SAA6588 is not set

#
# Video decoders
#
CONFIG_VIDEO_ADV7180=y
# CONFIG_VIDEO_ADV7183 is not set
# CONFIG_VIDEO_BT819 is not set
# CONFIG_VIDEO_BT856 is not set
# CONFIG_VIDEO_BT866 is not set
CONFIG_VIDEO_KS0127=y
CONFIG_VIDEO_SAA7110=y
# CONFIG_VIDEO_SAA711X is not set
# CONFIG_VIDEO_SAA7191 is not set
CONFIG_VIDEO_TVP514X=y
CONFIG_VIDEO_TVP5150=y
# CONFIG_VIDEO_TVP7002 is not set
CONFIG_VIDEO_TW2804=y
CONFIG_VIDEO_TW9903=y
CONFIG_VIDEO_TW9906=y
# CONFIG_VIDEO_VPX3220 is not set

#
# Video and audio decoders
#
CONFIG_VIDEO_SAA717X=y
# CONFIG_VIDEO_CX25840 is not set

#
# Video encoders
#
CONFIG_VIDEO_SAA7127=y
# CONFIG_VIDEO_SAA7185 is not set
# CONFIG_VIDEO_ADV7170 is not set
# CONFIG_VIDEO_ADV7175 is not set
# CONFIG_VIDEO_ADV7343 is not set
# CONFIG_VIDEO_ADV7393 is not set
CONFIG_VIDEO_AK881X=y

#
# Camera sensor devices
#

#
# Flash devices
#

#
# Video improvement chips
#
# CONFIG_VIDEO_UPD64031A is not set
# CONFIG_VIDEO_UPD64083 is not set

#
# Miscelaneous helper chips
#
# CONFIG_VIDEO_THS7303 is not set
CONFIG_VIDEO_M52790=y

#
# Sensors used on soc_camera driver
#
CONFIG_MEDIA_TUNER=y

#
# Customize TV tuners
#
# CONFIG_MEDIA_TUNER_SIMPLE is not set
# CONFIG_MEDIA_TUNER_TDA8290 is not set
CONFIG_MEDIA_TUNER_TDA827X=y
CONFIG_MEDIA_TUNER_TDA18271=y
CONFIG_MEDIA_TUNER_TDA9887=y
# CONFIG_MEDIA_TUNER_TEA5761 is not set
CONFIG_MEDIA_TUNER_TEA5767=y
# CONFIG_MEDIA_TUNER_MT20XX is not set
CONFIG_MEDIA_TUNER_MT2060=y
CONFIG_MEDIA_TUNER_MT2063=y
CONFIG_MEDIA_TUNER_MT2266=y
# CONFIG_MEDIA_TUNER_MT2131 is not set
CONFIG_MEDIA_TUNER_QT1010=y
CONFIG_MEDIA_TUNER_XC2028=y
CONFIG_MEDIA_TUNER_XC5000=y
CONFIG_MEDIA_TUNER_XC4000=y
CONFIG_MEDIA_TUNER_MXL5005S=y
CONFIG_MEDIA_TUNER_MXL5007T=y
CONFIG_MEDIA_TUNER_MC44S803=y
# CONFIG_MEDIA_TUNER_MAX2165 is not set
# CONFIG_MEDIA_TUNER_TDA18218 is not set
CONFIG_MEDIA_TUNER_FC0011=y
CONFIG_MEDIA_TUNER_FC0012=y
# CONFIG_MEDIA_TUNER_FC0013 is not set
# CONFIG_MEDIA_TUNER_TDA18212 is not set
# CONFIG_MEDIA_TUNER_E4000 is not set
# CONFIG_MEDIA_TUNER_FC2580 is not set
# CONFIG_MEDIA_TUNER_TUA9001 is not set
# CONFIG_MEDIA_TUNER_IT913X is not set
CONFIG_MEDIA_TUNER_R820T=y

#
# Customise DVB Frontends
#
# CONFIG_DVB_AU8522_V4L is not set
# CONFIG_DVB_TUNER_DIB0070 is not set
# CONFIG_DVB_TUNER_DIB0090 is not set

#
# Tools to develop new frontends
#
# CONFIG_DVB_DUMMY_FE is not set

#
# Graphics support
#
# CONFIG_DRM is not set
# CONFIG_VGASTATE is not set
CONFIG_VIDEO_OUTPUT_CONTROL=y
# CONFIG_FB is not set
CONFIG_OMAP2_DSS=y
# CONFIG_OMAP2_DSS_DEBUG is not set
# CONFIG_OMAP2_DSS_DEBUGFS is not set
CONFIG_OMAP2_DSS_DPI=y
CONFIG_OMAP2_DSS_RFBI=y
# CONFIG_OMAP2_DSS_VENC is not set
# CONFIG_OMAP4_DSS_HDMI is not set
CONFIG_OMAP2_DSS_SDI=y
# CONFIG_OMAP2_DSS_DSI is not set
CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK=0
# CONFIG_OMAP2_DSS_SLEEP_AFTER_VENC_RESET is not set

#
# OMAP2/3 Display Device Drivers
#
# CONFIG_PANEL_GENERIC_DPI is not set
CONFIG_PANEL_TFP410=y
CONFIG_PANEL_LGPHILIPS_LB035Q02=y
CONFIG_PANEL_SHARP_LS037V7DW01=y
CONFIG_PANEL_NEC_NL8048HL11_01B=y
CONFIG_PANEL_PICODLP=y
CONFIG_PANEL_TPO_TD043MTEA1=y
# CONFIG_PANEL_ACX565AKM is not set
CONFIG_PANEL_N8X0=y
# CONFIG_EXYNOS_VIDEO is not set
CONFIG_BACKLIGHT_LCD_SUPPORT=y
# CONFIG_LCD_CLASS_DEVICE is not set
CONFIG_BACKLIGHT_CLASS_DEVICE=y
CONFIG_BACKLIGHT_GENERIC=y
# CONFIG_BACKLIGHT_PWM is not set
# CONFIG_BACKLIGHT_MAX8925 is not set
CONFIG_BACKLIGHT_WM831X=y
CONFIG_BACKLIGHT_ADP5520=y
CONFIG_BACKLIGHT_ADP8860=y
CONFIG_BACKLIGHT_ADP8870=y
# CONFIG_BACKLIGHT_PCF50633 is not set
CONFIG_BACKLIGHT_LM3630=y
# CONFIG_BACKLIGHT_LM3639 is not set
# CONFIG_BACKLIGHT_LP855X is not set
# CONFIG_BACKLIGHT_PANDORA is not set
CONFIG_BACKLIGHT_AS3711=y
# CONFIG_SOUND is not set

#
# HID support
#
CONFIG_HID=y
# CONFIG_HID_BATTERY_STRENGTH is not set
CONFIG_HIDRAW=y
CONFIG_UHID=y
CONFIG_HID_GENERIC=y

#
# Special HID drivers
#
# CONFIG_HID_A4TECH is not set
# CONFIG_HID_ACRUX is not set
# CONFIG_HID_APPLE is not set
# CONFIG_HID_AUREAL is not set
CONFIG_HID_BELKIN=y
CONFIG_HID_CHERRY=y
# CONFIG_HID_CHICONY is not set
# CONFIG_HID_CYPRESS is not set
CONFIG_HID_DRAGONRISE=y
CONFIG_DRAGONRISE_FF=y
CONFIG_HID_EMS_FF=y
CONFIG_HID_ELECOM=y
CONFIG_HID_EZKEY=y
# CONFIG_HID_HOLTEK is not set
# CONFIG_HID_KEYTOUCH is not set
# CONFIG_HID_KYE is not set
# CONFIG_HID_UCLOGIC is not set
# CONFIG_HID_WALTOP is not set
# CONFIG_HID_GYRATION is not set
# CONFIG_HID_ICADE is not set
CONFIG_HID_TWINHAN=y
# CONFIG_HID_KENSINGTON is not set
CONFIG_HID_LCPOWER=y
CONFIG_HID_LENOVO_TPKBD=y
# CONFIG_HID_LOGITECH is not set
CONFIG_HID_MAGICMOUSE=y
# CONFIG_HID_MICROSOFT is not set
CONFIG_HID_MONTEREY=y
# CONFIG_HID_MULTITOUCH is not set
# CONFIG_HID_NTRIG is not set
# CONFIG_HID_ORTEK is not set
CONFIG_HID_PANTHERLORD=y
# CONFIG_PANTHERLORD_FF is not set
CONFIG_HID_PETALYNX=y
# CONFIG_HID_PICOLCD is not set
CONFIG_HID_PRIMAX=y
# CONFIG_HID_PS3REMOTE is not set
CONFIG_HID_ROCCAT=y
# CONFIG_HID_SAITEK is not set
CONFIG_HID_SAMSUNG=y
CONFIG_HID_SONY=y
# CONFIG_HID_SPEEDLINK is not set
CONFIG_HID_STEELSERIES=y
# CONFIG_HID_SUNPLUS is not set
# CONFIG_HID_GREENASIA is not set
# CONFIG_HID_SMARTJOYPLUS is not set
CONFIG_HID_TIVO=y
CONFIG_HID_TOPSEED=y
CONFIG_HID_THINGM=y
# CONFIG_HID_THRUSTMASTER is not set
# CONFIG_HID_WACOM is not set
CONFIG_HID_WIIMOTE=y
# CONFIG_HID_WIIMOTE_EXT is not set
CONFIG_HID_ZEROPLUS=y
CONFIG_ZEROPLUS_FF=y
# CONFIG_HID_ZYDACRON is not set
CONFIG_HID_SENSOR_HUB=y

#
# USB HID support
#
CONFIG_USB_HID=y
# CONFIG_HID_PID is not set
CONFIG_USB_HIDDEV=y

#
# I2C HID support
#
CONFIG_I2C_HID=y
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB_ARCH_HAS_EHCI=y
# CONFIG_USB_ARCH_HAS_XHCI is not set
CONFIG_USB_SUPPORT=y
CONFIG_USB_COMMON=y
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB=y
CONFIG_USB_DEBUG=y
# CONFIG_USB_ANNOUNCE_NEW_DEVICES is not set

#
# Miscellaneous USB options
#
# CONFIG_USB_DEFAULT_PERSIST is not set
# CONFIG_USB_DYNAMIC_MINORS is not set
CONFIG_USB_OTG_WHITELIST=y
# CONFIG_USB_OTG_BLACKLIST_HUB is not set
CONFIG_USB_MON=y
CONFIG_USB_WUSB_CBAF=y
# CONFIG_USB_WUSB_CBAF_DEBUG is not set

#
# USB Host Controller Drivers
#
CONFIG_USB_C67X00_HCD=y
# CONFIG_USB_EHCI_HCD is not set
# CONFIG_USB_OXU210HP_HCD is not set
# CONFIG_USB_ISP116X_HCD is not set
CONFIG_USB_ISP1760_HCD=y
CONFIG_USB_ISP1362_HCD=y
CONFIG_USB_OHCI_HCD=y
# CONFIG_USB_OHCI_HCD_OMAP3 is not set
CONFIG_USB_OHCI_HCD_PLATFORM=y
# CONFIG_USB_OHCI_BIG_ENDIAN_DESC is not set
# CONFIG_USB_OHCI_BIG_ENDIAN_MMIO is not set
CONFIG_USB_OHCI_LITTLE_ENDIAN=y
# CONFIG_USB_U132_HCD is not set
# CONFIG_USB_SL811_HCD is not set
CONFIG_USB_R8A66597_HCD=y
CONFIG_USB_RENESAS_USBHS_HCD=y
CONFIG_USB_HCD_BCMA=y
# CONFIG_USB_MUSB_HDRC is not set
CONFIG_USB_RENESAS_USBHS=y

#
# USB Device Class drivers
#
# CONFIG_USB_PRINTER is not set
CONFIG_USB_WDM=y
CONFIG_USB_TMC=y

#
# NOTE: USB_STORAGE depends on SCSI but BLK_DEV_SD may
#

#
# also be needed; see USB_STORAGE Help for more info
#
CONFIG_USB_STORAGE=y
# CONFIG_USB_STORAGE_DEBUG is not set
# CONFIG_USB_STORAGE_REALTEK is not set
CONFIG_USB_STORAGE_DATAFAB=y
CONFIG_USB_STORAGE_FREECOM=y
# CONFIG_USB_STORAGE_ISD200 is not set
CONFIG_USB_STORAGE_USBAT=y
CONFIG_USB_STORAGE_SDDR09=y
CONFIG_USB_STORAGE_SDDR55=y
# CONFIG_USB_STORAGE_JUMPSHOT is not set
# CONFIG_USB_STORAGE_ALAUDA is not set
# CONFIG_USB_STORAGE_ONETOUCH is not set
# CONFIG_USB_STORAGE_KARMA is not set
# CONFIG_USB_STORAGE_CYPRESS_ATACB is not set
CONFIG_USB_STORAGE_ENE_UB6250=y

#
# USB Imaging devices
#
# CONFIG_USB_MDC800 is not set
# CONFIG_USB_MICROTEK is not set
# CONFIG_USB_DWC3 is not set
CONFIG_USB_CHIPIDEA=y
CONFIG_USB_CHIPIDEA_UDC=y
# CONFIG_USB_CHIPIDEA_DEBUG is not set

#
# USB port drivers
#

#
# USB Miscellaneous drivers
#
# CONFIG_USB_EMI62 is not set
CONFIG_USB_EMI26=y
CONFIG_USB_ADUTUX=y
# CONFIG_USB_SEVSEG is not set
CONFIG_USB_RIO500=y
# CONFIG_USB_LEGOTOWER is not set
# CONFIG_USB_LCD is not set
# CONFIG_USB_LED is not set
CONFIG_USB_CYPRESS_CY7C63=y
# CONFIG_USB_CYTHERM is not set
# CONFIG_USB_IDMOUSE is not set
CONFIG_USB_FTDI_ELAN=y
CONFIG_USB_APPLEDISPLAY=y
CONFIG_USB_LD=y
# CONFIG_USB_TRANCEVIBRATOR is not set
CONFIG_USB_IOWARRIOR=y
CONFIG_USB_TEST=y
CONFIG_USB_ISIGHTFW=y
# CONFIG_USB_YUREX is not set
CONFIG_USB_EZUSB_FX2=y
# CONFIG_USB_HSIC_USB3503 is not set
# CONFIG_USB_PHY is not set
CONFIG_USB_GADGET=y
CONFIG_USB_GADGET_DEBUG=y
# CONFIG_USB_GADGET_DEBUG_FILES is not set
# CONFIG_USB_GADGET_DEBUG_FS is not set
CONFIG_USB_GADGET_VBUS_DRAW=2
CONFIG_USB_GADGET_STORAGE_NUM_BUFFERS=2

#
# USB Peripheral Controller
#
CONFIG_USB_FUSB300=y
# CONFIG_USB_R8A66597 is not set
# CONFIG_USB_RENESAS_USBHS_UDC is not set
CONFIG_USB_PXA27X=y
# CONFIG_USB_MV_UDC is not set
CONFIG_USB_MV_U3D=y
CONFIG_USB_M66592=y
# CONFIG_USB_NET2272 is not set
CONFIG_USB_DUMMY_HCD=y
CONFIG_USB_LIBCOMPOSITE=y
# CONFIG_USB_ZERO is not set
CONFIG_USB_ETH=y
# CONFIG_USB_ETH_RNDIS is not set
CONFIG_USB_ETH_EEM=y
# CONFIG_USB_G_NCM is not set
# CONFIG_USB_GADGETFS is not set
# CONFIG_USB_FUNCTIONFS is not set
# CONFIG_USB_MASS_STORAGE is not set
# CONFIG_USB_GADGET_TARGET is not set
# CONFIG_USB_G_PRINTER is not set
# CONFIG_USB_G_HID is not set
# CONFIG_USB_G_WEBCAM is not set
# CONFIG_MMC is not set
CONFIG_MEMSTICK=y
# CONFIG_MEMSTICK_DEBUG is not set

#
# MemoryStick drivers
#
CONFIG_MEMSTICK_UNSAFE_RESUME=y
# CONFIG_MSPRO_BLOCK is not set

#
# MemoryStick Host Controller Drivers
#
CONFIG_NEW_LEDS=y
CONFIG_LEDS_CLASS=y

#
# LED drivers
#
# CONFIG_LEDS_LM3530 is not set
# CONFIG_LEDS_LM3642 is not set
# CONFIG_LEDS_PCA9532 is not set
CONFIG_LEDS_GPIO=y
CONFIG_LEDS_LP3944=y
CONFIG_LEDS_LP55XX_COMMON=y
CONFIG_LEDS_LP5521=y
# CONFIG_LEDS_LP5523 is not set
CONFIG_LEDS_LP5562=y
CONFIG_LEDS_PCA955X=y
CONFIG_LEDS_PCA9633=y
CONFIG_LEDS_WM831X_STATUS=y
# CONFIG_LEDS_DAC124S085 is not set
# CONFIG_LEDS_PWM is not set
# CONFIG_LEDS_REGULATOR is not set
CONFIG_LEDS_BD2802=y
CONFIG_LEDS_LT3593=y
CONFIG_LEDS_ADP5520=y
CONFIG_LEDS_MC13783=y
# CONFIG_LEDS_RENESAS_TPU is not set
CONFIG_LEDS_TCA6507=y
# CONFIG_LEDS_LM355x is not set
# CONFIG_LEDS_OT200 is not set
# CONFIG_LEDS_BLINKM is not set

#
# LED Triggers
#
CONFIG_LEDS_TRIGGERS=y
# CONFIG_LEDS_TRIGGER_TIMER is not set
CONFIG_LEDS_TRIGGER_ONESHOT=y
CONFIG_LEDS_TRIGGER_HEARTBEAT=y
CONFIG_LEDS_TRIGGER_BACKLIGHT=y
CONFIG_LEDS_TRIGGER_CPU=y
# CONFIG_LEDS_TRIGGER_GPIO is not set
# CONFIG_LEDS_TRIGGER_DEFAULT_ON is not set

#
# iptables trigger is under Netfilter config (LED target)
#
CONFIG_LEDS_TRIGGER_TRANSIENT=y
CONFIG_LEDS_TRIGGER_CAMERA=y
# CONFIG_ACCESSIBILITY is not set
# CONFIG_EDAC is not set
CONFIG_RTC_LIB=y
# CONFIG_RTC_CLASS is not set
# CONFIG_DMADEVICES is not set
CONFIG_AUXDISPLAY=y
CONFIG_UIO=y
CONFIG_UIO_PDRV=y
CONFIG_UIO_PDRV_GENIRQ=y
# CONFIG_UIO_DMEM_GENIRQ is not set
# CONFIG_VIRT_DRIVERS is not set
CONFIG_VIRTIO=y

#
# Virtio drivers
#
# CONFIG_VIRTIO_BALLOON is not set
# CONFIG_VIRTIO_MMIO is not set

#
# Microsoft Hyper-V guest support
#
# CONFIG_STAGING is not set
CONFIG_CLKDEV_LOOKUP=y
CONFIG_HAVE_CLK_PREPARE=y
CONFIG_COMMON_CLK=y

#
# Common Clock Framework
#
# CONFIG_COMMON_CLK_DEBUG is not set
# CONFIG_COMMON_CLK_WM831X is not set
CONFIG_COMMON_CLK_VERSATILE=y
# CONFIG_COMMON_CLK_MAX77686 is not set
# CONFIG_COMMON_CLK_SI5351 is not set
CONFIG_CLK_TWL6040=y
CONFIG_MVEBU_CLK_CORE=y
CONFIG_MVEBU_CLK_CPU=y
CONFIG_MVEBU_CLK_GATING=y

#
# Hardware Spinlock drivers
#
# CONFIG_HSEM_U8500 is not set
CONFIG_CLKSRC_OF=y
CONFIG_CLKSRC_MMIO=y
CONFIG_DW_APB_TIMER=y
CONFIG_DW_APB_TIMER_OF=y
CONFIG_ARMADA_370_XP_TIMER=y
CONFIG_SUN4I_TIMER=y
CONFIG_CLKSRC_NOMADIK_MTU=y
# CONFIG_CLKSRC_DBX500_PRCMU is not set
CONFIG_ARM_ARCH_TIMER=y
CONFIG_MAILBOX=y
CONFIG_PL320_MBOX=y
CONFIG_OMAP2PLUS_MBOX=y
CONFIG_DBX500_MBOX=y
CONFIG_MBOX_KFIFO_SIZE=256
CONFIG_MBOX_DATA_SIZE=64
CONFIG_IOMMU_SUPPORT=y
CONFIG_OF_IOMMU=y
# CONFIG_OMAP_IOMMU is not set

#
# Remoteproc drivers
#
CONFIG_REMOTEPROC=y
CONFIG_STE_MODEM_RPROC=y

#
# Rpmsg drivers
#
# CONFIG_PM_DEVFREQ is not set
# CONFIG_EXTCON is not set
CONFIG_MEMORY=y
CONFIG_TI_EMIF=y
# CONFIG_IIO is not set
CONFIG_PWM=y
CONFIG_PWM_TIECAP=y
# CONFIG_PWM_TIEHRPWM is not set
CONFIG_PWM_TIPWMSS=y
CONFIG_PWM_TWL=y
CONFIG_PWM_TWL_LED=y
CONFIG_IRQCHIP=y
CONFIG_ARM_GIC=y
CONFIG_ARM_VIC=y
CONFIG_ARM_VIC_NR=2
CONFIG_IPACK_BUS=y
# CONFIG_RESET_CONTROLLER is not set

#
# File systems
#
CONFIG_DCACHE_WORD_ACCESS=y
CONFIG_EXT2_FS=y
# CONFIG_EXT2_FS_XATTR is not set
CONFIG_EXT2_FS_XIP=y
CONFIG_EXT3_FS=y
# CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set
CONFIG_EXT3_FS_XATTR=y
CONFIG_EXT3_FS_POSIX_ACL=y
# CONFIG_EXT3_FS_SECURITY is not set
# CONFIG_EXT4_FS is not set
CONFIG_FS_XIP=y
CONFIG_JBD=y
CONFIG_JBD_DEBUG=y
CONFIG_FS_MBCACHE=y
# CONFIG_REISERFS_FS is not set
CONFIG_JFS_FS=y
# CONFIG_JFS_POSIX_ACL is not set
# CONFIG_JFS_SECURITY is not set
# CONFIG_JFS_DEBUG is not set
CONFIG_JFS_STATISTICS=y
CONFIG_XFS_FS=y
CONFIG_XFS_QUOTA=y
# CONFIG_XFS_POSIX_ACL is not set
CONFIG_XFS_RT=y
CONFIG_XFS_DEBUG=y
# CONFIG_OCFS2_FS is not set
# CONFIG_BTRFS_FS is not set
CONFIG_NILFS2_FS=y
CONFIG_FS_POSIX_ACL=y
CONFIG_EXPORTFS=y
CONFIG_FILE_LOCKING=y
CONFIG_FSNOTIFY=y
# CONFIG_DNOTIFY is not set
CONFIG_INOTIFY_USER=y
# CONFIG_FANOTIFY is not set
# CONFIG_QUOTA is not set
CONFIG_QUOTA_NETLINK_INTERFACE=y
CONFIG_QUOTACTL=y
# CONFIG_AUTOFS4_FS is not set
CONFIG_FUSE_FS=y
# CONFIG_CUSE is not set

#
# Caches
#
# CONFIG_FSCACHE is not set

#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=y
# CONFIG_JOLIET is not set
# CONFIG_ZISOFS is not set
# CONFIG_UDF_FS is not set

#
# DOS/FAT/NT Filesystems
#
# CONFIG_MSDOS_FS is not set
# CONFIG_VFAT_FS is not set
# CONFIG_NTFS_FS is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
# CONFIG_PROC_VMCORE is not set
# CONFIG_PROC_SYSCTL is not set
CONFIG_PROC_PAGE_MONITOR=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
# CONFIG_TMPFS_POSIX_ACL is not set
CONFIG_TMPFS_XATTR=y
# CONFIG_HUGETLB_PAGE is not set
CONFIG_CONFIGFS_FS=y
# CONFIG_MISC_FILESYSTEMS is not set
# CONFIG_NETWORK_FILESYSTEMS is not set
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
# CONFIG_NLS_CODEPAGE_437 is not set
# CONFIG_NLS_CODEPAGE_737 is not set
CONFIG_NLS_CODEPAGE_775=y
CONFIG_NLS_CODEPAGE_850=y
CONFIG_NLS_CODEPAGE_852=y
CONFIG_NLS_CODEPAGE_855=y
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
CONFIG_NLS_CODEPAGE_861=y
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
CONFIG_NLS_CODEPAGE_864=y
CONFIG_NLS_CODEPAGE_865=y
CONFIG_NLS_CODEPAGE_866=y
CONFIG_NLS_CODEPAGE_869=y
CONFIG_NLS_CODEPAGE_936=y
CONFIG_NLS_CODEPAGE_950=y
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
CONFIG_NLS_CODEPAGE_874=y
# CONFIG_NLS_ISO8859_8 is not set
CONFIG_NLS_CODEPAGE_1250=y
# CONFIG_NLS_CODEPAGE_1251 is not set
# CONFIG_NLS_ASCII is not set
CONFIG_NLS_ISO8859_1=y
CONFIG_NLS_ISO8859_2=y
# CONFIG_NLS_ISO8859_3 is not set
CONFIG_NLS_ISO8859_4=y
CONFIG_NLS_ISO8859_5=y
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
CONFIG_NLS_ISO8859_13=y
CONFIG_NLS_ISO8859_14=y
# CONFIG_NLS_ISO8859_15 is not set
CONFIG_NLS_KOI8_R=y
# CONFIG_NLS_KOI8_U is not set
# CONFIG_NLS_MAC_ROMAN is not set
# CONFIG_NLS_MAC_CELTIC is not set
# CONFIG_NLS_MAC_CENTEURO is not set
CONFIG_NLS_MAC_CROATIAN=y
# CONFIG_NLS_MAC_CYRILLIC is not set
CONFIG_NLS_MAC_GAELIC=y
# CONFIG_NLS_MAC_GREEK is not set
CONFIG_NLS_MAC_ICELAND=y
# CONFIG_NLS_MAC_INUIT is not set
# CONFIG_NLS_MAC_ROMANIAN is not set
CONFIG_NLS_MAC_TURKISH=y
CONFIG_NLS_UTF8=y

#
# Kernel hacking
#
CONFIG_DEFAULT_MESSAGE_LOGLEVEL=4
# CONFIG_ENABLE_WARN_DEPRECATED is not set
# CONFIG_ENABLE_MUST_CHECK is not set
CONFIG_FRAME_WARN=1024
CONFIG_MAGIC_SYSRQ=y
# CONFIG_STRIP_ASM_SYMS is not set
CONFIG_READABLE_ASM=y
CONFIG_UNUSED_SYMBOLS=y
CONFIG_DEBUG_FS=y
# CONFIG_HEADERS_CHECK is not set
CONFIG_DEBUG_SECTION_MISMATCH=y
CONFIG_DEBUG_KERNEL=y
CONFIG_DEBUG_SHIRQ=y
# CONFIG_LOCKUP_DETECTOR is not set
# CONFIG_PANIC_ON_OOPS is not set
CONFIG_PANIC_ON_OOPS_VALUE=0
CONFIG_DETECT_HUNG_TASK=y
CONFIG_DEFAULT_HUNG_TASK_TIMEOUT=120
CONFIG_BOOTPARAM_HUNG_TASK_PANIC=y
CONFIG_BOOTPARAM_HUNG_TASK_PANIC_VALUE=1
CONFIG_SCHED_DEBUG=y
CONFIG_SCHEDSTATS=y
CONFIG_TIMER_STATS=y
# CONFIG_DEBUG_OBJECTS is not set
# CONFIG_SLUB_STATS is not set
CONFIG_HAVE_DEBUG_KMEMLEAK=y
CONFIG_DEBUG_KMEMLEAK=y
CONFIG_DEBUG_KMEMLEAK_EARLY_LOG_SIZE=400
# CONFIG_DEBUG_KMEMLEAK_DEFAULT_OFF is not set
# CONFIG_DEBUG_RT_MUTEXES is not set
# CONFIG_RT_MUTEX_TESTER is not set
CONFIG_DEBUG_SPINLOCK=y
CONFIG_DEBUG_MUTEXES=y
CONFIG_DEBUG_LOCK_ALLOC=y
# CONFIG_PROVE_LOCKING is not set
CONFIG_LOCKDEP=y
CONFIG_LOCK_STAT=y
CONFIG_DEBUG_LOCKDEP=y
# CONFIG_DEBUG_ATOMIC_SLEEP is not set
CONFIG_DEBUG_LOCKING_API_SELFTESTS=y
CONFIG_STACKTRACE=y
CONFIG_DEBUG_STACK_USAGE=y
# CONFIG_DEBUG_KOBJECT is not set
# CONFIG_DEBUG_HIGHMEM is not set
# CONFIG_DEBUG_INFO is not set
# CONFIG_DEBUG_VM is not set
# CONFIG_DEBUG_WRITECOUNT is not set
CONFIG_DEBUG_MEMORY_INIT=y
# CONFIG_DEBUG_LIST is not set
CONFIG_TEST_LIST_SORT=y
CONFIG_DEBUG_SG=y
CONFIG_DEBUG_NOTIFIERS=y
CONFIG_DEBUG_CREDENTIALS=y
CONFIG_FRAME_POINTER=y

#
# RCU Debugging
#
# CONFIG_SPARSE_RCU_POINTER is not set
CONFIG_RCU_TORTURE_TEST=y
CONFIG_RCU_TORTURE_TEST_RUNNABLE=y
CONFIG_RCU_CPU_STALL_TIMEOUT=21
CONFIG_RCU_CPU_STALL_INFO=y
CONFIG_RCU_TRACE=y
# CONFIG_BACKTRACE_SELF_TEST is not set
# CONFIG_DEBUG_BLOCK_EXT_DEVT is not set
CONFIG_DEBUG_FORCE_WEAK_PER_CPU=y
CONFIG_DEBUG_PER_CPU_MAPS=y
# CONFIG_LKDTM is not set
# CONFIG_NOTIFIER_ERROR_INJECTION is not set
CONFIG_FAULT_INJECTION=y
CONFIG_FAILSLAB=y
CONFIG_FAIL_PAGE_ALLOC=y
# CONFIG_FAIL_MAKE_REQUEST is not set
CONFIG_FAIL_IO_TIMEOUT=y
# CONFIG_FAULT_INJECTION_DEBUG_FS is not set
# CONFIG_DEBUG_PAGEALLOC is not set
CONFIG_HAVE_FUNCTION_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y
CONFIG_HAVE_DYNAMIC_FTRACE=y
CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y
CONFIG_HAVE_SYSCALL_TRACEPOINTS=y
CONFIG_HAVE_C_RECORDMCOUNT=y
CONFIG_TRACE_CLOCK=y
CONFIG_RING_BUFFER=y
CONFIG_RING_BUFFER_ALLOW_SWAP=y
CONFIG_TRACING_SUPPORT=y
# CONFIG_FTRACE is not set
# CONFIG_DMA_API_DEBUG is not set
CONFIG_ATOMIC64_SELFTEST=y
# CONFIG_SAMPLES is not set
CONFIG_HAVE_ARCH_KGDB=y
CONFIG_KGDB=y
# CONFIG_KGDB_TESTS is not set
CONFIG_KGDB_KDB=y
CONFIG_KDB_CONTINUE_CATASTROPHIC=0
# CONFIG_TEST_STRING_HELPERS is not set
# CONFIG_TEST_KSTRTOX is not set
CONFIG_STRICT_DEVMEM=y
# CONFIG_ARM_UNWIND is not set
CONFIG_DEBUG_USER=y
CONFIG_DEBUG_LL=y
CONFIG_DEBUG_HIGHBANK_UART=y
# CONFIG_DEBUG_MVEBU_UART is not set
# CONFIG_DEBUG_OMAP2PLUS_UART is not set
# CONFIG_DEBUG_PICOXCELL_UART is not set
# CONFIG_DEBUG_SOCFPGA_UART is not set
# CONFIG_DEBUG_SUNXI_UART0 is not set
# CONFIG_DEBUG_SUNXI_UART1 is not set
# CONFIG_DEBUG_SIRFPRIMA2_UART1 is not set
# CONFIG_DEBUG_SIRFMARCO_UART1 is not set
# CONFIG_DEBUG_UX500_UART is not set
# CONFIG_DEBUG_VEXPRESS_UART0_DETECT is not set
# CONFIG_DEBUG_VEXPRESS_UART0_CA9 is not set
# CONFIG_DEBUG_VEXPRESS_UART0_RS1 is not set
# CONFIG_DEBUG_ICEDCC is not set
# CONFIG_DEBUG_SEMIHOSTING is not set
CONFIG_DEBUG_LL_INCLUDE="debug/highbank.S"
CONFIG_DEBUG_UNCOMPRESS=y
CONFIG_UNCOMPRESS_INCLUDE="debug/uncompress.h"
CONFIG_EARLY_PRINTK=y
CONFIG_OC_ETM=y
# CONFIG_PID_IN_CONTEXTIDR is not set

#
# Security options
#
# CONFIG_KEYS is not set
CONFIG_SECURITY_DMESG_RESTRICT=y
CONFIG_SECURITY=y
CONFIG_SECURITYFS=y
CONFIG_SECURITY_NETWORK=y
CONFIG_SECURITY_PATH=y
# CONFIG_SECURITY_TOMOYO is not set
CONFIG_SECURITY_APPARMOR=y
CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE=1
CONFIG_SECURITY_YAMA=y
# CONFIG_SECURITY_YAMA_STACKED is not set
CONFIG_INTEGRITY=y
CONFIG_IMA=y
CONFIG_IMA_MEASURE_PCR_IDX=10
CONFIG_IMA_AUDIT=y
# CONFIG_IMA_APPRAISE is not set
CONFIG_DEFAULT_SECURITY_APPARMOR=y
# CONFIG_DEFAULT_SECURITY_YAMA is not set
# CONFIG_DEFAULT_SECURITY_DAC is not set
CONFIG_DEFAULT_SECURITY="apparmor"
CONFIG_CRYPTO=y

#
# Crypto core or helper
#
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_ALGAPI2=y
CONFIG_CRYPTO_AEAD=y
CONFIG_CRYPTO_AEAD2=y
CONFIG_CRYPTO_BLKCIPHER=y
CONFIG_CRYPTO_BLKCIPHER2=y
CONFIG_CRYPTO_HASH=y
CONFIG_CRYPTO_HASH2=y
CONFIG_CRYPTO_RNG=y
CONFIG_CRYPTO_RNG2=y
CONFIG_CRYPTO_PCOMP2=y
CONFIG_CRYPTO_MANAGER=y
CONFIG_CRYPTO_MANAGER2=y
CONFIG_CRYPTO_USER=y
CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=y
CONFIG_CRYPTO_GF128MUL=y
# CONFIG_CRYPTO_NULL is not set
CONFIG_CRYPTO_PCRYPT=y
CONFIG_CRYPTO_WORKQUEUE=y
# CONFIG_CRYPTO_CRYPTD is not set
# CONFIG_CRYPTO_AUTHENC is not set

#
# Authenticated Encryption with Associated Data
#
CONFIG_CRYPTO_CCM=y
# CONFIG_CRYPTO_GCM is not set
CONFIG_CRYPTO_SEQIV=y

#
# Block modes
#
# CONFIG_CRYPTO_CBC is not set
CONFIG_CRYPTO_CTR=y
# CONFIG_CRYPTO_CTS is not set
# CONFIG_CRYPTO_ECB is not set
CONFIG_CRYPTO_LRW=y
# CONFIG_CRYPTO_PCBC is not set
# CONFIG_CRYPTO_XTS is not set

#
# Hash modes
#
CONFIG_CRYPTO_CMAC=y
CONFIG_CRYPTO_HMAC=y
CONFIG_CRYPTO_XCBC=y
# CONFIG_CRYPTO_VMAC is not set

#
# Digest
#
CONFIG_CRYPTO_CRC32C=y
CONFIG_CRYPTO_CRC32=y
# CONFIG_CRYPTO_GHASH is not set
CONFIG_CRYPTO_MD4=y
CONFIG_CRYPTO_MD5=y
CONFIG_CRYPTO_MICHAEL_MIC=y
CONFIG_CRYPTO_RMD128=y
CONFIG_CRYPTO_RMD160=y
CONFIG_CRYPTO_RMD256=y
# CONFIG_CRYPTO_RMD320 is not set
CONFIG_CRYPTO_SHA1=y
# CONFIG_CRYPTO_SHA1_ARM is not set
# CONFIG_CRYPTO_SHA256 is not set
CONFIG_CRYPTO_SHA512=y
# CONFIG_CRYPTO_TGR192 is not set
# CONFIG_CRYPTO_WP512 is not set

#
# Ciphers
#
CONFIG_CRYPTO_AES=y
CONFIG_CRYPTO_AES_ARM=y
CONFIG_CRYPTO_ANUBIS=y
# CONFIG_CRYPTO_ARC4 is not set
CONFIG_CRYPTO_BLOWFISH=y
CONFIG_CRYPTO_BLOWFISH_COMMON=y
# CONFIG_CRYPTO_CAMELLIA is not set
CONFIG_CRYPTO_CAST_COMMON=y
# CONFIG_CRYPTO_CAST5 is not set
CONFIG_CRYPTO_CAST6=y
CONFIG_CRYPTO_DES=y
# CONFIG_CRYPTO_FCRYPT is not set
CONFIG_CRYPTO_KHAZAD=y
# CONFIG_CRYPTO_SALSA20 is not set
# CONFIG_CRYPTO_SEED is not set
CONFIG_CRYPTO_SERPENT=y
# CONFIG_CRYPTO_TEA is not set
# CONFIG_CRYPTO_TWOFISH is not set

#
# Compression
#
CONFIG_CRYPTO_DEFLATE=y
# CONFIG_CRYPTO_ZLIB is not set
CONFIG_CRYPTO_LZO=y
# CONFIG_CRYPTO_LZ4 is not set
# CONFIG_CRYPTO_LZ4HC is not set

#
# Random Number Generation
#
CONFIG_CRYPTO_ANSI_CPRNG=y
CONFIG_CRYPTO_USER_API=y
# CONFIG_CRYPTO_USER_API_HASH is not set
CONFIG_CRYPTO_USER_API_SKCIPHER=y
# CONFIG_CRYPTO_HW is not set
# CONFIG_BINARY_PRINTF is not set

#
# Library routines
#
CONFIG_BITREVERSE=y
CONFIG_GENERIC_STRNCPY_FROM_USER=y
CONFIG_GENERIC_STRNLEN_USER=y
CONFIG_GENERIC_PCI_IOMAP=y
CONFIG_GENERIC_IO=y
CONFIG_CRC_CCITT=y
CONFIG_CRC16=y
CONFIG_CRC_T10DIF=y
# CONFIG_CRC_ITU_T is not set
CONFIG_CRC32=y
# CONFIG_CRC32_SELFTEST is not set
CONFIG_CRC32_SLICEBY8=y
# CONFIG_CRC32_SLICEBY4 is not set
# CONFIG_CRC32_SARWATE is not set
# CONFIG_CRC32_BIT is not set
CONFIG_CRC7=y
CONFIG_LIBCRC32C=y
# CONFIG_CRC8 is not set
CONFIG_AUDIT_GENERIC=y
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
CONFIG_LZO_COMPRESS=y
CONFIG_LZO_DECOMPRESS=y
CONFIG_XZ_DEC=y
# CONFIG_XZ_DEC_X86 is not set
CONFIG_XZ_DEC_POWERPC=y
# CONFIG_XZ_DEC_IA64 is not set
# CONFIG_XZ_DEC_ARM is not set
# CONFIG_XZ_DEC_ARMTHUMB is not set
# CONFIG_XZ_DEC_SPARC is not set
CONFIG_XZ_DEC_BCJ=y
# CONFIG_XZ_DEC_TEST is not set
CONFIG_GENERIC_ALLOCATOR=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_DMA=y
# CONFIG_CPUMASK_OFFSTACK is not set
CONFIG_CPU_RMAP=y
CONFIG_DQL=y
CONFIG_NLATTR=y
CONFIG_GENERIC_ATOMIC64=y
CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE=y
# CONFIG_AVERAGE is not set
# CONFIG_CORDIC is not set
CONFIG_DDR=y
# CONFIG_VIRTUALIZATION is not set

From tony at atomide.com  Fri Apr 19 15:51:01 2013
From: tony at atomide.com (Tony Lindgren)
Date: Fri, 19 Apr 2013 12:51:01 -0700
Subject: linux-next ARM multi-platform randconfig errors
In-Reply-To: <20130419194323.GP10155@atomide.com>
References: <5170B4C6.1030300@gmail.com> <20130419161257.GI10155@atomide.com>
 <517173C0.6010902@ti.com> <20130419194323.GP10155@atomide.com>
Message-ID: <20130419195100.GR10155@atomide.com>

* Tony Lindgren <tony at atomide.com> [130419 12:49]:
> * Tomi Valkeinen <tomi.valkeinen at ti.com> [130419 09:46]:
> > On 2013-04-19 19:12, Tony Lindgren wrote:
> > > * Rob Herring <robherring2 at gmail.com> [130418 20:11]:
> > 
> > >> dss-common.c:(.cpuinit.text+0x38): undefined reference to `omap_get_wakeupgen_base'
> > >> dss-common.c:(.cpuinit.text+0x48): undefined reference to `omap_secure_apis_support'
> > >> dss-common.c:(.init.text+0x3db0): undefined reference to `omap_get_wakeupgen_base'
> > >> dss-common.c:(.init.text+0x3dcc): undefined reference to `omap_secure_apis_support'
> > >> dss-common.c:(.init.text+0x61b8): undefined reference to `usb_bind_phy'
> > >> dss-common.c:(.init.text+0x6314): undefined reference to `usb_bind_phy'
> > >> dss-common.c:(.init.text+0x6488): undefined reference to `usb_bind_phy'
> > >> dss-common.c:(.init.text+0x65ac): undefined reference to `usb_bind_phy'
> > >> dss-common.c:(.ref.text+0x10): undefined reference to `omap_get_wakeupgen_base'
> > >> dss-common.c:(.ref.text+0x18): undefined reference to `omap_secure_apis_support'
> > >> dss-common.c:(.ref.text+0x54): undefined reference to `omap4_hotplug_cpu'
> > >> dss-common.c:(.ref.text+0x58): undefined reference to `omap_secure_apis_support'
> > >> dss-common.c:(.text+0x11b5c): undefined reference to `usb_bind_phy'
> > > 
> > > Tomi, can you take a look at the dss-common.c one? That should be
> > > reproducable with omap2plus_defconfig and modifying some options
> > > there.
> > 
> > None of those functions are used by dss-common.c, so I don't really know
> > what that is about. Doesn't look correct errors to me... I can try to
> > reproduce.
> 
> This might happen when no SoC selected. There was a patch posted
> by Arnd to always select 2420 if nothing else is selected as it's the
> most minimal one. But Russell did not like that, so probably the way
> to fix that would be to have bool OMAP_SOC and if not selected, don't
> even try to build anything. I'll take a look at that.
> 
> > Btw, there's also this:
> > 
> > >> drivers/video/omap2/dss/dpi.c:181:2: error: implicit declaration of function 'dsi_hsdiv_calc' [-Werror=implicit-function-declaration]
> > >> drivers/video/omap2/dss/dpi.c:201:2: error: implicit declaration of function 'dsi_get_pll_clkin' [-Werror=implicit-function-declaration]
> > >> drivers/video/omap2/dss/dpi.c:212:2: error: implicit declaration of function 'dsi_pll_calc' [-Werror=implicit-function-declaration]
> > 
> > I have a patch for that, not yet applied.
> 
> OK thanks.

Sorry forgot to leave out my .config in the previous mail. No need for
the .config I posted as you already have those errors fixed.

Regards,

Tony 


From jon-hunter at ti.com  Fri Apr 19 15:52:53 2013
From: jon-hunter at ti.com (Jon Hunter)
Date: Fri, 19 Apr 2013 14:52:53 -0500
Subject: linux-next ARM multi-platform randconfig errors
In-Reply-To: <517173C0.6010902@ti.com>
References: <5170B4C6.1030300@gmail.com> <20130419161257.GI10155@atomide.com>
 <517173C0.6010902@ti.com>
Message-ID: <5171A095.8010104@ti.com>


On 04/19/2013 11:41 AM, Tomi Valkeinen wrote:
> On 2013-04-19 19:12, Tony Lindgren wrote:
>> * Rob Herring <robherring2 at gmail.com> [130418 20:11]:
> 
>>> dss-common.c:(.cpuinit.text+0x38): undefined reference to `omap_get_wakeupgen_base'
>>> dss-common.c:(.cpuinit.text+0x48): undefined reference to `omap_secure_apis_support'
>>> dss-common.c:(.init.text+0x3db0): undefined reference to `omap_get_wakeupgen_base'
>>> dss-common.c:(.init.text+0x3dcc): undefined reference to `omap_secure_apis_support'
>>> dss-common.c:(.init.text+0x61b8): undefined reference to `usb_bind_phy'
>>> dss-common.c:(.init.text+0x6314): undefined reference to `usb_bind_phy'
>>> dss-common.c:(.init.text+0x6488): undefined reference to `usb_bind_phy'
>>> dss-common.c:(.init.text+0x65ac): undefined reference to `usb_bind_phy'
>>> dss-common.c:(.ref.text+0x10): undefined reference to `omap_get_wakeupgen_base'
>>> dss-common.c:(.ref.text+0x18): undefined reference to `omap_secure_apis_support'
>>> dss-common.c:(.ref.text+0x54): undefined reference to `omap4_hotplug_cpu'
>>> dss-common.c:(.ref.text+0x58): undefined reference to `omap_secure_apis_support'
>>> dss-common.c:(.text+0x11b5c): undefined reference to `usb_bind_phy'
>>
>> Tomi, can you take a look at the dss-common.c one? That should be
>> reproducable with omap2plus_defconfig and modifying some options
>> there.
> 
> None of those functions are used by dss-common.c, so I don't really know
> what that is about. Doesn't look correct errors to me... I can try to
> reproduce.

The attached config generates the following ...

arch/arm/mach-omap2/built-in.o: In function `_add_initiator_dep':
dss-common.c:(.text+0x41b0): undefined reference to `clkdm_add_sleepdep'
arch/arm/mach-omap2/built-in.o: In function `_del_initiator_dep':
dss-common.c:(.text+0x4210): undefined reference to `clkdm_del_sleepdep'
arch/arm/mach-omap2/built-in.o: In function `_enable':
dss-common.c:(.text+0x475c): undefined reference to `clkdm_in_hwsup'
dss-common.c:(.text+0x4770): undefined reference to `clkdm_hwmod_enable'
dss-common.c:(.text+0x47b0): undefined reference to `clkdm_hwmod_disable'
dss-common.c:(.text+0x47e8): undefined reference to `clkdm_missing_idle_reporting'
arch/arm/mach-omap2/built-in.o: In function `_idle':
dss-common.c:(.text+0x4b28): undefined reference to `clkdm_hwmod_disable'
arch/arm/mach-omap2/built-in.o: In function `_shutdown':
dss-common.c:(.text+0x4d8c): undefined reference to `clkdm_hwmod_disable'
arch/arm/mach-omap2/built-in.o: In function `omap_hwmod_get_context_loss_count':
dss-common.c:(.text+0x5d10): undefined reference to `pwrdm_get_context_loss_count'
arch/arm/mach-omap2/built-in.o: In function `omap_pm_clkdms_setup':
dss-common.c:(.init.text+0x1df0): undefined reference to `clkdm_allow_idle'
dss-common.c:(.init.text+0x1e0c): undefined reference to `clkdm_sleep'
arch/arm/mach-omap2/built-in.o: In function `omap2_common_pm_late_init':
dss-common.c:(.init.text+0x1e38): undefined reference to `omap_voltage_late_init'
arch/arm/mach-omap2/built-in.o: In function `omap2_gpio_dev_init':
dss-common.c:(.init.text+0x219c): undefined reference to `pwrdm_can_ever_lose_context'
arch/arm/mach-omap2/built-in.o: In function `omap4_smp_prepare_cpus':
dss-common.c:(.init.text+0x3648): undefined reference to `omap_get_wakeupgen_base'
dss-common.c:(.init.text+0x3668): undefined reference to `omap_secure_apis_support'
dss-common.c:(.init.text+0x3684): undefined reference to `omap_auxcoreboot_addr'
arch/arm/mach-omap2/built-in.o: In function `omap4_boot_secondary':
dss-common.c:(.cpuinit.text+0x38): undefined reference to `omap_get_wakeupgen_base'
dss-common.c:(.cpuinit.text+0x4c): undefined reference to `omap_secure_apis_support'
dss-common.c:(.cpuinit.text+0x60): undefined reference to `omap_modify_auxcoreboot0'
dss-common.c:(.cpuinit.text+0x98): undefined reference to `clkdm_lookup'
dss-common.c:(.cpuinit.text+0xa8): undefined reference to `pwrdm_lookup'
dss-common.c:(.cpuinit.text+0xe0): undefined reference to `clkdm_wakeup'
dss-common.c:(.cpuinit.text+0xec): undefined reference to `omap_set_pwrdm_state'
dss-common.c:(.cpuinit.text+0xf4): undefined reference to `clkdm_allow_idle'
arch/arm/mach-omap2/built-in.o: In function `omap4_cpu_die':
dss-common.c:(.ref.text+0x8): undefined reference to `omap_get_wakeupgen_base'
dss-common.c:(.ref.text+0x10): undefined reference to `omap_secure_apis_support'
dss-common.c:(.ref.text+0x4c): undefined reference to `omap4_hotplug_cpu'
dss-common.c:(.ref.text+0x50): undefined reference to `omap_secure_apis_support'
dss-common.c:(.ref.text+0x5c): undefined reference to `omap_read_auxcoreboot0'
dss-common.c:(.ref.text+0x78): undefined reference to `omap_modify_auxcoreboot0'

Looks like if support for TI OMAP2/3/4/5 SOCs is enabled, but all
of OMAP2/3/4/5/AM33XX devices are then disabled you will get the
above errors.

I think that the error is misleading, because AFAICT it has nothing
to do with dss-common.c. The errors are because files like
clockdomain.c and powerdomain.c are not being compiled but
omap_hwmod.c is. 

Cheers
Jon
-------------- next part --------------
#
# Automatically generated file; DO NOT EDIT.
# Linux/arm 3.9.0-rc7 Kernel Configuration
#
CONFIG_ARM=y
CONFIG_SYS_SUPPORTS_APM_EMULATION=y
CONFIG_HAVE_PROC_CPU=y
CONFIG_NO_IOPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_RWSEM_GENERIC_SPINLOCK=y
CONFIG_ARCH_HAS_CPUFREQ=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ZONE_DMA=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_VECTORS_BASE=0xffff0000
CONFIG_ARM_PATCH_PHYS_VIRT=y
CONFIG_GENERIC_BUG=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y

#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
# CONFIG_SYSVIPC is not set
# CONFIG_POSIX_MQUEUE is not set
# CONFIG_FHANDLE is not set
# CONFIG_AUDIT is not set
CONFIG_HAVE_GENERIC_HARDIRQS=y

#
# IRQ subsystem
#
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_HARDIRQS_SW_RESEND=y
CONFIG_GENERIC_IRQ_CHIP=y
CONFIG_IRQ_DOMAIN=y
CONFIG_SPARSE_IRQ=y
# CONFIG_ALWAYS_USE_PERSISTENT_CLOCK is not set
CONFIG_KTIME_SCALAR=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_ARCH_HAS_TICK_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y

#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_PERIODIC_HZ=y
# CONFIG_NO_HZ_IDLE is not set
CONFIG_HIGH_RES_TIMERS=y

#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_TASKSTATS is not set

#
# RCU Subsystem
#
CONFIG_TREE_RCU=y
# CONFIG_PREEMPT_RCU is not set
CONFIG_RCU_STALL_COMMON=y
# CONFIG_RCU_USER_QS is not set
CONFIG_RCU_FANOUT=32
CONFIG_RCU_FANOUT_LEAF=16
# CONFIG_RCU_FANOUT_EXACT is not set
# CONFIG_TREE_RCU_TRACE is not set
# CONFIG_RCU_NOCB_CPU is not set
# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=17
# CONFIG_CGROUPS is not set
# CONFIG_CHECKPOINT_RESTORE is not set
CONFIG_NAMESPACES=y
CONFIG_UTS_NS=y
# CONFIG_USER_NS is not set
CONFIG_PID_NS=y
CONFIG_NET_NS=y
CONFIG_UIDGID_CONVERTED=y
# CONFIG_UIDGID_STRICT_TYPE_CHECKS is not set
# CONFIG_SCHED_AUTOGROUP is not set
# CONFIG_SYSFS_DEPRECATED is not set
# CONFIG_RELAY is not set
# CONFIG_BLK_DEV_INITRD is not set
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
# CONFIG_EXPERT is not set
CONFIG_HAVE_UID16=y
CONFIG_UID16=y
# CONFIG_SYSCTL_SYSCALL is not set
CONFIG_KALLSYMS=y
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_AIO=y
# CONFIG_EMBEDDED is not set
CONFIG_HAVE_PERF_EVENTS=y
CONFIG_PERF_USE_VMALLOC=y

#
# Kernel Performance Events And Counters
#
# CONFIG_PERF_EVENTS is not set
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_SLUB_DEBUG=y
CONFIG_COMPAT_BRK=y
# CONFIG_SLAB is not set
CONFIG_SLUB=y
# CONFIG_PROFILING is not set
CONFIG_HAVE_OPROFILE=y
# CONFIG_JUMP_LABEL is not set
# CONFIG_HAVE_64BIT_ALIGNED_ACCESS is not set
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
CONFIG_HAVE_ARCH_TRACEHOOK=y
CONFIG_HAVE_DMA_ATTRS=y
CONFIG_HAVE_DMA_CONTIGUOUS=y
CONFIG_USE_GENERIC_SMP_HELPERS=y
CONFIG_GENERIC_SMP_IDLE_THREAD=y
CONFIG_GENERIC_IDLE_LOOP=y
CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y
CONFIG_HAVE_CLK=y
CONFIG_HAVE_DMA_API_DEBUG=y
CONFIG_HAVE_ARCH_JUMP_LABEL=y
CONFIG_ARCH_WANT_IPC_PARSE_VERSION=y
CONFIG_HAVE_ARCH_SECCOMP_FILTER=y
CONFIG_HAVE_CONTEXT_TRACKING=y
CONFIG_HAVE_MOD_ARCH_SPECIFIC=y
CONFIG_MODULES_USE_ELF_REL=y
CONFIG_CLONE_BACKWARDS=y
CONFIG_OLD_SIGSUSPEND3=y
CONFIG_OLD_SIGACTION=y

#
# GCOV-based kernel profiling
#
CONFIG_HAVE_GENERIC_DMA_COHERENT=y
CONFIG_SLABINFO=y
CONFIG_RT_MUTEXES=y
CONFIG_BASE_SMALL=0
# CONFIG_MODULES is not set
CONFIG_STOP_MACHINE=y
CONFIG_BLOCK=y
CONFIG_LBDAF=y
CONFIG_BLK_DEV_BSG=y
# CONFIG_BLK_DEV_BSGLIB is not set
# CONFIG_BLK_DEV_INTEGRITY is not set

#
# Partition Types
#
# CONFIG_PARTITION_ADVANCED is not set
CONFIG_MSDOS_PARTITION=y
CONFIG_EFI_PARTITION=y

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_DEFAULT_DEADLINE is not set
CONFIG_DEFAULT_CFQ=y
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="cfq"
CONFIG_INLINE_SPIN_UNLOCK_IRQ=y
CONFIG_INLINE_READ_UNLOCK=y
CONFIG_INLINE_READ_UNLOCK_IRQ=y
CONFIG_INLINE_WRITE_UNLOCK=y
CONFIG_INLINE_WRITE_UNLOCK_IRQ=y
CONFIG_MUTEX_SPIN_ON_OWNER=y
CONFIG_FREEZER=y

#
# System Type
#
CONFIG_MMU=y
CONFIG_ARCH_MULTIPLATFORM=y
# CONFIG_ARCH_INTEGRATOR is not set
# CONFIG_ARCH_REALVIEW is not set
# CONFIG_ARCH_VERSATILE is not set
# CONFIG_ARCH_AT91 is not set
# CONFIG_ARCH_CLPS711X is not set
# CONFIG_ARCH_GEMINI is not set
# CONFIG_ARCH_EBSA110 is not set
# CONFIG_ARCH_EP93XX is not set
# CONFIG_ARCH_FOOTBRIDGE is not set
# CONFIG_ARCH_NETX is not set
# CONFIG_ARCH_IOP13XX is not set
# CONFIG_ARCH_IOP32X is not set
# CONFIG_ARCH_IOP33X is not set
# CONFIG_ARCH_IXP4XX is not set
# CONFIG_ARCH_DOVE is not set
# CONFIG_ARCH_KIRKWOOD is not set
# CONFIG_ARCH_MV78XX0 is not set
# CONFIG_ARCH_ORION5X is not set
# CONFIG_ARCH_MMP is not set
# CONFIG_ARCH_KS8695 is not set
# CONFIG_ARCH_W90X900 is not set
# CONFIG_ARCH_LPC32XX is not set
# CONFIG_ARCH_PXA is not set
# CONFIG_ARCH_MSM is not set
# CONFIG_ARCH_SHMOBILE is not set
# CONFIG_ARCH_RPC is not set
# CONFIG_ARCH_SA1100 is not set
# CONFIG_ARCH_S3C24XX is not set
# CONFIG_ARCH_S3C64XX is not set
# CONFIG_ARCH_S5P64X0 is not set
# CONFIG_ARCH_S5PC100 is not set
# CONFIG_ARCH_S5PV210 is not set
# CONFIG_ARCH_EXYNOS is not set
# CONFIG_ARCH_SHARK is not set
# CONFIG_ARCH_U300 is not set
# CONFIG_ARCH_DAVINCI is not set
# CONFIG_ARCH_OMAP1 is not set

#
# Multiple platform selection
#

#
# CPU Core family selection
#
# CONFIG_ARCH_MULTI_V6 is not set
CONFIG_ARCH_MULTI_V7=y
CONFIG_ARCH_MULTI_V6_V7=y
# CONFIG_ARCH_MULTI_CPU_AUTO is not set
CONFIG_ARCH_MVEBU=y

#
# Marvell SOC with device tree
#
CONFIG_MACH_ARMADA_370_XP=y
CONFIG_MACH_ARMADA_370=y
CONFIG_MACH_ARMADA_XP=y
# CONFIG_ARCH_BCM is not set
# CONFIG_GPIO_PCA953X is not set
# CONFIG_KEYBOARD_GPIO_POLLED is not set
CONFIG_ARCH_HIGHBANK=y
# CONFIG_ARCH_MXC is not set

#
# TI OMAP Common Features
#

#
# OMAP Feature Selections
#
# CONFIG_OMAP_RESET_CLOCKS is not set
CONFIG_OMAP_MUX=y
# CONFIG_OMAP_MUX_DEBUG is not set
CONFIG_OMAP_MUX_WARNINGS=y
CONFIG_OMAP_32K_TIMER=y
CONFIG_OMAP_DM_TIMER=y
CONFIG_OMAP_PM_NOOP=y
CONFIG_MACH_OMAP_GENERIC=y
CONFIG_ARCH_OMAP=y
CONFIG_ARCH_OMAP2PLUS=y

#
# TI OMAP2/3/4 Specific Features
#
CONFIG_ARCH_OMAP2PLUS_TYPICAL=y
CONFIG_SOC_HAS_OMAP2_SDRC=y
# CONFIG_ARCH_OMAP2 is not set
# CONFIG_ARCH_OMAP3 is not set
# CONFIG_ARCH_OMAP4 is not set
# CONFIG_SOC_OMAP5 is not set
# CONFIG_SOC_AM33XX is not set

#
# OMAP Board Type
#
CONFIG_ARCH_SOCFPGA=y
CONFIG_PLAT_SPEAR=y
CONFIG_ARCH_SPEAR13XX=y
CONFIG_MACH_SPEAR1310=y
CONFIG_MACH_SPEAR1340=y
CONFIG_ARCH_SUNXI=y
CONFIG_ARCH_SIRF=y

#
# CSR SiRF atlas6/primaII/Marco/Polo Specific Features
#
CONFIG_ARCH_ATLAS6=y
CONFIG_ARCH_PRIMA2=y
CONFIG_ARCH_MARCO=y
CONFIG_SIRF_IRQ=y
# CONFIG_ARCH_TEGRA is not set
# CONFIG_ARCH_U8500 is not set
CONFIG_ARCH_VEXPRESS=y

#
# Versatile Express platform type
#
# CONFIG_ARCH_VEXPRESS_CORTEX_A5_A9_ERRATA is not set
# CONFIG_ARCH_VEXPRESS_CA9X4 is not set
CONFIG_PLAT_VERSATILE_CLCD=y
CONFIG_PLAT_VERSATILE_SCHED_CLOCK=y
# CONFIG_ARCH_VIRT is not set
CONFIG_ARCH_VT8500=y
CONFIG_ARCH_WM8850=y
CONFIG_ARCH_ZYNQ=y
CONFIG_PLAT_ORION=y
CONFIG_PLAT_VERSATILE=y
CONFIG_ARM_TIMER_SP804=y

#
# Processor Type
#
CONFIG_CPU_PJ4B=y
CONFIG_CPU_V7=y
CONFIG_CPU_32v6K=y
CONFIG_CPU_32v7=y
CONFIG_CPU_ABRT_EV7=y
CONFIG_CPU_PABRT_V7=y
CONFIG_CPU_CACHE_V7=y
CONFIG_CPU_CACHE_VIPT=y
CONFIG_CPU_COPY_V6=y
CONFIG_CPU_TLB_V7=y
CONFIG_CPU_HAS_ASID=y
CONFIG_CPU_CP15=y
CONFIG_CPU_CP15_MMU=y

#
# Processor Features
#
# CONFIG_ARM_LPAE is not set
# CONFIG_ARCH_PHYS_ADDR_T_64BIT is not set
CONFIG_ARM_THUMB=y
# CONFIG_ARM_THUMBEE is not set
CONFIG_ARM_VIRT_EXT=y
CONFIG_SWP_EMULATE=y
# CONFIG_CPU_ICACHE_DISABLE is not set
# CONFIG_CPU_DCACHE_DISABLE is not set
# CONFIG_CPU_BPREDICT_DISABLE is not set
CONFIG_OUTER_CACHE=y
CONFIG_OUTER_CACHE_SYNC=y
CONFIG_MIGHT_HAVE_CACHE_L2X0=y
CONFIG_CACHE_L2X0=y
CONFIG_CACHE_PL310=y
CONFIG_ARM_L1_CACHE_SHIFT_6=y
CONFIG_ARM_L1_CACHE_SHIFT=6
CONFIG_ARM_DMA_MEM_BUFFERABLE=y
CONFIG_ARM_NR_BANKS=8
CONFIG_MULTI_IRQ_HANDLER=y
# CONFIG_ARM_ERRATA_430973 is not set
CONFIG_PL310_ERRATA_588369=y
CONFIG_ARM_ERRATA_720789=y
CONFIG_PL310_ERRATA_727915=y
# CONFIG_PL310_ERRATA_753970 is not set
CONFIG_ARM_ERRATA_754322=y
# CONFIG_ARM_ERRATA_754327 is not set
# CONFIG_ARM_ERRATA_764369 is not set
# CONFIG_PL310_ERRATA_769419 is not set
CONFIG_ARM_ERRATA_775420=y
# CONFIG_ARM_ERRATA_798181 is not set
CONFIG_ICST=y

#
# Bus support
#
CONFIG_ARM_AMBA=y
# CONFIG_PCI_SYSCALL is not set
# CONFIG_PCCARD is not set

#
# Kernel Features
#
CONFIG_HAVE_SMP=y
CONFIG_SMP=y
CONFIG_SMP_ON_UP=y
CONFIG_ARM_CPU_TOPOLOGY=y
# CONFIG_SCHED_MC is not set
# CONFIG_SCHED_SMT is not set
CONFIG_HAVE_ARM_SCU=y
# CONFIG_HAVE_ARM_ARCH_TIMER is not set
CONFIG_HAVE_ARM_TWD=y
CONFIG_VMSPLIT_3G=y
# CONFIG_VMSPLIT_2G is not set
# CONFIG_VMSPLIT_1G is not set
CONFIG_PAGE_OFFSET=0xC0000000
CONFIG_NR_CPUS=4
CONFIG_HOTPLUG_CPU=y
# CONFIG_ARM_PSCI is not set
CONFIG_LOCAL_TIMERS=y
CONFIG_ARCH_NR_GPIO=352
CONFIG_PREEMPT_NONE=y
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT is not set
CONFIG_HZ=100
CONFIG_SCHED_HRTICK=y
# CONFIG_THUMB2_KERNEL is not set
CONFIG_AEABI=y
CONFIG_OABI_COMPAT=y
CONFIG_ARCH_HAS_HOLES_MEMORYMODEL=y
# CONFIG_ARCH_SPARSEMEM_DEFAULT is not set
# CONFIG_ARCH_SELECT_MEMORY_MODEL is not set
CONFIG_HAVE_ARCH_PFN_VALID=y
CONFIG_HIGHMEM=y
CONFIG_HIGHPTE=y
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
CONFIG_HAVE_MEMBLOCK=y
# CONFIG_HAVE_BOOTMEM_INFO_NODE is not set
CONFIG_PAGEFLAGS_EXTENDED=y
CONFIG_SPLIT_PTLOCK_CPUS=4
CONFIG_COMPACTION=y
CONFIG_MIGRATION=y
# CONFIG_PHYS_ADDR_T_64BIT is not set
CONFIG_ZONE_DMA_FLAG=1
CONFIG_BOUNCE=y
# CONFIG_KSM is not set
CONFIG_DEFAULT_MMAP_MIN_ADDR=4096
CONFIG_CROSS_MEMORY_ATTACH=y
# CONFIG_CLEANCACHE is not set
# CONFIG_FRONTSWAP is not set
CONFIG_FORCE_MAX_ZONEORDER=11
CONFIG_ALIGNMENT_TRAP=y
# CONFIG_UACCESS_WITH_MEMCPY is not set
# CONFIG_SECCOMP is not set
# CONFIG_CC_STACKPROTECTOR is not set
# CONFIG_XEN is not set

#
# Boot options
#
CONFIG_USE_OF=y
CONFIG_ATAGS=y
# CONFIG_DEPRECATED_PARAM_STRUCT is not set
CONFIG_ZBOOT_ROM_TEXT=0
CONFIG_ZBOOT_ROM_BSS=0
CONFIG_ARM_APPENDED_DTB=y
# CONFIG_ARM_ATAG_DTB_COMPAT is not set
CONFIG_CMDLINE=""
# CONFIG_KEXEC is not set
# CONFIG_CRASH_DUMP is not set
CONFIG_AUTO_ZRELADDR=y

#
# CPU Power Management
#

#
# CPU Frequency scaling
#
# CONFIG_CPU_FREQ is not set
# CONFIG_CPU_IDLE is not set
# CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED is not set

#
# Floating point emulation
#

#
# At least one emulation must be selected
#
# CONFIG_FPE_NWFPE is not set
# CONFIG_FPE_FASTFPE is not set
CONFIG_VFP=y
CONFIG_VFPv3=y
CONFIG_NEON=y

#
# Userspace binary formats
#
CONFIG_BINFMT_ELF=y
CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE=y
CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS=y
CONFIG_BINFMT_SCRIPT=y
CONFIG_HAVE_AOUT=y
# CONFIG_BINFMT_AOUT is not set
# CONFIG_BINFMT_MISC is not set
CONFIG_COREDUMP=y

#
# Power management options
#
CONFIG_SUSPEND=y
CONFIG_SUSPEND_FREEZER=y
CONFIG_PM_SLEEP=y
CONFIG_PM_SLEEP_SMP=y
# CONFIG_PM_AUTOSLEEP is not set
# CONFIG_PM_WAKELOCKS is not set
CONFIG_PM_RUNTIME=y
CONFIG_PM=y
# CONFIG_PM_DEBUG is not set
# CONFIG_APM_EMULATION is not set
CONFIG_ARCH_HAS_OPP=y
CONFIG_PM_OPP=y
CONFIG_PM_CLK=y
CONFIG_CPU_PM=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARM_CPU_SUSPEND=y
CONFIG_NET=y

#
# Networking options
#
# CONFIG_PACKET is not set
# CONFIG_UNIX is not set
# CONFIG_NET_KEY is not set
# CONFIG_INET is not set
# CONFIG_NETWORK_SECMARK is not set
# CONFIG_NETWORK_PHY_TIMESTAMPING is not set
# CONFIG_NETFILTER is not set
# CONFIG_ATM is not set
# CONFIG_BRIDGE is not set
CONFIG_HAVE_NET_DSA=y
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_PHONET is not set
# CONFIG_IEEE802154 is not set
# CONFIG_NET_SCHED is not set
# CONFIG_DCB is not set
# CONFIG_BATMAN_ADV is not set
# CONFIG_OPENVSWITCH is not set
# CONFIG_VSOCKETS is not set
# CONFIG_NETLINK_DIAG is not set
CONFIG_RPS=y
CONFIG_RFS_ACCEL=y
CONFIG_XPS=y
CONFIG_BQL=y

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_HAMRADIO is not set
# CONFIG_CAN is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
CONFIG_WIRELESS=y
# CONFIG_CFG80211 is not set
# CONFIG_LIB80211 is not set

#
# CFG80211 needs to be enabled for MAC80211
#
# CONFIG_WIMAX is not set
# CONFIG_RFKILL is not set
# CONFIG_RFKILL_REGULATOR is not set
# CONFIG_NET_9P is not set
# CONFIG_CAIF is not set
# CONFIG_NFC is not set
CONFIG_HAVE_BPF_JIT=y

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_UEVENT_HELPER_PATH=""
# CONFIG_DEVTMPFS is not set
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
CONFIG_FIRMWARE_IN_KERNEL=y
CONFIG_EXTRA_FIRMWARE=""
CONFIG_FW_LOADER_USER_HELPER=y
# CONFIG_SYS_HYPERVISOR is not set
# CONFIG_GENERIC_CPU_DEVICES is not set
CONFIG_SOC_BUS=y
CONFIG_REGMAP=y
CONFIG_REGMAP_I2C=y
# CONFIG_DMA_SHARED_BUFFER is not set
# CONFIG_CMA is not set

#
# Bus devices
#
# CONFIG_OMAP_OCP2SCP is not set
CONFIG_OMAP_INTERCONNECT=y
# CONFIG_CONNECTOR is not set
# CONFIG_MTD is not set
CONFIG_DTC=y
CONFIG_OF=y

#
# Device Tree and Open Firmware support
#
CONFIG_PROC_DEVICETREE=y
# CONFIG_OF_SELFTEST is not set
CONFIG_OF_FLATTREE=y
CONFIG_OF_EARLY_FLATTREE=y
CONFIG_OF_ADDRESS=y
CONFIG_OF_IRQ=y
CONFIG_OF_DEVICE=y
CONFIG_OF_I2C=y
CONFIG_OF_NET=y
CONFIG_OF_MDIO=y
# CONFIG_PARPORT is not set
CONFIG_BLK_DEV=y
# CONFIG_BLK_DEV_COW_COMMON is not set
# CONFIG_BLK_DEV_LOOP is not set

#
# DRBD disabled because PROC_FS or INET not selected
#
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_RAM is not set
# CONFIG_CDROM_PKTCDVD is not set
# CONFIG_ATA_OVER_ETH is not set
# CONFIG_MG_DISK is not set
# CONFIG_BLOCKCONSOLE is not set

#
# Misc devices
#
# CONFIG_SENSORS_LIS3LV02D is not set
# CONFIG_AD525X_DPOT is not set
# CONFIG_ATMEL_PWM is not set
# CONFIG_DUMMY_IRQ is not set
# CONFIG_ICS932S401 is not set
# CONFIG_ATMEL_SSC is not set
# CONFIG_ENCLOSURE_SERVICES is not set
# CONFIG_APDS9802ALS is not set
# CONFIG_ISL29003 is not set
# CONFIG_ISL29020 is not set
# CONFIG_SENSORS_TSL2550 is not set
# CONFIG_SENSORS_BH1780 is not set
# CONFIG_SENSORS_BH1770 is not set
# CONFIG_SENSORS_APDS990X is not set
# CONFIG_HMC6352 is not set
# CONFIG_DS1682 is not set
# CONFIG_SPEAR13XX_PCIE_GADGET is not set
# CONFIG_TI_DAC7512 is not set
# CONFIG_ARM_CHARLCD is not set
# CONFIG_BMP085_I2C is not set
# CONFIG_BMP085_SPI is not set
# CONFIG_USB_SWITCH_FSA9480 is not set
# CONFIG_LATTICE_ECP3_CONFIG is not set
# CONFIG_SRAM is not set
# CONFIG_C2PORT is not set

#
# EEPROM support
#
# CONFIG_EEPROM_AT24 is not set
# CONFIG_EEPROM_AT25 is not set
# CONFIG_EEPROM_LEGACY is not set
# CONFIG_EEPROM_MAX6875 is not set
# CONFIG_EEPROM_93CX6 is not set
# CONFIG_EEPROM_93XX46 is not set

#
# Texas Instruments shared transport line discipline
#
# CONFIG_TI_ST is not set
# CONFIG_SENSORS_LIS3_SPI is not set
# CONFIG_SENSORS_LIS3_I2C is not set

#
# Altera FPGA firmware download module
#
# CONFIG_ALTERA_STAPL is not set

#
# SCSI device support
#
CONFIG_SCSI_MOD=y
# CONFIG_RAID_ATTRS is not set
CONFIG_SCSI=y
CONFIG_SCSI_DMA=y
# CONFIG_SCSI_TGT is not set
# CONFIG_SCSI_NETLINK is not set
CONFIG_SCSI_PROC_FS=y

#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=y
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
# CONFIG_BLK_DEV_SR is not set
# CONFIG_CHR_DEV_SG is not set
# CONFIG_CHR_DEV_SCH is not set
# CONFIG_SCSI_MULTI_LUN is not set
# CONFIG_SCSI_CONSTANTS is not set
# CONFIG_SCSI_LOGGING is not set
# CONFIG_SCSI_SCAN_ASYNC is not set

#
# SCSI Transports
#
# CONFIG_SCSI_SPI_ATTRS is not set
# CONFIG_SCSI_FC_ATTRS is not set
# CONFIG_SCSI_ISCSI_ATTRS is not set
# CONFIG_SCSI_SAS_ATTRS is not set
# CONFIG_SCSI_SAS_LIBSAS is not set
# CONFIG_SCSI_SRP_ATTRS is not set
CONFIG_SCSI_LOWLEVEL=y
# CONFIG_ISCSI_BOOT_SYSFS is not set
# CONFIG_SCSI_UFSHCD is not set
# CONFIG_LIBFC is not set
# CONFIG_LIBFCOE is not set
# CONFIG_SCSI_DEBUG is not set
# CONFIG_SCSI_DH is not set
# CONFIG_SCSI_OSD_INITIATOR is not set
CONFIG_HAVE_PATA_PLATFORM=y
CONFIG_ATA=y
# CONFIG_ATA_NONSTANDARD is not set
CONFIG_ATA_VERBOSE_ERROR=y
CONFIG_SATA_PMP=y

#
# Controllers with non-SFF native interface
#
CONFIG_SATA_AHCI_PLATFORM=y
CONFIG_ATA_SFF=y

#
# SFF controllers with custom DMA interface
#
CONFIG_ATA_BMDMA=y

#
# SATA SFF controllers with BMDMA
#
CONFIG_SATA_HIGHBANK=y
CONFIG_SATA_MV=y

#
# PATA SFF controllers with BMDMA
#
# CONFIG_PATA_ARASAN_CF is not set

#
# PIO-only SFF controllers
#
# CONFIG_PATA_PLATFORM is not set

#
# Generic fallback / legacy drivers
#
# CONFIG_MD is not set
# CONFIG_TARGET_CORE is not set
CONFIG_NETDEVICES=y
CONFIG_NET_CORE=y
# CONFIG_DUMMY is not set
# CONFIG_EQUALIZER is not set
CONFIG_MII=y
# CONFIG_NET_TEAM is not set
# CONFIG_MACVLAN is not set
# CONFIG_NETCONSOLE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set
# CONFIG_TUN is not set
# CONFIG_VETH is not set

#
# CAIF transport drivers
#

#
# Distributed Switch Architecture drivers
#
# CONFIG_NET_DSA_MV88E6XXX is not set
# CONFIG_NET_DSA_MV88E6060 is not set
# CONFIG_NET_DSA_MV88E6XXX_NEED_PPU is not set
# CONFIG_NET_DSA_MV88E6131 is not set
# CONFIG_NET_DSA_MV88E6123_61_65 is not set
CONFIG_ETHERNET=y
CONFIG_NET_CADENCE=y
# CONFIG_ARM_AT91_ETHER is not set
# CONFIG_MACB is not set
CONFIG_NET_VENDOR_BROADCOM=y
# CONFIG_B44 is not set
CONFIG_NET_CALXEDA_XGMAC=y
CONFIG_NET_VENDOR_CIRRUS=y
# CONFIG_CS89x0 is not set
# CONFIG_DM9000 is not set
# CONFIG_DNET is not set
CONFIG_NET_VENDOR_FARADAY=y
# CONFIG_FTMAC100 is not set
# CONFIG_FTGMAC100 is not set
CONFIG_NET_VENDOR_INTEL=y
CONFIG_NET_VENDOR_I825XX=y
CONFIG_NET_VENDOR_MARVELL=y
# CONFIG_MVMDIO is not set
# CONFIG_MVNETA is not set
CONFIG_NET_VENDOR_MICREL=y
# CONFIG_KS8842 is not set
# CONFIG_KS8851 is not set
# CONFIG_KS8851_MLL is not set
CONFIG_NET_VENDOR_MICROCHIP=y
# CONFIG_ENC28J60 is not set
CONFIG_NET_VENDOR_NATSEMI=y
CONFIG_NET_VENDOR_8390=y
# CONFIG_AX88796 is not set
# CONFIG_ETHOC is not set
CONFIG_NET_VENDOR_SEEQ=y
CONFIG_NET_VENDOR_SMSC=y
# CONFIG_SMC91X is not set
# CONFIG_SMC911X is not set
CONFIG_SMSC911X=y
# CONFIG_SMSC911X_ARCH_HOOKS is not set
CONFIG_NET_VENDOR_STMICRO=y
CONFIG_STMMAC_ETH=y
CONFIG_STMMAC_PLATFORM=y
# CONFIG_STMMAC_DA is not set
CONFIG_NET_VENDOR_WIZNET=y
# CONFIG_WIZNET_W5100 is not set
# CONFIG_WIZNET_W5300 is not set
CONFIG_PHYLIB=y

#
# MII PHY device drivers
#
# CONFIG_AT803X_PHY is not set
# CONFIG_AMD_PHY is not set
# CONFIG_MARVELL_PHY is not set
# CONFIG_DAVICOM_PHY is not set
# CONFIG_QSEMI_PHY is not set
# CONFIG_LXT_PHY is not set
# CONFIG_CICADA_PHY is not set
# CONFIG_VITESSE_PHY is not set
# CONFIG_SMSC_PHY is not set
# CONFIG_BROADCOM_PHY is not set
# CONFIG_BCM87XX_PHY is not set
# CONFIG_ICPLUS_PHY is not set
# CONFIG_REALTEK_PHY is not set
# CONFIG_NATIONAL_PHY is not set
# CONFIG_STE10XP is not set
# CONFIG_LSI_ET1011C_PHY is not set
# CONFIG_MICREL_PHY is not set
# CONFIG_FIXED_PHY is not set
# CONFIG_MDIO_BITBANG is not set
# CONFIG_MDIO_BUS_MUX_GPIO is not set
# CONFIG_MDIO_BUS_MUX_MMIOREG is not set
# CONFIG_MICREL_KS8995MA is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set

#
# USB Network Adapters
#
# CONFIG_USB_CATC is not set
# CONFIG_USB_KAWETH is not set
# CONFIG_USB_PEGASUS is not set
# CONFIG_USB_RTL8150 is not set
# CONFIG_USB_USBNET is not set
# CONFIG_USB_IPHETH is not set
CONFIG_WLAN=y
# CONFIG_USB_ZD1201 is not set
# CONFIG_HOSTAP is not set
# CONFIG_WL_TI is not set

#
# Enable WiMAX (Networking options) to see the WiMAX drivers
#
# CONFIG_WAN is not set
# CONFIG_ISDN is not set

#
# Input device support
#
CONFIG_INPUT=y
# CONFIG_INPUT_FF_MEMLESS is not set
# CONFIG_INPUT_POLLDEV is not set
# CONFIG_INPUT_SPARSEKMAP is not set
CONFIG_INPUT_MATRIXKMAP=y

#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
# CONFIG_INPUT_EVDEV is not set
# CONFIG_INPUT_EVBUG is not set

#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
# CONFIG_KEYBOARD_ADP5588 is not set
# CONFIG_KEYBOARD_ADP5589 is not set
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_KEYBOARD_QT1070 is not set
# CONFIG_KEYBOARD_QT2160 is not set
# CONFIG_KEYBOARD_LKKBD is not set
# CONFIG_KEYBOARD_GPIO is not set
# CONFIG_KEYBOARD_TCA6416 is not set
# CONFIG_KEYBOARD_TCA8418 is not set
# CONFIG_KEYBOARD_MATRIX is not set
# CONFIG_KEYBOARD_LM8333 is not set
# CONFIG_KEYBOARD_MAX7359 is not set
# CONFIG_KEYBOARD_MCS is not set
# CONFIG_KEYBOARD_MPR121 is not set
# CONFIG_KEYBOARD_NEWTON is not set
# CONFIG_KEYBOARD_OPENCORES is not set
# CONFIG_KEYBOARD_SAMSUNG is not set
# CONFIG_KEYBOARD_STOWAWAY is not set
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_OMAP4 is not set
CONFIG_KEYBOARD_SPEAR=y
# CONFIG_KEYBOARD_TWL4030 is not set
# CONFIG_KEYBOARD_XTKBD is not set
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
CONFIG_MOUSE_PS2_ALPS=y
CONFIG_MOUSE_PS2_LOGIPS2PP=y
CONFIG_MOUSE_PS2_SYNAPTICS=y
CONFIG_MOUSE_PS2_CYPRESS=y
CONFIG_MOUSE_PS2_TRACKPOINT=y
# CONFIG_MOUSE_PS2_ELANTECH is not set
# CONFIG_MOUSE_PS2_SENTELIC is not set
# CONFIG_MOUSE_PS2_TOUCHKIT is not set
# CONFIG_MOUSE_SERIAL is not set
# CONFIG_MOUSE_APPLETOUCH is not set
# CONFIG_MOUSE_BCM5974 is not set
# CONFIG_MOUSE_CYAPA is not set
# CONFIG_MOUSE_VSXXXAA is not set
# CONFIG_MOUSE_GPIO is not set
# CONFIG_MOUSE_SYNAPTICS_I2C is not set
# CONFIG_MOUSE_SYNAPTICS_USB is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TABLET is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
# CONFIG_INPUT_MISC is not set

#
# Hardware I/O ports
#
CONFIG_SERIO=y
CONFIG_SERIO_SERPORT=y
CONFIG_SERIO_AMBAKMI=y
CONFIG_SERIO_LIBPS2=y
# CONFIG_SERIO_RAW is not set
# CONFIG_SERIO_ALTERA_PS2 is not set
# CONFIG_SERIO_PS2MULT is not set
# CONFIG_SERIO_ARC_PS2 is not set
# CONFIG_SERIO_APBPS2 is not set
# CONFIG_GAMEPORT is not set

#
# Character devices
#
CONFIG_TTY=y
CONFIG_VT=y
CONFIG_CONSOLE_TRANSLATIONS=y
CONFIG_VT_CONSOLE=y
CONFIG_VT_CONSOLE_SLEEP=y
CONFIG_HW_CONSOLE=y
# CONFIG_VT_HW_CONSOLE_BINDING is not set
CONFIG_UNIX98_PTYS=y
# CONFIG_DEVPTS_MULTIPLE_INSTANCES is not set
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256
# CONFIG_SERIAL_NONSTANDARD is not set
# CONFIG_N_GSM is not set
# CONFIG_TRACE_SINK is not set
CONFIG_DEVKMEM=y

#
# Serial drivers
#
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_DEPRECATED_OPTIONS=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_8250_DMA=y
CONFIG_SERIAL_8250_NR_UARTS=4
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
# CONFIG_SERIAL_8250_EXTENDED is not set
CONFIG_SERIAL_8250_DW=y
# CONFIG_SERIAL_8250_EM is not set

#
# Non-8250 serial port support
#
# CONFIG_SERIAL_AMBA_PL010 is not set
CONFIG_SERIAL_AMBA_PL011=y
CONFIG_SERIAL_AMBA_PL011_CONSOLE=y
CONFIG_SERIAL_SIRFSOC=y
CONFIG_SERIAL_SIRFSOC_CONSOLE=y
# CONFIG_SERIAL_MAX3100 is not set
# CONFIG_SERIAL_MAX310X is not set
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
CONFIG_SERIAL_VT8500=y
CONFIG_SERIAL_VT8500_CONSOLE=y
CONFIG_SERIAL_OF_PLATFORM=y
CONFIG_SERIAL_OMAP=y
CONFIG_SERIAL_OMAP_CONSOLE=y
# CONFIG_SERIAL_SCCNXP is not set
# CONFIG_SERIAL_TIMBERDALE is not set
# CONFIG_SERIAL_ALTERA_JTAGUART is not set
# CONFIG_SERIAL_ALTERA_UART is not set
# CONFIG_SERIAL_IFX6X60 is not set
# CONFIG_SERIAL_XILINX_PS_UART is not set
# CONFIG_SERIAL_ARC is not set
# CONFIG_HVC_DCC is not set
CONFIG_IPMI_HANDLER=y
# CONFIG_IPMI_PANIC_EVENT is not set
# CONFIG_IPMI_DEVICE_INTERFACE is not set
CONFIG_IPMI_SI=y
# CONFIG_IPMI_WATCHDOG is not set
# CONFIG_IPMI_POWEROFF is not set
CONFIG_HW_RANDOM=y
# CONFIG_HW_RANDOM_TIMERIOMEM is not set
# CONFIG_HW_RANDOM_ATMEL is not set
# CONFIG_HW_RANDOM_EXYNOS is not set
# CONFIG_R3964 is not set
# CONFIG_RAW_DRIVER is not set
# CONFIG_TCG_TPM is not set
CONFIG_I2C=y
CONFIG_I2C_BOARDINFO=y
CONFIG_I2C_COMPAT=y
# CONFIG_I2C_CHARDEV is not set
# CONFIG_I2C_MUX is not set
CONFIG_I2C_HELPER_AUTO=y

#
# I2C Hardware Bus support
#

#
# I2C system bus drivers (mostly embedded / system-on-chip)
#
# CONFIG_I2C_CBUS_GPIO is not set
CONFIG_I2C_DESIGNWARE_CORE=y
CONFIG_I2C_DESIGNWARE_PLATFORM=y
# CONFIG_I2C_GPIO is not set
# CONFIG_I2C_MV64XXX is not set
# CONFIG_I2C_NOMADIK is not set
# CONFIG_I2C_OCORES is not set
CONFIG_I2C_OMAP=y
# CONFIG_I2C_PCA_PLATFORM is not set
# CONFIG_I2C_PXA_PCI is not set
# CONFIG_I2C_SIMTEC is not set
CONFIG_I2C_SIRF=y
# CONFIG_I2C_VERSATILE is not set
# CONFIG_I2C_XILINX is not set

#
# External I2C/SMBus adapter drivers
#
# CONFIG_I2C_DIOLAN_U2C is not set
# CONFIG_I2C_PARPORT_LIGHT is not set
# CONFIG_I2C_TAOS_EVM is not set
# CONFIG_I2C_TINY_USB is not set

#
# Other I2C/SMBus bus drivers
#
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
CONFIG_SPI=y
CONFIG_SPI_MASTER=y

#
# SPI Master Controller Drivers
#
# CONFIG_SPI_ALTERA is not set
CONFIG_SPI_BITBANG=y
# CONFIG_SPI_GPIO is not set
# CONFIG_SPI_FSL_SPI is not set
# CONFIG_SPI_OC_TINY is not set
# CONFIG_SPI_OMAP24XX is not set
# CONFIG_SPI_ORION is not set
CONFIG_SPI_PL022=y
# CONFIG_SPI_PXA2XX_PCI is not set
# CONFIG_SPI_SC18IS602 is not set
CONFIG_SPI_SIRF=y
# CONFIG_SPI_XCOMM is not set
# CONFIG_SPI_XILINX is not set
# CONFIG_SPI_DESIGNWARE is not set

#
# SPI Protocol Masters
#
# CONFIG_SPI_SPIDEV is not set
# CONFIG_SPI_TLE62X0 is not set

#
# Qualcomm MSM SSBI bus support
#
# CONFIG_SSBI is not set
# CONFIG_HSI is not set

#
# PPS support
#
CONFIG_PPS=y
# CONFIG_PPS_DEBUG is not set
# CONFIG_NTP_PPS is not set

#
# PPS clients support
#
# CONFIG_PPS_CLIENT_KTIMER is not set
# CONFIG_PPS_CLIENT_LDISC is not set
# CONFIG_PPS_CLIENT_GPIO is not set

#
# PPS generators support
#

#
# PTP clock support
#
CONFIG_PTP_1588_CLOCK=y

#
# Enable PHYLIB and NETWORK_PHY_TIMESTAMPING to see the additional clocks.
#
# CONFIG_PTP_1588_CLOCK_PCH is not set
CONFIG_PINCTRL=y

#
# Pin controllers
#
CONFIG_PINMUX=y
CONFIG_PINCONF=y
CONFIG_GENERIC_PINCONF=y
# CONFIG_PINCTRL_SINGLE is not set
CONFIG_PINCTRL_SIRF=y
CONFIG_PINCTRL_SUNXI=y
# CONFIG_PINCTRL_EXYNOS is not set
# CONFIG_PINCTRL_EXYNOS5440 is not set
CONFIG_PINCTRL_MVEBU=y
CONFIG_PINCTRL_ARMADA_370=y
CONFIG_PINCTRL_ARMADA_XP=y
CONFIG_PINCTRL_SPEAR=y
CONFIG_PINCTRL_SPEAR1310=y
CONFIG_PINCTRL_SPEAR1340=y
CONFIG_PINCTRL_SPEAR_PLGPIO=y
# CONFIG_PINCTRL_WM8850 is not set
CONFIG_ARCH_HAVE_CUSTOM_GPIO_H=y
CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y
CONFIG_ARCH_REQUIRE_GPIOLIB=y
CONFIG_GPIO_DEVRES=y
CONFIG_GPIOLIB=y
CONFIG_OF_GPIO=y
# CONFIG_GPIO_SYSFS is not set
CONFIG_GPIO_GENERIC=y

#
# Memory mapped GPIO drivers:
#
# CONFIG_GPIO_GENERIC_PLATFORM is not set
# CONFIG_GPIO_EM is not set
CONFIG_GPIO_MVEBU=y
CONFIG_GPIO_PL061=y
# CONFIG_GPIO_RCAR is not set
CONFIG_GPIO_SPEAR_SPICS=y
# CONFIG_GPIO_TS5500 is not set

#
# I2C GPIO expanders:
#
# CONFIG_GPIO_MAX7300 is not set
# CONFIG_GPIO_MAX732X is not set
# CONFIG_GPIO_PCF857X is not set
# CONFIG_GPIO_SX150X is not set
# CONFIG_GPIO_TWL4030 is not set
# CONFIG_GPIO_ADP5588 is not set
# CONFIG_GPIO_ADNP is not set

#
# PCI GPIO expanders:
#

#
# SPI GPIO expanders:
#
# CONFIG_GPIO_MAX7301 is not set
# CONFIG_GPIO_MCP23S08 is not set
# CONFIG_GPIO_MC33880 is not set
# CONFIG_GPIO_74X164 is not set

#
# AC97 GPIO expanders:
#

#
# MODULbus GPIO expanders:
#

#
# USB GPIO expanders:
#
# CONFIG_W1 is not set
CONFIG_POWER_SUPPLY=y
# CONFIG_POWER_SUPPLY_DEBUG is not set
# CONFIG_PDA_POWER is not set
# CONFIG_TEST_POWER is not set
# CONFIG_BATTERY_DS2780 is not set
# CONFIG_BATTERY_DS2781 is not set
# CONFIG_BATTERY_DS2782 is not set
# CONFIG_BATTERY_SBS is not set
# CONFIG_BATTERY_BQ27x00 is not set
# CONFIG_BATTERY_MAX17040 is not set
# CONFIG_BATTERY_MAX17042 is not set
# CONFIG_CHARGER_MAX8903 is not set
# CONFIG_CHARGER_TWL4030 is not set
# CONFIG_CHARGER_LP8727 is not set
# CONFIG_CHARGER_GPIO is not set
# CONFIG_CHARGER_MANAGER is not set
# CONFIG_CHARGER_BQ2415X is not set
# CONFIG_CHARGER_SMB347 is not set
# CONFIG_BATTERY_GOLDFISH is not set
CONFIG_POWER_RESET=y
# CONFIG_POWER_RESET_GPIO is not set
# CONFIG_POWER_RESET_QNAP is not set
# CONFIG_POWER_RESET_RESTART is not set
CONFIG_POWER_RESET_VEXPRESS=y
# CONFIG_POWER_AVS is not set
CONFIG_HWMON=y
# CONFIG_HWMON_VID is not set
# CONFIG_HWMON_DEBUG_CHIP is not set

#
# Native drivers
#
# CONFIG_SENSORS_AD7314 is not set
# CONFIG_SENSORS_AD7414 is not set
# CONFIG_SENSORS_AD7418 is not set
# CONFIG_SENSORS_ADCXX is not set
# CONFIG_SENSORS_ADM1021 is not set
# CONFIG_SENSORS_ADM1025 is not set
# CONFIG_SENSORS_ADM1026 is not set
# CONFIG_SENSORS_ADM1029 is not set
# CONFIG_SENSORS_ADM1031 is not set
# CONFIG_SENSORS_ADM9240 is not set
# CONFIG_SENSORS_ADT7310 is not set
# CONFIG_SENSORS_ADT7410 is not set
# CONFIG_SENSORS_ADT7411 is not set
# CONFIG_SENSORS_ADT7462 is not set
# CONFIG_SENSORS_ADT7470 is not set
# CONFIG_SENSORS_ADT7475 is not set
# CONFIG_SENSORS_ASC7621 is not set
# CONFIG_SENSORS_ATXP1 is not set
# CONFIG_SENSORS_DS620 is not set
# CONFIG_SENSORS_DS1621 is not set
# CONFIG_SENSORS_F71805F is not set
# CONFIG_SENSORS_F71882FG is not set
# CONFIG_SENSORS_F75375S is not set
# CONFIG_SENSORS_G760A is not set
# CONFIG_SENSORS_GL518SM is not set
# CONFIG_SENSORS_GL520SM is not set
# CONFIG_SENSORS_GPIO_FAN is not set
# CONFIG_SENSORS_HIH6130 is not set
# CONFIG_SENSORS_IBMAEM is not set
# CONFIG_SENSORS_IBMPEX is not set
# CONFIG_SENSORS_IT87 is not set
# CONFIG_SENSORS_JC42 is not set
# CONFIG_SENSORS_LINEAGE is not set
# CONFIG_SENSORS_LM63 is not set
# CONFIG_SENSORS_LM70 is not set
# CONFIG_SENSORS_LM73 is not set
# CONFIG_SENSORS_LM75 is not set
# CONFIG_SENSORS_LM77 is not set
# CONFIG_SENSORS_LM78 is not set
# CONFIG_SENSORS_LM80 is not set
# CONFIG_SENSORS_LM83 is not set
# CONFIG_SENSORS_LM85 is not set
# CONFIG_SENSORS_LM87 is not set
# CONFIG_SENSORS_LM90 is not set
# CONFIG_SENSORS_LM92 is not set
# CONFIG_SENSORS_LM93 is not set
# CONFIG_SENSORS_LTC4151 is not set
# CONFIG_SENSORS_LTC4215 is not set
# CONFIG_SENSORS_LTC4245 is not set
# CONFIG_SENSORS_LTC4261 is not set
# CONFIG_SENSORS_LM95234 is not set
# CONFIG_SENSORS_LM95241 is not set
# CONFIG_SENSORS_LM95245 is not set
# CONFIG_SENSORS_MAX1111 is not set
# CONFIG_SENSORS_MAX16065 is not set
# CONFIG_SENSORS_MAX1619 is not set
# CONFIG_SENSORS_MAX1668 is not set
# CONFIG_SENSORS_MAX197 is not set
# CONFIG_SENSORS_MAX6639 is not set
# CONFIG_SENSORS_MAX6642 is not set
# CONFIG_SENSORS_MAX6650 is not set
# CONFIG_SENSORS_MAX6697 is not set
# CONFIG_SENSORS_MCP3021 is not set
# CONFIG_SENSORS_NCT6775 is not set
# CONFIG_SENSORS_PC87360 is not set
# CONFIG_SENSORS_PC87427 is not set
# CONFIG_SENSORS_PCF8591 is not set
# CONFIG_PMBUS is not set
# CONFIG_SENSORS_SHT15 is not set
# CONFIG_SENSORS_SHT21 is not set
# CONFIG_SENSORS_SMM665 is not set
# CONFIG_SENSORS_DME1737 is not set
# CONFIG_SENSORS_EMC1403 is not set
# CONFIG_SENSORS_EMC2103 is not set
# CONFIG_SENSORS_EMC6W201 is not set
# CONFIG_SENSORS_SMSC47M1 is not set
# CONFIG_SENSORS_SMSC47M192 is not set
# CONFIG_SENSORS_SMSC47B397 is not set
# CONFIG_SENSORS_SCH56XX_COMMON is not set
# CONFIG_SENSORS_ADS1015 is not set
# CONFIG_SENSORS_ADS7828 is not set
# CONFIG_SENSORS_ADS7871 is not set
# CONFIG_SENSORS_AMC6821 is not set
# CONFIG_SENSORS_INA209 is not set
# CONFIG_SENSORS_INA2XX is not set
# CONFIG_SENSORS_THMC50 is not set
# CONFIG_SENSORS_TMP102 is not set
# CONFIG_SENSORS_TMP401 is not set
# CONFIG_SENSORS_TMP421 is not set
# CONFIG_SENSORS_VEXPRESS is not set
# CONFIG_SENSORS_VT1211 is not set
# CONFIG_SENSORS_W83781D is not set
# CONFIG_SENSORS_W83791D is not set
# CONFIG_SENSORS_W83792D is not set
# CONFIG_SENSORS_W83793 is not set
# CONFIG_SENSORS_W83795 is not set
# CONFIG_SENSORS_W83L785TS is not set
# CONFIG_SENSORS_W83L786NG is not set
# CONFIG_SENSORS_W83627HF is not set
# CONFIG_SENSORS_W83627EHF is not set
# CONFIG_THERMAL is not set
# CONFIG_WATCHDOG is not set
CONFIG_SSB_POSSIBLE=y

#
# Sonics Silicon Backplane
#
# CONFIG_SSB is not set
CONFIG_BCMA_POSSIBLE=y

#
# Broadcom specific AMBA
#
# CONFIG_BCMA is not set

#
# Multifunction device drivers
#
# CONFIG_MFD_CORE is not set
# CONFIG_MFD_AS3711 is not set
# CONFIG_PMIC_ADP5520 is not set
# CONFIG_MFD_AAT2870_CORE is not set
# CONFIG_MFD_CROS_EC is not set
# CONFIG_MFD_ASIC3 is not set
# CONFIG_PMIC_DA903X is not set
# CONFIG_MFD_DA9052_SPI is not set
# CONFIG_MFD_DA9052_I2C is not set
# CONFIG_MFD_DA9055 is not set
# CONFIG_MFD_MC13XXX_SPI is not set
# CONFIG_MFD_MC13XXX_I2C is not set
# CONFIG_HTC_EGPIO is not set
# CONFIG_HTC_PASIC3 is not set
# CONFIG_HTC_I2CPLD is not set
# CONFIG_MFD_88PM800 is not set
# CONFIG_MFD_88PM805 is not set
# CONFIG_MFD_88PM860X is not set
# CONFIG_MFD_MAX77686 is not set
# CONFIG_MFD_MAX77693 is not set
# CONFIG_MFD_MAX8907 is not set
# CONFIG_MFD_MAX8925 is not set
# CONFIG_MFD_MAX8997 is not set
# CONFIG_MFD_MAX8998 is not set
# CONFIG_EZX_PCAP is not set
# CONFIG_MFD_VIPERBOARD is not set
# CONFIG_MFD_RETU is not set
# CONFIG_MFD_PCF50633 is not set
# CONFIG_MFD_RC5T583 is not set
# CONFIG_MFD_SEC_CORE is not set
# CONFIG_MFD_SM501 is not set
# CONFIG_MFD_SMSC is not set
# CONFIG_ABX500_CORE is not set
# CONFIG_MFD_STMPE is not set
# CONFIG_MFD_SYSCON is not set
# CONFIG_MFD_TI_AM335X_TSCADC is not set
# CONFIG_MFD_LP8788 is not set
# CONFIG_MFD_PALMAS is not set
# CONFIG_TPS6105X is not set
# CONFIG_TPS65010 is not set
# CONFIG_TPS6507X is not set
# CONFIG_MFD_TPS65090 is not set
# CONFIG_MFD_TPS65217 is not set
# CONFIG_MFD_TPS6586X is not set
# CONFIG_MFD_TPS65910 is not set
# CONFIG_MFD_TPS65912 is not set
# CONFIG_MFD_TPS65912_I2C is not set
# CONFIG_MFD_TPS65912_SPI is not set
# CONFIG_MFD_TPS80031 is not set
CONFIG_TWL4030_CORE=y
# CONFIG_TWL4030_MADC is not set
CONFIG_TWL4030_POWER=y
# CONFIG_MFD_TWL4030_AUDIO is not set
# CONFIG_TWL6040_CORE is not set
# CONFIG_MFD_WL1273_CORE is not set
# CONFIG_MFD_SI476X_CORE is not set
# CONFIG_MFD_LM3533 is not set
# CONFIG_MFD_TC3589X is not set
# CONFIG_MFD_TMIO is not set
# CONFIG_MFD_T7L66XB is not set
# CONFIG_MFD_TC6387XB is not set
# CONFIG_MFD_TC6393XB is not set
# CONFIG_MFD_ARIZONA_I2C is not set
# CONFIG_MFD_ARIZONA_SPI is not set
# CONFIG_MFD_WM8400 is not set
# CONFIG_MFD_WM831X_I2C is not set
# CONFIG_MFD_WM831X_SPI is not set
# CONFIG_MFD_WM8350_I2C is not set
# CONFIG_MFD_WM8994 is not set
CONFIG_VEXPRESS_CONFIG=y
CONFIG_REGULATOR=y
# CONFIG_REGULATOR_DEBUG is not set
# CONFIG_REGULATOR_DUMMY is not set
CONFIG_REGULATOR_FIXED_VOLTAGE=y
# CONFIG_REGULATOR_VIRTUAL_CONSUMER is not set
# CONFIG_REGULATOR_USERSPACE_CONSUMER is not set
# CONFIG_REGULATOR_GPIO is not set
# CONFIG_REGULATOR_AD5398 is not set
# CONFIG_REGULATOR_FAN53555 is not set
# CONFIG_REGULATOR_ISL6271A is not set
# CONFIG_REGULATOR_MAX1586 is not set
# CONFIG_REGULATOR_MAX8649 is not set
# CONFIG_REGULATOR_MAX8660 is not set
# CONFIG_REGULATOR_MAX8952 is not set
# CONFIG_REGULATOR_MAX8973 is not set
# CONFIG_REGULATOR_LP3971 is not set
# CONFIG_REGULATOR_LP3972 is not set
# CONFIG_REGULATOR_LP872X is not set
# CONFIG_REGULATOR_LP8755 is not set
# CONFIG_REGULATOR_TPS51632 is not set
# CONFIG_REGULATOR_TPS62360 is not set
# CONFIG_REGULATOR_TPS65023 is not set
# CONFIG_REGULATOR_TPS6507X is not set
# CONFIG_REGULATOR_TPS6524X is not set
# CONFIG_REGULATOR_TWL4030 is not set
# CONFIG_REGULATOR_VEXPRESS is not set
# CONFIG_MEDIA_SUPPORT is not set

#
# Graphics support
#
# CONFIG_DRM is not set
# CONFIG_VGASTATE is not set
# CONFIG_VIDEO_OUTPUT_CONTROL is not set
CONFIG_VIDEOMODE_HELPERS=y
CONFIG_FB=y
# CONFIG_FIRMWARE_EDID is not set
# CONFIG_FB_DDC is not set
# CONFIG_FB_BOOT_VESA_SUPPORT is not set
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
# CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set
CONFIG_FB_SYS_FILLRECT=y
CONFIG_FB_SYS_COPYAREA=y
CONFIG_FB_SYS_IMAGEBLIT=y
# CONFIG_FB_FOREIGN_ENDIAN is not set
# CONFIG_FB_SYS_FOPS is not set
# CONFIG_FB_SVGALIB is not set
# CONFIG_FB_MACMODES is not set
# CONFIG_FB_BACKLIGHT is not set
CONFIG_FB_MODE_HELPERS=y
# CONFIG_FB_TILEBLITTING is not set

#
# Frame buffer hardware drivers
#
CONFIG_FB_ARMCLCD=y
# CONFIG_FB_S1D13XXX is not set
# CONFIG_FB_VT8500 is not set
CONFIG_FB_WM8505=y
# CONFIG_FB_WMT_GE_ROPS is not set
# CONFIG_FB_SMSCUFX is not set
# CONFIG_FB_UDL is not set
# CONFIG_FB_GOLDFISH is not set
# CONFIG_FB_VIRTUAL is not set
# CONFIG_FB_METRONOME is not set
# CONFIG_FB_BROADSHEET is not set
# CONFIG_FB_AUO_K190X is not set
# CONFIG_FB_SIMPLE is not set
# CONFIG_OMAP2_DSS is not set
# CONFIG_EXYNOS_VIDEO is not set
# CONFIG_BACKLIGHT_LCD_SUPPORT is not set

#
# Console display driver support
#
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
# CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY is not set
# CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set
# CONFIG_FONTS is not set
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y
# CONFIG_LOGO is not set
# CONFIG_FB_SSD1307 is not set
# CONFIG_SOUND is not set

#
# HID support
#
CONFIG_HID=y
# CONFIG_HID_BATTERY_STRENGTH is not set
# CONFIG_HIDRAW is not set
# CONFIG_UHID is not set
CONFIG_HID_GENERIC=y

#
# Special HID drivers
#
CONFIG_HID_A4TECH=y
# CONFIG_HID_ACRUX is not set
CONFIG_HID_APPLE=y
# CONFIG_HID_AUREAL is not set
CONFIG_HID_BELKIN=y
CONFIG_HID_CHERRY=y
CONFIG_HID_CHICONY=y
CONFIG_HID_CYPRESS=y
# CONFIG_HID_DRAGONRISE is not set
# CONFIG_HID_EMS_FF is not set
# CONFIG_HID_ELECOM is not set
CONFIG_HID_EZKEY=y
# CONFIG_HID_HOLTEK is not set
# CONFIG_HID_KEYTOUCH is not set
# CONFIG_HID_KYE is not set
# CONFIG_HID_UCLOGIC is not set
# CONFIG_HID_WALTOP is not set
# CONFIG_HID_GYRATION is not set
# CONFIG_HID_ICADE is not set
# CONFIG_HID_TWINHAN is not set
CONFIG_HID_KENSINGTON=y
# CONFIG_HID_LCPOWER is not set
# CONFIG_HID_LENOVO_TPKBD is not set
CONFIG_HID_LOGITECH=y
# CONFIG_HID_LOGITECH_DJ is not set
# CONFIG_LOGITECH_FF is not set
# CONFIG_LOGIRUMBLEPAD2_FF is not set
# CONFIG_LOGIG940_FF is not set
# CONFIG_LOGIWHEELS_FF is not set
# CONFIG_HID_MAGICMOUSE is not set
CONFIG_HID_MICROSOFT=y
CONFIG_HID_MONTEREY=y
# CONFIG_HID_MULTITOUCH is not set
# CONFIG_HID_NTRIG is not set
# CONFIG_HID_ORTEK is not set
# CONFIG_HID_PANTHERLORD is not set
# CONFIG_HID_PETALYNX is not set
# CONFIG_HID_PICOLCD is not set
# CONFIG_HID_PRIMAX is not set
# CONFIG_HID_PS3REMOTE is not set
# CONFIG_HID_ROCCAT is not set
# CONFIG_HID_SAITEK is not set
# CONFIG_HID_SAMSUNG is not set
# CONFIG_HID_SONY is not set
# CONFIG_HID_SPEEDLINK is not set
# CONFIG_HID_STEELSERIES is not set
# CONFIG_HID_SUNPLUS is not set
# CONFIG_HID_GREENASIA is not set
# CONFIG_HID_SMARTJOYPLUS is not set
# CONFIG_HID_TIVO is not set
# CONFIG_HID_TOPSEED is not set
# CONFIG_HID_THRUSTMASTER is not set
# CONFIG_HID_ZEROPLUS is not set
# CONFIG_HID_ZYDACRON is not set
# CONFIG_HID_SENSOR_HUB is not set

#
# USB HID support
#
CONFIG_USB_HID=y
# CONFIG_HID_PID is not set
# CONFIG_USB_HIDDEV is not set

#
# I2C HID support
#
# CONFIG_I2C_HID is not set
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB_ARCH_HAS_EHCI=y
# CONFIG_USB_ARCH_HAS_XHCI is not set
CONFIG_USB_SUPPORT=y
CONFIG_USB_COMMON=y
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB=y
# CONFIG_USB_DEBUG is not set
# CONFIG_USB_ANNOUNCE_NEW_DEVICES is not set

#
# Miscellaneous USB options
#
CONFIG_USB_DEFAULT_PERSIST=y
# CONFIG_USB_DYNAMIC_MINORS is not set
# CONFIG_USB_MON is not set
# CONFIG_USB_WUSB_CBAF is not set

#
# USB Host Controller Drivers
#
# CONFIG_USB_C67X00_HCD is not set
# CONFIG_USB_EHCI_HCD is not set
# CONFIG_USB_OXU210HP_HCD is not set
# CONFIG_USB_ISP116X_HCD is not set
CONFIG_USB_ISP1760_HCD=y
# CONFIG_USB_ISP1362_HCD is not set
# CONFIG_USB_OHCI_HCD is not set
# CONFIG_USB_UHCI_HCD is not set
# CONFIG_USB_SL811_HCD is not set
# CONFIG_USB_R8A66597_HCD is not set

#
# USB Device Class drivers
#
# CONFIG_USB_ACM is not set
# CONFIG_USB_PRINTER is not set
# CONFIG_USB_WDM is not set
# CONFIG_USB_TMC is not set

#
# NOTE: USB_STORAGE depends on SCSI but BLK_DEV_SD may
#

#
# also be needed; see USB_STORAGE Help for more info
#
CONFIG_USB_STORAGE=y
# CONFIG_USB_STORAGE_DEBUG is not set
# CONFIG_USB_STORAGE_REALTEK is not set
# CONFIG_USB_STORAGE_DATAFAB is not set
# CONFIG_USB_STORAGE_FREECOM is not set
# CONFIG_USB_STORAGE_ISD200 is not set
# CONFIG_USB_STORAGE_USBAT is not set
# CONFIG_USB_STORAGE_SDDR09 is not set
# CONFIG_USB_STORAGE_SDDR55 is not set
# CONFIG_USB_STORAGE_JUMPSHOT is not set
# CONFIG_USB_STORAGE_ALAUDA is not set
# CONFIG_USB_STORAGE_ONETOUCH is not set
# CONFIG_USB_STORAGE_KARMA is not set
# CONFIG_USB_STORAGE_CYPRESS_ATACB is not set
# CONFIG_USB_STORAGE_ENE_UB6250 is not set

#
# USB Imaging devices
#
# CONFIG_USB_MDC800 is not set
# CONFIG_USB_MICROTEK is not set
# CONFIG_USB_DWC3 is not set
# CONFIG_USB_CHIPIDEA is not set

#
# USB port drivers
#
# CONFIG_USB_SERIAL is not set

#
# USB Miscellaneous drivers
#
# CONFIG_USB_EMI62 is not set
# CONFIG_USB_EMI26 is not set
# CONFIG_USB_ADUTUX is not set
# CONFIG_USB_SEVSEG is not set
# CONFIG_USB_RIO500 is not set
# CONFIG_USB_LEGOTOWER is not set
# CONFIG_USB_LCD is not set
# CONFIG_USB_LED is not set
# CONFIG_USB_CYPRESS_CY7C63 is not set
# CONFIG_USB_CYTHERM is not set
# CONFIG_USB_IDMOUSE is not set
# CONFIG_USB_FTDI_ELAN is not set
# CONFIG_USB_APPLEDISPLAY is not set
# CONFIG_USB_LD is not set
# CONFIG_USB_TRANCEVIBRATOR is not set
# CONFIG_USB_IOWARRIOR is not set
# CONFIG_USB_TEST is not set
# CONFIG_USB_ISIGHTFW is not set
# CONFIG_USB_YUREX is not set
# CONFIG_USB_EZUSB_FX2 is not set
# CONFIG_USB_HSIC_USB3503 is not set
# CONFIG_USB_PHY is not set
# CONFIG_USB_GADGET is not set
CONFIG_MMC=y
# CONFIG_MMC_DEBUG is not set
# CONFIG_MMC_UNSAFE_RESUME is not set
# CONFIG_MMC_CLKGATE is not set

#
# MMC/SD/SDIO Card Drivers
#
CONFIG_MMC_BLOCK=y
CONFIG_MMC_BLOCK_MINORS=8
CONFIG_MMC_BLOCK_BOUNCE=y
# CONFIG_SDIO_UART is not set
# CONFIG_MMC_TEST is not set

#
# MMC/SD/SDIO Host Controller Drivers
#
CONFIG_MMC_ARMMMCI=y
CONFIG_MMC_SDHCI=y
CONFIG_MMC_SDHCI_PLTFM=y
# CONFIG_MMC_SDHCI_SIRF is not set
# CONFIG_MMC_SDHCI_PXAV3 is not set
# CONFIG_MMC_SDHCI_PXAV2 is not set
CONFIG_MMC_SDHCI_SPEAR=y
# CONFIG_MMC_OMAP is not set
# CONFIG_MMC_MVSDIO is not set
# CONFIG_MMC_DW is not set
# CONFIG_MMC_VUB300 is not set
# CONFIG_MMC_USHC is not set
CONFIG_MMC_WMT=y
# CONFIG_MEMSTICK is not set
# CONFIG_NEW_LEDS is not set
# CONFIG_ACCESSIBILITY is not set
CONFIG_EDAC=y
CONFIG_EDAC_LEGACY_SYSFS=y
# CONFIG_EDAC_DEBUG is not set
CONFIG_EDAC_MM_EDAC=y
CONFIG_EDAC_HIGHBANK_MC=y
CONFIG_EDAC_HIGHBANK_L2=y
CONFIG_RTC_LIB=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_HCTOSYS=y
CONFIG_RTC_SYSTOHC=y
CONFIG_RTC_HCTOSYS_DEVICE="rtc0"
# CONFIG_RTC_DEBUG is not set

#
# RTC interfaces
#
CONFIG_RTC_INTF_SYSFS=y
CONFIG_RTC_INTF_PROC=y
CONFIG_RTC_INTF_DEV=y
# CONFIG_RTC_INTF_DEV_UIE_EMUL is not set
# CONFIG_RTC_DRV_TEST is not set

#
# I2C RTC drivers
#
# CONFIG_RTC_DRV_DS1307 is not set
# CONFIG_RTC_DRV_DS1374 is not set
# CONFIG_RTC_DRV_DS1672 is not set
# CONFIG_RTC_DRV_DS3232 is not set
# CONFIG_RTC_DRV_MAX6900 is not set
# CONFIG_RTC_DRV_RS5C372 is not set
# CONFIG_RTC_DRV_ISL1208 is not set
# CONFIG_RTC_DRV_ISL12022 is not set
# CONFIG_RTC_DRV_X1205 is not set
# CONFIG_RTC_DRV_PCF8523 is not set
# CONFIG_RTC_DRV_PCF8563 is not set
# CONFIG_RTC_DRV_PCF8583 is not set
# CONFIG_RTC_DRV_M41T80 is not set
# CONFIG_RTC_DRV_BQ32K is not set
# CONFIG_RTC_DRV_TWL4030 is not set
# CONFIG_RTC_DRV_S35390A is not set
# CONFIG_RTC_DRV_FM3130 is not set
# CONFIG_RTC_DRV_RX8581 is not set
# CONFIG_RTC_DRV_RX8025 is not set
# CONFIG_RTC_DRV_EM3027 is not set
# CONFIG_RTC_DRV_RV3029C2 is not set

#
# SPI RTC drivers
#
# CONFIG_RTC_DRV_M41T93 is not set
# CONFIG_RTC_DRV_M41T94 is not set
# CONFIG_RTC_DRV_DS1305 is not set
# CONFIG_RTC_DRV_DS1390 is not set
# CONFIG_RTC_DRV_MAX6902 is not set
# CONFIG_RTC_DRV_R9701 is not set
# CONFIG_RTC_DRV_RS5C348 is not set
# CONFIG_RTC_DRV_DS3234 is not set
# CONFIG_RTC_DRV_PCF2123 is not set
# CONFIG_RTC_DRV_RX4581 is not set

#
# Platform RTC drivers
#
# CONFIG_RTC_DRV_CMOS is not set
# CONFIG_RTC_DRV_DS1286 is not set
# CONFIG_RTC_DRV_DS1511 is not set
# CONFIG_RTC_DRV_DS1553 is not set
# CONFIG_RTC_DRV_DS1742 is not set
# CONFIG_RTC_DRV_STK17TA8 is not set
# CONFIG_RTC_DRV_M48T86 is not set
# CONFIG_RTC_DRV_M48T35 is not set
# CONFIG_RTC_DRV_M48T59 is not set
# CONFIG_RTC_DRV_MSM6242 is not set
# CONFIG_RTC_DRV_BQ4802 is not set
# CONFIG_RTC_DRV_RP5C01 is not set
# CONFIG_RTC_DRV_V3020 is not set
# CONFIG_RTC_DRV_DS2404 is not set
CONFIG_RTC_DRV_SPEAR=y

#
# on-CPU RTC drivers
#
# CONFIG_RTC_DRV_PL030 is not set
CONFIG_RTC_DRV_PL031=y
CONFIG_RTC_DRV_VT8500=y
# CONFIG_RTC_DRV_MV is not set
# CONFIG_RTC_DRV_SNVS is not set

#
# HID Sensor RTC drivers
#
# CONFIG_RTC_DRV_HID_SENSOR_TIME is not set
CONFIG_DMADEVICES=y
# CONFIG_DMADEVICES_DEBUG is not set

#
# DMA Devices
#
# CONFIG_AMBA_PL08X is not set
CONFIG_DW_DMAC=y
# CONFIG_DW_DMAC_BIG_ENDIAN_IO is not set
# CONFIG_MV_XOR is not set
# CONFIG_TIMB_DMA is not set
CONFIG_SIRF_DMA=y
CONFIG_PL330_DMA=y
# CONFIG_DMA_OMAP is not set
CONFIG_DMA_ENGINE=y
CONFIG_DMA_OF=y

#
# DMA Clients
#
# CONFIG_NET_DMA is not set
# CONFIG_ASYNC_TX_DMA is not set
# CONFIG_DMATEST is not set
# CONFIG_AUXDISPLAY is not set
# CONFIG_UIO is not set
# CONFIG_VIRT_DRIVERS is not set

#
# Virtio drivers
#
# CONFIG_VIRTIO_MMIO is not set

#
# Microsoft Hyper-V guest support
#
# CONFIG_STAGING is not set
CONFIG_CLKDEV_LOOKUP=y
CONFIG_HAVE_CLK_PREPARE=y
CONFIG_COMMON_CLK=y

#
# Common Clock Framework
#
# CONFIG_COMMON_CLK_DEBUG is not set
CONFIG_COMMON_CLK_VERSATILE=y
# CONFIG_COMMON_CLK_SI5351 is not set
# CONFIG_COMMON_CLK_AXI_CLKGEN is not set
CONFIG_MVEBU_CLK_CORE=y
CONFIG_MVEBU_CLK_CPU=y
CONFIG_MVEBU_CLK_GATING=y

#
# Hardware Spinlock drivers
#
CONFIG_CLKSRC_OF=y
CONFIG_CLKSRC_MMIO=y
CONFIG_DW_APB_TIMER=y
CONFIG_DW_APB_TIMER_OF=y
CONFIG_ARMADA_370_XP_TIMER=y
CONFIG_SUN4I_TIMER=y
CONFIG_VT8500_TIMER=y
CONFIG_CADENCE_TTC_TIMER=y
CONFIG_MAILBOX=y
CONFIG_PL320_MBOX=y
# CONFIG_OMAP2PLUS_MBOX is not set
CONFIG_MBOX_KFIFO_SIZE=256
CONFIG_MBOX_DATA_SIZE=4
CONFIG_IOMMU_SUPPORT=y
CONFIG_OF_IOMMU=y
# CONFIG_OMAP_IOMMU is not set

#
# Remoteproc drivers
#
# CONFIG_STE_MODEM_RPROC is not set

#
# Rpmsg drivers
#
# CONFIG_PM_DEVFREQ is not set
# CONFIG_EXTCON is not set
# CONFIG_MEMORY is not set
# CONFIG_IIO is not set
CONFIG_PWM=y
# CONFIG_PWM_SPEAR is not set
# CONFIG_PWM_TWL is not set
# CONFIG_PWM_TWL_LED is not set
CONFIG_PWM_VT8500=y
CONFIG_IRQCHIP=y
CONFIG_ARM_GIC=y
# CONFIG_IPACK_BUS is not set
# CONFIG_RESET_CONTROLLER is not set

#
# File systems
#
CONFIG_DCACHE_WORD_ACCESS=y
# CONFIG_EXT2_FS is not set
# CONFIG_EXT3_FS is not set
# CONFIG_EXT4_FS is not set
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
# CONFIG_XFS_FS is not set
# CONFIG_GFS2_FS is not set
# CONFIG_BTRFS_FS is not set
# CONFIG_NILFS2_FS is not set
# CONFIG_FS_POSIX_ACL is not set
CONFIG_FILE_LOCKING=y
CONFIG_FSNOTIFY=y
CONFIG_DNOTIFY=y
CONFIG_INOTIFY_USER=y
# CONFIG_FANOTIFY is not set
# CONFIG_QUOTA is not set
# CONFIG_QUOTACTL is not set
# CONFIG_AUTOFS4_FS is not set
# CONFIG_FUSE_FS is not set

#
# Caches
#
# CONFIG_FSCACHE is not set

#
# CD-ROM/DVD Filesystems
#
# CONFIG_ISO9660_FS is not set
# CONFIG_UDF_FS is not set

#
# DOS/FAT/NT Filesystems
#
# CONFIG_MSDOS_FS is not set
# CONFIG_VFAT_FS is not set
# CONFIG_NTFS_FS is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_SYSCTL=y
CONFIG_PROC_PAGE_MONITOR=y
CONFIG_SYSFS=y
# CONFIG_TMPFS is not set
# CONFIG_HUGETLB_PAGE is not set
# CONFIG_CONFIGFS_FS is not set
CONFIG_MISC_FILESYSTEMS=y
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_LOGFS is not set
# CONFIG_CRAMFS is not set
# CONFIG_SQUASHFS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_OMFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_QNX6FS_FS is not set
# CONFIG_ROMFS_FS is not set
# CONFIG_PSTORE is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set
# CONFIG_F2FS_FS is not set
CONFIG_NETWORK_FILESYSTEMS=y
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
# CONFIG_NLS_CODEPAGE_437 is not set
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
# CONFIG_NLS_CODEPAGE_850 is not set
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
# CONFIG_NLS_ASCII is not set
# CONFIG_NLS_ISO8859_1 is not set
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
# CONFIG_NLS_ISO8859_15 is not set
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
# CONFIG_NLS_MAC_ROMAN is not set
# CONFIG_NLS_MAC_CELTIC is not set
# CONFIG_NLS_MAC_CENTEURO is not set
# CONFIG_NLS_MAC_CROATIAN is not set
# CONFIG_NLS_MAC_CYRILLIC is not set
# CONFIG_NLS_MAC_GAELIC is not set
# CONFIG_NLS_MAC_GREEK is not set
# CONFIG_NLS_MAC_ICELAND is not set
# CONFIG_NLS_MAC_INUIT is not set
# CONFIG_NLS_MAC_ROMANIAN is not set
# CONFIG_NLS_MAC_TURKISH is not set
# CONFIG_NLS_UTF8 is not set

#
# Kernel hacking
#
# CONFIG_PRINTK_TIME is not set
CONFIG_DEFAULT_MESSAGE_LOGLEVEL=4
CONFIG_ENABLE_WARN_DEPRECATED=y
CONFIG_ENABLE_MUST_CHECK=y
CONFIG_FRAME_WARN=1024
# CONFIG_MAGIC_SYSRQ is not set
# CONFIG_STRIP_ASM_SYMS is not set
# CONFIG_UNUSED_SYMBOLS is not set
# CONFIG_DEBUG_FS is not set
# CONFIG_HEADERS_CHECK is not set
# CONFIG_DEBUG_SECTION_MISMATCH is not set
# CONFIG_DEBUG_KERNEL is not set
# CONFIG_PANIC_ON_OOPS is not set
CONFIG_PANIC_ON_OOPS_VALUE=0
# CONFIG_SLUB_DEBUG_ON is not set
# CONFIG_SLUB_STATS is not set
CONFIG_HAVE_DEBUG_KMEMLEAK=y
CONFIG_DEBUG_BUGVERBOSE=y
CONFIG_DEBUG_MEMORY_INIT=y

#
# RCU Debugging
#
# CONFIG_SPARSE_RCU_POINTER is not set
CONFIG_RCU_CPU_STALL_TIMEOUT=21
CONFIG_HAVE_FUNCTION_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y
CONFIG_HAVE_DYNAMIC_FTRACE=y
CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y
CONFIG_HAVE_SYSCALL_TRACEPOINTS=y
CONFIG_HAVE_C_RECORDMCOUNT=y
CONFIG_TRACING_SUPPORT=y
# CONFIG_FTRACE is not set
# CONFIG_DMA_API_DEBUG is not set
# CONFIG_ATOMIC64_SELFTEST is not set
# CONFIG_SAMPLES is not set
CONFIG_HAVE_ARCH_KGDB=y
# CONFIG_TEST_STRING_HELPERS is not set
# CONFIG_TEST_KSTRTOX is not set
# CONFIG_STRICT_DEVMEM is not set
CONFIG_ARM_UNWIND=y
# CONFIG_DEBUG_USER is not set
CONFIG_DEBUG_LL_INCLUDE="mach/debug-macro.S"
CONFIG_UNCOMPRESS_INCLUDE="debug/uncompress.h"
# CONFIG_OC_ETM is not set
# CONFIG_PID_IN_CONTEXTIDR is not set

#
# Security options
#
# CONFIG_KEYS is not set
# CONFIG_SECURITY_DMESG_RESTRICT is not set
# CONFIG_SECURITY is not set
# CONFIG_SECURITYFS is not set
CONFIG_DEFAULT_SECURITY_DAC=y
CONFIG_DEFAULT_SECURITY=""
# CONFIG_CRYPTO is not set
# CONFIG_BINARY_PRINTF is not set

#
# Library routines
#
CONFIG_BITREVERSE=y
CONFIG_GENERIC_STRNCPY_FROM_USER=y
CONFIG_GENERIC_STRNLEN_USER=y
CONFIG_GENERIC_PCI_IOMAP=y
CONFIG_GENERIC_IO=y
# CONFIG_CRC_CCITT is not set
# CONFIG_CRC16 is not set
# CONFIG_CRC_T10DIF is not set
# CONFIG_CRC_ITU_T is not set
CONFIG_CRC32=y
# CONFIG_CRC32_SELFTEST is not set
CONFIG_CRC32_SLICEBY8=y
# CONFIG_CRC32_SLICEBY4 is not set
# CONFIG_CRC32_SARWATE is not set
# CONFIG_CRC32_BIT is not set
# CONFIG_CRC7 is not set
# CONFIG_LIBCRC32C is not set
# CONFIG_CRC8 is not set
CONFIG_LZO_COMPRESS=y
CONFIG_LZO_DECOMPRESS=y
# CONFIG_XZ_DEC is not set
# CONFIG_XZ_DEC_BCJ is not set
CONFIG_HAS_IOMEM=y
CONFIG_HAS_DMA=y
CONFIG_CPU_RMAP=y
CONFIG_DQL=y
CONFIG_NLATTR=y
CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE=y
# CONFIG_AVERAGE is not set
# CONFIG_CORDIC is not set
# CONFIG_DDR is not set
# CONFIG_VIRTUALIZATION is not set

From ezequiel.garcia at free-electrons.com  Fri Apr 19 16:02:09 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Fri, 19 Apr 2013 17:02:09 -0300
Subject: [PATCH v7 1/5] drivers: memory: Introduce Marvell EBU Device Bus
 driver
In-Reply-To: <20130419181633.GA31753@kroah.com>
References: <1365620644-15790-1-git-send-email-ezequiel.garcia@free-electrons.com>
 <1365620644-15790-2-git-send-email-ezequiel.garcia@free-electrons.com>
 <20130410191641.GG28693@titan.lakedaemon.net>
 <20130410194337.GA5681@kroah.com> <20130419181058.GA2243@localhost>
 <20130419181633.GA31753@kroah.com>
Message-ID: <20130419200208.GA12621@localhost>

Greg, 

On Fri, Apr 19, 2013 at 11:16:33AM -0700, Greg KH wrote:
> > On Wed, Apr 10, 2013 at 12:43:37PM -0700, Greg KH wrote:
> > > > On Wed, Apr 10, 2013 at 04:04:00PM -0300, Ezequiel Garcia wrote:
[...]
> > 
> > Is it possible that you take this patch instead, so it can make it in v3.10?
> 
> Sure, resend it to me today please.
> 

Forget about it. This Device Bus driver depends on the recent Mbus
driver, which was supposed to get pulled in the same branch.

I don't see an easy way to merge both of these, considering we're
so close to the merge window.

Thanks anyway and sorry for the noise.
-- 
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com


From arnd at arndb.de  Fri Apr 19 16:11:13 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 19 Apr 2013 22:11:13 +0200
Subject: linux-next ARM multi-platform randconfig errors
In-Reply-To: <20130419194323.GP10155@atomide.com>
References: <5170B4C6.1030300@gmail.com> <517173C0.6010902@ti.com>
 <20130419194323.GP10155@atomide.com>
Message-ID: <201304192211.13356.arnd@arndb.de>

On Friday 19 April 2013, Tony Lindgren wrote:
> This might happen when no SoC selected. There was a patch posted
> by Arnd to always select 2420 if nothing else is selected as it's the
> most minimal one. But Russell did not like that, so probably the way
> to fix that would be to have bool OMAP_SOC and if not selected, don't
> even try to build anything. I'll take a look at that.

My patch was actually just necessary to avoid building a kernel with
no platforms selected at all, but we now have a patch that makes that
a working option.

I think all the bugs that Rob reported can be fixed individually.

Note that the "dss-common.c" part there might be a Red Herring, the symbols
are likely to be used from somewhere else than that file.

	Arnd


From sergei.shtylyov at cogentembedded.com  Fri Apr 19 16:23:52 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Sat, 20 Apr 2013 00:23:52 +0400
Subject: [PATCH v3 4/4] ARM: shmobile: BOCK-W: enable USB in defconfig
In-Reply-To: <20130419021414.GB25718@verge.net.au>
References: <201304170135.10251.sergei.shtylyov@cogentembedded.com>
 <20130418140552.GO20929@verge.net.au> <5170789D.5020108@cogentembedded.com>
 <20130419021414.GB25718@verge.net.au>
Message-ID: <5171A7D8.2010000@cogentembedded.com>

On 04/19/2013 06:14 AM, Simon Horman wrote:
> On Fri, Apr 19, 2013 at 02:50:05AM +0400, Sergei Shtylyov wrote:
>> Hello.
>>
>> On 04/18/2013 06:05 PM, Simon Horman wrote:
>>
>>>> Enable USB platform EHCI/OHCI and common PHY drivers in 'bockw_defconfig'.
>>>> Enable USB storage driver and SCSI disk driver that it needs as well...
>>>>
>>>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
>>> I realise that this is not going to be useful until the rest
>>> of the series has been merged. But regardless I have pre-emptively
>>> queued it up for v3.11 in the defconfig-bockw branch.
>>>> ---
>>>>   arch/arm/configs/bockw_defconfig |   11 ++++++++++-
>>>>   1 file changed, 10 insertions(+), 1 deletion(-)
>>>>
>>>> Index: renesas/arch/arm/configs/bockw_defconfig
>>>> ===================================================================
>>>> --- renesas.orig/arch/arm/configs/bockw_defconfig
>>>> +++ renesas/arch/arm/configs/bockw_defconfig
>>>> @@ -48,6 +48,8 @@ CONFIG_DEVTMPFS_MOUNT=y
>>>>   # CONFIG_STANDALONE is not set
>>>>   # CONFIG_PREVENT_FIRMWARE_BUILD is not set
>>>>   # CONFIG_FW_LOADER is not set
>>>> +CONFIG_SCSI=y
>>>> +CONFIG_BLK_DEV_SD=y
>>>>   CONFIG_NETDEVICES=y
>>>>   # CONFIG_NET_CADENCE is not set
>>>>   # CONFIG_NET_VENDOR_BROADCOM is not set
>>>> @@ -71,7 +73,14 @@ CONFIG_SERIAL_SH_SCI_NR_UARTS=6
>>>>   CONFIG_SERIAL_SH_SCI_CONSOLE=y
>>>>   # CONFIG_HW_RANDOM is not set
>>>>   # CONFIG_HWMON is not set
>>>> -# CONFIG_USB_SUPPORT is not set
>>>> +CONFIG_USB=y
>>>> +CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
>>>> +CONFIG_USB_EHCI_HCD=y
>>>> +CONFIG_USB_OHCI_HCD=y
>>>> +CONFIG_USB_OHCI_HCD_PLATFORM=y
>>>> +CONFIG_USB_EHCI_HCD_PLATFORM=y
>>>> +CONFIG_USB_STORAGE=y
>>>> +CONFIG_USB_RCAR_PHY=y
>>>>
>>     Unfortunately, you've made a mistake in this last line of the patch:
>> you've truncated it to just "CONFIG_USB_RCAR". :-(
>>     Will you correct it?
> Sorry about that, I will fix it.

     Sorry to say, but you fixed it the wrong way; now it's:

+CONFIG_USB_RCAR=y

instead of:

+CONFIG_USB_RCAR_PHY=y

WBR, Sergei



From olof at lixom.net  Fri Apr 19 16:28:24 2013
From: olof at lixom.net (Olof Johansson)
Date: Fri, 19 Apr 2013 13:28:24 -0700
Subject: [GIT PULL] sunXi dt additions, take 4
In-Reply-To: <516C243E.2050407@free-electrons.com>
References: <516C243E.2050407@free-electrons.com>
Message-ID: <20130419202824.GA31842@quad.lixom.net>

On Mon, Apr 15, 2013 at 06:01:02PM +0200, Maxime Ripard wrote:
> Hi Arnd, Olof,
> 
> This pull request for 3.10 is just one small patch changing slightly
> merging the fixed rate oscillator with the oscillator gates.
> 
> This one will be the last pull request for 3.10-rc1.
> 
> Thanks,
> Maxime
> 
> The following changes since commit 0b19b7c2c6e169efccb4b1632fe628969d001618:
> 
>   ARM: sunxi: dt: Update watchdog compatible string (2013-04-08 21:56:34 +0200)
> 
> are available in the git repository at:
> 
>   git://github.com/mripard/linux.git tags/sunxi-dt-for-3.10-4

Hi,

I pulled this yesterday but seems to have missed replying to the email.

It's in next/dt and for-next now.

Thanks!

-Olof


From sylvester.nawrocki at gmail.com  Fri Apr 19 16:37:36 2013
From: sylvester.nawrocki at gmail.com (Sylwester Nawrocki)
Date: Fri, 19 Apr 2013 22:37:36 +0200
Subject: [PATCH] cpufreq: exynos: allow disabling cpufreq drivers
In-Reply-To: <201304192059.38606.arnd@arndb.de>
References: <201304191554.29679.arnd@arndb.de> <51717623.2060709@samsung.com>
 <201304192059.38606.arnd@arndb.de>
Message-ID: <5171AB10.5070702@gmail.com>

On 04/19/2013 08:59 PM, Arnd Bergmann wrote:
> Maybe you just didn't have CPUFREQ enabled? I also didn't notice this
> bug at first because it is turned off in the defconfigs.

I certainly had it enabled. Since I remember I needed to turn it off
temporarily after someone has introduced an incorrect change to the clock
tree definition and cpufreq was unexpectedly switching parents of one of
the root clocks at run time, which was causing malfunction of the camera
image processing chain.

Anyway this wasn't a clean mainline kernel, as there have been recently lot
of stuff pending upstream needed to have complete system with dt support.
I assume after 3.10 release the situation is going to be much better.

> It could also be working by chance on EXYNOS4, since the register
> definitions were not actually removed from the regs-clk.h header
> for those.

That's most likely what happened.


Thanks,
Sylwester


From tony at atomide.com  Fri Apr 19 16:40:29 2013
From: tony at atomide.com (Tony Lindgren)
Date: Fri, 19 Apr 2013 13:40:29 -0700
Subject: linux-next ARM multi-platform randconfig errors
In-Reply-To: <201304192211.13356.arnd@arndb.de>
References: <5170B4C6.1030300@gmail.com> <517173C0.6010902@ti.com>
 <20130419194323.GP10155@atomide.com>
 <201304192211.13356.arnd@arndb.de>
Message-ID: <20130419204028.GU10155@atomide.com>

* Arnd Bergmann <arnd at arndb.de> [130419 13:18]:
> On Friday 19 April 2013, Tony Lindgren wrote:
> > This might happen when no SoC selected. There was a patch posted
> > by Arnd to always select 2420 if nothing else is selected as it's the
> > most minimal one. But Russell did not like that, so probably the way
> > to fix that would be to have bool OMAP_SOC and if not selected, don't
> > even try to build anything. I'll take a look at that.
> 
> My patch was actually just necessary to avoid building a kernel with
> no platforms selected at all, but we now have a patch that makes that
> a working option.

Yes that's cool.
 
> I think all the bugs that Rob reported can be fixed individually.
> 
> Note that the "dss-common.c" part there might be a Red Herring, the symbols
> are likely to be used from somewhere else than that file.

Yeah. Here's an initial patch of what I had in mind, seems to
do the trick. Will spend a little more time looking at it.

Regards,

Tony


--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -1,6 +1,9 @@
 config ARCH_OMAP
 	bool
 
+config SOC_OMAP
+	bool
+
 config ARCH_OMAP2PLUS
 	bool "TI OMAP2/3/4/5 SoCs with device tree support" if (ARCH_MULTI_V6 || ARCH_MULTI_V7)
 	select ARCH_HAS_CPUFREQ
@@ -97,6 +100,7 @@ config ARCH_OMAP4
 	select PL310_ERRATA_727915
 	select PM_OPP if PM
 	select PM_RUNTIME if CPU_IDLE
+	select SOC_OMAP
 	select USB_ARCH_HAS_EHCI if USB_SUPPORT
 	select COMMON_CLK
 	select ARM_ERRATA_754322
@@ -110,6 +114,7 @@ config SOC_OMAP5
 	select HAVE_SMP
 	select COMMON_CLK
 	select HAVE_ARM_ARCH_TIMER
+	select SOC_OMAP
 
 comment "OMAP Core Type"
 	depends on ARCH_OMAP2
@@ -120,22 +125,26 @@ config SOC_OMAP2420
 	default y
 	select OMAP_DM_TIMER
 	select SOC_HAS_OMAP2_SDRC
+	select SOC_OMAP
 
 config SOC_OMAP2430
 	bool "OMAP2430 support"
 	depends on ARCH_OMAP2
 	default y
 	select SOC_HAS_OMAP2_SDRC
+	select SOC_OMAP
 
 config SOC_OMAP3430
 	bool "OMAP3430 support"
 	depends on ARCH_OMAP3
 	default y
 	select SOC_HAS_OMAP2_SDRC
+	select SOC_OMAP
 
 config SOC_TI81XX
 	bool "TI81XX support"
 	depends on ARCH_OMAP3
+	select SOC_OMAP
 	default y
 
 config SOC_AM33XX
@@ -145,6 +154,7 @@ config SOC_AM33XX
 	select CPU_V7
 	select MULTI_IRQ_HANDLER
 	select COMMON_CLK
+	select SOC_OMAP
 
 config OMAP_PACKAGE_ZAF
        bool
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -5,8 +5,12 @@
 ccflags-$(CONFIG_ARCH_MULTIPLATFORM) := -I$(srctree)/$(src)/include \
 	-I$(srctree)/arch/arm/plat-omap/include
 
+obj-y := id.o control.o
+
+ifeq ($(CONFIG_SOC_OMAP),y)
+
 # Common support
-obj-y := id.o io.o control.o mux.o devices.o fb.o serial.o gpmc.o timer.o pm.o \
+obj-y := io.o mux.o devices.o fb.o serial.o gpmc.o timer.o pm.o \
 	 common.o gpio.o dma.o wd_timer.o display.o i2c.o hdq1w.o omap_hwmod.o \
 	 omap_device.o sram.o
 
@@ -293,3 +297,5 @@ emac-$(CONFIG_TI_DAVINCI_EMAC)		:= am35xx-emac.o
 obj-y					+= $(emac-m) $(emac-y)
 
 obj-y					+= common-board-devices.o twl-common.o dss-common.o
+
+endif
--- a/arch/arm/plat-omap/include/plat/i2c.h
+++ b/arch/arm/plat-omap/include/plat/i2c.h
@@ -25,8 +25,17 @@
 struct i2c_board_info;
 struct omap_i2c_bus_platform_data;
 
+#if defined(CONFIG_ARCH_OMAP1) || defined(SOC_OMAP)
 int omap_i2c_add_bus(struct omap_i2c_bus_platform_data *i2c_pdata,
 			int bus_id);
+#else
+static inline int
+omap_i2c_add_bus(struct omap_i2c_bus_platform_data *i2c_pdata,
+			int bus_id)
+{
+	return -ENODEV;
+}
+#endif
 
 #if defined(CONFIG_I2C_OMAP) || defined(CONFIG_I2C_OMAP_MODULE)
 extern int omap_register_i2c_bus(int bus_id, u32 clkrate,


From tony at atomide.com  Fri Apr 19 16:42:15 2013
From: tony at atomide.com (Tony Lindgren)
Date: Fri, 19 Apr 2013 13:42:15 -0700
Subject: linux-next ARM multi-platform randconfig errors
In-Reply-To: <5171A095.8010104@ti.com>
References: <5170B4C6.1030300@gmail.com> <20130419161257.GI10155@atomide.com>
 <517173C0.6010902@ti.com> <5171A095.8010104@ti.com>
Message-ID: <20130419204215.GV10155@atomide.com>

* Jon Hunter <jon-hunter at ti.com> [130419 12:57]:
> 
> Looks like if support for TI OMAP2/3/4/5 SOCs is enabled, but all
> of OMAP2/3/4/5/AM33XX devices are then disabled you will get the
> above errors.
> 
> I think that the error is misleading, because AFAICT it has nothing
> to do with dss-common.c. The errors are because files like
> clockdomain.c and powerdomain.c are not being compiled but
> omap_hwmod.c is. 

Yeah just posted an initial patch for that as a reply to
Arnd's comment, maybe give that a try to see if it still
has randconfig sized holes?

Regards,

Tony


From arnd at arndb.de  Fri Apr 19 16:43:30 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 19 Apr 2013 22:43:30 +0200
Subject: [PATCH] cpufreq: exynos: allow disabling cpufreq drivers
In-Reply-To: <5171AB10.5070702@gmail.com>
References: <201304191554.29679.arnd@arndb.de>
 <201304192059.38606.arnd@arndb.de> <5171AB10.5070702@gmail.com>
Message-ID: <201304192243.30430.arnd@arndb.de>

On Friday 19 April 2013, Sylwester Nawrocki wrote:
> > It could also be working by chance on EXYNOS4, since the register
> > definitions were not actually removed from the regs-clk.h header
> > for those.
> 
> That's most likely what happened.

Ok. I think I see the bigger picture now. The EXYNOS5 cpufreq driver was
actually just merged now, so I assume that by the time Thomas did the clock
changes, the register definitions for EXYNOS5 were actually unused and he
subsequently removed them from the kernel.

Since the driver now depends on them, I think the only way forward for 3.10
is to revert the change that removed the definitions and put them back in
place.

We really should use the clock API from all the exynos cpufreq drivers, but it's
too late for that change now in 3.10 and we will have to do it for 3.11 then.

This are not looking so good for exynos multiplatform support in 3.10 now, but
if we get it in, that will mean we have to disable cpufreq when building
multiplatform, but it can remain for the classic single-platform configurations.

	Arnd


From arnd at arndb.de  Fri Apr 19 16:58:36 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 19 Apr 2013 22:58:36 +0200
Subject: linux-next ARM multi-platform randconfig errors
In-Reply-To: <20130419204028.GU10155@atomide.com>
References: <5170B4C6.1030300@gmail.com> <201304192211.13356.arnd@arndb.de>
 <20130419204028.GU10155@atomide.com>
Message-ID: <201304192258.36276.arnd@arndb.de>

On Friday 19 April 2013, Tony Lindgren wrote:
> Yeah. Here's an initial patch of what I had in mind, seems to
> do the trick. Will spend a little more time looking at it.

I suspect it won't be enough, as the same bugs you see with all of
them disable will likely happen also when you disable most of them.
If I'm right, the only solution is to look at each symbol individually
to find out exactly what code provides that symbol and ensure it
does not get used otherwise.

	Arnd


From tony at atomide.com  Fri Apr 19 17:02:14 2013
From: tony at atomide.com (Tony Lindgren)
Date: Fri, 19 Apr 2013 14:02:14 -0700
Subject: linux-next ARM multi-platform randconfig errors
In-Reply-To: <20130419204028.GU10155@atomide.com>
References: <5170B4C6.1030300@gmail.com> <517173C0.6010902@ti.com>
 <20130419194323.GP10155@atomide.com>
 <201304192211.13356.arnd@arndb.de>
 <20130419204028.GU10155@atomide.com>
Message-ID: <20130419210213.GW10155@atomide.com>

* Tony Lindgren <tony at atomide.com> [130419 13:47]:
> * Arnd Bergmann <arnd at arndb.de> [130419 13:18]:
>  
> > I think all the bugs that Rob reported can be fixed individually.
> > 
> > Note that the "dss-common.c" part there might be a Red Herring, the symbols
> > are likely to be used from somewhere else than that file.
> 
> Yeah. Here's an initial patch of what I had in mind, seems to
> do the trick. Will spend a little more time looking at it.
...

> --- a/arch/arm/plat-omap/include/plat/i2c.h
> +++ b/arch/arm/plat-omap/include/plat/i2c.h
> @@ -25,8 +25,17 @@
>  struct i2c_board_info;
>  struct omap_i2c_bus_platform_data;
>  
> +#if defined(CONFIG_ARCH_OMAP1) || defined(SOC_OMAP)

This should have defined(CONFIG_SOC_OMAP) instead. Will repost
after some more randconfig builds.

>  int omap_i2c_add_bus(struct omap_i2c_bus_platform_data *i2c_pdata,
>  			int bus_id);
> +#else
> +static inline int
> +omap_i2c_add_bus(struct omap_i2c_bus_platform_data *i2c_pdata,
> +			int bus_id)
> +{
> +	return -ENODEV;
> +}
> +#endif
>  
>  #if defined(CONFIG_I2C_OMAP) || defined(CONFIG_I2C_OMAP_MODULE)
>  extern int omap_register_i2c_bus(int bus_id, u32 clkrate,

Regards,

Tony


From tony at atomide.com  Fri Apr 19 17:09:29 2013
From: tony at atomide.com (Tony Lindgren)
Date: Fri, 19 Apr 2013 14:09:29 -0700
Subject: linux-next ARM multi-platform randconfig errors
In-Reply-To: <20130419204028.GU10155@atomide.com>
References: <5170B4C6.1030300@gmail.com> <517173C0.6010902@ti.com>
 <20130419194323.GP10155@atomide.com>
 <201304192211.13356.arnd@arndb.de>
 <20130419204028.GU10155@atomide.com>
Message-ID: <20130419210929.GX10155@atomide.com>

* Tony Lindgren <tony at atomide.com> [130419 13:47]:
> --- a/arch/arm/mach-omap2/Makefile
> +++ b/arch/arm/mach-omap2/Makefile
> @@ -5,8 +5,12 @@
>  ccflags-$(CONFIG_ARCH_MULTIPLATFORM) := -I$(srctree)/$(src)/include \
>  	-I$(srctree)/arch/arm/plat-omap/include
>  
> +obj-y := id.o control.o
> +
> +ifeq ($(CONFIG_SOC_OMAP),y)
> +
>  # Common support
> -obj-y := id.o io.o control.o mux.o devices.o fb.o serial.o gpmc.o timer.o pm.o \
> +obj-y := io.o mux.o devices.o fb.o serial.o gpmc.o timer.o pm.o \
>  	 common.o gpio.o dma.o wd_timer.o display.o i2c.o hdq1w.o omap_hwmod.o \
>  	 omap_device.o sram.o
>  

And the second obj-y needs to have += instead of := to build real configs :)

Tony


From arnd at arndb.de  Fri Apr 19 17:10:25 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 19 Apr 2013 23:10:25 +0200
Subject: [PATCH] ARM: exynos: restore mach/regs-clock.h for exynos5
In-Reply-To: <5171AB10.5070702@gmail.com>
References: <201304191554.29679.arnd@arndb.de>
 <201304192059.38606.arnd@arndb.de> <5171AB10.5070702@gmail.com>
Message-ID: <201304192310.26041.arnd@arndb.de>

Commit 6e6aac75 "ARM: EXYNOS: Migrate clock support to common
clock framework" from Thomas Abraham removed the Exynos5 specific
register definitions as they were unused at the time, but the
cpufreq driver actually still uses them.

Cc: Sylwester Nawrocki <s.nawrocki at samsung.com>
Cc: Tomasz Figa <t.figa at samsung.com>
Cc: Thomas Abraham <thomas.abraham at linaro.org>
Cc: Kukjin Kim <kgene.kim at samsung.com>
Signed-off-by: Arnd Bergmann <arnd at arndb.de>
8<----

I'd apply this one on next/drivers to fix the build error, unless
someone has concerns.

diff --git a/arch/arm/mach-exynos/include/mach/regs-clock.h b/arch/arm/mach-exynos/include/mach/regs-clock.h
index 20fbbdd..d36ad76 100644
--- a/arch/arm/mach-exynos/include/mach/regs-clock.h
+++ b/arch/arm/mach-exynos/include/mach/regs-clock.h
@@ -256,6 +256,113 @@
 #define EXYNOS4_CLKDIV_CAM1_JPEG_SHIFT		(0)
 #define EXYNOS4_CLKDIV_CAM1_JPEG_MASK		(0xf << EXYNOS4_CLKDIV_CAM1_JPEG_SHIFT)
 
+/* For EXYNOS5250 */
+
+#define EXYNOS5_APLL_LOCK			EXYNOS_CLKREG(0x00000)
+#define EXYNOS5_APLL_CON0			EXYNOS_CLKREG(0x00100)
+#define EXYNOS5_CLKSRC_CPU			EXYNOS_CLKREG(0x00200)
+#define EXYNOS5_CLKMUX_STATCPU			EXYNOS_CLKREG(0x00400)
+#define EXYNOS5_CLKDIV_CPU0			EXYNOS_CLKREG(0x00500)
+#define EXYNOS5_CLKDIV_CPU1			EXYNOS_CLKREG(0x00504)
+#define EXYNOS5_CLKDIV_STATCPU0			EXYNOS_CLKREG(0x00600)
+#define EXYNOS5_CLKDIV_STATCPU1			EXYNOS_CLKREG(0x00604)
+
+#define EXYNOS5_PWR_CTRL1			EXYNOS_CLKREG(0x01020)
+#define EXYNOS5_PWR_CTRL2			EXYNOS_CLKREG(0x01024)
+
+#define EXYNOS5_MPLL_CON0			EXYNOS_CLKREG(0x04100)
+#define EXYNOS5_CLKSRC_CORE1			EXYNOS_CLKREG(0x04204)
+
+#define EXYNOS5_CLKGATE_IP_CORE			EXYNOS_CLKREG(0x04900)
+
+#define EXYNOS5_CLKDIV_ACP			EXYNOS_CLKREG(0x08500)
+
+#define EXYNOS5_EPLL_CON0			EXYNOS_CLKREG(0x10130)
+#define EXYNOS5_EPLL_CON1			EXYNOS_CLKREG(0x10134)
+#define EXYNOS5_EPLL_CON2			EXYNOS_CLKREG(0x10138)
+#define EXYNOS5_VPLL_CON0			EXYNOS_CLKREG(0x10140)
+#define EXYNOS5_VPLL_CON1			EXYNOS_CLKREG(0x10144)
+#define EXYNOS5_VPLL_CON2			EXYNOS_CLKREG(0x10148)
+#define EXYNOS5_CPLL_CON0			EXYNOS_CLKREG(0x10120)
+
+#define EXYNOS5_CLKSRC_TOP0			EXYNOS_CLKREG(0x10210)
+#define EXYNOS5_CLKSRC_TOP1			EXYNOS_CLKREG(0x10214)
+#define EXYNOS5_CLKSRC_TOP2			EXYNOS_CLKREG(0x10218)
+#define EXYNOS5_CLKSRC_TOP3			EXYNOS_CLKREG(0x1021C)
+#define EXYNOS5_CLKSRC_GSCL			EXYNOS_CLKREG(0x10220)
+#define EXYNOS5_CLKSRC_DISP1_0			EXYNOS_CLKREG(0x1022C)
+#define EXYNOS5_CLKSRC_MAUDIO			EXYNOS_CLKREG(0x10240)
+#define EXYNOS5_CLKSRC_FSYS			EXYNOS_CLKREG(0x10244)
+#define EXYNOS5_CLKSRC_PERIC0			EXYNOS_CLKREG(0x10250)
+#define EXYNOS5_CLKSRC_PERIC1			EXYNOS_CLKREG(0x10254)
+#define EXYNOS5_SCLK_SRC_ISP			EXYNOS_CLKREG(0x10270)
+
+#define EXYNOS5_CLKSRC_MASK_TOP			EXYNOS_CLKREG(0x10310)
+#define EXYNOS5_CLKSRC_MASK_GSCL		EXYNOS_CLKREG(0x10320)
+#define EXYNOS5_CLKSRC_MASK_DISP1_0		EXYNOS_CLKREG(0x1032C)
+#define EXYNOS5_CLKSRC_MASK_MAUDIO		EXYNOS_CLKREG(0x10334)
+#define EXYNOS5_CLKSRC_MASK_FSYS		EXYNOS_CLKREG(0x10340)
+#define EXYNOS5_CLKSRC_MASK_PERIC0		EXYNOS_CLKREG(0x10350)
+#define EXYNOS5_CLKSRC_MASK_PERIC1		EXYNOS_CLKREG(0x10354)
+
+#define EXYNOS5_CLKDIV_TOP0			EXYNOS_CLKREG(0x10510)
+#define EXYNOS5_CLKDIV_TOP1			EXYNOS_CLKREG(0x10514)
+#define EXYNOS5_CLKDIV_GSCL			EXYNOS_CLKREG(0x10520)
+#define EXYNOS5_CLKDIV_DISP1_0			EXYNOS_CLKREG(0x1052C)
+#define EXYNOS5_CLKDIV_GEN			EXYNOS_CLKREG(0x1053C)
+#define EXYNOS5_CLKDIV_MAUDIO			EXYNOS_CLKREG(0x10544)
+#define EXYNOS5_CLKDIV_FSYS0			EXYNOS_CLKREG(0x10548)
+#define EXYNOS5_CLKDIV_FSYS1			EXYNOS_CLKREG(0x1054C)
+#define EXYNOS5_CLKDIV_FSYS2			EXYNOS_CLKREG(0x10550)
+#define EXYNOS5_CLKDIV_FSYS3			EXYNOS_CLKREG(0x10554)
+#define EXYNOS5_CLKDIV_PERIC0			EXYNOS_CLKREG(0x10558)
+#define EXYNOS5_CLKDIV_PERIC1			EXYNOS_CLKREG(0x1055C)
+#define EXYNOS5_CLKDIV_PERIC2			EXYNOS_CLKREG(0x10560)
+#define EXYNOS5_CLKDIV_PERIC3			EXYNOS_CLKREG(0x10564)
+#define EXYNOS5_CLKDIV_PERIC4			EXYNOS_CLKREG(0x10568)
+#define EXYNOS5_CLKDIV_PERIC5			EXYNOS_CLKREG(0x1056C)
+#define EXYNOS5_SCLK_DIV_ISP			EXYNOS_CLKREG(0x10580)
+
+#define EXYNOS5_CLKGATE_IP_ACP			EXYNOS_CLKREG(0x08800)
+#define EXYNOS5_CLKGATE_IP_ISP0			EXYNOS_CLKREG(0x0C800)
+#define EXYNOS5_CLKGATE_IP_ISP1			EXYNOS_CLKREG(0x0C804)
+#define EXYNOS5_CLKGATE_IP_GSCL			EXYNOS_CLKREG(0x10920)
+#define EXYNOS5_CLKGATE_IP_DISP1		EXYNOS_CLKREG(0x10928)
+#define EXYNOS5_CLKGATE_IP_MFC			EXYNOS_CLKREG(0x1092C)
+#define EXYNOS5_CLKGATE_IP_G3D			EXYNOS_CLKREG(0x10930)
+#define EXYNOS5_CLKGATE_IP_GEN			EXYNOS_CLKREG(0x10934)
+#define EXYNOS5_CLKGATE_IP_FSYS			EXYNOS_CLKREG(0x10944)
+#define EXYNOS5_CLKGATE_IP_GPS			EXYNOS_CLKREG(0x1094C)
+#define EXYNOS5_CLKGATE_IP_PERIC		EXYNOS_CLKREG(0x10950)
+#define EXYNOS5_CLKGATE_IP_PERIS		EXYNOS_CLKREG(0x10960)
+#define EXYNOS5_CLKGATE_BLOCK			EXYNOS_CLKREG(0x10980)
+
+#define EXYNOS5_BPLL_CON0			EXYNOS_CLKREG(0x20110)
+#define EXYNOS5_CLKSRC_CDREX			EXYNOS_CLKREG(0x20200)
+#define EXYNOS5_CLKDIV_CDREX			EXYNOS_CLKREG(0x20500)
+
+#define EXYNOS5_PLL_DIV2_SEL			EXYNOS_CLKREG(0x20A24)
+
+#define EXYNOS5_EPLL_LOCK			EXYNOS_CLKREG(0x10030)
+
+#define EXYNOS5_EPLLCON0_LOCKED_SHIFT		(29)
+
+#define PWR_CTRL1_CORE2_DOWN_RATIO		(7 << 28)
+#define PWR_CTRL1_CORE1_DOWN_RATIO		(7 << 16)
+#define PWR_CTRL1_DIV2_DOWN_EN			(1 << 9)
+#define PWR_CTRL1_DIV1_DOWN_EN			(1 << 8)
+#define PWR_CTRL1_USE_CORE1_WFE			(1 << 5)
+#define PWR_CTRL1_USE_CORE0_WFE			(1 << 4)
+#define PWR_CTRL1_USE_CORE1_WFI			(1 << 1)
+#define PWR_CTRL1_USE_CORE0_WFI			(1 << 0)
+
+#define PWR_CTRL2_DIV2_UP_EN			(1 << 25)
+#define PWR_CTRL2_DIV1_UP_EN			(1 << 24)
+#define PWR_CTRL2_DUR_STANDBY2_VAL		(1 << 16)
+#define PWR_CTRL2_DUR_STANDBY1_VAL		(1 << 8)
+#define PWR_CTRL2_CORE2_UP_RATIO		(1 << 4)
+#define PWR_CTRL2_CORE1_UP_RATIO		(1 << 0)
+
 /* Compatibility defines and inclusion */
 
 #include <mach/regs-pmu.h>


From sylvester.nawrocki at gmail.com  Fri Apr 19 17:12:13 2013
From: sylvester.nawrocki at gmail.com (Sylwester Nawrocki)
Date: Fri, 19 Apr 2013 23:12:13 +0200
Subject: [PATCH] cpufreq: exynos: allow disabling cpufreq drivers
In-Reply-To: <201304192243.30430.arnd@arndb.de>
References: <201304191554.29679.arnd@arndb.de>
 <201304192059.38606.arnd@arndb.de> <5171AB10.5070702@gmail.com>
 <201304192243.30430.arnd@arndb.de>
Message-ID: <5171B32D.6030601@gmail.com>

On 04/19/2013 10:43 PM, Arnd Bergmann wrote:
> On Friday 19 April 2013, Sylwester Nawrocki wrote:
>>> It could also be working by chance on EXYNOS4, since the register
>>> definitions were not actually removed from the regs-clk.h header
>>> for those.
>>
>> That's most likely what happened.
>
> Ok. I think I see the bigger picture now. The EXYNOS5 cpufreq driver was
> actually just merged now, so I assume that by the time Thomas did the clock
> changes, the register definitions for EXYNOS5 were actually unused and he
> subsequently removed them from the kernel.
>
> Since the driver now depends on them, I think the only way forward for 3.10
> is to revert the change that removed the definitions and put them back in
> place.

Yes, it sounds like a best thing to do. I was also considering that.

> We really should use the clock API from all the exynos cpufreq drivers, but it's
> too late for that change now in 3.10 and we will have to do it for 3.11 then.

Yes, the changes required to make the cpufreq driver using the clocks 
API would
be rather significant.

> This are not looking so good for exynos multiplatform support in 3.10 now, but
> if we get it in, that will mean we have to disable cpufreq when building
> multiplatform, but it can remain for the classic single-platform configurations.

Alright, let's hope eventually we get at least a minimum booting system. ;)

Thanks,
Sylwester


From olof at lixom.net  Fri Apr 19 17:17:53 2013
From: olof at lixom.net (Olof Johansson)
Date: Fri, 19 Apr 2013 14:17:53 -0700
Subject: [PATCH] ARM: exynos: restore mach/regs-clock.h for exynos5
In-Reply-To: <201304192310.26041.arnd@arndb.de>
References: <201304191554.29679.arnd@arndb.de>
 <201304192059.38606.arnd@arndb.de> <5171AB10.5070702@gmail.com>
 <201304192310.26041.arnd@arndb.de>
Message-ID: <CAOesGMg=ywanoJTeTZwcS-AxUYq00hD9NZCKeN=3_iksSm8QVA@mail.gmail.com>

On Fri, Apr 19, 2013 at 2:10 PM, Arnd Bergmann <arnd at arndb.de> wrote:
> Commit 6e6aac75 "ARM: EXYNOS: Migrate clock support to common
> clock framework" from Thomas Abraham removed the Exynos5 specific
> register definitions as they were unused at the time, but the
> cpufreq driver actually still uses them.
>
> Cc: Sylwester Nawrocki <s.nawrocki at samsung.com>
> Cc: Tomasz Figa <t.figa at samsung.com>
> Cc: Thomas Abraham <thomas.abraham at linaro.org>
> Cc: Kukjin Kim <kgene.kim at samsung.com>
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> 8<----
>
> I'd apply this one on next/drivers to fix the build error, unless
> someone has concerns.

Acked-by: Olof Johansson <olof at lixom.net>


From robherring2 at gmail.com  Fri Apr 19 17:32:40 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Fri, 19 Apr 2013 16:32:40 -0500
Subject: [PATCH v3] ARM: default machine descriptor for multiplatform
In-Reply-To: <201304191640.32139.arnd@arndb.de>
References: <1365779468-116419-1-git-send-email-arnd@arndb.de>
 <20130419132848.GO14496@n2100.arm.linux.org.uk>
 <201304191621.54681.arnd@arndb.de> <201304191640.32139.arnd@arndb.de>
Message-ID: <5171B7F8.4040601@gmail.com>

On 04/19/2013 09:40 AM, Arnd Bergmann wrote:
> Since we now have default implementations for init_time and init_irq,
> the init_machine callback is the only one that is not yet optional,
> but since simple DT based platforms all have the same
> of_platform_populate function call in there, we can consolidate them
> as well, and then actually boot with a completely empty machine_desc.
> Unofortunately we cannot just default to an empty init_machine: We
> cannot call of_platform_populate before init_machine because that
> does not work in case of auxdata, and we cannot call it after
> init_machine either because the machine might need to run code
> after adding the devices.
> 
> To take the final step, this adds support for booting without defining
> any machine_desc whatsoever.
> 
> For the case that CONFIG_MULTIPLATFORM is enabled, it adds a
> global machine descriptor that never matches any machine but is
> used as a fallback if nothing else matches. We assume that without
> CONFIG_MULTIPLATFORM, we only want to boot on the systems that the kernel
> is built for, so we still retain the build-time warning for missing
> machine descriptors and the run-time warning when the platform does not
> match in that case.
> 
> In the case that we run on a multiplatform kernel and the machine
> provides a fully populated device tree, we attempt to keep booting,
> hoping that no machine specific callbacks are necessary.
> 
> Finally, this also removes the misguided "select ARCH_VEXPRESS" that
> was only added to avoid a build error for allnoconfig kernels.
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Acked-by: Nicolas Pitre <nico at linaro.org>
> Acked-by: Olof Johansson <olof at lixom.net>
> Cc: "Russell King - ARM Linux" <linux at arm.linux.org.uk>

[...]

>  	if (machine_desc->init_machine)
>  		machine_desc->init_machine();
> +	else
> +		of_platform_populate(NULL, of_default_bus_match_table,

This will fail to build for !OF. of_platform.h needs this:

#define of_default_bus_match_table NULL

You may need some struct forward declarations, but this commit in my
tree for 3.10 should fix those:

commit d450f445f9a654080a6be4094376c2192d9a1f36
Author: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
Date:   Tue Feb 19 02:58:25 2013 +0300

    <linux/of_platform.h>: fix compilation warnings with DT disabled


Rob

> +					NULL, NULL);
>  	return 0;
>  }
>  arch_initcall(customize_machine);
> 



From nicolas.pitre at linaro.org  Fri Apr 19 17:37:00 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Fri, 19 Apr 2013 17:37:00 -0400 (EDT)
Subject: [PATCH] ARM: make cpu_init() notrace
In-Reply-To: <1366302046.3388.8.camel@linaro1.home>
References: <1366302046.3388.8.camel@linaro1.home>
Message-ID: <alpine.LFD.2.03.1304191735270.17375@syhkavp.arg>

On Thu, 18 Apr 2013, Jon Medhurst (Tixy) wrote:

> On resume from CPU power down any trace hooks enabled in cpu_init()
> will get called before that function has done set_my_cpu_offset(),
> so any use of per-cpu variables by trace hook code will cause bad
> things to happen. Prevent this by marking the function notrace.
> 
> This fixes lockups/crashes seen when enabling function tracer on TC2
> with the not yet mainlined cpuidle driver.

This has potential to fix things on other platforms too.

> 
> Signed-off-by: Jon Medhurst <tixy at linaro.org>

Acked-by: Nicolas Pitre <nico at linaro.org>

I think you may send it to RMK's patch system.


> ---
>  arch/arm/kernel/setup.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> index d343a6c..943cbf0 100644
> --- a/arch/arm/kernel/setup.c
> +++ b/arch/arm/kernel/setup.c
> @@ -390,7 +390,7 @@ static void __init feat_v6_fixup(void)
>   *
>   * cpu_init sets up the per-CPU stacks.
>   */
> -void cpu_init(void)
> +void notrace cpu_init(void)
>  {
>  	unsigned int cpu = smp_processor_id();
>  	struct stack *stk = &stacks[cpu];
> -- 
> 1.7.10.4
> 
> 


From arnd at arndb.de  Fri Apr 19 17:54:24 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 19 Apr 2013 23:54:24 +0200
Subject: [PATCH v3] ARM: default machine descriptor for multiplatform
In-Reply-To: <5171B7F8.4040601@gmail.com>
References: <1365779468-116419-1-git-send-email-arnd@arndb.de>
 <201304191640.32139.arnd@arndb.de> <5171B7F8.4040601@gmail.com>
Message-ID: <201304192354.25065.arnd@arndb.de>

On Friday 19 April 2013, Rob Herring wrote:
> This will fail to build for !OF. of_platform.h needs this:
> 
> #define of_default_bus_match_table NULL
> 
> You may need some struct forward declarations, but this commit in my
> tree for 3.10 should fix those:
> 
> commit d450f445f9a654080a6be4094376c2192d9a1f36
> Author: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
> Date:   Tue Feb 19 02:58:25 2013 +0300
> 
>     <linux/of_platform.h>: fix compilation warnings with DT disabled
> 

Ok. I've actually stumbled over missing declarations from of_platform.h
and related files a number of times. Could we please not hide any
declarations inside of #ifdef when there is no #else alternative?

If we just show the of_default_bus_match_table declaration in the
header file, there is no need to provide the silly NULL macro,
since the of_platform_populate alternative will just ignore it.

I'll just put the code in an #ifdef for now, but I'd really prefer
to clean up this and many other locations that currently have
to do #ifdef CONFIG_OF when they really don't need to.

	Arnd


From sergei.shtylyov at cogentembedded.com  Fri Apr 19 17:55:12 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Sat, 20 Apr 2013 01:55:12 +0400
Subject: [PATCH v5 0/9] Reorganize R8A7779/Marzen USB code
Message-ID: <201304200155.13492.sergei.shtylyov@cogentembedded.com>

Hello.

   Here's the set of 9 patches against the Simon Horman's 'renesas.git' repo,
'renesas-next-20130419' tag.  It was created to fix the shortcomings in the
R8A7779/Marzen USB platform code and R8A7779 USB common PHY driver, and so
spans both arch/arm/mach-shmobile/ and drivers/usb/ subtrees (some patches have
to touch both subtrees). The patches were conceived with the complete
bisectability goal in mind.

[1/9] ARM: shmobile: Marzen: move USB EHCI, OHCI, and PHY devices to R8A7779 code
[2/9] ehci-platform: add pre_setup() method to platform data
[3/9] ARM: shmobile: r8a7779: setup EHCI internal buffer
[4/9] rcar-phy: remove EHCI internal buffer setup
[5/9] ARM: shmobile: r8a7779: remove USB PHY 2nd memory resource
[6/9] rcar-phy: correct base address
[7/9] rcar-phy: add platform data
[8/9] ARM: shmobile: Marzen: pass platform data to USB PHY device
[9/9] rcar-phy: handle platform data

WBR, Sergei


From sergei.shtylyov at cogentembedded.com  Fri Apr 19 17:56:23 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Sat, 20 Apr 2013 01:56:23 +0400
Subject: [PATCH v5 1/9] ARM: shmobile: Marzen: move USB EHCI, OHCI,
 and PHY devices to R8A7779 code
Message-ID: <201304200156.23830.sergei.shtylyov@cogentembedded.com>

USB EHCI, OHCI, and common PHY are the SoC devices but are wrongly defined and
registered in the Marzen board file.  Move the data and code to their proper
place in setup-r8a7779.c; while at it, we have to rename 8a7779_late_devices[]
to 8a7779_standard_devices[] -- this seems legitimate since they are registered
from r8a7779_add_standard_devices() anyway.

Note that I'm deliberately changing the USB PHY platform device's 'id' field
from (previously just omitted) 0 to -1 as the device is a single of its kind.

Note also that the board and SoC code have to be in one patch to keep the code
bisectable...

The patch has been tested on the Marzen board.

Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Acked-by: Simon Horman <horms+renesas at verge.net.au>

---
Changes since version 4:
- resolved reject in the 'board-marzen.c' file, refreshed the patch.

Changes since version 3:
- refreshed the 'board-marzen.c' file.

Changes since version 2:
- added a note about testing to the changelog;
- added ACKs from Simon Horman and Kuninori Morimoto.

Changes since the original posting:
- added a note about bisectability to the changelog.

 arch/arm/mach-shmobile/board-marzen.c         |  178 -------------------------
 arch/arm/mach-shmobile/include/mach/r8a7779.h |    1 
 arch/arm/mach-shmobile/setup-r8a7779.c        |  185 +++++++++++++++++++++++++-
 3 files changed, 184 insertions(+), 180 deletions(-)

Index: renesas/arch/arm/mach-shmobile/board-marzen.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/board-marzen.c
+++ renesas/arch/arm/mach-shmobile/board-marzen.c
@@ -37,10 +37,6 @@
 #include <linux/mmc/host.h>
 #include <linux/mmc/sh_mobile_sdhi.h>
 #include <linux/mfd/tmio.h>
-#include <linux/usb/otg.h>
-#include <linux/usb/ehci_pdriver.h>
-#include <linux/usb/ohci_pdriver.h>
-#include <linux/pm_runtime.h>
 #include <mach/hardware.h>
 #include <mach/r8a7779.h>
 #include <mach/common.h>
@@ -150,26 +146,6 @@ static struct platform_device hspi_devic
 	.num_resources	= ARRAY_SIZE(hspi_resources),
 };
 
-/* USB PHY */
-static struct resource usb_phy_resources[] = {
-	[0] = {
-		.start		= 0xffe70000,
-		.end		= 0xffe70900 - 1,
-		.flags		= IORESOURCE_MEM,
-	},
-	[1] = {
-		.start		= 0xfff70000,
-		.end		= 0xfff70900 - 1,
-		.flags		= IORESOURCE_MEM,
-	},
-};
-
-static struct platform_device usb_phy_device = {
-	.name		= "rcar_usb_phy",
-	.resource	= usb_phy_resources,
-	.num_resources	= ARRAY_SIZE(usb_phy_resources),
-};
-
 /* LEDS */
 static struct gpio_led marzen_leds[] = {
 	{
@@ -205,161 +181,9 @@ static struct platform_device *marzen_de
 	&sdhi0_device,
 	&thermal_device,
 	&hspi_device,
-	&usb_phy_device,
 	&leds_device,
 };
 
-/* USB */
-static struct usb_phy *phy;
-static int usb_power_on(struct platform_device *pdev)
-{
-	if (!phy)
-		return -EIO;
-
-	pm_runtime_enable(&pdev->dev);
-	pm_runtime_get_sync(&pdev->dev);
-
-	usb_phy_init(phy);
-
-	return 0;
-}
-
-static void usb_power_off(struct platform_device *pdev)
-{
-	if (!phy)
-		return;
-
-	usb_phy_shutdown(phy);
-
-	pm_runtime_put_sync(&pdev->dev);
-	pm_runtime_disable(&pdev->dev);
-}
-
-static struct usb_ehci_pdata ehcix_pdata = {
-	.power_on	= usb_power_on,
-	.power_off	= usb_power_off,
-	.power_suspend	= usb_power_off,
-};
-
-static struct resource ehci0_resources[] = {
-	[0] = {
-		.start	= 0xffe70000,
-		.end	= 0xffe70400 - 1,
-		.flags	= IORESOURCE_MEM,
-	},
-	[1] = {
-		.start	= gic_iid(0x4c),
-		.flags	= IORESOURCE_IRQ,
-	},
-};
-
-static struct platform_device ehci0_device = {
-	.name	= "ehci-platform",
-	.id	= 0,
-	.dev	= {
-		.dma_mask		= &ehci0_device.dev.coherent_dma_mask,
-		.coherent_dma_mask	= 0xffffffff,
-		.platform_data		= &ehcix_pdata,
-	},
-	.num_resources	= ARRAY_SIZE(ehci0_resources),
-	.resource	= ehci0_resources,
-};
-
-static struct resource ehci1_resources[] = {
-	[0] = {
-		.start	= 0xfff70000,
-		.end	= 0xfff70400 - 1,
-		.flags	= IORESOURCE_MEM,
-	},
-	[1] = {
-		.start	= gic_iid(0x4d),
-		.flags	= IORESOURCE_IRQ,
-	},
-};
-
-static struct platform_device ehci1_device = {
-	.name	= "ehci-platform",
-	.id	= 1,
-	.dev	= {
-		.dma_mask		= &ehci1_device.dev.coherent_dma_mask,
-		.coherent_dma_mask	= 0xffffffff,
-		.platform_data		= &ehcix_pdata,
-	},
-	.num_resources	= ARRAY_SIZE(ehci1_resources),
-	.resource	= ehci1_resources,
-};
-
-static struct usb_ohci_pdata ohcix_pdata = {
-	.power_on	= usb_power_on,
-	.power_off	= usb_power_off,
-	.power_suspend	= usb_power_off,
-};
-
-static struct resource ohci0_resources[] = {
-	[0] = {
-		.start	= 0xffe70400,
-		.end	= 0xffe70800 - 1,
-		.flags	= IORESOURCE_MEM,
-	},
-	[1] = {
-		.start	= gic_iid(0x4c),
-		.flags	= IORESOURCE_IRQ,
-	},
-};
-
-static struct platform_device ohci0_device = {
-	.name	= "ohci-platform",
-	.id	= 0,
-	.dev	= {
-		.dma_mask		= &ohci0_device.dev.coherent_dma_mask,
-		.coherent_dma_mask	= 0xffffffff,
-		.platform_data		= &ohcix_pdata,
-	},
-	.num_resources	= ARRAY_SIZE(ohci0_resources),
-	.resource	= ohci0_resources,
-};
-
-static struct resource ohci1_resources[] = {
-	[0] = {
-		.start	= 0xfff70400,
-		.end	= 0xfff70800 - 1,
-		.flags	= IORESOURCE_MEM,
-	},
-	[1] = {
-		.start	= gic_iid(0x4d),
-		.flags	= IORESOURCE_IRQ,
-	},
-};
-
-static struct platform_device ohci1_device = {
-	.name	= "ohci-platform",
-	.id	= 1,
-	.dev	= {
-		.dma_mask		= &ohci1_device.dev.coherent_dma_mask,
-		.coherent_dma_mask	= 0xffffffff,
-		.platform_data		= &ohcix_pdata,
-	},
-	.num_resources	= ARRAY_SIZE(ohci1_resources),
-	.resource	= ohci1_resources,
-};
-
-static struct platform_device *marzen_late_devices[] __initdata = {
-	&ehci0_device,
-	&ehci1_device,
-	&ohci0_device,
-	&ohci1_device,
-};
-
-static void __init marzen_init_late(void)
-{
-	/* get usb phy */
-	phy = usb_get_phy(USB_PHY_TYPE_USB2);
-
-	shmobile_init_late();
-	platform_add_devices(marzen_late_devices,
-			     ARRAY_SIZE(marzen_late_devices));
-}
-
 static const struct pinctrl_map marzen_pinctrl_map[] = {
 	/* HSPI0 */
 	PIN_MAP_MUX_GROUP_DEFAULT("sh-hspi.0", "pfc-r8a7779",
@@ -418,6 +242,6 @@ MACHINE_START(MARZEN, "marzen")
 	.nr_irqs	= NR_IRQS_LEGACY,
 	.init_irq	= r8a7779_init_irq,
 	.init_machine	= marzen_init,
-	.init_late	= marzen_init_late,
+	.init_late	= r8a7779_init_late,
 	.init_time	= r8a7779_earlytimer_init,
 MACHINE_END
Index: renesas/arch/arm/mach-shmobile/include/mach/r8a7779.h
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/include/mach/r8a7779.h
+++ renesas/arch/arm/mach-shmobile/include/mach/r8a7779.h
@@ -33,6 +33,7 @@ extern void r8a7779_add_early_devices(vo
 extern void r8a7779_add_standard_devices(void);
 extern void r8a7779_add_standard_devices_dt(void);
 extern void r8a7779_add_ether_device(struct sh_eth_plat_data *pdata);
+extern void r8a7779_init_late(void);
 extern void r8a7779_clock_init(void);
 extern void r8a7779_pinmux_init(void);
 extern void r8a7779_pm_init(void);
Index: renesas/arch/arm/mach-shmobile/setup-r8a7779.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/setup-r8a7779.c
+++ renesas/arch/arm/mach-shmobile/setup-r8a7779.c
@@ -32,6 +32,10 @@
 #include <linux/sh_intc.h>
 #include <linux/sh_timer.h>
 #include <linux/dma-mapping.h>
+#include <linux/usb/otg.h>
+#include <linux/usb/ehci_pdriver.h>
+#include <linux/usb/ohci_pdriver.h>
+#include <linux/pm_runtime.h>
 #include <mach/hardware.h>
 #include <mach/irqs.h>
 #include <mach/r8a7779.h>
@@ -383,6 +387,162 @@ static struct platform_device sata_devic
 	},
 };
 
+/* USB PHY */
+static struct resource usb_phy_resources[] = {
+	[0] = {
+		.start		= 0xffe70000,
+		.end		= 0xffe70900 - 1,
+		.flags		= IORESOURCE_MEM,
+	},
+	[1] = {
+		.start		= 0xfff70000,
+		.end		= 0xfff70900 - 1,
+		.flags		= IORESOURCE_MEM,
+	},
+};
+
+static struct platform_device usb_phy_device = {
+	.name		= "rcar_usb_phy",
+	.id		= -1,
+	.resource	= usb_phy_resources,
+	.num_resources	= ARRAY_SIZE(usb_phy_resources),
+};
+
+/* USB */
+static struct usb_phy *phy;
+
+static int usb_power_on(struct platform_device *pdev)
+{
+	if (!phy)
+		return -EIO;
+
+	pm_runtime_enable(&pdev->dev);
+	pm_runtime_get_sync(&pdev->dev);
+
+	usb_phy_init(phy);
+
+	return 0;
+}
+
+static void usb_power_off(struct platform_device *pdev)
+{
+	if (!phy)
+		return;
+
+	usb_phy_shutdown(phy);
+
+	pm_runtime_put_sync(&pdev->dev);
+	pm_runtime_disable(&pdev->dev);
+}
+
+static struct usb_ehci_pdata ehcix_pdata = {
+	.power_on	= usb_power_on,
+	.power_off	= usb_power_off,
+	.power_suspend	= usb_power_off,
+};
+
+static struct resource ehci0_resources[] = {
+	[0] = {
+		.start	= 0xffe70000,
+		.end	= 0xffe70400 - 1,
+		.flags	= IORESOURCE_MEM,
+	},
+	[1] = {
+		.start	= gic_iid(0x4c),
+		.flags	= IORESOURCE_IRQ,
+	},
+};
+
+static struct platform_device ehci0_device = {
+	.name	= "ehci-platform",
+	.id	= 0,
+	.dev	= {
+		.dma_mask		= &ehci0_device.dev.coherent_dma_mask,
+		.coherent_dma_mask	= 0xffffffff,
+		.platform_data		= &ehcix_pdata,
+	},
+	.num_resources	= ARRAY_SIZE(ehci0_resources),
+	.resource	= ehci0_resources,
+};
+
+static struct resource ehci1_resources[] = {
+	[0] = {
+		.start	= 0xfff70000,
+		.end	= 0xfff70400 - 1,
+		.flags	= IORESOURCE_MEM,
+	},
+	[1] = {
+		.start	= gic_iid(0x4d),
+		.flags	= IORESOURCE_IRQ,
+	},
+};
+
+static struct platform_device ehci1_device = {
+	.name	= "ehci-platform",
+	.id	= 1,
+	.dev	= {
+		.dma_mask		= &ehci1_device.dev.coherent_dma_mask,
+		.coherent_dma_mask	= 0xffffffff,
+		.platform_data		= &ehcix_pdata,
+	},
+	.num_resources	= ARRAY_SIZE(ehci1_resources),
+	.resource	= ehci1_resources,
+};
+
+static struct usb_ohci_pdata ohcix_pdata = {
+	.power_on	= usb_power_on,
+	.power_off	= usb_power_off,
+	.power_suspend	= usb_power_off,
+};
+
+static struct resource ohci0_resources[] = {
+	[0] = {
+		.start	= 0xffe70400,
+		.end	= 0xffe70800 - 1,
+		.flags	= IORESOURCE_MEM,
+	},
+	[1] = {
+		.start	= gic_iid(0x4c),
+		.flags	= IORESOURCE_IRQ,
+	},
+};
+
+static struct platform_device ohci0_device = {
+	.name	= "ohci-platform",
+	.id	= 0,
+	.dev	= {
+		.dma_mask		= &ohci0_device.dev.coherent_dma_mask,
+		.coherent_dma_mask	= 0xffffffff,
+		.platform_data		= &ohcix_pdata,
+	},
+	.num_resources	= ARRAY_SIZE(ohci0_resources),
+	.resource	= ohci0_resources,
+};
+
+static struct resource ohci1_resources[] = {
+	[0] = {
+		.start	= 0xfff70400,
+		.end	= 0xfff70800 - 1,
+		.flags	= IORESOURCE_MEM,
+	},
+	[1] = {
+		.start	= gic_iid(0x4d),
+		.flags	= IORESOURCE_IRQ,
+	},
+};
+
+static struct platform_device ohci1_device = {
+	.name	= "ohci-platform",
+	.id	= 1,
+	.dev	= {
+		.dma_mask		= &ohci1_device.dev.coherent_dma_mask,
+		.coherent_dma_mask	= 0xffffffff,
+		.platform_data		= &ohcix_pdata,
+	},
+	.num_resources	= ARRAY_SIZE(ohci1_resources),
+	.resource	= ohci1_resources,
+};
+
 /* Ether */
 static struct resource ether_resources[] = {
 	{
@@ -404,9 +564,10 @@ static struct platform_device *r8a7779_d
 	&scif5_device,
 	&tmu00_device,
 	&tmu01_device,
+	&usb_phy_device,
 };
 
-static struct platform_device *r8a7779_late_devices[] __initdata = {
+static struct platform_device *r8a7779_standard_devices[] __initdata = {
 	&i2c0_device,
 	&i2c1_device,
 	&i2c2_device,
@@ -426,8 +587,8 @@ void __init r8a7779_add_standard_devices
 
 	platform_add_devices(r8a7779_devices_dt,
 			    ARRAY_SIZE(r8a7779_devices_dt));
-	platform_add_devices(r8a7779_late_devices,
-			    ARRAY_SIZE(r8a7779_late_devices));
+	platform_add_devices(r8a7779_standard_devices,
+			    ARRAY_SIZE(r8a7779_standard_devices));
 }
 
 void __init r8a7779_add_ether_device(struct sh_eth_plat_data *pdata)
@@ -470,6 +631,23 @@ void __init r8a7779_add_early_devices(vo
 	 */
 }
 
+static struct platform_device *r8a7779_late_devices[] __initdata = {
+	&ehci0_device,
+	&ehci1_device,
+	&ohci0_device,
+	&ohci1_device,
+};
+
+void __init r8a7779_init_late(void)
+{
+	/* get USB PHY */
+	phy = usb_get_phy(USB_PHY_TYPE_USB2);
+
+	shmobile_init_late();
+	platform_add_devices(r8a7779_late_devices,
+			     ARRAY_SIZE(r8a7779_late_devices));
+}
+
 #ifdef CONFIG_USE_OF
 void __init r8a7779_init_delay(void)
 {
@@ -503,6 +681,7 @@ DT_MACHINE_START(R8A7779_DT, "Generic R8
 	.init_irq	= r8a7779_init_irq_dt,
 	.init_machine	= r8a7779_add_standard_devices_dt,
 	.init_time	= shmobile_timer_init,
+	.init_late	= r8a7779_init_late,
 	.dt_compat	= r8a7779_compat_dt,
 MACHINE_END
 #endif /* CONFIG_USE_OF */


From sergei.shtylyov at cogentembedded.com  Fri Apr 19 17:58:18 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Sat, 20 Apr 2013 01:58:18 +0400
Subject: [PATCH v5 3/9] ARM: shmobile: r8a7779: setup EHCI internal buffer
Message-ID: <201304200158.19374.sergei.shtylyov@cogentembedded.com>

Setup the EHCI internal buffer (before EHCI driver has a chance to touch the
registers) using the pre_setup() method in 'struct usb_ehci_pdata'.

The patch has been tested on the Marzen board.

Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Acked-by: Simon Horman <horms+renesas at verge.net.au>

---
Changes since version 4:
- refreshed the patch.

Changes since version 3:
- lowercased the SoC name in the subject.

Changes since version 2:
- added #include <linux/usb/hcd.h>;
- added a note about testing to the changelog;
- added ACKs from Simon Horman and Kuninori Morimoto.

Changes since the original posting:
- changed from init() platform device method to pre_setup() as per the previous
  patch.

 arch/arm/mach-shmobile/setup-r8a7779.c |   16 ++++++++++++++++
 1 file changed, 16 insertions(+)

Index: renesas/arch/arm/mach-shmobile/setup-r8a7779.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/setup-r8a7779.c
+++ renesas/arch/arm/mach-shmobile/setup-r8a7779.c
@@ -33,6 +33,7 @@
 #include <linux/sh_timer.h>
 #include <linux/dma-mapping.h>
 #include <linux/usb/otg.h>
+#include <linux/usb/hcd.h>
 #include <linux/usb/ehci_pdriver.h>
 #include <linux/usb/ohci_pdriver.h>
 #include <linux/pm_runtime.h>
@@ -435,10 +436,25 @@ static void usb_power_off(struct platfor
 	pm_runtime_disable(&pdev->dev);
 }
 
+static int ehci_init_internal_buffer(struct usb_hcd *hcd)
+{
+	/*
+	 * Below are recommended values from the datasheet;
+	 * see [USB :: Setting of EHCI Internal Buffer].
+	 */
+	/* EHCI IP internal buffer setting */
+	iowrite32(0x00ff0040, hcd->regs + 0x0094);
+	/* EHCI IP internal buffer enable */
+	iowrite32(0x00000001, hcd->regs + 0x009C);
+
+	return 0;
+}
+
 static struct usb_ehci_pdata ehcix_pdata = {
 	.power_on	= usb_power_on,
 	.power_off	= usb_power_off,
 	.power_suspend	= usb_power_off,
+	.pre_setup	= ehci_init_internal_buffer,
 };
 
 static struct resource ehci0_resources[] = {


From sergei.shtylyov at cogentembedded.com  Fri Apr 19 17:59:18 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Sat, 20 Apr 2013 01:59:18 +0400
Subject: [PATCH v5 4/9] rcar-phy: remove EHCI internal buffer setup
Message-ID: <201304200159.18768.sergei.shtylyov@cogentembedded.com>

Now that the EHCI internal  buffer setup is done by the platform code, we  can
remove  such code from this driver as it  never  really belonged here.  We also
no longer need the 2nd memory region now (2nd EHCI controller is simply missing
in e.g. R8A7778 SoC).

The patch has been tested on the Marzen and BOCK-W boards.

Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Acked-by: Simon Horman <horms+renesas at verge.net.au>

---
Changes since version 2:
- added a note about testing to the changelog;
- added ACKs from Simon Horman and Kuninori Morimoto.

Changes since the original posting:
- split R8A7779 SoC file change to a separate patch.

 drivers/usb/phy/rcar-phy.c |   28 ++++------------------------
 1 file changed, 4 insertions(+), 24 deletions(-)

Index: renesas/drivers/usb/phy/rcar-phy.c
===================================================================
--- renesas.orig/drivers/usb/phy/rcar-phy.c
+++ renesas/drivers/usb/phy/rcar-phy.c
@@ -23,8 +23,6 @@
 #define USBEH0		0x080C
 #define USBOH0		0x081C
 #define USBCTL0		0x0858
-#define EIIBC1		0x0094
-#define EIIBC2		0x009C
 
 /* USBPCTRL1 */
 #define PHY_RST		(1 << 2)
@@ -40,7 +38,6 @@ struct rcar_usb_phy_priv {
 	spinlock_t lock;
 
 	void __iomem *reg0;
-	void __iomem *reg1;
 	int counter;
 };
 
@@ -59,7 +56,6 @@ static int rcar_usb_phy_init(struct usb_
 	struct rcar_usb_phy_priv *priv = usb_phy_to_priv(phy);
 	struct device *dev = phy->dev;
 	void __iomem *reg0 = priv->reg0;
-	void __iomem *reg1 = priv->reg1;
 	int i;
 	u32 val;
 	unsigned long flags;
@@ -97,19 +93,6 @@ static int rcar_usb_phy_init(struct usb_
 		iowrite32(0x00000000, (reg0 + USBPCTRL0));
 
 		/*
-		 * EHCI IP internal buffer setting
-		 * EHCI IP internal buffer enable
-		 *
-		 * These are recommended value of a datasheet
-		 * see [USB :: EHCI internal buffer setting]
-		 */
-		iowrite32(0x00ff0040, (reg0 + EIIBC1));
-		iowrite32(0x00ff0040, (reg1 + EIIBC1));
-
-		iowrite32(0x00000001, (reg0 + EIIBC2));
-		iowrite32(0x00000001, (reg1 + EIIBC2));
-
-		/*
 		 * Bus alignment settings
 		 */
 
@@ -145,14 +128,13 @@ static void rcar_usb_phy_shutdown(struct
 static int rcar_usb_phy_probe(struct platform_device *pdev)
 {
 	struct rcar_usb_phy_priv *priv;
-	struct resource *res0, *res1;
+	struct resource *res0;
 	struct device *dev = &pdev->dev;
-	void __iomem *reg0, *reg1;
+	void __iomem *reg0;
 	int ret;
 
 	res0 = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-	res1 = platform_get_resource(pdev, IORESOURCE_MEM, 1);
-	if (!res0 || !res1) {
+	if (!res0) {
 		dev_err(dev, "Not enough platform resources\n");
 		return -EINVAL;
 	}
@@ -164,8 +146,7 @@ static int rcar_usb_phy_probe(struct pla
 	 * this driver can't use devm_request_and_ioremap(dev, res) here
 	 */
 	reg0 = devm_ioremap_nocache(dev, res0->start, resource_size(res0));
-	reg1 = devm_ioremap_nocache(dev, res1->start, resource_size(res1));
-	if (!reg0 || !reg1) {
+	if (!reg0) {
 		dev_err(dev, "ioremap error\n");
 		return -ENOMEM;
 	}
@@ -177,7 +158,6 @@ static int rcar_usb_phy_probe(struct pla
 	}
 
 	priv->reg0		= reg0;
-	priv->reg1		= reg1;
 	priv->counter		= 0;
 	priv->phy.dev		= dev;
 	priv->phy.label		= dev_name(dev);


From sergei.shtylyov at cogentembedded.com  Fri Apr 19 18:00:07 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Sat, 20 Apr 2013 02:00:07 +0400
Subject: [PATCH v5 5/9] ARM: shmobile: r8a7779: remove USB PHY 2nd memory
 resource
Message-ID: <201304200200.08498.sergei.shtylyov@cogentembedded.com>

Now that 'drivers/usb/phy/rcar-phy.c' doesn't require the second memory resource
anymore, we can remove it from the R8A7779's USB PHY platform device.

Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Acked-by: Simon Horman <horms+renesas at verge.net.au>

---
Changes since version 4:
- refreshed the patch.

Changes since version 3:
- lowercased the SoC name in the subject.

Changes since version 2:
- refreshed atop of the prior patches;
- added a note about testing to the changelog;
- added ACKs from Simon Horman and Kuninori Morimoto.

Changes since the original posting:
- new patch in this version, split from the previous one.

 arch/arm/mach-shmobile/setup-r8a7779.c |    5 -----
 1 file changed, 5 deletions(-)

Index: renesas/arch/arm/mach-shmobile/setup-r8a7779.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/setup-r8a7779.c
+++ renesas/arch/arm/mach-shmobile/setup-r8a7779.c
@@ -395,11 +395,6 @@ static struct resource usb_phy_resources
 		.end		= 0xffe70900 - 1,
 		.flags		= IORESOURCE_MEM,
 	},
-	[1] = {
-		.start		= 0xfff70000,
-		.end		= 0xfff70900 - 1,
-		.flags		= IORESOURCE_MEM,
-	},
 };
 
 static struct platform_device usb_phy_device = {


From sergei.shtylyov at cogentembedded.com  Fri Apr 19 18:01:03 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Sat, 20 Apr 2013 02:01:03 +0400
Subject: [PATCH v5 6/9] rcar-phy: correct base address
Message-ID: <201304200201.04320.sergei.shtylyov@cogentembedded.com>

The memory region that is used by the driver overlaps EHCI and OHCI  register
regions for absolutely no reason now  -- fix it  by adding offset of 0x800 to
the base address, changing the register #define's accordingly. This has extra
positive effect that we now can use devm_ioremap_resource()...

Note that the driver and the SoC code have to be in one patch to keep the code
bisectable...

The patch has been tested on the Marzen board.

Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Acked-by: Simon Horman <horms+renesas at verge.net.au>

---
Changes since version 4:
- refreshed the patch.

Changes since version 2:
- refreshed atop of the prior patches;
- added a note about testing to the changelog;
- added ACKs from Simon Horman and Kuninori Morimoto.

Changes since the original posting:
- added a note about bisectability to the changelog.

 arch/arm/mach-shmobile/setup-r8a7779.c |    2 +-
 drivers/usb/phy/rcar-phy.c             |   28 ++++++++++------------------
 2 files changed, 11 insertions(+), 19 deletions(-)

Index: renesas/arch/arm/mach-shmobile/setup-r8a7779.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/setup-r8a7779.c
+++ renesas/arch/arm/mach-shmobile/setup-r8a7779.c
@@ -391,7 +391,7 @@ static struct platform_device sata_devic
 /* USB PHY */
 static struct resource usb_phy_resources[] = {
 	[0] = {
-		.start		= 0xffe70000,
+		.start		= 0xffe70800,
 		.end		= 0xffe70900 - 1,
 		.flags		= IORESOURCE_MEM,
 	},
Index: renesas/drivers/usb/phy/rcar-phy.c
===================================================================
--- renesas.orig/drivers/usb/phy/rcar-phy.c
+++ renesas/drivers/usb/phy/rcar-phy.c
@@ -16,13 +16,13 @@
 #include <linux/spinlock.h>
 #include <linux/module.h>
 
-/* USBH common register */
-#define USBPCTRL0	0x0800
-#define USBPCTRL1	0x0804
-#define USBST		0x0808
-#define USBEH0		0x080C
-#define USBOH0		0x081C
-#define USBCTL0		0x0858
+/* REGS block */
+#define USBPCTRL0	0x00
+#define USBPCTRL1	0x04
+#define USBST		0x08
+#define USBEH0		0x0C
+#define USBOH0		0x1C
+#define USBCTL0		0x58
 
 /* USBPCTRL1 */
 #define PHY_RST		(1 << 2)
@@ -139,17 +139,9 @@ static int rcar_usb_phy_probe(struct pla
 		return -EINVAL;
 	}
 
-	/*
-	 * CAUTION
-	 *
-	 * Because this phy address is also mapped under OHCI/EHCI address area,
-	 * this driver can't use devm_request_and_ioremap(dev, res) here
-	 */
-	reg0 = devm_ioremap_nocache(dev, res0->start, resource_size(res0));
-	if (!reg0) {
-		dev_err(dev, "ioremap error\n");
-		return -ENOMEM;
-	}
+	reg0 = devm_ioremap_resource(dev, res0);
+	if (IS_ERR(reg0))
+		return PTR_ERR(reg0);
 
 	priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
 	if (!priv) {


From lenb at kernel.org  Fri Apr 19 18:02:04 2013
From: lenb at kernel.org (Len Brown)
Date: Fri, 19 Apr 2013 18:02:04 -0400
Subject: [PATCH 7/9] intel: cpuidle: remove stop/start critical timings
In-Reply-To: <1364991322-20585-7-git-send-email-daniel.lezcano@linaro.org>
References: <1364991322-20585-1-git-send-email-daniel.lezcano@linaro.org>
 <1364991322-20585-7-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <5171BEDC.8020205@kernel.org>

On 04/03/2013 08:15 AM, Daniel Lezcano wrote:
> The start/stop_critical_timings are called from arch/x86/kernel/process.c
> in the cpu_idle loop function.
> 
> Remove the ones in the cpuidle driver.
> 
> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>

Acked-by: Len Brown <len.brown at intel.com>




From sergei.shtylyov at cogentembedded.com  Fri Apr 19 18:03:19 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Sat, 20 Apr 2013 02:03:19 +0400
Subject: [PATCH v5 8/9] ARM: shmobile: Marzen: pass platform data to USB PHY
 device
Message-ID: <201304200203.20482.sergei.shtylyov@cogentembedded.com>

Since we're now going to setup the USBPCTRL0 register using the USB PHY device's
platform data, we now need a way to pass those platform data from the board file
to the device which is situated in setup-r8a7779.c -- and what I'm suggesting is
r8a7779_add_usb_phy_device() that will register USB PHY platform device with the
passed platform data using platform_device_register_resndata() call; creating
this function envolves deletion of 'usb_phy_device' from r8a7779_devices_dt[],
so that it will no longer be registered for the generic R8A7779 machine (where
we can't provide the platform data anyway), hence EHCI/OHCI drivers will fail
to load as well.

For the Marzen board, this new function will be called from marzen_init() to
register the USB PHY device early enough.

Note that the board and the SoC code have to be in one patch to keep the code
bisectable...

The patch has been tested on the Marzen board.

Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Acked-by: Simon Horman <horms+renesas at verge.net.au>

---
Changes since version 4:
- refreshed the patch.

Changes since version 3:
- removed the initializer for 'usb_phy_platform_data';
- refreshed the 'board-marzen.c' file.

Changes since version 2:
- refreshed atop of the prior patches;
- added a note about testing to the changelog;
- added ACKs from Simon Horman and Kuninori Morimoto.

Changes since the original posting:
- added a note about bisectability to the changelog.

 arch/arm/mach-shmobile/board-marzen.c         |    3 +++
 arch/arm/mach-shmobile/include/mach/r8a7779.h |    2 ++
 arch/arm/mach-shmobile/setup-r8a7779.c        |   16 ++++++++--------
 3 files changed, 13 insertions(+), 8 deletions(-)

Index: renesas/arch/arm/mach-shmobile/board-marzen.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/board-marzen.c
+++ renesas/arch/arm/mach-shmobile/board-marzen.c
@@ -57,6 +57,8 @@ static struct regulator_consumer_supply 
 	REGULATOR_SUPPLY("vdd33a", "smsc911x"),
 };
 
+static struct rcar_phy_platform_data usb_phy_platform_data;
+
 /* SMSC LAN89218 */
 static struct resource smsc911x_resources[] = {
 	[0] = {
@@ -232,6 +234,7 @@ static void __init marzen_init(void)
 	r8a7779_init_irq_extpin(1); /* IRQ1 as individual interrupt */
 
 	r8a7779_add_standard_devices();
+	r8a7779_add_usb_phy_device(&usb_phy_platform_data);
 	platform_add_devices(marzen_devices, ARRAY_SIZE(marzen_devices));
 }
 
Index: renesas/arch/arm/mach-shmobile/include/mach/r8a7779.h
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/include/mach/r8a7779.h
+++ renesas/arch/arm/mach-shmobile/include/mach/r8a7779.h
@@ -4,6 +4,7 @@
 #include <linux/sh_clk.h>
 #include <linux/pm_domain.h>
 #include <linux/sh_eth.h>
+#include <linux/usb/rcar-phy.h>
 
 struct platform_device;
 
@@ -33,6 +34,7 @@ extern void r8a7779_add_early_devices(vo
 extern void r8a7779_add_standard_devices(void);
 extern void r8a7779_add_standard_devices_dt(void);
 extern void r8a7779_add_ether_device(struct sh_eth_plat_data *pdata);
+extern void r8a7779_add_usb_phy_device(struct rcar_phy_platform_data *pdata);
 extern void r8a7779_init_late(void);
 extern void r8a7779_clock_init(void);
 extern void r8a7779_pinmux_init(void);
Index: renesas/arch/arm/mach-shmobile/setup-r8a7779.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/setup-r8a7779.c
+++ renesas/arch/arm/mach-shmobile/setup-r8a7779.c
@@ -397,13 +397,6 @@ static struct resource usb_phy_resources
 	},
 };
 
-static struct platform_device usb_phy_device = {
-	.name		= "rcar_usb_phy",
-	.id		= -1,
-	.resource	= usb_phy_resources,
-	.num_resources	= ARRAY_SIZE(usb_phy_resources),
-};
-
 /* USB */
 static struct usb_phy *phy;
 
@@ -575,7 +568,6 @@ static struct platform_device *r8a7779_d
 	&scif5_device,
 	&tmu00_device,
 	&tmu01_device,
-	&usb_phy_device,
 };
 
 static struct platform_device *r8a7779_standard_devices[] __initdata = {
@@ -610,6 +602,14 @@ void __init r8a7779_add_ether_device(str
 					  pdata, sizeof(*pdata));
 }
 
+void __init r8a7779_add_usb_phy_device(struct rcar_phy_platform_data *pdata)
+{
+	platform_device_register_resndata(&platform_bus, "rcar_usb_phy", -1,
+					  usb_phy_resources,
+					  ARRAY_SIZE(usb_phy_resources),
+					  pdata, sizeof(*pdata));
+}
+
 /* do nothing for !CONFIG_SMP or !CONFIG_HAVE_TWD */
 void __init __weak r8a7779_register_twd(void) { }
 


From sergei.shtylyov at cogentembedded.com  Fri Apr 19 18:07:07 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Sat, 20 Apr 2013 02:07:07 +0400
Subject: [PATCH v4 0/4] Add USB support to R8A7778/BOCK-W
Message-ID: <201304200207.07895.sergei.shtylyov@cogentembedded.com>

Hello.

   Here's the set of 3 patches against the Simon Horman's 'renesas.git' repo,
'renesas-next-20130416' tag and the R8A7779/Marzen patchset I've posted.
 It was created to add support of R8A7778/BOCK-W USB to the platform code and
the USB common PHY driver, and so spans both arch/arm/mach-shmobile/ and
drivers/usb/phy/ subtrees.

[1/3] rcar-phy: add R8A7778 support
[2/3] ARM: shmobile: r8a7778: add USB support
[3/3] ARM: shmobile: BOCK-W: add USB support

The patch #4 (ARM: shmobile: BOCK-W: enable USB in defconfig) that has been
already merged, is not reposted.

WBR, Sergei


From arnd at arndb.de  Fri Apr 19 18:08:28 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Sat, 20 Apr 2013 00:08:28 +0200
Subject: linux-next ARM multi-platform randconfig errors
In-Reply-To: <20130419215134.GY10155@atomide.com>
References: <5170B4C6.1030300@gmail.com> <201304192258.36276.arnd@arndb.de>
 <20130419215134.GY10155@atomide.com>
Message-ID: <201304200008.28716.arnd@arndb.de>

On Friday 19 April 2013, Tony Lindgren wrote:
> In this case the options within the ifeq have already been tested
> with randconfigs. The reason for these build errors is that no SoC
> has been selected, and there's nothing implementing the the missing
> functions. The other option for fixing the issue would be to add a
> null SoC, which probably does not make sense in this case.
> 
> I've been building various omap2+ randconfigs for quite a while,
> and in general they work with a few warnings left. But I've
> been doing that with at least one SoC selected earlier because
> of the historic "must select a target board" that no longer is
> the case with your patch.

I think part of the problem is the way the Makefile is laid
out, e.g.

clockdomain-common                      += clockdomain.o
obj-$(CONFIG_ARCH_OMAP2)                += $(clockdomain-common)
obj-$(CONFIG_ARCH_OMAP3)                += $(clockdomain-common)
obj-$(CONFIG_ARCH_OMAP4)                += $(clockdomain-common)
obj-$(CONFIG_SOC_AM33XX)                += $(clockdomain-common)
obj-$(CONFIG_SOC_OMAP5)                 += $(clockdomain-common)

This results in building clockdomain.o whenever any of the various
SoCs are enabled, but not when none of them are enabled.

However, according to the error messages, this driver is actually
referenced by code that is enabled unconditionally.

You are right that your patch would fix this scenario, but it does
so by adding extra logic, not by simplifying it. I can see two ways
to make that more logical:

a) use the new Kconfig symbol consistently:
obj-$(CONFIG_SOC_OMAP)			+= clockdomain.o

b) don't introduce a new symbol but use the Makefile consistently
omap-common += io.o mux.o devices.o fb.o serial.o gpmc.o timer.o pm.o \
         common.o gpio.o dma.o wd_timer.o display.o i2c.o hdq1w.o omap_hwmod.o \
         omap_device.o sram.o
obj-$(CONFIG_ARCH_OMAP2)                += $(omap-common)
obj-$(CONFIG_ARCH_OMAP3)                += $(omap-common)
obj-$(CONFIG_ARCH_OMAP4)                += $(omap-common)
obj-$(CONFIG_SOC_AM33XX)                += $(omap-common)
obj-$(CONFIG_SOC_OMAP5)                 += $(omap-common)

	Arnd


From sergei.shtylyov at cogentembedded.com  Fri Apr 19 18:12:21 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Sat, 20 Apr 2013 02:12:21 +0400
Subject: [PATCH v4 2/3] ARM: shmobile: r8a7778: add USB support
Message-ID: <201304200212.22051.sergei.shtylyov@cogentembedded.com>

Add USB clock and EHCI, OHCI, and USB PHY platform devices for R8A7778 SoC;  add
a function to register PHY device with board-specific platform data and register
EHCI and OHCI platfrom devices from the init_late() board method.

Also,  don't forget to enable CONFIG_ARCH_HAS_[EO]HCI options for R8A7778 SoC in
Kconfig...

The patch has been tested on the BOCK-W board.

Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

---
Changes since version 3:
- resolved reject in the 'clock-r8a7778.c' file, refreshed the patch.

Changes since version 2:
- refreshed the patch.

Changes since the original posting:
- resolved rejects in the 'clock-r8a7778.c' file;
- lowercased the SoC name in the subject.

 arch/arm/mach-shmobile/Kconfig                |    2 
 arch/arm/mach-shmobile/clock-r8a7778.c        |    4 
 arch/arm/mach-shmobile/include/mach/r8a7778.h |    3 
 arch/arm/mach-shmobile/setup-r8a7778.c        |  108 ++++++++++++++++++++++++++
 4 files changed, 117 insertions(+)

Index: renesas/arch/arm/mach-shmobile/Kconfig
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/Kconfig
+++ renesas/arch/arm/mach-shmobile/Kconfig
@@ -41,6 +41,8 @@ config ARCH_R8A7778
 	select CPU_V7
 	select SH_CLK_CPG
 	select ARM_GIC
+	select USB_ARCH_HAS_EHCI
+	select USB_ARCH_HAS_OHCI
 
 config ARCH_R8A7779
 	bool "R-Car H1 (R8A77790)"
Index: renesas/arch/arm/mach-shmobile/clock-r8a7778.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/clock-r8a7778.c
+++ renesas/arch/arm/mach-shmobile/clock-r8a7778.c
@@ -105,6 +105,7 @@ static struct clk *main_clks[] = {
 enum {
 	MSTP323, MSTP322, MSTP321,
 	MSTP114,
+	MSTP100,
 	MSTP026, MSTP025, MSTP024, MSTP023, MSTP022, MSTP021,
 	MSTP016, MSTP015,
 	MSTP_NR };
@@ -114,6 +115,7 @@ static struct clk mstp_clks[MSTP_NR] = {
 	[MSTP322] = SH_CLK_MSTP32(&p_clk, MSTPCR3, 22, 0), /* SDHI1 */
 	[MSTP321] = SH_CLK_MSTP32(&p_clk, MSTPCR3, 21, 0), /* SDHI2 */
 	[MSTP114] = SH_CLK_MSTP32(&p_clk, MSTPCR1, 14, 0), /* Ether */
+	[MSTP100] = SH_CLK_MSTP32(&p_clk, MSTPCR1,  0, 0), /* USB0/1 */
 	[MSTP026] = SH_CLK_MSTP32(&p_clk, MSTPCR0, 26, 0), /* SCIF0 */
 	[MSTP025] = SH_CLK_MSTP32(&p_clk, MSTPCR0, 25, 0), /* SCIF1 */
 	[MSTP024] = SH_CLK_MSTP32(&p_clk, MSTPCR0, 24, 0), /* SCIF2 */
@@ -130,6 +132,8 @@ static struct clk_lookup lookups[] = {
 	CLKDEV_DEV_ID("sh_mobile_sdhi.1", &mstp_clks[MSTP322]), /* SDHI1 */
 	CLKDEV_DEV_ID("sh_mobile_sdhi.2", &mstp_clks[MSTP321]), /* SDHI2 */
 	CLKDEV_DEV_ID("sh-eth",	&mstp_clks[MSTP114]), /* Ether */
+	CLKDEV_DEV_ID("ehci-platform", &mstp_clks[MSTP100]), /* USB EHCI port0/1 */
+	CLKDEV_DEV_ID("ohci-platform", &mstp_clks[MSTP100]), /* USB OHCI port0/1 */
 	CLKDEV_DEV_ID("sh-sci.0", &mstp_clks[MSTP026]), /* SCIF0 */
 	CLKDEV_DEV_ID("sh-sci.1", &mstp_clks[MSTP025]), /* SCIF1 */
 	CLKDEV_DEV_ID("sh-sci.2", &mstp_clks[MSTP024]), /* SCIF2 */
Index: renesas/arch/arm/mach-shmobile/include/mach/r8a7778.h
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/include/mach/r8a7778.h
+++ renesas/arch/arm/mach-shmobile/include/mach/r8a7778.h
@@ -20,10 +20,13 @@
 
 #include <linux/mmc/sh_mobile_sdhi.h>
 #include <linux/sh_eth.h>
+#include <linux/usb/rcar-phy.h>
 
 extern void r8a7778_add_standard_devices(void);
 extern void r8a7778_add_standard_devices_dt(void);
 extern void r8a7778_add_ether_device(struct sh_eth_plat_data *pdata);
+extern void r8a7778_add_usb_phy_device(struct rcar_phy_platform_data *pdata);
+extern void r8a7778_init_late(void);
 extern void r8a7778_init_delay(void);
 extern void r8a7778_init_irq(void);
 extern void r8a7778_init_irq_dt(void);
Index: renesas/arch/arm/mach-shmobile/setup-r8a7778.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/setup-r8a7778.c
+++ renesas/arch/arm/mach-shmobile/setup-r8a7778.c
@@ -29,6 +29,12 @@
 #include <linux/irqchip.h>
 #include <linux/serial_sci.h>
 #include <linux/sh_timer.h>
+#include <linux/pm_runtime.h>
+#include <linux/usb/phy.h>
+#include <linux/usb/hcd.h>
+#include <linux/usb/ehci_pdriver.h>
+#include <linux/usb/ohci_pdriver.h>
+#include <linux/dma-mapping.h>
 #include <mach/irqs.h>
 #include <mach/r8a7778.h>
 #include <mach/common.h>
@@ -88,6 +94,99 @@ static struct sh_timer_config sh_tmu1_pl
 		&sh_tmu##idx##_platform_data,		\
 		sizeof(sh_tmu##idx##_platform_data))
 
+/* USB PHY */
+static struct resource usb_phy_resources[] = {
+	DEFINE_RES_MEM(0xffe70800, 0x100),
+	DEFINE_RES_MEM(0xffe76000, 0x100),
+};
+
+void __init r8a7778_add_usb_phy_device(struct rcar_phy_platform_data *pdata)
+{
+	platform_device_register_resndata(&platform_bus, "rcar_usb_phy", -1,
+					  usb_phy_resources,
+					  ARRAY_SIZE(usb_phy_resources),
+					  pdata, sizeof(*pdata));
+}
+
+/* USB */
+static struct usb_phy *phy;
+
+static int usb_power_on(struct platform_device *pdev)
+{
+	if (!phy)
+		return -EIO;
+
+	pm_runtime_enable(&pdev->dev);
+	pm_runtime_get_sync(&pdev->dev);
+
+	usb_phy_init(phy);
+
+	return 0;
+}
+
+static void usb_power_off(struct platform_device *pdev)
+{
+	if (!phy)
+		return;
+
+	usb_phy_shutdown(phy);
+
+	pm_runtime_put_sync(&pdev->dev);
+	pm_runtime_disable(&pdev->dev);
+}
+
+static int ehci_init_internal_buffer(struct usb_hcd *hcd)
+{
+	/*
+	 * Below are recommended values from the datasheet;
+	 * see [USB :: Setting of EHCI Internal Buffer].
+	 */
+	/* EHCI IP internal buffer setting */
+	iowrite32(0x00ff0040, hcd->regs + 0x0094);
+	/* EHCI IP internal buffer enable */
+	iowrite32(0x00000001, hcd->regs + 0x009C);
+
+	return 0;
+}
+
+static struct usb_ehci_pdata ehci_pdata = {
+	.power_on	= usb_power_on,
+	.power_off	= usb_power_off,
+	.power_suspend	= usb_power_off,
+	.pre_setup	= ehci_init_internal_buffer,
+};
+
+static struct resource ehci_resources[] = {
+	DEFINE_RES_MEM(0xffe70000, 0x400),
+	DEFINE_RES_IRQ(gic_iid(0x4c)),
+};
+
+static struct usb_ohci_pdata ohci_pdata = {
+	.power_on	= usb_power_on,
+	.power_off	= usb_power_off,
+	.power_suspend	= usb_power_off,
+};
+
+static struct resource ohci_resources[] = {
+	DEFINE_RES_MEM(0xffe70400, 0x400),
+	DEFINE_RES_IRQ(gic_iid(0x4c)),
+};
+
+#define USB_PLATFORM_INFO(hci)				\
+static struct platform_device_info hci##_info = {	\
+	.parent		= &platform_bus,		\
+	.name		= #hci "-platform",		\
+	.id		= -1,				\
+	.res		= hci##_resources,		\
+	.num_res	= ARRAY_SIZE(hci##_resources),	\
+	.data		= &hci##_pdata,			\
+	.size_data	= sizeof(hci##_pdata),		\
+	.dma_mask	= DMA_BIT_MASK(32),		\
+}
+
+USB_PLATFORM_INFO(ehci);
+USB_PLATFORM_INFO(ohci);
+
 /* Ether */
 static struct resource ether_resources[] = {
 	DEFINE_RES_MEM(0xfde00000, 0x400),
@@ -163,6 +262,14 @@ void __init r8a7778_add_standard_devices
 	r8a7778_register_tmu(1);
 }
 
+void __init r8a7778_init_late(void)
+{
+	phy = usb_get_phy(USB_PHY_TYPE_USB2);
+
+	platform_device_register_full(&ehci_info);
+	platform_device_register_full(&ohci_info);
+}
+
 static struct renesas_intc_irqpin_config irqpin_platform_data = {
 	.irq_base = irq_pin(0), /* IRQ0 -> IRQ3 */
 	.sense_bitfield_width = 2,
@@ -276,6 +383,7 @@ DT_MACHINE_START(R8A7778_DT, "Generic R8
 	.init_machine	= r8a7778_add_standard_devices_dt,
 	.init_time	= shmobile_timer_init,
 	.dt_compat	= r8a7778_compat_dt,
+	.init_late      = r8a7778_init_late,
 MACHINE_END
 
 #endif /* CONFIG_USE_OF */


From sergei.shtylyov at cogentembedded.com  Fri Apr 19 18:13:26 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Sat, 20 Apr 2013 02:13:26 +0400
Subject: [PATCH v4 3/3] ARM: shmobile: BOCK-W: add USB support
Message-ID: <201304200213.27342.sergei.shtylyov@cogentembedded.com>

Register the USB PHY device from bockw_init(), passing the platform  data to it.
Set machine's init_late() method to r8a7778_init_late() in order for [EO]HCI to
get registered too...

The patch has been tested on the BOCK-W board.

Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

---
Changes since version 3:
- removed initializer for 'usb_phy_platform_data' letting it be set to all 0s;
- refreshed the patch.

Changes since version 2:
- refreshed the patch.

Changes since the original posting:
- removed initializer for no longer existing field in 'usb_phy_platform_data',
  modified the comment to the 'ferrite_bead' field initializer.

 arch/arm/mach-shmobile/board-bockw.c |    4 ++++
 1 file changed, 4 insertions(+)

Index: renesas/arch/arm/mach-shmobile/board-bockw.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/board-bockw.c
+++ renesas/arch/arm/mach-shmobile/board-bockw.c
@@ -54,6 +54,8 @@ static struct resource smsc911x_resource
 	DEFINE_RES_IRQ(irq_pin(0)), /* IRQ 0 */
 };
 
+static struct rcar_phy_platform_data usb_phy_platform_data;
+
 static const struct pinctrl_map bockw_pinctrl_map[] = {
 	/* SCIF0 */
 	PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.0", "pfc-r8a7778",
@@ -71,6 +73,7 @@ static void __init bockw_init(void)
 	r8a7778_clock_init();
 	r8a7778_init_irq_extpin(1);
 	r8a7778_add_standard_devices();
+	r8a7778_add_usb_phy_device(&usb_phy_platform_data);
 
 	pinctrl_register_mappings(bockw_pinctrl_map,
 				  ARRAY_SIZE(bockw_pinctrl_map));
@@ -111,4 +114,5 @@ DT_MACHINE_START(BOCKW_DT, "bockw")
 	.init_machine	= bockw_init,
 	.init_time	= shmobile_timer_init,
 	.dt_compat	= bockw_boards_compat_dt,
+	.init_late      = r8a7778_init_late,
 MACHINE_END


From khilman at linaro.org  Fri Apr 19 18:17:53 2013
From: khilman at linaro.org (Kevin Hilman)
Date: Fri, 19 Apr 2013 15:17:53 -0700
Subject: [V3 patch 03/19] ARM: OMAP3: remove cpuidle_wrap_enter
In-Reply-To: <1365770165-27096-4-git-send-email-daniel.lezcano@linaro.org>
 (Daniel Lezcano's message of "Fri, 12 Apr 2013 14:35:49 +0200")
References: <1365770165-27096-1-git-send-email-daniel.lezcano@linaro.org>
 <1365770165-27096-4-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <87vc7iw4fi.fsf@linaro.org>

Daniel Lezcano <daniel.lezcano at linaro.org> writes:

> In a previous commit the en_core_tk_irqen flag has been added but we missed
> the cpuidle_wrap_enter which was doing the job to measure the time for the
> 'omap3_enter_idle' function.
>
> Actually, I don't see any reason to use this wrapper in the code. In the better
> case, the time computation is not correctly done because of the different
> operations done in omap3_enter_idle_bm which were not taken into account
> before the en_core_tk_irqen flag was set.
>
> As the time is reflected for the state overridden by the omap3_enter_idle_bm,
> using the wrapper is pointless now, so removing it.
>
> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>

The patch itself is fine, but the changelog is confusing, IMO.

I think you just need to say that since the en_core_tk flag is being
used, the wrapper is duplicating the time measurement already being done
by the core, so it should be removed.

Kevin


> ---
>  arch/arm/mach-omap2/cpuidle34xx.c |   30 +++++++++---------------------
>  1 file changed, 9 insertions(+), 21 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/cpuidle34xx.c b/arch/arm/mach-omap2/cpuidle34xx.c
> index 4f67a5b..a56310a 100644
> --- a/arch/arm/mach-omap2/cpuidle34xx.c
> +++ b/arch/arm/mach-omap2/cpuidle34xx.c
> @@ -99,11 +99,15 @@ static struct omap3_idle_statedata omap3_idle_data[] = {
>  	},
>  };
>  
> -/* Private functions */
> -
> -static int __omap3_enter_idle(struct cpuidle_device *dev,
> -				struct cpuidle_driver *drv,
> -				int index)
> +/**
> + * omap3_enter_idle - Programs OMAP3 to enter the specified state
> + * @dev: cpuidle device
> + * @drv: cpuidle driver
> + * @index: the index of state to be entered
> + */
> +static int omap3_enter_idle(struct cpuidle_device *dev,
> +			    struct cpuidle_driver *drv,
> +			    int index)
>  {
>  	struct omap3_idle_statedata *cx = &omap3_idle_data[index];
>  
> @@ -149,22 +153,6 @@ return_sleep_time:
>  }
>  
>  /**
> - * omap3_enter_idle - Programs OMAP3 to enter the specified state
> - * @dev: cpuidle device
> - * @drv: cpuidle driver
> - * @index: the index of state to be entered
> - *
> - * Called from the CPUidle framework to program the device to the
> - * specified target state selected by the governor.
> - */
> -static inline int omap3_enter_idle(struct cpuidle_device *dev,
> -				struct cpuidle_driver *drv,
> -				int index)
> -{
> -	return cpuidle_wrap_enter(dev, drv, index, __omap3_enter_idle);
> -}
> -
> -/**
>   * next_valid_state - Find next valid C-state
>   * @dev: cpuidle device
>   * @drv: cpuidle driver


From sergei.shtylyov at cogentembedded.com  Fri Apr 19 18:17:32 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Sat, 20 Apr 2013 02:17:32 +0400
Subject: [PATCH v2 0/1] Add I2C support to R8A7778/BOCK-W
Message-ID: <201304200217.32844.sergei.shtylyov@cogentembedded.com>

Hello.

   Here's the patch against the Simon Horman's 'renesas.git' repo,
'renesas-next-20130417' tag and my recent yet unapplied USB patches.
Here we add I2C support to the R8A7778 platform code. This will be
important in the future for the VIN driver since the video sensor chip
is controller via I2C bus #0 on BOCK-W. 

[1/1] ARM: shmobile: r8a7778: add I2C support

The patch #2 (ARM: shmobile: BOCK-W: enable I2C in defconfig) has been
already merged, and so not reposted.

WBR, Sergei


From khilman at linaro.org  Fri Apr 19 18:19:01 2013
From: khilman at linaro.org (Kevin Hilman)
Date: Fri, 19 Apr 2013 15:19:01 -0700
Subject: [V3 patch 09/19] ARM: OMAP3: cpuidle: use init/exit common routine
In-Reply-To: <1365770165-27096-10-git-send-email-daniel.lezcano@linaro.org>
 (Daniel Lezcano's message of "Fri, 12 Apr 2013 14:35:55 +0200")
References: <1365770165-27096-1-git-send-email-daniel.lezcano@linaro.org>
 <1365770165-27096-10-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <87obdaw4dm.fsf@linaro.org>

Daniel Lezcano <daniel.lezcano at linaro.org> writes:

> Remove the duplicated code and use the cpuidle common code for initialization.
>
> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>

Reviewed-by: Kevin Hilman <khilman at linaro.org>

> ---
>  arch/arm/mach-omap2/cpuidle34xx.c |   18 ++----------------
>  1 file changed, 2 insertions(+), 16 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/cpuidle34xx.c b/arch/arm/mach-omap2/cpuidle34xx.c
> index 027a787..cca045c 100644
> --- a/arch/arm/mach-omap2/cpuidle34xx.c
> +++ b/arch/arm/mach-omap2/cpuidle34xx.c
> @@ -26,6 +26,7 @@
>  #include <linux/cpuidle.h>
>  #include <linux/export.h>
>  #include <linux/cpu_pm.h>
> +#include <asm/cpuidle.h>
>  
>  #include "powerdomain.h"
>  #include "clockdomain.h"
> @@ -259,8 +260,6 @@ static int omap3_enter_idle_bm(struct cpuidle_device *dev,
>  	return ret;
>  }
>  
> -static DEFINE_PER_CPU(struct cpuidle_device, omap3_idle_dev);
> -
>  static struct cpuidle_driver omap3_idle_driver = {
>  	.name             = "omap3_idle",
>  	.owner            = THIS_MODULE,
> @@ -336,8 +335,6 @@ static struct cpuidle_driver omap3_idle_driver = {
>   */
>  int __init omap3_idle_init(void)
>  {
> -	struct cpuidle_device *dev;
> -
>  	mpu_pd = pwrdm_lookup("mpu_pwrdm");
>  	core_pd = pwrdm_lookup("core_pwrdm");
>  	per_pd = pwrdm_lookup("per_pwrdm");
> @@ -346,16 +343,5 @@ int __init omap3_idle_init(void)
>  	if (!mpu_pd || !core_pd || !per_pd || !cam_pd)
>  		return -ENODEV;
>  
> -	cpuidle_register_driver(&omap3_idle_driver);
> -
> -	dev = &per_cpu(omap3_idle_dev, smp_processor_id());
> -	dev->cpu = 0;
> -
> -	if (cpuidle_register_device(dev)) {
> -		printk(KERN_ERR "%s: CPUidle register device failed\n",
> -		       __func__);
> -		return -EIO;
> -	}
> -
> -	return 0;
> +	return cpuidle_register(&omap3_idle_driver, NULL);
>  }


From khilman at linaro.org  Fri Apr 19 18:19:33 2013
From: khilman at linaro.org (Kevin Hilman)
Date: Fri, 19 Apr 2013 15:19:33 -0700
Subject: [V3 patch 13/19] ARM: OMAP4: cpuidle: use init/exit common routine
In-Reply-To: <1365770165-27096-14-git-send-email-daniel.lezcano@linaro.org>
 (Daniel Lezcano's message of "Fri, 12 Apr 2013 14:35:59 +0200")
References: <1365770165-27096-1-git-send-email-daniel.lezcano@linaro.org>
 <1365770165-27096-14-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <87k3nyw4cq.fsf@linaro.org>

Daniel Lezcano <daniel.lezcano at linaro.org> writes:

> Remove the duplicated code and use the cpuidle common code for initialization.
>
> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>

Reviewed-by: Kevin Hilman <khilman at linaro.org>

> ---
>  arch/arm/mach-omap2/cpuidle44xx.c |   22 ++--------------------
>  1 file changed, 2 insertions(+), 20 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/cpuidle44xx.c b/arch/arm/mach-omap2/cpuidle44xx.c
> index cd188de..861dd90 100644
> --- a/arch/arm/mach-omap2/cpuidle44xx.c
> +++ b/arch/arm/mach-omap2/cpuidle44xx.c
> @@ -15,6 +15,7 @@
>  #include <linux/cpu_pm.h>
>  #include <linux/export.h>
>  
> +#include <asm/cpuidle.h>
>  #include <asm/proc-fns.h>
>  
>  #include "common.h"
> @@ -157,8 +158,6 @@ fail:
>  	return index;
>  }
>  
> -static DEFINE_PER_CPU(struct cpuidle_device, omap4_idle_dev);
> -
>  static struct cpuidle_driver omap4_idle_driver = {
>  	.name				= "omap4_idle",
>  	.owner				= THIS_MODULE,
> @@ -207,9 +206,6 @@ static struct cpuidle_driver omap4_idle_driver = {
>   */
>  int __init omap4_idle_init(void)
>  {
> -	struct cpuidle_device *dev;
> -	unsigned int cpu_id = 0;
> -
>  	mpu_pd = pwrdm_lookup("mpu_pwrdm");
>  	cpu_pd[0] = pwrdm_lookup("cpu0_pwrdm");
>  	cpu_pd[1] = pwrdm_lookup("cpu1_pwrdm");
> @@ -221,19 +217,5 @@ int __init omap4_idle_init(void)
>  	if (!cpu_clkdm[0] || !cpu_clkdm[1])
>  		return -ENODEV;
>  
> -	for_each_cpu(cpu_id, cpu_online_mask) {
> -		dev = &per_cpu(omap4_idle_dev, cpu_id);
> -		dev->cpu = cpu_id;
> -#ifdef CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED
> -		dev->coupled_cpus = *cpu_online_mask;
> -#endif
> -		cpuidle_register_driver(&omap4_idle_driver);
> -
> -		if (cpuidle_register_device(dev)) {
> -			pr_err("%s: CPUidle register failed\n", __func__);
> -			return -EIO;
> -		}
> -	}
> -
> -	return 0;
> +	return cpuidle_register(&omap4_idle_driver, cpu_online_mask);
>  }


From khilman at linaro.org  Fri Apr 19 18:21:54 2013
From: khilman at linaro.org (Kevin Hilman)
Date: Fri, 19 Apr 2013 15:21:54 -0700
Subject: [V3 patch 04/19] cpuidle: remove en_core_tk_irqen flag
In-Reply-To: <1365770165-27096-5-git-send-email-daniel.lezcano@linaro.org>
 (Daniel Lezcano's message of "Fri, 12 Apr 2013 14:35:50 +0200")
References: <1365770165-27096-1-git-send-email-daniel.lezcano@linaro.org>
 <1365770165-27096-5-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <87fvymw48t.fsf@linaro.org>

Daniel Lezcano <daniel.lezcano at linaro.org> writes:

> The en_core_tk_irqen flag is set in all the cpuidle driver which
> means it is not necessary to specify this flag.
>
> Remove the flag and the code related to it.
>
> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>

Acked-by: Kevin Hilman <khilman at linaro.org>  # for mach-omap2/*


From robherring2 at gmail.com  Fri Apr 19 18:22:15 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Fri, 19 Apr 2013 17:22:15 -0500
Subject: [PATCH v3] ARM: default machine descriptor for multiplatform
In-Reply-To: <201304192354.25065.arnd@arndb.de>
References: <1365779468-116419-1-git-send-email-arnd@arndb.de>
 <201304191640.32139.arnd@arndb.de> <5171B7F8.4040601@gmail.com>
 <201304192354.25065.arnd@arndb.de>
Message-ID: <5171C397.9090301@gmail.com>

On 04/19/2013 04:54 PM, Arnd Bergmann wrote:
> On Friday 19 April 2013, Rob Herring wrote:
>> This will fail to build for !OF. of_platform.h needs this:
>>
>> #define of_default_bus_match_table NULL
>>
>> You may need some struct forward declarations, but this commit in my
>> tree for 3.10 should fix those:
>>
>> commit d450f445f9a654080a6be4094376c2192d9a1f36
>> Author: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
>> Date:   Tue Feb 19 02:58:25 2013 +0300
>>
>>     <linux/of_platform.h>: fix compilation warnings with DT disabled
>>
> 
> Ok. I've actually stumbled over missing declarations from of_platform.h
> and related files a number of times. Could we please not hide any
> declarations inside of #ifdef when there is no #else alternative?
> 
> If we just show the of_default_bus_match_table declaration in the
> header file, there is no need to provide the silly NULL macro,
> since the of_platform_populate alternative will just ignore it.
> 
> I'll just put the code in an #ifdef for now, but I'd really prefer
> to clean up this and many other locations that currently have
> to do #ifdef CONFIG_OF when they really don't need to.

I think we can kill off CONFIG_OF_DEVICE completely. It is always
enabled when OF is (even for the oddball Sparc).

The only remaining user of of_platform_driver is ibmebus and 2 drivers.
It would be good to convert those to regular platform drivers.

Rob



From sergei.shtylyov at cogentembedded.com  Fri Apr 19 18:21:36 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Sat, 20 Apr 2013 02:21:36 +0400
Subject: [PATCH v2 1/1] ARM: shmobile: r8a7778: add I2C support
Message-ID: <201304200221.36928.sergei.shtylyov@cogentembedded.com>

From: Vladimir Barinov <vladimir.barinov at cogentembedded.com>

Add I2C clocks and platform devices for R8A7778 SoC.
Don't forget to also add the peripheral clock which the I2C driver uses.

Signed-off-by: Vladimir Barinov <vladimir.barinov at cogentembedded.com>
[Sergei: changed the registration function to platform_device_register_simple(),
regrouped MSTPxxx *enum* members, added the copyright.]
Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>

---
Changes since the original posting:
- regrouped MSTPxxx *enum* members;
- resolved reject in the 'clock-r8a7778.c' file, refreshed the patch;
- added an ACK from Kuninori Morimoto.

 arch/arm/mach-shmobile/clock-r8a7778.c |   14 +++++++++++++-
 arch/arm/mach-shmobile/setup-r8a7778.c |   32 ++++++++++++++++++++++++++++++++
 2 files changed, 45 insertions(+), 1 deletion(-)

Index: renesas/arch/arm/mach-shmobile/clock-r8a7778.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/clock-r8a7778.c
+++ renesas/arch/arm/mach-shmobile/clock-r8a7778.c
@@ -3,6 +3,7 @@
  *
  * Copyright (C) 2013  Renesas Solutions Corp.
  * Copyright (C) 2013  Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
+ * Copyright (C) 2013  Cogent Embedded, Inc.
  *
  * based on r8a7779
  *
@@ -106,7 +107,8 @@ enum {
 	MSTP323, MSTP322, MSTP321,
 	MSTP114,
 	MSTP100,
-	MSTP026, MSTP025, MSTP024, MSTP023, MSTP022, MSTP021,
+	MSTP030, MSTP029,
+	MSTP028, MSTP027, MSTP026, MSTP025, MSTP024, MSTP023, MSTP022, MSTP021,
 	MSTP016, MSTP015,
 	MSTP_NR };
 
@@ -116,6 +118,10 @@ static struct clk mstp_clks[MSTP_NR] = {
 	[MSTP321] = SH_CLK_MSTP32(&p_clk, MSTPCR3, 21, 0), /* SDHI2 */
 	[MSTP114] = SH_CLK_MSTP32(&p_clk, MSTPCR1, 14, 0), /* Ether */
 	[MSTP100] = SH_CLK_MSTP32(&p_clk, MSTPCR1,  0, 0), /* USB0/1 */
+	[MSTP030] = SH_CLK_MSTP32(&p_clk, MSTPCR0, 30, 0), /* I2C0 */
+	[MSTP029] = SH_CLK_MSTP32(&p_clk, MSTPCR0, 29, 0), /* I2C1 */
+	[MSTP028] = SH_CLK_MSTP32(&p_clk, MSTPCR0, 28, 0), /* I2C2 */
+	[MSTP027] = SH_CLK_MSTP32(&p_clk, MSTPCR0, 27, 0), /* I2C3 */
 	[MSTP026] = SH_CLK_MSTP32(&p_clk, MSTPCR0, 26, 0), /* SCIF0 */
 	[MSTP025] = SH_CLK_MSTP32(&p_clk, MSTPCR0, 25, 0), /* SCIF1 */
 	[MSTP024] = SH_CLK_MSTP32(&p_clk, MSTPCR0, 24, 0), /* SCIF2 */
@@ -127,6 +133,8 @@ static struct clk mstp_clks[MSTP_NR] = {
 };
 
 static struct clk_lookup lookups[] = {
+	CLKDEV_CON_ID("peripheral_clk", &p_clk),
+
 	/* MSTP32 clocks */
 	CLKDEV_DEV_ID("sh_mobile_sdhi.0", &mstp_clks[MSTP323]), /* SDHI0 */
 	CLKDEV_DEV_ID("sh_mobile_sdhi.1", &mstp_clks[MSTP322]), /* SDHI1 */
@@ -134,6 +142,10 @@ static struct clk_lookup lookups[] = {
 	CLKDEV_DEV_ID("sh-eth",	&mstp_clks[MSTP114]), /* Ether */
 	CLKDEV_DEV_ID("ehci-platform", &mstp_clks[MSTP100]), /* USB EHCI port0/1 */
 	CLKDEV_DEV_ID("ohci-platform", &mstp_clks[MSTP100]), /* USB OHCI port0/1 */
+	CLKDEV_DEV_ID("i2c-rcar.0", &mstp_clks[MSTP030]), /* I2C0 */
+	CLKDEV_DEV_ID("i2c-rcar.1", &mstp_clks[MSTP029]), /* I2C1 */
+	CLKDEV_DEV_ID("i2c-rcar.2", &mstp_clks[MSTP028]), /* I2C2 */
+	CLKDEV_DEV_ID("i2c-rcar.3", &mstp_clks[MSTP027]), /* I2C3 */
 	CLKDEV_DEV_ID("sh-sci.0", &mstp_clks[MSTP026]), /* SCIF0 */
 	CLKDEV_DEV_ID("sh-sci.1", &mstp_clks[MSTP025]), /* SCIF1 */
 	CLKDEV_DEV_ID("sh-sci.2", &mstp_clks[MSTP024]), /* SCIF2 */
Index: renesas/arch/arm/mach-shmobile/setup-r8a7778.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/setup-r8a7778.c
+++ renesas/arch/arm/mach-shmobile/setup-r8a7778.c
@@ -94,6 +94,33 @@ static struct sh_timer_config sh_tmu1_pl
 		&sh_tmu##idx##_platform_data,		\
 		sizeof(sh_tmu##idx##_platform_data))
 
+/* I2C */
+static struct resource i2c0_resources[] = {
+	DEFINE_RES_MEM(0xffc70000, 0x1000),
+	DEFINE_RES_IRQ(gic_iid(0x63)),
+};
+
+static struct resource i2c1_resources[] = {
+	DEFINE_RES_MEM(0xffc71000, 0x1000),
+	DEFINE_RES_IRQ(gic_iid(0x6e)),
+};
+
+static struct resource i2c2_resources[] = {
+	DEFINE_RES_MEM(0xffc72000, 0x1000),
+	DEFINE_RES_IRQ(gic_iid(0x6c)),
+};
+
+static struct resource i2c3_resources[] = {
+	DEFINE_RES_MEM(0xffc73000, 0x1000),
+	DEFINE_RES_IRQ(gic_iid(0x6d)),
+};
+
+#define r8a7778_register_i2c(idx)			\
+	platform_device_register_simple(		\
+		"i2c-rcar", idx,			\
+		i2c##idx##_resources,			\
+		ARRAY_SIZE(i2c##idx##_resources))
+
 /* USB PHY */
 static struct resource usb_phy_resources[] = {
 	DEFINE_RES_MEM(0xffe70800, 0x100),
@@ -260,6 +287,11 @@ void __init r8a7778_add_standard_devices
 
 	r8a7778_register_tmu(0);
 	r8a7778_register_tmu(1);
+
+	r8a7778_register_i2c(0);
+	r8a7778_register_i2c(1);
+	r8a7778_register_i2c(2);
+	r8a7778_register_i2c(3);
 }
 
 void __init r8a7778_init_late(void)


From sergei.shtylyov at cogentembedded.com  Fri Apr 19 18:27:32 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Sat, 20 Apr 2013 02:27:32 +0400
Subject: [PATCH v4 0/4] Add USB support to R8A7778/BOCK-W
In-Reply-To: <201304200207.07895.sergei.shtylyov@cogentembedded.com>
References: <201304200207.07895.sergei.shtylyov@cogentembedded.com>
Message-ID: <5171C4D4.8080607@cogentembedded.com>

Hello.

On 04/20/2013 02:07 AM, Sergei Shtylyov wrote:

>     Here's the set of 3 patches against the Simon Horman's 'renesas.git' repo,
> 'renesas-next-20130416' tag and the R8A7779/Marzen patchset I've posted.

    Sorry, it's against 'renesas-next-20130419' tag now.

WBR, Sergei



From sergei.shtylyov at cogentembedded.com  Fri Apr 19 18:28:14 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Sat, 20 Apr 2013 02:28:14 +0400
Subject: [PATCH v2 0/1] Add I2C support to R8A7778/BOCK-W
In-Reply-To: <201304200217.32844.sergei.shtylyov@cogentembedded.com>
References: <201304200217.32844.sergei.shtylyov@cogentembedded.com>
Message-ID: <5171C4FE.9000807@cogentembedded.com>

On 04/20/2013 02:17 AM, Sergei Shtylyov wrote:

>     Here's the patch against the Simon Horman's 'renesas.git' repo,
> 'renesas-next-20130417' tag and my recent yet unapplied USB patches.

    Sorry, it's against 'renesas-next-20130419' tag now.

WBR, Sergei



From sergei.shtylyov at cogentembedded.com  Fri Apr 19 18:30:07 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Sat, 20 Apr 2013 02:30:07 +0400
Subject: [PATCH v2 0/4] R-Car VIN driver with R8A7779/Marzen support
Message-ID: <201304200230.08819.sergei.shtylyov@cogentembedded.com>

Hello.

   Here's the set of 4 patches against the Simon Horman's 'renesas.git' repo,
'renesas-next-20130419' tag and my recent yet unapplied USB patches. Here we
add the VIN (Video In) driver and its platform code working on the R8A7779/
Marzen with ADV7180 I2C camera sensor. The driver patch also applies without
issues to Mauro's 'media_tree.git'...

[1/4] V4L2: soc_camera: Renesas R-Car VIN driver
[2/4] ARM: shmobile: r8a7779: add VIN support
[3/4] ARM: shmobile: Marzen: add VIN and ADV7180 support
[4/4] ARM: shmobile: Marzen: enable VIN and ADV7180 in defconfig

WBR, Sergei


From sergei.shtylyov at cogentembedded.com  Fri Apr 19 18:32:33 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Sat, 20 Apr 2013 02:32:33 +0400
Subject: [PATCH v2 2/4] ARM: shmobile: r8a7779: add VIN support
Message-ID: <201304200232.33731.sergei.shtylyov@cogentembedded.com>

From: Vladimir Barinov <vladimir.barinov at cogentembedded.com>

Add VIN clocks and platform devices for R8A7779 SoC; add function to register
the VIN platform devices.

Signed-off-by: Vladimir Barinov <vladimir.barinov at cogentembedded.com>
[Sergei: added 'id' parameter check to r8a7779_add_vin_device(), renamed some
variables.]
Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

---
Changes since the original posting:
- added 'id' parameter check to r8a7779_add_vin_device().

 arch/arm/mach-shmobile/clock-r8a7779.c        |   10 ++++++
 arch/arm/mach-shmobile/include/mach/r8a7779.h |    3 ++
 arch/arm/mach-shmobile/setup-r8a7779.c        |   38 ++++++++++++++++++++++++++
 3 files changed, 51 insertions(+)

Index: renesas/arch/arm/mach-shmobile/clock-r8a7779.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/clock-r8a7779.c
+++ renesas/arch/arm/mach-shmobile/clock-r8a7779.c
@@ -112,7 +112,9 @@ static struct clk *main_clks[] = {
 };
 
 enum { MSTP323, MSTP322, MSTP321, MSTP320,
+	MSTP120,
 	MSTP116, MSTP115, MSTP114,
+	MSTP110, MSTP109, MSTP108,
 	MSTP103, MSTP101, MSTP100,
 	MSTP030,
 	MSTP029, MSTP028, MSTP027, MSTP026, MSTP025, MSTP024, MSTP023, MSTP022, MSTP021,
@@ -125,9 +127,13 @@ static struct clk mstp_clks[MSTP_NR] = {
 	[MSTP322] = SH_CLK_MSTP32(&clkp_clk, MSTPCR3, 22, 0), /* SDHI1 */
 	[MSTP321] = SH_CLK_MSTP32(&clkp_clk, MSTPCR3, 21, 0), /* SDHI2 */
 	[MSTP320] = SH_CLK_MSTP32(&clkp_clk, MSTPCR3, 20, 0), /* SDHI3 */
+	[MSTP120] = SH_CLK_MSTP32(&clks_clk, MSTPCR1, 20, 0), /* VIN3 */
 	[MSTP116] = SH_CLK_MSTP32(&clkp_clk, MSTPCR1, 16, 0), /* PCIe */
 	[MSTP115] = SH_CLK_MSTP32(&clkp_clk, MSTPCR1, 15, 0), /* SATA */
 	[MSTP114] = SH_CLK_MSTP32(&clkp_clk, MSTPCR1, 14, 0), /* Ether */
+	[MSTP110] = SH_CLK_MSTP32(&clks_clk, MSTPCR1, 10, 0), /* VIN0 */
+	[MSTP109] = SH_CLK_MSTP32(&clks_clk, MSTPCR1,  9, 0), /* VIN1 */
+	[MSTP108] = SH_CLK_MSTP32(&clks_clk, MSTPCR1,  8, 0), /* VIN2 */
 	[MSTP103] = SH_CLK_MSTP32(&clks_clk, MSTPCR1,  3, 0), /* DU */
 	[MSTP101] = SH_CLK_MSTP32(&clkp_clk, MSTPCR1,  1, 0), /* USB2 */
 	[MSTP100] = SH_CLK_MSTP32(&clkp_clk, MSTPCR1,  0, 0), /* USB0/1 */
@@ -162,10 +168,14 @@ static struct clk_lookup lookups[] = {
 	CLKDEV_CON_ID("peripheral_clk",	&clkp_clk),
 
 	/* MSTP32 clocks */
+	CLKDEV_DEV_ID("rcar_vin.3", &mstp_clks[MSTP120]), /* VIN3 */
 	CLKDEV_DEV_ID("rcar-pcie", &mstp_clks[MSTP116]), /* PCIe */
 	CLKDEV_DEV_ID("sata_rcar", &mstp_clks[MSTP115]), /* SATA */
 	CLKDEV_DEV_ID("fc600000.sata", &mstp_clks[MSTP115]), /* SATA w/DT */
 	CLKDEV_DEV_ID("sh-eth", &mstp_clks[MSTP114]), /* Ether */
+	CLKDEV_DEV_ID("rcar_vin.0", &mstp_clks[MSTP110]), /* VIN0 */
+	CLKDEV_DEV_ID("rcar_vin.1", &mstp_clks[MSTP109]), /* VIN1 */
+	CLKDEV_DEV_ID("rcar_vin.2", &mstp_clks[MSTP108]), /* VIN2 */
 	CLKDEV_DEV_ID("ehci-platform.1", &mstp_clks[MSTP101]), /* USB EHCI port2 */
 	CLKDEV_DEV_ID("ohci-platform.1", &mstp_clks[MSTP101]), /* USB OHCI port2 */
 	CLKDEV_DEV_ID("ehci-platform.0", &mstp_clks[MSTP100]), /* USB EHCI port0/1 */
Index: renesas/arch/arm/mach-shmobile/include/mach/r8a7779.h
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/include/mach/r8a7779.h
+++ renesas/arch/arm/mach-shmobile/include/mach/r8a7779.h
@@ -5,6 +5,7 @@
 #include <linux/pm_domain.h>
 #include <linux/sh_eth.h>
 #include <linux/usb/rcar-phy.h>
+#include <linux/platform_data/camera-rcar.h>
 
 struct platform_device;
 
@@ -35,6 +36,8 @@ extern void r8a7779_add_standard_devices
 extern void r8a7779_add_standard_devices_dt(void);
 extern void r8a7779_add_ether_device(struct sh_eth_plat_data *pdata);
 extern void r8a7779_add_usb_phy_device(struct rcar_phy_platform_data *pdata);
+extern void r8a7779_add_vin_device(int idx,
+				   struct rcar_vin_platform_data *pdata);
 extern void r8a7779_init_late(void);
 extern void r8a7779_clock_init(void);
 extern void r8a7779_pinmux_init(void);
Index: renesas/arch/arm/mach-shmobile/setup-r8a7779.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/setup-r8a7779.c
+++ renesas/arch/arm/mach-shmobile/setup-r8a7779.c
@@ -559,6 +559,33 @@ static struct resource ether_resources[]
 	},
 };
 
+#define R8A7779_VIN(idx) \
+static struct resource vin##idx##_resources[] = {		\
+	DEFINE_RES_MEM(0xffc50000 + 0x1000 * (idx), 0x1000),	\
+	DEFINE_RES_IRQ(gic_iid(0x5f + (idx))),			\
+};								\
+								\
+static struct platform_device_info vin##idx##_info = {		\
+	.parent		= &platform_bus,			\
+	.name		= "rcar_vin",				\
+	.id		= idx,					\
+	.res		= vin##idx##_resources,			\
+	.num_res	= ARRAY_SIZE(vin##idx##_resources),	\
+	.dma_mask	= DMA_BIT_MASK(32),			\
+}
+
+R8A7779_VIN(0);
+R8A7779_VIN(1);
+R8A7779_VIN(2);
+R8A7779_VIN(3);
+
+static struct platform_device_info *vin_info_table[] __initdata = {
+	&vin0_info,
+	&vin1_info,
+	&vin2_info,
+	&vin3_info,
+};
+
 static struct platform_device *r8a7779_devices_dt[] __initdata = {
 	&scif0_device,
 	&scif1_device,
@@ -610,6 +637,17 @@ void __init r8a7779_add_usb_phy_device(s
 					  pdata, sizeof(*pdata));
 }
 
+void __init r8a7779_add_vin_device(int id,
+				   struct rcar_vin_platform_data *pdata)
+{
+	BUG_ON(id < 0 || id > 3);
+
+	vin_info_table[id]->data = pdata;
+	vin_info_table[id]->size_data = sizeof(struct rcar_vin_platform_data);
+
+	platform_device_register_full(vin_info_table[id]);
+}
+
 /* do nothing for !CONFIG_SMP or !CONFIG_HAVE_TWD */
 void __init __weak r8a7779_register_twd(void) { }
 


From sergei.shtylyov at cogentembedded.com  Fri Apr 19 18:33:32 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Sat, 20 Apr 2013 02:33:32 +0400
Subject: [PATCH v2 3/4] ARM: shmobile: Marzen: add VIN and ADV7180 support
Message-ID: <201304200233.33555.sergei.shtylyov@cogentembedded.com>

From: Vladimir Barinov <vladimir.barinov at cogentembedded.com>

Add ADV7180 platform devices on the Marzen board, configure VIN1/3 pins, and
register VIN1/3 devices with the ADV7180 specific platform data.

Signed-off-by: Vladimir Barinov <vladimir.barinov at cogentembedded.com>
[Sergei: removed superfluous tabulation and inserted empty lines in the macro
definition; updated the copyrights]
Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

---
Changes since the original posting:
- used a macro to define the camera platform devices;
- updated the copyrights;
- refreshed the patch.

 arch/arm/mach-shmobile/board-marzen.c |   44 +++++++++++++++++++++++++++++++++-
 1 file changed, 43 insertions(+), 1 deletion(-)

Index: renesas/arch/arm/mach-shmobile/board-marzen.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/board-marzen.c
+++ renesas/arch/arm/mach-shmobile/board-marzen.c
@@ -1,8 +1,9 @@
 /*
  * marzen board support
  *
- * Copyright (C) 2011  Renesas Solutions Corp.
+ * Copyright (C) 2011, 2013  Renesas Solutions Corp.
  * Copyright (C) 2011  Magnus Damm
+ * Copyright (C) 2013  Cogent Embedded, Inc.
  *
  * 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
@@ -37,6 +38,7 @@
 #include <linux/mmc/host.h>
 #include <linux/mmc/sh_mobile_sdhi.h>
 #include <linux/mfd/tmio.h>
+#include <media/soc_camera.h>
 #include <mach/hardware.h>
 #include <mach/r8a7779.h>
 #include <mach/common.h>
@@ -178,12 +180,40 @@ static struct platform_device leds_devic
 	},
 };
 
+static struct rcar_vin_platform_data vin_platform_data = {
+	.flags	= RCAR_VIN_BT656,
+};
+
+#define MARZEN_CAMERA(idx)					\
+static struct i2c_board_info camera##idx##_info = {		\
+	I2C_BOARD_INFO("adv7180", 0x20 + (idx)),		\
+};								\
+								\
+static struct soc_camera_link iclink##idx##_adv7180 = {		\
+	.bus_id		= 1 + 2 * (idx),			\
+	.i2c_adapter_id	= 0,					\
+	.board_info	= &camera##idx##_info,			\
+};								\
+								\
+static struct platform_device camera##idx##_device = {		\
+	.name	= "soc-camera-pdrv",				\
+	.id	= idx,						\
+	.dev	= {						\
+		.platform_data	= &iclink##idx##_adv7180,	\
+	},							\
+};
+
+MARZEN_CAMERA(0);
+MARZEN_CAMERA(1);
+
 static struct platform_device *marzen_devices[] __initdata = {
 	&eth_device,
 	&sdhi0_device,
 	&thermal_device,
 	&hspi_device,
 	&leds_device,
+	&camera0_device,
+	&camera1_device,
 };
 
 static const struct pinctrl_map marzen_pinctrl_map[] = {
@@ -219,6 +249,16 @@ static const struct pinctrl_map marzen_p
 	/* USB2 */
 	PIN_MAP_MUX_GROUP_DEFAULT("ehci-platform.1", "pfc-r8a7779",
 				  "usb2", "usb2"),
+	/* VIN1 */
+	PIN_MAP_MUX_GROUP_DEFAULT("rcar_vin.1", "pfc-r8a7779",
+				  "vin1_clk", "vin1"),
+	PIN_MAP_MUX_GROUP_DEFAULT("rcar_vin.1", "pfc-r8a7779",
+				  "vin1_data8", "vin1"),
+	/* VIN3 */
+	PIN_MAP_MUX_GROUP_DEFAULT("rcar_vin.3", "pfc-r8a7779",
+				  "vin3_clk", "vin3"),
+	PIN_MAP_MUX_GROUP_DEFAULT("rcar_vin.3", "pfc-r8a7779",
+				  "vin3_data8", "vin3"),
 };
 
 static void __init marzen_init(void)
@@ -235,6 +275,8 @@ static void __init marzen_init(void)
 
 	r8a7779_add_standard_devices();
 	r8a7779_add_usb_phy_device(&usb_phy_platform_data);
+	r8a7779_add_vin_device(1, &vin_platform_data);
+	r8a7779_add_vin_device(3, &vin_platform_data);
 	platform_add_devices(marzen_devices, ARRAY_SIZE(marzen_devices));
 }
 


From sergei.shtylyov at cogentembedded.com  Fri Apr 19 18:34:46 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Sat, 20 Apr 2013 02:34:46 +0400
Subject: [PATCH v2 4/4] ARM: shmobile: Marzen: enable VIN and ADV7180 in
 defconfig
Message-ID: <201304200234.47400.sergei.shtylyov@cogentembedded.com>

From: Vladimir Barinov <vladimir.barinov at cogentembedded.com>

Add the VIN and ADV7180 drivers to 'marzen_defconfig'.

Signed-off-by: Vladimir Barinov <vladimir.barinov at cogentembedded.com>
Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

---
 arch/arm/configs/marzen_defconfig |    7 +++++++
 1 file changed, 7 insertions(+)

Index: renesas/arch/arm/configs/marzen_defconfig
===================================================================
--- renesas.orig/arch/arm/configs/marzen_defconfig
+++ renesas/arch/arm/configs/marzen_defconfig
@@ -84,6 +84,13 @@ CONFIG_GPIO_RCAR=y
 CONFIG_THERMAL=y
 CONFIG_RCAR_THERMAL=y
 CONFIG_SSB=y
+CONFIG_MEDIA_SUPPORT=y
+CONFIG_MEDIA_CAMERA_SUPPORT=y
+CONFIG_V4L_PLATFORM_DRIVERS=y
+CONFIG_SOC_CAMERA=y
+CONFIG_VIDEO_RCAR_VIN=y
+# CONFIG_MEDIA_SUBDRV_AUTOSELECT is not set
+CONFIG_VIDEO_ADV7180=y
 CONFIG_USB=y
 CONFIG_USB_RCAR_PHY=y
 CONFIG_MMC=y


From robherring2 at gmail.com  Fri Apr 19 18:42:37 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Fri, 19 Apr 2013 17:42:37 -0500
Subject: linux-next arm64 randconfig errors
Message-ID: <5171C85D.8020909@gmail.com>

Here are errors in today's linux-next for arm64. Looks like most are missing arch pieces.

of_get_next_parent has a fix pending.

Rob

arch/arm64/kernel/early_printk.c:98:23: error: conflicting types for 'early_console'
drivers/base/regmap/regmap-mmio.c:120:4: error: implicit declaration of function 'readq' [-Werror=implicit-function-declaration]
drivers/base/regmap/regmap-mmio.c:64:4: error: implicit declaration of function 'writeq' [-Werror=implicit-function-declaration]
drivers/block/blockconsole.c:164:2: error: implicit declaration of function 'cmpxchg64' [-Werror=implicit-function-declaration]
drivers/dma/amba-pl08x.c:303:13: error: expected identifier before '(' token
drivers/gpio/gpio-generic.c:103:2: error: implicit declaration of function 'readq' [-Werror=implicit-function-declaration]
drivers/gpio/gpio-generic.c:98:2: error: implicit declaration of function 'writeq' [-Werror=implicit-function-declaration]
drivers/mfd/tps65912-core.c:147: undefined reference to `mfd_add_devices'
drivers/mfd/tps65912-core.c:164: undefined reference to `mfd_remove_devices'
drivers/mfd/tps65912-core.c:171: undefined reference to `mfd_remove_devices'
drivers/parport/parport_pc.c:67:25: fatal error: asm/parport.h: No such file or directory
ERROR: "of_get_next_parent" [drivers/media/v4l2-core/videodev.ko] undefined!
ERROR: "read_current_timer" [crypto/tcrypt.ko] undefined!
include/linux/vt_buffer.h:18:21: fatal error: asm/vga.h: No such file or directory
include/video/vga.h:22:21: fatal error: asm/vga.h: No such file or directory


From khilman at linaro.org  Fri Apr 19 18:44:19 2013
From: khilman at linaro.org (Kevin Hilman)
Date: Fri, 19 Apr 2013 15:44:19 -0700
Subject: [V3 patch 00/19] cpuidle: code consolidation
In-Reply-To: <1365770165-27096-1-git-send-email-daniel.lezcano@linaro.org>
 (Daniel Lezcano's message of "Fri, 12 Apr 2013 14:35:46 +0200")
References: <1365770165-27096-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <8761ziw37g.fsf@linaro.org>

Daniel Lezcano <daniel.lezcano at linaro.org> writes:

> This patchset series provide some code consolidation across the different
> cpuidle drivers. It contains two parts, the first one is the removal of
> the time keeping flag and the second one, is a common initialization routine.

[...]

> Tested-on: u8500
> Tested-on: at91
> Tested-on: intel i5
> Tested-on: OMAP4

Tested-by: Kevin Hilman <khilman at linaro.org> # OMAP3, OMAP4

Kevin


From paul at pwsan.com  Fri Apr 19 18:53:50 2013
From: paul at pwsan.com (Paul Walmsley)
Date: Fri, 19 Apr 2013 22:53:50 +0000 (UTC)
Subject: linux-next ARM multi-platform randconfig errors
In-Reply-To: <201304200008.28716.arnd@arndb.de>
References: <5170B4C6.1030300@gmail.com> <201304192258.36276.arnd@arndb.de>
 <20130419215134.GY10155@atomide.com> <201304200008.28716.arnd@arndb.de>
Message-ID: <alpine.DEB.2.00.1304192249250.24986@utopia.booyaka.com>

Hi,

On Sat, 20 Apr 2013, Arnd Bergmann wrote:

> I think part of the problem is the way the Makefile is laid
> out, e.g.
> 
> clockdomain-common                      += clockdomain.o
> obj-$(CONFIG_ARCH_OMAP2)                += $(clockdomain-common)
> obj-$(CONFIG_ARCH_OMAP3)                += $(clockdomain-common)
> obj-$(CONFIG_ARCH_OMAP4)                += $(clockdomain-common)
> obj-$(CONFIG_SOC_AM33XX)                += $(clockdomain-common)
> obj-$(CONFIG_SOC_OMAP5)                 += $(clockdomain-common)
> 
> This results in building clockdomain.o whenever any of the various
> SoCs are enabled, but not when none of them are enabled.
> 
> However, according to the error messages, this driver is actually
> referenced by code that is enabled unconditionally.

Seems to me that's where the issue is: in the code that uses it, like 
omap_hwmod.o.  If we're not building code for any OMAP SoCs, it seems 
rather pointless to build omap_hwmod.o -- at least until omap_hwmod.o is 
moved out into drivers/.


- Paul


From gregkh at linuxfoundation.org  Fri Apr 19 18:54:48 2013
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Fri, 19 Apr 2013 15:54:48 -0700
Subject: [PATCH v2 0/7] pcmcia: at91_cf: clean up and add DT support
In-Reply-To: <516E628B.1000104@atmel.com>
References: <cover.1363865228.git.nicolas.ferre@atmel.com>
 <CAHkwnC-aL=G9K9jttjD8Bk_ZKJ535vsGT26uCFbuFMeJUquYQw@mail.gmail.com>
 <516E628B.1000104@atmel.com>
Message-ID: <20130419225448.GA8242@kroah.com>

On Wed, Apr 17, 2013 at 10:51:23AM +0200, Nicolas Ferre wrote:
> On 04/17/2013 10:39 AM, Fabio Porcedda :
> > On Thu, Mar 21, 2013 at 12:40 PM, Nicolas Ferre <nicolas.ferre at atmel.com> wrote:
> >> These patches clean up at91_cf a bit and add DT bindings.
> >> It is based on a previous series from Joachim Eastwood and other cleanup
> >> patches by Fabio and Laurent.
> >> I have collected them together as they are lying around for some time.
> >>
> >> Please tell me if It can go through PCMCIA tree or if Andrew or Greg can
> >> take them.
> >> Note that they are not bug fixes, so you can stack them for 3.10.
> >>
> >> Thanks for your help, best regards.
> >>
> >> v2: add 2 more cleanup patches:
> >>         - move to module_platform_driver_probe()
> >>         - little trivial indentation fix
> >>
> >> Fabio Porcedda (1):
> >>   pcmcia: at91_cf: use module_platform_driver_probe()
> >>
> >> Joachim Eastwood (5):
> >>   pcmcia: at91_cf: fix gpio_get_value in at91_cf_get_status
> >>   pcmcia: at91_cf: convert to dev_ print functions
> >>   pcmcia: at91_cf: use devm_ functions for allocations
> >>   pcmcia: at91_cf: clean up header includes
> >>   pcmcia: at91_cf: add support for DT
> >>
> >> Laurent Navet (1):
> >>   pcmcia/trivial: at91_cf: fix checkpatch error
> >>
> >>  .../devicetree/bindings/ata/atmel-at91_cf.txt      |  19 +++
> >>  drivers/pcmcia/Kconfig                             |   2 +-
> >>  drivers/pcmcia/at91_cf.c                           | 176 ++++++++++-----------
> >>  3 files changed, 108 insertions(+), 89 deletions(-)
> >>  create mode 100644 Documentation/devicetree/bindings/ata/atmel-at91_cf.txt
> >>
> >> --
> >> 1.8.0
> >>
> > 
> > Ping?
> 
> Andrew, Greg, can you please take this series?
> 
> Here is the post on lkml:
> https://lkml.org/lkml/2013/3/21/246
> 
> Here is the first patch in patchwork (1/7):
> https://patchwork.kernel.org/patch/2312691/
> 
> Tell me if I can do something else to make this applied upstream...

The PCMCIA maintainer should take these, not me.

thanks,

greg k-h


From arnd at arndb.de  Fri Apr 19 19:11:44 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Sat, 20 Apr 2013 01:11:44 +0200
Subject: [PATCH v3] ARM: default machine descriptor for multiplatform
In-Reply-To: <5171C397.9090301@gmail.com>
References: <1365779468-116419-1-git-send-email-arnd@arndb.de>
 <201304192354.25065.arnd@arndb.de> <5171C397.9090301@gmail.com>
Message-ID: <201304200111.44617.arnd@arndb.de>

On Saturday 20 April 2013, Rob Herring wrote:
> The only remaining user of of_platform_driver is ibmebus and 2 drivers.
> It would be good to convert those to regular platform drivers.
> 

Right, I would not expect any trouble in converting ibmebus to
use a regular platform_driver. It already uses platform_device
anyway. We cannot remove ibmebus itself because it has special
DMA requirements, but we could move it to drivers/bus if the
powerpc maintainers like that.

	Arnd.


From sergei.shtylyov at cogentembedded.com  Fri Apr 19 20:10:45 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Sat, 20 Apr 2013 04:10:45 +0400
Subject: [PATCH v2 2/4] ARM: shmobile: r8a7779: add VIN support
In-Reply-To: <201304200232.33731.sergei.shtylyov@cogentembedded.com>
References: <201304200232.33731.sergei.shtylyov@cogentembedded.com>
Message-ID: <5171DD05.6020400@cogentembedded.com>

Hello.

On 04/20/2013 02:32 AM, Sergei Shtylyov wrote:

> From: Vladimir Barinov <vladimir.barinov at cogentembedded.com>
>
> Add VIN clocks and platform devices for R8A7779 SoC; add function to register
> the VIN platform devices.
>
> Signed-off-by: Vladimir Barinov <vladimir.barinov at cogentembedded.com>
> [Sergei: added 'id' parameter check to r8a7779_add_vin_device(), renamed some
> variables.]
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

[...]

> Index: renesas/arch/arm/mach-shmobile/setup-r8a7779.c
> ===================================================================
> --- renesas.orig/arch/arm/mach-shmobile/setup-r8a7779.c
> +++ renesas/arch/arm/mach-shmobile/setup-r8a7779.c
> @@ -559,6 +559,33 @@ static struct resource ether_resources[]
>   	},
>   };
>   
> +#define R8A7779_VIN(idx) \
> +static struct resource vin##idx##_resources[] = {		\
> +	DEFINE_RES_MEM(0xffc50000 + 0x1000 * (idx), 0x1000),	\
> +	DEFINE_RES_IRQ(gic_iid(0x5f + (idx))),			\
> +};								\
> +								\
> +static struct platform_device_info vin##idx##_info = {		\

    Hm, probably should have marked this as '__initdata'... maybe
the resources too.

> +	.parent		= &platform_bus,			\
> +	.name		= "rcar_vin",				\
> +	.id		= idx,					\
> +	.res		= vin##idx##_resources,			\
> +	.num_res	= ARRAY_SIZE(vin##idx##_resources),	\
> +	.dma_mask	= DMA_BIT_MASK(32),			\
> +}
>


From sboyd at codeaurora.org  Fri Apr 19 20:29:05 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Fri, 19 Apr 2013 17:29:05 -0700
Subject: [PATCH 3/4] ARM: sched_clock: Add support for >32 bit sched_clock
In-Reply-To: <1366417746-24990-1-git-send-email-sboyd@codeaurora.org>
References: <1366417746-24990-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1366417746-24990-4-git-send-email-sboyd@codeaurora.org>

The arm architected system counter has at least 56 bits of
useable bits. Add support to ARM's sched_clock implementation for
counters with more than 32 bits so we can avoid the complexity of
dealing with wraparound on these devices while benefiting from
the irqtime accounting and suspend/resume handling that the ARM
sched_clock code already has.

Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---

Maybe we need a union for the epoch_ns usage?

 arch/arm/include/asm/sched_clock.h |   2 +
 arch/arm/kernel/sched_clock.c      | 101 +++++++++++++++++++++++++++----------
 2 files changed, 77 insertions(+), 26 deletions(-)

diff --git a/arch/arm/include/asm/sched_clock.h b/arch/arm/include/asm/sched_clock.h
index 3d520dd..7fcd2ee 100644
--- a/arch/arm/include/asm/sched_clock.h
+++ b/arch/arm/include/asm/sched_clock.h
@@ -13,4 +13,6 @@ extern void setup_sched_clock(u32 (*read)(void), int bits, unsigned long rate);
 
 extern unsigned long long (*sched_clock_func)(void);
 
+extern void setup_sched_clock_64(u64 (*read)(void), int bits,
+				 unsigned long rate);
 #endif
diff --git a/arch/arm/kernel/sched_clock.c b/arch/arm/kernel/sched_clock.c
index 29ac613..7875e9e 100644
--- a/arch/arm/kernel/sched_clock.c
+++ b/arch/arm/kernel/sched_clock.c
@@ -44,6 +44,7 @@ static u32 notrace jiffy_sched_clock_read(void)
 }
 
 static u32 __read_mostly (*read_sched_clock)(void) = jiffy_sched_clock_read;
+static u64 __read_mostly (*read_sched_clock_64)(void);
 
 static inline u64 cyc_to_ns(u64 cyc, u32 mult, u32 shift)
 {
@@ -104,24 +105,12 @@ static void sched_clock_poll(unsigned long wrap_ticks)
 	update_sched_clock();
 }
 
-void __init setup_sched_clock(u32 (*read)(void), int bits, unsigned long rate)
+static u64 __init sched_clock_calc_wrap(int bits, unsigned long rate)
 {
-	unsigned long r, w;
+	unsigned long r;
 	u64 res, wrap;
 	char r_unit;
 
-	if (cd.rate > rate)
-		return;
-
-	BUG_ON(bits > 32);
-	WARN_ON(!irqs_disabled());
-	read_sched_clock = read;
-	sched_clock_mask = (1 << bits) - 1;
-	cd.rate = rate;
-
-	/* calculate the mult/shift to convert counter ticks to ns. */
-	clocks_calc_mult_shift(&cd.mult, &cd.shift, rate, NSEC_PER_SEC, 0);
-
 	r = rate;
 	if (r >= 4000000) {
 		r /= 1000000;
@@ -135,12 +124,39 @@ void __init setup_sched_clock(u32 (*read)(void), int bits, unsigned long rate)
 	/* calculate how many ns until we wrap */
 	wrap = cyc_to_ns((1ULL << bits) - 1, cd.mult, cd.shift);
 	do_div(wrap, NSEC_PER_MSEC);
-	w = wrap;
 
 	/* calculate the ns resolution of this counter */
 	res = cyc_to_ns(1ULL, cd.mult, cd.shift);
-	pr_info("sched_clock: %u bits at %lu%cHz, resolution %lluns, wraps every %lums\n",
-		bits, r, r_unit, res, w);
+	pr_info("sched_clock: %u bits at %lu%cHz, resolution %lluns, wraps every %llums\n",
+		bits, r, r_unit, res, wrap);
+
+	return wrap;
+}
+
+static void __init try_to_enable_irqtime(unsigned long rate)
+{
+	/* Enable IRQ time accounting if we have a fast enough sched_clock */
+	if (irqtime > 0 || (irqtime == -1 && rate >= 1000000))
+		enable_sched_clock_irqtime();
+}
+
+void __init setup_sched_clock(u32 (*read)(void), int bits, unsigned long rate)
+{
+	unsigned long w;
+
+	if (cd.rate > rate)
+		return;
+
+	BUG_ON(bits > 32);
+	WARN_ON(!irqs_disabled());
+	read_sched_clock = read;
+	sched_clock_mask = (1 << bits) - 1;
+	cd.rate = rate;
+
+	/* calculate the mult/shift to convert counter ticks to ns. */
+	clocks_calc_mult_shift(&cd.mult, &cd.shift, rate, NSEC_PER_SEC, 0);
+
+	w = sched_clock_calc_wrap(bits, rate);
 
 	/*
 	 * Start the timer to keep sched_clock() properly updated and
@@ -154,9 +170,7 @@ void __init setup_sched_clock(u32 (*read)(void), int bits, unsigned long rate)
 	 */
 	cd.epoch_ns = 0;
 
-	/* Enable IRQ time accounting if we have a fast enough sched_clock */
-	if (irqtime > 0 || (irqtime == -1 && rate >= 1000000))
-		enable_sched_clock_irqtime();
+	try_to_enable_irqtime(rate);
 
 	pr_debug("Registered %pF as sched_clock source\n", read);
 }
@@ -169,6 +183,32 @@ static unsigned long long notrace sched_clock_32(void)
 
 unsigned long long __read_mostly (*sched_clock_func)(void) = sched_clock_32;
 
+static unsigned long long notrace sched_clock_64(void)
+{
+	u64 cyc = read_sched_clock_64() - cd.epoch_ns;
+	return cyc * cd.mult;
+}
+
+void __init
+setup_sched_clock_64(u64 (*read)(void), int bits, unsigned long rate)
+{
+	if (cd.rate > rate)
+		return;
+
+	BUG_ON(bits <= 32);
+	WARN_ON(!irqs_disabled());
+	read_sched_clock_64 = read;
+	sched_clock_func = sched_clock_64;
+	cd.rate = rate;
+	cd.mult = NSEC_PER_SEC / rate;
+	cd.epoch_ns = read_sched_clock_64();
+
+	sched_clock_calc_wrap(bits, rate);
+
+	try_to_enable_irqtime(rate);
+	pr_debug("Registered %pF as %u bit sched_clock source\n", read, bits);
+}
+
 unsigned long long notrace sched_clock(void)
 {
 	if (cd.suspended)
@@ -181,25 +221,34 @@ void __init sched_clock_postinit(void)
 {
 	/*
 	 * If no sched_clock function has been provided at that point,
-	 * make it the final one one.
+	 * make it the final one.
 	 */
-	if (read_sched_clock == jiffy_sched_clock_read)
+	if (read_sched_clock == jiffy_sched_clock_read && !read_sched_clock_64)
 		setup_sched_clock(jiffy_sched_clock_read, 32, HZ);
 
-	sched_clock_poll(sched_clock_timer.data);
+	if (sched_clock_func == sched_clock_32)
+		sched_clock_poll(sched_clock_timer.data);
 }
 
 static int sched_clock_suspend(void)
 {
-	sched_clock_poll(sched_clock_timer.data);
+	if (sched_clock_func == sched_clock_32)
+		sched_clock_poll(sched_clock_timer.data);
+	else
+		cd.epoch_ns = read_sched_clock_64();
+
 	cd.suspended = true;
 	return 0;
 }
 
 static void sched_clock_resume(void)
 {
-	cd.epoch_cyc = read_sched_clock();
-	cd.epoch_cyc_copy = cd.epoch_cyc;
+	if (sched_clock_func == sched_clock_32) {
+		cd.epoch_cyc = read_sched_clock();
+		cd.epoch_cyc_copy = cd.epoch_cyc;
+	} else {
+		cd.epoch_ns += read_sched_clock_64() - cd.epoch_ns;
+	}
 	cd.suspended = false;
 }
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Fri Apr 19 20:29:02 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Fri, 19 Apr 2013 17:29:02 -0700
Subject: [PATCH 0/4] ARM 64 bit sched_clock take #2
In-Reply-To: <51709FD7.8050408@gmail.com>
References: <51709FD7.8050408@gmail.com>
Message-ID: <1366417746-24990-1-git-send-email-sboyd@codeaurora.org>

This is what I was thinking. I don't see why we can't move this to generic code and have arm64 use it too. Those patches will follow once I find an arm64
compiler.

First two patches should probably go in even if the 64 bit stuff doesn't go in
at the same time.

Stephen Boyd (4):
  ARM: sched_clock: Remove unused needs_suspend member
  ARM: sched_clock: Return suspended count earlier
  ARM: sched_clock: Add support for >32 bit sched_clock
  ARM: arch_timer: Move to setup_sched_clock_64()

 arch/arm/include/asm/sched_clock.h |   5 +-
 arch/arm/kernel/arch_timer.c       |  14 +----
 arch/arm/kernel/sched_clock.c      | 111 ++++++++++++++++++++++++++-----------
 3 files changed, 84 insertions(+), 46 deletions(-)

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Fri Apr 19 20:29:03 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Fri, 19 Apr 2013 17:29:03 -0700
Subject: [PATCH 1/4] ARM: sched_clock: Remove unused needs_suspend member
In-Reply-To: <1366417746-24990-1-git-send-email-sboyd@codeaurora.org>
References: <1366417746-24990-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1366417746-24990-2-git-send-email-sboyd@codeaurora.org>

The needs_suspend member is unused now that we always do the
suspend/resume handling (see 6a4dae5 (ARM: 7565/1: sched: stop
sched_clock() during suspend, 2012-10-23)).

Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 arch/arm/kernel/sched_clock.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/kernel/sched_clock.c b/arch/arm/kernel/sched_clock.c
index 8805848..48ab64a 100644
--- a/arch/arm/kernel/sched_clock.c
+++ b/arch/arm/kernel/sched_clock.c
@@ -24,7 +24,6 @@ struct clock_data {
 	u32 mult;
 	u32 shift;
 	bool suspended;
-	bool needs_suspend;
 };
 
 static void sched_clock_poll(unsigned long wrap_ticks);
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Fri Apr 19 20:29:04 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Fri, 19 Apr 2013 17:29:04 -0700
Subject: [PATCH 2/4] ARM: sched_clock: Return suspended count earlier
In-Reply-To: <1366417746-24990-1-git-send-email-sboyd@codeaurora.org>
References: <1366417746-24990-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1366417746-24990-3-git-send-email-sboyd@codeaurora.org>

If we're suspended and sched_clock() is called we're going to
read the hardware one more time and throw away that value and
return back the cached value we saved during the suspend
callback. This is wasteful, let's short circuit all that and
return the cached value if we're suspended as early as possible.

Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 arch/arm/kernel/sched_clock.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/kernel/sched_clock.c b/arch/arm/kernel/sched_clock.c
index 48ab64a..29ac613 100644
--- a/arch/arm/kernel/sched_clock.c
+++ b/arch/arm/kernel/sched_clock.c
@@ -55,9 +55,6 @@ static unsigned long long cyc_to_sched_clock(u32 cyc, u32 mask)
 	u64 epoch_ns;
 	u32 epoch_cyc;
 
-	if (cd.suspended)
-		return cd.epoch_ns;
-
 	/*
 	 * Load the epoch_cyc and epoch_ns atomically.  We do this by
 	 * ensuring that we always write epoch_cyc, epoch_ns and
@@ -174,6 +171,9 @@ unsigned long long __read_mostly (*sched_clock_func)(void) = sched_clock_32;
 
 unsigned long long notrace sched_clock(void)
 {
+	if (cd.suspended)
+		return cd.epoch_ns;
+
 	return sched_clock_func();
 }
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Fri Apr 19 20:29:06 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Fri, 19 Apr 2013 17:29:06 -0700
Subject: [PATCH 4/4] ARM: arch_timer: Move to setup_sched_clock_64()
In-Reply-To: <1366417746-24990-1-git-send-email-sboyd@codeaurora.org>
References: <1366417746-24990-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1366417746-24990-5-git-send-email-sboyd@codeaurora.org>

Register with the ARM sched_clock framework now that it supports
64 bits. This also fixes two problems with the current sched_clock
support for machines using the archited timers. First off, we
don't subtract the start value from subsequent sched_clock calls
so we can potentially start off with sched_clock returning
gigantic numbers. Second, there is no support for suspend/resume
handling so problems such as discussed in 6a4dae5 (ARM: 7565/1:
sched: stop sched_clock() during suspend, 2012-10-23) can happen.

Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 arch/arm/include/asm/sched_clock.h |  3 ---
 arch/arm/kernel/arch_timer.c       | 14 ++------------
 arch/arm/kernel/sched_clock.c      |  3 ++-
 3 files changed, 4 insertions(+), 16 deletions(-)

diff --git a/arch/arm/include/asm/sched_clock.h b/arch/arm/include/asm/sched_clock.h
index 7fcd2ee..e6f765a 100644
--- a/arch/arm/include/asm/sched_clock.h
+++ b/arch/arm/include/asm/sched_clock.h
@@ -10,9 +10,6 @@
 
 extern void sched_clock_postinit(void);
 extern void setup_sched_clock(u32 (*read)(void), int bits, unsigned long rate);
-
-extern unsigned long long (*sched_clock_func)(void);
-
 extern void setup_sched_clock_64(u64 (*read)(void), int bits,
 				 unsigned long rate);
 #endif
diff --git a/arch/arm/kernel/arch_timer.c b/arch/arm/kernel/arch_timer.c
index 59dcdce..b45250b 100644
--- a/arch/arm/kernel/arch_timer.c
+++ b/arch/arm/kernel/arch_timer.c
@@ -22,13 +22,6 @@ static unsigned long arch_timer_read_counter_long(void)
 	return arch_timer_read_counter();
 }
 
-static u32 sched_clock_mult __read_mostly;
-
-static unsigned long long notrace arch_timer_sched_clock(void)
-{
-	return arch_timer_read_counter() * sched_clock_mult;
-}
-
 static struct delay_timer arch_delay_timer;
 
 static void __init arch_timer_delay_timer_register(void)
@@ -48,11 +41,8 @@ int __init arch_timer_arch_init(void)
 
 	arch_timer_delay_timer_register();
 
-	/* Cache the sched_clock multiplier to save a divide in the hot path. */
-	sched_clock_mult = NSEC_PER_SEC / arch_timer_rate;
-	sched_clock_func = arch_timer_sched_clock;
-	pr_info("sched_clock: ARM arch timer >56 bits at %ukHz, resolution %uns\n",
-		arch_timer_rate / 1000, sched_clock_mult);
+	/* 56 bits minimum, so we assume worst case rollover */
+	setup_sched_clock_64(arch_timer_read_counter, 56, arch_timer_rate);
 
 	return 0;
 }
diff --git a/arch/arm/kernel/sched_clock.c b/arch/arm/kernel/sched_clock.c
index 7875e9e..b6067d8 100644
--- a/arch/arm/kernel/sched_clock.c
+++ b/arch/arm/kernel/sched_clock.c
@@ -181,7 +181,8 @@ static unsigned long long notrace sched_clock_32(void)
 	return cyc_to_sched_clock(cyc, sched_clock_mask);
 }
 
-unsigned long long __read_mostly (*sched_clock_func)(void) = sched_clock_32;
+static unsigned long long __read_mostly
+(*sched_clock_func)(void) = sched_clock_32;
 
 static unsigned long long notrace sched_clock_64(void)
 {
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From gang.chen at asianux.com  Fri Apr 19 21:54:01 2013
From: gang.chen at asianux.com (Chen Gang)
Date: Sat, 20 Apr 2013 09:54:01 +0800
Subject: [PATCH] ARM64: kernel: compiling issue: need define readq and
 writeq for driver module using.
In-Reply-To: <20130419123513.GB18443@arm.com>
References: <51712975.8030104@asianux.com> <20130419123513.GB18443@arm.com>
Message-ID: <5171F539.90604@asianux.com>

On 2013?04?19? 20:35, Catalin Marinas wrote:
> On Fri, Apr 19, 2013 at 12:24:37PM +0100, Chen Gang wrote:
>> > 
>> >   when compiling with allmodconfig, CONFIG_64BIT=y
>> >     the file drivers/base/regmap/regmap-mmio.c will use readq and writeq.
>> > 
>> >   so we need implement these functions.
>> > 
>> > BTW:
>> >   the coding style can not pass ./scripts/checkpatch.pl.
>> >   it seems better to provide additional patch for beautifying code.
> If it complains about long lines, just ignore it. I wouldn't worry too
> much about checkpatch.pl and coding style warnings ;)
> 

  ok, I can understand.

  :-)

-- 
Chen Gang

Asianux Corporation


From gang.chen at asianux.com  Fri Apr 19 21:54:39 2013
From: gang.chen at asianux.com (Chen Gang)
Date: Sat, 20 Apr 2013 09:54:39 +0800
Subject: [PATCH] ARM64: kernel: compiling issue, duplicate definition
 of early_console
In-Reply-To: <20130419123150.GA18443@arm.com>
References: <5152DB83.8080703@asianux.com>
 <20130327115509.GA1603@MacBook-Pro.local> <5152DFF1.2090000@asianux.com>
 <515BE49C.8040601@asianux.com> <515C14FD.4040703@codeaurora.org>
 <515C2808.70406@asianux.com> <516E66F9.9070904@asianux.com>
 <51712213.4060607@asianux.com> <20130419123150.GA18443@arm.com>
Message-ID: <5171F55F.5080501@asianux.com>

On 2013?04?19? 20:31, Catalin Marinas wrote:
> On Fri, Apr 19, 2013 at 11:53:07AM +0100, Chen Gang wrote:
>>   when compiling with allmodconfig.
>>     early_console is already defined as an extern global pointer.
>>
>>   need let it point to the object which we intend to (like ARM32 done).
>>
>>
>> Signed-off-by: Chen Gang <gang.chen at asianux.com>
> 
> Thanks for the patch.
> 

  :-)

-- 
Chen Gang

Asianux Corporation


From gang.chen at asianux.com  Fri Apr 19 21:55:07 2013
From: gang.chen at asianux.com (Chen Gang)
Date: Sat, 20 Apr 2013 09:55:07 +0800
Subject: [PATCH] ARM64: kernel: compiling issue, duplicate definition
 of early_console
In-Reply-To: <201304191415.31986.arnd@arndb.de>
References: <5152DB83.8080703@asianux.com> <516E66F9.9070904@asianux.com>
 <51712213.4060607@asianux.com> <201304191415.31986.arnd@arndb.de>
Message-ID: <5171F57B.7090305@asianux.com>

On 2013?04?19? 20:15, Arnd Bergmann wrote:
> On Friday 19 April 2013, Chen Gang wrote:
>> >   when compiling with allmodconfig.
>> >     early_console is already defined as an extern global pointer.
>> > 
>> >   need let it point to the object which we intend to (like ARM32 done).
>> > 
>> > 
>> > Signed-off-by: Chen Gang <gang.chen at asianux.com>
> Acked-by: Arnd Bergmann <arnd at arndb.de>
> 
> 

  thanks

-- 
Chen Gang

Asianux Corporation


From gang.chen at asianux.com  Fri Apr 19 22:28:55 2013
From: gang.chen at asianux.com (Chen Gang)
Date: Sat, 20 Apr 2013 10:28:55 +0800
Subject: [Suggestion] ARM64: kernel: compiling issue,
 need implement cmpxchg64 with assembler language.
In-Reply-To: <201304191412.54601.arnd@arndb.de>
References: <51712E5E.2020809@asianux.com> <201304191412.54601.arnd@arndb.de>
Message-ID: <5171FD67.2080104@asianux.com>

On 2013?04?19? 20:12, Arnd Bergmann wrote:
> On Friday 19 April 2013, Chen Gang wrote:
>> in arch/arm64/include/asm, not define the function cmpxchg64
>>
>>   when compiling with allmodconfig,
>>     drivers/block/blockconsole.c will need this function.
>>
>>   I am not quite familiar with ARM64 (neither ARM64 assembler)
>>
>>   can any member helps to send related patch ?
>>     if no one have time to send related patch, I should try.
>>     and I am glad to try, but need additional time resources,
>>     if I try, I should finish it within this month (2013-4-30).
>>
>>   welcome any suggestions or completions.
> 
> cmpxchg64 is the same as cmpxchg on 64-bit platforms, can't the
> driver be changed to use the latter?
> 
> 	Arnd
> 
> 

  can we be sure that cmpxchg64 is equal to cmpchg on all 64-bit platforms ?
    (I guess, the driver may need cross multiple platforms)
    (it seems, under x86, s390, better use cmpxchg64, at least they define it).

  whether we can be sure or not,
    I still prefer to define the macro cmpxchg64 just the alias of cmpxchg.
      (and I also guess ARM64 is always on 64-bit platform)

  the related patch may be like below.

-------------------------------patch begin--------------------------------------

diff --git a/arch/arm64/include/asm/cmpxchg.h b/arch/arm64/include/asm/cmpxchg.h
index 968b5cb..b572d2b 100644
--- a/arch/arm64/include/asm/cmpxchg.h
+++ b/arch/arm64/include/asm/cmpxchg.h
@@ -170,4 +170,6 @@ static inline unsigned long __cmpxchg_mb(volatile void *ptr, unsigned long old,
 				       (unsigned long)(n),		\
 				       sizeof(*(ptr))))
 
+#define cmpxchg64(ptr,o,n)	cmpxchg((ptr),(o),(n))
+
 #endif	/* __ASM_CMPXCHG_H */

-------------------------------patch end----------------------------------------



  I think, we can also reference the implementation of s390:
    it is in arch/s390/include/asm/cmpxchg.h.
    since we are ARM64, excluding ARM(32,16...), we can only consider 64-bit.
    if in the future, ARM64 and ARM are merged together:
      we can use CONFIG_64BIT to switch the cmpxchg64 definition.
      if define CONFIG_64BIT, use cmpxchg instead of cmpxchg64.
      else, use the definition of ARM (arch/arm/include/asm/cmpxchg.h already defines cmpxchg64)

-------------------------------reference begin----------------------------------

#ifdef CONFIG_64BIT
#define cmpxchg64(ptr, o, n)						\
({									\
	cmpxchg((ptr), (o), (n));					\
})
#else /* CONFIG_64BIT */
...
-------------------------------reference end------------------------------------

  :-)

-- 
Chen Gang

Asianux Corporation


From chen.gang.flying.transformer at gmail.com  Fri Apr 19 22:48:40 2013
From: chen.gang.flying.transformer at gmail.com (Chen Gang F T)
Date: Sat, 20 Apr 2013 10:48:40 +0800
Subject: [PATCH] ARM64: kernel: compiling issue: need define readq and
 writeq for driver module using.
In-Reply-To: <201304191413.57424.arnd@arndb.de>
References: <51712975.8030104@asianux.com> <201304191413.57424.arnd@arndb.de>
Message-ID: <51720208.3090605@gmail.com>

On 2013?04?19? 20:13, Arnd Bergmann wrote:
> On Friday 19 April 2013, Chen Gang wrote:
>> >   when compiling with allmodconfig, CONFIG_64BIT=y
>> >     the file drivers/base/regmap/regmap-mmio.c will use readq and writeq.
>> > 
>> >   so we need implement these functions.
>> > 
>> > BTW:
>> >   the coding style can not pass ./scripts/checkpatch.pl.
>> >   it seems better to provide additional patch for beautifying code.
>> > 
>> > Signed-off-by: Chen Gang <gang.chen at asianux.com>
> Acked-by: Arnd Bergmann <arnd at arndb.de>

  thanks.

-- 
Chen Gang

Flying Transformer


From vkale at apm.com  Sat Apr 20 03:15:27 2013
From: vkale at apm.com (Vinayak Kale)
Date: Sat, 20 Apr 2013 12:45:27 +0530
Subject: [PATCH 0/4] arm64: Initial patch-set for APM X-Gene SOC family
Message-ID: <1366442131-26094-1-git-send-email-vkale@apm.com>

These are initial patches for APM X-Gene SOC family.
This patch-set is based on soc-armv8-model branch of git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch64.git

Vinayak Kale (4):
  arm64: Add Kconfig option for APM X-Gene SOC family
  arm64: Initial defconfig for APM X-Gene SOC family
  arm64: Add defines for APM ARMv8 implementation
  arm64: Add initial DTS for APM X-Gene Storm SOC and APM Mustang board

 arch/arm64/Kconfig                 |    5 ++
 arch/arm64/boot/dts/Makefile       |    1 +
 arch/arm64/boot/dts/mustang.dts    |   28 +++++++++
 arch/arm64/boot/dts/storm.dtsi     |  116 ++++++++++++++++++++++++++++++++++++
 arch/arm64/configs/xgene_defconfig |   93 +++++++++++++++++++++++++++++
 arch/arm64/include/asm/cputype.h   |    3 +
 6 files changed, 246 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm64/boot/dts/mustang.dts
 create mode 100644 arch/arm64/boot/dts/storm.dtsi
 create mode 100644 arch/arm64/configs/xgene_defconfig

-- 
1.7.4.1



From vkale at apm.com  Sat Apr 20 03:15:29 2013
From: vkale at apm.com (Vinayak Kale)
Date: Sat, 20 Apr 2013 12:45:29 +0530
Subject: [PATCH 2/4] arm64: Initial defconfig for APM X-Gene SOC family
In-Reply-To: <1366442131-26094-1-git-send-email-vkale@apm.com>
References: <1366442131-26094-1-git-send-email-vkale@apm.com>
Message-ID: <1366442131-26094-3-git-send-email-vkale@apm.com>

This patch adds initial defconfig for APM X-Gene SOC family.

Signed-off-by: Kumar Sankaran <ksankaran at apm.com>
Signed-off-by: Loc Ho <lho at apm.com>
Signed-off-by: Feng Kan <fkan at apm.com>
---
 arch/arm64/configs/xgene_defconfig |   93 ++++++++++++++++++++++++++++++++++++
 1 files changed, 93 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm64/configs/xgene_defconfig

diff --git a/arch/arm64/configs/xgene_defconfig b/arch/arm64/configs/xgene_defconfig
new file mode 100644
index 0000000..4c6aefc
--- /dev/null
+++ b/arch/arm64/configs/xgene_defconfig
@@ -0,0 +1,93 @@
+# CONFIG_LOCALVERSION_AUTO is not set
+# CONFIG_SWAP is not set
+CONFIG_SYSVIPC=y
+CONFIG_POSIX_MQUEUE=y
+CONFIG_NO_HZ=y
+CONFIG_HIGH_RES_TIMERS=y
+CONFIG_BSD_PROCESS_ACCT=y
+CONFIG_BSD_PROCESS_ACCT_V3=y
+CONFIG_IKCONFIG=y
+CONFIG_IKCONFIG_PROC=y
+CONFIG_LOG_BUF_SHIFT=14
+# CONFIG_UTS_NS is not set
+# CONFIG_IPC_NS is not set
+# CONFIG_PID_NS is not set
+# CONFIG_NET_NS is not set
+CONFIG_SCHED_AUTOGROUP=y
+CONFIG_BLK_DEV_INITRD=y
+CONFIG_KALLSYMS_ALL=y
+# CONFIG_COMPAT_BRK is not set
+CONFIG_PROFILING=y
+CONFIG_MODULES=y
+CONFIG_MODULE_UNLOAD=y
+# CONFIG_BLK_DEV_BSG is not set
+# CONFIG_IOSCHED_DEADLINE is not set
+CONFIG_ARCH_XGENE=y
+CONFIG_SMP=y
+CONFIG_NR_CPUS=8
+CONFIG_PREEMPT_VOLUNTARY=y
+CONFIG_CMDLINE="console=ttyAMA0"
+# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
+CONFIG_COMPAT=y
+CONFIG_NET=y
+CONFIG_PACKET=y
+CONFIG_UNIX=y
+CONFIG_INET=y
+CONFIG_IP_PNP=y
+CONFIG_IP_PNP_DHCP=y
+CONFIG_IP_PNP_BOOTP=y
+# CONFIG_INET_LRO is not set
+# CONFIG_IPV6 is not set
+# CONFIG_WIRELESS is not set
+CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
+CONFIG_DEVTMPFS=y
+# CONFIG_BLK_DEV is not set
+CONFIG_SCSI=y
+# CONFIG_SCSI_PROC_FS is not set
+CONFIG_BLK_DEV_SD=y
+# CONFIG_SCSI_LOWLEVEL is not set
+CONFIG_NETDEVICES=y
+# CONFIG_NET_CADENCE is not set
+CONFIG_SMC91X=y
+# CONFIG_WLAN is not set
+CONFIG_INPUT_EVDEV=y
+# CONFIG_SERIO_I8042 is not set
+# CONFIG_SERIO_SERPORT is not set
+CONFIG_SERIO_AMBAKMI=y
+CONFIG_LEGACY_PTY_COUNT=16
+CONFIG_SERIAL_8250=y
+CONFIG_SERIAL_8250_CONSOLE=y
+CONFIG_SERIAL_OF_PLATFORM=y
+# CONFIG_HW_RANDOM is not set
+CONFIG_GPIOLIB=y
+# CONFIG_HWMON is not set
+CONFIG_FB=y
+CONFIG_FB_ARMCLCD=y
+# CONFIG_VGA_CONSOLE is not set
+CONFIG_FRAMEBUFFER_CONSOLE=y
+CONFIG_LOGO=y
+# CONFIG_LOGO_LINUX_MONO is not set
+# CONFIG_LOGO_LINUX_VGA16 is not set
+# CONFIG_USB_SUPPORT is not set
+# CONFIG_IOMMU_SUPPORT is not set
+CONFIG_EXT2_FS=y
+CONFIG_EXT3_FS=y
+# CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set
+# CONFIG_EXT3_FS_XATTR is not set
+CONFIG_FUSE_FS=y
+CONFIG_CUSE=y
+CONFIG_VFAT_FS=y
+CONFIG_TMPFS=y
+# CONFIG_MISC_FILESYSTEMS is not set
+CONFIG_NFS_FS=y
+CONFIG_ROOT_NFS=y
+CONFIG_NLS_CODEPAGE_437=y
+CONFIG_NLS_ISO8859_1=y
+CONFIG_MAGIC_SYSRQ=y
+CONFIG_DEBUG_FS=y
+CONFIG_DEBUG_KERNEL=y
+# CONFIG_SCHED_DEBUG is not set
+CONFIG_DEBUG_INFO=y
+CONFIG_RCU_CPU_STALL_TIMEOUT=60
+# CONFIG_FTRACE is not set
+CONFIG_ATOMIC64_SELFTEST=y
-- 
1.7.4.1



From vkale at apm.com  Sat Apr 20 03:15:28 2013
From: vkale at apm.com (Vinayak Kale)
Date: Sat, 20 Apr 2013 12:45:28 +0530
Subject: [PATCH 1/4] arm64: Add Kconfig option for APM X-Gene SOC family
In-Reply-To: <1366442131-26094-1-git-send-email-vkale@apm.com>
References: <1366442131-26094-1-git-send-email-vkale@apm.com>
Message-ID: <1366442131-26094-2-git-send-email-vkale@apm.com>

This patch adds arm64/Kconfig option for APM X-Gene SOC family.

Signed-off-by: Kumar Sankaran <ksankaran at apm.com>
Signed-off-by: Loc Ho <lho at apm.com>
Signed-off-by: Feng Kan <fkan at apm.com>
---
 arch/arm64/Kconfig |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 43b0e9f..5b8f113 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -114,6 +114,11 @@ config ARCH_VEXPRESS
 	  This enables support for the ARMv8 software model (Versatile
 	  Express).
 
+config ARCH_XGENE
+	bool "AppliedMicro X-Gene SOC Family"
+	help
+	  This enables support for AppliedMicro X-Gene SOC Family
+
 endmenu
 
 menu "Bus support"
-- 
1.7.4.1



From vkale at apm.com  Sat Apr 20 03:15:30 2013
From: vkale at apm.com (Vinayak Kale)
Date: Sat, 20 Apr 2013 12:45:30 +0530
Subject: [PATCH 3/4] arm64: Add defines for APM ARMv8 implementation
In-Reply-To: <1366442131-26094-1-git-send-email-vkale@apm.com>
References: <1366442131-26094-1-git-send-email-vkale@apm.com>
Message-ID: <1366442131-26094-4-git-send-email-vkale@apm.com>

This patch adds defines for APM CPU implementer ID and APM CPU part numbers in asm/cputype.h

Signed-off-by: Kumar Sankaran <ksankaran at apm.com>
Signed-off-by: Loc Ho <lho at apm.com>
Signed-off-by: Feng Kan <fkan at apm.com>
---
 arch/arm64/include/asm/cputype.h |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h
index cf27494..5fe138e 100644
--- a/arch/arm64/include/asm/cputype.h
+++ b/arch/arm64/include/asm/cputype.h
@@ -37,11 +37,14 @@
 })
 
 #define ARM_CPU_IMP_ARM		0x41
+#define ARM_CPU_IMP_APM		0x50
 
 #define ARM_CPU_PART_AEM_V8	0xD0F0
 #define ARM_CPU_PART_FOUNDATION	0xD000
 #define ARM_CPU_PART_CORTEX_A57	0xD070
 
+#define APM_CPU_PART_POTENZA	0x0000
+
 #ifndef __ASSEMBLY__
 
 /*
-- 
1.7.4.1



From vkale at apm.com  Sat Apr 20 03:15:31 2013
From: vkale at apm.com (Vinayak Kale)
Date: Sat, 20 Apr 2013 12:45:31 +0530
Subject: [PATCH 4/4] arm64: Add initial DTS for APM X-Gene Storm SOC and APM
 Mustang board
In-Reply-To: <1366442131-26094-1-git-send-email-vkale@apm.com>
References: <1366442131-26094-1-git-send-email-vkale@apm.com>
Message-ID: <1366442131-26094-5-git-send-email-vkale@apm.com>

This patch adds initial DTS files required for APM Mustang board.

Signed-off-by: Kumar Sankaran <ksankaran at apm.com>
Signed-off-by: Loc Ho <lho at apm.com>
Signed-off-by: Feng Kan <fkan at apm.com>
---
 arch/arm64/boot/dts/Makefile    |    1 +
 arch/arm64/boot/dts/mustang.dts |   28 +++++++++
 arch/arm64/boot/dts/storm.dtsi  |  116 +++++++++++++++++++++++++++++++++++++++
 3 files changed, 145 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm64/boot/dts/mustang.dts
 create mode 100644 arch/arm64/boot/dts/storm.dtsi

diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
index 68457e9..faeab34 100644
--- a/arch/arm64/boot/dts/Makefile
+++ b/arch/arm64/boot/dts/Makefile
@@ -1,4 +1,5 @@
 dtb-$(CONFIG_ARCH_VEXPRESS) += rtsm_ve-aemv8a.dtb foundation-v8.dtb
+dtb-$(CONFIG_ARCH_XGENE) += mustang.dtb
 
 targets += dtbs
 targets += $(dtb-y)
diff --git a/arch/arm64/boot/dts/mustang.dts b/arch/arm64/boot/dts/mustang.dts
new file mode 100644
index 0000000..a061c99
--- /dev/null
+++ b/arch/arm64/boot/dts/mustang.dts
@@ -0,0 +1,28 @@
+/*
+ * dts file for AppliedMicro (APM) Mustang Board
+ *
+ * Copyright (C) 2013, Applied Micro Circuits Corporation
+ *
+ * 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/ "storm.dtsi"
+
+/ {
+	model = "mustang";
+
+	/* chosen */
+	chosen {
+		linux,stdout-path = &serial0;
+	};
+
+	memory {
+		device_type = "memory";
+		reg = < 0x1 0x00000000 0x0 0x80000000 >; /* Updated by bootloader */
+	};
+};
diff --git a/arch/arm64/boot/dts/storm.dtsi b/arch/arm64/boot/dts/storm.dtsi
new file mode 100644
index 0000000..8cab5d1
--- /dev/null
+++ b/arch/arm64/boot/dts/storm.dtsi
@@ -0,0 +1,116 @@
+/*
+ * dts file for AppliedMicro (APM) X-Gene Storm SOC
+ *
+ * Copyright (C) 2013, Applied Micro Circuits Corporation
+ *
+ * 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.
+ */
+
+/ {
+	compatible = "apm,xgene,storm", "apm,xgene";
+	interrupt-parent = <&gic>;
+	#address-cells = <2>;
+	#size-cells = <2>;
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		cpu at 0 {
+			device_type = "cpu";
+			compatible = "arm,armv8";
+			reg = <0x0 0x0000>;
+			enable-method = "spin-table";
+			cpu-release-addr = <0x1 0x0000fff8>;
+		};
+		cpu at 1 {
+			device_type = "cpu";
+			compatible = "arm,armv8";
+			reg = <0x0 0x0001>;
+			enable-method = "spin-table";
+			cpu-release-addr = <0x1 0x0000fff8>;
+		};
+		cpu at 2 {
+			device_type = "cpu";
+			compatible = "arm,armv8";
+			reg = <0x0 0x0100>;
+			enable-method = "spin-table";
+			cpu-release-addr = <0x1 0x0000fff8>;
+		};
+		cpu at 3 {
+			device_type = "cpu";
+			compatible = "arm,armv8";
+			reg = <0x0 0x0101>;
+			enable-method = "spin-table";
+			cpu-release-addr = <0x1 0x0000fff8>;
+		};
+		cpu at 4 {
+			device_type = "cpu";
+			compatible = "arm,armv8";
+			reg = <0x0 0x0200>;
+			enable-method = "spin-table";
+			cpu-release-addr = <0x1 0x0000fff8>;
+		};
+		cpu at 5 {
+			device_type = "cpu";
+			compatible = "arm,armv8";
+			reg = <0x0 0x0201>;
+			enable-method = "spin-table";
+			cpu-release-addr = <0x1 0x0000fff8>;
+		};
+		cpu at 6 {
+			device_type = "cpu";
+			compatible = "arm,armv8";
+			reg = <0x0 0x0300>;
+			enable-method = "spin-table";
+			cpu-release-addr = <0x1 0x0000fff8>;
+		};
+		cpu at 7 {
+			device_type = "cpu";
+			compatible = "arm,armv8";
+			reg = <0x0 0x0301>;
+			enable-method = "spin-table";
+			cpu-release-addr = <0x1 0x0000fff8>;
+		};
+	};
+
+	gic: interrupt-controller at 78010000 {
+		compatible = "arm,cortex-a15-gic", "arm,cortex-a9-gic";
+		#interrupt-cells = <3>;
+		interrupt-controller;
+		reg = <0x0 0x78010000 0x0 0x1000>,	/* GIC Dist */
+		      <0x0 0x78020000 0x0 0x1000>,	/* GIC CPU */
+		      <0x0 0x78040000 0x0 0x2000>,	/* GIC VCPU Control */
+		      <0x0 0x78060000 0x0 0x2000>;	/* GIC VCPU */
+		interrupts = <1 9 0xf04>;	/* GIC Maintenence IRQ */
+	};
+
+	timer {
+		compatible = "arm,armv8-timer";
+		interrupts = <1 0 0xff01>,	/* Secure Phys IRQ */
+			     <1 13 0xff01>,	/* Non-secure Phys IRQ */
+			     <1 14 0xff01>,	/* Virt IRQ */
+			     <1 15 0xff01>;	/* Hyp IRQ */
+		clock-frequency = <50000000>;
+	};
+
+	soc {
+		compatible = "simple-bus";
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
+
+		serial0: uart0 at 1c020000 {
+			device_type = "serial";
+			compatible = "ns16550";
+			reg = <0 0x1c020000 0x0 0x1000>;
+			reg-shift = <2>;
+			clock-frequency = <10000000>; /* Updated by bootloader */
+			interrupt-parent = <&gic>;
+			interrupts = <0x0 0x4c 0x4>;
+		};
+	};
+};
-- 
1.7.4.1



From arnd at arndb.de  Sat Apr 20 03:32:02 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Sat, 20 Apr 2013 09:32:02 +0200
Subject: [Suggestion] ARM64: kernel: compiling issue,
 need implement cmpxchg64 with assembler language.
In-Reply-To: <5171FD67.2080104@asianux.com>
References: <51712E5E.2020809@asianux.com> <201304191412.54601.arnd@arndb.de>
 <5171FD67.2080104@asianux.com>
Message-ID: <2182812.ymprEm6XBb@wuerfel>

On Saturday 20 April 2013 10:28:55 Chen Gang wrote:
> 
> -------------------------------patch begin--------------------------------------
> 
> diff --git a/arch/arm64/include/asm/cmpxchg.h b/arch/arm64/include/asm/cmpxchg.h
> index 968b5cb..b572d2b 100644
> --- a/arch/arm64/include/asm/cmpxchg.h
> +++ b/arch/arm64/include/asm/cmpxchg.h
> @@ -170,4 +170,6 @@ static inline unsigned long __cmpxchg_mb(volatile void *ptr, unsigned long old,
>                                        (unsigned long)(n),              \
>                                        sizeof(*(ptr))))
>  
> +#define cmpxchg64(ptr,o,n)     cmpxchg((ptr),(o),(n))
> +
>  #endif /* __ASM_CMPXCHG_H */

Yes, this looks good. Please provide the same for cmpxchg64_local.

> -------------------------------patch end----------------------------------------
> 
> 
> 
>   I think, we can also reference the implementation of s390:
>     it is in arch/s390/include/asm/cmpxchg.h.
>     since we are ARM64, excluding ARM(32,16...), we can only consider 64-bit.
>     if in the future, ARM64 and ARM are merged together:
>       we can use CONFIG_64BIT to switch the cmpxchg64 definition.
>       if define CONFIG_64BIT, use cmpxchg instead of cmpxchg64.
>       else, use the definition of ARM (arch/arm/include/asm/cmpxchg.h already defines cmpxchg64)

I would not worry aobut merging the two at the moment.

> -------------------------------reference begin----------------------------------
> 
> #ifdef CONFIG_64BIT
> #define cmpxchg64(ptr, o, n)                                            \
> ({                                                                      \
>         cmpxchg((ptr), (o), (n));                                       \
> })
> #else /* CONFIG_64BIT */
> ...
> -------------------------------reference end------------------------------------

This implementation in unnecessarily verbose, I think the one you have
above is nicer.

	Arnd


From arnd at arndb.de  Sat Apr 20 03:35:14 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Sat, 20 Apr 2013 09:35:14 +0200
Subject: [PATCH 2/4] arm64: Initial defconfig for APM X-Gene SOC family
In-Reply-To: <1366442131-26094-3-git-send-email-vkale@apm.com>
References: <1366442131-26094-1-git-send-email-vkale@apm.com>
 <1366442131-26094-3-git-send-email-vkale@apm.com>
Message-ID: <2165570.9Zy5vrhoIa@wuerfel>

On Saturday 20 April 2013 12:45:29 Vinayak Kale wrote:
> This patch adds initial defconfig for APM X-Gene SOC family.
> 
> Signed-off-by: Kumar Sankaran <ksankaran at apm.com>
> Signed-off-by: Loc Ho <lho at apm.com>
> Signed-off-by: Feng Kan <fkan at apm.com>
> ---
>  arch/arm64/configs/xgene_defconfig |   93 ++++++++++++++++++++++++++++++++++++
>  1 files changed, 93 insertions(+), 0 deletions(-)
>  create mode 100644 arch/arm64/configs/xgene_defconfig

Could you modify the regular defconfig to enable everything you need instead
of adding another one? Since all the code is interoperable, I think we
should not need a defconfig per soc.

	Arnd


From arnd at arndb.de  Sat Apr 20 03:39:54 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Sat, 20 Apr 2013 09:39:54 +0200
Subject: [PATCH 4/4] arm64: Add initial DTS for APM X-Gene Storm SOC and
 APM Mustang board
In-Reply-To: <1366442131-26094-5-git-send-email-vkale@apm.com>
References: <1366442131-26094-1-git-send-email-vkale@apm.com>
 <1366442131-26094-5-git-send-email-vkale@apm.com>
Message-ID: <4355208.ttMnntCBET@wuerfel>

On Saturday 20 April 2013 12:45:31 Vinayak Kale wrote:
> This patch adds initial DTS files required for APM Mustang board.
> 
> Signed-off-by: Kumar Sankaran <ksankaran at apm.com>
> Signed-off-by: Loc Ho <lho at apm.com>
> Signed-off-by: Feng Kan <fkan at apm.com>

Looks ok, just one comment

> +	soc {
> +		compatible = "simple-bus";
> +		#address-cells = <2>;
> +		#size-cells = <2>;
> +		ranges;
> +
> +		serial0: uart0 at 1c020000 {
> +			device_type = "serial";
> +			compatible = "ns16550";
> +			reg = <0 0x1c020000 0x0 0x1000>;
> +			reg-shift = <2>;
> +			clock-frequency = <10000000>; /* Updated by bootloader */
> +			interrupt-parent = <&gic>;
> +			interrupts = <0x0 0x4c 0x4>;
> +		};
> +	};
> +};

The standard name for the uart is "serial", not "uart0". Please never use
numbers in the name part of the device, the idea is that you have the
same name for each device of the same kind and ambiguate them by the
address part or using a label. If you have multiple uarts on the SoC,
I would also recommend listing all of them here, and marking them
as status="disabled", and then have an entry in the board specific
.dts file to mark the ones that are connected to the outside like

&serial0 {
	status = enabled;
};

	Arnd


From shc_work at mail.ru  Sat Apr 20 05:16:28 2013
From: shc_work at mail.ru (=?UTF-8?B?QWxleGFuZGVyIFNoaXlhbg==?=)
Date: Sat, 20 Apr 2013 13:16:28 +0400
Subject: =?UTF-8?B?UmVbMl06IFtQQVRDSCAxLzJdIEdQSU86IGNscHM3MTF4OiBSZXdyaXRlIGRy?=
 =?UTF-8?B?aXZlciBmb3IgdXNpbmcgZ2VuZXJpYyBHUElPIGNvZGU=?=
In-Reply-To: <20130419140357.GR14496@n2100.arm.linux.org.uk>
References: <1365826900-30136-1-git-send-email-shc_work@mail.ru>
 <20130419140357.GR14496@n2100.arm.linux.org.uk>
Message-ID: <1366449388.889617041@f101.mail.ru>

> On Sat, Apr 13, 2013 at 08:21:39AM +0400, Alexander Shiyan wrote:
> > +static void __init clps711x_add_gpio(void)
> > +{
> > +	const struct resource clps711x_gpio0_res[] = {
> > +		DEFINE_RES_MEM(PADR, SZ_1),
> > +		DEFINE_RES_MEM(PADDR, SZ_1),
> > +	};
...
> which will in itself be a call out to memcpy, or an inlined memcpy.  Now
> do you see why it's wasteful?  You might as well write the thing in that
> way to start with and safe the additional code to copy the structures.
> 
> The other way to do this, which will probably be far more space efficient:
> 
> static phys_addr_t gpio_addrs[][2] = {
> 	{ PADR, PADDR },
> 	{ PBDR, PBDDR },
> ...
> };
> 
> static void __init clps711x_add_gpio(void)
> {
> 	struct resource gpio_res[2];
> 	unsigned i;
> 
> 	gpio_res[0].flags = IORESOURCE_MEM;
> 	gpio_res[1].flags = IORESOURCE_MEM;
> 
> 	for (i = 0; i < ARRAY_SIZE(gpio_addrs); i++) {
> 		gpio_res[0].start = gpio_addrs[i][0];
> 		gpio_res[0].end = gpio_res[0].start;
> 		gpio_res[1].start = gpio_addrs[i][1];
> 		gpio_res[1].end = gpio_res[1].start;
> 
> 		platform_device_register_simple("clps711x-gpio", i,
> 					gpio_res, ARRAY_SIZE(gpio_res));
> 	}
> }
> 
> which results in smaller storage and most probably also smaller code size
> too.

Code size (.text) now is 200 bytes, instead of 576 bytes in my version.
I will use code which you suggest. Thanks.

---

From vkale at apm.com  Sat Apr 20 05:19:37 2013
From: vkale at apm.com (Vinayak Kale)
Date: Sat, 20 Apr 2013 14:49:37 +0530
Subject: [PATCH 4/4] arm64: Add initial DTS for APM X-Gene Storm SOC and
 APM Mustang board
In-Reply-To: <4355208.ttMnntCBET@wuerfel>
References: <1366442131-26094-1-git-send-email-vkale@apm.com>
 <1366442131-26094-5-git-send-email-vkale@apm.com>
 <4355208.ttMnntCBET@wuerfel>
Message-ID: <CAPrCYkcVUn7ZtUc1zc-Wq47q4OgaPvO9rNRkHgCxN+ea_ZjZqg@mail.gmail.com>

On Sat, Apr 20, 2013 at 1:09 PM, Arnd Bergmann <arnd at arndb.de> wrote:
> On Saturday 20 April 2013 12:45:31 Vinayak Kale wrote:
>> This patch adds initial DTS files required for APM Mustang board.
>>
>> Signed-off-by: Kumar Sankaran <ksankaran at apm.com>
>> Signed-off-by: Loc Ho <lho at apm.com>
>> Signed-off-by: Feng Kan <fkan at apm.com>
>
> Looks ok, just one comment
>
>> +     soc {
>> +             compatible = "simple-bus";
>> +             #address-cells = <2>;
>> +             #size-cells = <2>;
>> +             ranges;
>> +
>> +             serial0: uart0 at 1c020000 {
>> +                     device_type = "serial";
>> +                     compatible = "ns16550";
>> +                     reg = <0 0x1c020000 0x0 0x1000>;
>> +                     reg-shift = <2>;
>> +                     clock-frequency = <10000000>; /* Updated by bootloader */
>> +                     interrupt-parent = <&gic>;
>> +                     interrupts = <0x0 0x4c 0x4>;
>> +             };
>> +     };
>> +};
>
> The standard name for the uart is "serial", not "uart0". Please never use
> numbers in the name part of the device, the idea is that you have the
> same name for each device of the same kind and ambiguate them by the
> address part or using a label. If you have multiple uarts on the SoC,
> I would also recommend listing all of them here, and marking them
> as status="disabled", and then have an entry in the board specific
> .dts file to mark the ones that are connected to the outside like
>
> &serial0 {
>         status = enabled;
> };
Okay.
>
>         Arnd
Thanks
-Vinayak


From vkale at apm.com  Sat Apr 20 05:31:47 2013
From: vkale at apm.com (Vinayak Kale)
Date: Sat, 20 Apr 2013 15:01:47 +0530
Subject: [PATCH 2/4] arm64: Initial defconfig for APM X-Gene SOC family
In-Reply-To: <2165570.9Zy5vrhoIa@wuerfel>
References: <1366442131-26094-1-git-send-email-vkale@apm.com>
 <1366442131-26094-3-git-send-email-vkale@apm.com>
 <2165570.9Zy5vrhoIa@wuerfel>
Message-ID: <CAPrCYkcc8owdKPUth2uDwugfjKV3i2MY9XHwbqCvn8UOL5s+6Q@mail.gmail.com>

On Sat, Apr 20, 2013 at 1:05 PM, Arnd Bergmann <arnd at arndb.de> wrote:
> On Saturday 20 April 2013 12:45:29 Vinayak Kale wrote:
>> This patch adds initial defconfig for APM X-Gene SOC family.
>>
>> Signed-off-by: Kumar Sankaran <ksankaran at apm.com>
>> Signed-off-by: Loc Ho <lho at apm.com>
>> Signed-off-by: Feng Kan <fkan at apm.com>
>> ---
>>  arch/arm64/configs/xgene_defconfig |   93 ++++++++++++++++++++++++++++++++++++
>>  1 files changed, 93 insertions(+), 0 deletions(-)
>>  create mode 100644 arch/arm64/configs/xgene_defconfig
>
> Could you modify the regular defconfig to enable everything you need instead
> of adding another one? Since all the code is interoperable, I think we
> should not need a defconfig per soc.
Okay. What would be the good place to change CONFIG_NR_CPUS - a)
defcofig or b) arch/arch64/Kconfig?
Currently default value 4 is defined in Kconfig. I reckon this would
eventually be set to a highest number of CPUs implemented by a soc
among all the socs.
>
>         Arnd
Thanks
-Vinayak


From jic23 at kernel.org  Sat Apr 20 05:52:01 2013
From: jic23 at kernel.org (Jonathan Cameron)
Date: Sat, 20 Apr 2013 10:52:01 +0100
Subject: [PATCH 1/3] iio: Add Nuvoton NAU7802 ADC driver
In-Reply-To: <1366299536-18353-2-git-send-email-alexandre.belloni@free-electrons.com>
References: <1366299536-18353-1-git-send-email-alexandre.belloni@free-electrons.com>
 <1366299536-18353-2-git-send-email-alexandre.belloni@free-electrons.com>
Message-ID: <51726541.6060304@kernel.org>

On 04/18/2013 04:38 PM, Alexandre Belloni wrote:
> The Nuvoton NAU7802 ADC is a 24-bit 2-channels I2C ADC, with adjustable
> gain and sampling rates.
>
> Signed-off-by: Alexandre Belloni <alexandre.belloni at free-electrons.com>
> Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>

A few bits and pieces inline.

Ouch, that interrupt handling is annoyingly complex.  Pesky hardware
designers...

> ---
>  .../bindings/iio/adc/nuvoton-nau7802.txt           |   17 +
>  drivers/iio/adc/Kconfig                            |    9 +
>  drivers/iio/adc/Makefile                           |    1 +
>  drivers/iio/adc/nau7802.c                          |  644 ++++++++++++++++++++
>  4 files changed, 671 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/iio/adc/nuvoton-nau7802.txt
>  create mode 100644 drivers/iio/adc/nau7802.c
>
> diff --git a/Documentation/devicetree/bindings/iio/adc/nuvoton-nau7802.txt b/Documentation/devicetree/bindings/iio/adc/nuvoton-nau7802.txt
> new file mode 100644
> index 0000000..9bc4218
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/adc/nuvoton-nau7802.txt
> @@ -0,0 +1,17 @@
> +* Nuvoton NAU7802 Analog to Digital Converter (ADC)
> +
> +Required properties:
> +  - compatible: Should be "nuvoton,nau7802"
> +  - reg: Should contain the ADC I2C address
> +
> +Optional properties:
> +  - nuvoton,vldo: Reference voltage in millivolts (integer)
As this is external I'd personally prefer using the regulator subsystem
to provide it.  That gives a more flexible way of supplying it.
If fixed you can always use a fixed regulator...
> +  - interrupts: IRQ line for the ADC. If not used the driver will use
> +    polling.
> +
> +Example:
> +adc2: nau7802 at 2a {
> +	compatible = "nuvoton,nau7802";
> +	reg = <0x2a>;
> +	nuvoton,vldo = <3000>;
> +};
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index e372257..ed3059a 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -113,6 +113,15 @@ config MAX1363
>  	  max11646, max11647) Provides direct access via sysfs and buffered
>  	  data via the iio dev interface.
>
> +config NAU7802
> +	tristate "Nuvoton NAU7802 ADC driver"
> +	depends on I2C
> +	help
> +	  Say yes here to build support for Nuvoton NAU7802 ADC.
> +
> +	  To compile this driver as a module, choose M here: the
> +	  module will be called nau7802.
> +
>  config TI_ADC081C
>  	tristate "Texas Instruments ADC081C021/027"
>  	depends on I2C
> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> index 2d5f100..a02150d 100644
> --- a/drivers/iio/adc/Makefile
> +++ b/drivers/iio/adc/Makefile
> @@ -12,6 +12,7 @@ obj-$(CONFIG_AD7887) += ad7887.o
>  obj-$(CONFIG_AT91_ADC) += at91_adc.o
>  obj-$(CONFIG_LP8788_ADC) += lp8788_adc.o
>  obj-$(CONFIG_MAX1363) += max1363.o
> +obj-$(CONFIG_NAU7802) += nau7802.o
>  obj-$(CONFIG_TI_ADC081C) += ti-adc081c.o
>  obj-$(CONFIG_TI_AM335X_ADC) += ti_am335x_adc.o
>  obj-$(CONFIG_VIPERBOARD_ADC) += viperboard_adc.o
> diff --git a/drivers/iio/adc/nau7802.c b/drivers/iio/adc/nau7802.c
> new file mode 100644
> index 0000000..0148fd8
> --- /dev/null
> +++ b/drivers/iio/adc/nau7802.c
> @@ -0,0 +1,644 @@
> +/*
> + * Driver for the Nuvoton NAU7802 ADC
> + *
> + * Copyright 2013 Free Electrons
> + *
> + * Licensed under the GPLv2 or later.
> + */
> +
> +#include <linux/delay.h>
> +#include <linux/i2c.h>
> +#include <linux/interrupt.h>
> +#include <linux/module.h>
> +#include <linux/wait.h>
> +#include <linux/of_irq.h>
> +#include <linux/log2.h>
> +
> +#include <linux/iio/iio.h>
> +#include <linux/iio/sysfs.h>
> +
> +#define NAU7802_REG_PUCTRL	0x00
> +#define NAU7802_PUCTRL_RR(x)		(x << 0)
> +#define NAU7802_PUCTRL_RR_BIT		NAU7802_PUCTRL_RR(1)
> +#define NAU7802_PUCTRL_PUD(x)		(x << 1)
> +#define NAU7802_PUCTRL_PUD_BIT		NAU7802_PUCTRL_PUD(1)
> +#define NAU7802_PUCTRL_PUA(x)		(x << 2)
> +#define NAU7802_PUCTRL_PUA_BIT		NAU7802_PUCTRL_PUA(1)
> +#define NAU7802_PUCTRL_PUR(x)		(x << 3)
> +#define NAU7802_PUCTRL_PUR_BIT		NAU7802_PUCTRL_PUR(1)
> +#define NAU7802_PUCTRL_CS(x)		(x << 4)
> +#define NAU7802_PUCTRL_CS_BIT		NAU7802_PUCTRL_CS(1)
> +#define NAU7802_PUCTRL_CR(x)		(x << 5)
> +#define NAU7802_PUCTRL_CR_BIT		NAU7802_PUCTRL_CR(1)
> +#define NAU7802_PUCTRL_AVDDS(x)		(x << 7)
> +#define NAU7802_PUCTRL_AVDDS_BIT	NAU7802_PUCTRL_AVDDS(1)
> +#define NAU7802_REG_CTRL1	0x01
> +#define NAU7802_CTRL1_VLDO(x)		(x << 3)
> +#define NAU7802_CTRL1_GAINS(x)		(x)
> +#define NAU7802_CTRL1_GAINS_BITS	0x07
> +#define NAU7802_REG_CTRL2	0x02
> +#define NAU7802_CTRL2_CHS(x)		(x << 7)
> +#define NAU7802_CTRL2_CRS(x)		(x << 4)
> +#define NAU7802_CTRL2_CHS_BIT		NAU7802_CTRL2_CHS(1)
> +#define NAU7802_REG_ADC_B2	0x12
> +#define NAU7802_REG_ADC_B1	0x13
> +#define NAU7802_REG_ADC_B0	0x14
> +#define NAU7802_REG_ADC_CTRL	0x15
> +
> +struct nau7802_state {
> +	struct i2c_client	*client;
> +	s32			last_value;
I can't immediately see why you need two locks...
I think the datalock is only ever taken when the
lock is already held (be it in a threaded irq).

> +	struct mutex		lock;
> +	struct mutex		data_lock;
> +	u32			vref_mv;
> +	u32			conversion_count;
> +	u32			min_conversions;
> +	u8			sample_rate;
> +	struct completion	value_ok;
> +};
> +
> +static int nau7802_i2c_read(struct nau7802_state *st, u8 reg, u8 *data)
> +{
> +	int ret = 0;
> +
> +	ret = i2c_smbus_read_byte_data(st->client, reg);
> +	if (ret < 0) {
> +		dev_err(&st->client->dev, "failed to read from I2C\n");
> +		return ret;
> +	}
> +
> +	*data = ret;
> +
> +	return 0;
> +}
> +
Don't wrap standard functions like this. Call them directly. It's not
worth the added complexity to get a not particularly informative error message
from the read.

> +static int nau7802_i2c_write(struct nau7802_state *st, u8 reg, u8 data)
> +{
> +	return i2c_smbus_write_byte_data(st->client, reg, data);
> +}
> +
> +static const u16 nau7802_sample_freq_avail[] = {10, 20, 40, 80,
> +						10, 10, 10, 320};
> +
> +static ssize_t nau7802_sysfs_set_sampling_frequency(struct device *dev,
> +		struct device_attribute *attr,
> +		const char *buf,
> +		size_t len)
> +{
> +	struct iio_dev *idev = dev_to_iio_dev(dev);
> +	struct nau7802_state *st = iio_priv(idev);
> +	u32 val;
> +	int ret, i;
> +
> +	ret = kstrtouint(buf, 10, &val);
> +	if (ret)
> +		return ret;
> +
> +	ret = -EINVAL;
> +	for (i = 0; i < 8; i++)
> +		if (val == nau7802_sample_freq_avail[i]) {
> +			mutex_lock(&st->lock);
> +			st->sample_rate = i;
> +			st->conversion_count = 0;
> +			nau7802_i2c_write(st, NAU7802_REG_CTRL2,
> +					NAU7802_CTRL2_CRS(st->sample_rate));
> +			mutex_unlock(&st->lock);
> +			ret = len;
> +			break;
> +		}
> +	return ret;
> +}
> +
> +static ssize_t nau7802_sysfs_get_sampling_frequency(struct device *dev,
> +		struct device_attribute *attr,
> +		char *buf)
> +{
> +	struct iio_dev *idev = dev_to_iio_dev(dev);
> +	struct nau7802_state *st = iio_priv(idev);
> +
> +	return sprintf(buf, "%d\n",
> +	       nau7802_sample_freq_avail[st->sample_rate]);
> +}
> +
> +static IIO_DEV_ATTR_SAMP_FREQ(S_IWUSR | S_IRUGO,
> +		nau7802_sysfs_get_sampling_frequency,
> +		nau7802_sysfs_set_sampling_frequency);
> +
> +static IIO_CONST_ATTR_SAMP_FREQ_AVAIL("10 40 80 320");
> +
> +static IIO_CONST_ATTR(gain_available, "1 2 4 8 16 32 64 128");
> +
> +static ssize_t nau7802_sysfs_set_gain(struct device *dev,
> +		struct device_attribute *attr,
> +		const char *buf,
> +		size_t len)
> +{
> +	struct iio_dev *idev = dev_to_iio_dev(dev);
> +	struct nau7802_state *st = iio_priv(idev);
> +	u32 val;
> +	u8 data;
> +	int ret;
> +
> +	ret = kstrtouint(buf, 10, &val);
> +	if (ret)
> +		return ret;
> +
> +	if (val < 1 || val > 128 || !is_power_of_2(val))
> +		return -EINVAL;
> +
> +	mutex_lock(&st->lock);
> +	st->conversion_count = 0;
> +
> +	ret = nau7802_i2c_read(st, NAU7802_REG_CTRL1, &data);
> +	if (ret < 0)
> +		goto nau7802_sysfs_set_gain_out;
> +	ret = nau7802_i2c_write(st, NAU7802_REG_CTRL1,
> +			(data & (~NAU7802_CTRL1_GAINS_BITS)) | ilog2(val));
> +nau7802_sysfs_set_gain_out:
> +	mutex_unlock(&st->lock);
> +	return ret ? ret : len;
> +}
> +
> +static ssize_t nau7802_sysfs_get_gain(struct device *dev,
> +		struct device_attribute *attr,
> +		char *buf)
> +{
> +	struct iio_dev *idev = dev_to_iio_dev(dev);
> +	struct nau7802_state *st = iio_priv(idev);
> +	u8 data;
> +	int ret;
> +
> +	ret = nau7802_i2c_read(st, NAU7802_REG_CTRL1, &data);
> +	if (ret < 0)
> +		return ret;
> +
> +	return sprintf(buf, "%d\n", 1 << (data & NAU7802_CTRL1_GAINS_BITS));
> +}
> +
> +static IIO_DEVICE_ATTR(gain, S_IWUSR | S_IRUGO,
> +		nau7802_sysfs_get_gain,
> +		nau7802_sysfs_set_gain, 0);
> +
> +static ssize_t nau7802_sysfs_set_min_conversions(struct device *dev,
> +		struct device_attribute *attr,
> +		const char *buf,
> +		size_t len)
> +{
> +	struct iio_dev *idev = dev_to_iio_dev(dev);
> +	struct nau7802_state *st = iio_priv(idev);
> +	u32 val;
> +	int ret;
> +
> +	ret = kstrtouint(buf, 10, &val);
> +	if (ret)
> +		return ret;
> +
> +	mutex_lock(&st->lock);
> +	st->min_conversions = val;
> +	st->conversion_count = 0;
> +	mutex_unlock(&st->lock);
> +	return len;
> +}
> +
> +static ssize_t nau7802_sysfs_get_min_conversions(struct device *dev,
> +		struct device_attribute *attr,
> +		char *buf)
> +{
> +	struct iio_dev *idev = dev_to_iio_dev(dev);
> +	struct nau7802_state *st = iio_priv(idev);
> +
> +	return sprintf(buf, "%d\n", st->min_conversions);
> +}
> +
> +static IIO_DEVICE_ATTR(min_conversions, S_IWUSR | S_IRUGO,
> +		nau7802_sysfs_get_min_conversions,
> +		nau7802_sysfs_set_min_conversions, 0);
> +
> +static struct attribute *nau7802_attributes[] = {
Given you have only adc channels you could just use the relevant
info_mask element for and have this as a shared attribute of them.
> +	&iio_dev_attr_sampling_frequency.dev_attr.attr,
> +	&iio_const_attr_sampling_frequency_available.dev_attr.attr,

Just have a range of scale options available and figure out which
gain they correspond to.  Obviously you'll need a write_raw callback
to implement that, but it's pretty standard and conforms to the iio
abi which this does not.   I've been meaning to clean up the way
'available' is handled but for now you will probaby want to have
a suitable gain here.
> +	&iio_dev_attr_gain.dev_attr.attr,
> +	&iio_const_attr_gain_available.dev_attr.attr,
> +	&iio_dev_attr_min_conversions.dev_attr.attr,
What governs this?  Looks to me more like it should be hidden away
in the device tree than be here.
> +	NULL
> +};
> +
> +static const struct attribute_group nau7802_attribute_group = {
> +	.attrs = nau7802_attributes,
> +};
> +
> +static int nau7802_read_conversion(struct nau7802_state *st)
> +{
> +	int ret;
> +	u8 data;
> +
> +	mutex_lock(&st->data_lock);
> +	ret = nau7802_i2c_read(st, NAU7802_REG_ADC_B2, &data);
> +	if (ret)
> +		goto nau7802_read_conversion_out;
> +	st->last_value = data << 24;
> +
> +	ret = nau7802_i2c_read(st, NAU7802_REG_ADC_B1, &data);
> +	if (ret)
> +		goto nau7802_read_conversion_out;
> +	st->last_value |= data << 16;
> +
> +	ret = nau7802_i2c_read(st, NAU7802_REG_ADC_B0, &data);
> +	if (ret)
> +		goto nau7802_read_conversion_out;
> +	st->last_value |= data << 8;
> +
> +	st->last_value >>= 8;
umm. Why shift everything 8 to the left then 8 to the right?
> +
> +nau7802_read_conversion_out:
> +	mutex_unlock(&st->data_lock);
> +	return ret;
> +}
> +
What does this do?  Perhaps a comment?
> +static int nau7802_sync(struct nau7802_state *st)
> +{
> +	int ret;
> +	u8 data;
> +
> +	ret = nau7802_i2c_read(st, NAU7802_REG_PUCTRL, &data);
> +	if (ret)
> +		return ret;
> +	ret = nau7802_i2c_write(st, NAU7802_REG_PUCTRL,
> +				data | NAU7802_PUCTRL_CS_BIT);
> +	return ret;
> +}
> +
> +static irqreturn_t nau7802_eoc_trigger(int irq, void *private)
> +{
> +	struct iio_dev *idev = private;
> +	struct nau7802_state *st = iio_priv(idev);
> +	u8 status;
> +	int ret;
> +
> +	ret = nau7802_i2c_read(st, NAU7802_REG_PUCTRL, &status);
> +	if (ret)
> +		return IRQ_HANDLED;
> +
> +	if (!(status & NAU7802_PUCTRL_CR_BIT))
> +		return IRQ_NONE;
> +
> +	if (nau7802_read_conversion(st))
> +		return IRQ_HANDLED;
> +
> +	/* wait for enough conversions before getting a stable value when
> +	 * changing channels */
> +	if (st->conversion_count < st->min_conversions)
> +		st->conversion_count++;
> +	if (st->conversion_count >= st->min_conversions)
> +		complete_all(&st->value_ok);
pretty much always stick in a  blank line before return statements.
Makes it easier to read...
> +	return IRQ_HANDLED;
> +}
> +
> +static int nau7802_read_irq(struct iio_dev *idev,
> +			struct iio_chan_spec const *chan,
> +			int *val)
> +{
> +	struct nau7802_state *st = iio_priv(idev);
> +	int ret;
> +
> +	INIT_COMPLETION(st->value_ok);

So let me see if I have this correct.
> +	enable_irq(st->client->irq);
This will probably fire immediately as it is a level irq and we have had
it masked.
> +
> +	nau7802_sync(st);
This flushes the device?
> +
> +	/* read registers to ensure we flush everything */
> +	ret = nau7802_read_conversion(st);
> +	if (ret)
> +		goto read_chan_info_failure;
> +
This then ensures we have scrubbed any left over data?  Might scrub
some extra but that isn't a problem...

> +	/* Wait for a conversion to finish */
> +	ret = wait_for_completion_interruptible_timeout(&st->value_ok,
> +			msecs_to_jiffies(1000));
This will fire next time we have new data?
> +	if (ret == 0)
> +		ret = -ETIMEDOUT;
> +
> +	if (ret < 0)
> +		goto read_chan_info_failure;
> +
> +	disable_irq(st->client->irq);
> +
> +	*val = st->last_value;
nitpick - blank line here.
> +	return IIO_VAL_INT;
> +
> +read_chan_info_failure:
> +	disable_irq(st->client->irq);
> +	return ret;
> +}
> +
> +static int nau7802_read_poll(struct iio_dev *idev,
> +			struct iio_chan_spec const *chan,
> +			int *val)
> +{
> +	struct nau7802_state *st = iio_priv(idev);
> +	int ret;
> +	u8 data;
> +
> +	nau7802_sync(st);
> +
> +	/* read registers to ensure we flush everything */
> +	ret = nau7802_read_conversion(st);
> +	if (ret)
> +		return ret;
> +
> +	do {
> +		nau7802_i2c_read(st, NAU7802_REG_PUCTRL, &data);
> +		if (ret)
> +			return ret;
> +		while (!(data & NAU7802_PUCTRL_CR_BIT)) {
> +			if (st->sample_rate != 0x07)
> +				msleep(20);
> +			else
> +				mdelay(4);
> +			nau7802_i2c_read(st, NAU7802_REG_PUCTRL, &data);
> +			if (ret)
> +				return ret;
> +		}
> +
> +		nau7802_read_conversion(st);
> +		if (ret)
> +			return ret;
> +		if (st->conversion_count < st->min_conversions)
> +			st->conversion_count++;
> +	} while (st->conversion_count < st->min_conversions);
> +
> +	*val = st->last_value;
nitpick - nicer with a blank line here.
> +	return IIO_VAL_INT;
> +}
> +
> +static int nau7802_read_raw(struct iio_dev *idev,
> +			    struct iio_chan_spec const *chan,
> +			    int *val, int *val2, long mask)
> +{
> +	struct nau7802_state *st = iio_priv(idev);
> +	u8 data;
> +	int ret;
> +
> +	switch (mask) {
> +	case IIO_CHAN_INFO_RAW:
> +		mutex_lock(&st->lock);
> +		/*
> +		 * Select the channel to use
> +		 *   - Channel 1 is value 0 in the CHS register
> +		 *   - Channel 2 is value 1 in the CHS register
> +		 */
> +		ret = nau7802_i2c_read(st, NAU7802_REG_CTRL2, &data);
> +		if (ret < 0)
> +			return ret;
> +		if (((data & NAU7802_CTRL2_CHS_BIT) && !chan->channel) ||
> +				(!(data & NAU7802_CTRL2_CHS_BIT) &&
> +				 chan->channel)) {
> +			st->conversion_count = 0;
> +			ret = nau7802_i2c_write(st, NAU7802_REG_CTRL2,
> +					NAU7802_CTRL2_CHS(chan->channel) |
> +					NAU7802_CTRL2_CRS(st->sample_rate));
> +			if (ret < 0)
> +				return ret;
> +		}
> +
> +		if (st->client->irq)
> +			ret = nau7802_read_irq(idev, chan, val);
> +		else
> +			ret = nau7802_read_poll(idev, chan, val);
> +
> +		mutex_unlock(&st->lock);
> +		return ret;
> +	case IIO_CHAN_INFO_SCALE:
> +		ret = nau7802_i2c_read(st, NAU7802_REG_CTRL1, &data);
> +		if (ret < 0)
> +			return ret;
> +
> +		*val = 0;
> +		*val2 = (((u64)st->vref_mv) * 1000000000ULL) >>
> +			(chan->scan_type.realbits +
> +			 (data & NAU7802_CTRL1_GAINS_BITS));
It's saturday morning and I'm half asleep so I'll take your word for
this being the nicest way of computing this. However with a 23 bit
adc measuring around 5V? I would have thought to get a decent number
of significant figures you'd want to do IIO_VAL_INT_PLUS_NANO?
> +		return IIO_VAL_INT_PLUS_MICRO;
> +	default:
> +		break;
> +	}
> +	return -EINVAL;
> +}
> +
> +static const struct iio_info nau7802_info = {
> +	.driver_module = THIS_MODULE,
> +	.read_raw = &nau7802_read_raw,
> +	.attrs = &nau7802_attribute_group,
> +};
> +
> +static int nau7802_channel_init(struct iio_dev *idev)
> +{
> +	struct iio_chan_spec *chan_array;
> +	int i;
> +
> +	idev->num_channels = 2;
> +
> +	chan_array = devm_kzalloc(&idev->dev,
> +				  sizeof(*chan_array) * idev->num_channels,
> +				  GFP_KERNEL);
> +
There are only two of them and that is pretty much fixed.  Do this with
a const static array rather than dynamically. If you really want the
flexibility on number of channels, then just set idev->num_channels
appropriately and it'll ignore later entries in the table.

Dynamic allocation only makes sense where we have a huge and complex
set of possible channel combinations.

> +	for (i = 0; i < idev->num_channels; i++) {
> +		struct iio_chan_spec *chan = chan_array + i;
> +
> +		chan->type = IIO_VOLTAGE;
> +		chan->indexed = 1;
> +		chan->channel = i;
> +		chan->scan_index = i;
> +		chan->scan_type.sign = 's';
> +		chan->scan_type.realbits = 23;
As I read it this part is a 24bit adc where they are committing to 23bits of good
precision. As such realbits should be 24.
Not that it's used for anything unless you are doing buffering!
(so feel free to drop the scan_index and san_type entirely.
> +		chan->scan_type.storagebits = 24;
> +		chan->info_mask = IIO_CHAN_INFO_SCALE_SHARED_BIT |
> +			IIO_CHAN_INFO_RAW_SEPARATE_BIT;
This has changed, take a look at the latest staging-next.
> +	}
> +	idev->channels = chan_array;
> +
> +	return idev->num_channels;
> +}
> +
> +static int nau7802_probe(struct i2c_client *client,
> +			const struct i2c_device_id *id)
> +{
> +	struct iio_dev *idev;
> +	struct nau7802_state *st;
> +	struct device_node *np = client->dev.of_node;
> +	int ret;
> +	u8 data;
> +	u32 tmp;
> +
> +	if (!client->dev.of_node) {
> +		dev_err(&client->dev, "No device tree node available.\n");
> +		return -EINVAL;
> +	}
> +
> +	/*
> +	 * If we have some interrupts declared, use them, if not, fall back
> +	 * on polling.
> +	 */
> +	if (of_find_property(np, "interrupts", NULL)) {
> +		if (client->irq <= 0) {
> +			client->irq = irq_of_parse_and_map(np, 0);
> +			if (client->irq <= 0)
> +				return -EPROBE_DEFER;
> +		}
> +	} else
> +		client->irq = 0;
> +
> +	idev = iio_device_alloc(sizeof(struct nau7802_state));
sizeof(*st) is a little cleaner.
Also we have pretty much standardized on calling the iio_dev
indio_dev (no idea why but it's how it turned out ;)  Whilst
it doesn't really matter it does make reviewers jobs marginally
easier ;)
> +	if (idev == NULL)
> +		return -ENOMEM;
> +
> +	st = iio_priv(idev);
> +
> +	i2c_set_clientdata(client, idev);
> +
> +	idev->dev.parent = &client->dev;
> +	idev->name = dev_name(&client->dev);
> +	idev->modes = INDIO_DIRECT_MODE;
> +	idev->info = &nau7802_info;
> +
> +	st->client = client;
> +
> +	/* Reset the device */
> +	nau7802_i2c_write(st, NAU7802_REG_PUCTRL, NAU7802_PUCTRL_RR_BIT);
> +
> +	/* Enter normal operation mode */
> +	nau7802_i2c_write(st, NAU7802_REG_PUCTRL, NAU7802_PUCTRL_PUD_BIT);
> +
> +	/*
> +	 * After about 200 usecs, the device should be ready and then
> +	 * the Power Up bit will be set to 1. If not, wait for it.
> +	 */
> +	do {
> +		udelay(200);
> +		ret = nau7802_i2c_read(st, NAU7802_REG_PUCTRL, &data);
> +		if (ret)
> +			return -ENODEV;
You want some sort of timeout and fail here.  Perasonally if the device
should be ready in 200 usec, I'd only let it have one go at doing so
before failing (or give 250 usec if it's not all that precise).

> +	} while (!(data & NAU7802_PUCTRL_PUR_BIT));
> +
> +	of_property_read_u32(np, "nuvoton,vldo", &tmp);
> +	st->vref_mv = tmp;
> +
> +	data = NAU7802_PUCTRL_PUD_BIT | NAU7802_PUCTRL_PUA_BIT |
> +		NAU7802_PUCTRL_CS_BIT;
> +	if (tmp >= 2400)
> +		data |= NAU7802_PUCTRL_AVDDS_BIT;
> +
> +	nau7802_i2c_write(st, NAU7802_REG_PUCTRL, data);
> +	nau7802_i2c_write(st, NAU7802_REG_ADC_CTRL, 0x30);
> +
> +	if (tmp >= 2400) {
> +		data = NAU7802_CTRL1_VLDO((4500 - tmp) / 300);
> +		nau7802_i2c_write(st, NAU7802_REG_CTRL1, data);
> +	}
> +
> +	st->min_conversions = 6;
> +
> +	/*
> +	 * The ADC fires continuously and we can't do anything about
> +	 * it. So we need to have the IRQ disabled by default, and we
> +	 * will enable them back when we will need them..
> +	 */
> +	if (client->irq) {
> +		irq_set_status_flags(client->irq, IRQ_NOAUTOEN);
> +		ret = request_threaded_irq(client->irq,
> +				NULL,
> +				nau7802_eoc_trigger,
> +				IRQF_TRIGGER_HIGH | IRQF_ONESHOT,
> +				client->dev.driver->name,
> +				idev);
> +		if (ret) {
> +			/*
> +			 * What may happen here is that our IRQ controller is
> +			 * not able to get level interrupt but this is required
> +			 * by this ADC as when going over 40 sample per second,
> +			 * the interrupt line may stay high between conversions.
> +			 * So, we continue no matter what but we switch to
> +			 * polling mode.
> +			 */
Good plan.  Pesky hardware designers and not guaranteeing transitions. ;)
> +			dev_info(&client->dev,
> +				"Failed to allocate IRQ, using polling mode\n");
> +			client->irq = 0;
> +			/*
> +			 * We are polling, use the fastest sample rate by
> +			 * default
> +			 */
> +			st->sample_rate = 0x7;
> +			nau7802_i2c_write(st, NAU7802_REG_CTRL2,
> +					NAU7802_CTRL2_CRS(st->sample_rate));
> +		}
> +	}
> +
> +	/* Setup the ADC channels available on the board */
> +	ret = nau7802_channel_init(idev);
> +	if (ret < 0) {
> +		dev_err(&client->dev, "Couldn't initialize the channels.\n");
> +		goto error_channel_init;
> +	}
> +
> +	init_completion(&st->value_ok);
> +	mutex_init(&st->lock);
> +	mutex_init(&st->data_lock);
> +
> +	ret = iio_device_register(idev);
> +	if (ret < 0) {
> +		dev_err(&client->dev, "Couldn't register the device.\n");
> +		goto error_device_register;
> +	}
> +
> +	return 0;
> +
> +error_device_register:
> +	mutex_destroy(&st->lock);
datalock?
> +error_channel_init:
> +	if (client->irq)
> +		free_irq(client->irq, idev);
> +	iio_device_free(idev);
> +	return ret;
> +}
> +
> +static int nau7802_remove(struct i2c_client *client)
> +{
> +	struct iio_dev *idev = i2c_get_clientdata(client);
> +	struct nau7802_state *st = iio_priv(idev);
> +
> +	iio_device_unregister(idev);
> +	mutex_destroy(&st->lock);
> +	mutex_destroy(&st->data_lock);
> +	if (client->irq)
> +		free_irq(client->irq, idev);
> +	iio_device_free(idev);
> +
> +	return 0;
> +}
> +
> +static const struct i2c_device_id nau7802_i2c_id[] = {
> +	{ "nau7802", 0 },
> +	{ }
> +};
> +MODULE_DEVICE_TABLE(i2c, nau7802_i2c_id);
> +
> +static const struct of_device_id nau7802_dt_ids[] = {
> +	{ .compatible = "nuvoton,nau7802" },
> +	{},
> +};
> +MODULE_DEVICE_TABLE(of, nau7802_dt_ids);
> +
> +static struct i2c_driver nau7802_driver = {
> +	.probe = nau7802_probe,
> +	.remove = nau7802_remove,
> +	.id_table = nau7802_i2c_id,
> +	.driver = {
> +		   .name = "nau7802",
> +		   .of_match_table = of_match_ptr(nau7802_dt_ids),
> +	},
> +};
> +
> +module_i2c_driver(nau7802_driver);
> +
> +MODULE_LICENSE("GPL");
> +MODULE_DESCRIPTION("Nuvoton NAU7802 ADC Driver");
> +MODULE_AUTHOR("Maxime Ripard <maxime.ripard at free-electrons.com>");
> +MODULE_AUTHOR("Alexandre Belloni <alexandre.belloni at free-electrons.com>");
>


From arnd at arndb.de  Sat Apr 20 06:27:29 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Sat, 20 Apr 2013 12:27:29 +0200
Subject: [PATCH 2/4] arm64: Initial defconfig for APM X-Gene SOC family
In-Reply-To: <CAPrCYkcc8owdKPUth2uDwugfjKV3i2MY9XHwbqCvn8UOL5s+6Q@mail.gmail.com>
References: <1366442131-26094-1-git-send-email-vkale@apm.com>
 <2165570.9Zy5vrhoIa@wuerfel>
 <CAPrCYkcc8owdKPUth2uDwugfjKV3i2MY9XHwbqCvn8UOL5s+6Q@mail.gmail.com>
Message-ID: <201304201227.29341.arnd@arndb.de>

On Saturday 20 April 2013, Vinayak Kale wrote:

> Okay. What would be the good place to change CONFIG_NR_CPUS - a)
> defcofig or b) arch/arch64/Kconfig?
> Currently default value 4 is defined in Kconfig. I reckon this would
> eventually be set to a highest number of CPUs implemented by a soc
> among all the socs.

I think Kconfig would be best. Since this is a setting that is fundamentally
tied to the largest system you want to run on, you can do it like this:

config NR_CPUS
        int "Maximum number of CPUs (2-256)"
        range 2 256
        depends on SMP
	# These have to remain sorted largest to smallest
	default "64" if XGENE
	default "16" if FOO
        default "4"

If you enable XGENE in defconfig, it will automatically get the appropriate
default here, and someone who does not care about XGENE will ge the next
smaller number he or she is building for.

	Arnd


From arnd at arndb.de  Sat Apr 20 06:33:45 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Sat, 20 Apr 2013 12:33:45 +0200
Subject: [PATCH v2] serial: pl011: Add Device Tree support to request DMA
 channels
In-Reply-To: <1366272857-14038-1-git-send-email-lee.jones@linaro.org>
References: <1366272857-14038-1-git-send-email-lee.jones@linaro.org>
Message-ID: <201304201233.45501.arnd@arndb.de>

Hi Lee and Russell,

While going through the arm-soc tree yesterday, I noticed two things:

* I had already done a patch for this in January which I meant to queue up
  for 3.10, as it is needed to make spear13xx use the dma-engine binding
* I actually forgot to merge that branch into for-next :(

I've put it into a "late" branch now. Could you have a look please?
If there are any problems with this, I'll probably just drop the branch
and queue it for 3.11 instead with the required fixes.

	Arnd

commit 787b0c1f8e1975157fe73104e67cac18f955281b
Author: Arnd Bergmann <arnd at arndb.de>
Date:   Mon Jan 28 16:24:37 2013 +0000

    serial: pl011: use generic DMA slave configuration if possible
    
    With the new OF DMA binding, it is possible to completely avoid the
    need for platform_data for configuring a DMA channel. In cases where the
    platform has already been converted, calling dma_request_slave_channel
    should get all the necessary information from the device tree.
    
    This also adds a binding document specific to the pl011 controller,
    and extends the generic primecell binding to mention "dmas" and other
    common properties.
    
    Like the patch that converts the dw_dma controller, this is completely
    untested and is looking for someone to try it out.
    
    Signed-off-by: Arnd Bergmann <arnd at arndb.de>
    Acked-by: Grant Likely <grant.likely at secretlab.ca>
    Acked-by: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
    Cc: Russell King <linux at arm.linux.org.uk>
    Cc: Jiri Slaby <jslaby at suse.cz>
    Cc: Viresh Kumar <viresh.kumar at linaro.org>
    Cc: devicetree-discuss at lists.ozlabs.org
    Cc: linux-arm-kernel at lists.infradead.org

diff --git a/Documentation/devicetree/bindings/arm/primecell.txt b/Documentation/devicetree/bindings/arm/primecell.txt
index 64fc82b..0df6aca 100644
--- a/Documentation/devicetree/bindings/arm/primecell.txt
+++ b/Documentation/devicetree/bindings/arm/primecell.txt
@@ -16,14 +16,31 @@ Optional properties:
 - clocks : From common clock binding. First clock is phandle to clock for apb
 	pclk. Additional clocks are optional and specific to those peripherals.
 - clock-names : From common clock binding. Shall be "apb_pclk" for first clock.
+- dmas : From common DMA binding. If present, refers to one or more dma channels.
+- dma-names : From common DMA binding, needs to match the 'dmas' property.
+              Devices with exactly one receive and transmit channel shall name
+              these "rx" and "tx", respectively.
+- pinctrl-<n> : Pinctrl states as described in bindings/pinctrl/pinctrl-bindings.txt
+- pinctrl-names : Names corresponding to the numbered pinctrl states
+- interrupts : one or more interrupt specifiers
+- interrupt-names : names corresponding to the interrupts properties
 
 Example:
 
 serial at fff36000 {
 	compatible = "arm,pl011", "arm,primecell";
 	arm,primecell-periphid = <0x00341011>;
+
 	clocks = <&pclk>;
 	clock-names = "apb_pclk";
-	
+
+	dmas = <&dma-controller 4>, <&dma-controller 5>;
+	dma-names = "rx", "tx";	
+
+	pinctrl-0 = <&uart0_default_mux>, <&uart0_default_mode>;
+	pinctrl-1 = <&uart0_sleep_mode>;
+	pinctrl-names = "default","sleep";
+
+	interrupts = <0 11 0x4>;
 };
 
diff --git a/Documentation/devicetree/bindings/serial/pl011.txt b/Documentation/devicetree/bindings/serial/pl011.txt
new file mode 100644
index 0000000..5d2e840
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/pl011.txt
@@ -0,0 +1,17 @@
+* ARM AMBA Primecell PL011 serial UART
+
+Required properties:
+- compatible: must be "arm,primecell", "arm,pl011"
+- reg: exactly one register range with length 0x1000
+- interrupts: exactly one interrupt specifier
+
+Optional properties:
+- pinctrl: When present, must have one state named "sleep"
+	   and one state named "default"
+- clocks:  When present, must refer to exactly one clock named
+	   "apb_pclk"
+- dmas:	   When present, may have one or two dma channels.
+	   The first one must be named "rx", the second one
+	   must be named "tx".
+
+See also bindings/arm/primecell.txt
diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
index 3ea5408..c25b00e 100644
--- a/drivers/tty/serial/amba-pl011.c
+++ b/drivers/tty/serial/amba-pl011.c
@@ -245,7 +245,7 @@ static void pl011_sgbuf_free(struct dma_chan *chan, struct pl011_sgbuf *sg,
 	}
 }
 
-static void pl011_dma_probe_initcall(struct uart_amba_port *uap)
+static void pl011_dma_probe_initcall(struct device *dev, struct uart_amba_port *uap)
 {
 	/* DMA is the sole user of the platform data right now */
 	struct amba_pl011_data *plat = uap->port.dev->platform_data;
@@ -259,20 +259,25 @@ static void pl011_dma_probe_initcall(struct uart_amba_port *uap)
 	struct dma_chan *chan;
 	dma_cap_mask_t mask;
 
-	/* We need platform data */
-	if (!plat || !plat->dma_filter) {
-		dev_info(uap->port.dev, "no DMA platform data\n");
-		return;
-	}
+	chan = dma_request_slave_channel(dev, "tx");
 
-	/* Try to acquire a generic DMA engine slave TX channel */
-	dma_cap_zero(mask);
-	dma_cap_set(DMA_SLAVE, mask);
-
-	chan = dma_request_channel(mask, plat->dma_filter, plat->dma_tx_param);
 	if (!chan) {
-		dev_err(uap->port.dev, "no TX DMA channel!\n");
-		return;
+		/* We need platform data */
+		if (!plat || !plat->dma_filter) {
+			dev_info(uap->port.dev, "no DMA platform data\n");
+			return;
+		}
+
+		/* Try to acquire a generic DMA engine slave TX channel */
+		dma_cap_zero(mask);
+		dma_cap_set(DMA_SLAVE, mask);
+
+		chan = dma_request_channel(mask, plat->dma_filter,
+						plat->dma_tx_param);
+		if (!chan) {
+			dev_err(uap->port.dev, "no TX DMA channel!\n");
+			return;
+		}
 	}
 
 	dmaengine_slave_config(chan, &tx_conf);
@@ -282,7 +287,18 @@ static void pl011_dma_probe_initcall(struct uart_amba_port *uap)
 		 dma_chan_name(uap->dmatx.chan));
 
 	/* Optionally make use of an RX channel as well */
-	if (plat->dma_rx_param) {
+	chan = dma_request_slave_channel(dev, "rx");
+	
+	if (!chan && plat->dma_rx_param) {
+		chan = dma_request_channel(mask, plat->dma_filter, plat->dma_rx_param);
+
+		if (!chan) {
+			dev_err(uap->port.dev, "no RX DMA channel!\n");
+			return;
+		}
+	}
+
+	if (chan) {
 		struct dma_slave_config rx_conf = {
 			.src_addr = uap->port.mapbase + UART01x_DR,
 			.src_addr_width = DMA_SLAVE_BUSWIDTH_1_BYTE,
@@ -291,12 +307,6 @@ static void pl011_dma_probe_initcall(struct uart_amba_port *uap)
 			.device_fc = false,
 		};
 
-		chan = dma_request_channel(mask, plat->dma_filter, plat->dma_rx_param);
-		if (!chan) {
-			dev_err(uap->port.dev, "no RX DMA channel!\n");
-			return;
-		}
-
 		dmaengine_slave_config(chan, &rx_conf);
 		uap->dmarx.chan = chan;
 
@@ -315,6 +325,7 @@ static void pl011_dma_probe_initcall(struct uart_amba_port *uap)
 struct dma_uap {
 	struct list_head node;
 	struct uart_amba_port *uap;
+	struct device *dev;
 };
 
 static LIST_HEAD(pl011_dma_uarts);
@@ -325,7 +336,7 @@ static int __init pl011_dma_initcall(void)
 
 	list_for_each_safe(node, tmp, &pl011_dma_uarts) {
 		struct dma_uap *dmau = list_entry(node, struct dma_uap, node);
-		pl011_dma_probe_initcall(dmau->uap);
+		pl011_dma_probe_initcall(dmau->dev, dmau->uap);
 		list_del(node);
 		kfree(dmau);
 	}
@@ -334,18 +345,19 @@ static int __init pl011_dma_initcall(void)
 
 device_initcall(pl011_dma_initcall);
 
-static void pl011_dma_probe(struct uart_amba_port *uap)
+static void pl011_dma_probe(struct device *dev, struct uart_amba_port *uap)
 {
 	struct dma_uap *dmau = kzalloc(sizeof(struct dma_uap), GFP_KERNEL);
 	if (dmau) {
 		dmau->uap = uap;
+		dmau->dev = dev;
 		list_add_tail(&dmau->node, &pl011_dma_uarts);
 	}
 }
 #else
-static void pl011_dma_probe(struct uart_amba_port *uap)
+static void pl011_dma_probe(struct device *dev, struct uart_amba_port *uap)
 {
-	pl011_dma_probe_initcall(uap);
+	pl011_dma_probe_initcall(dev, uap);
 }
 #endif
 
@@ -991,7 +991,7 @@ static inline bool pl011_dma_rx_running(struct uart_amba_port *uap)
 
 #else
 /* Blank functions if the DMA engine is not available */
-static inline void pl011_dma_probe(struct uart_amba_port *uap)
+static inline void pl011_dma_probe(struct device *dev, struct uart_amba_port *uap)
 {
 }
 @@ -2020,7 +2032,7 @@ static int pl011_probe(struct amba_device *dev, const struct amba_id *id)
 	uap->port.ops = &amba_pl011_pops;
 	uap->port.flags = UPF_BOOT_AUTOCONF;
 	uap->port.line = i;
-	pl011_dma_probe(uap);
+	pl011_dma_probe(&dev->dev, uap);
 
 	/* Ensure interrupts from this UART are masked and cleared */
 	writew(0, uap->port.membase + UART011_IMSC);





From linus.walleij at linaro.org  Sat Apr 20 09:19:43 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Sat, 20 Apr 2013 15:19:43 +0200
Subject: [PATCH 1/4] clocksource: nomadik-mtu: fix up clocksource/timer
In-Reply-To: <1366463287-9922-1-git-send-email-linus.walleij@linaro.org>
References: <1366463287-9922-1-git-send-email-linus.walleij@linaro.org>
Message-ID: <CACRpkdYWSM0BK77qWbQWh0xsN+Ps95Q70zG-GE98MYvThrky2A@mail.gmail.com>

ARM SoC folks:

On Sat, Apr 20, 2013 at 3:08 PM, Linus Walleij <linus.walleij at linaro.org> wrote:

> The Nomadik clocksource driver has had a bad define making it
> impossible to use it for sched_clock() for a while. Fix this
> and also enable it for the Nomadik.
>
> Signed-off-by: Linus Walleij <linus.walleij at linaro.org>

This one should go to fixes ASAP, could you pick it to your fixes
branch? It could be tagged stable if desired - this only affects the
Nomadik which works just OK on jiffies so it's really no big regression.
The Ux500 does not use the MTU for sched_clock().

Yours,
Linus Walleij


From linus.walleij at linaro.org  Sat Apr 20 09:36:22 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Sat, 20 Apr 2013 15:36:22 +0200
Subject: [PATCH v3] ARM: pci: create pci_common_init_dev()
In-Reply-To: <20130419140633.GS14496@n2100.arm.linux.org.uk>
References: <1365788748-7908-1-git-send-email-linus.walleij@linaro.org>
 <20130413102929.GB30758@avionic-0098.mockup.avionic-design.de>
 <20130419140633.GS14496@n2100.arm.linux.org.uk>
Message-ID: <CACRpkdabcCLku2tzMogVo2G-i3BjemHN3HkgcD2+mt3tSEf9Og@mail.gmail.com>

On Fri, Apr 19, 2013 at 4:06 PM, Russell King - ARM Linux
<linux at arm.linux.org.uk> wrote:
> On Sat, Apr 13, 2013 at 12:29:29PM +0200, Thierry Reding wrote:
>> On Fri, Apr 12, 2013 at 07:45:48PM +0200, Linus Walleij wrote:
>> [...]
>> > +static inline void pci_common_init(struct hw_pci *hw) {
>>
>> I think that the CodingStyle rule for putting the opening brace on a
>> line by itself also applies to inline functions.
>>
>> Aside from that nit:
>>
>> Reviewed-by: Thierry Reding <thierry.reding at avionic-design.de>
>
> Strangely the patch never came through the mailing list.  Where can it
> be found?  Obviously this is core ARM code which is being touched so
> it should've been copied to me.

Yes the mail header looks like this:

Received: from mail.df.lth.se (mail.df.lth.se. [194.47.250.12])
        by mx.google.com with ESMTPS id w10si3088342lbw.255.2013.04.12.10.44.04
        (version=TLSv1 cipher=RC4-SHA bits=128/128);
        Fri, 12 Apr 2013 10:44:04 -0700 (PDT)
Received-SPF: pass (google.com: domain of triad at df.lth.se designates
194.47.250.12 as permitted sender) client-ip=194.47.250.12;
Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of triad at df.lth.se designates
194.47.250.12 as permitted sender) smtp.mail=triad at df.lth.se
Received: from mer.df.lth.se (mer.df.lth.se [194.47.250.37])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by mail.df.lth.se (Postfix) with ESMTPS id AA5C765D3A;
Fri, 12 Apr 2013 19:44:02 +0200 (CEST)
Received: from mer.df.lth.se (triad at localhost.localdomain [127.0.0.1])
by mer.df.lth.se (8.14.3/8.14.3/Debian-9.4) with ESMTP id r3CHi24v007862;
Fri, 12 Apr 2013 19:44:02 +0200
Received: (from triad at localhost)
by mer.df.lth.se (8.14.3/8.14.3/Submit) id r3CHhuSs007858;
Fri, 12 Apr 2013 19:43:56 +0200
From: Linus Walleij <linus.walleij at linaro.org>
To: linux-arm-kernel at lists.infradead.org
Cc: Linus Walleij <linus.walleij at linaro.org>,
        Mike Rapoport <mike at compulab.co.il>,
        Russell King <linux at arm.linux.org.uk>,
        Ralf Baechle <ralf at linux-mips.org>,
        Thierry Reding <thierry.reding at avionic-design.de>,
        Andrew Murray <andrew.murray at arm.com>, Arnd Bergmann <arnd at arndb.de>,
        Benjamin Herrenschmitt <benh at kernel.crashing.org>
Subject: [PATCH v2] ARM: pci: create pci_common_init_dev()
Date: Fri, 12 Apr 2013 19:43:48 +0200
Message-Id: <1365788628-7831-1-git-send-email-linus.walleij at linaro.org>
X-Mailer: git-send-email 1.7.2.5

So I suspect it might be that this listserver does not accept that I am sending
@linaro.org mails from a non-linaro.org mailserver (mail.df.lth.se).

I guess I'll try to figure out how to send mails out of that domains mail server
instead.

Here is the patch, inlined (it'll probably me mangled by gmails editor..)
>From cabfcde34c85e8f6b73a86f20e43f76b0a040484 Mon Sep 17 00:00:00 2001
From: Linus Walleij <linus.walleij at linaro.org>
Date: Thu, 11 Apr 2013 23:32:28 +0200
Subject: [PATCH] ARM: pci: create pci_common_init_dev()

When working with device tree support for PCI on ARM you run
into a problem when mapping IRQs from the device tree irqmaps:
doing this the code in drivers/of/of_pci_irq.c will try to
find the OF node on the root bridge and this fails, because
bus->dev.of_node is NULL, and that in turn boils down to
the fact that pci_set_bus_of_node() has called
pcibios_get_phb_of_node() from drivers/pci/of.c to obtain
the OF node of the bridge or its parent and none is set
and thus NULL is returned.

Fix this by adding an additional parent argument API for
registering PCI bridges on the ARM architecture called
pci_common_init_dev(), and pass along this parent to
pci_scan_root_bus() called from pcibios_init_hw() in
bios32.c and voila: the IRQ mappings start working:
the OF node can be retrieved from the parent.

Create the old pci_common_init() as a wrapper around
the new call.

Cc: Mike Rapoport <mike at compulab.co.il>
Cc: Russell King <rmk+kernel at arm.linux.org.uk>
Cc: Ralf Baechle <ralf at linux-mips.org>
Cc: Andrew Murray <andrew.murray at arm.com>
Cc: Arnd Bergmann <arnd at arndb.de>
Cc: Benjamin Herrenschmitt <benh at kernel.crashing.org>
Reviewed-by: Thierry Reding <thierry.reding at avionic-design.de>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
ChangeLog v3->v4:
- Put opening bracket on its own line.
- Use the proper rmk+kernel address for Russells CC.
---
 arch/arm/include/asm/mach/pci.h | 12 +++++++++++-
 arch/arm/kernel/bios32.c        |  9 +++++----
 2 files changed, 16 insertions(+), 5 deletions(-)

diff --git a/arch/arm/include/asm/mach/pci.h b/arch/arm/include/asm/mach/pci.h
index 5cf2e97..28ac12f 100644
--- a/arch/arm/include/asm/mach/pci.h
+++ b/arch/arm/include/asm/mach/pci.h
@@ -16,6 +16,7 @@
 struct pci_sys_data;
 struct pci_ops;
 struct pci_bus;
+struct device;

 struct hw_pci {
 #ifdef CONFIG_PCI_DOMAINS
@@ -57,7 +58,16 @@ struct pci_sys_data {
 /*
  * Call this with your hw_pci struct to initialise the PCI system.
  */
-void pci_common_init(struct hw_pci *);
+void pci_common_init_dev(struct device *, struct hw_pci *);
+
+/*
+ * Compatibility wrapper for older platforms that do not care about
+ * passing the parent device.
+ */
+static inline void pci_common_init(struct hw_pci *hw)
+{
+    pci_common_init_dev(NULL, hw);
+}

 /*
  * Setup early fixed I/O mapping.
diff --git a/arch/arm/kernel/bios32.c b/arch/arm/kernel/bios32.c
index a1f73b5..a99bde1 100644
--- a/arch/arm/kernel/bios32.c
+++ b/arch/arm/kernel/bios32.c
@@ -445,7 +445,8 @@ static int pcibios_init_resources(int busnr,
struct pci_sys_data *sys)
     return 0;
 }

-static void pcibios_init_hw(struct hw_pci *hw, struct list_head *head)
+static void pcibios_init_hw(struct device *parent, struct hw_pci *hw,
+                struct list_head *head)
 {
     struct pci_sys_data *sys = NULL;
     int ret;
@@ -479,7 +480,7 @@ static void pcibios_init_hw(struct hw_pci *hw,
struct list_head *head)
             if (hw->scan)
                 sys->bus = hw->scan(nr, sys);
             else
-                sys->bus = pci_scan_root_bus(NULL, sys->busnr,
+                sys->bus = pci_scan_root_bus(parent, sys->busnr,
                         hw->ops, sys, &sys->resources);

             if (!sys->bus)
@@ -496,7 +497,7 @@ static void pcibios_init_hw(struct hw_pci *hw,
struct list_head *head)
     }
 }

-void pci_common_init(struct hw_pci *hw)
+void pci_common_init_dev(struct device *parent, struct hw_pci *hw)
 {
     struct pci_sys_data *sys;
     LIST_HEAD(head);
@@ -504,7 +505,7 @@ void pci_common_init(struct hw_pci *hw)
     pci_add_flags(PCI_REASSIGN_ALL_RSRC);
     if (hw->preinit)
         hw->preinit();
-    pcibios_init_hw(hw, &head);
+    pcibios_init_hw(parent, hw, &head);
     if (hw->postinit)
         hw->postinit();

--
1.8.1.4



Yours,
Linus Walleij


From linus.walleij at linaro.org  Sat Apr 20 09:55:24 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Sat, 20 Apr 2013 15:55:24 +0200
Subject: [RESEND PATCH 00/12] Integrator/AP PCI DT mappings
Message-ID: <1366466124-15336-1-git-send-email-linus.walleij@linaro.org>

This is a resend of this patch series - it appears that the mail
servers do not like that I'm sending my mails from a certain
mail server. Retry using the apropriate linaro.org SMTP
server.

Linus Walleij (12):
  Documentation/devicetree: add a small note on PCI
  ARM: pci: create pci_common_init_dev()
  ARM: integrator: merge PCIv3 driver into one file
  ARM: integrator: convert PCIv3 bridge to platform device
  ARM: integrator: grab PCI error IRQ in probe()
  ARM: integrator: move PCI base address grab to probe
  ARM: integrator: move V3 register definitions into driver
  ARM: integrator: remap PCIv3 base dynamically
  ARM: integrator: move VGA base assignment
  ARM: integrator: move static ioremapping into PCIv3 driver
  ARM: integrator: basic PCIv3 device tree support
  ARM: integrator: get PCI device IRQs from device tree

 Documentation/devicetree/bindings/pci/pci.txt      |   9 +
 .../devicetree/bindings/pci/v3-v360epc-pci.txt     |  15 +
 .../devicetree/bindings/vendor-prefixes.txt        |   1 +
 arch/arm/boot/dts/integratorap.dts                 |  41 ++
 arch/arm/include/asm/hardware/pci_v3.h             | 186 --------
 arch/arm/include/asm/mach/pci.h                    |  17 +-
 arch/arm/kernel/bios32.c                           |   9 +-
 arch/arm/mach-integrator/Makefile                  |   2 +-
 arch/arm/mach-integrator/include/mach/platform.h   |  23 -
 arch/arm/mach-integrator/integrator_ap.c           |  31 +-
 arch/arm/mach-integrator/pci.c                     | 113 -----
 arch/arm/mach-integrator/pci_v3.c                  | 521 +++++++++++++++++++--
 arch/arm/mach-integrator/pci_v3.h                  |   2 +
 13 files changed, 564 insertions(+), 406 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/pci/pci.txt
 create mode 100644 Documentation/devicetree/bindings/pci/v3-v360epc-pci.txt
 delete mode 100644 arch/arm/include/asm/hardware/pci_v3.h
 delete mode 100644 arch/arm/mach-integrator/pci.c
 create mode 100644 arch/arm/mach-integrator/pci_v3.h

-- 
1.8.1.4



From linus.walleij at linaro.org  Sat Apr 20 09:55:33 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Sat, 20 Apr 2013 15:55:33 +0200
Subject: [RESEND PATCH 01/12] Documentation/devicetree: add a small note on PCI
Message-ID: <1366466133-15369-1-git-send-email-linus.walleij@linaro.org>

Throw in a file with references to the IEEE binding documents.

Acked-by: Arnd Bergmann <arnd at arndb.de>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 Documentation/devicetree/bindings/pci/pci.txt | 9 +++++++++
 1 file changed, 9 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pci/pci.txt

diff --git a/Documentation/devicetree/bindings/pci/pci.txt b/Documentation/devicetree/bindings/pci/pci.txt
new file mode 100644
index 0000000..41aeed3
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/pci.txt
@@ -0,0 +1,9 @@
+PCI bus bridges have standardized Device Tree bindings:
+
+PCI Bus Binding to: IEEE Std 1275-1994
+http://www.openfirmware.org/ofwg/bindings/pci/pci2_1.pdf
+
+And for the interrupt mapping part:
+
+Open Firmware Recommended Practice: Interrupt Mapping
+http://www.openfirmware.org/1275/practice/imap/imap0_9d.pdf
-- 
1.8.1.4



From linus.walleij at linaro.org  Sat Apr 20 09:55:41 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Sat, 20 Apr 2013 15:55:41 +0200
Subject: [RESEND PATCH 02/12 v4] ARM: pci: create pci_common_init_dev()
Message-ID: <1366466141-15405-1-git-send-email-linus.walleij@linaro.org>

When working with device tree support for PCI on ARM you run
into a problem when mapping IRQs from the device tree irqmaps:
doing this the code in drivers/of/of_pci_irq.c will try to
find the OF node on the root bridge and this fails, because
bus->dev.of_node is NULL, and that in turn boils down to
the fact that pci_set_bus_of_node() has called
pcibios_get_phb_of_node() from drivers/pci/of.c to obtain
the OF node of the bridge or its parent and none is set
and thus NULL is returned.

Fix this by adding an additional parent argument API for
registering PCI bridges on the ARM architecture called
pci_common_init_dev(), and pass along this parent to
pci_scan_root_bus() called from pcibios_init_hw() in
bios32.c and voila: the IRQ mappings start working:
the OF node can be retrieved from the parent.

Create the old pci_common_init() as a wrapper around
the new call.

Cc: Mike Rapoport <mike at compulab.co.il>
Cc: Russell King <rmk+kernel at arm.linux.org.uk>
Cc: Ralf Baechle <ralf at linux-mips.org>
Cc: Andrew Murray <andrew.murray at arm.com>
Cc: Arnd Bergmann <arnd at arndb.de>
Cc: Benjamin Herrenschmitt <benh at kernel.crashing.org>
Reviewed-by: Thierry Reding <thierry.reding at avionic-design.de>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
ChangeLog v3->v4:
- Put opening bracket on its own line.
- Use the proper rmk+kernel address for Russells CC.
---
 arch/arm/include/asm/mach/pci.h | 12 +++++++++++-
 arch/arm/kernel/bios32.c        |  9 +++++----
 2 files changed, 16 insertions(+), 5 deletions(-)

diff --git a/arch/arm/include/asm/mach/pci.h b/arch/arm/include/asm/mach/pci.h
index 5cf2e97..28ac12f 100644
--- a/arch/arm/include/asm/mach/pci.h
+++ b/arch/arm/include/asm/mach/pci.h
@@ -16,6 +16,7 @@
 struct pci_sys_data;
 struct pci_ops;
 struct pci_bus;
+struct device;
 
 struct hw_pci {
 #ifdef CONFIG_PCI_DOMAINS
@@ -57,7 +58,16 @@ struct pci_sys_data {
 /*
  * Call this with your hw_pci struct to initialise the PCI system.
  */
-void pci_common_init(struct hw_pci *);
+void pci_common_init_dev(struct device *, struct hw_pci *);
+
+/*
+ * Compatibility wrapper for older platforms that do not care about
+ * passing the parent device.
+ */
+static inline void pci_common_init(struct hw_pci *hw)
+{
+	pci_common_init_dev(NULL, hw);
+}
 
 /*
  * Setup early fixed I/O mapping.
diff --git a/arch/arm/kernel/bios32.c b/arch/arm/kernel/bios32.c
index a1f73b5..a99bde1 100644
--- a/arch/arm/kernel/bios32.c
+++ b/arch/arm/kernel/bios32.c
@@ -445,7 +445,8 @@ static int pcibios_init_resources(int busnr, struct pci_sys_data *sys)
 	return 0;
 }
 
-static void pcibios_init_hw(struct hw_pci *hw, struct list_head *head)
+static void pcibios_init_hw(struct device *parent, struct hw_pci *hw,
+			    struct list_head *head)
 {
 	struct pci_sys_data *sys = NULL;
 	int ret;
@@ -479,7 +480,7 @@ static void pcibios_init_hw(struct hw_pci *hw, struct list_head *head)
 			if (hw->scan)
 				sys->bus = hw->scan(nr, sys);
 			else
-				sys->bus = pci_scan_root_bus(NULL, sys->busnr,
+				sys->bus = pci_scan_root_bus(parent, sys->busnr,
 						hw->ops, sys, &sys->resources);
 
 			if (!sys->bus)
@@ -496,7 +497,7 @@ static void pcibios_init_hw(struct hw_pci *hw, struct list_head *head)
 	}
 }
 
-void pci_common_init(struct hw_pci *hw)
+void pci_common_init_dev(struct device *parent, struct hw_pci *hw)
 {
 	struct pci_sys_data *sys;
 	LIST_HEAD(head);
@@ -504,7 +505,7 @@ void pci_common_init(struct hw_pci *hw)
 	pci_add_flags(PCI_REASSIGN_ALL_RSRC);
 	if (hw->preinit)
 		hw->preinit();
-	pcibios_init_hw(hw, &head);
+	pcibios_init_hw(parent, hw, &head);
 	if (hw->postinit)
 		hw->postinit();
 
-- 
1.8.1.4



From linus.walleij at linaro.org  Sat Apr 20 09:55:48 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Sat, 20 Apr 2013 15:55:48 +0200
Subject: [RESEND PATCH 03/12] ARM: integrator: merge PCIv3 driver into one file
Message-ID: <1366466148-15434-1-git-send-email-linus.walleij@linaro.org>

The Integrator/AP PCI bridget, "v3" is contained in two files,
where pci.c is a socket container to plug in the v3 device.
However to transition the v3 to enable device tree probing, it
need to be converted to a platform device (so that it can have
a device node in the device tree) and then we want the PCI
driver in a single file, as any other device driver, so we can
handle variants using compatible strings and device name,
and get the base address etc from resources connected to the
device node.

To move toward this goal we consolidate all code in the
pci_v3.c file.

Acked-by: Arnd Bergmann <arnd at arndb.de>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 arch/arm/include/asm/mach/pci.h   |   5 --
 arch/arm/mach-integrator/Makefile |   2 +-
 arch/arm/mach-integrator/pci.c    | 113 --------------------------------------
 arch/arm/mach-integrator/pci_v3.c |  88 +++++++++++++++++++++++++++--
 4 files changed, 85 insertions(+), 123 deletions(-)
 delete mode 100644 arch/arm/mach-integrator/pci.c

diff --git a/arch/arm/include/asm/mach/pci.h b/arch/arm/include/asm/mach/pci.h
index 28ac12f..b7b166b 100644
--- a/arch/arm/include/asm/mach/pci.h
+++ b/arch/arm/include/asm/mach/pci.h
@@ -95,9 +95,4 @@ extern struct pci_ops via82c505_ops;
 extern int via82c505_setup(int nr, struct pci_sys_data *);
 extern void via82c505_init(void *sysdata);
 
-extern struct pci_ops pci_v3_ops;
-extern int pci_v3_setup(int nr, struct pci_sys_data *);
-extern void pci_v3_preinit(void);
-extern void pci_v3_postinit(void);
-
 #endif /* __ASM_MACH_PCI_H */
diff --git a/arch/arm/mach-integrator/Makefile b/arch/arm/mach-integrator/Makefile
index 5521d18..e1e4eed 100644
--- a/arch/arm/mach-integrator/Makefile
+++ b/arch/arm/mach-integrator/Makefile
@@ -8,6 +8,6 @@ obj-y					:= core.o lm.o leds.o
 obj-$(CONFIG_ARCH_INTEGRATOR_AP)	+= integrator_ap.o
 obj-$(CONFIG_ARCH_INTEGRATOR_CP)	+= integrator_cp.o
 
-obj-$(CONFIG_PCI)			+= pci_v3.o pci.o
+obj-$(CONFIG_PCI)			+= pci_v3.o
 obj-$(CONFIG_CPU_FREQ_INTEGRATOR)	+= cpu.o
 obj-$(CONFIG_INTEGRATOR_IMPD1)		+= impd1.o
diff --git a/arch/arm/mach-integrator/pci.c b/arch/arm/mach-integrator/pci.c
deleted file mode 100644
index 6c1667e..0000000
--- a/arch/arm/mach-integrator/pci.c
+++ /dev/null
@@ -1,113 +0,0 @@
-/*
- *  linux/arch/arm/mach-integrator/pci-integrator.c
- *
- *  Copyright (C) 1999 ARM Limited
- *  Copyright (C) 2000 Deep Blue Solutions Ltd
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
- *
- *
- *  PCI functions for Integrator
- */
-#include <linux/kernel.h>
-#include <linux/pci.h>
-#include <linux/interrupt.h>
-#include <linux/init.h>
-
-#include <asm/mach/pci.h>
-#include <asm/mach-types.h>
-
-#include <mach/irqs.h>
-
-/* 
- * A small note about bridges and interrupts.  The DECchip 21050 (and
- * later) adheres to the PCI-PCI bridge specification.  This says that
- * the interrupts on the other side of a bridge are swizzled in the
- * following manner:
- *
- * Dev    Interrupt   Interrupt 
- *        Pin on      Pin on 
- *        Device      Connector
- *
- *   4    A           A
- *        B           B
- *        C           C
- *        D           D
- * 
- *   5    A           B
- *        B           C
- *        C           D
- *        D           A
- *
- *   6    A           C
- *        B           D
- *        C           A
- *        D           B
- *
- *   7    A           D
- *        B           A
- *        C           B
- *        D           C
- *
- * Where A = pin 1, B = pin 2 and so on and pin=0 = default = A.
- * Thus, each swizzle is ((pin-1) + (device#-4)) % 4
- */
-
-/*
- * This routine handles multiple bridges.
- */
-static u8 __init integrator_swizzle(struct pci_dev *dev, u8 *pinp)
-{
-	if (*pinp == 0)
-		*pinp = 1;
-
-	return pci_common_swizzle(dev, pinp);
-}
-
-static int irq_tab[4] __initdata = {
-	IRQ_AP_PCIINT0,	IRQ_AP_PCIINT1,	IRQ_AP_PCIINT2,	IRQ_AP_PCIINT3
-};
-
-/*
- * map the specified device/slot/pin to an IRQ.  This works out such
- * that slot 9 pin 1 is INT0, pin 2 is INT1, and slot 10 pin 1 is INT1.
- */
-static int __init integrator_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
-{
-	int intnr = ((slot - 9) + (pin - 1)) & 3;
-
-	return irq_tab[intnr];
-}
-
-extern void pci_v3_init(void *);
-
-static struct hw_pci integrator_pci __initdata = {
-	.swizzle		= integrator_swizzle,
-	.map_irq		= integrator_map_irq,
-	.setup			= pci_v3_setup,
-	.nr_controllers		= 1,
-	.ops			= &pci_v3_ops,
-	.preinit		= pci_v3_preinit,
-	.postinit		= pci_v3_postinit,
-};
-
-static int __init integrator_pci_init(void)
-{
-	if (machine_is_integrator())
-		pci_common_init(&integrator_pci);
-	return 0;
-}
-
-subsys_initcall(integrator_pci_init);
diff --git a/arch/arm/mach-integrator/pci_v3.c b/arch/arm/mach-integrator/pci_v3.c
index e7fcea7..b8d7033 100644
--- a/arch/arm/mach-integrator/pci_v3.c
+++ b/arch/arm/mach-integrator/pci_v3.c
@@ -35,6 +35,7 @@
 #include <asm/signal.h>
 #include <asm/mach/pci.h>
 #include <asm/irq_regs.h>
+#include <asm/mach-types.h>
 
 #include <asm/hardware/pci_v3.h>
 
@@ -337,7 +338,7 @@ static int v3_write_config(struct pci_bus *bus, unsigned int devfn, int where,
 	return PCIBIOS_SUCCESSFUL;
 }
 
-struct pci_ops pci_v3_ops = {
+static struct pci_ops pci_v3_ops = {
 	.read	= v3_read_config,
 	.write	= v3_write_config,
 };
@@ -471,7 +472,7 @@ static irqreturn_t v3_irq(int dummy, void *devid)
 	return IRQ_HANDLED;
 }
 
-int __init pci_v3_setup(int nr, struct pci_sys_data *sys)
+static int __init pci_v3_setup(int nr, struct pci_sys_data *sys)
 {
 	int ret = 0;
 
@@ -490,7 +491,7 @@ int __init pci_v3_setup(int nr, struct pci_sys_data *sys)
  * V3_LB_BASE? - local bus address
  * V3_LB_MAP?  - pci bus address
  */
-void __init pci_v3_preinit(void)
+static void __init pci_v3_preinit(void)
 {
 	unsigned long flags;
 	unsigned int temp;
@@ -589,7 +590,7 @@ void __init pci_v3_preinit(void)
 	raw_spin_unlock_irqrestore(&v3_lock, flags);
 }
 
-void __init pci_v3_postinit(void)
+static void __init pci_v3_postinit(void)
 {
 	unsigned int pci_cmd;
 
@@ -610,3 +611,82 @@ void __init pci_v3_postinit(void)
 
 	register_isa_ports(PHYS_PCI_MEM_BASE, PHYS_PCI_IO_BASE, 0);
 }
+
+/*
+ * A small note about bridges and interrupts.  The DECchip 21050 (and
+ * later) adheres to the PCI-PCI bridge specification.  This says that
+ * the interrupts on the other side of a bridge are swizzled in the
+ * following manner:
+ *
+ * Dev    Interrupt   Interrupt
+ *        Pin on      Pin on
+ *        Device      Connector
+ *
+ *   4    A           A
+ *        B           B
+ *        C           C
+ *        D           D
+ *
+ *   5    A           B
+ *        B           C
+ *        C           D
+ *        D           A
+ *
+ *   6    A           C
+ *        B           D
+ *        C           A
+ *        D           B
+ *
+ *   7    A           D
+ *        B           A
+ *        C           B
+ *        D           C
+ *
+ * Where A = pin 1, B = pin 2 and so on and pin=0 = default = A.
+ * Thus, each swizzle is ((pin-1) + (device#-4)) % 4
+ */
+
+/*
+ * This routine handles multiple bridges.
+ */
+static u8 __init integrator_swizzle(struct pci_dev *dev, u8 *pinp)
+{
+	if (*pinp == 0)
+		*pinp = 1;
+
+	return pci_common_swizzle(dev, pinp);
+}
+
+static int irq_tab[4] __initdata = {
+	IRQ_AP_PCIINT0,	IRQ_AP_PCIINT1,	IRQ_AP_PCIINT2,	IRQ_AP_PCIINT3
+};
+
+/*
+ * map the specified device/slot/pin to an IRQ.  This works out such
+ * that slot 9 pin 1 is INT0, pin 2 is INT1, and slot 10 pin 1 is INT1.
+ */
+static int __init integrator_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
+{
+	int intnr = ((slot - 9) + (pin - 1)) & 3;
+
+	return irq_tab[intnr];
+}
+
+static struct hw_pci integrator_pci __initdata = {
+	.swizzle		= integrator_swizzle,
+	.map_irq		= integrator_map_irq,
+	.setup			= pci_v3_setup,
+	.nr_controllers		= 1,
+	.ops			= &pci_v3_ops,
+	.preinit		= pci_v3_preinit,
+	.postinit		= pci_v3_postinit,
+};
+
+static int __init integrator_pci_init(void)
+{
+	if (machine_is_integrator())
+		pci_common_init(&integrator_pci);
+	return 0;
+}
+
+subsys_initcall(integrator_pci_init);
-- 
1.8.1.4



From linus.walleij at linaro.org  Sat Apr 20 09:55:56 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Sat, 20 Apr 2013 15:55:56 +0200
Subject: [RESEND PATCH 04/12] ARM: integrator: convert PCIv3 bridge to
 platform device
Message-ID: <1366466156-15463-1-git-send-email-linus.walleij@linaro.org>

This converts the PCIv3 driver to a platform device driver, and
registers the device only on the Integrator/AP instead of bailing
out in the initcall if the platform is not correct.

Acked-by: Arnd Bergmann <arnd at arndb.de>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 arch/arm/mach-integrator/integrator_ap.c | 17 +++++++++++++++++
 arch/arm/mach-integrator/pci_v3.c        | 30 ++++++++++++++++++++----------
 2 files changed, 37 insertions(+), 10 deletions(-)

diff --git a/arch/arm/mach-integrator/integrator_ap.c b/arch/arm/mach-integrator/integrator_ap.c
index ea96144..f190bab 100644
--- a/arch/arm/mach-integrator/integrator_ap.c
+++ b/arch/arm/mach-integrator/integrator_ap.c
@@ -494,6 +494,15 @@ static struct of_dev_auxdata ap_auxdata_lookup[] __initdata = {
 	{ /* sentinel */ },
 };
 
+/*
+ * This is a placeholder that will get deleted when we move the PCI
+ * device over to the device tree.
+ */
+static struct platform_device pci_v3_device_of = {
+	.name		= "pci-v3",
+	.id		= 0,
+};
+
 static void __init ap_init_of(void)
 {
 	unsigned long sc_dec;
@@ -550,6 +559,8 @@ static void __init ap_init_of(void)
 	of_platform_populate(root, of_default_bus_match_table,
 			ap_auxdata_lookup, parent);
 
+	platform_device_register(&pci_v3_device_of);
+
 	sc_dec = readl(ap_syscon_base + INTEGRATOR_SC_DEC_OFFSET);
 	for (i = 0; i < 4; i++) {
 		struct lm_device *lmdev;
@@ -617,6 +628,11 @@ static void __init ap_map_io_atag(void)
  * for eventual deletion.
  */
 
+static struct platform_device pci_v3_device = {
+	.name		= "pci-v3",
+	.id		= 0,
+};
+
 static struct resource cfi_flash_resource = {
 	.start		= INTEGRATOR_FLASH_BASE,
 	.end		= INTEGRATOR_FLASH_BASE + INTEGRATOR_FLASH_SIZE - 1,
@@ -674,6 +690,7 @@ static void __init ap_init(void)
 	unsigned long sc_dec;
 	int i;
 
+	platform_device_register(&pci_v3_device);
 	platform_device_register(&cfi_flash_device);
 
 	ap_syscon_base = __io_address(INTEGRATOR_SC_BASE);
diff --git a/arch/arm/mach-integrator/pci_v3.c b/arch/arm/mach-integrator/pci_v3.c
index b8d7033..2733c6c 100644
--- a/arch/arm/mach-integrator/pci_v3.c
+++ b/arch/arm/mach-integrator/pci_v3.c
@@ -27,6 +27,7 @@
 #include <linux/spinlock.h>
 #include <linux/init.h>
 #include <linux/io.h>
+#include <linux/platform_device.h>
 
 #include <mach/hardware.h>
 #include <mach/platform.h>
@@ -35,7 +36,6 @@
 #include <asm/signal.h>
 #include <asm/mach/pci.h>
 #include <asm/irq_regs.h>
-#include <asm/mach-types.h>
 
 #include <asm/hardware/pci_v3.h>
 
@@ -649,7 +649,7 @@ static void __init pci_v3_postinit(void)
 /*
  * This routine handles multiple bridges.
  */
-static u8 __init integrator_swizzle(struct pci_dev *dev, u8 *pinp)
+static u8 __init pci_v3_swizzle(struct pci_dev *dev, u8 *pinp)
 {
 	if (*pinp == 0)
 		*pinp = 1;
@@ -665,16 +665,16 @@ static int irq_tab[4] __initdata = {
  * map the specified device/slot/pin to an IRQ.  This works out such
  * that slot 9 pin 1 is INT0, pin 2 is INT1, and slot 10 pin 1 is INT1.
  */
-static int __init integrator_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
+static int __init pci_v3_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
 {
 	int intnr = ((slot - 9) + (pin - 1)) & 3;
 
 	return irq_tab[intnr];
 }
 
-static struct hw_pci integrator_pci __initdata = {
-	.swizzle		= integrator_swizzle,
-	.map_irq		= integrator_map_irq,
+static struct hw_pci pci_v3 __initdata = {
+	.swizzle		= pci_v3_swizzle,
+	.map_irq		= pci_v3_map_irq,
 	.setup			= pci_v3_setup,
 	.nr_controllers		= 1,
 	.ops			= &pci_v3_ops,
@@ -682,11 +682,21 @@ static struct hw_pci integrator_pci __initdata = {
 	.postinit		= pci_v3_postinit,
 };
 
-static int __init integrator_pci_init(void)
+static int __init pci_v3_probe(struct platform_device *pdev)
 {
-	if (machine_is_integrator())
-		pci_common_init(&integrator_pci);
+	pci_common_init(&pci_v3);
 	return 0;
 }
 
-subsys_initcall(integrator_pci_init);
+static struct platform_driver pci_v3_driver = {
+	.driver = {
+		.name = "pci-v3",
+	},
+};
+
+static int __init pci_v3_init(void)
+{
+	return platform_driver_probe(&pci_v3_driver, pci_v3_probe);
+}
+
+subsys_initcall(pci_v3_init);
-- 
1.8.1.4



From linus.walleij at linaro.org  Sat Apr 20 09:56:03 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Sat, 20 Apr 2013 15:56:03 +0200
Subject: [RESEND PATCH 05/12] ARM: integrator: grab PCI error IRQ in probe()
Message-ID: <1366466163-15492-1-git-send-email-linus.walleij@linaro.org>

This moves the request of the PCI error interrupt to the probe()
function for the device, uses the devm* managed call and switch
to a dev_err() error print.

Acked-by: Arnd Bergmann <arnd at arndb.de>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 arch/arm/mach-integrator/pci_v3.c | 19 ++++++++++---------
 1 file changed, 10 insertions(+), 9 deletions(-)

diff --git a/arch/arm/mach-integrator/pci_v3.c b/arch/arm/mach-integrator/pci_v3.c
index 2733c6c..f027596 100644
--- a/arch/arm/mach-integrator/pci_v3.c
+++ b/arch/arm/mach-integrator/pci_v3.c
@@ -495,7 +495,6 @@ static void __init pci_v3_preinit(void)
 {
 	unsigned long flags;
 	unsigned int temp;
-	int ret;
 
 	/* Remap the Integrator system controller */
 	ap_syscon_base = ioremap(INTEGRATOR_SC_BASE, 0x100);
@@ -579,14 +578,6 @@ static void __init pci_v3_preinit(void)
 	v3_writeb(V3_LB_IMASK, 0x28);
 	__raw_writel(3, ap_syscon_base + INTEGRATOR_SC_PCIENABLE_OFFSET);
 
-	/*
-	 * Grab the PCI error interrupt.
-	 */
-	ret = request_irq(IRQ_AP_V3INT, v3_irq, 0, "V3", NULL);
-	if (ret)
-		printk(KERN_ERR "PCI: unable to grab PCI error "
-		       "interrupt: %d\n", ret);
-
 	raw_spin_unlock_irqrestore(&v3_lock, flags);
 }
 
@@ -684,7 +675,17 @@ static struct hw_pci pci_v3 __initdata = {
 
 static int __init pci_v3_probe(struct platform_device *pdev)
 {
+	int ret;
+
+	ret = devm_request_irq(&pdev->dev, IRQ_AP_V3INT, v3_irq, 0, "V3", NULL);
+	if (ret) {
+		dev_err(&pdev->dev, "unable to grab PCI error interrupt: %d\n",
+			ret);
+		return -ENODEV;
+	}
+
 	pci_common_init(&pci_v3);
+
 	return 0;
 }
 
-- 
1.8.1.4



From linus.walleij at linaro.org  Sat Apr 20 09:56:11 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Sat, 20 Apr 2013 15:56:11 +0200
Subject: [RESEND PATCH 06/12] ARM: integrator: move PCI base address grab to
 probe
Message-ID: <1366466171-15521-1-git-send-email-linus.walleij@linaro.org>

This moves the point where the PCIv3 driver grabs the SC base
address to the probe function.

Acked-by: Arnd Bergmann <arnd at arndb.de>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 arch/arm/mach-integrator/pci_v3.c | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/arm/mach-integrator/pci_v3.c b/arch/arm/mach-integrator/pci_v3.c
index f027596..756a5f2 100644
--- a/arch/arm/mach-integrator/pci_v3.c
+++ b/arch/arm/mach-integrator/pci_v3.c
@@ -496,13 +496,6 @@ static void __init pci_v3_preinit(void)
 	unsigned long flags;
 	unsigned int temp;
 
-	/* Remap the Integrator system controller */
-	ap_syscon_base = ioremap(INTEGRATOR_SC_BASE, 0x100);
-	if (!ap_syscon_base) {
-		pr_err("unable to remap the AP syscon for PCIv3\n");
-		return;
-	}
-
 	pcibios_min_mem = 0x00100000;
 
 	/*
@@ -677,6 +670,13 @@ static int __init pci_v3_probe(struct platform_device *pdev)
 {
 	int ret;
 
+	/* Remap the Integrator system controller */
+	ap_syscon_base = ioremap(INTEGRATOR_SC_BASE, 0x100);
+	if (!ap_syscon_base) {
+		dev_err(&pdev->dev, "unable to remap the AP syscon for PCIv3\n");
+		return -ENODEV;
+	}
+
 	ret = devm_request_irq(&pdev->dev, IRQ_AP_V3INT, v3_irq, 0, "V3", NULL);
 	if (ret) {
 		dev_err(&pdev->dev, "unable to grab PCI error interrupt: %d\n",
-- 
1.8.1.4



From linus.walleij at linaro.org  Sat Apr 20 09:56:18 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Sat, 20 Apr 2013 15:56:18 +0200
Subject: [RESEND PATCH 07/12] ARM: integrator: move V3 register definitions
 into driver
Message-ID: <1366466178-15550-1-git-send-email-linus.walleij@linaro.org>

This moves the PCIv3 register definitions into the driver itself.
There is no other driver or board code including this file, nor
will there be. If some other platform needs this driver it should
be generalized to support several platforms.

Acked-by: Arnd Bergmann <arnd at arndb.de>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 arch/arm/include/asm/hardware/pci_v3.h | 186 ---------------------------------
 arch/arm/mach-integrator/pci_v3.c      | 160 +++++++++++++++++++++++++++-
 2 files changed, 159 insertions(+), 187 deletions(-)
 delete mode 100644 arch/arm/include/asm/hardware/pci_v3.h

diff --git a/arch/arm/include/asm/hardware/pci_v3.h b/arch/arm/include/asm/hardware/pci_v3.h
deleted file mode 100644
index 2811c7e..0000000
--- a/arch/arm/include/asm/hardware/pci_v3.h
+++ /dev/null
@@ -1,186 +0,0 @@
-/*
- *  arch/arm/include/asm/hardware/pci_v3.h
- *
- *  Internal header file PCI V3 chip
- *
- *  Copyright (C) ARM Limited
- *  Copyright (C) 2000-2001 Deep Blue Solutions Ltd.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
- */
-#ifndef ASM_ARM_HARDWARE_PCI_V3_H
-#define ASM_ARM_HARDWARE_PCI_V3_H
-
-/* -------------------------------------------------------------------------------
- *  V3 Local Bus to PCI Bridge definitions
- * -------------------------------------------------------------------------------
- *  Registers (these are taken from page 129 of the EPC User's Manual Rev 1.04
- *  All V3 register names are prefaced by V3_ to avoid clashing with any other
- *  PCI definitions.  Their names match the user's manual.
- * 
- *  I'm assuming that I20 is disabled.
- * 
- */
-#define V3_PCI_VENDOR                   0x00000000
-#define V3_PCI_DEVICE                   0x00000002
-#define V3_PCI_CMD                      0x00000004
-#define V3_PCI_STAT                     0x00000006
-#define V3_PCI_CC_REV                   0x00000008
-#define V3_PCI_HDR_CFG                  0x0000000C
-#define V3_PCI_IO_BASE                  0x00000010
-#define V3_PCI_BASE0                    0x00000014
-#define V3_PCI_BASE1                    0x00000018
-#define V3_PCI_SUB_VENDOR               0x0000002C
-#define V3_PCI_SUB_ID                   0x0000002E
-#define V3_PCI_ROM                      0x00000030
-#define V3_PCI_BPARAM                   0x0000003C
-#define V3_PCI_MAP0                     0x00000040
-#define V3_PCI_MAP1                     0x00000044
-#define V3_PCI_INT_STAT                 0x00000048
-#define V3_PCI_INT_CFG                  0x0000004C 
-#define V3_LB_BASE0                     0x00000054
-#define V3_LB_BASE1                     0x00000058
-#define V3_LB_MAP0                      0x0000005E
-#define V3_LB_MAP1                      0x00000062
-#define V3_LB_BASE2                     0x00000064
-#define V3_LB_MAP2                      0x00000066
-#define V3_LB_SIZE                      0x00000068
-#define V3_LB_IO_BASE                   0x0000006E
-#define V3_FIFO_CFG                     0x00000070
-#define V3_FIFO_PRIORITY                0x00000072
-#define V3_FIFO_STAT                    0x00000074
-#define V3_LB_ISTAT                     0x00000076
-#define V3_LB_IMASK                     0x00000077
-#define V3_SYSTEM                       0x00000078
-#define V3_LB_CFG                       0x0000007A
-#define V3_PCI_CFG                      0x0000007C
-#define V3_DMA_PCI_ADR0                 0x00000080
-#define V3_DMA_PCI_ADR1                 0x00000090
-#define V3_DMA_LOCAL_ADR0               0x00000084
-#define V3_DMA_LOCAL_ADR1               0x00000094
-#define V3_DMA_LENGTH0                  0x00000088
-#define V3_DMA_LENGTH1                  0x00000098
-#define V3_DMA_CSR0                     0x0000008B
-#define V3_DMA_CSR1                     0x0000009B
-#define V3_DMA_CTLB_ADR0                0x0000008C
-#define V3_DMA_CTLB_ADR1                0x0000009C
-#define V3_DMA_DELAY                    0x000000E0
-#define V3_MAIL_DATA                    0x000000C0
-#define V3_PCI_MAIL_IEWR                0x000000D0
-#define V3_PCI_MAIL_IERD                0x000000D2
-#define V3_LB_MAIL_IEWR                 0x000000D4
-#define V3_LB_MAIL_IERD                 0x000000D6
-#define V3_MAIL_WR_STAT                 0x000000D8
-#define V3_MAIL_RD_STAT                 0x000000DA
-#define V3_QBA_MAP                      0x000000DC
-
-/*  PCI COMMAND REGISTER bits
- */
-#define V3_COMMAND_M_FBB_EN             (1 << 9)
-#define V3_COMMAND_M_SERR_EN            (1 << 8)
-#define V3_COMMAND_M_PAR_EN             (1 << 6)
-#define V3_COMMAND_M_MASTER_EN          (1 << 2)
-#define V3_COMMAND_M_MEM_EN             (1 << 1)
-#define V3_COMMAND_M_IO_EN              (1 << 0)
-
-/*  SYSTEM REGISTER bits
- */
-#define V3_SYSTEM_M_RST_OUT             (1 << 15)
-#define V3_SYSTEM_M_LOCK                (1 << 14)
-
-/*  PCI_CFG bits
- */
-#define V3_PCI_CFG_M_I2O_EN		(1 << 15)
-#define V3_PCI_CFG_M_IO_REG_DIS		(1 << 14)
-#define V3_PCI_CFG_M_IO_DIS		(1 << 13)
-#define V3_PCI_CFG_M_EN3V		(1 << 12)
-#define V3_PCI_CFG_M_RETRY_EN           (1 << 10)
-#define V3_PCI_CFG_M_AD_LOW1            (1 << 9)
-#define V3_PCI_CFG_M_AD_LOW0            (1 << 8)
-
-/*  PCI_BASE register bits (PCI -> Local Bus)
- */
-#define V3_PCI_BASE_M_ADR_BASE          0xFFF00000
-#define V3_PCI_BASE_M_ADR_BASEL         0x000FFF00
-#define V3_PCI_BASE_M_PREFETCH          (1 << 3)
-#define V3_PCI_BASE_M_TYPE              (3 << 1)
-#define V3_PCI_BASE_M_IO                (1 << 0)
-
-/*  PCI MAP register bits (PCI -> Local bus)
- */
-#define V3_PCI_MAP_M_MAP_ADR            0xFFF00000
-#define V3_PCI_MAP_M_RD_POST_INH        (1 << 15)
-#define V3_PCI_MAP_M_ROM_SIZE           (3 << 10)
-#define V3_PCI_MAP_M_SWAP               (3 << 8)
-#define V3_PCI_MAP_M_ADR_SIZE           0x000000F0
-#define V3_PCI_MAP_M_REG_EN             (1 << 1)
-#define V3_PCI_MAP_M_ENABLE             (1 << 0)
-
-/*
- *  LB_BASE0,1 register bits (Local bus -> PCI)
- */
-#define V3_LB_BASE_ADR_BASE		0xfff00000
-#define V3_LB_BASE_SWAP			(3 << 8)
-#define V3_LB_BASE_ADR_SIZE		(15 << 4)
-#define V3_LB_BASE_PREFETCH		(1 << 3)
-#define V3_LB_BASE_ENABLE		(1 << 0)
-
-#define V3_LB_BASE_ADR_SIZE_1MB		(0 << 4)
-#define V3_LB_BASE_ADR_SIZE_2MB		(1 << 4)
-#define V3_LB_BASE_ADR_SIZE_4MB		(2 << 4)
-#define V3_LB_BASE_ADR_SIZE_8MB		(3 << 4)
-#define V3_LB_BASE_ADR_SIZE_16MB	(4 << 4)
-#define V3_LB_BASE_ADR_SIZE_32MB	(5 << 4)
-#define V3_LB_BASE_ADR_SIZE_64MB	(6 << 4)
-#define V3_LB_BASE_ADR_SIZE_128MB	(7 << 4)
-#define V3_LB_BASE_ADR_SIZE_256MB	(8 << 4)
-#define V3_LB_BASE_ADR_SIZE_512MB	(9 << 4)
-#define V3_LB_BASE_ADR_SIZE_1GB		(10 << 4)
-#define V3_LB_BASE_ADR_SIZE_2GB		(11 << 4)
-
-#define v3_addr_to_lb_base(a)	((a) & V3_LB_BASE_ADR_BASE)
-
-/*
- *  LB_MAP0,1 register bits (Local bus -> PCI)
- */
-#define V3_LB_MAP_MAP_ADR		0xfff0
-#define V3_LB_MAP_TYPE			(7 << 1)
-#define V3_LB_MAP_AD_LOW_EN		(1 << 0)
-
-#define V3_LB_MAP_TYPE_IACK		(0 << 1)
-#define V3_LB_MAP_TYPE_IO		(1 << 1)
-#define V3_LB_MAP_TYPE_MEM		(3 << 1)
-#define V3_LB_MAP_TYPE_CONFIG		(5 << 1)
-#define V3_LB_MAP_TYPE_MEM_MULTIPLE	(6 << 1)
-
-#define v3_addr_to_lb_map(a)	(((a) >> 16) & V3_LB_MAP_MAP_ADR)
-
-/*
- *  LB_BASE2 register bits (Local bus -> PCI IO)
- */
-#define V3_LB_BASE2_ADR_BASE		0xff00
-#define V3_LB_BASE2_SWAP		(3 << 6)
-#define V3_LB_BASE2_ENABLE		(1 << 0)
-
-#define v3_addr_to_lb_base2(a)	(((a) >> 16) & V3_LB_BASE2_ADR_BASE)
-
-/*
- *  LB_MAP2 register bits (Local bus -> PCI IO)
- */
-#define V3_LB_MAP2_MAP_ADR		0xff00
-
-#define v3_addr_to_lb_map2(a)	(((a) >> 16) & V3_LB_MAP2_MAP_ADR)
-
-#endif
diff --git a/arch/arm/mach-integrator/pci_v3.c b/arch/arm/mach-integrator/pci_v3.c
index 756a5f2..604064b 100644
--- a/arch/arm/mach-integrator/pci_v3.c
+++ b/arch/arm/mach-integrator/pci_v3.c
@@ -37,7 +37,165 @@
 #include <asm/mach/pci.h>
 #include <asm/irq_regs.h>
 
-#include <asm/hardware/pci_v3.h>
+/*
+ * V3 Local Bus to PCI Bridge definitions
+ *
+ * Registers (these are taken from page 129 of the EPC User's Manual Rev 1.04
+ * All V3 register names are prefaced by V3_ to avoid clashing with any other
+ * PCI definitions.  Their names match the user's manual.
+ *
+ * I'm assuming that I20 is disabled.
+ *
+ */
+#define V3_PCI_VENDOR                   0x00000000
+#define V3_PCI_DEVICE                   0x00000002
+#define V3_PCI_CMD                      0x00000004
+#define V3_PCI_STAT                     0x00000006
+#define V3_PCI_CC_REV                   0x00000008
+#define V3_PCI_HDR_CFG                  0x0000000C
+#define V3_PCI_IO_BASE                  0x00000010
+#define V3_PCI_BASE0                    0x00000014
+#define V3_PCI_BASE1                    0x00000018
+#define V3_PCI_SUB_VENDOR               0x0000002C
+#define V3_PCI_SUB_ID                   0x0000002E
+#define V3_PCI_ROM                      0x00000030
+#define V3_PCI_BPARAM                   0x0000003C
+#define V3_PCI_MAP0                     0x00000040
+#define V3_PCI_MAP1                     0x00000044
+#define V3_PCI_INT_STAT                 0x00000048
+#define V3_PCI_INT_CFG                  0x0000004C
+#define V3_LB_BASE0                     0x00000054
+#define V3_LB_BASE1                     0x00000058
+#define V3_LB_MAP0                      0x0000005E
+#define V3_LB_MAP1                      0x00000062
+#define V3_LB_BASE2                     0x00000064
+#define V3_LB_MAP2                      0x00000066
+#define V3_LB_SIZE                      0x00000068
+#define V3_LB_IO_BASE                   0x0000006E
+#define V3_FIFO_CFG                     0x00000070
+#define V3_FIFO_PRIORITY                0x00000072
+#define V3_FIFO_STAT                    0x00000074
+#define V3_LB_ISTAT                     0x00000076
+#define V3_LB_IMASK                     0x00000077
+#define V3_SYSTEM                       0x00000078
+#define V3_LB_CFG                       0x0000007A
+#define V3_PCI_CFG                      0x0000007C
+#define V3_DMA_PCI_ADR0                 0x00000080
+#define V3_DMA_PCI_ADR1                 0x00000090
+#define V3_DMA_LOCAL_ADR0               0x00000084
+#define V3_DMA_LOCAL_ADR1               0x00000094
+#define V3_DMA_LENGTH0                  0x00000088
+#define V3_DMA_LENGTH1                  0x00000098
+#define V3_DMA_CSR0                     0x0000008B
+#define V3_DMA_CSR1                     0x0000009B
+#define V3_DMA_CTLB_ADR0                0x0000008C
+#define V3_DMA_CTLB_ADR1                0x0000009C
+#define V3_DMA_DELAY                    0x000000E0
+#define V3_MAIL_DATA                    0x000000C0
+#define V3_PCI_MAIL_IEWR                0x000000D0
+#define V3_PCI_MAIL_IERD                0x000000D2
+#define V3_LB_MAIL_IEWR                 0x000000D4
+#define V3_LB_MAIL_IERD                 0x000000D6
+#define V3_MAIL_WR_STAT                 0x000000D8
+#define V3_MAIL_RD_STAT                 0x000000DA
+#define V3_QBA_MAP                      0x000000DC
+
+/*  PCI COMMAND REGISTER bits
+ */
+#define V3_COMMAND_M_FBB_EN             (1 << 9)
+#define V3_COMMAND_M_SERR_EN            (1 << 8)
+#define V3_COMMAND_M_PAR_EN             (1 << 6)
+#define V3_COMMAND_M_MASTER_EN          (1 << 2)
+#define V3_COMMAND_M_MEM_EN             (1 << 1)
+#define V3_COMMAND_M_IO_EN              (1 << 0)
+
+/*  SYSTEM REGISTER bits
+ */
+#define V3_SYSTEM_M_RST_OUT             (1 << 15)
+#define V3_SYSTEM_M_LOCK                (1 << 14)
+
+/*  PCI_CFG bits
+ */
+#define V3_PCI_CFG_M_I2O_EN		(1 << 15)
+#define V3_PCI_CFG_M_IO_REG_DIS		(1 << 14)
+#define V3_PCI_CFG_M_IO_DIS		(1 << 13)
+#define V3_PCI_CFG_M_EN3V		(1 << 12)
+#define V3_PCI_CFG_M_RETRY_EN           (1 << 10)
+#define V3_PCI_CFG_M_AD_LOW1            (1 << 9)
+#define V3_PCI_CFG_M_AD_LOW0            (1 << 8)
+
+/*  PCI_BASE register bits (PCI -> Local Bus)
+ */
+#define V3_PCI_BASE_M_ADR_BASE          0xFFF00000
+#define V3_PCI_BASE_M_ADR_BASEL         0x000FFF00
+#define V3_PCI_BASE_M_PREFETCH          (1 << 3)
+#define V3_PCI_BASE_M_TYPE              (3 << 1)
+#define V3_PCI_BASE_M_IO                (1 << 0)
+
+/*  PCI MAP register bits (PCI -> Local bus)
+ */
+#define V3_PCI_MAP_M_MAP_ADR            0xFFF00000
+#define V3_PCI_MAP_M_RD_POST_INH        (1 << 15)
+#define V3_PCI_MAP_M_ROM_SIZE           (3 << 10)
+#define V3_PCI_MAP_M_SWAP               (3 << 8)
+#define V3_PCI_MAP_M_ADR_SIZE           0x000000F0
+#define V3_PCI_MAP_M_REG_EN             (1 << 1)
+#define V3_PCI_MAP_M_ENABLE             (1 << 0)
+
+/*
+ *  LB_BASE0,1 register bits (Local bus -> PCI)
+ */
+#define V3_LB_BASE_ADR_BASE		0xfff00000
+#define V3_LB_BASE_SWAP			(3 << 8)
+#define V3_LB_BASE_ADR_SIZE		(15 << 4)
+#define V3_LB_BASE_PREFETCH		(1 << 3)
+#define V3_LB_BASE_ENABLE		(1 << 0)
+
+#define V3_LB_BASE_ADR_SIZE_1MB		(0 << 4)
+#define V3_LB_BASE_ADR_SIZE_2MB		(1 << 4)
+#define V3_LB_BASE_ADR_SIZE_4MB		(2 << 4)
+#define V3_LB_BASE_ADR_SIZE_8MB		(3 << 4)
+#define V3_LB_BASE_ADR_SIZE_16MB	(4 << 4)
+#define V3_LB_BASE_ADR_SIZE_32MB	(5 << 4)
+#define V3_LB_BASE_ADR_SIZE_64MB	(6 << 4)
+#define V3_LB_BASE_ADR_SIZE_128MB	(7 << 4)
+#define V3_LB_BASE_ADR_SIZE_256MB	(8 << 4)
+#define V3_LB_BASE_ADR_SIZE_512MB	(9 << 4)
+#define V3_LB_BASE_ADR_SIZE_1GB		(10 << 4)
+#define V3_LB_BASE_ADR_SIZE_2GB		(11 << 4)
+
+#define v3_addr_to_lb_base(a)	((a) & V3_LB_BASE_ADR_BASE)
+
+/*
+ *  LB_MAP0,1 register bits (Local bus -> PCI)
+ */
+#define V3_LB_MAP_MAP_ADR		0xfff0
+#define V3_LB_MAP_TYPE			(7 << 1)
+#define V3_LB_MAP_AD_LOW_EN		(1 << 0)
+
+#define V3_LB_MAP_TYPE_IACK		(0 << 1)
+#define V3_LB_MAP_TYPE_IO		(1 << 1)
+#define V3_LB_MAP_TYPE_MEM		(3 << 1)
+#define V3_LB_MAP_TYPE_CONFIG		(5 << 1)
+#define V3_LB_MAP_TYPE_MEM_MULTIPLE	(6 << 1)
+
+#define v3_addr_to_lb_map(a)	(((a) >> 16) & V3_LB_MAP_MAP_ADR)
+
+/*
+ *  LB_BASE2 register bits (Local bus -> PCI IO)
+ */
+#define V3_LB_BASE2_ADR_BASE		0xff00
+#define V3_LB_BASE2_SWAP		(3 << 6)
+#define V3_LB_BASE2_ENABLE		(1 << 0)
+
+#define v3_addr_to_lb_base2(a)	(((a) >> 16) & V3_LB_BASE2_ADR_BASE)
+
+/*
+ *  LB_MAP2 register bits (Local bus -> PCI IO)
+ */
+#define V3_LB_MAP2_MAP_ADR		0xff00
+
+#define v3_addr_to_lb_map2(a)	(((a) >> 16) & V3_LB_MAP2_MAP_ADR)
 
 /*
  * The V3 PCI interface chip in Integrator provides several windows from
-- 
1.8.1.4



From linus.walleij at linaro.org  Sat Apr 20 09:56:25 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Sat, 20 Apr 2013 15:56:25 +0200
Subject: [RESEND PATCH 08/12] ARM: integrator: remap PCIv3 base dynamically
Message-ID: <1366466185-15579-1-git-send-email-linus.walleij@linaro.org>

Remove the static mapping for the PCIv3 PCI bridge controller
and do this dynamically when probing instead.

Acked-by: Arnd Bergmann <arnd at arndb.de>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 arch/arm/mach-integrator/include/mach/platform.h |  1 -
 arch/arm/mach-integrator/integrator_ap.c         |  6 ------
 arch/arm/mach-integrator/pci_v3.c                | 20 ++++++++++++++------
 3 files changed, 14 insertions(+), 13 deletions(-)

diff --git a/arch/arm/mach-integrator/include/mach/platform.h b/arch/arm/mach-integrator/include/mach/platform.h
index be5859e..62fa119 100644
--- a/arch/arm/mach-integrator/include/mach/platform.h
+++ b/arch/arm/mach-integrator/include/mach/platform.h
@@ -325,7 +325,6 @@
 
 #define PCI_MEMORY_VADDR		IOMEM(0xe8000000)
 #define PCI_CONFIG_VADDR		IOMEM(0xec000000)
-#define PCI_V3_VADDR			IOMEM(0xed000000)
 
 /* ------------------------------------------------------------------------
  *  Integrator Interrupt Controllers
diff --git a/arch/arm/mach-integrator/integrator_ap.c b/arch/arm/mach-integrator/integrator_ap.c
index f190bab..9b2d28b 100644
--- a/arch/arm/mach-integrator/integrator_ap.c
+++ b/arch/arm/mach-integrator/integrator_ap.c
@@ -80,7 +80,6 @@ void __iomem *ap_syscon_base;
  * Logical      Physical
  * e8000000	40000000	PCI memory		PHYS_PCI_MEM_BASE	(max 512M)
  * ec000000	61000000	PCI config space	PHYS_PCI_CONFIG_BASE	(max 16M)
- * ed000000	62000000	PCI V3 regs		PHYS_PCI_V3_BASE	(max 64k)
  * fee00000	60000000	PCI IO			PHYS_PCI_IO_BASE	(max 16M)
  * ef000000			Cache flush
  * f1000000	10000000	Core module registers
@@ -140,11 +139,6 @@ static struct map_desc ap_io_desc[] __initdata __maybe_unused = {
 		.pfn		= __phys_to_pfn(PHYS_PCI_CONFIG_BASE),
 		.length		= SZ_16M,
 		.type		= MT_DEVICE
-	}, {
-		.virtual	= (unsigned long)PCI_V3_VADDR,
-		.pfn		= __phys_to_pfn(PHYS_PCI_V3_BASE),
-		.length		= SZ_64K,
-		.type		= MT_DEVICE
 	}
 };
 
diff --git a/arch/arm/mach-integrator/pci_v3.c b/arch/arm/mach-integrator/pci_v3.c
index 604064b..9dd7125 100644
--- a/arch/arm/mach-integrator/pci_v3.c
+++ b/arch/arm/mach-integrator/pci_v3.c
@@ -260,15 +260,17 @@
  * the mappings into PCI memory.
  */
 
+static void __iomem *pci_v3_base;
+
 // V3 access routines
-#define v3_writeb(o,v) __raw_writeb(v, PCI_V3_VADDR + (unsigned int)(o))
-#define v3_readb(o)    (__raw_readb(PCI_V3_VADDR + (unsigned int)(o)))
+#define v3_writeb(o,v) __raw_writeb(v, pci_v3_base + (unsigned int)(o))
+#define v3_readb(o)    (__raw_readb(pci_v3_base + (unsigned int)(o)))
 
-#define v3_writew(o,v) __raw_writew(v, PCI_V3_VADDR + (unsigned int)(o))
-#define v3_readw(o)    (__raw_readw(PCI_V3_VADDR + (unsigned int)(o)))
+#define v3_writew(o,v) __raw_writew(v, pci_v3_base + (unsigned int)(o))
+#define v3_readw(o)    (__raw_readw(pci_v3_base + (unsigned int)(o)))
 
-#define v3_writel(o,v) __raw_writel(v, PCI_V3_VADDR + (unsigned int)(o))
-#define v3_readl(o)    (__raw_readl(PCI_V3_VADDR + (unsigned int)(o)))
+#define v3_writel(o,v) __raw_writel(v, pci_v3_base + (unsigned int)(o))
+#define v3_readl(o)    (__raw_readl(pci_v3_base + (unsigned int)(o)))
 
 /*============================================================================
  *
@@ -835,6 +837,12 @@ static int __init pci_v3_probe(struct platform_device *pdev)
 		return -ENODEV;
 	}
 
+	pci_v3_base = devm_ioremap(&pdev->dev, PHYS_PCI_V3_BASE, SZ_64K);
+	if (!pci_v3_base) {
+		dev_err(&pdev->dev, "unable to remap PCIv3 base\n");
+		return -ENODEV;
+	}
+
 	ret = devm_request_irq(&pdev->dev, IRQ_AP_V3INT, v3_irq, 0, "V3", NULL);
 	if (ret) {
 		dev_err(&pdev->dev, "unable to grab PCI error interrupt: %d\n",
-- 
1.8.1.4



From linus.walleij at linaro.org  Sat Apr 20 09:56:32 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Sat, 20 Apr 2013 15:56:32 +0200
Subject: [RESEND PATCH 09/12] ARM: integrator: move VGA base assignment
Message-ID: <1366466192-15608-1-git-send-email-linus.walleij@linaro.org>

The global vga_base is used for things like getting an early
console on a PCI-based VGA adapter. Move this assignment into
the probe function for the PCI bridge.

Acked-by: Arnd Bergmann <arnd at arndb.de>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 arch/arm/mach-integrator/integrator_ap.c | 2 --
 arch/arm/mach-integrator/pci_v3.c        | 2 ++
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-integrator/integrator_ap.c b/arch/arm/mach-integrator/integrator_ap.c
index 9b2d28b..fe1ee7c0 100644
--- a/arch/arm/mach-integrator/integrator_ap.c
+++ b/arch/arm/mach-integrator/integrator_ap.c
@@ -41,7 +41,6 @@
 #include <linux/stat.h>
 #include <linux/sys_soc.h>
 #include <linux/termios.h>
-#include <video/vga.h>
 
 #include <mach/hardware.h>
 #include <mach/platform.h>
@@ -145,7 +144,6 @@ static struct map_desc ap_io_desc[] __initdata __maybe_unused = {
 static void __init ap_map_io(void)
 {
 	iotable_init(ap_io_desc, ARRAY_SIZE(ap_io_desc));
-	vga_base = (unsigned long)PCI_MEMORY_VADDR;
 	pci_map_io_early(__phys_to_pfn(PHYS_PCI_IO_BASE));
 }
 
diff --git a/arch/arm/mach-integrator/pci_v3.c b/arch/arm/mach-integrator/pci_v3.c
index 9dd7125..059ac4e 100644
--- a/arch/arm/mach-integrator/pci_v3.c
+++ b/arch/arm/mach-integrator/pci_v3.c
@@ -28,6 +28,7 @@
 #include <linux/init.h>
 #include <linux/io.h>
 #include <linux/platform_device.h>
+#include <video/vga.h>
 
 #include <mach/hardware.h>
 #include <mach/platform.h>
@@ -850,6 +851,7 @@ static int __init pci_v3_probe(struct platform_device *pdev)
 		return -ENODEV;
 	}
 
+	vga_base = (unsigned long)PCI_MEMORY_VADDR;
 	pci_common_init(&pci_v3);
 
 	return 0;
-- 
1.8.1.4



From linus.walleij at linaro.org  Sat Apr 20 09:56:39 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Sat, 20 Apr 2013 15:56:39 +0200
Subject: [RESEND PATCH 10/12] ARM: integrator: move static ioremapping into
 PCIv3 driver
Message-ID: <1366466199-15651-1-git-send-email-linus.walleij@linaro.org>

Try to make this driver self-contained by moving the ioremapping
into the driver.

Acked-by: Arnd Bergmann <arnd at arndb.de>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 arch/arm/mach-integrator/include/mach/platform.h | 22 -----------
 arch/arm/mach-integrator/integrator_ap.c         | 17 +--------
 arch/arm/mach-integrator/pci_v3.c                | 48 +++++++++++++++++++++++-
 arch/arm/mach-integrator/pci_v3.h                |  2 +
 4 files changed, 51 insertions(+), 38 deletions(-)
 create mode 100644 arch/arm/mach-integrator/pci_v3.h

diff --git a/arch/arm/mach-integrator/include/mach/platform.h b/arch/arm/mach-integrator/include/mach/platform.h
index 62fa119..306d025 100644
--- a/arch/arm/mach-integrator/include/mach/platform.h
+++ b/arch/arm/mach-integrator/include/mach/platform.h
@@ -305,28 +305,6 @@
 /* KMI definitions are now in include/asm-arm/hardware/amba_kmi.h -- rmk */
 
 /* ------------------------------------------------------------------------
- *  Where in the memory map does PCI live?
- * ------------------------------------------------------------------------
- *  This represents a fairly liberal usage of address space.  Even though
- *  the V3 only has two windows (therefore we need to map stuff on the fly),
- *  we maintain the same addresses, even if they're not mapped.
- *
- */
-#define PHYS_PCI_MEM_BASE               0x40000000   /* 512M to xxx */
-/*  unused 256M from A0000000-AFFFFFFF might be used for I2O ???
- */
-#define PHYS_PCI_IO_BASE                0x60000000   /* 16M to xxx */
-/*  unused (128-16)M from B1000000-B7FFFFFF
- */
-#define PHYS_PCI_CONFIG_BASE            0x61000000   /* 16M to xxx */
-/*  unused ((128-16)M - 64K) from XXX
- */
-#define PHYS_PCI_V3_BASE                0x62000000
-
-#define PCI_MEMORY_VADDR		IOMEM(0xe8000000)
-#define PCI_CONFIG_VADDR		IOMEM(0xec000000)
-
-/* ------------------------------------------------------------------------
  *  Integrator Interrupt Controllers
  * ------------------------------------------------------------------------
  *
diff --git a/arch/arm/mach-integrator/integrator_ap.c b/arch/arm/mach-integrator/integrator_ap.c
index fe1ee7c0..f617489 100644
--- a/arch/arm/mach-integrator/integrator_ap.c
+++ b/arch/arm/mach-integrator/integrator_ap.c
@@ -56,10 +56,10 @@
 #include <asm/mach/arch.h>
 #include <asm/mach/irq.h>
 #include <asm/mach/map.h>
-#include <asm/mach/pci.h>
 #include <asm/mach/time.h>
 
 #include "common.h"
+#include "pci_v3.h"
 
 /* Base address to the AP system controller */
 void __iomem *ap_syscon_base;
@@ -77,9 +77,6 @@ void __iomem *ap_syscon_base;
 
 /*
  * Logical      Physical
- * e8000000	40000000	PCI memory		PHYS_PCI_MEM_BASE	(max 512M)
- * ec000000	61000000	PCI config space	PHYS_PCI_CONFIG_BASE	(max 16M)
- * fee00000	60000000	PCI IO			PHYS_PCI_IO_BASE	(max 16M)
  * ef000000			Cache flush
  * f1000000	10000000	Core module registers
  * f1100000	11000000	System controller registers
@@ -128,23 +125,13 @@ static struct map_desc ap_io_desc[] __initdata __maybe_unused = {
 		.pfn		= __phys_to_pfn(INTEGRATOR_AP_GPIO_BASE),
 		.length		= SZ_4K,
 		.type		= MT_DEVICE
-	}, {
-		.virtual	= (unsigned long)PCI_MEMORY_VADDR,
-		.pfn		= __phys_to_pfn(PHYS_PCI_MEM_BASE),
-		.length		= SZ_16M,
-		.type		= MT_DEVICE
-	}, {
-		.virtual	= (unsigned long)PCI_CONFIG_VADDR,
-		.pfn		= __phys_to_pfn(PHYS_PCI_CONFIG_BASE),
-		.length		= SZ_16M,
-		.type		= MT_DEVICE
 	}
 };
 
 static void __init ap_map_io(void)
 {
 	iotable_init(ap_io_desc, ARRAY_SIZE(ap_io_desc));
-	pci_map_io_early(__phys_to_pfn(PHYS_PCI_IO_BASE));
+	pci_v3_early_init();
 }
 
 #ifdef CONFIG_PM
diff --git a/arch/arm/mach-integrator/pci_v3.c b/arch/arm/mach-integrator/pci_v3.c
index 059ac4e..a3cefde 100644
--- a/arch/arm/mach-integrator/pci_v3.c
+++ b/arch/arm/mach-integrator/pci_v3.c
@@ -34,10 +34,28 @@
 #include <mach/platform.h>
 #include <mach/irqs.h>
 
+#include <asm/mach/map.h>
 #include <asm/signal.h>
 #include <asm/mach/pci.h>
 #include <asm/irq_regs.h>
 
+#include "pci_v3.h"
+
+/*
+ * Where in the memory map does PCI live?
+ *
+ * This represents a fairly liberal usage of address space.  Even though
+ * the V3 only has two windows (therefore we need to map stuff on the fly),
+ * we maintain the same addresses, even if they're not mapped.
+ */
+#define PHYS_PCI_MEM_BASE               0x40000000 /* 512M */
+#define PHYS_PCI_IO_BASE                0x60000000 /* 16M */
+#define PHYS_PCI_CONFIG_BASE            0x61000000 /* 16M */
+#define PHYS_PCI_V3_BASE                0x62000000 /* 64K */
+
+#define PCI_MEMORY_VADDR               IOMEM(0xe8000000)
+#define PCI_CONFIG_VADDR               IOMEM(0xec000000)
+
 /*
  * V3 Local Bus to PCI Bridge definitions
  *
@@ -851,7 +869,6 @@ static int __init pci_v3_probe(struct platform_device *pdev)
 		return -ENODEV;
 	}
 
-	vga_base = (unsigned long)PCI_MEMORY_VADDR;
 	pci_common_init(&pci_v3);
 
 	return 0;
@@ -869,3 +886,32 @@ static int __init pci_v3_init(void)
 }
 
 subsys_initcall(pci_v3_init);
+
+/*
+ * Static mappings for the PCIv3 bridge
+ *
+ * e8000000	40000000	PCI memory		PHYS_PCI_MEM_BASE	(max 512M)
+ * ec000000	61000000	PCI config space	PHYS_PCI_CONFIG_BASE	(max 16M)
+ * fee00000	60000000	PCI IO			PHYS_PCI_IO_BASE	(max 16M)
+ */
+static struct map_desc pci_v3_io_desc[] __initdata __maybe_unused = {
+	{
+		.virtual	= (unsigned long)PCI_MEMORY_VADDR,
+		.pfn		= __phys_to_pfn(PHYS_PCI_MEM_BASE),
+		.length		= SZ_16M,
+		.type		= MT_DEVICE
+	}, {
+		.virtual	= (unsigned long)PCI_CONFIG_VADDR,
+		.pfn		= __phys_to_pfn(PHYS_PCI_CONFIG_BASE),
+		.length		= SZ_16M,
+		.type		= MT_DEVICE
+	}
+};
+
+int __init pci_v3_early_init(void)
+{
+	iotable_init(pci_v3_io_desc, ARRAY_SIZE(pci_v3_io_desc));
+	vga_base = (unsigned long)PCI_MEMORY_VADDR;
+	pci_map_io_early(__phys_to_pfn(PHYS_PCI_IO_BASE));
+	return 0;
+}
diff --git a/arch/arm/mach-integrator/pci_v3.h b/arch/arm/mach-integrator/pci_v3.h
new file mode 100644
index 0000000..755fd29
--- /dev/null
+++ b/arch/arm/mach-integrator/pci_v3.h
@@ -0,0 +1,2 @@
+/* Simple oneliner include to the PCIv3 early init */
+extern int pci_v3_early_init(void);
-- 
1.8.1.4



From linus.walleij at linaro.org  Sat Apr 20 09:56:47 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Sat, 20 Apr 2013 15:56:47 +0200
Subject: [RESEND PATCH 11/12] ARM: integrator: basic PCIv3 device tree support
Message-ID: <1366466207-15680-1-git-send-email-linus.walleij@linaro.org>

This registers the memory ranges for I/O, non-prefetched and
prefetched memory and configuration space for the PCIv3 bridge
and let us fetch these basic memory resources from the device
tree in the device tree boot path. Remove the stepping stone
platform device. This is an either/or approach - the platform
data path is mutually exclusive to the plain platform data
path and provided addresses from the device tree have to be
correct.

This patch does not add the IRQ mapping - that is to follow
in later patches.

Acked-by: Arnd Bergmann <arnd at arndb.de>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 .../devicetree/bindings/pci/v3-v360epc-pci.txt     |  15 +++
 .../devicetree/bindings/vendor-prefixes.txt        |   1 +
 arch/arm/boot/dts/integratorap.dts                 |  17 +++
 arch/arm/mach-integrator/integrator_ap.c           |  11 --
 arch/arm/mach-integrator/pci_v3.c                  | 143 +++++++++++++++++----
 5 files changed, 152 insertions(+), 35 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/pci/v3-v360epc-pci.txt

diff --git a/Documentation/devicetree/bindings/pci/v3-v360epc-pci.txt b/Documentation/devicetree/bindings/pci/v3-v360epc-pci.txt
new file mode 100644
index 0000000..30b364e
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/v3-v360epc-pci.txt
@@ -0,0 +1,15 @@
+V3 Semiconductor V360 EPC PCI bridge
+
+This bridge is found in the ARM Integrator/AP (Application Platform)
+
+Integrator-specific notes:
+
+- syscon: should contain a link to the syscon device node (since
+  on the Integrator, some registers in the syscon are required to
+  operate the V3).
+
+V360 EPC specific notes:
+
+- reg: should contain the base address of the V3 adapter.
+- interrupts: should contain a reference to the V3 error interrupt
+  as routed on the system.
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 19e1ef7..c51a6d2 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -56,6 +56,7 @@ ste	ST-Ericsson
 stericsson	ST-Ericsson
 ti	Texas Instruments
 toshiba	Toshiba Corporation
+v3	V3 Semiconductor
 via	VIA Technologies, Inc.
 wlf	Wolfson Microelectronics
 wm	Wondermedia Technologies, Inc.
diff --git a/arch/arm/boot/dts/integratorap.dts b/arch/arm/boot/dts/integratorap.dts
index c9c3fa3..9c78130 100644
--- a/arch/arm/boot/dts/integratorap.dts
+++ b/arch/arm/boot/dts/integratorap.dts
@@ -39,6 +39,23 @@
 		valid-mask = <0x003fffff>;
 	};
 
+	pci: pciv3 at 62000000 {
+		compatible = "v3,v360epc-pci";
+		#size-cells = <2>;
+		#address-cells = <3>;
+		reg = <0x62000000 0x10000>;
+		interrupt-parent = <&pic>;
+		interrupts = <17>; /* Bus error IRQ */
+		ranges = <0x00000000 0 0x61000000 /* config space */
+			0x61000000 0 0x00100000 /* 16 MiB @ 61000000 */
+			0x01000000 0 0x60000000 /* I/O space */
+			0x60000000 0 0x00100000 /* 16 MiB @ 60000000 */
+			0x02000000 0 0x40000000 /* non-prefectable memory */
+			0x40000000 0 0x10000000 /* 256 MiB @ 40000000 */
+			0x42000000 0 0x50000000 /* prefetchable memory */
+			0x50000000 0 0x10000000>; /* 256 MiB @ 50000000 */
+	};
+
 	fpga {
 		/*
 		 * The Integator/AP predates the idea to have magic numbers
diff --git a/arch/arm/mach-integrator/integrator_ap.c b/arch/arm/mach-integrator/integrator_ap.c
index f617489..793c262 100644
--- a/arch/arm/mach-integrator/integrator_ap.c
+++ b/arch/arm/mach-integrator/integrator_ap.c
@@ -473,15 +473,6 @@ static struct of_dev_auxdata ap_auxdata_lookup[] __initdata = {
 	{ /* sentinel */ },
 };
 
-/*
- * This is a placeholder that will get deleted when we move the PCI
- * device over to the device tree.
- */
-static struct platform_device pci_v3_device_of = {
-	.name		= "pci-v3",
-	.id		= 0,
-};
-
 static void __init ap_init_of(void)
 {
 	unsigned long sc_dec;
@@ -538,8 +529,6 @@ static void __init ap_init_of(void)
 	of_platform_populate(root, of_default_bus_match_table,
 			ap_auxdata_lookup, parent);
 
-	platform_device_register(&pci_v3_device_of);
-
 	sc_dec = readl(ap_syscon_base + INTEGRATOR_SC_DEC_OFFSET);
 	for (i = 0; i < 4; i++) {
 		struct lm_device *lmdev;
diff --git a/arch/arm/mach-integrator/pci_v3.c b/arch/arm/mach-integrator/pci_v3.c
index a3cefde..8932eb3 100644
--- a/arch/arm/mach-integrator/pci_v3.c
+++ b/arch/arm/mach-integrator/pci_v3.c
@@ -28,6 +28,9 @@
 #include <linux/init.h>
 #include <linux/io.h>
 #include <linux/platform_device.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_pci.h>
 #include <video/vga.h>
 
 #include <mach/hardware.h>
@@ -279,7 +282,12 @@
  * the mappings into PCI memory.
  */
 
+/* Filled in by probe */
 static void __iomem *pci_v3_base;
+static struct resource conf_mem; /* FIXME: remap this instead of static map */
+static struct resource io_mem;
+static struct resource non_mem;
+static struct resource pre_mem;
 
 // V3 access routines
 #define v3_writeb(o,v) __raw_writeb(v, pci_v3_base + (unsigned int)(o))
@@ -423,13 +431,13 @@ static void __iomem *v3_open_config_window(struct pci_bus *bus,
 	 * prefetchable), this frees up base1 for re-use by
 	 * configuration memory
 	 */
-	v3_writel(V3_LB_BASE0, v3_addr_to_lb_base(PHYS_PCI_MEM_BASE) |
+	v3_writel(V3_LB_BASE0, v3_addr_to_lb_base(non_mem.start) |
 			V3_LB_BASE_ADR_SIZE_512MB | V3_LB_BASE_ENABLE);
 
 	/*
 	 * Set up base1/map1 to point into configuration space.
 	 */
-	v3_writel(V3_LB_BASE1, v3_addr_to_lb_base(PHYS_PCI_CONFIG_BASE) |
+	v3_writel(V3_LB_BASE1, v3_addr_to_lb_base(conf_mem.start) |
 			V3_LB_BASE_ADR_SIZE_16MB | V3_LB_BASE_ENABLE);
 	v3_writew(V3_LB_MAP1, mapaddress);
 
@@ -441,7 +449,7 @@ static void v3_close_config_window(void)
 	/*
 	 * Reassign base1 for use by prefetchable PCI memory
 	 */
-	v3_writel(V3_LB_BASE1, v3_addr_to_lb_base(PHYS_PCI_MEM_BASE + SZ_256M) |
+	v3_writel(V3_LB_BASE1, v3_addr_to_lb_base(pre_mem.start) |
 			V3_LB_BASE_ADR_SIZE_256MB | V3_LB_BASE_PREFETCH |
 			V3_LB_BASE_ENABLE);
 	v3_writew(V3_LB_MAP1, v3_addr_to_lb_map(PCI_BUS_PREMEM_START) |
@@ -450,7 +458,7 @@ static void v3_close_config_window(void)
 	/*
 	 * And shrink base0 back to a 256M window (NOTE: MAP0 already correct)
 	 */
-	v3_writel(V3_LB_BASE0, v3_addr_to_lb_base(PHYS_PCI_MEM_BASE) |
+	v3_writel(V3_LB_BASE0, v3_addr_to_lb_base(non_mem.start) |
 			V3_LB_BASE_ADR_SIZE_256MB | V3_LB_BASE_ENABLE);
 }
 
@@ -522,20 +530,6 @@ static struct pci_ops pci_v3_ops = {
 	.write	= v3_write_config,
 };
 
-static struct resource non_mem = {
-	.name	= "PCI non-prefetchable",
-	.start	= PHYS_PCI_MEM_BASE + PCI_BUS_NONMEM_START,
-	.end	= PHYS_PCI_MEM_BASE + PCI_BUS_NONMEM_START + PCI_BUS_NONMEM_SIZE - 1,
-	.flags	= IORESOURCE_MEM,
-};
-
-static struct resource pre_mem = {
-	.name	= "PCI prefetchable",
-	.start	= PHYS_PCI_MEM_BASE + PCI_BUS_PREMEM_START,
-	.end	= PHYS_PCI_MEM_BASE + PCI_BUS_PREMEM_START + PCI_BUS_PREMEM_SIZE - 1,
-	.flags	= IORESOURCE_MEM | IORESOURCE_PREFETCH,
-};
-
 static int __init pci_v3_setup_resources(struct pci_sys_data *sys)
 {
 	if (request_resource(&iomem_resource, &non_mem)) {
@@ -659,7 +653,7 @@ static int __init pci_v3_setup(int nr, struct pci_sys_data *sys)
 		return -EINVAL;
 
 	if (nr == 0) {
-		sys->mem_offset = PHYS_PCI_MEM_BASE;
+		sys->mem_offset = non_mem.start;
 		ret = pci_v3_setup_resources(sys);
 	}
 
@@ -697,7 +691,7 @@ static void __init pci_v3_preinit(void)
 	 * Setup window 0 - PCI non-prefetchable memory
 	 *  Local: 0x40000000 Bus: 0x00000000 Size: 256MB
 	 */
-	v3_writel(V3_LB_BASE0, v3_addr_to_lb_base(PHYS_PCI_MEM_BASE) |
+	v3_writel(V3_LB_BASE0, v3_addr_to_lb_base(non_mem.start) |
 			V3_LB_BASE_ADR_SIZE_256MB | V3_LB_BASE_ENABLE);
 	v3_writew(V3_LB_MAP0, v3_addr_to_lb_map(PCI_BUS_NONMEM_START) |
 			V3_LB_MAP_TYPE_MEM);
@@ -706,7 +700,7 @@ static void __init pci_v3_preinit(void)
 	 * Setup window 1 - PCI prefetchable memory
 	 *  Local: 0x50000000 Bus: 0x10000000 Size: 256MB
 	 */
-	v3_writel(V3_LB_BASE1, v3_addr_to_lb_base(PHYS_PCI_MEM_BASE + SZ_256M) |
+	v3_writel(V3_LB_BASE1, v3_addr_to_lb_base(pre_mem.start) |
 			V3_LB_BASE_ADR_SIZE_256MB | V3_LB_BASE_PREFETCH |
 			V3_LB_BASE_ENABLE);
 	v3_writew(V3_LB_MAP1, v3_addr_to_lb_map(PCI_BUS_PREMEM_START) |
@@ -715,7 +709,7 @@ static void __init pci_v3_preinit(void)
 	/*
 	 * Setup window 2 - PCI IO
 	 */
-	v3_writel(V3_LB_BASE2, v3_addr_to_lb_base2(PHYS_PCI_IO_BASE) |
+	v3_writel(V3_LB_BASE2, v3_addr_to_lb_base2(io_mem.start) |
 			V3_LB_BASE_ENABLE);
 	v3_writew(V3_LB_MAP2, v3_addr_to_lb_map2(0));
 
@@ -772,7 +766,7 @@ static void __init pci_v3_postinit(void)
 		       "interrupt: %d\n", ret);
 #endif
 
-	register_isa_ports(PHYS_PCI_MEM_BASE, PHYS_PCI_IO_BASE, 0);
+	register_isa_ports(non_mem.start, io_mem.start, 0);
 }
 
 /*
@@ -845,8 +839,77 @@ static struct hw_pci pci_v3 __initdata = {
 	.postinit		= pci_v3_postinit,
 };
 
+static int __init pci_v3_dtprobe(struct platform_device *pdev,
+				struct device_node *np)
+{
+	struct of_pci_range_parser parser;
+	struct of_pci_range range;
+	struct resource *res;
+	int irq, ret;
+
+	if (of_pci_range_parser(&parser, np))
+		return -EINVAL;
+
+	/* Get base for bridge registers */
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	if (!res) {
+		dev_err(&pdev->dev, "unable to obtain PCIv3 base\n");
+		return -ENODEV;
+	}
+	pci_v3_base = devm_ioremap(&pdev->dev, res->start,
+				   resource_size(res));
+	if (!pci_v3_base) {
+		dev_err(&pdev->dev, "unable to remap PCIv3 base\n");
+		return -ENODEV;
+	}
+
+	/* Get and request error IRQ resource */
+	irq = platform_get_irq(pdev, 0);
+	if (irq <= 0) {
+		dev_err(&pdev->dev, "unable to obtain PCIv3 error IRQ\n");
+		return -ENODEV;
+	}
+	ret = devm_request_irq(&pdev->dev, irq, v3_irq, 0,
+			"PCIv3 error", NULL);
+	if (ret < 0) {
+		dev_err(&pdev->dev, "unable to request PCIv3 error IRQ %d (%d)\n", irq, ret);
+		return ret;
+	}
+
+	for_each_of_pci_range(&parser, &range) {
+		if (!range.flags) {
+			of_pci_range_to_resource(&range, np, &conf_mem);
+			conf_mem.name = "PCIv3 config";
+		}
+		if (range.flags & IORESOURCE_IO) {
+			of_pci_range_to_resource(&range, np, &io_mem);
+			io_mem.name = "PCIv3 I/O";
+		}
+		if ((range.flags & IORESOURCE_MEM) &&
+			!(range.flags & IORESOURCE_PREFETCH)) {
+			of_pci_range_to_resource(&range, np, &non_mem);
+			non_mem.name = "PCIv3 non-prefetched mem";
+		}
+		if ((range.flags & IORESOURCE_MEM) &&
+			(range.flags & IORESOURCE_PREFETCH)) {
+			of_pci_range_to_resource(&range, np, &pre_mem);
+			pre_mem.name = "PCIv3 prefetched mem";
+		}
+	}
+
+	if (!conf_mem.start || !io_mem.start ||
+	    !non_mem.start || !pre_mem.start) {
+		dev_err(&pdev->dev, "missing ranges in device node\n");
+		return -EINVAL;
+	}
+
+	pci_common_init(&pdev->dev, &pci_v3);
+	return 0;
+}
+
 static int __init pci_v3_probe(struct platform_device *pdev)
 {
+	struct device_node *np = pdev->dev.of_node;
 	int ret;
 
 	/* Remap the Integrator system controller */
@@ -856,6 +919,10 @@ static int __init pci_v3_probe(struct platform_device *pdev)
 		return -ENODEV;
 	}
 
+	/* Device tree probe path */
+	if (np)
+		return pci_v3_dtprobe(pdev, np);
+
 	pci_v3_base = devm_ioremap(&pdev->dev, PHYS_PCI_V3_BASE, SZ_64K);
 	if (!pci_v3_base) {
 		dev_err(&pdev->dev, "unable to remap PCIv3 base\n");
@@ -869,14 +936,42 @@ static int __init pci_v3_probe(struct platform_device *pdev)
 		return -ENODEV;
 	}
 
-	pci_common_init(&pci_v3);
+	conf_mem.name = "PCIv3 config";
+	conf_mem.start = PHYS_PCI_CONFIG_BASE;
+	conf_mem.end = PHYS_PCI_CONFIG_BASE + SZ_16M - 1;
+	conf_mem.flags = IORESOURCE_MEM;
+
+	io_mem.name = "PCIv3 I/O";
+	io_mem.start = PHYS_PCI_IO_BASE;
+	io_mem.end = PHYS_PCI_IO_BASE + SZ_16M - 1;
+	io_mem.flags = IORESOURCE_MEM;
+
+	non_mem.name = "PCIv3 non-prefetched mem";
+	non_mem.start = PHYS_PCI_MEM_BASE + PCI_BUS_NONMEM_START;
+	non_mem.end = PHYS_PCI_MEM_BASE + PCI_BUS_NONMEM_START +
+		PCI_BUS_NONMEM_SIZE - 1;
+	non_mem.flags = IORESOURCE_MEM;
+
+	pre_mem.name = "PCIv3 prefetched mem";
+	pre_mem.start = PHYS_PCI_MEM_BASE + PCI_BUS_PREMEM_START;
+	pre_mem.end = PHYS_PCI_MEM_BASE + PCI_BUS_PREMEM_START +
+		PCI_BUS_PREMEM_SIZE - 1;
+	pre_mem.flags = IORESOURCE_MEM | IORESOURCE_PREFETCH;
+
+	pci_common_init_dev(&pdev->dev, &pci_v3);
 
 	return 0;
 }
 
+static const struct of_device_id pci_ids[] = {
+	{ .compatible = "v3,v360epc-pci", },
+	{},
+};
+
 static struct platform_driver pci_v3_driver = {
 	.driver = {
 		.name = "pci-v3",
+		.of_match_table = pci_ids,
 	},
 };
 
-- 
1.8.1.4



From linus.walleij at linaro.org  Sat Apr 20 09:56:54 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Sat, 20 Apr 2013 15:56:54 +0200
Subject: [RESEND PATCH 12/12] ARM: integrator: get PCI device IRQs from device
 tree
Message-ID: <1366466214-15714-1-git-send-email-linus.walleij@linaro.org>

This adds the interrupt-map property to the PCIv3 DTS file
and makes the bridge obtain mappings from the device tree.

Acked-by: Arnd Bergmann <arnd at arndb.de>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 arch/arm/boot/dts/integratorap.dts | 24 ++++++++++++++++++++++++
 arch/arm/mach-integrator/pci_v3.c  | 23 ++++++++++++++++++++++-
 2 files changed, 46 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/integratorap.dts b/arch/arm/boot/dts/integratorap.dts
index 9c78130..03f23b7 100644
--- a/arch/arm/boot/dts/integratorap.dts
+++ b/arch/arm/boot/dts/integratorap.dts
@@ -41,6 +41,7 @@
 
 	pci: pciv3 at 62000000 {
 		compatible = "v3,v360epc-pci";
+		#interrupt-cells = <1>;
 		#size-cells = <2>;
 		#address-cells = <3>;
 		reg = <0x62000000 0x10000>;
@@ -54,6 +55,29 @@
 			0x40000000 0 0x10000000 /* 256 MiB @ 40000000 */
 			0x42000000 0 0x50000000 /* prefetchable memory */
 			0x50000000 0 0x10000000>; /* 256 MiB @ 50000000 */
+		interrupt-map-mask = <0xf800 0 0 0x7>;
+		interrupt-map = <
+		/* IDSEL 9 */
+		0x4800 0 0 1 &pic 13 /* INT A on slot 9 is irq 13 */
+		0x4800 0 0 2 &pic 14 /* INT B on slot 9 is irq 14 */
+		0x4800 0 0 3 &pic 15 /* INT C on slot 9 is irq 15 */
+		0x4800 0 0 4 &pic 16 /* INT D on slot 9 is irq 16 */
+		/* IDSEL 10 */
+		0x5000 0 0 1 &pic 14 /* INT A on slot 10 is irq 14 */
+		0x5000 0 0 2 &pic 15 /* INT B on slot 10 is irq 15 */
+		0x5000 0 0 3 &pic 16 /* INT C on slot 10 is irq 16 */
+		0x5000 0 0 4 &pic 13 /* INT D on slot 10 is irq 13 */
+		/* IDSEL 11 */
+		0x5800 0 0 1 &pic 15 /* INT A on slot 11 is irq 15 */
+		0x5800 0 0 2 &pic 16 /* INT B on slot 11 is irq 16 */
+		0x5800 0 0 3 &pic 13 /* INT C on slot 11 is irq 13 */
+		0x5800 0 0 4 &pic 14 /* INT D on slot 11 is irq 14 */
+		/* IDSEL 12 */
+		0x6000 0 0 1 &pic 16 /* INT A on slot 12 is irq 16 */
+		0x6000 0 0 2 &pic 13 /* INT B on slot 12 is irq 13 */
+		0x6000 0 0 3 &pic 14 /* INT C on slot 12 is irq 14 */
+		0x6000 0 0 4 &pic 15 /* INT D on slot 12 is irq 15 */
+		>;
 	};
 
 	fpga {
diff --git a/arch/arm/mach-integrator/pci_v3.c b/arch/arm/mach-integrator/pci_v3.c
index 8932eb3..020048a 100644
--- a/arch/arm/mach-integrator/pci_v3.c
+++ b/arch/arm/mach-integrator/pci_v3.c
@@ -30,6 +30,7 @@
 #include <linux/platform_device.h>
 #include <linux/of.h>
 #include <linux/of_address.h>
+#include <linux/of_irq.h>
 #include <linux/of_pci.h>
 #include <video/vga.h>
 
@@ -829,9 +830,24 @@ static int __init pci_v3_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
 	return irq_tab[intnr];
 }
 
+static int __init pci_v3_map_irq_dt(const struct pci_dev *dev, u8 slot, u8 pin)
+{
+	struct of_irq oirq;
+	int ret;
+
+	ret = of_irq_map_pci(dev, &oirq);
+	if (ret) {
+		dev_err(&dev->dev, "of_irq_map_pci() %d\n", ret);
+		/* Proper return code 0 == NO_IRQ */
+		return 0;
+	}
+
+	return irq_create_of_mapping(oirq.controller, oirq.specifier,
+				     oirq.size);
+}
+
 static struct hw_pci pci_v3 __initdata = {
 	.swizzle		= pci_v3_swizzle,
-	.map_irq		= pci_v3_map_irq,
 	.setup			= pci_v3_setup,
 	.nr_controllers		= 1,
 	.ops			= &pci_v3_ops,
@@ -903,7 +919,10 @@ static int __init pci_v3_dtprobe(struct platform_device *pdev,
 		return -EINVAL;
 	}
 
+	pci_v3.map_irq = pci_v3_map_irq_dt;
+
 	pci_common_init(&pdev->dev, &pci_v3);
+
 	return 0;
 }
 
@@ -958,6 +977,8 @@ static int __init pci_v3_probe(struct platform_device *pdev)
 		PCI_BUS_PREMEM_SIZE - 1;
 	pre_mem.flags = IORESOURCE_MEM | IORESOURCE_PREFETCH;
 
+	pci_v3.map_irq = pci_v3_map_irq;
+
 	pci_common_init_dev(&pdev->dev, &pci_v3);
 
 	return 0;
-- 
1.8.1.4



From linus.walleij at linaro.org  Sat Apr 20 10:09:17 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Sat, 20 Apr 2013 16:09:17 +0200
Subject: [PATCH 1/4] clocksource: nomadik-mtu: fix up clocksource/timer
Message-ID: <1366466957-16053-1-git-send-email-linus.walleij@linaro.org>

The Nomadik clocksource driver has had a bad define making it
impossible to use it for sched_clock() for a while. Fix this
and also enable it for the Nomadik.

Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 arch/arm/mach-nomadik/Kconfig     | 1 +
 drivers/clocksource/nomadik-mtu.c | 4 ++--
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-nomadik/Kconfig b/arch/arm/mach-nomadik/Kconfig
index 954f0e3..8c1ccd4 100644
--- a/arch/arm/mach-nomadik/Kconfig
+++ b/arch/arm/mach-nomadik/Kconfig
@@ -5,6 +5,7 @@ config ARCH_NOMADIK
 	select ARM_AMBA
 	select ARM_VIC
 	select CLKSRC_NOMADIK_MTU
+	select CLKSRC_NOMADIK_MTU_SCHED_CLOCK
 	select COMMON_CLK
 	select CPU_ARM926T
 	select GENERIC_CLOCKEVENTS
diff --git a/drivers/clocksource/nomadik-mtu.c b/drivers/clocksource/nomadik-mtu.c
index 071f6ea..e405531 100644
--- a/drivers/clocksource/nomadik-mtu.c
+++ b/drivers/clocksource/nomadik-mtu.c
@@ -67,7 +67,7 @@ static u32 clk_prescale;
 static u32 nmdk_cycle;		/* write-once */
 static struct delay_timer mtu_delay_timer;
 
-#ifdef CONFIG_NOMADIK_MTU_SCHED_CLOCK
+#ifdef CONFIG_CLKSRC_NOMADIK_MTU_SCHED_CLOCK
 /*
  * Override the global weak sched_clock symbol with this
  * local implementation which uses the clocksource to get some
@@ -233,7 +233,7 @@ void __init nmdk_timer_init(void __iomem *base, int irq)
 		pr_err("timer: failed to initialize clock source %s\n",
 		       "mtu_0");
 
-#ifdef CONFIG_NOMADIK_MTU_SCHED_CLOCK
+#ifdef CONFIG_CLKSRC_NOMADIK_MTU_SCHED_CLOCK
 	setup_sched_clock(nomadik_read_sched_clock, 32, rate);
 #endif
 
-- 
1.8.1.4



From linus.walleij at linaro.org  Sat Apr 20 10:09:26 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Sat, 20 Apr 2013 16:09:26 +0200
Subject: [PATCH 2/4] clocksource: nomadik-mtu: support of probe
Message-ID: <1366466966-16082-1-git-send-email-linus.walleij@linaro.org>

From: Rabin Vincent <rabin.vincent at stericsson.com>

Support device tree probe of the nomadik-mtu clocksource.

Signed-off-by: Rabin Vincent <rabin.vincent at stericsson.com>
---
 drivers/clocksource/nomadik-mtu.c | 70 ++++++++++++++++++++++++++++++++-------
 1 file changed, 58 insertions(+), 12 deletions(-)

diff --git a/drivers/clocksource/nomadik-mtu.c b/drivers/clocksource/nomadik-mtu.c
index e405531..7982cb0 100644
--- a/drivers/clocksource/nomadik-mtu.c
+++ b/drivers/clocksource/nomadik-mtu.c
@@ -13,6 +13,9 @@
 #include <linux/io.h>
 #include <linux/clockchips.h>
 #include <linux/clocksource.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+#include <linux/of_platform.h>
 #include <linux/clk.h>
 #include <linux/jiffies.h>
 #include <linux/delay.h>
@@ -188,22 +191,15 @@ static struct irqaction nmdk_timer_irq = {
 	.dev_id		= &nmdk_clkevt,
 };
 
-void __init nmdk_timer_init(void __iomem *base, int irq)
+static void __init __nmdk_timer_init(void __iomem *base, int irq,
+				     struct clk *pclk, struct clk *clk)
 {
 	unsigned long rate;
-	struct clk *clk0, *pclk0;
 
 	mtu_base = base;
 
-	pclk0 = clk_get_sys("mtu0", "apb_pclk");
-	BUG_ON(IS_ERR(pclk0));
-	BUG_ON(clk_prepare(pclk0) < 0);
-	BUG_ON(clk_enable(pclk0) < 0);
-
-	clk0 = clk_get_sys("mtu0", NULL);
-	BUG_ON(IS_ERR(clk0));
-	BUG_ON(clk_prepare(clk0) < 0);
-	BUG_ON(clk_enable(clk0) < 0);
+	BUG_ON(clk_prepare_enable(pclk));
+	BUG_ON(clk_prepare_enable(clk));
 
 	/*
 	 * Tick rate is 2.4MHz for Nomadik and 2.4Mhz, 100MHz or 133 MHz
@@ -213,7 +209,7 @@ void __init nmdk_timer_init(void __iomem *base, int irq)
 	 * to wake-up at a max 127s a head in time. Dividing a 2.4 MHz timer
 	 * with 16 gives too low timer resolution.
 	 */
-	rate = clk_get_rate(clk0);
+	rate = clk_get_rate(clk);
 	if (rate > 32000000) {
 		rate /= 16;
 		clk_prescale = MTU_CRn_PRESCALE_16;
@@ -247,3 +243,53 @@ void __init nmdk_timer_init(void __iomem *base, int irq)
 	mtu_delay_timer.freq = rate;
 	register_current_timer_delay(&mtu_delay_timer);
 }
+
+void __init nmdk_timer_init(void __iomem *base, int irq)
+{
+	struct clk *clk0, *pclk0;
+
+	pclk0 = clk_get_sys("mtu0", "apb_pclk");
+	BUG_ON(IS_ERR(pclk0));
+	clk0 = clk_get_sys("mtu0", NULL);
+	BUG_ON(IS_ERR(clk0));
+
+	__nmdk_timer_init(base, irq, pclk0, clk0);
+}
+
+static struct of_device_id nmdk_timer_match[] __initconst = {
+	{ .compatible = "st,nomadik-mtu" },
+	{}
+};
+
+static void __init nmdk_timer_of_init(void)
+{
+	struct device_node *node;
+	struct clk *pclk;
+	struct clk *clk;
+	void __iomem *base;
+	int irq;
+
+	node = of_find_matching_node(NULL, nmdk_timer_match);
+	if (!node)
+		panic("No timer node");
+
+	base = of_iomap(node, 0);
+	if (!base)
+		panic("Can't remap registers");
+
+	pclk = of_clk_get_by_name(node, "apb_pclk");
+	if (IS_ERR(pclk))
+		panic("could not get apb_pclk");
+
+	clk = of_clk_get_by_name(node, "timclk");
+	if (IS_ERR(clk))
+		panic("could not get timclk");
+
+	irq = irq_of_parse_and_map(node, 0);
+	if (irq <= 0)
+		panic("Can't parse IRQ");
+
+	__nmdk_timer_init(base, irq, pclk, clk);
+}
+CLOCKSOURCE_OF_DECLARE(nomadik_mtu, "st,nomadik-mtu",
+		       nmdk_timer_of_init);
-- 
1.8.1.4



From linus.walleij at linaro.org  Sat Apr 20 10:09:34 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Sat, 20 Apr 2013 16:09:34 +0200
Subject: [PATCH 3/4] ARM: nomadik: convert all clocks except timer to dt
Message-ID: <1366466974-16115-1-git-send-email-linus.walleij@linaro.org>

This moves all Nomadik clocks except the one used for the
timer/clocksource over to the device tree.

Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 .../devicetree/bindings/arm/ste-nomadik.txt        |  5 ++
 arch/arm/boot/dts/ste-nomadik-stn8815.dtsi         | 54 ++++++++++++++++++++++
 arch/arm/mach-nomadik/cpu-8815.c                   | 20 +-------
 drivers/clk/clk-nomadik.c                          | 26 +++--------
 4 files changed, 68 insertions(+), 37 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/ste-nomadik.txt b/Documentation/devicetree/bindings/arm/ste-nomadik.txt
index 19bca04..6256ec3 100644
--- a/Documentation/devicetree/bindings/arm/ste-nomadik.txt
+++ b/Documentation/devicetree/bindings/arm/ste-nomadik.txt
@@ -3,6 +3,11 @@ ST-Ericsson Nomadik Device Tree Bindings
 For various board the "board" node may contain specific properties
 that pertain to this particular board, such as board-specific GPIOs.
 
+Required root node property: src
+- Nomadik System and reset controller used for basic chip control, clock
+  and reset line control.
+- compatible: must be "stericsson,nomadik,src"
+
 Boards with the Nomadik SoC include:
 
 S8815 "MiniKit" manufactured by Calao Systems:
diff --git a/arch/arm/boot/dts/ste-nomadik-stn8815.dtsi b/arch/arm/boot/dts/ste-nomadik-stn8815.dtsi
index 4a4aab3..f0df948 100644
--- a/arch/arm/boot/dts/ste-nomadik-stn8815.dtsi
+++ b/arch/arm/boot/dts/ste-nomadik-stn8815.dtsi
@@ -45,6 +45,7 @@
 		gpio-controller;
 		#gpio-cells = <2>;
 		gpio-bank = <0>;
+		clocks = <&pclk>;
 	};
 
 	gpio1: gpio at 101e5000 {
@@ -57,6 +58,7 @@
 		gpio-controller;
 		#gpio-cells = <2>;
 		gpio-bank = <1>;
+		clocks = <&pclk>;
 	};
 
 	gpio2: gpio at 101e6000 {
@@ -69,6 +71,7 @@
 		gpio-controller;
 		#gpio-cells = <2>;
 		gpio-bank = <2>;
+		clocks = <&pclk>;
 	};
 
 	gpio3: gpio at 101e7000 {
@@ -81,12 +84,50 @@
 		gpio-controller;
 		#gpio-cells = <2>;
 		gpio-bank = <3>;
+		clocks = <&pclk>;
 	};
 
 	pinctrl {
 		compatible = "stericsson,nmk-pinctrl-stn8815";
 	};
 
+	src: src at 101e0000 {
+		compatible = "stericsson,nomadik-src";
+		reg = <0x101e0000 0x1000>;
+		clocks {
+			/*
+			 * Dummy clock for primecells
+			 */
+			pclk: pclk at 0 {
+				#clock-cells = <0>;
+				compatible = "fixed-clock";
+				clock-frequency = <2400000>;
+			};
+			/*
+			 * The 2.4 MHz TIMCLK reference clock is active at
+			 * boot time, this is actually the MXTALCLK @19.2 MHz
+			 * divided by 8. This clock is used by the timers and
+			 * watchdog. See page 105 ff.
+			 */
+			timclk: timclk at 2.4M {
+				#clock-cells = <0>;
+				compatible = "fixed-clock";
+				clock-frequency = <2400000>;
+			};
+			/*
+			 * At boot time, PLL2 is set to generate a set of
+			 * fixed clocks, one of them is CLK48, the 48 MHz
+			 * clock, routed to the UART, MMC/SD, I2C, IrDA,
+			 * USB and SSP blocks.
+			 */
+			clk48: clk48 at 48M {
+				#clock-cells = <0>;
+				compatible = "fixed-clock";
+				clock-frequency = <48000000>;
+			};
+		};
+	};
+
 	/* A NAND flash of 128 MiB */
 	fsmc: flash at 40000000 {
 		compatible = "stericsson,fsmc-nand";
@@ -97,6 +138,7 @@
 			<0x41000000 0x2000>,	/* NAND Base ADDR */
 			<0x40800000 0x2000>;	/* NAND Base CMD */
 		reg-names = "fsmc_regs", "nand_data", "nand_addr", "nand_cmd";
+		clocks = <&pclk>;
 		status = "okay";
 
 		partition at 0 {
@@ -211,6 +253,8 @@
 			reg = <0x101fd000 0x1000>;
 			interrupt-parent = <&vica>;
 			interrupts = <12>;
+			clocks = <&clk48>, <&pclk>;
+			clock-names = "uartclk", "apb_pclk";
 		};
 
 		uart1: uart at 101fb000 {
@@ -218,6 +262,8 @@
 			reg = <0x101fb000 0x1000>;
 			interrupt-parent = <&vica>;
 			interrupts = <17>;
+			clocks = <&clk48>, <&pclk>;
+			clock-names = "uartclk", "apb_pclk";
 		};
 
 		uart2: uart at 101f2000 {
@@ -225,17 +271,23 @@
 			reg = <0x101f2000 0x1000>;
 			interrupt-parent = <&vica>;
 			interrupts = <28>;
+			clocks = <&clk48>, <&pclk>;
+			clock-names = "uartclk", "apb_pclk";
 			status = "disabled";
 		};
 
 		rng: rng at 101b0000 {
 			compatible = "arm,primecell";
 			reg = <0x101b0000 0x1000>;
+			clocks = <&clk48>, <&pclk>;
+			clock-names = "rng", "apb_pclk";
 		};
 
 		rtc: rtc at 101e8000 {
 			compatible = "arm,pl031", "arm,primecell";
 			reg = <0x101e8000 0x1000>;
+			clocks = <&pclk>;
+			clock-names = "apb_pclk";
 			interrupt-parent = <&vica>;
 			interrupts = <10>;
 		};
@@ -243,6 +295,8 @@
 		mmcsd: sdi at 101f6000 {
 			compatible = "arm,pl18x", "arm,primecell";
 			reg = <0x101f6000 0x1000>;
+			clocks = <&clk48>, <&pclk>;
+			clock-names = "mclk", "apb_pclk";
 			interrupt-parent = <&vica>;
 			interrupts = <22>;
 			max-frequency = <48000000>;
diff --git a/arch/arm/mach-nomadik/cpu-8815.c b/arch/arm/mach-nomadik/cpu-8815.c
index 59f6ff5..0e2c5e0 100644
--- a/arch/arm/mach-nomadik/cpu-8815.c
+++ b/arch/arm/mach-nomadik/cpu-8815.c
@@ -280,28 +280,12 @@ device_initcall(cpu8815_mmcsd_init);
 
 /* These are mostly to get the right device names for the clock lookups */
 static struct of_dev_auxdata cpu8815_auxdata_lookup[] __initdata = {
-	OF_DEV_AUXDATA("st,nomadik-gpio", NOMADIK_GPIO0_BASE,
-		"gpio.0", NULL),
-	OF_DEV_AUXDATA("st,nomadik-gpio", NOMADIK_GPIO1_BASE,
-		"gpio.1", NULL),
-	OF_DEV_AUXDATA("st,nomadik-gpio", NOMADIK_GPIO2_BASE,
-		"gpio.2", NULL),
-	OF_DEV_AUXDATA("st,nomadik-gpio", NOMADIK_GPIO3_BASE,
-		"gpio.3", NULL),
 	OF_DEV_AUXDATA("stericsson,nmk-pinctrl-stn8815", 0,
 		"pinctrl-stn8815", NULL),
-	OF_DEV_AUXDATA("arm,primecell", NOMADIK_UART0_BASE,
-		"uart0", NULL),
-	OF_DEV_AUXDATA("arm,primecell", NOMADIK_UART1_BASE,
-		"uart1", NULL),
-	OF_DEV_AUXDATA("arm,primecell", NOMADIK_RNG_BASE,
-		"rng", NULL),
-	OF_DEV_AUXDATA("arm,primecell", NOMADIK_RTC_BASE,
-		"rtc-pl031", NULL),
 	OF_DEV_AUXDATA("stericsson,fsmc-nand", NOMADIK_FSMC_BASE,
-		"fsmc-nand", &cpu8815_nand_data),
+		NULL, &cpu8815_nand_data),
 	OF_DEV_AUXDATA("arm,primecell", NOMADIK_SDI_BASE,
-		"mmci", &mmcsd_plat_data),
+		NULL, &mmcsd_plat_data),
 	{ /* sentinel */ },
 };
 
diff --git a/drivers/clk/clk-nomadik.c b/drivers/clk/clk-nomadik.c
index 6b4c70f..19f197c 100644
--- a/drivers/clk/clk-nomadik.c
+++ b/drivers/clk/clk-nomadik.c
@@ -3,24 +3,24 @@
 #include <linux/err.h>
 #include <linux/io.h>
 #include <linux/clk-provider.h>
+#include <linux/of.h>
 
 /*
  * The Nomadik clock tree is described in the STN8815A12 DB V4.2
  * reference manual for the chip, page 94 ff.
  */
 
+static const __initconst struct of_device_id cpu8815_clk_match[] = {
+	{ .compatible = "fixed-clock", .data = of_fixed_clk_setup, },
+	{ /* sentinel */ }
+};
+
 void __init nomadik_clk_init(void)
 {
 	struct clk *clk;
 
 	clk = clk_register_fixed_rate(NULL, "apb_pclk", NULL, CLK_IS_ROOT, 0);
 	clk_register_clkdev(clk, "apb_pclk", NULL);
-	clk_register_clkdev(clk, NULL, "gpio.0");
-	clk_register_clkdev(clk, NULL, "gpio.1");
-	clk_register_clkdev(clk, NULL, "gpio.2");
-	clk_register_clkdev(clk, NULL, "gpio.3");
-	clk_register_clkdev(clk, NULL, "rng");
-	clk_register_clkdev(clk, NULL, "fsmc-nand");
 
 	/*
 	 * The 2.4 MHz TIMCLK reference clock is active at boot time, this is
@@ -32,17 +32,5 @@ void __init nomadik_clk_init(void)
 	clk_register_clkdev(clk, NULL, "mtu0");
 	clk_register_clkdev(clk, NULL, "mtu1");
 
-	/*
-	 * At boot time, PLL2 is set to generate a set of fixed clocks,
-	 * one of them is CLK48, the 48 MHz clock, routed to the UART, MMC/SD
-	 * I2C, IrDA, USB and SSP blocks.
-	 */
-	clk = clk_register_fixed_rate(NULL, "CLK48", NULL, CLK_IS_ROOT,
-				      48000000);
-	clk_register_clkdev(clk, NULL, "uart0");
-	clk_register_clkdev(clk, NULL, "uart1");
-	clk_register_clkdev(clk, NULL, "mmci");
-	clk_register_clkdev(clk, NULL, "ssp");
-	clk_register_clkdev(clk, NULL, "nmk-i2c.0");
-	clk_register_clkdev(clk, NULL, "nmk-i2c.1");
+	of_clk_init(cpu8815_clk_match);
 }
-- 
1.8.1.4



From linus.walleij at linaro.org  Sat Apr 20 10:09:43 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Sat, 20 Apr 2013 16:09:43 +0200
Subject: [PATCH 4/4] ARM: nomadik: register clocksource from device tree
Message-ID: <1366466983-16151-1-git-send-email-linus.walleij@linaro.org>

This switches the Nomadik platform to also registering its
clocksource from the device tree, removing unused support
code as we go along.

Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 arch/arm/boot/dts/ste-nomadik-stn8815.dtsi | 11 ++++++++---
 arch/arm/mach-nomadik/Kconfig              |  1 +
 arch/arm/mach-nomadik/cpu-8815.c           |  6 +++---
 drivers/clk/clk-nomadik.c                  | 15 ---------------
 4 files changed, 12 insertions(+), 21 deletions(-)

diff --git a/arch/arm/boot/dts/ste-nomadik-stn8815.dtsi b/arch/arm/boot/dts/ste-nomadik-stn8815.dtsi
index f0df948..51a33e0 100644
--- a/arch/arm/boot/dts/ste-nomadik-stn8815.dtsi
+++ b/arch/arm/boot/dts/ste-nomadik-stn8815.dtsi
@@ -21,18 +21,23 @@
 		cache-level = <2>;
 	};
 
-	mtu0 {
+	mtu0: mtu at 101e2000 {
 		/* Nomadik system timer */
+		compatible = "st,nomadik-mtu";
 		reg = <0x101e2000 0x1000>;
 		interrupt-parent = <&vica>;
 		interrupts = <4>;
+		clocks = <&timclk>, <&pclk>;
+		clock-names = "timclk", "apb_pclk";
 	};
 
-	mtu1 {
+	mtu1: mtu at 101e3000 {
 		/* Secondary timer */
 		reg = <0x101e3000 0x1000>;
 		interrupt-parent = <&vica>;
 		interrupts = <5>;
+		clocks = <&timclk>, <&pclk>;
+		clock-names = "timclk", "apb_pclk";
 	};
 
 	gpio0: gpio at 101e4000 {
@@ -101,7 +106,7 @@
 			pclk: pclk at 0 {
 				#clock-cells = <0>;
 				compatible = "fixed-clock";
-				clock-frequency = <2400000>;
+				clock-frequency = <0>;
 			};
 			/*
 			 * The 2.4 MHz TIMCLK reference clock is active at
diff --git a/arch/arm/mach-nomadik/Kconfig b/arch/arm/mach-nomadik/Kconfig
index 8c1ccd4..4eafec3 100644
--- a/arch/arm/mach-nomadik/Kconfig
+++ b/arch/arm/mach-nomadik/Kconfig
@@ -6,6 +6,7 @@ config ARCH_NOMADIK
 	select ARM_VIC
 	select CLKSRC_NOMADIK_MTU
 	select CLKSRC_NOMADIK_MTU_SCHED_CLOCK
+	select CLKSRC_OF
 	select COMMON_CLK
 	select CPU_ARM926T
 	select GENERIC_CLOCKEVENTS
diff --git a/arch/arm/mach-nomadik/cpu-8815.c b/arch/arm/mach-nomadik/cpu-8815.c
index 0e2c5e0..e73a71f7 100644
--- a/arch/arm/mach-nomadik/cpu-8815.c
+++ b/arch/arm/mach-nomadik/cpu-8815.c
@@ -29,7 +29,7 @@
 #include <linux/platform_data/clk-nomadik.h>
 #include <linux/platform_data/pinctrl-nomadik.h>
 #include <linux/pinctrl/machine.h>
-#include <linux/platform_data/clocksource-nomadik-mtu.h>
+#include <linux/clocksource.h>
 #include <linux/of_irq.h>
 #include <linux/of_gpio.h>
 #include <linux/of_address.h>
@@ -172,7 +172,7 @@ static void __init cpu8815_timer_init_of(void)
 	/* We need this to be up now */
 	nomadik_clk_init();
 
-	mtu = of_find_node_by_path("/mtu0");
+	mtu = of_find_node_by_path("/mtu at 101e2000");
 	if (!mtu)
 		return;
 	base = of_iomap(mtu, 0);
@@ -188,7 +188,7 @@ static void __init cpu8815_timer_init_of(void)
 	src_cr |= SRC_CR_INIT_VAL;
 	writel(src_cr, base);
 
-	nmdk_timer_init(base, irq);
+	clocksource_of_init();
 }
 
 static struct fsmc_nand_timings cpu8815_nand_timings = {
diff --git a/drivers/clk/clk-nomadik.c b/drivers/clk/clk-nomadik.c
index 19f197c..4a1ab27 100644
--- a/drivers/clk/clk-nomadik.c
+++ b/drivers/clk/clk-nomadik.c
@@ -17,20 +17,5 @@ static const __initconst struct of_device_id cpu8815_clk_match[] = {
 
 void __init nomadik_clk_init(void)
 {
-	struct clk *clk;
-
-	clk = clk_register_fixed_rate(NULL, "apb_pclk", NULL, CLK_IS_ROOT, 0);
-	clk_register_clkdev(clk, "apb_pclk", NULL);
-
-	/*
-	 * The 2.4 MHz TIMCLK reference clock is active at boot time, this is
-	 * actually the MXTALCLK @19.2 MHz divided by 8. This clock is used
-	 * by the timers and watchdog. See page 105 ff.
-	 */
-	clk = clk_register_fixed_rate(NULL, "TIMCLK", NULL, CLK_IS_ROOT,
-				      2400000);
-	clk_register_clkdev(clk, NULL, "mtu0");
-	clk_register_clkdev(clk, NULL, "mtu1");
-
 	of_clk_init(cpu8815_clk_match);
 }
-- 
1.8.1.4



From liuj97 at gmail.com  Sat Apr 20 11:19:58 2013
From: liuj97 at gmail.com (Jiang Liu)
Date: Sat, 20 Apr 2013 23:19:58 +0800
Subject: [PATCH v4, part3 13/41] mm/ARM: prepare for removing num_physpages
 and simplify mem_init()
In-Reply-To: <20130419165429.GA14496@n2100.arm.linux.org.uk>
References: <1365258760-30821-1-git-send-email-jiang.liu@huawei.com>
 <1365258760-30821-14-git-send-email-jiang.liu@huawei.com>
 <20130419165429.GA14496@n2100.arm.linux.org.uk>
Message-ID: <5172B21E.9000805@gmail.com>

On 04/20/2013 12:54 AM, Russell King - ARM Linux wrote:
> On Sat, Apr 06, 2013 at 10:32:12PM +0800, Jiang Liu wrote:
>> Prepare for removing num_physpages and simplify mem_init().
>>
>> Signed-off-by: Jiang Liu <jiang.liu at huawei.com>
>> Cc: Russell King <linux at arm.linux.org.uk>
>> Cc: Catalin Marinas <catalin.marinas at arm.com>
>> Cc: Will Deacon <will.deacon at arm.com>
>> Cc: linux-arm-kernel at lists.infradead.org
>> Cc: linux-kernel at vger.kernel.org
>> ---
>>  arch/arm/mm/init.c |   47 ++---------------------------------------------
>>  1 file changed, 2 insertions(+), 45 deletions(-)
>>
>> diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
>> index add4fcb..7a911d1 100644
>> --- a/arch/arm/mm/init.c
>> +++ b/arch/arm/mm/init.c
>> @@ -582,9 +582,6 @@ static void __init free_highpages(void)
>>   */
>>  void __init mem_init(void)
>>  {
>> -	unsigned long reserved_pages, free_pages;
>> -	struct memblock_region *reg;
>> -	int i;
>>  #ifdef CONFIG_HAVE_TCM
>>  	/* These pointers are filled in on TCM detection */
>>  	extern u32 dtcm_end;
>> @@ -605,47 +602,7 @@ void __init mem_init(void)
>>  
>>  	free_highpages();
>>  
>> -	reserved_pages = free_pages = 0;
>> -
>> -	for_each_bank(i, &meminfo) {
>> -		struct membank *bank = &meminfo.bank[i];
>> -		unsigned int pfn1, pfn2;
>> -		struct page *page, *end;
>> -
>> -		pfn1 = bank_pfn_start(bank);
>> -		pfn2 = bank_pfn_end(bank);
>> -
>> -		page = pfn_to_page(pfn1);
>> -		end  = pfn_to_page(pfn2 - 1) + 1;
>> -
>> -		do {
>> -			if (PageReserved(page))
>> -				reserved_pages++;
>> -			else if (!page_count(page))
>> -				free_pages++;
>> -			page++;
>> -		} while (page < end);
>> -	}
>> -
>> -	/*
>> -	 * Since our memory may not be contiguous, calculate the
>> -	 * real number of pages we have in this system
>> -	 */
>> -	printk(KERN_INFO "Memory:");
>> -	num_physpages = 0;
>> -	for_each_memblock(memory, reg) {
>> -		unsigned long pages = memblock_region_memory_end_pfn(reg) -
>> -			memblock_region_memory_base_pfn(reg);
>> -		num_physpages += pages;
>> -		printk(" %ldMB", pages >> (20 - PAGE_SHIFT));
>> -	}
>> -	printk(" = %luMB total\n", num_physpages >> (20 - PAGE_SHIFT));
>> -
>> -	printk(KERN_NOTICE "Memory: %luk/%luk available, %luk reserved, %luK highmem\n",
>> -		nr_free_pages() << (PAGE_SHIFT-10),
>> -		free_pages << (PAGE_SHIFT-10),
>> -		reserved_pages << (PAGE_SHIFT-10),
>> -		totalhigh_pages << (PAGE_SHIFT-10));
>> +	mem_init_print_info(NULL);
> 
> I'm concerned about this.  We explicitly do not use the memblock information
> when walking the memory above for the reserved/free pages because memblock
> merges the various banks of memory together - and those may cross sparsemem
> boundaries.  Any crossing of the sparsemem boundaries needs the struct page
> pointer to be re-evaluated because it can be part of a different array of
> such things.
> 
> Where's the rest of the patches?
> 
Hi Russel,
	Thanks for review the patch. You may find the patch introducing 
mem_init_print_info() at: http://marc.info/?l=linux-mm&m=136525938817934&w=2
Basically it prints standard memory statistics info as below for all architectures
without walking the page structure array.
Memory: 7744624K/8074824K available (6969K kernel code, 1011K data, 2828K rodata, 1016K init, 9640K bss, 330200K reserved)

On the other hand, the patch does change information printed on boot, especially
it doesn't print size of each memory block. If needed, I can revert the code to
print size of each memory block.

	Regards!
	Gerry





From mikedunn at newsguy.com  Sat Apr 20 11:26:16 2013
From: mikedunn at newsguy.com (Mike Dunn)
Date: Sat, 20 Apr 2013 08:26:16 -0700
Subject: gpio-pxa initcall level change and machine init breakage
Message-ID: <5172B398.7060706@newsguy.com>

Hi,

After a few months of neglect, I rebased my palm treo 680 kernel with the latest
from Linus' official tree, and now all the calls to gpio lib functions
(gpio_request(), etc) made from the init_machine() method in struct machine_desc
fail.  I tracked this back to commit 6c7e660a27da7494c670bfba21cfeba30457656c
dated Jan 23 2013

    gpio: pxa: set initcall level to module init

    gpio & pinctrl driver are used together. The pinctrl driver is already
    launched before gpio driver in Makefile. So set gpio driver to module
    init level. Otherwise, the sequence will be inverted.

    Signed-off-by: Haojian Zhuang <haojian.zhuang at linaro.org>
    Signed-off-by: Linus Walleij <linus.walleij at linaro.org>

At the time, Haojian addressed a question about this patch regarding module
dependencies, advising use of the deferred probe infrastructure.  But unless I'm
mistaken, mine is an initcall level problem, not a dependency issue among driver
probes.  Now that gpio-pxa initialization is at the device level (initcall6),
calls to gpiolib are no longer possible from init_machine(), which remains at
the initcall3 level.

I feel like I must be missing something, because a lot of pxa boards call
gpiolib from init machine(), so my breakage should not be an isolated case.

If I'm not missing anything and the patch is necessary, it looks like one
solution would be to move all the initializations that use gpiolib to the
init_late method in struct machine_desc, which runs as initcall7.

Grateful for any advice!

Thanks,
Mike


From liuj97 at gmail.com  Sat Apr 20 11:34:34 2013
From: liuj97 at gmail.com (Jiang Liu)
Date: Sat, 20 Apr 2013 23:34:34 +0800
Subject: [PATCH v4,
 part3 01/15] mm: fix build warnings caused by free_reserved_area()
In-Reply-To: <20130419165208.GZ14496@n2100.arm.linux.org.uk>
References: <1365256509-29024-1-git-send-email-jiang.liu@huawei.com>
 <1365256509-29024-2-git-send-email-jiang.liu@huawei.com>
 <20130419165208.GZ14496@n2100.arm.linux.org.uk>
Message-ID: <5172B58A.3090006@gmail.com>

On 04/20/2013 12:52 AM, Russell King - ARM Linux wrote:
> On Sat, Apr 06, 2013 at 09:54:55PM +0800, Jiang Liu wrote:
>> Fix following build warnings cuased by free_reserved_area():
>>
>> arch/arm/mm/init.c: In function 'mem_init':
>> arch/arm/mm/init.c:603:2: warning: passing argument 1 of 'free_reserved_area' makes integer from pointer without a cast [enabled by default]
>>   free_reserved_area(__va(PHYS_PFN_OFFSET), swapper_pg_dir, 0, NULL);
>>   ^
>> In file included from include/linux/mman.h:4:0,
>>                  from arch/arm/mm/init.c:15:
>> include/linux/mm.h:1301:22: note: expected 'long unsigned int' but argument is of type 'void *'
>>  extern unsigned long free_reserved_area(unsigned long start, unsigned long end,
>>
>>    mm/page_alloc.c: In function 'free_reserved_area':
>>>> mm/page_alloc.c:5134:3: warning: passing argument 1 of 'virt_to_phys' makes pointer from integer without a cast [enabled by default]
>>    In file included from arch/mips/include/asm/page.h:49:0,
>>                     from include/linux/mmzone.h:20,
>>                     from include/linux/gfp.h:4,
>>                     from include/linux/mm.h:8,
>>                     from mm/page_alloc.c:18:
>>    arch/mips/include/asm/io.h:119:29: note: expected 'const volatile void *' but argument is of type 'long unsigned int'
>>    mm/page_alloc.c: In function 'free_area_init_nodes':
>>    mm/page_alloc.c:5030:34: warning: array subscript is below array bounds [-Warray-bounds]
>>
>> Signed-off-by: Jiang Liu <jiang.liu at huawei.com>
>> Reported-by: Arnd Bergmann <arnd at arndb.de>
>> Cc: linux-arm-kernel at lists.infradead.org
>> Cc: linux-kernel at vger.kernel.org
>> Cc: linux-mm at kvack.org
>> ---
>>  arch/arm/mm/init.c |    6 ++++--
>>  mm/page_alloc.c    |    2 +-
>>  2 files changed, 5 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
>> index 9a5cdc0..7a82fcd 100644
>> --- a/arch/arm/mm/init.c
>> +++ b/arch/arm/mm/init.c
>> @@ -600,7 +600,8 @@ void __init mem_init(void)
>>  
>>  #ifdef CONFIG_SA1111
>>  	/* now that our DMA memory is actually so designated, we can free it */
>> -	free_reserved_area(__va(PHYS_PFN_OFFSET), swapper_pg_dir, 0, NULL);
>> +	free_reserved_area((unsigned long)__va(PHYS_PFN_OFFSET),
>> +			   (unsigned long)swapper_pg_dir, 0, NULL);
>>  #endif
>>  
>>  	free_highpages();
>> @@ -728,7 +729,8 @@ void free_initmem(void)
>>  	extern char __tcm_start, __tcm_end;
>>  
>>  	poison_init_mem(&__tcm_start, &__tcm_end - &__tcm_start);
>> -	free_reserved_area(&__tcm_start, &__tcm_end, 0, "TCM link");
>> +	free_reserved_area((unsigned long)&__tcm_start,
>> +			   (unsigned long)&__tcm_end, 0, "TCM link");
>>  #endif
>>  
>>  	poison_init_mem(__init_begin, __init_end - __init_begin);
>> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
>> index e4923e9..8bf7956 100644
>> --- a/mm/page_alloc.c
>> +++ b/mm/page_alloc.c
>> @@ -5196,7 +5196,7 @@ unsigned long free_reserved_area(unsigned long start, unsigned long end,
>>  	for (pages = 0; pos < end; pos += PAGE_SIZE, pages++) {
>>  		if (poison)
>>  			memset((void *)pos, poison, PAGE_SIZE);
>> -		free_reserved_page(virt_to_page(pos));
>> +		free_reserved_page(virt_to_page((void *)pos));
> 
> Don't all these casts suggest to you that you may have the type wrong
> in the first place?
> 
Hi Russell,
	Good question! 
	Originally free_reserved_area() is designed to simplify free_initrd_mem(), and 
free_initrd_mem() is declared as:
	void free_initrd_mem(unsigned long start, unsigned long end)
	So I have chosen "unsigned long" for free_reserved_area()'s first and second
parameters, otherwise it will cause much more type casts in function free_initrd_mem().
For code purity, we should use "void *" instead. So should we change to "void *" here?
	Regards!
	Gerry


From alexandre.belloni at free-electrons.com  Sat Apr 20 11:38:51 2013
From: alexandre.belloni at free-electrons.com (Alexandre Belloni)
Date: Sat, 20 Apr 2013 17:38:51 +0200
Subject: [PATCH 1/3] iio: Add Nuvoton NAU7802 ADC driver
In-Reply-To: <51726541.6060304@kernel.org>
References: <1366299536-18353-1-git-send-email-alexandre.belloni@free-electrons.com>
 <1366299536-18353-2-git-send-email-alexandre.belloni@free-electrons.com>
 <51726541.6060304@kernel.org>
Message-ID: <5172B68B.4010506@free-electrons.com>

Hi Jonathan,

Thanks for your review,

On 20/04/2013 11:52, Jonathan Cameron wrote:
> A few bits and pieces inline.
>
> Ouch, that interrupt handling is annoyingly complex.  Pesky hardware
> designers...
>

Right, even worse is that on the board we are using, the interrupt line
is connected to a pca9555 and that seems to not handle interrupts very
well and I think something is fishy in the driver. From want I read in
the datasheet, I suspect it only handles level interrupts but the driver
is only accepting edge interrupts.
It seems that sometimes we end up with the nau7802 correctly sending an
interrupt, the pca also correctly sending an interrupt but the pca
driver is then not calling the interrupt handlers. I also suspect the
nau7802 to forget to switch the interrupt line when we ask for fast
conversions. I investigated that a bit but I'm still waiting for my
logic analyzer to get delivered to go further.

>> diff --git a/Documentation/devicetree/bindings/iio/adc/nuvoton-nau7802.txt b/Documentation/devicetree/bindings/iio/adc/nuvoton-nau7802.txt
>> new file mode 100644
>> index 0000000..9bc4218
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/iio/adc/nuvoton-nau7802.txt
>> @@ -0,0 +1,17 @@
>> +* Nuvoton NAU7802 Analog to Digital Converter (ADC)
>> +
>> +Required properties:
>> +  - compatible: Should be "nuvoton,nau7802"
>> +  - reg: Should contain the ADC I2C address
>> +
>> +Optional properties:
>> +  - nuvoton,vldo: Reference voltage in millivolts (integer)
> As this is external I'd personally prefer using the regulator subsystem
> to provide it.  That gives a more flexible way of supplying it.
> If fixed you can always use a fixed regulator...

Actually, that one allows us to configure the internal LDO. The nau7802
is also able to get that voltage from an external source but indeed,
this is not well handled by the driver currently. How do you suggest to
manage those cases then ?

>
> +
> +struct nau7802_state {
> +	struct i2c_client	*client;
> +	s32			last_value;
> I can't immediately see why you need two locks...
> I think the datalock is only ever taken when the
> lock is already held (be it in a threaded irq).

Actually, "lock" is taken by read_raw() but, we still want the interrupt
handler thread to be able to run while waiting for the completion (else,
we would just timeout every time). Main goal of data_lock is to prevent
reading part of the output from the interrupt handler and part from
read_raw().

>> +	struct mutex		lock;
>> +	struct mutex		data_lock;
>> +	u32			vref_mv;
>> +	u32			conversion_count;
>> +	u32			min_conversions;
>> +	u8			sample_rate;
>> +	struct completion	value_ok;
>> +};
>> +
>> +static int nau7802_i2c_read(struct nau7802_state *st, u8 reg, u8 *data)
>> +{
>> +	int ret = 0;
>> +
>> +	ret = i2c_smbus_read_byte_data(st->client, reg);
>> +	if (ret < 0) {
>> +		dev_err(&st->client->dev, "failed to read from I2C\n");
>> +		return ret;
>> +	}
>> +
>> +	*data = ret;
>> +
>> +	return 0;
>> +}
>> +
> Don't wrap standard functions like this. Call them directly. It's not
> worth the added complexity to get a not particularly informative error message
> from the read.

OK, it was mainly useful for debugging as we had some troubles with the
underlying i2c driver. I will remove those.

>> +static int nau7802_i2c_write(struct nau7802_state *st, u8 reg, u8 data)
>> +{
>> +	return i2c_smbus_write_byte_data(st->client, reg, data);
>> +}
>> +
>> +static const u16 nau7802_sample_freq_avail[] = {10, 20, 40, 80,
>> +						10, 10, 10, 320};
>> +
>> +static ssize_t nau7802_sysfs_set_sampling_frequency(struct device *dev,
>> +		struct device_attribute *attr,
>> +		const char *buf,
>> +		size_t len)
>> +{
>> +	struct iio_dev *idev = dev_to_iio_dev(dev);
>> +	struct nau7802_state *st = iio_priv(idev);
>> +	u32 val;
>> +	int ret, i;
>> +
>> +	ret = kstrtouint(buf, 10, &val);
>> +	if (ret)
>> +		return ret;
>> +
>> +	ret = -EINVAL;
>> +	for (i = 0; i < 8; i++)
>> +		if (val == nau7802_sample_freq_avail[i]) {
>> +			mutex_lock(&st->lock);
>> +			st->sample_rate = i;
>> +			st->conversion_count = 0;
>> +			nau7802_i2c_write(st, NAU7802_REG_CTRL2,
>> +					NAU7802_CTRL2_CRS(st->sample_rate));
>> +			mutex_unlock(&st->lock);
>> +			ret = len;
>> +			break;
>> +		}
>> +	return ret;
>> +}
>> +
>> +static ssize_t nau7802_sysfs_get_sampling_frequency(struct device *dev,
>> +		struct device_attribute *attr,
>> +		char *buf)
>> +{
>> +	struct iio_dev *idev = dev_to_iio_dev(dev);
>> +	struct nau7802_state *st = iio_priv(idev);
>> +
>> +	return sprintf(buf, "%d\n",
>> +	       nau7802_sample_freq_avail[st->sample_rate]);
>> +}
>> +
>> +static IIO_DEV_ATTR_SAMP_FREQ(S_IWUSR | S_IRUGO,
>> +		nau7802_sysfs_get_sampling_frequency,
>> +		nau7802_sysfs_set_sampling_frequency);
>> +
>> +static IIO_CONST_ATTR_SAMP_FREQ_AVAIL("10 40 80 320");
>> +
>> +static IIO_CONST_ATTR(gain_available, "1 2 4 8 16 32 64 128");
>> +
>> +static ssize_t nau7802_sysfs_set_gain(struct device *dev,
>> +		struct device_attribute *attr,
>> +		const char *buf,
>> +		size_t len)
>> +{
>> +	struct iio_dev *idev = dev_to_iio_dev(dev);
>> +	struct nau7802_state *st = iio_priv(idev);
>> +	u32 val;
>> +	u8 data;
>> +	int ret;
>> +
>> +	ret = kstrtouint(buf, 10, &val);
>> +	if (ret)
>> +		return ret;
>> +
>> +	if (val < 1 || val > 128 || !is_power_of_2(val))
>> +		return -EINVAL;
>> +
>> +	mutex_lock(&st->lock);
>> +	st->conversion_count = 0;
>> +
>> +	ret = nau7802_i2c_read(st, NAU7802_REG_CTRL1, &data);
>> +	if (ret < 0)
>> +		goto nau7802_sysfs_set_gain_out;
>> +	ret = nau7802_i2c_write(st, NAU7802_REG_CTRL1,
>> +			(data & (~NAU7802_CTRL1_GAINS_BITS)) | ilog2(val));
>> +nau7802_sysfs_set_gain_out:
>> +	mutex_unlock(&st->lock);
>> +	return ret ? ret : len;
>> +}
>> +
>> +static ssize_t nau7802_sysfs_get_gain(struct device *dev,
>> +		struct device_attribute *attr,
>> +		char *buf)
>> +{
>> +	struct iio_dev *idev = dev_to_iio_dev(dev);
>> +	struct nau7802_state *st = iio_priv(idev);
>> +	u8 data;
>> +	int ret;
>> +
>> +	ret = nau7802_i2c_read(st, NAU7802_REG_CTRL1, &data);
>> +	if (ret < 0)
>> +		return ret;
>> +
>> +	return sprintf(buf, "%d\n", 1 << (data & NAU7802_CTRL1_GAINS_BITS));
>> +}
>> +
>> +static IIO_DEVICE_ATTR(gain, S_IWUSR | S_IRUGO,
>> +		nau7802_sysfs_get_gain,
>> +		nau7802_sysfs_set_gain, 0);
>> +
>> +static ssize_t nau7802_sysfs_set_min_conversions(struct device *dev,
>> +		struct device_attribute *attr,
>> +		const char *buf,
>> +		size_t len)
>> +{
>> +	struct iio_dev *idev = dev_to_iio_dev(dev);
>> +	struct nau7802_state *st = iio_priv(idev);
>> +	u32 val;
>> +	int ret;
>> +
>> +	ret = kstrtouint(buf, 10, &val);
>> +	if (ret)
>> +		return ret;
>> +
>> +	mutex_lock(&st->lock);
>> +	st->min_conversions = val;
>> +	st->conversion_count = 0;
>> +	mutex_unlock(&st->lock);
>> +	return len;
>> +}
>> +
>> +static ssize_t nau7802_sysfs_get_min_conversions(struct device *dev,
>> +		struct device_attribute *attr,
>> +		char *buf)
>> +{
>> +	struct iio_dev *idev = dev_to_iio_dev(dev);
>> +	struct nau7802_state *st = iio_priv(idev);
>> +
>> +	return sprintf(buf, "%d\n", st->min_conversions);
>> +}
>> +
>> +static IIO_DEVICE_ATTR(min_conversions, S_IWUSR | S_IRUGO,
>> +		nau7802_sysfs_get_min_conversions,
>> +		nau7802_sysfs_set_min_conversions, 0);
>> +
>> +static struct attribute *nau7802_attributes[] = {
> Given you have only adc channels you could just use the relevant
> info_mask element for and have this as a shared attribute of them.

Right, I'll have a look at that.
>> +	&iio_dev_attr_sampling_frequency.dev_attr.attr,
>> +	&iio_const_attr_sampling_frequency_available.dev_attr.attr,
> Just have a range of scale options available and figure out which
> gain they correspond to.  Obviously you'll need a write_raw callback
> to implement that, but it's pretty standard and conforms to the iio
> abi which this does not.   I've been meaning to clean up the way
> 'available' is handled but for now you will probaby want to have
> a suitable gain here.

Yeah, I was wondering about doing that. But as it is also possible to
set the internal voltage, I will have to be clever to get the best vldo
and gain couple to have the best range.

>> +	&iio_dev_attr_gain.dev_attr.attr,
>> +	&iio_const_attr_gain_available.dev_attr.attr,
>> +	&iio_dev_attr_min_conversions.dev_attr.attr,
> What governs this?  Looks to me more like it should be hidden away
> in the device tree than be here.

I guess it will depend on what you connect to your adc. Do we want to
fix that in the DT or to be able to change it at runtime ?

>> +	NULL
>> +};
>> +
>> +static const struct attribute_group nau7802_attribute_group = {
>> +	.attrs = nau7802_attributes,
>> +};
>> +
>> +static int nau7802_read_conversion(struct nau7802_state *st)
>> +{
>> +	int ret;
>> +	u8 data;
>> +
>> +	mutex_lock(&st->data_lock);
>> +	ret = nau7802_i2c_read(st, NAU7802_REG_ADC_B2, &data);
>> +	if (ret)
>> +		goto nau7802_read_conversion_out;
>> +	st->last_value = data << 24;
>> +
>> +	ret = nau7802_i2c_read(st, NAU7802_REG_ADC_B1, &data);
>> +	if (ret)
>> +		goto nau7802_read_conversion_out;
>> +	st->last_value |= data << 16;
>> +
>> +	ret = nau7802_i2c_read(st, NAU7802_REG_ADC_B0, &data);
>> +	if (ret)
>> +		goto nau7802_read_conversion_out;
>> +	st->last_value |= data << 8;
>> +
>> +	st->last_value >>= 8;
> umm. Why shift everything 8 to the left then 8 to the right?

The nau7802 is handling 24 bits of *signed* data. Doing that allows us
to store the signed 24bits value in a signed 32bits integer. Is there a
more clever way ?

>> +
>> +nau7802_read_conversion_out:
>> +	mutex_unlock(&st->data_lock);
>> +	return ret;
>> +}
>> +
> What does this do?  Perhaps a comment?
The conversions are synchronized on the rising edge of the CS bit of
PUCTRL. It is not necessarily needed but it can be nice when wse are
running slow, like at 10 samples per second.
>> +static int nau7802_sync(struct nau7802_state *st)
>> +{
>> +	int ret;
>> +	u8 data;
>> +
>> +	ret = nau7802_i2c_read(st, NAU7802_REG_PUCTRL, &data);
>> +	if (ret)
>> +		return ret;
>> +	ret = nau7802_i2c_write(st, NAU7802_REG_PUCTRL,
>> +				data | NAU7802_PUCTRL_CS_BIT);
>> +	return ret;
>> +}
>> +
>> +static irqreturn_t nau7802_eoc_trigger(int irq, void *private)
>> +{
>> +	struct iio_dev *idev = private;
>> +	struct nau7802_state *st = iio_priv(idev);
>> +	u8 status;
>> +	int ret;
>> +
>> +	ret = nau7802_i2c_read(st, NAU7802_REG_PUCTRL, &status);
>> +	if (ret)
>> +		return IRQ_HANDLED;
>> +
>> +	if (!(status & NAU7802_PUCTRL_CR_BIT))
>> +		return IRQ_NONE;
>> +
>> +	if (nau7802_read_conversion(st))
>> +		return IRQ_HANDLED;
>> +
>> +	/* wait for enough conversions before getting a stable value when
>> +	 * changing channels */
>> +	if (st->conversion_count < st->min_conversions)
>> +		st->conversion_count++;
>> +	if (st->conversion_count >= st->min_conversions)
>> +		complete_all(&st->value_ok);
> pretty much always stick in a  blank line before return statements.
> Makes it easier to read...

Will do.
>> +	return IRQ_HANDLED;
>> +}
>> +
>> +static int nau7802_read_irq(struct iio_dev *idev,
>> +			struct iio_chan_spec const *chan,
>> +			int *val)
>> +{
>> +	struct nau7802_state *st = iio_priv(idev);
>> +	int ret;
>> +
>> +	INIT_COMPLETION(st->value_ok);
> So let me see if I have this correct.
>> +	enable_irq(st->client->irq);
> This will probably fire immediately as it is a level irq and we have had
> it masked.

It fires almost immediately. But like I said, on my setup the pca
doesn't seem to reliably call the interrupt handler at hte correct time.
Also, sometimes, as it is an interrupt thread, it may actually be
scheduled a bit later.
>> +
>> +	nau7802_sync(st);
> This flushes the device?
>> +
>> +	/* read registers to ensure we flush everything */
>> +	ret = nau7802_read_conversion(st);
>> +	if (ret)
>> +		goto read_chan_info_failure;
>> +
> This then ensures we have scrubbed any left over data?  Might scrub
> some extra but that isn't a problem...

We have to read the 3 output registers to be sure we shift out the
previous conversion result. It is also supposed to ensure we will get an
interrupt.

>> +	/* Wait for a conversion to finish */
>> +	ret = wait_for_completion_interruptible_timeout(&st->value_ok,
>> +			msecs_to_jiffies(1000));
> This will fire next time we have new data?

Yeah, we are actually waiting for a minimum number of conversions to
happen when switching channels because there is actually only one ADC
for the 2 channels. When the value are far apart, we have to wait for
some conversions to happen before we get a significant value. Maybe I
can add a comment for that too ?
> +	case IIO_CHAN_INFO_SCALE:
> +		ret = nau7802_i2c_read(st, NAU7802_REG_CTRL1, &data);
> +		if (ret < 0)
> +			return ret;
> +
> +		*val = 0;
> +		*val2 = (((u64)st->vref_mv) * 1000000000ULL) >>
> +			(chan->scan_type.realbits +
> +			 (data & NAU7802_CTRL1_GAINS_BITS));
> It's saturday morning and I'm half asleep so I'll take your word for
> this being the nicest way of computing this. However with a 23 bit
> adc measuring around 5V? I would have thought to get a decent number
> of significant figures you'd want to do IIO_VAL_INT_PLUS_NANO?

Sure, will do. It actually took me quite some time to get it right and
then I forgot to switch to IIO_VAL_INT_PLUS_NANO.

>> +		return IIO_VAL_INT_PLUS_MICRO;
>> +	default:
>> +		break;
>> +	}
>> +	return -EINVAL;
>> +}
>> +
>> +static const struct iio_info nau7802_info = {
>> +	.driver_module = THIS_MODULE,
>> +	.read_raw = &nau7802_read_raw,
>> +	.attrs = &nau7802_attribute_group,
>> +};
>> +
>> +static int nau7802_channel_init(struct iio_dev *idev)
>> +{
>> +	struct iio_chan_spec *chan_array;
>> +	int i;
>> +
>> +	idev->num_channels = 2;
>> +
>> +	chan_array = devm_kzalloc(&idev->dev,
>> +				  sizeof(*chan_array) * idev->num_channels,
>> +				  GFP_KERNEL);
>> +
> There are only two of them and that is pretty much fixed.  Do this with
> a const static array rather than dynamically. If you really want the
> flexibility on number of channels, then just set idev->num_channels
> appropriately and it'll ignore later entries in the table.
>
> Dynamic allocation only makes sense where we have a huge and complex
> set of possible channel combinations.

Ok, we only have 2 channels anyway.

>> +	for (i = 0; i < idev->num_channels; i++) {
>> +		struct iio_chan_spec *chan = chan_array + i;
>> +
>> +		chan->type = IIO_VOLTAGE;
>> +		chan->indexed = 1;
>> +		chan->channel = i;
>> +		chan->scan_index = i;
>> +		chan->scan_type.sign = 's';
>> +		chan->scan_type.realbits = 23;
> As I read it this part is a 24bit adc where they are committing to 23bits of good
> precision. As such realbits should be 24.
> Not that it's used for anything unless you are doing buffering!
> (so feel free to drop the scan_index and san_type entirely.
>> +		chan->scan_type.storagebits = 24;
>> +		chan->info_mask = IIO_CHAN_INFO_SCALE_SHARED_BIT |
>> +			IIO_CHAN_INFO_RAW_SEPARATE_BIT;
> This has changed, take a look at the latest staging-next.

I'll have a look.

>> +	}
>> +	idev->channels = chan_array;
>> +
>> +	return idev->num_channels;
>> +}
>> +
>> +static int nau7802_probe(struct i2c_client *client,
>> +			const struct i2c_device_id *id)
>> +{
>> +	struct iio_dev *idev;
>> +	struct nau7802_state *st;
>> +	struct device_node *np = client->dev.of_node;
>> +	int ret;
>> +	u8 data;
>> +	u32 tmp;
>> +
>> +	if (!client->dev.of_node) {
>> +		dev_err(&client->dev, "No device tree node available.\n");
>> +		return -EINVAL;
>> +	}
>> +
>> +	/*
>> +	 * If we have some interrupts declared, use them, if not, fall back
>> +	 * on polling.
>> +	 */
>> +	if (of_find_property(np, "interrupts", NULL)) {
>> +		if (client->irq <= 0) {
>> +			client->irq = irq_of_parse_and_map(np, 0);
>> +			if (client->irq <= 0)
>> +				return -EPROBE_DEFER;
>> +		}
>> +	} else
>> +		client->irq = 0;
>> +
>> +	idev = iio_device_alloc(sizeof(struct nau7802_state));
> sizeof(*st) is a little cleaner.
> Also we have pretty much standardized on calling the iio_dev
> indio_dev (no idea why but it's how it turned out ;)  Whilst
> it doesn't really matter it does make reviewers jobs marginally
> easier ;)

OK
>> +	if (idev == NULL)
>> +		return -ENOMEM;
>> +
>> +	st = iio_priv(idev);
>> +
>> +	i2c_set_clientdata(client, idev);
>> +
>> +	idev->dev.parent = &client->dev;
>> +	idev->name = dev_name(&client->dev);
>> +	idev->modes = INDIO_DIRECT_MODE;
>> +	idev->info = &nau7802_info;
>> +
>> +	st->client = client;
>> +
>> +	/* Reset the device */
>> +	nau7802_i2c_write(st, NAU7802_REG_PUCTRL, NAU7802_PUCTRL_RR_BIT);
>> +
>> +	/* Enter normal operation mode */
>> +	nau7802_i2c_write(st, NAU7802_REG_PUCTRL, NAU7802_PUCTRL_PUD_BIT);
>> +
>> +	/*
>> +	 * After about 200 usecs, the device should be ready and then
>> +	 * the Power Up bit will be set to 1. If not, wait for it.
>> +	 */
>> +	do {
>> +		udelay(200);
>> +		ret = nau7802_i2c_read(st, NAU7802_REG_PUCTRL, &data);
>> +		if (ret)
>> +			return -ENODEV;
> You want some sort of timeout and fail here.  Perasonally if the device
> should be ready in 200 usec, I'd only let it have one go at doing so
> before failing (or give 250 usec if it's not all that precise).
Right.
>> +	} while (!(data & NAU7802_PUCTRL_PUR_BIT));
>> +
>> +	of_property_read_u32(np, "nuvoton,vldo", &tmp);
>> +	st->vref_mv = tmp;
>> +
>> +	data = NAU7802_PUCTRL_PUD_BIT | NAU7802_PUCTRL_PUA_BIT |
>> +		NAU7802_PUCTRL_CS_BIT;
>> +	if (tmp >= 2400)
>> +		data |= NAU7802_PUCTRL_AVDDS_BIT;
>> +
>> +	nau7802_i2c_write(st, NAU7802_REG_PUCTRL, data);
>> +	nau7802_i2c_write(st, NAU7802_REG_ADC_CTRL, 0x30);
>> +
>> +	if (tmp >= 2400) {
>> +		data = NAU7802_CTRL1_VLDO((4500 - tmp) / 300);
>> +		nau7802_i2c_write(st, NAU7802_REG_CTRL1, data);
>> +	}
>> +
>> +	st->min_conversions = 6;
>> +
>> +	/*
>> +	 * The ADC fires continuously and we can't do anything about
>> +	 * it. So we need to have the IRQ disabled by default, and we
>> +	 * will enable them back when we will need them..
>> +	 */
>> +	if (client->irq) {
>> +		irq_set_status_flags(client->irq, IRQ_NOAUTOEN);
>> +		ret = request_threaded_irq(client->irq,
>> +				NULL,
>> +				nau7802_eoc_trigger,
>> +				IRQF_TRIGGER_HIGH | IRQF_ONESHOT,
>> +				client->dev.driver->name,
>> +				idev);
>> +		if (ret) {
>> +			/*
>> +			 * What may happen here is that our IRQ controller is
>> +			 * not able to get level interrupt but this is required
>> +			 * by this ADC as when going over 40 sample per second,
>> +			 * the interrupt line may stay high between conversions.
>> +			 * So, we continue no matter what but we switch to
>> +			 * polling mode.
>> +			 */
> Good plan.  Pesky hardware designers and not guaranteeing transitions. ;)

Yeah, I'll still have to check whether it is an issue with the pca or
the nau. I actually suspect both ;)
But anyway, as we are able to poll, I think it is still a good idea to
choose polling when your interrupt controller is not able to handle your
interrupt type.

>> +			dev_info(&client->dev,
>> +				"Failed to allocate IRQ, using polling mode\n");
>> +			client->irq = 0;
>> +			/*
>> +			 * We are polling, use the fastest sample rate by
>> +			 * default
>> +			 */
>> +			st->sample_rate = 0x7;
>> +			nau7802_i2c_write(st, NAU7802_REG_CTRL2,
>> +					NAU7802_CTRL2_CRS(st->sample_rate));
>> +		}
>> +	}
>> +
>> +	/* Setup the ADC channels available on the board */
>> +	ret = nau7802_channel_init(idev);
>> +	if (ret < 0) {
>> +		dev_err(&client->dev, "Couldn't initialize the channels.\n");
>> +		goto error_channel_init;
>> +	}
>> +
>> +	init_completion(&st->value_ok);
>> +	mutex_init(&st->lock);
>> +	mutex_init(&st->data_lock);
>> +
>> +	ret = iio_device_register(idev);
>> +	if (ret < 0) {
>> +		dev_err(&client->dev, "Couldn't register the device.\n");
>> +		goto error_device_register;
>> +	}
>> +
>> +	return 0;
>> +
>> +error_device_register:
>> +	mutex_destroy(&st->lock);
> datalock?
oops

Thanks again for your review, I'll prepare a v2 while waiting for your
answers.

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com



From lars at metafoo.de  Sat Apr 20 12:49:40 2013
From: lars at metafoo.de (Lars-Peter Clausen)
Date: Sat, 20 Apr 2013 18:49:40 +0200
Subject: [PATCH 1/3] iio: Add Nuvoton NAU7802 ADC driver
In-Reply-To: <1366299536-18353-2-git-send-email-alexandre.belloni@free-electrons.com>
References: <1366299536-18353-1-git-send-email-alexandre.belloni@free-electrons.com>
 <1366299536-18353-2-git-send-email-alexandre.belloni@free-electrons.com>
Message-ID: <5172C724.4070605@metafoo.de>

Hi,

Some comments on top of what Jonathan said.

On 04/18/2013 05:38 PM, Alexandre Belloni wrote:
[...]
> diff --git a/drivers/iio/adc/nau7802.c b/drivers/iio/adc/nau7802.c
> new file mode 100644
> index 0000000..0148fd8
> --- /dev/null
> +++ b/drivers/iio/adc/nau7802.c
> @@ -0,0 +1,644 @@
[...]

> +static int nau7802_read_raw(struct iio_dev *idev,
> +			    struct iio_chan_spec const *chan,
> +			    int *val, int *val2, long mask)
> +{
> +	struct nau7802_state *st = iio_priv(idev);
> +	u8 data;
> +	int ret;
> +
> +	switch (mask) {
> +
[...]
> +	case IIO_CHAN_INFO_SCALE:
> +		ret = nau7802_i2c_read(st, NAU7802_REG_CTRL1, &data);
> +		if (ret < 0)
> +			return ret;
> +
> +		*val = 0;
> +		*val2 = (((u64)st->vref_mv) * 1000000000ULL) >>
> +			(chan->scan_type.realbits +
> +			 (data & NAU7802_CTRL1_GAINS_BITS));

If you use IIO_VAL_FRACTIONAL_LOG2 this becomes much more readable.

		*val = st->vref_mv;
		*val2 = chan->scan_type.realbits +
				(data & NAU7802_CTRL1_GAINS_BITS);


> +		return IIO_VAL_INT_PLUS_MICRO;
> +	default:
> +		break;
> +	}
> +	return -EINVAL;
> +}
[...]

> +static int nau7802_probe(struct i2c_client *client,
> +			const struct i2c_device_id *id)
> +{
> +	struct iio_dev *idev;
> +	struct nau7802_state *st;
> +	struct device_node *np = client->dev.of_node;
> +	int ret;
> +	u8 data;
> +	u32 tmp;
> +
> +	if (!client->dev.of_node) {
> +		dev_err(&client->dev, "No device tree node available.\n");
> +		return -EINVAL;
> +	}
> +
> +	/*
> +	 * If we have some interrupts declared, use them, if not, fall back
> +	 * on polling.
> +	 */
> +	if (of_find_property(np, "interrupts", NULL)) {
> +		if (client->irq <= 0) {
> +			client->irq = irq_of_parse_and_map(np, 0);
> +			if (client->irq <= 0)
> +				return -EPROBE_DEFER;
> +		}
> +	} else
> +		client->irq = 0;

This looks like something that could go into the of_i2c.c code.

> +
> +	idev = iio_device_alloc(sizeof(struct nau7802_state));
> +	if (idev == NULL)
> +		return -ENOMEM;
> +
> +	st = iio_priv(idev);
> +
> +	i2c_set_clientdata(client, idev);
> +
> +	idev->dev.parent = &client->dev;
> +	idev->name = dev_name(&client->dev);
> +	idev->modes = INDIO_DIRECT_MODE;
> +	idev->info = &nau7802_info;
> +
> +	st->client = client;
> +
> +	/* Reset the device */
> +	nau7802_i2c_write(st, NAU7802_REG_PUCTRL, NAU7802_PUCTRL_RR_BIT);
> +
> +	/* Enter normal operation mode */
> +	nau7802_i2c_write(st, NAU7802_REG_PUCTRL, NAU7802_PUCTRL_PUD_BIT);
> +
> +	/*
> +	 * After about 200 usecs, the device should be ready and then
> +	 * the Power Up bit will be set to 1. If not, wait for it.
> +	 */
> +	do {
> +		udelay(200);
> +		ret = nau7802_i2c_read(st, NAU7802_REG_PUCTRL, &data);
> +		if (ret)
> +			return -ENODEV;
> +	} while (!(data & NAU7802_PUCTRL_PUR_BIT));
> +
> +	of_property_read_u32(np, "nuvoton,vldo", &tmp);
> +	st->vref_mv = tmp;

We've standardized on using the regulator framework for providing voltages.
You should use it here as well.

> +
> +	data = NAU7802_PUCTRL_PUD_BIT | NAU7802_PUCTRL_PUA_BIT |
> +		NAU7802_PUCTRL_CS_BIT;
> +	if (tmp >= 2400)
> +		data |= NAU7802_PUCTRL_AVDDS_BIT;
> +
> +	nau7802_i2c_write(st, NAU7802_REG_PUCTRL, data);
> +	nau7802_i2c_write(st, NAU7802_REG_ADC_CTRL, 0x30);
> +
> +	if (tmp >= 2400) {
> +		data = NAU7802_CTRL1_VLDO((4500 - tmp) / 300);
> +		nau7802_i2c_write(st, NAU7802_REG_CTRL1, data);
> +	}
> +
> +	st->min_conversions = 6;
> +
> +	/*
> +	 * The ADC fires continuously and we can't do anything about
> +	 * it. So we need to have the IRQ disabled by default, and we
> +	 * will enable them back when we will need them..
> +	 */
> +	if (client->irq) {
> +		irq_set_status_flags(client->irq, IRQ_NOAUTOEN);

No driver should be messing with a IRQs flags. Basically if you need irq.h
for your device driver its probably wrong. The proper solution is to
introduce a IRQF_NOAUTOEN.

> +		ret = request_threaded_irq(client->irq,
> +				NULL,
> +				nau7802_eoc_trigger,
> +				IRQF_TRIGGER_HIGH | IRQF_ONESHOT,
> +				client->dev.driver->name,
> +				idev);
> +		if (ret) {
> +			/*
> +			 * What may happen here is that our IRQ controller is
> +			 * not able to get level interrupt but this is required
> +			 * by this ADC as when going over 40 sample per second,
> +			 * the interrupt line may stay high between conversions.
> +			 * So, we continue no matter what but we switch to
> +			 * polling mode.
> +			 */
> +			dev_info(&client->dev,
> +				"Failed to allocate IRQ, using polling mode\n");
> +			client->irq = 0;
> +			/*
> +			 * We are polling, use the fastest sample rate by
> +			 * default
> +			 */
> +			st->sample_rate = 0x7;
> +			nau7802_i2c_write(st, NAU7802_REG_CTRL2,
> +					NAU7802_CTRL2_CRS(st->sample_rate));
> +		}
> +	}
> +
> +	/* Setup the ADC channels available on the board */
> +	ret = nau7802_channel_init(idev);
> +	if (ret < 0) {
> +		dev_err(&client->dev, "Couldn't initialize the channels.\n");
> +		goto error_channel_init;
> +	}
> +
> +	init_completion(&st->value_ok);
> +	mutex_init(&st->lock);
> +	mutex_init(&st->data_lock);
> +
> +	ret = iio_device_register(idev);
> +	if (ret < 0) {
> +		dev_err(&client->dev, "Couldn't register the device.\n");
> +		goto error_device_register;
> +	}
> +
> +	return 0;
> +
> +error_device_register:
> +	mutex_destroy(&st->lock);
> +error_channel_init:
> +	if (client->irq)
> +		free_irq(client->irq, idev);
> +	iio_device_free(idev);
> +	return ret;
> +}
[...]


From cdall at cs.columbia.edu  Sat Apr 20 12:59:20 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Sat, 20 Apr 2013 09:59:20 -0700
Subject: KVM/ARM in next
Message-ID: <CAEDV+gK-84M+6zx_z1z48sNi5UiaELdsbz983tE7GOS25SnymA@mail.gmail.com>

Hi Stephen,

I'm maintaining the KVM/ARM implementation, which was merged during
the 3.9 merge window.

I'd like for you to pull changes from my kvm-arm-next branch at
git://github.com/columbia/linux-kvm-arm.git into linux-next.

The merge procedure for this tree is typically through the kvm tree,
but occasionally through Russell King's ARM tree, if there are
substantial changes to generic ARM code in there.

In case of problems please notify me and Marc Zyngier <marc.zyngier at arm.com>

Thanks,
-Christoffer


From plagnioj at jcrosoft.com  Sat Apr 20 13:00:04 2013
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Sat, 20 Apr 2013 19:00:04 +0200
Subject: [PATCH 4/4] ARM: nomadik: register clocksource from device tree
In-Reply-To: <1366466983-16151-1-git-send-email-linus.walleij@linaro.org>
References: <1366466983-16151-1-git-send-email-linus.walleij@linaro.org>
Message-ID: <20130420170004.GH4998@game.jcrosoft.org>

On 16:09 Sat 20 Apr     , Linus Walleij wrote:
> This switches the Nomadik platform to also registering its
> clocksource from the device tree, removing unused support
> code as we go along.
> 
> Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
> ---
>  arch/arm/boot/dts/ste-nomadik-stn8815.dtsi | 11 ++++++++---
>  arch/arm/mach-nomadik/Kconfig              |  1 +
>  arch/arm/mach-nomadik/cpu-8815.c           |  6 +++---
>  drivers/clk/clk-nomadik.c                  | 15 ---------------
>  4 files changed, 12 insertions(+), 21 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/ste-nomadik-stn8815.dtsi b/arch/arm/boot/dts/ste-nomadik-stn8815.dtsi
> index f0df948..51a33e0 100644
> --- a/arch/arm/boot/dts/ste-nomadik-stn8815.dtsi
> +++ b/arch/arm/boot/dts/ste-nomadik-stn8815.dtsi
> @@ -21,18 +21,23 @@
>  		cache-level = <2>;
>  	};
>  
> -	mtu0 {
> +	mtu0: mtu at 101e2000 {
>  		/* Nomadik system timer */
> +		compatible = "st,nomadik-mtu";
>  		reg = <0x101e2000 0x1000>;
>  		interrupt-parent = <&vica>;
>  		interrupts = <4>;
> +		clocks = <&timclk>, <&pclk>;
> +		clock-names = "timclk", "apb_pclk";
>  	};
>  
> -	mtu1 {
> +	mtu1: mtu at 101e3000 {
>  		/* Secondary timer */
>  		reg = <0x101e3000 0x1000>;
>  		interrupt-parent = <&vica>;
>  		interrupts = <5>;
> +		clocks = <&timclk>, <&pclk>;
> +		clock-names = "timclk", "apb_pclk";
>  	};
>  
>  	gpio0: gpio at 101e4000 {
> @@ -101,7 +106,7 @@
>  			pclk: pclk at 0 {
>  				#clock-cells = <0>;
>  				compatible = "fixed-clock";
> -				clock-frequency = <2400000>;
> +				clock-frequency = <0>;
really 0?

IIRC it's 2.4Mhz
>  			};
>  			/*
>  			 * The 2.4 MHz TIMCLK reference clock is active at
> diff --git a/arch/arm/mach-nomadik/Kconfig b/arch/arm/mach-nomadik/Kconfig
> index 8c1ccd4..4eafec3 100644
> --- a/arch/arm/mach-nomadik/Kconfig
> +++ b/arch/arm/mach-nomadik/Kconfig
> @@ -6,6 +6,7 @@ config ARCH_NOMADIK
>  	select ARM_VIC
>  	select CLKSRC_NOMADIK_MTU
>  	select CLKSRC_NOMADIK_MTU_SCHED_CLOCK
> +	select CLKSRC_OF
>  	select COMMON_CLK
>  	select CPU_ARM926T
>  	select GENERIC_CLOCKEVENTS
> diff --git a/arch/arm/mach-nomadik/cpu-8815.c b/arch/arm/mach-nomadik/cpu-8815.c
> index 0e2c5e0..e73a71f7 100644
> --- a/arch/arm/mach-nomadik/cpu-8815.c
> +++ b/arch/arm/mach-nomadik/cpu-8815.c
> @@ -29,7 +29,7 @@
>  #include <linux/platform_data/clk-nomadik.h>
>  #include <linux/platform_data/pinctrl-nomadik.h>
>  #include <linux/pinctrl/machine.h>
> -#include <linux/platform_data/clocksource-nomadik-mtu.h>
> +#include <linux/clocksource.h>
>  #include <linux/of_irq.h>
>  #include <linux/of_gpio.h>
>  #include <linux/of_address.h>
> @@ -172,7 +172,7 @@ static void __init cpu8815_timer_init_of(void)
>  	/* We need this to be up now */
>  	nomadik_clk_init();
>  
> -	mtu = of_find_node_by_path("/mtu0");
> +	mtu = of_find_node_by_path("/mtu at 101e2000");
>  	if (!mtu)
>  		return;
>  	base = of_iomap(mtu, 0);
> @@ -188,7 +188,7 @@ static void __init cpu8815_timer_init_of(void)
>  	src_cr |= SRC_CR_INIT_VAL;
>  	writel(src_cr, base);
>  
> -	nmdk_timer_init(base, irq);
> +	clocksource_of_init();
>  }
>  
>  static struct fsmc_nand_timings cpu8815_nand_timings = {
> diff --git a/drivers/clk/clk-nomadik.c b/drivers/clk/clk-nomadik.c
> index 19f197c..4a1ab27 100644
> --- a/drivers/clk/clk-nomadik.c
> +++ b/drivers/clk/clk-nomadik.c
> @@ -17,20 +17,5 @@ static const __initconst struct of_device_id cpu8815_clk_match[] = {
>  
>  void __init nomadik_clk_init(void)
>  {
> -	struct clk *clk;
> -
> -	clk = clk_register_fixed_rate(NULL, "apb_pclk", NULL, CLK_IS_ROOT, 0);
> -	clk_register_clkdev(clk, "apb_pclk", NULL);
> -
> -	/*
> -	 * The 2.4 MHz TIMCLK reference clock is active at boot time, this is
> -	 * actually the MXTALCLK @19.2 MHz divided by 8. This clock is used
> -	 * by the timers and watchdog. See page 105 ff.
> -	 */
> -	clk = clk_register_fixed_rate(NULL, "TIMCLK", NULL, CLK_IS_ROOT,
> -				      2400000);
> -	clk_register_clkdev(clk, NULL, "mtu0");
> -	clk_register_clkdev(clk, NULL, "mtu1");
> -
>  	of_clk_init(cpu8815_clk_match);
>  }
> -- 
> 1.8.1.4
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From sergei.shtylyov at cogentembedded.com  Sat Apr 20 16:13:45 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Sun, 21 Apr 2013 00:13:45 +0400
Subject: [PATCH 0/5] OKI ML86V7667 driver and R8A7778/BOCK-W VIN support
Message-ID: <201304210013.46110.sergei.shtylyov@cogentembedded.com>

Hello.

   Here's the set of 4 patches against the Simon Horman's 'renesas.git' repo,
'renesas-next-20130419' tag and my recent yet unapplied patches. Here we
add the OKI ML86V7667 video decoder driver and the VIN platform code working on
the R8A7778/BOCK-W with ML86V7667. The driver patch also applies (with offsets)
to Mauro's 'media_tree.git'...

[1/5] V4L2: I2C: ML86V7667 video decoder driver
[2/5] sh-pfc: r8a7778: add VIN pin groups
[3/5] ARM: shmobile: r8a7778: add VIN support
[4/5] ARM: shmobile: BOCK-W: add VIN and ADV7180 support
[5/5] ARM: shmobile: BOCK-W: enable VIN and ADV7180 in defconfig

WBR, Sergei


From sergei.shtylyov at cogentembedded.com  Sat Apr 20 16:28:31 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Sun, 21 Apr 2013 00:28:31 +0400
Subject: [PATCH 3/5] ARM: shmobile: r8a7778: add VIN support
In-Reply-To: <201304210013.46110.sergei.shtylyov@cogentembedded.com>
References: <201304210013.46110.sergei.shtylyov@cogentembedded.com>
Message-ID: <201304210028.32447.sergei.shtylyov@cogentembedded.com>

From: Vladimir Barinov <vladimir.barinov at cogentembedded.com>

Add VIN clocks and platform devices on R8A7778 SoC; add function to register
the VIN platform devices.

Signed-off-by: Vladimir Barinov <vladimir.barinov at cogentembedded.com>
[Sergei: added 'id' parameter check to r8a7779_add_vin_device(), used '*pdata'
in *sizeof* operator there, renamed some variables, marked 'vin[01]_info' as
'__initdata'.]
Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

---
 arch/arm/mach-shmobile/clock-r8a7778.c        |    5 +++
 arch/arm/mach-shmobile/include/mach/r8a7778.h |    3 ++
 arch/arm/mach-shmobile/setup-r8a7778.c        |   33 ++++++++++++++++++++++++++
 3 files changed, 41 insertions(+)

Index: renesas/arch/arm/mach-shmobile/clock-r8a7778.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/clock-r8a7778.c
+++ renesas/arch/arm/mach-shmobile/clock-r8a7778.c
@@ -106,6 +106,7 @@ static struct clk *main_clks[] = {
 enum {
 	MSTP323, MSTP322, MSTP321,
 	MSTP114,
+	MSTP110, MSTP109,
 	MSTP100,
 	MSTP030, MSTP029,
 	MSTP028, MSTP027, MSTP026, MSTP025, MSTP024, MSTP023, MSTP022, MSTP021,
@@ -117,6 +118,8 @@ static struct clk mstp_clks[MSTP_NR] = {
 	[MSTP322] = SH_CLK_MSTP32(&p_clk, MSTPCR3, 22, 0), /* SDHI1 */
 	[MSTP321] = SH_CLK_MSTP32(&p_clk, MSTPCR3, 21, 0), /* SDHI2 */
 	[MSTP114] = SH_CLK_MSTP32(&p_clk, MSTPCR1, 14, 0), /* Ether */
+	[MSTP110] = SH_CLK_MSTP32(&s_clk, MSTPCR1, 10, 0), /* VIN0 */
+	[MSTP109] = SH_CLK_MSTP32(&s_clk, MSTPCR1,  9, 0), /* VIN1 */
 	[MSTP100] = SH_CLK_MSTP32(&p_clk, MSTPCR1,  0, 0), /* USB0/1 */
 	[MSTP030] = SH_CLK_MSTP32(&p_clk, MSTPCR0, 30, 0), /* I2C0 */
 	[MSTP029] = SH_CLK_MSTP32(&p_clk, MSTPCR0, 29, 0), /* I2C1 */
@@ -140,6 +143,8 @@ static struct clk_lookup lookups[] = {
 	CLKDEV_DEV_ID("sh_mobile_sdhi.1", &mstp_clks[MSTP322]), /* SDHI1 */
 	CLKDEV_DEV_ID("sh_mobile_sdhi.2", &mstp_clks[MSTP321]), /* SDHI2 */
 	CLKDEV_DEV_ID("sh-eth",	&mstp_clks[MSTP114]), /* Ether */
+	CLKDEV_DEV_ID("rcar_vin.0", &mstp_clks[MSTP110]), /* VIN0 */
+	CLKDEV_DEV_ID("rcar_vin.1", &mstp_clks[MSTP109]), /* VIN1 */
 	CLKDEV_DEV_ID("ehci-platform", &mstp_clks[MSTP100]), /* USB EHCI port0/1 */
 	CLKDEV_DEV_ID("ohci-platform", &mstp_clks[MSTP100]), /* USB OHCI port0/1 */
 	CLKDEV_DEV_ID("i2c-rcar.0", &mstp_clks[MSTP030]), /* I2C0 */
Index: renesas/arch/arm/mach-shmobile/include/mach/r8a7778.h
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/include/mach/r8a7778.h
+++ renesas/arch/arm/mach-shmobile/include/mach/r8a7778.h
@@ -21,11 +21,14 @@
 #include <linux/mmc/sh_mobile_sdhi.h>
 #include <linux/sh_eth.h>
 #include <linux/usb/rcar-phy.h>
+#include <linux/platform_data/camera-rcar.h>
 
 extern void r8a7778_add_standard_devices(void);
 extern void r8a7778_add_standard_devices_dt(void);
 extern void r8a7778_add_ether_device(struct sh_eth_plat_data *pdata);
 extern void r8a7778_add_usb_phy_device(struct rcar_phy_platform_data *pdata);
+extern void r8a7778_add_vin_device(int id,
+				   struct rcar_vin_platform_data *pdata);
 extern void r8a7778_init_late(void);
 extern void r8a7778_init_delay(void);
 extern void r8a7778_init_irq(void);
Index: renesas/arch/arm/mach-shmobile/setup-r8a7778.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/setup-r8a7778.c
+++ renesas/arch/arm/mach-shmobile/setup-r8a7778.c
@@ -265,6 +265,39 @@ void __init r8a7778_sdhi_init(int id,
 		info, sizeof(*info));
 }
 
+/* VIN */
+#define R8A7778_VIN(idx)						\
+static struct resource vin##idx##_resources[] = {			\
+	DEFINE_RES_MEM(0xffc50000 + 0x1000 * (idx), 0x1000),		\
+	DEFINE_RES_IRQ(gic_iid(0x5a)),					\
+};									\
+									\
+static struct platform_device_info vin##idx##_info __initdata = {	\
+	.parent		= &platform_bus,				\
+	.name		= "rcar_vin",					\
+	.id		= idx,						\
+	.res		= vin##idx##_resources,				\
+	.num_res	= ARRAY_SIZE(vin##idx##_resources),		\
+	.dma_mask	= DMA_BIT_MASK(32),				\
+}
+
+R8A7778_VIN(0);
+R8A7778_VIN(1);
+
+static struct platform_device_info *vin_info_table[] __initdata = {
+	&vin0_info,
+	&vin1_info,
+};
+
+void __init r8a7778_add_vin_device(int id, struct rcar_vin_platform_data *pdata)
+{
+	BUG_ON(id < 0 || id > 1);
+
+	vin_info_table[id]->data = pdata;
+	vin_info_table[id]->size_data = sizeof(*pdata);
+	platform_device_register_full(vin_info_table[id]);
+}
+
 void __init r8a7778_add_standard_devices(void)
 {
 	int i;


From sergei.shtylyov at cogentembedded.com  Sat Apr 20 16:36:01 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Sun, 21 Apr 2013 00:36:01 +0400
Subject: [PATCH 4/5] ARM: shmobile: BOCK-W: add VIN and ML86V7667 support
In-Reply-To: <201304210013.46110.sergei.shtylyov@cogentembedded.com>
References: <201304210013.46110.sergei.shtylyov@cogentembedded.com>
Message-ID: <201304210036.02003.sergei.shtylyov@cogentembedded.com>

From: Vladimir Barinov <vladimir.barinov at cogentembedded.com>

Add ML86V7667 platform devices on BOCK-W board, configure VIN0/1 pins, and
register VIN0/1 devices with the ML86V7667 specific platform data.

Signed-off-by: Vladimir Barinov <vladimir.barinov at cogentembedded.com>
[Sergei: some macro/comment cleanup; updated the copyrights.]
Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

---
 arch/arm/mach-shmobile/board-bockw.c |   40 +++++++++++++++++++++++++++++++++++
 1 file changed, 40 insertions(+)

Index: renesas/arch/arm/mach-shmobile/board-bockw.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/board-bockw.c
+++ renesas/arch/arm/mach-shmobile/board-bockw.c
@@ -3,6 +3,7 @@
  *
  * Copyright (C) 2013  Renesas Solutions Corp.
  * Copyright (C) 2013  Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
+ * Copyright (C) 2013  Cogent Embedded, Inc.
  *
  * 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
@@ -23,6 +24,8 @@
 #include <linux/regulator/fixed.h>
 #include <linux/regulator/machine.h>
 #include <linux/smsc911x.h>
+#include <linux/pinctrl/machine.h>
+#include <media/soc_camera.h>
 #include <mach/common.h>
 #include <mach/irqs.h>
 #include <mach/r8a7778.h>
@@ -56,12 +59,41 @@ static struct resource smsc911x_resource
 
 static struct rcar_phy_platform_data usb_phy_platform_data;
 
+static struct rcar_vin_platform_data vin_platform_data = {
+	.flags	= RCAR_VIN_BT656,
+};
+
+/* In the default configuration both decoders reside on I2C bus 0 */
+#define BOCKW_CAMERA(idx)						\
+static struct i2c_board_info camera##idx##_info = {			\
+	I2C_BOARD_INFO("ml86v7667", 0x41 + 2 * (idx)),			\
+};									\
+									\
+static struct soc_camera_link iclink##idx##_ml86v7667 = {		\
+	.bus_id		= idx,						\
+	.i2c_adapter_id	= 0,						\
+	.board_info	= &camera##idx##_info,				\
+};
+
+BOCKW_CAMERA(0);
+BOCKW_CAMERA(1);
+
 static const struct pinctrl_map bockw_pinctrl_map[] = {
 	/* SCIF0 */
 	PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.0", "pfc-r8a7778",
 				  "scif0_data_a", "scif0"),
 	PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.0", "pfc-r8a7778",
 				  "scif0_ctrl", "scif0"),
+	/* VIN0 */
+	PIN_MAP_MUX_GROUP_DEFAULT("rcar_vin.0", "pfc-r8a7778",
+				  "vin0_clk", "vin0"),
+	PIN_MAP_MUX_GROUP_DEFAULT("rcar_vin.0", "pfc-r8a7778",
+				  "vin0_data8", "vin0"),
+	/* VIN1 */
+	PIN_MAP_MUX_GROUP_DEFAULT("rcar_vin.1", "pfc-r8a7778",
+				  "vin1_clk", "vin1"),
+	PIN_MAP_MUX_GROUP_DEFAULT("rcar_vin.1", "pfc-r8a7778",
+				  "vin1_data8", "vin1"),
 };
 
 #define FPGA	0x18200000
@@ -74,6 +106,14 @@ static void __init bockw_init(void)
 	r8a7778_init_irq_extpin(1);
 	r8a7778_add_standard_devices();
 	r8a7778_add_usb_phy_device(&usb_phy_platform_data);
+	r8a7778_add_vin_device(0, &vin_platform_data);
+	r8a7778_add_vin_device(1, &vin_platform_data);
+	platform_device_register_data(&platform_bus, "soc-camera-pdrv", 0,
+				      &iclink0_ml86v7667,
+				      sizeof(iclink0_ml86v7667));
+	platform_device_register_data(&platform_bus, "soc-camera-pdrv", 1,
+				      &iclink1_ml86v7667,
+				      sizeof(iclink1_ml86v7667));
 
 	pinctrl_register_mappings(bockw_pinctrl_map,
 				  ARRAY_SIZE(bockw_pinctrl_map));


From sergei.shtylyov at cogentembedded.com  Sat Apr 20 16:38:43 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Sun, 21 Apr 2013 00:38:43 +0400
Subject: [PATCH 5/5] ARM: shmobile: BOCK-W: enable VIN and ML86V7667 in
 defconfig
In-Reply-To: <201304210013.46110.sergei.shtylyov@cogentembedded.com>
References: <201304210013.46110.sergei.shtylyov@cogentembedded.com>
Message-ID: <201304210038.43857.sergei.shtylyov@cogentembedded.com>

From: Vladimir Barinov <vladimir.barinov at cogentembedded.com>

Add the VIN and ML86V7667 drivers to 'bockw_defconfig'.

Signed-off-by: Vladimir Barinov <vladimir.barinov at cogentembedded.com>
Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

---
 arch/arm/configs/bockw_defconfig |    7 +++++++
 1 file changed, 7 insertions(+)

Index: renesas/arch/arm/configs/bockw_defconfig
===================================================================
--- renesas.orig/arch/arm/configs/bockw_defconfig
+++ renesas/arch/arm/configs/bockw_defconfig
@@ -76,6 +76,13 @@ CONFIG_SERIAL_SH_SCI_CONSOLE=y
 # CONFIG_HWMON is not set
 CONFIG_I2C=y
 CONFIG_I2C_RCAR=y
+CONFIG_MEDIA_SUPPORT=y
+CONFIG_MEDIA_CAMERA_SUPPORT=y
+CONFIG_V4L_PLATFORM_DRIVERS=y
+CONFIG_SOC_CAMERA=y
+CONFIG_VIDEO_RCAR_VIN=y
+# CONFIG_MEDIA_SUBDRV_AUTOSELECT is not set
+CONFIG_VIDEO_ML86V7667=y
 CONFIG_USB=y
 CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
 CONFIG_USB_EHCI_HCD=y


From sergei.shtylyov at cogentembedded.com  Sat Apr 20 16:43:24 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Sun, 21 Apr 2013 00:43:24 +0400
Subject: [PATCH 0/5] OKI ML86V7667 driver and R8A7778/BOCK-W VIN support
In-Reply-To: <201304210013.46110.sergei.shtylyov@cogentembedded.com>
References: <201304210013.46110.sergei.shtylyov@cogentembedded.com>
Message-ID: <5172FDEC.3070200@cogentembedded.com>

Hello.

On 04/21/2013 12:13 AM, Sergei Shtylyov wrote:

>     Here's the set of 4 patches against the Simon Horman's 'renesas.git' repo,
> 'renesas-next-20130419' tag and my recent yet unapplied patches. Here we
> add the OKI ML86V7667 video decoder driver and the VIN platform code working on
> the R8A7778/BOCK-W with ML86V7667. The driver patch also applies (with offsets)
> to Mauro's 'media_tree.git'...
>
> [1/5] V4L2: I2C: ML86V7667 video decoder driver
> [2/5] sh-pfc: r8a7778: add VIN pin groups
> [3/5] ARM: shmobile: r8a7778: add VIN support
> [4/5] ARM: shmobile: BOCK-W: add VIN and ADV7180 support
> [5/5] ARM: shmobile: BOCK-W: enable VIN and ADV7180 in defconfig

     s/ADV7180/ML86V7667/. Sorry, used the old cover letter as a template
and forgot to fix the decoder name.

WBR, Sergei



From arnd at arndb.de  Sat Apr 20 18:01:59 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Sun, 21 Apr 2013 00:01:59 +0200
Subject: [PATCH] clocksource: add samsung pwm timer driver
Message-ID: <201304210002.00125.arnd@arndb.de>

From: Tomasz Figa <t.figa at samsung.com>

This adds a new clocksource driver for the PWM timer that is
present in most Samsung SoCs, based on the existing driver in
arch/arm/plat-samsung/samsung-time.c and many changes implemented by
Tomasz Figa.

Originally, the conversion of all Samsung machines to the new driver was
planned for 3.10, but that work ended up being too late and too invasive
just before the merge window.

Unfortunately, other changes in the Exynos platform resulted in some
Exynos4 setups, particularly the Universal C210 board to be broken. In
order to fix that with minimum risk, so we now leave the existing pwm
clocksource driver in place for all older platforms and use the new
driver only for device tree enabled boards. This way, we can get the
broken machines running again using DT descriptions.

All clocksource changes were implemented by Tomasz, while the DT
registration was rewritten by Arnd.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Cc: Tomasz Figa <t.figa at samsung.com>
Cc: Kyungmin Park <kyungmin.park at samsung.com>
Cc: Kukjin Kim <kgene.kim at samsung.com>
Cc: Ben Dooks <ben-linux at fluff.org>
Cc: John Stultz <john.stultz at linaro.org>
Cc: Thomas Gleixner <tglx at linutronix.de>
---
This is my final attempt to fix the Exynos4 regressions we have, since
Tomasz put a lot of work into getting this running, and I gave him a
hard time about some of the earlier patches.

Tomasz, can you have a look at this to see if it would actually help?
I have removed all the non-DT registration from your code, as well
as the interface to the pwm subsystem, since I assume the existing
code will work for all users we care about.

diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index 73fcddb..5b8ba91 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -75,3 +75,13 @@ config CLKSRC_EXYNOS_MCT
 	def_bool y if ARCH_EXYNOS
 	help
 	  Support for Multi Core Timer controller on Exynos SoCs.
+
+config CLKSRC_SAMSUNG_PWM
+	def_bool ARCH_EXYNOS4
+	depends on OF
+	select CLKSRC_MMIO
+	help
+	  This is a new clocksource driver for the PWM timer found in
+	  Samsung S3C, S5P and Exynos SoCs, replacing an earlier driver
+	  for all devicetree enabled platforms. This driver will be
+	  needed only on systems that do not have the Exynos MCT available.
diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index cd1f09c..2289f0c 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -21,6 +21,7 @@ obj-$(CONFIG_ARCH_TEGRA)	+= tegra20_timer.o
 obj-$(CONFIG_VT8500_TIMER)	+= vt8500_timer.o
 obj-$(CONFIG_CADENCE_TTC_TIMER)	+= cadence_ttc_timer.o
 obj-$(CONFIG_CLKSRC_EXYNOS_MCT)	+= exynos_mct.o
+obj-$(CONFIG_CLKSRC_SAMSUNG_PWM)	+= samsung_pwm_timer.o
 
 obj-$(CONFIG_ARM_ARCH_TIMER)		+= arm_arch_timer.o
 obj-$(CONFIG_CLKSRC_METAG_GENERIC)	+= metag_generic.o
diff --git a/drivers/clocksource/samsung_pwm_timer.c b/drivers/clocksource/samsung_pwm_timer.c
new file mode 100644
index 0000000..1752457
--- /dev/null
+++ b/drivers/clocksource/samsung_pwm_timer.c
@@ -0,0 +1,477 @@
+/*
+ * Copyright (c) 2011 Samsung Electronics Co., Ltd.
+ *		http://www.samsung.com/
+ *
+ * samsung - Common hr-timer support (s3c and s5p)
+ *
+ * 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/interrupt.h>
+#include <linux/irq.h>
+#include <linux/err.h>
+#include <linux/clk.h>
+#include <linux/clockchips.h>
+#include <linux/list.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+
+#include <clocksource/samsung_pwm.h>
+
+#include <asm/sched_clock.h>
+
+/*
+ * Clocksource driver
+ */
+
+#define REG_TCFG0			0x00
+#define REG_TCFG1			0x04
+#define REG_TCON			0x08
+#define REG_TINT_CSTAT			0x44
+
+#define REG_TCNTB(chan)			(0x0c + 12 * (chan))
+#define REG_TCMPB(chan)			(0x10 + 12 * (chan))
+
+#define TCFG0_PRESCALER_MASK		0xff
+#define TCFG0_PRESCALER1_SHIFT		8
+
+#define TCFG1_SHIFT(x)	  		((x) * 4)
+#define TCFG1_MUX_MASK	  		0xf
+
+#define TCON_START(chan)		(1 << (4 * (chan) + 0))
+#define TCON_MANUALUPDATE(chan)		(1 << (4 * (chan) + 1))
+#define TCON_INVERT(chan)		(1 << (4 * (chan) + 2))
+#define TCON_AUTORELOAD(chan)		(1 << (4 * (chan) + 3))
+
+struct samsung_timer_source {
+	unsigned int event_id;
+	unsigned int source_id;
+	unsigned int tcnt_max;
+	unsigned int tscaler_div;
+	unsigned int tdiv;
+};
+
+static struct samsung_pwm *pwm;
+static struct clk *timerclk;
+static struct samsung_timer_source timer_source;
+static unsigned long clock_count_per_tick;
+
+static void samsung_timer_set_prescale(struct samsung_pwm *pwm,
+					unsigned int channel, u16 prescale)
+{
+	unsigned long flags;
+	u8 shift = 0;
+	u32 reg;
+
+	if (channel >= 2)
+		shift = TCFG0_PRESCALER1_SHIFT;
+
+	spin_lock_irqsave(&pwm->slock, flags);
+
+	reg = readl(pwm->base + REG_TCFG0);
+	reg &= ~(TCFG0_PRESCALER_MASK << shift);
+	reg |= (prescale - 1) << shift;
+	writel(reg, pwm->base + REG_TCFG0);
+
+	spin_unlock_irqrestore(&pwm->slock, flags);
+}
+
+static void samsung_timer_set_divisor(struct samsung_pwm *pwm,
+					unsigned int channel, u8 divisor)
+{
+	u8 shift = TCFG1_SHIFT(channel);
+	unsigned long flags;
+	u32 reg;
+	u8 bits;
+
+	bits = (fls(divisor) - 1) - pwm->variant.div_base;
+
+	spin_lock_irqsave(&pwm->slock, flags);
+
+	reg = readl(pwm->base + REG_TCFG1);
+	reg &= ~(TCFG1_MUX_MASK << shift);
+	reg |= bits << shift;
+	writel(reg, pwm->base + REG_TCFG1);
+
+	spin_unlock_irqrestore(&pwm->slock, flags);
+}
+
+static void samsung_time_stop(unsigned int channel)
+{
+	unsigned long tcon;
+	unsigned long flags;
+
+	if (channel > 0)
+		++channel;
+
+	spin_lock_irqsave(&pwm->slock, flags);
+
+	tcon = __raw_readl(pwm->base + REG_TCON);
+	tcon &= ~TCON_START(channel);
+	__raw_writel(tcon, pwm->base + REG_TCON);
+
+	spin_unlock_irqrestore(&pwm->slock, flags);
+}
+
+static void samsung_time_setup(unsigned int channel, unsigned long tcnt)
+{
+	unsigned long tcon;
+	unsigned long flags;
+	unsigned int tcon_chan = channel;
+
+	if (tcon_chan > 0)
+		++tcon_chan;
+
+	spin_lock_irqsave(&pwm->slock, flags);
+
+	tcon = __raw_readl(pwm->base + REG_TCON);
+
+	tcnt--;
+
+	tcon &= ~(TCON_START(tcon_chan) | TCON_AUTORELOAD(tcon_chan));
+	tcon |= TCON_MANUALUPDATE(tcon_chan);
+
+	__raw_writel(tcnt, pwm->base + REG_TCNTB(channel));
+	__raw_writel(tcnt, pwm->base + REG_TCMPB(channel));
+	__raw_writel(tcon, pwm->base + REG_TCON);
+
+	spin_unlock_irqrestore(&pwm->slock, flags);
+}
+
+static void samsung_time_start(unsigned int channel, bool periodic)
+{
+	unsigned long tcon;
+	unsigned long flags;
+
+	if (channel > 0)
+		++channel;
+
+	spin_lock_irqsave(&pwm->slock, flags);
+
+	tcon = __raw_readl(pwm->base + REG_TCON);
+
+	tcon &= ~TCON_MANUALUPDATE(channel);
+	tcon |= TCON_START(channel);
+
+	if (periodic)
+		tcon |= TCON_AUTORELOAD(channel);
+	else
+		tcon &= ~TCON_AUTORELOAD(channel);
+
+	__raw_writel(tcon, pwm->base + REG_TCON);
+
+	spin_unlock_irqrestore(&pwm->slock, flags);
+}
+
+static int samsung_set_next_event(unsigned long cycles,
+				struct clock_event_device *evt)
+{
+	samsung_time_setup(timer_source.event_id, cycles);
+	samsung_time_start(timer_source.event_id, false);
+
+	return 0;
+}
+
+static void samsung_timer_resume(void)
+{
+	/* event timer restart */
+	samsung_time_setup(timer_source.event_id, clock_count_per_tick);
+	samsung_time_start(timer_source.event_id, true);
+
+	/* source timer restart */
+	samsung_time_setup(timer_source.source_id, timer_source.tcnt_max);
+	samsung_time_start(timer_source.source_id, true);
+}
+
+static void samsung_set_mode(enum clock_event_mode mode,
+				struct clock_event_device *evt)
+{
+	samsung_time_stop(timer_source.event_id);
+
+	switch (mode) {
+	case CLOCK_EVT_MODE_PERIODIC:
+		samsung_time_setup(timer_source.event_id, clock_count_per_tick);
+		samsung_time_start(timer_source.event_id, true);
+		break;
+
+	case CLOCK_EVT_MODE_ONESHOT:
+		break;
+
+	case CLOCK_EVT_MODE_UNUSED:
+	case CLOCK_EVT_MODE_SHUTDOWN:
+		break;
+
+	case CLOCK_EVT_MODE_RESUME:
+		samsung_timer_resume();
+		break;
+	}
+}
+
+static struct clock_event_device time_event_device = {
+	.name		= "samsung_event_timer",
+	.features	= CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT,
+	.rating		= 200,
+	.set_next_event	= samsung_set_next_event,
+	.set_mode	= samsung_set_mode,
+};
+
+static irqreturn_t samsung_clock_event_isr(int irq, void *dev_id)
+{
+	struct clock_event_device *evt = dev_id;
+
+	if (pwm->variant.has_tint_cstat) {
+		u32 mask = (1 << timer_source.event_id);
+		writel(mask | (mask << 5), pwm->base + REG_TINT_CSTAT);
+	}
+
+	evt->event_handler(evt);
+
+	return IRQ_HANDLED;
+}
+
+static struct irqaction samsung_clock_event_irq = {
+	.name		= "samsung_time_irq",
+	.flags		= IRQF_DISABLED | IRQF_TIMER | IRQF_IRQPOLL,
+	.handler	= samsung_clock_event_isr,
+	.dev_id		= &time_event_device,
+};
+
+static void __init samsung_clockevent_init(void)
+{
+	unsigned long pclk;
+	unsigned long clock_rate;
+	unsigned int irq_number;
+
+	pclk = clk_get_rate(timerclk);
+
+	samsung_timer_set_prescale(pwm, timer_source.event_id,
+						timer_source.tscaler_div);
+	samsung_timer_set_divisor(pwm, timer_source.event_id,
+						timer_source.tdiv);
+
+	clock_rate = pclk / (timer_source.tscaler_div * timer_source.tdiv);
+	clock_count_per_tick = clock_rate / HZ;
+
+	time_event_device.cpumask = cpumask_of(0);
+	clockevents_config_and_register(&time_event_device, clock_rate, 1, -1);
+
+	irq_number = pwm->irq[timer_source.event_id];
+	setup_irq(irq_number, &samsung_clock_event_irq);
+
+	if (pwm->variant.has_tint_cstat) {
+		u32 mask = (1 << timer_source.event_id);
+		writel(mask | (mask << 5), pwm->base + REG_TINT_CSTAT);
+	}
+}
+
+static void __iomem *samsung_timer_reg(void)
+{
+	switch (timer_source.source_id) {
+	case 0:
+	case 1:
+	case 2:
+	case 3:
+		return pwm->base + timer_source.source_id * 0x0c + 0x14;
+
+	case 4:
+		return pwm->base + 0x40;
+
+	default:
+		BUG();
+	}
+}
+
+/*
+ * Override the global weak sched_clock symbol with this
+ * local implementation which uses the clocksource to get some
+ * better resolution when scheduling the kernel. We accept that
+ * this wraps around for now, since it is just a relative time
+ * stamp. (Inspired by U300 implementation.)
+ */
+static u32 notrace samsung_read_sched_clock(void)
+{
+	void __iomem *reg = samsung_timer_reg();
+
+	if (!reg)
+		return 0;
+
+	return ~__raw_readl(reg);
+}
+
+static void __init samsung_clocksource_init(void)
+{
+	void __iomem *reg = samsung_timer_reg();
+	unsigned long pclk;
+	unsigned long clock_rate;
+	int ret;
+
+	pclk = clk_get_rate(timerclk);
+
+	samsung_timer_set_prescale(pwm, timer_source.source_id,
+						timer_source.tscaler_div);
+	samsung_timer_set_divisor(pwm, timer_source.source_id,
+						timer_source.tdiv);
+
+	clock_rate = pclk / (timer_source.tscaler_div * timer_source.tdiv);
+
+	samsung_time_setup(timer_source.source_id, timer_source.tcnt_max);
+	samsung_time_start(timer_source.source_id, true);
+
+	setup_sched_clock(samsung_read_sched_clock,
+						pwm->variant.bits, clock_rate);
+
+	ret = clocksource_mmio_init(reg, "samsung_clocksource_timer",
+					clock_rate, 250, pwm->variant.bits,
+					clocksource_mmio_readl_down);
+	if (ret)
+		panic("samsung_clocksource_timer: can't register clocksource\n");
+}
+
+static void __init samsung_timer_resources(void)
+{
+	timerclk = clk_get(NULL, "timers");
+	if (IS_ERR(timerclk))
+		panic("failed to get timers clock for timer");
+
+	clk_prepare_enable(timerclk);
+
+	timer_source.tcnt_max = (1UL << pwm->variant.bits) - 1;
+	if (pwm->variant.bits == 16) {
+		timer_source.tscaler_div = 25;
+		timer_source.tdiv = 2;
+	} else {
+		timer_source.tscaler_div = 2;
+		timer_source.tdiv = 1;
+	}
+}
+
+/*
+ * PWM master driver
+ */
+static void __init samsung_pwm_clocksource_init(void)
+{
+	u8 mask;
+	int channel;
+
+	if (!pwm)
+		panic("no pwm clocksource device found");
+
+	mask = ~pwm->variant.output_mask & ((1 << SAMSUNG_PWM_NUM) - 1);
+	channel = fls(mask) - 1;
+	if (channel < 0)
+		panic("failed to find PWM channel for clocksource");
+	timer_source.source_id = channel;
+
+	mask &= ~(1 << channel);
+	channel = fls(mask) - 1;
+	if (channel < 0)
+		panic("failed to find PWM channel for clock event");
+	timer_source.event_id = channel;
+
+	samsung_timer_resources();
+	samsung_clockevent_init();
+	samsung_clocksource_init();
+}
+
+static void __init samsung_pwm_alloc(struct device_node *np,
+				     const struct samsung_pwm_variant *variant)
+{
+	struct resource res;
+	struct property *prop;
+	const __be32 *cur;
+	u32 val;
+	int i;
+
+	pwm = kzalloc(sizeof(*pwm), GFP_KERNEL);
+	if (!pwm) {
+		pr_err("%s: could not allocate PWM device struct\n", __func__);
+		return;
+	}
+	memcpy(&pwm->variant, variant, sizeof(pwm->variant));
+	spin_lock_init(&pwm->slock);
+	for (i = 0; i < SAMSUNG_PWM_NUM; ++i)
+		pwm->irq[i] = irq_of_parse_and_map(np, i);
+
+	of_property_for_each_u32(np, "samsung,pwm-outputs", prop, cur, val) {
+		if (val >= SAMSUNG_PWM_NUM) {
+			pr_warning("%s: invalid channel index in samsung,pwm-outputs property\n",
+								__func__);
+			continue;
+		}
+		pwm->variant.output_mask |= 1 << val;
+	}
+
+	of_address_to_resource(np, 0, &res);
+	if (!request_mem_region(res.start,
+				resource_size(&res), "samsung-pwm")) {
+		pr_err("%s: failed to request IO mem region\n", __func__);
+		return;
+	}
+
+	pwm->base = ioremap(res.start, resource_size(&res));
+	if (!pwm->base) {
+		pr_err("%s: failed to map PWM registers\n", __func__);
+		release_mem_region(res.start, resource_size(&res));
+		return;
+	}
+
+	samsung_pwm_clocksource_init();
+}
+
+static const struct samsung_pwm_variant s3c24xx_variant = {
+	.bits		= 16,
+	.div_base	= 1,
+	.has_tint_cstat	= false,
+	.tclk_mask	= (1 << 4),
+};
+
+static void __init s3c2410_pwm_clocksource_init(struct device_node *np)
+{
+	samsung_pwm_alloc(np, &s3c24xx_variant);
+}
+CLOCKSOURCE_OF_DECLARE(s3c2410_pwm, "samsung,s3c2410-pwm", s3c2410_pwm_clocksource_init);
+
+static const struct samsung_pwm_variant s3c64xx_variant = {
+	.bits		= 32,
+	.div_base	= 0,
+	.has_tint_cstat	= true,
+	.tclk_mask	= (1 << 7) | (1 << 6) | (1 << 5),
+};
+
+static void __init s3c64xx_pwm_clocksource_init(struct device_node *np)
+{
+	samsung_pwm_alloc(np, &s3c64xx_variant);
+}
+CLOCKSOURCE_OF_DECLARE(s3c6400_pwm, "samsung,s3c6400-pwm", s3c64xx_pwm_clocksource_init);
+
+static const struct samsung_pwm_variant s5p64x0_variant = {
+	.bits		= 32,
+	.div_base	= 0,
+	.has_tint_cstat	= true,
+	.tclk_mask	= 0,
+};
+
+static void __init s5p64x0_pwm_clocksource_init(struct device_node *np)
+{
+	samsung_pwm_alloc(np, &s5p64x0_variant);
+}
+CLOCKSOURCE_OF_DECLARE(s5p6440_pwm, "samsung,s5p6440-pwm", s5p64x0_pwm_clocksource_init);
+
+static const struct samsung_pwm_variant s5p_variant = {
+	.bits		= 32,
+	.div_base	= 0,
+	.has_tint_cstat	= true,
+	.tclk_mask	= (1 << 5),
+};
+
+static void __init s5p_pwm_clocksource_init(struct device_node *np)
+{
+	samsung_pwm_alloc(np, &s5p_variant);
+}
+CLOCKSOURCE_OF_DECLARE(s5pc100_pwm, "samsung,s5pc100-pwm", s5p_pwm_clocksource_init);
diff --git a/include/clocksource/samsung_pwm.h b/include/clocksource/samsung_pwm.h
new file mode 100644
index 0000000..eff8668
--- /dev/null
+++ b/include/clocksource/samsung_pwm.h
@@ -0,0 +1,41 @@
+/*
+ * Copyright (C) 2013 Samsung Electronics Co., Ltd.
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
+ */
+#ifndef __CLOCKSOURCE_SAMSUNG_PWM_H
+#define __CLOCKSOURCE_SAMSUNG_PWM_H
+
+#include <linux/spinlock.h>
+
+#define SAMSUNG_PWM_NUM		5
+
+struct platform_device;
+struct device_node;
+
+struct samsung_pwm_variant {
+	u8 bits;
+	u8 div_base;
+	u8 tclk_mask;
+	u8 output_mask;
+	bool has_tint_cstat;
+};
+
+struct samsung_pwm {
+	struct samsung_pwm_variant variant;
+	spinlock_t slock;
+	void __iomem *base;
+	int irq[SAMSUNG_PWM_NUM];
+};
+
+#endif /* __CLOCKSOURCE_SAMSUNG_PWM_H */


From jason at lakedaemon.net  Sat Apr 20 18:33:43 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Sat, 20 Apr 2013 18:33:43 -0400
Subject: [PATCH v7 3/3] of/pci: mips: convert to common of_pci_range_parser
In-Reply-To: <5170F016.6050502@openwrt.org>
References: <1366107508-12672-1-git-send-email-Andrew.Murray@arm.com>
 <1366107508-12672-4-git-send-email-Andrew.Murray@arm.com>
 <CACRpkdbBaT1OKr5t8HW4+8y_wSDmGxmewAyVMekx8S-K9s3K8Q@mail.gmail.com>
 <20130418125910.GA17128@arm.com>
 <20130418130919.GI27197@titan.lakedaemon.net>
 <5170F016.6050502@openwrt.org>
Message-ID: <20130420223343.GB25724@titan.lakedaemon.net>

On Fri, Apr 19, 2013 at 09:19:50AM +0200, Gabor Juhos wrote:
> 2013.04.18. 15:09 keltez?ssel, Jason Cooper ?rta:
> > On Thu, Apr 18, 2013 at 01:59:10PM +0100, Andrew Murray wrote:
> >> On Wed, Apr 17, 2013 at 04:42:48PM +0100, Linus Walleij wrote:
> >>> On Tue, Apr 16, 2013 at 12:18 PM, Andrew Murray <Andrew.Murray at arm.com> wrote:
> >>>
> >>>> This patch converts the pci_load_of_ranges function to use the new common
> >>>> of_pci_range_parser.
> >>>>
> >>>> Signed-off-by: Andrew Murray <Andrew.Murray at arm.com>
> >>>> Signed-off-by: Liviu Dudau <Liviu.Dudau at arm.com>
> >>>> Reviewed-by: Rob Herring <rob.herring at calxeda.com>
> >>>
> >>> Tested-by: Linus Walleij <linus.walleij at linaro.org>
> >>
> >> Jason - you may not have seen this, but here (Linus Walleij) is another Tested-by
> >> to add to this patch in your tree (if you can).
> > 
> > Thanks, I saw it.  Unfortunately, the PR was already sent, and the branch
> > is now pulled into arm-soc.
> 
> Sorry I had no time earlier, but I have tested this now on MIPS. The patch
> causes build errors unfortunately. Given the fact that this has been merged
> already, I will send a fixup patch.

Olof has dropped this branch from arm-soc, plase post the build error
and fix here so that it can be included in this series.

thx,

Jason.


From jassisinghbrar at gmail.com  Sat Apr 20 22:40:59 2013
From: jassisinghbrar at gmail.com (Jassi Brar)
Date: Sun, 21 Apr 2013 08:10:59 +0530
Subject: [PATCHv3 00/14] drivers: mailbox: framework creation
In-Reply-To: <1363145021-14339-1-git-send-email-s-anna@ti.com>
References: <1363145021-14339-1-git-send-email-s-anna@ti.com>
Message-ID: <CABb+yY0RYkVeo2Sb4WsDJY0jf17488FEz0d2CB994eQaSOEsVg@mail.gmail.com>

Hi Suman,

  [Resending with mailing-list CCed this time. For some reason LKML
doesn't appear in reply-to despite this message being fwd'ed from
there]

On Wed, Mar 13, 2013 at 8:53 AM, Suman Anna <s-anna at ti.com> wrote:
> Hi,
> Please find the updated mailbox patch series for pulling into linux-next.
> The series is rebased on top of 3.9-rc2, and includes one new patch to
> rename an existing mailbox.h added as part of the highbank cpufreq
> support for 3.9 merge window [1].
>
I am to implement IPC protocol and client drivers on a platform that
has a master processor having control over critical h/w resources,
like clock and power management, to be used by the MPCore running
linux. And there are 2 such IPC controllers - one for communication
within the MPCore and another for between MPCore and the 'Master'.

I have a few concerns about this api as follows...

a) No documentation. Usually the header would have proper
documentation of data structures and info for users of both side of
the api.

b) The api is not scalable. The assumption of just one IPC controller
in the platform is hardcoded.

c) There seems to be no consistent design - mailbox_ops has 12
callback hooks. Some, save_ctx, restore_ctx, enable_irq, disable_irq
are exported for no apparent reason (legacy of a legacy - OMAP), while
other hooks are kept private to the api.
I believe OMAP had valid reasons to make IPC clients save/restore
context of the IPC controller, but I don't think that is the case in
general. I2C client drivers don't save/restore context of I2C
controller's, why should IPC's?  Similarly enable/disable_irq of the
controller seem too intrusive for a client driver.

mailbox_ops.mailbox_type_t makes no sense to me. At least not without
documentation, though I doubt any amount of documentation could help
it - mailbox.c doesn't even read the member. Btw, isn't every mailbox
a MBOX_SHARED_MEM_TYPE? A part of data passed via FIFO/REG could point
to location in shared memory that might have full command/payload for
the message. Or did I get the meaning of MBOX_SHARED_MEM_TYPE wrong in
the absence of documentation?

The api seems to worry too much about the low-level details of the IPC
controller (save/restore context, enable/disable_irq and ack_irq),
while it fails to provide a tight well-defined interface to client
drivers.

There are also some code issues, which might come as replies to
respective patches.

Regards,
-Jassi


From haojian.zhuang at linaro.org  Sun Apr 21 02:02:11 2013
From: haojian.zhuang at linaro.org (Haojian Zhuang)
Date: Sun, 21 Apr 2013 14:02:11 +0800
Subject: gpio-pxa initcall level change and machine init breakage
In-Reply-To: <5172B398.7060706@newsguy.com>
References: <5172B398.7060706@newsguy.com>
Message-ID: <CAD6h2NSRA9w7GZLQGgK-+TvEAsxwOHow5_26JyVUA6YQyj3OQg@mail.gmail.com>

On 20 April 2013 23:26, Mike Dunn <mikedunn at newsguy.com> wrote:
> Hi,
>
> After a few months of neglect, I rebased my palm treo 680 kernel with the latest
> from Linus' official tree, and now all the calls to gpio lib functions
> (gpio_request(), etc) made from the init_machine() method in struct machine_desc
> fail.  I tracked this back to commit 6c7e660a27da7494c670bfba21cfeba30457656c
> dated Jan 23 2013
>
>     gpio: pxa: set initcall level to module init
>
>     gpio & pinctrl driver are used together. The pinctrl driver is already
>     launched before gpio driver in Makefile. So set gpio driver to module
>     init level. Otherwise, the sequence will be inverted.
>
>     Signed-off-by: Haojian Zhuang <haojian.zhuang at linaro.org>
>     Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
>
> At the time, Haojian addressed a question about this patch regarding module
> dependencies, advising use of the deferred probe infrastructure.  But unless I'm
> mistaken, mine is an initcall level problem, not a dependency issue among driver
> probes.  Now that gpio-pxa initialization is at the device level (initcall6),
> calls to gpiolib are no longer possible from init_machine(), which remains at
> the initcall3 level.
>
> I feel like I must be missing something, because a lot of pxa boards call
> gpiolib from init machine(), so my breakage should not be an isolated case.
>
> If I'm not missing anything and the patch is necessary, it looks like one
> solution would be to move all the initializations that use gpiolib to the
> init_late method in struct machine_desc, which runs as initcall7.
>
> Grateful for any advice!
>
> Thanks,
> Mike

Actually gpio request should be handled in the driver, not machine platform
driver. For example, lcd init may request gpio. pxafb.c provides the callback
to handle it. We need to move code of requesting gpio into the callback.

Since this change breaks current platform, we have to revert it. We still need
a code cleanup in arch-pxa directory.

Linus,
Could you help to revert this commit? Or do I need to send a revert commit
to you?

Regards
Haojian


From juhosg at openwrt.org  Sun Apr 21 03:27:02 2013
From: juhosg at openwrt.org (Gabor Juhos)
Date: Sun, 21 Apr 2013 09:27:02 +0200
Subject: [PATCH v7 3/3] of/pci: mips: convert to common of_pci_range_parser
In-Reply-To: <20130420223343.GB25724@titan.lakedaemon.net>
References: <1366107508-12672-1-git-send-email-Andrew.Murray@arm.com>
 <1366107508-12672-4-git-send-email-Andrew.Murray@arm.com>
 <CACRpkdbBaT1OKr5t8HW4+8y_wSDmGxmewAyVMekx8S-K9s3K8Q@mail.gmail.com>
 <20130418125910.GA17128@arm.com>
 <20130418130919.GI27197@titan.lakedaemon.net> <5170F016.6050502@openwrt.org>
 <20130420223343.GB25724@titan.lakedaemon.net>
Message-ID: <517394C6.2060407@openwrt.org>

Hi Jason,

>> Sorry I had no time earlier, but I have tested this now on MIPS. The patch
>> causes build errors unfortunately. Given the fact that this has been merged
>> already, I will send a fixup patch.
> 
> Olof has dropped this branch from arm-soc, plase post the build error
> and fix here so that it can be included in this series.

I have posted the patch to Olof two days ago. It has been CC'd to you as well
but In case that it does not exists in your mailbox the patch can be found here:

https://patchwork.linux-mips.org/patch/5196/

However I can re-post the patch as a reply to this thread if you prefer that.

-Gabor


From mpa at pengutronix.de  Sun Apr 21 04:11:15 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Sun, 21 Apr 2013 10:11:15 +0200
Subject: [PATCH v4 2/2] video: imxfb: Add DT support
In-Reply-To: <20130418160614.GF4998@game.jcrosoft.org>
References: <1366290183-367-1-git-send-email-mpa@pengutronix.de>
 <1366290183-367-3-git-send-email-mpa@pengutronix.de>
 <20130418160614.GF4998@game.jcrosoft.org>
Message-ID: <20130421081115.GA31179@pengutronix.de>

On Thu, Apr 18, 2013 at 06:06:14PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 15:03 Thu 18 Apr     , Markus Pargmann wrote:
> > Add devicetree support for imx framebuffer driver. It uses the generic
> > display bindings and helper functions.
> > 
> > Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
> > Cc: Fabio Estevam <festevam at gmail.com>
> > Cc: Mark Rutland <mark.rutland at arm.com>
> > ---
> > 
> > Notes:
> >     Changes in v4:
> >     - Remove eukrea specific dmacr property.
> >     - Add optional dmacr property. If not present, the dmacr reset value is not
> >       changed.
> >     
> >     Changes in v3:
> >     - Fix returncodes of of_read_mode function and print error messages
> >     - Introduce a lower bound check for bits per pixel
> >     - Calculate correct bytes per pixel value before using it for the calculation of
> >     	memory size
> >     - Change DT property names
> >     
> >     Changes in v2:
> >     - Removed pwmr register property
> >     - Cleanup of devicetree binding documentation
> >     - Use default values for pwmr and lscr1
> > 
> >  .../devicetree/bindings/video/fsl,imx-fb.txt       |  51 ++++++
> >  drivers/video/imxfb.c                              | 194 +++++++++++++++++----
> >  2 files changed, 210 insertions(+), 35 deletions(-)
> >  create mode 100644 Documentation/devicetree/bindings/video/fsl,imx-fb.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/video/fsl,imx-fb.txt b/Documentation/devicetree/bindings/video/fsl,imx-fb.txt
> > new file mode 100644
> > index 0000000..aff16a4
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/video/fsl,imx-fb.txt
> > @@ -0,0 +1,51 @@
> > +Freescale imx21 Framebuffer
> > +
> > +This framebuffer driver supports devices imx1, imx21, imx25, and imx27.
> > +
> > +Required properties:
> > +- compatible : "fsl,<chip>-fb", chip should be imx1 or imx21
> > +- reg : Should contain 1 register ranges(address and length)
> > +- interrupts : One interrupt of the fb dev
> > +
> > +Required nodes:
> > +- display: Phandle to a display node as described in
> > +	Documentation/devicetree/bindings/video/display-timing.txt
> > +	Additional, the display node has to define properties:
> > +	- fsl,bpp: Bits per pixel
> > +	- fsl,pcr: LCDC PCR value
> > +
> > +Optional properties:
> > +- fsl,dmacr: DMA Control Register value. This is optional. By default, the
> > +	register is not modified as recommended by the datasheet.
> > +- fsl,lscr1: LCDC Sharp Configuration Register value.
> > +
> > +Example:
> > +
> > +	imxfb: fb at 10021000 {
> > +		compatible = "fsl,imx27-fb", "fsl,imx21-fb";
> you put both when in the doc you request one

Thanks, fixed.

> > +		interrupts = <61>;
> > +		reg = <0x10021000 0x1000>;
> > +		display = <&display0>;
> > +	};
> > +
> > +	...
> > +
> > +	display0: display0 {
> > +		model = "Primeview-PD050VL1";
> > +		native-mode = <&timing_disp0>;
> > +		fsl,bpp = <16>;		/* non-standard but required */
> there is a generic binding bit-per-pixel use a cross other IP

I can't find a generic binding for that. There are only 2 other drivers
using a "bpp" property, but they both use it within different contexts.
tilcdc panel uses it within a "panel-info" property and via,vt8500-fb
within modes. So I think it would be better to use a clear distinction
because there is no generic binding. That was also suggested in comments
on version 2 of this patch:
https://patchwork.kernel.org/patch/2220511/

Regards,

Markus

> > +		fsl,pcr = <0xf0c88080>;	/* non-standard but required */
> > +		display-timings {
> > +			timing_disp0: 640x480 {
> > +				hactive = <640>;
> > +				vactive = <480>;
> > +				hback-porch = <112>;
> > +				hfront-porch = <36>;
> > +				hsync-len = <32>;
> > +				vback-porch = <33>;
> > +				vfront-porch = <33>;
> > +				vsync-len = <2>;
> > +				clock-frequency = <25000000>;
> > +			};
> > +		};
> > +	};
> > diff --git a/drivers/video/imxfb.c b/drivers/video/imxfb.c
> > index ef2b587..e0230f8 100644
> > --- a/drivers/video/imxfb.c
> > +++ b/drivers/video/imxfb.c
> > @@ -32,6 +32,12 @@
> >  #include <linux/io.h>
> >  #include <linux/math64.h>
> >  #include <linux/uaccess.h>
> > +#include <linux/of.h>
> > +#include <linux/of_device.h>
> > +
> > +#include <video/of_display_timing.h>
> > +#include <video/of_videomode.h>
> > +#include <video/videomode.h>
> >  
> >  #include <linux/platform_data/video-imxfb.h>
> >  
> > @@ -117,10 +123,11 @@
> >  #define LGWCR_GWAV(alpha)	(((alpha) & 0xff) << 24)
> >  #define LGWCR_GWE	(1 << 22)
> >  
> > +#define IMXFB_LSCR1_DEFAULT 0x00120300
> > +
> >  /* Used fb-mode. Can be set on kernel command line, therefore file-static. */
> >  static const char *fb_mode;
> >  
> > -
> >  /*
> >   * These are the bitfields for each
> >   * display depth that we support.
> > @@ -192,6 +199,19 @@ static struct platform_device_id imxfb_devtype[] = {
> >  };
> >  MODULE_DEVICE_TABLE(platform, imxfb_devtype);
> >  
> > +static struct of_device_id imxfb_of_dev_id[] = {
> > +	{
> > +		.compatible = "fsl,imx1-fb",
> > +		.data = &imxfb_devtype[IMX1_FB],
> > +	}, {
> > +		.compatible = "fsl,imx21-fb",
> > +		.data = &imxfb_devtype[IMX21_FB],
> > +	}, {
> > +		/* sentinel */
> > +	}
> > +};
> > +MODULE_DEVICE_TABLE(of, imxfb_of_dev_id);
> > +
> >  static inline int is_imx1_fb(struct imxfb_info *fbi)
> >  {
> >  	return fbi->devtype == IMX1_FB;
> > @@ -324,6 +344,9 @@ static const struct imx_fb_videomode *imxfb_find_mode(struct imxfb_info *fbi)
> >  	struct imx_fb_videomode *m;
> >  	int i;
> >  
> > +	if (!fb_mode)
> > +		return &fbi->mode[0];
> > +
> >  	for (i = 0, m = &fbi->mode[0]; i < fbi->num_modes; i++, m++) {
> >  		if (!strcmp(m->mode.name, fb_mode))
> >  			return m;
> > @@ -479,6 +502,9 @@ static int imxfb_bl_update_status(struct backlight_device *bl)
> >  	struct imxfb_info *fbi = bl_get_data(bl);
> >  	int brightness = bl->props.brightness;
> >  
> > +	if (!fbi->pwmr)
> > +		return 0;
> > +
> >  	if (bl->props.power != FB_BLANK_UNBLANK)
> >  		brightness = 0;
> >  	if (bl->props.fb_blank != FB_BLANK_UNBLANK)
> > @@ -719,10 +745,14 @@ static int imxfb_activate_var(struct fb_var_screeninfo *var, struct fb_info *inf
> >  
> >  	writel(fbi->pcr, fbi->regs + LCDC_PCR);
> >  #ifndef PWMR_BACKLIGHT_AVAILABLE
> > -	writel(fbi->pwmr, fbi->regs + LCDC_PWMR);
> > +	if (fbi->pwmr)
> > +		writel(fbi->pwmr, fbi->regs + LCDC_PWMR);
> >  #endif
> >  	writel(fbi->lscr1, fbi->regs + LCDC_LSCR1);
> > -	writel(fbi->dmacr, fbi->regs + LCDC_DMACR);
> > +
> > +	/* dmacr = 0 is no valid value, as we need DMA control marks. */
> > +	if (fbi->dmacr)
> > +		writel(fbi->dmacr, fbi->regs + LCDC_DMACR);
> >  
> >  	return 0;
> >  }
> > @@ -758,13 +788,12 @@ static int imxfb_resume(struct platform_device *dev)
> >  #define imxfb_resume	NULL
> >  #endif
> >  
> > -static int __init imxfb_init_fbinfo(struct platform_device *pdev)
> > +static int imxfb_init_fbinfo(struct platform_device *pdev)
> >  {
> >  	struct imx_fb_platform_data *pdata = pdev->dev.platform_data;
> >  	struct fb_info *info = dev_get_drvdata(&pdev->dev);
> >  	struct imxfb_info *fbi = info->par;
> > -	struct imx_fb_videomode *m;
> > -	int i;
> > +	struct device_node *np;
> >  
> >  	pr_debug("%s\n",__func__);
> >  
> > @@ -795,41 +824,95 @@ static int __init imxfb_init_fbinfo(struct platform_device *pdev)
> >  	info->fbops			= &imxfb_ops;
> >  	info->flags			= FBINFO_FLAG_DEFAULT |
> >  					  FBINFO_READS_FAST;
> > -	info->var.grayscale		= pdata->cmap_greyscale;
> > -	fbi->cmap_inverse		= pdata->cmap_inverse;
> > -	fbi->cmap_static		= pdata->cmap_static;
> > -	fbi->lscr1			= pdata->lscr1;
> > -	fbi->dmacr			= pdata->dmacr;
> > -	fbi->pwmr			= pdata->pwmr;
> > -	fbi->lcd_power			= pdata->lcd_power;
> > -	fbi->backlight_power		= pdata->backlight_power;
> > -
> > -	for (i = 0, m = &pdata->mode[0]; i < pdata->num_modes; i++, m++)
> > -		info->fix.smem_len = max_t(size_t, info->fix.smem_len,
> > -				m->mode.xres * m->mode.yres * m->bpp / 8);
> > +	if (pdata) {
> > +		info->var.grayscale		= pdata->cmap_greyscale;
> > +		fbi->cmap_inverse		= pdata->cmap_inverse;
> > +		fbi->cmap_static		= pdata->cmap_static;
> > +		fbi->lscr1			= pdata->lscr1;
> > +		fbi->dmacr			= pdata->dmacr;
> > +		fbi->pwmr			= pdata->pwmr;
> > +		fbi->lcd_power			= pdata->lcd_power;
> > +		fbi->backlight_power		= pdata->backlight_power;
> > +	} else {
> > +		np = pdev->dev.of_node;
> > +		info->var.grayscale = of_property_read_bool(np,
> > +						"cmap-greyscale");
> > +		fbi->cmap_inverse = of_property_read_bool(np, "cmap-inverse");
> > +		fbi->cmap_static = of_property_read_bool(np, "cmap-static");
> > +
> > +		fbi->lscr1 = IMXFB_LSCR1_DEFAULT;
> > +		of_property_read_u32(np, "fsl,lscr1", &fbi->lscr1);
> > +
> > +		of_property_read_u32(np, "fsl,dmacr", &fbi->dmacr);
> > +
> > +		/* These two function pointers could be used by some specific
> > +		 * platforms. */
> > +		fbi->lcd_power = NULL;
> > +		fbi->backlight_power = NULL;
> > +	}
> > +
> > +	return 0;
> > +}
> > +
> > +static int imxfb_of_read_mode(struct device *dev, struct device_node *np,
> > +		struct imx_fb_videomode *imxfb_mode)
> > +{
> > +	int ret;
> > +	struct fb_videomode *of_mode = &imxfb_mode->mode;
> > +	u32 bpp;
> > +	u32 pcr;
> > +
> > +	ret = of_property_read_string(np, "model", &of_mode->name);
> > +	if (ret)
> > +		of_mode->name = NULL;
> > +
> > +	ret = of_get_fb_videomode(np, of_mode, OF_USE_NATIVE_MODE);
> > +	if (ret) {
> > +		dev_err(dev, "Failed to get videomode from DT\n");
> > +		return ret;
> > +	}
> > +
> > +	ret = of_property_read_u32(np, "fsl,bpp", &bpp);
> > +	ret |= of_property_read_u32(np, "fsl,pcr", &pcr);
> > +
> > +	if (ret) {
> > +		dev_err(dev, "Failed to read bpp and pcr from DT\n");
> > +		return -EINVAL;
> > +	}
> > +
> > +	if (bpp < 1 || bpp > 255) {
> > +		dev_err(dev, "Bits per pixel have to be between 1 and 255\n");
> > +		return -EINVAL;
> > +	}
> > +
> > +	imxfb_mode->bpp = bpp;
> > +	imxfb_mode->pcr = pcr;
> >  
> >  	return 0;
> >  }
> >  
> > -static int __init imxfb_probe(struct platform_device *pdev)
> > +static int imxfb_probe(struct platform_device *pdev)
> >  {
> >  	struct imxfb_info *fbi;
> >  	struct fb_info *info;
> >  	struct imx_fb_platform_data *pdata;
> >  	struct resource *res;
> > +	struct imx_fb_videomode *m;
> > +	const struct of_device_id *of_id;
> >  	int ret, i;
> > +	int bytes_per_pixel;
> >  
> >  	dev_info(&pdev->dev, "i.MX Framebuffer driver\n");
> >  
> > +	of_id = of_match_device(imxfb_of_dev_id, &pdev->dev);
> > +	if (of_id)
> > +		pdev->id_entry = of_id->data;
> > +
> >  	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> >  	if (!res)
> >  		return -ENODEV;
> >  
> >  	pdata = pdev->dev.platform_data;
> > -	if (!pdata) {
> > -		dev_err(&pdev->dev,"No platform_data available\n");
> > -		return -ENOMEM;
> > -	}
> >  
> >  	info = framebuffer_alloc(sizeof(struct imxfb_info), &pdev->dev);
> >  	if (!info)
> > @@ -837,15 +920,55 @@ static int __init imxfb_probe(struct platform_device *pdev)
> >  
> >  	fbi = info->par;
> >  
> > -	if (!fb_mode)
> > -		fb_mode = pdata->mode[0].mode.name;
> > -
> >  	platform_set_drvdata(pdev, info);
> >  
> >  	ret = imxfb_init_fbinfo(pdev);
> >  	if (ret < 0)
> >  		goto failed_init;
> >  
> > +	if (pdata) {
> > +		if (!fb_mode)
> > +			fb_mode = pdata->mode[0].mode.name;
> > +
> > +		fbi->mode = pdata->mode;
> > +		fbi->num_modes = pdata->num_modes;
> > +	} else {
> > +		struct device_node *display_np;
> > +		fb_mode = NULL;
> > +
> > +		display_np = of_parse_phandle(pdev->dev.of_node, "display", 0);
> > +		if (!display_np) {
> > +			dev_err(&pdev->dev, "No display defined in devicetree\n");
> > +			ret = -EINVAL;
> > +			goto failed_of_parse;
> > +		}
> > +
> > +		/*
> > +		 * imxfb does not support more modes, we choose only the native
> > +		 * mode.
> > +		 */
> > +		fbi->num_modes = 1;
> > +
> > +		fbi->mode = devm_kzalloc(&pdev->dev,
> > +				sizeof(struct imx_fb_videomode), GFP_KERNEL);
> > +		if (!fbi->mode) {
> > +			ret = -ENOMEM;
> > +			goto failed_of_parse;
> > +		}
> > +
> > +		ret = imxfb_of_read_mode(&pdev->dev, display_np, fbi->mode);
> > +		if (ret)
> > +			goto failed_of_parse;
> > +	}
> > +
> > +	/* Calculate maximum bytes used per pixel. In most cases this should
> > +	 * be the same as m->bpp/8 */
> > +	m = &fbi->mode[0];
> > +	bytes_per_pixel = (m->bpp + 7) / 8;
> > +	for (i = 0; i < fbi->num_modes; i++, m++)
> > +		info->fix.smem_len = max_t(size_t, info->fix.smem_len,
> > +				m->mode.xres * m->mode.yres * bytes_per_pixel);
> > +
> >  	res = request_mem_region(res->start, resource_size(res),
> >  				DRIVER_NAME);
> >  	if (!res) {
> > @@ -878,7 +1001,8 @@ static int __init imxfb_probe(struct platform_device *pdev)
> >  		goto failed_ioremap;
> >  	}
> >  
> > -	if (!pdata->fixed_screen_cpu) {
> > +	/* Seems not being used by anyone, so no support for oftree */
> > +	if (!pdata || !pdata->fixed_screen_cpu) {
> >  		fbi->map_size = PAGE_ALIGN(info->fix.smem_len);
> >  		fbi->map_cpu = dma_alloc_writecombine(&pdev->dev,
> >  				fbi->map_size, &fbi->map_dma, GFP_KERNEL);
> > @@ -903,18 +1027,16 @@ static int __init imxfb_probe(struct platform_device *pdev)
> >  		info->fix.smem_start = fbi->screen_dma;
> >  	}
> >  
> > -	if (pdata->init) {
> > +	if (pdata && pdata->init) {
> >  		ret = pdata->init(fbi->pdev);
> >  		if (ret)
> >  			goto failed_platform_init;
> >  	}
> >  
> > -	fbi->mode = pdata->mode;
> > -	fbi->num_modes = pdata->num_modes;
> >  
> >  	INIT_LIST_HEAD(&info->modelist);
> > -	for (i = 0; i < pdata->num_modes; i++)
> > -		fb_add_videomode(&pdata->mode[i].mode, &info->modelist);
> > +	for (i = 0; i < fbi->num_modes; i++)
> > +		fb_add_videomode(&fbi->mode[i].mode, &info->modelist);
> >  
> >  	/*
> >  	 * This makes sure that our colour bitfield
> > @@ -944,10 +1066,10 @@ static int __init imxfb_probe(struct platform_device *pdev)
> >  failed_register:
> >  	fb_dealloc_cmap(&info->cmap);
> >  failed_cmap:
> > -	if (pdata->exit)
> > +	if (pdata && pdata->exit)
> >  		pdata->exit(fbi->pdev);
> >  failed_platform_init:
> > -	if (!pdata->fixed_screen_cpu)
> > +	if (pdata && !pdata->fixed_screen_cpu)
> >  		dma_free_writecombine(&pdev->dev,fbi->map_size,fbi->map_cpu,
> >  			fbi->map_dma);
> >  failed_map:
> > @@ -956,6 +1078,7 @@ failed_ioremap:
> >  failed_getclock:
> >  	release_mem_region(res->start, resource_size(res));
> >  failed_req:
> > +failed_of_parse:
> >  	kfree(info->pseudo_palette);
> >  failed_init:
> >  	platform_set_drvdata(pdev, NULL);
> > @@ -980,7 +1103,7 @@ static int imxfb_remove(struct platform_device *pdev)
> >  	unregister_framebuffer(info);
> >  
> >  	pdata = pdev->dev.platform_data;
> > -	if (pdata->exit)
> > +	if (pdata && pdata->exit)
> >  		pdata->exit(fbi->pdev);
> >  
> >  	fb_dealloc_cmap(&info->cmap);
> > @@ -1009,6 +1132,7 @@ static struct platform_driver imxfb_driver = {
> >  	.shutdown	= imxfb_shutdown,
> >  	.driver		= {
> >  		.name	= DRIVER_NAME,
> > +		.of_match_table = imxfb_of_dev_id,
> >  	},
> >  	.id_table	= imxfb_devtype,
> >  };
> > -- 
> > 1.8.1.5
> > 
> 

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From mpa at pengutronix.de  Sun Apr 21 04:51:29 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Sun, 21 Apr 2013 10:51:29 +0200
Subject: [PATCH RESEND v5 0/2] dma: imx-dma: OFTree support
In-Reply-To: <20130418144428.GB2222@S2101-09.ap.freescale.net>
References: <1366291298-30004-1-git-send-email-mpa@pengutronix.de>
 <20130418144428.GB2222@S2101-09.ap.freescale.net>
Message-ID: <20130421085129.GB31179@pengutronix.de>

On Thu, Apr 18, 2013 at 10:44:29PM +0800, Shawn Guo wrote:
> On Thu, Apr 18, 2013 at 03:21:36PM +0200, Markus Pargmann wrote:
> > Markus Pargmann (2):
> >       dma: imx-dma: Add oftree support
> >       DMA: imx-dma: imxdma->dev used uninitialized
> 
> Both,
> 
> Reviewed-by: Shawn Guo <shawn.guo at linaro.org>
> 
Thanks

Markus

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From linux at arm.linux.org.uk  Sun Apr 21 04:53:21 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Sun, 21 Apr 2013 09:53:21 +0100
Subject: [PATCH v2] serial: pl011: Add Device Tree support to request
 DMA channels
In-Reply-To: <201304201233.45501.arnd@arndb.de>
References: <1366272857-14038-1-git-send-email-lee.jones@linaro.org>
 <201304201233.45501.arnd@arndb.de>
Message-ID: <20130421085321.GD14496@n2100.arm.linux.org.uk>

On Sat, Apr 20, 2013 at 12:33:45PM +0200, Arnd Bergmann wrote:
> @@ -315,6 +325,7 @@ static void pl011_dma_probe_initcall(struct uart_amba_port *uap)
>  struct dma_uap {
>  	struct list_head node;
>  	struct uart_amba_port *uap;
> +	struct device *dev;

There is really no need for this.  This device is available via uap->port.dev.


From mpa at pengutronix.de  Sun Apr 21 05:08:21 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Sun, 21 Apr 2013 11:08:21 +0200
Subject: [PATCH v6 0/2] dma: imx-dma: OFTree support
Message-ID: <1366535303-31223-1-git-send-email-mpa@pengutronix.de>

Hi,

this series adds support for the generic DMA DT bindings for imx-dma.

@Arnd and Shawn:
I added your Reviewed-by tags again. Please let me know if they do not include
the last style fixes on the xlate function.

Thanks,

Markus


Markus Pargmann (2):
      dma: imx-dma: Add oftree support
      DMA: imx-dma: imxdma->dev used uninitialized

 Documentation/devicetree/bindings/dma/fsl-imx-dma.txt | 48 ++++++++++++++++++++++++++++++++++++++++++++++++
 drivers/dma/imx-dma.c                                 | 77 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
 include/linux/platform_data/dma-imx.h                 |  6 ++----
 3 files changed, 126 insertions(+), 5 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/dma/fsl-imx-dma.txt



From mpa at pengutronix.de  Sun Apr 21 05:08:22 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Sun, 21 Apr 2013 11:08:22 +0200
Subject: [PATCH v6 1/2] dma: imx-dma: Add oftree support
In-Reply-To: <1366535303-31223-1-git-send-email-mpa@pengutronix.de>
References: <1366535303-31223-1-git-send-email-mpa@pengutronix.de>
Message-ID: <1366535303-31223-2-git-send-email-mpa@pengutronix.de>

Adding devicetree support for imx-dma driver. Use driver name for
function 'imx_dma_is_general_purpose' because the devicename for
devicetree initialized devices is different.

Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
Reviewed-by: Arnd Bergmann <arnd at arndb.de>
Reviewed-by: Shawn Guo <shawn.guo at linaro.org>
---

Notes:
    Changes in V6:
    - Style fixes in imxdma_xlate function, moved request assignment and removed
      unnecessary cast.
    
    Changes in V5:
    - Style fix
    - Documentation reference
    
    Changes in V4:
    - Directly use "imxdma_channel" as proposed by Arnd. This removes the
    allocation of imx_dma_data.
    - Simplify function imx_dma_is_general_purpose using driver names.
    
    Changes in V3:
    - Create a imxdma translate function to pass the device object into the
    filter function.
    
    Changes in V2:
    - Change the driver to use generic DMA DT bindings.
    - Add a imx-dma filter function that sets the dma request line in
      private data.

 .../devicetree/bindings/dma/fsl-imx-dma.txt        | 48 ++++++++++++++
 drivers/dma/imx-dma.c                              | 75 ++++++++++++++++++++++
 include/linux/platform_data/dma-imx.h              |  6 +-
 3 files changed, 125 insertions(+), 4 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/dma/fsl-imx-dma.txt

diff --git a/Documentation/devicetree/bindings/dma/fsl-imx-dma.txt b/Documentation/devicetree/bindings/dma/fsl-imx-dma.txt
new file mode 100644
index 0000000..2717ecb
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/fsl-imx-dma.txt
@@ -0,0 +1,48 @@
+* Freescale Direct Memory Access (DMA) Controller for i.MX
+
+This document will only describe differences to the generic DMA Controller and
+DMA request bindings as described in dma/dma.txt .
+
+* DMA controller
+
+Required properties:
+- compatible : Should be "fsl,<chip>-dma". chip can be imx1, imx21 or imx27
+- reg : Should contain DMA registers location and length
+- interrupts : First item should be DMA interrupt, second one is optional and
+    should contain DMA Error interrupt
+- #dma-cells : Has to be 1. imx-dma does not support anything else.
+
+Optional properties:
+- #dma-channels : Number of DMA channels supported. Should be 16.
+- #dma-requests : Number of DMA requests supported.
+
+Example:
+
+	dma: dma at 10001000 {
+		compatible = "fsl,imx27-dma";
+		reg = <0x10001000 0x1000>;
+		interrupts = <32 33>;
+		#dma-cells = <1>;
+		#dma-channels = <16>;
+	};
+
+
+* DMA client
+
+Clients have to specify the DMA requests with phandles in a list.
+
+Required properties:
+- dmas: List of one or more DMA request specifiers. One DMA request specifier
+    consists of a phandle to the DMA controller followed by the integer
+    specifiying the request line.
+- dma-names: List of string identifiers for the DMA requests. For the correct
+    names, have a look at the specific client driver.
+
+Example:
+
+	sdhci1: sdhci at 10013000 {
+		...
+		dmas = <&dma 7>;
+		dma-names = "rx-tx";
+		...
+	};
diff --git a/drivers/dma/imx-dma.c b/drivers/dma/imx-dma.c
index 70b8975..b74b249 100644
--- a/drivers/dma/imx-dma.c
+++ b/drivers/dma/imx-dma.c
@@ -27,6 +27,8 @@
 #include <linux/clk.h>
 #include <linux/dmaengine.h>
 #include <linux/module.h>
+#include <linux/of_device.h>
+#include <linux/of_dma.h>
 
 #include <asm/irq.h>
 #include <linux/platform_data/dma-imx.h>
@@ -186,6 +188,11 @@ struct imxdma_engine {
 	enum imx_dma_type		devtype;
 };
 
+struct imxdma_filter_data {
+	struct imxdma_engine	*imxdma;
+	int			 request;
+};
+
 static struct platform_device_id imx_dma_devtype[] = {
 	{
 		.name = "imx1-dma",
@@ -202,6 +209,22 @@ static struct platform_device_id imx_dma_devtype[] = {
 };
 MODULE_DEVICE_TABLE(platform, imx_dma_devtype);
 
+static const struct of_device_id imx_dma_of_dev_id[] = {
+	{
+		.compatible = "fsl,imx1-dma",
+		.data = &imx_dma_devtype[IMX1_DMA],
+	}, {
+		.compatible = "fsl,imx21-dma",
+		.data = &imx_dma_devtype[IMX21_DMA],
+	}, {
+		.compatible = "fsl,imx27-dma",
+		.data = &imx_dma_devtype[IMX27_DMA],
+	}, {
+		/* sentinel */
+	}
+};
+MODULE_DEVICE_TABLE(of, imx_dma_of_dev_id);
+
 static inline int is_imx1_dma(struct imxdma_engine *imxdma)
 {
 	return imxdma->devtype == IMX1_DMA;
@@ -997,13 +1020,50 @@ static void imxdma_issue_pending(struct dma_chan *chan)
 	spin_unlock_irqrestore(&imxdma->lock, flags);
 }
 
+static bool imxdma_filter_fn(struct dma_chan *chan, void *param)
+{
+	struct imxdma_filter_data *fdata = param;
+	struct imxdma_channel *imxdma_chan = to_imxdma_chan(chan);
+
+	if (chan->device->dev != fdata->imxdma->dev)
+		return false;
+
+	imxdma_chan->dma_request = fdata->request;
+	chan->private = NULL;
+
+	return true;
+}
+
+static struct dma_chan *imxdma_xlate(struct of_phandle_args *dma_spec,
+						struct of_dma *ofdma)
+{
+	int count = dma_spec->args_count;
+	struct imxdma_engine *imxdma = ofdma->of_dma_data;
+	struct imxdma_filter_data fdata = {
+		.imxdma = imxdma,
+	};
+
+	if (count != 1)
+		return NULL;
+
+	fdata.request = dma_spec->args[0];
+
+	return dma_request_channel(imxdma->dma_device.cap_mask,
+					imxdma_filter_fn, &fdata);
+}
+
 static int __init imxdma_probe(struct platform_device *pdev)
 	{
 	struct imxdma_engine *imxdma;
 	struct resource *res;
+	const struct of_device_id *of_id;
 	int ret, i;
 	int irq, irq_err;
 
+	of_id = of_match_device(imx_dma_of_dev_id, &pdev->dev);
+	if (of_id)
+		pdev->id_entry = of_id->data;
+
 	imxdma = devm_kzalloc(&pdev->dev, sizeof(*imxdma), GFP_KERNEL);
 	if (!imxdma)
 		return -ENOMEM;
@@ -1137,8 +1197,19 @@ static int __init imxdma_probe(struct platform_device *pdev)
 		goto err;
 	}
 
+	if (pdev->dev.of_node) {
+		ret = of_dma_controller_register(pdev->dev.of_node,
+				imxdma_xlate, imxdma);
+		if (ret) {
+			dev_err(&pdev->dev, "unable to register of_dma_controller\n");
+			goto err_of_dma_controller;
+		}
+	}
+
 	return 0;
 
+err_of_dma_controller:
+	dma_async_device_unregister(&imxdma->dma_device);
 err:
 	clk_disable_unprepare(imxdma->dma_ipg);
 	clk_disable_unprepare(imxdma->dma_ahb);
@@ -1151,6 +1222,9 @@ static int __exit imxdma_remove(struct platform_device *pdev)
 
         dma_async_device_unregister(&imxdma->dma_device);
 
+	if (pdev->dev.of_node)
+		of_dma_controller_free(pdev->dev.of_node);
+
 	clk_disable_unprepare(imxdma->dma_ipg);
 	clk_disable_unprepare(imxdma->dma_ahb);
 
@@ -1160,6 +1234,7 @@ static int __exit imxdma_remove(struct platform_device *pdev)
 static struct platform_driver imxdma_driver = {
 	.driver		= {
 		.name	= "imx-dma",
+		.of_match_table = imx_dma_of_dev_id,
 	},
 	.id_table	= imx_dma_devtype,
 	.remove		= __exit_p(imxdma_remove),
diff --git a/include/linux/platform_data/dma-imx.h b/include/linux/platform_data/dma-imx.h
index f6d30cc..beac6b8 100644
--- a/include/linux/platform_data/dma-imx.h
+++ b/include/linux/platform_data/dma-imx.h
@@ -60,10 +60,8 @@ static inline int imx_dma_is_ipu(struct dma_chan *chan)
 
 static inline int imx_dma_is_general_purpose(struct dma_chan *chan)
 {
-	return strstr(dev_name(chan->device->dev), "sdma") ||
-		!strcmp(dev_name(chan->device->dev), "imx1-dma") ||
-		!strcmp(dev_name(chan->device->dev), "imx21-dma") ||
-		!strcmp(dev_name(chan->device->dev), "imx27-dma");
+	return !strcmp(chan->device->dev->driver->name, "imx-sdma") ||
+		!strcmp(chan->device->dev->driver->name, "imx-dma");
 }
 
 #endif
-- 
1.8.1.5



From mpa at pengutronix.de  Sun Apr 21 05:08:23 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Sun, 21 Apr 2013 11:08:23 +0200
Subject: [PATCH v6 2/2] DMA: imx-dma: imxdma->dev used uninitialized
In-Reply-To: <1366535303-31223-1-git-send-email-mpa@pengutronix.de>
References: <1366535303-31223-1-git-send-email-mpa@pengutronix.de>
Message-ID: <1366535303-31223-3-git-send-email-mpa@pengutronix.de>

imxdma->dev is used for dev_warn before it was set.

Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
Reviewed-by: Shawn Guo <shawn.guo at linaro.org>
---
 drivers/dma/imx-dma.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dma/imx-dma.c b/drivers/dma/imx-dma.c
index b74b249..b9aa549 100644
--- a/drivers/dma/imx-dma.c
+++ b/drivers/dma/imx-dma.c
@@ -1068,6 +1068,7 @@ static int __init imxdma_probe(struct platform_device *pdev)
 	if (!imxdma)
 		return -ENOMEM;
 
+	imxdma->dev = &pdev->dev;
 	imxdma->devtype = pdev->id_entry->driver_data;
 
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -1172,7 +1173,6 @@ static int __init imxdma_probe(struct platform_device *pdev)
 			      &imxdma->dma_device.channels);
 	}
 
-	imxdma->dev = &pdev->dev;
 	imxdma->dma_device.dev = &pdev->dev;
 
 	imxdma->dma_device.device_alloc_chan_resources = imxdma_alloc_chan_resources;
-- 
1.8.1.5



From tim at krieglstein.org  Sun Apr 21 05:43:50 2013
From: tim at krieglstein.org (Tim Sander)
Date: Sun, 21 Apr 2013 11:43:50 +0200
Subject: Pinmuxing with devicetree (beaglebone)
Message-ID: <201304211143.50961.tim@krieglstein.org>

Hi

I am currently trying to get pinmuxing working on a beaglebone board with an 
offtree driver. This is for a custom handbuild hardware so i guess there is no 
point in bringing this mainline.

While this is havyly patched 3.8.4 version running over here i think the
pinmux infrastructure is the new standard way. At least there is a 
pinctrl/44e10800.pinmux directory in debugfs?

My last aproach was using the devicetree but beeing new to this devicetree 
stuff i just got stuck: 
http://comments.gmane.org/gmane.linux.ports.arm.kernel/231204

Now i tried use the way it is described in Documentation/pinctrl.txt but still 
there are the includes missing: #include <linux/pinctrl/consumer.h>.

Also while there is a /sys/kernel/debug/pinctrl/44e10800.pinmux in debugfs i 
found that not so intuitive as the omap_mux which disappeared. Also i didn't 
find any documentation for this debugfs stuff.

So what is the recommended way to get this stupid pinmuxing going. In pre 
devicetree days one would just pick the mux.h include of the platform and 
initialized the muxers which was pretty straight forward. Now with device tree 
its much more complicated. No proper syntax checking as with the c definitions 
and no documentation how to get this magic stuff working :-(.

The whole stuff is build by a ptxdist (a embedded buildsystem) and can be 
found over here:
https://gitorious.org/ptxdist-beaglebone/ptxdist-beaglebone

Best regards
Tim


From haojian.zhuang at linaro.org  Sun Apr 21 05:46:55 2013
From: haojian.zhuang at linaro.org (Haojian Zhuang)
Date: Sun, 21 Apr 2013 17:46:55 +0800
Subject: [PATCH 1/3] irqchip: move mmp irq driver
Message-ID: <1366537617-11328-1-git-send-email-haojian.zhuang@linaro.org>

Move irq-mmp driver from mach-mmp directory into irqchip directory.

Signed-off-by: Haojian Zhuang <haojian.zhuang at linaro.org>
---
 arch/arm/mach-mmp/Makefile                           |    2 +-
 arch/arm/mach-mmp/common.h                           |    1 -
 arch/arm/mach-mmp/include/mach/pxa168.h              |    1 +
 arch/arm/mach-mmp/include/mach/pxa910.h              |    1 +
 arch/arm/mach-mmp/pxa910.c                           |    1 +
 drivers/irqchip/Makefile                             |    1 +
 arch/arm/mach-mmp/irq.c => drivers/irqchip/irq-mmp.c |    2 --
 7 files changed, 5 insertions(+), 4 deletions(-)
 rename arch/arm/mach-mmp/irq.c => drivers/irqchip/irq-mmp.c (99%)

diff --git a/arch/arm/mach-mmp/Makefile b/arch/arm/mach-mmp/Makefile
index 095c155..9b702a1 100644
--- a/arch/arm/mach-mmp/Makefile
+++ b/arch/arm/mach-mmp/Makefile
@@ -2,7 +2,7 @@
 # Makefile for Marvell's PXA168 processors line
 #
 
-obj-y				+= common.o devices.o time.o irq.o
+obj-y				+= common.o devices.o time.o
 
 # SoC support
 obj-$(CONFIG_CPU_PXA168)	+= pxa168.o
diff --git a/arch/arm/mach-mmp/common.h b/arch/arm/mach-mmp/common.h
index 0bdc50b..9c1c9be 100644
--- a/arch/arm/mach-mmp/common.h
+++ b/arch/arm/mach-mmp/common.h
@@ -2,7 +2,6 @@
 
 extern void timer_init(int irq);
 
-extern void __init icu_init_irq(void);
 extern void __init mmp_map_io(void);
 extern void mmp_restart(char, const char *);
 extern void __init pxa168_clk_init(void);
diff --git a/arch/arm/mach-mmp/include/mach/pxa168.h b/arch/arm/mach-mmp/include/mach/pxa168.h
index 7ed1df2..e01dc2a 100644
--- a/arch/arm/mach-mmp/include/mach/pxa168.h
+++ b/arch/arm/mach-mmp/include/mach/pxa168.h
@@ -2,6 +2,7 @@
 #define __ASM_MACH_PXA168_H
 
 extern void pxa168_timer_init(void);
+extern void __init icu_init_irq(void);
 extern void __init pxa168_init_irq(void);
 extern void pxa168_restart(char, const char *);
 extern void pxa168_clear_keypad_wakeup(void);
diff --git a/arch/arm/mach-mmp/include/mach/pxa910.h b/arch/arm/mach-mmp/include/mach/pxa910.h
index b914afa..9225320 100644
--- a/arch/arm/mach-mmp/include/mach/pxa910.h
+++ b/arch/arm/mach-mmp/include/mach/pxa910.h
@@ -2,6 +2,7 @@
 #define __ASM_MACH_PXA910_H
 
 extern void pxa910_timer_init(void);
+extern void __init icu_init_irq(void);
 extern void __init pxa910_init_irq(void);
 
 #include <linux/i2c.h>
diff --git a/arch/arm/mach-mmp/pxa910.c b/arch/arm/mach-mmp/pxa910.c
index ce6393a..a586742 100644
--- a/arch/arm/mach-mmp/pxa910.c
+++ b/arch/arm/mach-mmp/pxa910.c
@@ -23,6 +23,7 @@
 #include <mach/dma.h>
 #include <mach/mfp.h>
 #include <mach/devices.h>
+#include <mach/pxa910.h>
 
 #include "common.h"
 
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index 8daa76a..9418f4b 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -6,6 +6,7 @@ obj-$(CONFIG_ARCH_MXS)			+= irq-mxs.o
 obj-$(CONFIG_ARCH_S3C24XX)		+= irq-s3c24xx.o
 obj-$(CONFIG_METAG)			+= irq-metag-ext.o
 obj-$(CONFIG_METAG_PERFCOUNTER_IRQS)	+= irq-metag.o
+obj-$(CONFIG_ARCH_MMP)			+= irq-mmp.o
 obj-$(CONFIG_ARCH_SUNXI)		+= irq-sun4i.o
 obj-$(CONFIG_ARCH_SPEAR3XX)		+= spear-shirq.o
 obj-$(CONFIG_ARM_GIC)			+= irq-gic.o
diff --git a/arch/arm/mach-mmp/irq.c b/drivers/irqchip/irq-mmp.c
similarity index 99%
rename from arch/arm/mach-mmp/irq.c
rename to drivers/irqchip/irq-mmp.c
index 3c71246..dab6def 100644
--- a/arch/arm/mach-mmp/irq.c
+++ b/drivers/irqchip/irq-mmp.c
@@ -30,8 +30,6 @@
 #include <mach/pm-pxa910.h>
 #endif
 
-#include "common.h"
-
 #define MAX_ICU_NR		16
 
 struct icu_chip_data {
-- 
1.7.10.4



From haojian.zhuang at linaro.org  Sun Apr 21 05:46:56 2013
From: haojian.zhuang at linaro.org (Haojian Zhuang)
Date: Sun, 21 Apr 2013 17:46:56 +0800
Subject: [PATCH 2/3] irqchip: mmp: support irqchip
In-Reply-To: <1366537617-11328-1-git-send-email-haojian.zhuang@linaro.org>
References: <1366537617-11328-1-git-send-email-haojian.zhuang@linaro.org>
Message-ID: <1366537617-11328-2-git-send-email-haojian.zhuang@linaro.org>

Support IRQCHIP on irq-mmp driver.

Signed-off-by: Haojian Zhuang <haojian.zhuang at linaro.org>
---
 arch/arm/mach-mmp/mmp-dt.c  |   10 +--
 arch/arm/mach-mmp/mmp2-dt.c |    9 +-
 drivers/irqchip/irq-mmp.c   |  208 +++++++++++++++++++++----------------------
 3 files changed, 109 insertions(+), 118 deletions(-)

diff --git a/arch/arm/mach-mmp/mmp-dt.c b/arch/arm/mach-mmp/mmp-dt.c
index b37915d..aaca3c8 100644
--- a/arch/arm/mach-mmp/mmp-dt.c
+++ b/arch/arm/mach-mmp/mmp-dt.c
@@ -9,17 +9,13 @@
  *  publishhed by the Free Software Foundation.
  */
 
-#include <linux/irq.h>
-#include <linux/irqdomain.h>
-#include <linux/of_irq.h>
+#include <linux/irqchip.h>
 #include <linux/of_platform.h>
 #include <asm/mach/arch.h>
 #include <asm/mach/time.h>
-#include <mach/irqs.h>
 
 #include "common.h"
 
-extern void __init mmp_dt_irq_init(void);
 extern void __init mmp_dt_init_timer(void);
 
 static const struct of_dev_auxdata pxa168_auxdata_lookup[] __initconst = {
@@ -64,7 +60,7 @@ static const char *mmp_dt_board_compat[] __initdata = {
 
 DT_MACHINE_START(PXA168_DT, "Marvell PXA168 (Device Tree Support)")
 	.map_io		= mmp_map_io,
-	.init_irq	= mmp_dt_irq_init,
+	.init_irq	= irqchip_init,
 	.init_time	= mmp_dt_init_timer,
 	.init_machine	= pxa168_dt_init,
 	.dt_compat	= mmp_dt_board_compat,
@@ -72,7 +68,7 @@ MACHINE_END
 
 DT_MACHINE_START(PXA910_DT, "Marvell PXA910 (Device Tree Support)")
 	.map_io		= mmp_map_io,
-	.init_irq	= mmp_dt_irq_init,
+	.init_irq	= irqchip_init,
 	.init_time	= mmp_dt_init_timer,
 	.init_machine	= pxa910_dt_init,
 	.dt_compat	= mmp_dt_board_compat,
diff --git a/arch/arm/mach-mmp/mmp2-dt.c b/arch/arm/mach-mmp/mmp2-dt.c
index 4ac2567..d12231d 100644
--- a/arch/arm/mach-mmp/mmp2-dt.c
+++ b/arch/arm/mach-mmp/mmp2-dt.c
@@ -10,18 +10,13 @@
  */
 
 #include <linux/io.h>
-#include <linux/irq.h>
-#include <linux/irqdomain.h>
-#include <linux/of_irq.h>
+#include <linux/irqchip.h>
 #include <linux/of_platform.h>
 #include <asm/mach/arch.h>
 #include <asm/mach/time.h>
-#include <mach/irqs.h>
-#include <mach/regs-apbc.h>
 
 #include "common.h"
 
-extern void __init mmp_dt_irq_init(void);
 extern void __init mmp_dt_init_timer(void);
 
 static const struct of_dev_auxdata mmp2_auxdata_lookup[] __initconst = {
@@ -49,7 +44,7 @@ static const char *mmp2_dt_board_compat[] __initdata = {
 
 DT_MACHINE_START(MMP2_DT, "Marvell MMP2 (Device Tree Support)")
 	.map_io		= mmp_map_io,
-	.init_irq	= mmp_dt_irq_init,
+	.init_irq	= irqchip_init,
 	.init_time	= mmp_dt_init_timer,
 	.init_machine	= mmp2_dt_init,
 	.dt_compat	= mmp2_dt_board_compat,
diff --git a/drivers/irqchip/irq-mmp.c b/drivers/irqchip/irq-mmp.c
index dab6def..2f088ba 100644
--- a/drivers/irqchip/irq-mmp.c
+++ b/drivers/irqchip/irq-mmp.c
@@ -30,6 +30,8 @@
 #include <mach/pm-pxa910.h>
 #endif
 
+#include "irqchip.h"
+
 #define MAX_ICU_NR		16
 
 struct icu_chip_data {
@@ -324,138 +326,136 @@ void __init mmp2_init_icu(void)
 }
 
 #ifdef CONFIG_OF
-static const struct of_device_id intc_ids[] __initconst = {
-	{ .compatible = "mrvl,mmp-intc", .data = &mmp_conf },
-	{ .compatible = "mrvl,mmp2-intc", .data = &mmp2_conf },
-	{}
-};
-
-static const struct of_device_id mmp_mux_irq_match[] __initconst = {
-	{ .compatible = "mrvl,mmp2-mux-intc" },
-	{}
-};
-
-int __init mmp2_mux_init(struct device_node *parent)
+static int __init mmp_init_bases(struct device_node *node)
 {
-	struct device_node *node;
-	const struct of_device_id *of_id;
-	struct resource res;
-	int i, irq_base, ret, irq;
-	u32 nr_irqs, mfp_irq;
-
-	node = parent;
-	max_icu_nr = 1;
-	for (i = 1; i < MAX_ICU_NR; i++) {
-		node = of_find_matching_node(node, mmp_mux_irq_match);
-		if (!node)
-			break;
-		of_id = of_match_node(&mmp_mux_irq_match[0], node);
-		ret = of_property_read_u32(node, "mrvl,intc-nr-irqs",
-					   &nr_irqs);
-		if (ret) {
-			pr_err("Not found mrvl,intc-nr-irqs property\n");
-			ret = -EINVAL;
-			goto err;
-		}
-		ret = of_address_to_resource(node, 0, &res);
-		if (ret < 0) {
-			pr_err("Not found reg property\n");
-			ret = -EINVAL;
-			goto err;
-		}
-		icu_data[i].reg_status = mmp_icu_base + res.start;
-		ret = of_address_to_resource(node, 1, &res);
-		if (ret < 0) {
-			pr_err("Not found reg property\n");
-			ret = -EINVAL;
-			goto err;
-		}
-		icu_data[i].reg_mask = mmp_icu_base + res.start;
-		icu_data[i].cascade_irq = irq_of_parse_and_map(node, 0);
-		if (!icu_data[i].cascade_irq) {
-			ret = -EINVAL;
-			goto err;
-		}
-
-		irq_base = irq_alloc_descs(-1, 0, nr_irqs, 0);
-		if (irq_base < 0) {
-			pr_err("Failed to allocate IRQ numbers for mux intc\n");
-			ret = irq_base;
-			goto err;
-		}
-		if (!of_property_read_u32(node, "mrvl,clr-mfp-irq",
-					  &mfp_irq)) {
-			icu_data[i].clr_mfp_irq_base = irq_base;
-			icu_data[i].clr_mfp_hwirq = mfp_irq;
-		}
-		irq_set_chained_handler(icu_data[i].cascade_irq,
-					icu_mux_irq_demux);
-		icu_data[i].nr_irqs = nr_irqs;
-		icu_data[i].virq_base = irq_base;
-		icu_data[i].domain = irq_domain_add_legacy(node, nr_irqs,
-							   irq_base, 0,
-							   &mmp_irq_domain_ops,
-							   &icu_data[i]);
-		for (irq = irq_base; irq < irq_base + nr_irqs; irq++)
-			icu_mask_irq(irq_get_irq_data(irq));
-	}
-	max_icu_nr = i;
-	return 0;
-err:
-	of_node_put(node);
-	max_icu_nr = i;
-	return ret;
-}
-
-void __init mmp_dt_irq_init(void)
-{
-	struct device_node *node;
-	const struct of_device_id *of_id;
-	struct mmp_intc_conf *conf;
-	int nr_irqs, irq_base, ret, irq;
-
-	node = of_find_matching_node(NULL, intc_ids);
-	if (!node) {
-		pr_err("Failed to find interrupt controller in arch-mmp\n");
-		return;
-	}
-	of_id = of_match_node(intc_ids, node);
-	conf = of_id->data;
+	int ret, nr_irqs, irq, irq_base;
 
 	ret = of_property_read_u32(node, "mrvl,intc-nr-irqs", &nr_irqs);
 	if (ret) {
 		pr_err("Not found mrvl,intc-nr-irqs property\n");
-		return;
+		return ret;
 	}
 
 	mmp_icu_base = of_iomap(node, 0);
 	if (!mmp_icu_base) {
 		pr_err("Failed to get interrupt controller register\n");
-		return;
+		return -ENOMEM;
 	}
 
 	irq_base = irq_alloc_descs(-1, 0, nr_irqs - NR_IRQS_LEGACY, 0);
 	if (irq_base < 0) {
 		pr_err("Failed to allocate IRQ numbers\n");
+		ret = irq_base;
 		goto err;
 	} else if (irq_base != NR_IRQS_LEGACY) {
 		pr_err("ICU's irqbase should be started from 0\n");
+		ret = -EINVAL;
 		goto err;
 	}
-	icu_data[0].conf_enable = conf->conf_enable;
-	icu_data[0].conf_disable = conf->conf_disable;
-	icu_data[0].conf_mask = conf->conf_mask;
 	icu_data[0].nr_irqs = nr_irqs;
 	icu_data[0].virq_base = 0;
 	icu_data[0].domain = irq_domain_add_legacy(node, nr_irqs, 0, 0,
 						   &mmp_irq_domain_ops,
 						   &icu_data[0]);
-	irq_set_default_host(icu_data[0].domain);
 	for (irq = 0; irq < nr_irqs; irq++)
 		icu_mask_irq(irq_get_irq_data(irq));
-	mmp2_mux_init(node);
-	return;
+	return 0;
 err:
 	iounmap(mmp_icu_base);
+	return ret;
+}
+
+static int __init mmp_of_init(struct device_node *node,
+			      struct device_node *parent)
+{
+	int ret;
+
+	ret = mmp_init_bases(node);
+	if (ret < 0)
+		return ret;
+
+	icu_data[0].conf_enable = mmp_conf.conf_enable;
+	icu_data[0].conf_disable = mmp_conf.conf_disable;
+	icu_data[0].conf_mask = mmp_conf.conf_mask;
+	irq_set_default_host(icu_data[0].domain);
+	max_icu_nr = 1;
+	return 0;
+}
+
+static int __init mmp2_of_init(struct device_node *node,
+			       struct device_node *parent)
+{
+	int ret;
+
+	ret = mmp_init_bases(node);
+	if (ret < 0)
+		return ret;
+
+	icu_data[0].conf_enable = mmp2_conf.conf_enable;
+	icu_data[0].conf_disable = mmp2_conf.conf_disable;
+	icu_data[0].conf_mask = mmp2_conf.conf_mask;
+	irq_set_default_host(icu_data[0].domain);
+	max_icu_nr = 1;
+	return 0;
+}
+
+static int __init mmp2_mux_of_init(struct device_node *node,
+				   struct device_node *parent)
+{
+	struct resource res;
+	int i, irq_base, ret, irq;
+	u32 nr_irqs, mfp_irq;
+
+	if (!parent)
+		return -ENODEV;
+
+	i = max_icu_nr;
+	ret = of_property_read_u32(node, "mrvl,intc-nr-irqs",
+				   &nr_irqs);
+	if (ret) {
+		pr_err("Not found mrvl,intc-nr-irqs property\n");
+		return -EINVAL;
+	}
+	ret = of_address_to_resource(node, 0, &res);
+	if (ret < 0) {
+		pr_err("Not found reg property\n");
+		return -EINVAL;
+	}
+	icu_data[i].reg_status = mmp_icu_base + res.start;
+	ret = of_address_to_resource(node, 1, &res);
+	if (ret < 0) {
+		pr_err("Not found reg property\n");
+		return -EINVAL;
+	}
+	icu_data[i].reg_mask = mmp_icu_base + res.start;
+	icu_data[i].cascade_irq = irq_of_parse_and_map(node, 0);
+	if (!icu_data[i].cascade_irq)
+		return -EINVAL;
+
+	irq_base = irq_alloc_descs(-1, 0, nr_irqs, 0);
+	if (irq_base < 0) {
+		pr_err("Failed to allocate IRQ numbers for mux intc\n");
+		return irq_base;
+	}
+	if (!of_property_read_u32(node, "mrvl,clr-mfp-irq",
+				  &mfp_irq)) {
+		icu_data[i].clr_mfp_irq_base = irq_base;
+		icu_data[i].clr_mfp_hwirq = mfp_irq;
+	}
+	irq_set_chained_handler(icu_data[i].cascade_irq,
+				icu_mux_irq_demux);
+	icu_data[i].nr_irqs = nr_irqs;
+	icu_data[i].virq_base = irq_base;
+	icu_data[i].domain = irq_domain_add_legacy(node, nr_irqs,
+						   irq_base, 0,
+						   &mmp_irq_domain_ops,
+						   &icu_data[i]);
+	for (irq = irq_base; irq < irq_base + nr_irqs; irq++)
+		icu_mask_irq(irq_get_irq_data(irq));
+	max_icu_nr++;
+	return 0;
 }
+IRQCHIP_DECLARE(mmp_intc, "mrvl,mmp-intc", mmp_of_init);
+IRQCHIP_DECLARE(mmp2_intc, "mrvl,mmp2-intc", mmp2_of_init);
+IRQCHIP_DECLARE(mmp2_mux_intc, "mrvl,mmp2-mux-intc", mmp2_mux_of_init);
 #endif
-- 
1.7.10.4



From haojian.zhuang at linaro.org  Sun Apr 21 05:46:57 2013
From: haojian.zhuang at linaro.org (Haojian Zhuang)
Date: Sun, 21 Apr 2013 17:46:57 +0800
Subject: [PATCH 3/3] irqchip: mmp: support MULTI_IRQ_HANDLER
In-Reply-To: <1366537617-11328-1-git-send-email-haojian.zhuang@linaro.org>
References: <1366537617-11328-1-git-send-email-haojian.zhuang@linaro.org>
Message-ID: <1366537617-11328-3-git-send-email-haojian.zhuang@linaro.org>

Support CONFIG_MULTI_IRQ_HANDLER in ARCH_MMP. So remove entry-macro.S.

Signed-off-by: Haojian Zhuang <haojian.zhuang at linaro.org>
---
 arch/arm/Kconfig                             |    1 +
 arch/arm/mach-mmp/include/mach/entry-macro.S |   26 ----------------
 drivers/irqchip/irq-mmp.c                    |   42 +++++++++++++++++++++++++-
 3 files changed, 42 insertions(+), 27 deletions(-)
 delete mode 100644 arch/arm/mach-mmp/include/mach/entry-macro.S

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 8b6694b..832ce62 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -550,6 +550,7 @@ config ARCH_MMP
 	select GENERIC_CLOCKEVENTS
 	select GPIO_PXA
 	select IRQ_DOMAIN
+	select MULTI_IRQ_HANDLER
 	select NEED_MACH_GPIO_H
 	select PINCTRL
 	select PLAT_PXA
diff --git a/arch/arm/mach-mmp/include/mach/entry-macro.S b/arch/arm/mach-mmp/include/mach/entry-macro.S
deleted file mode 100644
index bd152e2..0000000
--- a/arch/arm/mach-mmp/include/mach/entry-macro.S
+++ /dev/null
@@ -1,26 +0,0 @@
-/*
- * linux/arch/arm/mach-mmp/include/mach/entry-macro.S
- *
- * 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 <asm/irq.h>
-#include <mach/regs-icu.h>
-
-	.macro	get_irqnr_preamble, base, tmp
-	mrc	p15, 0, \tmp, c0, c0, 0		@ CPUID
-	and	\tmp, \tmp, #0xff00
-	cmp	\tmp, #0x5800
-	ldr	\base, =mmp_icu_base
-	ldr	\base, [\base, #0]
-	addne	\base, \base, #0x10c		@ PJ1 AP INT SEL register
-	addeq	\base, \base, #0x104		@ PJ4 IRQ SEL register
-	.endm
-
-	.macro	get_irqnr_and_base, irqnr, irqstat, base, tmp
-	ldr	\tmp, [\base, #0]
-	and	\irqnr, \tmp, #0x3f
-	tst	\tmp, #(1 << 6)
-	.endm
diff --git a/drivers/irqchip/irq-mmp.c b/drivers/irqchip/irq-mmp.c
index 2f088ba..f54ebca 100644
--- a/drivers/irqchip/irq-mmp.c
+++ b/drivers/irqchip/irq-mmp.c
@@ -21,6 +21,9 @@
 #include <linux/of_address.h>
 #include <linux/of_irq.h>
 
+#include <asm/exception.h>
+#include <asm/mach/irq.h>
+
 #include <mach/irqs.h>
 
 #ifdef CONFIG_CPU_MMP2
@@ -34,6 +37,13 @@
 
 #define MAX_ICU_NR		16
 
+#define PJ1_INT_SEL		0x10c
+#define PJ4_INT_SEL		0x104
+
+/* bit fields in PJ1_INT_SEL and PJ4_INT_SEL */
+#define SEL_INT_PENDING		(1 << 6)
+#define SEL_INT_NUM_MASK	0x3f
+
 struct icu_chip_data {
 	int			nr_irqs;
 	unsigned int		virq_base;
@@ -54,7 +64,7 @@ struct mmp_intc_conf {
 	unsigned int	conf_mask;
 };
 
-void __iomem *mmp_icu_base;
+static void __iomem *mmp_icu_base;
 static struct icu_chip_data icu_data[MAX_ICU_NR];
 static int max_icu_nr;
 
@@ -193,6 +203,32 @@ static struct mmp_intc_conf mmp2_conf = {
 	.conf_mask	= 0x7f,
 };
 
+static asmlinkage void __exception_irq_entry
+mmp_handle_irq(struct pt_regs *regs)
+{
+	int irq, hwirq;
+
+	hwirq = readl_relaxed(mmp_icu_base + PJ1_INT_SEL);
+	if (!(hwirq & SEL_INT_PENDING))
+		return;
+	hwirq &= SEL_INT_NUM_MASK;
+	irq = irq_find_mapping(icu_data[0].domain, hwirq);
+	handle_IRQ(irq, regs);
+}
+
+static asmlinkage void __exception_irq_entry
+mmp2_handle_irq(struct pt_regs *regs)
+{
+	int irq, hwirq;
+
+	hwirq = readl_relaxed(mmp_icu_base + PJ4_INT_SEL);
+	if (!(hwirq & SEL_INT_PENDING))
+		return;
+	hwirq &= SEL_INT_NUM_MASK;
+	irq = irq_find_mapping(icu_data[0].domain, hwirq);
+	handle_IRQ(irq, regs);
+}
+
 /* MMP (ARMv5) */
 void __init icu_init_irq(void)
 {
@@ -214,6 +250,7 @@ void __init icu_init_irq(void)
 		set_irq_flags(irq, IRQF_VALID);
 	}
 	irq_set_default_host(icu_data[0].domain);
+	set_handle_irq(mmp_handle_irq);
 #ifdef CONFIG_CPU_PXA910
 	icu_irq_chip.irq_set_wake = pxa910_set_wake;
 #endif
@@ -320,6 +357,7 @@ void __init mmp2_init_icu(void)
 		set_irq_flags(irq, IRQF_VALID);
 	}
 	irq_set_default_host(icu_data[0].domain);
+	set_handle_irq(mmp2_handle_irq);
 #ifdef CONFIG_CPU_MMP2
 	icu_irq_chip.irq_set_wake = mmp2_set_wake;
 #endif
@@ -378,6 +416,7 @@ static int __init mmp_of_init(struct device_node *node,
 	icu_data[0].conf_disable = mmp_conf.conf_disable;
 	icu_data[0].conf_mask = mmp_conf.conf_mask;
 	irq_set_default_host(icu_data[0].domain);
+	set_handle_irq(mmp_handle_irq);
 	max_icu_nr = 1;
 	return 0;
 }
@@ -395,6 +434,7 @@ static int __init mmp2_of_init(struct device_node *node,
 	icu_data[0].conf_disable = mmp2_conf.conf_disable;
 	icu_data[0].conf_mask = mmp2_conf.conf_mask;
 	irq_set_default_host(icu_data[0].domain);
+	set_handle_irq(mmp2_handle_irq);
 	max_icu_nr = 1;
 	return 0;
 }
-- 
1.7.10.4



From enash54 at gmail.com  Sun Apr 21 09:50:46 2013
From: enash54 at gmail.com (Ed Nash)
Date: Sun, 21 Apr 2013 13:50:46 +0000 (UTC)
Subject: [PATCH 1/3] ARM/MVF600: add Vybrid Family platform support
References: <1365749825-20601-1-git-send-email-b35083@freescale.com>
 <1365749825-20601-2-git-send-email-b35083@freescale.com>
Message-ID: <loom.20130421T154042-216@post.gmane.org>

Jingchang Lu <b35083 <at> freescale.com> writes:

Hi- I'm new to participating so please be kind if I break protocol.

> diff --git a/arch/arm/mach-imx/mach-mvf600.c 
> b/arch/arm/mach-imx/mach-mvf600.c
> +
> +static void __init mvf_of_init_irq(void)
> +{
> +	struct device_node *np;
> +	void __iomem *mscm_base;
> +	int i;
> +
> +	l2x0_of_init(0, ~0UL);
> +
> +	np = of_find_compatible_node(NULL, NULL, "fsl,mvf-mscm");
> +	mscm_base = of_iomap(np, 0);
> +	if (!mscm_base)
> +		return;
> +
> +	for (i = 0; i < 128; i++)
> +		__raw_writew(1, mscm_base + 0x880 + 2 * i);

This is a problem if the M4 core program boots first and routes any interrupts
to itself. This should be an OR function with the existing bits so as not to
reset M4 bits.





From sfr at canb.auug.org.au  Sun Apr 21 11:12:53 2013
From: sfr at canb.auug.org.au (Stephen Rothwell)
Date: Mon, 22 Apr 2013 01:12:53 +1000
Subject: KVM/ARM in next
In-Reply-To: <CAEDV+gK-84M+6zx_z1z48sNi5UiaELdsbz983tE7GOS25SnymA@mail.gmail.com>
References: <CAEDV+gK-84M+6zx_z1z48sNi5UiaELdsbz983tE7GOS25SnymA@mail.gmail.com>
Message-ID: <20130422011253.9588b1a1e99a69a5991d7268@canb.auug.org.au>

Hi Christoffer,

On Sat, 20 Apr 2013 09:59:20 -0700 Christoffer Dall <cdall at cs.columbia.edu> wrote:
>
> I'm maintaining the KVM/ARM implementation, which was merged during
> the 3.9 merge window.
> 
> I'd like for you to pull changes from my kvm-arm-next branch at
> git://github.com/columbia/linux-kvm-arm.git into linux-next.
> 
> The merge procedure for this tree is typically through the kvm tree,
> but occasionally through Russell King's ARM tree, if there are
> substantial changes to generic ARM code in there.
> 
> In case of problems please notify me and Marc Zyngier <marc.zyngier at arm.com>

I have added your tree from today with you and Marc as contacts.

Thanks for adding your subsystem tree as a participant of linux-next.  As
you may know, this is not a judgment of your code.  The purpose of
linux-next is for integration testing and to lower the impact of
conflicts between subsystems in the next merge window. 

You will need to ensure that the patches/commits in your tree/series have
been:
     * submitted under GPL v2 (or later) and include the Contributor's
	Signed-off-by,
     * posted to the relevant mailing list,
     * reviewed by you (or another maintainer of your subsystem tree),
     * successfully unit tested, and 
     * destined for the current or next Linux merge window.

Basically, this should be just what you would send to Linus (or ask him
to fetch).  It is allowed to be rebased if you deem it necessary.

-- 
Cheers,
Stephen Rothwell 
sfr at canb.auug.org.au

Legal Stuff:
By participating in linux-next, your subsystem tree contributions are
public and will be included in the linux-next trees.  You may be sent
e-mail messages indicating errors or other issues when the
patches/commits from your subsystem tree are merged and tested in
linux-next.  These messages may also be cross-posted to the linux-next
mailing list, the linux-kernel mailing list, etc.  The linux-next tree
project and IBM (my employer) make no warranties regarding the linux-next
project, the testing procedures, the results, the e-mails, etc.  If you
don't agree to these ground rules, let me know and I'll remove your tree
from participation in linux-next.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130422/0614f363/attachment.sig>

From tbm at cyrius.com  Sun Apr 21 11:28:02 2013
From: tbm at cyrius.com (Martin Michlmayr)
Date: Sun, 21 Apr 2013 16:28:02 +0100
Subject: [PATCH] Enable PCIe port 1 on QNAP TS-11x/TS-21x
Message-ID: <20130421152802.GA1408@jirafa.cyrius.com>

Enable KW_PCIE1 on QNAP TS-11x/TS-21x devices as newer revisions
(rev 1.3) have a USB 3.0 chip from Etron on PCIe port 1.  Thanks
to Marek Vasut for identifying this issue!

Cc: <stable at kernel.org>
Signed-off-by: Martin Michlmayr <tbm at cyrius.com>
Tested-by: Marek Vasut <marex at denx.de>

diff --git a/arch/arm/mach-kirkwood/board-ts219.c b/arch/arm/mach-kirkwood/board-ts219.c
index acb0187..651e6b3 100644
--- a/arch/arm/mach-kirkwood/board-ts219.c
+++ b/arch/arm/mach-kirkwood/board-ts219.c
@@ -46,7 +46,7 @@ void __init qnap_dt_ts219_init(void)
 static int __init ts219_pci_init(void)
 {
 	if (machine_is_ts219())
-		kirkwood_pcie_init(KW_PCIE0);
+		kirkwood_pcie_init(KW_PCIE1 | KW_PCIE0);
 
 	return 0;
 }
diff --git a/arch/arm/mach-kirkwood/ts219-setup.c b/arch/arm/mach-kirkwood/ts219-setup.c
index 283abff..e1267d6 100644
--- a/arch/arm/mach-kirkwood/ts219-setup.c
+++ b/arch/arm/mach-kirkwood/ts219-setup.c
@@ -124,7 +124,7 @@ static void __init qnap_ts219_init(void)
 static int __init ts219_pci_init(void)
 {
 	if (machine_is_ts219())
-		kirkwood_pcie_init(KW_PCIE0);
+		kirkwood_pcie_init(KW_PCIE1 | KW_PCIE0);
 
 	return 0;
 }

-- 
Martin Michlmayr
http://www.cyrius.com/


From andrew at lunn.ch  Sun Apr 21 11:47:04 2013
From: andrew at lunn.ch (Andrew Lunn)
Date: Sun, 21 Apr 2013 17:47:04 +0200
Subject: [PATCH] Enable PCIe port 1 on QNAP TS-11x/TS-21x
In-Reply-To: <20130421152802.GA1408@jirafa.cyrius.com>
References: <20130421152802.GA1408@jirafa.cyrius.com>
Message-ID: <20130421154704.GV2824@lunn.ch>

On Sun, Apr 21, 2013 at 04:28:02PM +0100, Martin Michlmayr wrote:
> Enable KW_PCIE1 on QNAP TS-11x/TS-21x devices as newer revisions
> (rev 1.3) have a USB 3.0 chip from Etron on PCIe port 1.  Thanks
> to Marek Vasut for identifying this issue!
> 
> Cc: <stable at kernel.org>
> Signed-off-by: Martin Michlmayr <tbm at cyrius.com>
> Tested-by: Marek Vasut <marex at denx.de>
> 
> diff --git a/arch/arm/mach-kirkwood/board-ts219.c b/arch/arm/mach-kirkwood/board-ts219.c
> index acb0187..651e6b3 100644
> --- a/arch/arm/mach-kirkwood/board-ts219.c
> +++ b/arch/arm/mach-kirkwood/board-ts219.c
> @@ -46,7 +46,7 @@ void __init qnap_dt_ts219_init(void)
>  static int __init ts219_pci_init(void)
>  {
>  	if (machine_is_ts219())
> -		kirkwood_pcie_init(KW_PCIE0);
> +		kirkwood_pcie_init(KW_PCIE1 | KW_PCIE0);
>  

Hi Martin

For the DT based board, this will not help. Did you notice the FIXME?

Now that i know both ports are needed, i will fix the DT for 3.11 when
we introduce PCI bindings via DT.

>  	return 0;
>  }
> diff --git a/arch/arm/mach-kirkwood/ts219-setup.c b/arch/arm/mach-kirkwood/ts219-setup.c
> index 283abff..e1267d6 100644
> --- a/arch/arm/mach-kirkwood/ts219-setup.c
> +++ b/arch/arm/mach-kirkwood/ts219-setup.c
> @@ -124,7 +124,7 @@ static void __init qnap_ts219_init(void)
>  static int __init ts219_pci_init(void)
>  {
>  	if (machine_is_ts219())
> -		kirkwood_pcie_init(KW_PCIE0);
> +		kirkwood_pcie_init(KW_PCIE1 | KW_PCIE0);

This looks correct. Please could you submit a new version with just
this hunk. Since its a fix, we can probably get it quickly into 3.10
and then into stable.

Thanks
	Andrew


From tbm at cyrius.com  Sun Apr 21 12:12:42 2013
From: tbm at cyrius.com (Martin Michlmayr)
Date: Sun, 21 Apr 2013 17:12:42 +0100
Subject: [PATCH] Enable PCIe port 1 on QNAP TS-11x/TS-21x
In-Reply-To: <20130421154704.GV2824@lunn.ch>
References: <20130421152802.GA1408@jirafa.cyrius.com>
 <20130421154704.GV2824@lunn.ch>
Message-ID: <20130421161241.GC26943@jirafa.cyrius.com>

* Andrew Lunn <andrew at lunn.ch> [2013-04-21 17:47]:
> For the DT based board, this will not help. Did you notice the FIXME?

Yes, and I've read your discussions about this topic in the meantime.

I'll send a new patch for the non-DT case only since this is what's
relevant for current kernels.

> Now that i know both ports are needed, i will fix the DT for 3.11 when
> we introduce PCI bindings via DT.

Thanks.
-- 
Martin Michlmayr
http://www.cyrius.com/


From tbm at cyrius.com  Sun Apr 21 12:14:00 2013
From: tbm at cyrius.com (Martin Michlmayr)
Date: Sun, 21 Apr 2013 17:14:00 +0100
Subject: [PATCH] Kirkwood: Enable PCIe port 1 on QNAP TS-11x/TS-21x
In-Reply-To: <20130421154704.GV2824@lunn.ch>
References: <20130421152802.GA1408@jirafa.cyrius.com>
 <20130421154704.GV2824@lunn.ch>
Message-ID: <20130421161400.GD26943@jirafa.cyrius.com>

Enable KW_PCIE1 on QNAP TS-11x/TS-21x devices as newer revisions
(rev 1.3) have a USB 3.0 chip from Etron on PCIe port 1.  Thanks
to Marek Vasut for identifying this issue!

Cc: <stable at kernel.org>
Signed-off-by: Martin Michlmayr <tbm at cyrius.com>
Tested-by: Marek Vasut <marex at denx.de>

diff --git a/arch/arm/mach-kirkwood/ts219-setup.c b/arch/arm/mach-kirkwood/ts219-setup.c
index 283abff..e1267d6 100644
--- a/arch/arm/mach-kirkwood/ts219-setup.c
+++ b/arch/arm/mach-kirkwood/ts219-setup.c
@@ -124,7 +124,7 @@ static void __init qnap_ts219_init(void)
 static int __init ts219_pci_init(void)
 {
 	if (machine_is_ts219())
-		kirkwood_pcie_init(KW_PCIE0);
+		kirkwood_pcie_init(KW_PCIE1 | KW_PCIE0);
 
 	return 0;
 }

-- 
Martin Michlmayr
http://www.cyrius.com/


From andrew at lunn.ch  Sun Apr 21 13:03:40 2013
From: andrew at lunn.ch (Andrew Lunn)
Date: Sun, 21 Apr 2013 19:03:40 +0200
Subject: [PATCH] Kirkwood: Enable PCIe port 1 on QNAP TS-11x/TS-21x
In-Reply-To: <20130421161400.GD26943@jirafa.cyrius.com>
References: <20130421152802.GA1408@jirafa.cyrius.com>
 <20130421154704.GV2824@lunn.ch>
 <20130421161400.GD26943@jirafa.cyrius.com>
Message-ID: <20130421170340.GX2824@lunn.ch>

On Sun, Apr 21, 2013 at 05:14:00PM +0100, Martin Michlmayr wrote:
> Enable KW_PCIE1 on QNAP TS-11x/TS-21x devices as newer revisions
> (rev 1.3) have a USB 3.0 chip from Etron on PCIe port 1.  Thanks
> to Marek Vasut for identifying this issue!
> 
> Cc: <stable at kernel.org>
> Signed-off-by: Martin Michlmayr <tbm at cyrius.com>
> Tested-by: Marek Vasut <marex at denx.de>
> 
> diff --git a/arch/arm/mach-kirkwood/ts219-setup.c b/arch/arm/mach-kirkwood/ts219-setup.c
> index 283abff..e1267d6 100644
> --- a/arch/arm/mach-kirkwood/ts219-setup.c
> +++ b/arch/arm/mach-kirkwood/ts219-setup.c
> @@ -124,7 +124,7 @@ static void __init qnap_ts219_init(void)
>  static int __init ts219_pci_init(void)
>  {
>  	if (machine_is_ts219())
> -		kirkwood_pcie_init(KW_PCIE0);
> +		kirkwood_pcie_init(KW_PCIE1 | KW_PCIE0);
>  
>  	return 0;
>  }

Acked-by: Andrew Lunn <andrew at lunn.ch>

	  Andrew


From heiko at sntech.de  Sun Apr 21 14:02:30 2013
From: heiko at sntech.de (Heiko =?utf-8?q?St=C3=BCbner?=)
Date: Sun, 21 Apr 2013 20:02:30 +0200
Subject: [PATCH 0/3] ARM: S3C24XX: dma cleanups for s3c2412 and s3c2443
Message-ID: <201304212002.31082.heiko@sntech.de>

The s3c2412 uses the same dma channel selection-type as the s3c2443 and later
but introduced the notion of a receive channel to keep the spi channels,
together that are separate in hardware.

This series split the spi channels like later socs do (the s3c24xx-spi driver
does not use dma at all) and removes this type of special handling.

Heiko Stuebner (3):
  ARM: S3C24XX: split s3c2412 spi dma channels
  ARM: S3C24XX: dma-s3c2443 - do not write into arbitary bits
  ARM: S3C24XX: remove obsolete s3c2412 specific dma settings

 arch/arm/mach-s3c24xx/dma-s3c2412.c              |   56 ++++++----------------
 arch/arm/mach-s3c24xx/dma-s3c2443.c              |    3 +-
 arch/arm/mach-s3c24xx/dma.c                      |    3 -
 arch/arm/plat-samsung/include/plat/dma-s3c24xx.h |    5 --
 4 files changed, 17 insertions(+), 50 deletions(-)

-- 
1.7.2.3



From heiko at sntech.de  Sun Apr 21 14:03:18 2013
From: heiko at sntech.de (Heiko =?utf-8?q?St=C3=BCbner?=)
Date: Sun, 21 Apr 2013 20:03:18 +0200
Subject: [PATCH 1/3] ARM: S3C24XX: split s3c2412 spi dma channels
In-Reply-To: <201304212002.31082.heiko@sntech.de>
References: <201304212002.31082.heiko@sntech.de>
Message-ID: <201304212003.19031.heiko@sntech.de>

While s3c24xx before s3c2412 (2410, 2440, 2442) use one dma channel
for both sending and receiving spi data, all later s3c24xx socs use
separate channels.

To keep with the structure of "one spi channel" s3c2412 introduced
a channel_rx attribute to the map and selects the correct request
channel depending on the dma direction, hiding the underlying
separation from view.

The s3c24xx-spi driver, which would need this, currently does not
use dma at all, but as s3c2443 has both highspeed (spi0) and regular
(spi1) controllers and also uses the split scheme a future dma support
for s3c24xx-spi would in any case need to differentiate between
old-style and new-style spi channel structure.

Thus we can swtch to the split channel structure like in later socs.

Signed-off-by: Heiko Stuebner <heiko at sntech.de>
---
 arch/arm/mach-s3c24xx/dma-s3c2412.c |   22 ++++++++++++++++------
 1 files changed, 16 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-s3c24xx/dma-s3c2412.c b/arch/arm/mach-s3c24xx/dma-s3c2412.c
index c0e8c3f..8d8a679 100644
--- a/arch/arm/mach-s3c24xx/dma-s3c2412.c
+++ b/arch/arm/mach-s3c24xx/dma-s3c2412.c
@@ -49,16 +49,26 @@ static struct s3c24xx_dma_map __initdata s3c2412_dma_mappings[] = {
 		.channels	= MAP(S3C2412_DMAREQSEL_SDI),
 		.channels_rx	= MAP(S3C2412_DMAREQSEL_SDI),
 	},
-	[DMACH_SPI0] = {
-		.name		= "spi0",
-		.channels	= MAP(S3C2412_DMAREQSEL_SPI0TX),
+	[DMACH_SPI0_RX] = {
+		.name		= "spi0-rx",
+		.channels	= MAP(S3C2412_DMAREQSEL_SPI0RX),
 		.channels_rx	= MAP(S3C2412_DMAREQSEL_SPI0RX),
 	},
-	[DMACH_SPI1] = {
-		.name		= "spi1",
-		.channels	= MAP(S3C2412_DMAREQSEL_SPI1TX),
+	[DMACH_SPI0_TX] = {
+		.name		= "spi0-tx",
+		.channels	= MAP(S3C2412_DMAREQSEL_SPI0TX),
+		.channels_rx	= MAP(S3C2412_DMAREQSEL_SPI0TX),
+	},
+	[DMACH_SPI1_RX] = {
+		.name		= "spi1-rx",
+		.channels	= MAP(S3C2412_DMAREQSEL_SPI1RX),
 		.channels_rx	= MAP(S3C2412_DMAREQSEL_SPI1RX),
 	},
+	[DMACH_SPI1_TX] = {
+		.name		= "spi1-tx",
+		.channels	= MAP(S3C2412_DMAREQSEL_SPI1TX),
+		.channels_rx	= MAP(S3C2412_DMAREQSEL_SPI1TX),
+	},
 	[DMACH_UART0] = {
 		.name		= "uart0",
 		.channels	= MAP(S3C2412_DMAREQSEL_UART0_0),
-- 
1.7.2.3



From heiko at sntech.de  Sun Apr 21 14:04:03 2013
From: heiko at sntech.de (Heiko =?utf-8?q?St=C3=BCbner?=)
Date: Sun, 21 Apr 2013 20:04:03 +0200
Subject: [PATCH 2/3] ARM: S3C24XX: dma-s3c2443 - do not write into arbitary
 bits
In-Reply-To: <201304212002.31082.heiko@sntech.de>
References: <201304212002.31082.heiko@sntech.de>
Message-ID: <201304212004.03459.heiko@sntech.de>

The values read from the channel map always also contain the
DMA_CH_VALID (= 1<<31) setting, which should not get written
into the register, even if this bit is unused.

Signed-off-by: Heiko Stuebner <heiko at sntech.de>
---
 arch/arm/mach-s3c24xx/dma-s3c2443.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-s3c24xx/dma-s3c2443.c b/arch/arm/mach-s3c24xx/dma-s3c2443.c
index 000e4c6..e992a7c 100644
--- a/arch/arm/mach-s3c24xx/dma-s3c2443.c
+++ b/arch/arm/mach-s3c24xx/dma-s3c2443.c
@@ -130,7 +130,8 @@ static struct s3c24xx_dma_map __initdata s3c2443_dma_mappings[] = {
 static void s3c2443_dma_select(struct s3c2410_dma_chan *chan,
 			       struct s3c24xx_dma_map *map)
 {
-	writel(map->channels[0] | S3C2443_DMAREQSEL_HW,
+	unsigned long chsel = map->channels[0] & (~DMA_CH_VALID);
+	writel(chsel | S3C2443_DMAREQSEL_HW,
 	       chan->regs + S3C2443_DMA_DMAREQSEL);
 }
 
-- 
1.7.2.3



From heiko at sntech.de  Sun Apr 21 14:04:33 2013
From: heiko at sntech.de (Heiko =?utf-8?q?St=C3=BCbner?=)
Date: Sun, 21 Apr 2013 20:04:33 +0200
Subject: [PATCH 3/3] ARM: S3C24XX: remove obsolete s3c2412 specific dma
 settings
In-Reply-To: <201304212002.31082.heiko@sntech.de>
References: <201304212002.31082.heiko@sntech.de>
Message-ID: <201304212004.33544.heiko@sntech.de>

The s3c2412 dma init contained code to handle dma-direction specific
settings. As now all s3c2412-dma-channels are direction-independent this
is not needed anymore.

As the s3c2412 also was the only user of this, it can go away completely.

Signed-off-by: Heiko Stuebner <heiko at sntech.de>
---
 arch/arm/mach-s3c24xx/dma-s3c2412.c              |   42 ++--------------------
 arch/arm/mach-s3c24xx/dma.c                      |    3 --
 arch/arm/plat-samsung/include/plat/dma-s3c24xx.h |    5 ---
 3 files changed, 3 insertions(+), 47 deletions(-)

diff --git a/arch/arm/mach-s3c24xx/dma-s3c2412.c b/arch/arm/mach-s3c24xx/dma-s3c2412.c
index 8d8a679..9950400 100644
--- a/arch/arm/mach-s3c24xx/dma-s3c2412.c
+++ b/arch/arm/mach-s3c24xx/dma-s3c2412.c
@@ -37,131 +37,95 @@ static struct s3c24xx_dma_map __initdata s3c2412_dma_mappings[] = {
 	[DMACH_XD0] = {
 		.name		= "xdreq0",
 		.channels	= MAP(S3C2412_DMAREQSEL_XDREQ0),
-		.channels_rx	= MAP(S3C2412_DMAREQSEL_XDREQ0),
 	},
 	[DMACH_XD1] = {
 		.name		= "xdreq1",
 		.channels	= MAP(S3C2412_DMAREQSEL_XDREQ1),
-		.channels_rx	= MAP(S3C2412_DMAREQSEL_XDREQ1),
 	},
 	[DMACH_SDI] = {
 		.name		= "sdi",
 		.channels	= MAP(S3C2412_DMAREQSEL_SDI),
-		.channels_rx	= MAP(S3C2412_DMAREQSEL_SDI),
 	},
 	[DMACH_SPI0_RX] = {
 		.name		= "spi0-rx",
 		.channels	= MAP(S3C2412_DMAREQSEL_SPI0RX),
-		.channels_rx	= MAP(S3C2412_DMAREQSEL_SPI0RX),
 	},
 	[DMACH_SPI0_TX] = {
 		.name		= "spi0-tx",
 		.channels	= MAP(S3C2412_DMAREQSEL_SPI0TX),
-		.channels_rx	= MAP(S3C2412_DMAREQSEL_SPI0TX),
 	},
 	[DMACH_SPI1_RX] = {
 		.name		= "spi1-rx",
 		.channels	= MAP(S3C2412_DMAREQSEL_SPI1RX),
-		.channels_rx	= MAP(S3C2412_DMAREQSEL_SPI1RX),
 	},
 	[DMACH_SPI1_TX] = {
 		.name		= "spi1-tx",
 		.channels	= MAP(S3C2412_DMAREQSEL_SPI1TX),
-		.channels_rx	= MAP(S3C2412_DMAREQSEL_SPI1TX),
 	},
 	[DMACH_UART0] = {
 		.name		= "uart0",
 		.channels	= MAP(S3C2412_DMAREQSEL_UART0_0),
-		.channels_rx	= MAP(S3C2412_DMAREQSEL_UART0_0),
 	},
 	[DMACH_UART1] = {
 		.name		= "uart1",
 		.channels	= MAP(S3C2412_DMAREQSEL_UART1_0),
-		.channels_rx	= MAP(S3C2412_DMAREQSEL_UART1_0),
 	},
       	[DMACH_UART2] = {
 		.name		= "uart2",
 		.channels	= MAP(S3C2412_DMAREQSEL_UART2_0),
-		.channels_rx	= MAP(S3C2412_DMAREQSEL_UART2_0),
 	},
 	[DMACH_UART0_SRC2] = {
 		.name		= "uart0",
 		.channels	= MAP(S3C2412_DMAREQSEL_UART0_1),
-		.channels_rx	= MAP(S3C2412_DMAREQSEL_UART0_1),
 	},
 	[DMACH_UART1_SRC2] = {
 		.name		= "uart1",
 		.channels	= MAP(S3C2412_DMAREQSEL_UART1_1),
-		.channels_rx	= MAP(S3C2412_DMAREQSEL_UART1_1),
 	},
       	[DMACH_UART2_SRC2] = {
 		.name		= "uart2",
 		.channels	= MAP(S3C2412_DMAREQSEL_UART2_1),
-		.channels_rx	= MAP(S3C2412_DMAREQSEL_UART2_1),
 	},
 	[DMACH_TIMER] = {
 		.name		= "timer",
 		.channels	= MAP(S3C2412_DMAREQSEL_TIMER),
-		.channels_rx	= MAP(S3C2412_DMAREQSEL_TIMER),
 	},
 	[DMACH_I2S_IN] = {
 		.name		= "i2s-sdi",
 		.channels	= MAP(S3C2412_DMAREQSEL_I2SRX),
-		.channels_rx	= MAP(S3C2412_DMAREQSEL_I2SRX),
 	},
 	[DMACH_I2S_OUT] = {
 		.name		= "i2s-sdo",
 		.channels	= MAP(S3C2412_DMAREQSEL_I2STX),
-		.channels_rx	= MAP(S3C2412_DMAREQSEL_I2STX),
 	},
 	[DMACH_USB_EP1] = {
 		.name		= "usb-ep1",
 		.channels	= MAP(S3C2412_DMAREQSEL_USBEP1),
-		.channels_rx	= MAP(S3C2412_DMAREQSEL_USBEP1),
 	},
 	[DMACH_USB_EP2] = {
 		.name		= "usb-ep2",
 		.channels	= MAP(S3C2412_DMAREQSEL_USBEP2),
-		.channels_rx	= MAP(S3C2412_DMAREQSEL_USBEP2),
 	},
 	[DMACH_USB_EP3] = {
 		.name		= "usb-ep3",
 		.channels	= MAP(S3C2412_DMAREQSEL_USBEP3),
-		.channels_rx	= MAP(S3C2412_DMAREQSEL_USBEP3),
 	},
 	[DMACH_USB_EP4] = {
 		.name		= "usb-ep4",
 		.channels	= MAP(S3C2412_DMAREQSEL_USBEP4),
-		.channels_rx	= MAP(S3C2412_DMAREQSEL_USBEP4),
 	},
 };
 
-static void s3c2412_dma_direction(struct s3c2410_dma_chan *chan,
-				  struct s3c24xx_dma_map *map,
-				  enum dma_data_direction dir)
-{
-	unsigned long chsel;
-
-	if (dir == DMA_FROM_DEVICE)
-		chsel = map->channels_rx[0];
-	else
-		chsel = map->channels[0];
-
-	chsel &= ~DMA_CH_VALID;
-	chsel |= S3C2412_DMAREQSEL_HW;
-
-	writel(chsel, chan->regs + S3C2412_DMA_DMAREQSEL);
-}
-
 static void s3c2412_dma_select(struct s3c2410_dma_chan *chan,
 			       struct s3c24xx_dma_map *map)
 {
-	s3c2412_dma_direction(chan, map, chan->source);
+	unsigned long chsel = map->channels[0] & (~DMA_CH_VALID);
+	writel(chsel | S3C2412_DMAREQSEL_HW,
+	       chan->regs + S3C2412_DMA_DMAREQSEL);
 }
 
 static struct s3c24xx_dma_selection __initdata s3c2412_dma_sel = {
 	.select		= s3c2412_dma_select,
-	.direction	= s3c2412_dma_direction,
 	.dcon_mask	= 0,
 	.map		= s3c2412_dma_mappings,
 	.map_size	= ARRAY_SIZE(s3c2412_dma_mappings),
diff --git a/arch/arm/mach-s3c24xx/dma.c b/arch/arm/mach-s3c24xx/dma.c
index aab6490..4a65cba 100644
--- a/arch/arm/mach-s3c24xx/dma.c
+++ b/arch/arm/mach-s3c24xx/dma.c
@@ -1159,9 +1159,6 @@ int s3c2410_dma_devconfig(enum dma_ch channel,
 		return -EINVAL;
 	}
 
-	if (dma_sel.direction != NULL)
-		(dma_sel.direction)(chan, chan->map, source);
-
 	return 0;
 }
 
diff --git a/arch/arm/plat-samsung/include/plat/dma-s3c24xx.h b/arch/arm/plat-samsung/include/plat/dma-s3c24xx.h
index d015763..bd3a6db 100644
--- a/arch/arm/plat-samsung/include/plat/dma-s3c24xx.h
+++ b/arch/arm/plat-samsung/include/plat/dma-s3c24xx.h
@@ -28,7 +28,6 @@ struct s3c24xx_dma_map {
 	const char		*name;
 
 	unsigned long		 channels[S3C_DMA_CHANNELS];
-	unsigned long		 channels_rx[S3C_DMA_CHANNELS];
 };
 
 struct s3c24xx_dma_selection {
@@ -38,10 +37,6 @@ struct s3c24xx_dma_selection {
 
 	void	(*select)(struct s3c2410_dma_chan *chan,
 			  struct s3c24xx_dma_map *map);
-
-	void	(*direction)(struct s3c2410_dma_chan *chan,
-			     struct s3c24xx_dma_map *map,
-			     enum dma_data_direction dir);
 };
 
 extern int s3c24xx_dma_init_map(struct s3c24xx_dma_selection *sel);
-- 
1.7.2.3



From sergei.shtylyov at cogentembedded.com  Sun Apr 21 14:37:22 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Sun, 21 Apr 2013 22:37:22 +0400
Subject: [PATCH v2 0/5] OKI ML86V7667 driver and R8A7778/BOCK-W VIN support
Message-ID: <201304212237.23500.sergei.shtylyov@cogentembedded.com>

Hello.

   Here's the set of 5 patches against the Simon Horman's 'renesas.git' repo,
'renesas-next-20130419' tag and my recent yet unapplied patches. Here we
add the OKI ML86V7667 video decoder driver and the VIN platform code working on
the R8A7778/BOCK-W with ML86V7667. The driver patch also applies (with offsets)
to Mauro's 'media_tree.git'...

[1/5] V4L2: I2C: ML86V7667 video decoder driver
[2/5] sh-pfc: r8a7778: add VIN pin groups
[3/5] ARM: shmobile: r8a7778: add VIN support
[4/5] ARM: shmobile: BOCK-W: add VIN and ML86V7667 support
[5/5] ARM: shmobile: BOCK-W: enable VIN and ML86V7667 in defconfig

WBR, Sergei


From sergei.shtylyov at cogentembedded.com  Sun Apr 21 14:42:02 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Sun, 21 Apr 2013 22:42:02 +0400
Subject: [PATCH v2 3/5] ARM: shmobile: r8a7778: add VIN support
Message-ID: <201304212242.03076.sergei.shtylyov@cogentembedded.com>

From: Vladimir Barinov <vladimir.barinov at cogentembedded.com>

Add VIN clocks and platform devices on R8A7778 SoC; add function to register
the VIN platform devices.

Signed-off-by: Vladimir Barinov <vladimir.barinov at cogentembedded.com>
[Sergei: added 'id' parameter check to r8a7779_add_vin_device(), used '*pdata'
in *sizeof* operator there, renamed some variables, marked 'vin[01]_info' as
'__initdata'.]
Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

---
 arch/arm/mach-shmobile/clock-r8a7778.c        |    5 +++
 arch/arm/mach-shmobile/include/mach/r8a7778.h |    3 ++
 arch/arm/mach-shmobile/setup-r8a7778.c        |   33 ++++++++++++++++++++++++++
 3 files changed, 41 insertions(+)

Index: renesas/arch/arm/mach-shmobile/clock-r8a7778.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/clock-r8a7778.c
+++ renesas/arch/arm/mach-shmobile/clock-r8a7778.c
@@ -106,6 +106,7 @@ static struct clk *main_clks[] = {
 enum {
 	MSTP323, MSTP322, MSTP321,
 	MSTP114,
+	MSTP110, MSTP109,
 	MSTP100,
 	MSTP030, MSTP029,
 	MSTP028, MSTP027, MSTP026, MSTP025, MSTP024, MSTP023, MSTP022, MSTP021,
@@ -117,6 +118,8 @@ static struct clk mstp_clks[MSTP_NR] = {
 	[MSTP322] = SH_CLK_MSTP32(&p_clk, MSTPCR3, 22, 0), /* SDHI1 */
 	[MSTP321] = SH_CLK_MSTP32(&p_clk, MSTPCR3, 21, 0), /* SDHI2 */
 	[MSTP114] = SH_CLK_MSTP32(&p_clk, MSTPCR1, 14, 0), /* Ether */
+	[MSTP110] = SH_CLK_MSTP32(&s_clk, MSTPCR1, 10, 0), /* VIN0 */
+	[MSTP109] = SH_CLK_MSTP32(&s_clk, MSTPCR1,  9, 0), /* VIN1 */
 	[MSTP100] = SH_CLK_MSTP32(&p_clk, MSTPCR1,  0, 0), /* USB0/1 */
 	[MSTP030] = SH_CLK_MSTP32(&p_clk, MSTPCR0, 30, 0), /* I2C0 */
 	[MSTP029] = SH_CLK_MSTP32(&p_clk, MSTPCR0, 29, 0), /* I2C1 */
@@ -140,6 +143,8 @@ static struct clk_lookup lookups[] = {
 	CLKDEV_DEV_ID("sh_mobile_sdhi.1", &mstp_clks[MSTP322]), /* SDHI1 */
 	CLKDEV_DEV_ID("sh_mobile_sdhi.2", &mstp_clks[MSTP321]), /* SDHI2 */
 	CLKDEV_DEV_ID("sh-eth",	&mstp_clks[MSTP114]), /* Ether */
+	CLKDEV_DEV_ID("rcar_vin.0", &mstp_clks[MSTP110]), /* VIN0 */
+	CLKDEV_DEV_ID("rcar_vin.1", &mstp_clks[MSTP109]), /* VIN1 */
 	CLKDEV_DEV_ID("ehci-platform", &mstp_clks[MSTP100]), /* USB EHCI port0/1 */
 	CLKDEV_DEV_ID("ohci-platform", &mstp_clks[MSTP100]), /* USB OHCI port0/1 */
 	CLKDEV_DEV_ID("i2c-rcar.0", &mstp_clks[MSTP030]), /* I2C0 */
Index: renesas/arch/arm/mach-shmobile/include/mach/r8a7778.h
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/include/mach/r8a7778.h
+++ renesas/arch/arm/mach-shmobile/include/mach/r8a7778.h
@@ -21,11 +21,14 @@
 #include <linux/mmc/sh_mobile_sdhi.h>
 #include <linux/sh_eth.h>
 #include <linux/usb/rcar-phy.h>
+#include <linux/platform_data/camera-rcar.h>
 
 extern void r8a7778_add_standard_devices(void);
 extern void r8a7778_add_standard_devices_dt(void);
 extern void r8a7778_add_ether_device(struct sh_eth_plat_data *pdata);
 extern void r8a7778_add_usb_phy_device(struct rcar_phy_platform_data *pdata);
+extern void r8a7778_add_vin_device(int id,
+				   struct rcar_vin_platform_data *pdata);
 extern void r8a7778_init_late(void);
 extern void r8a7778_init_delay(void);
 extern void r8a7778_init_irq(void);
Index: renesas/arch/arm/mach-shmobile/setup-r8a7778.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/setup-r8a7778.c
+++ renesas/arch/arm/mach-shmobile/setup-r8a7778.c
@@ -265,6 +265,39 @@ void __init r8a7778_sdhi_init(int id,
 		info, sizeof(*info));
 }
 
+/* VIN */
+#define R8A7778_VIN(idx)						\
+static struct resource vin##idx##_resources[] = {			\
+	DEFINE_RES_MEM(0xffc50000 + 0x1000 * (idx), 0x1000),		\
+	DEFINE_RES_IRQ(gic_iid(0x5a)),					\
+};									\
+									\
+static struct platform_device_info vin##idx##_info __initdata = {	\
+	.parent		= &platform_bus,				\
+	.name		= "rcar_vin",					\
+	.id		= idx,						\
+	.res		= vin##idx##_resources,				\
+	.num_res	= ARRAY_SIZE(vin##idx##_resources),		\
+	.dma_mask	= DMA_BIT_MASK(32),				\
+}
+
+R8A7778_VIN(0);
+R8A7778_VIN(1);
+
+static struct platform_device_info *vin_info_table[] __initdata = {
+	&vin0_info,
+	&vin1_info,
+};
+
+void __init r8a7778_add_vin_device(int id, struct rcar_vin_platform_data *pdata)
+{
+	BUG_ON(id < 0 || id > 1);
+
+	vin_info_table[id]->data = pdata;
+	vin_info_table[id]->size_data = sizeof(*pdata);
+	platform_device_register_full(vin_info_table[id]);
+}
+
 void __init r8a7778_add_standard_devices(void)
 {
 	int i;


From sergei.shtylyov at cogentembedded.com  Sun Apr 21 14:42:39 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Sun, 21 Apr 2013 22:42:39 +0400
Subject: [PATCH v2 4/5] ARM: shmobile: BOCK-W: add VIN and ML86V7667 support
Message-ID: <201304212242.39693.sergei.shtylyov@cogentembedded.com>

From: Vladimir Barinov <vladimir.barinov at cogentembedded.com>

Add ML86V7667 platform devices on BOCK-W board, configure VIN0/1 pins, and
register VIN0/1 devices with the ML86V7667 specific platform data.

Signed-off-by: Vladimir Barinov <vladimir.barinov at cogentembedded.com>
[Sergei: some macro/comment cleanup; updated the copyrights.]
Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

---
 arch/arm/mach-shmobile/board-bockw.c |   40 +++++++++++++++++++++++++++++++++++
 1 file changed, 40 insertions(+)

Index: renesas/arch/arm/mach-shmobile/board-bockw.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/board-bockw.c
+++ renesas/arch/arm/mach-shmobile/board-bockw.c
@@ -3,6 +3,7 @@
  *
  * Copyright (C) 2013  Renesas Solutions Corp.
  * Copyright (C) 2013  Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
+ * Copyright (C) 2013  Cogent Embedded, Inc.
  *
  * 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
@@ -23,6 +24,8 @@
 #include <linux/regulator/fixed.h>
 #include <linux/regulator/machine.h>
 #include <linux/smsc911x.h>
+#include <linux/pinctrl/machine.h>
+#include <media/soc_camera.h>
 #include <mach/common.h>
 #include <mach/irqs.h>
 #include <mach/r8a7778.h>
@@ -56,12 +59,41 @@ static struct resource smsc911x_resource
 
 static struct rcar_phy_platform_data usb_phy_platform_data;
 
+static struct rcar_vin_platform_data vin_platform_data = {
+	.flags	= RCAR_VIN_BT656,
+};
+
+/* In the default configuration both decoders reside on I2C bus 0 */
+#define BOCKW_CAMERA(idx)						\
+static struct i2c_board_info camera##idx##_info = {			\
+	I2C_BOARD_INFO("ml86v7667", 0x41 + 2 * (idx)),			\
+};									\
+									\
+static struct soc_camera_link iclink##idx##_ml86v7667 = {		\
+	.bus_id		= idx,						\
+	.i2c_adapter_id	= 0,						\
+	.board_info	= &camera##idx##_info,				\
+};
+
+BOCKW_CAMERA(0);
+BOCKW_CAMERA(1);
+
 static const struct pinctrl_map bockw_pinctrl_map[] = {
 	/* SCIF0 */
 	PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.0", "pfc-r8a7778",
 				  "scif0_data_a", "scif0"),
 	PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.0", "pfc-r8a7778",
 				  "scif0_ctrl", "scif0"),
+	/* VIN0 */
+	PIN_MAP_MUX_GROUP_DEFAULT("rcar_vin.0", "pfc-r8a7778",
+				  "vin0_clk", "vin0"),
+	PIN_MAP_MUX_GROUP_DEFAULT("rcar_vin.0", "pfc-r8a7778",
+				  "vin0_data8", "vin0"),
+	/* VIN1 */
+	PIN_MAP_MUX_GROUP_DEFAULT("rcar_vin.1", "pfc-r8a7778",
+				  "vin1_clk", "vin1"),
+	PIN_MAP_MUX_GROUP_DEFAULT("rcar_vin.1", "pfc-r8a7778",
+				  "vin1_data8", "vin1"),
 };
 
 #define FPGA	0x18200000
@@ -74,6 +106,14 @@ static void __init bockw_init(void)
 	r8a7778_init_irq_extpin(1);
 	r8a7778_add_standard_devices();
 	r8a7778_add_usb_phy_device(&usb_phy_platform_data);
+	r8a7778_add_vin_device(0, &vin_platform_data);
+	r8a7778_add_vin_device(1, &vin_platform_data);
+	platform_device_register_data(&platform_bus, "soc-camera-pdrv", 0,
+				      &iclink0_ml86v7667,
+				      sizeof(iclink0_ml86v7667));
+	platform_device_register_data(&platform_bus, "soc-camera-pdrv", 1,
+				      &iclink1_ml86v7667,
+				      sizeof(iclink1_ml86v7667));
 
 	pinctrl_register_mappings(bockw_pinctrl_map,
 				  ARRAY_SIZE(bockw_pinctrl_map));


From sergei.shtylyov at cogentembedded.com  Sun Apr 21 14:43:01 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Sun, 21 Apr 2013 22:43:01 +0400
Subject: [PATCH v2 5/5] ARM: shmobile: BOCK-W: enable VIN and ML86V7667 in
 defconfig
Message-ID: <201304212243.02148.sergei.shtylyov@cogentembedded.com>

From: Vladimir Barinov <vladimir.barinov at cogentembedded.com>

Add the VIN and ML86V7667 drivers to 'bockw_defconfig'.

Signed-off-by: Vladimir Barinov <vladimir.barinov at cogentembedded.com>
Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

---
 arch/arm/configs/bockw_defconfig |    7 +++++++
 1 file changed, 7 insertions(+)

Index: renesas/arch/arm/configs/bockw_defconfig
===================================================================
--- renesas.orig/arch/arm/configs/bockw_defconfig
+++ renesas/arch/arm/configs/bockw_defconfig
@@ -76,6 +76,13 @@ CONFIG_SERIAL_SH_SCI_CONSOLE=y
 # CONFIG_HWMON is not set
 CONFIG_I2C=y
 CONFIG_I2C_RCAR=y
+CONFIG_MEDIA_SUPPORT=y
+CONFIG_MEDIA_CAMERA_SUPPORT=y
+CONFIG_V4L_PLATFORM_DRIVERS=y
+CONFIG_SOC_CAMERA=y
+CONFIG_VIDEO_RCAR_VIN=y
+# CONFIG_MEDIA_SUBDRV_AUTOSELECT is not set
+CONFIG_VIDEO_ML86V7667=y
 CONFIG_USB=y
 CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
 CONFIG_USB_EHCI_HCD=y


From sergei.shtylyov at cogentembedded.com  Sun Apr 21 15:16:37 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Sun, 21 Apr 2013 23:16:37 +0400
Subject: [PATCH v2 4/5] ARM: shmobile: BOCK-W: add VIN and ML86V7667
 support
In-Reply-To: <201304212242.39693.sergei.shtylyov@cogentembedded.com>
References: <201304212242.39693.sergei.shtylyov@cogentembedded.com>
Message-ID: <51743B15.4000107@cogentembedded.com>

Hello.

On 04/21/2013 10:42 PM, Sergei Shtylyov wrote:

> From: Vladimir Barinov <vladimir.barinov at cogentembedded.com>
>
> Add ML86V7667 platform devices on BOCK-W board, configure VIN0/1 pins, and
> register VIN0/1 devices with the ML86V7667 specific platform data.
>
> Signed-off-by: Vladimir Barinov <vladimir.barinov at cogentembedded.com>
> [Sergei: some macro/comment cleanup; updated the copyrights.]
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
>
> ---
>   arch/arm/mach-shmobile/board-bockw.c |   40 +++++++++++++++++++++++++++++++++++
>   1 file changed, 40 insertions(+)
>
> Index: renesas/arch/arm/mach-shmobile/board-bockw.c
> ===================================================================
> --- renesas.orig/arch/arm/mach-shmobile/board-bockw.c
> +++ renesas/arch/arm/mach-shmobile/board-bockw.c

[...]

> @@ -23,6 +24,8 @@
>   #include <linux/regulator/fixed.h>
>   #include <linux/regulator/machine.h>
>   #include <linux/smsc911x.h>
> +#include <linux/pinctrl/machine.h>

    Noticed just now: this #include is duplicate. It seems I was too 
fast in resending
the series...

WBR, Sergei



From sergei.shtylyov at cogentembedded.com  Sun Apr 21 15:19:28 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Sun, 21 Apr 2013 23:19:28 +0400
Subject: [PATCH v5 1/9] ARM: shmobile: Marzen: move USB EHCI, OHCI, and
 PHY devices to R8A7779 code
In-Reply-To: <201304200156.23830.sergei.shtylyov@cogentembedded.com>
References: <201304200156.23830.sergei.shtylyov@cogentembedded.com>
Message-ID: <51743BC0.20506@cogentembedded.com>

Hello.

On 04/20/2013 01:56 AM, Sergei Shtylyov wrote:

> USB EHCI, OHCI, and common PHY are the SoC devices but are wrongly defined and
> registered in the Marzen board file.  Move the data and code to their proper
> place in setup-r8a7779.c; while at it, we have to rename 8a7779_late_devices[]
> to 8a7779_standard_devices[] -- this seems legitimate since they are registered

     I've been pointed to the types in the above variable names privately.
Don't know should I resend or Simon could fix s/8a7779/r8a7779/ while
applying... well, the USB patches haven't been ACK'ed yet.

> from r8a7779_add_standard_devices() anyway.
>
> Note that I'm deliberately changing the USB PHY platform device's 'id' field
> from (previously just omitted) 0 to -1 as the device is a single of its kind.
>
> Note also that the board and SoC code have to be in one patch to keep the code
> bisectable...
>
> The patch has been tested on the Marzen board.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
> Acked-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
> Acked-by: Simon Horman <horms+renesas at verge.net.au>

WBR, Sergei



From tomasz.figa at gmail.com  Sun Apr 21 15:20:50 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Sun, 21 Apr 2013 21:20:50 +0200
Subject: [PATCH] MAINTAINERS: Add linux-samsung-soc list to all related entries
Message-ID: <1366572050-626-1-git-send-email-tomasz.figa@gmail.com>

Several entries in MAINTAINERS file related to Samsung SoCs do not point
to linux-samsung-soc mailing list, which is supposed to collect all
Samsung SoC-related threads, to ease following of Samsung SoC-related
work. This leads to a problem with people skipping this mailing list in
their posts, even though they are related to Samsung SoCs.

This patch adds pointers to linux-samsung-soc mailing list to affected
entries of MAINTAINERS file.

Signed-off-by: Tomasz Figa <tomasz.figa at gmail.com>
---
 MAINTAINERS | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 6c0d68b..07cb8da 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1139,6 +1139,7 @@ F:	arch/arm/mach-exynos*/
 ARM/SAMSUNG MOBILE MACHINE SUPPORT
 M:	Kyungmin Park <kyungmin.park at samsung.com>
 L:	linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
+L:	linux-samsung-soc at vger.kernel.org (moderated for non-subscribers)
 S:	Maintained
 F:	arch/arm/mach-s5pv210/mach-aquila.c
 F:	arch/arm/mach-s5pv210/mach-goni.c
@@ -1150,6 +1151,7 @@ M:	Kyungmin Park <kyungmin.park at samsung.com>
 M:	Kamil Debski <k.debski at samsung.com>
 L:	linux-arm-kernel at lists.infradead.org
 L:	linux-media at vger.kernel.org
+L:	linux-samsung-soc at vger.kernel.org (moderated for non-subscribers)
 S:	Maintained
 F:	drivers/media/platform/s5p-g2d/
 
@@ -1158,6 +1160,7 @@ M:	Kyungmin Park <kyungmin.park at samsung.com>
 M:	Sylwester Nawrocki <s.nawrocki at samsung.com>
 L:	linux-arm-kernel at lists.infradead.org
 L:	linux-media at vger.kernel.org
+L:	linux-samsung-soc at vger.kernel.org (moderated for non-subscribers)
 S:	Maintained
 F:	arch/arm/plat-samsung/include/plat/*fimc*
 F:	drivers/media/platform/s5p-fimc/
@@ -1168,6 +1171,7 @@ M:	Kamil Debski <k.debski at samsung.com>
 M:	Jeongtae Park <jtp.park at samsung.com>
 L:	linux-arm-kernel at lists.infradead.org
 L:	linux-media at vger.kernel.org
+L:	linux-samsung-soc at vger.kernel.org (moderated for non-subscribers)
 S:	Maintained
 F:	arch/arm/plat-samsung/s5p-dev-mfc.c
 F:	drivers/media/platform/s5p-mfc/
@@ -1177,6 +1181,7 @@ M:	Kyungmin Park <kyungmin.park at samsung.com>
 M:	Tomasz Stanislawski <t.stanislaws at samsung.com>
 L:	linux-arm-kernel at lists.infradead.org
 L:	linux-media at vger.kernel.org
+L:	linux-samsung-soc at vger.kernel.org (moderated for non-subscribers)
 S:	Maintained
 F:	drivers/media/platform/s5p-tv/
 
@@ -2679,6 +2684,7 @@ M:	Joonyoung Shim <jy0922.shim at samsung.com>
 M:	Seung-Woo Kim <sw0312.kim at samsung.com>
 M:	Kyungmin Park <kyungmin.park at samsung.com>
 L:	dri-devel at lists.freedesktop.org
+L:	linux-samsung-soc at vger.kernel.org (moderated for non-subscribers)
 T:	git git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
 S:	Supported
 F:	drivers/gpu/drm/exynos
@@ -3142,6 +3148,7 @@ F:	Documentation/extcon/
 EXYNOS DP DRIVER
 M:	Jingoo Han <jg1.han at samsung.com>
 L:	linux-fbdev at vger.kernel.org
+L:	linux-samsung-soc at vger.kernel.org (moderated for non-subscribers)
 S:	Maintained
 F:	drivers/video/exynos/exynos_dp*
 F:	include/video/exynos_dp*
@@ -3151,6 +3158,7 @@ M:	Inki Dae <inki.dae at samsung.com>
 M:	Donghwa Lee <dh09.lee at samsung.com>
 M:	Kyungmin Park <kyungmin.park at samsung.com>
 L:	linux-fbdev at vger.kernel.org
+L:	linux-samsung-soc at vger.kernel.org (moderated for non-subscribers)
 S:	Maintained
 F:	drivers/video/exynos/exynos_mipi*
 F:	include/video/exynos_mipi*
@@ -6892,12 +6900,14 @@ F:	drivers/platform/x86/samsung-laptop.c
 SAMSUNG AUDIO (ASoC) DRIVERS
 M:	Sangbeom Kim <sbkim73 at samsung.com>
 L:	alsa-devel at alsa-project.org (moderated for non-subscribers)
+L:	linux-samsung-soc at vger.kernel.org (moderated for non-subscribers)
 S:	Supported
 F:	sound/soc/samsung
 
 SAMSUNG FRAMEBUFFER DRIVER
 M:	Jingoo Han <jg1.han at samsung.com>
 L:	linux-fbdev at vger.kernel.org
+L:	linux-samsung-soc at vger.kernel.org (moderated for non-subscribers)
 S:	Maintained
 F:	drivers/video/s3c-fb.c
 
@@ -7087,6 +7097,7 @@ F:	drivers/mmc/host/sdhci-pltfm.[ch]
 SECURE DIGITAL HOST CONTROLLER INTERFACE (SDHCI) SAMSUNG DRIVER
 M:	Ben Dooks <ben-linux at fluff.org>
 L:	linux-mmc at vger.kernel.org
+L:	linux-samsung-soc at vger.kernel.org (moderated for non-subscribers)
 S:	Maintained
 F:	drivers/mmc/host/sdhci-s3c.c
 
-- 
1.8.2.1



From marex at denx.de  Sun Apr 21 17:30:01 2013
From: marex at denx.de (Marek Vasut)
Date: Sun, 21 Apr 2013 23:30:01 +0200
Subject: [PATCH 1/8] ARM: mx5: Add AUDMUX4 pinctrl data
Message-ID: <1366579808-12067-1-git-send-email-marex@denx.de>

This patch adds pinctrl data for the AUDMUX4 on MX53.

Signed-off-by: Marek Vasut <marex at denx.de>
Cc: Fabio Estevam <fabio.estevam at freescale.com>
Cc: Shawn Guo <shawn.guo at linaro.org>
---
 arch/arm/boot/dts/imx53.dtsi |    9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/boot/dts/imx53.dtsi b/arch/arm/boot/dts/imx53.dtsi
index c4ddf51..fb701bb 100644
--- a/arch/arm/boot/dts/imx53.dtsi
+++ b/arch/arm/boot/dts/imx53.dtsi
@@ -298,6 +298,15 @@
 							MX53_PAD_KEY_ROW1__AUDMUX_AUD5_RXD  0x80000000
 						>;
 					};
+
+					pinctrl_audmux_2: audmuxgrp-2 {
+						fsl,pins = <
+							MX53_PAD_SD2_DATA3__AUDMUX_AUD4_TXC	0x80000000
+							MX53_PAD_SD2_DATA2__AUDMUX_AUD4_TXD	0x80000000
+							MX53_PAD_SD2_DATA1__AUDMUX_AUD4_TXFS	0x80000000
+							MX53_PAD_SD2_DATA0__AUDMUX_AUD4_RXD	0x80000000
+						>;
+					};
 				};
 
 				fec {
-- 
1.7.10.4



From marex at denx.de  Sun Apr 21 17:30:06 2013
From: marex at denx.de (Marek Vasut)
Date: Sun, 21 Apr 2013 23:30:06 +0200
Subject: [PATCH 6/8] ARM: mx5: Add LCD IPU pinctrl data
In-Reply-To: <1366579808-12067-1-git-send-email-marex@denx.de>
References: <1366579808-12067-1-git-send-email-marex@denx.de>
Message-ID: <1366579808-12067-6-git-send-email-marex@denx.de>

This patch adds pinmux for IPU LCD 1 and IPU LVDS.

Signed-off-by: Marek Vasut <marex at denx.de>
---
 arch/arm/boot/dts/imx53.dtsi |   57 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 57 insertions(+)

diff --git a/arch/arm/boot/dts/imx53.dtsi b/arch/arm/boot/dts/imx53.dtsi
index 7574026..91fc8cc 100644
--- a/arch/arm/boot/dts/imx53.dtsi
+++ b/arch/arm/boot/dts/imx53.dtsi
@@ -513,6 +513,63 @@
 					};
 				};
 
+				ipu_disp1 {
+					pinctrl_ipu_disp1_1: ipudisp1grp-1 {
+						fsl,pins = <
+							MX53_PAD_EIM_DA9__IPU_DISP1_DAT_0	0x5
+							MX53_PAD_EIM_DA8__IPU_DISP1_DAT_1	0x5
+							MX53_PAD_EIM_DA7__IPU_DISP1_DAT_2	0x5
+							MX53_PAD_EIM_DA6__IPU_DISP1_DAT_3	0x5
+							MX53_PAD_EIM_DA5__IPU_DISP1_DAT_4	0x5
+							MX53_PAD_EIM_DA4__IPU_DISP1_DAT_5	0x5
+							MX53_PAD_EIM_DA3__IPU_DISP1_DAT_6	0x5
+							MX53_PAD_EIM_DA2__IPU_DISP1_DAT_7	0x5
+							MX53_PAD_EIM_DA1__IPU_DISP1_DAT_8	0x5
+							MX53_PAD_EIM_DA0__IPU_DISP1_DAT_9	0x5
+							MX53_PAD_EIM_EB1__IPU_DISP1_DAT_10	0x5
+							MX53_PAD_EIM_EB0__IPU_DISP1_DAT_11	0x5
+							MX53_PAD_EIM_A17__IPU_DISP1_DAT_12	0x5
+							MX53_PAD_EIM_A18__IPU_DISP1_DAT_13	0x5
+							MX53_PAD_EIM_A19__IPU_DISP1_DAT_14	0x5
+							MX53_PAD_EIM_A20__IPU_DISP1_DAT_15	0x5
+							MX53_PAD_EIM_A21__IPU_DISP1_DAT_16	0x5
+							MX53_PAD_EIM_A22__IPU_DISP1_DAT_17	0x5
+							MX53_PAD_EIM_A23__IPU_DISP1_DAT_18	0x5
+							MX53_PAD_EIM_A24__IPU_DISP1_DAT_19	0x5
+							MX53_PAD_EIM_D31__IPU_DISP1_DAT_20	0x5
+							MX53_PAD_EIM_D30__IPU_DISP1_DAT_21	0x5
+							MX53_PAD_EIM_D26__IPU_DISP1_DAT_22	0x5
+							MX53_PAD_EIM_D27__IPU_DISP1_DAT_23	0x5
+							MX53_PAD_EIM_A16__IPU_DI1_DISP_CLK	0x5
+							MX53_PAD_EIM_DA13__IPU_DI1_D0_CS	0x5
+							MX53_PAD_EIM_DA14__IPU_DI1_D1_CS	0x5
+							MX53_PAD_EIM_DA15__IPU_DI1_PIN1	0x5
+							MX53_PAD_EIM_DA11__IPU_DI1_PIN2	0x5
+							MX53_PAD_EIM_DA12__IPU_DI1_PIN3	0x5
+							MX53_PAD_EIM_A25__IPU_DI1_PIN12	0x5
+							MX53_PAD_EIM_DA10__IPU_DI1_PIN15	0x5
+						>;
+					};
+				};
+
+				ipu_disp2 {
+					pinctrl_ipu_disp2_1: ipudisp2grp-1 {
+						fsl,pins = <
+							MX53_PAD_LVDS0_TX0_P__LDB_LVDS0_TX0	0x80000000
+							MX53_PAD_LVDS0_TX1_P__LDB_LVDS0_TX1	0x80000000
+							MX53_PAD_LVDS0_TX2_P__LDB_LVDS0_TX2	0x80000000
+							MX53_PAD_LVDS0_TX3_P__LDB_LVDS0_TX3	0x80000000
+							MX53_PAD_LVDS0_CLK_P__LDB_LVDS0_CLK	0x80000000
+
+							MX53_PAD_LVDS1_TX0_P__LDB_LVDS1_TX0	0x80000000
+							MX53_PAD_LVDS1_TX1_P__LDB_LVDS1_TX1	0x80000000
+							MX53_PAD_LVDS1_TX2_P__LDB_LVDS1_TX2	0x80000000
+							MX53_PAD_LVDS1_TX3_P__LDB_LVDS1_TX3	0x80000000
+							MX53_PAD_LVDS1_CLK_P__LDB_LVDS1_CLK	0x80000000
+						>;
+					};
+				};
+
 				uart1 {
 					pinctrl_uart1_1: uart1grp-1 {
 						fsl,pins = <
-- 
1.7.10.4



From marex at denx.de  Sun Apr 21 17:30:05 2013
From: marex at denx.de (Marek Vasut)
Date: Sun, 21 Apr 2013 23:30:05 +0200
Subject: [PATCH 5/8] ARM: mx5: Add NAND pinctrl data
In-Reply-To: <1366579808-12067-1-git-send-email-marex@denx.de>
References: <1366579808-12067-1-git-send-email-marex@denx.de>
Message-ID: <1366579808-12067-5-git-send-email-marex@denx.de>

This patch adds pinctrl data for NAND on MX53.

Signed-off-by: Marek Vasut <marex at denx.de>
Cc: Fabio Estevam <fabio.estevam at freescale.com>
Cc: Shawn Guo <shawn.guo at linaro.org>
---
 arch/arm/boot/dts/imx53.dtsi |   21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/arch/arm/boot/dts/imx53.dtsi b/arch/arm/boot/dts/imx53.dtsi
index 09145e2..7574026 100644
--- a/arch/arm/boot/dts/imx53.dtsi
+++ b/arch/arm/boot/dts/imx53.dtsi
@@ -575,6 +575,27 @@
 					};
 				};
 
+				nand {
+					pinctrl_nand_1: nandgrp-1 {
+						fsl,pins = <
+							MX53_PAD_NANDF_WE_B__EMI_NANDF_WE_B	0x4
+							MX53_PAD_NANDF_RE_B__EMI_NANDF_RE_B	0x4
+							MX53_PAD_NANDF_CLE__EMI_NANDF_CLE	0x4
+							MX53_PAD_NANDF_ALE__EMI_NANDF_ALE	0x4
+							MX53_PAD_NANDF_WP_B__EMI_NANDF_WP_B	0xe0
+							MX53_PAD_NANDF_RB0__EMI_NANDF_RB_0	0xe0
+							MX53_PAD_NANDF_CS0__EMI_NANDF_CS_0	0x4
+							MX53_PAD_PATA_DATA0__EMI_NANDF_D_0	0xa4
+							MX53_PAD_PATA_DATA1__EMI_NANDF_D_1	0xa4
+							MX53_PAD_PATA_DATA2__EMI_NANDF_D_2	0xa4
+							MX53_PAD_PATA_DATA3__EMI_NANDF_D_3	0xa4
+							MX53_PAD_PATA_DATA4__EMI_NANDF_D_4	0xa4
+							MX53_PAD_PATA_DATA5__EMI_NANDF_D_5	0xa4
+							MX53_PAD_PATA_DATA6__EMI_NANDF_D_6	0xa4
+							MX53_PAD_PATA_DATA7__EMI_NANDF_D_7	0xa4
+						>;
+					};
+				};
 			};
 
 			gpr: iomuxc-gpr at 53fa8000 {
-- 
1.7.10.4



From marex at denx.de  Sun Apr 21 17:30:08 2013
From: marex at denx.de (Marek Vasut)
Date: Sun, 21 Apr 2013 23:30:08 +0200
Subject: [PATCH 8/8] ARM: mx5: Add support for DENX M53EVK
In-Reply-To: <1366579808-12067-1-git-send-email-marex@denx.de>
References: <1366579808-12067-1-git-send-email-marex@denx.de>
Message-ID: <1366579808-12067-8-git-send-email-marex@denx.de>

This patch adds support for the DENX M53EVK board. The board currently supports
NAND, Ethernet, UART, CAN, I2C.

Signed-off-by: Marek Vasut <marex at denx.de>
Cc: Fabio Estevam <fabio.estevam at freescale.com>
Cc: Shawn Guo <shawn.guo at linaro.org>
---
 arch/arm/boot/dts/Makefile         |    1 +
 arch/arm/boot/dts/imx53-m53evk.dts |  282 ++++++++++++++++++++++++++++++++++++
 arch/arm/mach-imx/mach-imx53.c     |   16 +-
 3 files changed, 297 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm/boot/dts/imx53-m53evk.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 4fd1f62..1fbec6b 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -107,6 +107,7 @@ dtb-$(CONFIG_ARCH_MXC) += \
 	imx51-babbage.dtb \
 	imx53-ard.dtb \
 	imx53-evk.dtb \
+	imx53-m53evk.dtb \
 	imx53-mba53.dtb \
 	imx53-qsb.dtb \
 	imx53-smd.dtb \
diff --git a/arch/arm/boot/dts/imx53-m53evk.dts b/arch/arm/boot/dts/imx53-m53evk.dts
new file mode 100644
index 0000000..32f8ff4
--- /dev/null
+++ b/arch/arm/boot/dts/imx53-m53evk.dts
@@ -0,0 +1,282 @@
+/*
+ * Copyright (C) 2013 Marek Vasut <marex at denx.de>
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+/dts-v1/;
+#include "imx53.dtsi"
+
+/ {
+	model = "DENX M53EVK";
+	compatible = "denx,imx53-m53evk", "fsl,imx53";
+
+	memory {
+		reg = <0x70000000 0x20000000>;
+	};
+
+	soc {
+		display at di0 {
+			compatible = "fsl,imx-parallel-display";
+			crtcs = <&ipu 0>;
+			interface-pix-fmt = "rgb24";
+			pinctrl-names = "default";
+			pinctrl-0 = <&pinctrl_ipu_disp1_1>;
+
+			display-timings {
+				800x480p60 {
+					native-mode;
+					clock-frequency = <31500000>;
+					hactive = <800>;
+					vactive = <480>;
+					hfront-porch = <40>;
+					hback-porch = <88>;
+					hsync-len = <128>;
+					vback-porch = <33>;
+					vfront-porch = <9>;
+					vsync-len = <3>;
+					vsync-active = <1>;
+				};
+			};
+		};
+
+		display at di1 {
+			compatible = "fsl,imx-parallel-display";
+			crtcs = <&ipu 1>;
+			interface-pix-fmt = "rgb24";
+			pinctrl-names = "default";
+			pinctrl-0 = <&pinctrl_ipu_disp2_1>;
+
+			display-timings {
+				800x480p60 {
+					native-mode;
+					clock-frequency = <31500000>;
+					hactive = <800>;
+					vactive = <480>;
+					hfront-porch = <40>;
+					hback-porch = <88>;
+					hsync-len = <128>;
+					vback-porch = <33>;
+					vfront-porch = <9>;
+					vsync-len = <3>;
+					vsync-active = <1>;
+				};
+			};
+		};
+	};
+
+	leds {
+		compatible = "gpio-leds";
+		pinctrl-names = "default";
+		pinctrl-0 = <&led_pin_gpio>;
+
+		user1 {
+			label = "user1";
+			gpios = <&gpio2 8 0>;
+			linux,default-trigger = "heartbeat";
+		};
+
+		user2 {
+			label = "user2";
+			gpios = <&gpio2 9 0>;
+			linux,default-trigger = "heartbeat";
+		};
+	};
+
+	regulators {
+		compatible = "simple-bus";
+
+		reg_3p2v: 3p2v {
+			compatible = "regulator-fixed";
+			regulator-name = "3P2V";
+			regulator-min-microvolt = <3200000>;
+			regulator-max-microvolt = <3200000>;
+			regulator-always-on;
+		};
+	};
+
+	sound {
+		compatible = "fsl,imx53-m53evk-sgtl5000",
+			     "fsl,imx-audio-sgtl5000";
+		model = "imx53-m53evk-sgtl5000";
+		ssi-controller = <&ssi2>;
+		audio-codec = <&sgtl5000>;
+		audio-routing =
+			"MIC_IN", "Mic Jack",
+			"Mic Jack", "Mic Bias",
+			"LINE_IN", "Line In Jack",
+			"Headphone Jack", "HP_OUT",
+			"Ext Spk", "LINE_OUT";
+		mux-int-port = <2>;
+		mux-ext-port = <4>;
+	};
+
+	backlight {
+		compatible = "pwm-backlight";
+		pwms = <&pwm1 0 3000>;
+		brightness-levels = <0 4 8 16 32 64 128 255>;
+		default-brightness-level = <6>;
+	};
+};
+
+&esdhc1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_esdhc1_1>;
+	cd-gpios = <&gpio1 1 0>;
+	wp-gpios = <&gpio1 9 0>;
+	status = "okay";
+};
+
+&ssi2 {
+	fsl,mode = "i2s-slave";
+	status = "okay";
+};
+
+&uart3 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_uart3_1>;
+	status = "okay";
+};
+
+&pwm1 {
+/*	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_pwm1_1>;*/
+	status = "okay";
+};
+
+&uart1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_uart1_2>;
+	status = "okay";
+};
+
+&uart2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_uart2_1>;
+	status = "okay";
+};
+
+&iomuxc {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_hog>;
+
+	hog {
+		pinctrl_hog: hoggrp {
+			fsl,pins = <
+				MX53_PAD_GPIO_0__CCM_SSI_EXT1_CLK	0x80000000
+				MX53_PAD_EIM_EB3__GPIO2_31		0x80000000
+				MX53_PAD_PATA_DA_0__GPIO7_6		0x80000000
+				MX53_PAD_DISP0_DAT8__PWM1_PWMO		0x5
+
+			>;
+		};
+
+		led_pin_gpio: led_gpio at 0 {
+			fsl,pins = <
+				MX53_PAD_PATA_DATA8__GPIO2_8		0x80000000
+				MX53_PAD_PATA_DATA9__GPIO2_9		0x80000000
+			>;
+		};
+	};
+};
+
+&can1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_can1_3>;
+	status = "okay";
+};
+
+&can2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_can2_1>;
+	status = "okay";
+};
+
+&i2c1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_i2c1_2>;
+	status = "okay";
+
+	sgtl5000: codec at 0a {
+		compatible = "fsl,sgtl5000";
+		reg = <0x0a>;
+		VDDA-supply = <&reg_3p2v>;
+		VDDIO-supply = <&reg_3p2v>;
+	};
+};
+
+&i2c2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_i2c2_2>;
+	clock-frequency = <400000>;
+	status = "okay";
+
+	stmpe610 at 41 {
+		compatible = "st,stmpe610";
+		#address-cells = <1>;
+		#size-cells = <0>;
+		reg = <0x41>;
+		irq-over-gpio;
+		irq-gpios = <&gpio7 6 0>;
+		id = <0>;
+		blocks = <0x5>;
+		irq-trigger = <0x1>;
+
+		stmpe_touchscreen {
+			compatible = "stmpe,ts";
+			reg = <0>;
+			ts,sample-time = <4>;
+			ts,mod-12b = <1>;
+			ts,ref-sel = <0>;
+			ts,adc-freq = <1>;
+			ts,ave-ctrl = <3>;
+			ts,touch-det-delay = <3>;
+			ts,settling = <4>;
+			ts,fraction-z = <7>;
+			ts,i-drive = <1>;
+		};
+	};
+
+	eeprom: eeprom at 50 {
+		compatible = "atmel,24c128";
+		reg = <0x50>;
+		pagesize = <32>;
+	};
+
+	rtc: rtc at 68 {
+		compatible = "stm,m41t62";
+		reg = <0x68>;
+	};
+};
+
+&i2c3 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_i2c3_1>;
+	status = "okay";
+};
+
+&audmux {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_audmux_2>;
+	status = "okay";
+};
+
+&nfc {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_nand_1>;
+	nand-bus-width = <8>;
+	nand-ecc-mode = "hw";
+	status = "okay";
+};
+
+&fec {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_fec_1>;
+	phy-mode = "rmii";
+	status = "okay";
+};
diff --git a/arch/arm/mach-imx/mach-imx53.c b/arch/arm/mach-imx/mach-imx53.c
index f579c61..4effe59 100644
--- a/arch/arm/mach-imx/mach-imx53.c
+++ b/arch/arm/mach-imx/mach-imx53.c
@@ -23,7 +23,7 @@
 #include "common.h"
 #include "mx53.h"
 
-static void __init imx53_qsb_init(void)
+static void __init imx53_ssi_clk_init(const char *device)
 {
 	struct clk *clk;
 
@@ -33,11 +33,23 @@ static void __init imx53_qsb_init(void)
 		return;
 	}
 
-	clk_register_clkdev(clk, NULL, "0-000a");
+	clk_register_clkdev(clk, NULL, device);
+}
+
+static void __init imx53_qsb_init(void)
+{
+	imx53_ssi_clk_init("0-000a");
+}
+
+static void __init imx53_m53evk_init(void)
+{
+	imx53_ssi_clk_init("2-000a");
 }
 
 static void __init imx53_dt_init(void)
 {
+	if (of_machine_is_compatible("denx,imx53-m53evk"))
+		imx53_m53evk_init();
 	if (of_machine_is_compatible("fsl,imx53-qsb"))
 		imx53_qsb_init();
 
-- 
1.7.10.4



From marex at denx.de  Sun Apr 21 17:30:02 2013
From: marex at denx.de (Marek Vasut)
Date: Sun, 21 Apr 2013 23:30:02 +0200
Subject: [PATCH 2/8] ARM: mx5: Add CAN1 pinctrl data
In-Reply-To: <1366579808-12067-1-git-send-email-marex@denx.de>
References: <1366579808-12067-1-git-send-email-marex@denx.de>
Message-ID: <1366579808-12067-2-git-send-email-marex@denx.de>

This patch adds pinctrl data for different mux of CAN1 on MX53.

Signed-off-by: Marek Vasut <marex at denx.de>
Cc: Fabio Estevam <fabio.estevam at freescale.com>
Cc: Shawn Guo <shawn.guo at linaro.org>
---
 arch/arm/boot/dts/imx53.dtsi |    7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/imx53.dtsi b/arch/arm/boot/dts/imx53.dtsi
index fb701bb..6a2f5a8 100644
--- a/arch/arm/boot/dts/imx53.dtsi
+++ b/arch/arm/boot/dts/imx53.dtsi
@@ -446,6 +446,13 @@
 							MX53_PAD_KEY_ROW2__CAN1_RXCAN 0x80000000
 						>;
 					};
+
+					pinctrl_can1_3: can1grp-3 {
+						fsl,pins = <
+							MX53_PAD_GPIO_7__CAN1_TXCAN	0x80000000
+							MX53_PAD_GPIO_8__CAN1_RXCAN	0x80000000
+						>;
+					};
 				};
 
 				can2 {
-- 
1.7.10.4



From marex at denx.de  Sun Apr 21 17:30:03 2013
From: marex at denx.de (Marek Vasut)
Date: Sun, 21 Apr 2013 23:30:03 +0200
Subject: [PATCH 3/8] ARM: mx5: Add I2C1 pinctrl data
In-Reply-To: <1366579808-12067-1-git-send-email-marex@denx.de>
References: <1366579808-12067-1-git-send-email-marex@denx.de>
Message-ID: <1366579808-12067-3-git-send-email-marex@denx.de>

This patch adds pinctrl data for different mux of I2C1 on MX53.

Signed-off-by: Marek Vasut <marex at denx.de>
Cc: Fabio Estevam <fabio.estevam at freescale.com>
Cc: Shawn Guo <shawn.guo at linaro.org>
---
 arch/arm/boot/dts/imx53.dtsi |    7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/imx53.dtsi b/arch/arm/boot/dts/imx53.dtsi
index 6a2f5a8..1f6868d 100644
--- a/arch/arm/boot/dts/imx53.dtsi
+++ b/arch/arm/boot/dts/imx53.dtsi
@@ -471,6 +471,13 @@
 							MX53_PAD_CSI0_DAT9__I2C1_SCL 0xc0000000
 						>;
 					};
+
+					pinctrl_i2c1_2: i2c1grp-2 {
+						fsl,pins = <
+							MX53_PAD_EIM_D21__I2C1_SCL	0xc0000000
+							MX53_PAD_EIM_D28__I2C1_SDA	0xc0000000
+						>;
+					};
 				};
 
 				i2c2 {
-- 
1.7.10.4



From marex at denx.de  Sun Apr 21 17:30:07 2013
From: marex at denx.de (Marek Vasut)
Date: Sun, 21 Apr 2013 23:30:07 +0200
Subject: [PATCH 7/8] ARM: mx5: Add PWM1 pinctrl data
In-Reply-To: <1366579808-12067-1-git-send-email-marex@denx.de>
References: <1366579808-12067-1-git-send-email-marex@denx.de>
Message-ID: <1366579808-12067-7-git-send-email-marex@denx.de>

This patch adds pinctrl data for PWM1 on MX53.

Signed-off-by: Marek Vasut <marex at denx.de>
---
 arch/arm/boot/dts/imx53.dtsi |    8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/imx53.dtsi b/arch/arm/boot/dts/imx53.dtsi
index 91fc8cc..c343ba6 100644
--- a/arch/arm/boot/dts/imx53.dtsi
+++ b/arch/arm/boot/dts/imx53.dtsi
@@ -653,6 +653,14 @@
 						>;
 					};
 				};
+
+				pwm1 {
+					pinctrl_pwm1_1: pwm1grp-1 {
+						fsl,pins = <
+							MX53_PAD_DISP0_DAT8__PWM1_PWMO	0x5
+						>;
+					};
+				};
 			};
 
 			gpr: iomuxc-gpr at 53fa8000 {
-- 
1.7.10.4



From marex at denx.de  Sun Apr 21 17:30:04 2013
From: marex at denx.de (Marek Vasut)
Date: Sun, 21 Apr 2013 23:30:04 +0200
Subject: [PATCH 4/8] ARM: mx5: Add I2C2 pinctrl data
In-Reply-To: <1366579808-12067-1-git-send-email-marex@denx.de>
References: <1366579808-12067-1-git-send-email-marex@denx.de>
Message-ID: <1366579808-12067-4-git-send-email-marex@denx.de>

This patch adds pinctrl data for different mux of I2C2 on MX53.

Signed-off-by: Marek Vasut <marex at denx.de>
Cc: Fabio Estevam <fabio.estevam at freescale.com>
Cc: Shawn Guo <shawn.guo at linaro.org>
---
 arch/arm/boot/dts/imx53.dtsi |    7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/imx53.dtsi b/arch/arm/boot/dts/imx53.dtsi
index 1f6868d..09145e2 100644
--- a/arch/arm/boot/dts/imx53.dtsi
+++ b/arch/arm/boot/dts/imx53.dtsi
@@ -487,6 +487,13 @@
 							MX53_PAD_KEY_COL3__I2C2_SCL 0xc0000000
 						>;
 					};
+
+					pinctrl_i2c2_2: i2c2grp-2 {
+						fsl,pins = <
+							MX53_PAD_EIM_D16__I2C2_SDA	0xc0000000
+							MX53_PAD_EIM_EB2__I2C2_SCL	0xc0000000
+						>;
+					};
 				};
 
 				i2c3 {
-- 
1.7.10.4



From gmbnomis at gmail.com  Sun Apr 21 18:06:30 2013
From: gmbnomis at gmail.com (Simon Baatz)
Date: Mon, 22 Apr 2013 00:06:30 +0200
Subject: [PATCH V3 2/2] ARM: Handle user space mapped pages in
 flush_kernel_dcache_page
In-Reply-To: <20130418135104.GA18616@arm.com>
References: <1349609352-6408-3-git-send-email-gmbnomis@gmail.com>
 <20121008174428.GB3204@arm.com>
 <20121008200216.GA14167@schnuecks.de>
 <20121008202040.GC4625@n2100.arm.linux.org.uk>
 <20121008230733.GA17819@schnuecks.de>
 <20121118211005.GW22106@titan.lakedaemon.net>
 <20130418111608.GF27197@titan.lakedaemon.net>
 <20130418112201.GQ14496@n2100.arm.linux.org.uk>
 <20130418114016.GG27197@titan.lakedaemon.net>
 <20130418135104.GA18616@arm.com>
Message-ID: <20130421220629.GA25571@schnuecks.de>


Hi Catalin,

On Thu, Apr 18, 2013 at 02:51:04PM +0100, Catalin Marinas wrote:
> On Thu, Apr 18, 2013 at 12:40:16PM +0100, Jason Cooper wrote:
> > Ok, got it.  I should have been more explicit.  LVM doesn't work on ARM.
> > iirc, Simon had a demo of dm-crypt also faulting on ARM.  This patch was
> > not the correct approach.  Is there an interest (particularly Simon) in
> > fixing the problem?
> 
> I think fixing this for ARM is useful but I don't have any time to
> allocate. I think I acked the first patch in the series but I don't
> fully remember the details behind the second one.
> 
> As Russell said, flush_kernel_dcache_page() is not the right API.

It is not the driver itself which is using the API, it is the
generic scatterlist memory iterator. And I don't think that this is
wrong, as I have tried to explain in [1].


> flush_dcache_page() is not supposed to be used on anonymous pages. What
> we have for such pages is flush_anon_page() which is a no-op for VIPT
> non-aliasing pages. I can see that __get_user_pages() calls both
> flush_anon_page() flush_dcache_page().

Yes. But I think that is not relevant here. Although the naming
suggest that the function is just a light-weight version of
flush_dcache_page(), both the documentation and the commit text say
that flush_kernel_dcache_page() has to handle pages that were
obtained through get_user_pages, which includes anon pages.


Btw. many drivers which modify pages via the kernel mapping currently
use flush_dcache_page() instead.  This is not supposed to work in
e.g.  the direct I/O case where a driver sees anon pages.  This works
just because flush_dcache_page() flushes the kernel mapping also for
anon pages.  Something is is clearly not supposed to do according to
documentation.

> Is the problem that you have related to I-D cache coherency? Is
> flush_anon_page() the right place for this?

This particular problem is not related to I/D cache coherency. 
However, as far as I know, flush_dcache_page() is expected to ensure
also I/D cache coherency.  Also, we flush the I-cache in certain
situations in this function.  As said in my response to Russel, I
don't know whether this is expected from flush_kernel_dcache_page()
as well.  I would say yes, but I also have posted a version that only
flushes the D-cache kernel mapping.

- Simon

[1] http://permalink.gmane.org/gmane.linux.ports.arm.kernel/181703


From mikedunn at newsguy.com  Sun Apr 21 18:23:50 2013
From: mikedunn at newsguy.com (Mike Dunn)
Date: Sun, 21 Apr 2013 15:23:50 -0700
Subject: gpio-pxa initcall level change and machine init breakage
In-Reply-To: <CAD6h2NSRA9w7GZLQGgK-+TvEAsxwOHow5_26JyVUA6YQyj3OQg@mail.gmail.com>
References: <5172B398.7060706@newsguy.com>
 <CAD6h2NSRA9w7GZLQGgK-+TvEAsxwOHow5_26JyVUA6YQyj3OQg@mail.gmail.com>
Message-ID: <517466F6.3000003@newsguy.com>

On 04/20/2013 11:02 PM, Haojian Zhuang wrote:
> On 20 April 2013 23:26, Mike Dunn <mikedunn at newsguy.com> wrote:
>> Hi,
>>
>> After a few months of neglect, I rebased my palm treo 680 kernel with the latest
>> from Linus' official tree, and now all the calls to gpio lib functions
>> (gpio_request(), etc) made from the init_machine() method in struct machine_desc
>> fail.  I tracked this back to commit 6c7e660a27da7494c670bfba21cfeba30457656c
>> dated Jan 23 2013
>>
>>     gpio: pxa: set initcall level to module init
>>
>>     gpio & pinctrl driver are used together. The pinctrl driver is already
>>     launched before gpio driver in Makefile. So set gpio driver to module
>>     init level. Otherwise, the sequence will be inverted.
>>
>>     Signed-off-by: Haojian Zhuang <haojian.zhuang at linaro.org>
>>     Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
>>
>> At the time, Haojian addressed a question about this patch regarding module
>> dependencies, advising use of the deferred probe infrastructure.  But unless I'm
>> mistaken, mine is an initcall level problem, not a dependency issue among driver
>> probes.  Now that gpio-pxa initialization is at the device level (initcall6),
>> calls to gpiolib are no longer possible from init_machine(), which remains at
>> the initcall3 level.
>>
>> I feel like I must be missing something, because a lot of pxa boards call
>> gpiolib from init machine(), so my breakage should not be an isolated case.
>>
>> If I'm not missing anything and the patch is necessary, it looks like one
>> solution would be to move all the initializations that use gpiolib to the
>> init_late method in struct machine_desc, which runs as initcall7.
>>
>> Grateful for any advice!
>>
>> Thanks,
>> Mike
> 
> Actually gpio request should be handled in the driver, not machine platform
> driver. For example, lcd init may request gpio. pxafb.c provides the callback
> to handle it. We need to move code of requesting gpio into the callback.


Yes, I see.  Thanks for the example.


> 
> Since this change breaks current platform, we have to revert it. We still need
> a code cleanup in arch-pxa directory.


I knew some cleanup was needed to the palm stuff, but didn't realize the extent.
 Should not be too difficult; I hope to have patches soon.  But there are other
pxa boards that grab various gpios in init_machine() and may not be as
straightforward.


> 
> Linus,
> Could you help to revert this commit? Or do I need to send a revert commit
> to you?


Will the big guy see this?  Only posted to linux-arm-kernel ML.

Thanks Haojian,
Mike


From marex at denx.de  Sun Apr 21 19:04:10 2013
From: marex at denx.de (Marek Vasut)
Date: Mon, 22 Apr 2013 01:04:10 +0200
Subject: [PATCH] video: imx: Add BGR666 support for parallel display
Message-ID: <1366585450-12762-1-git-send-email-marex@denx.de>

Support the BGR666 format on the IPUv3 parallel display.

Signed-off-by: Marek Vasut <marex at denx.de>
Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
Cc: Philipp Zabel <p.zabel at pengutronix.de>
Cc: Sascha Hauer <s.hauer at pengutronix.de>
Cc: Bill Pemberton <wfp5p at virginia.edu>
---
 drivers/staging/imx-drm/ipu-v3/ipu-dc.c    |    9 +++++++++
 drivers/staging/imx-drm/parallel-display.c |    2 ++
 2 files changed, 11 insertions(+)

diff --git a/drivers/staging/imx-drm/ipu-v3/ipu-dc.c b/drivers/staging/imx-drm/ipu-v3/ipu-dc.c
index 1cb0631..59f03f9 100644
--- a/drivers/staging/imx-drm/ipu-v3/ipu-dc.c
+++ b/drivers/staging/imx-drm/ipu-v3/ipu-dc.c
@@ -90,6 +90,7 @@ enum ipu_dc_map {
 	IPU_DC_MAP_RGB24,
 	IPU_DC_MAP_RGB565,
 	IPU_DC_MAP_GBR24, /* TVEv2 */
+	IPU_DC_MAP_BGR666,
 };
 
 struct ipu_dc {
@@ -149,6 +150,8 @@ static int ipu_pixfmt_to_map(u32 fmt)
 		return IPU_DC_MAP_RGB565;
 	case IPU_PIX_FMT_GBR24:
 		return IPU_DC_MAP_GBR24;
+	case V4L2_PIX_FMT_BGR666:
+		return IPU_DC_MAP_BGR666;
 	default:
 		return -EINVAL;
 	}
@@ -385,6 +388,12 @@ int ipu_dc_init(struct ipu_soc *ipu, struct device *dev,
 	ipu_dc_map_config(priv, IPU_DC_MAP_GBR24, 1, 7, 0xff); /* blue */
 	ipu_dc_map_config(priv, IPU_DC_MAP_GBR24, 0, 23, 0xff); /* red */
 
+	/* bgr666 */
+	ipu_dc_map_clear(priv, IPU_DC_MAP_BGR666);
+	ipu_dc_map_config(priv, IPU_DC_MAP_BGR666, 0, 5, 0xfc); /* blue */
+	ipu_dc_map_config(priv, IPU_DC_MAP_BGR666, 1, 11, 0xfc); /* green */
+	ipu_dc_map_config(priv, IPU_DC_MAP_BGR666, 2, 17, 0xfc); /* red */
+
 	return 0;
 }
 
diff --git a/drivers/staging/imx-drm/parallel-display.c b/drivers/staging/imx-drm/parallel-display.c
index 2a25202..e7fba62 100644
--- a/drivers/staging/imx-drm/parallel-display.c
+++ b/drivers/staging/imx-drm/parallel-display.c
@@ -230,6 +230,8 @@ static int imx_pd_probe(struct platform_device *pdev)
 			imxpd->interface_pix_fmt = V4L2_PIX_FMT_RGB24;
 		else if (!strcmp(fmt, "rgb565"))
 			imxpd->interface_pix_fmt = V4L2_PIX_FMT_RGB565;
+		else if (!strcmp(fmt, "bgr666"))
+			imxpd->interface_pix_fmt = V4L2_PIX_FMT_BGR666;
 	}
 
 	imxpd->dev = &pdev->dev;
-- 
1.7.10.4



From rjw at sisk.pl  Sun Apr 21 19:32:17 2013
From: rjw at sisk.pl (Rafael J. Wysocki)
Date: Mon, 22 Apr 2013 01:32:17 +0200
Subject: [PATCH] cpufreq: exynos5440: Protect opp search calls with rcu
 lock
In-Reply-To: <1366007087-12090-1-git-send-email-amit.daniel@samsung.com>
References: <1366007087-12090-1-git-send-email-amit.daniel@samsung.com>
Message-ID: <27334831.finUCxlqRS@vostro.rjw.lan>

On Monday, April 15, 2013 11:54:47 AM Amit Daniel Kachhap wrote:
> As per the OPP library documentation(Documentation/power/opp.txt) all
> opp find/get calls should be protected by rcu locks.
> 
> Signed-off-by: Amit Daniel Kachhap <amit.daniel at samsung.com>
> ---
> 
> This patch is created against linux-next tree and is suggested by
> Nishanth Menon. (https://lkml.org/lkml/2013/4/12/119)

Applied.

Thanks,
Rafael


>  drivers/cpufreq/exynos5440-cpufreq.c |    3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/cpufreq/exynos5440-cpufreq.c b/drivers/cpufreq/exynos5440-cpufreq.c
> index ead7ed4..0c74018 100644
> --- a/drivers/cpufreq/exynos5440-cpufreq.c
> +++ b/drivers/cpufreq/exynos5440-cpufreq.c
> @@ -120,11 +120,13 @@ static int init_div_table(void)
>  	int i = 0;
>  	struct opp *opp;
>  
> +	rcu_read_lock();
>  	for (i = 0; freq_tbl[i].frequency != CPUFREQ_TABLE_END; i++) {
>  
>  		opp = opp_find_freq_exact(dvfs_info->dev,
>  					freq_tbl[i].frequency * 1000, true);
>  		if (IS_ERR(opp)) {
> +			rcu_read_unlock();
>  			dev_err(dvfs_info->dev,
>  				"failed to find valid OPP for %u KHZ\n",
>  				freq_tbl[i].frequency);
> @@ -159,6 +161,7 @@ static int init_div_table(void)
>  		__raw_writel(tmp, dvfs_info->base + XMU_PMU_P0_7 + 4 * i);
>  	}
>  
> +	rcu_read_unlock();
>  	return 0;
>  }
>  
> 
-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.


From haojian.zhuang at linaro.org  Sun Apr 21 20:58:00 2013
From: haojian.zhuang at linaro.org (Haojian Zhuang)
Date: Mon, 22 Apr 2013 08:58:00 +0800
Subject: gpio-pxa initcall level change and machine init breakage
In-Reply-To: <517466F6.3000003@newsguy.com>
References: <5172B398.7060706@newsguy.com>
 <CAD6h2NSRA9w7GZLQGgK-+TvEAsxwOHow5_26JyVUA6YQyj3OQg@mail.gmail.com>
 <517466F6.3000003@newsguy.com>
Message-ID: <CAD6h2NSy0=3P-PHdCiJJQG_jvGaFnr7uex+Uxs=0F-VsUxtPWg@mail.gmail.com>

On 22 April 2013 06:23, Mike Dunn <mikedunn at newsguy.com> wrote:
> On 04/20/2013 11:02 PM, Haojian Zhuang wrote:
>> On 20 April 2013 23:26, Mike Dunn <mikedunn at newsguy.com> wrote:
>>> Hi,
>>>
>>> After a few months of neglect, I rebased my palm treo 680 kernel with the latest
>>> from Linus' official tree, and now all the calls to gpio lib functions
>>> (gpio_request(), etc) made from the init_machine() method in struct machine_desc
>>> fail.  I tracked this back to commit 6c7e660a27da7494c670bfba21cfeba30457656c
>>> dated Jan 23 2013
>>>
>>>     gpio: pxa: set initcall level to module init
>>>
>>>     gpio & pinctrl driver are used together. The pinctrl driver is already
>>>     launched before gpio driver in Makefile. So set gpio driver to module
>>>     init level. Otherwise, the sequence will be inverted.
>>>
>>>     Signed-off-by: Haojian Zhuang <haojian.zhuang at linaro.org>
>>>     Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
>>>
>>> At the time, Haojian addressed a question about this patch regarding module
>>> dependencies, advising use of the deferred probe infrastructure.  But unless I'm
>>> mistaken, mine is an initcall level problem, not a dependency issue among driver
>>> probes.  Now that gpio-pxa initialization is at the device level (initcall6),
>>> calls to gpiolib are no longer possible from init_machine(), which remains at
>>> the initcall3 level.
>>>
>>> I feel like I must be missing something, because a lot of pxa boards call
>>> gpiolib from init machine(), so my breakage should not be an isolated case.
>>>
>>> If I'm not missing anything and the patch is necessary, it looks like one
>>> solution would be to move all the initializations that use gpiolib to the
>>> init_late method in struct machine_desc, which runs as initcall7.
>>>
>>> Grateful for any advice!
>>>
>>> Thanks,
>>> Mike
>>
>> Actually gpio request should be handled in the driver, not machine platform
>> driver. For example, lcd init may request gpio. pxafb.c provides the callback
>> to handle it. We need to move code of requesting gpio into the callback.
>
>
> Yes, I see.  Thanks for the example.
>
>
>>
>> Since this change breaks current platform, we have to revert it. We still need
>> a code cleanup in arch-pxa directory.
>
>
> I knew some cleanup was needed to the palm stuff, but didn't realize the extent.
>  Should not be too difficult; I hope to have patches soon.  But there are other
> pxa boards that grab various gpios in init_machine() and may not be as
> straightforward.
>
>
>>
>> Linus,
>> Could you help to revert this commit? Or do I need to send a revert commit
>> to you?
>
>
> Will the big guy see this?  Only posted to linux-arm-kernel ML.
>
> Thanks Haojian,
> Mike

Sorry, I forgot to loop him in.

Linus,
Should I send the revert commit to you? Or will you revert it directly?

Regards
Haojian


From horms at verge.net.au  Sun Apr 21 21:09:17 2013
From: horms at verge.net.au (Simon Horman)
Date: Mon, 22 Apr 2013 10:09:17 +0900
Subject: [PATCH v5 1/9] ARM: shmobile: Marzen: move USB EHCI, OHCI, and
 PHY devices to R8A7779 code
In-Reply-To: <51743BC0.20506@cogentembedded.com>
References: <201304200156.23830.sergei.shtylyov@cogentembedded.com>
 <51743BC0.20506@cogentembedded.com>
Message-ID: <20130422010917.GC15680@verge.net.au>

On Sun, Apr 21, 2013 at 11:19:28PM +0400, Sergei Shtylyov wrote:
> Hello.
> 
> On 04/20/2013 01:56 AM, Sergei Shtylyov wrote:
> 
> >USB EHCI, OHCI, and common PHY are the SoC devices but are wrongly defined and
> >registered in the Marzen board file.  Move the data and code to their proper
> >place in setup-r8a7779.c; while at it, we have to rename 8a7779_late_devices[]
> >to 8a7779_standard_devices[] -- this seems legitimate since they are registered
> 
>     I've been pointed to the types in the above variable names privately.
> Don't know should I resend or Simon could fix s/8a7779/r8a7779/ while
> applying... well, the USB patches haven't been ACK'ed yet.

I can fix that up.

Is the series waiting on anything?

> 
> >from r8a7779_add_standard_devices() anyway.
> >
> >Note that I'm deliberately changing the USB PHY platform device's 'id' field
> >from (previously just omitted) 0 to -1 as the device is a single of its kind.
> >
> >Note also that the board and SoC code have to be in one patch to keep the code
> >bisectable...
> >
> >The patch has been tested on the Marzen board.
> >
> >Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
> >Acked-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
> >Acked-by: Simon Horman <horms+renesas at verge.net.au>
> 
> WBR, Sergei
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


From horms at verge.net.au  Sun Apr 21 21:09:53 2013
From: horms at verge.net.au (Simon Horman)
Date: Mon, 22 Apr 2013 10:09:53 +0900
Subject: [PATCH v4 0/4] Add USB support to R8A7778/BOCK-W
In-Reply-To: <5171C4D4.8080607@cogentembedded.com>
References: <201304200207.07895.sergei.shtylyov@cogentembedded.com>
 <5171C4D4.8080607@cogentembedded.com>
Message-ID: <20130422010953.GD15680@verge.net.au>

On Sat, Apr 20, 2013 at 02:27:32AM +0400, Sergei Shtylyov wrote:
> Hello.
> 
> On 04/20/2013 02:07 AM, Sergei Shtylyov wrote:
> 
> >    Here's the set of 3 patches against the Simon Horman's 'renesas.git' repo,
> >'renesas-next-20130416' tag and the R8A7779/Marzen patchset I've posted.
> 
>    Sorry, it's against 'renesas-next-20130419' tag now.

Thanks, got it.


From rusty at rustcorp.com.au  Sun Apr 21 21:21:13 2013
From: rusty at rustcorp.com.au (Rusty Russell)
Date: Mon, 22 Apr 2013 10:51:13 +0930
Subject: [RFC] arm64: Early printk support for virtio-mmio console devices.
In-Reply-To: <CAAHg+HiHKV+8hBT1QWe4hSxocCX6wpRd3bCPWB7zU8jVFmPuAA@mail.gmail.com>
References: <1366264344-28025-1-git-send-email-pranavkumar@linaro.org>
 <87wqs02uws.fsf@rustcorp.com.au>
 <CAAHg+HiHKV+8hBT1QWe4hSxocCX6wpRd3bCPWB7zU8jVFmPuAA@mail.gmail.com>
Message-ID: <87ehe3bbsm.fsf@rustcorp.com.au>

Pranavkumar Sawargaonkar <pranavkumar at linaro.org> writes:
> On 18 April 2013 12:21, Rusty Russell <rusty at rustcorp.com.au> wrote:
>>
>> PranavkumarSawargaonkar <pranavkumar at linaro.org> writes:
>> > From: Pranavkumar Sawargaonkar <pranavkumar at linaro.org>
>> >
>> > This patch implements early printk support for virtio-mmio console devices without using any hypercalls.
>>
>> This makes some sense, though not sure that early console *read* makes
>> much sense.  I can see the PCI version of this being useful as well.
>
> Read can be useful for "mach-virt" which will have only virtio console
> as a console device. Then if someone wants to have UEFI or any other
> boot-loader emulation, which expects user to input few things, in that
> case read might become handy.

But implementing virtio inside a bootloader has already been done for
coreboot, for example.  A bootloader probably wants a virtio block
device, so a console is trivial.

A single writable field for debugging makes sense.  Anything more is far
less certain.

Thanks,
Rusty.


From Barry.Song at csr.com  Sun Apr 21 22:26:24 2013
From: Barry.Song at csr.com (Barry Song)
Date: Mon, 22 Apr 2013 02:26:24 +0000
Subject: [PATCHv5 00/11] Remove ARM local timer API
In-Reply-To: <1366388385-30722-1-git-send-email-sboyd@codeaurora.org>
References: <1366388385-30722-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <5EB3BFCD089AD643B9BB63439F5FD5E9012A244417@SHAASIEXM01.ASIA.ROOT.PRI>

> -----Original Message-----
> From: Stephen Boyd [mailto:sboyd at codeaurora.org]
> Sent: Saturday, April 20, 2013 12:20 AM
> To: linux-arm-kernel at lists.infradead.org
> Cc: linux-kernel at vger.kernel.org; linux-arm-msm at vger.kernel.org; Mark
> Rutland; Marc Zyngier; Kukjin Kim; Barry Song; Daniel Walker; Bryan Huntsman;
> Tony Lindgren; John Stultz; Thomas Gleixner; Thomas Abraham
> Subject: [PATCHv5 00/11] Remove ARM local timer API
> 
> In light of Mark Rutland's recent work on divorcing the ARM architected
> timers from the ARM local timer API and introducing a generic arch hook for
> broadcast it seems that we should remove the local timer API entirely.
> Doing so will reduce the architecture dependencies of our timer drivers,
> reduce code in ARM core, and simplify timer drivers because they no longer
> go through an architecture layer that is essentially a hotplug notifier.
> 
> Previous attempts have been made[1] unsuccessfully. I'm hoping this can
> be accepted now so that we can clean up the timer drivers that are
> used in both UP and SMP situations. Right now these drivers have to ignore
> the timer setup callback on the boot CPU to avoid registering clockevents
> twice. This is not very symmetric and causes convuluted code that does
> the same thing in two places.
> 
> Patches based on next-20130418
> 
> I'm still looking for Acks/Tested-by on EXYNOS and PRIMA2.

Stephen, I hope I can give a test soon. But I have some others in higher priority now.

> [1] http://article.gmane.org/gmane.linux.ports.arm.kernel/145705

-barry


Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at www.csr.com. Follow CSR on Twitter at http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog

From horms+renesas at verge.net.au  Sun Apr 21 23:06:30 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Mon, 22 Apr 2013 12:06:30 +0900
Subject: [PATCH] ARM: shmobile: lager: Add GPIO LEDs
Message-ID: <1366599990-31751-1-git-send-email-horms+renesas@verge.net.au>

The board has 3 LEDs connected to GPIOs. Add a led-gpio device to
support them.

Based on "ARM: shmobile: marzen: Add GPIO LEDs" by Laurent Pinchart.

Cc: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/board-lager.c | 37 ++++++++++++++++++++++++++++++++++++
 1 file changed, 37 insertions(+)

Tested on lager board.
Based on the tag renesas-next-20130419 of my renesas tree.

diff --git a/arch/arm/mach-shmobile/board-lager.c b/arch/arm/mach-shmobile/board-lager.c
index 6114edd..a8aa04f 100644
--- a/arch/arm/mach-shmobile/board-lager.c
+++ b/arch/arm/mach-shmobile/board-lager.c
@@ -21,13 +21,49 @@
 #include <linux/interrupt.h>
 #include <linux/irqchip.h>
 #include <linux/kernel.h>
+#include <linux/leds.h>
 #include <linux/pinctrl/machine.h>
+#include <linux/platform_data/gpio-rcar.h>
 #include <linux/platform_device.h>
 #include <mach/common.h>
 #include <mach/r8a7790.h>
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
 
+/* LEDS */
+static struct gpio_led lager_leds[] = {
+	{
+		.name		= "led8",
+		.gpio		= RCAR_GP_PIN(5, 17),
+		.default_state	= LEDS_GPIO_DEFSTATE_ON,
+	}, {
+		.name		= "led7",
+		.gpio		= RCAR_GP_PIN(4, 23),
+		.default_state	= LEDS_GPIO_DEFSTATE_ON,
+	}, {
+		.name		= "led6",
+		.gpio		= RCAR_GP_PIN(4, 22),
+		.default_state	= LEDS_GPIO_DEFSTATE_ON,
+	},
+};
+
+static struct gpio_led_platform_data lager_leds_pdata = {
+	.leds		= lager_leds,
+	.num_leds	= ARRAY_SIZE(lager_leds),
+};
+
+static struct platform_device leds_device = {
+	.name	= "leds-gpio",
+	.id	= 0,
+	.dev	= {
+		.platform_data  = &lager_leds_pdata,
+	},
+};
+
+static struct platform_device *lager_devices[] __initdata = {
+	&leds_device,
+};
+
 static const struct pinctrl_map lager_pinctrl_map[] = {
 	/* SCIF0 (CN19: DEBUG SERIAL0) */
 	PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.6", "pfc-r8a7790",
@@ -46,6 +82,7 @@ static void __init lager_add_standard_devices(void)
 	r8a7790_pinmux_init();
 
 	r8a7790_add_standard_devices();
+	platform_add_devices(lager_devices, ARRAY_SIZE(lager_devices));
 }
 
 static const char *lager_boards_compat_dt[] __initdata = {
-- 
1.8.2.1



From anup.patel at linaro.org  Sun Apr 21 23:10:56 2013
From: anup.patel at linaro.org (Anup Patel)
Date: Mon, 22 Apr 2013 08:40:56 +0530
Subject: [RFC] arm64: Early printk support for virtio-mmio console devices.
In-Reply-To: <87ehe3bbsm.fsf@rustcorp.com.au>
References: <1366264344-28025-1-git-send-email-pranavkumar@linaro.org>
 <87wqs02uws.fsf@rustcorp.com.au>
 <CAAHg+HiHKV+8hBT1QWe4hSxocCX6wpRd3bCPWB7zU8jVFmPuAA@mail.gmail.com>
 <87ehe3bbsm.fsf@rustcorp.com.au>
Message-ID: <CALrVBkub+TABrrBwh4+P6S5TGL1qSmnZrd1cbGgj6JiRpY=rOA@mail.gmail.com>

On 22 April 2013 06:51, Rusty Russell <rusty at rustcorp.com.au> wrote:
>
> Pranavkumar Sawargaonkar <pranavkumar at linaro.org> writes:
> > On 18 April 2013 12:21, Rusty Russell <rusty at rustcorp.com.au> wrote:
> >>
> >> PranavkumarSawargaonkar <pranavkumar at linaro.org> writes:
> >> > From: Pranavkumar Sawargaonkar <pranavkumar at linaro.org>
> >> >
> >> > This patch implements early printk support for virtio-mmio console
> >> > devices without using any hypercalls.
> >>
> >> This makes some sense, though not sure that early console *read* makes
> >> much sense.  I can see the PCI version of this being useful as well.
> >
> > Read can be useful for "mach-virt" which will have only virtio console
> > as a console device. Then if someone wants to have UEFI or any other
> > boot-loader emulation, which expects user to input few things, in that
> > case read might become handy.
>
> But implementing virtio inside a bootloader has already been done for
> coreboot, for example.  A bootloader probably wants a virtio block
> device, so a console is trivial.
>
> A single writable field for debugging makes sense.  Anything more is far
> less certain.

The early read can be handy for bootloader who don't want to implement
complete VirtIO programming.

IMHO, early read would be totally optional for host and will not
introduce any new config register so it is good to have in VirtIO
console spec. Also, without early read the read behavior of early_rw
field would be undefined in VirtIO console spec.

>
> Thanks,
> Rusty.

Best Regards,
Anup


From horms+renesas at verge.net.au  Sun Apr 21 23:45:03 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Mon, 22 Apr 2013 12:45:03 +0900
Subject: [PATCH] ARM: shmobile: sh73a0: Use IORESOURCE_MEM_* everywhere
Message-ID: <1366602303-31749-1-git-send-email-horms+renesas@verge.net.au>

Convert code to use IORESOURCE_MEM_* macros.
These macros were already used in this file,
this change makes their usage consistent throughout the file.

Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/setup-sh73a0.c | 79 ++++++-----------------------------
 1 file changed, 13 insertions(+), 66 deletions(-)

Based on the renesas-next-20130419 tag of my renesas tree.
Boot tested on the kzm9g board.

diff --git a/arch/arm/mach-shmobile/setup-sh73a0.c b/arch/arm/mach-shmobile/setup-sh73a0.c
index 658c0ad..2ac5f2f 100644
--- a/arch/arm/mach-shmobile/setup-sh73a0.c
+++ b/arch/arm/mach-shmobile/setup-sh73a0.c
@@ -244,12 +244,7 @@ static struct sh_timer_config tmu00_platform_data = {
 };
 
 static struct resource tmu00_resources[] = {
-	[0] = {
-		.name	= "TMU00",
-		.start	= 0xfff60008,
-		.end	= 0xfff60013,
-		.flags	= IORESOURCE_MEM,
-	},
+	[0] = DEFINE_RES_MEM_NAMED(0xfff60008, 0xc, "TMU00"),
 	[1] = {
 		.start	= intcs_evt2irq(0x0e80), /* TMU0_TUNI00 */
 		.flags	= IORESOURCE_IRQ,
@@ -274,12 +269,7 @@ static struct sh_timer_config tmu01_platform_data = {
 };
 
 static struct resource tmu01_resources[] = {
-	[0] = {
-		.name	= "TMU01",
-		.start	= 0xfff60014,
-		.end	= 0xfff6001f,
-		.flags	= IORESOURCE_MEM,
-	},
+	[0] = DEFINE_RES_MEM_NAMED(0xfff60014, 0xc, "TMU00"),
 	[1] = {
 		.start	= intcs_evt2irq(0x0ea0), /* TMU0_TUNI01 */
 		.flags	= IORESOURCE_IRQ,
@@ -297,12 +287,7 @@ static struct platform_device tmu01_device = {
 };
 
 static struct resource i2c0_resources[] = {
-	[0] = {
-		.name	= "IIC0",
-		.start	= 0xe6820000,
-		.end	= 0xe6820425 - 1,
-		.flags	= IORESOURCE_MEM,
-	},
+	[0] = DEFINE_RES_MEM_NAMED(0xe6820000, 0x426, "IIC0"),
 	[1] = {
 		.start	= gic_spi(167),
 		.end	= gic_spi(170),
@@ -311,12 +296,7 @@ static struct resource i2c0_resources[] = {
 };
 
 static struct resource i2c1_resources[] = {
-	[0] = {
-		.name	= "IIC1",
-		.start	= 0xe6822000,
-		.end	= 0xe6822425 - 1,
-		.flags	= IORESOURCE_MEM,
-	},
+	[0] = DEFINE_RES_MEM_NAMED(0xe6822000, 0x426, "IIC1"),
 	[1] = {
 		.start	= gic_spi(51),
 		.end	= gic_spi(54),
@@ -325,12 +305,7 @@ static struct resource i2c1_resources[] = {
 };
 
 static struct resource i2c2_resources[] = {
-	[0] = {
-		.name	= "IIC2",
-		.start	= 0xe6824000,
-		.end	= 0xe6824425 - 1,
-		.flags	= IORESOURCE_MEM,
-	},
+	[0] = DEFINE_RES_MEM_NAMED(0xe6824000, 0x426, "IIC2"),
 	[1] = {
 		.start	= gic_spi(171),
 		.end	= gic_spi(174),
@@ -339,12 +314,7 @@ static struct resource i2c2_resources[] = {
 };
 
 static struct resource i2c3_resources[] = {
-	[0] = {
-		.name	= "IIC3",
-		.start	= 0xe6826000,
-		.end	= 0xe6826425 - 1,
-		.flags	= IORESOURCE_MEM,
-	},
+	[0] = DEFINE_RES_MEM_NAMED(0xe6826000, 0x426, "IIC3"),
 	[1] = {
 		.start	= gic_spi(183),
 		.end	= gic_spi(186),
@@ -353,12 +323,7 @@ static struct resource i2c3_resources[] = {
 };
 
 static struct resource i2c4_resources[] = {
-	[0] = {
-		.name	= "IIC4",
-		.start	= 0xe6828000,
-		.end	= 0xe6828425 - 1,
-		.flags	= IORESOURCE_MEM,
-	},
+	[0] = DEFINE_RES_MEM_NAMED(0xe6828000, 0x426, "IIC4"),
 	[1] = {
 		.start	= gic_spi(187),
 		.end	= gic_spi(190),
@@ -579,12 +544,7 @@ static struct sh_dmae_pdata sh73a0_dmae_platform_data = {
 };
 
 static struct resource sh73a0_dmae_resources[] = {
-	{
-		/* Registers including DMAOR and channels including DMARSx */
-		.start  = 0xfe000020,
-		.end    = 0xfe008a00 - 1,
-		.flags  = IORESOURCE_MEM,
-	},
+	DEFINE_RES_MEM(0xfe000020, 0x89e0),
 	{
 		.name	= "error_irq",
 		.start  = gic_spi(129),
@@ -683,18 +643,10 @@ static struct sh_dmae_pdata sh73a0_mpdma_platform_data = {
 
 /* Resource order important! */
 static struct resource sh73a0_mpdma_resources[] = {
-	{
-		/* Channel registers and DMAOR */
-		.start	= 0xec618020,
-		.end	= 0xec61828f,
-		.flags	= IORESOURCE_MEM,
-	},
-	{
-		/* DMARSx */
-		.start	= 0xec619000,
-		.end	= 0xec61900b,
-		.flags	= IORESOURCE_MEM,
-	},
+	/* Channel registers and DMAOR */
+	DEFINE_RES_MEM(0xec618020, 0x270),
+	/* DMARSx */
+	DEFINE_RES_MEM(0xec619000, 0xc),
 	{
 		.name	= "error_irq",
 		.start	= gic_spi(181),
@@ -741,12 +693,7 @@ static struct platform_device pmu_device = {
 
 /* an IPMMU module for ICB */
 static struct resource ipmmu_resources[] = {
-	[0] = {
-		.name	= "IPMMU",
-		.start	= 0xfe951000,
-		.end	= 0xfe9510ff,
-		.flags	= IORESOURCE_MEM,
-	},
+	DEFINE_RES_MEM_NAMED(0xfe951000, 0x100, "IPMMU"),
 };
 
 static const char * const ipmmu_dev_names[] = {
-- 
1.8.2.1



From horms at verge.net.au  Sun Apr 21 23:45:54 2013
From: horms at verge.net.au (Simon Horman)
Date: Mon, 22 Apr 2013 12:45:54 +0900
Subject: [PATCH 1/8] ARM: shmobile:Marzen: move USB EHCI, OHCI, and PHY
 devices to R8A7779 code
In-Reply-To: <51712E2E.8040105@cogentembedded.com>
References: <201304050257.00799.sergei.shtylyov@cogentembedded.com>
 <20130418154425.GZ14496@n2100.arm.linux.org.uk>
 <5170301B.3030306@cogentembedded.com>
 <20130419021755.GF25718@verge.net.au>
 <51712E2E.8040105@cogentembedded.com>
Message-ID: <20130422034554.GI15680@verge.net.au>

On Fri, Apr 19, 2013 at 03:44:46PM +0400, Sergei Shtylyov wrote:
> Hello.
> 
> On 19-04-2013 6:17, Simon Horman wrote:
> 
> >>>>+/* USB PHY */
> >>>>+static struct resource usb_phy_resources[] = {
> >>>>+	[0] = {
> >>>>+		.start		= 0xffe70000,
> >>>>+		.end		= 0xffe70900 - 1,
> >>>>+		.flags		= IORESOURCE_MEM,
> >>>>+	},
> >>>>+	[1] = {
> >>>>+		.start		= 0xfff70000,
> >>>>+		.end		= 0xfff70900 - 1,
> >>>>+		.flags		= IORESOURCE_MEM,
> >>>>+	},
> 
> >>>Please consider using the macros for these initialisers.
> 
> >>    I'm just moving the code as is here. The destination file still
> >>uses old style initializers, and probably needs the wholesale
> >>conversion patch in the future.
> 
> >My preference is for you to either convert these users in this patch or
> >provide a patch that makes a wholesale conversion.
> 
>    I'll try to do the latter but my load is currently very high, so that
> may take some time.

Thanks. In the same vein I have posted the following patch to
convert the sh73a0 SoC to use the macros.

"[PATCH] ARM: shmobile: sh73a0: Use IORESOURCE_MEM_* everywhere"


From horms at verge.net.au  Mon Apr 22 00:00:43 2013
From: horms at verge.net.au (Simon Horman)
Date: Mon, 22 Apr 2013 13:00:43 +0900
Subject: [PATCH v3 4/4] ARM: shmobile: BOCK-W: enable USB in defconfig
In-Reply-To: <5171A7D8.2010000@cogentembedded.com>
References: <201304170135.10251.sergei.shtylyov@cogentembedded.com>
 <20130418140552.GO20929@verge.net.au>
 <5170789D.5020108@cogentembedded.com>
 <20130419021414.GB25718@verge.net.au>
 <5171A7D8.2010000@cogentembedded.com>
Message-ID: <20130422040043.GJ15680@verge.net.au>

On Sat, Apr 20, 2013 at 12:23:52AM +0400, Sergei Shtylyov wrote:
> On 04/19/2013 06:14 AM, Simon Horman wrote:
> >On Fri, Apr 19, 2013 at 02:50:05AM +0400, Sergei Shtylyov wrote:
> >>Hello.
> >>
> >>On 04/18/2013 06:05 PM, Simon Horman wrote:
> >>
> >>>>Enable USB platform EHCI/OHCI and common PHY drivers in 'bockw_defconfig'.
> >>>>Enable USB storage driver and SCSI disk driver that it needs as well...
> >>>>
> >>>>Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
> >>>I realise that this is not going to be useful until the rest
> >>>of the series has been merged. But regardless I have pre-emptively
> >>>queued it up for v3.11 in the defconfig-bockw branch.
> >>>>---
> >>>>  arch/arm/configs/bockw_defconfig |   11 ++++++++++-
> >>>>  1 file changed, 10 insertions(+), 1 deletion(-)
> >>>>
> >>>>Index: renesas/arch/arm/configs/bockw_defconfig
> >>>>===================================================================
> >>>>--- renesas.orig/arch/arm/configs/bockw_defconfig
> >>>>+++ renesas/arch/arm/configs/bockw_defconfig
> >>>>@@ -48,6 +48,8 @@ CONFIG_DEVTMPFS_MOUNT=y
> >>>>  # CONFIG_STANDALONE is not set
> >>>>  # CONFIG_PREVENT_FIRMWARE_BUILD is not set
> >>>>  # CONFIG_FW_LOADER is not set
> >>>>+CONFIG_SCSI=y
> >>>>+CONFIG_BLK_DEV_SD=y
> >>>>  CONFIG_NETDEVICES=y
> >>>>  # CONFIG_NET_CADENCE is not set
> >>>>  # CONFIG_NET_VENDOR_BROADCOM is not set
> >>>>@@ -71,7 +73,14 @@ CONFIG_SERIAL_SH_SCI_NR_UARTS=6
> >>>>  CONFIG_SERIAL_SH_SCI_CONSOLE=y
> >>>>  # CONFIG_HW_RANDOM is not set
> >>>>  # CONFIG_HWMON is not set
> >>>>-# CONFIG_USB_SUPPORT is not set
> >>>>+CONFIG_USB=y
> >>>>+CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
> >>>>+CONFIG_USB_EHCI_HCD=y
> >>>>+CONFIG_USB_OHCI_HCD=y
> >>>>+CONFIG_USB_OHCI_HCD_PLATFORM=y
> >>>>+CONFIG_USB_EHCI_HCD_PLATFORM=y
> >>>>+CONFIG_USB_STORAGE=y
> >>>>+CONFIG_USB_RCAR_PHY=y
> >>>>
> >>    Unfortunately, you've made a mistake in this last line of the patch:
> >>you've truncated it to just "CONFIG_USB_RCAR". :-(
> >>    Will you correct it?
> >Sorry about that, I will fix it.
> 
>     Sorry to say, but you fixed it the wrong way; now it's:
> 
> +CONFIG_USB_RCAR=y
> 
> instead of:
> 
> +CONFIG_USB_RCAR_PHY=y

Sorry for my carelessness.
I will forcibly push the following:

>From 26b78f5c9ad1e4809f6d0a5547e4eab222f53f23 Mon Sep 17 00:00:00 2001
From: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
Date: Wed, 17 Apr 2013 01:35:09 +0400
Subject: [PATCH] ARM: shmobile: BOCK-W: enable USB in defconfig

Enable USB platform EHCI/OHCI and common PHY drivers in 'bockw_defconfig'.
Enable USB storage driver and SCSI disk driver that it needs as well...

Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/configs/bockw_defconfig | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/arch/arm/configs/bockw_defconfig b/arch/arm/configs/bockw_defconfig
index a4bc76d..d662608 100644
--- a/arch/arm/configs/bockw_defconfig
+++ b/arch/arm/configs/bockw_defconfig
@@ -49,6 +49,8 @@ CONFIG_DEVTMPFS_MOUNT=y
 # CONFIG_STANDALONE is not set
 # CONFIG_PREVENT_FIRMWARE_BUILD is not set
 # CONFIG_FW_LOADER is not set
+CONFIG_SCSI=y
+CONFIG_BLK_DEV_SD=y
 CONFIG_NETDEVICES=y
 # CONFIG_NET_CADENCE is not set
 # CONFIG_NET_VENDOR_BROADCOM is not set
@@ -74,7 +76,14 @@ CONFIG_SERIAL_SH_SCI_CONSOLE=y
 # CONFIG_HWMON is not set
 CONFIG_I2C=y
 CONFIG_I2C_RCAR=y
-# CONFIG_USB_SUPPORT is not set
+CONFIG_USB=y
+CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
+CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_OHCI_HCD=y
+CONFIG_USB_OHCI_HCD_PLATFORM=y
+CONFIG_USB_EHCI_HCD_PLATFORM=y
+CONFIG_USB_STORAGE=y
+CONFIG_USB_RCAR_PHY=y
 CONFIG_MMC=y
 CONFIG_MMC_SDHI=y
 CONFIG_UIO=y
-- 
1.8.2.1



From horms at verge.net.au  Mon Apr 22 00:21:20 2013
From: horms at verge.net.au (Simon Horman)
Date: Mon, 22 Apr 2013 13:21:20 +0900
Subject: [PATCH 0/5] OKI ML86V7667 driver and R8A7778/BOCK-W VIN support
In-Reply-To: <201304210013.46110.sergei.shtylyov@cogentembedded.com>
References: <201304210013.46110.sergei.shtylyov@cogentembedded.com>
Message-ID: <20130422042120.GN15680@verge.net.au>

On Sun, Apr 21, 2013 at 12:13:45AM +0400, Sergei Shtylyov wrote:
> Hello.
> 
>    Here's the set of 4 patches against the Simon Horman's 'renesas.git' repo,
> 'renesas-next-20130419' tag and my recent yet unapplied patches. Here we
> add the OKI ML86V7667 video decoder driver and the VIN platform code working on
> the R8A7778/BOCK-W with ML86V7667. The driver patch also applies (with offsets)
> to Mauro's 'media_tree.git'...
> 
> [1/5] V4L2: I2C: ML86V7667 video decoder driver
> [2/5] sh-pfc: r8a7778: add VIN pin groups
> [3/5] ARM: shmobile: r8a7778: add VIN support
> [4/5] ARM: shmobile: BOCK-W: add VIN and ADV7180 support
> [5/5] ARM: shmobile: BOCK-W: enable VIN and ADV7180 in defconfig

Hi Sergei,

it seems to me that patches 2 and 3 of the series could
be applied to my tree without further delay. Would you
like me to do that?


From weiyj.lk at gmail.com  Mon Apr 22 00:39:56 2013
From: weiyj.lk at gmail.com (Wei Yongjun)
Date: Mon, 22 Apr 2013 12:39:56 +0800
Subject: [PATCH -next] ARM: vexpress: remove duplicated include from v2m.c
Message-ID: <CAPgLHd-hTihxfc8CS2E2ZsfwFHf7oN5o4oicWOXo_dwcFhg2kA@mail.gmail.com>

From: Wei Yongjun <yongjun_wei at trendmicro.com.cn>

Remove duplicated include.

Signed-off-by: Wei Yongjun <yongjun_wei at trendmicro.com.cn>
---
 arch/arm/mach-vexpress/v2m.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/mach-vexpress/v2m.c b/arch/arm/mach-vexpress/v2m.c
index b6083bb..d07048c 100644
--- a/arch/arm/mach-vexpress/v2m.c
+++ b/arch/arm/mach-vexpress/v2m.c
@@ -6,7 +6,6 @@
 #include <linux/amba/bus.h>
 #include <linux/amba/mmci.h>
 #include <linux/io.h>
-#include <linux/clocksource.h>
 #include <linux/smp.h>
 #include <linux/init.h>
 #include <linux/irqchip.h>



From horms at verge.net.au  Mon Apr 22 00:52:49 2013
From: horms at verge.net.au (Simon Horman)
Date: Mon, 22 Apr 2013 13:52:49 +0900
Subject: [PATCH v2 0/1] Add I2C support to R8A7778/BOCK-W
In-Reply-To: <5171C4FE.9000807@cogentembedded.com>
References: <201304200217.32844.sergei.shtylyov@cogentembedded.com>
 <5171C4FE.9000807@cogentembedded.com>
Message-ID: <20130422045248.GO15680@verge.net.au>

On Sat, Apr 20, 2013 at 02:28:14AM +0400, Sergei Shtylyov wrote:
> On 04/20/2013 02:17 AM, Sergei Shtylyov wrote:
> 
> >    Here's the patch against the Simon Horman's 'renesas.git' repo,
> >'renesas-next-20130417' tag and my recent yet unapplied USB patches.
> 
>    Sorry, it's against 'renesas-next-20130419' tag now.

Sorry, it doesn't seem to apply cleanly on top of
renesas-next-20130417 or renesas-next-20130419.

Could you please rebase, add Morimoto-san's Acked-by and repost?

Thanks


From shawn.guo at linaro.org  Mon Apr 22 00:56:01 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Mon, 22 Apr 2013 12:56:01 +0800
Subject: [PATCH] ARM: imx: move imx53-qsb audio codec clk lookup into DT
Message-ID: <1366606561-18805-1-git-send-email-shawn.guo@linaro.org>

With device tree clk lookup support in place, we can move audio codec
clk lookup for ssi_ext1 into device tree now, so that imx53_qsb_init()
can be saved.

Since ssi_ext2 lookup is used nowhere, it gets removed together with
ssi_ext1 lookup from clk driver.

Signed-off-by: Shawn Guo <shawn.guo at linaro.org>
---
 arch/arm/boot/dts/imx53-qsb.dts     |    1 +
 arch/arm/mach-imx/clk-imx51-imx53.c |    2 --
 arch/arm/mach-imx/mach-imx53.c      |   16 ----------------
 3 files changed, 1 insertion(+), 18 deletions(-)

diff --git a/arch/arm/boot/dts/imx53-qsb.dts b/arch/arm/boot/dts/imx53-qsb.dts
index 8f0e9ae..ed47e43 100644
--- a/arch/arm/boot/dts/imx53-qsb.dts
+++ b/arch/arm/boot/dts/imx53-qsb.dts
@@ -147,6 +147,7 @@
 		reg = <0x0a>;
 		VDDA-supply = <&reg_3p2v>;
 		VDDIO-supply = <&reg_3p2v>;
+		clocks = <&clks 150>;
 	};
 };
 
diff --git a/arch/arm/mach-imx/clk-imx51-imx53.c b/arch/arm/mach-imx/clk-imx51-imx53.c
index 6fc486b..adea706 100644
--- a/arch/arm/mach-imx/clk-imx51-imx53.c
+++ b/arch/arm/mach-imx/clk-imx51-imx53.c
@@ -310,8 +310,6 @@ static void __init mx5_clocks_common_init(unsigned long rate_ckil,
 	clk_register_clkdev(clk[ssi1_ipg_gate], NULL, "imx-ssi.0");
 	clk_register_clkdev(clk[ssi2_ipg_gate], NULL, "imx-ssi.1");
 	clk_register_clkdev(clk[ssi3_ipg_gate], NULL, "imx-ssi.2");
-	clk_register_clkdev(clk[ssi_ext1_gate], "ssi_ext1", NULL);
-	clk_register_clkdev(clk[ssi_ext2_gate], "ssi_ext2", NULL);
 	clk_register_clkdev(clk[sdma_gate], NULL, "imx35-sdma");
 	clk_register_clkdev(clk[cpu_podf], NULL, "cpufreq-cpu0.0");
 	clk_register_clkdev(clk[iim_gate], "iim", NULL);
diff --git a/arch/arm/mach-imx/mach-imx53.c b/arch/arm/mach-imx/mach-imx53.c
index f579c61..8d47571 100644
--- a/arch/arm/mach-imx/mach-imx53.c
+++ b/arch/arm/mach-imx/mach-imx53.c
@@ -23,24 +23,8 @@
 #include "common.h"
 #include "mx53.h"
 
-static void __init imx53_qsb_init(void)
-{
-	struct clk *clk;
-
-	clk = clk_get_sys(NULL, "ssi_ext1");
-	if (IS_ERR(clk)) {
-		pr_err("failed to get clk ssi_ext1\n");
-		return;
-	}
-
-	clk_register_clkdev(clk, NULL, "0-000a");
-}
-
 static void __init imx53_dt_init(void)
 {
-	if (of_machine_is_compatible("fsl,imx53-qsb"))
-		imx53_qsb_init();
-
 	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
 }
 
-- 
1.7.9.5




From horms at verge.net.au  Mon Apr 22 00:57:58 2013
From: horms at verge.net.au (Simon Horman)
Date: Mon, 22 Apr 2013 13:57:58 +0900
Subject: [PATCH v2 2/4] ARM: shmobile: r8a7779: add VIN support
In-Reply-To: <5171DD05.6020400@cogentembedded.com>
References: <201304200232.33731.sergei.shtylyov@cogentembedded.com>
 <5171DD05.6020400@cogentembedded.com>
Message-ID: <20130422045758.GP15680@verge.net.au>

On Sat, Apr 20, 2013 at 04:10:45AM +0400, Sergei Shtylyov wrote:
> Hello.
> 
> On 04/20/2013 02:32 AM, Sergei Shtylyov wrote:
> 
> >From: Vladimir Barinov <vladimir.barinov at cogentembedded.com>
> >
> >Add VIN clocks and platform devices for R8A7779 SoC; add function to register
> >the VIN platform devices.
> >
> >Signed-off-by: Vladimir Barinov <vladimir.barinov at cogentembedded.com>
> >[Sergei: added 'id' parameter check to r8a7779_add_vin_device(), renamed some
> >variables.]
> >Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
> 
> [...]
> 
> >Index: renesas/arch/arm/mach-shmobile/setup-r8a7779.c
> >===================================================================
> >--- renesas.orig/arch/arm/mach-shmobile/setup-r8a7779.c
> >+++ renesas/arch/arm/mach-shmobile/setup-r8a7779.c
> >@@ -559,6 +559,33 @@ static struct resource ether_resources[]
> >  	},
> >  };
> >+#define R8A7779_VIN(idx) \
> >+static struct resource vin##idx##_resources[] = {		\
> >+	DEFINE_RES_MEM(0xffc50000 + 0x1000 * (idx), 0x1000),	\
> >+	DEFINE_RES_IRQ(gic_iid(0x5f + (idx))),			\
> >+};								\
> >+								\
> >+static struct platform_device_info vin##idx##_info = {		\
> 
>    Hm, probably should have marked this as '__initdata'... maybe
> the resources too.

That doesn't seem to be the case for other devices in
that or other shmobile files. Am I missing something
or should numerous other devices be updated?

> 
> >+	.parent		= &platform_bus,			\
> >+	.name		= "rcar_vin",				\
> >+	.id		= idx,					\
> >+	.res		= vin##idx##_resources,			\
> >+	.num_res	= ARRAY_SIZE(vin##idx##_resources),	\
> >+	.dma_mask	= DMA_BIT_MASK(32),			\
> >+}
> >
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


From shawn.guo at linaro.org  Mon Apr 22 01:00:52 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Mon, 22 Apr 2013 13:00:52 +0800
Subject: [PATCH 1/8] ARM: mx5: Add AUDMUX4 pinctrl data
In-Reply-To: <1366579808-12067-1-git-send-email-marex@denx.de>
References: <1366579808-12067-1-git-send-email-marex@denx.de>
Message-ID: <20130422050049.GB10821@S2101-09.ap.freescale.net>

On Sun, Apr 21, 2013 at 11:30:01PM +0200, Marek Vasut wrote:
> This patch adds pinctrl data for the AUDMUX4 on MX53.
> 
> Signed-off-by: Marek Vasut <marex at denx.de>
> Cc: Fabio Estevam <fabio.estevam at freescale.com>
> Cc: Shawn Guo <shawn.guo at linaro.org>

Applied 1~7, with some small fixups (see replies).



From shawn.guo at linaro.org  Mon Apr 22 01:02:57 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Mon, 22 Apr 2013 13:02:57 +0800
Subject: [PATCH 5/8] ARM: mx5: Add NAND pinctrl data
In-Reply-To: <1366579808-12067-5-git-send-email-marex@denx.de>
References: <1366579808-12067-1-git-send-email-marex@denx.de>
 <1366579808-12067-5-git-send-email-marex@denx.de>
Message-ID: <20130422050254.GC10821@S2101-09.ap.freescale.net>

On Sun, Apr 21, 2013 at 11:30:05PM +0200, Marek Vasut wrote:
> This patch adds pinctrl data for NAND on MX53.
> 
> Signed-off-by: Marek Vasut <marex at denx.de>
> Cc: Fabio Estevam <fabio.estevam at freescale.com>
> Cc: Shawn Guo <shawn.guo at linaro.org>
> ---
>  arch/arm/boot/dts/imx53.dtsi |   21 +++++++++++++++++++++
>  1 file changed, 21 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/imx53.dtsi b/arch/arm/boot/dts/imx53.dtsi
> index 09145e2..7574026 100644
> --- a/arch/arm/boot/dts/imx53.dtsi
> +++ b/arch/arm/boot/dts/imx53.dtsi
> @@ -575,6 +575,27 @@
>  					};
>  				};
>  
> +				nand {

I put it before node "owire" to have it somehow sorted.

Shawn

> +					pinctrl_nand_1: nandgrp-1 {
> +						fsl,pins = <
> +							MX53_PAD_NANDF_WE_B__EMI_NANDF_WE_B	0x4
> +							MX53_PAD_NANDF_RE_B__EMI_NANDF_RE_B	0x4
> +							MX53_PAD_NANDF_CLE__EMI_NANDF_CLE	0x4
> +							MX53_PAD_NANDF_ALE__EMI_NANDF_ALE	0x4
> +							MX53_PAD_NANDF_WP_B__EMI_NANDF_WP_B	0xe0
> +							MX53_PAD_NANDF_RB0__EMI_NANDF_RB_0	0xe0
> +							MX53_PAD_NANDF_CS0__EMI_NANDF_CS_0	0x4
> +							MX53_PAD_PATA_DATA0__EMI_NANDF_D_0	0xa4
> +							MX53_PAD_PATA_DATA1__EMI_NANDF_D_1	0xa4
> +							MX53_PAD_PATA_DATA2__EMI_NANDF_D_2	0xa4
> +							MX53_PAD_PATA_DATA3__EMI_NANDF_D_3	0xa4
> +							MX53_PAD_PATA_DATA4__EMI_NANDF_D_4	0xa4
> +							MX53_PAD_PATA_DATA5__EMI_NANDF_D_5	0xa4
> +							MX53_PAD_PATA_DATA6__EMI_NANDF_D_6	0xa4
> +							MX53_PAD_PATA_DATA7__EMI_NANDF_D_7	0xa4
> +						>;
> +					};
> +				};
>  			};
>  
>  			gpr: iomuxc-gpr at 53fa8000 {
> -- 
> 1.7.10.4
> 



From shawn.guo at linaro.org  Mon Apr 22 01:05:01 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Mon, 22 Apr 2013 13:05:01 +0800
Subject: [PATCH 6/8] ARM: mx5: Add LCD IPU pinctrl data
In-Reply-To: <1366579808-12067-6-git-send-email-marex@denx.de>
References: <1366579808-12067-1-git-send-email-marex@denx.de>
 <1366579808-12067-6-git-send-email-marex@denx.de>
Message-ID: <20130422050457.GD10821@S2101-09.ap.freescale.net>

On Sun, Apr 21, 2013 at 11:30:06PM +0200, Marek Vasut wrote:
> This patch adds pinmux for IPU LCD 1 and IPU LVDS.
> 
> Signed-off-by: Marek Vasut <marex at denx.de>
> ---
>  arch/arm/boot/dts/imx53.dtsi |   57 ++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 57 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/imx53.dtsi b/arch/arm/boot/dts/imx53.dtsi
> index 7574026..91fc8cc 100644
> --- a/arch/arm/boot/dts/imx53.dtsi
> +++ b/arch/arm/boot/dts/imx53.dtsi
> @@ -513,6 +513,63 @@
>  					};
>  				};
>  
> +				ipu_disp1 {
> +					pinctrl_ipu_disp1_1: ipudisp1grp-1 {
> +						fsl,pins = <
> +							MX53_PAD_EIM_DA9__IPU_DISP1_DAT_0	0x5
> +							MX53_PAD_EIM_DA8__IPU_DISP1_DAT_1	0x5
> +							MX53_PAD_EIM_DA7__IPU_DISP1_DAT_2	0x5
> +							MX53_PAD_EIM_DA6__IPU_DISP1_DAT_3	0x5
> +							MX53_PAD_EIM_DA5__IPU_DISP1_DAT_4	0x5
> +							MX53_PAD_EIM_DA4__IPU_DISP1_DAT_5	0x5
> +							MX53_PAD_EIM_DA3__IPU_DISP1_DAT_6	0x5
> +							MX53_PAD_EIM_DA2__IPU_DISP1_DAT_7	0x5
> +							MX53_PAD_EIM_DA1__IPU_DISP1_DAT_8	0x5
> +							MX53_PAD_EIM_DA0__IPU_DISP1_DAT_9	0x5
> +							MX53_PAD_EIM_EB1__IPU_DISP1_DAT_10	0x5
> +							MX53_PAD_EIM_EB0__IPU_DISP1_DAT_11	0x5
> +							MX53_PAD_EIM_A17__IPU_DISP1_DAT_12	0x5
> +							MX53_PAD_EIM_A18__IPU_DISP1_DAT_13	0x5
> +							MX53_PAD_EIM_A19__IPU_DISP1_DAT_14	0x5
> +							MX53_PAD_EIM_A20__IPU_DISP1_DAT_15	0x5
> +							MX53_PAD_EIM_A21__IPU_DISP1_DAT_16	0x5
> +							MX53_PAD_EIM_A22__IPU_DISP1_DAT_17	0x5
> +							MX53_PAD_EIM_A23__IPU_DISP1_DAT_18	0x5
> +							MX53_PAD_EIM_A24__IPU_DISP1_DAT_19	0x5
> +							MX53_PAD_EIM_D31__IPU_DISP1_DAT_20	0x5
> +							MX53_PAD_EIM_D30__IPU_DISP1_DAT_21	0x5
> +							MX53_PAD_EIM_D26__IPU_DISP1_DAT_22	0x5
> +							MX53_PAD_EIM_D27__IPU_DISP1_DAT_23	0x5
> +							MX53_PAD_EIM_A16__IPU_DI1_DISP_CLK	0x5
> +							MX53_PAD_EIM_DA13__IPU_DI1_D0_CS	0x5
> +							MX53_PAD_EIM_DA14__IPU_DI1_D1_CS	0x5
> +							MX53_PAD_EIM_DA15__IPU_DI1_PIN1	0x5
> +							MX53_PAD_EIM_DA11__IPU_DI1_PIN2	0x5
> +							MX53_PAD_EIM_DA12__IPU_DI1_PIN3	0x5
> +							MX53_PAD_EIM_A25__IPU_DI1_PIN12	0x5

I fixed the indent a little bit to have 0x5 aligned with above one.

> +							MX53_PAD_EIM_DA10__IPU_DI1_PIN15	0x5
> +						>;
> +					};
> +				};
> +
> +				ipu_disp2 {
> +					pinctrl_ipu_disp2_1: ipudisp2grp-1 {
> +						fsl,pins = <
> +							MX53_PAD_LVDS0_TX0_P__LDB_LVDS0_TX0	0x80000000
> +							MX53_PAD_LVDS0_TX1_P__LDB_LVDS0_TX1	0x80000000
> +							MX53_PAD_LVDS0_TX2_P__LDB_LVDS0_TX2	0x80000000
> +							MX53_PAD_LVDS0_TX3_P__LDB_LVDS0_TX3	0x80000000
> +							MX53_PAD_LVDS0_CLK_P__LDB_LVDS0_CLK	0x80000000
> +
I removed this new line.

> +							MX53_PAD_LVDS1_TX0_P__LDB_LVDS1_TX0	0x80000000
> +							MX53_PAD_LVDS1_TX1_P__LDB_LVDS1_TX1	0x80000000
> +							MX53_PAD_LVDS1_TX2_P__LDB_LVDS1_TX2	0x80000000
> +							MX53_PAD_LVDS1_TX3_P__LDB_LVDS1_TX3	0x80000000
> +							MX53_PAD_LVDS1_CLK_P__LDB_LVDS1_CLK	0x80000000
> +						>;
> +					};
> +				};
> +

I put the nodes after i2c ones.

Shawn

>  				uart1 {
>  					pinctrl_uart1_1: uart1grp-1 {
>  						fsl,pins = <
> -- 
> 1.7.10.4
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel



From shawn.guo at linaro.org  Mon Apr 22 01:05:49 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Mon, 22 Apr 2013 13:05:49 +0800
Subject: [PATCH 7/8] ARM: mx5: Add PWM1 pinctrl data
In-Reply-To: <1366579808-12067-7-git-send-email-marex@denx.de>
References: <1366579808-12067-1-git-send-email-marex@denx.de>
 <1366579808-12067-7-git-send-email-marex@denx.de>
Message-ID: <20130422050547.GE10821@S2101-09.ap.freescale.net>

On Sun, Apr 21, 2013 at 11:30:07PM +0200, Marek Vasut wrote:
> This patch adds pinctrl data for PWM1 on MX53.
> 
> Signed-off-by: Marek Vasut <marex at denx.de>
> ---
>  arch/arm/boot/dts/imx53.dtsi |    8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/imx53.dtsi b/arch/arm/boot/dts/imx53.dtsi
> index 91fc8cc..c343ba6 100644
> --- a/arch/arm/boot/dts/imx53.dtsi
> +++ b/arch/arm/boot/dts/imx53.dtsi
> @@ -653,6 +653,14 @@
>  						>;
>  					};
>  				};
> +
> +				pwm1 {

I put the node after owire.

Shawn

> +					pinctrl_pwm1_1: pwm1grp-1 {
> +						fsl,pins = <
> +							MX53_PAD_DISP0_DAT8__PWM1_PWMO	0x5
> +						>;
> +					};
> +				};
>  			};
>  
>  			gpr: iomuxc-gpr at 53fa8000 {
> -- 
> 1.7.10.4
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel



From dhobsong at igel.co.jp  Mon Apr 22 01:07:40 2013
From: dhobsong at igel.co.jp (Damian Hobson-Garcia)
Date: Mon, 22 Apr 2013 14:07:40 +0900
Subject: [RFC/PATCH 0/4] dma-mapping: Define dma_{alloc,
 free}_attrs() for all archs
Message-ID: <1366607260-2852-1-git-send-email-dhobsong@igel.co.jp>

Most architectures that define CONFIG_HAVE_DMA=y, have implementations for
both dma_alloc_attrs() and dma_free_attrs().  All achitectures that do
not define CONFIG_HAVE_DMA also have both of these definitions provided by
dma-mapping-broken.h.

Provide a default definition for the archs that define CONFIG_HAVE_DMA=y,
but have no implementation for dma_{alloc,free}_attrs() by simply calling
dma_{alloc,free}_coherent() and throwing away the attrs argument.

Damian Hobson-Garcia (4):
  Provide default implementation for dma_{alloc,free}_attrs on arm64
  Provide default implementation for dma_{alloc,free}_attrs on c6x
  Provide default implementation for dma_{alloc,free}_attrs on parisc
  Provide default implementation for dma_{alloc,free}_attrs on s390

 arch/arm64/include/asm/dma-mapping.h  |    3 +++
 arch/c6x/include/asm/dma-mapping.h    |    3 +++
 arch/parisc/include/asm/dma-mapping.h |    3 +++
 arch/s390/include/asm/dma-mapping.h   |    3 +++
 4 files changed, 12 insertions(+), 0 deletions(-)

-- 
1.7.5.4



From gang.chen at asianux.com  Mon Apr 22 01:08:22 2013
From: gang.chen at asianux.com (Chen Gang)
Date: Mon, 22 Apr 2013 13:08:22 +0800
Subject: [Suggestion] ARM64: kernel: compiling issue,
 need implement cmpxchg64 with assembler language.
In-Reply-To: <2182812.ymprEm6XBb@wuerfel>
References: <51712E5E.2020809@asianux.com> <201304191412.54601.arnd@arndb.de>
 <5171FD67.2080104@asianux.com> <2182812.ymprEm6XBb@wuerfel>
Message-ID: <5174C5C6.5010206@asianux.com>

On 2013?04?20? 15:32, Arnd Bergmann wrote:
> On Saturday 20 April 2013 10:28:55 Chen Gang wrote:
>>
>> -------------------------------patch begin--------------------------------------
>>
>> diff --git a/arch/arm64/include/asm/cmpxchg.h b/arch/arm64/include/asm/cmpxchg.h
>> index 968b5cb..b572d2b 100644
>> --- a/arch/arm64/include/asm/cmpxchg.h
>> +++ b/arch/arm64/include/asm/cmpxchg.h
>> @@ -170,4 +170,6 @@ static inline unsigned long __cmpxchg_mb(volatile void *ptr, unsigned long old,
>>                                        (unsigned long)(n),              \
>>                                        sizeof(*(ptr))))
>>  
>> +#define cmpxchg64(ptr,o,n)     cmpxchg((ptr),(o),(n))
>> +
>>  #endif /* __ASM_CMPXCHG_H */
> 
> Yes, this looks good. Please provide the same for cmpxchg64_local.
> 

  ok, thanks, I will send related patch.


gchen.



From dhobsong at igel.co.jp  Mon Apr 22 01:09:09 2013
From: dhobsong at igel.co.jp (Damian Hobson-Garcia)
Date: Mon, 22 Apr 2013 14:09:09 +0900
Subject: [RFC/PATCH 1/4] arm64: Provide default implementation for dma_{alloc,
 free}_attrs
Message-ID: <1366607349-2992-1-git-send-email-dhobsong@igel.co.jp>

Most architectures that define CONFIG_HAVE_DMA, have implementations for
both dma_alloc_attrs() and dma_free_attrs().  All achitectures that do
not define CONFIG_HAVE_DMA also have both of these definitions provided by
dma-mapping-broken.h.

Add default implementations for these functions on arm64.

Signed-off-by: Damian Hobson-Garcia <dhobsong at igel.co.jp>
---
 arch/arm64/include/asm/dma-mapping.h |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/arm64/include/asm/dma-mapping.h b/arch/arm64/include/asm/dma-mapping.h
index 9947768..65ab181 100644
--- a/arch/arm64/include/asm/dma-mapping.h
+++ b/arch/arm64/include/asm/dma-mapping.h
@@ -81,6 +81,9 @@ static inline void dma_mark_clean(void *addr, size_t size)
 {
 }
 
+#define dma_alloc_attrs(d, s, h, f, a) dma_alloc_coherent(d, s, h, f)
+#define dma_free_attrs(d, s, h, f, a) dma_free_coherent(d, s, h, f)
+
 static inline void *dma_alloc_coherent(struct device *dev, size_t size,
 				       dma_addr_t *dma_handle, gfp_t flags)
 {
-- 
1.7.5.4



From horms at verge.net.au  Mon Apr 22 01:09:23 2013
From: horms at verge.net.au (Simon Horman)
Date: Mon, 22 Apr 2013 14:09:23 +0900
Subject: [PATCH v2 0/1] Add I2C support to R8A7778/BOCK-W
In-Reply-To: <20130422045248.GO15680@verge.net.au>
References: <201304200217.32844.sergei.shtylyov@cogentembedded.com>
 <5171C4FE.9000807@cogentembedded.com>
 <20130422045248.GO15680@verge.net.au>
Message-ID: <20130422050923.GA1817@verge.net.au>

On Mon, Apr 22, 2013 at 01:52:49PM +0900, Simon Horman wrote:
> On Sat, Apr 20, 2013 at 02:28:14AM +0400, Sergei Shtylyov wrote:
> > On 04/20/2013 02:17 AM, Sergei Shtylyov wrote:
> > 
> > >    Here's the patch against the Simon Horman's 'renesas.git' repo,
> > >'renesas-next-20130417' tag and my recent yet unapplied USB patches.
> > 
> >    Sorry, it's against 'renesas-next-20130419' tag now.
> 
> Sorry, it doesn't seem to apply cleanly on top of
> renesas-next-20130417 or renesas-next-20130419.
> 
> Could you please rebase, add Morimoto-san's Acked-by and repost?

Please ignore that, I see your USB patches are part of the base.


From gang.chen at asianux.com  Mon Apr 22 01:08:41 2013
From: gang.chen at asianux.com (Chen Gang)
Date: Mon, 22 Apr 2013 13:08:41 +0800
Subject: [PATCH] ARM64: kernel: compiling issue,
 define cmpxchg64 and cmpxchg64_local for outside using.
In-Reply-To: <2182812.ymprEm6XBb@wuerfel>
References: <51712E5E.2020809@asianux.com> <201304191412.54601.arnd@arndb.de>
 <5171FD67.2080104@asianux.com> <2182812.ymprEm6XBb@wuerfel>
Message-ID: <5174C5D9.3060109@asianux.com>


  drivers use cmpxchg64, cmpxchg64_local ... to perform 64-bit operation,
  so they can cross 32-bit and 64-bit platforms (it is a standard way).


Signed-off-by: Chen Gang <gang.chen at asianux.com>
---
 arch/arm64/include/asm/cmpxchg.h |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/arm64/include/asm/cmpxchg.h b/arch/arm64/include/asm/cmpxchg.h
index 968b5cb..8a8ce0e 100644
--- a/arch/arm64/include/asm/cmpxchg.h
+++ b/arch/arm64/include/asm/cmpxchg.h
@@ -170,4 +170,7 @@ static inline unsigned long __cmpxchg_mb(volatile void *ptr, unsigned long old,
 				       (unsigned long)(n),		\
 				       sizeof(*(ptr))))
 
+#define cmpxchg64(ptr,o,n)		cmpxchg((ptr),(o),(n))
+#define cmpxchg64_local(ptr,o,n)	cmpxchg_local((ptr),(o),(n))
+
 #endif	/* __ASM_CMPXCHG_H */
-- 
1.7.7.6


From shawn.guo at linaro.org  Mon Apr 22 01:19:19 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Mon, 22 Apr 2013 13:19:19 +0800
Subject: [PATCH 8/8] ARM: mx5: Add support for DENX M53EVK
In-Reply-To: <1366579808-12067-8-git-send-email-marex@denx.de>
References: <1366579808-12067-1-git-send-email-marex@denx.de>
 <1366579808-12067-8-git-send-email-marex@denx.de>
Message-ID: <20130422051916.GF10821@S2101-09.ap.freescale.net>

On Sun, Apr 21, 2013 at 11:30:08PM +0200, Marek Vasut wrote:
> This patch adds support for the DENX M53EVK board. The board currently supports
> NAND, Ethernet, UART, CAN, I2C.
> 
> Signed-off-by: Marek Vasut <marex at denx.de>
> Cc: Fabio Estevam <fabio.estevam at freescale.com>
> Cc: Shawn Guo <shawn.guo at linaro.org>
> ---
>  arch/arm/boot/dts/Makefile         |    1 +
>  arch/arm/boot/dts/imx53-m53evk.dts |  282 ++++++++++++++++++++++++++++++++++++
>  arch/arm/mach-imx/mach-imx53.c     |   16 +-
>  3 files changed, 297 insertions(+), 2 deletions(-)
>  create mode 100644 arch/arm/boot/dts/imx53-m53evk.dts
> 
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 4fd1f62..1fbec6b 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -107,6 +107,7 @@ dtb-$(CONFIG_ARCH_MXC) += \
>  	imx51-babbage.dtb \
>  	imx53-ard.dtb \
>  	imx53-evk.dtb \
> +	imx53-m53evk.dtb \
>  	imx53-mba53.dtb \
>  	imx53-qsb.dtb \
>  	imx53-smd.dtb \
> diff --git a/arch/arm/boot/dts/imx53-m53evk.dts b/arch/arm/boot/dts/imx53-m53evk.dts
> new file mode 100644
> index 0000000..32f8ff4
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx53-m53evk.dts
> @@ -0,0 +1,282 @@
> +/*
> + * Copyright (C) 2013 Marek Vasut <marex at denx.de>
> + *
> + * The code contained herein is licensed under the GNU General Public
> + * License. You may obtain a copy of the GNU General Public License
> + * Version 2 or later at the following locations:
> + *
> + * http://www.opensource.org/licenses/gpl-license.html
> + * http://www.gnu.org/copyleft/gpl.html
> + */
> +
> +/dts-v1/;
> +#include "imx53.dtsi"
> +
> +/ {
> +	model = "DENX M53EVK";
> +	compatible = "denx,imx53-m53evk", "fsl,imx53";
> +
> +	memory {
> +		reg = <0x70000000 0x20000000>;
> +	};
> +
> +	soc {
> +		display at di0 {
> +			compatible = "fsl,imx-parallel-display";
> +			crtcs = <&ipu 0>;
> +			interface-pix-fmt = "rgb24";
> +			pinctrl-names = "default";
> +			pinctrl-0 = <&pinctrl_ipu_disp1_1>;
> +
> +			display-timings {
> +				800x480p60 {
> +					native-mode;
> +					clock-frequency = <31500000>;
> +					hactive = <800>;
> +					vactive = <480>;
> +					hfront-porch = <40>;
> +					hback-porch = <88>;
> +					hsync-len = <128>;
> +					vback-porch = <33>;
> +					vfront-porch = <9>;
> +					vsync-len = <3>;
> +					vsync-active = <1>;
> +				};
> +			};
> +		};
> +
> +		display at di1 {
> +			compatible = "fsl,imx-parallel-display";
> +			crtcs = <&ipu 1>;
> +			interface-pix-fmt = "rgb24";
> +			pinctrl-names = "default";
> +			pinctrl-0 = <&pinctrl_ipu_disp2_1>;
> +
> +			display-timings {
> +				800x480p60 {
> +					native-mode;
> +					clock-frequency = <31500000>;
> +					hactive = <800>;
> +					vactive = <480>;
> +					hfront-porch = <40>;
> +					hback-porch = <88>;
> +					hsync-len = <128>;
> +					vback-porch = <33>;
> +					vfront-porch = <9>;
> +					vsync-len = <3>;
> +					vsync-active = <1>;
> +				};
> +			};
> +		};
> +	};
> +
> +	leds {
> +		compatible = "gpio-leds";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&led_pin_gpio>;
> +
> +		user1 {
> +			label = "user1";
> +			gpios = <&gpio2 8 0>;
> +			linux,default-trigger = "heartbeat";
> +		};
> +
> +		user2 {
> +			label = "user2";
> +			gpios = <&gpio2 9 0>;
> +			linux,default-trigger = "heartbeat";
> +		};
> +	};
> +
> +	regulators {
> +		compatible = "simple-bus";
> +
> +		reg_3p2v: 3p2v {
> +			compatible = "regulator-fixed";
> +			regulator-name = "3P2V";
> +			regulator-min-microvolt = <3200000>;
> +			regulator-max-microvolt = <3200000>;
> +			regulator-always-on;
> +		};
> +	};
> +
> +	sound {
> +		compatible = "fsl,imx53-m53evk-sgtl5000",
> +			     "fsl,imx-audio-sgtl5000";
> +		model = "imx53-m53evk-sgtl5000";
> +		ssi-controller = <&ssi2>;
> +		audio-codec = <&sgtl5000>;
> +		audio-routing =
> +			"MIC_IN", "Mic Jack",
> +			"Mic Jack", "Mic Bias",
> +			"LINE_IN", "Line In Jack",
> +			"Headphone Jack", "HP_OUT",
> +			"Ext Spk", "LINE_OUT";
> +		mux-int-port = <2>;
> +		mux-ext-port = <4>;
> +	};
> +
> +	backlight {
> +		compatible = "pwm-backlight";
> +		pwms = <&pwm1 0 3000>;
> +		brightness-levels = <0 4 8 16 32 64 128 255>;
> +		default-brightness-level = <6>;
> +	};

I'm going to be picky on new board dts file on the node sorting.  Please
put "backlight" before "leds".

> +};
> +
> +&esdhc1 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_esdhc1_1>;
> +	cd-gpios = <&gpio1 1 0>;
> +	wp-gpios = <&gpio1 9 0>;
> +	status = "okay";
> +};
> +
Please sort all these nodes per label names.

> +&ssi2 {
> +	fsl,mode = "i2s-slave";
> +	status = "okay";
> +};
> +
> +&uart3 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_uart3_1>;
> +	status = "okay";
> +};
> +
> +&pwm1 {
> +/*	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_pwm1_1>;*/

Please remove it, either the commenting or the lines.

> +	status = "okay";
> +};
> +
> +&uart1 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_uart1_2>;
> +	status = "okay";
> +};
> +
> +&uart2 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_uart2_1>;
> +	status = "okay";
> +};
> +
> +&iomuxc {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_hog>;
> +
> +	hog {
> +		pinctrl_hog: hoggrp {
> +			fsl,pins = <
> +				MX53_PAD_GPIO_0__CCM_SSI_EXT1_CLK	0x80000000
> +				MX53_PAD_EIM_EB3__GPIO2_31		0x80000000
> +				MX53_PAD_PATA_DA_0__GPIO7_6		0x80000000
> +				MX53_PAD_DISP0_DAT8__PWM1_PWMO		0x5
> +
> +			>;
> +		};
> +
> +		led_pin_gpio: led_gpio at 0 {
> +			fsl,pins = <
> +				MX53_PAD_PATA_DATA8__GPIO2_8		0x80000000
> +				MX53_PAD_PATA_DATA9__GPIO2_9		0x80000000
> +			>;
> +		};
> +	};
> +};
> +
> +&can1 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_can1_3>;
> +	status = "okay";
> +};
> +
> +&can2 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_can2_1>;
> +	status = "okay";
> +};
> +
> +&i2c1 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_i2c1_2>;
> +	status = "okay";
> +
> +	sgtl5000: codec at 0a {
> +		compatible = "fsl,sgtl5000";
> +		reg = <0x0a>;
> +		VDDA-supply = <&reg_3p2v>;
> +		VDDIO-supply = <&reg_3p2v>;
> +	};
> +};
> +
> +&i2c2 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_i2c2_2>;
> +	clock-frequency = <400000>;
> +	status = "okay";
> +
> +	stmpe610 at 41 {
> +		compatible = "st,stmpe610";
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +		reg = <0x41>;
> +		irq-over-gpio;
> +		irq-gpios = <&gpio7 6 0>;
> +		id = <0>;
> +		blocks = <0x5>;
> +		irq-trigger = <0x1>;
> +
> +		stmpe_touchscreen {
> +			compatible = "stmpe,ts";
> +			reg = <0>;
> +			ts,sample-time = <4>;
> +			ts,mod-12b = <1>;
> +			ts,ref-sel = <0>;
> +			ts,adc-freq = <1>;
> +			ts,ave-ctrl = <3>;
> +			ts,touch-det-delay = <3>;
> +			ts,settling = <4>;
> +			ts,fraction-z = <7>;
> +			ts,i-drive = <1>;
> +		};
> +	};
> +
> +	eeprom: eeprom at 50 {
> +		compatible = "atmel,24c128";
> +		reg = <0x50>;
> +		pagesize = <32>;
> +	};
> +
> +	rtc: rtc at 68 {
> +		compatible = "stm,m41t62";
> +		reg = <0x68>;
> +	};
> +};
> +
> +&i2c3 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_i2c3_1>;
> +	status = "okay";
> +};
> +
> +&audmux {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_audmux_2>;
> +	status = "okay";
> +};
> +
> +&nfc {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_nand_1>;
> +	nand-bus-width = <8>;
> +	nand-ecc-mode = "hw";
> +	status = "okay";
> +};
> +
> +&fec {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_fec_1>;
> +	phy-mode = "rmii";
> +	status = "okay";
> +};
> diff --git a/arch/arm/mach-imx/mach-imx53.c b/arch/arm/mach-imx/mach-imx53.c
> index f579c61..4effe59 100644
> --- a/arch/arm/mach-imx/mach-imx53.c
> +++ b/arch/arm/mach-imx/mach-imx53.c
> @@ -23,7 +23,7 @@
>  #include "common.h"
>  #include "mx53.h"
>  
> -static void __init imx53_qsb_init(void)
> +static void __init imx53_ssi_clk_init(const char *device)
>  {
>  	struct clk *clk;
>  
> @@ -33,11 +33,23 @@ static void __init imx53_qsb_init(void)
>  		return;
>  	}
>  
> -	clk_register_clkdev(clk, NULL, "0-000a");
> +	clk_register_clkdev(clk, NULL, device);

I just sent a patch (you are on CC) to move the lookup into DT.  With
it, you do not need to touch mach-imx53.c but just add the clk in your
board dts instead.

Shawn

> +}
> +
> +static void __init imx53_qsb_init(void)
> +{
> +	imx53_ssi_clk_init("0-000a");
> +}
> +
> +static void __init imx53_m53evk_init(void)
> +{
> +	imx53_ssi_clk_init("2-000a");
>  }
>  
>  static void __init imx53_dt_init(void)
>  {
> +	if (of_machine_is_compatible("denx,imx53-m53evk"))
> +		imx53_m53evk_init();
>  	if (of_machine_is_compatible("fsl,imx53-qsb"))
>  		imx53_qsb_init();
>  
> -- 
> 1.7.10.4
> 



From preeti at linux.vnet.ibm.com  Mon Apr 22 01:45:58 2013
From: preeti at linux.vnet.ibm.com (Preeti U Murthy)
Date: Mon, 22 Apr 2013 11:15:58 +0530
Subject: [RFC PATCH v3 5/6] sched: pack the idle load balance
In-Reply-To: <CAKfTPtArtgkH5MU_xFAKjLDS-i32g2qQMdvyW=LLkG84tH8Hhg@mail.gmail.com>
References: <1363955155-18382-1-git-send-email-vincent.guittot@linaro.org>
 <1363955155-18382-6-git-send-email-vincent.guittot@linaro.org>
 <1364302359.5053.21.camel@laptop>
 <CAKfTPtD=_oS5gJeynUG=ft-Y1zEdxZEMhUPH9hSXx+H2pi4xgA@mail.gmail.com>
 <1364308932.5053.46.camel@laptop>
 <CAKfTPtArtgkH5MU_xFAKjLDS-i32g2qQMdvyW=LLkG84tH8Hhg@mail.gmail.com>
Message-ID: <5174CE96.3060805@linux.vnet.ibm.com>

Hi Vincent,

On 04/05/2013 04:38 PM, Vincent Guittot wrote:
> Peter,
> 
> After some toughts about your comments,I can update the buddy cpu
> during ILB or periofdic LB to a new idle core and extend the packing
> mechanism  Does this additional mechanism sound better for you ?

If the primary goal of this patchset is to pack small tasks in fewer
power domains then why not see if the power aware scheduler patchset by
Alex does the same for you? The reason being:

a.The power aware scheduler also checks if a task is small enough to be
packed on a cpu which has just enough capacity to take on that
task(leader cpu). This cpu belongs to a scheduler group which is nearly
full(group_leader),so we end up packing tasks.

b.The overhead of assigning a buddy cpu gets eliminated because the best
cpu for packing is decided during wake up.

c.This is a scalable solution because if the leader cpu is busy,then any
other idle cpu from that group_leader is chosen.Eventually you end up
packing anyway.

The reason that I am suggesting this is that we could unify the power
awareness of the scheduler under one umbrella.And i believe that the
current power aware scheduler patchset is flexible enough to do this and
that we must cash in on it.

Thanks

Regards
Preeti U Murthy
> 
> Vincent
> 
> On 26 March 2013 15:42, Peter Zijlstra <peterz at infradead.org> wrote:
>> On Tue, 2013-03-26 at 15:03 +0100, Vincent Guittot wrote:
>>>> But ha! here's your NO_HZ link.. but does the above DTRT and ensure
>>>> that the ILB is a little core when possible?
>>>
>>> The loop looks for an idle CPU as close as possible to the buddy CPU
>>> and the buddy CPU is the 1st CPU has been chosen. So if your buddy is
>>> a little and there is an idle little, the ILB will be this idle
>>> little.
>>
>> Earlier you wrote:
>>
>>>       | Cluster 0   | Cluster 1   |
>>>       | CPU0 | CPU1 | CPU2 | CPU3 |
>>> -----------------------------------
>>> buddy | CPU0 | CPU0 | CPU0 | CPU2 |
>>
>> So extrapolating that to a 4+4 big-little you'd get something like:
>>
>>       |   little  A9  ||   big A15     |
>>       | 0 | 1 | 2 | 3 || 4 | 5 | 6 | 7 |
>> ------+---+---+---+---++---+---+---+---+
>> buddy | 0 | 0 | 0 | 0 || 0 | 4 | 4 | 4 |
>>
>> Right?
>>
>> So supposing the current ILB is 6, we'll only check 4, not 0-3, even
>> though there might be a perfectly idle cpu in there.
>>
>> Also, your scheme fails to pack when cpus 0,4 are filled, even when
>> there's idle cores around.
>>
>> If we'd use the ILB as packing cpu, we would simply select a next pack
>> target once the old one fills up.
>>
> 



From dirk.behme at de.bosch.com  Mon Apr 22 02:00:34 2013
From: dirk.behme at de.bosch.com (Dirk Behme)
Date: Mon, 22 Apr 2013 08:00:34 +0200
Subject: [PATCH] ARM i.MX6: correct MLB clock configuration
Message-ID: <1366610434-23042-1-git-send-email-dirk.behme@de.bosch.com>

From: Dirk Behme <dirk.behme at gmail.com>

According to the i.MX6 Dual/Quad technical reference manual
(Figure 18-2. Clock Tree - Part 1) the MLB clock is directly
feed by the AXI_CLK_ROOT. This is called 'axi' in our code.

Note that the clock of the MLB IP block on the i.MX6 is completely
independent of the PLL8 (MLB PLL). The MLB PLL isn't responsible
for feeding the MLB IP block with a clock. Instead, it's used
internally by the MLB module to sync the bus clock in case the MLB
6-pin interface is enabled:

MediaLB Control 0 Register, MLB150_MLBC0[5], MLBPEN:
1 MediaLB 6-pin interface enabled. MLB PLL and MLB PHY is enabled in this case.

I.e. the PLL8 MLB PLL has to be handled by the MLB driver and isn't needed
for clocking the MLB module itself.

Signed-off-by: Dirk Behme <dirk.behme at de.bosch.com>
CC: Shawn Guo <shawn.guo at linaro.org>
CC: Jiada Wang <Jiada_Wang at mentor.com>
---
 arch/arm/mach-imx/clk-imx6q.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-imx/clk-imx6q.c b/arch/arm/mach-imx/clk-imx6q.c
index d38e54f..fd0189d 100644
--- a/arch/arm/mach-imx/clk-imx6q.c
+++ b/arch/arm/mach-imx/clk-imx6q.c
@@ -399,7 +399,7 @@ int __init mx6q_clocks_init(void)
 	clk[ldb_di1]      = imx_clk_gate2("ldb_di1",       "ldb_di1_podf",      base + 0x74, 14);
 	clk[ipu2_di1]     = imx_clk_gate2("ipu2_di1",      "ipu2_di1_sel",      base + 0x74, 10);
 	clk[hsi_tx]       = imx_clk_gate2("hsi_tx",        "hsi_tx_podf",       base + 0x74, 16);
-	clk[mlb]          = imx_clk_gate2("mlb",           "pll8_mlb",          base + 0x74, 18);
+	clk[mlb]          = imx_clk_gate2("mlb",           "axi",               base + 0x74, 18);
 	clk[mmdc_ch0_axi] = imx_clk_gate2("mmdc_ch0_axi",  "mmdc_ch0_axi_podf", base + 0x74, 20);
 	clk[mmdc_ch1_axi] = imx_clk_gate2("mmdc_ch1_axi",  "mmdc_ch1_axi_podf", base + 0x74, 22);
 	clk[ocram]        = imx_clk_gate2("ocram",         "ahb",               base + 0x74, 28);
-- 
1.8.2



From kishon at ti.com  Mon Apr 22 02:09:57 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Mon, 22 Apr 2013 11:39:57 +0530
Subject: [PATCH v3 1/6] drivers: phy: add generic PHY framework
In-Reply-To: <20130419090933.AB4253E116D@localhost>
References: <1363770725-13717-1-git-send-email-kishon@ti.com>
 <1363770725-13717-2-git-send-email-kishon@ti.com>
 <20130415113416.7C3943E0AA8@localhost> <516BF1E2.3020104@ti.com>
 <20130415195030.9F7E93E0AA8@localhost> <516D255F.40604@ti.com>
 <20130419090933.AB4253E116D@localhost>
Message-ID: <5174D435.7080408@ti.com>

Hi,

On Friday 19 April 2013 02:39 PM, Grant Likely wrote:
> On Tue, 16 Apr 2013 15:48:07 +0530, Kishon Vijay Abraham I <kishon at ti.com> wrote:
>> On Tuesday 16 April 2013 01:20 AM, Grant Likely wrote:
>>> On Mon, 15 Apr 2013 17:56:10 +0530, Kishon Vijay Abraham I <kishon at ti.com> wrote:
>>>> On Monday 15 April 2013 05:04 PM, Grant Likely wrote:
>>>>> On Wed, 20 Mar 2013 14:42:00 +0530, Kishon Vijay Abraham I <kishon at ti.com> wrote:
>>>> We have decided not to implement the PHY layer as a separate bus layer.
>>>> The PHY provider can be part of any other bus. Making the PHY layer as a
>>>> bus will make the PHY provider to be part of multiple buses which will
>>>> lead to bad design. All we are trying to do here is keep the pool of PHY
>>>> devices under PHY class in this layer and help any controller that wants
>>>> to use the PHY to get it.
>>>
>>> If you're using a class, then you already have your list of registered
>>> phy devices! :-) No need to create another global list that you need to
>>> manage.
>>
>> right. We already use _class_dev_iter_ for finding the phy device.
>> .
>> .
>> +static struct phy *of_phy_lookup(struct device *dev, struct device_node
>> *node)
>> +{
>> +	struct phy *phy;
>> +	struct class_dev_iter iter;
>> +
>> +	class_dev_iter_init(&iter, phy_class, NULL, NULL);
>> +	while ((dev = class_dev_iter_next(&iter))) {
>> +		phy = container_of(dev, struct phy, dev);
>> +		if (node != phy->of_node)
>> +			continue;
>> +
>> +		class_dev_iter_exit(&iter);
>> +		return phy;
>> +	}
>> +
>> +	class_dev_iter_exit(&iter);
>> +	return ERR_PTR(-EPROBE_DEFER);
>> +}
>> .
>> .
>>
>> however we can't get rid of the other list (phy_bind_list) where we
>> maintain the phy binding information. It's used for the non-dt boot case.
>
> Why? If you're using a class, then it is always there. Why would non-DT
> and DT be different in this regard? (more below)
>
>>>>> Since there is at most a 1:N relationship between host controllers and
>>>>> PHYs, there shouldn't be any need for a separate structure to describe
>>>>> binding. Put the inding data into the struct phy itself. Each host
>>>>> controller can have a list of phys that it is bound to.
>>>>
>>>> No. Having the host controller to have a list of phys wont be a good
>>>> idea IMHO. The host controller is just an IP and the PHY to which it
>>>> will be connected can vary from board to board, platform to platform. So
>>>> ideally this binding should come from platform initialization code/dt data.
>>>
>>> That is not what I mean. I mean the host controller instance should
>>> contain a list of all the PHYs that are attached to it. There should not
>>
>> Doesn't sound correct IMO. The host controller instance need not know
>> anything about the PHY instances that is connected to it. Think of it
>> similar to regulator, the controller wouldn't know which regulator it is
>> connected to, all it has to know is it just has a regulator connected to
>> it. It's up-to the regulator framework to give the controller the
>> correct regulator. It's similar here. It makes sense for me to keep a
>> list in the PHY framework in order for it to return the correct PHY (but
>> note that this list is not needed for dt boot).
>
> With regulators and clocks it makes sense to have a global
> registration place becase both implement an interconnected network
> independent of the device that use them. (clocks depend on other clocks;
> regulators depend on other regulators).
>
> Phys are different. There is a 1:N relationship between host controllers
> and phys, and you don't get a interconnected network of PHYs. Its a bad
> idea to keep the binding data separate from the actual host controller
> when there is nothing else that actually needs to use the data. It
> creates a new set of data structures that need housekeeping to keep them
> in sync with the actual device structures. It really is just a bad idea
> and it becomes more difficult (in the non-DT case) to determine what
> data is associated with a given host controller. You can't tell by
> looking at the struct device.
>
> Instead, for the non-DT case, do what we've always done for describing
> connections. Put the phy reference into the host controllers
> platform_data structure.
hmm... my only concern here is there is no way we can enforce the phy 
reference is added in the platform_data structure.
That is what it is there for. That completely
> eliminates the need to housekeep a new set of data structures.

Ok. Makes sense.

Thanks
Kishon


From lars at metafoo.de  Mon Apr 22 02:11:10 2013
From: lars at metafoo.de (Lars-Peter Clausen)
Date: Mon, 22 Apr 2013 08:11:10 +0200
Subject: [RFC/PATCH 1/4] arm64: Provide default implementation for
 dma_{alloc, free}_attrs
In-Reply-To: <1366607349-2992-1-git-send-email-dhobsong@igel.co.jp>
References: <1366607349-2992-1-git-send-email-dhobsong@igel.co.jp>
Message-ID: <5174D47E.3090301@metafoo.de>

On 04/22/2013 07:09 AM, Damian Hobson-Garcia wrote:
> Most architectures that define CONFIG_HAVE_DMA, have implementations for
> both dma_alloc_attrs() and dma_free_attrs().  All achitectures that do
> not define CONFIG_HAVE_DMA also have both of these definitions provided by
> dma-mapping-broken.h.
> 
> Add default implementations for these functions on arm64.
> 
> Signed-off-by: Damian Hobson-Garcia <dhobsong at igel.co.jp>
> ---
>  arch/arm64/include/asm/dma-mapping.h |    3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/dma-mapping.h b/arch/arm64/include/asm/dma-mapping.h
> index 9947768..65ab181 100644
> --- a/arch/arm64/include/asm/dma-mapping.h
> +++ b/arch/arm64/include/asm/dma-mapping.h
> @@ -81,6 +81,9 @@ static inline void dma_mark_clean(void *addr, size_t size)
>  {
>  }
>  
> +#define dma_alloc_attrs(d, s, h, f, a) dma_alloc_coherent(d, s, h, f)
> +#define dma_free_attrs(d, s, h, f, a) dma_free_coherent(d, s, h, f)
> +
>  static inline void *dma_alloc_coherent(struct device *dev, size_t size,
>  				       dma_addr_t *dma_handle, gfp_t flags)
>  {

The other way around would be better, properly implement
dma_{alloc,free}_attrs and implement dma_{alloc,free}_coherent on top of
the. E.g. you are supposed to pass the attrs parameter to ops->alloc and
ops->free instead of NULL. And it will also allow us to move
dma_{alloc,free}_coherent to asm-generic/dma-mapping-common.h eventually.

- Lars


From gang.chen at asianux.com  Mon Apr 22 02:13:14 2013
From: gang.chen at asianux.com (Chen Gang)
Date: Mon, 22 Apr 2013 14:13:14 +0800
Subject: [Suggestion] ARM:S5pv210: compiling issue for s5pv210 by using
 randconfig
In-Reply-To: <20130417100243.GV14496@n2100.arm.linux.org.uk>
References: <514FB202.3040807@asianux.com> <515BFA8D.2000204@asianux.com>
 <20130403101018.GE11040@mudshark.cambridge.arm.com>
 <515C047A.9010906@asianux.com> <516E6A8E.3000001@asianux.com>
 <20130417100243.GV14496@n2100.arm.linux.org.uk>
Message-ID: <5174D4FA.70404@asianux.com>

On 2013?04?17? 18:02, Russell King - ARM Linux wrote:
> On Wed, Apr 17, 2013 at 05:25:34PM +0800, Chen Gang wrote:
>> CONFIG_CPU_ARM7TDMI=y
>> CONFIG_CPU_ARM9TDMI=y
>> CONFIG_CPU_V7=y
>> CONFIG_CPU_32v4T=y
>> CONFIG_CPU_32v6K=y
>> CONFIG_CPU_32v7=y
> 
> This is an invalid configuration.  A single kernel can not support ARMv7
> and ARMv4T simultaneously.
> 
> The problem is caused by MMU=n, which exposes the CPU_ARM7TDMI and
> CPU_ARM9TDMI options, which in turn select 32v4T.  This is in turn
> caused by the incomplete integration of uclinux.
> 
> I think the only thing which can be done is to remove the ARM9TDMI
> support code, which doesn't seem to be used by anything, and adjust
> ARM7TDMI so that it isn't visible, but is selected by ARCH_AT91X40
> (which seems to be its only user.)
> 
> Here's the slightly smaller version of that:
> 

  I apply your patch below.
  and also let CONFIG_MMU=y in menuconfig (just Arnd suggested).
  it passes compilation.

  I prefer to let the patch below to integrate into next-tree.
  if I should do it (e.g. need send the patch again in normal way), I
should try.

  thanks.


gchen.


> diff --git a/arch/arm/mach-at91/Kconfig.non_dt b/arch/arm/mach-at91/Kconfig.non_dt
> index 6c24985..dc972e1 100644
> --- a/arch/arm/mach-at91/Kconfig.non_dt
> +++ b/arch/arm/mach-at91/Kconfig.non_dt
> @@ -47,6 +47,7 @@ config ARCH_AT91X40
>  	select ARCH_USES_GETTIMEOFFSET
>  	select MULTI_IRQ_HANDLER
>  	select SPARSE_IRQ
> +	select CPU_ARM7TDMI
>  
>  endchoice
>  
> diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
> index cb812a1..deb6c6a 100644
> --- a/arch/arm/mm/Kconfig
> +++ b/arch/arm/mm/Kconfig
> @@ -6,7 +6,7 @@ comment "Processor Type"
>  
>  # ARM7TDMI
>  config CPU_ARM7TDMI
> -	bool "Support ARM7TDMI processor"
> +	bool
>  	depends on !MMU
>  	select CPU_32v4T
>  	select CPU_ABRT_LV4T
> @@ -56,7 +56,7 @@ config CPU_ARM740T
>  
>  # ARM9TDMI
>  config CPU_ARM9TDMI
> -	bool "Support ARM9TDMI processor"
> +	bool
>  	depends on !MMU
>  	select CPU_32v4T
>  	select CPU_ABRT_NOMMU
> 
> 
> 


-- 
Chen Gang

Asianux Corporation


From w at 1wt.eu  Mon Apr 22 02:20:24 2013
From: w at 1wt.eu (Willy Tarreau)
Date: Mon, 22 Apr 2013 08:20:24 +0200
Subject: MVEBU and MVNETA driver
In-Reply-To: <51716A8B.9080903@itooo.com>
References: <5171419C.2090003@itooo.com> <20130419131237.GC22440@1wt.eu>
 <517150FF.9010806@itooo.com> <20130419144324.GD22440@1wt.eu>
 <51715BC7.3040906@free-electrons.com> <51716A8B.9080903@itooo.com>
Message-ID: <20130422062024.GK30850@1wt.eu>

On Fri, Apr 19, 2013 at 06:02:19PM +0200, Greg wrote:
> A simple tool like netcat shows ~470Mbps but this limited by the CPU.
> Iperf isn't CPU limited
> 
> The same test with Marvell LSP shows ~940Mbps in both directions.

I've retested here on my mirabox using httpterm as the tcp server.
Using the normal send() syscall, it emits 839 Mbps on a single TCP
connection. Using splice(), it emits 969 Mbps in the same conditions.

Here's what ethtool is saying about the NIC's tuning :
# ethtool -k eth0
Offload parameters for eth0:
rx-checksumming: off
tx-checksumming: on
scatter-gather: on
tcp-segmentation-offload: off
udp-fragmentation-offload: off
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off
rx-vlan-offload: off
tx-vlan-offload: off
ntuple-filters: off
receive-hashing: off

I've tried changing other settings such as the interrupt delays
(rx-usecs, rx-frames, tx-frames) but this has no effect. So in
short, I cannot reproduce this behaviour. Are you using the SLOB
allocator ? I'm asking because I remember experiencing very poor
performance with it in the past.

Regards,
Willy



From s.hauer at pengutronix.de  Mon Apr 22 02:30:13 2013
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Mon, 22 Apr 2013 08:30:13 +0200
Subject: [PATCH] video: imx: Add BGR666 support for parallel display
In-Reply-To: <1366585450-12762-1-git-send-email-marex@denx.de>
References: <1366585450-12762-1-git-send-email-marex@denx.de>
Message-ID: <20130422063013.GF10373@pengutronix.de>

Hi Marek,

On Mon, Apr 22, 2013 at 01:04:10AM +0200, Marek Vasut wrote:
> Support the BGR666 format on the IPUv3 parallel display.
> 
> Signed-off-by: Marek Vasut <marex at denx.de>
> Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
> Cc: Philipp Zabel <p.zabel at pengutronix.de>
> Cc: Sascha Hauer <s.hauer at pengutronix.de>
> Cc: Bill Pemberton <wfp5p at virginia.edu>
> ---
>  drivers/staging/imx-drm/ipu-v3/ipu-dc.c    |    9 +++++++++
>  drivers/staging/imx-drm/parallel-display.c |    2 ++

Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt is
missing in the diffstat

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From daniel.lezcano at linaro.org  Mon Apr 22 02:32:13 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Mon, 22 Apr 2013 08:32:13 +0200
Subject: [V3 patch 10/19] ARM: s3c64xx: cpuidle: use init/exit common
 routine
In-Reply-To: <1365770165-27096-11-git-send-email-daniel.lezcano@linaro.org>
References: <1365770165-27096-1-git-send-email-daniel.lezcano@linaro.org>
 <1365770165-27096-11-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <5174D96D.40602@linaro.org>

On 04/12/2013 02:35 PM, Daniel Lezcano wrote:
> Remove the duplicated code and use the cpuidle common code for initialization.
>
> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
> ---

Kim, Ben,

is it possible you ack this patch if you are ok with it ?

So it can go into the linux-pm tree before the merge windows [1]

Thanks !

-- Daniel

[1] http://www.spinics.net/lists/linux-acpi/msg43138.html

>  arch/arm/mach-s3c64xx/cpuidle.c |   14 +-------------
>  1 file changed, 1 insertion(+), 13 deletions(-)
>
> diff --git a/arch/arm/mach-s3c64xx/cpuidle.c b/arch/arm/mach-s3c64xx/cpuidle.c
> index 852ff16..3c8ab07 100644
> --- a/arch/arm/mach-s3c64xx/cpuidle.c
> +++ b/arch/arm/mach-s3c64xx/cpuidle.c
> @@ -40,8 +40,6 @@ static int s3c64xx_enter_idle(struct cpuidle_device *dev,
>  	return index;
>  }
>  
> -static DEFINE_PER_CPU(struct cpuidle_device, s3c64xx_cpuidle_device);
> -
>  static struct cpuidle_driver s3c64xx_cpuidle_driver = {
>  	.name	= "s3c64xx_cpuidle",
>  	.owner  = THIS_MODULE,
> @@ -60,16 +58,6 @@ static struct cpuidle_driver s3c64xx_cpuidle_driver = {
>  
>  static int __init s3c64xx_init_cpuidle(void)
>  {
> -	int ret;
> -
> -	cpuidle_register_driver(&s3c64xx_cpuidle_driver);
> -
> -	ret = cpuidle_register_device(&s3c64xx_cpuidle_device);
> -	if (ret) {
> -		pr_err("Failed to register cpuidle device: %d\n", ret);
> -		return ret;
> -	}
> -
> -	return 0;
> +	return cpuidle_register(&s3c64xx_cpuidle_driver, NULL);
>  }
>  device_initcall(s3c64xx_init_cpuidle);


-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From s.hauer at pengutronix.de  Mon Apr 22 02:41:23 2013
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Mon, 22 Apr 2013 08:41:23 +0200
Subject: [PATCH 8/8] ARM: mx5: Add support for DENX M53EVK
In-Reply-To: <1366579808-12067-8-git-send-email-marex@denx.de>
References: <1366579808-12067-1-git-send-email-marex@denx.de>
 <1366579808-12067-8-git-send-email-marex@denx.de>
Message-ID: <20130422064123.GG10373@pengutronix.de>

On Sun, Apr 21, 2013 at 11:30:08PM +0200, Marek Vasut wrote:
> This patch adds support for the DENX M53EVK board. The board currently supports
> NAND, Ethernet, UART, CAN, I2C.
> 
> Signed-off-by: Marek Vasut <marex at denx.de>
> Cc: Fabio Estevam <fabio.estevam at freescale.com>
> Cc: Shawn Guo <shawn.guo at linaro.org>
> ---
> +/ {
> +	model = "DENX M53EVK";
> +	compatible = "denx,imx53-m53evk", "fsl,imx53";
> +
> +	memory {
> +		reg = <0x70000000 0x20000000>;
> +	};
> +
> +	soc {
> +		display at di0 {
> +			compatible = "fsl,imx-parallel-display";
> +			crtcs = <&ipu 0>;
> +			interface-pix-fmt = "rgb24";
> +			pinctrl-names = "default";
> +			pinctrl-0 = <&pinctrl_ipu_disp1_1>;
> +
> +			display-timings {
> +				800x480p60 {
> +					native-mode;
> +					clock-frequency = <31500000>;
> +					hactive = <800>;
> +					vactive = <480>;
> +					hfront-porch = <40>;
> +					hback-porch = <88>;
> +					hsync-len = <128>;
> +					vback-porch = <33>;
> +					vfront-porch = <9>;
> +					vsync-len = <3>;
> +					vsync-active = <1>;
> +				};
> +			};
> +		};
> +
> +		display at di1 {
> +			compatible = "fsl,imx-parallel-display";
> +			crtcs = <&ipu 1>;
> +			interface-pix-fmt = "rgb24";
> +			pinctrl-names = "default";
> +			pinctrl-0 = <&pinctrl_ipu_disp2_1>;
> +
> +			display-timings {
> +				800x480p60 {
> +					native-mode;
> +					clock-frequency = <31500000>;
> +					hactive = <800>;
> +					vactive = <480>;
> +					hfront-porch = <40>;
> +					hback-porch = <88>;
> +					hsync-len = <128>;
> +					vback-porch = <33>;
> +					vfront-porch = <9>;
> +					vsync-len = <3>;
> +					vsync-active = <1>;
> +				};
> +			};
> +		};

This board has two identical displays?

> +	};
> +
> +	leds {
> +		compatible = "gpio-leds";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&led_pin_gpio>;
> +
> +		user1 {
> +			label = "user1";
> +			gpios = <&gpio2 8 0>;
> +			linux,default-trigger = "heartbeat";
> +		};
> +
> +		user2 {
> +			label = "user2";
> +			gpios = <&gpio2 9 0>;
> +			linux,default-trigger = "heartbeat";
> +		};
> +	};

Two heartbeat LEDs? Why not use one for something else?

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From daniel.lezcano at linaro.org  Mon Apr 22 02:57:17 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Mon, 22 Apr 2013 08:57:17 +0200
Subject: [PATCH 05/18] cpuidle: make a single register function for all
In-Reply-To: <51657E61.9010701@gmail.com>
References: <1365603743-5618-1-git-send-email-daniel.lezcano@linaro.org>
 <1365603743-5618-6-git-send-email-daniel.lezcano@linaro.org>
 <51657E61.9010701@gmail.com>
Message-ID: <5174DF4D.5020701@linaro.org>

On 04/10/2013 04:59 PM, Rob Herring wrote:
> On 04/10/2013 09:22 AM, Daniel Lezcano wrote:
>> The usual scheme to initialize a cpuidle driver on a SMP is:
>>
>> 	cpuidle_register_driver(drv);
>> 	for_each_possible_cpu(cpu) {
>> 		device = &per_cpu(cpuidle_dev, cpu);
>> 		cpuidle_register_device(device);
>> 	}
>>
>> This code is duplicated in each cpuidle driver.
>>
>> On UP systems, it is done this way:
>>
>> 	cpuidle_register_driver(drv);
>> 	device = &per_cpu(cpuidle_dev, cpu);
>> 	cpuidle_register_device(device);
>>
>> On UP, the macro 'for_each_cpu' does one iteration:
>>
>> #define for_each_cpu(cpu, mask)                 \
>>         for ((cpu) = 0; (cpu) < 1; (cpu)++, (void)mask)
>>
>> Hence, the initialization loop is the same for UP than SMP.
>>
>> Beside, we saw different bugs / mis-initialization / return code unchecked in
>> the different drivers, the code is duplicated including bugs. After fixing all
>> these ones, it appears the initialization pattern is the same for everyone.
>>
>> Let's add a wrapper function doing this initialization with a cpumask parameter
>> for the coupled idle states and use it for all the drivers.
>>
>> That will save a lot of LOC, consolidate the code, and the modifications in the
>> future could be done in a single place. Another benefit is the consolidation of
>> the cpuidle_device variable which is now in the cpuidle framework and no longer
>> spread accross the different arch specific drivers.
>>
>> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
>> ---
> Perhaps my ack was too quick...

Hi Rob,

now that I have fixed the routine in V3, shall I consider the patch is
acked ?

Thanks
-- Daniel

-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From daniel.lezcano at linaro.org  Mon Apr 22 03:01:10 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Mon, 22 Apr 2013 09:01:10 +0200
Subject: [V3 patch 17/19] ARM: kirkwood: cpuidle: use init/exit common
 routine
In-Reply-To: <20130414151429.GF5061@lunn.ch>
References: <1365770165-27096-1-git-send-email-daniel.lezcano@linaro.org>
 <1365770165-27096-18-git-send-email-daniel.lezcano@linaro.org>
 <20130414151429.GF5061@lunn.ch>
Message-ID: <5174E036.9090808@linaro.org>

On 04/14/2013 05:14 PM, Andrew Lunn wrote:

[ ... ]
>  int kirkwood_cpuidle_remove(struct platform_device *pdev)
>  {
> -	cpuidle_unregister_device(device);
> -	cpuidle_unregister_driver(&kirkwood_idle_driver);
> -
> +	cpuidle_unregister(&kirkwood_idle_driver);
>  	return 0;
>  }
>  
> -- 
> 1.7.9.5
>
> Tested-by: Andrew Lunn <andrew at lunn.ch>

Hi Andrew,

shall I consider it as acked-by also ?

Thanks
  -- Daniel


From girishks2000 at gmail.com  Mon Apr 22 03:09:22 2013
From: girishks2000 at gmail.com (Girish K S)
Date: Mon, 22 Apr 2013 12:39:22 +0530
Subject: [PATCH 0/3] Polling support for s3c64xx spi controller
Message-ID: <1366614565-3743-1-git-send-email-ks.giri@samsung.com>

This patch series adds support for the polling mode only. Also 2nd patch
in the series adds support for dedicated cs pin. After Thomas's patch for
using default gpio is merged(commit id: 00ab539), one of the patch in this
series is dropped and new series is generated.

Girish K S (3):
  spi: s3c64xx: added support for polling mode
  spi: s3c64xx: Added provision for dedicated cs pin
  spi: s3c64xx: Added support for exynos5440 spi

 drivers/spi/spi-s3c64xx.c |  192 +++++++++++++++++++++++++++++++-------------
 1 files changed, 135 insertions(+), 57 deletions(-)

-- 
1.7.5.4



From girishks2000 at gmail.com  Mon Apr 22 03:09:23 2013
From: girishks2000 at gmail.com (Girish K S)
Date: Mon, 22 Apr 2013 12:39:23 +0530
Subject: [PATCH 1/3] spi: s3c64xx: added support for polling mode
In-Reply-To: <1366614565-3743-1-git-send-email-ks.giri@samsung.com>
References: <1366614565-3743-1-git-send-email-ks.giri@samsung.com>
Message-ID: <1366614565-3743-2-git-send-email-ks.giri@samsung.com>

From: Girish K S <girishks2000 at gmail.com>

The 64xx spi driver supports partial polling mode.
Only the last chunk of the transfer length is transferred
or recieved in polling mode.

Some SoC's that adopt this controller might not have have dma
interface. This patch adds support for complete polling mode
and gives flexibity for the user to select poll/dma mode.

Signed-off-by: Girish K S <ks.giri at samsung.com>
---
 drivers/spi/spi-s3c64xx.c |  150 ++++++++++++++++++++++++++++++---------------
 1 files changed, 101 insertions(+), 49 deletions(-)

diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index 5000586..665fe2b 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -39,6 +39,7 @@
 #endif
 
 #define MAX_SPI_PORTS		3
+#define S3C64XX_SPI_QUIRK_POLL		(1 << 0)
 
 /* Registers and bit-fields */
 
@@ -130,6 +131,7 @@
 #define S3C64XX_SPI_TRAILCNT		S3C64XX_SPI_MAX_TRAILCNT
 
 #define msecs_to_loops(t) (loops_per_jiffy / 1000 * HZ * t)
+#define is_polling(x)	(x->port_conf->quirks & S3C64XX_SPI_QUIRK_POLL)
 
 #define RXBUSY    (1<<2)
 #define TXBUSY    (1<<3)
@@ -158,6 +160,7 @@ struct s3c64xx_spi_port_config {
 	int	fifo_lvl_mask[MAX_SPI_PORTS];
 	int	rx_lvl_offset;
 	int	tx_st_done;
+	int	quirks;
 	bool	high_speed;
 	bool	clk_from_cmu;
 };
@@ -344,8 +347,12 @@ static int s3c64xx_spi_prepare_transfer(struct spi_master *spi)
 {
 	struct s3c64xx_spi_driver_data *sdd = spi_master_get_devdata(spi);
 
-	/* Acquire DMA channels */
-	while (!acquire_dma(sdd))
+	/*
+	 * If DMA resource was not available during
+	 * probe, no need to continue with dma requests
+	 * else Acquire DMA channels
+	 */
+	while (!is_polling(sdd) && !acquire_dma(sdd))
 		usleep_range(10000, 11000);
 
 	pm_runtime_get_sync(&sdd->pdev->dev);
@@ -358,9 +365,12 @@ static int s3c64xx_spi_unprepare_transfer(struct spi_master *spi)
 	struct s3c64xx_spi_driver_data *sdd = spi_master_get_devdata(spi);
 
 	/* Free DMA channels */
-	sdd->ops->release((enum dma_ch)sdd->rx_dma.ch, &s3c64xx_spi_dma_client);
-	sdd->ops->release((enum dma_ch)sdd->tx_dma.ch, &s3c64xx_spi_dma_client);
-
+	if (!is_polling(sdd)) {
+		sdd->ops->release((enum dma_ch)sdd->rx_dma.ch,
+					&s3c64xx_spi_dma_client);
+		sdd->ops->release((enum dma_ch)sdd->tx_dma.ch,
+					&s3c64xx_spi_dma_client);
+	}
 	pm_runtime_put(&sdd->pdev->dev);
 
 	return 0;
@@ -464,8 +474,10 @@ static int s3c64xx_spi_unprepare_transfer(struct spi_master *spi)
 	struct s3c64xx_spi_driver_data *sdd = spi_master_get_devdata(spi);
 
 	/* Free DMA channels */
-	dma_release_channel(sdd->rx_dma.ch);
-	dma_release_channel(sdd->tx_dma.ch);
+	if (!is_polling(sdd)) {
+		dma_release_channel(sdd->rx_dma.ch);
+		dma_release_channel(sdd->tx_dma.ch);
+	}
 
 	pm_runtime_put(&sdd->pdev->dev);
 	return 0;
@@ -566,6 +578,27 @@ static inline void enable_cs(struct s3c64xx_spi_driver_data *sdd,
 
 	cs = spi->controller_data;
 	gpio_set_value(cs->line, spi->mode & SPI_CS_HIGH ? 1 : 0);
+
+	/* Start the signals */
+	writel(0, sdd->regs + S3C64XX_SPI_SLAVE_SEL);
+}
+
+static u32 wait_for_timeout(struct s3c64xx_spi_driver_data *sdd,
+					int timeout_ms)
+{
+	void __iomem *regs = sdd->regs;
+	unsigned long val;
+	u32 status;
+	/* max fifo depth available */
+	u32 max_fifo = (FIFO_LVL_MASK(sdd) >> 1) + 1;
+
+	val = msecs_to_loops(timeout_ms);
+	do {
+		status = readl(regs + S3C64XX_SPI_STATUS);
+	} while (RX_FIFO_LVL(status, sdd) < max_fifo && --val);
+
+	/* return the actual received data length */
+	return RX_FIFO_LVL(status, sdd);
 }
 
 static int wait_for_xfer(struct s3c64xx_spi_driver_data *sdd,
@@ -590,20 +623,19 @@ static int wait_for_xfer(struct s3c64xx_spi_driver_data *sdd,
 		} while (RX_FIFO_LVL(status, sdd) < xfer->len && --val);
 	}
 
-	if (!val)
-		return -EIO;
-
 	if (dma_mode) {
 		u32 status;
 
 		/*
+		 * If the previous xfer was completed within timeout, then
+		 * proceed further else return -EIO.
 		 * DmaTx returns after simply writing data in the FIFO,
 		 * w/o waiting for real transmission on the bus to finish.
 		 * DmaRx returns only after Dma read data from FIFO which
 		 * needs bus transmission to finish, so we don't worry if
 		 * Xfer involved Rx(with or without Tx).
 		 */
-		if (xfer->rx_buf == NULL) {
+		if (val && !xfer->rx_buf) {
 			val = msecs_to_loops(10);
 			status = readl(regs + S3C64XX_SPI_STATUS);
 			while ((TX_FIFO_LVL(status, sdd)
@@ -613,30 +645,53 @@ static int wait_for_xfer(struct s3c64xx_spi_driver_data *sdd,
 				status = readl(regs + S3C64XX_SPI_STATUS);
 			}
 
-			if (!val)
-				return -EIO;
 		}
+
+		/* If timed out while checking rx/tx status return error */
+		if (!val)
+			return -EIO;
 	} else {
+		int loops;
+		u32 cpy_len;
+		u8 *buf;
+
 		/* If it was only Tx */
-		if (xfer->rx_buf == NULL) {
+		if (!xfer->rx_buf) {
 			sdd->state &= ~TXBUSY;
 			return 0;
 		}
 
-		switch (sdd->cur_bpw) {
-		case 32:
-			ioread32_rep(regs + S3C64XX_SPI_RX_DATA,
-				xfer->rx_buf, xfer->len / 4);
-			break;
-		case 16:
-			ioread16_rep(regs + S3C64XX_SPI_RX_DATA,
-				xfer->rx_buf, xfer->len / 2);
-			break;
-		default:
-			ioread8_rep(regs + S3C64XX_SPI_RX_DATA,
-				xfer->rx_buf, xfer->len);
-			break;
-		}
+		/*
+		 * If the receive length is bigger than the controller fifo
+		 * size, calculate the loops and read the fifo as many times.
+		 * loops = length / max fifo size (calculated by using the
+		 * fifo mask).
+		 * For any size less than the fifo size the below code is
+		 * executed atleast once.
+		 */
+		loops = xfer->len / ((FIFO_LVL_MASK(sdd) >> 1) + 1);
+		buf = xfer->rx_buf;
+		do {
+			/* wait for data to be received in the fifo */
+			cpy_len = wait_for_timeout(sdd, ms);
+
+			switch (sdd->cur_bpw) {
+			case 32:
+				ioread32_rep(regs + S3C64XX_SPI_RX_DATA,
+					buf, cpy_len / 4);
+				break;
+			case 16:
+				ioread16_rep(regs + S3C64XX_SPI_RX_DATA,
+					buf, cpy_len / 2);
+				break;
+			default:
+				ioread8_rep(regs + S3C64XX_SPI_RX_DATA,
+					buf, cpy_len);
+				break;
+			}
+
+			buf = buf + cpy_len;
+		} while (loops--);
 		sdd->state &= ~RXBUSY;
 	}
 
@@ -652,6 +707,9 @@ static inline void disable_cs(struct s3c64xx_spi_driver_data *sdd,
 		sdd->tgl_spi = NULL;
 
 	gpio_set_value(cs->line, spi->mode & SPI_CS_HIGH ? 0 : 1);
+
+	/* Quiese the signals */
+	writel(S3C64XX_SPI_SLAVE_SIG_INACT, sdd->regs + S3C64XX_SPI_SLAVE_SEL);
 }
 
 static void s3c64xx_spi_config(struct s3c64xx_spi_driver_data *sdd)
@@ -733,7 +791,7 @@ static int s3c64xx_spi_map_mssg(struct s3c64xx_spi_driver_data *sdd,
 	struct device *dev = &sdd->pdev->dev;
 	struct spi_transfer *xfer;
 
-	if (msg->is_dma_mapped)
+	if (is_polling(sdd) || msg->is_dma_mapped)
 		return 0;
 
 	/* First mark all xfer unmapped */
@@ -782,7 +840,7 @@ static void s3c64xx_spi_unmap_mssg(struct s3c64xx_spi_driver_data *sdd,
 	struct device *dev = &sdd->pdev->dev;
 	struct spi_transfer *xfer;
 
-	if (msg->is_dma_mapped)
+	if (is_polling(sdd) || msg->is_dma_mapped)
 		return;
 
 	list_for_each_entry(xfer, &msg->transfers, transfer_list) {
@@ -861,8 +919,9 @@ static int s3c64xx_spi_transfer_one_message(struct spi_master *master,
 
 		/* Polling method for xfers not bigger than FIFO capacity */
 		use_dma = 0;
-		if (sdd->rx_dma.ch && sdd->tx_dma.ch &&
-		    (xfer->len > ((FIFO_LVL_MASK(sdd) >> 1) + 1)))
+		if (!is_polling(sdd) &&
+			(sdd->rx_dma.ch && sdd->tx_dma.ch &&
+			(xfer->len > ((FIFO_LVL_MASK(sdd) >> 1) + 1))))
 			use_dma = 1;
 
 		spin_lock_irqsave(&sdd->lock, flags);
@@ -876,17 +935,10 @@ static int s3c64xx_spi_transfer_one_message(struct spi_master *master,
 		/* Slave Select */
 		enable_cs(sdd, spi);
 
-		/* Start the signals */
-		writel(0, sdd->regs + S3C64XX_SPI_SLAVE_SEL);
-
 		spin_unlock_irqrestore(&sdd->lock, flags);
 
 		status = wait_for_xfer(sdd, xfer, use_dma);
 
-		/* Quiese the signals */
-		writel(S3C64XX_SPI_SLAVE_SIG_INACT,
-		       sdd->regs + S3C64XX_SPI_SLAVE_SEL);
-
 		if (status) {
 			dev_err(&spi->dev, "I/O Error: rx-%d tx-%d res:rx-%c tx-%c len-%d\n",
 				xfer->rx_buf ? 1 : 0, xfer->tx_buf ? 1 : 0,
@@ -1287,19 +1339,19 @@ static int s3c64xx_spi_probe(struct platform_device *pdev)
 	if (!sdd->pdev->dev.of_node) {
 		res = platform_get_resource(pdev, IORESOURCE_DMA,  0);
 		if (!res) {
-			dev_err(&pdev->dev, "Unable to get SPI tx dma "
-					"resource\n");
-			return -ENXIO;
-		}
-		sdd->tx_dma.dmach = res->start;
+			dev_warn(&pdev->dev, "Unable to get SPI tx dma "
+					"resource. Switching to poll mode\n");
+			sdd->port_conf->quirks = S3C64XX_SPI_QUIRK_POLL;
+		} else
+			sdd->tx_dma.dmach = res->start;
 
 		res = platform_get_resource(pdev, IORESOURCE_DMA,  1);
 		if (!res) {
-			dev_err(&pdev->dev, "Unable to get SPI rx dma "
-					"resource\n");
-			return -ENXIO;
-		}
-		sdd->rx_dma.dmach = res->start;
+			dev_warn(&pdev->dev, "Unable to get SPI rx dma "
+					"resource. Switching to poll mode\n");
+			sdd->port_conf->quirks = S3C64XX_SPI_QUIRK_POLL;
+		} else
+			sdd->rx_dma.dmach = res->start;
 	}
 
 	sdd->tx_dma.direction = DMA_MEM_TO_DEV;
-- 
1.7.5.4



From girishks2000 at gmail.com  Mon Apr 22 03:09:24 2013
From: girishks2000 at gmail.com (Girish K S)
Date: Mon, 22 Apr 2013 12:39:24 +0530
Subject: [PATCH 2/3] spi: s3c64xx: Added provision for dedicated cs pin
In-Reply-To: <1366614565-3743-1-git-send-email-ks.giri@samsung.com>
References: <1366614565-3743-1-git-send-email-ks.giri@samsung.com>
Message-ID: <1366614565-3743-3-git-send-email-ks.giri@samsung.com>

From: Girish K S <girishks2000 at gmail.com>

The existing driver supports gpio based /cs signal.
For controller's that have one device per controller,
the slave device's /cs signal might be internally controlled
by the chip select bit of slave select register. They are not
externally asserted/deasserted using gpio pin.

This patch adds support for controllers with dedicated /cs pin.
if "cs-gpio" property doesnt exist in a spi dts node, the controller
would treat the /cs pin as dedicated.

Signed-off-by: Girish K S <ks.giri at samsung.com>
---
 drivers/spi/spi-s3c64xx.c |   32 ++++++++++++++++++++++++--------
 1 files changed, 24 insertions(+), 8 deletions(-)

diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index 665fe2b..07f9e00 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -208,6 +208,7 @@ struct s3c64xx_spi_driver_data {
 	struct s3c64xx_spi_port_config	*port_conf;
 	unsigned int			port_id;
 	unsigned long			gpios[4];
+	bool				cs_gpio;
 };
 
 static void flush_fifo(struct s3c64xx_spi_driver_data *sdd)
@@ -570,14 +571,16 @@ static inline void enable_cs(struct s3c64xx_spi_driver_data *sdd,
 		if (sdd->tgl_spi != spi) { /* if last mssg on diff device */
 			/* Deselect the last toggled device */
 			cs = sdd->tgl_spi->controller_data;
-			gpio_set_value(cs->line,
-				spi->mode & SPI_CS_HIGH ? 0 : 1);
+			if (sdd->cs_gpio)
+				gpio_set_value(cs->line,
+					spi->mode & SPI_CS_HIGH ? 0 : 1);
 		}
 		sdd->tgl_spi = NULL;
 	}
 
 	cs = spi->controller_data;
-	gpio_set_value(cs->line, spi->mode & SPI_CS_HIGH ? 1 : 0);
+	if (sdd->cs_gpio)
+		gpio_set_value(cs->line, spi->mode & SPI_CS_HIGH ? 1 : 0);
 
 	/* Start the signals */
 	writel(0, sdd->regs + S3C64XX_SPI_SLAVE_SEL);
@@ -706,7 +709,8 @@ static inline void disable_cs(struct s3c64xx_spi_driver_data *sdd,
 	if (sdd->tgl_spi == spi)
 		sdd->tgl_spi = NULL;
 
-	gpio_set_value(cs->line, spi->mode & SPI_CS_HIGH ? 0 : 1);
+	if (sdd->cs_gpio)
+		gpio_set_value(cs->line, spi->mode & SPI_CS_HIGH ? 0 : 1);
 
 	/* Quiese the signals */
 	writel(S3C64XX_SPI_SLAVE_SIG_INACT, sdd->regs + S3C64XX_SPI_SLAVE_SEL);
@@ -1015,7 +1019,10 @@ static struct s3c64xx_spi_csinfo *s3c64xx_get_slave_ctrldata(
 		return ERR_PTR(-ENOMEM);
 	}
 
-	cs->line = of_get_named_gpio(data_np, "cs-gpio", 0);
+	/* The CS line is asserted/deasserted by the gpio pin */
+	if (sdd->cs_gpio)
+		cs->line = of_get_named_gpio(data_np, "cs-gpio", 0);
+
 	if (!gpio_is_valid(cs->line)) {
 		dev_err(&spi->dev, "chip select gpio is not specified or invalid\n");
 		kfree(cs);
@@ -1055,7 +1062,8 @@ static int s3c64xx_spi_setup(struct spi_device *spi)
 		return -ENODEV;
 	}
 
-	if (!spi_get_ctldata(spi)) {
+	/* Request gpio only if cs line is asserted by gpio pins */
+	if (sdd->cs_gpio) {
 		err = gpio_request_one(cs->line, GPIOF_OUT_INIT_HIGH,
 				       dev_name(&spi->dev));
 		if (err) {
@@ -1064,9 +1072,11 @@ static int s3c64xx_spi_setup(struct spi_device *spi)
 				cs->line, err);
 			goto err_gpio_req;
 		}
-		spi_set_ctldata(spi, cs);
 	}
 
+	if (!spi_get_ctldata(spi))
+		spi_set_ctldata(spi, cs);
+
 	sci = sdd->cntrlr_info;
 
 	spin_lock_irqsave(&sdd->lock, flags);
@@ -1144,8 +1154,10 @@ err_gpio_req:
 static void s3c64xx_spi_cleanup(struct spi_device *spi)
 {
 	struct s3c64xx_spi_csinfo *cs = spi_get_ctldata(spi);
+	struct s3c64xx_spi_driver_data *sdd;
 
-	if (cs) {
+	sdd = spi_master_get_devdata(spi->master);
+	if (cs && sdd->cs_gpio) {
 		gpio_free(cs->line);
 		if (spi->dev.of_node)
 			kfree(cs);
@@ -1322,7 +1334,11 @@ static int s3c64xx_spi_probe(struct platform_device *pdev)
 	sdd->cntrlr_info = sci;
 	sdd->pdev = pdev;
 	sdd->sfr_start = mem_res->start;
+	sdd->cs_gpio = false;
 	if (pdev->dev.of_node) {
+		if (of_find_property(pdev->dev.of_node, "cs-gpio", NULL))
+			sdd->cs_gpio = true;
+
 		ret = of_alias_get_id(pdev->dev.of_node, "spi");
 		if (ret < 0) {
 			dev_err(&pdev->dev, "failed to get alias id, errno %d\n",
-- 
1.7.5.4



From girishks2000 at gmail.com  Mon Apr 22 03:09:25 2013
From: girishks2000 at gmail.com (Girish K S)
Date: Mon, 22 Apr 2013 12:39:25 +0530
Subject: [PATCH 3/3] spi: s3c64xx: Added support for exynos5440 spi
In-Reply-To: <1366614565-3743-1-git-send-email-ks.giri@samsung.com>
References: <1366614565-3743-1-git-send-email-ks.giri@samsung.com>
Message-ID: <1366614565-3743-4-git-send-email-ks.giri@samsung.com>

From: Girish K S <girishks2000 at gmail.com>

This patch adds support for the exynos5440 spi controller.
The integration of the spi IP in exynos5440 is different from
other SoC's. The I/O pins are no more configured via gpio, they
have dedicated pins.

Signed-off-by: Girish K S <ks.giri at samsung.com>
---
 drivers/spi/spi-s3c64xx.c |   12 ++++++++++++
 1 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index 07f9e00..b2ef717 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -1603,6 +1603,15 @@ static struct s3c64xx_spi_port_config exynos4_spi_port_config = {
 	.clk_from_cmu	= true,
 };
 
+static struct s3c64xx_spi_port_config exynos5440_spi_port_config = {
+	.fifo_lvl_mask	= { 0x1ff },
+	.rx_lvl_offset	= 15,
+	.tx_st_done	= 25,
+	.high_speed	= true,
+	.clk_from_cmu	= true,
+	.quirks		= S3C64XX_SPI_QUIRK_POLL,
+};
+
 static struct platform_device_id s3c64xx_spi_driver_ids[] = {
 	{
 		.name		= "s3c2443-spi",
@@ -1631,6 +1640,9 @@ static const struct of_device_id s3c64xx_spi_dt_match[] = {
 	{ .compatible = "samsung,exynos4210-spi",
 			.data = (void *)&exynos4_spi_port_config,
 	},
+	{ .compatible = "samsung,exynos5440-spi",
+			.data = (void *)&exynos5440_spi_port_config,
+	},
 	{ },
 };
 MODULE_DEVICE_TABLE(of, s3c64xx_spi_dt_match);
-- 
1.7.5.4



From rogerq at ti.com  Mon Apr 22 03:23:57 2013
From: rogerq at ti.com (Roger Quadros)
Date: Mon, 22 Apr 2013 10:23:57 +0300
Subject: linux-next ARM multi-platform randconfig errors
In-Reply-To: <20130419161257.GI10155@atomide.com>
References: <5170B4C6.1030300@gmail.com> <20130419161257.GI10155@atomide.com>
Message-ID: <5174E58D.8080800@ti.com>

-Kevin Hilman <khilman at ti.com>
+Kevin Hilman <khilman at deeprootsystems.com>

On 04/19/2013 07:12 PM, Tony Lindgren wrote:
> * Rob Herring <robherring2 at gmail.com> [130418 20:11]:
>> Current errors in linux-next for ARM multi-platform randconfig builds.
>>
>> Rob
>>
>> arch/arm/mach-omap2/built-in.o:dss-common.c:(.init.text+0x6830): more undefined references to `usb_bind_phy' follow
> 
> Felipe & Roger, can you guys take a look at the usb_bind_phy issue
> in linux next? I have not seen that in the multiplatform randconfigs
> I've built, but I have had some omap2+ specific things enabled there.

These problems happen if USB_PHY is not enabled as a built-in driver.
I had pointed this out earlier [1] and Felipe should have a fix for it.

[1] https://lkml.org/lkml/2013/4/11/270

cheers,
-roger


From balbi at ti.com  Mon Apr 22 03:49:31 2013
From: balbi at ti.com (Felipe Balbi)
Date: Mon, 22 Apr 2013 10:49:31 +0300
Subject: Multiple issues with omap4 panda es in linux next
In-Reply-To: <20130419171318.GK10155@atomide.com>
References: <20130419171318.GK10155@atomide.com>
Message-ID: <20130422074931.GH10536@arwen.pp.htv.fi>

Hi,

On Fri, Apr 19, 2013 at 10:13:19AM -0700, Tony Lindgren wrote:
> 2. MUSB fails with legacy booting and DT on panda es
> 
> With both legacy and DT booting I get something like:
> 
> HS USB OTG: no transceiver configured
> musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with status -517

well, enable a transceiver :-p

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130422/a4fac839/attachment.sig>

From maxime.ripard at free-electrons.com  Mon Apr 22 03:58:02 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Mon, 22 Apr 2013 09:58:02 +0200
Subject: [PATCH 1/3] iio: Add Nuvoton NAU7802 ADC driver
In-Reply-To: <5172B68B.4010506@free-electrons.com>
References: <1366299536-18353-1-git-send-email-alexandre.belloni@free-electrons.com>
 <1366299536-18353-2-git-send-email-alexandre.belloni@free-electrons.com>
 <51726541.6060304@kernel.org> <5172B68B.4010506@free-electrons.com>
Message-ID: <5174ED8A.5090802@free-electrons.com>

Hi Alexandre, Jonathan,

Le 20/04/2013 17:38, Alexandre Belloni a ?crit :
> On 20/04/2013 11:52, Jonathan Cameron wrote:
>>> +	&iio_dev_attr_gain.dev_attr.attr,
>>> +	&iio_const_attr_gain_available.dev_attr.attr,
>>> +	&iio_dev_attr_min_conversions.dev_attr.attr,
>> What governs this?  Looks to me more like it should be hidden away
>> in the device tree than be here.
> 
> I guess it will depend on what you connect to your adc. Do we want to
> fix that in the DT or to be able to change it at runtime ?

I don't think so. Unless I misunderstood it, this attribute is the
number of conversions that must occur when switching from one channel to
another to get a good-enough precision for the ADC, right?

So I don't really see 1) why it could be changed by the user through
sysfs in the first place 2) this is not hardware configuration at all,
more some black magic within the driver, so it shouldn't be at all in
the device tree anyway.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


From maxime.ripard at free-electrons.com  Mon Apr 22 04:01:21 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Mon, 22 Apr 2013 10:01:21 +0200
Subject: [PATCH 1/3] iio: Add Nuvoton NAU7802 ADC driver
In-Reply-To: <1366299536-18353-2-git-send-email-alexandre.belloni@free-electrons.com>
References: <1366299536-18353-1-git-send-email-alexandre.belloni@free-electrons.com>
 <1366299536-18353-2-git-send-email-alexandre.belloni@free-electrons.com>
Message-ID: <5174EE51.4000606@free-electrons.com>

Hi Alexandre,

Le 18/04/2013 17:38, Alexandre Belloni a ?crit :
> +	nau7802_i2c_write(st, NAU7802_REG_PUCTRL, data);
> +	nau7802_i2c_write(st, NAU7802_REG_ADC_CTRL, 0x30);
> +
> +	if (tmp >= 2400) {
> +		data = NAU7802_CTRL1_VLDO((4500 - tmp) / 300);
> +		nau7802_i2c_write(st, NAU7802_REG_CTRL1, data);
> +	}

You should probably make a macro or inline function (with a comment) out
of that computation explaining why you are doing this.

> +
> +	st->min_conversions = 6;

I'd prefer to see this as a define.

> +
> +	/*
> +	 * The ADC fires continuously and we can't do anything about
> +	 * it. So we need to have the IRQ disabled by default, and we
> +	 * will enable them back when we will need them..
> +	 */
> +	if (client->irq) {
> +		irq_set_status_flags(client->irq, IRQ_NOAUTOEN);
> +		ret = request_threaded_irq(client->irq,
> +				NULL,
> +				nau7802_eoc_trigger,
> +				IRQF_TRIGGER_HIGH | IRQF_ONESHOT,
> +				client->dev.driver->name,
> +				idev);
> +		if (ret) {
> +			/*
> +			 * What may happen here is that our IRQ controller is
> +			 * not able to get level interrupt but this is required
> +			 * by this ADC as when going over 40 sample per second,
> +			 * the interrupt line may stay high between conversions.
> +			 * So, we continue no matter what but we switch to
> +			 * polling mode.
> +			 */
> +			dev_info(&client->dev,
> +				"Failed to allocate IRQ, using polling mode\n");
> +			client->irq = 0;
> +			/*
> +			 * We are polling, use the fastest sample rate by
> +			 * default
> +			 */
> +			st->sample_rate = 0x7;

Ditto.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


From maxime.ripard at free-electrons.com  Mon Apr 22 04:07:58 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Mon, 22 Apr 2013 10:07:58 +0200
Subject: [PATCH] video: mxsfb: Fix colors display on lower color depth
In-Reply-To: <20130418144838.GD2222@S2101-09.ap.freescale.net>
References: <516EBCA4.1020609@free-electrons.com>
 <1366277032-671-1-git-send-email-maxime.ripard@free-electrons.com>
 <20130418144838.GD2222@S2101-09.ap.freescale.net>
Message-ID: <5174EFDE.6080009@free-electrons.com>

Hi Shawn,

Le 18/04/2013 16:48, Shawn Guo a ?crit :
> Copy Sascha.

Ah, yes, sorry, I somehow got confused and thought you were the one that
wrote the driver.

I'll resend the patch.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


From maxime.ripard at free-electrons.com  Mon Apr 22 04:11:50 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Mon, 22 Apr 2013 10:11:50 +0200
Subject: [PATCH RESEND] video: mxsfb: Fix colors display on lower color depth
Message-ID: <1366618310-7068-1-git-send-email-maxime.ripard@free-electrons.com>

The current code always registers as a 32 bits display, and uses the
hardware to drop the MSB of each color to abjust to the interface width
used by the panel.

This results on 18 bits (and probably 16 bits display as well) in colors
being displayed poorly, because the MSB are obviously the most important
bits for each color definition.

The default controller behaviour when using an interface width smaller
than the color depth is to drop the LSBs of each color, which makes more
sense because you lose the least important part of the color definition.

So, to fix the colors display, just get back to the default controller
behaviour.

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
  - Copied Sascha

 drivers/video/mxsfb.c |    5 -----
 1 file changed, 5 deletions(-)

diff --git a/drivers/video/mxsfb.c b/drivers/video/mxsfb.c
index 755556c..2cfaf8b 100644
--- a/drivers/video/mxsfb.c
+++ b/drivers/video/mxsfb.c
@@ -424,11 +424,6 @@ static int mxsfb_set_par(struct fb_info *fb_info)
 			return -EINVAL;
 		case STMLCDIF_16BIT:
 		case STMLCDIF_18BIT:
-			/* 24 bit to 18 bit mapping */
-			ctrl |= CTRL_DF24; /* ignore the upper 2 bits in
-					    *  each colour component
-					    */
-			break;
 		case STMLCDIF_24BIT:
 			/* real 24 bit */
 			break;
-- 
1.7.10.4



From itooo at itooo.com  Mon Apr 22 04:19:41 2013
From: itooo at itooo.com (Greg)
Date: Mon, 22 Apr 2013 10:19:41 +0200
Subject: MVEBU and MVNETA driver
In-Reply-To: <20130422062024.GK30850@1wt.eu>
References: <5171419C.2090003@itooo.com> <20130419131237.GC22440@1wt.eu>
 <517150FF.9010806@itooo.com> <20130419144324.GD22440@1wt.eu>
 <51715BC7.3040906@free-electrons.com> <51716A8B.9080903@itooo.com>
 <20130422062024.GK30850@1wt.eu>
Message-ID: <5174F29D.5070908@itooo.com>

Le 22/04/2013 08:20, Willy Tarreau a ?crit :
> On Fri, Apr 19, 2013 at 06:02:19PM +0200, Greg wrote:
>> A simple tool like netcat shows ~470Mbps but this limited by the CPU.
>> Iperf isn't CPU limited
>>
>> The same test with Marvell LSP shows ~940Mbps in both directions.
> I've retested here on my mirabox using httpterm as the tcp server.
> Using the normal send() syscall, it emits 839 Mbps on a single TCP
> connection. Using splice(), it emits 969 Mbps in the same conditions.
>
> Here's what ethtool is saying about the NIC's tuning :
> # ethtool -k eth0
> Offload parameters for eth0:
> rx-checksumming: off
> tx-checksumming: on
> scatter-gather: on
> tcp-segmentation-offload: off
> udp-fragmentation-offload: off
> generic-segmentation-offload: on
> generic-receive-offload: on
> large-receive-offload: off
> rx-vlan-offload: off
> tx-vlan-offload: off
> ntuple-filters: off
> receive-hashing: off
>
> I've tried changing other settings such as the interrupt delays
> (rx-usecs, rx-frames, tx-frames) but this has no effect. So in
> short, I cannot reproduce this behaviour. Are you using the SLOB
> allocator ? I'm asking because I remember experiencing very poor
> performance with it in the past.
>
Willy,

I'm using SLAB allocator.
As for offloading, I can't seem to be able to turn it on :
> $ ethtool -K eth0 gro on
> Cannot set device GRO settings: Operation not supported
> $ ethtool -K eth0 gso on
> Cannot set device generic segmentation offload settings: Operation not 
> supported
Default values :
> $ ethtool -k eth0
> Offload parameters for eth0:
> rx-checksumming: off
> tx-checksumming: on
> scatter-gather: on
> tcp-segmentation-offload: off
> udp-fragmentation-offload: off
> generic-segmentation-offload: off
> generic-receive-offload: off
> large-receive-offload: off
> rx-vlan-offload: off
> tx-vlan-offload: off
> ntuple-filters: off
> receive-hashing: off

I can see 1 difference between our setups, Mirabox has an Armada370, I 
have an ArmadaXP, it would be interesting to know what Gregory is using.

Another difference on my setup, and something I wanted to report you : 
there is no PHY on my system. I had to instantiate a dummy PHY in the 
device tree blob and bind it to the mvneta driver because it would fail 
at init without PHY.

Regards,


From iamjoonsoo.kim at lge.com  Mon Apr 22 04:22:25 2013
From: iamjoonsoo.kim at lge.com (Joonsoo Kim)
Date: Mon, 22 Apr 2013 17:22:25 +0900
Subject: [RFC PATCH 0/6] ARM: use NO_BOOTMEM on default configuration
In-Reply-To: <1364184674-13798-1-git-send-email-iamjoonsoo.kim@lge.com>
References: <1364184674-13798-1-git-send-email-iamjoonsoo.kim@lge.com>
Message-ID: <20130422082225.GB19454@lge.com>

On Mon, Mar 25, 2013 at 01:11:08PM +0900, Joonsoo Kim wrote:
> Currently, ARM use traditional 'bootmem' allocator. It use a bitmap for
> managing memory space, so initialize a bitmap at first step. It is
> a needless overhead if we use 'nobootmem'. 'nobootmem' use a memblock
> allocator internally, so there is no additional initializing overhead.
> In addition, if we use 'nobootmem', we can save small amount of memory,
> because 'nobootmem' manage memory space as byte unit. However, 
> 'bootmem' manage it as page unit, so some space is wasted,
> although it is very small. On my system, 20 KB memories can be saved. :)
> Using 'nobootmem' have another advantage. Before initializing 'bootmem'
> allocator, we use memblock allocator. If we use memblock allocator
> after initializing 'bootmem' by mistake, there is possible problem.
> Patch '1/6' is good example of this case. 'nobootmem' use memblock
> allocator internally, so these risk will be disappeared.
> 
> There is one stopper to enable NO_BOOTMEM, it is max_low_pfn.
> nobootmem use max_low_pfn for computing boundary in free_all_bootmem()
> So we need proper value to max_low_pfn.
> But, there is some difficulty related to max_low_pfn. max_low_pfn is used
> for two meanings in various architectures. One is for number of pages
> in lowmem and the other is for maximum lowmem pfn. Now, in ARM, it is used
> as number of pages in lowmem. You can get more information in below link.
> http://lwn.net/Articles/543408/
> http://lwn.net/Articles/543424/
>     
> As I investigated, architectures which use max_low_pfn as maximum pfn are
> more than others, so IMHO, to change meaning of max_low_pfn to maximum pfn
> is preferable solution to me. This patchset change max_low_pfn as maximum
> lowmem pfn in ARM. In addition, min_low_pfn, max_pfn is assigned according
> to this criteria.
> 
> AFAIK, there is no real user for max_low_pfn except block/blk-setting.c
> and blk-setting.c assume that max_low_pfn is maximum lowmem pfn,
> so this patch may not harm anything. But, I'm not expert about this,
> so please let me know what I am missing.
> 
> I did some working test on my android device and it worked. :)
> Feel free to give me some opinion about this patset.
> This patchset is based on v3.9-rc4.
> 
> Thanks.
> 
> Joonsoo Kim (6):
>   ARM, TCM: initialize TCM in paging_init(), instead of setup_arch()
>   ARM, crashkernel: use ___alloc_bootmem_node_nopanic() for reserving
>     memory
>   ARM, crashkernel: correct total_mem size in reserve_crashkernel()
>   ARM, mm: don't do arm_bootmem_init() if CONFIG_NO_BOOTMEM
>   ARM, mm: change meaning of max_low_pfn to maximum pfn for nobootmem
>   ARM, mm: enable NO_BOOTMEM for default ARM build
> 
>  arch/arm/Kconfig        |    1 +
>  arch/arm/kernel/setup.c |   22 ++++++++--------------
>  arch/arm/kernel/tcm.c   |    1 -
>  arch/arm/kernel/tcm.h   |   17 -----------------
>  arch/arm/mm/init.c      |   19 ++++++++++++-------
>  arch/arm/mm/mmu.c       |    2 ++
>  arch/arm/mm/tcm.h       |   17 +++++++++++++++++
>  7 files changed, 40 insertions(+), 39 deletions(-)
>  delete mode 100644 arch/arm/kernel/tcm.h
>  create mode 100644 arch/arm/mm/tcm.h

Hello, guys.

Could you review and comment this patchset?
[1/6] is already merged, but others wait for someone's review :)

Thanks.

> 
> -- 
> 1.7.9.5
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/


From balbi at ti.com  Mon Apr 22 04:21:49 2013
From: balbi at ti.com (Felipe Balbi)
Date: Mon, 22 Apr 2013 11:21:49 +0300
Subject: linux-next ARM multi-platform randconfig errors
In-Reply-To: <5174E58D.8080800@ti.com>
References: <5170B4C6.1030300@gmail.com> <20130419161257.GI10155@atomide.com>
 <5174E58D.8080800@ti.com>
Message-ID: <20130422082149.GK10536@arwen.pp.htv.fi>

Hi,

On Mon, Apr 22, 2013 at 10:23:57AM +0300, Roger Quadros wrote:
> -Kevin Hilman <khilman at ti.com>
> +Kevin Hilman <khilman at deeprootsystems.com>
> 
> On 04/19/2013 07:12 PM, Tony Lindgren wrote:
> > * Rob Herring <robherring2 at gmail.com> [130418 20:11]:
> >> Current errors in linux-next for ARM multi-platform randconfig builds.
> >>
> >> Rob
> >>
> >> arch/arm/mach-omap2/built-in.o:dss-common.c:(.init.text+0x6830): more undefined references to `usb_bind_phy' follow
> > 
> > Felipe & Roger, can you guys take a look at the usb_bind_phy issue
> > in linux next? I have not seen that in the multiplatform randconfigs
> > I've built, but I have had some omap2+ specific things enabled there.
> 
> These problems happen if USB_PHY is not enabled as a built-in driver.
> I had pointed this out earlier [1] and Felipe should have a fix for it.

yeah, ideally we wouldn't do any 'select' and just update defconfig with
the necessary changes. We need the patch below to update defconfig and
another patch to stub out usb_bind_phy when !USB_PHY.

8< ---------------------- cut here -------------------------------------

From 3062dbf02d0f677aabd5c12333e446ab0c13afc0 Mon Sep 17 00:00:00 2001
From: Felipe Balbi <balbi at ti.com>
Date: Mon, 22 Apr 2013 11:10:23 +0300
Subject: [PATCH] arm: defconfigs: add USB_PHY to omap2plus_defconfig

without USB_PHY (and a few PHY drivers) we won't
have functional USB on any OMAP platform.

Enable some sensible defaults so omap2plus_defconfig
works for most platforms.

Signed-off-by: Felipe Balbi <balbi at ti.com>
---
 arch/arm/configs/omap2plus_defconfig | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig
index bd07864..8c243ac 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -74,6 +74,7 @@ CONFIG_CMA=y
 CONFIG_CONNECTOR=y
 CONFIG_DEVTMPFS=y
 CONFIG_DEVTMPFS_MOUNT=y
+CONFIG_OMAP_OCP2SCP=y
 CONFIG_MTD=y
 CONFIG_MTD_CMDLINE_PARTS=y
 CONFIG_MTD_CHAR=y
@@ -205,6 +206,11 @@ CONFIG_USB_WDM=y
 CONFIG_USB_STORAGE=y
 CONFIG_USB_LIBUSUAL=y
 CONFIG_USB_TEST=y
+CONFIG_USB_PHY=y
+CONFIG_NOP_USB_XCEIV=y
+CONFIG_OMAP_USB2=y
+CONFIG_OMAP_USB3=y
+CONFIG_USB_ULPI=y
 CONFIG_USB_GADGET=y
 CONFIG_USB_GADGET_DEBUG=y
 CONFIG_USB_GADGET_DEBUG_FILES=y
-- 
1.8.2


-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130422/61ed6eae/attachment.sig>

From tomi.valkeinen at ti.com  Mon Apr 22 04:32:19 2013
From: tomi.valkeinen at ti.com (Tomi Valkeinen)
Date: Mon, 22 Apr 2013 11:32:19 +0300
Subject: [GIT PULL] omap dss board clean-up for v3.10 merge window
In-Reply-To: <20130419184518.GA30836@quad.lixom.net>
References: <20130418033936.GC10155@atomide.com>
 <20130419184518.GA30836@quad.lixom.net>
Message-ID: <5174F593.20705@ti.com>

On 2013-04-19 21:45, Olof Johansson wrote:
> Hi,
> 
> On Wed, Apr 17, 2013 at 08:39:37PM -0700, Tony Lindgren wrote:
>> The following changes since commit 07961ac7c0ee8b546658717034fe692fd12eefa9:
>>
>>   Linux 3.9-rc5 (2013-03-31 15:12:43 -0700)
>>
>> are available in the git repository at:
>>
>>   git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.10/dss-signed
> 
> 
> Merged, but not happy about it.

Thanks.

> As mentioned on IRC, I was going to let this one be until 3.11, but it sounds
> like it will cause regressions in DSS if we don't merge it.

Yes, that's true. The branch has been unchanged and in linux-next, so
merging it late shouldn't cause any bigger issues. But I understand it's
quite late, and I should've pushed the branch forward much earlier.
Sorry about that.

> This is an indication that the work wasn't done right on the DSS rework.
> Ideally the old configurations through platform_data should have been left in
> for a release to give the boards a window to convert over without regressing
> functionality. Tomi, please don't do it this way in the future since it's
> painful for everybody to deal with.

I've been trying to keep everything working even if parts of the whole
series go through different trees. I've been very strict on that things
must compile, but keeping display working if only half of the series is
merged is rather difficult at times.

For this series, I think it could've been done, but it would have
required adding hacks, or some kind of "bool new_pdata" fields so that
the driver understand what to do. And duplicate code to manage the
different platform data versions.

In the near future we'll get rid of the current custom omapdss panel
device, and use the standard platform/i2c/etc devices for the panel. The
only way to do that while keeping everything running is to clone the
panel drivers, one handling the old one and the other handling the new one.

All this makes me spend lots of time doing extra work, that in no way
improves the driver. Its only for the purpose of getting arch changes
through one tree, and driver changes through the other. And this makes
the patches much more difficult to follow, as the related changes are in
separate series, and there may be extra crud just to handle this separation.

So while I think it is a good habit to push the arch changes and driver
changes separately, my question is, should that rule be followed to the
extreme? Can I just keep all the changes in one branch if separating the
arch and driver changes would end up with cloning files or lots of extra
code?

Of course, I don't know what DRM maintainer thinks of merging arch
changes through his tree, so that's also open.

 Tomi


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130422/a5bb66d4/attachment.sig>

From kishon at ti.com  Mon Apr 22 04:41:12 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Mon, 22 Apr 2013 14:11:12 +0530
Subject: Multiple issues with omap4 panda es in linux next
In-Reply-To: <20130419171318.GK10155@atomide.com>
References: <20130419171318.GK10155@atomide.com>
Message-ID: <5174F7A8.7070308@ti.com>

Hi,

On Friday 19 April 2013 10:43 PM, Tony Lindgren wrote:
> Hi all,
>
> Here's a list of breakage I've noticed so far while trying to
> use linux next on my pandaboard es. Probably similar issues exist
> on other boards as well.
>
> Ideally we would not have any breakage by the merge window, so
> let's try to get these fixed ASAP:
>
> 1. Serial console broken on panda es booting with DT
>
> The symptoms are dmesg output stopping after few lines
> and only continuing after pressing a key. Does not seem to
> happen on blaze with DT for some reason. And does not happen
> on panda es with legacy booting.
>
> 2. MUSB fails with legacy booting and DT on panda es
>
> With both legacy and DT booting I get something like:
>
> HS USB OTG: no transceiver configured
> musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with status -517

The dt should work fine with https://patchwork.kernel.org/patch/2423061/.

But non-dt has got a real issue. We were using usb_bind_phy() for 
binding the controller with the PHY (we use device names). But in 
linux-next the device names have changed because of using 
PLATFORM_DEVID_AUTO. We can modify the usb_bind_phy() calls to use the 
new device names, But I suspect the device names can change again. Not 
sure what we can do here :-(

Thanks
Kishon


From sam at ravnborg.org  Mon Apr 22 04:56:19 2013
From: sam at ravnborg.org (Sam Ravnborg)
Date: Mon, 22 Apr 2013 10:56:19 +0200
Subject: [PATCH 1/2] Allow constructor name selection by architecture.
In-Reply-To: <20130418123931.GR14496@n2100.arm.linux.org.uk>
References: <1338230018-31052-1-git-send-email-vincent.sanders@collabora.co.uk>
 <1338230018-31052-2-git-send-email-vincent.sanders@collabora.co.uk>
 <20120528203005.GA20560@merkur.ravnborg.org>
 <20120529090614.GD12217@n2100.arm.linux.org.uk>
 <20120606101253.GM8262@n2100.arm.linux.org.uk>
 <87F2CC87-0FAF-49CB-AE70-423FB063A0E5@mvista.com>
 <20130401215834.GA5972@merkur.ravnborg.org>
 <CAE1uF8dCy3m3TO4xa6Cc3i-CM3QYUFADZH_6o+hgy6MSPEWnyQ@mail.gmail.com>
 <20130418123931.GR14496@n2100.arm.linux.org.uk>
Message-ID: <20130422085619.GA9393@merkur.ravnborg.org>

On Thu, Apr 18, 2013 at 01:39:31PM +0100, Russell King - ARM Linux wrote:
> Looks to me like this has died again.  Unless Sam responds shortly,
> I'm going to ask for this to be put into the patch system and I'll
> just apply it for 3.10 and be done with it.

I had preferred it was a solution where we supported both
variants in the code.
But I do not feel strongly about it.

So you can add my ack and apply it.
Acked-by: Sam Ravnborg <sam at ravnborg.org>

	Sam


From marex at denx.de  Mon Apr 22 04:47:14 2013
From: marex at denx.de (Marek Vasut)
Date: Mon, 22 Apr 2013 10:47:14 +0200
Subject: [PATCH 1/8] ARM: mx5: Add AUDMUX4 pinctrl data
In-Reply-To: <20130422050049.GB10821@S2101-09.ap.freescale.net>
References: <1366579808-12067-1-git-send-email-marex@denx.de>
 <20130422050049.GB10821@S2101-09.ap.freescale.net>
Message-ID: <201304221047.14842.marex@denx.de>

Hi Shawn,

> On Sun, Apr 21, 2013 at 11:30:01PM +0200, Marek Vasut wrote:
> > This patch adds pinctrl data for the AUDMUX4 on MX53.
> > 
> > Signed-off-by: Marek Vasut <marex at denx.de>
> > Cc: Fabio Estevam <fabio.estevam at freescale.com>
> > Cc: Shawn Guo <shawn.guo at linaro.org>
> 
> Applied 1~7, with some small fixups (see replies).

Thanks, really appreciated! I'll fix 0008 and repost only that one.

Best regards,
Marek Vasut


From jic23 at jic23.retrosnub.co.uk  Mon Apr 22 05:04:30 2013
From: jic23 at jic23.retrosnub.co.uk (Jonathan Cameron)
Date: Mon, 22 Apr 2013 10:04:30 +0100
Subject: [PATCH 1/3] iio: Add Nuvoton NAU7802 ADC driver
In-Reply-To: <5172B68B.4010506@free-electrons.com>
References: <1366299536-18353-1-git-send-email-alexandre.belloni@free-electrons.com>
 <1366299536-18353-2-git-send-email-alexandre.belloni@free-electrons.com>
 <51726541.6060304@kernel.org> <5172B68B.4010506@free-electrons.com>
Message-ID: <5174FD1E.30605@jic23.retrosnub.co.uk>

On 20/04/13 16:38, Alexandre Belloni wrote:
> Hi Jonathan,
>
> Thanks for your review,
>
> On 20/04/2013 11:52, Jonathan Cameron wrote:
>> A few bits and pieces inline.
>>
>> Ouch, that interrupt handling is annoyingly complex.  Pesky hardware
>> designers...
>>
>
> Right, even worse is that on the board we are using, the interrupt line
> is connected to a pca9555 and that seems to not handle interrupts very
> well and I think something is fishy in the driver. From want I read in
> the datasheet, I suspect it only handles level interrupts but the driver
> is only accepting edge interrupts.
> It seems that sometimes we end up with the nau7802 correctly sending an
> interrupt, the pca also correctly sending an interrupt but the pca
> driver is then not calling the interrupt handlers. I also suspect the
> nau7802 to forget to switch the interrupt line when we ask for fast
> conversions. I investigated that a bit but I'm still waiting for my
> logic analyzer to get delivered to go further.
Fair enough.  We are very early in the cycle so plenty of time for you
to pin that down before we merge this.
>
>>> diff --git a/Documentation/devicetree/bindings/iio/adc/nuvoton-nau7802.txt b/Documentation/devicetree/bindings/iio/adc/nuvoton-nau7802.txt
>>> new file mode 100644
>>> index 0000000..9bc4218
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/iio/adc/nuvoton-nau7802.txt
>>> @@ -0,0 +1,17 @@
>>> +* Nuvoton NAU7802 Analog to Digital Converter (ADC)
>>> +
>>> +Required properties:
>>> +  - compatible: Should be "nuvoton,nau7802"
>>> +  - reg: Should contain the ADC I2C address
>>> +
>>> +Optional properties:
>>> +  - nuvoton,vldo: Reference voltage in millivolts (integer)
>> As this is external I'd personally prefer using the regulator subsystem
>> to provide it.  That gives a more flexible way of supplying it.
>> If fixed you can always use a fixed regulator...
>
> Actually, that one allows us to configure the internal LDO. The nau7802
> is also able to get that voltage from an external source but indeed,
> this is not well handled by the driver currently. How do you suggest to
> manage those cases then ?
The decision on whether it is an external ref is probably a job for 
device tree as chances you want the internal one when someone has
wired up the external is low to non existent.

As for configuring it, then perhaps it does make sense to do it as
you have here.
>
>>
>> +
>> +struct nau7802_state {
>> +	struct i2c_client	*client;
>> +	s32			last_value;
>> I can't immediately see why you need two locks...
>> I think the datalock is only ever taken when the
>> lock is already held (be it in a threaded irq).
>
> Actually, "lock" is taken by read_raw() but, we still want the interrupt
> handler thread to be able to run while waiting for the completion (else,
> we would just timeout every time). Main goal of data_lock is to prevent
> reading part of the output from the interrupt handler and part from
> read_raw().
Fair enough.  Thanks for the explanation...
>
>>> +	struct mutex		lock;
>>> +	struct mutex		data_lock;
>>> +	u32			vref_mv;
>>> +	u32			conversion_count;
>>> +	u32			min_conversions;
>>> +	u8			sample_rate;
>>> +	struct completion	value_ok;
>>> +};
>>> +
>>> +static int nau7802_i2c_read(struct nau7802_state *st, u8 reg, u8 *data)
>>> +{
>>> +	int ret = 0;
>>> +
>>> +	ret = i2c_smbus_read_byte_data(st->client, reg);
>>> +	if (ret < 0) {
>>> +		dev_err(&st->client->dev, "failed to read from I2C\n");
>>> +		return ret;
>>> +	}
>>> +
>>> +	*data = ret;
>>> +
>>> +	return 0;
>>> +}
>>> +
>> Don't wrap standard functions like this. Call them directly. It's not
>> worth the added complexity to get a not particularly informative error message
>> from the read.
>
> OK, it was mainly useful for debugging as we had some troubles with the
> underlying i2c driver. I will remove those.
>
>>> +static int nau7802_i2c_write(struct nau7802_state *st, u8 reg, u8 data)
>>> +{
>>> +	return i2c_smbus_write_byte_data(st->client, reg, data);
>>> +}
>>> +
>>> +static const u16 nau7802_sample_freq_avail[] = {10, 20, 40, 80,
>>> +						10, 10, 10, 320};
>>> +
>>> +static ssize_t nau7802_sysfs_set_sampling_frequency(struct device *dev,
>>> +		struct device_attribute *attr,
>>> +		const char *buf,
>>> +		size_t len)
>>> +{
>>> +	struct iio_dev *idev = dev_to_iio_dev(dev);
>>> +	struct nau7802_state *st = iio_priv(idev);
>>> +	u32 val;
>>> +	int ret, i;
>>> +
>>> +	ret = kstrtouint(buf, 10, &val);
>>> +	if (ret)
>>> +		return ret;
>>> +
>>> +	ret = -EINVAL;
>>> +	for (i = 0; i < 8; i++)
>>> +		if (val == nau7802_sample_freq_avail[i]) {
>>> +			mutex_lock(&st->lock);
>>> +			st->sample_rate = i;
>>> +			st->conversion_count = 0;
>>> +			nau7802_i2c_write(st, NAU7802_REG_CTRL2,
>>> +					NAU7802_CTRL2_CRS(st->sample_rate));
>>> +			mutex_unlock(&st->lock);
>>> +			ret = len;
>>> +			break;
>>> +		}
>>> +	return ret;
>>> +}
>>> +
>>> +static ssize_t nau7802_sysfs_get_sampling_frequency(struct device *dev,
>>> +		struct device_attribute *attr,
>>> +		char *buf)
>>> +{
>>> +	struct iio_dev *idev = dev_to_iio_dev(dev);
>>> +	struct nau7802_state *st = iio_priv(idev);
>>> +
>>> +	return sprintf(buf, "%d\n",
>>> +	       nau7802_sample_freq_avail[st->sample_rate]);
>>> +}
>>> +
>>> +static IIO_DEV_ATTR_SAMP_FREQ(S_IWUSR | S_IRUGO,
>>> +		nau7802_sysfs_get_sampling_frequency,
>>> +		nau7802_sysfs_set_sampling_frequency);
>>> +
>>> +static IIO_CONST_ATTR_SAMP_FREQ_AVAIL("10 40 80 320");
>>> +
>>> +static IIO_CONST_ATTR(gain_available, "1 2 4 8 16 32 64 128");
>>> +
>>> +static ssize_t nau7802_sysfs_set_gain(struct device *dev,
>>> +		struct device_attribute *attr,
>>> +		const char *buf,
>>> +		size_t len)
>>> +{
>>> +	struct iio_dev *idev = dev_to_iio_dev(dev);
>>> +	struct nau7802_state *st = iio_priv(idev);
>>> +	u32 val;
>>> +	u8 data;
>>> +	int ret;
>>> +
>>> +	ret = kstrtouint(buf, 10, &val);
>>> +	if (ret)
>>> +		return ret;
>>> +
>>> +	if (val < 1 || val > 128 || !is_power_of_2(val))
>>> +		return -EINVAL;
>>> +
>>> +	mutex_lock(&st->lock);
>>> +	st->conversion_count = 0;
>>> +
>>> +	ret = nau7802_i2c_read(st, NAU7802_REG_CTRL1, &data);
>>> +	if (ret < 0)
>>> +		goto nau7802_sysfs_set_gain_out;
>>> +	ret = nau7802_i2c_write(st, NAU7802_REG_CTRL1,
>>> +			(data & (~NAU7802_CTRL1_GAINS_BITS)) | ilog2(val));
>>> +nau7802_sysfs_set_gain_out:
>>> +	mutex_unlock(&st->lock);
>>> +	return ret ? ret : len;
>>> +}
>>> +
>>> +static ssize_t nau7802_sysfs_get_gain(struct device *dev,
>>> +		struct device_attribute *attr,
>>> +		char *buf)
>>> +{
>>> +	struct iio_dev *idev = dev_to_iio_dev(dev);
>>> +	struct nau7802_state *st = iio_priv(idev);
>>> +	u8 data;
>>> +	int ret;
>>> +
>>> +	ret = nau7802_i2c_read(st, NAU7802_REG_CTRL1, &data);
>>> +	if (ret < 0)
>>> +		return ret;
>>> +
>>> +	return sprintf(buf, "%d\n", 1 << (data & NAU7802_CTRL1_GAINS_BITS));
>>> +}
>>> +
>>> +static IIO_DEVICE_ATTR(gain, S_IWUSR | S_IRUGO,
>>> +		nau7802_sysfs_get_gain,
>>> +		nau7802_sysfs_set_gain, 0);
>>> +
>>> +static ssize_t nau7802_sysfs_set_min_conversions(struct device *dev,
>>> +		struct device_attribute *attr,
>>> +		const char *buf,
>>> +		size_t len)
>>> +{
>>> +	struct iio_dev *idev = dev_to_iio_dev(dev);
>>> +	struct nau7802_state *st = iio_priv(idev);
>>> +	u32 val;
>>> +	int ret;
>>> +
>>> +	ret = kstrtouint(buf, 10, &val);
>>> +	if (ret)
>>> +		return ret;
>>> +
>>> +	mutex_lock(&st->lock);
>>> +	st->min_conversions = val;
>>> +	st->conversion_count = 0;
>>> +	mutex_unlock(&st->lock);
>>> +	return len;
>>> +}
>>> +
>>> +static ssize_t nau7802_sysfs_get_min_conversions(struct device *dev,
>>> +		struct device_attribute *attr,
>>> +		char *buf)
>>> +{
>>> +	struct iio_dev *idev = dev_to_iio_dev(dev);
>>> +	struct nau7802_state *st = iio_priv(idev);
>>> +
>>> +	return sprintf(buf, "%d\n", st->min_conversions);
>>> +}
>>> +
>>> +static IIO_DEVICE_ATTR(min_conversions, S_IWUSR | S_IRUGO,
>>> +		nau7802_sysfs_get_min_conversions,
>>> +		nau7802_sysfs_set_min_conversions, 0);
>>> +
>>> +static struct attribute *nau7802_attributes[] = {
>> Given you have only adc channels you could just use the relevant
>> info_mask element for and have this as a shared attribute of them.
>
> Right, I'll have a look at that.
>>> +	&iio_dev_attr_sampling_frequency.dev_attr.attr,
>>> +	&iio_const_attr_sampling_frequency_available.dev_attr.attr,
>> Just have a range of scale options available and figure out which
>> gain they correspond to.  Obviously you'll need a write_raw callback
>> to implement that, but it's pretty standard and conforms to the iio
>> abi which this does not.   I've been meaning to clean up the way
>> 'available' is handled but for now you will probaby want to have
>> a suitable gain here.
>
> Yeah, I was wondering about doing that. But as it is also possible to
> set the internal voltage, I will have to be clever to get the best vldo
> and gain couple to have the best range.
Yes.  If you can possibly drop a user control without loosing 
functionality then it would be great.
>
>>> +	&iio_dev_attr_gain.dev_attr.attr,
>>> +	&iio_const_attr_gain_available.dev_attr.attr,
>>> +	&iio_dev_attr_min_conversions.dev_attr.attr,
>> What governs this?  Looks to me more like it should be hidden away
>> in the device tree than be here.
>
> I guess it will depend on what you connect to your adc. Do we want to
> fix that in the DT or to be able to change it at runtime ?
>
I'll leave that for the other branch of this thread.
>>> +	NULL
>>> +};
>>> +
>>> +static const struct attribute_group nau7802_attribute_group = {
>>> +	.attrs = nau7802_attributes,
>>> +};
>>> +
>>> +static int nau7802_read_conversion(struct nau7802_state *st)
>>> +{
>>> +	int ret;
>>> +	u8 data;
>>> +
>>> +	mutex_lock(&st->data_lock);
>>> +	ret = nau7802_i2c_read(st, NAU7802_REG_ADC_B2, &data);
>>> +	if (ret)
>>> +		goto nau7802_read_conversion_out;
>>> +	st->last_value = data << 24;
>>> +
>>> +	ret = nau7802_i2c_read(st, NAU7802_REG_ADC_B1, &data);
>>> +	if (ret)
>>> +		goto nau7802_read_conversion_out;
>>> +	st->last_value |= data << 16;
>>> +
>>> +	ret = nau7802_i2c_read(st, NAU7802_REG_ADC_B0, &data);
>>> +	if (ret)
>>> +		goto nau7802_read_conversion_out;
>>> +	st->last_value |= data << 8;
>>> +
>>> +	st->last_value >>= 8;
>> umm. Why shift everything 8 to the left then 8 to the right?
>
> The nau7802 is handling 24 bits of *signed* data. Doing that allows us
> to store the signed 24bits value in a signed 32bits integer. Is there a
> more clever way ?
Ah, missed that.  It might still make sense form a readability point
of view to build it as a 24bit signed value then use the existing
sign extension function sign_extend32 to do the extension.  With a bit
of luck the compiler will figure it out and give your roughly the same
result, but with marginally more readable code?
>
>>> +
>>> +nau7802_read_conversion_out:
>>> +	mutex_unlock(&st->data_lock);
>>> +	return ret;
>>> +}
>>> +
>> What does this do?  Perhaps a comment?
> The conversions are synchronized on the rising edge of the CS bit of
> PUCTRL. It is not necessarily needed but it can be nice when wse are
> running slow, like at 10 samples per second.
>>> +static int nau7802_sync(struct nau7802_state *st)
>>> +{
>>> +	int ret;
>>> +	u8 data;
>>> +
>>> +	ret = nau7802_i2c_read(st, NAU7802_REG_PUCTRL, &data);
>>> +	if (ret)
>>> +		return ret;
>>> +	ret = nau7802_i2c_write(st, NAU7802_REG_PUCTRL,
>>> +				data | NAU7802_PUCTRL_CS_BIT);
>>> +	return ret;
>>> +}
>>> +
>>> +static irqreturn_t nau7802_eoc_trigger(int irq, void *private)
>>> +{
>>> +	struct iio_dev *idev = private;
>>> +	struct nau7802_state *st = iio_priv(idev);
>>> +	u8 status;
>>> +	int ret;
>>> +
>>> +	ret = nau7802_i2c_read(st, NAU7802_REG_PUCTRL, &status);
>>> +	if (ret)
>>> +		return IRQ_HANDLED;
>>> +
>>> +	if (!(status & NAU7802_PUCTRL_CR_BIT))
>>> +		return IRQ_NONE;
>>> +
>>> +	if (nau7802_read_conversion(st))
>>> +		return IRQ_HANDLED;
>>> +
>>> +	/* wait for enough conversions before getting a stable value when
>>> +	 * changing channels */
>>> +	if (st->conversion_count < st->min_conversions)
>>> +		st->conversion_count++;
>>> +	if (st->conversion_count >= st->min_conversions)
>>> +		complete_all(&st->value_ok);
>> pretty much always stick in a  blank line before return statements.
>> Makes it easier to read...
>
> Will do.
>>> +	return IRQ_HANDLED;
>>> +}
>>> +
>>> +static int nau7802_read_irq(struct iio_dev *idev,
>>> +			struct iio_chan_spec const *chan,
>>> +			int *val)
>>> +{
>>> +	struct nau7802_state *st = iio_priv(idev);
>>> +	int ret;
>>> +
>>> +	INIT_COMPLETION(st->value_ok);
>> So let me see if I have this correct.
>>> +	enable_irq(st->client->irq);
>> This will probably fire immediately as it is a level irq and we have had
>> it masked.
>
> It fires almost immediately. But like I said, on my setup the pca
> doesn't seem to reliably call the interrupt handler at hte correct time.
> Also, sometimes, as it is an interrupt thread, it may actually be
> scheduled a bit later.
>>> +
>>> +	nau7802_sync(st);
>> This flushes the device?
>>> +
>>> +	/* read registers to ensure we flush everything */
>>> +	ret = nau7802_read_conversion(st);
>>> +	if (ret)
>>> +		goto read_chan_info_failure;
>>> +
>> This then ensures we have scrubbed any left over data?  Might scrub
>> some extra but that isn't a problem...
>
> We have to read the 3 output registers to be sure we shift out the
> previous conversion result. It is also supposed to ensure we will get an
> interrupt.
>
>>> +	/* Wait for a conversion to finish */
>>> +	ret = wait_for_completion_interruptible_timeout(&st->value_ok,
>>> +			msecs_to_jiffies(1000));
>> This will fire next time we have new data?
>
> Yeah, we are actually waiting for a minimum number of conversions to
> happen when switching channels because there is actually only one ADC
> for the 2 channels. When the value are far apart, we have to wait for
> some conversions to happen before we get a significant value. Maybe I
> can add a comment for that too ?
Yup, as this stuff is all a little unusual it makes sense to have some
explanatory comments.
>> +	case IIO_CHAN_INFO_SCALE:
>> +		ret = nau7802_i2c_read(st, NAU7802_REG_CTRL1, &data);
>> +		if (ret < 0)
>> +			return ret;
>> +
>> +		*val = 0;
>> +		*val2 = (((u64)st->vref_mv) * 1000000000ULL) >>
>> +			(chan->scan_type.realbits +
>> +			 (data & NAU7802_CTRL1_GAINS_BITS));
>> It's saturday morning and I'm half asleep so I'll take your word for
>> this being the nicest way of computing this. However with a 23 bit
>> adc measuring around 5V? I would have thought to get a decent number
>> of significant figures you'd want to do IIO_VAL_INT_PLUS_NANO?
>
> Sure, will do. It actually took me quite some time to get it right and
> then I forgot to switch to IIO_VAL_INT_PLUS_NANO.
>
>>> +		return IIO_VAL_INT_PLUS_MICRO;
>>> +	default:
>>> +		break;
>>> +	}
>>> +	return -EINVAL;
>>> +}
>>> +
>>> +static const struct iio_info nau7802_info = {
>>> +	.driver_module = THIS_MODULE,
>>> +	.read_raw = &nau7802_read_raw,
>>> +	.attrs = &nau7802_attribute_group,
>>> +};
>>> +
>>> +static int nau7802_channel_init(struct iio_dev *idev)
>>> +{
>>> +	struct iio_chan_spec *chan_array;
>>> +	int i;
>>> +
>>> +	idev->num_channels = 2;
>>> +
>>> +	chan_array = devm_kzalloc(&idev->dev,
>>> +				  sizeof(*chan_array) * idev->num_channels,
>>> +				  GFP_KERNEL);
>>> +
>> There are only two of them and that is pretty much fixed.  Do this with
>> a const static array rather than dynamically. If you really want the
>> flexibility on number of channels, then just set idev->num_channels
>> appropriately and it'll ignore later entries in the table.
>>
>> Dynamic allocation only makes sense where we have a huge and complex
>> set of possible channel combinations.
>
> Ok, we only have 2 channels anyway.
>
>>> +	for (i = 0; i < idev->num_channels; i++) {
>>> +		struct iio_chan_spec *chan = chan_array + i;
>>> +
>>> +		chan->type = IIO_VOLTAGE;
>>> +		chan->indexed = 1;
>>> +		chan->channel = i;
>>> +		chan->scan_index = i;
>>> +		chan->scan_type.sign = 's';
>>> +		chan->scan_type.realbits = 23;
>> As I read it this part is a 24bit adc where they are committing to 23bits of good
>> precision. As such realbits should be 24.
>> Not that it's used for anything unless you are doing buffering!
>> (so feel free to drop the scan_index and san_type entirely.
>>> +		chan->scan_type.storagebits = 24;
>>> +		chan->info_mask = IIO_CHAN_INFO_SCALE_SHARED_BIT |
>>> +			IIO_CHAN_INFO_RAW_SEPARATE_BIT;
>> This has changed, take a look at the latest staging-next.
>
> I'll have a look.
>
>>> +	}
>>> +	idev->channels = chan_array;
>>> +
>>> +	return idev->num_channels;
>>> +}
>>> +
>>> +static int nau7802_probe(struct i2c_client *client,
>>> +			const struct i2c_device_id *id)
>>> +{
>>> +	struct iio_dev *idev;
>>> +	struct nau7802_state *st;
>>> +	struct device_node *np = client->dev.of_node;
>>> +	int ret;
>>> +	u8 data;
>>> +	u32 tmp;
>>> +
>>> +	if (!client->dev.of_node) {
>>> +		dev_err(&client->dev, "No device tree node available.\n");
>>> +		return -EINVAL;
>>> +	}
>>> +
>>> +	/*
>>> +	 * If we have some interrupts declared, use them, if not, fall back
>>> +	 * on polling.
>>> +	 */
>>> +	if (of_find_property(np, "interrupts", NULL)) {
>>> +		if (client->irq <= 0) {
>>> +			client->irq = irq_of_parse_and_map(np, 0);
>>> +			if (client->irq <= 0)
>>> +				return -EPROBE_DEFER;
>>> +		}
>>> +	} else
>>> +		client->irq = 0;
>>> +
>>> +	idev = iio_device_alloc(sizeof(struct nau7802_state));
>> sizeof(*st) is a little cleaner.
>> Also we have pretty much standardized on calling the iio_dev
>> indio_dev (no idea why but it's how it turned out ;)  Whilst
>> it doesn't really matter it does make reviewers jobs marginally
>> easier ;)
>
> OK
>>> +	if (idev == NULL)
>>> +		return -ENOMEM;
>>> +
>>> +	st = iio_priv(idev);
>>> +
>>> +	i2c_set_clientdata(client, idev);
>>> +
>>> +	idev->dev.parent = &client->dev;
>>> +	idev->name = dev_name(&client->dev);
>>> +	idev->modes = INDIO_DIRECT_MODE;
>>> +	idev->info = &nau7802_info;
>>> +
>>> +	st->client = client;
>>> +
>>> +	/* Reset the device */
>>> +	nau7802_i2c_write(st, NAU7802_REG_PUCTRL, NAU7802_PUCTRL_RR_BIT);
>>> +
>>> +	/* Enter normal operation mode */
>>> +	nau7802_i2c_write(st, NAU7802_REG_PUCTRL, NAU7802_PUCTRL_PUD_BIT);
>>> +
>>> +	/*
>>> +	 * After about 200 usecs, the device should be ready and then
>>> +	 * the Power Up bit will be set to 1. If not, wait for it.
>>> +	 */
>>> +	do {
>>> +		udelay(200);
>>> +		ret = nau7802_i2c_read(st, NAU7802_REG_PUCTRL, &data);
>>> +		if (ret)
>>> +			return -ENODEV;
>> You want some sort of timeout and fail here.  Perasonally if the device
>> should be ready in 200 usec, I'd only let it have one go at doing so
>> before failing (or give 250 usec if it's not all that precise).
> Right.
>>> +	} while (!(data & NAU7802_PUCTRL_PUR_BIT));
>>> +
>>> +	of_property_read_u32(np, "nuvoton,vldo", &tmp);
>>> +	st->vref_mv = tmp;
>>> +
>>> +	data = NAU7802_PUCTRL_PUD_BIT | NAU7802_PUCTRL_PUA_BIT |
>>> +		NAU7802_PUCTRL_CS_BIT;
>>> +	if (tmp >= 2400)
>>> +		data |= NAU7802_PUCTRL_AVDDS_BIT;
>>> +
>>> +	nau7802_i2c_write(st, NAU7802_REG_PUCTRL, data);
>>> +	nau7802_i2c_write(st, NAU7802_REG_ADC_CTRL, 0x30);
>>> +
>>> +	if (tmp >= 2400) {
>>> +		data = NAU7802_CTRL1_VLDO((4500 - tmp) / 300);
>>> +		nau7802_i2c_write(st, NAU7802_REG_CTRL1, data);
>>> +	}
>>> +
>>> +	st->min_conversions = 6;
>>> +
>>> +	/*
>>> +	 * The ADC fires continuously and we can't do anything about
>>> +	 * it. So we need to have the IRQ disabled by default, and we
>>> +	 * will enable them back when we will need them..
>>> +	 */
>>> +	if (client->irq) {
>>> +		irq_set_status_flags(client->irq, IRQ_NOAUTOEN);
>>> +		ret = request_threaded_irq(client->irq,
>>> +				NULL,
>>> +				nau7802_eoc_trigger,
>>> +				IRQF_TRIGGER_HIGH | IRQF_ONESHOT,
>>> +				client->dev.driver->name,
>>> +				idev);
>>> +		if (ret) {
>>> +			/*
>>> +			 * What may happen here is that our IRQ controller is
>>> +			 * not able to get level interrupt but this is required
>>> +			 * by this ADC as when going over 40 sample per second,
>>> +			 * the interrupt line may stay high between conversions.
>>> +			 * So, we continue no matter what but we switch to
>>> +			 * polling mode.
>>> +			 */
>> Good plan.  Pesky hardware designers and not guaranteeing transitions. ;)
>
> Yeah, I'll still have to check whether it is an issue with the pca or
> the nau. I actually suspect both ;)
> But anyway, as we are able to poll, I think it is still a good idea to
> choose polling when your interrupt controller is not able to handle your
> interrupt type.
Agreed though I'd hope that the device tree writer would know the 
interrupt controller isn't capable of what is happening and never 
provide the interrupt in the first place - ideally the hardware designer
would have noticed and never connected it :)
>
>>> +			dev_info(&client->dev,
>>> +				"Failed to allocate IRQ, using polling mode\n");
>>> +			client->irq = 0;
>>> +			/*
>>> +			 * We are polling, use the fastest sample rate by
>>> +			 * default
>>> +			 */
>>> +			st->sample_rate = 0x7;
>>> +			nau7802_i2c_write(st, NAU7802_REG_CTRL2,
>>> +					NAU7802_CTRL2_CRS(st->sample_rate));
>>> +		}
>>> +	}
>>> +
>>> +	/* Setup the ADC channels available on the board */
>>> +	ret = nau7802_channel_init(idev);
>>> +	if (ret < 0) {
>>> +		dev_err(&client->dev, "Couldn't initialize the channels.\n");
>>> +		goto error_channel_init;
>>> +	}
>>> +
>>> +	init_completion(&st->value_ok);
>>> +	mutex_init(&st->lock);
>>> +	mutex_init(&st->data_lock);
>>> +
>>> +	ret = iio_device_register(idev);
>>> +	if (ret < 0) {
>>> +		dev_err(&client->dev, "Couldn't register the device.\n");
>>> +		goto error_device_register;
>>> +	}
>>> +
>>> +	return 0;
>>> +
>>> +error_device_register:
>>> +	mutex_destroy(&st->lock);
>> datalock?
> oops
>
> Thanks again for your review, I'll prepare a v2 while waiting for your
> answers.
>
Cool, plenty of time.

Jonathan



From w at 1wt.eu  Mon Apr 22 05:08:03 2013
From: w at 1wt.eu (Willy Tarreau)
Date: Mon, 22 Apr 2013 11:08:03 +0200
Subject: MVEBU and MVNETA driver
In-Reply-To: <5174F29D.5070908@itooo.com>
References: <5171419C.2090003@itooo.com> <20130419131237.GC22440@1wt.eu>
 <517150FF.9010806@itooo.com> <20130419144324.GD22440@1wt.eu>
 <51715BC7.3040906@free-electrons.com> <51716A8B.9080903@itooo.com>
 <20130422062024.GK30850@1wt.eu> <5174F29D.5070908@itooo.com>
Message-ID: <20130422090803.GA3715@1wt.eu>

On Mon, Apr 22, 2013 at 10:19:41AM +0200, Greg wrote:
> I'm using SLAB allocator.
> As for offloading, I can't seem to be able to turn it on :
> >$ ethtool -K eth0 gro on
> >Cannot set device GRO settings: Operation not supported
> >$ ethtool -K eth0 gso on
> >Cannot set device generic segmentation offload settings: Operation not 
> >supported
> Default values :
> >$ ethtool -k eth0
> >Offload parameters for eth0:
> >rx-checksumming: off
> >tx-checksumming: on
> >scatter-gather: on
> >tcp-segmentation-offload: off
> >udp-fragmentation-offload: off
> >generic-segmentation-offload: off
> >generic-receive-offload: off
> >large-receive-offload: off
> >rx-vlan-offload: off
> >tx-vlan-offload: off
> >ntuple-filters: off
> >receive-hashing: off
> 
> I can see 1 difference between our setups, Mirabox has an Armada370, I 
> have an ArmadaXP, it would be interesting to know what Gregory is using.

OK so I guess you have a kernel version prior to 3.9-rc7. There is a bug
in the driver which causes it to report tx cksum and sg but they're not
enabled. You need to disable then enable them :

  ethtool -K eth0 tx off
  ethtool -K eth0 sg off
  ethtool -K eth0 tx on
  ethtool -K eth0 sg on

Then you can enable gso/gro. And that clearly explains a significant
performance difference.

> Another difference on my setup, and something I wanted to report you : 
> there is no PHY on my system. I had to instantiate a dummy PHY in the 
> device tree blob and bind it to the mvneta driver because it would fail 
> at init without PHY.

I think this is more something for Thomas then.

Regards,
Willy



From tomi.valkeinen at ti.com  Mon Apr 22 05:08:38 2013
From: tomi.valkeinen at ti.com (Tomi Valkeinen)
Date: Mon, 22 Apr 2013 12:08:38 +0300
Subject: Multiple issues with omap4 panda es in linux next
In-Reply-To: <20130419171318.GK10155@atomide.com>
References: <20130419171318.GK10155@atomide.com>
Message-ID: <5174FE16.6080307@ti.com>

On 2013-04-19 20:13, Tony Lindgren wrote:

> 3. DSS fails with DT booting
> 
> Works with legacy booting but fails with DT. I'm almost certain
> the DT booting was working last week or so?
> 
> This is what I now get with DT booting:
> 
> omapdss DSI error: can't get VDDS_DSI regulator
> omapdss HDMI error: can't get VDDA_HDMI_DAC regulator
> omapdss HDMI error: device hdmi init failed: -517
> omapdss CORE error: driver probe failed: -22
> ...

I think this is the issue Christoph Fritz reported earlier, DSS is being
initialized before TWL, and thus DSS doesn't find the regulators.

The proper fix is of course to make DSS support EPROBE_DEFER, but that's
easier said than done. I'll have a look if I can get it working enough
to fix this issue.

 Tomi


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130422/88930a19/attachment-0001.sig>

From nicolas.ferre at atmel.com  Mon Apr 22 05:09:25 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Mon, 22 Apr 2013 11:09:25 +0200
Subject: [GIT PULL] at91: soc for 3.10 #4
Message-ID: <1366621765-31315-1-git-send-email-nicolas.ferre@atmel.com>

Arnd, Olof,

Another (late) round of SoC patches for 3.10 (or, of course 3.11). I would
totally understand if you delay this series to 3.11 as the merge window is
opening in one week.

I decided to sent this pull-request to you because it deals with the common
slave DMA bindings for AT91 SoCs. It is a long-awaited feature and it can be
interesting to see it merged as soon as possible.

The last patch is not related to DMA bindings but is pretty trivial.

Tell me what you think about this...
Thanks, best regards,

The following changes since commit f5fa4098c3fcc0e504fbc0682dccd331dbbcf197:

  ARM: at91: suspend both memory controllers on at91sam9263 (2013-04-18 16:31:02 +0200)

are available in the git repository at:

  git://github.com/at91linux/linux-at91.git tags/at91-soc

for you to fetch changes up to a6268b86483ba91c9df3e278bbc82d665d781d9e:

  ARM: at91/sama5d34ek.dts: remove not needed compatibility string (2013-04-19 11:38:05 +0200)

----------------------------------------------------------------
DT modifications for generic slave DMA binding.
Addition of MCI and I2C DMA bindings.
A little DT machine compatibility removal for SAMA5.

----------------------------------------------------------------
Ludovic Desroches (3):
      ARM: at91: dts: set #dma-cells to the correct value
      ARM: at91: dts: add i2c dma support
      ARM: at91: dts: add MCI DMA support

Nicolas Ferre (1):
      ARM: at91/sama5d34ek.dts: remove not needed compatibility string

 arch/arm/boot/dts/at91sam9g45.dtsi |  5 +++++
 arch/arm/boot/dts/at91sam9n12.dtsi |  9 +++++++++
 arch/arm/boot/dts/at91sam9x5.dtsi  | 15 +++++++++++++++
 arch/arm/boot/dts/sama5d3.dtsi     | 19 +++++++++++++++++--
 arch/arm/boot/dts/sama5d34ek.dts   |  2 +-
 5 files changed, 47 insertions(+), 3 deletions(-)

-- 
Nicolas Ferre


From jbe at pengutronix.de  Mon Apr 22 05:08:16 2013
From: jbe at pengutronix.de (Juergen Beisert)
Date: Mon, 22 Apr 2013 11:08:16 +0200
Subject: [PATCH RESEND] video: mxsfb: Fix colors display on lower color
 depth
In-Reply-To: <1366618310-7068-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1366618310-7068-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <201304221108.17339.jbe@pengutronix.de>

Hi Maxime,

Maxime Ripard wrote:
> The current code always registers as a 32 bits display, and uses the
> hardware to drop the MSB of each color to abjust to the interface width
> used by the panel.
>
> This results on 18 bits (and probably 16 bits display as well) in colors
> being displayed poorly, because the MSB are obviously the most important
> bits for each color definition.

But the "def_rgb666" bitfield description reports correctly to use bit 0..5 
for each colour component in this mode. Maybe your userland program has a bug 
and forgets to honor the bitfield description?

> The default controller behaviour when using an interface width smaller
> than the color depth is to drop the LSBs of each color, which makes more
> sense because you lose the least important part of the color definition.
>
> So, to fix the colors display, just get back to the default controller
> behaviour.

If you do this change, you also must adapt the "def_rgb666" bitfield 
description.
This structure currently reports the lower 6 bits to be used for this mode:
  blue -> 0..5 (skip 6/7)
  green -> 8..13 (skip 14/15)
  red -> 16..21 (skip 22/23).

> [...]

jbe

-- 
Pengutronix e.K.                              | Juergen Beisert             |
Linux Solutions for Science and Industry      | http://www.pengutronix.de/  |


From marex at denx.de  Mon Apr 22 05:16:17 2013
From: marex at denx.de (Marek Vasut)
Date: Mon, 22 Apr 2013 11:16:17 +0200
Subject: [PATCH RESEND] video: mxsfb: Fix colors display on lower color
 depth
In-Reply-To: <1366618310-7068-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1366618310-7068-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <201304221116.18080.marex@denx.de>

Dear Maxime Ripard,

> The current code always registers as a 32 bits display, and uses the
> hardware to drop the MSB of each color to abjust to the interface width
> used by the panel.
> 
> This results on 18 bits (and probably 16 bits display as well) in colors
> being displayed poorly, because the MSB are obviously the most important
> bits for each color definition.
> 
> The default controller behaviour when using an interface width smaller
> than the color depth is to drop the LSBs of each color, which makes more
> sense because you lose the least important part of the color definition.
> 
> So, to fix the colors display, just get back to the default controller
> behaviour.
> 
> Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>

Did you receive my latest email? Check M28EVK (imx28-m28evk.dts), it uses 18bit 
LCD and works without this patch I think.

Best regards,
Marek Vasut


From rusty at rustcorp.com.au  Mon Apr 22 01:15:48 2013
From: rusty at rustcorp.com.au (Rusty Russell)
Date: Mon, 22 Apr 2013 14:45:48 +0930
Subject: [RFC] arm64: Early printk support for virtio-mmio console devices.
In-Reply-To: <CALrVBkub+TABrrBwh4+P6S5TGL1qSmnZrd1cbGgj6JiRpY=rOA@mail.gmail.com>
References: <1366264344-28025-1-git-send-email-pranavkumar@linaro.org>
 <87wqs02uws.fsf@rustcorp.com.au>
 <CAAHg+HiHKV+8hBT1QWe4hSxocCX6wpRd3bCPWB7zU8jVFmPuAA@mail.gmail.com>
 <87ehe3bbsm.fsf@rustcorp.com.au>
 <CALrVBkub+TABrrBwh4+P6S5TGL1qSmnZrd1cbGgj6JiRpY=rOA@mail.gmail.com>
Message-ID: <87mwsr9md7.fsf@rustcorp.com.au>

Anup Patel <anup.patel at linaro.org> writes:
> On 22 April 2013 06:51, Rusty Russell <rusty at rustcorp.com.au> wrote:
>>
>> Pranavkumar Sawargaonkar <pranavkumar at linaro.org> writes:
>> > On 18 April 2013 12:21, Rusty Russell <rusty at rustcorp.com.au> wrote:
>> >>
>> >> PranavkumarSawargaonkar <pranavkumar at linaro.org> writes:
>> >> > From: Pranavkumar Sawargaonkar <pranavkumar at linaro.org>
>> >> >
>> >> > This patch implements early printk support for virtio-mmio console
>> >> > devices without using any hypercalls.
>> >>
>> >> This makes some sense, though not sure that early console *read* makes
>> >> much sense.  I can see the PCI version of this being useful as well.
>> >
>> > Read can be useful for "mach-virt" which will have only virtio console
>> > as a console device. Then if someone wants to have UEFI or any other
>> > boot-loader emulation, which expects user to input few things, in that
>> > case read might become handy.
>>
>> But implementing virtio inside a bootloader has already been done for
>> coreboot, for example.  A bootloader probably wants a virtio block
>> device, so a console is trivial.
>>
>> A single writable field for debugging makes sense.  Anything more is far
>> less certain.
>
> The early read can be handy for bootloader who don't want to implement
> complete VirtIO programming.

I've said this twice already.  This is the last time.

1) We do not add complexity unless we have to.
2) Making it optional does not make it significantly less complex.
3) Having two ways of doing the same thing is always ugly.
4) Having an emergency output method makes sense for several use cases,
   an emergency input method does not.
5) A bootloader which uses virtio to get the images to boot can
   implement a console in less than 10 lines.
6) A bootloader which does not use any virtio devices but nonetheless
   wants to obtain input can implement a simple console in well under 100
   lines.  See below.

Finally, in case you still don't understand:

My task is to make this decision, and I've made it.  Arguing with me is
only useful if you bring new facts which you can change my mind.

Hope that clarifies,
Rusty.

#define VIRTIO_MMIO_GUEST_PAGE_SIZE	0x028
#define VIRTIO_MMIO_QUEUE_SEL		0x030
#define VIRTIO_MMIO_QUEUE_NUM_MAX	0x034
#define VIRTIO_MMIO_QUEUE_NUM		0x038
#define VIRTIO_MMIO_QUEUE_ALIGN		0x03c
#define VIRTIO_MMIO_QUEUE_PFN		0x040
#define VIRTIO_MMIO_QUEUE_NOTIFY	0x050

struct vring_desc {
	__u64 addr;
	__u32 len;
	__u16 flags;
	__u16 next;
};

struct vring_used_elem {
	__u32 id;
	__u32 len;
};

struct vconsole_ring {
        struct vring_desc desc[2];
	__u16 avail_flags;
	__u16 avail_idx;
	__u16 available[2];
	__u16 used_event_idx;
	__u16 pad; /* Hit 4-byte boundary */

	// A ring of used descriptor heads with free-running index.
	__u16 used_flags;
	__u16 used_idx;
	struct vring_used_elem used[2];
	__u16 avail_event_idx;
};

static char console_in;
static struct vconsole_ring vc_ring = {
        { { PHYSICAL_ADDR(console_in), 1, 2, 0 } },
        1, /* No interrupts */
}

static void post_buffer(void *base)
{
        vc_ring->avail_idx++;
        wmb();
        writel(0, base + VIRTIO_MMIO_QUEUE_NOTIFY);
}

bool vc_read(void *base, char *c)
{
        mb();
        if (vc_ring->used_idx != vc_ring->avail_idx)
                return false;
        *c = console_in;
        post_buffer(base);
        return true;
}

void vc_init(void *base)
{
        /* Alignment of 4 bytes, don't waste any. */
	writel(4, base + VIRTIO_MMIO_GUEST_PAGE_SIZE);

        /* Setup incoming vq. */
	writel(0, base + VIRTIO_MMIO_QUEUE_SEL);

        /* 2 elements */
	writel(2, base + VIRTIO_MMIO_QUEUE_NUM);
        /* Alignment of 4 bytes */
	writel(4, base + VIRTIO_MMIO_QUEUE_ALIGN);
        /* Location of queue. */
	writel(PHYSICAL_ADDR(&vc_ring) >> 4, base + VIRTIO_MMIO_QUEUE_PFN);

        post_buffer(base);
}


From itooo at itooo.com  Mon Apr 22 05:40:57 2013
From: itooo at itooo.com (Greg)
Date: Mon, 22 Apr 2013 11:40:57 +0200
Subject: MVEBU and MVNETA driver
In-Reply-To: <20130422090803.GA3715@1wt.eu>
References: <5171419C.2090003@itooo.com> <20130419131237.GC22440@1wt.eu>
 <517150FF.9010806@itooo.com> <20130419144324.GD22440@1wt.eu>
 <51715BC7.3040906@free-electrons.com> <51716A8B.9080903@itooo.com>
 <20130422062024.GK30850@1wt.eu> <5174F29D.5070908@itooo.com>
 <20130422090803.GA3715@1wt.eu>
Message-ID: <517505A9.20600@itooo.com>

Le 22/04/2013 11:08, Willy Tarreau a ?crit :
> On Mon, Apr 22, 2013 at 10:19:41AM +0200, Greg wrote:
>> I'm using SLAB allocator.
>> As for offloading, I can't seem to be able to turn it on :
>>> $ ethtool -K eth0 gro on
>>> Cannot set device GRO settings: Operation not supported
>>> $ ethtool -K eth0 gso on
>>> Cannot set device generic segmentation offload settings: Operation not
>>> supported
>> Default values :
>>> $ ethtool -k eth0
>>> Offload parameters for eth0:
>>> rx-checksumming: off
>>> tx-checksumming: on
>>> scatter-gather: on
>>> tcp-segmentation-offload: off
>>> udp-fragmentation-offload: off
>>> generic-segmentation-offload: off
>>> generic-receive-offload: off
>>> large-receive-offload: off
>>> rx-vlan-offload: off
>>> tx-vlan-offload: off
>>> ntuple-filters: off
>>> receive-hashing: off
>> I can see 1 difference between our setups, Mirabox has an Armada370, I
>> have an ArmadaXP, it would be interesting to know what Gregory is using.
> OK so I guess you have a kernel version prior to 3.9-rc7. There is a bug
> in the driver which causes it to report tx cksum and sg but they're not
> enabled. You need to disable then enable them :
>
>    ethtool -K eth0 tx off
>    ethtool -K eth0 sg off
>    ethtool -K eth0 tx on
>    ethtool -K eth0 sg on
>
> Then you can enable gso/gro. And that clearly explains a significant
> performance difference.
Yes, as explain in my original mail, I'm using 3.8.8
I followed your recommendations and performance is now ~930-940Mbits in 
both directions which is fine.
Thanks !
>> Another difference on my setup, and something I wanted to report you :
>> there is no PHY on my system. I had to instantiate a dummy PHY in the
>> device tree blob and bind it to the mvneta driver because it would fail
>> at init without PHY.
> I think this is more something for Thomas then.
>
The "failure" is located in mvneta_mdio_probe but I guess this is more 
like an architectural problem.
The MVNETA driver assumes a PHY is present, but this is not a 
requirement to establish link between 2 MACs.
I guess using a dummy PHY is a not-so-bad idea for my situation at this 
time.

Regards,


From nicolas.ferre at atmel.com  Mon Apr 22 05:49:01 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Mon, 22 Apr 2013 11:49:01 +0200
Subject: [GIT PULL] at91: DT changes for 3.11 #1 (or 3.10 #4)
Message-ID: <1366624141-32477-1-git-send-email-nicolas.ferre@atmel.com>

Arnd, Olof,

This is an early AT91 Device Tree pull-request for 3.11 (or late for 3.10 ;-)).
Feel free to take it now, delay it or simply tell me to re-send this
pull-request later! I do not want to bother you with these patches as they
certainly can wait and are pretty simple and harmless.

They should be stacked on top of arm-soc/at91/dt3 and are merging seamlessly
with other at91 branches.

Thanks, best regards,

The following changes since commit f10491fff07dcced77f8ab1b3bc1f8e18715bfb9:

  ARM: at91/at91sam9260.dtsi: fix u(s)art pinctrl encoding (2013-04-04 18:31:17 +0200)

are available in the git repository at:

  git://github.com/at91linux/linux-at91.git tags/at91-dt

for you to fetch changes up to 2e6faf10411968706cf42a62729dccfc57230115:

  ARM: at91: add Acme Systems Fox G20 board (2013-04-19 12:38:26 +0200)

----------------------------------------------------------------
RTC modification and USART addition for at91sam9x5 SoC.
RTC addition and UART modifications for Aria G25 board.
Addition of Acme Systems Fox G20 board.

----------------------------------------------------------------
Douglas Gilbert (1):
      ARM: at91: add Acme Systems Fox G20 board

Nicolas Ferre (4):
      ARM: at91: at91sam9x5 RTC is not compatible with at91rm9200 one
      ARM: at91/at91-ariag25.dts: add RTC node
      ARM: at91/at91sam9x5.dtsi: add UART0/1 nodes
      ARM: at91/at91-ariag25.dts: UART0/1 nodes are disabled

 arch/arm/boot/dts/Makefile         |   1 +
 arch/arm/boot/dts/at91-ariag25.dts |  21 +++--
 arch/arm/boot/dts/at91-foxg20.dts  | 157 +++++++++++++++++++++++++++++++++++
 arch/arm/boot/dts/at91sam9x5.dtsi  |  20 ++++-
 4 files changed, 192 insertions(+), 7 deletions(-)
 create mode 100644 arch/arm/boot/dts/at91-foxg20.dts

-- 
Nicolas Ferre


From linus.walleij at stericsson.com  Mon Apr 22 05:51:23 2013
From: linus.walleij at stericsson.com (Linus Walleij)
Date: Mon, 22 Apr 2013 11:51:23 +0200
Subject: [PATCH 01/23] ARM: u300: fix ages old copy/paste bug
Message-ID: <1366624283-6122-1-git-send-email-linus.walleij@stericsson.com>

From: Linus Walleij <linus.walleij at linaro.org>

The UART1 is on the fast AHB bridge, not on the slow bus.

Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 arch/arm/mach-u300/include/mach/u300-regs.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-u300/include/mach/u300-regs.h b/arch/arm/mach-u300/include/mach/u300-regs.h
index 1e49d90..0320495 100644
--- a/arch/arm/mach-u300/include/mach/u300-regs.h
+++ b/arch/arm/mach-u300/include/mach/u300-regs.h
@@ -95,7 +95,7 @@
 #define U300_SPI_BASE			(U300_FAST_PER_PHYS_BASE+0x6000)
 
 /* Fast UART1 on U335 only */
-#define U300_UART1_BASE			(U300_SLOW_PER_PHYS_BASE+0x7000)
+#define U300_UART1_BASE			(U300_FAST_PER_PHYS_BASE+0x7000)
 
 /*
  * SLOW peripherals
-- 
1.7.11.3



From linus.walleij at stericsson.com  Mon Apr 22 05:51:53 2013
From: linus.walleij at stericsson.com (Linus Walleij)
Date: Mon, 22 Apr 2013 11:51:53 +0200
Subject: [PATCH 04/23] pinctrl: u300 device tree support
Message-ID: <1366624313-6225-1-git-send-email-linus.walleij@stericsson.com>

From: Linus Walleij <linus.walleij at linaro.org>

This adds a simple device tree compat string for the U300 pin
controller. The base address is already passed properly as
a resource and everything works fine.

Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 drivers/pinctrl/pinctrl-u300.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/pinctrl/pinctrl-u300.c b/drivers/pinctrl/pinctrl-u300.c
index 2b57725..ae0a460 100644
--- a/drivers/pinctrl/pinctrl-u300.c
+++ b/drivers/pinctrl/pinctrl-u300.c
@@ -1105,10 +1105,17 @@ static int u300_pmx_remove(struct platform_device *pdev)
 	return 0;
 }
 
+static const struct of_device_id u300_pinctrl_match[] = {
+	{ .compatible = "stericsson,pinctrl-u300" },
+	{},
+};
+
+
 static struct platform_driver u300_pmx_driver = {
 	.driver = {
 		.name = DRIVER_NAME,
 		.owner = THIS_MODULE,
+		.of_match_table = u300_pinctrl_match,
 	},
 	.probe = u300_pmx_probe,
 	.remove = u300_pmx_remove,
-- 
1.7.11.3



From linus.walleij at stericsson.com  Mon Apr 22 05:51:11 2013
From: linus.walleij at stericsson.com (Linus Walleij)
Date: Mon, 22 Apr 2013 11:51:11 +0200
Subject: [PATCH 00/23] U300 device tree series
Message-ID: <1366624271-6088-1-git-send-email-linus.walleij@stericsson.com>

From: Linus Walleij <linus.walleij at linaro.org>

This converts the U300 machine to use device tree exclusively,
and deletes the static board data and selects USE_OF.

This will be followed by a series for multiplatform, and a
final vacuum-cleaning step removing the non-DT support from
the drivers only used by U300.

But for now let's get the device tree conversion done first.

I'm seeking ACKs from apropriate subsystem maintainers.

Linus Walleij (23):
  ARM: u300: fix ages old copy/paste bug
  ARM: u300: enabled delaytimer on the U300
  ARM: u300: device tree support for the timer
  pinctrl: u300 device tree support
  pinctrl: coh901: add device tree support
  ARM: u300: basic device tree support
  i2c: stu300: device tree support
  ARM: u300: register I2C bus drivers from device tree
  watchdog: coh901327: devicetree support
  ARM: u300: add the COH 901 327 watchdog to device tree
  rtc: coh901331: add devicetree support
  ARM: u300: add RTC to device tree
  regulator: ab3100: refactor probe to use IDs
  regulator: ab3100: device tree support
  ARM: u300: set up board power from device tree
  ARM: u300: support regulators in the device tree
  ARM: u300: enable MMC/SD card from device tree
  dma: coh901318: add devicetree support
  ARM: u300: add the COH 901 318 DMAC to device tree
  ARM: u300: add SPI PL022 to the device tree
  ARM: u300: probe the U300 dummy-spichip from device tree
  ARM: u300: add FSMC flash into the device tree
  ARM: u300: delete all static board data

 Documentation/devicetree/bindings/arm/ste-u300.txt |  22 +
 .../bindings/gpio/gpio-stericsson-coh901.txt       |   9 +
 .../devicetree/bindings/i2c/i2c-st-ddci2c.txt      |  15 +
 .../bindings/timer/stericsson-u300-apptimer.txt    |  18 +
 .../bindings/watchdog/stericsson-coh901327.txt     |  15 +
 arch/arm/Kconfig                                   |   1 +
 arch/arm/boot/dts/Makefile                         |   1 +
 arch/arm/boot/dts/ste-u300.dts                     | 256 +++++++++
 arch/arm/mach-u300/Makefile                        |   2 -
 arch/arm/mach-u300/core.c                          | 573 ++++-----------------
 arch/arm/mach-u300/dummyspichip.c                  |   6 +
 arch/arm/mach-u300/i2c.c                           | 285 ----------
 arch/arm/mach-u300/i2c.h                           |  23 -
 arch/arm/mach-u300/include/mach/u300-regs.h        |   2 +-
 arch/arm/mach-u300/regulator.c                     |  36 +-
 arch/arm/mach-u300/spi.c                           | 102 ----
 arch/arm/mach-u300/spi.h                           |  26 -
 arch/arm/mach-u300/timer.c                         | 106 ++--
 arch/arm/mach-u300/u300-gpio.h                     |  70 ---
 drivers/dma/coh901318.c                            |   5 +
 drivers/i2c/busses/i2c-stu300.c                    |  12 +
 drivers/mfd/ab3100-core.c                          |   1 +
 drivers/pinctrl/pinctrl-coh901.c                   |   9 +
 drivers/pinctrl/pinctrl-u300.c                     |   7 +
 drivers/regulator/ab3100.c                         | 209 ++++++--
 drivers/rtc/rtc-coh901331.c                        |   6 +
 drivers/watchdog/coh901327_wdt.c                   |   6 +
 27 files changed, 763 insertions(+), 1060 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/ste-u300.txt
 create mode 100644 Documentation/devicetree/bindings/gpio/gpio-stericsson-coh901.txt
 create mode 100644 Documentation/devicetree/bindings/i2c/i2c-st-ddci2c.txt
 create mode 100644 Documentation/devicetree/bindings/timer/stericsson-u300-apptimer.txt
 create mode 100644 Documentation/devicetree/bindings/watchdog/stericsson-coh901327.txt
 create mode 100644 arch/arm/boot/dts/ste-u300.dts
 delete mode 100644 arch/arm/mach-u300/i2c.c
 delete mode 100644 arch/arm/mach-u300/i2c.h
 delete mode 100644 arch/arm/mach-u300/spi.c
 delete mode 100644 arch/arm/mach-u300/spi.h
 delete mode 100644 arch/arm/mach-u300/u300-gpio.h

-- 
1.7.11.3



From linus.walleij at stericsson.com  Mon Apr 22 05:51:33 2013
From: linus.walleij at stericsson.com (Linus Walleij)
Date: Mon, 22 Apr 2013 11:51:33 +0200
Subject: [PATCH 02/23] ARM: u300: enabled delaytimer on the U300
Message-ID: <1366624293-6156-1-git-send-email-linus.walleij@stericsson.com>

From: Linus Walleij <linus.walleij at linaro.org>

The U300 can support timer-based delays, so implement this.
Skips past jiffy calibration.

Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 arch/arm/mach-u300/timer.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/mach-u300/timer.c b/arch/arm/mach-u300/timer.c
index d9e7320..c3d3802 100644
--- a/arch/arm/mach-u300/timer.c
+++ b/arch/arm/mach-u300/timer.c
@@ -18,6 +18,7 @@
 #include <linux/clk.h>
 #include <linux/err.h>
 #include <linux/irq.h>
+#include <linux/delay.h>
 
 #include <mach/hardware.h>
 #include <mach/irqs.h>
@@ -345,6 +346,12 @@ static u32 notrace u300_read_sched_clock(void)
 	return readl(U300_TIMER_APP_VBASE + U300_TIMER_APP_GPT2CC);
 }
 
+static unsigned long u300_read_current_timer(void)
+{
+	return readl(U300_TIMER_APP_VBASE + U300_TIMER_APP_GPT2CC);
+}
+
+static struct delay_timer u300_delay_timer;
 
 /*
  * This sets up the system timers, clock source and clock event.
@@ -362,6 +369,10 @@ void __init u300_timer_init(void)
 
 	setup_sched_clock(u300_read_sched_clock, 32, rate);
 
+	u300_delay_timer.read_current_timer = &u300_read_current_timer;
+	u300_delay_timer.freq = rate;
+	register_current_timer_delay(&u300_delay_timer);
+
 	/*
 	 * Disable the "OS" and "DD" timers - these are designed for Symbian!
 	 * Example usage in cnh1601578 cpu subsystem pd_timer_app.c
-- 
1.7.11.3



From linus.walleij at stericsson.com  Mon Apr 22 05:52:06 2013
From: linus.walleij at stericsson.com (Linus Walleij)
Date: Mon, 22 Apr 2013 11:52:06 +0200
Subject: [PATCH 05/23] pinctrl: coh901: add device tree support
Message-ID: <1366624326-6259-1-git-send-email-linus.walleij@stericsson.com>

From: Linus Walleij <linus.walleij at linaro.org>

This makes it possible to probe the COH901 pinctrl driver from
the device tree, and assigned the device tree node in the
gpio_chip so we can look up cross-references from the device
tree.

Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 .../devicetree/bindings/gpio/gpio-stericsson-coh901.txt          | 9 +++++++++
 drivers/pinctrl/pinctrl-coh901.c                                 | 9 +++++++++
 2 files changed, 18 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/gpio/gpio-stericsson-coh901.txt

diff --git a/Documentation/devicetree/bindings/gpio/gpio-stericsson-coh901.txt b/Documentation/devicetree/bindings/gpio/gpio-stericsson-coh901.txt
new file mode 100644
index 0000000..355f8ea
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-stericsson-coh901.txt
@@ -0,0 +1,9 @@
+ST-Ericsson COH 901 571/3 GPIO controller
+
+Required properties:
+- compatible: Compatible property value should be "stericsson,gpio-coh901"
+- reg: Physical base address of the controller and length of memory mapped
+  region.
+- interrupts: the 0...n interrupts assigned to the different GPIO ports/banks.
+- interrupt-names: name the interrupts after port/bank, "gpio0", "gpio1" etc.
+
diff --git a/drivers/pinctrl/pinctrl-coh901.c b/drivers/pinctrl/pinctrl-coh901.c
index 8b7e7bc..bed47ab 100644
--- a/drivers/pinctrl/pinctrl-coh901.c
+++ b/drivers/pinctrl/pinctrl-coh901.c
@@ -808,6 +808,9 @@ static int __init u300_gpio_probe(struct platform_device *pdev)
 	}
 	dev_dbg(gpio->dev, "initialized %d GPIO ports\n", portno);
 
+#ifdef CONFIG_OF_GPIO
+	gpio->chip.of_node = pdev->dev.of_node;
+#endif
 	err = gpiochip_add(&gpio->chip);
 	if (err) {
 		dev_err(gpio->dev, "unable to add gpiochip: %d\n", err);
@@ -861,9 +864,15 @@ static int __exit u300_gpio_remove(struct platform_device *pdev)
 	return 0;
 }
 
+static const struct of_device_id u300_gpio_match[] = {
+	{ .compatible = "stericsson,gpio-coh901" },
+	{},
+};
+
 static struct platform_driver u300_gpio_driver = {
 	.driver		= {
 		.name	= "u300-gpio",
+		.of_match_table = u300_gpio_match,
 	},
 	.remove		= __exit_p(u300_gpio_remove),
 };
-- 
1.7.11.3



From linus.walleij at stericsson.com  Mon Apr 22 05:51:44 2013
From: linus.walleij at stericsson.com (Linus Walleij)
Date: Mon, 22 Apr 2013 11:51:44 +0200
Subject: [PATCH 03/23] ARM: u300: device tree support for the timer
Message-ID: <1366624304-6190-1-git-send-email-linus.walleij@stericsson.com>

From: Linus Walleij <linus.walleij at linaro.org>

This adds device tree support for the U300 timer, by making
the memory base offset and IRQ dynamically assigned, then
optionally looking them up from the device tree.

Since the timer needs to be registered before any platform
devices are created, we will go into the device tree and look
up the "/timer at c0014000" node and read our base address and
IRQ from there.

Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 .../bindings/timer/stericsson-u300-apptimer.txt    | 18 ++++
 arch/arm/mach-u300/timer.c                         | 99 ++++++++++++++--------
 2 files changed, 80 insertions(+), 37 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/timer/stericsson-u300-apptimer.txt

diff --git a/Documentation/devicetree/bindings/timer/stericsson-u300-apptimer.txt b/Documentation/devicetree/bindings/timer/stericsson-u300-apptimer.txt
new file mode 100644
index 0000000..9499bc8
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/stericsson-u300-apptimer.txt
@@ -0,0 +1,18 @@
+ST-Ericsson U300 apptimer
+
+Required properties:
+
+- compatible : should be "stericsson,u300-apptimer"
+- reg : Specifies base physical address and size of the registers.
+- interrupts : A list of 4 interrupts; one for each subtimer. These
+  are, in order: OS (operating system), DD (device driver) both
+  adopted for EPOC/Symbian with two specific IRQs for these tasks,
+  then GP1 and GP2, which are general-purpose timers.
+
+Example:
+
+timer {
+	compatible = "stericsson,u300-apptimer";
+	reg = <0xc0014000 0x1000>;
+	interrupts = <24 25 26 27>;
+};
diff --git a/arch/arm/mach-u300/timer.c b/arch/arm/mach-u300/timer.c
index c3d3802..5e60a5e 100644
--- a/arch/arm/mach-u300/timer.c
+++ b/arch/arm/mach-u300/timer.c
@@ -19,6 +19,8 @@
 #include <linux/err.h>
 #include <linux/irq.h>
 #include <linux/delay.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
 
 #include <mach/hardware.h>
 #include <mach/irqs.h>
@@ -190,6 +192,8 @@
 #define TICKS_PER_JIFFY ((CLOCK_TICK_RATE + (HZ/2)) / HZ)
 #define US_PER_TICK ((1000000 + (HZ/2)) / HZ)
 
+static void __iomem *u300_timer_base;
+
 /*
  * The u300_set_mode() function is always called first, if we
  * have oneshot timer active, the oneshot scheduling function
@@ -202,28 +206,28 @@ static void u300_set_mode(enum clock_event_mode mode,
 	case CLOCK_EVT_MODE_PERIODIC:
 		/* Disable interrupts on GPT1 */
 		writel(U300_TIMER_APP_GPT1IE_IRQ_DISABLE,
-		       U300_TIMER_APP_VBASE + U300_TIMER_APP_GPT1IE);
+		       u300_timer_base + U300_TIMER_APP_GPT1IE);
 		/* Disable GP1 while we're reprogramming it. */
 		writel(U300_TIMER_APP_DGPT1_TIMER_DISABLE,
-		       U300_TIMER_APP_VBASE + U300_TIMER_APP_DGPT1);
+		       u300_timer_base + U300_TIMER_APP_DGPT1);
 		/*
 		 * Set the periodic mode to a certain number of ticks per
 		 * jiffy.
 		 */
 		writel(TICKS_PER_JIFFY,
-		       U300_TIMER_APP_VBASE + U300_TIMER_APP_GPT1TC);
+		       u300_timer_base + U300_TIMER_APP_GPT1TC);
 		/*
 		 * Set continuous mode, so the timer keeps triggering
 		 * interrupts.
 		 */
 		writel(U300_TIMER_APP_SGPT1M_MODE_CONTINUOUS,
-		       U300_TIMER_APP_VBASE + U300_TIMER_APP_SGPT1M);
+		       u300_timer_base + U300_TIMER_APP_SGPT1M);
 		/* Enable timer interrupts */
 		writel(U300_TIMER_APP_GPT1IE_IRQ_ENABLE,
-		       U300_TIMER_APP_VBASE + U300_TIMER_APP_GPT1IE);
+		       u300_timer_base + U300_TIMER_APP_GPT1IE);
 		/* Then enable the OS timer again */
 		writel(U300_TIMER_APP_EGPT1_TIMER_ENABLE,
-		       U300_TIMER_APP_VBASE + U300_TIMER_APP_EGPT1);
+		       u300_timer_base + U300_TIMER_APP_EGPT1);
 		break;
 	case CLOCK_EVT_MODE_ONESHOT:
 		/* Just break; here? */
@@ -234,33 +238,33 @@ static void u300_set_mode(enum clock_event_mode mode,
 		 */
 		/* Disable interrupts on GPT1 */
 		writel(U300_TIMER_APP_GPT1IE_IRQ_DISABLE,
-		       U300_TIMER_APP_VBASE + U300_TIMER_APP_GPT1IE);
+		       u300_timer_base + U300_TIMER_APP_GPT1IE);
 		/* Disable GP1 while we're reprogramming it. */
 		writel(U300_TIMER_APP_DGPT1_TIMER_DISABLE,
-		       U300_TIMER_APP_VBASE + U300_TIMER_APP_DGPT1);
+		       u300_timer_base + U300_TIMER_APP_DGPT1);
 		/*
 		 * Expire far in the future, u300_set_next_event() will be
 		 * called soon...
 		 */
-		writel(0xFFFFFFFF, U300_TIMER_APP_VBASE + U300_TIMER_APP_GPT1TC);
+		writel(0xFFFFFFFF, u300_timer_base + U300_TIMER_APP_GPT1TC);
 		/* We run one shot per tick here! */
 		writel(U300_TIMER_APP_SGPT1M_MODE_ONE_SHOT,
-		       U300_TIMER_APP_VBASE + U300_TIMER_APP_SGPT1M);
+		       u300_timer_base + U300_TIMER_APP_SGPT1M);
 		/* Enable interrupts for this timer */
 		writel(U300_TIMER_APP_GPT1IE_IRQ_ENABLE,
-		       U300_TIMER_APP_VBASE + U300_TIMER_APP_GPT1IE);
+		       u300_timer_base + U300_TIMER_APP_GPT1IE);
 		/* Enable timer */
 		writel(U300_TIMER_APP_EGPT1_TIMER_ENABLE,
-		       U300_TIMER_APP_VBASE + U300_TIMER_APP_EGPT1);
+		       u300_timer_base + U300_TIMER_APP_EGPT1);
 		break;
 	case CLOCK_EVT_MODE_UNUSED:
 	case CLOCK_EVT_MODE_SHUTDOWN:
 		/* Disable interrupts on GP1 */
 		writel(U300_TIMER_APP_GPT1IE_IRQ_DISABLE,
-		       U300_TIMER_APP_VBASE + U300_TIMER_APP_GPT1IE);
+		       u300_timer_base + U300_TIMER_APP_GPT1IE);
 		/* Disable GP1 */
 		writel(U300_TIMER_APP_DGPT1_TIMER_DISABLE,
-		       U300_TIMER_APP_VBASE + U300_TIMER_APP_DGPT1);
+		       u300_timer_base + U300_TIMER_APP_DGPT1);
 		break;
 	case CLOCK_EVT_MODE_RESUME:
 		/* Ignore this call */
@@ -282,27 +286,27 @@ static int u300_set_next_event(unsigned long cycles,
 {
 	/* Disable interrupts on GPT1 */
 	writel(U300_TIMER_APP_GPT1IE_IRQ_DISABLE,
-	       U300_TIMER_APP_VBASE + U300_TIMER_APP_GPT1IE);
+	       u300_timer_base + U300_TIMER_APP_GPT1IE);
 	/* Disable GP1 while we're reprogramming it. */
 	writel(U300_TIMER_APP_DGPT1_TIMER_DISABLE,
-	       U300_TIMER_APP_VBASE + U300_TIMER_APP_DGPT1);
+	       u300_timer_base + U300_TIMER_APP_DGPT1);
 	/* Reset the General Purpose timer 1. */
 	writel(U300_TIMER_APP_RGPT1_TIMER_RESET,
-	       U300_TIMER_APP_VBASE + U300_TIMER_APP_RGPT1);
+	       u300_timer_base + U300_TIMER_APP_RGPT1);
 	/* IRQ in n * cycles */
-	writel(cycles, U300_TIMER_APP_VBASE + U300_TIMER_APP_GPT1TC);
+	writel(cycles, u300_timer_base + U300_TIMER_APP_GPT1TC);
 	/*
 	 * We run one shot per tick here! (This is necessary to reconfigure,
 	 * the timer will tilt if you don't!)
 	 */
 	writel(U300_TIMER_APP_SGPT1M_MODE_ONE_SHOT,
-	       U300_TIMER_APP_VBASE + U300_TIMER_APP_SGPT1M);
+	       u300_timer_base + U300_TIMER_APP_SGPT1M);
 	/* Enable timer interrupts */
 	writel(U300_TIMER_APP_GPT1IE_IRQ_ENABLE,
-	       U300_TIMER_APP_VBASE + U300_TIMER_APP_GPT1IE);
+	       u300_timer_base + U300_TIMER_APP_GPT1IE);
 	/* Then enable the OS timer again */
 	writel(U300_TIMER_APP_EGPT1_TIMER_ENABLE,
-	       U300_TIMER_APP_VBASE + U300_TIMER_APP_EGPT1);
+	       u300_timer_base + U300_TIMER_APP_EGPT1);
 	return 0;
 }
 
@@ -321,8 +325,9 @@ static irqreturn_t u300_timer_interrupt(int irq, void *dev_id)
 {
 	struct clock_event_device *evt = &clockevent_u300_1mhz;
 	/* ACK/Clear timer IRQ for the APP GPT1 Timer */
+
 	writel(U300_TIMER_APP_GPT1IA_IRQ_ACK,
-		U300_TIMER_APP_VBASE + U300_TIMER_APP_GPT1IA);
+		u300_timer_base + U300_TIMER_APP_GPT1IA);
 	evt->event_handler(evt);
 	return IRQ_HANDLED;
 }
@@ -343,12 +348,12 @@ static struct irqaction u300_timer_irq = {
 
 static u32 notrace u300_read_sched_clock(void)
 {
-	return readl(U300_TIMER_APP_VBASE + U300_TIMER_APP_GPT2CC);
+	return readl(u300_timer_base + U300_TIMER_APP_GPT2CC);
 }
 
 static unsigned long u300_read_current_timer(void)
 {
-	return readl(U300_TIMER_APP_VBASE + U300_TIMER_APP_GPT2CC);
+	return readl(u300_timer_base + U300_TIMER_APP_GPT2CC);
 }
 
 static struct delay_timer u300_delay_timer;
@@ -360,6 +365,26 @@ void __init u300_timer_init(void)
 {
 	struct clk *clk;
 	unsigned long rate;
+	int irq = 0;
+
+#ifdef CONFIG_OF
+	struct device_node *timer = NULL;
+
+	timer = of_find_node_by_path("/timer0 at c0014000");
+	if (timer) {
+		struct resource irq_res;
+
+		u300_timer_base = of_iomap(timer, 0);
+		/* Get the IRQ for the GP1 timer */
+		irq = of_irq_to_resource(timer, 2, &irq_res);
+	}
+#endif
+	/* Fallback to static maps if base & IRQ not found in DT */
+	if (!u300_timer_base)
+		u300_timer_base = U300_TIMER_APP_VBASE;
+	if (irq <= 0)
+		irq = IRQ_U300_TIMER_APP_GP1;
+	pr_info("U300 GP1 timer @ base: %p, IRQ: %d\n", u300_timer_base, irq);
 
 	/* Clock the interrupt controller */
 	clk = clk_get_sys("apptimer", NULL);
@@ -378,40 +403,40 @@ void __init u300_timer_init(void)
 	 * Example usage in cnh1601578 cpu subsystem pd_timer_app.c
 	 */
 	writel(U300_TIMER_APP_CRC_CLOCK_REQUEST_ENABLE,
-		U300_TIMER_APP_VBASE + U300_TIMER_APP_CRC);
+		u300_timer_base + U300_TIMER_APP_CRC);
 	writel(U300_TIMER_APP_ROST_TIMER_RESET,
-		U300_TIMER_APP_VBASE + U300_TIMER_APP_ROST);
+		u300_timer_base + U300_TIMER_APP_ROST);
 	writel(U300_TIMER_APP_DOST_TIMER_DISABLE,
-		U300_TIMER_APP_VBASE + U300_TIMER_APP_DOST);
+		u300_timer_base + U300_TIMER_APP_DOST);
 	writel(U300_TIMER_APP_RDDT_TIMER_RESET,
-		U300_TIMER_APP_VBASE + U300_TIMER_APP_RDDT);
+		u300_timer_base + U300_TIMER_APP_RDDT);
 	writel(U300_TIMER_APP_DDDT_TIMER_DISABLE,
-		U300_TIMER_APP_VBASE + U300_TIMER_APP_DDDT);
+		u300_timer_base + U300_TIMER_APP_DDDT);
 
 	/* Reset the General Purpose timer 1. */
 	writel(U300_TIMER_APP_RGPT1_TIMER_RESET,
-		U300_TIMER_APP_VBASE + U300_TIMER_APP_RGPT1);
+		u300_timer_base + U300_TIMER_APP_RGPT1);
 
 	/* Set up the IRQ handler */
-	setup_irq(IRQ_U300_TIMER_APP_GP1, &u300_timer_irq);
+	setup_irq(irq, &u300_timer_irq);
 
 	/* Reset the General Purpose timer 2 */
 	writel(U300_TIMER_APP_RGPT2_TIMER_RESET,
-		U300_TIMER_APP_VBASE + U300_TIMER_APP_RGPT2);
+		u300_timer_base + U300_TIMER_APP_RGPT2);
 	/* Set this timer to run around forever */
-	writel(0xFFFFFFFFU, U300_TIMER_APP_VBASE + U300_TIMER_APP_GPT2TC);
+	writel(0xFFFFFFFFU, u300_timer_base + U300_TIMER_APP_GPT2TC);
 	/* Set continuous mode so it wraps around */
 	writel(U300_TIMER_APP_SGPT2M_MODE_CONTINUOUS,
-	       U300_TIMER_APP_VBASE + U300_TIMER_APP_SGPT2M);
+	       u300_timer_base + U300_TIMER_APP_SGPT2M);
 	/* Disable timer interrupts */
 	writel(U300_TIMER_APP_GPT2IE_IRQ_DISABLE,
-		U300_TIMER_APP_VBASE + U300_TIMER_APP_GPT2IE);
+		u300_timer_base + U300_TIMER_APP_GPT2IE);
 	/* Then enable the GP2 timer to use as a free running us counter */
 	writel(U300_TIMER_APP_EGPT2_TIMER_ENABLE,
-		U300_TIMER_APP_VBASE + U300_TIMER_APP_EGPT2);
+		u300_timer_base + U300_TIMER_APP_EGPT2);
 
 	/* Use general purpose timer 2 as clock source */
-	if (clocksource_mmio_init(U300_TIMER_APP_VBASE + U300_TIMER_APP_GPT2CC,
+	if (clocksource_mmio_init(u300_timer_base + U300_TIMER_APP_GPT2CC,
 			"GPT2", rate, 300, 32, clocksource_mmio_readl_up))
 		pr_err("timer: failed to initialize U300 clock source\n");
 
-- 
1.7.11.3



From linus.walleij at stericsson.com  Mon Apr 22 05:52:20 2013
From: linus.walleij at stericsson.com (Linus Walleij)
Date: Mon, 22 Apr 2013 11:52:20 +0200
Subject: [PATCH 06/23] ARM: u300: basic device tree support
Message-ID: <1366624340-6293-1-git-send-email-linus.walleij@stericsson.com>

From: Linus Walleij <linus.walleij at linaro.org>

This register the most basic peripherals and makes the
U300 boot to prompt from a device tree.

Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 Documentation/devicetree/bindings/arm/ste-u300.txt |  9 +++
 arch/arm/boot/dts/Makefile                         |  1 +
 arch/arm/boot/dts/ste-u300.dts                     | 86 ++++++++++++++++++++++
 arch/arm/mach-u300/core.c                          | 80 ++++++++++++++++++++
 4 files changed, 176 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/ste-u300.txt
 create mode 100644 arch/arm/boot/dts/ste-u300.dts

diff --git a/Documentation/devicetree/bindings/arm/ste-u300.txt b/Documentation/devicetree/bindings/arm/ste-u300.txt
new file mode 100644
index 0000000..222dca5
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/ste-u300.txt
@@ -0,0 +1,9 @@
+ST-Ericsson U300 Device Tree Bindings
+
+For various board the "board" node may contain specific properties
+that pertain to this particular board, such as board-specific GPIOs
+or board power regulator supplies.
+
+Required root node property:
+
+compatible="stericsson,u300";
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 9c62558..369fba7 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -165,6 +165,7 @@ dtb-$(CONFIG_ARCH_TEGRA) += tegra20-harmony.dtb \
 	tegra30-cardhu-a04.dtb \
 	tegra114-dalmore.dtb \
 	tegra114-pluto.dtb
+dtb-$(CONFIG_ARCH_U300) += ste-u300.dtb
 dtb-$(CONFIG_ARCH_VEXPRESS) += vexpress-v2p-ca5s.dtb \
 	vexpress-v2p-ca9.dtb \
 	vexpress-v2p-ca15-tc1.dtb \
diff --git a/arch/arm/boot/dts/ste-u300.dts b/arch/arm/boot/dts/ste-u300.dts
new file mode 100644
index 0000000..80f963c
--- /dev/null
+++ b/arch/arm/boot/dts/ste-u300.dts
@@ -0,0 +1,86 @@
+/*
+ * Device Tree for the ST-Ericsson U300 Machine and SoC
+ */
+
+/dts-v1/;
+/include/ "skeleton.dtsi"
+
+/ {
+	model = "ST-Ericsson U300";
+	compatible = "stericsson,u300";
+	#address-cells = <1>;
+	#size-cells = <1>;
+
+	chosen {
+		bootargs = "root=/dev/ram0 console=ttyAMA0,115200n8 earlyprintk";
+	};
+
+	aliases {
+		serial0 = &uart0;
+		serial1 = &uart1;
+        };
+
+	memory {
+		reg = <0x48000000 0x03c00000>;
+	};
+
+	timer: timer0 at c0014000 {
+		compatible = "stericsson,u300-apptimer";
+		reg = <0xc0014000 0x1000>;
+		interrupt-parent = <&vica>;
+		interrupts = <24 25 26 27>;
+	};
+
+	gpio: gpio0 at c0016000 {
+		compatible = "stericsson,gpio-coh901";
+		reg = <0xc0016000 0x1000>;
+		interrupt-parent = <&vicb>;
+		interrupts = <0 1 2 18 21 22 23>;
+		interrupt-names = "gpio0", "gpio1", "gpio2", "gpio3",
+				"gpio4", "gpio5", "gpio6";
+		interrupt-controller;
+		#interrupt-cells = <2>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
+	pinctrl: pinctrl0 at c0011000 {
+		compatible = "stericsson,pinctrl-u300";
+		reg = <0xc0011000 0x1000>;
+	};
+
+	amba {
+		compatible = "arm,amba-bus";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges;
+
+		vica: intc at 0xa0001000 {
+			compatible = "arm,versatile-vic";
+			interrupt-controller;
+			#interrupt-cells = <1>;
+			reg = <0xa0001000 0x20>;
+		};
+
+		vicb: intc at 0xa0002000 {
+			compatible = "arm,versatile-vic";
+			interrupt-controller;
+			#interrupt-cells = <1>;
+			reg = <0xa0002000 0x20>;
+		};
+
+		uart0: uart at c0013000 {
+			compatible = "arm,pl011", "arm,primecell";
+			reg = <0xc0013000 0x1000>;
+			interrupt-parent = <&vica>;
+			interrupts = <22>;
+		};
+
+		uart1: uart at c0007000 {
+			compatible = "arm,pl011", "arm,primecell";
+			reg = <0xc0007000 0x1000>;
+			interrupt-parent = <&vicb>;
+			interrupts = <20>;
+		};
+	};
+};
diff --git a/arch/arm/mach-u300/core.c b/arch/arm/mach-u300/core.c
index a683d17..5b42983 100644
--- a/arch/arm/mach-u300/core.c
+++ b/arch/arm/mach-u300/core.c
@@ -33,6 +33,8 @@
 #include <linux/platform_data/pinctrl-coh901.h>
 #include <linux/platform_data/dma-coh901318.h>
 #include <linux/irqchip/arm-vic.h>
+#include <linux/irqchip.h>
+#include <linux/of_platform.h>
 
 #include <asm/types.h>
 #include <asm/setup.h>
@@ -698,3 +700,81 @@ MACHINE_START(U300, "Ericsson AB U335 S335/B335 Prototype Board")
 	.init_machine	= u300_init_machine,
 	.restart	= u300_restart,
 MACHINE_END
+
+#ifdef CONFIG_OF
+
+/* These are mostly to get the right device names for the clock lookups */
+static struct of_dev_auxdata u300_auxdata_lookup[] __initdata = {
+	OF_DEV_AUXDATA("stericsson,pinctrl-u300", U300_SYSCON_BASE,
+		"pinctrl-u300", NULL),
+	OF_DEV_AUXDATA("stericsson,gpio-coh901", U300_GPIO_BASE,
+		"u300-gpio", &u300_gpio_plat),
+	OF_DEV_AUXDATA("arm,primecell", U300_UART0_BASE,
+		"uart0", &uart0_plat_data),
+	OF_DEV_AUXDATA("arm,primecell", U300_UART1_BASE,
+		"uart1", &uart1_plat_data),
+	OF_DEV_AUXDATA("arm,primecell", U300_MMCSD_BASE,
+		"mmci", &mmcsd_platform_data),
+	{ /* sentinel */ },
+};
+
+static void __init u300_init_irq_dt(void)
+{
+	struct clk *clk;
+
+	/* initialize clocking early, we want to clock the INTCON */
+	u300_clk_init(U300_SYSCON_VBASE);
+
+	/* Bootstrap EMIF and SEMI clocks */
+	clk = clk_get_sys("pl172", NULL);
+	BUG_ON(IS_ERR(clk));
+	clk_prepare_enable(clk);
+	clk = clk_get_sys("semi", NULL);
+	BUG_ON(IS_ERR(clk));
+	clk_prepare_enable(clk);
+
+	/* Clock the interrupt controller */
+	clk = clk_get_sys("intcon", NULL);
+	BUG_ON(IS_ERR(clk));
+	clk_prepare_enable(clk);
+
+	irqchip_init();
+}
+
+static void __init u300_init_machine_dt(void)
+{
+	u16 val;
+
+	/* Check what platform we run and print some status information */
+	u300_init_check_chip();
+
+	u300_assign_physmem();
+
+	/* Initialize pinmuxing */
+	pinctrl_register_mappings(u300_pinmux_map,
+				  ARRAY_SIZE(u300_pinmux_map));
+
+	of_platform_populate(NULL, of_default_bus_match_table,
+			u300_auxdata_lookup, NULL);
+
+	/* Enable SEMI self refresh */
+	val = readw(U300_SYSCON_VBASE + U300_SYSCON_SMCR) |
+		U300_SYSCON_SMCR_SEMI_SREFREQ_ENABLE;
+	writew(val, U300_SYSCON_VBASE + U300_SYSCON_SMCR);
+}
+
+static const char * u300_board_compat[] = {
+	"stericsson,u300",
+	NULL,
+};
+
+DT_MACHINE_START(U300_DT, "U300 S335/B335 (Device Tree)")
+	.map_io		= u300_map_io,
+	.init_irq	= u300_init_irq_dt,
+	.init_time	= u300_timer_init,
+	.init_machine	= u300_init_machine_dt,
+	.restart	= u300_restart,
+	.dt_compat      = u300_board_compat,
+MACHINE_END
+
+#endif /* CONFIG_OF */
-- 
1.7.11.3



From vinod.koul at intel.com  Mon Apr 22 05:21:53 2013
From: vinod.koul at intel.com (Vinod Koul)
Date: Mon, 22 Apr 2013 14:51:53 +0530
Subject: [PATCH 02/32] dmaengine: ste_dma40: Move default memcpy
 configs into the driver
In-Reply-To: <1366279934-30761-3-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-3-git-send-email-lee.jones@linaro.org>
Message-ID: <20130422092153.GA24632@intel.com>

On Thu, Apr 18, 2013 at 11:11:44AM +0100, Lee Jones wrote:
> There are only two default memcpy configurations used for the DMA40
> driver; one for physical memcpy and one for logical memcpy. Instead
> of invariably passing the same configurations though platform data,
> we're moving them into the driver instead.
> 
> Cc: Vinod Koul <vinod.koul at intel.com>
> Cc: Dan Williams <djbw at fb.com>
> Cc: Per Forlin <per.forlin at stericsson.com>
> Cc: Rabin Vincent <rabin at rab.in>
> Acked-by: Arnd Bergmann <arnd at arndb.de>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>
Acked-by: Vinod Koul <vnod.koul at intel.com>

--
~Vinod
> ---
>  arch/arm/mach-ux500/devices-db8500.c        |   28 -----------------------
>  drivers/dma/ste_dma40.c                     |   32 +++++++++++++++++++++++++--
>  include/linux/platform_data/dma-ste-dma40.h |    4 ----
>  3 files changed, 30 insertions(+), 34 deletions(-)
> 
> diff --git a/arch/arm/mach-ux500/devices-db8500.c b/arch/arm/mach-ux500/devices-db8500.c
> index 9b09683..5b1f1f7 100644
> --- a/arch/arm/mach-ux500/devices-db8500.c
> +++ b/arch/arm/mach-ux500/devices-db8500.c
> @@ -42,32 +42,6 @@ static struct resource dma40_resources[] = {
>  	}
>  };
>  
> -/* Default configuration for physcial memcpy */
> -struct stedma40_chan_cfg dma40_memcpy_conf_phy = {
> -	.mode = STEDMA40_MODE_PHYSICAL,
> -	.dir = STEDMA40_MEM_TO_MEM,
> -
> -	.src_info.data_width = STEDMA40_BYTE_WIDTH,
> -	.src_info.psize = STEDMA40_PSIZE_PHY_1,
> -	.src_info.flow_ctrl = STEDMA40_NO_FLOW_CTRL,
> -
> -	.dst_info.data_width = STEDMA40_BYTE_WIDTH,
> -	.dst_info.psize = STEDMA40_PSIZE_PHY_1,
> -	.dst_info.flow_ctrl = STEDMA40_NO_FLOW_CTRL,
> -};
> -/* Default configuration for logical memcpy */
> -struct stedma40_chan_cfg dma40_memcpy_conf_log = {
> -	.dir = STEDMA40_MEM_TO_MEM,
> -
> -	.src_info.data_width = STEDMA40_BYTE_WIDTH,
> -	.src_info.psize = STEDMA40_PSIZE_LOG_1,
> -	.src_info.flow_ctrl = STEDMA40_NO_FLOW_CTRL,
> -
> -	.dst_info.data_width = STEDMA40_BYTE_WIDTH,
> -	.dst_info.psize = STEDMA40_PSIZE_LOG_1,
> -	.dst_info.flow_ctrl = STEDMA40_NO_FLOW_CTRL,
> -};
> -
>  /*
>   * Mapping between destination event lines and physical device address.
>   * The event line is tied to a device and therefore the address is constant.
> @@ -150,8 +124,6 @@ static struct stedma40_platform_data dma40_plat_data = {
>  	.dev_len = DB8500_DMA_NR_DEV,
>  	.dev_rx = dma40_rx_map,
>  	.dev_tx = dma40_tx_map,
> -	.memcpy_conf_phy = &dma40_memcpy_conf_phy,
> -	.memcpy_conf_log = &dma40_memcpy_conf_log,
>  	.disabled_channels = {-1},
>  };
>  
> diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
> index 12de79e..3b83dee 100644
> --- a/drivers/dma/ste_dma40.c
> +++ b/drivers/dma/ste_dma40.c
> @@ -58,6 +58,34 @@
>  /* Reserved event lines for memcpy only. */
>  static int dma40_memcpy_channels[] = { 56, 57, 58, 59, 60 };
>  
> +/* Default configuration for physcial memcpy */
> +struct stedma40_chan_cfg dma40_memcpy_conf_phy = {
> +	.mode = STEDMA40_MODE_PHYSICAL,
> +	.dir = STEDMA40_MEM_TO_MEM,
> +
> +	.src_info.data_width = STEDMA40_BYTE_WIDTH,
> +	.src_info.psize = STEDMA40_PSIZE_PHY_1,
> +	.src_info.flow_ctrl = STEDMA40_NO_FLOW_CTRL,
> +
> +	.dst_info.data_width = STEDMA40_BYTE_WIDTH,
> +	.dst_info.psize = STEDMA40_PSIZE_PHY_1,
> +	.dst_info.flow_ctrl = STEDMA40_NO_FLOW_CTRL,
> +};
> +
> +/* Default configuration for logical memcpy */
> +struct stedma40_chan_cfg dma40_memcpy_conf_log = {
> +	.mode = STEDMA40_MODE_LOGICAL,
> +	.dir = STEDMA40_MEM_TO_MEM,
> +
> +	.src_info.data_width = STEDMA40_BYTE_WIDTH,
> +	.src_info.psize = STEDMA40_PSIZE_LOG_1,
> +	.src_info.flow_ctrl = STEDMA40_NO_FLOW_CTRL,
> +
> +	.dst_info.data_width = STEDMA40_BYTE_WIDTH,
> +	.dst_info.psize = STEDMA40_PSIZE_LOG_1,
> +	.dst_info.flow_ctrl = STEDMA40_NO_FLOW_CTRL,
> +};
> +
>  /**
>   * enum 40_command - The different commands and/or statuses.
>   *
> @@ -2015,13 +2043,13 @@ static int d40_config_memcpy(struct d40_chan *d40c)
>  	dma_cap_mask_t cap = d40c->chan.device->cap_mask;
>  
>  	if (dma_has_cap(DMA_MEMCPY, cap) && !dma_has_cap(DMA_SLAVE, cap)) {
> -		d40c->dma_cfg = *d40c->base->plat_data->memcpy_conf_log;
> +		d40c->dma_cfg = dma40_memcpy_conf_log;
>  		d40c->dma_cfg.src_dev_type = STEDMA40_DEV_SRC_MEMORY;
>  		d40c->dma_cfg.dst_dev_type = dma40_memcpy_channels[d40c->chan.chan_id];
>  
>  	} else if (dma_has_cap(DMA_MEMCPY, cap) &&
>  		   dma_has_cap(DMA_SLAVE, cap)) {
> -		d40c->dma_cfg = *d40c->base->plat_data->memcpy_conf_phy;
> +		d40c->dma_cfg = dma40_memcpy_conf_phy;
>  	} else {
>  		chan_err(d40c, "No memcpy\n");
>  		return -EINVAL;
> diff --git a/include/linux/platform_data/dma-ste-dma40.h b/include/linux/platform_data/dma-ste-dma40.h
> index a808784..869c571 100644
> --- a/include/linux/platform_data/dma-ste-dma40.h
> +++ b/include/linux/platform_data/dma-ste-dma40.h
> @@ -141,8 +141,6 @@ struct stedma40_chan_cfg {
>   * @dev_len: length of dev_tx and dev_rx
>   * @dev_tx: mapping between destination event line and io address
>   * @dev_rx: mapping between source event line and io address
> - * @memcpy_conf_phy: default configuration of physical channel memcpy
> - * @memcpy_conf_log: default configuration of logical channel memcpy
>   * @disabled_channels: A vector, ending with -1, that marks physical channels
>   * that are for different reasons not available for the driver.
>   * @soft_lli_chans: A vector, that marks physical channels will use LLI by SW
> @@ -160,8 +158,6 @@ struct stedma40_platform_data {
>  	u32				 dev_len;
>  	const dma_addr_t		*dev_tx;
>  	const dma_addr_t		*dev_rx;
> -	struct stedma40_chan_cfg	*memcpy_conf_phy;
> -	struct stedma40_chan_cfg	*memcpy_conf_log;
>  	int				 disabled_channels[STEDMA40_MAX_PHYS];
>  	int				*soft_lli_chans;
>  	int				 num_of_soft_lli_chans;
> -- 
> 1.7.10.4
> 


From linus.walleij at stericsson.com  Mon Apr 22 05:53:03 2013
From: linus.walleij at stericsson.com (Linus Walleij)
Date: Mon, 22 Apr 2013 11:53:03 +0200
Subject: [PATCH 07/23] i2c: stu300: device tree support
Message-ID: <1366624383-6330-1-git-send-email-linus.walleij@stericsson.com>

From: Linus Walleij <linus.walleij at linaro.org>

This adds device tree support for the ST DDC I2C driver known
as "stu300" in the kernel tree.

Cc: Wolfram Sang <wsa at the-dreams.de>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
Wolfram, I'm seeking an ACK to take this with the other lump
of U300 device tree patches through the ARM SoC tree.
---
 Documentation/devicetree/bindings/i2c/i2c-st-ddci2c.txt | 15 +++++++++++++++
 drivers/i2c/busses/i2c-stu300.c                         | 12 ++++++++++++
 2 files changed, 27 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/i2c/i2c-st-ddci2c.txt

diff --git a/Documentation/devicetree/bindings/i2c/i2c-st-ddci2c.txt b/Documentation/devicetree/bindings/i2c/i2c-st-ddci2c.txt
new file mode 100644
index 0000000..bd81a48
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-st-ddci2c.txt
@@ -0,0 +1,15 @@
+ST Microelectronics DDC I2C
+
+Required properties :
+- compatible : Must be "st,ddci2c"
+- reg: physical base address of the controller and length of memory mapped
+     region.
+- interrupts: interrupt number to the cpu.
+- #address-cells = <1>;
+- #size-cells = <0>;
+
+Optional properties:
+- Child nodes conforming to i2c bus binding
+
+Examples :
+
diff --git a/drivers/i2c/busses/i2c-stu300.c b/drivers/i2c/busses/i2c-stu300.c
index 0a6f941..1beaa05a 100644
--- a/drivers/i2c/busses/i2c-stu300.c
+++ b/drivers/i2c/busses/i2c-stu300.c
@@ -17,6 +17,7 @@
 #include <linux/clk.h>
 #include <linux/io.h>
 #include <linux/slab.h>
+#include <linux/of_i2c.h>
 
 /* the name of this kernel module */
 #define NAME "stu300"
@@ -923,6 +924,7 @@ stu300_probe(struct platform_device *pdev)
 	adap->nr = bus_nr;
 	adap->algo = &stu300_algo;
 	adap->dev.parent = &pdev->dev;
+	adap->dev.of_node = pdev->dev.of_node;
 	i2c_set_adapdata(adap, dev);
 
 	/* i2c device drivers may be active on return from add_adapter() */
@@ -934,6 +936,10 @@ stu300_probe(struct platform_device *pdev)
 	}
 
 	platform_set_drvdata(pdev, dev);
+	dev_info(&pdev->dev, "ST DDC I2C @ %p, irq %d\n",
+		 dev->virtbase, dev->irq);
+	of_i2c_register_devices(adap);
+
 	return 0;
 }
 
@@ -978,11 +984,17 @@ stu300_remove(struct platform_device *pdev)
 	return 0;
 }
 
+static const struct of_device_id stu300_dt_match[] = {
+	{ .compatible = "st,ddci2c" },
+	{},
+};
+
 static struct platform_driver stu300_i2c_driver = {
 	.driver = {
 		.name	= NAME,
 		.owner	= THIS_MODULE,
 		.pm	= STU300_I2C_PM,
+		.of_match_table = stu300_dt_match,
 	},
 	.remove		= __exit_p(stu300_remove),
 
-- 
1.7.11.3



From linus.walleij at stericsson.com  Mon Apr 22 05:53:20 2013
From: linus.walleij at stericsson.com (Linus Walleij)
Date: Mon, 22 Apr 2013 11:53:20 +0200
Subject: [PATCH 08/23] ARM: u300: register I2C bus drivers from device tree
Message-ID: <1366624400-6364-1-git-send-email-linus.walleij@stericsson.com>

From: Linus Walleij <linus.walleij at linaro.org>

This adds the two I2C busses to the device tree so these
probe properly.

Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 arch/arm/boot/dts/ste-u300.dts | 18 ++++++++++++++++++
 arch/arm/mach-u300/core.c      |  4 ++++
 2 files changed, 22 insertions(+)

diff --git a/arch/arm/boot/dts/ste-u300.dts b/arch/arm/boot/dts/ste-u300.dts
index 80f963c..9c08d5e 100644
--- a/arch/arm/boot/dts/ste-u300.dts
+++ b/arch/arm/boot/dts/ste-u300.dts
@@ -49,6 +49,24 @@
 		reg = <0xc0011000 0x1000>;
 	};
 
+	i2c0: i2c at c0004000 {
+		compatible = "st,ddci2c";
+		reg = <0xc0004000 0x1000>;
+		interrupt-parent = <&vicb>;
+		interrupts = <8>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+	};
+
+	i2c1: i2c at c0005000 {
+		compatible = "st,ddci2c";
+		reg = <0xc0005000 0x1000>;
+		interrupt-parent = <&vicb>;
+		interrupts = <9>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+	};
+
 	amba {
 		compatible = "arm,amba-bus";
 		#address-cells = <1>;
diff --git a/arch/arm/mach-u300/core.c b/arch/arm/mach-u300/core.c
index 5b42983..fedad38 100644
--- a/arch/arm/mach-u300/core.c
+++ b/arch/arm/mach-u300/core.c
@@ -713,6 +713,10 @@ static struct of_dev_auxdata u300_auxdata_lookup[] __initdata = {
 		"uart0", &uart0_plat_data),
 	OF_DEV_AUXDATA("arm,primecell", U300_UART1_BASE,
 		"uart1", &uart1_plat_data),
+	OF_DEV_AUXDATA("st,ddci2c", U300_I2C0_BASE,
+		"stu300.0", NULL),
+	OF_DEV_AUXDATA("st,ddci2c", U300_I2C1_BASE,
+		"stu300.1", NULL),
 	OF_DEV_AUXDATA("arm,primecell", U300_MMCSD_BASE,
 		"mmci", &mmcsd_platform_data),
 	{ /* sentinel */ },
-- 
1.7.11.3



From vinod.koul at intel.com  Mon Apr 22 05:22:35 2013
From: vinod.koul at intel.com (Vinod Koul)
Date: Mon, 22 Apr 2013 14:52:35 +0530
Subject: [PATCH 01/32] dmaengine: ste_dma40: Assign memcpy channels in
 the driver
In-Reply-To: <1366279934-30761-2-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-2-git-send-email-lee.jones@linaro.org>
Message-ID: <20130422092235.GB24632@intel.com>

On Thu, Apr 18, 2013 at 11:11:43AM +0100, Lee Jones wrote:
> The channels reserved for memcpy are the same for all currently
> supported platforms. With this in mind, we can ease the platform
> data passing requirement by moving these assignments out from
> platform code and place them directly into the driver.
> 
> Cc: Vinod Koul <vinod.koul at intel.com>
> Cc: Dan Williams <djbw at fb.com>
> Cc: Per Forlin <per.forlin at stericsson.com>
> Cc: Rabin Vincent <rabin at rab.in>
> Acked-by: Arnd Bergmann <arnd at arndb.de>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>
Acked-by: Vinod Koul <vnod.koul at intel.com>

--
~Vinod
> ---
>  arch/arm/mach-ux500/devices-db8500.c        |   12 ------------
>  drivers/dma/ste_dma40.c                     |   12 +++++++-----
>  include/linux/platform_data/dma-ste-dma40.h |    4 ----
>  3 files changed, 7 insertions(+), 21 deletions(-)
> 
> diff --git a/arch/arm/mach-ux500/devices-db8500.c b/arch/arm/mach-ux500/devices-db8500.c
> index afa5b04..9b09683 100644
> --- a/arch/arm/mach-ux500/devices-db8500.c
> +++ b/arch/arm/mach-ux500/devices-db8500.c
> @@ -146,22 +146,10 @@ static const dma_addr_t dma40_rx_map[DB8500_DMA_NR_DEV] = {
>  	[DB8500_DMA_DEV48_CAC1_RX] = U8500_CRYP1_BASE + CRYP1_RX_REG_OFFSET,
>  };
>  
> -/* Reserved event lines for memcpy only */
> -static int dma40_memcpy_event[] = {
> -	DB8500_DMA_MEMCPY_TX_0,
> -	DB8500_DMA_MEMCPY_TX_1,
> -	DB8500_DMA_MEMCPY_TX_2,
> -	DB8500_DMA_MEMCPY_TX_3,
> -	DB8500_DMA_MEMCPY_TX_4,
> -	DB8500_DMA_MEMCPY_TX_5,
> -};
> -
>  static struct stedma40_platform_data dma40_plat_data = {
>  	.dev_len = DB8500_DMA_NR_DEV,
>  	.dev_rx = dma40_rx_map,
>  	.dev_tx = dma40_tx_map,
> -	.memcpy = dma40_memcpy_event,
> -	.memcpy_len = ARRAY_SIZE(dma40_memcpy_event),
>  	.memcpy_conf_phy = &dma40_memcpy_conf_phy,
>  	.memcpy_conf_log = &dma40_memcpy_conf_log,
>  	.disabled_channels = {-1},
> diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
> index 1734fee..12de79e 100644
> --- a/drivers/dma/ste_dma40.c
> +++ b/drivers/dma/ste_dma40.c
> @@ -55,6 +55,9 @@
>  
>  #define MAX(a, b) (((a) < (b)) ? (b) : (a))
>  
> +/* Reserved event lines for memcpy only. */
> +static int dma40_memcpy_channels[] = { 56, 57, 58, 59, 60 };
> +
>  /**
>   * enum 40_command - The different commands and/or statuses.
>   *
> @@ -2014,8 +2017,7 @@ static int d40_config_memcpy(struct d40_chan *d40c)
>  	if (dma_has_cap(DMA_MEMCPY, cap) && !dma_has_cap(DMA_SLAVE, cap)) {
>  		d40c->dma_cfg = *d40c->base->plat_data->memcpy_conf_log;
>  		d40c->dma_cfg.src_dev_type = STEDMA40_DEV_SRC_MEMORY;
> -		d40c->dma_cfg.dst_dev_type = d40c->base->plat_data->
> -			memcpy[d40c->chan.chan_id];
> +		d40c->dma_cfg.dst_dev_type = dma40_memcpy_channels[d40c->chan.chan_id];
>  
>  	} else if (dma_has_cap(DMA_MEMCPY, cap) &&
>  		   dma_has_cap(DMA_SLAVE, cap)) {
> @@ -2927,7 +2929,7 @@ static int __init d40_dmaengine_init(struct d40_base *base,
>  	}
>  
>  	d40_chan_init(base, &base->dma_memcpy, base->log_chans,
> -		      base->num_log_chans, base->plat_data->memcpy_len);
> +		      base->num_log_chans, ARRAY_SIZE(dma40_memcpy_channels));
>  
>  	dma_cap_zero(base->dma_memcpy.cap_mask);
>  	dma_cap_set(DMA_MEMCPY, base->dma_memcpy.cap_mask);
> @@ -3215,7 +3217,7 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
>  			num_log_chans++;
>  
>  	base = kzalloc(ALIGN(sizeof(struct d40_base), 4) +
> -		       (num_phy_chans + num_log_chans + plat_data->memcpy_len) *
> +		       (num_phy_chans + num_log_chans + ARRAY_SIZE(dma40_memcpy_channels)) *
>  		       sizeof(struct d40_chan), GFP_KERNEL);
>  
>  	if (base == NULL) {
> @@ -3276,7 +3278,7 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
>  	if (!base->lookup_phy_chans)
>  		goto failure;
>  
> -	if (num_log_chans + plat_data->memcpy_len) {
> +	if (num_log_chans + ARRAY_SIZE(dma40_memcpy_channels)) {
>  		/*
>  		 * The max number of logical channels are event lines for all
>  		 * src devices and dst devices
> diff --git a/include/linux/platform_data/dma-ste-dma40.h b/include/linux/platform_data/dma-ste-dma40.h
> index 4b78101..a808784 100644
> --- a/include/linux/platform_data/dma-ste-dma40.h
> +++ b/include/linux/platform_data/dma-ste-dma40.h
> @@ -141,8 +141,6 @@ struct stedma40_chan_cfg {
>   * @dev_len: length of dev_tx and dev_rx
>   * @dev_tx: mapping between destination event line and io address
>   * @dev_rx: mapping between source event line and io address
> - * @memcpy: list of memcpy event lines
> - * @memcpy_len: length of memcpy
>   * @memcpy_conf_phy: default configuration of physical channel memcpy
>   * @memcpy_conf_log: default configuration of logical channel memcpy
>   * @disabled_channels: A vector, ending with -1, that marks physical channels
> @@ -162,8 +160,6 @@ struct stedma40_platform_data {
>  	u32				 dev_len;
>  	const dma_addr_t		*dev_tx;
>  	const dma_addr_t		*dev_rx;
> -	int				*memcpy;
> -	u32				 memcpy_len;
>  	struct stedma40_chan_cfg	*memcpy_conf_phy;
>  	struct stedma40_chan_cfg	*memcpy_conf_log;
>  	int				 disabled_channels[STEDMA40_MAX_PHYS];
> -- 
> 1.7.10.4
> 


From vinod.koul at intel.com  Mon Apr 22 05:23:21 2013
From: vinod.koul at intel.com (Vinod Koul)
Date: Mon, 22 Apr 2013 14:53:21 +0530
Subject: [PATCH 13/32] dmaengine: ste_dma40: Calculate number of
 logical channels from physical ones
In-Reply-To: <1366279934-30761-14-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-14-git-send-email-lee.jones@linaro.org>
Message-ID: <20130422092321.GC24632@intel.com>

On Thu, Apr 18, 2013 at 11:11:55AM +0100, Lee Jones wrote:
> This change will cost ~25KB of memory, but it's worth the trade-off,
> as it removes a great deal of overhead. It means that instead of only
> allocating memory for the logical channels in use, it does so for all
> available ones, which is 32 per physical channel. However, this now
> means we can remove some platform data and we don't have to worry
> about adding vendor specific variables to Device Tree.
> 
> Cc: Vinod Koul <vinod.koul at intel.com>
> Cc: Dan Williams <djbw at fb.com>
> Cc: Per Forlin <per.forlin at stericsson.com>
> Cc: Rabin Vincent <rabin at rab.in>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>
> ---
>  arch/arm/mach-ux500/devices-db8500.c        |    1 -
>  drivers/dma/ste_dma40.c                     |   16 ++++++----------
>  include/linux/platform_data/dma-ste-dma40.h |    2 --
>  3 files changed, 6 insertions(+), 13 deletions(-)
> 
> diff --git a/arch/arm/mach-ux500/devices-db8500.c b/arch/arm/mach-ux500/devices-db8500.c
> index 03efd4c1..2fcb8c2 100644
> --- a/arch/arm/mach-ux500/devices-db8500.c
> +++ b/arch/arm/mach-ux500/devices-db8500.c
> @@ -121,7 +121,6 @@ static const dma_addr_t dma40_rx_map[DB8500_DMA_NR_DEV] = {
>  };
>  
>  static struct stedma40_platform_data dma40_plat_data = {
> -	.dev_len = DB8500_DMA_NR_DEV,
>  	.dev_rx = dma40_rx_map,
>  	.dev_tx = dma40_tx_map,
>  	.disabled_channels = {-1},
> diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
> index 7b451b2..a39ef74 100644
> --- a/drivers/dma/ste_dma40.c
> +++ b/drivers/dma/ste_dma40.c
> @@ -45,6 +45,9 @@
>  #define D40_LCLA_LINK_PER_EVENT_GRP 128
>  #define D40_LCLA_END D40_LCLA_LINK_PER_EVENT_GRP
>  
> +/* Max number of logical channels per physical channel */
> +#define D40_MAX_LOG_CHAN_PER_PHY 32
> +
>  /* Attempts before giving up to trying to get pages that are aligned */
>  #define MAX_LCLA_ALLOC_ATTEMPTS 256
>  
> @@ -3197,6 +3200,8 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
>  	else
>  		num_phy_chans = 4 * (readl(virtbase + D40_DREG_ICFG) & 0x7) + 4;
>  
> +	num_log_chans = num_phy_chans * D40_MAX_LOG_CHAN_PER_PHY;
> +
>  	dev_info(&pdev->dev, "hardware revision: %d @ 0x%x with %d physical channels\n",
>  		 rev, res->start, num_phy_chans);
>  
> @@ -3206,15 +3211,6 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
>  		goto failure;
>  	}
>  
> -	/* Count the number of logical channels in use */
> -	for (i = 0; i < plat_data->dev_len; i++)
> -		if (plat_data->dev_rx[i] != 0)
> -			num_log_chans++;
> -
> -	for (i = 0; i < plat_data->dev_len; i++)
> -		if (plat_data->dev_tx[i] != 0)
> -			num_log_chans++;
> -
>  	base = kzalloc(ALIGN(sizeof(struct d40_base), 4) +
>  		       (num_phy_chans + num_log_chans + ARRAY_SIZE(dma40_memcpy_channels)) *
>  		       sizeof(struct d40_chan), GFP_KERNEL);
> @@ -3282,7 +3278,7 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
>  		 * The max number of logical channels are event lines for all
>  		 * src devices and dst devices
>  		 */
> -		base->lookup_log_chans = kzalloc(plat_data->dev_len * 2 *
> +		base->lookup_log_chans = kzalloc(num_log_chans *
you could have used devm_ helper for this.

Still,

Acked-by: Vinod Koul <vnod.koul at intel.com>

--
~Vinod
>  						 sizeof(struct d40_chan *),
>  						 GFP_KERNEL);
>  		if (!base->lookup_log_chans)
> diff --git a/include/linux/platform_data/dma-ste-dma40.h b/include/linux/platform_data/dma-ste-dma40.h
> index 9e42a67..c54af61 100644
> --- a/include/linux/platform_data/dma-ste-dma40.h
> +++ b/include/linux/platform_data/dma-ste-dma40.h
> @@ -136,7 +136,6 @@ struct stedma40_chan_cfg {
>  /**
>   * struct stedma40_platform_data - Configuration struct for the dma device.
>   *
> - * @dev_len: length of dev_tx and dev_rx
>   * @dev_tx: mapping between destination event line and io address
>   * @dev_rx: mapping between source event line and io address
>   * @disabled_channels: A vector, ending with -1, that marks physical channels
> @@ -153,7 +152,6 @@ struct stedma40_chan_cfg {
>   * for 'multiple of 4' channels, like 8.
>   */
>  struct stedma40_platform_data {
> -	u32				 dev_len;
>  	const dma_addr_t		*dev_tx;
>  	const dma_addr_t		*dev_rx;
>  	int				 disabled_channels[STEDMA40_MAX_PHYS];
> -- 
> 1.7.10.4
> 


From linus.walleij at stericsson.com  Mon Apr 22 05:55:18 2013
From: linus.walleij at stericsson.com (Linus Walleij)
Date: Mon, 22 Apr 2013 11:55:18 +0200
Subject: [PATCH 10/23] ARM: u300: add the COH 901 327 watchdog to device tree
Message-ID: <1366624518-6471-1-git-send-email-linus.walleij@stericsson.com>

From: Linus Walleij <linus.walleij at linaro.org>

This adds the COH 901 327 watchdog to the U300 device tree.

Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 arch/arm/boot/dts/ste-u300.dts | 7 +++++++
 arch/arm/mach-u300/core.c      | 2 ++
 2 files changed, 9 insertions(+)

diff --git a/arch/arm/boot/dts/ste-u300.dts b/arch/arm/boot/dts/ste-u300.dts
index 9c08d5e..b1b63bb 100644
--- a/arch/arm/boot/dts/ste-u300.dts
+++ b/arch/arm/boot/dts/ste-u300.dts
@@ -49,6 +49,13 @@
 		reg = <0xc0011000 0x1000>;
 	};
 
+	watchdog: watchdog at c0012000 {
+		compatible = "stericsson,coh901327";
+		reg = <0xc0012000 0x1000>;
+		interrupt-parent = <&vicb>;
+		interrupts = <3>;
+	};
+
 	i2c0: i2c at c0004000 {
 		compatible = "st,ddci2c";
 		reg = <0xc0004000 0x1000>;
diff --git a/arch/arm/mach-u300/core.c b/arch/arm/mach-u300/core.c
index fedad38..f97b65c 100644
--- a/arch/arm/mach-u300/core.c
+++ b/arch/arm/mach-u300/core.c
@@ -709,6 +709,8 @@ static struct of_dev_auxdata u300_auxdata_lookup[] __initdata = {
 		"pinctrl-u300", NULL),
 	OF_DEV_AUXDATA("stericsson,gpio-coh901", U300_GPIO_BASE,
 		"u300-gpio", &u300_gpio_plat),
+	OF_DEV_AUXDATA("stericsson,coh901327", U300_WDOG_BASE,
+		"coh901327_wdog", NULL),
 	OF_DEV_AUXDATA("arm,primecell", U300_UART0_BASE,
 		"uart0", &uart0_plat_data),
 	OF_DEV_AUXDATA("arm,primecell", U300_UART1_BASE,
-- 
1.7.11.3



From linus.walleij at stericsson.com  Mon Apr 22 05:55:05 2013
From: linus.walleij at stericsson.com (Linus Walleij)
Date: Mon, 22 Apr 2013 11:55:05 +0200
Subject: [PATCH 09/23] watchdog: coh901327: devicetree support
Message-ID: <1366624505-6437-1-git-send-email-linus.walleij@stericsson.com>

From: Linus Walleij <linus.walleij at linaro.org>

This adds support for probing the COH 901 327 watchdog from
the device tree and also adds associated bindings.

Cc: Wim Van Sebroeck <wim at iguana.be>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
Hi Wim, I'm seeking an ACK on this patch to take it into
ARM SoC along with the patches making use of this new
binding.
---
 .../devicetree/bindings/watchdog/stericsson-coh901327.txt | 15 +++++++++++++++
 drivers/watchdog/coh901327_wdt.c                          |  6 ++++++
 2 files changed, 21 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/watchdog/stericsson-coh901327.txt

diff --git a/Documentation/devicetree/bindings/watchdog/stericsson-coh901327.txt b/Documentation/devicetree/bindings/watchdog/stericsson-coh901327.txt
new file mode 100644
index 0000000..3d7c958
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/stericsson-coh901327.txt
@@ -0,0 +1,15 @@
+ST-Ericsson COH 901 327 Watchdog timer
+
+Required properties:
+- compatible: must be "stericsson,coh901327".
+- reg: physical base address of the controller and length of memory mapped
+  region.
+- interrupts: the interrupt used for the watchdog timeout warning.
+
+Example:
+
+watchdog: watchdog at c0012000 {
+	compatible = "stericsson,coh901327";
+	reg = <0xc0012000 0x1000>;
+	interrupts = <3>;
+};
diff --git a/drivers/watchdog/coh901327_wdt.c b/drivers/watchdog/coh901327_wdt.c
index b9b8a8b..bb7da59 100644
--- a/drivers/watchdog/coh901327_wdt.c
+++ b/drivers/watchdog/coh901327_wdt.c
@@ -441,10 +441,16 @@ void coh901327_watchdog_reset(void)
 	/* Return and await doom */
 }
 
+static const struct of_device_id coh901327_dt_match[] = {
+	{ .compatible = "stericsson,coh901327" },
+	{},
+};
+
 static struct platform_driver coh901327_driver = {
 	.driver = {
 		.owner	= THIS_MODULE,
 		.name	= "coh901327_wdog",
+		.of_match_table = coh901327_dt_match,
 	},
 	.remove		= __exit_p(coh901327_remove),
 	.suspend	= coh901327_suspend,
-- 
1.7.11.3



From maxime.ripard at free-electrons.com  Mon Apr 22 05:55:53 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Mon, 22 Apr 2013 11:55:53 +0200
Subject: [PATCHv2 0/2] Add support for the Solomon SSD1306 OLED Controller
Message-ID: <1366624555-5616-1-git-send-email-maxime.ripard@free-electrons.com>

Hi,

This patchset adds the needed bits to the ssd1307fb driver to support the
very similar Solomon SSD1306 controller.

Since the SSD1307 has been replaced by the SSD1306 in the latest CFA-10036
production samples, we also need to change the device tree accordingly.

Thanks,
Maxime

Changes from v1:
  - Fix style errors

Maxime Ripard (2):
  video: ssd1307fb: Add support for SSD1306 OLED controller
  ARM: dts: cfa10036: Change the OLED display to SSD1306

 .../devicetree/bindings/video/ssd1307fb.txt        |   10 +-
 arch/arm/boot/dts/imx28-cfa10036.dts               |   14 +-
 arch/arm/boot/dts/imx28-cfa10049.dts               |    4 +-
 drivers/video/ssd1307fb.c                          |  273 +++++++++++++++-----
 4 files changed, 216 insertions(+), 85 deletions(-)

-- 
1.7.10.4



From maxime.ripard at free-electrons.com  Mon Apr 22 05:55:55 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Mon, 22 Apr 2013 11:55:55 +0200
Subject: [PATCH 2/2] ARM: dts: cfa10036: Change the OLED display to SSD1306
In-Reply-To: <1366624555-5616-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1366624555-5616-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1366624555-5616-3-git-send-email-maxime.ripard@free-electrons.com>

The SSD1307 was used in an early prototype that will never get
distributed. The final board now has a SSD1306 instead, that has its own
power generation unit and thus doesn't need any PWM. The panel attached
to it also changed.

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 arch/arm/boot/dts/imx28-cfa10036.dts |   14 +++++---------
 arch/arm/boot/dts/imx28-cfa10049.dts |    4 ++--
 2 files changed, 7 insertions(+), 11 deletions(-)

diff --git a/arch/arm/boot/dts/imx28-cfa10036.dts b/arch/arm/boot/dts/imx28-cfa10036.dts
index 1594694..40488f5a8 100644
--- a/arch/arm/boot/dts/imx28-cfa10036.dts
+++ b/arch/arm/boot/dts/imx28-cfa10036.dts
@@ -58,12 +58,6 @@
 		};
 
 		apbx at 80040000 {
-			pwm: pwm at 80064000 {
-				pinctrl-names = "default";
-				pinctrl-0 = <&pwm4_pins_a>;
-				status = "okay";
-			};
-
 			duart: serial at 80074000 {
 				pinctrl-names = "default";
 				pinctrl-0 = <&duart_pins_b>;
@@ -75,11 +69,13 @@
 				pinctrl-0 = <&i2c0_pins_b>;
 				status = "okay";
 
-				ssd1307: oled at 3c {
-					compatible = "solomon,ssd1307fb-i2c";
+				ssd1306: oled at 3c {
+					compatible = "solomon,ssd1306fb-i2c";
 					reg = <0x3c>;
-					pwms = <&pwm 4 3000>;
 					reset-gpios = <&gpio2 7 0>;
+					solomon,height = <32>;
+					solomon,width = <128>;
+					solomon,page-offset = <0>;
 				};
 			};
 		};
diff --git a/arch/arm/boot/dts/imx28-cfa10049.dts b/arch/arm/boot/dts/imx28-cfa10049.dts
index a0d3e9f..ded7784 100644
--- a/arch/arm/boot/dts/imx28-cfa10049.dts
+++ b/arch/arm/boot/dts/imx28-cfa10049.dts
@@ -132,8 +132,8 @@
 
 		apbx at 80040000 {
 			pwm: pwm at 80064000 {
-				pinctrl-names = "default", "default";
-				pinctrl-1 = <&pwm3_pins_b>;
+				pinctrl-names = "default";
+				pinctrl-0 = <&pwm3_pins_b>;
 				status = "okay";
 			};
 
-- 
1.7.10.4



From maxime.ripard at free-electrons.com  Mon Apr 22 05:55:54 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Mon, 22 Apr 2013 11:55:54 +0200
Subject: [PATCH 1/2] video: ssd1307fb: Add support for SSD1306 OLED controller
In-Reply-To: <1366624555-5616-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1366624555-5616-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1366624555-5616-2-git-send-email-maxime.ripard@free-electrons.com>

The Solomon SSD1306 OLED controller is very similar to the SSD1307,
except for the fact that the power is given through an external PWM for
the 1307, and while the 1306 can generate its own power without any PWM.

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 .../devicetree/bindings/video/ssd1307fb.txt        |   10 +-
 drivers/video/ssd1307fb.c                          |  273 +++++++++++++++-----
 2 files changed, 209 insertions(+), 74 deletions(-)

diff --git a/Documentation/devicetree/bindings/video/ssd1307fb.txt b/Documentation/devicetree/bindings/video/ssd1307fb.txt
index 3d0060c..7a12542 100644
--- a/Documentation/devicetree/bindings/video/ssd1307fb.txt
+++ b/Documentation/devicetree/bindings/video/ssd1307fb.txt
@@ -1,13 +1,17 @@
 * Solomon SSD1307 Framebuffer Driver
 
 Required properties:
-  - compatible: Should be "solomon,ssd1307fb-<bus>". The only supported bus for
-    now is i2c.
+  - compatible: Should be "solomon,<chip>fb-<bus>". The only supported bus for
+    now is i2c, and the supported chips are ssd1306 and ssd1307.
   - reg: Should contain address of the controller on the I2C bus. Most likely
          0x3c or 0x3d
   - pwm: Should contain the pwm to use according to the OF device tree PWM
-         specification [0]
+         specification [0]. Only required for the ssd1307.
   - reset-gpios: Should contain the GPIO used to reset the OLED display
+  - solomon,height: Height in pixel of the screen driven by the controller
+  - solomon,width: Width in pixel of the screen driven by the controller
+  - solomon,page-offset: Offset of pages (band of 8 pixels) that the screen is
+    mapped to.
 
 Optional properties:
   - reset-active-low: Is the reset gpio is active on physical low?
diff --git a/drivers/video/ssd1307fb.c b/drivers/video/ssd1307fb.c
index 395cb6a..5ab5281 100644
--- a/drivers/video/ssd1307fb.c
+++ b/drivers/video/ssd1307fb.c
@@ -16,24 +16,39 @@
 #include <linux/pwm.h>
 #include <linux/delay.h>
 
-#define SSD1307FB_WIDTH			96
-#define SSD1307FB_HEIGHT		16
-
 #define SSD1307FB_DATA			0x40
 #define SSD1307FB_COMMAND		0x80
 
 #define SSD1307FB_CONTRAST		0x81
+#define	SSD1307FB_CHARGE_PUMP		0x8d
 #define SSD1307FB_SEG_REMAP_ON		0xa1
 #define SSD1307FB_DISPLAY_OFF		0xae
+#define SSD1307FB_SET_MULTIPLEX_RATIO	0xa8
 #define SSD1307FB_DISPLAY_ON		0xaf
 #define SSD1307FB_START_PAGE_ADDRESS	0xb0
+#define SSD1307FB_SET_DISPLAY_OFFSET	0xd3
+#define	SSD1307FB_SET_CLOCK_FREQ	0xd5
+#define	SSD1307FB_SET_PRECHARGE_PERIOD	0xd9
+#define	SSD1307FB_SET_COM_PINS_CONFIG	0xda
+#define	SSD1307FB_SET_VCOMH		0xdb
+
+struct ssd1307fb_par;
+
+struct ssd1307fb_ops {
+	int (*init)(struct ssd1307fb_par *);
+	int (*remove)(struct ssd1307fb_par *);
+};
 
 struct ssd1307fb_par {
 	struct i2c_client *client;
+	u32 height;
 	struct fb_info *info;
+	struct ssd1307fb_ops *ops;
+	u32 page_offset;
 	struct pwm_device *pwm;
 	u32 pwm_period;
 	int reset;
+	u32 width;
 };
 
 static struct fb_fix_screeninfo ssd1307fb_fix = {
@@ -43,15 +58,10 @@ static struct fb_fix_screeninfo ssd1307fb_fix = {
 	.xpanstep	= 0,
 	.ypanstep	= 0,
 	.ywrapstep	= 0,
-	.line_length	= SSD1307FB_WIDTH / 8,
 	.accel		= FB_ACCEL_NONE,
 };
 
 static struct fb_var_screeninfo ssd1307fb_var = {
-	.xres		= SSD1307FB_WIDTH,
-	.yres		= SSD1307FB_HEIGHT,
-	.xres_virtual	= SSD1307FB_WIDTH,
-	.yres_virtual	= SSD1307FB_HEIGHT,
 	.bits_per_pixel	= 1,
 };
 
@@ -134,16 +144,17 @@ static void ssd1307fb_update_display(struct ssd1307fb_par *par)
 	 *  (5) A4 B4 C4 D4 E4 F4 G4 H4
 	 */
 
-	for (i = 0; i < (SSD1307FB_HEIGHT / 8); i++) {
-		ssd1307fb_write_cmd(par->client, SSD1307FB_START_PAGE_ADDRESS + (i + 1));
+	for (i = 0; i < (par->height / 8); i++) {
+		ssd1307fb_write_cmd(par->client,
+				    SSD1307FB_START_PAGE_ADDRESS + i + par->page_offset);
 		ssd1307fb_write_cmd(par->client, 0x00);
 		ssd1307fb_write_cmd(par->client, 0x10);
 
-		for (j = 0; j < SSD1307FB_WIDTH; j++) {
+		for (j = 0; j < par->width; j++) {
 			u8 buf = 0;
 			for (k = 0; k < 8; k++) {
-				u32 page_length = SSD1307FB_WIDTH * i;
-				u32 index = page_length + (SSD1307FB_WIDTH * k + j) / 8;
+				u32 page_length = par->width * i;
+				u32 index = page_length + (par->width * k + j) / 8;
 				u8 byte = *(vmem + index);
 				u8 bit = byte & (1 << (j % 8));
 				bit = bit >> (j % 8);
@@ -227,16 +238,147 @@ static struct fb_deferred_io ssd1307fb_defio = {
 	.deferred_io	= ssd1307fb_deferred_io,
 };
 
+static int ssd1307fb_ssd1307_init(struct ssd1307fb_par *par)
+{
+	int ret;
+
+	par->pwm = pwm_get(&par->client->dev, NULL);
+	if (IS_ERR(par->pwm)) {
+		dev_err(&par->client->dev, "Could not get PWM from device tree!\n");
+		return PTR_ERR(par->pwm);
+	}
+
+	par->pwm_period = pwm_get_period(par->pwm);
+	/* Enable the PWM */
+	pwm_config(par->pwm, par->pwm_period / 2, par->pwm_period);
+	pwm_enable(par->pwm);
+
+	dev_dbg(&par->client->dev, "Using PWM%d with a %dns period.\n",
+		par->pwm->pwm, par->pwm_period);
+
+	/* Map column 127 of the OLED to segment 0 */
+	ret = ssd1307fb_write_cmd(par->client, SSD1307FB_SEG_REMAP_ON);
+	if (ret < 0)
+		return ret;
+
+	/* Turn on the display */
+	ret = ssd1307fb_write_cmd(par->client, SSD1307FB_DISPLAY_ON);
+	if (ret < 0)
+		return ret;
+
+	return 0;
+}
+
+static int ssd1307fb_ssd1307_remove(struct ssd1307fb_par *par)
+{
+	pwm_disable(par->pwm);
+	pwm_put(par->pwm);
+	return 0;
+}
+
+static struct ssd1307fb_ops ssd1307fb_ssd1307_ops = {
+	.init	= ssd1307fb_ssd1307_init,
+	.remove	= ssd1307fb_ssd1307_remove,
+};
+
+static int ssd1307fb_ssd1306_init(struct ssd1307fb_par *par)
+{
+	int ret;
+
+	/* Set initial contrast */
+	ret = ssd1307fb_write_cmd(par->client, SSD1307FB_CONTRAST);
+	ret = ret & ssd1307fb_write_cmd(par->client, 0x7f);
+	if (ret < 0)
+		return ret;
+
+	/* Set COM direction */
+	ret = ssd1307fb_write_cmd(par->client, 0xc8);
+	if (ret < 0)
+		return ret;
+
+	/* Set segment re-map */
+	ret = ssd1307fb_write_cmd(par->client, SSD1307FB_SEG_REMAP_ON);
+	if (ret < 0)
+		return ret;
+
+	/* Set multiplex ratio value */
+	ret = ssd1307fb_write_cmd(par->client, SSD1307FB_SET_MULTIPLEX_RATIO);
+	ret = ret & ssd1307fb_write_cmd(par->client, par->height - 1);
+	if (ret < 0)
+		return ret;
+
+	/* set display offset value */
+	ret = ssd1307fb_write_cmd(par->client, SSD1307FB_SET_DISPLAY_OFFSET);
+	ret = ssd1307fb_write_cmd(par->client, 0x20);
+	if (ret < 0)
+		return ret;
+
+	/* Set clock frequency */
+	ret = ssd1307fb_write_cmd(par->client, SSD1307FB_SET_CLOCK_FREQ);
+	ret = ret & ssd1307fb_write_cmd(par->client, 0xf0);
+	if (ret < 0)
+		return ret;
+
+	/* Set precharge period in number of ticks from the internal clock */
+	ret = ssd1307fb_write_cmd(par->client, SSD1307FB_SET_PRECHARGE_PERIOD);
+	ret = ret & ssd1307fb_write_cmd(par->client, 0x22);
+	if (ret < 0)
+		return ret;
+
+	/* Set COM pins configuration */
+	ret = ssd1307fb_write_cmd(par->client, SSD1307FB_SET_COM_PINS_CONFIG);
+	ret = ret & ssd1307fb_write_cmd(par->client, 0x22);
+	if (ret < 0)
+		return ret;
+
+	/* Set VCOMH */
+	ret = ssd1307fb_write_cmd(par->client, SSD1307FB_SET_VCOMH);
+	ret = ret & ssd1307fb_write_cmd(par->client, 0x49);
+	if (ret < 0)
+		return ret;
+
+	/* Turn on the DC-DC Charge Pump */
+	ret = ssd1307fb_write_cmd(par->client, SSD1307FB_CHARGE_PUMP);
+	ret = ret & ssd1307fb_write_cmd(par->client, 0x14);
+	if (ret < 0)
+		return ret;
+
+	/* Turn on the display */
+	ret = ssd1307fb_write_cmd(par->client, SSD1307FB_DISPLAY_ON);
+	if (ret < 0)
+		return ret;
+
+	return 0;
+}
+
+static struct ssd1307fb_ops ssd1307fb_ssd1306_ops = {
+	.init	= ssd1307fb_ssd1306_init,
+};
+
+static const struct of_device_id ssd1307fb_of_match[] = {
+	{
+		.compatible = "solomon,ssd1306fb-i2c",
+		.data = (void *)&ssd1307fb_ssd1306_ops,
+	},
+	{
+		.compatible = "solomon,ssd1307fb-i2c",
+		.data = (void *)&ssd1307fb_ssd1307_ops,
+	},
+	{},
+};
+MODULE_DEVICE_TABLE(of, ssd1307fb_of_match);
+
 static int ssd1307fb_probe(struct i2c_client *client,
 			   const struct i2c_device_id *id)
 {
 	struct fb_info *info;
-	u32 vmem_size = SSD1307FB_WIDTH * SSD1307FB_HEIGHT / 8;
+	struct device_node *node = client->dev.of_node;
+	u32 vmem_size;
 	struct ssd1307fb_par *par;
 	u8 *vmem;
 	int ret;
 
-	if (!client->dev.of_node) {
+	if (!node) {
 		dev_err(&client->dev, "No device tree data found!\n");
 		return -EINVAL;
 	}
@@ -247,6 +389,31 @@ static int ssd1307fb_probe(struct i2c_client *client,
 		return -ENOMEM;
 	}
 
+	par = info->par;
+	par->info = info;
+	par->client = client;
+
+	par->ops = (struct ssd1307fb_ops *)of_match_device(ssd1307fb_of_match,
+							   &client->dev)->data;
+
+	par->reset = of_get_named_gpio(client->dev.of_node,
+					 "reset-gpios", 0);
+	if (!gpio_is_valid(par->reset)) {
+		ret = -EINVAL;
+		goto fb_alloc_error;
+	}
+
+	if (of_property_read_u32(node, "solomon,width", &par->width))
+		par->width = 96;
+
+	if (of_property_read_u32(node, "solomon,height", &par->height))
+		par->width = 16;
+
+	if (of_property_read_u32(node, "solomon,page-offset", &par->page_offset))
+		par->page_offset = 1;
+
+	vmem_size = par->width * par->height / 8;
+
 	vmem = devm_kzalloc(&client->dev, vmem_size, GFP_KERNEL);
 	if (!vmem) {
 		dev_err(&client->dev, "Couldn't allocate graphical memory.\n");
@@ -256,9 +423,15 @@ static int ssd1307fb_probe(struct i2c_client *client,
 
 	info->fbops = &ssd1307fb_ops;
 	info->fix = ssd1307fb_fix;
+	info->fix.line_length = par->width / 8;
 	info->fbdefio = &ssd1307fb_defio;
 
 	info->var = ssd1307fb_var;
+	info->var.xres = par->width;
+	info->var.xres_virtual = par->width;
+	info->var.yres = par->height;
+	info->var.yres_virtual = par->height;
+
 	info->var.red.length = 1;
 	info->var.red.offset = 0;
 	info->var.green.length = 1;
@@ -272,17 +445,6 @@ static int ssd1307fb_probe(struct i2c_client *client,
 
 	fb_deferred_io_init(info);
 
-	par = info->par;
-	par->info = info;
-	par->client = client;
-
-	par->reset = of_get_named_gpio(client->dev.of_node,
-					 "reset-gpios", 0);
-	if (!gpio_is_valid(par->reset)) {
-		ret = -EINVAL;
-		goto reset_oled_error;
-	}
-
 	ret = devm_gpio_request_one(&client->dev, par->reset,
 				    GPIOF_OUT_INIT_HIGH,
 				    "oled-reset");
@@ -293,23 +455,6 @@ static int ssd1307fb_probe(struct i2c_client *client,
 		goto reset_oled_error;
 	}
 
-	par->pwm = pwm_get(&client->dev, NULL);
-	if (IS_ERR(par->pwm)) {
-		dev_err(&client->dev, "Could not get PWM from device tree!\n");
-		ret = PTR_ERR(par->pwm);
-		goto pwm_error;
-	}
-
-	par->pwm_period = pwm_get_period(par->pwm);
-
-	dev_dbg(&client->dev, "Using PWM%d with a %dns period.\n", par->pwm->pwm, par->pwm_period);
-
-	ret = register_framebuffer(info);
-	if (ret) {
-		dev_err(&client->dev, "Couldn't register the framebuffer\n");
-		goto fbreg_error;
-	}
-
 	i2c_set_clientdata(client, info);
 
 	/* Reset the screen */
@@ -318,34 +463,25 @@ static int ssd1307fb_probe(struct i2c_client *client,
 	gpio_set_value(par->reset, 1);
 	udelay(4);
 
-	/* Enable the PWM */
-	pwm_config(par->pwm, par->pwm_period / 2, par->pwm_period);
-	pwm_enable(par->pwm);
-
-	/* Map column 127 of the OLED to segment 0 */
-	ret = ssd1307fb_write_cmd(client, SSD1307FB_SEG_REMAP_ON);
-	if (ret < 0) {
-		dev_err(&client->dev, "Couldn't remap the screen.\n");
-		goto remap_error;
+	if (par->ops->init) {
+		ret = par->ops->init(par);
+		if (ret)
+			goto reset_oled_error;
 	}
 
-	/* Turn on the display */
-	ret = ssd1307fb_write_cmd(client, SSD1307FB_DISPLAY_ON);
-	if (ret < 0) {
-		dev_err(&client->dev, "Couldn't turn the display on.\n");
-		goto remap_error;
+	ret = register_framebuffer(info);
+	if (ret) {
+		dev_err(&client->dev, "Couldn't register the framebuffer\n");
+		goto panel_init_error;
 	}
 
 	dev_info(&client->dev, "fb%d: %s framebuffer device registered, using %d bytes of video memory\n", info->node, info->fix.id, vmem_size);
 
 	return 0;
 
-remap_error:
-	unregister_framebuffer(info);
-	pwm_disable(par->pwm);
-fbreg_error:
-	pwm_put(par->pwm);
-pwm_error:
+panel_init_error:
+	if (par->ops->remove)
+		par->ops->remove(par);
 reset_oled_error:
 	fb_deferred_io_cleanup(info);
 fb_alloc_error:
@@ -359,8 +495,8 @@ static int ssd1307fb_remove(struct i2c_client *client)
 	struct ssd1307fb_par *par = info->par;
 
 	unregister_framebuffer(info);
-	pwm_disable(par->pwm);
-	pwm_put(par->pwm);
+	if (par->ops->remove)
+		par->ops->remove(par);
 	fb_deferred_io_cleanup(info);
 	framebuffer_release(info);
 
@@ -368,17 +504,12 @@ static int ssd1307fb_remove(struct i2c_client *client)
 }
 
 static const struct i2c_device_id ssd1307fb_i2c_id[] = {
+	{ "ssd1306fb", 0 },
 	{ "ssd1307fb", 0 },
 	{ }
 };
 MODULE_DEVICE_TABLE(i2c, ssd1307fb_i2c_id);
 
-static const struct of_device_id ssd1307fb_of_match[] = {
-	{ .compatible = "solomon,ssd1307fb-i2c" },
-	{},
-};
-MODULE_DEVICE_TABLE(of, ssd1307fb_of_match);
-
 static struct i2c_driver ssd1307fb_driver = {
 	.probe = ssd1307fb_probe,
 	.remove = ssd1307fb_remove,
-- 
1.7.10.4



From linus.walleij at stericsson.com  Mon Apr 22 05:56:05 2013
From: linus.walleij at stericsson.com (Linus Walleij)
Date: Mon, 22 Apr 2013 11:56:05 +0200
Subject: [PATCH 11/23] rtc: coh901331: add devicetree support
Message-ID: <1366624566-6510-1-git-send-email-linus.walleij@stericsson.com>

From: Linus Walleij <linus.walleij at linaro.org>

This add devicetree probe support to the COH 901 331 RTC
driver.

Cc: Alessandro Zummo <a.zummo at towertech.it>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
Hi Alessandro, I'm seeking an ACK to take this patch through
the ARM SoC tree along with the code making use of it.
---
 drivers/rtc/rtc-coh901331.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/rtc/rtc-coh901331.c b/drivers/rtc/rtc-coh901331.c
index 2d28ec1..4415b57 100644
--- a/drivers/rtc/rtc-coh901331.c
+++ b/drivers/rtc/rtc-coh901331.c
@@ -276,10 +276,16 @@ static void coh901331_shutdown(struct platform_device *pdev)
 	clk_disable_unprepare(rtap->clk);
 }
 
+static const struct of_device_id coh901331_dt_match[] = {
+	{ .compatible = "stericsson,coh901331" },
+	{},
+};
+
 static struct platform_driver coh901331_driver = {
 	.driver = {
 		.name = "rtc-coh901331",
 		.owner = THIS_MODULE,
+		.of_match_table = coh901331_dt_match,
 	},
 	.remove = __exit_p(coh901331_remove),
 	.suspend = coh901331_suspend,
-- 
1.7.11.3



From linus.walleij at stericsson.com  Mon Apr 22 05:56:16 2013
From: linus.walleij at stericsson.com (Linus Walleij)
Date: Mon, 22 Apr 2013 11:56:16 +0200
Subject: [PATCH 12/23] ARM: u300: add RTC to device tree
Message-ID: <1366624576-6544-1-git-send-email-linus.walleij@stericsson.com>

From: Linus Walleij <linus.walleij at linaro.org>

This adds the COH 901 331 RTC to the U300 device tree.

Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 arch/arm/boot/dts/ste-u300.dts | 7 +++++++
 arch/arm/mach-u300/core.c      | 2 ++
 2 files changed, 9 insertions(+)

diff --git a/arch/arm/boot/dts/ste-u300.dts b/arch/arm/boot/dts/ste-u300.dts
index b1b63bb..784e17a 100644
--- a/arch/arm/boot/dts/ste-u300.dts
+++ b/arch/arm/boot/dts/ste-u300.dts
@@ -56,6 +56,13 @@
 		interrupts = <3>;
 	};
 
+	rtc: rtc at c0017000 {
+		compatible = "stericsson,coh901331";
+		reg = <0xc0017000 0x1000>;
+		interrupt-parent = <&vicb>;
+		interrupts = <10>;
+	};
+
 	i2c0: i2c at c0004000 {
 		compatible = "st,ddci2c";
 		reg = <0xc0004000 0x1000>;
diff --git a/arch/arm/mach-u300/core.c b/arch/arm/mach-u300/core.c
index f97b65c..20d6c46 100644
--- a/arch/arm/mach-u300/core.c
+++ b/arch/arm/mach-u300/core.c
@@ -711,6 +711,8 @@ static struct of_dev_auxdata u300_auxdata_lookup[] __initdata = {
 		"u300-gpio", &u300_gpio_plat),
 	OF_DEV_AUXDATA("stericsson,coh901327", U300_WDOG_BASE,
 		"coh901327_wdog", NULL),
+	OF_DEV_AUXDATA("stericsson,coh901331", U300_RTC_BASE,
+		"rtc-coh901331", NULL),
 	OF_DEV_AUXDATA("arm,primecell", U300_UART0_BASE,
 		"uart0", &uart0_plat_data),
 	OF_DEV_AUXDATA("arm,primecell", U300_UART1_BASE,
-- 
1.7.11.3



From linus.walleij at stericsson.com  Mon Apr 22 05:57:14 2013
From: linus.walleij at stericsson.com (Linus Walleij)
Date: Mon, 22 Apr 2013 11:57:14 +0200
Subject: [PATCH 13/23] regulator: ab3100: refactor probe to use IDs
Message-ID: <1366624634-6579-1-git-send-email-linus.walleij@stericsson.com>

From: Linus Walleij <linus.walleij at linaro.org>

This refactors the AB3100 regulator probe to use regulator IDs
and pass this to a separate registration function. This works
much smoother when migrating to device tree, as we can use a
match table with this regulator ID encoded in the .driver_data.

Cc: Mark Brown <broonie at kernel.org>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
Hi Mark, seeking an ACK on this to take it through the
ARM SoC tree.
---
 drivers/regulator/ab3100.c | 90 ++++++++++++++++++++++++++++------------------
 1 file changed, 55 insertions(+), 35 deletions(-)

diff --git a/drivers/regulator/ab3100.c b/drivers/regulator/ab3100.c
index 111ec69..740735d 100644
--- a/drivers/regulator/ab3100.c
+++ b/drivers/regulator/ab3100.c
@@ -488,6 +488,58 @@ ab3100_regulator_desc[AB3100_NUM_REGULATORS] = {
 	},
 };
 
+static int ab3100_regulator_register(struct platform_device *pdev,
+				     struct ab3100_platform_data *plfdata,
+				     int id)
+{
+	struct regulator_desc *desc;
+	struct ab3100_regulator *reg;
+	struct regulator_dev *rdev;
+	struct regulator_config config = { };
+	int err, i;
+
+	for (i = 0; i < AB3100_NUM_REGULATORS; i++) {
+		desc = &ab3100_regulator_desc[i];
+		if (desc->id == id)
+			break;
+	}
+	if (desc->id != id)
+		return -ENODEV;
+
+	/* Same index used for this array */
+	reg = &ab3100_regulators[i];
+
+	/*
+	 * Initialize per-regulator struct.
+	 * Inherit platform data, this comes down from the
+	 * i2c boarddata, from the machine. So if you want to
+	 * see what it looks like for a certain machine, go
+	 * into the machine I2C setup.
+	 */
+	reg->dev = &pdev->dev;
+	if (plfdata) {
+		/* This will be replaced by device tree data */
+		reg->plfdata = plfdata;
+		config.init_data = &plfdata->reg_constraints[i];
+	}
+	config.dev = &pdev->dev;
+	config.driver_data = reg;
+
+	rdev = regulator_register(desc, &config);
+	if (IS_ERR(rdev)) {
+		err = PTR_ERR(rdev);
+		dev_err(&pdev->dev,
+			"%s: failed to register regulator %s err %d\n",
+			__func__, desc->name,
+			err);
+		return err;
+	}
+
+	/* Then set a pointer back to the registered regulator */
+	reg->rdev = rdev;
+	return 0;
+}
+
 /*
  * NOTE: the following functions are regulators pluralis - it is the
  * binding to the AB3100 core driver and the parent platform device
@@ -497,7 +549,6 @@ ab3100_regulator_desc[AB3100_NUM_REGULATORS] = {
 static int ab3100_regulators_probe(struct platform_device *pdev)
 {
 	struct ab3100_platform_data *plfdata = pdev->dev.platform_data;
-	struct regulator_config config = { };
 	int err = 0;
 	u8 data;
 	int i;
@@ -530,42 +581,11 @@ static int ab3100_regulators_probe(struct platform_device *pdev)
 
 	/* Register the regulators */
 	for (i = 0; i < AB3100_NUM_REGULATORS; i++) {
-		struct ab3100_regulator *reg = &ab3100_regulators[i];
-		struct regulator_dev *rdev;
-
-		/*
-		 * Initialize per-regulator struct.
-		 * Inherit platform data, this comes down from the
-		 * i2c boarddata, from the machine. So if you want to
-		 * see what it looks like for a certain machine, go
-		 * into the machine I2C setup.
-		 */
-		reg->dev = &pdev->dev;
-		reg->plfdata = plfdata;
-
-		config.dev = &pdev->dev;
-		config.driver_data = reg;
-		config.init_data = &plfdata->reg_constraints[i];
+		struct regulator_desc *desc = &ab3100_regulator_desc[i];
 
-		/*
-		 * Register the regulator, pass around
-		 * the ab3100_regulator struct
-		 */
-		rdev = regulator_register(&ab3100_regulator_desc[i], &config);
-		if (IS_ERR(rdev)) {
-			err = PTR_ERR(rdev);
-			dev_err(&pdev->dev,
-				"%s: failed to register regulator %s err %d\n",
-				__func__, ab3100_regulator_desc[i].name,
-				err);
-			/* remove the already registered regulators */
-			while (--i >= 0)
-				regulator_unregister(ab3100_regulators[i].rdev);
+		err = ab3100_regulator_register(pdev, plfdata, desc->id);
+		if (err)
 			return err;
-		}
-
-		/* Then set a pointer back to the registered regulator */
-		reg->rdev = rdev;
 	}
 
 	return 0;
-- 
1.7.11.3



From linus.walleij at stericsson.com  Mon Apr 22 05:57:25 2013
From: linus.walleij at stericsson.com (Linus Walleij)
Date: Mon, 22 Apr 2013 11:57:25 +0200
Subject: [PATCH 14/23] regulator: ab3100: device tree support
Message-ID: <1366624645-6614-1-git-send-email-linus.walleij@stericsson.com>

From: Linus Walleij <linus.walleij at linaro.org>

This implements device tree support for the AB3100 regulators
driver. The initial settings are moved out of platform data
and into the driver for the device tree case, as it appears
that there is no way to supply this as AUXDATA for an I2C
device. The style and bindings are heavily inspired by
Lee Jones' style for AB8500.

Cc: Lee Jones <lee.jones at linaro.org>
Cc: Mark Brown <broonie at kernel.org>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
Hi Mark, seeking an ACK on this to take it through the ARM
SoC tree.
---
 drivers/mfd/ab3100-core.c  |   1 +
 drivers/regulator/ab3100.c | 123 ++++++++++++++++++++++++++++++++++++++++++---
 2 files changed, 118 insertions(+), 6 deletions(-)

diff --git a/drivers/mfd/ab3100-core.c b/drivers/mfd/ab3100-core.c
index 2ec7725..a9bb140 100644
--- a/drivers/mfd/ab3100-core.c
+++ b/drivers/mfd/ab3100-core.c
@@ -753,6 +753,7 @@ static struct mfd_cell ab3100_devs[] = {
 	},
 	{
 		.name = "ab3100-regulators",
+		.of_compatible = "stericsson,ab3100-regulators",
 		.id = -1,
 	},
 	{
diff --git a/drivers/regulator/ab3100.c b/drivers/regulator/ab3100.c
index 740735d..be1e6ad 100644
--- a/drivers/regulator/ab3100.c
+++ b/drivers/regulator/ab3100.c
@@ -17,6 +17,8 @@
 #include <linux/regulator/driver.h>
 #include <linux/mfd/ab3100.h>
 #include <linux/mfd/abx500.h>
+#include <linux/of.h>
+#include <linux/regulator/of_regulator.h>
 
 /* LDO registers and some handy masking definitions for AB3100 */
 #define AB3100_LDO_A		0x40
@@ -345,7 +347,11 @@ static int ab3100_get_voltage_regulator_external(struct regulator_dev *reg)
 {
 	struct ab3100_regulator *abreg = rdev_get_drvdata(reg);
 
-	return abreg->plfdata->external_voltage;
+	if (abreg->plfdata)
+		return abreg->plfdata->external_voltage;
+	else
+		/* TODO: encode external voltage into device tree */
+		return 0;
 }
 
 static struct regulator_ops regulator_ops_fixed = {
@@ -490,6 +496,8 @@ ab3100_regulator_desc[AB3100_NUM_REGULATORS] = {
 
 static int ab3100_regulator_register(struct platform_device *pdev,
 				     struct ab3100_platform_data *plfdata,
+				     struct regulator_init_data *init_data,
+				     struct device_node *np,
 				     int id)
 {
 	struct regulator_desc *desc;
@@ -518,9 +526,11 @@ static int ab3100_regulator_register(struct platform_device *pdev,
 	 */
 	reg->dev = &pdev->dev;
 	if (plfdata) {
-		/* This will be replaced by device tree data */
 		reg->plfdata = plfdata;
 		config.init_data = &plfdata->reg_constraints[i];
+	} else if (np) {
+		config.of_node = np;
+		config.init_data = init_data;
 	}
 	config.dev = &pdev->dev;
 	config.driver_data = reg;
@@ -540,15 +550,103 @@ static int ab3100_regulator_register(struct platform_device *pdev,
 	return 0;
 }
 
+static struct of_regulator_match ab3100_regulator_matches[] = {
+	{ .name = "ab3100_ldo_a", .driver_data = (void *) AB3100_LDO_A, },
+	{ .name = "ab3100_ldo_c", .driver_data = (void *) AB3100_LDO_C, },
+	{ .name = "ab3100_ldo_d", .driver_data = (void *) AB3100_LDO_D, },
+	{ .name = "ab3100_ldo_e", .driver_data = (void *) AB3100_LDO_E, },
+	{ .name = "ab3100_ldo_f", .driver_data = (void *) AB3100_LDO_F },
+	{ .name = "ab3100_ldo_g", .driver_data = (void *) AB3100_LDO_G },
+	{ .name = "ab3100_ldo_h", .driver_data = (void *) AB3100_LDO_H },
+	{ .name = "ab3100_ldo_k", .driver_data = (void *) AB3100_LDO_K },
+	{ .name = "ab3100_ext", .driver_data = (void *) AB3100_LDO_EXT },
+	{ .name = "ab3100_buck", .driver_data = (void *) AB3100_BUCK },
+};
+
 /*
- * NOTE: the following functions are regulators pluralis - it is the
- * binding to the AB3100 core driver and the parent platform device
- * for all the different regulators.
+ * Initial settings of ab3100 registers.
+ * Common for below LDO regulator settings are that
+ * bit 7-5 controls voltage. Bit 4 turns regulator ON(1) or OFF(0).
+ * Bit 3-2 controls sleep enable and bit 1-0 controls sleep mode.
  */
+/* LDO_A 0x16: 2.75V, ON, SLEEP_A, SLEEP OFF GND */
+#define LDO_A_SETTING		0x16
+/* LDO_C 0x10: 2.65V, ON, SLEEP_A or B, SLEEP full power */
+#define LDO_C_SETTING		0x10
+/* LDO_D 0x10: 2.65V, ON, sleep mode not used */
+#define LDO_D_SETTING		0x10
+/* LDO_E 0x10: 1.8V, ON, SLEEP_A or B, SLEEP full power */
+#define LDO_E_SETTING		0x10
+/* LDO_E SLEEP 0x00: 1.8V, not used, SLEEP_A or B, not used */
+#define LDO_E_SLEEP_SETTING	0x00
+/* LDO_F 0xD0: 2.5V, ON, SLEEP_A or B, SLEEP full power */
+#define LDO_F_SETTING		0xD0
+/* LDO_G 0x00: 2.85V, OFF, SLEEP_A or B, SLEEP full power */
+#define LDO_G_SETTING		0x00
+/* LDO_H 0x18: 2.75V, ON, SLEEP_B, SLEEP full power */
+#define LDO_H_SETTING		0x18
+/* LDO_K 0x00: 2.75V, OFF, SLEEP_A or B, SLEEP full power */
+#define LDO_K_SETTING		0x00
+/* LDO_EXT 0x00: Voltage not set, OFF, not used, not used */
+#define LDO_EXT_SETTING		0x00
+/* BUCK 0x7D: 1.2V, ON, SLEEP_A and B, SLEEP low power */
+#define BUCK_SETTING	0x7D
+/* BUCK SLEEP 0xAC: 1.05V, Not used, SLEEP_A and B, Not used */
+#define BUCK_SLEEP_SETTING	0xAC
+
+static const u8 ab3100_reg_initvals[] = {
+	LDO_A_SETTING,
+	LDO_C_SETTING,
+	LDO_E_SETTING,
+	LDO_E_SLEEP_SETTING,
+	LDO_F_SETTING,
+	LDO_G_SETTING,
+	LDO_H_SETTING,
+	LDO_K_SETTING,
+	LDO_EXT_SETTING,
+	BUCK_SETTING,
+	BUCK_SLEEP_SETTING,
+	LDO_D_SETTING,
+};
+
+static int
+ab3100_regulator_of_probe(struct platform_device *pdev, struct device_node *np)
+{
+	int err, i;
+
+	/*
+	 * Set up the regulator registers, as was previously done with
+	 * platform data.
+	 */
+	/* Set up regulators */
+	for (i = 0; i < ARRAY_SIZE(ab3100_reg_init_order); i++) {
+		err = abx500_set_register_interruptible(&pdev->dev, 0,
+					ab3100_reg_init_order[i],
+					ab3100_reg_initvals[i]);
+		if (err) {
+			dev_err(&pdev->dev, "regulator initialization failed with error %d\n",
+				err);
+			return err;
+		}
+	}
+
+	for (i = 0; i < ARRAY_SIZE(ab3100_regulator_matches); i++) {
+		err = ab3100_regulator_register(
+			pdev, NULL, ab3100_regulator_matches[i].init_data,
+			ab3100_regulator_matches[i].of_node,
+			(int) ab3100_regulator_matches[i].driver_data);
+		if (err)
+			return err;
+	}
+
+	return 0;
+}
+
 
 static int ab3100_regulators_probe(struct platform_device *pdev)
 {
 	struct ab3100_platform_data *plfdata = pdev->dev.platform_data;
+	struct device_node *np = pdev->dev.of_node;
 	int err = 0;
 	u8 data;
 	int i;
@@ -567,6 +665,18 @@ static int ab3100_regulators_probe(struct platform_device *pdev)
 		dev_notice(&pdev->dev,
 			   "chip is in inactive mode (Cold start)\n");
 
+	if (np) {
+		err = of_regulator_match(&pdev->dev, np,
+					 ab3100_regulator_matches,
+					 ARRAY_SIZE(ab3100_regulator_matches));
+		if (err < 0) {
+			dev_err(&pdev->dev,
+				"Error parsing regulator init data: %d\n", err);
+			return err;
+		}
+		return ab3100_regulator_of_probe(pdev, np);
+	}
+
 	/* Set up regulators */
 	for (i = 0; i < ARRAY_SIZE(ab3100_reg_init_order); i++) {
 		err = abx500_set_register_interruptible(&pdev->dev, 0,
@@ -583,7 +693,8 @@ static int ab3100_regulators_probe(struct platform_device *pdev)
 	for (i = 0; i < AB3100_NUM_REGULATORS; i++) {
 		struct regulator_desc *desc = &ab3100_regulator_desc[i];
 
-		err = ab3100_regulator_register(pdev, plfdata, desc->id);
+		err = ab3100_regulator_register(pdev, plfdata, NULL, NULL,
+						desc->id);
 		if (err)
 			return err;
 	}
-- 
1.7.11.3



From linus.walleij at stericsson.com  Mon Apr 22 05:57:36 2013
From: linus.walleij at stericsson.com (Linus Walleij)
Date: Mon, 22 Apr 2013 11:57:36 +0200
Subject: [PATCH 15/23] ARM: u300: set up board power from device tree
Message-ID: <1366624656-6648-1-git-send-email-linus.walleij@stericsson.com>

From: Linus Walleij <linus.walleij at linaro.org>

This adds support for setting up the board power from the
device tree on the U300. We use a board-specific node in the
device tree for the S365 board and bind a regulator for the
board power to this node.

Cc: Mark Brown <broonie at kernel.org>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
Hi Mark, this was especially tricky due to the absence of a
function to get a named regulator without a device node. After
some cleverness introducing a node for the board akin to the
solution I did for Nomadik, this seems to be an acceptable way
forward, any other suggestions welcome.
---
 Documentation/devicetree/bindings/arm/ste-u300.txt | 13 +++++++
 arch/arm/mach-u300/regulator.c                     | 42 ++++++++++++++++++++--
 2 files changed, 52 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/ste-u300.txt b/Documentation/devicetree/bindings/arm/ste-u300.txt
index 222dca5..cd9001a 100644
--- a/Documentation/devicetree/bindings/arm/ste-u300.txt
+++ b/Documentation/devicetree/bindings/arm/ste-u300.txt
@@ -7,3 +7,16 @@ or board power regulator supplies.
 Required root node property:
 
 compatible="stericsson,u300";
+
+Boards with the U300 SoC include:
+
+S365 "Small Board U365":
+
+Required node: s365
+
+Example:
+
+s365 {
+	compatible = "stericsson,s365";
+	vana15-supply = <&ab3100_ldo_d_reg>;
+};
diff --git a/arch/arm/mach-u300/regulator.c b/arch/arm/mach-u300/regulator.c
index 9c53f01..8a67dc6 100644
--- a/arch/arm/mach-u300/regulator.c
+++ b/arch/arm/mach-u300/regulator.c
@@ -10,9 +10,14 @@
 #include <linux/device.h>
 #include <linux/signal.h>
 #include <linux/err.h>
+#include <linux/of.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/regulator/machine.h>
 #include <linux/regulator/consumer.h>
 /* Those are just for writing in syscon */
 #include <linux/io.h>
+#include <asm/mach-types.h>
 #include <mach/hardware.h>
 #include <mach/syscon.h>
 
@@ -47,13 +52,17 @@ void u300_pm_poweroff(void)
 /*
  * Hog the regulators needed to power up the board.
  */
-static int __init u300_init_boardpower(void)
+static int __init __u300_init_boardpower(struct platform_device *pdev)
 {
 	int err;
 	u32 val;
 
 	pr_info("U300: setting up board power\n");
-	main_power_15 = regulator_get(NULL, "vana15");
+	if (pdev)
+		main_power_15 = regulator_get(&pdev->dev, "vana15");
+	else
+		main_power_15 = regulator_get(NULL, "vana15");
+
 	if (IS_ERR(main_power_15)) {
 		pr_err("could not get vana15");
 		return PTR_ERR(main_power_15);
@@ -82,7 +91,34 @@ static int __init u300_init_boardpower(void)
 	return 0;
 }
 
+static int __init s365_board_probe(struct platform_device *pdev)
+{
+	return __u300_init_boardpower(pdev);
+}
+
+static const struct of_device_id s365_board_match[] = {
+	{ .compatible = "stericsson,s365" },
+	{},
+};
+
+static struct platform_driver s365_board_driver = {
+	.driver		= {
+		.name   = "s365-board",
+		.owner  = THIS_MODULE,
+		.of_match_table = s365_board_match,
+	},
+};
+
 /*
  * So at module init time we hog the regulator!
  */
-module_init(u300_init_boardpower);
+static int __init u300_init_boardpower(void)
+{
+	if (of_have_populated_dt())
+		return platform_driver_probe(&s365_board_driver,
+					     s365_board_probe);
+	/* Only call this on non-DT boots */
+	return __u300_init_boardpower(NULL);
+}
+
+device_initcall(u300_init_boardpower);
-- 
1.7.11.3



From rogerq at ti.com  Mon Apr 22 05:57:53 2013
From: rogerq at ti.com (Roger Quadros)
Date: Mon, 22 Apr 2013 12:57:53 +0300
Subject: [PATCH] ARM: OMAP2+: omap-usb-host: clean up pin mux setup code
Message-ID: <1366624673-2684-1-git-send-email-rogerq@ti.com>

The USB host pins are named quite differently between OMAP3 and
OMAP4+ SoCs. To make this managable in code, we create a pin mapping
table (pin_names) that maps pin function to pin name.

This pin mapping table is populated at runtime based on a pin
name template. Templates are provided for OMAP3 and 4 SoCs.

The setup_io_mux() function uses the pin mapping table to
setup the pin mux.

The resulting code is a lot more clean, manageable and scalable.

Signed-off-by: Roger Quadros <rogerq at ti.com>
---
 arch/arm/mach-omap2/usb-host.c |  648 ++++++++++++++--------------------------
 1 files changed, 225 insertions(+), 423 deletions(-)

diff --git a/arch/arm/mach-omap2/usb-host.c b/arch/arm/mach-omap2/usb-host.c
index aa27d7f..86cafee 100644
--- a/arch/arm/mach-omap2/usb-host.c
+++ b/arch/arm/mach-omap2/usb-host.c
@@ -10,6 +10,7 @@
  *
  * Generalization by:
  * Felipe Balbi <balbi at ti.com>
+ * Roger Quadros <rogerq at 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
@@ -41,439 +42,239 @@
 #define	USBHS_UHH_HWMODNAME	"usb_host_hs"
 #define USBHS_TLL_HWMODNAME	"usb_tll_hs"
 
-/* MUX settings for EHCI pins */
+#define MAX_PIN_NAME	20
+
+/* all possible USB pin configurations for one port */
+enum usbhs_pin_function {
+	/* EHCI PHY mode pins */
+	PHY_STP, PHY_CLK, PHY_DIR, PHY_NXT, PHY_DAT0, PHY_DAT1,
+	PHY_DAT2, PHY_DAT3, PHY_DAT4, PHY_DAT5, PHY_DAT6, PHY_DAT7,
+
+	/* EHCI TLL mode pins */
+	TLL_STP, TLL_CLK, TLL_DIR, TLL_NXT, TLL_DAT0, TLL_DAT1,
+	TLL_DAT2, TLL_DAT3, TLL_DAT4, TLL_DAT5, TLL_DAT6, TLL_DAT7,
+
+	/* OHCI mode pins */
+	RXDP, RXDM, RXRCV, TXEN, TXSE0, TXDAT,
+
+	/* Terminator */
+	MAX_PINS,
+};
+
 /*
- * setup_ehci_io_mux - initialize IO pad mux for USBHOST
+ * NOTE: In the pin templates, the pin names must contain %d
+ * where port number is to be inserted.
+ * e.g. hsusb%d_stp becomes hsusb1_stp
  */
-static void __init setup_ehci_io_mux(const enum usbhs_omap_port_mode *port_mode)
-{
-	switch (port_mode[0]) {
-	case OMAP_EHCI_PORT_MODE_PHY:
-		omap_mux_init_signal("hsusb1_stp", OMAP_PIN_OUTPUT);
-		omap_mux_init_signal("hsusb1_clk", OMAP_PIN_OUTPUT);
-		omap_mux_init_signal("hsusb1_dir", OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("hsusb1_nxt", OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("hsusb1_data0", OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("hsusb1_data1", OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("hsusb1_data2", OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("hsusb1_data3", OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("hsusb1_data4", OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("hsusb1_data5", OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("hsusb1_data6", OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("hsusb1_data7", OMAP_PIN_INPUT_PULLDOWN);
-		break;
-	case OMAP_EHCI_PORT_MODE_TLL:
-		omap_mux_init_signal("hsusb1_tll_stp",
-			OMAP_PIN_INPUT_PULLUP);
-		omap_mux_init_signal("hsusb1_tll_clk",
-			OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("hsusb1_tll_dir",
-			OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("hsusb1_tll_nxt",
-			OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("hsusb1_tll_data0",
-			OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("hsusb1_tll_data1",
-			OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("hsusb1_tll_data2",
-			OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("hsusb1_tll_data3",
-			OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("hsusb1_tll_data4",
-			OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("hsusb1_tll_data5",
-			OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("hsusb1_tll_data6",
-			OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("hsusb1_tll_data7",
-			OMAP_PIN_INPUT_PULLDOWN);
-		break;
-	case OMAP_USBHS_PORT_MODE_UNUSED:
-		/* FALLTHROUGH */
-	default:
-		break;
-	}
 
-	switch (port_mode[1]) {
-	case OMAP_EHCI_PORT_MODE_PHY:
-		omap_mux_init_signal("hsusb2_stp", OMAP_PIN_OUTPUT);
-		omap_mux_init_signal("hsusb2_clk", OMAP_PIN_OUTPUT);
-		omap_mux_init_signal("hsusb2_dir", OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("hsusb2_nxt", OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("hsusb2_data0",
-			OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("hsusb2_data1",
-			OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("hsusb2_data2",
-			OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("hsusb2_data3",
-			OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("hsusb2_data4",
-			OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("hsusb2_data5",
-			OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("hsusb2_data6",
-			OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("hsusb2_data7",
-			OMAP_PIN_INPUT_PULLDOWN);
-		break;
-	case OMAP_EHCI_PORT_MODE_TLL:
-		omap_mux_init_signal("hsusb2_tll_stp",
-			OMAP_PIN_INPUT_PULLUP);
-		omap_mux_init_signal("hsusb2_tll_clk",
-			OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("hsusb2_tll_dir",
-			OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("hsusb2_tll_nxt",
-			OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("hsusb2_tll_data0",
-			OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("hsusb2_tll_data1",
-			OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("hsusb2_tll_data2",
-			OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("hsusb2_tll_data3",
-			OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("hsusb2_tll_data4",
-			OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("hsusb2_tll_data5",
-			OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("hsusb2_tll_data6",
-			OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("hsusb2_tll_data7",
-			OMAP_PIN_INPUT_PULLDOWN);
-		break;
-	case OMAP_USBHS_PORT_MODE_UNUSED:
-		/* FALLTHROUGH */
-	default:
-		break;
-	}
+/* Pin template for OMAP3 SoCs */
+static const char __initdata omap3_pin_template[MAX_PINS][MAX_PIN_NAME] = {
+	[PHY_STP] = "hsusb%d_stp",
+	[PHY_CLK] = "hsusb%d_clk",
+	[PHY_DIR] = "hsusb%d_dir",
+	[PHY_NXT] = "hsusb%d_nxt",
+	[PHY_DAT0] = "hsusb%d_data0",
+	[PHY_DAT1] = "hsusb%d_data1",
+	[PHY_DAT2] = "hsusb%d_data2",
+	[PHY_DAT3] = "hsusb%d_data3",
+	[PHY_DAT4] = "hsusb%d_data4",
+	[PHY_DAT5] = "hsusb%d_data5",
+	[PHY_DAT6] = "hsusb%d_data6",
+	[PHY_DAT7] = "hsusb%d_data7",
+
+	[TLL_STP] = "hsusb%d_tll_stp",
+	[TLL_CLK] = "hsusb%d_tll_clk",
+	[TLL_DIR] = "hsusb%d_tll_dir",
+	[TLL_NXT] = "hsusb%d_tll_nxt",
+	[TLL_DAT0] = "hsusb%d_tll_data0",
+	[TLL_DAT1] = "hsusb%d_tll_data1",
+	[TLL_DAT2] = "hsusb%d_tll_data2",
+	[TLL_DAT3] = "hsusb%d_tll_data3",
+	[TLL_DAT4] = "hsusb%d_tll_data4",
+	[TLL_DAT5] = "hsusb%d_tll_data5",
+	[TLL_DAT6] = "hsusb%d_tll_data6",
+	[TLL_DAT7] = "hsusb%d_tll_data7",
+
+	[RXDP] = "mm%d_rxdp",
+	[RXDM] = "mm%d_rxdm",
+	[RXRCV] = "mm%d_rxrcv",
+	[TXEN] = "mm%d_txen_n",
+	[TXSE0] = "mm%d_txse0",
+	[TXDAT] = "mm%d_txdat",
+};
 
-	switch (port_mode[2]) {
-	case OMAP_EHCI_PORT_MODE_PHY:
-		printk(KERN_WARNING "Port3 can't be used in PHY mode\n");
-		break;
-	case OMAP_EHCI_PORT_MODE_TLL:
-		omap_mux_init_signal("hsusb3_tll_stp",
-			OMAP_PIN_INPUT_PULLUP);
-		omap_mux_init_signal("hsusb3_tll_clk",
-			OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("hsusb3_tll_dir",
-			OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("hsusb3_tll_nxt",
-			OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("hsusb3_tll_data0",
-			OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("hsusb3_tll_data1",
-			OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("hsusb3_tll_data2",
-			OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("hsusb3_tll_data3",
-			OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("hsusb3_tll_data4",
-			OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("hsusb3_tll_data5",
-			OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("hsusb3_tll_data6",
-			OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("hsusb3_tll_data7",
-			OMAP_PIN_INPUT_PULLDOWN);
-		break;
-	case OMAP_USBHS_PORT_MODE_UNUSED:
-		/* FALLTHROUGH */
-	default:
-		break;
-	}
+/* Pin template for OMAP4+ SoCs */
+static const char __initdata omap4_pin_template[MAX_PINS][MAX_PIN_NAME] = {
+	[PHY_STP] = "usbb%d_ulpiphy_stp",
+	[PHY_CLK] = "usbb%d_ulpiphy_clk",
+	[PHY_DIR] = "usbb%d_ulpiphy_dir",
+	[PHY_NXT] = "usbb%d_ulpiphy_nxt",
+	[PHY_DAT0] = "usbb%d_ulpiphy_dat0",
+	[PHY_DAT1] = "usbb%d_ulpiphy_dat1",
+	[PHY_DAT2] = "usbb%d_ulpiphy_dat2",
+	[PHY_DAT3] = "usbb%d_ulpiphy_dat3",
+	[PHY_DAT4] = "usbb%d_ulpiphy_dat4",
+	[PHY_DAT5] = "usbb%d_ulpiphy_dat5",
+	[PHY_DAT6] = "usbb%d_ulpiphy_dat6",
+	[PHY_DAT7] = "usbb%d_ulpiphy_dat7",
+
+	[TLL_STP] = "usbb%d_ulpitll_stp",
+	[TLL_CLK] = "usbb%d_ulpitll_clk",
+	[TLL_DIR] = "usbb%d_ulpitll_dir",
+	[TLL_NXT] = "usbb%d_ulpitll_nxt",
+	[TLL_DAT0] = "usbb%d_ulpitll_dat0",
+	[TLL_DAT1] = "usbb%d_ulpitll_dat1",
+	[TLL_DAT2] = "usbb%d_ulpitll_dat2",
+	[TLL_DAT3] = "usbb%d_ulpitll_dat3",
+	[TLL_DAT4] = "usbb%d_ulpitll_dat4",
+	[TLL_DAT5] = "usbb%d_ulpitll_dat5",
+	[TLL_DAT6] = "usbb%d_ulpitll_dat6",
+	[TLL_DAT7] = "usbb%d_ulpitll_dat7",
+
+	[RXDP] = "usbb%d_mm_rxdp",
+	[RXDM] = "usbb%d_mm_rxdm",
+	[RXRCV] = "usbb%d_mm_rxrcv",
+	[TXEN] = "usbb%d_mm_txen",
+	[TXSE0] = "usbb%d_mm_txse0",
+	[TXDAT] = "usbb%d_mm_txdat",
+};
 
-	return;
+/**
+ * populate_pin_names - populate the pin names based on the given template
+ * @template: the name template for the pins
+ * @pin_names: the table where the pin names will be stored
+ *
+ * This function populates the pin names into the pin_names table.
+ */
+static void __init populate_pin_names(const char (*template)[MAX_PIN_NAME],
+				char (*pin_names)[MAX_PINS][MAX_PIN_NAME])
+{
+	int i, j;
+
+	for (i = 0; i < OMAP3_HS_USB_PORTS; i++) {
+		for (j = 0; j < MAX_PINS; j++) {
+			/* template contains %d */
+			snprintf(pin_names[i][j], MAX_PIN_NAME,
+						template[j], i + 1);
+		}
+	}
 }
 
+/**
+ * usbhs_setup_io_mux - Setup IO mux for USB Host pins based on port_mode
+ * @port_mode: port mode list
+ * @template: pin name template for the SoC
+ */
 static
-void __init setup_4430ehci_io_mux(const enum usbhs_omap_port_mode *port_mode)
+void __init usbhs_setup_io_mux(const enum usbhs_omap_port_mode *port_mode,
+					const char (*template)[MAX_PIN_NAME])
 {
-	switch (port_mode[0]) {
-	case OMAP_EHCI_PORT_MODE_PHY:
-		omap_mux_init_signal("usbb1_ulpiphy_stp",
-			OMAP_PIN_OUTPUT);
-		omap_mux_init_signal("usbb1_ulpiphy_clk",
-			OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("usbb1_ulpiphy_dir",
-			OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("usbb1_ulpiphy_nxt",
-			OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("usbb1_ulpiphy_dat0",
-			OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("usbb1_ulpiphy_dat1",
-			OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("usbb1_ulpiphy_dat2",
-			OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("usbb1_ulpiphy_dat3",
-			OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("usbb1_ulpiphy_dat4",
-			OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("usbb1_ulpiphy_dat5",
-			OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("usbb1_ulpiphy_dat6",
-			OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("usbb1_ulpiphy_dat7",
-			OMAP_PIN_INPUT_PULLDOWN);
-			break;
-	case OMAP_EHCI_PORT_MODE_TLL:
-		omap_mux_init_signal("usbb1_ulpitll_stp",
-			OMAP_PIN_INPUT_PULLUP);
-		omap_mux_init_signal("usbb1_ulpitll_clk",
-			OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("usbb1_ulpitll_dir",
-			OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("usbb1_ulpitll_nxt",
-			OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("usbb1_ulpitll_dat0",
-			OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("usbb1_ulpitll_dat1",
-			OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("usbb1_ulpitll_dat2",
-			OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("usbb1_ulpitll_dat3",
-			OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("usbb1_ulpitll_dat4",
-			OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("usbb1_ulpitll_dat5",
-			OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("usbb1_ulpitll_dat6",
-			OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("usbb1_ulpitll_dat7",
-			OMAP_PIN_INPUT_PULLDOWN);
-			break;
-	case OMAP_USBHS_PORT_MODE_UNUSED:
-	default:
-			break;
+	int i;
+
+	char (*pin_names)[MAX_PINS][MAX_PIN_NAME];
+
+	pin_names  = kmalloc(sizeof(char [OMAP3_HS_USB_PORTS][MAX_PINS][MAX_PIN_NAME]),
+						GFP_KERNEL);
+	if (!pin_names) {
+		pr_err("%s: memory allocation failed\n", __func__);
+		return;
 	}
-	switch (port_mode[1]) {
-	case OMAP_EHCI_PORT_MODE_PHY:
-		omap_mux_init_signal("usbb2_ulpiphy_stp",
-			OMAP_PIN_OUTPUT);
-		omap_mux_init_signal("usbb2_ulpiphy_clk",
-			OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("usbb2_ulpiphy_dir",
-			OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("usbb2_ulpiphy_nxt",
-			OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("usbb2_ulpiphy_dat0",
-			OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("usbb2_ulpiphy_dat1",
-			OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("usbb2_ulpiphy_dat2",
-			OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("usbb2_ulpiphy_dat3",
-			OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("usbb2_ulpiphy_dat4",
-			OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("usbb2_ulpiphy_dat5",
-			OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("usbb2_ulpiphy_dat6",
-			OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("usbb2_ulpiphy_dat7",
-			OMAP_PIN_INPUT_PULLDOWN);
-			break;
-	case OMAP_EHCI_PORT_MODE_TLL:
-		omap_mux_init_signal("usbb2_ulpitll_stp",
-			OMAP_PIN_INPUT_PULLUP);
-		omap_mux_init_signal("usbb2_ulpitll_clk",
-			OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("usbb2_ulpitll_dir",
-			OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("usbb2_ulpitll_nxt",
-			OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("usbb2_ulpitll_dat0",
-			OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("usbb2_ulpitll_dat1",
-			OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("usbb2_ulpitll_dat2",
-			OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("usbb2_ulpitll_dat3",
-			OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("usbb2_ulpitll_dat4",
-			OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("usbb2_ulpitll_dat5",
-			OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("usbb2_ulpitll_dat6",
-			OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("usbb2_ulpitll_dat7",
-			OMAP_PIN_INPUT_PULLDOWN);
+
+	populate_pin_names(template, pin_names);
+
+	for (i = 0; i < OMAP3_HS_USB_PORTS; i++) {
+		switch (port_mode[i]) {
+		/* EHCI cases */
+		case OMAP_EHCI_PORT_MODE_PHY:
+			omap_mux_init_signal(pin_names[i][PHY_STP],
+				OMAP_PIN_OUTPUT);
+			omap_mux_init_signal(pin_names[i][PHY_CLK],
+				OMAP_PIN_INPUT_PULLDOWN);
+			omap_mux_init_signal(pin_names[i][PHY_DIR],
+				OMAP_PIN_INPUT_PULLDOWN);
+			omap_mux_init_signal(pin_names[i][PHY_NXT],
+				OMAP_PIN_INPUT_PULLDOWN);
+			omap_mux_init_signal(pin_names[i][PHY_DAT0],
+				OMAP_PIN_INPUT_PULLDOWN);
+			omap_mux_init_signal(pin_names[i][PHY_DAT1],
+				OMAP_PIN_INPUT_PULLDOWN);
+			omap_mux_init_signal(pin_names[i][PHY_DAT2],
+				OMAP_PIN_INPUT_PULLDOWN);
+			omap_mux_init_signal(pin_names[i][PHY_DAT3],
+				OMAP_PIN_INPUT_PULLDOWN);
+			omap_mux_init_signal(pin_names[i][PHY_DAT4],
+				OMAP_PIN_INPUT_PULLDOWN);
+			omap_mux_init_signal(pin_names[i][PHY_DAT5],
+				OMAP_PIN_INPUT_PULLDOWN);
+			omap_mux_init_signal(pin_names[i][PHY_DAT6],
+				OMAP_PIN_INPUT_PULLDOWN);
+			omap_mux_init_signal(pin_names[i][PHY_DAT7],
+				OMAP_PIN_INPUT_PULLDOWN);
 			break;
-	case OMAP_USBHS_PORT_MODE_UNUSED:
-	default:
+
+		case OMAP_EHCI_PORT_MODE_TLL:
+			omap_mux_init_signal(pin_names[i][TLL_STP],
+				OMAP_PIN_OUTPUT);
+			omap_mux_init_signal(pin_names[i][TLL_CLK],
+				OMAP_PIN_INPUT_PULLDOWN);
+			omap_mux_init_signal(pin_names[i][TLL_DIR],
+				OMAP_PIN_INPUT_PULLDOWN);
+			omap_mux_init_signal(pin_names[i][TLL_NXT],
+				OMAP_PIN_INPUT_PULLDOWN);
+			omap_mux_init_signal(pin_names[i][TLL_DAT0],
+				OMAP_PIN_INPUT_PULLDOWN);
+			omap_mux_init_signal(pin_names[i][TLL_DAT1],
+				OMAP_PIN_INPUT_PULLDOWN);
+			omap_mux_init_signal(pin_names[i][TLL_DAT2],
+				OMAP_PIN_INPUT_PULLDOWN);
+			omap_mux_init_signal(pin_names[i][TLL_DAT3],
+				OMAP_PIN_INPUT_PULLDOWN);
+			omap_mux_init_signal(pin_names[i][TLL_DAT4],
+				OMAP_PIN_INPUT_PULLDOWN);
+			omap_mux_init_signal(pin_names[i][TLL_DAT5],
+				OMAP_PIN_INPUT_PULLDOWN);
+			omap_mux_init_signal(pin_names[i][TLL_DAT6],
+				OMAP_PIN_INPUT_PULLDOWN);
+			omap_mux_init_signal(pin_names[i][TLL_DAT7],
+				OMAP_PIN_INPUT_PULLDOWN);
 			break;
-	}
-}
 
-static void __init setup_ohci_io_mux(const enum usbhs_omap_port_mode *port_mode)
-{
-	switch (port_mode[0]) {
-	case OMAP_OHCI_PORT_MODE_PHY_6PIN_DATSE0:
-	case OMAP_OHCI_PORT_MODE_PHY_6PIN_DPDM:
-	case OMAP_OHCI_PORT_MODE_TLL_6PIN_DATSE0:
-	case OMAP_OHCI_PORT_MODE_TLL_6PIN_DPDM:
-		omap_mux_init_signal("mm1_rxdp",
-			OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("mm1_rxdm",
-			OMAP_PIN_INPUT_PULLDOWN);
-		/* FALLTHROUGH */
-	case OMAP_OHCI_PORT_MODE_PHY_4PIN_DPDM:
-	case OMAP_OHCI_PORT_MODE_TLL_4PIN_DPDM:
-		omap_mux_init_signal("mm1_rxrcv",
-			OMAP_PIN_INPUT_PULLDOWN);
-		/* FALLTHROUGH */
-	case OMAP_OHCI_PORT_MODE_PHY_3PIN_DATSE0:
-	case OMAP_OHCI_PORT_MODE_TLL_3PIN_DATSE0:
-		omap_mux_init_signal("mm1_txen_n", OMAP_PIN_OUTPUT);
-		/* FALLTHROUGH */
-	case OMAP_OHCI_PORT_MODE_TLL_2PIN_DATSE0:
-	case OMAP_OHCI_PORT_MODE_TLL_2PIN_DPDM:
-		omap_mux_init_signal("mm1_txse0",
-			OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("mm1_txdat",
-			OMAP_PIN_INPUT_PULLDOWN);
-		break;
-	case OMAP_USBHS_PORT_MODE_UNUSED:
-		/* FALLTHROUGH */
-	default:
-		break;
-	}
-	switch (port_mode[1]) {
-	case OMAP_OHCI_PORT_MODE_PHY_6PIN_DATSE0:
-	case OMAP_OHCI_PORT_MODE_PHY_6PIN_DPDM:
-	case OMAP_OHCI_PORT_MODE_TLL_6PIN_DATSE0:
-	case OMAP_OHCI_PORT_MODE_TLL_6PIN_DPDM:
-		omap_mux_init_signal("mm2_rxdp",
-			OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("mm2_rxdm",
-			OMAP_PIN_INPUT_PULLDOWN);
-		/* FALLTHROUGH */
-	case OMAP_OHCI_PORT_MODE_PHY_4PIN_DPDM:
-	case OMAP_OHCI_PORT_MODE_TLL_4PIN_DPDM:
-		omap_mux_init_signal("mm2_rxrcv",
-			OMAP_PIN_INPUT_PULLDOWN);
-		/* FALLTHROUGH */
-	case OMAP_OHCI_PORT_MODE_PHY_3PIN_DATSE0:
-	case OMAP_OHCI_PORT_MODE_TLL_3PIN_DATSE0:
-		omap_mux_init_signal("mm2_txen_n", OMAP_PIN_OUTPUT);
-		/* FALLTHROUGH */
-	case OMAP_OHCI_PORT_MODE_TLL_2PIN_DATSE0:
-	case OMAP_OHCI_PORT_MODE_TLL_2PIN_DPDM:
-		omap_mux_init_signal("mm2_txse0",
-			OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("mm2_txdat",
-			OMAP_PIN_INPUT_PULLDOWN);
-		break;
-	case OMAP_USBHS_PORT_MODE_UNUSED:
-		/* FALLTHROUGH */
-	default:
-		break;
-	}
-	switch (port_mode[2]) {
-	case OMAP_OHCI_PORT_MODE_PHY_6PIN_DATSE0:
-	case OMAP_OHCI_PORT_MODE_PHY_6PIN_DPDM:
-	case OMAP_OHCI_PORT_MODE_TLL_6PIN_DATSE0:
-	case OMAP_OHCI_PORT_MODE_TLL_6PIN_DPDM:
-		omap_mux_init_signal("mm3_rxdp",
-			OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("mm3_rxdm",
-			OMAP_PIN_INPUT_PULLDOWN);
-		/* FALLTHROUGH */
-	case OMAP_OHCI_PORT_MODE_PHY_4PIN_DPDM:
-	case OMAP_OHCI_PORT_MODE_TLL_4PIN_DPDM:
-		omap_mux_init_signal("mm3_rxrcv",
-			OMAP_PIN_INPUT_PULLDOWN);
-		/* FALLTHROUGH */
-	case OMAP_OHCI_PORT_MODE_PHY_3PIN_DATSE0:
-	case OMAP_OHCI_PORT_MODE_TLL_3PIN_DATSE0:
-		omap_mux_init_signal("mm3_txen_n", OMAP_PIN_OUTPUT);
-		/* FALLTHROUGH */
-	case OMAP_OHCI_PORT_MODE_TLL_2PIN_DATSE0:
-	case OMAP_OHCI_PORT_MODE_TLL_2PIN_DPDM:
-		omap_mux_init_signal("mm3_txse0",
-			OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("mm3_txdat",
-			OMAP_PIN_INPUT_PULLDOWN);
-		break;
-	case OMAP_USBHS_PORT_MODE_UNUSED:
-		/* FALLTHROUGH */
-	default:
-		break;
-	}
-}
+		/* OHCI cases */
+		case OMAP_OHCI_PORT_MODE_PHY_6PIN_DATSE0:
+		case OMAP_OHCI_PORT_MODE_PHY_6PIN_DPDM:
+		case OMAP_OHCI_PORT_MODE_TLL_6PIN_DATSE0:
+		case OMAP_OHCI_PORT_MODE_TLL_6PIN_DPDM:
+			omap_mux_init_signal(pin_names[i][RXDP],
+					OMAP_PIN_INPUT_PULLDOWN);
+			omap_mux_init_signal(pin_names[i][RXDM],
+					OMAP_PIN_INPUT_PULLDOWN);
+
+		case OMAP_OHCI_PORT_MODE_PHY_4PIN_DPDM:
+		case OMAP_OHCI_PORT_MODE_TLL_4PIN_DPDM:
+			omap_mux_init_signal(pin_names[i][RXRCV],
+					OMAP_PIN_INPUT_PULLDOWN);
+
+		case OMAP_OHCI_PORT_MODE_PHY_3PIN_DATSE0:
+		case OMAP_OHCI_PORT_MODE_TLL_3PIN_DATSE0:
+			omap_mux_init_signal(pin_names[i][TXEN],
+					OMAP_PIN_INPUT_PULLDOWN);
+
+		case OMAP_OHCI_PORT_MODE_TLL_2PIN_DATSE0:
+		case OMAP_OHCI_PORT_MODE_TLL_2PIN_DPDM:
+			omap_mux_init_signal(pin_names[i][TXDAT],
+					OMAP_PIN_INPUT_PULLDOWN);
+			omap_mux_init_signal(pin_names[i][TXSE0],
+					OMAP_PIN_INPUT_PULLDOWN);
+			break;
 
-static
-void __init setup_4430ohci_io_mux(const enum usbhs_omap_port_mode *port_mode)
-{
-	switch (port_mode[0]) {
-	case OMAP_OHCI_PORT_MODE_PHY_6PIN_DATSE0:
-	case OMAP_OHCI_PORT_MODE_PHY_6PIN_DPDM:
-	case OMAP_OHCI_PORT_MODE_TLL_6PIN_DATSE0:
-	case OMAP_OHCI_PORT_MODE_TLL_6PIN_DPDM:
-		omap_mux_init_signal("usbb1_mm_rxdp",
-			OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("usbb1_mm_rxdm",
-			OMAP_PIN_INPUT_PULLDOWN);
-
-	case OMAP_OHCI_PORT_MODE_PHY_4PIN_DPDM:
-	case OMAP_OHCI_PORT_MODE_TLL_4PIN_DPDM:
-		omap_mux_init_signal("usbb1_mm_rxrcv",
-			OMAP_PIN_INPUT_PULLDOWN);
-
-	case OMAP_OHCI_PORT_MODE_PHY_3PIN_DATSE0:
-	case OMAP_OHCI_PORT_MODE_TLL_3PIN_DATSE0:
-		omap_mux_init_signal("usbb1_mm_txen",
-			OMAP_PIN_INPUT_PULLDOWN);
-
-
-	case OMAP_OHCI_PORT_MODE_TLL_2PIN_DATSE0:
-	case OMAP_OHCI_PORT_MODE_TLL_2PIN_DPDM:
-		omap_mux_init_signal("usbb1_mm_txdat",
-			OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("usbb1_mm_txse0",
-			OMAP_PIN_INPUT_PULLDOWN);
-		break;
-
-	case OMAP_USBHS_PORT_MODE_UNUSED:
-	default:
-		break;
+		/* unused */
+		case OMAP_USBHS_PORT_MODE_UNUSED:
+		default:
+			break;
+		}
 	}
 
-	switch (port_mode[1]) {
-	case OMAP_OHCI_PORT_MODE_PHY_6PIN_DATSE0:
-	case OMAP_OHCI_PORT_MODE_PHY_6PIN_DPDM:
-	case OMAP_OHCI_PORT_MODE_TLL_6PIN_DATSE0:
-	case OMAP_OHCI_PORT_MODE_TLL_6PIN_DPDM:
-		omap_mux_init_signal("usbb2_mm_rxdp",
-			OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("usbb2_mm_rxdm",
-			OMAP_PIN_INPUT_PULLDOWN);
-
-	case OMAP_OHCI_PORT_MODE_PHY_4PIN_DPDM:
-	case OMAP_OHCI_PORT_MODE_TLL_4PIN_DPDM:
-		omap_mux_init_signal("usbb2_mm_rxrcv",
-			OMAP_PIN_INPUT_PULLDOWN);
-
-	case OMAP_OHCI_PORT_MODE_PHY_3PIN_DATSE0:
-	case OMAP_OHCI_PORT_MODE_TLL_3PIN_DATSE0:
-		omap_mux_init_signal("usbb2_mm_txen",
-			OMAP_PIN_INPUT_PULLDOWN);
-
-
-	case OMAP_OHCI_PORT_MODE_TLL_2PIN_DATSE0:
-	case OMAP_OHCI_PORT_MODE_TLL_2PIN_DPDM:
-		omap_mux_init_signal("usbb2_mm_txdat",
-			OMAP_PIN_INPUT_PULLDOWN);
-		omap_mux_init_signal("usbb2_mm_txse0",
-			OMAP_PIN_INPUT_PULLDOWN);
-		break;
-
-	case OMAP_USBHS_PORT_MODE_UNUSED:
-	default:
-		break;
-	}
+	kfree(pin_names);
 }
 
 void __init usbhs_init(struct usbhs_omap_platform_data *pdata)
@@ -482,18 +283,19 @@ void __init usbhs_init(struct usbhs_omap_platform_data *pdata)
 	struct platform_device	*pdev;
 	int			bus_id = -1;
 
-	if (cpu_is_omap34xx()) {
-		setup_ehci_io_mux(pdata->port_mode);
-		setup_ohci_io_mux(pdata->port_mode);
+	const char (*pin_template)[MAX_PIN_NAME];
+
+	pin_template = omap4_pin_template;
 
+	if (cpu_is_omap34xx()) {
 		if (omap_rev() <= OMAP3430_REV_ES2_1)
 			pdata->single_ulpi_bypass = true;
 
-	} else if (cpu_is_omap44xx()) {
-		setup_4430ehci_io_mux(pdata->port_mode);
-		setup_4430ohci_io_mux(pdata->port_mode);
+		pin_template = omap3_pin_template;
 	}
 
+	usbhs_setup_io_mux(pdata->port_mode, pin_template);
+
 	uhh_hwm = omap_hwmod_lookup(USBHS_UHH_HWMODNAME);
 	if (!uhh_hwm) {
 		pr_err("Could not look up %s\n", USBHS_UHH_HWMODNAME);
-- 
1.7.4.1



From linus.walleij at stericsson.com  Mon Apr 22 05:57:48 2013
From: linus.walleij at stericsson.com (Linus Walleij)
Date: Mon, 22 Apr 2013 11:57:48 +0200
Subject: [PATCH 16/23] ARM: u300: support regulators in the device tree
Message-ID: <1366624668-6682-1-git-send-email-linus.walleij@stericsson.com>

From: Linus Walleij <linus.walleij at linaro.org>

Now that we have enabled board power and the AB3100 regulators,
put the regulator data into the device tree and enable it so
we can start to tie regulators to devices. To begin with we're
only supplying the power to the board itself.

Cc: Mark Brown <broonie at kernel.org>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 arch/arm/boot/dts/ste-u300.dts | 79 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 79 insertions(+)

diff --git a/arch/arm/boot/dts/ste-u300.dts b/arch/arm/boot/dts/ste-u300.dts
index 784e17a..1b3ec2d 100644
--- a/arch/arm/boot/dts/ste-u300.dts
+++ b/arch/arm/boot/dts/ste-u300.dts
@@ -24,6 +24,11 @@
 		reg = <0x48000000 0x03c00000>;
 	};
 
+	s365 {
+		compatible = "stericsson,s365";
+		vana15-supply = <&ab3100_ldo_d_reg>;
+	};
+
 	timer: timer0 at c0014000 {
 		compatible = "stericsson,u300-apptimer";
 		reg = <0xc0014000 0x1000>;
@@ -70,6 +75,74 @@
 		interrupts = <8>;
 		#address-cells = <1>;
 		#size-cells = <0>;
+		ab3100: ab3100 at 0x48 {
+			compatible = "stericsson,ab3100";
+			reg = <0x48>;
+			interrupt-parent = <&vica>;
+			interrupts = <0>; /* EXT0 IRQ */
+			ab3100-regulators {
+				compatible = "stericsson,ab3100-regulators";
+				ab3100_ldo_a_reg: ab3100_ldo_a {
+					regulator-compatible = "ab3100_ldo_a";
+					startup-delay-us = <200>;
+					regulator-always-on;
+					regulator-boot-on;
+				};
+				ab3100_ldo_c_reg: ab3100_ldo_c {
+					regulator-compatible = "ab3100_ldo_c";
+					startup-delay-us = <200>;
+				};
+				ab3100_ldo_d_reg: ab3100_ldo_d {
+					regulator-compatible = "ab3100_ldo_d";
+					startup-delay-us = <200>;
+				};
+				ab3100_ldo_e_reg: ab3100_ldo_e {
+					regulator-compatible = "ab3100_ldo_e";
+					regulator-min-microvolt = <1800000>;
+					regulator-max-microvolt = <1800000>;
+					startup-delay-us = <200>;
+					regulator-always-on;
+					regulator-boot-on;
+				};
+				ab3100_ldo_f_reg: ab3100_ldo_f {
+					regulator-compatible = "ab3100_ldo_f";
+					regulator-min-microvolt = <2500000>;
+					regulator-max-microvolt = <2500000>;
+					startup-delay-us = <600>;
+					regulator-always-on;
+					regulator-boot-on;
+				};
+				ab3100_ldo_g_reg: ab3100_ldo_g {
+					regulator-compatible = "ab3100_ldo_g";
+					regulator-min-microvolt = <1500000>;
+					regulator-max-microvolt = <2850000>;
+					startup-delay-us = <400>;
+				};
+				ab3100_ldo_h_reg: ab3100_ldo_h {
+					regulator-compatible = "ab3100_ldo_h";
+					regulator-min-microvolt = <1200000>;
+					regulator-max-microvolt = <2750000>;
+					startup-delay-us = <200>;
+				};
+				ab3100_ldo_k_reg: ab3100_ldo_k {
+					regulator-compatible = "ab3100_ldo_k";
+					regulator-min-microvolt = <1800000>;
+					regulator-max-microvolt = <2750000>;
+					startup-delay-us = <200>;
+				};
+				ab3100_ext_reg: ab3100_ext {
+					regulator-compatible = "ab3100_ext";
+				};
+				ab3100_buck_reg: ab3100_buck {
+					regulator-compatible = "ab3100_buck";
+					regulator-min-microvolt = <1200000>;
+					regulator-max-microvolt = <1800000>;
+					startup-delay-us = <1000>;
+					regulator-always-on;
+					regulator-boot-on;
+				};
+			};
+		};
 	};
 
 	i2c1: i2c at c0005000 {
@@ -79,6 +152,12 @@
 		interrupts = <9>;
 		#address-cells = <1>;
 		#size-cells = <0>;
+		fwcam0: fwcam at 0x10 {
+			reg = <0x10>;
+		};
+		fwcam1: fwcam at 0x5d {
+			reg = <0x5d>;
+		};
 	};
 
 	amba {
-- 
1.7.11.3



From linus.walleij at stericsson.com  Mon Apr 22 05:58:35 2013
From: linus.walleij at stericsson.com (Linus Walleij)
Date: Mon, 22 Apr 2013 11:58:35 +0200
Subject: [PATCH 17/23] ARM: u300: enable MMC/SD card from device tree
Message-ID: <1366624715-6751-1-git-send-email-linus.walleij@stericsson.com>

From: Linus Walleij <linus.walleij at linaro.org>

This adds support for the U300 MMC/SD card slot from the device
tree boot. No other changes needed.

Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 arch/arm/boot/dts/ste-u300.dts | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm/boot/dts/ste-u300.dts b/arch/arm/boot/dts/ste-u300.dts
index 1b3ec2d..ee747fe 100644
--- a/arch/arm/boot/dts/ste-u300.dts
+++ b/arch/arm/boot/dts/ste-u300.dts
@@ -193,5 +193,19 @@
 			interrupt-parent = <&vicb>;
 			interrupts = <20>;
 		};
+
+		mmcsd: mmcsd at c0001000 {
+			compatible = "arm,pl18x", "arm,primecell";
+			reg = <0xc0001000 0x1000>;
+			interrupt-parent = <&vicb>;
+			interrupts = <6 7>;
+			max-frequency = <24000000>;
+			bus-width = <4>; // SD-card slot
+			mmc-cap-mmc-highspeed;
+			mmc-cap-sd-highspeed;
+			cd-gpios = <&gpio 12 0x4>;
+			cd-inverted;
+			vmmc-supply = <&ab3100_ldo_g_reg>;
+		};
 	};
 };
-- 
1.7.11.3



From linus.walleij at stericsson.com  Mon Apr 22 05:59:30 2013
From: linus.walleij at stericsson.com (Linus Walleij)
Date: Mon, 22 Apr 2013 11:59:30 +0200
Subject: [PATCH 18/23] dma: coh901318: add devicetree support
Message-ID: <1366624770-6786-1-git-send-email-linus.walleij@stericsson.com>

From: Linus Walleij <linus.walleij at linaro.org>

This adds support for probing the COH 901 318 DMA controller
from the device tree.

Cc: Vinod Koul <vinod.koul at intel.com>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
Hi Vinod, I'm seeking an ACK on this patch to take it through
the ARM SoC tree.
---
 drivers/dma/coh901318.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/drivers/dma/coh901318.c b/drivers/dma/coh901318.c
index 797940e..2855646 100644
--- a/drivers/dma/coh901318.c
+++ b/drivers/dma/coh901318.c
@@ -2758,11 +2758,16 @@ static int __exit coh901318_remove(struct platform_device *pdev)
 	return 0;
 }
 
+static const struct of_device_id coh901318_dt_match[] = {
+	{ .compatible = "stericsson,coh901318" },
+	{},
+};
 
 static struct platform_driver coh901318_driver = {
 	.remove = __exit_p(coh901318_remove),
 	.driver = {
 		.name	= "coh901318",
+		.of_match_table = coh901318_dt_match,
 	},
 };
 
-- 
1.7.11.3



From linus.walleij at stericsson.com  Mon Apr 22 05:59:39 2013
From: linus.walleij at stericsson.com (Linus Walleij)
Date: Mon, 22 Apr 2013 11:59:39 +0200
Subject: [PATCH 19/23] ARM: u300: add the COH 901 318 DMAC to device tree
Message-ID: <1366624779-6820-1-git-send-email-linus.walleij@stericsson.com>

From: Linus Walleij <linus.walleij at linaro.org>

This adds the COH 901 318 DMA controller to the U300
device tree. All devices now converted to device tree
so far will start to find their DMA channels.

Note that the U300 is not yet using the device tree
to obtain DMA channels, but this is a first step.

Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 arch/arm/boot/dts/ste-u300.dts | 7 +++++++
 arch/arm/mach-u300/core.c      | 2 ++
 2 files changed, 9 insertions(+)

diff --git a/arch/arm/boot/dts/ste-u300.dts b/arch/arm/boot/dts/ste-u300.dts
index ee747fe..cdffeb9 100644
--- a/arch/arm/boot/dts/ste-u300.dts
+++ b/arch/arm/boot/dts/ste-u300.dts
@@ -68,6 +68,13 @@
 		interrupts = <10>;
 	};
 
+	dmac: dmac at c00020000 {
+		compatible = "stericsson,coh901318";
+		reg = <0xc0020000 0x1000>;
+		interrupt-parent = <&vica>;
+		interrupts = <2>;
+	};
+
 	i2c0: i2c at c0004000 {
 		compatible = "st,ddci2c";
 		reg = <0xc0004000 0x1000>;
diff --git a/arch/arm/mach-u300/core.c b/arch/arm/mach-u300/core.c
index 20d6c46..98d4dbe 100644
--- a/arch/arm/mach-u300/core.c
+++ b/arch/arm/mach-u300/core.c
@@ -713,6 +713,8 @@ static struct of_dev_auxdata u300_auxdata_lookup[] __initdata = {
 		"coh901327_wdog", NULL),
 	OF_DEV_AUXDATA("stericsson,coh901331", U300_RTC_BASE,
 		"rtc-coh901331", NULL),
+	OF_DEV_AUXDATA("stericsson,coh901318", U300_DMAC_BASE,
+		"coh901318", NULL),
 	OF_DEV_AUXDATA("arm,primecell", U300_UART0_BASE,
 		"uart0", &uart0_plat_data),
 	OF_DEV_AUXDATA("arm,primecell", U300_UART1_BASE,
-- 
1.7.11.3



From laurent.pinchart at ideasonboard.com  Mon Apr 22 06:00:02 2013
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Mon, 22 Apr 2013 12:00:02 +0200
Subject: [PATCH] ARM: shmobile: lager: Add GPIO LEDs
In-Reply-To: <1366599990-31751-1-git-send-email-horms+renesas@verge.net.au>
References: <1366599990-31751-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1761228.8meccMO5Km@avalon>

Hi Simon,

Thank you for the patch.

On Monday 22 April 2013 12:06:30 Simon Horman wrote:
> The board has 3 LEDs connected to GPIOs. Add a led-gpio device to
> support them.
> 
> Based on "ARM: shmobile: marzen: Add GPIO LEDs" by Laurent Pinchart.
> 
> Cc: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
> Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
> ---
>  arch/arm/mach-shmobile/board-lager.c | 37 +++++++++++++++++++++++++++++++++
>  1 file changed, 37 insertions(+)
> 
> Tested on lager board.
> Based on the tag renesas-next-20130419 of my renesas tree.
> 
> diff --git a/arch/arm/mach-shmobile/board-lager.c
> b/arch/arm/mach-shmobile/board-lager.c index 6114edd..a8aa04f 100644
> --- a/arch/arm/mach-shmobile/board-lager.c
> +++ b/arch/arm/mach-shmobile/board-lager.c
> @@ -21,13 +21,49 @@
>  #include <linux/interrupt.h>
>  #include <linux/irqchip.h>
>  #include <linux/kernel.h>
> +#include <linux/leds.h>
>  #include <linux/pinctrl/machine.h>
> +#include <linux/platform_data/gpio-rcar.h>
>  #include <linux/platform_device.h>
>  #include <mach/common.h>
>  #include <mach/r8a7790.h>
>  #include <asm/mach-types.h>
>  #include <asm/mach/arch.h>
> 
> +/* LEDS */
> +static struct gpio_led lager_leds[] = {
> +	{
> +		.name		= "led8",
> +		.gpio		= RCAR_GP_PIN(5, 17),
> +		.default_state	= LEDS_GPIO_DEFSTATE_ON,
> +	}, {
> +		.name		= "led7",
> +		.gpio		= RCAR_GP_PIN(4, 23),
> +		.default_state	= LEDS_GPIO_DEFSTATE_ON,
> +	}, {
> +		.name		= "led6",
> +		.gpio		= RCAR_GP_PIN(4, 22),
> +		.default_state	= LEDS_GPIO_DEFSTATE_ON,

Just out of curiosity, why is the default state on ?

> +	},
> +};
> +
> +static struct gpio_led_platform_data lager_leds_pdata = {
> +	.leds		= lager_leds,
> +	.num_leds	= ARRAY_SIZE(lager_leds),
> +};
> +
> +static struct platform_device leds_device = {
> +	.name	= "leds-gpio",
> +	.id	= 0,

As there's a single leds-gpio device, maybe id = -1 ?

> +	.dev	= {
> +		.platform_data  = &lager_leds_pdata,
> +	},
> +};
> +
> +static struct platform_device *lager_devices[] __initdata = {
> +	&leds_device,
> +};
> +
>  static const struct pinctrl_map lager_pinctrl_map[] = {
>  	/* SCIF0 (CN19: DEBUG SERIAL0) */
>  	PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.6", "pfc-r8a7790",
> @@ -46,6 +82,7 @@ static void __init lager_add_standard_devices(void)
>  	r8a7790_pinmux_init();
> 
>  	r8a7790_add_standard_devices();
> +	platform_add_devices(lager_devices, ARRAY_SIZE(lager_devices));
>  }
> 
>  static const char *lager_boards_compat_dt[] __initdata = {

-- 
Regards,

Laurent Pinchart



From linus.walleij at stericsson.com  Mon Apr 22 06:00:03 2013
From: linus.walleij at stericsson.com (Linus Walleij)
Date: Mon, 22 Apr 2013 12:00:03 +0200
Subject: [PATCH 20/23] ARM: u300: add SPI PL022 to the device tree
Message-ID: <1366624803-6854-1-git-send-email-linus.walleij@stericsson.com>

From: Linus Walleij <linus.walleij at linaro.org>

This registers the PL022 PrimeCell from the U300 device
tree. We make a new copy of the platform data for the
device tree boot path, as the old platform data is in an
older file which will be going away.

Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 arch/arm/boot/dts/ste-u300.dts |  7 +++++++
 arch/arm/mach-u300/core.c      | 19 +++++++++++++++++++
 2 files changed, 26 insertions(+)

diff --git a/arch/arm/boot/dts/ste-u300.dts b/arch/arm/boot/dts/ste-u300.dts
index cdffeb9..979d96c 100644
--- a/arch/arm/boot/dts/ste-u300.dts
+++ b/arch/arm/boot/dts/ste-u300.dts
@@ -214,5 +214,12 @@
 			cd-inverted;
 			vmmc-supply = <&ab3100_ldo_g_reg>;
 		};
+
+		spi: ssp at c0006000 {
+			compatible = "arm,pl022", "arm,primecell";
+			reg = <0xc0006000 0x1000>;
+			interrupt-parent = <&vica>;
+			interrupts = <23>;
+		};
 	};
 };
diff --git a/arch/arm/mach-u300/core.c b/arch/arm/mach-u300/core.c
index 98d4dbe..9467ffe 100644
--- a/arch/arm/mach-u300/core.c
+++ b/arch/arm/mach-u300/core.c
@@ -19,6 +19,7 @@
 #include <linux/dmaengine.h>
 #include <linux/amba/bus.h>
 #include <linux/amba/mmci.h>
+#include <linux/amba/pl022.h>
 #include <linux/amba/serial.h>
 #include <linux/platform_device.h>
 #include <linux/gpio.h>
@@ -703,6 +704,22 @@ MACHINE_END
 
 #ifdef CONFIG_OF
 
+static struct pl022_ssp_controller spi_plat_data = {
+	/* If you have several SPI buses this varies, we have only bus 0 */
+	.bus_id = 0,
+	/*
+	 * On the APP CPU GPIO 4, 5 and 6 are connected as generic
+	 * chip selects for SPI. (Same on U330, U335 and U365.)
+	 * TODO: make sure the GPIO driver can select these properly
+	 * and do padmuxing accordingly too.
+	 */
+	.num_chipselect = 3,
+	.enable_dma = 1,
+	.dma_filter = coh901318_filter_id,
+	.dma_rx_param = (void *) U300_DMA_SPI_RX,
+	.dma_tx_param = (void *) U300_DMA_SPI_TX,
+};
+
 /* These are mostly to get the right device names for the clock lookups */
 static struct of_dev_auxdata u300_auxdata_lookup[] __initdata = {
 	OF_DEV_AUXDATA("stericsson,pinctrl-u300", U300_SYSCON_BASE,
@@ -719,6 +736,8 @@ static struct of_dev_auxdata u300_auxdata_lookup[] __initdata = {
 		"uart0", &uart0_plat_data),
 	OF_DEV_AUXDATA("arm,primecell", U300_UART1_BASE,
 		"uart1", &uart1_plat_data),
+	OF_DEV_AUXDATA("arm,primecell", U300_SPI_BASE,
+		"pl022", &spi_plat_data),
 	OF_DEV_AUXDATA("st,ddci2c", U300_I2C0_BASE,
 		"stu300.0", NULL),
 	OF_DEV_AUXDATA("st,ddci2c", U300_I2C1_BASE,
-- 
1.7.11.3



From linus.walleij at stericsson.com  Mon Apr 22 06:01:17 2013
From: linus.walleij at stericsson.com (Linus Walleij)
Date: Mon, 22 Apr 2013 12:01:17 +0200
Subject: [PATCH 20/23] ARM: u300: add SPI PL022 to the device tree
Message-ID: <1366624877-6932-1-git-send-email-linus.walleij@stericsson.com>

From: Linus Walleij <linus.walleij at linaro.org>

This registers the PL022 PrimeCell from the U300 device
tree. We make a new copy of the platform data for the
device tree boot path, as the old platform data is in an
older file which will be going away.

Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 arch/arm/boot/dts/ste-u300.dts |  7 +++++++
 arch/arm/mach-u300/core.c      | 19 +++++++++++++++++++
 2 files changed, 26 insertions(+)

diff --git a/arch/arm/boot/dts/ste-u300.dts b/arch/arm/boot/dts/ste-u300.dts
index cdffeb9..979d96c 100644
--- a/arch/arm/boot/dts/ste-u300.dts
+++ b/arch/arm/boot/dts/ste-u300.dts
@@ -214,5 +214,12 @@
 			cd-inverted;
 			vmmc-supply = <&ab3100_ldo_g_reg>;
 		};
+
+		spi: ssp at c0006000 {
+			compatible = "arm,pl022", "arm,primecell";
+			reg = <0xc0006000 0x1000>;
+			interrupt-parent = <&vica>;
+			interrupts = <23>;
+		};
 	};
 };
diff --git a/arch/arm/mach-u300/core.c b/arch/arm/mach-u300/core.c
index 98d4dbe..9467ffe 100644
--- a/arch/arm/mach-u300/core.c
+++ b/arch/arm/mach-u300/core.c
@@ -19,6 +19,7 @@
 #include <linux/dmaengine.h>
 #include <linux/amba/bus.h>
 #include <linux/amba/mmci.h>
+#include <linux/amba/pl022.h>
 #include <linux/amba/serial.h>
 #include <linux/platform_device.h>
 #include <linux/gpio.h>
@@ -703,6 +704,22 @@ MACHINE_END
 
 #ifdef CONFIG_OF
 
+static struct pl022_ssp_controller spi_plat_data = {
+	/* If you have several SPI buses this varies, we have only bus 0 */
+	.bus_id = 0,
+	/*
+	 * On the APP CPU GPIO 4, 5 and 6 are connected as generic
+	 * chip selects for SPI. (Same on U330, U335 and U365.)
+	 * TODO: make sure the GPIO driver can select these properly
+	 * and do padmuxing accordingly too.
+	 */
+	.num_chipselect = 3,
+	.enable_dma = 1,
+	.dma_filter = coh901318_filter_id,
+	.dma_rx_param = (void *) U300_DMA_SPI_RX,
+	.dma_tx_param = (void *) U300_DMA_SPI_TX,
+};
+
 /* These are mostly to get the right device names for the clock lookups */
 static struct of_dev_auxdata u300_auxdata_lookup[] __initdata = {
 	OF_DEV_AUXDATA("stericsson,pinctrl-u300", U300_SYSCON_BASE,
@@ -719,6 +736,8 @@ static struct of_dev_auxdata u300_auxdata_lookup[] __initdata = {
 		"uart0", &uart0_plat_data),
 	OF_DEV_AUXDATA("arm,primecell", U300_UART1_BASE,
 		"uart1", &uart1_plat_data),
+	OF_DEV_AUXDATA("arm,primecell", U300_SPI_BASE,
+		"pl022", &spi_plat_data),
 	OF_DEV_AUXDATA("st,ddci2c", U300_I2C0_BASE,
 		"stu300.0", NULL),
 	OF_DEV_AUXDATA("st,ddci2c", U300_I2C1_BASE,
-- 
1.7.11.3



From linus.walleij at stericsson.com  Mon Apr 22 06:01:25 2013
From: linus.walleij at stericsson.com (Linus Walleij)
Date: Mon, 22 Apr 2013 12:01:25 +0200
Subject: [PATCH 21/23] ARM: u300: probe the U300 dummy-spichip from device tree
Message-ID: <1366624885-6966-1-git-send-email-linus.walleij@stericsson.com>

From: Linus Walleij <linus.walleij at linaro.org>

This probes the U300 dummy-spichip from the device tree
and adds the apropriate node to the tree.

Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 arch/arm/boot/dts/ste-u300.dts    | 5 +++++
 arch/arm/mach-u300/dummyspichip.c | 6 ++++++
 2 files changed, 11 insertions(+)

diff --git a/arch/arm/boot/dts/ste-u300.dts b/arch/arm/boot/dts/ste-u300.dts
index 979d96c..9a163e1 100644
--- a/arch/arm/boot/dts/ste-u300.dts
+++ b/arch/arm/boot/dts/ste-u300.dts
@@ -220,6 +220,11 @@
 			reg = <0xc0006000 0x1000>;
 			interrupt-parent = <&vica>;
 			interrupts = <23>;
+			spi-dummy at 1 {
+				compatible = "arm,pl022-dummy";
+				reg = <1>;
+				spi-max-frequency = <20000000>;
+			};
 		};
 	};
 };
diff --git a/arch/arm/mach-u300/dummyspichip.c b/arch/arm/mach-u300/dummyspichip.c
index 2785cb6..52962bf 100644
--- a/arch/arm/mach-u300/dummyspichip.c
+++ b/arch/arm/mach-u300/dummyspichip.c
@@ -263,10 +263,16 @@ static int pl022_dummy_remove(struct spi_device *spi)
 	return 0;
 }
 
+static const struct of_device_id pl022_dummy_dt_match[] = {
+	{ .compatible = "arm,pl022-dummy" },
+	{},
+};
+
 static struct spi_driver pl022_dummy_driver = {
 	.driver = {
 		.name	= "spi-dummy",
 		.owner	= THIS_MODULE,
+		.of_match_table = pl022_dummy_dt_match,
 	},
 	.probe	= pl022_dummy_probe,
 	.remove	= pl022_dummy_remove,
-- 
1.7.11.3



From u.kleine-koenig at pengutronix.de  Mon Apr 22 06:02:19 2013
From: u.kleine-koenig at pengutronix.de (Uwe =?iso-8859-1?Q?Kleine-K=F6nig?=)
Date: Mon, 22 Apr 2013 12:02:19 +0200
Subject: [PATCH v3] irqchip: Add support for ARMv7-M's NVIC
In-Reply-To: <20130419150927.GE15233@pengutronix.de>
References: <1366214540-31166-1-git-send-email-u.kleine-koenig@pengutronix.de>
 <alpine.LFD.2.02.1304180947070.21884@ionos>
 <20130419150927.GE15233@pengutronix.de>
Message-ID: <20130422100219.GH15233@pengutronix.de>

Hello,

(for the new readers of this thread: This is about using

	u32 mask = 1 << (d->hwirq % 32);

instead of

	u32 mask = 1 << (d->irq - gc->irq_base);

in the callbacks for the irq generic chip.)

On Fri, Apr 19, 2013 at 05:09:27PM +0200, Uwe Kleine-K?nig wrote:
> On Thu, Apr 18, 2013 at 11:35:22AM +0200, Thomas Gleixner wrote:
> > On Wed, 17 Apr 2013, Uwe Kleine-K?nig wrote:
> > How is that different from what the generic irq chip implementation
> > does? The only difference is that mask is generated by d->hwirq and
> > not by d->irq. And due to the fact, that you use a full linear mapping
> > between hwirq and virq the generic code simply works.
> I'm not sure what you mean when you say "full linear mapping". AFAICT
> using irq_domain_add_linear doesn't imply that two consecutive hardware
> irq numbers get consecutive Linux irq numbers, so using d->irq won't work.
>  
> > Even if it would not work, it would be trivial to extend the generic
> > chip with that functionality instead of hacking another slightly
> > different copy of the same thing.
> I will try that and report back.
I wonder if using hwirq % 32 should work everywhere where now d->irq -
gc->irqbase is used. Depending on d->hwirq and not d->irq has the upside
of working with non-legacy irq domains, too.

Looking at next-20130419 the affected functions
(irq_gc_mask_disable_reg, irq_gc_mask_set_bit, irq_gc_mask_clr_bit,
irq_gc_unmask_enable_reg, irq_gc_ack_set_bit, irq_gc_ack_clr_bit,
irq_gc_mask_disable_reg_and_ack, irq_gc_eoi, irq_gc_set_wake) are used
in:

arch/arm/mach-davinci/irq.c
arch/arm/mach-imx/avic.c
arch/arm/mach-imx/tzic.c
arch/arm/mach-omap2/irq.c
arch/arm/mach-omap2/prm_common.c

arch/arm/mach-s5p64x0/common.c
	-> uses irq_base=101 for irq_alloc_generic_chip
arch/arm/plat-orion/gpio.c
	-> depends on how orion_gpio_of_init is called. No callers
	found.

arch/arm/plat-orion/irq.c
arch/arm/plat-samsung/irq-vic-timer.c
	-> used for a single irq that isn't a multiple of 32

arch/arm/plat-samsung/s5p-irq-gpioint.c
	-> would need % 8?

arch/mips/jz4740/gpio.c
	-> JZ4740_IRQ_GPIO(0) != JZ4740_IRQ_GPIO0 ?
	-> uses 56 + i * 32 as irqbase

arch/mips/jz4740/irq.c
	-> uses 8 as irqbase

arch/sh/boards/mach-se/7343/irq.c
	-> uses irq_base = irq_linear_revmap(se7343_irq_domain, 0) where
	se7343_irq_domain is a linear domain.
	AFAICT this is a bug. (After adding the domain they map all irqs
	in increasing order which currently seems to guarantee that it
	works. But IMHO it should use a legacy domain.)

arch/sh/boards/mach-se/7722/irq.c
	as above.

drivers/gpio/gpio-mxc.c
drivers/gpio/gpio-mxs.c
drivers/gpio/gpio-omap.c
drivers/gpio/gpio-sodaville.c
drivers/irqchip/irq-sirfsoc.c
drivers/mfd/jz4740-adc.c
	-> uses platform_get_irq(pdev, 1) as irq_base for 5 irqs.

For the uncommented files using %32 instead of -gc->irq_base should
work.

So it seems I cannot just substitute how the mask is called. 

The options I see are:

 - introduce a new set of functions
   Do you have a nice naming scheme?
   irq_gc_unmask_enable_reg_hwirqmod32? Or should I rename the existing
   ones to irq_gc_unmask_enable_reg_irqbaseoffset?
 - use
 	u32 mask = 1 << (d->hwirq - gc->irq_base) % 32;
   This is ugly but might work assuming irq_base == 0 for chips with irq
   domain support and hwirq == irq for the others.

I'm not lucky with the options, so I'm looking forward to suggestions.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |


From linus.walleij at stericsson.com  Mon Apr 22 06:02:19 2013
From: linus.walleij at stericsson.com (Linus Walleij)
Date: Mon, 22 Apr 2013 12:02:19 +0200
Subject: [PATCH 22/23] ARM: u300: add FSMC flash into the device tree
Message-ID: <1366624939-7003-1-git-send-email-linus.walleij@stericsson.com>

From: Linus Walleij <linus.walleij at linaro.org>

This registers the U300 FSMC flash controller from the
device tree, and defines the three partitions. Skip the
BBT scan as in the current platform data.

Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 arch/arm/boot/dts/ste-u300.dts | 26 ++++++++++++++++++++++++++
 arch/arm/mach-u300/core.c      |  2 ++
 2 files changed, 28 insertions(+)

diff --git a/arch/arm/boot/dts/ste-u300.dts b/arch/arm/boot/dts/ste-u300.dts
index 9a163e1..e4b8c7b 100644
--- a/arch/arm/boot/dts/ste-u300.dts
+++ b/arch/arm/boot/dts/ste-u300.dts
@@ -75,6 +75,32 @@
 		interrupts = <2>;
 	};
 
+	/* A NAND flash of 128 MiB */
+	fsmc: flash at 40000000 {
+		compatible = "stericsson,fsmc-nand";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		reg = <0x9f800000 0x1000>,	/* FSMC Register*/
+			<0x80000000 0x4000>,	/* NAND Base DATA */
+			<0x80020000 0x4000>,	/* NAND Base ADDR */
+			<0x80010000 0x4000>;	/* NAND Base CMD */
+		reg-names = "fsmc_regs", "nand_data", "nand_addr", "nand_cmd";
+		nand-skip-bbtscan;
+
+		partition at 0 {
+		label = "boot records";
+			reg = <0x0 0x20000>;
+		};
+		partition at 20000 {
+			label = "free";
+			reg = <0x20000 0x7e0000>;
+		};
+		partition at 800000 {
+			label = "platform";
+			reg = <0x800000 0xf800000>;
+		};
+	};
+
 	i2c0: i2c at c0004000 {
 		compatible = "st,ddci2c";
 		reg = <0xc0004000 0x1000>;
diff --git a/arch/arm/mach-u300/core.c b/arch/arm/mach-u300/core.c
index 9467ffe..82f57f1 100644
--- a/arch/arm/mach-u300/core.c
+++ b/arch/arm/mach-u300/core.c
@@ -732,6 +732,8 @@ static struct of_dev_auxdata u300_auxdata_lookup[] __initdata = {
 		"rtc-coh901331", NULL),
 	OF_DEV_AUXDATA("stericsson,coh901318", U300_DMAC_BASE,
 		"coh901318", NULL),
+	OF_DEV_AUXDATA("stericsson,fsmc-nand", U300_NAND_IF_PHYS_BASE,
+		"fsmc-nand", NULL),
 	OF_DEV_AUXDATA("arm,primecell", U300_UART0_BASE,
 		"uart0", &uart0_plat_data),
 	OF_DEV_AUXDATA("arm,primecell", U300_UART1_BASE,
-- 
1.7.11.3



From linus.walleij at stericsson.com  Mon Apr 22 06:02:35 2013
From: linus.walleij at stericsson.com (Linus Walleij)
Date: Mon, 22 Apr 2013 12:02:35 +0200
Subject: [PATCH 23/23] ARM: u300: delete all static board data
Message-ID: <1366624955-7037-1-git-send-email-linus.walleij@stericsson.com>

From: Linus Walleij <linus.walleij at linaro.org>

We have now transferred all the U300 peripherals to the device
tree, so we just select USE_OF, and delete all static board data,
then require that this platform shall be booted using the device
tree and nothing else.

Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 arch/arm/Kconfig               |   1 +
 arch/arm/mach-u300/Makefile    |   2 -
 arch/arm/mach-u300/core.c      | 488 +----------------------------------------
 arch/arm/mach-u300/i2c.c       | 285 ------------------------
 arch/arm/mach-u300/i2c.h       |  23 --
 arch/arm/mach-u300/regulator.c |  12 +-
 arch/arm/mach-u300/spi.c       | 102 ---------
 arch/arm/mach-u300/spi.h       |  26 ---
 arch/arm/mach-u300/timer.c     |  22 +-
 arch/arm/mach-u300/u300-gpio.h |  70 ------
 10 files changed, 16 insertions(+), 1015 deletions(-)
 delete mode 100644 arch/arm/mach-u300/i2c.c
 delete mode 100644 arch/arm/mach-u300/i2c.h
 delete mode 100644 arch/arm/mach-u300/spi.c
 delete mode 100644 arch/arm/mach-u300/spi.h
 delete mode 100644 arch/arm/mach-u300/u300-gpio.h

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 13b7394..d0a4e6d 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -898,6 +898,7 @@ config ARCH_U300
 	select GENERIC_CLOCKEVENTS
 	select HAVE_TCM
 	select SPARSE_IRQ
+	select USE_OF
 	help
 	  Support for ST-Ericsson U300 series mobile platforms.
 
diff --git a/arch/arm/mach-u300/Makefile b/arch/arm/mach-u300/Makefile
index 5a86c58..0f362b6 100644
--- a/arch/arm/mach-u300/Makefile
+++ b/arch/arm/mach-u300/Makefile
@@ -7,7 +7,5 @@ obj-m		:=
 obj-n		:=
 obj-		:=
 
-obj-$(CONFIG_SPI_PL022)           += spi.o
 obj-$(CONFIG_MACH_U300_SPIDUMMY)  += dummyspichip.o
-obj-$(CONFIG_I2C_STU300)          += i2c.o
 obj-$(CONFIG_REGULATOR_AB3100)    += regulator.o
diff --git a/arch/arm/mach-u300/core.c b/arch/arm/mach-u300/core.c
index 82f57f1..42f5a67 100644
--- a/arch/arm/mach-u300/core.c
+++ b/arch/arm/mach-u300/core.c
@@ -9,49 +9,25 @@
  * Author: Linus Walleij <linus.walleij at stericsson.com>
  */
 #include <linux/kernel.h>
-#include <linux/init.h>
-#include <linux/spinlock.h>
-#include <linux/interrupt.h>
-#include <linux/bitops.h>
-#include <linux/device.h>
-#include <linux/mm.h>
-#include <linux/termios.h>
-#include <linux/dmaengine.h>
-#include <linux/amba/bus.h>
 #include <linux/amba/mmci.h>
 #include <linux/amba/pl022.h>
 #include <linux/amba/serial.h>
-#include <linux/platform_device.h>
-#include <linux/gpio.h>
-#include <linux/clk.h>
-#include <linux/err.h>
-#include <linux/mtd/nand.h>
-#include <linux/mtd/fsmc.h>
 #include <linux/pinctrl/machine.h>
 #include <linux/pinctrl/pinconf-generic.h>
-#include <linux/dma-mapping.h>
 #include <linux/platform_data/clk-u300.h>
 #include <linux/platform_data/pinctrl-coh901.h>
 #include <linux/platform_data/dma-coh901318.h>
-#include <linux/irqchip/arm-vic.h>
 #include <linux/irqchip.h>
 #include <linux/of_platform.h>
+#include <linux/clk.h>
 
-#include <asm/types.h>
-#include <asm/setup.h>
-#include <asm/memory.h>
 #include <asm/mach/map.h>
-#include <asm/mach-types.h>
 #include <asm/mach/arch.h>
 
-#include <mach/hardware.h>
+#include <mach/u300-regs.h>
 #include <mach/syscon.h>
-#include <mach/irqs.h>
 
 #include "timer.h"
-#include "spi.h"
-#include "i2c.h"
-#include "u300-gpio.h"
 
 /*
  * Static I/O mappings that are needed for booting the U300 platforms. The
@@ -98,10 +74,6 @@ static struct amba_pl011_data uart0_plat_data = {
 #endif
 };
 
-/* Slow device at 0x3000 offset */
-static AMBA_APB_DEVICE(uart0, "uart0", 0, U300_UART0_BASE,
-	{ IRQ_U300_UART0 }, &uart0_plat_data);
-
 /* The U335 have an additional UART1 on the APP CPU */
 static struct amba_pl011_data uart1_plat_data = {
 #ifdef CONFIG_COH901318
@@ -111,31 +83,7 @@ static struct amba_pl011_data uart1_plat_data = {
 #endif
 };
 
-/* Fast device at 0x7000 offset */
-static AMBA_APB_DEVICE(uart1, "uart1", 0, U300_UART1_BASE,
-	{ IRQ_U300_UART1 }, &uart1_plat_data);
-
-/* AHB device at 0x4000 offset */
-static AMBA_APB_DEVICE(pl172, "pl172", 0, U300_EMIF_CFG_BASE, { }, NULL);
-
-/* Fast device at 0x6000 offset */
-static AMBA_APB_DEVICE(pl022, "pl022", 0, U300_SPI_BASE,
-	{ IRQ_U300_SPI }, NULL);
-
-/* Fast device at 0x1000 offset */
-#define U300_MMCSD_IRQS	{ IRQ_U300_MMCSD_MCIINTR0, IRQ_U300_MMCSD_MCIINTR1 }
-
 static struct mmci_platform_data mmcsd_platform_data = {
-	/*
-	 * Do not set ocr_mask or voltage translation function,
-	 * we have a regulator we can control instead.
-	 */
-	.f_max = 24000000,
-	.gpio_wp = -1,
-	.gpio_cd = U300_GPIO_PIN_MMC_CD,
-	.cd_invert = true,
-	.capabilities = MMC_CAP_MMC_HIGHSPEED |
-	MMC_CAP_SD_HIGHSPEED | MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA,
 #ifdef CONFIG_COH901318
 	.dma_filter = coh901318_filter_id,
 	.dma_rx_param = (void *) U300_DMA_MMCSD_RX_TX,
@@ -143,229 +91,6 @@ static struct mmci_platform_data mmcsd_platform_data = {
 #endif
 };
 
-static AMBA_APB_DEVICE(mmcsd, "mmci", 0, U300_MMCSD_BASE,
-	U300_MMCSD_IRQS, &mmcsd_platform_data);
-
-/*
- * The order of device declaration may be important, since some devices
- * have dependencies on other devices being initialized first.
- */
-static struct amba_device *amba_devs[] __initdata = {
-	&uart0_device,
-	&uart1_device,
-	&pl022_device,
-	&pl172_device,
-	&mmcsd_device,
-};
-
-/* Here follows a list of all hw resources that the platform devices
- * allocate. Note, clock dependencies are not included
- */
-
-static struct resource gpio_resources[] = {
-	{
-		.start = U300_GPIO_BASE,
-		.end   = (U300_GPIO_BASE + SZ_4K - 1),
-		.flags = IORESOURCE_MEM,
-	},
-	{
-		.name  = "gpio0",
-		.start = IRQ_U300_GPIO_PORT0,
-		.end   = IRQ_U300_GPIO_PORT0,
-		.flags = IORESOURCE_IRQ,
-	},
-	{
-		.name  = "gpio1",
-		.start = IRQ_U300_GPIO_PORT1,
-		.end   = IRQ_U300_GPIO_PORT1,
-		.flags = IORESOURCE_IRQ,
-	},
-	{
-		.name  = "gpio2",
-		.start = IRQ_U300_GPIO_PORT2,
-		.end   = IRQ_U300_GPIO_PORT2,
-		.flags = IORESOURCE_IRQ,
-	},
-	{
-		.name  = "gpio3",
-		.start = IRQ_U300_GPIO_PORT3,
-		.end   = IRQ_U300_GPIO_PORT3,
-		.flags = IORESOURCE_IRQ,
-	},
-	{
-		.name  = "gpio4",
-		.start = IRQ_U300_GPIO_PORT4,
-		.end   = IRQ_U300_GPIO_PORT4,
-		.flags = IORESOURCE_IRQ,
-	},
-	{
-		.name  = "gpio5",
-		.start = IRQ_U300_GPIO_PORT5,
-		.end   = IRQ_U300_GPIO_PORT5,
-		.flags = IORESOURCE_IRQ,
-	},
-	{
-		.name  = "gpio6",
-		.start = IRQ_U300_GPIO_PORT6,
-		.end   = IRQ_U300_GPIO_PORT6,
-		.flags = IORESOURCE_IRQ,
-	},
-};
-
-static struct resource keypad_resources[] = {
-	{
-		.start = U300_KEYPAD_BASE,
-		.end   = U300_KEYPAD_BASE + SZ_4K - 1,
-		.flags = IORESOURCE_MEM,
-	},
-	{
-		.name  = "coh901461-press",
-		.start = IRQ_U300_KEYPAD_KEYBF,
-		.end   = IRQ_U300_KEYPAD_KEYBF,
-		.flags = IORESOURCE_IRQ,
-	},
-	{
-		.name  = "coh901461-release",
-		.start = IRQ_U300_KEYPAD_KEYBR,
-		.end   = IRQ_U300_KEYPAD_KEYBR,
-		.flags = IORESOURCE_IRQ,
-	},
-};
-
-static struct resource rtc_resources[] = {
-	{
-		.start = U300_RTC_BASE,
-		.end   = U300_RTC_BASE + SZ_4K - 1,
-		.flags = IORESOURCE_MEM,
-	},
-	{
-		.start = IRQ_U300_RTC,
-		.end   = IRQ_U300_RTC,
-		.flags = IORESOURCE_IRQ,
-	},
-};
-
-/*
- * Fsmc does have IRQs: #43 and #44 (NFIF and NFIF2)
- * but these are not yet used by the driver.
- */
-static struct resource fsmc_resources[] = {
-	{
-		.name  = "nand_addr",
-		.start = U300_NAND_CS0_PHYS_BASE + PLAT_NAND_ALE,
-		.end   = U300_NAND_CS0_PHYS_BASE + PLAT_NAND_ALE + SZ_16K - 1,
-		.flags = IORESOURCE_MEM,
-	},
-	{
-		.name  = "nand_cmd",
-		.start = U300_NAND_CS0_PHYS_BASE + PLAT_NAND_CLE,
-		.end   = U300_NAND_CS0_PHYS_BASE + PLAT_NAND_CLE + SZ_16K - 1,
-		.flags = IORESOURCE_MEM,
-	},
-	{
-		.name  = "nand_data",
-		.start = U300_NAND_CS0_PHYS_BASE,
-		.end   = U300_NAND_CS0_PHYS_BASE + SZ_16K - 1,
-		.flags = IORESOURCE_MEM,
-	},
-	{
-		.name  = "fsmc_regs",
-		.start = U300_NAND_IF_PHYS_BASE,
-		.end   = U300_NAND_IF_PHYS_BASE + SZ_4K - 1,
-		.flags = IORESOURCE_MEM,
-	},
-};
-
-static struct resource i2c0_resources[] = {
-	{
-		.start = U300_I2C0_BASE,
-		.end   = U300_I2C0_BASE + SZ_4K - 1,
-		.flags = IORESOURCE_MEM,
-	},
-	{
-		.start = IRQ_U300_I2C0,
-		.end   = IRQ_U300_I2C0,
-		.flags = IORESOURCE_IRQ,
-	},
-};
-
-static struct resource i2c1_resources[] = {
-	{
-		.start = U300_I2C1_BASE,
-		.end   = U300_I2C1_BASE + SZ_4K - 1,
-		.flags = IORESOURCE_MEM,
-	},
-	{
-		.start = IRQ_U300_I2C1,
-		.end   = IRQ_U300_I2C1,
-		.flags = IORESOURCE_IRQ,
-	},
-
-};
-
-static struct resource wdog_resources[] = {
-	{
-		.start = U300_WDOG_BASE,
-		.end   = U300_WDOG_BASE + SZ_4K - 1,
-		.flags = IORESOURCE_MEM,
-	},
-	{
-		.start = IRQ_U300_WDOG,
-		.end   = IRQ_U300_WDOG,
-		.flags = IORESOURCE_IRQ,
-	}
-};
-
-static struct resource dma_resource[] = {
-	{
-		.start = U300_DMAC_BASE,
-		.end = U300_DMAC_BASE + PAGE_SIZE - 1,
-		.flags =  IORESOURCE_MEM,
-	},
-	{
-		.start = IRQ_U300_DMA,
-		.end = IRQ_U300_DMA,
-		.flags =  IORESOURCE_IRQ,
-	}
-};
-
-
-static struct resource pinctrl_resources[] = {
-	{
-		.start = U300_SYSCON_BASE,
-		.end   = U300_SYSCON_BASE + SZ_4K - 1,
-		.flags = IORESOURCE_MEM,
-	},
-};
-
-static struct platform_device wdog_device = {
-	.name = "coh901327_wdog",
-	.id = -1,
-	.num_resources = ARRAY_SIZE(wdog_resources),
-	.resource = wdog_resources,
-};
-
-static struct platform_device i2c0_device = {
-	.name = "stu300",
-	.id = 0,
-	.num_resources = ARRAY_SIZE(i2c0_resources),
-	.resource = i2c0_resources,
-};
-
-static struct platform_device i2c1_device = {
-	.name = "stu300",
-	.id = 1,
-	.num_resources = ARRAY_SIZE(i2c1_resources),
-	.resource = i2c1_resources,
-};
-
-static struct platform_device pinctrl_device = {
-	.name = "pinctrl-u300",
-	.id = -1,
-	.num_resources = ARRAY_SIZE(pinctrl_resources),
-	.resource = pinctrl_resources,
-};
-
 /*
  * The different variants have a few different versions of the
  * GPIO block, with different number of ports.
@@ -375,75 +100,6 @@ static struct u300_gpio_platform u300_gpio_plat = {
 	.gpio_base = 0,
 };
 
-static struct platform_device gpio_device = {
-	.name = "u300-gpio",
-	.id = -1,
-	.num_resources = ARRAY_SIZE(gpio_resources),
-	.resource = gpio_resources,
-	.dev = {
-		.platform_data = &u300_gpio_plat,
-	},
-};
-
-static struct platform_device keypad_device = {
-	.name = "keypad",
-	.id = -1,
-	.num_resources = ARRAY_SIZE(keypad_resources),
-	.resource = keypad_resources,
-};
-
-static struct platform_device rtc_device = {
-	.name = "rtc-coh901331",
-	.id = -1,
-	.num_resources = ARRAY_SIZE(rtc_resources),
-	.resource = rtc_resources,
-};
-
-static struct mtd_partition u300_partitions[] = {
-	{
-		.name = "bootrecords",
-		.offset = 0,
-		.size = SZ_128K,
-	},
-	{
-		.name = "free",
-		.offset = SZ_128K,
-		.size = 8064 * SZ_1K,
-	},
-	{
-		.name = "platform",
-		.offset = 8192 * SZ_1K,
-		.size = 253952 * SZ_1K,
-	},
-};
-
-static struct fsmc_nand_platform_data nand_platform_data = {
-	.partitions = u300_partitions,
-	.nr_partitions = ARRAY_SIZE(u300_partitions),
-	.options = NAND_SKIP_BBTSCAN,
-	.width = FSMC_NAND_BW8,
-};
-
-static struct platform_device nand_device = {
-	.name = "fsmc-nand",
-	.id = -1,
-	.resource = fsmc_resources,
-	.num_resources = ARRAY_SIZE(fsmc_resources),
-	.dev = {
-		.platform_data = &nand_platform_data,
-	},
-};
-
-static struct platform_device dma_device = {
-	.name		= "coh901318",
-	.id		= -1,
-	.resource	= dma_resource,
-	.num_resources  = ARRAY_SIZE(dma_resource),
-	.dev = {
-		.coherent_dma_mask = ~0,
-	},
-};
-
 static unsigned long pin_pullup_conf[] = {
 	PIN_CONF_PACKED(PIN_CONFIG_BIAS_PULL_UP, 1),
 };
@@ -470,61 +126,6 @@ static struct pinctrl_map __initdata u300_pinmux_map[] = {
 				    pin_highz_conf),
 };
 
-/*
- * Notice that AMBA devices are initialized before platform devices.
- *
- */
-static struct platform_device *platform_devs[] __initdata = {
-	&dma_device,
-	&i2c0_device,
-	&i2c1_device,
-	&keypad_device,
-	&rtc_device,
-	&pinctrl_device,
-	&gpio_device,
-	&nand_device,
-	&wdog_device,
-};
-
-/*
- * Interrupts: the U300 platforms have two pl190 ARM PrimeCells connected
- * together so some interrupts are connected to the first one and some
- * to the second one.
- */
-static void __init u300_init_irq(void)
-{
-	u32 mask[2] = {0, 0};
-	struct clk *clk;
-	int i;
-
-	/* initialize clocking early, we want to clock the INTCON */
-	u300_clk_init(U300_SYSCON_VBASE);
-
-	/* Bootstrap EMIF and SEMI clocks */
-	clk = clk_get_sys("pl172", NULL);
-	BUG_ON(IS_ERR(clk));
-	clk_prepare_enable(clk);
-	clk = clk_get_sys("semi", NULL);
-	BUG_ON(IS_ERR(clk));
-	clk_prepare_enable(clk);
-
-	/* Clock the interrupt controller */
-	clk = clk_get_sys("intcon", NULL);
-	BUG_ON(IS_ERR(clk));
-	clk_prepare_enable(clk);
-
-	for (i = 0; i < U300_VIC_IRQS_END; i++)
-		set_bit(i, (unsigned long *) &mask[0]);
-	vic_init((void __iomem *) U300_INTCON0_VBASE, IRQ_U300_INTCON0_START,
-		 mask[0], mask[0]);
-	vic_init((void __iomem *) U300_INTCON1_VBASE, IRQ_U300_INTCON1_START,
-		 mask[1], mask[1]);
-}
-
-
-/*
- * U300 platforms peripheral handling
- */
 struct db_chip {
 	u16 chipid;
 	const char *name;
@@ -603,74 +204,6 @@ static void __init u300_init_check_chip(void)
 	}
 }
 
-/*
- * Some devices and their resources require reserved physical memory from
- * the end of the available RAM. This function traverses the list of devices
- * and assigns actual addresses to these.
- */
-static void __init u300_assign_physmem(void)
-{
-	unsigned long curr_start = __pa(high_memory);
-	int i, j;
-
-	for (i = 0; i < ARRAY_SIZE(platform_devs); i++) {
-		for (j = 0; j < platform_devs[i]->num_resources; j++) {
-			struct resource *const res =
-			  &platform_devs[i]->resource[j];
-
-			if (IORESOURCE_MEM == res->flags &&
-				     0 == res->start) {
-				res->start  = curr_start;
-				res->end   += curr_start;
-				curr_start += resource_size(res);
-
-				printk(KERN_INFO "core.c: Mapping RAM " \
-				       "%#x-%#x to device %s:%s\n",
-					res->start, res->end,
-				       platform_devs[i]->name, res->name);
-			}
-		}
-	}
-}
-
-static void __init u300_init_machine(void)
-{
-	int i;
-	u16 val;
-
-	/* Check what platform we run and print some status information */
-	u300_init_check_chip();
-
-	/* Initialize SPI device with some board specifics */
-	u300_spi_init(&pl022_device);
-
-	/* Register the AMBA devices in the AMBA bus abstraction layer */
-	for (i = 0; i < ARRAY_SIZE(amba_devs); i++) {
-		struct amba_device *d = amba_devs[i];
-		amba_device_register(d, &iomem_resource);
-	}
-
-	u300_assign_physmem();
-
-	/* Initialize pinmuxing */
-	pinctrl_register_mappings(u300_pinmux_map,
-				  ARRAY_SIZE(u300_pinmux_map));
-
-	/* Register subdevices on the I2C buses */
-	u300_i2c_register_board_devices();
-
-	/* Register the platform devices */
-	platform_add_devices(platform_devs, ARRAY_SIZE(platform_devs));
-
-	/* Register subdevices on the SPI bus */
-	u300_spi_register_board_devices();
-
-	/* Enable SEMI self refresh */
-	val = readw(U300_SYSCON_VBASE + U300_SYSCON_SMCR) |
-		U300_SYSCON_SMCR_SEMI_SREFREQ_ENABLE;
-	writew(val, U300_SYSCON_VBASE + U300_SYSCON_SMCR);
-}
-
 /* Forward declare this function from the watchdog */
 void coh901327_watchdog_reset(void);
 
@@ -691,19 +224,6 @@ static void u300_restart(char mode, const char *cmd)
 	while (1);
 }
 
-MACHINE_START(U300, "Ericsson AB U335 S335/B335 Prototype Board")
-	/* Maintainer: Linus Walleij <linus.walleij at stericsson.com> */
-	.atag_offset	= 0x100,
-	.map_io		= u300_map_io,
-	.nr_irqs	= 0,
-	.init_irq	= u300_init_irq,
-	.init_time	= u300_timer_init,
-	.init_machine	= u300_init_machine,
-	.restart	= u300_restart,
-MACHINE_END
-
-#ifdef CONFIG_OF
-
 static struct pl022_ssp_controller spi_plat_data = {
 	/* If you have several SPI buses this varies, we have only bus 0 */
 	.bus_id = 0,
@@ -779,8 +299,6 @@ static void __init u300_init_machine_dt(void)
 	/* Check what platform we run and print some status information */
 	u300_init_check_chip();
 
-	u300_assign_physmem();
-
 	/* Initialize pinmuxing */
 	pinctrl_register_mappings(u300_pinmux_map,
 				  ARRAY_SIZE(u300_pinmux_map));
@@ -807,5 +325,3 @@ DT_MACHINE_START(U300_DT, "U300 S335/B335 (Device Tree)")
 	.restart	= u300_restart,
 	.dt_compat      = u300_board_compat,
 MACHINE_END
-
-#endif /* CONFIG_OF */
diff --git a/arch/arm/mach-u300/i2c.c b/arch/arm/mach-u300/i2c.c
deleted file mode 100644
index 96800aa..0000000
--- a/arch/arm/mach-u300/i2c.c
+++ /dev/null
@@ -1,285 +0,0 @@
-/*
- * arch/arm/mach-u300/i2c.c
- *
- * Copyright (C) 2009-2012 ST-Ericsson AB
- * License terms: GNU General Public License (GPL) version 2
- *
- * Register board i2c devices
- * Author: Linus Walleij <linus.walleij at stericsson.com>
- */
-#include <linux/kernel.h>
-#include <linux/i2c.h>
-#include <linux/mfd/ab3100.h>
-#include <linux/regulator/machine.h>
-#include <linux/amba/bus.h>
-#include <mach/irqs.h>
-
-/*
- * Initial settings of ab3100 registers.
- * Common for below LDO regulator settings are that
- * bit 7-5 controls voltage. Bit 4 turns regulator ON(1) or OFF(0).
- * Bit 3-2 controls sleep enable and bit 1-0 controls sleep mode.
- */
-
-/* LDO_A 0x16: 2.75V, ON, SLEEP_A, SLEEP OFF GND */
-#define LDO_A_SETTING		0x16
-/* LDO_C 0x10: 2.65V, ON, SLEEP_A or B, SLEEP full power */
-#define LDO_C_SETTING		0x10
-/* LDO_D 0x10: 2.65V, ON, sleep mode not used */
-#define LDO_D_SETTING		0x10
-/* LDO_E 0x10: 1.8V, ON, SLEEP_A or B, SLEEP full power */
-#define LDO_E_SETTING		0x10
-/* LDO_E SLEEP 0x00: 1.8V, not used, SLEEP_A or B, not used */
-#define LDO_E_SLEEP_SETTING	0x00
-/* LDO_F 0xD0: 2.5V, ON, SLEEP_A or B, SLEEP full power */
-#define LDO_F_SETTING		0xD0
-/* LDO_G 0x00: 2.85V, OFF, SLEEP_A or B, SLEEP full power */
-#define LDO_G_SETTING		0x00
-/* LDO_H 0x18: 2.75V, ON, SLEEP_B, SLEEP full power */
-#define LDO_H_SETTING		0x18
-/* LDO_K 0x00: 2.75V, OFF, SLEEP_A or B, SLEEP full power */
-#define LDO_K_SETTING		0x00
-/* LDO_EXT 0x00: Voltage not set, OFF, not used, not used */
-#define LDO_EXT_SETTING		0x00
-/* BUCK 0x7D: 1.2V, ON, SLEEP_A and B, SLEEP low power */
-#define BUCK_SETTING	0x7D
-/* BUCK SLEEP 0xAC: 1.05V, Not used, SLEEP_A and B, Not used */
-#define BUCK_SLEEP_SETTING	0xAC
-
-#ifdef CONFIG_AB3100_CORE
-static struct regulator_consumer_supply supply_ldo_c[] = {
-	{
-		.dev_name = "ab3100-codec",
-		.supply = "vaudio", /* Powers the codec */
-	},
-};
-
-/*
- * This one needs to be a supply so we can turn it off
- * in order to shut down the system.
- */
-static struct regulator_consumer_supply supply_ldo_d[] = {
-	{
-		.supply = "vana15", /* Powers the SoC (CPU etc) */
-	},
-};
-
-static struct regulator_consumer_supply supply_ldo_g[] = {
-	{
-		.dev_name = "mmci",
-		.supply = "vmmc", /* Powers MMC/SD card */
-	},
-};
-
-static struct regulator_consumer_supply supply_ldo_h[] = {
-	{
-		.dev_name = "xgam_pdi",
-		.supply = "vdisp", /* Powers camera, display etc */
-	},
-};
-
-static struct regulator_consumer_supply supply_ldo_k[] = {
-	{
-		.dev_name = "irda",
-		.supply = "vir", /* Power IrDA */
-	},
-};
-
-/*
- * This is a placeholder for whoever wish to use the
- * external power.
- */
-static struct regulator_consumer_supply supply_ldo_ext[] = {
-	{
-		.supply = "vext", /* External power */
-	},
-};
-
-/* Preset (hardware defined) voltages for these regulators */
-#define LDO_A_VOLTAGE 2750000
-#define LDO_C_VOLTAGE 2650000
-#define LDO_D_VOLTAGE 2650000
-
-static struct ab3100_platform_data ab3100_plf_data = {
-	.reg_constraints = {
-		/* LDO A routing and constraints */
-		{
-			.constraints = {
-				.name = "vrad",
-				.min_uV = LDO_A_VOLTAGE,
-				.max_uV = LDO_A_VOLTAGE,
-				.valid_modes_mask = REGULATOR_MODE_NORMAL,
-				.always_on = 1,
-				.boot_on = 1,
-			},
-		},
-		/* LDO C routing and constraints */
-		{
-			.constraints = {
-				.min_uV = LDO_C_VOLTAGE,
-				.max_uV = LDO_C_VOLTAGE,
-				.valid_modes_mask = REGULATOR_MODE_NORMAL,
-			},
-			.num_consumer_supplies = ARRAY_SIZE(supply_ldo_c),
-			.consumer_supplies = supply_ldo_c,
-		},
-		/* LDO D routing and constraints */
-		{
-			.constraints = {
-				.min_uV = LDO_D_VOLTAGE,
-				.max_uV = LDO_D_VOLTAGE,
-				.valid_modes_mask = REGULATOR_MODE_NORMAL,
-				.valid_ops_mask = REGULATOR_CHANGE_STATUS,
-				/*
-				 * Actually this is boot_on but we need
-				 * to reference count it externally to
-				 * be able to shut down the system.
-				 */
-			},
-			.num_consumer_supplies = ARRAY_SIZE(supply_ldo_d),
-			.consumer_supplies = supply_ldo_d,
-		},
-		/* LDO E routing and constraints */
-		{
-			.constraints = {
-				.name = "vio",
-				.min_uV = 1800000,
-				.max_uV = 1800000,
-				.valid_modes_mask = REGULATOR_MODE_NORMAL,
-				.always_on = 1,
-				.boot_on = 1,
-			},
-		},
-		/* LDO F routing and constraints */
-		{
-			.constraints = {
-				.name = "vana25",
-				.min_uV = 2500000,
-				.max_uV = 2500000,
-				.valid_modes_mask = REGULATOR_MODE_NORMAL,
-				.always_on = 1,
-				.boot_on = 1,
-			},
-		},
-		/* LDO G routing and constraints */
-		{
-			.constraints = {
-				.min_uV = 1500000,
-				.max_uV = 2850000,
-				.valid_modes_mask = REGULATOR_MODE_NORMAL,
-				.valid_ops_mask =
-				REGULATOR_CHANGE_VOLTAGE |
-				REGULATOR_CHANGE_STATUS,
-			},
-			.num_consumer_supplies = ARRAY_SIZE(supply_ldo_g),
-			.consumer_supplies = supply_ldo_g,
-		},
-		/* LDO H routing and constraints */
-		{
-			.constraints = {
-				.min_uV = 1200000,
-				.max_uV = 2750000,
-				.valid_modes_mask = REGULATOR_MODE_NORMAL,
-				.valid_ops_mask =
-				REGULATOR_CHANGE_VOLTAGE |
-				REGULATOR_CHANGE_STATUS,
-			},
-			.num_consumer_supplies = ARRAY_SIZE(supply_ldo_h),
-			.consumer_supplies = supply_ldo_h,
-		},
-		/* LDO K routing and constraints */
-		{
-			.constraints = {
-				.min_uV = 1800000,
-				.max_uV = 2750000,
-				.valid_modes_mask = REGULATOR_MODE_NORMAL,
-				.valid_ops_mask =
-				REGULATOR_CHANGE_VOLTAGE |
-				REGULATOR_CHANGE_STATUS,
-			},
-			.num_consumer_supplies = ARRAY_SIZE(supply_ldo_k),
-			.consumer_supplies = supply_ldo_k,
-		},
-		/* External regulator interface. No fixed voltage specified.
-		 * If we knew the voltage of the external regulator and it
-		 * was connected on the board, we could add the (fixed)
-		 * voltage for it here.
-		 */
-		{
-			.constraints = {
-				.min_uV = 0,
-				.max_uV = 0,
-				.valid_modes_mask = REGULATOR_MODE_NORMAL,
-				.valid_ops_mask =
-				REGULATOR_CHANGE_STATUS,
-			},
-			.num_consumer_supplies = ARRAY_SIZE(supply_ldo_ext),
-			.consumer_supplies = supply_ldo_ext,
-		},
-		/* Buck converter routing and constraints */
-		{
-			.constraints = {
-				.name = "vcore",
-				.min_uV = 1200000,
-				.max_uV = 1800000,
-				.valid_modes_mask = REGULATOR_MODE_NORMAL,
-				.valid_ops_mask =
-				REGULATOR_CHANGE_VOLTAGE,
-				.always_on = 1,
-				.boot_on = 1,
-			},
-		},
-	},
-	.reg_initvals = {
-		LDO_A_SETTING,
-		LDO_C_SETTING,
-		LDO_E_SETTING,
-		LDO_E_SLEEP_SETTING,
-		LDO_F_SETTING,
-		LDO_G_SETTING,
-		LDO_H_SETTING,
-		LDO_K_SETTING,
-		LDO_EXT_SETTING,
-		BUCK_SETTING,
-		BUCK_SLEEP_SETTING,
-		LDO_D_SETTING,
-	},
-};
-#endif
-
-static struct i2c_board_info __initdata bus0_i2c_board_info[] = {
-#ifdef CONFIG_AB3100_CORE
-	{
-		.type = "ab3100",
-		.addr = 0x48,
-		.irq = IRQ_U300_IRQ0_EXT,
-		.platform_data = &ab3100_plf_data,
-	},
-#else
-	{ },
-#endif
-};
-
-static struct i2c_board_info __initdata bus1_i2c_board_info[] = {
-	{
-		.type = "fwcam",
-		.addr = 0x10,
-	},
-	{
-		.type = "fwcam",
-		.addr = 0x5d,
-	},
-};
-
-void __init u300_i2c_register_board_devices(void)
-{
-	i2c_register_board_info(0, bus0_i2c_board_info,
-				ARRAY_SIZE(bus0_i2c_board_info));
-	/*
-	 * This makes the core shut down all unused regulators
-	 * after all the initcalls have completed.
-	 */
-	regulator_has_full_constraints();
-	i2c_register_board_info(1, bus1_i2c_board_info,
-				ARRAY_SIZE(bus1_i2c_board_info));
-}
diff --git a/arch/arm/mach-u300/i2c.h b/arch/arm/mach-u300/i2c.h
deleted file mode 100644
index 485c02e..0000000
--- a/arch/arm/mach-u300/i2c.h
+++ /dev/null
@@ -1,23 +0,0 @@
-/*
- * arch/arm/mach-u300/i2c.h
- *
- * Copyright (C) 2009 ST-Ericsson AB
- * License terms: GNU General Public License (GPL) version 2
- *
- * Register board i2c devices
- * Author: Linus Walleij <linus.walleij at stericsson.com>
- */
-
-#ifndef MACH_U300_I2C_H
-#define MACH_U300_I2C_H
-
-#ifdef CONFIG_I2C_STU300
-void __init u300_i2c_register_board_devices(void);
-#else
-/* Compile out this stuff if no I2C adapter is available */
-static inline void __init u300_i2c_register_board_devices(void)
-{
-}
-#endif
-
-#endif
diff --git a/arch/arm/mach-u300/regulator.c b/arch/arm/mach-u300/regulator.c
index 8a67dc6..bbda954 100644
--- a/arch/arm/mach-u300/regulator.c
+++ b/arch/arm/mach-u300/regulator.c
@@ -58,10 +58,7 @@ static int __init __u300_init_boardpower(struct platform_device *pdev)
 	u32 val;
 
 	pr_info("U300: setting up board power\n");
-	if (pdev)
-		main_power_15 = regulator_get(&pdev->dev, "vana15");
-	else
-		main_power_15 = regulator_get(NULL, "vana15");
+	main_power_15 = regulator_get(&pdev->dev, "vana15");
 
 	if (IS_ERR(main_power_15)) {
 		pr_err("could not get vana15");
@@ -114,11 +111,8 @@ static struct platform_driver s365_board_driver = {
  */
 static int __init u300_init_boardpower(void)
 {
-	if (of_have_populated_dt())
-		return platform_driver_probe(&s365_board_driver,
-					     s365_board_probe);
-	/* Only call this on non-DT boots */
-	return __u300_init_boardpower(NULL);
+	return platform_driver_probe(&s365_board_driver,
+				     s365_board_probe);
 }
 
 device_initcall(u300_init_boardpower);
diff --git a/arch/arm/mach-u300/spi.c b/arch/arm/mach-u300/spi.c
deleted file mode 100644
index 9106982..0000000
--- a/arch/arm/mach-u300/spi.c
+++ /dev/null
@@ -1,102 +0,0 @@
-/*
- * arch/arm/mach-u300/spi.c
- *
- * Copyright (C) 2009 ST-Ericsson AB
- * License terms: GNU General Public License (GPL) version 2
- *
- * Author: Linus Walleij <linus.walleij at stericsson.com>
- */
-#include <linux/device.h>
-#include <linux/amba/bus.h>
-#include <linux/spi/spi.h>
-#include <linux/amba/pl022.h>
-#include <linux/platform_data/dma-coh901318.h>
-#include <linux/err.h>
-
-/*
- * The following is for the actual devices on the SSP/SPI bus
- */
-#ifdef CONFIG_MACH_U300_SPIDUMMY
-static void select_dummy_chip(u32 chipselect)
-{
-	pr_debug("CORE: %s called with CS=0x%x (%s)\n",
-		 __func__,
-		 chipselect,
-		 chipselect ? "unselect chip" : "select chip");
-	/*
-	 * Here you would write the chip select value to the GPIO pins if
-	 * this was a real chip (but this is a loopback dummy).
-	 */
-}
-
-struct pl022_config_chip dummy_chip_info = {
-	/* available POLLING_TRANSFER, INTERRUPT_TRANSFER, DMA_TRANSFER */
-	.com_mode = DMA_TRANSFER,
-	.iface = SSP_INTERFACE_MOTOROLA_SPI,
-	/* We can only act as master but SSP_SLAVE is possible in theory */
-	.hierarchy = SSP_MASTER,
-	/* 0 = drive TX even as slave, 1 = do not drive TX as slave */
-	.slave_tx_disable = 0,
-	.rx_lev_trig = SSP_RX_4_OR_MORE_ELEM,
-	.tx_lev_trig = SSP_TX_4_OR_MORE_EMPTY_LOC,
-	.ctrl_len = SSP_BITS_12,
-	.wait_state = SSP_MWIRE_WAIT_ZERO,
-	.duplex = SSP_MICROWIRE_CHANNEL_FULL_DUPLEX,
-	/*
-	 * This is where you insert a call to a function to enable CS
-	 * (usually GPIO) for a certain chip.
-	 */
-	.cs_control = select_dummy_chip,
-};
-#endif
-
-static struct spi_board_info u300_spi_devices[] = {
-#ifdef CONFIG_MACH_U300_SPIDUMMY
-	{
-		/* A dummy chip used for loopback tests */
-		.modalias       = "spi-dummy",
-		/* Really dummy, pass in additional chip config here */
-		.platform_data  = NULL,
-		/* This defines how the controller shall handle the device */
-		.controller_data = &dummy_chip_info,
-		/* .irq - no external IRQ routed from this device */
-		.max_speed_hz   = 1000000,
-		.bus_num        = 0, /* Only one bus on this chip */
-		.chip_select    = 0,
-		/* Means SPI_CS_HIGH, change if e.g low CS */
-		.mode           = SPI_MODE_1 | SPI_LOOP,
-	},
-#endif
-};
-
-static struct pl022_ssp_controller ssp_platform_data = {
-	/* If you have several SPI buses this varies, we have only bus 0 */
-	.bus_id = 0,
-	/*
-	 * On the APP CPU GPIO 4, 5 and 6 are connected as generic
-	 * chip selects for SPI. (Same on U330, U335 and U365.)
-	 * TODO: make sure the GPIO driver can select these properly
-	 * and do padmuxing accordingly too.
-	 */
-	.num_chipselect = 3,
-#ifdef CONFIG_COH901318
-	.enable_dma = 1,
-	.dma_filter = coh901318_filter_id,
-	.dma_rx_param = (void *) U300_DMA_SPI_RX,
-	.dma_tx_param = (void *) U300_DMA_SPI_TX,
-#else
-	.enable_dma = 0,
-#endif
-};
-
-
-void __init u300_spi_init(struct amba_device *adev)
-{
-	adev->dev.platform_data = &ssp_platform_data;
-}
-
-void __init u300_spi_register_board_devices(void)
-{
-	/* Register any SPI devices */
-	spi_register_board_info(u300_spi_devices, ARRAY_SIZE(u300_spi_devices));
-}
diff --git a/arch/arm/mach-u300/spi.h b/arch/arm/mach-u300/spi.h
deleted file mode 100644
index bd3d867..0000000
--- a/arch/arm/mach-u300/spi.h
+++ /dev/null
@@ -1,26 +0,0 @@
-/*
- * arch/arm/mach-u300/spi.h
- *
- * Copyright (C) 2009 ST-Ericsson AB
- * License terms: GNU General Public License (GPL) version 2
- *
- * Author: Linus Walleij <linus.walleij at stericsson.com>
- */
-#ifndef SPI_H
-#define SPI_H
-#include <linux/amba/bus.h>
-
-#ifdef CONFIG_SPI_PL022
-void __init u300_spi_init(struct amba_device *adev);
-void __init u300_spi_register_board_devices(void);
-#else
-/* Compile out SPI support if PL022 is not selected */
-static inline void __init u300_spi_init(struct amba_device *adev)
-{
-}
-static inline void __init u300_spi_register_board_devices(void)
-{
-}
-#endif
-
-#endif
diff --git a/arch/arm/mach-u300/timer.c b/arch/arm/mach-u300/timer.c
index 5e60a5e..310dab6 100644
--- a/arch/arm/mach-u300/timer.c
+++ b/arch/arm/mach-u300/timer.c
@@ -366,24 +366,22 @@ void __init u300_timer_init(void)
 	struct clk *clk;
 	unsigned long rate;
 	int irq = 0;
-
-#ifdef CONFIG_OF
 	struct device_node *timer = NULL;
+	struct resource irq_res;
 
 	timer = of_find_node_by_path("/timer0 at c0014000");
-	if (timer) {
-		struct resource irq_res;
+	if (!timer)
+		panic("no system timer\n");
 
-		u300_timer_base = of_iomap(timer, 0);
-		/* Get the IRQ for the GP1 timer */
-		irq = of_irq_to_resource(timer, 2, &irq_res);
-	}
-#endif
-	/* Fallback to static maps if base & IRQ not found in DT */
+	u300_timer_base = of_iomap(timer, 0);
 	if (!u300_timer_base)
-		u300_timer_base = U300_TIMER_APP_VBASE;
+		panic("could not ioremap system timer\n");
+
+	/* Get the IRQ for the GP1 timer */
+	irq = of_irq_to_resource(timer, 2, &irq_res);
 	if (irq <= 0)
-		irq = IRQ_U300_TIMER_APP_GP1;
+		panic("no IRQ for system timer\n");
+
 	pr_info("U300 GP1 timer @ base: %p, IRQ: %d\n", u300_timer_base, irq);
 
 	/* Clock the interrupt controller */
diff --git a/arch/arm/mach-u300/u300-gpio.h b/arch/arm/mach-u300/u300-gpio.h
deleted file mode 100644
index 83f5077..0000000
--- a/arch/arm/mach-u300/u300-gpio.h
+++ /dev/null
@@ -1,70 +0,0 @@
-/*
- * Individual pin assignments for the B335/S335.
- * Notice that the actual usage of these pins depends on the
- * PAD MUX settings, that is why the same number can potentially
- * appear several times. In the reference design each pin is only
- * used for one purpose. These were determined by inspecting the
- * S365 schematic.
- */
-#define U300_GPIO_PIN_UART_RX		0
-#define U300_GPIO_PIN_UART_TX		1
-#define U300_GPIO_PIN_UART_CTS		2
-#define U300_GPIO_PIN_UART_RTS		3
-#define U300_GPIO_PIN_CAM_MAIN_STANDBY	4 /* Camera MAIN standby */
-#define U300_GPIO_PIN_GPIO05		5 /* Unrouted */
-#define U300_GPIO_PIN_MS_CD		6 /* Memory Stick Card insertion */
-#define U300_GPIO_PIN_GPIO07		7 /* Test point TP2430 */
-
-#define U300_GPIO_PIN_GPIO08		8 /* Test point TP2437 */
-#define U300_GPIO_PIN_GPIO09		9 /* Test point TP2431 */
-#define U300_GPIO_PIN_GPIO10		10 /* Test point TP2432 */
-#define U300_GPIO_PIN_MMC_CLKRET	11 /* Clock return from MMC/SD card */
-#define U300_GPIO_PIN_MMC_CD		12 /* MMC Card insertion detection */
-#define U300_GPIO_PIN_CAM_SUB_STANDBY	13 /* Camera SUB standby */
-#define U300_GPIO_PIN_GPIO14		14 /* Test point TP2436 */
-#define U300_GPIO_PIN_GPIO15		15 /* Unrouted */
-
-#define U300_GPIO_PIN_GPIO16		16 /* Test point TP2438 */
-#define U300_GPIO_PIN_PHFSENSE		17 /* Headphone jack sensing */
-#define U300_GPIO_PIN_GPIO18		18 /* Test point TP2439 */
-#define U300_GPIO_PIN_GPIO19		19 /* Routed somewhere */
-#define U300_GPIO_PIN_GPIO20		20 /* Unrouted */
-#define U300_GPIO_PIN_GPIO21		21 /* Unrouted */
-#define U300_GPIO_PIN_GPIO22		22 /* Unrouted */
-#define U300_GPIO_PIN_GPIO23		23 /* Unrouted */
-
-#define U300_GPIO_PIN_GPIO24		24 /* Unrouted */
-#define U300_GPIO_PIN_GPIO25		25 /* Unrouted */
-#define U300_GPIO_PIN_GPIO26		26 /* Unrouted */
-#define U300_GPIO_PIN_GPIO27		27 /* Unrouted */
-#define U300_GPIO_PIN_GPIO28		28 /* Unrouted */
-#define U300_GPIO_PIN_GPIO29		29 /* Unrouted */
-#define U300_GPIO_PIN_GPIO30		30 /* Unrouted */
-#define U300_GPIO_PIN_GPIO31		31 /* Unrouted */
-
-#define U300_GPIO_PIN_GPIO32		32 /* Unrouted */
-#define U300_GPIO_PIN_GPIO33		33 /* Unrouted */
-#define U300_GPIO_PIN_GPIO34		34 /* Unrouted */
-#define U300_GPIO_PIN_GPIO35		35 /* Unrouted */
-#define U300_GPIO_PIN_GPIO36		36 /* Unrouted */
-#define U300_GPIO_PIN_GPIO37		37 /* Unrouted */
-#define U300_GPIO_PIN_GPIO38		38 /* Unrouted */
-#define U300_GPIO_PIN_GPIO39		39 /* Unrouted */
-
-#define U300_GPIO_PIN_GPIO40		40 /* Unrouted */
-#define U300_GPIO_PIN_GPIO41		41 /* Unrouted */
-#define U300_GPIO_PIN_GPIO42		42 /* Unrouted */
-#define U300_GPIO_PIN_GPIO43		43 /* Unrouted */
-#define U300_GPIO_PIN_GPIO44		44 /* Unrouted */
-#define U300_GPIO_PIN_GPIO45		45 /* Unrouted */
-#define U300_GPIO_PIN_GPIO46		46 /* Unrouted */
-#define U300_GPIO_PIN_GPIO47		47 /* Unrouted */
-
-#define U300_GPIO_PIN_GPIO48		48 /* Unrouted */
-#define U300_GPIO_PIN_GPIO49		49 /* Unrouted */
-#define U300_GPIO_PIN_GPIO50		50 /* Unrouted */
-#define U300_GPIO_PIN_GPIO51		51 /* Unrouted */
-#define U300_GPIO_PIN_GPIO52		52 /* Unrouted */
-#define U300_GPIO_PIN_GPIO53		53 /* Unrouted */
-#define U300_GPIO_PIN_GPIO54		54 /* Unrouted */
-#define U300_GPIO_PIN_GPIO55		55 /* Unrouted */
-- 
1.7.11.3



From maxime.ripard at free-electrons.com  Mon Apr 22 06:02:22 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Mon, 22 Apr 2013 12:02:22 +0200
Subject: [PATCH 1/4] ARM: cfa10036: dt: Change i2c0 clock frequency
In-Reply-To: <1366624945-5708-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1366624945-5708-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1366624945-5708-2-git-send-email-maxime.ripard@free-electrons.com>

The OLED display can work faster. Change the i2c controller clock
frequency to remove the tearing effect that can be seen on the display.

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 arch/arm/boot/dts/imx28-cfa10036.dts |    1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/imx28-cfa10036.dts b/arch/arm/boot/dts/imx28-cfa10036.dts
index 40488f5a8..a524caf 100644
--- a/arch/arm/boot/dts/imx28-cfa10036.dts
+++ b/arch/arm/boot/dts/imx28-cfa10036.dts
@@ -67,6 +67,7 @@
 			i2c0: i2c at 80058000 {
 				pinctrl-names = "default";
 				pinctrl-0 = <&i2c0_pins_b>;
+				clock-frequency = <400000>;
 				status = "okay";
 
 				ssd1306: oled at 3c {
-- 
1.7.10.4



From maxime.ripard at free-electrons.com  Mon Apr 22 06:02:21 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Mon, 22 Apr 2013 12:02:21 +0200
Subject: [PATCH 0/4] drivers: video: Optimisations for the ssd1307fb driver
Message-ID: <1366624945-5708-1-git-send-email-maxime.ripard@free-electrons.com>

Hi everyone,

This is a patchset to improve significantly (by an order of magnitude)
the refreshing time of the SSD1306 and SSD1307.

We do so by sending the pixels by batches, instead of 8 at a time,
combined with some additionnal features found on these controllers
that allows to send a whole screen content at once.

This obviously removes the tearing effect that was previously seen
with these controllers.

This patchset depends on the "Add support for the Solomon SSD1306 OLED
Controller" I sent previously.

Thanks,
Maxime

Maxime Ripard (4):
  ARM: cfa10036: dt: Change i2c0 clock frequency
  ssd1307fb: Rework the communication functions
  ssd1307fb: Speed up the communication with the controller
  ssd1307fb: Make use of horizontal addressing mode

 arch/arm/boot/dts/imx28-cfa10036.dts |    1 +
 drivers/video/ssd1307fb.c            |  123 ++++++++++++++++++++++++----------
 2 files changed, 89 insertions(+), 35 deletions(-)

-- 
1.7.10.4



From maxime.ripard at free-electrons.com  Mon Apr 22 06:02:23 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Mon, 22 Apr 2013 12:02:23 +0200
Subject: [PATCH 2/4] ssd1307fb: Rework the communication functions
In-Reply-To: <1366624945-5708-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1366624945-5708-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1366624945-5708-3-git-send-email-maxime.ripard@free-electrons.com>

To efficiently send a whole page to the display, we need to be able to
manipulate more easily the data arrays that has to be sent to the OLED
controller. As such, this patch introduces a ssd1307fb_array structure
that handles both the small header to be sent over i2c, which contains
the type of information sent, and the raw bytes after that.

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 drivers/video/ssd1307fb.c |   77 +++++++++++++++++++++++++++++----------------
 1 file changed, 50 insertions(+), 27 deletions(-)

diff --git a/drivers/video/ssd1307fb.c b/drivers/video/ssd1307fb.c
index 5ab5281..35f5348 100644
--- a/drivers/video/ssd1307fb.c
+++ b/drivers/video/ssd1307fb.c
@@ -51,6 +51,11 @@ struct ssd1307fb_par {
 	u32 width;
 };
 
+struct ssd1307fb_array {
+	u8	type;
+	u8	data[0];
+};
+
 static struct fb_fix_screeninfo ssd1307fb_fix = {
 	.id		= "Solomon SSD1307",
 	.type		= FB_TYPE_PACKED_PIXELS,
@@ -65,49 +70,67 @@ static struct fb_var_screeninfo ssd1307fb_var = {
 	.bits_per_pixel	= 1,
 };
 
-static int ssd1307fb_write_array(struct i2c_client *client, u8 type, u8 *cmd, u32 len)
+static struct ssd1307fb_array *ssd1307fb_alloc_array(u32 len, u8 type)
 {
-	u8 *buf;
-	int ret = 0;
-
-	buf = kzalloc(len + 1, GFP_KERNEL);
-	if (!buf) {
-		dev_err(&client->dev, "Couldn't allocate sending buffer.\n");
-		return -ENOMEM;
-	}
+	struct ssd1307fb_array *array;
 
-	buf[0] = type;
-	memcpy(buf + 1, cmd, len);
+	array = kzalloc(sizeof(struct ssd1307fb_array) + len, GFP_KERNEL);
+	if (!array)
+		return NULL;
 
-	ret = i2c_master_send(client, buf, len + 1);
-	if (ret != len + 1) {
-		dev_err(&client->dev, "Couldn't send I2C command.\n");
-		goto error;
-	}
+	array->type = type;
 
-error:
-	kfree(buf);
-	return ret;
+	return array;
 }
 
-static inline int ssd1307fb_write_cmd_array(struct i2c_client *client, u8 *cmd, u32 len)
+static int ssd1307fb_write_array(struct i2c_client *client,
+				 struct ssd1307fb_array *array, u32 len)
 {
-	return ssd1307fb_write_array(client, SSD1307FB_COMMAND, cmd, len);
+	int ret;
+
+	len += sizeof(struct ssd1307fb_array);
+
+	ret = i2c_master_send(client, (u8 *)array, len);
+	if (ret != len) {
+		dev_err(&client->dev, "Couldn't send I2C command.\n");
+		return ret;
+	}
+
+	return 0;
 }
 
 static inline int ssd1307fb_write_cmd(struct i2c_client *client, u8 cmd)
 {
-	return ssd1307fb_write_cmd_array(client, &cmd, 1);
-}
+	struct ssd1307fb_array *array;
+	int ret;
 
-static inline int ssd1307fb_write_data_array(struct i2c_client *client, u8 *cmd, u32 len)
-{
-	return ssd1307fb_write_array(client, SSD1307FB_DATA, cmd, len);
+	array = ssd1307fb_alloc_array(1, SSD1307FB_COMMAND);
+	if (!array)
+		return -ENOMEM;
+
+	array->data[0] = cmd;
+
+	ret = ssd1307fb_write_array(client, array, 1);
+	kfree(array);
+
+	return ret;
 }
 
 static inline int ssd1307fb_write_data(struct i2c_client *client, u8 data)
 {
-	return ssd1307fb_write_data_array(client, &data, 1);
+	struct ssd1307fb_array *array;
+	int ret;
+
+	array = ssd1307fb_alloc_array(1, SSD1307FB_DATA);
+	if (!array)
+		return -ENOMEM;
+
+	array->data[0] = data;
+
+	ret = ssd1307fb_write_array(client, array, 1);
+	kfree(array);
+
+	return ret;
 }
 
 static void ssd1307fb_update_display(struct ssd1307fb_par *par)
-- 
1.7.10.4



From maxime.ripard at free-electrons.com  Mon Apr 22 06:02:24 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Mon, 22 Apr 2013 12:02:24 +0200
Subject: [PATCH 3/4] ssd1307fb: Speed up the communication with the controller
In-Reply-To: <1366624945-5708-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1366624945-5708-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1366624945-5708-4-git-send-email-maxime.ripard@free-electrons.com>

The code until now was sending only 1pixel-wide page segment at once,
and started a new transfer every time. It has proven very inefficient,
because for one byte to display on the screen, we had to actually send 3
bytes over I2C: the address, the type of data that was going to the
controller, and then the actual data.

This patches changes that by sending a whole page at once, avoiding most
of this expensive overhead.

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 drivers/video/ssd1307fb.c |   11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/video/ssd1307fb.c b/drivers/video/ssd1307fb.c
index 35f5348..cab5f7c 100644
--- a/drivers/video/ssd1307fb.c
+++ b/drivers/video/ssd1307fb.c
@@ -168,23 +168,28 @@ static void ssd1307fb_update_display(struct ssd1307fb_par *par)
 	 */
 
 	for (i = 0; i < (par->height / 8); i++) {
+		struct ssd1307fb_array *array;
 		ssd1307fb_write_cmd(par->client,
 				    SSD1307FB_START_PAGE_ADDRESS + i + par->page_offset);
 		ssd1307fb_write_cmd(par->client, 0x00);
 		ssd1307fb_write_cmd(par->client, 0x10);
 
+		array = ssd1307fb_alloc_array(par->width, SSD1307FB_DATA);
+
 		for (j = 0; j < par->width; j++) {
-			u8 buf = 0;
+			array->data[j] = 0;
 			for (k = 0; k < 8; k++) {
 				u32 page_length = par->width * i;
 				u32 index = page_length + (par->width * k + j) / 8;
 				u8 byte = *(vmem + index);
 				u8 bit = byte & (1 << (j % 8));
 				bit = bit >> (j % 8);
-				buf |= bit << k;
+				array->data[j] |= bit << k;
 			}
-			ssd1307fb_write_data(par->client, buf);
 		}
+
+		ssd1307fb_write_array(par->client, array, par->width);
+		kfree(array);
 	}
 }
 
-- 
1.7.10.4



From maxime.ripard at free-electrons.com  Mon Apr 22 06:02:25 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Mon, 22 Apr 2013 12:02:25 +0200
Subject: [PATCH 4/4] ssd1307fb: Make use of horizontal addressing mode
In-Reply-To: <1366624945-5708-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1366624945-5708-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1366624945-5708-5-git-send-email-maxime.ripard@free-electrons.com>

By default, the ssd1307 controller uses an addressing mode called page
addressing. This mode only increments the column cursor in memory when
writing data but will not increments the page cursor when we are at the
end of the page.

However, the controller supports another addressing mode, called
horizontal addressing, that will maintain both the page and column
cursors when writing data to the controller.

That means that we can just remove the code that increments the current
page address and reset the column cursor when reaching the end of the
line, allowing to have a lower data overhead, and a simpler driver.

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 drivers/video/ssd1307fb.c |   51 +++++++++++++++++++++++++++++++++------------
 1 file changed, 38 insertions(+), 13 deletions(-)

diff --git a/drivers/video/ssd1307fb.c b/drivers/video/ssd1307fb.c
index cab5f7c..259c9ee 100644
--- a/drivers/video/ssd1307fb.c
+++ b/drivers/video/ssd1307fb.c
@@ -19,6 +19,12 @@
 #define SSD1307FB_DATA			0x40
 #define SSD1307FB_COMMAND		0x80
 
+#define SSD1307FB_SET_ADDRESS_MODE	0x20
+#define SSD1307FB_SET_ADDRESS_MODE_HORIZONTAL	(0x00)
+#define SSD1307FB_SET_ADDRESS_MODE_VERTICAL	(0x01)
+#define SSD1307FB_SET_ADDRESS_MODE_PAGE		(0x02)
+#define SSD1307FB_SET_COL_RANGE		0x21
+#define SSD1307FB_SET_PAGE_RANGE	0x22
 #define SSD1307FB_CONTRAST		0x81
 #define	SSD1307FB_CHARGE_PUMP		0x8d
 #define SSD1307FB_SEG_REMAP_ON		0xa1
@@ -135,9 +141,15 @@ static inline int ssd1307fb_write_data(struct i2c_client *client, u8 data)
 
 static void ssd1307fb_update_display(struct ssd1307fb_par *par)
 {
+	struct ssd1307fb_array *array;
 	u8 *vmem = par->info->screen_base;
 	int i, j, k;
 
+	array = ssd1307fb_alloc_array(par->width * par->height / 8,
+				      SSD1307FB_DATA);
+	if (!array)
+		return;
+
 	/*
 	 * The screen is divided in pages, each having a height of 8
 	 * pixels, and the width of the screen. When sending a byte of
@@ -168,29 +180,22 @@ static void ssd1307fb_update_display(struct ssd1307fb_par *par)
 	 */
 
 	for (i = 0; i < (par->height / 8); i++) {
-		struct ssd1307fb_array *array;
-		ssd1307fb_write_cmd(par->client,
-				    SSD1307FB_START_PAGE_ADDRESS + i + par->page_offset);
-		ssd1307fb_write_cmd(par->client, 0x00);
-		ssd1307fb_write_cmd(par->client, 0x10);
-
-		array = ssd1307fb_alloc_array(par->width, SSD1307FB_DATA);
-
 		for (j = 0; j < par->width; j++) {
-			array->data[j] = 0;
+			u32 array_idx = i * par->width + j;
+			array->data[array_idx] = 0;
 			for (k = 0; k < 8; k++) {
 				u32 page_length = par->width * i;
 				u32 index = page_length + (par->width * k + j) / 8;
 				u8 byte = *(vmem + index);
 				u8 bit = byte & (1 << (j % 8));
 				bit = bit >> (j % 8);
-				array->data[j] |= bit << k;
+				array->data[array_idx] |= bit << k;
 			}
 		}
-
-		ssd1307fb_write_array(par->client, array, par->width);
-		kfree(array);
 	}
+
+	ssd1307fb_write_array(par->client, array, par->width * par->height / 8);
+	kfree(array);
 }
 
 
@@ -371,6 +376,26 @@ static int ssd1307fb_ssd1306_init(struct ssd1307fb_par *par)
 	if (ret < 0)
 		return ret;
 
+	/* Switch to horizontal addressing mode */
+	ret = ssd1307fb_write_cmd(par->client, SSD1307FB_SET_ADDRESS_MODE);
+	ret = ret & ssd1307fb_write_cmd(par->client,
+					SSD1307FB_SET_ADDRESS_MODE_HORIZONTAL);
+	if (ret < 0)
+		return ret;
+
+	ret = ssd1307fb_write_cmd(par->client, SSD1307FB_SET_COL_RANGE);
+	ret = ret & ssd1307fb_write_cmd(par->client, 0x0);
+	ret = ret & ssd1307fb_write_cmd(par->client, par->width - 1);
+	if (ret < 0)
+		return ret;
+
+	ret = ssd1307fb_write_cmd(par->client, SSD1307FB_SET_PAGE_RANGE);
+	ret = ret & ssd1307fb_write_cmd(par->client, 0x0);
+	ret = ret & ssd1307fb_write_cmd(par->client,
+					par->page_offset + (par->height / 8) - 1);
+	if (ret < 0)
+		return ret;
+
 	/* Turn on the display */
 	ret = ssd1307fb_write_cmd(par->client, SSD1307FB_DISPLAY_ON);
 	if (ret < 0)
-- 
1.7.10.4



From vinod.koul at intel.com  Mon Apr 22 05:34:23 2013
From: vinod.koul at intel.com (Vinod Koul)
Date: Mon, 22 Apr 2013 15:04:23 +0530
Subject: [PATCH 17/32] dmaengine: ste_dma40: Remove redundant argument
 from d40_phy_cfg()
In-Reply-To: <1366279934-30761-18-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-18-git-send-email-lee.jones@linaro.org>
Message-ID: <20130422093423.GD24632@intel.com>

On Thu, Apr 18, 2013 at 11:11:59AM +0100, Lee Jones wrote:
> d40_phy_cfg is now only ever called to configure physical channels, so
> there's no requirement to pass though an argument describing the type
> of channel and to subsequently test for it.
> 
> Cc: Vinod Koul <vinod.koul at intel.com>
> Cc: Dan Williams <djbw at fb.com>
> Cc: Per Forlin <per.forlin at stericsson.com>
> Cc: Rabin Vincent <rabin at rab.in>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>
> ---
>  drivers/dma/ste_dma40.c    |    3 +-
>  drivers/dma/ste_dma40_ll.c |  101 +++++++++++++++++++++-----------------------
>  drivers/dma/ste_dma40_ll.h |    3 +-
>  3 files changed, 50 insertions(+), 57 deletions(-)
> 
> diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
> index 1c570b6..ff41972 100644
> --- a/drivers/dma/ste_dma40.c
> +++ b/drivers/dma/ste_dma40.c
> @@ -2799,8 +2799,7 @@ static int d40_set_runtime_config(struct dma_chan *chan,
>  	if (chan_is_logical(d40c))
>  		d40_log_cfg(cfg, &d40c->log_def.lcsp1, &d40c->log_def.lcsp3);
>  	else
> -		d40_phy_cfg(cfg, &d40c->src_def_cfg,
> -			    &d40c->dst_def_cfg, false);
> +		d40_phy_cfg(cfg, &d40c->src_def_cfg, &d40c->dst_def_cfg);
>  
>  	/* These settings will take precedence later */
>  	d40c->runtime_addr = config_addr;
> diff --git a/drivers/dma/ste_dma40_ll.c b/drivers/dma/ste_dma40_ll.c
> index b72d3e2..9ab9dff 100644
> --- a/drivers/dma/ste_dma40_ll.c
> +++ b/drivers/dma/ste_dma40_ll.c
> @@ -56,63 +56,58 @@ void d40_log_gim_unmask(u32 *src_cfg, u32 *dst_cfg) {
>  	*dst_cfg |= 1 << D40_SREG_CFG_LOG_GIM_POS;
>  }
>  
> -/* Sets up SRC and DST CFG register for both logical and physical channels */
> -void d40_phy_cfg(struct stedma40_chan_cfg *cfg,
> -		 u32 *src_cfg, u32 *dst_cfg, bool is_log)
> +void d40_phy_cfg(struct stedma40_chan_cfg *cfg, u32 *src_cfg, u32 *dst_cfg)
>  {
>  	u32 src = 0;
>  	u32 dst = 0;
>  
> -	if (!is_log) {
> -		/* Physical channel */
> -		if ((cfg->dir ==  STEDMA40_PERIPH_TO_MEM) ||
> -		    (cfg->dir == STEDMA40_PERIPH_TO_PERIPH)) {
> -			/* Set master port to 1 */
> -			src |= 1 << D40_SREG_CFG_MST_POS;
> -			src |= D40_TYPE_TO_EVENT(cfg->dev_type);
> -
> -			if (cfg->src_info.flow_ctrl == STEDMA40_NO_FLOW_CTRL)
> -				src |= 1 << D40_SREG_CFG_PHY_TM_POS;
> -			else
> -				src |= 3 << D40_SREG_CFG_PHY_TM_POS;
> -		}
> -		if ((cfg->dir ==  STEDMA40_MEM_TO_PERIPH) ||
> -		    (cfg->dir == STEDMA40_PERIPH_TO_PERIPH)) {
> -			/* Set master port to 1 */
> -			dst |= 1 << D40_SREG_CFG_MST_POS;
> -			dst |= D40_TYPE_TO_EVENT(cfg->dev_type);
> -
> -			if (cfg->dst_info.flow_ctrl == STEDMA40_NO_FLOW_CTRL)
> -				dst |= 1 << D40_SREG_CFG_PHY_TM_POS;
> -			else
> -				dst |= 3 << D40_SREG_CFG_PHY_TM_POS;
> -		}
> -		/* Interrupt on end of transfer for destination */
> -		dst |= 1 << D40_SREG_CFG_TIM_POS;
> -
> -		/* Generate interrupt on error */
> -		src |= 1 << D40_SREG_CFG_EIM_POS;
> -		dst |= 1 << D40_SREG_CFG_EIM_POS;
> -
> -		/* PSIZE */
> -		if (cfg->src_info.psize != STEDMA40_PSIZE_PHY_1) {
> -			src |= 1 << D40_SREG_CFG_PHY_PEN_POS;
> -			src |= cfg->src_info.psize << D40_SREG_CFG_PSIZE_POS;
> -		}
> -		if (cfg->dst_info.psize != STEDMA40_PSIZE_PHY_1) {
> -			dst |= 1 << D40_SREG_CFG_PHY_PEN_POS;
> -			dst |= cfg->dst_info.psize << D40_SREG_CFG_PSIZE_POS;
> -		}
> -
> -		/* Element size */
> -		src |= cfg->src_info.data_width << D40_SREG_CFG_ESIZE_POS;
> -		dst |= cfg->dst_info.data_width << D40_SREG_CFG_ESIZE_POS;
> -
> -		/* Set the priority bit to high for the physical channel */
> -		if (cfg->high_priority) {
> -			src |= 1 << D40_SREG_CFG_PRI_POS;
> -			dst |= 1 << D40_SREG_CFG_PRI_POS;
> -		}
> +	if ((cfg->dir ==  STEDMA40_PERIPH_TO_MEM) ||
> +	    (cfg->dir == STEDMA40_PERIPH_TO_PERIPH)) {
Why would you need your own direction defines, I see that there is not much
diff between these and what dmaengine defines, so perhpas you could use
those?

> +		/* Set master port to 1 */
> +		src |= 1 << D40_SREG_CFG_MST_POS;
> +		src |= D40_TYPE_TO_EVENT(cfg->dev_type);
> +
> +		if (cfg->src_info.flow_ctrl == STEDMA40_NO_FLOW_CTRL)
> +			src |= 1 << D40_SREG_CFG_PHY_TM_POS;
> +		else
> +			src |= 3 << D40_SREG_CFG_PHY_TM_POS;
> +	}
> +	if ((cfg->dir ==  STEDMA40_MEM_TO_PERIPH) ||
> +	    (cfg->dir == STEDMA40_PERIPH_TO_PERIPH)) {
> +		/* Set master port to 1 */
> +		dst |= 1 << D40_SREG_CFG_MST_POS;
> +		dst |= D40_TYPE_TO_EVENT(cfg->dev_type);
> +
> +		if (cfg->dst_info.flow_ctrl == STEDMA40_NO_FLOW_CTRL)
> +			dst |= 1 << D40_SREG_CFG_PHY_TM_POS;
> +		else
> +			dst |= 3 << D40_SREG_CFG_PHY_TM_POS;
> +	}
> +	/* Interrupt on end of transfer for destination */
> +	dst |= 1 << D40_SREG_CFG_TIM_POS;
> +
> +	/* Generate interrupt on error */
> +	src |= 1 << D40_SREG_CFG_EIM_POS;
> +	dst |= 1 << D40_SREG_CFG_EIM_POS;
> +
> +	/* PSIZE */
> +	if (cfg->src_info.psize != STEDMA40_PSIZE_PHY_1) {
> +		src |= 1 << D40_SREG_CFG_PHY_PEN_POS;
> +		src |= cfg->src_info.psize << D40_SREG_CFG_PSIZE_POS;
> +	}
> +	if (cfg->dst_info.psize != STEDMA40_PSIZE_PHY_1) {
> +		dst |= 1 << D40_SREG_CFG_PHY_PEN_POS;
> +		dst |= cfg->dst_info.psize << D40_SREG_CFG_PSIZE_POS;
> +	}
> +
> +	/* Element size */
> +	src |= cfg->src_info.data_width << D40_SREG_CFG_ESIZE_POS;
> +	dst |= cfg->dst_info.data_width << D40_SREG_CFG_ESIZE_POS;
> +
> +	/* Set the priority bit to high for the physical channel */
> +	if (cfg->high_priority) {
> +		src |= 1 << D40_SREG_CFG_PRI_POS;
> +		dst |= 1 << D40_SREG_CFG_PRI_POS;
>  	}
>  
>  	if (cfg->src_info.big_endian)
> diff --git a/drivers/dma/ste_dma40_ll.h b/drivers/dma/ste_dma40_ll.h
> index 8aad679..e54df09 100644
> --- a/drivers/dma/ste_dma40_ll.h
> +++ b/drivers/dma/ste_dma40_ll.h
> @@ -434,8 +434,7 @@ void d40_log_gim_unmask(u32 *src_cfg, u32 *dst_cfg);
>  
>  void d40_phy_cfg(struct stedma40_chan_cfg *cfg,
>  		 u32 *src_cfg,
> -		 u32 *dst_cfg,
> -		 bool is_log);
> +		 u32 *dst_cfg);
>  
>  void d40_log_cfg(struct stedma40_chan_cfg *cfg,
>  		 u32 *lcsp1,
> -- 
> 1.7.10.4
> 


From vinod.koul at intel.com  Mon Apr 22 05:36:31 2013
From: vinod.koul at intel.com (Vinod Koul)
Date: Mon, 22 Apr 2013 15:06:31 +0530
Subject: [PATCH 21/32] dmaengine: ste_dma40: Also report the number of
 logical channels
In-Reply-To: <1366279934-30761-22-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-22-git-send-email-lee.jones@linaro.org>
Message-ID: <20130422093631.GE24632@intel.com>

On Thu, Apr 18, 2013 at 11:12:03AM +0100, Lee Jones wrote:
> Now we know the total of physical and logical channels, we may as
> well report them within the information log.
> 
> Before:
> dma40 dma40.0: hardware revision: 3 @ 0x801c0000 with 8 physical channels
> 
> After:
> <as above ...> and 256 logical channels
> 
> Cc: Vinod Koul <vinod.koul at intel.com>
> Cc: Dan Williams <djbw at fb.com>
> Cc: Per Forlin <per.forlin at stericsson.com>
> Cc: Rabin Vincent <rabin at rab.in>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>
> ---
>  drivers/dma/ste_dma40.c |    5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
> index 282dd59..805049c 100644
> --- a/drivers/dma/ste_dma40.c
> +++ b/drivers/dma/ste_dma40.c
> @@ -3200,8 +3200,9 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
>  
>  	num_log_chans = num_phy_chans * D40_MAX_LOG_CHAN_PER_PHY;
>  
> -	dev_info(&pdev->dev, "hardware revision: %d @ 0x%x with %d physical channels\n",
> -		 rev, res->start, num_phy_chans);
> +	dev_info(&pdev->dev, "hardware revision: %d @ 0x%x with "
> +		"%d physical channels and %d logical channels\n",
> +		rev, res->start, num_phy_chans, num_log_chans);
Splitting log messages across lines is bad idea and sacrifces readablity... also
wasnt splitting logging to multiple lines emit checkpatch warn

--
~Vinod
>  
>  	base = kzalloc(ALIGN(sizeof(struct d40_base), 4) + (num_phy_chans +
>  	num_log_chans + ARRAY_SIZE(dma40_memcpy_channels)) * -- 1.7.10.4
> 


From vinod.koul at intel.com  Mon Apr 22 05:37:25 2013
From: vinod.koul at intel.com (Vinod Koul)
Date: Mon, 22 Apr 2013 15:07:25 +0530
Subject: [PATCH 19/32] dmaengine: ste_dma40: Move more setup into the
 configuration routines
In-Reply-To: <1366279934-30761-20-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-20-git-send-email-lee.jones@linaro.org>
Message-ID: <20130422093725.GF24632@intel.com>

On Thu, Apr 18, 2013 at 11:12:01AM +0100, Lee Jones wrote:
> The less configuration we can do during the allocation of a channel the
> better. As this will mean the likelihood of requiring extra information
> which isn't normally passed through the dma_request_channel() is lessened.
> 
> Cc: Vinod Koul <vinod.koul at intel.com>
> Cc: Dan Williams <djbw at fb.com>
> Cc: Per Forlin <per.forlin at stericsson.com>
> Cc: Rabin Vincent <rabin at rab.in>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>
Acked-by: Vinod Koul <vnod.koul at intel.com>

--
~Vinod
> ---
>  drivers/dma/ste_dma40.c |   22 ++++++++++------------
>  1 file changed, 10 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
> index 04cc75f..28fe153 100644
> --- a/drivers/dma/ste_dma40.c
> +++ b/drivers/dma/ste_dma40.c
> @@ -2440,16 +2440,6 @@ static int d40_alloc_chan_resources(struct dma_chan *chan)
>  
>  	d40_set_prio_realtime(d40c);
>  
> -	if (chan_is_logical(d40c)) {
> -		if (d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_MEM)
> -			d40c->lcpa = d40c->base->lcpa_base +
> -				d40c->dma_cfg.src_dev_type * D40_LCPA_CHAN_SIZE;
> -		else
> -			d40c->lcpa = d40c->base->lcpa_base +
> -				d40c->dma_cfg.dst_dev_type *
> -				D40_LCPA_CHAN_SIZE + D40_LCPA_CHAN_DST_DELTA;
> -	}
> -
>  	if (chan_is_logical(d40c))
>  		d40_log_gim_unmask(&d40c->src_def_cfg, &d40c->dst_def_cfg);
>  
> @@ -2793,9 +2783,17 @@ static int d40_set_runtime_config(struct dma_chan *chan,
>  		return ret;
>  
>  	/* Fill in register values */
> -	if (chan_is_logical(d40c))
> +	if (chan_is_logical(d40c)) {
> +		if (d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_MEM)
> +			d40c->lcpa = d40c->base->lcpa_base +
> +				d40c->dma_cfg.dev_type * D40_LCPA_CHAN_SIZE;
> +		else
> +			d40c->lcpa = d40c->base->lcpa_base +
> +				d40c->dma_cfg.dev_type *
> +				D40_LCPA_CHAN_SIZE + D40_LCPA_CHAN_DST_DELTA;
> +
>  		d40_log_cfg(cfg, &d40c->log_def.lcsp1, &d40c->log_def.lcsp3);
> -	else
> +	} else
>  		d40_phy_cfg(cfg, &d40c->src_def_cfg, &d40c->dst_def_cfg);
>  
>  	/* These settings will take precedence later */
> -- 
> 1.7.10.4
> 


From vinod.koul at intel.com  Mon Apr 22 05:38:44 2013
From: vinod.koul at intel.com (Vinod Koul)
Date: Mon, 22 Apr 2013 15:08:44 +0530
Subject: [PATCH 22/32] dmaengine: ste_dma40: Allocate plat_data on
 declaration
In-Reply-To: <1366279934-30761-23-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-23-git-send-email-lee.jones@linaro.org>
Message-ID: <20130422093844.GG24632@intel.com>

On Thu, Apr 18, 2013 at 11:12:04AM +0100, Lee Jones wrote:
> It's the way that most other drivers do it.
> 
> Very trivial clean-up which reduces line count and simplifies code.
> 
> Cc: Vinod Koul <vinod.koul at intel.com>
> Cc: Dan Williams <djbw at fb.com>
> Cc: Per Forlin <per.forlin at stericsson.com>
> Cc: Rabin Vincent <rabin at rab.in>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>
Acked-by: Vinod Koul <vnod.koul at intel.com>

--
~Vinod
> ---
>  drivers/dma/ste_dma40.c |    4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
> index 805049c..6f9f801 100644
> --- a/drivers/dma/ste_dma40.c
> +++ b/drivers/dma/ste_dma40.c
> @@ -3119,7 +3119,7 @@ static int __init d40_phy_res_init(struct d40_base *base)
>  
>  static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
>  {
> -	struct stedma40_platform_data *plat_data;
> +	struct stedma40_platform_data *plat_data = pdev->dev.platform_data;
>  	struct clk *clk = NULL;
>  	void __iomem *virtbase = NULL;
>  	struct resource *res = NULL;
> @@ -3190,8 +3190,6 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
>  		goto failure;
>  	}
>  
> -	plat_data = pdev->dev.platform_data;
> -
>  	/* The number of physical channels on this HW */
>  	if (plat_data->num_of_phy_chans)
>  		num_phy_chans = plat_data->num_of_phy_chans;
> -- 
> 1.7.10.4
> 


From vinod.koul at intel.com  Mon Apr 22 05:40:10 2013
From: vinod.koul at intel.com (Vinod Koul)
Date: Mon, 22 Apr 2013 15:10:10 +0530
Subject: [PATCH 22/32] dmaengine: ste_dma40: Allocate plat_data on
 declaration
In-Reply-To: <1366279934-30761-23-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-23-git-send-email-lee.jones@linaro.org>
Message-ID: <20130422094010.GH24632@intel.com>

On Thu, Apr 18, 2013 at 11:12:04AM +0100, Lee Jones wrote:
> It's the way that most other drivers do it.
> 
> Very trivial clean-up which reduces line count and simplifies code.
> 
> Cc: Vinod Koul <vinod.koul at intel.com>
> Cc: Dan Williams <djbw at fb.com>
> Cc: Per Forlin <per.forlin at stericsson.com>
> Cc: Rabin Vincent <rabin at rab.in>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>
Acked-by: Vinod Koul <vnod.koul at intel.com>

--
~Vinod
> ---
>  drivers/dma/ste_dma40.c |    4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
> index 805049c..6f9f801 100644
> --- a/drivers/dma/ste_dma40.c
> +++ b/drivers/dma/ste_dma40.c
> @@ -3119,7 +3119,7 @@ static int __init d40_phy_res_init(struct d40_base *base)
>  
>  static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
>  {
> -	struct stedma40_platform_data *plat_data;
> +	struct stedma40_platform_data *plat_data = pdev->dev.platform_data;
>  	struct clk *clk = NULL;
>  	void __iomem *virtbase = NULL;
>  	struct resource *res = NULL;
> @@ -3190,8 +3190,6 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
>  		goto failure;
>  	}
>  
> -	plat_data = pdev->dev.platform_data;
> -
>  	/* The number of physical channels on this HW */
>  	if (plat_data->num_of_phy_chans)
>  		num_phy_chans = plat_data->num_of_phy_chans;
> -- 
> 1.7.10.4
> 


From lee.jones at linaro.org  Mon Apr 22 06:11:33 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Mon, 22 Apr 2013 11:11:33 +0100
Subject: [PATCH 13/32] dmaengine: ste_dma40: Calculate number of logical
 channels from physical ones
In-Reply-To: <20130422092321.GC24632@intel.com>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-14-git-send-email-lee.jones@linaro.org>
 <20130422092321.GC24632@intel.com>
Message-ID: <20130422101133.GG3432@gmail.com>

On Mon, 22 Apr 2013, Vinod Koul wrote:

> On Thu, Apr 18, 2013 at 11:11:55AM +0100, Lee Jones wrote:
> > This change will cost ~25KB of memory, but it's worth the trade-off,
> > as it removes a great deal of overhead. It means that instead of only
> > allocating memory for the logical channels in use, it does so for all
> > available ones, which is 32 per physical channel. However, this now
> > means we can remove some platform data and we don't have to worry
> > about adding vendor specific variables to Device Tree.
> > 
> > Cc: Vinod Koul <vinod.koul at intel.com>
> > Cc: Dan Williams <djbw at fb.com>
> > Cc: Per Forlin <per.forlin at stericsson.com>
> > Cc: Rabin Vincent <rabin at rab.in>
> > Signed-off-by: Lee Jones <lee.jones at linaro.org>
> > ---
> >  arch/arm/mach-ux500/devices-db8500.c        |    1 -
> >  drivers/dma/ste_dma40.c                     |   16 ++++++----------
> >  include/linux/platform_data/dma-ste-dma40.h |    2 --
> >  3 files changed, 6 insertions(+), 13 deletions(-)
> > 
> > diff --git a/arch/arm/mach-ux500/devices-db8500.c b/arch/arm/mach-ux500/devices-db8500.c
> > index 03efd4c1..2fcb8c2 100644
> > --- a/arch/arm/mach-ux500/devices-db8500.c
> > +++ b/arch/arm/mach-ux500/devices-db8500.c
> > @@ -121,7 +121,6 @@ static const dma_addr_t dma40_rx_map[DB8500_DMA_NR_DEV] = {
> >  };
> >  
> >  static struct stedma40_platform_data dma40_plat_data = {
> > -	.dev_len = DB8500_DMA_NR_DEV,
> >  	.dev_rx = dma40_rx_map,
> >  	.dev_tx = dma40_tx_map,
> >  	.disabled_channels = {-1},
> > diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
> > index 7b451b2..a39ef74 100644
> > --- a/drivers/dma/ste_dma40.c
> > +++ b/drivers/dma/ste_dma40.c
> > @@ -45,6 +45,9 @@
> >  #define D40_LCLA_LINK_PER_EVENT_GRP 128
> >  #define D40_LCLA_END D40_LCLA_LINK_PER_EVENT_GRP
> >  
> > +/* Max number of logical channels per physical channel */
> > +#define D40_MAX_LOG_CHAN_PER_PHY 32
> > +
> >  /* Attempts before giving up to trying to get pages that are aligned */
> >  #define MAX_LCLA_ALLOC_ATTEMPTS 256
> >  
> > @@ -3197,6 +3200,8 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
> >  	else
> >  		num_phy_chans = 4 * (readl(virtbase + D40_DREG_ICFG) & 0x7) + 4;
> >  
> > +	num_log_chans = num_phy_chans * D40_MAX_LOG_CHAN_PER_PHY;
> > +
> >  	dev_info(&pdev->dev, "hardware revision: %d @ 0x%x with %d physical channels\n",
> >  		 rev, res->start, num_phy_chans);
> >  
> > @@ -3206,15 +3211,6 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
> >  		goto failure;
> >  	}
> >  
> > -	/* Count the number of logical channels in use */
> > -	for (i = 0; i < plat_data->dev_len; i++)
> > -		if (plat_data->dev_rx[i] != 0)
> > -			num_log_chans++;
> > -
> > -	for (i = 0; i < plat_data->dev_len; i++)
> > -		if (plat_data->dev_tx[i] != 0)
> > -			num_log_chans++;
> > -
> >  	base = kzalloc(ALIGN(sizeof(struct d40_base), 4) +
> >  		       (num_phy_chans + num_log_chans + ARRAY_SIZE(dma40_memcpy_channels)) *
> >  		       sizeof(struct d40_chan), GFP_KERNEL);
> > @@ -3282,7 +3278,7 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
> >  		 * The max number of logical channels are event lines for all
> >  		 * src devices and dst devices
> >  		 */
> > -		base->lookup_log_chans = kzalloc(plat_data->dev_len * 2 *
> > +		base->lookup_log_chans = kzalloc(num_log_chans *
> you could have used devm_ helper for this.

I'll convert the entire driver over to devm_ in a latter patch.

> Acked-by: Vinod Koul <vnod.koul at intel.com>

Thanks. 

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From vinod.koul at intel.com  Mon Apr 22 05:41:25 2013
From: vinod.koul at intel.com (Vinod Koul)
Date: Mon, 22 Apr 2013 15:11:25 +0530
Subject: [PATCH 20/32] dmaengine: ste_dma40: Move rev error-check up to
 revision acquisition
In-Reply-To: <1366279934-30761-21-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-21-git-send-email-lee.jones@linaro.org>
Message-ID: <20130422094125.GI24632@intel.com>

On Thu, Apr 18, 2013 at 11:12:02AM +0100, Lee Jones wrote:
> At the moment we fetch the hardware revision, then do some stuff, then
> check whether the revision is correct and return in error if it's not.
> Well we may as well check it as soon as we know what it is, so let's
> move the check right up underneath where we acquire the version.
> 
> Cc: Vinod Koul <vinod.koul at intel.com>
> Cc: Dan Williams <djbw at fb.com>
> Cc: Per Forlin <per.forlin at stericsson.com>
> Cc: Rabin Vincent <rabin at rab.in>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>
Acked-by: Vinod Koul <vnod.koul at intel.com>

--
~Vinod
> ---
>  drivers/dma/ste_dma40.c |   10 ++++------
>  1 file changed, 4 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
> index 28fe153..282dd59 100644
> --- a/drivers/dma/ste_dma40.c
> +++ b/drivers/dma/ste_dma40.c
> @@ -3185,6 +3185,10 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
>  	 * DB8540v1 has revision 4
>  	 */
>  	rev = AMBA_REV_BITS(pid);
> +	if (rev < 2) {
> +		d40_err(&pdev->dev, "hardware revision: %d is not supported", rev);
> +		goto failure;
> +	}
>  
>  	plat_data = pdev->dev.platform_data;
>  
> @@ -3199,12 +3203,6 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
>  	dev_info(&pdev->dev, "hardware revision: %d @ 0x%x with %d physical channels\n",
>  		 rev, res->start, num_phy_chans);
>  
> -	if (rev < 2) {
> -		d40_err(&pdev->dev, "hardware revision: %d is not supported",
> -			rev);
> -		goto failure;
> -	}
> -
>  	base = kzalloc(ALIGN(sizeof(struct d40_base), 4) +
>  		       (num_phy_chans + num_log_chans + ARRAY_SIZE(dma40_memcpy_channels)) *
>  		       sizeof(struct d40_chan), GFP_KERNEL);
> -- 
> 1.7.10.4
> 


From vinod.koul at intel.com  Mon Apr 22 05:42:50 2013
From: vinod.koul at intel.com (Vinod Koul)
Date: Mon, 22 Apr 2013 15:12:50 +0530
Subject: [PATCH 05/32] dmaengine: ste_dma40: Supply macros to resolve
 'src' and 'dst' directions
In-Reply-To: <1366279934-30761-6-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-6-git-send-email-lee.jones@linaro.org>
Message-ID: <20130422094250.GJ24632@intel.com>

On Thu, Apr 18, 2013 at 11:11:47AM +0100, Lee Jones wrote:
> There are lots of lengthy if() statements located sporadically up and
> down the driver. This simple macro should make many of them a little
> simpler to decipher. The remainder have to stay in place, as they
> detail slightly more specific settings.
I would like these to be DMAENGINE_IS_SRC... and this patch use the defines
provided in dmaengine

--
~Vinod
> 
> Cc: Vinod Koul <vinod.koul at intel.com>
> Cc: Dan Williams <djbw at fb.com>
> Cc: Per Forlin <per.forlin at stericsson.com>
> Cc: Rabin Vincent <rabin at rab.in>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>
> ---
>  drivers/dma/ste_dma40.c |   38 ++++++++++++++++++++------------------
>  1 file changed, 20 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
> index e50354d..b21a8a3 100644
> --- a/drivers/dma/ste_dma40.c
> +++ b/drivers/dma/ste_dma40.c
> @@ -55,6 +55,10 @@
>  
>  #define MAX(a, b) (((a) < (b)) ? (b) : (a))
>  
> +#define D40_IS_SRC(dir)  ((dir == STEDMA40_PERIPH_TO_MEM) ? true : false)
> +#define D40_IS_DST(dir) (((dir == STEDMA40_MEM_TO_PERIPH) || \
> +			  (dir == STEDMA40_MEM_TO_MEM)) ? true : false)
> +
>  /* Reserved event lines for memcpy only. */
>  static int dma40_memcpy_channels[] = { 56, 57, 58, 59, 60 };
>  
> @@ -823,7 +827,7 @@ static void d40_log_lli_to_lcxa(struct d40_chan *chan, struct d40_desc *desc)
>  		 * that uses linked lists.
>  		 */
>  		if (!(chan->phy_chan->use_soft_lli &&
> -			chan->dma_cfg.dir == STEDMA40_PERIPH_TO_MEM))
> +		      D40_IS_SRC(chan->dma_cfg.dir)))
>  			curr_lcla = d40_lcla_alloc_one(chan, desc);
>  
>  		first_lcla = curr_lcla;
> @@ -1291,12 +1295,12 @@ static void d40_config_set_event(struct d40_chan *d40c,
>  	u32 event = D40_TYPE_TO_EVENT(d40c->dma_cfg.dev_type);
>  
>  	/* Enable event line connected to device (or memcpy) */
> -	if ((d40c->dma_cfg.dir ==  STEDMA40_PERIPH_TO_MEM) ||
> +	if (D40_IS_SRC(d40c->dma_cfg.dir) ||
>  	    (d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_PERIPH))
>  		__d40_config_set_event(d40c, event_type, event,
>  				       D40_CHAN_REG_SSLNK);
>  
> -	if (d40c->dma_cfg.dir !=  STEDMA40_PERIPH_TO_MEM)
> +	if (!D40_IS_SRC(d40c->dma_cfg.dir))
>  		__d40_config_set_event(d40c, event_type, event,
>  				       D40_CHAN_REG_SDLNK);
>  }
> @@ -1762,7 +1766,7 @@ static int d40_validate_conf(struct d40_chan *d40c,
>  		res = -EINVAL;
>  	}
>  
> -	if (conf->dir == STEDMA40_PERIPH_TO_MEM &&
> +	if (D40_IS_SRC(conf->dir) &&
>  	    d40c->base->plat_data->dev_rx[conf->dev_type] == 0 &&
>  	    d40c->runtime_addr == 0) {
>  		chan_err(d40c, "Invalid RX channel address (%d)\n",
> @@ -1895,17 +1899,17 @@ static int d40_allocate_channel(struct d40_chan *d40c, bool *first_phy_user)
>  	int j;
>  	int log_num;
>  	int num_phy_chans;
> +	int dir = d40c->dma_cfg.dir;
>  	bool is_src;
>  	bool is_log = d40c->dma_cfg.mode == STEDMA40_MODE_LOGICAL;
>  
>  	phys = d40c->base->phy_res;
>  	num_phy_chans = d40c->base->num_phy_chans;
>  
> -	if (d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_MEM) {
> +	if (D40_IS_SRC(dir)) {
>  		log_num = 2 * dev_type;
>  		is_src = true;
> -	} else if (d40c->dma_cfg.dir == STEDMA40_MEM_TO_PERIPH ||
> -		   d40c->dma_cfg.dir == STEDMA40_MEM_TO_MEM) {
> +	} else if (D40_IS_DST(dir)) {
>  		/* dst event lines are used for logical memcpy */
>  		log_num = 2 * dev_type + 1;
>  		is_src = false;
> @@ -1916,7 +1920,7 @@ static int d40_allocate_channel(struct d40_chan *d40c, bool *first_phy_user)
>  	event_line = D40_TYPE_TO_EVENT(dev_type);
>  
>  	if (!is_log) {
> -		if (d40c->dma_cfg.dir == STEDMA40_MEM_TO_MEM) {
> +		if (dir == STEDMA40_MEM_TO_MEM) {
>  			/* Find physical half channel */
>  			if (d40c->dma_cfg.use_fixed_channel) {
>  				i = d40c->dma_cfg.phy_channel;
> @@ -2053,11 +2057,10 @@ static int d40_free_dma(struct d40_chan *d40c)
>  		return -EINVAL;
>  	}
>  
> -	if (d40c->dma_cfg.dir == STEDMA40_MEM_TO_PERIPH ||
> -	    d40c->dma_cfg.dir == STEDMA40_MEM_TO_MEM)
> -		is_src = false;
> -	else if (d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_MEM)
> +	if (D40_IS_SRC(d40c->dma_cfg.dir))
>  		is_src = true;
> +	else if (D40_IS_DST(d40c->dma_cfg.dir))
> +		is_src = false;
>  	else {
>  		chan_err(d40c, "Unknown direction\n");
>  		return -EINVAL;
> @@ -2118,12 +2121,11 @@ static bool d40_is_paused(struct d40_chan *d40c)
>  		goto _exit;
>  	}
>  
> -	if (d40c->dma_cfg.dir == STEDMA40_MEM_TO_PERIPH ||
> -	    d40c->dma_cfg.dir == STEDMA40_MEM_TO_MEM) {
> -		status = readl(chanbase + D40_CHAN_REG_SDLNK);
> -	} else if (d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_MEM) {
> +	if (D40_IS_SRC(d40c->dma_cfg.dir))
>  		status = readl(chanbase + D40_CHAN_REG_SSLNK);
> -	} else {
> +	else if (D40_IS_DST(d40c->dma_cfg.dir))
> +		status = readl(chanbase + D40_CHAN_REG_SDLNK);
> +	else {
>  		chan_err(d40c, "Unknown direction\n");
>  		goto _exit;
>  	}
> @@ -2394,7 +2396,7 @@ static void d40_set_prio_realtime(struct d40_chan *d40c)
>  	if (d40c->base->rev < 3)
>  		return;
>  
> -	if ((d40c->dma_cfg.dir ==  STEDMA40_PERIPH_TO_MEM) ||
> +	if (D40_IS_SRC(d40c->dma_cfg.dir) ||
>  	    (d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_PERIPH))
>  		__d40_set_prio_rt(d40c, d40c->dma_cfg.dev_type, true);
>  
> -- 
> 1.7.10.4
> 


From lee.jones at linaro.org  Mon Apr 22 06:14:55 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Mon, 22 Apr 2013 11:14:55 +0100
Subject: [PATCH 21/32] dmaengine: ste_dma40: Also report the number of
 logical channels
In-Reply-To: <20130422093631.GE24632@intel.com>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-22-git-send-email-lee.jones@linaro.org>
 <20130422093631.GE24632@intel.com>
Message-ID: <20130422101455.GH3432@gmail.com>

On Mon, 22 Apr 2013, Vinod Koul wrote:

> On Thu, Apr 18, 2013 at 11:12:03AM +0100, Lee Jones wrote:
> > Now we know the total of physical and logical channels, we may as
> > well report them within the information log.
> > 
> > Before:
> > dma40 dma40.0: hardware revision: 3 @ 0x801c0000 with 8 physical channels
> > 
> > After:
> > <as above ...> and 256 logical channels
> > 
> > Cc: Vinod Koul <vinod.koul at intel.com>
> > Cc: Dan Williams <djbw at fb.com>
> > Cc: Per Forlin <per.forlin at stericsson.com>
> > Cc: Rabin Vincent <rabin at rab.in>
> > Signed-off-by: Lee Jones <lee.jones at linaro.org>
> > ---
> >  drivers/dma/ste_dma40.c |    5 +++--
> >  1 file changed, 3 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
> > index 282dd59..805049c 100644
> > --- a/drivers/dma/ste_dma40.c
> > +++ b/drivers/dma/ste_dma40.c
> > @@ -3200,8 +3200,9 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
> >  
> >  	num_log_chans = num_phy_chans * D40_MAX_LOG_CHAN_PER_PHY;
> >  
> > -	dev_info(&pdev->dev, "hardware revision: %d @ 0x%x with %d physical channels\n",
> > -		 rev, res->start, num_phy_chans);
> > +	dev_info(&pdev->dev, "hardware revision: %d @ 0x%x with "
> > +		"%d physical channels and %d logical channels\n",
> > +		rev, res->start, num_phy_chans, num_log_chans);
> Splitting log messages across lines is bad idea and sacrifces readablity... also
> wasnt splitting logging to multiple lines emit checkpatch warn

You also get a check-patch error if your lines are over 80 chars.

How would you solve this?

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From vinod.koul at intel.com  Mon Apr 22 05:44:32 2013
From: vinod.koul at intel.com (Vinod Koul)
Date: Mon, 22 Apr 2013 15:14:32 +0530
Subject: [PATCH 14/32] dmaengine: ste_dma40: Remove 'always true' checking
In-Reply-To: <1366279934-30761-15-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-15-git-send-email-lee.jones@linaro.org>
Message-ID: <20130422094432.GK24632@intel.com>

On Thu, Apr 18, 2013 at 11:11:56AM +0100, Lee Jones wrote:
> Before allocating memory for logical channels, the current driver
> checks to see if there are any. Well as the dma40_memcpy_channels[]
> array is always populated, the check is always true. Best to
> remove the check.
> 
> Cc: Vinod Koul <vinod.koul at intel.com>
> Cc: Dan Williams <djbw at fb.com>
> Cc: Per Forlin <per.forlin at stericsson.com>
> Cc: Rabin Vincent <rabin at rab.in>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>
Acked-by: Vinod Koul <vnod.koul at intel.com>

The init should be updated to use devm_ versions..

--
~Vinod
> ---
>  drivers/dma/ste_dma40.c |   16 +++++-----------
>  1 file changed, 5 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
> index a39ef74..ec0d6ab 100644
> --- a/drivers/dma/ste_dma40.c
> +++ b/drivers/dma/ste_dma40.c
> @@ -3273,17 +3273,11 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
>  	if (!base->lookup_phy_chans)
>  		goto failure;
>  
> -	if (num_log_chans + ARRAY_SIZE(dma40_memcpy_channels)) {
> -		/*
> -		 * The max number of logical channels are event lines for all
> -		 * src devices and dst devices
> -		 */
> -		base->lookup_log_chans = kzalloc(num_log_chans *
> -						 sizeof(struct d40_chan *),
> -						 GFP_KERNEL);
> -		if (!base->lookup_log_chans)
> -			goto failure;
> -	}
> +	base->lookup_log_chans = kzalloc(num_log_chans *
> +					 sizeof(struct d40_chan *),
> +					 GFP_KERNEL);
> +	if (!base->lookup_log_chans)
> +		goto failure;
>  
>  	base->reg_val_backup_chan = kmalloc(base->num_phy_chans *
>  					    sizeof(d40_backup_regs_chan),
> -- 
> 1.7.10.4
> 


From maxime.ripard at free-electrons.com  Mon Apr 22 06:15:39 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Mon, 22 Apr 2013 12:15:39 +0200
Subject: [PATCH RESEND] video: mxsfb: Fix colors display on lower color
 depth
In-Reply-To: <201304221108.17339.jbe@pengutronix.de>
References: <1366618310-7068-1-git-send-email-maxime.ripard@free-electrons.com>
 <201304221108.17339.jbe@pengutronix.de>
Message-ID: <51750DCB.3060306@free-electrons.com>

Hi Juergen,

Le 22/04/2013 11:08, Juergen Beisert a ?crit :
> Hi Maxime,
> 
> Maxime Ripard wrote:
>> The current code always registers as a 32 bits display, and uses the
>> hardware to drop the MSB of each color to abjust to the interface width
>> used by the panel.
>>
>> This results on 18 bits (and probably 16 bits display as well) in colors
>> being displayed poorly, because the MSB are obviously the most important
>> bits for each color definition.
> 
> But the "def_rgb666" bitfield description reports correctly to use bit 0..5 
> for each colour component in this mode. Maybe your userland program has a bug 
> and forgets to honor the bitfield description?

Hmmm, that might be the case actually, yes, I'll check into this and let
you know. Thanks!

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


From lee.jones at linaro.org  Mon Apr 22 06:18:33 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Mon, 22 Apr 2013 11:18:33 +0100
Subject: [PATCH 17/32] dmaengine: ste_dma40: Remove redundant argument
 from d40_phy_cfg()
In-Reply-To: <20130422093423.GD24632@intel.com>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-18-git-send-email-lee.jones@linaro.org>
 <20130422093423.GD24632@intel.com>
Message-ID: <20130422101833.GI3432@gmail.com>

> > +	if ((cfg->dir ==  STEDMA40_PERIPH_TO_MEM) ||
> > +	    (cfg->dir == STEDMA40_PERIPH_TO_PERIPH)) {
> Why would you need your own direction defines, I see that there is not much
> diff between these and what dmaengine defines, so perhpas you could use
> those?

I agree. I'll speak to the STE folk.

For this (and other) patch(es), I'll continue to use the STEDMA40 ones
though. Converting everything over to the generic defines should be a
subsequent patch-set IMHO.

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From vinod.koul at intel.com  Mon Apr 22 05:48:42 2013
From: vinod.koul at intel.com (Vinod Koul)
Date: Mon, 22 Apr 2013 15:18:42 +0530
Subject: [PATCH 21/32] dmaengine: ste_dma40: Also report the number of
 logical channels
In-Reply-To: <20130422101455.GH3432@gmail.com>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-22-git-send-email-lee.jones@linaro.org>
 <20130422093631.GE24632@intel.com>
 <20130422101455.GH3432@gmail.com>
Message-ID: <20130422094842.GL24632@intel.com>

On Mon, Apr 22, 2013 at 11:14:55AM +0100, Lee Jones wrote:
> On Mon, 22 Apr 2013, Vinod Koul wrote:
> 
> > On Thu, Apr 18, 2013 at 11:12:03AM +0100, Lee Jones wrote:
> > > Now we know the total of physical and logical channels, we may as
> > > well report them within the information log.
> > > 
> > > Before:
> > > dma40 dma40.0: hardware revision: 3 @ 0x801c0000 with 8 physical channels
> > > 
> > > After:
> > > <as above ...> and 256 logical channels
> > > 
> > > Cc: Vinod Koul <vinod.koul at intel.com>
> > > Cc: Dan Williams <djbw at fb.com>
> > > Cc: Per Forlin <per.forlin at stericsson.com>
> > > Cc: Rabin Vincent <rabin at rab.in>
> > > Signed-off-by: Lee Jones <lee.jones at linaro.org>
> > > ---
> > >  drivers/dma/ste_dma40.c |    5 +++--
> > >  1 file changed, 3 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
> > > index 282dd59..805049c 100644
> > > --- a/drivers/dma/ste_dma40.c
> > > +++ b/drivers/dma/ste_dma40.c
> > > @@ -3200,8 +3200,9 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
> > >  
> > >  	num_log_chans = num_phy_chans * D40_MAX_LOG_CHAN_PER_PHY;
> > >  
> > > -	dev_info(&pdev->dev, "hardware revision: %d @ 0x%x with %d physical channels\n",
> > > -		 rev, res->start, num_phy_chans);
> > > +	dev_info(&pdev->dev, "hardware revision: %d @ 0x%x with "
> > > +		"%d physical channels and %d logical channels\n",
> > > +		rev, res->start, num_phy_chans, num_log_chans);
> > Splitting log messages across lines is bad idea and sacrifces readablity... also
> > wasnt splitting logging to multiple lines emit checkpatch warn
> 
> You also get a check-patch error if your lines are over 80 chars.
No, you get a warn
> 
> How would you solve this?
Use common sense :) I would never sacrfice readablity of code. Erring on 80chars
is fine by me as long as it makes sense.

--
~Vinod


From maxime.ripard at free-electrons.com  Mon Apr 22 06:19:37 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Mon, 22 Apr 2013 12:19:37 +0200
Subject: [PATCH RESEND] video: mxsfb: Fix colors display on lower color
 depth
In-Reply-To: <201304221116.18080.marex@denx.de>
References: <1366618310-7068-1-git-send-email-maxime.ripard@free-electrons.com>
 <201304221116.18080.marex@denx.de>
Message-ID: <51750EB9.3020301@free-electrons.com>

Hi Marek,

Le 22/04/2013 11:16, Marek Vasut a ?crit :
> Dear Maxime Ripard,
> 
>> The current code always registers as a 32 bits display, and uses the
>> hardware to drop the MSB of each color to abjust to the interface width
>> used by the panel.
>>
>> This results on 18 bits (and probably 16 bits display as well) in colors
>> being displayed poorly, because the MSB are obviously the most important
>> bits for each color definition.
>>
>> The default controller behaviour when using an interface width smaller
>> than the color depth is to drop the LSBs of each color, which makes more
>> sense because you lose the least important part of the color definition.
>>
>> So, to fix the colors display, just get back to the default controller
>> behaviour.
>>
>> Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
> 
> Did you receive my latest email? Check M28EVK (imx28-m28evk.dts), it uses 18bit 
> LCD and works without this patch I think.

Thanks for the pointer. You mentionned in your other mail that it was
wired on 24bits but that the screen is actually 18 bits. I went to
search for the schematics to look at the wirings to see what could
differ, but I couldn't find any for the M28EVK. Are they publicly available?

Thanks,
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


From nicolas.ferre at atmel.com  Mon Apr 22 06:22:32 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Mon, 22 Apr 2013 12:22:32 +0200
Subject: [PATCH v3 1/6] at_hdmac: move to generic DMA binding
In-Reply-To: <1366362683-14496-2-git-send-email-ludovic.desroches@atmel.com>
References: <1366362683-14496-1-git-send-email-ludovic.desroches@atmel.com>
 <1366362683-14496-2-git-send-email-ludovic.desroches@atmel.com>
Message-ID: <51750F68.4040701@atmel.com>

On 04/19/2013 11:11 AM, ludovic.desroches at atmel.com :
> From: Ludovic Desroches <ludovic.desroches at atmel.com>
> 
> Update at_hdmac driver to support generic DMA device tree binding. Devices
> can still request channel with dma_request_channel() then it doesn't break
> DMA for non DT boards.
> 
> Signed-off-by: Ludovic Desroches <ludovic.desroches at atmel.com>
> Acked-by: Nicolas Ferre <nicolas.ferre at atmel.com>
> Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
> Acked-by: Arnd Bergmann <arnd at arndb.de>

Hi Vinod,

As you were not in copy of the patch, I send you a little reminder for
it. It is part of a series by Ludovic and is adding the generic slave
DMA device tree binding for our at_hdmac dmaengine driver.

Here is the only patch of the series that should go through your tree.
Other maintainers and ourselves have taken the other patches (no strong
synchronization needed between them).

Here is the Linux arm kernel patchwork reference:
https://patchwork.kernel.org/patch/2463601/

But for sure, Ludovic or myself can send it again to you if you need.

Thanks, best regards,

> ---
>  .../devicetree/bindings/dma/atmel-dma.txt          | 35 ++++++--
>  drivers/dma/at_hdmac.c                             | 93 ++++++++++++++++++++--
>  drivers/dma/at_hdmac_regs.h                        |  4 +
>  3 files changed, 121 insertions(+), 11 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/dma/atmel-dma.txt b/Documentation/devicetree/bindings/dma/atmel-dma.txt
> index 3c046ee..c80e8a3 100644
> --- a/Documentation/devicetree/bindings/dma/atmel-dma.txt
> +++ b/Documentation/devicetree/bindings/dma/atmel-dma.txt
> @@ -1,14 +1,39 @@
>  * Atmel Direct Memory Access Controller (DMA)
>  
>  Required properties:
> -- compatible: Should be "atmel,<chip>-dma"
> -- reg: Should contain DMA registers location and length
> -- interrupts: Should contain DMA interrupt
> +- compatible: Should be "atmel,<chip>-dma".
> +- reg: Should contain DMA registers location and length.
> +- interrupts: Should contain DMA interrupt.
> +- #dma-cells: Must be <2>, used to represent the number of integer cells in
> +the dmas property of client devices.
>  
> -Examples:
> +Example:
>  
> -dma at ffffec00 {
> +dma0: dma at ffffec00 {
>  	compatible = "atmel,at91sam9g45-dma";
>  	reg = <0xffffec00 0x200>;
>  	interrupts = <21>;
> +	#dma-cells = <2>;
> +};
> +
> +DMA clients connected to the Atmel DMA controller must use the format
> +described in the dma.txt file, using a three-cell specifier for each channel:
> +a phandle plus two interger cells.
> +The three cells in order are:
> +
> +1. A phandle pointing to the DMA controller.
> +2. The memory interface (16 most significant bits), the peripheral interface
> +(16 less significant bits).
> +3. The peripheral identifier for the hardware handshaking interface. The
> +identifier can be different for tx and rx.
> +
> +Example:
> +
> +i2c0 at i2c@f8010000 {
> +	compatible = "atmel,at91sam9x5-i2c";
> +	reg = <0xf8010000 0x100>;
> +	interrupts = <9 4 6>;
> +	dmas = <&dma0 1 7>,
> +	       <&dma0 1 8>;
> +	dma-names = "tx", "rx";
>  };
> diff --git a/drivers/dma/at_hdmac.c b/drivers/dma/at_hdmac.c
> index de4e930..fda2661 100644
> --- a/drivers/dma/at_hdmac.c
> +++ b/drivers/dma/at_hdmac.c
> @@ -24,6 +24,7 @@
>  #include <linux/slab.h>
>  #include <linux/of.h>
>  #include <linux/of_device.h>
> +#include <linux/of_dma.h>
>  
>  #include "at_hdmac_regs.h"
>  #include "dmaengine.h"
> @@ -677,7 +678,7 @@ atc_prep_slave_sg(struct dma_chan *chan, struct scatterlist *sgl,
>  		ctrlb |=  ATC_DST_ADDR_MODE_FIXED
>  			| ATC_SRC_ADDR_MODE_INCR
>  			| ATC_FC_MEM2PER
> -			| ATC_SIF(AT_DMA_MEM_IF) | ATC_DIF(AT_DMA_PER_IF);
> +			| ATC_SIF(atchan->mem_if) | ATC_DIF(atchan->per_if);
>  		reg = sconfig->dst_addr;
>  		for_each_sg(sgl, sg, sg_len, i) {
>  			struct at_desc	*desc;
> @@ -716,7 +717,7 @@ atc_prep_slave_sg(struct dma_chan *chan, struct scatterlist *sgl,
>  		ctrlb |=  ATC_DST_ADDR_MODE_INCR
>  			| ATC_SRC_ADDR_MODE_FIXED
>  			| ATC_FC_PER2MEM
> -			| ATC_SIF(AT_DMA_PER_IF) | ATC_DIF(AT_DMA_MEM_IF);
> +			| ATC_SIF(atchan->per_if) | ATC_DIF(atchan->mem_if);
>  
>  		reg = sconfig->src_addr;
>  		for_each_sg(sgl, sg, sg_len, i) {
> @@ -822,8 +823,8 @@ atc_dma_cyclic_fill_desc(struct dma_chan *chan, struct at_desc *desc,
>  		desc->lli.ctrlb = ATC_DST_ADDR_MODE_FIXED
>  				| ATC_SRC_ADDR_MODE_INCR
>  				| ATC_FC_MEM2PER
> -				| ATC_SIF(AT_DMA_MEM_IF)
> -				| ATC_DIF(AT_DMA_PER_IF);
> +				| ATC_SIF(atchan->mem_if)
> +				| ATC_DIF(atchan->per_if);
>  		break;
>  
>  	case DMA_DEV_TO_MEM:
> @@ -833,8 +834,8 @@ atc_dma_cyclic_fill_desc(struct dma_chan *chan, struct at_desc *desc,
>  		desc->lli.ctrlb = ATC_DST_ADDR_MODE_INCR
>  				| ATC_SRC_ADDR_MODE_FIXED
>  				| ATC_FC_PER2MEM
> -				| ATC_SIF(AT_DMA_PER_IF)
> -				| ATC_DIF(AT_DMA_MEM_IF);
> +				| ATC_SIF(atchan->per_if)
> +				| ATC_DIF(atchan->mem_if);
>  		break;
>  
>  	default:
> @@ -1190,6 +1191,67 @@ static void atc_free_chan_resources(struct dma_chan *chan)
>  	dev_vdbg(chan2dev(chan), "free_chan_resources: done\n");
>  }
>  
> +#ifdef CONFIG_OF
> +static bool at_dma_filter(struct dma_chan *chan, void *slave)
> +{
> +	struct at_dma_slave *atslave = slave;
> +
> +	if (atslave->dma_dev == chan->device->dev) {
> +		chan->private = atslave;
> +		return true;
> +	} else {
> +		return false;
> +	}
> +}
> +
> +static struct dma_chan *at_dma_xlate(struct of_phandle_args *dma_spec,
> +				     struct of_dma *of_dma)
> +{
> +	struct dma_chan *chan;
> +	struct at_dma_chan *atchan;
> +	struct at_dma_slave *atslave;
> +	dma_cap_mask_t mask;
> +	unsigned int per_id;
> +	struct platform_device *dmac_pdev;
> +
> +	if (dma_spec->args_count != 2)
> +		return NULL;
> +
> +	dmac_pdev = of_find_device_by_node(dma_spec->np);
> +
> +	dma_cap_zero(mask);
> +	dma_cap_set(DMA_SLAVE, mask);
> +
> +	atslave = devm_kzalloc(&dmac_pdev->dev, sizeof(*atslave), GFP_KERNEL);
> +	if (!atslave)
> +		return NULL;
> +	/*
> +	 * We can fill both SRC_PER and DST_PER, one of these fields will be
> +	 * ignored depending on DMA transfer direction.
> +	 */
> +	per_id = dma_spec->args[1];
> +	atslave->cfg = ATC_FIFOCFG_HALFFIFO | ATC_DST_H2SEL_HW
> +		      | ATC_SRC_H2SEL_HW | ATC_DST_PER(per_id)
> +		      | ATC_SRC_PER(per_id);
> +	atslave->dma_dev = &dmac_pdev->dev;
> +
> +	chan = dma_request_channel(mask, at_dma_filter, atslave);
> +	if (!chan)
> +		return NULL;
> +
> +	atchan = to_at_dma_chan(chan);
> +	atchan->per_if = dma_spec->args[0] & 0xff;
> +	atchan->mem_if = (dma_spec->args[0] >> 16) & 0xff;
> +
> +	return chan;
> +}
> +#else
> +static struct dma_chan *at_dma_xlate(struct of_phandle_args *dma_spec,
> +				     struct of_dma *of_dma)
> +{
> +	return NULL;
> +}
> +#endif
>  
>  /*--  Module Management  -----------------------------------------------*/
>  
> @@ -1344,6 +1406,8 @@ static int __init at_dma_probe(struct platform_device *pdev)
>  	for (i = 0; i < plat_dat->nr_channels; i++) {
>  		struct at_dma_chan	*atchan = &atdma->chan[i];
>  
> +		atchan->mem_if = AT_DMA_MEM_IF;
> +		atchan->per_if = AT_DMA_PER_IF;
>  		atchan->chan_common.device = &atdma->dma_common;
>  		dma_cookie_init(&atchan->chan_common);
>  		list_add_tail(&atchan->chan_common.device_node,
> @@ -1390,8 +1454,25 @@ static int __init at_dma_probe(struct platform_device *pdev)
>  
>  	dma_async_device_register(&atdma->dma_common);
>  
> +	/*
> +	 * Do not return an error if the dmac node is not present in order to
> +	 * not break the existing way of requesting channel with
> +	 * dma_request_channel().
> +	 */
> +	if (pdev->dev.of_node) {
> +		err = of_dma_controller_register(pdev->dev.of_node,
> +						 at_dma_xlate, atdma);
> +		if (err) {
> +			dev_err(&pdev->dev, "could not register of_dma_controller\n");
> +			goto err_of_dma_controller_register;
> +		}
> +	}
> +
>  	return 0;
>  
> +err_of_dma_controller_register:
> +	dma_async_device_unregister(&atdma->dma_common);
> +	dma_pool_destroy(atdma->dma_desc_pool);
>  err_pool_create:
>  	platform_set_drvdata(pdev, NULL);
>  	free_irq(platform_get_irq(pdev, 0), atdma);
> diff --git a/drivers/dma/at_hdmac_regs.h b/drivers/dma/at_hdmac_regs.h
> index 0eb3c13..c604d26 100644
> --- a/drivers/dma/at_hdmac_regs.h
> +++ b/drivers/dma/at_hdmac_regs.h
> @@ -220,6 +220,8 @@ enum atc_status {
>   * @device: parent device
>   * @ch_regs: memory mapped register base
>   * @mask: channel index in a mask
> + * @per_if: peripheral interface
> + * @mem_if: memory interface
>   * @status: transmit status information from irq/prep* functions
>   *                to tasklet (use atomic operations)
>   * @tasklet: bottom half to finish transaction work
> @@ -238,6 +240,8 @@ struct at_dma_chan {
>  	struct at_dma		*device;
>  	void __iomem		*ch_regs;
>  	u8			mask;
> +	u8			per_if;
> +	u8			mem_if;
>  	unsigned long		status;
>  	struct tasklet_struct	tasklet;
>  	u32			save_cfg;
> 


-- 
Nicolas Ferre


From vinod.koul at intel.com  Mon Apr 22 05:51:30 2013
From: vinod.koul at intel.com (Vinod Koul)
Date: Mon, 22 Apr 2013 15:21:30 +0530
Subject: [PATCH 15/32] dmaengine: ste_dma40: Separate Logical Global
 Interrupt Mask (GIM) unmasking
In-Reply-To: <1366279934-30761-16-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-16-git-send-email-lee.jones@linaro.org>
Message-ID: <20130422095130.GM24632@intel.com>

On Thu, Apr 18, 2013 at 11:11:57AM +0100, Lee Jones wrote:
> During the initial setup of a logical channel, it is necessary to unmask
> the GIM in order to receive generated terminal count and error interrupts.
> We're separating out this required code so it will be possible to move
> the remaining code in d40_phy_cfg(), which is mostly runtime configuration
> into the runtime_config() routine.
> 
> Cc: Vinod Koul <vinod.koul at intel.com>
> Cc: Dan Williams <djbw at fb.com>
> Cc: Per Forlin <per.forlin at stericsson.com>
> Cc: Rabin Vincent <rabin at rab.in>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>
> ---
>  drivers/dma/ste_dma40.c    |    3 +++
>  drivers/dma/ste_dma40_ll.c |   11 ++++++-----
>  drivers/dma/ste_dma40_ll.h |    2 ++
>  3 files changed, 11 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
> index ec0d6ab..178a03c 100644
> --- a/drivers/dma/ste_dma40.c
> +++ b/drivers/dma/ste_dma40.c
> @@ -2456,6 +2456,9 @@ static int d40_alloc_chan_resources(struct dma_chan *chan)
>  				D40_LCPA_CHAN_SIZE + D40_LCPA_CHAN_DST_DELTA;
>  	}
>  
> +	if (chan_is_logical(d40c))
> +		d40_log_gim_unmask(&d40c->src_def_cfg, &d40c->dst_def_cfg);
> +
>  	dev_dbg(chan2dev(d40c), "allocated %s channel (phy %d%s)\n",
>  		 chan_is_logical(d40c) ? "logical" : "physical",
>  		 d40c->phy_chan->num,
> diff --git a/drivers/dma/ste_dma40_ll.c b/drivers/dma/ste_dma40_ll.c
> index 5eb6c10..b72d3e2 100644
> --- a/drivers/dma/ste_dma40_ll.c
> +++ b/drivers/dma/ste_dma40_ll.c
> @@ -50,6 +50,12 @@ void d40_log_cfg(struct stedma40_chan_cfg *cfg,
>  
>  }
>  
> +void d40_log_gim_unmask(u32 *src_cfg, u32 *dst_cfg) {
> +
> +	*src_cfg |= 1 << D40_SREG_CFG_LOG_GIM_POS;
> +	*dst_cfg |= 1 << D40_SREG_CFG_LOG_GIM_POS;
> +}
> +
>  /* Sets up SRC and DST CFG register for both logical and physical channels */
>  void d40_phy_cfg(struct stedma40_chan_cfg *cfg,
>  		 u32 *src_cfg, u32 *dst_cfg, bool is_log)
> @@ -107,11 +113,6 @@ void d40_phy_cfg(struct stedma40_chan_cfg *cfg,
>  			src |= 1 << D40_SREG_CFG_PRI_POS;
>  			dst |= 1 << D40_SREG_CFG_PRI_POS;
shouldnt these be converted to BIT() macro and in gim_unmask above?
Driver needs to be consistent in doing things

>  		}
> -
> -	} else {
> -		/* Logical channel */
> -		dst |= 1 << D40_SREG_CFG_LOG_GIM_POS;
> -		src |= 1 << D40_SREG_CFG_LOG_GIM_POS;
>  	}
>  
>  	if (cfg->src_info.big_endian)
> diff --git a/drivers/dma/ste_dma40_ll.h b/drivers/dma/ste_dma40_ll.h
> index fdde8ef..8aad679 100644
> --- a/drivers/dma/ste_dma40_ll.h
> +++ b/drivers/dma/ste_dma40_ll.h
> @@ -430,6 +430,8 @@ enum d40_lli_flags {
>  	LLI_LAST_LINK	= 1 << 3,
>  };
>  
> +void d40_log_gim_unmask(u32 *src_cfg, u32 *dst_cfg);
> +
>  void d40_phy_cfg(struct stedma40_chan_cfg *cfg,
>  		 u32 *src_cfg,
>  		 u32 *dst_cfg,
> -- 
> 1.7.10.4
> 


From vinod.koul at intel.com  Mon Apr 22 05:52:18 2013
From: vinod.koul at intel.com (Vinod Koul)
Date: Mon, 22 Apr 2013 15:22:18 +0530
Subject: [PATCH 16/32] dmaengine: ste_dma40: Remove unnecessary call to
 d40_phy_cfg()
In-Reply-To: <1366279934-30761-17-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-17-git-send-email-lee.jones@linaro.org>
Message-ID: <20130422095218.GN24632@intel.com>

On Thu, Apr 18, 2013 at 11:11:58AM +0100, Lee Jones wrote:
> All configuration left in d40_phy_cfg() is runtime configurable and
> there is already a call into it from d40_runtime_config(), so let's
> rely on that.
> 
> Cc: Vinod Koul <vinod.koul at intel.com>
> Cc: Dan Williams <djbw at fb.com>
> Cc: Per Forlin <per.forlin at stericsson.com>
> Cc: Rabin Vincent <rabin at rab.in>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>
Acked-by: Vinod Koul <vinod.koul at intel.com>

--
~Vinod
> ---
>  drivers/dma/ste_dma40.c |    3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
> index 178a03c..1c570b6 100644
> --- a/drivers/dma/ste_dma40.c
> +++ b/drivers/dma/ste_dma40.c
> @@ -2437,9 +2437,6 @@ static int d40_alloc_chan_resources(struct dma_chan *chan)
>  	}
>  
>  	pm_runtime_get_sync(d40c->base->dev);
> -	/* Fill in basic CFG register values */
> -	d40_phy_cfg(&d40c->dma_cfg, &d40c->src_def_cfg,
> -		    &d40c->dst_def_cfg, chan_is_logical(d40c));
>  
>  	d40_set_prio_realtime(d40c);
>  
> -- 
> 1.7.10.4
> 


From tomi.valkeinen at ti.com  Mon Apr 22 06:24:56 2013
From: tomi.valkeinen at ti.com (Tomi Valkeinen)
Date: Mon, 22 Apr 2013 13:24:56 +0300
Subject: Multiple issues with omap4 panda es in linux next
In-Reply-To: <5174FE16.6080307@ti.com>
References: <20130419171318.GK10155@atomide.com> <5174FE16.6080307@ti.com>
Message-ID: <51750FF8.6000401@ti.com>

On 2013-04-22 12:08, Tomi Valkeinen wrote:
> On 2013-04-19 20:13, Tony Lindgren wrote:
> 
>> 3. DSS fails with DT booting
>>
>> Works with legacy booting but fails with DT. I'm almost certain
>> the DT booting was working last week or so?
>>
>> This is what I now get with DT booting:
>>
>> omapdss DSI error: can't get VDDS_DSI regulator
>> omapdss HDMI error: can't get VDDA_HDMI_DAC regulator
>> omapdss HDMI error: device hdmi init failed: -517
>> omapdss CORE error: driver probe failed: -22
>> ...
> 
> I think this is the issue Christoph Fritz reported earlier, DSS is being
> initialized before TWL, and thus DSS doesn't find the regulators.
> 
> The proper fix is of course to make DSS support EPROBE_DEFER, but that's
> easier said than done. I'll have a look if I can get it working enough
> to fix this issue.

Yes, it seems delayed regulator initialization brought up this issue.

I hacked DSI driver of omapdss and Taal panel driver to somewhat work
with EPROBE_DEFER. But then the issue was with omapfb.

omapfb is currently set to start at late_initcall, so that omapdss and
panels are loaded before omapfb. But even that's not late enough to get
the regulators for omapdss. It seems the regulators get also initialized
at the late_initcall level. Changing omapfb to late_initcall_sync was
late enough to get things working.

Again, making omapdss, panel drivers and omapfb support EPROBE_DEFER and
dynamic panel driver insertion is the proper fix, but it's a big job,
and there are "interesting" issues with it (like how to know if a panel
device will ever get a driver loaded).

But is there something wrong with the TWL and regulators? late_initcall
sounds rather late for such a core resource. Even if all drivers
supported EPROBE_DEFER, won't it cause extra delays in the boot as
drivers are getting probed multiple times?

As for fixing the DSS problem for 3.10, I don't have any ideas except
pure hacks. I'll continue studying this.

 Tomi


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130422/f61fc675/attachment-0001.sig>

From lee.jones at linaro.org  Mon Apr 22 06:27:48 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Mon, 22 Apr 2013 11:27:48 +0100
Subject: [PATCH 05/32] dmaengine: ste_dma40: Supply macros to resolve
 'src' and 'dst' directions
In-Reply-To: <20130422094250.GJ24632@intel.com>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-6-git-send-email-lee.jones@linaro.org>
 <20130422094250.GJ24632@intel.com>
Message-ID: <20130422102748.GJ3432@gmail.com>

On Mon, 22 Apr 2013, Vinod Koul wrote:

> On Thu, Apr 18, 2013 at 11:11:47AM +0100, Lee Jones wrote:
> > There are lots of lengthy if() statements located sporadically up and
> > down the driver. This simple macro should make many of them a little
> > simpler to decipher. The remainder have to stay in place, as they
> > detail slightly more specific settings.
> I would like these to be DMAENGINE_IS_SRC...

I don't understand, as they're DMA40 specific?

> and this patch use the defines provided in dmaengine

I think a subsequent patch doing he following would be more suitable:

s/STEDMA40_MEM_TO_MEM/DMA_MEM_TO_MEM/
s/STEDMA40_MEM_TO_PERIPH/DMA_MEM_TO_DEV/
s/STEDMA40_PERIPH_TO_MEM/DMA_DEV_TO_MEM/
s/STEDMA40_PERIPH_TO_PERIPH/DMA_DEV_TO_DEV/

If you don't mind?

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From vinod.koul at intel.com  Mon Apr 22 06:02:57 2013
From: vinod.koul at intel.com (Vinod Koul)
Date: Mon, 22 Apr 2013 15:32:57 +0530
Subject: [PATCH 23/32] dmaengine: ste_dma40: Allow driver to be
 probe()able when DT is enabled
In-Reply-To: <1366279934-30761-24-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-24-git-send-email-lee.jones@linaro.org>
Message-ID: <20130422100257.GO24632@intel.com>

On Thu, Apr 18, 2013 at 11:12:05AM +0100, Lee Jones wrote:
> When booting using Device Tree, devices aren't registered in the normal
> way. Instead, they need to be provided with a compatible string which is
> held in an OF Match Table for comparison during start-up. Here we provide
> the compatible string and prepare the driver to not receive a platform
> data pointer.
> 
> Cc: Vinod Koul <vinod.koul at intel.com>
> Cc: Dan Williams <djbw at fb.com>
> Cc: Per Forlin <per.forlin at stericsson.com>
> Cc: Rabin Vincent <rabin at rab.in>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>
Acked-by: Vinod Koul <vinod.koul at intel.com>

--
~Vinod
> ---
>  drivers/dma/ste_dma40.c |   42 ++++++++++++++++++++++++++++++++++++++++--
>  1 file changed, 40 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
> index 6f9f801..4782ee7 100644
> --- a/drivers/dma/ste_dma40.c
> +++ b/drivers/dma/ste_dma40.c
> @@ -17,6 +17,7 @@
>  #include <linux/pm.h>
>  #include <linux/pm_runtime.h>
>  #include <linux/err.h>
> +#include <linux/of.h>
>  #include <linux/amba/bus.h>
>  #include <linux/regulator/consumer.h>
>  #include <linux/platform_data/dma-ste-dma40.h>
> @@ -3452,17 +3453,48 @@ failure:
>  	return ret;
>  }
>  
> +static int __init d40_of_probe(struct platform_device *pdev,
> +			       struct device_node *np)
> +{
> +	/*
> +	 * FIXME: Fill in this routine as more support is added.
> +	 * First platform enabled (u8500) doens't need any extra
> +	 * properties to run, so this is fairly sparce currently.
> +	 */
> +	pdev->dev.platform_data =
> +		devm_kzalloc(&pdev->dev,
> +			     sizeof(struct stedma40_platform_data),
> +			     GFP_KERNEL);
> +	if (!pdev->dev.platform_data)
> +		return -ENOMEM;
> +
> +	return 0;
> +}
> +
>  static int __init d40_probe(struct platform_device *pdev)
>  {
> +	struct stedma40_platform_data *plat_data = pdev->dev.platform_data;
> +	struct device_node *np = pdev->dev.of_node;
>  	int err;
>  	int ret = -ENOENT;
> -	struct d40_base *base;
> +	struct d40_base *base = NULL;
>  	struct resource *res = NULL;
>  	int num_reserved_chans;
>  	u32 val;
>  
> -	base = d40_hw_detect_init(pdev);
> +	if (!plat_data) {
> +		if (np) {
> +			if(d40_of_probe(pdev, np)) {
> +				ret = -ENOMEM;
> +				goto failure;
> +			}
> +		} else {
> +			d40_err(&pdev->dev, "No pdata or Device Tree provided\n");
> +			goto failure;
> +		}
> +	}
>  
> +	base = d40_hw_detect_init(pdev);
>  	if (!base)
>  		goto failure;
>  
> @@ -3636,11 +3668,17 @@ failure:
>  	return ret;
>  }
>  
> +static const struct of_device_id d40_match[] = {
> +        { .compatible = "stericsson,dma40", },
> +        {}
> +};
> +
>  static struct platform_driver d40_driver = {
>  	.driver = {
>  		.owner = THIS_MODULE,
>  		.name  = D40_NAME,
>  		.pm = DMA40_PM_OPS,
> +		.of_match_table = d40_match,
>  	},
>  };
>  
> -- 
> 1.7.10.4
> 


From lee.jones at linaro.org  Mon Apr 22 06:37:15 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Mon, 22 Apr 2013 11:37:15 +0100
Subject: [PATCH 21/32] dmaengine: ste_dma40: Also report the number of
 logical channels
In-Reply-To: <20130422094842.GL24632@intel.com>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-22-git-send-email-lee.jones@linaro.org>
 <20130422093631.GE24632@intel.com>
 <20130422101455.GH3432@gmail.com>
 <20130422094842.GL24632@intel.com>
Message-ID: <20130422103715.GK3432@gmail.com>

On Mon, 22 Apr 2013, Vinod Koul wrote:

> On Mon, Apr 22, 2013 at 11:14:55AM +0100, Lee Jones wrote:
> > On Mon, 22 Apr 2013, Vinod Koul wrote:
> > 
> > > On Thu, Apr 18, 2013 at 11:12:03AM +0100, Lee Jones wrote:
> > > > Now we know the total of physical and logical channels, we may as
> > > > well report them within the information log.
> > > > 
> > > > Before:
> > > > dma40 dma40.0: hardware revision: 3 @ 0x801c0000 with 8 physical channels
> > > > 
> > > > After:
> > > > <as above ...> and 256 logical channels
> > > > 
> > > > Cc: Vinod Koul <vinod.koul at intel.com>
> > > > Cc: Dan Williams <djbw at fb.com>
> > > > Cc: Per Forlin <per.forlin at stericsson.com>
> > > > Cc: Rabin Vincent <rabin at rab.in>
> > > > Signed-off-by: Lee Jones <lee.jones at linaro.org>
> > > > ---
> > > >  drivers/dma/ste_dma40.c |    5 +++--
> > > >  1 file changed, 3 insertions(+), 2 deletions(-)
> > > > 
> > > > diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
> > > > index 282dd59..805049c 100644
> > > > --- a/drivers/dma/ste_dma40.c
> > > > +++ b/drivers/dma/ste_dma40.c
> > > > @@ -3200,8 +3200,9 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
> > > >  
> > > >  	num_log_chans = num_phy_chans * D40_MAX_LOG_CHAN_PER_PHY;
> > > >  
> > > > -	dev_info(&pdev->dev, "hardware revision: %d @ 0x%x with %d physical channels\n",
> > > > -		 rev, res->start, num_phy_chans);
> > > > +	dev_info(&pdev->dev, "hardware revision: %d @ 0x%x with "
> > > > +		"%d physical channels and %d logical channels\n",
> > > > +		rev, res->start, num_phy_chans, num_log_chans);
> > > Splitting log messages across lines is bad idea and sacrifces readablity... also
> > > wasnt splitting logging to multiple lines emit checkpatch warn
> > 
> > You also get a check-patch error if your lines are over 80 chars.
> No, you get a warn

You only get a warning for this too:

 WARNING: quoted string split across lines
#33: FILE: drivers/dma/ste_dma40.c:3204:
+	dev_info(&pdev->dev, "hardware revision: %d @ 0x%x with "
+		"%d physical channels and %d logical channels\n",

> > How would you solve this?
> Use common sense :) I would never sacrfice readablity of code. Erring on 80chars
> is fine by me as long as it makes sense.

Common sense to me says split a string which goes over 100 chars. :)

... and I don't think readability is compromised all that much, if at all.

But you're the maintainer. I'll go with whatever you decide.

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From andre.przywara at linaro.org  Mon Apr 22 06:36:58 2013
From: andre.przywara at linaro.org (Andre Przywara)
Date: Mon, 22 Apr 2013 12:36:58 +0200
Subject: [PATCH] ARM: KVM: iterate over all CPUs for CPU compatibility
 check
In-Reply-To: <CAEDV+gL=rbxxBRgYdHxBj_C9ZBFbuORaG0jcSzEUJ7pO9-Fqkg@mail.gmail.com>
References: <51680AF9.7040109@arm.com>
 <CAEDV+g+E8PLc60vMRhq4O_AL2WjmYDLb6=Wh34ynhevh7uAGJA@mail.gmail.com>
 <d455f2823b9639af8d38d30f2c3234bd@localhost>
 <CAEDV+gJuFG49oQ=BEaCHcTP=nHVyX8ALw6076dR_C1s7TuyqXQ@mail.gmail.com>
 <d47697abd39a0d5d41f5ac110a40e261@localhost>
 <CAEDV+gK9==sXYxRVZ8JVFYPiw3_xgzZBbydEwPunmnocNLKXrQ@mail.gmail.com>
 <CAFEAcA-bPoa8YoPuHPmupzfUW+yR233XquK79eNorzcRpFiK=g@mail.gmail.com>
 <516BCAD0.9000708@linaro.org>
 <CAJRNFKJoBzgt4UhxsH65_LyhcGXPnzB_pg3q-zeYT2OVv59q4A@mail.gmail.com>
 <516BFD13.1000400@linaro.org>
 <20130415134837.GI9827@mudshark.cambridge.arm.com>
 <CAEDV+gJB7Bj9O7pftFqoYQ=goORjdurBnEfQVmC5arDuNJfpBg@mail.gmail.com>
 <32d532438f5b621e40679aea9f5888c7@localhost> <516E586C.5030407@linaro.org>
 <8e0bda3fd84d1b0c5aa55161ca178a8e@localhost>
 <CAEDV+g+3nkdvbLdj0m-ZdDKt0JY2vgzhP2AQA2nf=R3h4yTQmQ@mail.gmail.com>
 <51713F91.5080102@linaro.org>
 <CAEDV+gL=rbxxBRgYdHxBj_C9ZBFbuORaG0jcSzEUJ7pO9-Fqkg@mail.gmail.com>
Message-ID: <517512CA.6070503@linaro.org>

On 04/19/2013 06:13 PM, Christoffer Dall wrote:
> On Fri, Apr 19, 2013 at 5:58 AM, Andre Przywara
> <andre.przywara at linaro.org> wrote:
>> On 04/17/2013 11:12 AM, Christoffer Dall wrote:
>>>
>>>  ...
>>>
>>> You could also try installing a vector handler early and detect faults,
>>> and add an alternative return path from the init function with some
>>> error reporting value in r0 or something like that, just for debugging,
>>> naturally, but that could be a way to detect if we really are taking
>>> recursive faults here.
>>
>>
>> OK, I added code to return earlier on CPUs not from cluster 0.
>> Indeed it hangs in the HSCR write. The two A15s pass this instruction,
>> writing 0x30c5187F into the register.
>> This means all the fixed bits for A15 correctly, C,A,M and I set and WXN,
>> EE, TE cleared. FI was also cleared
>> The A7 wanted to write the very same value. I tried to set bit 21, which
>> kind of the A7 TRM hints to do: but no change.
>> Before the HSCLTR write, the register reads 0x30c50878, with SCTLR being
>> 0x30c5387d.
>> So the code wants to set M, A, C and I in HSCLTR. Interestingly SCTLR has
>> the V bits set, could that be an issue?
>>
> Can you try writing 0x30c50879 into the register instead? Basically
> check to see if enabling caches or alignment checks causes the issue,
> or if it is indeed enabling the MMU that's the issue... If that works,
> start a bisect on the remaining bits. Also, just for fun, could you
> try flushing the entire I-cache before writing into the HSCLTR?

OK, both clearing the I-bit and doing an "isb; ICIALLU" before the "isb; 
write HSCLTR; isb" worked, the kernel boots on and KVM is enabled.

I could easily make a patch, but I am not sure how to proceed from here:

1.) At least I don't have an understanding why this is only a problem on 
A7 and not on A15. I would feel better if we have an explanation for 
this. Mark, Will, Peter: any ideas?

2.) We still do not claim to support A7s. ARM_CPU_PART_CORTEX_A15 is the 
only MIDR content not returning -EINVAL. And there is no coproc_a7.c 
yet. From browsing through coproc_a15.c I sense it looks compatible to 
the A7, only handling L2CTLR[25:24] and ACTLR[SMP] explicitly. On pure 
A7 systems this should work, but in mixed (aka. b.L) systems guests 
would see inconsistent input depending on the current scheduling. This 
looks like we need a real solution, which needs some time and work 
(read: proper b.L support).

3.) Even if we would understand this fix and take it, the kernel 
currently still randomly enables or disables KVM - with only A15 
supported and the check routine running on one of the cores only.
And even if we add A7 to the list, I think we still need to iterate 
through all cores to catch unsupported cores in a different b.L 
configuration.

I suppose it is to late for 3.9 in any case right? Or should we try to 
push at least the ICIALLU fix?

> Why wouldn't the V bit be set in the SCTLR, Linus uses high vectors
> (at 0xffff0000) for exception handling on ARM.

Shame on me, didn't know this. I assumed that those high vectors are 
there for legacy reasons only. Good to know and thanks for telling me.


Regards,
Andre.



From lee.jones at linaro.org  Mon Apr 22 06:40:12 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Mon, 22 Apr 2013 11:40:12 +0100
Subject: [PATCH 15/32] dmaengine: ste_dma40: Separate Logical Global
 Interrupt Mask (GIM) unmasking
In-Reply-To: <20130422095130.GM24632@intel.com>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-16-git-send-email-lee.jones@linaro.org>
 <20130422095130.GM24632@intel.com>
Message-ID: <20130422104012.GL3432@gmail.com>

> >  void d40_phy_cfg(struct stedma40_chan_cfg *cfg,
> >  		 u32 *src_cfg, u32 *dst_cfg, bool is_log)
> > @@ -107,11 +113,6 @@ void d40_phy_cfg(struct stedma40_chan_cfg *cfg,
> >  			src |= 1 << D40_SREG_CFG_PRI_POS;
> >  			dst |= 1 << D40_SREG_CFG_PRI_POS;
> shouldnt these be converted to BIT() macro and in gim_unmask above?
> Driver needs to be consistent in doing things

Absolutely they do. I haven't converted ste_dma40_ll.c to BIT yet
though. I have this on my TODO and it will happen in the next
patch-set.

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From vinod.koul at intel.com  Mon Apr 22 06:10:29 2013
From: vinod.koul at intel.com (Vinod Koul)
Date: Mon, 22 Apr 2013 15:40:29 +0530
Subject: [PATCH 08/32] dmaengine: ste_dma40: Optimise local MAX() macro
In-Reply-To: <1366279934-30761-9-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-9-git-send-email-lee.jones@linaro.org>
Message-ID: <20130422101029.GP24632@intel.com>

On Thu, Apr 18, 2013 at 11:11:50AM +0100, Lee Jones wrote:
> The current implementation of the DMA40's local MAX() macro evaluates
> its arguments more times than is necessary. This patch strips it
> optimises it to only evaluate what's appropriate.
> 
> Cc: Vinod Koul <vinod.koul at intel.com>
> Cc: Dan Williams <djbw at fb.com>
> Cc: Per Forlin <per.forlin at stericsson.com>
> Cc: Rabin Vincent <rabin at rab.in>
> Reported-by: Harvey Harrison <harvey.harrison at gmail.com>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>
> ---
>  drivers/dma/ste_dma40.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
> index b21a8a3..7b451b2 100644
> --- a/drivers/dma/ste_dma40.c
> +++ b/drivers/dma/ste_dma40.c
> @@ -53,7 +53,7 @@
>  #define D40_ALLOC_PHY		BIT(30)
>  #define D40_ALLOC_LOG_FREE	BIT(0)
>  
> -#define MAX(a, b) (((a) < (b)) ? (b) : (a))
> +#define MAX(a, b) ((a > b) ? a : b)
Am not a big fan of own redefines, can you use kernel max() macro instead

--
~Vinod
>  
>  #define D40_IS_SRC(dir)  ((dir == STEDMA40_PERIPH_TO_MEM) ? true : false)
>  #define D40_IS_DST(dir) (((dir == STEDMA40_MEM_TO_PERIPH) || \
> -- 
> 1.7.10.4
> 


From Andrew.Murray at arm.com  Mon Apr 22 06:41:35 2013
From: Andrew.Murray at arm.com (Andrew Murray)
Date: Mon, 22 Apr 2013 11:41:35 +0100
Subject: [PATCH v8 3/3] of/pci: mips: convert to common of_pci_range_parser
In-Reply-To: <1366627295-16964-1-git-send-email-Andrew.Murray@arm.com>
References: <1366627295-16964-1-git-send-email-Andrew.Murray@arm.com>
Message-ID: <1366627295-16964-4-git-send-email-Andrew.Murray@arm.com>

This patch converts the pci_load_of_ranges function to use the new common
of_pci_range_parser.

Signed-off-by: Andrew Murray <Andrew.Murray at arm.com>
Signed-off-by: Liviu Dudau <Liviu.Dudau at arm.com>
Signed-off-by: Gabor Juhos <juhosg at openwrt.org>
Reviewed-by: Rob Herring <rob.herring at calxeda.com>
Reviewed-by: Grant Likely <grant.likely at secretlab.ca>
Tested-by: Linus Walleij <linus.walleij at linaro.org>
---
 arch/mips/pci/pci.c |   51 +++++++++++++++++++--------------------------------
 1 files changed, 19 insertions(+), 32 deletions(-)

diff --git a/arch/mips/pci/pci.c b/arch/mips/pci/pci.c
index 0872f12..4b09ca8 100644
--- a/arch/mips/pci/pci.c
+++ b/arch/mips/pci/pci.c
@@ -122,51 +122,38 @@ static void pcibios_scanbus(struct pci_controller *hose)
 #ifdef CONFIG_OF
 void pci_load_of_ranges(struct pci_controller *hose, struct device_node *node)
 {
-	const __be32 *ranges;
-	int rlen;
-	int pna = of_n_addr_cells(node);
-	int np = pna + 5;
+	struct of_pci_range range;
+	struct of_pci_range_parser parser;
+	u32 res_type;
 
 	pr_info("PCI host bridge %s ranges:\n", node->full_name);
-	ranges = of_get_property(node, "ranges", &rlen);
-	if (ranges == NULL)
-		return;
 	hose->of_node = node;
 
-	while ((rlen -= np * 4) >= 0) {
-		u32 pci_space;
+	if (of_pci_range_parser_init(&parser, node))
+		return;
+
+	for_each_of_pci_range(&parser, &range) {
 		struct resource *res = NULL;
-		u64 addr, size;
-
-		pci_space = be32_to_cpup(&ranges[0]);
-		addr = of_translate_address(node, ranges + 3);
-		size = of_read_number(ranges + pna + 3, 2);
-		ranges += np;
-		switch ((pci_space >> 24) & 0x3) {
-		case 1:		/* PCI IO space */
+
+		switch (range.flags & IORESOURCE_TYPE_BITS) {
+		case IORESOURCE_IO:
 			pr_info("  IO 0x%016llx..0x%016llx\n",
-					addr, addr + size - 1);
+				range.cpu_addr,
+				range.cpu_addr + range.size - 1);
 			hose->io_map_base =
-				(unsigned long)ioremap(addr, size);
+				(unsigned long)ioremap(range.cpu_addr,
+						       range.size);
 			res = hose->io_resource;
-			res->flags = IORESOURCE_IO;
 			break;
-		case 2:		/* PCI Memory space */
-		case 3:		/* PCI 64 bits Memory space */
+		case IORESOURCE_MEM:
 			pr_info(" MEM 0x%016llx..0x%016llx\n",
-					addr, addr + size - 1);
+				range.cpu_addr,
+				range.cpu_addr + range.size - 1);
 			res = hose->mem_resource;
-			res->flags = IORESOURCE_MEM;
 			break;
 		}
-		if (res != NULL) {
-			res->start = addr;
-			res->name = node->full_name;
-			res->end = res->start + size - 1;
-			res->parent = NULL;
-			res->sibling = NULL;
-			res->child = NULL;
-		}
+		if (res != NULL)
+			of_pci_range_to_resource(&range, node, res);
 	}
 }
 #endif
-- 
1.7.0.4



From Andrew.Murray at arm.com  Mon Apr 22 06:41:34 2013
From: Andrew.Murray at arm.com (Andrew Murray)
Date: Mon, 22 Apr 2013 11:41:34 +0100
Subject: [PATCH v8 2/3] of/pci: Provide support for parsing PCI DT ranges
 property
In-Reply-To: <1366627295-16964-1-git-send-email-Andrew.Murray@arm.com>
References: <1366627295-16964-1-git-send-email-Andrew.Murray@arm.com>
Message-ID: <1366627295-16964-3-git-send-email-Andrew.Murray@arm.com>

This patch factors out common implementation patterns to reduce overall kernel
code and provide a means for host bridge drivers to directly obtain struct
resources from the DT's ranges property without relying on architecture specific
DT handling. This will make it easier to write archiecture independent host bridge
drivers and mitigate against further duplication of DT parsing code.

This patch can be used in the following way:

	struct of_pci_range_parser parser;
	struct of_pci_range range;

	if (of_pci_range_parser_init(&parser, np))
		; //no ranges property

	for_each_of_pci_range(&parser, &range) {

		/*
			directly access properties of the address range, e.g.:
			range.pci_space, range.pci_addr, range.cpu_addr,
			range.size, range.flags

			alternatively obtain a struct resource, e.g.:
			struct resource res;
			of_pci_range_to_resource(&range, np, &res);
		*/
	}

Additionally the implementation takes care of adjacent ranges and merges them
into a single range (as was the case with powerpc and microblaze).

Signed-off-by: Andrew Murray <Andrew.Murray at arm.com>
Signed-off-by: Liviu Dudau <Liviu.Dudau at arm.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Reviewed-by: Rob Herring <rob.herring at calxeda.com>
Tested-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Tested-by: Linus Walleij <linus.walleij at linaro.org>
Acked-by: Grant Likely <grant.likely at secretlab.ca>
---
 drivers/of/address.c       |   67 ++++++++++++++++++++++++++
 drivers/of/of_pci.c        |  113 +++++++++++++++++---------------------------
 include/linux/of_address.h |   48 +++++++++++++++++++
 3 files changed, 158 insertions(+), 70 deletions(-)

diff --git a/drivers/of/address.c b/drivers/of/address.c
index 04da786..fdd0636 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -227,6 +227,73 @@ int of_pci_address_to_resource(struct device_node *dev, int bar,
 	return __of_address_to_resource(dev, addrp, size, flags, NULL, r);
 }
 EXPORT_SYMBOL_GPL(of_pci_address_to_resource);
+
+int of_pci_range_parser_init(struct of_pci_range_parser *parser,
+				struct device_node *node)
+{
+	const int na = 3, ns = 2;
+	int rlen;
+
+	parser->node = node;
+	parser->pna = of_n_addr_cells(node);
+	parser->np = parser->pna + na + ns;
+
+	parser->range = of_get_property(node, "ranges", &rlen);
+	if (parser->range == NULL)
+		return -ENOENT;
+
+	parser->end = parser->range + rlen / sizeof(__be32);
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(of_pci_range_parser_init);
+
+struct of_pci_range *of_pci_range_parser_one(struct of_pci_range_parser *parser,
+						struct of_pci_range *range)
+{
+	const int na = 3, ns = 2;
+
+	if (!range)
+		return NULL;
+
+	if (!parser->range || parser->range + parser->np > parser->end)
+		return NULL;
+
+	range->pci_space = parser->range[0];
+	range->flags = of_bus_pci_get_flags(parser->range);
+	range->pci_addr = of_read_number(parser->range + 1, ns);
+	range->cpu_addr = of_translate_address(parser->node,
+				parser->range + na);
+	range->size = of_read_number(parser->range + parser->pna + na, ns);
+
+	parser->range += parser->np;
+
+	/* Now consume following elements while they are contiguous */
+	while (parser->range + parser->np <= parser->end) {
+		u32 flags, pci_space;
+		u64 pci_addr, cpu_addr, size;
+
+		pci_space = be32_to_cpup(parser->range);
+		flags = of_bus_pci_get_flags(parser->range);
+		pci_addr = of_read_number(parser->range + 1, ns);
+		cpu_addr = of_translate_address(parser->node,
+				parser->range + na);
+		size = of_read_number(parser->range + parser->pna + na, ns);
+
+		if (flags != range->flags)
+			break;
+		if (pci_addr != range->pci_addr + range->size ||
+		    cpu_addr != range->cpu_addr + range->size)
+			break;
+
+		range->size += size;
+		parser->range += parser->np;
+	}
+
+	return range;
+}
+EXPORT_SYMBOL_GPL(of_pci_range_parser_one);
+
 #endif /* CONFIG_PCI */
 
 /*
diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
index 1626172..3c49ab2 100644
--- a/drivers/of/of_pci.c
+++ b/drivers/of/of_pci.c
@@ -2,6 +2,7 @@
 #include <linux/export.h>
 #include <linux/of.h>
 #include <linux/of_pci.h>
+#include <linux/of_address.h>
 #include <asm/prom.h>
 
 #if defined(CONFIG_PPC32) || defined(CONFIG_PPC64) || defined(CONFIG_MICROBLAZE)
@@ -82,67 +83,42 @@ EXPORT_SYMBOL_GPL(of_pci_find_child_device);
 void pci_process_bridge_OF_ranges(struct pci_controller *hose,
 				  struct device_node *dev, int primary)
 {
-	const u32 *ranges;
-	int rlen;
-	int pna = of_n_addr_cells(dev);
-	int np = pna + 5;
 	int memno = 0, isa_hole = -1;
-	u32 pci_space;
-	unsigned long long pci_addr, cpu_addr, pci_next, cpu_next, size;
 	unsigned long long isa_mb = 0;
 	struct resource *res;
+	struct of_pci_range range;
+	struct of_pci_range_parser parser;
 
 	pr_info("PCI host bridge %s %s ranges:\n",
 	       dev->full_name, primary ? "(primary)" : "");
 
-	/* Get ranges property */
-	ranges = of_get_property(dev, "ranges", &rlen);
-	if (ranges == NULL)
+	/* Check for ranges property */
+	if (of_pci_range_parser_init(&parser, dev))
 		return;
 
-	/* Parse it */
 	pr_debug("Parsing ranges property...\n");
-	while ((rlen -= np * 4) >= 0) {
+	for_each_of_pci_range(&parser, &range) {
 		/* Read next ranges element */
-		pci_space = ranges[0];
-		pci_addr = of_read_number(ranges + 1, 2);
-		cpu_addr = of_translate_address(dev, ranges + 3);
-		size = of_read_number(ranges + pna + 3, 2);
-
-		pr_debug("pci_space: 0x%08x pci_addr:0x%016llx ",
-				pci_space, pci_addr);
-		pr_debug("cpu_addr:0x%016llx size:0x%016llx\n",
-					cpu_addr, size);
-
-		ranges += np;
+		pr_debug("pci_space: 0x%08x pci_addr: 0x%016llx ",
+				range.pci_space, range.pci_addr);
+		pr_debug("cpu_addr: 0x%016llx size: 0x%016llx\n",
+				range.cpu_addr, range.size);
 
 		/* If we failed translation or got a zero-sized region
 		 * (some FW try to feed us with non sensical zero sized regions
 		 * such as power3 which look like some kind of attempt
 		 * at exposing the VGA memory hole)
 		 */
-		if (cpu_addr == OF_BAD_ADDR || size == 0)
+		if (range.cpu_addr == OF_BAD_ADDR || range.size == 0)
 			continue;
 
-		/* Now consume following elements while they are contiguous */
-		for (; rlen >= np * sizeof(u32);
-		     ranges += np, rlen -= np * 4) {
-			if (ranges[0] != pci_space)
-				break;
-			pci_next = of_read_number(ranges + 1, 2);
-			cpu_next = of_translate_address(dev, ranges + 3);
-			if (pci_next != pci_addr + size ||
-			    cpu_next != cpu_addr + size)
-				break;
-			size += of_read_number(ranges + pna + 3, 2);
-		}
-
 		/* Act based on address space type */
 		res = NULL;
-		switch ((pci_space >> 24) & 0x3) {
-		case 1:		/* PCI IO space */
+		switch (range.flags & IORESOURCE_TYPE_BITS) {
+		case IORESOURCE_IO:
 			pr_info("  IO 0x%016llx..0x%016llx -> 0x%016llx\n",
-			       cpu_addr, cpu_addr + size - 1, pci_addr);
+				range.cpu_addr, range.cpu_addr + range.size - 1,
+				range.pci_addr);
 
 			/* We support only one IO range */
 			if (hose->pci_io_size) {
@@ -151,11 +127,12 @@ void pci_process_bridge_OF_ranges(struct pci_controller *hose,
 			}
 #if (!IS_ENABLED(CONFIG_64BIT))
 			/* On 32 bits, limit I/O space to 16MB */
-			if (size > 0x01000000)
-				size = 0x01000000;
+			if (range.size > 0x01000000)
+				range.size = 0x01000000;
 
 			/* 32 bits needs to map IOs here */
-			hose->io_base_virt = ioremap(cpu_addr, size);
+			hose->io_base_virt = ioremap(range.cpu_addr,
+						range.size);
 
 			/* Expect trouble if pci_addr is not 0 */
 			if (primary)
@@ -165,19 +142,21 @@ void pci_process_bridge_OF_ranges(struct pci_controller *hose,
 			/* pci_io_size and io_base_phys always represent IO
 			 * space starting at 0 so we factor in pci_addr
 			 */
-			hose->pci_io_size = pci_addr + size;
-			hose->io_base_phys = cpu_addr - pci_addr;
+			hose->pci_io_size = range.pci_addr + range.size;
+			hose->io_base_phys = range.cpu_addr - range.pci_addr;
 
 			/* Build resource */
 			res = &hose->io_resource;
-			res->flags = IORESOURCE_IO;
-			res->start = pci_addr;
+			range.cpu_addr = range.pci_addr;
+
 			break;
-		case 2:		/* PCI Memory space */
-		case 3:		/* PCI 64 bits Memory space */
+
+		case IORESOURCE_MEM:
 			pr_info(" MEM 0x%016llx..0x%016llx -> 0x%016llx %s\n",
-			       cpu_addr, cpu_addr + size - 1, pci_addr,
-			       (pci_space & 0x40000000) ? "Prefetch" : "");
+				range.cpu_addr, range.cpu_addr + range.size - 1,
+				range.pci_addr,
+				(range.pci_space & 0x40000000) ?
+				"Prefetch" : "");
 
 			/* We support only 3 memory ranges */
 			if (memno >= 3) {
@@ -185,13 +164,13 @@ void pci_process_bridge_OF_ranges(struct pci_controller *hose,
 				continue;
 			}
 			/* Handles ISA memory hole space here */
-			if (pci_addr == 0) {
-				isa_mb = cpu_addr;
+			if (range.pci_addr == 0) {
+				isa_mb = range.cpu_addr;
 				isa_hole = memno;
 				if (primary || isa_mem_base == 0)
-					isa_mem_base = cpu_addr;
-				hose->isa_mem_phys = cpu_addr;
-				hose->isa_mem_size = size;
+					isa_mem_base = range.cpu_addr;
+				hose->isa_mem_phys = range.cpu_addr;
+				hose->isa_mem_size = range.size;
 			}
 
 			/* We get the PCI/Mem offset from the first range or
@@ -199,30 +178,24 @@ void pci_process_bridge_OF_ranges(struct pci_controller *hose,
 			 * hole. If they don't match, bugger.
 			 */
 			if (memno == 0 ||
-			    (isa_hole >= 0 && pci_addr != 0 &&
+			(isa_hole >= 0 && range.pci_addr != 0 &&
 			     hose->pci_mem_offset == isa_mb))
-				hose->pci_mem_offset = cpu_addr - pci_addr;
-			else if (pci_addr != 0 &&
-				 hose->pci_mem_offset != cpu_addr - pci_addr) {
+				hose->pci_mem_offset = range.cpu_addr -
+							range.pci_addr;
+			else if (range.pci_addr != 0 &&
+				hose->pci_mem_offset != range.cpu_addr -
+							range.pci_addr) {
 				pr_info(" \\--> Skipped (offset mismatch) !\n");
 				continue;
 			}
 
 			/* Build resource */
 			res = &hose->mem_resources[memno++];
-			res->flags = IORESOURCE_MEM;
-			if (pci_space & 0x40000000)
-				res->flags |= IORESOURCE_PREFETCH;
-			res->start = cpu_addr;
+
 			break;
 		}
-		if (res != NULL) {
-			res->name = dev->full_name;
-			res->end = res->start + size - 1;
-			res->parent = NULL;
-			res->sibling = NULL;
-			res->child = NULL;
-		}
+		if (res != NULL)
+			of_pci_range_to_resource(&range, dev, res);
 	}
 
 	/* If there's an ISA hole and the pci_mem_offset is -not- matching
diff --git a/include/linux/of_address.h b/include/linux/of_address.h
index 0506eb5..4c2e6f2 100644
--- a/include/linux/of_address.h
+++ b/include/linux/of_address.h
@@ -4,6 +4,36 @@
 #include <linux/errno.h>
 #include <linux/of.h>
 
+struct of_pci_range_parser {
+	struct device_node *node;
+	const __be32 *range;
+	const __be32 *end;
+	int np;
+	int pna;
+};
+
+struct of_pci_range {
+	u32 pci_space;
+	u64 pci_addr;
+	u64 cpu_addr;
+	u64 size;
+	u32 flags;
+};
+
+#define for_each_of_pci_range(parser, range) \
+	for (; of_pci_range_parser_one(parser, range);)
+
+static inline void of_pci_range_to_resource(struct of_pci_range *range,
+					    struct device_node *np,
+					    struct resource *res)
+{
+	res->flags = range->flags;
+	res->start = range->cpu_addr;
+	res->end = range->cpu_addr + range->size - 1;
+	res->parent = res->child = res->sibling = NULL;
+	res->name = np->full_name;
+}
+
 #ifdef CONFIG_OF_ADDRESS
 extern u64 of_translate_address(struct device_node *np, const __be32 *addr);
 extern bool of_can_translate_address(struct device_node *dev);
@@ -27,6 +57,11 @@ static inline unsigned long pci_address_to_pio(phys_addr_t addr) { return -1; }
 #define pci_address_to_pio pci_address_to_pio
 #endif
 
+extern int of_pci_range_parser_init(struct of_pci_range_parser *parser,
+			struct device_node *node);
+extern struct of_pci_range *of_pci_range_parser_one(
+					struct of_pci_range_parser *parser,
+					struct of_pci_range *range);
 #else /* CONFIG_OF_ADDRESS */
 #ifndef of_address_to_resource
 static inline int of_address_to_resource(struct device_node *dev, int index,
@@ -53,6 +88,19 @@ static inline const __be32 *of_get_address(struct device_node *dev, int index,
 {
 	return NULL;
 }
+
+static inline int of_pci_range_parser_init(struct of_pci_range_parser *parser,
+			struct device_node *node)
+{
+	return -1;
+}
+
+static inline struct of_pci_range *of_pci_range_parser_one(
+					struct of_pci_range_parser *parser,
+					struct of_pci_range *range)
+{
+	return NULL;
+}
 #endif /* CONFIG_OF_ADDRESS */
 
 
-- 
1.7.0.4



From Andrew.Murray at arm.com  Mon Apr 22 06:41:32 2013
From: Andrew.Murray at arm.com (Andrew Murray)
Date: Mon, 22 Apr 2013 11:41:32 +0100
Subject: [PATCH v8 0/3] of/pci: Provide common support for PCI DT parsing
Message-ID: <1366627295-16964-1-git-send-email-Andrew.Murray@arm.com>

This patchset factors out duplicated code associated with parsing PCI
DT "ranges" properties across the architectures and introduces a
"ranges" parser. This parser "of_pci_range_parser" can be used directly
by ARM host bridge drivers enabling them to obtain ranges from device
trees.

I've included the Reviewed-by, Tested-by and Acked-by's received from v5/v6/v7
in this patchset, earlier versions of this patchset (v3) have been tested-by:

Thierry Reding <thierry.reding at avionic-design.de>
Jingoo Han <jg1.han at samsung.com>

I've tested that this patchset builds and runs on ARM and that it builds on
PowerPC, x86_64 and MIPS.

Compared to the v7 sent by Andrew Murray, the following changes have been made
(please note that the first patch is unchanged from v7):

 * Rename of_pci_range_parser to of_pci_range_parser_init and
   of_pci_process_ranges to of_pci_range_parser_one as suggested by Grant
   Likely.

 * Reverted back to using a switch statement instead of if/else in
   pci_process_bridge_OF_ranges. Grant Likely highlighted this change from
   the original code which was unnecessary.

 * Squashed in a patch provided by Gabor Juhos which fixes build errors on
   MIPS found in the last patchset.

Compared to the v6 sent by Andrew Murray, the following changes have
been made in response to build errors/warnings:

 * Inclusion of linux/of_address.h in of_pci.c as suggested by Michal
   Simek to prevent compilation failures on Microblaze (and others) and his
   ack.

 * Use of externs, static inlines and a typo in linux/of_address.h in response
   to linker errors (multiple defination) on x86_64 as spotted by a kbuild test
   robot on (jcooper/linux.git mvebu/drivers)

 * Add EXPORT_SYMBOL_GPL to of_pci_range_parser function to be consistent
   with of_pci_process_ranges function

Compared to the v5 sent by Andrew Murray, the following changes have
been made:

 * Use of CONFIG_64BIT instead of CONFIG_[a32bitarch] as suggested by
   Rob Herring in drivers/of/of_pci.c

 * Added forward declaration of struct pci_controller in linux/of_pci.h
   to prevent compiler warning as suggested by Thomas Petazzoni

 * Improved error checking (!range check), removal of unnecessary be32_to_cpup
   call, improved formatting of struct of_pci_range_parser layout and
   replacement of macro with a static inline. All suggested by Rob Herring.

Compared to the v4 (incorrectly labelled v3) sent by Andrew Murray,
the following changes have been made:

 * Split the patch as suggested by Rob Herring

Compared to the v3 sent by Andrew Murray, the following changes have
been made:

 * Unify and move duplicate pci_process_bridge_OF_ranges functions to
   drivers/of/of_pci.c as suggested by Rob Herring

 * Fix potential build errors with Microblaze/MIPS

Compared to "[PATCH v5 01/17] of/pci: Provide support for parsing PCI DT
ranges property", the following changes have been made:

 * Correct use of IORESOURCE_* as suggested by Russell King

 * Improved interface and naming as suggested by Thierry Reding

Compared to the v2 sent by Andrew Murray, Thomas Petazzoni did:

 * Add a memset() on the struct of_pci_range_iter when starting the
   for loop in for_each_pci_range(). Otherwise, with an uninitialized
   of_pci_range_iter, of_pci_process_ranges() may crash.

 * Add parenthesis around 'res', 'np' and 'iter' in the
   for_each_of_pci_range macro definitions. Otherwise, passing
   something like &foobar as 'res' didn't work.

 * Rebased on top of 3.9-rc2, which required fixing a few conflicts in
   the Microblaze code.

v2:
  This follows on from suggestions made by Grant Likely
  (marc.info/?l=linux-kernel&m=136079602806328)

Andrew Murray (3):
  of/pci: Unify pci_process_bridge_OF_ranges from Microblaze and
    PowerPC
  of/pci: Provide support for parsing PCI DT ranges property
  of/pci: mips: convert to common of_pci_range_parser

 arch/microblaze/include/asm/pci-bridge.h |    5 +-
 arch/microblaze/pci/pci-common.c         |  192 ------------------------------
 arch/mips/pci/pci.c                      |   51 +++-----
 arch/powerpc/include/asm/pci-bridge.h    |    5 +-
 arch/powerpc/kernel/pci-common.c         |  192 ------------------------------
 drivers/of/address.c                     |   67 +++++++++++
 drivers/of/of_pci.c                      |  173 +++++++++++++++++++++++++++
 include/linux/of_address.h               |   48 ++++++++
 include/linux/of_pci.h                   |    4 +
 9 files changed, 313 insertions(+), 424 deletions(-)



From Andrew.Murray at arm.com  Mon Apr 22 06:41:33 2013
From: Andrew.Murray at arm.com (Andrew Murray)
Date: Mon, 22 Apr 2013 11:41:33 +0100
Subject: [PATCH v8 1/3] of/pci: Unify pci_process_bridge_OF_ranges from
 Microblaze and PowerPC
In-Reply-To: <1366627295-16964-1-git-send-email-Andrew.Murray@arm.com>
References: <1366627295-16964-1-git-send-email-Andrew.Murray@arm.com>
Message-ID: <1366627295-16964-2-git-send-email-Andrew.Murray@arm.com>

The pci_process_bridge_OF_ranges function, used to parse the "ranges"
property of a PCI host device, is found in both Microblaze and PowerPC
architectures. These implementations are nearly identical. This patch
moves this common code to a common place.

Signed-off-by: Andrew Murray <Andrew.Murray at arm.com>
Signed-off-by: Liviu Dudau <Liviu.Dudau at arm.com>
Reviewed-by: Rob Herring <rob.herring at calxeda.com>
Tested-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Tested-by: Linus Walleij <linus.walleij at linaro.org>
Acked-by: Michal Simek <monstr at monstr.eu>
Acked-by: Grant Likely <grant.likely at linaro.org>
---
 arch/microblaze/include/asm/pci-bridge.h |    5 +-
 arch/microblaze/pci/pci-common.c         |  192 ----------------------------
 arch/powerpc/include/asm/pci-bridge.h    |    5 +-
 arch/powerpc/kernel/pci-common.c         |  192 ----------------------------
 drivers/of/of_pci.c                      |  200 ++++++++++++++++++++++++++++++
 include/linux/of_pci.h                   |    4 +
 6 files changed, 206 insertions(+), 392 deletions(-)

diff --git a/arch/microblaze/include/asm/pci-bridge.h b/arch/microblaze/include/asm/pci-bridge.h
index cb5d397..5783cd6 100644
--- a/arch/microblaze/include/asm/pci-bridge.h
+++ b/arch/microblaze/include/asm/pci-bridge.h
@@ -10,6 +10,7 @@
 #include <linux/pci.h>
 #include <linux/list.h>
 #include <linux/ioport.h>
+#include <linux/of_pci.h>
 
 struct device_node;
 
@@ -132,10 +133,6 @@ extern void setup_indirect_pci(struct pci_controller *hose,
 extern struct pci_controller *pci_find_hose_for_OF_device(
 			struct device_node *node);
 
-/* Fill up host controller resources from the OF node */
-extern void pci_process_bridge_OF_ranges(struct pci_controller *hose,
-			struct device_node *dev, int primary);
-
 /* Allocate & free a PCI host bridge structure */
 extern struct pci_controller *pcibios_alloc_controller(struct device_node *dev);
 extern void pcibios_free_controller(struct pci_controller *phb);
diff --git a/arch/microblaze/pci/pci-common.c b/arch/microblaze/pci/pci-common.c
index 9ea521e..2735ad9 100644
--- a/arch/microblaze/pci/pci-common.c
+++ b/arch/microblaze/pci/pci-common.c
@@ -622,198 +622,6 @@ void pci_resource_to_user(const struct pci_dev *dev, int bar,
 	*end = rsrc->end - offset;
 }
 
-/**
- * pci_process_bridge_OF_ranges - Parse PCI bridge resources from device tree
- * @hose: newly allocated pci_controller to be setup
- * @dev: device node of the host bridge
- * @primary: set if primary bus (32 bits only, soon to be deprecated)
- *
- * This function will parse the "ranges" property of a PCI host bridge device
- * node and setup the resource mapping of a pci controller based on its
- * content.
- *
- * Life would be boring if it wasn't for a few issues that we have to deal
- * with here:
- *
- *   - We can only cope with one IO space range and up to 3 Memory space
- *     ranges. However, some machines (thanks Apple !) tend to split their
- *     space into lots of small contiguous ranges. So we have to coalesce.
- *
- *   - We can only cope with all memory ranges having the same offset
- *     between CPU addresses and PCI addresses. Unfortunately, some bridges
- *     are setup for a large 1:1 mapping along with a small "window" which
- *     maps PCI address 0 to some arbitrary high address of the CPU space in
- *     order to give access to the ISA memory hole.
- *     The way out of here that I've chosen for now is to always set the
- *     offset based on the first resource found, then override it if we
- *     have a different offset and the previous was set by an ISA hole.
- *
- *   - Some busses have IO space not starting at 0, which causes trouble with
- *     the way we do our IO resource renumbering. The code somewhat deals with
- *     it for 64 bits but I would expect problems on 32 bits.
- *
- *   - Some 32 bits platforms such as 4xx can have physical space larger than
- *     32 bits so we need to use 64 bits values for the parsing
- */
-void pci_process_bridge_OF_ranges(struct pci_controller *hose,
-				  struct device_node *dev, int primary)
-{
-	const u32 *ranges;
-	int rlen;
-	int pna = of_n_addr_cells(dev);
-	int np = pna + 5;
-	int memno = 0, isa_hole = -1;
-	u32 pci_space;
-	unsigned long long pci_addr, cpu_addr, pci_next, cpu_next, size;
-	unsigned long long isa_mb = 0;
-	struct resource *res;
-
-	pr_info("PCI host bridge %s %s ranges:\n",
-	       dev->full_name, primary ? "(primary)" : "");
-
-	/* Get ranges property */
-	ranges = of_get_property(dev, "ranges", &rlen);
-	if (ranges == NULL)
-		return;
-
-	/* Parse it */
-	pr_debug("Parsing ranges property...\n");
-	while ((rlen -= np * 4) >= 0) {
-		/* Read next ranges element */
-		pci_space = ranges[0];
-		pci_addr = of_read_number(ranges + 1, 2);
-		cpu_addr = of_translate_address(dev, ranges + 3);
-		size = of_read_number(ranges + pna + 3, 2);
-
-		pr_debug("pci_space: 0x%08x pci_addr:0x%016llx ",
-				pci_space, pci_addr);
-		pr_debug("cpu_addr:0x%016llx size:0x%016llx\n",
-					cpu_addr, size);
-
-		ranges += np;
-
-		/* If we failed translation or got a zero-sized region
-		 * (some FW try to feed us with non sensical zero sized regions
-		 * such as power3 which look like some kind of attempt
-		 * at exposing the VGA memory hole)
-		 */
-		if (cpu_addr == OF_BAD_ADDR || size == 0)
-			continue;
-
-		/* Now consume following elements while they are contiguous */
-		for (; rlen >= np * sizeof(u32);
-		     ranges += np, rlen -= np * 4) {
-			if (ranges[0] != pci_space)
-				break;
-			pci_next = of_read_number(ranges + 1, 2);
-			cpu_next = of_translate_address(dev, ranges + 3);
-			if (pci_next != pci_addr + size ||
-			    cpu_next != cpu_addr + size)
-				break;
-			size += of_read_number(ranges + pna + 3, 2);
-		}
-
-		/* Act based on address space type */
-		res = NULL;
-		switch ((pci_space >> 24) & 0x3) {
-		case 1:		/* PCI IO space */
-			pr_info("  IO 0x%016llx..0x%016llx -> 0x%016llx\n",
-			       cpu_addr, cpu_addr + size - 1, pci_addr);
-
-			/* We support only one IO range */
-			if (hose->pci_io_size) {
-				pr_info(" \\--> Skipped (too many) !\n");
-				continue;
-			}
-			/* On 32 bits, limit I/O space to 16MB */
-			if (size > 0x01000000)
-				size = 0x01000000;
-
-			/* 32 bits needs to map IOs here */
-			hose->io_base_virt = ioremap(cpu_addr, size);
-
-			/* Expect trouble if pci_addr is not 0 */
-			if (primary)
-				isa_io_base =
-					(unsigned long)hose->io_base_virt;
-			/* pci_io_size and io_base_phys always represent IO
-			 * space starting at 0 so we factor in pci_addr
-			 */
-			hose->pci_io_size = pci_addr + size;
-			hose->io_base_phys = cpu_addr - pci_addr;
-
-			/* Build resource */
-			res = &hose->io_resource;
-			res->flags = IORESOURCE_IO;
-			res->start = pci_addr;
-			break;
-		case 2:		/* PCI Memory space */
-		case 3:		/* PCI 64 bits Memory space */
-			pr_info(" MEM 0x%016llx..0x%016llx -> 0x%016llx %s\n",
-			       cpu_addr, cpu_addr + size - 1, pci_addr,
-			       (pci_space & 0x40000000) ? "Prefetch" : "");
-
-			/* We support only 3 memory ranges */
-			if (memno >= 3) {
-				pr_info(" \\--> Skipped (too many) !\n");
-				continue;
-			}
-			/* Handles ISA memory hole space here */
-			if (pci_addr == 0) {
-				isa_mb = cpu_addr;
-				isa_hole = memno;
-				if (primary || isa_mem_base == 0)
-					isa_mem_base = cpu_addr;
-				hose->isa_mem_phys = cpu_addr;
-				hose->isa_mem_size = size;
-			}
-
-			/* We get the PCI/Mem offset from the first range or
-			 * the, current one if the offset came from an ISA
-			 * hole. If they don't match, bugger.
-			 */
-			if (memno == 0 ||
-			    (isa_hole >= 0 && pci_addr != 0 &&
-			     hose->pci_mem_offset == isa_mb))
-				hose->pci_mem_offset = cpu_addr - pci_addr;
-			else if (pci_addr != 0 &&
-				 hose->pci_mem_offset != cpu_addr - pci_addr) {
-				pr_info(" \\--> Skipped (offset mismatch) !\n");
-				continue;
-			}
-
-			/* Build resource */
-			res = &hose->mem_resources[memno++];
-			res->flags = IORESOURCE_MEM;
-			if (pci_space & 0x40000000)
-				res->flags |= IORESOURCE_PREFETCH;
-			res->start = cpu_addr;
-			break;
-		}
-		if (res != NULL) {
-			res->name = dev->full_name;
-			res->end = res->start + size - 1;
-			res->parent = NULL;
-			res->sibling = NULL;
-			res->child = NULL;
-		}
-	}
-
-	/* If there's an ISA hole and the pci_mem_offset is -not- matching
-	 * the ISA hole offset, then we need to remove the ISA hole from
-	 * the resource list for that brige
-	 */
-	if (isa_hole >= 0 && hose->pci_mem_offset != isa_mb) {
-		unsigned int next = isa_hole + 1;
-		pr_info(" Removing ISA hole at 0x%016llx\n", isa_mb);
-		if (next < memno)
-			memmove(&hose->mem_resources[isa_hole],
-				&hose->mem_resources[next],
-				sizeof(struct resource) * (memno - next));
-		hose->mem_resources[--memno].flags = 0;
-	}
-}
-
 /* Decide whether to display the domain number in /proc */
 int pci_proc_domain(struct pci_bus *bus)
 {
diff --git a/arch/powerpc/include/asm/pci-bridge.h b/arch/powerpc/include/asm/pci-bridge.h
index 025a130..205bfba 100644
--- a/arch/powerpc/include/asm/pci-bridge.h
+++ b/arch/powerpc/include/asm/pci-bridge.h
@@ -10,6 +10,7 @@
 #include <linux/pci.h>
 #include <linux/list.h>
 #include <linux/ioport.h>
+#include <linux/of_pci.h>
 #include <asm-generic/pci-bridge.h>
 
 struct device_node;
@@ -231,10 +232,6 @@ extern int pcibios_map_io_space(struct pci_bus *bus);
 extern struct pci_controller *pci_find_hose_for_OF_device(
 			struct device_node* node);
 
-/* Fill up host controller resources from the OF node */
-extern void pci_process_bridge_OF_ranges(struct pci_controller *hose,
-			struct device_node *dev, int primary);
-
 /* Allocate & free a PCI host bridge structure */
 extern struct pci_controller *pcibios_alloc_controller(struct device_node *dev);
 extern void pcibios_free_controller(struct pci_controller *phb);
diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index fa12ae4..6edf396 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -640,198 +640,6 @@ void pci_resource_to_user(const struct pci_dev *dev, int bar,
 	*end = rsrc->end - offset;
 }
 
-/**
- * pci_process_bridge_OF_ranges - Parse PCI bridge resources from device tree
- * @hose: newly allocated pci_controller to be setup
- * @dev: device node of the host bridge
- * @primary: set if primary bus (32 bits only, soon to be deprecated)
- *
- * This function will parse the "ranges" property of a PCI host bridge device
- * node and setup the resource mapping of a pci controller based on its
- * content.
- *
- * Life would be boring if it wasn't for a few issues that we have to deal
- * with here:
- *
- *   - We can only cope with one IO space range and up to 3 Memory space
- *     ranges. However, some machines (thanks Apple !) tend to split their
- *     space into lots of small contiguous ranges. So we have to coalesce.
- *
- *   - We can only cope with all memory ranges having the same offset
- *     between CPU addresses and PCI addresses. Unfortunately, some bridges
- *     are setup for a large 1:1 mapping along with a small "window" which
- *     maps PCI address 0 to some arbitrary high address of the CPU space in
- *     order to give access to the ISA memory hole.
- *     The way out of here that I've chosen for now is to always set the
- *     offset based on the first resource found, then override it if we
- *     have a different offset and the previous was set by an ISA hole.
- *
- *   - Some busses have IO space not starting at 0, which causes trouble with
- *     the way we do our IO resource renumbering. The code somewhat deals with
- *     it for 64 bits but I would expect problems on 32 bits.
- *
- *   - Some 32 bits platforms such as 4xx can have physical space larger than
- *     32 bits so we need to use 64 bits values for the parsing
- */
-void pci_process_bridge_OF_ranges(struct pci_controller *hose,
-				  struct device_node *dev, int primary)
-{
-	const u32 *ranges;
-	int rlen;
-	int pna = of_n_addr_cells(dev);
-	int np = pna + 5;
-	int memno = 0, isa_hole = -1;
-	u32 pci_space;
-	unsigned long long pci_addr, cpu_addr, pci_next, cpu_next, size;
-	unsigned long long isa_mb = 0;
-	struct resource *res;
-
-	printk(KERN_INFO "PCI host bridge %s %s ranges:\n",
-	       dev->full_name, primary ? "(primary)" : "");
-
-	/* Get ranges property */
-	ranges = of_get_property(dev, "ranges", &rlen);
-	if (ranges == NULL)
-		return;
-
-	/* Parse it */
-	while ((rlen -= np * 4) >= 0) {
-		/* Read next ranges element */
-		pci_space = ranges[0];
-		pci_addr = of_read_number(ranges + 1, 2);
-		cpu_addr = of_translate_address(dev, ranges + 3);
-		size = of_read_number(ranges + pna + 3, 2);
-		ranges += np;
-
-		/* If we failed translation or got a zero-sized region
-		 * (some FW try to feed us with non sensical zero sized regions
-		 * such as power3 which look like some kind of attempt at exposing
-		 * the VGA memory hole)
-		 */
-		if (cpu_addr == OF_BAD_ADDR || size == 0)
-			continue;
-
-		/* Now consume following elements while they are contiguous */
-		for (; rlen >= np * sizeof(u32);
-		     ranges += np, rlen -= np * 4) {
-			if (ranges[0] != pci_space)
-				break;
-			pci_next = of_read_number(ranges + 1, 2);
-			cpu_next = of_translate_address(dev, ranges + 3);
-			if (pci_next != pci_addr + size ||
-			    cpu_next != cpu_addr + size)
-				break;
-			size += of_read_number(ranges + pna + 3, 2);
-		}
-
-		/* Act based on address space type */
-		res = NULL;
-		switch ((pci_space >> 24) & 0x3) {
-		case 1:		/* PCI IO space */
-			printk(KERN_INFO
-			       "  IO 0x%016llx..0x%016llx -> 0x%016llx\n",
-			       cpu_addr, cpu_addr + size - 1, pci_addr);
-
-			/* We support only one IO range */
-			if (hose->pci_io_size) {
-				printk(KERN_INFO
-				       " \\--> Skipped (too many) !\n");
-				continue;
-			}
-#ifdef CONFIG_PPC32
-			/* On 32 bits, limit I/O space to 16MB */
-			if (size > 0x01000000)
-				size = 0x01000000;
-
-			/* 32 bits needs to map IOs here */
-			hose->io_base_virt = ioremap(cpu_addr, size);
-
-			/* Expect trouble if pci_addr is not 0 */
-			if (primary)
-				isa_io_base =
-					(unsigned long)hose->io_base_virt;
-#endif /* CONFIG_PPC32 */
-			/* pci_io_size and io_base_phys always represent IO
-			 * space starting at 0 so we factor in pci_addr
-			 */
-			hose->pci_io_size = pci_addr + size;
-			hose->io_base_phys = cpu_addr - pci_addr;
-
-			/* Build resource */
-			res = &hose->io_resource;
-			res->flags = IORESOURCE_IO;
-			res->start = pci_addr;
-			break;
-		case 2:		/* PCI Memory space */
-		case 3:		/* PCI 64 bits Memory space */
-			printk(KERN_INFO
-			       " MEM 0x%016llx..0x%016llx -> 0x%016llx %s\n",
-			       cpu_addr, cpu_addr + size - 1, pci_addr,
-			       (pci_space & 0x40000000) ? "Prefetch" : "");
-
-			/* We support only 3 memory ranges */
-			if (memno >= 3) {
-				printk(KERN_INFO
-				       " \\--> Skipped (too many) !\n");
-				continue;
-			}
-			/* Handles ISA memory hole space here */
-			if (pci_addr == 0) {
-				isa_mb = cpu_addr;
-				isa_hole = memno;
-				if (primary || isa_mem_base == 0)
-					isa_mem_base = cpu_addr;
-				hose->isa_mem_phys = cpu_addr;
-				hose->isa_mem_size = size;
-			}
-
-			/* We get the PCI/Mem offset from the first range or
-			 * the, current one if the offset came from an ISA
-			 * hole. If they don't match, bugger.
-			 */
-			if (memno == 0 ||
-			    (isa_hole >= 0 && pci_addr != 0 &&
-			     hose->pci_mem_offset == isa_mb))
-				hose->pci_mem_offset = cpu_addr - pci_addr;
-			else if (pci_addr != 0 &&
-				 hose->pci_mem_offset != cpu_addr - pci_addr) {
-				printk(KERN_INFO
-				       " \\--> Skipped (offset mismatch) !\n");
-				continue;
-			}
-
-			/* Build resource */
-			res = &hose->mem_resources[memno++];
-			res->flags = IORESOURCE_MEM;
-			if (pci_space & 0x40000000)
-				res->flags |= IORESOURCE_PREFETCH;
-			res->start = cpu_addr;
-			break;
-		}
-		if (res != NULL) {
-			res->name = dev->full_name;
-			res->end = res->start + size - 1;
-			res->parent = NULL;
-			res->sibling = NULL;
-			res->child = NULL;
-		}
-	}
-
-	/* If there's an ISA hole and the pci_mem_offset is -not- matching
-	 * the ISA hole offset, then we need to remove the ISA hole from
-	 * the resource list for that brige
-	 */
-	if (isa_hole >= 0 && hose->pci_mem_offset != isa_mb) {
-		unsigned int next = isa_hole + 1;
-		printk(KERN_INFO " Removing ISA hole at 0x%016llx\n", isa_mb);
-		if (next < memno)
-			memmove(&hose->mem_resources[isa_hole],
-				&hose->mem_resources[next],
-				sizeof(struct resource) * (memno - next));
-		hose->mem_resources[--memno].flags = 0;
-	}
-}
-
 /* Decide whether to display the domain number in /proc */
 int pci_proc_domain(struct pci_bus *bus)
 {
diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
index 13e37e2..1626172 100644
--- a/drivers/of/of_pci.c
+++ b/drivers/of/of_pci.c
@@ -4,6 +4,10 @@
 #include <linux/of_pci.h>
 #include <asm/prom.h>
 
+#if defined(CONFIG_PPC32) || defined(CONFIG_PPC64) || defined(CONFIG_MICROBLAZE)
+#include <asm/pci-bridge.h>
+#endif
+
 static inline int __of_pci_pci_compare(struct device_node *node,
 				       unsigned int devfn)
 {
@@ -40,3 +44,199 @@ struct device_node *of_pci_find_child_device(struct device_node *parent,
 	return NULL;
 }
 EXPORT_SYMBOL_GPL(of_pci_find_child_device);
+
+/**
+ * pci_process_bridge_OF_ranges - Parse PCI bridge resources from device tree
+ * @hose: newly allocated pci_controller to be setup
+ * @dev: device node of the host bridge
+ * @primary: set if primary bus (32 bits only, soon to be deprecated)
+ *
+ * This function will parse the "ranges" property of a PCI host bridge device
+ * node and setup the resource mapping of a pci controller based on its
+ * content.
+ *
+ * Life would be boring if it wasn't for a few issues that we have to deal
+ * with here:
+ *
+ *   - We can only cope with one IO space range and up to 3 Memory space
+ *     ranges. However, some machines (thanks Apple !) tend to split their
+ *     space into lots of small contiguous ranges. So we have to coalesce.
+ *
+ *   - We can only cope with all memory ranges having the same offset
+ *     between CPU addresses and PCI addresses. Unfortunately, some bridges
+ *     are setup for a large 1:1 mapping along with a small "window" which
+ *     maps PCI address 0 to some arbitrary high address of the CPU space in
+ *     order to give access to the ISA memory hole.
+ *     The way out of here that I've chosen for now is to always set the
+ *     offset based on the first resource found, then override it if we
+ *     have a different offset and the previous was set by an ISA hole.
+ *
+ *   - Some busses have IO space not starting at 0, which causes trouble with
+ *     the way we do our IO resource renumbering. The code somewhat deals with
+ *     it for 64 bits but I would expect problems on 32 bits.
+ *
+ *   - Some 32 bits platforms such as 4xx can have physical space larger than
+ *     32 bits so we need to use 64 bits values for the parsing
+ */
+#if defined(CONFIG_PPC32) || defined(CONFIG_PPC64) || defined(CONFIG_MICROBLAZE)
+void pci_process_bridge_OF_ranges(struct pci_controller *hose,
+				  struct device_node *dev, int primary)
+{
+	const u32 *ranges;
+	int rlen;
+	int pna = of_n_addr_cells(dev);
+	int np = pna + 5;
+	int memno = 0, isa_hole = -1;
+	u32 pci_space;
+	unsigned long long pci_addr, cpu_addr, pci_next, cpu_next, size;
+	unsigned long long isa_mb = 0;
+	struct resource *res;
+
+	pr_info("PCI host bridge %s %s ranges:\n",
+	       dev->full_name, primary ? "(primary)" : "");
+
+	/* Get ranges property */
+	ranges = of_get_property(dev, "ranges", &rlen);
+	if (ranges == NULL)
+		return;
+
+	/* Parse it */
+	pr_debug("Parsing ranges property...\n");
+	while ((rlen -= np * 4) >= 0) {
+		/* Read next ranges element */
+		pci_space = ranges[0];
+		pci_addr = of_read_number(ranges + 1, 2);
+		cpu_addr = of_translate_address(dev, ranges + 3);
+		size = of_read_number(ranges + pna + 3, 2);
+
+		pr_debug("pci_space: 0x%08x pci_addr:0x%016llx ",
+				pci_space, pci_addr);
+		pr_debug("cpu_addr:0x%016llx size:0x%016llx\n",
+					cpu_addr, size);
+
+		ranges += np;
+
+		/* If we failed translation or got a zero-sized region
+		 * (some FW try to feed us with non sensical zero sized regions
+		 * such as power3 which look like some kind of attempt
+		 * at exposing the VGA memory hole)
+		 */
+		if (cpu_addr == OF_BAD_ADDR || size == 0)
+			continue;
+
+		/* Now consume following elements while they are contiguous */
+		for (; rlen >= np * sizeof(u32);
+		     ranges += np, rlen -= np * 4) {
+			if (ranges[0] != pci_space)
+				break;
+			pci_next = of_read_number(ranges + 1, 2);
+			cpu_next = of_translate_address(dev, ranges + 3);
+			if (pci_next != pci_addr + size ||
+			    cpu_next != cpu_addr + size)
+				break;
+			size += of_read_number(ranges + pna + 3, 2);
+		}
+
+		/* Act based on address space type */
+		res = NULL;
+		switch ((pci_space >> 24) & 0x3) {
+		case 1:		/* PCI IO space */
+			pr_info("  IO 0x%016llx..0x%016llx -> 0x%016llx\n",
+			       cpu_addr, cpu_addr + size - 1, pci_addr);
+
+			/* We support only one IO range */
+			if (hose->pci_io_size) {
+				pr_info(" \\--> Skipped (too many) !\n");
+				continue;
+			}
+#if (!IS_ENABLED(CONFIG_64BIT))
+			/* On 32 bits, limit I/O space to 16MB */
+			if (size > 0x01000000)
+				size = 0x01000000;
+
+			/* 32 bits needs to map IOs here */
+			hose->io_base_virt = ioremap(cpu_addr, size);
+
+			/* Expect trouble if pci_addr is not 0 */
+			if (primary)
+				isa_io_base =
+					(unsigned long)hose->io_base_virt;
+#endif /* !CONFIG_64BIT */
+			/* pci_io_size and io_base_phys always represent IO
+			 * space starting at 0 so we factor in pci_addr
+			 */
+			hose->pci_io_size = pci_addr + size;
+			hose->io_base_phys = cpu_addr - pci_addr;
+
+			/* Build resource */
+			res = &hose->io_resource;
+			res->flags = IORESOURCE_IO;
+			res->start = pci_addr;
+			break;
+		case 2:		/* PCI Memory space */
+		case 3:		/* PCI 64 bits Memory space */
+			pr_info(" MEM 0x%016llx..0x%016llx -> 0x%016llx %s\n",
+			       cpu_addr, cpu_addr + size - 1, pci_addr,
+			       (pci_space & 0x40000000) ? "Prefetch" : "");
+
+			/* We support only 3 memory ranges */
+			if (memno >= 3) {
+				pr_info(" \\--> Skipped (too many) !\n");
+				continue;
+			}
+			/* Handles ISA memory hole space here */
+			if (pci_addr == 0) {
+				isa_mb = cpu_addr;
+				isa_hole = memno;
+				if (primary || isa_mem_base == 0)
+					isa_mem_base = cpu_addr;
+				hose->isa_mem_phys = cpu_addr;
+				hose->isa_mem_size = size;
+			}
+
+			/* We get the PCI/Mem offset from the first range or
+			 * the, current one if the offset came from an ISA
+			 * hole. If they don't match, bugger.
+			 */
+			if (memno == 0 ||
+			    (isa_hole >= 0 && pci_addr != 0 &&
+			     hose->pci_mem_offset == isa_mb))
+				hose->pci_mem_offset = cpu_addr - pci_addr;
+			else if (pci_addr != 0 &&
+				 hose->pci_mem_offset != cpu_addr - pci_addr) {
+				pr_info(" \\--> Skipped (offset mismatch) !\n");
+				continue;
+			}
+
+			/* Build resource */
+			res = &hose->mem_resources[memno++];
+			res->flags = IORESOURCE_MEM;
+			if (pci_space & 0x40000000)
+				res->flags |= IORESOURCE_PREFETCH;
+			res->start = cpu_addr;
+			break;
+		}
+		if (res != NULL) {
+			res->name = dev->full_name;
+			res->end = res->start + size - 1;
+			res->parent = NULL;
+			res->sibling = NULL;
+			res->child = NULL;
+		}
+	}
+
+	/* If there's an ISA hole and the pci_mem_offset is -not- matching
+	 * the ISA hole offset, then we need to remove the ISA hole from
+	 * the resource list for that brige
+	 */
+	if (isa_hole >= 0 && hose->pci_mem_offset != isa_mb) {
+		unsigned int next = isa_hole + 1;
+		pr_info(" Removing ISA hole at 0x%016llx\n", isa_mb);
+		if (next < memno)
+			memmove(&hose->mem_resources[isa_hole],
+				&hose->mem_resources[next],
+				sizeof(struct resource) * (memno - next));
+		hose->mem_resources[--memno].flags = 0;
+	}
+}
+#endif
diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
index bb115de..33e8ead 100644
--- a/include/linux/of_pci.h
+++ b/include/linux/of_pci.h
@@ -11,4 +11,8 @@ struct device_node;
 struct device_node *of_pci_find_child_device(struct device_node *parent,
 					     unsigned int devfn);
 
+struct pci_controller;
+void pci_process_bridge_OF_ranges(struct pci_controller *hose,
+			struct device_node *dev, int primary);
+
 #endif
-- 
1.7.0.4



From vinod.koul at intel.com  Mon Apr 22 06:13:32 2013
From: vinod.koul at intel.com (Vinod Koul)
Date: Mon, 22 Apr 2013 15:43:32 +0530
Subject: [PATCH 03/32 v2] dmaengine: ste_dma40: Use the BIT macro to
 replace ugly '(1 << x)'s
In-Reply-To: <20130418121637.GG27903@gmail.com>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-4-git-send-email-lee.jones@linaro.org>
 <20130418121637.GG27903@gmail.com>
Message-ID: <20130422101332.GQ24632@intel.com>

On Thu, Apr 18, 2013 at 01:16:37PM +0100, Lee Jones wrote:
> The aim is to make the code that little more readable.
> 
> Cc: Vinod Koul <vinod.koul at intel.com>
> Cc: Dan Williams <djbw at fb.com>
> Cc: Per Forlin <per.forlin at stericsson.com>
> Cc: Rabin Vincent <rabin at rab.in>
> Acked-by: Arnd Bergmann <arnd at arndb.de>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>
Acked-by: Vinod Koul <vinod.koul at intel.com>

--
~Vinod
> 
> diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
> index 3b83dee..ddf5ff1 100644
> --- a/drivers/dma/ste_dma40.c
> +++ b/drivers/dma/ste_dma40.c
> @@ -49,9 +49,9 @@
>  #define MAX_LCLA_ALLOC_ATTEMPTS 256
>  
>  /* Bit markings for allocation map */
> -#define D40_ALLOC_FREE		(1 << 31)
> -#define D40_ALLOC_PHY		(1 << 30)
> -#define D40_ALLOC_LOG_FREE	0
> +#define D40_ALLOC_FREE		BIT(31)
> +#define D40_ALLOC_PHY		BIT(30)
> +#define D40_ALLOC_LOG_FREE	BIT(0)
>  
>  #define MAX(a, b) (((a) < (b)) ? (b) : (a))
>  
> @@ -993,12 +993,12 @@ static int d40_size_2_dmalen(int size, u32 data_width1, u32 data_width2)
>  	int dmalen;
>  	u32 max_w = max(data_width1, data_width2);
>  	u32 min_w = min(data_width1, data_width2);
> -	u32 seg_max = ALIGN(STEDMA40_MAX_SEG_SIZE << min_w, 1 << max_w);
> +	u32 seg_max = ALIGN(STEDMA40_MAX_SEG_SIZE << min_w, BIT(max_w));
>  
>  	if (seg_max > STEDMA40_MAX_SEG_SIZE)
> -		seg_max -= (1 << max_w);
> +		seg_max -= BIT(max_w);
>  
> -	if (!IS_ALIGNED(size, 1 << max_w))
> +	if (!IS_ALIGNED(size, BIT(max_w)))
>  		return -EINVAL;
>  
>  	if (size <= seg_max)
> @@ -1448,7 +1448,7 @@ static u32 d40_residue(struct d40_chan *d40c)
>  			  >> D40_SREG_ELEM_PHY_ECNT_POS;
>  	}
>  
> -	return num_elt * (1 << d40c->dma_cfg.dst_info.data_width);
> +	return num_elt << d40c->dma_cfg.dst_info.data_width;
>  }
>  
>  static bool d40_tx_is_linked(struct d40_chan *d40c)
> @@ -1722,7 +1722,7 @@ static irqreturn_t d40_handle_interrupt(int irq, void *data)
>  		}
>  
>  		/* ACK interrupt */
> -		writel(1 << idx, base->virtbase + il[row].clr);
> +		writel(BIT(idx), base->virtbase + il[row].clr);
>  
>  		spin_lock(&d40c->lock);
>  
> @@ -1804,9 +1804,9 @@ static int d40_validate_conf(struct d40_chan *d40c,
>  	}
>  
>  	if (d40_psize_2_burst_size(is_log, conf->src_info.psize) *
> -	    (1 << conf->src_info.data_width) !=
> +	    BIT(conf->src_info.data_width) !=
>  	    d40_psize_2_burst_size(is_log, conf->dst_info.psize) *
> -	    (1 << conf->dst_info.data_width)) {
> +	    BIT(conf->dst_info.data_width)) {
>  		/*
>  		 * The DMAC hardware only supports
>  		 * src (burst x width) == dst (burst x width)
> @@ -1848,8 +1848,8 @@ static bool d40_alloc_mask_set(struct d40_phy_res *phy,
>  		if (phy->allocated_src == D40_ALLOC_FREE)
>  			phy->allocated_src = D40_ALLOC_LOG_FREE;
>  
> -		if (!(phy->allocated_src & (1 << log_event_line))) {
> -			phy->allocated_src |= 1 << log_event_line;
> +		if (!(phy->allocated_src & BIT(log_event_line))) {
> +			phy->allocated_src |= BIT(log_event_line);
>  			goto found;
>  		} else
>  			goto not_found;
> @@ -1860,8 +1860,8 @@ static bool d40_alloc_mask_set(struct d40_phy_res *phy,
>  		if (phy->allocated_dst == D40_ALLOC_FREE)
>  			phy->allocated_dst = D40_ALLOC_LOG_FREE;
>  
> -		if (!(phy->allocated_dst & (1 << log_event_line))) {
> -			phy->allocated_dst |= 1 << log_event_line;
> +		if (!(phy->allocated_dst & BIT(log_event_line))) {
> +			phy->allocated_dst |= BIT(log_event_line);
>  			goto found;
>  		} else
>  			goto not_found;
> @@ -1891,11 +1891,11 @@ static bool d40_alloc_mask_free(struct d40_phy_res *phy, bool is_src,
>  
>  	/* Logical channel */
>  	if (is_src) {
> -		phy->allocated_src &= ~(1 << log_event_line);
> +		phy->allocated_src &= ~BIT(log_event_line);
>  		if (phy->allocated_src == D40_ALLOC_LOG_FREE)
>  			phy->allocated_src = D40_ALLOC_FREE;
>  	} else {
> -		phy->allocated_dst &= ~(1 << log_event_line);
> +		phy->allocated_dst &= ~BIT(log_event_line);
>  		if (phy->allocated_dst == D40_ALLOC_LOG_FREE)
>  			phy->allocated_dst = D40_ALLOC_FREE;
>  	}
> @@ -2394,7 +2394,7 @@ static void __d40_set_prio_rt(struct d40_chan *d40c, int dev_type, bool src)
>  	u32 rtreg;
>  	u32 event = D40_TYPE_TO_EVENT(dev_type);
>  	u32 group = D40_TYPE_TO_GROUP(dev_type);
> -	u32 bit = 1 << event;
> +	u32 bit = BIT(event);
>  	u32 prioreg;
>  	struct d40_gen_dmac *dmac = &d40c->base->gen_dmac;


From will.deacon at arm.com  Mon Apr 22 06:46:54 2013
From: will.deacon at arm.com (Will Deacon)
Date: Mon, 22 Apr 2013 11:46:54 +0100
Subject: arm: ARM_VIRT_EXT is not supported by all v7 platforms, so it
 should not be enabled by default
In-Reply-To: <kks14c$e4p$1@ger.gmane.org>
References: <kks14c$e4p$1@ger.gmane.org>
Message-ID: <20130422104653.GA2572@mudshark.cambridge.arm.com>

On Fri, Apr 19, 2013 at 07:07:15PM +0100, Sebastian Gottschall wrote:
> introduced in kernel 3.9 CONFIG_ARM_VIRT_EXT is default for all V7 arm 
> cpu's. this is wrong and breaks smp support on BCM4708 for example.
> so keep it optional since no all v7 cpu's seem to support it. BCM4708 
> for instance is a arm cortex-a9. please merge this into one of the next 
> patches.

This was intentional, since ARM_VIRT_EXT shouldn't have any visible effect
when selected on CPUs without the virtualisation extensions.

If this is breaking SMP support, then there is a bug somewhere, so please
can elaborate on the problems which you are seeing?

Cheers,

Will


From vinod.koul at intel.com  Mon Apr 22 06:16:06 2013
From: vinod.koul at intel.com (Vinod Koul)
Date: Mon, 22 Apr 2013 15:46:06 +0530
Subject: [PATCH 24/32] dmaengine: ste_dma40: Supply full Device Tree
 parsing support
In-Reply-To: <1366279934-30761-25-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-25-git-send-email-lee.jones@linaro.org>
Message-ID: <20130422101606.GR24632@intel.com>

On Thu, Apr 18, 2013 at 11:12:06AM +0100, Lee Jones wrote:
> Using the new DMA DT bindings and API, we can register the DMA40 driver
> as Device Tree capable. Now, when a client attempts to allocate a
> channel using the DMA DT bindings via its own node, we are able to parse
> the request and allocate a channel in the correct manor.
typo						    ^^^^^
> 
> Cc: Vinod Koul <vinod.koul at intel.com>
> Cc: Dan Williams <djbw at fb.com>
> Cc: Per Forlin <per.forlin at stericsson.com>
> Cc: Rabin Vincent <rabin at rab.in>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>
> ---
>  .../devicetree/bindings/dma/ste-dma40.txt          |   66 ++++++++++++++++++++
>  drivers/dma/ste_dma40.c                            |   58 +++++++++++++++++
>  2 files changed, 124 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/dma/ste-dma40.txt
> 
> diff --git a/Documentation/devicetree/bindings/dma/ste-dma40.txt b/Documentation/devicetree/bindings/dma/ste-dma40.txt
> new file mode 100644
> index 0000000..1eb7958
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/dma/ste-dma40.txt
> @@ -0,0 +1,66 @@
> +* DMA40 DMA Controller
> +
> +Required properties:
> +- compatible: "stericsson,dma40"
> +- reg: Address range of the DMAC registers
> +- interrupt: Should contain the DMAC interrupt number
> +- dma-channels: Number of channels supported by hardware
> +- #dma-cells: must be <3>
> +
> +Optional properties:
> +- interrupt-parent: Should be the phandle for the interrupt controller
> +  that services interrupts for this device
> +
> +Example:
> +
> +	dma: dma-controller at 801C0000 {
> +		compatible = "stericsson,db8500-dma40", "stericsson,dma40";
> +		reg = <0x801C0000 0x1000>;
> +		reg-names = "base";
> +		interrupt-parent = <&intc>;
> +		interrupts = <0 25 0x4>;
> +
> +		#dma-cells = <2>;
> +		dma-channels = <0>; /* Zero means read from H/W. */
> +	};
> +
This needs to be Acked-By Arnd..
> +Clients
> +Required properties:
> +- dmas: Comma seperated list of dma channel requests
> +- dma-names: Names of the aforementioned requested channels
> +
> +Each dmas request consists of 4 cells:
> +  1. A phandle pointing to the DMA controller
> +  2. The DMA request line number (only when 'use fixed channel' is set)
> +  3. Device Type
> +  4. A 32bit mask specifying; mode, direction and endianess [NB: This list will grow]
> +        bits 1-2: Mode:
> +          00: Logical
> +          01: Physical
> +          10: Operation
> +          11: Undefined - will most likely return an error
> +        bits 3-4: Direction:
> +          00: Mem to Mem
> +          01: Mem to Dev
> +          10: Dev to Mem
> +          11: Dev to Dev
> +        bit 5: Endianess:
> +           0: Little endian
> +           1: Big endian
> +        bit 6: Use fixed channel:
> +           0: Use automatic channel selection
> +           1: Use DMA request line number
> +
> +Example:
> +
> +	uart at 80120000 {
> +		compatible = "arm,pl011", "arm,primecell";
> +		reg = <0x80120000 0x1000>;
> +		interrupts = <0 11 0x4>;
> +
> +		dmas = <&dma 0 13 0x8>, /* Logical - DevToMem */
> +		       <&dma 0 13 0x4>; /* Logical - MemToDev */
> +		dma-names = "rx", "rx";
> +
> +		status = "disabled";
> +	};
> diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
> index 4782ee7..9115c0e 100644
> --- a/drivers/dma/ste_dma40.c
> +++ b/drivers/dma/ste_dma40.c
> @@ -18,6 +18,7 @@
>  #include <linux/pm_runtime.h>
>  #include <linux/err.h>
>  #include <linux/of.h>
> +#include <linux/of_dma.h>
>  #include <linux/amba/bus.h>
>  #include <linux/regulator/consumer.h>
>  #include <linux/platform_data/dma-ste-dma40.h>
> @@ -2409,6 +2410,56 @@ static void d40_set_prio_realtime(struct d40_chan *d40c)
>  		__d40_set_prio_rt(d40c, d40c->dma_cfg.dev_type, false);
>  }
>  
> +#define D40_DT_FLAGS_MODE(flags)       ((flags >> 0) & 0x3)
> +#define D40_DT_FLAGS_DIR(flags)        ((flags >> 2) & 0x3)
> +#define D40_DT_FLAGS_BIG_ENDIAN(flags) ((flags >> 4) & 0x1)
> +#define D40_DT_FLAGS_FIXED_CHAN(flags) ((flags >> 5) & 0x1)
> +
> +static struct dma_chan *d40_xlate(struct of_phandle_args *dma_spec,
> +				  struct of_dma *ofdma)
> +{
> +	struct stedma40_chan_cfg cfg;
> +	dma_cap_mask_t cap;
> +	u32 flags;
> +
> +	memset(&cfg, 0, sizeof(struct stedma40_chan_cfg));
> +
> +	dma_cap_zero(cap);
> +	dma_cap_set(DMA_SLAVE, cap);
> +
> +	cfg.dev_type = dma_spec->args[1];
> +	flags = dma_spec->args[2];
> +
> +	switch (D40_DT_FLAGS_MODE(flags)) {
> +	case 0: cfg.mode = STEDMA40_MODE_LOGICAL; break;
> +	case 1: cfg.mode = STEDMA40_MODE_PHYSICAL; break;
> +	case 2: cfg.mode = STEDMA40_MODE_OPERATION; break;
> +	default:
> +		pr_err("dma40: Unknown mode read from DT (%d)\n",
> +		       D40_DT_FLAGS_MODE(flags));
> +		return NULL;
> +	}
> +
> +	switch (D40_DT_FLAGS_DIR(flags)) {
> +	case 0: cfg.dir = STEDMA40_MEM_TO_MEM; break;
> +	case 1: cfg.dir = STEDMA40_MEM_TO_PERIPH; break;
> +	case 2: cfg.dir = STEDMA40_PERIPH_TO_MEM; break;
> +	case 3: cfg.dir = STEDMA40_PERIPH_TO_PERIPH; break;
this looks ugly to me, Checkpatch should have complained..
Break could be on subsequent lines...
> +	}
> +
> +	if (cfg.dir == STEDMA40_PERIPH_TO_MEM)
> +		cfg.src_info.big_endian = D40_DT_FLAGS_BIG_ENDIAN(flags);
> +	if (cfg.dir == STEDMA40_MEM_TO_PERIPH)
> +		cfg.dst_info.big_endian = D40_DT_FLAGS_BIG_ENDIAN(flags);
> +
> +	if (D40_DT_FLAGS_FIXED_CHAN(flags)) {
> +		cfg.phy_channel = dma_spec->args[0];
> +		cfg.use_fixed_channel = true;
> +	}
> +
> +	return dma_request_channel(cap, stedma40_filter, &cfg);
> +}
> +
>  /* DMA ENGINE functions */
>  static int d40_alloc_chan_resources(struct dma_chan *chan)
>  {
> @@ -3615,6 +3666,13 @@ static int __init d40_probe(struct platform_device *pdev)
>  
>  	d40_hw_init(base);
>  
> +	if (np) {
> +		err = of_dma_controller_register(np, d40_xlate, NULL);
> +		if (err && err != -ENODEV)
> +			dev_err(&pdev->dev,
> +				"could not register of_dma_controller\n");
> +	}
> +
>  	dev_info(base->dev, "initialized\n");
>  	return 0;
>  
> -- 
> 1.7.10.4
> 


From lee.jones at linaro.org  Mon Apr 22 06:47:36 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Mon, 22 Apr 2013 11:47:36 +0100
Subject: [PATCH 14/23] regulator: ab3100: device tree support
In-Reply-To: <1366624645-6614-1-git-send-email-linus.walleij@stericsson.com>
References: <1366624645-6614-1-git-send-email-linus.walleij@stericsson.com>
Message-ID: <20130422104736.GM3432@gmail.com>

On Mon, 22 Apr 2013, Linus Walleij wrote:

> From: Linus Walleij <linus.walleij at linaro.org>
> 
> This implements device tree support for the AB3100 regulators
> driver. The initial settings are moved out of platform data
> and into the driver for the device tree case, as it appears
> that there is no way to supply this as AUXDATA for an I2C
> device. The style and bindings are heavily inspired by
> Lee Jones' style for AB8500.
> 
> Cc: Lee Jones <lee.jones at linaro.org>
> Cc: Mark Brown <broonie at kernel.org>
> Signed-off-by: Linus Walleij <linus.walleij at linaro.org>

I don't see any issues with it.

Acked-by: Lee Jones <lee.jones at linaro.org>

> ---
> Hi Mark, seeking an ACK on this to take it through the ARM
> SoC tree.
> ---
>  drivers/mfd/ab3100-core.c  |   1 +
>  drivers/regulator/ab3100.c | 123 ++++++++++++++++++++++++++++++++++++++++++---
>  2 files changed, 118 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/mfd/ab3100-core.c b/drivers/mfd/ab3100-core.c
> index 2ec7725..a9bb140 100644
> --- a/drivers/mfd/ab3100-core.c
> +++ b/drivers/mfd/ab3100-core.c
> @@ -753,6 +753,7 @@ static struct mfd_cell ab3100_devs[] = {
>  	},
>  	{
>  		.name = "ab3100-regulators",
> +		.of_compatible = "stericsson,ab3100-regulators",
>  		.id = -1,
>  	},
>  	{
> diff --git a/drivers/regulator/ab3100.c b/drivers/regulator/ab3100.c
> index 740735d..be1e6ad 100644
> --- a/drivers/regulator/ab3100.c
> +++ b/drivers/regulator/ab3100.c
> @@ -17,6 +17,8 @@
>  #include <linux/regulator/driver.h>
>  #include <linux/mfd/ab3100.h>
>  #include <linux/mfd/abx500.h>
> +#include <linux/of.h>
> +#include <linux/regulator/of_regulator.h>
>  
>  /* LDO registers and some handy masking definitions for AB3100 */
>  #define AB3100_LDO_A		0x40
> @@ -345,7 +347,11 @@ static int ab3100_get_voltage_regulator_external(struct regulator_dev *reg)
>  {
>  	struct ab3100_regulator *abreg = rdev_get_drvdata(reg);
>  
> -	return abreg->plfdata->external_voltage;
> +	if (abreg->plfdata)
> +		return abreg->plfdata->external_voltage;
> +	else
> +		/* TODO: encode external voltage into device tree */
> +		return 0;
>  }
>  
>  static struct regulator_ops regulator_ops_fixed = {
> @@ -490,6 +496,8 @@ ab3100_regulator_desc[AB3100_NUM_REGULATORS] = {
>  
>  static int ab3100_regulator_register(struct platform_device *pdev,
>  				     struct ab3100_platform_data *plfdata,
> +				     struct regulator_init_data *init_data,
> +				     struct device_node *np,
>  				     int id)
>  {
>  	struct regulator_desc *desc;
> @@ -518,9 +526,11 @@ static int ab3100_regulator_register(struct platform_device *pdev,
>  	 */
>  	reg->dev = &pdev->dev;
>  	if (plfdata) {
> -		/* This will be replaced by device tree data */
>  		reg->plfdata = plfdata;
>  		config.init_data = &plfdata->reg_constraints[i];
> +	} else if (np) {
> +		config.of_node = np;
> +		config.init_data = init_data;
>  	}
>  	config.dev = &pdev->dev;
>  	config.driver_data = reg;
> @@ -540,15 +550,103 @@ static int ab3100_regulator_register(struct platform_device *pdev,
>  	return 0;
>  }
>  
> +static struct of_regulator_match ab3100_regulator_matches[] = {
> +	{ .name = "ab3100_ldo_a", .driver_data = (void *) AB3100_LDO_A, },
> +	{ .name = "ab3100_ldo_c", .driver_data = (void *) AB3100_LDO_C, },
> +	{ .name = "ab3100_ldo_d", .driver_data = (void *) AB3100_LDO_D, },
> +	{ .name = "ab3100_ldo_e", .driver_data = (void *) AB3100_LDO_E, },
> +	{ .name = "ab3100_ldo_f", .driver_data = (void *) AB3100_LDO_F },
> +	{ .name = "ab3100_ldo_g", .driver_data = (void *) AB3100_LDO_G },
> +	{ .name = "ab3100_ldo_h", .driver_data = (void *) AB3100_LDO_H },
> +	{ .name = "ab3100_ldo_k", .driver_data = (void *) AB3100_LDO_K },
> +	{ .name = "ab3100_ext", .driver_data = (void *) AB3100_LDO_EXT },
> +	{ .name = "ab3100_buck", .driver_data = (void *) AB3100_BUCK },
> +};
> +
>  /*
> - * NOTE: the following functions are regulators pluralis - it is the
> - * binding to the AB3100 core driver and the parent platform device
> - * for all the different regulators.
> + * Initial settings of ab3100 registers.
> + * Common for below LDO regulator settings are that
> + * bit 7-5 controls voltage. Bit 4 turns regulator ON(1) or OFF(0).
> + * Bit 3-2 controls sleep enable and bit 1-0 controls sleep mode.
>   */
> +/* LDO_A 0x16: 2.75V, ON, SLEEP_A, SLEEP OFF GND */
> +#define LDO_A_SETTING		0x16
> +/* LDO_C 0x10: 2.65V, ON, SLEEP_A or B, SLEEP full power */
> +#define LDO_C_SETTING		0x10
> +/* LDO_D 0x10: 2.65V, ON, sleep mode not used */
> +#define LDO_D_SETTING		0x10
> +/* LDO_E 0x10: 1.8V, ON, SLEEP_A or B, SLEEP full power */
> +#define LDO_E_SETTING		0x10
> +/* LDO_E SLEEP 0x00: 1.8V, not used, SLEEP_A or B, not used */
> +#define LDO_E_SLEEP_SETTING	0x00
> +/* LDO_F 0xD0: 2.5V, ON, SLEEP_A or B, SLEEP full power */
> +#define LDO_F_SETTING		0xD0
> +/* LDO_G 0x00: 2.85V, OFF, SLEEP_A or B, SLEEP full power */
> +#define LDO_G_SETTING		0x00
> +/* LDO_H 0x18: 2.75V, ON, SLEEP_B, SLEEP full power */
> +#define LDO_H_SETTING		0x18
> +/* LDO_K 0x00: 2.75V, OFF, SLEEP_A or B, SLEEP full power */
> +#define LDO_K_SETTING		0x00
> +/* LDO_EXT 0x00: Voltage not set, OFF, not used, not used */
> +#define LDO_EXT_SETTING		0x00
> +/* BUCK 0x7D: 1.2V, ON, SLEEP_A and B, SLEEP low power */
> +#define BUCK_SETTING	0x7D
> +/* BUCK SLEEP 0xAC: 1.05V, Not used, SLEEP_A and B, Not used */
> +#define BUCK_SLEEP_SETTING	0xAC
> +
> +static const u8 ab3100_reg_initvals[] = {
> +	LDO_A_SETTING,
> +	LDO_C_SETTING,
> +	LDO_E_SETTING,
> +	LDO_E_SLEEP_SETTING,
> +	LDO_F_SETTING,
> +	LDO_G_SETTING,
> +	LDO_H_SETTING,
> +	LDO_K_SETTING,
> +	LDO_EXT_SETTING,
> +	BUCK_SETTING,
> +	BUCK_SLEEP_SETTING,
> +	LDO_D_SETTING,
> +};
> +
> +static int
> +ab3100_regulator_of_probe(struct platform_device *pdev, struct device_node *np)
> +{
> +	int err, i;
> +
> +	/*
> +	 * Set up the regulator registers, as was previously done with
> +	 * platform data.
> +	 */
> +	/* Set up regulators */
> +	for (i = 0; i < ARRAY_SIZE(ab3100_reg_init_order); i++) {
> +		err = abx500_set_register_interruptible(&pdev->dev, 0,
> +					ab3100_reg_init_order[i],
> +					ab3100_reg_initvals[i]);
> +		if (err) {
> +			dev_err(&pdev->dev, "regulator initialization failed with error %d\n",
> +				err);
> +			return err;
> +		}
> +	}
> +
> +	for (i = 0; i < ARRAY_SIZE(ab3100_regulator_matches); i++) {
> +		err = ab3100_regulator_register(
> +			pdev, NULL, ab3100_regulator_matches[i].init_data,
> +			ab3100_regulator_matches[i].of_node,
> +			(int) ab3100_regulator_matches[i].driver_data);
> +		if (err)
> +			return err;
> +	}
> +
> +	return 0;
> +}
> +
>  
>  static int ab3100_regulators_probe(struct platform_device *pdev)
>  {
>  	struct ab3100_platform_data *plfdata = pdev->dev.platform_data;
> +	struct device_node *np = pdev->dev.of_node;
>  	int err = 0;
>  	u8 data;
>  	int i;
> @@ -567,6 +665,18 @@ static int ab3100_regulators_probe(struct platform_device *pdev)
>  		dev_notice(&pdev->dev,
>  			   "chip is in inactive mode (Cold start)\n");
>  
> +	if (np) {
> +		err = of_regulator_match(&pdev->dev, np,
> +					 ab3100_regulator_matches,
> +					 ARRAY_SIZE(ab3100_regulator_matches));
> +		if (err < 0) {
> +			dev_err(&pdev->dev,
> +				"Error parsing regulator init data: %d\n", err);
> +			return err;
> +		}
> +		return ab3100_regulator_of_probe(pdev, np);
> +	}
> +
>  	/* Set up regulators */
>  	for (i = 0; i < ARRAY_SIZE(ab3100_reg_init_order); i++) {
>  		err = abx500_set_register_interruptible(&pdev->dev, 0,
> @@ -583,7 +693,8 @@ static int ab3100_regulators_probe(struct platform_device *pdev)
>  	for (i = 0; i < AB3100_NUM_REGULATORS; i++) {
>  		struct regulator_desc *desc = &ab3100_regulator_desc[i];
>  
> -		err = ab3100_regulator_register(pdev, plfdata, desc->id);
> +		err = ab3100_regulator_register(pdev, plfdata, NULL, NULL,
> +						desc->id);
>  		if (err)
>  			return err;
>  	}

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From vinod.koul at intel.com  Mon Apr 22 06:17:41 2013
From: vinod.koul at intel.com (Vinod Koul)
Date: Mon, 22 Apr 2013 15:47:41 +0530
Subject: [PATCH 24/32 v2] dmaengine: ste_dma40: Supply full Device Tree
 parsing support
In-Reply-To: <20130418121253.GF27903@gmail.com>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-25-git-send-email-lee.jones@linaro.org>
 <20130418121253.GF27903@gmail.com>
Message-ID: <20130422101741.GS24632@intel.com>

On Thu, Apr 18, 2013 at 01:12:53PM +0100, Lee Jones wrote:
> Using the new DMA DT bindings and API, we can register the DMA40 driver
> as Device Tree capable. Now, when a client attempts to allocate a
> channel using the DMA DT bindings via its own node, we are able to parse
> the request and allocate a channel in the correct manner.
> +
> +	switch (D40_DT_FLAGS_MODE(flags)) {
> +	case 0: cfg.mode = STEDMA40_MODE_LOGICAL; break;
> +	case 1: cfg.mode = STEDMA40_MODE_PHYSICAL; break;
ah there was a v2, i need to see the thread, this one still needs to be fixed
though

--
~Vinod


From will.deacon at arm.com  Mon Apr 22 06:48:58 2013
From: will.deacon at arm.com (Will Deacon)
Date: Mon, 22 Apr 2013 11:48:58 +0100
Subject: [PATCH 3/4] ARM: sched_clock: Add support for >32 bit sched_clock
In-Reply-To: <1366417746-24990-4-git-send-email-sboyd@codeaurora.org>
References: <1366417746-24990-1-git-send-email-sboyd@codeaurora.org>
 <1366417746-24990-4-git-send-email-sboyd@codeaurora.org>
Message-ID: <20130422104858.GB2572@mudshark.cambridge.arm.com>

Hi Stephen,

On Sat, Apr 20, 2013 at 01:29:05AM +0100, Stephen Boyd wrote:
> The arm architected system counter has at least 56 bits of
> useable bits. Add support to ARM's sched_clock implementation for
> counters with more than 32 bits so we can avoid the complexity of
> dealing with wraparound on these devices while benefiting from
> the irqtime accounting and suspend/resume handling that the ARM
> sched_clock code already has.
> 
> Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
> ---
> 
> Maybe we need a union for the epoch_ns usage?
> 
>  arch/arm/include/asm/sched_clock.h |   2 +
>  arch/arm/kernel/sched_clock.c      | 101 +++++++++++++++++++++++++++----------
>  2 files changed, 77 insertions(+), 26 deletions(-)
> 
> diff --git a/arch/arm/include/asm/sched_clock.h b/arch/arm/include/asm/sched_clock.h
> index 3d520dd..7fcd2ee 100644
> --- a/arch/arm/include/asm/sched_clock.h
> +++ b/arch/arm/include/asm/sched_clock.h
> @@ -13,4 +13,6 @@ extern void setup_sched_clock(u32 (*read)(void), int bits, unsigned long rate);
>  
>  extern unsigned long long (*sched_clock_func)(void);
>  
> +extern void setup_sched_clock_64(u64 (*read)(void), int bits,
> +				 unsigned long rate);

Curious, but why do we need two setup_sched_clock functions, where the bits
are passed as a parameter? Can't we just do the right thing if the clock
claims to be more than 32 bits wide (and get rid of the BUG_ONs at the same
time)?

Will


From andrew.murray at arm.com  Mon Apr 22 06:49:16 2013
From: andrew.murray at arm.com (Andrew Murray)
Date: Mon, 22 Apr 2013 11:49:16 +0100
Subject: [PATCH v7 3/3] of/pci: mips: convert to common of_pci_range_parser
In-Reply-To: <517394C6.2060407@openwrt.org>
References: <1366107508-12672-1-git-send-email-Andrew.Murray@arm.com>
 <1366107508-12672-4-git-send-email-Andrew.Murray@arm.com>
 <CACRpkdbBaT1OKr5t8HW4+8y_wSDmGxmewAyVMekx8S-K9s3K8Q@mail.gmail.com>
 <20130418125910.GA17128@arm.com>
 <20130418130919.GI27197@titan.lakedaemon.net>
 <5170F016.6050502@openwrt.org>
 <20130420223343.GB25724@titan.lakedaemon.net>
 <517394C6.2060407@openwrt.org>
Message-ID: <20130422104916.GA17007@arm.com>

On Sun, Apr 21, 2013 at 08:27:02AM +0100, Gabor Juhos wrote:
> Hi Jason,
> 
> >> Sorry I had no time earlier, but I have tested this now on MIPS. The patch
> >> causes build errors unfortunately. Given the fact that this has been merged
> >> already, I will send a fixup patch.
> > 
> > Olof has dropped this branch from arm-soc, plase post the build error
> > and fix here so that it can be included in this series.
> 
> I have posted the patch to Olof two days ago. It has been CC'd to you as well
> but In case that it does not exists in your mailbox the patch can be found here:
> 
> https://patchwork.linux-mips.org/patch/5196/
> 
> However I can re-post the patch as a reply to this thread if you prefer that.

As this branch was dropped I have updated my patchset to include Grant's recent
feedback - I've also included Gabor's fixes to this patchset (and his sign-off).

If you include this new patchset in your branch the drivers that depend on it
will need to be updated to reflect the new naming of functions as suggested by
Grant.

Thanks,

Andrew Murray


From vinod.koul at intel.com  Mon Apr 22 06:18:58 2013
From: vinod.koul at intel.com (Vinod Koul)
Date: Mon, 22 Apr 2013 15:48:58 +0530
Subject: [PATCH 24/32 v3] dmaengine: ste_dma40: Supply full Device Tree
 parsing support
In-Reply-To: <20130418141752.GC3959@gmail.com>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-25-git-send-email-lee.jones@linaro.org>
 <20130418121253.GF27903@gmail.com>
 <20130418141752.GC3959@gmail.com>
Message-ID: <20130422101858.GT24632@intel.com>

On Thu, Apr 18, 2013 at 03:17:52PM +0100, Lee Jones wrote:
> Using the new DMA DT bindings and API, we can register the DMA40 driver
> as Device Tree capable. Now, when a client attempts to allocate a
> channel using the DMA DT bindings via its own node, we are able to parse
> the request and allocate a channel in the correct manner.
> 
> Cc: Vinod Koul <vinod.koul at intel.com>
> Cc: Dan Williams <djbw at fb.com>
> Cc: Per Forlin <per.forlin at stericsson.com>
> Cc: Rabin Vincent <rabin at rab.in>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>
Okay read vN if there is one, before replying!
so..

Acked-by: Vinod Koul <vinod.koul at intel.com>

--
~Vinod
> 
> diff --git a/Documentation/devicetree/bindings/dma/ste-dma40.txt b/Documentation/devicetree/bindings/dma/ste-dma40.txt
> new file mode 100644
> index 0000000..2679a87
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/dma/ste-dma40.txt
> @@ -0,0 +1,62 @@
> +* DMA40 DMA Controller
> +
> +Required properties:
> +- compatible: "stericsson,dma40"
> +- reg: Address range of the DMAC registers
> +- reg-names: Names of the above areas to use during resource look-up
> +- interrupt: Should contain the DMAC interrupt number
> +- #dma-cells: must be <3>
> +
> +Optional properties:
> +- dma-channels: Number of channels supported by hardware - if not present
> +		the driver will attempt to obtain the information from H/W
> +
> +Example:
> +
> +	dma: dma-controller at 801C0000 {
> +		compatible = "stericsson,db8500-dma40", "stericsson,dma40";
> +		reg = <0x801C0000 0x1000  0x40010000 0x800>;
> +		reg-names = "base", "lcpa";
> +		interrupt-parent = <&intc>;
> +		interrupts = <0 25 0x4>;
> +
> +		#dma-cells = <2>;
> +		dma-channels = <8>;
> +	};
> +
> +Clients
> +Required properties:
> +- dmas: Comma separated list of dma channel requests
> +- dma-names: Names of the aforementioned requested channels
> +
> +Each dmas request consists of 4 cells:
> +  1. A phandle pointing to the DMA controller
> +  2. Device Type
> +  3. The DMA request line number (only when 'use fixed channel' is set)
> +  4. A 32bit mask specifying; mode, direction and endianess [NB: This list will grow]
> +        0x00000001: Mode:
> +                Logical channel when unset
> +                Physical channel when set
> +        0x00000002: Direction:
> +                Memory to Device when unset
> +                Device to Memory when set
> +        0x00000004: Endianess:
> +                Little endian when unset
> +                Big endian when set
> +        0x00000008: Use fixed channel:
> +                Use automatic channel selection when unset
> +                Use DMA request line number when set
> +
> +Example:
> +
> +	uart at 80120000 {
> +		compatible = "arm,pl011", "arm,primecell";
> +		reg = <0x80120000 0x1000>;
> +		interrupts = <0 11 0x4>;
> +
> +		dmas = <&dma 13 0 0x2>, /* Logical - DevToMem */
> +		       <&dma 13 0 0x0>; /* Logical - MemToDev */
> +		dma-names = "rx", "rx";
> +
> +		status = "disabled";
> +	};
> diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
> index bad8753..94d0edb 100644
> --- a/drivers/dma/ste_dma40.c
> +++ b/drivers/dma/ste_dma40.c
> @@ -18,6 +18,7 @@
>  #include <linux/pm_runtime.h>
>  #include <linux/err.h>
>  #include <linux/of.h>
> +#include <linux/of_dma.h>
>  #include <linux/amba/bus.h>
>  #include <linux/regulator/consumer.h>
>  #include <linux/platform_data/dma-ste-dma40.h>
> @@ -2409,6 +2410,50 @@ static void d40_set_prio_realtime(struct d40_chan *d40c)
>  		__d40_set_prio_rt(d40c, d40c->dma_cfg.dev_type, false);
>  }
>  
> +#define D40_DT_FLAGS_MODE(flags)       ((flags >> 0) & 0x1)
> +#define D40_DT_FLAGS_DIR(flags)        ((flags >> 1) & 0x1)
> +#define D40_DT_FLAGS_BIG_ENDIAN(flags) ((flags >> 2) & 0x1)
> +#define D40_DT_FLAGS_FIXED_CHAN(flags) ((flags >> 3) & 0x1)
> +
> +static struct dma_chan *d40_xlate(struct of_phandle_args *dma_spec,
> +				  struct of_dma *ofdma)
> +{
> +	struct stedma40_chan_cfg cfg;
> +	dma_cap_mask_t cap;
> +	u32 flags;
> +
> +	memset(&cfg, 0, sizeof(struct stedma40_chan_cfg));
> +
> +	dma_cap_zero(cap);
> +	dma_cap_set(DMA_SLAVE, cap);
> +
> +	cfg.dev_type = dma_spec->args[0];
> +	flags = dma_spec->args[2];
> +
> +	switch (D40_DT_FLAGS_MODE(flags)) {
> +	case 0: cfg.mode = STEDMA40_MODE_LOGICAL; break;
> +	case 1: cfg.mode = STEDMA40_MODE_PHYSICAL; break;
> +	}
> +
> +	switch (D40_DT_FLAGS_DIR(flags)) {
> +	case 0:
> +		cfg.dir = STEDMA40_MEM_TO_PERIPH;
> +		cfg.dst_info.big_endian = D40_DT_FLAGS_BIG_ENDIAN(flags);
> +		break;
> +	case 1:
> +		cfg.dir = STEDMA40_PERIPH_TO_MEM;
> +		cfg.src_info.big_endian = D40_DT_FLAGS_BIG_ENDIAN(flags);
> +		break;
> +	}
> +
> +	if (D40_DT_FLAGS_FIXED_CHAN(flags)) {
> +		cfg.phy_channel = dma_spec->args[1];
> +		cfg.use_fixed_channel = true;
> +	}
> +
> +	return dma_request_channel(cap, stedma40_filter, &cfg);
> +}
> +
>  /* DMA ENGINE functions */
>  static int d40_alloc_chan_resources(struct dma_chan *chan)
>  {
> @@ -3615,6 +3660,13 @@ static int __init d40_probe(struct platform_device *pdev)
>  
>  	d40_hw_init(base);
>  
> +	if (np) {
> +		err = of_dma_controller_register(np, d40_xlate, NULL);
> +		if (err && err != -ENODEV)
> +			dev_err(&pdev->dev,
> +				"could not register of_dma_controller\n");
> +	}
> +
>  	dev_info(base->dev, "initialized\n");
>  	return 0;


From vinod.koul at intel.com  Mon Apr 22 06:19:49 2013
From: vinod.koul at intel.com (Vinod Koul)
Date: Mon, 22 Apr 2013 15:49:49 +0530
Subject: [PATCH 05/32] dmaengine: ste_dma40: Supply macros to resolve
 'src' and 'dst' directions
In-Reply-To: <20130422102748.GJ3432@gmail.com>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-6-git-send-email-lee.jones@linaro.org>
 <20130422094250.GJ24632@intel.com>
 <20130422102748.GJ3432@gmail.com>
Message-ID: <20130422101949.GU24632@intel.com>

On Mon, Apr 22, 2013 at 11:27:48AM +0100, Lee Jones wrote:
> On Mon, 22 Apr 2013, Vinod Koul wrote:
> 
> > On Thu, Apr 18, 2013 at 11:11:47AM +0100, Lee Jones wrote:
> > > There are lots of lengthy if() statements located sporadically up and
> > > down the driver. This simple macro should make many of them a little
> > > simpler to decipher. The remainder have to stay in place, as they
> > > detail slightly more specific settings.
> > I would like these to be DMAENGINE_IS_SRC...
> 
> I don't understand, as they're DMA40 specific?
> 
> > and this patch use the defines provided in dmaengine
> 
> I think a subsequent patch doing he following would be more suitable:
> 
> s/STEDMA40_MEM_TO_MEM/DMA_MEM_TO_MEM/
> s/STEDMA40_MEM_TO_PERIPH/DMA_MEM_TO_DEV/
> s/STEDMA40_PERIPH_TO_MEM/DMA_DEV_TO_MEM/
> s/STEDMA40_PERIPH_TO_PERIPH/DMA_DEV_TO_DEV/
> 
> If you don't mind?
sounds like a good plan

--
~Vinod


From lee.jones at linaro.org  Mon Apr 22 06:53:53 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Mon, 22 Apr 2013 11:53:53 +0100
Subject: [PATCH 08/32] dmaengine: ste_dma40: Optimise local MAX() macro
In-Reply-To: <20130422101029.GP24632@intel.com>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-9-git-send-email-lee.jones@linaro.org>
 <20130422101029.GP24632@intel.com>
Message-ID: <20130422105353.GN3432@gmail.com>

On Mon, 22 Apr 2013, Vinod Koul wrote:

> On Thu, Apr 18, 2013 at 11:11:50AM +0100, Lee Jones wrote:
> > The current implementation of the DMA40's local MAX() macro evaluates
> > its arguments more times than is necessary. This patch strips it
> > optimises it to only evaluate what's appropriate.
> > 
> > Cc: Vinod Koul <vinod.koul at intel.com>
> > Cc: Dan Williams <djbw at fb.com>
> > Cc: Per Forlin <per.forlin at stericsson.com>
> > Cc: Rabin Vincent <rabin at rab.in>
> > Reported-by: Harvey Harrison <harvey.harrison at gmail.com>
> > Signed-off-by: Lee Jones <lee.jones at linaro.org>
> > ---
> >  drivers/dma/ste_dma40.c |    2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
> > index b21a8a3..7b451b2 100644
> > --- a/drivers/dma/ste_dma40.c
> > +++ b/drivers/dma/ste_dma40.c
> > @@ -53,7 +53,7 @@
> >  #define D40_ALLOC_PHY		BIT(30)
> >  #define D40_ALLOC_LOG_FREE	BIT(0)
> >  
> > -#define MAX(a, b) (((a) < (b)) ? (b) : (a))
> > +#define MAX(a, b) ((a > b) ? a : b)
> Am not a big fan of own redefines, can you use kernel max() macro instead

Unfortunately not in this instance, as the kernel max() macro uses
curly braces and is not suitable for this use-case. There is a thread
regarding this on the MLs with Arnd Bergmann, Russell King and myself.

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From vinod.koul at intel.com  Mon Apr 22 06:23:41 2013
From: vinod.koul at intel.com (Vinod Koul)
Date: Mon, 22 Apr 2013 15:53:41 +0530
Subject: [PATCH 21/32] dmaengine: ste_dma40: Also report the number of
 logical channels
In-Reply-To: <20130422103715.GK3432@gmail.com>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-22-git-send-email-lee.jones@linaro.org>
 <20130422093631.GE24632@intel.com>
 <20130422101455.GH3432@gmail.com>
 <20130422094842.GL24632@intel.com>
 <20130422103715.GK3432@gmail.com>
Message-ID: <20130422102341.GV24632@intel.com>

On Mon, Apr 22, 2013 at 11:37:15AM +0100, Lee Jones wrote:
> On Mon, 22 Apr 2013, Vinod Koul wrote:
> You only get a warning for this too:
Yup, oh i wrongly mention error
> 
>  WARNING: quoted string split across lines
> #33: FILE: drivers/dma/ste_dma40.c:3204:
> +	dev_info(&pdev->dev, "hardware revision: %d @ 0x%x with "
> +		"%d physical channels and %d logical channels\n",
> 
> > > How would you solve this?
> > Use common sense :) I would never sacrfice readablity of code. Erring on 80chars
> > is fine by me as long as it makes sense.
> 
> Common sense to me says split a string which goes over 100 chars. :)
agreed :)
> 
> ... and I don't think readability is compromised all that much, if at all.
I think if you start above at next line, you can be in 100chars and still be in
single line...
	dev_info(&pdev->dev,
		"hardware revision: %d @ 0x%x with %d physical channels and %d logical channels\n",
Plus a truncated one would help too...
s/revision/rev
s/channels/ch
etc

would bring this to saner levels :)

--
~Vinod


From linux at arm.linux.org.uk  Mon Apr 22 06:52:45 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Mon, 22 Apr 2013 11:52:45 +0100
Subject: [PATCH 21/32] dmaengine: ste_dma40: Also report the number of
 logical channels
In-Reply-To: <20130422103715.GK3432@gmail.com>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-22-git-send-email-lee.jones@linaro.org>
 <20130422093631.GE24632@intel.com> <20130422101455.GH3432@gmail.com>
 <20130422094842.GL24632@intel.com> <20130422103715.GK3432@gmail.com>
Message-ID: <20130422105245.GG14496@n2100.arm.linux.org.uk>

On Mon, Apr 22, 2013 at 11:37:15AM +0100, Lee Jones wrote:
> On Mon, 22 Apr 2013, Vinod Koul wrote:
> 
> > On Mon, Apr 22, 2013 at 11:14:55AM +0100, Lee Jones wrote:
> > > On Mon, 22 Apr 2013, Vinod Koul wrote:
> > > 
> > > > On Thu, Apr 18, 2013 at 11:12:03AM +0100, Lee Jones wrote:
> > > > > +	dev_info(&pdev->dev, "hardware revision: %d @ 0x%x with "
> > > > > +		"%d physical channels and %d logical channels\n",
> > > > > +		rev, res->start, num_phy_chans, num_log_chans);
> > > > Splitting log messages across lines is bad idea and sacrifces readablity... also
> > > > wasnt splitting logging to multiple lines emit checkpatch warn

Yes, but for a different reason...

> > > You also get a check-patch error if your lines are over 80 chars.
> > No, you get a warn
> 
> You only get a warning for this too:
> 
>  WARNING: quoted string split across lines
> #33: FILE: drivers/dma/ste_dma40.c:3204:
> +	dev_info(&pdev->dev, "hardware revision: %d @ 0x%x with "
> +		"%d physical channels and %d logical channels\n",

>From coding style: "However, never break user-visible strings such as
printk messages, because that breaks the ability to grep for them."

You can argue that you wouldn't grep for the above string - but consider
if you grepped for "hardware revision.*channels" to try and find the
above message, which would be a reasonable thing to try if you got lots
of hits on just "hardware revision".


From andrew.murray at arm.com  Mon Apr 22 06:57:24 2013
From: andrew.murray at arm.com (Andrew Murray)
Date: Mon, 22 Apr 2013 11:57:24 +0100
Subject: [PATCH v7 2/3] of/pci: Provide support for parsing PCI DT
 ranges property
In-Reply-To: <20130418134401.84AEE3E1319@localhost>
References: <1366107508-12672-1-git-send-email-Andrew.Murray@arm.com>
 <1366107508-12672-3-git-send-email-Andrew.Murray@arm.com>
 <20130418134401.84AEE3E1319@localhost>
Message-ID: <20130422105724.GB17007@arm.com>

On Thu, Apr 18, 2013 at 02:44:01PM +0100, Grant Likely wrote:
> On Tue, 16 Apr 2013 11:18:27 +0100, Andrew Murray <Andrew.Murray at arm.com> wrote:

> 
> Acked-by: Grant Likely <grant.likely at secretlab.ca>
> 
> But comments below...
> 

I've updated the patchset (now v8) to reflect your feedback, after a closer
look...

> > -
> > -		pr_debug("pci_space: 0x%08x pci_addr:0x%016llx ",
> > -				pci_space, pci_addr);
> > -		pr_debug("cpu_addr:0x%016llx size:0x%016llx\n",
> > -					cpu_addr, size);
> > -
> > -		ranges += np;
> > +		pr_debug("pci_space: 0x%08x pci_addr: 0x%016llx ",
> > +				range.pci_space, range.pci_addr);
> > +		pr_debug("cpu_addr: 0x%016llx size: 0x%016llx\n",
> > +				range.cpu_addr, range.size);
> 
> Nit: the patch changed whitespace on the pr_debug() statements, so even
> though the first line of each is identical, they look different in the
> patch.
> 

Actually the first line isn't identical, the original file was inconsistent
with its use of spaces between ':' and '0x%0' - my patch ensured that there
was always a space. I guess this could have been done as a separate patch.

> >  
> >  		/* If we failed translation or got a zero-sized region
> >  		 * (some FW try to feed us with non sensical zero sized regions
> >  		 * such as power3 which look like some kind of attempt
> >  		 * at exposing the VGA memory hole)
> >  		 */
> > -		if (cpu_addr == OF_BAD_ADDR || size == 0)
> > +		if (range.cpu_addr == OF_BAD_ADDR || range.size == 0)
> >  			continue;
> 
> Can this also be rolled into the parsing iterator?
> 

I decided not to do this. Mainly because ARM drivers use the parser directly
(instead of pci_process_bridge_OF_ranges function) and it seemed perfectly
valid for the parser to return a range of size 0 if that is what was present in
the DT.

> >  
> > -		/* Now consume following elements while they are contiguous */
> > -		for (; rlen >= np * sizeof(u32);
> > -		     ranges += np, rlen -= np * 4) {
> > -			if (ranges[0] != pci_space)
> > -				break;
> > -			pci_next = of_read_number(ranges + 1, 2);
> > -			cpu_next = of_translate_address(dev, ranges + 3);
> > -			if (pci_next != pci_addr + size ||
> > -			    cpu_next != cpu_addr + size)
> > -				break;
> > -			size += of_read_number(ranges + pna + 3, 2);
> > -		}
> > -
> >  		/* Act based on address space type */
> >  		res = NULL;
> > -		switch ((pci_space >> 24) & 0x3) {
> > -		case 1:		/* PCI IO space */
> > +		res_type = range.flags & IORESOURCE_TYPE_BITS;
> > +		if (res_type == IORESOURCE_IO) {
> 
> Why the change from switch() to an if/else if sequence?

I think this was an artifact of the patches evolution, I've reverted back to
the switch.

> 
> But those are mostly nitpicks. If this is deferred to v3.10 then I would
> suggest fixing them up and posting for another round of review.

Andrew Murray


From marc.zyngier at arm.com  Mon Apr 22 07:02:59 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon, 22 Apr 2013 12:02:59 +0100
Subject: [PATCH] ARM: KVM: iterate over all CPUs for CPU compatibility
 check
In-Reply-To: <517512CA.6070503@linaro.org>
References: <51680AF9.7040109@arm.com>
 <CAEDV+g+E8PLc60vMRhq4O_AL2WjmYDLb6=Wh34ynhevh7uAGJA@mail.gmail.com>
 <d455f2823b9639af8d38d30f2c3234bd@localhost>
 <CAEDV+gJuFG49oQ=BEaCHcTP=nHVyX8ALw6076dR_C1s7TuyqXQ@mail.gmail.com>
 <d47697abd39a0d5d41f5ac110a40e261@localhost>
 <CAEDV+gK9==sXYxRVZ8JVFYPiw3_xgzZBbydEwPunmnocNLKXrQ@mail.gmail.com>
 <CAFEAcA-bPoa8YoPuHPmupzfUW+yR233XquK79eNorzcRpFiK=g@mail.gmail.com>
 <516BCAD0.9000708@linaro.org>
 <CAJRNFKJoBzgt4UhxsH65_LyhcGXPnzB_pg3q-zeYT2OVv59q4A@mail.gmail.com>
 <516BFD13.1000400@linaro.org>
 <20130415134837.GI9827@mudshark.cambridge.arm.com>
 <CAEDV+gJB7Bj9O7pftFqoYQ=goORjdurBnEfQVmC5arDuNJfpBg@mail.gmail.com>
 <32d532438f5b621e40679aea9f5888c7@localhost> <516E586C.5030407@linaro.org>
 <8e0bda3fd84d1b0c5aa55161ca178a8e@localhost>
 <CAEDV+g+3nkdvbLdj0m-ZdDKt0JY2vgzhP2AQA2nf=R3h4yTQmQ@mail.gmail.com>
 <51713F91.5080102@linaro.org>
 <CAEDV+gL=rbxxBRgYdHxBj_C9ZBFbuORaG0jcSzEUJ7pO9-Fqkg@mail.gmail.com>
 <517512CA.6070503@linaro.org>
Message-ID: <517518E3.5020209@arm.com>

On 22/04/13 11:36, Andre Przywara wrote:
> On 04/19/2013 06:13 PM, Christoffer Dall wrote:
>> On Fri, Apr 19, 2013 at 5:58 AM, Andre Przywara
>> <andre.przywara at linaro.org> wrote:
>>> On 04/17/2013 11:12 AM, Christoffer Dall wrote:
>>>>
>>>>  ...
>>>>
>>>> You could also try installing a vector handler early and detect faults,
>>>> and add an alternative return path from the init function with some
>>>> error reporting value in r0 or something like that, just for debugging,
>>>> naturally, but that could be a way to detect if we really are taking
>>>> recursive faults here.
>>>
>>>
>>> OK, I added code to return earlier on CPUs not from cluster 0.
>>> Indeed it hangs in the HSCR write. The two A15s pass this instruction,
>>> writing 0x30c5187F into the register.
>>> This means all the fixed bits for A15 correctly, C,A,M and I set and WXN,
>>> EE, TE cleared. FI was also cleared
>>> The A7 wanted to write the very same value. I tried to set bit 21, which
>>> kind of the A7 TRM hints to do: but no change.
>>> Before the HSCLTR write, the register reads 0x30c50878, with SCTLR being
>>> 0x30c5387d.
>>> So the code wants to set M, A, C and I in HSCLTR. Interestingly SCTLR has
>>> the V bits set, could that be an issue?
>>>
>> Can you try writing 0x30c50879 into the register instead? Basically
>> check to see if enabling caches or alignment checks causes the issue,
>> or if it is indeed enabling the MMU that's the issue... If that works,
>> start a bisect on the remaining bits. Also, just for fun, could you
>> try flushing the entire I-cache before writing into the HSCLTR?
> 
> OK, both clearing the I-bit and doing an "isb; ICIALLU" before the "isb; 
> write HSCLTR; isb" worked, the kernel boots on and KVM is enabled.
> 
> I could easily make a patch, but I am not sure how to proceed from here:
> 
> 1.) At least I don't have an understanding why this is only a problem on 
> A7 and not on A15. I would feel better if we have an explanation for 
> this. Mark, Will, Peter: any ideas?

Blink!

Can you check your board.txt config file? It should have a line that
starts with "SCC: 0x400 ..."

If not, can you add a line that reads:
SCC: 0x400 0x00000000

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...



From vinod.koul at intel.com  Mon Apr 22 06:34:37 2013
From: vinod.koul at intel.com (Vinod Koul)
Date: Mon, 22 Apr 2013 16:04:37 +0530
Subject: [PATCH 18/23] dma: coh901318: add devicetree support
In-Reply-To: <1366624770-6786-1-git-send-email-linus.walleij@stericsson.com>
References: <1366624770-6786-1-git-send-email-linus.walleij@stericsson.com>
Message-ID: <20130422103437.GX24632@intel.com>

On Mon, Apr 22, 2013 at 11:59:30AM +0200, Linus Walleij wrote:
> From: Linus Walleij <linus.walleij at linaro.org>
> 
> This adds support for probing the COH 901 318 DMA controller
> from the device tree.
> 
> Cc: Vinod Koul <vinod.koul at intel.com>
> Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
Acked-by: Vinod Koul <vinod.koul at intel.com>

--
~Vinod
> ---
> Hi Vinod, I'm seeking an ACK on this patch to take it through
> the ARM SoC tree.
> ---
>  drivers/dma/coh901318.c | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/dma/coh901318.c b/drivers/dma/coh901318.c
> index 797940e..2855646 100644
> --- a/drivers/dma/coh901318.c
> +++ b/drivers/dma/coh901318.c
> @@ -2758,11 +2758,16 @@ static int __exit coh901318_remove(struct platform_device *pdev)
>  	return 0;
>  }
>  
> +static const struct of_device_id coh901318_dt_match[] = {
> +	{ .compatible = "stericsson,coh901318" },
> +	{},
> +};
>  
>  static struct platform_driver coh901318_driver = {
>  	.remove = __exit_p(coh901318_remove),
>  	.driver = {
>  		.name	= "coh901318",
> +		.of_match_table = coh901318_dt_match,
>  	},
>  };
>  
> -- 
> 1.7.11.3
> 


From marc.zyngier at arm.com  Mon Apr 22 07:14:39 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon, 22 Apr 2013 13:14:39 +0200
Subject: [PATCH] ARM: KVM: iterate over all CPUs for CPU compatibility
 check
In-Reply-To: <517518E3.5020209@arm.com>
References: <51680AF9.7040109@arm.com>
 <CAEDV+g+E8PLc60vMRhq4O_AL2WjmYDLb6=Wh34ynhevh7uAGJA@mail.gmail.com>
 <d455f2823b9639af8d38d30f2c3234bd@localhost>
 <CAEDV+gJuFG49oQ=BEaCHcTP=nHVyX8ALw6076dR_C1s7TuyqXQ@mail.gmail.com>
 <d47697abd39a0d5d41f5ac110a40e261@localhost>
 <CAEDV+gK9==sXYxRVZ8JVFYPiw3_xgzZBbydEwPunmnocNLKXrQ@mail.gmail.com>
 <CAFEAcA-bPoa8YoPuHPmupzfUW+yR233XquK79eNorzcRpFiK=g@mail.gmail.com>
 <516BCAD0.9000708@linaro.org>
 <CAJRNFKJoBzgt4UhxsH65_LyhcGXPnzB_pg3q-zeYT2OVv59q4A@mail.gmail.com>
 <516BFD13.1000400@linaro.org>
 <20130415134837.GI9827@mudshark.cambridge.arm.com>
 <CAEDV+gJB7Bj9O7pftFqoYQ=goORjdurBnEfQVmC5arDuNJfpBg@mail.gmail.com>
 <32d532438f5b621e40679aea9f5888c7@localhost> <516E586C.5030407@linaro.org>
 <8e0bda3fd84d1b0c5aa55161ca178a8e@localhost>
 <CAEDV+g+3nkdvbLdj0m-ZdDKt0JY2vgzhP2AQA2nf=R3h4yTQmQ@mail.gmail.com>
 <51713F91.5080102@linaro.org>
 <CAEDV+gL=rbxxBRgYdHxBj_C9ZBFbuORaG0jcSzEUJ7pO9-Fqkg@mail.gmail.com>
 <517512CA.6070503@linaro.org> <517518E3.5020209@arm.com>
Message-ID: <0d25b7378e6e13be4e3c599c4325f2b4@localhost>

On Mon, 22 Apr 2013 12:02:59 +0100, Marc Zyngier <marc.zyngier at arm.com>
wrote:
> On 22/04/13 11:36, Andre Przywara wrote:
>> On 04/19/2013 06:13 PM, Christoffer Dall wrote:
>>> On Fri, Apr 19, 2013 at 5:58 AM, Andre Przywara
>>> <andre.przywara at linaro.org> wrote:
>>>> On 04/17/2013 11:12 AM, Christoffer Dall wrote:
>>>>>
>>>>>  ...
>>>>>
>>>>> You could also try installing a vector handler early and detect
>>>>> faults,
>>>>> and add an alternative return path from the init function with some
>>>>> error reporting value in r0 or something like that, just for
>>>>> debugging,
>>>>> naturally, but that could be a way to detect if we really are taking
>>>>> recursive faults here.
>>>>
>>>>
>>>> OK, I added code to return earlier on CPUs not from cluster 0.
>>>> Indeed it hangs in the HSCR write. The two A15s pass this
instruction,
>>>> writing 0x30c5187F into the register.
>>>> This means all the fixed bits for A15 correctly, C,A,M and I set and
>>>> WXN,
>>>> EE, TE cleared. FI was also cleared
>>>> The A7 wanted to write the very same value. I tried to set bit 21,
>>>> which
>>>> kind of the A7 TRM hints to do: but no change.
>>>> Before the HSCLTR write, the register reads 0x30c50878, with SCTLR
>>>> being
>>>> 0x30c5387d.
>>>> So the code wants to set M, A, C and I in HSCLTR. Interestingly SCTLR
>>>> has
>>>> the V bits set, could that be an issue?
>>>>
>>> Can you try writing 0x30c50879 into the register instead? Basically
>>> check to see if enabling caches or alignment checks causes the issue,
>>> or if it is indeed enabling the MMU that's the issue... If that works,
>>> start a bisect on the remaining bits. Also, just for fun, could you
>>> try flushing the entire I-cache before writing into the HSCLTR?
>> 
>> OK, both clearing the I-bit and doing an "isb; ICIALLU" before the
"isb; 
>> write HSCLTR; isb" worked, the kernel boots on and KVM is enabled.
>> 
>> I could easily make a patch, but I am not sure how to proceed from
here:
>> 
>> 1.) At least I don't have an understanding why this is only a problem
on 
>> A7 and not on A15. I would feel better if we have an explanation for 
>> this. Mark, Will, Peter: any ideas?
> 
> Blink!
> 
> Can you check your board.txt config file? It should have a line that
> starts with "SCC: 0x400 ..."
> 
> If not, can you add a line that reads:
> SCC: 0x400 0x00000000

Actually you, may want to try:
SCC: 0x400 0x3330c00

instead, as Peter pointed out that some bits are flagged as reserved in
the TRM...

        M.

-- 
Fast, cheap, reliable. Pick two.


From mark.rutland at arm.com  Mon Apr 22 07:14:53 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Mon, 22 Apr 2013 12:14:53 +0100
Subject: [PATCH 4/4] arm64: Add initial DTS for APM X-Gene Storm SOC
 and APM Mustang board
In-Reply-To: <1366442131-26094-5-git-send-email-vkale@apm.com>
References: <1366442131-26094-1-git-send-email-vkale@apm.com>
 <1366442131-26094-5-git-send-email-vkale@apm.com>
Message-ID: <20130422111453.GA3791@e106331-lin.cambridge.arm.com>

Hi,

I have a couple of minor comments on the dts:

> diff --git a/arch/arm64/boot/dts/storm.dtsi b/arch/arm64/boot/dts/storm.dtsi
> new file mode 100644
> index 0000000..8cab5d1
> --- /dev/null
> +++ b/arch/arm64/boot/dts/storm.dtsi
> @@ -0,0 +1,116 @@
> +/*
> + * dts file for AppliedMicro (APM) X-Gene Storm SOC
> + *
> + * Copyright (C) 2013, Applied Micro Circuits Corporation
> + *
> + * 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.
> + */
> +
> +/ {
> +	compatible = "apm,xgene,storm", "apm,xgene";
> +	interrupt-parent = <&gic>;
> +	#address-cells = <2>;
> +	#size-cells = <2>;
> +
> +	cpus {
> +		#address-cells = <1>;

The reg is 64-bit, so address-cells should be 2.

> +		#size-cells = <0>;
> +
> +		cpu at 0 {
> +			device_type = "cpu";
> +			compatible = "arm,armv8";

It might be good to also have a compatible string for the X-Gene's CPU
implementation, e.g.

compatible = "apm,xgene-cpu", "arm,armv8";

> +			reg = <0x0 0x0000>;
> +			enable-method = "spin-table";
> +			cpu-release-addr = <0x1 0x0000fff8>;
> +		};
> +		cpu at 1 {
> +			device_type = "cpu";
> +			compatible = "arm,armv8";
> +			reg = <0x0 0x0001>;
> +			enable-method = "spin-table";
> +			cpu-release-addr = <0x1 0x0000fff8>;
> +		};
> +		cpu at 2 {
> +			device_type = "cpu";
> +			compatible = "arm,armv8";
> +			reg = <0x0 0x0100>;
> +			enable-method = "spin-table";
> +			cpu-release-addr = <0x1 0x0000fff8>;
> +		};

This should be cpu at 101 to match the reg property (and the following nodes
should be fixed up similarly).

> +		cpu at 3 {
> +			device_type = "cpu";
> +			compatible = "arm,armv8";
> +			reg = <0x0 0x0101>;
> +			enable-method = "spin-table";
> +			cpu-release-addr = <0x1 0x0000fff8>;
> +		};
> +		cpu at 4 {
> +			device_type = "cpu";
> +			compatible = "arm,armv8";
> +			reg = <0x0 0x0200>;
> +			enable-method = "spin-table";
> +			cpu-release-addr = <0x1 0x0000fff8>;
> +		};
> +		cpu at 5 {
> +			device_type = "cpu";
> +			compatible = "arm,armv8";
> +			reg = <0x0 0x0201>;
> +			enable-method = "spin-table";
> +			cpu-release-addr = <0x1 0x0000fff8>;
> +		};
> +		cpu at 6 {
> +			device_type = "cpu";
> +			compatible = "arm,armv8";
> +			reg = <0x0 0x0300>;
> +			enable-method = "spin-table";
> +			cpu-release-addr = <0x1 0x0000fff8>;
> +		};
> +		cpu at 7 {
> +			device_type = "cpu";
> +			compatible = "arm,armv8";
> +			reg = <0x0 0x0301>;
> +			enable-method = "spin-table";
> +			cpu-release-addr = <0x1 0x0000fff8>;
> +		};
> +	};

[...]

Thanks,
Mark.


From thomas.abraham at linaro.org  Mon Apr 22 07:35:06 2013
From: thomas.abraham at linaro.org (Thomas Abraham)
Date: Mon, 22 Apr 2013 17:05:06 +0530
Subject: [PATCH v2 0/2] ARM: Exynos: Add DT based I/O mapping for Chip-ID
 controller
Message-ID: <1366630508-26101-1-git-send-email-thomas.abraham@linaro.org>

Changes since v1:
- Rebased to v3.9-rc8

This patch series allows device tree enabled platforms to setup a runtime
I/O mapping for the chip-id controller. This helps to remove statically
defined I/O mapping for the Chip-ID controller. This series is based on
linux-next master branch and tested for Exynos4210, Exynos5250 and
Exynos5440.

Thomas Abraham (2):
  ARM: Exynos: Create virtual I/O mapping for Chip-ID controller using device tree
  ARM: dts: Add chip-id controller node on Exynos4/5 SoC



From thomas.abraham at linaro.org  Mon Apr 22 07:35:07 2013
From: thomas.abraham at linaro.org (Thomas Abraham)
Date: Mon, 22 Apr 2013 17:05:07 +0530
Subject: [PATCH v2 1/2] ARM: Exynos: Create virtual I/O mapping for Chip-ID
 controller using device tree
In-Reply-To: <1366630508-26101-1-git-send-email-thomas.abraham@linaro.org>
References: <1366630508-26101-1-git-send-email-thomas.abraham@linaro.org>
Message-ID: <1366630508-26101-2-git-send-email-thomas.abraham@linaro.org>

On device tree enabled exynos platforms, retrieve the physical base address
of the chip-id controller from device tree and create a virtual I/O mapping
for the chip-id controller. This helps to remove the chip-id controller entry
from the statically defined I/O mapping tables.

Cc: Kukjin Kim <kgene.kim at samsung.com>
Signed-off-by: Thomas Abraham <thomas.abraham at linaro.org>
---
 arch/arm/mach-exynos/common.c           |   53 +++++++++++++++++-------------
 arch/arm/mach-exynos/include/mach/map.h |    1 -
 2 files changed, 30 insertions(+), 24 deletions(-)

diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
index 8419190..64ef39e 100644
--- a/arch/arm/mach-exynos/common.c
+++ b/arch/arm/mach-exynos/common.c
@@ -120,17 +120,6 @@ static struct map_desc exynos_iodesc[] __initdata = {
 	},
 };
 
-#ifdef CONFIG_ARCH_EXYNOS5
-static struct map_desc exynos5440_iodesc[] __initdata = {
-	{
-		.virtual	= (unsigned long)S5P_VA_CHIPID,
-		.pfn		= __phys_to_pfn(EXYNOS5440_PA_CHIPID),
-		.length		= SZ_4K,
-		.type		= MT_DEVICE,
-	},
-};
-#endif
-
 static struct map_desc exynos4_iodesc[] __initdata = {
 	{
 		.virtual	= (unsigned long)S3C_VA_SYS,
@@ -348,6 +337,31 @@ void __init exynos_init_late(void)
 	exynos_pm_late_initcall();
 }
 
+#ifdef CONFIG_OF
+int __init exynos_fdt_map_chipid(unsigned long node, const char *uname,
+					int depth, void *data)
+{
+	struct map_desc iodesc;
+	__be32 *reg;
+	unsigned long len;
+
+	if (!of_flat_dt_is_compatible(node, "samsung,exynos4210-chipid") &&
+		!of_flat_dt_is_compatible(node, "samsung,exynos5440-clock"))
+		return 0;
+
+	reg = of_get_flat_dt_prop(node, "reg", &len);
+	if (reg == NULL || len != (sizeof(unsigned long) * 2))
+		return 0;
+
+	iodesc.pfn = __phys_to_pfn(be32_to_cpu(reg[0]));
+	iodesc.length = be32_to_cpu(reg[1]) - 1;
+	iodesc.virtual = (unsigned long)S5P_VA_CHIPID;
+	iodesc.type = MT_DEVICE;
+	iotable_init(&iodesc, 1);
+	return 1;
+}
+#endif
+
 /*
  * exynos_map_io
  *
@@ -356,19 +370,12 @@ void __init exynos_init_late(void)
 
 void __init exynos_init_io(struct map_desc *mach_desc, int size)
 {
-	struct map_desc *iodesc = exynos_iodesc;
-	int iodesc_sz = ARRAY_SIZE(exynos_iodesc);
-#if defined(CONFIG_OF) && defined(CONFIG_ARCH_EXYNOS5)
-	unsigned long root = of_get_flat_dt_root();
-
-	/* initialize the io descriptors we need for initialization */
-	if (of_flat_dt_is_compatible(root, "samsung,exynos5440")) {
-		iodesc = exynos5440_iodesc;
-		iodesc_sz = ARRAY_SIZE(exynos5440_iodesc);
-	}
+#ifdef CONFIG_OF
+	if (initial_boot_params)
+		of_scan_flat_dt(exynos_fdt_map_chipid, NULL);
+	else
 #endif
-
-	iotable_init(iodesc, iodesc_sz);
+		iotable_init(exynos_iodesc, ARRAY_SIZE(exynos_iodesc));
 
 	if (mach_desc)
 		iotable_init(mach_desc, size);
diff --git a/arch/arm/mach-exynos/include/mach/map.h b/arch/arm/mach-exynos/include/mach/map.h
index 99e0a79..92b29bb 100644
--- a/arch/arm/mach-exynos/include/mach/map.h
+++ b/arch/arm/mach-exynos/include/mach/map.h
@@ -56,7 +56,6 @@
 #define EXYNOS4_PA_ONENAND_DMA		0x0C600000
 
 #define EXYNOS_PA_CHIPID		0x10000000
-#define EXYNOS5440_PA_CHIPID		0x00160000
 
 #define EXYNOS4_PA_SYSCON		0x10010000
 #define EXYNOS5_PA_SYSCON		0x10050100
-- 
1.6.6.rc2



From thomas.abraham at linaro.org  Mon Apr 22 07:35:08 2013
From: thomas.abraham at linaro.org (Thomas Abraham)
Date: Mon, 22 Apr 2013 17:05:08 +0530
Subject: [PATCH v2 2/2] ARM: dts: Add chip-id controller node on Exynos4/5 SoC
In-Reply-To: <1366630508-26101-1-git-send-email-thomas.abraham@linaro.org>
References: <1366630508-26101-1-git-send-email-thomas.abraham@linaro.org>
Message-ID: <1366630508-26101-3-git-send-email-thomas.abraham@linaro.org>

Add chip-id controller nodes for Exynos4 and Exynos5 SoCs.

Cc: Kukjin Kim <kgene.kim at samsung.com>
Signed-off-by: Thomas Abraham <thomas.abraham at linaro.org>
---
 arch/arm/boot/dts/exynos4.dtsi    |    5 +++++
 arch/arm/boot/dts/exynos5250.dtsi |    5 +++++
 2 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index d73eaa1..efd441a 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -38,6 +38,11 @@
 		i2c7 = &i2c_7;
 	};
 
+	chipid at 10000000 {
+		compatible = "samsung,exynos4210-chipid";
+		reg = <0x10000000 0x100>;
+	};
+
 	pd_mfc: mfc-power-domain at 10023C40 {
 		compatible = "samsung,exynos4210-pd";
 		reg = <0x10023C40 0x20>;
diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi
index 6727eed..4bd9e9c 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -51,6 +51,11 @@
 		pinctrl3 = &pinctrl_3;
 	};
 
+	chipid at 10000000 {
+		compatible = "samsung,exynos4210-chipid";
+		reg = <0x10000000 0x100>;
+	};
+
 	pd_gsc: gsc-power-domain at 0x10044000 {
 		compatible = "samsung,exynos4210-pd";
 		reg = <0x10044000 0x20>;
-- 
1.6.6.rc2



From thomas.abraham at linaro.org  Mon Apr 22 07:20:39 2013
From: thomas.abraham at linaro.org (Thomas Abraham)
Date: Mon, 22 Apr 2013 16:50:39 +0530
Subject: [PATCH 0/2] ARM: Exynos: Add DT based I/O mapping for Chip-ID
 controller
In-Reply-To: <27ea01ce3101$a8dae850$fa90b8f0$%kim@samsung.com>
References: <1361174099-18749-1-git-send-email-thomas.abraham@linaro.org>
 <27ea01ce3101$a8dae850$fa90b8f0$%kim@samsung.com>
Message-ID: <CAJuYYwTV5U8-wqNhet4ZEdgRSnbok6-ziE-qkx4ee9j84z8xdg@mail.gmail.com>

On 4 April 2013 12:27, Kukjin Kim <kgene.kim at samsung.com> wrote:
> Thomas Abraham wrote:
>>
>> This patch series allows device tree enabled platforms to setup a runtime
>> I/O mapping for the chip-id controller. This helps to remove statically
>> defined I/O mapping for the Chip-ID controller.
>>
>> Thomas Abraham (2):
>>   ARM: Exynos: Create virtual I/O mapping for Chip-ID controller using
>> device tree
>>   ARM: dts: Add chip-id controller node on Exynos4/5 SoC
>>
>>  .../arm/samsung/samsung,exynos4210-chipid.txt      |   15 ++++++
>>  arch/arm/boot/dts/exynos4.dtsi                     |    5 ++
>>  arch/arm/boot/dts/exynos5250.dtsi                  |    5 ++
>>  arch/arm/mach-exynos/common.c                      |   53
> +++++++++++---------
>>  arch/arm/mach-exynos/include/mach/map.h            |    1 -
>>  5 files changed, 55 insertions(+), 24 deletions(-)
>>  create mode 100644
>> Documentation/devicetree/bindings/arm/samsung/samsung,exynos4210-
>> chipid.txt
>>
>> --
>> 1.7.5.4
>
> Thomas,
>
> Can you update this series can support exynos5440 as well? It should be done
> together.

Hi Mr. Kim,

Sorry for the delayed reply. This patch series is supported for
Exynos5440 as well. The v2 version of this patch series has been
submitted.

Thanks,
Thomas.

>
> - Kukjin
>


From shawn.guo at linaro.org  Mon Apr 22 07:25:35 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Mon, 22 Apr 2013 19:25:35 +0800
Subject: [PATCH] ARM i.MX6: correct MLB clock configuration
In-Reply-To: <1366610434-23042-1-git-send-email-dirk.behme@de.bosch.com>
References: <1366610434-23042-1-git-send-email-dirk.behme@de.bosch.com>
Message-ID: <20130422112534.GH10647@S2101-09.ap.freescale.net>

On Mon, Apr 22, 2013 at 08:00:34AM +0200, Dirk Behme wrote:
> From: Dirk Behme <dirk.behme at gmail.com>
> 
> According to the i.MX6 Dual/Quad technical reference manual
> (Figure 18-2. Clock Tree - Part 1) the MLB clock is directly
> feed by the AXI_CLK_ROOT. This is called 'axi' in our code.
> 
> Note that the clock of the MLB IP block on the i.MX6 is completely
> independent of the PLL8 (MLB PLL). The MLB PLL isn't responsible
> for feeding the MLB IP block with a clock. Instead, it's used
> internally by the MLB module to sync the bus clock in case the MLB
> 6-pin interface is enabled:
> 
> MediaLB Control 0 Register, MLB150_MLBC0[5], MLBPEN:
> 1 MediaLB 6-pin interface enabled. MLB PLL and MLB PHY is enabled in this case.
> 
> I.e. the PLL8 MLB PLL has to be handled by the MLB driver and isn't needed
> for clocking the MLB module itself.
> 
> Signed-off-by: Dirk Behme <dirk.behme at de.bosch.com>
> CC: Shawn Guo <shawn.guo at linaro.org>
> CC: Jiada Wang <Jiada_Wang at mentor.com>

Applied, thanks.

> ---
>  arch/arm/mach-imx/clk-imx6q.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-imx/clk-imx6q.c b/arch/arm/mach-imx/clk-imx6q.c
> index d38e54f..fd0189d 100644
> --- a/arch/arm/mach-imx/clk-imx6q.c
> +++ b/arch/arm/mach-imx/clk-imx6q.c
> @@ -399,7 +399,7 @@ int __init mx6q_clocks_init(void)
>  	clk[ldb_di1]      = imx_clk_gate2("ldb_di1",       "ldb_di1_podf",      base + 0x74, 14);
>  	clk[ipu2_di1]     = imx_clk_gate2("ipu2_di1",      "ipu2_di1_sel",      base + 0x74, 10);
>  	clk[hsi_tx]       = imx_clk_gate2("hsi_tx",        "hsi_tx_podf",       base + 0x74, 16);
> -	clk[mlb]          = imx_clk_gate2("mlb",           "pll8_mlb",          base + 0x74, 18);
> +	clk[mlb]          = imx_clk_gate2("mlb",           "axi",               base + 0x74, 18);
>  	clk[mmdc_ch0_axi] = imx_clk_gate2("mmdc_ch0_axi",  "mmdc_ch0_axi_podf", base + 0x74, 20);
>  	clk[mmdc_ch1_axi] = imx_clk_gate2("mmdc_ch1_axi",  "mmdc_ch1_axi_podf", base + 0x74, 22);
>  	clk[ocram]        = imx_clk_gate2("ocram",         "ahb",               base + 0x74, 28);
> -- 
> 1.8.2
> 



From arnd at arndb.de  Mon Apr 22 07:34:03 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 22 Apr 2013 13:34:03 +0200
Subject: [PATCH 01/23] ARM: u300: fix ages old copy/paste bug
In-Reply-To: <1366624283-6122-1-git-send-email-linus.walleij@stericsson.com>
References: <1366624283-6122-1-git-send-email-linus.walleij@stericsson.com>
Message-ID: <201304221334.04160.arnd@arndb.de>

On Monday 22 April 2013, Linus Walleij wrote:
> From: Linus Walleij <linus.walleij at linaro.org>
> 
> The UART1 is on the fast AHB bridge, not on the slow bus.
> 
> Signed-off-by: Linus Walleij <linus.walleij at linaro.org>

Do you want to mark this for stable?

While there are not a lot of people that would need the fix, I think 
we should do it by habit in cases that fit the stable rules.

Acked-by: Arnd Bergmann <arnd at arndb.de>


From arnd at arndb.de  Mon Apr 22 07:36:21 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 22 Apr 2013 13:36:21 +0200
Subject: [PATCH 03/23] ARM: u300: device tree support for the timer
In-Reply-To: <1366624304-6190-1-git-send-email-linus.walleij@stericsson.com>
References: <1366624304-6190-1-git-send-email-linus.walleij@stericsson.com>
Message-ID: <201304221336.21921.arnd@arndb.de>

On Monday 22 April 2013, Linus Walleij wrote:
> +#ifdef CONFIG_OF
> +       struct device_node *timer = NULL;
> +
> +       timer = of_find_node_by_path("/timer0 at c0014000");
> +       if (timer) {
> +               struct resource irq_res;
> +
> +               u300_timer_base = of_iomap(timer, 0);
> +               /* Get the IRQ for the GP1 timer */
> +               irq = of_irq_to_resource(timer, 2, &irq_res);
> +       }
> +#endif

Do you need the #ifdef? The functions should be defined in a way that
removes this code if CONFIG_OF is not defined.

	Arnd


From sachin.kamat at linaro.org  Mon Apr 22 07:40:05 2013
From: sachin.kamat at linaro.org (Sachin Kamat)
Date: Mon, 22 Apr 2013 17:10:05 +0530
Subject: [PATCH v3 00/10] ARM: exynos multiplatform series, part 1
In-Reply-To: <201304191536.17796.arnd@arndb.de>
References: <1365716245-99231-1-git-send-email-arnd@arndb.de>
 <201304191536.17796.arnd@arndb.de>
Message-ID: <CAK9yfHwEZUPs70j3rS7V44RWxpZShEP8uxo3fFW54=L3NG-bDA@mail.gmail.com>

Hi Arnd,

On 19 April 2013 19:06, Arnd Bergmann <arnd at arndb.de> wrote:
> On Thursday 11 April 2013, Arnd Bergmann wrote:
>> These are the patches that I would like to apply directly to
>> the arm-soc next/multiplatform branch, unless you have any
>> objections. This would get all the simple stuff out of the
>> way, and I don't think there is a big risk of introducing
>> regressions with these.
>>
>> A lot of the other patches have already been merged into
>> subsystem trees. After this series in in arm-soc, what is
>> left comes down to
>>
>> * The ASoC conversion to dmaengine won't make it unless someone
>>   who knows that code better steps up to do it right away. This
>>   means that we won't have audio in a 3.10 multiplatform kernel
>>   on Exynos, but it will still work for users that don't enable
>>   multiplatform.
>>
>> * The irqchip (combiner), clk and clksource patches are all based
>>   on top   of other changesets we pulled in from your trees, so I
>>   would not make them part of the next/multiplatform branch. We can
>>   apply them on top of the next/drivers branch once they are
>>   tested successfully.
>>
>> * A trivial patch is needed in the end to actually make
>>   CONFIG_ARCH_EXYNOS visible in multiplatform configurations.
>>   We will do that as a separate patch once everything else is
>>   there.
>>
>> Please provide an ACK so I can put this into arm-soc, or let
>> me know if I screwed up somewhere.
>
> No reply?
>
> I'm putting them into the next/multiplatform branch now, with
> the exception of the i2c patch that is already in the i2c
> tree.
>
> I've tested this on the Arndale board and am putting it into
> the next/multiplatform branch now as a stepping stone for
> part two, which will be a late branch at best, if we decide
> to merge it in 3.10.

With this branch now available (merged) in linux-next (20130422),
looks like exynos4 DT support is broken on it. Tested on Origen 4210
and 4412 and I get the following warnings on 4412 Origen board with
exynos_defconfig (Note that clocks are all 0). However, it boots fine
on Arndale board.

SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
Preemptible hierarchical RCU implementation.
NR_IRQS:549
Exynos4x12 clocks: sclk_apll = 0, sclk_mpll = 0
        sclk_epll = 0, sclk_vpll = 0, arm_clk = 0
Division by zero in kernel.
CPU: 0 PID: 0 Comm: swapper/0 Not tainted
3.9.0-rc8-next-20130422-00038-g20ff84f #50
[<c0013fc8>] (unwind_backtrace+0x0/0xf8) from [<c0010ee4>]
(show_stack+0x10/0x14)
[<c0010ee4>] (show_stack+0x10/0x14) from [<c0190704>] (Ldiv0_64+0x8/0x18)
[<c0190704>] (Ldiv0_64+0x8/0x18) from [<c00549c4>]
(__clocksource_updatefreq_scale+0x44/0x19c)
[<c00549c4>] (__clocksource_updatefreq_scale+0x44/0x19c) from
[<c0054b28>] (__clocksource_register_scale+0xc/0x44)
[<c0054b28>] (__clocksource_register_scale+0xc/0x44) from [<c04895b0>]
(exynos4_clocksource_init+0x20/0x40)
[<c04895b0>] (exynos4_clocksource_init+0x20/0x40) from [<c0489638>]
(mct_init_dt+0x68/0x74)
[<c0489638>] (mct_init_dt+0x68/0x74) from [<c0489384>]
(clocksource_of_init+0x30/0x58)
[<c0489384>] (clocksource_of_init+0x30/0x58) from [<c0473ae0>]
(time_init+0x1c/0x30)
[<c0473ae0>] (time_init+0x1c/0x30) from [<c04706a0>] (start_kernel+0x1a0/0x37c)
[<c04706a0>] (start_kernel+0x1a0/0x37c) from [<40008074>] (0x40008074)
Division by zero in kernel.


-- 
With warm regards,
Sachin


From arnd at arndb.de  Mon Apr 22 07:40:17 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 22 Apr 2013 13:40:17 +0200
Subject: [PATCH 05/23] pinctrl: coh901: add device tree support
In-Reply-To: <1366624326-6259-1-git-send-email-linus.walleij@stericsson.com>
References: <1366624326-6259-1-git-send-email-linus.walleij@stericsson.com>
Message-ID: <201304221340.18080.arnd@arndb.de>

On Monday 22 April 2013, Linus Walleij wrote:
> +Required properties:
> +- compatible: Compatible property value should be "stericsson,gpio-coh901"
> +- reg: Physical base address of the controller and length of memory mapped
> +  region.
> +- interrupts: the 0...n interrupts assigned to the different GPIO ports/banks.
> +- interrupt-names: name the interrupts after port/bank, "gpio0", "gpio1" etc.
> +

I think it would be better to leave out the interrupt-names in this case, since
the name directly corresponds to the index, so there is no ambiguity.

	Arnd


From arnd at arndb.de  Mon Apr 22 07:44:00 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 22 Apr 2013 13:44:00 +0200
Subject: [PATCH 06/23] ARM: u300: basic device tree support
In-Reply-To: <1366624340-6293-1-git-send-email-linus.walleij@stericsson.com>
References: <1366624340-6293-1-git-send-email-linus.walleij@stericsson.com>
Message-ID: <201304221344.00422.arnd@arndb.de>

On Monday 22 April 2013, Linus Walleij wrote:
> +/ {

We don't really care about the device node names in Linux, but please use the
common ones, without any trailing digits:

> +	timer: timer0 at c0014000 {
> +		compatible = "stericsson,u300-apptimer";
> +		reg = <0xc0014000 0x1000>;
> +		interrupt-parent = <&vica>;
> +		interrupts = <24 25 26 27>;
> +	};

timer at c0014000

> +
> +	gpio: gpio0 at c0016000 {
> +		compatible = "stericsson,gpio-coh901";
> +		reg = <0xc0016000 0x1000>;


gpio at c0016000

> +	pinctrl: pinctrl0 at c0011000 {
> +		compatible = "stericsson,pinctrl-u300";
> +		reg = <0xc0011000 0x1000>;
> +	};

pinctrl at c0011000

> +		vica: intc at 0xa0001000 {
> +			compatible = "arm,versatile-vic";
> +			interrupt-controller;
> +			#interrupt-cells = <1>;
> +			reg = <0xa0001000 0x20>;
> +		};

interrupt-controller at a0001000

Note also the erroneous 0x part you have in the name here.

> +		uart0: uart at c0013000 {
> +			compatible = "arm,pl011", "arm,primecell";
> +			reg = <0xc0013000 0x1000>;
> +			interrupt-parent = <&vica>;
> +			interrupts = <22>;
> +		};

serial at c0013000

	Arnd


From wsa at the-dreams.de  Mon Apr 22 07:50:17 2013
From: wsa at the-dreams.de (Wolfram Sang)
Date: Mon, 22 Apr 2013 13:50:17 +0200
Subject: [PATCH 07/23] i2c: stu300: device tree support
In-Reply-To: <1366624383-6330-1-git-send-email-linus.walleij@stericsson.com>
References: <1366624383-6330-1-git-send-email-linus.walleij@stericsson.com>
Message-ID: <20130422115016.GA3930@the-dreams.de>

On Mon, Apr 22, 2013 at 11:53:03AM +0200, Linus Walleij wrote:
> From: Linus Walleij <linus.walleij at linaro.org>
> 
> This adds device tree support for the ST DDC I2C driver known
> as "stu300" in the kernel tree.
> 
> Cc: Wolfram Sang <wsa at the-dreams.de>
> Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
> ---
> Wolfram, I'm seeking an ACK to take this with the other lump
> of U300 device tree patches through the ARM SoC tree.

Reviewed-by: Wolfram Sang <wsa at the-dreams.de>



From balbi at ti.com  Mon Apr 22 07:52:43 2013
From: balbi at ti.com (Felipe Balbi)
Date: Mon, 22 Apr 2013 14:52:43 +0300
Subject: linux-next ARM multi-platform randconfig errors
In-Reply-To: <20130422082149.GK10536@arwen.pp.htv.fi>
References: <5170B4C6.1030300@gmail.com> <20130419161257.GI10155@atomide.com>
 <5174E58D.8080800@ti.com> <20130422082149.GK10536@arwen.pp.htv.fi>
Message-ID: <20130422115243.GD10797@arwen.pp.htv.fi>

Hi,

On Mon, Apr 22, 2013 at 11:21:49AM +0300, Felipe Balbi wrote:
> > -Kevin Hilman <khilman at ti.com>
> > +Kevin Hilman <khilman at deeprootsystems.com>
> > 
> > On 04/19/2013 07:12 PM, Tony Lindgren wrote:
> > > * Rob Herring <robherring2 at gmail.com> [130418 20:11]:
> > >> Current errors in linux-next for ARM multi-platform randconfig builds.
> > >>
> > >> Rob
> > >>
> > >> arch/arm/mach-omap2/built-in.o:dss-common.c:(.init.text+0x6830): more undefined references to `usb_bind_phy' follow
> > > 
> > > Felipe & Roger, can you guys take a look at the usb_bind_phy issue
> > > in linux next? I have not seen that in the multiplatform randconfigs
> > > I've built, but I have had some omap2+ specific things enabled there.
> > 
> > These problems happen if USB_PHY is not enabled as a built-in driver.
> > I had pointed this out earlier [1] and Felipe should have a fix for it.
> 
> yeah, ideally we wouldn't do any 'select' and just update defconfig with
> the necessary changes. We need the patch below to update defconfig and
> another patch to stub out usb_bind_phy when !USB_PHY.

the stub is already there, this should fix the other part though:

8< --------------- cut here ----------------------

From b2ead0f71d62ff896bd035c92f1216dba4eb3385 Mon Sep 17 00:00:00 2001
From: Felipe Balbi <balbi at ti.com>
Date: Mon, 22 Apr 2013 14:50:56 +0300
Subject: [PATCH] usb: phy: remove bogus __init annotation

there's no guarantee that usb_bind_phy() will
always be called from initialization time.

Leaving that __init section annotation leads
to undefined references build errors. Remove it.

Signed-off-by: Felipe Balbi <balbi at ti.com>
---
 drivers/usb/phy/phy.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/phy/phy.c b/drivers/usb/phy/phy.c
index f52c006..a9984c7 100644
--- a/drivers/usb/phy/phy.c
+++ b/drivers/usb/phy/phy.c
@@ -413,7 +413,7 @@ EXPORT_SYMBOL_GPL(usb_remove_phy);
  *
  * To be used by platform specific initialization code.
  */
-int __init usb_bind_phy(const char *dev_name, u8 index,
+int usb_bind_phy(const char *dev_name, u8 index,
 				const char *phy_dev_name)
 {
 	struct usb_phy_bind *phy_bind;
-- 
1.8.2


-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130422/037a93b9/attachment-0001.sig>

From arnd at arndb.de  Mon Apr 22 08:04:31 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 22 Apr 2013 14:04:31 +0200
Subject: [PATCH v3] irqchip: Add support for ARMv7-M's NVIC
In-Reply-To: <20130422100219.GH15233@pengutronix.de>
References: <1366214540-31166-1-git-send-email-u.kleine-koenig@pengutronix.de>
 <20130419150927.GE15233@pengutronix.de>
 <20130422100219.GH15233@pengutronix.de>
Message-ID: <201304221404.31281.arnd@arndb.de>

On Monday 22 April 2013, Uwe Kleine-K?nig wrote:
> Hello,
> 
> (for the new readers of this thread: This is about using
> 
> 	u32 mask = 1 << (d->hwirq % 32);
> 
> instead of
> 
> 	u32 mask = 1 << (d->irq - gc->irq_base);

While not technically any different, I would suggest writing the above
as (d->hwirq & 0x1f), which makes it clear to the reader that this is
intended to be a cheap bit mask operation rather than an expensive
division.
> 
> arch/arm/mach-s5p64x0/common.c
> 	-> uses irq_base=101 for irq_alloc_generic_chip

I think there are plans to replace this code with
drivers/pinctrl/pinctrl-samsung.c, but I don't know if patches
exist already.

> arch/arm/plat-orion/gpio.c
> 	-> depends on how orion_gpio_of_init is called. No callers
> 	found.

As of f9e7592230b, this code has been replaced with a pinctrl driver
and can be killed.

> arch/arm/plat-orion/irq.c
> arch/arm/plat-samsung/irq-vic-timer.c
> 	-> used for a single irq that isn't a multiple of 32

Tomasz Figa has a patch set to remove this file, will likely get merged
in 3.11.

> arch/arm/plat-samsung/s5p-irq-gpioint.c
> 	-> would need % 8?

AFAICT this code is the same driver as arch/arm/mach-s5p64x0/common.c
and will meet the same fate.

> arch/sh/boards/mach-se/7343/irq.c
> 	-> uses irq_base = irq_linear_revmap(se7343_irq_domain, 0) where
> 	se7343_irq_domain is a linear domain.
> 	AFAICT this is a bug. (After adding the domain they map all irqs
> 	in increasing order which currently seems to guarantee that it
> 	works. But IMHO it should use a legacy domain.)
> 
> arch/sh/boards/mach-se/7722/irq.c
> 	as above.

Right. I think irq_domain_add_simple() is the right interface to use
here.

> For the uncommented files using %32 instead of -gc->irq_base should
> work.

I'm not sure I understand why this doesn't work for the ones that use
a base that isn't a multiple of 32. Since you are masking the hwirq
rather than the irq number, it will still be zero-based, won't it?

	Arnd


From grygorii.strashko at ti.com  Mon Apr 22 08:21:28 2013
From: grygorii.strashko at ti.com (Grygorii Strashko)
Date: Mon, 22 Apr 2013 15:21:28 +0300
Subject: Multiple issues with omap4 panda es in linux next
In-Reply-To: <51750FF8.6000401@ti.com>
References: <20130419171318.GK10155@atomide.com> <5174FE16.6080307@ti.com>
 <51750FF8.6000401@ti.com>
Message-ID: <51752B48.50700@ti.com>

On 04/22/2013 01:24 PM, Tomi Valkeinen wrote:
> On 2013-04-22 12:08, Tomi Valkeinen wrote:
>> On 2013-04-19 20:13, Tony Lindgren wrote:
>>
>>> 3. DSS fails with DT booting
>>>
>>> Works with legacy booting but fails with DT. I'm almost certain
>>> the DT booting was working last week or so?
>>>
>>> This is what I now get with DT booting:
>>>
>>> omapdss DSI error: can't get VDDS_DSI regulator
>>> omapdss HDMI error: can't get VDDA_HDMI_DAC regulator
>>> omapdss HDMI error: device hdmi init failed: -517
>>> omapdss CORE error: driver probe failed: -22
>>> ...
>> I think this is the issue Christoph Fritz reported earlier, DSS is being
>> initialized before TWL, and thus DSS doesn't find the regulators.
>>
>> The proper fix is of course to make DSS support EPROBE_DEFER, but that's
>> easier said than done. I'll have a look if I can get it working enough
>> to fix this issue.
> Yes, it seems delayed regulator initialization brought up this issue.
>
> I hacked DSI driver of omapdss and Taal panel driver to somewhat work
> with EPROBE_DEFER. But then the issue was with omapfb.
>
> omapfb is currently set to start at late_initcall, so that omapdss and
> panels are loaded before omapfb. But even that's not late enough to get
> the regulators for omapdss. It seems the regulators get also initialized
> at the late_initcall level. Changing omapfb to late_initcall_sync was
> late enough to get things working.
>
> Again, making omapdss, panel drivers and omapfb support EPROBE_DEFER and
> dynamic panel driver insertion is the proper fix, but it's a big job,
> and there are "interesting" issues with it (like how to know if a panel
> device will ever get a driver loaded).
>
> But is there something wrong with the TWL and regulators? late_initcall
> sounds rather late for such a core resource. Even if all drivers
> supported EPROBE_DEFER, won't it cause extra delays in the boot as
> drivers are getting probed multiple times?
>
> As for fixing the DSS problem for 3.10, I don't have any ideas except
> pure hacks. I'll continue studying this.
Hi Tomi,
twl is not initialized because of I2C,
I2C is not initialized because of pinctrl-single,
pinctrl-single is initialized at mudule/device init time.
So, most everything will be shifted at late_initcall time.

Hack that sequence is here - https://patchwork.kernel.org/patch/2444501/


>
>   Tomi
>
>



From david.andrey at netmodule.com  Mon Apr 22 08:22:41 2013
From: david.andrey at netmodule.com (David Andrey)
Date: Mon, 22 Apr 2013 14:22:41 +0200
Subject: [PATCH] clk: remove clock notifier at unregister
Message-ID: <1366633361-28887-1-git-send-email-david.andrey@netmodule.com>

Clock notifier node is now removed from the
notifier list during unregister

Signed-off-by: David Andrey <david.andrey at netmodule.com>
Acked-by: Martin Meuli <martin.meuli at netmodule.com>
---
 drivers/clk/clk.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 20ce67f..eb66434 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -1941,7 +1941,10 @@ int clk_notifier_unregister(struct clk *clk, struct notifier_block *nb)
 
 		/* XXX the notifier code should handle this better */
 		if (!cn->notifier_head.head) {
+			if (clk->notifier_count)
+				BUG();
 			srcu_cleanup_notifier_head(&cn->notifier_head);
+			list_del(&cn->node);
 			kfree(cn);
 		}
 
-- 
1.7.4.1



From vkale at apm.com  Mon Apr 22 08:23:51 2013
From: vkale at apm.com (Vinayak Kale)
Date: Mon, 22 Apr 2013 17:53:51 +0530
Subject: [PATCH 4/4] arm64: Add initial DTS for APM X-Gene Storm SOC and
 APM Mustang board
In-Reply-To: <20130422111453.GA3791@e106331-lin.cambridge.arm.com>
References: <1366442131-26094-1-git-send-email-vkale@apm.com>
 <1366442131-26094-5-git-send-email-vkale@apm.com>
 <20130422111453.GA3791@e106331-lin.cambridge.arm.com>
Message-ID: <CAPrCYkezfig2Drr+_dQpt7DxLRWt-v93o8hfS_ghcizussPq0w@mail.gmail.com>

On Mon, Apr 22, 2013 at 4:44 PM, Mark Rutland <mark.rutland at arm.com> wrote:
> Hi,
>
> I have a couple of minor comments on the dts:
>
>> diff --git a/arch/arm64/boot/dts/storm.dtsi b/arch/arm64/boot/dts/storm.dtsi
>> new file mode 100644
>> index 0000000..8cab5d1
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/storm.dtsi
>> @@ -0,0 +1,116 @@
>> +/*
>> + * dts file for AppliedMicro (APM) X-Gene Storm SOC
>> + *
>> + * Copyright (C) 2013, Applied Micro Circuits Corporation
>> + *
>> + * 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.
>> + */
>> +
>> +/ {
>> +     compatible = "apm,xgene,storm", "apm,xgene";
>> +     interrupt-parent = <&gic>;
>> +     #address-cells = <2>;
>> +     #size-cells = <2>;
>> +
>> +     cpus {
>> +             #address-cells = <1>;
>
> The reg is 64-bit, so address-cells should be 2.
>
Please see my comment below regarding 'reg' property & cpu node naming.
>> +             #size-cells = <0>;
>> +
>> +             cpu at 0 {
>> +                     device_type = "cpu";
>> +                     compatible = "arm,armv8";
>
> It might be good to also have a compatible string for the X-Gene's CPU
> implementation, e.g.
>
> compatible = "apm,xgene-cpu", "arm,armv8";
>
Okay, will add a compatible string for APM-Xgene.
>> +                     reg = <0x0 0x0000>;
>> +                     enable-method = "spin-table";
>> +                     cpu-release-addr = <0x1 0x0000fff8>;
>> +             };
>> +             cpu at 1 {
>> +                     device_type = "cpu";
>> +                     compatible = "arm,armv8";
>> +                     reg = <0x0 0x0001>;
>> +                     enable-method = "spin-table";
>> +                     cpu-release-addr = <0x1 0x0000fff8>;
>> +             };
>> +             cpu at 2 {
>> +                     device_type = "cpu";
>> +                     compatible = "arm,armv8";
>> +                     reg = <0x0 0x0100>;
>> +                     enable-method = "spin-table";
>> +                     cpu-release-addr = <0x1 0x0000fff8>;
>> +             };
>
> This should be cpu at 101 to match the reg property (and the following nodes
> should be fixed up similarly).
>
I would like to keep the cpu numbering as is (0 to 7). It helps the
boot-loader to iterate over cpu nodes based on logical numbers to do
fix-ups. Also here 'reg' property is not holding an address instead it
contains value to be compared with mpidr_el1.
>> +             cpu at 3 {
>> +                     device_type = "cpu";
>> +                     compatible = "arm,armv8";
>> +                     reg = <0x0 0x0101>;
>> +                     enable-method = "spin-table";
>> +                     cpu-release-addr = <0x1 0x0000fff8>;
>> +             };
>> +             cpu at 4 {
>> +                     device_type = "cpu";
>> +                     compatible = "arm,armv8";
>> +                     reg = <0x0 0x0200>;
>> +                     enable-method = "spin-table";
>> +                     cpu-release-addr = <0x1 0x0000fff8>;
>> +             };
>> +             cpu at 5 {
>> +                     device_type = "cpu";
>> +                     compatible = "arm,armv8";
>> +                     reg = <0x0 0x0201>;
>> +                     enable-method = "spin-table";
>> +                     cpu-release-addr = <0x1 0x0000fff8>;
>> +             };
>> +             cpu at 6 {
>> +                     device_type = "cpu";
>> +                     compatible = "arm,armv8";
>> +                     reg = <0x0 0x0300>;
>> +                     enable-method = "spin-table";
>> +                     cpu-release-addr = <0x1 0x0000fff8>;
>> +             };
>> +             cpu at 7 {
>> +                     device_type = "cpu";
>> +                     compatible = "arm,armv8";
>> +                     reg = <0x0 0x0301>;
>> +                     enable-method = "spin-table";
>> +                     cpu-release-addr = <0x1 0x0000fff8>;
>> +             };
>> +     };
>
> [...]
>
> Thanks,
> Mark.


From sergei.shtylyov at cogentembedded.com  Mon Apr 22 08:27:06 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Mon, 22 Apr 2013 16:27:06 +0400
Subject: [PATCH] ARM: shmobile: lager: Add GPIO LEDs
In-Reply-To: <1366599990-31751-1-git-send-email-horms+renesas@verge.net.au>
References: <1366599990-31751-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <51752C9A.2040508@cogentembedded.com>

Hello.

On 22-04-2013 7:06, Simon Horman wrote:

> The board has 3 LEDs connected to GPIOs. Add a led-gpio device to
> support them.

> Based on "ARM: shmobile: marzen: Add GPIO LEDs" by Laurent Pinchart.

> Cc: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
> Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
> ---
>   arch/arm/mach-shmobile/board-lager.c | 37 ++++++++++++++++++++++++++++++++++++
>   1 file changed, 37 insertions(+)

> Tested on lager board.
> Based on the tag renesas-next-20130419 of my renesas tree.

> diff --git a/arch/arm/mach-shmobile/board-lager.c b/arch/arm/mach-shmobile/board-lager.c
> index 6114edd..a8aa04f 100644
> --- a/arch/arm/mach-shmobile/board-lager.c
> +++ b/arch/arm/mach-shmobile/board-lager.c
[...]
> @@ -46,6 +82,7 @@ static void __init lager_add_standard_devices(void)
>   	r8a7790_pinmux_init();
>
>   	r8a7790_add_standard_devices();
> +	platform_add_devices(lager_devices, ARRAY_SIZE(lager_devices));

    I thought we shouldn't use platform_add_devices() anymore, being close 
relative to platform_device_register()?

WBR, Sergei



From nschichan at freebox.fr  Mon Apr 22 08:31:20 2013
From: nschichan at freebox.fr (Nicolas Schichan)
Date: Mon, 22 Apr 2013 14:31:20 +0200
Subject: [PATCH V2 1/3] seccomp: add generic code for jitted seccomp
 filters.
In-Reply-To: <20130417145628.88058f0f3104ab9ae551ddd3@linux-foundation.org>
References: <1363618233-6375-1-git-send-email-nschichan@freebox.fr>
 <1363618233-6375-2-git-send-email-nschichan@freebox.fr>
 <20130417145628.88058f0f3104ab9ae551ddd3@linux-foundation.org>
Message-ID: <51752D98.8070709@freebox.fr>

On 04/17/2013 11:56 PM, Andrew Morton wrote:
> This patch is killing me.
>
>> --- a/include/linux/seccomp.h
>> +++ b/include/linux/seccomp.h
>> @@ -6,6 +6,7 @@
>>   #ifdef CONFIG_SECCOMP
>>
>>   #include <linux/thread_info.h>
>> +#include <linux/filter.h>
>>   #include <asm/seccomp.h>
>
> In file included from include/linux/compat.h:18,
>                   from include/linux/filter.h:9,
>                   from include/linux/seccomp.h:9,
>                   from include/linux/sched.h:39,
>                   from arch/x86/kernel/asm-offsets.c:9:
> /usr/src/25/arch/x86/include/asm/compat.h: In function 'arch_compat_alloc_user_space':
> /usr/src/25/arch/x86/include/asm/compat.h:301: error: dereferencing pointer to incomplete type
>
> Problem is, compat.h's arch_compat_alloc_user_space() needs sched.h for
> task_struct but as you can see from the above include tree, sched.h
> includes seccomp.h and everything falls over.  The preprocessed code
> contains the definition of arch_compat_alloc_user_space() *before* the
> definition of task_struct.
>
> This is a basic x86_64 "make clean; make allmodconfig; make".

Hi,

Would including <uapi/linux/filter.h> instead of <linux/filter.h> in seccomp.h 
be an acceptable solution ?

I have tried that and (with an additional forward declaration of struct 
sk_buff) an x86_64 "make clean; make allmodconfig" run finishes succesfully.

If that's ok with you, I can resend the serie with that fix.

Regards,

-- 
Nicolas Schichan
Freebox SAS


From sergei.shtylyov at cogentembedded.com  Mon Apr 22 08:30:15 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Mon, 22 Apr 2013 16:30:15 +0400
Subject: [PATCH] ARM: shmobile: sh73a0: Use IORESOURCE_MEM_* everywhere
In-Reply-To: <1366602303-31749-1-git-send-email-horms+renesas@verge.net.au>
References: <1366602303-31749-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <51752D57.2000806@cogentembedded.com>

Hello.

On 22-04-2013 7:45, Simon Horman wrote:

> Convert code to use IORESOURCE_MEM_* macros.

    You probably meant DEFINE_RES_MEM*() here and in the subject?

> These macros were already used in this file,
> this change makes their usage consistent throughout the file.

> Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
> ---
>   arch/arm/mach-shmobile/setup-sh73a0.c | 79 ++++++-----------------------------
>   1 file changed, 13 insertions(+), 66 deletions(-)

> Based on the renesas-next-20130419 tag of my renesas tree.
> Boot tested on the kzm9g board.

> diff --git a/arch/arm/mach-shmobile/setup-sh73a0.c b/arch/arm/mach-shmobile/setup-sh73a0.c
> index 658c0ad..2ac5f2f 100644
> --- a/arch/arm/mach-shmobile/setup-sh73a0.c
> +++ b/arch/arm/mach-shmobile/setup-sh73a0.c
> @@ -244,12 +244,7 @@ static struct sh_timer_config tmu00_platform_data = {
>   };
>
>   static struct resource tmu00_resources[] = {
> -	[0] = {
> -		.name	= "TMU00",
> -		.start	= 0xfff60008,
> -		.end	= 0xfff60013,
> -		.flags	= IORESOURCE_MEM,
> -	},
> +	[0] = DEFINE_RES_MEM_NAMED(0xfff60008, 0xc, "TMU00"),
>   	[1] = {
>   		.start	= intcs_evt2irq(0x0e80), /* TMU0_TUNI00 */
>   		.flags	= IORESOURCE_IRQ,
> @@ -274,12 +269,7 @@ static struct sh_timer_config tmu01_platform_data = {
>   };
>
>   static struct resource tmu01_resources[] = {
> -	[0] = {
> -		.name	= "TMU01",
> -		.start	= 0xfff60014,
> -		.end	= 0xfff6001f,
> -		.flags	= IORESOURCE_MEM,
> -	},
> +	[0] = DEFINE_RES_MEM_NAMED(0xfff60014, 0xc, "TMU00"),
>   	[1] = {
>   		.start	= intcs_evt2irq(0x0ea0), /* TMU0_TUNI01 */
>   		.flags	= IORESOURCE_IRQ,
> @@ -297,12 +287,7 @@ static struct platform_device tmu01_device = {
>   };
>
>   static struct resource i2c0_resources[] = {
> -	[0] = {
> -		.name	= "IIC0",
> -		.start	= 0xe6820000,
> -		.end	= 0xe6820425 - 1,
> -		.flags	= IORESOURCE_MEM,
> -	},
> +	[0] = DEFINE_RES_MEM_NAMED(0xe6820000, 0x426, "IIC0"),
>   	[1] = {
>   		.start	= gic_spi(167),
>   		.end	= gic_spi(170),
> @@ -311,12 +296,7 @@ static struct resource i2c0_resources[] = {
>   };
>
>   static struct resource i2c1_resources[] = {
> -	[0] = {
> -		.name	= "IIC1",
> -		.start	= 0xe6822000,
> -		.end	= 0xe6822425 - 1,
> -		.flags	= IORESOURCE_MEM,
> -	},
> +	[0] = DEFINE_RES_MEM_NAMED(0xe6822000, 0x426, "IIC1"),
>   	[1] = {
>   		.start	= gic_spi(51),
>   		.end	= gic_spi(54),
> @@ -325,12 +305,7 @@ static struct resource i2c1_resources[] = {
>   };
>
>   static struct resource i2c2_resources[] = {
> -	[0] = {
> -		.name	= "IIC2",
> -		.start	= 0xe6824000,
> -		.end	= 0xe6824425 - 1,
> -		.flags	= IORESOURCE_MEM,
> -	},
> +	[0] = DEFINE_RES_MEM_NAMED(0xe6824000, 0x426, "IIC2"),
>   	[1] = {
>   		.start	= gic_spi(171),
>   		.end	= gic_spi(174),
> @@ -339,12 +314,7 @@ static struct resource i2c2_resources[] = {
>   };
>
>   static struct resource i2c3_resources[] = {
> -	[0] = {
> -		.name	= "IIC3",
> -		.start	= 0xe6826000,
> -		.end	= 0xe6826425 - 1,
> -		.flags	= IORESOURCE_MEM,
> -	},
> +	[0] = DEFINE_RES_MEM_NAMED(0xe6826000, 0x426, "IIC3"),
>   	[1] = {
>   		.start	= gic_spi(183),
>   		.end	= gic_spi(186),
> @@ -353,12 +323,7 @@ static struct resource i2c3_resources[] = {
>   };
>
>   static struct resource i2c4_resources[] = {
> -	[0] = {
> -		.name	= "IIC4",
> -		.start	= 0xe6828000,
> -		.end	= 0xe6828425 - 1,
> -		.flags	= IORESOURCE_MEM,
> -	},
> +	[0] = DEFINE_RES_MEM_NAMED(0xe6828000, 0x426, "IIC4"),
>   	[1] = {
>   		.start	= gic_spi(187),
>   		.end	= gic_spi(190),
> @@ -579,12 +544,7 @@ static struct sh_dmae_pdata sh73a0_dmae_platform_data = {
>   };
>
>   static struct resource sh73a0_dmae_resources[] = {
> -	{
> -		/* Registers including DMAOR and channels including DMARSx */
> -		.start  = 0xfe000020,
> -		.end    = 0xfe008a00 - 1,
> -		.flags  = IORESOURCE_MEM,
> -	},
> +	DEFINE_RES_MEM(0xfe000020, 0x89e0),
>   	{
>   		.name	= "error_irq",
>   		.start  = gic_spi(129),
> @@ -683,18 +643,10 @@ static struct sh_dmae_pdata sh73a0_mpdma_platform_data = {
>
>   /* Resource order important! */
>   static struct resource sh73a0_mpdma_resources[] = {
> -	{
> -		/* Channel registers and DMAOR */
> -		.start	= 0xec618020,
> -		.end	= 0xec61828f,
> -		.flags	= IORESOURCE_MEM,
> -	},
> -	{
> -		/* DMARSx */
> -		.start	= 0xec619000,
> -		.end	= 0xec61900b,
> -		.flags	= IORESOURCE_MEM,
> -	},
> +	/* Channel registers and DMAOR */
> +	DEFINE_RES_MEM(0xec618020, 0x270),
> +	/* DMARSx */
> +	DEFINE_RES_MEM(0xec619000, 0xc),
>   	{
>   		.name	= "error_irq",
>   		.start	= gic_spi(181),
> @@ -741,12 +693,7 @@ static struct platform_device pmu_device = {
>
>   /* an IPMMU module for ICB */
>   static struct resource ipmmu_resources[] = {
> -	[0] = {
> -		.name	= "IPMMU",
> -		.start	= 0xfe951000,
> -		.end	= 0xfe9510ff,
> -		.flags	= IORESOURCE_MEM,
> -	},
> +	DEFINE_RES_MEM_NAMED(0xfe951000, 0x100, "IPMMU"),
>   };
>
>   static const char * const ipmmu_dev_names[] = {

WBR, Sergei



From arnd at arndb.de  Mon Apr 22 08:32:47 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 22 Apr 2013 14:32:47 +0200
Subject: [PATCH 19/23] ARM: u300: add the COH 901 318 DMAC to device tree
In-Reply-To: <1366624779-6820-1-git-send-email-linus.walleij@stericsson.com>
References: <1366624779-6820-1-git-send-email-linus.walleij@stericsson.com>
Message-ID: <201304221432.47444.arnd@arndb.de>

On Monday 22 April 2013, Linus Walleij wrote:
> From: Linus Walleij <linus.walleij at linaro.org>
> 
> This adds the COH 901 318 DMA controller to the U300
> device tree. All devices now converted to device tree
> so far will start to find their DMA channels.
> 
> Note that the U300 is not yet using the device tree
> to obtain DMA channels, but this is a first step.

I think you definitely should implement the entire binding at once.
It should be really trivial for this driver, see the patch below.
I did not even build test it, but I'm sure you'll figure out the rest.

8<-----
Subject: dma: coh901318: implement of_dma_controller API

This provides a simple xlate and filter function pair for the coh901318
dma engine. Every request line is tied to one channel here, so this is
really trivial: the only information we need to pass is the channel number.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>

---
diff --git a/drivers/dma/coh901318.c b/drivers/dma/coh901318.c
index 797940e..a90ba74 100644
--- a/drivers/dma/coh901318.c
+++ b/drivers/dma/coh901318.c
@@ -1788,6 +1788,35 @@ bool coh901318_filter_id(struct dma_chan *chan, void *chan_id)
 }
 EXPORT_SYMBOL(coh901318_filter_id);
 
+struct coh901318_filter_args {
+	struct coh901318_base *base;
+	unsigned int ch_nr;
+};
+
+static bool coh901318_filter_base_and_id(struct dma_chan *chan, void *data)
+{
+	struct coh901318_filter_args *args = data;
+
+	if (&args->base->dma_slave == chan->device &&
+	    args->ch_nr == to_coh901318_chan(chan)->id)
+		return true;
+
+	return false;
+}
+
+static struct dma_chan *coh901318_xlate(struct of_phandle_args *dma_spec,
+					struct of_dma *ofdma)
+{
+	struct coh901318_filter_args args = {
+		.base = ofdma->of_dma_data,
+		.ch_nr = dma_spec->args[0],
+	};
+	dma_cap_mask_t cap;
+	dma_cap_zero(cap);
+	dma_cap_set(DMA_SLAVE, cap);
+
+	return dma_request_channel(cap, coh901318_filter_base_and_id, args);
+}
 /*
  * DMA channel allocation
  */
@@ -2735,12 +2764,18 @@ static int __init coh901318_probe(struct platform_device *pdev)
 	if (err)
 		goto err_register_memcpy;
 
+	ret = of_dma_controller_register(pdev->dev.of_node, coh901318_xlate, base);
+	if (err)
+		goto err_register_of_dma;
+
 	platform_set_drvdata(pdev, base);
 	dev_info(&pdev->dev, "Initialized COH901318 DMA on virtual base 0x%08x\n",
 		(u32) base->virtbase);
 
 	return err;
 
+ err_register_of_dma:
+	dma_async_device_unregister(&base->dma_memcpy);
  err_register_memcpy:
 	dma_async_device_unregister(&base->dma_slave);
  err_register_slave:
@@ -2752,6 +2787,7 @@ static int __exit coh901318_remove(struct platform_device *pdev)
 {
 	struct coh901318_base *base = platform_get_drvdata(pdev);
 
+	of_dma_controller_free(pdev->dev.of_node);
 	dma_async_device_unregister(&base->dma_memcpy);
 	dma_async_device_unregister(&base->dma_slave);
 	coh901318_pool_destroy(&base->pool);


From sergei.shtylyov at cogentembedded.com  Mon Apr 22 08:33:40 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Mon, 22 Apr 2013 16:33:40 +0400
Subject: [PATCH v2 0/1] Add I2C support to R8A7778/BOCK-W
In-Reply-To: <20130422045248.GO15680@verge.net.au>
References: <201304200217.32844.sergei.shtylyov@cogentembedded.com>
 <5171C4FE.9000807@cogentembedded.com> <20130422045248.GO15680@verge.net.au>
Message-ID: <51752E24.6030800@cogentembedded.com>

Hello.

On 22-04-2013 8:52, Simon Horman wrote:

>>>     Here's the patch against the Simon Horman's 'renesas.git' repo,
>>> 'renesas-next-20130417' tag and my recent yet unapplied USB patches.

>>     Sorry, it's against 'renesas-next-20130419' tag now.

> Sorry, it doesn't seem to apply cleanly on top of
> renesas-next-20130417 or renesas-next-20130419.

    It's also atop of USB the patches.

> Could you please rebase, add Morimoto-san's Acked-by and repost?

    I don't think we're in a hurry to apply this before USB patches but if you 
insist, I'll exchange these patchsets in my series and repost.

> Thanks

WBR, Sergei



From broonie at opensource.wolfsonmicro.com  Mon Apr 22 08:37:49 2013
From: broonie at opensource.wolfsonmicro.com (Mark Brown)
Date: Mon, 22 Apr 2013 13:37:49 +0100
Subject: [PATCH 13/23] regulator: ab3100: refactor probe to use IDs
In-Reply-To: <1366624634-6579-1-git-send-email-linus.walleij@stericsson.com>
References: <1366624634-6579-1-git-send-email-linus.walleij@stericsson.com>
Message-ID: <20130422123749.GJ30351@opensource.wolfsonmicro.com>

On Mon, Apr 22, 2013 at 11:57:14AM +0200, Linus Walleij wrote:

> Hi Mark, seeking an ACK on this to take it through the
> ARM SoC tree.

Since the arm-soc tree is locked down now I may as well just apply it so
it shows up in the merge window?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130422/ead68297/attachment.sig>

From sergei.shtylyov at cogentembedded.com  Mon Apr 22 08:37:33 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Mon, 22 Apr 2013 16:37:33 +0400
Subject: [PATCH v2 2/4] ARM: shmobile: r8a7779: add VIN support
In-Reply-To: <20130422045758.GP15680@verge.net.au>
References: <201304200232.33731.sergei.shtylyov@cogentembedded.com>
 <5171DD05.6020400@cogentembedded.com> <20130422045758.GP15680@verge.net.au>
Message-ID: <51752F0D.6080805@cogentembedded.com>

Hello.

On 22-04-2013 8:57, Simon Horman wrote:

>>> From: Vladimir Barinov <vladimir.barinov at cogentembedded.com>

>>> Add VIN clocks and platform devices for R8A7779 SoC; add function to register
>>> the VIN platform devices.

>>> Signed-off-by: Vladimir Barinov <vladimir.barinov at cogentembedded.com>
>>> [Sergei: added 'id' parameter check to r8a7779_add_vin_device(), renamed some
>>> variables.]
>>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

>> [...]

>>> Index: renesas/arch/arm/mach-shmobile/setup-r8a7779.c
>>> ===================================================================
>>> --- renesas.orig/arch/arm/mach-shmobile/setup-r8a7779.c
>>> +++ renesas/arch/arm/mach-shmobile/setup-r8a7779.c
>>> @@ -559,6 +559,33 @@ static struct resource ether_resources[]
>>>   	},
>>>   };
>>> +#define R8A7779_VIN(idx) \
>>> +static struct resource vin##idx##_resources[] = {		\
>>> +	DEFINE_RES_MEM(0xffc50000 + 0x1000 * (idx), 0x1000),	\
>>> +	DEFINE_RES_IRQ(gic_iid(0x5f + (idx))),			\
>>> +};								\
>>> +								\
>>> +static struct platform_device_info vin##idx##_info = {		\

>>     Hm, probably should have marked this as '__initdata'... maybe
>> the resources too.

> That doesn't seem to be the case for other devices in
> that or other shmobile files. Am I missing something
> or should numerous other devices be updated?

    If the device is registered using platform_device_register_*(), it seems 
worth marking the resources, the platfrom data and 'struct 
platform_device_info' as '__initdata' as they're copied to the memory 
allocated from heap anyway and hence not needed past the init phase...

WBR, Sergei



From srinivas.kandagatla at st.com  Mon Apr 22 08:43:24 2013
From: srinivas.kandagatla at st.com (Srinivas KANDAGATLA)
Date: Mon, 22 Apr 2013 13:43:24 +0100
Subject: [PATCH v1] ARM: do not select ARCH_VEXPRESS by default on
 ARCH_MULTI_V7
Message-ID: <1366634604-12637-1-git-send-email-srinivas.kandagatla@st.com>

From: Srinivas Kandagatla <srinivas.kandagatla at st.com>

This patch removes ARCH_VEXPRESS selection as default when ARCH_MULTI_V7
is selected. ARCH_VEXPRESS should be selected from
mach-vexpress/Kconfig.

Without this patch, any multiplatform build will have ARCH_VEXPRESS
selected, as a result all the vexpress associated dtbs are build when we
make dtbs.

Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla at st.com>
---
 arch/arm/Kconfig |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 1cacda4..e67d49d 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1014,7 +1014,6 @@ config ARCH_MULTI_V7
 	bool "ARMv7 based platforms (Cortex-A, PJ4, Scorpion, Krait)"
 	default y
 	select ARCH_MULTI_V6_V7
-	select ARCH_VEXPRESS
 	select CPU_V7
 
 config ARCH_MULTI_V6_V7
-- 
1.7.6.5



From kishon at ti.com  Mon Apr 22 08:45:25 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Mon, 22 Apr 2013 18:15:25 +0530
Subject: linux-next ARM multi-platform randconfig errors
In-Reply-To: <20130422115243.GD10797@arwen.pp.htv.fi>
References: <5170B4C6.1030300@gmail.com> <20130419161257.GI10155@atomide.com>
 <5174E58D.8080800@ti.com> <20130422082149.GK10536@arwen.pp.htv.fi>
 <20130422115243.GD10797@arwen.pp.htv.fi>
Message-ID: <517530E5.5050901@ti.com>

Hi,

On Monday 22 April 2013 05:22 PM, Felipe Balbi wrote:
> Hi,
>
> On Mon, Apr 22, 2013 at 11:21:49AM +0300, Felipe Balbi wrote:
>>> -Kevin Hilman <khilman at ti.com>
>>> +Kevin Hilman <khilman at deeprootsystems.com>
>>>
>>> On 04/19/2013 07:12 PM, Tony Lindgren wrote:
>>>> * Rob Herring <robherring2 at gmail.com> [130418 20:11]:
>>>>> Current errors in linux-next for ARM multi-platform randconfig builds.
>>>>>
>>>>> Rob
>>>>>
>>>>> arch/arm/mach-omap2/built-in.o:dss-common.c:(.init.text+0x6830): more undefined references to `usb_bind_phy' follow
>>>>
>>>> Felipe & Roger, can you guys take a look at the usb_bind_phy issue
>>>> in linux next? I have not seen that in the multiplatform randconfigs
>>>> I've built, but I have had some omap2+ specific things enabled there.
>>>
>>> These problems happen if USB_PHY is not enabled as a built-in driver.
>>> I had pointed this out earlier [1] and Felipe should have a fix for it.
>>
>> yeah, ideally we wouldn't do any 'select' and just update defconfig with
>> the necessary changes. We need the patch below to update defconfig and
>> another patch to stub out usb_bind_phy when !USB_PHY.
>
> the stub is already there, this should fix the other part though:

Denis had sent a patch for it 4 days back [1]. Lets use that instead.

Thanks
Kishon

[1] - https://patchwork.kernel.org/patch/2460691/




From mark.rutland at arm.com  Mon Apr 22 08:59:16 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Mon, 22 Apr 2013 13:59:16 +0100
Subject: [PATCH 4/4] arm64: Add initial DTS for APM X-Gene Storm SOC
 and APM Mustang board
In-Reply-To: <CAPrCYkezfig2Drr+_dQpt7DxLRWt-v93o8hfS_ghcizussPq0w@mail.gmail.com>
References: <1366442131-26094-1-git-send-email-vkale@apm.com>
 <1366442131-26094-5-git-send-email-vkale@apm.com>
 <20130422111453.GA3791@e106331-lin.cambridge.arm.com>
 <CAPrCYkezfig2Drr+_dQpt7DxLRWt-v93o8hfS_ghcizussPq0w@mail.gmail.com>
Message-ID: <20130422125916.GB3791@e106331-lin.cambridge.arm.com>

On Mon, Apr 22, 2013 at 01:23:51PM +0100, Vinayak Kale wrote:
> On Mon, Apr 22, 2013 at 4:44 PM, Mark Rutland <mark.rutland at arm.com> wrote:
> > Hi,
> >
> > I have a couple of minor comments on the dts:
> >
> >> diff --git a/arch/arm64/boot/dts/storm.dtsi b/arch/arm64/boot/dts/storm.dtsi
> >> new file mode 100644
> >> index 0000000..8cab5d1
> >> --- /dev/null
> >> +++ b/arch/arm64/boot/dts/storm.dtsi
> >> @@ -0,0 +1,116 @@
> >> +/*
> >> + * dts file for AppliedMicro (APM) X-Gene Storm SOC
> >> + *
> >> + * Copyright (C) 2013, Applied Micro Circuits Corporation
> >> + *
> >> + * 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.
> >> + */
> >> +
> >> +/ {
> >> +     compatible = "apm,xgene,storm", "apm,xgene";
> >> +     interrupt-parent = <&gic>;
> >> +     #address-cells = <2>;
> >> +     #size-cells = <2>;
> >> +
> >> +     cpus {
> >> +             #address-cells = <1>;
> >
> > The reg is 64-bit, so address-cells should be 2.
> >
> Please see my comment below regarding 'reg' property & cpu node naming.
> >> +             #size-cells = <0>;
> >> +
> >> +             cpu at 0 {
> >> +                     device_type = "cpu";
> >> +                     compatible = "arm,armv8";
> >
> > It might be good to also have a compatible string for the X-Gene's CPU
> > implementation, e.g.
> >
> > compatible = "apm,xgene-cpu", "arm,armv8";
> >
> Okay, will add a compatible string for APM-Xgene.
> >> +                     reg = <0x0 0x0000>;
> >> +                     enable-method = "spin-table";
> >> +                     cpu-release-addr = <0x1 0x0000fff8>;
> >> +             };
> >> +             cpu at 1 {
> >> +                     device_type = "cpu";
> >> +                     compatible = "arm,armv8";
> >> +                     reg = <0x0 0x0001>;
> >> +                     enable-method = "spin-table";
> >> +                     cpu-release-addr = <0x1 0x0000fff8>;
> >> +             };
> >> +             cpu at 2 {
> >> +                     device_type = "cpu";
> >> +                     compatible = "arm,armv8";
> >> +                     reg = <0x0 0x0100>;
> >> +                     enable-method = "spin-table";
> >> +                     cpu-release-addr = <0x1 0x0000fff8>;
> >> +             };
> >
> > This should be cpu at 101 to match the reg property (and the following nodes
> > should be fixed up similarly).
> >
> I would like to keep the cpu numbering as is (0 to 7). It helps the
> boot-loader to iterate over cpu nodes based on logical numbers to do
> fix-ups. Also here 'reg' property is not holding an address instead it
> contains value to be compared with mpidr_el1.

We use the address bits in a cpu node's reg property to hold the mpidr_el1
value. Regardless of the semantics of an address vs CPU id, the address bits in
the reg property take 2 cells, and hence #address-cells should be 2, as ePAPR
states:

"The #address-cells property defines the number of <u32> cells used to encode
the address field in a child node?s reg property."

Regarding the unit-address, ePAPR states:

"The unit-address must match the first address specified in the reg property of
the node."

We've tried to stick to this so far.

Thanks,
Mark.


From balbi at ti.com  Mon Apr 22 09:04:59 2013
From: balbi at ti.com (Felipe Balbi)
Date: Mon, 22 Apr 2013 16:04:59 +0300
Subject: linux-next ARM multi-platform randconfig errors
In-Reply-To: <517530E5.5050901@ti.com>
References: <5170B4C6.1030300@gmail.com> <20130419161257.GI10155@atomide.com>
 <5174E58D.8080800@ti.com> <20130422082149.GK10536@arwen.pp.htv.fi>
 <20130422115243.GD10797@arwen.pp.htv.fi> <517530E5.5050901@ti.com>
Message-ID: <20130422130459.GI10797@arwen.pp.htv.fi>

Hi,

On Mon, Apr 22, 2013 at 06:15:25PM +0530, Kishon Vijay Abraham I wrote:
> Hi,
> 
> On Monday 22 April 2013 05:22 PM, Felipe Balbi wrote:
> >Hi,
> >
> >On Mon, Apr 22, 2013 at 11:21:49AM +0300, Felipe Balbi wrote:
> >>>-Kevin Hilman <khilman at ti.com>
> >>>+Kevin Hilman <khilman at deeprootsystems.com>
> >>>
> >>>On 04/19/2013 07:12 PM, Tony Lindgren wrote:
> >>>>* Rob Herring <robherring2 at gmail.com> [130418 20:11]:
> >>>>>Current errors in linux-next for ARM multi-platform randconfig builds.
> >>>>>
> >>>>>Rob
> >>>>>
> >>>>>arch/arm/mach-omap2/built-in.o:dss-common.c:(.init.text+0x6830): more undefined references to `usb_bind_phy' follow
> >>>>
> >>>>Felipe & Roger, can you guys take a look at the usb_bind_phy issue
> >>>>in linux next? I have not seen that in the multiplatform randconfigs
> >>>>I've built, but I have had some omap2+ specific things enabled there.
> >>>
> >>>These problems happen if USB_PHY is not enabled as a built-in driver.
> >>>I had pointed this out earlier [1] and Felipe should have a fix for it.
> >>
> >>yeah, ideally we wouldn't do any 'select' and just update defconfig with
> >>the necessary changes. We need the patch below to update defconfig and
> >>another patch to stub out usb_bind_phy when !USB_PHY.
> >
> >the stub is already there, this should fix the other part though:
> 
> Denis had sent a patch for it 4 days back [1]. Lets use that instead.

makes sense :-)

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130422/91bbce4c/attachment.sig>

From arnd at arndb.de  Mon Apr 22 09:12:25 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 22 Apr 2013 15:12:25 +0200
Subject: [PATCH v3 00/10] ARM: exynos multiplatform series, part 1
In-Reply-To: <CAK9yfHwEZUPs70j3rS7V44RWxpZShEP8uxo3fFW54=L3NG-bDA@mail.gmail.com>
References: <1365716245-99231-1-git-send-email-arnd@arndb.de>
 <201304191536.17796.arnd@arndb.de>
 <CAK9yfHwEZUPs70j3rS7V44RWxpZShEP8uxo3fFW54=L3NG-bDA@mail.gmail.com>
Message-ID: <201304221512.25920.arnd@arndb.de>

On Monday 22 April 2013, Sachin Kamat wrote:
> 
> With this branch now available (merged) in linux-next (20130422),
> looks like exynos4 DT support is broken on it. Tested on Origen 4210
> and 4412 and I get the following warnings on 4412 Origen board with
> exynos_defconfig (Note that clocks are all 0). However, it boots fine
> on Arndale board.

I think this issue should be fixed with the patch that Thomas Abraham
just sent. Thomas, can you confirm?

> SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
> Preemptible hierarchical RCU implementation.
> NR_IRQS:549
> Exynos4x12 clocks: sclk_apll = 0, sclk_mpll = 0
>         sclk_epll = 0, sclk_vpll = 0, arm_clk = 0
> Division by zero in kernel.
> CPU: 0 PID: 0 Comm: swapper/0 Not tainted
> 3.9.0-rc8-next-20130422-00038-g20ff84f #50
> [<c0013fc8>] (unwind_backtrace+0x0/0xf8) from [<c0010ee4>]
> (show_stack+0x10/0x14)
> [<c0010ee4>] (show_stack+0x10/0x14) from [<c0190704>] (Ldiv0_64+0x8/0x18)
> [<c0190704>] (Ldiv0_64+0x8/0x18) from [<c00549c4>]
> (__clocksource_updatefreq_scale+0x44/0x19c)
> [<c00549c4>] (__clocksource_updatefreq_scale+0x44/0x19c) from
> [<c0054b28>] (__clocksource_register_scale+0xc/0x44)
> [<c0054b28>] (__clocksource_register_scale+0xc/0x44) from [<c04895b0>]
> (exynos4_clocksource_init+0x20/0x40)
> [<c04895b0>] (exynos4_clocksource_init+0x20/0x40) from [<c0489638>]
> (mct_init_dt+0x68/0x74)
> [<c0489638>] (mct_init_dt+0x68/0x74) from [<c0489384>]
> (clocksource_of_init+0x30/0x58)
> [<c0489384>] (clocksource_of_init+0x30/0x58) from [<c0473ae0>]
> (time_init+0x1c/0x30)
> [<c0473ae0>] (time_init+0x1c/0x30) from [<c04706a0>] (start_kernel+0x1a0/0x37c)
> [<c04706a0>] (start_kernel+0x1a0/0x37c) from [<40008074>] (0x40008074)
> Division by zero in kernel.

	Arnd


From thomas.petazzoni at free-electrons.com  Mon Apr 22 09:26:06 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Mon, 22 Apr 2013 15:26:06 +0200
Subject: linux-next: build failure after merge of the arm-soc tree
In-Reply-To: <CAOesGMhUTyPdNo=yaRqEv+Zhf7ga8e-R0asbnuje_LioWbqsgg@mail.gmail.com>
References: <20130419164636.0d2405ca5fd927f1ba31fe40@canb.auug.org.au>
 <CAOesGMhUTyPdNo=yaRqEv+Zhf7ga8e-R0asbnuje_LioWbqsgg@mail.gmail.com>
Message-ID: <20130422152606.5e4fb41a@skate>

Dear Olof Johansson,

On Fri, 19 Apr 2013 07:01:28 -0700, Olof Johansson wrote:

> > After merging the arm-soc tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> >
> > powerpc64-linux-ld: cannot find drivers/pci/host/built-in.o: No
> > such file or directory
> >
> > Caused by commit 9ecbe03ae85b ("pci: infrastructure to add drivers
> > in drivers/pci/host").
> >
> > I have used the arm-soc tree from next-20130418 for today.
> 
> Sorry about that, I'll drop the branch that brought in the of_pci
> consolidation from our repo.

The build failure reported here is totally independent of the of_pci
consolidation work. It's caused by the commit pointed in this e-mail,
and it is independent from Andrew Murray's work on of_pci consolidation.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From vkale at apm.com  Mon Apr 22 09:27:57 2013
From: vkale at apm.com (Vinayak Kale)
Date: Mon, 22 Apr 2013 18:57:57 +0530
Subject: [PATCH 4/4] arm64: Add initial DTS for APM X-Gene Storm SOC and
 APM Mustang board
In-Reply-To: <20130422125916.GB3791@e106331-lin.cambridge.arm.com>
References: <1366442131-26094-1-git-send-email-vkale@apm.com>
 <1366442131-26094-5-git-send-email-vkale@apm.com>
 <20130422111453.GA3791@e106331-lin.cambridge.arm.com>
 <CAPrCYkezfig2Drr+_dQpt7DxLRWt-v93o8hfS_ghcizussPq0w@mail.gmail.com>
 <20130422125916.GB3791@e106331-lin.cambridge.arm.com>
Message-ID: <CAPrCYkfpU06JOTagNiLgnikNyR61ku+9x5CUgHjkeGFCSS209A@mail.gmail.com>

On Mon, Apr 22, 2013 at 6:29 PM, Mark Rutland <mark.rutland at arm.com> wrote:
> On Mon, Apr 22, 2013 at 01:23:51PM +0100, Vinayak Kale wrote:
>> On Mon, Apr 22, 2013 at 4:44 PM, Mark Rutland <mark.rutland at arm.com> wrote:
>> > Hi,
>> >
>> > I have a couple of minor comments on the dts:
>> >
>> >> diff --git a/arch/arm64/boot/dts/storm.dtsi b/arch/arm64/boot/dts/storm.dtsi
>> >> new file mode 100644
>> >> index 0000000..8cab5d1
>> >> --- /dev/null
>> >> +++ b/arch/arm64/boot/dts/storm.dtsi
>> >> @@ -0,0 +1,116 @@
>> >> +/*
>> >> + * dts file for AppliedMicro (APM) X-Gene Storm SOC
>> >> + *
>> >> + * Copyright (C) 2013, Applied Micro Circuits Corporation
>> >> + *
>> >> + * 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.
>> >> + */
>> >> +
>> >> +/ {
>> >> +     compatible = "apm,xgene,storm", "apm,xgene";
>> >> +     interrupt-parent = <&gic>;
>> >> +     #address-cells = <2>;
>> >> +     #size-cells = <2>;
>> >> +
>> >> +     cpus {
>> >> +             #address-cells = <1>;
>> >
>> > The reg is 64-bit, so address-cells should be 2.
>> >
>> Please see my comment below regarding 'reg' property & cpu node naming.
>> >> +             #size-cells = <0>;
>> >> +
>> >> +             cpu at 0 {
>> >> +                     device_type = "cpu";
>> >> +                     compatible = "arm,armv8";
>> >
>> > It might be good to also have a compatible string for the X-Gene's CPU
>> > implementation, e.g.
>> >
>> > compatible = "apm,xgene-cpu", "arm,armv8";
>> >
>> Okay, will add a compatible string for APM-Xgene.
>> >> +                     reg = <0x0 0x0000>;
>> >> +                     enable-method = "spin-table";
>> >> +                     cpu-release-addr = <0x1 0x0000fff8>;
>> >> +             };
>> >> +             cpu at 1 {
>> >> +                     device_type = "cpu";
>> >> +                     compatible = "arm,armv8";
>> >> +                     reg = <0x0 0x0001>;
>> >> +                     enable-method = "spin-table";
>> >> +                     cpu-release-addr = <0x1 0x0000fff8>;
>> >> +             };
>> >> +             cpu at 2 {
>> >> +                     device_type = "cpu";
>> >> +                     compatible = "arm,armv8";
>> >> +                     reg = <0x0 0x0100>;
>> >> +                     enable-method = "spin-table";
>> >> +                     cpu-release-addr = <0x1 0x0000fff8>;
>> >> +             };
>> >
>> > This should be cpu at 101 to match the reg property (and the following nodes
>> > should be fixed up similarly).
>> >
>> I would like to keep the cpu numbering as is (0 to 7). It helps the
>> boot-loader to iterate over cpu nodes based on logical numbers to do
>> fix-ups. Also here 'reg' property is not holding an address instead it
>> contains value to be compared with mpidr_el1.
>
> We use the address bits in a cpu node's reg property to hold the mpidr_el1
> value. Regardless of the semantics of an address vs CPU id, the address bits in
> the reg property take 2 cells, and hence #address-cells should be 2, as ePAPR
> states:
>
> "The #address-cells property defines the number of <u32> cells used to encode
> the address field in a child node?s reg property."
>
> Regarding the unit-address, ePAPR states:
>
> "The unit-address must match the first address specified in the reg property of
> the node."
>
> We've tried to stick to this so far.
>
Okay, will modify accordingly.
> Thanks,
> Mark.

Thanks
-Vinayak


From sergei.shtylyov at cogentembedded.com  Mon Apr 22 09:34:05 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Mon, 22 Apr 2013 17:34:05 +0400
Subject: [PATCH v5 1/9] ARM: shmobile: Marzen: move USB EHCI, OHCI, and
 PHY devices to R8A7779 code
In-Reply-To: <20130422010917.GC15680@verge.net.au>
References: <201304200156.23830.sergei.shtylyov@cogentembedded.com>
 <51743BC0.20506@cogentembedded.com> <20130422010917.GC15680@verge.net.au>
Message-ID: <51753C4D.4080701@cogentembedded.com>

Hello.

On 22-04-2013 5:09, Simon Horman wrote:

>>> USB EHCI, OHCI, and common PHY are the SoC devices but are wrongly defined and
>>> registered in the Marzen board file.  Move the data and code to their proper
>>> place in setup-r8a7779.c; while at it, we have to rename 8a7779_late_devices[]
>>> to 8a7779_standard_devices[] -- this seems legitimate since they are registered
>>
>>      I've been pointed to the types in the above variable names privately.
>> Don't know should I resend or Simon could fix s/8a7779/r8a7779/ while
>> applying... well, the USB patches haven't been ACK'ed yet.

> I can fix that up.

> Is the series waiting on anything?

    Probably on Felipe's ACKs on rcar-phy.c patches... Felipe hasn't appeared 
on this list for a week but I see his mails from today.

>> >from r8a7779_add_standard_devices() anyway.

>>> Note that I'm deliberately changing the USB PHY platform device's 'id' field
>> >from (previously just omitted) 0 to -1 as the device is a single of its kind.

>>> Note also that the board and SoC code have to be in one patch to keep the code
>>> bisectable...

>>> The patch has been tested on the Marzen board.

>>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
>>> Acked-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
>>> Acked-by: Simon Horman <horms+renesas at verge.net.au>

WBR, Sergei



From thomas.abraham at linaro.org  Mon Apr 22 09:36:24 2013
From: thomas.abraham at linaro.org (Thomas Abraham)
Date: Mon, 22 Apr 2013 19:06:24 +0530
Subject: [PATCH v3 00/10] ARM: exynos multiplatform series, part 1
In-Reply-To: <201304221512.25920.arnd@arndb.de>
References: <1365716245-99231-1-git-send-email-arnd@arndb.de>
 <201304191536.17796.arnd@arndb.de>
 <CAK9yfHwEZUPs70j3rS7V44RWxpZShEP8uxo3fFW54=L3NG-bDA@mail.gmail.com>
 <201304221512.25920.arnd@arndb.de>
Message-ID: <CAJuYYwQS8HJ5gdH7-YxJ+x72Jfn-stP3DSiU=fUObc=RJfbb6w@mail.gmail.com>

On 22 April 2013 18:42, Arnd Bergmann <arnd at arndb.de> wrote:
> On Monday 22 April 2013, Sachin Kamat wrote:
>>
>> With this branch now available (merged) in linux-next (20130422),
>> looks like exynos4 DT support is broken on it. Tested on Origen 4210
>> and 4412 and I get the following warnings on 4412 Origen board with
>> exynos_defconfig (Note that clocks are all 0). However, it boots fine
>> on Arndale board.
>
> I think this issue should be fixed with the patch that Thomas Abraham
> just sent. Thomas, can you confirm?

Yes, this issue is resolved with chip-id dt support patches, without
which the parent of fin_pll clock is set as xxti (which is set to 0Hz
for Origen4210) instead of xusbxti.

Thomas.

>
>> SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
>> Preemptible hierarchical RCU implementation.
>> NR_IRQS:549
>> Exynos4x12 clocks: sclk_apll = 0, sclk_mpll = 0
>>         sclk_epll = 0, sclk_vpll = 0, arm_clk = 0
>> Division by zero in kernel.
>> CPU: 0 PID: 0 Comm: swapper/0 Not tainted
>> 3.9.0-rc8-next-20130422-00038-g20ff84f #50
>> [<c0013fc8>] (unwind_backtrace+0x0/0xf8) from [<c0010ee4>]
>> (show_stack+0x10/0x14)
>> [<c0010ee4>] (show_stack+0x10/0x14) from [<c0190704>] (Ldiv0_64+0x8/0x18)
>> [<c0190704>] (Ldiv0_64+0x8/0x18) from [<c00549c4>]
>> (__clocksource_updatefreq_scale+0x44/0x19c)
>> [<c00549c4>] (__clocksource_updatefreq_scale+0x44/0x19c) from
>> [<c0054b28>] (__clocksource_register_scale+0xc/0x44)
>> [<c0054b28>] (__clocksource_register_scale+0xc/0x44) from [<c04895b0>]
>> (exynos4_clocksource_init+0x20/0x40)
>> [<c04895b0>] (exynos4_clocksource_init+0x20/0x40) from [<c0489638>]
>> (mct_init_dt+0x68/0x74)
>> [<c0489638>] (mct_init_dt+0x68/0x74) from [<c0489384>]
>> (clocksource_of_init+0x30/0x58)
>> [<c0489384>] (clocksource_of_init+0x30/0x58) from [<c0473ae0>]
>> (time_init+0x1c/0x30)
>> [<c0473ae0>] (time_init+0x1c/0x30) from [<c04706a0>] (start_kernel+0x1a0/0x37c)
>> [<c04706a0>] (start_kernel+0x1a0/0x37c) from [<40008074>] (0x40008074)
>> Division by zero in kernel.
>
>         Arnd


From linux at roeck-us.net  Mon Apr 22 09:44:08 2013
From: linux at roeck-us.net (Guenter Roeck)
Date: Mon, 22 Apr 2013 06:44:08 -0700
Subject: [PATCH 09/23] watchdog: coh901327: devicetree support
In-Reply-To: <1366624505-6437-1-git-send-email-linus.walleij@stericsson.com>
References: <1366624505-6437-1-git-send-email-linus.walleij@stericsson.com>
Message-ID: <20130422134408.GA28711@roeck-us.net>

On Mon, Apr 22, 2013 at 11:55:05AM +0200, Linus Walleij wrote:
> From: Linus Walleij <linus.walleij at linaro.org>
> 
> This adds support for probing the COH 901 327 watchdog from
> the device tree and also adds associated bindings.
> 
> Cc: Wim Van Sebroeck <wim at iguana.be>
> Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
> ---
> Hi Wim, I'm seeking an ACK on this patch to take it into
> ARM SoC along with the patches making use of this new
> binding.
> ---
>  .../devicetree/bindings/watchdog/stericsson-coh901327.txt | 15 +++++++++++++++
>  drivers/watchdog/coh901327_wdt.c                          |  6 ++++++
>  2 files changed, 21 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/watchdog/stericsson-coh901327.txt
> 
> diff --git a/Documentation/devicetree/bindings/watchdog/stericsson-coh901327.txt b/Documentation/devicetree/bindings/watchdog/stericsson-coh901327.txt
> new file mode 100644
> index 0000000..3d7c958
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/watchdog/stericsson-coh901327.txt
> @@ -0,0 +1,15 @@
> +ST-Ericsson COH 901 327 Watchdog timer
> +
> +Required properties:
> +- compatible: must be "stericsson,coh901327".
> +- reg: physical base address of the controller and length of memory mapped
> +  region.
> +- interrupts: the interrupt used for the watchdog timeout warning.
> +
> +Example:
> +
> +watchdog: watchdog at c0012000 {
> +	compatible = "stericsson,coh901327";
> +	reg = <0xc0012000 0x1000>;
> +	interrupts = <3>;
> +};

If you add a call to watchdog_init_timeout(), it would also support
setting the timeout through the timeout-sec property.

Guenter


From tglx at linutronix.de  Mon Apr 22 09:50:50 2013
From: tglx at linutronix.de (Thomas Gleixner)
Date: Mon, 22 Apr 2013 15:50:50 +0200 (CEST)
Subject: [PATCH v3] irqchip: Add support for ARMv7-M's NVIC
In-Reply-To: <201304221404.31281.arnd@arndb.de>
References: <1366214540-31166-1-git-send-email-u.kleine-koenig@pengutronix.de>
 <20130419150927.GE15233@pengutronix.de>
 <20130422100219.GH15233@pengutronix.de> <201304221404.31281.arnd@arndb.de>
Message-ID: <alpine.LFD.2.02.1304221519221.21884@ionos>

On Mon, 22 Apr 2013, Arnd Bergmann wrote:
> On Monday 22 April 2013, Uwe Kleine-K?nig wrote:
> > For the uncommented files using %32 instead of -gc->irq_base should
> > work.
> 
> I'm not sure I understand why this doesn't work for the ones that use
> a base that isn't a multiple of 32. Since you are masking the hwirq
> rather than the irq number, it will still be zero-based, won't it?

The issue is that for anything which uses this w/o irq domains
d->hwirq is 0.

Thanks,

	tglx


From linux at arm.linux.org.uk  Mon Apr 22 10:06:01 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Mon, 22 Apr 2013 15:06:01 +0100
Subject: [PATCH v6 1/4] arm: introduce psci_smp_ops
In-Reply-To: <alpine.DEB.2.02.1304181714560.7254@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1304031239550.5078@kaball.uk.xensource.com>
 <1365167495-18508-1-git-send-email-stefano.stabellini@eu.citrix.com>
 <20130418161341.GB14496@n2100.arm.linux.org.uk>
 <alpine.DEB.2.02.1304181714560.7254@kaball.uk.xensource.com>
Message-ID: <20130422140601.GH14496@n2100.arm.linux.org.uk>

On Thu, Apr 18, 2013 at 05:20:23PM +0100, Stefano Stabellini wrote:
> On Thu, 18 Apr 2013, Russell King - ARM Linux wrote:
> > Remember, we're trying to move away from using "mdesc"s for platform
> > stuff, relying on things like DT and such like.  We really should not
> > be going for mdesc-overriding-newstuff but newstuff-overriding-mdesc.
> 
> That's correct, in fact if you look at the next patch you'll see that it
> changes the order.

You may have noticed that I've been catching up with email, and it's
exceedingly difficult to track what patches are obsolete and have been
overridden by new versions.

> I introduced the mechanism first and changed the priority later - it
> should help bisectability.
> I can fold the two patches into one if you prefer.

On the face of it, I think that would be better.  I don't remember what
your last version looks like though.

> > Now, if the psci stuff can't be relied upon to provide the correct
> > functionality, then that's a separate problem which needs addressing
> > differently.
> > 
> > This should allow the Xen problem to be resolved, because Xen will
> > provide the PSCI operations, and it's correct in that case to override
> > the platform's SMP operations.
> 
> Yes, increasing the priority of PSCI helps Xen a lot.
> In order to completely solve the issue for Xen though, another patch is
> needed (http://marc.info/?l=linux-kernel&m=136630106201968&w=2) because
> of the introduction of smp_init.

Given the way the code in setup.c will work:

+static bool __init xen_smp_init(void)
+{
+#ifdef CONFIG_SMP
+	/* If we are running on Xen, use PSCI if available.
+	 * In any case do not try to use the native smp_ops. */
+	if (psci_smp_available())
+		smp_set_ops(&psci_smp_ops);
+#endif
+	return true;
+}

Doesn't this just need to return false, and then we'll drop down to
using PSCI if those operations are available?


From linux at arm.linux.org.uk  Mon Apr 22 10:07:11 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Mon, 22 Apr 2013 15:07:11 +0100
Subject: [PATCH] ARM: make cpu_init() notrace
In-Reply-To: <1366302046.3388.8.camel@linaro1.home>
References: <1366302046.3388.8.camel@linaro1.home>
Message-ID: <20130422140711.GI14496@n2100.arm.linux.org.uk>

On Thu, Apr 18, 2013 at 05:20:46PM +0100, Jon Medhurst (Tixy) wrote:
> On resume from CPU power down any trace hooks enabled in cpu_init()
> will get called before that function has done set_my_cpu_offset(),
> so any use of per-cpu variables by trace hook code will cause bad
> things to happen. Prevent this by marking the function notrace.
> 
> This fixes lockups/crashes seen when enabling function tracer on TC2
> with the not yet mainlined cpuidle driver.

Looks sane.  Needs to go to the patch system though.  Not sure if it'll
make 3.9 given its proximity (we're on -rc8).


From mpfj-list at newflow.co.uk  Mon Apr 22 10:07:35 2013
From: mpfj-list at newflow.co.uk (Mark Jackson)
Date: Mon, 22 Apr 2013 15:07:35 +0100
Subject: [PATCH 0/3] Dual EMAC mode implementation of CPSW
In-Reply-To: <517018E6.6080108@newflow.co.uk>
References: <1360612340-9266-1-git-send-email-mugunthanvnm@ti.com>
 <516B0098.4040809@mimc.co.uk> <516C33D2.4050105@ti.com>
 <516C38B9.50904@mimc.co.uk> <516C3A0D.70903@ti.com>
 <517018E6.6080108@newflow.co.uk>
Message-ID: <51754427.7000908@newflow.co.uk>

On 18/04/13 17:01, Mark Jackson wrote:
> On 15/04/13 18:34, Mugunthan V N wrote:
>> On 4/15/2013 10:58 PM, Mark Jackson wrote:
>>> On 15/04/13 18:07, Mugunthan V N wrote:
>>>> On 4/15/2013 12:46 AM, Mark Jackson wrote:
>>>
>>> <snip>
>>>
>>>>>
>>>>> Notice that at the end, the nfs link appears to come back "ok", but
>>>>> the "ps" command never completes.
>>>>>
>>>>> Any ideas of what's going on ?
>>>>
>>>> I have tried ping on both the interface fine. Will verify with ps again
>>>> later in this week.
>>>> Can you provide below details details
>>>> - Are you using EVMsk or custom build EVM?
>>>
>>> This is a custom board (based on the BeagleBone design) with dual
>>> Ethernet, NAND, NOR and FRAM.
>>>
>>> The dual emac thing is (one of) the last things to get signed off, so
>>> I'm willing to assist in tracking this down.
>>
>> After testing the scenario i may be able to send you an update later in
>> this week.
> 
> I have made some progress ... I realised I was missing a (clearly rather
> important !!) item in my .config file, namely CONFIG_TI_DAVINCI_EMAC.
> 
> I am now able to ping from our board to other systems on the network
> (again, I've only tested eth0 at the moment).
> 
> However, I am unable to ping everything I should be able to !!

<snip>

> When the pings fail, I am unable to see *any* activity on the network
> (using wireshark).
> 
> Is there anything else I should try ?

Mugunthan

Can you confirm that I'm actually trying to achieve the right thing ?

I have all along assumed that Dual EMAC mode would simply provide the
kernel will a pair of independent Ethernet ports.

All I am trying to do is to get both Ethernet ports working so I can
have one port on (say) 10.0.x.x and the other on (say) 10.1.x.x

But there is all this reference to VLANs(in the source code and the TRM)
... I have not setup any VLANs.  Do I need to ?  If so, how ?

Cheers
Mark J.


From linux at arm.linux.org.uk  Mon Apr 22 10:17:19 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Mon, 22 Apr 2013 15:17:19 +0100
Subject: [PATCH] Report double word access atomicity on LPAE enabled
 targets through AUXV
In-Reply-To: <20130418162232.GB23112@arm.com>
References: <C3FF039D-7DE3-4A99-8317-789094095D8B@oracle.com>
 <20130408142406.GL17995@n2100.arm.linux.org.uk>
 <20130408155749.GS17476@mudshark.cambridge.arm.com>
 <CD54D5A4-2E19-49D9-B6E7-051F36AB5DF8@oracle.com>
 <20130416172258.GE3770@mudshark.cambridge.arm.com>
 <20130418162232.GB23112@arm.com>
Message-ID: <20130422141719.GJ14496@n2100.arm.linux.org.uk>

On Thu, Apr 18, 2013 at 05:22:33PM +0100, Catalin Marinas wrote:
> I would rather add individual entries like atomicd. User space does not
> need to know whether LPAE is supported or not.

I'm not sure that userspace should know this detail.

| LDM, LDC, LDC2, LDRD, STM, STC, STC2, STRD, PUSH, POP, RFE, SRS, VLDM,
| VLDR, VSTM, and VSTR instructions are executed as a sequence of word-
| aligned word accesses. Each 32-bit word access is guaranteed to be
| single-copy atomic. The architecture does not require subsequences
| of two or more word accesses from the sequence to be single-copy
| atomic.
| 
| In an implementation that includes the Large Physical Address Extension,
| LDRD and STRD accesses to 64-bit aligned locations are 64-bit single-copy
| atomic as seen by translation table walks and accesses to translation
| tables.
| ...
| Load/store multiple instructions, such as LDM, LDRD, STM, and STRD,
| generate multiple word accesses, each of which is a separate access
| for the purpose of determining ordering.

Note carefully the wording in the ARM ARM in the second paragraph -
it's not saying that LDRD and STRD accesses are single-copy atomic
to all viewers, but it's limited to the translation tables.

Sure, you can argue that the translation tables are just normal memory
accesses, but in that case why use the above wording if not to permit
them to be multiple-copy accesses as stated in the paragraph above
and elsewhere in the ARM ARM in the paragraph below.

Maybe an error in the ARM ARM?  It doesn't seem wise through to permit
userspace to assume that LDRD/STRD are atomic in userspace given the
above wording unless the ARM ARM gets fixed.


From linux at arm.linux.org.uk  Mon Apr 22 10:20:55 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Mon, 22 Apr 2013 15:20:55 +0100
Subject: [PATCH v6 1/4] arm: introduce psci_smp_ops
In-Reply-To: <alpine.LFD.2.03.1304181233580.17375@syhkavp.arg>
References: <alpine.DEB.2.02.1304031239550.5078@kaball.uk.xensource.com>
 <1365167495-18508-1-git-send-email-stefano.stabellini@eu.citrix.com>
 <20130418161341.GB14496@n2100.arm.linux.org.uk>
 <alpine.DEB.2.02.1304181714560.7254@kaball.uk.xensource.com>
 <alpine.LFD.2.03.1304181233580.17375@syhkavp.arg>
Message-ID: <20130422142055.GK14496@n2100.arm.linux.org.uk>

On Thu, Apr 18, 2013 at 12:35:57PM -0400, Nicolas Pitre wrote:
> On Thu, 18 Apr 2013, Stefano Stabellini wrote:
> 
> > On Thu, 18 Apr 2013, Russell King - ARM Linux wrote:
> > > On Fri, Apr 05, 2013 at 02:11:32PM +0100, Stefano Stabellini wrote:
> > > > +	psci_init();
> > > >  #ifdef CONFIG_SMP
> > > >  	if (is_smp()) {
> > > > -		smp_set_ops(mdesc->smp);
> > > > +		if (mdesc->smp)
> > > > +			smp_set_ops(mdesc->smp);
> > > > +		else if (psci_smp_available())
> > > > +			smp_set_ops(&psci_smp_ops);
> > > 
> > > So, I have a vague recollection that the ordering of the above got discussed
> > > but I can't find it amongst the 21k of messages so far this year.
> > > 
> > > The above looks weird to me.  Surely this should be:
> > > 
> > > 		if (psci_smp_available())
> > > 			smp_set_ops(&psci_smp_ops);
> > > 		else if (mdesc->smp)
> > > 			smp_set_ops(mdesc->ops);
> > > 
> > > This means that if PSCI is available, and provides a set of operations,
> > > we override whatever the platform has statically provided.
> > > 
> > > Remember, we're trying to move away from using "mdesc"s for platform
> > > stuff, relying on things like DT and such like.  We really should not
> > > be going for mdesc-overriding-newstuff but newstuff-overriding-mdesc.
> > 
> > That's correct, in fact if you look at the next patch you'll see that it
> > changes the order.
> > 
> > I introduced the mechanism first and changed the priority later - it
> > should help bisectability.
> > I can fold the two patches into one if you prefer.
> 
> Please let's keep the order as we discussed.  Otherwise this is just too 
> confusing (Russell's comment is a good example of that).

My comment is based on the code which I had read and quoted.  Things
had moved on from that point, but, because I had 2000 odd messages to
get through, there was no way to know at that point that there had been
further discussion.

This is why catching up is such a problem - not only the amount of time
it takes (I'm _still_ reading messages - I've only just read your reply
above, so I'm still back in Thursday's email...)

I don't think there's any confusion though - the order I suggested seems
to be the order which I recall later patches adopted.


From tglx at linutronix.de  Mon Apr 22 10:21:23 2013
From: tglx at linutronix.de (Thomas Gleixner)
Date: Mon, 22 Apr 2013 16:21:23 +0200 (CEST)
Subject: [PATCH v3] irqchip: Add support for ARMv7-M's NVIC
In-Reply-To: <20130422100219.GH15233@pengutronix.de>
References: <1366214540-31166-1-git-send-email-u.kleine-koenig@pengutronix.de>
 <alpine.LFD.2.02.1304180947070.21884@ionos>
 <20130419150927.GE15233@pengutronix.de>
 <20130422100219.GH15233@pengutronix.de>
Message-ID: <alpine.LFD.2.02.1304221551240.21884@ionos>

On Mon, 22 Apr 2013, Uwe Kleine-K?nig wrote:
> The options I see are:
> 
>  - introduce a new set of functions
>    Do you have a nice naming scheme?
>    irq_gc_unmask_enable_reg_hwirqmod32? Or should I rename the existing
>    ones to irq_gc_unmask_enable_reg_irqbaseoffset?

Shudder. We do not need new functions at all, we just need to think a
bit.

>  - use
>  	u32 mask = 1 << (d->hwirq - gc->irq_base) % 32;
>    This is ugly but might work assuming irq_base == 0 for chips with irq
>    domain support and hwirq == irq for the others.

Which is not correct, as hwirq is always 0 for !irqdomain users. And
no, we don't set it to irq.

Calculating the mask over and over is stupid to begin with. We can
precompute it and store it in irq_data->mask. For the existing generic
chip users we simply precompute it with 1 << (d->hwirq - gc->irq_base)
and let the irqdomain code calculate it for everything else.

Hmm?

Thanks,

	tglx
---

diff --git a/include/linux/irq.h b/include/linux/irq.h
index bc4e066..03fd64a 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -119,6 +119,7 @@ struct irq_domain;
 
 /**
  * struct irq_data - per irq and irq chip data passed down to chip functions
+ * @mask:		precomputed bitmask for accessing the chip registers
  * @irq:		interrupt number
  * @hwirq:		hardware interrupt number, local to the interrupt domain
  * @node:		node index useful for balancing
@@ -138,6 +139,7 @@ struct irq_domain;
  * irq_data.
  */
 struct irq_data {
+	u32			mask;
 	unsigned int		irq;
 	unsigned long		hwirq;
 	unsigned int		node;
@@ -700,10 +702,14 @@ struct irq_chip_generic {
  * @IRQ_GC_INIT_NESTED_LOCK:	Set the lock class of the irqs to nested for
  *				irq chips which need to call irq_set_wake() on
  *				the parent irq. Usually GPIO implementations
+ * @IRQ_GC_NO_MASK:		Do not calculate irq_data->mask
+ * @IRQ_GC_MASK_FROM_HWIRQ:	Calculate irq_data->mask from the hwirq number
  */
 enum irq_gc_flags {
 	IRQ_GC_INIT_MASK_CACHE		= 1 << 0,
 	IRQ_GC_INIT_NESTED_LOCK		= 1 << 1,
+	IRQ_GC_NO_MASK			= 1 << 2,
+	IRQ_GC_MASK_FROM_HWIRQ		= 1 << 4,
 };
 
 /* Generic chip callback functions */
diff --git a/kernel/irq/generic-chip.c b/kernel/irq/generic-chip.c
index c89295a..a013a35 100644
--- a/kernel/irq/generic-chip.c
+++ b/kernel/irq/generic-chip.c
@@ -39,7 +39,7 @@ void irq_gc_noop(struct irq_data *d)
 void irq_gc_mask_disable_reg(struct irq_data *d)
 {
 	struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
-	u32 mask = 1 << (d->irq - gc->irq_base);
+	u32 mask = d->mask;
 
 	irq_gc_lock(gc);
 	irq_reg_writel(mask, gc->reg_base + cur_regs(d)->disable);
@@ -57,7 +57,7 @@ void irq_gc_mask_disable_reg(struct irq_data *d)
 void irq_gc_mask_set_bit(struct irq_data *d)
 {
 	struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
-	u32 mask = 1 << (d->irq - gc->irq_base);
+	u32 mask = d->mask;
 
 	irq_gc_lock(gc);
 	gc->mask_cache |= mask;
@@ -75,7 +75,7 @@ void irq_gc_mask_set_bit(struct irq_data *d)
 void irq_gc_mask_clr_bit(struct irq_data *d)
 {
 	struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
-	u32 mask = 1 << (d->irq - gc->irq_base);
+	u32 mask = d->mask;
 
 	irq_gc_lock(gc);
 	gc->mask_cache &= ~mask;
@@ -93,7 +93,7 @@ void irq_gc_mask_clr_bit(struct irq_data *d)
 void irq_gc_unmask_enable_reg(struct irq_data *d)
 {
 	struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
-	u32 mask = 1 << (d->irq - gc->irq_base);
+	u32 mask = d->mask;
 
 	irq_gc_lock(gc);
 	irq_reg_writel(mask, gc->reg_base + cur_regs(d)->enable);
@@ -108,7 +108,7 @@ void irq_gc_unmask_enable_reg(struct irq_data *d)
 void irq_gc_ack_set_bit(struct irq_data *d)
 {
 	struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
-	u32 mask = 1 << (d->irq - gc->irq_base);
+	u32 mask = d->mask;
 
 	irq_gc_lock(gc);
 	irq_reg_writel(mask, gc->reg_base + cur_regs(d)->ack);
@@ -122,7 +122,7 @@ void irq_gc_ack_set_bit(struct irq_data *d)
 void irq_gc_ack_clr_bit(struct irq_data *d)
 {
 	struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
-	u32 mask = ~(1 << (d->irq - gc->irq_base));
+	u32 mask = ~d->mask;
 
 	irq_gc_lock(gc);
 	irq_reg_writel(mask, gc->reg_base + cur_regs(d)->ack);
@@ -136,7 +136,7 @@ void irq_gc_ack_clr_bit(struct irq_data *d)
 void irq_gc_mask_disable_reg_and_ack(struct irq_data *d)
 {
 	struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
-	u32 mask = 1 << (d->irq - gc->irq_base);
+	u32 mask = d->mask;
 
 	irq_gc_lock(gc);
 	irq_reg_writel(mask, gc->reg_base + cur_regs(d)->mask);
@@ -151,7 +151,7 @@ void irq_gc_mask_disable_reg_and_ack(struct irq_data *d)
 void irq_gc_eoi(struct irq_data *d)
 {
 	struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
-	u32 mask = 1 << (d->irq - gc->irq_base);
+	u32 mask = d->mask;
 
 	irq_gc_lock(gc);
 	irq_reg_writel(mask, gc->reg_base + cur_regs(d)->eoi);
@@ -169,7 +169,7 @@ void irq_gc_eoi(struct irq_data *d)
 int irq_gc_set_wake(struct irq_data *d, unsigned int on)
 {
 	struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
-	u32 mask = 1 << (d->irq - gc->irq_base);
+	u32 mask = d->mask;
 
 	if (!(mask & gc->wake_enabled))
 		return -EINVAL;
@@ -254,6 +254,15 @@ void irq_setup_generic_chip(struct irq_chip_generic *gc, u32 msk,
 		if (flags & IRQ_GC_INIT_NESTED_LOCK)
 			irq_set_lockdep_class(i, &irq_nested_lock_class);
 
+		if (!(flags & IRQ_GC_NO_MASK)) {
+			struct irq_data *d = irq_get_irq_data(i);
+			u32 mask;
+
+			if (flags & IRQ_GC_MASK_FROM_HWIRQ)
+				d->mask = 1 << (d->hwirq % 32);
+			else
+				d->mask = 1 << (i - gc->irq_base);
+		}
 		irq_set_chip_and_handler(i, &ct->chip, ct->handler);
 		irq_set_chip_data(i, gc);
 		irq_modify_status(i, clr, set);



From linux at arm.linux.org.uk  Mon Apr 22 10:23:18 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Mon, 22 Apr 2013 15:23:18 +0100
Subject: [PATCH v6 1/4] arm: introduce psci_smp_ops
In-Reply-To: <alpine.DEB.2.02.1304181748010.7254@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1304031239550.5078@kaball.uk.xensource.com>
 <1365167495-18508-1-git-send-email-stefano.stabellini@eu.citrix.com>
 <20130418161341.GB14496@n2100.arm.linux.org.uk>
 <alpine.DEB.2.02.1304181714560.7254@kaball.uk.xensource.com>
 <alpine.LFD.2.03.1304181233580.17375@syhkavp.arg>
 <alpine.DEB.2.02.1304181748010.7254@kaball.uk.xensource.com>
Message-ID: <20130422142318.GL14496@n2100.arm.linux.org.uk>

On Thu, Apr 18, 2013 at 05:49:21PM +0100, Stefano Stabellini wrote:
> On Thu, 18 Apr 2013, Nicolas Pitre wrote:
> > Please let's keep the order as we discussed.  Otherwise this is just too 
> > confusing (Russell's comment is a good example of that).
> 
> You are right, it is confusing.
> By "keep the order as we discussed", do you mean merge the second patch
> into the first one, correct?

Well, the solution to this kind of confusion is to ignore comments on the
older patches and post a new set of patches and ask for all relevant
comments to be against that set and that set only.


From linux at arm.linux.org.uk  Mon Apr 22 10:24:57 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Mon, 22 Apr 2013 15:24:57 +0100
Subject: [RFC PATCH] drivers: bus: add ARM CCI support
In-Reply-To: <alpine.LFD.2.03.1304181341020.17375@syhkavp.arg>
References: <1365691679-28674-1-git-send-email-lorenzo.pieralisi@arm.com>
 <1365691679-28674-2-git-send-email-lorenzo.pieralisi@arm.com>
 <51702B70.9000908@codeaurora.org>
 <alpine.LFD.2.03.1304181341020.17375@syhkavp.arg>
Message-ID: <20130422142457.GM14496@n2100.arm.linux.org.uk>

On Thu, Apr 18, 2013 at 01:54:04PM -0400, Nicolas Pitre wrote:
> On Thu, 18 Apr 2013, Stephen Boyd wrote:
> 
> > On 04/11/13 07:47, Lorenzo Pieralisi wrote:
> > > diff --git a/drivers/bus/arm-cci.c b/drivers/bus/arm-cci.c
> > > new file mode 100644
> > > index 0000000..81953de
> > > --- /dev/null
> > > +++ b/drivers/bus/arm-cci.c
> > [...]
> > > +static void notrace cci_port_control(unsigned int port, bool enable)
> > > +{
> > > +	void __iomem *base = ports[port].base;
> > > +
> > > +	if (!base)
> > > +		return;
> > > +
> > > +	writel_relaxed(enable, base + CCI_PORT_CTRL);
> > > +	while (readl_relaxed(cci_ctrl_base + CCI_CTRL_STATUS) & 0x1)
> > > +			;
> > 
> > cpu_relax()?
> 
> In some cases there is no more cache coherence when this is called and 
> the hardware might not be in a good state to cope with whatever action 
> people might be tempted to insert into cpu_relax().  After the CCI is 
> disabled it is important to keep a low profile and not touch anything 
> global. With some early hardware revision, even a DMB here was harmful.

It would be useful if there was a comment in the code explaining this.
As it stands, you _will_ get a stream of patches from kernel janitors
itching to add cpu_relax() there.

If you're going to do something different from the norm, it _needs_ to
definitely be commented and explained.


From linux at arm.linux.org.uk  Mon Apr 22 10:25:55 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Mon, 22 Apr 2013 15:25:55 +0100
Subject: [PATCH] clk: vexpress: Add separate SP810 driver
In-Reply-To: <1366305802.3077.37.camel@hornet>
References: <1363358409-5693-1-git-send-email-pawel.moll@arm.com>
 <20130417222630.19887.75481@quantum> <1366305802.3077.37.camel@hornet>
Message-ID: <20130422142555.GN14496@n2100.arm.linux.org.uk>

On Thu, Apr 18, 2013 at 06:23:22PM +0100, Pawel Moll wrote:
> On Wed, 2013-04-17 at 23:26 +0100, Mike Turquette wrote:
> > In this case you are using clk_prepare for one-time configuration.  I
> > agree that no alternative exists yet, but there have been discussions
> > recently about using DT for configuration details that are not strictly
> > descriptions of the hardware.  I've added a comment block in the patch
> > below which notes this with a FIXME since there isn't a graceful
> > alternative to using clk_prepare for ont-time configuration.
> 
> Fair enough.
> 
> > Can you test the patch below against the latest clk-next and let me know
> > if it working on your platform?
> 
> It wasn't:
> 
> WARNING: at [...]/drivers/clk/clk.c:808 __clk_enable+0x94/0xa0()
> 
> because the new parent is not prepared automagically. This simple change
> heals the problem and now everything is just fine:
> 
>         /* Switch the parent if necessary */
> -       if (old_parent != new_parent)
> +       if (old_parent != new_parent) {
> +               clk_prepare(new_parent);
>                 clk_set_parent(hw->clk, new_parent);
> +               clk_unprepare(old_parent);
> +       }
> 
> So, to summarize, the patch that works for me is below.

So what if the old parent clock wasn't prepared?


From catalin.marinas at arm.com  Mon Apr 22 10:28:30 2013
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Mon, 22 Apr 2013 15:28:30 +0100
Subject: [PATCH] Report double word access atomicity on LPAE enabled
 targets through AUXV
In-Reply-To: <20130422141719.GJ14496@n2100.arm.linux.org.uk>
References: <C3FF039D-7DE3-4A99-8317-789094095D8B@oracle.com>
 <20130408142406.GL17995@n2100.arm.linux.org.uk>
 <20130408155749.GS17476@mudshark.cambridge.arm.com>
 <CD54D5A4-2E19-49D9-B6E7-051F36AB5DF8@oracle.com>
 <20130416172258.GE3770@mudshark.cambridge.arm.com>
 <20130418162232.GB23112@arm.com>
 <20130422141719.GJ14496@n2100.arm.linux.org.uk>
Message-ID: <20130422142830.GA7398@arm.com>

On Mon, Apr 22, 2013 at 03:17:19PM +0100, Russell King - ARM Linux wrote:
> On Thu, Apr 18, 2013 at 05:22:33PM +0100, Catalin Marinas wrote:
> > I would rather add individual entries like atomicd. User space does not
> > need to know whether LPAE is supported or not.
> 
> I'm not sure that userspace should know this detail.

Which detail, LPAE or atomic double accesses?

> | LDM, LDC, LDC2, LDRD, STM, STC, STC2, STRD, PUSH, POP, RFE, SRS, VLDM,
> | VLDR, VSTM, and VSTR instructions are executed as a sequence of word-
> | aligned word accesses. Each 32-bit word access is guaranteed to be
> | single-copy atomic. The architecture does not require subsequences
> | of two or more word accesses from the sequence to be single-copy
> | atomic.
> | 
> | In an implementation that includes the Large Physical Address Extension,
> | LDRD and STRD accesses to 64-bit aligned locations are 64-bit single-copy
> | atomic as seen by translation table walks and accesses to translation
> | tables.
> | ...
> | Load/store multiple instructions, such as LDM, LDRD, STM, and STRD,
> | generate multiple word accesses, each of which is a separate access
> | for the purpose of determining ordering.
> 
> Note carefully the wording in the ARM ARM in the second paragraph -
> it's not saying that LDRD and STRD accesses are single-copy atomic
> to all viewers, but it's limited to the translation tables.

Yes, I raised this (in private I think) when Will proposed similar
kernel changes. But we discussed with the ARM architecture guys and even
though the ARM ARM states that this, in practice the CPUs just implement
full 64-bit atomic accesses.

> Sure, you can argue that the translation tables are just normal memory
> accesses, but in that case why use the above wording if not to permit
> them to be multiple-copy accesses as stated in the paragraph above
> and elsewhere in the ARM ARM in the paragraph below.
> 
> Maybe an error in the ARM ARM?  It doesn't seem wise through to permit
> userspace to assume that LDRD/STRD are atomic in userspace given the
> above wording unless the ARM ARM gets fixed.

Not an error in the ARM ARM but I don't think ARM is going to extend
this definition (not an easy process for such modifications). For
practical purposes, CPUs with LPAE implement 64-bit atomics and it's of
real benefit for some user-space cases.

Maybe a better alternative would be to add it via __v7_proc on
individual CPUs (A7 and A15).

-- 
Catalin


From linux at arm.linux.org.uk  Mon Apr 22 10:28:45 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Mon, 22 Apr 2013 15:28:45 +0100
Subject: [RFC v2] video: ARM CLCD: Add DT & CDF support
In-Reply-To: <1366306402-21651-1-git-send-email-pawel.moll@arm.com>
References: <20130418102444.GL14496@n2100.arm.linux.org.uk>
 <1366306402-21651-1-git-send-email-pawel.moll@arm.com>
Message-ID: <20130422142845.GO14496@n2100.arm.linux.org.uk>

On Thu, Apr 18, 2013 at 06:33:21PM +0100, Pawel Moll wrote:
> This patch adds basic DT bindings for the PL11x CLCD cells
> and make their fbdev driver use them, together with the
> Common Display Framework.
> 
> The DT provides information about the hardware configuration
> and limitations (eg. the largest supported resolution)
> but the video modes come exclusively from the Common
> Display Framework drivers, referenced to by the standard CDF
> binding.
> 
> Signed-off-by: Pawel Moll <pawel.moll at arm.com>

Much better.

I will point out though that there be all sorts of worms here when you
come to the previous ARM evaluation boards (which is why the capabilities
stuff got written in the first place) where there's a horrid mixture of
BGR/RGB ordering at various levels of the system - some of which must be
set correctly because the CLCD output isn't strictly used as R bits
G bits and B bits (to support different formats from the CLCD's native
formats.)


From marex at denx.de  Mon Apr 22 10:30:48 2013
From: marex at denx.de (Marek Vasut)
Date: Mon, 22 Apr 2013 16:30:48 +0200
Subject: [PATCH RESEND] video: mxsfb: Fix colors display on lower color
 depth
In-Reply-To: <51750EB9.3020301@free-electrons.com>
References: <1366618310-7068-1-git-send-email-maxime.ripard@free-electrons.com>
 <201304221116.18080.marex@denx.de> <51750EB9.3020301@free-electrons.com>
Message-ID: <201304221630.48644.marex@denx.de>

Dear Maxime Ripard,

> Hi Marek,
> 
> Le 22/04/2013 11:16, Marek Vasut a ?crit :
> > Dear Maxime Ripard,
> > 
> >> The current code always registers as a 32 bits display, and uses the
> >> hardware to drop the MSB of each color to abjust to the interface width
> >> used by the panel.
> >> 
> >> This results on 18 bits (and probably 16 bits display as well) in colors
> >> being displayed poorly, because the MSB are obviously the most important
> >> bits for each color definition.
> >> 
> >> The default controller behaviour when using an interface width smaller
> >> than the color depth is to drop the LSBs of each color, which makes more
> >> sense because you lose the least important part of the color definition.
> >> 
> >> So, to fix the colors display, just get back to the default controller
> >> behaviour.
> >> 
> >> Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
> > 
> > Did you receive my latest email? Check M28EVK (imx28-m28evk.dts), it uses
> > 18bit LCD and works without this patch I think.
> 
> Thanks for the pointer. You mentionned in your other mail that it was
> wired on 24bits but that the screen is actually 18 bits. I went to
> search for the schematics to look at the wirings to see what could
> differ, but I couldn't find any for the M28EVK. Are they publicly
> available?

Yes, [1] page 6 .

[1] http://www.denx-cs.de/doku/sites/default/files/M28EVK_V20_0.pdf

Best regards,
Marek Vasut


From pawel.moll at arm.com  Mon Apr 22 10:34:39 2013
From: pawel.moll at arm.com (Pawel Moll)
Date: Mon, 22 Apr 2013 15:34:39 +0100
Subject: [PATCH] clk: vexpress: Add separate SP810 driver
In-Reply-To: <20130422142555.GN14496@n2100.arm.linux.org.uk>
References: <1363358409-5693-1-git-send-email-pawel.moll@arm.com>
 <20130417222630.19887.75481@quantum> <1366305802.3077.37.camel@hornet>
 <20130422142555.GN14496@n2100.arm.linux.org.uk>
Message-ID: <1366641279.3203.15.camel@hornet>

On Mon, 2013-04-22 at 15:25 +0100, Russell King - ARM Linux wrote:
> >         /* Switch the parent if necessary */
> > -       if (old_parent != new_parent)
> > +       if (old_parent != new_parent) {
> > +               clk_prepare(new_parent);
> >                 clk_set_parent(hw->clk, new_parent);
> > +               clk_unprepare(old_parent);
> > +       }
> > 
> > So, to summarize, the patch that works for me is below.
> 
> So what if the old parent clock wasn't prepared?

The clk_prepare() does __clk_prepare(clk->parent) before
clk->ops->prepare(clk->kw), so the old_parent is always prepared.

Pawe?




From andre.przywara at linaro.org  Mon Apr 22 10:35:42 2013
From: andre.przywara at linaro.org (Andre Przywara)
Date: Mon, 22 Apr 2013 16:35:42 +0200
Subject: [PATCH] ARM: KVM: iterate over all CPUs for CPU compatibility
 check
In-Reply-To: <0d25b7378e6e13be4e3c599c4325f2b4@localhost>
References: <51680AF9.7040109@arm.com>
 <d455f2823b9639af8d38d30f2c3234bd@localhost>
 <CAEDV+gJuFG49oQ=BEaCHcTP=nHVyX8ALw6076dR_C1s7TuyqXQ@mail.gmail.com>
 <d47697abd39a0d5d41f5ac110a40e261@localhost>
 <CAEDV+gK9==sXYxRVZ8JVFYPiw3_xgzZBbydEwPunmnocNLKXrQ@mail.gmail.com>
 <CAFEAcA-bPoa8YoPuHPmupzfUW+yR233XquK79eNorzcRpFiK=g@mail.gmail.com>
 <516BCAD0.9000708@linaro.org>
 <CAJRNFKJoBzgt4UhxsH65_LyhcGXPnzB_pg3q-zeYT2OVv59q4A@mail.gmail.com>
 <516BFD13.1000400@linaro.org>
 <20130415134837.GI9827@mudshark.cambridge.arm.com>
 <CAEDV+gJB7Bj9O7pftFqoYQ=goORjdurBnEfQVmC5arDuNJfpBg@mail.gmail.com>
 <32d532438f5b621e40679aea9f5888c7@localhost> <516E586C.5030407@linaro.org>
 <8e0bda3fd84d1b0c5aa55161ca178a8e@localhost>
 <CAEDV+g+3nkdvbLdj0m-ZdDKt0JY2vgzhP2AQA2nf=R3h4yTQmQ@mail.gmail.com>
 <51713F91.5080102@linaro.org>
 <CAEDV+gL=rbxxBRgYdHxBj_C9ZBFbuORaG0jcSzEUJ7pO9-Fqkg@mail.gmail.com>
 <517512CA.6070503@linaro.org> <517518E3.5020209@arm.com>
 <0d25b7378e6e13be4e3c599c4325f2b4@localhost>
Message-ID: <51754ABE.7030802@linaro.org>

On 04/22/2013 01:14 PM, Marc Zyngier wrote:
> On Mon, 22 Apr 2013 12:02:59 +0100, Marc Zyngier <marc.zyngier at arm.com>
> wrote:
>> On 22/04/13 11:36, Andre Przywara wrote:
>>> On 04/19/2013 06:13 PM, Christoffer Dall wrote:
>>>> On Fri, Apr 19, 2013 at 5:58 AM, Andre Przywara
>>>> <andre.przywara at linaro.org> wrote:
>>>>> On 04/17/2013 11:12 AM, Christoffer Dall wrote:
>>>>>>
>>>>>>   ...
>>>>>>
>>>>>> You could also try installing a vector handler early and detect
>>>>>> faults,
>>>>>> and add an alternative return path from the init function with some
>>>>>> error reporting value in r0 or something like that, just for
>>>>>> debugging,
>>>>>> naturally, but that could be a way to detect if we really are taking
>>>>>> recursive faults here.
>>>>>
>>>>>
>>>>> OK, I added code to return earlier on CPUs not from cluster 0.
>>>>> Indeed it hangs in the HSCR write. The two A15s pass this
> instruction,
>>>>> writing 0x30c5187F into the register.
>>>>> This means all the fixed bits for A15 correctly, C,A,M and I set and
>>>>> WXN,
>>>>> EE, TE cleared. FI was also cleared
>>>>> The A7 wanted to write the very same value. I tried to set bit 21,
>>>>> which
>>>>> kind of the A7 TRM hints to do: but no change.
>>>>> Before the HSCLTR write, the register reads 0x30c50878, with SCTLR
>>>>> being
>>>>> 0x30c5387d.
>>>>> So the code wants to set M, A, C and I in HSCLTR. Interestingly SCTLR
>>>>> has
>>>>> the V bits set, could that be an issue?
>>>>>
>>>> Can you try writing 0x30c50879 into the register instead? Basically
>>>> check to see if enabling caches or alignment checks causes the issue,
>>>> or if it is indeed enabling the MMU that's the issue... If that works,
>>>> start a bisect on the remaining bits. Also, just for fun, could you
>>>> try flushing the entire I-cache before writing into the HSCLTR?
>>>
>>> OK, both clearing the I-bit and doing an "isb; ICIALLU" before the
> "isb;
>>> write HSCLTR; isb" worked, the kernel boots on and KVM is enabled.
>>>

Arrgh! While cleaning up the code I saw that I had left a debug exit 
point early in init.S, so the HSCTLR write was not executed. Fixing this 
I can now say that cleaning the I-cache and even disabling it does not 
help. Sorry for the premature hooray!
In fact the only thing that makes the kernel boot is cleaning the M bit 
(disabling the MMU), which is a debug hint, but by no means a useful 
workaround :-(

So the problem still persists.

>>> I could easily make a patch, but I am not sure how to proceed from
> here:
>>>
>>> 1.) At least I don't have an understanding why this is only a problem
> on
>>> A7 and not on A15. I would feel better if we have an explanation for
>>> this. Mark, Will, Peter: any ideas?
>>
>> Blink!
>>
>> Can you check your board.txt config file? It should have a line that
>> starts with "SCC: 0x400 ..."
>>
>> If not, can you add a line that reads:
>> SCC: 0x400 0x00000000
>
> Actually you, may want to try:
> SCC: 0x400 0x3330c00
>
> instead, as Peter pointed out that some bits are flagged as reserved in
> the TRM...

I tried to play with SCC 0x400 for two boots, but it didn't change 
anything. Didn't do the full scale of possible HSCLTR bits with and 
without this, though. Does that make sense to do this, or was SCC 0x400 
only for cache problems?

Regards,
Andre.



From linux at arm.linux.org.uk  Mon Apr 22 10:36:16 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Mon, 22 Apr 2013 15:36:16 +0100
Subject: [PATCHv2] arm: Preserve TPIDRURW on context switch
In-Reply-To: <517168BB.3070903@dawncrow.de>
References: <517168BB.3070903@dawncrow.de>
Message-ID: <20130422143616.GP14496@n2100.arm.linux.org.uk>

On Fri, Apr 19, 2013 at 05:54:35PM +0200, Andr? Hentschel wrote:
> From: =?UTF-8?q?Andr=C3=A9=20Hentschel?= <nerv at dawncrow.de>
> 
> There are more and more applications coming to WinRT, Wine could support them,
> but mostly they expect to have the thread environment block (TEB) in TPIDRURW.
> This register must be preserved per thread instead of being cleared.
> 
> Signed-off-by: Andr? Hentschel <nerv at dawncrow.de>

This actually makes things less efficient all round, because you
now use the value immediately after loading, which means it will cause
pipeline stalls, certainly on older CPUs.

Could you please rework the patch to try avoiding soo many modifications
to the way things have been done here?


From agraf at suse.de  Mon Apr 22 10:50:58 2013
From: agraf at suse.de (Alexander Graf)
Date: Mon, 22 Apr 2013 16:50:58 +0200
Subject: [RFC] arm64: Early printk support for virtio-mmio console devices.
In-Reply-To: <CALrVBkub+TABrrBwh4+P6S5TGL1qSmnZrd1cbGgj6JiRpY=rOA@mail.gmail.com>
References: <1366264344-28025-1-git-send-email-pranavkumar@linaro.org>
 <87wqs02uws.fsf@rustcorp.com.au>
 <CAAHg+HiHKV+8hBT1QWe4hSxocCX6wpRd3bCPWB7zU8jVFmPuAA@mail.gmail.com>
 <87ehe3bbsm.fsf@rustcorp.com.au>
 <CALrVBkub+TABrrBwh4+P6S5TGL1qSmnZrd1cbGgj6JiRpY=rOA@mail.gmail.com>
Message-ID: <88344511-0EFA-4EA1-9793-5D25E8DA8239@suse.de>


On 22.04.2013, at 05:10, Anup Patel wrote:

> On 22 April 2013 06:51, Rusty Russell <rusty at rustcorp.com.au> wrote:
>> 
>> Pranavkumar Sawargaonkar <pranavkumar at linaro.org> writes:
>>> On 18 April 2013 12:21, Rusty Russell <rusty at rustcorp.com.au> wrote:
>>>> 
>>>> PranavkumarSawargaonkar <pranavkumar at linaro.org> writes:
>>>>> From: Pranavkumar Sawargaonkar <pranavkumar at linaro.org>
>>>>> 
>>>>> This patch implements early printk support for virtio-mmio console
>>>>> devices without using any hypercalls.
>>>> 
>>>> This makes some sense, though not sure that early console *read* makes
>>>> much sense.  I can see the PCI version of this being useful as well.
>>> 
>>> Read can be useful for "mach-virt" which will have only virtio console
>>> as a console device. Then if someone wants to have UEFI or any other
>>> boot-loader emulation, which expects user to input few things, in that
>>> case read might become handy.
>> 
>> But implementing virtio inside a bootloader has already been done for
>> coreboot, for example.  A bootloader probably wants a virtio block
>> device, so a console is trivial.
>> 
>> A single writable field for debugging makes sense.  Anything more is far
>> less certain.
> 
> The early read can be handy for bootloader who don't want to implement
> complete VirtIO programming.

Virtio is trivial. Seriously. Don't invent new secondary interfaces to the same thing just because you're afraid to write 5 lines of code instead of 2.


Alex

> 
> IMHO, early read would be totally optional for host and will not
> introduce any new config register so it is good to have in VirtIO
> console spec. Also, without early read the read behavior of early_rw
> field would be undefined in VirtIO console spec.
> 
>> 
>> Thanks,
>> Rusty.
> 
> Best Regards,
> Anup
> _______________________________________________
> kvmarm mailing list
> kvmarm at lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm



From linux at arm.linux.org.uk  Mon Apr 22 10:51:23 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Mon, 22 Apr 2013 15:51:23 +0100
Subject: [PATCH v5 0/9] Reorganize R8A7779/Marzen USB code
In-Reply-To: <201304200155.13492.sergei.shtylyov@cogentembedded.com>
References: <201304200155.13492.sergei.shtylyov@cogentembedded.com>
Message-ID: <20130422145122.GQ14496@n2100.arm.linux.org.uk>

On Sat, Apr 20, 2013 at 01:55:12AM +0400, Sergei Shtylyov wrote:
> Hello.
> 
>    Here's the set of 9 patches against the Simon Horman's 'renesas.git' repo,
> 'renesas-next-20130419' tag.  It was created to fix the shortcomings in the
> R8A7779/Marzen USB platform code and R8A7779 USB common PHY driver, and so
> spans both arch/arm/mach-shmobile/ and drivers/usb/ subtrees (some patches have
> to touch both subtrees). The patches were conceived with the complete
> bisectability goal in mind.
> 
> [1/9] ARM: shmobile: Marzen: move USB EHCI, OHCI, and PHY devices to R8A7779 code
> [2/9] ehci-platform: add pre_setup() method to platform data
> [3/9] ARM: shmobile: r8a7779: setup EHCI internal buffer
> [4/9] rcar-phy: remove EHCI internal buffer setup
> [5/9] ARM: shmobile: r8a7779: remove USB PHY 2nd memory resource
> [6/9] rcar-phy: correct base address
> [7/9] rcar-phy: add platform data
> [8/9] ARM: shmobile: Marzen: pass platform data to USB PHY device
> [9/9] rcar-phy: handle platform data

Please can you rethink how you use get_maintainers.pl and send out
patches?

Sending them "To" everyone who get_maintainers.pl spits out is all well
and good, but it means that there's no discrimination between those who
have a primary interest in the patches and those who don't.

Examples of people with a primary interest: those maintaining the
platforms and/or those who you want to merge your patches.  These
should be on the To: line.

Those who don't: everyone else who may have an interest - these go on
the Cc: line.

You're about the only person I regularly get patches for platforms which
are sent To: me all the time, and really they are not "important" for
me (though they are important enough for me to be Cc'd).

What I'm saying is that having come back from a vacation last Tuesday,
I could not just scan through this mailbox for all messages marked "To"
me and treat those as being more important than everything else, because
soo many of yours were captured by that.  And I'm still tacking the
backlog today, almost a week later.

Please be more considerate to those who you're mailing.

(Also, make sure you don't honor the Mail-Followup-To: header, which
will lead your mailer to keep placing all recipients into the To:
header on reply - because it breaks the above reasoning.  The To:
header should be those recipients who you are directly discussing, and
Cc: is for "interested side parties".)

Thanks.


From shawn.guo at linaro.org  Mon Apr 22 10:57:29 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Mon, 22 Apr 2013 22:57:29 +0800
Subject: [PATCH 3/3] pinctrl: add MVF pinctrl driver
In-Reply-To: <1365753432-14247-1-git-send-email-b35083@freescale.com>
References: <1365753432-14247-1-git-send-email-b35083@freescale.com>
Message-ID: <20130422145727.GA27475@S2101-09.ap.freescale.net>

On Fri, Apr 12, 2013 at 03:57:12PM +0800, Jingchang Lu wrote:
> It adds Freescale Vybrid Family pin controller
> driver to I.MX IOMUXC common driver architecture.
> The only difference is the MUX and CONF register
> is the same on MVF platform, so the defined
> config value including the mux_mode int DTS.
> 
This make no sense.  We should patch pinctrl-imx driver to support MVF.

> Signed-off-by: Jingchang Lu <b35083 at freescale.com>
> ---
>  .../bindings/pinctrl/fsl,mvf-pinctrl.txt           |  825 ++++++++
>  drivers/pinctrl/Kconfig                            |    8 +
>  drivers/pinctrl/Makefile                           |    1 +
>  drivers/pinctrl/pinctrl-mvf.c                      | 2042 ++++++++++++++++++++

We just removed those big arrays of imx_pin_reg from imx pinctrl soc
drivers.  Please do not bring it back for MVF.

Shawn



From arnd at arndb.de  Mon Apr 22 11:16:45 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 22 Apr 2013 17:16:45 +0200
Subject: [PATCH 0/4] ARM 64 bit sched_clock take #2
In-Reply-To: <1366417746-24990-1-git-send-email-sboyd@codeaurora.org>
References: <51709FD7.8050408@gmail.com>
 <1366417746-24990-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <201304221716.46105.arnd@arndb.de>

On Saturday 20 April 2013, Stephen Boyd wrote:
> This is what I was thinking. I don't see why we can't move this to generic code
> and have arm64 use it too. Those patches will follow once I find an arm64
> compiler.

I don't have enough background to review the patches, but I know that you can
find an arm64 compiler in Ubuntu Raring. If you are running that on one
of your sysstems, just 'apt-get install gcc-aarch64-linux-gnu'.

	Arnd


From will.deacon at arm.com  Mon Apr 22 11:18:37 2013
From: will.deacon at arm.com (Will Deacon)
Date: Mon, 22 Apr 2013 16:18:37 +0100
Subject: [PATCHv2] arm: Preserve TPIDRURW on context switch
In-Reply-To: <20130422143616.GP14496@n2100.arm.linux.org.uk>
References: <517168BB.3070903@dawncrow.de>
 <20130422143616.GP14496@n2100.arm.linux.org.uk>
Message-ID: <20130422151836.GA15665@mudshark.cambridge.arm.com>

On Mon, Apr 22, 2013 at 03:36:16PM +0100, Russell King - ARM Linux wrote:
> On Fri, Apr 19, 2013 at 05:54:35PM +0200, Andr? Hentschel wrote:
> > From: =?UTF-8?q?Andr=C3=A9=20Hentschel?= <nerv at dawncrow.de>
> > 
> > There are more and more applications coming to WinRT, Wine could support them,
> > but mostly they expect to have the thread environment block (TEB) in TPIDRURW.
> > This register must be preserved per thread instead of being cleared.
> > 
> > Signed-off-by: Andr? Hentschel <nerv at dawncrow.de>
> 
> This actually makes things less efficient all round, because you
> now use the value immediately after loading, which means it will cause
> pipeline stalls, certainly on older CPUs.
> 
> Could you please rework the patch to try avoiding soo many modifications
> to the way things have been done here?

copy_thread also needs updating so that the *register* value for the parent
is copied to the child, since the parent may have written the register
after the last context-switch, meaning that tp_value is out-of-date.

Will


From nicolas.pitre at linaro.org  Mon Apr 22 11:18:58 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Mon, 22 Apr 2013 11:18:58 -0400 (EDT)
Subject: [RFC PATCH] drivers: bus: add ARM CCI support
In-Reply-To: <20130422142457.GM14496@n2100.arm.linux.org.uk>
References: <1365691679-28674-1-git-send-email-lorenzo.pieralisi@arm.com>
 <1365691679-28674-2-git-send-email-lorenzo.pieralisi@arm.com>
 <51702B70.9000908@codeaurora.org>
 <alpine.LFD.2.03.1304181341020.17375@syhkavp.arg>
 <20130422142457.GM14496@n2100.arm.linux.org.uk>
Message-ID: <alpine.LFD.2.03.1304221118100.17375@syhkavp.arg>

On Mon, 22 Apr 2013, Russell King - ARM Linux wrote:

> On Thu, Apr 18, 2013 at 01:54:04PM -0400, Nicolas Pitre wrote:
> > On Thu, 18 Apr 2013, Stephen Boyd wrote:
> > 
> > > On 04/11/13 07:47, Lorenzo Pieralisi wrote:
> > > > diff --git a/drivers/bus/arm-cci.c b/drivers/bus/arm-cci.c
> > > > new file mode 100644
> > > > index 0000000..81953de
> > > > --- /dev/null
> > > > +++ b/drivers/bus/arm-cci.c
> > > [...]
> > > > +static void notrace cci_port_control(unsigned int port, bool enable)
> > > > +{
> > > > +	void __iomem *base = ports[port].base;
> > > > +
> > > > +	if (!base)
> > > > +		return;
> > > > +
> > > > +	writel_relaxed(enable, base + CCI_PORT_CTRL);
> > > > +	while (readl_relaxed(cci_ctrl_base + CCI_CTRL_STATUS) & 0x1)
> > > > +			;
> > > 
> > > cpu_relax()?
> > 
> > In some cases there is no more cache coherence when this is called and 
> > the hardware might not be in a good state to cope with whatever action 
> > people might be tempted to insert into cpu_relax().  After the CCI is 
> > disabled it is important to keep a low profile and not touch anything 
> > global. With some early hardware revision, even a DMB here was harmful.
> 
> It would be useful if there was a comment in the code explaining this.
> As it stands, you _will_ get a stream of patches from kernel janitors
> itching to add cpu_relax() there.

Absolutely right.


Nicolas


From Ian.Campbell at citrix.com  Mon Apr 22 11:21:09 2013
From: Ian.Campbell at citrix.com (Ian Campbell)
Date: Mon, 22 Apr 2013 16:21:09 +0100
Subject: [Xen-devel] [PATCH v6 1/4] arm: introduce psci_smp_ops
In-Reply-To: <alpine.DEB.2.02.1304191739120.7254@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1304031239550.5078@kaball.uk.xensource.com>
 <1365167495-18508-1-git-send-email-stefano.stabellini@eu.citrix.com>
 <20130418161341.GB14496@n2100.arm.linux.org.uk>
 <alpine.DEB.2.02.1304181714560.7254@kaball.uk.xensource.com>
 <alpine.LFD.2.03.1304181237480.17375@syhkavp.arg>
 <alpine.DEB.2.02.1304181749260.7254@kaball.uk.xensource.com>
 <alpine.LFD.2.03.1304181336280.17375@syhkavp.arg>
 <alpine.DEB.2.02.1304191035360.7254@kaball.uk.xensource.com>
 <alpine.LFD.2.03.1304191146230.17375@syhkavp.arg>
 <1366388166.29403.2.camel@dagon.hellion.org.uk>
 <alpine.LFD.2.03.1304191223280.17375@syhkavp.arg>
 <alpine.DEB.2.02.1304191739120.7254@kaball.uk.xensource.com>
Message-ID: <1366644069.20256.8.camel@zakaz.uk.xensource.com>

On Fri, 2013-04-19 at 18:06 +0100, Stefano Stabellini wrote:
> On Fri, 19 Apr 2013, Nicolas Pitre wrote:
> > On Fri, 19 Apr 2013, Ian Campbell wrote:
> > 
> > > On Fri, 2013-04-19 at 16:47 +0100, Nicolas Pitre wrote:
> > > > No one should be probing registers without making sure it is safe to do 
> > > > so.  Even on non virtualized hardware this can be a dangerous thing to 
> > > > do.
> > > 
> > > Won't people writing per machine code consider, not unreasonably, that
> > > having been called through a mdesc machine specific hook constitutes
> > > enough "making sure" that they think it is safe to touch registers which
> > > are specific to that machine?
> > 
> > Remember that this hook was introduced to decide at run time between 
> > different possibilities for SMP ops on the _same_ machine configuration.  
> > That machine shouldn't do things which is not permitted on either 
> > possible alternatives already.  So far the actual usage of that hook 
> > only looks in the DT to make a decision.  But even if it were to touch 
> > the hardware, that means it has to be safe to do so on all the possible 
> > hardware variations this mdesc is associated to.
> 
> This last sentence is the key.
> 
> It is not guaranteed that being safe on "all the possible hardware
> variations this mdesc is associated to" and being safe on Xen are the
> same thing.
> 
> What if the same magic configuration register exists on all the possible
> variations of the platform?
> I understand that it is unlikely but I think it is a possibility.

I think it is actually quite likely for such configuration registers,
nvram etc to exist on all variants of a platform and not all that
unlikely that smp_init might want to consult them.

> If we don't take further precautions I'll be forced to regularly scan
> the list for smp_init implementations and look for possible breakages,
> pointing the unaware author of the patches to this conversation.
> Honestly it is not my idea of fun.
> 
> 
> > And if Xen wants to emulate one of those hardware alternatives, then it 
> > better be ready to emulate it properly, or manage for _another_ mdesc to 
> > be selected instead.  That's why mach-virt was introduced.
> 
> I don't mean to argue pointlessly here, but I thought that it was clear
> that Xen does not emulate any hardware interfaces at all.
> 
> Of course when a convenient virtualization aware hardware interface is
> available (the vGIC for example) Xen is going to use it, but other than
> that no emulation is going to be done.

I think the key thing that non-Xen folks aren't aware of is that
although Xen passes the majority of the underlying hardware to the dom0
kernel to manage one of the few things it does not expose to guests
(where "guests" includes dom0) is the SMP topology of the underlying system.

The physical CPUs are managed/scheduled/etc by the hypervisor and it is
the hypervisor which will need to be aware of big.LITTLE and MCPM etc.

The guests, and again this includes dom0, see only a set of VCPUs which
are scheduled amongst the PCPUs by the hypervisor. It is not unusual to
configure dom0 to have less VCPUs than there are PCPUs in the system.
Currently the VCPUs are all considered to be uniform i.e. there is no
big.LITTLE exposed to guests, although the hypervisor will most likely
eventually support it and so may be scheduling the VCPUs among the big
and LITTLE PCPUs according to $THINGS.

I don't think we want to go the route of mandating a 1:1 PCPU:VCPU
relationship for dom0 for Xen on ARM.

Ian.



From vinayakm.list at gmail.com  Mon Apr 22 11:23:00 2013
From: vinayakm.list at gmail.com (vinayakm.list at gmail.com)
Date: Mon, 22 Apr 2013 20:53:00 +0530
Subject: [PATCH] mm: add an option to disable bounce
Message-ID: <1366644180-6140-1-git-send-email-vinayakm.list@gmail.com>

From: Vinayak Menon <vinayakm.list at gmail.com>

There are times when HIGHMEM is enabled, but
we don't prefer CONFIG_BOUNCE to be enabled.
CONFIG_BOUNCE can reduce the block device
throughput, and this is not ideal for machines
where we don't gain much by enabling it. So
provide an option to deselect CONFIG_BOUNCE. The
observation was made while measuring eMMC throughput
using iozone on an ARM device with 1GB RAM.

Signed-off-by: Vinayak Menon <vinayakm.list at gmail.com>
---
 mm/Kconfig |    6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/mm/Kconfig b/mm/Kconfig
index 3bea74f..29f9736 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -263,8 +263,14 @@ config ZONE_DMA_FLAG
 	default "1"
 
 config BOUNCE
+	bool "Enable bounce buffers"
 	def_bool y
 	depends on BLOCK && MMU && (ZONE_DMA || HIGHMEM)
+	help
+	  Enable bounce buffers for devices that cannot access
+	  the full range of memory available to the CPU. Enabled
+	  by default when ZONE_DMA or HIGMEM is selected, but you
+	  may say n to override this.
 
 # On the 'tile' arch, USB OHCI needs the bounce pool since tilegx will often
 # have more than 4GB of memory, but we don't currently use the IOTLB to present
-- 
1.7.10.4



From lorenzo.pieralisi at arm.com  Mon Apr 22 11:27:23 2013
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Mon, 22 Apr 2013 16:27:23 +0100
Subject: [RFC PATCH v2 01/13] ARM: DT: kernel: move temporary cpu map stack
 array to static data
In-Reply-To: <1366644455-16550-1-git-send-email-lorenzo.pieralisi@arm.com>
References: <1366644455-16550-1-git-send-email-lorenzo.pieralisi@arm.com>
Message-ID: <1366644455-16550-2-git-send-email-lorenzo.pieralisi@arm.com>

As the number of CPUs increase, the temporary array allocated on the
stack in arm_dt_init_cpu_maps() can become too big and trigger stack
issues.
This patch moves the allocated memory to static __initdata so that stack
data is not used anymore to allocate the temporary array.
Memory is marked as __initdata since it need not be persistent after boot.

Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
---
 arch/arm/kernel/devtree.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
index 70f1bde..f149217 100644
--- a/arch/arm/kernel/devtree.c
+++ b/arch/arm/kernel/devtree.c
@@ -78,11 +78,12 @@ void __init arm_dt_init_cpu_maps(void)
 	 * contain a list of MPIDR[23:0] values where MPIDR[31:24] must
 	 * read as 0.
 	 */
+	static u32 tmp_map[NR_CPUS] __initdata = {
+				[0 ... NR_CPUS-1] = UINT_MAX };
 	struct device_node *cpu, *cpus;
 	u32 i, j, cpuidx = 1;
 	u32 mpidr = is_smp() ? read_cpuid_mpidr() & MPIDR_HWID_BITMASK : 0;
 
-	u32 tmp_map[NR_CPUS] = { [0 ... NR_CPUS-1] = UINT_MAX };
 	bool bootcpu_valid = false;
 	cpus = of_find_node_by_path("/cpus");
 
-- 
1.7.12




From lorenzo.pieralisi at arm.com  Mon Apr 22 11:27:24 2013
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Mon, 22 Apr 2013 16:27:24 +0100
Subject: [RFC PATCH v2 02/13] ARM: mach-mv78xx0: cpus/cpu node dts updates
In-Reply-To: <1366644455-16550-1-git-send-email-lorenzo.pieralisi@arm.com>
References: <1366644455-16550-1-git-send-email-lorenzo.pieralisi@arm.com>
Message-ID: <1366644455-16550-3-git-send-email-lorenzo.pieralisi@arm.com>

This patch updates the in-kernel dts files according to the latest cpus
and cpu bindings updates for ARM.

Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
---
 arch/arm/boot/dts/armada-370-xp.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi b/arch/arm/boot/dts/armada-370-xp.dtsi
index 6f1acc7..79a6689 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -24,6 +24,7 @@
 
 	cpus {
 		cpu at 0 {
+			reg = <0>;
 			compatible = "marvell,sheeva-v7";
 		};
 	};
-- 
1.7.12




From lorenzo.pieralisi at arm.com  Mon Apr 22 11:27:22 2013
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Mon, 22 Apr 2013 16:27:22 +0100
Subject: [RFC PATCH v2 00/13] ARM: DT cpu bindings updates
Message-ID: <1366644455-16550-1-git-send-email-lorenzo.pieralisi@arm.com>

This patchset is an update of a previous posting:

http://lists.infradead.org/pipermail/linux-arm-kernel/2013-April/163310.html

v2 changes:

- Reworded DT cpu bindings
- Split the set, with per-mach specific dts updates
- Updated cpu node compatible string list
- Defined behaviour of OS running on v8 in AArch32

The introduction of DT cpus/cpu bindings for ARM requires well established
rules to enforce the reg property definition for 32-bit and 64-bit ARM
processors, inclusive of legacy and current uniprocessor/SMP systems.

ARM 64 bit architecture also requires dtb compiled for 64-bit configurations
to be reused for kernels running in 32 bit mode, so the cpus/cpu bindings
specification must be made compliant to cope with this configuration.

Patch #1 of this series is a fix and is included to have a clean patch
series and should get reviewed and merged separately.

Patch #2-13, along with some kernel fixes related to DT parsing function,
update the cpu node bindings and in kernel dts files to cope with legacy,
current and upcoming ARM systems.

In-kernel device tree source files are updated to comply with the latest
specification, so thorough testing is required in order to validate all
changes on all affected ARM systems, in particular systems with exotic
MPIDR configurations that are likely to break with the changes provided.

Code relying on the reg property size to be 4-bytes will break when
dtb compiled for 64-bit kernels are used to boot a 32-bit system so
kernel code relying on that (bogus) assumption must be updated properly.

Lorenzo Pieralisi (13):
  ARM: DT: kernel: move temporary cpu map stack array to static data
  ARM: mach-mv78xx0: cpus/cpu node dts updates
  ARM: mach-at91: cpus/cpu node dts updates
  ARM: mach-exynos: cpus/cpu nodes dts updates
  ARM: mach-imx: cpus/cpu nodes dts updates
  ARM: mach-lpc32xx: cpus/cpu nodes dts updates
  ARM: mach-omap2: cpus/cpu nodes dts updates
  ARM: mach-picoxcell: cpus/cpu nodes dts updates
  ARM: mach-shmobile: cpus/cpu nodes dts updates
  ARM: mach-spear: cpus/cpu nodes dts updates
  ARM: mach-sunxi: cpus/cpu nodes dts updates
  ARM: mach-vt8500: cpus/cpu nodes dts updates
  ARM: DT: kernel: DT cpu node bindings update

 Documentation/devicetree/bindings/arm/cpus.txt | 378 ++++++++++++++++++++++---
 arch/arm/boot/dts/armada-370-xp.dtsi           |   1 +
 arch/arm/boot/dts/at91sam9260.dtsi             |   2 +-
 arch/arm/boot/dts/at91sam9263.dtsi             |   2 +-
 arch/arm/boot/dts/at91sam9g45.dtsi             |   2 +-
 arch/arm/boot/dts/at91sam9n12.dtsi             |   2 +-
 arch/arm/boot/dts/exynos5440.dtsi              |   7 +
 arch/arm/boot/dts/imx23.dtsi                   |   2 +-
 arch/arm/boot/dts/imx28.dtsi                   |   2 +-
 arch/arm/boot/dts/lpc32xx.dtsi                 |   2 +-
 arch/arm/boot/dts/omap3.dtsi                   |   4 +
 arch/arm/boot/dts/omap4.dtsi                   |   5 +
 arch/arm/boot/dts/omap5.dtsi                   |   5 +
 arch/arm/boot/dts/picoxcell-pc3x2.dtsi         |   2 +-
 arch/arm/boot/dts/picoxcell-pc3x3.dtsi         |   2 +-
 arch/arm/boot/dts/r8a7740.dtsi                 |   3 +
 arch/arm/boot/dts/sh7372.dtsi                  |   4 +
 arch/arm/boot/dts/spear3xx.dtsi                |   2 +-
 arch/arm/boot/dts/spear600.dtsi                |   2 +-
 arch/arm/boot/dts/sunxi.dtsi                   |   4 +
 arch/arm/boot/dts/wm8505.dtsi                  |   2 +-
 arch/arm/kernel/devtree.c                      |  85 ++++--
 22 files changed, 431 insertions(+), 89 deletions(-)

-- 
1.7.12




From lorenzo.pieralisi at arm.com  Mon Apr 22 11:27:26 2013
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Mon, 22 Apr 2013 16:27:26 +0100
Subject: [RFC PATCH v2 04/13] ARM: mach-exynos: cpus/cpu nodes dts updates
In-Reply-To: <1366644455-16550-1-git-send-email-lorenzo.pieralisi@arm.com>
References: <1366644455-16550-1-git-send-email-lorenzo.pieralisi@arm.com>
Message-ID: <1366644455-16550-5-git-send-email-lorenzo.pieralisi@arm.com>

This patch updates the in-kernel dts files according to the latest cpus
and cpu bindings updates for ARM.

Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
---
 arch/arm/boot/dts/exynos5440.dtsi | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5440.dtsi b/arch/arm/boot/dts/exynos5440.dtsi
index 5f3562a..eda21d5 100644
--- a/arch/arm/boot/dts/exynos5440.dtsi
+++ b/arch/arm/boot/dts/exynos5440.dtsi
@@ -24,8 +24,12 @@
 	};
 
 	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
 		cpu at 0 {
 			compatible = "arm,cortex-a15";
+			reg = <0x0>;
 			timer {
 				compatible = "arm,armv7-timer";
 				interrupts = <1 13 0xf08>;
@@ -34,6 +38,7 @@
 		};
 		cpu at 1 {
 			compatible = "arm,cortex-a15";
+			reg = <0x1>;
 			timer {
 				compatible = "arm,armv7-timer";
 				interrupts = <1 14 0xf08>;
@@ -42,6 +47,7 @@
 		};
 		cpu at 2 {
 			compatible = "arm,cortex-a15";
+			reg = <0x2>;
 			timer {
 				compatible = "arm,armv7-timer";
 				interrupts = <1 14 0xf08>;
@@ -50,6 +56,7 @@
 		};
 		cpu at 3 {
 			compatible = "arm,cortex-a15";
+			reg = <0x3>;
 			timer {
 				compatible = "arm,armv7-timer";
 				interrupts = <1 14 0xf08>;
-- 
1.7.12




From lorenzo.pieralisi at arm.com  Mon Apr 22 11:27:27 2013
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Mon, 22 Apr 2013 16:27:27 +0100
Subject: [RFC PATCH v2 05/13] ARM: mach-imx: cpus/cpu nodes dts updates
In-Reply-To: <1366644455-16550-1-git-send-email-lorenzo.pieralisi@arm.com>
References: <1366644455-16550-1-git-send-email-lorenzo.pieralisi@arm.com>
Message-ID: <1366644455-16550-6-git-send-email-lorenzo.pieralisi@arm.com>

This patch updates the in-kernel dts files according to the latest cpus
and cpu bindings updates for ARM.

Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
---
 arch/arm/boot/dts/imx23.dtsi | 2 +-
 arch/arm/boot/dts/imx28.dtsi | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/imx23.dtsi b/arch/arm/boot/dts/imx23.dtsi
index 56afcf4..d98330c 100644
--- a/arch/arm/boot/dts/imx23.dtsi
+++ b/arch/arm/boot/dts/imx23.dtsi
@@ -24,7 +24,7 @@
 
 	cpus {
 		cpu at 0 {
-			compatible = "arm,arm926ejs";
+			compatible = "arm,arm926";
 		};
 	};
 
diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
index 7ba4966..8c5a3ba 100644
--- a/arch/arm/boot/dts/imx28.dtsi
+++ b/arch/arm/boot/dts/imx28.dtsi
@@ -33,7 +33,7 @@
 
 	cpus {
 		cpu at 0 {
-			compatible = "arm,arm926ejs";
+			compatible = "arm,arm926";
 		};
 	};
 
-- 
1.7.12




From lorenzo.pieralisi at arm.com  Mon Apr 22 11:27:25 2013
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Mon, 22 Apr 2013 16:27:25 +0100
Subject: [RFC PATCH v2 03/13] ARM: mach-at91: cpus/cpu node dts updates
In-Reply-To: <1366644455-16550-1-git-send-email-lorenzo.pieralisi@arm.com>
References: <1366644455-16550-1-git-send-email-lorenzo.pieralisi@arm.com>
Message-ID: <1366644455-16550-4-git-send-email-lorenzo.pieralisi@arm.com>

This patch updates the in-kernel dts files according to the latest cpus
and cpu bindings updates for ARM.

Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
---
 arch/arm/boot/dts/at91sam9260.dtsi | 2 +-
 arch/arm/boot/dts/at91sam9263.dtsi | 2 +-
 arch/arm/boot/dts/at91sam9g45.dtsi | 2 +-
 arch/arm/boot/dts/at91sam9n12.dtsi | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/at91sam9260.dtsi b/arch/arm/boot/dts/at91sam9260.dtsi
index cb7bcc5..2e9de85 100644
--- a/arch/arm/boot/dts/at91sam9260.dtsi
+++ b/arch/arm/boot/dts/at91sam9260.dtsi
@@ -33,7 +33,7 @@
 	};
 	cpus {
 		cpu at 0 {
-			compatible = "arm,arm926ejs";
+			compatible = "arm,arm926";
 		};
 	};
 
diff --git a/arch/arm/boot/dts/at91sam9263.dtsi b/arch/arm/boot/dts/at91sam9263.dtsi
index 271d4de..25c4725 100644
--- a/arch/arm/boot/dts/at91sam9263.dtsi
+++ b/arch/arm/boot/dts/at91sam9263.dtsi
@@ -30,7 +30,7 @@
 	};
 	cpus {
 		cpu at 0 {
-			compatible = "arm,arm926ejs";
+			compatible = "arm,arm926";
 		};
 	};
 
diff --git a/arch/arm/boot/dts/at91sam9g45.dtsi b/arch/arm/boot/dts/at91sam9g45.dtsi
index 6b1d4ca..cf647d1 100644
--- a/arch/arm/boot/dts/at91sam9g45.dtsi
+++ b/arch/arm/boot/dts/at91sam9g45.dtsi
@@ -36,7 +36,7 @@
 	};
 	cpus {
 		cpu at 0 {
-			compatible = "arm,arm926ejs";
+			compatible = "arm,arm926";
 		};
 	};
 
diff --git a/arch/arm/boot/dts/at91sam9n12.dtsi b/arch/arm/boot/dts/at91sam9n12.dtsi
index 7750f98..d531ae3 100644
--- a/arch/arm/boot/dts/at91sam9n12.dtsi
+++ b/arch/arm/boot/dts/at91sam9n12.dtsi
@@ -32,7 +32,7 @@
 	};
 	cpus {
 		cpu at 0 {
-			compatible = "arm,arm926ejs";
+			compatible = "arm,arm926";
 		};
 	};
 
-- 
1.7.12




From lorenzo.pieralisi at arm.com  Mon Apr 22 11:27:28 2013
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Mon, 22 Apr 2013 16:27:28 +0100
Subject: [RFC PATCH v2 06/13] ARM: mach-lpc32xx: cpus/cpu nodes dts updates
In-Reply-To: <1366644455-16550-1-git-send-email-lorenzo.pieralisi@arm.com>
References: <1366644455-16550-1-git-send-email-lorenzo.pieralisi@arm.com>
Message-ID: <1366644455-16550-7-git-send-email-lorenzo.pieralisi@arm.com>

This patch updates the in-kernel dts files according to the latest cpus
and cpu bindings updates for ARM.

Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
---
 arch/arm/boot/dts/lpc32xx.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/lpc32xx.dtsi b/arch/arm/boot/dts/lpc32xx.dtsi
index 1582f48..c376975 100644
--- a/arch/arm/boot/dts/lpc32xx.dtsi
+++ b/arch/arm/boot/dts/lpc32xx.dtsi
@@ -19,7 +19,7 @@
 
 	cpus {
 		cpu at 0 {
-			compatible = "arm,arm926ejs";
+			compatible = "arm,arm926";
 		};
 	};
 
-- 
1.7.12




From lorenzo.pieralisi at arm.com  Mon Apr 22 11:27:32 2013
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Mon, 22 Apr 2013 16:27:32 +0100
Subject: [RFC PATCH v2 10/13] ARM: mach-spear: cpus/cpu nodes dts updates
In-Reply-To: <1366644455-16550-1-git-send-email-lorenzo.pieralisi@arm.com>
References: <1366644455-16550-1-git-send-email-lorenzo.pieralisi@arm.com>
Message-ID: <1366644455-16550-11-git-send-email-lorenzo.pieralisi@arm.com>

This patch updates the in-kernel dts files according to the latest cpus
and cpu bindings updates for ARM.

Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
---
 arch/arm/boot/dts/spear3xx.dtsi | 2 +-
 arch/arm/boot/dts/spear600.dtsi | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/spear3xx.dtsi b/arch/arm/boot/dts/spear3xx.dtsi
index c2a852d..485d4d8 100644
--- a/arch/arm/boot/dts/spear3xx.dtsi
+++ b/arch/arm/boot/dts/spear3xx.dtsi
@@ -18,7 +18,7 @@
 
 	cpus {
 		cpu at 0 {
-			compatible = "arm,arm926ejs";
+			compatible = "arm,arm926";
 		};
 	};
 
diff --git a/arch/arm/boot/dts/spear600.dtsi b/arch/arm/boot/dts/spear600.dtsi
index 19f99dc..0498700 100644
--- a/arch/arm/boot/dts/spear600.dtsi
+++ b/arch/arm/boot/dts/spear600.dtsi
@@ -16,7 +16,7 @@
 
 	cpus {
 		cpu at 0 {
-			compatible = "arm,arm926ejs";
+			compatible = "arm,arm926";
 		};
 	};
 
-- 
1.7.12




From lorenzo.pieralisi at arm.com  Mon Apr 22 11:27:33 2013
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Mon, 22 Apr 2013 16:27:33 +0100
Subject: [RFC PATCH v2 11/13] ARM: mach-sunxi: cpus/cpu nodes dts updates
In-Reply-To: <1366644455-16550-1-git-send-email-lorenzo.pieralisi@arm.com>
References: <1366644455-16550-1-git-send-email-lorenzo.pieralisi@arm.com>
Message-ID: <1366644455-16550-12-git-send-email-lorenzo.pieralisi@arm.com>

This patch updates the in-kernel dts files according to the latest cpus
and cpu bindings updates for ARM.

Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
---
 arch/arm/boot/dts/sunxi.dtsi | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/sunxi.dtsi b/arch/arm/boot/dts/sunxi.dtsi
index 8b36abe..447a0f0 100644
--- a/arch/arm/boot/dts/sunxi.dtsi
+++ b/arch/arm/boot/dts/sunxi.dtsi
@@ -17,8 +17,12 @@
 	interrupt-parent = <&intc>;
 
 	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
 		cpu at 0 {
 			compatible = "arm,cortex-a8";
+			reg = <0x0>;
 		};
 	};
 
-- 
1.7.12




From lorenzo.pieralisi at arm.com  Mon Apr 22 11:27:34 2013
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Mon, 22 Apr 2013 16:27:34 +0100
Subject: [RFC PATCH v2 12/13] ARM: mach-vt8500: cpus/cpu nodes dts updates
In-Reply-To: <1366644455-16550-1-git-send-email-lorenzo.pieralisi@arm.com>
References: <1366644455-16550-1-git-send-email-lorenzo.pieralisi@arm.com>
Message-ID: <1366644455-16550-13-git-send-email-lorenzo.pieralisi@arm.com>

This patch updates the in-kernel dts files according to the latest cpus
and cpu bindings updates for ARM.

Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
---
 arch/arm/boot/dts/wm8505.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/wm8505.dtsi b/arch/arm/boot/dts/wm8505.dtsi
index e74a1c0..a470808 100644
--- a/arch/arm/boot/dts/wm8505.dtsi
+++ b/arch/arm/boot/dts/wm8505.dtsi
@@ -13,7 +13,7 @@
 
 	cpus {
 		cpu at 0 {
-			compatible = "arm,arm926ejs";
+			compatible = "arm,arm926";
 		};
 	};
 
-- 
1.7.12




From lorenzo.pieralisi at arm.com  Mon Apr 22 11:27:29 2013
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Mon, 22 Apr 2013 16:27:29 +0100
Subject: [RFC PATCH v2 07/13] ARM: mach-omap2: cpus/cpu nodes dts updates
In-Reply-To: <1366644455-16550-1-git-send-email-lorenzo.pieralisi@arm.com>
References: <1366644455-16550-1-git-send-email-lorenzo.pieralisi@arm.com>
Message-ID: <1366644455-16550-8-git-send-email-lorenzo.pieralisi@arm.com>

This patch updates the in-kernel dts files according to the latest cpus
and cpu bindings updates for ARM.

Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
---
 arch/arm/boot/dts/omap3.dtsi | 4 ++++
 arch/arm/boot/dts/omap4.dtsi | 5 +++++
 arch/arm/boot/dts/omap5.dtsi | 5 +++++
 3 files changed, 14 insertions(+)

diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 1acc261..b4e2b8d 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -21,8 +21,12 @@
 	};
 
 	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
 		cpu at 0 {
 			compatible = "arm,cortex-a8";
+			reg = <0x0>;
 		};
 	};
 
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 739bb79..9c5f7c2 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -28,13 +28,18 @@
 	};
 
 	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
 		cpu at 0 {
 			compatible = "arm,cortex-a9";
 			next-level-cache = <&L2>;
+			reg = <0x0>;
 		};
 		cpu at 1 {
 			compatible = "arm,cortex-a9";
 			next-level-cache = <&L2>;
+			reg = <0x1>;
 		};
 	};
 
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 790bb2a..d2106b6 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -31,8 +31,12 @@
 	};
 
 	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
 		cpu at 0 {
 			compatible = "arm,cortex-a15";
+			reg = <0x0>;
 			timer {
 				compatible = "arm,armv7-timer";
 				/* 14th PPI IRQ, active low level-sensitive */
@@ -42,6 +46,7 @@
 		};
 		cpu at 1 {
 			compatible = "arm,cortex-a15";
+			reg = <0x1>;
 			timer {
 				compatible = "arm,armv7-timer";
 				/* 14th PPI IRQ, active low level-sensitive */
-- 
1.7.12




From lorenzo.pieralisi at arm.com  Mon Apr 22 11:27:31 2013
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Mon, 22 Apr 2013 16:27:31 +0100
Subject: [RFC PATCH v2 09/13] ARM: mach-shmobile: cpus/cpu nodes dts updates
In-Reply-To: <1366644455-16550-1-git-send-email-lorenzo.pieralisi@arm.com>
References: <1366644455-16550-1-git-send-email-lorenzo.pieralisi@arm.com>
Message-ID: <1366644455-16550-10-git-send-email-lorenzo.pieralisi@arm.com>

This patch updates the in-kernel dts files according to the latest cpus
and cpu bindings updates for ARM.

Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
---
 arch/arm/boot/dts/r8a7740.dtsi | 3 +++
 arch/arm/boot/dts/sh7372.dtsi  | 4 ++++
 2 files changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7740.dtsi b/arch/arm/boot/dts/r8a7740.dtsi
index 798fa35..b47bb36 100644
--- a/arch/arm/boot/dts/r8a7740.dtsi
+++ b/arch/arm/boot/dts/r8a7740.dtsi
@@ -14,8 +14,11 @@
 	compatible = "renesas,r8a7740";
 
 	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
 		cpu at 0 {
 			compatible = "arm,cortex-a9";
+			reg = <0x0>;
 		};
 	};
 };
diff --git a/arch/arm/boot/dts/sh7372.dtsi b/arch/arm/boot/dts/sh7372.dtsi
index 677fc60..78478af 100644
--- a/arch/arm/boot/dts/sh7372.dtsi
+++ b/arch/arm/boot/dts/sh7372.dtsi
@@ -14,8 +14,12 @@
 	compatible = "renesas,sh7372";
 
 	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
 		cpu at 0 {
 			compatible = "arm,cortex-a8";
+			reg = <0x0>;
 		};
 	};
 };
-- 
1.7.12




From lorenzo.pieralisi at arm.com  Mon Apr 22 11:27:35 2013
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Mon, 22 Apr 2013 16:27:35 +0100
Subject: [RFC PATCH v2 13/13] ARM: DT: kernel: DT cpu node bindings update
In-Reply-To: <1366644455-16550-1-git-send-email-lorenzo.pieralisi@arm.com>
References: <1366644455-16550-1-git-send-email-lorenzo.pieralisi@arm.com>
Message-ID: <1366644455-16550-14-git-send-email-lorenzo.pieralisi@arm.com>

In order to extend the current cpu nodes bindings to newer CPUs
inclusive of AArch64 and to update support for older ARM CPUs this
patch updates device tree documentation for the cpu nodes bindings.

Main changes:

- adds 64-bit bindings (inclusive of cpus node #address-cells updates)
- defines behaviour on pre and post v7 uniprocessor systems
- adds ARM 11MPcore specific reg property definition

DT cpu map parsing code must be made compliant with the latest bindings
updates, hence this patch also updates the arm_dt_init_cpu_maps() function
with checks and additional parsing rules.

Uniprocessor systems predating v7 do not parse the cpus node at all
since the reg property is meaningless on those systems.

Device trees for 64-bit systems can be taken as device tree input also
for 64-bit CPUs running in 32-bit mode. The code checks that the reg entries
are zeroed as required in the respective fields and detects automatically
the cpus node #address-cells value so that device tree written for
64-bit ARM platforms (cpus #address-cells == 2) can still be taken as
input. The correct device tree entries are to be set up by the boot
loader, kernel code just checks that device tree entries in the cpus
node are as expected for a 32-bit CPU (reg[63:24] == 0).

cpu node entries with invalid reg property or containing duplicates are
ignored and the device tree parsing is not stopped anymore when such
entries are encountered, the device tree cpu entry is just skipped.

A device tree with cpu nodes missing the boot CPU MPIDR is considered a
hard error and the kernel flags this up as a bug to force firmware updates.

Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
---
 Documentation/devicetree/bindings/arm/cpus.txt | 378 ++++++++++++++++++++++---
 arch/arm/kernel/devtree.c                      |  82 ++++--
 2 files changed, 384 insertions(+), 76 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt
index f32494d..82684ca 100644
--- a/Documentation/devicetree/bindings/arm/cpus.txt
+++ b/Documentation/devicetree/bindings/arm/cpus.txt
@@ -1,77 +1,361 @@
-* ARM CPUs binding description
+=================
+ARM CPUs bindings
+=================
 
 The device tree allows to describe the layout of CPUs in a system through
 the "cpus" node, which in turn contains a number of subnodes (ie "cpu")
 defining properties for every cpu.
 
-Bindings for CPU nodes follow the ePAPR standard, available from:
-
-http://devicetree.org
-
-For the ARM architecture every CPU node must contain the following properties:
-
-- device_type:	must be "cpu"
-- reg:		property matching the CPU MPIDR[23:0] register bits
-		reg[31:24] bits must be set to 0
-- compatible:	should be one of:
-		"arm,arm1020"
-		"arm,arm1020e"
-		"arm,arm1022"
-		"arm,arm1026"
-		"arm,arm720"
-		"arm,arm740"
-		"arm,arm7tdmi"
-		"arm,arm920"
-		"arm,arm922"
-		"arm,arm925"
-		"arm,arm926"
-		"arm,arm940"
-		"arm,arm946"
-		"arm,arm9tdmi"
-		"arm,cortex-a5"
-		"arm,cortex-a7"
-		"arm,cortex-a8"
-		"arm,cortex-a9"
-		"arm,cortex-a15"
-		"arm,arm1136"
-		"arm,arm1156"
-		"arm,arm1176"
-		"arm,arm11mpcore"
-		"faraday,fa526"
-		"intel,sa110"
-		"intel,sa1100"
-		"marvell,feroceon"
-		"marvell,mohawk"
-		"marvell,xsc3"
-		"marvell,xscale"
-
-Example:
+Bindings for CPU nodes follow the ePAPR v1.1 standard, available from:
+
+https://www.power.org/documentation/epapr-version-1-1/
+
+with updates for 32-bit and 64-bit ARM systems provided in this document.
+
+================================
+Convention used in this document
+================================
+
+This document follows the conventions described in the ePAPR v1.1, with
+the addition:
+
+- square brackets define bitfields, eg reg[7:0] value of the bitfield in
+  the reg property contained in bits 7 down to 0
+
+=====================================
+cpus and cpu node bindings definition
+=====================================
+
+The ARM architecture, in accordance with the ePAPR, requires the cpus and cpu
+nodes to be present and contain the properties described below.
+
+- cpus node
+
+	Description: Container of cpu nodes
+
+	The node name must be "cpus".
+
+	A cpus node must define the following properties:
+
+	- #address-cells
+		Usage: required
+		Value type: <u32>
+		Definition: must be set to 1 for 32-bit systems and 2 for
+			    64-bit systems
+	- #size-cells
+		Usage: required
+		Value type: <u32>
+		Definition: must be set to 0
+
+- cpu node
+
+	Description: Describes a CPU in an ARM based system
+
+	PROPERTIES
+
+	- device_type
+		Usage: required
+		Value type: <string>
+		Definition: must be "cpu"
+	- reg
+		Usage and definition depend on ARM architecture version and
+		configuration:
+
+			# On uniprocessor ARM architectures previous to v7
+			  this property is optional since they do not define
+			  any register that provides a CPU identifier.
+			  Any value set in the reg property for these CPUs
+			  should be ignored.
+
+			# On ARM 11 MPcore based systems this property is
+			  required and matches the CPUID[11:0] register bits.
+
+			  Bits [11:0] in the reg cell must be set to
+			  bits [11:0] in CPU ID register.
+
+			  All other bits in the reg cell must be set to 0.
+
+			# On 32-bit ARM v7 or later systems this property is
+			  required and matches the CPU MPIDR[23:0] register
+			  bits.
+
+			  Bits [23:0] in the reg cell must be set to
+			  bits [23:0] in MPIDR.
+
+			  All other bits in the reg cell must be set to 0.
+
+			# On ARM v8 64-bit systems, where the reg property
+			  is made up of two cells to accomodate the 64-bit
+			  MPDIR_EL1 register this property is required and
+			  matches:
+
+			  - On systems running the OS in AArch32:
+
+			    The first reg cell must be set to 0.
+
+			    The second reg cell bits [23:0] must be set to
+			    bits [23:0] of MPIDR_EL1, all other bits in the
+			    reg cell must be set to 0.
+
+			  - On systems running the OS in AArch64:
+
+			    The first reg cell bits [7:0] must be set to
+			    bits [39:32] of MPIDR_EL1.
+
+			    The second reg cell bits [23:0] must be set to
+			    bits [23:0] of MPIDR_EL1.
+
+			    All other bits in the reg cells must be set to 0.
+	- compatible:
+		Usage: required
+		Value type: <string>
+		Definition: should be one of:
+			    "arm,arm720"
+			    "arm,arm740"
+			    "arm,arm7tdmi"
+			    "arm,arm920"
+			    "arm,arm922"
+			    "arm,arm925"
+			    "arm,arm926"
+			    "arm,arm940"
+			    "arm,arm946"
+			    "arm,arm9tdmi"
+			    "arm,arm1020"
+			    "arm,arm1022"
+			    "arm,arm1026"
+			    "arm,arm1136"
+			    "arm,arm1156"
+			    "arm,arm1176"
+			    "arm,arm11mpcore"
+			    "arm,cortex-a5"
+			    "arm,cortex-a7"
+			    "arm,cortex-a8"
+			    "arm,cortex-a9"
+			    "arm,cortex-a15"
+			    "arm,cortex-a53"
+			    "arm,cortex-a57"
+			    "arm,cortex-m0"
+			    "arm,cortex-m0+"
+			    "arm,cortex-m1"
+			    "arm,cortex-m3"
+			    "arm,cortex-m4"
+			    "arm,cortex-r4"
+			    "arm,cortex-r5"
+			    "arm,cortex-r7"
+			    "faraday,fa526"
+			    "intel,sa110"
+			    "intel,sa1100"
+			    "marvell,feroceon"
+			    "marvell,mohawk"
+			    "marvell,pj4"
+			    "marvell,sheeva-v7"
+			    "marvell,xsc3"
+			    "marvell,xscale"
+			    "qcom,krait"
+			    "qcom,scorpion"
+	- enable-method
+		Value type: <stringlist>
+		Usage and definition depend on ARM architecture version and
+		configuration:
+			# On ARM v8 64-bit systems running the OS in AArch64,
+			  this property is required and must be "spin-table".
+			# On ARM 32-bit systems or ARM v8 systems running
+			  the OS in AArch32 this property is prohibited.
+
+	- cpu-release-addr
+		Usage: required for systems that have an "enable-method"
+		       property value of "spin-table".
+		Value type: <prop-encoded-array>
+		Definition:
+			# On ARM v8 64-bit systems must be a two cell
+			  property identifying a 64-bit zero-initialised
+			  memory location.
+
+Example 1 (dual-cluster big.LITTLE system 32-bit):
 
 	cpus {
 		#size-cells = <0>;
 		#address-cells = <1>;
 
-		CPU0: cpu at 0 {
+		cpu at 0 {
 			device_type = "cpu";
 			compatible = "arm,cortex-a15";
 			reg = <0x0>;
 		};
 
-		CPU1: cpu at 1 {
+		cpu at 1 {
 			device_type = "cpu";
 			compatible = "arm,cortex-a15";
 			reg = <0x1>;
 		};
 
-		CPU2: cpu at 100 {
+		cpu at 100 {
 			device_type = "cpu";
 			compatible = "arm,cortex-a7";
 			reg = <0x100>;
 		};
 
-		CPU3: cpu at 101 {
+		cpu at 101 {
 			device_type = "cpu";
 			compatible = "arm,cortex-a7";
 			reg = <0x101>;
 		};
 	};
+
+Example 2 (Cortex-A8 uniprocessor 32-bit system):
+
+	cpus {
+		#size-cells = <0>;
+		#address-cells = <1>;
+
+		cpu at 0 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a8";
+			reg = <0x0>;
+		};
+
+	};
+
+Example 3 (ARM 1176 uniprocessor 32-bit system):
+
+	cpus {
+		cpu {
+			device_type = "cpu";
+			compatible = "arm,arm1176";
+		};
+	};
+
+Example 4 (ARM Cortex-A57 64-bit system):
+
+cpus {
+	#size-cells = <0>;
+	#address-cells = <2>;
+
+	cpu at 0 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a57";
+		reg = <0x0 0x0>;
+		enable-method = "spin-table";
+		cpu-release-addr = <0 0x20000000>;
+	};
+
+	cpu at 1 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a57";
+		reg = <0x0 0x1>;
+		enable-method = "spin-table";
+		cpu-release-addr = <0 0x20000000>;
+	};
+
+	cpu at 100 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a57";
+		reg = <0x0 0x100>;
+		enable-method = "spin-table";
+		cpu-release-addr = <0 0x20000000>;
+	};
+
+	cpu at 101 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a57";
+		reg = <0x0 0x101>;
+		enable-method = "spin-table";
+		cpu-release-addr = <0 0x20000000>;
+	};
+
+	cpu at 10000 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a57";
+		reg = <0x0 0x10000>;
+		enable-method = "spin-table";
+		cpu-release-addr = <0 0x20000000>;
+	};
+
+	cpu at 10001 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a57";
+		reg = <0x0 0x10001>;
+		enable-method = "spin-table";
+		cpu-release-addr = <0 0x20000000>;
+	};
+
+	cpu at 10100 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a57";
+		reg = <0x0 0x10100>;
+		enable-method = "spin-table";
+		cpu-release-addr = <0 0x20000000>;
+	};
+
+	cpu at 10101 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a57";
+		reg = <0x0 0x10101>;
+		enable-method = "spin-table";
+		cpu-release-addr = <0 0x20000000>;
+	};
+
+	cpu at 100000000 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a57";
+		reg = <0x1 0x0>;
+		enable-method = "spin-table";
+		cpu-release-addr = <0 0x20000000>;
+	};
+
+	cpu at 100000001 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a57";
+		reg = <0x1 0x1>;
+		enable-method = "spin-table";
+		cpu-release-addr = <0 0x20000000>;
+	};
+
+	cpu at 100000100 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a57";
+		reg = <0x1 0x100>;
+		enable-method = "spin-table";
+		cpu-release-addr = <0 0x20000000>;
+	};
+
+	cpu at 100000101 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a57";
+		reg = <0x1 0x101>;
+		enable-method = "spin-table";
+		cpu-release-addr = <0 0x20000000>;
+	};
+
+	cpu at 100010000 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a57";
+		reg = <0x1 0x10000>;
+		enable-method = "spin-table";
+		cpu-release-addr = <0 0x20000000>;
+	};
+
+	cpu at 100010001 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a57";
+		reg = <0x1 0x10001>;
+		enable-method = "spin-table";
+		cpu-release-addr = <0 0x20000000>;
+	};
+
+	cpu at 100010100 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a57";
+		reg = <0x1 0x10100>;
+		enable-method = "spin-table";
+		cpu-release-addr = <0 0x20000000>;
+	};
+
+	cpu at 100010101 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a57";
+		reg = <0x1 0x10101>;
+		enable-method = "spin-table";
+		cpu-release-addr = <0 0x20000000>;
+	};
+};
diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
index f149217..4eda2dc 100644
--- a/arch/arm/kernel/devtree.c
+++ b/arch/arm/kernel/devtree.c
@@ -23,6 +23,7 @@
 #include <asm/setup.h>
 #include <asm/page.h>
 #include <asm/smp_plat.h>
+#include <asm/system_info.h>
 #include <asm/mach/arch.h>
 #include <asm/mach-types.h>
 
@@ -81,48 +82,68 @@ void __init arm_dt_init_cpu_maps(void)
 	static u32 tmp_map[NR_CPUS] __initdata = {
 				[0 ... NR_CPUS-1] = UINT_MAX };
 	struct device_node *cpu, *cpus;
-	u32 i, j, cpuidx = 1;
+	u32 i, j, ac, cpuidx = 1;
 	u32 mpidr = is_smp() ? read_cpuid_mpidr() & MPIDR_HWID_BITMASK : 0;
-
+	int len;
 	bool bootcpu_valid = false;
+
 	cpus = of_find_node_by_path("/cpus");
 
-	if (!cpus)
+	if (!cpus || ((cpu_architecture() < CPU_ARCH_ARMv7) && !is_smp()))
 		return;
 
+	if (WARN_ON(of_property_read_u32(cpus, "#address-cells", &ac)))
+		ac = of_n_addr_cells(cpus);
+
 	for_each_child_of_node(cpus, cpu) {
-		u32 hwid;
+		u64 hwid64;
+		u32 hwid32;
+		const __be32 *prop;
 
 		pr_debug(" * %s...\n", cpu->full_name);
 		/*
-		 * A device tree containing CPU nodes with missing "reg"
-		 * properties is considered invalid to build the
-		 * cpu_logical_map.
+		 * A CPU node with missing or wrong "reg" property is
+		 * considered invalid to build a cpu_logical_map entry.
 		 */
-		if (of_property_read_u32(cpu, "reg", &hwid)) {
-			pr_debug(" * %s missing reg property\n",
-				     cpu->full_name);
-			return;
+		prop = of_get_property(cpu, "reg", &len);
+		if (!prop || len < (ac * sizeof(*prop))) {
+				WARN(1, " * %s node missing/wrong reg"
+					 " property, skipped\n",
+					 cpu->full_name);
+				goto next;
 		}
-
 		/*
-		 * 8 MSBs must be set to 0 in the DT since the reg property
-		 * defines the MPIDR[23:0].
+		 * Always read reg as u64 value.
+		 * For dts with #address-cells == 1 hwid64[63:32]
+		 * will be set to 0 by of_read_number.
+		 * Toss away the top 32 bits and store value in hwid32.
+		 */
+		hwid32 = hwid64 = of_read_number(prop, ac);
+		/*
+		 * hwid64[63:24] must be always be 0 since the reg
+		 * property defines the MPIDR[23:0] bits regardless
+		 * of the cpus node #address-cells value.
 		 */
-		if (hwid & ~MPIDR_HWID_BITMASK)
-			return;
+		if (hwid64 & ~MPIDR_HWID_BITMASK) {
+			WARN(1, " * %s node reg[63:24] must be 0 on"
+			       " 32-bit dts, got %#016llx, skipped\n",
+			       cpu->full_name, hwid64);
+			goto next;
+		}
 
 		/*
 		 * Duplicate MPIDRs are a recipe for disaster.
 		 * Scan all initialized entries and check for
-		 * duplicates. If any is found just bail out.
+		 * duplicates. If any is found just ignore the CPU.
 		 * temp values were initialized to UINT_MAX
 		 * to avoid matching valid MPIDR[23:0] values.
 		 */
 		for (j = 0; j < cpuidx; j++)
-			if (WARN(tmp_map[j] == hwid, "Duplicate /cpu reg "
-						     "properties in the DT\n"))
-				return;
+			if (WARN(tmp_map[j] == hwid32, " * %s node "
+						"duplicate cpu reg "
+						"property, skipped\n",
+						cpu->full_name))
+				goto next;
 
 		/*
 		 * Build a stashed array of MPIDR values. Numbering scheme
@@ -133,26 +154,29 @@ void __init arm_dt_init_cpu_maps(void)
 		 * logical map built from DT is validated and can be used
 		 * to override the map created in smp_setup_processor_id().
 		 */
-		if (hwid == mpidr) {
+		if (hwid32 == mpidr) {
 			i = 0;
 			bootcpu_valid = true;
 		} else {
 			i = cpuidx++;
 		}
 
-		if (WARN(cpuidx > nr_cpu_ids, "DT /cpu %u nodes greater than "
-					       "max cores %u, capping them\n",
+		if (WARN_ONCE(cpuidx > nr_cpu_ids, "DT cpu %u nodes greater"
+						   " than max cores %u,"
+						   " capping them\n",
 					       cpuidx, nr_cpu_ids)) {
 			cpuidx = nr_cpu_ids;
-			break;
+			goto next;
 		}
 
-		tmp_map[i] = hwid;
+		tmp_map[i] = hwid32;
+next:	;
 	}
-
-	if (WARN(!bootcpu_valid, "DT missing boot CPU MPIDR[23:0], "
-				 "fall back to default cpu_logical_map\n"))
-		return;
+	/*
+	 * A DT missing the boot CPU MPIDR is a really bad omen
+	 * Flag it up as such and force firmware/dtb updates
+	 */
+	BUG_ON(!bootcpu_valid);
 
 	/*
 	 * Since the boot CPU node contains proper data, and all nodes have
-- 
1.7.12




From lorenzo.pieralisi at arm.com  Mon Apr 22 11:27:30 2013
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Mon, 22 Apr 2013 16:27:30 +0100
Subject: [RFC PATCH v2 08/13] ARM: mach-picoxcell: cpus/cpu nodes dts updates
In-Reply-To: <1366644455-16550-1-git-send-email-lorenzo.pieralisi@arm.com>
References: <1366644455-16550-1-git-send-email-lorenzo.pieralisi@arm.com>
Message-ID: <1366644455-16550-9-git-send-email-lorenzo.pieralisi@arm.com>


Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
---
 arch/arm/boot/dts/picoxcell-pc3x2.dtsi | 2 +-
 arch/arm/boot/dts/picoxcell-pc3x3.dtsi | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/picoxcell-pc3x2.dtsi b/arch/arm/boot/dts/picoxcell-pc3x2.dtsi
index f0a8c20..978dbdf 100644
--- a/arch/arm/boot/dts/picoxcell-pc3x2.dtsi
+++ b/arch/arm/boot/dts/picoxcell-pc3x2.dtsi
@@ -22,7 +22,7 @@
 		#size-cells = <0>;
 
 		cpu at 0 {
-			compatible = "arm,1176jz-s";
+			compatible = "arm,arm1176";
 			clock-frequency = <400000000>;
 			reg = <0>;
 			d-cache-line-size = <32>;
diff --git a/arch/arm/boot/dts/picoxcell-pc3x3.dtsi b/arch/arm/boot/dts/picoxcell-pc3x3.dtsi
index daa962d..5fa309e 100644
--- a/arch/arm/boot/dts/picoxcell-pc3x3.dtsi
+++ b/arch/arm/boot/dts/picoxcell-pc3x3.dtsi
@@ -22,7 +22,7 @@
 		#size-cells = <0>;
 
 		cpu at 0 {
-			compatible = "arm,1176jz-s";
+			compatible = "arm,arm1176;
 			cpu-clock = <&arm_clk>, "cpu";
 			reg = <0>;
 			d-cache-line-size = <32>;
-- 
1.7.12




From haojian.zhuang at gmail.com  Mon Apr 22 11:33:44 2013
From: haojian.zhuang at gmail.com (Haojian Zhuang)
Date: Mon, 22 Apr 2013 23:33:44 +0800
Subject: Pinmuxing with devicetree (beaglebone)
In-Reply-To: <201304211143.50961.tim@krieglstein.org>
References: <201304211143.50961.tim@krieglstein.org>
Message-ID: <CAN1soZzz=GRMrmj3rtBkxE74e0JZ4xewR=yVMUeMvp=6Yp34nQ@mail.gmail.com>

On Sun, Apr 21, 2013 at 5:43 PM, Tim Sander <tim at krieglstein.org> wrote:
> Hi
>
> I am currently trying to get pinmuxing working on a beaglebone board with an
> offtree driver. This is for a custom handbuild hardware so i guess there is no
> point in bringing this mainline.
>
> While this is havyly patched 3.8.4 version running over here i think the
> pinmux infrastructure is the new standard way. At least there is a
> pinctrl/44e10800.pinmux directory in debugfs?
>
> My last aproach was using the devicetree but beeing new to this devicetree
> stuff i just got stuck:
> http://comments.gmane.org/gmane.linux.ports.arm.kernel/231204
>
> Now i tried use the way it is described in Documentation/pinctrl.txt but still
> there are the includes missing: #include <linux/pinctrl/consumer.h>.
>
> Also while there is a /sys/kernel/debug/pinctrl/44e10800.pinmux in debugfs i
> found that not so intuitive as the omap_mux which disappeared. Also i didn't
> find any documentation for this debugfs stuff.
>
> So what is the recommended way to get this stupid pinmuxing going. In pre
> devicetree days one would just pick the mux.h include of the platform and
> initialized the muxers which was pretty straight forward. Now with device tree
> its much more complicated. No proper syntax checking as with the c definitions
> and no documentation how to get this magic stuff working :-(.
>
> The whole stuff is build by a ptxdist (a embedded buildsystem) and can be
> found over here:
> https://gitorious.org/ptxdist-beaglebone/ptxdist-beaglebone
>
"pins" node could dump the register configuration if it's pinctrl-single driver.

You can dump this to check whether the right pinmux is set.

I checked your patch in the link.  It seems that you only write the pinmux
configuration without using them.

Don't forget to append this in your DTS file.
     pinctrl-names = "default";
       pinctrl-0 = <&wind_pins>;

There're two documents worth to read for enabling pins for
pinctrl-single driver.
Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt

Regards
Haojian

> Best regards
> Tim
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From mark.rutland at arm.com  Mon Apr 22 11:34:08 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Mon, 22 Apr 2013 16:34:08 +0100
Subject: [PATCH 0/4] ARM 64 bit sched_clock take #2
In-Reply-To: <1366417746-24990-1-git-send-email-sboyd@codeaurora.org>
References: <51709FD7.8050408@gmail.com>
 <1366417746-24990-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <20130422153408.GD3791@e106331-lin.cambridge.arm.com>

Hi Stephen,

On Sat, Apr 20, 2013 at 01:29:02AM +0100, Stephen Boyd wrote:
> This is what I was thinking. I don't see why we can't move this to generic
> code and have arm64 use it too. Those patches will follow once I find an
> arm64 compiler.
> 
> First two patches should probably go in even if the 64 bit stuff doesn't go in
> at the same time.
> 
> Stephen Boyd (4):
>   ARM: sched_clock: Remove unused needs_suspend member
>   ARM: sched_clock: Return suspended count earlier
>   ARM: sched_clock: Add support for >32 bit sched_clock
>   ARM: arch_timer: Move to setup_sched_clock_64()
> 
>  arch/arm/include/asm/sched_clock.h |   5 +-
>  arch/arm/kernel/arch_timer.c       |  14 +----
>  arch/arm/kernel/sched_clock.c      | 111 ++++++++++++++++++++++++++-----------
>  3 files changed, 84 insertions(+), 46 deletions(-)

I wanted to look at the series with more context, but I don't seem to be able
to apply patch 2 and beyond to my tree, and I couldn't figure out what tree
this series was based on.

What do I need to use as the base for this series?

Thanks,
Mark.


From sboyd at codeaurora.org  Mon Apr 22 11:35:42 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Mon, 22 Apr 2013 08:35:42 -0700
Subject: [PATCH 3/4] ARM: sched_clock: Add support for >32 bit sched_clock
In-Reply-To: <20130422104858.GB2572@mudshark.cambridge.arm.com>
References: <1366417746-24990-1-git-send-email-sboyd@codeaurora.org>
 <1366417746-24990-4-git-send-email-sboyd@codeaurora.org>
 <20130422104858.GB2572@mudshark.cambridge.arm.com>
Message-ID: <517558CE.7090602@codeaurora.org>

On 04/22/13 03:48, Will Deacon wrote:
> Hi Stephen,
>
> On Sat, Apr 20, 2013 at 01:29:05AM +0100, Stephen Boyd wrote:
>> The arm architected system counter has at least 56 bits of
>> useable bits. Add support to ARM's sched_clock implementation for
>> counters with more than 32 bits so we can avoid the complexity of
>> dealing with wraparound on these devices while benefiting from
>> the irqtime accounting and suspend/resume handling that the ARM
>> sched_clock code already has.
>>
>> Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
>> ---
>>
>> Maybe we need a union for the epoch_ns usage?
>>
>>  arch/arm/include/asm/sched_clock.h |   2 +
>>  arch/arm/kernel/sched_clock.c      | 101 +++++++++++++++++++++++++++----------
>>  2 files changed, 77 insertions(+), 26 deletions(-)
>>
>> diff --git a/arch/arm/include/asm/sched_clock.h b/arch/arm/include/asm/sched_clock.h
>> index 3d520dd..7fcd2ee 100644
>> --- a/arch/arm/include/asm/sched_clock.h
>> +++ b/arch/arm/include/asm/sched_clock.h
>> @@ -13,4 +13,6 @@ extern void setup_sched_clock(u32 (*read)(void), int bits, unsigned long rate);
>>  
>>  extern unsigned long long (*sched_clock_func)(void);
>>  
>> +extern void setup_sched_clock_64(u64 (*read)(void), int bits,
>> +				 unsigned long rate);
> Curious, but why do we need two setup_sched_clock functions, where the bits
> are passed as a parameter? Can't we just do the right thing if the clock
> claims to be more than 32 bits wide (and get rid of the BUG_ONs at the same
> time)?

This is to avoid having to change a bunch of code that is using
setup_sched_clock() already where their read function returns a u32
instead of a u64. I suppose we could make the 64 bit version fall back
to the 32 bit version if the bits aren't large enough and provide some
sort of u32 wrapper function around the u64 callback. It may also be
useful if we can determine that the timer wraps too quickly even when
there are more than 32 bits.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Mon Apr 22 11:36:14 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Mon, 22 Apr 2013 08:36:14 -0700
Subject: [PATCH 0/4] ARM 64 bit sched_clock take #2
In-Reply-To: <20130422153408.GD3791@e106331-lin.cambridge.arm.com>
References: <51709FD7.8050408@gmail.com>
 <1366417746-24990-1-git-send-email-sboyd@codeaurora.org>
 <20130422153408.GD3791@e106331-lin.cambridge.arm.com>
Message-ID: <517558EE.5020708@codeaurora.org>

On 04/22/13 08:34, Mark Rutland wrote:
> Hi Stephen,
>
> On Sat, Apr 20, 2013 at 01:29:02AM +0100, Stephen Boyd wrote:
>> This is what I was thinking. I don't see why we can't move this to generic
>> code and have arm64 use it too. Those patches will follow once I find an
>> arm64 compiler.
>>
>> First two patches should probably go in even if the 64 bit stuff doesn't go in
>> at the same time.
>>
>> Stephen Boyd (4):
>>   ARM: sched_clock: Remove unused needs_suspend member
>>   ARM: sched_clock: Return suspended count earlier
>>   ARM: sched_clock: Add support for >32 bit sched_clock
>>   ARM: arch_timer: Move to setup_sched_clock_64()
>>
>>  arch/arm/include/asm/sched_clock.h |   5 +-
>>  arch/arm/kernel/arch_timer.c       |  14 +----
>>  arch/arm/kernel/sched_clock.c      | 111 ++++++++++++++++++++++++++-----------
>>  3 files changed, 84 insertions(+), 46 deletions(-)
> I wanted to look at the series with more context, but I don't seem to be able
> to apply patch 2 and beyond to my tree, and I couldn't figure out what tree
> this series was based on.
>
> What do I need to use as the base for this series?

These are based on next-20130419.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation



From nicolas.ferre at atmel.com  Mon Apr 22 11:48:45 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Mon, 22 Apr 2013 17:48:45 +0200
Subject: [RFC PATCH v2 03/13] ARM: mach-at91: cpus/cpu node dts updates
In-Reply-To: <1366644455-16550-4-git-send-email-lorenzo.pieralisi@arm.com>
References: <1366644455-16550-1-git-send-email-lorenzo.pieralisi@arm.com>
 <1366644455-16550-4-git-send-email-lorenzo.pieralisi@arm.com>
Message-ID: <51755BDD.4060007@atmel.com>

On 04/22/2013 05:27 PM, Lorenzo Pieralisi :
> This patch updates the in-kernel dts files according to the latest cpus
> and cpu bindings updates for ARM.
> 
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>

Acked-by: Nicolas Ferre <nicolas.ferre at atmel.com>

Thanks, bye.

> ---
>  arch/arm/boot/dts/at91sam9260.dtsi | 2 +-
>  arch/arm/boot/dts/at91sam9263.dtsi | 2 +-
>  arch/arm/boot/dts/at91sam9g45.dtsi | 2 +-
>  arch/arm/boot/dts/at91sam9n12.dtsi | 2 +-
>  4 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/at91sam9260.dtsi b/arch/arm/boot/dts/at91sam9260.dtsi
> index cb7bcc5..2e9de85 100644
> --- a/arch/arm/boot/dts/at91sam9260.dtsi
> +++ b/arch/arm/boot/dts/at91sam9260.dtsi
> @@ -33,7 +33,7 @@
>  	};
>  	cpus {
>  		cpu at 0 {
> -			compatible = "arm,arm926ejs";
> +			compatible = "arm,arm926";
>  		};
>  	};
>  
> diff --git a/arch/arm/boot/dts/at91sam9263.dtsi b/arch/arm/boot/dts/at91sam9263.dtsi
> index 271d4de..25c4725 100644
> --- a/arch/arm/boot/dts/at91sam9263.dtsi
> +++ b/arch/arm/boot/dts/at91sam9263.dtsi
> @@ -30,7 +30,7 @@
>  	};
>  	cpus {
>  		cpu at 0 {
> -			compatible = "arm,arm926ejs";
> +			compatible = "arm,arm926";
>  		};
>  	};
>  
> diff --git a/arch/arm/boot/dts/at91sam9g45.dtsi b/arch/arm/boot/dts/at91sam9g45.dtsi
> index 6b1d4ca..cf647d1 100644
> --- a/arch/arm/boot/dts/at91sam9g45.dtsi
> +++ b/arch/arm/boot/dts/at91sam9g45.dtsi
> @@ -36,7 +36,7 @@
>  	};
>  	cpus {
>  		cpu at 0 {
> -			compatible = "arm,arm926ejs";
> +			compatible = "arm,arm926";
>  		};
>  	};
>  
> diff --git a/arch/arm/boot/dts/at91sam9n12.dtsi b/arch/arm/boot/dts/at91sam9n12.dtsi
> index 7750f98..d531ae3 100644
> --- a/arch/arm/boot/dts/at91sam9n12.dtsi
> +++ b/arch/arm/boot/dts/at91sam9n12.dtsi
> @@ -32,7 +32,7 @@
>  	};
>  	cpus {
>  		cpu at 0 {
> -			compatible = "arm,arm926ejs";
> +			compatible = "arm,arm926";
>  		};
>  	};
>  
> 


-- 
Nicolas Ferre


From mark.rutland at arm.com  Mon Apr 22 11:51:47 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Mon, 22 Apr 2013 16:51:47 +0100
Subject: [PATCH 0/4] ARM 64 bit sched_clock take #2
In-Reply-To: <517558EE.5020708@codeaurora.org>
References: <51709FD7.8050408@gmail.com>
 <1366417746-24990-1-git-send-email-sboyd@codeaurora.org>
 <20130422153408.GD3791@e106331-lin.cambridge.arm.com>
 <517558EE.5020708@codeaurora.org>
Message-ID: <20130422155147.GA7018@e106331-lin.cambridge.arm.com>

On Mon, Apr 22, 2013 at 04:36:14PM +0100, Stephen Boyd wrote:
> On 04/22/13 08:34, Mark Rutland wrote:
> > Hi Stephen,
> >
> > On Sat, Apr 20, 2013 at 01:29:02AM +0100, Stephen Boyd wrote:
> >> This is what I was thinking. I don't see why we can't move this to generic
> >> code and have arm64 use it too. Those patches will follow once I find an
> >> arm64 compiler.
> >>
> >> First two patches should probably go in even if the 64 bit stuff doesn't go in
> >> at the same time.
> >>
> >> Stephen Boyd (4):
> >>   ARM: sched_clock: Remove unused needs_suspend member
> >>   ARM: sched_clock: Return suspended count earlier
> >>   ARM: sched_clock: Add support for >32 bit sched_clock
> >>   ARM: arch_timer: Move to setup_sched_clock_64()
> >>
> >>  arch/arm/include/asm/sched_clock.h |   5 +-
> >>  arch/arm/kernel/arch_timer.c       |  14 +----
> >>  arch/arm/kernel/sched_clock.c      | 111 ++++++++++++++++++++++++++-----------
> >>  3 files changed, 84 insertions(+), 46 deletions(-)
> > I wanted to look at the series with more context, but I don't seem to be able
> > to apply patch 2 and beyond to my tree, and I couldn't figure out what tree
> > this series was based on.
> >
> > What do I need to use as the base for this series?
> 
> These are based on next-20130419.

Cheers!

Mark.


From plagnioj at jcrosoft.com  Mon Apr 22 11:51:25 2013
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Mon, 22 Apr 2013 17:51:25 +0200
Subject: [PATCH v4 2/2] video: imxfb: Add DT support
In-Reply-To: <20130421081115.GA31179@pengutronix.de>
References: <1366290183-367-1-git-send-email-mpa@pengutronix.de>
 <1366290183-367-3-git-send-email-mpa@pengutronix.de>
 <20130418160614.GF4998@game.jcrosoft.org>
 <20130421081115.GA31179@pengutronix.de>
Message-ID: <20130422155125.GI4998@game.jcrosoft.org>

On 10:11 Sun 21 Apr     , Markus Pargmann wrote:
> On Thu, Apr 18, 2013 at 06:06:14PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > On 15:03 Thu 18 Apr     , Markus Pargmann wrote:
> > > Add devicetree support for imx framebuffer driver. It uses the generic
> > > display bindings and helper functions.
> > > 
> > > Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
> > > Cc: Fabio Estevam <festevam at gmail.com>
> > > Cc: Mark Rutland <mark.rutland at arm.com>
> > > ---
> > > 
> > > Notes:
> > >     Changes in v4:
> > >     - Remove eukrea specific dmacr property.
> > >     - Add optional dmacr property. If not present, the dmacr reset value is not
> > >       changed.
> > >     
> > >     Changes in v3:
> > >     - Fix returncodes of of_read_mode function and print error messages
> > >     - Introduce a lower bound check for bits per pixel
> > >     - Calculate correct bytes per pixel value before using it for the calculation of
> > >     	memory size
> > >     - Change DT property names
> > >     
> > >     Changes in v2:
> > >     - Removed pwmr register property
> > >     - Cleanup of devicetree binding documentation
> > >     - Use default values for pwmr and lscr1
> > > 
> > >  .../devicetree/bindings/video/fsl,imx-fb.txt       |  51 ++++++
> > >  drivers/video/imxfb.c                              | 194 +++++++++++++++++----
> > >  2 files changed, 210 insertions(+), 35 deletions(-)
> > >  create mode 100644 Documentation/devicetree/bindings/video/fsl,imx-fb.txt
> > > 
> > > diff --git a/Documentation/devicetree/bindings/video/fsl,imx-fb.txt b/Documentation/devicetree/bindings/video/fsl,imx-fb.txt
> > > new file mode 100644
> > > index 0000000..aff16a4
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/video/fsl,imx-fb.txt
> > > @@ -0,0 +1,51 @@
> > > +Freescale imx21 Framebuffer
> > > +
> > > +This framebuffer driver supports devices imx1, imx21, imx25, and imx27.
> > > +
> > > +Required properties:
> > > +- compatible : "fsl,<chip>-fb", chip should be imx1 or imx21
> > > +- reg : Should contain 1 register ranges(address and length)
> > > +- interrupts : One interrupt of the fb dev
> > > +
> > > +Required nodes:
> > > +- display: Phandle to a display node as described in
> > > +	Documentation/devicetree/bindings/video/display-timing.txt
> > > +	Additional, the display node has to define properties:
> > > +	- fsl,bpp: Bits per pixel
> > > +	- fsl,pcr: LCDC PCR value
> > > +
> > > +Optional properties:
> > > +- fsl,dmacr: DMA Control Register value. This is optional. By default, the
> > > +	register is not modified as recommended by the datasheet.
> > > +- fsl,lscr1: LCDC Sharp Configuration Register value.
> > > +
> > > +Example:
> > > +
> > > +	imxfb: fb at 10021000 {
> > > +		compatible = "fsl,imx27-fb", "fsl,imx21-fb";
> > you put both when in the doc you request one
> 
> Thanks, fixed.
> 
> > > +		interrupts = <61>;
> > > +		reg = <0x10021000 0x1000>;
> > > +		display = <&display0>;
> > > +	};
> > > +
> > > +	...
> > > +
> > > +	display0: display0 {
> > > +		model = "Primeview-PD050VL1";
> > > +		native-mode = <&timing_disp0>;
> > > +		fsl,bpp = <16>;		/* non-standard but required */
> > there is a generic binding bit-per-pixel use a cross other IP
> 
> I can't find a generic binding for that. There are only 2 other drivers
> using a "bpp" property, but they both use it within different contexts.
> tilcdc panel uses it within a "panel-info" property and via,vt8500-fb
> within modes. So I think it would be better to use a clear distinction
> because there is no generic binding. That was also suggested in comments
> on version 2 of this patch:
> https://patchwork.kernel.org/patch/2220511/

via use bits-per-pixel
atmel ditto
mxs ditto IIRC

Best Regards,
J.
> 
> Regards,
> 
> Markus
> 
> > > +		fsl,pcr = <0xf0c88080>;	/* non-standard but required */
> > > +		display-timings {
> > > +			timing_disp0: 640x480 {
> > > +				hactive = <640>;
> > > +				vactive = <480>;
> > > +				hback-porch = <112>;
> > > +				hfront-porch = <36>;
> > > +				hsync-len = <32>;
> > > +				vback-porch = <33>;
> > > +				vfront-porch = <33>;
> > > +				vsync-len = <2>;
> > > +				clock-frequency = <25000000>;
> > > +			};
> > > +		};
> > > +	};
> > > diff --git a/drivers/video/imxfb.c b/drivers/video/imxfb.c
> > > index ef2b587..e0230f8 100644
> > > --- a/drivers/video/imxfb.c
> > > +++ b/drivers/video/imxfb.c
> > > @@ -32,6 +32,12 @@
> > >  #include <linux/io.h>
> > >  #include <linux/math64.h>
> > >  #include <linux/uaccess.h>
> > > +#include <linux/of.h>
> > > +#include <linux/of_device.h>
> > > +
> > > +#include <video/of_display_timing.h>
> > > +#include <video/of_videomode.h>
> > > +#include <video/videomode.h>
> > >  
> > >  #include <linux/platform_data/video-imxfb.h>
> > >  
> > > @@ -117,10 +123,11 @@
> > >  #define LGWCR_GWAV(alpha)	(((alpha) & 0xff) << 24)
> > >  #define LGWCR_GWE	(1 << 22)
> > >  
> > > +#define IMXFB_LSCR1_DEFAULT 0x00120300
> > > +
> > >  /* Used fb-mode. Can be set on kernel command line, therefore file-static. */
> > >  static const char *fb_mode;
> > >  
> > > -
> > >  /*
> > >   * These are the bitfields for each
> > >   * display depth that we support.
> > > @@ -192,6 +199,19 @@ static struct platform_device_id imxfb_devtype[] = {
> > >  };
> > >  MODULE_DEVICE_TABLE(platform, imxfb_devtype);
> > >  
> > > +static struct of_device_id imxfb_of_dev_id[] = {
> > > +	{
> > > +		.compatible = "fsl,imx1-fb",
> > > +		.data = &imxfb_devtype[IMX1_FB],
> > > +	}, {
> > > +		.compatible = "fsl,imx21-fb",
> > > +		.data = &imxfb_devtype[IMX21_FB],
> > > +	}, {
> > > +		/* sentinel */
> > > +	}
> > > +};
> > > +MODULE_DEVICE_TABLE(of, imxfb_of_dev_id);
> > > +
> > >  static inline int is_imx1_fb(struct imxfb_info *fbi)
> > >  {
> > >  	return fbi->devtype == IMX1_FB;
> > > @@ -324,6 +344,9 @@ static const struct imx_fb_videomode *imxfb_find_mode(struct imxfb_info *fbi)
> > >  	struct imx_fb_videomode *m;
> > >  	int i;
> > >  
> > > +	if (!fb_mode)
> > > +		return &fbi->mode[0];
> > > +
> > >  	for (i = 0, m = &fbi->mode[0]; i < fbi->num_modes; i++, m++) {
> > >  		if (!strcmp(m->mode.name, fb_mode))
> > >  			return m;
> > > @@ -479,6 +502,9 @@ static int imxfb_bl_update_status(struct backlight_device *bl)
> > >  	struct imxfb_info *fbi = bl_get_data(bl);
> > >  	int brightness = bl->props.brightness;
> > >  
> > > +	if (!fbi->pwmr)
> > > +		return 0;
> > > +
> > >  	if (bl->props.power != FB_BLANK_UNBLANK)
> > >  		brightness = 0;
> > >  	if (bl->props.fb_blank != FB_BLANK_UNBLANK)
> > > @@ -719,10 +745,14 @@ static int imxfb_activate_var(struct fb_var_screeninfo *var, struct fb_info *inf
> > >  
> > >  	writel(fbi->pcr, fbi->regs + LCDC_PCR);
> > >  #ifndef PWMR_BACKLIGHT_AVAILABLE
> > > -	writel(fbi->pwmr, fbi->regs + LCDC_PWMR);
> > > +	if (fbi->pwmr)
> > > +		writel(fbi->pwmr, fbi->regs + LCDC_PWMR);
> > >  #endif
> > >  	writel(fbi->lscr1, fbi->regs + LCDC_LSCR1);
> > > -	writel(fbi->dmacr, fbi->regs + LCDC_DMACR);
> > > +
> > > +	/* dmacr = 0 is no valid value, as we need DMA control marks. */
> > > +	if (fbi->dmacr)
> > > +		writel(fbi->dmacr, fbi->regs + LCDC_DMACR);
> > >  
> > >  	return 0;
> > >  }
> > > @@ -758,13 +788,12 @@ static int imxfb_resume(struct platform_device *dev)
> > >  #define imxfb_resume	NULL
> > >  #endif
> > >  
> > > -static int __init imxfb_init_fbinfo(struct platform_device *pdev)
> > > +static int imxfb_init_fbinfo(struct platform_device *pdev)
> > >  {
> > >  	struct imx_fb_platform_data *pdata = pdev->dev.platform_data;
> > >  	struct fb_info *info = dev_get_drvdata(&pdev->dev);
> > >  	struct imxfb_info *fbi = info->par;
> > > -	struct imx_fb_videomode *m;
> > > -	int i;
> > > +	struct device_node *np;
> > >  
> > >  	pr_debug("%s\n",__func__);
> > >  
> > > @@ -795,41 +824,95 @@ static int __init imxfb_init_fbinfo(struct platform_device *pdev)
> > >  	info->fbops			= &imxfb_ops;
> > >  	info->flags			= FBINFO_FLAG_DEFAULT |
> > >  					  FBINFO_READS_FAST;
> > > -	info->var.grayscale		= pdata->cmap_greyscale;
> > > -	fbi->cmap_inverse		= pdata->cmap_inverse;
> > > -	fbi->cmap_static		= pdata->cmap_static;
> > > -	fbi->lscr1			= pdata->lscr1;
> > > -	fbi->dmacr			= pdata->dmacr;
> > > -	fbi->pwmr			= pdata->pwmr;
> > > -	fbi->lcd_power			= pdata->lcd_power;
> > > -	fbi->backlight_power		= pdata->backlight_power;
> > > -
> > > -	for (i = 0, m = &pdata->mode[0]; i < pdata->num_modes; i++, m++)
> > > -		info->fix.smem_len = max_t(size_t, info->fix.smem_len,
> > > -				m->mode.xres * m->mode.yres * m->bpp / 8);
> > > +	if (pdata) {
> > > +		info->var.grayscale		= pdata->cmap_greyscale;
> > > +		fbi->cmap_inverse		= pdata->cmap_inverse;
> > > +		fbi->cmap_static		= pdata->cmap_static;
> > > +		fbi->lscr1			= pdata->lscr1;
> > > +		fbi->dmacr			= pdata->dmacr;
> > > +		fbi->pwmr			= pdata->pwmr;
> > > +		fbi->lcd_power			= pdata->lcd_power;
> > > +		fbi->backlight_power		= pdata->backlight_power;
> > > +	} else {
> > > +		np = pdev->dev.of_node;
> > > +		info->var.grayscale = of_property_read_bool(np,
> > > +						"cmap-greyscale");
> > > +		fbi->cmap_inverse = of_property_read_bool(np, "cmap-inverse");
> > > +		fbi->cmap_static = of_property_read_bool(np, "cmap-static");
> > > +
> > > +		fbi->lscr1 = IMXFB_LSCR1_DEFAULT;
> > > +		of_property_read_u32(np, "fsl,lscr1", &fbi->lscr1);
> > > +
> > > +		of_property_read_u32(np, "fsl,dmacr", &fbi->dmacr);
> > > +
> > > +		/* These two function pointers could be used by some specific
> > > +		 * platforms. */
> > > +		fbi->lcd_power = NULL;
> > > +		fbi->backlight_power = NULL;
> > > +	}
> > > +
> > > +	return 0;
> > > +}
> > > +
> > > +static int imxfb_of_read_mode(struct device *dev, struct device_node *np,
> > > +		struct imx_fb_videomode *imxfb_mode)
> > > +{
> > > +	int ret;
> > > +	struct fb_videomode *of_mode = &imxfb_mode->mode;
> > > +	u32 bpp;
> > > +	u32 pcr;
> > > +
> > > +	ret = of_property_read_string(np, "model", &of_mode->name);
> > > +	if (ret)
> > > +		of_mode->name = NULL;
> > > +
> > > +	ret = of_get_fb_videomode(np, of_mode, OF_USE_NATIVE_MODE);
> > > +	if (ret) {
> > > +		dev_err(dev, "Failed to get videomode from DT\n");
> > > +		return ret;
> > > +	}
> > > +
> > > +	ret = of_property_read_u32(np, "fsl,bpp", &bpp);
> > > +	ret |= of_property_read_u32(np, "fsl,pcr", &pcr);
> > > +
> > > +	if (ret) {
> > > +		dev_err(dev, "Failed to read bpp and pcr from DT\n");
> > > +		return -EINVAL;
> > > +	}
> > > +
> > > +	if (bpp < 1 || bpp > 255) {
> > > +		dev_err(dev, "Bits per pixel have to be between 1 and 255\n");
> > > +		return -EINVAL;
> > > +	}
> > > +
> > > +	imxfb_mode->bpp = bpp;
> > > +	imxfb_mode->pcr = pcr;
> > >  
> > >  	return 0;
> > >  }
> > >  
> > > -static int __init imxfb_probe(struct platform_device *pdev)
> > > +static int imxfb_probe(struct platform_device *pdev)
> > >  {
> > >  	struct imxfb_info *fbi;
> > >  	struct fb_info *info;
> > >  	struct imx_fb_platform_data *pdata;
> > >  	struct resource *res;
> > > +	struct imx_fb_videomode *m;
> > > +	const struct of_device_id *of_id;
> > >  	int ret, i;
> > > +	int bytes_per_pixel;
> > >  
> > >  	dev_info(&pdev->dev, "i.MX Framebuffer driver\n");
> > >  
> > > +	of_id = of_match_device(imxfb_of_dev_id, &pdev->dev);
> > > +	if (of_id)
> > > +		pdev->id_entry = of_id->data;
> > > +
> > >  	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > >  	if (!res)
> > >  		return -ENODEV;
> > >  
> > >  	pdata = pdev->dev.platform_data;
> > > -	if (!pdata) {
> > > -		dev_err(&pdev->dev,"No platform_data available\n");
> > > -		return -ENOMEM;
> > > -	}
> > >  
> > >  	info = framebuffer_alloc(sizeof(struct imxfb_info), &pdev->dev);
> > >  	if (!info)
> > > @@ -837,15 +920,55 @@ static int __init imxfb_probe(struct platform_device *pdev)
> > >  
> > >  	fbi = info->par;
> > >  
> > > -	if (!fb_mode)
> > > -		fb_mode = pdata->mode[0].mode.name;
> > > -
> > >  	platform_set_drvdata(pdev, info);
> > >  
> > >  	ret = imxfb_init_fbinfo(pdev);
> > >  	if (ret < 0)
> > >  		goto failed_init;
> > >  
> > > +	if (pdata) {
> > > +		if (!fb_mode)
> > > +			fb_mode = pdata->mode[0].mode.name;
> > > +
> > > +		fbi->mode = pdata->mode;
> > > +		fbi->num_modes = pdata->num_modes;
> > > +	} else {
> > > +		struct device_node *display_np;
> > > +		fb_mode = NULL;
> > > +
> > > +		display_np = of_parse_phandle(pdev->dev.of_node, "display", 0);
> > > +		if (!display_np) {
> > > +			dev_err(&pdev->dev, "No display defined in devicetree\n");
> > > +			ret = -EINVAL;
> > > +			goto failed_of_parse;
> > > +		}
> > > +
> > > +		/*
> > > +		 * imxfb does not support more modes, we choose only the native
> > > +		 * mode.
> > > +		 */
> > > +		fbi->num_modes = 1;
> > > +
> > > +		fbi->mode = devm_kzalloc(&pdev->dev,
> > > +				sizeof(struct imx_fb_videomode), GFP_KERNEL);
> > > +		if (!fbi->mode) {
> > > +			ret = -ENOMEM;
> > > +			goto failed_of_parse;
> > > +		}
> > > +
> > > +		ret = imxfb_of_read_mode(&pdev->dev, display_np, fbi->mode);
> > > +		if (ret)
> > > +			goto failed_of_parse;
> > > +	}
> > > +
> > > +	/* Calculate maximum bytes used per pixel. In most cases this should
> > > +	 * be the same as m->bpp/8 */
> > > +	m = &fbi->mode[0];
> > > +	bytes_per_pixel = (m->bpp + 7) / 8;
> > > +	for (i = 0; i < fbi->num_modes; i++, m++)
> > > +		info->fix.smem_len = max_t(size_t, info->fix.smem_len,
> > > +				m->mode.xres * m->mode.yres * bytes_per_pixel);
> > > +
> > >  	res = request_mem_region(res->start, resource_size(res),
> > >  				DRIVER_NAME);
> > >  	if (!res) {
> > > @@ -878,7 +1001,8 @@ static int __init imxfb_probe(struct platform_device *pdev)
> > >  		goto failed_ioremap;
> > >  	}
> > >  
> > > -	if (!pdata->fixed_screen_cpu) {
> > > +	/* Seems not being used by anyone, so no support for oftree */
> > > +	if (!pdata || !pdata->fixed_screen_cpu) {
> > >  		fbi->map_size = PAGE_ALIGN(info->fix.smem_len);
> > >  		fbi->map_cpu = dma_alloc_writecombine(&pdev->dev,
> > >  				fbi->map_size, &fbi->map_dma, GFP_KERNEL);
> > > @@ -903,18 +1027,16 @@ static int __init imxfb_probe(struct platform_device *pdev)
> > >  		info->fix.smem_start = fbi->screen_dma;
> > >  	}
> > >  
> > > -	if (pdata->init) {
> > > +	if (pdata && pdata->init) {
> > >  		ret = pdata->init(fbi->pdev);
> > >  		if (ret)
> > >  			goto failed_platform_init;
> > >  	}
> > >  
> > > -	fbi->mode = pdata->mode;
> > > -	fbi->num_modes = pdata->num_modes;
> > >  
> > >  	INIT_LIST_HEAD(&info->modelist);
> > > -	for (i = 0; i < pdata->num_modes; i++)
> > > -		fb_add_videomode(&pdata->mode[i].mode, &info->modelist);
> > > +	for (i = 0; i < fbi->num_modes; i++)
> > > +		fb_add_videomode(&fbi->mode[i].mode, &info->modelist);
> > >  
> > >  	/*
> > >  	 * This makes sure that our colour bitfield
> > > @@ -944,10 +1066,10 @@ static int __init imxfb_probe(struct platform_device *pdev)
> > >  failed_register:
> > >  	fb_dealloc_cmap(&info->cmap);
> > >  failed_cmap:
> > > -	if (pdata->exit)
> > > +	if (pdata && pdata->exit)
> > >  		pdata->exit(fbi->pdev);
> > >  failed_platform_init:
> > > -	if (!pdata->fixed_screen_cpu)
> > > +	if (pdata && !pdata->fixed_screen_cpu)
> > >  		dma_free_writecombine(&pdev->dev,fbi->map_size,fbi->map_cpu,
> > >  			fbi->map_dma);
> > >  failed_map:
> > > @@ -956,6 +1078,7 @@ failed_ioremap:
> > >  failed_getclock:
> > >  	release_mem_region(res->start, resource_size(res));
> > >  failed_req:
> > > +failed_of_parse:
> > >  	kfree(info->pseudo_palette);
> > >  failed_init:
> > >  	platform_set_drvdata(pdev, NULL);
> > > @@ -980,7 +1103,7 @@ static int imxfb_remove(struct platform_device *pdev)
> > >  	unregister_framebuffer(info);
> > >  
> > >  	pdata = pdev->dev.platform_data;
> > > -	if (pdata->exit)
> > > +	if (pdata && pdata->exit)
> > >  		pdata->exit(fbi->pdev);
> > >  
> > >  	fb_dealloc_cmap(&info->cmap);
> > > @@ -1009,6 +1132,7 @@ static struct platform_driver imxfb_driver = {
> > >  	.shutdown	= imxfb_shutdown,
> > >  	.driver		= {
> > >  		.name	= DRIVER_NAME,
> > > +		.of_match_table = imxfb_of_dev_id,
> > >  	},
> > >  	.id_table	= imxfb_devtype,
> > >  };
> > > -- 
> > > 1.8.1.5
> > > 
> > 
> 
> -- 
> Pengutronix e.K.                           |                             |
> Industrial Linux Solutions                 | http://www.pengutronix.de/  |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
> Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From s-anna at ti.com  Mon Apr 22 11:56:57 2013
From: s-anna at ti.com (Anna, Suman)
Date: Mon, 22 Apr 2013 15:56:57 +0000
Subject: [PATCHv3 00/14] drivers: mailbox: framework creation
In-Reply-To: <CABb+yY0RYkVeo2Sb4WsDJY0jf17488FEz0d2CB994eQaSOEsVg@mail.gmail.com>
References: <1363145021-14339-1-git-send-email-s-anna@ti.com>
 <CABb+yY0RYkVeo2Sb4WsDJY0jf17488FEz0d2CB994eQaSOEsVg@mail.gmail.com>
Message-ID: <37C860A02101E749A747FA2D3C1E3C504A5DF7@DLEE11.ent.ti.com>

> 
> Hi Suman,
> 
>   [Resending with mailing-list CCed this time. For some reason LKML doesn't
> appear in reply-to despite this message being fwd'ed from there]
> 
> On Wed, Mar 13, 2013 at 8:53 AM, Suman Anna <s-anna at ti.com> wrote:
> > Hi,
> > Please find the updated mailbox patch series for pulling into linux-next.
> > The series is rebased on top of 3.9-rc2, and includes one new patch to
> > rename an existing mailbox.h added as part of the highbank cpufreq
> > support for 3.9 merge window [1].
> >
> I am to implement IPC protocol and client drivers on a platform that has a master
> processor having control over critical h/w resources, like clock and power
> management, to be used by the MPCore running linux. And there are 2 such IPC
> controllers - one for communication within the MPCore and another for between
> MPCore and the 'Master'.
> 
> I have a few concerns about this api as follows...

Thank Jassi for your comments. I am aware of some of the concerns, Andy Green had highlighted (a) & (b) as well previously, and I am actually working through the next set of patches to fix these. I will post them sometime next week. 

> 
> a) No documentation. Usually the header would have proper documentation of
> data structures and info for users of both side of the api.

I will fix the documentation portion for 3.10. I will also add a TODO as part of the documentation so that it highlights the gaps and work-items.

> 
> b) The api is not scalable. The assumption of just one IPC controller in the
> platform is hardcoded.

Yes, this is a major concern and I will be handling this in the upcoming patches . The current code was primarily based on moving the OMAP mailbox code and expanding it to support the ST DBX500 mailbox. As it is today, it doesn't scale to support multiple IP instances/controllers.

> 
> c) There seems to be no consistent design - mailbox_ops has 12 callback hooks.
> Some, save_ctx, restore_ctx, enable_irq, disable_irq are exported for no
> apparent reason (legacy of a legacy - OMAP), while other hooks are kept private
> to the api.
> I believe OMAP had valid reasons to make IPC clients save/restore context of the
> IPC controller, but I don't think that is the case in general. I2C client drivers don't
> save/restore context of I2C controller's, why should IPC's?  Similarly
> enable/disable_irq of the controller seem too intrusive for a client driver.

Yep, these are exported because of the OMAP legacy TIDSPBRIDGE stack, and should vanish with the addition of runtime_pm support.

> 
> mailbox_ops.mailbox_type_t makes no sense to me. At least not without
> documentation, though I doubt any amount of documentation could help it -
> mailbox.c doesn't even read the member. Btw, isn't every mailbox a
> MBOX_SHARED_MEM_TYPE? A part of data passed via FIFO/REG could point to
> location in shared memory that might have full command/payload for the
> message. Or did I get the meaning of MBOX_SHARED_MEM_TYPE wrong in the
> absence of documentation?

Yes, this needs to be removed, it is a carry-over from the OMAP mailbox code.

> 
> The api seems to worry too much about the low-level details of the IPC controller
> (save/restore context, enable/disable_irq and ack_irq), while it fails to provide a
> tight well-defined interface to client drivers.
> 
> There are also some code issues, which might come as replies to respective
> patches.

Thanks for the review of the patches. I will await your comments, and will address them as incremental patches. 

Regards
Suman

From nicolas.pitre at linaro.org  Mon Apr 22 12:07:23 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Mon, 22 Apr 2013 12:07:23 -0400 (EDT)
Subject: [Xen-devel] [PATCH v6 1/4] arm: introduce psci_smp_ops
In-Reply-To: <1366644069.20256.8.camel@zakaz.uk.xensource.com>
References: <alpine.DEB.2.02.1304031239550.5078@kaball.uk.xensource.com>
 <1365167495-18508-1-git-send-email-stefano.stabellini@eu.citrix.com>
 <20130418161341.GB14496@n2100.arm.linux.org.uk>
 <alpine.DEB.2.02.1304181714560.7254@kaball.uk.xensource.com>
 <alpine.LFD.2.03.1304181237480.17375@syhkavp.arg>
 <alpine.DEB.2.02.1304181749260.7254@kaball.uk.xensource.com>
 <alpine.LFD.2.03.1304181336280.17375@syhkavp.arg>
 <alpine.DEB.2.02.1304191035360.7254@kaball.uk.xensource.com>
 <alpine.LFD.2.03.1304191146230.17375@syhkavp.arg>
 <1366388166.29403.2.camel@dagon.hellion.org.uk>
 <alpine.LFD.2.03.1304191223280.17375@syhkavp.arg>
 <alpine.DEB.2.02.1304191739120.7254@kaball.uk.xensource.com>
 <1366644069.20256.8.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.LFD.2.03.1304221151200.17375@syhkavp.arg>

On Mon, 22 Apr 2013, Ian Campbell wrote:

> On Fri, 2013-04-19 at 18:06 +0100, Stefano Stabellini wrote:
> > On Fri, 19 Apr 2013, Nicolas Pitre wrote:
> > > On Fri, 19 Apr 2013, Ian Campbell wrote:
> > > 
> > > > On Fri, 2013-04-19 at 16:47 +0100, Nicolas Pitre wrote:
> > > > > No one should be probing registers without making sure it is safe to do 
> > > > > so.  Even on non virtualized hardware this can be a dangerous thing to 
> > > > > do.
> > > > 
> > > > Won't people writing per machine code consider, not unreasonably, that
> > > > having been called through a mdesc machine specific hook constitutes
> > > > enough "making sure" that they think it is safe to touch registers which
> > > > are specific to that machine?
> > > 
> > > Remember that this hook was introduced to decide at run time between 
> > > different possibilities for SMP ops on the _same_ machine configuration.  
> > > That machine shouldn't do things which is not permitted on either 
> > > possible alternatives already.  So far the actual usage of that hook 
> > > only looks in the DT to make a decision.  But even if it were to touch 
> > > the hardware, that means it has to be safe to do so on all the possible 
> > > hardware variations this mdesc is associated to.
> > 
> > This last sentence is the key.
> > 
> > It is not guaranteed that being safe on "all the possible hardware
> > variations this mdesc is associated to" and being safe on Xen are the
> > same thing.
> > 
> > What if the same magic configuration register exists on all the possible
> > variations of the platform?
> > I understand that it is unlikely but I think it is a possibility.
> 
> I think it is actually quite likely for such configuration registers,
> nvram etc to exist on all variants of a platform and not all that
> unlikely that smp_init might want to consult them.

In which case the rest of the kernel is also going to consult those 
registers for other purposes.

Again, what's the problem please?

> I think the key thing that non-Xen folks aren't aware of is that
> although Xen passes the majority of the underlying hardware to the dom0
> kernel to manage one of the few things it does not expose to guests
> (where "guests" includes dom0) is the SMP topology of the underlying system.

I suspect it is unlikely to pass on the DT information about the CCI 
either.  Which means that, in the case that started this thread, the 
smp_init function needed by MCPM will simply return false and the next 
priority in the list i.e. plain PSCI will be initialized instead.

I don't forsee the need to poke at the hardware directly within 
->smp_init, not since everything is moving to DT now.

Sure there are ways to screw up Xen support from within this hook, but 
that can be achieved in many other places.  Will Xen take over every 
possible hooks in the kernel to prevent that from happening?

So please let's not cry wolf needlessly.

> Currently the VCPUs are all considered to be uniform i.e. there is no
> big.LITTLE exposed to guests, although the hypervisor will most likely
> eventually support it and so may be scheduling the VCPUs among the big
> and LITTLE PCPUs according to $THINGS.

Indeed.  That's what I suggested earlier.


Nicolas


From will.deacon at arm.com  Mon Apr 22 12:41:12 2013
From: will.deacon at arm.com (Will Deacon)
Date: Mon, 22 Apr 2013 17:41:12 +0100
Subject: [RFC PATCH v2 00/13] ARM: DT cpu bindings updates
In-Reply-To: <1366644455-16550-1-git-send-email-lorenzo.pieralisi@arm.com>
References: <1366644455-16550-1-git-send-email-lorenzo.pieralisi@arm.com>
Message-ID: <20130422164112.GB3076@mudshark.cambridge.arm.com>

Hi Lorenzo,

On Mon, Apr 22, 2013 at 04:27:22PM +0100, Lorenzo Pieralisi wrote:
> Code relying on the reg property size to be 4-bytes will break when
> dtb compiled for 64-bit kernels are used to boot a 32-bit system so
> kernel code relying on that (bogus) assumption must be updated properly.

So that code currently includes kvmtool, and I think it's unfair to break
it:

	- kvmtool can boot either 32-bit or 64-bit guests under a 64-bit
	  kernel and only AFF0 is exposed by the KVM host (containing the
	  vcpu id). This allows us to use a single cell for the reg
	  property, regardless of the guest payload.

	- It always sets the #address-cells property correctly, so if it
	  passes a 32-bit reg property, then #address-cells will be 0x1

	- This scheme worked fine with older kernels

Why can't we instead allow the kernel to zero extend single-cell CPU reg
properies on 64-bit systems? We can always check them against the logical
map and barf if they don't match what's sitting in the hardware, without
penalising machines which don't make use of the upper bits. Given that
people *will* run 32-bit OSs on 64-bit CPUs (a use-case which we allow), I
don't think penalising 64-bit software is the right thing to do.

Thoughts? I notice Catalin has some patches queued for arm64 which
unconditionally use of_property_read_u64, but I have a patch to honour the
#address-cells property instead.

Will


From kgene.kim at samsung.com  Mon Apr 22 12:44:04 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Tue, 23 Apr 2013 01:44:04 +0900
Subject: [PATCH v3 00/10] ARM: exynos multiplatform series, part 1
In-Reply-To: <1365716245-99231-1-git-send-email-arnd@arndb.de>
References: <1365716245-99231-1-git-send-email-arnd@arndb.de>
Message-ID: <517568D4.8020307@samsung.com>

On 04/12/13 06:37, Arnd Bergmann wrote:
> Hi Kukjin,
>
Hi Arnd,

> These are the patches that I would like to apply directly to
> the arm-soc next/multiplatform branch, unless you have any

Yeah, looks good to me.

> objections. This would get all the simple stuff out of the
> way, and I don't think there is a big risk of introducing
> regressions with these.
>
OK, please go ahead and if you want to add my ack:

Acked-by: Kukjin Kim <kgene.kim at samsung.com>

Thanks.

- Kukjin

> A lot of the other patches have already been merged into
> subsystem trees. After this series in in arm-soc, what is
> left comes down to
>
> * The ASoC conversion to dmaengine won't make it unless someone
>    who knows that code better steps up to do it right away. This
>    means that we won't have audio in a 3.10 multiplatform kernel
>    on Exynos, but it will still work for users that don't enable
>    multiplatform.
>
> * The irqchip (combiner), clk and clksource patches are all based
>    on top   of other changesets we pulled in from your trees, so I
>    would not make them part of the next/multiplatform branch. We can
>    apply them on top of the next/drivers branch once they are
>    tested successfully.
>
> * A trivial patch is needed in the end to actually make
>    CONFIG_ARCH_EXYNOS visible in multiplatform configurations.
>    We will do that as a separate patch once everything else is
>    there.
>
> Please provide an ACK so I can put this into arm-soc, or let
> me know if I screwed up somewhere.
>
> 	Arnd
>
> Arnd Bergmann (10):
>    ARM: exynos: introduce EXYNOS_ATAGS symbol
>    ARM: exynos: prepare for sparse IRQ
>    ARM: exynos: move debug-macro.S to include/debug/
>    ARM: samsung: move mfc device definition to s5p-dev-mfc.c
>    i2c: s3c2410: make header file local
>    mmc: sdhci-s3c: remove platform dependencies
>    thermal/exynos: remove unnecessary header inclusions
>    mtd: onenand/samsung: make regs-onenand.h file local
>    rtc: s3c: make header file local
>    ARM: exynos: enable multiplatform support
>
>   arch/arm/Kconfig                                   |  9 +---
>   arch/arm/Kconfig.debug                             |  8 ++++
>   arch/arm/configs/exynos4_defconfig                 |  2 +-
>   .../mach/debug-macro.S =>  include/debug/exynos.S}  | 12 ++---
>   .../plat/debug-macro.S =>  include/debug/samsung.S} |  2 +-
>   arch/arm/mach-exynos/Kconfig                       | 41 ++++++++++++++--
>   arch/arm/mach-exynos/Makefile                      |  5 +-
>   arch/arm/mach-exynos/common.c                      |  6 +++
>   arch/arm/mach-exynos/dev-uart.c                    |  1 +
>   arch/arm/mach-exynos/include/mach/irqs.h           |  5 +-
>   arch/arm/mach-exynos/mach-armlex4210.c             |  2 +
>   arch/arm/mach-exynos/mach-exynos4-dt.c             |  2 +
>   arch/arm/mach-exynos/mach-exynos5-dt.c             |  2 +
>   arch/arm/mach-exynos/mach-nuri.c                   |  2 +
>   arch/arm/mach-exynos/mach-origen.c                 |  2 +
>   arch/arm/mach-exynos/mach-smdk4x12.c               |  2 +
>   arch/arm/mach-exynos/mach-smdkv310.c               |  3 ++
>   arch/arm/mach-exynos/setup-sdhci-gpio.c            |  2 +-
>   arch/arm/mach-s3c24xx/include/mach/debug-macro.S   |  2 +-
>   arch/arm/mach-s3c24xx/mach-rx1950.c                |  1 -
>   arch/arm/mach-s3c64xx/include/mach/debug-macro.S   |  2 +-
>   arch/arm/mach-s5p64x0/include/mach/debug-macro.S   |  2 +-
>   arch/arm/mach-s5pc100/include/mach/debug-macro.S   |  2 +-
>   arch/arm/mach-s5pc100/setup-sdhci-gpio.c           |  1 -
>   arch/arm/mach-s5pv210/include/mach/debug-macro.S   |  2 +-
>   arch/arm/mach-s5pv210/setup-sdhci-gpio.c           |  1 -
>   arch/arm/plat-samsung/Kconfig                      |  7 ++-
>   arch/arm/plat-samsung/Makefile                     |  8 +++-
>   arch/arm/plat-samsung/devs.c                       | 46 ------------------
>   arch/arm/plat-samsung/include/plat/pm.h            |  5 ++
>   arch/arm/plat-samsung/include/plat/sdhci.h         | 56 +---------------------
>   arch/arm/plat-samsung/irq-vic-timer.c              |  1 +
>   arch/arm/plat-samsung/pm.c                         |  1 +
>   arch/arm/plat-samsung/s5p-dev-mfc.c                | 42 +++++++++++++++-
>   arch/arm/plat-samsung/s5p-irq.c                    |  1 +
>   drivers/gpio/Makefile                              |  2 +-
>   drivers/i2c/busses/i2c-s3c2410.c                   |  3 +-
>   .../regs-iic.h =>  drivers/i2c/busses/i2c-s3c2410.h |  0
>   drivers/mmc/host/Kconfig                           |  2 +-
>   .../mmc/host/sdhci-s3c-regs.h                      |  0
>   drivers/mmc/host/sdhci-s3c.c                       |  5 +-
>   drivers/mtd/onenand/samsung.c                      |  4 +-
>   .../mtd/onenand/samsung.h                          |  2 -
>   drivers/rtc/rtc-s3c.c                              |  3 +-
>   .../plat/regs-rtc.h =>  drivers/rtc/rtc-s3c.h       |  3 +-
>   drivers/thermal/exynos_thermal.c                   |  2 -
>   include/linux/platform_data/mmc-sdhci-s3c.h        | 56 ++++++++++++++++++++++
>   47 files changed, 217 insertions(+), 153 deletions(-)
>   rename arch/arm/{mach-exynos/include/mach/debug-macro.S =>  include/debug/exynos.S} (84%)
>   rename arch/arm/{plat-samsung/include/plat/debug-macro.S =>  include/debug/samsung.S} (98%)
>   rename arch/arm/plat-samsung/include/plat/regs-iic.h =>  drivers/i2c/busses/i2c-s3c2410.h (100%)
>   rename arch/arm/plat-samsung/include/plat/regs-sdhci.h =>  drivers/mmc/host/sdhci-s3c-regs.h (100%)
>   rename arch/arm/plat-samsung/include/plat/regs-onenand.h =>  drivers/mtd/onenand/samsung.h (98%)
>   rename arch/arm/plat-samsung/include/plat/regs-rtc.h =>  drivers/rtc/rtc-s3c.h (97%)
>   create mode 100644 include/linux/platform_data/mmc-sdhci-s3c.h


From kgene.kim at samsung.com  Mon Apr 22 12:45:37 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Tue, 23 Apr 2013 01:45:37 +0900
Subject: [PATCH v2 0/2] ARM: Exynos: Add DT based I/O mapping for Chip-ID
 controller
In-Reply-To: <1366630508-26101-1-git-send-email-thomas.abraham@linaro.org>
References: <1366630508-26101-1-git-send-email-thomas.abraham@linaro.org>
Message-ID: <51756931.9080506@samsung.com>

On 04/22/13 20:35, Thomas Abraham wrote:
> Changes since v1:
> - Rebased to v3.9-rc8
>
> This patch series allows device tree enabled platforms to setup a runtime
> I/O mapping for the chip-id controller. This helps to remove statically
> defined I/O mapping for the Chip-ID controller. This series is based on
> linux-next master branch and tested for Exynos4210, Exynos5250 and
> Exynos5440.
>
> Thomas Abraham (2):
>    ARM: Exynos: Create virtual I/O mapping for Chip-ID controller using device tree
>    ARM: dts: Add chip-id controller node on Exynos4/5 SoC
>
Looks good to me, applied.

Thanks.

- Kukjin


From kgene.kim at samsung.com  Mon Apr 22 12:47:46 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Tue, 23 Apr 2013 01:47:46 +0900
Subject: [PATCH 0/2] ARM: Exynos: Add DT based I/O mapping for Chip-ID
 controller
In-Reply-To: <CAJuYYwTV5U8-wqNhet4ZEdgRSnbok6-ziE-qkx4ee9j84z8xdg@mail.gmail.com>
References: <1361174099-18749-1-git-send-email-thomas.abraham@linaro.org>	<27ea01ce3101$a8dae850$fa90b8f0$%kim@samsung.com>
 <CAJuYYwTV5U8-wqNhet4ZEdgRSnbok6-ziE-qkx4ee9j84z8xdg@mail.gmail.com>
Message-ID: <517569B2.7040302@samsung.com>

On 04/22/13 20:20, Thomas Abraham wrote:
> On 4 April 2013 12:27, Kukjin Kim<kgene.kim at samsung.com>  wrote:
>> Thomas Abraham wrote:
>>>
>>> This patch series allows device tree enabled platforms to setup a runtime
>>> I/O mapping for the chip-id controller. This helps to remove statically
>>> defined I/O mapping for the Chip-ID controller.
>>>
>>> Thomas Abraham (2):
>>>    ARM: Exynos: Create virtual I/O mapping for Chip-ID controller using
>>> device tree
>>>    ARM: dts: Add chip-id controller node on Exynos4/5 SoC
>>>
>>>   .../arm/samsung/samsung,exynos4210-chipid.txt      |   15 ++++++
>>>   arch/arm/boot/dts/exynos4.dtsi                     |    5 ++
>>>   arch/arm/boot/dts/exynos5250.dtsi                  |    5 ++
>>>   arch/arm/mach-exynos/common.c                      |   53
>> +++++++++++---------
>>>   arch/arm/mach-exynos/include/mach/map.h            |    1 -
>>>   5 files changed, 55 insertions(+), 24 deletions(-)
>>>   create mode 100644
>>> Documentation/devicetree/bindings/arm/samsung/samsung,exynos4210-
>>> chipid.txt
>>>
>>> --
>>> 1.7.5.4
>>
>> Thomas,
>>
>> Can you update this series can support exynos5440 as well? It should be done
>> together.
>
> Hi Mr. Kim,
>
> Sorry for the delayed reply. This patch series is supported for
> Exynos5440 as well. The v2 version of this patch series has been
> submitted.
>
OK, thanks.

- Kukjin


From andrew at lunn.ch  Mon Apr 22 12:47:56 2013
From: andrew at lunn.ch (Andrew Lunn)
Date: Mon, 22 Apr 2013 18:47:56 +0200
Subject: [V3 patch 17/19] ARM: kirkwood: cpuidle: use init/exit common
 routine
In-Reply-To: <5174E036.9090808@linaro.org>
References: <1365770165-27096-1-git-send-email-daniel.lezcano@linaro.org>
 <1365770165-27096-18-git-send-email-daniel.lezcano@linaro.org>
 <20130414151429.GF5061@lunn.ch> <5174E036.9090808@linaro.org>
Message-ID: <20130422164756.GG29947@lunn.ch>

On Mon, Apr 22, 2013 at 09:01:10AM +0200, Daniel Lezcano wrote:
> On 04/14/2013 05:14 PM, Andrew Lunn wrote:
> 
> [ ... ]
> >  int kirkwood_cpuidle_remove(struct platform_device *pdev)
> >  {
> > -	cpuidle_unregister_device(device);
> > -	cpuidle_unregister_driver(&kirkwood_idle_driver);
> > -
> > +	cpuidle_unregister(&kirkwood_idle_driver);
> >  	return 0;
> >  }
> >  
> > -- 
> > 1.7.9.5
> >
> > Tested-by: Andrew Lunn <andrew at lunn.ch>
> 
> Hi Andrew,
> 
> shall I consider it as acked-by also ?

Yes, please do.

     Andrew


From jason at lakedaemon.net  Mon Apr 22 12:53:43 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Mon, 22 Apr 2013 12:53:43 -0400
Subject: [PATCH v8 0/3] of/pci: Provide common support for PCI DT parsing
In-Reply-To: <1366627295-16964-1-git-send-email-Andrew.Murray@arm.com>
References: <1366627295-16964-1-git-send-email-Andrew.Murray@arm.com>
Message-ID: <20130422165343.GE25724@titan.lakedaemon.net>

On Mon, Apr 22, 2013 at 11:41:32AM +0100, Andrew Murray wrote:
> This patchset factors out duplicated code associated with parsing PCI
> DT "ranges" properties across the architectures and introduces a
> "ranges" parser. This parser "of_pci_range_parser" can be used directly
> by ARM host bridge drivers enabling them to obtain ranges from device
> trees.
> 
> I've included the Reviewed-by, Tested-by and Acked-by's received from v5/v6/v7
> in this patchset, earlier versions of this patchset (v3) have been tested-by:
> 
> Thierry Reding <thierry.reding at avionic-design.de>
> Jingoo Han <jg1.han at samsung.com>
> 
> I've tested that this patchset builds and runs on ARM and that it builds on
> PowerPC, x86_64 and MIPS.

Andrew,

Unfortunately, the mvebu/drivers branch containing your series had to be
dropped from arm-soc for v3.10.  This was not due to your series, but
since arm-soc's granularity is branches, your series was caught in the
drop.

As the mvebu-pcie driver is now v3.11 material, I have taken the
opportunity to upgrade from your v7 patchset to v8.  You can find the
whole branch at mvebu-next/pcie.

mvebu-next/pcie *will* be rebased onto v3.9 once it drops.  Several
dependencies will be removed (since they will have been merged into
v3.9).

Once the rebase is done, I'll send a pull request to Arnd and Olof so we
can get as many cycles on -next as possible.

thx,

Jason.

> 
> Compared to the v7 sent by Andrew Murray, the following changes have been made
> (please note that the first patch is unchanged from v7):
> 
>  * Rename of_pci_range_parser to of_pci_range_parser_init and
>    of_pci_process_ranges to of_pci_range_parser_one as suggested by Grant
>    Likely.
> 
>  * Reverted back to using a switch statement instead of if/else in
>    pci_process_bridge_OF_ranges. Grant Likely highlighted this change from
>    the original code which was unnecessary.
> 
>  * Squashed in a patch provided by Gabor Juhos which fixes build errors on
>    MIPS found in the last patchset.
> 
> Compared to the v6 sent by Andrew Murray, the following changes have
> been made in response to build errors/warnings:
> 
>  * Inclusion of linux/of_address.h in of_pci.c as suggested by Michal
>    Simek to prevent compilation failures on Microblaze (and others) and his
>    ack.
> 
>  * Use of externs, static inlines and a typo in linux/of_address.h in response
>    to linker errors (multiple defination) on x86_64 as spotted by a kbuild test
>    robot on (jcooper/linux.git mvebu/drivers)
> 
>  * Add EXPORT_SYMBOL_GPL to of_pci_range_parser function to be consistent
>    with of_pci_process_ranges function
> 
> Compared to the v5 sent by Andrew Murray, the following changes have
> been made:
> 
>  * Use of CONFIG_64BIT instead of CONFIG_[a32bitarch] as suggested by
>    Rob Herring in drivers/of/of_pci.c
> 
>  * Added forward declaration of struct pci_controller in linux/of_pci.h
>    to prevent compiler warning as suggested by Thomas Petazzoni
> 
>  * Improved error checking (!range check), removal of unnecessary be32_to_cpup
>    call, improved formatting of struct of_pci_range_parser layout and
>    replacement of macro with a static inline. All suggested by Rob Herring.
> 
> Compared to the v4 (incorrectly labelled v3) sent by Andrew Murray,
> the following changes have been made:
> 
>  * Split the patch as suggested by Rob Herring
> 
> Compared to the v3 sent by Andrew Murray, the following changes have
> been made:
> 
>  * Unify and move duplicate pci_process_bridge_OF_ranges functions to
>    drivers/of/of_pci.c as suggested by Rob Herring
> 
>  * Fix potential build errors with Microblaze/MIPS
> 
> Compared to "[PATCH v5 01/17] of/pci: Provide support for parsing PCI DT
> ranges property", the following changes have been made:
> 
>  * Correct use of IORESOURCE_* as suggested by Russell King
> 
>  * Improved interface and naming as suggested by Thierry Reding
> 
> Compared to the v2 sent by Andrew Murray, Thomas Petazzoni did:
> 
>  * Add a memset() on the struct of_pci_range_iter when starting the
>    for loop in for_each_pci_range(). Otherwise, with an uninitialized
>    of_pci_range_iter, of_pci_process_ranges() may crash.
> 
>  * Add parenthesis around 'res', 'np' and 'iter' in the
>    for_each_of_pci_range macro definitions. Otherwise, passing
>    something like &foobar as 'res' didn't work.
> 
>  * Rebased on top of 3.9-rc2, which required fixing a few conflicts in
>    the Microblaze code.
> 
> v2:
>   This follows on from suggestions made by Grant Likely
>   (marc.info/?l=linux-kernel&m=136079602806328)
> 
> Andrew Murray (3):
>   of/pci: Unify pci_process_bridge_OF_ranges from Microblaze and
>     PowerPC
>   of/pci: Provide support for parsing PCI DT ranges property
>   of/pci: mips: convert to common of_pci_range_parser
> 
>  arch/microblaze/include/asm/pci-bridge.h |    5 +-
>  arch/microblaze/pci/pci-common.c         |  192 ------------------------------
>  arch/mips/pci/pci.c                      |   51 +++-----
>  arch/powerpc/include/asm/pci-bridge.h    |    5 +-
>  arch/powerpc/kernel/pci-common.c         |  192 ------------------------------
>  drivers/of/address.c                     |   67 +++++++++++
>  drivers/of/of_pci.c                      |  173 +++++++++++++++++++++++++++
>  include/linux/of_address.h               |   48 ++++++++
>  include/linux/of_pci.h                   |    4 +
>  9 files changed, 313 insertions(+), 424 deletions(-)
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From daniel.lezcano at linaro.org  Mon Apr 22 12:54:04 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Mon, 22 Apr 2013 18:54:04 +0200
Subject: [V3 patch 17/19] ARM: kirkwood: cpuidle: use init/exit common
 routine
In-Reply-To: <20130422164756.GG29947@lunn.ch>
References: <1365770165-27096-1-git-send-email-daniel.lezcano@linaro.org>
 <1365770165-27096-18-git-send-email-daniel.lezcano@linaro.org>
 <20130414151429.GF5061@lunn.ch> <5174E036.9090808@linaro.org>
 <20130422164756.GG29947@lunn.ch>
Message-ID: <51756B2C.3080405@linaro.org>

On 04/22/2013 06:47 PM, Andrew Lunn wrote:
> On Mon, Apr 22, 2013 at 09:01:10AM +0200, Daniel Lezcano wrote:
>> On 04/14/2013 05:14 PM, Andrew Lunn wrote:
>>
>> [ ... ]
>>>  int kirkwood_cpuidle_remove(struct platform_device *pdev)
>>>  {
>>> -	cpuidle_unregister_device(device);
>>> -	cpuidle_unregister_driver(&kirkwood_idle_driver);
>>> -
>>> +	cpuidle_unregister(&kirkwood_idle_driver);
>>>  	return 0;
>>>  }
>>>  
>>> -- 
>>> 1.7.9.5
>>>
>>> Tested-by: Andrew Lunn <andrew at lunn.ch>
>>
>> Hi Andrew,
>>
>> shall I consider it as acked-by also ?
> 
> Yes, please do.

Thanks !

-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From rdunlap at infradead.org  Mon Apr 22 12:58:12 2013
From: rdunlap at infradead.org (Randy Dunlap)
Date: Mon, 22 Apr 2013 09:58:12 -0700
Subject: [PATCH] mm: add an option to disable bounce
In-Reply-To: <1366644180-6140-1-git-send-email-vinayakm.list@gmail.com>
References: <1366644180-6140-1-git-send-email-vinayakm.list@gmail.com>
Message-ID: <51756C24.8060505@infradead.org>

On 04/22/13 08:23, vinayakm.list at gmail.com wrote:
> From: Vinayak Menon <vinayakm.list at gmail.com>
> 
> There are times when HIGHMEM is enabled, but
> we don't prefer CONFIG_BOUNCE to be enabled.
> CONFIG_BOUNCE can reduce the block device
> throughput, and this is not ideal for machines
> where we don't gain much by enabling it. So
> provide an option to deselect CONFIG_BOUNCE. The
> observation was made while measuring eMMC throughput
> using iozone on an ARM device with 1GB RAM.
> 
> Signed-off-by: Vinayak Menon <vinayakm.list at gmail.com>
> ---
>  mm/Kconfig |    6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/mm/Kconfig b/mm/Kconfig
> index 3bea74f..29f9736 100644
> --- a/mm/Kconfig
> +++ b/mm/Kconfig
> @@ -263,8 +263,14 @@ config ZONE_DMA_FLAG
>  	default "1"
>  
>  config BOUNCE
> +	bool "Enable bounce buffers"
>  	def_bool y
>  	depends on BLOCK && MMU && (ZONE_DMA || HIGHMEM)
> +	help
> +	  Enable bounce buffers for devices that cannot access
> +	  the full range of memory available to the CPU. Enabled
> +	  by default when ZONE_DMA or HIGMEM is selected, but you

	                              HIGHMEM

> +	  may say n to override this.
>  
>  # On the 'tile' arch, USB OHCI needs the bounce pool since tilegx will often
>  # have more than 4GB of memory, but we don't currently use the IOTLB to present
> 


-- 
~Randy


From kgene.kim at samsung.com  Mon Apr 22 12:59:25 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Tue, 23 Apr 2013 01:59:25 +0900
Subject: [PATCH 0/3] ARM: S3C24XX: dma cleanups for s3c2412 and s3c2443
In-Reply-To: <201304212002.31082.heiko@sntech.de>
References: <201304212002.31082.heiko@sntech.de>
Message-ID: <51756C6D.9020500@samsung.com>

On 04/22/13 03:02, Heiko St?bner wrote:
> The s3c2412 uses the same dma channel selection-type as the s3c2443 and later
> but introduced the notion of a receive channel to keep the spi channels,
> together that are separate in hardware.
>
> This series split the spi channels like later socs do (the s3c24xx-spi driver
> does not use dma at all) and removes this type of special handling.
>
> Heiko Stuebner (3):
>    ARM: S3C24XX: split s3c2412 spi dma channels
>    ARM: S3C24XX: dma-s3c2443 - do not write into arbitary bits
>    ARM: S3C24XX: remove obsolete s3c2412 specific dma settings
>
>   arch/arm/mach-s3c24xx/dma-s3c2412.c              |   56 ++++++----------------
>   arch/arm/mach-s3c24xx/dma-s3c2443.c              |    3 +-
>   arch/arm/mach-s3c24xx/dma.c                      |    3 -
>   arch/arm/plat-samsung/include/plat/dma-s3c24xx.h |    5 --
>   4 files changed, 17 insertions(+), 50 deletions(-)
>
Applied, thanks.

- Kukjin


From pawel.moll at arm.com  Mon Apr 22 12:59:26 2013
From: pawel.moll at arm.com (Pawel Moll)
Date: Mon, 22 Apr 2013 17:59:26 +0100
Subject: [PATCH v1] ARM: do not select ARCH_VEXPRESS by default on
 ARCH_MULTI_V7
In-Reply-To: <1366634604-12637-1-git-send-email-srinivas.kandagatla@st.com>
References: <1366634604-12637-1-git-send-email-srinivas.kandagatla@st.com>
Message-ID: <1366649966.3203.40.camel@hornet>

Hi Srinivas,

On Mon, 2013-04-22 at 13:43 +0100, Srinivas KANDAGATLA wrote:
> From: Srinivas Kandagatla <srinivas.kandagatla at st.com>
> 
> This patch removes ARCH_VEXPRESS selection as default when ARCH_MULTI_V7
> is selected. ARCH_VEXPRESS should be selected from
> mach-vexpress/Kconfig.
> 
> Without this patch, any multiplatform build will have ARCH_VEXPRESS
> selected, as a result all the vexpress associated dtbs are build when we
> make dtbs.
> 
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla at st.com>

Fabio was looking at this some time ago:
http://thread.gmane.org/gmane.linux.ports.arm.kernel/201499
He may comment on the relevant issues.

Cheers!

Pawe?





From john.stultz at linaro.org  Mon Apr 22 13:00:38 2013
From: john.stultz at linaro.org (John Stultz)
Date: Mon, 22 Apr 2013 10:00:38 -0700
Subject: [PATCH 0/4] ARM 64 bit sched_clock take #2
In-Reply-To: <1366417746-24990-1-git-send-email-sboyd@codeaurora.org>
References: <51709FD7.8050408@gmail.com>
 <1366417746-24990-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <51756CB6.5060607@linaro.org>

On 04/19/2013 05:29 PM, Stephen Boyd wrote:
> This is what I was thinking. I don't see why we can't move this to generic code and have arm64 use it too. Those patches will follow once I find an arm64
> compiler.

I think moving this to generic code sounds like a good idea. You could 
probably also prototype and test the 64bit code with x86_64, using the 
TSC counter.

thanks
-john



From mugunthanvnm at ti.com  Mon Apr 22 13:01:38 2013
From: mugunthanvnm at ti.com (Mugunthan V N)
Date: Mon, 22 Apr 2013 22:31:38 +0530
Subject: [PATCH 0/3] Dual EMAC mode implementation of CPSW
In-Reply-To: <51754427.7000908@newflow.co.uk>
References: <1360612340-9266-1-git-send-email-mugunthanvnm@ti.com>
 <516B0098.4040809@mimc.co.uk> <516C33D2.4050105@ti.com>
 <516C38B9.50904@mimc.co.uk> <516C3A0D.70903@ti.com>
 <517018E6.6080108@newflow.co.uk> <51754427.7000908@newflow.co.uk>
Message-ID: <51756CF2.4050602@ti.com>

On 4/22/2013 7:37 PM, Mark Jackson wrote:
> Mugunthan
>
> Can you confirm that I'm actually trying to achieve the right thing ?
>
> I have all along assumed that Dual EMAC mode would simply provide the
> kernel will a pair of independent Ethernet ports.
Yes, it will provide two network interfaces for ex eth0 and eth1
> All I am trying to do is to get both Ethernet ports working so I can
> have one port on (say) 10.0.x.x and the other on (say) 10.1.x.x
This is perfectly correct
> But there is all this reference to VLANs(in the source code and the TRM)
> ... I have not setup any VLANs.  Do I need to ?  If so, how ?
No need to setup any VLAN. VLAN are used to segregate the
two down stream ports and it will be taken care by the driver

Regards
Mugunthan V N


From kgene.kim at samsung.com  Mon Apr 22 13:02:26 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Tue, 23 Apr 2013 02:02:26 +0900
Subject: [PATCH] clocksource: add samsung pwm timer driver
In-Reply-To: <201304210002.00125.arnd@arndb.de>
References: <201304210002.00125.arnd@arndb.de>
Message-ID: <51756D22.20103@samsung.com>

On 04/21/13 07:01, Arnd Bergmann wrote:
> From: Tomasz Figa<t.figa at samsung.com>
>
> This adds a new clocksource driver for the PWM timer that is
> present in most Samsung SoCs, based on the existing driver in
> arch/arm/plat-samsung/samsung-time.c and many changes implemented by
> Tomasz Figa.
>
> Originally, the conversion of all Samsung machines to the new driver was
> planned for 3.10, but that work ended up being too late and too invasive
> just before the merge window.
>
> Unfortunately, other changes in the Exynos platform resulted in some
> Exynos4 setups, particularly the Universal C210 board to be broken. In
> order to fix that with minimum risk, so we now leave the existing pwm
> clocksource driver in place for all older platforms and use the new
> driver only for device tree enabled boards. This way, we can get the
> broken machines running again using DT descriptions.
>
> All clocksource changes were implemented by Tomasz, while the DT
> registration was rewritten by Arnd.
>
> Signed-off-by: Arnd Bergmann<arnd at arndb.de>
> Cc: Tomasz Figa<t.figa at samsung.com>
> Cc: Kyungmin Park<kyungmin.park at samsung.com>
> Cc: Kukjin Kim<kgene.kim at samsung.com>

Acked-by: Kukjin Kim <kgene.kim at samsung.com>

Thanks.

- Kukjin

> Cc: Ben Dooks<ben-linux at fluff.org>
> Cc: John Stultz<john.stultz at linaro.org>
> Cc: Thomas Gleixner<tglx at linutronix.de>
> ---
> This is my final attempt to fix the Exynos4 regressions we have, since
> Tomasz put a lot of work into getting this running, and I gave him a
> hard time about some of the earlier patches.
>
> Tomasz, can you have a look at this to see if it would actually help?
> I have removed all the non-DT registration from your code, as well
> as the interface to the pwm subsystem, since I assume the existing
> code will work for all users we care about.


From kevin at bracey.fi  Mon Apr 22 13:03:48 2013
From: kevin at bracey.fi (Kevin Bracey)
Date: Mon, 22 Apr 2013 20:03:48 +0300
Subject: [PATCH] ARM: smp: call platform's cpu_die in ipi_cpu_stop
In-Reply-To: <20130418195735.GF14496@n2100.arm.linux.org.uk>
References: <1365251824-4852-1-git-send-email-kevin@bracey.fi>
 <1365251824-4852-2-git-send-email-kevin@bracey.fi>
 <20130418171801.GC14496@n2100.arm.linux.org.uk>
 <20130418182534.GD14496@n2100.arm.linux.org.uk> <51704D31.10808@bracey.fi>
 <20130418195735.GF14496@n2100.arm.linux.org.uk>
Message-ID: <51756D74.1070604@bracey.fi>

On 18/04/2013 22:57, Russell King - ARM Linux wrote:
> Well, the idea as far as hotplug CPU is concerned is that we guarantee
> in core code that platform_cpu_kill() will not be called until it is
> safe for the dying CPU to be powered off - so the synchronisation is
> done by the core code.  That's always been what the completion stuff
> is about in arch/arm/kernel/smp.c.
>
> It was missing the cache bits because (a) the ARM development platforms
> don't actually take the CPUs offline, and (b) we never really had an
> API at the time hotplug CPU was designed to flush just the local CPUs
> L1 cache.
>
> Now, practically, most platforms which cut power/clocks to the CPU do
> it in one of two ways.  Either they do it in their cpu_die() callback,
> via WFI, or they do it from a running CPU via the cpu_kill() callback.
>
> Either way, platforms are not expected to have any further
> synchronisation.  Once that complete() call has returned, the dying
> CPU is expected to become dead very shortly after that point - whether
> that be as a result of cpu_kill() or cpu_die().
>
> The whole point is to stop platforms having to implement synchronisation
> in these callbacks, with all the bugs that will cause.  The patch I
> posted took about an hour of thought and walking through, and discussion
> with Will to make sure that all issues had been covered.  Taking a CPU
> offline safely is far from trivial, and the less code that a platform
> has to do the better.
>
>
Okay, so in the final analysis, would this be a reasonable summary?

* Generally a hotplug platform will implement either cpu_kill, or 
cpu_die, but not normally both;

* it should be up to the core code to ensure that a CPU is safe to be 
killed before cpu_kill is entered, w.r.t. non-platform-specifics like 
the cache;

* if both calls are implemented, cpu_kill can't assume that cpu_die will 
be called, so shouldn't depend on co-ordinating with it;

* because cpu_kill is used in panic-type contexts, it shouldn't be 
attempting anything complex anyway;

* the current framework wouldn't straightforwardly support a 
platform-specific requirement for hotplug-out like "hardware register X 
must be poked after the dying core has entered STANDBYWFI", due to the 
above restrictions.

I can't say for certain at this stage whether I do have a requirement 
like the last, but I fear I might do. So at present, I'd be fine with 
your patch dealing with the cache, but I'm just worried that it won't be 
enough.

It just all still feels a little bit off; the system is overly 
constrained by the ipi_cpu_stop case. It feels to me that life would be 
simpler if there was a distinction between "hotplug cpu kill" and 
"emergency cpu kill", which would then permit more ambitious platform 
hotplug code. Is there some way I've missed that would allow me to 
distinguish the two cases in the current framework?

Kevin



From kgene.kim at samsung.com  Mon Apr 22 13:08:40 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Tue, 23 Apr 2013 02:08:40 +0900
Subject: [PATCH RESEND] ARM: EXYNOS: no more support non-DT for EXYNOS SoCs
In-Reply-To: <516571BC.9030909@samsung.com>
References: <51642dab.e844440a.0ad1.ffffc13f@mx.google.com>
 <201304101459.07263.arnd@arndb.de> <51656D2D.7060004@samsung.com>
 <201304101555.27984.arnd@arndb.de> <516571BC.9030909@samsung.com>
Message-ID: <51756E98.9040606@samsung.com>

On 04/10/13 23:05, Kukjin Kim wrote:
> On 04/10/13 22:55, Arnd Bergmann wrote:
>> On Wednesday 10 April 2013, Sylwester Nawrocki wrote:
>>> Hmm, it turns out we are still actively using some boards based on
>>> Exynos4210 EVT0 SoCs. And since it seems unlikely the patches from
>>> Tomasz [1] adding basic DT support for those will get merged for
>>> 3.10, it would be a bit inconvenient to remove the ATAGS support
>>> now, leaving Exynos4210 Rev. 0 not supported at all.
>>
>> I still have hope to get those included.
>>
> I agree and I asked Tomasz to re-send universal dt patch.
>
Hi Arnd and Olof,

Is it possible to send one more pull-request for this and something like 
dt patches for exynos?

- Kukjin


From festevam at gmail.com  Mon Apr 22 13:10:49 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Mon, 22 Apr 2013 14:10:49 -0300
Subject: [PATCH v1] ARM: do not select ARCH_VEXPRESS by default on
 ARCH_MULTI_V7
In-Reply-To: <1366649966.3203.40.camel@hornet>
References: <1366634604-12637-1-git-send-email-srinivas.kandagatla@st.com>
 <1366649966.3203.40.camel@hornet>
Message-ID: <CAOMZO5BMesWazKtfgQ9BFDiW0oiWCQop2LUs0j6P4fDSGMhvfg@mail.gmail.com>

On Mon, Apr 22, 2013 at 1:59 PM, Pawel Moll <pawel.moll at arm.com> wrote:

> Fabio was looking at this some time ago:
> http://thread.gmane.org/gmane.linux.ports.arm.kernel/201499
> He may comment on the relevant issues.

Arnd has recently posted a patch to address this issue:
https://patchwork.kernel.org/patch/2436131/

Regards,

Fabio Estevam


From mturquette at linaro.org  Mon Apr 22 13:27:58 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Mon, 22 Apr 2013 10:27:58 -0700
Subject: [PATCH] clk: vexpress: Add separate SP810 driver
In-Reply-To: <1366641279.3203.15.camel@hornet>
References: <1363358409-5693-1-git-send-email-pawel.moll@arm.com>
 <20130417222630.19887.75481@quantum> <1366305802.3077.37.camel@hornet>
 <20130422142555.GN14496@n2100.arm.linux.org.uk>
 <1366641279.3203.15.camel@hornet>
Message-ID: <20130422172758.17530.12432@quantum>

Quoting Pawel Moll (2013-04-22 07:34:39)
> On Mon, 2013-04-22 at 15:25 +0100, Russell King - ARM Linux wrote:
> > >         /* Switch the parent if necessary */
> > > -       if (old_parent != new_parent)
> > > +       if (old_parent != new_parent) {
> > > +               clk_prepare(new_parent);
> > >                 clk_set_parent(hw->clk, new_parent);
> > > +               clk_unprepare(old_parent);
> > > +       }
> > > 
> > > So, to summarize, the patch that works for me is below.
> > 
> > So what if the old parent clock wasn't prepared?
> 
> The clk_prepare() does __clk_prepare(clk->parent) before
> clk->ops->prepare(clk->kw), so the old_parent is always prepared.
> 

Yes, this hack is subtle.  The reparent operation happens within the
.prepare callback, so the old parent chain is implicitly prepared.

Regards,
Mike

> Pawe?


From catalin.marinas at arm.com  Mon Apr 22 13:31:16 2013
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Mon, 22 Apr 2013 18:31:16 +0100
Subject: [PATCH 2/4] arm64: Initial defconfig for APM X-Gene SOC family
In-Reply-To: <2165570.9Zy5vrhoIa@wuerfel>
References: <1366442131-26094-1-git-send-email-vkale@apm.com>
 <1366442131-26094-3-git-send-email-vkale@apm.com>
 <2165570.9Zy5vrhoIa@wuerfel>
Message-ID: <20130422173116.GD9602@arm.com>

On Sat, Apr 20, 2013 at 08:35:14AM +0100, Arnd Bergmann wrote:
> On Saturday 20 April 2013 12:45:29 Vinayak Kale wrote:
> > This patch adds initial defconfig for APM X-Gene SOC family.
> > 
> > Signed-off-by: Kumar Sankaran <ksankaran at apm.com>
> > Signed-off-by: Loc Ho <lho at apm.com>
> > Signed-off-by: Feng Kan <fkan at apm.com>
> > ---
> >  arch/arm64/configs/xgene_defconfig |   93 ++++++++++++++++++++++++++++++++++++
> >  1 files changed, 93 insertions(+), 0 deletions(-)
> >  create mode 100644 arch/arm64/configs/xgene_defconfig
> 
> Could you modify the regular defconfig to enable everything you need instead
> of adding another one? Since all the code is interoperable, I think we
> should not need a defconfig per soc.

That's good as we can get any automatic builds using defconfig to test
all the platforms. The only issue I see is that as the number of SoCs
grows, if you only need to select a single SoC you could end up with
features enabled for other platforms.

A way around this would be for such features to be enabled by an ARCH_*
entry in arch/arm64/Kconfig (or depending on them) so that we don't get
the values set in the (minimal) defconfig.

Another option would be to avoid any ARCH_* arch/arm64/Kconfig entries
entirely and use per-SoC defconfigs, together with an overall defconfig
including all SoCs.

I would go for the first choice with Kconfig ARCH_* entries, that's the
closest to arch/arm/ as well, though there are virtual platforms like
kvmtool which do not require a specific ARCH_ option. For vexpress I had
to add ARCH_VEXPRESS since it relies code under drivers/ which is
conditionally compiled based on this option.

-- 
Catalin


From mpatocka at redhat.com  Mon Apr 22 13:32:53 2013
From: mpatocka at redhat.com (Mikulas Patocka)
Date: Mon, 22 Apr 2013 13:32:53 -0400 (EDT)
Subject: linux-next ARM multi-platform randconfig errors
In-Reply-To: <5170B4C6.1030300@gmail.com>
References: <5170B4C6.1030300@gmail.com>
Message-ID: <Pine.LNX.4.64.1304221318350.22065@file.rdu.redhat.com>



On Thu, 18 Apr 2013, Rob Herring wrote:

> Current errors in linux-next for ARM multi-platform randconfig builds.
> 
> Rob
> 
> drivers/built-in.o:drivers/md/dm-cache-target.c:429: more undefined references to `__udivdi3' follow
> /var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/md/dm-cache-target.c:429: undefined reference to `__udivdi3'
> /var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/md/dm-cache-target.c:429: undefined reference to `__umoddi3'
> driversdrivers/md/dm-cache-target.c:429: more undefined references to `__udivdi3' follow
> drivers/md/dm-cache-target.c:429: undefined reference to `__udivdi3'
> drivers/md/dm-cache-target.c:429: undefined reference to `__umoddi3'

Hi

I tried to cross-compile dm-cache on linux-next for arm and there were no 
failures and no references to __udivdi3 and __umoddi3.

Please send the .config file that resulted in these faulures.

Mikulas


From kgene.kim at samsung.com  Mon Apr 22 13:37:33 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Tue, 23 Apr 2013 02:37:33 +0900
Subject: [PATCH v5 00/14] ARM: samsung-time: Prepare for multiplatform
 support
In-Reply-To: <201304122251.41393.arnd@arndb.de>
References: <1365794250-14436-1-git-send-email-t.figa@samsung.com>
 <201304122251.41393.arnd@arndb.de>
Message-ID: <5175755D.20305@samsung.com>

On 04/13/13 05:51, Arnd Bergmann wrote:
> On Friday 12 April 2013, Tomasz Figa wrote:
>> This series is an attempt to make the samsung-time clocksource driver ready
>> for multiplatform kernels. It moves the driver to drivers/clocksource, cleans
>> it up from uses of static platform-specific definitions, simplifies timer
>> interrupt handling and adds Device Tree support.
>>
>> The samsung_pwm clocksource driver is made the master driver, which
>> exposes a single function to the PWM driver to get required data. Only
>> samsung-time driver is reworked to use the master driver at this time,
>> since the PWM driver can be already considered broken at the moment and
>> needs separate series of several patches to fix and clean it up, which
>> I am already working on.
>>
>> Tested on Universal C210 board with Device Tree. Not tested without
>> Device Tree, since it has been already broken before this series.
>> Compile tested for other related SoCs.
>
> Acked-by: Arnd Bergmann<arnd at arndb.de>

Applied, this whole series.

Thanks.

- Kukjin


From vinayakm.list at gmail.com  Mon Apr 22 13:37:48 2013
From: vinayakm.list at gmail.com (vinayak)
Date: Mon, 22 Apr 2013 23:07:48 +0530
Subject: [PATCH] mm: add an option to disable bounce
In-Reply-To: <51756C24.8060505@infradead.org>
References: <1366644180-6140-1-git-send-email-vinayakm.list@gmail.com>
 <51756C24.8060505@infradead.org>
Message-ID: <5175756C.5080009@gmail.com>

On Monday 22 April 2013 10:28 PM, Randy Dunlap wrote:

> On 04/22/13 08:23, vinayakm.list at gmail.com wrote:
>> From: Vinayak Menon <vinayakm.list at gmail.com>
>>
>> There are times when HIGHMEM is enabled, but
>> we don't prefer CONFIG_BOUNCE to be enabled.
>> CONFIG_BOUNCE can reduce the block device
>> throughput, and this is not ideal for machines
>> where we don't gain much by enabling it. So
>> provide an option to deselect CONFIG_BOUNCE. The
>> observation was made while measuring eMMC throughput
>> using iozone on an ARM device with 1GB RAM.
>>
>> Signed-off-by: Vinayak Menon <vinayakm.list at gmail.com>
>> ---
>>  mm/Kconfig |    6 ++++++
>>  1 file changed, 6 insertions(+)
>>
>> diff --git a/mm/Kconfig b/mm/Kconfig
>> index 3bea74f..29f9736 100644
>> --- a/mm/Kconfig
>> +++ b/mm/Kconfig
>> @@ -263,8 +263,14 @@ config ZONE_DMA_FLAG
>>  	default "1"
>>  
>>  config BOUNCE
>> +	bool "Enable bounce buffers"
>>  	def_bool y
>>  	depends on BLOCK && MMU && (ZONE_DMA || HIGHMEM)
>> +	help
>> +	  Enable bounce buffers for devices that cannot access
>> +	  the full range of memory available to the CPU. Enabled
>> +	  by default when ZONE_DMA or HIGMEM is selected, but you
> 
> 	                              HIGHMEM


Thanks. I will correct this.

> 
>> +	  may say n to override this.
>>  
>>  # On the 'tile' arch, USB OHCI needs the bounce pool since tilegx will often
>>  # have more than 4GB of memory, but we don't currently use the IOTLB to present
>>
> 
> 




From kgene.kim at samsung.com  Mon Apr 22 13:40:45 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Tue, 23 Apr 2013 02:40:45 +0900
Subject: [PATCH v2 0/3] ARM: EXYNOS: DT-enabled support for Universal C210
In-Reply-To: <1366036922-4103-1-git-send-email-t.figa@samsung.com>
References: <1366036922-4103-1-git-send-email-t.figa@samsung.com>
Message-ID: <5175761D.9030906@samsung.com>

On 04/15/13 23:41, Tomasz Figa wrote:
> This series intends to add support for Universal C210 board using Device
> Tree. Main difference from other boards based on Exynos 4210 is that
> hardware revision of the SoC used on Universal C210 does not support MCT
> timers and legacy PWM timers must be used instead.
>
> First patch adds device tree node for PWM block available on Exynos4 SoCs,
> second patch adds support for Exynos4210 rev0 SoC in exynos_init_time()
> and third patch introduces initial device tree for Universal C210 board.
>
> Depends on my series for PWM timers rework:
> [PATCH v5 00/14] ARM: samsung-time: Prepare for multiplatform support
> (http://thread.gmane.org/gmane.linux.kernel.samsung-soc/17864)
>
> On Universal C210 board:
>
> Tested-by: Tomasz Figa<t.figa at samsung.com>
>
> Tomasz Figa (3):
>    ARM: dts: exynos4: Add node for PWM device
>    ARM: EXYNOS: Fix support of Exynos4210 rev0 SoC
>    ARM: dts: exynos4210: Add basic dts file for universal_c210 board
>
>   arch/arm/boot/dts/Makefile                      |   1 +
>   arch/arm/boot/dts/exynos4.dtsi                  |   8 +
>   arch/arm/boot/dts/exynos4210-universal_c210.dts | 352 ++++++++++++++++++++++++
>   arch/arm/mach-exynos/common.c                   |   6 +-
>   arch/arm/mach-exynos/mach-universal_c210.c      |   2 +-
>   5 files changed, 367 insertions(+), 2 deletions(-)
>   create mode 100644 arch/arm/boot/dts/exynos4210-universal_c210.dts
>

Applied, thanks.

- Kukjin


From lauraa at codeaurora.org  Mon Apr 22 13:47:00 2013
From: lauraa at codeaurora.org (Laura Abbott)
Date: Mon, 22 Apr 2013 10:47:00 -0700
Subject: [RFC][PATCH] arm: highmem: Add support for flushing kmap_atomic
 mappings
In-Reply-To: <20130419164030.GY14496@n2100.arm.linux.org.uk>
References: <1365198171-8469-1-git-send-email-lauraa@codeaurora.org>
 <20130419164030.GY14496@n2100.arm.linux.org.uk>
Message-ID: <51757794.9040206@codeaurora.org>

On 4/19/2013 9:40 AM, Russell King - ARM Linux wrote:
> On Fri, Apr 05, 2013 at 02:42:51PM -0700, Laura Abbott wrote:
>> The highmem code provides kmap_flush_unused to ensure all kmap
>> mappings are really removed if they are used. This code does not
>> handle kmap_atomic mappings since they are managed separately.
>> This prevents an issue for any code which relies on having absolutely
>> no mappings for a particular page. Rather than pay the penalty of
>> having CONFIG_DEBUG_HIGHMEM on all the time, add functionality
>> to remove the kmap_atomic mappings in a similar way to kmap_flush_unused.
>
> I get the feeling that there's something behind this which is pushing
> for there only being no mappings for a particular page.  In a SMP
> environment that sounds like a dodgy assumption.  Maybe you could
> provide the background behind this patch?
>

Yes, I was asked this before and neglected to update the commit text.

We have a use case where we pass memory to trustzone to have it 
protected such that the non-secure environment may not read or write 
that memory. The protecting/unprotecting can happen at runtime. If there 
are any valid mappings in the page tables, the CPU is free to 
speculatively access that memory. If the CPU speculates into a protected 
region while in the non-secure world, we get a fault violation. 
Essentially this means that even if we reserve the memory at bootup time 
with memblock_reserve, if the memory was ever previously mapped with 
kmap_atomic (to flush caches for example) we could still end up with 
stray mappings which can lead to faults.

In general, it seems like this is missing functionality from the 
intended behavior of kmap_flush_unused which is to get rid of all stray 
mappings.



>> This is intended to be an RFC to make sure this approach is
>> reasonable. The goal is to have kmap_atomic_flush_unused be a public
>> API.
>
> That implies that there's some callers which need it, which aren't
> part of this patch - and a motivation for this outside of what we
> can see here.  That needs to be explained.  Plus, unused APIs in
> the mainline kernel don't tend ot stick around for long, so it really
> needs a use case to be demonstrated before it can be merged.
>
>>
>> Signed-off-by: Laura Abbott <lauraa at codeaurora.org>
>> ---
>>   arch/arm/mm/highmem.c |   51 +++++++++++++++++++++++++++++++++++++++++++++++++
>>   1 files changed, 51 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/mm/highmem.c b/arch/arm/mm/highmem.c
>> index 21b9e1b..f4c0466 100644
>> --- a/arch/arm/mm/highmem.c
>> +++ b/arch/arm/mm/highmem.c
>> @@ -10,6 +10,7 @@
>>    * published by the Free Software Foundation.
>>    */
>>
>> +#include <linux/cpu.h>
>>   #include <linux/module.h>
>>   #include <linux/highmem.h>
>>   #include <linux/interrupt.h>
>> @@ -135,3 +136,53 @@ struct page *kmap_atomic_to_page(const void *ptr)
>>
>>   	return pte_page(get_top_pte(vaddr));
>>   }
>> +
>> +static void kmap_remove_unused_cpu(int cpu)
>> +{
>> +	int start_idx, idx, type;
>> +
>> +	pagefault_disable();
>> +	type = kmap_atomic_idx();
>> +	start_idx = type + 1 + KM_TYPE_NR * cpu;
>> +
>> +	for (idx = start_idx; idx < KM_TYPE_NR + KM_TYPE_NR * cpu; idx++) {
>> +		unsigned long vaddr = __fix_to_virt(FIX_KMAP_BEGIN + idx);
>> +		set_top_pte(vaddr, __pte(0));
>> +	}
>> +	pagefault_enable();
>
> Hmm.  Why are you using pagefault_disable() around this?  This code itself
> should not cause any page faults.  Maybe you mean to disable preemption,
> but that should already be disabled (if not the above is buggy.)  Maybe
> interrupts - that would make more sense, but as soon as interrupts are
> re-enabled, it's possible for drivers to start create kmap_atomic()
> mappings again.
>
> So... the question is... why this... for what use case?
>
> At the moment it just feels like it's rather buggy and racy.
>

Yes, I think the pagefault disabling is overkill and preemption 
disabling is what I was going for. It is indeed possible for drivers to 
start creating kmap_atomic mappings again but I consider that a buggy 
driver design; any driver who intends for all mappings to really be gone 
needs to do proper locking to prevent against cases of getting new mappings.


>> +static int hotplug_kmap_atomic_callback(struct notifier_block *nfb,
>> +                                unsigned long action, void *hcpu)
>> +{
>> +        switch (action & (~CPU_TASKS_FROZEN)) {
>
> Parens around ~CPU_TASKS_FROZEN is not required.
>
>> +        case CPU_DYING:
>> +		kmap_remove_unused_cpu((int)hcpu);
>> +                break;
>> +        default:
>> +                break;
>> +        }
>> +
>> +        return NOTIFY_OK;
>
> Please watch your indentation...
>
>> +}
>> +
>> +static struct notifier_block hotplug_kmap_atomic_notifier = {
>> +        .notifier_call = hotplug_kmap_atomic_callback,
>> +};
>> +
>> +static int __init init_kmap_atomic(void)
>> +{
>> +
>
> And this blank line isn't needed.
>

Yes, I missed the checkpatch cleanup.

Thanks,
Laura

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation


From linux at arm.linux.org.uk  Mon Apr 22 13:47:12 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Mon, 22 Apr 2013 18:47:12 +0100
Subject: [PATCH] mm: add an option to disable bounce
In-Reply-To: <1366644180-6140-1-git-send-email-vinayakm.list@gmail.com>
References: <1366644180-6140-1-git-send-email-vinayakm.list@gmail.com>
Message-ID: <20130422174712.GS14496@n2100.arm.linux.org.uk>

On Mon, Apr 22, 2013 at 08:53:00PM +0530, vinayakm.list at gmail.com wrote:
> From: Vinayak Menon <vinayakm.list at gmail.com>
> 
> There are times when HIGHMEM is enabled, but
> we don't prefer CONFIG_BOUNCE to be enabled.
> CONFIG_BOUNCE can reduce the block device
> throughput, and this is not ideal for machines
> where we don't gain much by enabling it. So
> provide an option to deselect CONFIG_BOUNCE. The
> observation was made while measuring eMMC throughput
> using iozone on an ARM device with 1GB RAM.
> 
> Signed-off-by: Vinayak Menon <vinayakm.list at gmail.com>
> ---
>  mm/Kconfig |    6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/mm/Kconfig b/mm/Kconfig
> index 3bea74f..29f9736 100644
> --- a/mm/Kconfig
> +++ b/mm/Kconfig
> @@ -263,8 +263,14 @@ config ZONE_DMA_FLAG
>  	default "1"
>  
>  config BOUNCE
> +	bool "Enable bounce buffers"
>  	def_bool y
>  	depends on BLOCK && MMU && (ZONE_DMA || HIGHMEM)

I don't think this is correct.  You shouldn't use "bool" with "def_bool".
Sure, add the "bool", but also change "def_bool" to "default".


From linux at arm.linux.org.uk  Mon Apr 22 13:49:05 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Mon, 22 Apr 2013 18:49:05 +0100
Subject: [PATCH v1] ARM: do not select ARCH_VEXPRESS by default on
 ARCH_MULTI_V7
In-Reply-To: <1366634604-12637-1-git-send-email-srinivas.kandagatla@st.com>
References: <1366634604-12637-1-git-send-email-srinivas.kandagatla@st.com>
Message-ID: <20130422174905.GT14496@n2100.arm.linux.org.uk>

On Mon, Apr 22, 2013 at 01:43:24PM +0100, Srinivas KANDAGATLA wrote:
> From: Srinivas Kandagatla <srinivas.kandagatla at st.com>
> 
> This patch removes ARCH_VEXPRESS selection as default when ARCH_MULTI_V7
> is selected. ARCH_VEXPRESS should be selected from
> mach-vexpress/Kconfig.
> 
> Without this patch, any multiplatform build will have ARCH_VEXPRESS
> selected, as a result all the vexpress associated dtbs are build when we
> make dtbs.
> 
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla at st.com>

There are reasons that this is done at the moment; Arnd has this under
control, and will remove this when stuff is ready to survive without
VEXPRESS enabled.


From sergei.shtylyov at cogentembedded.com  Mon Apr 22 13:52:22 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Mon, 22 Apr 2013 21:52:22 +0400
Subject: [PATCH v5 0/9] Reorganize R8A7779/Marzen USB code
In-Reply-To: <20130422145122.GQ14496@n2100.arm.linux.org.uk>
References: <201304200155.13492.sergei.shtylyov@cogentembedded.com>
 <20130422145122.GQ14496@n2100.arm.linux.org.uk>
Message-ID: <517578D6.2050409@cogentembedded.com>

Hello.

Hello.

On 04/22/2013 06:51 PM, Russell King - ARM Linux wrote:

>
>> Hello.
>>
>>     Here's the set of 9 patches against the Simon Horman's 'renesas.git' repo,
>> 'renesas-next-20130419' tag.  It was created to fix the shortcomings in the
>> R8A7779/Marzen USB platform code and R8A7779 USB common PHY driver, and so
>> spans both arch/arm/mach-shmobile/ and drivers/usb/ subtrees (some patches have
>> to touch both subtrees). The patches were conceived with the complete
>> bisectability goal in mind.
>>
>> [1/9] ARM: shmobile: Marzen: move USB EHCI, OHCI, and PHY devices to R8A7779 code
>> [2/9] ehci-platform: add pre_setup() method to platform data
>> [3/9] ARM: shmobile: r8a7779: setup EHCI internal buffer
>> [4/9] rcar-phy: remove EHCI internal buffer setup
>> [5/9] ARM: shmobile: r8a7779: remove USB PHY 2nd memory resource
>> [6/9] rcar-phy: correct base address
>> [7/9] rcar-phy: add platform data
>> [8/9] ARM: shmobile: Marzen: pass platform data to USB PHY device
>> [9/9] rcar-phy: handle platform data
> Please can you rethink how you use get_maintainers.pl and send out
> patches?
>
> Sending them "To" everyone who get_maintainers.pl spits out is all well
> and good, but it means that there's no discrimination between those who
> have a primary interest in the patches and those who don't.

    Heh, yet I completely ignore the "commit signers" list that it has
a habit to spitting out. :-)

> Examples of people with a primary interest: those maintaining the
> platforms and/or those who you want to merge your patches.  These
> should be on the To: line.
>
> Those who don't: everyone else who may have an interest - these go on
> the Cc: line.
>
> You're about the only person I regularly get patches for platforms which
> are sent To: me all the time, and really they are not "important" for
> me (though they are important enough for me to be Cc'd).

    OK, I'll try to make this distinction in the future. I just didn't 
think the
difference between To: and Cc: was really that important to anyone.

> What I'm saying is that having come back from a vacation last Tuesday,
> I could not just scan through this mailbox for all messages marked "To"
> me and treat those as being more important than everything else, because
> soo many of yours were captured by that.  And I'm still tacking the
> backlog today, almost a week later.

     Sorry about that.

> Please be more considerate to those who you're mailing.
>
> (Also, make sure you don't honor the Mail-Followup-To: header, which
> will lead your mailer to keep placing all recipients into the To:
> header on reply - because it breaks the above reasoning.  The To:
> header should be those recipients who you are directly discussing, and
> Cc: is for "interested side parties".)

    That would be somewhat tougher, as I'm usually quick to hit the send
button after completing the email, so can forget to change people from
To: list to CC: list... but I'll have to promise to try to give it more 
attention
from now on.

> Thanks.

WBR, Sergei



From lorenzo.pieralisi at arm.com  Mon Apr 22 14:00:59 2013
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Mon, 22 Apr 2013 19:00:59 +0100
Subject: [RFC PATCH v2 00/13] ARM: DT cpu bindings updates
In-Reply-To: <20130422164112.GB3076@mudshark.cambridge.arm.com>
References: <1366644455-16550-1-git-send-email-lorenzo.pieralisi@arm.com>
 <20130422164112.GB3076@mudshark.cambridge.arm.com>
Message-ID: <20130422180057.GB17071@e102568-lin.cambridge.arm.com>

Hi Will,

On Mon, Apr 22, 2013 at 05:41:12PM +0100, Will Deacon wrote:
> Hi Lorenzo,
> 
> On Mon, Apr 22, 2013 at 04:27:22PM +0100, Lorenzo Pieralisi wrote:
> > Code relying on the reg property size to be 4-bytes will break when
> > dtb compiled for 64-bit kernels are used to boot a 32-bit system so
> > kernel code relying on that (bogus) assumption must be updated properly.
> 
> So that code currently includes kvmtool, and I think it's unfair to break
> it:
> 
> 	- kvmtool can boot either 32-bit or 64-bit guests under a 64-bit
> 	  kernel and only AFF0 is exposed by the KVM host (containing the
> 	  vcpu id). This allows us to use a single cell for the reg
> 	  property, regardless of the guest payload.
> 
> 	- It always sets the #address-cells property correctly, so if it
> 	  passes a 32-bit reg property, then #address-cells will be 0x1
> 
> 	- This scheme worked fine with older kernels
> 
> Why can't we instead allow the kernel to zero extend single-cell CPU reg
> properies on 64-bit systems? We can always check them against the logical
> map and barf if they don't match what's sitting in the hardware, without
> penalising machines which don't make use of the upper bits. Given that
> people *will* run 32-bit OSs on 64-bit CPUs (a use-case which we allow), I
> don't think penalising 64-bit software is the right thing to do.
> 
> Thoughts? I notice Catalin has some patches queued for arm64 which
> unconditionally use of_property_read_u64, but I have a patch to honour the
> #address-cells property instead.

Basically you want me to rule out passing a dtb with cpus node having
#address-cells == 2 to a 32-bit kernel, correct ? Or put it another way:

- a 32-bit kernel must always get passed a dtb with cpus node
  #address-cells == 1. If the system is ARMv8 with CPUs having
  MPIDR_EL1[63:32] != 0x0, well, running 32-bit kernel on it is not
  the safest thing to do anyway.
- a 64 bit kernel can get passed a dtb blob with configurable
  #address-cells [1,2]. If MPIDR_EL1[63:32] is == 0, #address-cells can be
  set to 1 and the OS must zero extend the reg property. #address-cells
  == 1 implies -> zero extension required in the OS.

It makes sense. I disagree on the check you mentioned, we are not able
to probe MPIDR_EL1, so if the kernel gets passed wrong reg values we have
a problem, logical_map depends on DT, if DT assumes MPIDR_EL1[63:32] is
0 but it is not there is no way we can recover.

I will update the bindings and arm32 parsing code if nobody objects.

Lorenzo



From tony at atomide.com  Mon Apr 22 14:03:17 2013
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 22 Apr 2013 11:03:17 -0700
Subject: Multiple issues with omap4 panda es in linux next
In-Reply-To: <5174F7A8.7070308@ti.com>
References: <20130419171318.GK10155@atomide.com>
 <5174F7A8.7070308@ti.com>
Message-ID: <20130422180316.GA10155@atomide.com>

* Kishon Vijay Abraham I <kishon at ti.com> [130422 01:46]:
> Hi,
> 
> On Friday 19 April 2013 10:43 PM, Tony Lindgren wrote:
> >Hi all,
> >
> >Here's a list of breakage I've noticed so far while trying to
> >use linux next on my pandaboard es. Probably similar issues exist
> >on other boards as well.
> >
> >Ideally we would not have any breakage by the merge window, so
> >let's try to get these fixed ASAP:
> >
> >1. Serial console broken on panda es booting with DT
> >
> >The symptoms are dmesg output stopping after few lines
> >and only continuing after pressing a key. Does not seem to
> >happen on blaze with DT for some reason. And does not happen
> >on panda es with legacy booting.
> >
> >2. MUSB fails with legacy booting and DT on panda es
> >
> >With both legacy and DT booting I get something like:
> >
> >HS USB OTG: no transceiver configured
> >musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with status -517
> 
> The dt should work fine with https://patchwork.kernel.org/patch/2423061/.

OK thanks for checking that.
 
> But non-dt has got a real issue. We were using usb_bind_phy() for
> binding the controller with the PHY (we use device names). But in
> linux-next the device names have changed because of using
> PLATFORM_DEVID_AUTO. We can modify the usb_bind_phy() calls to use
> the new device names, But I suspect the device names can change
> again. Not sure what we can do here :-(

Let's do a minimal fix for v3.10. Then we'll make omap4 DT only for
v3.11 and that problem is solved for good.

Regards,

Tony


From tony at atomide.com  Mon Apr 22 14:08:22 2013
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 22 Apr 2013 11:08:22 -0700
Subject: Multiple issues with omap4 panda es in linux next
In-Reply-To: <51752B48.50700@ti.com>
References: <20130419171318.GK10155@atomide.com> <5174FE16.6080307@ti.com>
 <51750FF8.6000401@ti.com> <51752B48.50700@ti.com>
Message-ID: <20130422180822.GB10155@atomide.com>

* Grygorii Strashko <grygorii.strashko at ti.com> [130422 05:27]:
> On 04/22/2013 01:24 PM, Tomi Valkeinen wrote:
> >On 2013-04-22 12:08, Tomi Valkeinen wrote:
> >>On 2013-04-19 20:13, Tony Lindgren wrote:
> >>
> >>>3. DSS fails with DT booting
> >>>
> >>>Works with legacy booting but fails with DT. I'm almost certain
> >>>the DT booting was working last week or so?
> >>>
> >>>This is what I now get with DT booting:
> >>>
> >>>omapdss DSI error: can't get VDDS_DSI regulator
> >>>omapdss HDMI error: can't get VDDA_HDMI_DAC regulator
> >>>omapdss HDMI error: device hdmi init failed: -517
> >>>omapdss CORE error: driver probe failed: -22
> >>>...
> >>I think this is the issue Christoph Fritz reported earlier, DSS is being
> >>initialized before TWL, and thus DSS doesn't find the regulators.
> >>
> >>The proper fix is of course to make DSS support EPROBE_DEFER, but that's
> >>easier said than done. I'll have a look if I can get it working enough
> >>to fix this issue.
> >Yes, it seems delayed regulator initialization brought up this issue.
> >
> >I hacked DSI driver of omapdss and Taal panel driver to somewhat work
> >with EPROBE_DEFER. But then the issue was with omapfb.
> >
> >omapfb is currently set to start at late_initcall, so that omapdss and
> >panels are loaded before omapfb. But even that's not late enough to get
> >the regulators for omapdss. It seems the regulators get also initialized
> >at the late_initcall level. Changing omapfb to late_initcall_sync was
> >late enough to get things working.
> >
> >Again, making omapdss, panel drivers and omapfb support EPROBE_DEFER and
> >dynamic panel driver insertion is the proper fix, but it's a big job,
> >and there are "interesting" issues with it (like how to know if a panel
> >device will ever get a driver loaded).
> >
> >But is there something wrong with the TWL and regulators? late_initcall
> >sounds rather late for such a core resource. Even if all drivers
> >supported EPROBE_DEFER, won't it cause extra delays in the boot as
> >drivers are getting probed multiple times?
> >
> >As for fixing the DSS problem for 3.10, I don't have any ideas except
> >pure hacks. I'll continue studying this.
> Hi Tomi,
> twl is not initialized because of I2C,
> I2C is not initialized because of pinctrl-single,
> pinctrl-single is initialized at mudule/device init time.
> So, most everything will be shifted at late_initcall time.
> 
> Hack that sequence is here - https://patchwork.kernel.org/patch/2444501/

Hmm I'm pretty sure the LCD was working on panda with DT
few weeks ago?

In any case, all those drivers should be just module_init
so we get out of the race to bottom to initialize drivers
early. Pinctrl is already before i2c in drivers/Makefile.

I suspect there may be some recent regression that has
happened in linux next over past few weeks.

Regards,

Tony


From tixy at linaro.org  Mon Apr 22 14:08:36 2013
From: tixy at linaro.org (Jon Medhurst (Tixy))
Date: Mon, 22 Apr 2013 19:08:36 +0100
Subject: [PATCH] ARM: make cpu_init() notrace
In-Reply-To: <20130422140711.GI14496@n2100.arm.linux.org.uk>
References: <1366302046.3388.8.camel@linaro1.home>
 <20130422140711.GI14496@n2100.arm.linux.org.uk>
Message-ID: <1366654116.3989.16.camel@computer5.home>

On Mon, 2013-04-22 at 15:07 +0100, Russell King - ARM Linux wrote:
> On Thu, Apr 18, 2013 at 05:20:46PM +0100, Jon Medhurst (Tixy) wrote:
> > On resume from CPU power down any trace hooks enabled in cpu_init()
> > will get called before that function has done set_my_cpu_offset(),
> > so any use of per-cpu variables by trace hook code will cause bad
> > things to happen. Prevent this by marking the function notrace.
> > 
> > This fixes lockups/crashes seen when enabling function tracer on TC2
> > with the not yet mainlined cpuidle driver.
> 
> Looks sane.  Needs to go to the patch system though.  Not sure if it'll
> make 3.9 given its proximity (we're on -rc8).

Added as patch 7700/1. Don't think there is a big rush as the problem
has probably been there since 3.8 when commit 14318efb (implement
optimized percpu variable access) started using TPIDRPRW; which is
presumably lost over CPU power down.

-- 
Tixy



From vinayakm.list at gmail.com  Mon Apr 22 14:18:51 2013
From: vinayakm.list at gmail.com (vinayak)
Date: Mon, 22 Apr 2013 23:48:51 +0530
Subject: [PATCH] mm: add an option to disable bounce
In-Reply-To: <20130422174712.GS14496@n2100.arm.linux.org.uk>
References: <1366644180-6140-1-git-send-email-vinayakm.list@gmail.com>
 <20130422174712.GS14496@n2100.arm.linux.org.uk>
Message-ID: <51757F0B.1090104@gmail.com>

On Monday 22 April 2013 11:17 PM, Russell King - ARM Linux wrote:

> On Mon, Apr 22, 2013 at 08:53:00PM +0530, vinayakm.list at gmail.com wrote:
>> From: Vinayak Menon <vinayakm.list at gmail.com>
>>
>> There are times when HIGHMEM is enabled, but
>> we don't prefer CONFIG_BOUNCE to be enabled.
>> CONFIG_BOUNCE can reduce the block device
>> throughput, and this is not ideal for machines
>> where we don't gain much by enabling it. So
>> provide an option to deselect CONFIG_BOUNCE. The
>> observation was made while measuring eMMC throughput
>> using iozone on an ARM device with 1GB RAM.
>>
>> Signed-off-by: Vinayak Menon <vinayakm.list at gmail.com>
>> ---
>>  mm/Kconfig |    6 ++++++
>>  1 file changed, 6 insertions(+)
>>
>> diff --git a/mm/Kconfig b/mm/Kconfig
>> index 3bea74f..29f9736 100644
>> --- a/mm/Kconfig
>> +++ b/mm/Kconfig
>> @@ -263,8 +263,14 @@ config ZONE_DMA_FLAG
>>  	default "1"
>>  
>>  config BOUNCE
>> +	bool "Enable bounce buffers"
>>  	def_bool y
>>  	depends on BLOCK && MMU && (ZONE_DMA || HIGHMEM)
> 
> I don't think this is correct.  You shouldn't use "bool" with "def_bool".
> Sure, add the "bool", but also change "def_bool" to "default".


Yes. I will change it to "default" and this looks to be correct
even from the definition in kconfig-language.txt. But I see other
instances in mm/Kconfig, where bool and def_bool are used together. When
I had tested this patch with def_bool, it worked as expected.


From mturquette at linaro.org  Mon Apr 22 14:59:02 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Mon, 22 Apr 2013 11:59:02 -0700
Subject: linux-next ARM multi-platform randconfig errors
In-Reply-To: <5170B4C6.1030300@gmail.com>
References: <5170B4C6.1030300@gmail.com>
Message-ID: <20130422185902.17530.70477@quantum>

Quoting Rob Herring (2013-04-18 20:06:46)
> drivers/clk/ux500/clk-prcc.c:145:13: error: conflicting types for 'clk_reg_prcc_pclk'
> drivers/clk/ux500/clk-prcc.c:155:13: error: conflicting types for 'clk_reg_prcc_kclk'

I had a hard time compiling for u8500 with linux-next.  Seems lots of
brokenness there.  Anyways the fix seems trivial so here it is, as
applied to clk-next:



From c700835bf8568f9c183c9b6aa7794d29266da15b Mon Sep 17 00:00:00 2001
From: Mike Turquette <mturquette at linaro.org>
Date: Mon, 22 Apr 2013 11:46:10 -0700
Subject: [PATCH] clk: ux500: fix mismatched types

As reported by Rob Herring[1] there were some mismatched types between
drivers/clk/ux500/clk.h and the corresponding function definitions:

drivers/clk/ux500/clk-prcc.c:145:13: error: conflicting types for 'clk_reg_prcc_pclk'
drivers/clk/ux500/clk-prcc.c:155:13: error: conflicting types for 'clk_reg_prcc_kclk'

[1] http://article.gmane.org/gmane.linux.ports.arm.kernel/232246

Reported-by: Rob Herring <robherring2 at gmail.com>
Signed-off-by: Mike Turquette <mturquette at linaro.org>
Cc: Ulf Hansson <ulf.hansson at linaro.org>
Cc: Linus Walleij <linus.walleij at linaro.org>
---
 drivers/clk/ux500/clk.h |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/ux500/clk.h b/drivers/clk/ux500/clk.h
index 3d2dfdc..a2bb92d 100644
--- a/drivers/clk/ux500/clk.h
+++ b/drivers/clk/ux500/clk.h
@@ -12,16 +12,17 @@
 
 #include <linux/clk.h>
 #include <linux/device.h>
+#include <linux/types.h>
 
 struct clk *clk_reg_prcc_pclk(const char *name,
 			      const char *parent_name,
-			      unsigned int phy_base,
+			      resource_size_t phy_base,
 			      u32 cg_sel,
 			      unsigned long flags);
 
 struct clk *clk_reg_prcc_kclk(const char *name,
 			      const char *parent_name,
-			      unsigned int phy_base,
+			      resource_size_t phy_base,
 			      u32 cg_sel,
 			      unsigned long flags);
 
-- 
1.7.10.4



From arnd at arndb.de  Mon Apr 22 15:11:45 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 22 Apr 2013 21:11:45 +0200
Subject: [PATCH RESEND] ARM: EXYNOS: no more support non-DT for EXYNOS SoCs
In-Reply-To: <51756E98.9040606@samsung.com>
References: <51642dab.e844440a.0ad1.ffffc13f@mx.google.com>
 <516571BC.9030909@samsung.com> <51756E98.9040606@samsung.com>
Message-ID: <201304222111.45653.arnd@arndb.de>

On Monday 22 April 2013, Kukjin Kim wrote:
> On 04/10/13 23:05, Kukjin Kim wrote:
> > On 04/10/13 22:55, Arnd Bergmann wrote:
> >> On Wednesday 10 April 2013, Sylwester Nawrocki wrote:
> >>> Hmm, it turns out we are still actively using some boards based on
> >>> Exynos4210 EVT0 SoCs. And since it seems unlikely the patches from
> >>> Tomasz [1] adding basic DT support for those will get merged for
> >>> 3.10, it would be a bit inconvenient to remove the ATAGS support
> >>> now, leaving Exynos4210 Rev. 0 not supported at all.
> >>
> >> I still have hope to get those included.
> >>
> > I agree and I asked Tomasz to re-send universal dt patch.
> >
> Hi Arnd and Olof,
> 
> Is it possible to send one more pull-request for this and something like 
> dt patches for exynos?

I think it's too late for that now, let's just fix the broken pieces
now and do the minimum amount of patches on top of what we have:

* Thomas Abraham's fix for the clk code
* Tomasz Figa's patch to restore Universal C210
* Whatever is needed to get USB working again on Arndale
* Anything else that comes up that is really a bug fix.
* Getting the PWM and ADC drivers working with DT, that can
  easily be done.
* Possibly a patch to mark CONFIG_EXYNOS_ATAGS as broken,
  if you think that helps.

but not:

* The entire series to rework the PWM clock from Tomasz
* The entire series to remove ATAGS support on Exynos
* Any other non-bugfix patches

	Arnd


From arnd at arndb.de  Mon Apr 22 15:18:41 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 22 Apr 2013 21:18:41 +0200
Subject: [RFC PATCH v2 00/13] ARM: DT cpu bindings updates
In-Reply-To: <20130422180057.GB17071@e102568-lin.cambridge.arm.com>
References: <1366644455-16550-1-git-send-email-lorenzo.pieralisi@arm.com>
 <20130422164112.GB3076@mudshark.cambridge.arm.com>
 <20130422180057.GB17071@e102568-lin.cambridge.arm.com>
Message-ID: <201304222118.41262.arnd@arndb.de>

On Monday 22 April 2013, Lorenzo Pieralisi wrote:
> > Thoughts? I notice Catalin has some patches queued for arm64 which
> > unconditionally use of_property_read_u64, but I have a patch to honour the
> > #address-cells property instead.
> 
> Basically you want me to rule out passing a dtb with cpus node having
> #address-cells == 2 to a 32-bit kernel, correct ? Or put it another way:
> 
> - a 32-bit kernel must always get passed a dtb with cpus node
>   #address-cells == 1. 

Why that? For other registers, we allow leading zeroes. This is
already required for MMIO registers on LPAE capable machines.

>   If the system is ARMv8 with CPUs having
>   MPIDR_EL1[63:32] != 0x0, well, running 32-bit kernel on it is not
>   the safest thing to do anyway.

I would assume the hypervisor to provide a virtual MPIDR_EL1 for
a 32 bit kernel in that case.

	Arnd


From tomasz.figa at gmail.com  Mon Apr 22 15:21:05 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Mon, 22 Apr 2013 21:21:05 +0200
Subject: [PATCH v5 00/14] ARM: samsung-time: Prepare for multiplatform
 support
In-Reply-To: <5175755D.20305@samsung.com>
References: <1365794250-14436-1-git-send-email-t.figa@samsung.com>
 <201304122251.41393.arnd@arndb.de> <5175755D.20305@samsung.com>
Message-ID: <8994400.x1JqGELAnV@flatron>

On Tuesday 23 of April 2013 02:37:33 Kukjin Kim wrote:
> On 04/13/13 05:51, Arnd Bergmann wrote:
> > On Friday 12 April 2013, Tomasz Figa wrote:
> >> This series is an attempt to make the samsung-time clocksource driver
> >> ready for multiplatform kernels. It moves the driver to
> >> drivers/clocksource, cleans it up from uses of static
> >> platform-specific definitions, simplifies timer interrupt handling
> >> and adds Device Tree support.
> >> 
> >> The samsung_pwm clocksource driver is made the master driver, which
> >> exposes a single function to the PWM driver to get required data.
> >> Only
> >> samsung-time driver is reworked to use the master driver at this
> >> time,
> >> since the PWM driver can be already considered broken at the moment
> >> and
> >> needs separate series of several patches to fix and clean it up,
> >> which
> >> I am already working on.
> >> 
> >> Tested on Universal C210 board with Device Tree. Not tested without
> >> Device Tree, since it has been already broken before this series.
> >> Compile tested for other related SoCs.
> > 
> > Acked-by: Arnd Bergmann<arnd at arndb.de>
> 
> Applied, this whole series.

It would be nice if we could still get this for 3.10, but AFAIK it is 
already much too late.

I've discussed this matter with Arnd and the solution that can be accepted 
by arm-soc maintainers is to send a subset of this series, like in the 
patch sent by Arnd (clocksource: add samsung pwm timer driver; it needs 
additional fixes, though.).

Best regards,
Tomasz



From arnd at arndb.de  Mon Apr 22 15:25:55 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 22 Apr 2013 21:25:55 +0200
Subject: [PATCH 2/4] arm64: Initial defconfig for APM X-Gene SOC family
In-Reply-To: <20130422173116.GD9602@arm.com>
References: <1366442131-26094-1-git-send-email-vkale@apm.com>
 <2165570.9Zy5vrhoIa@wuerfel> <20130422173116.GD9602@arm.com>
Message-ID: <201304222125.55220.arnd@arndb.de>

On Monday 22 April 2013, Catalin Marinas wrote:
> That's good as we can get any automatic builds using defconfig to test
> all the platforms. The only issue I see is that as the number of SoCs
> grows, if you only need to select a single SoC you could end up with
> features enabled for other platforms.

I don't see that as a problem, as long as the defconfig just works for
everyone. Anyone building an embedded system can just disable the drivers
they don't need.

	Arnd


From gmbnomis at gmail.com  Mon Apr 22 15:54:57 2013
From: gmbnomis at gmail.com (Simon Baatz)
Date: Mon, 22 Apr 2013 21:54:57 +0200
Subject: [PATCH 0/3] ARM: Kirkwood: Add DT support for (eSATA) Sheevaplug
Message-ID: <1366660500-26835-1-git-send-email-gmbnomis@gmail.com>

These patches add DT support for the Sheevaplugs by Globalscale
Technologies.  There exists two versions, one with an eSATA port and
one without.

Surprisingly, the conversion was not straight forward. In the eSATA
version (board revision 1.3), the CD and WP pins are connected to GPIO
lines, but I could not get this to work.  Apparently, I am not the only
one ([1]).  I found that the pins are reversed on my hardware and use
different active low/active high settings.

Thus, the first patch adds support for the GPIO active low/high flag in
DT to the mvsdio driver.

With that, everything except the Gigabit Ethernet can be described in
the DTS.  I have split the DTS and the board support files into two
patches.  This way, we can drop the last patch once we can describe
everything in the DTS or we can squash them together if we don't want
to wait.

I could only test on an eSATA Sheevaplug. I found patches with
different LEDs for the Sheevaplug.  Thus, I would highly appreciate if
someone with the hardware could give this a spin on a non-eSATA
version.  Some additional testing of the change detect and write
protect behaviour for sdio can't hurt either.  I hope that there aren't
board revisions with different CD/WP pins out there.

[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2011-August/062567.html

Simon Baatz (3):
  mmc: mvsdio: Support inverted CD and WP GPIO lines
  ARM: Kirkwood: Add dts files for Sheevaplug and eSATA Sheevaplug
  ARM: Kirkwood: Add DT support for Sheevaplug and Sheevaplug eSATA

 arch/arm/boot/dts/Makefile                        |    2 +
 arch/arm/boot/dts/kirkwood-mplcec4.dts            |    2 +-
 arch/arm/boot/dts/kirkwood-sheevaplug-common.dtsi |   97 +++++++++++++++++++++
 arch/arm/boot/dts/kirkwood-sheevaplug-esata.dts   |   40 +++++++++
 arch/arm/boot/dts/kirkwood-sheevaplug.dts         |   43 +++++++++
 arch/arm/mach-kirkwood/Kconfig                    |    7 ++
 arch/arm/mach-kirkwood/Makefile                   |    1 +
 arch/arm/mach-kirkwood/board-dt.c                 |    4 +
 arch/arm/mach-kirkwood/board-sheevaplug.c         |   27 ++++++
 arch/arm/mach-kirkwood/common.h                   |    5 ++
 drivers/mmc/host/mvsdio.c                         |   14 ++-
 11 files changed, 239 insertions(+), 3 deletions(-)
 create mode 100644 arch/arm/boot/dts/kirkwood-sheevaplug-common.dtsi
 create mode 100644 arch/arm/boot/dts/kirkwood-sheevaplug-esata.dts
 create mode 100644 arch/arm/boot/dts/kirkwood-sheevaplug.dts
 create mode 100644 arch/arm/mach-kirkwood/board-sheevaplug.c

-- 
1.7.9.5



From gmbnomis at gmail.com  Mon Apr 22 15:54:58 2013
From: gmbnomis at gmail.com (Simon Baatz)
Date: Mon, 22 Apr 2013 21:54:58 +0200
Subject: [PATCH 1/3] mmc: mvsdio: Support inverted CD and WP GPIO lines
In-Reply-To: <1366660500-26835-1-git-send-email-gmbnomis@gmail.com>
References: <1366660500-26835-1-git-send-email-gmbnomis@gmail.com>
Message-ID: <1366660500-26835-2-git-send-email-gmbnomis@gmail.com>

The slot-gpio helper functions allow to specify whether card detect and
write protect GPIO lines are active high or active low.  Since DT
allows to specify active low/high for GPIO lines as well, we can simply
initialize the flags for slot-gpio using the GPIO flags to support all
cases.

We need to adapt the dts files that use CD/WP via GPIO accordingly.
Only the dts for "MPL CEC4" is affected by this change.

Signed-off-by: Simon Baatz <gmbnomis at gmail.com>
---
 arch/arm/boot/dts/kirkwood-mplcec4.dts |    2 +-
 drivers/mmc/host/mvsdio.c              |   14 ++++++++++++--
 2 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/kirkwood-mplcec4.dts b/arch/arm/boot/dts/kirkwood-mplcec4.dts
index 7588241..bf3a58c 100644
--- a/arch/arm/boot/dts/kirkwood-mplcec4.dts
+++ b/arch/arm/boot/dts/kirkwood-mplcec4.dts
@@ -136,7 +136,7 @@
 			pinctrl-0 = <&pmx_sdio &pmx_sdio_cd>;
 			pinctrl-names = "default";
 			status = "okay";
-			cd-gpios = <&gpio1 15 0>;
+			cd-gpios = <&gpio1 15 1>;
 			/* No WP GPIO */
 		};
 	};
diff --git a/drivers/mmc/host/mvsdio.c b/drivers/mmc/host/mvsdio.c
index 145cdaf..d444efd 100644
--- a/drivers/mmc/host/mvsdio.c
+++ b/drivers/mmc/host/mvsdio.c
@@ -691,6 +691,7 @@ static int __init mvsd_probe(struct platform_device *pdev)
 	struct resource *r;
 	int ret, irq;
 	int gpio_card_detect, gpio_write_protect;
+	enum of_gpio_flags gpio_flags;
 	struct pinctrl *pinctrl;
 
 	r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -731,8 +732,17 @@ static int __init mvsd_probe(struct platform_device *pdev)
 		}
 
 		host->base_clock = clk_get_rate(host->clk) / 2;
-		gpio_card_detect = of_get_named_gpio(np, "cd-gpios", 0);
-		gpio_write_protect = of_get_named_gpio(np, "wp-gpios", 0);
+		gpio_card_detect = of_get_named_gpio_flags(np, "cd-gpios", 0,
+						     &gpio_flags);
+		if (gpio_is_valid(gpio_card_detect) &&
+		    !(gpio_flags & OF_GPIO_ACTIVE_LOW))
+			mmc->caps2 |= MMC_CAP2_CD_ACTIVE_HIGH;
+
+		gpio_write_protect = of_get_named_gpio_flags(np, "wp-gpios", 0,
+						       &gpio_flags);
+		if (gpio_is_valid(gpio_write_protect) &&
+		    !(gpio_flags & OF_GPIO_ACTIVE_LOW))
+			mmc->caps2 |= MMC_CAP2_RO_ACTIVE_HIGH;
 	} else {
 		const struct mvsdio_platform_data *mvsd_data;
 		mvsd_data = pdev->dev.platform_data;
-- 
1.7.9.5



From gmbnomis at gmail.com  Mon Apr 22 15:54:59 2013
From: gmbnomis at gmail.com (Simon Baatz)
Date: Mon, 22 Apr 2013 21:54:59 +0200
Subject: [PATCH 2/3] ARM: Kirkwood: Add dts files for Sheevaplug and eSATA
 Sheevaplug
In-Reply-To: <1366660500-26835-1-git-send-email-gmbnomis@gmail.com>
References: <1366660500-26835-1-git-send-email-gmbnomis@gmail.com>
Message-ID: <1366660500-26835-3-git-send-email-gmbnomis@gmail.com>


Signed-off-by: Simon Baatz <gmbnomis at gmail.com>
---
 arch/arm/boot/dts/Makefile                        |    2 +
 arch/arm/boot/dts/kirkwood-sheevaplug-common.dtsi |   97 +++++++++++++++++++++
 arch/arm/boot/dts/kirkwood-sheevaplug-esata.dts   |   40 +++++++++
 arch/arm/boot/dts/kirkwood-sheevaplug.dts         |   43 +++++++++
 4 files changed, 182 insertions(+)
 create mode 100644 arch/arm/boot/dts/kirkwood-sheevaplug-common.dtsi
 create mode 100644 arch/arm/boot/dts/kirkwood-sheevaplug-esata.dts
 create mode 100644 arch/arm/boot/dts/kirkwood-sheevaplug.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 9c62558..c2f52db 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -70,6 +70,8 @@ dtb-$(CONFIG_ARCH_KIRKWOOD) += kirkwood-dns320.dtb \
 	kirkwood-ns2max.dtb \
 	kirkwood-ns2mini.dtb \
 	kirkwood-nsa310.dtb \
+	kirkwood-sheevaplug.dtb \
+	kirkwood-sheevaplug-esata.dtb \
 	kirkwood-topkick.dtb \
 	kirkwood-ts219-6281.dtb \
 	kirkwood-ts219-6282.dtb \
diff --git a/arch/arm/boot/dts/kirkwood-sheevaplug-common.dtsi b/arch/arm/boot/dts/kirkwood-sheevaplug-common.dtsi
new file mode 100644
index 0000000..9d59475
--- /dev/null
+++ b/arch/arm/boot/dts/kirkwood-sheevaplug-common.dtsi
@@ -0,0 +1,97 @@
+/*
+ * kirkwood-sheevaplug-common.dts - Common parts for Sheevaplugs
+ *
+ * Copyright (C) 2013 Simon Baatz <gmbnomis at gmail.com>
+ *
+ * Licensed under GPLv2
+ */
+
+/include/ "kirkwood.dtsi"
+/include/ "kirkwood-6281.dtsi"
+
+/ {
+	memory {
+		device_type = "memory";
+		reg = <0x00000000 0x20000000>;
+	};
+
+	chosen {
+		bootargs = "console=ttyS0,115200n8 earlyprintk";
+	};
+
+	ocp at f1000000 {
+		pinctrl: pinctrl at 10000 {
+
+			pmx_usb_power_enable: pmx-usb-power-enable {
+				marvell,pins = "mpp29";
+				marvell,function = "gpio";
+			};
+			pmx_led_red: pmx-led-red {
+				marvell,pins = "mpp46";
+				marvell,function = "gpio";
+			};
+			pmx_led_blue: pmx-led-blue {
+				marvell,pins = "mpp49";
+				marvell,function = "gpio";
+			};
+			pmx_sdio_cd: pmx-sdio-cd {
+				marvell,pins = "mpp44";
+				marvell,function = "gpio";
+			};
+			pmx_sdio_wp: pmx-sdio-wp {
+				marvell,pins = "mpp47";
+				marvell,function = "gpio";
+			};
+		};
+		serial at 12000 {
+			status = "okay";
+		};
+
+		nand at 3000000 {
+			status = "okay";
+
+			partition at 0 {
+				label = "u-boot";
+				reg = <0x0000000 0x100000>;
+			};
+
+			partition at 100000 {
+				label = "uImage";
+				reg = <0x0100000 0x400000>;
+			};
+
+			partition at 500000 {
+				label = "root";
+				reg = <0x0500000 0x1fb00000>;
+			};
+		};
+	};
+
+	regulators {
+		compatible = "simple-bus";
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		usb_power: regulator at 1 {
+			compatible = "regulator-fixed";
+			reg = <1>;
+			regulator-name = "USB Power";
+			regulator-min-microvolt = <5000000>;
+			regulator-max-microvolt = <5000000>;
+			enable-active-high;
+			regulator-always-on;
+			regulator-boot-on;
+			gpio = <&gpio0 29 0>;
+		};
+	};
+
+	gpio-leds {
+		compatible = "gpio-leds";
+
+		health {
+			label = "sheevaplug:blue:health";
+			gpios = <&gpio1 17 1>;
+			linux,default-trigger = "default-on";
+		};
+	};
+};
diff --git a/arch/arm/boot/dts/kirkwood-sheevaplug-esata.dts b/arch/arm/boot/dts/kirkwood-sheevaplug-esata.dts
new file mode 100644
index 0000000..1c6946a
--- /dev/null
+++ b/arch/arm/boot/dts/kirkwood-sheevaplug-esata.dts
@@ -0,0 +1,40 @@
+/*
+ * kirkwood-sheevaplug-esata.dts - Device tree file for eSATA Sheevaplug
+ *
+ * Copyright (C) 2013 Simon Baatz <gmbnomis at gmail.com>
+ *
+ * Licensed under GPLv2
+ */
+
+/dts-v1/;
+
+/include/ "kirkwood-sheevaplug-common.dtsi"
+
+/ {
+	model = "Globalscale Technologies eSATA SheevaPlug";
+	compatible = "globalscale,sheevaplug-esata-rev13", "globalscale,sheevaplug-esata", "globalscale,sheevaplug", "marvell,kirkwood-88f6281", "marvell,kirkwood";
+
+	ocp at f1000000 {
+		pinctrl: pinctrl at 10000 {
+
+			pinctrl-0 = < &pmx_nand &pmx_uart0
+				      &pmx_usb_power_enable
+				      &pmx_led_blue>;
+			pinctrl-names = "default";
+
+		};
+
+		sata at 80000 {
+			status = "okay";
+			nr-ports = <2>;
+		};
+
+		mvsdio at 90000 {
+			pinctrl-0 = <&pmx_sdio &pmx_sdio_cd &pmx_sdio_wp>;
+			pinctrl-names = "default";
+			status = "okay";
+			cd-gpios = <&gpio1 12 1>;
+			wp-gpios = <&gpio1 15 0>;
+		};
+	};
+};
diff --git a/arch/arm/boot/dts/kirkwood-sheevaplug.dts b/arch/arm/boot/dts/kirkwood-sheevaplug.dts
new file mode 100644
index 0000000..ca2ac1c
--- /dev/null
+++ b/arch/arm/boot/dts/kirkwood-sheevaplug.dts
@@ -0,0 +1,43 @@
+/*
+ * kirkwood-sheevaplug-esata.dts - Device tree file for Sheevaplug
+ *
+ * Copyright (C) 2013 Simon Baatz <gmbnomis at gmail.com>
+ *
+ * Licensed under GPLv2
+ */
+
+/dts-v1/;
+
+/include/ "kirkwood-sheevaplug-common.dtsi"
+
+/ {
+	model = "Globalscale Technologies SheevaPlug";
+	compatible = "globalscale,sheevaplug", "marvell,kirkwood-88f6281", "marvell,kirkwood";
+
+	ocp at f1000000 {
+		pinctrl: pinctrl at 10000 {
+
+			pinctrl-0 = < &pmx_nand &pmx_uart0
+				      &pmx_usb_power_enable
+				      &pmx_led_red
+				      &pmx_led_blue>;
+			pinctrl-names = "default";
+
+		};
+
+		mvsdio at 90000 {
+			pinctrl-0 = <&pmx_sdio>;
+			pinctrl-names = "default";
+			status = "okay";
+		};
+	};
+
+	gpio-leds {
+		compatible = "gpio-leds";
+
+		misc {
+			label = "sheevaplug:red:misc";
+			gpios = <&gpio1 14 1>;
+		};
+	};
+};
-- 
1.7.9.5



From gmbnomis at gmail.com  Mon Apr 22 15:55:00 2013
From: gmbnomis at gmail.com (Simon Baatz)
Date: Mon, 22 Apr 2013 21:55:00 +0200
Subject: [PATCH 3/3] ARM: Kirkwood: Add DT support for Sheevaplug and
 Sheevaplug eSATA
In-Reply-To: <1366660500-26835-1-git-send-email-gmbnomis@gmail.com>
References: <1366660500-26835-1-git-send-email-gmbnomis@gmail.com>
Message-ID: <1366660500-26835-4-git-send-email-gmbnomis@gmail.com>


Signed-off-by: Simon Baatz <gmbnomis at gmail.com>
---
 arch/arm/mach-kirkwood/Kconfig            |    7 +++++++
 arch/arm/mach-kirkwood/Makefile           |    1 +
 arch/arm/mach-kirkwood/board-dt.c         |    4 ++++
 arch/arm/mach-kirkwood/board-sheevaplug.c |   27 +++++++++++++++++++++++++++
 arch/arm/mach-kirkwood/common.h           |    5 +++++
 5 files changed, 44 insertions(+)
 create mode 100644 arch/arm/mach-kirkwood/board-sheevaplug.c

diff --git a/arch/arm/mach-kirkwood/Kconfig b/arch/arm/mach-kirkwood/Kconfig
index 7b6a64b..5bf6642 100644
--- a/arch/arm/mach-kirkwood/Kconfig
+++ b/arch/arm/mach-kirkwood/Kconfig
@@ -58,6 +58,13 @@ config ARCH_KIRKWOOD_DT
 	  Say 'Y' here if you want your kernel to support the
 	  Marvell Kirkwood using flattened device tree.
 
+config MACH_SHEEVAPLUG_DT
+	bool "Marvell (eSATA) SheevaPlug (Flattened Device Tree)"
+	select ARCH_KIRKWOOD_DT
+	help
+	  Say 'Y' here if you want your kernel to support the
+	  Marvell (eSATA) SheevaPlug (Flattened Device Tree).
+
 config MACH_GURUPLUG_DT
 	bool "Marvell GuruPlug Reference Board (Flattened Device Tree)"
 	select ARCH_KIRKWOOD_DT
diff --git a/arch/arm/mach-kirkwood/Makefile b/arch/arm/mach-kirkwood/Makefile
index 4cc4bee..71cb451 100644
--- a/arch/arm/mach-kirkwood/Makefile
+++ b/arch/arm/mach-kirkwood/Makefile
@@ -22,6 +22,7 @@ obj-$(CONFIG_MACH_T5325)		+= t5325-setup.o
 obj-$(CONFIG_ARCH_KIRKWOOD_DT)		+= board-dt.o
 obj-$(CONFIG_MACH_DREAMPLUG_DT)		+= board-dreamplug.o
 obj-$(CONFIG_MACH_GURUPLUG_DT)		+= board-guruplug.o
+obj-$(CONFIG_MACH_SHEEVAPLUG_DT)	+= board-sheevaplug.o
 obj-$(CONFIG_MACH_ICONNECT_DT)		+= board-iconnect.o
 obj-$(CONFIG_MACH_DLINK_KIRKWOOD_DT)	+= board-dnskw.o
 obj-$(CONFIG_MACH_IB62X0_DT)		+= board-ib62x0.o
diff --git a/arch/arm/mach-kirkwood/board-dt.c b/arch/arm/mach-kirkwood/board-dt.c
index d367aa6..0e3ac29 100644
--- a/arch/arm/mach-kirkwood/board-dt.c
+++ b/arch/arm/mach-kirkwood/board-dt.c
@@ -112,6 +112,9 @@ static void __init kirkwood_dt_init(void)
 	if (of_machine_is_compatible("globalscale,guruplug"))
 		guruplug_dt_init();
 
+	if (of_machine_is_compatible("globalscale,sheevaplug"))
+		sheevaplug_dt_init();
+
 	if (of_machine_is_compatible("dlink,dns-kirkwood"))
 		dnskw_init();
 
@@ -161,6 +164,7 @@ static void __init kirkwood_dt_init(void)
 static const char * const kirkwood_dt_board_compat[] = {
 	"globalscale,dreamplug",
 	"globalscale,guruplug",
+	"globalscale,sheevaplug",
 	"dlink,dns-320",
 	"dlink,dns-325",
 	"iom,iconnect",
diff --git a/arch/arm/mach-kirkwood/board-sheevaplug.c b/arch/arm/mach-kirkwood/board-sheevaplug.c
new file mode 100644
index 0000000..fa38937
--- /dev/null
+++ b/arch/arm/mach-kirkwood/board-sheevaplug.c
@@ -0,0 +1,27 @@
+/*
+ * arch/arm/mach-kirkwood/board-sheevaplug.c
+ *
+ * Marvell Sheevaplug Reference Board Init for drivers not converted to
+ * flattened device tree yet.
+ *
+ * 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/kernel.h>
+#include <linux/init.h>
+#include <linux/mv643xx_eth.h>
+#include "common.h"
+
+static struct mv643xx_eth_platform_data sheevaplug_ge00_data = {
+	.phy_addr	= MV643XX_ETH_PHY_ADDR(0),
+};
+
+void __init sheevaplug_dt_init(void)
+{
+	/*
+	 * Basic setup. Needs to be called early.
+	 */
+	kirkwood_ge00_init(&sheevaplug_ge00_data);
+}
diff --git a/arch/arm/mach-kirkwood/common.h b/arch/arm/mach-kirkwood/common.h
index 5ed7056..4944201 100644
--- a/arch/arm/mach-kirkwood/common.h
+++ b/arch/arm/mach-kirkwood/common.h
@@ -65,6 +65,11 @@ void guruplug_dt_init(void);
 #else
 static inline void guruplug_dt_init(void) {};
 #endif
+#ifdef CONFIG_MACH_SHEEVAPLUG_DT
+void sheevaplug_dt_init(void);
+#else
+static inline void sheevaplug_dt_init(void) {};
+#endif
 #ifdef CONFIG_MACH_TS219_DT
 void qnap_dt_ts219_init(void);
 #else
-- 
1.7.9.5



From cjb at laptop.org  Mon Apr 22 16:03:15 2013
From: cjb at laptop.org (Chris Ball)
Date: Mon, 22 Apr 2013 16:03:15 -0400
Subject: [PATCH 1/3] mmc: mvsdio: Support inverted CD and WP GPIO lines
In-Reply-To: <1366660500-26835-2-git-send-email-gmbnomis@gmail.com> (Simon
 Baatz's message of "Mon, 22 Apr 2013 21:54:58 +0200")
References: <1366660500-26835-1-git-send-email-gmbnomis@gmail.com>
 <1366660500-26835-2-git-send-email-gmbnomis@gmail.com>
Message-ID: <87wqrutjss.fsf@octavius.laptop.org>

Hi Simon,

On Mon, Apr 22 2013, Simon Baatz wrote:
> diff --git a/drivers/mmc/host/mvsdio.c b/drivers/mmc/host/mvsdio.c
> index 145cdaf..d444efd 100644
> --- a/drivers/mmc/host/mvsdio.c
> +++ b/drivers/mmc/host/mvsdio.c
> @@ -691,6 +691,7 @@ static int __init mvsd_probe(struct platform_device *pdev)
>  	struct resource *r;
>  	int ret, irq;
>  	int gpio_card_detect, gpio_write_protect;
> +	enum of_gpio_flags gpio_flags;
>  	struct pinctrl *pinctrl;
>  
>  	r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> @@ -731,8 +732,17 @@ static int __init mvsd_probe(struct platform_device *pdev)
>  		}
>  
>  		host->base_clock = clk_get_rate(host->clk) / 2;
> -		gpio_card_detect = of_get_named_gpio(np, "cd-gpios", 0);
> -		gpio_write_protect = of_get_named_gpio(np, "wp-gpios", 0);
> +		gpio_card_detect = of_get_named_gpio_flags(np, "cd-gpios", 0,
> +						     &gpio_flags);
> +		if (gpio_is_valid(gpio_card_detect) &&
> +		    !(gpio_flags & OF_GPIO_ACTIVE_LOW))
> +			mmc->caps2 |= MMC_CAP2_CD_ACTIVE_HIGH;
> +
> +		gpio_write_protect = of_get_named_gpio_flags(np, "wp-gpios", 0,
> +						       &gpio_flags);
> +		if (gpio_is_valid(gpio_write_protect) &&
> +		    !(gpio_flags & OF_GPIO_ACTIVE_LOW))
> +			mmc->caps2 |= MMC_CAP2_RO_ACTIVE_HIGH;
>  	} else {
>  		const struct mvsdio_platform_data *mvsd_data;
>  		mvsd_data = pdev->dev.platform_data;

The core function mmc_of_parse() (new in 3.9) will do all of this DT
parsing for you, and will also take care of the driver's later calls
to mmc_gpio_request_{cd,wp}().  Could you try using that function
instead, please?

Thanks,

- Chris.
-- 
Chris Ball   <cjb at laptop.org>   <http://printf.net/>
One Laptop Per Child


From andrew at lunn.ch  Mon Apr 22 16:37:23 2013
From: andrew at lunn.ch (Andrew Lunn)
Date: Mon, 22 Apr 2013 22:37:23 +0200
Subject: [PATCH 1/3] mmc: mvsdio: Support inverted CD and WP GPIO lines
In-Reply-To: <87wqrutjss.fsf@octavius.laptop.org>
References: <1366660500-26835-1-git-send-email-gmbnomis@gmail.com>
 <1366660500-26835-2-git-send-email-gmbnomis@gmail.com>
 <87wqrutjss.fsf@octavius.laptop.org>
Message-ID: <20130422203723.GI29947@lunn.ch>

On Mon, Apr 22, 2013 at 04:03:15PM -0400, Chris Ball wrote:
> Hi Simon,
> 
> On Mon, Apr 22 2013, Simon Baatz wrote:
> > diff --git a/drivers/mmc/host/mvsdio.c b/drivers/mmc/host/mvsdio.c
> > index 145cdaf..d444efd 100644
> > --- a/drivers/mmc/host/mvsdio.c
> > +++ b/drivers/mmc/host/mvsdio.c
> > @@ -691,6 +691,7 @@ static int __init mvsd_probe(struct platform_device *pdev)
> >  	struct resource *r;
> >  	int ret, irq;
> >  	int gpio_card_detect, gpio_write_protect;
> > +	enum of_gpio_flags gpio_flags;
> >  	struct pinctrl *pinctrl;
> >  
> >  	r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > @@ -731,8 +732,17 @@ static int __init mvsd_probe(struct platform_device *pdev)
> >  		}
> >  
> >  		host->base_clock = clk_get_rate(host->clk) / 2;
> > -		gpio_card_detect = of_get_named_gpio(np, "cd-gpios", 0);
> > -		gpio_write_protect = of_get_named_gpio(np, "wp-gpios", 0);
> > +		gpio_card_detect = of_get_named_gpio_flags(np, "cd-gpios", 0,
> > +						     &gpio_flags);
> > +		if (gpio_is_valid(gpio_card_detect) &&
> > +		    !(gpio_flags & OF_GPIO_ACTIVE_LOW))
> > +			mmc->caps2 |= MMC_CAP2_CD_ACTIVE_HIGH;
> > +
> > +		gpio_write_protect = of_get_named_gpio_flags(np, "wp-gpios", 0,
> > +						       &gpio_flags);
> > +		if (gpio_is_valid(gpio_write_protect) &&
> > +		    !(gpio_flags & OF_GPIO_ACTIVE_LOW))
> > +			mmc->caps2 |= MMC_CAP2_RO_ACTIVE_HIGH;
> >  	} else {
> >  		const struct mvsdio_platform_data *mvsd_data;
> >  		mvsd_data = pdev->dev.platform_data;
> 
> The core function mmc_of_parse() (new in 3.9) will do all of this DT
> parsing for you, and will also take care of the driver's later calls
> to mmc_gpio_request_{cd,wp}().  Could you try using that function
> instead, please?

Hi Chris, Simon

I have a vague recollection that Thomas Petazzoni already did this
conversion. Take a look in linux-next, or maybe Jason can point you at
a branch.

  Andrew


From robherring2 at gmail.com  Mon Apr 22 16:46:48 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Mon, 22 Apr 2013 15:46:48 -0500
Subject: [PATCH 0/4] ARM 64 bit sched_clock take #2
In-Reply-To: <51756CB6.5060607@linaro.org>
References: <51709FD7.8050408@gmail.com>
 <1366417746-24990-1-git-send-email-sboyd@codeaurora.org>
 <51756CB6.5060607@linaro.org>
Message-ID: <5175A1B8.1090202@gmail.com>

On 04/22/2013 12:00 PM, John Stultz wrote:
> On 04/19/2013 05:29 PM, Stephen Boyd wrote:
>> This is what I was thinking. I don't see why we can't move this to
>> generic code and have arm64 use it too. Those patches will follow once
>> I find an arm64
>> compiler.
> 
> I think moving this to generic code sounds like a good idea. You could
> probably also prototype and test the 64bit code with x86_64, using the
> TSC counter.

I agree this should all be common, but I'd like to see the common
version first. That is not going to make it for 3.10. For 3.10, the
immediate need is to fix suspend and initial time for the arch timer. I
think this should be fixed locally in arch timer code for 3.10. The
alternative is to revert linux-next commit 023796b9be3a77481cd5 (ARM:
arch_timer: use full 64-bit counter for sched_clock) which will cause
the arch timer to not be used as sched_clock if another higher frequency
sched_clock is registered.

Rob



From robherring2 at gmail.com  Mon Apr 22 16:59:47 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Mon, 22 Apr 2013 15:59:47 -0500
Subject: [PATCH 4/4] arm64: Add initial DTS for APM X-Gene Storm SOC and
 APM Mustang board
In-Reply-To: <1366442131-26094-5-git-send-email-vkale@apm.com>
References: <1366442131-26094-1-git-send-email-vkale@apm.com>
 <1366442131-26094-5-git-send-email-vkale@apm.com>
Message-ID: <5175A4C3.3090009@gmail.com>

On 04/20/2013 02:15 AM, Vinayak Kale wrote:
> This patch adds initial DTS files required for APM Mustang board.
> 
> Signed-off-by: Kumar Sankaran <ksankaran at apm.com>
> Signed-off-by: Loc Ho <lho at apm.com>
> Signed-off-by: Feng Kan <fkan at apm.com>
> ---
>  arch/arm64/boot/dts/Makefile    |    1 +
>  arch/arm64/boot/dts/mustang.dts |   28 +++++++++
>  arch/arm64/boot/dts/storm.dtsi  |  116 +++++++++++++++++++++++++++++++++++++++

Can you add "apm" to these filenames.

>  3 files changed, 145 insertions(+), 0 deletions(-)
>  create mode 100644 arch/arm64/boot/dts/mustang.dts
>  create mode 100644 arch/arm64/boot/dts/storm.dtsi
> 
> diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
> index 68457e9..faeab34 100644
> --- a/arch/arm64/boot/dts/Makefile
> +++ b/arch/arm64/boot/dts/Makefile
> @@ -1,4 +1,5 @@
>  dtb-$(CONFIG_ARCH_VEXPRESS) += rtsm_ve-aemv8a.dtb foundation-v8.dtb
> +dtb-$(CONFIG_ARCH_XGENE) += mustang.dtb
>  
>  targets += dtbs
>  targets += $(dtb-y)
> diff --git a/arch/arm64/boot/dts/mustang.dts b/arch/arm64/boot/dts/mustang.dts
> new file mode 100644
> index 0000000..a061c99
> --- /dev/null
> +++ b/arch/arm64/boot/dts/mustang.dts
> @@ -0,0 +1,28 @@
> +/*
> + * dts file for AppliedMicro (APM) Mustang Board
> + *
> + * Copyright (C) 2013, Applied Micro Circuits Corporation
> + *
> + * 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/ "storm.dtsi"
> +
> +/ {
> +	model = "mustang";
> +
> +	/* chosen */

Wow, that's a useful comment.

> +	chosen {
> +		linux,stdout-path = &serial0;

I don't think this is needed if you only have a single uart.

> +	};
> +
> +	memory {
> +		device_type = "memory";
> +		reg = < 0x1 0x00000000 0x0 0x80000000 >; /* Updated by bootloader */
> +	};
> +};
> diff --git a/arch/arm64/boot/dts/storm.dtsi b/arch/arm64/boot/dts/storm.dtsi
> new file mode 100644
> index 0000000..8cab5d1
> --- /dev/null
> +++ b/arch/arm64/boot/dts/storm.dtsi
> @@ -0,0 +1,116 @@
> +/*
> + * dts file for AppliedMicro (APM) X-Gene Storm SOC
> + *
> + * Copyright (C) 2013, Applied Micro Circuits Corporation
> + *
> + * 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.
> + */
> +
> +/ {
> +	compatible = "apm,xgene,storm", "apm,xgene";

Need to add documentation for the binding and the vendor prefix if it is
not already there.

> +	interrupt-parent = <&gic>;
> +	#address-cells = <2>;
> +	#size-cells = <2>;
> +
> +	cpus {
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
> +		cpu at 0 {
> +			device_type = "cpu";
> +			compatible = "arm,armv8";
> +			reg = <0x0 0x0000>;
> +			enable-method = "spin-table";
> +			cpu-release-addr = <0x1 0x0000fff8>;
> +		};
> +		cpu at 1 {
> +			device_type = "cpu";
> +			compatible = "arm,armv8";
> +			reg = <0x0 0x0001>;
> +			enable-method = "spin-table";
> +			cpu-release-addr = <0x1 0x0000fff8>;
> +		};
> +		cpu at 2 {
> +			device_type = "cpu";
> +			compatible = "arm,armv8";
> +			reg = <0x0 0x0100>;
> +			enable-method = "spin-table";
> +			cpu-release-addr = <0x1 0x0000fff8>;
> +		};
> +		cpu at 3 {
> +			device_type = "cpu";
> +			compatible = "arm,armv8";
> +			reg = <0x0 0x0101>;
> +			enable-method = "spin-table";
> +			cpu-release-addr = <0x1 0x0000fff8>;
> +		};
> +		cpu at 4 {
> +			device_type = "cpu";
> +			compatible = "arm,armv8";
> +			reg = <0x0 0x0200>;
> +			enable-method = "spin-table";
> +			cpu-release-addr = <0x1 0x0000fff8>;
> +		};
> +		cpu at 5 {
> +			device_type = "cpu";
> +			compatible = "arm,armv8";
> +			reg = <0x0 0x0201>;
> +			enable-method = "spin-table";
> +			cpu-release-addr = <0x1 0x0000fff8>;
> +		};
> +		cpu at 6 {
> +			device_type = "cpu";
> +			compatible = "arm,armv8";
> +			reg = <0x0 0x0300>;
> +			enable-method = "spin-table";
> +			cpu-release-addr = <0x1 0x0000fff8>;
> +		};
> +		cpu at 7 {
> +			device_type = "cpu";
> +			compatible = "arm,armv8";
> +			reg = <0x0 0x0301>;
> +			enable-method = "spin-table";
> +			cpu-release-addr = <0x1 0x0000fff8>;
> +		};
> +	};
> +
> +	gic: interrupt-controller at 78010000 {
> +		compatible = "arm,cortex-a15-gic", "arm,cortex-a9-gic";
> +		#interrupt-cells = <3>;
> +		interrupt-controller;
> +		reg = <0x0 0x78010000 0x0 0x1000>,	/* GIC Dist */
> +		      <0x0 0x78020000 0x0 0x1000>,	/* GIC CPU */
> +		      <0x0 0x78040000 0x0 0x2000>,	/* GIC VCPU Control */
> +		      <0x0 0x78060000 0x0 0x2000>;	/* GIC VCPU */
> +		interrupts = <1 9 0xf04>;	/* GIC Maintenence IRQ */
> +	};
> +
> +	timer {
> +		compatible = "arm,armv8-timer";
> +		interrupts = <1 0 0xff01>,	/* Secure Phys IRQ */
> +			     <1 13 0xff01>,	/* Non-secure Phys IRQ */
> +			     <1 14 0xff01>,	/* Virt IRQ */
> +			     <1 15 0xff01>;	/* Hyp IRQ */
> +		clock-frequency = <50000000>;
> +	};
> +
> +	soc {
> +		compatible = "simple-bus";
> +		#address-cells = <2>;
> +		#size-cells = <2>;
> +		ranges;
> +
> +		serial0: uart0 at 1c020000 {
> +			device_type = "serial";
> +			compatible = "ns16550";
> +			reg = <0 0x1c020000 0x0 0x1000>;
> +			reg-shift = <2>;
> +			clock-frequency = <10000000>; /* Updated by bootloader */
> +			interrupt-parent = <&gic>;
> +			interrupts = <0x0 0x4c 0x4>;
> +		};
> +	};
> +};
> 



From nerv at dawncrow.de  Mon Apr 22 17:07:35 2013
From: nerv at dawncrow.de (=?ISO-8859-1?Q?Andr=E9_Hentschel?=)
Date: Mon, 22 Apr 2013 23:07:35 +0200
Subject: [PATCHv2] arm: Preserve TPIDRURW on context switch
In-Reply-To: <20130422151836.GA15665@mudshark.cambridge.arm.com>
References: <517168BB.3070903@dawncrow.de>
 <20130422143616.GP14496@n2100.arm.linux.org.uk>
 <20130422151836.GA15665@mudshark.cambridge.arm.com>
Message-ID: <5175A697.3080308@dawncrow.de>

Am 22.04.2013 17:18, schrieb Will Deacon:
> On Mon, Apr 22, 2013 at 03:36:16PM +0100, Russell King - ARM Linux wrote:
>> On Fri, Apr 19, 2013 at 05:54:35PM +0200, Andr? Hentschel wrote:
>>> From: =?UTF-8?q?Andr=C3=A9=20Hentschel?= <nerv at dawncrow.de>
>>>
>>> There are more and more applications coming to WinRT, Wine could support them,
>>> but mostly they expect to have the thread environment block (TEB) in TPIDRURW.
>>> This register must be preserved per thread instead of being cleared.
>>>
>>> Signed-off-by: Andr? Hentschel <nerv at dawncrow.de>
>>
>> This actually makes things less efficient all round, because you
>> now use the value immediately after loading, which means it will cause
>> pipeline stalls, certainly on older CPUs.
>>
>> Could you please rework the patch to try avoiding soo many modifications
>> to the way things have been done here?
> 
> copy_thread also needs updating so that the *register* value for the parent
> is copied to the child, since the parent may have written the register
> after the last context-switch, meaning that tp_value is out-of-date.

Thank you both for reviewing.

I guess you mostly mean "ldr	r6, [r2, #TI_CPU_DOMAIN]".
I just thought about old CPUs and remembered again that we at Wine
need that patch only on v7 (and later). So is it ok to introduce a set_tls_v7
in tls.h and make use of CONFIG_CPU_V7 compile-time check in
the changed files and in the copy_thread function?
Do i need any further flag checks in copy_thread or can i use the
compile-time check to add unconditional code?



From arnd at arndb.de  Mon Apr 22 17:08:24 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 22 Apr 2013 23:08:24 +0200
Subject: [PATCH v2 1/3] ARM: dts: exynos4: Add node for PWM device
In-Reply-To: <1366036922-4103-2-git-send-email-t.figa@samsung.com>
References: <1366036922-4103-1-git-send-email-t.figa@samsung.com>
 <1366036922-4103-2-git-send-email-t.figa@samsung.com>
Message-ID: <201304222308.24226.arnd@arndb.de>

On Monday 15 April 2013, Tomasz Figa wrote:
> This patch adds device tree node for PWM block present on Exynos 4 SoCs.
> 
> Signed-off-by: Tomasz Figa <t.figa at samsung.com>
> ---
>  arch/arm/boot/dts/exynos4.dtsi | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
> index d73eaa1..d7058c1 100644
> --- a/arch/arm/boot/dts/exynos4.dtsi
> +++ b/arch/arm/boot/dts/exynos4.dtsi
> @@ -333,6 +333,14 @@
>                 status = "disabled";
>         };
>  
> +       pwm at 139D0000 {
> +               compatible = "samsung,exynos4210-pwm";
> +               reg = <0x139D0000 0x1000>;
> +               interrupts = <0 37 0>, <0 38 0>, <0 39 0>, <0 40 0>, <0 41 0>;
> +               #pwm-cells = <2>;
> +               status = "disabled";
> +       };

Acked-by: Arnd Bergmann <arnd at arndb.de>


From jason at lakedaemon.net  Mon Apr 22 17:09:49 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Mon, 22 Apr 2013 17:09:49 -0400
Subject: [PATCH 1/3] mmc: mvsdio: Support inverted CD and WP GPIO lines
In-Reply-To: <20130422203723.GI29947@lunn.ch>
References: <1366660500-26835-1-git-send-email-gmbnomis@gmail.com>
 <1366660500-26835-2-git-send-email-gmbnomis@gmail.com>
 <87wqrutjss.fsf@octavius.laptop.org>
 <20130422203723.GI29947@lunn.ch>
Message-ID: <20130422210949.GJ25724@titan.lakedaemon.net>

On Mon, Apr 22, 2013 at 10:37:23PM +0200, Andrew Lunn wrote:
> On Mon, Apr 22, 2013 at 04:03:15PM -0400, Chris Ball wrote:
> > Hi Simon,
> > 
> > On Mon, Apr 22 2013, Simon Baatz wrote:
> > > diff --git a/drivers/mmc/host/mvsdio.c b/drivers/mmc/host/mvsdio.c
> > > index 145cdaf..d444efd 100644
> > > --- a/drivers/mmc/host/mvsdio.c
> > > +++ b/drivers/mmc/host/mvsdio.c
> > > @@ -691,6 +691,7 @@ static int __init mvsd_probe(struct platform_device *pdev)
> > >  	struct resource *r;
> > >  	int ret, irq;
> > >  	int gpio_card_detect, gpio_write_protect;
> > > +	enum of_gpio_flags gpio_flags;
> > >  	struct pinctrl *pinctrl;
> > >  
> > >  	r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > > @@ -731,8 +732,17 @@ static int __init mvsd_probe(struct platform_device *pdev)
> > >  		}
> > >  
> > >  		host->base_clock = clk_get_rate(host->clk) / 2;
> > > -		gpio_card_detect = of_get_named_gpio(np, "cd-gpios", 0);
> > > -		gpio_write_protect = of_get_named_gpio(np, "wp-gpios", 0);
> > > +		gpio_card_detect = of_get_named_gpio_flags(np, "cd-gpios", 0,
> > > +						     &gpio_flags);
> > > +		if (gpio_is_valid(gpio_card_detect) &&
> > > +		    !(gpio_flags & OF_GPIO_ACTIVE_LOW))
> > > +			mmc->caps2 |= MMC_CAP2_CD_ACTIVE_HIGH;
> > > +
> > > +		gpio_write_protect = of_get_named_gpio_flags(np, "wp-gpios", 0,
> > > +						       &gpio_flags);
> > > +		if (gpio_is_valid(gpio_write_protect) &&
> > > +		    !(gpio_flags & OF_GPIO_ACTIVE_LOW))
> > > +			mmc->caps2 |= MMC_CAP2_RO_ACTIVE_HIGH;
> > >  	} else {
> > >  		const struct mvsdio_platform_data *mvsd_data;
> > >  		mvsd_data = pdev->dev.platform_data;
> > 
> > The core function mmc_of_parse() (new in 3.9) will do all of this DT
> > parsing for you, and will also take care of the driver's later calls
> > to mmc_gpio_request_{cd,wp}().  Could you try using that function
> > instead, please?
> 
> Hi Chris, Simon
> 
> I have a vague recollection that Thomas Petazzoni already did this
> conversion. Take a look in linux-next, or maybe Jason can point you at
> a branch.

Andrew,

Thomas did a board conversion here (slated for v3.11 in /pcie branch):

  cd2bde5 arm: kirkwood: convert db-88f6281 to the Device Tree

And Sebastian did some mvsdio WP and CD pin work here:

  0d0644eARM: Kirkwood: fix unused mvsdio gpio pins

Nothing else really jumps out though.  Where either of these what you
were thinking of?

thx,

Jason.


From arnd at arndb.de  Mon Apr 22 17:10:34 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 22 Apr 2013 23:10:34 +0200
Subject: [PATCH v2 2/3] ARM: EXYNOS: Fix support of Exynos4210 rev0 SoC
In-Reply-To: <1366036922-4103-3-git-send-email-t.figa@samsung.com>
References: <1366036922-4103-1-git-send-email-t.figa@samsung.com>
 <1366036922-4103-3-git-send-email-t.figa@samsung.com>
Message-ID: <201304222310.34775.arnd@arndb.de>

On Monday 15 April 2013, Tomasz Figa wrote:
> This patch extends exynos_init_time() function to handle Exynos4210 rev0
> SoC, which differs in availability of system timers and needs different
> clocksource initialization.
> 
> This makes it possible to use exynos_init_time() function as init_time
> callback for all Exynos-based boards, including Universal_C210, which
> originally had to use samsung_timer_init().
> 
> Signed-off-by: Tomasz Figa <t.figa at samsung.com>

Acked-by: Arnd Bergmann <arnd at arndb.de>

Note that it would be helpful to mention here that this is required for
the calling samsung_timer_init from the exynos4-dt.c file.

	Arnd


From arnd at arndb.de  Mon Apr 22 17:11:06 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 22 Apr 2013 23:11:06 +0200
Subject: [PATCH v2 3/3] ARM: dts: exynos4210: Add basic dts file for
 universal_c210 board
In-Reply-To: <1366036922-4103-4-git-send-email-t.figa@samsung.com>
References: <1366036922-4103-1-git-send-email-t.figa@samsung.com>
 <1366036922-4103-4-git-send-email-t.figa@samsung.com>
Message-ID: <201304222311.06845.arnd@arndb.de>

On Monday 15 April 2013, Tomasz Figa wrote:
> 
> This patch adds basic device tree sources for Universal C210 board.
> 
> Currently support includes:
> - eMMC
> - serial
> - max8952 and max8998 voltage regulators.
> - gpio-keys
> 
> More support will be added in further patches.
> 
> Signed-off-by: Tomasz Figa <t.figa at samsung.com>

Acked-by: Arnd Bergmann <arnd at arndb.de>


From marex at denx.de  Mon Apr 22 17:19:31 2013
From: marex at denx.de (Marek Vasut)
Date: Mon, 22 Apr 2013 23:19:31 +0200
Subject: [PATCH V2] video: imx: Add BGR666 support for parallel display
Message-ID: <1366665571-8897-1-git-send-email-marex@denx.de>

Support the BGR666 format on the IPUv3 parallel display.

Signed-off-by: Marek Vasut <marex at denx.de>
Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
Cc: Philipp Zabel <p.zabel at pengutronix.de>
Cc: Sascha Hauer <s.hauer at pengutronix.de>
Cc: Bill Pemberton <wfp5p at virginia.edu>
---
 .../devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt       |    2 +-
 drivers/staging/imx-drm/ipu-v3/ipu-dc.c                       |    9 +++++++++
 drivers/staging/imx-drm/parallel-display.c                    |    2 ++
 3 files changed, 12 insertions(+), 1 deletion(-)

V2: Update documentation

diff --git a/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt b/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
index f769857..b876d49 100644
--- a/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
+++ b/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
@@ -29,7 +29,7 @@ Required properties:
 - crtc: the crtc this display is connected to, see below
 Optional properties:
 - interface_pix_fmt: How this display is connected to the
-  crtc. Currently supported types: "rgb24", "rgb565"
+  crtc. Currently supported types: "rgb24", "rgb565", "bgr666"
 - edid: verbatim EDID data block describing attached display.
 - ddc: phandle describing the i2c bus handling the display data
   channel
diff --git a/drivers/staging/imx-drm/ipu-v3/ipu-dc.c b/drivers/staging/imx-drm/ipu-v3/ipu-dc.c
index 1cb0631..59f03f9 100644
--- a/drivers/staging/imx-drm/ipu-v3/ipu-dc.c
+++ b/drivers/staging/imx-drm/ipu-v3/ipu-dc.c
@@ -90,6 +90,7 @@ enum ipu_dc_map {
 	IPU_DC_MAP_RGB24,
 	IPU_DC_MAP_RGB565,
 	IPU_DC_MAP_GBR24, /* TVEv2 */
+	IPU_DC_MAP_BGR666,
 };
 
 struct ipu_dc {
@@ -149,6 +150,8 @@ static int ipu_pixfmt_to_map(u32 fmt)
 		return IPU_DC_MAP_RGB565;
 	case IPU_PIX_FMT_GBR24:
 		return IPU_DC_MAP_GBR24;
+	case V4L2_PIX_FMT_BGR666:
+		return IPU_DC_MAP_BGR666;
 	default:
 		return -EINVAL;
 	}
@@ -385,6 +388,12 @@ int ipu_dc_init(struct ipu_soc *ipu, struct device *dev,
 	ipu_dc_map_config(priv, IPU_DC_MAP_GBR24, 1, 7, 0xff); /* blue */
 	ipu_dc_map_config(priv, IPU_DC_MAP_GBR24, 0, 23, 0xff); /* red */
 
+	/* bgr666 */
+	ipu_dc_map_clear(priv, IPU_DC_MAP_BGR666);
+	ipu_dc_map_config(priv, IPU_DC_MAP_BGR666, 0, 5, 0xfc); /* blue */
+	ipu_dc_map_config(priv, IPU_DC_MAP_BGR666, 1, 11, 0xfc); /* green */
+	ipu_dc_map_config(priv, IPU_DC_MAP_BGR666, 2, 17, 0xfc); /* red */
+
 	return 0;
 }
 
diff --git a/drivers/staging/imx-drm/parallel-display.c b/drivers/staging/imx-drm/parallel-display.c
index 2a25202..e7fba62 100644
--- a/drivers/staging/imx-drm/parallel-display.c
+++ b/drivers/staging/imx-drm/parallel-display.c
@@ -230,6 +230,8 @@ static int imx_pd_probe(struct platform_device *pdev)
 			imxpd->interface_pix_fmt = V4L2_PIX_FMT_RGB24;
 		else if (!strcmp(fmt, "rgb565"))
 			imxpd->interface_pix_fmt = V4L2_PIX_FMT_RGB565;
+		else if (!strcmp(fmt, "bgr666"))
+			imxpd->interface_pix_fmt = V4L2_PIX_FMT_BGR666;
 	}
 
 	imxpd->dev = &pdev->dev;
-- 
1.7.10.4



From marex at denx.de  Mon Apr 22 17:23:47 2013
From: marex at denx.de (Marek Vasut)
Date: Mon, 22 Apr 2013 23:23:47 +0200
Subject: [PATCH V2] ARM: mx5: Add support for DENX M53EVK
Message-ID: <1366665827-8949-1-git-send-email-marex@denx.de>

This patch adds support for the DENX M53EVK board. The board currently supports
NAND, Ethernet, UART, CAN, I2C.

Signed-off-by: Marek Vasut <marex at denx.de>
Cc: Fabio Estevam <fabio.estevam at freescale.com>
Cc: Shawn Guo <shawn.guo at linaro.org>
---
 arch/arm/boot/dts/Makefile         |    1 +
 arch/arm/boot/dts/imx53-m53evk.dts |  259 ++++++++++++++++++++++++++++++++++++
 2 files changed, 260 insertions(+)
 create mode 100644 arch/arm/boot/dts/imx53-m53evk.dts

V2: - Rebase on top of Shawn's patch:
      "[PATCH] ARM: imx: move imx53-qsb audio codec clk lookup into DT"
    - Use BGR666 format on LCD, this makes it depend on:
      "[PATCH V2] video: imx: Add BGR666 support for parallel display"
    - Remove the first LCD as it's not populated
    - Reorder the DT nodes in alphabetical order
    - Configure PWM pinmux properly
    - Pass IRQ GPIO to STMPE-TS driver using "interrupt" and
      "interrupt-parent" DT properties

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 4fd1f62..1fbec6b 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -107,6 +107,7 @@ dtb-$(CONFIG_ARCH_MXC) += \
 	imx51-babbage.dtb \
 	imx53-ard.dtb \
 	imx53-evk.dtb \
+	imx53-m53evk.dtb \
 	imx53-mba53.dtb \
 	imx53-qsb.dtb \
 	imx53-smd.dtb \
diff --git a/arch/arm/boot/dts/imx53-m53evk.dts b/arch/arm/boot/dts/imx53-m53evk.dts
new file mode 100644
index 0000000..7d304d0
--- /dev/null
+++ b/arch/arm/boot/dts/imx53-m53evk.dts
@@ -0,0 +1,259 @@
+/*
+ * Copyright (C) 2013 Marek Vasut <marex at denx.de>
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+/dts-v1/;
+#include "imx53.dtsi"
+
+/ {
+	model = "DENX M53EVK";
+	compatible = "denx,imx53-m53evk", "fsl,imx53";
+
+	memory {
+		reg = <0x70000000 0x20000000>;
+	};
+
+	soc {
+		display at di1 {
+			compatible = "fsl,imx-parallel-display";
+			crtcs = <&ipu 1>;
+			interface-pix-fmt = "bgr666";
+			pinctrl-names = "default";
+			pinctrl-0 = <&pinctrl_ipu_disp2_1>;
+
+			display-timings {
+				800x480p60 {
+					native-mode;
+					clock-frequency = <31500000>;
+					hactive = <800>;
+					vactive = <480>;
+					hfront-porch = <40>;
+					hback-porch = <88>;
+					hsync-len = <128>;
+					vback-porch = <33>;
+					vfront-porch = <9>;
+					vsync-len = <3>;
+					vsync-active = <1>;
+				};
+			};
+		};
+	};
+
+	backlight {
+		compatible = "pwm-backlight";
+		pwms = <&pwm1 0 3000>;
+		brightness-levels = <0 4 8 16 32 64 128 255>;
+		default-brightness-level = <6>;
+	};
+
+	leds {
+		compatible = "gpio-leds";
+		pinctrl-names = "default";
+		pinctrl-0 = <&led_pin_gpio>;
+
+		user1 {
+			label = "user1";
+			gpios = <&gpio2 8 0>;
+			linux,default-trigger = "heartbeat";
+		};
+
+		user2 {
+			label = "user2";
+			gpios = <&gpio2 9 0>;
+			linux,default-trigger = "heartbeat";
+		};
+	};
+
+	regulators {
+		compatible = "simple-bus";
+
+		reg_3p2v: 3p2v {
+			compatible = "regulator-fixed";
+			regulator-name = "3P2V";
+			regulator-min-microvolt = <3200000>;
+			regulator-max-microvolt = <3200000>;
+			regulator-always-on;
+		};
+	};
+
+	sound {
+		compatible = "fsl,imx53-m53evk-sgtl5000",
+			     "fsl,imx-audio-sgtl5000";
+		model = "imx53-m53evk-sgtl5000";
+		ssi-controller = <&ssi2>;
+		audio-codec = <&sgtl5000>;
+		audio-routing =
+			"MIC_IN", "Mic Jack",
+			"Mic Jack", "Mic Bias",
+			"LINE_IN", "Line In Jack",
+			"Headphone Jack", "HP_OUT",
+			"Ext Spk", "LINE_OUT";
+		mux-int-port = <2>;
+		mux-ext-port = <4>;
+	};
+};
+
+&audmux {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_audmux_2>;
+	status = "okay";
+};
+
+&can1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_can1_3>;
+	status = "okay";
+};
+
+&can2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_can2_1>;
+	status = "okay";
+};
+
+&esdhc1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_esdhc1_1>;
+	cd-gpios = <&gpio1 1 0>;
+	wp-gpios = <&gpio1 9 0>;
+	status = "okay";
+};
+
+&fec {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_fec_1>;
+	phy-mode = "rmii";
+	status = "okay";
+};
+
+&i2c1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_i2c1_2>;
+	status = "okay";
+
+	sgtl5000: codec at 0a {
+		compatible = "fsl,sgtl5000";
+		reg = <0x0a>;
+		VDDA-supply = <&reg_3p2v>;
+		VDDIO-supply = <&reg_3p2v>;
+		clocks = <&clks 150>;
+	};
+};
+
+&i2c2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_i2c2_2>;
+	clock-frequency = <400000>;
+	status = "okay";
+
+	stmpe610 at 41 {
+		compatible = "st,stmpe610";
+		#address-cells = <1>;
+		#size-cells = <0>;
+		reg = <0x41>;
+		id = <0>;
+		blocks = <0x5>;
+		interrupts = <6 0x0>;
+		interrupt-parent = <&gpio7>;
+		irq-trigger = <0x1>;
+
+		stmpe_touchscreen {
+			compatible = "stmpe,ts";
+			reg = <0>;
+			ts,sample-time = <4>;
+			ts,mod-12b = <1>;
+			ts,ref-sel = <0>;
+			ts,adc-freq = <1>;
+			ts,ave-ctrl = <3>;
+			ts,touch-det-delay = <3>;
+			ts,settling = <4>;
+			ts,fraction-z = <7>;
+			ts,i-drive = <1>;
+		};
+	};
+
+	eeprom: eeprom at 50 {
+		compatible = "atmel,24c128";
+		reg = <0x50>;
+		pagesize = <32>;
+	};
+
+	rtc: rtc at 68 {
+		compatible = "stm,m41t62";
+		reg = <0x68>;
+	};
+};
+
+&i2c3 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_i2c3_1>;
+	status = "okay";
+};
+
+&iomuxc {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_hog>;
+
+	hog {
+		pinctrl_hog: hoggrp {
+			fsl,pins = <
+				MX53_PAD_GPIO_0__CCM_SSI_EXT1_CLK	0x80000000
+				MX53_PAD_EIM_EB3__GPIO2_31		0x80000000
+				MX53_PAD_PATA_DA_0__GPIO7_6		0x80000000
+				MX53_PAD_DISP0_DAT8__PWM1_PWMO		0x5
+
+			>;
+		};
+
+		led_pin_gpio: led_gpio at 0 {
+			fsl,pins = <
+				MX53_PAD_PATA_DATA8__GPIO2_8		0x80000000
+				MX53_PAD_PATA_DATA9__GPIO2_9		0x80000000
+			>;
+		};
+	};
+};
+
+&nfc {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_nand_1>;
+	nand-bus-width = <8>;
+	nand-ecc-mode = "hw";
+	status = "okay";
+};
+
+&pwm1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_pwm1_1>;
+	status = "okay";
+};
+
+&ssi2 {
+	fsl,mode = "i2s-slave";
+	status = "okay";
+};
+
+&uart1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_uart1_2>;
+	status = "okay";
+};
+
+&uart2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_uart2_1>;
+	status = "okay";
+};
+
+&uart3 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_uart3_1>;
+	status = "okay";
+};
-- 
1.7.10.4



From marex at denx.de  Mon Apr 22 17:28:30 2013
From: marex at denx.de (Marek Vasut)
Date: Mon, 22 Apr 2013 23:28:30 +0200
Subject: [RFC][PATCH] video: imx: Select VIDEOMODE_HELPERS
Message-ID: <1366666110-9585-1-git-send-email-marex@denx.de>

Without this, I get the following problem when building kernel:

drivers/built-in.o: In function `imx_pd_connector_get_modes':
/linux-2.6/drivers/staging/imx-drm/parallel-display.c:78: undefined reference to `of_get_drm_display_mode'
make: *** [vmlinux] Error 1

NOTE: I think this patch is almost absolutely not correct.

Signed-off-by: Marek Vasut <marex at denx.de>
Cc: Sascha Hauer <s.hauer at pengutronix.de>
Cc: Philipp Zabel <p.zabel at pengutronix.de>
Cc: Fabio Estevam <fabio.estevam at freescale.com>
---
 drivers/staging/imx-drm/Kconfig |    1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/imx-drm/Kconfig b/drivers/staging/imx-drm/Kconfig
index 8c9e403..5ad9165 100644
--- a/drivers/staging/imx-drm/Kconfig
+++ b/drivers/staging/imx-drm/Kconfig
@@ -1,6 +1,7 @@
 config DRM_IMX
 	tristate "DRM Support for Freescale i.MX"
 	select DRM_KMS_HELPER
+	select VIDEOMODE_HELPERS
 	select DRM_GEM_CMA_HELPER
 	select DRM_KMS_CMA_HELPER
 	depends on DRM && (ARCH_MXC || ARCH_MULTIPLATFORM)
-- 
1.7.10.4



From nicolas.pitre at linaro.org  Mon Apr 22 17:29:32 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Mon, 22 Apr 2013 17:29:32 -0400 (EDT)
Subject: ARM: 7684/1: errata: Workaround for Cortex-A15 erratum 798181
 (TLBI/DSB operations)
Message-ID: <alpine.LFD.2.03.1304221641340.17375@syhkavp.arg>

Hi Catalin,

I notice that commit 93dc68876b60 ( "ARM: 7684/1: errata: Workaround for 
Cortex-A15 erratum 798181 (TLBI/DSB operations)") is in mainline, but it 
is causing a flood of warnings with CONFIG_DEBUG_PREEMPT active, making 
the system unusable. Unfortunately, I failed to find it in the list 
archives, so I couldn't reply to the original patch.

The kernel spits out this on every fork():

BUG: using smp_processor_id() in preemptible [00000000] code: bash/1419
caller is broadcast_tlb_mm_a15_erratum+0x94/0xfc
[<c0014640>] (unwind_backtrace+0x0/0xf8) from [<c02074ec>] (debug_smp_processor_id+0xc4/0xe8)
[<c02074ec>] (debug_smp_processor_id+0xc4/0xe8) from [<c0013a3c>] (broadcast_tlb_mm_a15_erratum+0x94/0xfc)
[<c0013a3c>] (broadcast_tlb_mm_a15_erratum+0x94/0xfc) from [<c0020f28>] (dup_mm+0x30c/0x41c)
[<c0020f28>] (dup_mm+0x30c/0x41c) from [<c00217a4>] (copy_process.part.56+0x724/0xe20)
[<c00217a4>] (copy_process.part.56+0x724/0xe20) from [<c0021f54>] (do_fork+0x90/0x320)
[<c0021f54>] (do_fork+0x90/0x320) from [<c000e240>] (ret_fast_syscall+0x0/0x30)
BUG: using smp_processor_id() in preemptible [00000000] code: bash/1419
caller is broadcast_tlb_mm_a15_erratum+0x94/0xfc
[<c0014640>] (unwind_backtrace+0x0/0xf8) from [<c02074ec>] (debug_smp_processor_id+0xc4/0xe8)
[<c02074ec>] (debug_smp_processor_id+0xc4/0xe8) from [<c0013a3c>] (broadcast_tlb_mm_a15_erratum+0x94/0xfc)
[<c0013a3c>] (broadcast_tlb_mm_a15_erratum+0x94/0xfc) from [<c0020f28>] (dup_mm+0x30c/0x41c)
[<c0020f28>] (dup_mm+0x30c/0x41c) from [<c00217a4>] (copy_process.part.56+0x724/0xe20)
[<c00217a4>] (copy_process.part.56+0x724/0xe20) from [<c0021f54>] (do_fork+0x90/0x320)
[<c0021f54>] (do_fork+0x90/0x320) from [<c000e240>] (ret_fast_syscall+0x0/0x30)
BUG: using smp_processor_id() in preemptible [00000000] code: bash/1419
caller is smp_call_function_many+0x18/0x2c0
[<c0014640>] (unwind_backtrace+0x0/0xf8) from [<c02074ec>] (debug_smp_processor_id+0xc4/0xe8)
[<c02074ec>] (debug_smp_processor_id+0xc4/0xe8) from [<c006b3d4>] (smp_call_function_many+0x18/0x2c0)
[<c006b3d4>] (smp_call_function_many+0x18/0x2c0) from [<c0013a8c>] (broadcast_tlb_mm_a15_erratum+0xe4/0xfc)
[<c0013a8c>] (broadcast_tlb_mm_a15_erratum+0xe4/0xfc) from [<c0020f28>] (dup_mm+0x30c/0x41c)
[<c0020f28>] (dup_mm+0x30c/0x41c) from [<c00217a4>] (copy_process.part.56+0x724/0xe20)
[<c00217a4>] (copy_process.part.56+0x724/0xe20) from [<c0021f54>] (do_fork+0x90/0x320)
[<c0021f54>] (do_fork+0x90/0x320) from [<c000e240>] (ret_fast_syscall+0x0/0x30)


Nicolas


From andrew at lunn.ch  Mon Apr 22 17:45:43 2013
From: andrew at lunn.ch (Andrew Lunn)
Date: Mon, 22 Apr 2013 23:45:43 +0200
Subject: [PATCH 1/3] mmc: mvsdio: Support inverted CD and WP GPIO lines
In-Reply-To: <20130422210949.GJ25724@titan.lakedaemon.net>
References: <1366660500-26835-1-git-send-email-gmbnomis@gmail.com>
 <1366660500-26835-2-git-send-email-gmbnomis@gmail.com>
 <87wqrutjss.fsf@octavius.laptop.org>
 <20130422203723.GI29947@lunn.ch>
 <20130422210949.GJ25724@titan.lakedaemon.net>
Message-ID: <20130422214543.GJ29947@lunn.ch>

> > > The core function mmc_of_parse() (new in 3.9) will do all of this DT
> > > parsing for you, and will also take care of the driver's later calls
> > > to mmc_gpio_request_{cd,wp}().  Could you try using that function
> > > instead, please?
> > 
> > Hi Chris, Simon
> > 
> > I have a vague recollection that Thomas Petazzoni already did this
> > conversion. Take a look in linux-next, or maybe Jason can point you at
> > a branch.
> 
> Andrew,
> 
> Thomas did a board conversion here (slated for v3.11 in /pcie branch):
> 
>   cd2bde5 arm: kirkwood: convert db-88f6281 to the Device Tree
> 
> And Sebastian did some mvsdio WP and CD pin work here:
> 
>   0d0644eARM: Kirkwood: fix unused mvsdio gpio pins
> 
> Nothing else really jumps out though.  Where either of these what you
> were thinking of?

http://lists.infradead.org/pipermail/linux-arm-kernel/2012-December/138514.html

and

http://lists.infradead.org/pipermail/linux-arm-kernel/2012-December/138513.html

	Andrew


From cjb at laptop.org  Mon Apr 22 17:50:17 2013
From: cjb at laptop.org (Chris Ball)
Date: Mon, 22 Apr 2013 17:50:17 -0400
Subject: [PATCH 1/3] mmc: mvsdio: Support inverted CD and WP GPIO lines
In-Reply-To: <20130422214543.GJ29947@lunn.ch> (Andrew Lunn's message of "Mon, 
 22 Apr 2013 23:45:43 +0200")
References: <1366660500-26835-1-git-send-email-gmbnomis@gmail.com>
 <1366660500-26835-2-git-send-email-gmbnomis@gmail.com>
 <87wqrutjss.fsf@octavius.laptop.org> <20130422203723.GI29947@lunn.ch>
 <20130422210949.GJ25724@titan.lakedaemon.net>
 <20130422214543.GJ29947@lunn.ch>
Message-ID: <87sj2iteue.fsf@octavius.laptop.org>

Hi,

On Mon, Apr 22 2013, Andrew Lunn wrote:
>> Nothing else really jumps out though.  Where either of these what you
>> were thinking of?
>
> http://lists.infradead.org/pipermail/linux-arm-kernel/2012-December/138514.html
>
> and
>
> http://lists.infradead.org/pipermail/linux-arm-kernel/2012-December/138513.html

These patches move mvsdio to slot-gpio, which is a prerequisite for
using the shared mmc_of_parse(), but they don't go all the way to
using mmc_of_parse().

(Which makes sense; mmc_of_parse() was merged to mmc-next in February,
so it wasn't available for this patchset in December.)

Thanks,

- Chris.
-- 
Chris Ball   <cjb at laptop.org>   <http://printf.net/>
One Laptop Per Child


From mturquette at linaro.org  Mon Apr 22 17:54:32 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Mon, 22 Apr 2013 14:54:32 -0700
Subject: [PATCH 4/4] ARM: nomadik: register clocksource from device tree
In-Reply-To: <1366466983-16151-1-git-send-email-linus.walleij@linaro.org>
References: <1366466983-16151-1-git-send-email-linus.walleij@linaro.org>
Message-ID: <20130422215432.17530.87226@quantum>

Quoting Linus Walleij (2013-04-20 07:09:43)
> This switches the Nomadik platform to also registering its
> clocksource from the device tree, removing unused support
> code as we go along.
> 
> Signed-off-by: Linus Walleij <linus.walleij at linaro.org>

For the clk-nomadik.c part:

Acked-by: Mike Turquette <mturquette at linaro.org>

> ---
>  arch/arm/boot/dts/ste-nomadik-stn8815.dtsi | 11 ++++++++---
>  arch/arm/mach-nomadik/Kconfig              |  1 +
>  arch/arm/mach-nomadik/cpu-8815.c           |  6 +++---
>  drivers/clk/clk-nomadik.c                  | 15 ---------------
>  4 files changed, 12 insertions(+), 21 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/ste-nomadik-stn8815.dtsi b/arch/arm/boot/dts/ste-nomadik-stn8815.dtsi
> index f0df948..51a33e0 100644
> --- a/arch/arm/boot/dts/ste-nomadik-stn8815.dtsi
> +++ b/arch/arm/boot/dts/ste-nomadik-stn8815.dtsi
> @@ -21,18 +21,23 @@
>                 cache-level = <2>;
>         };
>  
> -       mtu0 {
> +       mtu0: mtu at 101e2000 {
>                 /* Nomadik system timer */
> +               compatible = "st,nomadik-mtu";
>                 reg = <0x101e2000 0x1000>;
>                 interrupt-parent = <&vica>;
>                 interrupts = <4>;
> +               clocks = <&timclk>, <&pclk>;
> +               clock-names = "timclk", "apb_pclk";
>         };
>  
> -       mtu1 {
> +       mtu1: mtu at 101e3000 {
>                 /* Secondary timer */
>                 reg = <0x101e3000 0x1000>;
>                 interrupt-parent = <&vica>;
>                 interrupts = <5>;
> +               clocks = <&timclk>, <&pclk>;
> +               clock-names = "timclk", "apb_pclk";
>         };
>  
>         gpio0: gpio at 101e4000 {
> @@ -101,7 +106,7 @@
>                         pclk: pclk at 0 {
>                                 #clock-cells = <0>;
>                                 compatible = "fixed-clock";
> -                               clock-frequency = <2400000>;
> +                               clock-frequency = <0>;
>                         };
>                         /*
>                          * The 2.4 MHz TIMCLK reference clock is active at
> diff --git a/arch/arm/mach-nomadik/Kconfig b/arch/arm/mach-nomadik/Kconfig
> index 8c1ccd4..4eafec3 100644
> --- a/arch/arm/mach-nomadik/Kconfig
> +++ b/arch/arm/mach-nomadik/Kconfig
> @@ -6,6 +6,7 @@ config ARCH_NOMADIK
>         select ARM_VIC
>         select CLKSRC_NOMADIK_MTU
>         select CLKSRC_NOMADIK_MTU_SCHED_CLOCK
> +       select CLKSRC_OF
>         select COMMON_CLK
>         select CPU_ARM926T
>         select GENERIC_CLOCKEVENTS
> diff --git a/arch/arm/mach-nomadik/cpu-8815.c b/arch/arm/mach-nomadik/cpu-8815.c
> index 0e2c5e0..e73a71f7 100644
> --- a/arch/arm/mach-nomadik/cpu-8815.c
> +++ b/arch/arm/mach-nomadik/cpu-8815.c
> @@ -29,7 +29,7 @@
>  #include <linux/platform_data/clk-nomadik.h>
>  #include <linux/platform_data/pinctrl-nomadik.h>
>  #include <linux/pinctrl/machine.h>
> -#include <linux/platform_data/clocksource-nomadik-mtu.h>
> +#include <linux/clocksource.h>
>  #include <linux/of_irq.h>
>  #include <linux/of_gpio.h>
>  #include <linux/of_address.h>
> @@ -172,7 +172,7 @@ static void __init cpu8815_timer_init_of(void)
>         /* We need this to be up now */
>         nomadik_clk_init();
>  
> -       mtu = of_find_node_by_path("/mtu0");
> +       mtu = of_find_node_by_path("/mtu at 101e2000");
>         if (!mtu)
>                 return;
>         base = of_iomap(mtu, 0);
> @@ -188,7 +188,7 @@ static void __init cpu8815_timer_init_of(void)
>         src_cr |= SRC_CR_INIT_VAL;
>         writel(src_cr, base);
>  
> -       nmdk_timer_init(base, irq);
> +       clocksource_of_init();
>  }
>  
>  static struct fsmc_nand_timings cpu8815_nand_timings = {
> diff --git a/drivers/clk/clk-nomadik.c b/drivers/clk/clk-nomadik.c
> index 19f197c..4a1ab27 100644
> --- a/drivers/clk/clk-nomadik.c
> +++ b/drivers/clk/clk-nomadik.c
> @@ -17,20 +17,5 @@ static const __initconst struct of_device_id cpu8815_clk_match[] = {
>  
>  void __init nomadik_clk_init(void)
>  {
> -       struct clk *clk;
> -
> -       clk = clk_register_fixed_rate(NULL, "apb_pclk", NULL, CLK_IS_ROOT, 0);
> -       clk_register_clkdev(clk, "apb_pclk", NULL);
> -
> -       /*
> -        * The 2.4 MHz TIMCLK reference clock is active at boot time, this is
> -        * actually the MXTALCLK @19.2 MHz divided by 8. This clock is used
> -        * by the timers and watchdog. See page 105 ff.
> -        */
> -       clk = clk_register_fixed_rate(NULL, "TIMCLK", NULL, CLK_IS_ROOT,
> -                                     2400000);
> -       clk_register_clkdev(clk, NULL, "mtu0");
> -       clk_register_clkdev(clk, NULL, "mtu1");
> -
>         of_clk_init(cpu8815_clk_match);
>  }
> -- 
> 1.8.1.4
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From mturquette at linaro.org  Mon Apr 22 18:01:16 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Mon, 22 Apr 2013 15:01:16 -0700
Subject: [PATCH 3/4] ARM: nomadik: convert all clocks except timer to dt
In-Reply-To: <1366466974-16115-1-git-send-email-linus.walleij@linaro.org>
References: <1366466974-16115-1-git-send-email-linus.walleij@linaro.org>
Message-ID: <20130422220116.17530.44985@quantum>

Quoting Linus Walleij (2013-04-20 07:09:34)
> This moves all Nomadik clocks except the one used for the
> timer/clocksource over to the device tree.
> 
> Signed-off-by: Linus Walleij <linus.walleij at linaro.org>

For the clk-nomadik.c part:

Acked-by: Mike Turquette <mturquette at linaro.org>

> ---
>  .../devicetree/bindings/arm/ste-nomadik.txt        |  5 ++
>  arch/arm/boot/dts/ste-nomadik-stn8815.dtsi         | 54 ++++++++++++++++++++++
>  arch/arm/mach-nomadik/cpu-8815.c                   | 20 +-------
>  drivers/clk/clk-nomadik.c                          | 26 +++--------
>  4 files changed, 68 insertions(+), 37 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/arm/ste-nomadik.txt b/Documentation/devicetree/bindings/arm/ste-nomadik.txt
> index 19bca04..6256ec3 100644
> --- a/Documentation/devicetree/bindings/arm/ste-nomadik.txt
> +++ b/Documentation/devicetree/bindings/arm/ste-nomadik.txt
> @@ -3,6 +3,11 @@ ST-Ericsson Nomadik Device Tree Bindings
>  For various board the "board" node may contain specific properties
>  that pertain to this particular board, such as board-specific GPIOs.
>  
> +Required root node property: src
> +- Nomadik System and reset controller used for basic chip control, clock
> +  and reset line control.
> +- compatible: must be "stericsson,nomadik,src"
> +
>  Boards with the Nomadik SoC include:
>  
>  S8815 "MiniKit" manufactured by Calao Systems:
> diff --git a/arch/arm/boot/dts/ste-nomadik-stn8815.dtsi b/arch/arm/boot/dts/ste-nomadik-stn8815.dtsi
> index 4a4aab3..f0df948 100644
> --- a/arch/arm/boot/dts/ste-nomadik-stn8815.dtsi
> +++ b/arch/arm/boot/dts/ste-nomadik-stn8815.dtsi
> @@ -45,6 +45,7 @@
>                 gpio-controller;
>                 #gpio-cells = <2>;
>                 gpio-bank = <0>;
> +               clocks = <&pclk>;
>         };
>  
>         gpio1: gpio at 101e5000 {
> @@ -57,6 +58,7 @@
>                 gpio-controller;
>                 #gpio-cells = <2>;
>                 gpio-bank = <1>;
> +               clocks = <&pclk>;
>         };
>  
>         gpio2: gpio at 101e6000 {
> @@ -69,6 +71,7 @@
>                 gpio-controller;
>                 #gpio-cells = <2>;
>                 gpio-bank = <2>;
> +               clocks = <&pclk>;
>         };
>  
>         gpio3: gpio at 101e7000 {
> @@ -81,12 +84,50 @@
>                 gpio-controller;
>                 #gpio-cells = <2>;
>                 gpio-bank = <3>;
> +               clocks = <&pclk>;
>         };
>  
>         pinctrl {
>                 compatible = "stericsson,nmk-pinctrl-stn8815";
>         };
>  
> +       src: src at 101e0000 {
> +               compatible = "stericsson,nomadik-src";
> +               reg = <0x101e0000 0x1000>;
> +               clocks {
> +                       /*
> +                        * Dummy clock for primecells
> +                        */
> +                       pclk: pclk at 0 {
> +                               #clock-cells = <0>;
> +                               compatible = "fixed-clock";
> +                               clock-frequency = <2400000>;
> +                       };
> +                       /*
> +                        * The 2.4 MHz TIMCLK reference clock is active at
> +                        * boot time, this is actually the MXTALCLK @19.2 MHz
> +                        * divided by 8. This clock is used by the timers and
> +                        * watchdog. See page 105 ff.
> +                        */
> +                       timclk: timclk at 2.4M {
> +                               #clock-cells = <0>;
> +                               compatible = "fixed-clock";
> +                               clock-frequency = <2400000>;
> +                       };
> +                       /*
> +                        * At boot time, PLL2 is set to generate a set of
> +                        * fixed clocks, one of them is CLK48, the 48 MHz
> +                        * clock, routed to the UART, MMC/SD, I2C, IrDA,
> +                        * USB and SSP blocks.
> +                        */
> +                       clk48: clk48 at 48M {
> +                               #clock-cells = <0>;
> +                               compatible = "fixed-clock";
> +                               clock-frequency = <48000000>;
> +                       };
> +               };
> +       };
> +
>         /* A NAND flash of 128 MiB */
>         fsmc: flash at 40000000 {
>                 compatible = "stericsson,fsmc-nand";
> @@ -97,6 +138,7 @@
>                         <0x41000000 0x2000>,    /* NAND Base ADDR */
>                         <0x40800000 0x2000>;    /* NAND Base CMD */
>                 reg-names = "fsmc_regs", "nand_data", "nand_addr", "nand_cmd";
> +               clocks = <&pclk>;
>                 status = "okay";
>  
>                 partition at 0 {
> @@ -211,6 +253,8 @@
>                         reg = <0x101fd000 0x1000>;
>                         interrupt-parent = <&vica>;
>                         interrupts = <12>;
> +                       clocks = <&clk48>, <&pclk>;
> +                       clock-names = "uartclk", "apb_pclk";
>                 };
>  
>                 uart1: uart at 101fb000 {
> @@ -218,6 +262,8 @@
>                         reg = <0x101fb000 0x1000>;
>                         interrupt-parent = <&vica>;
>                         interrupts = <17>;
> +                       clocks = <&clk48>, <&pclk>;
> +                       clock-names = "uartclk", "apb_pclk";
>                 };
>  
>                 uart2: uart at 101f2000 {
> @@ -225,17 +271,23 @@
>                         reg = <0x101f2000 0x1000>;
>                         interrupt-parent = <&vica>;
>                         interrupts = <28>;
> +                       clocks = <&clk48>, <&pclk>;
> +                       clock-names = "uartclk", "apb_pclk";
>                         status = "disabled";
>                 };
>  
>                 rng: rng at 101b0000 {
>                         compatible = "arm,primecell";
>                         reg = <0x101b0000 0x1000>;
> +                       clocks = <&clk48>, <&pclk>;
> +                       clock-names = "rng", "apb_pclk";
>                 };
>  
>                 rtc: rtc at 101e8000 {
>                         compatible = "arm,pl031", "arm,primecell";
>                         reg = <0x101e8000 0x1000>;
> +                       clocks = <&pclk>;
> +                       clock-names = "apb_pclk";
>                         interrupt-parent = <&vica>;
>                         interrupts = <10>;
>                 };
> @@ -243,6 +295,8 @@
>                 mmcsd: sdi at 101f6000 {
>                         compatible = "arm,pl18x", "arm,primecell";
>                         reg = <0x101f6000 0x1000>;
> +                       clocks = <&clk48>, <&pclk>;
> +                       clock-names = "mclk", "apb_pclk";
>                         interrupt-parent = <&vica>;
>                         interrupts = <22>;
>                         max-frequency = <48000000>;
> diff --git a/arch/arm/mach-nomadik/cpu-8815.c b/arch/arm/mach-nomadik/cpu-8815.c
> index 59f6ff5..0e2c5e0 100644
> --- a/arch/arm/mach-nomadik/cpu-8815.c
> +++ b/arch/arm/mach-nomadik/cpu-8815.c
> @@ -280,28 +280,12 @@ device_initcall(cpu8815_mmcsd_init);
>  
>  /* These are mostly to get the right device names for the clock lookups */
>  static struct of_dev_auxdata cpu8815_auxdata_lookup[] __initdata = {
> -       OF_DEV_AUXDATA("st,nomadik-gpio", NOMADIK_GPIO0_BASE,
> -               "gpio.0", NULL),
> -       OF_DEV_AUXDATA("st,nomadik-gpio", NOMADIK_GPIO1_BASE,
> -               "gpio.1", NULL),
> -       OF_DEV_AUXDATA("st,nomadik-gpio", NOMADIK_GPIO2_BASE,
> -               "gpio.2", NULL),
> -       OF_DEV_AUXDATA("st,nomadik-gpio", NOMADIK_GPIO3_BASE,
> -               "gpio.3", NULL),
>         OF_DEV_AUXDATA("stericsson,nmk-pinctrl-stn8815", 0,
>                 "pinctrl-stn8815", NULL),
> -       OF_DEV_AUXDATA("arm,primecell", NOMADIK_UART0_BASE,
> -               "uart0", NULL),
> -       OF_DEV_AUXDATA("arm,primecell", NOMADIK_UART1_BASE,
> -               "uart1", NULL),
> -       OF_DEV_AUXDATA("arm,primecell", NOMADIK_RNG_BASE,
> -               "rng", NULL),
> -       OF_DEV_AUXDATA("arm,primecell", NOMADIK_RTC_BASE,
> -               "rtc-pl031", NULL),
>         OF_DEV_AUXDATA("stericsson,fsmc-nand", NOMADIK_FSMC_BASE,
> -               "fsmc-nand", &cpu8815_nand_data),
> +               NULL, &cpu8815_nand_data),
>         OF_DEV_AUXDATA("arm,primecell", NOMADIK_SDI_BASE,
> -               "mmci", &mmcsd_plat_data),
> +               NULL, &mmcsd_plat_data),
>         { /* sentinel */ },
>  };
>  
> diff --git a/drivers/clk/clk-nomadik.c b/drivers/clk/clk-nomadik.c
> index 6b4c70f..19f197c 100644
> --- a/drivers/clk/clk-nomadik.c
> +++ b/drivers/clk/clk-nomadik.c
> @@ -3,24 +3,24 @@
>  #include <linux/err.h>
>  #include <linux/io.h>
>  #include <linux/clk-provider.h>
> +#include <linux/of.h>
>  
>  /*
>   * The Nomadik clock tree is described in the STN8815A12 DB V4.2
>   * reference manual for the chip, page 94 ff.
>   */
>  
> +static const __initconst struct of_device_id cpu8815_clk_match[] = {
> +       { .compatible = "fixed-clock", .data = of_fixed_clk_setup, },
> +       { /* sentinel */ }
> +};
> +
>  void __init nomadik_clk_init(void)
>  {
>         struct clk *clk;
>  
>         clk = clk_register_fixed_rate(NULL, "apb_pclk", NULL, CLK_IS_ROOT, 0);
>         clk_register_clkdev(clk, "apb_pclk", NULL);
> -       clk_register_clkdev(clk, NULL, "gpio.0");
> -       clk_register_clkdev(clk, NULL, "gpio.1");
> -       clk_register_clkdev(clk, NULL, "gpio.2");
> -       clk_register_clkdev(clk, NULL, "gpio.3");
> -       clk_register_clkdev(clk, NULL, "rng");
> -       clk_register_clkdev(clk, NULL, "fsmc-nand");
>  
>         /*
>          * The 2.4 MHz TIMCLK reference clock is active at boot time, this is
> @@ -32,17 +32,5 @@ void __init nomadik_clk_init(void)
>         clk_register_clkdev(clk, NULL, "mtu0");
>         clk_register_clkdev(clk, NULL, "mtu1");
>  
> -       /*
> -        * At boot time, PLL2 is set to generate a set of fixed clocks,
> -        * one of them is CLK48, the 48 MHz clock, routed to the UART, MMC/SD
> -        * I2C, IrDA, USB and SSP blocks.
> -        */
> -       clk = clk_register_fixed_rate(NULL, "CLK48", NULL, CLK_IS_ROOT,
> -                                     48000000);
> -       clk_register_clkdev(clk, NULL, "uart0");
> -       clk_register_clkdev(clk, NULL, "uart1");
> -       clk_register_clkdev(clk, NULL, "mmci");
> -       clk_register_clkdev(clk, NULL, "ssp");
> -       clk_register_clkdev(clk, NULL, "nmk-i2c.0");
> -       clk_register_clkdev(clk, NULL, "nmk-i2c.1");
> +       of_clk_init(cpu8815_clk_match);
>  }
> -- 
> 1.8.1.4
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From festevam at gmail.com  Mon Apr 22 18:35:00 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Mon, 22 Apr 2013 19:35:00 -0300
Subject: [RFC][PATCH] video: imx: Select VIDEOMODE_HELPERS
In-Reply-To: <1366666110-9585-1-git-send-email-marex@denx.de>
References: <1366666110-9585-1-git-send-email-marex@denx.de>
Message-ID: <CAOMZO5Av8RyptoxAQ13Psxjjd4nhHVbEJoVm6SqyLr55bPmSng@mail.gmail.com>

Hi Marek,

On Mon, Apr 22, 2013 at 6:28 PM, Marek Vasut <marex at denx.de> wrote:
> Without this, I get the following problem when building kernel:
>
> drivers/built-in.o: In function `imx_pd_connector_get_modes':
> /linux-2.6/drivers/staging/imx-drm/parallel-display.c:78: undefined reference to `of_get_drm_display_mode'
> make: *** [vmlinux] Error 1
>
> NOTE: I think this patch is almost absolutely not correct.
>
> Signed-off-by: Marek Vasut <marex at denx.de>
> Cc: Sascha Hauer <s.hauer at pengutronix.de>
> Cc: Philipp Zabel <p.zabel at pengutronix.de>
> Cc: Fabio Estevam <fabio.estevam at freescale.com>

Patch looks good, but you should have copied Greg Kroah-Hartman, as he
is the one who takes patches into staging.

Regards,

Fabio Estevam


From jason at lakedaemon.net  Mon Apr 22 18:54:56 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Mon, 22 Apr 2013 18:54:56 -0400
Subject: [PATCH 1/3] mmc: mvsdio: Support inverted CD and WP GPIO lines
In-Reply-To: <20130422214543.GJ29947@lunn.ch>
References: <1366660500-26835-1-git-send-email-gmbnomis@gmail.com>
 <1366660500-26835-2-git-send-email-gmbnomis@gmail.com>
 <87wqrutjss.fsf@octavius.laptop.org>
 <20130422203723.GI29947@lunn.ch>
 <20130422210949.GJ25724@titan.lakedaemon.net>
 <20130422214543.GJ29947@lunn.ch>
Message-ID: <20130422225456.GK25724@titan.lakedaemon.net>

On Mon, Apr 22, 2013 at 11:45:43PM +0200, Andrew Lunn wrote:
> > > > The core function mmc_of_parse() (new in 3.9) will do all of this DT
> > > > parsing for you, and will also take care of the driver's later calls
> > > > to mmc_gpio_request_{cd,wp}().  Could you try using that function
> > > > instead, please?
> > > 
> > > Hi Chris, Simon
> > > 
> > > I have a vague recollection that Thomas Petazzoni already did this
> > > conversion. Take a look in linux-next, or maybe Jason can point you at
> > > a branch.
> > 
> > Andrew,
> > 
> > Thomas did a board conversion here (slated for v3.11 in /pcie branch):
> > 
> >   cd2bde5 arm: kirkwood: convert db-88f6281 to the Device Tree
> > 
> > And Sebastian did some mvsdio WP and CD pin work here:
> > 
> >   0d0644eARM: Kirkwood: fix unused mvsdio gpio pins
> > 
> > Nothing else really jumps out though.  Where either of these what you
> > were thinking of?
> 
> http://lists.infradead.org/pipermail/linux-arm-kernel/2012-December/138514.html
> 
> and
> 
> http://lists.infradead.org/pipermail/linux-arm-kernel/2012-December/138513.html

Ahh, they were with the original submission for mvsdio:

  07728b7 mmc: mvsdio: use slot-gpio for card detect gpio
  3724482 mmc: mvsdio: use slot-gpio infrastructure for write protect gpio

I thought you were referring to a newer patch.

thx,

Jason.


From robherring2 at gmail.com  Mon Apr 22 18:57:47 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Mon, 22 Apr 2013 17:57:47 -0500
Subject: linux-next ARM multi-platform randconfig errors
In-Reply-To: <Pine.LNX.4.64.1304221318350.22065@file.rdu.redhat.com>
References: <5170B4C6.1030300@gmail.com>
 <Pine.LNX.4.64.1304221318350.22065@file.rdu.redhat.com>
Message-ID: <5175C06B.4020805@gmail.com>

On 04/22/2013 12:32 PM, Mikulas Patocka wrote:
> 
> 
> On Thu, 18 Apr 2013, Rob Herring wrote:
> 
>> Current errors in linux-next for ARM multi-platform randconfig builds.
>>
>> Rob
>>
>> drivers/built-in.o:drivers/md/dm-cache-target.c:429: more undefined references to `__udivdi3' follow
>> /var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/md/dm-cache-target.c:429: undefined reference to `__udivdi3'
>> /var/lib/jenkins/jobs/linux-randconfig/workspace/drivers/md/dm-cache-target.c:429: undefined reference to `__umoddi3'
>> driversdrivers/md/dm-cache-target.c:429: more undefined references to `__udivdi3' follow
>> drivers/md/dm-cache-target.c:429: undefined reference to `__udivdi3'
>> drivers/md/dm-cache-target.c:429: undefined reference to `__umoddi3'
> 
> Hi
> 
> I tried to cross-compile dm-cache on linux-next for arm and there were no 
> failures and no references to __udivdi3 and __umoddi3.
> 
> Please send the .config file that resulted in these faulures.

The config is attached. My guess is it might be related to CONFIG_AEABI
not set. The compiler is "gcc version 4.6.3 (Ubuntu/Linaro
4.6.3-1ubuntu5)" which is ubuntu 12.04 arm cross compiler.

Rob
-------------- next part --------------
#
# Automatically generated file; DO NOT EDIT.
# Linux/arm 3.9.0-rc7 Kernel Configuration
#
CONFIG_ARM=y
CONFIG_SYS_SUPPORTS_APM_EMULATION=y
CONFIG_HAVE_PROC_CPU=y
CONFIG_NO_IOPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_RWSEM_GENERIC_SPINLOCK=y
CONFIG_ARCH_HAS_CPUFREQ=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_VECTORS_BASE=0xffff0000
CONFIG_ARM_PATCH_PHYS_VIRT=y
CONFIG_GENERIC_BUG=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y

#
# General setup
#
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
# CONFIG_SWAP is not set
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_FHANDLE=y
CONFIG_HAVE_GENERIC_HARDIRQS=y

#
# IRQ subsystem
#
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_HARDIRQS_SW_RESEND=y
CONFIG_GENERIC_IRQ_CHIP=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_DOMAIN_DEBUG=y
CONFIG_SPARSE_IRQ=y
# CONFIG_ALWAYS_USE_PERSISTENT_CLOCK is not set
CONFIG_KTIME_SCALAR=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y

#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_PERIODIC_HZ=y
# CONFIG_NO_HZ_IDLE is not set
CONFIG_HIGH_RES_TIMERS=y

#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_BSD_PROCESS_ACCT is not set

#
# RCU Subsystem
#
CONFIG_TINY_RCU=y
# CONFIG_PREEMPT_RCU is not set
CONFIG_RCU_STALL_COMMON=y
# CONFIG_TREE_RCU_TRACE is not set
CONFIG_IKCONFIG=y
# CONFIG_IKCONFIG_PROC is not set
CONFIG_LOG_BUF_SHIFT=17
CONFIG_CGROUPS=y
CONFIG_CGROUP_DEBUG=y
CONFIG_CGROUP_FREEZER=y
# CONFIG_CGROUP_DEVICE is not set
CONFIG_CPUSETS=y
# CONFIG_PROC_PID_CPUSET is not set
CONFIG_CGROUP_CPUACCT=y
# CONFIG_RESOURCE_COUNTERS is not set
CONFIG_CGROUP_SCHED=y
CONFIG_FAIR_GROUP_SCHED=y
# CONFIG_CFS_BANDWIDTH is not set
CONFIG_RT_GROUP_SCHED=y
# CONFIG_BLK_CGROUP is not set
# CONFIG_CHECKPOINT_RESTORE is not set
# CONFIG_NAMESPACES is not set
CONFIG_SCHED_AUTOGROUP=y
CONFIG_SYSFS_DEPRECATED=y
CONFIG_SYSFS_DEPRECATED_V2=y
# CONFIG_RELAY is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_RD_GZIP=y
# CONFIG_RD_BZIP2 is not set
# CONFIG_RD_LZMA is not set
# CONFIG_RD_XZ is not set
CONFIG_RD_LZO=y
# CONFIG_RD_LZ4 is not set
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
CONFIG_EXPERT=y
CONFIG_HAVE_UID16=y
# CONFIG_UID16 is not set
CONFIG_SYSCTL_SYSCALL=y
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
# CONFIG_BASE_FULL is not set
CONFIG_FUTEX=y
# CONFIG_EPOLL is not set
# CONFIG_SIGNALFD is not set
# CONFIG_TIMERFD is not set
CONFIG_EVENTFD=y
# CONFIG_SHMEM is not set
CONFIG_AIO=y
CONFIG_EMBEDDED=y
CONFIG_HAVE_PERF_EVENTS=y
CONFIG_PERF_USE_VMALLOC=y

#
# Kernel Performance Events And Counters
#
# CONFIG_PERF_EVENTS is not set
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_SLUB_DEBUG=y
# CONFIG_COMPAT_BRK is not set
# CONFIG_SLAB is not set
CONFIG_SLUB=y
# CONFIG_SLOB is not set
# CONFIG_PROFILING is not set
CONFIG_TRACEPOINTS=y
CONFIG_HAVE_OPROFILE=y
# CONFIG_JUMP_LABEL is not set
# CONFIG_HAVE_64BIT_ALIGNED_ACCESS is not set
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
CONFIG_HAVE_ARCH_TRACEHOOK=y
CONFIG_HAVE_DMA_ATTRS=y
CONFIG_HAVE_DMA_CONTIGUOUS=y
CONFIG_GENERIC_SMP_IDLE_THREAD=y
CONFIG_GENERIC_IDLE_LOOP=y
CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y
CONFIG_HAVE_CLK=y
CONFIG_HAVE_DMA_API_DEBUG=y
CONFIG_HAVE_ARCH_JUMP_LABEL=y
CONFIG_ARCH_WANT_IPC_PARSE_VERSION=y
CONFIG_HAVE_ARCH_SECCOMP_FILTER=y
CONFIG_HAVE_CONTEXT_TRACKING=y
CONFIG_MODULES_USE_ELF_REL=y
CONFIG_CLONE_BACKWARDS=y
CONFIG_OLD_SIGSUSPEND3=y
CONFIG_OLD_SIGACTION=y

#
# GCOV-based kernel profiling
#
# CONFIG_GCOV_KERNEL is not set
CONFIG_HAVE_GENERIC_DMA_COHERENT=y
CONFIG_SLABINFO=y
CONFIG_RT_MUTEXES=y
CONFIG_BASE_SMALL=1
# CONFIG_MODULES is not set
CONFIG_BLOCK=y
CONFIG_LBDAF=y
CONFIG_BLK_DEV_BSG=y
# CONFIG_BLK_DEV_BSGLIB is not set
# CONFIG_BLK_DEV_INTEGRITY is not set

#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
CONFIG_ACORN_PARTITION=y
CONFIG_ACORN_PARTITION_CUMANA=y
CONFIG_ACORN_PARTITION_EESOX=y
# CONFIG_ACORN_PARTITION_ICS is not set
# CONFIG_ACORN_PARTITION_ADFS is not set
CONFIG_ACORN_PARTITION_POWERTEC=y
# CONFIG_ACORN_PARTITION_RISCIX is not set
# CONFIG_OSF_PARTITION is not set
# CONFIG_AMIGA_PARTITION is not set
# CONFIG_ATARI_PARTITION is not set
# CONFIG_MAC_PARTITION is not set
# CONFIG_MSDOS_PARTITION is not set
CONFIG_LDM_PARTITION=y
CONFIG_LDM_DEBUG=y
CONFIG_SGI_PARTITION=y
CONFIG_ULTRIX_PARTITION=y
# CONFIG_SUN_PARTITION is not set
CONFIG_KARMA_PARTITION=y
# CONFIG_EFI_PARTITION is not set
# CONFIG_SYSV68_PARTITION is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_DEADLINE=y
# CONFIG_IOSCHED_CFQ is not set
CONFIG_DEFAULT_DEADLINE=y
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="deadline"
CONFIG_UNINLINE_SPIN_UNLOCK=y
CONFIG_FREEZER=y

#
# System Type
#
CONFIG_MMU=y
CONFIG_ARCH_MULTIPLATFORM=y
# CONFIG_ARCH_INTEGRATOR is not set
# CONFIG_ARCH_REALVIEW is not set
# CONFIG_ARCH_VERSATILE is not set
# CONFIG_ARCH_AT91 is not set
# CONFIG_ARCH_CLPS711X is not set
# CONFIG_ARCH_GEMINI is not set
# CONFIG_ARCH_EBSA110 is not set
# CONFIG_ARCH_EP93XX is not set
# CONFIG_ARCH_FOOTBRIDGE is not set
# CONFIG_ARCH_NETX is not set
# CONFIG_ARCH_IOP13XX is not set
# CONFIG_ARCH_IOP32X is not set
# CONFIG_ARCH_IOP33X is not set
# CONFIG_ARCH_IXP4XX is not set
# CONFIG_ARCH_DOVE is not set
# CONFIG_ARCH_KIRKWOOD is not set
# CONFIG_ARCH_MV78XX0 is not set
# CONFIG_ARCH_ORION5X is not set
# CONFIG_ARCH_MMP is not set
# CONFIG_ARCH_KS8695 is not set
# CONFIG_ARCH_W90X900 is not set
# CONFIG_ARCH_LPC32XX is not set
# CONFIG_ARCH_PXA is not set
# CONFIG_ARCH_MSM is not set
# CONFIG_ARCH_SHMOBILE is not set
# CONFIG_ARCH_RPC is not set
# CONFIG_ARCH_SA1100 is not set
# CONFIG_ARCH_S3C24XX is not set
# CONFIG_ARCH_S3C64XX is not set
# CONFIG_ARCH_S5P64X0 is not set
# CONFIG_ARCH_S5PC100 is not set
# CONFIG_ARCH_S5PV210 is not set
# CONFIG_ARCH_EXYNOS is not set
# CONFIG_ARCH_SHARK is not set
# CONFIG_ARCH_U300 is not set
# CONFIG_ARCH_DAVINCI is not set
# CONFIG_ARCH_OMAP1 is not set

#
# Multiple platform selection
#

#
# CPU Core family selection
#
CONFIG_ARCH_MULTI_V6=y
CONFIG_ARCH_MULTI_V7=y
CONFIG_ARCH_MULTI_V6_V7=y
# CONFIG_ARCH_MULTI_CPU_AUTO is not set
CONFIG_ARCH_MVEBU=y

#
# Marvell SOC with device tree
#
CONFIG_MACH_ARMADA_370_XP=y
# CONFIG_MACH_ARMADA_370 is not set
CONFIG_MACH_ARMADA_XP=y
CONFIG_ARCH_BCM=y
# CONFIG_ARCH_BCM2835 is not set
# CONFIG_ARCH_CNS3XXX is not set
CONFIG_GPIO_PCA953X=y
CONFIG_ARCH_HIGHBANK=y
# CONFIG_ARCH_MXC is not set

#
# TI OMAP Common Features
#

#
# OMAP Feature Selections
#
# CONFIG_OMAP_RESET_CLOCKS is not set
CONFIG_OMAP_MUX=y
# CONFIG_OMAP_MUX_DEBUG is not set
CONFIG_OMAP_MUX_WARNINGS=y
CONFIG_OMAP_32K_TIMER=y
CONFIG_OMAP_DM_TIMER=y
CONFIG_OMAP_PM_NOOP=y
# CONFIG_MACH_OMAP_GENERIC is not set
CONFIG_ARCH_OMAP=y
CONFIG_ARCH_OMAP2PLUS=y

#
# TI OMAP2/3/4 Specific Features
#
# CONFIG_ARCH_OMAP2PLUS_TYPICAL is not set
CONFIG_SOC_HAS_OMAP2_SDRC=y
# CONFIG_SOC_HAS_REALTIME_COUNTER is not set
# CONFIG_ARCH_OMAP2 is not set
# CONFIG_ARCH_OMAP3 is not set
CONFIG_ARCH_OMAP4=y
CONFIG_SOC_OMAP5=y
# CONFIG_SOC_AM33XX is not set
CONFIG_OMAP_PACKAGE_CBL=y
CONFIG_OMAP_PACKAGE_CBS=y

#
# OMAP Board Type
#
CONFIG_MACH_OMAP_4430SDP=y
# CONFIG_MACH_OMAP4_PANDA is not set
# CONFIG_ARCH_PICOXCELL is not set
CONFIG_ARCH_SOCFPGA=y
# CONFIG_PLAT_SPEAR is not set
# CONFIG_ARCH_SUNXI is not set
# CONFIG_ARCH_SIRF is not set
# CONFIG_ARCH_TEGRA is not set
# CONFIG_ARCH_U8500 is not set
CONFIG_ARCH_VEXPRESS=y

#
# Versatile Express platform type
#
CONFIG_ARCH_VEXPRESS_CORTEX_A5_A9_ERRATA=y
CONFIG_ARCH_VEXPRESS_CA9X4=y
CONFIG_PLAT_VERSATILE_CLCD=y
CONFIG_PLAT_VERSATILE_SCHED_CLOCK=y
CONFIG_ARCH_VIRT=y
CONFIG_ARCH_VT8500=y
# CONFIG_ARCH_WM8750 is not set
CONFIG_ARCH_WM8850=y
CONFIG_ARCH_ZYNQ=y
CONFIG_PLAT_ORION=y
CONFIG_PLAT_VERSATILE=y
CONFIG_ARM_TIMER_SP804=y

#
# Processor Type
#
CONFIG_CPU_PJ4B=y
CONFIG_CPU_V6=y
CONFIG_CPU_V7=y
CONFIG_CPU_32v6=y
CONFIG_CPU_32v6K=y
CONFIG_CPU_32v7=y
CONFIG_CPU_ABRT_EV6=y
CONFIG_CPU_ABRT_EV7=y
CONFIG_CPU_PABRT_V6=y
CONFIG_CPU_PABRT_V7=y
CONFIG_CPU_CACHE_V6=y
CONFIG_CPU_CACHE_V7=y
CONFIG_CPU_CACHE_VIPT=y
CONFIG_CPU_COPY_V6=y
CONFIG_CPU_TLB_V6=y
CONFIG_CPU_TLB_V7=y
CONFIG_CPU_HAS_ASID=y
CONFIG_CPU_CP15=y
CONFIG_CPU_CP15_MMU=y
CONFIG_CPU_USE_DOMAINS=y

#
# Processor Features
#
# CONFIG_ARCH_PHYS_ADDR_T_64BIT is not set
# CONFIG_ARM_THUMB is not set
# CONFIG_ARM_THUMBEE is not set
CONFIG_ARM_VIRT_EXT=y
# CONFIG_CPU_ICACHE_DISABLE is not set
# CONFIG_CPU_DCACHE_DISABLE is not set
CONFIG_CPU_BPREDICT_DISABLE=y
CONFIG_OUTER_CACHE=y
CONFIG_OUTER_CACHE_SYNC=y
CONFIG_MIGHT_HAVE_CACHE_L2X0=y
CONFIG_CACHE_L2X0=y
CONFIG_ARM_L1_CACHE_SHIFT_6=y
CONFIG_ARM_L1_CACHE_SHIFT=6
CONFIG_ARM_DMA_MEM_BUFFERABLE=y
CONFIG_ARM_NR_BANKS=8
CONFIG_MULTI_IRQ_HANDLER=y
# CONFIG_ARM_ERRATA_326103 is not set
# CONFIG_ARM_ERRATA_411920 is not set
CONFIG_ARM_ERRATA_430973=y
CONFIG_PL310_ERRATA_588369=y
CONFIG_ARM_ERRATA_720789=y
CONFIG_PL310_ERRATA_727915=y
CONFIG_ARM_ERRATA_754322=y
CONFIG_ARM_ERRATA_364296=y
# CONFIG_PL310_ERRATA_769419 is not set
CONFIG_ARM_ERRATA_775420=y
CONFIG_ICST=y

#
# Bus support
#
CONFIG_ARM_AMBA=y
# CONFIG_PCI_SYSCALL is not set
CONFIG_PCCARD=y
CONFIG_PCMCIA=y
CONFIG_PCMCIA_LOAD_CIS=y

#
# PC-card bridges
#

#
# Kernel Features
#
CONFIG_HAVE_SMP=y
# CONFIG_SMP is not set
CONFIG_HAVE_ARM_SCU=y
CONFIG_HAVE_ARM_ARCH_TIMER=y
CONFIG_VMSPLIT_3G=y
# CONFIG_VMSPLIT_2G is not set
# CONFIG_VMSPLIT_1G is not set
CONFIG_PAGE_OFFSET=0xC0000000
CONFIG_ARM_PSCI=y
CONFIG_ARCH_NR_GPIO=512
CONFIG_PREEMPT_NONE=y
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT is not set
CONFIG_HZ=100
CONFIG_SCHED_HRTICK=y
# CONFIG_AEABI is not set
CONFIG_ARCH_HAS_HOLES_MEMORYMODEL=y
# CONFIG_ARCH_SPARSEMEM_DEFAULT is not set
# CONFIG_ARCH_SELECT_MEMORY_MODEL is not set
CONFIG_HAVE_ARCH_PFN_VALID=y
CONFIG_HIGHMEM=y
CONFIG_HIGHPTE=y
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
CONFIG_HAVE_MEMBLOCK=y
CONFIG_MEMORY_ISOLATION=y
# CONFIG_HAVE_BOOTMEM_INFO_NODE is not set
CONFIG_PAGEFLAGS_EXTENDED=y
CONFIG_SPLIT_PTLOCK_CPUS=999999
CONFIG_BALLOON_COMPACTION=y
CONFIG_COMPACTION=y
CONFIG_MIGRATION=y
# CONFIG_PHYS_ADDR_T_64BIT is not set
CONFIG_ZONE_DMA_FLAG=0
CONFIG_BOUNCE=y
CONFIG_KSM=y
CONFIG_DEFAULT_MMAP_MIN_ADDR=4096
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_NEED_PER_CPU_KM=y
CONFIG_CLEANCACHE=y
CONFIG_FORCE_MAX_ZONEORDER=11
CONFIG_ALIGNMENT_TRAP=y
# CONFIG_UACCESS_WITH_MEMCPY is not set
# CONFIG_SECCOMP is not set
# CONFIG_CC_STACKPROTECTOR is not set

#
# Boot options
#
CONFIG_USE_OF=y
# CONFIG_ATAGS is not set
CONFIG_ZBOOT_ROM_TEXT=0
CONFIG_ZBOOT_ROM_BSS=0
# CONFIG_ARM_APPENDED_DTB is not set
CONFIG_CMDLINE=""
CONFIG_KEXEC=y
# CONFIG_CRASH_DUMP is not set
CONFIG_AUTO_ZRELADDR=y

#
# CPU Power Management
#

#
# CPU Frequency scaling
#
# CONFIG_CPU_FREQ is not set
# CONFIG_CPU_IDLE is not set
# CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED is not set

#
# Floating point emulation
#

#
# At least one emulation must be selected
#
CONFIG_FPE_NWFPE=y
CONFIG_FPE_NWFPE_XP=y
# CONFIG_FPE_FASTFPE is not set
CONFIG_VFP=y
CONFIG_VFPv3=y
CONFIG_NEON=y

#
# Userspace binary formats
#
# CONFIG_BINFMT_ELF is not set
CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE=y
# CONFIG_BINFMT_SCRIPT is not set
CONFIG_HAVE_AOUT=y
# CONFIG_BINFMT_AOUT is not set
CONFIG_BINFMT_MISC=y
# CONFIG_COREDUMP is not set
CONFIG_ARTHUR=y

#
# Power management options
#
# CONFIG_SUSPEND is not set
# CONFIG_PM_RUNTIME is not set
CONFIG_ARCH_HAS_OPP=y
CONFIG_PM_OPP=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
# CONFIG_ARM_CPU_SUSPEND is not set
# CONFIG_NET is not set
CONFIG_HAVE_BPF_JIT=y

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_UEVENT_HELPER_PATH=""
# CONFIG_DEVTMPFS is not set
CONFIG_STANDALONE=y
# CONFIG_PREVENT_FIRMWARE_BUILD is not set
CONFIG_FW_LOADER=y
# CONFIG_FIRMWARE_IN_KERNEL is not set
CONFIG_EXTRA_FIRMWARE=""
CONFIG_FW_LOADER_USER_HELPER=y
# CONFIG_DEBUG_DRIVER is not set
CONFIG_DEBUG_DEVRES=y
# CONFIG_SYS_HYPERVISOR is not set
# CONFIG_GENERIC_CPU_DEVICES is not set
CONFIG_SOC_BUS=y
CONFIG_REGMAP=y
CONFIG_REGMAP_I2C=y
CONFIG_REGMAP_MMIO=y
CONFIG_REGMAP_IRQ=y
CONFIG_DMA_SHARED_BUFFER=y
CONFIG_CMA=y
CONFIG_CMA_DEBUG=y

#
# Default contiguous memory area size:
#
CONFIG_CMA_SIZE_MBYTES=16
CONFIG_CMA_SIZE_SEL_MBYTES=y
# CONFIG_CMA_SIZE_SEL_PERCENTAGE is not set
# CONFIG_CMA_SIZE_SEL_MIN is not set
# CONFIG_CMA_SIZE_SEL_MAX is not set
CONFIG_CMA_ALIGNMENT=8
CONFIG_CMA_AREAS=7

#
# Bus devices
#
CONFIG_OMAP_OCP2SCP=y
CONFIG_OMAP_INTERCONNECT=y
CONFIG_MTD=y
# CONFIG_MTD_REDBOOT_PARTS is not set
# CONFIG_MTD_CMDLINE_PARTS is not set
# CONFIG_MTD_AFS_PARTS is not set
CONFIG_MTD_OF_PARTS=y
# CONFIG_MTD_AR7_PARTS is not set

#
# User Modules And Translation Layers
#
CONFIG_MTD_BLKDEVS=y
# CONFIG_MTD_BLOCK is not set
CONFIG_MTD_BLOCK_RO=y
CONFIG_FTL=y
CONFIG_NFTL=y
# CONFIG_NFTL_RW is not set
CONFIG_INFTL=y
CONFIG_RFD_FTL=y
# CONFIG_SSFDC is not set
# CONFIG_SM_FTL is not set
CONFIG_MTD_OOPS=y

#
# RAM/ROM/Flash chip drivers
#
# CONFIG_MTD_CFI is not set
# CONFIG_MTD_JEDECPROBE is not set
CONFIG_MTD_MAP_BANK_WIDTH_1=y
CONFIG_MTD_MAP_BANK_WIDTH_2=y
CONFIG_MTD_MAP_BANK_WIDTH_4=y
# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set
CONFIG_MTD_CFI_I1=y
CONFIG_MTD_CFI_I2=y
# CONFIG_MTD_CFI_I4 is not set
# CONFIG_MTD_CFI_I8 is not set
# CONFIG_MTD_RAM is not set
# CONFIG_MTD_ROM is not set
# CONFIG_MTD_ABSENT is not set

#
# Mapping drivers for chip access
#
CONFIG_MTD_COMPLEX_MAPPINGS=y
CONFIG_MTD_PHYSMAP=y
CONFIG_MTD_PHYSMAP_COMPAT=y
CONFIG_MTD_PHYSMAP_START=0x8000000
CONFIG_MTD_PHYSMAP_LEN=0
CONFIG_MTD_PHYSMAP_BANKWIDTH=2
# CONFIG_MTD_PCMCIA is not set
CONFIG_MTD_GPIO_ADDR=y
# CONFIG_MTD_PLATRAM is not set
CONFIG_MTD_LATCH_ADDR=y

#
# Self-contained MTD device drivers
#
# CONFIG_MTD_SLRAM is not set
# CONFIG_MTD_PHRAM is not set
# CONFIG_MTD_MTDRAM is not set
CONFIG_MTD_BLOCK2MTD=y

#
# Disk-On-Chip Device Drivers
#
# CONFIG_MTD_DOCG3 is not set
CONFIG_MTD_NAND_ECC=y
CONFIG_MTD_NAND_ECC_SMC=y
CONFIG_MTD_NAND=y
# CONFIG_MTD_NAND_ECC_BCH is not set
# CONFIG_MTD_SM_COMMON is not set
# CONFIG_MTD_NAND_DENALI is not set
# CONFIG_MTD_NAND_GPIO is not set
CONFIG_MTD_NAND_OMAP2=y
CONFIG_MTD_NAND_IDS=y
CONFIG_MTD_NAND_DISKONCHIP=y
CONFIG_MTD_NAND_DISKONCHIP_PROBE_ADVANCED=y
CONFIG_MTD_NAND_DISKONCHIP_PROBE_ADDRESS=0
# CONFIG_MTD_NAND_DISKONCHIP_PROBE_HIGH is not set
# CONFIG_MTD_NAND_DISKONCHIP_BBTWRITE is not set
# CONFIG_MTD_NAND_DOCG4 is not set
# CONFIG_MTD_NAND_TMIO is not set
# CONFIG_MTD_NAND_NANDSIM is not set
# CONFIG_MTD_NAND_PLATFORM is not set
# CONFIG_MTD_NAND_ORION is not set
# CONFIG_MTD_ONENAND is not set

#
# LPDDR flash memory drivers
#
CONFIG_MTD_LPDDR=y
CONFIG_MTD_QINFO_PROBE=y
CONFIG_MTD_UBI=y
CONFIG_MTD_UBI_WL_THRESHOLD=4096
CONFIG_MTD_UBI_BEB_LIMIT=20
CONFIG_MTD_UBI_FASTMAP=y
# CONFIG_MTD_UBI_GLUEBI is not set
CONFIG_DTC=y
CONFIG_OF=y

#
# Device Tree and Open Firmware support
#
CONFIG_PROC_DEVICETREE=y
CONFIG_OF_SELFTEST=y
CONFIG_OF_FLATTREE=y
CONFIG_OF_EARLY_FLATTREE=y
CONFIG_OF_ADDRESS=y
CONFIG_OF_IRQ=y
CONFIG_OF_DEVICE=y
CONFIG_OF_I2C=y
CONFIG_OF_MTD=y
# CONFIG_PARPORT is not set
CONFIG_BLK_DEV=y
# CONFIG_BLK_DEV_COW_COMMON is not set
# CONFIG_BLK_DEV_LOOP is not set

#
# DRBD disabled because PROC_FS or INET not selected
#
CONFIG_BLK_DEV_OSD=y
# CONFIG_BLK_DEV_RAM is not set
CONFIG_CDROM_PKTCDVD=y
CONFIG_CDROM_PKTCDVD_BUFFERS=8
# CONFIG_CDROM_PKTCDVD_WCACHE is not set
# CONFIG_MG_DISK is not set
# CONFIG_VIRTIO_BLK is not set
# CONFIG_BLOCKCONSOLE is not set

#
# Misc devices
#
# CONFIG_SENSORS_LIS3LV02D is not set
# CONFIG_AD525X_DPOT is not set
# CONFIG_ATMEL_PWM is not set
CONFIG_DUMMY_IRQ=y
CONFIG_ICS932S401=y
CONFIG_ATMEL_SSC=y
# CONFIG_ENCLOSURE_SERVICES is not set
CONFIG_APDS9802ALS=y
CONFIG_ISL29003=y
# CONFIG_ISL29020 is not set
CONFIG_SENSORS_TSL2550=y
CONFIG_SENSORS_BH1780=y
# CONFIG_SENSORS_BH1770 is not set
# CONFIG_SENSORS_APDS990X is not set
# CONFIG_HMC6352 is not set
# CONFIG_DS1682 is not set
CONFIG_ARM_CHARLCD=y
# CONFIG_BMP085_I2C is not set
# CONFIG_USB_SWITCH_FSA9480 is not set
CONFIG_SRAM=y
# CONFIG_C2PORT is not set

#
# EEPROM support
#
# CONFIG_EEPROM_AT24 is not set
CONFIG_EEPROM_LEGACY=y
# CONFIG_EEPROM_MAX6875 is not set
CONFIG_EEPROM_93CX6=y

#
# Texas Instruments shared transport line discipline
#
# CONFIG_SENSORS_LIS3_I2C is not set

#
# Altera FPGA firmware download module
#
CONFIG_ALTERA_STAPL=y
CONFIG_HAVE_IDE=y
# CONFIG_IDE is not set

#
# SCSI device support
#
CONFIG_SCSI_MOD=y
# CONFIG_RAID_ATTRS is not set
CONFIG_SCSI=y
CONFIG_SCSI_DMA=y
# CONFIG_SCSI_TGT is not set
# CONFIG_SCSI_NETLINK is not set
# CONFIG_SCSI_PROC_FS is not set

#
# SCSI support type (disk, tape, CD-ROM)
#
# CONFIG_BLK_DEV_SD is not set
CONFIG_CHR_DEV_ST=y
# CONFIG_CHR_DEV_OSST is not set
# CONFIG_BLK_DEV_SR is not set
# CONFIG_CHR_DEV_SG is not set
# CONFIG_CHR_DEV_SCH is not set
# CONFIG_SCSI_MULTI_LUN is not set
CONFIG_SCSI_CONSTANTS=y
CONFIG_SCSI_LOGGING=y
# CONFIG_SCSI_SCAN_ASYNC is not set

#
# SCSI Transports
#
# CONFIG_SCSI_SPI_ATTRS is not set
# CONFIG_SCSI_FC_ATTRS is not set
CONFIG_SCSI_SAS_ATTRS=y
# CONFIG_SCSI_SAS_LIBSAS is not set
# CONFIG_SCSI_SRP_ATTRS is not set
# CONFIG_SCSI_LOWLEVEL is not set
# CONFIG_SCSI_LOWLEVEL_PCMCIA is not set
CONFIG_SCSI_DH=y
CONFIG_SCSI_DH_RDAC=y
CONFIG_SCSI_DH_HP_SW=y
# CONFIG_SCSI_DH_EMC is not set
# CONFIG_SCSI_DH_ALUA is not set
CONFIG_SCSI_OSD_INITIATOR=y
CONFIG_SCSI_OSD_ULD=y
CONFIG_SCSI_OSD_DPRINT_SENSE=1
# CONFIG_SCSI_OSD_DEBUG is not set
CONFIG_HAVE_PATA_PLATFORM=y
# CONFIG_ATA is not set
CONFIG_MD=y
CONFIG_BLK_DEV_MD=y
CONFIG_MD_AUTODETECT=y
CONFIG_MD_LINEAR=y
# CONFIG_MD_RAID0 is not set
CONFIG_MD_RAID1=y
CONFIG_MD_RAID10=y
CONFIG_MD_RAID456=y
# CONFIG_MD_MULTIPATH is not set
# CONFIG_MD_FAULTY is not set
CONFIG_BCACHE=y
CONFIG_BCACHE_DEBUG=y
CONFIG_BCACHE_EDEBUG=y
CONFIG_BCACHE_CLOSURES_DEBUG=y
CONFIG_BLK_DEV_DM=y
CONFIG_DM_DEBUG=y
CONFIG_DM_BUFIO=y
CONFIG_DM_BIO_PRISON=y
CONFIG_DM_PERSISTENT_DATA=y
CONFIG_DM_CRYPT=y
CONFIG_DM_SNAPSHOT=y
CONFIG_DM_THIN_PROVISIONING=y
# CONFIG_DM_DEBUG_BLOCK_STACK_TRACING is not set
CONFIG_DM_CACHE=y
CONFIG_DM_CACHE_MQ=y
CONFIG_DM_CACHE_CLEANER=y
# CONFIG_DM_MIRROR is not set
CONFIG_DM_RAID=y
# CONFIG_DM_ZERO is not set
CONFIG_DM_MULTIPATH=y
CONFIG_DM_MULTIPATH_QL=y
# CONFIG_DM_MULTIPATH_ST is not set
# CONFIG_DM_DELAY is not set
CONFIG_DM_UEVENT=y
CONFIG_DM_FLAKEY=y
# CONFIG_DM_VERITY is not set
CONFIG_TARGET_CORE=y
# CONFIG_TCM_IBLOCK is not set
# CONFIG_TCM_FILEIO is not set
CONFIG_TCM_PSCSI=y
CONFIG_LOOPBACK_TARGET=y

#
# Input device support
#
CONFIG_INPUT=y
CONFIG_INPUT_FF_MEMLESS=y
CONFIG_INPUT_POLLDEV=y
# CONFIG_INPUT_SPARSEKMAP is not set
# CONFIG_INPUT_MATRIXKMAP is not set

#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
# CONFIG_INPUT_EVDEV is not set
# CONFIG_INPUT_EVBUG is not set

#
# Input Device Drivers
#
# CONFIG_INPUT_KEYBOARD is not set
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
# CONFIG_MOUSE_PS2_ALPS is not set
# CONFIG_MOUSE_PS2_LOGIPS2PP is not set
# CONFIG_MOUSE_PS2_SYNAPTICS is not set
CONFIG_MOUSE_PS2_CYPRESS=y
CONFIG_MOUSE_PS2_TRACKPOINT=y
# CONFIG_MOUSE_PS2_ELANTECH is not set
# CONFIG_MOUSE_PS2_SENTELIC is not set
# CONFIG_MOUSE_PS2_TOUCHKIT is not set
CONFIG_MOUSE_SERIAL=y
CONFIG_MOUSE_CYAPA=y
CONFIG_MOUSE_VSXXXAA=y
CONFIG_MOUSE_GPIO=y
CONFIG_MOUSE_SYNAPTICS_I2C=y
# CONFIG_INPUT_JOYSTICK is not set
CONFIG_INPUT_TABLET=y
CONFIG_INPUT_TOUCHSCREEN=y
CONFIG_TOUCHSCREEN_AD7879=y
# CONFIG_TOUCHSCREEN_AD7879_I2C is not set
CONFIG_TOUCHSCREEN_ATMEL_MXT=y
CONFIG_TOUCHSCREEN_AUO_PIXCIR=y
# CONFIG_TOUCHSCREEN_BU21013 is not set
CONFIG_TOUCHSCREEN_CY8CTMG110=y
# CONFIG_TOUCHSCREEN_CYTTSP_CORE is not set
# CONFIG_TOUCHSCREEN_DYNAPRO is not set
CONFIG_TOUCHSCREEN_HAMPSHIRE=y
CONFIG_TOUCHSCREEN_EETI=y
CONFIG_TOUCHSCREEN_EGALAX=y
CONFIG_TOUCHSCREEN_FUJITSU=y
CONFIG_TOUCHSCREEN_ILI210X=y
# CONFIG_TOUCHSCREEN_GUNZE is not set
# CONFIG_TOUCHSCREEN_ELO is not set
# CONFIG_TOUCHSCREEN_WACOM_W8001 is not set
CONFIG_TOUCHSCREEN_WACOM_I2C=y
CONFIG_TOUCHSCREEN_MAX11801=y
# CONFIG_TOUCHSCREEN_MCS5000 is not set
# CONFIG_TOUCHSCREEN_MMS114 is not set
# CONFIG_TOUCHSCREEN_MTOUCH is not set
# CONFIG_TOUCHSCREEN_INEXIO is not set
# CONFIG_TOUCHSCREEN_MK712 is not set
CONFIG_TOUCHSCREEN_PENMOUNT=y
CONFIG_TOUCHSCREEN_EDT_FT5X06=y
CONFIG_TOUCHSCREEN_TOUCHRIGHT=y
CONFIG_TOUCHSCREEN_TOUCHWIN=y
# CONFIG_TOUCHSCREEN_PIXCIR is not set
CONFIG_TOUCHSCREEN_TOUCHIT213=y
# CONFIG_TOUCHSCREEN_TSC_SERIO is not set
# CONFIG_TOUCHSCREEN_TSC2007 is not set
# CONFIG_TOUCHSCREEN_W90X900 is not set
# CONFIG_TOUCHSCREEN_ST1232 is not set
CONFIG_TOUCHSCREEN_STMPE=y
# CONFIG_TOUCHSCREEN_TPS6507X is not set
# CONFIG_INPUT_MISC is not set

#
# Hardware I/O ports
#
CONFIG_SERIO=y
CONFIG_SERIO_SERPORT=y
CONFIG_SERIO_AMBAKMI=y
CONFIG_SERIO_LIBPS2=y
CONFIG_SERIO_RAW=y
# CONFIG_SERIO_ALTERA_PS2 is not set
CONFIG_SERIO_PS2MULT=y
# CONFIG_SERIO_ARC_PS2 is not set
CONFIG_SERIO_APBPS2=y
# CONFIG_GAMEPORT is not set

#
# Character devices
#
CONFIG_TTY=y
CONFIG_VT=y
# CONFIG_CONSOLE_TRANSLATIONS is not set
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
CONFIG_VT_HW_CONSOLE_BINDING=y
# CONFIG_UNIX98_PTYS is not set
# CONFIG_LEGACY_PTYS is not set
CONFIG_SERIAL_NONSTANDARD=y
CONFIG_N_HDLC=y
# CONFIG_TRACE_SINK is not set
# CONFIG_DEVKMEM is not set
# CONFIG_STALDRV is not set

#
# Serial drivers
#
# CONFIG_SERIAL_8250 is not set

#
# Non-8250 serial port support
#
# CONFIG_SERIAL_AMBA_PL010 is not set
# CONFIG_SERIAL_AMBA_PL011 is not set
CONFIG_SERIAL_CORE=y
# CONFIG_SERIAL_VT8500 is not set
# CONFIG_SERIAL_OMAP is not set
CONFIG_SERIAL_SCCNXP=y
# CONFIG_SERIAL_SCCNXP_CONSOLE is not set
# CONFIG_SERIAL_TIMBERDALE is not set
# CONFIG_SERIAL_ALTERA_JTAGUART is not set
CONFIG_SERIAL_ALTERA_UART=y
CONFIG_SERIAL_ALTERA_UART_MAXPORTS=4
CONFIG_SERIAL_ALTERA_UART_BAUDRATE=115200
# CONFIG_SERIAL_ALTERA_UART_CONSOLE is not set
# CONFIG_SERIAL_XILINX_PS_UART is not set
CONFIG_SERIAL_ARC=y
# CONFIG_SERIAL_ARC_CONSOLE is not set
CONFIG_SERIAL_ARC_NR_PORTS=1
CONFIG_TTY_PRINTK=y
CONFIG_HVC_DRIVER=y
# CONFIG_HVC_DCC is not set
CONFIG_VIRTIO_CONSOLE=y
# CONFIG_IPMI_HANDLER is not set
CONFIG_HW_RANDOM=y
CONFIG_HW_RANDOM_TIMERIOMEM=y
# CONFIG_HW_RANDOM_ATMEL is not set
# CONFIG_HW_RANDOM_VIRTIO is not set
# CONFIG_HW_RANDOM_EXYNOS is not set
CONFIG_HW_RANDOM_TPM=y
CONFIG_R3964=y

#
# PCMCIA character devices
#
# CONFIG_SYNCLINK_CS is not set
CONFIG_CARDMAN_4000=y
# CONFIG_CARDMAN_4040 is not set
CONFIG_RAW_DRIVER=y
CONFIG_MAX_RAW_DEVS=256
CONFIG_TCG_TPM=y
# CONFIG_TCG_TIS_I2C_INFINEON is not set
CONFIG_TCG_ST33_I2C=y
CONFIG_I2C=y
CONFIG_I2C_BOARDINFO=y
CONFIG_I2C_COMPAT=y
# CONFIG_I2C_CHARDEV is not set
CONFIG_I2C_MUX=y

#
# Multiplexer I2C Chip support
#
CONFIG_I2C_ARB_GPIO_CHALLENGE=y
CONFIG_I2C_MUX_GPIO=y
CONFIG_I2C_MUX_PCA9541=y
CONFIG_I2C_MUX_PCA954x=y
# CONFIG_I2C_MUX_PINCTRL is not set
CONFIG_I2C_HELPER_AUTO=y
CONFIG_I2C_ALGOBIT=y

#
# I2C Hardware Bus support
#

#
# I2C system bus drivers (mostly embedded / system-on-chip)
#
# CONFIG_I2C_CBUS_GPIO is not set
CONFIG_I2C_DESIGNWARE_CORE=y
CONFIG_I2C_DESIGNWARE_PLATFORM=y
CONFIG_I2C_GPIO=y
CONFIG_I2C_MV64XXX=y
CONFIG_I2C_NOMADIK=y
CONFIG_I2C_OCORES=y
# CONFIG_I2C_OMAP is not set
# CONFIG_I2C_PCA_PLATFORM is not set
# CONFIG_I2C_PXA_PCI is not set
# CONFIG_I2C_SIMTEC is not set
# CONFIG_I2C_VERSATILE is not set
CONFIG_I2C_XILINX=y

#
# External I2C/SMBus adapter drivers
#
# CONFIG_I2C_PARPORT_LIGHT is not set
CONFIG_I2C_TAOS_EVM=y

#
# Other I2C/SMBus bus drivers
#
CONFIG_I2C_DEBUG_CORE=y
CONFIG_I2C_DEBUG_ALGO=y
CONFIG_I2C_DEBUG_BUS=y
# CONFIG_SPI is not set

#
# Qualcomm MSM SSBI bus support
#
CONFIG_SSBI=y
# CONFIG_HSI is not set

#
# PPS support
#
CONFIG_PPS=y
# CONFIG_PPS_DEBUG is not set
CONFIG_NTP_PPS=y

#
# PPS clients support
#
CONFIG_PPS_CLIENT_KTIMER=y
CONFIG_PPS_CLIENT_LDISC=y
# CONFIG_PPS_CLIENT_GPIO is not set

#
# PPS generators support
#

#
# PTP clock support
#
# CONFIG_PTP_1588_CLOCK is not set

#
# Enable PHYLIB and NETWORK_PHY_TIMESTAMPING to see the additional clocks.
#
# CONFIG_PTP_1588_CLOCK_PCH is not set
CONFIG_PINCTRL=y

#
# Pin controllers
#
CONFIG_PINMUX=y
CONFIG_PINCONF=y
CONFIG_DEBUG_PINCTRL=y
# CONFIG_PINCTRL_SINGLE is not set
# CONFIG_PINCTRL_EXYNOS is not set
CONFIG_PINCTRL_EXYNOS5440=y
CONFIG_PINCTRL_MVEBU=y
CONFIG_PINCTRL_ARMADA_XP=y
# CONFIG_PINCTRL_WM8850 is not set
CONFIG_ARCH_HAVE_CUSTOM_GPIO_H=y
CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y
CONFIG_ARCH_REQUIRE_GPIOLIB=y
CONFIG_GPIO_DEVRES=y
CONFIG_GPIOLIB=y
CONFIG_OF_GPIO=y
# CONFIG_DEBUG_GPIO is not set
# CONFIG_GPIO_SYSFS is not set
CONFIG_GPIO_GENERIC=y
# CONFIG_GPIO_DA9055 is not set

#
# Memory mapped GPIO drivers:
#
# CONFIG_GPIO_GENERIC_PLATFORM is not set
CONFIG_GPIO_EM=y
CONFIG_GPIO_MVEBU=y
CONFIG_GPIO_PL061=y
CONFIG_GPIO_RCAR=y
CONFIG_GPIO_TS5500=y

#
# I2C GPIO expanders:
#
# CONFIG_GPIO_MAX7300 is not set
CONFIG_GPIO_MAX732X=y
CONFIG_GPIO_MAX732X_IRQ=y
CONFIG_GPIO_PCA953X_IRQ=y
# CONFIG_GPIO_PCF857X is not set
# CONFIG_GPIO_SX150X is not set
CONFIG_GPIO_STMPE=y
# CONFIG_GPIO_WM8350 is not set
# CONFIG_GPIO_ADP5520 is not set
CONFIG_GPIO_ADP5588=y
CONFIG_GPIO_ADP5588_IRQ=y
CONFIG_GPIO_ADNP=y

#
# PCI GPIO expanders:
#

#
# SPI GPIO expanders:
#
# CONFIG_GPIO_MCP23S08 is not set

#
# AC97 GPIO expanders:
#

#
# MODULbus GPIO expanders:
#
# CONFIG_GPIO_PALMAS is not set

#
# USB GPIO expanders:
#
CONFIG_W1=y

#
# 1-wire Bus Masters
#
CONFIG_W1_MASTER_DS2482=y
# CONFIG_W1_MASTER_DS1WM is not set
CONFIG_W1_MASTER_GPIO=y
CONFIG_HDQ_MASTER_OMAP=y

#
# 1-wire Slaves
#
# CONFIG_W1_SLAVE_THERM is not set
CONFIG_W1_SLAVE_SMEM=y
# CONFIG_W1_SLAVE_DS2408 is not set
# CONFIG_W1_SLAVE_DS2413 is not set
# CONFIG_W1_SLAVE_DS2423 is not set
# CONFIG_W1_SLAVE_DS2431 is not set
CONFIG_W1_SLAVE_DS2433=y
# CONFIG_W1_SLAVE_DS2433_CRC is not set
CONFIG_W1_SLAVE_DS2760=y
CONFIG_W1_SLAVE_DS2780=y
CONFIG_W1_SLAVE_DS2781=y
CONFIG_W1_SLAVE_DS28E04=y
CONFIG_W1_SLAVE_BQ27000=y
CONFIG_POWER_SUPPLY=y
# CONFIG_POWER_SUPPLY_DEBUG is not set
CONFIG_PDA_POWER=y
CONFIG_GENERIC_ADC_BATTERY=y
CONFIG_WM8350_POWER=y
CONFIG_TEST_POWER=y
CONFIG_BATTERY_DS2760=y
CONFIG_BATTERY_DS2780=y
CONFIG_BATTERY_DS2781=y
CONFIG_BATTERY_DS2782=y
CONFIG_BATTERY_SBS=y
# CONFIG_BATTERY_BQ27x00 is not set
# CONFIG_BATTERY_MAX17040 is not set
# CONFIG_BATTERY_MAX17042 is not set
# CONFIG_CHARGER_MAX8903 is not set
CONFIG_CHARGER_LP8727=y
CONFIG_CHARGER_LP8788=y
# CONFIG_CHARGER_GPIO is not set
CONFIG_CHARGER_BQ2415X=y
# CONFIG_CHARGER_SMB347 is not set
# CONFIG_BATTERY_GOLDFISH is not set
CONFIG_POWER_RESET=y
CONFIG_POWER_RESET_GPIO=y
# CONFIG_POWER_RESET_QNAP is not set
CONFIG_POWER_RESET_RESTART=y
CONFIG_POWER_RESET_VEXPRESS=y
CONFIG_POWER_AVS=y
CONFIG_HWMON=y
CONFIG_HWMON_VID=y
CONFIG_HWMON_DEBUG_CHIP=y

#
# Native drivers
#
# CONFIG_SENSORS_AD7414 is not set
# CONFIG_SENSORS_AD7418 is not set
# CONFIG_SENSORS_ADM1021 is not set
# CONFIG_SENSORS_ADM1025 is not set
# CONFIG_SENSORS_ADM1026 is not set
# CONFIG_SENSORS_ADM1029 is not set
# CONFIG_SENSORS_ADM1031 is not set
CONFIG_SENSORS_ADM9240=y
CONFIG_SENSORS_ADT7X10=y
CONFIG_SENSORS_ADT7410=y
# CONFIG_SENSORS_ADT7411 is not set
# CONFIG_SENSORS_ADT7462 is not set
# CONFIG_SENSORS_ADT7470 is not set
CONFIG_SENSORS_ADT7475=y
# CONFIG_SENSORS_ASC7621 is not set
# CONFIG_SENSORS_ATXP1 is not set
# CONFIG_SENSORS_DS620 is not set
CONFIG_SENSORS_DS1621=y
CONFIG_SENSORS_DA9055=y
# CONFIG_SENSORS_F71805F is not set
# CONFIG_SENSORS_F71882FG is not set
CONFIG_SENSORS_F75375S=y
CONFIG_SENSORS_G760A=y
CONFIG_SENSORS_GL518SM=y
# CONFIG_SENSORS_GL520SM is not set
CONFIG_SENSORS_GPIO_FAN=y
CONFIG_SENSORS_HIH6130=y
# CONFIG_SENSORS_IIO_HWMON is not set
CONFIG_SENSORS_IT87=y
CONFIG_SENSORS_JC42=y
CONFIG_SENSORS_LINEAGE=y
CONFIG_SENSORS_LM63=y
CONFIG_SENSORS_LM73=y
CONFIG_SENSORS_LM75=y
CONFIG_SENSORS_LM77=y
CONFIG_SENSORS_LM78=y
# CONFIG_SENSORS_LM80 is not set
# CONFIG_SENSORS_LM83 is not set
# CONFIG_SENSORS_LM85 is not set
# CONFIG_SENSORS_LM87 is not set
CONFIG_SENSORS_LM90=y
CONFIG_SENSORS_LM92=y
# CONFIG_SENSORS_LM93 is not set
CONFIG_SENSORS_LTC4151=y
CONFIG_SENSORS_LTC4215=y
# CONFIG_SENSORS_LTC4245 is not set
CONFIG_SENSORS_LTC4261=y
CONFIG_SENSORS_LM95234=y
# CONFIG_SENSORS_LM95241 is not set
CONFIG_SENSORS_LM95245=y
CONFIG_SENSORS_MAX16065=y
CONFIG_SENSORS_MAX1619=y
CONFIG_SENSORS_MAX1668=y
# CONFIG_SENSORS_MAX197 is not set
CONFIG_SENSORS_MAX6639=y
CONFIG_SENSORS_MAX6642=y
CONFIG_SENSORS_MAX6650=y
# CONFIG_SENSORS_MAX6697 is not set
# CONFIG_SENSORS_MCP3021 is not set
# CONFIG_SENSORS_NCT6775 is not set
CONFIG_SENSORS_NTC_THERMISTOR=y
CONFIG_SENSORS_PC87360=y
# CONFIG_SENSORS_PC87427 is not set
# CONFIG_SENSORS_PCF8591 is not set
CONFIG_PMBUS=y
# CONFIG_SENSORS_PMBUS is not set
# CONFIG_SENSORS_ADM1275 is not set
# CONFIG_SENSORS_LM25066 is not set
CONFIG_SENSORS_LTC2978=y
CONFIG_SENSORS_MAX16064=y
CONFIG_SENSORS_MAX34440=y
CONFIG_SENSORS_MAX8688=y
# CONFIG_SENSORS_UCD9000 is not set
# CONFIG_SENSORS_UCD9200 is not set
CONFIG_SENSORS_ZL6100=y
# CONFIG_SENSORS_SHT15 is not set
# CONFIG_SENSORS_SHT21 is not set
CONFIG_SENSORS_SMM665=y
# CONFIG_SENSORS_DME1737 is not set
# CONFIG_SENSORS_EMC1403 is not set
# CONFIG_SENSORS_EMC2103 is not set
# CONFIG_SENSORS_EMC6W201 is not set
# CONFIG_SENSORS_SMSC47M1 is not set
# CONFIG_SENSORS_SMSC47M192 is not set
CONFIG_SENSORS_SMSC47B397=y
# CONFIG_SENSORS_SCH56XX_COMMON is not set
CONFIG_SENSORS_ADS1015=y
CONFIG_SENSORS_ADS7828=y
CONFIG_SENSORS_AMC6821=y
# CONFIG_SENSORS_INA209 is not set
CONFIG_SENSORS_INA2XX=y
CONFIG_SENSORS_THMC50=y
# CONFIG_SENSORS_TMP102 is not set
CONFIG_SENSORS_TMP401=y
CONFIG_SENSORS_TMP421=y
CONFIG_SENSORS_VEXPRESS=y
CONFIG_SENSORS_VT1211=y
# CONFIG_SENSORS_W83781D is not set
CONFIG_SENSORS_W83791D=y
CONFIG_SENSORS_W83792D=y
# CONFIG_SENSORS_W83793 is not set
# CONFIG_SENSORS_W83795 is not set
CONFIG_SENSORS_W83L785TS=y
# CONFIG_SENSORS_W83L786NG is not set
# CONFIG_SENSORS_W83627HF is not set
CONFIG_SENSORS_W83627EHF=y
# CONFIG_SENSORS_WM8350 is not set
# CONFIG_THERMAL is not set
# CONFIG_WATCHDOG is not set
CONFIG_SSB_POSSIBLE=y

#
# Sonics Silicon Backplane
#
CONFIG_SSB=y
CONFIG_SSB_PCMCIAHOST_POSSIBLE=y
# CONFIG_SSB_PCMCIAHOST is not set
CONFIG_SSB_SILENT=y
# CONFIG_SSB_DRIVER_GPIO is not set
CONFIG_BCMA_POSSIBLE=y

#
# Broadcom specific AMBA
#
# CONFIG_BCMA is not set

#
# Multifunction device drivers
#
CONFIG_MFD_CORE=y
CONFIG_MFD_AS3711=y
CONFIG_PMIC_ADP5520=y
CONFIG_MFD_AAT2870_CORE=y
# CONFIG_MFD_CROS_EC is not set
# CONFIG_MFD_ASIC3 is not set
# CONFIG_PMIC_DA903X is not set
# CONFIG_MFD_DA9052_I2C is not set
CONFIG_MFD_DA9055=y
# CONFIG_MFD_MC13XXX_I2C is not set
# CONFIG_HTC_EGPIO is not set
# CONFIG_HTC_PASIC3 is not set
# CONFIG_HTC_I2CPLD is not set
CONFIG_MFD_88PM800=y
CONFIG_MFD_88PM805=y
# CONFIG_MFD_88PM860X is not set
# CONFIG_MFD_MAX77686 is not set
# CONFIG_MFD_MAX77693 is not set
# CONFIG_MFD_MAX8907 is not set
# CONFIG_MFD_MAX8925 is not set
# CONFIG_MFD_MAX8997 is not set
# CONFIG_MFD_MAX8998 is not set
CONFIG_MFD_RETU=y
# CONFIG_MFD_PCF50633 is not set
# CONFIG_MFD_RC5T583 is not set
CONFIG_MFD_SEC_CORE=y
# CONFIG_MFD_SM501 is not set
CONFIG_MFD_SMSC=y
# CONFIG_ABX500_CORE is not set
CONFIG_MFD_STMPE=y

#
# STMicroelectronics STMPE Interface Drivers
#
# CONFIG_STMPE_I2C is not set
CONFIG_MFD_SYSCON=y
# CONFIG_MFD_TI_AM335X_TSCADC is not set
CONFIG_MFD_LP8788=y
CONFIG_MFD_PALMAS=y
CONFIG_TPS6105X=y
# CONFIG_TPS65010 is not set
CONFIG_TPS6507X=y
# CONFIG_MFD_TPS65090 is not set
# CONFIG_MFD_TPS65217 is not set
# CONFIG_MFD_TPS6586X is not set
# CONFIG_MFD_TPS65910 is not set
# CONFIG_MFD_TPS65912 is not set
# CONFIG_MFD_TPS65912_I2C is not set
# CONFIG_MFD_TPS80031 is not set
# CONFIG_TWL4030_CORE is not set
# CONFIG_TWL6040_CORE is not set
CONFIG_MFD_WL1273_CORE=y
# CONFIG_MFD_SI476X_CORE is not set
CONFIG_MFD_LM3533=y
# CONFIG_MFD_TC3589X is not set
CONFIG_MFD_TMIO=y
CONFIG_MFD_T7L66XB=y
# CONFIG_MFD_TC6387XB is not set
# CONFIG_MFD_TC6393XB is not set
# CONFIG_MFD_ARIZONA_I2C is not set
CONFIG_MFD_WM8400=y
# CONFIG_MFD_WM831X_I2C is not set
CONFIG_MFD_WM8350=y
CONFIG_MFD_WM8350_I2C=y
# CONFIG_MFD_WM8994 is not set
CONFIG_VEXPRESS_CONFIG=y
CONFIG_REGULATOR=y
CONFIG_REGULATOR_DEBUG=y
CONFIG_REGULATOR_DUMMY=y
CONFIG_REGULATOR_FIXED_VOLTAGE=y
CONFIG_REGULATOR_VIRTUAL_CONSUMER=y
# CONFIG_REGULATOR_USERSPACE_CONSUMER is not set
# CONFIG_REGULATOR_GPIO is not set
CONFIG_REGULATOR_AD5398=y
CONFIG_REGULATOR_AAT2870=y
CONFIG_REGULATOR_DA9055=y
CONFIG_REGULATOR_FAN53555=y
CONFIG_REGULATOR_ANATOP=y
# CONFIG_REGULATOR_ISL6271A is not set
# CONFIG_REGULATOR_MAX1586 is not set
CONFIG_REGULATOR_MAX8649=y
# CONFIG_REGULATOR_MAX8660 is not set
# CONFIG_REGULATOR_MAX8952 is not set
# CONFIG_REGULATOR_MAX8973 is not set
# CONFIG_REGULATOR_LP3971 is not set
CONFIG_REGULATOR_LP3972=y
# CONFIG_REGULATOR_LP872X is not set
CONFIG_REGULATOR_LP8755=y
CONFIG_REGULATOR_LP8788=y
# CONFIG_REGULATOR_S2MPS11 is not set
# CONFIG_REGULATOR_S5M8767 is not set
# CONFIG_REGULATOR_PALMAS is not set
CONFIG_REGULATOR_TPS51632=y
CONFIG_REGULATOR_TPS6105X=y
CONFIG_REGULATOR_TPS62360=y
CONFIG_REGULATOR_TPS65023=y
# CONFIG_REGULATOR_TPS6507X is not set
CONFIG_REGULATOR_VEXPRESS=y
# CONFIG_REGULATOR_WM8350 is not set
CONFIG_REGULATOR_WM8400=y
CONFIG_REGULATOR_AS3711=y
CONFIG_MEDIA_SUPPORT=y

#
# Multimedia core support
#
# CONFIG_MEDIA_CAMERA_SUPPORT is not set
# CONFIG_MEDIA_ANALOG_TV_SUPPORT is not set
CONFIG_MEDIA_DIGITAL_TV_SUPPORT=y
CONFIG_MEDIA_RADIO_SUPPORT=y
# CONFIG_MEDIA_RC_SUPPORT is not set
CONFIG_VIDEO_DEV=y
CONFIG_VIDEO_V4L2=y
CONFIG_VIDEO_ADV_DEBUG=y
# CONFIG_VIDEO_FIXED_MINOR_RANGES is not set
CONFIG_VIDEO_V4L2_INT_DEVICE=y
CONFIG_DVB_CORE=y
# CONFIG_TTPCI_EEPROM is not set
CONFIG_DVB_MAX_ADAPTERS=8
# CONFIG_DVB_DYNAMIC_MINORS is not set

#
# Media drivers
#

#
# Supported MMC/SDIO adapters
#
# CONFIG_RADIO_ADAPTERS is not set

#
# Media ancillary drivers (tuners, sensors, i2c, frontends)
#
# CONFIG_MEDIA_SUBDRV_AUTOSELECT is not set

#
# Encoders, decoders, sensors and other helper chips
#

#
# Audio decoders, processors and mixers
#
CONFIG_VIDEO_TVAUDIO=y
# CONFIG_VIDEO_TDA7432 is not set
CONFIG_VIDEO_TDA9840=y
CONFIG_VIDEO_TEA6415C=y
# CONFIG_VIDEO_TEA6420 is not set
# CONFIG_VIDEO_MSP3400 is not set
# CONFIG_VIDEO_CS5345 is not set
# CONFIG_VIDEO_CS53L32A is not set
# CONFIG_VIDEO_TLV320AIC23B is not set
# CONFIG_VIDEO_UDA1342 is not set
# CONFIG_VIDEO_WM8775 is not set
# CONFIG_VIDEO_WM8739 is not set
CONFIG_VIDEO_VP27SMPX=y
# CONFIG_VIDEO_SONY_BTF_MPX is not set

#
# RDS decoders
#
# CONFIG_VIDEO_SAA6588 is not set

#
# Video decoders
#
CONFIG_VIDEO_ADV7180=y
CONFIG_VIDEO_ADV7183=y
# CONFIG_VIDEO_BT819 is not set
# CONFIG_VIDEO_BT856 is not set
CONFIG_VIDEO_BT866=y
# CONFIG_VIDEO_KS0127 is not set
CONFIG_VIDEO_SAA7110=y
# CONFIG_VIDEO_SAA711X is not set
# CONFIG_VIDEO_SAA7191 is not set
# CONFIG_VIDEO_TVP514X is not set
CONFIG_VIDEO_TVP5150=y
# CONFIG_VIDEO_TVP7002 is not set
# CONFIG_VIDEO_TW2804 is not set
# CONFIG_VIDEO_TW9903 is not set
# CONFIG_VIDEO_TW9906 is not set
CONFIG_VIDEO_VPX3220=y

#
# Video and audio decoders
#
# CONFIG_VIDEO_SAA717X is not set
CONFIG_VIDEO_CX25840=y

#
# Video encoders
#
CONFIG_VIDEO_SAA7127=y
# CONFIG_VIDEO_SAA7185 is not set
CONFIG_VIDEO_ADV7170=y
CONFIG_VIDEO_ADV7175=y
CONFIG_VIDEO_ADV7343=y
# CONFIG_VIDEO_ADV7393 is not set
CONFIG_VIDEO_AK881X=y

#
# Camera sensor devices
#

#
# Flash devices
#

#
# Video improvement chips
#
# CONFIG_VIDEO_UPD64031A is not set
# CONFIG_VIDEO_UPD64083 is not set

#
# Miscelaneous helper chips
#
CONFIG_VIDEO_THS7303=y
# CONFIG_VIDEO_M52790 is not set

#
# Sensors used on soc_camera driver
#
CONFIG_MEDIA_TUNER=y

#
# Customize TV tuners
#
CONFIG_MEDIA_TUNER_SIMPLE=y
CONFIG_MEDIA_TUNER_TDA8290=y
CONFIG_MEDIA_TUNER_TDA827X=y
CONFIG_MEDIA_TUNER_TDA18271=y
CONFIG_MEDIA_TUNER_TDA9887=y
CONFIG_MEDIA_TUNER_TEA5761=y
# CONFIG_MEDIA_TUNER_TEA5767 is not set
CONFIG_MEDIA_TUNER_MT20XX=y
# CONFIG_MEDIA_TUNER_MT2060 is not set
# CONFIG_MEDIA_TUNER_MT2063 is not set
CONFIG_MEDIA_TUNER_MT2266=y
# CONFIG_MEDIA_TUNER_MT2131 is not set
# CONFIG_MEDIA_TUNER_QT1010 is not set
# CONFIG_MEDIA_TUNER_XC2028 is not set
CONFIG_MEDIA_TUNER_XC5000=y
# CONFIG_MEDIA_TUNER_XC4000 is not set
CONFIG_MEDIA_TUNER_MXL5005S=y
# CONFIG_MEDIA_TUNER_MXL5007T is not set
# CONFIG_MEDIA_TUNER_MC44S803 is not set
CONFIG_MEDIA_TUNER_MAX2165=y
CONFIG_MEDIA_TUNER_TDA18218=y
# CONFIG_MEDIA_TUNER_FC0011 is not set
CONFIG_MEDIA_TUNER_FC0012=y
CONFIG_MEDIA_TUNER_FC0013=y
CONFIG_MEDIA_TUNER_TDA18212=y
# CONFIG_MEDIA_TUNER_E4000 is not set
CONFIG_MEDIA_TUNER_FC2580=y
CONFIG_MEDIA_TUNER_TUA9001=y
CONFIG_MEDIA_TUNER_IT913X=y
# CONFIG_MEDIA_TUNER_R820T is not set

#
# Customise DVB Frontends
#

#
# Multistandard (satellite) frontends
#
CONFIG_DVB_STB0899=y
# CONFIG_DVB_STB6100 is not set
# CONFIG_DVB_STV090x is not set
CONFIG_DVB_STV6110x=y

#
# Multistandard (cable + terrestrial) frontends
#
CONFIG_DVB_DRXK=y
CONFIG_DVB_TDA18271C2DD=y

#
# DVB-S (satellite) frontends
#
# CONFIG_DVB_CX24110 is not set
CONFIG_DVB_CX24123=y
CONFIG_DVB_MT312=y
# CONFIG_DVB_ZL10036 is not set
CONFIG_DVB_ZL10039=y
CONFIG_DVB_S5H1420=y
CONFIG_DVB_STV0288=y
CONFIG_DVB_STB6000=y
CONFIG_DVB_STV0299=y
CONFIG_DVB_STV6110=y
# CONFIG_DVB_STV0900 is not set
CONFIG_DVB_TDA8083=y
# CONFIG_DVB_TDA10086 is not set
# CONFIG_DVB_TDA8261 is not set
CONFIG_DVB_VES1X93=y
CONFIG_DVB_TUNER_ITD1000=y
CONFIG_DVB_TUNER_CX24113=y
CONFIG_DVB_TDA826X=y
# CONFIG_DVB_TUA6100 is not set
CONFIG_DVB_CX24116=y
# CONFIG_DVB_SI21XX is not set
CONFIG_DVB_TS2020=y
# CONFIG_DVB_DS3000 is not set
# CONFIG_DVB_MB86A16 is not set
# CONFIG_DVB_TDA10071 is not set

#
# DVB-T (terrestrial) frontends
#
# CONFIG_DVB_SP8870 is not set
# CONFIG_DVB_SP887X is not set
# CONFIG_DVB_CX22700 is not set
# CONFIG_DVB_CX22702 is not set
CONFIG_DVB_S5H1432=y
# CONFIG_DVB_DRXD is not set
# CONFIG_DVB_L64781 is not set
CONFIG_DVB_TDA1004X=y
CONFIG_DVB_NXT6000=y
CONFIG_DVB_MT352=y
# CONFIG_DVB_ZL10353 is not set
CONFIG_DVB_DIB3000MB=y
CONFIG_DVB_DIB3000MC=y
# CONFIG_DVB_DIB7000M is not set
CONFIG_DVB_DIB7000P=y
# CONFIG_DVB_DIB9000 is not set
# CONFIG_DVB_TDA10048 is not set
# CONFIG_DVB_AF9013 is not set
# CONFIG_DVB_EC100 is not set
CONFIG_DVB_HD29L2=y
# CONFIG_DVB_STV0367 is not set
# CONFIG_DVB_CXD2820R is not set
# CONFIG_DVB_RTL2830 is not set
# CONFIG_DVB_RTL2832 is not set

#
# DVB-C (cable) frontends
#
# CONFIG_DVB_VES1820 is not set
# CONFIG_DVB_TDA10021 is not set
CONFIG_DVB_TDA10023=y
CONFIG_DVB_STV0297=y

#
# ATSC (North American/Korean Terrestrial/Cable DTV) frontends
#
# CONFIG_DVB_NXT200X is not set
# CONFIG_DVB_OR51211 is not set
CONFIG_DVB_OR51132=y
# CONFIG_DVB_BCM3510 is not set
CONFIG_DVB_LGDT330X=y
# CONFIG_DVB_LGDT3305 is not set
# CONFIG_DVB_LG2160 is not set
CONFIG_DVB_S5H1409=y
# CONFIG_DVB_AU8522_DTV is not set
# CONFIG_DVB_AU8522_V4L is not set
CONFIG_DVB_S5H1411=y

#
# ISDB-T (terrestrial) frontends
#
CONFIG_DVB_S921=y
CONFIG_DVB_DIB8000=y
# CONFIG_DVB_MB86A20S is not set

#
# Digital terrestrial only tuners/PLL
#
# CONFIG_DVB_PLL is not set
CONFIG_DVB_TUNER_DIB0070=y
# CONFIG_DVB_TUNER_DIB0090 is not set

#
# SEC control devices for DVB-S
#
CONFIG_DVB_LNBP21=y
# CONFIG_DVB_LNBP22 is not set
# CONFIG_DVB_ISL6405 is not set
# CONFIG_DVB_ISL6421 is not set
CONFIG_DVB_ISL6423=y
# CONFIG_DVB_A8293 is not set
# CONFIG_DVB_LGS8GL5 is not set
# CONFIG_DVB_LGS8GXX is not set
CONFIG_DVB_ATBM8830=y
CONFIG_DVB_TDA665x=y
CONFIG_DVB_IX2505V=y
# CONFIG_DVB_IT913X_FE is not set
# CONFIG_DVB_M88RS2000 is not set
# CONFIG_DVB_AF9033 is not set

#
# Tools to develop new frontends
#
# CONFIG_DVB_DUMMY_FE is not set

#
# Graphics support
#
CONFIG_DRM=y
# CONFIG_DRM_EXYNOS is not set
# CONFIG_DRM_TILCDC is not set
# CONFIG_VGASTATE is not set
# CONFIG_VIDEO_OUTPUT_CONTROL is not set
CONFIG_VIDEOMODE_HELPERS=y
CONFIG_HDMI=y
CONFIG_FB=y
# CONFIG_FIRMWARE_EDID is not set
# CONFIG_FB_DDC is not set
# CONFIG_FB_BOOT_VESA_SUPPORT is not set
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
# CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set
CONFIG_FB_SYS_FILLRECT=y
CONFIG_FB_SYS_COPYAREA=y
CONFIG_FB_SYS_IMAGEBLIT=y
CONFIG_FB_FOREIGN_ENDIAN=y
CONFIG_FB_BOTH_ENDIAN=y
# CONFIG_FB_BIG_ENDIAN is not set
# CONFIG_FB_LITTLE_ENDIAN is not set
CONFIG_FB_SYS_FOPS=y
CONFIG_FB_DEFERRED_IO=y
# CONFIG_FB_SVGALIB is not set
# CONFIG_FB_MACMODES is not set
# CONFIG_FB_BACKLIGHT is not set
CONFIG_FB_MODE_HELPERS=y
# CONFIG_FB_TILEBLITTING is not set

#
# Frame buffer hardware drivers
#
CONFIG_FB_ARMCLCD=y
# CONFIG_FB_S1D13XXX is not set
CONFIG_FB_VT8500=y
# CONFIG_FB_WM8505 is not set
# CONFIG_FB_WMT_GE_ROPS is not set
# CONFIG_FB_TMIO is not set
# CONFIG_FB_GOLDFISH is not set
# CONFIG_FB_VIRTUAL is not set
CONFIG_FB_METRONOME=y
# CONFIG_FB_BROADSHEET is not set
# CONFIG_FB_AUO_K190X is not set
# CONFIG_FB_SIMPLE is not set
# CONFIG_OMAP2_DSS is not set
# CONFIG_EXYNOS_VIDEO is not set
CONFIG_BACKLIGHT_LCD_SUPPORT=y
# CONFIG_LCD_CLASS_DEVICE is not set
CONFIG_BACKLIGHT_CLASS_DEVICE=y
# CONFIG_BACKLIGHT_GENERIC is not set
CONFIG_BACKLIGHT_LM3533=y
CONFIG_BACKLIGHT_PWM=y
# CONFIG_BACKLIGHT_ADP5520 is not set
CONFIG_BACKLIGHT_ADP8860=y
# CONFIG_BACKLIGHT_ADP8870 is not set
# CONFIG_BACKLIGHT_AAT2870 is not set
# CONFIG_BACKLIGHT_LM3630 is not set
# CONFIG_BACKLIGHT_LM3639 is not set
# CONFIG_BACKLIGHT_LP855X is not set
# CONFIG_BACKLIGHT_LP8788 is not set
# CONFIG_BACKLIGHT_AS3711 is not set

#
# Console display driver support
#
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
# CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY is not set
CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y
CONFIG_FONTS=y
CONFIG_FONT_8x8=y
# CONFIG_FONT_8x16 is not set
# CONFIG_FONT_6x11 is not set
CONFIG_FONT_7x14=y
CONFIG_FONT_PEARL_8x8=y
# CONFIG_FONT_ACORN_8x8 is not set
# CONFIG_FONT_MINI_4x6 is not set
CONFIG_FONT_SUN8x16=y
CONFIG_FONT_SUN12x22=y
CONFIG_FONT_10x18=y
CONFIG_LOGO=y
CONFIG_LOGO_LINUX_MONO=y
CONFIG_LOGO_LINUX_VGA16=y
# CONFIG_LOGO_LINUX_CLUT224 is not set
# CONFIG_FB_SSD1307 is not set
# CONFIG_SOUND is not set

#
# HID support
#
CONFIG_HID=y
CONFIG_HID_BATTERY_STRENGTH=y
CONFIG_HIDRAW=y
CONFIG_UHID=y
# CONFIG_HID_GENERIC is not set

#
# Special HID drivers
#
CONFIG_HID_A4TECH=y
CONFIG_HID_ACRUX=y
CONFIG_HID_ACRUX_FF=y
CONFIG_HID_APPLE=y
# CONFIG_HID_AUREAL is not set
CONFIG_HID_BELKIN=y
CONFIG_HID_CHERRY=y
CONFIG_HID_CHICONY=y
CONFIG_HID_CYPRESS=y
CONFIG_HID_DRAGONRISE=y
# CONFIG_DRAGONRISE_FF is not set
# CONFIG_HID_EMS_FF is not set
# CONFIG_HID_ELECOM is not set
# CONFIG_HID_EZKEY is not set
CONFIG_HID_KEYTOUCH=y
CONFIG_HID_KYE=y
# CONFIG_HID_UCLOGIC is not set
# CONFIG_HID_WALTOP is not set
# CONFIG_HID_GYRATION is not set
CONFIG_HID_ICADE=y
CONFIG_HID_TWINHAN=y
# CONFIG_HID_KENSINGTON is not set
# CONFIG_HID_LCPOWER is not set
# CONFIG_HID_LOGITECH is not set
# CONFIG_HID_MAGICMOUSE is not set
# CONFIG_HID_MICROSOFT is not set
# CONFIG_HID_MONTEREY is not set
CONFIG_HID_MULTITOUCH=y
# CONFIG_HID_ORTEK is not set
# CONFIG_HID_PANTHERLORD is not set
# CONFIG_HID_PETALYNX is not set
CONFIG_HID_PICOLCD=y
# CONFIG_HID_PICOLCD_FB is not set
CONFIG_HID_PICOLCD_BACKLIGHT=y
# CONFIG_HID_PICOLCD_LEDS is not set
# CONFIG_HID_PRIMAX is not set
# CONFIG_HID_PS3REMOTE is not set
CONFIG_HID_SAITEK=y
CONFIG_HID_SAMSUNG=y
# CONFIG_HID_SPEEDLINK is not set
# CONFIG_HID_STEELSERIES is not set
CONFIG_HID_SUNPLUS=y
CONFIG_HID_GREENASIA=y
CONFIG_GREENASIA_FF=y
# CONFIG_HID_SMARTJOYPLUS is not set
CONFIG_HID_TIVO=y
CONFIG_HID_TOPSEED=y
# CONFIG_HID_THINGM is not set
CONFIG_HID_THRUSTMASTER=y
# CONFIG_THRUSTMASTER_FF is not set
CONFIG_HID_WACOM=y
CONFIG_HID_WIIMOTE=y
CONFIG_HID_WIIMOTE_EXT=y
# CONFIG_HID_ZEROPLUS is not set
CONFIG_HID_ZYDACRON=y
CONFIG_HID_SENSOR_HUB=y

#
# I2C HID support
#
CONFIG_I2C_HID=y
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB_ARCH_HAS_EHCI=y
# CONFIG_USB_ARCH_HAS_XHCI is not set
# CONFIG_USB_SUPPORT is not set
# CONFIG_MMC is not set
# CONFIG_MEMSTICK is not set
CONFIG_NEW_LEDS=y
CONFIG_LEDS_CLASS=y

#
# LED drivers
#
CONFIG_LEDS_LM3530=y
CONFIG_LEDS_LM3533=y
CONFIG_LEDS_LM3642=y
# CONFIG_LEDS_PCA9532 is not set
# CONFIG_LEDS_GPIO is not set
# CONFIG_LEDS_LP3944 is not set
CONFIG_LEDS_LP55XX_COMMON=y
# CONFIG_LEDS_LP5521 is not set
# CONFIG_LEDS_LP5523 is not set
CONFIG_LEDS_LP5562=y
CONFIG_LEDS_LP8788=y
CONFIG_LEDS_PCA955X=y
CONFIG_LEDS_PCA9633=y
CONFIG_LEDS_WM8350=y
# CONFIG_LEDS_PWM is not set
CONFIG_LEDS_REGULATOR=y
CONFIG_LEDS_BD2802=y
CONFIG_LEDS_LT3593=y
# CONFIG_LEDS_ADP5520 is not set
CONFIG_LEDS_RENESAS_TPU=y
CONFIG_LEDS_TCA6507=y
# CONFIG_LEDS_LM355x is not set
CONFIG_LEDS_OT200=y
# CONFIG_LEDS_BLINKM is not set

#
# LED Triggers
#
CONFIG_LEDS_TRIGGERS=y
CONFIG_LEDS_TRIGGER_TIMER=y
# CONFIG_LEDS_TRIGGER_ONESHOT is not set
# CONFIG_LEDS_TRIGGER_HEARTBEAT is not set
CONFIG_LEDS_TRIGGER_BACKLIGHT=y
# CONFIG_LEDS_TRIGGER_CPU is not set
CONFIG_LEDS_TRIGGER_GPIO=y
CONFIG_LEDS_TRIGGER_DEFAULT_ON=y

#
# iptables trigger is under Netfilter config (LED target)
#
# CONFIG_LEDS_TRIGGER_TRANSIENT is not set
CONFIG_LEDS_TRIGGER_CAMERA=y
# CONFIG_ACCESSIBILITY is not set
# CONFIG_EDAC is not set
CONFIG_RTC_LIB=y
# CONFIG_RTC_CLASS is not set
# CONFIG_DMADEVICES is not set
# CONFIG_AUXDISPLAY is not set
# CONFIG_UIO is not set
# CONFIG_VIRT_DRIVERS is not set
CONFIG_VIRTIO=y

#
# Virtio drivers
#
CONFIG_VIRTIO_BALLOON=y
CONFIG_VIRTIO_MMIO=y
# CONFIG_VIRTIO_MMIO_CMDLINE_DEVICES is not set

#
# Microsoft Hyper-V guest support
#
# CONFIG_STAGING is not set
CONFIG_CLKDEV_LOOKUP=y
CONFIG_HAVE_CLK_PREPARE=y
CONFIG_COMMON_CLK=y

#
# Common Clock Framework
#
# CONFIG_COMMON_CLK_DEBUG is not set
CONFIG_COMMON_CLK_VERSATILE=y
# CONFIG_COMMON_CLK_SI5351 is not set
CONFIG_COMMON_CLK_AXI_CLKGEN=y
CONFIG_MVEBU_CLK_CORE=y
CONFIG_MVEBU_CLK_CPU=y
CONFIG_MVEBU_CLK_GATING=y
CONFIG_HWSPINLOCK=y

#
# Hardware Spinlock drivers
#
CONFIG_HWSPINLOCK_OMAP=y
CONFIG_CLKSRC_OF=y
CONFIG_CLKSRC_MMIO=y
CONFIG_DW_APB_TIMER=y
CONFIG_DW_APB_TIMER_OF=y
CONFIG_ARMADA_370_XP_TIMER=y
CONFIG_VT8500_TIMER=y
CONFIG_CADENCE_TTC_TIMER=y
CONFIG_ARM_ARCH_TIMER=y
CONFIG_MAILBOX=y
CONFIG_PL320_MBOX=y
CONFIG_OMAP2PLUS_MBOX=y
CONFIG_MBOX_KFIFO_SIZE=256
CONFIG_MBOX_DATA_SIZE=4
# CONFIG_IOMMU_SUPPORT is not set

#
# Remoteproc drivers
#
# CONFIG_STE_MODEM_RPROC is not set

#
# Rpmsg drivers
#
# CONFIG_PM_DEVFREQ is not set
# CONFIG_EXTCON is not set
# CONFIG_MEMORY is not set
CONFIG_IIO=y
CONFIG_IIO_BUFFER=y
# CONFIG_IIO_BUFFER_CB is not set
CONFIG_IIO_KFIFO_BUF=y
CONFIG_IIO_TRIGGERED_BUFFER=y
CONFIG_IIO_TRIGGER=y
CONFIG_IIO_CONSUMERS_PER_TRIGGER=2

#
# Accelerometers
#
CONFIG_HID_SENSOR_ACCEL_3D=y
CONFIG_IIO_ST_ACCEL_3AXIS=y
CONFIG_IIO_ST_ACCEL_I2C_3AXIS=y

#
# Analog to digital converters
#
# CONFIG_EXYNOS_ADC is not set
CONFIG_LP8788_ADC=y
# CONFIG_MAX1363 is not set
CONFIG_TI_ADC081C=y

#
# Amplifiers
#

#
# Hid Sensor IIO Common
#
CONFIG_HID_SENSOR_IIO_COMMON=y
CONFIG_HID_SENSOR_IIO_TRIGGER=y
CONFIG_HID_SENSOR_ENUM_BASE_QUIRKS=y
CONFIG_IIO_ST_SENSORS_I2C=y
CONFIG_IIO_ST_SENSORS_CORE=y

#
# Digital to analog converters
#
CONFIG_AD5064=y
CONFIG_AD5380=y
CONFIG_AD5446=y
# CONFIG_MAX517 is not set
CONFIG_MCP4725=y

#
# Frequency Synthesizers DDS/PLL
#

#
# Clock Generator/Distribution
#

#
# Phase-Locked Loop (PLL) frequency synthesizers
#

#
# Digital gyroscope sensors
#
CONFIG_HID_SENSOR_GYRO_3D=y
CONFIG_IIO_ST_GYRO_3AXIS=y
CONFIG_IIO_ST_GYRO_I2C_3AXIS=y
# CONFIG_ITG3200 is not set

#
# Inertial measurement units
#
# CONFIG_INV_MPU6050_IIO is not set

#
# Light sensors
#
# CONFIG_ADJD_S311 is not set
CONFIG_SENSORS_LM3533=y
CONFIG_SENSORS_TSL2563=y
CONFIG_VCNL4000=y
# CONFIG_HID_SENSOR_ALS is not set

#
# Magnetometer sensors
#
# CONFIG_AK8975 is not set
# CONFIG_HID_SENSOR_MAGNETOMETER_3D is not set
# CONFIG_IIO_ST_MAGN_3AXIS is not set
CONFIG_PWM=y
CONFIG_PWM_VT8500=y
CONFIG_IRQCHIP=y
CONFIG_ARM_GIC=y
CONFIG_IPACK_BUS=y
# CONFIG_SERIAL_IPOCTAL is not set
CONFIG_RESET_CONTROLLER=y

#
# File systems
#
CONFIG_DCACHE_WORD_ACCESS=y
# CONFIG_EXT2_FS is not set
# CONFIG_EXT3_FS is not set
# CONFIG_EXT4_FS is not set
# CONFIG_REISERFS_FS is not set
CONFIG_JFS_FS=y
# CONFIG_JFS_POSIX_ACL is not set
CONFIG_JFS_SECURITY=y
CONFIG_JFS_DEBUG=y
# CONFIG_JFS_STATISTICS is not set
CONFIG_XFS_FS=y
# CONFIG_XFS_QUOTA is not set
CONFIG_XFS_POSIX_ACL=y
# CONFIG_XFS_RT is not set
# CONFIG_XFS_DEBUG is not set
CONFIG_GFS2_FS=y
CONFIG_BTRFS_FS=y
# CONFIG_BTRFS_FS_POSIX_ACL is not set
CONFIG_BTRFS_FS_CHECK_INTEGRITY=y
CONFIG_NILFS2_FS=y
CONFIG_FS_POSIX_ACL=y
CONFIG_EXPORTFS=y
CONFIG_FILE_LOCKING=y
CONFIG_FSNOTIFY=y
# CONFIG_DNOTIFY is not set
CONFIG_INOTIFY_USER=y
# CONFIG_FANOTIFY is not set
# CONFIG_QUOTA is not set
CONFIG_QUOTACTL=y
# CONFIG_AUTOFS4_FS is not set
CONFIG_FUSE_FS=y
CONFIG_CUSE=y

#
# Caches
#
CONFIG_FSCACHE=y
CONFIG_FSCACHE_STATS=y
CONFIG_FSCACHE_HISTOGRAM=y
CONFIG_FSCACHE_DEBUG=y
# CONFIG_FSCACHE_OBJECT_LIST is not set
CONFIG_CACHEFILES=y
# CONFIG_CACHEFILES_DEBUG is not set
# CONFIG_CACHEFILES_HISTOGRAM is not set

#
# CD-ROM/DVD Filesystems
#
# CONFIG_ISO9660_FS is not set
# CONFIG_UDF_FS is not set

#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=y
# CONFIG_VFAT_FS is not set
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_NTFS_FS=y
# CONFIG_NTFS_DEBUG is not set
# CONFIG_NTFS_RW is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_SYSCTL=y
# CONFIG_PROC_PAGE_MONITOR is not set
CONFIG_SYSFS=y
# CONFIG_HUGETLB_PAGE is not set
CONFIG_CONFIGFS_FS=y
CONFIG_MISC_FILESYSTEMS=y
# CONFIG_ADFS_FS is not set
CONFIG_AFFS_FS=y
# CONFIG_HFS_FS is not set
CONFIG_HFSPLUS_FS=y
CONFIG_BEFS_FS=y
CONFIG_BEFS_DEBUG=y
# CONFIG_BFS_FS is not set
CONFIG_EFS_FS=y
# CONFIG_JFFS2_FS is not set
CONFIG_UBIFS_FS=y
# CONFIG_UBIFS_FS_ADVANCED_COMPR is not set
CONFIG_UBIFS_FS_LZO=y
CONFIG_UBIFS_FS_ZLIB=y
CONFIG_LOGFS=y
CONFIG_CRAMFS=y
CONFIG_SQUASHFS=y
CONFIG_SQUASHFS_XATTR=y
CONFIG_SQUASHFS_ZLIB=y
# CONFIG_SQUASHFS_LZO is not set
# CONFIG_SQUASHFS_XZ is not set
CONFIG_SQUASHFS_4K_DEVBLK_SIZE=y
CONFIG_SQUASHFS_EMBEDDED=y
CONFIG_SQUASHFS_FRAGMENT_CACHE_SIZE=3
CONFIG_VXFS_FS=y
CONFIG_MINIX_FS=y
CONFIG_OMFS_FS=y
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_QNX6FS_FS is not set
# CONFIG_ROMFS_FS is not set
CONFIG_PSTORE=y
CONFIG_PSTORE_CONSOLE=y
CONFIG_PSTORE_RAM=y
# CONFIG_SYSV_FS is not set
CONFIG_UFS_FS=y
# CONFIG_UFS_FS_WRITE is not set
CONFIG_UFS_DEBUG=y
# CONFIG_EXOFS_FS is not set
# CONFIG_F2FS_FS is not set
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
# CONFIG_NLS_CODEPAGE_437 is not set
# CONFIG_NLS_CODEPAGE_737 is not set
CONFIG_NLS_CODEPAGE_775=y
CONFIG_NLS_CODEPAGE_850=y
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
CONFIG_NLS_CODEPAGE_865=y
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
CONFIG_NLS_CODEPAGE_949=y
# CONFIG_NLS_CODEPAGE_874 is not set
CONFIG_NLS_ISO8859_8=y
CONFIG_NLS_CODEPAGE_1250=y
CONFIG_NLS_CODEPAGE_1251=y
CONFIG_NLS_ASCII=y
# CONFIG_NLS_ISO8859_1 is not set
CONFIG_NLS_ISO8859_2=y
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
CONFIG_NLS_ISO8859_5=y
CONFIG_NLS_ISO8859_6=y
CONFIG_NLS_ISO8859_7=y
# CONFIG_NLS_ISO8859_9 is not set
CONFIG_NLS_ISO8859_13=y
# CONFIG_NLS_ISO8859_14 is not set
CONFIG_NLS_ISO8859_15=y
CONFIG_NLS_KOI8_R=y
CONFIG_NLS_KOI8_U=y
CONFIG_NLS_MAC_ROMAN=y
CONFIG_NLS_MAC_CELTIC=y
# CONFIG_NLS_MAC_CENTEURO is not set
CONFIG_NLS_MAC_CROATIAN=y
# CONFIG_NLS_MAC_CYRILLIC is not set
# CONFIG_NLS_MAC_GAELIC is not set
CONFIG_NLS_MAC_GREEK=y
# CONFIG_NLS_MAC_ICELAND is not set
CONFIG_NLS_MAC_INUIT=y
CONFIG_NLS_MAC_ROMANIAN=y
# CONFIG_NLS_MAC_TURKISH is not set
CONFIG_NLS_UTF8=y

#
# Kernel hacking
#
# CONFIG_PRINTK_TIME is not set
CONFIG_DEFAULT_MESSAGE_LOGLEVEL=4
CONFIG_ENABLE_WARN_DEPRECATED=y
# CONFIG_ENABLE_MUST_CHECK is not set
CONFIG_FRAME_WARN=1024
CONFIG_MAGIC_SYSRQ=y
# CONFIG_STRIP_ASM_SYMS is not set
# CONFIG_READABLE_ASM is not set
CONFIG_UNUSED_SYMBOLS=y
CONFIG_DEBUG_FS=y
# CONFIG_HEADERS_CHECK is not set
CONFIG_DEBUG_SECTION_MISMATCH=y
CONFIG_DEBUG_KERNEL=y
CONFIG_DEBUG_SHIRQ=y
CONFIG_LOCKUP_DETECTOR=y
# CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC is not set
CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC_VALUE=0
# CONFIG_PANIC_ON_OOPS is not set
CONFIG_PANIC_ON_OOPS_VALUE=0
# CONFIG_DETECT_HUNG_TASK is not set
# CONFIG_SCHED_DEBUG is not set
CONFIG_SCHEDSTATS=y
# CONFIG_TIMER_STATS is not set
CONFIG_DEBUG_OBJECTS=y
CONFIG_DEBUG_OBJECTS_SELFTEST=y
CONFIG_DEBUG_OBJECTS_FREE=y
# CONFIG_DEBUG_OBJECTS_TIMERS is not set
# CONFIG_DEBUG_OBJECTS_WORK is not set
CONFIG_DEBUG_OBJECTS_RCU_HEAD=y
CONFIG_DEBUG_OBJECTS_PERCPU_COUNTER=y
CONFIG_DEBUG_OBJECTS_ENABLE_DEFAULT=1
# CONFIG_SLUB_DEBUG_ON is not set
# CONFIG_SLUB_STATS is not set
CONFIG_HAVE_DEBUG_KMEMLEAK=y
# CONFIG_DEBUG_KMEMLEAK is not set
CONFIG_DEBUG_RT_MUTEXES=y
CONFIG_DEBUG_PI_LIST=y
# CONFIG_RT_MUTEX_TESTER is not set
CONFIG_DEBUG_SPINLOCK=y
CONFIG_DEBUG_MUTEXES=y
CONFIG_DEBUG_LOCK_ALLOC=y
CONFIG_PROVE_LOCKING=y
CONFIG_LOCKDEP=y
CONFIG_LOCK_STAT=y
# CONFIG_DEBUG_LOCKDEP is not set
CONFIG_TRACE_IRQFLAGS=y
# CONFIG_DEBUG_ATOMIC_SLEEP is not set
CONFIG_DEBUG_LOCKING_API_SELFTESTS=y
CONFIG_STACKTRACE=y
# CONFIG_DEBUG_STACK_USAGE is not set
CONFIG_DEBUG_KOBJECT=y
# CONFIG_DEBUG_HIGHMEM is not set
# CONFIG_DEBUG_BUGVERBOSE is not set
CONFIG_DEBUG_INFO=y
CONFIG_DEBUG_INFO_REDUCED=y
CONFIG_DEBUG_VM=y
CONFIG_DEBUG_VM_RB=y
# CONFIG_DEBUG_WRITECOUNT is not set
# CONFIG_DEBUG_MEMORY_INIT is not set
# CONFIG_DEBUG_LIST is not set
CONFIG_TEST_LIST_SORT=y
CONFIG_DEBUG_SG=y
CONFIG_DEBUG_NOTIFIERS=y
CONFIG_DEBUG_CREDENTIALS=y
CONFIG_FRAME_POINTER=y
CONFIG_BOOT_PRINTK_DELAY=y

#
# RCU Debugging
#
# CONFIG_PROVE_RCU is not set
CONFIG_SPARSE_RCU_POINTER=y
# CONFIG_RCU_TORTURE_TEST is not set
CONFIG_RCU_CPU_STALL_TIMEOUT=21
CONFIG_RCU_TRACE=y
CONFIG_BACKTRACE_SELF_TEST=y
CONFIG_DEBUG_BLOCK_EXT_DEVT=y
CONFIG_DEBUG_FORCE_WEAK_PER_CPU=y
CONFIG_LKDTM=y
# CONFIG_NOTIFIER_ERROR_INJECTION is not set
# CONFIG_FAULT_INJECTION is not set
# CONFIG_LATENCYTOP is not set
CONFIG_DEBUG_PAGEALLOC=y
CONFIG_WANT_PAGE_DEBUG_FLAGS=y
CONFIG_PAGE_POISONING=y
CONFIG_NOP_TRACER=y
CONFIG_HAVE_FUNCTION_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y
CONFIG_HAVE_DYNAMIC_FTRACE=y
CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y
CONFIG_HAVE_SYSCALL_TRACEPOINTS=y
CONFIG_HAVE_C_RECORDMCOUNT=y
CONFIG_TRACER_MAX_TRACE=y
CONFIG_TRACE_CLOCK=y
CONFIG_RING_BUFFER=y
CONFIG_EVENT_TRACING=y
CONFIG_CONTEXT_SWITCH_TRACER=y
CONFIG_RING_BUFFER_ALLOW_SWAP=y
CONFIG_TRACING=y
CONFIG_GENERIC_TRACER=y
CONFIG_TRACING_SUPPORT=y
CONFIG_FTRACE=y
# CONFIG_FUNCTION_TRACER is not set
CONFIG_IRQSOFF_TRACER=y
# CONFIG_SCHED_TRACER is not set
CONFIG_FTRACE_SYSCALLS=y
CONFIG_TRACER_SNAPSHOT=y
CONFIG_TRACER_SNAPSHOT_PER_CPU_SWAP=y
CONFIG_BRANCH_PROFILE_NONE=y
# CONFIG_PROFILE_ANNOTATED_BRANCHES is not set
# CONFIG_PROFILE_ALL_BRANCHES is not set
# CONFIG_STACK_TRACER is not set
# CONFIG_BLK_DEV_IO_TRACE is not set
# CONFIG_PROBE_EVENTS is not set
CONFIG_FTRACE_SELFTEST=y
CONFIG_FTRACE_STARTUP_TEST=y
# CONFIG_EVENT_TRACE_TEST_SYSCALLS is not set
# CONFIG_RING_BUFFER_BENCHMARK is not set
# CONFIG_RING_BUFFER_STARTUP_TEST is not set
# CONFIG_DYNAMIC_DEBUG is not set
CONFIG_DMA_API_DEBUG=y
CONFIG_ATOMIC64_SELFTEST=y
CONFIG_ASYNC_RAID6_TEST=y
# CONFIG_SAMPLES is not set
CONFIG_HAVE_ARCH_KGDB=y
# CONFIG_KGDB is not set
CONFIG_TEST_STRING_HELPERS=y
# CONFIG_TEST_KSTRTOX is not set
# CONFIG_STRICT_DEVMEM is not set
CONFIG_DEBUG_USER=y
# CONFIG_DEBUG_LL is not set
CONFIG_DEBUG_LL_INCLUDE="mach/debug-macro.S"
CONFIG_UNCOMPRESS_INCLUDE="debug/uncompress.h"
CONFIG_OC_ETM=y
CONFIG_PID_IN_CONTEXTIDR=y

#
# Security options
#
# CONFIG_KEYS is not set
# CONFIG_SECURITY_DMESG_RESTRICT is not set
CONFIG_SECURITY=y
CONFIG_SECURITYFS=y
# CONFIG_SECURITY_NETWORK is not set
CONFIG_SECURITY_PATH=y
CONFIG_SECURITY_YAMA=y
CONFIG_SECURITY_YAMA_STACKED=y
CONFIG_INTEGRITY=y
CONFIG_IMA=y
CONFIG_IMA_MEASURE_PCR_IDX=10
CONFIG_IMA_APPRAISE=y
CONFIG_DEFAULT_SECURITY_YAMA=y
# CONFIG_DEFAULT_SECURITY_DAC is not set
CONFIG_DEFAULT_SECURITY="yama"
CONFIG_XOR_BLOCKS=y
CONFIG_ASYNC_CORE=y
CONFIG_ASYNC_MEMCPY=y
CONFIG_ASYNC_XOR=y
CONFIG_ASYNC_PQ=y
CONFIG_ASYNC_RAID6_RECOV=y
CONFIG_CRYPTO=y

#
# Crypto core or helper
#
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_ALGAPI2=y
CONFIG_CRYPTO_AEAD=y
CONFIG_CRYPTO_AEAD2=y
CONFIG_CRYPTO_BLKCIPHER=y
CONFIG_CRYPTO_BLKCIPHER2=y
CONFIG_CRYPTO_HASH=y
CONFIG_CRYPTO_HASH2=y
CONFIG_CRYPTO_RNG=y
CONFIG_CRYPTO_RNG2=y
CONFIG_CRYPTO_PCOMP=y
CONFIG_CRYPTO_PCOMP2=y
CONFIG_CRYPTO_MANAGER=y
CONFIG_CRYPTO_MANAGER2=y
CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=y
CONFIG_CRYPTO_GF128MUL=y
# CONFIG_CRYPTO_NULL is not set
CONFIG_CRYPTO_WORKQUEUE=y
# CONFIG_CRYPTO_CRYPTD is not set
# CONFIG_CRYPTO_AUTHENC is not set

#
# Authenticated Encryption with Associated Data
#
CONFIG_CRYPTO_CCM=y
# CONFIG_CRYPTO_GCM is not set
CONFIG_CRYPTO_SEQIV=y

#
# Block modes
#
CONFIG_CRYPTO_CBC=y
CONFIG_CRYPTO_CTR=y
# CONFIG_CRYPTO_CTS is not set
CONFIG_CRYPTO_ECB=y
# CONFIG_CRYPTO_LRW is not set
# CONFIG_CRYPTO_PCBC is not set
# CONFIG_CRYPTO_XTS is not set

#
# Hash modes
#
CONFIG_CRYPTO_CMAC=y
CONFIG_CRYPTO_HMAC=y
CONFIG_CRYPTO_XCBC=y
# CONFIG_CRYPTO_VMAC is not set

#
# Digest
#
CONFIG_CRYPTO_CRC32C=y
# CONFIG_CRYPTO_CRC32 is not set
CONFIG_CRYPTO_GHASH=y
# CONFIG_CRYPTO_MD4 is not set
CONFIG_CRYPTO_MD5=y
CONFIG_CRYPTO_MICHAEL_MIC=y
# CONFIG_CRYPTO_RMD128 is not set
# CONFIG_CRYPTO_RMD160 is not set
CONFIG_CRYPTO_RMD256=y
# CONFIG_CRYPTO_RMD320 is not set
CONFIG_CRYPTO_SHA1=y
CONFIG_CRYPTO_SHA1_ARM=y
# CONFIG_CRYPTO_SHA256 is not set
# CONFIG_CRYPTO_SHA512 is not set
# CONFIG_CRYPTO_TGR192 is not set
CONFIG_CRYPTO_WP512=y

#
# Ciphers
#
CONFIG_CRYPTO_AES=y
# CONFIG_CRYPTO_AES_ARM is not set
CONFIG_CRYPTO_ANUBIS=y
# CONFIG_CRYPTO_ARC4 is not set
CONFIG_CRYPTO_BLOWFISH=y
CONFIG_CRYPTO_BLOWFISH_COMMON=y
# CONFIG_CRYPTO_CAMELLIA is not set
CONFIG_CRYPTO_CAST_COMMON=y
CONFIG_CRYPTO_CAST5=y
# CONFIG_CRYPTO_CAST6 is not set
# CONFIG_CRYPTO_DES is not set
# CONFIG_CRYPTO_FCRYPT is not set
CONFIG_CRYPTO_KHAZAD=y
# CONFIG_CRYPTO_SALSA20 is not set
CONFIG_CRYPTO_SEED=y
CONFIG_CRYPTO_SERPENT=y
# CONFIG_CRYPTO_TEA is not set
CONFIG_CRYPTO_TWOFISH=y
CONFIG_CRYPTO_TWOFISH_COMMON=y

#
# Compression
#
CONFIG_CRYPTO_DEFLATE=y
CONFIG_CRYPTO_ZLIB=y
CONFIG_CRYPTO_LZO=y
CONFIG_CRYPTO_LZ4=y
CONFIG_CRYPTO_LZ4HC=y

#
# Random Number Generation
#
# CONFIG_CRYPTO_ANSI_CPRNG is not set
CONFIG_CRYPTO_HW=y
CONFIG_CRYPTO_DEV_MV_CESA=y
CONFIG_BINARY_PRINTF=y

#
# Library routines
#
CONFIG_RAID6_PQ=y
CONFIG_BITREVERSE=y
CONFIG_GENERIC_STRNCPY_FROM_USER=y
CONFIG_GENERIC_STRNLEN_USER=y
CONFIG_GENERIC_PCI_IOMAP=y
CONFIG_GENERIC_IO=y
# CONFIG_CRC_CCITT is not set
CONFIG_CRC16=y
# CONFIG_CRC_T10DIF is not set
CONFIG_CRC_ITU_T=y
CONFIG_CRC32=y
# CONFIG_CRC32_SELFTEST is not set
CONFIG_CRC32_SLICEBY8=y
# CONFIG_CRC32_SLICEBY4 is not set
# CONFIG_CRC32_SARWATE is not set
# CONFIG_CRC32_BIT is not set
CONFIG_CRC7=y
CONFIG_LIBCRC32C=y
# CONFIG_CRC8 is not set
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
CONFIG_LZO_COMPRESS=y
CONFIG_LZO_DECOMPRESS=y
CONFIG_LZ4_COMPRESS=y
CONFIG_LZ4HC_COMPRESS=y
CONFIG_LZ4_DECOMPRESS=y
# CONFIG_XZ_DEC is not set
# CONFIG_XZ_DEC_BCJ is not set
CONFIG_DECOMPRESS_GZIP=y
CONFIG_DECOMPRESS_LZO=y
CONFIG_GENERIC_ALLOCATOR=y
CONFIG_REED_SOLOMON=y
CONFIG_REED_SOLOMON_ENC8=y
CONFIG_REED_SOLOMON_DEC8=y
CONFIG_REED_SOLOMON_DEC16=y
CONFIG_BTREE=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_DMA=y
CONFIG_NLATTR=y
CONFIG_GENERIC_ATOMIC64=y
CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE=y
CONFIG_AVERAGE=y
CONFIG_CORDIC=y
CONFIG_DDR=y
# CONFIG_VIRTUALIZATION is not set

From jason at lakedaemon.net  Mon Apr 22 19:02:51 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Mon, 22 Apr 2013 19:02:51 -0400
Subject: [PATCH v8 0/3] of/pci: Provide common support for PCI DT parsing
In-Reply-To: <20130422165343.GE25724@titan.lakedaemon.net>
References: <1366627295-16964-1-git-send-email-Andrew.Murray@arm.com>
 <20130422165343.GE25724@titan.lakedaemon.net>
Message-ID: <20130422230251.GL25724@titan.lakedaemon.net>

On Mon, Apr 22, 2013 at 12:53:43PM -0400, Jason Cooper wrote:
> On Mon, Apr 22, 2013 at 11:41:32AM +0100, Andrew Murray wrote:
> > This patchset factors out duplicated code associated with parsing PCI
> > DT "ranges" properties across the architectures and introduces a
> > "ranges" parser. This parser "of_pci_range_parser" can be used directly
> > by ARM host bridge drivers enabling them to obtain ranges from device
> > trees.
> > 
> > I've included the Reviewed-by, Tested-by and Acked-by's received from v5/v6/v7
> > in this patchset, earlier versions of this patchset (v3) have been tested-by:
> > 
> > Thierry Reding <thierry.reding at avionic-design.de>
> > Jingoo Han <jg1.han at samsung.com>
> > 
> > I've tested that this patchset builds and runs on ARM and that it builds on
> > PowerPC, x86_64 and MIPS.
> 
> Andrew,
> 
> Unfortunately, the mvebu/drivers branch containing your series had to be
> dropped from arm-soc for v3.10.  This was not due to your series, but
> since arm-soc's granularity is branches, your series was caught in the
> drop.
> 
> As the mvebu-pcie driver is now v3.11 material, I have taken the
> opportunity to upgrade from your v7 patchset to v8.  You can find the
> whole branch at mvebu-next/pcie.
> 
> mvebu-next/pcie *will* be rebased onto v3.9 once it drops.  Several
> dependencies will be removed (since they will have been merged into
> v3.9).

s/v3.9/v3.10-rc1/g  :)

> Once the rebase is done, I'll send a pull request to Arnd and Olof so we
> can get as many cycles on -next as possible.

thx,

Jason.


From marex at denx.de  Mon Apr 22 19:57:47 2013
From: marex at denx.de (Marek Vasut)
Date: Tue, 23 Apr 2013 01:57:47 +0200
Subject: [RFC][PATCH] video: imx: Select VIDEOMODE_HELPERS
In-Reply-To: <CAOMZO5Av8RyptoxAQ13Psxjjd4nhHVbEJoVm6SqyLr55bPmSng@mail.gmail.com>
References: <1366666110-9585-1-git-send-email-marex@denx.de>
 <CAOMZO5Av8RyptoxAQ13Psxjjd4nhHVbEJoVm6SqyLr55bPmSng@mail.gmail.com>
Message-ID: <201304230157.47992.marex@denx.de>

Dear Fabio Estevam,

> Hi Marek,
> 
> On Mon, Apr 22, 2013 at 6:28 PM, Marek Vasut <marex at denx.de> wrote:
> > Without this, I get the following problem when building kernel:
> > 
> > drivers/built-in.o: In function `imx_pd_connector_get_modes':
> > /linux-2.6/drivers/staging/imx-drm/parallel-display.c:78: undefined
> > reference to `of_get_drm_display_mode' make: *** [vmlinux] Error 1
> > 
> > NOTE: I think this patch is almost absolutely not correct.
> > 
> > Signed-off-by: Marek Vasut <marex at denx.de>
> > Cc: Sascha Hauer <s.hauer at pengutronix.de>
> > Cc: Philipp Zabel <p.zabel at pengutronix.de>
> > Cc: Fabio Estevam <fabio.estevam at freescale.com>
> 
> Patch looks good, but you should have copied Greg Kroah-Hartman, as he
> is the one who takes patches into staging.

I'm not sure if the select is at correct symbol, I dont think it is.

Best regards,
Marek Vasut


From horms at verge.net.au  Mon Apr 22 21:15:25 2013
From: horms at verge.net.au (Simon Horman)
Date: Tue, 23 Apr 2013 10:15:25 +0900
Subject: [PATCH] ARM: shmobile: lager: Add GPIO LEDs
In-Reply-To: <1761228.8meccMO5Km@avalon>
References: <1366599990-31751-1-git-send-email-horms+renesas@verge.net.au>
 <1761228.8meccMO5Km@avalon>
Message-ID: <20130423011524.GE12017@verge.net.au>

On Mon, Apr 22, 2013 at 12:00:02PM +0200, Laurent Pinchart wrote:
> Hi Simon,
> 
> Thank you for the patch.
> 
> On Monday 22 April 2013 12:06:30 Simon Horman wrote:
> > The board has 3 LEDs connected to GPIOs. Add a led-gpio device to
> > support them.
> > 
> > Based on "ARM: shmobile: marzen: Add GPIO LEDs" by Laurent Pinchart.
> > 
> > Cc: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
> > Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
> > ---
> >  arch/arm/mach-shmobile/board-lager.c | 37 +++++++++++++++++++++++++++++++++
> >  1 file changed, 37 insertions(+)
> > 
> > Tested on lager board.
> > Based on the tag renesas-next-20130419 of my renesas tree.
> > 
> > diff --git a/arch/arm/mach-shmobile/board-lager.c
> > b/arch/arm/mach-shmobile/board-lager.c index 6114edd..a8aa04f 100644
> > --- a/arch/arm/mach-shmobile/board-lager.c
> > +++ b/arch/arm/mach-shmobile/board-lager.c
> > @@ -21,13 +21,49 @@
> >  #include <linux/interrupt.h>
> >  #include <linux/irqchip.h>
> >  #include <linux/kernel.h>
> > +#include <linux/leds.h>
> >  #include <linux/pinctrl/machine.h>
> > +#include <linux/platform_data/gpio-rcar.h>
> >  #include <linux/platform_device.h>
> >  #include <mach/common.h>
> >  #include <mach/r8a7790.h>
> >  #include <asm/mach-types.h>
> >  #include <asm/mach/arch.h>
> > 
> > +/* LEDS */
> > +static struct gpio_led lager_leds[] = {
> > +	{
> > +		.name		= "led8",
> > +		.gpio		= RCAR_GP_PIN(5, 17),
> > +		.default_state	= LEDS_GPIO_DEFSTATE_ON,
> > +	}, {
> > +		.name		= "led7",
> > +		.gpio		= RCAR_GP_PIN(4, 23),
> > +		.default_state	= LEDS_GPIO_DEFSTATE_ON,
> > +	}, {
> > +		.name		= "led6",
> > +		.gpio		= RCAR_GP_PIN(4, 22),
> > +		.default_state	= LEDS_GPIO_DEFSTATE_ON,
> 
> Just out of curiosity, why is the default state on ?

Only because thats what the marzen code does.
Would off be a better choice?

> 
> > +	},
> > +};
> > +
> > +static struct gpio_led_platform_data lager_leds_pdata = {
> > +	.leds		= lager_leds,
> > +	.num_leds	= ARRAY_SIZE(lager_leds),
> > +};
> > +
> > +static struct platform_device leds_device = {
> > +	.name	= "leds-gpio",
> > +	.id	= 0,
> 
> As there's a single leds-gpio device, maybe id = -1 ?

Yes, true. I'll fix that.
I think the marzen code should probably be fixed too.

> > +	.dev	= {
> > +		.platform_data  = &lager_leds_pdata,
> > +	},
> > +};
> > +
> > +static struct platform_device *lager_devices[] __initdata = {
> > +	&leds_device,
> > +};
> > +
> >  static const struct pinctrl_map lager_pinctrl_map[] = {
> >  	/* SCIF0 (CN19: DEBUG SERIAL0) */
> >  	PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.6", "pfc-r8a7790",
> > @@ -46,6 +82,7 @@ static void __init lager_add_standard_devices(void)
> >  	r8a7790_pinmux_init();
> > 
> >  	r8a7790_add_standard_devices();
> > +	platform_add_devices(lager_devices, ARRAY_SIZE(lager_devices));
> >  }
> > 
> >  static const char *lager_boards_compat_dt[] __initdata = {
> 
> -- 
> Regards,
> 
> Laurent Pinchart
> 


From horms at verge.net.au  Mon Apr 22 21:17:52 2013
From: horms at verge.net.au (Simon Horman)
Date: Tue, 23 Apr 2013 10:17:52 +0900
Subject: [PATCH] ARM: shmobile: lager: Add GPIO LEDs
In-Reply-To: <51752C9A.2040508@cogentembedded.com>
References: <1366599990-31751-1-git-send-email-horms+renesas@verge.net.au>
 <51752C9A.2040508@cogentembedded.com>
Message-ID: <20130423011752.GF12017@verge.net.au>

On Mon, Apr 22, 2013 at 04:27:06PM +0400, Sergei Shtylyov wrote:
> Hello.
> 
> On 22-04-2013 7:06, Simon Horman wrote:
> 
> >The board has 3 LEDs connected to GPIOs. Add a led-gpio device to
> >support them.
> 
> >Based on "ARM: shmobile: marzen: Add GPIO LEDs" by Laurent Pinchart.
> 
> >Cc: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
> >Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
> >---
> >  arch/arm/mach-shmobile/board-lager.c | 37 ++++++++++++++++++++++++++++++++++++
> >  1 file changed, 37 insertions(+)
> 
> >Tested on lager board.
> >Based on the tag renesas-next-20130419 of my renesas tree.
> 
> >diff --git a/arch/arm/mach-shmobile/board-lager.c b/arch/arm/mach-shmobile/board-lager.c
> >index 6114edd..a8aa04f 100644
> >--- a/arch/arm/mach-shmobile/board-lager.c
> >+++ b/arch/arm/mach-shmobile/board-lager.c
> [...]
> >@@ -46,6 +82,7 @@ static void __init lager_add_standard_devices(void)
> >  	r8a7790_pinmux_init();
> >
> >  	r8a7790_add_standard_devices();
> >+	platform_add_devices(lager_devices, ARRAY_SIZE(lager_devices));
> 
>    I thought we shouldn't use platform_add_devices() anymore, being
> close relative to platform_device_register()?

Thanks, as there is only one device I think this
can be changed to use platform_device_register_resndata().
I'll see about making it so.


From horms at verge.net.au  Mon Apr 22 21:18:37 2013
From: horms at verge.net.au (Simon Horman)
Date: Tue, 23 Apr 2013 10:18:37 +0900
Subject: [PATCH] ARM: shmobile: sh73a0: Use IORESOURCE_MEM_* everywhere
In-Reply-To: <51752D57.2000806@cogentembedded.com>
References: <1366602303-31749-1-git-send-email-horms+renesas@verge.net.au>
 <51752D57.2000806@cogentembedded.com>
Message-ID: <20130423011837.GG12017@verge.net.au>

On Mon, Apr 22, 2013 at 04:30:15PM +0400, Sergei Shtylyov wrote:
> Hello.
> 
> On 22-04-2013 7:45, Simon Horman wrote:
> 
> >Convert code to use IORESOURCE_MEM_* macros.
> 
>    You probably meant DEFINE_RES_MEM*() here and in the subject?

Yes, I don't know what I was thinking. I will repost.

> >These macros were already used in this file,
> >this change makes their usage consistent throughout the file.
> 
> >Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
> >---
> >  arch/arm/mach-shmobile/setup-sh73a0.c | 79 ++++++-----------------------------
> >  1 file changed, 13 insertions(+), 66 deletions(-)
> 
> >Based on the renesas-next-20130419 tag of my renesas tree.
> >Boot tested on the kzm9g board.
> 
> >diff --git a/arch/arm/mach-shmobile/setup-sh73a0.c b/arch/arm/mach-shmobile/setup-sh73a0.c
> >index 658c0ad..2ac5f2f 100644
> >--- a/arch/arm/mach-shmobile/setup-sh73a0.c
> >+++ b/arch/arm/mach-shmobile/setup-sh73a0.c
> >@@ -244,12 +244,7 @@ static struct sh_timer_config tmu00_platform_data = {
> >  };
> >
> >  static struct resource tmu00_resources[] = {
> >-	[0] = {
> >-		.name	= "TMU00",
> >-		.start	= 0xfff60008,
> >-		.end	= 0xfff60013,
> >-		.flags	= IORESOURCE_MEM,
> >-	},
> >+	[0] = DEFINE_RES_MEM_NAMED(0xfff60008, 0xc, "TMU00"),
> >  	[1] = {
> >  		.start	= intcs_evt2irq(0x0e80), /* TMU0_TUNI00 */
> >  		.flags	= IORESOURCE_IRQ,
> >@@ -274,12 +269,7 @@ static struct sh_timer_config tmu01_platform_data = {
> >  };
> >
> >  static struct resource tmu01_resources[] = {
> >-	[0] = {
> >-		.name	= "TMU01",
> >-		.start	= 0xfff60014,
> >-		.end	= 0xfff6001f,
> >-		.flags	= IORESOURCE_MEM,
> >-	},
> >+	[0] = DEFINE_RES_MEM_NAMED(0xfff60014, 0xc, "TMU00"),
> >  	[1] = {
> >  		.start	= intcs_evt2irq(0x0ea0), /* TMU0_TUNI01 */
> >  		.flags	= IORESOURCE_IRQ,
> >@@ -297,12 +287,7 @@ static struct platform_device tmu01_device = {
> >  };
> >
> >  static struct resource i2c0_resources[] = {
> >-	[0] = {
> >-		.name	= "IIC0",
> >-		.start	= 0xe6820000,
> >-		.end	= 0xe6820425 - 1,
> >-		.flags	= IORESOURCE_MEM,
> >-	},
> >+	[0] = DEFINE_RES_MEM_NAMED(0xe6820000, 0x426, "IIC0"),
> >  	[1] = {
> >  		.start	= gic_spi(167),
> >  		.end	= gic_spi(170),
> >@@ -311,12 +296,7 @@ static struct resource i2c0_resources[] = {
> >  };
> >
> >  static struct resource i2c1_resources[] = {
> >-	[0] = {
> >-		.name	= "IIC1",
> >-		.start	= 0xe6822000,
> >-		.end	= 0xe6822425 - 1,
> >-		.flags	= IORESOURCE_MEM,
> >-	},
> >+	[0] = DEFINE_RES_MEM_NAMED(0xe6822000, 0x426, "IIC1"),
> >  	[1] = {
> >  		.start	= gic_spi(51),
> >  		.end	= gic_spi(54),
> >@@ -325,12 +305,7 @@ static struct resource i2c1_resources[] = {
> >  };
> >
> >  static struct resource i2c2_resources[] = {
> >-	[0] = {
> >-		.name	= "IIC2",
> >-		.start	= 0xe6824000,
> >-		.end	= 0xe6824425 - 1,
> >-		.flags	= IORESOURCE_MEM,
> >-	},
> >+	[0] = DEFINE_RES_MEM_NAMED(0xe6824000, 0x426, "IIC2"),
> >  	[1] = {
> >  		.start	= gic_spi(171),
> >  		.end	= gic_spi(174),
> >@@ -339,12 +314,7 @@ static struct resource i2c2_resources[] = {
> >  };
> >
> >  static struct resource i2c3_resources[] = {
> >-	[0] = {
> >-		.name	= "IIC3",
> >-		.start	= 0xe6826000,
> >-		.end	= 0xe6826425 - 1,
> >-		.flags	= IORESOURCE_MEM,
> >-	},
> >+	[0] = DEFINE_RES_MEM_NAMED(0xe6826000, 0x426, "IIC3"),
> >  	[1] = {
> >  		.start	= gic_spi(183),
> >  		.end	= gic_spi(186),
> >@@ -353,12 +323,7 @@ static struct resource i2c3_resources[] = {
> >  };
> >
> >  static struct resource i2c4_resources[] = {
> >-	[0] = {
> >-		.name	= "IIC4",
> >-		.start	= 0xe6828000,
> >-		.end	= 0xe6828425 - 1,
> >-		.flags	= IORESOURCE_MEM,
> >-	},
> >+	[0] = DEFINE_RES_MEM_NAMED(0xe6828000, 0x426, "IIC4"),
> >  	[1] = {
> >  		.start	= gic_spi(187),
> >  		.end	= gic_spi(190),
> >@@ -579,12 +544,7 @@ static struct sh_dmae_pdata sh73a0_dmae_platform_data = {
> >  };
> >
> >  static struct resource sh73a0_dmae_resources[] = {
> >-	{
> >-		/* Registers including DMAOR and channels including DMARSx */
> >-		.start  = 0xfe000020,
> >-		.end    = 0xfe008a00 - 1,
> >-		.flags  = IORESOURCE_MEM,
> >-	},
> >+	DEFINE_RES_MEM(0xfe000020, 0x89e0),
> >  	{
> >  		.name	= "error_irq",
> >  		.start  = gic_spi(129),
> >@@ -683,18 +643,10 @@ static struct sh_dmae_pdata sh73a0_mpdma_platform_data = {
> >
> >  /* Resource order important! */
> >  static struct resource sh73a0_mpdma_resources[] = {
> >-	{
> >-		/* Channel registers and DMAOR */
> >-		.start	= 0xec618020,
> >-		.end	= 0xec61828f,
> >-		.flags	= IORESOURCE_MEM,
> >-	},
> >-	{
> >-		/* DMARSx */
> >-		.start	= 0xec619000,
> >-		.end	= 0xec61900b,
> >-		.flags	= IORESOURCE_MEM,
> >-	},
> >+	/* Channel registers and DMAOR */
> >+	DEFINE_RES_MEM(0xec618020, 0x270),
> >+	/* DMARSx */
> >+	DEFINE_RES_MEM(0xec619000, 0xc),
> >  	{
> >  		.name	= "error_irq",
> >  		.start	= gic_spi(181),
> >@@ -741,12 +693,7 @@ static struct platform_device pmu_device = {
> >
> >  /* an IPMMU module for ICB */
> >  static struct resource ipmmu_resources[] = {
> >-	[0] = {
> >-		.name	= "IPMMU",
> >-		.start	= 0xfe951000,
> >-		.end	= 0xfe9510ff,
> >-		.flags	= IORESOURCE_MEM,
> >-	},
> >+	DEFINE_RES_MEM_NAMED(0xfe951000, 0x100, "IPMMU"),
> >  };
> >
> >  static const char * const ipmmu_dev_names[] = {
> 
> WBR, Sergei
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


From horms at verge.net.au  Mon Apr 22 21:19:41 2013
From: horms at verge.net.au (Simon Horman)
Date: Tue, 23 Apr 2013 10:19:41 +0900
Subject: [PATCH v2 2/4] ARM: shmobile: r8a7779: add VIN support
In-Reply-To: <51752F0D.6080805@cogentembedded.com>
References: <201304200232.33731.sergei.shtylyov@cogentembedded.com>
 <5171DD05.6020400@cogentembedded.com>
 <20130422045758.GP15680@verge.net.au>
 <51752F0D.6080805@cogentembedded.com>
Message-ID: <20130423011940.GH12017@verge.net.au>

On Mon, Apr 22, 2013 at 04:37:33PM +0400, Sergei Shtylyov wrote:
> Hello.
> 
> On 22-04-2013 8:57, Simon Horman wrote:
> 
> >>>From: Vladimir Barinov <vladimir.barinov at cogentembedded.com>
> 
> >>>Add VIN clocks and platform devices for R8A7779 SoC; add function to register
> >>>the VIN platform devices.
> 
> >>>Signed-off-by: Vladimir Barinov <vladimir.barinov at cogentembedded.com>
> >>>[Sergei: added 'id' parameter check to r8a7779_add_vin_device(), renamed some
> >>>variables.]
> >>>Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
> 
> >>[...]
> 
> >>>Index: renesas/arch/arm/mach-shmobile/setup-r8a7779.c
> >>>===================================================================
> >>>--- renesas.orig/arch/arm/mach-shmobile/setup-r8a7779.c
> >>>+++ renesas/arch/arm/mach-shmobile/setup-r8a7779.c
> >>>@@ -559,6 +559,33 @@ static struct resource ether_resources[]
> >>>  	},
> >>>  };
> >>>+#define R8A7779_VIN(idx) \
> >>>+static struct resource vin##idx##_resources[] = {		\
> >>>+	DEFINE_RES_MEM(0xffc50000 + 0x1000 * (idx), 0x1000),	\
> >>>+	DEFINE_RES_IRQ(gic_iid(0x5f + (idx))),			\
> >>>+};								\
> >>>+								\
> >>>+static struct platform_device_info vin##idx##_info = {		\
> 
> >>    Hm, probably should have marked this as '__initdata'... maybe
> >>the resources too.
> 
> >That doesn't seem to be the case for other devices in
> >that or other shmobile files. Am I missing something
> >or should numerous other devices be updated?
> 
>    If the device is registered using platform_device_register_*(),
> it seems worth marking the resources, the platfrom data and 'struct
> platform_device_info' as '__initdata' as they're copied to the
> memory allocated from heap anyway and hence not needed past the init
> phase...

Thanks for the explanation, that make sense.


From vinayakm.list at gmail.com  Mon Apr 22 21:28:26 2013
From: vinayakm.list at gmail.com (vinayakm.list at gmail.com)
Date: Tue, 23 Apr 2013 06:58:26 +0530
Subject: [PATCH v2] mm: add an option to disable bounce
Message-ID: <1366680506-2812-1-git-send-email-vinayakm.list@gmail.com>

From: Vinayak Menon <vinayakm.list at gmail.com>

There are times when HIGHMEM is enabled, but
we don't prefer CONFIG_BOUNCE to be enabled.
CONFIG_BOUNCE can reduce the block device
throughput, and this is not ideal for machines
where we don't gain much by enabling it. So
provide an option to deselect CONFIG_BOUNCE. The
observation was made while measuring eMMC throughput
using iozone on an ARM device with 1GB RAM.

Signed-off-by: Vinayak Menon <vinayakm.list at gmail.com>
---
 mm/Kconfig |    8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/mm/Kconfig b/mm/Kconfig
index 3bea74f..e742d06 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -263,8 +263,14 @@ config ZONE_DMA_FLAG
 	default "1"
 
 config BOUNCE
-	def_bool y
+	bool "Enable bounce buffers"
+	default y
 	depends on BLOCK && MMU && (ZONE_DMA || HIGHMEM)
+	help
+	  Enable bounce buffers for devices that cannot access
+	  the full range of memory available to the CPU. Enabled
+	  by default when ZONE_DMA or HIGHMEM is selected, but you
+	  may say n to override this.
 
 # On the 'tile' arch, USB OHCI needs the bounce pool since tilegx will often
 # have more than 4GB of memory, but we don't currently use the IOTLB to present
-- 
1.7.10.4



From thomas.petazzoni at free-electrons.com  Mon Apr 22 21:48:58 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Tue, 23 Apr 2013 03:48:58 +0200
Subject: [PATCH 1/3] mmc: mvsdio: Support inverted CD and WP GPIO lines
In-Reply-To: <87sj2iteue.fsf@octavius.laptop.org>
References: <1366660500-26835-1-git-send-email-gmbnomis@gmail.com>
 <1366660500-26835-2-git-send-email-gmbnomis@gmail.com>
 <87wqrutjss.fsf@octavius.laptop.org>
 <20130422203723.GI29947@lunn.ch>
 <20130422210949.GJ25724@titan.lakedaemon.net>
 <20130422214543.GJ29947@lunn.ch>
 <87sj2iteue.fsf@octavius.laptop.org>
Message-ID: <20130423034858.28c7f99c@skate>

Dear Chris Ball,

On Mon, 22 Apr 2013 17:50:17 -0400, Chris Ball wrote:

> On Mon, Apr 22 2013, Andrew Lunn wrote:
> >> Nothing else really jumps out though.  Where either of these what you
> >> were thinking of?
> >
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2012-December/138514.html
> >
> > and
> >
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2012-December/138513.html
> 
> These patches move mvsdio to slot-gpio, which is a prerequisite for
> using the shared mmc_of_parse(), but they don't go all the way to
> using mmc_of_parse().
> 
> (Which makes sense; mmc_of_parse() was merged to mmc-next in February,
> so it wasn't available for this patchset in December.)

Correct. I used the slot-gpio infrastructure in mvsdio, but I wasn't
aware of the new mmc_of_parse() thing, and I don't have any patch that
converts mvsdio to use it for the moment.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From horms at verge.net.au  Mon Apr 22 21:52:31 2013
From: horms at verge.net.au (Simon Horman)
Date: Tue, 23 Apr 2013 10:52:31 +0900
Subject: [PATCH v5 1/9] ARM: shmobile: Marzen: move USB EHCI, OHCI, and
 PHY devices to R8A7779 code
In-Reply-To: <51753C4D.4080701@cogentembedded.com>
References: <201304200156.23830.sergei.shtylyov@cogentembedded.com>
 <51743BC0.20506@cogentembedded.com>
 <20130422010917.GC15680@verge.net.au>
 <51753C4D.4080701@cogentembedded.com>
Message-ID: <20130423015230.GJ12017@verge.net.au>

On Mon, Apr 22, 2013 at 05:34:05PM +0400, Sergei Shtylyov wrote:
> Hello.
> 
> On 22-04-2013 5:09, Simon Horman wrote:
> 
> >>>USB EHCI, OHCI, and common PHY are the SoC devices but are wrongly defined and
> >>>registered in the Marzen board file.  Move the data and code to their proper
> >>>place in setup-r8a7779.c; while at it, we have to rename 8a7779_late_devices[]
> >>>to 8a7779_standard_devices[] -- this seems legitimate since they are registered
> >>
> >>     I've been pointed to the types in the above variable names privately.
> >>Don't know should I resend or Simon could fix s/8a7779/r8a7779/ while
> >>applying... well, the USB patches haven't been ACK'ed yet.
> 
> >I can fix that up.
> 
> >Is the series waiting on anything?
> 
>    Probably on Felipe's ACKs on rcar-phy.c patches... Felipe hasn't
> appeared on this list for a week but I see his mails from today.

Thanks, lets wait a little longer for his feedback.
Please feel free to ping me if things stagnate.

> >>>from r8a7779_add_standard_devices() anyway.
> 
> >>>Note that I'm deliberately changing the USB PHY platform device's 'id' field
> >>>from (previously just omitted) 0 to -1 as the device is a single of its kind.
> 
> >>>Note also that the board and SoC code have to be in one patch to keep the code
> >>>bisectable...
> 
> >>>The patch has been tested on the Marzen board.
> 
> >>>Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
> >>>Acked-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
> >>>Acked-by: Simon Horman <horms+renesas at verge.net.au>
> 
> WBR, Sergei
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


From horms at verge.net.au  Mon Apr 22 21:55:11 2013
From: horms at verge.net.au (Simon Horman)
Date: Tue, 23 Apr 2013 10:55:11 +0900
Subject: [RFC PATCH v2 09/13] ARM: mach-shmobile: cpus/cpu nodes dts
 updates
In-Reply-To: <1366644455-16550-10-git-send-email-lorenzo.pieralisi@arm.com>
References: <1366644455-16550-1-git-send-email-lorenzo.pieralisi@arm.com>
 <1366644455-16550-10-git-send-email-lorenzo.pieralisi@arm.com>
Message-ID: <20130423015511.GK12017@verge.net.au>

On Mon, Apr 22, 2013 at 04:27:31PM +0100, Lorenzo Pieralisi wrote:
> This patch updates the in-kernel dts files according to the latest cpus
> and cpu bindings updates for ARM.

Sorry to be a pain, but I would appreciate two separate patches,
one per-Soc.

> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
> ---
>  arch/arm/boot/dts/r8a7740.dtsi | 3 +++
>  arch/arm/boot/dts/sh7372.dtsi  | 4 ++++
>  2 files changed, 7 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/r8a7740.dtsi b/arch/arm/boot/dts/r8a7740.dtsi
> index 798fa35..b47bb36 100644
> --- a/arch/arm/boot/dts/r8a7740.dtsi
> +++ b/arch/arm/boot/dts/r8a7740.dtsi
> @@ -14,8 +14,11 @@
>  	compatible = "renesas,r8a7740";
>  
>  	cpus {
> +		#address-cells = <1>;
> +		#size-cells = <0>;
>  		cpu at 0 {
>  			compatible = "arm,cortex-a9";
> +			reg = <0x0>;
>  		};
>  	};
>  };
> diff --git a/arch/arm/boot/dts/sh7372.dtsi b/arch/arm/boot/dts/sh7372.dtsi
> index 677fc60..78478af 100644
> --- a/arch/arm/boot/dts/sh7372.dtsi
> +++ b/arch/arm/boot/dts/sh7372.dtsi
> @@ -14,8 +14,12 @@
>  	compatible = "renesas,sh7372";
>  
>  	cpus {
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
>  		cpu at 0 {
>  			compatible = "arm,cortex-a8";
> +			reg = <0x0>;
>  		};
>  	};
>  };
> -- 
> 1.7.12
> 
> 


From cdall at cs.columbia.edu  Mon Apr 22 22:05:02 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Mon, 22 Apr 2013 19:05:02 -0700
Subject: [PATCH] KVM: ARM: Fix API documentation for ONE_REG encoding
Message-ID: <1366682702-23947-1-git-send-email-cdall@cs.columbia.edu>

Unless I'm mistaken, the size field was encoded 4 bits off and a wrong
value was used for 64-bit FP registers.

Signed-off-by: Christoffer Dall <cdall at cs.columbia.edu>
---
 Documentation/virtual/kvm/api.txt |   12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
index 976eb65..7145ee9 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -1797,22 +1797,22 @@ ARM registers are mapped using the lower 32 bits.  The upper 16 of that
 is the register group type, or coprocessor number:
 
 ARM core registers have the following id bit patterns:
-  0x4002 0000 0010 <index into the kvm_regs struct:16>
+  0x4020 0000 0010 <index into the kvm_regs struct:16>
 
 ARM 32-bit CP15 registers have the following id bit patterns:
-  0x4002 0000 000F <zero:1> <crn:4> <crm:4> <opc1:4> <opc2:3>
+  0x4020 0000 000F <zero:1> <crn:4> <crm:4> <opc1:4> <opc2:3>
 
 ARM 64-bit CP15 registers have the following id bit patterns:
-  0x4003 0000 000F <zero:1> <zero:4> <crm:4> <opc1:4> <zero:3>
+  0x4030 0000 000F <zero:1> <zero:4> <crm:4> <opc1:4> <zero:3>
 
 ARM CCSIDR registers are demultiplexed by CSSELR value:
-  0x4002 0000 0011 00 <csselr:8>
+  0x4020 0000 0011 00 <csselr:8>
 
 ARM 32-bit VFP control registers have the following id bit patterns:
-  0x4002 0000 0012 1 <regno:12>
+  0x4020 0000 0012 1 <regno:12>
 
 ARM 64-bit FP registers have the following id bit patterns:
-  0x4002 0000 0012 0 <regno:12>
+  0x4030 0000 0012 0 <regno:12>
 
 4.69 KVM_GET_ONE_REG
 
-- 
1.7.10.4



From horms at verge.net.au  Mon Apr 22 22:09:46 2013
From: horms at verge.net.au (Simon Horman)
Date: Tue, 23 Apr 2013 11:09:46 +0900
Subject: [PATCH v2 0/1] Add I2C support to R8A7778/BOCK-W
In-Reply-To: <51752E24.6030800@cogentembedded.com>
References: <201304200217.32844.sergei.shtylyov@cogentembedded.com>
 <5171C4FE.9000807@cogentembedded.com>
 <20130422045248.GO15680@verge.net.au>
 <51752E24.6030800@cogentembedded.com>
Message-ID: <20130423020946.GN12017@verge.net.au>

On Mon, Apr 22, 2013 at 04:33:40PM +0400, Sergei Shtylyov wrote:
> Hello.
> 
> On 22-04-2013 8:52, Simon Horman wrote:
> 
> >>>    Here's the patch against the Simon Horman's 'renesas.git' repo,
> >>>'renesas-next-20130417' tag and my recent yet unapplied USB patches.
> 
> >>    Sorry, it's against 'renesas-next-20130419' tag now.
> 
> >Sorry, it doesn't seem to apply cleanly on top of
> >renesas-next-20130417 or renesas-next-20130419.
> 
>    It's also atop of USB the patches.

Sorry for missing that.

> >Could you please rebase, add Morimoto-san's Acked-by and repost?
> 
>    I don't think we're in a hurry to apply this before USB patches
> but if you insist, I'll exchange these patchsets in my series and
> repost.

I'm comfortable with waiting if you are.

Please let me know if/when any of your series are ready.
I try to keep on top of things things but there are a number
of patches in-flight so there is ample scope for error on my part.


From linux at prisktech.co.nz  Mon Apr 22 22:13:18 2013
From: linux at prisktech.co.nz (Tony Prisk)
Date: Tue, 23 Apr 2013 14:13:18 +1200
Subject: [RFC PATCH v2 12/13] ARM: mach-vt8500: cpus/cpu nodes dts updates
In-Reply-To: <1366644455-16550-13-git-send-email-lorenzo.pieralisi@arm.com>
References: <1366644455-16550-1-git-send-email-lorenzo.pieralisi@arm.com>
 <1366644455-16550-13-git-send-email-lorenzo.pieralisi@arm.com>
Message-ID: <5175EE3E.7080809@prisktech.co.nz>

On 23/04/13 03:27, Lorenzo Pieralisi wrote:
> This patch updates the in-kernel dts files according to the latest cpus
> and cpu bindings updates for ARM.
>
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
> ---
>   arch/arm/boot/dts/wm8505.dtsi | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/wm8505.dtsi b/arch/arm/boot/dts/wm8505.dtsi
> index e74a1c0..a470808 100644
> --- a/arch/arm/boot/dts/wm8505.dtsi
> +++ b/arch/arm/boot/dts/wm8505.dtsi
> @@ -13,7 +13,7 @@
>   
>   	cpus {
>   		cpu at 0 {
> -			compatible = "arm,arm926ejs";
> +			compatible = "arm,arm926";
>   		};
>   	};
>   
As the only author for that file, and the arch-vt8500 maintainer, a CC 
would have been nice :)

This binding is still incomplete.device_type, compatible and reg are all 
required properties.
Also, you seem to have only fixed the wm8505.dtsi, while vt8500.dtsi, 
wm8650.dtsi and wm8850.dtsi are all left incorrect.

I am already carrying a patch to fix all this properly so could you drop 
the arch-vt8500 related patch and I will send in a more complete version 
for 3.11

Regards
Tony Prisk


From cdall at cs.columbia.edu  Mon Apr 22 22:17:10 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Mon, 22 Apr 2013 19:17:10 -0700
Subject: [PATCH] ARM: mm: Get rid of L_PTE_USER ref from PAGE_S2_DEVICE
Message-ID: <1366683430-24328-1-git-send-email-cdall@cs.columbia.edu>

THe L_PTE_USER actually has nothing to do with stage 2 mappings and the
L_PTE_S2_RDONLY value sets the readable bit, which was what L_PTE_USER
was used for before proper handling of stage 2 memory defines.

Signed-off-by: Christoffer Dall <cdall at cs.columbia.edu>
---
 arch/arm/include/asm/pgtable.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/pgtable.h b/arch/arm/include/asm/pgtable.h
index 80d6fc4..1d1f97f 100644
--- a/arch/arm/include/asm/pgtable.h
+++ b/arch/arm/include/asm/pgtable.h
@@ -88,7 +88,7 @@ extern pgprot_t		pgprot_s2_device;
 #define PAGE_HYP		_MOD_PROT(pgprot_kernel, L_PTE_HYP)
 #define PAGE_HYP_DEVICE		_MOD_PROT(pgprot_hyp_device, L_PTE_HYP)
 #define PAGE_S2			_MOD_PROT(pgprot_s2, L_PTE_S2_RDONLY)
-#define PAGE_S2_DEVICE		_MOD_PROT(pgprot_s2_device, L_PTE_USER | L_PTE_S2_RDONLY)
+#define PAGE_S2_DEVICE		_MOD_PROT(pgprot_s2_device, L_PTE_S2_RDONLY)
 
 #define __PAGE_NONE		__pgprot(_L_PTE_DEFAULT | L_PTE_RDONLY | L_PTE_XN | L_PTE_NONE)
 #define __PAGE_SHARED		__pgprot(_L_PTE_DEFAULT | L_PTE_USER | L_PTE_XN)
-- 
1.7.10.4



From linux at prisktech.co.nz  Mon Apr 22 22:20:46 2013
From: linux at prisktech.co.nz (Tony Prisk)
Date: Tue, 23 Apr 2013 14:20:46 +1200
Subject: [RFC PATCH v2 12/13] ARM: mach-vt8500: cpus/cpu nodes dts updates
In-Reply-To: <5175EE3E.7080809@prisktech.co.nz>
References: <1366644455-16550-1-git-send-email-lorenzo.pieralisi@arm.com>
 <1366644455-16550-13-git-send-email-lorenzo.pieralisi@arm.com>
 <5175EE3E.7080809@prisktech.co.nz>
Message-ID: <5175EFFE.7020903@prisktech.co.nz>

On 23/04/13 14:13, Tony Prisk wrote:
> On 23/04/13 03:27, Lorenzo Pieralisi wrote:
>> This patch updates the in-kernel dts files according to the latest cpus
>> and cpu bindings updates for ARM.
>>
>> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
>> ---
>>   arch/arm/boot/dts/wm8505.dtsi | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/boot/dts/wm8505.dtsi 
>> b/arch/arm/boot/dts/wm8505.dtsi
>> index e74a1c0..a470808 100644
>> --- a/arch/arm/boot/dts/wm8505.dtsi
>> +++ b/arch/arm/boot/dts/wm8505.dtsi
>> @@ -13,7 +13,7 @@
>>         cpus {
>>           cpu at 0 {
>> -            compatible = "arm,arm926ejs";
>> +            compatible = "arm,arm926";
>>           };
>>       };
> As the only author for that file, and the arch-vt8500 maintainer, a CC 
> would have been nice :)
>
> This binding is still incomplete.device_type, compatible and reg are 
> all required properties.
> Also, you seem to have only fixed the wm8505.dtsi, while vt8500.dtsi, 
> wm8650.dtsi and wm8850.dtsi are all left incorrect.
>
> I am already carrying a patch to fix all this properly so could you 
> drop the arch-vt8500 related patch and I will send in a more complete 
> version for 3.11
>
> Regards
> Tony Prisk

I didn't notice the rules had been changed in the last patch - shouldn't 
you be changing the rules (read: binding) before changing the devicetree 
files?
Request still stands - please drop this patch and I will submit a more 
complete one with the other SoCs updated as well.

Tony P


From alex.shi at intel.com  Mon Apr 22 22:23:26 2013
From: alex.shi at intel.com (Alex Shi)
Date: Tue, 23 Apr 2013 10:23:26 +0800
Subject: [RFC PATCH v3 5/6] sched: pack the idle load balance
In-Reply-To: <CAKfTPtCCCifC=c+xjjnAH_HSqkR80PiQoddQKXPHuZwZawbvcA@mail.gmail.com>
References: <1363955155-18382-1-git-send-email-vincent.guittot@linaro.org>
 <1363955155-18382-6-git-send-email-vincent.guittot@linaro.org>
 <1364302359.5053.21.camel@laptop>
 <CAKfTPtD=_oS5gJeynUG=ft-Y1zEdxZEMhUPH9hSXx+H2pi4xgA@mail.gmail.com>
 <1364308932.5053.46.camel@laptop>
 <CAKfTPtArtgkH5MU_xFAKjLDS-i32g2qQMdvyW=LLkG84tH8Hhg@mail.gmail.com>
 <5174CE96.3060805@linux.vnet.ibm.com>
 <CAKfTPtCCCifC=c+xjjnAH_HSqkR80PiQoddQKXPHuZwZawbvcA@mail.gmail.com>
Message-ID: <5175F09E.1000304@intel.com>

Thanks you, Preeti and Vincent to talk the power aware scheduler for
details! believe this open discussion is helpful to conduct a a more
comprehensive solution. :)

> Hi Preeti,
> 
> I have had a look at Alex patches but i have some concerns with his patches
> -There no notion of power domain which is quite important when we speak
> about power saving IMHO. Packing tasks has got an interest if the idle
> CPUs can reach a useful low power state independently from busy CPUs.
> Architectures have different low power state capabilities which must be
> taken into account. In addition, you can have system which have CPUs
> with better power efficiency and this kind of system are not taken into
> account.

I agree with you on this point. and like what's you done to add new flag
in sched domain. It also make scheduler easy pick up new idea in balancing.
BTW, Currently, the my balance is trying pack task per SMT, maybe
packing task per cpu horse power is more compatible for other archs?

> -There are some computation of statistics on a potentially large number
> of cpus and groups at each task wake up. This overhead concerns me and
> such amount of computation should only be done when we have more time
> like the periodic load balance.

Usually, some computation is far slighter then the task migration. If
the computation is helpful to reduce future possible migration, it will
save much. On current code, I observed the fork balancing can distribute
task well in powersaving policy. That means the computation is worth.

> -There are some heuristics that will be hard to tune:
>  *powersaving balance period set as 8*max_interval
>  *power saving can do some performance load balance if there was no
> performance load balance in the last 32 balances with no more than 4
> perf balance in the last 64 balance

Do you have other tunning opinions on the numbers? I am glad to hear any
input.
>  *sched_burst_threshold

I find it is useful on 3.8 kernel when aim7 cause a very imbalance
wakeup. but now aim7 is calm down after lock-stealing RWSEM used in
kernel, maybe need to re-evaluate this on future new version.
> 
> I'm going to send a proposal for a more aggressive and scalable mode of
> my patches which will take care of my concerns. Let see how this new
> patchset can fit with Alex's ones


-- 
Thanks Alex


From horms+renesas at verge.net.au  Mon Apr 22 22:27:15 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue, 23 Apr 2013 11:27:15 +0900
Subject: [PATCH] ARM: shmobile: sh73a0: Use DEFINE_RES_MEM*() everywhere
Message-ID: <1366684035-6882-1-git-send-email-horms+renesas@verge.net.au>

Convert code to use DEFINE_RES_MEM*() macros.
These macros were already used in this file,
this change makes their usage consistent throughout the file.

Signed-off-by: Simon Horman <horms+renesas at verge.net.au>

---

v2
* As suggested by Sergei Shtylyov:
  Correct change log to refer to DEFINE_RES_MEM* instead of
  IORESOURCE_MEM_*.
---
 arch/arm/mach-shmobile/setup-sh73a0.c | 79 ++++++-----------------------------
 1 file changed, 13 insertions(+), 66 deletions(-)

diff --git a/arch/arm/mach-shmobile/setup-sh73a0.c b/arch/arm/mach-shmobile/setup-sh73a0.c
index 658c0ad..2ac5f2f 100644
--- a/arch/arm/mach-shmobile/setup-sh73a0.c
+++ b/arch/arm/mach-shmobile/setup-sh73a0.c
@@ -244,12 +244,7 @@ static struct sh_timer_config tmu00_platform_data = {
 };
 
 static struct resource tmu00_resources[] = {
-	[0] = {
-		.name	= "TMU00",
-		.start	= 0xfff60008,
-		.end	= 0xfff60013,
-		.flags	= IORESOURCE_MEM,
-	},
+	[0] = DEFINE_RES_MEM_NAMED(0xfff60008, 0xc, "TMU00"),
 	[1] = {
 		.start	= intcs_evt2irq(0x0e80), /* TMU0_TUNI00 */
 		.flags	= IORESOURCE_IRQ,
@@ -274,12 +269,7 @@ static struct sh_timer_config tmu01_platform_data = {
 };
 
 static struct resource tmu01_resources[] = {
-	[0] = {
-		.name	= "TMU01",
-		.start	= 0xfff60014,
-		.end	= 0xfff6001f,
-		.flags	= IORESOURCE_MEM,
-	},
+	[0] = DEFINE_RES_MEM_NAMED(0xfff60014, 0xc, "TMU00"),
 	[1] = {
 		.start	= intcs_evt2irq(0x0ea0), /* TMU0_TUNI01 */
 		.flags	= IORESOURCE_IRQ,
@@ -297,12 +287,7 @@ static struct platform_device tmu01_device = {
 };
 
 static struct resource i2c0_resources[] = {
-	[0] = {
-		.name	= "IIC0",
-		.start	= 0xe6820000,
-		.end	= 0xe6820425 - 1,
-		.flags	= IORESOURCE_MEM,
-	},
+	[0] = DEFINE_RES_MEM_NAMED(0xe6820000, 0x426, "IIC0"),
 	[1] = {
 		.start	= gic_spi(167),
 		.end	= gic_spi(170),
@@ -311,12 +296,7 @@ static struct resource i2c0_resources[] = {
 };
 
 static struct resource i2c1_resources[] = {
-	[0] = {
-		.name	= "IIC1",
-		.start	= 0xe6822000,
-		.end	= 0xe6822425 - 1,
-		.flags	= IORESOURCE_MEM,
-	},
+	[0] = DEFINE_RES_MEM_NAMED(0xe6822000, 0x426, "IIC1"),
 	[1] = {
 		.start	= gic_spi(51),
 		.end	= gic_spi(54),
@@ -325,12 +305,7 @@ static struct resource i2c1_resources[] = {
 };
 
 static struct resource i2c2_resources[] = {
-	[0] = {
-		.name	= "IIC2",
-		.start	= 0xe6824000,
-		.end	= 0xe6824425 - 1,
-		.flags	= IORESOURCE_MEM,
-	},
+	[0] = DEFINE_RES_MEM_NAMED(0xe6824000, 0x426, "IIC2"),
 	[1] = {
 		.start	= gic_spi(171),
 		.end	= gic_spi(174),
@@ -339,12 +314,7 @@ static struct resource i2c2_resources[] = {
 };
 
 static struct resource i2c3_resources[] = {
-	[0] = {
-		.name	= "IIC3",
-		.start	= 0xe6826000,
-		.end	= 0xe6826425 - 1,
-		.flags	= IORESOURCE_MEM,
-	},
+	[0] = DEFINE_RES_MEM_NAMED(0xe6826000, 0x426, "IIC3"),
 	[1] = {
 		.start	= gic_spi(183),
 		.end	= gic_spi(186),
@@ -353,12 +323,7 @@ static struct resource i2c3_resources[] = {
 };
 
 static struct resource i2c4_resources[] = {
-	[0] = {
-		.name	= "IIC4",
-		.start	= 0xe6828000,
-		.end	= 0xe6828425 - 1,
-		.flags	= IORESOURCE_MEM,
-	},
+	[0] = DEFINE_RES_MEM_NAMED(0xe6828000, 0x426, "IIC4"),
 	[1] = {
 		.start	= gic_spi(187),
 		.end	= gic_spi(190),
@@ -579,12 +544,7 @@ static struct sh_dmae_pdata sh73a0_dmae_platform_data = {
 };
 
 static struct resource sh73a0_dmae_resources[] = {
-	{
-		/* Registers including DMAOR and channels including DMARSx */
-		.start  = 0xfe000020,
-		.end    = 0xfe008a00 - 1,
-		.flags  = IORESOURCE_MEM,
-	},
+	DEFINE_RES_MEM(0xfe000020, 0x89e0),
 	{
 		.name	= "error_irq",
 		.start  = gic_spi(129),
@@ -683,18 +643,10 @@ static struct sh_dmae_pdata sh73a0_mpdma_platform_data = {
 
 /* Resource order important! */
 static struct resource sh73a0_mpdma_resources[] = {
-	{
-		/* Channel registers and DMAOR */
-		.start	= 0xec618020,
-		.end	= 0xec61828f,
-		.flags	= IORESOURCE_MEM,
-	},
-	{
-		/* DMARSx */
-		.start	= 0xec619000,
-		.end	= 0xec61900b,
-		.flags	= IORESOURCE_MEM,
-	},
+	/* Channel registers and DMAOR */
+	DEFINE_RES_MEM(0xec618020, 0x270),
+	/* DMARSx */
+	DEFINE_RES_MEM(0xec619000, 0xc),
 	{
 		.name	= "error_irq",
 		.start	= gic_spi(181),
@@ -741,12 +693,7 @@ static struct platform_device pmu_device = {
 
 /* an IPMMU module for ICB */
 static struct resource ipmmu_resources[] = {
-	[0] = {
-		.name	= "IPMMU",
-		.start	= 0xfe951000,
-		.end	= 0xfe9510ff,
-		.flags	= IORESOURCE_MEM,
-	},
+	DEFINE_RES_MEM_NAMED(0xfe951000, 0x100, "IPMMU"),
 };
 
 static const char * const ipmmu_dev_names[] = {
-- 
1.8.2.1



From horms at verge.net.au  Mon Apr 22 22:36:37 2013
From: horms at verge.net.au (Simon Horman)
Date: Tue, 23 Apr 2013 11:36:37 +0900
Subject: [PATCH] ARM: shmobile: lager: Add GPIO LEDs
In-Reply-To: <20130423011752.GF12017@verge.net.au>
References: <1366599990-31751-1-git-send-email-horms+renesas@verge.net.au>
 <51752C9A.2040508@cogentembedded.com>
 <20130423011752.GF12017@verge.net.au>
Message-ID: <20130423023636.GR12017@verge.net.au>

On Tue, Apr 23, 2013 at 10:17:52AM +0900, Simon Horman wrote:
> On Mon, Apr 22, 2013 at 04:27:06PM +0400, Sergei Shtylyov wrote:
> > Hello.
> > 
> > On 22-04-2013 7:06, Simon Horman wrote:
> > 
> > >The board has 3 LEDs connected to GPIOs. Add a led-gpio device to
> > >support them.
> > 
> > >Based on "ARM: shmobile: marzen: Add GPIO LEDs" by Laurent Pinchart.
> > 
> > >Cc: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
> > >Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
> > >---
> > >  arch/arm/mach-shmobile/board-lager.c | 37 ++++++++++++++++++++++++++++++++++++
> > >  1 file changed, 37 insertions(+)
> > 
> > >Tested on lager board.
> > >Based on the tag renesas-next-20130419 of my renesas tree.
> > 
> > >diff --git a/arch/arm/mach-shmobile/board-lager.c b/arch/arm/mach-shmobile/board-lager.c
> > >index 6114edd..a8aa04f 100644
> > >--- a/arch/arm/mach-shmobile/board-lager.c
> > >+++ b/arch/arm/mach-shmobile/board-lager.c
> > [...]
> > >@@ -46,6 +82,7 @@ static void __init lager_add_standard_devices(void)
> > >  	r8a7790_pinmux_init();
> > >
> > >  	r8a7790_add_standard_devices();
> > >+	platform_add_devices(lager_devices, ARRAY_SIZE(lager_devices));
> > 
> >    I thought we shouldn't use platform_add_devices() anymore, being
> > close relative to platform_device_register()?
> 
> Thanks, as there is only one device I think this
> can be changed to use platform_device_register_resndata().
> I'll see about making it so.

On closer examination platform_device_register_data() seems more
appropriate.


From horms+renesas at verge.net.au  Mon Apr 22 22:37:05 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue, 23 Apr 2013 11:37:05 +0900
Subject: [PATCH] ARM: shmobile: lager: Add GPIO LEDs
Message-ID: <1366684625-17256-1-git-send-email-horms+renesas@verge.net.au>

The board has 3 LEDs connected to GPIOs. Add a led-gpio device to
support them.

Based on "ARM: shmobile: marzen: Add GPIO LEDs" by Laurent Pinchart.

Cc: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>

---

v2
* As suggested by Sergei Shtylyov:
  Use platform_device_register_data() instead of platform_add_devices()
* As suggested by Laurent Pinchart:
  Use -1 as device id as there is only one such device
---
 arch/arm/mach-shmobile/board-lager.c | 27 +++++++++++++++++++++++++++
 1 file changed, 27 insertions(+)

diff --git a/arch/arm/mach-shmobile/board-lager.c b/arch/arm/mach-shmobile/board-lager.c
index 6114edd..6a1ba38 100644
--- a/arch/arm/mach-shmobile/board-lager.c
+++ b/arch/arm/mach-shmobile/board-lager.c
@@ -21,13 +21,37 @@
 #include <linux/interrupt.h>
 #include <linux/irqchip.h>
 #include <linux/kernel.h>
+#include <linux/leds.h>
 #include <linux/pinctrl/machine.h>
+#include <linux/platform_data/gpio-rcar.h>
 #include <linux/platform_device.h>
 #include <mach/common.h>
 #include <mach/r8a7790.h>
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
 
+/* LEDS */
+static struct gpio_led lager_leds[] = {
+	{
+		.name		= "led8",
+		.gpio		= RCAR_GP_PIN(5, 17),
+		.default_state	= LEDS_GPIO_DEFSTATE_ON,
+	}, {
+		.name		= "led7",
+		.gpio		= RCAR_GP_PIN(4, 23),
+		.default_state	= LEDS_GPIO_DEFSTATE_ON,
+	}, {
+		.name		= "led6",
+		.gpio		= RCAR_GP_PIN(4, 22),
+		.default_state	= LEDS_GPIO_DEFSTATE_ON,
+	},
+};
+
+static struct gpio_led_platform_data lager_leds_pdata = {
+	.leds		= lager_leds,
+	.num_leds	= ARRAY_SIZE(lager_leds),
+};
+
 static const struct pinctrl_map lager_pinctrl_map[] = {
 	/* SCIF0 (CN19: DEBUG SERIAL0) */
 	PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.6", "pfc-r8a7790",
@@ -46,6 +70,9 @@ static void __init lager_add_standard_devices(void)
 	r8a7790_pinmux_init();
 
 	r8a7790_add_standard_devices();
+	platform_device_register_data(&platform_bus, "leds-gpio", -1,
+				      &lager_leds_pdata,
+				      sizeof(lager_leds_pdata));
 }
 
 static const char *lager_boards_compat_dt[] __initdata = {
-- 
1.8.2.1



From linux at prisktech.co.nz  Mon Apr 22 22:43:48 2013
From: linux at prisktech.co.nz (Tony Prisk)
Date: Tue, 23 Apr 2013 14:43:48 +1200
Subject: [RFC PATCH v2 12/13] ARM: mach-vt8500: cpus/cpu nodes dts updates
In-Reply-To: <1366644455-16550-13-git-send-email-lorenzo.pieralisi@arm.com>
References: <1366644455-16550-1-git-send-email-lorenzo.pieralisi@arm.com>
 <1366644455-16550-13-git-send-email-lorenzo.pieralisi@arm.com>
Message-ID: <5175F564.8030405@prisktech.co.nz>

On 23/04/13 03:27, Lorenzo Pieralisi wrote:
> This patch updates the in-kernel dts files according to the latest cpus
> and cpu bindings updates for ARM.
>
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
> ---
>   arch/arm/boot/dts/wm8505.dtsi | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/wm8505.dtsi b/arch/arm/boot/dts/wm8505.dtsi
> index e74a1c0..a470808 100644
> --- a/arch/arm/boot/dts/wm8505.dtsi
> +++ b/arch/arm/boot/dts/wm8505.dtsi
> @@ -13,7 +13,7 @@
>   
>   	cpus {
>   		cpu at 0 {
> -			compatible = "arm,arm926ejs";
> +			compatible = "arm,arm926";
>   		};
>   	};
>   
The more I look at this, the more wrong it is :/

 From the new binding documentation,

+	A cpus node must define the following properties:
+
+	- #address-cells
+		Usage: required
+		Value type: <u32>
+		Definition: must be set to 1 for 32-bit systems and 2 for
+			    64-bit systems
+	- #size-cells
+		Usage: required
+		Value type: <u32>
+		Definition: must be set to 0

...

+- cpu node
+
+	Description: Describes a CPU in an ARM based system
+
+	PROPERTIES
+
+	- device_type
+		Usage: required
+		Value type: <string>
+		Definition: must be "cpu"

Three required properties that aren't present in the patch.

cpus {
     #size-cells = <0>;
     #address-cells = <1>;

     cpu {
         device_type = "cpu"
         compatible = "arm,arm926";
     };
};

Regards
Tony P


From linux at prisktech.co.nz  Mon Apr 22 22:46:36 2013
From: linux at prisktech.co.nz (Tony Prisk)
Date: Tue, 23 Apr 2013 14:46:36 +1200
Subject: [RFC PATCH v2 13/13] ARM: DT: kernel: DT cpu node bindings update
In-Reply-To: <1366644455-16550-14-git-send-email-lorenzo.pieralisi@arm.com>
References: <1366644455-16550-1-git-send-email-lorenzo.pieralisi@arm.com>
 <1366644455-16550-14-git-send-email-lorenzo.pieralisi@arm.com>
Message-ID: <5175F60C.1070508@prisktech.co.nz>

On 23/04/13 03:27, Lorenzo Pieralisi wrote:
> +
> +=====================================
> +cpus and cpu node bindings definition
> +=====================================
> +
> +The ARM architecture, in accordance with the ePAPR, requires the cpus and cpu
> +nodes to be present and contain the properties described below.
> +
> +- cpus node
> +
> +	Description: Container of cpu nodes
> +
> +	The node name must be "cpus".
> +
> +	A cpus node must define the following properties:
> +
> +	- #address-cells
> +		Usage: required
> +		Value type: <u32>
> +		Definition: must be set to 1 for 32-bit systems and 2 for
> +			    64-bit systems
> +	- #size-cells
> +		Usage: required
> +		Value type: <u32>
> +		Definition: must be set to 0
> +
...
> +Example 3 (ARM 1176 uniprocessor 32-bit system):
> +
> +	cpus {
> +		cpu {
> +			device_type = "cpu";
> +			compatible = "arm,arm1176";
> +		};
> +	};
> +
This example is missing the required #size-cells and #address-cells 
properties.

Regards
Tony P


From dhobsong at igel.co.jp  Mon Apr 22 23:41:48 2013
From: dhobsong at igel.co.jp (Damian Hobson-Garcia)
Date: Tue, 23 Apr 2013 12:41:48 +0900
Subject: [RFC/PATCH 1/4] arm64: Provide default implementation for
 dma_{alloc, free}_attrs
In-Reply-To: <5174D47E.3090301@metafoo.de>
References: <1366607349-2992-1-git-send-email-dhobsong@igel.co.jp>
 <5174D47E.3090301@metafoo.de>
Message-ID: <517602FC.2080305@igel.co.jp>

Hi Lars,
On 2013/04/22 15:11, Lars-Peter Clausen wrote:
> On 04/22/2013 07:09 AM, Damian Hobson-Garcia wrote:
>> Most architectures that define CONFIG_HAVE_DMA, have implementations for
>> both dma_alloc_attrs() and dma_free_attrs().  All achitectures that do
>> not define CONFIG_HAVE_DMA also have both of these definitions provided by
>> dma-mapping-broken.h.
>>
>> Add default implementations for these functions on arm64.
>>
>> Signed-off-by: Damian Hobson-Garcia <dhobsong at igel.co.jp>
>> ---
>>  arch/arm64/include/asm/dma-mapping.h |    3 +++
>>  1 files changed, 3 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm64/include/asm/dma-mapping.h b/arch/arm64/include/asm/dma-mapping.h
>> index 9947768..65ab181 100644
>> --- a/arch/arm64/include/asm/dma-mapping.h
>> +++ b/arch/arm64/include/asm/dma-mapping.h
>> @@ -81,6 +81,9 @@ static inline void dma_mark_clean(void *addr, size_t size)
>>  {
>>  }
>>  
>> +#define dma_alloc_attrs(d, s, h, f, a) dma_alloc_coherent(d, s, h, f)
>> +#define dma_free_attrs(d, s, h, f, a) dma_free_coherent(d, s, h, f)
>> +
>>  static inline void *dma_alloc_coherent(struct device *dev, size_t size,
>>  				       dma_addr_t *dma_handle, gfp_t flags)
>>  {
> 
> The other way around would be better, properly implement
> dma_{alloc,free}_attrs and implement dma_{alloc,free}_coherent on top of
> the. E.g. you are supposed to pass the attrs parameter to ops->alloc and
> ops->free instead of NULL. And it will also allow us to move
> dma_{alloc,free}_coherent to asm-generic/dma-mapping-common.h eventually.

Ok, makes sense.  I'll update this for archs that are using dma_map_ops
(arm64 and s390).

Thanks,
Damian

> 
> - Lars
> 
-- 
Damian Hobson-Garcia
IGEL Co.,Ltd
http://www.igel.co.jp


From sachin.kamat at linaro.org  Tue Apr 23 00:02:30 2013
From: sachin.kamat at linaro.org (Sachin Kamat)
Date: Tue, 23 Apr 2013 09:32:30 +0530
Subject: [PATCH v3 00/10] ARM: exynos multiplatform series, part 1
In-Reply-To: <201304221512.25920.arnd@arndb.de>
References: <1365716245-99231-1-git-send-email-arnd@arndb.de>
 <201304191536.17796.arnd@arndb.de>
 <CAK9yfHwEZUPs70j3rS7V44RWxpZShEP8uxo3fFW54=L3NG-bDA@mail.gmail.com>
 <201304221512.25920.arnd@arndb.de>
Message-ID: <CAK9yfHxR_NE2R8qzx4p2DinJHqZoOK-4g6EtiAg6fecjy_Vd5A@mail.gmail.com>

On 22 April 2013 18:42, Arnd Bergmann <arnd at arndb.de> wrote:
> On Monday 22 April 2013, Sachin Kamat wrote:
>>
>> With this branch now available (merged) in linux-next (20130422),
>> looks like exynos4 DT support is broken on it. Tested on Origen 4210
>> and 4412 and I get the following warnings on 4412 Origen board with
>> exynos_defconfig (Note that clocks are all 0). However, it boots fine
>> on Arndale board.
>
> I think this issue should be fixed with the patch that Thomas Abraham
> just sent. Thomas, can you confirm?

Boot tested Origen 4210, 4412 and Arndale boards after applying Thomas
Abraham's chip-id dt support patches.
They all boot fine.

However I could not see multiplatform support for Exynos in
exynos_defconfig (i.e., CONFIG_ARCH_EXYNOS and
CONFIG_ARCH_MULTIPLATFORM are not set together). This was available in
your 'samsung/exynos-multiplatform' branch. Has this been disabled in
next?

---
With warm regards,
Sachin


From vinod.koul at intel.com  Mon Apr 22 23:44:07 2013
From: vinod.koul at intel.com (Vinod Koul)
Date: Tue, 23 Apr 2013 09:14:07 +0530
Subject: [PATCH v3 1/6] at_hdmac: move to generic DMA binding
In-Reply-To: <51750F68.4040701@atmel.com>
References: <1366362683-14496-1-git-send-email-ludovic.desroches@atmel.com>
 <1366362683-14496-2-git-send-email-ludovic.desroches@atmel.com>
 <51750F68.4040701@atmel.com>
Message-ID: <20130423034407.GY24632@intel.com>

On Mon, Apr 22, 2013 at 12:22:32PM +0200, Nicolas Ferre wrote:
> On 04/19/2013 11:11 AM, ludovic.desroches at atmel.com :
> > From: Ludovic Desroches <ludovic.desroches at atmel.com>

> > +#ifdef CONFIG_OF
> > +static bool at_dma_filter(struct dma_chan *chan, void *slave)
this is not defined for else case here. Also this could be CONFIG_DMA_OF...?
> > +{
> > +	struct at_dma_slave *atslave = slave;
> > +
> > +	if (atslave->dma_dev == chan->device->dev) {
> > +		chan->private = atslave;
> > +		return true;
> > +	} else {
> > +		return false;
> > +	}
> > +}

--
~Vinod


From preeti at linux.vnet.ibm.com  Tue Apr 23 00:36:57 2013
From: preeti at linux.vnet.ibm.com (Preeti U Murthy)
Date: Tue, 23 Apr 2013 10:06:57 +0530
Subject: [RFC PATCH v3 5/6] sched: pack the idle load balance
In-Reply-To: <CAKfTPtCCCifC=c+xjjnAH_HSqkR80PiQoddQKXPHuZwZawbvcA@mail.gmail.com>
References: <1363955155-18382-1-git-send-email-vincent.guittot@linaro.org>
 <1363955155-18382-6-git-send-email-vincent.guittot@linaro.org>
 <1364302359.5053.21.camel@laptop>
 <CAKfTPtD=_oS5gJeynUG=ft-Y1zEdxZEMhUPH9hSXx+H2pi4xgA@mail.gmail.com>
 <1364308932.5053.46.camel@laptop>
 <CAKfTPtArtgkH5MU_xFAKjLDS-i32g2qQMdvyW=LLkG84tH8Hhg@mail.gmail.com>
 <5174CE96.3060805@linux.vnet.ibm.com>
 <CAKfTPtCCCifC=c+xjjnAH_HSqkR80PiQoddQKXPHuZwZawbvcA@mail.gmail.com>
Message-ID: <51760FE9.3030607@linux.vnet.ibm.com>

Hi Vincent,

Thank you very much for bringing about the differences between your
goals and the working of the power aware scheduler patchset.This was
essential for us to understand the various requirements from a power
aware scheduler.After you post out the patchset we could try and
evaluate the following points again.

Thanks

Regards
Preeti U Murthy

On 04/23/2013 01:27 AM, Vincent Guittot wrote:
> On Monday, 22 April 2013, Preeti U Murthy <preeti at linux.vnet.ibm.com> wrote:
>> Hi Vincent,
>>
>> On 04/05/2013 04:38 PM, Vincent Guittot wrote:
>>> Peter,
>>>
>>> After some toughts about your comments,I can update the buddy cpu
>>> during ILB or periofdic LB to a new idle core and extend the packing
>>> mechanism  Does this additional mechanism sound better for you ?
>>
> 
> Hi Preeti,
> 
> I have had a look at Alex patches but i have some concerns with his patches
> -There no notion of power domain which is quite important when we speak
> about power saving IMHO. Packing tasks has got an interest if the idle CPUs
> can reach a useful low power state independently from busy CPUs.
> Architectures have different low power state capabilities which must be
> taken into account. In addition, you can have system which have CPUs with
> better power efficiency and this kind of system are not taken into account.
> -There are some computation of statistics on a potentially large number of
> cpus and groups at each task wake up. This overhead concerns me and such
> amount of computation should only be done when we have more time like the
> periodic load balance.
> -There are some heuristics that will be hard to tune:
>  *powersaving balance period set as 8*max_interval
>  *power saving can do some performance load balance if there was no
> performance load balance in the last 32 balances with no more than 4 perf
> balance in the last 64 balance
>  *sched_burst_threshold
> 
> I'm going to send a proposal for a more aggressive and scalable mode of my
> patches which will take care of my concerns. Let see how this new patchset
> can fit with Alex's ones
> 
> Regards,
> Vincent
> 
>> If the primary goal of this patchset is to pack small tasks in fewer
>> power domains then why not see if the power aware scheduler patchset by
>> Alex does the same for you? The reason being:
>>
>> a.The power aware scheduler also checks if a task is small enough to be
>> packed on a cpu which has just enough capacity to take on that
>> task(leader cpu). This cpu belongs to a scheduler group which is nearly
>> full(group_leader),so we end up packing tasks.
>>
>> b.The overhead of assigning a buddy cpu gets eliminated because the best
>> cpu for packing is decided during wake up.
>>
>> c.This is a scalable solution because if the leader cpu is busy,then any
>> other idle cpu from that group_leader is chosen.Eventually you end up
>> packing anyway.
>>
>> The reason that I am suggesting this is that we could unify the power
>> awareness of the scheduler under one umbrella.And i believe that the
>> current power aware scheduler patchset is flexible enough to do this and
>> that we must cash in on it.
>>
>> Thanks
>>
>> Regards
>> Preeti U Murthy
>>>
>>> Vincent
>>>
>>> On 26 March 2013 15:42, Peter Zijlstra <peterz at infradead.org> wrote:
>>>> On Tue, 2013-03-26 at 15:03 +0100, Vincent Guittot wrote:
>>>>>> But ha! here's your NO_HZ link.. but does the above DTRT and ensure
>>>>>> that the ILB is a little core when possible?
>>>>>
>>>>> The loop looks for an idle CPU as close as possible to the buddy CPU
>>>>> and the buddy CPU is the 1st CPU has been chosen. So if your buddy is
>>>>> a little and there is an idle little, the ILB will be this idle
>>>>> little.
>>>>
>>>> Earlier you wrote:
>>>>
>>>>>       | Cluster 0   | Cluster 1   |
>>>>>       | CPU0 | CPU1 | CPU2 | CPU3 |
>>>>> -----------------------------------
>>>>> buddy | CPU0 | CPU0 | CPU0 | CPU2 |
>>>>
>>>> So extrapolating that to a 4+4 big-little you'd get something like:
>>>>
>>>>       |   little  A9  ||   big A15     |
>>>>       | 0 | 1 | 2 | 3 || 4 | 5 | 6 | 7 |
>>>> ------+---+---+---+---++---+---+---+---+
>>>> buddy | 0 | 0 | 0 | 0 || 0 | 4 | 4 | 4 |
>>>>
>>>> Right?
>>>>
>>>> So supposing the current ILB is 6, we'll only check 4, not 0-3, even
>>>> though there might be a perfectly idle cpu in there.
>>>>
>>>> Also, your scheme fails to pack when cpus 0,4 are filled, even when
>>>> there's idle cores around.
>>>>
>>>> If we'd use the ILB as packing cpu, we would simply select a next pack
>>>> target once the old one fills up.
>>>>
>>>
>>
>>
> 



From jassisinghbrar at gmail.com  Tue Apr 23 00:51:06 2013
From: jassisinghbrar at gmail.com (Jassi Brar)
Date: Tue, 23 Apr 2013 10:21:06 +0530
Subject: [PATCHv3 00/14] drivers: mailbox: framework creation
In-Reply-To: <37C860A02101E749A747FA2D3C1E3C504A5DF7@DLEE11.ent.ti.com>
References: <1363145021-14339-1-git-send-email-s-anna@ti.com>
 <CABb+yY0RYkVeo2Sb4WsDJY0jf17488FEz0d2CB994eQaSOEsVg@mail.gmail.com>
 <37C860A02101E749A747FA2D3C1E3C504A5DF7@DLEE11.ent.ti.com>
Message-ID: <CABb+yY1x4x_A+QtGG9ohsLPgs8c3nEVnd_ExJBGOOR8=6YLPFA@mail.gmail.com>

Hi Suman,

On Mon, Apr 22, 2013 at 9:26 PM, Anna, Suman <s-anna at ti.com> wrote:
>>
>> a) No documentation. Usually the header would have proper documentation of
>> data structures and info for users of both side of the api.
>
> I will fix the documentation portion for 3.10. I will also add a TODO as part of the documentation so that it highlights the gaps and work-items.
>
>>
>> b) The api is not scalable. The assumption of just one IPC controller in the
>> platform is hardcoded.
>
> Yes, this is a major concern and I will be handling this in the upcoming patches . The current code was primarily based on moving the OMAP mailbox code and expanding it to support the ST DBX500 mailbox. As it is today, it doesn't scale to support multiple IP instances/controllers.
>
>>
>> c) There seems to be no consistent design - mailbox_ops has 12 callback hooks.
>> Some, save_ctx, restore_ctx, enable_irq, disable_irq are exported for no
>> apparent reason (legacy of a legacy - OMAP), while other hooks are kept private
>> to the api.
>> I believe OMAP had valid reasons to make IPC clients save/restore context of the
>> IPC controller, but I don't think that is the case in general. I2C client drivers don't
>> save/restore context of I2C controller's, why should IPC's?  Similarly
>> enable/disable_irq of the controller seem too intrusive for a client driver.
>
> Yep, these are exported because of the OMAP legacy TIDSPBRIDGE stack, and should vanish with the addition of runtime_pm support.
>
>>
>> mailbox_ops.mailbox_type_t makes no sense to me. At least not without
>> documentation, though I doubt any amount of documentation could help it -
>> mailbox.c doesn't even read the member. Btw, isn't every mailbox a
>> MBOX_SHARED_MEM_TYPE? A part of data passed via FIFO/REG could point to
>> location in shared memory that might have full command/payload for the
>> message. Or did I get the meaning of MBOX_SHARED_MEM_TYPE wrong in the
>> absence of documentation?
>
> Yes, this needs to be removed, it is a carry-over from the OMAP mailbox code.
>
>>
>> The api seems to worry too much about the low-level details of the IPC controller
>> (save/restore context, enable/disable_irq and ack_irq), while it fails to provide a
>> tight well-defined interface to client drivers.
>>
>> There are also some code issues, which might come as replies to respective
>> patches.
>
> Thanks for the review of the patches. I will await your comments, and will address them as incremental patches.
>
So we agree
a) Documentation is missing.
b) mailbox_type_t, save_ctx, restore_ctx, ack_irq, enable_irq,
disable_irq need to be removed.
c) Support for more than one IPC controllers is needed.

Out of 11 exported functions, we'll be left with the 5 trivial ones
mailbox_un/register, mailbox_get/put and mailbox_msg_send.
mailbox_msg_send_no_irq and mailbox_msg_send_receive_no_irq are STE(?)
specific quirky requirements, which should be possible to simulate
over the mailbox API if designed well.

Documentation wise, we'd need documentation for what we finally wanna
have, not the current implementation.

There are also some desired features in a good API:-

a) The API should be simple and efficient, i.e, submission of requests
by clients and notifications of data received by the API should be
possible from atomic context - most of the IPC is going to be about
exchanging 'commands'. The API shouldn't add to the latencies.

b) It would be very useful to allow submission of a new request from
the completion callback of last one.

c) The request/free/ack_irq on behalf of the IPC controller driver
should be no business of the API. The API design should only assume a
simple but generic enough h/w model beneath it and provide support to
h/w that doesn't have an expected feature.
 For example, API should assume the IPC controller can detect and
report when the remote asserts Ready-To-Receive (RTR). This is when
the API callbacks .tx_done(mssg) on the client. If some h/w doesn't
have RTR assertion interrupt, the API should provide optional feature
to poll the controller periodically.

(d) The 'struct mailbox_msg' should be just an opaque void* - the
client/protocol driver typecasts to void* the IPC controller specific
message structure. API shouldn't aim the impossible of providing a
generic message format.

(a) and (b) are already proved to be useful and supported by a similar
API - DMAEngine.

As you see there would be not much of the present left eventually. So
I wonder if should sculpt a new api out of TI's or start from scratch?
One of my controllers is similar to 'pl320' (which you left out
converting to the API). I am in process of implementing all this
assuming it is OK to keep a controller out of this API :)  So maybe we
can collaborate on a new implementation from scratch.

Regards,
Jassi


From preeti at linux.vnet.ibm.com  Tue Apr 23 00:57:13 2013
From: preeti at linux.vnet.ibm.com (Preeti U Murthy)
Date: Tue, 23 Apr 2013 10:27:13 +0530
Subject: [RFC PATCH v3 5/6] sched: pack the idle load balance
In-Reply-To: <5175F09E.1000304@intel.com>
References: <1363955155-18382-1-git-send-email-vincent.guittot@linaro.org>
 <1363955155-18382-6-git-send-email-vincent.guittot@linaro.org>
 <1364302359.5053.21.camel@laptop>
 <CAKfTPtD=_oS5gJeynUG=ft-Y1zEdxZEMhUPH9hSXx+H2pi4xgA@mail.gmail.com>
 <1364308932.5053.46.camel@laptop>
 <CAKfTPtArtgkH5MU_xFAKjLDS-i32g2qQMdvyW=LLkG84tH8Hhg@mail.gmail.com>
 <5174CE96.3060805@linux.vnet.ibm.com>
 <CAKfTPtCCCifC=c+xjjnAH_HSqkR80PiQoddQKXPHuZwZawbvcA@mail.gmail.com>
 <5175F09E.1000304@intel.com>
Message-ID: <517614A9.50600@linux.vnet.ibm.com>

Hi Alex,

I have one point below.

On 04/23/2013 07:53 AM, Alex Shi wrote:
> Thanks you, Preeti and Vincent to talk the power aware scheduler for
> details! believe this open discussion is helpful to conduct a a more
> comprehensive solution. :)
> 
>> Hi Preeti,
>>
>> I have had a look at Alex patches but i have some concerns with his patches
>> -There no notion of power domain which is quite important when we speak
>> about power saving IMHO. Packing tasks has got an interest if the idle
>> CPUs can reach a useful low power state independently from busy CPUs.
>> Architectures have different low power state capabilities which must be
>> taken into account. In addition, you can have system which have CPUs
>> with better power efficiency and this kind of system are not taken into
>> account.
> 
> I agree with you on this point. and like what's you done to add new flag
> in sched domain. It also make scheduler easy pick up new idea in balancing.
> BTW, Currently, the my balance is trying pack task per SMT, maybe
> packing task per cpu horse power is more compatible for other archs?

Correct me if I am wrong,but the scheduler today does not compare the
task load to the destination cpu power before moving the task to the
destination cpu.This could be during:

1. Load balancing: In move_tasks(), only the imbalance is verified
against the task load before moving tasks and does not necessarily check
if the destination cpu has enough cpu power to handle these tasks.

2. select_task_rq_fair(): For a forked task, the idlest cpu in the group
leader is found during power save balance( I am focussing only on the
power save policy),and is returned as the destination cpu for the forked
task.But I feel we need to check if the idle cpu has the cpu power to
handle the task load.

Why I am bringing about this point is due to a use case which we might
need to handle in the power aware scheduler going ahead.That being the
big.LITTLE cpus. We would ideally want the short running tasks on the
LITTLE cpus and the long running tasks on the big cpus.

While the power aware scheduler strives to pack tasks,it should not end
up packing long running tasks on LITTLE cpus. Not having big cpus to
handle short running tasks is the next step of course but atleast not
throttle the long running tasks by scheduling them on LITTLE cpus.

Thanks

Regards
Preeti U Murthy



From andrew at lunn.ch  Tue Apr 23 01:00:34 2013
From: andrew at lunn.ch (Andrew Lunn)
Date: Tue, 23 Apr 2013 07:00:34 +0200
Subject: [PATCH 0/3] ARM: Kirkwood: Add DT support for (eSATA) Sheevaplug
In-Reply-To: <1366660500-26835-1-git-send-email-gmbnomis@gmail.com>
References: <1366660500-26835-1-git-send-email-gmbnomis@gmail.com>
Message-ID: <20130423050034.GA8710@lunn.ch>

On Mon, Apr 22, 2013 at 09:54:57PM +0200, Simon Baatz wrote:
> These patches add DT support for the Sheevaplugs by Globalscale
> Technologies.  There exists two versions, one with an eSATA port and
> one without.
> 
> Surprisingly, the conversion was not straight forward. In the eSATA
> version (board revision 1.3), the CD and WP pins are connected to GPIO
> lines, but I could not get this to work.  Apparently, I am not the only
> one ([1]).  I found that the pins are reversed on my hardware and use
> different active low/active high settings.
> 
> Thus, the first patch adds support for the GPIO active low/high flag in
> DT to the mvsdio driver.
> 
> With that, everything except the Gigabit Ethernet can be described in
> the DTS.  I have split the DTS and the board support files into two
> patches.  This way, we can drop the last patch once we can describe
> everything in the DTS or we can squash them together if we don't want
> to wait.
> 
> I could only test on an eSATA Sheevaplug. I found patches with
> different LEDs for the Sheevaplug.  Thus, I would highly appreciate if
> someone with the hardware could give this a spin on a non-eSATA
> version.  Some additional testing of the change detect and write
> protect behaviour for sdio can't hurt either.  I hope that there aren't
> board revisions with different CD/WP pins out there.

Hi Simon

Patches 2 and 3 look good to me. If you submit a new version with the
SDIO issue resolved i can give you a Acked-by:

     Thanks
	Andrew


From s.hauer at pengutronix.de  Tue Apr 23 01:07:45 2013
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Tue, 23 Apr 2013 07:07:45 +0200
Subject: [RFC][PATCH] video: imx: Select VIDEOMODE_HELPERS
In-Reply-To: <201304230157.47992.marex@denx.de>
References: <1366666110-9585-1-git-send-email-marex@denx.de>
 <CAOMZO5Av8RyptoxAQ13Psxjjd4nhHVbEJoVm6SqyLr55bPmSng@mail.gmail.com>
 <201304230157.47992.marex@denx.de>
Message-ID: <20130423050745.GO32299@pengutronix.de>

On Tue, Apr 23, 2013 at 01:57:47AM +0200, Marek Vasut wrote:
> Dear Fabio Estevam,
> 
> > Hi Marek,
> > 
> > On Mon, Apr 22, 2013 at 6:28 PM, Marek Vasut <marex at denx.de> wrote:
> > > Without this, I get the following problem when building kernel:
> > > 
> > > drivers/built-in.o: In function `imx_pd_connector_get_modes':
> > > /linux-2.6/drivers/staging/imx-drm/parallel-display.c:78: undefined
> > > reference to `of_get_drm_display_mode' make: *** [vmlinux] Error 1
> > > 
> > > NOTE: I think this patch is almost absolutely not correct.
> > > 
> > > Signed-off-by: Marek Vasut <marex at denx.de>
> > > Cc: Sascha Hauer <s.hauer at pengutronix.de>
> > > Cc: Philipp Zabel <p.zabel at pengutronix.de>
> > > Cc: Fabio Estevam <fabio.estevam at freescale.com>
> > 
> > Patch looks good, but you should have copied Greg Kroah-Hartman, as he
> > is the one who takes patches into staging.
> 
> I'm not sure if the select is at correct symbol, I dont think it is.

No it's not. The parallel display driver needs it, not the i.MX drm
support in general.

Sascha


-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From mpfj-list at newflow.co.uk  Tue Apr 23 01:11:06 2013
From: mpfj-list at newflow.co.uk (Mark Jackson)
Date: Tue, 23 Apr 2013 06:11:06 +0100
Subject: [PATCH 0/3] Dual EMAC mode implementation of CPSW
In-Reply-To: <51756CF2.4050602@ti.com>
References: <1360612340-9266-1-git-send-email-mugunthanvnm@ti.com>
 <516B0098.4040809@mimc.co.uk> <516C33D2.4050105@ti.com>
 <516C38B9.50904@mimc.co.uk> <516C3A0D.70903@ti.com>
 <517018E6.6080108@newflow.co.uk> <51754427.7000908@newflow.co.uk>
 <51756CF2.4050602@ti.com>
Message-ID: <517617EA.7050807@newflow.co.uk>

On 22/04/13 18:01, Mugunthan V N wrote:
> On 4/22/2013 7:37 PM, Mark Jackson wrote:
>> Mugunthan
>>
>> Can you confirm that I'm actually trying to achieve the right thing ?
>>
>> I have all along assumed that Dual EMAC mode would simply provide the
>> kernel will a pair of independent Ethernet ports.
> Yes, it will provide two network interfaces for ex eth0 and eth1
>> All I am trying to do is to get both Ethernet ports working so I can
>> have one port on (say) 10.0.x.x and the other on (say) 10.1.x.x
> This is perfectly correct
>> But there is all this reference to VLANs(in the source code and the TRM)
>> ... I have not setup any VLANs.  Do I need to ?  If so, how ?
> No need to setup any VLAN. VLAN are used to segregate the
> two down stream ports and it will be taken care by the driver

Mugunthan

I now have this all working, thanks to Markus Brunner who spotted that
the CPSW_VLAN_AWARE bit is being incorrectly set rather than cleared in
cpsw_init_host_port().

I think he will be posting a patch soon.

Regards
Mark J.


From vkale at apm.com  Tue Apr 23 01:27:40 2013
From: vkale at apm.com (Vinayak Kale)
Date: Tue, 23 Apr 2013 10:57:40 +0530
Subject: [PATCH 4/4] arm64: Add initial DTS for APM X-Gene Storm SOC and
 APM Mustang board
In-Reply-To: <5175A4C3.3090009@gmail.com>
References: <1366442131-26094-1-git-send-email-vkale@apm.com>
 <1366442131-26094-5-git-send-email-vkale@apm.com>
 <5175A4C3.3090009@gmail.com>
Message-ID: <CAPrCYkct5TA8BK2TGHyMroxBxrSVB5+UgFQQVQJfGLYOmAZceA@mail.gmail.com>

On Tue, Apr 23, 2013 at 2:29 AM, Rob Herring <robherring2 at gmail.com> wrote:
> On 04/20/2013 02:15 AM, Vinayak Kale wrote:
>> This patch adds initial DTS files required for APM Mustang board.
>>
>> Signed-off-by: Kumar Sankaran <ksankaran at apm.com>
>> Signed-off-by: Loc Ho <lho at apm.com>
>> Signed-off-by: Feng Kan <fkan at apm.com>
>> ---
>>  arch/arm64/boot/dts/Makefile    |    1 +
>>  arch/arm64/boot/dts/mustang.dts |   28 +++++++++
>>  arch/arm64/boot/dts/storm.dtsi  |  116 +++++++++++++++++++++++++++++++++++++++
>
> Can you add "apm" to these filenames.
>
Okay, I'll add 'apm-' prefix to dts filenames.
>>  3 files changed, 145 insertions(+), 0 deletions(-)
>>  create mode 100644 arch/arm64/boot/dts/mustang.dts
>>  create mode 100644 arch/arm64/boot/dts/storm.dtsi
>>
>> diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
>> index 68457e9..faeab34 100644
>> --- a/arch/arm64/boot/dts/Makefile
>> +++ b/arch/arm64/boot/dts/Makefile
>> @@ -1,4 +1,5 @@
>>  dtb-$(CONFIG_ARCH_VEXPRESS) += rtsm_ve-aemv8a.dtb foundation-v8.dtb
>> +dtb-$(CONFIG_ARCH_XGENE) += mustang.dtb
>>
>>  targets += dtbs
>>  targets += $(dtb-y)
>> diff --git a/arch/arm64/boot/dts/mustang.dts b/arch/arm64/boot/dts/mustang.dts
>> new file mode 100644
>> index 0000000..a061c99
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/mustang.dts
>> @@ -0,0 +1,28 @@
>> +/*
>> + * dts file for AppliedMicro (APM) Mustang Board
>> + *
>> + * Copyright (C) 2013, Applied Micro Circuits Corporation
>> + *
>> + * 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/ "storm.dtsi"
>> +
>> +/ {
>> +     model = "mustang";
>> +
>> +     /* chosen */
>
> Wow, that's a useful comment.
>
>> +     chosen {
>> +             linux,stdout-path = &serial0;
>
> I don't think this is needed if you only have a single uart.
>
In subsequent patches we will add other serial nodes in the dts.
>> +     };
>> +
>> +     memory {
>> +             device_type = "memory";
>> +             reg = < 0x1 0x00000000 0x0 0x80000000 >; /* Updated by bootloader */
>> +     };
>> +};
>> diff --git a/arch/arm64/boot/dts/storm.dtsi b/arch/arm64/boot/dts/storm.dtsi
>> new file mode 100644
>> index 0000000..8cab5d1
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/storm.dtsi
>> @@ -0,0 +1,116 @@
>> +/*
>> + * dts file for AppliedMicro (APM) X-Gene Storm SOC
>> + *
>> + * Copyright (C) 2013, Applied Micro Circuits Corporation
>> + *
>> + * 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.
>> + */
>> +
>> +/ {
>> +     compatible = "apm,xgene,storm", "apm,xgene";
>
> Need to add documentation for the binding and the vendor prefix if it is
> not already there.
>
>> +     interrupt-parent = <&gic>;
>> +     #address-cells = <2>;
>> +     #size-cells = <2>;
>> +
>> +     cpus {
>> +             #address-cells = <1>;
>> +             #size-cells = <0>;
>> +
>> +             cpu at 0 {
>> +                     device_type = "cpu";
>> +                     compatible = "arm,armv8";
>> +                     reg = <0x0 0x0000>;
>> +                     enable-method = "spin-table";
>> +                     cpu-release-addr = <0x1 0x0000fff8>;
>> +             };
>> +             cpu at 1 {
>> +                     device_type = "cpu";
>> +                     compatible = "arm,armv8";
>> +                     reg = <0x0 0x0001>;
>> +                     enable-method = "spin-table";
>> +                     cpu-release-addr = <0x1 0x0000fff8>;
>> +             };
>> +             cpu at 2 {
>> +                     device_type = "cpu";
>> +                     compatible = "arm,armv8";
>> +                     reg = <0x0 0x0100>;
>> +                     enable-method = "spin-table";
>> +                     cpu-release-addr = <0x1 0x0000fff8>;
>> +             };
>> +             cpu at 3 {
>> +                     device_type = "cpu";
>> +                     compatible = "arm,armv8";
>> +                     reg = <0x0 0x0101>;
>> +                     enable-method = "spin-table";
>> +                     cpu-release-addr = <0x1 0x0000fff8>;
>> +             };
>> +             cpu at 4 {
>> +                     device_type = "cpu";
>> +                     compatible = "arm,armv8";
>> +                     reg = <0x0 0x0200>;
>> +                     enable-method = "spin-table";
>> +                     cpu-release-addr = <0x1 0x0000fff8>;
>> +             };
>> +             cpu at 5 {
>> +                     device_type = "cpu";
>> +                     compatible = "arm,armv8";
>> +                     reg = <0x0 0x0201>;
>> +                     enable-method = "spin-table";
>> +                     cpu-release-addr = <0x1 0x0000fff8>;
>> +             };
>> +             cpu at 6 {
>> +                     device_type = "cpu";
>> +                     compatible = "arm,armv8";
>> +                     reg = <0x0 0x0300>;
>> +                     enable-method = "spin-table";
>> +                     cpu-release-addr = <0x1 0x0000fff8>;
>> +             };
>> +             cpu at 7 {
>> +                     device_type = "cpu";
>> +                     compatible = "arm,armv8";
>> +                     reg = <0x0 0x0301>;
>> +                     enable-method = "spin-table";
>> +                     cpu-release-addr = <0x1 0x0000fff8>;
>> +             };
>> +     };
>> +
>> +     gic: interrupt-controller at 78010000 {
>> +             compatible = "arm,cortex-a15-gic", "arm,cortex-a9-gic";
>> +             #interrupt-cells = <3>;
>> +             interrupt-controller;
>> +             reg = <0x0 0x78010000 0x0 0x1000>,      /* GIC Dist */
>> +                   <0x0 0x78020000 0x0 0x1000>,      /* GIC CPU */
>> +                   <0x0 0x78040000 0x0 0x2000>,      /* GIC VCPU Control */
>> +                   <0x0 0x78060000 0x0 0x2000>;      /* GIC VCPU */
>> +             interrupts = <1 9 0xf04>;       /* GIC Maintenence IRQ */
>> +     };
>> +
>> +     timer {
>> +             compatible = "arm,armv8-timer";
>> +             interrupts = <1 0 0xff01>,      /* Secure Phys IRQ */
>> +                          <1 13 0xff01>,     /* Non-secure Phys IRQ */
>> +                          <1 14 0xff01>,     /* Virt IRQ */
>> +                          <1 15 0xff01>;     /* Hyp IRQ */
>> +             clock-frequency = <50000000>;
>> +     };
>> +
>> +     soc {
>> +             compatible = "simple-bus";
>> +             #address-cells = <2>;
>> +             #size-cells = <2>;
>> +             ranges;
>> +
>> +             serial0: uart0 at 1c020000 {
>> +                     device_type = "serial";
>> +                     compatible = "ns16550";
>> +                     reg = <0 0x1c020000 0x0 0x1000>;
>> +                     reg-shift = <2>;
>> +                     clock-frequency = <10000000>; /* Updated by bootloader */
>> +                     interrupt-parent = <&gic>;
>> +                     interrupts = <0x0 0x4c 0x4>;
>> +             };
>> +     };
>> +};
>>
>


From pranavkumar at linaro.org  Tue Apr 23 01:53:38 2013
From: pranavkumar at linaro.org (Pranavkumar Sawargaonkar)
Date: Tue, 23 Apr 2013 11:23:38 +0530
Subject: [RFC] arm64: Early printk support for virtio-mmio console devices.
In-Reply-To: <87mwsr9md7.fsf@rustcorp.com.au>
References: <1366264344-28025-1-git-send-email-pranavkumar@linaro.org>
 <87wqs02uws.fsf@rustcorp.com.au>
 <CAAHg+HiHKV+8hBT1QWe4hSxocCX6wpRd3bCPWB7zU8jVFmPuAA@mail.gmail.com>
 <87ehe3bbsm.fsf@rustcorp.com.au>
 <CALrVBkub+TABrrBwh4+P6S5TGL1qSmnZrd1cbGgj6JiRpY=rOA@mail.gmail.com>
 <87mwsr9md7.fsf@rustcorp.com.au>
Message-ID: <CAAHg+Hg1u-md_5hSWxyVOOrg_f9=h0tO5iv2WQL-U-MyTMAV9g@mail.gmail.com>

On 22 April 2013 10:45, Rusty Russell <rusty at rustcorp.com.au> wrote:
> Anup Patel <anup.patel at linaro.org> writes:
>> On 22 April 2013 06:51, Rusty Russell <rusty at rustcorp.com.au> wrote:
>>>
>>> Pranavkumar Sawargaonkar <pranavkumar at linaro.org> writes:
>>> > On 18 April 2013 12:21, Rusty Russell <rusty at rustcorp.com.au> wrote:
>>> >>
>>> >> PranavkumarSawargaonkar <pranavkumar at linaro.org> writes:
>>> >> > From: Pranavkumar Sawargaonkar <pranavkumar at linaro.org>
>>> >> >
>>> >> > This patch implements early printk support for virtio-mmio console
>>> >> > devices without using any hypercalls.
>>> >>
>>> >> This makes some sense, though not sure that early console *read* makes
>>> >> much sense.  I can see the PCI version of this being useful as well.
>>> >
>>> > Read can be useful for "mach-virt" which will have only virtio console
>>> > as a console device. Then if someone wants to have UEFI or any other
>>> > boot-loader emulation, which expects user to input few things, in that
>>> > case read might become handy.
>>>
>>> But implementing virtio inside a bootloader has already been done for
>>> coreboot, for example.  A bootloader probably wants a virtio block
>>> device, so a console is trivial.
>>>
>>> A single writable field for debugging makes sense.  Anything more is far
>>> less certain.
>>
>> The early read can be handy for bootloader who don't want to implement
>> complete VirtIO programming.
>
> I've said this twice already.  This is the last time.
>
> 1) We do not add complexity unless we have to.
> 2) Making it optional does not make it significantly less complex.
> 3) Having two ways of doing the same thing is always ugly.
> 4) Having an emergency output method makes sense for several use cases,
>    an emergency input method does not.
Okay,  i will restructure my patch by keeping just output write part
and post it back.

Thanks,
Pranav

> 5) A bootloader which uses virtio to get the images to boot can
>    implement a console in less than 10 lines.
> 6) A bootloader which does not use any virtio devices but nonetheless
>    wants to obtain input can implement a simple console in well under 100
>    lines.  See below.
>
> Finally, in case you still don't understand:
>
> My task is to make this decision, and I've made it.  Arguing with me is
> only useful if you bring new facts which you can change my mind.
>
> Hope that clarifies,
> Rusty.
>
> #define VIRTIO_MMIO_GUEST_PAGE_SIZE     0x028
> #define VIRTIO_MMIO_QUEUE_SEL           0x030
> #define VIRTIO_MMIO_QUEUE_NUM_MAX       0x034
> #define VIRTIO_MMIO_QUEUE_NUM           0x038
> #define VIRTIO_MMIO_QUEUE_ALIGN         0x03c
> #define VIRTIO_MMIO_QUEUE_PFN           0x040
> #define VIRTIO_MMIO_QUEUE_NOTIFY        0x050
>
> struct vring_desc {
>         __u64 addr;
>         __u32 len;
>         __u16 flags;
>         __u16 next;
> };
>
> struct vring_used_elem {
>         __u32 id;
>         __u32 len;
> };
>
> struct vconsole_ring {
>         struct vring_desc desc[2];
>         __u16 avail_flags;
>         __u16 avail_idx;
>         __u16 available[2];
>         __u16 used_event_idx;
>         __u16 pad; /* Hit 4-byte boundary */
>
>         // A ring of used descriptor heads with free-running index.
>         __u16 used_flags;
>         __u16 used_idx;
>         struct vring_used_elem used[2];
>         __u16 avail_event_idx;
> };
>
> static char console_in;
> static struct vconsole_ring vc_ring = {
>         { { PHYSICAL_ADDR(console_in), 1, 2, 0 } },
>         1, /* No interrupts */
> }
>
> static void post_buffer(void *base)
> {
>         vc_ring->avail_idx++;
>         wmb();
>         writel(0, base + VIRTIO_MMIO_QUEUE_NOTIFY);
> }
>
> bool vc_read(void *base, char *c)
> {
>         mb();
>         if (vc_ring->used_idx != vc_ring->avail_idx)
>                 return false;
>         *c = console_in;
>         post_buffer(base);
>         return true;
> }
>
> void vc_init(void *base)
> {
>         /* Alignment of 4 bytes, don't waste any. */
>         writel(4, base + VIRTIO_MMIO_GUEST_PAGE_SIZE);
>
>         /* Setup incoming vq. */
>         writel(0, base + VIRTIO_MMIO_QUEUE_SEL);
>
>         /* 2 elements */
>         writel(2, base + VIRTIO_MMIO_QUEUE_NUM);
>         /* Alignment of 4 bytes */
>         writel(4, base + VIRTIO_MMIO_QUEUE_ALIGN);
>         /* Location of queue. */
>         writel(PHYSICAL_ADDR(&vc_ring) >> 4, base + VIRTIO_MMIO_QUEUE_PFN);
>
>         post_buffer(base);
> }


From kishon at ti.com  Tue Apr 23 02:14:16 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Tue, 23 Apr 2013 11:44:16 +0530
Subject: [PATCH] ARM: OMAP4: change the device names in usb_bind_phy
Message-ID: <1366697656-14315-1-git-send-email-kishon@ti.com>

After the device names are created using PLATFORM_DEVID_AUTO, the old
device names given in usb_bind_phy are no longer valid causing the musb
controller not to get the phy reference. Updated the usb_bind_phy with
the new device names to get MUSB functional in omap4 panda.

Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
---
Tested in OMAP4 PANDA.
 arch/arm/mach-omap2/board-4430sdp.c    |    2 +-
 arch/arm/mach-omap2/board-omap4panda.c |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c
index 00d7290..56a9a4f 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -730,7 +730,7 @@ static void __init omap_4430sdp_init(void)
 	omap4_sdp4430_wifi_init();
 	omap4_twl6030_hsmmc_init(mmc);
 
-	usb_bind_phy("musb-hdrc.0.auto", 0, "omap-usb2.1.auto");
+	usb_bind_phy("musb-hdrc.2.auto", 0, "omap-usb2.3.auto");
 	usb_musb_init(&musb_board_data);
 
 	status = omap_ethernet_init();
diff --git a/arch/arm/mach-omap2/board-omap4panda.c b/arch/arm/mach-omap2/board-omap4panda.c
index a71ad34..1e2c75e 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -435,7 +435,7 @@ static void __init omap4_panda_init(void)
 	omap_sdrc_init(NULL, NULL);
 	omap4_twl6030_hsmmc_init(mmc);
 	omap4_ehci_init();
-	usb_bind_phy("musb-hdrc.0.auto", 0, "omap-usb2.1.auto");
+	usb_bind_phy("musb-hdrc.2.auto", 0, "omap-usb2.3.auto");
 	usb_musb_init(&musb_board_data);
 	omap4_panda_display_init();
 }
-- 
1.7.10.4



From viresh.kumar at linaro.org  Tue Apr 23 02:18:17 2013
From: viresh.kumar at linaro.org (Viresh Kumar)
Date: Tue, 23 Apr 2013 11:48:17 +0530
Subject: [RFC PATCH v2 10/13] ARM: mach-spear: cpus/cpu nodes dts updates
In-Reply-To: <1366644455-16550-11-git-send-email-lorenzo.pieralisi@arm.com>
References: <1366644455-16550-1-git-send-email-lorenzo.pieralisi@arm.com>
 <1366644455-16550-11-git-send-email-lorenzo.pieralisi@arm.com>
Message-ID: <CAKohpon+8k9Fm-GoStP1HTnUfxeUJaLaVa4dbkGw925Mg9_1dA@mail.gmail.com>

On 22 April 2013 20:57, Lorenzo Pieralisi <lorenzo.pieralisi at arm.com> wrote:
> This patch updates the in-kernel dts files according to the latest cpus
> and cpu bindings updates for ARM.
>
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
> ---
>  arch/arm/boot/dts/spear3xx.dtsi | 2 +-
>  arch/arm/boot/dts/spear600.dtsi | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)

Acked-by: Viresh Kumar <viresh.kumar at linaro.org>


From marek.belisko at gmail.com  Tue Apr 23 02:22:49 2013
From: marek.belisko at gmail.com (Marek Belisko)
Date: Tue, 23 Apr 2013 08:22:49 +0200
Subject: [PATCH 1/2] clk: si5351: Fix clkout rate computation.
Message-ID: <1366698170-31346-1-git-send-email-marek.belisko@streamunlimited.com>

Rate was incorrectly computed because we read from wrong divider register.

Signed-off-by: Marek Belisko <marek.belisko at streamunlimited.com>
---
 drivers/clk/clk-si5351.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/clk-si5351.c b/drivers/clk/clk-si5351.c
index 8927284..cf39e53 100644
--- a/drivers/clk/clk-si5351.c
+++ b/drivers/clk/clk-si5351.c
@@ -932,7 +932,7 @@ static unsigned long si5351_clkout_recalc_rate(struct clk_hw *hw,
 	unsigned char reg;
 	unsigned char rdiv;
 
-	if (hwdata->num > 5)
+	if (hwdata->num <= 5)
 		reg = si5351_msynth_params_address(hwdata->num) + 2;
 	else
 		reg = SI5351_CLK6_7_OUTPUT_DIVIDER;
-- 
1.7.9.5



From marek.belisko at gmail.com  Tue Apr 23 02:22:50 2013
From: marek.belisko at gmail.com (Marek Belisko)
Date: Tue, 23 Apr 2013 08:22:50 +0200
Subject: [PATCH 2/2] clk: si5351: Apply rate when clock-frequency is defined
 in devicetree.
In-Reply-To: <1366698170-31346-1-git-send-email-marek.belisko@streamunlimited.com>
References: <1366698170-31346-1-git-send-email-marek.belisko@streamunlimited.com>
Message-ID: <1366698170-31346-2-git-send-email-marek.belisko@streamunlimited.com>

clock-frequency property from devicetree was read but never used. Apply
defined rate when clock is registered.

Signed-off-by: Marek Belisko <marek.belisko at streamunlimited.com>
---
 drivers/clk/clk-si5351.c |   10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/clk/clk-si5351.c b/drivers/clk/clk-si5351.c
index cf39e53..8323c31 100644
--- a/drivers/clk/clk-si5351.c
+++ b/drivers/clk/clk-si5351.c
@@ -1477,6 +1477,16 @@ static int si5351_i2c_probe(struct i2c_client *client,
 			return -EINVAL;
 		}
 		drvdata->onecell.clks[n] = clk;
+
+		/* set rate when defined in devicetree */
+		if (pdata->clkout[n].rate != 0) {
+			int ret;
+			ret = clk_set_rate(clk, pdata->clkout[n].rate);
+			if (ret != 0) {
+				dev_err(&client->dev, "Cannot set rate : %d\n",
+					ret);
+			}
+		}
 	}
 
 	ret = of_clk_add_provider(client->dev.of_node, of_clk_src_onecell_get,
-- 
1.7.9.5



From srinivas.kandagatla at st.com  Tue Apr 23 02:48:46 2013
From: srinivas.kandagatla at st.com (Srinivas KANDAGATLA)
Date: Tue, 23 Apr 2013 07:48:46 +0100
Subject: [PATCH v1] ARM: do not select ARCH_VEXPRESS by default on
 ARCH_MULTI_V7
In-Reply-To: <CAOMZO5BMesWazKtfgQ9BFDiW0oiWCQop2LUs0j6P4fDSGMhvfg@mail.gmail.com>
References: <1366634604-12637-1-git-send-email-srinivas.kandagatla@st.com>
 <1366649966.3203.40.camel@hornet>
 <CAOMZO5BMesWazKtfgQ9BFDiW0oiWCQop2LUs0j6P4fDSGMhvfg@mail.gmail.com>
Message-ID: <51762ECE.8070202@st.com>

On 22/04/13 18:10, Fabio Estevam wrote:
> On Mon, Apr 22, 2013 at 1:59 PM, Pawel Moll <pawel.moll at arm.com> wrote:
>
>> Fabio was looking at this some time ago:
>> http://thread.gmane.org/gmane.linux.ports.arm.kernel/201499
>> He may comment on the relevant issues.
Thankyou for the patch, now I understand the reasoning.
> Arnd has recently posted a patch to address this issue:
> https://patchwork.kernel.org/patch/2436131/
>
> Regards,
>
> Fabio Estevam
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>



From linus.walleij at linaro.org  Tue Apr 23 03:26:56 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Tue, 23 Apr 2013 09:26:56 +0200
Subject: gpio-pxa initcall level change and machine init breakage
In-Reply-To: <CAD6h2NSy0=3P-PHdCiJJQG_jvGaFnr7uex+Uxs=0F-VsUxtPWg@mail.gmail.com>
References: <5172B398.7060706@newsguy.com>
 <CAD6h2NSRA9w7GZLQGgK-+TvEAsxwOHow5_26JyVUA6YQyj3OQg@mail.gmail.com>
 <517466F6.3000003@newsguy.com>
 <CAD6h2NSy0=3P-PHdCiJJQG_jvGaFnr7uex+Uxs=0F-VsUxtPWg@mail.gmail.com>
Message-ID: <CACRpkdbk24kR75fanvXVAocnuozNq_=jWDSPHPCWhbZCOrN5_Q@mail.gmail.com>

On Mon, Apr 22, 2013 at 2:58 AM, Haojian Zhuang
<haojian.zhuang at linaro.org> wrote:
> On 22 April 2013 06:23, Mike Dunn <mikedunn at newsguy.com> wrote:
>> Will the big guy see this?  Only posted to linux-arm-kernel ML.
>>
>> Thanks Haojian,
>> Mike

I guess Haojian is referring to me, not Torvalds ...

> Sorry, I forgot to loop him in.
>
> Linus,
> Should I send the revert commit to you? Or will you revert it directly?

How hard is it to fix the real problem?

I'm looking at arch/arm/mach-pxa/palmtreo.c, would
something like this solve the problem:

>From 5acf99a576f563d48ca5d25b9e5a1bcdd09331eb Mon Sep 17 00:00:00 2001
From: Linus Walleij <linus.walleij at linaro.org>
Date: Tue, 23 Apr 2013 09:24:43 +0200
Subject: [PATCH] ARM: pxa: set up Treo GPIOs using device initcall

This augments the Treo setup to grab LCD GPIOs at device_initcall()
level instead of at init_machine() time, and propagates any
returned errors so that deferred probe will work.

Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 arch/arm/mach-pxa/palmtreo.c | 36 +++++++++++++++++++++++-------------
 1 file changed, 23 insertions(+), 13 deletions(-)

diff --git a/arch/arm/mach-pxa/palmtreo.c b/arch/arm/mach-pxa/palmtreo.c
index d82a50b..669b609 100644
--- a/arch/arm/mach-pxa/palmtreo.c
+++ b/arch/arm/mach-pxa/palmtreo.c
@@ -455,16 +455,20 @@ static void __init palmphone_common_init(void)
 }

 #ifdef CONFIG_MACH_TREO680
-void __init treo680_gpio_init(void)
+static int __init treo680_gpio_init(void)
 {
     unsigned int gpio;
+    int ret;

     /* drive all three lcd gpios high initially */
     const unsigned long lcd_flags = GPIOF_INIT_HIGH | GPIOF_DIR_OUT;

     /*
      * LCD GPIO initialization...
+     * only run this on the Treo680
      */
+    if (!machine_is_treo680())
+        return 0;

     /*
      * This is likely the power to the lcd.  Toggling it low/high appears to
@@ -474,8 +478,9 @@ void __init treo680_gpio_init(void)
      * treo680 configures it as gpio.
      */
     gpio = GPIO_NR_TREO680_LCD_POWER;
-    if (gpio_request_one(gpio, lcd_flags, "LCD power") < 0)
-        goto fail;
+    ret = gpio_request_one(gpio, lcd_flags, "LCD power");
+    if (ret < 0)
+        goto fail_lcd_power;

     /*
      * These two are called "enables", for lack of a better understanding.
@@ -486,28 +491,33 @@ void __init treo680_gpio_init(void)
      * revisited.
      */
     gpio = GPIO_NR_TREO680_LCD_EN;
-    if (gpio_request_one(gpio, lcd_flags, "LCD enable") < 0)
-        goto fail;
+    ret = gpio_request_one(gpio, lcd_flags, "LCD enable");
+    if (ret < 0)
+        goto fail_lcd_en;
     gpio = GPIO_NR_TREO680_LCD_EN_N;
-    if (gpio_request_one(gpio, lcd_flags, "LCD enable_n") < 0)
-        goto fail;
+    ret = gpio_request_one(gpio, lcd_flags, "LCD enable_n");
+    if (ret < 0)
+        goto fail_lcd_en_n;

     /* driving this low turns LCD on */
     gpio_set_value(GPIO_NR_TREO680_LCD_EN_N, 0);

-    return;
- fail:
-    pr_err("gpio %d initialization failed\n", gpio);
-    gpio_free(GPIO_NR_TREO680_LCD_POWER);
+    return 0;
+
+fail_lcd_en_n:
     gpio_free(GPIO_NR_TREO680_LCD_EN);
-    gpio_free(GPIO_NR_TREO680_LCD_EN_N);
+fail_lcd_en:
+    gpio_free(GPIO_NR_TREO680_LCD_POWER);
+fail_lcd_power:
+    pr_err("gpio %d initialization failed\n", gpio);
+    return ret;
 }
+device_initcall(treo680_gpio_init);

 static void __init treo680_init(void)
 {
     pxa2xx_mfp_config(ARRAY_AND_SIZE(treo680_pin_config));
     palmphone_common_init();
-    treo680_gpio_init();
     palm27x_mmc_init(GPIO_NR_TREO_SD_DETECT_N, GPIO_NR_TREO680_SD_READONLY,
             GPIO_NR_TREO680_SD_POWER, 0);
     treo680_docg4_flash_init();
--
1.7.11.3

(Tell me if gmail screws up the whitespace and I'll send it with
git-send-email ...)

Yours,
Linus Walleij


From shawn.guo at linaro.org  Tue Apr 23 03:34:26 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 23 Apr 2013 15:34:26 +0800
Subject: [RFC PATCH v2 05/13] ARM: mach-imx: cpus/cpu nodes dts updates
In-Reply-To: <1366644455-16550-6-git-send-email-lorenzo.pieralisi@arm.com>
References: <1366644455-16550-1-git-send-email-lorenzo.pieralisi@arm.com>
 <1366644455-16550-6-git-send-email-lorenzo.pieralisi@arm.com>
Message-ID: <20130423073425.GB27475@S2101-09.ap.freescale.net>

On Mon, Apr 22, 2013 at 04:27:27PM +0100, Lorenzo Pieralisi wrote:
> This patch updates the in-kernel dts files according to the latest cpus
> and cpu bindings updates for ARM.
> 
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>

Acked-by: Shawn Guo <shawn.guo at linaro.org>

> ---
>  arch/arm/boot/dts/imx23.dtsi | 2 +-
>  arch/arm/boot/dts/imx28.dtsi | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/imx23.dtsi b/arch/arm/boot/dts/imx23.dtsi
> index 56afcf4..d98330c 100644
> --- a/arch/arm/boot/dts/imx23.dtsi
> +++ b/arch/arm/boot/dts/imx23.dtsi
> @@ -24,7 +24,7 @@
>  
>  	cpus {
>  		cpu at 0 {
> -			compatible = "arm,arm926ejs";
> +			compatible = "arm,arm926";
>  		};
>  	};
>  
> diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
> index 7ba4966..8c5a3ba 100644
> --- a/arch/arm/boot/dts/imx28.dtsi
> +++ b/arch/arm/boot/dts/imx28.dtsi
> @@ -33,7 +33,7 @@
>  
>  	cpus {
>  		cpu at 0 {
> -			compatible = "arm,arm926ejs";
> +			compatible = "arm,arm926";
>  		};
>  	};
>  
> -- 
> 1.7.12
> 
> 



From p.zabel at pengutronix.de  Tue Apr 23 03:41:02 2013
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Tue, 23 Apr 2013 09:41:02 +0200
Subject: [RFC][PATCH] video: imx: Select VIDEOMODE_HELPERS
In-Reply-To: <201304230157.47992.marex@denx.de>
References: <1366666110-9585-1-git-send-email-marex@denx.de>
 <CAOMZO5Av8RyptoxAQ13Psxjjd4nhHVbEJoVm6SqyLr55bPmSng@mail.gmail.com>
 <201304230157.47992.marex@denx.de>
Message-ID: <1366702862.4365.2.camel@pizza.hi.pengutronix.de>

Hi Marek,

Am Dienstag, den 23.04.2013, 01:57 +0200 schrieb Marek Vasut:
> Dear Fabio Estevam,
> 
> > Hi Marek,
> > 
> > On Mon, Apr 22, 2013 at 6:28 PM, Marek Vasut <marex at denx.de> wrote:
> > > Without this, I get the following problem when building kernel:
> > > 
> > > drivers/built-in.o: In function `imx_pd_connector_get_modes':
> > > /linux-2.6/drivers/staging/imx-drm/parallel-display.c:78: undefined
> > > reference to `of_get_drm_display_mode' make: *** [vmlinux] Error 1
> > > 
> > > NOTE: I think this patch is almost absolutely not correct.
> > > 
> > > Signed-off-by: Marek Vasut <marex at denx.de>
> > > Cc: Sascha Hauer <s.hauer at pengutronix.de>
> > > Cc: Philipp Zabel <p.zabel at pengutronix.de>
> > > Cc: Fabio Estevam <fabio.estevam at freescale.com>
> > 
> > Patch looks good, but you should have copied Greg Kroah-Hartman, as he
> > is the one who takes patches into staging.
> 
> I'm not sure if the select is at correct symbol, I dont think it is.

OF_VIDEOMODE is the correct one. The implementation of
of_get_drm_display_mode in drivers/gpu/drm/drm_modes.c depends on it.

regards
Philipp



From peter.ujfalusi at ti.com  Tue Apr 23 03:42:51 2013
From: peter.ujfalusi at ti.com (Peter Ujfalusi)
Date: Tue, 23 Apr 2013 09:42:51 +0200
Subject: Query on pinctrl usage for DT nodes
In-Reply-To: <20130416213232.GU10155@atomide.com>
References: <CA+V-a8uiPwsAD--OHFAE=i2ed+-wbXm4p2deZXr92+Zv6GDS1w@mail.gmail.com>
 <515C5C76.3080009@wwwdotorg.org>
 <CA+V-a8t3wtP77DdeUoQHKMjAuWmV+ude+1J3UjJmMTqobgStjA@mail.gmail.com>
 <5162FD4A.1030909@wwwdotorg.org>
 <CA+V-a8vwdCkyMqiynj5BodXbjwJ=e4qNb-29FhLweqbjc7DBQA@mail.gmail.com>
 <5165A22B.4070200@wwwdotorg.org> <20130410203408.GP10155@atomide.com>
 <516BB99F.2080502@ti.com> <20130416213232.GU10155@atomide.com>
Message-ID: <51763B7B.707@ti.com>

On 04/16/2013 11:32 PM, Tony Lindgren wrote:
> * Peter Ujfalusi <peter.ujfalusi at ti.com> [130415 01:30]:
>> On 04/10/2013 10:34 PM, Tony Lindgren wrote:
>>> Yeah how about just change the pintctrl-single,bits register
>>> naming to be register + bit?  Something like 0xdeadbeef.0 and
>>> 0xdeadbeef.1 and so on.
>>
>> Something like this might work I think. It is going to be a bit tricky IMHO
>> since we might need span out new 'register' every time a device requests for a
>> new pinctrl-single,bits for already used register in the
>> pinctrl-single,bit-per-mux area. In this way we still can make sure that
>> certain bit are only used by a single driver.
> 
> OK. If it's one bit per mux type register we should be able to create
> the right amount of entries based on the submask in pinctrs-single,bit?

Right now it seams to be true that we have one bit per mux (in DEVCONF0 on
OMAP3 for example). So that would work fine, but There could be different
registers around with more than one bit per mux.

Another way to deal with this is to:
in case of pinctrl-single,bit-per-mux we assume one bit per mux and create
entries based on the pinctrl-single,function-mask's bits.

In case we have more than one bit for the mux in the register we could have
optional property stating the number of different muxes handled by the register.

One bit per mux type:

control_devconf0: pinmux at 48002274 {
        compatible = "pinctrl-single";
        reg = <0x48002274 4>;   /* Single register */
        #address-cells = <1>;
        #size-cells = <0>;
        pinctrl-single,bit-per-mux;
        pinctrl-single,register-width = <32>;
        pinctrl-single,function-mask = <0x5F>;
};

Results six entries.

control_devconf0: pinmux at 48002274 {
        compatible = "pinctrl-single";
        reg = <0x48002274 4>;   /* Single register */
        #address-cells = <1>;
        #size-cells = <0>;
        pinctrl-single,bit-per-mux;
        pinctrl-single,functions-in-register = <3>;
        pinctrl-single,register-width = <32>;
        pinctrl-single,function-mask = <0x5F>;
};

Will results three entries.

In both cases we still need to test overlaps in the handled bits.

-- 
P?ter


From marc.zyngier at arm.com  Tue Apr 23 03:45:51 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Tue, 23 Apr 2013 09:45:51 +0200
Subject: [PATCH] ARM: mm: Get rid of
 =?UTF-8?Q?L=5FPTE=5FUSER=20ref=20from=20P?=
 =?UTF-8?Q?AGE=5FS=32=5FDEVICE?=
In-Reply-To: <1366683430-24328-1-git-send-email-cdall@cs.columbia.edu>
References: <1366683430-24328-1-git-send-email-cdall@cs.columbia.edu>
Message-ID: <062dea0374552dcb48be3687ae95262d@localhost>

On Mon, 22 Apr 2013 19:17:10 -0700, Christoffer Dall
<cdall at cs.columbia.edu> wrote:
> THe L_PTE_USER actually has nothing to do with stage 2 mappings and the
> L_PTE_S2_RDONLY value sets the readable bit, which was what L_PTE_USER
> was used for before proper handling of stage 2 memory defines.
> 
> Signed-off-by: Christoffer Dall <cdall at cs.columbia.edu>
> ---
>  arch/arm/include/asm/pgtable.h |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/include/asm/pgtable.h
> b/arch/arm/include/asm/pgtable.h
> index 80d6fc4..1d1f97f 100644
> --- a/arch/arm/include/asm/pgtable.h
> +++ b/arch/arm/include/asm/pgtable.h
> @@ -88,7 +88,7 @@ extern pgprot_t		pgprot_s2_device;
>  #define PAGE_HYP		_MOD_PROT(pgprot_kernel, L_PTE_HYP)
>  #define PAGE_HYP_DEVICE		_MOD_PROT(pgprot_hyp_device, L_PTE_HYP)
>  #define PAGE_S2			_MOD_PROT(pgprot_s2, L_PTE_S2_RDONLY)
> -#define PAGE_S2_DEVICE		_MOD_PROT(pgprot_s2_device, L_PTE_USER |
> L_PTE_S2_RDONLY)
> +#define PAGE_S2_DEVICE		_MOD_PROT(pgprot_s2_device, L_PTE_S2_RDONLY)
>  
>  #define __PAGE_NONE		__pgprot(_L_PTE_DEFAULT | L_PTE_RDONLY | L_PTE_XN
|
>  L_PTE_NONE)
>  #define __PAGE_SHARED		__pgprot(_L_PTE_DEFAULT | L_PTE_USER | L_PTE_XN)

Good catch.

While we're at it, why not directly set it to be RW instead of RO? The
only use of PAGE_S2_DEVICE immediately sets the writeable bit anyway.

        M.
-- 
Fast, cheap, reliable. Pick two.


From haojian.zhuang at linaro.org  Tue Apr 23 03:49:43 2013
From: haojian.zhuang at linaro.org (Haojian Zhuang)
Date: Tue, 23 Apr 2013 15:49:43 +0800
Subject: gpio-pxa initcall level change and machine init breakage
In-Reply-To: <CACRpkdbk24kR75fanvXVAocnuozNq_=jWDSPHPCWhbZCOrN5_Q@mail.gmail.com>
References: <5172B398.7060706@newsguy.com>
 <CAD6h2NSRA9w7GZLQGgK-+TvEAsxwOHow5_26JyVUA6YQyj3OQg@mail.gmail.com>
 <517466F6.3000003@newsguy.com>
 <CAD6h2NSy0=3P-PHdCiJJQG_jvGaFnr7uex+Uxs=0F-VsUxtPWg@mail.gmail.com>
 <CACRpkdbk24kR75fanvXVAocnuozNq_=jWDSPHPCWhbZCOrN5_Q@mail.gmail.com>
Message-ID: <CAD6h2NSpDc-uaB5e5BLmr1u89PZ1Z-wQO=a77JtBcmL0R+iTdA@mail.gmail.com>

On 23 April 2013 15:26, Linus Walleij <linus.walleij at linaro.org> wrote:
> On Mon, Apr 22, 2013 at 2:58 AM, Haojian Zhuang
> <haojian.zhuang at linaro.org> wrote:
>> On 22 April 2013 06:23, Mike Dunn <mikedunn at newsguy.com> wrote:
>>> Will the big guy see this?  Only posted to linux-arm-kernel ML.
>>>
>>> Thanks Haojian,
>>> Mike
>
> I guess Haojian is referring to me, not Torvalds ...
>
>> Sorry, I forgot to loop him in.
>>
>> Linus,
>> Should I send the revert commit to you? Or will you revert it directly?
>
> How hard is it to fix the real problem?
>
> I'm looking at arch/arm/mach-pxa/palmtreo.c, would
> something like this solve the problem:
>
Your fix could resolve the issue on palmtreo. After grep
gpio_request() in arch-pxa,
I found that there're a lot of files using gpio_request() in .init_machine().

Regards
Haojian


From cedric at precidata.com  Tue Apr 23 04:02:20 2013
From: cedric at precidata.com (Cedric Berger)
Date: Tue, 23 Apr 2013 10:02:20 +0200 (CEST)
Subject: [PATCH 4/10] LPC32XX: 004-mmc.2: Enable dma for Phytec board (V2)
Message-ID: <mailman.0.1366704147.1125.linux-arm-kernel@lists.infradead.org>

Enable DMA for phy3250. Without that, the mmc driver is unusable.

Signed-off-by: Gabriele Mondada <gabriele at precidata.com>
---

Index: arch/arm/mach-lpc32xx/phy3250.c
===================================================================
--- arch/arm/mach-lpc32xx/phy3250.c	(revision 1769)
+++ arch/arm/mach-lpc32xx/phy3250.c	(working copy)
@@ -168,6 +168,12 @@
 		.max_signal = 12,
 		.periph_buses = PL08X_AHB1,
 	},
+	{
+		.bus_id = "mmc",
+		.min_signal = 4,
+		.max_signal = 4,
+		.periph_buses = PL08X_AHB1,
+	},
 };
 
 static int pl08x_get_signal(const struct pl08x_channel_data *cd)
@@ -202,9 +208,14 @@
 	.ocr_mask	= MMC_VDD_30_31 | MMC_VDD_31_32 |
 			  MMC_VDD_32_33 | MMC_VDD_33_34,
 	.ios_handler	= mmc_handle_ios,
-	.dma_filter	= NULL,
-	/* No DMA for now since AMBA PL080 dmaengine driver only does scatter
-	 * gather, and the MMCI driver doesn't do it this way */
+	.dma_filter	= pl08x_filter_id,
+	.dma_quirks	= MCI_DMA_QUIRK_PL18X_RX | MCI_DMA_QUIRK_PL18X_TX,
+	.dma_rx_param	= "mmc",
+	/*
+	 * When not defined, tx channel is the same as rx.
+	 * Defining dma_tx_param with the same value as dma_rx_param does not
+	 * work.
+	 */
 };
 
 static struct lpc32xx_slc_platform_data lpc32xx_slc_data = {


From cedric at precidata.com  Tue Apr 23 04:02:19 2013
From: cedric at precidata.com (Cedric Berger)
Date: Tue, 23 Apr 2013 10:02:19 +0200 (CEST)
Subject: [PATCH 3/10] LPC32XX: 003-mmc.2: Cleanup,
 Don't access private fields in MMC controller (V2)
Message-ID: <mailman.1.1366704159.1125.linux-arm-kernel@lists.infradead.org>

The mmci_set_clkreg() function violates its general contract by accessing
directly private host->mmc fields. This prevents us from implementing a MUX
on top of this driver. Fix that by changing slightly the function prototype.

Signed-off-by: Gabriele Mondada <gabriele at precidata.com>
---

Index: drivers/mmc/host/mmci.c
===================================================================
--- drivers/mmc/host/mmci.c	(revision 1726)
+++ drivers/mmc/host/mmci.c	(revision 1727)
@@ -207,10 +207,11 @@
 /*
  * This must be called with host->lock held
  */
-static void mmci_set_clkreg(struct mmci_host *host, unsigned int desired)
+static void mmci_set_clkreg(struct mmci_host *host, struct mmc_ios *ios)
 {
 	struct variant_data *variant = host->variant;
 	u32 clk = variant->clkreg;
+	unsigned int desired = ios->clock;
 
 	if (desired) {
 		if (desired >= host->mclk) {
@@ -246,12 +247,12 @@
 		/* clk |= MCI_CLK_PWRSAVE; */
 	}
 
-	if (host->mmc->ios.bus_width == MMC_BUS_WIDTH_4)
+	if (ios->bus_width == MMC_BUS_WIDTH_4)
 		clk |= MCI_4BIT_BUS;
-	if (host->mmc->ios.bus_width == MMC_BUS_WIDTH_8)
+	if (ios->bus_width == MMC_BUS_WIDTH_8)
 		clk |= MCI_ST_8BIT_BUS;
 
-	if (host->mmc->ios.timing == MMC_TIMING_UHS_DDR50)
+	if (ios->timing == MMC_TIMING_UHS_DDR50)
 		clk |= MCI_ST_UX500_NEG_EDGE;
 
 	mmci_write_clkreg(host, clk);
@@ -1319,7 +1320,7 @@
 
 	spin_lock_irqsave(&host->lock, flags);
 
-	mmci_set_clkreg(host, ios->clock);
+	mmci_set_clkreg(host, ios);
 	mmci_write_pwrreg(host, pwr);
 
 	spin_unlock_irqrestore(&host->lock, flags);


From cedric at precidata.com  Tue Apr 23 04:02:17 2013
From: cedric at precidata.com (Cedric Berger)
Date: Tue, 23 Apr 2013 10:02:17 +0200 (CEST)
Subject: [PATCH 1/10] LPC32XX: 001-mmc.2: Define + Implement DMA_FORCE_BURST
 for pl08x (V2)
Message-ID: <mailman.2.1366704174.1125.linux-arm-kernel@lists.infradead.org>

To implement the MMC driver on LPC32xx (and other silicon using PL08x+PL18x),
we need a way to force a DMA burst by software. This patch defines a new
DMA_FORCE_BURST hook and implements it for the pl08x.c

Signed-off-by: Gabriele Mondada <gabriele at precidata.com>
---

Index: include/linux/dmaengine.h
===================================================================
--- include/linux/dmaengine.h	(revision 1688)
+++ include/linux/dmaengine.h	(revision 1736)
@@ -208,6 +208,7 @@
  * argument of struct dma_slave_config must be passed in with this
  * command.
  * @FSLDMA_EXTERNAL_START: this command will put the Freescale DMA controller
+ * @DMA_FORCE_BURST: force DMA burst
  * into external start mode.
  */
 enum dma_ctrl_cmd {
@@ -216,6 +217,7 @@
 	DMA_RESUME,
 	DMA_SLAVE_CONFIG,
 	FSLDMA_EXTERNAL_START,
+	DMA_FORCE_BURST,
 };
 
 /**
Index: drivers/dma/amba-pl08x.c
===================================================================
--- drivers/dma/amba-pl08x.c	(revision 1688)
+++ drivers/dma/amba-pl08x.c	(revision 1736)
@@ -448,6 +448,19 @@
 	writel(1 << ch->id, pl08x->base + PL080_TC_CLEAR);
 }
 
+/*
+ * simulate a DMA request by software, generating a burst transfer
+ */
+static void pl08x_force_burst(struct pl08x_dma_chan *plchan)
+{
+	struct pl08x_driver_data *pl08x = plchan->host;
+
+	dev_dbg(&pl08x->adev->dev, "force burst signal=%d plchan=%p\n",
+		plchan->signal, plchan);
+	if (plchan->signal >= 0)
+		writel(1 << plchan->signal, pl08x->base + PL080_SOFT_BREQ);
+}
+
 static inline u32 get_bytes_in_cctl(u32 cctl)
 {
 	/* The source width defines the number of bytes */
@@ -1574,6 +1587,9 @@
 		pl08x_resume_phy_chan(plchan->phychan);
 		plchan->state = PL08X_CHAN_RUNNING;
 		break;
+	case DMA_FORCE_BURST:
+		pl08x_force_burst(plchan);
+		break;
 	default:
 		/* Unknown command */
 		ret = -ENXIO;


From cedric at precidata.com  Tue Apr 23 04:02:18 2013
From: cedric at precidata.com (Cedric Berger)
Date: Tue, 23 Apr 2013 10:02:18 +0200 (CEST)
Subject: [PATCH 2/10] LPC32XX: 002-mmc.2: Workaround for MMC+DMA on LPC32xx
 (V2)
Message-ID: <mailman.3.1366704182.1125.linux-arm-kernel@lists.infradead.org>

Because of some PL08x and PL18x buggered up design, software workaround is
needed be integrated to maje that combination work. Here is a rework of
original NXP patch for the 3.9 kernel.

Signed-off-by: Gabriele Mondada <gabriele at precidata.com>
---

Index: include/linux/amba/mmci.h
===================================================================
--- include/linux/amba/mmci.h	(revision 1767)
+++ include/linux/amba/mmci.h	(working copy)
@@ -19,6 +19,12 @@
 #define MCI_ST_FBCLKEN		(1 << 7)
 #define MCI_ST_DATA74DIREN	(1 << 8)
 
+/*
+ * list of DMA quirks
+ */
+#define MCI_DMA_QUIRK_PL18X_RX	(1 << 0)
+#define MCI_DMA_QUIRK_PL18X_TX	(1 << 1)
+
 /* Just some dummy forwarding */
 struct dma_chan;
 
@@ -57,6 +63,8 @@
  * @dma_tx_param: parameter passed to the DMA allocation
  * filter in order to select an appropriate TX channel. If this
  * is NULL the driver will attempt to use the RX channel as a
+ * @dma_pl18x_quirks: apply quirks to make the pl08x/pl18x combination
+ * work properly, such as with nxp lpc32xx cpu.
  * bidirectional channel
  */
 struct mmci_platform_data {
@@ -70,6 +78,7 @@
 	unsigned long capabilities;
 	unsigned long capabilities2;
 	u32 sigdir;
+	u32 dma_quirks;
 	bool (*dma_filter)(struct dma_chan *chan, void *filter_param);
 	void *dma_rx_param;
 	void *dma_tx_param;
Index: drivers/mmc/host/mmci.c
===================================================================
--- drivers/mmc/host/mmci.c	(revision 1768)
+++ drivers/mmc/host/mmci.c	(working copy)
@@ -3,6 +3,7 @@
  *
  *  Copyright (C) 2003 Deep Blue Solutions, Ltd, All Rights Reserved.
  *  Copyright (C) 2010 ST-Ericsson SA
+ *  Copyright (C) 2013 Precidata Sarl, Gabriele Mondada
  *
  * 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
@@ -45,6 +46,14 @@
 
 #define DRIVER_NAME "mmci-pl18x"
 
+#define COOKIE_PREP	0x00000001
+#define COOKIE_SINGLE	0x00000002
+#define COOKIE_ID_MASK	0xFF000000
+#define COOKIE_ID_SHIFT	24
+#define COOKIE_ID(n)	(COOKIE_ID_MASK & ((n) << COOKIE_ID_SHIFT))
+
+#define DMA_QUIRKS_TX_SIZE SZ_64K
+
 static unsigned int fmax = 515633;
 
 /**
@@ -305,14 +314,38 @@
 	struct mmci_platform_data *plat = host->plat;
 	const char *rxname, *txname;
 	dma_cap_mask_t mask;
+	int i;
 
 	if (!plat || !plat->dma_filter) {
 		dev_info(mmc_dev(host->mmc), "no DMA platform data\n");
 		return;
 	}
 
-	/* initialize pre request cookie */
-	host->next_data.cookie = 1;
+	host->dma_quirks = plat->dma_quirks;
+	if (host->dma_quirks & MCI_DMA_QUIRK_PL18X_TX) {
+		/*
+		 * The PL08X+PL18X do not support sg on TX DMA. So
+		 * a temporary bounce buffer is used if more than 1 sg segment
+		 * is passed in the data request. The bounce buffer will get a
+		 * contiguous copy of the TX data and it will be used instead.
+		 */
+		for (i = 0; i < 2; i++) {
+			host->bounce_buf_pool[i].dma_v_tx = dma_alloc_coherent(
+				mmc_dev(host->mmc), DMA_QUIRKS_TX_SIZE,
+				&host->bounce_buf_pool[i].dma_p_tx, GFP_KERNEL);
+			if (host->bounce_buf_pool[i].dma_v_tx == NULL) {
+				dev_err(mmc_dev(host->mmc),
+					"error getting DMA region\n");
+				return;
+			}
+			dev_info(mmc_dev(host->mmc),
+				"DMA buffer: phy:%p, virt:%p\n",
+				(void *)host->bounce_buf_pool[i].dma_p_tx,
+				host->bounce_buf_pool[i].dma_v_tx);
+		}
+		host->bounce_buf = &host->bounce_buf_pool[0];
+		host->next_data.bounce_buf = &host->bounce_buf_pool[1];
+	}
 
 	/* Try to acquire a generic DMA engine slave channel */
 	dma_cap_zero(mask);
@@ -382,12 +415,26 @@
 static inline void mmci_dma_release(struct mmci_host *host)
 {
 	struct mmci_platform_data *plat = host->plat;
+	int i;
 
 	if (host->dma_rx_channel)
 		dma_release_channel(host->dma_rx_channel);
 	if (host->dma_tx_channel && plat->dma_tx_param)
 		dma_release_channel(host->dma_tx_channel);
 	host->dma_rx_channel = host->dma_tx_channel = NULL;
+
+	if (host->dma_quirks & MCI_DMA_QUIRK_PL18X_TX) {
+		for (i = 0; i < 2; i++) {
+			if (host->bounce_buf_pool[i].dma_v_tx == NULL)
+				continue;
+			dma_free_coherent(mmc_dev(host->mmc),
+				DMA_QUIRKS_TX_SIZE,
+				host->bounce_buf_pool[i].dma_v_tx,
+				host->bounce_buf_pool[i].dma_p_tx);
+			host->bounce_buf_pool[i].dma_v_tx = NULL;
+			host->bounce_buf_pool[i].dma_p_tx = 0;
+		}
+	}
 }
 
 static void mmci_dma_data_error(struct mmci_host *host)
@@ -396,7 +443,6 @@
 	dmaengine_terminate_all(host->dma_current);
 	host->dma_current = NULL;
 	host->dma_desc_current = NULL;
-	host->data->host_cookie = 0;
 }
 
 static void mmci_dma_unmap(struct mmci_host *host, struct mmc_data *data)
@@ -412,7 +458,9 @@
 		chan = host->dma_tx_channel;
 	}
 
-	dma_unmap_sg(chan->device->dev, data->sg, data->sg_len, dir);
+	if (!(data->host_cookie & COOKIE_SINGLE))
+		dma_unmap_sg(chan->device->dev, data->sg, data->sg_len, dir);
+	data->host_cookie = 0;
 }
 
 static void mmci_dma_finalize(struct mmci_host *host, struct mmc_data *data)
@@ -459,7 +507,8 @@
 /* prepares DMA channel and DMA descriptor, returns non-zero on failure */
 static int __mmci_dma_prep_data(struct mmci_host *host, struct mmc_data *data,
 				struct dma_chan **dma_chan,
-				struct dma_async_tx_descriptor **dma_desc)
+				struct dma_async_tx_descriptor **dma_desc,
+				struct mmci_bounce_buf *bounce_buf)
 {
 	struct variant_data *variant = host->variant;
 	struct dma_slave_config conf = {
@@ -476,7 +525,11 @@
 	struct dma_async_tx_descriptor *desc;
 	enum dma_data_direction buffer_dirn;
 	int nr_sg;
+	bool single = bounce_buf && (data->flags & MMC_DATA_WRITE) &&
+			(data->sg_len > 1);
 
+	WARN_ON(data->host_cookie);
+
 	if (data->flags & MMC_DATA_READ) {
 		conf.direction = DMA_DEV_TO_MEM;
 		buffer_dirn = DMA_FROM_DEVICE;
@@ -485,6 +538,8 @@
 		conf.direction = DMA_MEM_TO_DEV;
 		buffer_dirn = DMA_TO_DEVICE;
 		chan = host->dma_tx_channel;
+		if (host->dma_quirks & MCI_DMA_QUIRK_PL18X_TX)
+			conf.device_fc = true;
 	}
 
 	/* If there's no DMA channel, fall back to PIO */
@@ -496,23 +551,58 @@
 		return -EINVAL;
 
 	device = chan->device;
-	nr_sg = dma_map_sg(device->dev, data->sg, data->sg_len, buffer_dirn);
-	if (nr_sg == 0)
-		return -EINVAL;
+	dmaengine_slave_config(chan, &conf);
 
-	dmaengine_slave_config(chan, &conf);
-	desc = dmaengine_prep_slave_sg(chan, data->sg, nr_sg,
-					    conf.direction, DMA_CTRL_ACK);
+	if (single) {
+		int i;
+		unsigned char *dst = bounce_buf->dma_v_tx;
+		size_t len = 0;
+
+		dev_dbg(mmc_dev(host->mmc), "use bounce buffer\n");
+
+		/* Move data to contiguous buffer first, then transfer it */
+		for (i = 0; i < data->sg_len; i++) {
+			unsigned long flags;
+			struct scatterlist *sg = &data->sg[i];
+			void *src;
+
+			/* Map the current scatter buffer, copy data, unmap */
+			local_irq_save(flags);
+			src = (unsigned char *)kmap_atomic(sg_page(sg)) +
+							   sg->offset;
+			memcpy(dst + len, src, sg->length);
+			len += sg->length;
+			kunmap_atomic(src);
+			local_irq_restore(flags);
+		}
+
+		desc = dmaengine_prep_slave_single(chan, bounce_buf->dma_p_tx,
+						len, buffer_dirn, DMA_CTRL_ACK);
+	} else {
+		nr_sg = dma_map_sg(device->dev, data->sg, data->sg_len,
+				   buffer_dirn);
+		if (nr_sg == 0)
+			return -EINVAL;
+
+		desc = dmaengine_prep_slave_sg(chan, data->sg, nr_sg,
+					       conf.direction, DMA_CTRL_ACK);
+	}
+
 	if (!desc)
 		goto unmap_exit;
 
 	*dma_chan = chan;
 	*dma_desc = desc;
 
+	data->host_cookie = COOKIE_PREP;
+	if (single)
+		data->host_cookie |= COOKIE_SINGLE;
+
 	return 0;
 
  unmap_exit:
-	dma_unmap_sg(device->dev, data->sg, data->sg_len, buffer_dirn);
+	if (!single)
+		dma_unmap_sg(device->dev, data->sg, data->sg_len, buffer_dirn);
 	return -ENOMEM;
 }
 
@@ -525,14 +615,20 @@
 
 	/* No job were prepared thus do it now. */
 	return __mmci_dma_prep_data(host, data, &host->dma_current,
-				    &host->dma_desc_current);
+				    &host->dma_desc_current,
+				    host->bounce_buf);
 }
 
 static inline int mmci_dma_prep_next(struct mmci_host *host,
 				     struct mmc_data *data)
 {
 	struct mmci_host_next *nd = &host->next_data;
-	return __mmci_dma_prep_data(host, data, &nd->dma_chan, &nd->dma_desc);
+	int rv;
+	rv = __mmci_dma_prep_data(host, data, &nd->dma_chan, &nd->dma_desc,
+				    nd->bounce_buf);
+	if (!rv)
+		data->host_cookie |= COOKIE_ID(++host->next_data.cookie_cnt);
+	return rv;
 }
 
 static int mmci_dma_start_data(struct mmci_host *host, unsigned int datactrl)
@@ -569,14 +665,22 @@
 static void mmci_get_next_data(struct mmci_host *host, struct mmc_data *data)
 {
 	struct mmci_host_next *next = &host->next_data;
+	struct mmci_bounce_buf *tmp;
 
-	WARN_ON(data->host_cookie && data->host_cookie != next->cookie);
+	WARN_ON(data->host_cookie && ((data->host_cookie & COOKIE_ID_MASK) !=
+					COOKIE_ID(next->cookie_cnt)));
 	WARN_ON(!data->host_cookie && (next->dma_desc || next->dma_chan));
 
 	host->dma_desc_current = next->dma_desc;
 	host->dma_current = next->dma_chan;
 	next->dma_desc = NULL;
 	next->dma_chan = NULL;
+
+	if (host->dma_quirks & MCI_DMA_QUIRK_PL18X_TX) {
+		tmp = host->next_data.bounce_buf;
+		host->next_data.bounce_buf = host->bounce_buf;
+		host->bounce_buf = tmp;
+	}
 }
 
 static void mmci_pre_request(struct mmc_host *mmc, struct mmc_request *mrq,
@@ -584,7 +688,6 @@
 {
 	struct mmci_host *host = mmc_priv(mmc);
 	struct mmc_data *data = mrq->data;
-	struct mmci_host_next *nd = &host->next_data;
 
 	if (!data)
 		return;
@@ -594,8 +697,7 @@
 	if (mmci_validate_data(host, data))
 		return;
 
-	if (!mmci_dma_prep_next(host, data))
-		data->host_cookie = ++nd->cookie < 0 ? 1 : nd->cookie;
+	mmci_dma_prep_next(host, data);
 }
 
 static void mmci_post_request(struct mmc_host *mmc, struct mmc_request *mrq,
@@ -836,6 +938,16 @@
 		dev_err(mmc_dev(host->mmc), "stray MCI_DATABLOCKEND interrupt\n");
 
 	if (status & MCI_DATAEND || data->error) {
+		/*
+		 * On pl08x+pl18x, there is a problem with the DMA flow control
+		 * and the last burst transfer is not performed. So we force
+		 * the transfer programmatically here.
+		 */
+		if ((host->dma_quirks & MCI_DMA_QUIRK_PL18X_RX) &&
+		    (data->flags & MMC_DATA_READ) &&
+		    host->dma_rx_channel)
+			dmaengine_device_control(host->dma_rx_channel,
+			    DMA_FORCE_BURST, 0);
 		if (dma_inprogress(host))
 			mmci_dma_finalize(host, data);
 		mmci_stop_data(host);
Index: drivers/mmc/host/mmci.h
===================================================================
--- drivers/mmc/host/mmci.h	(revision 1768)
+++ drivers/mmc/host/mmci.h	(working copy)
@@ -158,10 +158,16 @@
 struct variant_data;
 struct dma_chan;
 
+struct mmci_bounce_buf {
+	void				*dma_v_tx;
+	dma_addr_t			dma_p_tx;
+};
+
 struct mmci_host_next {
 	struct dma_async_tx_descriptor	*dma_desc;
 	struct dma_chan			*dma_chan;
-	s32				cookie;
+	struct mmci_bounce_buf		*bounce_buf;
+	s32				cookie_cnt;
 };
 
 struct mmci_host {
@@ -208,6 +214,10 @@
 	struct dma_async_tx_descriptor	*dma_desc_current;
 	struct mmci_host_next	next_data;
 
+	struct mmci_bounce_buf  *bounce_buf;
+	struct mmci_bounce_buf	bounce_buf_pool[2];
+	u32			dma_quirks;
+
 #define dma_inprogress(host)	((host)->dma_current)
 #else
 #define dma_inprogress(host)	(0)


From cedric at precidata.com  Tue Apr 23 04:06:47 2013
From: cedric at precidata.com (Cedric Berger)
Date: Tue, 23 Apr 2013 10:06:47 +0200
Subject: [PATCH 2/10] LPC32XX: 002-mmc.1: Workaround for MMC+DMA on LPC32xx
In-Reply-To: <20130418095650.GK14496@n2100.arm.linux.org.uk>
References: <E1USZDI-0006T8-MV@merlin.infradead.org>
 <20130418095650.GK14496@n2100.arm.linux.org.uk>
Message-ID: <51764117.20905@precidata.com>

On 4/18/13 11:56 AM, Russell King - ARM Linux wrote:
> On Wed, Apr 17, 2013 at 10:42:50PM +0200, Cedric Berger wrote:
>> Signed-off-by: Gabriele Mondada <gabriele at precidata.com>
>> ---
>> the connection between the MMC controller and the DMA on NXP LPC32xx has
>> silicon bugs. NXP did a patch to workaround this, but it has not been commited
>> on the main branch. This is a rework of that patch for 3.9 kernel.
>
> Again, this should be in the commit description.
>
>> +#ifdef CONFIG_ARCH_LPC32XX
>> +	/*
>> +	 * The LPC32XX do not support sg on TX DMA. So
>> +	 * a temporary bounce buffer is used if more than 1 sg segment
>> +	 * is passed in the data request. The bounce buffer will get a
>> +	 * contiguous copy of the TX data and it will be used instead.
>> +	 */
>
> I don't think this is a silicon bug.  If you read the PL08x and PL18x
> manuals carefully, you will come to the realisation that the whole thing
> is a buggered up design - the PL08x will ignore the individual segment
> lengths when using flow control, and rely on the PL18x to tell it when
> to move to the next DMA segment, but the PL18x will only signal that at
> the end of the transfer.
>
> Someone in ARM Ltd did not have their head screwed on properly when they
> designed this.  I decided to totally scrap the idea of getting this crap
> working on ARMs evaluation boards because of this - but if we have real
> platforms with this problem, we shouldn't limit it to just those
> platforms.
>
> However, the problem affects both transmit and receive sides when flow
> control is used - I don't remember if FC is supposed to be used with
> receive with the PL18x though.

Hello,

I just sent a new set of patches (the first 4 mmc-related).
Is that something like that you wanted?

Thanks for looking into that.
Cedric



From paul at pwsan.com  Tue Apr 23 04:19:52 2013
From: paul at pwsan.com (Paul Walmsley)
Date: Tue, 23 Apr 2013 08:19:52 +0000 (UTC)
Subject: [PATCH 2/8] ARM: OMAP2+: hwmod: Cleanup sidle/mstandby programming
In-Reply-To: <516FD093.1020607@ti.com>
References: <1361354272-18089-1-git-send-email-santosh.shilimkar@ti.com>
 <1361354272-18089-3-git-send-email-santosh.shilimkar@ti.com>
 <alpine.DEB.2.00.1303310053351.6436@utopia.booyaka.com>
 <515947D3.50904@ti.com> <516FD093.1020607@ti.com>
Message-ID: <alpine.DEB.2.00.1304230804410.30196@utopia.booyaka.com>

Hi Rajendra,

On Thu, 18 Apr 2013, Rajendra Nayak wrote:

> >>> _enable_wakeup() and _disable_wakeup() are expected to program the
> >>> OCP_SYSCONFIG.ENAWAKEUP bit.
> >>
> >> These functions were originally intended to take care of everything needed 
> >> for the IP block to wake up the chip, including the PRCM WKEN programming.  
> >> ENAWAKEUP is simply one part of that.
> >>
> >>> Get rid of the additional sidle/mstandby programming in them, as its 
> >>> confusing (this is expected to be handled elsewhere as part of 
> >>> _enable_sysc()/__idle_sysc())
> >>
> >> Sorry, why does the expectation exist for the code to enable and disable 
> >> device wakeup to be part of _enable_sysc()/_idle_sysc(), rather than in 
> >> functions called by _enable_sysc()/_idle_sysc()?
> > 
> > It all comes down to if SIDLE_SMART_WKUP/MSTANDBY_SMART_WKUP programming
> > be considered as 'idlemode' programming or 'enwakeup' programming.
> > If you consider these are being part of 'enwakeup' progrmming, these should
> > certainly be handled as part of _enable_wakeup() and _disable_wakeup().
> > 
> > Today, in some cases, these are *also* handled as part of _enable_sysc()
> > and _idle_sysc(). The way _enable_wakeup() is invoked from _enable_sysc()
> > is also very inconsistent. For instance, for any IP which supports
> > SYSC_HAS_MIDLEMODE and SYSC_HAS_ENAWAKEUP, we invoke _enable_wakeup()
> > regardless of the MIDLEMODE programmmed.
> > While in case of the IP supporting SYSC_HAS_SIDLEMODE, _enable_wakeup() is
> > invoked only when the SIDLEMODE programmed is SMART or SMART_WKUP.
> > 
> > I understand the cleanups you are suggesting below as part of the movement
> > of some of these things outside of mach-omap2.
> > I was more looking at fixing the existing piece so its readable and does
> > things more consistently.
> 
> Do you have any further thoughts on how we should do about this?

Is it possible to implement a solution that preserves _enable_wakeup() and 
_disable_wakeup() as distinct functions, that can be called by separate 
wakeup control entry points?

If it makes sense to change _enable_sysc() so that it doesn't call 
_enable_wakeup(), but does similar work itself, that's fine with me, as 
long as there's not too much code duplication.

It will be good to have the inconsistencies fixed.


- Paul


From daniel.lezcano at linaro.org  Tue Apr 23 04:54:30 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Tue, 23 Apr 2013 10:54:30 +0200
Subject: [V4 patch 00/15] cpuidle: code consolidation
Message-ID: <1366707285-12179-1-git-send-email-daniel.lezcano@linaro.org>

This patchset series provide some code consolidation across the different
cpuidle drivers. It contains two parts, the first one is the removal of
the time keeping flag and the second one, is a common initialization routine.

All the drivers use the en_core_tk_irqen flag, which means it is not necessary
to make the time computation optional. We can remove this flag and assume the
cpuidle framework always manage this operation.

The cpuidle code initialization is duplicated across the different drivers in
the same manner.

The repeating pattern is:

SMP:

cpuidle_register_driver(drv);
for_each_possible_cpu(cpu) {
        dev = per_cpu(cpuidle_device, cpu);
        cpuidle_register_device(dev);
}

UP:

cpuidle_register_driver(drv);
cpuidle_register_device(dev);

As on a UP machine the macro 'for_each_cpu' is a one iteration loop, using the
initialization loop from SMP to UP works.

The patchset does some cleanup for different drivers in order to make the init
code the same. Then it introduces a generic function:

  cpuidle_register(struct cpuidle_driver *drv, struct cpumask *cpumask)

The cpumask is for the coupled idle states.

The drivers are then modified to take into account this new function and
to remove the duplicated code.

The benefit is observable in the diffstat: 332 lines of code removed.

Changelog:
 - V4:
   * Added the different Acked-by and Reviewed-by
   * Removed the patches already merged:
     * ARM: shmobile: cpuidle: remove shmobile_enter_wfi function
     * ARM: shmobile: cpuidle: remove shmobile_enter_wfi prototype
     * ARM: OMAP3: remove cpuidle_wrap_enter
   * Removed patch without acked-by (no answer from the maintainer)
     * ARM: s3c64xx: cpuidle: use init/exit common routine

 - V3:
   * folded patch 5/19 into 19/19, they were:
     * ARM: imx: cpuidle: use init/exit common routine
     * ARM: imx: cpuidle: create separate drivers for imx5/imx6
   * removed rule to make cpuidle.o in the imx's Makefile
   * splitted patch 1/19 into two, they are:
     * [V3 patch 01/19] ARM: shmobile: cpuidle: remove shmobile_enter_wfi
     * [V3 patch 02/19] ARM: shmobile: cpuidle: remove shmobile_enter_wfi prototype

 - V2:
   * fixed cpumask NULL test for coupled state in cpuidle_register
   * added comment about structure copy
   * changed printk by pr_err
   * folded splitted message
   * fixed return code in cpuidle_register
   * updated Documentation/cpuidle/drivers.txt
   * added in the changelog dev->state_count is filled by cpuidle_enable_device
   * fixed tag for tegra in the first line patch description
   * fixed tegra2 removed tegra_tear_down_cpu = tegra20_tear_down_cpu;

 - V1: Initial post

Tested-on: u8500
Tested-on: at91
Tested-on: intel i5
Tested-on: OMAP4
Tested-by: Kevin Hilman <khilman at linaro.org> # OMAP3, OMAP4
Tested-by: Andrew Lunn <andrew at lunn.ch> # Kirkwood

Compiled with and without CPU_IDLE for:
 u8500, at91, davinci, exynos, imx5, imx6, kirkwood, multi_v7 (for calxeda),
 omap2plus, s3c64, tegra1, tegra2, tegra3

Daniel Lezcano (15):
  cpuidle: remove en_core_tk_irqen flag
  ARM: ux500: cpuidle: replace for_each_online_cpu by
    for_each_possible_cpu
  cpuidle: make a single register function for all
  ARM: ux500: cpuidle: use init/exit common routine
  ARM: at91: cpuidle: use init/exit common routine
  ARM: OMAP3: cpuidle: use init/exit common routine
  ARM: tegra: cpuidle: use init/exit common routine
  ARM: shmobile: cpuidle: use init/exit common routine
  ARM: OMAP4: cpuidle: use init/exit common routine
  ARM: tegra: cpuidle: use init/exit common routine for tegra2
  ARM: tegra: cpuidle: use init/exit common routine for tegra3
  ARM: calxeda: cpuidle: use init/exit common routine
  ARM: kirkwood: cpuidle: use init/exit common routine
  ARM: davinci: cpuidle: use init/exit common routine
  ARM: imx: cpuidle: use init/exit common routine

 Documentation/cpuidle/driver.txt                |    6 +
 arch/arm/mach-at91/cpuidle.c                    |   18 +--
 arch/arm/mach-davinci/cpuidle.c                 |   21 +---
 arch/arm/mach-exynos/cpuidle.c                  |    1 -
 arch/arm/mach-imx/Makefile                      |    2 +-
 arch/arm/mach-imx/cpuidle-imx5.c                |   37 ++++++
 arch/arm/mach-imx/cpuidle-imx6q.c               |    3 +-
 arch/arm/mach-imx/cpuidle.c                     |   80 -------------
 arch/arm/mach-imx/cpuidle.h                     |   10 +-
 arch/arm/mach-imx/pm-imx5.c                     |   30 +----
 arch/arm/mach-omap2/cpuidle34xx.c               |   23 +---
 arch/arm/mach-omap2/cpuidle44xx.c               |   27 +----
 arch/arm/mach-s3c64xx/cpuidle.c                 |    1 -
 arch/arm/mach-shmobile/cpuidle.c                |   11 +-
 arch/arm/mach-shmobile/pm-sh7372.c              |    1 -
 arch/arm/mach-tegra/cpuidle-tegra114.c          |   27 +----
 arch/arm/mach-tegra/cpuidle-tegra20.c           |   31 +----
 arch/arm/mach-tegra/cpuidle-tegra30.c           |   28 +----
 arch/arm/mach-ux500/cpuidle.c                   |   33 +-----
 arch/powerpc/platforms/pseries/processor_idle.c |    1 -
 arch/sh/kernel/cpu/shmobile/cpuidle.c           |    1 -
 arch/x86/kernel/apm_32.c                        |    1 -
 drivers/acpi/processor_idle.c                   |    1 -
 drivers/cpuidle/cpuidle-calxeda.c               |   53 +--------
 drivers/cpuidle/cpuidle-kirkwood.c              |   18 +--
 drivers/cpuidle/cpuidle.c                       |  144 ++++++++++++++---------
 drivers/idle/intel_idle.c                       |    1 -
 include/linux/cpuidle.h                         |   20 ++--
 28 files changed, 162 insertions(+), 468 deletions(-)
 create mode 100644 arch/arm/mach-imx/cpuidle-imx5.c
 delete mode 100644 arch/arm/mach-imx/cpuidle.c

-- 
1.7.9.5



From daniel.lezcano at linaro.org  Tue Apr 23 04:54:32 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Tue, 23 Apr 2013 10:54:32 +0200
Subject: [V4 patch 02/15] ARM: ux500: cpuidle: replace for_each_online_cpu by
 for_each_possible_cpu
In-Reply-To: <1366707285-12179-1-git-send-email-daniel.lezcano@linaro.org>
References: <1366707285-12179-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1366707285-12179-3-git-send-email-daniel.lezcano@linaro.org>

All the drivers are using, in their initialization function, the
for_each_possible_cpu macro.

Using for_each_online_cpu means the driver must handle the initialization
of the cpuidle device when a cpu is up which is not the case here.

Change the macro to for_each_possible_cpu as that fix the hotplug
initialization and make the initialization routine consistent with the
rest of the code in the different drivers.

Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
Acked-by: Linus Walleij <linus.walleij at linaro.org>
---
 arch/arm/mach-ux500/cpuidle.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-ux500/cpuidle.c b/arch/arm/mach-ux500/cpuidle.c
index c29c1bf..5657d4a 100644
--- a/arch/arm/mach-ux500/cpuidle.c
+++ b/arch/arm/mach-ux500/cpuidle.c
@@ -125,7 +125,7 @@ int __init ux500_idle_init(void)
 		return ret;
 	}
 
-	for_each_online_cpu(cpu) {
+	for_each_possible(cpu) {
 		device = &per_cpu(ux500_cpuidle_device, cpu);
 		device->cpu = cpu;
 		ret = cpuidle_register_device(device);
@@ -139,7 +139,7 @@ out:
 	return ret;
 
 out_unregister:
-	for_each_online_cpu(cpu) {
+	for_each_possible_cpu(cpu) {
 		device = &per_cpu(ux500_cpuidle_device, cpu);
 		cpuidle_unregister_device(device);
 	}
-- 
1.7.9.5



From daniel.lezcano at linaro.org  Tue Apr 23 04:54:31 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Tue, 23 Apr 2013 10:54:31 +0200
Subject: [V4 patch 01/15] cpuidle: remove en_core_tk_irqen flag
In-Reply-To: <1366707285-12179-1-git-send-email-daniel.lezcano@linaro.org>
References: <1366707285-12179-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1366707285-12179-2-git-send-email-daniel.lezcano@linaro.org>

The en_core_tk_irqen flag is set in all the cpuidle driver which
means it is not necessary to specify this flag.

Remove the flag and the code related to it.

Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
Acked-by: Kevin Hilman <khilman at linaro.org>  # for mach-omap2/*
---
 arch/arm/mach-at91/cpuidle.c                    |    1 -
 arch/arm/mach-davinci/cpuidle.c                 |    1 -
 arch/arm/mach-exynos/cpuidle.c                  |    1 -
 arch/arm/mach-imx/cpuidle-imx6q.c               |    1 -
 arch/arm/mach-imx/pm-imx5.c                     |    1 -
 arch/arm/mach-omap2/cpuidle34xx.c               |    1 -
 arch/arm/mach-omap2/cpuidle44xx.c               |    1 -
 arch/arm/mach-s3c64xx/cpuidle.c                 |    1 -
 arch/arm/mach-shmobile/cpuidle.c                |    1 -
 arch/arm/mach-shmobile/pm-sh7372.c              |    1 -
 arch/arm/mach-tegra/cpuidle-tegra114.c          |    1 -
 arch/arm/mach-tegra/cpuidle-tegra20.c           |    1 -
 arch/arm/mach-tegra/cpuidle-tegra30.c           |    1 -
 arch/arm/mach-ux500/cpuidle.c                   |    1 -
 arch/powerpc/platforms/pseries/processor_idle.c |    1 -
 arch/sh/kernel/cpu/shmobile/cpuidle.c           |    1 -
 arch/x86/kernel/apm_32.c                        |    1 -
 drivers/acpi/processor_idle.c                   |    1 -
 drivers/cpuidle/cpuidle-calxeda.c               |    1 -
 drivers/cpuidle/cpuidle-kirkwood.c              |    1 -
 drivers/cpuidle/cpuidle.c                       |   72 ++++++-----------------
 drivers/idle/intel_idle.c                       |    1 -
 include/linux/cpuidle.h                         |   11 ----
 23 files changed, 18 insertions(+), 86 deletions(-)

diff --git a/arch/arm/mach-at91/cpuidle.c b/arch/arm/mach-at91/cpuidle.c
index 0c63815..0130df7 100644
--- a/arch/arm/mach-at91/cpuidle.c
+++ b/arch/arm/mach-at91/cpuidle.c
@@ -47,7 +47,6 @@ static int at91_enter_idle(struct cpuidle_device *dev,
 static struct cpuidle_driver at91_idle_driver = {
 	.name			= "at91_idle",
 	.owner			= THIS_MODULE,
-	.en_core_tk_irqen	= 1,
 	.states[0]		= ARM_CPUIDLE_WFI_STATE,
 	.states[1]		= {
 		.enter			= at91_enter_idle,
diff --git a/arch/arm/mach-davinci/cpuidle.c b/arch/arm/mach-davinci/cpuidle.c
index 22d6d4a..c2887c5 100644
--- a/arch/arm/mach-davinci/cpuidle.c
+++ b/arch/arm/mach-davinci/cpuidle.c
@@ -62,7 +62,6 @@ static int davinci_enter_idle(struct cpuidle_device *dev,
 static struct cpuidle_driver davinci_idle_driver = {
 	.name			= "cpuidle-davinci",
 	.owner			= THIS_MODULE,
-	.en_core_tk_irqen	= 1,
 	.states[0]		= ARM_CPUIDLE_WFI_STATE,
 	.states[1]		= {
 		.enter			= davinci_enter_idle,
diff --git a/arch/arm/mach-exynos/cpuidle.c b/arch/arm/mach-exynos/cpuidle.c
index fcfe025..498a7a2 100644
--- a/arch/arm/mach-exynos/cpuidle.c
+++ b/arch/arm/mach-exynos/cpuidle.c
@@ -58,7 +58,6 @@ static DEFINE_PER_CPU(struct cpuidle_device, exynos4_cpuidle_device);
 static struct cpuidle_driver exynos4_idle_driver = {
 	.name			= "exynos4_idle",
 	.owner			= THIS_MODULE,
-	.en_core_tk_irqen	= 1,
 };
 
 /* Ext-GIC nIRQ/nFIQ is the only wakeup source in AFTR */
diff --git a/arch/arm/mach-imx/cpuidle-imx6q.c b/arch/arm/mach-imx/cpuidle-imx6q.c
index a783a63..e2739ad 100644
--- a/arch/arm/mach-imx/cpuidle-imx6q.c
+++ b/arch/arm/mach-imx/cpuidle-imx6q.c
@@ -45,7 +45,6 @@ done:
 static struct cpuidle_driver imx6q_cpuidle_driver = {
 	.name = "imx6q_cpuidle",
 	.owner = THIS_MODULE,
-	.en_core_tk_irqen = 1,
 	.states = {
 		/* WFI */
 		ARM_CPUIDLE_WFI_STATE,
diff --git a/arch/arm/mach-imx/pm-imx5.c b/arch/arm/mach-imx/pm-imx5.c
index f67fd7e..4b52b3e 100644
--- a/arch/arm/mach-imx/pm-imx5.c
+++ b/arch/arm/mach-imx/pm-imx5.c
@@ -164,7 +164,6 @@ static int imx5_cpuidle_enter(struct cpuidle_device *dev,
 static struct cpuidle_driver imx5_cpuidle_driver = {
 	.name			= "imx5_cpuidle",
 	.owner			= THIS_MODULE,
-	.en_core_tk_irqen	= 1,
 	.states[0]	= {
 		.enter			= imx5_cpuidle_enter,
 		.exit_latency		= 2,
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c b/arch/arm/mach-omap2/cpuidle34xx.c
index 0ee39a8..20785b2 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -264,7 +264,6 @@ static DEFINE_PER_CPU(struct cpuidle_device, omap3_idle_dev);
 static struct cpuidle_driver omap3_idle_driver = {
 	.name             = "omap3_idle",
 	.owner            = THIS_MODULE,
-	.en_core_tk_irqen = 1,
 	.states = {
 		{
 			.enter		  = omap3_enter_idle_bm,
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c b/arch/arm/mach-omap2/cpuidle44xx.c
index 8a0e43c..d1bfb21 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -164,7 +164,6 @@ static DEFINE_PER_CPU(struct cpuidle_device, omap_idle_dev);
 static struct cpuidle_driver omap4_idle_driver = {
 	.name				= "omap4_idle",
 	.owner				= THIS_MODULE,
-	.en_core_tk_irqen		= 1,
 	.states = {
 		{
 			/* C1 - CPU0 ON + CPU1 ON + MPU ON */
diff --git a/arch/arm/mach-s3c64xx/cpuidle.c b/arch/arm/mach-s3c64xx/cpuidle.c
index ead5fab..852ff16 100644
--- a/arch/arm/mach-s3c64xx/cpuidle.c
+++ b/arch/arm/mach-s3c64xx/cpuidle.c
@@ -45,7 +45,6 @@ static DEFINE_PER_CPU(struct cpuidle_device, s3c64xx_cpuidle_device);
 static struct cpuidle_driver s3c64xx_cpuidle_driver = {
 	.name	= "s3c64xx_cpuidle",
 	.owner  = THIS_MODULE,
-	.en_core_tk_irqen = 1,
 	.states = {
 		{
 			.enter            = s3c64xx_enter_idle,
diff --git a/arch/arm/mach-shmobile/cpuidle.c b/arch/arm/mach-shmobile/cpuidle.c
index c872ae8..d671ae9 100644
--- a/arch/arm/mach-shmobile/cpuidle.c
+++ b/arch/arm/mach-shmobile/cpuidle.c
@@ -20,7 +20,6 @@ static struct cpuidle_device shmobile_cpuidle_dev;
 static struct cpuidle_driver shmobile_cpuidle_default_driver = {
 	.name			= "shmobile_cpuidle",
 	.owner			= THIS_MODULE,
-	.en_core_tk_irqen	= 1,
 	.states[0]		= ARM_CPUIDLE_WFI_STATE,
 	.safe_state_index	= 0, /* C1 */
 	.state_count		= 1,
diff --git a/arch/arm/mach-shmobile/pm-sh7372.c b/arch/arm/mach-shmobile/pm-sh7372.c
index fbef7b9..dec9293 100644
--- a/arch/arm/mach-shmobile/pm-sh7372.c
+++ b/arch/arm/mach-shmobile/pm-sh7372.c
@@ -410,7 +410,6 @@ static int sh7372_enter_a4s(struct cpuidle_device *dev,
 static struct cpuidle_driver sh7372_cpuidle_driver = {
 	.name			= "sh7372_cpuidle",
 	.owner			= THIS_MODULE,
-	.en_core_tk_irqen	= 1,
 	.state_count		= 5,
 	.safe_state_index	= 0, /* C1 */
 	.states[0] = ARM_CPUIDLE_WFI_STATE,
diff --git a/arch/arm/mach-tegra/cpuidle-tegra114.c b/arch/arm/mach-tegra/cpuidle-tegra114.c
index c527cff..c5fadf9 100644
--- a/arch/arm/mach-tegra/cpuidle-tegra114.c
+++ b/arch/arm/mach-tegra/cpuidle-tegra114.c
@@ -23,7 +23,6 @@
 static struct cpuidle_driver tegra_idle_driver = {
 	.name = "tegra_idle",
 	.owner = THIS_MODULE,
-	.en_core_tk_irqen = 1,
 	.state_count = 1,
 	.states = {
 		[0] = ARM_CPUIDLE_WFI_STATE_PWR(600),
diff --git a/arch/arm/mach-tegra/cpuidle-tegra20.c b/arch/arm/mach-tegra/cpuidle-tegra20.c
index b94d76a..f1f6ac4 100644
--- a/arch/arm/mach-tegra/cpuidle-tegra20.c
+++ b/arch/arm/mach-tegra/cpuidle-tegra20.c
@@ -51,7 +51,6 @@ static int tegra20_idle_lp2_coupled(struct cpuidle_device *dev,
 static struct cpuidle_driver tegra_idle_driver = {
 	.name = "tegra_idle",
 	.owner = THIS_MODULE,
-	.en_core_tk_irqen = 1,
 	.states = {
 		ARM_CPUIDLE_WFI_STATE_PWR(600),
 #ifdef CONFIG_PM_SLEEP
diff --git a/arch/arm/mach-tegra/cpuidle-tegra30.c b/arch/arm/mach-tegra/cpuidle-tegra30.c
index c4e01fe..f6a0c72 100644
--- a/arch/arm/mach-tegra/cpuidle-tegra30.c
+++ b/arch/arm/mach-tegra/cpuidle-tegra30.c
@@ -43,7 +43,6 @@ static int tegra30_idle_lp2(struct cpuidle_device *dev,
 static struct cpuidle_driver tegra_idle_driver = {
 	.name = "tegra_idle",
 	.owner = THIS_MODULE,
-	.en_core_tk_irqen = 1,
 #ifdef CONFIG_PM_SLEEP
 	.state_count = 2,
 #else
diff --git a/arch/arm/mach-ux500/cpuidle.c b/arch/arm/mach-ux500/cpuidle.c
index 1b16d9e..c29c1bf 100644
--- a/arch/arm/mach-ux500/cpuidle.c
+++ b/arch/arm/mach-ux500/cpuidle.c
@@ -94,7 +94,6 @@ out:
 static struct cpuidle_driver ux500_idle_driver = {
 	.name = "ux500_idle",
 	.owner = THIS_MODULE,
-	.en_core_tk_irqen = 1,
 	.states = {
 		ARM_CPUIDLE_WFI_STATE,
 		{
diff --git a/arch/powerpc/platforms/pseries/processor_idle.c b/arch/powerpc/platforms/pseries/processor_idle.c
index a197120..4644efa0 100644
--- a/arch/powerpc/platforms/pseries/processor_idle.c
+++ b/arch/powerpc/platforms/pseries/processor_idle.c
@@ -25,7 +25,6 @@
 struct cpuidle_driver pseries_idle_driver = {
 	.name             = "pseries_idle",
 	.owner            = THIS_MODULE,
-	.en_core_tk_irqen = 1,
 };
 
 #define MAX_IDLE_STATE_COUNT	2
diff --git a/arch/sh/kernel/cpu/shmobile/cpuidle.c b/arch/sh/kernel/cpu/shmobile/cpuidle.c
index ea6ab02..fdfe57f4 100644
--- a/arch/sh/kernel/cpu/shmobile/cpuidle.c
+++ b/arch/sh/kernel/cpu/shmobile/cpuidle.c
@@ -55,7 +55,6 @@ static struct cpuidle_device cpuidle_dev;
 static struct cpuidle_driver cpuidle_driver = {
 	.name   = "sh_idle",
 	.owner  = THIS_MODULE,
-	.en_core_tk_irqen = 1,
 	.states = {
 		{
 			.exit_latency = 1,
diff --git a/arch/x86/kernel/apm_32.c b/arch/x86/kernel/apm_32.c
index 66b5faf..53a4e27 100644
--- a/arch/x86/kernel/apm_32.c
+++ b/arch/x86/kernel/apm_32.c
@@ -373,7 +373,6 @@ static int apm_cpu_idle(struct cpuidle_device *dev,
 static struct cpuidle_driver apm_idle_driver = {
 	.name = "apm_idle",
 	.owner = THIS_MODULE,
-	.en_core_tk_irqen = 1,
 	.states = {
 		{ /* entry 0 is for polling */ },
 		{ /* entry 1 is for APM idle */
diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c
index ee255c6..f0df2c9 100644
--- a/drivers/acpi/processor_idle.c
+++ b/drivers/acpi/processor_idle.c
@@ -918,7 +918,6 @@ static int acpi_idle_enter_bm(struct cpuidle_device *dev,
 struct cpuidle_driver acpi_idle_driver = {
 	.name =		"acpi_idle",
 	.owner =	THIS_MODULE,
-	.en_core_tk_irqen = 1,
 };
 
 /**
diff --git a/drivers/cpuidle/cpuidle-calxeda.c b/drivers/cpuidle/cpuidle-calxeda.c
index e1aab38..a3b56f5 100644
--- a/drivers/cpuidle/cpuidle-calxeda.c
+++ b/drivers/cpuidle/cpuidle-calxeda.c
@@ -100,7 +100,6 @@ static void calxeda_idle_cpuidle_devices_uninit(void)
 
 static struct cpuidle_driver calxeda_idle_driver = {
 	.name = "calxeda_idle",
-	.en_core_tk_irqen = 1,
 	.states = {
 		ARM_CPUIDLE_WFI_STATE,
 		{
diff --git a/drivers/cpuidle/cpuidle-kirkwood.c b/drivers/cpuidle/cpuidle-kirkwood.c
index 53aad73..6f31524 100644
--- a/drivers/cpuidle/cpuidle-kirkwood.c
+++ b/drivers/cpuidle/cpuidle-kirkwood.c
@@ -41,7 +41,6 @@ static int kirkwood_enter_idle(struct cpuidle_device *dev,
 static struct cpuidle_driver kirkwood_idle_driver = {
 	.name			= "kirkwood_idle",
 	.owner			= THIS_MODULE,
-	.en_core_tk_irqen	= 1,
 	.states[0]		= ARM_CPUIDLE_WFI_STATE,
 	.states[1]		= {
 		.enter			= kirkwood_enter_idle,
diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
index c500370..0da795b 100644
--- a/drivers/cpuidle/cpuidle.c
+++ b/drivers/cpuidle/cpuidle.c
@@ -43,24 +43,6 @@ void disable_cpuidle(void)
 
 static int __cpuidle_register_device(struct cpuidle_device *dev);
 
-static inline int cpuidle_enter(struct cpuidle_device *dev,
-				struct cpuidle_driver *drv, int index)
-{
-	struct cpuidle_state *target_state = &drv->states[index];
-	return target_state->enter(dev, drv, index);
-}
-
-static inline int cpuidle_enter_tk(struct cpuidle_device *dev,
-			       struct cpuidle_driver *drv, int index)
-{
-	return cpuidle_wrap_enter(dev, drv, index, cpuidle_enter);
-}
-
-typedef int (*cpuidle_enter_t)(struct cpuidle_device *dev,
-			       struct cpuidle_driver *drv, int index);
-
-static cpuidle_enter_t cpuidle_enter_ops;
-
 /**
  * cpuidle_play_dead - cpu off-lining
  *
@@ -90,11 +72,27 @@ int cpuidle_play_dead(void)
  * @next_state: index into drv->states of the state to enter
  */
 int cpuidle_enter_state(struct cpuidle_device *dev, struct cpuidle_driver *drv,
-		int next_state)
+			int index)
 {
 	int entered_state;
 
-	entered_state = cpuidle_enter_ops(dev, drv, next_state);
+	struct cpuidle_state *target_state = &drv->states[index];
+	ktime_t time_start, time_end;
+	s64 diff;
+
+	time_start = ktime_get();
+
+	entered_state = target_state->enter(dev, drv, index);
+
+	time_end = ktime_get();
+
+	local_irq_enable();
+
+	diff = ktime_to_us(ktime_sub(time_end, time_start));
+	if (diff > INT_MAX)
+		diff = INT_MAX;
+
+	dev->last_residency = (int) diff;
 
 	if (entered_state >= 0) {
 		/* Update cpuidle counters */
@@ -231,37 +229,6 @@ void cpuidle_resume(void)
 	mutex_unlock(&cpuidle_lock);
 }
 
-/**
- * cpuidle_wrap_enter - performs timekeeping and irqen around enter function
- * @dev: pointer to a valid cpuidle_device object
- * @drv: pointer to a valid cpuidle_driver object
- * @index: index of the target cpuidle state.
- */
-int cpuidle_wrap_enter(struct cpuidle_device *dev,
-				struct cpuidle_driver *drv, int index,
-				int (*enter)(struct cpuidle_device *dev,
-					struct cpuidle_driver *drv, int index))
-{
-	ktime_t time_start, time_end;
-	s64 diff;
-
-	time_start = ktime_get();
-
-	index = enter(dev, drv, index);
-
-	time_end = ktime_get();
-
-	local_irq_enable();
-
-	diff = ktime_to_us(ktime_sub(time_end, time_start));
-	if (diff > INT_MAX)
-		diff = INT_MAX;
-
-	dev->last_residency = (int) diff;
-
-	return index;
-}
-
 #ifdef CONFIG_ARCH_HAS_CPU_RELAX
 static int poll_idle(struct cpuidle_device *dev,
 		struct cpuidle_driver *drv, int index)
@@ -333,9 +300,6 @@ int cpuidle_enable_device(struct cpuidle_device *dev)
 			return ret;
 	}
 
-	cpuidle_enter_ops = drv->en_core_tk_irqen ?
-		cpuidle_enter_tk : cpuidle_enter;
-
 	poll_idle_init(drv);
 
 	ret = cpuidle_add_device_sysfs(dev);
diff --git a/drivers/idle/intel_idle.c b/drivers/idle/intel_idle.c
index 10541da..0e8fab1 100644
--- a/drivers/idle/intel_idle.c
+++ b/drivers/idle/intel_idle.c
@@ -71,7 +71,6 @@
 static struct cpuidle_driver intel_idle_driver = {
 	.name = "intel_idle",
 	.owner = THIS_MODULE,
-	.en_core_tk_irqen = 1,
 };
 /* intel_idle.max_cstate=0 disables driver */
 static int max_cstate = CPUIDLE_STATE_MAX - 1;
diff --git a/include/linux/cpuidle.h b/include/linux/cpuidle.h
index fc3e580..79e3811 100644
--- a/include/linux/cpuidle.h
+++ b/include/linux/cpuidle.h
@@ -105,8 +105,6 @@ struct cpuidle_driver {
 	struct module 		*owner;
 	int                     refcnt;
 
-	/* set to 1 to use the core cpuidle time keeping (for all states). */
-	unsigned int		en_core_tk_irqen:1;
         /* used by the cpuidle framework to setup the broadcast timer */
 	unsigned int            bctimer:1;
 	/* states array must be ordered in decreasing power consumption */
@@ -132,10 +130,6 @@ extern void cpuidle_pause(void);
 extern void cpuidle_resume(void);
 extern int cpuidle_enable_device(struct cpuidle_device *dev);
 extern void cpuidle_disable_device(struct cpuidle_device *dev);
-extern int cpuidle_wrap_enter(struct cpuidle_device *dev,
-				struct cpuidle_driver *drv, int index,
-				int (*enter)(struct cpuidle_device *dev,
-					struct cpuidle_driver *drv, int index));
 extern int cpuidle_play_dead(void);
 
 extern struct cpuidle_driver *cpuidle_get_cpu_driver(struct cpuidle_device *dev);
@@ -162,11 +156,6 @@ static inline void cpuidle_resume(void) { }
 static inline int cpuidle_enable_device(struct cpuidle_device *dev)
 {return -ENODEV; }
 static inline void cpuidle_disable_device(struct cpuidle_device *dev) { }
-static inline int cpuidle_wrap_enter(struct cpuidle_device *dev,
-				struct cpuidle_driver *drv, int index,
-				int (*enter)(struct cpuidle_device *dev,
-					struct cpuidle_driver *drv, int index))
-{ return -ENODEV; }
 static inline int cpuidle_play_dead(void) {return -ENODEV; }
 #endif
 
-- 
1.7.9.5



From daniel.lezcano at linaro.org  Tue Apr 23 04:54:33 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Tue, 23 Apr 2013 10:54:33 +0200
Subject: [V4 patch 03/15] cpuidle: make a single register function for all
In-Reply-To: <1366707285-12179-1-git-send-email-daniel.lezcano@linaro.org>
References: <1366707285-12179-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1366707285-12179-4-git-send-email-daniel.lezcano@linaro.org>

The usual scheme to initialize a cpuidle driver on a SMP is:

	cpuidle_register_driver(drv);
	for_each_possible_cpu(cpu) {
		device = &per_cpu(cpuidle_dev, cpu);
		cpuidle_register_device(device);
	}

This code is duplicated in each cpuidle driver.

On UP systems, it is done this way:

	cpuidle_register_driver(drv);
	device = &per_cpu(cpuidle_dev, cpu);
	cpuidle_register_device(device);

On UP, the macro 'for_each_cpu' does one iteration:

#define for_each_cpu(cpu, mask)                 \
        for ((cpu) = 0; (cpu) < 1; (cpu)++, (void)mask)

Hence, the initialization loop is the same for UP than SMP.

Beside, we saw different bugs / mis-initialization / return code unchecked in
the different drivers, the code is duplicated including bugs. After fixing all
these ones, it appears the initialization pattern is the same for everyone.

Please note, some drivers are doing dev->state_count = drv->state_count. This is
not necessary because it is done by the cpuidle_enable_device function in the
cpuidle framework. This is true, until you have the same states for all your
devices. Otherwise, the 'low level' API should be used instead with the specific
initialization for the driver.

Let's add a wrapper function doing this initialization with a cpumask parameter
for the coupled idle states and use it for all the drivers.

That will save a lot of LOC, consolidate the code, and the modifications in the
future could be done in a single place. Another benefit is the consolidation of
the cpuidle_device variable which is now in the cpuidle framework and no longer
spread accross the different arch specific drivers.

Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
---
 Documentation/cpuidle/driver.txt |    6 ++++
 drivers/cpuidle/cpuidle.c        |   72 ++++++++++++++++++++++++++++++++++++++
 include/linux/cpuidle.h          |    9 +++--
 3 files changed, 85 insertions(+), 2 deletions(-)

diff --git a/Documentation/cpuidle/driver.txt b/Documentation/cpuidle/driver.txt
index 7a9e09e..1b0d81d 100644
--- a/Documentation/cpuidle/driver.txt
+++ b/Documentation/cpuidle/driver.txt
@@ -15,11 +15,17 @@ has mechanisms in place to support actual entry-exit into CPU idle states.
 cpuidle driver initializes the cpuidle_device structure for each CPU device
 and registers with cpuidle using cpuidle_register_device.
 
+If all the idle states are the same, the wrapper function cpuidle_register
+could be used instead.
+
 It can also support the dynamic changes (like battery <-> AC), by using
 cpuidle_pause_and_lock, cpuidle_disable_device and cpuidle_enable_device,
 cpuidle_resume_and_unlock.
 
 Interfaces:
+extern int cpuidle_register(struct cpuidle_driver *drv,
+                            const struct cpumask *const coupled_cpus);
+extern int cpuidle_unregister(struct cpuidle_driver *drv);
 extern int cpuidle_register_driver(struct cpuidle_driver *drv);
 extern void cpuidle_unregister_driver(struct cpuidle_driver *drv);
 extern int cpuidle_register_device(struct cpuidle_device *dev);
diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
index 0da795b..49e8d30 100644
--- a/drivers/cpuidle/cpuidle.c
+++ b/drivers/cpuidle/cpuidle.c
@@ -24,6 +24,7 @@
 #include "cpuidle.h"
 
 DEFINE_PER_CPU(struct cpuidle_device *, cpuidle_devices);
+DEFINE_PER_CPU(struct cpuidle_device, cpuidle_dev);
 
 DEFINE_MUTEX(cpuidle_lock);
 LIST_HEAD(cpuidle_detected_devices);
@@ -453,6 +454,77 @@ void cpuidle_unregister_device(struct cpuidle_device *dev)
 
 EXPORT_SYMBOL_GPL(cpuidle_unregister_device);
 
+/*
+ * cpuidle_unregister: unregister a driver and the devices. This function
+ * can be used only if the driver has been previously registered through
+ * the cpuidle_register function.
+ *
+ * @drv: a valid pointer to a struct cpuidle_driver
+ */
+void cpuidle_unregister(struct cpuidle_driver *drv)
+{
+	int cpu;
+	struct cpuidle_device *device;
+
+	for_each_possible_cpu(cpu) {
+		device = &per_cpu(cpuidle_dev, cpu);
+		cpuidle_unregister_device(device);
+	}
+
+	cpuidle_unregister_driver(drv);
+}
+EXPORT_SYMBOL_GPL(cpuidle_unregister);
+
+/**
+ * cpuidle_register: registers the driver and the cpu devices with the
+ * coupled_cpus passed as parameter. This function is used for all common
+ * initialization pattern there are in the arch specific drivers. The
+ * devices is globally defined in this file.
+ *
+ * @drv         : a valid pointer to a struct cpuidle_driver
+ * @coupled_cpus: a cpumask for the coupled states
+ *
+ * Returns 0 on success, < 0 otherwise
+ */
+int cpuidle_register(struct cpuidle_driver *drv,
+		     const struct cpumask *const coupled_cpus)
+{
+	int ret, cpu;
+	struct cpuidle_device *device;
+
+	ret = cpuidle_register_driver(drv);
+	if (ret) {
+		pr_err("failed to register cpuidle driver\n");
+		return ret;
+	}
+
+	for_each_possible_cpu(cpu) {
+		device = &per_cpu(cpuidle_dev, cpu);
+		device->cpu = cpu;
+
+#ifdef CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED
+		/*
+		 * On multiplatform for ARM, the coupled idle states could
+		 * enabled in the kernel even if the cpuidle driver does not
+		 * use it. Note, coupled_cpus is a struct copy.
+		 */
+		if (coupled_cpus)
+			device->coupled_cpus = *coupled_cpus;
+#endif
+		ret = cpuidle_register_device(device);
+		if (!ret)
+			continue;
+
+		pr_err("Failed to register cpuidle device for cpu%d\n", cpu);
+
+		cpuidle_unregister(drv);
+		break;
+	}
+
+	return ret;
+}
+EXPORT_SYMBOL_GPL(cpuidle_register);
+
 #ifdef CONFIG_SMP
 
 static void smp_callback(void *v)
diff --git a/include/linux/cpuidle.h b/include/linux/cpuidle.h
index 79e3811..3c86faa 100644
--- a/include/linux/cpuidle.h
+++ b/include/linux/cpuidle.h
@@ -123,7 +123,9 @@ extern void cpuidle_driver_unref(void);
 extern void cpuidle_unregister_driver(struct cpuidle_driver *drv);
 extern int cpuidle_register_device(struct cpuidle_device *dev);
 extern void cpuidle_unregister_device(struct cpuidle_device *dev);
-
+extern int cpuidle_register(struct cpuidle_driver *drv,
+			    const struct cpumask *const coupled_cpus);
+extern void cpuidle_unregister(struct cpuidle_driver *drv);
 extern void cpuidle_pause_and_lock(void);
 extern void cpuidle_resume_and_unlock(void);
 extern void cpuidle_pause(void);
@@ -148,7 +150,10 @@ static inline void cpuidle_unregister_driver(struct cpuidle_driver *drv) { }
 static inline int cpuidle_register_device(struct cpuidle_device *dev)
 {return -ENODEV; }
 static inline void cpuidle_unregister_device(struct cpuidle_device *dev) { }
-
+static inline int cpuidle_register(struct cpuidle_driver *drv,
+				   const struct cpumask *const coupled_cpus)
+{return -ENODEV; }
+static inline void cpuidle_unregister(struct cpuidle_driver *drv) { }
 static inline void cpuidle_pause_and_lock(void) { }
 static inline void cpuidle_resume_and_unlock(void) { }
 static inline void cpuidle_pause(void) { }
-- 
1.7.9.5



From daniel.lezcano at linaro.org  Tue Apr 23 04:54:34 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Tue, 23 Apr 2013 10:54:34 +0200
Subject: [V4 patch 04/15] ARM: ux500: cpuidle: use init/exit common routine
In-Reply-To: <1366707285-12179-1-git-send-email-daniel.lezcano@linaro.org>
References: <1366707285-12179-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1366707285-12179-5-git-send-email-daniel.lezcano@linaro.org>

Remove the duplicate code and use the cpuidle common code for initialization.

Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
Acked-by: Linus Walleij <linus.walleij at linaro.org>
---
 arch/arm/mach-ux500/cpuidle.c |   32 +-------------------------------
 1 file changed, 1 insertion(+), 31 deletions(-)

diff --git a/arch/arm/mach-ux500/cpuidle.c b/arch/arm/mach-ux500/cpuidle.c
index 5657d4a..488e074 100644
--- a/arch/arm/mach-ux500/cpuidle.c
+++ b/arch/arm/mach-ux500/cpuidle.c
@@ -21,7 +21,6 @@
 
 static atomic_t master = ATOMIC_INIT(0);
 static DEFINE_SPINLOCK(master_lock);
-static DEFINE_PER_CPU(struct cpuidle_device, ux500_cpuidle_device);
 
 static inline int ux500_enter_idle(struct cpuidle_device *dev,
 				   struct cpuidle_driver *drv, int index)
@@ -112,40 +111,11 @@ static struct cpuidle_driver ux500_idle_driver = {
 
 int __init ux500_idle_init(void)
 {
-	int ret, cpu;
-	struct cpuidle_device *device;
-
         /* Configure wake up reasons */
 	prcmu_enable_wakeups(PRCMU_WAKEUP(ARM) | PRCMU_WAKEUP(RTC) |
 			     PRCMU_WAKEUP(ABB));
 
-	ret = cpuidle_register_driver(&ux500_idle_driver);
-	if (ret) {
-		printk(KERN_ERR "failed to register ux500 idle driver\n");
-		return ret;
-	}
-
-	for_each_possible(cpu) {
-		device = &per_cpu(ux500_cpuidle_device, cpu);
-		device->cpu = cpu;
-		ret = cpuidle_register_device(device);
-		if (ret) {
-			printk(KERN_ERR "Failed to register cpuidle "
-			       "device for cpu%d\n", cpu);
-			goto out_unregister;
-		}
-	}
-out:
-	return ret;
-
-out_unregister:
-	for_each_possible_cpu(cpu) {
-		device = &per_cpu(ux500_cpuidle_device, cpu);
-		cpuidle_unregister_device(device);
-	}
-
-	cpuidle_unregister_driver(&ux500_idle_driver);
-	goto out;
+	return cpuidle_register(&ux500_idle_driver, NULL);
 }
 
 device_initcall(ux500_idle_init);
-- 
1.7.9.5



From daniel.lezcano at linaro.org  Tue Apr 23 04:54:35 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Tue, 23 Apr 2013 10:54:35 +0200
Subject: [V4 patch 05/15] ARM: at91: cpuidle: use init/exit common routine
In-Reply-To: <1366707285-12179-1-git-send-email-daniel.lezcano@linaro.org>
References: <1366707285-12179-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1366707285-12179-6-git-send-email-daniel.lezcano@linaro.org>

Remove the duplicated code and use the cpuidle common code for initialization.

Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
Acked-by: Nicolas Ferre <nicolas.ferre at atmel.com>
---
 arch/arm/mach-at91/cpuidle.c |   17 ++---------------
 1 file changed, 2 insertions(+), 15 deletions(-)

diff --git a/arch/arm/mach-at91/cpuidle.c b/arch/arm/mach-at91/cpuidle.c
index 0130df7..48f1228 100644
--- a/arch/arm/mach-at91/cpuidle.c
+++ b/arch/arm/mach-at91/cpuidle.c
@@ -27,8 +27,6 @@
 
 #define AT91_MAX_STATES	2
 
-static DEFINE_PER_CPU(struct cpuidle_device, at91_cpuidle_device);
-
 /* Actual code that puts the SoC in different idle states */
 static int at91_enter_idle(struct cpuidle_device *dev,
 			struct cpuidle_driver *drv,
@@ -60,20 +58,9 @@ static struct cpuidle_driver at91_idle_driver = {
 };
 
 /* Initialize CPU idle by registering the idle states */
-static int at91_init_cpuidle(void)
+static int __init at91_init_cpuidle(void)
 {
-	struct cpuidle_device *device;
-
-	device = &per_cpu(at91_cpuidle_device, smp_processor_id());
-	device->state_count = AT91_MAX_STATES;
-
-	cpuidle_register_driver(&at91_idle_driver);
-
-	if (cpuidle_register_device(device)) {
-		printk(KERN_ERR "at91_init_cpuidle: Failed registering\n");
-		return -EIO;
-	}
-	return 0;
+	return cpuidle_register(&at91_idle_driver, NULL);
 }
 
 device_initcall(at91_init_cpuidle);
-- 
1.7.9.5



From daniel.lezcano at linaro.org  Tue Apr 23 04:54:36 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Tue, 23 Apr 2013 10:54:36 +0200
Subject: [V4 patch 06/15] ARM: OMAP3: cpuidle: use init/exit common routine
In-Reply-To: <1366707285-12179-1-git-send-email-daniel.lezcano@linaro.org>
References: <1366707285-12179-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1366707285-12179-7-git-send-email-daniel.lezcano@linaro.org>

Remove the duplicated code and use the cpuidle common code for initialization.

Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
Acked-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
Reviewed-by: Kevin Hilman <khilman at linaro.org>
Tested-by: Kevin Hilman <khilman at linaro.org>
---
 arch/arm/mach-omap2/cpuidle34xx.c |   22 ++--------------------
 1 file changed, 2 insertions(+), 20 deletions(-)

diff --git a/arch/arm/mach-omap2/cpuidle34xx.c b/arch/arm/mach-omap2/cpuidle34xx.c
index 20785b2..cca045c 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -26,6 +26,7 @@
 #include <linux/cpuidle.h>
 #include <linux/export.h>
 #include <linux/cpu_pm.h>
+#include <asm/cpuidle.h>
 
 #include "powerdomain.h"
 #include "clockdomain.h"
@@ -259,8 +260,6 @@ static int omap3_enter_idle_bm(struct cpuidle_device *dev,
 	return ret;
 }
 
-static DEFINE_PER_CPU(struct cpuidle_device, omap3_idle_dev);
-
 static struct cpuidle_driver omap3_idle_driver = {
 	.name             = "omap3_idle",
 	.owner            = THIS_MODULE,
@@ -336,8 +335,6 @@ static struct cpuidle_driver omap3_idle_driver = {
  */
 int __init omap3_idle_init(void)
 {
-	struct cpuidle_device *dev;
-
 	mpu_pd = pwrdm_lookup("mpu_pwrdm");
 	core_pd = pwrdm_lookup("core_pwrdm");
 	per_pd = pwrdm_lookup("per_pwrdm");
@@ -346,20 +343,5 @@ int __init omap3_idle_init(void)
 	if (!mpu_pd || !core_pd || !per_pd || !cam_pd)
 		return -ENODEV;
 
-	if (cpuidle_register_driver(&omap3_idle_driver)) {
-		pr_err("%s: CPUidle driver register failed\n", __func__);
-		return -EIO;
-	}
-
-	dev = &per_cpu(omap3_idle_dev, smp_processor_id());
-	dev->cpu = 0;
-
-	if (cpuidle_register_device(dev)) {
-		printk(KERN_ERR "%s: CPUidle register device failed\n",
-		       __func__);
-		cpuidle_unregister_driver(&omap3_idle_driver);
-		return -EIO;
-	}
-
-	return 0;
+	return cpuidle_register(&omap3_idle_driver, NULL);
 }
-- 
1.7.9.5



From daniel.lezcano at linaro.org  Tue Apr 23 04:54:37 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Tue, 23 Apr 2013 10:54:37 +0200
Subject: [V4 patch 07/15] ARM: tegra: cpuidle: use init/exit common routine
In-Reply-To: <1366707285-12179-1-git-send-email-daniel.lezcano@linaro.org>
References: <1366707285-12179-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1366707285-12179-8-git-send-email-daniel.lezcano@linaro.org>

Remove the duplicated code and use the cpuidle common code for initialization.

Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
Acked-by: Stephen Warren <swarren at nvidia.com>
---
 arch/arm/mach-tegra/cpuidle-tegra114.c |   26 +-------------------------
 1 file changed, 1 insertion(+), 25 deletions(-)

diff --git a/arch/arm/mach-tegra/cpuidle-tegra114.c b/arch/arm/mach-tegra/cpuidle-tegra114.c
index c5fadf9..1d1c602 100644
--- a/arch/arm/mach-tegra/cpuidle-tegra114.c
+++ b/arch/arm/mach-tegra/cpuidle-tegra114.c
@@ -29,31 +29,7 @@ static struct cpuidle_driver tegra_idle_driver = {
 	},
 };
 
-static DEFINE_PER_CPU(struct cpuidle_device, tegra_idle_device);
-
 int __init tegra114_cpuidle_init(void)
 {
-	int ret;
-	unsigned int cpu;
-	struct cpuidle_device *dev;
-	struct cpuidle_driver *drv = &tegra_idle_driver;
-
-	ret = cpuidle_register_driver(&tegra_idle_driver);
-	if (ret) {
-		pr_err("CPUidle driver registration failed\n");
-		return ret;
-	}
-
-	for_each_possible_cpu(cpu) {
-		dev = &per_cpu(tegra_idle_device, cpu);
-		dev->cpu = cpu;
-
-		ret = cpuidle_register_device(dev);
-		if (ret) {
-			pr_err("CPU%u: CPUidle device registration failed\n",
-				cpu);
-			return ret;
-		}
-	}
-	return 0;
+	return cpuidle_register(&tegra_idle_driver, NULL);
 }
-- 
1.7.9.5



From daniel.lezcano at linaro.org  Tue Apr 23 04:54:40 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Tue, 23 Apr 2013 10:54:40 +0200
Subject: [V4 patch 10/15] ARM: tegra: cpuidle: use init/exit common routine
 for tegra2
In-Reply-To: <1366707285-12179-1-git-send-email-daniel.lezcano@linaro.org>
References: <1366707285-12179-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1366707285-12179-11-git-send-email-daniel.lezcano@linaro.org>

Remove the duplicated code and use the cpuidle common code for initialization.

Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
Acked-by: Stephen Warren <swarren at nvidia.com>
---
 arch/arm/mach-tegra/cpuidle-tegra20.c |   30 +-----------------------------
 1 file changed, 1 insertion(+), 29 deletions(-)

diff --git a/arch/arm/mach-tegra/cpuidle-tegra20.c b/arch/arm/mach-tegra/cpuidle-tegra20.c
index f1f6ac4..590ec25 100644
--- a/arch/arm/mach-tegra/cpuidle-tegra20.c
+++ b/arch/arm/mach-tegra/cpuidle-tegra20.c
@@ -70,8 +70,6 @@ static struct cpuidle_driver tegra_idle_driver = {
 	.safe_state_index = 0,
 };
 
-static DEFINE_PER_CPU(struct cpuidle_device, tegra_idle_device);
-
 #ifdef CONFIG_PM_SLEEP
 #ifdef CONFIG_SMP
 static void __iomem *pmc = IO_ADDRESS(TEGRA_PMC_BASE);
@@ -220,34 +218,8 @@ static int tegra20_idle_lp2_coupled(struct cpuidle_device *dev,
 
 int __init tegra20_cpuidle_init(void)
 {
-	int ret;
-	unsigned int cpu;
-	struct cpuidle_device *dev;
-	struct cpuidle_driver *drv = &tegra_idle_driver;
-
 #ifdef CONFIG_PM_SLEEP
 	tegra_tear_down_cpu = tegra20_tear_down_cpu;
 #endif
-
-	ret = cpuidle_register_driver(&tegra_idle_driver);
-	if (ret) {
-		pr_err("CPUidle driver registration failed\n");
-		return ret;
-	}
-
-	for_each_possible_cpu(cpu) {
-		dev = &per_cpu(tegra_idle_device, cpu);
-		dev->cpu = cpu;
-#ifdef CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED
-		dev->coupled_cpus = *cpu_possible_mask;
-#endif
-
-		ret = cpuidle_register_device(dev);
-		if (ret) {
-			pr_err("CPU%u: CPUidle device registration failed\n",
-				cpu);
-			return ret;
-		}
-	}
-	return 0;
+	return cpuidle_register(&tegra_idle_driver, cpu_possible_mask);
 }
-- 
1.7.9.5



From daniel.lezcano at linaro.org  Tue Apr 23 04:54:38 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Tue, 23 Apr 2013 10:54:38 +0200
Subject: [V4 patch 08/15] ARM: shmobile: cpuidle: use init/exit common routine
In-Reply-To: <1366707285-12179-1-git-send-email-daniel.lezcano@linaro.org>
References: <1366707285-12179-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1366707285-12179-9-git-send-email-daniel.lezcano@linaro.org>

Remove the duplicated code and use the cpuidle common code for initialization.

Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
Acked-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/cpuidle.c |   10 +---------
 1 file changed, 1 insertion(+), 9 deletions(-)

diff --git a/arch/arm/mach-shmobile/cpuidle.c b/arch/arm/mach-shmobile/cpuidle.c
index d671ae9..0afeb5c 100644
--- a/arch/arm/mach-shmobile/cpuidle.c
+++ b/arch/arm/mach-shmobile/cpuidle.c
@@ -16,7 +16,6 @@
 #include <asm/cpuidle.h>
 #include <asm/io.h>
 
-static struct cpuidle_device shmobile_cpuidle_dev;
 static struct cpuidle_driver shmobile_cpuidle_default_driver = {
 	.name			= "shmobile_cpuidle",
 	.owner			= THIS_MODULE,
@@ -34,12 +33,5 @@ void __init shmobile_cpuidle_set_driver(struct cpuidle_driver *drv)
 
 int __init shmobile_cpuidle_init(void)
 {
-	struct cpuidle_device *dev = &shmobile_cpuidle_dev;
-
-	cpuidle_register_driver(cpuidle_drv);
-
-	dev->state_count = cpuidle_drv->state_count;
-	cpuidle_register_device(dev);
-
-	return 0;
+	return cpuidle_register(cpuidle_drv, NULL);
 }
-- 
1.7.9.5



From daniel.lezcano at linaro.org  Tue Apr 23 04:54:39 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Tue, 23 Apr 2013 10:54:39 +0200
Subject: [V4 patch 09/15] ARM: OMAP4: cpuidle: use init/exit common routine
In-Reply-To: <1366707285-12179-1-git-send-email-daniel.lezcano@linaro.org>
References: <1366707285-12179-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1366707285-12179-10-git-send-email-daniel.lezcano@linaro.org>

Remove the duplicated code and use the cpuidle common code for initialization.

Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
Acked-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
Reviewed-by: Kevin Hilman <khilman at linaro.org>
Tested-by: Kevin Hilman <khilman at linaro.org>
---
 arch/arm/mach-omap2/cpuidle44xx.c |   26 ++------------------------
 1 file changed, 2 insertions(+), 24 deletions(-)

diff --git a/arch/arm/mach-omap2/cpuidle44xx.c b/arch/arm/mach-omap2/cpuidle44xx.c
index d1bfb21..5a286b5 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -15,6 +15,7 @@
 #include <linux/cpu_pm.h>
 #include <linux/export.h>
 
+#include <asm/cpuidle.h>
 #include <asm/proc-fns.h>
 
 #include "common.h"
@@ -159,8 +160,6 @@ fail:
 	return index;
 }
 
-static DEFINE_PER_CPU(struct cpuidle_device, omap_idle_dev);
-
 static struct cpuidle_driver omap4_idle_driver = {
 	.name				= "omap4_idle",
 	.owner				= THIS_MODULE,
@@ -209,9 +208,6 @@ static struct cpuidle_driver omap4_idle_driver = {
  */
 int __init omap4_idle_init(void)
 {
-	struct cpuidle_device *dev;
-	unsigned int cpu_id = 0;
-
 	mpu_pd = pwrdm_lookup("mpu_pwrdm");
 	cpu_pd[0] = pwrdm_lookup("cpu0_pwrdm");
 	cpu_pd[1] = pwrdm_lookup("cpu1_pwrdm");
@@ -223,23 +219,5 @@ int __init omap4_idle_init(void)
 	if (!cpu_clkdm[0] || !cpu_clkdm[1])
 		return -ENODEV;
 
-	if (cpuidle_register_driver(&omap4_idle_driver)) {
-		pr_err("%s: CPUidle driver register failed\n", __func__);
-		return -EIO;
-	}
-
-	for_each_cpu(cpu_id, cpu_online_mask) {
-		dev = &per_cpu(omap_idle_dev, cpu_id);
-		dev->cpu = cpu_id;
-#ifdef CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED
-		dev->coupled_cpus = *cpu_online_mask;
-#endif
-		if (cpuidle_register_device(dev)) {
-			pr_err("%s: CPUidle register failed\n", __func__);
-			cpuidle_unregister_driver(&omap4_idle_driver);
-			return -EIO;
-		}
-	}
-
-	return 0;
+	return cpuidle_register(&omap4_idle_driver, cpu_online_mask);
 }
-- 
1.7.9.5



From daniel.lezcano at linaro.org  Tue Apr 23 04:54:41 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Tue, 23 Apr 2013 10:54:41 +0200
Subject: [V4 patch 11/15] ARM: tegra: cpuidle: use init/exit common routine
 for tegra3
In-Reply-To: <1366707285-12179-1-git-send-email-daniel.lezcano@linaro.org>
References: <1366707285-12179-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1366707285-12179-12-git-send-email-daniel.lezcano@linaro.org>

Remove the duplicated code and use the cpuidle common code for initialization.

Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
Acked-by: Stephen Warren <swarren at nvidia.com>
---
 arch/arm/mach-tegra/cpuidle-tegra30.c |   27 +--------------------------
 1 file changed, 1 insertion(+), 26 deletions(-)

diff --git a/arch/arm/mach-tegra/cpuidle-tegra30.c b/arch/arm/mach-tegra/cpuidle-tegra30.c
index f6a0c72..36dc2be 100644
--- a/arch/arm/mach-tegra/cpuidle-tegra30.c
+++ b/arch/arm/mach-tegra/cpuidle-tegra30.c
@@ -64,8 +64,6 @@ static struct cpuidle_driver tegra_idle_driver = {
 	},
 };
 
-static DEFINE_PER_CPU(struct cpuidle_device, tegra_idle_device);
-
 #ifdef CONFIG_PM_SLEEP
 static bool tegra30_cpu_cluster_power_down(struct cpuidle_device *dev,
 					   struct cpuidle_driver *drv,
@@ -156,31 +154,8 @@ static int tegra30_idle_lp2(struct cpuidle_device *dev,
 
 int __init tegra30_cpuidle_init(void)
 {
-	int ret;
-	unsigned int cpu;
-	struct cpuidle_device *dev;
-	struct cpuidle_driver *drv = &tegra_idle_driver;
-
 #ifdef CONFIG_PM_SLEEP
 	tegra_tear_down_cpu = tegra30_tear_down_cpu;
 #endif
-
-	ret = cpuidle_register_driver(&tegra_idle_driver);
-	if (ret) {
-		pr_err("CPUidle driver registration failed\n");
-		return ret;
-	}
-
-	for_each_possible_cpu(cpu) {
-		dev = &per_cpu(tegra_idle_device, cpu);
-		dev->cpu = cpu;
-
-		ret = cpuidle_register_device(dev);
-		if (ret) {
-			pr_err("CPU%u: CPUidle device registration failed\n",
-				cpu);
-			return ret;
-		}
-	}
-	return 0;
+	return cpuidle_register(&tegra_idle_driver, NULL);
 }
-- 
1.7.9.5



From daniel.lezcano at linaro.org  Tue Apr 23 04:54:42 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Tue, 23 Apr 2013 10:54:42 +0200
Subject: [V4 patch 12/15] ARM: calxeda: cpuidle: use init/exit common routine
In-Reply-To: <1366707285-12179-1-git-send-email-daniel.lezcano@linaro.org>
References: <1366707285-12179-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1366707285-12179-13-git-send-email-daniel.lezcano@linaro.org>

Remove the duplicated code and use the cpuidle common code for initialization.

Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
Acked-by: Rob Herring <rob.herring at calxeda.com>
---
 drivers/cpuidle/cpuidle-calxeda.c |   52 +------------------------------------
 1 file changed, 1 insertion(+), 51 deletions(-)

diff --git a/drivers/cpuidle/cpuidle-calxeda.c b/drivers/cpuidle/cpuidle-calxeda.c
index a3b56f5..e344b56 100644
--- a/drivers/cpuidle/cpuidle-calxeda.c
+++ b/drivers/cpuidle/cpuidle-calxeda.c
@@ -35,8 +35,6 @@
 extern void highbank_set_cpu_jump(int cpu, void *jump_addr);
 extern void *scu_base_addr;
 
-static struct cpuidle_device __percpu *calxeda_idle_cpuidle_devices;
-
 static inline unsigned int get_auxcr(void)
 {
 	unsigned int val;
@@ -85,19 +83,6 @@ static int calxeda_pwrdown_idle(struct cpuidle_device *dev,
 	return index;
 }
 
-static void calxeda_idle_cpuidle_devices_uninit(void)
-{
-	int i;
-	struct cpuidle_device *dev;
-
-	for_each_possible_cpu(i) {
-		dev = per_cpu_ptr(calxeda_idle_cpuidle_devices, i);
-		cpuidle_unregister_device(dev);
-	}
-
-	free_percpu(calxeda_idle_cpuidle_devices);
-}
-
 static struct cpuidle_driver calxeda_idle_driver = {
 	.name = "calxeda_idle",
 	.states = {
@@ -117,44 +102,9 @@ static struct cpuidle_driver calxeda_idle_driver = {
 
 static int __init calxeda_cpuidle_init(void)
 {
-	int cpu_id;
-	int ret;
-	struct cpuidle_device *dev;
-	struct cpuidle_driver *drv = &calxeda_idle_driver;
-
 	if (!of_machine_is_compatible("calxeda,highbank"))
 		return -ENODEV;
 
-	ret = cpuidle_register_driver(drv);
-	if (ret)
-		return ret;
-
-	calxeda_idle_cpuidle_devices = alloc_percpu(struct cpuidle_device);
-	if (calxeda_idle_cpuidle_devices == NULL) {
-		ret = -ENOMEM;
-		goto unregister_drv;
-	}
-
-	/* initialize state data for each cpuidle_device */
-	for_each_possible_cpu(cpu_id) {
-		dev = per_cpu_ptr(calxeda_idle_cpuidle_devices, cpu_id);
-		dev->cpu = cpu_id;
-		dev->state_count = drv->state_count;
-
-		ret = cpuidle_register_device(dev);
-		if (ret) {
-			pr_err("Failed to register cpu %u, error: %d\n",
-			       cpu_id, ret);
-			goto uninit;
-		}
-	}
-
-	return 0;
-
-uninit:
-	calxeda_idle_cpuidle_devices_uninit();
-unregister_drv:
-	cpuidle_unregister_driver(drv);
-	return ret;
+	return cpuidle_register(&calxeda_idle_driver, NULL);
 }
 module_init(calxeda_cpuidle_init);
-- 
1.7.9.5



From daniel.lezcano at linaro.org  Tue Apr 23 04:54:43 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Tue, 23 Apr 2013 10:54:43 +0200
Subject: [V4 patch 13/15] ARM: kirkwood: cpuidle: use init/exit common routine
In-Reply-To: <1366707285-12179-1-git-send-email-daniel.lezcano@linaro.org>
References: <1366707285-12179-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1366707285-12179-14-git-send-email-daniel.lezcano@linaro.org>

Remove the duplicated code and use the cpuidle common code for initialization.

Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
Tested-by: Andrew Lunn <andrew at lunn.ch>
Acked-by: Andrew Lunn <andrew at lunn.ch>
---
 drivers/cpuidle/cpuidle-kirkwood.c |   17 ++---------------
 1 file changed, 2 insertions(+), 15 deletions(-)

diff --git a/drivers/cpuidle/cpuidle-kirkwood.c b/drivers/cpuidle/cpuidle-kirkwood.c
index 6f31524..53290e1 100644
--- a/drivers/cpuidle/cpuidle-kirkwood.c
+++ b/drivers/cpuidle/cpuidle-kirkwood.c
@@ -52,9 +52,6 @@ static struct cpuidle_driver kirkwood_idle_driver = {
 	},
 	.state_count = KIRKWOOD_MAX_STATES,
 };
-static struct cpuidle_device *device;
-
-static DEFINE_PER_CPU(struct cpuidle_device, kirkwood_cpuidle_device);
 
 /* Initialize CPU idle by registering the idle states */
 static int kirkwood_cpuidle_probe(struct platform_device *pdev)
@@ -69,22 +66,12 @@ static int kirkwood_cpuidle_probe(struct platform_device *pdev)
 	if (IS_ERR(ddr_operation_base))
 		return PTR_ERR(ddr_operation_base);
 
-	device = &per_cpu(kirkwood_cpuidle_device, smp_processor_id());
-	device->state_count = KIRKWOOD_MAX_STATES;
-
-	cpuidle_register_driver(&kirkwood_idle_driver);
-	if (cpuidle_register_device(device)) {
-		pr_err("kirkwood_init_cpuidle: Failed registering\n");
-		return -EIO;
-	}
-	return 0;
+	return cpuidle_register(&kirkwood_idle_driver, NULL);
 }
 
 int kirkwood_cpuidle_remove(struct platform_device *pdev)
 {
-	cpuidle_unregister_device(device);
-	cpuidle_unregister_driver(&kirkwood_idle_driver);
-
+	cpuidle_unregister(&kirkwood_idle_driver);
 	return 0;
 }
 
-- 
1.7.9.5



From daniel.lezcano at linaro.org  Tue Apr 23 04:54:44 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Tue, 23 Apr 2013 10:54:44 +0200
Subject: [V4 patch 14/15] ARM: davinci: cpuidle: use init/exit common routine
In-Reply-To: <1366707285-12179-1-git-send-email-daniel.lezcano@linaro.org>
References: <1366707285-12179-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1366707285-12179-15-git-send-email-daniel.lezcano@linaro.org>

Remove the duplicated code and use the cpuidle common code for initialization.

Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
Acked-by: Sekhar Nori <nsekhar at ti.com>
---
 arch/arm/mach-davinci/cpuidle.c |   20 +-------------------
 1 file changed, 1 insertion(+), 19 deletions(-)

diff --git a/arch/arm/mach-davinci/cpuidle.c b/arch/arm/mach-davinci/cpuidle.c
index c2887c5..36aef3a 100644
--- a/arch/arm/mach-davinci/cpuidle.c
+++ b/arch/arm/mach-davinci/cpuidle.c
@@ -25,7 +25,6 @@
 
 #define DAVINCI_CPUIDLE_MAX_STATES	2
 
-static DEFINE_PER_CPU(struct cpuidle_device, davinci_cpuidle_device);
 static void __iomem *ddr2_reg_base;
 static bool ddr2_pdown;
 
@@ -76,12 +75,8 @@ static struct cpuidle_driver davinci_idle_driver = {
 
 static int __init davinci_cpuidle_probe(struct platform_device *pdev)
 {
-	int ret;
-	struct cpuidle_device *device;
 	struct davinci_cpuidle_config *pdata = pdev->dev.platform_data;
 
-	device = &per_cpu(davinci_cpuidle_device, smp_processor_id());
-
 	if (!pdata) {
 		dev_err(&pdev->dev, "cannot get platform data\n");
 		return -ENOENT;
@@ -91,20 +86,7 @@ static int __init davinci_cpuidle_probe(struct platform_device *pdev)
 
 	ddr2_pdown = pdata->ddr2_pdown;
 
-	ret = cpuidle_register_driver(&davinci_idle_driver);
-	if (ret) {
-		dev_err(&pdev->dev, "failed to register driver\n");
-		return ret;
-	}
-
-	ret = cpuidle_register_device(device);
-	if (ret) {
-		dev_err(&pdev->dev, "failed to register device\n");
-		cpuidle_unregister_driver(&davinci_idle_driver);
-		return ret;
-	}
-
-	return 0;
+	return cpuidle_register(&davinci_idle_driver, NULL);
 }
 
 static struct platform_driver davinci_cpuidle_driver = {
-- 
1.7.9.5



From daniel.lezcano at linaro.org  Tue Apr 23 04:54:45 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Tue, 23 Apr 2013 10:54:45 +0200
Subject: [V4 patch 15/15] ARM: imx: cpuidle: use init/exit common routine
In-Reply-To: <1366707285-12179-1-git-send-email-daniel.lezcano@linaro.org>
References: <1366707285-12179-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1366707285-12179-16-git-send-email-daniel.lezcano@linaro.org>

The code intializes the cpuidle driver at different places.
The cpuidle driver for :
  * imx5 : is in the pm-imx5.c, the init function is in cpuidle.c
  * imx6 : is in cpuidle-imx6q.c, the init function is in cpuidle.c
           and cpuidle-imx6q.c

Instead of having the cpuidle code spread across different files,
let's create a driver for each SoC and use the common register function.

Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
Acked-by: Shawn Guo <shawn.guo at linaro.org>
---
 arch/arm/mach-imx/Makefile        |    2 +-
 arch/arm/mach-imx/cpuidle-imx5.c  |   37 +++++++++++++++++
 arch/arm/mach-imx/cpuidle-imx6q.c |    2 +-
 arch/arm/mach-imx/cpuidle.c       |   80 -------------------------------------
 arch/arm/mach-imx/cpuidle.h       |   10 ++---
 arch/arm/mach-imx/pm-imx5.c       |   29 +-------------
 6 files changed, 44 insertions(+), 116 deletions(-)
 create mode 100644 arch/arm/mach-imx/cpuidle-imx5.c
 delete mode 100644 arch/arm/mach-imx/cpuidle.c

diff --git a/arch/arm/mach-imx/Makefile b/arch/arm/mach-imx/Makefile
index c4ce090..cb70961 100644
--- a/arch/arm/mach-imx/Makefile
+++ b/arch/arm/mach-imx/Makefile
@@ -30,7 +30,7 @@ obj-$(CONFIG_MXC_DEBUG_BOARD) += 3ds_debugboard.o
 obj-$(CONFIG_CPU_FREQ_IMX)    += cpufreq.o
 
 ifeq ($(CONFIG_CPU_IDLE),y)
-obj-y += cpuidle.o
+obj-$(CONFIG_SOC_IMX5) += cpuidle-imx5.o
 obj-$(CONFIG_SOC_IMX6Q) += cpuidle-imx6q.o
 endif
 
diff --git a/arch/arm/mach-imx/cpuidle-imx5.c b/arch/arm/mach-imx/cpuidle-imx5.c
new file mode 100644
index 0000000..5a47e3c
--- /dev/null
+++ b/arch/arm/mach-imx/cpuidle-imx5.c
@@ -0,0 +1,37 @@
+/*
+ * Copyright (C) 2012 Freescale Semiconductor, Inc.
+ *
+ * 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/cpuidle.h>
+#include <linux/module.h>
+#include <asm/system_misc.h>
+
+static int imx5_cpuidle_enter(struct cpuidle_device *dev,
+			      struct cpuidle_driver *drv, int index)
+{
+	arm_pm_idle();
+	return index;
+}
+
+static struct cpuidle_driver imx5_cpuidle_driver = {
+	.name             = "imx5_cpuidle",
+	.owner            = THIS_MODULE,
+	.states[0] = {
+		.enter            = imx5_cpuidle_enter,
+		.exit_latency     = 2,
+		.target_residency = 1,
+		.flags            = CPUIDLE_FLAG_TIME_VALID,
+		.name             = "IMX5 SRPG",
+		.desc             = "CPU state retained,powered off",
+	},
+	.state_count = 1,
+};
+
+int __init imx5_cpuidle_init(void)
+{
+	return cpuidle_register(&imx5_cpuidle_driver, NULL);
+}
diff --git a/arch/arm/mach-imx/cpuidle-imx6q.c b/arch/arm/mach-imx/cpuidle-imx6q.c
index e2739ad..23ddfb6 100644
--- a/arch/arm/mach-imx/cpuidle-imx6q.c
+++ b/arch/arm/mach-imx/cpuidle-imx6q.c
@@ -71,5 +71,5 @@ int __init imx6q_cpuidle_init(void)
 	/* Set chicken bit to get a reliable WAIT mode support */
 	imx6q_set_chicken_bit();
 
-	return imx_cpuidle_init(&imx6q_cpuidle_driver);
+	return cpuidle_register(&imx6q_cpuidle_driver, NULL);
 }
diff --git a/arch/arm/mach-imx/cpuidle.c b/arch/arm/mach-imx/cpuidle.c
deleted file mode 100644
index d4cb511..0000000
--- a/arch/arm/mach-imx/cpuidle.c
+++ /dev/null
@@ -1,80 +0,0 @@
-/*
- * Copyright 2012 Freescale Semiconductor, Inc.
- * Copyright 2012 Linaro Ltd.
- *
- * The code contained herein is licensed under the GNU General Public
- * License. You may obtain a copy of the GNU General Public License
- * Version 2 or later at the following locations:
- *
- * http://www.opensource.org/licenses/gpl-license.html
- * http://www.gnu.org/copyleft/gpl.html
- */
-
-#include <linux/cpuidle.h>
-#include <linux/err.h>
-#include <linux/hrtimer.h>
-#include <linux/io.h>
-#include <linux/kernel.h>
-#include <linux/slab.h>
-
-static struct cpuidle_device __percpu * imx_cpuidle_devices;
-
-static void __init imx_cpuidle_devices_uninit(void)
-{
-	int cpu_id;
-	struct cpuidle_device *dev;
-
-	for_each_possible_cpu(cpu_id) {
-		dev = per_cpu_ptr(imx_cpuidle_devices, cpu_id);
-		cpuidle_unregister_device(dev);
-	}
-
-	free_percpu(imx_cpuidle_devices);
-}
-
-int __init imx_cpuidle_init(struct cpuidle_driver *drv)
-{
-	struct cpuidle_device *dev;
-	int cpu_id, ret;
-
-	if (drv->state_count > CPUIDLE_STATE_MAX) {
-		pr_err("%s: state_count exceeds maximum\n", __func__);
-		return -EINVAL;
-	}
-
-	ret = cpuidle_register_driver(drv);
-	if (ret) {
-		pr_err("%s: Failed to register cpuidle driver with error: %d\n",
-			 __func__, ret);
-		return ret;
-	}
-
-	imx_cpuidle_devices = alloc_percpu(struct cpuidle_device);
-	if (imx_cpuidle_devices == NULL) {
-		ret = -ENOMEM;
-		goto unregister_drv;
-	}
-
-	/* initialize state data for each cpuidle_device */
-	for_each_possible_cpu(cpu_id) {
-		dev = per_cpu_ptr(imx_cpuidle_devices, cpu_id);
-		dev->cpu = cpu_id;
-		dev->state_count = drv->state_count;
-
-		ret = cpuidle_register_device(dev);
-		if (ret) {
-			pr_err("%s: Failed to register cpu %u, error: %d\n",
-				__func__, cpu_id, ret);
-			goto uninit;
-		}
-	}
-
-	return 0;
-
-uninit:
-	imx_cpuidle_devices_uninit();
-
-unregister_drv:
-	cpuidle_unregister_driver(drv);
-	return ret;
-}
diff --git a/arch/arm/mach-imx/cpuidle.h b/arch/arm/mach-imx/cpuidle.h
index e092d13..786f98e 100644
--- a/arch/arm/mach-imx/cpuidle.h
+++ b/arch/arm/mach-imx/cpuidle.h
@@ -10,18 +10,16 @@
  * http://www.gnu.org/copyleft/gpl.html
  */
 
-#include <linux/cpuidle.h>
-
 #ifdef CONFIG_CPU_IDLE
-extern int imx_cpuidle_init(struct cpuidle_driver *drv);
+extern int imx5_cpuidle_init(void);
 extern int imx6q_cpuidle_init(void);
 #else
-static inline int imx_cpuidle_init(struct cpuidle_driver *drv)
+static inline int imx5_cpuidle_init(void)
 {
-	return -ENODEV;
+	return 0;
 }
 static inline int imx6q_cpuidle_init(void)
 {
-	return -ENODEV;
+	return 0;
 }
 #endif
diff --git a/arch/arm/mach-imx/pm-imx5.c b/arch/arm/mach-imx/pm-imx5.c
index 4b52b3e..82e79c6 100644
--- a/arch/arm/mach-imx/pm-imx5.c
+++ b/arch/arm/mach-imx/pm-imx5.c
@@ -149,32 +149,6 @@ static void imx5_pm_idle(void)
 	imx5_cpu_do_idle();
 }
 
-static int imx5_cpuidle_enter(struct cpuidle_device *dev,
-				struct cpuidle_driver *drv, int idx)
-{
-	int ret;
-
-	ret = imx5_cpu_do_idle();
-	if (ret < 0)
-		return ret;
-
-	return idx;
-}
-
-static struct cpuidle_driver imx5_cpuidle_driver = {
-	.name			= "imx5_cpuidle",
-	.owner			= THIS_MODULE,
-	.states[0]	= {
-		.enter			= imx5_cpuidle_enter,
-		.exit_latency		= 2,
-		.target_residency	= 1,
-		.flags			= CPUIDLE_FLAG_TIME_VALID,
-		.name			= "IMX5 SRPG",
-		.desc			= "CPU state retained,powered off",
-	},
-	.state_count		= 1,
-};
-
 static int __init imx5_pm_common_init(void)
 {
 	int ret;
@@ -192,8 +166,7 @@ static int __init imx5_pm_common_init(void)
 	/* Set the registers to the default cpu idle state. */
 	mx5_cpu_lp_set(IMX5_DEFAULT_CPU_IDLE_STATE);
 
-	imx_cpuidle_init(&imx5_cpuidle_driver);
-	return 0;
+	return imx5_cpuidle_init();
 }
 
 void __init imx51_pm_init(void)
-- 
1.7.9.5



From arnd at arndb.de  Tue Apr 23 05:09:46 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 23 Apr 2013 11:09:46 +0200
Subject: [PATCH v3 00/10] ARM: exynos multiplatform series, part 1
In-Reply-To: <CAK9yfHxR_NE2R8qzx4p2DinJHqZoOK-4g6EtiAg6fecjy_Vd5A@mail.gmail.com>
References: <1365716245-99231-1-git-send-email-arnd@arndb.de>
 <201304221512.25920.arnd@arndb.de>
 <CAK9yfHxR_NE2R8qzx4p2DinJHqZoOK-4g6EtiAg6fecjy_Vd5A@mail.gmail.com>
Message-ID: <3631184.UZH7PcBe14@wuerfel>

On Tuesday 23 April 2013 09:32:30 Sachin Kamat wrote:
> On 22 April 2013 18:42, Arnd Bergmann <arnd at arndb.de> wrote:
> > On Monday 22 April 2013, Sachin Kamat wrote:
> >>
> >> With this branch now available (merged) in linux-next (20130422),
> >> looks like exynos4 DT support is broken on it. Tested on Origen 4210
> >> and 4412 and I get the following warnings on 4412 Origen board with
> >> exynos_defconfig (Note that clocks are all 0). However, it boots fine
> >> on Arndale board.
> >
> > I think this issue should be fixed with the patch that Thomas Abraham
> > just sent. Thomas, can you confirm?
> 
> Boot tested Origen 4210, 4412 and Arndale boards after applying Thomas
> Abraham's chip-id dt support patches.
> They all boot fine.
> 
> However I could not see multiplatform support for Exynos in
> exynos_defconfig (i.e., CONFIG_ARCH_EXYNOS and
> CONFIG_ARCH_MULTIPLATFORM are not set together). This was available in
> your 'samsung/exynos-multiplatform' branch. Has this been disabled in
> next?

Yes, you have to remove the "depends on BROKEN" part in
arch/arm/mach-exynos/Kconfig. The problem is that multiplatform support
on Exynos only works when you have many the patches that are in
linux-next at the moment, but it does not work with arm-soc alone,
so I cannot enable it yet.

	Arnd


From will.deacon at arm.com  Tue Apr 23 05:09:43 2013
From: will.deacon at arm.com (Will Deacon)
Date: Tue, 23 Apr 2013 10:09:43 +0100
Subject: [RFC PATCH v2 00/13] ARM: DT cpu bindings updates
In-Reply-To: <201304222118.41262.arnd@arndb.de>
References: <1366644455-16550-1-git-send-email-lorenzo.pieralisi@arm.com>
 <20130422164112.GB3076@mudshark.cambridge.arm.com>
 <20130422180057.GB17071@e102568-lin.cambridge.arm.com>
 <201304222118.41262.arnd@arndb.de>
Message-ID: <20130423090942.GA17593@mudshark.cambridge.arm.com>

Hi Lorenzo,

On Mon, Apr 22, 2013 at 08:18:41PM +0100, Arnd Bergmann wrote:
> On Monday 22 April 2013, Lorenzo Pieralisi wrote:
> > > Thoughts? I notice Catalin has some patches queued for arm64 which
> > > unconditionally use of_property_read_u64, but I have a patch to honour the
> > > #address-cells property instead.
> > 
> > Basically you want me to rule out passing a dtb with cpus node having
> > #address-cells == 2 to a 32-bit kernel, correct ? Or put it another way:

No, I'm not proposing that! I don't see why we couldn't make the same change
for 32-bit kernels and honour the address-cells field there too.

> > 
> > - a 32-bit kernel must always get passed a dtb with cpus node
> >   #address-cells == 1. 
> 
> Why that? For other registers, we allow leading zeroes. This is
> already required for MMIO registers on LPAE capable machines.

Indeed, we should probably allow any old #address-cells and parse the reg
property accordingly. Of course, if any bits above bit 31 are non-zero, then
we should complain loudly on an AArch32 system.

> >   If the system is ARMv8 with CPUs having
> >   MPIDR_EL1[63:32] != 0x0, well, running 32-bit kernel on it is not
> >   the safest thing to do anyway.
> 
> I would assume the hypervisor to provide a virtual MPIDR_EL1 for
> a 32 bit kernel in that case.

Correct, but that doesn't help with the bare-metal/host case (where we will
need to scream, as described above).

Also, when I mentioned the mpidr check, I was just referring to the boot
CPU -- you're right about the secondaries.

Will


From lorenzo.pieralisi at arm.com  Tue Apr 23 05:15:20 2013
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Tue, 23 Apr 2013 10:15:20 +0100
Subject: [RFC PATCH v2 12/13] ARM: mach-vt8500: cpus/cpu nodes dts updates
In-Reply-To: <5175EE3E.7080809@prisktech.co.nz>
References: <1366644455-16550-1-git-send-email-lorenzo.pieralisi@arm.com>
 <1366644455-16550-13-git-send-email-lorenzo.pieralisi@arm.com>
 <5175EE3E.7080809@prisktech.co.nz>
Message-ID: <20130423091519.GA22946@e102568-lin.cambridge.arm.com>

On Tue, Apr 23, 2013 at 03:13:18AM +0100, Tony Prisk wrote:
> On 23/04/13 03:27, Lorenzo Pieralisi wrote:
> > This patch updates the in-kernel dts files according to the latest cpus
> > and cpu bindings updates for ARM.
> >
> > Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
> > ---
> >   arch/arm/boot/dts/wm8505.dtsi | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/boot/dts/wm8505.dtsi b/arch/arm/boot/dts/wm8505.dtsi
> > index e74a1c0..a470808 100644
> > --- a/arch/arm/boot/dts/wm8505.dtsi
> > +++ b/arch/arm/boot/dts/wm8505.dtsi
> > @@ -13,7 +13,7 @@
> >   
> >   	cpus {
> >   		cpu at 0 {
> > -			compatible = "arm,arm926ejs";
> > +			compatible = "arm,arm926";
> >   		};
> >   	};
> >   
> As the only author for that file, and the arch-vt8500 maintainer, a CC 
> would have been nice :)

Apologies.

> This binding is still incomplete.device_type, compatible and reg are all 
> required properties.

device_type should already be there and I should not be in charge of
adding it; reg is not required for that processor.

> Also, you seem to have only fixed the wm8505.dtsi, while vt8500.dtsi, 
> wm8650.dtsi and wm8850.dtsi are all left incorrect.

There is no cpus node in there. I can't add cpus node in all dts files
in the kernel where it is missing (why have those dts files been
accepted in the first place, with no cpus node ? why ? cpus node is mandatory
since device tree was introduced, I really do not understand why those dts
landed in the kernel as they are), I would kindly ask maintainers to do
that, I just can not know what cpus are there for every given SoC.

> I am already carrying a patch to fix all this properly so could you drop 
> the arch-vt8500 related patch and I will send in a more complete version 
> for 3.11

Good, thanks.
Lorenzo



From will.deacon at arm.com  Tue Apr 23 05:15:36 2013
From: will.deacon at arm.com (Will Deacon)
Date: Tue, 23 Apr 2013 10:15:36 +0100
Subject: [PATCHv2] arm: Preserve TPIDRURW on context switch
In-Reply-To: <5175A697.3080308@dawncrow.de>
References: <517168BB.3070903@dawncrow.de>
 <20130422143616.GP14496@n2100.arm.linux.org.uk>
 <20130422151836.GA15665@mudshark.cambridge.arm.com>
 <5175A697.3080308@dawncrow.de>
Message-ID: <20130423091536.GB17593@mudshark.cambridge.arm.com>

On Mon, Apr 22, 2013 at 10:07:35PM +0100, Andr? Hentschel wrote:
> Am 22.04.2013 17:18, schrieb Will Deacon:
> > On Mon, Apr 22, 2013 at 03:36:16PM +0100, Russell King - ARM Linux wrote:
> >> On Fri, Apr 19, 2013 at 05:54:35PM +0200, Andr? Hentschel wrote:
> >>> From: =?UTF-8?q?Andr=C3=A9=20Hentschel?= <nerv at dawncrow.de>
> >>>
> >>> There are more and more applications coming to WinRT, Wine could support them,
> >>> but mostly they expect to have the thread environment block (TEB) in TPIDRURW.
> >>> This register must be preserved per thread instead of being cleared.
> >>>
> >>> Signed-off-by: Andr? Hentschel <nerv at dawncrow.de>
> >>
> >> This actually makes things less efficient all round, because you
> >> now use the value immediately after loading, which means it will cause
> >> pipeline stalls, certainly on older CPUs.
> >>
> >> Could you please rework the patch to try avoiding soo many modifications
> >> to the way things have been done here?
> > 
> > copy_thread also needs updating so that the *register* value for the parent
> > is copied to the child, since the parent may have written the register
> > after the last context-switch, meaning that tp_value is out-of-date.
> 
> Thank you both for reviewing.
> 
> I guess you mostly mean "ldr	r6, [r2, #TI_CPU_DOMAIN]".
> I just thought about old CPUs and remembered again that we at Wine
> need that patch only on v7 (and later). So is it ok to introduce a set_tls_v7
> in tls.h and make use of CONFIG_CPU_V7 compile-time check in
> the changed files and in the copy_thread function?

No, we should support this feature on any CPU with the TPIDRURW register,
otherwise it's going to get really confusing for userspace.

> Do i need any further flag checks in copy_thread or can i use the
> compile-time check to add unconditional code?

You could introduce `get' tls functions, which don't do anything for CPUs
without the relevant registers.

Will


From lorenzo.pieralisi at arm.com  Tue Apr 23 05:16:18 2013
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Tue, 23 Apr 2013 10:16:18 +0100
Subject: [RFC PATCH v2 12/13] ARM: mach-vt8500: cpus/cpu nodes dts updates
In-Reply-To: <5175EFFE.7020903@prisktech.co.nz>
References: <1366644455-16550-1-git-send-email-lorenzo.pieralisi@arm.com>
 <1366644455-16550-13-git-send-email-lorenzo.pieralisi@arm.com>
 <5175EE3E.7080809@prisktech.co.nz>
 <5175EFFE.7020903@prisktech.co.nz>
Message-ID: <20130423091618.GB22946@e102568-lin.cambridge.arm.com>

On Tue, Apr 23, 2013 at 03:20:46AM +0100, Tony Prisk wrote:
> On 23/04/13 14:13, Tony Prisk wrote:
> > On 23/04/13 03:27, Lorenzo Pieralisi wrote:
> >> This patch updates the in-kernel dts files according to the latest cpus
> >> and cpu bindings updates for ARM.
> >>
> >> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
> >> ---
> >>   arch/arm/boot/dts/wm8505.dtsi | 2 +-
> >>   1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/arch/arm/boot/dts/wm8505.dtsi 
> >> b/arch/arm/boot/dts/wm8505.dtsi
> >> index e74a1c0..a470808 100644
> >> --- a/arch/arm/boot/dts/wm8505.dtsi
> >> +++ b/arch/arm/boot/dts/wm8505.dtsi
> >> @@ -13,7 +13,7 @@
> >>         cpus {
> >>           cpu at 0 {
> >> -            compatible = "arm,arm926ejs";
> >> +            compatible = "arm,arm926";
> >>           };
> >>       };
> > As the only author for that file, and the arch-vt8500 maintainer, a CC 
> > would have been nice :)
> >
> > This binding is still incomplete.device_type, compatible and reg are 
> > all required properties.
> > Also, you seem to have only fixed the wm8505.dtsi, while vt8500.dtsi, 
> > wm8650.dtsi and wm8850.dtsi are all left incorrect.
> >
> > I am already carrying a patch to fix all this properly so could you 
> > drop the arch-vt8500 related patch and I will send in a more complete 
> > version for 3.11
> >
> > Regards
> > Tony Prisk
> 
> I didn't notice the rules had been changed in the last patch - shouldn't 
> you be changing the rules (read: binding) before changing the devicetree 
> files?

Fair enough, point taken.

> Request still stands - please drop this patch and I will submit a more 
> complete one with the other SoCs updated as well.

Great, thanks,
Lorenzo



From mfuzzey at parkeon.com  Tue Apr 23 05:16:33 2013
From: mfuzzey at parkeon.com (Martin Fuzzey)
Date: Tue, 23 Apr 2013 11:16:33 +0200
Subject: [PATCH V4] ARM: i.MX5: Allow DT clock providers
Message-ID: <20130423091633.22088.58225.stgit@localhost>

Currently clock providers defined in the DT are not registered
on i.MX5 platforms since of_clk_init() is not called.

This is not a problem for the SOC's own clocks, which are registered
in code,  but prevents the DT being used to define clocks for external
hardware.

Fix this by calling of_clk_init() and actually using the DT to obtain
the 4 SOC fixed clocks.
These are already defined in the DT but were previously just used to
manually obtain the rate.

Fall back to the old scheme for non DT platforms.

Since the same method may be useful for other i.MX platforms
implement the imx_obtain_fixed_clock() function in common code.

Actually changing other i.MX platforms to use this should be done
later by someone with access to the appropriate hardware.

Signed-off-by: Martin Fuzzey <mfuzzey at parkeon.com>
Tested-by: Fabio Estevam <fabio.estevam at freescale.com>

---
Changelog:
V2: Applied comments from Sascha Hauer:
	* Use kasprintf instead of scnprintf to avoid length limit
	* Avoid use of IS_ERR_OR_NULL

V3: Applied comments from Shawn Guo:
	* Find clocks by path rather than compatible string
	* Remove unnecessary #ifdef CONFIG_OF

V4:
	* Moved clock obtention function to mach-imx/clk.c to allow use by
		other imx platforms (request from Sascha)
	* Added Tested-by from Fabio Estevam
---
 arch/arm/mach-imx/clk-imx51-imx53.c |   44 ++++++-----------------------------
 arch/arm/mach-imx/clk.c             |   37 +++++++++++++++++++++++++++++
 arch/arm/mach-imx/clk.h             |    3 ++
 3 files changed, 48 insertions(+), 36 deletions(-)

diff --git a/arch/arm/mach-imx/clk-imx51-imx53.c b/arch/arm/mach-imx/clk-imx51-imx53.c
index 3228b4e..debd76d 100644
--- a/arch/arm/mach-imx/clk-imx51-imx53.c
+++ b/arch/arm/mach-imx/clk-imx51-imx53.c
@@ -123,11 +123,13 @@ static void __init mx5_clocks_common_init(unsigned long rate_ckil,
 {
 	int i;
 
+	of_clk_init(NULL);
+
 	clk[dummy] = imx_clk_fixed("dummy", 0);
-	clk[ckil] = imx_clk_fixed("ckil", rate_ckil);
-	clk[osc] = imx_clk_fixed("osc", rate_osc);
-	clk[ckih1] = imx_clk_fixed("ckih1", rate_ckih1);
-	clk[ckih2] = imx_clk_fixed("ckih2", rate_ckih2);
+	clk[ckil] = imx_obtain_fixed_clock("ckil", rate_ckil);
+	clk[osc] = imx_obtain_fixed_clock("osc", rate_osc);
+	clk[ckih1] = imx_obtain_fixed_clock("ckih1", rate_ckih1);
+	clk[ckih2] = imx_obtain_fixed_clock("ckih2", rate_ckih2);
 
 	clk[lp_apm] = imx_clk_mux("lp_apm", MXC_CCM_CCSR, 9, 1,
 				lp_apm_sel, ARRAY_SIZE(lp_apm_sel));
@@ -539,42 +541,12 @@ int __init mx53_clocks_init(unsigned long rate_ckil, unsigned long rate_osc,
 	return of_clk_configure();
 }
 
-#ifdef CONFIG_OF
-static void __init clk_get_freq_dt(unsigned long *ckil, unsigned long *osc,
-				   unsigned long *ckih1, unsigned long *ckih2)
-{
-	struct device_node *np;
-
-	/* retrieve the freqency of fixed clocks from device tree */
-	for_each_compatible_node(np, NULL, "fixed-clock") {
-		u32 rate;
-		if (of_property_read_u32(np, "clock-frequency", &rate))
-			continue;
-
-		if (of_device_is_compatible(np, "fsl,imx-ckil"))
-			*ckil = rate;
-		else if (of_device_is_compatible(np, "fsl,imx-osc"))
-			*osc = rate;
-		else if (of_device_is_compatible(np, "fsl,imx-ckih1"))
-			*ckih1 = rate;
-		else if (of_device_is_compatible(np, "fsl,imx-ckih2"))
-			*ckih2 = rate;
-	}
-}
-
 int __init mx51_clocks_init_dt(void)
 {
-	unsigned long ckil, osc, ckih1, ckih2;
-
-	clk_get_freq_dt(&ckil, &osc, &ckih1, &ckih2);
-	return mx51_clocks_init(ckil, osc, ckih1, ckih2);
+	return mx51_clocks_init(0, 0, 0, 0);
 }
 
 int __init mx53_clocks_init_dt(void)
 {
-	unsigned long ckil, osc, ckih1, ckih2;
-
-	clk_get_freq_dt(&ckil, &osc, &ckih1, &ckih2);
-	return mx53_clocks_init(ckil, osc, ckih1, ckih2);
+	return mx53_clocks_init(0, 0, 0, 0);
 }
-#endif
diff --git a/arch/arm/mach-imx/clk.c b/arch/arm/mach-imx/clk.c
index f5e8be8..f2c73f2 100644
--- a/arch/arm/mach-imx/clk.c
+++ b/arch/arm/mach-imx/clk.c
@@ -1,3 +1,40 @@
+#include <linux/clk.h>
+#include <linux/err.h>
+#include <linux/of.h>
+#include <linux/slab.h>
 #include <linux/spinlock.h>
 
+#include "clk.h"
+
 DEFINE_SPINLOCK(imx_ccm_lock);
+
+static struct clk * __init imx_obtain_fixed_clock_from_dt(const char *name)
+{
+	struct of_phandle_args phandle = {0};
+	struct clk *clk = ERR_PTR(-ENODEV);
+	char *path;
+
+	path = kasprintf(GFP_KERNEL, "/clocks/%s", name);
+	if (!path)
+		return ERR_PTR(-ENOMEM);
+
+	phandle.np = of_find_node_by_path(path);
+	kfree(path);
+
+	if (phandle.np) {
+		clk = of_clk_get_from_provider(&phandle);
+		of_node_put(phandle.np);
+	}
+	return clk;
+}
+
+struct clk * __init imx_obtain_fixed_clock(
+			const char *name, unsigned long rate)
+{
+	struct clk *clk;
+
+	clk = imx_obtain_fixed_clock_from_dt(name);
+	if (IS_ERR(clk))
+		clk = imx_clk_fixed(name, rate);
+	return clk;
+}
diff --git a/arch/arm/mach-imx/clk.h b/arch/arm/mach-imx/clk.h
index d9d9d9c..780fd67 100644
--- a/arch/arm/mach-imx/clk.h
+++ b/arch/arm/mach-imx/clk.h
@@ -29,6 +29,9 @@ struct clk *clk_register_gate2(struct device *dev, const char *name,
 		void __iomem *reg, u8 bit_idx,
 		u8 clk_gate_flags, spinlock_t *lock);
 
+struct clk * __init imx_obtain_fixed_clock(
+			const char *name, unsigned long rate);
+
 static inline struct clk *imx_clk_gate2(const char *name, const char *parent,
 		void __iomem *reg, u8 shift)
 {



From lorenzo.pieralisi at arm.com  Tue Apr 23 05:26:38 2013
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Tue, 23 Apr 2013 10:26:38 +0100
Subject: [RFC PATCH v2 12/13] ARM: mach-vt8500: cpus/cpu nodes dts updates
In-Reply-To: <5175F564.8030405@prisktech.co.nz>
References: <1366644455-16550-1-git-send-email-lorenzo.pieralisi@arm.com>
 <1366644455-16550-13-git-send-email-lorenzo.pieralisi@arm.com>
 <5175F564.8030405@prisktech.co.nz>
Message-ID: <20130423092637.GC22946@e102568-lin.cambridge.arm.com>

On Tue, Apr 23, 2013 at 03:43:48AM +0100, Tony Prisk wrote:
> On 23/04/13 03:27, Lorenzo Pieralisi wrote:
> > This patch updates the in-kernel dts files according to the latest cpus
> > and cpu bindings updates for ARM.
> >
> > Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
> > ---
> >   arch/arm/boot/dts/wm8505.dtsi | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/boot/dts/wm8505.dtsi b/arch/arm/boot/dts/wm8505.dtsi
> > index e74a1c0..a470808 100644
> > --- a/arch/arm/boot/dts/wm8505.dtsi
> > +++ b/arch/arm/boot/dts/wm8505.dtsi
> > @@ -13,7 +13,7 @@
> >   
> >   	cpus {
> >   		cpu at 0 {
> > -			compatible = "arm,arm926ejs";
> > +			compatible = "arm,arm926";
> >   		};
> >   	};
> >   
> The more I look at this, the more wrong it is :/
> 
>  From the new binding documentation,
> 
> +	A cpus node must define the following properties:
> +
> +	- #address-cells
> +		Usage: required
> +		Value type: <u32>
> +		Definition: must be set to 1 for 32-bit systems and 2 for
> +			    64-bit systems
> +	- #size-cells
> +		Usage: required
> +		Value type: <u32>
> +		Definition: must be set to 0
> 
> ...
> 
> +- cpu node
> +
> +	Description: Describes a CPU in an ARM based system
> +
> +	PROPERTIES
> +
> +	- device_type
> +		Usage: required
> +		Value type: <string>
> +		Definition: must be "cpu"
> 

This property is required since DT was invented, again, I should not be
in charge of adding it.

> Three required properties that aren't present in the patch.
> 
> cpus {
>      #size-cells = <0>;
>      #address-cells = <1>;
> 
>      cpu {
>          device_type = "cpu"
>          compatible = "arm,arm926";
>      };
> };

I am of two minds about this. That processor does not have an MPIDR
equivalent so in theory #address-cells and #size-cells could be omitted
because the reg property is meaningless. I do not know to be honest the
best way to handle this.

Thoughts ?

Thanks for the review,
Lorenzo



From lorenzo.pieralisi at arm.com  Tue Apr 23 05:34:49 2013
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Tue, 23 Apr 2013 10:34:49 +0100
Subject: [RFC PATCH v2 00/13] ARM: DT cpu bindings updates
In-Reply-To: <20130423090942.GA17593@mudshark.cambridge.arm.com>
References: <1366644455-16550-1-git-send-email-lorenzo.pieralisi@arm.com>
 <20130422164112.GB3076@mudshark.cambridge.arm.com>
 <20130422180057.GB17071@e102568-lin.cambridge.arm.com>
 <201304222118.41262.arnd@arndb.de>
 <20130423090942.GA17593@mudshark.cambridge.arm.com>
Message-ID: <20130423093449.GD22946@e102568-lin.cambridge.arm.com>

On Tue, Apr 23, 2013 at 10:09:43AM +0100, Will Deacon wrote:
> Hi Lorenzo,
> 
> On Mon, Apr 22, 2013 at 08:18:41PM +0100, Arnd Bergmann wrote:
> > On Monday 22 April 2013, Lorenzo Pieralisi wrote:
> > > > Thoughts? I notice Catalin has some patches queued for arm64 which
> > > > unconditionally use of_property_read_u64, but I have a patch to honour the
> > > > #address-cells property instead.
> > > 
> > > Basically you want me to rule out passing a dtb with cpus node having
> > > #address-cells == 2 to a 32-bit kernel, correct ? Or put it another way:
> 
> No, I'm not proposing that! I don't see why we couldn't make the same change
> for 32-bit kernels and honour the address-cells field there too.

Ok, that was a misunderstanding. I do honour the address-cells field in
the arm32 kernel, but there is code that does not and must be fixed (or
removed, I have to knock together an RFC to do that or ping the authors
and let them do it).

> > > - a 32-bit kernel must always get passed a dtb with cpus node
> > >   #address-cells == 1. 
> > 
> > Why that? For other registers, we allow leading zeroes. This is
> > already required for MMIO registers on LPAE capable machines.
> 
> Indeed, we should probably allow any old #address-cells and parse the reg
> property accordingly. Of course, if any bits above bit 31 are non-zero, then
> we should complain loudly on an AArch32 system.

That's what I do, but again there is code that does not check that and
honestly what I would like to do is parsing the reg property once for
all at cpu_logical_map init time to avoid reg property parsing proliferation
in the kernel.

> > >   If the system is ARMv8 with CPUs having
> > >   MPIDR_EL1[63:32] != 0x0, well, running 32-bit kernel on it is not
> > >   the safest thing to do anyway.
> > 
> > I would assume the hypervisor to provide a virtual MPIDR_EL1 for
> > a 32 bit kernel in that case.
> 
> Correct, but that doesn't help with the bare-metal/host case (where we will
> need to scream, as described above).
> 
> Also, when I mentioned the mpidr check, I was just referring to the boot
> CPU -- you're right about the secondaries.

Ok, that's agreed.

Thanks,
Lorenzo



From cb at sgoc.de  Tue Apr 23 05:47:40 2013
From: cb at sgoc.de (Christoph G. Baumann)
Date: Tue, 23 Apr 2013 11:47:40 +0200
Subject: [PATCH] Support fsl-dcp crypto coprocessor
Message-ID: <1366710460-11637-1-git-send-email-cb@sgoc.de>

From: "Christoph G. Baumann" <cb at sgoc.de>

The following patch is a port of the original driver from Freescale to
the current mainline. The patch was tested under 3.7.

Signed-off-by: "Christoph G. Baumann" <cb at sgoc.de>
---
 drivers/staging/crypto/Kconfig               |   15 +
 drivers/staging/crypto/Makefile              |    1 +
 drivers/staging/crypto/fsl-dcp.c             | 1817 ++++++++++++++++++++++++++
 drivers/staging/crypto/fsl-dcp.h             |  739 +++++++++++
 include/linux/fsl/fsl-dcp_bootstream_ioctl.h |   32 +
 5 files changed, 2604 insertions(+)
 create mode 100644 drivers/staging/crypto/Kconfig
 create mode 100644 drivers/staging/crypto/Makefile
 create mode 100644 drivers/staging/crypto/fsl-dcp.c
 create mode 100644 drivers/staging/crypto/fsl-dcp.h
 create mode 100644 include/linux/fsl/fsl-dcp_bootstream_ioctl.h

diff --git a/drivers/staging/crypto/Kconfig b/drivers/staging/crypto/Kconfig
new file mode 100644
index 0000000..acf2cf9
--- /dev/null
+++ b/drivers/staging/crypto/Kconfig
@@ -0,0 +1,15 @@
+config CRYPTO_DEV_FSL_DCP
+	tristate "Support for the DCP engine"
+	depends on SOC_IMX23 || SOC_IMX28 || SOC_IMX50
+  select CRYPTO_HW
+	select CRYPTO_ALGAPI
+  select CRYPTO_SHA256
+	select CRYPTO_AES
+	select CRYPTO_BLKCIPHER
+	help
+	  Say 'Y' here to use the DCP AES and SHA
+	  engine for the CryptoAPI algorithms.
+
+	  To compile this driver as a module, choose M here: the module
+	  will be called fsl-dcp.
+
diff --git a/drivers/staging/crypto/Makefile b/drivers/staging/crypto/Makefile
new file mode 100644
index 0000000..06eabdf
--- /dev/null
+++ b/drivers/staging/crypto/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_CRYPTO_DEV_FSL_DCP) += fsl-dcp.o
diff --git a/drivers/staging/crypto/fsl-dcp.c b/drivers/staging/crypto/fsl-dcp.c
new file mode 100644
index 0000000..fba7f1d
--- /dev/null
+++ b/drivers/staging/crypto/fsl-dcp.c
@@ -0,0 +1,1817 @@
+/*
+ * Copyright (C) 2008-2010 Freescale Semiconductor, Inc.
+ */
+/*
+ * adapted to Kernel version 3.7 by Christoph G. Baumann <cgb at debian.org>
+ */
+/*
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+/*
+ * Based on geode-aes.c
+ * Copyright (C) 2004-2006, Advanced Micro Devices, Inc.
+ */
+
+#include <linux/slab.h>
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/errno.h>
+#include <linux/bitops.h>
+#include <linux/crypto.h>
+#include <linux/spinlock.h>
+#include <linux/miscdevice.h>
+#include <linux/platform_device.h>
+#include <linux/err.h>
+#include <linux/sysfs.h>
+#include <linux/fs.h>
+#include <crypto/algapi.h>
+#include <crypto/aes.h>
+#include <crypto/sha.h>
+#include <crypto/hash.h>
+#include <crypto/internal/hash.h>
+#include <linux/dma-mapping.h>
+#include <linux/interrupt.h>
+#include <linux/delay.h>
+#include <linux/uaccess.h>
+#include <linux/clk.h>
+#include <linux/io.h>
+#include <linux/delay.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_device.h>
+
+#include <asm/cacheflush.h>
+#include <mach/hardware.h>
+#include <linux/fsl/fsl-dcp_bootstream_ioctl.h>
+#include "fsl-dcp.h"
+
+/* Following data only used by DCP bootstream interface */
+struct dcpboot_dma_area {
+	struct dcp_hw_packet hw_packet;
+	uint16_t block[16];
+};
+
+struct dcp {
+	struct device *dev;
+	spinlock_t lock;
+	struct mutex op_mutex[DCP_NUM_CHANNELS];
+	struct completion op_wait[DCP_NUM_CHANNELS];
+	int wait[DCP_NUM_CHANNELS];
+	int dcp_vmi_irq;
+	int dcp_irq;
+	u32 dcp_regs_base;
+	ulong clock_state;
+	bool chan_in_use[DCP_NUM_CHANNELS];
+
+	/* Following buffers used in hashing to meet 64-byte len alignment */
+	char *buf1;
+	char *buf2;
+	dma_addr_t buf1_phys;
+	dma_addr_t buf2_phys;
+	struct dcp_hash_coherent_block *buf1_desc;
+	struct dcp_hash_coherent_block *buf2_desc;
+	struct dcp_hash_coherent_block *user_buf_desc;
+
+	/* Following data only used by DCP bootstream interface */
+	struct dcpboot_dma_area *dcpboot_dma_area;
+	dma_addr_t dcpboot_dma_area_phys;
+};
+
+/* cipher flags */
+#define DCP_ENC	0x0001
+#define DCP_DEC	0x0002
+#define DCP_ECB	0x0004
+#define DCP_CBC	0x0008
+#define DCP_CBC_INIT	0x0010
+#define DCP_OTPKEY	0x0020
+
+/* hash flags */
+#define DCP_INIT	0x0001
+#define DCP_UPDATE	0x0002
+#define DCP_FINAL	0x0004
+
+#define DCP_AES	0x1000
+#define DCP_SHA1	0x2000
+#define DCP_CRC32	0x3000
+#define DCP_COPY	0x4000
+#define DCP_FILL	0x5000
+#define DCP_MODE_MASK	0xf000
+
+/* clock defines */
+#define CLOCK_ON	1
+#define CLOCK_OFF	0
+
+struct dcp_op {
+
+	unsigned int flags;
+
+	void *src;
+	dma_addr_t src_phys;
+
+	void *dst;
+	dma_addr_t dst_phys;
+
+	int len;
+
+	/* the key contains the IV for block modes */
+	union {
+		struct {
+			u8 key[2 * AES_KEYSIZE_128]
+			    __attribute__ ((__aligned__(32)));
+			dma_addr_t key_phys;
+			int keylen;
+		} cipher;
+		struct {
+			u8 digest[SHA256_DIGEST_SIZE]
+			    __attribute__ ((__aligned__(32)));
+			dma_addr_t digest_phys;
+			int digestlen;
+			int init;
+		} hash;
+	};
+
+	union {
+		struct crypto_blkcipher *blk;
+		struct crypto_cipher *cip;
+		struct crypto_hash *hash;
+	} fallback;
+
+	struct dcp_hw_packet pkt __attribute__ ((__aligned__(32)));
+};
+
+struct dcp_hash_coherent_block {
+	struct dcp_hw_packet pkt[1]
+	    __attribute__ ((__aligned__(32)));
+	u8 digest[SHA256_DIGEST_SIZE]
+	    __attribute__ ((__aligned__(32)));
+	unsigned int len;
+	dma_addr_t src_phys;
+	void *src;
+	void *dst;
+	dma_addr_t my_phys;
+	u32 hash_sel;
+	struct dcp_hash_coherent_block *next;
+};
+
+struct dcp_hash_op {
+
+	unsigned int flags;
+
+	/* the key contains the IV for block modes */
+	union {
+		struct {
+			u8 key[2 * AES_KEYSIZE_128]
+			    __attribute__ ((__aligned__(32)));
+			dma_addr_t key_phys;
+			int keylen;
+		} cipher;
+		struct {
+			u8 digest[SHA256_DIGEST_SIZE]
+			    __attribute__ ((__aligned__(32)));
+			dma_addr_t digest_phys;
+			int digestlen;
+			int init;
+		} hash;
+	};
+
+	u32 length;
+	struct dcp_hash_coherent_block *head_desc;
+	struct dcp_hash_coherent_block *tail_desc;
+};
+
+/* only one */
+static struct dcp *global_sdcp;
+
+static void dcp_clock(struct dcp *sdcp, ulong state, bool force)
+{
+	u32 chan;
+	struct clk *clk = clk_get(sdcp->dev, "dcp_clk");
+
+	/* unless force is true (used during suspend/resume), if any
+	 * channel is running, then clk is already on, and must stay on */
+	if (!force)
+		for (chan = 0; chan < DCP_NUM_CHANNELS; chan++)
+			if (sdcp->chan_in_use[chan])
+				goto exit;
+
+	if (state == CLOCK_OFF) {
+		/* gate at clock source */
+		if (!IS_ERR(clk))
+			clk_disable(clk);
+		/* gate at DCP */
+		else
+			__raw_writel(BM_DCP_CTRL_CLKGATE,
+				     (volatile void *)(sdcp->dcp_regs_base +
+						       HW_DCP_CTRL_SET));
+
+		sdcp->clock_state = CLOCK_OFF;
+
+	} else {
+		/* ungate at clock source */
+		if (!IS_ERR(clk))
+			clk_enable(clk);
+		/* ungate at DCP */
+		else
+			__raw_writel(BM_DCP_CTRL_CLKGATE,
+				     (volatile void *)(sdcp->dcp_regs_base +
+						       HW_DCP_CTRL_CLR));
+
+		sdcp->clock_state = CLOCK_ON;
+	}
+
+ exit:
+	return;
+}
+
+static void dcp_perform_op(struct dcp_op *op)
+{
+	struct dcp *sdcp = global_sdcp;
+	struct mutex *mutex;
+	struct dcp_hw_packet *pkt;
+	int chan;
+	u32 pkt1, pkt2;
+	unsigned long timeout;
+	dma_addr_t pkt_phys;
+	u32 stat;
+
+	pkt1 = BM_DCP_PACKET1_DECR_SEMAPHORE | BM_DCP_PACKET1_INTERRUPT;
+
+	switch (op->flags & DCP_MODE_MASK) {
+
+	case DCP_AES:
+
+		chan = CIPHER_CHAN;
+
+		/* key is at the payload */
+		pkt1 |= BM_DCP_PACKET1_ENABLE_CIPHER;
+		if ((op->flags & DCP_OTPKEY) == 0)
+			pkt1 |= BM_DCP_PACKET1_PAYLOAD_KEY;
+		if (op->flags & DCP_ENC)
+			pkt1 |= BM_DCP_PACKET1_CIPHER_ENCRYPT;
+		if (op->flags & DCP_CBC_INIT)
+			pkt1 |= BM_DCP_PACKET1_CIPHER_INIT;
+
+		pkt2 = BF(0, DCP_PACKET2_CIPHER_CFG) |
+		    BF(0, DCP_PACKET2_KEY_SELECT) |
+		    BF(BV_DCP_PACKET2_CIPHER_SELECT__AES128,
+		       DCP_PACKET2_CIPHER_SELECT);
+
+		if (op->flags & DCP_ECB)
+			pkt2 |= BF(BV_DCP_PACKET2_CIPHER_MODE__ECB,
+				   DCP_PACKET2_CIPHER_MODE);
+		else if (op->flags & DCP_CBC)
+			pkt2 |= BF(BV_DCP_PACKET2_CIPHER_MODE__CBC,
+				   DCP_PACKET2_CIPHER_MODE);
+
+		break;
+
+	case DCP_SHA1:
+
+		chan = HASH_CHAN;
+
+		pkt1 |= BM_DCP_PACKET1_ENABLE_HASH;
+		if (op->flags & DCP_INIT)
+			pkt1 |= BM_DCP_PACKET1_HASH_INIT;
+		if (op->flags & DCP_FINAL) {
+			pkt1 |= BM_DCP_PACKET1_HASH_TERM;
+			BUG_ON(op->hash.digest == NULL);
+		}
+
+		pkt2 = BF(BV_DCP_PACKET2_HASH_SELECT__SHA1,
+			  DCP_PACKET2_HASH_SELECT);
+		break;
+
+	default:
+		dev_err(sdcp->dev, "Unsupported mode\n");
+		return;
+	}
+
+	mutex = &sdcp->op_mutex[chan];
+	pkt = &op->pkt;
+
+	pkt->pNext = 0;
+	pkt->pkt1 = pkt1;
+	pkt->pkt2 = pkt2;
+	pkt->pSrc = (u32) op->src_phys;
+	pkt->pDst = (u32) op->dst_phys;
+	pkt->size = op->len;
+	pkt->pPayload = chan == CIPHER_CHAN ?
+	    (u32) op->cipher.key_phys : (u32) op->hash.digest_phys;
+	pkt->stat = 0;
+
+	pkt_phys = dma_map_single(sdcp->dev, pkt, sizeof(*pkt),
+				  DMA_BIDIRECTIONAL);
+	if (dma_mapping_error(sdcp->dev, pkt_phys)) {
+		dev_err(sdcp->dev, "Unable to map packet descriptor\n");
+		return;
+	}
+
+	/* submit the work */
+	mutex_lock(mutex);
+	dcp_clock(sdcp, CLOCK_ON, false);
+	sdcp->chan_in_use[chan] = true;
+
+	__raw_writel(-1,
+		     (volatile void *)(sdcp->dcp_regs_base +
+				       HW_DCP_CHnSTAT_CLR(chan)));
+
+	/* Load the work packet pointer and bump the channel semaphore */
+	__raw_writel((u32) pkt_phys, (volatile void *)(sdcp->dcp_regs_base +
+						       HW_DCP_CHnCMDPTR(chan)));
+
+	/* XXX wake from interrupt instead of looping */
+	timeout = jiffies + msecs_to_jiffies(1000);
+
+	sdcp->wait[chan] = 0;
+	__raw_writel(BF(1, DCP_CHnSEMA_INCREMENT),
+		     (volatile void *)(sdcp->dcp_regs_base +
+				       HW_DCP_CHnSEMA(chan)));
+	while (time_before(jiffies, timeout) && sdcp->wait[chan] == 0)
+		cpu_relax();
+
+	if (!time_before(jiffies, timeout)) {
+		dev_err(sdcp->dev, "Timeout while waiting STAT 0x%08x\n",
+			__raw_readl((volatile void *)(sdcp->dcp_regs_base +
+						      HW_DCP_STAT)));
+		goto out;
+	}
+
+	stat =
+	    __raw_readl((volatile void *)(sdcp->dcp_regs_base +
+					  HW_DCP_CHnSTAT(chan)));
+	if ((stat & 0xff) != 0)
+		dev_err(sdcp->dev, "Channel stat error 0x%02x\n",
+			__raw_readl((volatile void *)(sdcp->dcp_regs_base +
+						      (HW_DCP_CHnSTAT(chan) &
+						       0xff))));
+ out:
+	sdcp->chan_in_use[chan] = false;
+	dcp_clock(sdcp, CLOCK_OFF, false);
+	mutex_unlock(mutex);
+	dma_unmap_single(sdcp->dev, pkt_phys, sizeof(*pkt), DMA_TO_DEVICE);
+}
+
+static int dcp_aes_setkey_cip(struct crypto_tfm *tfm, const u8 *key,
+			      unsigned int len)
+{
+	struct dcp_op *op = crypto_tfm_ctx(tfm);
+	unsigned int ret;
+
+	op->cipher.keylen = len;
+
+	if (len == AES_KEYSIZE_128) {
+		memcpy(op->cipher.key, key, len);
+		return 0;
+	}
+
+	if (len != AES_KEYSIZE_192 && len != AES_KEYSIZE_256) {
+		/* not supported at all */
+		tfm->crt_flags |= CRYPTO_TFM_RES_BAD_KEY_LEN;
+		return -EINVAL;
+	}
+
+	/*
+	 * The requested key size is not supported by HW, do a fallback
+	 */
+	op->fallback.blk->base.crt_flags &= ~CRYPTO_TFM_REQ_MASK;
+	op->fallback.blk->base.crt_flags |= (tfm->crt_flags &
+					     CRYPTO_TFM_REQ_MASK);
+
+	ret = crypto_cipher_setkey(op->fallback.cip, key, len);
+	if (ret) {
+		tfm->crt_flags &= ~CRYPTO_TFM_RES_MASK;
+		tfm->crt_flags |= (op->fallback.blk->base.crt_flags &
+				   CRYPTO_TFM_RES_MASK);
+	}
+	return ret;
+}
+
+static void dcp_aes_encrypt(struct crypto_tfm *tfm, u8 *out, const u8 *in)
+{
+	struct dcp *sdcp = global_sdcp;
+	struct dcp_op *op = crypto_tfm_ctx(tfm);
+
+	if (unlikely(op->cipher.keylen != AES_KEYSIZE_128)) {
+		crypto_cipher_encrypt_one(op->fallback.cip, out, in);
+		return;
+	}
+
+	op->src = (void *)in;
+	op->dst = (void *)out;
+	op->flags = DCP_AES | DCP_ENC | DCP_ECB;
+	op->len = AES_KEYSIZE_128;
+
+	/* map the data */
+	op->src_phys = dma_map_single(sdcp->dev, (void *)in, AES_KEYSIZE_128,
+				      DMA_TO_DEVICE);
+	if (dma_mapping_error(sdcp->dev, op->src_phys)) {
+		dev_err(sdcp->dev, "Unable to map source\n");
+		return;
+	}
+
+	op->dst_phys = dma_map_single(sdcp->dev, out, AES_KEYSIZE_128,
+				      DMA_FROM_DEVICE);
+	if (dma_mapping_error(sdcp->dev, op->dst_phys)) {
+		dev_err(sdcp->dev, "Unable to map dest\n");
+		goto err_unmap_src;
+	}
+
+	op->cipher.key_phys = dma_map_single(sdcp->dev, op->cipher.key,
+					     AES_KEYSIZE_128, DMA_TO_DEVICE);
+	if (dma_mapping_error(sdcp->dev, op->cipher.key_phys)) {
+		dev_err(sdcp->dev, "Unable to map key\n");
+		goto err_unmap_dst;
+	}
+
+	/* perform the operation */
+	dcp_perform_op(op);
+
+	dma_unmap_single(sdcp->dev, op->cipher.key_phys, AES_KEYSIZE_128,
+			 DMA_TO_DEVICE);
+ err_unmap_dst:
+	dma_unmap_single(sdcp->dev, op->dst_phys, op->len, DMA_FROM_DEVICE);
+ err_unmap_src:
+	dma_unmap_single(sdcp->dev, op->src_phys, op->len, DMA_TO_DEVICE);
+}
+
+static void dcp_aes_decrypt(struct crypto_tfm *tfm, u8 *out, const u8 *in)
+{
+	struct dcp *sdcp = global_sdcp;
+	struct dcp_op *op = crypto_tfm_ctx(tfm);
+
+	if (unlikely(op->cipher.keylen != AES_KEYSIZE_128)) {
+		crypto_cipher_decrypt_one(op->fallback.cip, out, in);
+		return;
+	}
+
+	op->src = (void *)in;
+	op->dst = (void *)out;
+	op->flags = DCP_AES | DCP_DEC | DCP_ECB;
+	op->len = AES_KEYSIZE_128;
+
+	/* map the data */
+	op->src_phys = dma_map_single(sdcp->dev, (void *)in, AES_KEYSIZE_128,
+				      DMA_TO_DEVICE);
+	if (dma_mapping_error(sdcp->dev, op->src_phys)) {
+		dev_err(sdcp->dev, "Unable to map source\n");
+		return;
+	}
+
+	op->dst_phys = dma_map_single(sdcp->dev, out, AES_KEYSIZE_128,
+				      DMA_FROM_DEVICE);
+	if (dma_mapping_error(sdcp->dev, op->dst_phys)) {
+		dev_err(sdcp->dev, "Unable to map dest\n");
+		goto err_unmap_src;
+	}
+
+	op->cipher.key_phys = dma_map_single(sdcp->dev, op->cipher.key,
+					     AES_KEYSIZE_128, DMA_TO_DEVICE);
+	if (dma_mapping_error(sdcp->dev, op->cipher.key_phys)) {
+		dev_err(sdcp->dev, "Unable to map key\n");
+		goto err_unmap_dst;
+	}
+
+	/* perform the operation */
+	dcp_perform_op(op);
+
+	dma_unmap_single(sdcp->dev, op->cipher.key_phys, AES_KEYSIZE_128,
+			 DMA_TO_DEVICE);
+ err_unmap_dst:
+	dma_unmap_single(sdcp->dev, op->dst_phys, op->len, DMA_FROM_DEVICE);
+ err_unmap_src:
+	dma_unmap_single(sdcp->dev, op->src_phys, op->len, DMA_TO_DEVICE);
+}
+
+static int fallback_init_cip(struct crypto_tfm *tfm)
+{
+	const char *name = tfm->__crt_alg->cra_name;
+	struct dcp_op *op = crypto_tfm_ctx(tfm);
+
+	op->fallback.cip = crypto_alloc_cipher(name, 0,
+					       CRYPTO_ALG_ASYNC |
+					       CRYPTO_ALG_NEED_FALLBACK);
+
+	if (IS_ERR(op->fallback.cip)) {
+		printk(KERN_ERR "Error allocating fallback algo %s\n", name);
+		return PTR_ERR(op->fallback.cip);
+	}
+
+	return 0;
+}
+
+static void fallback_exit_cip(struct crypto_tfm *tfm)
+{
+	struct dcp_op *op = crypto_tfm_ctx(tfm);
+
+	crypto_free_cipher(op->fallback.cip);
+	op->fallback.cip = NULL;
+}
+
+static struct crypto_alg dcp_aes_alg = {
+	.cra_name = "aes",
+	.cra_driver_name = "dcp-aes",
+	.cra_priority = 300,
+	.cra_alignmask = 15,
+	.cra_flags = CRYPTO_ALG_TYPE_CIPHER | CRYPTO_ALG_NEED_FALLBACK,
+	.cra_init = fallback_init_cip,
+	.cra_exit = fallback_exit_cip,
+	.cra_blocksize = AES_KEYSIZE_128,
+	.cra_ctxsize = sizeof(struct dcp_op),
+	.cra_module = THIS_MODULE,
+	.cra_list = LIST_HEAD_INIT(dcp_aes_alg.cra_list),
+	.cra_u = {
+		  .cipher = {
+			     .cia_min_keysize = AES_MIN_KEY_SIZE,
+			     .cia_max_keysize = AES_MAX_KEY_SIZE,
+			     .cia_setkey = dcp_aes_setkey_cip,
+			     .cia_encrypt = dcp_aes_encrypt,
+			     .cia_decrypt = dcp_aes_decrypt}
+		  }
+};
+
+static int dcp_aes_setkey_blk(struct crypto_tfm *tfm, const u8 *key,
+			      unsigned int len)
+{
+	struct dcp_op *op = crypto_tfm_ctx(tfm);
+	unsigned int ret;
+
+	op->cipher.keylen = len;
+
+	if (len == AES_KEYSIZE_128) {
+		memcpy(op->cipher.key, key, len);
+		return 0;
+	}
+
+	if (len != AES_KEYSIZE_192 && len != AES_KEYSIZE_256) {
+		/* not supported at all */
+		tfm->crt_flags |= CRYPTO_TFM_RES_BAD_KEY_LEN;
+		return -EINVAL;
+	}
+
+	/*
+	 * The requested key size is not supported by HW, do a fallback
+	 */
+	op->fallback.blk->base.crt_flags &= ~CRYPTO_TFM_REQ_MASK;
+	op->fallback.blk->base.crt_flags |= (tfm->crt_flags &
+					     CRYPTO_TFM_REQ_MASK);
+
+	ret = crypto_blkcipher_setkey(op->fallback.blk, key, len);
+	if (ret) {
+		tfm->crt_flags &= ~CRYPTO_TFM_RES_MASK;
+		tfm->crt_flags |= (op->fallback.blk->base.crt_flags &
+				   CRYPTO_TFM_RES_MASK);
+	}
+	return ret;
+}
+
+static int fallback_blk_dec(struct blkcipher_desc *desc,
+			    struct scatterlist *dst, struct scatterlist *src,
+			    unsigned int nbytes)
+{
+	unsigned int ret;
+	struct crypto_blkcipher *tfm;
+	struct dcp_op *op = crypto_blkcipher_ctx(desc->tfm);
+
+	tfm = desc->tfm;
+	desc->tfm = op->fallback.blk;
+
+	ret = crypto_blkcipher_decrypt_iv(desc, dst, src, nbytes);
+
+	desc->tfm = tfm;
+	return ret;
+}
+
+static int fallback_blk_enc(struct blkcipher_desc *desc,
+			    struct scatterlist *dst, struct scatterlist *src,
+			    unsigned int nbytes)
+{
+	unsigned int ret;
+	struct crypto_blkcipher *tfm;
+	struct dcp_op *op = crypto_blkcipher_ctx(desc->tfm);
+
+	tfm = desc->tfm;
+	desc->tfm = op->fallback.blk;
+
+	ret = crypto_blkcipher_encrypt_iv(desc, dst, src, nbytes);
+
+	desc->tfm = tfm;
+	return ret;
+}
+
+static int fallback_init_blk(struct crypto_tfm *tfm)
+{
+	const char *name = tfm->__crt_alg->cra_name;
+	struct dcp_op *op = crypto_tfm_ctx(tfm);
+
+	op->fallback.blk = crypto_alloc_blkcipher(name, 0,
+						  CRYPTO_ALG_ASYNC |
+						  CRYPTO_ALG_NEED_FALLBACK);
+
+	if (IS_ERR(op->fallback.blk)) {
+		printk(KERN_ERR "Error allocating fallback algo %s\n", name);
+		return PTR_ERR(op->fallback.blk);
+	}
+
+	return 0;
+}
+
+static void fallback_exit_blk(struct crypto_tfm *tfm)
+{
+	struct dcp_op *op = crypto_tfm_ctx(tfm);
+
+	crypto_free_blkcipher(op->fallback.blk);
+	op->fallback.blk = NULL;
+}
+
+static int
+dcp_aes_ecb_decrypt(struct blkcipher_desc *desc,
+		    struct scatterlist *dst, struct scatterlist *src,
+		    unsigned int nbytes)
+{
+	struct dcp *sdcp = global_sdcp;
+	struct dcp_op *op = crypto_blkcipher_ctx(desc->tfm);
+	struct blkcipher_walk walk;
+	int err;
+
+	if (unlikely(op->cipher.keylen != AES_KEYSIZE_128))
+		return fallback_blk_dec(desc, dst, src, nbytes);
+
+	blkcipher_walk_init(&walk, dst, src, nbytes);
+
+	/* key needs to be mapped only once */
+	op->cipher.key_phys = dma_map_single(sdcp->dev, op->cipher.key,
+					     AES_KEYSIZE_128, DMA_TO_DEVICE);
+	if (dma_mapping_error(sdcp->dev, op->cipher.key_phys)) {
+		dev_err(sdcp->dev, "Unable to map key\n");
+		return -ENOMEM;
+	}
+
+	err = blkcipher_walk_virt(desc, &walk);
+	while (err == 0 && (nbytes = walk.nbytes) > 0) {
+		op->src = walk.src.virt.addr, op->dst = walk.dst.virt.addr;
+		op->flags = DCP_AES | DCP_DEC | DCP_ECB;
+		op->len = nbytes - (nbytes % AES_KEYSIZE_128);
+
+		/* map the data */
+		op->src_phys = dma_map_single(sdcp->dev, op->src, op->len,
+					      DMA_TO_DEVICE);
+		if (dma_mapping_error(sdcp->dev, op->src_phys)) {
+			dev_err(sdcp->dev, "Unable to map source\n");
+			err = -ENOMEM;
+			break;
+		}
+
+		op->dst_phys = dma_map_single(sdcp->dev, op->dst, op->len,
+					      DMA_FROM_DEVICE);
+		if (dma_mapping_error(sdcp->dev, op->dst_phys)) {
+			dma_unmap_single(sdcp->dev, op->src_phys, op->len,
+					 DMA_TO_DEVICE);
+			dev_err(sdcp->dev, "Unable to map dest\n");
+			err = -ENOMEM;
+			break;
+		}
+
+		/* perform! */
+		dcp_perform_op(op);
+
+		dma_unmap_single(sdcp->dev, op->dst_phys, op->len,
+				 DMA_FROM_DEVICE);
+		dma_unmap_single(sdcp->dev, op->src_phys, op->len,
+				 DMA_TO_DEVICE);
+
+		nbytes -= op->len;
+		err = blkcipher_walk_done(desc, &walk, nbytes);
+	}
+
+	dma_unmap_single(sdcp->dev, op->cipher.key_phys, AES_KEYSIZE_128,
+			 DMA_TO_DEVICE);
+
+	return err;
+}
+
+static int
+dcp_aes_ecb_encrypt(struct blkcipher_desc *desc,
+		    struct scatterlist *dst, struct scatterlist *src,
+		    unsigned int nbytes)
+{
+	struct dcp *sdcp = global_sdcp;
+	struct dcp_op *op = crypto_blkcipher_ctx(desc->tfm);
+	struct blkcipher_walk walk;
+	int err, ret;
+
+	if (unlikely(op->cipher.keylen != AES_KEYSIZE_128))
+		return fallback_blk_enc(desc, dst, src, nbytes);
+
+	blkcipher_walk_init(&walk, dst, src, nbytes);
+
+	/* key needs to be mapped only once */
+	op->cipher.key_phys = dma_map_single(sdcp->dev, op->cipher.key,
+					     AES_KEYSIZE_128, DMA_TO_DEVICE);
+	if (dma_mapping_error(sdcp->dev, op->cipher.key_phys)) {
+		dev_err(sdcp->dev, "Unable to map key\n");
+		return -ENOMEM;
+	}
+
+	err = blkcipher_walk_virt(desc, &walk);
+
+	err = 0;
+	while (err == 0 && (nbytes = walk.nbytes) > 0) {
+		op->src = walk.src.virt.addr, op->dst = walk.dst.virt.addr;
+		op->flags = DCP_AES | DCP_ENC | DCP_ECB;
+		op->len = nbytes - (nbytes % AES_KEYSIZE_128);
+
+		/* map the data */
+		op->src_phys = dma_map_single(sdcp->dev, op->src, op->len,
+					      DMA_TO_DEVICE);
+		if (dma_mapping_error(sdcp->dev, op->src_phys)) {
+			dev_err(sdcp->dev, "Unable to map source\n");
+			err = -ENOMEM;
+			break;
+		}
+
+		op->dst_phys = dma_map_single(sdcp->dev, op->dst, op->len,
+					      DMA_FROM_DEVICE);
+		if (dma_mapping_error(sdcp->dev, op->dst_phys)) {
+			dma_unmap_single(sdcp->dev, op->src_phys, op->len,
+					 DMA_TO_DEVICE);
+			dev_err(sdcp->dev, "Unable to map dest\n");
+			err = -ENOMEM;
+			break;
+		}
+
+		/* perform! */
+		dcp_perform_op(op);
+
+		dma_unmap_single(sdcp->dev, op->dst_phys, op->len,
+				 DMA_FROM_DEVICE);
+		dma_unmap_single(sdcp->dev, op->src_phys, op->len,
+				 DMA_TO_DEVICE);
+
+		nbytes -= op->len;
+		ret = blkcipher_walk_done(desc, &walk, nbytes);
+	}
+
+	dma_unmap_single(sdcp->dev, op->cipher.key_phys, AES_KEYSIZE_128,
+			 DMA_TO_DEVICE);
+
+	return err;
+}
+
+static struct crypto_alg dcp_aes_ecb_alg = {
+	.cra_name = "ecb(aes)",
+	.cra_driver_name = "dcp-ecb-aes",
+	.cra_priority = 400,
+	.cra_alignmask = 15,
+	.cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER | CRYPTO_ALG_NEED_FALLBACK,
+	.cra_init = fallback_init_blk,
+	.cra_exit = fallback_exit_blk,
+	.cra_blocksize = AES_KEYSIZE_128,
+	.cra_ctxsize = sizeof(struct dcp_op),
+	.cra_type = &crypto_blkcipher_type,
+	.cra_module = THIS_MODULE,
+	.cra_list = LIST_HEAD_INIT(dcp_aes_ecb_alg.cra_list),
+	.cra_u = {
+		  .blkcipher = {
+				.min_keysize = AES_MIN_KEY_SIZE,
+				.max_keysize = AES_MAX_KEY_SIZE,
+				.setkey = dcp_aes_setkey_blk,
+				.encrypt = dcp_aes_ecb_encrypt,
+				.decrypt = dcp_aes_ecb_decrypt}
+		  }
+};
+
+static int
+dcp_aes_cbc_decrypt(struct blkcipher_desc *desc,
+		    struct scatterlist *dst, struct scatterlist *src,
+		    unsigned int nbytes)
+{
+	struct dcp *sdcp = global_sdcp;
+	struct dcp_op *op = crypto_blkcipher_ctx(desc->tfm);
+	struct blkcipher_walk walk;
+	int err, blockno;
+
+	if (unlikely(op->cipher.keylen != AES_KEYSIZE_128))
+		return fallback_blk_dec(desc, dst, src, nbytes);
+
+	blkcipher_walk_init(&walk, dst, src, nbytes);
+
+	blockno = 0;
+	err = blkcipher_walk_virt(desc, &walk);
+	while (err == 0 && (nbytes = walk.nbytes) > 0) {
+		op->src = walk.src.virt.addr, op->dst = walk.dst.virt.addr;
+		op->flags = DCP_AES | DCP_DEC | DCP_CBC;
+		if (blockno == 0) {
+			op->flags |= DCP_CBC_INIT;
+			memcpy(op->cipher.key + AES_KEYSIZE_128, walk.iv,
+			       AES_KEYSIZE_128);
+		}
+		op->len = nbytes - (nbytes % AES_KEYSIZE_128);
+
+		/* key (+iv) needs to be mapped only once */
+		op->cipher.key_phys = dma_map_single(sdcp->dev, op->cipher.key,
+						     AES_KEYSIZE_128 * 2,
+						     DMA_BIDIRECTIONAL);
+		if (dma_mapping_error(sdcp->dev, op->cipher.key_phys)) {
+			dev_err(sdcp->dev, "Unable to map key\n");
+			err = -ENOMEM;
+			break;
+		}
+
+		/* map the data */
+		op->src_phys = dma_map_single(sdcp->dev, op->src, op->len,
+					      DMA_TO_DEVICE);
+		if (dma_mapping_error(sdcp->dev, op->src_phys)) {
+			dma_unmap_single(sdcp->dev, op->cipher.key_phys,
+					 AES_KEYSIZE_128 * 2,
+					 DMA_BIDIRECTIONAL);
+			dev_err(sdcp->dev, "Unable to map source\n");
+			err = -ENOMEM;
+			break;
+		}
+
+		op->dst_phys = dma_map_single(sdcp->dev, op->dst, op->len,
+					      DMA_FROM_DEVICE);
+		if (dma_mapping_error(sdcp->dev, op->dst_phys)) {
+			dma_unmap_single(sdcp->dev, op->cipher.key_phys,
+					 AES_KEYSIZE_128 * 2,
+					 DMA_BIDIRECTIONAL);
+			dma_unmap_single(sdcp->dev, op->src_phys, op->len,
+					 DMA_TO_DEVICE);
+			dev_err(sdcp->dev, "Unable to map dest\n");
+			err = -ENOMEM;
+			break;
+		}
+
+		/* perform! */
+		dcp_perform_op(op);
+
+		dma_unmap_single(sdcp->dev, op->cipher.key_phys,
+				 AES_KEYSIZE_128 * 2, DMA_BIDIRECTIONAL);
+		dma_unmap_single(sdcp->dev, op->dst_phys, op->len,
+				 DMA_FROM_DEVICE);
+		dma_unmap_single(sdcp->dev, op->src_phys, op->len,
+				 DMA_TO_DEVICE);
+
+		nbytes -= op->len;
+		err = blkcipher_walk_done(desc, &walk, nbytes);
+
+		blockno++;
+	}
+
+	return err;
+}
+
+static int
+dcp_aes_cbc_encrypt(struct blkcipher_desc *desc,
+		    struct scatterlist *dst, struct scatterlist *src,
+		    unsigned int nbytes)
+{
+	struct dcp *sdcp = global_sdcp;
+	struct dcp_op *op = crypto_blkcipher_ctx(desc->tfm);
+	struct blkcipher_walk walk;
+	int err, ret, blockno;
+
+	if (unlikely(op->cipher.keylen != AES_KEYSIZE_128))
+		return fallback_blk_enc(desc, dst, src, nbytes);
+
+	blkcipher_walk_init(&walk, dst, src, nbytes);
+
+	blockno = 0;
+
+	err = blkcipher_walk_virt(desc, &walk);
+	while (err == 0 && (nbytes = walk.nbytes) > 0) {
+		op->src = walk.src.virt.addr, op->dst = walk.dst.virt.addr;
+		op->flags = DCP_AES | DCP_ENC | DCP_CBC;
+		if (blockno == 0) {
+			op->flags |= DCP_CBC_INIT;
+			memcpy(op->cipher.key + AES_KEYSIZE_128, walk.iv,
+			       AES_KEYSIZE_128);
+		}
+		op->len = nbytes - (nbytes % AES_KEYSIZE_128);
+
+		/* key needs to be mapped only once */
+		op->cipher.key_phys = dma_map_single(sdcp->dev, op->cipher.key,
+						     AES_KEYSIZE_128 * 2,
+						     DMA_BIDIRECTIONAL);
+		if (dma_mapping_error(sdcp->dev, op->cipher.key_phys)) {
+			dev_err(sdcp->dev, "Unable to map key\n");
+			return -ENOMEM;
+		}
+
+		/* map the data */
+		op->src_phys = dma_map_single(sdcp->dev, op->src, op->len,
+					      DMA_TO_DEVICE);
+		if (dma_mapping_error(sdcp->dev, op->src_phys)) {
+			dma_unmap_single(sdcp->dev, op->cipher.key_phys,
+					 AES_KEYSIZE_128 * 2,
+					 DMA_BIDIRECTIONAL);
+			dev_err(sdcp->dev, "Unable to map source\n");
+			err = -ENOMEM;
+			break;
+		}
+
+		op->dst_phys = dma_map_single(sdcp->dev, op->dst, op->len,
+					      DMA_FROM_DEVICE);
+		if (dma_mapping_error(sdcp->dev, op->dst_phys)) {
+			dma_unmap_single(sdcp->dev, op->cipher.key_phys,
+					 AES_KEYSIZE_128 * 2,
+					 DMA_BIDIRECTIONAL);
+			dma_unmap_single(sdcp->dev, op->src_phys, op->len,
+					 DMA_TO_DEVICE);
+			dev_err(sdcp->dev, "Unable to map dest\n");
+			err = -ENOMEM;
+			break;
+		}
+
+		/* perform! */
+		dcp_perform_op(op);
+
+		dma_unmap_single(sdcp->dev, op->cipher.key_phys,
+				 AES_KEYSIZE_128 * 2, DMA_BIDIRECTIONAL);
+		dma_unmap_single(sdcp->dev, op->dst_phys, op->len,
+				 DMA_FROM_DEVICE);
+		dma_unmap_single(sdcp->dev, op->src_phys, op->len,
+				 DMA_TO_DEVICE);
+
+		nbytes -= op->len;
+		ret = blkcipher_walk_done(desc, &walk, nbytes);
+
+		blockno++;
+	}
+
+	return err;
+}
+
+static struct crypto_alg dcp_aes_cbc_alg = {
+	.cra_name = "cbc(aes)",
+	.cra_driver_name = "dcp-cbc-aes",
+	.cra_priority = 400,
+	.cra_alignmask = 15,
+	.cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER | CRYPTO_ALG_NEED_FALLBACK,
+	.cra_init = fallback_init_blk,
+	.cra_exit = fallback_exit_blk,
+	.cra_blocksize = AES_KEYSIZE_128,
+	.cra_ctxsize = sizeof(struct dcp_op),
+	.cra_type = &crypto_blkcipher_type,
+	.cra_module = THIS_MODULE,
+	.cra_list = LIST_HEAD_INIT(dcp_aes_cbc_alg.cra_list),
+	.cra_u = {
+		  .blkcipher = {
+				.min_keysize = AES_MIN_KEY_SIZE,
+				.max_keysize = AES_MAX_KEY_SIZE,
+				.setkey = dcp_aes_setkey_blk,
+				.encrypt = dcp_aes_cbc_encrypt,
+				.decrypt = dcp_aes_cbc_decrypt,
+				.ivsize = AES_KEYSIZE_128,
+				}
+		  }
+};
+
+static int dcp_perform_hash_op(struct dcp_hash_coherent_block *input,
+			       u32 num_desc, bool init, bool terminate)
+{
+	struct dcp *sdcp = global_sdcp;
+	int chan;
+	struct dcp_hw_packet *pkt;
+	struct dcp_hash_coherent_block *hw;
+	unsigned long timeout;
+	u32 stat;
+	int descno, mapped;
+
+	chan = HASH_CHAN;
+
+	hw = input;
+	pkt = hw->pkt;
+
+	for (descno = 0; descno < num_desc; descno++) {
+
+		if (descno != 0) {
+
+			/* set next ptr and CHAIN bit in last packet */
+			pkt->pNext =
+			    hw->next->my_phys +
+			    offsetof(struct dcp_hash_coherent_block, pkt[0]);
+			pkt->pkt1 |= BM_DCP_PACKET1_CHAIN;
+
+			/* iterate to next descriptor */
+			hw = hw->next;
+			pkt = hw->pkt;
+		}
+
+		pkt->pkt1 = BM_DCP_PACKET1_DECR_SEMAPHORE |
+		    BM_DCP_PACKET1_ENABLE_HASH;
+
+		if (init && descno == 0)
+			pkt->pkt1 |= BM_DCP_PACKET1_HASH_INIT;
+
+		pkt->pkt2 = BF(hw->hash_sel, DCP_PACKET2_HASH_SELECT);
+
+		/* no need to flush buf1 or buf2, which are uncached */
+		if (hw->src != sdcp->buf1 && hw->src != sdcp->buf2) {
+
+			/* we have to flush the cache for the buffer */
+			hw->src_phys = dma_map_single(sdcp->dev,
+						      hw->src, hw->len,
+						      DMA_TO_DEVICE);
+
+			if (dma_mapping_error(sdcp->dev, hw->src_phys)) {
+				dev_err(sdcp->dev, "Unable to map source\n");
+
+				/* unmap any previous mapped buffers */
+				for (mapped = 0, hw = input; mapped < descno;
+				     mapped++) {
+
+					if (mapped != 0)
+						hw = hw->next;
+					if (hw->src != sdcp->buf1 &&
+					    hw->src != sdcp->buf2)
+						dma_unmap_single(sdcp->dev,
+								 hw->src_phys,
+								 hw->len,
+								 DMA_TO_DEVICE);
+				}
+
+				return -EFAULT;
+			}
+		}
+
+		pkt->pSrc = (u32) hw->src_phys;
+		pkt->pDst = 0;
+		pkt->size = hw->len;
+		pkt->pPayload = 0;
+		pkt->stat = 0;
+
+		/* set HASH_TERM bit on last buf if terminate was set */
+		if (terminate && (descno == (num_desc - 1))) {
+			pkt->pkt1 |= BM_DCP_PACKET1_HASH_TERM;
+
+			memset(input->digest, 0, sizeof(input->digest));
+
+			/* set payload ptr to the 1st buffer's digest */
+			pkt->pPayload = (u32) input->my_phys +
+			    offsetof(struct dcp_hash_coherent_block, digest);
+		}
+	}
+
+	/* submit the work */
+
+	__raw_writel(-1,
+		     (volatile void *)(sdcp->dcp_regs_base +
+				       HW_DCP_CHnSTAT_CLR(chan)));
+
+	mb();
+	/* Load the 1st descriptor's physical address */
+	__raw_writel((u32) input->my_phys +
+		     offsetof(struct dcp_hash_coherent_block,
+			      pkt[0]),
+		     (volatile void *)(sdcp->dcp_regs_base +
+				       HW_DCP_CHnCMDPTR(chan)));
+
+	/* XXX wake from interrupt instead of looping */
+	timeout = jiffies + msecs_to_jiffies(1000);
+
+	/* write num_desc into sema register */
+	__raw_writel(BF(num_desc, DCP_CHnSEMA_INCREMENT),
+		     (volatile void *)(sdcp->dcp_regs_base +
+				       HW_DCP_CHnSEMA(chan)));
+
+	while (time_before(jiffies, timeout)
+	       &&
+	       (__raw_readl
+		((volatile void *)(sdcp->dcp_regs_base +
+				   ((HW_DCP_CHnSEMA(chan) >> 16) & 0xff))) !=
+		0)) {
+		cpu_relax();
+	}
+
+	if (!time_before(jiffies, timeout)) {
+		dev_err(sdcp->dev,
+			"Timeout while waiting STAT 0x%08x\n",
+			__raw_readl((volatile void *)(sdcp->dcp_regs_base +
+						      HW_DCP_STAT)));
+	}
+
+	stat =
+	    __raw_readl((volatile void *)(sdcp->dcp_regs_base +
+					  HW_DCP_CHnSTAT(chan)));
+	if ((stat & 0xff) != 0)
+		dev_err(sdcp->dev, "Channel stat error 0x%02x\n",
+			__raw_readl((volatile void *)(sdcp->dcp_regs_base +
+						      (HW_DCP_CHnSTAT(chan) &
+						       0xff))));
+
+	/* unmap all src buffers */
+	for (descno = 0, hw = input; descno < num_desc; descno++) {
+		if (descno != 0)
+			hw = hw->next;
+		if (hw->src != sdcp->buf1 && hw->src != sdcp->buf2)
+			dma_unmap_single(sdcp->dev, hw->src_phys, hw->len,
+					 DMA_TO_DEVICE);
+	}
+
+	return 0;
+
+}
+
+static int dcp_sha_init(struct shash_desc *desc)
+{
+	struct dcp *sdcp = global_sdcp;
+	struct dcp_hash_op *op = shash_desc_ctx(desc);
+	struct mutex *mutex = &sdcp->op_mutex[HASH_CHAN];
+
+	mutex_lock(mutex);
+	dcp_clock(sdcp, CLOCK_ON, false);
+	sdcp->chan_in_use[HASH_CHAN] = true;
+
+	op->length = 0;
+
+	/* reset the lengths and the pointers of buffer descriptors */
+	sdcp->buf1_desc->len = 0;
+	sdcp->buf1_desc->src = sdcp->buf1;
+	sdcp->buf2_desc->len = 0;
+	sdcp->buf2_desc->src = sdcp->buf2;
+	op->head_desc = sdcp->buf1_desc;
+	op->tail_desc = sdcp->buf2_desc;
+
+	return 0;
+}
+
+static int dcp_sha_update(struct shash_desc *desc, const u8 *data,
+			  unsigned int length)
+{
+	struct dcp *sdcp = global_sdcp;
+	struct dcp_hash_op *op = shash_desc_ctx(desc);
+	struct dcp_hash_coherent_block *temp;
+	u32 rem_bytes, bytes_borrowed, hash_sel;
+	int ret = 0;
+
+	if (strcmp(desc->tfm->base.__crt_alg->cra_name, "sha1") == 0)
+		hash_sel = BV_DCP_PACKET2_HASH_SELECT__SHA1;
+	else
+		hash_sel = BV_DCP_PACKET2_HASH_SELECT__SHA256;
+
+	sdcp->user_buf_desc->src = (void *)data;
+	sdcp->user_buf_desc->len = length;
+
+	op->tail_desc->len = 0;
+
+	/* check if any pending data from previous updates */
+	if (op->head_desc->len) {
+
+		/* borrow from this buffer to make it 64 bytes */
+		bytes_borrowed = min(64 - op->head_desc->len,
+				     sdcp->user_buf_desc->len);
+
+		/* copy n bytes to head */
+		memcpy(op->head_desc->src + op->head_desc->len,
+		       sdcp->user_buf_desc->src, bytes_borrowed);
+		op->head_desc->len += bytes_borrowed;
+
+		/* update current buffer's src and len */
+		sdcp->user_buf_desc->src += bytes_borrowed;
+		sdcp->user_buf_desc->len -= bytes_borrowed;
+	}
+
+	/* Is current buffer unaligned to 64 byte length?
+	 * Each buffer's length must be a multiple of 64 bytes for DCP
+	 */
+	rem_bytes = sdcp->user_buf_desc->len % 64;
+
+	/* if length is unaligned, copy remainder to tail */
+	if (rem_bytes) {
+
+		memcpy(op->tail_desc->src, (sdcp->user_buf_desc->src +
+					    sdcp->user_buf_desc->len -
+					    rem_bytes), rem_bytes);
+
+		/* update length of current buffer */
+		sdcp->user_buf_desc->len -= rem_bytes;
+
+		op->tail_desc->len = rem_bytes;
+	}
+
+	/* do not send to DCP if length is < 64 */
+	if ((op->head_desc->len + sdcp->user_buf_desc->len) >= 64) {
+
+		/* set hash alg to be used (SHA1 or SHA256) */
+		op->head_desc->hash_sel = hash_sel;
+		sdcp->user_buf_desc->hash_sel = hash_sel;
+
+		if (op->head_desc->len) {
+			op->head_desc->next = sdcp->user_buf_desc;
+
+			ret = dcp_perform_hash_op(op->head_desc,
+						  sdcp->user_buf_desc->
+						  len ? 2 : 1, op->length == 0,
+						  false);
+		} else {
+			ret = dcp_perform_hash_op(sdcp->user_buf_desc, 1,
+						  op->length == 0, false);
+		}
+
+		op->length += op->head_desc->len + sdcp->user_buf_desc->len;
+		op->head_desc->len = 0;
+	}
+
+	/* if tail has bytes, make it the head for next time */
+	if (op->tail_desc->len) {
+		temp = op->head_desc;
+		op->head_desc = op->tail_desc;
+		op->tail_desc = temp;
+	}
+
+	/* hash_sel to be used by final function */
+	op->head_desc->hash_sel = hash_sel;
+
+	return ret;
+}
+
+static int dcp_sha_final(struct shash_desc *desc, u8 *out)
+{
+	struct dcp_hash_op *op = shash_desc_ctx(desc);
+	const uint8_t *digest;
+	struct dcp *sdcp = global_sdcp;
+	u32 i, digest_len;
+	struct mutex *mutex = &sdcp->op_mutex[HASH_CHAN];
+	int ret = 0;
+
+	/* Send the leftover bytes in head, which can be length 0,
+	 * but DCP still produces hash result in payload ptr.
+	 * Last data bytes need not be 64-byte multiple.
+	 */
+	ret = dcp_perform_hash_op(op->head_desc, 1, op->length == 0, true);
+
+	op->length += op->head_desc->len;
+
+	digest_len = (op->head_desc->hash_sel ==
+		      BV_DCP_PACKET2_HASH_SELECT__SHA1) ? SHA1_DIGEST_SIZE :
+	    SHA256_DIGEST_SIZE;
+
+	/* hardware reverses the digest (for some unexplicable reason) */
+	digest = op->head_desc->digest + digest_len;
+	for (i = 0; i < digest_len; i++)
+		*out++ = *--digest;
+
+	sdcp->chan_in_use[HASH_CHAN] = false;
+	dcp_clock(sdcp, CLOCK_OFF, false);
+	mutex_unlock(mutex);
+
+	return ret;
+}
+
+static struct shash_alg dcp_sha1_alg = {
+	.init = dcp_sha_init,
+	.update = dcp_sha_update,
+	.final = dcp_sha_final,
+	.descsize = sizeof(struct dcp_hash_op),
+	.digestsize = SHA1_DIGEST_SIZE,
+	.base = {
+		 .cra_name = "sha1",
+		 .cra_driver_name = "sha1-dcp",
+		 .cra_priority = 300,
+		 .cra_blocksize = SHA1_BLOCK_SIZE,
+		 .cra_ctxsize = sizeof(struct dcp_hash_op),
+		 .cra_module = THIS_MODULE,
+		 }
+};
+
+static struct shash_alg dcp_sha256_alg = {
+	.init = dcp_sha_init,
+	.update = dcp_sha_update,
+	.final = dcp_sha_final,
+	.descsize = sizeof(struct dcp_hash_op),
+	.digestsize = SHA256_DIGEST_SIZE,
+	.base = {
+		 .cra_name = "sha256",
+		 .cra_driver_name = "sha256-dcp",
+		 .cra_priority = 300,
+		 .cra_blocksize = SHA256_BLOCK_SIZE,
+		 .cra_ctxsize = sizeof(struct dcp_hash_op),
+		 .cra_module = THIS_MODULE,
+		 }
+};
+
+static irqreturn_t dcp_common_irq(int irq, void *context)
+{
+	struct dcp *sdcp = context;
+	u32 msk;
+
+	/* check */
+	msk =
+	    __raw_readl((volatile void *)(sdcp->dcp_regs_base +
+					  HW_DCP_STAT)) & BF(0x0f,
+							     DCP_STAT_IRQ);
+	if (msk == 0)
+		return IRQ_NONE;
+
+	/* clear this channel */
+	__raw_writel(msk,
+		     (volatile void *)(sdcp->dcp_regs_base + HW_DCP_STAT_CLR));
+	if (msk & BF(0x01, DCP_STAT_IRQ))
+		sdcp->wait[0]++;
+	if (msk & BF(0x02, DCP_STAT_IRQ))
+		sdcp->wait[1]++;
+	if (msk & BF(0x04, DCP_STAT_IRQ))
+		sdcp->wait[2]++;
+	if (msk & BF(0x08, DCP_STAT_IRQ))
+		sdcp->wait[3]++;
+	return IRQ_HANDLED;
+}
+
+static irqreturn_t dcp_vmi_irq(int irq, void *context)
+{
+	return dcp_common_irq(irq, context);
+}
+
+static irqreturn_t dcp_irq(int irq, void *context)
+{
+	return dcp_common_irq(irq, context);
+}
+
+/* DCP bootstream verification interface: uses OTP key for crypto */
+static long dcp_bootstream_ioctl(struct file *file, unsigned int cmd,
+				 unsigned long arg)
+{
+	struct dcp *sdcp = global_sdcp;
+	struct dcpboot_dma_area *da = sdcp->dcpboot_dma_area;
+	void __user *argp = (void __user *)arg;
+	int chan = ROM_DCP_CHAN;
+	unsigned long timeout;
+	struct mutex *mutex;
+	int retVal;
+
+	/* be paranoid */
+	if (sdcp == NULL)
+		return -EBADF;
+
+	if (cmd != DBS_ENC && cmd != DBS_DEC)
+		return -EINVAL;
+
+	/* copy to (aligned) block */
+	if (copy_from_user(da->block, argp, 16))
+		return -EFAULT;
+
+	mutex = &sdcp->op_mutex[chan];
+	mutex_lock(mutex);
+	dcp_clock(sdcp, CLOCK_ON, false);
+	sdcp->chan_in_use[chan] = true;
+
+	__raw_writel(-1, (volatile void *)(sdcp->dcp_regs_base +
+					   HW_DCP_CHnSTAT_CLR(ROM_DCP_CHAN)));
+	__raw_writel(BF(ROM_DCP_CHAN_MASK, DCP_STAT_IRQ),
+		     (volatile void *)(sdcp->dcp_regs_base + HW_DCP_STAT_CLR));
+
+	da->hw_packet.pNext = 0;
+	da->hw_packet.pkt1 = BM_DCP_PACKET1_DECR_SEMAPHORE |
+	    BM_DCP_PACKET1_ENABLE_CIPHER | BM_DCP_PACKET1_OTP_KEY |
+	    BM_DCP_PACKET1_INTERRUPT |
+	    (cmd == DBS_ENC ? BM_DCP_PACKET1_CIPHER_ENCRYPT : 0);
+	da->hw_packet.pkt2 = BF(0, DCP_PACKET2_CIPHER_CFG) |
+	    BF(0, DCP_PACKET2_KEY_SELECT) |
+	    BF(BV_DCP_PACKET2_CIPHER_MODE__ECB, DCP_PACKET2_CIPHER_MODE) |
+	    BF(BV_DCP_PACKET2_CIPHER_SELECT__AES128, DCP_PACKET2_CIPHER_SELECT);
+	da->hw_packet.pSrc = sdcp->dcpboot_dma_area_phys +
+	    offsetof(struct dcpboot_dma_area, block);
+	da->hw_packet.pDst = da->hw_packet.pSrc;	/* in-place */
+	da->hw_packet.size = 16;
+	da->hw_packet.pPayload = 0;
+	da->hw_packet.stat = 0;
+
+	/* Load the work packet pointer and bump the channel semaphore */
+	__raw_writel(sdcp->dcpboot_dma_area_phys +
+		     offsetof(struct dcpboot_dma_area, hw_packet),
+		     (volatile void *)(sdcp->dcp_regs_base +
+				       HW_DCP_CHnCMDPTR(ROM_DCP_CHAN)));
+
+	sdcp->wait[chan] = 0;
+	__raw_writel(BF(1, DCP_CHnSEMA_INCREMENT),
+		     (volatile void *)(sdcp->dcp_regs_base +
+				       HW_DCP_CHnSEMA(ROM_DCP_CHAN)));
+
+	timeout = jiffies + msecs_to_jiffies(100);
+
+	while (time_before(jiffies, timeout) && sdcp->wait[chan] == 0)
+		cpu_relax();
+
+	if (!time_before(jiffies, timeout)) {
+		dev_err(sdcp->dev,
+			"Timeout while waiting for operation to complete\n");
+		retVal = -ETIMEDOUT;
+		goto exit;
+	}
+
+	if (__raw_readl
+	    ((volatile void *)(sdcp->dcp_regs_base +
+			       (HW_DCP_CHnSTAT(ROM_DCP_CHAN) & 0xff))) != 0) {
+		dev_err(sdcp->dev, "Channel stat error 0x%02x\n",
+			__raw_readl((volatile void *)(sdcp->dcp_regs_base +
+						      (HW_DCP_CHnSTAT
+						       (ROM_DCP_CHAN) &
+						       0xff))));
+		retVal = -EFAULT;
+		goto exit;
+	}
+
+	if (copy_to_user(argp, da->block, 16)) {
+		retVal = -EFAULT;
+		goto exit;
+	}
+
+	retVal = 0;
+
+ exit:
+	sdcp->chan_in_use[chan] = false;
+	dcp_clock(sdcp, CLOCK_OFF, false);
+	mutex_unlock(mutex);
+	return retVal;
+}
+
+static const struct file_operations dcp_bootstream_fops = {
+	.owner = THIS_MODULE,
+	.unlocked_ioctl = dcp_bootstream_ioctl,
+};
+
+static struct miscdevice dcp_bootstream_misc = {
+	.minor = MISC_DYNAMIC_MINOR,
+	.name = "dcpboot",
+	.fops = &dcp_bootstream_fops,
+};
+
+static int dcp_probe(struct platform_device *pdev)
+{
+	struct dcp *sdcp = NULL;
+	struct resource *r;
+	int i, ret;
+	dma_addr_t hw_phys;
+
+	if (global_sdcp != NULL) {
+		dev_err(&pdev->dev, "Only one instance allowed\n");
+		ret = -ENODEV;
+		goto err;
+	}
+
+	/* allocate memory */
+	sdcp = kzalloc(sizeof(*sdcp), GFP_KERNEL);
+	if (sdcp == NULL) {
+		dev_err(&pdev->dev, "Failed to allocate structure\n");
+		ret = -ENOMEM;
+		goto err;
+	}
+
+	sdcp->dev = &pdev->dev;
+	spin_lock_init(&sdcp->lock);
+
+	for (i = 0; i < DCP_NUM_CHANNELS; i++) {
+		mutex_init(&sdcp->op_mutex[i]);
+		init_completion(&sdcp->op_wait[i]);
+		sdcp->chan_in_use[i] = false;
+	}
+
+	platform_set_drvdata(pdev, sdcp);
+
+	r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	if (!r) {
+		dev_err(&pdev->dev, "failed to get IORESOURCE_MEM\n");
+		ret = -ENXIO;
+		goto err_kfree;
+	}
+	sdcp->dcp_regs_base = (u32) ioremap(r->start, r->end - r->start + 1);
+	dcp_clock(sdcp, CLOCK_ON, true);
+
+	/* Soft reset and remove the clock gate */
+	__raw_writel(BM_DCP_CTRL_SFTRST,
+		     (volatile void *)(sdcp->dcp_regs_base + HW_DCP_CTRL_SET));
+
+	/* At 24Mhz, it takes no more than 4 clocks (160 ns) Maximum for
+	 * the part to reset, reading the register twice should
+	 * be sufficient to get 4 clks delay.
+	 */
+	__raw_readl((volatile void *)(sdcp->dcp_regs_base + HW_DCP_CTRL));
+	__raw_readl((volatile void *)(sdcp->dcp_regs_base + HW_DCP_CTRL));
+
+	__raw_writel(BM_DCP_CTRL_SFTRST | BM_DCP_CTRL_CLKGATE,
+		     (volatile void *)(sdcp->dcp_regs_base + HW_DCP_CTRL_CLR));
+
+	/* Initialize control registers */
+	__raw_writel(DCP_CTRL_INIT,
+		     (volatile void *)(sdcp->dcp_regs_base + HW_DCP_CTRL));
+	__raw_writel(DCP_CHANNELCTRL_INIT,
+		     (volatile void *)(sdcp->dcp_regs_base +
+				       HW_DCP_CHANNELCTRL));
+
+	/* We do not enable context switching. Give the context
+	 * buffer pointer an illegal address so if context switching is
+	 * inadvertantly enabled, the dcp will return an error instead of
+	 * trashing good memory. The dcp dma cannot access rom, so any rom
+	 * address will do.
+	 */
+	__raw_writel(0xFFFF0000,
+		     (volatile void *)(sdcp->dcp_regs_base + HW_DCP_CONTEXT));
+
+	for (i = 0; i < DCP_NUM_CHANNELS; i++)
+		__raw_writel(-1,
+			     (volatile void *)(sdcp->dcp_regs_base +
+					       HW_DCP_CHnSTAT_CLR(i)));
+	__raw_writel(-1,
+		     (volatile void *)(sdcp->dcp_regs_base + HW_DCP_STAT_CLR));
+
+	r = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
+	if (!r) {
+		dev_err(&pdev->dev, "can't get IRQ resource (0)\n");
+		ret = -EIO;
+		goto err_gate_clk;
+	}
+	sdcp->dcp_vmi_irq = r->start;
+	ret = request_irq(sdcp->dcp_vmi_irq, dcp_vmi_irq, 0, "dcp", sdcp);
+	if (ret != 0) {
+		dev_err(&pdev->dev, "can't request_irq (0)\n");
+		goto err_gate_clk;
+	}
+
+	r = platform_get_resource(pdev, IORESOURCE_IRQ, 1);
+	if (!r) {
+		dev_err(&pdev->dev, "can't get IRQ resource (1)\n");
+		ret = -EIO;
+		goto err_free_irq0;
+	}
+	sdcp->dcp_irq = r->start;
+	ret = request_irq(sdcp->dcp_irq, dcp_irq, 0, "dcp", sdcp);
+	if (ret != 0) {
+		dev_err(&pdev->dev, "can't request_irq (1)\n");
+		goto err_free_irq0;
+	}
+
+	global_sdcp = sdcp;
+
+	ret = crypto_register_alg(&dcp_aes_alg);
+	if (ret != 0) {
+		dev_err(&pdev->dev, "Failed to register aes crypto\n");
+		goto err_free_irq1;
+	}
+
+	ret = crypto_register_alg(&dcp_aes_ecb_alg);
+	if (ret != 0) {
+		dev_err(&pdev->dev, "Failed to register aes ecb crypto\n");
+		goto err_unregister_aes;
+	}
+
+	ret = crypto_register_alg(&dcp_aes_cbc_alg);
+	if (ret != 0) {
+		dev_err(&pdev->dev, "Failed to register aes cbc crypto\n");
+		goto err_unregister_aes_ecb;
+	}
+
+	/* Allocate the descriptor to be used for user buffer
+	 * passed in by the "update" function from Crypto API
+	 */
+	sdcp->user_buf_desc = dma_alloc_coherent(sdcp->dev,
+						 sizeof(struct
+							dcp_hash_coherent_block),
+						 &hw_phys, GFP_KERNEL);
+	if (sdcp->user_buf_desc == NULL) {
+		printk(KERN_ERR "Error allocating coherent block\n");
+		ret = -ENOMEM;
+		goto err_unregister_aes_cbc;
+	}
+
+	sdcp->user_buf_desc->my_phys = hw_phys;
+
+	/* Allocate 2 buffers (head & tail) & its descriptors to deal with
+	 * buffer lengths that are not 64 byte aligned, except for the
+	 * last one.
+	 */
+	sdcp->buf1 = dma_alloc_coherent(sdcp->dev,
+					64, &sdcp->buf1_phys, GFP_KERNEL);
+	if (sdcp->buf1 == NULL) {
+		printk(KERN_ERR "Error allocating coherent block\n");
+		ret = -ENOMEM;
+		goto err_unregister_aes_cbc;
+	}
+
+	sdcp->buf2 = dma_alloc_coherent(sdcp->dev,
+					64, &sdcp->buf2_phys, GFP_KERNEL);
+	if (sdcp->buf2 == NULL) {
+		printk(KERN_ERR "Error allocating coherent block\n");
+		ret = -ENOMEM;
+		goto err_unregister_aes_cbc;
+	}
+
+	sdcp->buf1_desc = dma_alloc_coherent(sdcp->dev,
+					     sizeof(struct
+						    dcp_hash_coherent_block),
+					     &hw_phys, GFP_KERNEL);
+	if (sdcp->buf1_desc == NULL) {
+		printk(KERN_ERR "Error allocating coherent block\n");
+		ret = -ENOMEM;
+		goto err_unregister_aes_cbc;
+	}
+
+	sdcp->buf1_desc->my_phys = hw_phys;
+	sdcp->buf1_desc->src = (void *)sdcp->buf1;
+	sdcp->buf1_desc->src_phys = sdcp->buf1_phys;
+
+	sdcp->buf2_desc = dma_alloc_coherent(sdcp->dev,
+					     sizeof(struct
+						    dcp_hash_coherent_block),
+					     &hw_phys, GFP_KERNEL);
+	if (sdcp->buf2_desc == NULL) {
+		printk(KERN_ERR "Error allocating coherent block\n");
+		ret = -ENOMEM;
+		goto err_unregister_aes_cbc;
+	}
+
+	sdcp->buf2_desc->my_phys = hw_phys;
+	sdcp->buf2_desc->src = (void *)sdcp->buf2;
+	sdcp->buf2_desc->src_phys = sdcp->buf2_phys;
+
+	ret = crypto_register_shash(&dcp_sha1_alg);
+	if (ret != 0) {
+		dev_err(&pdev->dev, "Failed to register sha1 hash\n");
+		goto err_unregister_aes_cbc;
+	}
+
+	if (__raw_readl
+	    ((volatile void *)(sdcp->dcp_regs_base +
+			       HW_DCP_CAPABILITY1)) &
+	    BF_DCP_CAPABILITY1_HASH_ALGORITHMS
+	    (BV_DCP_CAPABILITY1_HASH_ALGORITHMS__SHA256)) {
+
+		ret = crypto_register_shash(&dcp_sha256_alg);
+		if (ret != 0) {
+			dev_err(&pdev->dev, "Failed to register sha256 hash\n");
+			goto err_unregister_sha1;
+		}
+	}
+
+	/* register dcpboot interface to allow apps (such as kobs-ng) to
+	 * verify files (such as the bootstream) using the OTP key for crypto */
+	ret = misc_register(&dcp_bootstream_misc);
+	if (ret != 0) {
+		dev_err(&pdev->dev, "Unable to register misc device\n");
+		goto err_unregister_sha1;
+	}
+
+	sdcp->dcpboot_dma_area = dma_alloc_coherent(&pdev->dev,
+						    sizeof(*sdcp->
+							   dcpboot_dma_area),
+						    &sdcp->
+						    dcpboot_dma_area_phys,
+						    GFP_KERNEL);
+	if (sdcp->dcpboot_dma_area == NULL) {
+		dev_err(&pdev->dev, "Unable to allocate DMAable memory \
+			 for dcpboot interface\n");
+		goto err_dereg;
+	}
+
+	dcp_clock(sdcp, CLOCK_OFF, false);
+	dev_notice(&pdev->dev, "DCP crypto enabled.!\n");
+	return 0;
+
+ err_dereg:
+	misc_deregister(&dcp_bootstream_misc);
+ err_unregister_sha1:
+	crypto_unregister_shash(&dcp_sha1_alg);
+ err_unregister_aes_cbc:
+	crypto_unregister_alg(&dcp_aes_cbc_alg);
+ err_unregister_aes_ecb:
+	crypto_unregister_alg(&dcp_aes_ecb_alg);
+ err_unregister_aes:
+	crypto_unregister_alg(&dcp_aes_alg);
+ err_free_irq1:
+	free_irq(sdcp->dcp_irq, sdcp);
+ err_free_irq0:
+	free_irq(sdcp->dcp_vmi_irq, sdcp);
+ err_gate_clk:
+	dcp_clock(sdcp, CLOCK_OFF, false);
+ err_kfree:
+	kfree(sdcp);
+ err:
+
+	return ret;
+}
+
+static int dcp_remove(struct platform_device *pdev)
+{
+	struct dcp *sdcp;
+
+	sdcp = platform_get_drvdata(pdev);
+	platform_set_drvdata(pdev, NULL);
+
+	dcp_clock(sdcp, CLOCK_ON, false);
+
+	free_irq(sdcp->dcp_irq, sdcp);
+	free_irq(sdcp->dcp_vmi_irq, sdcp);
+
+	/* if head and tail buffers were allocated, free them */
+	if (sdcp->buf1) {
+		dma_free_coherent(sdcp->dev, 64, sdcp->buf1, sdcp->buf1_phys);
+		dma_free_coherent(sdcp->dev, 64, sdcp->buf2, sdcp->buf2_phys);
+
+		dma_free_coherent(sdcp->dev,
+				  sizeof(struct dcp_hash_coherent_block),
+				  sdcp->buf1_desc, sdcp->buf1_desc->my_phys);
+
+		dma_free_coherent(sdcp->dev,
+				  sizeof(struct dcp_hash_coherent_block),
+				  sdcp->buf2_desc, sdcp->buf2_desc->my_phys);
+
+		dma_free_coherent(sdcp->dev,
+				  sizeof(struct dcp_hash_coherent_block),
+				  sdcp->user_buf_desc,
+				  sdcp->user_buf_desc->my_phys);
+	}
+
+	if (sdcp->dcpboot_dma_area) {
+		dma_free_coherent(&pdev->dev, sizeof(*sdcp->dcpboot_dma_area),
+				  sdcp->dcpboot_dma_area,
+				  sdcp->dcpboot_dma_area_phys);
+		misc_deregister(&dcp_bootstream_misc);
+	}
+
+	crypto_unregister_shash(&dcp_sha1_alg);
+
+	if (__raw_readl
+	    ((volatile void *)(sdcp->dcp_regs_base +
+			       HW_DCP_CAPABILITY1)) &
+	    BF_DCP_CAPABILITY1_HASH_ALGORITHMS
+	    (BV_DCP_CAPABILITY1_HASH_ALGORITHMS__SHA256))
+		crypto_unregister_shash(&dcp_sha256_alg);
+
+	crypto_unregister_alg(&dcp_aes_cbc_alg);
+	crypto_unregister_alg(&dcp_aes_ecb_alg);
+	crypto_unregister_alg(&dcp_aes_alg);
+
+	dcp_clock(sdcp, CLOCK_OFF, true);
+	iounmap((void *)sdcp->dcp_regs_base);
+	kfree(sdcp);
+	global_sdcp = NULL;
+
+	return 0;
+}
+
+static int dcp_suspend(struct platform_device *pdev, pm_message_t state)
+{
+#ifdef CONFIG_PM
+	struct dcp *sdcp = platform_get_drvdata(pdev);
+
+	if (sdcp->clock_state == CLOCK_ON) {
+		dcp_clock(sdcp, CLOCK_OFF, true);
+		/* indicate that clock needs to be turned on upon resume */
+		sdcp->clock_state = CLOCK_ON;
+	}
+#endif
+	return 0;
+}
+
+static int dcp_resume(struct platform_device *pdev)
+{
+#ifdef CONFIG_PM
+	struct dcp *sdcp = platform_get_drvdata(pdev);
+
+	/* if clock was on prior to suspend, turn it back on */
+	if (sdcp->clock_state == CLOCK_ON)
+		dcp_clock(sdcp, CLOCK_ON, true);
+#endif
+	return 0;
+}
+
+static const struct of_device_id mxs_dcp_dt_ids[] = {
+	{.compatible = "fsl,fsl-dcp", .data = NULL,},
+	{ /* sentinel */ }
+};
+
+MODULE_DEVICE_TABLE(of, mxs_dcp_dt_ids);
+
+static struct platform_driver dcp_driver = {
+	.probe = dcp_probe,
+	.remove = dcp_remove,
+	.suspend = dcp_suspend,
+	.resume = dcp_resume,
+	.driver = {
+		   .name = "fsl-dcp",
+		   .owner = THIS_MODULE,
+		   .of_match_table = mxs_dcp_dt_ids,
+		   },
+};
+
+static int __init dcp_init(void)
+{
+	return platform_driver_register(&dcp_driver);
+}
+
+static void __exit dcp_exit(void)
+{
+	platform_driver_unregister(&dcp_driver);
+}
+
+MODULE_AUTHOR("Pantelis Antoniou <pantelis at embeddedalley.com>");
+MODULE_DESCRIPTION("DCP Crypto Driver");
+MODULE_LICENSE("GPL");
+
+module_init(dcp_init);
+module_exit(dcp_exit);
diff --git a/drivers/staging/crypto/fsl-dcp.h b/drivers/staging/crypto/fsl-dcp.h
new file mode 100644
index 0000000..7c9045f
--- /dev/null
+++ b/drivers/staging/crypto/fsl-dcp.h
@@ -0,0 +1,739 @@
+/*
+ * Copyright 2008-2010 Freescale Semiconductor, Inc. All Rights Reserved.
+ */
+
+/*
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+#ifndef DCP_H_
+#define DCP_H_
+
+/* cipher flags */
+#define DCP_ENC	0x0001
+#define DCP_DEC	0x0002
+#define DCP_ECB	0x0004
+#define DCP_CBC	0x0008
+#define DCP_CBC_INIT	0x0010
+#define DCP_OTPKEY	0x0020
+
+/* hash flags */
+#define DCP_INIT	0x0001
+#define DCP_UPDATE	0x0002
+#define DCP_FINAL	0x0004
+
+#define DCP_AES	0x1000
+#define DCP_SHA1	0x2000
+#define DCP_CRC32	0x3000
+#define DCP_COPY	0x4000
+#define DCP_FILL	0x5000
+#define DCP_MODE_MASK	0xf000
+
+/* clock defines */
+#define CLOCK_ON	1
+#define CLOCK_OFF	0
+
+#define CIPHER_CHAN	1
+#define CIPHER_MASK	(1 << CIPHER_CHAN)
+
+#define HASH_CHAN	0
+#define HASH_MASK	(1 << HASH_CHAN)
+
+/* DCP boostream interface uses this channel (same as the ROM) */
+#define ROM_DCP_CHAN 3
+#define ROM_DCP_CHAN_MASK (1 << ROM_DCP_CHAN)
+
+#define ALL_MASK	(CIPHER_MASK | HASH_MASK | ROM_DCP_CHAN_MASK)
+
+/* Defines the initialization value for the dcp control register */
+#define DCP_CTRL_INIT \
+   (BM_DCP_CTRL_GATHER_RESIDUAL_WRITES | \
+    BM_DCP_CTRL_ENABLE_CONTEXT_CACHING | \
+    BV_DCP_CTRL_CHANNEL_INTERRUPT_ENABLE__CH0 | \
+    BV_DCP_CTRL_CHANNEL_INTERRUPT_ENABLE__CH1 | \
+    BV_DCP_CTRL_CHANNEL_INTERRUPT_ENABLE__CH2 | \
+    BV_DCP_CTRL_CHANNEL_INTERRUPT_ENABLE__CH3)
+
+/* Defines the initialization value for the dcp channel control register */
+#define DCP_CHANNELCTRL_INIT \
+    BF(ALL_MASK, DCP_CHANNELCTRL_ENABLE_CHANNEL)
+
+/* DCP work packet 1 value for encryption */
+#define DCP_PKT1_ENCRYPT \
+   (BM_DCP_PACKET1_DECR_SEMAPHORE | \
+    BM_DCP_PACKET1_ENABLE_CIPHER | \
+    BM_DCP_PACKET1_CIPHER_ENCRYPT | \
+    BM_DCP_PACKET1_CIPHER_INIT)
+
+/* DCP work packet 1 value for decryption */
+#define DCP_PKT1_DECRYPT \
+   (BM_DCP_PACKET1_DECR_SEMAPHORE | \
+    BM_DCP_PACKET1_ENABLE_CIPHER | \
+    BM_DCP_PACKET1_CIPHER_INIT)
+
+/* DCP (decryption) work packet definition */
+struct dcp_hw_packet {
+	uint32_t pNext;		/* next dcp work packet address */
+	uint32_t pkt1;		/* dcp work packet 1 (control 0) */
+	uint32_t pkt2;		/* dcp work packet 2 (control 1) */
+	uint32_t pSrc;		/* source buffer address */
+	uint32_t pDst;		/* destination buffer address */
+	uint32_t size;		/* buffer size in bytes */
+	uint32_t pPayload;	/* payload buffer address */
+	uint32_t stat;		/* dcp status (written by dcp) */
+};
+
+#define DCP_NUM_CHANNELS 4
+
+/* DCP Register definitions */
+
+#ifndef BF
+#define BF(value, field) (((value) << BP_##field) & BM_##field)
+#endif
+
+#define REGS_DCP_SIZE 0x00002000
+
+#define HW_DCP_CTRL	(0x00000000)
+#define HW_DCP_CTRL_SET	(0x00000004)
+#define HW_DCP_CTRL_CLR	(0x00000008)
+#define HW_DCP_CTRL_TOG	(0x0000000c)
+
+#define BM_DCP_CTRL_SFTRST	0x80000000
+#define BM_DCP_CTRL_CLKGATE	0x40000000
+#define BM_DCP_CTRL_PRESENT_CRYPTO	0x20000000
+#define BV_DCP_CTRL_PRESENT_CRYPTO__Present 0x1
+#define BV_DCP_CTRL_PRESENT_CRYPTO__Absent  0x0
+#define BM_DCP_CTRL_PRESENT_CSC	0x10000000
+#define BV_DCP_CTRL_PRESENT_CSC__Present 0x1
+#define BV_DCP_CTRL_PRESENT_CSC__Absent  0x0
+#define BP_DCP_CTRL_RSVD1	24
+#define BM_DCP_CTRL_RSVD1	0x0F000000
+#define BF_DCP_CTRL_RSVD1(v)  \
+		(((v) << 24) & BM_DCP_CTRL_RSVD1)
+#define BM_DCP_CTRL_GATHER_RESIDUAL_WRITES	0x00800000
+#define BM_DCP_CTRL_ENABLE_CONTEXT_CACHING	0x00400000
+#define BM_DCP_CTRL_ENABLE_CONTEXT_SWITCHING	0x00200000
+#define BP_DCP_CTRL_RSVD0	9
+#define BM_DCP_CTRL_RSVD0	0x001FFE00
+#define BF_DCP_CTRL_RSVD0(v)  \
+		(((v) << 9) & BM_DCP_CTRL_RSVD0)
+#define BM_DCP_CTRL_CSC_INTERRUPT_ENABLE	0x00000100
+#define BP_DCP_CTRL_CHANNEL_INTERRUPT_ENABLE	0
+#define BM_DCP_CTRL_CHANNEL_INTERRUPT_ENABLE	0x000000FF
+#define BF_DCP_CTRL_CHANNEL_INTERRUPT_ENABLE(v)  \
+		(((v) << 0) & BM_DCP_CTRL_CHANNEL_INTERRUPT_ENABLE)
+#define BV_DCP_CTRL_CHANNEL_INTERRUPT_ENABLE__CH0 0x01
+#define BV_DCP_CTRL_CHANNEL_INTERRUPT_ENABLE__CH1 0x02
+#define BV_DCP_CTRL_CHANNEL_INTERRUPT_ENABLE__CH2 0x04
+#define BV_DCP_CTRL_CHANNEL_INTERRUPT_ENABLE__CH3 0x08
+
+#define HW_DCP_STAT	(0x00000010)
+#define HW_DCP_STAT_SET	(0x00000014)
+#define HW_DCP_STAT_CLR	(0x00000018)
+#define HW_DCP_STAT_TOG	(0x0000001c)
+
+#define BP_DCP_STAT_RSVD2	29
+#define BM_DCP_STAT_RSVD2	0xE0000000
+#define BF_DCP_STAT_RSVD2(v) \
+		(((v) << 29) & BM_DCP_STAT_RSVD2)
+#define BM_DCP_STAT_OTP_KEY_READY	0x10000000
+#define BP_DCP_STAT_CUR_CHANNEL	24
+#define BM_DCP_STAT_CUR_CHANNEL	0x0F000000
+#define BF_DCP_STAT_CUR_CHANNEL(v)  \
+		(((v) << 24) & BM_DCP_STAT_CUR_CHANNEL)
+#define BV_DCP_STAT_CUR_CHANNEL__None 0x0
+#define BV_DCP_STAT_CUR_CHANNEL__CH0  0x1
+#define BV_DCP_STAT_CUR_CHANNEL__CH1  0x2
+#define BV_DCP_STAT_CUR_CHANNEL__CH2  0x3
+#define BV_DCP_STAT_CUR_CHANNEL__CH3  0x4
+#define BV_DCP_STAT_CUR_CHANNEL__CSC  0x8
+#define BP_DCP_STAT_READY_CHANNELS	16
+#define BM_DCP_STAT_READY_CHANNELS	0x00FF0000
+#define BF_DCP_STAT_READY_CHANNELS(v)  \
+		(((v) << 16) & BM_DCP_STAT_READY_CHANNELS)
+#define BV_DCP_STAT_READY_CHANNELS__CH0 0x01
+#define BV_DCP_STAT_READY_CHANNELS__CH1 0x02
+#define BV_DCP_STAT_READY_CHANNELS__CH2 0x04
+#define BV_DCP_STAT_READY_CHANNELS__CH3 0x08
+#define BP_DCP_STAT_RSVD1	9
+#define BM_DCP_STAT_RSVD1	0x0000FE00
+#define BF_DCP_STAT_RSVD1(v)  \
+		(((v) << 9) & BM_DCP_STAT_RSVD1)
+#define BM_DCP_STAT_CSCIRQ	0x00000100
+#define BP_DCP_STAT_RSVD0	4
+#define BM_DCP_STAT_RSVD0	0x000000F0
+#define BF_DCP_STAT_RSVD0(v)  \
+		(((v) << 4) & BM_DCP_STAT_RSVD0)
+#define BP_DCP_STAT_IRQ	0
+#define BM_DCP_STAT_IRQ	0x0000000F
+#define BF_DCP_STAT_IRQ(v)  \
+		(((v) << 0) & BM_DCP_STAT_IRQ)
+
+#define HW_DCP_CHANNELCTRL	(0x00000020)
+#define HW_DCP_CHANNELCTRL_SET	(0x00000024)
+#define HW_DCP_CHANNELCTRL_CLR	(0x00000028)
+#define HW_DCP_CHANNELCTRL_TOG	(0x0000002c)
+
+#define BP_DCP_CHANNELCTRL_RSVD	19
+#define BM_DCP_CHANNELCTRL_RSVD	0xFFF80000
+#define BF_DCP_CHANNELCTRL_RSVD(v) \
+		(((v) << 19) & BM_DCP_CHANNELCTRL_RSVD)
+#define BP_DCP_CHANNELCTRL_CSC_PRIORITY	17
+#define BM_DCP_CHANNELCTRL_CSC_PRIORITY	0x00060000
+#define BF_DCP_CHANNELCTRL_CSC_PRIORITY(v)  \
+		(((v) << 17) & BM_DCP_CHANNELCTRL_CSC_PRIORITY)
+#define BV_DCP_CHANNELCTRL_CSC_PRIORITY__HIGH       0x3
+#define BV_DCP_CHANNELCTRL_CSC_PRIORITY__MED        0x2
+#define BV_DCP_CHANNELCTRL_CSC_PRIORITY__LOW        0x1
+#define BV_DCP_CHANNELCTRL_CSC_PRIORITY__BACKGROUND 0x0
+#define BM_DCP_CHANNELCTRL_CH0_IRQ_MERGED	0x00010000
+#define BP_DCP_CHANNELCTRL_HIGH_PRIORITY_CHANNEL	8
+#define BM_DCP_CHANNELCTRL_HIGH_PRIORITY_CHANNEL	0x0000FF00
+#define BF_DCP_CHANNELCTRL_HIGH_PRIORITY_CHANNEL(v)  \
+		(((v) << 8) & BM_DCP_CHANNELCTRL_HIGH_PRIORITY_CHANNEL)
+#define BV_DCP_CHANNELCTRL_HIGH_PRIORITY_CHANNEL__CH0 0x01
+#define BV_DCP_CHANNELCTRL_HIGH_PRIORITY_CHANNEL__CH1 0x02
+#define BV_DCP_CHANNELCTRL_HIGH_PRIORITY_CHANNEL__CH2 0x04
+#define BV_DCP_CHANNELCTRL_HIGH_PRIORITY_CHANNEL__CH3 0x08
+#define BP_DCP_CHANNELCTRL_ENABLE_CHANNEL	0
+#define BM_DCP_CHANNELCTRL_ENABLE_CHANNEL	0x000000FF
+#define BF_DCP_CHANNELCTRL_ENABLE_CHANNEL(v)  \
+		(((v) << 0) & BM_DCP_CHANNELCTRL_ENABLE_CHANNEL)
+#define BV_DCP_CHANNELCTRL_ENABLE_CHANNEL__CH0 0x01
+#define BV_DCP_CHANNELCTRL_ENABLE_CHANNEL__CH1 0x02
+#define BV_DCP_CHANNELCTRL_ENABLE_CHANNEL__CH2 0x04
+#define BV_DCP_CHANNELCTRL_ENABLE_CHANNEL__CH3 0x08
+
+#define HW_DCP_CAPABILITY0	(0x00000030)
+
+#define BM_DCP_CAPABILITY0_DISABLE_DECRYPT	0x80000000
+#define BM_DCP_CAPABILITY0_ENABLE_TZONE	0x40000000
+#define BP_DCP_CAPABILITY0_RSVD	12
+#define BM_DCP_CAPABILITY0_RSVD	0x3FFFF000
+#define BF_DCP_CAPABILITY0_RSVD(v)  \
+		(((v) << 12) & BM_DCP_CAPABILITY0_RSVD)
+#define BP_DCP_CAPABILITY0_NUM_CHANNELS	8
+#define BM_DCP_CAPABILITY0_NUM_CHANNELS	0x00000F00
+#define BF_DCP_CAPABILITY0_NUM_CHANNELS(v)  \
+		(((v) << 8) & BM_DCP_CAPABILITY0_NUM_CHANNELS)
+#define BP_DCP_CAPABILITY0_NUM_KEYS	0
+#define BM_DCP_CAPABILITY0_NUM_KEYS	0x000000FF
+#define BF_DCP_CAPABILITY0_NUM_KEYS(v)  \
+		(((v) << 0) & BM_DCP_CAPABILITY0_NUM_KEYS)
+
+#define HW_DCP_CAPABILITY1	(0x00000040)
+
+#define BP_DCP_CAPABILITY1_HASH_ALGORITHMS	16
+#define BM_DCP_CAPABILITY1_HASH_ALGORITHMS	0xFFFF0000
+#define BF_DCP_CAPABILITY1_HASH_ALGORITHMS(v) \
+		(((v) << 16) & BM_DCP_CAPABILITY1_HASH_ALGORITHMS)
+#define BV_DCP_CAPABILITY1_HASH_ALGORITHMS__SHA1  0x0001
+#define BV_DCP_CAPABILITY1_HASH_ALGORITHMS__CRC32 0x0002
+#define BV_DCP_CAPABILITY1_HASH_ALGORITHMS__SHA256  0x0004
+#define BP_DCP_CAPABILITY1_CIPHER_ALGORITHMS	0
+#define BM_DCP_CAPABILITY1_CIPHER_ALGORITHMS	0x0000FFFF
+#define BF_DCP_CAPABILITY1_CIPHER_ALGORITHMS(v)  \
+		(((v) << 0) & BM_DCP_CAPABILITY1_CIPHER_ALGORITHMS)
+#define BV_DCP_CAPABILITY1_CIPHER_ALGORITHMS__AES128 0x0001
+
+#define HW_DCP_CONTEXT	(0x00000050)
+
+#define BP_DCP_CONTEXT_ADDR	0
+#define BM_DCP_CONTEXT_ADDR	0xFFFFFFFF
+#define BF_DCP_CONTEXT_ADDR(v)	(v)
+
+#define HW_DCP_KEY	(0x00000060)
+
+#define BP_DCP_KEY_RSVD	8
+#define BM_DCP_KEY_RSVD	0xFFFFFF00
+#define BF_DCP_KEY_RSVD(v) \
+		(((v) << 8) & BM_DCP_KEY_RSVD)
+#define BP_DCP_KEY_RSVD_INDEX	6
+#define BM_DCP_KEY_RSVD_INDEX	0x000000C0
+#define BF_DCP_KEY_RSVD_INDEX(v)  \
+		(((v) << 6) & BM_DCP_KEY_RSVD_INDEX)
+#define BP_DCP_KEY_INDEX	4
+#define BM_DCP_KEY_INDEX	0x00000030
+#define BF_DCP_KEY_INDEX(v)  \
+		(((v) << 4) & BM_DCP_KEY_INDEX)
+#define BP_DCP_KEY_RSVD_SUBWORD	2
+#define BM_DCP_KEY_RSVD_SUBWORD	0x0000000C
+#define BF_DCP_KEY_RSVD_SUBWORD(v)  \
+		(((v) << 2) & BM_DCP_KEY_RSVD_SUBWORD)
+#define BP_DCP_KEY_SUBWORD	0
+#define BM_DCP_KEY_SUBWORD	0x00000003
+#define BF_DCP_KEY_SUBWORD(v)  \
+		(((v) << 0) & BM_DCP_KEY_SUBWORD)
+
+#define HW_DCP_KEYDATA	(0x00000070)
+
+#define BP_DCP_KEYDATA_DATA	0
+#define BM_DCP_KEYDATA_DATA	0xFFFFFFFF
+#define BF_DCP_KEYDATA_DATA(v)	(v)
+
+#define HW_DCP_PACKET0	(0x00000080)
+
+#define BP_DCP_PACKET0_ADDR	0
+#define BM_DCP_PACKET0_ADDR	0xFFFFFFFF
+#define BF_DCP_PACKET0_ADDR(v)	(v)
+
+#define HW_DCP_PACKET1	(0x00000090)
+
+#define BP_DCP_PACKET1_TAG	24
+#define BM_DCP_PACKET1_TAG	0xFF000000
+#define BF_DCP_PACKET1_TAG(v) \
+		(((v) << 24) & BM_DCP_PACKET1_TAG)
+#define BM_DCP_PACKET1_OUTPUT_WORDSWAP	0x00800000
+#define BM_DCP_PACKET1_OUTPUT_BYTESWAP	0x00400000
+#define BM_DCP_PACKET1_INPUT_WORDSWAP	0x00200000
+#define BM_DCP_PACKET1_INPUT_BYTESWAP	0x00100000
+#define BM_DCP_PACKET1_KEY_WORDSWAP	0x00080000
+#define BM_DCP_PACKET1_KEY_BYTESWAP	0x00040000
+#define BM_DCP_PACKET1_TEST_SEMA_IRQ	0x00020000
+#define BM_DCP_PACKET1_CONSTANT_FILL	0x00010000
+#define BM_DCP_PACKET1_HASH_OUTPUT	0x00008000
+#define BV_DCP_PACKET1_HASH_OUTPUT__INPUT  0x00
+#define BV_DCP_PACKET1_HASH_OUTPUT__OUTPUT 0x01
+#define BM_DCP_PACKET1_CHECK_HASH	0x00004000
+#define BM_DCP_PACKET1_HASH_TERM	0x00002000
+#define BM_DCP_PACKET1_HASH_INIT	0x00001000
+#define BM_DCP_PACKET1_PAYLOAD_KEY	0x00000800
+#define BM_DCP_PACKET1_OTP_KEY	0x00000400
+#define BM_DCP_PACKET1_CIPHER_INIT	0x00000200
+#define BM_DCP_PACKET1_CIPHER_ENCRYPT	0x00000100
+#define BV_DCP_PACKET1_CIPHER_ENCRYPT__ENCRYPT 0x01
+#define BV_DCP_PACKET1_CIPHER_ENCRYPT__DECRYPT 0x00
+#define BM_DCP_PACKET1_ENABLE_BLIT	0x00000080
+#define BM_DCP_PACKET1_ENABLE_HASH	0x00000040
+#define BM_DCP_PACKET1_ENABLE_CIPHER	0x00000020
+#define BM_DCP_PACKET1_ENABLE_MEMCOPY	0x00000010
+#define BM_DCP_PACKET1_CHAIN_CONTIGUOUS	0x00000008
+#define BM_DCP_PACKET1_CHAIN	0x00000004
+#define BM_DCP_PACKET1_DECR_SEMAPHORE	0x00000002
+#define BM_DCP_PACKET1_INTERRUPT	0x00000001
+
+#define HW_DCP_PACKET2	(0x000000a0)
+
+#define BP_DCP_PACKET2_CIPHER_CFG	24
+#define BM_DCP_PACKET2_CIPHER_CFG	0xFF000000
+#define BF_DCP_PACKET2_CIPHER_CFG(v) \
+		(((v) << 24) & BM_DCP_PACKET2_CIPHER_CFG)
+#define BP_DCP_PACKET2_RSVD	20
+#define BM_DCP_PACKET2_RSVD	0x00F00000
+#define BF_DCP_PACKET2_RSVD(v)  \
+		(((v) << 20) & BM_DCP_PACKET2_RSVD)
+#define BP_DCP_PACKET2_HASH_SELECT	16
+#define BM_DCP_PACKET2_HASH_SELECT	0x000F0000
+#define BF_DCP_PACKET2_HASH_SELECT(v)  \
+		(((v) << 16) & BM_DCP_PACKET2_HASH_SELECT)
+#define BV_DCP_PACKET2_HASH_SELECT__SHA1  0x00
+#define BV_DCP_PACKET2_HASH_SELECT__CRC32 0x01
+#define BV_DCP_PACKET2_HASH_SELECT__SHA256  0x02
+#define BP_DCP_PACKET2_KEY_SELECT	8
+#define BM_DCP_PACKET2_KEY_SELECT	0x0000FF00
+#define BF_DCP_PACKET2_KEY_SELECT(v)  \
+		(((v) << 8) & BM_DCP_PACKET2_KEY_SELECT)
+#define BP_DCP_PACKET2_CIPHER_MODE	4
+#define BM_DCP_PACKET2_CIPHER_MODE	0x000000F0
+#define BF_DCP_PACKET2_CIPHER_MODE(v)  \
+		(((v) << 4) & BM_DCP_PACKET2_CIPHER_MODE)
+#define BV_DCP_PACKET2_CIPHER_MODE__ECB 0x00
+#define BV_DCP_PACKET2_CIPHER_MODE__CBC 0x01
+#define BP_DCP_PACKET2_CIPHER_SELECT	0
+#define BM_DCP_PACKET2_CIPHER_SELECT	0x0000000F
+#define BF_DCP_PACKET2_CIPHER_SELECT(v)  \
+		(((v) << 0) & BM_DCP_PACKET2_CIPHER_SELECT)
+#define BV_DCP_PACKET2_CIPHER_SELECT__AES128 0x00
+
+#define HW_DCP_PACKET3	(0x000000b0)
+
+#define BP_DCP_PACKET3_ADDR	0
+#define BM_DCP_PACKET3_ADDR	0xFFFFFFFF
+#define BF_DCP_PACKET3_ADDR(v)	(v)
+
+#define HW_DCP_PACKET4	(0x000000c0)
+
+#define BP_DCP_PACKET4_ADDR	0
+#define BM_DCP_PACKET4_ADDR	0xFFFFFFFF
+#define BF_DCP_PACKET4_ADDR(v)	(v)
+
+#define HW_DCP_PACKET5	(0x000000d0)
+
+#define BP_DCP_PACKET5_COUNT	0
+#define BM_DCP_PACKET5_COUNT	0xFFFFFFFF
+#define BF_DCP_PACKET5_COUNT(v)	(v)
+
+#define HW_DCP_PACKET6	(0x000000e0)
+
+#define BP_DCP_PACKET6_ADDR	0
+#define BM_DCP_PACKET6_ADDR	0xFFFFFFFF
+#define BF_DCP_PACKET6_ADDR(v)	(v)
+
+/*
+ *  multi-register-define name HW_DCP_CHnCMDPTR
+ *              base 0x00000100
+ *              count 4
+ *              offset 0x40
+ */
+#define HW_DCP_CHnCMDPTR(n)	(0x00000100 + (n) * 0x40)
+
+#define BP_DCP_CHnCMDPTR_ADDR	0
+#define BM_DCP_CHnCMDPTR_ADDR	0xFFFFFFFF
+#define BF_DCP_CHnCMDPTR_ADDR(v)	(v)
+
+/*
+ *  multi-register-define name HW_DCP_CHnSEMA
+ *              base 0x00000110
+ *              count 4
+ *              offset 0x40
+ */
+#define HW_DCP_CHnSEMA(n)	(0x00000110 + (n) * 0x40)
+
+#define BP_DCP_CHnSEMA_RSVD2	24
+#define BM_DCP_CHnSEMA_RSVD2	0xFF000000
+#define BF_DCP_CHnSEMA_RSVD2(v) \
+		(((v) << 24) & BM_DCP_CHnSEMA_RSVD2)
+#define BP_DCP_CHnSEMA_VALUE	16
+#define BM_DCP_CHnSEMA_VALUE	0x00FF0000
+#define BF_DCP_CHnSEMA_VALUE(v)  \
+		(((v) << 16) & BM_DCP_CHnSEMA_VALUE)
+#define BP_DCP_CHnSEMA_RSVD1	8
+#define BM_DCP_CHnSEMA_RSVD1	0x0000FF00
+#define BF_DCP_CHnSEMA_RSVD1(v)  \
+		(((v) << 8) & BM_DCP_CHnSEMA_RSVD1)
+#define BP_DCP_CHnSEMA_INCREMENT	0
+#define BM_DCP_CHnSEMA_INCREMENT	0x000000FF
+#define BF_DCP_CHnSEMA_INCREMENT(v)  \
+		(((v) << 0) & BM_DCP_CHnSEMA_INCREMENT)
+
+/*
+ *  multi-register-define name HW_DCP_CHnSTAT
+ *              base 0x00000120
+ *              count 4
+ *              offset 0x40
+ */
+#define HW_DCP_CHnSTAT(n)	(0x00000120 + (n) * 0x40)
+#define HW_DCP_CHnSTAT_SET(n)	(0x00000124 + (n) * 0x40)
+#define HW_DCP_CHnSTAT_CLR(n)	(0x00000128 + (n) * 0x40)
+#define HW_DCP_CHnSTAT_TOG(n)	(0x0000012c + (n) * 0x40)
+
+#define BP_DCP_CHnSTAT_TAG	24
+#define BM_DCP_CHnSTAT_TAG	0xFF000000
+#define BF_DCP_CHnSTAT_TAG(v) \
+		(((v) << 24) & BM_DCP_CHnSTAT_TAG)
+#define BP_DCP_CHnSTAT_ERROR_CODE	16
+#define BM_DCP_CHnSTAT_ERROR_CODE	0x00FF0000
+#define BF_DCP_CHnSTAT_ERROR_CODE(v)  \
+		(((v) << 16) & BM_DCP_CHnSTAT_ERROR_CODE)
+#define BV_DCP_CHnSTAT_ERROR_CODE__NEXT_CHAIN_IS_0 0x01
+#define BV_DCP_CHnSTAT_ERROR_CODE__NO_CHAIN        0x02
+#define BV_DCP_CHnSTAT_ERROR_CODE__CONTEXT_ERROR   0x03
+#define BV_DCP_CHnSTAT_ERROR_CODE__PAYLOAD_ERROR   0x04
+#define BV_DCP_CHnSTAT_ERROR_CODE__INVALID_MODE    0x05
+#define BP_DCP_CHnSTAT_RSVD0	7
+#define BM_DCP_CHnSTAT_RSVD0	0x0000FF80
+#define BF_DCP_CHnSTAT_RSVD0(v)  \
+		(((v) << 7) & BM_DCP_CHnSTAT_RSVD0)
+#define BM_DCP_CHnSTAT_ERROR_PAGEFAULT	0x00000040
+#define BM_DCP_CHnSTAT_ERROR_DST	0x00000020
+#define BM_DCP_CHnSTAT_ERROR_SRC	0x00000010
+#define BM_DCP_CHnSTAT_ERROR_PACKET	0x00000008
+#define BM_DCP_CHnSTAT_ERROR_SETUP	0x00000004
+#define BM_DCP_CHnSTAT_HASH_MISMATCH	0x00000002
+#define BM_DCP_CHnSTAT_RSVD_COMPLETE	0x00000001
+
+/*
+ *  multi-register-define name HW_DCP_CHnOPTS
+ *              base 0x00000130
+ *              count 4
+ *              offset 0x40
+ */
+#define HW_DCP_CHnOPTS(n)	(0x00000130 + (n) * 0x40)
+#define HW_DCP_CHnOPTS_SET(n)	(0x00000134 + (n) * 0x40)
+#define HW_DCP_CHnOPTS_CLR(n)	(0x00000138 + (n) * 0x40)
+#define HW_DCP_CHnOPTS_TOG(n)	(0x0000013c + (n) * 0x40)
+
+#define BP_DCP_CHnOPTS_RSVD	16
+#define BM_DCP_CHnOPTS_RSVD	0xFFFF0000
+#define BF_DCP_CHnOPTS_RSVD(v) \
+		(((v) << 16) & BM_DCP_CHnOPTS_RSVD)
+#define BP_DCP_CHnOPTS_RECOVERY_TIMER	0
+#define BM_DCP_CHnOPTS_RECOVERY_TIMER	0x0000FFFF
+#define BF_DCP_CHnOPTS_RECOVERY_TIMER(v)  \
+		(((v) << 0) & BM_DCP_CHnOPTS_RECOVERY_TIMER)
+
+#define HW_DCP_CSCCTRL0	(0x00000300)
+#define HW_DCP_CSCCTRL0_SET	(0x00000304)
+#define HW_DCP_CSCCTRL0_CLR	(0x00000308)
+#define HW_DCP_CSCCTRL0_TOG	(0x0000030c)
+
+#define BP_DCP_CSCCTRL0_RSVD1	16
+#define BM_DCP_CSCCTRL0_RSVD1	0xFFFF0000
+#define BF_DCP_CSCCTRL0_RSVD1(v) \
+		(((v) << 16) & BM_DCP_CSCCTRL0_RSVD1)
+#define BM_DCP_CSCCTRL0_CLIP	0x00008000
+#define BM_DCP_CSCCTRL0_UPSAMPLE	0x00004000
+#define BM_DCP_CSCCTRL0_SCALE	0x00002000
+#define BM_DCP_CSCCTRL0_ROTATE	0x00001000
+#define BM_DCP_CSCCTRL0_SUBSAMPLE	0x00000800
+#define BM_DCP_CSCCTRL0_DELTA	0x00000400
+#define BP_DCP_CSCCTRL0_RGB_FORMAT	8
+#define BM_DCP_CSCCTRL0_RGB_FORMAT	0x00000300
+#define BF_DCP_CSCCTRL0_RGB_FORMAT(v)  \
+		(((v) << 8) & BM_DCP_CSCCTRL0_RGB_FORMAT)
+#define BV_DCP_CSCCTRL0_RGB_FORMAT__RGB16_565 0x0
+#define BV_DCP_CSCCTRL0_RGB_FORMAT__YCbCrI    0x1
+#define BV_DCP_CSCCTRL0_RGB_FORMAT__RGB24     0x2
+#define BV_DCP_CSCCTRL0_RGB_FORMAT__YUV422I   0x3
+#define BP_DCP_CSCCTRL0_YUV_FORMAT	4
+#define BM_DCP_CSCCTRL0_YUV_FORMAT	0x000000F0
+#define BF_DCP_CSCCTRL0_YUV_FORMAT(v)  \
+		(((v) << 4) & BM_DCP_CSCCTRL0_YUV_FORMAT)
+#define BV_DCP_CSCCTRL0_YUV_FORMAT__YUV420 0x0
+#define BV_DCP_CSCCTRL0_YUV_FORMAT__YUV422 0x2
+#define BP_DCP_CSCCTRL0_RSVD0	1
+#define BM_DCP_CSCCTRL0_RSVD0	0x0000000E
+#define BF_DCP_CSCCTRL0_RSVD0(v)  \
+		(((v) << 1) & BM_DCP_CSCCTRL0_RSVD0)
+#define BM_DCP_CSCCTRL0_ENABLE	0x00000001
+
+#define HW_DCP_CSCSTAT	(0x00000310)
+#define HW_DCP_CSCSTAT_SET	(0x00000314)
+#define HW_DCP_CSCSTAT_CLR	(0x00000318)
+#define HW_DCP_CSCSTAT_TOG	(0x0000031c)
+
+#define BP_DCP_CSCSTAT_RSVD3	24
+#define BM_DCP_CSCSTAT_RSVD3	0xFF000000
+#define BF_DCP_CSCSTAT_RSVD3(v) \
+		(((v) << 24) & BM_DCP_CSCSTAT_RSVD3)
+#define BP_DCP_CSCSTAT_ERROR_CODE	16
+#define BM_DCP_CSCSTAT_ERROR_CODE	0x00FF0000
+#define BF_DCP_CSCSTAT_ERROR_CODE(v)  \
+		(((v) << 16) & BM_DCP_CSCSTAT_ERROR_CODE)
+#define BV_DCP_CSCSTAT_ERROR_CODE__LUMA0_FETCH_ERROR_Y0 0x01
+#define BV_DCP_CSCSTAT_ERROR_CODE__LUMA1_FETCH_ERROR_Y1 0x02
+#define BV_DCP_CSCSTAT_ERROR_CODE__CHROMA_FETCH_ERROR_U 0x03
+#define BV_DCP_CSCSTAT_ERROR_CODE__CHROMA_FETCH_ERROR_V 0x04
+#define BP_DCP_CSCSTAT_RSVD2	7
+#define BM_DCP_CSCSTAT_RSVD2	0x0000FF80
+#define BF_DCP_CSCSTAT_RSVD2(v)  \
+		(((v) << 7) & BM_DCP_CSCSTAT_RSVD2)
+#define BM_DCP_CSCSTAT_ERROR_PAGEFAULT	0x00000040
+#define BM_DCP_CSCSTAT_ERROR_DST	0x00000020
+#define BM_DCP_CSCSTAT_ERROR_SRC	0x00000010
+#define BM_DCP_CSCSTAT_RSVD1	0x00000008
+#define BM_DCP_CSCSTAT_ERROR_SETUP	0x00000004
+#define BM_DCP_CSCSTAT_RSVD0	0x00000002
+#define BM_DCP_CSCSTAT_COMPLETE	0x00000001
+
+#define HW_DCP_CSCOUTBUFPARAM	(0x00000320)
+
+#define BP_DCP_CSCOUTBUFPARAM_RSVD1	24
+#define BM_DCP_CSCOUTBUFPARAM_RSVD1	0xFF000000
+#define BF_DCP_CSCOUTBUFPARAM_RSVD1(v) \
+		(((v) << 24) & BM_DCP_CSCOUTBUFPARAM_RSVD1)
+#define BP_DCP_CSCOUTBUFPARAM_FIELD_SIZE	12
+#define BM_DCP_CSCOUTBUFPARAM_FIELD_SIZE	0x00FFF000
+#define BF_DCP_CSCOUTBUFPARAM_FIELD_SIZE(v)  \
+		(((v) << 12) & BM_DCP_CSCOUTBUFPARAM_FIELD_SIZE)
+#define BP_DCP_CSCOUTBUFPARAM_LINE_SIZE	0
+#define BM_DCP_CSCOUTBUFPARAM_LINE_SIZE	0x00000FFF
+#define BF_DCP_CSCOUTBUFPARAM_LINE_SIZE(v)  \
+		(((v) << 0) & BM_DCP_CSCOUTBUFPARAM_LINE_SIZE)
+
+#define HW_DCP_CSCINBUFPARAM	(0x00000330)
+
+#define BP_DCP_CSCINBUFPARAM_RSVD1	12
+#define BM_DCP_CSCINBUFPARAM_RSVD1	0xFFFFF000
+#define BF_DCP_CSCINBUFPARAM_RSVD1(v) \
+		(((v) << 12) & BM_DCP_CSCINBUFPARAM_RSVD1)
+#define BP_DCP_CSCINBUFPARAM_LINE_SIZE	0
+#define BM_DCP_CSCINBUFPARAM_LINE_SIZE	0x00000FFF
+#define BF_DCP_CSCINBUFPARAM_LINE_SIZE(v)  \
+		(((v) << 0) & BM_DCP_CSCINBUFPARAM_LINE_SIZE)
+
+#define HW_DCP_CSCRGB	(0x00000340)
+
+#define BP_DCP_CSCRGB_ADDR	0
+#define BM_DCP_CSCRGB_ADDR	0xFFFFFFFF
+#define BF_DCP_CSCRGB_ADDR(v)	(v)
+
+#define HW_DCP_CSCLUMA	(0x00000350)
+
+#define BP_DCP_CSCLUMA_ADDR	0
+#define BM_DCP_CSCLUMA_ADDR	0xFFFFFFFF
+#define BF_DCP_CSCLUMA_ADDR(v)	(v)
+
+#define HW_DCP_CSCCHROMAU	(0x00000360)
+
+#define BP_DCP_CSCCHROMAU_ADDR	0
+#define BM_DCP_CSCCHROMAU_ADDR	0xFFFFFFFF
+#define BF_DCP_CSCCHROMAU_ADDR(v)	(v)
+
+#define HW_DCP_CSCCHROMAV	(0x00000370)
+
+#define BP_DCP_CSCCHROMAV_ADDR	0
+#define BM_DCP_CSCCHROMAV_ADDR	0xFFFFFFFF
+#define BF_DCP_CSCCHROMAV_ADDR(v)	(v)
+
+#define HW_DCP_CSCCOEFF0	(0x00000380)
+
+#define BP_DCP_CSCCOEFF0_RSVD1	26
+#define BM_DCP_CSCCOEFF0_RSVD1	0xFC000000
+#define BF_DCP_CSCCOEFF0_RSVD1(v) \
+		(((v) << 26) & BM_DCP_CSCCOEFF0_RSVD1)
+#define BP_DCP_CSCCOEFF0_C0	16
+#define BM_DCP_CSCCOEFF0_C0	0x03FF0000
+#define BF_DCP_CSCCOEFF0_C0(v)  \
+		(((v) << 16) & BM_DCP_CSCCOEFF0_C0)
+#define BP_DCP_CSCCOEFF0_UV_OFFSET	8
+#define BM_DCP_CSCCOEFF0_UV_OFFSET	0x0000FF00
+#define BF_DCP_CSCCOEFF0_UV_OFFSET(v)  \
+		(((v) << 8) & BM_DCP_CSCCOEFF0_UV_OFFSET)
+#define BP_DCP_CSCCOEFF0_Y_OFFSET	0
+#define BM_DCP_CSCCOEFF0_Y_OFFSET	0x000000FF
+#define BF_DCP_CSCCOEFF0_Y_OFFSET(v)  \
+		(((v) << 0) & BM_DCP_CSCCOEFF0_Y_OFFSET)
+
+#define HW_DCP_CSCCOEFF1	(0x00000390)
+
+#define BP_DCP_CSCCOEFF1_RSVD1	26
+#define BM_DCP_CSCCOEFF1_RSVD1	0xFC000000
+#define BF_DCP_CSCCOEFF1_RSVD1(v) \
+		(((v) << 26) & BM_DCP_CSCCOEFF1_RSVD1)
+#define BP_DCP_CSCCOEFF1_C1	16
+#define BM_DCP_CSCCOEFF1_C1	0x03FF0000
+#define BF_DCP_CSCCOEFF1_C1(v)  \
+		(((v) << 16) & BM_DCP_CSCCOEFF1_C1)
+#define BP_DCP_CSCCOEFF1_RSVD0	10
+#define BM_DCP_CSCCOEFF1_RSVD0	0x0000FC00
+#define BF_DCP_CSCCOEFF1_RSVD0(v)  \
+		(((v) << 10) & BM_DCP_CSCCOEFF1_RSVD0)
+#define BP_DCP_CSCCOEFF1_C4	0
+#define BM_DCP_CSCCOEFF1_C4	0x000003FF
+#define BF_DCP_CSCCOEFF1_C4(v)  \
+		(((v) << 0) & BM_DCP_CSCCOEFF1_C4)
+
+#define HW_DCP_CSCCOEFF2	(0x000003a0)
+
+#define BP_DCP_CSCCOEFF2_RSVD1	26
+#define BM_DCP_CSCCOEFF2_RSVD1	0xFC000000
+#define BF_DCP_CSCCOEFF2_RSVD1(v) \
+		(((v) << 26) & BM_DCP_CSCCOEFF2_RSVD1)
+#define BP_DCP_CSCCOEFF2_C2	16
+#define BM_DCP_CSCCOEFF2_C2	0x03FF0000
+#define BF_DCP_CSCCOEFF2_C2(v)  \
+		(((v) << 16) & BM_DCP_CSCCOEFF2_C2)
+#define BP_DCP_CSCCOEFF2_RSVD0	10
+#define BM_DCP_CSCCOEFF2_RSVD0	0x0000FC00
+#define BF_DCP_CSCCOEFF2_RSVD0(v)  \
+		(((v) << 10) & BM_DCP_CSCCOEFF2_RSVD0)
+#define BP_DCP_CSCCOEFF2_C3	0
+#define BM_DCP_CSCCOEFF2_C3	0x000003FF
+#define BF_DCP_CSCCOEFF2_C3(v)  \
+		(((v) << 0) & BM_DCP_CSCCOEFF2_C3)
+
+#define HW_DCP_CSCCLIP	(0x000003d0)
+
+#define BP_DCP_CSCCLIP_RSVD1	24
+#define BM_DCP_CSCCLIP_RSVD1	0xFF000000
+#define BF_DCP_CSCCLIP_RSVD1(v) \
+		(((v) << 24) & BM_DCP_CSCCLIP_RSVD1)
+#define BP_DCP_CSCCLIP_HEIGHT	12
+#define BM_DCP_CSCCLIP_HEIGHT	0x00FFF000
+#define BF_DCP_CSCCLIP_HEIGHT(v)  \
+		(((v) << 12) & BM_DCP_CSCCLIP_HEIGHT)
+#define BP_DCP_CSCCLIP_WIDTH	0
+#define BM_DCP_CSCCLIP_WIDTH	0x00000FFF
+#define BF_DCP_CSCCLIP_WIDTH(v)  \
+		(((v) << 0) & BM_DCP_CSCCLIP_WIDTH)
+
+#define HW_DCP_CSCXSCALE	(0x000003e0)
+
+#define BP_DCP_CSCXSCALE_RSVD1	26
+#define BM_DCP_CSCXSCALE_RSVD1	0xFC000000
+#define BF_DCP_CSCXSCALE_RSVD1(v) \
+		(((v) << 26) & BM_DCP_CSCXSCALE_RSVD1)
+#define BP_DCP_CSCXSCALE_INT	24
+#define BM_DCP_CSCXSCALE_INT	0x03000000
+#define BF_DCP_CSCXSCALE_INT(v)  \
+		(((v) << 24) & BM_DCP_CSCXSCALE_INT)
+#define BP_DCP_CSCXSCALE_FRAC	12
+#define BM_DCP_CSCXSCALE_FRAC	0x00FFF000
+#define BF_DCP_CSCXSCALE_FRAC(v)  \
+		(((v) << 12) & BM_DCP_CSCXSCALE_FRAC)
+#define BP_DCP_CSCXSCALE_WIDTH	0
+#define BM_DCP_CSCXSCALE_WIDTH	0x00000FFF
+#define BF_DCP_CSCXSCALE_WIDTH(v)  \
+		(((v) << 0) & BM_DCP_CSCXSCALE_WIDTH)
+
+#define HW_DCP_CSCYSCALE	(0x000003f0)
+
+#define BP_DCP_CSCYSCALE_RSVD1	26
+#define BM_DCP_CSCYSCALE_RSVD1	0xFC000000
+#define BF_DCP_CSCYSCALE_RSVD1(v) \
+		(((v) << 26) & BM_DCP_CSCYSCALE_RSVD1)
+#define BP_DCP_CSCYSCALE_INT	24
+#define BM_DCP_CSCYSCALE_INT	0x03000000
+#define BF_DCP_CSCYSCALE_INT(v)  \
+		(((v) << 24) & BM_DCP_CSCYSCALE_INT)
+#define BP_DCP_CSCYSCALE_FRAC	12
+#define BM_DCP_CSCYSCALE_FRAC	0x00FFF000
+#define BF_DCP_CSCYSCALE_FRAC(v)  \
+		(((v) << 12) & BM_DCP_CSCYSCALE_FRAC)
+#define BP_DCP_CSCYSCALE_HEIGHT	0
+#define BM_DCP_CSCYSCALE_HEIGHT	0x00000FFF
+#define BF_DCP_CSCYSCALE_HEIGHT(v)  \
+		(((v) << 0) & BM_DCP_CSCYSCALE_HEIGHT)
+
+#define HW_DCP_DBGSELECT	(0x00000400)
+
+#define BP_DCP_DBGSELECT_RSVD	8
+#define BM_DCP_DBGSELECT_RSVD	0xFFFFFF00
+#define BF_DCP_DBGSELECT_RSVD(v) \
+		(((v) << 8) & BM_DCP_DBGSELECT_RSVD)
+#define BP_DCP_DBGSELECT_INDEX	0
+#define BM_DCP_DBGSELECT_INDEX	0x000000FF
+#define BF_DCP_DBGSELECT_INDEX(v)  \
+		(((v) << 0) & BM_DCP_DBGSELECT_INDEX)
+#define BV_DCP_DBGSELECT_INDEX__CONTROL 0x01
+#define BV_DCP_DBGSELECT_INDEX__OTPKEY0 0x10
+#define BV_DCP_DBGSELECT_INDEX__OTPKEY1 0x11
+#define BV_DCP_DBGSELECT_INDEX__OTPKEY2 0x12
+#define BV_DCP_DBGSELECT_INDEX__OTPKEY3 0x13
+
+#define HW_DCP_DBGDATA	(0x00000410)
+
+#define BP_DCP_DBGDATA_DATA	0
+#define BM_DCP_DBGDATA_DATA	0xFFFFFFFF
+#define BF_DCP_DBGDATA_DATA(v)	(v)
+
+#define HW_DCP_PAGETABLE	(0x00000420)
+
+#define BP_DCP_PAGETABLE_BASE	2
+#define BM_DCP_PAGETABLE_BASE	0xFFFFFFFC
+#define BF_DCP_PAGETABLE_BASE(v) \
+		(((v) << 2) & BM_DCP_PAGETABLE_BASE)
+#define BM_DCP_PAGETABLE_FLUSH	0x00000002
+#define BM_DCP_PAGETABLE_ENABLE	0x00000001
+
+#define HW_DCP_VERSION	(0x00000430)
+
+#define BP_DCP_VERSION_MAJOR	24
+#define BM_DCP_VERSION_MAJOR	0xFF000000
+#define BF_DCP_VERSION_MAJOR(v) \
+		(((v) << 24) & BM_DCP_VERSION_MAJOR)
+#define BP_DCP_VERSION_MINOR	16
+#define BM_DCP_VERSION_MINOR	0x00FF0000
+#define BF_DCP_VERSION_MINOR(v)  \
+		(((v) << 16) & BM_DCP_VERSION_MINOR)
+#define BP_DCP_VERSION_STEP	0
+#define BM_DCP_VERSION_STEP	0x0000FFFF
+#define BF_DCP_VERSION_STEP(v)  \
+		(((v) << 0) & BM_DCP_VERSION_STEP)
+
+#endif
diff --git a/include/linux/fsl/fsl-dcp_bootstream_ioctl.h b/include/linux/fsl/fsl-dcp_bootstream_ioctl.h
new file mode 100644
index 0000000..2859a8d
--- /dev/null
+++ b/include/linux/fsl/fsl-dcp_bootstream_ioctl.h
@@ -0,0 +1,32 @@
+/*
+ * Freescale DCP driver for bootstream update. Only handles the OTP KEY
+ * case and can only encrypt/decrypt.
+ *
+ * Author: Pantelis Antoniou <pantelis at embeddedalley.com>
+ *
+ * Copyright (C) 2008-2010 Freescale Semiconductor, Inc. All Rights Reserved.
+ * Copyright 2008 Embedded Alley Solutions, Inc All Rights Reserved.
+ */
+
+/*
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+#ifndef DCP_BOOTSTREAM_IOCTL_H
+#define DCP_BOOTSTREAM_IOCTL_H
+
+/* remember to have included the proper _IO definition
+ * file before hand.
+ * For user space it's <sys/ioctl.h>
+ */
+
+#define DBS_IOCTL_BASE   'd'
+
+#define DBS_ENC _IOW(DBS_IOCTL_BASE, 0x00, uint8_t[16])
+#define DBS_DEC _IOW(DBS_IOCTL_BASE, 0x01, uint8_t[16])
+
+#endif
-- 
1.7.9.5



From catalin.marinas at arm.com  Tue Apr 23 06:03:32 2013
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Tue, 23 Apr 2013 11:03:32 +0100
Subject: ARM: 7684/1: errata: Workaround for Cortex-A15 erratum 798181
 (TLBI/DSB operations)
In-Reply-To: <alpine.LFD.2.03.1304221641340.17375@syhkavp.arg>
References: <alpine.LFD.2.03.1304221641340.17375@syhkavp.arg>
Message-ID: <20130423100332.GA23407@arm.com>

On Mon, Apr 22, 2013 at 10:29:32PM +0100, Nicolas Pitre wrote:
> I notice that commit 93dc68876b60 ( "ARM: 7684/1: errata: Workaround for 
> Cortex-A15 erratum 798181 (TLBI/DSB operations)") is in mainline, but it 
> is causing a flood of warnings with CONFIG_DEBUG_PREEMPT active, making 
> the system unusable. Unfortunately, I failed to find it in the list 
> archives, so I couldn't reply to the original patch.

It wasn't on the list (and I'll reply in private why).

> The kernel spits out this on every fork():
> 
> BUG: using smp_processor_id() in preemptible [00000000] code: bash/1419
> caller is broadcast_tlb_mm_a15_erratum+0x94/0xfc
> [<c0014640>] (unwind_backtrace+0x0/0xf8) from [<c02074ec>] (debug_smp_processor_id+0xc4/0xe8)
> [<c02074ec>] (debug_smp_processor_id+0xc4/0xe8) from [<c0013a3c>] (broadcast_tlb_mm_a15_erratum+0x94/0xfc)
> [<c0013a3c>] (broadcast_tlb_mm_a15_erratum+0x94/0xfc) from [<c0020f28>] (dup_mm+0x30c/0x41c)
> [<c0020f28>] (dup_mm+0x30c/0x41c) from [<c00217a4>] (copy_process.part.56+0x724/0xe20)
> [<c00217a4>] (copy_process.part.56+0x724/0xe20) from [<c0021f54>] (do_fork+0x90/0x320)
> [<c0021f54>] (do_fork+0x90/0x320) from [<c000e240>] (ret_fast_syscall+0x0/0x30)

So it needs preemption disabled, see below.

I'll double-check with the hardware guys whether the dummy TLBI can
happen on any CPU (if we get preempted), otherwise I'll have to disable
the preemption around both the local_flush_tlb_*() and broadcast_tlb_*()
functions.

Thanks,

Catalin

----------------------8<----------------------------------------

>From 8655f0d38ae4057dcca8e1f6b4878d1c87604f90 Mon Sep 17 00:00:00 2001
From: Catalin Marinas <catalin.marinas at arm.com>
Date: Tue, 23 Apr 2013 10:05:06 +0100
Subject: [PATCH] arm: Disable preemption in broadcast_tlb*_a17_erratum()

Commit 93dc688 (ARM: 7684/1: errata: Workaround for Cortex-A15 erratum
798181 (TLBI/DSB operations)) introduces calls to smp_processor_id() and
smp_call_function_many() with preemption enabled. This patch disables
preemption and also optimises the smp_processor_id() call in
broadcast_tlb_mm_a15_erratum(). The broadcast_tlb_a15_erratum() function
is changed to use smp_call_function() which disables preemption.

Signed-off-by: Catalin Marinas <catalin.marinas at arm.com>
Reported-by: Geoff Levand <geoff at infradead.org>
Reported-by: Nicolas Pitre <nicolas.pitre at linaro.org>
---
 arch/arm/kernel/smp_tlb.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/arch/arm/kernel/smp_tlb.c b/arch/arm/kernel/smp_tlb.c
index e82e1d2..9a52a07 100644
--- a/arch/arm/kernel/smp_tlb.c
+++ b/arch/arm/kernel/smp_tlb.c
@@ -98,21 +98,21 @@ static void broadcast_tlb_a15_erratum(void)
 		return;
 
 	dummy_flush_tlb_a15_erratum();
-	smp_call_function_many(cpu_online_mask, ipi_flush_tlb_a15_erratum,
-			       NULL, 1);
+	smp_call_function(ipi_flush_tlb_a15_erratum, NULL, 1);
 }
 
 static void broadcast_tlb_mm_a15_erratum(struct mm_struct *mm)
 {
-	int cpu;
+	int cpu, this_cpu;
 	cpumask_t mask = { CPU_BITS_NONE };
 
 	if (!erratum_a15_798181())
 		return;
 
 	dummy_flush_tlb_a15_erratum();
+	this_cpu = get_cpu();
 	for_each_online_cpu(cpu) {
-		if (cpu == smp_processor_id())
+		if (cpu == this_cpu)
 			continue;
 		/*
 		 * We only need to send an IPI if the other CPUs are running
@@ -127,6 +127,7 @@ static void broadcast_tlb_mm_a15_erratum(struct mm_struct *mm)
 			cpumask_set_cpu(cpu, &mask);
 	}
 	smp_call_function_many(&mask, ipi_flush_tlb_a15_erratum, NULL, 1);
+	put_cpu();
 }
 
 void flush_tlb_all(void)


From B35083 at freescale.com  Tue Apr 23 06:09:46 2013
From: B35083 at freescale.com (Lu Jingchang-B35083)
Date: Tue, 23 Apr 2013 10:09:46 +0000
Subject: [PATCH 3/3] pinctrl: add MVF pinctrl driver
In-Reply-To: <20130422145727.GA27475@S2101-09.ap.freescale.net>
References: <1365753432-14247-1-git-send-email-b35083@freescale.com>
 <20130422145727.GA27475@S2101-09.ap.freescale.net>
Message-ID: <B56CDBE15CE27145A4B77D2D24263E851B17D9@039-SN1MPN1-003.039d.mgd.msft.net>

>-----Original Message-----
>From: Shawn Guo [mailto:shawn.guo at linaro.org]
>Sent: Monday, April 22, 2013 10:57 PM
>To: Lu Jingchang-B35083
>Cc: linux-arm-kernel at lists.infradead.org; linus.walleij at linaro.org
>Subject: Re: [PATCH 3/3] pinctrl: add MVF pinctrl driver
>
>On Fri, Apr 12, 2013 at 03:57:12PM +0800, Jingchang Lu wrote:
>> It adds Freescale Vybrid Family pin controller driver to I.MX IOMUXC
>> common driver architecture.
>> The only difference is the MUX and CONF register is the same on MVF
>> platform, so the defined config value including the mux_mode int DTS.
>>
>This make no sense.  We should patch pinctrl-imx driver to support MVF.
>
[Lu Jingchang-B35083] 
i.mx and MVF platform have difference register definition for IOMUXC. On i.mx there are two registers for mux_mode and control value, But on MVF platform there is only one register. I'll try to investigate your new IMX pinctrl framework and try to patch it to support the MVF platform. Thanks.

>> Signed-off-by: Jingchang Lu <b35083 at freescale.com>
>> ---
>>  .../bindings/pinctrl/fsl,mvf-pinctrl.txt           |  825 ++++++++
>>  drivers/pinctrl/Kconfig                            |    8 +
>>  drivers/pinctrl/Makefile                           |    1 +
>>  drivers/pinctrl/pinctrl-mvf.c                      | 2042
>++++++++++++++++++++
>
>We just removed those big arrays of imx_pin_reg from imx pinctrl soc
>drivers.  Please do not bring it back for MVF.
>
[Lu Jingchang-B35083] 
What's the status of your new i.mx pinctrl framework? I found that there are some discussion for that, Are they accepted? Where can I find the latest code so I can use it as the base for MVF platform? Thanks.


>Shawn



From vkale at apm.com  Tue Apr 23 06:25:55 2013
From: vkale at apm.com (Vinayak Kale)
Date: Tue, 23 Apr 2013 15:55:55 +0530
Subject: [PATCH V2 0/4] arm64: Initial patch-set for APM X-Gene SOC family
Message-ID: <1366712759-3431-1-git-send-email-vkale@apm.com>

These are initial patches for APM X-Gene SOC family.
This patch-set is based on soc-armv8-model branch of git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch64.git

Changelog:

-V2:
 * set NR_CPUS in arch/arm64/Kconfig based on selected targets
 * use default defconfig instead of xgene_defconfig
 * added 'apm-' prefix to dts filenames
 * fixed #address-cells in /cpus node in dts file
 * fixed cpu node naming under /cpus node in dts file
 * fixed serial device node name in dts file

-V1: Initial post

Vinayak Kale (4):
  arm64: Add Kconfig option for APM X-Gene SOC family
  arm64: Enable APM X-Gene SOC family in the defconfig
  arm64: Add defines for APM ARMv8 implementation
  arm64: Add initial DTS for APM X-Gene Storm SOC and APM Mustang board

 arch/arm64/Kconfig                  |    7 ++
 arch/arm64/boot/dts/Makefile        |    1 +
 arch/arm64/boot/dts/apm-mustang.dts |   27 ++++++++
 arch/arm64/boot/dts/apm-storm.dtsi  |  116 +++++++++++++++++++++++++++++++++++
 arch/arm64/configs/defconfig        |    4 +
 arch/arm64/include/asm/cputype.h    |    3 +
 6 files changed, 158 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm64/boot/dts/apm-mustang.dts
 create mode 100644 arch/arm64/boot/dts/apm-storm.dtsi

-- 
1.7.4.1



From vkale at apm.com  Tue Apr 23 06:25:56 2013
From: vkale at apm.com (Vinayak Kale)
Date: Tue, 23 Apr 2013 15:55:56 +0530
Subject: [PATCH V2 1/4] arm64: Add Kconfig option for APM X-Gene SOC family
In-Reply-To: <1366712759-3431-1-git-send-email-vkale@apm.com>
References: <1366712759-3431-1-git-send-email-vkale@apm.com>
Message-ID: <1366712759-3431-2-git-send-email-vkale@apm.com>

This patch adds arm64/Kconfig option for APM X-Gene SOC family.

Signed-off-by: Kumar Sankaran <ksankaran at apm.com>
Signed-off-by: Loc Ho <lho at apm.com>
Signed-off-by: Feng Kan <fkan at apm.com>
---
 arch/arm64/Kconfig |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 43b0e9f..16d0198 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -114,6 +114,11 @@ config ARCH_VEXPRESS
 	  This enables support for the ARMv8 software model (Versatile
 	  Express).
 
+config ARCH_XGENE
+	bool "AppliedMicro X-Gene SOC Family"
+	help
+	  This enables support for AppliedMicro X-Gene SOC Family
+
 endmenu
 
 menu "Bus support"
@@ -153,6 +158,8 @@ config NR_CPUS
 	int "Maximum number of CPUs (2-32)"
 	range 2 32
 	depends on SMP
+	# These have to remain sorted largest to smallest
+	default "8" if ARCH_XGENE
 	default "4"
 
 source kernel/Kconfig.preempt
-- 
1.7.4.1



From vkale at apm.com  Tue Apr 23 06:25:57 2013
From: vkale at apm.com (Vinayak Kale)
Date: Tue, 23 Apr 2013 15:55:57 +0530
Subject: [PATCH V2 2/4] arm64: Enable APM X-Gene SOC family in the defconfig
In-Reply-To: <1366712759-3431-1-git-send-email-vkale@apm.com>
References: <1366712759-3431-1-git-send-email-vkale@apm.com>
Message-ID: <1366712759-3431-3-git-send-email-vkale@apm.com>

This patch enables APM X-Gene SOC family in the defconfig. It also enables 8250 serial driver needed by X-Gene SOC family.

Signed-off-by: Kumar Sankaran <ksankaran at apm.com>
Signed-off-by: Loc Ho <lho at apm.com>
Signed-off-by: Feng Kan <fkan at apm.com>
---
 arch/arm64/configs/defconfig |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 09bef29..7dfad0a 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -23,6 +23,7 @@ CONFIG_MODULES=y
 CONFIG_MODULE_UNLOAD=y
 # CONFIG_BLK_DEV_BSG is not set
 # CONFIG_IOSCHED_DEADLINE is not set
+CONFIG_ARCH_XGENE=y
 CONFIG_SMP=y
 CONFIG_PREEMPT_VOLUNTARY=y
 CONFIG_CMDLINE="console=ttyAMA0"
@@ -52,6 +53,9 @@ CONFIG_INPUT_EVDEV=y
 # CONFIG_SERIO_I8042 is not set
 # CONFIG_SERIO_SERPORT is not set
 CONFIG_LEGACY_PTY_COUNT=16
+CONFIG_SERIAL_8250=y
+CONFIG_SERIAL_8250_CONSOLE=y
+CONFIG_SERIAL_OF_PLATFORM=y
 # CONFIG_HW_RANDOM is not set
 # CONFIG_HWMON is not set
 CONFIG_FB=y
-- 
1.7.4.1



From vkale at apm.com  Tue Apr 23 06:25:58 2013
From: vkale at apm.com (Vinayak Kale)
Date: Tue, 23 Apr 2013 15:55:58 +0530
Subject: [PATCH V2 3/4] arm64: Add defines for APM ARMv8 implementation
In-Reply-To: <1366712759-3431-1-git-send-email-vkale@apm.com>
References: <1366712759-3431-1-git-send-email-vkale@apm.com>
Message-ID: <1366712759-3431-4-git-send-email-vkale@apm.com>

This patch adds defines for APM CPU implementer ID and APM CPU part numbers in asm/cputype.h

Signed-off-by: Kumar Sankaran <ksankaran at apm.com>
Signed-off-by: Loc Ho <lho at apm.com>
Signed-off-by: Feng Kan <fkan at apm.com>
---
 arch/arm64/include/asm/cputype.h |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h
index cf27494..5fe138e 100644
--- a/arch/arm64/include/asm/cputype.h
+++ b/arch/arm64/include/asm/cputype.h
@@ -37,11 +37,14 @@
 })
 
 #define ARM_CPU_IMP_ARM		0x41
+#define ARM_CPU_IMP_APM		0x50
 
 #define ARM_CPU_PART_AEM_V8	0xD0F0
 #define ARM_CPU_PART_FOUNDATION	0xD000
 #define ARM_CPU_PART_CORTEX_A57	0xD070
 
+#define APM_CPU_PART_POTENZA	0x0000
+
 #ifndef __ASSEMBLY__
 
 /*
-- 
1.7.4.1



From vkale at apm.com  Tue Apr 23 06:25:59 2013
From: vkale at apm.com (Vinayak Kale)
Date: Tue, 23 Apr 2013 15:55:59 +0530
Subject: [PATCH V2 4/4] arm64: Add initial DTS for APM X-Gene Storm SOC and
 APM Mustang board
In-Reply-To: <1366712759-3431-1-git-send-email-vkale@apm.com>
References: <1366712759-3431-1-git-send-email-vkale@apm.com>
Message-ID: <1366712759-3431-5-git-send-email-vkale@apm.com>

This patch adds initial DTS files required for APM Mustang board.

Signed-off-by: Kumar Sankaran <ksankaran at apm.com>
Signed-off-by: Loc Ho <lho at apm.com>
Signed-off-by: Feng Kan <fkan at apm.com>
---
 arch/arm64/boot/dts/Makefile        |    1 +
 arch/arm64/boot/dts/apm-mustang.dts |   27 ++++++++
 arch/arm64/boot/dts/apm-storm.dtsi  |  116 +++++++++++++++++++++++++++++++++++
 3 files changed, 144 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm64/boot/dts/apm-mustang.dts
 create mode 100644 arch/arm64/boot/dts/apm-storm.dtsi

diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
index 68457e9..c52bdb0 100644
--- a/arch/arm64/boot/dts/Makefile
+++ b/arch/arm64/boot/dts/Makefile
@@ -1,4 +1,5 @@
 dtb-$(CONFIG_ARCH_VEXPRESS) += rtsm_ve-aemv8a.dtb foundation-v8.dtb
+dtb-$(CONFIG_ARCH_XGENE) += apm-mustang.dtb
 
 targets += dtbs
 targets += $(dtb-y)
diff --git a/arch/arm64/boot/dts/apm-mustang.dts b/arch/arm64/boot/dts/apm-mustang.dts
new file mode 100644
index 0000000..625322c
--- /dev/null
+++ b/arch/arm64/boot/dts/apm-mustang.dts
@@ -0,0 +1,27 @@
+/*
+ * dts file for AppliedMicro (APM) Mustang Board
+ *
+ * Copyright (C) 2013, Applied Micro Circuits Corporation
+ *
+ * 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/ "apm-storm.dtsi"
+
+/ {
+	model = "mustang";
+
+	chosen {
+		linux,stdout-path = &serial0;
+	};
+
+	memory {
+		device_type = "memory";
+		reg = < 0x1 0x00000000 0x0 0x80000000 >; /* Updated by bootloader */
+	};
+};
diff --git a/arch/arm64/boot/dts/apm-storm.dtsi b/arch/arm64/boot/dts/apm-storm.dtsi
new file mode 100644
index 0000000..d3f3f5d
--- /dev/null
+++ b/arch/arm64/boot/dts/apm-storm.dtsi
@@ -0,0 +1,116 @@
+/*
+ * dts file for AppliedMicro (APM) X-Gene Storm SOC
+ *
+ * Copyright (C) 2013, Applied Micro Circuits Corporation
+ *
+ * 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.
+ */
+
+/ {
+	compatible = "apm,xgene,storm", "apm,xgene";
+	interrupt-parent = <&gic>;
+	#address-cells = <2>;
+	#size-cells = <2>;
+
+	cpus {
+		#address-cells = <2>;
+		#size-cells = <0>;
+
+		cpu at 000 {
+			device_type = "cpu";
+			compatible = "apm,xgene", "arm,armv8";
+			reg = <0x0 0x000>;
+			enable-method = "spin-table";
+			cpu-release-addr = <0x1 0x0000fff8>;
+		};
+		cpu at 001 {
+			device_type = "cpu";
+			compatible = "apm,xgene", "arm,armv8";
+			reg = <0x0 0x001>;
+			enable-method = "spin-table";
+			cpu-release-addr = <0x1 0x0000fff8>;
+		};
+		cpu at 100 {
+			device_type = "cpu";
+			compatible = "apm,xgene", "arm,armv8";
+			reg = <0x0 0x100>;
+			enable-method = "spin-table";
+			cpu-release-addr = <0x1 0x0000fff8>;
+		};
+		cpu at 101 {
+			device_type = "cpu";
+			compatible = "apm,xgene", "arm,armv8";
+			reg = <0x0 0x101>;
+			enable-method = "spin-table";
+			cpu-release-addr = <0x1 0x0000fff8>;
+		};
+		cpu at 200 {
+			device_type = "cpu";
+			compatible = "apm,xgene", "arm,armv8";
+			reg = <0x0 0x200>;
+			enable-method = "spin-table";
+			cpu-release-addr = <0x1 0x0000fff8>;
+		};
+		cpu at 201 {
+			device_type = "cpu";
+			compatible = "apm,xgene", "arm,armv8";
+			reg = <0x0 0x201>;
+			enable-method = "spin-table";
+			cpu-release-addr = <0x1 0x0000fff8>;
+		};
+		cpu at 300 {
+			device_type = "cpu";
+			compatible = "apm,xgene", "arm,armv8";
+			reg = <0x0 0x300>;
+			enable-method = "spin-table";
+			cpu-release-addr = <0x1 0x0000fff8>;
+		};
+		cpu at 301 {
+			device_type = "cpu";
+			compatible = "apm,xgene", "arm,armv8";
+			reg = <0x0 0x301>;
+			enable-method = "spin-table";
+			cpu-release-addr = <0x1 0x0000fff8>;
+		};
+	};
+
+	gic: interrupt-controller at 78010000 {
+		compatible = "arm,cortex-a15-gic", "arm,cortex-a9-gic";
+		#interrupt-cells = <3>;
+		interrupt-controller;
+		reg = <0x0 0x78010000 0x0 0x1000>,	/* GIC Dist */
+		      <0x0 0x78020000 0x0 0x1000>,	/* GIC CPU */
+		      <0x0 0x78040000 0x0 0x2000>,	/* GIC VCPU Control */
+		      <0x0 0x78060000 0x0 0x2000>;	/* GIC VCPU */
+		interrupts = <1 9 0xf04>;	/* GIC Maintenence IRQ */
+	};
+
+	timer {
+		compatible = "arm,armv8-timer";
+		interrupts = <1 0 0xff01>,	/* Secure Phys IRQ */
+			     <1 13 0xff01>,	/* Non-secure Phys IRQ */
+			     <1 14 0xff01>,	/* Virt IRQ */
+			     <1 15 0xff01>;	/* Hyp IRQ */
+		clock-frequency = <50000000>;
+	};
+
+	soc {
+		compatible = "simple-bus";
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
+
+		serial0: serial at 1c020000 {
+			device_type = "serial";
+			compatible = "ns16550";
+			reg = <0 0x1c020000 0x0 0x1000>;
+			reg-shift = <2>;
+			clock-frequency = <10000000>; /* Updated by bootloader */
+			interrupt-parent = <&gic>;
+			interrupts = <0x0 0x4c 0x4>;
+		};
+	};
+};
-- 
1.7.4.1



From josh.wu at atmel.com  Tue Apr 23 06:29:53 2013
From: josh.wu at atmel.com (Josh Wu)
Date: Tue, 23 Apr 2013 18:29:53 +0800
Subject: [PATCH 0/4] mtd: atmel_nand: enable Nand Flash Controller (NFC)
 support
Message-ID: <1366712997-17639-1-git-send-email-josh.wu@atmel.com>

This patch series enable NFC support for SAMA5 soc. It can send command,
address cycles automaticly. Also when enable NFC sram, NFC will transfer
data to sram. Which can save lots of cpu time.

Josh Wu (4):
  mtd: atmel_nand: replace pmecc enable code with one function.
  mtd: atmel_nand: add Nand Flash Controller (NFC) support
  mtd: atmel_nand: enable Nand Flash Controller (NFC) read data
    via sram
  mtd: atmel_nand: enable Nand Flash Controller (NFC) write via
    sram

 .../devicetree/bindings/mtd/atmel-nand.txt         |    4 +
 drivers/mtd/nand/atmel_nand.c                      |  658 ++++++++++++++++++--
 drivers/mtd/nand/atmel_nand_ecc.h                  |    7 +-
 drivers/mtd/nand/atmel_nand_nfc.h                  |  106 ++++
 4 files changed, 725 insertions(+), 50 deletions(-)
 create mode 100644 drivers/mtd/nand/atmel_nand_nfc.h

-- 
1.7.9.5



From josh.wu at atmel.com  Tue Apr 23 06:29:54 2013
From: josh.wu at atmel.com (Josh Wu)
Date: Tue, 23 Apr 2013 18:29:54 +0800
Subject: [PATCH 1/4] mtd: atmel_nand: replace pmecc enable code with one
 function.
In-Reply-To: <1366712997-17639-1-git-send-email-josh.wu@atmel.com>
References: <1366712997-17639-1-git-send-email-josh.wu@atmel.com>
Message-ID: <1366712997-17639-2-git-send-email-josh.wu@atmel.com>

Signed-off-by: Josh Wu <josh.wu at atmel.com>
---
 drivers/mtd/nand/atmel_nand.c     |   35 ++++++++++++++++++++---------------
 drivers/mtd/nand/atmel_nand_ecc.h |    7 ++++++-
 2 files changed, 26 insertions(+), 16 deletions(-)

diff --git a/drivers/mtd/nand/atmel_nand.c b/drivers/mtd/nand/atmel_nand.c
index ffcbcca..cd9aba2 100644
--- a/drivers/mtd/nand/atmel_nand.c
+++ b/drivers/mtd/nand/atmel_nand.c
@@ -763,6 +763,24 @@ normal_check:
 	return total_err;
 }
 
+static void pmecc_enable(struct atmel_nand_host *host, enum pmecc_op op)
+{
+	u32 val;
+	pmecc_writel(host->ecc, CTRL, PMECC_CTRL_RST);
+	pmecc_writel(host->ecc, CTRL, PMECC_CTRL_DISABLE);
+	val = pmecc_readl_relaxed(host->ecc, CFG);
+
+	if (op == PMECC_READ)
+		pmecc_writel(host->ecc, CFG, (val & ~PMECC_CFG_WRITE_OP)
+			| PMECC_CFG_AUTO_ENABLE);
+	else
+		pmecc_writel(host->ecc, CFG, (val | PMECC_CFG_WRITE_OP)
+			& ~PMECC_CFG_AUTO_ENABLE);
+
+	pmecc_writel(host->ecc, CTRL, PMECC_CTRL_ENABLE);
+	pmecc_writel(host->ecc, CTRL, PMECC_CTRL_DATA);
+}
+
 static int atmel_nand_pmecc_read_page(struct mtd_info *mtd,
 	struct nand_chip *chip, uint8_t *buf, int oob_required, int page)
 {
@@ -774,13 +792,7 @@ static int atmel_nand_pmecc_read_page(struct mtd_info *mtd,
 	unsigned long end_time;
 	int bitflips = 0;
 
-	pmecc_writel(host->ecc, CTRL, PMECC_CTRL_RST);
-	pmecc_writel(host->ecc, CTRL, PMECC_CTRL_DISABLE);
-	pmecc_writel(host->ecc, CFG, (pmecc_readl_relaxed(host->ecc, CFG)
-		& ~PMECC_CFG_WRITE_OP) | PMECC_CFG_AUTO_ENABLE);
-
-	pmecc_writel(host->ecc, CTRL, PMECC_CTRL_ENABLE);
-	pmecc_writel(host->ecc, CTRL, PMECC_CTRL_DATA);
+	pmecc_enable(host, PMECC_READ);
 
 	chip->read_buf(mtd, buf, eccsize);
 	chip->read_buf(mtd, oob, mtd->oobsize);
@@ -813,14 +825,7 @@ static int atmel_nand_pmecc_write_page(struct mtd_info *mtd,
 	int i, j;
 	unsigned long end_time;
 
-	pmecc_writel(host->ecc, CTRL, PMECC_CTRL_RST);
-	pmecc_writel(host->ecc, CTRL, PMECC_CTRL_DISABLE);
-
-	pmecc_writel(host->ecc, CFG, (pmecc_readl_relaxed(host->ecc, CFG) |
-		PMECC_CFG_WRITE_OP) & ~PMECC_CFG_AUTO_ENABLE);
-
-	pmecc_writel(host->ecc, CTRL, PMECC_CTRL_ENABLE);
-	pmecc_writel(host->ecc, CTRL, PMECC_CTRL_DATA);
+	pmecc_enable(host, PMECC_WRITE);
 
 	chip->write_buf(mtd, (u8 *)buf, mtd->writesize);
 
diff --git a/drivers/mtd/nand/atmel_nand_ecc.h b/drivers/mtd/nand/atmel_nand_ecc.h
index 8a1e9a6..b397f77 100644
--- a/drivers/mtd/nand/atmel_nand_ecc.h
+++ b/drivers/mtd/nand/atmel_nand_ecc.h
@@ -3,7 +3,7 @@
  * Based on AT91SAM9260 datasheet revision B.
  *
  * Copyright (C) 2007 Andrew Victor
- * Copyright (C) 2007 - 2012 Atmel Corporation.
+ * Copyright (C) 2007 - 2013 Atmel Corporation.
  *
  * 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
@@ -148,4 +148,9 @@
 /* Time out value for reading PMECC status register */
 #define PMECC_MAX_TIMEOUT_MS			100
 
+enum pmecc_op {
+	PMECC_READ,
+	PMECC_WRITE,
+};
+
 #endif
-- 
1.7.9.5



From josh.wu at atmel.com  Tue Apr 23 06:29:55 2013
From: josh.wu at atmel.com (Josh Wu)
Date: Tue, 23 Apr 2013 18:29:55 +0800
Subject: =?UTF-8?q?=5BPATCH=202/4=5D=20mtd=3A=20atmel=5Fnand=3A=20add=20Nand=20Flash=20Controller=20=28NFC=29=20support?=
In-Reply-To: <1366712997-17639-1-git-send-email-josh.wu@atmel.com>
References: <1366712997-17639-1-git-send-email-josh.wu@atmel.com>
Message-ID: <1366712997-17639-3-git-send-email-josh.wu@atmel.com>

Nand Flash Controller (NFC) can handle automatic transfers, sending the
commands and address cycles to the NAND Flash.

To use NFC in this driver, the user needs to set the address and size of
NFC command registers, NFC registers (embedded in HSMC) and NFC SRAM in dts.
Also user need to set up the HSMC irq, which use to check whether nfc
command is finish or not.

This driver has been tested on SAMA5D3X-EK board with JFFS2, YAFFS,
UBIFS and mtd-utils.

I put the part of the mtd_speedtest result here for your information.
>From the mtd_speedtest, we can see the NFC will reduce the %50 of cpu load
when writing nand flash. No change when reading.
In the meantime, the speed will be slow about %8.

- commands use to test:
    #insmod /mnt/mtd_speedtest.ko dev=2 &
    #top -n 30 -d 1 | grep speedtest

- test result:

Before the patch:
=================================================
mtd_speedtest: MTD device: 2
mtd_speedtest: MTD device size 41943040, eraseblock size 131072, page size 2048, count of eraseblocks 320, pages per eraseblock 64, OOB size 64
  515   495 root     R     1164   0%  93% insmod /mnt/mtd_speedtest.ko dev=2
  515   495 root     R     1164   0%  98% insmod /mnt/mtd_speedtest.ko dev=2
  515   495 root     R     1164   0%  99% insmod /mnt/mtd_speedtest.ko dev=2
mtd_speedtest: eraseblock write speed is 5768 KiB/s
mtd_speedtest: testing eraseblock read speed
  515   495 root     R     1164   0%  92% insmod /mnt/mtd_speedtest.ko dev=2
  515   495 root     R     1164   0%  91% insmod /mnt/mtd_speedtest.ko dev=2
  515   495 root     R     1164   0%  94% insmod /mnt/mtd_speedtest.ko dev=2
mtd_speedtest: eraseblock read speed is 5932 KiB/s
mtd_speedtest: testing page write speed
  515   495 root     R     1164   0%  94% insmod /mnt/mtd_speedtest.ko dev=2
  515   495 root     R     1164   0%  98% insmod /mnt/mtd_speedtest.ko dev=2
  515   495 root     R     1164   0%  98% insmod /mnt/mtd_speedtest.ko dev=2
mtd_speedtest: page write speed is 5770 KiB/s
mtd_speedtest: testing page read speed
  515   495 root     R     1164   0%  91% insmod /mnt/mtd_speedtest.ko dev=2
  515   495 root     R     1164   0%  89% insmod /mnt/mtd_speedtest.ko dev=2
  515   495 root     R     1164   0%  91% insmod /mnt/mtd_speedtest.ko dev=2
mtd_speedtest: page read speed is 5910 KiB/s

After the patch:
=================================================
mtd_speedtest: MTD device: 2
mtd_speedtest: MTD device size 41943040, eraseblock size 131072, page size 2048, count of eraseblocks 320, pages per eraseblock 64, OOB size 64
mtd_speedtest: testing eraseblock write speed
  509   495 root     D     1164   0%  49% insmod /mnt/mtd_speedtest.ko dev=2
  509   495 root     D     1164   0%  50% insmod /mnt/mtd_speedtest.ko dev=2
  509   495 root     D     1164   0%  47% insmod /mnt/mtd_speedtest.ko dev=2
mtd_speedtest: eraseblock write speed is 5370 KiB/s
mtd_speedtest: testing eraseblock read speed
  509   495 root     R     1164   0%  92% insmod /mnt/mtd_speedtest.ko dev=2
  509   495 root     R     1164   0%  91% insmod /mnt/mtd_speedtest.ko dev=2
  509   495 root     R     1164   0%  95% insmod /mnt/mtd_speedtest.ko dev=2
mtd_speedtest: eraseblock read speed is 5715 KiB/s
mtd_speedtest: testing page write speed
  509   495 root     D     1164   0%  48% insmod /mnt/mtd_speedtest.ko dev=2
  509   495 root     D     1164   0%  47% insmod /mnt/mtd_speedtest.ko dev=2
  509   495 root     D     1164   0%  50% insmod /mnt/mtd_speedtest.ko dev=2
mtd_speedtest: page write speed is 5224 KiB/s
mtd_speedtest: testing page read speed
  509   495 root     R     1164   0%  89% insmod /mnt/mtd_speedtest.ko dev=2
  509   495 root     R     1164   0%  94% insmod /mnt/mtd_speedtest.ko dev=2
  509   495 root     R     1164   0%  93% insmod /mnt/mtd_speedtest.ko dev=2
mtd_speedtest: page read speed is 5641 KiB/s

Signed-off-by: Josh Wu <josh.wu at atmel.com>
---
 .../devicetree/bindings/mtd/atmel-nand.txt         |    3 +
 drivers/mtd/nand/atmel_nand.c                      |  383 ++++++++++++++++++--
 drivers/mtd/nand/atmel_nand_nfc.h                  |  106 ++++++
 3 files changed, 464 insertions(+), 28 deletions(-)
 create mode 100644 drivers/mtd/nand/atmel_nand_nfc.h

diff --git a/Documentation/devicetree/bindings/mtd/atmel-nand.txt b/Documentation/devicetree/bindings/mtd/atmel-nand.txt
index d555421..88e3313 100644
--- a/Documentation/devicetree/bindings/mtd/atmel-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/atmel-nand.txt
@@ -6,6 +6,8 @@ Required properties:
 	and hardware ECC controller if available.
 	If the hardware ECC is PMECC, it should contain address and size for
 	PMECC, PMECC Error Location controller and ROM which has lookup tables.
+	If hardware supports Nand Flash Controller, it should contain address and
+	size for NFC command registers, NFC registers and NFC Sram.
 - atmel,nand-addr-offset : offset for the address latch.
 - atmel,nand-cmd-offset : offset for the command latch.
 - #address-cells, #size-cells : Must be present if the device has sub-nodes
@@ -29,6 +31,7 @@ Optional properties:
   sector size 1024.
 - nand-bus-width : 8 or 16 bus width if not present 8
 - nand-on-flash-bbt: boolean to enable on flash bbt option if not present false
+- atmel,has-nfc: boolean to enable Nand Flash Controller(NFC).
 
 Examples:
 nand0: nand at 40000000,0 {
diff --git a/drivers/mtd/nand/atmel_nand.c b/drivers/mtd/nand/atmel_nand.c
index cd9aba2..fc609db 100644
--- a/drivers/mtd/nand/atmel_nand.c
+++ b/drivers/mtd/nand/atmel_nand.c
@@ -18,6 +18,9 @@
  *  Add Programmable Multibit ECC support for various AT91 SoC
  *     ? Copyright 2012 ATMEL, Hong Xu
  *
+ *  Add Nand Flash Controller support for SAMA5 SoC
+ *     ? Copyright 2013 ATMEL, Josh Wu (josh.wu at atmel.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.
@@ -37,9 +40,11 @@
 #include <linux/mtd/nand.h>
 #include <linux/mtd/partitions.h>
 
+#include <linux/delay.h>
 #include <linux/dmaengine.h>
 #include <linux/gpio.h>
 #include <linux/io.h>
+#include <linux/interrupt.h>
 #include <linux/platform_data/atmel.h>
 #include <linux/pinctrl/consumer.h>
 
@@ -58,6 +63,7 @@ module_param(on_flash_bbt, int, 0);
 	__raw_writel((value), add + ATMEL_ECC_##reg)
 
 #include "atmel_nand_ecc.h"	/* Hardware ECC registers */
+#include "atmel_nand_nfc.h"	/* Nand Flash Controller definition */
 
 /* oob layout for large page size
  * bad block info is on bytes 0 and 1
@@ -85,6 +91,13 @@ static struct nand_ecclayout atmel_oobinfo_small = {
 	},
 };
 
+struct atmel_nfc {
+	void __iomem		*base_cmd_regs;
+	void __iomem		*hsmc_regs;
+	void __iomem		*sram_bank0;
+	dma_addr_t		sram_bank0_phys;
+};
+
 struct atmel_nand_host {
 	struct nand_chip	nand_chip;
 	struct mtd_info		mtd;
@@ -93,10 +106,15 @@ struct atmel_nand_host {
 	struct atmel_nand_data	board;
 	struct device		*dev;
 	void __iomem		*ecc;
+	int			irq;
 
 	struct completion	comp;
 	struct dma_chan		*dma_chan;
 
+	bool			has_nfc;
+	struct atmel_nfc	nfc;
+	struct completion	comp_nfc;
+
 	bool			has_pmecc;
 	u8			pmecc_corr_cap;
 	u16			pmecc_sector_size;
@@ -1352,6 +1370,7 @@ static int atmel_of_init_port(struct atmel_nand_host *host,
 	board->det_pin = of_get_gpio(np, 2);
 
 	host->has_pmecc = of_property_read_bool(np, "atmel,has-pmecc");
+	host->has_nfc = of_property_read_bool(np, "atmel,has-nfc");
 
 	if (!(board->ecc_mode == NAND_ECC_HW) || !host->has_pmecc)
 		return 0;	/* Not using PMECC */
@@ -1464,6 +1483,285 @@ static int __init atmel_hw_nand_init_params(struct platform_device *pdev,
 	return 0;
 }
 
+/* SMC interrupt service routine */
+static irqreturn_t hsmc_interrupt(int irq, void *dev_id)
+{
+	struct atmel_nand_host *host = dev_id;
+	u32 status, mask, pending;
+	irqreturn_t ret = IRQ_NONE;
+
+	status = nfc_readl(host->nfc.hsmc_regs, SR);
+	mask = nfc_readl(host->nfc.hsmc_regs, IMR);
+	pending = status & mask;
+
+	if (pending & ATMEL_HSMC_NFC_XFR_DONE) {
+		complete(&host->comp_nfc);
+		nfc_writel(host->nfc.hsmc_regs, IDR, ATMEL_HSMC_NFC_XFR_DONE);
+		ret = IRQ_HANDLED;
+	} else if (pending & ATMEL_HSMC_NFC_RB_EDGE) {
+		complete(&host->comp_nfc);
+		nfc_writel(host->nfc.hsmc_regs, IDR, ATMEL_HSMC_NFC_RB_EDGE);
+		ret = IRQ_HANDLED;
+	} else if (pending & ATMEL_HSMC_NFC_CMD_DONE) {
+		complete(&host->comp_nfc);
+		nfc_writel(host->nfc.hsmc_regs, IDR, ATMEL_HSMC_NFC_CMD_DONE);
+		ret = IRQ_HANDLED;
+	}
+
+	return ret;
+}
+
+/* NFC(Nand Flash Controller) related functions */
+static int nfc_wait_interrupt(struct atmel_nand_host *host, u32 flag)
+{
+	unsigned long timeout;
+	init_completion(&host->comp_nfc);
+
+	/* Enable interrupt that need to wait for */
+	nfc_writel(host->nfc.hsmc_regs, IER, flag);
+
+	timeout = wait_for_completion_timeout(&host->comp_nfc,
+			msecs_to_jiffies(NFC_TIME_OUT_MS));
+	if (timeout)
+		return 0;
+
+	/* Time out to wait for the interrupt */
+	dev_err(host->dev, "Time out to wait for interrupt: 0x%08x\n", flag);
+	return -ETIMEDOUT;
+}
+
+static int nfc_send_command(struct atmel_nand_host *host,
+	unsigned int cmd, unsigned int addr, unsigned char cycle0)
+{
+	unsigned long timeout;
+	dev_dbg(host->dev,
+		"nfc_cmd: 0x%08x, addr1234: 0x%08x, cycle0: 0x%02x\n",
+		cmd, addr, cycle0);
+
+	timeout = jiffies + msecs_to_jiffies(NFC_TIME_OUT_MS);
+	while (nfc_cmd_readl(NFCADDR_CMD_NFCBUSY, host->nfc.base_cmd_regs)
+			& NFCADDR_CMD_NFCBUSY) {
+		if (time_after(jiffies, timeout)) {
+			dev_err(host->dev,
+				"Time out to wait CMD_NFCBUSY ready!\n");
+			break;
+		}
+	}
+	nfc_writel(host->nfc.hsmc_regs, CYCLE0, cycle0);
+	nfc_cmd_addr1234_writel(cmd, addr, host->nfc.base_cmd_regs);
+	return nfc_wait_interrupt(host, ATMEL_HSMC_NFC_CMD_DONE);
+}
+
+static int nfc_device_ready(struct mtd_info *mtd)
+{
+	struct nand_chip *nand_chip = mtd->priv;
+	struct atmel_nand_host *host = nand_chip->priv;
+	if (!nfc_wait_interrupt(host, ATMEL_HSMC_NFC_RB_EDGE))
+		return 1;
+	return 0;
+}
+
+static void nfc_select_chip(struct mtd_info *mtd, int chip)
+{
+	struct nand_chip *nand_chip = mtd->priv;
+	struct atmel_nand_host *host = nand_chip->priv;
+
+	if (chip == -1)
+		nfc_writel(host->nfc.hsmc_regs, CTRL, ATMEL_HSMC_NFC_DISABLE);
+	else
+		nfc_writel(host->nfc.hsmc_regs, CTRL, ATMEL_HSMC_NFC_ENABLE);
+}
+
+static int nfc_init(struct platform_device *pdev, struct mtd_info *mtd)
+{
+	struct nand_chip *nand_chip = mtd->priv;
+	struct atmel_nand_host *host = nand_chip->priv;
+	struct atmel_nfc *nfc = &host->nfc;
+	struct resource *nfc_cmd_regs, *nfc_hsmc_regs, *nfc_sram;
+
+	nfc_cmd_regs = platform_get_resource(pdev, IORESOURCE_MEM, 4);
+	if (!nfc_cmd_regs)
+		return -EINVAL;
+
+	nfc_hsmc_regs = platform_get_resource(pdev, IORESOURCE_MEM, 5);
+	if (!nfc_hsmc_regs)
+		return -EINVAL;
+
+	nfc_sram = platform_get_resource(pdev, IORESOURCE_MEM, 6);
+	if (!nfc_sram)
+		return -EINVAL;
+
+	nfc->base_cmd_regs = devm_ioremap_resource(&pdev->dev, nfc_cmd_regs);
+	if (IS_ERR(nfc->base_cmd_regs))
+		return PTR_ERR(nfc->base_cmd_regs);
+
+	nfc->hsmc_regs = devm_ioremap_resource(&pdev->dev, nfc_hsmc_regs);
+	if (IS_ERR(nfc->hsmc_regs))
+		return PTR_ERR(nfc->hsmc_regs);
+
+	nfc->sram_bank0 = devm_ioremap_resource(&pdev->dev, nfc_sram);
+	if (IS_ERR(nfc->sram_bank0))
+		return PTR_ERR(nfc->sram_bank0);
+
+	nfc->sram_bank0_phys = (dma_addr_t)nfc_sram->start;
+
+	dev_info(host->dev, "Using NFC\n");
+	return 0;
+}
+
+static int nfc_make_addr(struct mtd_info *mtd, int column, int page_addr,
+		unsigned int *addr1234, unsigned int *cycle0)
+{
+	struct nand_chip *chip = mtd->priv;
+
+	int acycle = 0;
+	unsigned char addr_bytes[8];
+	int index = 0, bit_shift;
+
+	BUG_ON(addr1234 == NULL || cycle0 == NULL);
+
+	*cycle0 = 0;
+	*addr1234 = 0;
+
+	if (column != -1) {
+		if (chip->options & NAND_BUSWIDTH_16)
+			column >>= 1;
+		addr_bytes[acycle++] = column & 0xff;
+		if (mtd->writesize > 512)
+			addr_bytes[acycle++] = (column >> 8) & 0xff;
+	}
+
+	if (page_addr != -1) {
+		addr_bytes[acycle++] = page_addr & 0xff;
+		addr_bytes[acycle++] = (page_addr >> 8) & 0xff;
+		if (chip->chipsize > (128 << 20))
+			addr_bytes[acycle++] = (page_addr >> 16) & 0xff;
+	}
+
+	if (acycle > 4)
+		*cycle0 = addr_bytes[index++];
+
+	for (bit_shift = 0; index < acycle; bit_shift += 8)
+		*addr1234 += addr_bytes[index++] << bit_shift;
+
+	return acycle << 19;	/* return acycle in cmd register */
+}
+
+static void nfc_nand_command(struct mtd_info *mtd, unsigned int command,
+				int column, int page_addr)
+{
+	struct nand_chip *chip = mtd->priv;
+	struct atmel_nand_host *host = chip->priv;
+	unsigned long timeout;
+	unsigned int nfc_addr_cmd = 0;
+
+	unsigned int cmd1 = command << 2;
+
+	/* Set default settings: no cmd2, no addr cycle. read from nand */
+	unsigned int cmd2 = 0;
+	unsigned int vcmd2 = 0;
+	int acycle = NFCADDR_CMD_ACYCLE_NONE;
+	int csid = NFCADDR_CMD_CSID_3;
+	int dataen = NFCADDR_CMD_DATADIS;
+	int nfcwr = NFCADDR_CMD_NFCRD;
+	unsigned int addr1234 = 0;
+	unsigned int cycle0 = 0;
+	bool do_addr = true;
+
+	dev_dbg(host->dev, "%s: cmd = 0x%02x, col = 0x%08x, page = 0x%08x\n",
+	     __func__, command, column, page_addr);
+
+	switch (command) {
+	case NAND_CMD_RESET:
+		nfc_addr_cmd = cmd1 | acycle | csid | dataen | nfcwr;
+		nfc_send_command(host, nfc_addr_cmd, addr1234, cycle0);
+		udelay(chip->chip_delay);
+
+		nfc_nand_command(mtd, NAND_CMD_STATUS, -1, -1);
+		timeout = jiffies + msecs_to_jiffies(NFC_TIME_OUT_MS);
+		while (!(chip->read_byte(mtd) & NAND_STATUS_READY)) {
+			if (time_after(jiffies, timeout)) {
+				dev_err(host->dev,
+					"Time out to wait status ready!\n");
+				break;
+			}
+		}
+		return;
+	case NAND_CMD_STATUS:
+		do_addr = false;
+		break;
+	case NAND_CMD_PARAM:
+	case NAND_CMD_READID:
+		do_addr = false;
+		acycle = NFCADDR_CMD_ACYCLE_1;
+		if (column != -1)
+			addr1234 = column;
+		break;
+	case NAND_CMD_RNDOUT:
+		cmd2 = NAND_CMD_RNDOUTSTART << 10;
+		vcmd2 = NFCADDR_CMD_VCMD2;
+		break;
+	case NAND_CMD_READ0:
+	case NAND_CMD_READOOB:
+		if (command == NAND_CMD_READOOB) {
+			column += mtd->writesize;
+			command = NAND_CMD_READ0; /* only READ0 is valid */
+			cmd1 = command << 2;
+		}
+
+		cmd2 = NAND_CMD_READSTART << 10;
+		vcmd2 = NFCADDR_CMD_VCMD2;
+		break;
+	/* For prgramming command, the cmd need set to write enable */
+	case NAND_CMD_PAGEPROG:
+	case NAND_CMD_SEQIN:
+	case NAND_CMD_RNDIN:
+		nfcwr = NFCADDR_CMD_NFCWR;
+		break;
+	default:
+		break;
+	}
+
+	if (do_addr)
+		acycle = nfc_make_addr(mtd, column, page_addr, &addr1234,
+				&cycle0);
+
+	nfc_addr_cmd = cmd1 | cmd2 | vcmd2 | acycle | csid | dataen | nfcwr;
+	nfc_send_command(host, nfc_addr_cmd, addr1234, cycle0);
+
+	/*
+	 * Program and erase have their own busy handlers status, sequential
+	 * in, and deplete1 need no delay.
+	 */
+	switch (command) {
+	case NAND_CMD_CACHEDPROG:
+	case NAND_CMD_PAGEPROG:
+	case NAND_CMD_ERASE1:
+	case NAND_CMD_ERASE2:
+	case NAND_CMD_RNDIN:
+	case NAND_CMD_STATUS:
+	case NAND_CMD_DEPLETE1:
+	case NAND_CMD_RNDOUT:
+	case NAND_CMD_SEQIN:
+	case NAND_CMD_READID:
+		return;
+
+	case NAND_CMD_STATUS_ERROR:
+	case NAND_CMD_STATUS_ERROR0:
+	case NAND_CMD_STATUS_ERROR1:
+	case NAND_CMD_STATUS_ERROR2:
+	case NAND_CMD_STATUS_ERROR3:
+		/* Read error status commands require only a short delay */
+		udelay(chip->chip_delay);
+		return;
+
+	case NAND_CMD_READ0:
+		/* fall through */
+	default:
+		nfc_wait_interrupt(host, ATMEL_HSMC_NFC_RB_EDGE);
+	}
+}
+
 /*
  * Probe for the NAND device.
  */
@@ -1474,7 +1772,7 @@ static int __init atmel_nand_probe(struct platform_device *pdev)
 	struct nand_chip *nand_chip;
 	struct resource *mem;
 	struct mtd_part_parser_data ppdata = {};
-	int res;
+	int res, irq;
 	struct pinctrl *pinctrl;
 
 	mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -1518,7 +1816,6 @@ static int __init atmel_nand_probe(struct platform_device *pdev)
 	/* Set address of NAND IO lines */
 	nand_chip->IO_ADDR_R = host->io_base;
 	nand_chip->IO_ADDR_W = host->io_base;
-	nand_chip->cmd_ctrl = atmel_nand_cmd_ctrl;
 
 	pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
 	if (IS_ERR(pinctrl)) {
@@ -1527,41 +1824,69 @@ static int __init atmel_nand_probe(struct platform_device *pdev)
 		goto err_ecc_ioremap;
 	}
 
-	if (gpio_is_valid(host->board.rdy_pin)) {
-		res = gpio_request(host->board.rdy_pin, "nand_rdy");
-		if (res < 0) {
-			dev_err(&pdev->dev,
-				"can't request rdy gpio %d\n",
-				host->board.rdy_pin);
+	if (host->has_nfc) {
+		res = nfc_init(pdev, mtd);
+		if (res)
+			goto err_ecc_ioremap;
+		nand_chip->select_chip = nfc_select_chip;
+		nand_chip->dev_ready = nfc_device_ready;
+		nand_chip->cmdfunc = nfc_nand_command;
+
+		/* Initialize the interrupt for NFC */
+		irq = platform_get_irq(pdev, 0);
+		if (irq < 0) {
+			dev_err(host->dev, "Cannot get HSMC irq!\n");
 			goto err_ecc_ioremap;
 		}
 
-		res = gpio_direction_input(host->board.rdy_pin);
-		if (res < 0) {
-			dev_err(&pdev->dev,
-				"can't request input direction rdy gpio %d\n",
-				host->board.rdy_pin);
+		res = request_irq(irq, hsmc_interrupt, 0, "hsmc", host);
+		if (res) {
+			dev_err(&pdev->dev, "Unable to request HSMC irq %d\n",
+				irq);
 			goto err_ecc_ioremap;
 		}
 
-		nand_chip->dev_ready = atmel_nand_device_ready;
-	}
+		host->irq = irq;
+	} else {
+		nand_chip->cmd_ctrl = atmel_nand_cmd_ctrl;
+
+		if (gpio_is_valid(host->board.rdy_pin)) {
+			res = gpio_request(host->board.rdy_pin, "nand_rdy");
+			if (res < 0) {
+				dev_err(&pdev->dev,
+					"can't request rdy gpio %d\n",
+					host->board.rdy_pin);
+				goto err_ecc_ioremap;
+			}
 
-	if (gpio_is_valid(host->board.enable_pin)) {
-		res = gpio_request(host->board.enable_pin, "nand_enable");
-		if (res < 0) {
-			dev_err(&pdev->dev,
-				"can't request enable gpio %d\n",
-				host->board.enable_pin);
-			goto err_ecc_ioremap;
+			res = gpio_direction_input(host->board.rdy_pin);
+			if (res < 0) {
+				dev_err(&pdev->dev,
+					"can't request input direction rdy gpio %d\n",
+					host->board.rdy_pin);
+				goto err_ecc_ioremap;
+			}
+
+			nand_chip->dev_ready = atmel_nand_device_ready;
 		}
 
-		res = gpio_direction_output(host->board.enable_pin, 1);
-		if (res < 0) {
-			dev_err(&pdev->dev,
-				"can't request output direction enable gpio %d\n",
-				host->board.enable_pin);
-			goto err_ecc_ioremap;
+		if (gpio_is_valid(host->board.enable_pin)) {
+			res = gpio_request(host->board.enable_pin,
+				"nand_enable");
+			if (res < 0) {
+				dev_err(&pdev->dev,
+					"can't request enable gpio %d\n",
+					host->board.enable_pin);
+				goto err_ecc_ioremap;
+			}
+
+			res = gpio_direction_output(host->board.enable_pin, 1);
+			if (res < 0) {
+				dev_err(&pdev->dev,
+					"can't request output direction enable gpio %d\n",
+					host->board.enable_pin);
+				goto err_ecc_ioremap;
+			}
 		}
 	}
 
@@ -1677,6 +2002,8 @@ err_ecc_ioremap:
 	iounmap(host->io_base);
 err_nand_ioremap:
 	kfree(host);
+	if (host->irq)
+		free_irq(host->irq, host);
 	return res;
 }
 
diff --git a/drivers/mtd/nand/atmel_nand_nfc.h b/drivers/mtd/nand/atmel_nand_nfc.h
new file mode 100644
index 0000000..ca124de
--- /dev/null
+++ b/drivers/mtd/nand/atmel_nand_nfc.h
@@ -0,0 +1,106 @@
+/*
+ * Atmel Nand Flash Controller (NFC) - System peripherals regsters.
+ * Based on SAMA5D3 datasheet.
+ *
+ * ? Copyright 2013 Atmel Corporation.
+ *
+ * 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.
+ */
+
+#ifndef ATMEL_NAND_NFC_H
+#define ATMEL_NAND_NFC_H
+
+/*
+ * HSMC NFC registers
+ */
+#define ATMEL_HSMC_NFC_CFG		0x00	/* NFC Configuration Register */
+#define		ATMEL_HSMC_PAGESIZE_512		(0)
+#define		ATMEL_HSMC_PAGESIZE_1024	(1)
+#define		ATMEL_HSMC_PAGESIZE_2048	(2)
+#define		ATMEL_HSMC_PAGESIZE_4096	(3)
+#define		ATMEL_HSMC_PAGESIZE_8192	(4)
+#define		ATMEL_HSMC_WSPARE		(1 << 8)
+#define		ATMEL_HSMC_RSPARE		(1 << 9)
+#define		ATMEL_HSMC_EDGE_CTRL_RISING	(0 << 12)
+#define		ATMEL_HSMC_EDGE_CTRL_FALLING	(1 << 12)
+#define		ATMEL_HSMC_RBEDGE		(1 << 13)
+#define		ATMEL_HSMC_NFC_DTOCYC		(0xf << 16)
+#define		ATMEL_HSMC_NFC_DTOMUL		(0x7 << 20)
+#define		ATMEL_HSMC_NFC_SPARESIZE	(0x7f << 24)
+
+#define ATMEL_HSMC_NFC_CTRL		0x04	/* NFC Control Register */
+#define		ATMEL_HSMC_NFC_ENABLE		(1 << 0)
+#define		ATMEL_HSMC_NFC_DISABLE		(1 << 1)
+
+#define ATMEL_HSMC_NFC_SR		0x08	/* NFC Status Register */
+#define		ATMEL_HSMC_NFC_STATUS		(1 << 0)
+#define		ATMEL_HSMC_NFC_RB_RISE		(1 << 4)
+#define		ATMEL_HSMC_NFC_RB_FALL		(1 << 5)
+#define		ATMEL_HSMC_NFC_BUSY		(1 << 8)
+#define		ATMEL_HSMC_NFC_WR		(1 << 11)
+#define		ATMEL_HSMC_NFC_CSID		(7 << 12)
+#define		ATMEL_HSMC_NFC_XFR_DONE		(1 << 16)
+#define		ATMEL_HSMC_NFC_CMD_DONE		(1 << 17)
+#define		ATMEL_HSMC_NFC_DTOE		(1 << 20)
+#define		ATMEL_HSMC_NFC_UNDEF		(1 << 21)
+#define		ATMEL_HSMC_NFC_AWB		(1 << 22)
+#define		ATMEL_HSMC_NFC_ASE		(1 << 23)
+#define		ATMEL_HSMC_NFC_RB_EDGE		(1 << 24)
+
+#define ATMEL_HSMC_NFC_IER		0x0c
+#define ATMEL_HSMC_NFC_IDR		0x10
+#define ATMEL_HSMC_NFC_IMR		0x14
+#define ATMEL_HSMC_NFC_CYCLE0		0x18	/* NFC Address Cycle Zero */
+#define		ATMEL_HSMC_NFC_ADDR_CYCLE0	(0xff)
+
+#define ATMEL_HSMC_NFC_BANK		0x1c	/* NFC Bank Register */
+#define		ATMEL_HSMC_NFC_BANK0	(0 << 0)
+#define		ATMEL_HSMC_NFC_BANK1	(1 << 0)
+#define		NFC_SRAM_BANK_OFFSET	(0x1200)
+
+#define nfc_writel(addr, reg, value) \
+	writel((value), (addr) + ATMEL_HSMC_NFC_##reg)
+
+#define nfc_readl(addr, reg) \
+	readl_relaxed((addr) + ATMEL_HSMC_NFC_##reg)
+
+/*
+ * NFC Address Command definitions
+ */
+#define NFCADDR_CMD_CMD1	(0xff << 2)	/* Command for Cycle 1 */
+#define NFCADDR_CMD_CMD2	(0xff << 10)	/* Command for Cycle 2 */
+#define NFCADDR_CMD_VCMD2	(0x1 << 18)	/* Valid Cycle 2 Command */
+#define NFCADDR_CMD_ACYCLE	(0x7 << 19)	/* Number of Address required */
+#define   NFCADDR_CMD_ACYCLE_NONE	(0x0 << 19)
+#define   NFCADDR_CMD_ACYCLE_1		(0x1 << 19)
+#define   NFCADDR_CMD_ACYCLE_2		(0x2 << 19)
+#define   NFCADDR_CMD_ACYCLE_3		(0x3 << 19)
+#define   NFCADDR_CMD_ACYCLE_4		(0x4 << 19)
+#define   NFCADDR_CMD_ACYCLE_5		(0x5 << 19)
+#define NFCADDR_CMD_CSID	(0x7 << 22)	/* Chip Select Identifier */
+#define   NFCADDR_CMD_CSID_0		(0x0 << 22)
+#define   NFCADDR_CMD_CSID_1		(0x1 << 22)
+#define   NFCADDR_CMD_CSID_2		(0x2 << 22)
+#define   NFCADDR_CMD_CSID_3		(0x3 << 22)
+#define   NFCADDR_CMD_CSID_4		(0x4 << 22)
+#define   NFCADDR_CMD_CSID_5		(0x5 << 22)
+#define   NFCADDR_CMD_CSID_6		(0x6 << 22)
+#define   NFCADDR_CMD_CSID_7		(0x7 << 22)
+#define NFCADDR_CMD_DATAEN	(0x1 << 25)	/* Data Transfer Enable */
+#define NFCADDR_CMD_DATADIS	(0x0 << 25)	/* Data Transfer Disable */
+#define NFCADDR_CMD_NFCRD	(0x0 << 26)	/* NFC Read Enable */
+#define NFCADDR_CMD_NFCWR	(0x1 << 26)	/* NFC Write Enable */
+#define NFCADDR_CMD_NFCBUSY	(0x1 << 27)	/* NFC Busy */
+
+#define nfc_cmd_addr1234_writel(cmd, addr1234, nfc_base) \
+	writel((addr1234), (cmd) + nfc_base)
+
+#define nfc_cmd_readl(bitstatus, nfc_base) \
+	readl_relaxed((bitstatus) + nfc_base)
+
+#define NFC_TIME_OUT_MS		100
+
+#endif
-- 
1.7.9.5



From josh.wu at atmel.com  Tue Apr 23 06:29:56 2013
From: josh.wu at atmel.com (Josh Wu)
Date: Tue, 23 Apr 2013 18:29:56 +0800
Subject: [PATCH 3/4] mtd: atmel_nand: enable Nand Flash Controller (NFC) read
 data via sram
In-Reply-To: <1366712997-17639-1-git-send-email-josh.wu@atmel.com>
References: <1366712997-17639-1-git-send-email-josh.wu@atmel.com>
Message-ID: <1366712997-17639-4-git-send-email-josh.wu@atmel.com>

NFC has embedded sram which can use to transfer data. This patch enable reading
nand flash via NFC SRAM. It will minimize the CPU overhead.

This driver has been tested on SAMA5D3X-EK with JFFS2, YAFFS2, UBIFS and
mtd-utils.

Here puts the part of mtd_speedtest (read test) result as following:
Compare with non-NFC mtd_speedtest result, reading will reduce %45 cpu load
with increase %80 speed.

- commands use to test:
  # insmod /mnt/mtd_speedtest.ko dev=2 &
  # top -n 30 -d 1 | grep speedtest

- test result:
=================================================
mtd_speedtest: MTD device: 2
mtd_speedtest: MTD device size 41943040, eraseblock size 131072, page size 2048, count of eraseblocks 320, pages per eraseblock 64, OOB size 64
mtd_speedtest: testing eraseblock read speed
  509   495 root     D     1164   0%  28% insmod /mnt/mtd_speedtest.ko dev=2
  509   495 root     D     1164   0%  25% insmod /mnt/mtd_speedtest.ko dev=2
  509   495 root     D     1164   0%  26% insmod /mnt/mtd_speedtest.ko dev=2
mtd_speedtest: eraseblock read speed is 9403 KiB/s
mtd_speedtest: testing page read speed
  509   495 root     R     1164   0%  31% insmod /mnt/mtd_speedtest.ko dev=2
  509   495 root     D     1164   0%  57% insmod /mnt/mtd_speedtest.ko dev=2
  509   495 root     D     1164   0%  53% insmod /mnt/mtd_speedtest.ko dev=2
  509   495 root     D     1164   0%  71% insmod /mnt/mtd_speedtest.ko dev=2
mtd_speedtest: page read speed is 9258 KiB/s

Signed-off-by: Josh Wu <josh.wu at atmel.com>
---
 .../devicetree/bindings/mtd/atmel-nand.txt         |    1 +
 drivers/mtd/nand/atmel_nand.c                      |  154 +++++++++++++++++++-
 2 files changed, 151 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/mtd/atmel-nand.txt b/Documentation/devicetree/bindings/mtd/atmel-nand.txt
index 88e3313..40bf3fd 100644
--- a/Documentation/devicetree/bindings/mtd/atmel-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/atmel-nand.txt
@@ -32,6 +32,7 @@ Optional properties:
 - nand-bus-width : 8 or 16 bus width if not present 8
 - nand-on-flash-bbt: boolean to enable on flash bbt option if not present false
 - atmel,has-nfc: boolean to enable Nand Flash Controller(NFC).
+- atmel,use-nfc-sram: boolean to enable NFC transfer data via sram.
 
 Examples:
 nand0: nand at 40000000,0 {
diff --git a/drivers/mtd/nand/atmel_nand.c b/drivers/mtd/nand/atmel_nand.c
index fc609db..d16cd2e 100644
--- a/drivers/mtd/nand/atmel_nand.c
+++ b/drivers/mtd/nand/atmel_nand.c
@@ -96,6 +96,9 @@ struct atmel_nfc {
 	void __iomem		*hsmc_regs;
 	void __iomem		*sram_bank0;
 	dma_addr_t		sram_bank0_phys;
+
+	/* Point to the sram bank which include readed data via NFC */
+	void __iomem		*data_in_sram;
 };
 
 struct atmel_nand_host {
@@ -112,6 +115,7 @@ struct atmel_nand_host {
 	struct dma_chan		*dma_chan;
 
 	bool			has_nfc;
+	bool			use_nfc_sram;
 	struct atmel_nfc	nfc;
 	struct completion	comp_nfc;
 
@@ -204,21 +208,43 @@ static int atmel_nand_device_ready(struct mtd_info *mtd)
                 !!host->board.rdy_pin_active_low;
 }
 
+static void memcpy32_fromio(void *trg, const void __iomem  *src, size_t size)
+{
+	int i;
+	u32 *t = trg;
+	const __iomem u32 *s = src;
+
+	for (i = 0; i < (size >> 2); i++)
+		*t++ = readl_relaxed(s++);
+}
+
 /*
  * Minimal-overhead PIO for data access.
  */
 static void atmel_read_buf8(struct mtd_info *mtd, u8 *buf, int len)
 {
 	struct nand_chip	*nand_chip = mtd->priv;
+	struct atmel_nand_host *host = nand_chip->priv;
 
-	__raw_readsb(nand_chip->IO_ADDR_R, buf, len);
+	if (host->use_nfc_sram && host->nfc.data_in_sram) {
+		memcpy32_fromio(buf, host->nfc.data_in_sram, len);
+		host->nfc.data_in_sram += len;
+	} else {
+		__raw_readsb(nand_chip->IO_ADDR_R, buf, len);
+	}
 }
 
 static void atmel_read_buf16(struct mtd_info *mtd, u8 *buf, int len)
 {
 	struct nand_chip	*nand_chip = mtd->priv;
+	struct atmel_nand_host *host = nand_chip->priv;
 
-	__raw_readsw(nand_chip->IO_ADDR_R, buf, len / 2);
+	if (host->use_nfc_sram && host->nfc.data_in_sram) {
+		memcpy32_fromio(buf, host->nfc.data_in_sram, len);
+		host->nfc.data_in_sram += len;
+	} else {
+		__raw_readsw(nand_chip->IO_ADDR_R, buf, len / 2);
+	}
 }
 
 static void atmel_write_buf8(struct mtd_info *mtd, const u8 *buf, int len)
@@ -240,6 +266,40 @@ static void dma_complete_func(void *completion)
 	complete(completion);
 }
 
+static int nfc_set_sram_bank(struct atmel_nand_host *host, unsigned int bank)
+{
+	/* NFC only has two banks. Must be 0 or 1 */
+	if (bank > 1)
+		return -EINVAL;
+
+	if (bank) {
+		/* Only for a 2k-page or lower flash, NFC can handle 2 banks */
+		if (host->mtd.writesize > 2048)
+			return -EINVAL;
+		nfc_writel(host->nfc.hsmc_regs, BANK, ATMEL_HSMC_NFC_BANK1);
+	} else {
+		nfc_writel(host->nfc.hsmc_regs, BANK, ATMEL_HSMC_NFC_BANK0);
+	}
+
+	return 0;
+}
+
+static uint nfc_get_sram_off(struct atmel_nand_host *host)
+{
+	if (nfc_readl(host->nfc.hsmc_regs, BANK) & ATMEL_HSMC_NFC_BANK1)
+		return NFC_SRAM_BANK_OFFSET;
+	else
+		return 0;
+}
+
+static dma_addr_t nfc_sram_phys(struct atmel_nand_host *host)
+{
+	if (nfc_readl(host->nfc.hsmc_regs, BANK) & ATMEL_HSMC_NFC_BANK1)
+		return host->nfc.sram_bank0_phys + NFC_SRAM_BANK_OFFSET;
+	else
+		return host->nfc.sram_bank0_phys;
+}
+
 static int atmel_nand_dma_op(struct mtd_info *mtd, void *buf, int len,
 			       int is_read)
 {
@@ -253,6 +313,7 @@ static int atmel_nand_dma_op(struct mtd_info *mtd, void *buf, int len,
 	void *p = buf;
 	int err = -EIO;
 	enum dma_data_direction dir = is_read ? DMA_FROM_DEVICE : DMA_TO_DEVICE;
+	struct atmel_nfc *nfc = &host->nfc;
 
 	if (buf >= high_memory)
 		goto err_buf;
@@ -269,7 +330,12 @@ static int atmel_nand_dma_op(struct mtd_info *mtd, void *buf, int len,
 	}
 
 	if (is_read) {
-		dma_src_addr = host->io_phys;
+		if (nfc->data_in_sram)
+			dma_src_addr = nfc_sram_phys(host) + (nfc->data_in_sram
+				- (nfc->sram_bank0 + nfc_get_sram_off(host)));
+		else
+			dma_src_addr = host->io_phys;
+
 		dma_dst_addr = phys_addr;
 	} else {
 		dma_src_addr = phys_addr;
@@ -296,6 +362,10 @@ static int atmel_nand_dma_op(struct mtd_info *mtd, void *buf, int len,
 	dma_async_issue_pending(host->dma_chan);
 	wait_for_completion(&host->comp);
 
+	if (is_read && host->nfc.data_in_sram)
+		/* After read data from SRAM, need to increase the position */
+		host->nfc.data_in_sram += len;
+
 	err = 0;
 
 err_dma:
@@ -810,7 +880,8 @@ static int atmel_nand_pmecc_read_page(struct mtd_info *mtd,
 	unsigned long end_time;
 	int bitflips = 0;
 
-	pmecc_enable(host, PMECC_READ);
+	if (!host->use_nfc_sram)
+		pmecc_enable(host, PMECC_READ);
 
 	chip->read_buf(mtd, buf, eccsize);
 	chip->read_buf(mtd, oob, mtd->oobsize);
@@ -1371,6 +1442,7 @@ static int atmel_of_init_port(struct atmel_nand_host *host,
 
 	host->has_pmecc = of_property_read_bool(np, "atmel,has-pmecc");
 	host->has_nfc = of_property_read_bool(np, "atmel,has-nfc");
+	host->use_nfc_sram = of_property_read_bool(np, "atmel,use-nfc-sram");
 
 	if (!(board->ecc_mode == NAND_ECC_HW) || !host->has_pmecc)
 		return 0;	/* Not using PMECC */
@@ -1667,6 +1739,7 @@ static void nfc_nand_command(struct mtd_info *mtd, unsigned int command,
 	unsigned int addr1234 = 0;
 	unsigned int cycle0 = 0;
 	bool do_addr = true;
+	host->nfc.data_in_sram = NULL;
 
 	dev_dbg(host->dev, "%s: cmd = 0x%02x, col = 0x%08x, page = 0x%08x\n",
 	     __func__, command, column, page_addr);
@@ -1708,6 +1781,16 @@ static void nfc_nand_command(struct mtd_info *mtd, unsigned int command,
 			command = NAND_CMD_READ0; /* only READ0 is valid */
 			cmd1 = command << 2;
 		}
+		if (host->use_nfc_sram) {
+			/* Enable Data transfer to sram */
+			dataen = NFCADDR_CMD_DATAEN;
+
+			/* Need enable PMECC now, since NFC will transfer
+			 * data in bus after sending nfc read command.
+			 */
+			if (chip->ecc.mode == NAND_ECC_HW && host->has_pmecc)
+				pmecc_enable(host, PMECC_READ);
+		}
 
 		cmd2 = NAND_CMD_READSTART << 10;
 		vcmd2 = NFCADDR_CMD_VCMD2;
@@ -1729,6 +1812,10 @@ static void nfc_nand_command(struct mtd_info *mtd, unsigned int command,
 	nfc_addr_cmd = cmd1 | cmd2 | vcmd2 | acycle | csid | dataen | nfcwr;
 	nfc_send_command(host, nfc_addr_cmd, addr1234, cycle0);
 
+	if (dataen == NFCADDR_CMD_DATAEN)
+		if (nfc_wait_interrupt(host, ATMEL_HSMC_NFC_XFR_DONE))
+			dev_err(host->dev, "something wrong, No XFR_DONE interrupt comes.\n");
+
 	/*
 	 * Program and erase have their own busy handlers status, sequential
 	 * in, and deplete1 need no delay.
@@ -1756,12 +1843,62 @@ static void nfc_nand_command(struct mtd_info *mtd, unsigned int command,
 		return;
 
 	case NAND_CMD_READ0:
+		if (dataen == NFCADDR_CMD_DATAEN) {
+			host->nfc.data_in_sram = host->nfc.sram_bank0 +
+				nfc_get_sram_off(host);
+			return;
+		}
 		/* fall through */
 	default:
 		nfc_wait_interrupt(host, ATMEL_HSMC_NFC_RB_EDGE);
 	}
 }
 
+static int nfc_sram_init(struct mtd_info *mtd)
+{
+	struct nand_chip *chip = mtd->priv;
+	struct atmel_nand_host *host = chip->priv;
+	int res = 0;
+
+	/* Initialize the NFC CFG register */
+	unsigned int cfg_nfc = 0;
+
+	/* set page size and oob layout */
+	switch (mtd->writesize) {
+	case 512:
+		cfg_nfc = ATMEL_HSMC_PAGESIZE_512;
+		break;
+	case 1024:
+		cfg_nfc = ATMEL_HSMC_PAGESIZE_1024;
+		break;
+	case 2048:
+		cfg_nfc = ATMEL_HSMC_PAGESIZE_2048;
+		break;
+	case 4096:
+		cfg_nfc = ATMEL_HSMC_PAGESIZE_4096;
+		break;
+	case 8192:
+		cfg_nfc = ATMEL_HSMC_PAGESIZE_8192;
+		break;
+	default:
+		dev_err(host->dev, "Unsupported page size for NFC.\n");
+		res = -ENXIO;
+		return res;
+	}
+
+	cfg_nfc |= ((mtd->oobsize / 4) - 1) << 24;
+	cfg_nfc |= ATMEL_HSMC_RSPARE |
+			ATMEL_HSMC_NFC_DTOCYC | ATMEL_HSMC_NFC_DTOMUL;
+
+	nfc_writel(host->nfc.hsmc_regs, CFG, cfg_nfc);
+
+	nfc_set_sram_bank(host, 0);
+
+	dev_info(host->dev, "Using NFC Sram\n");
+
+	return 0;
+}
+
 /*
  * Probe for the NAND device.
  */
@@ -1967,6 +2104,15 @@ static int __init atmel_nand_probe(struct platform_device *pdev)
 			goto err_hw_ecc;
 	}
 
+	/* initialize the nfc configuration register */
+	if (host->has_nfc && host->use_nfc_sram) {
+		res = nfc_sram_init(mtd);
+		if (res) {
+			host->use_nfc_sram = false;
+			dev_err(host->dev, "Disable use nfc sram for data transfer.\n");
+		}
+	}
+
 	/* second phase scan */
 	if (nand_scan_tail(mtd)) {
 		res = -ENXIO;
-- 
1.7.9.5



From josh.wu at atmel.com  Tue Apr 23 06:29:57 2013
From: josh.wu at atmel.com (Josh Wu)
Date: Tue, 23 Apr 2013 18:29:57 +0800
Subject: [PATCH 4/4] mtd: atmel_nand: enable Nand Flash Controller (NFC) write
 via sram
In-Reply-To: <1366712997-17639-1-git-send-email-josh.wu@atmel.com>
References: <1366712997-17639-1-git-send-email-josh.wu@atmel.com>
Message-ID: <1366712997-17639-5-git-send-email-josh.wu@atmel.com>

This patch enable writing nand flash via NFC SRAM. It will minimize the CPU
overhead. The SRAM write only support ECC_NONE and ECC_HW with PMECC.

This driver has been tested on SAMA5D3X-EK with JFFS2, YAFFS2, UBIFS and
mtd-utils.

Here is part of mtd_speedtest (writing test) result, compare with non-NFC
writing, it reduces %65 cpu load with loss %12 speed.

- commands use to test:
  # insmod /mnt/mtd_speedtest.ko dev=2 &
  # top -n 30 -d 1 | grep speedtest

- test result:
=================================================
mtd_speedtest: MTD device: 2
mtd_speedtest: MTD device size 41943040, eraseblock size 131072, page size 2048, count of eraseblocks 320, pages per eraseblock 64, OOB size 64
mtd_speedtest: testing eraseblock write speed
  509   495 root     D     1164   0%   7% insmod /mnt/mtd_speedtest.ko dev=2
  509   495 root     D     1164   0%   8% insmod /mnt/mtd_speedtest.ko dev=2
  509   495 root     R     1164   0%   5% insmod /mnt/mtd_speedtest.ko dev=2
mtd_speedtest: eraseblock write speed is 5194 KiB/s
mtd_speedtest: testing page write speed
  509   495 root     D     1164   0%  32% insmod /mnt/mtd_speedtest.ko dev=2
  509   495 root     D     1164   0%  27% insmod /mnt/mtd_speedtest.ko dev=2
  509   495 root     D     1164   0%  25% insmod /mnt/mtd_speedtest.ko dev=2
  509   495 root     D     1164   0%  30% insmod /mnt/mtd_speedtest.ko dev=2
mtd_speedtest: page write speed is 5024 KiB/s

Signed-off-by: Josh Wu <josh.wu at atmel.com>
---
 drivers/mtd/nand/atmel_nand.c |   90 +++++++++++++++++++++++++++++++++++++++--
 1 file changed, 86 insertions(+), 4 deletions(-)

diff --git a/drivers/mtd/nand/atmel_nand.c b/drivers/mtd/nand/atmel_nand.c
index d16cd2e..56e36ba 100644
--- a/drivers/mtd/nand/atmel_nand.c
+++ b/drivers/mtd/nand/atmel_nand.c
@@ -99,6 +99,7 @@ struct atmel_nfc {
 
 	/* Point to the sram bank which include readed data via NFC */
 	void __iomem		*data_in_sram;
+	bool			will_write_sram;
 };
 
 struct atmel_nand_host {
@@ -218,6 +219,16 @@ static void memcpy32_fromio(void *trg, const void __iomem  *src, size_t size)
 		*t++ = readl_relaxed(s++);
 }
 
+static void memcpy32_toio(void __iomem *trg, const void *src, int size)
+{
+	int i;
+	u32 __iomem *t = trg;
+	const u32 *s = src;
+
+	for (i = 0; i < (size >> 2); i++)
+		writel_relaxed(*s++, t++);
+}
+
 /*
  * Minimal-overhead PIO for data access.
  */
@@ -339,7 +350,11 @@ static int atmel_nand_dma_op(struct mtd_info *mtd, void *buf, int len,
 		dma_dst_addr = phys_addr;
 	} else {
 		dma_src_addr = phys_addr;
-		dma_dst_addr = host->io_phys;
+
+		if (host->use_nfc_sram)
+			dma_dst_addr = nfc_sram_phys(host);
+		else
+			dma_dst_addr = host->io_phys;
 	}
 
 	tx = dma_dev->device_prep_dma_memcpy(host->dma_chan, dma_dst_addr,
@@ -914,9 +929,10 @@ static int atmel_nand_pmecc_write_page(struct mtd_info *mtd,
 	int i, j;
 	unsigned long end_time;
 
-	pmecc_enable(host, PMECC_WRITE);
-
-	chip->write_buf(mtd, (u8 *)buf, mtd->writesize);
+	if (!host->use_nfc_sram) {
+		pmecc_enable(host, PMECC_WRITE);
+		chip->write_buf(mtd, (u8 *)buf, mtd->writesize);
+	}
 
 	end_time = jiffies + msecs_to_jiffies(PMECC_MAX_TIMEOUT_MS);
 	while ((pmecc_readl_relaxed(host->ecc, SR) & PMECC_SR_BUSY)) {
@@ -1800,6 +1816,8 @@ static void nfc_nand_command(struct mtd_info *mtd, unsigned int command,
 	case NAND_CMD_SEQIN:
 	case NAND_CMD_RNDIN:
 		nfcwr = NFCADDR_CMD_NFCWR;
+		if (host->nfc.will_write_sram && command == NAND_CMD_SEQIN)
+			dataen = NFCADDR_CMD_DATAEN;
 		break;
 	default:
 		break;
@@ -1854,6 +1872,64 @@ static void nfc_nand_command(struct mtd_info *mtd, unsigned int command,
 	}
 }
 
+static int nfc_sram_write_page(struct mtd_info *mtd, struct nand_chip *chip,
+			   const uint8_t *buf, int oob_required, int page,
+			   int cached, int raw)
+{
+	int cfg, len;
+	int status = 0;
+	struct atmel_nand_host *host = chip->priv;
+	void __iomem *sram = host->nfc.sram_bank0 + nfc_get_sram_off(host);
+
+	cfg = nfc_readl(host->nfc.hsmc_regs, CFG);
+	len = mtd->writesize;
+
+	if (unlikely(raw)) {
+		len += mtd->oobsize;
+		nfc_writel(host->nfc.hsmc_regs, CFG, cfg | ATMEL_HSMC_WSPARE);
+	} else
+		nfc_writel(host->nfc.hsmc_regs, CFG, cfg & ~ATMEL_HSMC_WSPARE);
+
+	/* Copy page data to sram that will write to nand via NFC */
+	if (use_dma) {
+		if (atmel_nand_dma_op(mtd, (void *)buf, len, 0) != 0)
+			/* Fall back to use cpu copy */
+			memcpy32_toio(sram, buf, len);
+	} else {
+		memcpy32_toio(sram, buf, len);
+	}
+
+	if (chip->ecc.mode == NAND_ECC_HW && host->has_pmecc)
+		/*
+		 * When use NFC sram, need set up PMECC before send
+		 * NAND_CMD_SEQIN command. Since when the nand command
+		 * is sent, nfc will do transfer from sram and nand.
+		 */
+		pmecc_enable(host, PMECC_WRITE);
+
+	host->nfc.will_write_sram = true;
+	chip->cmdfunc(mtd, NAND_CMD_SEQIN, 0x00, page);
+	host->nfc.will_write_sram = false;
+
+	if (likely(!raw))
+		/* Need to write ecc into oob */
+		status = chip->ecc.write_page(mtd, chip, buf, oob_required);
+
+	if (status < 0)
+		return status;
+
+	chip->cmdfunc(mtd, NAND_CMD_PAGEPROG, -1, -1);
+	status = chip->waitfunc(mtd, chip);
+
+	if ((status & NAND_STATUS_FAIL) && (chip->errstat))
+		status = chip->errstat(mtd, chip, FL_WRITING, status, page);
+
+	if (status & NAND_STATUS_FAIL)
+		return -EIO;
+
+	return 0;
+}
+
 static int nfc_sram_init(struct mtd_info *mtd)
 {
 	struct nand_chip *chip = mtd->priv;
@@ -1892,10 +1968,16 @@ static int nfc_sram_init(struct mtd_info *mtd)
 
 	nfc_writel(host->nfc.hsmc_regs, CFG, cfg_nfc);
 
+	host->nfc.will_write_sram = false;
 	nfc_set_sram_bank(host, 0);
 
 	dev_info(host->dev, "Using NFC Sram\n");
 
+	/* Use Write page with NFC SRAM only for PMECC or ECC NONE. */
+	if ((chip->ecc.mode == NAND_ECC_HW && host->has_pmecc) ||
+			chip->ecc.mode == NAND_ECC_NONE)
+		chip->write_page = nfc_sram_write_page;
+
 	return 0;
 }
 
-- 
1.7.9.5



From marex at denx.de  Tue Apr 23 06:29:48 2013
From: marex at denx.de (Marek Vasut)
Date: Tue, 23 Apr 2013 12:29:48 +0200
Subject: [RFC][PATCH] video: imx: Select VIDEOMODE_HELPERS
In-Reply-To: <20130423050745.GO32299@pengutronix.de>
References: <1366666110-9585-1-git-send-email-marex@denx.de>
 <201304230157.47992.marex@denx.de> <20130423050745.GO32299@pengutronix.de>
Message-ID: <201304231229.48511.marex@denx.de>

Dear Sascha Hauer,

> On Tue, Apr 23, 2013 at 01:57:47AM +0200, Marek Vasut wrote:
> > Dear Fabio Estevam,
> > 
> > > Hi Marek,
> > > 
> > > On Mon, Apr 22, 2013 at 6:28 PM, Marek Vasut <marex at denx.de> wrote:
> > > > Without this, I get the following problem when building kernel:
> > > > 
> > > > drivers/built-in.o: In function `imx_pd_connector_get_modes':
> > > > /linux-2.6/drivers/staging/imx-drm/parallel-display.c:78: undefined
> > > > reference to `of_get_drm_display_mode' make: *** [vmlinux] Error 1
> > > > 
> > > > NOTE: I think this patch is almost absolutely not correct.
> > > > 
> > > > Signed-off-by: Marek Vasut <marex at denx.de>
> > > > Cc: Sascha Hauer <s.hauer at pengutronix.de>
> > > > Cc: Philipp Zabel <p.zabel at pengutronix.de>
> > > > Cc: Fabio Estevam <fabio.estevam at freescale.com>
> > > 
> > > Patch looks good, but you should have copied Greg Kroah-Hartman, as he
> > > is the one who takes patches into staging.
> > 
> > I'm not sure if the select is at correct symbol, I dont think it is.
> 
> No it's not. The parallel display driver needs it, not the i.MX drm
> support in general.

Yep, I expected this coming, thus RFC. I'll roll out new patch and move this to 
parallel display, ok?

Best regards,
Marek Vasut


From linus.walleij at linaro.org  Tue Apr 23 06:42:12 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Tue, 23 Apr 2013 12:42:12 +0200
Subject: [PATCH] ARM: ux500: Supply a DTS file for the u8540 platform
In-Reply-To: <20130404072907.GB3004@gmail.com>
References: <1364908916-29803-1-git-send-email-lee.jones@linaro.org>
 <1364908916-29803-3-git-send-email-lee.jones@linaro.org>
 <CACRpkdafSvT5Xb=7sqnkRHcc4UKkVzr8jzThMgWn6459RDmKGw@mail.gmail.com>
 <20130404072907.GB3004@gmail.com>
Message-ID: <CACRpkdZL=j+gj8dFbWMfYiNFisjQj23HKiMeZXk+OAfcp=j4zg@mail.gmail.com>

On Thu, Apr 4, 2013 at 9:29 AM, Lee Jones <lee.jones at linaro.org> wrote:

> This is a skeleton DTS file which only enables serial. Just using
> this simple file yields a terminal when booting u8540.
>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>

I've queued this patch for v3.11.

Yours,
Linus Walleij


From laurent.pinchart at ideasonboard.com  Tue Apr 23 06:48:03 2013
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Tue, 23 Apr 2013 12:48:03 +0200
Subject: [PATCH] ARM: shmobile: lager: Add GPIO LEDs
In-Reply-To: <20130423011524.GE12017@verge.net.au>
References: <1366599990-31751-1-git-send-email-horms+renesas@verge.net.au>
 <1761228.8meccMO5Km@avalon> <20130423011524.GE12017@verge.net.au>
Message-ID: <2538127.Zp8aiG0hQe@avalon>

Hi Simon,

On Tuesday 23 April 2013 10:15:25 Simon Horman wrote:
> On Mon, Apr 22, 2013 at 12:00:02PM +0200, Laurent Pinchart wrote:
> > Hi Simon,
> > 
> > Thank you for the patch.
> > 
> > On Monday 22 April 2013 12:06:30 Simon Horman wrote:
> > > The board has 3 LEDs connected to GPIOs. Add a led-gpio device to
> > > support them.
> > > 
> > > Based on "ARM: shmobile: marzen: Add GPIO LEDs" by Laurent Pinchart.
> > > 
> > > Cc: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
> > > Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
> > > ---
> > > 
> > >  arch/arm/mach-shmobile/board-lager.c | 37 +++++++++++++++++++++++++++++
> > >  1 file changed, 37 insertions(+)
> > > 
> > > Tested on lager board.
> > > Based on the tag renesas-next-20130419 of my renesas tree.
> > > 
> > > diff --git a/arch/arm/mach-shmobile/board-lager.c
> > > b/arch/arm/mach-shmobile/board-lager.c index 6114edd..a8aa04f 100644
> > > --- a/arch/arm/mach-shmobile/board-lager.c
> > > +++ b/arch/arm/mach-shmobile/board-lager.c
> > > @@ -21,13 +21,49 @@
> > >  #include <linux/interrupt.h>
> > >  #include <linux/irqchip.h>
> > >  #include <linux/kernel.h>
> > > +#include <linux/leds.h>
> > >  #include <linux/pinctrl/machine.h>
> > > +#include <linux/platform_data/gpio-rcar.h>
> > >  #include <linux/platform_device.h>
> > >  #include <mach/common.h>
> > >  #include <mach/r8a7790.h>
> > >  #include <asm/mach-types.h>
> > >  #include <asm/mach/arch.h>
> > > 
> > > +/* LEDS */
> > > +static struct gpio_led lager_leds[] = {
> > > +	{
> > > +		.name		= "led8",
> > > +		.gpio		= RCAR_GP_PIN(5, 17),
> > > +		.default_state	= LEDS_GPIO_DEFSTATE_ON,
> > > +	}, {
> > > +		.name		= "led7",
> > > +		.gpio		= RCAR_GP_PIN(4, 23),
> > > +		.default_state	= LEDS_GPIO_DEFSTATE_ON,
> > > +	}, {
> > > +		.name		= "led6",
> > > +		.gpio		= RCAR_GP_PIN(4, 22),
> > > +		.default_state	= LEDS_GPIO_DEFSTATE_ON,
> > 
> > Just out of curiosity, why is the default state on ?
> 
> Only because thats what the marzen code does.
> Would off be a better choice?

It would save a little bit of power by default :-)

> > > +	},
> > > +};

-- 
Regards,

Laurent Pinchart



From catalin.marinas at arm.com  Tue Apr 23 06:48:51 2013
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Tue, 23 Apr 2013 11:48:51 +0100
Subject: [PATCH] ARM64: kernel: compiling issue, define cmpxchg64 and
 cmpxchg64_local for outside using.
In-Reply-To: <5174C5D9.3060109@asianux.com>
References: <51712E5E.2020809@asianux.com> <201304191412.54601.arnd@arndb.de>
 <5171FD67.2080104@asianux.com> <2182812.ymprEm6XBb@wuerfel>
 <5174C5D9.3060109@asianux.com>
Message-ID: <20130423104851.GC23407@arm.com>

On Mon, Apr 22, 2013 at 06:08:41AM +0100, Chen Gang wrote:
> 
>   drivers use cmpxchg64, cmpxchg64_local ... to perform 64-bit operation,
>   so they can cross 32-bit and 64-bit platforms (it is a standard way).
> 
> 
> Signed-off-by: Chen Gang <gang.chen at asianux.com>

Applied, thanks.

-- 
Catalin


From gang.chen at asianux.com  Tue Apr 23 06:54:02 2013
From: gang.chen at asianux.com (Chen Gang)
Date: Tue, 23 Apr 2013 18:54:02 +0800
Subject: [PATCH] ARM64: kernel: compiling issue, define cmpxchg64 and
 cmpxchg64_local for outside using.
In-Reply-To: <20130423104851.GC23407@arm.com>
References: <51712E5E.2020809@asianux.com> <201304191412.54601.arnd@arndb.de>
 <5171FD67.2080104@asianux.com> <2182812.ymprEm6XBb@wuerfel>
 <5174C5D9.3060109@asianux.com> <20130423104851.GC23407@arm.com>
Message-ID: <5176684A.2080600@asianux.com>

On 2013?04?23? 18:48, Catalin Marinas wrote:
> On Mon, Apr 22, 2013 at 06:08:41AM +0100, Chen Gang wrote:
>> > 
>> >   drivers use cmpxchg64, cmpxchg64_local ... to perform 64-bit operation,
>> >   so they can cross 32-bit and 64-bit platforms (it is a standard way).
>> > 
>> > 
>> > Signed-off-by: Chen Gang <gang.chen at asianux.com>
> Applied, thanks.


Thanks too. I should continue to find and make new patches for arm64.


-- 
Chen Gang

Asianux Corporation


From pavel at denx.de  Tue Apr 23 06:58:27 2013
From: pavel at denx.de (Pavel Machek)
Date: Tue, 23 Apr 2013 12:58:27 +0200
Subject: dw_apb_timer_of.c: remove parts that were picoxcell-specific
Message-ID: <20130423105827.GA6983@amd.pavel.ucw.cz>


It seems we made a mistake when creating dw_apb_timer_of.c:
picoxcell sched_clock parts were not related to dw_apb_timer, yet
we moved them to dw_apb_timer_of, and tried to use them on socfpga.
    
This results in system where user/system time is not measured properly,
as demonstrated by
    
    time dd if=/dev/urandom of=/dev/zero bs=100000 count=100
    
    .
    
So this patch:
    
    1) moves picoxcell sched_clock parts back to picoxcell
    
    2) adds support to use dw_apb_timer s as sched_clock. Picoxcell could
    consider switching to these
    
    3) adds missing of_node_put() in dw_apb_timer_init().
    
Tested on socfpga, soc-next (3.9-rc6) based tree.
    
Signed-off-by: Pavel Machek <pavel at denx.de>

diff --git a/arch/arm/mach-picoxcell/common.c b/arch/arm/mach-picoxcell/common.c
index 70b441a..22759f5 100644
--- a/arch/arm/mach-picoxcell/common.c
+++ b/arch/arm/mach-picoxcell/common.c
@@ -84,11 +84,39 @@ static void picoxcell_wdt_restart(char mode, const char *cmd)
 	}
 }
 
+static const struct of_device_id picochip_rtc_ids[] __initconst = {
+        { .compatible = "picochip,pc3x2-rtc" },
+        { /* Sentinel */ },
+};
+
+static void __iomem *sched_io_base;
+
+static u32 read_sched_clock(void)
+{
+        return __raw_readl(sched_io_base);
+}
+
+static void __init timer_init(void)
+{
+	u32 rate;
+
+	dw_apb_timer_init(0);
+
+	sched_timer = of_find_matching_node(timer, osctimer_ids);
+	if (!sched_timer)
+		panic("No suitable timer for scheduler clock\n");
+
+	timer_get_base_and_rate(sched_timer, &sched_io_base, &rate);
+	of_node_put(sched_timer);
+
+	setup_sched_clock(read_sched_clock, 32, rate);
+}
+
 DT_MACHINE_START(PICOXCELL, "Picochip picoXcell")
 	.map_io		= picoxcell_map_io,
 	.nr_irqs	= NR_IRQS_LEGACY,
 	.init_irq	= irqchip_init,
-	.init_time	= dw_apb_timer_init,
+	.init_time	= timer_init,
 	.init_machine	= picoxcell_init_machine,
 	.dt_compat	= picoxcell_dt_match,
 	.restart	= picoxcell_wdt_restart,
diff --git a/arch/arm/mach-socfpga/socfpga.c b/arch/arm/mach-socfpga/socfpga.c
index 46a0513..3a030e5 100644
--- a/arch/arm/mach-socfpga/socfpga.c
+++ b/arch/arm/mach-socfpga/socfpga.c
@@ -116,11 +116,17 @@ static const char *altera_dt_match[] = {
 	NULL
 };
 
+static void __init timer_init(void)
+{
+	dw_apb_timer_init(1);
+}
+
+
 DT_MACHINE_START(SOCFPGA, "Altera SOCFPGA")
 	.smp		= smp_ops(socfpga_smp_ops),
 	.map_io		= socfpga_map_io,
 	.init_irq	= socfpga_init_irq,
-	.init_time	= dw_apb_timer_init,
+	.init_time	= timer_init,
 	.init_machine	= socfpga_cyclone5_init,
 	.restart	= socfpga_cyclone5_restart,
 	.dt_compat	= altera_dt_match,
diff --git a/drivers/clocksource/dw_apb_timer.c b/drivers/clocksource/dw_apb_timer.c
index 8c2a35f..460ac99 100644
--- a/drivers/clocksource/dw_apb_timer.c
+++ b/drivers/clocksource/dw_apb_timer.c
@@ -21,12 +21,6 @@
 #define APBT_MIN_PERIOD			4
 #define APBT_MIN_DELTA_USEC		200
 
-#define APBTMR_N_LOAD_COUNT		0x00
-#define APBTMR_N_CURRENT_VALUE		0x04
-#define APBTMR_N_CONTROL		0x08
-#define APBTMR_N_EOI			0x0c
-#define APBTMR_N_INT_STATUS		0x10
-
 #define APBTMRS_INT_STATUS		0xa0
 #define APBTMRS_EOI			0xa4
 #define APBTMRS_RAW_INT_STATUS		0xa8
diff --git a/drivers/clocksource/dw_apb_timer_of.c b/drivers/clocksource/dw_apb_timer_of.c
index ab09ed3..ac4ea00 100644
--- a/drivers/clocksource/dw_apb_timer_of.c
+++ b/drivers/clocksource/dw_apb_timer_of.c
@@ -57,7 +57,16 @@ static void add_clockevent(struct device_node *event_timer)
 	dw_apb_clockevent_register(ced);
 }
 
-static void add_clocksource(struct device_node *source_timer)
+static void __iomem *sched_io_base;
+
+/* This is actually same as __apbt_read_clocksource(), but with
+   different interface */
+static u32 read_sched_clock_sptimer(void)
+{
+	return ~__raw_readl(sched_io_base + APBTMR_N_CURRENT_VALUE);
+}
+
+static void add_clocksource(struct device_node *source_timer, int use_as_scheduler)
 {
 	void __iomem *iobase;
 	struct dw_apb_clocksource *cs;
@@ -71,45 +80,34 @@ static void add_clocksource(struct device_node *source_timer)
 
 	dw_apb_clocksource_start(cs);
 	dw_apb_clocksource_register(cs);
-}
 
-static void __iomem *sched_io_base;
-
-static u32 read_sched_clock(void)
-{
-	return __raw_readl(sched_io_base);
+	if (use_as_scheduler) {
+		sched_io_base = iobase;
+		setup_sched_clock(read_sched_clock_sptimer, 32, rate);
+	}
 }
 
-static const struct of_device_id sptimer_ids[] __initconst = {
-	{ .compatible = "picochip,pc3x2-rtc" },
+static const struct of_device_id osctimer_ids[] __initconst = {
+	{ .compatible = "picochip,pc3x2-timer" },
+	{ .compatible = "snps,dw-apb-timer-osc" },
 	{ .compatible = "snps,dw-apb-timer-sp" },
-	{ /* Sentinel */ },
+	{  /* Sentinel */ },
 };
 
-static void init_sched_clock(void)
-{
-	struct device_node *sched_timer;
-	u32 rate;
-
-	sched_timer = of_find_matching_node(NULL, sptimer_ids);
-	if (!sched_timer)
-		panic("No RTC for sched clock to use");
-
-	timer_get_base_and_rate(sched_timer, &sched_io_base, &rate);
-	of_node_put(sched_timer);
+/*
+   You don't have to use dw_apb_timer for scheduler clock,
+   this should also work fine on arm:
 
-	setup_sched_clock(read_sched_clock, 32, rate);
-}
+  twd_local_timer_of_register();
+  arch_timer_of_register();                 
+  arch_timer_sched_clock_init();
+*/
 
-static const struct of_device_id osctimer_ids[] __initconst = {
-	{ .compatible = "picochip,pc3x2-timer" },
-	{ .compatible = "snps,dw-apb-timer-osc" },
-	{},
-};
 
-void __init dw_apb_timer_init(void)
+void __init dw_apb_timer_init(int use_as_scheduler)
 {
 	struct device_node *event_timer, *source_timer;
+	u32 rate;
 
 	event_timer = of_find_matching_node(NULL, osctimer_ids);
 	if (!event_timer)
@@ -119,9 +117,8 @@ void __init dw_apb_timer_init(void)
 	source_timer = of_find_matching_node(event_timer, osctimer_ids);
 	if (!source_timer)
 		panic("No timer for clocksource");
-	add_clocksource(source_timer);
+	add_clocksource(source_timer, use_as_scheduler);
 
+	of_node_put(event_timer);
 	of_node_put(source_timer);
-
-	init_sched_clock();
 }
diff --git a/include/linux/dw_apb_timer.h b/include/linux/dw_apb_timer.h
index dd755ce..d503245 100644
--- a/include/linux/dw_apb_timer.h
+++ b/include/linux/dw_apb_timer.h
@@ -17,6 +17,12 @@
 #include <linux/clocksource.h>
 #include <linux/interrupt.h>
 
+#define APBTMR_N_LOAD_COUNT		0x00
+#define APBTMR_N_CURRENT_VALUE		0x04
+#define APBTMR_N_CONTROL		0x08
+#define APBTMR_N_EOI			0x0c
+#define APBTMR_N_INT_STATUS		0x10
+
 #define APBTMRS_REG_SIZE       0x14
 
 struct dw_apb_timer {
@@ -53,5 +59,5 @@ void dw_apb_clocksource_start(struct dw_apb_clocksource *dw_cs);
 cycle_t dw_apb_clocksource_read(struct dw_apb_clocksource *dw_cs);
 void dw_apb_clocksource_unregister(struct dw_apb_clocksource *dw_cs);
 
-extern void dw_apb_timer_init(void);
+extern void dw_apb_timer_init(int);
 #endif /* __DW_APB_TIMER_H__ */

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


From linus.walleij at linaro.org  Tue Apr 23 06:58:52 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Tue, 23 Apr 2013 12:58:52 +0200
Subject: [PATCH] ARM: ux500: Supply a DTS file for the u8540 platform
In-Reply-To: <20130404072907.GB3004@gmail.com>
References: <1364908916-29803-1-git-send-email-lee.jones@linaro.org>
 <1364908916-29803-3-git-send-email-lee.jones@linaro.org>
 <CACRpkdafSvT5Xb=7sqnkRHcc4UKkVzr8jzThMgWn6459RDmKGw@mail.gmail.com>
 <20130404072907.GB3004@gmail.com>
Message-ID: <CACRpkdZWuw9O3-wr=g1AehZqmBR1YJ353w9ANfBTHhr5mRiwiw@mail.gmail.com>

On Thu, Apr 4, 2013 at 9:29 AM, Lee Jones <lee.jones at linaro.org> wrote:

> This is a skeleton DTS file which only enables serial. Just using
> this simple file yields a terminal when booting u8540.
>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>

Now, wait... this doesn't work.

> +/ {
> +  model = "ST-Ericsson U8540 platform with Device Tree";
> +  compatible = "st-ericsson,u8540";
> +
> +       memory {
> +              reg = <0x00000000 0x20000000>;
> +              };

Funny whitespace. Use tabs ...

> +       soc-u9500 {

Please rename this not just "soc"

> +                 uart at 80120000 {
> +                                       status = "okay";
> +                                              };
> +
> +               uart at 80121000 {
> +                               status = "okay";
> +                                      };
> +
> +               uart at 80007000 {
> +                               status = "okay";
> +                                      };
> +                                      };
> +};

The whitespace looks a bit funny compared to the
old patch, what happened here?

It also has the side effect that patch 5/9 does not
apply... By the way, since I already applied 4/9, please
squash 5/9 into this patch to avoid problems.

Finally, please patch arch/arm/boot/dts/Makefile
in the obvious way so that the DTB gets compiled.

Yours,
Linus Walleij


From linus.walleij at linaro.org  Tue Apr 23 06:59:50 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Tue, 23 Apr 2013 12:59:50 +0200
Subject: [PATCH] ARM: ux500: Over-ride TCDM size when booting the DB8540
 platform
In-Reply-To: <20130404073340.GA6892@gmail.com>
References: <1364908916-29803-1-git-send-email-lee.jones@linaro.org>
 <1364908916-29803-5-git-send-email-lee.jones@linaro.org>
 <CACRpkdbh-DJti2ny=uBe-b_vGkQBNL=emMuZ6+_cE5jvRsA4sA@mail.gmail.com>
 <20130404073340.GA6892@gmail.com>
Message-ID: <CACRpkdYLJyvCK33pAHeOkXfBOiPJGAZ9bV+s-cJanfOXz+VTOg@mail.gmail.com>

On Thu, Apr 4, 2013 at 9:33 AM, Lee Jones <lee.jones at linaro.org> wrote:

> The PRCMU's Tightly Coupled Data Memory on the DB8540 platform is
> 8kB larger than it's predecessor's. We need to reflect that in its
> Device Tree. By re-specifying the address and size of the device
> we effectively over-ride the previous values with more accurate
> ones.
>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>

As mentioned this patch does not apply. Some whitespace trouble.

And please squash it into the patch adding the ccu8540, 3/9.

Yours,
Linus Walleij


From catalin.marinas at arm.com  Tue Apr 23 07:20:34 2013
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Tue, 23 Apr 2013 12:20:34 +0100
Subject: [PATCH V2 0/4] arm64: Initial patch-set for APM X-Gene SOC family
In-Reply-To: <1366712759-3431-1-git-send-email-vkale@apm.com>
References: <1366712759-3431-1-git-send-email-vkale@apm.com>
Message-ID: <20130423112034.GE23407@arm.com>

Hi Vinayak,

On Tue, Apr 23, 2013 at 11:25:55AM +0100, Vinayak Kale wrote:
> These are initial patches for APM X-Gene SOC family.
> This patch-set is based on soc-armv8-model branch of
> git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch64.git

The patches look ok to me but let's see if there are any other comments
on the dts files.

Since we go with a common defconfig, I'll drop the vexpress_defconfig as
well. There are dependencies on GIC and some other vexpress patches to
go into mainline before I can push my soc-armv8-model changes. I'll
queue your patches for 3.11 (after this merging window).

Thanks.

-- 
Catalin


From shawn.guo at linaro.org  Tue Apr 23 07:47:42 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 23 Apr 2013 19:47:42 +0800
Subject: [PATCH 3/3] pinctrl: add MVF pinctrl driver
In-Reply-To: <B56CDBE15CE27145A4B77D2D24263E851B17D9@039-SN1MPN1-003.039d.mgd.msft.net>
References: <1365753432-14247-1-git-send-email-b35083@freescale.com>
 <20130422145727.GA27475@S2101-09.ap.freescale.net>
 <B56CDBE15CE27145A4B77D2D24263E851B17D9@039-SN1MPN1-003.039d.mgd.msft.net>
Message-ID: <20130423114740.GC27475@S2101-09.ap.freescale.net>

On Tue, Apr 23, 2013 at 10:09:46AM +0000, Lu Jingchang-B35083 wrote:
> >> Signed-off-by: Jingchang Lu <b35083 at freescale.com>
> >> ---
> >>  .../bindings/pinctrl/fsl,mvf-pinctrl.txt           |  825 ++++++++
> >>  drivers/pinctrl/Kconfig                            |    8 +
> >>  drivers/pinctrl/Makefile                           |    1 +
> >>  drivers/pinctrl/pinctrl-mvf.c                      | 2042
> >++++++++++++++++++++
> >
> >We just removed those big arrays of imx_pin_reg from imx pinctrl soc
> >drivers.  Please do not bring it back for MVF.
> >
> [Lu Jingchang-B35083] 
> What's the status of your new i.mx pinctrl framework? I found that there are some discussion for that, Are they accepted? Where can I find the latest code so I can use it as the base for MVF platform? Thanks.
> 
It's on linux-next right now, and should be merged in the coming 3.10
window.

Shawn



From shawn.guo at linaro.org  Tue Apr 23 07:50:09 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 23 Apr 2013 19:50:09 +0800
Subject: [PATCH V2] ARM: mx5: Add support for DENX M53EVK
In-Reply-To: <1366665827-8949-1-git-send-email-marex@denx.de>
References: <1366665827-8949-1-git-send-email-marex@denx.de>
Message-ID: <20130423115007.GD27475@S2101-09.ap.freescale.net>

On Mon, Apr 22, 2013 at 11:23:47PM +0200, Marek Vasut wrote:
> This patch adds support for the DENX M53EVK board. The board currently supports
> NAND, Ethernet, UART, CAN, I2C.
> 
> Signed-off-by: Marek Vasut <marex at denx.de>
> Cc: Fabio Estevam <fabio.estevam at freescale.com>
> Cc: Shawn Guo <shawn.guo at linaro.org>
> ---
>  arch/arm/boot/dts/Makefile         |    1 +
>  arch/arm/boot/dts/imx53-m53evk.dts |  259 ++++++++++++++++++++++++++++++++++++
>  2 files changed, 260 insertions(+)
>  create mode 100644 arch/arm/boot/dts/imx53-m53evk.dts
> 
> V2: - Rebase on top of Shawn's patch:
>       "[PATCH] ARM: imx: move imx53-qsb audio codec clk lookup into DT"
>     - Use BGR666 format on LCD, this makes it depend on:
>       "[PATCH V2] video: imx: Add BGR666 support for parallel display"

Does it hurt if I just go ahead to apply the patch?  Or do I have to
wait for above patch goes in?

Shawn

>     - Remove the first LCD as it's not populated
>     - Reorder the DT nodes in alphabetical order
>     - Configure PWM pinmux properly
>     - Pass IRQ GPIO to STMPE-TS driver using "interrupt" and
>       "interrupt-parent" DT properties



From rjw at sisk.pl  Tue Apr 23 08:00:26 2013
From: rjw at sisk.pl (Rafael J. Wysocki)
Date: Tue, 23 Apr 2013 14:00:26 +0200
Subject: [V4 patch 00/15] cpuidle: code consolidation
In-Reply-To: <1366707285-12179-1-git-send-email-daniel.lezcano@linaro.org>
References: <1366707285-12179-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1575993.FIabeJeWGY@vostro.rjw.lan>

On Tuesday, April 23, 2013 10:54:30 AM Daniel Lezcano wrote:
> This patchset series provide some code consolidation across the different
> cpuidle drivers. It contains two parts, the first one is the removal of
> the time keeping flag and the second one, is a common initialization routine.
> 
> All the drivers use the en_core_tk_irqen flag, which means it is not necessary
> to make the time computation optional. We can remove this flag and assume the
> cpuidle framework always manage this operation.
> 
> The cpuidle code initialization is duplicated across the different drivers in
> the same manner.
> 
> The repeating pattern is:
> 
> SMP:
> 
> cpuidle_register_driver(drv);
> for_each_possible_cpu(cpu) {
>         dev = per_cpu(cpuidle_device, cpu);
>         cpuidle_register_device(dev);
> }
> 
> UP:
> 
> cpuidle_register_driver(drv);
> cpuidle_register_device(dev);
> 
> As on a UP machine the macro 'for_each_cpu' is a one iteration loop, using the
> initialization loop from SMP to UP works.
> 
> The patchset does some cleanup for different drivers in order to make the init
> code the same. Then it introduces a generic function:
> 
>   cpuidle_register(struct cpuidle_driver *drv, struct cpumask *cpumask)
> 
> The cpumask is for the coupled idle states.
> 
> The drivers are then modified to take into account this new function and
> to remove the duplicated code.
> 
> The benefit is observable in the diffstat: 332 lines of code removed.
> 
> Changelog:
>  - V4:
>    * Added the different Acked-by and Reviewed-by
>    * Removed the patches already merged:
>      * ARM: shmobile: cpuidle: remove shmobile_enter_wfi function
>      * ARM: shmobile: cpuidle: remove shmobile_enter_wfi prototype
>      * ARM: OMAP3: remove cpuidle_wrap_enter
>    * Removed patch without acked-by (no answer from the maintainer)
>      * ARM: s3c64xx: cpuidle: use init/exit common routine
> 
>  - V3:
>    * folded patch 5/19 into 19/19, they were:
>      * ARM: imx: cpuidle: use init/exit common routine
>      * ARM: imx: cpuidle: create separate drivers for imx5/imx6
>    * removed rule to make cpuidle.o in the imx's Makefile
>    * splitted patch 1/19 into two, they are:
>      * [V3 patch 01/19] ARM: shmobile: cpuidle: remove shmobile_enter_wfi
>      * [V3 patch 02/19] ARM: shmobile: cpuidle: remove shmobile_enter_wfi prototype
> 
>  - V2:
>    * fixed cpumask NULL test for coupled state in cpuidle_register
>    * added comment about structure copy
>    * changed printk by pr_err
>    * folded splitted message
>    * fixed return code in cpuidle_register
>    * updated Documentation/cpuidle/drivers.txt
>    * added in the changelog dev->state_count is filled by cpuidle_enable_device
>    * fixed tag for tegra in the first line patch description
>    * fixed tegra2 removed tegra_tear_down_cpu = tegra20_tear_down_cpu;
> 
>  - V1: Initial post
> 
> Tested-on: u8500
> Tested-on: at91
> Tested-on: intel i5
> Tested-on: OMAP4
> Tested-by: Kevin Hilman <khilman at linaro.org> # OMAP3, OMAP4
> Tested-by: Andrew Lunn <andrew at lunn.ch> # Kirkwood
> 
> Compiled with and without CPU_IDLE for:
>  u8500, at91, davinci, exynos, imx5, imx6, kirkwood, multi_v7 (for calxeda),
>  omap2plus, s3c64, tegra1, tegra2, tegra3
> 
> Daniel Lezcano (15):
>   cpuidle: remove en_core_tk_irqen flag
>   ARM: ux500: cpuidle: replace for_each_online_cpu by
>     for_each_possible_cpu
>   cpuidle: make a single register function for all
>   ARM: ux500: cpuidle: use init/exit common routine
>   ARM: at91: cpuidle: use init/exit common routine
>   ARM: OMAP3: cpuidle: use init/exit common routine
>   ARM: tegra: cpuidle: use init/exit common routine
>   ARM: shmobile: cpuidle: use init/exit common routine
>   ARM: OMAP4: cpuidle: use init/exit common routine
>   ARM: tegra: cpuidle: use init/exit common routine for tegra2
>   ARM: tegra: cpuidle: use init/exit common routine for tegra3
>   ARM: calxeda: cpuidle: use init/exit common routine
>   ARM: kirkwood: cpuidle: use init/exit common routine
>   ARM: davinci: cpuidle: use init/exit common routine
>   ARM: imx: cpuidle: use init/exit common routine

Whole series applied.

Thanks,
Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.


From linus.walleij at linaro.org  Tue Apr 23 08:00:11 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Tue, 23 Apr 2013 14:00:11 +0200
Subject: [PATCH 1/2] pinctrl: s3c64xx: Fix build error caused by undefined
 chained_irq_enter
In-Reply-To: <30362001.FF4K7WsZvh@flatron>
References: <1366060483-20342-1-git-send-email-tomasz.figa@gmail.com>
 <20130416163331.GP26958@opensource.wolfsonmicro.com>
 <30362001.FF4K7WsZvh@flatron>
Message-ID: <CACRpkdZ_9K-=4C7ksScqoX3WeF0LyPrzkCS6iMG6u_mCNnWRWw@mail.gmail.com>

On Wed, Apr 17, 2013 at 12:23 AM, Tomasz Figa <tomasz.figa at gmail.com> wrote:

> Commit de88cbb7 moved definitions of chained_irq_enter and
> chained_irq_exit to a generic header, which must be now included instead
> of the legacy arch-specific one.
>
> This patch fixes build error caused by including the legacy header
> leading to undefined chained_irq_enter and chained_irq_exit symbols.
>
> Signed-off-by: Tomasz Figa <tomasz.figa at gmail.com>

Patch applied.

Thanks!
Linus Walleij


From linus.walleij at linaro.org  Tue Apr 23 08:03:12 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Tue, 23 Apr 2013 14:03:12 +0200
Subject: [PATCH 2/2] pinctrl: samsung: Fix link error with
 CONFIG_PINCTRL_EXYNOS disabled
In-Reply-To: <1398545.9FqHoC0WZW@flatron>
References: <1366060483-20342-1-git-send-email-tomasz.figa@gmail.com>
 <20130416163331.GP26958@opensource.wolfsonmicro.com>
 <30362001.FF4K7WsZvh@flatron> <1398545.9FqHoC0WZW@flatron>
Message-ID: <CACRpkdbJj9Newk+sCTvJzxA4V2cmJ3hzuQELv7t1wFMhd_Y8+Q@mail.gmail.com>

On Wed, Apr 17, 2013 at 12:24 AM, Tomasz Figa <tomasz.figa at gmail.com> wrote:

> Commit f67faf487 added driver data for Exynos5250, which is available
> only if CONFIG_PINCTRL_EXYNOS is enabled. However probably due to merge
> error, the reference to this driver data structure was located outside
> of relevant ifdef and compiled unconditionally, leading to link error
> with CONFIG_PINCTRL_EXYNOS.
>
> This patch fixes mentioned link error by moving driver data entry under
> ifdef CONFIG_PINCTRL_EXYNOS.
>
> Signed-off-by: Tomasz Figa <tomasz.figa at gmail.com>

This does not apply to my "devel" branch in the pinctrl tree.

Could you rebase it on that branch?

Or is the error not even in my tree?

Yours,
Linus Walleij


From marex at denx.de  Tue Apr 23 08:05:31 2013
From: marex at denx.de (Marek Vasut)
Date: Tue, 23 Apr 2013 14:05:31 +0200
Subject: [PATCH V2] ARM: mx5: Add support for DENX M53EVK
In-Reply-To: <20130423115007.GD27475@S2101-09.ap.freescale.net>
References: <1366665827-8949-1-git-send-email-marex@denx.de>
 <20130423115007.GD27475@S2101-09.ap.freescale.net>
Message-ID: <201304231405.31785.marex@denx.de>

Dear Shawn Guo,

> On Mon, Apr 22, 2013 at 11:23:47PM +0200, Marek Vasut wrote:
> > This patch adds support for the DENX M53EVK board. The board currently
> > supports NAND, Ethernet, UART, CAN, I2C.
> > 
> > Signed-off-by: Marek Vasut <marex at denx.de>
> > Cc: Fabio Estevam <fabio.estevam at freescale.com>
> > Cc: Shawn Guo <shawn.guo at linaro.org>
> > ---
> > 
> >  arch/arm/boot/dts/Makefile         |    1 +
> >  arch/arm/boot/dts/imx53-m53evk.dts |  259
> >  ++++++++++++++++++++++++++++++++++++ 2 files changed, 260 insertions(+)
> >  create mode 100644 arch/arm/boot/dts/imx53-m53evk.dts
> > 
> > V2: - Rebase on top of Shawn's patch:
> >       "[PATCH] ARM: imx: move imx53-qsb audio codec clk lookup into DT"
> >     
> >     - Use BGR666 format on LCD, this makes it depend on:
> >       "[PATCH V2] video: imx: Add BGR666 support for parallel display"
> 
> Does it hurt if I just go ahead to apply the patch?  Or do I have to
> wait for above patch goes in?

The LCD will fail to probe, but other than that, it will work OK.

Best regards,
Marek Vasut


From t.figa at samsung.com  Tue Apr 23 08:09:46 2013
From: t.figa at samsung.com (Tomasz Figa)
Date: Tue, 23 Apr 2013 14:09:46 +0200
Subject: [PATCH 2/2] pinctrl: samsung: Fix link error with
 CONFIG_PINCTRL_EXYNOS disabled
In-Reply-To: <CACRpkdbJj9Newk+sCTvJzxA4V2cmJ3hzuQELv7t1wFMhd_Y8+Q@mail.gmail.com>
References: <1366060483-20342-1-git-send-email-tomasz.figa@gmail.com>
 <1398545.9FqHoC0WZW@flatron>
 <CACRpkdbJj9Newk+sCTvJzxA4V2cmJ3hzuQELv7t1wFMhd_Y8+Q@mail.gmail.com>
Message-ID: <6940961.67Lk2axxPL@amdc1227>

Hi Linus,

On Tuesday 23 of April 2013 14:03:12 Linus Walleij wrote:
> On Wed, Apr 17, 2013 at 12:24 AM, Tomasz Figa <tomasz.figa at gmail.com> wrote:
> > Commit f67faf487 added driver data for Exynos5250, which is available
> > only if CONFIG_PINCTRL_EXYNOS is enabled. However probably due to merge
> > error, the reference to this driver data structure was located outside
> > of relevant ifdef and compiled unconditionally, leading to link error
> > with CONFIG_PINCTRL_EXYNOS.
> > 
> > This patch fixes mentioned link error by moving driver data entry under
> > ifdef CONFIG_PINCTRL_EXYNOS.
> > 
> > Signed-off-by: Tomasz Figa <tomasz.figa at gmail.com>
> 
> This does not apply to my "devel" branch in the pinctrl tree.
> 
> Could you rebase it on that branch?
> 
> Or is the error not even in my tree?

This one got sent incorrectly due to my mistake. Please try the correct 
version:

[PATCH RESEND 2/2] pinctrl: samsung: Fix link error with CONFIG_PINCTRL_EXYNOS 
disabled

Best regards,
-- 
Tomasz Figa
Samsung Poland R&D Center
SW Solution Development, Kernel and System Framework



From cb at sgoc.de  Tue Apr 23 08:11:25 2013
From: cb at sgoc.de (Christoph G. Baumann)
Date: Tue, 23 Apr 2013 14:11:25 +0200
Subject: [PATCH 2/2] Support fsl-dcp crypto coprocessor
In-Reply-To: <1366719085-12847-1-git-send-email-cb@sgoc.de>
References: <1366710460-11637-1-git-send-email-cb@sgoc.de>
 <1366719085-12847-1-git-send-email-cb@sgoc.de>
Message-ID: <1366719085-12847-3-git-send-email-cb@sgoc.de>

From: "Christoph G. Baumann" <c.baumann at ppc-ag.de>

Forgot some changed files in the first try...

The following patch is a port of the original driver from Freescale to
the current mainline. The patch was tested under 3.7.

Signed-off-by: "Christoph G. Baumann" <cb at sgoc.de>
---
 arch/arm/boot/dts/imx28.dtsi                 |    2 +-
 drivers/staging/Kconfig                      |    2 ++
 drivers/staging/Makefile                     |    1 +
 include/linux/fsl/fsl-dcp_bootstream_ioctl.h |   32 ++++++++++++++++++++++++++
 4 files changed, 36 insertions(+), 1 deletion(-)
 create mode 100644 include/linux/fsl/fsl-dcp_bootstream_ioctl.h

diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
index 7ba4966..07c80cd 100644
--- a/arch/arm/boot/dts/imx28.dtsi
+++ b/arch/arm/boot/dts/imx28.dtsi
@@ -664,9 +664,9 @@
 			};
 
 			dcp at 80028000 {
+				compatible = "fsl,fsl-dcp";
 				reg = <0x80028000 0x2000>;
 				interrupts = <52 53 54>;
-				status = "disabled";
 			};
 
 			pxp at 8002a000 {
diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig
index 093f10c..b3cf08b 100644
--- a/drivers/staging/Kconfig
+++ b/drivers/staging/Kconfig
@@ -140,4 +140,6 @@ source "drivers/staging/zcache/Kconfig"
 
 source "drivers/staging/goldfish/Kconfig"
 
+source "drivers/staging/crypto/Kconfig"
+
 endif # STAGING
diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile
index fa41b04..6875e3e 100644
--- a/drivers/staging/Makefile
+++ b/drivers/staging/Makefile
@@ -62,3 +62,4 @@ obj-$(CONFIG_SB105X)		+= sb105x/
 obj-$(CONFIG_FIREWIRE_SERIAL)	+= fwserial/
 obj-$(CONFIG_ZCACHE)		+= zcache/
 obj-$(CONFIG_GOLDFISH)		+= goldfish/
+obj-$(CONFIG_CRYPTO_HW)		+= crypto/
diff --git a/include/linux/fsl/fsl-dcp_bootstream_ioctl.h b/include/linux/fsl/fsl-dcp_bootstream_ioctl.h
new file mode 100644
index 0000000..2859a8d
--- /dev/null
+++ b/include/linux/fsl/fsl-dcp_bootstream_ioctl.h
@@ -0,0 +1,32 @@
+/*
+ * Freescale DCP driver for bootstream update. Only handles the OTP KEY
+ * case and can only encrypt/decrypt.
+ *
+ * Author: Pantelis Antoniou <pantelis at embeddedalley.com>
+ *
+ * Copyright (C) 2008-2010 Freescale Semiconductor, Inc. All Rights Reserved.
+ * Copyright 2008 Embedded Alley Solutions, Inc All Rights Reserved.
+ */
+
+/*
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+#ifndef DCP_BOOTSTREAM_IOCTL_H
+#define DCP_BOOTSTREAM_IOCTL_H
+
+/* remember to have included the proper _IO definition
+ * file before hand.
+ * For user space it's <sys/ioctl.h>
+ */
+
+#define DBS_IOCTL_BASE   'd'
+
+#define DBS_ENC _IOW(DBS_IOCTL_BASE, 0x00, uint8_t[16])
+#define DBS_DEC _IOW(DBS_IOCTL_BASE, 0x01, uint8_t[16])
+
+#endif
-- 
1.7.9.5



From cb at sgoc.de  Tue Apr 23 08:11:23 2013
From: cb at sgoc.de (Christoph G. Baumann)
Date: Tue, 23 Apr 2013 14:11:23 +0200
Subject: [PATCH 0/2] Support fsl-dcp crypto coprocessor
In-Reply-To: <1366710460-11637-1-git-send-email-cb@sgoc.de>
References: <1366710460-11637-1-git-send-email-cb@sgoc.de>
Message-ID: <1366719085-12847-1-git-send-email-cb@sgoc.de>

From: "Christoph G. Baumann" <c.baumann at ppc-ag.de>


Forgot some changed files in the first try...

The following patch is a port of the original driver from Freescale to
the current mainline. The patch was tested under 3.7.

Christoph G. Baumann (2):
  Support fsl-dcp crypto coprocessor
  Support fsl-dcp crypto coprocessor

 arch/arm/boot/dts/imx28.dtsi                 |    2 +-
 drivers/staging/Kconfig                      |    2 +
 drivers/staging/Makefile                     |    1 +
 drivers/staging/crypto/Kconfig               |   15 +
 drivers/staging/crypto/Makefile              |    1 +
 drivers/staging/crypto/fsl-dcp.c             | 1817 ++++++++++++++++++++++++++
 drivers/staging/crypto/fsl-dcp.h             |  739 +++++++++++
 include/linux/fsl/fsl-dcp_bootstream_ioctl.h |   32 +
 8 files changed, 2608 insertions(+), 1 deletion(-)
 create mode 100644 drivers/staging/crypto/Kconfig
 create mode 100644 drivers/staging/crypto/Makefile
 create mode 100644 drivers/staging/crypto/fsl-dcp.c
 create mode 100644 drivers/staging/crypto/fsl-dcp.h
 create mode 100644 include/linux/fsl/fsl-dcp_bootstream_ioctl.h

-- 
1.7.9.5



From cb at sgoc.de  Tue Apr 23 08:11:24 2013
From: cb at sgoc.de (Christoph G. Baumann)
Date: Tue, 23 Apr 2013 14:11:24 +0200
Subject: [PATCH 1/2] Support fsl-dcp crypto coprocessor
In-Reply-To: <1366719085-12847-1-git-send-email-cb@sgoc.de>
References: <1366710460-11637-1-git-send-email-cb@sgoc.de>
 <1366719085-12847-1-git-send-email-cb@sgoc.de>
Message-ID: <1366719085-12847-2-git-send-email-cb@sgoc.de>

From: "Christoph G. Baumann" <c.baumann at ppc-ag.de>

Forgot some changed files in the first try...

The following patch is a port of the original driver from Freescale to
the current mainline. The patch was tested under 3.7.

Signed-off-by: "Christoph G. Baumann" <cb at sgoc.de>
---
 drivers/staging/crypto/Kconfig   |   15 +
 drivers/staging/crypto/Makefile  |    1 +
 drivers/staging/crypto/fsl-dcp.c | 1817 ++++++++++++++++++++++++++++++++++++++
 drivers/staging/crypto/fsl-dcp.h |  739 ++++++++++++++++
 4 files changed, 2572 insertions(+)
 create mode 100644 drivers/staging/crypto/Kconfig
 create mode 100644 drivers/staging/crypto/Makefile
 create mode 100644 drivers/staging/crypto/fsl-dcp.c
 create mode 100644 drivers/staging/crypto/fsl-dcp.h

diff --git a/drivers/staging/crypto/Kconfig b/drivers/staging/crypto/Kconfig
new file mode 100644
index 0000000..acf2cf9
--- /dev/null
+++ b/drivers/staging/crypto/Kconfig
@@ -0,0 +1,15 @@
+config CRYPTO_DEV_FSL_DCP
+	tristate "Support for the DCP engine"
+	depends on SOC_IMX23 || SOC_IMX28 || SOC_IMX50
+  select CRYPTO_HW
+	select CRYPTO_ALGAPI
+  select CRYPTO_SHA256
+	select CRYPTO_AES
+	select CRYPTO_BLKCIPHER
+	help
+	  Say 'Y' here to use the DCP AES and SHA
+	  engine for the CryptoAPI algorithms.
+
+	  To compile this driver as a module, choose M here: the module
+	  will be called fsl-dcp.
+
diff --git a/drivers/staging/crypto/Makefile b/drivers/staging/crypto/Makefile
new file mode 100644
index 0000000..06eabdf
--- /dev/null
+++ b/drivers/staging/crypto/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_CRYPTO_DEV_FSL_DCP) += fsl-dcp.o
diff --git a/drivers/staging/crypto/fsl-dcp.c b/drivers/staging/crypto/fsl-dcp.c
new file mode 100644
index 0000000..013cf64
--- /dev/null
+++ b/drivers/staging/crypto/fsl-dcp.c
@@ -0,0 +1,1817 @@
+/*
+ * Copyright (C) 2008-2010 Freescale Semiconductor, Inc.
+ */
+/*
+ * adapted to Kernel version 3.7 by Christoph G. Baumann <cgb at debian.org>
+ */
+/*
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+/*
+ * Based on geode-aes.c
+ * Copyright (C) 2004-2006, Advanced Micro Devices, Inc.
+ */
+
+#include <linux/slab.h>
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/errno.h>
+#include <linux/bitops.h>
+#include <linux/crypto.h>
+#include <linux/spinlock.h>
+#include <linux/miscdevice.h>
+#include <linux/platform_device.h>
+#include <linux/err.h>
+#include <linux/sysfs.h>
+#include <linux/fs.h>
+#include <crypto/algapi.h>
+#include <crypto/aes.h>
+#include <crypto/sha.h>
+#include <crypto/hash.h>
+#include <crypto/internal/hash.h>
+#include <linux/dma-mapping.h>
+#include <linux/interrupt.h>
+#include <linux/delay.h>
+#include <linux/uaccess.h>
+#include <linux/clk.h>
+#include <linux/io.h>
+#include <linux/delay.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_device.h>
+
+#include <asm/cacheflush.h>
+#include <mach/hardware.h>
+#include <linux/fsl/fsl-dcp_bootstream_ioctl.h>
+#include "fsl-dcp.h"
+
+/* Following data only used by DCP bootstream interface */
+struct dcpboot_dma_area {
+	struct dcp_hw_packet hw_packet;
+	uint16_t block[16];
+};
+
+struct dcp {
+	struct device *dev;
+	spinlock_t lock;
+	struct mutex op_mutex[DCP_NUM_CHANNELS];
+	struct completion op_wait[DCP_NUM_CHANNELS];
+	int wait[DCP_NUM_CHANNELS];
+	int dcp_vmi_irq;
+	int dcp_irq;
+	u32 dcp_regs_base;
+	ulong clock_state;
+	bool chan_in_use[DCP_NUM_CHANNELS];
+
+	/* Following buffers used in hashing to meet 64-byte len alignment */
+	char *buf1;
+	char *buf2;
+	dma_addr_t buf1_phys;
+	dma_addr_t buf2_phys;
+	struct dcp_hash_coherent_block *buf1_desc;
+	struct dcp_hash_coherent_block *buf2_desc;
+	struct dcp_hash_coherent_block *user_buf_desc;
+
+	/* Following data only used by DCP bootstream interface */
+	struct dcpboot_dma_area *dcpboot_dma_area;
+	dma_addr_t dcpboot_dma_area_phys;
+};
+
+/* cipher flags */
+#define DCP_ENC	0x0001
+#define DCP_DEC	0x0002
+#define DCP_ECB	0x0004
+#define DCP_CBC	0x0008
+#define DCP_CBC_INIT	0x0010
+#define DCP_OTPKEY	0x0020
+
+/* hash flags */
+#define DCP_INIT	0x0001
+#define DCP_UPDATE	0x0002
+#define DCP_FINAL	0x0004
+
+#define DCP_AES	0x1000
+#define DCP_SHA1	0x2000
+#define DCP_CRC32	0x3000
+#define DCP_COPY	0x4000
+#define DCP_FILL	0x5000
+#define DCP_MODE_MASK	0xf000
+
+/* clock defines */
+#define CLOCK_ON	1
+#define CLOCK_OFF	0
+
+struct dcp_op {
+
+	unsigned int flags;
+
+	void *src;
+	dma_addr_t src_phys;
+
+	void *dst;
+	dma_addr_t dst_phys;
+
+	int len;
+
+	/* the key contains the IV for block modes */
+	union {
+		struct {
+			u8 key[2 * AES_KEYSIZE_128]
+			    __attribute__ ((__aligned__(32)));
+			dma_addr_t key_phys;
+			int keylen;
+		} cipher;
+		struct {
+			u8 digest[SHA256_DIGEST_SIZE]
+			    __attribute__ ((__aligned__(32)));
+			dma_addr_t digest_phys;
+			int digestlen;
+			int init;
+		} hash;
+	};
+
+	union {
+		struct crypto_blkcipher *blk;
+		struct crypto_cipher *cip;
+		struct crypto_hash *hash;
+	} fallback;
+
+	struct dcp_hw_packet pkt __attribute__ ((__aligned__(32)));
+};
+
+struct dcp_hash_coherent_block {
+	struct dcp_hw_packet pkt[1]
+	    __attribute__ ((__aligned__(32)));
+	u8 digest[SHA256_DIGEST_SIZE]
+	    __attribute__ ((__aligned__(32)));
+	unsigned int len;
+	dma_addr_t src_phys;
+	void *src;
+	void *dst;
+	dma_addr_t my_phys;
+	u32 hash_sel;
+	struct dcp_hash_coherent_block *next;
+};
+
+struct dcp_hash_op {
+
+	unsigned int flags;
+
+	/* the key contains the IV for block modes */
+	union {
+		struct {
+			u8 key[2 * AES_KEYSIZE_128]
+			    __attribute__ ((__aligned__(32)));
+			dma_addr_t key_phys;
+			int keylen;
+		} cipher;
+		struct {
+			u8 digest[SHA256_DIGEST_SIZE]
+			    __attribute__ ((__aligned__(32)));
+			dma_addr_t digest_phys;
+			int digestlen;
+			int init;
+		} hash;
+	};
+
+	u32 length;
+	struct dcp_hash_coherent_block *head_desc;
+	struct dcp_hash_coherent_block *tail_desc;
+};
+
+/* only one */
+static struct dcp *global_sdcp;
+
+static void dcp_clock(struct dcp *sdcp, ulong state, bool force)
+{
+	u32 chan;
+	struct clk *clk = clk_get(sdcp->dev, "dcp_clk");
+
+	/* unless force is true (used during suspend/resume), if any
+	 * channel is running, then clk is already on, and must stay on */
+	if (!force)
+		for (chan = 0; chan < DCP_NUM_CHANNELS; chan++)
+			if (sdcp->chan_in_use[chan])
+				goto exit;
+
+	if (state == CLOCK_OFF) {
+		/* gate at clock source */
+		if (!IS_ERR(clk))
+			clk_disable(clk);
+		/* gate at DCP */
+		else
+			__raw_writel(BM_DCP_CTRL_CLKGATE,
+				     (volatile void *)(sdcp->dcp_regs_base +
+						       HW_DCP_CTRL_SET));
+
+		sdcp->clock_state = CLOCK_OFF;
+
+	} else {
+		/* ungate at clock source */
+		if (!IS_ERR(clk))
+			clk_enable(clk);
+		/* ungate at DCP */
+		else
+			__raw_writel(BM_DCP_CTRL_CLKGATE,
+				     (volatile void *)(sdcp->dcp_regs_base +
+						       HW_DCP_CTRL_CLR));
+
+		sdcp->clock_state = CLOCK_ON;
+	}
+
+ exit:
+	return;
+}
+
+static void dcp_perform_op(struct dcp_op *op)
+{
+	struct dcp *sdcp = global_sdcp;
+	struct mutex *mutex;
+	struct dcp_hw_packet *pkt;
+	int chan;
+	u32 pkt1, pkt2;
+	unsigned long timeout;
+	dma_addr_t pkt_phys;
+	u32 stat;
+
+	pkt1 = BM_DCP_PACKET1_DECR_SEMAPHORE | BM_DCP_PACKET1_INTERRUPT;
+
+	switch (op->flags & DCP_MODE_MASK) {
+
+	case DCP_AES:
+
+		chan = CIPHER_CHAN;
+
+		/* key is at the payload */
+		pkt1 |= BM_DCP_PACKET1_ENABLE_CIPHER;
+		if ((op->flags & DCP_OTPKEY) == 0)
+			pkt1 |= BM_DCP_PACKET1_PAYLOAD_KEY;
+		if (op->flags & DCP_ENC)
+			pkt1 |= BM_DCP_PACKET1_CIPHER_ENCRYPT;
+		if (op->flags & DCP_CBC_INIT)
+			pkt1 |= BM_DCP_PACKET1_CIPHER_INIT;
+
+		pkt2 = BF(0, DCP_PACKET2_CIPHER_CFG) |
+		    BF(0, DCP_PACKET2_KEY_SELECT) |
+		    BF(BV_DCP_PACKET2_CIPHER_SELECT__AES128,
+		       DCP_PACKET2_CIPHER_SELECT);
+
+		if (op->flags & DCP_ECB)
+			pkt2 |= BF(BV_DCP_PACKET2_CIPHER_MODE__ECB,
+				   DCP_PACKET2_CIPHER_MODE);
+		else if (op->flags & DCP_CBC)
+			pkt2 |= BF(BV_DCP_PACKET2_CIPHER_MODE__CBC,
+				   DCP_PACKET2_CIPHER_MODE);
+
+		break;
+
+	case DCP_SHA1:
+
+		chan = HASH_CHAN;
+
+		pkt1 |= BM_DCP_PACKET1_ENABLE_HASH;
+		if (op->flags & DCP_INIT)
+			pkt1 |= BM_DCP_PACKET1_HASH_INIT;
+		if (op->flags & DCP_FINAL) {
+			pkt1 |= BM_DCP_PACKET1_HASH_TERM;
+			BUG_ON(op->hash.digest == NULL);
+		}
+
+		pkt2 = BF(BV_DCP_PACKET2_HASH_SELECT__SHA1,
+			  DCP_PACKET2_HASH_SELECT);
+		break;
+
+	default:
+		dev_err(sdcp->dev, "Unsupported mode\n");
+		return;
+	}
+
+	mutex = &sdcp->op_mutex[chan];
+	pkt = &op->pkt;
+
+	pkt->pNext = 0;
+	pkt->pkt1 = pkt1;
+	pkt->pkt2 = pkt2;
+	pkt->pSrc = (u32) op->src_phys;
+	pkt->pDst = (u32) op->dst_phys;
+	pkt->size = op->len;
+	pkt->pPayload = chan == CIPHER_CHAN ?
+	    (u32) op->cipher.key_phys : (u32) op->hash.digest_phys;
+	pkt->stat = 0;
+
+	pkt_phys = dma_map_single(sdcp->dev, pkt, sizeof(*pkt),
+				  DMA_BIDIRECTIONAL);
+	if (dma_mapping_error(sdcp->dev, pkt_phys)) {
+		dev_err(sdcp->dev, "Unable to map packet descriptor\n");
+		return;
+	}
+
+	/* submit the work */
+	mutex_lock(mutex);
+	dcp_clock(sdcp, CLOCK_ON, false);
+	sdcp->chan_in_use[chan] = true;
+
+	__raw_writel(-1,
+		     (volatile void *)(sdcp->dcp_regs_base +
+				       HW_DCP_CHnSTAT_CLR(chan)));
+
+	/* Load the work packet pointer and bump the channel semaphore */
+	__raw_writel((u32) pkt_phys, (volatile void *)(sdcp->dcp_regs_base +
+						       HW_DCP_CHnCMDPTR(chan)));
+
+	/* XXX wake from interrupt instead of looping */
+	timeout = jiffies + msecs_to_jiffies(1000);
+
+	sdcp->wait[chan] = 0;
+	__raw_writel(BF(1, DCP_CHnSEMA_INCREMENT),
+		     (volatile void *)(sdcp->dcp_regs_base +
+				       HW_DCP_CHnSEMA(chan)));
+	while (time_before(jiffies, timeout) && sdcp->wait[chan] == 0)
+		cpu_relax();
+
+	if (!time_before(jiffies, timeout)) {
+		dev_err(sdcp->dev, "Timeout while waiting STAT 0x%08x\n",
+			__raw_readl((volatile void *)(sdcp->dcp_regs_base +
+						      HW_DCP_STAT)));
+		goto out;
+	}
+
+	stat =
+	    __raw_readl((volatile void *)(sdcp->dcp_regs_base +
+					  HW_DCP_CHnSTAT(chan)));
+	if ((stat & 0xff) != 0)
+		dev_err(sdcp->dev, "Channel stat error 0x%02x\n",
+			__raw_readl((volatile void *)(sdcp->dcp_regs_base +
+						      (HW_DCP_CHnSTAT(chan) &
+						       0xff))));
+ out:
+	sdcp->chan_in_use[chan] = false;
+	dcp_clock(sdcp, CLOCK_OFF, false);
+	mutex_unlock(mutex);
+	dma_unmap_single(sdcp->dev, pkt_phys, sizeof(*pkt), DMA_TO_DEVICE);
+}
+
+static int dcp_aes_setkey_cip(struct crypto_tfm *tfm, const u8 *key,
+			      unsigned int len)
+{
+	struct dcp_op *op = crypto_tfm_ctx(tfm);
+	unsigned int ret;
+
+	op->cipher.keylen = len;
+
+	if (len == AES_KEYSIZE_128) {
+		memcpy(op->cipher.key, key, len);
+		return 0;
+	}
+
+	if (len != AES_KEYSIZE_192 && len != AES_KEYSIZE_256) {
+		/* not supported at all */
+		tfm->crt_flags |= CRYPTO_TFM_RES_BAD_KEY_LEN;
+		return -EINVAL;
+	}
+
+	/*
+	 * The requested key size is not supported by HW, do a fallback
+	 */
+	op->fallback.blk->base.crt_flags &= ~CRYPTO_TFM_REQ_MASK;
+	op->fallback.blk->base.crt_flags |= (tfm->crt_flags &
+					     CRYPTO_TFM_REQ_MASK);
+
+	ret = crypto_cipher_setkey(op->fallback.cip, key, len);
+	if (ret) {
+		tfm->crt_flags &= ~CRYPTO_TFM_RES_MASK;
+		tfm->crt_flags |= (op->fallback.blk->base.crt_flags &
+				   CRYPTO_TFM_RES_MASK);
+	}
+	return ret;
+}
+
+static void dcp_aes_encrypt(struct crypto_tfm *tfm, u8 *out, const u8 *in)
+{
+	struct dcp *sdcp = global_sdcp;
+	struct dcp_op *op = crypto_tfm_ctx(tfm);
+
+	if (unlikely(op->cipher.keylen != AES_KEYSIZE_128)) {
+		crypto_cipher_encrypt_one(op->fallback.cip, out, in);
+		return;
+	}
+
+	op->src = (void *)in;
+	op->dst = (void *)out;
+	op->flags = DCP_AES | DCP_ENC | DCP_ECB;
+	op->len = AES_KEYSIZE_128;
+
+	/* map the data */
+	op->src_phys = dma_map_single(sdcp->dev, (void *)in, AES_KEYSIZE_128,
+				      DMA_TO_DEVICE);
+	if (dma_mapping_error(sdcp->dev, op->src_phys)) {
+		dev_err(sdcp->dev, "Unable to map source\n");
+		return;
+	}
+
+	op->dst_phys = dma_map_single(sdcp->dev, out, AES_KEYSIZE_128,
+				      DMA_FROM_DEVICE);
+	if (dma_mapping_error(sdcp->dev, op->dst_phys)) {
+		dev_err(sdcp->dev, "Unable to map dest\n");
+		goto err_unmap_src;
+	}
+
+	op->cipher.key_phys = dma_map_single(sdcp->dev, op->cipher.key,
+					     AES_KEYSIZE_128, DMA_TO_DEVICE);
+	if (dma_mapping_error(sdcp->dev, op->cipher.key_phys)) {
+		dev_err(sdcp->dev, "Unable to map key\n");
+		goto err_unmap_dst;
+	}
+
+	/* perform the operation */
+	dcp_perform_op(op);
+
+	dma_unmap_single(sdcp->dev, op->cipher.key_phys, AES_KEYSIZE_128,
+			 DMA_TO_DEVICE);
+ err_unmap_dst:
+	dma_unmap_single(sdcp->dev, op->dst_phys, op->len, DMA_FROM_DEVICE);
+ err_unmap_src:
+	dma_unmap_single(sdcp->dev, op->src_phys, op->len, DMA_TO_DEVICE);
+}
+
+static void dcp_aes_decrypt(struct crypto_tfm *tfm, u8 *out, const u8 *in)
+{
+	struct dcp *sdcp = global_sdcp;
+	struct dcp_op *op = crypto_tfm_ctx(tfm);
+
+	if (unlikely(op->cipher.keylen != AES_KEYSIZE_128)) {
+		crypto_cipher_decrypt_one(op->fallback.cip, out, in);
+		return;
+	}
+
+	op->src = (void *)in;
+	op->dst = (void *)out;
+	op->flags = DCP_AES | DCP_DEC | DCP_ECB;
+	op->len = AES_KEYSIZE_128;
+
+	/* map the data */
+	op->src_phys = dma_map_single(sdcp->dev, (void *)in, AES_KEYSIZE_128,
+				      DMA_TO_DEVICE);
+	if (dma_mapping_error(sdcp->dev, op->src_phys)) {
+		dev_err(sdcp->dev, "Unable to map source\n");
+		return;
+	}
+
+	op->dst_phys = dma_map_single(sdcp->dev, out, AES_KEYSIZE_128,
+				      DMA_FROM_DEVICE);
+	if (dma_mapping_error(sdcp->dev, op->dst_phys)) {
+		dev_err(sdcp->dev, "Unable to map dest\n");
+		goto err_unmap_src;
+	}
+
+	op->cipher.key_phys = dma_map_single(sdcp->dev, op->cipher.key,
+					     AES_KEYSIZE_128, DMA_TO_DEVICE);
+	if (dma_mapping_error(sdcp->dev, op->cipher.key_phys)) {
+		dev_err(sdcp->dev, "Unable to map key\n");
+		goto err_unmap_dst;
+	}
+
+	/* perform the operation */
+	dcp_perform_op(op);
+
+	dma_unmap_single(sdcp->dev, op->cipher.key_phys, AES_KEYSIZE_128,
+			 DMA_TO_DEVICE);
+ err_unmap_dst:
+	dma_unmap_single(sdcp->dev, op->dst_phys, op->len, DMA_FROM_DEVICE);
+ err_unmap_src:
+	dma_unmap_single(sdcp->dev, op->src_phys, op->len, DMA_TO_DEVICE);
+}
+
+static int fallback_init_cip(struct crypto_tfm *tfm)
+{
+	const char *name = tfm->__crt_alg->cra_name;
+	struct dcp_op *op = crypto_tfm_ctx(tfm);
+
+	op->fallback.cip = crypto_alloc_cipher(name, 0,
+					       CRYPTO_ALG_ASYNC |
+					       CRYPTO_ALG_NEED_FALLBACK);
+
+	if (IS_ERR(op->fallback.cip)) {
+		printk(KERN_ERR "Error allocating fallback algo %s\n", name);
+		return PTR_ERR(op->fallback.cip);
+	}
+
+	return 0;
+}
+
+static void fallback_exit_cip(struct crypto_tfm *tfm)
+{
+	struct dcp_op *op = crypto_tfm_ctx(tfm);
+
+	crypto_free_cipher(op->fallback.cip);
+	op->fallback.cip = NULL;
+}
+
+static struct crypto_alg dcp_aes_alg = {
+	.cra_name = "aes",
+	.cra_driver_name = "dcp-aes",
+	.cra_priority = 300,
+	.cra_alignmask = 15,
+	.cra_flags = CRYPTO_ALG_TYPE_CIPHER | CRYPTO_ALG_NEED_FALLBACK,
+	.cra_init = fallback_init_cip,
+	.cra_exit = fallback_exit_cip,
+	.cra_blocksize = AES_KEYSIZE_128,
+	.cra_ctxsize = sizeof(struct dcp_op),
+	.cra_module = THIS_MODULE,
+	.cra_list = LIST_HEAD_INIT(dcp_aes_alg.cra_list),
+	.cra_u = {
+		  .cipher = {
+			     .cia_min_keysize = AES_MIN_KEY_SIZE,
+			     .cia_max_keysize = AES_MAX_KEY_SIZE,
+			     .cia_setkey = dcp_aes_setkey_cip,
+			     .cia_encrypt = dcp_aes_encrypt,
+			     .cia_decrypt = dcp_aes_decrypt}
+		  }
+};
+
+static int dcp_aes_setkey_blk(struct crypto_tfm *tfm, const u8 *key,
+			      unsigned int len)
+{
+	struct dcp_op *op = crypto_tfm_ctx(tfm);
+	unsigned int ret;
+
+	op->cipher.keylen = len;
+
+	if (len == AES_KEYSIZE_128) {
+		memcpy(op->cipher.key, key, len);
+		return 0;
+	}
+
+	if (len != AES_KEYSIZE_192 && len != AES_KEYSIZE_256) {
+		/* not supported at all */
+		tfm->crt_flags |= CRYPTO_TFM_RES_BAD_KEY_LEN;
+		return -EINVAL;
+	}
+
+	/*
+	 * The requested key size is not supported by HW, do a fallback
+	 */
+	op->fallback.blk->base.crt_flags &= ~CRYPTO_TFM_REQ_MASK;
+	op->fallback.blk->base.crt_flags |= (tfm->crt_flags &
+					     CRYPTO_TFM_REQ_MASK);
+
+	ret = crypto_blkcipher_setkey(op->fallback.blk, key, len);
+	if (ret) {
+		tfm->crt_flags &= ~CRYPTO_TFM_RES_MASK;
+		tfm->crt_flags |= (op->fallback.blk->base.crt_flags &
+				   CRYPTO_TFM_RES_MASK);
+	}
+	return ret;
+}
+
+static int fallback_blk_dec(struct blkcipher_desc *desc,
+			    struct scatterlist *dst, struct scatterlist *src,
+			    unsigned int nbytes)
+{
+	unsigned int ret;
+	struct crypto_blkcipher *tfm;
+	struct dcp_op *op = crypto_blkcipher_ctx(desc->tfm);
+
+	tfm = desc->tfm;
+	desc->tfm = op->fallback.blk;
+
+	ret = crypto_blkcipher_decrypt_iv(desc, dst, src, nbytes);
+
+	desc->tfm = tfm;
+	return ret;
+}
+
+static int fallback_blk_enc(struct blkcipher_desc *desc,
+			    struct scatterlist *dst, struct scatterlist *src,
+			    unsigned int nbytes)
+{
+	unsigned int ret;
+	struct crypto_blkcipher *tfm;
+	struct dcp_op *op = crypto_blkcipher_ctx(desc->tfm);
+
+	tfm = desc->tfm;
+	desc->tfm = op->fallback.blk;
+
+	ret = crypto_blkcipher_encrypt_iv(desc, dst, src, nbytes);
+
+	desc->tfm = tfm;
+	return ret;
+}
+
+static int fallback_init_blk(struct crypto_tfm *tfm)
+{
+	const char *name = tfm->__crt_alg->cra_name;
+	struct dcp_op *op = crypto_tfm_ctx(tfm);
+
+	op->fallback.blk = crypto_alloc_blkcipher(name, 0,
+						  CRYPTO_ALG_ASYNC |
+						  CRYPTO_ALG_NEED_FALLBACK);
+
+	if (IS_ERR(op->fallback.blk)) {
+		printk(KERN_ERR "Error allocating fallback algo %s\n", name);
+		return PTR_ERR(op->fallback.blk);
+	}
+
+	return 0;
+}
+
+static void fallback_exit_blk(struct crypto_tfm *tfm)
+{
+	struct dcp_op *op = crypto_tfm_ctx(tfm);
+
+	crypto_free_blkcipher(op->fallback.blk);
+	op->fallback.blk = NULL;
+}
+
+static int
+dcp_aes_ecb_decrypt(struct blkcipher_desc *desc,
+		    struct scatterlist *dst, struct scatterlist *src,
+		    unsigned int nbytes)
+{
+	struct dcp *sdcp = global_sdcp;
+	struct dcp_op *op = crypto_blkcipher_ctx(desc->tfm);
+	struct blkcipher_walk walk;
+	int err;
+
+	if (unlikely(op->cipher.keylen != AES_KEYSIZE_128))
+		return fallback_blk_dec(desc, dst, src, nbytes);
+
+	blkcipher_walk_init(&walk, dst, src, nbytes);
+
+	/* key needs to be mapped only once */
+	op->cipher.key_phys = dma_map_single(sdcp->dev, op->cipher.key,
+					     AES_KEYSIZE_128, DMA_TO_DEVICE);
+	if (dma_mapping_error(sdcp->dev, op->cipher.key_phys)) {
+		dev_err(sdcp->dev, "Unable to map key\n");
+		return -ENOMEM;
+	}
+
+	err = blkcipher_walk_virt(desc, &walk);
+	while (err == 0 && (nbytes = walk.nbytes) > 0) {
+		op->src = walk.src.virt.addr, op->dst = walk.dst.virt.addr;
+		op->flags = DCP_AES | DCP_DEC | DCP_ECB;
+		op->len = nbytes - (nbytes % AES_KEYSIZE_128);
+
+		/* map the data */
+		op->src_phys = dma_map_single(sdcp->dev, op->src, op->len,
+					      DMA_TO_DEVICE);
+		if (dma_mapping_error(sdcp->dev, op->src_phys)) {
+			dev_err(sdcp->dev, "Unable to map source\n");
+			err = -ENOMEM;
+			break;
+		}
+
+		op->dst_phys = dma_map_single(sdcp->dev, op->dst, op->len,
+					      DMA_FROM_DEVICE);
+		if (dma_mapping_error(sdcp->dev, op->dst_phys)) {
+			dma_unmap_single(sdcp->dev, op->src_phys, op->len,
+					 DMA_TO_DEVICE);
+			dev_err(sdcp->dev, "Unable to map dest\n");
+			err = -ENOMEM;
+			break;
+		}
+
+		/* perform! */
+		dcp_perform_op(op);
+
+		dma_unmap_single(sdcp->dev, op->dst_phys, op->len,
+				 DMA_FROM_DEVICE);
+		dma_unmap_single(sdcp->dev, op->src_phys, op->len,
+				 DMA_TO_DEVICE);
+
+		nbytes -= op->len;
+		err = blkcipher_walk_done(desc, &walk, nbytes);
+	}
+
+	dma_unmap_single(sdcp->dev, op->cipher.key_phys, AES_KEYSIZE_128,
+			 DMA_TO_DEVICE);
+
+	return err;
+}
+
+static int
+dcp_aes_ecb_encrypt(struct blkcipher_desc *desc,
+		    struct scatterlist *dst, struct scatterlist *src,
+		    unsigned int nbytes)
+{
+	struct dcp *sdcp = global_sdcp;
+	struct dcp_op *op = crypto_blkcipher_ctx(desc->tfm);
+	struct blkcipher_walk walk;
+	int err, ret;
+
+	if (unlikely(op->cipher.keylen != AES_KEYSIZE_128))
+		return fallback_blk_enc(desc, dst, src, nbytes);
+
+	blkcipher_walk_init(&walk, dst, src, nbytes);
+
+	/* key needs to be mapped only once */
+	op->cipher.key_phys = dma_map_single(sdcp->dev, op->cipher.key,
+					     AES_KEYSIZE_128, DMA_TO_DEVICE);
+	if (dma_mapping_error(sdcp->dev, op->cipher.key_phys)) {
+		dev_err(sdcp->dev, "Unable to map key\n");
+		return -ENOMEM;
+	}
+
+	err = blkcipher_walk_virt(desc, &walk);
+
+	err = 0;
+	while (err == 0 && (nbytes = walk.nbytes) > 0) {
+		op->src = walk.src.virt.addr, op->dst = walk.dst.virt.addr;
+		op->flags = DCP_AES | DCP_ENC | DCP_ECB;
+		op->len = nbytes - (nbytes % AES_KEYSIZE_128);
+
+		/* map the data */
+		op->src_phys = dma_map_single(sdcp->dev, op->src, op->len,
+					      DMA_TO_DEVICE);
+		if (dma_mapping_error(sdcp->dev, op->src_phys)) {
+			dev_err(sdcp->dev, "Unable to map source\n");
+			err = -ENOMEM;
+			break;
+		}
+
+		op->dst_phys = dma_map_single(sdcp->dev, op->dst, op->len,
+					      DMA_FROM_DEVICE);
+		if (dma_mapping_error(sdcp->dev, op->dst_phys)) {
+			dma_unmap_single(sdcp->dev, op->src_phys, op->len,
+					 DMA_TO_DEVICE);
+			dev_err(sdcp->dev, "Unable to map dest\n");
+			err = -ENOMEM;
+			break;
+		}
+
+		/* perform! */
+		dcp_perform_op(op);
+
+		dma_unmap_single(sdcp->dev, op->dst_phys, op->len,
+				 DMA_FROM_DEVICE);
+		dma_unmap_single(sdcp->dev, op->src_phys, op->len,
+				 DMA_TO_DEVICE);
+
+		nbytes -= op->len;
+		ret = blkcipher_walk_done(desc, &walk, nbytes);
+	}
+
+	dma_unmap_single(sdcp->dev, op->cipher.key_phys, AES_KEYSIZE_128,
+			 DMA_TO_DEVICE);
+
+	return err;
+}
+
+static struct crypto_alg dcp_aes_ecb_alg = {
+	.cra_name = "ecb(aes)",
+	.cra_driver_name = "dcp-ecb-aes",
+	.cra_priority = 400,
+	.cra_alignmask = 15,
+	.cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER | CRYPTO_ALG_NEED_FALLBACK,
+	.cra_init = fallback_init_blk,
+	.cra_exit = fallback_exit_blk,
+	.cra_blocksize = AES_KEYSIZE_128,
+	.cra_ctxsize = sizeof(struct dcp_op),
+	.cra_type = &crypto_blkcipher_type,
+	.cra_module = THIS_MODULE,
+	.cra_list = LIST_HEAD_INIT(dcp_aes_ecb_alg.cra_list),
+	.cra_u = {
+		  .blkcipher = {
+				.min_keysize = AES_MIN_KEY_SIZE,
+				.max_keysize = AES_MAX_KEY_SIZE,
+				.setkey = dcp_aes_setkey_blk,
+				.encrypt = dcp_aes_ecb_encrypt,
+				.decrypt = dcp_aes_ecb_decrypt}
+		  }
+};
+
+static int
+dcp_aes_cbc_decrypt(struct blkcipher_desc *desc,
+		    struct scatterlist *dst, struct scatterlist *src,
+		    unsigned int nbytes)
+{
+	struct dcp *sdcp = global_sdcp;
+	struct dcp_op *op = crypto_blkcipher_ctx(desc->tfm);
+	struct blkcipher_walk walk;
+	int err, blockno;
+
+	if (unlikely(op->cipher.keylen != AES_KEYSIZE_128))
+		return fallback_blk_dec(desc, dst, src, nbytes);
+
+	blkcipher_walk_init(&walk, dst, src, nbytes);
+
+	blockno = 0;
+	err = blkcipher_walk_virt(desc, &walk);
+	while (err == 0 && (nbytes = walk.nbytes) > 0) {
+		op->src = walk.src.virt.addr, op->dst = walk.dst.virt.addr;
+		op->flags = DCP_AES | DCP_DEC | DCP_CBC;
+		if (blockno == 0) {
+			op->flags |= DCP_CBC_INIT;
+			memcpy(op->cipher.key + AES_KEYSIZE_128, walk.iv,
+			       AES_KEYSIZE_128);
+		}
+		op->len = nbytes - (nbytes % AES_KEYSIZE_128);
+
+		/* key (+iv) needs to be mapped only once */
+		op->cipher.key_phys = dma_map_single(sdcp->dev, op->cipher.key,
+						     AES_KEYSIZE_128 * 2,
+						     DMA_BIDIRECTIONAL);
+		if (dma_mapping_error(sdcp->dev, op->cipher.key_phys)) {
+			dev_err(sdcp->dev, "Unable to map key\n");
+			err = -ENOMEM;
+			break;
+		}
+
+		/* map the data */
+		op->src_phys = dma_map_single(sdcp->dev, op->src, op->len,
+					      DMA_TO_DEVICE);
+		if (dma_mapping_error(sdcp->dev, op->src_phys)) {
+			dma_unmap_single(sdcp->dev, op->cipher.key_phys,
+					 AES_KEYSIZE_128 * 2,
+					 DMA_BIDIRECTIONAL);
+			dev_err(sdcp->dev, "Unable to map source\n");
+			err = -ENOMEM;
+			break;
+		}
+
+		op->dst_phys = dma_map_single(sdcp->dev, op->dst, op->len,
+					      DMA_FROM_DEVICE);
+		if (dma_mapping_error(sdcp->dev, op->dst_phys)) {
+			dma_unmap_single(sdcp->dev, op->cipher.key_phys,
+					 AES_KEYSIZE_128 * 2,
+					 DMA_BIDIRECTIONAL);
+			dma_unmap_single(sdcp->dev, op->src_phys, op->len,
+					 DMA_TO_DEVICE);
+			dev_err(sdcp->dev, "Unable to map dest\n");
+			err = -ENOMEM;
+			break;
+		}
+
+		/* perform! */
+		dcp_perform_op(op);
+
+		dma_unmap_single(sdcp->dev, op->cipher.key_phys,
+				 AES_KEYSIZE_128 * 2, DMA_BIDIRECTIONAL);
+		dma_unmap_single(sdcp->dev, op->dst_phys, op->len,
+				 DMA_FROM_DEVICE);
+		dma_unmap_single(sdcp->dev, op->src_phys, op->len,
+				 DMA_TO_DEVICE);
+
+		nbytes -= op->len;
+		err = blkcipher_walk_done(desc, &walk, nbytes);
+
+		blockno++;
+	}
+
+	return err;
+}
+
+static int
+dcp_aes_cbc_encrypt(struct blkcipher_desc *desc,
+		    struct scatterlist *dst, struct scatterlist *src,
+		    unsigned int nbytes)
+{
+	struct dcp *sdcp = global_sdcp;
+	struct dcp_op *op = crypto_blkcipher_ctx(desc->tfm);
+	struct blkcipher_walk walk;
+	int err, ret, blockno;
+
+	if (unlikely(op->cipher.keylen != AES_KEYSIZE_128))
+		return fallback_blk_enc(desc, dst, src, nbytes);
+
+	blkcipher_walk_init(&walk, dst, src, nbytes);
+
+	blockno = 0;
+
+	err = blkcipher_walk_virt(desc, &walk);
+	while (err == 0 && (nbytes = walk.nbytes) > 0) {
+		op->src = walk.src.virt.addr, op->dst = walk.dst.virt.addr;
+		op->flags = DCP_AES | DCP_ENC | DCP_CBC;
+		if (blockno == 0) {
+			op->flags |= DCP_CBC_INIT;
+			memcpy(op->cipher.key + AES_KEYSIZE_128, walk.iv,
+			       AES_KEYSIZE_128);
+		}
+		op->len = nbytes - (nbytes % AES_KEYSIZE_128);
+
+		/* key needs to be mapped only once */
+		op->cipher.key_phys = dma_map_single(sdcp->dev, op->cipher.key,
+						     AES_KEYSIZE_128 * 2,
+						     DMA_BIDIRECTIONAL);
+		if (dma_mapping_error(sdcp->dev, op->cipher.key_phys)) {
+			dev_err(sdcp->dev, "Unable to map key\n");
+			return -ENOMEM;
+		}
+
+		/* map the data */
+		op->src_phys = dma_map_single(sdcp->dev, op->src, op->len,
+					      DMA_TO_DEVICE);
+		if (dma_mapping_error(sdcp->dev, op->src_phys)) {
+			dma_unmap_single(sdcp->dev, op->cipher.key_phys,
+					 AES_KEYSIZE_128 * 2,
+					 DMA_BIDIRECTIONAL);
+			dev_err(sdcp->dev, "Unable to map source\n");
+			err = -ENOMEM;
+			break;
+		}
+
+		op->dst_phys = dma_map_single(sdcp->dev, op->dst, op->len,
+					      DMA_FROM_DEVICE);
+		if (dma_mapping_error(sdcp->dev, op->dst_phys)) {
+			dma_unmap_single(sdcp->dev, op->cipher.key_phys,
+					 AES_KEYSIZE_128 * 2,
+					 DMA_BIDIRECTIONAL);
+			dma_unmap_single(sdcp->dev, op->src_phys, op->len,
+					 DMA_TO_DEVICE);
+			dev_err(sdcp->dev, "Unable to map dest\n");
+			err = -ENOMEM;
+			break;
+		}
+
+		/* perform! */
+		dcp_perform_op(op);
+
+		dma_unmap_single(sdcp->dev, op->cipher.key_phys,
+				 AES_KEYSIZE_128 * 2, DMA_BIDIRECTIONAL);
+		dma_unmap_single(sdcp->dev, op->dst_phys, op->len,
+				 DMA_FROM_DEVICE);
+		dma_unmap_single(sdcp->dev, op->src_phys, op->len,
+				 DMA_TO_DEVICE);
+
+		nbytes -= op->len;
+		ret = blkcipher_walk_done(desc, &walk, nbytes);
+
+		blockno++;
+	}
+
+	return err;
+}
+
+static struct crypto_alg dcp_aes_cbc_alg = {
+	.cra_name = "cbc(aes)",
+	.cra_driver_name = "dcp-cbc-aes",
+	.cra_priority = 400,
+	.cra_alignmask = 15,
+	.cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER | CRYPTO_ALG_NEED_FALLBACK,
+	.cra_init = fallback_init_blk,
+	.cra_exit = fallback_exit_blk,
+	.cra_blocksize = AES_KEYSIZE_128,
+	.cra_ctxsize = sizeof(struct dcp_op),
+	.cra_type = &crypto_blkcipher_type,
+	.cra_module = THIS_MODULE,
+	.cra_list = LIST_HEAD_INIT(dcp_aes_cbc_alg.cra_list),
+	.cra_u = {
+		  .blkcipher = {
+				.min_keysize = AES_MIN_KEY_SIZE,
+				.max_keysize = AES_MAX_KEY_SIZE,
+				.setkey = dcp_aes_setkey_blk,
+				.encrypt = dcp_aes_cbc_encrypt,
+				.decrypt = dcp_aes_cbc_decrypt,
+				.ivsize = AES_KEYSIZE_128,
+				}
+		  }
+};
+
+static int dcp_perform_hash_op(struct dcp_hash_coherent_block *input,
+			       u32 num_desc, bool init, bool terminate)
+{
+	struct dcp *sdcp = global_sdcp;
+	int chan;
+	struct dcp_hw_packet *pkt;
+	struct dcp_hash_coherent_block *hw;
+	unsigned long timeout;
+	u32 stat;
+	int descno, mapped;
+
+	chan = HASH_CHAN;
+
+	hw = input;
+	pkt = hw->pkt;
+
+	for (descno = 0; descno < num_desc; descno++) {
+
+		if (descno != 0) {
+
+			/* set next ptr and CHAIN bit in last packet */
+			pkt->pNext =
+			    hw->next->my_phys +
+			    offsetof(struct dcp_hash_coherent_block, pkt[0]);
+			pkt->pkt1 |= BM_DCP_PACKET1_CHAIN;
+
+			/* iterate to next descriptor */
+			hw = hw->next;
+			pkt = hw->pkt;
+		}
+
+		pkt->pkt1 = BM_DCP_PACKET1_DECR_SEMAPHORE |
+		    BM_DCP_PACKET1_ENABLE_HASH;
+
+		if (init && descno == 0)
+			pkt->pkt1 |= BM_DCP_PACKET1_HASH_INIT;
+
+		pkt->pkt2 = BF(hw->hash_sel, DCP_PACKET2_HASH_SELECT);
+
+		/* no need to flush buf1 or buf2, which are uncached */
+		if (hw->src != sdcp->buf1 && hw->src != sdcp->buf2) {
+
+			/* we have to flush the cache for the buffer */
+			hw->src_phys = dma_map_single(sdcp->dev,
+						      hw->src, hw->len,
+						      DMA_TO_DEVICE);
+
+			if (dma_mapping_error(sdcp->dev, hw->src_phys)) {
+				dev_err(sdcp->dev, "Unable to map source\n");
+
+				/* unmap any previous mapped buffers */
+				for (mapped = 0, hw = input; mapped < descno;
+				     mapped++) {
+
+					if (mapped != 0)
+						hw = hw->next;
+					if (hw->src != sdcp->buf1 &&
+					    hw->src != sdcp->buf2)
+						dma_unmap_single(sdcp->dev,
+								 hw->src_phys,
+								 hw->len,
+								 DMA_TO_DEVICE);
+				}
+
+				return -EFAULT;
+			}
+		}
+
+		pkt->pSrc = (u32) hw->src_phys;
+		pkt->pDst = 0;
+		pkt->size = hw->len;
+		pkt->pPayload = 0;
+		pkt->stat = 0;
+
+		/* set HASH_TERM bit on last buf if terminate was set */
+		if (terminate && (descno == (num_desc - 1))) {
+			pkt->pkt1 |= BM_DCP_PACKET1_HASH_TERM;
+
+			memset(input->digest, 0, sizeof(input->digest));
+
+			/* set payload ptr to the 1st buffer's digest */
+			pkt->pPayload = (u32) input->my_phys +
+			    offsetof(struct dcp_hash_coherent_block, digest);
+		}
+	}
+
+	/* submit the work */
+
+	__raw_writel(-1,
+		     (volatile void *)(sdcp->dcp_regs_base +
+				       HW_DCP_CHnSTAT_CLR(chan)));
+
+	mb();
+	/* Load the 1st descriptor's physical address */
+	__raw_writel((u32) input->my_phys +
+		     offsetof(struct dcp_hash_coherent_block,
+			      pkt[0]),
+		     (volatile void *)(sdcp->dcp_regs_base +
+				       HW_DCP_CHnCMDPTR(chan)));
+
+	/* XXX wake from interrupt instead of looping */
+	timeout = jiffies + msecs_to_jiffies(1000);
+
+	/* write num_desc into sema register */
+	__raw_writel(BF(num_desc, DCP_CHnSEMA_INCREMENT),
+		     (volatile void *)(sdcp->dcp_regs_base +
+				       HW_DCP_CHnSEMA(chan)));
+
+	while (time_before(jiffies, timeout)
+	       &&
+	       (__raw_readl
+		((volatile void *)(sdcp->dcp_regs_base +
+				   ((HW_DCP_CHnSEMA(chan) >> 16) & 0xff))) !=
+		0)) {
+		cpu_relax();
+	}
+
+	if (!time_before(jiffies, timeout)) {
+		dev_err(sdcp->dev,
+			"Timeout while waiting STAT 0x%08x\n",
+			__raw_readl((volatile void *)(sdcp->dcp_regs_base +
+						      HW_DCP_STAT)));
+	}
+
+	stat =
+	    __raw_readl((volatile void *)(sdcp->dcp_regs_base +
+					  HW_DCP_CHnSTAT(chan)));
+	if ((stat & 0xff) != 0)
+		dev_err(sdcp->dev, "Channel stat error 0x%02x\n",
+			__raw_readl((volatile void *)(sdcp->dcp_regs_base +
+						      (HW_DCP_CHnSTAT(chan) &
+						       0xff))));
+
+	/* unmap all src buffers */
+	for (descno = 0, hw = input; descno < num_desc; descno++) {
+		if (descno != 0)
+			hw = hw->next;
+		if (hw->src != sdcp->buf1 && hw->src != sdcp->buf2)
+			dma_unmap_single(sdcp->dev, hw->src_phys, hw->len,
+					 DMA_TO_DEVICE);
+	}
+
+	return 0;
+
+}
+
+static int dcp_sha_init(struct shash_desc *desc)
+{
+	struct dcp *sdcp = global_sdcp;
+	struct dcp_hash_op *op = shash_desc_ctx(desc);
+	struct mutex *mutex = &sdcp->op_mutex[HASH_CHAN];
+
+	mutex_lock(mutex);
+	dcp_clock(sdcp, CLOCK_ON, false);
+	sdcp->chan_in_use[HASH_CHAN] = true;
+
+	op->length = 0;
+
+	/* reset the lengths and the pointers of buffer descriptors */
+	sdcp->buf1_desc->len = 0;
+	sdcp->buf1_desc->src = sdcp->buf1;
+	sdcp->buf2_desc->len = 0;
+	sdcp->buf2_desc->src = sdcp->buf2;
+	op->head_desc = sdcp->buf1_desc;
+	op->tail_desc = sdcp->buf2_desc;
+
+	return 0;
+}
+
+static int dcp_sha_update(struct shash_desc *desc, const u8 *data,
+			  unsigned int length)
+{
+	struct dcp *sdcp = global_sdcp;
+	struct dcp_hash_op *op = shash_desc_ctx(desc);
+	struct dcp_hash_coherent_block *temp;
+	u32 rem_bytes, bytes_borrowed, hash_sel;
+	int ret = 0;
+
+	if (strcmp(desc->tfm->base.__crt_alg->cra_name, "sha1") == 0)
+		hash_sel = BV_DCP_PACKET2_HASH_SELECT__SHA1;
+	else
+		hash_sel = BV_DCP_PACKET2_HASH_SELECT__SHA256;
+
+	sdcp->user_buf_desc->src = (void *)data;
+	sdcp->user_buf_desc->len = length;
+
+	op->tail_desc->len = 0;
+
+	/* check if any pending data from previous updates */
+	if (op->head_desc->len) {
+
+		/* borrow from this buffer to make it 64 bytes */
+		bytes_borrowed = min(64 - op->head_desc->len,
+				     sdcp->user_buf_desc->len);
+
+		/* copy n bytes to head */
+		memcpy(op->head_desc->src + op->head_desc->len,
+		       sdcp->user_buf_desc->src, bytes_borrowed);
+		op->head_desc->len += bytes_borrowed;
+
+		/* update current buffer's src and len */
+		sdcp->user_buf_desc->src += bytes_borrowed;
+		sdcp->user_buf_desc->len -= bytes_borrowed;
+	}
+
+	/* Is current buffer unaligned to 64 byte length?
+	 * Each buffer's length must be a multiple of 64 bytes for DCP
+	 */
+	rem_bytes = sdcp->user_buf_desc->len % 64;
+
+	/* if length is unaligned, copy remainder to tail */
+	if (rem_bytes) {
+
+		memcpy(op->tail_desc->src, (sdcp->user_buf_desc->src +
+					    sdcp->user_buf_desc->len -
+					    rem_bytes), rem_bytes);
+
+		/* update length of current buffer */
+		sdcp->user_buf_desc->len -= rem_bytes;
+
+		op->tail_desc->len = rem_bytes;
+	}
+
+	/* do not send to DCP if length is < 64 */
+	if ((op->head_desc->len + sdcp->user_buf_desc->len) >= 64) {
+
+		/* set hash alg to be used (SHA1 or SHA256) */
+		op->head_desc->hash_sel = hash_sel;
+		sdcp->user_buf_desc->hash_sel = hash_sel;
+
+		if (op->head_desc->len) {
+			op->head_desc->next = sdcp->user_buf_desc;
+
+			ret = dcp_perform_hash_op(op->head_desc,
+						  sdcp->user_buf_desc->
+						  len ? 2 : 1, op->length == 0,
+						  false);
+		} else {
+			ret = dcp_perform_hash_op(sdcp->user_buf_desc, 1,
+						  op->length == 0, false);
+		}
+
+		op->length += op->head_desc->len + sdcp->user_buf_desc->len;
+		op->head_desc->len = 0;
+	}
+
+	/* if tail has bytes, make it the head for next time */
+	if (op->tail_desc->len) {
+		temp = op->head_desc;
+		op->head_desc = op->tail_desc;
+		op->tail_desc = temp;
+	}
+
+	/* hash_sel to be used by final function */
+	op->head_desc->hash_sel = hash_sel;
+
+	return ret;
+}
+
+static int dcp_sha_final(struct shash_desc *desc, u8 *out)
+{
+	struct dcp_hash_op *op = shash_desc_ctx(desc);
+	const uint8_t *digest;
+	struct dcp *sdcp = global_sdcp;
+	u32 i, digest_len;
+	struct mutex *mutex = &sdcp->op_mutex[HASH_CHAN];
+	int ret = 0;
+
+	/* Send the leftover bytes in head, which can be length 0,
+	 * but DCP still produces hash result in payload ptr.
+	 * Last data bytes need not be 64-byte multiple.
+	 */
+	ret = dcp_perform_hash_op(op->head_desc, 1, op->length == 0, true);
+
+	op->length += op->head_desc->len;
+
+	digest_len = (op->head_desc->hash_sel ==
+		      BV_DCP_PACKET2_HASH_SELECT__SHA1) ? SHA1_DIGEST_SIZE :
+	    SHA256_DIGEST_SIZE;
+
+	/* hardware reverses the digest (for some unexplicable reason) */
+	digest = op->head_desc->digest + digest_len;
+	for (i = 0; i < digest_len; i++)
+		*out++ = *--digest;
+
+	sdcp->chan_in_use[HASH_CHAN] = false;
+	dcp_clock(sdcp, CLOCK_OFF, false);
+	mutex_unlock(mutex);
+
+	return ret;
+}
+
+static struct shash_alg dcp_sha1_alg = {
+	.init = dcp_sha_init,
+	.update = dcp_sha_update,
+	.final = dcp_sha_final,
+	.descsize = sizeof(struct dcp_hash_op),
+	.digestsize = SHA1_DIGEST_SIZE,
+	.base = {
+		 .cra_name = "sha1",
+		 .cra_driver_name = "sha1-dcp",
+		 .cra_priority = 300,
+		 .cra_blocksize = SHA1_BLOCK_SIZE,
+		 .cra_ctxsize = sizeof(struct dcp_hash_op),
+		 .cra_module = THIS_MODULE,
+		 }
+};
+
+static struct shash_alg dcp_sha256_alg = {
+	.init = dcp_sha_init,
+	.update = dcp_sha_update,
+	.final = dcp_sha_final,
+	.descsize = sizeof(struct dcp_hash_op),
+	.digestsize = SHA256_DIGEST_SIZE,
+	.base = {
+		 .cra_name = "sha256",
+		 .cra_driver_name = "sha256-dcp",
+		 .cra_priority = 300,
+		 .cra_blocksize = SHA256_BLOCK_SIZE,
+		 .cra_ctxsize = sizeof(struct dcp_hash_op),
+		 .cra_module = THIS_MODULE,
+		 }
+};
+
+static irqreturn_t dcp_common_irq(int irq, void *context)
+{
+	struct dcp *sdcp = context;
+	u32 msk;
+
+	/* check */
+	msk =
+	    __raw_readl((volatile void *)(sdcp->dcp_regs_base +
+					  HW_DCP_STAT)) & BF(0x0f,
+							     DCP_STAT_IRQ);
+	if (msk == 0)
+		return IRQ_NONE;
+
+	/* clear this channel */
+	__raw_writel(msk,
+		     (volatile void *)(sdcp->dcp_regs_base + HW_DCP_STAT_CLR));
+	if (msk & BF(0x01, DCP_STAT_IRQ))
+		sdcp->wait[0]++;
+	if (msk & BF(0x02, DCP_STAT_IRQ))
+		sdcp->wait[1]++;
+	if (msk & BF(0x04, DCP_STAT_IRQ))
+		sdcp->wait[2]++;
+	if (msk & BF(0x08, DCP_STAT_IRQ))
+		sdcp->wait[3]++;
+	return IRQ_HANDLED;
+}
+
+static irqreturn_t dcp_vmi_irq(int irq, void *context)
+{
+	return dcp_common_irq(irq, context);
+}
+
+static irqreturn_t dcp_irq(int irq, void *context)
+{
+	return dcp_common_irq(irq, context);
+}
+
+/* DCP bootstream verification interface: uses OTP key for crypto */
+static long dcp_bootstream_ioctl(struct file *file, unsigned int cmd,
+				 unsigned long arg)
+{
+	struct dcp *sdcp = global_sdcp;
+	struct dcpboot_dma_area *da = sdcp->dcpboot_dma_area;
+	void __user *argp = (void __user *)arg;
+	int chan = ROM_DCP_CHAN;
+	unsigned long timeout;
+	struct mutex *mutex;
+	int retVal;
+
+	/* be paranoid */
+	if (sdcp == NULL)
+		return -EBADF;
+
+	if (cmd != DBS_ENC && cmd != DBS_DEC)
+		return -EINVAL;
+
+	/* copy to (aligned) block */
+	if (copy_from_user(da->block, argp, 16))
+		return -EFAULT;
+
+	mutex = &sdcp->op_mutex[chan];
+	mutex_lock(mutex);
+	dcp_clock(sdcp, CLOCK_ON, false);
+	sdcp->chan_in_use[chan] = true;
+
+	__raw_writel(-1, (volatile void *)(sdcp->dcp_regs_base +
+					   HW_DCP_CHnSTAT_CLR(ROM_DCP_CHAN)));
+	__raw_writel(BF(ROM_DCP_CHAN_MASK, DCP_STAT_IRQ),
+		     (volatile void *)(sdcp->dcp_regs_base + HW_DCP_STAT_CLR));
+
+	da->hw_packet.pNext = 0;
+	da->hw_packet.pkt1 = BM_DCP_PACKET1_DECR_SEMAPHORE |
+	    BM_DCP_PACKET1_ENABLE_CIPHER | BM_DCP_PACKET1_OTP_KEY |
+	    BM_DCP_PACKET1_INTERRUPT |
+	    (cmd == DBS_ENC ? BM_DCP_PACKET1_CIPHER_ENCRYPT : 0);
+	da->hw_packet.pkt2 = BF(0, DCP_PACKET2_CIPHER_CFG) |
+	    BF(0, DCP_PACKET2_KEY_SELECT) |
+	    BF(BV_DCP_PACKET2_CIPHER_MODE__ECB, DCP_PACKET2_CIPHER_MODE) |
+	    BF(BV_DCP_PACKET2_CIPHER_SELECT__AES128, DCP_PACKET2_CIPHER_SELECT);
+	da->hw_packet.pSrc = sdcp->dcpboot_dma_area_phys +
+	    offsetof(struct dcpboot_dma_area, block);
+	da->hw_packet.pDst = da->hw_packet.pSrc;	/* in-place */
+	da->hw_packet.size = 16;
+	da->hw_packet.pPayload = 0;
+	da->hw_packet.stat = 0;
+
+	/* Load the work packet pointer and bump the channel semaphore */
+	__raw_writel(sdcp->dcpboot_dma_area_phys +
+		     offsetof(struct dcpboot_dma_area, hw_packet),
+		     (volatile void *)(sdcp->dcp_regs_base +
+				       HW_DCP_CHnCMDPTR(ROM_DCP_CHAN)));
+
+	sdcp->wait[chan] = 0;
+	__raw_writel(BF(1, DCP_CHnSEMA_INCREMENT),
+		     (volatile void *)(sdcp->dcp_regs_base +
+				       HW_DCP_CHnSEMA(ROM_DCP_CHAN)));
+
+	timeout = jiffies + msecs_to_jiffies(100);
+
+	while (time_before(jiffies, timeout) && sdcp->wait[chan] == 0)
+		cpu_relax();
+
+	if (!time_before(jiffies, timeout)) {
+		dev_err(sdcp->dev,
+			"Timeout while waiting for operation to complete\n");
+		retVal = -ETIMEDOUT;
+		goto exit;
+	}
+
+	if (__raw_readl
+	    ((volatile void *)(sdcp->dcp_regs_base +
+			       (HW_DCP_CHnSTAT(ROM_DCP_CHAN) & 0xff))) != 0) {
+		dev_err(sdcp->dev, "Channel stat error 0x%02x\n",
+			__raw_readl((volatile void *)(sdcp->dcp_regs_base +
+						      (HW_DCP_CHnSTAT
+						       (ROM_DCP_CHAN) &
+						       0xff))));
+		retVal = -EFAULT;
+		goto exit;
+	}
+
+	if (copy_to_user(argp, da->block, 16)) {
+		retVal = -EFAULT;
+		goto exit;
+	}
+
+	retVal = 0;
+
+ exit:
+	sdcp->chan_in_use[chan] = false;
+	dcp_clock(sdcp, CLOCK_OFF, false);
+	mutex_unlock(mutex);
+	return retVal;
+}
+
+static const struct file_operations dcp_bootstream_fops = {
+	.owner = THIS_MODULE,
+	.unlocked_ioctl = dcp_bootstream_ioctl,
+};
+
+static struct miscdevice dcp_bootstream_misc = {
+	.minor = MISC_DYNAMIC_MINOR,
+	.name = "dcpboot",
+	.fops = &dcp_bootstream_fops,
+};
+
+static int dcp_probe(struct platform_device *pdev)
+{
+	struct dcp *sdcp = NULL;
+	struct resource *r;
+	int i, ret;
+	dma_addr_t hw_phys;
+
+	if (global_sdcp != NULL) {
+		dev_err(&pdev->dev, "Only one instance allowed\n");
+		ret = -ENODEV;
+		goto err;
+	}
+
+	/* allocate memory */
+	sdcp = kzalloc(sizeof(*sdcp), GFP_KERNEL);
+	if (sdcp == NULL) {
+		dev_err(&pdev->dev, "Failed to allocate structure\n");
+		ret = -ENOMEM;
+		goto err;
+	}
+
+	sdcp->dev = &pdev->dev;
+	spin_lock_init(&sdcp->lock);
+
+	for (i = 0; i < DCP_NUM_CHANNELS; i++) {
+		mutex_init(&sdcp->op_mutex[i]);
+		init_completion(&sdcp->op_wait[i]);
+		sdcp->chan_in_use[i] = false;
+	}
+
+	platform_set_drvdata(pdev, sdcp);
+
+	r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	if (!r) {
+		dev_err(&pdev->dev, "failed to get IORESOURCE_MEM\n");
+		ret = -ENXIO;
+		goto err_kfree;
+	}
+	sdcp->dcp_regs_base = (u32) ioremap(r->start, r->end - r->start + 1);
+	dcp_clock(sdcp, CLOCK_ON, true);
+
+	/* Soft reset and remove the clock gate */
+	__raw_writel(BM_DCP_CTRL_SFTRST,
+		     (volatile void *)(sdcp->dcp_regs_base + HW_DCP_CTRL_SET));
+
+	/* At 24Mhz, it takes no more than 4 clocks (160 ns) Maximum for
+	 * the part to reset, reading the register twice should
+	 * be sufficient to get 4 clks delay.
+	 */
+	__raw_readl((volatile void *)(sdcp->dcp_regs_base + HW_DCP_CTRL));
+	__raw_readl((volatile void *)(sdcp->dcp_regs_base + HW_DCP_CTRL));
+
+	__raw_writel(BM_DCP_CTRL_SFTRST | BM_DCP_CTRL_CLKGATE,
+		     (volatile void *)(sdcp->dcp_regs_base + HW_DCP_CTRL_CLR));
+
+	/* Initialize control registers */
+	__raw_writel(DCP_CTRL_INIT,
+		     (volatile void *)(sdcp->dcp_regs_base + HW_DCP_CTRL));
+	__raw_writel(DCP_CHANNELCTRL_INIT,
+		     (volatile void *)(sdcp->dcp_regs_base +
+				       HW_DCP_CHANNELCTRL));
+
+	/* We do not enable context switching. Give the context
+	 * buffer pointer an illegal address so if context switching is
+	 * inadvertantly enabled, the dcp will return an error instead of
+	 * trashing good memory. The dcp dma cannot access rom, so any rom
+	 * address will do.
+	 */
+	__raw_writel(0xFFFF0000,
+		     (volatile void *)(sdcp->dcp_regs_base + HW_DCP_CONTEXT));
+
+	for (i = 0; i < DCP_NUM_CHANNELS; i++)
+		__raw_writel(-1,
+			     (volatile void *)(sdcp->dcp_regs_base +
+					       HW_DCP_CHnSTAT_CLR(i)));
+	__raw_writel(-1,
+		     (volatile void *)(sdcp->dcp_regs_base + HW_DCP_STAT_CLR));
+
+	r = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
+	if (!r) {
+		dev_err(&pdev->dev, "can't get IRQ resource (0)\n");
+		ret = -EIO;
+		goto err_gate_clk;
+	}
+	sdcp->dcp_vmi_irq = r->start;
+	ret = request_irq(sdcp->dcp_vmi_irq, dcp_vmi_irq, 0, "dcp", sdcp);
+	if (ret != 0) {
+		dev_err(&pdev->dev, "can't request_irq (0)\n");
+		goto err_gate_clk;
+	}
+
+	r = platform_get_resource(pdev, IORESOURCE_IRQ, 1);
+	if (!r) {
+		dev_err(&pdev->dev, "can't get IRQ resource (1)\n");
+		ret = -EIO;
+		goto err_free_irq0;
+	}
+	sdcp->dcp_irq = r->start;
+	ret = request_irq(sdcp->dcp_irq, dcp_irq, 0, "dcp", sdcp);
+	if (ret != 0) {
+		dev_err(&pdev->dev, "can't request_irq (1)\n");
+		goto err_free_irq0;
+	}
+
+	global_sdcp = sdcp;
+
+	ret = crypto_register_alg(&dcp_aes_alg);
+	if (ret != 0) {
+		dev_err(&pdev->dev, "Failed to register aes crypto\n");
+		goto err_free_irq1;
+	}
+
+	ret = crypto_register_alg(&dcp_aes_ecb_alg);
+	if (ret != 0) {
+		dev_err(&pdev->dev, "Failed to register aes ecb crypto\n");
+		goto err_unregister_aes;
+	}
+
+	ret = crypto_register_alg(&dcp_aes_cbc_alg);
+	if (ret != 0) {
+		dev_err(&pdev->dev, "Failed to register aes cbc crypto\n");
+		goto err_unregister_aes_ecb;
+	}
+
+	/* Allocate the descriptor to be used for user buffer
+	 * passed in by the "update" function from Crypto API
+	 */
+	sdcp->user_buf_desc = dma_alloc_coherent(sdcp->dev,
+						 sizeof(struct
+							dcp_hash_coherent_block),
+						 &hw_phys, GFP_KERNEL);
+	if (sdcp->user_buf_desc == NULL) {
+		printk(KERN_ERR "Error allocating coherent block\n");
+		ret = -ENOMEM;
+		goto err_unregister_aes_cbc;
+	}
+
+	sdcp->user_buf_desc->my_phys = hw_phys;
+
+	/* Allocate 2 buffers (head & tail) & its descriptors to deal with
+	 * buffer lengths that are not 64 byte aligned, except for the
+	 * last one.
+	 */
+	sdcp->buf1 = dma_alloc_coherent(sdcp->dev,
+					64, &sdcp->buf1_phys, GFP_KERNEL);
+	if (sdcp->buf1 == NULL) {
+		printk(KERN_ERR "Error allocating coherent block\n");
+		ret = -ENOMEM;
+		goto err_unregister_aes_cbc;
+	}
+
+	sdcp->buf2 = dma_alloc_coherent(sdcp->dev,
+					64, &sdcp->buf2_phys, GFP_KERNEL);
+	if (sdcp->buf2 == NULL) {
+		printk(KERN_ERR "Error allocating coherent block\n");
+		ret = -ENOMEM;
+		goto err_unregister_aes_cbc;
+	}
+
+	sdcp->buf1_desc = dma_alloc_coherent(sdcp->dev,
+					     sizeof(struct
+						    dcp_hash_coherent_block),
+					     &hw_phys, GFP_KERNEL);
+	if (sdcp->buf1_desc == NULL) {
+		printk(KERN_ERR "Error allocating coherent block\n");
+		ret = -ENOMEM;
+		goto err_unregister_aes_cbc;
+	}
+
+	sdcp->buf1_desc->my_phys = hw_phys;
+	sdcp->buf1_desc->src = (void *)sdcp->buf1;
+	sdcp->buf1_desc->src_phys = sdcp->buf1_phys;
+
+	sdcp->buf2_desc = dma_alloc_coherent(sdcp->dev,
+					     sizeof(struct
+						    dcp_hash_coherent_block),
+					     &hw_phys, GFP_KERNEL);
+	if (sdcp->buf2_desc == NULL) {
+		printk(KERN_ERR "Error allocating coherent block\n");
+		ret = -ENOMEM;
+		goto err_unregister_aes_cbc;
+	}
+
+	sdcp->buf2_desc->my_phys = hw_phys;
+	sdcp->buf2_desc->src = (void *)sdcp->buf2;
+	sdcp->buf2_desc->src_phys = sdcp->buf2_phys;
+
+	ret = crypto_register_shash(&dcp_sha1_alg);
+	if (ret != 0) {
+		dev_err(&pdev->dev, "Failed to register sha1 hash\n");
+		goto err_unregister_aes_cbc;
+	}
+
+	if (__raw_readl
+	    ((volatile void *)(sdcp->dcp_regs_base +
+			       HW_DCP_CAPABILITY1)) &
+	    BF_DCP_CAPABILITY1_HASH_ALGORITHMS
+	    (BV_DCP_CAPABILITY1_HASH_ALGORITHMS__SHA256)) {
+
+		ret = crypto_register_shash(&dcp_sha256_alg);
+		if (ret != 0) {
+			dev_err(&pdev->dev, "Failed to register sha256 hash\n");
+			goto err_unregister_sha1;
+		}
+	}
+
+	/* register dcpboot interface to allow apps (such as kobs-ng) to
+	 * verify files (such as the bootstream) using the OTP key for crypto */
+	ret = misc_register(&dcp_bootstream_misc);
+	if (ret != 0) {
+		dev_err(&pdev->dev, "Unable to register misc device\n");
+		goto err_unregister_sha1;
+	}
+
+	sdcp->dcpboot_dma_area = dma_alloc_coherent(&pdev->dev,
+						    sizeof(*sdcp->
+							   dcpboot_dma_area),
+						    &sdcp->
+						    dcpboot_dma_area_phys,
+						    GFP_KERNEL);
+	if (sdcp->dcpboot_dma_area == NULL) {
+		dev_err(&pdev->dev, "Unable to allocate DMAable memory \
+			 for dcpboot interface\n");
+		goto err_dereg;
+	}
+
+	dcp_clock(sdcp, CLOCK_OFF, false);
+	dev_notice(&pdev->dev, "DCP crypto enabled.!\n");
+	return 0;
+
+ err_dereg:
+	misc_deregister(&dcp_bootstream_misc);
+ err_unregister_sha1:
+	crypto_unregister_shash(&dcp_sha1_alg);
+ err_unregister_aes_cbc:
+	crypto_unregister_alg(&dcp_aes_cbc_alg);
+ err_unregister_aes_ecb:
+	crypto_unregister_alg(&dcp_aes_ecb_alg);
+ err_unregister_aes:
+	crypto_unregister_alg(&dcp_aes_alg);
+ err_free_irq1:
+	free_irq(sdcp->dcp_irq, sdcp);
+ err_free_irq0:
+	free_irq(sdcp->dcp_vmi_irq, sdcp);
+ err_gate_clk:
+	dcp_clock(sdcp, CLOCK_OFF, false);
+ err_kfree:
+	kfree(sdcp);
+ err:
+
+	return ret;
+}
+
+static int dcp_remove(struct platform_device *pdev)
+{
+	struct dcp *sdcp;
+
+	sdcp = platform_get_drvdata(pdev);
+	platform_set_drvdata(pdev, NULL);
+
+	dcp_clock(sdcp, CLOCK_ON, false);
+
+	free_irq(sdcp->dcp_irq, sdcp);
+	free_irq(sdcp->dcp_vmi_irq, sdcp);
+
+	/* if head and tail buffers were allocated, free them */
+	if (sdcp->buf1) {
+		dma_free_coherent(sdcp->dev, 64, sdcp->buf1, sdcp->buf1_phys);
+		dma_free_coherent(sdcp->dev, 64, sdcp->buf2, sdcp->buf2_phys);
+
+		dma_free_coherent(sdcp->dev,
+				  sizeof(struct dcp_hash_coherent_block),
+				  sdcp->buf1_desc, sdcp->buf1_desc->my_phys);
+
+		dma_free_coherent(sdcp->dev,
+				  sizeof(struct dcp_hash_coherent_block),
+				  sdcp->buf2_desc, sdcp->buf2_desc->my_phys);
+
+		dma_free_coherent(sdcp->dev,
+				  sizeof(struct dcp_hash_coherent_block),
+				  sdcp->user_buf_desc,
+				  sdcp->user_buf_desc->my_phys);
+	}
+
+	if (sdcp->dcpboot_dma_area) {
+		dma_free_coherent(&pdev->dev, sizeof(*sdcp->dcpboot_dma_area),
+				  sdcp->dcpboot_dma_area,
+				  sdcp->dcpboot_dma_area_phys);
+		misc_deregister(&dcp_bootstream_misc);
+	}
+
+	crypto_unregister_shash(&dcp_sha1_alg);
+
+	if (__raw_readl
+	    ((volatile void *)(sdcp->dcp_regs_base +
+			       HW_DCP_CAPABILITY1)) &
+	    BF_DCP_CAPABILITY1_HASH_ALGORITHMS
+	    (BV_DCP_CAPABILITY1_HASH_ALGORITHMS__SHA256))
+		crypto_unregister_shash(&dcp_sha256_alg);
+
+	crypto_unregister_alg(&dcp_aes_cbc_alg);
+	crypto_unregister_alg(&dcp_aes_ecb_alg);
+	crypto_unregister_alg(&dcp_aes_alg);
+
+	dcp_clock(sdcp, CLOCK_OFF, true);
+	iounmap((void *)sdcp->dcp_regs_base);
+	kfree(sdcp);
+	global_sdcp = NULL;
+
+	return 0;
+}
+
+static int dcp_suspend(struct platform_device *pdev, pm_message_t state)
+{
+#ifdef CONFIG_PM
+	struct dcp *sdcp = platform_get_drvdata(pdev);
+
+	if (sdcp->clock_state == CLOCK_ON) {
+		dcp_clock(sdcp, CLOCK_OFF, true);
+		/* indicate that clock needs to be turned on upon resume */
+		sdcp->clock_state = CLOCK_ON;
+	}
+#endif
+	return 0;
+}
+
+static int dcp_resume(struct platform_device *pdev)
+{
+#ifdef CONFIG_PM
+	struct dcp *sdcp = platform_get_drvdata(pdev);
+
+	/* if clock was on prior to suspend, turn it back on */
+	if (sdcp->clock_state == CLOCK_ON)
+		dcp_clock(sdcp, CLOCK_ON, true);
+#endif
+	return 0;
+}
+
+static const struct of_device_id mxs_dcp_dt_ids[] = {
+	{.compatible = "fsl,fsl-dcp", .data = NULL,},
+	{ /* sentinel */ }
+};
+
+MODULE_DEVICE_TABLE(of, mxs_dcp_dt_ids);
+
+static struct platform_driver dcp_driver = {
+	.probe = dcp_probe,
+	.remove = dcp_remove,
+	.suspend = dcp_suspend,
+	.resume = dcp_resume,
+	.driver = {
+		   .name = "fsl-dcp",
+		   .owner = THIS_MODULE,
+		   .of_match_table = mxs_dcp_dt_ids,
+		   },
+};
+
+static int __init dcp_init(void)
+{
+	return platform_driver_register(&dcp_driver);
+}
+
+static void __exit dcp_exit(void)
+{
+	platform_driver_unregister(&dcp_driver);
+}
+
+MODULE_AUTHOR("Pantelis Antoniou <pantelis at embeddedalley.com>");
+MODULE_DESCRIPTION("DCP Crypto Driver");
+MODULE_LICENSE("GPL");
+
+module_init(dcp_init);
+module_exit(dcp_exit);
diff --git a/drivers/staging/crypto/fsl-dcp.h b/drivers/staging/crypto/fsl-dcp.h
new file mode 100644
index 0000000..7c9045f
--- /dev/null
+++ b/drivers/staging/crypto/fsl-dcp.h
@@ -0,0 +1,739 @@
+/*
+ * Copyright 2008-2010 Freescale Semiconductor, Inc. All Rights Reserved.
+ */
+
+/*
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+#ifndef DCP_H_
+#define DCP_H_
+
+/* cipher flags */
+#define DCP_ENC	0x0001
+#define DCP_DEC	0x0002
+#define DCP_ECB	0x0004
+#define DCP_CBC	0x0008
+#define DCP_CBC_INIT	0x0010
+#define DCP_OTPKEY	0x0020
+
+/* hash flags */
+#define DCP_INIT	0x0001
+#define DCP_UPDATE	0x0002
+#define DCP_FINAL	0x0004
+
+#define DCP_AES	0x1000
+#define DCP_SHA1	0x2000
+#define DCP_CRC32	0x3000
+#define DCP_COPY	0x4000
+#define DCP_FILL	0x5000
+#define DCP_MODE_MASK	0xf000
+
+/* clock defines */
+#define CLOCK_ON	1
+#define CLOCK_OFF	0
+
+#define CIPHER_CHAN	1
+#define CIPHER_MASK	(1 << CIPHER_CHAN)
+
+#define HASH_CHAN	0
+#define HASH_MASK	(1 << HASH_CHAN)
+
+/* DCP boostream interface uses this channel (same as the ROM) */
+#define ROM_DCP_CHAN 3
+#define ROM_DCP_CHAN_MASK (1 << ROM_DCP_CHAN)
+
+#define ALL_MASK	(CIPHER_MASK | HASH_MASK | ROM_DCP_CHAN_MASK)
+
+/* Defines the initialization value for the dcp control register */
+#define DCP_CTRL_INIT \
+   (BM_DCP_CTRL_GATHER_RESIDUAL_WRITES | \
+    BM_DCP_CTRL_ENABLE_CONTEXT_CACHING | \
+    BV_DCP_CTRL_CHANNEL_INTERRUPT_ENABLE__CH0 | \
+    BV_DCP_CTRL_CHANNEL_INTERRUPT_ENABLE__CH1 | \
+    BV_DCP_CTRL_CHANNEL_INTERRUPT_ENABLE__CH2 | \
+    BV_DCP_CTRL_CHANNEL_INTERRUPT_ENABLE__CH3)
+
+/* Defines the initialization value for the dcp channel control register */
+#define DCP_CHANNELCTRL_INIT \
+    BF(ALL_MASK, DCP_CHANNELCTRL_ENABLE_CHANNEL)
+
+/* DCP work packet 1 value for encryption */
+#define DCP_PKT1_ENCRYPT \
+   (BM_DCP_PACKET1_DECR_SEMAPHORE | \
+    BM_DCP_PACKET1_ENABLE_CIPHER | \
+    BM_DCP_PACKET1_CIPHER_ENCRYPT | \
+    BM_DCP_PACKET1_CIPHER_INIT)
+
+/* DCP work packet 1 value for decryption */
+#define DCP_PKT1_DECRYPT \
+   (BM_DCP_PACKET1_DECR_SEMAPHORE | \
+    BM_DCP_PACKET1_ENABLE_CIPHER | \
+    BM_DCP_PACKET1_CIPHER_INIT)
+
+/* DCP (decryption) work packet definition */
+struct dcp_hw_packet {
+	uint32_t pNext;		/* next dcp work packet address */
+	uint32_t pkt1;		/* dcp work packet 1 (control 0) */
+	uint32_t pkt2;		/* dcp work packet 2 (control 1) */
+	uint32_t pSrc;		/* source buffer address */
+	uint32_t pDst;		/* destination buffer address */
+	uint32_t size;		/* buffer size in bytes */
+	uint32_t pPayload;	/* payload buffer address */
+	uint32_t stat;		/* dcp status (written by dcp) */
+};
+
+#define DCP_NUM_CHANNELS 4
+
+/* DCP Register definitions */
+
+#ifndef BF
+#define BF(value, field) (((value) << BP_##field) & BM_##field)
+#endif
+
+#define REGS_DCP_SIZE 0x00002000
+
+#define HW_DCP_CTRL	(0x00000000)
+#define HW_DCP_CTRL_SET	(0x00000004)
+#define HW_DCP_CTRL_CLR	(0x00000008)
+#define HW_DCP_CTRL_TOG	(0x0000000c)
+
+#define BM_DCP_CTRL_SFTRST	0x80000000
+#define BM_DCP_CTRL_CLKGATE	0x40000000
+#define BM_DCP_CTRL_PRESENT_CRYPTO	0x20000000
+#define BV_DCP_CTRL_PRESENT_CRYPTO__Present 0x1
+#define BV_DCP_CTRL_PRESENT_CRYPTO__Absent  0x0
+#define BM_DCP_CTRL_PRESENT_CSC	0x10000000
+#define BV_DCP_CTRL_PRESENT_CSC__Present 0x1
+#define BV_DCP_CTRL_PRESENT_CSC__Absent  0x0
+#define BP_DCP_CTRL_RSVD1	24
+#define BM_DCP_CTRL_RSVD1	0x0F000000
+#define BF_DCP_CTRL_RSVD1(v)  \
+		(((v) << 24) & BM_DCP_CTRL_RSVD1)
+#define BM_DCP_CTRL_GATHER_RESIDUAL_WRITES	0x00800000
+#define BM_DCP_CTRL_ENABLE_CONTEXT_CACHING	0x00400000
+#define BM_DCP_CTRL_ENABLE_CONTEXT_SWITCHING	0x00200000
+#define BP_DCP_CTRL_RSVD0	9
+#define BM_DCP_CTRL_RSVD0	0x001FFE00
+#define BF_DCP_CTRL_RSVD0(v)  \
+		(((v) << 9) & BM_DCP_CTRL_RSVD0)
+#define BM_DCP_CTRL_CSC_INTERRUPT_ENABLE	0x00000100
+#define BP_DCP_CTRL_CHANNEL_INTERRUPT_ENABLE	0
+#define BM_DCP_CTRL_CHANNEL_INTERRUPT_ENABLE	0x000000FF
+#define BF_DCP_CTRL_CHANNEL_INTERRUPT_ENABLE(v)  \
+		(((v) << 0) & BM_DCP_CTRL_CHANNEL_INTERRUPT_ENABLE)
+#define BV_DCP_CTRL_CHANNEL_INTERRUPT_ENABLE__CH0 0x01
+#define BV_DCP_CTRL_CHANNEL_INTERRUPT_ENABLE__CH1 0x02
+#define BV_DCP_CTRL_CHANNEL_INTERRUPT_ENABLE__CH2 0x04
+#define BV_DCP_CTRL_CHANNEL_INTERRUPT_ENABLE__CH3 0x08
+
+#define HW_DCP_STAT	(0x00000010)
+#define HW_DCP_STAT_SET	(0x00000014)
+#define HW_DCP_STAT_CLR	(0x00000018)
+#define HW_DCP_STAT_TOG	(0x0000001c)
+
+#define BP_DCP_STAT_RSVD2	29
+#define BM_DCP_STAT_RSVD2	0xE0000000
+#define BF_DCP_STAT_RSVD2(v) \
+		(((v) << 29) & BM_DCP_STAT_RSVD2)
+#define BM_DCP_STAT_OTP_KEY_READY	0x10000000
+#define BP_DCP_STAT_CUR_CHANNEL	24
+#define BM_DCP_STAT_CUR_CHANNEL	0x0F000000
+#define BF_DCP_STAT_CUR_CHANNEL(v)  \
+		(((v) << 24) & BM_DCP_STAT_CUR_CHANNEL)
+#define BV_DCP_STAT_CUR_CHANNEL__None 0x0
+#define BV_DCP_STAT_CUR_CHANNEL__CH0  0x1
+#define BV_DCP_STAT_CUR_CHANNEL__CH1  0x2
+#define BV_DCP_STAT_CUR_CHANNEL__CH2  0x3
+#define BV_DCP_STAT_CUR_CHANNEL__CH3  0x4
+#define BV_DCP_STAT_CUR_CHANNEL__CSC  0x8
+#define BP_DCP_STAT_READY_CHANNELS	16
+#define BM_DCP_STAT_READY_CHANNELS	0x00FF0000
+#define BF_DCP_STAT_READY_CHANNELS(v)  \
+		(((v) << 16) & BM_DCP_STAT_READY_CHANNELS)
+#define BV_DCP_STAT_READY_CHANNELS__CH0 0x01
+#define BV_DCP_STAT_READY_CHANNELS__CH1 0x02
+#define BV_DCP_STAT_READY_CHANNELS__CH2 0x04
+#define BV_DCP_STAT_READY_CHANNELS__CH3 0x08
+#define BP_DCP_STAT_RSVD1	9
+#define BM_DCP_STAT_RSVD1	0x0000FE00
+#define BF_DCP_STAT_RSVD1(v)  \
+		(((v) << 9) & BM_DCP_STAT_RSVD1)
+#define BM_DCP_STAT_CSCIRQ	0x00000100
+#define BP_DCP_STAT_RSVD0	4
+#define BM_DCP_STAT_RSVD0	0x000000F0
+#define BF_DCP_STAT_RSVD0(v)  \
+		(((v) << 4) & BM_DCP_STAT_RSVD0)
+#define BP_DCP_STAT_IRQ	0
+#define BM_DCP_STAT_IRQ	0x0000000F
+#define BF_DCP_STAT_IRQ(v)  \
+		(((v) << 0) & BM_DCP_STAT_IRQ)
+
+#define HW_DCP_CHANNELCTRL	(0x00000020)
+#define HW_DCP_CHANNELCTRL_SET	(0x00000024)
+#define HW_DCP_CHANNELCTRL_CLR	(0x00000028)
+#define HW_DCP_CHANNELCTRL_TOG	(0x0000002c)
+
+#define BP_DCP_CHANNELCTRL_RSVD	19
+#define BM_DCP_CHANNELCTRL_RSVD	0xFFF80000
+#define BF_DCP_CHANNELCTRL_RSVD(v) \
+		(((v) << 19) & BM_DCP_CHANNELCTRL_RSVD)
+#define BP_DCP_CHANNELCTRL_CSC_PRIORITY	17
+#define BM_DCP_CHANNELCTRL_CSC_PRIORITY	0x00060000
+#define BF_DCP_CHANNELCTRL_CSC_PRIORITY(v)  \
+		(((v) << 17) & BM_DCP_CHANNELCTRL_CSC_PRIORITY)
+#define BV_DCP_CHANNELCTRL_CSC_PRIORITY__HIGH       0x3
+#define BV_DCP_CHANNELCTRL_CSC_PRIORITY__MED        0x2
+#define BV_DCP_CHANNELCTRL_CSC_PRIORITY__LOW        0x1
+#define BV_DCP_CHANNELCTRL_CSC_PRIORITY__BACKGROUND 0x0
+#define BM_DCP_CHANNELCTRL_CH0_IRQ_MERGED	0x00010000
+#define BP_DCP_CHANNELCTRL_HIGH_PRIORITY_CHANNEL	8
+#define BM_DCP_CHANNELCTRL_HIGH_PRIORITY_CHANNEL	0x0000FF00
+#define BF_DCP_CHANNELCTRL_HIGH_PRIORITY_CHANNEL(v)  \
+		(((v) << 8) & BM_DCP_CHANNELCTRL_HIGH_PRIORITY_CHANNEL)
+#define BV_DCP_CHANNELCTRL_HIGH_PRIORITY_CHANNEL__CH0 0x01
+#define BV_DCP_CHANNELCTRL_HIGH_PRIORITY_CHANNEL__CH1 0x02
+#define BV_DCP_CHANNELCTRL_HIGH_PRIORITY_CHANNEL__CH2 0x04
+#define BV_DCP_CHANNELCTRL_HIGH_PRIORITY_CHANNEL__CH3 0x08
+#define BP_DCP_CHANNELCTRL_ENABLE_CHANNEL	0
+#define BM_DCP_CHANNELCTRL_ENABLE_CHANNEL	0x000000FF
+#define BF_DCP_CHANNELCTRL_ENABLE_CHANNEL(v)  \
+		(((v) << 0) & BM_DCP_CHANNELCTRL_ENABLE_CHANNEL)
+#define BV_DCP_CHANNELCTRL_ENABLE_CHANNEL__CH0 0x01
+#define BV_DCP_CHANNELCTRL_ENABLE_CHANNEL__CH1 0x02
+#define BV_DCP_CHANNELCTRL_ENABLE_CHANNEL__CH2 0x04
+#define BV_DCP_CHANNELCTRL_ENABLE_CHANNEL__CH3 0x08
+
+#define HW_DCP_CAPABILITY0	(0x00000030)
+
+#define BM_DCP_CAPABILITY0_DISABLE_DECRYPT	0x80000000
+#define BM_DCP_CAPABILITY0_ENABLE_TZONE	0x40000000
+#define BP_DCP_CAPABILITY0_RSVD	12
+#define BM_DCP_CAPABILITY0_RSVD	0x3FFFF000
+#define BF_DCP_CAPABILITY0_RSVD(v)  \
+		(((v) << 12) & BM_DCP_CAPABILITY0_RSVD)
+#define BP_DCP_CAPABILITY0_NUM_CHANNELS	8
+#define BM_DCP_CAPABILITY0_NUM_CHANNELS	0x00000F00
+#define BF_DCP_CAPABILITY0_NUM_CHANNELS(v)  \
+		(((v) << 8) & BM_DCP_CAPABILITY0_NUM_CHANNELS)
+#define BP_DCP_CAPABILITY0_NUM_KEYS	0
+#define BM_DCP_CAPABILITY0_NUM_KEYS	0x000000FF
+#define BF_DCP_CAPABILITY0_NUM_KEYS(v)  \
+		(((v) << 0) & BM_DCP_CAPABILITY0_NUM_KEYS)
+
+#define HW_DCP_CAPABILITY1	(0x00000040)
+
+#define BP_DCP_CAPABILITY1_HASH_ALGORITHMS	16
+#define BM_DCP_CAPABILITY1_HASH_ALGORITHMS	0xFFFF0000
+#define BF_DCP_CAPABILITY1_HASH_ALGORITHMS(v) \
+		(((v) << 16) & BM_DCP_CAPABILITY1_HASH_ALGORITHMS)
+#define BV_DCP_CAPABILITY1_HASH_ALGORITHMS__SHA1  0x0001
+#define BV_DCP_CAPABILITY1_HASH_ALGORITHMS__CRC32 0x0002
+#define BV_DCP_CAPABILITY1_HASH_ALGORITHMS__SHA256  0x0004
+#define BP_DCP_CAPABILITY1_CIPHER_ALGORITHMS	0
+#define BM_DCP_CAPABILITY1_CIPHER_ALGORITHMS	0x0000FFFF
+#define BF_DCP_CAPABILITY1_CIPHER_ALGORITHMS(v)  \
+		(((v) << 0) & BM_DCP_CAPABILITY1_CIPHER_ALGORITHMS)
+#define BV_DCP_CAPABILITY1_CIPHER_ALGORITHMS__AES128 0x0001
+
+#define HW_DCP_CONTEXT	(0x00000050)
+
+#define BP_DCP_CONTEXT_ADDR	0
+#define BM_DCP_CONTEXT_ADDR	0xFFFFFFFF
+#define BF_DCP_CONTEXT_ADDR(v)	(v)
+
+#define HW_DCP_KEY	(0x00000060)
+
+#define BP_DCP_KEY_RSVD	8
+#define BM_DCP_KEY_RSVD	0xFFFFFF00
+#define BF_DCP_KEY_RSVD(v) \
+		(((v) << 8) & BM_DCP_KEY_RSVD)
+#define BP_DCP_KEY_RSVD_INDEX	6
+#define BM_DCP_KEY_RSVD_INDEX	0x000000C0
+#define BF_DCP_KEY_RSVD_INDEX(v)  \
+		(((v) << 6) & BM_DCP_KEY_RSVD_INDEX)
+#define BP_DCP_KEY_INDEX	4
+#define BM_DCP_KEY_INDEX	0x00000030
+#define BF_DCP_KEY_INDEX(v)  \
+		(((v) << 4) & BM_DCP_KEY_INDEX)
+#define BP_DCP_KEY_RSVD_SUBWORD	2
+#define BM_DCP_KEY_RSVD_SUBWORD	0x0000000C
+#define BF_DCP_KEY_RSVD_SUBWORD(v)  \
+		(((v) << 2) & BM_DCP_KEY_RSVD_SUBWORD)
+#define BP_DCP_KEY_SUBWORD	0
+#define BM_DCP_KEY_SUBWORD	0x00000003
+#define BF_DCP_KEY_SUBWORD(v)  \
+		(((v) << 0) & BM_DCP_KEY_SUBWORD)
+
+#define HW_DCP_KEYDATA	(0x00000070)
+
+#define BP_DCP_KEYDATA_DATA	0
+#define BM_DCP_KEYDATA_DATA	0xFFFFFFFF
+#define BF_DCP_KEYDATA_DATA(v)	(v)
+
+#define HW_DCP_PACKET0	(0x00000080)
+
+#define BP_DCP_PACKET0_ADDR	0
+#define BM_DCP_PACKET0_ADDR	0xFFFFFFFF
+#define BF_DCP_PACKET0_ADDR(v)	(v)
+
+#define HW_DCP_PACKET1	(0x00000090)
+
+#define BP_DCP_PACKET1_TAG	24
+#define BM_DCP_PACKET1_TAG	0xFF000000
+#define BF_DCP_PACKET1_TAG(v) \
+		(((v) << 24) & BM_DCP_PACKET1_TAG)
+#define BM_DCP_PACKET1_OUTPUT_WORDSWAP	0x00800000
+#define BM_DCP_PACKET1_OUTPUT_BYTESWAP	0x00400000
+#define BM_DCP_PACKET1_INPUT_WORDSWAP	0x00200000
+#define BM_DCP_PACKET1_INPUT_BYTESWAP	0x00100000
+#define BM_DCP_PACKET1_KEY_WORDSWAP	0x00080000
+#define BM_DCP_PACKET1_KEY_BYTESWAP	0x00040000
+#define BM_DCP_PACKET1_TEST_SEMA_IRQ	0x00020000
+#define BM_DCP_PACKET1_CONSTANT_FILL	0x00010000
+#define BM_DCP_PACKET1_HASH_OUTPUT	0x00008000
+#define BV_DCP_PACKET1_HASH_OUTPUT__INPUT  0x00
+#define BV_DCP_PACKET1_HASH_OUTPUT__OUTPUT 0x01
+#define BM_DCP_PACKET1_CHECK_HASH	0x00004000
+#define BM_DCP_PACKET1_HASH_TERM	0x00002000
+#define BM_DCP_PACKET1_HASH_INIT	0x00001000
+#define BM_DCP_PACKET1_PAYLOAD_KEY	0x00000800
+#define BM_DCP_PACKET1_OTP_KEY	0x00000400
+#define BM_DCP_PACKET1_CIPHER_INIT	0x00000200
+#define BM_DCP_PACKET1_CIPHER_ENCRYPT	0x00000100
+#define BV_DCP_PACKET1_CIPHER_ENCRYPT__ENCRYPT 0x01
+#define BV_DCP_PACKET1_CIPHER_ENCRYPT__DECRYPT 0x00
+#define BM_DCP_PACKET1_ENABLE_BLIT	0x00000080
+#define BM_DCP_PACKET1_ENABLE_HASH	0x00000040
+#define BM_DCP_PACKET1_ENABLE_CIPHER	0x00000020
+#define BM_DCP_PACKET1_ENABLE_MEMCOPY	0x00000010
+#define BM_DCP_PACKET1_CHAIN_CONTIGUOUS	0x00000008
+#define BM_DCP_PACKET1_CHAIN	0x00000004
+#define BM_DCP_PACKET1_DECR_SEMAPHORE	0x00000002
+#define BM_DCP_PACKET1_INTERRUPT	0x00000001
+
+#define HW_DCP_PACKET2	(0x000000a0)
+
+#define BP_DCP_PACKET2_CIPHER_CFG	24
+#define BM_DCP_PACKET2_CIPHER_CFG	0xFF000000
+#define BF_DCP_PACKET2_CIPHER_CFG(v) \
+		(((v) << 24) & BM_DCP_PACKET2_CIPHER_CFG)
+#define BP_DCP_PACKET2_RSVD	20
+#define BM_DCP_PACKET2_RSVD	0x00F00000
+#define BF_DCP_PACKET2_RSVD(v)  \
+		(((v) << 20) & BM_DCP_PACKET2_RSVD)
+#define BP_DCP_PACKET2_HASH_SELECT	16
+#define BM_DCP_PACKET2_HASH_SELECT	0x000F0000
+#define BF_DCP_PACKET2_HASH_SELECT(v)  \
+		(((v) << 16) & BM_DCP_PACKET2_HASH_SELECT)
+#define BV_DCP_PACKET2_HASH_SELECT__SHA1  0x00
+#define BV_DCP_PACKET2_HASH_SELECT__CRC32 0x01
+#define BV_DCP_PACKET2_HASH_SELECT__SHA256  0x02
+#define BP_DCP_PACKET2_KEY_SELECT	8
+#define BM_DCP_PACKET2_KEY_SELECT	0x0000FF00
+#define BF_DCP_PACKET2_KEY_SELECT(v)  \
+		(((v) << 8) & BM_DCP_PACKET2_KEY_SELECT)
+#define BP_DCP_PACKET2_CIPHER_MODE	4
+#define BM_DCP_PACKET2_CIPHER_MODE	0x000000F0
+#define BF_DCP_PACKET2_CIPHER_MODE(v)  \
+		(((v) << 4) & BM_DCP_PACKET2_CIPHER_MODE)
+#define BV_DCP_PACKET2_CIPHER_MODE__ECB 0x00
+#define BV_DCP_PACKET2_CIPHER_MODE__CBC 0x01
+#define BP_DCP_PACKET2_CIPHER_SELECT	0
+#define BM_DCP_PACKET2_CIPHER_SELECT	0x0000000F
+#define BF_DCP_PACKET2_CIPHER_SELECT(v)  \
+		(((v) << 0) & BM_DCP_PACKET2_CIPHER_SELECT)
+#define BV_DCP_PACKET2_CIPHER_SELECT__AES128 0x00
+
+#define HW_DCP_PACKET3	(0x000000b0)
+
+#define BP_DCP_PACKET3_ADDR	0
+#define BM_DCP_PACKET3_ADDR	0xFFFFFFFF
+#define BF_DCP_PACKET3_ADDR(v)	(v)
+
+#define HW_DCP_PACKET4	(0x000000c0)
+
+#define BP_DCP_PACKET4_ADDR	0
+#define BM_DCP_PACKET4_ADDR	0xFFFFFFFF
+#define BF_DCP_PACKET4_ADDR(v)	(v)
+
+#define HW_DCP_PACKET5	(0x000000d0)
+
+#define BP_DCP_PACKET5_COUNT	0
+#define BM_DCP_PACKET5_COUNT	0xFFFFFFFF
+#define BF_DCP_PACKET5_COUNT(v)	(v)
+
+#define HW_DCP_PACKET6	(0x000000e0)
+
+#define BP_DCP_PACKET6_ADDR	0
+#define BM_DCP_PACKET6_ADDR	0xFFFFFFFF
+#define BF_DCP_PACKET6_ADDR(v)	(v)
+
+/*
+ *  multi-register-define name HW_DCP_CHnCMDPTR
+ *              base 0x00000100
+ *              count 4
+ *              offset 0x40
+ */
+#define HW_DCP_CHnCMDPTR(n)	(0x00000100 + (n) * 0x40)
+
+#define BP_DCP_CHnCMDPTR_ADDR	0
+#define BM_DCP_CHnCMDPTR_ADDR	0xFFFFFFFF
+#define BF_DCP_CHnCMDPTR_ADDR(v)	(v)
+
+/*
+ *  multi-register-define name HW_DCP_CHnSEMA
+ *              base 0x00000110
+ *              count 4
+ *              offset 0x40
+ */
+#define HW_DCP_CHnSEMA(n)	(0x00000110 + (n) * 0x40)
+
+#define BP_DCP_CHnSEMA_RSVD2	24
+#define BM_DCP_CHnSEMA_RSVD2	0xFF000000
+#define BF_DCP_CHnSEMA_RSVD2(v) \
+		(((v) << 24) & BM_DCP_CHnSEMA_RSVD2)
+#define BP_DCP_CHnSEMA_VALUE	16
+#define BM_DCP_CHnSEMA_VALUE	0x00FF0000
+#define BF_DCP_CHnSEMA_VALUE(v)  \
+		(((v) << 16) & BM_DCP_CHnSEMA_VALUE)
+#define BP_DCP_CHnSEMA_RSVD1	8
+#define BM_DCP_CHnSEMA_RSVD1	0x0000FF00
+#define BF_DCP_CHnSEMA_RSVD1(v)  \
+		(((v) << 8) & BM_DCP_CHnSEMA_RSVD1)
+#define BP_DCP_CHnSEMA_INCREMENT	0
+#define BM_DCP_CHnSEMA_INCREMENT	0x000000FF
+#define BF_DCP_CHnSEMA_INCREMENT(v)  \
+		(((v) << 0) & BM_DCP_CHnSEMA_INCREMENT)
+
+/*
+ *  multi-register-define name HW_DCP_CHnSTAT
+ *              base 0x00000120
+ *              count 4
+ *              offset 0x40
+ */
+#define HW_DCP_CHnSTAT(n)	(0x00000120 + (n) * 0x40)
+#define HW_DCP_CHnSTAT_SET(n)	(0x00000124 + (n) * 0x40)
+#define HW_DCP_CHnSTAT_CLR(n)	(0x00000128 + (n) * 0x40)
+#define HW_DCP_CHnSTAT_TOG(n)	(0x0000012c + (n) * 0x40)
+
+#define BP_DCP_CHnSTAT_TAG	24
+#define BM_DCP_CHnSTAT_TAG	0xFF000000
+#define BF_DCP_CHnSTAT_TAG(v) \
+		(((v) << 24) & BM_DCP_CHnSTAT_TAG)
+#define BP_DCP_CHnSTAT_ERROR_CODE	16
+#define BM_DCP_CHnSTAT_ERROR_CODE	0x00FF0000
+#define BF_DCP_CHnSTAT_ERROR_CODE(v)  \
+		(((v) << 16) & BM_DCP_CHnSTAT_ERROR_CODE)
+#define BV_DCP_CHnSTAT_ERROR_CODE__NEXT_CHAIN_IS_0 0x01
+#define BV_DCP_CHnSTAT_ERROR_CODE__NO_CHAIN        0x02
+#define BV_DCP_CHnSTAT_ERROR_CODE__CONTEXT_ERROR   0x03
+#define BV_DCP_CHnSTAT_ERROR_CODE__PAYLOAD_ERROR   0x04
+#define BV_DCP_CHnSTAT_ERROR_CODE__INVALID_MODE    0x05
+#define BP_DCP_CHnSTAT_RSVD0	7
+#define BM_DCP_CHnSTAT_RSVD0	0x0000FF80
+#define BF_DCP_CHnSTAT_RSVD0(v)  \
+		(((v) << 7) & BM_DCP_CHnSTAT_RSVD0)
+#define BM_DCP_CHnSTAT_ERROR_PAGEFAULT	0x00000040
+#define BM_DCP_CHnSTAT_ERROR_DST	0x00000020
+#define BM_DCP_CHnSTAT_ERROR_SRC	0x00000010
+#define BM_DCP_CHnSTAT_ERROR_PACKET	0x00000008
+#define BM_DCP_CHnSTAT_ERROR_SETUP	0x00000004
+#define BM_DCP_CHnSTAT_HASH_MISMATCH	0x00000002
+#define BM_DCP_CHnSTAT_RSVD_COMPLETE	0x00000001
+
+/*
+ *  multi-register-define name HW_DCP_CHnOPTS
+ *              base 0x00000130
+ *              count 4
+ *              offset 0x40
+ */
+#define HW_DCP_CHnOPTS(n)	(0x00000130 + (n) * 0x40)
+#define HW_DCP_CHnOPTS_SET(n)	(0x00000134 + (n) * 0x40)
+#define HW_DCP_CHnOPTS_CLR(n)	(0x00000138 + (n) * 0x40)
+#define HW_DCP_CHnOPTS_TOG(n)	(0x0000013c + (n) * 0x40)
+
+#define BP_DCP_CHnOPTS_RSVD	16
+#define BM_DCP_CHnOPTS_RSVD	0xFFFF0000
+#define BF_DCP_CHnOPTS_RSVD(v) \
+		(((v) << 16) & BM_DCP_CHnOPTS_RSVD)
+#define BP_DCP_CHnOPTS_RECOVERY_TIMER	0
+#define BM_DCP_CHnOPTS_RECOVERY_TIMER	0x0000FFFF
+#define BF_DCP_CHnOPTS_RECOVERY_TIMER(v)  \
+		(((v) << 0) & BM_DCP_CHnOPTS_RECOVERY_TIMER)
+
+#define HW_DCP_CSCCTRL0	(0x00000300)
+#define HW_DCP_CSCCTRL0_SET	(0x00000304)
+#define HW_DCP_CSCCTRL0_CLR	(0x00000308)
+#define HW_DCP_CSCCTRL0_TOG	(0x0000030c)
+
+#define BP_DCP_CSCCTRL0_RSVD1	16
+#define BM_DCP_CSCCTRL0_RSVD1	0xFFFF0000
+#define BF_DCP_CSCCTRL0_RSVD1(v) \
+		(((v) << 16) & BM_DCP_CSCCTRL0_RSVD1)
+#define BM_DCP_CSCCTRL0_CLIP	0x00008000
+#define BM_DCP_CSCCTRL0_UPSAMPLE	0x00004000
+#define BM_DCP_CSCCTRL0_SCALE	0x00002000
+#define BM_DCP_CSCCTRL0_ROTATE	0x00001000
+#define BM_DCP_CSCCTRL0_SUBSAMPLE	0x00000800
+#define BM_DCP_CSCCTRL0_DELTA	0x00000400
+#define BP_DCP_CSCCTRL0_RGB_FORMAT	8
+#define BM_DCP_CSCCTRL0_RGB_FORMAT	0x00000300
+#define BF_DCP_CSCCTRL0_RGB_FORMAT(v)  \
+		(((v) << 8) & BM_DCP_CSCCTRL0_RGB_FORMAT)
+#define BV_DCP_CSCCTRL0_RGB_FORMAT__RGB16_565 0x0
+#define BV_DCP_CSCCTRL0_RGB_FORMAT__YCbCrI    0x1
+#define BV_DCP_CSCCTRL0_RGB_FORMAT__RGB24     0x2
+#define BV_DCP_CSCCTRL0_RGB_FORMAT__YUV422I   0x3
+#define BP_DCP_CSCCTRL0_YUV_FORMAT	4
+#define BM_DCP_CSCCTRL0_YUV_FORMAT	0x000000F0
+#define BF_DCP_CSCCTRL0_YUV_FORMAT(v)  \
+		(((v) << 4) & BM_DCP_CSCCTRL0_YUV_FORMAT)
+#define BV_DCP_CSCCTRL0_YUV_FORMAT__YUV420 0x0
+#define BV_DCP_CSCCTRL0_YUV_FORMAT__YUV422 0x2
+#define BP_DCP_CSCCTRL0_RSVD0	1
+#define BM_DCP_CSCCTRL0_RSVD0	0x0000000E
+#define BF_DCP_CSCCTRL0_RSVD0(v)  \
+		(((v) << 1) & BM_DCP_CSCCTRL0_RSVD0)
+#define BM_DCP_CSCCTRL0_ENABLE	0x00000001
+
+#define HW_DCP_CSCSTAT	(0x00000310)
+#define HW_DCP_CSCSTAT_SET	(0x00000314)
+#define HW_DCP_CSCSTAT_CLR	(0x00000318)
+#define HW_DCP_CSCSTAT_TOG	(0x0000031c)
+
+#define BP_DCP_CSCSTAT_RSVD3	24
+#define BM_DCP_CSCSTAT_RSVD3	0xFF000000
+#define BF_DCP_CSCSTAT_RSVD3(v) \
+		(((v) << 24) & BM_DCP_CSCSTAT_RSVD3)
+#define BP_DCP_CSCSTAT_ERROR_CODE	16
+#define BM_DCP_CSCSTAT_ERROR_CODE	0x00FF0000
+#define BF_DCP_CSCSTAT_ERROR_CODE(v)  \
+		(((v) << 16) & BM_DCP_CSCSTAT_ERROR_CODE)
+#define BV_DCP_CSCSTAT_ERROR_CODE__LUMA0_FETCH_ERROR_Y0 0x01
+#define BV_DCP_CSCSTAT_ERROR_CODE__LUMA1_FETCH_ERROR_Y1 0x02
+#define BV_DCP_CSCSTAT_ERROR_CODE__CHROMA_FETCH_ERROR_U 0x03
+#define BV_DCP_CSCSTAT_ERROR_CODE__CHROMA_FETCH_ERROR_V 0x04
+#define BP_DCP_CSCSTAT_RSVD2	7
+#define BM_DCP_CSCSTAT_RSVD2	0x0000FF80
+#define BF_DCP_CSCSTAT_RSVD2(v)  \
+		(((v) << 7) & BM_DCP_CSCSTAT_RSVD2)
+#define BM_DCP_CSCSTAT_ERROR_PAGEFAULT	0x00000040
+#define BM_DCP_CSCSTAT_ERROR_DST	0x00000020
+#define BM_DCP_CSCSTAT_ERROR_SRC	0x00000010
+#define BM_DCP_CSCSTAT_RSVD1	0x00000008
+#define BM_DCP_CSCSTAT_ERROR_SETUP	0x00000004
+#define BM_DCP_CSCSTAT_RSVD0	0x00000002
+#define BM_DCP_CSCSTAT_COMPLETE	0x00000001
+
+#define HW_DCP_CSCOUTBUFPARAM	(0x00000320)
+
+#define BP_DCP_CSCOUTBUFPARAM_RSVD1	24
+#define BM_DCP_CSCOUTBUFPARAM_RSVD1	0xFF000000
+#define BF_DCP_CSCOUTBUFPARAM_RSVD1(v) \
+		(((v) << 24) & BM_DCP_CSCOUTBUFPARAM_RSVD1)
+#define BP_DCP_CSCOUTBUFPARAM_FIELD_SIZE	12
+#define BM_DCP_CSCOUTBUFPARAM_FIELD_SIZE	0x00FFF000
+#define BF_DCP_CSCOUTBUFPARAM_FIELD_SIZE(v)  \
+		(((v) << 12) & BM_DCP_CSCOUTBUFPARAM_FIELD_SIZE)
+#define BP_DCP_CSCOUTBUFPARAM_LINE_SIZE	0
+#define BM_DCP_CSCOUTBUFPARAM_LINE_SIZE	0x00000FFF
+#define BF_DCP_CSCOUTBUFPARAM_LINE_SIZE(v)  \
+		(((v) << 0) & BM_DCP_CSCOUTBUFPARAM_LINE_SIZE)
+
+#define HW_DCP_CSCINBUFPARAM	(0x00000330)
+
+#define BP_DCP_CSCINBUFPARAM_RSVD1	12
+#define BM_DCP_CSCINBUFPARAM_RSVD1	0xFFFFF000
+#define BF_DCP_CSCINBUFPARAM_RSVD1(v) \
+		(((v) << 12) & BM_DCP_CSCINBUFPARAM_RSVD1)
+#define BP_DCP_CSCINBUFPARAM_LINE_SIZE	0
+#define BM_DCP_CSCINBUFPARAM_LINE_SIZE	0x00000FFF
+#define BF_DCP_CSCINBUFPARAM_LINE_SIZE(v)  \
+		(((v) << 0) & BM_DCP_CSCINBUFPARAM_LINE_SIZE)
+
+#define HW_DCP_CSCRGB	(0x00000340)
+
+#define BP_DCP_CSCRGB_ADDR	0
+#define BM_DCP_CSCRGB_ADDR	0xFFFFFFFF
+#define BF_DCP_CSCRGB_ADDR(v)	(v)
+
+#define HW_DCP_CSCLUMA	(0x00000350)
+
+#define BP_DCP_CSCLUMA_ADDR	0
+#define BM_DCP_CSCLUMA_ADDR	0xFFFFFFFF
+#define BF_DCP_CSCLUMA_ADDR(v)	(v)
+
+#define HW_DCP_CSCCHROMAU	(0x00000360)
+
+#define BP_DCP_CSCCHROMAU_ADDR	0
+#define BM_DCP_CSCCHROMAU_ADDR	0xFFFFFFFF
+#define BF_DCP_CSCCHROMAU_ADDR(v)	(v)
+
+#define HW_DCP_CSCCHROMAV	(0x00000370)
+
+#define BP_DCP_CSCCHROMAV_ADDR	0
+#define BM_DCP_CSCCHROMAV_ADDR	0xFFFFFFFF
+#define BF_DCP_CSCCHROMAV_ADDR(v)	(v)
+
+#define HW_DCP_CSCCOEFF0	(0x00000380)
+
+#define BP_DCP_CSCCOEFF0_RSVD1	26
+#define BM_DCP_CSCCOEFF0_RSVD1	0xFC000000
+#define BF_DCP_CSCCOEFF0_RSVD1(v) \
+		(((v) << 26) & BM_DCP_CSCCOEFF0_RSVD1)
+#define BP_DCP_CSCCOEFF0_C0	16
+#define BM_DCP_CSCCOEFF0_C0	0x03FF0000
+#define BF_DCP_CSCCOEFF0_C0(v)  \
+		(((v) << 16) & BM_DCP_CSCCOEFF0_C0)
+#define BP_DCP_CSCCOEFF0_UV_OFFSET	8
+#define BM_DCP_CSCCOEFF0_UV_OFFSET	0x0000FF00
+#define BF_DCP_CSCCOEFF0_UV_OFFSET(v)  \
+		(((v) << 8) & BM_DCP_CSCCOEFF0_UV_OFFSET)
+#define BP_DCP_CSCCOEFF0_Y_OFFSET	0
+#define BM_DCP_CSCCOEFF0_Y_OFFSET	0x000000FF
+#define BF_DCP_CSCCOEFF0_Y_OFFSET(v)  \
+		(((v) << 0) & BM_DCP_CSCCOEFF0_Y_OFFSET)
+
+#define HW_DCP_CSCCOEFF1	(0x00000390)
+
+#define BP_DCP_CSCCOEFF1_RSVD1	26
+#define BM_DCP_CSCCOEFF1_RSVD1	0xFC000000
+#define BF_DCP_CSCCOEFF1_RSVD1(v) \
+		(((v) << 26) & BM_DCP_CSCCOEFF1_RSVD1)
+#define BP_DCP_CSCCOEFF1_C1	16
+#define BM_DCP_CSCCOEFF1_C1	0x03FF0000
+#define BF_DCP_CSCCOEFF1_C1(v)  \
+		(((v) << 16) & BM_DCP_CSCCOEFF1_C1)
+#define BP_DCP_CSCCOEFF1_RSVD0	10
+#define BM_DCP_CSCCOEFF1_RSVD0	0x0000FC00
+#define BF_DCP_CSCCOEFF1_RSVD0(v)  \
+		(((v) << 10) & BM_DCP_CSCCOEFF1_RSVD0)
+#define BP_DCP_CSCCOEFF1_C4	0
+#define BM_DCP_CSCCOEFF1_C4	0x000003FF
+#define BF_DCP_CSCCOEFF1_C4(v)  \
+		(((v) << 0) & BM_DCP_CSCCOEFF1_C4)
+
+#define HW_DCP_CSCCOEFF2	(0x000003a0)
+
+#define BP_DCP_CSCCOEFF2_RSVD1	26
+#define BM_DCP_CSCCOEFF2_RSVD1	0xFC000000
+#define BF_DCP_CSCCOEFF2_RSVD1(v) \
+		(((v) << 26) & BM_DCP_CSCCOEFF2_RSVD1)
+#define BP_DCP_CSCCOEFF2_C2	16
+#define BM_DCP_CSCCOEFF2_C2	0x03FF0000
+#define BF_DCP_CSCCOEFF2_C2(v)  \
+		(((v) << 16) & BM_DCP_CSCCOEFF2_C2)
+#define BP_DCP_CSCCOEFF2_RSVD0	10
+#define BM_DCP_CSCCOEFF2_RSVD0	0x0000FC00
+#define BF_DCP_CSCCOEFF2_RSVD0(v)  \
+		(((v) << 10) & BM_DCP_CSCCOEFF2_RSVD0)
+#define BP_DCP_CSCCOEFF2_C3	0
+#define BM_DCP_CSCCOEFF2_C3	0x000003FF
+#define BF_DCP_CSCCOEFF2_C3(v)  \
+		(((v) << 0) & BM_DCP_CSCCOEFF2_C3)
+
+#define HW_DCP_CSCCLIP	(0x000003d0)
+
+#define BP_DCP_CSCCLIP_RSVD1	24
+#define BM_DCP_CSCCLIP_RSVD1	0xFF000000
+#define BF_DCP_CSCCLIP_RSVD1(v) \
+		(((v) << 24) & BM_DCP_CSCCLIP_RSVD1)
+#define BP_DCP_CSCCLIP_HEIGHT	12
+#define BM_DCP_CSCCLIP_HEIGHT	0x00FFF000
+#define BF_DCP_CSCCLIP_HEIGHT(v)  \
+		(((v) << 12) & BM_DCP_CSCCLIP_HEIGHT)
+#define BP_DCP_CSCCLIP_WIDTH	0
+#define BM_DCP_CSCCLIP_WIDTH	0x00000FFF
+#define BF_DCP_CSCCLIP_WIDTH(v)  \
+		(((v) << 0) & BM_DCP_CSCCLIP_WIDTH)
+
+#define HW_DCP_CSCXSCALE	(0x000003e0)
+
+#define BP_DCP_CSCXSCALE_RSVD1	26
+#define BM_DCP_CSCXSCALE_RSVD1	0xFC000000
+#define BF_DCP_CSCXSCALE_RSVD1(v) \
+		(((v) << 26) & BM_DCP_CSCXSCALE_RSVD1)
+#define BP_DCP_CSCXSCALE_INT	24
+#define BM_DCP_CSCXSCALE_INT	0x03000000
+#define BF_DCP_CSCXSCALE_INT(v)  \
+		(((v) << 24) & BM_DCP_CSCXSCALE_INT)
+#define BP_DCP_CSCXSCALE_FRAC	12
+#define BM_DCP_CSCXSCALE_FRAC	0x00FFF000
+#define BF_DCP_CSCXSCALE_FRAC(v)  \
+		(((v) << 12) & BM_DCP_CSCXSCALE_FRAC)
+#define BP_DCP_CSCXSCALE_WIDTH	0
+#define BM_DCP_CSCXSCALE_WIDTH	0x00000FFF
+#define BF_DCP_CSCXSCALE_WIDTH(v)  \
+		(((v) << 0) & BM_DCP_CSCXSCALE_WIDTH)
+
+#define HW_DCP_CSCYSCALE	(0x000003f0)
+
+#define BP_DCP_CSCYSCALE_RSVD1	26
+#define BM_DCP_CSCYSCALE_RSVD1	0xFC000000
+#define BF_DCP_CSCYSCALE_RSVD1(v) \
+		(((v) << 26) & BM_DCP_CSCYSCALE_RSVD1)
+#define BP_DCP_CSCYSCALE_INT	24
+#define BM_DCP_CSCYSCALE_INT	0x03000000
+#define BF_DCP_CSCYSCALE_INT(v)  \
+		(((v) << 24) & BM_DCP_CSCYSCALE_INT)
+#define BP_DCP_CSCYSCALE_FRAC	12
+#define BM_DCP_CSCYSCALE_FRAC	0x00FFF000
+#define BF_DCP_CSCYSCALE_FRAC(v)  \
+		(((v) << 12) & BM_DCP_CSCYSCALE_FRAC)
+#define BP_DCP_CSCYSCALE_HEIGHT	0
+#define BM_DCP_CSCYSCALE_HEIGHT	0x00000FFF
+#define BF_DCP_CSCYSCALE_HEIGHT(v)  \
+		(((v) << 0) & BM_DCP_CSCYSCALE_HEIGHT)
+
+#define HW_DCP_DBGSELECT	(0x00000400)
+
+#define BP_DCP_DBGSELECT_RSVD	8
+#define BM_DCP_DBGSELECT_RSVD	0xFFFFFF00
+#define BF_DCP_DBGSELECT_RSVD(v) \
+		(((v) << 8) & BM_DCP_DBGSELECT_RSVD)
+#define BP_DCP_DBGSELECT_INDEX	0
+#define BM_DCP_DBGSELECT_INDEX	0x000000FF
+#define BF_DCP_DBGSELECT_INDEX(v)  \
+		(((v) << 0) & BM_DCP_DBGSELECT_INDEX)
+#define BV_DCP_DBGSELECT_INDEX__CONTROL 0x01
+#define BV_DCP_DBGSELECT_INDEX__OTPKEY0 0x10
+#define BV_DCP_DBGSELECT_INDEX__OTPKEY1 0x11
+#define BV_DCP_DBGSELECT_INDEX__OTPKEY2 0x12
+#define BV_DCP_DBGSELECT_INDEX__OTPKEY3 0x13
+
+#define HW_DCP_DBGDATA	(0x00000410)
+
+#define BP_DCP_DBGDATA_DATA	0
+#define BM_DCP_DBGDATA_DATA	0xFFFFFFFF
+#define BF_DCP_DBGDATA_DATA(v)	(v)
+
+#define HW_DCP_PAGETABLE	(0x00000420)
+
+#define BP_DCP_PAGETABLE_BASE	2
+#define BM_DCP_PAGETABLE_BASE	0xFFFFFFFC
+#define BF_DCP_PAGETABLE_BASE(v) \
+		(((v) << 2) & BM_DCP_PAGETABLE_BASE)
+#define BM_DCP_PAGETABLE_FLUSH	0x00000002
+#define BM_DCP_PAGETABLE_ENABLE	0x00000001
+
+#define HW_DCP_VERSION	(0x00000430)
+
+#define BP_DCP_VERSION_MAJOR	24
+#define BM_DCP_VERSION_MAJOR	0xFF000000
+#define BF_DCP_VERSION_MAJOR(v) \
+		(((v) << 24) & BM_DCP_VERSION_MAJOR)
+#define BP_DCP_VERSION_MINOR	16
+#define BM_DCP_VERSION_MINOR	0x00FF0000
+#define BF_DCP_VERSION_MINOR(v)  \
+		(((v) << 16) & BM_DCP_VERSION_MINOR)
+#define BP_DCP_VERSION_STEP	0
+#define BM_DCP_VERSION_STEP	0x0000FFFF
+#define BF_DCP_VERSION_STEP(v)  \
+		(((v) << 0) & BM_DCP_VERSION_STEP)
+
+#endif
-- 
1.7.9.5



From shawn.guo at linaro.org  Tue Apr 23 08:20:10 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 23 Apr 2013 20:20:10 +0800
Subject: [PATCH V4] ARM: i.MX5: Allow DT clock providers
In-Reply-To: <20130423091633.22088.58225.stgit@localhost>
References: <20130423091633.22088.58225.stgit@localhost>
Message-ID: <20130423122007.GE27475@S2101-09.ap.freescale.net>

On Tue, Apr 23, 2013 at 11:16:33AM +0200, Martin Fuzzey wrote:
> Currently clock providers defined in the DT are not registered
> on i.MX5 platforms since of_clk_init() is not called.
> 
> This is not a problem for the SOC's own clocks, which are registered
> in code,  but prevents the DT being used to define clocks for external
> hardware.
> 
> Fix this by calling of_clk_init() and actually using the DT to obtain
> the 4 SOC fixed clocks.
> These are already defined in the DT but were previously just used to
> manually obtain the rate.
> 
> Fall back to the old scheme for non DT platforms.
> 
> Since the same method may be useful for other i.MX platforms
> implement the imx_obtain_fixed_clock() function in common code.
> 
> Actually changing other i.MX platforms to use this should be done
> later by someone with access to the appropriate hardware.
> 
> Signed-off-by: Martin Fuzzey <mfuzzey at parkeon.com>
> Tested-by: Fabio Estevam <fabio.estevam at freescale.com>

Applied with a small fixup below.

> 
> ---
> Changelog:
> V2: Applied comments from Sascha Hauer:
> 	* Use kasprintf instead of scnprintf to avoid length limit
> 	* Avoid use of IS_ERR_OR_NULL
> 
> V3: Applied comments from Shawn Guo:
> 	* Find clocks by path rather than compatible string
> 	* Remove unnecessary #ifdef CONFIG_OF
> 
> V4:
> 	* Moved clock obtention function to mach-imx/clk.c to allow use by
> 		other imx platforms (request from Sascha)
> 	* Added Tested-by from Fabio Estevam
> ---
>  arch/arm/mach-imx/clk-imx51-imx53.c |   44 ++++++-----------------------------
>  arch/arm/mach-imx/clk.c             |   37 +++++++++++++++++++++++++++++
>  arch/arm/mach-imx/clk.h             |    3 ++
>  3 files changed, 48 insertions(+), 36 deletions(-)
> 
> diff --git a/arch/arm/mach-imx/clk-imx51-imx53.c b/arch/arm/mach-imx/clk-imx51-imx53.c
> index 3228b4e..debd76d 100644
> --- a/arch/arm/mach-imx/clk-imx51-imx53.c
> +++ b/arch/arm/mach-imx/clk-imx51-imx53.c
> @@ -123,11 +123,13 @@ static void __init mx5_clocks_common_init(unsigned long rate_ckil,
>  {
>  	int i;
>  
> +	of_clk_init(NULL);
> +
>  	clk[dummy] = imx_clk_fixed("dummy", 0);
> -	clk[ckil] = imx_clk_fixed("ckil", rate_ckil);
> -	clk[osc] = imx_clk_fixed("osc", rate_osc);
> -	clk[ckih1] = imx_clk_fixed("ckih1", rate_ckih1);
> -	clk[ckih2] = imx_clk_fixed("ckih2", rate_ckih2);
> +	clk[ckil] = imx_obtain_fixed_clock("ckil", rate_ckil);
> +	clk[osc] = imx_obtain_fixed_clock("osc", rate_osc);
> +	clk[ckih1] = imx_obtain_fixed_clock("ckih1", rate_ckih1);
> +	clk[ckih2] = imx_obtain_fixed_clock("ckih2", rate_ckih2);
>  
>  	clk[lp_apm] = imx_clk_mux("lp_apm", MXC_CCM_CCSR, 9, 1,
>  				lp_apm_sel, ARRAY_SIZE(lp_apm_sel));
> @@ -539,42 +541,12 @@ int __init mx53_clocks_init(unsigned long rate_ckil, unsigned long rate_osc,
>  	return of_clk_configure();
>  }
>  
> -#ifdef CONFIG_OF
> -static void __init clk_get_freq_dt(unsigned long *ckil, unsigned long *osc,
> -				   unsigned long *ckih1, unsigned long *ckih2)
> -{
> -	struct device_node *np;
> -
> -	/* retrieve the freqency of fixed clocks from device tree */
> -	for_each_compatible_node(np, NULL, "fixed-clock") {
> -		u32 rate;
> -		if (of_property_read_u32(np, "clock-frequency", &rate))
> -			continue;
> -
> -		if (of_device_is_compatible(np, "fsl,imx-ckil"))
> -			*ckil = rate;
> -		else if (of_device_is_compatible(np, "fsl,imx-osc"))
> -			*osc = rate;
> -		else if (of_device_is_compatible(np, "fsl,imx-ckih1"))
> -			*ckih1 = rate;
> -		else if (of_device_is_compatible(np, "fsl,imx-ckih2"))
> -			*ckih2 = rate;
> -	}
> -}
> -
>  int __init mx51_clocks_init_dt(void)
>  {
> -	unsigned long ckil, osc, ckih1, ckih2;
> -
> -	clk_get_freq_dt(&ckil, &osc, &ckih1, &ckih2);
> -	return mx51_clocks_init(ckil, osc, ckih1, ckih2);
> +	return mx51_clocks_init(0, 0, 0, 0);
>  }
>  
>  int __init mx53_clocks_init_dt(void)
>  {
> -	unsigned long ckil, osc, ckih1, ckih2;
> -
> -	clk_get_freq_dt(&ckil, &osc, &ckih1, &ckih2);
> -	return mx53_clocks_init(ckil, osc, ckih1, ckih2);
> +	return mx53_clocks_init(0, 0, 0, 0);
>  }
> -#endif
> diff --git a/arch/arm/mach-imx/clk.c b/arch/arm/mach-imx/clk.c
> index f5e8be8..f2c73f2 100644
> --- a/arch/arm/mach-imx/clk.c
> +++ b/arch/arm/mach-imx/clk.c
> @@ -1,3 +1,40 @@
> +#include <linux/clk.h>
> +#include <linux/err.h>
> +#include <linux/of.h>
> +#include <linux/slab.h>
>  #include <linux/spinlock.h>
>  
> +#include "clk.h"
> +
>  DEFINE_SPINLOCK(imx_ccm_lock);
> +
> +static struct clk * __init imx_obtain_fixed_clock_from_dt(const char *name)
> +{
> +	struct of_phandle_args phandle = {0};
> +	struct clk *clk = ERR_PTR(-ENODEV);
> +	char *path;
> +
> +	path = kasprintf(GFP_KERNEL, "/clocks/%s", name);
> +	if (!path)
> +		return ERR_PTR(-ENOMEM);
> +
> +	phandle.np = of_find_node_by_path(path);
> +	kfree(path);
> +
> +	if (phandle.np) {
> +		clk = of_clk_get_from_provider(&phandle);
> +		of_node_put(phandle.np);
> +	}
> +	return clk;
> +}
> +
> +struct clk * __init imx_obtain_fixed_clock(
> +			const char *name, unsigned long rate)
> +{
> +	struct clk *clk;
> +
> +	clk = imx_obtain_fixed_clock_from_dt(name);
> +	if (IS_ERR(clk))
> +		clk = imx_clk_fixed(name, rate);
> +	return clk;
> +}
> diff --git a/arch/arm/mach-imx/clk.h b/arch/arm/mach-imx/clk.h
> index d9d9d9c..780fd67 100644
> --- a/arch/arm/mach-imx/clk.h
> +++ b/arch/arm/mach-imx/clk.h
> @@ -29,6 +29,9 @@ struct clk *clk_register_gate2(struct device *dev, const char *name,
>  		void __iomem *reg, u8 bit_idx,
>  		u8 clk_gate_flags, spinlock_t *lock);
>  
> +struct clk * __init imx_obtain_fixed_clock(

The __init annotation is not needed for function declaration, so I just
removed it.

Shawn

> +			const char *name, unsigned long rate);
> +
>  static inline struct clk *imx_clk_gate2(const char *name, const char *parent,
>  		void __iomem *reg, u8 shift)
>  {
> 



From robherring2 at gmail.com  Tue Apr 23 08:19:50 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Tue, 23 Apr 2013 07:19:50 -0500
Subject: [V4 patch 03/15] cpuidle: make a single register function for all
In-Reply-To: <1366707285-12179-4-git-send-email-daniel.lezcano@linaro.org>
References: <1366707285-12179-1-git-send-email-daniel.lezcano@linaro.org>
 <1366707285-12179-4-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <51767C66.7010102@gmail.com>

On 04/23/2013 03:54 AM, Daniel Lezcano wrote:
> The usual scheme to initialize a cpuidle driver on a SMP is:
> 
> 	cpuidle_register_driver(drv);
> 	for_each_possible_cpu(cpu) {
> 		device = &per_cpu(cpuidle_dev, cpu);
> 		cpuidle_register_device(device);
> 	}
> 
> This code is duplicated in each cpuidle driver.
> 
> On UP systems, it is done this way:
> 
> 	cpuidle_register_driver(drv);
> 	device = &per_cpu(cpuidle_dev, cpu);
> 	cpuidle_register_device(device);
> 
> On UP, the macro 'for_each_cpu' does one iteration:
> 
> #define for_each_cpu(cpu, mask)                 \
>         for ((cpu) = 0; (cpu) < 1; (cpu)++, (void)mask)
> 
> Hence, the initialization loop is the same for UP than SMP.
> 
> Beside, we saw different bugs / mis-initialization / return code unchecked in
> the different drivers, the code is duplicated including bugs. After fixing all
> these ones, it appears the initialization pattern is the same for everyone.
> 
> Please note, some drivers are doing dev->state_count = drv->state_count. This is
> not necessary because it is done by the cpuidle_enable_device function in the
> cpuidle framework. This is true, until you have the same states for all your
> devices. Otherwise, the 'low level' API should be used instead with the specific
> initialization for the driver.
> 
> Let's add a wrapper function doing this initialization with a cpumask parameter
> for the coupled idle states and use it for all the drivers.
> 
> That will save a lot of LOC, consolidate the code, and the modifications in the
> future could be done in a single place. Another benefit is the consolidation of
> the cpuidle_device variable which is now in the cpuidle framework and no longer
> spread accross the different arch specific drivers.
> 
> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>

Reviewed-by: Rob Herring <rob.herring at calxeda.com>

> ---
>  Documentation/cpuidle/driver.txt |    6 ++++
>  drivers/cpuidle/cpuidle.c        |   72 ++++++++++++++++++++++++++++++++++++++
>  include/linux/cpuidle.h          |    9 +++--
>  3 files changed, 85 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/cpuidle/driver.txt b/Documentation/cpuidle/driver.txt
> index 7a9e09e..1b0d81d 100644
> --- a/Documentation/cpuidle/driver.txt
> +++ b/Documentation/cpuidle/driver.txt
> @@ -15,11 +15,17 @@ has mechanisms in place to support actual entry-exit into CPU idle states.
>  cpuidle driver initializes the cpuidle_device structure for each CPU device
>  and registers with cpuidle using cpuidle_register_device.
>  
> +If all the idle states are the same, the wrapper function cpuidle_register
> +could be used instead.
> +
>  It can also support the dynamic changes (like battery <-> AC), by using
>  cpuidle_pause_and_lock, cpuidle_disable_device and cpuidle_enable_device,
>  cpuidle_resume_and_unlock.
>  
>  Interfaces:
> +extern int cpuidle_register(struct cpuidle_driver *drv,
> +                            const struct cpumask *const coupled_cpus);
> +extern int cpuidle_unregister(struct cpuidle_driver *drv);
>  extern int cpuidle_register_driver(struct cpuidle_driver *drv);
>  extern void cpuidle_unregister_driver(struct cpuidle_driver *drv);
>  extern int cpuidle_register_device(struct cpuidle_device *dev);
> diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
> index 0da795b..49e8d30 100644
> --- a/drivers/cpuidle/cpuidle.c
> +++ b/drivers/cpuidle/cpuidle.c
> @@ -24,6 +24,7 @@
>  #include "cpuidle.h"
>  
>  DEFINE_PER_CPU(struct cpuidle_device *, cpuidle_devices);
> +DEFINE_PER_CPU(struct cpuidle_device, cpuidle_dev);
>  
>  DEFINE_MUTEX(cpuidle_lock);
>  LIST_HEAD(cpuidle_detected_devices);
> @@ -453,6 +454,77 @@ void cpuidle_unregister_device(struct cpuidle_device *dev)
>  
>  EXPORT_SYMBOL_GPL(cpuidle_unregister_device);
>  
> +/*
> + * cpuidle_unregister: unregister a driver and the devices. This function
> + * can be used only if the driver has been previously registered through
> + * the cpuidle_register function.
> + *
> + * @drv: a valid pointer to a struct cpuidle_driver
> + */
> +void cpuidle_unregister(struct cpuidle_driver *drv)
> +{
> +	int cpu;
> +	struct cpuidle_device *device;
> +
> +	for_each_possible_cpu(cpu) {
> +		device = &per_cpu(cpuidle_dev, cpu);
> +		cpuidle_unregister_device(device);
> +	}
> +
> +	cpuidle_unregister_driver(drv);
> +}
> +EXPORT_SYMBOL_GPL(cpuidle_unregister);
> +
> +/**
> + * cpuidle_register: registers the driver and the cpu devices with the
> + * coupled_cpus passed as parameter. This function is used for all common
> + * initialization pattern there are in the arch specific drivers. The
> + * devices is globally defined in this file.
> + *
> + * @drv         : a valid pointer to a struct cpuidle_driver
> + * @coupled_cpus: a cpumask for the coupled states
> + *
> + * Returns 0 on success, < 0 otherwise
> + */
> +int cpuidle_register(struct cpuidle_driver *drv,
> +		     const struct cpumask *const coupled_cpus)
> +{
> +	int ret, cpu;
> +	struct cpuidle_device *device;
> +
> +	ret = cpuidle_register_driver(drv);
> +	if (ret) {
> +		pr_err("failed to register cpuidle driver\n");
> +		return ret;
> +	}
> +
> +	for_each_possible_cpu(cpu) {
> +		device = &per_cpu(cpuidle_dev, cpu);
> +		device->cpu = cpu;
> +
> +#ifdef CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED
> +		/*
> +		 * On multiplatform for ARM, the coupled idle states could
> +		 * enabled in the kernel even if the cpuidle driver does not
> +		 * use it. Note, coupled_cpus is a struct copy.
> +		 */
> +		if (coupled_cpus)
> +			device->coupled_cpus = *coupled_cpus;
> +#endif
> +		ret = cpuidle_register_device(device);
> +		if (!ret)
> +			continue;
> +
> +		pr_err("Failed to register cpuidle device for cpu%d\n", cpu);
> +
> +		cpuidle_unregister(drv);
> +		break;
> +	}
> +
> +	return ret;
> +}
> +EXPORT_SYMBOL_GPL(cpuidle_register);
> +
>  #ifdef CONFIG_SMP
>  
>  static void smp_callback(void *v)
> diff --git a/include/linux/cpuidle.h b/include/linux/cpuidle.h
> index 79e3811..3c86faa 100644
> --- a/include/linux/cpuidle.h
> +++ b/include/linux/cpuidle.h
> @@ -123,7 +123,9 @@ extern void cpuidle_driver_unref(void);
>  extern void cpuidle_unregister_driver(struct cpuidle_driver *drv);
>  extern int cpuidle_register_device(struct cpuidle_device *dev);
>  extern void cpuidle_unregister_device(struct cpuidle_device *dev);
> -
> +extern int cpuidle_register(struct cpuidle_driver *drv,
> +			    const struct cpumask *const coupled_cpus);
> +extern void cpuidle_unregister(struct cpuidle_driver *drv);
>  extern void cpuidle_pause_and_lock(void);
>  extern void cpuidle_resume_and_unlock(void);
>  extern void cpuidle_pause(void);
> @@ -148,7 +150,10 @@ static inline void cpuidle_unregister_driver(struct cpuidle_driver *drv) { }
>  static inline int cpuidle_register_device(struct cpuidle_device *dev)
>  {return -ENODEV; }
>  static inline void cpuidle_unregister_device(struct cpuidle_device *dev) { }
> -
> +static inline int cpuidle_register(struct cpuidle_driver *drv,
> +				   const struct cpumask *const coupled_cpus)
> +{return -ENODEV; }
> +static inline void cpuidle_unregister(struct cpuidle_driver *drv) { }
>  static inline void cpuidle_pause_and_lock(void) { }
>  static inline void cpuidle_resume_and_unlock(void) { }
>  static inline void cpuidle_pause(void) { }
> 



From shawn.guo at linaro.org  Tue Apr 23 08:22:41 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 23 Apr 2013 20:22:41 +0800
Subject: [PATCH V2] ARM: mx5: Add support for DENX M53EVK
In-Reply-To: <1366665827-8949-1-git-send-email-marex@denx.de>
References: <1366665827-8949-1-git-send-email-marex@denx.de>
Message-ID: <20130423122239.GF27475@S2101-09.ap.freescale.net>

On Mon, Apr 22, 2013 at 11:23:47PM +0200, Marek Vasut wrote:
> This patch adds support for the DENX M53EVK board. The board currently supports
> NAND, Ethernet, UART, CAN, I2C.
> 
> Signed-off-by: Marek Vasut <marex at denx.de>

Applied, thanks.



From rickard.andersson at stericsson.com  Tue Apr 23 08:26:10 2013
From: rickard.andersson at stericsson.com (Rickard Andersson)
Date: Tue, 23 Apr 2013 14:26:10 +0200
Subject: [PATCH V2 03/12] PM / Domains: Add on-off notifiers
In-Reply-To: <3261022.s2M99fPNjC@vostro.rjw.lan>
References: <1364487098-10319-1-git-send-email-rickard.andersson@stericsson.com>
 <1364487098-10319-4-git-send-email-rickard.andersson@stericsson.com>
 <3261022.s2M99fPNjC@vostro.rjw.lan>
Message-ID: <51767DE2.7050203@stericsson.com>

On 03/31/2013 12:17 AM, Rafael J. Wysocki wrote:
> On Thursday, March 28, 2013 05:11:29 PM Rickard Andersson wrote:
>> Some drivers needs to restore their context directly
>> when a power domain is activated. For example a driver
>> handling system bus settings must be able to restore
>> context before the bus is being used for the first time.
>> Other examples could be clock settings hardware blocks and
>> special debugging hardware blocks which should be restored
>> as early as possible in order to be able to debug direcly
>> from waking up. Typically these notifers are needed in
>> systems with CPU coupled power domains. The notifiers
>> are intended to be trigged by cpuidle driver or the
>> suspend ops hooks.
>>
>> The drivers that needs to use these notifiers are
>> some special cases. Most drivers should not use this
>> method and instead control their context via the
>> pm_runtime interface.
>>
>> Signed-off-by: Rickard Andersson<rickard.andersson at stericsson.com>
>> ---
>> I believe notifiers are the best solution to the problem of
>> restoring context early when waking up after sleep.
> I don't.

Some motivation would be good.
>> It is similar to what is done in /kernel/cpu_pm.c
> Which is causing tons of problems to happen.

What type of problems have you seen with the notifiers in 
"/kernel/cpu_pm.c"?
>> but but for a generic power domain instead.
> Which has a potential of being even worse.
>
>> An alternative solution could be to try to call the drivers
>> runtime_resume/runtime_suspend callbacks instead via genpd
>> from cpuidle or suspend/resume. I do not recommend that
>> solution for the following reasons:
>>
>> * Altered use of runtime PM. As it is today the driver itself
>>    controls when to runtime-suspend/runtime-resume.
> That's not correct.
>
>> * Runtime PM is disabled during late stages of suspend.
>> * Complicates runtime PM for a few special cases.
> Well, quite frankly, it is hard to say what problem this is supposed to
> address from your description.  Care to give some more details?
>
> Rafael
The problem is that some hardware blocks needs to be restored as early 
as possible after leaving the U8500 CPU coupled sleep state ApSleep (APE 
power domain being off). This is comparable to CPU needing early restore 
using "/kernel/cpu_pm.c" but for the APE power domain instead.
One could argue that one should save/restore the context directly in the 
cpuidle driver instead but that means duplicated code since hardware 
block registers will be modified both in the block driver and in the 
cpuidle driver. With the notifiers solution the cpuidle driver does not 
need to be aware of which hardware blocks that is being included in the 
APE power domain (needing early context restore), it is the same for 
system suspend/resume. Cpuidle and system suspend/resume should use the 
function pm_genpd_notify_power_on_off(..) to tell the system that it 
will change/has changed the state of a certain power domain.
Note that only a few of the hardware blocks in the APE power domain 
needs to use these notifiers, most drivers will do fine using pm_runtime.

If you for example look at patch "[PATCH V2 06/12] clk: ux500: Add PRCC 
power management" you can see that all PRCC clock registers are handled 
in the clock driver. There is no need to put duplicated code handling 
clocks context in "/arch/arm/mach-ux500/" for suspend/resume and 
cpuidle. Clock settings should be set directly as soon as possible after 
leaving the sleep state ApSleep, that is why the notifiers are being used.

If you do not think this mechanism is a way forward then please advice 
how you think is should be solved.

Thanks
Rickard
>
>> ---
>>   drivers/base/power/domain.c | 63 +++++++++++++++++++++++++++++++++++++++++++++
>>   include/linux/pm_domain.h   | 22 ++++++++++++++++
>>   2 files changed, 85 insertions(+)
>>
>> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
>> index acc3a8d..91e3b7d 100644
>> --- a/drivers/base/power/domain.c
>> +++ b/drivers/base/power/domain.c
>> @@ -1956,6 +1956,68 @@ int pm_genpd_name_detach_cpuidle(const char *name)
>>   	return pm_genpd_detach_cpuidle(pm_genpd_lookup_name(name));
>>   }
>>
>> +/**
>> + * pm_genpd_register_on_off_notifier - Register to early power on /
>> + * late power off notifications.
>> + * Only use this function if absolutly needed. It is only intended to be
>> + * used for power domains that are coupled with the CPU, that is, power
>> + * domains being controlled from cpuidle and the platform suspend ops hooks.
>> + * Also only devices that needs their context to be restored directly when
>> + * leaving a sleep state should use this method. Most devices should be
>> + * fine handling their context and power domains via pm_runtime.
>> + * @dev: Device to register.
>> + * @nb: Notifier block to be registered.
>> + */
>> +int pm_genpd_register_on_off_notifier(struct device *dev,
>> +				      struct notifier_block *nb)
>> +{
>> +	struct generic_pm_domain *genpd;
>> +
>> +	dev_dbg(dev, "%s()\n", __func__);
>> +
>> +	genpd = dev_to_genpd(dev);
>> +
>> +	return atomic_notifier_chain_register(&genpd->on_off_notifier, nb);
>> +}
>> +
>> +/**
>> + * pm_genpd_unregister_on_off_notifier - Unregister to early power on /
>> + * late power off notification.
>> + * @dev: Device to unregister.
>> + * @nb: Notifier block to be unregistered.
>> + */
>> +int pm_genpd_unregister_on_off_notifier(struct device *dev,
>> +					struct notifier_block *nb)
>> +{
>> +	struct generic_pm_domain *genpd;
>> +
>> +	dev_dbg(dev, "%s()\n", __func__);
>> +
>> +	genpd = dev_to_genpd(dev);
>> +
>> +	return atomic_notifier_chain_unregister(&genpd->on_off_notifier, nb);
>> +}
>> +
>> +/**
>> + * pm_genpd_notify_power_on_off - Notify that the CPU coupled power
>> + * domain is going to be powered off or has been powered on.5D
>> + * Intended users of this function are cpuidle drivers and the platform
>> + * suspend operations implementation.
>> + * @genpd: pm domain that will change state.
>> + * @power_on_off: true = has been powered on, false = will power off.
>> + */
>> +int pm_genpd_notify_power_on_off(struct generic_pm_domain *genpd,
>> +				 bool power_on_off)
>> +{
>> +	if (IS_ERR_OR_NULL(genpd))
>> +		return -EINVAL;
>> +
>> +	atomic_notifier_call_chain((&genpd->on_off_notifier),
>> +				   power_on_off, NULL);
>> +
>> +	return 0;
>> +}
>> +
>>   /* Default device callbacks for generic PM domains. */
>>
>>   /**
>> @@ -2137,6 +2199,7 @@ void pm_genpd_init(struct generic_pm_domain *genpd,
>>   	atomic_set(&genpd->sd_count, 0);
>>   	genpd->status = is_off ? GPD_STATE_POWER_OFF : GPD_STATE_ACTIVE;
>>   	init_waitqueue_head(&genpd->status_wait_queue);
>> +	ATOMIC_INIT_NOTIFIER_HEAD(&genpd->on_off_notifier);
>>   	genpd->poweroff_task = NULL;
>>   	genpd->resume_count = 0;
>>   	genpd->device_count = 0;
>> diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
>> index 7c1d252..bf5e7d514 100644
>> --- a/include/linux/pm_domain.h
>> +++ b/include/linux/pm_domain.h
>> @@ -82,6 +82,7 @@ struct generic_pm_domain {
>>   	bool cached_power_down_ok;
>>   	struct device_node *of_node; /* Node in device tree */
>>   	struct gpd_cpu_data *cpu_data;
>> +	struct atomic_notifier_head on_off_notifier;
>>   };
>>
>>   static inline struct generic_pm_domain *pd_to_genpd(struct dev_pm_domain *pd)
>> @@ -159,6 +160,12 @@ extern int pm_genpd_attach_cpuidle(struct generic_pm_domain *genpd, int state);
>>   extern int pm_genpd_name_attach_cpuidle(const char *name, int state);
>>   extern int pm_genpd_detach_cpuidle(struct generic_pm_domain *genpd);
>>   extern int pm_genpd_name_detach_cpuidle(const char *name);
>> +extern int pm_genpd_register_on_off_notifier(struct device *dev,
>> +					     struct notifier_block *nb);
>> +extern int pm_genpd_unregister_on_off_notifier(struct device *dev,
>> +					struct notifier_block *nb);
>> +extern int pm_genpd_notify_power_on_off(struct generic_pm_domain *genpd,
>> +				  bool power_on_off);
>>   extern void pm_genpd_init(struct generic_pm_domain *genpd,
>>   			  struct dev_power_governor *gov, bool is_off);
>>
>> @@ -243,6 +250,21 @@ static inline int pm_genpd_name_detach_cpuidle(const char *name)
>>   {
>>   	return -ENOSYS;
>>   }
>> +static inline int pm_genpd_register_on_off_notifier(struct device *dev,
>> +						    struct notifier_block *nb)
>> +{
>> +	return -ENOSYS;
>> +}
>> +static inline int pm_genpd_unregister_on_off_notifier(struct device *dev,
>> +						      struct notifier_block *nb)
>> +{
>> +	return -ENOSYS;
>> +}
>> +static inline int pm_genpd_notify_power_on_off(struct generic_pm_domain *genpd,
>> +					       bool power_on_off)
>> +{
>> +	return -ENOSYS;
>> +}
>>   static inline void pm_genpd_init(struct generic_pm_domain *genpd,
>>   				 struct dev_power_governor *gov, bool is_off)
>>   {
>>



From santosh.shilimkar at ti.com  Tue Apr 23 08:32:23 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Tue, 23 Apr 2013 18:02:23 +0530
Subject: [V4 patch 03/15] cpuidle: make a single register function for all
In-Reply-To: <1366707285-12179-4-git-send-email-daniel.lezcano@linaro.org>
References: <1366707285-12179-1-git-send-email-daniel.lezcano@linaro.org>
 <1366707285-12179-4-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <51767F57.7060809@ti.com>

On Tuesday 23 April 2013 02:24 PM, Daniel Lezcano wrote:
> The usual scheme to initialize a cpuidle driver on a SMP is:
> 
> 	cpuidle_register_driver(drv);
> 	for_each_possible_cpu(cpu) {
> 		device = &per_cpu(cpuidle_dev, cpu);
> 		cpuidle_register_device(device);
> 	}
> 
> This code is duplicated in each cpuidle driver.
> 
> On UP systems, it is done this way:
> 
> 	cpuidle_register_driver(drv);
> 	device = &per_cpu(cpuidle_dev, cpu);
> 	cpuidle_register_device(device);
> 
> On UP, the macro 'for_each_cpu' does one iteration:
> 
> #define for_each_cpu(cpu, mask)                 \
>         for ((cpu) = 0; (cpu) < 1; (cpu)++, (void)mask)
> 
> Hence, the initialization loop is the same for UP than SMP.
> 
> Beside, we saw different bugs / mis-initialization / return code unchecked in
> the different drivers, the code is duplicated including bugs. After fixing all
> these ones, it appears the initialization pattern is the same for everyone.
> 
> Please note, some drivers are doing dev->state_count = drv->state_count. This is
> not necessary because it is done by the cpuidle_enable_device function in the
> cpuidle framework. This is true, until you have the same states for all your
> devices. Otherwise, the 'low level' API should be used instead with the specific
> initialization for the driver.
> 
> Let's add a wrapper function doing this initialization with a cpumask parameter
> for the coupled idle states and use it for all the drivers.
> 
> That will save a lot of LOC, consolidate the code, and the modifications in the
> future could be done in a single place. Another benefit is the consolidation of
> the cpuidle_device variable which is now in the cpuidle framework and no longer
> spread accross the different arch specific drivers.
> 
> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
> ---

I don't see you have addressed the comment on V3 [1] i gave for the subject patch
Any reason ?

Regards,
Santosh

[1] https://patchwork.kernel.org/patch/2435281/



From r.schwebel at pengutronix.de  Tue Apr 23 08:34:08 2013
From: r.schwebel at pengutronix.de (Robert Schwebel)
Date: Tue, 23 Apr 2013 14:34:08 +0200
Subject: [PATCH] Support fsl-dcp crypto coprocessor
In-Reply-To: <1366710460-11637-1-git-send-email-cb@sgoc.de>
References: <1366710460-11637-1-git-send-email-cb@sgoc.de>
Message-ID: <20130423123408.GB1366@pengutronix.de>

On Tue, Apr 23, 2013 at 11:47:40AM +0200, Christoph G. Baumann wrote:
> From: "Christoph G. Baumann" <cb at sgoc.de>
> 
> The following patch is a port of the original driver from Freescale to
> the current mainline. The patch was tested under 3.7.
> 
> Signed-off-by: "Christoph G. Baumann" <cb at sgoc.de>
> ---
>  drivers/staging/crypto/Kconfig               |   15 +
>  drivers/staging/crypto/Makefile              |    1 +
>  drivers/staging/crypto/fsl-dcp.c             | 1817 ++++++++++++++++++++++++++
>  drivers/staging/crypto/fsl-dcp.h             |  739 +++++++++++
>  include/linux/fsl/fsl-dcp_bootstream_ioctl.h |   32 +
>  5 files changed, 2604 insertions(+)
>  create mode 100644 drivers/staging/crypto/Kconfig
>  create mode 100644 drivers/staging/crypto/Makefile
>  create mode 100644 drivers/staging/crypto/fsl-dcp.c
>  create mode 100644 drivers/staging/crypto/fsl-dcp.h
>  create mode 100644 include/linux/fsl/fsl-dcp_bootstream_ioctl.h

IMHO it doesn't make any sense to push this into staging. The Freescale
kernel is full of drivers which are not ready for mainline yet.

Until now, it was a good strategy to wait until some code is needed,
then clean it up, adapt it to the right kernel APIs and push it into
non-staging mainline.

rsc
-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From daniel.lezcano at linaro.org  Tue Apr 23 08:51:41 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Tue, 23 Apr 2013 14:51:41 +0200
Subject: [V4 patch 03/15] cpuidle: make a single register function for all
In-Reply-To: <51767F57.7060809@ti.com>
References: <1366707285-12179-1-git-send-email-daniel.lezcano@linaro.org>
 <1366707285-12179-4-git-send-email-daniel.lezcano@linaro.org>
 <51767F57.7060809@ti.com>
Message-ID: <517683DD.6060805@linaro.org>

On 04/23/2013 02:32 PM, Santosh Shilimkar wrote:
> On Tuesday 23 April 2013 02:24 PM, Daniel Lezcano wrote:
>> The usual scheme to initialize a cpuidle driver on a SMP is:
>>
>> 	cpuidle_register_driver(drv);
>> 	for_each_possible_cpu(cpu) {
>> 		device = &per_cpu(cpuidle_dev, cpu);
>> 		cpuidle_register_device(device);
>> 	}
>>
>> This code is duplicated in each cpuidle driver.
>>
>> On UP systems, it is done this way:
>>
>> 	cpuidle_register_driver(drv);
>> 	device = &per_cpu(cpuidle_dev, cpu);
>> 	cpuidle_register_device(device);
>>
>> On UP, the macro 'for_each_cpu' does one iteration:
>>
>> #define for_each_cpu(cpu, mask)                 \
>>         for ((cpu) = 0; (cpu) < 1; (cpu)++, (void)mask)
>>
>> Hence, the initialization loop is the same for UP than SMP.
>>
>> Beside, we saw different bugs / mis-initialization / return code unchecked in
>> the different drivers, the code is duplicated including bugs. After fixing all
>> these ones, it appears the initialization pattern is the same for everyone.
>>
>> Please note, some drivers are doing dev->state_count = drv->state_count. This is
>> not necessary because it is done by the cpuidle_enable_device function in the
>> cpuidle framework. This is true, until you have the same states for all your
>> devices. Otherwise, the 'low level' API should be used instead with the specific
>> initialization for the driver.
>>
>> Let's add a wrapper function doing this initialization with a cpumask parameter
>> for the coupled idle states and use it for all the drivers.
>>
>> That will save a lot of LOC, consolidate the code, and the modifications in the
>> future could be done in a single place. Another benefit is the consolidation of
>> the cpuidle_device variable which is now in the cpuidle framework and no longer
>> spread accross the different arch specific drivers.
>>
>> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
>> ---
> 
> I don't see you have addressed the comment on V3 [1] i gave for the subject patch
> Any reason ?

Yes, sorry for not answering.

This modification should be handled in the __cpuidle_register_device
function.

diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
index 49e8d30..936d862 100644
--- a/drivers/cpuidle/cpuidle.c
+++ b/drivers/cpuidle/cpuidle.c
@@ -372,7 +372,7 @@ static int __cpuidle_register_device(struct
cpuidle_device *dev)
        int ret;
        struct cpuidle_driver *drv = cpuidle_get_cpu_driver(dev);

-       if (!try_module_get(drv->owner))
+       if (!drv || !try_module_get(drv->owner))
                return -EINVAL;

        per_cpu(cpuidle_devices, dev->cpu) = dev;

Thus, the cpuidle_register function is not impacted by this as it will
always do cpuidle_register_driver, followed by cpuidle_register_device.

  -- Daniel

-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From cb at sgoc.de  Tue Apr 23 08:55:57 2013
From: cb at sgoc.de (Christoph G. Baumann)
Date: Tue, 23 Apr 2013 14:55:57 +0200 (CEST)
Subject: [PATCH] Support fsl-dcp crypto coprocessor
In-Reply-To: <20130423123408.GB1366@pengutronix.de>
References: <1366710460-11637-1-git-send-email-cb@sgoc.de>
 <20130423123408.GB1366@pengutronix.de>
Message-ID: <341422577.566569.1366721757554.open-xchange@email.1und1.de>


> IMHO it doesn't make any sense to push this into staging. The Freescale
> kernel is full of drivers which are not ready for mainline yet.

Indeed the Freescale kernel is a heap of <censored>.


> Until now, it was a good strategy to wait until some code is needed,
> then clean it up, adapt it to the right kernel APIs and push it into
> non-staging mainline.

Well, that's what I'm trying to do. I picked a particular driver and
adapted it to the current mainline.
So if there are concrete proposals or criticism about this patch, please
tell me. As I stated the code is from Freescale and I won't be offended.




Christoph


From santosh.shilimkar at ti.com  Tue Apr 23 09:04:11 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Tue, 23 Apr 2013 18:34:11 +0530
Subject: [V4 patch 03/15] cpuidle: make a single register function for all
In-Reply-To: <517683DD.6060805@linaro.org>
References: <1366707285-12179-1-git-send-email-daniel.lezcano@linaro.org>
 <1366707285-12179-4-git-send-email-daniel.lezcano@linaro.org>
 <51767F57.7060809@ti.com> <517683DD.6060805@linaro.org>
Message-ID: <517686CB.7080909@ti.com>

On Tuesday 23 April 2013 06:21 PM, Daniel Lezcano wrote:
> On 04/23/2013 02:32 PM, Santosh Shilimkar wrote:
>> On Tuesday 23 April 2013 02:24 PM, Daniel Lezcano wrote:
>>> The usual scheme to initialize a cpuidle driver on a SMP is:
>>>
>>> 	cpuidle_register_driver(drv);
>>> 	for_each_possible_cpu(cpu) {
>>> 		device = &per_cpu(cpuidle_dev, cpu);
>>> 		cpuidle_register_device(device);
>>> 	}
>>>
>>> This code is duplicated in each cpuidle driver.
>>>
>>> On UP systems, it is done this way:
>>>
>>> 	cpuidle_register_driver(drv);
>>> 	device = &per_cpu(cpuidle_dev, cpu);
>>> 	cpuidle_register_device(device);
>>>
>>> On UP, the macro 'for_each_cpu' does one iteration:
>>>
>>> #define for_each_cpu(cpu, mask)                 \
>>>         for ((cpu) = 0; (cpu) < 1; (cpu)++, (void)mask)
>>>
>>> Hence, the initialization loop is the same for UP than SMP.
>>>
>>> Beside, we saw different bugs / mis-initialization / return code unchecked in
>>> the different drivers, the code is duplicated including bugs. After fixing all
>>> these ones, it appears the initialization pattern is the same for everyone.
>>>
>>> Please note, some drivers are doing dev->state_count = drv->state_count. This is
>>> not necessary because it is done by the cpuidle_enable_device function in the
>>> cpuidle framework. This is true, until you have the same states for all your
>>> devices. Otherwise, the 'low level' API should be used instead with the specific
>>> initialization for the driver.
>>>
>>> Let's add a wrapper function doing this initialization with a cpumask parameter
>>> for the coupled idle states and use it for all the drivers.
>>>
>>> That will save a lot of LOC, consolidate the code, and the modifications in the
>>> future could be done in a single place. Another benefit is the consolidation of
>>> the cpuidle_device variable which is now in the cpuidle framework and no longer
>>> spread accross the different arch specific drivers.
>>>
>>> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
>>> ---
>>
>> I don't see you have addressed the comment on V3 [1] i gave for the subject patch
>> Any reason ?
> 
> Yes, sorry for not answering.
> 
> This modification should be handled in the __cpuidle_register_device
> function.
> 
> diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
> index 49e8d30..936d862 100644
> --- a/drivers/cpuidle/cpuidle.c
> +++ b/drivers/cpuidle/cpuidle.c
> @@ -372,7 +372,7 @@ static int __cpuidle_register_device(struct
> cpuidle_device *dev)
>         int ret;
>         struct cpuidle_driver *drv = cpuidle_get_cpu_driver(dev);
> 
> -       if (!try_module_get(drv->owner))
> +       if (!drv || !try_module_get(drv->owner))
>                 return -EINVAL;
> 
>         per_cpu(cpuidle_devices, dev->cpu) = dev;
> 
> Thus, the cpuidle_register function is not impacted by this as it will
> always do cpuidle_register_driver, followed by cpuidle_register_device.
> 
I still don't follow you. I know the fix will be needed but in the subject
patch sequence as well, the device registration should be done first and
then the driver registration. Below hunk I mean.

----
+int cpuidle_register(struct cpuidle_driver *drv,
+		     const struct cpumask *const coupled_cpus)
+{
+	int ret, cpu;
+	struct cpuidle_device *device;
+
+	ret = cpuidle_register_driver(drv);
+	if (ret) {
+		pr_err("failed to register cpuidle driver\n");
+		return ret;
+	}
+
+	for_each_possible_cpu(cpu) {
+		device = &per_cpu(cpuidle_dev, cpu);
+		device->cpu = cpu;
+
+#ifdef CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED
+		/*
+		 * On multiplatform for ARM, the coupled idle states could
+		 * enabled in the kernel even if the cpuidle driver does not
+		 * use it. Note, coupled_cpus is a struct copy.
+		 */
+		if (coupled_cpus)
+			device->coupled_cpus = *coupled_cpus;
+#endif
+		ret = cpuidle_register_device(device);
+		if (!ret)
+			continue;
+
+		pr_err("Failed to register cpuidle device for cpu%d\n", cpu);
+
+		cpuidle_unregister(drv);
+		break;
+	}
------

I also had a comment on kernel doc for both of these new functions.
Out of curiosity I have seen this patch again o.w I would have assumed
that you did address the comments.

Regards,
Santosh











From robherring2 at gmail.com  Tue Apr 23 09:05:30 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Tue, 23 Apr 2013 08:05:30 -0500
Subject: [PATCH V2 4/4] arm64: Add initial DTS for APM X-Gene Storm SOC
 and APM Mustang board
In-Reply-To: <1366712759-3431-5-git-send-email-vkale@apm.com>
References: <1366712759-3431-1-git-send-email-vkale@apm.com>
 <1366712759-3431-5-git-send-email-vkale@apm.com>
Message-ID: <5176871A.4040209@gmail.com>

On 04/23/2013 05:25 AM, Vinayak Kale wrote:
> This patch adds initial DTS files required for APM Mustang board.
> 
> Signed-off-by: Kumar Sankaran <ksankaran at apm.com>
> Signed-off-by: Loc Ho <lho at apm.com>
> Signed-off-by: Feng Kan <fkan at apm.com>
> ---
>  arch/arm64/boot/dts/Makefile        |    1 +
>  arch/arm64/boot/dts/apm-mustang.dts |   27 ++++++++
>  arch/arm64/boot/dts/apm-storm.dtsi  |  116 +++++++++++++++++++++++++++++++++++

Well, you renamed the files, but did not address any of my other comments.

>  3 files changed, 144 insertions(+), 0 deletions(-)
>  create mode 100644 arch/arm64/boot/dts/apm-mustang.dts
>  create mode 100644 arch/arm64/boot/dts/apm-storm.dtsi
> 
> diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
> index 68457e9..c52bdb0 100644
> --- a/arch/arm64/boot/dts/Makefile
> +++ b/arch/arm64/boot/dts/Makefile
> @@ -1,4 +1,5 @@
>  dtb-$(CONFIG_ARCH_VEXPRESS) += rtsm_ve-aemv8a.dtb foundation-v8.dtb
> +dtb-$(CONFIG_ARCH_XGENE) += apm-mustang.dtb
>  
>  targets += dtbs
>  targets += $(dtb-y)
> diff --git a/arch/arm64/boot/dts/apm-mustang.dts b/arch/arm64/boot/dts/apm-mustang.dts
> new file mode 100644
> index 0000000..625322c
> --- /dev/null
> +++ b/arch/arm64/boot/dts/apm-mustang.dts
> @@ -0,0 +1,27 @@
> +/*
> + * dts file for AppliedMicro (APM) Mustang Board
> + *
> + * Copyright (C) 2013, Applied Micro Circuits Corporation
> + *
> + * 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/ "apm-storm.dtsi"
> +
> +/ {
> +	model = "mustang";

This should/can be a more descriptive string.

You need a compatible field for the board.

> +
> +	chosen {
> +		linux,stdout-path = &serial0;

See my prior comment.

> +	};
> +
> +	memory {
> +		device_type = "memory";
> +		reg = < 0x1 0x00000000 0x0 0x80000000 >; /* Updated by bootloader */
> +	};
> +};
> diff --git a/arch/arm64/boot/dts/apm-storm.dtsi b/arch/arm64/boot/dts/apm-storm.dtsi
> new file mode 100644
> index 0000000..d3f3f5d
> --- /dev/null
> +++ b/arch/arm64/boot/dts/apm-storm.dtsi
> @@ -0,0 +1,116 @@
> +/*
> + * dts file for AppliedMicro (APM) X-Gene Storm SOC
> + *
> + * Copyright (C) 2013, Applied Micro Circuits Corporation
> + *
> + * 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.
> + */
> +
> +/ {
> +	compatible = "apm,xgene,storm", "apm,xgene";

This still needs documentation. "apm,xgene-storm" would be more in line
with convention. apm,xgene collides with the cpu name. Is xgene the soc
or cpu core? Use the soc name here.

Rob

> +	interrupt-parent = <&gic>;
> +	#address-cells = <2>;
> +	#size-cells = <2>;
> +
> +	cpus {
> +		#address-cells = <2>;
> +		#size-cells = <0>;
> +
> +		cpu at 000 {
> +			device_type = "cpu";
> +			compatible = "apm,xgene", "arm,armv8";
> +			reg = <0x0 0x000>;
> +			enable-method = "spin-table";
> +			cpu-release-addr = <0x1 0x0000fff8>;
> +		};
> +		cpu at 001 {
> +			device_type = "cpu";
> +			compatible = "apm,xgene", "arm,armv8";
> +			reg = <0x0 0x001>;
> +			enable-method = "spin-table";
> +			cpu-release-addr = <0x1 0x0000fff8>;
> +		};
> +		cpu at 100 {
> +			device_type = "cpu";
> +			compatible = "apm,xgene", "arm,armv8";
> +			reg = <0x0 0x100>;
> +			enable-method = "spin-table";
> +			cpu-release-addr = <0x1 0x0000fff8>;
> +		};
> +		cpu at 101 {
> +			device_type = "cpu";
> +			compatible = "apm,xgene", "arm,armv8";
> +			reg = <0x0 0x101>;
> +			enable-method = "spin-table";
> +			cpu-release-addr = <0x1 0x0000fff8>;
> +		};
> +		cpu at 200 {
> +			device_type = "cpu";
> +			compatible = "apm,xgene", "arm,armv8";
> +			reg = <0x0 0x200>;
> +			enable-method = "spin-table";
> +			cpu-release-addr = <0x1 0x0000fff8>;
> +		};
> +		cpu at 201 {
> +			device_type = "cpu";
> +			compatible = "apm,xgene", "arm,armv8";
> +			reg = <0x0 0x201>;
> +			enable-method = "spin-table";
> +			cpu-release-addr = <0x1 0x0000fff8>;
> +		};
> +		cpu at 300 {
> +			device_type = "cpu";
> +			compatible = "apm,xgene", "arm,armv8";
> +			reg = <0x0 0x300>;
> +			enable-method = "spin-table";
> +			cpu-release-addr = <0x1 0x0000fff8>;
> +		};
> +		cpu at 301 {
> +			device_type = "cpu";
> +			compatible = "apm,xgene", "arm,armv8";
> +			reg = <0x0 0x301>;
> +			enable-method = "spin-table";
> +			cpu-release-addr = <0x1 0x0000fff8>;
> +		};
> +	};
> +
> +	gic: interrupt-controller at 78010000 {
> +		compatible = "arm,cortex-a15-gic", "arm,cortex-a9-gic";
> +		#interrupt-cells = <3>;
> +		interrupt-controller;
> +		reg = <0x0 0x78010000 0x0 0x1000>,	/* GIC Dist */
> +		      <0x0 0x78020000 0x0 0x1000>,	/* GIC CPU */
> +		      <0x0 0x78040000 0x0 0x2000>,	/* GIC VCPU Control */
> +		      <0x0 0x78060000 0x0 0x2000>;	/* GIC VCPU */
> +		interrupts = <1 9 0xf04>;	/* GIC Maintenence IRQ */
> +	};
> +
> +	timer {
> +		compatible = "arm,armv8-timer";
> +		interrupts = <1 0 0xff01>,	/* Secure Phys IRQ */
> +			     <1 13 0xff01>,	/* Non-secure Phys IRQ */
> +			     <1 14 0xff01>,	/* Virt IRQ */
> +			     <1 15 0xff01>;	/* Hyp IRQ */
> +		clock-frequency = <50000000>;
> +	};
> +
> +	soc {
> +		compatible = "simple-bus";
> +		#address-cells = <2>;
> +		#size-cells = <2>;
> +		ranges;
> +
> +		serial0: serial at 1c020000 {
> +			device_type = "serial";
> +			compatible = "ns16550";
> +			reg = <0 0x1c020000 0x0 0x1000>;
> +			reg-shift = <2>;
> +			clock-frequency = <10000000>; /* Updated by bootloader */
> +			interrupt-parent = <&gic>;
> +			interrupts = <0x0 0x4c 0x4>;
> +		};
> +	};
> +};
> 



From mkl at pengutronix.de  Tue Apr 23 09:07:55 2013
From: mkl at pengutronix.de (Marc Kleine-Budde)
Date: Tue, 23 Apr 2013 15:07:55 +0200
Subject: BUG: Re: [PATCH v2 3/3] clocksource: use
 clockevents_config_and_register() where possible
In-Reply-To: <1357991406-22778-4-git-send-email-shawn.guo@linaro.org>
References: <1357991406-22778-1-git-send-email-shawn.guo@linaro.org>
 <1357991406-22778-4-git-send-email-shawn.guo@linaro.org>
Message-ID: <517687AB.1040309@pengutronix.de>

Hello,

On 01/12/2013 12:50 PM, Shawn Guo wrote:
> The clockevent core is able to figure out the best mult and shift,
> calculate min_delta_ns and max_delta_ns, with the necessary info passed
> into clockevents_config_and_register().  Use this combined configure
> and register function where possible to make the codes less error prone
> and gain some positive diff stat.
> 
> Signed-off-by: Shawn Guo <shawn.guo at linaro.org>
> Cc: Andres Salomon <dilinger at queued.net>
> Cc: Nicolas Ferre <nicolas.ferre at atmel.com>
> Acked-by: Maxime Ripard <maxime.ripard at free-electrons.com>

[...]

I just bisected a timer problem down to this commit.

> diff --git a/drivers/clocksource/tcb_clksrc.c b/drivers/clocksource/tcb_clksrc.c
> index 32cb929..8a61872 100644
> --- a/drivers/clocksource/tcb_clksrc.c
> +++ b/drivers/clocksource/tcb_clksrc.c
> @@ -157,7 +157,6 @@ static struct tc_clkevt_device clkevt = {
>  		.name		= "tc_clkevt",
>  		.features	= CLOCK_EVT_FEAT_PERIODIC
>  					| CLOCK_EVT_FEAT_ONESHOT,
> -		.shift		= 32,
>  		/* Should be lower than at91rm9200's system timer */
>  		.rating		= 125,
>  		.set_next_event	= tc_next_event,
> @@ -196,13 +195,9 @@ static void __init setup_clkevents(struct atmel_tc *tc, int clk32k_divisor_idx)
>  
>  	timer_clock = clk32k_divisor_idx;
>  
> -	clkevt.clkevt.mult = div_sc(32768, NSEC_PER_SEC, clkevt.clkevt.shift);
> -	clkevt.clkevt.max_delta_ns
> -		= clockevent_delta2ns(0xffff, &clkevt.clkevt);
> -	clkevt.clkevt.min_delta_ns = clockevent_delta2ns(1, &clkevt.clkevt) + 1;
                                                                           ^^^^^^

With this patch, the "+ 1" gets lost, resulting in a different
"min_delta_ns".

good:
setup_clkevents: shift=32 mult=140737 min=30518 max=1999976422

bad:
setup_clkevents: shift=32 mult=140737 min=30517 max=1999976422

This leads to problems with schedule_delayed_work() with a delay of
"1". These worksqueues seem to be hanging for several seconds. I'll
send a RFC patch.

>  	clkevt.clkevt.cpumask = cpumask_of(0);
>  
> -	clockevents_register_device(&clkevt.clkevt);
> +	clockevents_config_and_register(&clkevt.clkevt, 32768, 1, 0xffff);
>  
>  	setup_irq(irq, &tc_irqaction);
>  }
> 

Marc

-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130423/63f7b390/attachment.sig>

From mkl at pengutronix.de  Tue Apr 23 09:08:44 2013
From: mkl at pengutronix.de (Marc Kleine-Budde)
Date: Tue, 23 Apr 2013 15:08:44 +0200
Subject: RFC: [PATCH] clocksource: tcb: fix min_delta calculation
In-Reply-To: <517687AB.1040309@pengutronix.de>
References: <517687AB.1040309@pengutronix.de>
Message-ID: <1366722524-25991-1-git-send-email-mkl@pengutronix.de>

The commit

    77cc982 clocksource: use clockevents_config_and_register() where possible

switches from manually calculating min_delta_ns (and others) and
clockevents_register_device() to automatic calculation via
clockevents_config_and_register(). During this conversation the "+ 1" in

    min_delta_ns = clockevent_delta2ns(1, &clkevt.clkevt) + 1;

was lost. This leads to problems with schedule_delayed_work() with a delay of
"1". Resulting in the work not scheduled in time.

This patch fixes the problem by increasing the min_delta to "2" ticks.

Signed-off-by: Marc Kleine-Budde <mkl at pengutronix.de>
---
 drivers/clocksource/tcb_clksrc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clocksource/tcb_clksrc.c b/drivers/clocksource/tcb_clksrc.c
index 8a61872..7cf6dc7 100644
--- a/drivers/clocksource/tcb_clksrc.c
+++ b/drivers/clocksource/tcb_clksrc.c
@@ -197,7 +197,7 @@ static void __init setup_clkevents(struct atmel_tc *tc, int clk32k_divisor_idx)
 
 	clkevt.clkevt.cpumask = cpumask_of(0);
 
-	clockevents_config_and_register(&clkevt.clkevt, 32768, 1, 0xffff);
+	clockevents_config_and_register(&clkevt.clkevt, 32768, 2, 0xffff);
 
 	setup_irq(irq, &tc_irqaction);
 }
-- 
1.8.2.rc2



From mkl at pengutronix.de  Tue Apr 23 09:11:33 2013
From: mkl at pengutronix.de (Marc Kleine-Budde)
Date: Tue, 23 Apr 2013 15:11:33 +0200
Subject: RFC: [PATCH] clocksource: tcb: fix min_delta calculation
In-Reply-To: <1366722524-25991-1-git-send-email-mkl@pengutronix.de>
References: <517687AB.1040309@pengutronix.de>
 <1366722524-25991-1-git-send-email-mkl@pengutronix.de>
Message-ID: <51768885.4080301@pengutronix.de>

On 04/23/2013 03:08 PM, Marc Kleine-Budde wrote:
> The commit
> 
>     77cc982 clocksource: use clockevents_config_and_register() where possible
> 
> switches from manually calculating min_delta_ns (and others) and
> clockevents_register_device() to automatic calculation via
> clockevents_config_and_register(). During this conversation the "+ 1" in
> 
>     min_delta_ns = clockevent_delta2ns(1, &clkevt.clkevt) + 1;
> 
> was lost. This leads to problems with schedule_delayed_work() with a delay of
> "1". Resulting in the work not scheduled in time.
> 
> This patch fixes the problem by increasing the min_delta to "2" ticks.
> 
> Signed-off-by: Marc Kleine-Budde <mkl at pengutronix.de>

The problem appears on at91sam9263. This patch successfully fixes the
problem and applies to current linus/master (post v3.9-rc8).

regards,
Marc
-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130423/84a18667/attachment.sig>

From robherring2 at gmail.com  Tue Apr 23 09:11:46 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Tue, 23 Apr 2013 08:11:46 -0500
Subject: [RFC PATCH v2 03/13] ARM: mach-at91: cpus/cpu node dts updates
In-Reply-To: <1366644455-16550-4-git-send-email-lorenzo.pieralisi@arm.com>
References: <1366644455-16550-1-git-send-email-lorenzo.pieralisi@arm.com>
 <1366644455-16550-4-git-send-email-lorenzo.pieralisi@arm.com>
Message-ID: <51768892.7060807@gmail.com>

On 04/22/2013 10:27 AM, Lorenzo Pieralisi wrote:
> This patch updates the in-kernel dts files according to the latest cpus
> and cpu bindings updates for ARM.
> 
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
> ---
>  arch/arm/boot/dts/at91sam9260.dtsi | 2 +-
>  arch/arm/boot/dts/at91sam9263.dtsi | 2 +-
>  arch/arm/boot/dts/at91sam9g45.dtsi | 2 +-
>  arch/arm/boot/dts/at91sam9n12.dtsi | 2 +-
>  4 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/at91sam9260.dtsi b/arch/arm/boot/dts/at91sam9260.dtsi
> index cb7bcc5..2e9de85 100644
> --- a/arch/arm/boot/dts/at91sam9260.dtsi
> +++ b/arch/arm/boot/dts/at91sam9260.dtsi
> @@ -33,7 +33,7 @@
>  	};
>  	cpus {
>  		cpu at 0 {
> -			compatible = "arm,arm926ejs";
> +			compatible = "arm,arm926";

I don't understand why you are doing this. If this does not match the
documentation, fix the documentation. We can't continue on changing dts
files without reqard to breaking compatibility.

Rob

>  		};
>  	};
>  
> diff --git a/arch/arm/boot/dts/at91sam9263.dtsi b/arch/arm/boot/dts/at91sam9263.dtsi
> index 271d4de..25c4725 100644
> --- a/arch/arm/boot/dts/at91sam9263.dtsi
> +++ b/arch/arm/boot/dts/at91sam9263.dtsi
> @@ -30,7 +30,7 @@
>  	};
>  	cpus {
>  		cpu at 0 {
> -			compatible = "arm,arm926ejs";
> +			compatible = "arm,arm926";
>  		};
>  	};
>  
> diff --git a/arch/arm/boot/dts/at91sam9g45.dtsi b/arch/arm/boot/dts/at91sam9g45.dtsi
> index 6b1d4ca..cf647d1 100644
> --- a/arch/arm/boot/dts/at91sam9g45.dtsi
> +++ b/arch/arm/boot/dts/at91sam9g45.dtsi
> @@ -36,7 +36,7 @@
>  	};
>  	cpus {
>  		cpu at 0 {
> -			compatible = "arm,arm926ejs";
> +			compatible = "arm,arm926";
>  		};
>  	};
>  
> diff --git a/arch/arm/boot/dts/at91sam9n12.dtsi b/arch/arm/boot/dts/at91sam9n12.dtsi
> index 7750f98..d531ae3 100644
> --- a/arch/arm/boot/dts/at91sam9n12.dtsi
> +++ b/arch/arm/boot/dts/at91sam9n12.dtsi
> @@ -32,7 +32,7 @@
>  	};
>  	cpus {
>  		cpu at 0 {
> -			compatible = "arm,arm926ejs";
> +			compatible = "arm,arm926";
>  		};
>  	};
>  
> 



From mark.rutland at arm.com  Tue Apr 23 09:12:15 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Tue, 23 Apr 2013 14:12:15 +0100
Subject: [PATCH V2 4/4] arm64: Add initial DTS for APM X-Gene Storm SOC
 and APM Mustang board
In-Reply-To: <1366712759-3431-5-git-send-email-vkale@apm.com>
References: <1366712759-3431-1-git-send-email-vkale@apm.com>
 <1366712759-3431-5-git-send-email-vkale@apm.com>
Message-ID: <20130423131215.GB28663@e106331-lin.cambridge.arm.com>

Hi,

On Tue, Apr 23, 2013 at 11:25:59AM +0100, Vinayak Kale wrote:
> This patch adds initial DTS files required for APM Mustang board.
> 
> Signed-off-by: Kumar Sankaran <ksankaran at apm.com>
> Signed-off-by: Loc Ho <lho at apm.com>
> Signed-off-by: Feng Kan <fkan at apm.com>
> ---
>  arch/arm64/boot/dts/Makefile        |    1 +
>  arch/arm64/boot/dts/apm-mustang.dts |   27 ++++++++
>  arch/arm64/boot/dts/apm-storm.dtsi  |  116 +++++++++++++++++++++++++++++++++++
>  3 files changed, 144 insertions(+), 0 deletions(-)
>  create mode 100644 arch/arm64/boot/dts/apm-mustang.dts
>  create mode 100644 arch/arm64/boot/dts/apm-storm.dtsi
> 
> diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
> index 68457e9..c52bdb0 100644
> --- a/arch/arm64/boot/dts/Makefile
> +++ b/arch/arm64/boot/dts/Makefile
> @@ -1,4 +1,5 @@
>  dtb-$(CONFIG_ARCH_VEXPRESS) += rtsm_ve-aemv8a.dtb foundation-v8.dtb
> +dtb-$(CONFIG_ARCH_XGENE) += apm-mustang.dtb
>  
>  targets += dtbs
>  targets += $(dtb-y)
> diff --git a/arch/arm64/boot/dts/apm-mustang.dts b/arch/arm64/boot/dts/apm-mustang.dts
> new file mode 100644
> index 0000000..625322c
> --- /dev/null
> +++ b/arch/arm64/boot/dts/apm-mustang.dts
> @@ -0,0 +1,27 @@
> +/*
> + * dts file for AppliedMicro (APM) Mustang Board
> + *
> + * Copyright (C) 2013, Applied Micro Circuits Corporation
> + *
> + * 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/ "apm-storm.dtsi"
> +
> +/ {
> +	model = "mustang";
> +
> +	chosen {
> +		linux,stdout-path = &serial0;
> +	};
> +
> +	memory {
> +		device_type = "memory";
> +		reg = < 0x1 0x00000000 0x0 0x80000000 >; /* Updated by bootloader */
> +	};
> +};
> diff --git a/arch/arm64/boot/dts/apm-storm.dtsi b/arch/arm64/boot/dts/apm-storm.dtsi
> new file mode 100644
> index 0000000..d3f3f5d
> --- /dev/null
> +++ b/arch/arm64/boot/dts/apm-storm.dtsi
> @@ -0,0 +1,116 @@
> +/*
> + * dts file for AppliedMicro (APM) X-Gene Storm SOC
> + *
> + * Copyright (C) 2013, Applied Micro Circuits Corporation
> + *
> + * 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.
> + */
> +
> +/ {
> +	compatible = "apm,xgene,storm", "apm,xgene";
> +	interrupt-parent = <&gic>;
> +	#address-cells = <2>;
> +	#size-cells = <2>;
> +
> +	cpus {
> +		#address-cells = <2>;
> +		#size-cells = <0>;
> +
> +		cpu at 000 {
> +			device_type = "cpu";
> +			compatible = "apm,xgene", "arm,armv8";

You've used the "apm,xgene" compatible string for both the CPU and the board.

In PATCH 3, you added APM_CPU_PART_POTENZA, so presumably "apm,potenza" makes
more sense as the CPU compatible string?

Thanks,
Mark.


From plagnioj at jcrosoft.com  Tue Apr 23 09:25:11 2013
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Tue, 23 Apr 2013 21:25:11 +0800
Subject: [RFC PATCH v2 03/13] ARM: mach-at91: cpus/cpu node dts updates
In-Reply-To: <51768892.7060807@gmail.com>
References: <1366644455-16550-1-git-send-email-lorenzo.pieralisi@arm.com>
 <1366644455-16550-4-git-send-email-lorenzo.pieralisi@arm.com>
 <51768892.7060807@gmail.com>
Message-ID: <C0C2D01E-6F76-4606-9F63-70F3877C02BB@jcrosoft.com>


On Apr 23, 2013, at 9:11 PM, Rob Herring <robherring2 at gmail.com> wrote:

> On 04/22/2013 10:27 AM, Lorenzo Pieralisi wrote:
>> This patch updates the in-kernel dts files according to the latest cpus
>> and cpu bindings updates for ARM.
>> 
>> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
>> ---
>> arch/arm/boot/dts/at91sam9260.dtsi | 2 +-
>> arch/arm/boot/dts/at91sam9263.dtsi | 2 +-
>> arch/arm/boot/dts/at91sam9g45.dtsi | 2 +-
>> arch/arm/boot/dts/at91sam9n12.dtsi | 2 +-
>> 4 files changed, 4 insertions(+), 4 deletions(-)
>> 
>> diff --git a/arch/arm/boot/dts/at91sam9260.dtsi b/arch/arm/boot/dts/at91sam9260.dtsi
>> index cb7bcc5..2e9de85 100644
>> --- a/arch/arm/boot/dts/at91sam9260.dtsi
>> +++ b/arch/arm/boot/dts/at91sam9260.dtsi
>> @@ -33,7 +33,7 @@
>> 	};
>> 	cpus {
>> 		cpu at 0 {
>> -			compatible = "arm,arm926ejs";
>> +			compatible = "arm,arm926";
> 
> I don't understand why you are doing this. If this does not match the
> documentation, fix the documentation. We can't continue on changing dts
> files without reqard to breaking compatibility.

agreed and on AT91 it's a arm926ejs cpu
> 
> Rob
> 
>> 		};
>> 	};
>> 
>> diff --git a/arch/arm/boot/dts/at91sam9263.dtsi b/arch/arm/boot/dts/at91sam9263.dtsi
>> index 271d4de..25c4725 100644
>> --- a/arch/arm/boot/dts/at91sam9263.dtsi
>> +++ b/arch/arm/boot/dts/at91sam9263.dtsi
>> @@ -30,7 +30,7 @@
>> 	};
>> 	cpus {
>> 		cpu at 0 {
>> -			compatible = "arm,arm926ejs";
>> +			compatible = "arm,arm926";
>> 		};
>> 	};
>> 
>> diff --git a/arch/arm/boot/dts/at91sam9g45.dtsi b/arch/arm/boot/dts/at91sam9g45.dtsi
>> index 6b1d4ca..cf647d1 100644
>> --- a/arch/arm/boot/dts/at91sam9g45.dtsi
>> +++ b/arch/arm/boot/dts/at91sam9g45.dtsi
>> @@ -36,7 +36,7 @@
>> 	};
>> 	cpus {
>> 		cpu at 0 {
>> -			compatible = "arm,arm926ejs";
>> +			compatible = "arm,arm926";
>> 		};
>> 	};
>> 
>> diff --git a/arch/arm/boot/dts/at91sam9n12.dtsi b/arch/arm/boot/dts/at91sam9n12.dtsi
>> index 7750f98..d531ae3 100644
>> --- a/arch/arm/boot/dts/at91sam9n12.dtsi
>> +++ b/arch/arm/boot/dts/at91sam9n12.dtsi
>> @@ -32,7 +32,7 @@
>> 	};
>> 	cpus {
>> 		cpu at 0 {
>> -			compatible = "arm,arm926ejs";
>> +			compatible = "arm,arm926";
>> 		};
>> 	};
>> 
>> 
> 
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss



From laurent.pinchart+renesas at ideasonboard.com  Tue Apr 23 09:28:38 2013
From: laurent.pinchart+renesas at ideasonboard.com (Laurent Pinchart)
Date: Tue, 23 Apr 2013 15:28:38 +0200
Subject: [PATCH] pinctrl: generic: Fix typos and clarify comments
Message-ID: <1366723718-5369-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>

Drive strength controls both sink and source currents, clarify the
description accordingly.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
---
 include/linux/pinctrl/pinconf-generic.h | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/include/linux/pinctrl/pinconf-generic.h b/include/linux/pinctrl/pinconf-generic.h
index 72474e1..1301f15 100644
--- a/include/linux/pinctrl/pinconf-generic.h
+++ b/include/linux/pinctrl/pinconf-generic.h
@@ -37,17 +37,17 @@
  *	if it is 0, pull-down is disabled.
  * @PIN_CONFIG_DRIVE_PUSH_PULL: the pin will be driven actively high and
  *	low, this is the most typical case and is typically achieved with two
- *	active transistors on the output. Sending this config will enabale
+ *	active transistors on the output. Setting this config will enable
  *	push-pull mode, the argument is ignored.
  * @PIN_CONFIG_DRIVE_OPEN_DRAIN: the pin will be driven with open drain (open
  *	collector) which means it is usually wired with other output ports
- *	which are then pulled up with an external resistor. Sending this
- *	config will enabale open drain mode, the argument is ignored.
+ *	which are then pulled up with an external resistor. Setting this
+ *	config will enable open drain mode, the argument is ignored.
  * @PIN_CONFIG_DRIVE_OPEN_SOURCE: the pin will be driven with open source
- *	(open emitter). Sending this config will enabale open drain mode, the
+ *	(open emitter). Setting this config will enable open drain mode, the
  *	argument is ignored.
- * @PIN_CONFIG_DRIVE_STRENGTH: the pin will output the current passed as
- * 	argument. The argument is in mA.
+ * @PIN_CONFIG_DRIVE_STRENGTH: the pin will sink or source at most the current
+ *	passed as argument. The argument is in mA.
  * @PIN_CONFIG_INPUT_SCHMITT_ENABLE: control schmitt-trigger mode on the pin.
  *      If the argument != 0, schmitt-trigger mode is enabled. If it's 0,
  *      schmitt-trigger mode is disabled.
-- 
Regards,

Laurent Pinchart



From laurent.pinchart at ideasonboard.com  Tue Apr 23 09:33:25 2013
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Tue, 23 Apr 2013 15:33:25 +0200
Subject: [PATCH] pinctrl: document the "GPIO mode" pitfall
In-Reply-To: <1363345636-2006-1-git-send-email-linus.walleij@stericsson.com>
References: <1363345636-2006-1-git-send-email-linus.walleij@stericsson.com>
Message-ID: <2408684.1bsjMDDzMu@avalon>

Hi Linus,

On Friday 15 March 2013 12:07:16 Linus Walleij wrote:
> From: Linus Walleij <linus.walleij at linaro.org>
> 
> Recently as adoption of the pinctrl framework is reaching
> niches where the pins are reconfigured during system sleep
> and datasheets often talk about something called "GPIO mode",
> some engineers become confused by this, thinking that since
> it is named "GPIO (something something)" it must be modeled
> in the kernel using <linux/gpio.h>.
> 
> To clarify things, let's put in this piece of documentation,
> or just start off the discussion here.
> 
> Cc: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
> Cc: Pankaj Dev <pankaj.dev at st.com>
> Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
> ---
>  Documentation/pinctrl.txt | 112 +++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 112 insertions(+)
> 
> diff --git a/Documentation/pinctrl.txt b/Documentation/pinctrl.txt
> index a2b57e0..3e41545 100644
> --- a/Documentation/pinctrl.txt
> +++ b/Documentation/pinctrl.txt
> @@ -736,6 +736,13 @@ All the above functions are mandatory to implement for
> a pinmux driver. Pin control interaction with the GPIO subsystem
>  ===============================================
> 
> +Note that the following implies that the use case is to use a certain pin
> +from the Linux kernel using the API in <linux/gpio.h> with gpio_request()
> +and similar functions. There are cases where you may be using something
> +that your datasheet calls "GPIO mode" but actually is just an electrical
> +configuration for a certain device. See the section below named
> +"GPIO mode pitfalls" for more details on this scenario.
> +
>  The public pinmux API contains two functions named pinctrl_request_gpio()
>  and pinctrl_free_gpio(). These two functions shall *ONLY* be called from
>  gpiolib-based drivers as part of their gpio_request() and
> @@ -774,6 +781,111 @@ obtain the function "gpioN" where "N" is the global
> GPIO pin number if no special GPIO-handler is registered.
> 
> 
> +GPIO mode pitfalls
> +==================
> +
> +Sometime the developer may be confused by a datasheet talking about a pin
> +being possible to set into "GPIO mode". It appears that what hardware
> +engineers mean with "GPIO mode" is not necessarily the use case that is
> +implied in the kernel interface <linux/gpio.h>: a pin that you grab from
> +kernel code and then either listen for input or drive high/low to
> +assert/deassert some external line.
> +
> +Rather hardware engineers think that "GPIO mode" means that you can
> +software-control a few electrical properties of the pin that you would
> +not be able to control if the pin was in some other mode, such as muxed in
> +for a device.
> +
> +Example: a pin is usually muxed in to be used as a UART TX line. But during
> +system sleep, we need to put this pin into "GPIO mode" and ground it. +
> +If you make a 1-to-1 map to the GPIO subsystem for this pin, you may start
> +to think that you need to come up with something real complex, that the
> +pin shall be used for UART TX and GPIO at the same time, that you will grab
> +a pin control handle and set it to a certain state to enable UART TX to be
> +muxed in, then twist it over to GPIO mode and use gpio_direction_output()
> +to drive it low during sleep, then mux it over to UART TX again when you
> +wake up and maybe even gpio_request/gpio_free as part of this cycle. This
> +all gets very complicated.
> +
> +The solution is to not think that what the datasheet calls "GPIO mode"
> +has to be handled by the <linux/gpio.h> interface. Instead view this as
> +a certain pin config setting. Look in e.g.
> + <linux/pinctrl/pinconf-generic.h> and you find this in the documentation:
> +
> +  PIN_CONFIG_OUTPUT: this will configure the pin in output, use argument
> +     1 to indicate high level, argument 0 to indicate low level.
> +
> +So it is perfectly possible to push a pin into "GPIO mode" and drive the
> +line low as part of the usual pin control map. So for example your UART
> +driver may look like this:
> +
> +#include <linux/pinctrl/consumer.h>
> +
> +struct pinctrl          *pinctrl;
> +struct pinctrl_state    *pins_default;
> +struct pinctrl_state    *pins_sleep;
> +
> +pins_default = pinctrl_lookup_state(uap->pinctrl, PINCTRL_STATE_DEFAULT);
> +pins_sleep = pinctrl_lookup_state(uap->pinctrl, PINCTRL_STATE_SLEEP);
> +
> +/* Normal mode */
> +retval = pinctrl_select_state(pinctrl, pins_default);
> +/* Sleep mode */
> +retval = pinctrl_select_state(pinctrl, pins_sleep);
> +
> +And your machine configuration may look like this:
> +--------------------------------------------------
> +
> +static unsigned long uart_default_mode[] = {
> +    PIN_CONF_PACKED(PIN_CONFIG_DRIVE_PUSH_PULL, 0),
> +};
> +
> +static unsigned long uart_sleep_mode[] = {
> +    PIN_CONF_PACKED(PIN_CONFIG_OUTPUT, 0),
> +};

I'm having a bit of trouble with PIN_CONFIG_DRIVE_PUSH_PULL and 
PIN_CONFIG_OUTPUT. Strictly speaking, when configured in output mode, the pin 
will be in a push-pull configuration. Could you clarify the exact scope of the 
two configuration parameters ?

> +static struct pinctrl_map __initdata pinmap[] = {
> +    PIN_MAP_MUX_GROUP("uart", PINCTRL_STATE_DEFAULT", "pinctrl-foo",
> +                      "u0_group", "u0"),
> +    PIN_MAP_CONFIGS_PIN("uart", PINCTRL_STATE_DEFAULT, "pinctrl-foo",
> +                        "UART_TX_PIN", uart_default_mode),
> +    PIN_MAP_MUX_GROUP("uart", PINCTRL_STATE_SLEEP, "pinctrl-foo",
> +                      "u0_group", "gpio-mode"),
> +    PIN_MAP_CONFIGS_PIN("uart", PINCTRL_STATE_SLEEP, "pinctrl-foo",
> +                        "UART_TX_PIN", uart_sleep_mode),
> +};
> +
> +foo_init(void) {
> +    pinctrl_register_mappings(pinmap, ARRAY_SIZE(pinmap));
> +}
> +
> +Here the pins we want to control are in the "u0_group" and there is some
> +function called "u0" that can be enabled on this group of pins, and then
> +everything is UART business as usual. But there is also some function
> +named "gpio-mode" that can be mapped onto the same pins to move them into
> +GPIO mode.
> +
> +This will give the desired effect without any bogus interaction with the
> +GPIO subsystem. It is just an electrical configuration used by that device
> +when going to sleep, it might imply that the pin is set into something the
> +datasheet calls "GPIO mode" but that is not the point: it is still used
> +by that UART device to control the pins that pertain to that very UART
> +driver, putting them into modes needed by the UART. GPIO in the Linux
> +kernel sense are just some 1-bit line, and is a different use case.
> +
> +How the registers are poked to attain the push/pull and output low
> +configuration and the muxing of the "u0" or "gpio-mode" group onto these
> +pins is a question for the driver.
> +
> +Some datasheets will be more helpful and refer to the "GPIO mode" as
> +"low power mode" rather than anything to do with GPIO. This often means
> +the same thing electrically speaking, but in this latter case the
> +software engineers will usually quickly identify that this is some
> +specific muxing/configuration rather than anything related to the GPIO
> +API.
> +
> +
>  Board/machine configuration
>  ==================================

-- 
Regards,

Laurent Pinchart



From daniel.lezcano at linaro.org  Tue Apr 23 09:43:45 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Tue, 23 Apr 2013 15:43:45 +0200
Subject: [V3 patch 06/19] cpuidle: make a single register function for all
In-Reply-To: <516FB35D.7000303@ti.com>
References: <1365770165-27096-1-git-send-email-daniel.lezcano@linaro.org>
 <1365770165-27096-7-git-send-email-daniel.lezcano@linaro.org>
 <516FB35D.7000303@ti.com>
Message-ID: <51769011.7030608@linaro.org>

On 04/18/2013 10:48 AM, Santosh Shilimkar wrote:
> On Friday 12 April 2013 06:05 PM, Daniel Lezcano wrote:
>> The usual scheme to initialize a cpuidle driver on a SMP is:
>>
>> 	cpuidle_register_driver(drv);
>> 	for_each_possible_cpu(cpu) {
>> 		device = &per_cpu(cpuidle_dev, cpu);
>> 		cpuidle_register_device(device);
>> 	}
>>
> Not exactly related to $subject patch but the driver should
> be registered after all devices has been registered to avoid
> devices start using the idle state data as soon as it is
> registered. In multi CPU system, this race can easily happen.

Could you elaborate what problems the system will be facing if a cpu
starts using the idle state data as soon as it is registered ?

Is there a bug related to this ?

> Current CPUIDLE core layer is also written with the assumption
> that driver will be registered first and then the devices which
> is not mandatory as per typical drive/device model.

Yes, that's true. The framework assumes cpuidle_register_driver is
called before cpuidle_register_device.

> May be you can fix that part while you are creating this common
> wrapper.

Personally, as that will modify the cpuidle core layer and the changes
are not obvious (because of the design of the code) I prefer to do that
in a separate patchset if it is worth to do it - if there is a bug
related to it, then there is no discussion, we have to do it :)

[ ... ]

-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From shawn.guo at linaro.org  Tue Apr 23 09:44:50 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 23 Apr 2013 21:44:50 +0800
Subject: RFC: [PATCH] clocksource: tcb: fix min_delta calculation
In-Reply-To: <51768885.4080301@pengutronix.de>
References: <517687AB.1040309@pengutronix.de>
 <1366722524-25991-1-git-send-email-mkl@pengutronix.de>
 <51768885.4080301@pengutronix.de>
Message-ID: <20130423134448.GG27475@S2101-09.ap.freescale.net>

On Tue, Apr 23, 2013 at 03:11:33PM +0200, Marc Kleine-Budde wrote:
> On 04/23/2013 03:08 PM, Marc Kleine-Budde wrote:
> > The commit
> > 
> >     77cc982 clocksource: use clockevents_config_and_register() where possible
> > 
> > switches from manually calculating min_delta_ns (and others) and
> > clockevents_register_device() to automatic calculation via
> > clockevents_config_and_register(). During this conversation the "+ 1" in
> > 
> >     min_delta_ns = clockevent_delta2ns(1, &clkevt.clkevt) + 1;
> > 
> > was lost. This leads to problems with schedule_delayed_work() with a delay of
> > "1". Resulting in the work not scheduled in time.
> > 
> > This patch fixes the problem by increasing the min_delta to "2" ticks.
> > 
> > Signed-off-by: Marc Kleine-Budde <mkl at pengutronix.de>
> 
> The problem appears on at91sam9263. This patch successfully fixes the
> problem and applies to current linus/master (post v3.9-rc8).

Thanks for the fixing, Marc.

Acked-by: Shawn Guo <shawn.guo at linaro.org>



From mkl at pengutronix.de  Tue Apr 23 09:50:37 2013
From: mkl at pengutronix.de (Marc Kleine-Budde)
Date: Tue, 23 Apr 2013 15:50:37 +0200
Subject: RFC: [PATCH] clocksource: tcb: fix min_delta calculation
In-Reply-To: <20130423134448.GG27475@S2101-09.ap.freescale.net>
References: <517687AB.1040309@pengutronix.de>
 <1366722524-25991-1-git-send-email-mkl@pengutronix.de>
 <51768885.4080301@pengutronix.de>
 <20130423134448.GG27475@S2101-09.ap.freescale.net>
Message-ID: <517691AD.304@pengutronix.de>

On 04/23/2013 03:44 PM, Shawn Guo wrote:
> On Tue, Apr 23, 2013 at 03:11:33PM +0200, Marc Kleine-Budde wrote:
>> On 04/23/2013 03:08 PM, Marc Kleine-Budde wrote:
>>> The commit
>>>
>>>     77cc982 clocksource: use clockevents_config_and_register() where possible
>>>
>>> switches from manually calculating min_delta_ns (and others) and
>>> clockevents_register_device() to automatic calculation via
>>> clockevents_config_and_register(). During this conversation the "+ 1" in
>>>
>>>     min_delta_ns = clockevent_delta2ns(1, &clkevt.clkevt) + 1;
>>>
>>> was lost. This leads to problems with schedule_delayed_work() with a delay of
>>> "1". Resulting in the work not scheduled in time.
>>>
>>> This patch fixes the problem by increasing the min_delta to "2" ticks.
>>>
>>> Signed-off-by: Marc Kleine-Budde <mkl at pengutronix.de>
>>
>> The problem appears on at91sam9263. This patch successfully fixes the
>> problem and applies to current linus/master (post v3.9-rc8).
> 
> Thanks for the fixing, Marc.
> 
> Acked-by: Shawn Guo <shawn.guo at linaro.org>

Thanks. The downside of my RFC Patch is, that min_delta_ns is increased
from 30518 to 61035:

good: setup_clkevents: shift=32 mult=140737 min=30518 max=1999976422
bad:  setup_clkevents: shift=32 mult=140737 min=30517 max=1999976422
RFC:  setup_clkevents: shift=32 mult=140737 min=61035 max=1999976422

To keep the original min_delta_ns value of 30518, a rather hackish
option would be this:

diff --git a/drivers/clocksource/tcb_clksrc.c b/drivers/clocksource/tcb_clksrc.c
index 8a61872..30e0a68 100644
--- a/drivers/clocksource/tcb_clksrc.c
+++ b/drivers/clocksource/tcb_clksrc.c
@@ -198,6 +198,7 @@ static void __init setup_clkevents(struct atmel_tc *tc, int clk32k_divisor_idx)
        clkevt.clkevt.cpumask = cpumask_of(0);

        clockevents_config_and_register(&clkevt.clkevt, 32768, 1, 0xffff);
+       clkevt.clkevt.min_delta_ns = clockevent_delta2ns(1, &clkevt.clkevt) + 1;

        setup_irq(irq, &tc_irqaction);
 }

Marc

-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130423/111540f3/attachment-0001.sig>

From tixy at linaro.org  Tue Apr 23 09:52:08 2013
From: tixy at linaro.org (Jon Medhurst (Tixy))
Date: Tue, 23 Apr 2013 14:52:08 +0100
Subject: [RFC PATCH] drivers: bus: add ARM CCI support
In-Reply-To: <1365691679-28674-2-git-send-email-lorenzo.pieralisi@arm.com>
References: <1365691679-28674-1-git-send-email-lorenzo.pieralisi@arm.com>
 <1365691679-28674-2-git-send-email-lorenzo.pieralisi@arm.com>
Message-ID: <1366725128.8473.21.camel@computer5.home>

On Thu, 2013-04-11 at 15:47 +0100, Lorenzo Pieralisi wrote:
[...]
> diff --git a/drivers/bus/arm-cci.c b/drivers/bus/arm-cci.c
> new file mode 100644
> index 0000000..81953de
> --- /dev/null
> +++ b/drivers/bus/arm-cci.c
> @@ -0,0 +1,344 @@
> +/*
> + * CCI cache coherent interconnect driver
> + *
> + * Copyright (C) 2013 ARM Ltd.
> + * Author: Lorenzo Pieralisi <lorenzo.pieralisi at arm.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.
> + *
> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
> + * kind, whether express or implied; without even the implied warranty
> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include <linux/arm-cci.h>
> +#include <linux/device.h>
> +#include <linux/io.h>
> +#include <linux/module.h>
> +#include <linux/of_address.h>
> +#include <linux/of_device.h>
> +#include <linux/platform_device.h>
> +#include <linux/slab.h>
> +
> +#include <asm/cacheflush.h>
> +#include <asm/dt_affinity.h>
> +#include <asm/outercache.h>
> +#include <asm/smp_plat.h>
> +
> +#define DRIVER_NAME		"CCI"
> +#define CCI_CTRL_STATUS		0xc
> +
> +#define CCI_PORT_CTRL		0x0
> +
> +struct cci_nb_ports {
> +	unsigned int nb_ace;
> +	unsigned int nb_ace_lite;
> +};
> +
> +enum cci_ace_port_type {
> +	ACE_INVALID_PORT = 0x0,
> +	ACE_PORT,
> +	ACE_LITE_PORT,
> +};
> +
> +struct cci_ace_port {
> +	void __iomem *base;
> +	int type;
> +	union {
> +		cpumask_t match_mask;
> +		struct device_node *np;
> +	} match;
> +};
> +
> +static struct cci_ace_port *ports;
> +static unsigned int nb_cci_ports;
> +
> +static void __iomem *cci_ctrl_base;
> +#define INVALID_PORT_IDX	-1
> +static int cpu_port[NR_CPUS] = { [0 ... NR_CPUS-1] = INVALID_PORT_IDX };
> +
> +static void __init cci_ace_init_ports(void)
> +{
> +	bool is_ace;
> +	int port, cpu;
> +	/*
> +	 * Port index look-up speeds up the function disabling ports by CPU,
> +	 * since the logical to port index mapping is done once and does
> +	 * not change after system boot.
> +	 * The stashed index array is initialized for all possible CPUs
> +	 * at probe time.
> +	 */
> +	for_each_possible_cpu(cpu) {
> +		for (port = 0; port < nb_cci_ports; port++) {
> +			is_ace = ports[port].type == ACE_PORT;
> +			if (is_ace && cpu_isset(cpu,
> +					 ports[port].match.match_mask)) {
> +				cpu_port[cpu] = port;
> +				break;
> +			}
> +		}
> +		WARN(cpu_port[cpu] == INVALID_PORT_IDX, "CPU %d has an invalid"
> +							" CCI port index\n",

I think the convention is to not split user visible messages across
multiple source lines as this makes grepping for them difficult.

> +							cpu);
> +	}
> +}
> +
> +/*
> + * cci_ace_lite_port - Function to retrieve the port index corresponding to
> + *		       a device tree node
> + *
> + * @np = device tree node to match
> + *
> + * Return value:
> + *	- ACE LITE port index if success
> + *	- -EINVAL if failure
> + *
> + */
> +static int cci_ace_lite_port(struct device_node *np)
> +{
> +	int i;
> +	bool is_ace_lite;
> +
> +	for (i = 0; i < nb_cci_ports; i++) {
> +		is_ace_lite = ports[i].type == ACE_LITE_PORT;
> +		if (is_ace_lite && np == ports[i].match.np)
> +			return i;
> +	}
> +	return -ENODEV;
> +}
> +
> +/*
> + * Functions to enable/disable a CCI interconnect slave port
> + *
> + * They are called by low-level power management code to disable slave
> + * interfaces snoops and DVM broadcast.
> + * Since they may execute with cache data allocation disabled and
> + * after the caches have been cleaned and invalidated the functions provide
> + * no explicit locking since they may run with D-cache disabled, so normal
> + * cacheable kernel locks based on ldrex/strex may not work.
> + * Locking has to be provided by BSP implementations to ensure proper
> + * operations.
> + */
> +
> +/*
> + * cci_port_control()
> + *	@port = index of the port to setup
> + *	@enable = if true enables the port, if false disables it
> + */
> +static void notrace cci_port_control(unsigned int port, bool enable)
> +{
> +	void __iomem *base = ports[port].base;
> +
> +	if (!base)
> +		return;
> +
> +	writel_relaxed(enable, base + CCI_PORT_CTRL);

If enable is bool (0 or 1) then this is going to set snoops as specified
but is always going to clear DVM broadcast as that is controlled by bit1
of the register. So, does the API need specifying different to allow the
caller to choose DVM state as well, or does this function need to assume
DVM and snoops state should be equal? I.e.

	writel_relaxed(enable ? 0x3 : 0x0, base + CCI_PORT_CTRL);


> +	while (readl_relaxed(cci_ctrl_base + CCI_CTRL_STATUS) & 0x1)
> +			;
> +}
> +
> +/*
> + * cci_disable_port_by_cpu()
> + *	@mpidr = mpidr of the CPU whose CCI port should be disabled
> + *	Returns:
> + *		0 on success
> + *		-ENODEV on port look-up failure
> + *
> + * Disabling a CCI port for a CPU implies disabling the CCI port
> + * controlling that CPU cluster. Code disabling CPU CCI ports
> + * must make sure that the CPU running the code is the last active CPU
> + * in the cluster ie all other CPUs are quiescent in a low power state.
> + */
> +int notrace cci_disable_port_by_cpu(u64 mpidr)
> +{
> +	int cpu = get_logical_index(mpidr & MPIDR_HWID_BITMASK);
> +
> +	if (cpu < 0 || cpu_port[cpu] == INVALID_PORT_IDX)
> +		return -ENODEV;
> +	cci_port_control(cpu_port[cpu], false);
> +	return 0;
> +}
> +EXPORT_SYMBOL_GPL(cci_disable_port_by_cpu);
> +
> +/*
> + * __cci_control_port_by_device()
> + *	@np = device_node of the device whose CCI port should be enabled
> + *	@enable = if true enables the port, if false disables it
> + *	Returns:
> + *		0 on success
> + *		-ENODEV on port look-up failure
> + */
> +int notrace __cci_control_port_by_device(struct device_node *np, bool enable)
> +{
> +	int port = cci_ace_lite_port(np);
> +	if (WARN_ONCE(port < 0,
> +		      "ACE lite port look-up failure, node %p\n", np))
> +		return -ENODEV;
> +	cci_port_control(port, enable);
> +	return 0;
> +}
> +EXPORT_SYMBOL_GPL(__cci_control_port_by_device);
> +
> +static const struct of_device_id arm_cci_matches[];
> +
> +static int __init cci_driver_probe(struct platform_device *pdev)
> +{
> +	const struct of_device_id *match;
> +	struct cci_nb_ports const *cci_config;
> +	int ret, j, i, nb_ace = 0, nb_ace_lite = 0;
> +	struct device_node *np, *cp;
> +	const char *match_str;
> +
> +	match = of_match_device(arm_cci_matches, &pdev->dev);
> +
> +	if (!match)
> +		return -ENODEV;
> +
> +	cci_config = (struct cci_nb_ports const *)match->data;
> +	nb_cci_ports = cci_config->nb_ace + cci_config->nb_ace_lite;
> +	ports = kzalloc(sizeof(*ports) * nb_cci_ports, GFP_KERNEL);
> +	if (!ports)
> +		return -ENOMEM;
> +
> +	np = pdev->dev.of_node;
> +	cci_ctrl_base = of_iomap(np, 0);
> +
> +	if (!cci_ctrl_base) {
> +		dev_err(&pdev->dev, "unable to ioremap CCI ctrl\n");
> +		ret = -ENXIO;
> +		goto memalloc_err;
> +	}
> +	for_each_child_of_node(np, cp) {
> +		i = nb_ace + nb_ace_lite;
> +
> +		if (i >= nb_cci_ports)
> +			break;
> +
> +		if (of_property_read_string(cp, "interface-type",
> +					    &match_str)) {
> +			WARN(1, " * %s missing interface-type property\n",
> +				  cp->full_name);
> +			continue;
> +		}
> +
> +		/*
> +		 * A CCI interface has to define a "master" affinity
> +		 * property otherwise it is not considered valid
> +		 */
> +		if (!strcmp(match_str, "ace")) {
> +			if (WARN_ON(nb_ace >= cci_config->nb_ace))
> +				continue;
> +			cpumask_clear(&ports[i].match.match_mask);
> +			if (arm_dt_affine_get_mask(cp, "master", 0,
> +					&ports[i].match.match_mask))
> +				continue;
> +			ports[i].type = ACE_PORT;
> +			++nb_ace;
> +		} else if (!strcmp(match_str, "ace-lite")) {
> +			if (WARN_ON(nb_ace_lite >= cci_config->nb_ace_lite))
> +				continue;
> +
> +			ports[i].match.np =
> +				of_parse_phandle(cp, "master", 0);
> +
> +			if (!ports[i].match.np)
> +				continue;
> +			of_node_put(ports[i].match.np);
> +			ports[i].type = ACE_LITE_PORT;
> +			++nb_ace_lite;
> +		} else {
> +			WARN(1, " * %s containing invalid interface-type"
> +				" property, skipping it\n", cp->full_name);

Error message being split across multiple lines again.

> +			continue;
> +		}
> +
> +		ports[i].base = of_iomap(cp, 0);
> +
> +		if (!ports[i].base) {
> +			dev_err(&pdev->dev, "unable to ioremap "
> +					    "ace port %d\n", i);

Split error message again.

> +			ret = -ENXIO;
> +			goto ioremap_err;
> +		}
> +	}
> +	cci_ace_init_ports();
> +	/*
> +	 * Multi-cluster systems may need this data when non-coherent, during
> +	 * cluster power-up/power-down. Make sure it reaches main memory:
> +	 */
> +	__cpuc_flush_dcache_area(ports, sizeof(*ports) * nb_cci_ports);
> +	__cpuc_flush_dcache_area(&cci_ctrl_base, sizeof cci_ctrl_base);
> +	__cpuc_flush_dcache_area(cpu_port, sizeof cpu_port);
> +	outer_clean_range(virt_to_phys(ports),
> +			  virt_to_phys(ports + nb_cci_ports));
> +	outer_clean_range(virt_to_phys(&cci_ctrl_base),
> +			  virt_to_phys(&cci_ctrl_base + 1));
> +	outer_clean_range(virt_to_phys(cpu_port),
> +			  virt_to_phys(cpu_port + NR_CPUS));
> +	dev_info(&pdev->dev, "ARM CCI driver probed\n");
> +	return 0;
> +
> +ioremap_err:
> +	for (j = 0; j < nb_cci_ports; j++) {
> +		if (j == i)
> +			break;
> +		iounmap(ports[j].base);
> +	}

That loop would be simpler as:

	while (--i >= 0)
		iounmap(ports[i].base);

and declaration of 'j' can dropped from the function start.


> +
> +	iounmap(cci_ctrl_base);
> +memalloc_err:
> +
> +	kfree(ports);
> +	return ret;
> +}
> +
> +static int __exit cci_driver_remove(struct platform_device *pdev)

Under what circumstances would we want to remove the driver?

> +{
> +	int i;
> +
> +	for (i = 0; i < nb_cci_ports; i++)
> +		if (ports[i].base)
> +			iounmap(ports[i].base);
> +
> +	iounmap(cci_ctrl_base);
> +	kfree(ports);
> +	return 0;
> +}
> +
> +static const struct cci_nb_ports cci400_ports = {
> +	.nb_ace = 2,
> +	.nb_ace_lite = 3
> +};
> +
> +static const struct of_device_id arm_cci_matches[] = {
> +	{.compatible = "arm,cci-400", .data = &cci400_ports },
> +	{},
> +};
> +
> +static struct platform_driver cci_platform_driver = {
> +	.driver = {
> +		   .owner = THIS_MODULE,
> +		   .name = DRIVER_NAME,
> +		   .of_match_table = arm_cci_matches,
> +		   },
> +	.probe = cci_driver_probe,
> +	.remove = cci_driver_remove,
> +};
> +
> +static int __init cci_init(void)
> +{
> +	return platform_driver_register(&cci_platform_driver);
> +}
> +
> +static void __exit cci_exit(void)
> +{
> +	platform_driver_unregister(&cci_platform_driver);
> +}
> +
> +core_initcall(cci_init);
> +module_exit(cci_exit);
> +MODULE_LICENSE("GPL");
> +MODULE_DESCRIPTION("ARM CCI support");
[...]

-- 
Tixy



From lorenzo.pieralisi at arm.com  Tue Apr 23 09:53:04 2013
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Tue, 23 Apr 2013 14:53:04 +0100
Subject: [RFC PATCH v2 03/13] ARM: mach-at91: cpus/cpu node dts updates
In-Reply-To: <51768892.7060807@gmail.com>
References: <1366644455-16550-1-git-send-email-lorenzo.pieralisi@arm.com>
 <1366644455-16550-4-git-send-email-lorenzo.pieralisi@arm.com>
 <51768892.7060807@gmail.com>
Message-ID: <20130423135304.GG22946@e102568-lin.cambridge.arm.com>

On Tue, Apr 23, 2013 at 02:11:46PM +0100, Rob Herring wrote:
> On 04/22/2013 10:27 AM, Lorenzo Pieralisi wrote:
> > This patch updates the in-kernel dts files according to the latest cpus
> > and cpu bindings updates for ARM.
> > 
> > Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
> > ---
> >  arch/arm/boot/dts/at91sam9260.dtsi | 2 +-
> >  arch/arm/boot/dts/at91sam9263.dtsi | 2 +-
> >  arch/arm/boot/dts/at91sam9g45.dtsi | 2 +-
> >  arch/arm/boot/dts/at91sam9n12.dtsi | 2 +-
> >  4 files changed, 4 insertions(+), 4 deletions(-)
> > 
> > diff --git a/arch/arm/boot/dts/at91sam9260.dtsi b/arch/arm/boot/dts/at91sam9260.dtsi
> > index cb7bcc5..2e9de85 100644
> > --- a/arch/arm/boot/dts/at91sam9260.dtsi
> > +++ b/arch/arm/boot/dts/at91sam9260.dtsi
> > @@ -33,7 +33,7 @@
> >  	};
> >  	cpus {
> >  		cpu at 0 {
> > -			compatible = "arm,arm926ejs";
> > +			compatible = "arm,arm926";
> 
> I don't understand why you are doing this. If this does not match the
> documentation, fix the documentation. We can't continue on changing dts
> files without reqard to breaking compatibility.

IMHO compatibility is already broken. There are a number of dts in the
kernel missing cpus and cpu nodes, others with cpu nodes missing
device_type = "cpu", missing cpu nodes compatible properties and the list
goes on and on. Those files got merged in the kernel before bindings were
properly defined for ARM so at that point in time the only reference was the
ePAPR and still, it was not followed (eg my broken patch above fails to add
device_type = "cpu" to the cpu node, should I change the documentation (ePAPR)
to make the dts above compliant ? I do not think so, I reckon we should fix
all dts and force them to comply with the ePAPR and the in-kernel bindings).

If we do not set in stone the bindings and draw a line now, this stuff will
go wild, it is already in a state that I do not like much.

The reason we are patching the compatible property above is to avoid having
compatible properties containing suffixes for CPUs, we do not deem that
necessary, see:

http://lists.infradead.org/pipermail/linux-arm-kernel/2013-January/145305.html

That's just my opinion, open to change it to find a proper solution to this
issue as long as we make progress.

Thanks for the review,
Lorenzo

> 
> Rob
> 
> >  		};
> >  	};
> >  
> > diff --git a/arch/arm/boot/dts/at91sam9263.dtsi b/arch/arm/boot/dts/at91sam9263.dtsi
> > index 271d4de..25c4725 100644
> > --- a/arch/arm/boot/dts/at91sam9263.dtsi
> > +++ b/arch/arm/boot/dts/at91sam9263.dtsi
> > @@ -30,7 +30,7 @@
> >  	};
> >  	cpus {
> >  		cpu at 0 {
> > -			compatible = "arm,arm926ejs";
> > +			compatible = "arm,arm926";
> >  		};
> >  	};
> >  
> > diff --git a/arch/arm/boot/dts/at91sam9g45.dtsi b/arch/arm/boot/dts/at91sam9g45.dtsi
> > index 6b1d4ca..cf647d1 100644
> > --- a/arch/arm/boot/dts/at91sam9g45.dtsi
> > +++ b/arch/arm/boot/dts/at91sam9g45.dtsi
> > @@ -36,7 +36,7 @@
> >  	};
> >  	cpus {
> >  		cpu at 0 {
> > -			compatible = "arm,arm926ejs";
> > +			compatible = "arm,arm926";
> >  		};
> >  	};
> >  
> > diff --git a/arch/arm/boot/dts/at91sam9n12.dtsi b/arch/arm/boot/dts/at91sam9n12.dtsi
> > index 7750f98..d531ae3 100644
> > --- a/arch/arm/boot/dts/at91sam9n12.dtsi
> > +++ b/arch/arm/boot/dts/at91sam9n12.dtsi
> > @@ -32,7 +32,7 @@
> >  	};
> >  	cpus {
> >  		cpu at 0 {
> > -			compatible = "arm,arm926ejs";
> > +			compatible = "arm,arm926";
> >  		};
> >  	};
> >  
> > 
> 
> 



From grygorii.strashko at ti.com  Tue Apr 23 09:53:12 2013
From: grygorii.strashko at ti.com (Grygorii Strashko)
Date: Tue, 23 Apr 2013 16:53:12 +0300
Subject: Multiple issues with omap4 panda es in linux next
In-Reply-To: <20130422180822.GB10155@atomide.com>
References: <20130419171318.GK10155@atomide.com> <5174FE16.6080307@ti.com>
 <51750FF8.6000401@ti.com> <51752B48.50700@ti.com>
 <20130422180822.GB10155@atomide.com>
Message-ID: <51769248.60602@ti.com>

On 04/22/2013 09:08 PM, Tony Lindgren wrote:
> * Grygorii Strashko <grygorii.strashko at ti.com> [130422 05:27]:
>> On 04/22/2013 01:24 PM, Tomi Valkeinen wrote:
>>> On 2013-04-22 12:08, Tomi Valkeinen wrote:
>>>> On 2013-04-19 20:13, Tony Lindgren wrote:
>>>>
>>>>> 3. DSS fails with DT booting
>>>>>
>>>>> Works with legacy booting but fails with DT. I'm almost certain
>>>>> the DT booting was working last week or so?
>>>>>
>>>>> This is what I now get with DT booting:
>>>>>
>>>>> omapdss DSI error: can't get VDDS_DSI regulator
>>>>> omapdss HDMI error: can't get VDDA_HDMI_DAC regulator
>>>>> omapdss HDMI error: device hdmi init failed: -517
>>>>> omapdss CORE error: driver probe failed: -22
>>>>> ...
>>>> I think this is the issue Christoph Fritz reported earlier, DSS is being
>>>> initialized before TWL, and thus DSS doesn't find the regulators.
>>>>
>>>> The proper fix is of course to make DSS support EPROBE_DEFER, but that's
>>>> easier said than done. I'll have a look if I can get it working enough
>>>> to fix this issue.
>>> Yes, it seems delayed regulator initialization brought up this issue.
>>>
>>> I hacked DSI driver of omapdss and Taal panel driver to somewhat work
>>> with EPROBE_DEFER. But then the issue was with omapfb.
>>>
>>> omapfb is currently set to start at late_initcall, so that omapdss and
>>> panels are loaded before omapfb. But even that's not late enough to get
>>> the regulators for omapdss. It seems the regulators get also initialized
>>> at the late_initcall level. Changing omapfb to late_initcall_sync was
>>> late enough to get things working.
>>>
>>> Again, making omapdss, panel drivers and omapfb support EPROBE_DEFER and
>>> dynamic panel driver insertion is the proper fix, but it's a big job,
>>> and there are "interesting" issues with it (like how to know if a panel
>>> device will ever get a driver loaded).
>>>
>>> But is there something wrong with the TWL and regulators? late_initcall
>>> sounds rather late for such a core resource. Even if all drivers
>>> supported EPROBE_DEFER, won't it cause extra delays in the boot as
>>> drivers are getting probed multiple times?
>>>
>>> As for fixing the DSS problem for 3.10, I don't have any ideas except
>>> pure hacks. I'll continue studying this.
>> Hi Tomi,
>> twl is not initialized because of I2C,
>> I2C is not initialized because of pinctrl-single,
>> pinctrl-single is initialized at mudule/device init time.
>> So, most everything will be shifted at late_initcall time.
>>
>> Hack that sequence is here - https://patchwork.kernel.org/patch/2444501/
> Hmm I'm pretty sure the LCD was working on panda with DT
> few weeks ago?
>
> In any case, all those drivers should be just module_init
> so we get out of the race to bottom to initialize drivers
> early. Pinctrl is already before i2c in drivers/Makefile.
>
> I suspect there may be some recent regression that has
> happened in linux next over past few weeks.
Hi Tony,

I've posted two patches to fix I2C/TWL initialization and they should fix
DSS indirectly (if not - DSS need to be shifted to init later).
lkml.org/lkml/2013/4/23/215
lkml.org/lkml/2013/4/23/217

In addition, It seems, possibly :), drivers/Makefile might need to be 
changed a bit:
- move generic drivers framework to be initialized first ("base", "clk");
- move "i2c" buses initialization as early as possible (but after 
"pinctrl" and "gpio")
- move "mfd" initialization before "regulators"
- move "video" initialization down after "regulators" (as minimum).

Regards
-grygorii
> Regards,
>
> Tony
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



From santosh.shilimkar at ti.com  Tue Apr 23 09:56:38 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Tue, 23 Apr 2013 19:26:38 +0530
Subject: [V3 patch 06/19] cpuidle: make a single register function for all
In-Reply-To: <51769011.7030608@linaro.org>
References: <1365770165-27096-1-git-send-email-daniel.lezcano@linaro.org>
 <1365770165-27096-7-git-send-email-daniel.lezcano@linaro.org>
 <516FB35D.7000303@ti.com> <51769011.7030608@linaro.org>
Message-ID: <51769316.9090309@ti.com>

On Tuesday 23 April 2013 07:13 PM, Daniel Lezcano wrote:
> On 04/18/2013 10:48 AM, Santosh Shilimkar wrote:
>> On Friday 12 April 2013 06:05 PM, Daniel Lezcano wrote:
>>> The usual scheme to initialize a cpuidle driver on a SMP is:
>>>
>>> 	cpuidle_register_driver(drv);
>>> 	for_each_possible_cpu(cpu) {
>>> 		device = &per_cpu(cpuidle_dev, cpu);
>>> 		cpuidle_register_device(device);
>>> 	}
>>>
>> Not exactly related to $subject patch but the driver should
>> be registered after all devices has been registered to avoid
>> devices start using the idle state data as soon as it is
>> registered. In multi CPU system, this race can easily happen.
> 
> Could you elaborate what problems the system will be facing if a cpu
> starts using the idle state data as soon as it is registered ?
> 
> Is there a bug related to this ?
>
Ofcouse. In multi-CPU scenario, where CPU C-states needs co-ordination
can just lead into unknown issues if all the CPUs are not already part
registered.
 
>> Current CPUIDLE core layer is also written with the assumption
>> that driver will be registered first and then the devices which
>> is not mandatory as per typical drive/device model.
> 
> Yes, that's true. The framework assumes cpuidle_register_driver is
> called before cpuidle_register_device.
> 
>> May be you can fix that part while you are creating this common
>> wrapper.
> 
> Personally, as that will modify the cpuidle core layer and the changes
> are not obvious (because of the design of the code) I prefer to do that
> in a separate patchset if it is worth to do it - if there is a bug
> related to it, then there is no discussion, we have to do it :)
> 
Sure. It would have been nice if you would have clarified that before
posting the next version.

You still need to fix the kernel doc in your v4 though.

Regards,
Santosh



From kgene.kim at samsung.com  Tue Apr 23 09:56:13 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Tue, 23 Apr 2013 22:56:13 +0900
Subject: [PATCH v2 2/3] ARM: EXYNOS: Fix support of Exynos4210 rev0 SoC
In-Reply-To: <201304222310.34775.arnd@arndb.de>
References: <1366036922-4103-1-git-send-email-t.figa@samsung.com>
 <1366036922-4103-3-git-send-email-t.figa@samsung.com>
 <201304222310.34775.arnd@arndb.de>
Message-ID: <517692FD.9080005@samsung.com>

On 04/23/13 06:10, Arnd Bergmann wrote:
> On Monday 15 April 2013, Tomasz Figa wrote:
>> This patch extends exynos_init_time() function to handle Exynos4210 rev0
>> SoC, which differs in availability of system timers and needs different
>> clocksource initialization.
>>
>> This makes it possible to use exynos_init_time() function as init_time
>> callback for all Exynos-based boards, including Universal_C210, which
>> originally had to use samsung_timer_init().
>>
>> Signed-off-by: Tomasz Figa<t.figa at samsung.com>
>
> Acked-by: Arnd Bergmann<arnd at arndb.de>
>
> Note that it would be helpful to mention here that this is required for
> the calling samsung_timer_init from the exynos4-dt.c file.
>
I did 'amend' as per your suggestion and added your ack on this series.

Thanks.

- Kukjin


From kgene.kim at samsung.com  Tue Apr 23 10:14:54 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Tue, 23 Apr 2013 23:14:54 +0900
Subject: [PATCH RESEND] ARM: EXYNOS: no more support non-DT for EXYNOS SoCs
In-Reply-To: <201304222111.45653.arnd@arndb.de>
References: <51642dab.e844440a.0ad1.ffffc13f@mx.google.com>
 <516571BC.9030909@samsung.com> <51756E98.9040606@samsung.com>
 <201304222111.45653.arnd@arndb.de>
Message-ID: <5176975E.5000802@samsung.com>

On 04/23/13 04:11, Arnd Bergmann wrote:

>>>> I still have hope to get those included.
>>>>
>>> I agree and I asked Tomasz to re-send universal dt patch.
>>>
>> Hi Arnd and Olof,
>>
>> Is it possible to send one more pull-request for this and something like
>> dt patches for exynos?
>
> I think it's too late for that now, let's just fix the broken pieces
> now and do the minimum amount of patches on top of what we have:
>
Agreed, but following has been sent to arm-soc as a name of 'dt-exynos2 
for v3.10' at 4/10, even though its base should be fixed.

--------8<----------------8<---------
Sachin Kamat (5):
       ARM: dts: Remove keypad entries from exynos4x12-pinctrl.dtsi
       ARM: dts: Add keypad entries to Exynos4412 based Origen
       ARM: dts: Add keypad entries to SMDK4412
       ARM: dts: Add MFC clock entries for exynos4
       ARM: dts: Update MFC documentation for clock entries

Vivek Gautam (5):
       ARM: dts: Enabling samsung-usb2phy driver for exynos5250
       ARM: dts: Enabling samsung-usb3phy driver for exynos5250
       ARM: dts: Add device tree bindings for dwc3-exynos
       ARM: dts: Enabling dwc3-exynos driver for exynos5250
       ARM: EXYNOS: Enable XHCI support on exynos5

.../devicetree/bindings/media/s5p-mfc.txt          |  5 ++
  .../devicetree/bindings/usb/exynos-usb.txt         | 34 +++++++++
  arch/arm/boot/dts/exynos4.dtsi                     |  2 +
  arch/arm/boot/dts/exynos4412-origen.dts            | 62 +++++++++++++++
  arch/arm/boot/dts/exynos4412-smdk4412.dts          | 87 
++++++++++++++++++++++
  arch/arm/boot/dts/exynos4x12-pinctrl.dtsi          | 56 --------------
  arch/arm/boot/dts/exynos5250.dtsi                  | 45 +++++++++++
  arch/arm/mach-exynos/Kconfig                       |  1 +
  8 files changed, 236 insertions(+), 56 deletions(-)
--------8<----------------8<---------

So I'd like to send below you mentioned with above.

Note that I will send this removing non-DT exynos support patch to 
arm-soc tree after release v3.10-rc1.

> * Thomas Abraham's fix for the clk code

Included in my late-dt branch for exynos.

> * Tomasz Figa's patch to restore Universal C210

If you mean '[PATCH v2 0/3] ARM: EXYNOS: DT-enabled support for 
Universal C210', the series included but as I know, that depends on 
'[PATCH v5 00/14] ARM: samsung-time: Prepare for multiplatform support' 
you asked to postpone for v3.11...

> * Whatever is needed to get USB working again on Arndale

Hmm, I'm not sure which patch is needed for this on Arndale, 
unfortunately, I don't have the platform...Probably above Vivek's patches?

> * Anything else that comes up that is really a bug fix.

Yes, right.

> * Getting the PWM and ADC drivers working with DT, that can
>    easily be done.

OK.

> * Possibly a patch to mark CONFIG_EXYNOS_ATAGS as broken,
>    if you think that helps.

Yes.

> but not:
>
> * The entire series to rework the PWM clock from Tomasz

See above comments.

> * The entire series to remove ATAGS support on Exynos

OK.

> * Any other non-bugfix patches
>
OK.

- Kukjin


From daniel.lezcano at linaro.org  Tue Apr 23 10:22:07 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Tue, 23 Apr 2013 16:22:07 +0200
Subject: [V3 patch 06/19] cpuidle: make a single register function for all
In-Reply-To: <51769316.9090309@ti.com>
References: <1365770165-27096-1-git-send-email-daniel.lezcano@linaro.org>
 <1365770165-27096-7-git-send-email-daniel.lezcano@linaro.org>
 <516FB35D.7000303@ti.com> <51769011.7030608@linaro.org>
 <51769316.9090309@ti.com>
Message-ID: <5176990F.5070605@linaro.org>

On 04/23/2013 03:56 PM, Santosh Shilimkar wrote:
> On Tuesday 23 April 2013 07:13 PM, Daniel Lezcano wrote:
>> On 04/18/2013 10:48 AM, Santosh Shilimkar wrote:
>>> On Friday 12 April 2013 06:05 PM, Daniel Lezcano wrote:
>>>> The usual scheme to initialize a cpuidle driver on a SMP is:
>>>>
>>>> 	cpuidle_register_driver(drv);
>>>> 	for_each_possible_cpu(cpu) {
>>>> 		device = &per_cpu(cpuidle_dev, cpu);
>>>> 		cpuidle_register_device(device);
>>>> 	}
>>>>
>>> Not exactly related to $subject patch but the driver should
>>> be registered after all devices has been registered to avoid
>>> devices start using the idle state data as soon as it is
>>> registered. In multi CPU system, this race can easily happen.
>>
>> Could you elaborate what problems the system will be facing if a cpu
>> starts using the idle state data as soon as it is registered ?
>>
>> Is there a bug related to this ?
>>
> Ofcouse. In multi-CPU scenario, where CPU C-states needs co-ordination
> can just lead into unknown issues if all the CPUs are not already part
> registered.

Hmm, ok. I don't see a scenario, with the current code, where that could
occurs. The coupled idle state will wait for the other cpus to enter
idle before initiating a shutdown sequence and, so far, the other sync
algorithm (last man standing) are doing the same.

There are some systems with 1024 cpus, and I did not heard problems like
this.

Do you know a system where this problem occurred ? Or is it something
you suspect that can happen ?

That would be interesting to have a system where this race occurs in
order to check the modifications will solve the issue.

>>> Current CPUIDLE core layer is also written with the assumption
>>> that driver will be registered first and then the devices which
>>> is not mandatory as per typical drive/device model.
>>
>> Yes, that's true. The framework assumes cpuidle_register_driver is
>> called before cpuidle_register_device.
>>
>>> May be you can fix that part while you are creating this common
>>> wrapper.
>>
>> Personally, as that will modify the cpuidle core layer and the changes
>> are not obvious (because of the design of the code) I prefer to do that
>> in a separate patchset if it is worth to do it - if there is a bug
>> related to it, then there is no discussion, we have to do it :)
>>
> Sure. It would have been nice if you would have clarified that before
> posting the next version.
> 
> You still need to fix the kernel doc in your v4 though.

Which one ? "s/accross/across" ?

Thanks
  -- Daniel

-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From t.figa at samsung.com  Tue Apr 23 10:26:15 2013
From: t.figa at samsung.com (Tomasz Figa)
Date: Tue, 23 Apr 2013 16:26:15 +0200
Subject: [PATCH v2 2/3] ARM: EXYNOS: Fix support of Exynos4210 rev0 SoC
In-Reply-To: <517692FD.9080005@samsung.com>
References: <1366036922-4103-1-git-send-email-t.figa@samsung.com>
 <201304222310.34775.arnd@arndb.de> <517692FD.9080005@samsung.com>
Message-ID: <1696892.zdvbYPFFr0@amdc1227>

Hi Kukjin,

On Tuesday 23 of April 2013 22:56:13 Kukjin Kim wrote:
> On 04/23/13 06:10, Arnd Bergmann wrote:
> > On Monday 15 April 2013, Tomasz Figa wrote:
> >> This patch extends exynos_init_time() function to handle Exynos4210 rev0
> >> SoC, which differs in availability of system timers and needs different
> >> clocksource initialization.
> >> 
> >> This makes it possible to use exynos_init_time() function as init_time
> >> callback for all Exynos-based boards, including Universal_C210, which
> >> originally had to use samsung_timer_init().
> >> 
> >> Signed-off-by: Tomasz Figa<t.figa at samsung.com>
> > 
> > Acked-by: Arnd Bergmann<arnd at arndb.de>
> > 
> > Note that it would be helpful to mention here that this is required for
> > the calling samsung_timer_init from the exynos4-dt.c file.
> 
> I did 'amend' as per your suggestion and added your ack on this series.
> 
> Thanks.
> 
> - Kukjin

Since the samsung-time rework patches were replaced with a non-invasive subset 
with different semantics (going to send them in a while), this patch should be 
replaced with new version I'm going to send (in a while as well).

Best regards,
-- 
Tomasz Figa
Samsung Poland R&D Center
SW Solution Development, Kernel and System Framework



From lorenzo.pieralisi at arm.com  Tue Apr 23 10:27:41 2013
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Tue, 23 Apr 2013 15:27:41 +0100
Subject: [RFC PATCH] drivers: bus: add ARM CCI support
In-Reply-To: <1366725128.8473.21.camel@computer5.home>
References: <1365691679-28674-1-git-send-email-lorenzo.pieralisi@arm.com>
 <1365691679-28674-2-git-send-email-lorenzo.pieralisi@arm.com>
 <1366725128.8473.21.camel@computer5.home>
Message-ID: <20130423142741.GH22946@e102568-lin.cambridge.arm.com>

On Tue, Apr 23, 2013 at 02:52:08PM +0100, Jon Medhurst (Tixy) wrote:
> On Thu, 2013-04-11 at 15:47 +0100, Lorenzo Pieralisi wrote:
> [...]
> > diff --git a/drivers/bus/arm-cci.c b/drivers/bus/arm-cci.c
> > new file mode 100644
> > index 0000000..81953de
> > --- /dev/null
> > +++ b/drivers/bus/arm-cci.c
> > @@ -0,0 +1,344 @@
> > +/*
> > + * CCI cache coherent interconnect driver
> > + *
> > + * Copyright (C) 2013 ARM Ltd.
> > + * Author: Lorenzo Pieralisi <lorenzo.pieralisi at arm.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.
> > + *
> > + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
> > + * kind, whether express or implied; without even the implied warranty
> > + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > + * GNU General Public License for more details.
> > + */
> > +
> > +#include <linux/arm-cci.h>
> > +#include <linux/device.h>
> > +#include <linux/io.h>
> > +#include <linux/module.h>
> > +#include <linux/of_address.h>
> > +#include <linux/of_device.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/slab.h>
> > +
> > +#include <asm/cacheflush.h>
> > +#include <asm/dt_affinity.h>
> > +#include <asm/outercache.h>
> > +#include <asm/smp_plat.h>
> > +
> > +#define DRIVER_NAME		"CCI"
> > +#define CCI_CTRL_STATUS		0xc
> > +
> > +#define CCI_PORT_CTRL		0x0
> > +
> > +struct cci_nb_ports {
> > +	unsigned int nb_ace;
> > +	unsigned int nb_ace_lite;
> > +};
> > +
> > +enum cci_ace_port_type {
> > +	ACE_INVALID_PORT = 0x0,
> > +	ACE_PORT,
> > +	ACE_LITE_PORT,
> > +};
> > +
> > +struct cci_ace_port {
> > +	void __iomem *base;
> > +	int type;
> > +	union {
> > +		cpumask_t match_mask;
> > +		struct device_node *np;
> > +	} match;
> > +};
> > +
> > +static struct cci_ace_port *ports;
> > +static unsigned int nb_cci_ports;
> > +
> > +static void __iomem *cci_ctrl_base;
> > +#define INVALID_PORT_IDX	-1
> > +static int cpu_port[NR_CPUS] = { [0 ... NR_CPUS-1] = INVALID_PORT_IDX };
> > +
> > +static void __init cci_ace_init_ports(void)
> > +{
> > +	bool is_ace;
> > +	int port, cpu;
> > +	/*
> > +	 * Port index look-up speeds up the function disabling ports by CPU,
> > +	 * since the logical to port index mapping is done once and does
> > +	 * not change after system boot.
> > +	 * The stashed index array is initialized for all possible CPUs
> > +	 * at probe time.
> > +	 */
> > +	for_each_possible_cpu(cpu) {
> > +		for (port = 0; port < nb_cci_ports; port++) {
> > +			is_ace = ports[port].type == ACE_PORT;
> > +			if (is_ace && cpu_isset(cpu,
> > +					 ports[port].match.match_mask)) {
> > +				cpu_port[cpu] = port;
> > +				break;
> > +			}
> > +		}
> > +		WARN(cpu_port[cpu] == INVALID_PORT_IDX, "CPU %d has an invalid"
> > +							" CCI port index\n",
> 
> I think the convention is to not split user visible messages across
> multiple source lines as this makes grepping for them difficult.

Ok, I will address this issue on the entire patch.

> 
> > +							cpu);
> > +	}
> > +}
> > +
> > +/*
> > + * cci_ace_lite_port - Function to retrieve the port index corresponding to
> > + *		       a device tree node
> > + *
> > + * @np = device tree node to match
> > + *
> > + * Return value:
> > + *	- ACE LITE port index if success
> > + *	- -EINVAL if failure
> > + *
> > + */
> > +static int cci_ace_lite_port(struct device_node *np)
> > +{
> > +	int i;
> > +	bool is_ace_lite;
> > +
> > +	for (i = 0; i < nb_cci_ports; i++) {
> > +		is_ace_lite = ports[i].type == ACE_LITE_PORT;
> > +		if (is_ace_lite && np == ports[i].match.np)
> > +			return i;
> > +	}
> > +	return -ENODEV;
> > +}
> > +
> > +/*
> > + * Functions to enable/disable a CCI interconnect slave port
> > + *
> > + * They are called by low-level power management code to disable slave
> > + * interfaces snoops and DVM broadcast.
> > + * Since they may execute with cache data allocation disabled and
> > + * after the caches have been cleaned and invalidated the functions provide
> > + * no explicit locking since they may run with D-cache disabled, so normal
> > + * cacheable kernel locks based on ldrex/strex may not work.
> > + * Locking has to be provided by BSP implementations to ensure proper
> > + * operations.
> > + */
> > +
> > +/*
> > + * cci_port_control()
> > + *	@port = index of the port to setup
> > + *	@enable = if true enables the port, if false disables it
> > + */
> > +static void notrace cci_port_control(unsigned int port, bool enable)
> > +{
> > +	void __iomem *base = ports[port].base;
> > +
> > +	if (!base)
> > +		return;
> > +
> > +	writel_relaxed(enable, base + CCI_PORT_CTRL);
> 
> If enable is bool (0 or 1) then this is going to set snoops as specified
> but is always going to clear DVM broadcast as that is controlled by bit1
> of the register. So, does the API need specifying different to allow the
> caller to choose DVM state as well, or does this function need to assume
> DVM and snoops state should be equal? I.e.
> 
> 	writel_relaxed(enable ? 0x3 : 0x0, base + CCI_PORT_CTRL);

Well spotted. I will have to think about this, but you are spot-on, the
current interface is plain wrong.

[...]

> > +ioremap_err:
> > +	for (j = 0; j < nb_cci_ports; j++) {
> > +		if (j == i)
> > +			break;
> > +		iounmap(ports[j].base);
> > +	}
> 
> That loop would be simpler as:
> 
> 	while (--i >= 0)
> 		iounmap(ports[i].base);
> 
> and declaration of 'j' can dropped from the function start.

Yes, absolutely.

> > +
> > +	iounmap(cci_ctrl_base);
> > +memalloc_err:
> > +
> > +	kfree(ports);
> > +	return ret;
> > +}
> > +
> > +static int __exit cci_driver_remove(struct platform_device *pdev)
> 
> Under what circumstances would we want to remove the driver?

Consider this function gone, so 0 circumstances.

Thanks a lot for the review,
Lorenzo



From kgene.kim at samsung.com  Tue Apr 23 10:29:32 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Tue, 23 Apr 2013 23:29:32 +0900
Subject: [PATCH v5 5/6] ARM: dts: Add basic dts include files for Samsung
 S3C64xx SoCs
In-Reply-To: <CAL_JsqL_i-5SDCsGZCrsxMehLVMGoLO1s_V3R-H6Oa5ff16dEQ@mail.gmail.com>
References: <1366060483-20342-1-git-send-email-tomasz.figa@gmail.com>	<1366060483-20342-6-git-send-email-tomasz.figa@gmail.com>	<516D4D76.2010409@gmail.com>	<1829212.6niSeTsyIU@amdc1227>
 <CAL_JsqL_i-5SDCsGZCrsxMehLVMGoLO1s_V3R-H6Oa5ff16dEQ@mail.gmail.com>
Message-ID: <51769ACC.4070706@samsung.com>

On 04/18/13 02:46, Rob Herring wrote:

>>>> +   vic0: interrupt-controller at 71200000 {
>>>
>>> These nodes should be off a "simple-bus" node.
>>
>> Hmm, is there any reason behind it?
>>
>> I thought simple bus was just a convenient helper to represent hierarchical
>> bus structures if one has a need to do so.
>
> No. The DT should reflect the bus structure of the chip. How
> accurately it is done is up to you and the information available, but
> you have to have a bus of some sort.
>
> There's obvious examples that don't follow this, but I'd like to not have more.
>
Tomasz, can you address comments?

Thanks.

- Kukjin


From kgene.kim at gmail.com  Tue Apr 23 10:33:38 2013
From: kgene.kim at gmail.com (Kukjin Kim)
Date: Tue, 23 Apr 2013 23:33:38 +0900
Subject: [PATCH v5 3/6] gpio: samsung: Skip legacy GPIO registration if
 pinctrl-s3c64xx is present
In-Reply-To: <20130417130609.GA13687@opensource.wolfsonmicro.com>
References: <1366060483-20342-1-git-send-email-tomasz.figa@gmail.com>
 <1366060483-20342-4-git-send-email-tomasz.figa@gmail.com>
 <20130416162750.GO26958@opensource.wolfsonmicro.com>
 <22399020.Z89v9QS8su@flatron>
 <20130417130609.GA13687@opensource.wolfsonmicro.com>
Message-ID: <51769BC2.9010507@gmail.com>

On 04/17/13 22:06, Mark Brown wrote:
> On Wed, Apr 17, 2013 at 12:35:58AM +0200, Tomasz Figa wrote:
>> On Tuesday 16 of April 2013 17:27:50 Mark Brown wrote:
>
>>> Strictly speaking this is a separate bug fix (though I see that's
>>> already in -next separately anyway so whatever).
>
I agree with this.

>> Right. But this fix is so small that I thought it would be a major waste
>> of mail server processing power to send it as a separate patch.
>
But the fix would be value...

> There's reviewer bandwidth too - one of the things people check for is
> that the change is doing what it's supposed to do, extra stuff in there
> is usually a red flag.

Thanks.

- Kukjin


From broonie at kernel.org  Tue Apr 23 10:42:56 2013
From: broonie at kernel.org (Mark Brown)
Date: Tue, 23 Apr 2013 15:42:56 +0100
Subject: [PATCH 2/3] spi: s3c64xx: Added provision for dedicated cs pin
In-Reply-To: <1366614565-3743-3-git-send-email-ks.giri@samsung.com>
References: <1366614565-3743-1-git-send-email-ks.giri@samsung.com>
 <1366614565-3743-3-git-send-email-ks.giri@samsung.com>
Message-ID: <20130423144256.GP5019@opensource.wolfsonmicro.com>

On Mon, Apr 22, 2013 at 12:39:24PM +0530, Girish K S wrote:
> From: Girish K S <girishks2000 at gmail.com>
> 
> The existing driver supports gpio based /cs signal.
> For controller's that have one device per controller,
> the slave device's /cs signal might be internally controlled
> by the chip select bit of slave select register. They are not
> externally asserted/deasserted using gpio pin.

This doesn't build:

drivers/spi/spi-s3c64xx.c: In function 's3c64xx_get_slave_ctrldata':
drivers/spi/spi-s3c64xx.c:1023: error: 'sdd' undeclared (first use in this function)
drivers/spi/spi-s3c64xx.c:1023: error: (Each undeclared identifier is reported only once
drivers/spi/spi-s3c64xx.c:1023: error: for each function it appears in.)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130423/ab4c606f/attachment.sig>

From vkale at apm.com  Tue Apr 23 10:43:01 2013
From: vkale at apm.com (Vinayak Kale)
Date: Tue, 23 Apr 2013 20:13:01 +0530
Subject: [PATCH V2 4/4] arm64: Add initial DTS for APM X-Gene Storm SOC
 and APM Mustang board
In-Reply-To: <5176871A.4040209@gmail.com>
References: <1366712759-3431-1-git-send-email-vkale@apm.com>
 <1366712759-3431-5-git-send-email-vkale@apm.com>
 <5176871A.4040209@gmail.com>
Message-ID: <CAPrCYkfx8CEW82SnUGLNAWKWLQHJPMOk-hYH8D+4yOyYZ29kWA@mail.gmail.com>

On Tue, Apr 23, 2013 at 6:35 PM, Rob Herring <robherring2 at gmail.com> wrote:
> On 04/23/2013 05:25 AM, Vinayak Kale wrote:
>> This patch adds initial DTS files required for APM Mustang board.
>>
>> Signed-off-by: Kumar Sankaran <ksankaran at apm.com>
>> Signed-off-by: Loc Ho <lho at apm.com>
>> Signed-off-by: Feng Kan <fkan at apm.com>
>> ---
>>  arch/arm64/boot/dts/Makefile        |    1 +
>>  arch/arm64/boot/dts/apm-mustang.dts |   27 ++++++++
>>  arch/arm64/boot/dts/apm-storm.dtsi  |  116 +++++++++++++++++++++++++++++++++++
>
> Well, you renamed the files, but did not address any of my other comments.
>
>>  3 files changed, 144 insertions(+), 0 deletions(-)
>>  create mode 100644 arch/arm64/boot/dts/apm-mustang.dts
>>  create mode 100644 arch/arm64/boot/dts/apm-storm.dtsi
>>
>> diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
>> index 68457e9..c52bdb0 100644
>> --- a/arch/arm64/boot/dts/Makefile
>> +++ b/arch/arm64/boot/dts/Makefile
>> @@ -1,4 +1,5 @@
>>  dtb-$(CONFIG_ARCH_VEXPRESS) += rtsm_ve-aemv8a.dtb foundation-v8.dtb
>> +dtb-$(CONFIG_ARCH_XGENE) += apm-mustang.dtb
>>
>>  targets += dtbs
>>  targets += $(dtb-y)
>> diff --git a/arch/arm64/boot/dts/apm-mustang.dts b/arch/arm64/boot/dts/apm-mustang.dts
>> new file mode 100644
>> index 0000000..625322c
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/apm-mustang.dts
>> @@ -0,0 +1,27 @@
>> +/*
>> + * dts file for AppliedMicro (APM) Mustang Board
>> + *
>> + * Copyright (C) 2013, Applied Micro Circuits Corporation
>> + *
>> + * 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/ "apm-storm.dtsi"
>> +
>> +/ {
>> +     model = "mustang";
>
> This should/can be a more descriptive string.
>
> You need a compatible field for the board.
>
Okay.
>> +
>> +     chosen {
>> +             linux,stdout-path = &serial0;
>
> See my prior comment.
>
>> +     };
>> +
>> +     memory {
>> +             device_type = "memory";
>> +             reg = < 0x1 0x00000000 0x0 0x80000000 >; /* Updated by bootloader */
>> +     };
>> +};
>> diff --git a/arch/arm64/boot/dts/apm-storm.dtsi b/arch/arm64/boot/dts/apm-storm.dtsi
>> new file mode 100644
>> index 0000000..d3f3f5d
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/apm-storm.dtsi
>> @@ -0,0 +1,116 @@
>> +/*
>> + * dts file for AppliedMicro (APM) X-Gene Storm SOC
>> + *
>> + * Copyright (C) 2013, Applied Micro Circuits Corporation
>> + *
>> + * 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.
>> + */
>> +
>> +/ {
>> +     compatible = "apm,xgene,storm", "apm,xgene";
>
> This still needs documentation. "apm,xgene-storm" would be more in line
> with convention. apm,xgene collides with the cpu name. Is xgene the soc
> or cpu core? Use the soc name here.
>
Potenza is the cpu name, xgene-storm being the soc. I'll change here
accordingly, also will fix the cpu name.
For devicetree bindings documentation, currently there is no directory
for arm64. We will add the documentation later along with subseqeunt
soc patches as this is intial patch-set.
> Rob
>
>> +     interrupt-parent = <&gic>;
>> +     #address-cells = <2>;
>> +     #size-cells = <2>;
>> +
>> +     cpus {
>> +             #address-cells = <2>;
>> +             #size-cells = <0>;
>> +
>> +             cpu at 000 {
>> +                     device_type = "cpu";
>> +                     compatible = "apm,xgene", "arm,armv8";
>> +                     reg = <0x0 0x000>;
>> +                     enable-method = "spin-table";
>> +                     cpu-release-addr = <0x1 0x0000fff8>;
>> +             };
>> +             cpu at 001 {
>> +                     device_type = "cpu";
>> +                     compatible = "apm,xgene", "arm,armv8";
>> +                     reg = <0x0 0x001>;
>> +                     enable-method = "spin-table";
>> +                     cpu-release-addr = <0x1 0x0000fff8>;
>> +             };
>> +             cpu at 100 {
>> +                     device_type = "cpu";
>> +                     compatible = "apm,xgene", "arm,armv8";
>> +                     reg = <0x0 0x100>;
>> +                     enable-method = "spin-table";
>> +                     cpu-release-addr = <0x1 0x0000fff8>;
>> +             };
>> +             cpu at 101 {
>> +                     device_type = "cpu";
>> +                     compatible = "apm,xgene", "arm,armv8";
>> +                     reg = <0x0 0x101>;
>> +                     enable-method = "spin-table";
>> +                     cpu-release-addr = <0x1 0x0000fff8>;
>> +             };
>> +             cpu at 200 {
>> +                     device_type = "cpu";
>> +                     compatible = "apm,xgene", "arm,armv8";
>> +                     reg = <0x0 0x200>;
>> +                     enable-method = "spin-table";
>> +                     cpu-release-addr = <0x1 0x0000fff8>;
>> +             };
>> +             cpu at 201 {
>> +                     device_type = "cpu";
>> +                     compatible = "apm,xgene", "arm,armv8";
>> +                     reg = <0x0 0x201>;
>> +                     enable-method = "spin-table";
>> +                     cpu-release-addr = <0x1 0x0000fff8>;
>> +             };
>> +             cpu at 300 {
>> +                     device_type = "cpu";
>> +                     compatible = "apm,xgene", "arm,armv8";
>> +                     reg = <0x0 0x300>;
>> +                     enable-method = "spin-table";
>> +                     cpu-release-addr = <0x1 0x0000fff8>;
>> +             };
>> +             cpu at 301 {
>> +                     device_type = "cpu";
>> +                     compatible = "apm,xgene", "arm,armv8";
>> +                     reg = <0x0 0x301>;
>> +                     enable-method = "spin-table";
>> +                     cpu-release-addr = <0x1 0x0000fff8>;
>> +             };
>> +     };
>> +
>> +     gic: interrupt-controller at 78010000 {
>> +             compatible = "arm,cortex-a15-gic", "arm,cortex-a9-gic";
>> +             #interrupt-cells = <3>;
>> +             interrupt-controller;
>> +             reg = <0x0 0x78010000 0x0 0x1000>,      /* GIC Dist */
>> +                   <0x0 0x78020000 0x0 0x1000>,      /* GIC CPU */
>> +                   <0x0 0x78040000 0x0 0x2000>,      /* GIC VCPU Control */
>> +                   <0x0 0x78060000 0x0 0x2000>;      /* GIC VCPU */
>> +             interrupts = <1 9 0xf04>;       /* GIC Maintenence IRQ */
>> +     };
>> +
>> +     timer {
>> +             compatible = "arm,armv8-timer";
>> +             interrupts = <1 0 0xff01>,      /* Secure Phys IRQ */
>> +                          <1 13 0xff01>,     /* Non-secure Phys IRQ */
>> +                          <1 14 0xff01>,     /* Virt IRQ */
>> +                          <1 15 0xff01>;     /* Hyp IRQ */
>> +             clock-frequency = <50000000>;
>> +     };
>> +
>> +     soc {
>> +             compatible = "simple-bus";
>> +             #address-cells = <2>;
>> +             #size-cells = <2>;
>> +             ranges;
>> +
>> +             serial0: serial at 1c020000 {
>> +                     device_type = "serial";
>> +                     compatible = "ns16550";
>> +                     reg = <0 0x1c020000 0x0 0x1000>;
>> +                     reg-shift = <2>;
>> +                     clock-frequency = <10000000>; /* Updated by bootloader */
>> +                     interrupt-parent = <&gic>;
>> +                     interrupts = <0x0 0x4c 0x4>;
>> +             };
>> +     };
>> +};
>>
>

Thanks
-Vinayak


From vkale at apm.com  Tue Apr 23 10:44:14 2013
From: vkale at apm.com (Vinayak Kale)
Date: Tue, 23 Apr 2013 20:14:14 +0530
Subject: [PATCH V2 4/4] arm64: Add initial DTS for APM X-Gene Storm SOC
 and APM Mustang board
In-Reply-To: <20130423131215.GB28663@e106331-lin.cambridge.arm.com>
References: <1366712759-3431-1-git-send-email-vkale@apm.com>
 <1366712759-3431-5-git-send-email-vkale@apm.com>
 <20130423131215.GB28663@e106331-lin.cambridge.arm.com>
Message-ID: <CAPrCYketDyi+BqiSukOf55+dLNJELr+7_o3Jdj9aGsssT0QBmg@mail.gmail.com>

On Tue, Apr 23, 2013 at 6:42 PM, Mark Rutland <mark.rutland at arm.com> wrote:
> Hi,
>
> On Tue, Apr 23, 2013 at 11:25:59AM +0100, Vinayak Kale wrote:
>> This patch adds initial DTS files required for APM Mustang board.
>>
>> Signed-off-by: Kumar Sankaran <ksankaran at apm.com>
>> Signed-off-by: Loc Ho <lho at apm.com>
>> Signed-off-by: Feng Kan <fkan at apm.com>
>> ---
>>  arch/arm64/boot/dts/Makefile        |    1 +
>>  arch/arm64/boot/dts/apm-mustang.dts |   27 ++++++++
>>  arch/arm64/boot/dts/apm-storm.dtsi  |  116 +++++++++++++++++++++++++++++++++++
>>  3 files changed, 144 insertions(+), 0 deletions(-)
>>  create mode 100644 arch/arm64/boot/dts/apm-mustang.dts
>>  create mode 100644 arch/arm64/boot/dts/apm-storm.dtsi
>>
>> diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
>> index 68457e9..c52bdb0 100644
>> --- a/arch/arm64/boot/dts/Makefile
>> +++ b/arch/arm64/boot/dts/Makefile
>> @@ -1,4 +1,5 @@
>>  dtb-$(CONFIG_ARCH_VEXPRESS) += rtsm_ve-aemv8a.dtb foundation-v8.dtb
>> +dtb-$(CONFIG_ARCH_XGENE) += apm-mustang.dtb
>>
>>  targets += dtbs
>>  targets += $(dtb-y)
>> diff --git a/arch/arm64/boot/dts/apm-mustang.dts b/arch/arm64/boot/dts/apm-mustang.dts
>> new file mode 100644
>> index 0000000..625322c
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/apm-mustang.dts
>> @@ -0,0 +1,27 @@
>> +/*
>> + * dts file for AppliedMicro (APM) Mustang Board
>> + *
>> + * Copyright (C) 2013, Applied Micro Circuits Corporation
>> + *
>> + * 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/ "apm-storm.dtsi"
>> +
>> +/ {
>> +     model = "mustang";
>> +
>> +     chosen {
>> +             linux,stdout-path = &serial0;
>> +     };
>> +
>> +     memory {
>> +             device_type = "memory";
>> +             reg = < 0x1 0x00000000 0x0 0x80000000 >; /* Updated by bootloader */
>> +     };
>> +};
>> diff --git a/arch/arm64/boot/dts/apm-storm.dtsi b/arch/arm64/boot/dts/apm-storm.dtsi
>> new file mode 100644
>> index 0000000..d3f3f5d
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/apm-storm.dtsi
>> @@ -0,0 +1,116 @@
>> +/*
>> + * dts file for AppliedMicro (APM) X-Gene Storm SOC
>> + *
>> + * Copyright (C) 2013, Applied Micro Circuits Corporation
>> + *
>> + * 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.
>> + */
>> +
>> +/ {
>> +     compatible = "apm,xgene,storm", "apm,xgene";
>> +     interrupt-parent = <&gic>;
>> +     #address-cells = <2>;
>> +     #size-cells = <2>;
>> +
>> +     cpus {
>> +             #address-cells = <2>;
>> +             #size-cells = <0>;
>> +
>> +             cpu at 000 {
>> +                     device_type = "cpu";
>> +                     compatible = "apm,xgene", "arm,armv8";
>
> You've used the "apm,xgene" compatible string for both the CPU and the board.
>
> In PATCH 3, you added APM_CPU_PART_POTENZA, so presumably "apm,potenza" makes
> more sense as the CPU compatible string?
>
Yes, will fix this. Thanks
> Thanks,
> Mark.

Thanks
-Vinayak


From t.figa at samsung.com  Tue Apr 23 10:44:10 2013
From: t.figa at samsung.com (Tomasz Figa)
Date: Tue, 23 Apr 2013 16:44:10 +0200
Subject: [PATCH v5 5/6] ARM: dts: Add basic dts include files for Samsung
 S3C64xx SoCs
In-Reply-To: <51769ACC.4070706@samsung.com>
References: <1366060483-20342-1-git-send-email-tomasz.figa@gmail.com>
 <CAL_JsqL_i-5SDCsGZCrsxMehLVMGoLO1s_V3R-H6Oa5ff16dEQ@mail.gmail.com>
 <51769ACC.4070706@samsung.com>
Message-ID: <3174365.tBvafCFyal@amdc1227>

On Tuesday 23 of April 2013 23:29:32 Kukjin Kim wrote:
> On 04/18/13 02:46, Rob Herring wrote:
> >>>> +   vic0: interrupt-controller at 71200000 {
> >>> 
> >>> These nodes should be off a "simple-bus" node.
> >> 
> >> Hmm, is there any reason behind it?
> >> 
> >> I thought simple bus was just a convenient helper to represent
> >> hierarchical
> >> bus structures if one has a need to do so.
> > 
> > No. The DT should reflect the bus structure of the chip. How
> > accurately it is done is up to you and the information available, but
> > you have to have a bus of some sort.
> > 
> > There's obvious examples that don't follow this, but I'd like to not have
> > more.
> Tomasz, can you address comments?

Please discard this series for now.

I've decided to post it for 3.11, including a driver for Common Clock 
Framework and several cleanup patches, which I have ready and waiting.

Best regards,
-- 
Tomasz Figa
Samsung Poland R&D Center
SW Solution Development, Kernel and System Framework



From kgene.kim at samsung.com  Tue Apr 23 10:48:46 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Tue, 23 Apr 2013 23:48:46 +0900
Subject: [PATCH v5 5/6] ARM: dts: Add basic dts include files for Samsung
 S3C64xx SoCs
In-Reply-To: <3174365.tBvafCFyal@amdc1227>
References: <1366060483-20342-1-git-send-email-tomasz.figa@gmail.com>
 <CAL_JsqL_i-5SDCsGZCrsxMehLVMGoLO1s_V3R-H6Oa5ff16dEQ@mail.gmail.com>
 <51769ACC.4070706@samsung.com> <3174365.tBvafCFyal@amdc1227>
Message-ID: <51769F4E.3010602@samsung.com>

On 04/23/13 23:44, Tomasz Figa wrote:

>> Tomasz, can you address comments?
>
> Please discard this series for now.
>
OK.

> I've decided to post it for 3.11, including a driver for Common Clock
> Framework and several cleanup patches, which I have ready and waiting.
>
Sounds good.

Thanks.

- Kukjin


From kgene.kim at samsung.com  Tue Apr 23 11:02:29 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Wed, 24 Apr 2013 00:02:29 +0900
Subject: [PATCH v2 2/3] ARM: EXYNOS: Fix support of Exynos4210 rev0 SoC
In-Reply-To: <1696892.zdvbYPFFr0@amdc1227>
References: <1366036922-4103-1-git-send-email-t.figa@samsung.com>
 <201304222310.34775.arnd@arndb.de> <517692FD.9080005@samsung.com>
 <1696892.zdvbYPFFr0@amdc1227>
Message-ID: <5176A285.9030009@samsung.com>

On 04/23/13 23:26, Tomasz Figa wrote:
> Hi Kukjin,

[...]

>>> Acked-by: Arnd Bergmann<arnd at arndb.de>
>>>
>>> Note that it would be helpful to mention here that this is required for
>>> the calling samsung_timer_init from the exynos4-dt.c file.
>>
>> I did 'amend' as per your suggestion and added your ack on this series.
>>
>> Thanks.
>>
>> - Kukjin
>
> Since the samsung-time rework patches were replaced with a non-invasive subset
> with different semantics (going to send them in a while), this patch should be
> replaced with new version I'm going to send (in a while as well).
>
Oh, OK. You want to replace with new patches you will send. I dropped 
this series in my late dt branch.

BTW, the series should depend on your samsung-time patches, right?

One more note, this makes following build error.

arch/arm/mach-exynos/built-in.o: In function `exynos_init_time':
arch/arm/mach-exynos/common.c:424: undefined reference to 
`samsung_timer_init'
make: *** [vmlinux] Error 1

Thanks.

- Kukjin


From cdall at cs.columbia.edu  Tue Apr 23 11:02:43 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Tue, 23 Apr 2013 08:02:43 -0700
Subject: [PATCH] ARM: mm: Get rid of L_PTE_USER ref from PAGE_S2_DEVICE
In-Reply-To: <062dea0374552dcb48be3687ae95262d@localhost>
References: <1366683430-24328-1-git-send-email-cdall@cs.columbia.edu>
 <062dea0374552dcb48be3687ae95262d@localhost>
Message-ID: <CAEDV+gK9J-grV=e0OfEo-bL0UezaAwFH1p1k4YkbvOB7D2LTbw@mail.gmail.com>

On Tue, Apr 23, 2013 at 12:45 AM, Marc Zyngier <marc.zyngier at arm.com> wrote:
> On Mon, 22 Apr 2013 19:17:10 -0700, Christoffer Dall
> <cdall at cs.columbia.edu> wrote:
>> THe L_PTE_USER actually has nothing to do with stage 2 mappings and the
>> L_PTE_S2_RDONLY value sets the readable bit, which was what L_PTE_USER
>> was used for before proper handling of stage 2 memory defines.
>>
>> Signed-off-by: Christoffer Dall <cdall at cs.columbia.edu>
>> ---
>>  arch/arm/include/asm/pgtable.h |    2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/include/asm/pgtable.h
>> b/arch/arm/include/asm/pgtable.h
>> index 80d6fc4..1d1f97f 100644
>> --- a/arch/arm/include/asm/pgtable.h
>> +++ b/arch/arm/include/asm/pgtable.h
>> @@ -88,7 +88,7 @@ extern pgprot_t             pgprot_s2_device;
>>  #define PAGE_HYP             _MOD_PROT(pgprot_kernel, L_PTE_HYP)
>>  #define PAGE_HYP_DEVICE              _MOD_PROT(pgprot_hyp_device, L_PTE_HYP)
>>  #define PAGE_S2                      _MOD_PROT(pgprot_s2, L_PTE_S2_RDONLY)
>> -#define PAGE_S2_DEVICE               _MOD_PROT(pgprot_s2_device, L_PTE_USER |
>> L_PTE_S2_RDONLY)
>> +#define PAGE_S2_DEVICE               _MOD_PROT(pgprot_s2_device, L_PTE_S2_RDONLY)
>>
>>  #define __PAGE_NONE          __pgprot(_L_PTE_DEFAULT | L_PTE_RDONLY | L_PTE_XN
> |
>>  L_PTE_NONE)
>>  #define __PAGE_SHARED                __pgprot(_L_PTE_DEFAULT | L_PTE_USER | L_PTE_XN)
>
> Good catch.
>
> While we're at it, why not directly set it to be RW instead of RO? The
> only use of PAGE_S2_DEVICE immediately sets the writeable bit anyway.
>

hmm, any potential future uses of read-only device mappings? It seems
"easier" to or on write permissions than remove them, or maybe I'm
imagining things...


From lee.jones at linaro.org  Tue Apr 23 11:03:04 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Tue, 23 Apr 2013 16:03:04 +0100
Subject: [PATCH 00/10] usb: musb: ux500: pathe the way for Device Tree
 enablement
Message-ID: <1366729394-11406-1-git-send-email-lee.jones@linaro.org>

In this patch-set we firstly ease the burden on data being passed from
platform data, then start to build up support to finally enable Device
Tree.

 Documentation/devicetree/bindings/usb/ux500-usb.txt |   49 +++++++++++++++++++++++++++++++++++++++++++++++++
 arch/arm/boot/dts/dbx5x0.dtsi                       |   31 ++++++++++++++++++++++++++++++-
 arch/arm/mach-ux500/cpu-db8500.c                    |   17 ++---------------
 arch/arm/mach-ux500/usb.c                           |   25 ++++++-------------------
 drivers/usb/musb/ux500.c                            |   61 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
 drivers/usb/musb/ux500_dma.c                        |   59 +++++++++++++++++++++++++++++++++--------------------------
 include/linux/platform_data/usb-musb-ux500.h        |    5 +----
 7 files changed, 181 insertions(+), 66 deletions(-)




From lee.jones at linaro.org  Tue Apr 23 11:03:05 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Tue, 23 Apr 2013 16:03:05 +0100
Subject: [PATCH 01/10] usb: musb: ux500: move channel number knowledge into
 the driver
In-Reply-To: <1366729394-11406-1-git-send-email-lee.jones@linaro.org>
References: <1366729394-11406-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1366729394-11406-2-git-send-email-lee.jones@linaro.org>

For all ux500 based platforms the maximum number of end-points are used.
Move this knowledge into the driver so we can relinquish the burden from
platform data. This also removes quite a bit of complexity from the driver
and will aid us when we come to enable the driver for Device Tree.

Cc: Felipe Balbi <balbi at ti.com>
Cc: linux-usb at vger.kernel.org
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/mach-ux500/usb.c                    |   14 ++++++------
 drivers/usb/musb/ux500_dma.c                 |   30 ++++++++------------------
 include/linux/platform_data/usb-musb-ux500.h |    5 +----
 3 files changed, 16 insertions(+), 33 deletions(-)

diff --git a/arch/arm/mach-ux500/usb.c b/arch/arm/mach-ux500/usb.c
index 821703d..8aff9a4 100644
--- a/arch/arm/mach-ux500/usb.c
+++ b/arch/arm/mach-ux500/usb.c
@@ -22,7 +22,7 @@
 		.dir = STEDMA40_MEM_TO_PERIPH, \
 	}
 
-static struct stedma40_chan_cfg musb_dma_rx_ch[UX500_MUSB_DMA_NUM_RX_CHANNELS]
+static struct stedma40_chan_cfg musb_dma_rx_ch[UX500_MUSB_DMA_NUM_RX_TX_CHANNELS]
 	= {
 	MUSB_DMA40_RX_CH,
 	MUSB_DMA40_RX_CH,
@@ -34,7 +34,7 @@ static struct stedma40_chan_cfg musb_dma_rx_ch[UX500_MUSB_DMA_NUM_RX_CHANNELS]
 	MUSB_DMA40_RX_CH
 };
 
-static struct stedma40_chan_cfg musb_dma_tx_ch[UX500_MUSB_DMA_NUM_TX_CHANNELS]
+static struct stedma40_chan_cfg musb_dma_tx_ch[UX500_MUSB_DMA_NUM_RX_TX_CHANNELS]
 	= {
 	MUSB_DMA40_TX_CH,
 	MUSB_DMA40_TX_CH,
@@ -46,7 +46,7 @@ static struct stedma40_chan_cfg musb_dma_tx_ch[UX500_MUSB_DMA_NUM_TX_CHANNELS]
 	MUSB_DMA40_TX_CH,
 };
 
-static void *ux500_dma_rx_param_array[UX500_MUSB_DMA_NUM_RX_CHANNELS] = {
+static void *ux500_dma_rx_param_array[UX500_MUSB_DMA_NUM_RX_TX_CHANNELS] = {
 	&musb_dma_rx_ch[0],
 	&musb_dma_rx_ch[1],
 	&musb_dma_rx_ch[2],
@@ -57,7 +57,7 @@ static void *ux500_dma_rx_param_array[UX500_MUSB_DMA_NUM_RX_CHANNELS] = {
 	&musb_dma_rx_ch[7]
 };
 
-static void *ux500_dma_tx_param_array[UX500_MUSB_DMA_NUM_TX_CHANNELS] = {
+static void *ux500_dma_tx_param_array[UX500_MUSB_DMA_NUM_RX_TX_CHANNELS] = {
 	&musb_dma_tx_ch[0],
 	&musb_dma_tx_ch[1],
 	&musb_dma_tx_ch[2],
@@ -71,8 +71,6 @@ static void *ux500_dma_tx_param_array[UX500_MUSB_DMA_NUM_TX_CHANNELS] = {
 static struct ux500_musb_board_data musb_board_data = {
 	.dma_rx_param_array = ux500_dma_rx_param_array,
 	.dma_tx_param_array = ux500_dma_tx_param_array,
-	.num_rx_channels = UX500_MUSB_DMA_NUM_RX_CHANNELS,
-	.num_tx_channels = UX500_MUSB_DMA_NUM_TX_CHANNELS,
 	.dma_filter = stedma40_filter,
 };
 
@@ -119,7 +117,7 @@ static inline void ux500_usb_dma_update_rx_ch_config(int *dev_type)
 {
 	u32 idx;
 
-	for (idx = 0; idx < UX500_MUSB_DMA_NUM_RX_CHANNELS; idx++)
+	for (idx = 0; idx < UX500_MUSB_DMA_NUM_RX_TX_CHANNELS; idx++)
 		musb_dma_rx_ch[idx].dev_type = dev_type[idx];
 }
 
@@ -127,7 +125,7 @@ static inline void ux500_usb_dma_update_tx_ch_config(int *dev_type)
 {
 	u32 idx;
 
-	for (idx = 0; idx < UX500_MUSB_DMA_NUM_TX_CHANNELS; idx++)
+	for (idx = 0; idx < UX500_MUSB_DMA_NUM_RX_TX_CHANNELS; idx++)
 		musb_dma_tx_ch[idx].dev_type = dev_type[idx];
 }
 
diff --git a/drivers/usb/musb/ux500_dma.c b/drivers/usb/musb/ux500_dma.c
index 039e567d..c75e07a 100644
--- a/drivers/usb/musb/ux500_dma.c
+++ b/drivers/usb/musb/ux500_dma.c
@@ -47,10 +47,8 @@ struct ux500_dma_channel {
 
 struct ux500_dma_controller {
 	struct dma_controller controller;
-	struct ux500_dma_channel rx_channel[UX500_MUSB_DMA_NUM_RX_CHANNELS];
-	struct ux500_dma_channel tx_channel[UX500_MUSB_DMA_NUM_TX_CHANNELS];
-	u32	num_rx_channels;
-	u32	num_tx_channels;
+	struct ux500_dma_channel rx_channel[UX500_MUSB_DMA_NUM_RX_TX_CHANNELS];
+	struct ux500_dma_channel tx_channel[UX500_MUSB_DMA_NUM_RX_TX_CHANNELS];
 	void *private_data;
 	dma_addr_t phy_base;
 };
@@ -142,19 +140,15 @@ static struct dma_channel *ux500_dma_channel_allocate(struct dma_controller *c,
 	struct ux500_dma_channel *ux500_channel = NULL;
 	struct musb *musb = controller->private_data;
 	u8 ch_num = hw_ep->epnum - 1;
-	u32 max_ch;
 
-	/* Max 8 DMA channels (0 - 7). Each DMA channel can only be allocated
+	/* 8 DMA channels (0 - 7). Each DMA channel can only be allocated
 	 * to specified hw_ep. For example DMA channel 0 can only be allocated
 	 * to hw_ep 1 and 9.
 	 */
 	if (ch_num > 7)
 		ch_num -= 8;
 
-	max_ch = is_tx ? controller->num_tx_channels :
-			controller->num_rx_channels;
-
-	if (ch_num >= max_ch)
+	if (ch_num >= UX500_MUSB_DMA_NUM_RX_TX_CHANNELS)
 		return NULL;
 
 	ux500_channel = is_tx ? &(controller->tx_channel[ch_num]) :
@@ -262,7 +256,7 @@ static int ux500_dma_controller_stop(struct dma_controller *c)
 	struct dma_channel *channel;
 	u8 ch_num;
 
-	for (ch_num = 0; ch_num < controller->num_rx_channels; ch_num++) {
+	for (ch_num = 0; ch_num < UX500_MUSB_DMA_NUM_RX_TX_CHANNELS; ch_num++) {
 		channel = &controller->rx_channel[ch_num].channel;
 		ux500_channel = channel->private_data;
 
@@ -272,7 +266,7 @@ static int ux500_dma_controller_stop(struct dma_controller *c)
 			dma_release_channel(ux500_channel->dma_chan);
 	}
 
-	for (ch_num = 0; ch_num < controller->num_tx_channels; ch_num++) {
+	for (ch_num = 0; ch_num < UX500_MUSB_DMA_NUM_RX_TX_CHANNELS; ch_num++) {
 		channel = &controller->tx_channel[ch_num].channel;
 		ux500_channel = channel->private_data;
 
@@ -301,26 +295,21 @@ static int ux500_dma_controller_start(struct dma_controller *c)
 
 	void **param_array;
 	struct ux500_dma_channel *channel_array;
-	u32 ch_count;
 	dma_cap_mask_t mask;
 
-	if ((data->num_rx_channels > UX500_MUSB_DMA_NUM_RX_CHANNELS) ||
-		(data->num_tx_channels > UX500_MUSB_DMA_NUM_TX_CHANNELS))
-		return -EINVAL;
 
-	controller->num_rx_channels = data->num_rx_channels;
-	controller->num_tx_channels = data->num_tx_channels;
 
 	dma_cap_zero(mask);
 	dma_cap_set(DMA_SLAVE, mask);
 
 	/* Prepare the loop for RX channels */
 	channel_array = controller->rx_channel;
-	ch_count = data->num_rx_channels;
 	param_array = data->dma_rx_param_array;
 
 	for (dir = 0; dir < 2; dir++) {
-		for (ch_num = 0; ch_num < ch_count; ch_num++) {
+		for (ch_num = 0;
+		     ch_num < UX500_MUSB_DMA_NUM_RX_TX_CHANNELS;
+		     ch_num++) {
 			ux500_channel = &channel_array[ch_num];
 			ux500_channel->controller = controller;
 			ux500_channel->ch_num = ch_num;
@@ -348,7 +337,6 @@ static int ux500_dma_controller_start(struct dma_controller *c)
 
 		/* Prepare the loop for TX channels */
 		channel_array = controller->tx_channel;
-		ch_count = data->num_tx_channels;
 		param_array = data->dma_tx_param_array;
 		is_tx = 1;
 	}
diff --git a/include/linux/platform_data/usb-musb-ux500.h b/include/linux/platform_data/usb-musb-ux500.h
index 4c1cc50..dd9c83a 100644
--- a/include/linux/platform_data/usb-musb-ux500.h
+++ b/include/linux/platform_data/usb-musb-ux500.h
@@ -9,14 +9,11 @@
 
 #include <linux/dmaengine.h>
 
-#define UX500_MUSB_DMA_NUM_RX_CHANNELS 8
-#define UX500_MUSB_DMA_NUM_TX_CHANNELS 8
+#define UX500_MUSB_DMA_NUM_RX_TX_CHANNELS 8
 
 struct ux500_musb_board_data {
 	void	**dma_rx_param_array;
 	void	**dma_tx_param_array;
-	u32	num_rx_channels;
-	u32	num_tx_channels;
 	bool (*dma_filter)(struct dma_chan *chan, void *filter_param);
 };
 
-- 
1.7.10.4



From lee.jones at linaro.org  Tue Apr 23 11:03:06 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Tue, 23 Apr 2013 16:03:06 +0100
Subject: [PATCH 02/10] usb: musb: ux500: move the MUSB HDRC configuration into
 the driver
In-Reply-To: <1366729394-11406-1-git-send-email-lee.jones@linaro.org>
References: <1366729394-11406-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1366729394-11406-3-git-send-email-lee.jones@linaro.org>

The MUSB HDRC configuration never changes between each of the ux500
supported platforms, so there's little point passing it though platform
data. If we set it in the driver instead, we can make good use of it
when booting with either ATAGs or Device Tree.

Cc: Felipe Balbi <balbi at ti.com>
Cc: linux-usb at vger.kernel.org
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/mach-ux500/usb.c |    8 --------
 drivers/usb/musb/ux500.c  |    8 ++++++++
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/arch/arm/mach-ux500/usb.c b/arch/arm/mach-ux500/usb.c
index 8aff9a4..4f68a9c 100644
--- a/arch/arm/mach-ux500/usb.c
+++ b/arch/arm/mach-ux500/usb.c
@@ -76,16 +76,8 @@ static struct ux500_musb_board_data musb_board_data = {
 
 static u64 ux500_musb_dmamask = DMA_BIT_MASK(32);
 
-static struct musb_hdrc_config musb_hdrc_config = {
-	.multipoint	= true,
-	.dyn_fifo	= true,
-	.num_eps	= 16,
-	.ram_bits	= 16,
-};
-
 static struct musb_hdrc_platform_data musb_platform_data = {
 	.mode = MUSB_OTG,
-	.config = &musb_hdrc_config,
 	.board_data = &musb_board_data,
 };
 
diff --git a/drivers/usb/musb/ux500.c b/drivers/usb/musb/ux500.c
index 13a3929..4a8f5c9 100644
--- a/drivers/usb/musb/ux500.c
+++ b/drivers/usb/musb/ux500.c
@@ -29,6 +29,13 @@
 
 #include "musb_core.h"
 
+static struct musb_hdrc_config ux500_musb_hdrc_config = {
+	.multipoint	= true,
+	.dyn_fifo	= true,
+	.num_eps	= 16,
+	.ram_bits	= 16,
+};
+
 struct ux500_glue {
 	struct device		*dev;
 	struct platform_device	*musb;
@@ -123,6 +130,7 @@ static int ux500_probe(struct platform_device *pdev)
 	glue->clk			= clk;
 
 	pdata->platform_ops		= &ux500_ops;
+	pdata->config 			= &ux500_musb_hdrc_config;
 
 	platform_set_drvdata(pdev, glue);
 
-- 
1.7.10.4



From lee.jones at linaro.org  Tue Apr 23 11:03:08 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Tue, 23 Apr 2013 16:03:08 +0100
Subject: [PATCH 04/10] usb: musb: ux500: harden checks for platform data
In-Reply-To: <1366729394-11406-1-git-send-email-lee.jones@linaro.org>
References: <1366729394-11406-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1366729394-11406-5-git-send-email-lee.jones@linaro.org>

In its current state, the ux500-musb driver uses platform data pointers
blindly with no prior checking. If no platform data pointer is passed
this will Oops the kernel. In this patch we ensure platform data and
board data are present prior to using them.

Cc: Felipe Balbi <balbi at ti.com>
Cc: linux-usb at vger.kernel.org
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 drivers/usb/musb/ux500_dma.c |   11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/musb/ux500_dma.c b/drivers/usb/musb/ux500_dma.c
index c75e07a..02b4a6e 100644
--- a/drivers/usb/musb/ux500_dma.c
+++ b/drivers/usb/musb/ux500_dma.c
@@ -287,7 +287,7 @@ static int ux500_dma_controller_start(struct dma_controller *c)
 	struct musb *musb = controller->private_data;
 	struct device *dev = musb->controller;
 	struct musb_hdrc_platform_data *plat = dev->platform_data;
-	struct ux500_musb_board_data *data = plat->board_data;
+	struct ux500_musb_board_data *data;
 	struct dma_channel *dma_channel = NULL;
 	u32 ch_num;
 	u8 dir;
@@ -297,14 +297,19 @@ static int ux500_dma_controller_start(struct dma_controller *c)
 	struct ux500_dma_channel *channel_array;
 	dma_cap_mask_t mask;
 
+	if (!plat) {
+		dev_err(musb->controller, "No platform data\n");
+		return -EINVAL;
+	}
 
+	data = plat->board_data;
 
 	dma_cap_zero(mask);
 	dma_cap_set(DMA_SLAVE, mask);
 
 	/* Prepare the loop for RX channels */
 	channel_array = controller->rx_channel;
-	param_array = data->dma_rx_param_array;
+	param_array = (data) ? data->dma_rx_param_array : NULL;
 
 	for (dir = 0; dir < 2; dir++) {
 		for (ch_num = 0;
@@ -337,7 +342,7 @@ static int ux500_dma_controller_start(struct dma_controller *c)
 
 		/* Prepare the loop for TX channels */
 		channel_array = controller->tx_channel;
-		param_array = data->dma_tx_param_array;
+		param_array = (data) ? data->dma_tx_param_array : NULL;
 		is_tx = 1;
 	}
 
-- 
1.7.10.4



From lee.jones at linaro.org  Tue Apr 23 11:03:07 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Tue, 23 Apr 2013 16:03:07 +0100
Subject: [PATCH 03/10] usb: musb: ux500: take the dma_mask from
 coherent_dma_mask
In-Reply-To: <1366729394-11406-1-git-send-email-lee.jones@linaro.org>
References: <1366729394-11406-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1366729394-11406-4-git-send-email-lee.jones@linaro.org>

The dma_mask will always be the same as the coherent_dma_mask, so let's
cut down on the platform_data burden and set it as such in the driver.
This also saves us from supporting it separately when we come to enable
this driver for Device Tree.

Cc: Felipe Balbi <balbi at ti.com>
Cc: linux-usb at vger.kernel.org
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/mach-ux500/usb.c |    3 ---
 drivers/usb/musb/ux500.c  |    2 +-
 2 files changed, 1 insertion(+), 4 deletions(-)

diff --git a/arch/arm/mach-ux500/usb.c b/arch/arm/mach-ux500/usb.c
index 4f68a9c..e6c4a05 100644
--- a/arch/arm/mach-ux500/usb.c
+++ b/arch/arm/mach-ux500/usb.c
@@ -74,8 +74,6 @@ static struct ux500_musb_board_data musb_board_data = {
 	.dma_filter = stedma40_filter,
 };
 
-static u64 ux500_musb_dmamask = DMA_BIT_MASK(32);
-
 static struct musb_hdrc_platform_data musb_platform_data = {
 	.mode = MUSB_OTG,
 	.board_data = &musb_board_data,
@@ -98,7 +96,6 @@ struct platform_device ux500_musb_device = {
 	.id = 0,
 	.dev = {
 		.platform_data = &musb_platform_data,
-		.dma_mask = &ux500_musb_dmamask,
 		.coherent_dma_mask = DMA_BIT_MASK(32),
 	},
 	.num_resources = ARRAY_SIZE(usb_resources),
diff --git a/drivers/usb/musb/ux500.c b/drivers/usb/musb/ux500.c
index 4a8f5c9..7ddb132 100644
--- a/drivers/usb/musb/ux500.c
+++ b/drivers/usb/musb/ux500.c
@@ -122,7 +122,7 @@ static int ux500_probe(struct platform_device *pdev)
 	}
 
 	musb->dev.parent		= &pdev->dev;
-	musb->dev.dma_mask		= pdev->dev.dma_mask;
+	musb->dev.dma_mask		= &pdev->dev.coherent_dma_mask;
 	musb->dev.coherent_dma_mask	= pdev->dev.coherent_dma_mask;
 
 	glue->dev			= &pdev->dev;
-- 
1.7.10.4



From lee.jones at linaro.org  Tue Apr 23 11:03:09 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Tue, 23 Apr 2013 16:03:09 +0100
Subject: [PATCH 05/10] usb: musb: ux500: attempt to find channels by name
 before using pdata
In-Reply-To: <1366729394-11406-1-git-send-email-lee.jones@linaro.org>
References: <1366729394-11406-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1366729394-11406-6-git-send-email-lee.jones@linaro.org>

If we can ever get to a state where we can solely search for DMA channels
by name, this will almost completely alleviate the requirement to pass
copious amounts of information though platform data. Here we take the
first step towards this. The next step will be to enable Device Tree
complete with name<->event_line mapping.

Cc: Felipe Balbi <balbi at ti.com>
Cc: linux-usb at vger.kernel.org
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 drivers/usb/musb/ux500_dma.c |   20 +++++++++++++++++---
 1 file changed, 17 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/musb/ux500_dma.c b/drivers/usb/musb/ux500_dma.c
index 02b4a6e..6eef449 100644
--- a/drivers/usb/musb/ux500_dma.c
+++ b/drivers/usb/musb/ux500_dma.c
@@ -33,6 +33,11 @@
 #include <linux/platform_data/usb-musb-ux500.h>
 #include "musb_core.h"
 
+static const char *iep_chan_names[] = { "iep_1_9", "iep_2_10", "iep_3_11", "iep_4_12",
+					"iep_5_13", "iep_6_14", "iep_7_15", "iep_8" };
+static const char *oep_chan_names[] = { "oep_1_9", "oep_2_10", "oep_3_11", "oep_4_12",
+					"oep_5_13", "oep_6_14", "oep_7_15", "oep_8" };
+
 struct ux500_dma_channel {
 	struct dma_channel channel;
 	struct ux500_dma_controller *controller;
@@ -289,6 +294,7 @@ static int ux500_dma_controller_start(struct dma_controller *c)
 	struct musb_hdrc_platform_data *plat = dev->platform_data;
 	struct ux500_musb_board_data *data;
 	struct dma_channel *dma_channel = NULL;
+	char **chan_names;
 	u32 ch_num;
 	u8 dir;
 	u8 is_tx = 0;
@@ -310,6 +316,7 @@ static int ux500_dma_controller_start(struct dma_controller *c)
 	/* Prepare the loop for RX channels */
 	channel_array = controller->rx_channel;
 	param_array = (data) ? data->dma_rx_param_array : NULL;
+	chan_names = (char **)iep_chan_names;
 
 	for (dir = 0; dir < 2; dir++) {
 		for (ch_num = 0;
@@ -325,9 +332,15 @@ static int ux500_dma_controller_start(struct dma_controller *c)
 			dma_channel->status = MUSB_DMA_STATUS_FREE;
 			dma_channel->max_len = SZ_16M;
 
-			ux500_channel->dma_chan = dma_request_channel(mask,
-							data->dma_filter,
-							param_array[ch_num]);
+			ux500_channel->dma_chan =
+				dma_request_slave_channel(dev, chan_names[ch_num]);
+
+			if (!ux500_channel->dma_chan)
+				ux500_channel->dma_chan =
+					dma_request_channel(mask,
+							    data->dma_filter,
+							    param_array[ch_num]);
+
 			if (!ux500_channel->dma_chan) {
 				ERR("Dma pipe allocation error dir=%d ch=%d\n",
 					dir, ch_num);
@@ -343,6 +356,7 @@ static int ux500_dma_controller_start(struct dma_controller *c)
 		/* Prepare the loop for TX channels */
 		channel_array = controller->tx_channel;
 		param_array = (data) ? data->dma_tx_param_array : NULL;
+		chan_names = (char **)oep_chan_names;
 		is_tx = 1;
 	}
 
-- 
1.7.10.4



From lee.jones at linaro.org  Tue Apr 23 11:03:13 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Tue, 23 Apr 2013 16:03:13 +0100
Subject: [PATCH 09/10] ARM: ux500: Remove ux500-musb platform registation when
 booting with DT
In-Reply-To: <1366729394-11406-1-git-send-email-lee.jones@linaro.org>
References: <1366729394-11406-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1366729394-11406-10-git-send-email-lee.jones@linaro.org>

Now the ux500-musb driver has been enabled for Device Tree, there is no
requirement to register it from platform code.

Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/mach-ux500/cpu-db8500.c |    2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/arm/mach-ux500/cpu-db8500.c b/arch/arm/mach-ux500/cpu-db8500.c
index 5a6b9ae..36ef6ed 100644
--- a/arch/arm/mach-ux500/cpu-db8500.c
+++ b/arch/arm/mach-ux500/cpu-db8500.c
@@ -227,8 +227,6 @@ static struct device * __init u8500_of_init_devices(void)
 {
 	struct device *parent = db8500_soc_device_init();
 
-	db8500_add_usb(parent, usb_db8500_dma_cfg, usb_db8500_dma_cfg);
-
 	return parent;
 }
 
-- 
1.7.10.4



From lee.jones at linaro.org  Tue Apr 23 11:03:10 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Tue, 23 Apr 2013 16:03:10 +0100
Subject: [PATCH 06/10] usb: musb: ux500: add device tree probing support
In-Reply-To: <1366729394-11406-1-git-send-email-lee.jones@linaro.org>
References: <1366729394-11406-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1366729394-11406-7-git-send-email-lee.jones@linaro.org>

This patch will allow ux500-musb to be probed and configured solely from
configuration found in Device Tree.

Cc: Felipe Balbi <balbi at ti.com>
Cc: linux-usb at vger.kernel.org
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 .../devicetree/bindings/usb/ux500-usb.txt          |   49 +++++++++++++++++++
 drivers/usb/musb/ux500.c                           |   51 ++++++++++++++++++++
 2 files changed, 100 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/usb/ux500-usb.txt

diff --git a/Documentation/devicetree/bindings/usb/ux500-usb.txt b/Documentation/devicetree/bindings/usb/ux500-usb.txt
new file mode 100644
index 0000000..2844cbc
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/ux500-usb.txt
@@ -0,0 +1,49 @@
+Ux500 MUSB
+
+Required properties:
+ - compatible : Should be "stericsson,db8500-musb"
+ - reg        : Offset and length of registers
+ - interrupts : Interrupt; mode, number and trigger
+ - mode       : One of; "host", "otg", or "peripheral"
+
+Optional properties:
+ - dmas       : A list of dma channels;
+                dma-controller, event-line, fixed-channel, flags
+ - dma-names  : An ordered list of channel names affiliated to the above
+
+Example:
+
+usb_per5 at a03e0000 {
+	compatible = "stericsson,db8500-musb", "mentor,musb";
+	reg = <0xa03e0000 0x10000>;
+	interrupts = <0 23 0x4>;
+	interrupt-names = "mc";
+
+	mode = "otg";
+
+	dmas = <&dma 38 0 0x2>, /* Logical - DevToMem */
+	       <&dma 38 0 0x0>, /* Logical - MemToDev */
+	       <&dma 37 0 0x2>, /* Logical - DevToMem */
+	       <&dma 37 0 0x0>, /* Logical - MemToDev */
+	       <&dma 36 0 0x2>, /* Logical - DevToMem */
+	       <&dma 36 0 0x0>, /* Logical - MemToDev */
+	       <&dma 19 0 0x2>, /* Logical - DevToMem */
+	       <&dma 19 0 0x0>, /* Logical - MemToDev */
+	       <&dma 18 0 0x2>, /* Logical - DevToMem */
+	       <&dma 18 0 0x0>, /* Logical - MemToDev */
+	       <&dma 17 0 0x2>, /* Logical - DevToMem */
+	       <&dma 17 0 0x0>, /* Logical - MemToDev */
+	       <&dma 16 0 0x2>, /* Logical - DevToMem */
+	       <&dma 16 0 0x0>, /* Logical - MemToDev */
+	       <&dma 39 0 0x2>, /* Logical - DevToMem */
+	       <&dma 39 0 0x0>; /* Logical - MemToDev */
+
+	dma-names = "iep_1_9",  "oep_1_9",
+		    "iep_2_10", "oep_2_10",
+		    "iep_3_11", "oep_3_11",
+		    "iep_4_12", "oep_4_12",
+		    "iep_5_13", "oep_5_13",
+		    "iep_6_14", "oep_6_14",
+		    "iep_7_15", "oep_7_15",
+		    "iep_8",    "oep_8";
+};
diff --git a/drivers/usb/musb/ux500.c b/drivers/usb/musb/ux500.c
index 7ddb132..6418624 100644
--- a/drivers/usb/musb/ux500.c
+++ b/drivers/usb/musb/ux500.c
@@ -25,6 +25,7 @@
 #include <linux/clk.h>
 #include <linux/err.h>
 #include <linux/io.h>
+#include <linux/of.h>
 #include <linux/platform_device.h>
 
 #include "musb_core.h"
@@ -88,14 +89,57 @@ static const struct musb_platform_ops ux500_ops = {
 	.exit		= ux500_musb_exit,
 };
 
+static struct musb_hdrc_platform_data *
+ux500_of_probe(struct platform_device *pdev, struct device_node *np)
+{
+	struct musb_hdrc_platform_data *pdata;
+	const char *mode;
+	int strlen;
+
+	pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
+	if (!pdata)
+		return NULL;
+
+	mode = of_get_property(np, "mode", &strlen);
+	if (!mode) {
+		dev_err(&pdev->dev, "No 'mode' property found\n");
+		return NULL;
+	}
+
+	if (strlen > 0) {
+		if (!strcmp(mode, "host"))
+			pdata->mode = MUSB_HOST;
+		if (!strcmp(mode, "otg"))
+			pdata->mode = MUSB_OTG;
+		if (!strcmp(mode, "peripheral"))
+			pdata->mode = MUSB_PERIPHERAL;
+	}
+
+	return pdata;
+}
+
 static int ux500_probe(struct platform_device *pdev)
 {
 	struct musb_hdrc_platform_data	*pdata = pdev->dev.platform_data;
+	struct device_node		*np = pdev->dev.of_node;
 	struct platform_device		*musb;
 	struct ux500_glue		*glue;
 	struct clk			*clk;
 	int				ret = -ENOMEM;
 
+	if (!pdata) {
+		if (np) {
+			pdata = ux500_of_probe(pdev, np);
+			if (!pdata)
+				goto err0;
+
+			pdev->dev.platform_data = pdata;
+		} else {
+			dev_err(&pdev->dev, "no pdata or device tree found\n");
+			goto err0;
+		}
+	}
+
 	glue = kzalloc(sizeof(*glue), GFP_KERNEL);
 	if (!glue) {
 		dev_err(&pdev->dev, "failed to allocate glue context\n");
@@ -124,6 +168,7 @@ static int ux500_probe(struct platform_device *pdev)
 	musb->dev.parent		= &pdev->dev;
 	musb->dev.dma_mask		= &pdev->dev.coherent_dma_mask;
 	musb->dev.coherent_dma_mask	= pdev->dev.coherent_dma_mask;
+	musb->dev.of_node		= pdev->dev.of_node;
 
 	glue->dev			= &pdev->dev;
 	glue->musb			= musb;
@@ -222,12 +267,18 @@ static const struct dev_pm_ops ux500_pm_ops = {
 #define DEV_PM_OPS	NULL
 #endif
 
+static const struct of_device_id ux500_match[] = {
+        { .compatible = "stericsson,db8500-musb", },
+        {}
+};
+
 static struct platform_driver ux500_driver = {
 	.probe		= ux500_probe,
 	.remove		= ux500_remove,
 	.driver		= {
 		.name	= "musb-ux500",
 		.pm	= DEV_PM_OPS,
+		.of_match_table = ux500_match,
 	},
 };
 
-- 
1.7.10.4



From lee.jones at linaro.org  Tue Apr 23 11:03:11 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Tue, 23 Apr 2013 16:03:11 +0100
Subject: [PATCH 07/10] ARM: ux500: Add an auxdata entry for MUSB for
 clock-name look-up
In-Reply-To: <1366729394-11406-1-git-send-email-lee.jones@linaro.org>
References: <1366729394-11406-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1366729394-11406-8-git-send-email-lee.jones@linaro.org>

The recently DT:ed MUSB driver will require clock-name by device-name
look-up capability, until common clk has is properly supported by the
ux500 platform.

Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/mach-ux500/cpu-db8500.c |    1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-ux500/cpu-db8500.c b/arch/arm/mach-ux500/cpu-db8500.c
index 3276472..5a6b9ae 100644
--- a/arch/arm/mach-ux500/cpu-db8500.c
+++ b/arch/arm/mach-ux500/cpu-db8500.c
@@ -259,6 +259,7 @@ static struct of_dev_auxdata u8500_auxdata_lookup[] __initdata = {
 	OF_DEV_AUXDATA("st,nomadik-i2c", 0x80128000, "nmk-i2c.2", NULL),
 	OF_DEV_AUXDATA("st,nomadik-i2c", 0x80110000, "nmk-i2c.3", NULL),
 	OF_DEV_AUXDATA("st,nomadik-i2c", 0x8012a000, "nmk-i2c.4", NULL),
+	OF_DEV_AUXDATA("stericsson,db8500-musb", 0xa03e0000, "musb-ux500.0", NULL),
 	OF_DEV_AUXDATA("stericsson,db8500-prcmu", 0x80157000, "db8500-prcmu",
 			&db8500_prcmu_pdata),
 	/* Requires device name bindings. */
-- 
1.7.10.4



From lee.jones at linaro.org  Tue Apr 23 11:03:12 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Tue, 23 Apr 2013 16:03:12 +0100
Subject: [PATCH 08/10] ARM: ux500: Populate the ux500-musb Device Tree entry
In-Reply-To: <1366729394-11406-1-git-send-email-lee.jones@linaro.org>
References: <1366729394-11406-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1366729394-11406-9-git-send-email-lee.jones@linaro.org>

This patch provides all the information to successfully probe() and
correctly configure the ux500-musb device driver for DMA.

Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/boot/dts/dbx5x0.dtsi |   31 ++++++++++++++++++++++++++++++-
 1 file changed, 30 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/dbx5x0.dtsi b/arch/arm/boot/dts/dbx5x0.dtsi
index 86b35a1..f4f371f 100644
--- a/arch/arm/boot/dts/dbx5x0.dtsi
+++ b/arch/arm/boot/dts/dbx5x0.dtsi
@@ -175,11 +175,40 @@
 			prcm = <&prcmu>;
 		};
 
-		usb at a03e0000 {
+		usb_per5 at a03e0000 {
 			compatible = "stericsson,db8500-musb",
 				"mentor,musb";
 			reg = <0xa03e0000 0x10000>;
 			interrupts = <0 23 0x4>;
+			interrupt-names = "mc";
+
+			mode = "otg";
+
+			dmas = <&dma 38 0 0x2>, /* Logical - DevToMem */
+			       <&dma 38 0 0x0>, /* Logical - MemToDev */
+			       <&dma 37 0 0x2>, /* Logical - DevToMem */
+			       <&dma 37 0 0x0>, /* Logical - MemToDev */
+			       <&dma 36 0 0x2>, /* Logical - DevToMem */
+			       <&dma 36 0 0x0>, /* Logical - MemToDev */
+			       <&dma 19 0 0x2>, /* Logical - DevToMem */
+			       <&dma 19 0 0x0>, /* Logical - MemToDev */
+			       <&dma 18 0 0x2>, /* Logical - DevToMem */
+			       <&dma 18 0 0x0>, /* Logical - MemToDev */
+			       <&dma 17 0 0x2>, /* Logical - DevToMem */
+			       <&dma 17 0 0x0>, /* Logical - MemToDev */
+			       <&dma 16 0 0x2>, /* Logical - DevToMem */
+			       <&dma 16 0 0x0>, /* Logical - MemToDev */
+			       <&dma 39 0 0x2>, /* Logical - DevToMem */
+			       <&dma 39 0 0x0>; /* Logical - MemToDev */
+
+			dma-names = "iep_1_9",  "oep_1_9",
+				    "iep_2_10", "oep_2_10",
+				    "iep_3_11", "oep_3_11",
+				    "iep_4_12", "oep_4_12",
+				    "iep_5_13", "oep_5_13",
+				    "iep_6_14", "oep_6_14",
+				    "iep_7_15", "oep_7_15",
+				    "iep_8",    "oep_8";
 		};
 
 		dma: dma-controller at 801C0000 {
-- 
1.7.10.4



From lee.jones at linaro.org  Tue Apr 23 11:03:14 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Tue, 23 Apr 2013 16:03:14 +0100
Subject: [PATCH 10/10] ARM: ux500: Remove empty function
 u8500_of_init_devices()
In-Reply-To: <1366729394-11406-1-git-send-email-lee.jones@linaro.org>
References: <1366729394-11406-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1366729394-11406-11-git-send-email-lee.jones@linaro.org>

As promised, now all devices which resided in u8500_of_init_devices()
have been enabled for Device Tree, we can completely remove it.

Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/mach-ux500/cpu-db8500.c |   14 +-------------
 1 file changed, 1 insertion(+), 13 deletions(-)

diff --git a/arch/arm/mach-ux500/cpu-db8500.c b/arch/arm/mach-ux500/cpu-db8500.c
index 36ef6ed..a2c83c2 100644
--- a/arch/arm/mach-ux500/cpu-db8500.c
+++ b/arch/arm/mach-ux500/cpu-db8500.c
@@ -221,15 +221,6 @@ struct device * __init u8500_init_devices(struct ab8500_platform_data *ab8500)
 }
 
 #ifdef CONFIG_MACH_UX500_DT
-
-/* TODO: Once all pieces are DT:ed, remove completely. */
-static struct device * __init u8500_of_init_devices(void)
-{
-	struct device *parent = db8500_soc_device_init();
-
-	return parent;
-}
-
 static struct of_dev_auxdata u8500_auxdata_lookup[] __initdata = {
 	/* Requires call-back bindings. */
 	OF_DEV_AUXDATA("arm,cortex-a9-pmu", 0, "arm-pmu", &db8500_pmu_platdata),
@@ -288,7 +279,7 @@ static const struct of_device_id u8500_local_bus_nodes[] = {
 
 static void __init u8500_init_machine(void)
 {
-	struct device *parent = NULL;
+	struct device *parent = db8500_soc_device_init();
 
 	/* Pinmaps must be in place before devices register */
 	if (of_machine_is_compatible("st-ericsson,mop500"))
@@ -301,9 +292,6 @@ static void __init u8500_init_machine(void)
 	else if (of_machine_is_compatible("st-ericsson,ccu9540")) {}
 		/* TODO: Add pinmaps for ccu9540 board. */
 
-	/* TODO: Export SoC, USB, cpu-freq and DMA40 */
-	parent = u8500_of_init_devices();
-
 	/* automatically probe child nodes of db8500 device */
 	of_platform_populate(NULL, u8500_local_bus_nodes, u8500_auxdata_lookup, parent);
 }
-- 
1.7.10.4



From santosh.shilimkar at ti.com  Tue Apr 23 11:07:48 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Tue, 23 Apr 2013 20:37:48 +0530
Subject: [V3 patch 06/19] cpuidle: make a single register function for all
In-Reply-To: <5176990F.5070605@linaro.org>
References: <1365770165-27096-1-git-send-email-daniel.lezcano@linaro.org>
 <1365770165-27096-7-git-send-email-daniel.lezcano@linaro.org>
 <516FB35D.7000303@ti.com> <51769011.7030608@linaro.org>
 <51769316.9090309@ti.com> <5176990F.5070605@linaro.org>
Message-ID: <5176A3C4.2020008@ti.com>

On Tuesday 23 April 2013 07:52 PM, Daniel Lezcano wrote:
> On 04/23/2013 03:56 PM, Santosh Shilimkar wrote:
>> On Tuesday 23 April 2013 07:13 PM, Daniel Lezcano wrote:
>>> On 04/18/2013 10:48 AM, Santosh Shilimkar wrote:
>>>> On Friday 12 April 2013 06:05 PM, Daniel Lezcano wrote:
>>>>> The usual scheme to initialize a cpuidle driver on a SMP is:
>>>>>
>>>>> 	cpuidle_register_driver(drv);
>>>>> 	for_each_possible_cpu(cpu) {
>>>>> 		device = &per_cpu(cpuidle_dev, cpu);
>>>>> 		cpuidle_register_device(device);
>>>>> 	}
>>>>>
>>>> Not exactly related to $subject patch but the driver should
>>>> be registered after all devices has been registered to avoid
>>>> devices start using the idle state data as soon as it is
>>>> registered. In multi CPU system, this race can easily happen.
>>>
>>> Could you elaborate what problems the system will be facing if a cpu
>>> starts using the idle state data as soon as it is registered ?
>>>
>>> Is there a bug related to this ?
>>>
>> Ofcouse. In multi-CPU scenario, where CPU C-states needs co-ordination
>> can just lead into unknown issues if all the CPUs are not already part
>> registered.
> 
> Hmm, ok. I don't see a scenario, with the current code, where that could
> occurs. The coupled idle state will wait for the other cpus to enter
> idle before initiating a shutdown sequence and, so far, the other sync
> algorithm (last man standing) are doing the same.
> 
Its no just couple idle state usages. CPUs do share power domains, clock
domains, clocks etc. One CPU going ahead and tampering/progarmming
the low power states till the next one isn't registered yet
can lead to issues.

> There are some systems with 1024 cpus, and I did not heard problems like
> this.
> 
That is because todays CPUIDLe core code doesn't let that happen. Once
you fix the ordering issue, there is window where the issue could happen.

> Do you know a system where this problem occurred ? Or is it something
> you suspect that can happen ?
> 
See above. Its more prone to issues true for systems with higher
number of CPUs. Not sure if that was the reason the core code, doesn't
proceed without all the devices are registered ?

> That would be interesting to have a system where this race occurs in
> order to check the modifications will solve the issue.
> 
I haven't see the issue myself but logically it could easily happen
once the core code is fixed.

>>>> Current CPUIDLE core layer is also written with the assumption
>>>> that driver will be registered first and then the devices which
>>>> is not mandatory as per typical drive/device model.
>>>
>>> Yes, that's true. The framework assumes cpuidle_register_driver is
>>> called before cpuidle_register_device.
>>>
>>>> May be you can fix that part while you are creating this common
>>>> wrapper.
>>>
>>> Personally, as that will modify the cpuidle core layer and the changes
>>> are not obvious (because of the design of the code) I prefer to do that
>>> in a separate patchset if it is worth to do it - if there is a bug
>>> related to it, then there is no discussion, we have to do it :)
>>>
>> Sure. It would have been nice if you would have clarified that before
>> posting the next version.
>>
>> You still need to fix the kernel doc in your v4 though.
> 
> Which one ? "s/accross/across" ?
> 
s/*/** below hunk in v4

+/*
+ * cpuidle_unregister: unregister a driver and the devices. This function
+ * can be used only if the driver has been previously registered through
+ * the cpuidle_register function.
+ *
+ * @drv: a valid pointer to a struct cpuidle_driver
+ */
+void cpuidle_unregister(struct cpuidle_driver *drv)
+{
+	int cpu;
+	struct cpuidle_device *device;



From kishon at ti.com  Tue Apr 23 11:10:19 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Tue, 23 Apr 2013 20:40:19 +0530
Subject: Multiple issues with omap4 panda es in linux next
In-Reply-To: <20130422180316.GA10155@atomide.com>
References: <20130419171318.GK10155@atomide.com> <5174F7A8.7070308@ti.com>
 <20130422180316.GA10155@atomide.com>
Message-ID: <5176A45B.5@ti.com>

Hi Tony,

On Monday 22 April 2013 11:33 PM, Tony Lindgren wrote:
> * Kishon Vijay Abraham I <kishon at ti.com> [130422 01:46]:
>> Hi,
>>
>> On Friday 19 April 2013 10:43 PM, Tony Lindgren wrote:
>>> Hi all,
>>>
>>> Here's a list of breakage I've noticed so far while trying to
>>> use linux next on my pandaboard es. Probably similar issues exist
>>> on other boards as well.
>>>
>>> Ideally we would not have any breakage by the merge window, so
>>> let's try to get these fixed ASAP:
>>>
>>> 1. Serial console broken on panda es booting with DT
>>>
>>> The symptoms are dmesg output stopping after few lines
>>> and only continuing after pressing a key. Does not seem to
>>> happen on blaze with DT for some reason. And does not happen
>>> on panda es with legacy booting.
>>>
>>> 2. MUSB fails with legacy booting and DT on panda es
>>>
>>> With both legacy and DT booting I get something like:
>>>
>>> HS USB OTG: no transceiver configured
>>> musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with status -517
>>
>> The dt should work fine with https://patchwork.kernel.org/patch/2423061/.
>
> OK thanks for checking that.
>
>> But non-dt has got a real issue. We were using usb_bind_phy() for
>> binding the controller with the PHY (we use device names). But in
>> linux-next the device names have changed because of using
>> PLATFORM_DEVID_AUTO. We can modify the usb_bind_phy() calls to use
>> the new device names, But I suspect the device names can change
>> again. Not sure what we can do here :-(
>
> Let's do a minimal fix for v3.10. Then we'll make omap4 DT only for
> v3.11 and that problem is solved for good.

Have posted a patch https://patchwork.kernel.org/patch/2475521/ for 
getting MUSB functional in omap4 panda.

Thanks
Kishon


From sergei.shtylyov at cogentembedded.com  Tue Apr 23 11:11:55 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Tue, 23 Apr 2013 19:11:55 +0400
Subject: [PATCH v6 0/9] Reorganize R8A7779/Marzen USB code
Message-ID: <201304231911.56202.sergei.shtylyov@cogentembedded.com>

Hello.

   Here's the set of 9 patches against the Simon Horman's 'renesas.git' repo,
'renesas-next-20130422' tag.  It was created to fix the shortcomings in the
R8A7779/Marzen USB platform code and R8A7779 USB common PHY driver, and so
spans both arch/arm/mach-shmobile/ and drivers/usb/ subtrees (some patches have
to touch both subtrees). The patches were conceived with the complete
bisectability goal in mind.

[1/9] ARM: shmobile: Marzen: move USB EHCI, OHCI, and PHY devices to R8A7779 code
[2/9] ehci-platform: add pre_setup() method to platform data
[3/9] ARM: shmobile: r8a7779: setup EHCI internal buffer
[4/9] rcar-phy: remove EHCI internal buffer setup
[5/9] ARM: shmobile: r8a7779: remove USB PHY 2nd memory resource
[6/9] rcar-phy: correct base address
[7/9] rcar-phy: add platform data
[8/9] ARM: shmobile: Marzen: pass platform data to USB PHY device
[9/9] rcar-phy: handle platform data

   Felipe, please ACK or NAK the rcar-phy patches ASAP. It's time consuming for
me to keep all these patches fresh atop of ever changing 'next' branch....

WBR, Sergei


From arnd at arndb.de  Tue Apr 23 11:14:06 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 23 Apr 2013 17:14:06 +0200
Subject: [PATCH 06/10] usb: musb: ux500: add device tree probing support
In-Reply-To: <1366729394-11406-7-git-send-email-lee.jones@linaro.org>
References: <1366729394-11406-1-git-send-email-lee.jones@linaro.org>
 <1366729394-11406-7-git-send-email-lee.jones@linaro.org>
Message-ID: <201304231714.06326.arnd@arndb.de>

On Tuesday 23 April 2013, Lee Jones wrote:
> +Required properties:
> + - compatible : Should be "stericsson,db8500-musb"
> + - reg        : Offset and length of registers
> + - interrupts : Interrupt; mode, number and trigger
> + - mode       : One of; "host", "otg", or "peripheral"

I think we don't have any precedent for this combination of "mode" property
and contents. You could either try to match ehci-omap.txt and do

 - mode : Should be "3" to represent OTG. "1" signifies HOST and "2"
   represents PERIPHERAL.

Or you match fsl-usb.txt and nvidia,tegra20-ehci.txt, defining

 - dr_mode : dual role mode. Indicates the working mode to
   controllers.  Can be "host", "peripheral", or "otg".  Default to
   "host" if not defined for backward compatibility.

> +Optional properties:
> + - dmas       : A list of dma channels;
> +                dma-controller, event-line, fixed-channel, flags
> + - dma-names  : An ordered list of channel names affiliated to the above

Please list the exact dma-names that are required.

	Arnd


From sergei.shtylyov at cogentembedded.com  Tue Apr 23 11:14:19 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Tue, 23 Apr 2013 19:14:19 +0400
Subject: [PATCH v6 1/9] ARM: shmobile: Marzen: move USB EHCI, OHCI,
 and PHY devices to R8A7779 code
In-Reply-To: <201304200155.13492.sergei.shtylyov@cogentembedded.com>
References: <201304200155.13492.sergei.shtylyov@cogentembedded.com>
Message-ID: <201304231914.20195.sergei.shtylyov@cogentembedded.com>

USB EHCI, OHCI, and common PHY are the SoC devices but are wrongly defined and
registered in the Marzen board file.  Move the data and code to their proper
place in setup-r8a7779.c; while at it, we have to rename r8a7779_late_devices[]
to r8a7779_standard_devices[] -- this seems legitimate since they are registered
from r8a7779_add_standard_devices() anyway.

Note that I'm deliberately changing the USB PHY platform device's 'id' field
from (previously just omitted) 0 to -1 as the device is a single of its kind.

Note also that the board and SoC code have to be in one patch to keep the code
bisectable...

The patch has been tested on the Marzen board.

Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Acked-by: Simon Horman <horms+renesas at verge.net.au>

---
Changes since version 5:
- fixed typos in the changelog.

Changes since version 4:
- resolved reject in the 'board-marzen.c' file, refreshed the patch.

Changes since version 3:
- refreshed the 'board-marzen.c' file.

Changes since version 2:
- added a note about testing to the changelog;
- added ACKs from Simon Horman and Kuninori Morimoto.

Changes since the original posting:
- added a note about bisectability to the changelog.

 arch/arm/mach-shmobile/board-marzen.c         |  178 -------------------------
 arch/arm/mach-shmobile/include/mach/r8a7779.h |    1 
 arch/arm/mach-shmobile/setup-r8a7779.c        |  185 +++++++++++++++++++++++++-
 3 files changed, 184 insertions(+), 180 deletions(-)

Index: renesas/arch/arm/mach-shmobile/board-marzen.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/board-marzen.c
+++ renesas/arch/arm/mach-shmobile/board-marzen.c
@@ -37,10 +37,6 @@
 #include <linux/mmc/host.h>
 #include <linux/mmc/sh_mobile_sdhi.h>
 #include <linux/mfd/tmio.h>
-#include <linux/usb/otg.h>
-#include <linux/usb/ehci_pdriver.h>
-#include <linux/usb/ohci_pdriver.h>
-#include <linux/pm_runtime.h>
 #include <mach/hardware.h>
 #include <mach/r8a7779.h>
 #include <mach/common.h>
@@ -150,26 +146,6 @@ static struct platform_device hspi_devic
 	.num_resources	= ARRAY_SIZE(hspi_resources),
 };
 
-/* USB PHY */
-static struct resource usb_phy_resources[] = {
-	[0] = {
-		.start		= 0xffe70000,
-		.end		= 0xffe70900 - 1,
-		.flags		= IORESOURCE_MEM,
-	},
-	[1] = {
-		.start		= 0xfff70000,
-		.end		= 0xfff70900 - 1,
-		.flags		= IORESOURCE_MEM,
-	},
-};
-
-static struct platform_device usb_phy_device = {
-	.name		= "rcar_usb_phy",
-	.resource	= usb_phy_resources,
-	.num_resources	= ARRAY_SIZE(usb_phy_resources),
-};
-
 /* LEDS */
 static struct gpio_led marzen_leds[] = {
 	{
@@ -205,161 +181,9 @@ static struct platform_device *marzen_de
 	&sdhi0_device,
 	&thermal_device,
 	&hspi_device,
-	&usb_phy_device,
 	&leds_device,
 };
 
-/* USB */
-static struct usb_phy *phy;
-static int usb_power_on(struct platform_device *pdev)
-{
-	if (!phy)
-		return -EIO;
-
-	pm_runtime_enable(&pdev->dev);
-	pm_runtime_get_sync(&pdev->dev);
-
-	usb_phy_init(phy);
-
-	return 0;
-}
-
-static void usb_power_off(struct platform_device *pdev)
-{
-	if (!phy)
-		return;
-
-	usb_phy_shutdown(phy);
-
-	pm_runtime_put_sync(&pdev->dev);
-	pm_runtime_disable(&pdev->dev);
-}
-
-static struct usb_ehci_pdata ehcix_pdata = {
-	.power_on	= usb_power_on,
-	.power_off	= usb_power_off,
-	.power_suspend	= usb_power_off,
-};
-
-static struct resource ehci0_resources[] = {
-	[0] = {
-		.start	= 0xffe70000,
-		.end	= 0xffe70400 - 1,
-		.flags	= IORESOURCE_MEM,
-	},
-	[1] = {
-		.start	= gic_iid(0x4c),
-		.flags	= IORESOURCE_IRQ,
-	},
-};
-
-static struct platform_device ehci0_device = {
-	.name	= "ehci-platform",
-	.id	= 0,
-	.dev	= {
-		.dma_mask		= &ehci0_device.dev.coherent_dma_mask,
-		.coherent_dma_mask	= 0xffffffff,
-		.platform_data		= &ehcix_pdata,
-	},
-	.num_resources	= ARRAY_SIZE(ehci0_resources),
-	.resource	= ehci0_resources,
-};
-
-static struct resource ehci1_resources[] = {
-	[0] = {
-		.start	= 0xfff70000,
-		.end	= 0xfff70400 - 1,
-		.flags	= IORESOURCE_MEM,
-	},
-	[1] = {
-		.start	= gic_iid(0x4d),
-		.flags	= IORESOURCE_IRQ,
-	},
-};
-
-static struct platform_device ehci1_device = {
-	.name	= "ehci-platform",
-	.id	= 1,
-	.dev	= {
-		.dma_mask		= &ehci1_device.dev.coherent_dma_mask,
-		.coherent_dma_mask	= 0xffffffff,
-		.platform_data		= &ehcix_pdata,
-	},
-	.num_resources	= ARRAY_SIZE(ehci1_resources),
-	.resource	= ehci1_resources,
-};
-
-static struct usb_ohci_pdata ohcix_pdata = {
-	.power_on	= usb_power_on,
-	.power_off	= usb_power_off,
-	.power_suspend	= usb_power_off,
-};
-
-static struct resource ohci0_resources[] = {
-	[0] = {
-		.start	= 0xffe70400,
-		.end	= 0xffe70800 - 1,
-		.flags	= IORESOURCE_MEM,
-	},
-	[1] = {
-		.start	= gic_iid(0x4c),
-		.flags	= IORESOURCE_IRQ,
-	},
-};
-
-static struct platform_device ohci0_device = {
-	.name	= "ohci-platform",
-	.id	= 0,
-	.dev	= {
-		.dma_mask		= &ohci0_device.dev.coherent_dma_mask,
-		.coherent_dma_mask	= 0xffffffff,
-		.platform_data		= &ohcix_pdata,
-	},
-	.num_resources	= ARRAY_SIZE(ohci0_resources),
-	.resource	= ohci0_resources,
-};
-
-static struct resource ohci1_resources[] = {
-	[0] = {
-		.start	= 0xfff70400,
-		.end	= 0xfff70800 - 1,
-		.flags	= IORESOURCE_MEM,
-	},
-	[1] = {
-		.start	= gic_iid(0x4d),
-		.flags	= IORESOURCE_IRQ,
-	},
-};
-
-static struct platform_device ohci1_device = {
-	.name	= "ohci-platform",
-	.id	= 1,
-	.dev	= {
-		.dma_mask		= &ohci1_device.dev.coherent_dma_mask,
-		.coherent_dma_mask	= 0xffffffff,
-		.platform_data		= &ohcix_pdata,
-	},
-	.num_resources	= ARRAY_SIZE(ohci1_resources),
-	.resource	= ohci1_resources,
-};
-
-static struct platform_device *marzen_late_devices[] __initdata = {
-	&ehci0_device,
-	&ehci1_device,
-	&ohci0_device,
-	&ohci1_device,
-};
-
-static void __init marzen_init_late(void)
-{
-	/* get usb phy */
-	phy = usb_get_phy(USB_PHY_TYPE_USB2);
-
-	shmobile_init_late();
-	platform_add_devices(marzen_late_devices,
-			     ARRAY_SIZE(marzen_late_devices));
-}
-
 static const struct pinctrl_map marzen_pinctrl_map[] = {
 	/* HSPI0 */
 	PIN_MAP_MUX_GROUP_DEFAULT("sh-hspi.0", "pfc-r8a7779",
@@ -418,6 +242,6 @@ MACHINE_START(MARZEN, "marzen")
 	.nr_irqs	= NR_IRQS_LEGACY,
 	.init_irq	= r8a7779_init_irq,
 	.init_machine	= marzen_init,
-	.init_late	= marzen_init_late,
+	.init_late	= r8a7779_init_late,
 	.init_time	= r8a7779_earlytimer_init,
 MACHINE_END
Index: renesas/arch/arm/mach-shmobile/include/mach/r8a7779.h
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/include/mach/r8a7779.h
+++ renesas/arch/arm/mach-shmobile/include/mach/r8a7779.h
@@ -33,6 +33,7 @@ extern void r8a7779_add_early_devices(vo
 extern void r8a7779_add_standard_devices(void);
 extern void r8a7779_add_standard_devices_dt(void);
 extern void r8a7779_add_ether_device(struct sh_eth_plat_data *pdata);
+extern void r8a7779_init_late(void);
 extern void r8a7779_clock_init(void);
 extern void r8a7779_pinmux_init(void);
 extern void r8a7779_pm_init(void);
Index: renesas/arch/arm/mach-shmobile/setup-r8a7779.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/setup-r8a7779.c
+++ renesas/arch/arm/mach-shmobile/setup-r8a7779.c
@@ -32,6 +32,10 @@
 #include <linux/sh_intc.h>
 #include <linux/sh_timer.h>
 #include <linux/dma-mapping.h>
+#include <linux/usb/otg.h>
+#include <linux/usb/ehci_pdriver.h>
+#include <linux/usb/ohci_pdriver.h>
+#include <linux/pm_runtime.h>
 #include <mach/hardware.h>
 #include <mach/irqs.h>
 #include <mach/r8a7779.h>
@@ -383,6 +387,162 @@ static struct platform_device sata_devic
 	},
 };
 
+/* USB PHY */
+static struct resource usb_phy_resources[] = {
+	[0] = {
+		.start		= 0xffe70000,
+		.end		= 0xffe70900 - 1,
+		.flags		= IORESOURCE_MEM,
+	},
+	[1] = {
+		.start		= 0xfff70000,
+		.end		= 0xfff70900 - 1,
+		.flags		= IORESOURCE_MEM,
+	},
+};
+
+static struct platform_device usb_phy_device = {
+	.name		= "rcar_usb_phy",
+	.id		= -1,
+	.resource	= usb_phy_resources,
+	.num_resources	= ARRAY_SIZE(usb_phy_resources),
+};
+
+/* USB */
+static struct usb_phy *phy;
+
+static int usb_power_on(struct platform_device *pdev)
+{
+	if (!phy)
+		return -EIO;
+
+	pm_runtime_enable(&pdev->dev);
+	pm_runtime_get_sync(&pdev->dev);
+
+	usb_phy_init(phy);
+
+	return 0;
+}
+
+static void usb_power_off(struct platform_device *pdev)
+{
+	if (!phy)
+		return;
+
+	usb_phy_shutdown(phy);
+
+	pm_runtime_put_sync(&pdev->dev);
+	pm_runtime_disable(&pdev->dev);
+}
+
+static struct usb_ehci_pdata ehcix_pdata = {
+	.power_on	= usb_power_on,
+	.power_off	= usb_power_off,
+	.power_suspend	= usb_power_off,
+};
+
+static struct resource ehci0_resources[] = {
+	[0] = {
+		.start	= 0xffe70000,
+		.end	= 0xffe70400 - 1,
+		.flags	= IORESOURCE_MEM,
+	},
+	[1] = {
+		.start	= gic_iid(0x4c),
+		.flags	= IORESOURCE_IRQ,
+	},
+};
+
+static struct platform_device ehci0_device = {
+	.name	= "ehci-platform",
+	.id	= 0,
+	.dev	= {
+		.dma_mask		= &ehci0_device.dev.coherent_dma_mask,
+		.coherent_dma_mask	= 0xffffffff,
+		.platform_data		= &ehcix_pdata,
+	},
+	.num_resources	= ARRAY_SIZE(ehci0_resources),
+	.resource	= ehci0_resources,
+};
+
+static struct resource ehci1_resources[] = {
+	[0] = {
+		.start	= 0xfff70000,
+		.end	= 0xfff70400 - 1,
+		.flags	= IORESOURCE_MEM,
+	},
+	[1] = {
+		.start	= gic_iid(0x4d),
+		.flags	= IORESOURCE_IRQ,
+	},
+};
+
+static struct platform_device ehci1_device = {
+	.name	= "ehci-platform",
+	.id	= 1,
+	.dev	= {
+		.dma_mask		= &ehci1_device.dev.coherent_dma_mask,
+		.coherent_dma_mask	= 0xffffffff,
+		.platform_data		= &ehcix_pdata,
+	},
+	.num_resources	= ARRAY_SIZE(ehci1_resources),
+	.resource	= ehci1_resources,
+};
+
+static struct usb_ohci_pdata ohcix_pdata = {
+	.power_on	= usb_power_on,
+	.power_off	= usb_power_off,
+	.power_suspend	= usb_power_off,
+};
+
+static struct resource ohci0_resources[] = {
+	[0] = {
+		.start	= 0xffe70400,
+		.end	= 0xffe70800 - 1,
+		.flags	= IORESOURCE_MEM,
+	},
+	[1] = {
+		.start	= gic_iid(0x4c),
+		.flags	= IORESOURCE_IRQ,
+	},
+};
+
+static struct platform_device ohci0_device = {
+	.name	= "ohci-platform",
+	.id	= 0,
+	.dev	= {
+		.dma_mask		= &ohci0_device.dev.coherent_dma_mask,
+		.coherent_dma_mask	= 0xffffffff,
+		.platform_data		= &ohcix_pdata,
+	},
+	.num_resources	= ARRAY_SIZE(ohci0_resources),
+	.resource	= ohci0_resources,
+};
+
+static struct resource ohci1_resources[] = {
+	[0] = {
+		.start	= 0xfff70400,
+		.end	= 0xfff70800 - 1,
+		.flags	= IORESOURCE_MEM,
+	},
+	[1] = {
+		.start	= gic_iid(0x4d),
+		.flags	= IORESOURCE_IRQ,
+	},
+};
+
+static struct platform_device ohci1_device = {
+	.name	= "ohci-platform",
+	.id	= 1,
+	.dev	= {
+		.dma_mask		= &ohci1_device.dev.coherent_dma_mask,
+		.coherent_dma_mask	= 0xffffffff,
+		.platform_data		= &ohcix_pdata,
+	},
+	.num_resources	= ARRAY_SIZE(ohci1_resources),
+	.resource	= ohci1_resources,
+};
+
 /* Ether */
 static struct resource ether_resources[] = {
 	{
@@ -404,9 +564,10 @@ static struct platform_device *r8a7779_d
 	&scif5_device,
 	&tmu00_device,
 	&tmu01_device,
+	&usb_phy_device,
 };
 
-static struct platform_device *r8a7779_late_devices[] __initdata = {
+static struct platform_device *r8a7779_standard_devices[] __initdata = {
 	&i2c0_device,
 	&i2c1_device,
 	&i2c2_device,
@@ -426,8 +587,8 @@ void __init r8a7779_add_standard_devices
 
 	platform_add_devices(r8a7779_devices_dt,
 			    ARRAY_SIZE(r8a7779_devices_dt));
-	platform_add_devices(r8a7779_late_devices,
-			    ARRAY_SIZE(r8a7779_late_devices));
+	platform_add_devices(r8a7779_standard_devices,
+			    ARRAY_SIZE(r8a7779_standard_devices));
 }
 
 void __init r8a7779_add_ether_device(struct sh_eth_plat_data *pdata)
@@ -470,6 +631,23 @@ void __init r8a7779_add_early_devices(vo
 	 */
 }
 
+static struct platform_device *r8a7779_late_devices[] __initdata = {
+	&ehci0_device,
+	&ehci1_device,
+	&ohci0_device,
+	&ohci1_device,
+};
+
+void __init r8a7779_init_late(void)
+{
+	/* get USB PHY */
+	phy = usb_get_phy(USB_PHY_TYPE_USB2);
+
+	shmobile_init_late();
+	platform_add_devices(r8a7779_late_devices,
+			     ARRAY_SIZE(r8a7779_late_devices));
+}
+
 #ifdef CONFIG_USE_OF
 void __init r8a7779_init_delay(void)
 {
@@ -503,6 +681,7 @@ DT_MACHINE_START(R8A7779_DT, "Generic R8
 	.init_irq	= r8a7779_init_irq_dt,
 	.init_machine	= r8a7779_add_standard_devices_dt,
 	.init_time	= shmobile_timer_init,
+	.init_late	= r8a7779_init_late,
 	.dt_compat	= r8a7779_compat_dt,
 MACHINE_END
 #endif /* CONFIG_USE_OF */



From broonie at kernel.org  Tue Apr 23 11:15:12 2013
From: broonie at kernel.org (Mark Brown)
Date: Tue, 23 Apr 2013 16:15:12 +0100
Subject: [PATCH 1/3] spi: s3c64xx: added support for polling mode
In-Reply-To: <1366614565-3743-2-git-send-email-ks.giri@samsung.com>
References: <1366614565-3743-1-git-send-email-ks.giri@samsung.com>
 <1366614565-3743-2-git-send-email-ks.giri@samsung.com>
Message-ID: <20130423151511.GR5019@opensource.wolfsonmicro.com>

On Mon, Apr 22, 2013 at 12:39:23PM +0530, Girish K S wrote:
> From: Girish K S <girishks2000 at gmail.com>
> 
> The 64xx spi driver supports partial polling mode.
> Only the last chunk of the transfer length is transferred
> or recieved in polling mode.

This appears to have a very noticable negative impact on SPI performance
on my S3C6410 based system.  Not delved into it to test why but are you
sure it's not mistakenly selecting polling?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130423/8081cceb/attachment.sig>

From balbi at ti.com  Tue Apr 23 11:15:33 2013
From: balbi at ti.com (Felipe Balbi)
Date: Tue, 23 Apr 2013 18:15:33 +0300
Subject: [PATCH 06/10] usb: musb: ux500: add device tree probing support
In-Reply-To: <201304231714.06326.arnd@arndb.de>
References: <1366729394-11406-1-git-send-email-lee.jones@linaro.org>
 <1366729394-11406-7-git-send-email-lee.jones@linaro.org>
 <201304231714.06326.arnd@arndb.de>
Message-ID: <20130423151533.GD15177@arwen.pp.htv.fi>

On Tue, Apr 23, 2013 at 05:14:06PM +0200, Arnd Bergmann wrote:
> On Tuesday 23 April 2013, Lee Jones wrote:
> > +Required properties:
> > + - compatible : Should be "stericsson,db8500-musb"
> > + - reg        : Offset and length of registers
> > + - interrupts : Interrupt; mode, number and trigger
> > + - mode       : One of; "host", "otg", or "peripheral"
> 
> I think we don't have any precedent for this combination of "mode" property
> and contents. You could either try to match ehci-omap.txt and do

there is dr_mode which other folks are using. Let's use the same thing.

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130423/22540e2b/attachment.sig>

From lee.jones at linaro.org  Tue Apr 23 11:09:59 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Tue, 23 Apr 2013 16:09:59 +0100
Subject: [PATCH] ARM: ux500: Over-ride TCDM size when booting the DB8540
 platform
In-Reply-To: <CACRpkdYLJyvCK33pAHeOkXfBOiPJGAZ9bV+s-cJanfOXz+VTOg@mail.gmail.com>
References: <1364908916-29803-1-git-send-email-lee.jones@linaro.org>
 <1364908916-29803-5-git-send-email-lee.jones@linaro.org>
 <CACRpkdbh-DJti2ny=uBe-b_vGkQBNL=emMuZ6+_cE5jvRsA4sA@mail.gmail.com>
 <20130404073340.GA6892@gmail.com>
 <CACRpkdYLJyvCK33pAHeOkXfBOiPJGAZ9bV+s-cJanfOXz+VTOg@mail.gmail.com>
Message-ID: <20130423150959.GA17416@gmail.com>

On Tue, 23 Apr 2013, Linus Walleij wrote:

> On Thu, Apr 4, 2013 at 9:33 AM, Lee Jones <lee.jones at linaro.org> wrote:
> 
> > The PRCMU's Tightly Coupled Data Memory on the DB8540 platform is
> > 8kB larger than it's predecessor's. We need to reflect that in its
> > Device Tree. By re-specifying the address and size of the device
> > we effectively over-ride the previous values with more accurate
> > ones.
> >
> > Signed-off-by: Lee Jones <lee.jones at linaro.org>
> 
> As mentioned this patch does not apply. Some whitespace trouble.
> 
> And please squash it into the patch adding the ccu8540, 3/9.

I'm not sure what's going on with all this whitespace stuff, my branch
looks fine. Any chance I can just supply you with a branch to take
instead?

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From arnd at arndb.de  Tue Apr 23 11:16:54 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 23 Apr 2013 17:16:54 +0200
Subject: [PATCH 00/10] usb: musb: ux500: pathe the way for Device Tree
 enablement
In-Reply-To: <1366729394-11406-1-git-send-email-lee.jones@linaro.org>
References: <1366729394-11406-1-git-send-email-lee.jones@linaro.org>
Message-ID: <201304231716.54516.arnd@arndb.de>

On Tuesday 23 April 2013, Lee Jones wrote:
> In this patch-set we firstly ease the burden on data being passed from
> platform data, then start to build up support to finally enable Device
> Tree.

Very nice series!

I only have two small comments on the binding document, everything else looks
great.

Acked-by: Arnd Bergmann <arnd at arndb.de>


From sergei.shtylyov at cogentembedded.com  Tue Apr 23 11:17:47 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Tue, 23 Apr 2013 19:17:47 +0400
Subject: [PATCH v6 2/9] ehci-platform: add pre_setup() method to platform data
In-Reply-To: <201304231911.56202.sergei.shtylyov@cogentembedded.com>
References: <201304231911.56202.sergei.shtylyov@cogentembedded.com>
Message-ID: <201304231917.48349.sergei.shtylyov@cogentembedded.com>

Sometimes there is a need  to initialize some non-standard registers mapped to
the EHCI region before accessing the standard EHCI registers.  Add pre_setup()
method with 'struct usb_hcd *' parameter to be called just before ehci_setup()
to the 'ehci-platform'  driver's platform data for this purpose...

While at it, add the missing incomplete declaration of 'struct platform_device'
to <linux/usb/ehci_pdriver.h>...

The patch has been tested on the Marzen and BOCK-W boards.

Suggested-by: Alan Stern <stern at rowland.harvard.edu>
Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Acked-by: Simon Horman <horms+renesas at verge.net.au>
Acked-by: Alan Stern <stern at rowland.harvard.edu>

---
Changes since version 3:
- added ACK from Alan Stern.

Changes since version 2:
- replaced #include with incomplete declarations of 'struct platform_device' and
  'struct usb_hcd';
- added a note about testing to the changelog;
- added ACKs from Simon Horman and Kuninori Morimoto.

Changes since the original posting:
- changed init() method to pre_setup() with different parameters and call site.

 drivers/usb/host/ehci-platform.c |    6 ++++++
 include/linux/usb/ehci_pdriver.h |    4 ++++
 2 files changed, 10 insertions(+)

Index: renesas/drivers/usb/host/ehci-platform.c
===================================================================
--- renesas.orig/drivers/usb/host/ehci-platform.c
+++ renesas/drivers/usb/host/ehci-platform.c
@@ -46,6 +46,12 @@ static int ehci_platform_reset(struct us
 	ehci->big_endian_desc = pdata->big_endian_desc;
 	ehci->big_endian_mmio = pdata->big_endian_mmio;
 
+	if (pdata->pre_setup) {
+		retval = pdata->pre_setup(hcd);
+		if (retval < 0)
+			return retval;
+	}
+
 	ehci->caps = hcd->regs + pdata->caps_offset;
 	retval = ehci_setup(hcd);
 	if (retval)
Index: renesas/include/linux/usb/ehci_pdriver.h
===================================================================
--- renesas.orig/include/linux/usb/ehci_pdriver.h
+++ renesas/include/linux/usb/ehci_pdriver.h
@@ -19,6 +19,9 @@
 #ifndef __USB_CORE_EHCI_PDRIVER_H
 #define __USB_CORE_EHCI_PDRIVER_H
 
+struct platform_device;
+struct usb_hcd;
+
 /**
  * struct usb_ehci_pdata - platform_data for generic ehci driver
  *
@@ -50,6 +53,7 @@ struct usb_ehci_pdata {
 	/* Turn on only VBUS suspend power and hotplug detection,
 	 * turn off everything else */
 	void (*power_suspend)(struct platform_device *pdev);
+	int (*pre_setup)(struct usb_hcd *hcd);
 };
 
 #endif /* __USB_CORE_EHCI_PDRIVER_H */


From sergei.shtylyov at cogentembedded.com  Tue Apr 23 11:20:40 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Tue, 23 Apr 2013 19:20:40 +0400
Subject: [PATCH v6 3/9] ARM: shmobile: r8a7779: setup EHCI internal buffer
In-Reply-To: <201304231911.56202.sergei.shtylyov@cogentembedded.com>
References: <201304231911.56202.sergei.shtylyov@cogentembedded.com>
Message-ID: <201304231920.41469.sergei.shtylyov@cogentembedded.com>

Setup the EHCI internal buffer (before EHCI driver has a chance to touch the
registers) using the pre_setup() method in 'struct usb_ehci_pdata'.

The patch has been tested on the Marzen board.

Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Acked-by: Simon Horman <horms+renesas at verge.net.au>

---
Changes since version 4:
- refreshed the patch.

Changes since version 3:
- lowercased the SoC name in the subject.

Changes since version 2:
- added #include <linux/usb/hcd.h>;
- added a note about testing to the changelog;
- added ACKs from Simon Horman and Kuninori Morimoto.

Changes since the original posting:
- changed from init() platform device method to pre_setup() as per the previous
  patch.

 arch/arm/mach-shmobile/setup-r8a7779.c |   16 ++++++++++++++++
 1 file changed, 16 insertions(+)

Index: renesas/arch/arm/mach-shmobile/setup-r8a7779.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/setup-r8a7779.c
+++ renesas/arch/arm/mach-shmobile/setup-r8a7779.c
@@ -33,6 +33,7 @@
 #include <linux/sh_timer.h>
 #include <linux/dma-mapping.h>
 #include <linux/usb/otg.h>
+#include <linux/usb/hcd.h>
 #include <linux/usb/ehci_pdriver.h>
 #include <linux/usb/ohci_pdriver.h>
 #include <linux/pm_runtime.h>
@@ -435,10 +436,25 @@ static void usb_power_off(struct platfor
 	pm_runtime_disable(&pdev->dev);
 }
 
+static int ehci_init_internal_buffer(struct usb_hcd *hcd)
+{
+	/*
+	 * Below are recommended values from the datasheet;
+	 * see [USB :: Setting of EHCI Internal Buffer].
+	 */
+	/* EHCI IP internal buffer setting */
+	iowrite32(0x00ff0040, hcd->regs + 0x0094);
+	/* EHCI IP internal buffer enable */
+	iowrite32(0x00000001, hcd->regs + 0x009C);
+
+	return 0;
+}
+
 static struct usb_ehci_pdata ehcix_pdata = {
 	.power_on	= usb_power_on,
 	.power_off	= usb_power_off,
 	.power_suspend	= usb_power_off,
+	.pre_setup	= ehci_init_internal_buffer,
 };
 
 static struct resource ehci0_resources[] = {


From daniel.lezcano at linaro.org  Tue Apr 23 11:21:44 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Tue, 23 Apr 2013 17:21:44 +0200
Subject: [V3 patch 06/19] cpuidle: make a single register function for all
In-Reply-To: <5176A3C4.2020008@ti.com>
References: <1365770165-27096-1-git-send-email-daniel.lezcano@linaro.org>
 <1365770165-27096-7-git-send-email-daniel.lezcano@linaro.org>
 <516FB35D.7000303@ti.com> <51769011.7030608@linaro.org>
 <51769316.9090309@ti.com> <5176990F.5070605@linaro.org>
 <5176A3C4.2020008@ti.com>
Message-ID: <5176A708.2070506@linaro.org>

On 04/23/2013 05:07 PM, Santosh Shilimkar wrote:
> On Tuesday 23 April 2013 07:52 PM, Daniel Lezcano wrote:
>> On 04/23/2013 03:56 PM, Santosh Shilimkar wrote:
>>> On Tuesday 23 April 2013 07:13 PM, Daniel Lezcano wrote:
>>>> On 04/18/2013 10:48 AM, Santosh Shilimkar wrote:
>>>>> On Friday 12 April 2013 06:05 PM, Daniel Lezcano wrote:
>>>>>> The usual scheme to initialize a cpuidle driver on a SMP is:
>>>>>>
>>>>>> 	cpuidle_register_driver(drv);
>>>>>> 	for_each_possible_cpu(cpu) {
>>>>>> 		device = &per_cpu(cpuidle_dev, cpu);
>>>>>> 		cpuidle_register_device(device);
>>>>>> 	}
>>>>>>
>>>>> Not exactly related to $subject patch but the driver should
>>>>> be registered after all devices has been registered to avoid
>>>>> devices start using the idle state data as soon as it is
>>>>> registered. In multi CPU system, this race can easily happen.
>>>>
>>>> Could you elaborate what problems the system will be facing if a cpu
>>>> starts using the idle state data as soon as it is registered ?
>>>>
>>>> Is there a bug related to this ?
>>>>
>>> Ofcouse. In multi-CPU scenario, where CPU C-states needs co-ordination
>>> can just lead into unknown issues if all the CPUs are not already part
>>> registered.
>>
>> Hmm, ok. I don't see a scenario, with the current code, where that could
>> occurs. The coupled idle state will wait for the other cpus to enter
>> idle before initiating a shutdown sequence and, so far, the other sync
>> algorithm (last man standing) are doing the same.
>>
> Its no just couple idle state usages. CPUs do share power domains, clock
> domains, clocks etc. One CPU going ahead and tampering/progarmming
> the low power states till the next one isn't registered yet
> can lead to issues.
> 
>> There are some systems with 1024 cpus, and I did not heard problems like
>> this.
>>
> That is because todays CPUIDLe core code doesn't let that happen. Once
> you fix the ordering issue, there is window where the issue could happen.
> 
>> Do you know a system where this problem occurred ? Or is it something
>> you suspect that can happen ?
>>
> See above. Its more prone to issues true for systems with higher
> number of CPUs. Not sure if that was the reason the core code, doesn't
> proceed without all the devices are registered ?
> 
>> That would be interesting to have a system where this race occurs in
>> order to check the modifications will solve the issue.
>>
> I haven't see the issue myself but logically it could easily happen
> once the core code is fixed.
> 
>>>>> Current CPUIDLE core layer is also written with the assumption
>>>>> that driver will be registered first and then the devices which
>>>>> is not mandatory as per typical drive/device model.
>>>>
>>>> Yes, that's true. The framework assumes cpuidle_register_driver is
>>>> called before cpuidle_register_device.
>>>>
>>>>> May be you can fix that part while you are creating this common
>>>>> wrapper.
>>>>
>>>> Personally, as that will modify the cpuidle core layer and the changes
>>>> are not obvious (because of the design of the code) I prefer to do that
>>>> in a separate patchset if it is worth to do it - if there is a bug
>>>> related to it, then there is no discussion, we have to do it :)
>>>>
>>> Sure. It would have been nice if you would have clarified that before
>>> posting the next version.
>>>
>>> You still need to fix the kernel doc in your v4 though.
>>
>> Which one ? "s/accross/across" ?
>>
> s/*/** below hunk in v4
> 
> +/*
> + * cpuidle_unregister: unregister a driver and the devices. This function
> + * can be used only if the driver has been previously registered through
> + * the cpuidle_register function.
> + *
> + * @drv: a valid pointer to a struct cpuidle_driver
> + */
> +void cpuidle_unregister(struct cpuidle_driver *drv)
> +{
> +	int cpu;
> +	struct cpuidle_device *device;
> 

Ah, ok. I thought you were referring to something in 'Documentation'.

I will fix this nit.

Thanks !
  -- Daniel

-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From kgene.kim at samsung.com  Tue Apr 23 11:25:59 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Wed, 24 Apr 2013 00:25:59 +0900
Subject: [PATCH 07/18] cpufreq: s3c24xx: move cpufreq driver to
 drivers/cpufreq
In-Reply-To: <1769336.FkfMpuXqqb@vostro.rjw.lan>
References: <cover.1365079581.git.viresh.kumar@linaro.org>
 <2a5901ce31c9$95160980$bf421c80$%kim@samsung.com>
 <CAKohpokk1Q+0gRpeW=ts0a8D+rGAUpHu62X+7ejdpfom_B6FYA@mail.gmail.com>
 <1769336.FkfMpuXqqb@vostro.rjw.lan>
Message-ID: <5176A807.2090005@samsung.com>

On 04/05/13 20:36, Rafael J. Wysocki wrote:
> On Friday, April 05, 2013 12:36:34 PM Viresh Kumar wrote:
>> On 5 April 2013 12:18, Kukjin Kim<kgene.kim at samsung.com>  wrote:
>>> Basically, this moving looks good to me, but should be re-worked based on
>>> for-next of samsung tree because this touches too many samsung stuff so this
>>> should be sent to upstream via samsung tree.
>>
>> Hmm... Its already applied in Rafael's tree. But it doesn't mean that
>> it can't be
>> moved to your tree if there is a issue.
>
> Well, I'm dropping it.  Please merge via the Samsung tree.
>

Oops, I missed, maybe I have no more chance to send this to upstream for 
upcoming merge window :-(

Rafael, please take this patch with my ack in your tree, sorry for noise.

Acked-by: Kukjin Kim <kgene.kim at samsung.com>

If any problems, please kindly let me know.

Thanks.

- Kukjin


From arnd at arndb.de  Tue Apr 23 11:27:10 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 23 Apr 2013 17:27:10 +0200
Subject: [PATCH 06/10] usb: musb: ux500: add device tree probing support
In-Reply-To: <20130423151533.GD15177@arwen.pp.htv.fi>
References: <1366729394-11406-1-git-send-email-lee.jones@linaro.org>
 <201304231714.06326.arnd@arndb.de> <20130423151533.GD15177@arwen.pp.htv.fi>
Message-ID: <201304231727.10696.arnd@arndb.de>

On Tuesday 23 April 2013, Felipe Balbi wrote:
> On Tue, Apr 23, 2013 at 05:14:06PM +0200, Arnd Bergmann wrote:
> > On Tuesday 23 April 2013, Lee Jones wrote:
> > > +Required properties:
> > > + - compatible : Should be "stericsson,db8500-musb"
> > > + - reg        : Offset and length of registers
> > > + - interrupts : Interrupt; mode, number and trigger
> > > + - mode       : One of; "host", "otg", or "peripheral"
> > 
> > I think we don't have any precedent for this combination of "mode" property
> > and contents. You could either try to match ehci-omap.txt and do
> 
> there is dr_mode which other folks are using. Let's use the same thing.

On that topic, should we support the same property in am35x.c and 
musbhsdma.c? They currently use an integer rather than a string.

	Arnd


From sergei.shtylyov at cogentembedded.com  Tue Apr 23 11:26:53 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Tue, 23 Apr 2013 19:26:53 +0400
Subject: [PATCH v6 5/9] ARM: shmobile: r8a7779: remove USB PHY 2nd memory
 resource
In-Reply-To: <201304231911.56202.sergei.shtylyov@cogentembedded.com>
References: <201304231911.56202.sergei.shtylyov@cogentembedded.com>
Message-ID: <201304231926.53887.sergei.shtylyov@cogentembedded.com>

Now that 'drivers/usb/phy/rcar-phy.c' doesn't require the second memory resource
anymore, we can remove it from the R8A7779's USB PHY platform device.

Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Acked-by: Simon Horman <horms+renesas at verge.net.au>

---
Changes since version 4:
- refreshed the patch.

Changes since version 3:
- lowercased the SoC name in the subject.

Changes since version 2:
- refreshed atop of the prior patches;
- added a note about testing to the changelog;
- added ACKs from Simon Horman and Kuninori Morimoto.

Changes since the original posting:
- new patch in this version, split from the previous one.

 arch/arm/mach-shmobile/setup-r8a7779.c |    5 -----
 1 file changed, 5 deletions(-)

Index: renesas/arch/arm/mach-shmobile/setup-r8a7779.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/setup-r8a7779.c
+++ renesas/arch/arm/mach-shmobile/setup-r8a7779.c
@@ -395,11 +395,6 @@ static struct resource usb_phy_resources
 		.end		= 0xffe70900 - 1,
 		.flags		= IORESOURCE_MEM,
 	},
-	[1] = {
-		.start		= 0xfff70000,
-		.end		= 0xfff70900 - 1,
-		.flags		= IORESOURCE_MEM,
-	},
 };
 
 static struct platform_device usb_phy_device = {


From balbi at ti.com  Tue Apr 23 11:29:21 2013
From: balbi at ti.com (Felipe Balbi)
Date: Tue, 23 Apr 2013 18:29:21 +0300
Subject: [PATCH 06/10] usb: musb: ux500: add device tree probing support
In-Reply-To: <201304231727.10696.arnd@arndb.de>
References: <1366729394-11406-1-git-send-email-lee.jones@linaro.org>
 <201304231714.06326.arnd@arndb.de>
 <20130423151533.GD15177@arwen.pp.htv.fi>
 <201304231727.10696.arnd@arndb.de>
Message-ID: <20130423152921.GE15177@arwen.pp.htv.fi>

Hi,

On Tue, Apr 23, 2013 at 05:27:10PM +0200, Arnd Bergmann wrote:
> > > > +Required properties:
> > > > + - compatible : Should be "stericsson,db8500-musb"
> > > > + - reg        : Offset and length of registers
> > > > + - interrupts : Interrupt; mode, number and trigger
> > > > + - mode       : One of; "host", "otg", or "peripheral"
> > > 
> > > I think we don't have any precedent for this combination of "mode" property
> > > and contents. You could either try to match ehci-omap.txt and do
> > 
> > there is dr_mode which other folks are using. Let's use the same thing.
> 
> On that topic, should we support the same property in am35x.c and 
> musbhsdma.c? They currently use an integer rather than a string.

certainly :) I also plan to add dr_mode support for dwc3.

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130423/03d6dba2/attachment.sig>

From arjan at linux.intel.com  Tue Apr 23 11:30:58 2013
From: arjan at linux.intel.com (Arjan van de Ven)
Date: Tue, 23 Apr 2013 08:30:58 -0700
Subject: [RFC PATCH v3 5/6] sched: pack the idle load balance
In-Reply-To: <5175F09E.1000304@intel.com>
References: <1363955155-18382-1-git-send-email-vincent.guittot@linaro.org>
 <1363955155-18382-6-git-send-email-vincent.guittot@linaro.org>
 <1364302359.5053.21.camel@laptop>
 <CAKfTPtD=_oS5gJeynUG=ft-Y1zEdxZEMhUPH9hSXx+H2pi4xgA@mail.gmail.com>
 <1364308932.5053.46.camel@laptop>
 <CAKfTPtArtgkH5MU_xFAKjLDS-i32g2qQMdvyW=LLkG84tH8Hhg@mail.gmail.com>
 <5174CE96.3060805@linux.vnet.ibm.com>
 <CAKfTPtCCCifC=c+xjjnAH_HSqkR80PiQoddQKXPHuZwZawbvcA@mail.gmail.com>
 <5175F09E.1000304@intel.com>
Message-ID: <5176A932.5050506@linux.intel.com>

On 4/22/2013 7:23 PM, Alex Shi wrote:
> Thanks you, Preeti and Vincent to talk the power aware scheduler for
> details! believe this open discussion is helpful to conduct a a more
> comprehensive solution. :)
>
>> Hi Preeti,
>>
>> I have had a look at Alex patches but i have some concerns with his patches
>> -There no notion of power domain which is quite important when we speak
>> about power saving IMHO. Packing tasks has got an interest if the idle
>> CPUs can reach a useful low power state independently from busy CPUs.
>> Architectures have different low power state capabilities which must be
>> taken into account. In addition, you can have system which have CPUs
>> with better power efficiency and this kind of system are not taken into
>> account.
>
> I agree with you on this point. and like what's you done to add new flag
> in sched domain.

For x86 we should not be setting such flag then; we don't have a way for some cpu packages to
go to an extra deep power state if they're completely idle.
(this afaik is true for both Intel and AMD)





From sergei.shtylyov at cogentembedded.com  Tue Apr 23 11:39:01 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Tue, 23 Apr 2013 19:39:01 +0400
Subject: [PATCH v6 8/9] ARM: shmobile: Marzen: pass platform data to USB PHY
 device
In-Reply-To: <201304231911.56202.sergei.shtylyov@cogentembedded.com>
References: <201304231911.56202.sergei.shtylyov@cogentembedded.com>
Message-ID: <201304231939.02407.sergei.shtylyov@cogentembedded.com>

Since we're now going to setup the USBPCTRL0 register using the USB PHY device's
platform data, we now need a way to pass those platform data from the board file
to the device which is situated in setup-r8a7779.c -- and what I'm suggesting is
r8a7779_add_usb_phy_device() that will register USB PHY platform device with the
passed platform data using platform_device_register_resndata() call; creating
this function involves deletion of 'usb_phy_device' from r8a7779_devices_dt[],
so that it will no longer be registered for the generic R8A7779 machine (where
we can't provide the platform data anyway), hence EHCI/OHCI drivers will fail
to load as well.

For the Marzen board, this new function will be called from marzen_init() to
register the USB PHY device early enough.

Note that the board and the SoC code have to be in one patch to keep the code
bisectable...

The patch has been tested on the Marzen board.

Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Acked-by: Simon Horman <horms+renesas at verge.net.au>

---
Changes since version 5:
- annotated USB PHY resources and platform data as '__initdata' since they're
  kmemdup()'ed while registering the platform device anyway;
- fixed typo in the changelog.

Changes since version 4:
- refreshed the patch.

Changes since version 3:
- removed the initializer for 'usb_phy_platform_data';
- refreshed the 'board-marzen.c' file.

Changes since version 2:
- refreshed atop of the prior patches;
- added a note about testing to the changelog;
- added ACKs from Simon Horman and Kuninori Morimoto.

Changes since the original posting:
- added a note about bisectability to the changelog.

 arch/arm/mach-shmobile/board-marzen.c         |    3 +++
 arch/arm/mach-shmobile/include/mach/r8a7779.h |    2 ++
 arch/arm/mach-shmobile/setup-r8a7779.c        |   18 +++++++++---------
 3 files changed, 14 insertions(+), 9 deletions(-)

Index: renesas/arch/arm/mach-shmobile/board-marzen.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/board-marzen.c
+++ renesas/arch/arm/mach-shmobile/board-marzen.c
@@ -57,6 +57,8 @@ static struct regulator_consumer_supply 
 	REGULATOR_SUPPLY("vdd33a", "smsc911x"),
 };
 
+static struct rcar_phy_platform_data usb_phy_platform_data __initdata;
+
 /* SMSC LAN89218 */
 static struct resource smsc911x_resources[] = {
 	[0] = {
@@ -232,6 +234,7 @@ static void __init marzen_init(void)
 	r8a7779_init_irq_extpin(1); /* IRQ1 as individual interrupt */
 
 	r8a7779_add_standard_devices();
+	r8a7779_add_usb_phy_device(&usb_phy_platform_data);
 	platform_add_devices(marzen_devices, ARRAY_SIZE(marzen_devices));
 }
 
Index: renesas/arch/arm/mach-shmobile/include/mach/r8a7779.h
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/include/mach/r8a7779.h
+++ renesas/arch/arm/mach-shmobile/include/mach/r8a7779.h
@@ -4,6 +4,7 @@
 #include <linux/sh_clk.h>
 #include <linux/pm_domain.h>
 #include <linux/sh_eth.h>
+#include <linux/usb/rcar-phy.h>
 
 struct platform_device;
 
@@ -33,6 +34,7 @@ extern void r8a7779_add_early_devices(vo
 extern void r8a7779_add_standard_devices(void);
 extern void r8a7779_add_standard_devices_dt(void);
 extern void r8a7779_add_ether_device(struct sh_eth_plat_data *pdata);
+extern void r8a7779_add_usb_phy_device(struct rcar_phy_platform_data *pdata);
 extern void r8a7779_init_late(void);
 extern void r8a7779_clock_init(void);
 extern void r8a7779_pinmux_init(void);
Index: renesas/arch/arm/mach-shmobile/setup-r8a7779.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/setup-r8a7779.c
+++ renesas/arch/arm/mach-shmobile/setup-r8a7779.c
@@ -389,7 +389,7 @@ static struct platform_device sata_devic
 };
 
 /* USB PHY */
-static struct resource usb_phy_resources[] = {
+static struct resource usb_phy_resources[] __initdata = {
 	[0] = {
 		.start		= 0xffe70800,
 		.end		= 0xffe70900 - 1,
@@ -397,13 +397,6 @@ static struct resource usb_phy_resources
 	},
 };
 
-static struct platform_device usb_phy_device = {
-	.name		= "rcar_usb_phy",
-	.id		= -1,
-	.resource	= usb_phy_resources,
-	.num_resources	= ARRAY_SIZE(usb_phy_resources),
-};
-
 /* USB */
 static struct usb_phy *phy;
 
@@ -575,7 +568,6 @@ static struct platform_device *r8a7779_d
 	&scif5_device,
 	&tmu00_device,
 	&tmu01_device,
-	&usb_phy_device,
 };
 
 static struct platform_device *r8a7779_standard_devices[] __initdata = {
@@ -610,6 +602,14 @@ void __init r8a7779_add_ether_device(str
 					  pdata, sizeof(*pdata));
 }
 
+void __init r8a7779_add_usb_phy_device(struct rcar_phy_platform_data *pdata)
+{
+	platform_device_register_resndata(&platform_bus, "rcar_usb_phy", -1,
+					  usb_phy_resources,
+					  ARRAY_SIZE(usb_phy_resources),
+					  pdata, sizeof(*pdata));
+}
+
 /* do nothing for !CONFIG_SMP or !CONFIG_HAVE_TWD */
 void __init __weak r8a7779_register_twd(void) { }
 


From arnd at arndb.de  Tue Apr 23 11:44:40 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 23 Apr 2013 17:44:40 +0200
Subject: [PATCH] ARM: bcm: mark bcm_kona_smc_init as __init
Message-ID: <201304231744.40614.arnd@arndb.de>

The bcm_kona_smc_init function references the bcm_kona_smc_ids variable
that is marked __initconst, so the function itself has to be __init
to avoid this build error:

WARNING: arch/arm/mach-bcm/built-in.o(.text+0x12c): Section mismatch in reference from the function bcm_kona_smc_init() to the (unknown reference) .init.rodata:(unknown)

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Cc: Christian Daudt <csd at broadcom.com>
---
I have applied this trivial fix to the next/firmware branch

diff --git a/arch/arm/mach-bcm/bcm_kona_smc.c b/arch/arm/mach-bcm/bcm_kona_smc.c
index 5f1d131..56d9d19 100644
--- a/arch/arm/mach-bcm/bcm_kona_smc.c
+++ b/arch/arm/mach-bcm/bcm_kona_smc.c
@@ -41,7 +41,7 @@ static const struct of_device_id bcm_kona_smc_ids[] __initconst = {
 };
 
 /* Map in the bounce area */
-void bcm_kona_smc_init(void)
+void __init bcm_kona_smc_init(void)
 {
 	struct device_node *node;
 


From t.figa at samsung.com  Tue Apr 23 11:46:21 2013
From: t.figa at samsung.com (Tomasz Figa)
Date: Tue, 23 Apr 2013 17:46:21 +0200
Subject: [PATCH v3 00/13] ARM: EXYNOS: Fix Universal C210 support
Message-ID: <1366731994-7478-1-git-send-email-t.figa@samsung.com>

This series intends to fix support for Universal C210 board in mainline.
Main difference from other boards based on Exynos 4210 is that hardware
revision of the SoC used on Universal C210 does not support MCT timers
and legacy PWM timers must be used instead.

First (and the biggest) part of the series deals with cleaning up and
fixing the samsung_pwm_timer clocksource driver, that was posted
recently by Arnd. In addition the driver is prepared to share the
hardware with PWM driver that will be reworked later, since it is not
a component crucial for system operation.

Second part fixes ATAGS support of Exynos 4210 rev0 SoC, which needs
different timer initialization, using the new samsung_pwm_timer driver.

Third and last part adds Device Tree-based support for Universal C210
board by providing device tree sources for it.

On Universal C210 board, both with and without DT:

Tested-by: Tomasz Figa <t.figa at samsung.com>

Tomasz Figa (13):
  Documentation: Add device tree bindings for Samsung PWM timers
  clocksource: samsung_pwm_timer: Let platforms select the driver
  clocksource: samsung_pwm_timer: Make PWM spinlock global
  clocksource: samsung_pwm_timer: Keep all driver data in a structure
  clocksource: samsung_pwm_timer: Drop unused samsung_pwm struct
  clocksource: samsung_pwm_timer: Add support for non-DT platforms
  clocksource: samsung_pwm_timer: Use proper clockevents max_delta
  clocksource: samsung_pwm_timer: Correct programming of clock events
  clocksource: samsung_pwm_timer: Work around rounding errors in
    clockevents core
  ARM: SAMSUNG: Do not register legacy timer interrupts on Exynos
  ARM: EXYNOS: Fix support of Exynos4210 rev0 SoC
  ARM: dts: exynos4: Add node for PWM device
  ARM: dts: exynos4210: Add basic dts file for universal_c210 board

 .../devicetree/bindings/pwm/pwm-samsung.txt        |  43 +++
 arch/arm/boot/dts/Makefile                         |   1 +
 arch/arm/boot/dts/exynos4.dtsi                     |   8 +
 arch/arm/boot/dts/exynos4210-universal_c210.dts    | 352 +++++++++++++++++++++
 arch/arm/mach-exynos/Kconfig                       |   3 +-
 arch/arm/mach-exynos/common.c                      |  45 ++-
 arch/arm/mach-exynos/common.h                      |   2 +
 arch/arm/mach-exynos/mach-universal_c210.c         |   5 +-
 arch/arm/plat-samsung/Kconfig                      |   4 +-
 drivers/clocksource/Kconfig                        |   3 +-
 drivers/clocksource/samsung_pwm_timer.c            | 215 +++++++------
 include/clocksource/samsung_pwm.h                  |  11 +-
 12 files changed, 561 insertions(+), 131 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/pwm/pwm-samsung.txt
 create mode 100644 arch/arm/boot/dts/exynos4210-universal_c210.dts

-- 
1.8.2.1



From t.figa at samsung.com  Tue Apr 23 11:46:22 2013
From: t.figa at samsung.com (Tomasz Figa)
Date: Tue, 23 Apr 2013 17:46:22 +0200
Subject: [PATCH v3 01/13] Documentation: Add device tree bindings for Samsung
 PWM timers
In-Reply-To: <1366731994-7478-1-git-send-email-t.figa@samsung.com>
References: <1366731994-7478-1-git-send-email-t.figa@samsung.com>
Message-ID: <1366731994-7478-2-git-send-email-t.figa@samsung.com>

This patch adds missing documentation describing Device Tree bindings
for Samsung PWM timers.

Signed-off-by: Tomasz Figa <t.figa at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
---
 .../devicetree/bindings/pwm/pwm-samsung.txt        | 43 ++++++++++++++++++++++
 1 file changed, 43 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pwm/pwm-samsung.txt

diff --git a/Documentation/devicetree/bindings/pwm/pwm-samsung.txt b/Documentation/devicetree/bindings/pwm/pwm-samsung.txt
new file mode 100644
index 0000000..ac67c68
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/pwm-samsung.txt
@@ -0,0 +1,43 @@
+* Samsung PWM timers
+
+Samsung SoCs contain PWM timer blocks which can be used for system clock source
+and clock event timers, as well as to drive SoC outputs with PWM signal. Each
+PWM timer block provides 5 PWM channels (not all of them can drive physical
+outputs - see SoC and board manual).
+
+Be aware that the clocksource driver supports only uniprocessor systems.
+
+Required properties:
+- compatible : should be one of following:
+    samsung,s3c2410-pwm - for 16-bit timers present on S3C24xx SoCs
+    samsung,s3c6400-pwm - for 32-bit timers present on S3C64xx SoCs
+    samsung,s5p6440-pwm - for 32-bit timers present on S5P64x0 SoCs
+    samsung,s5pc100-pwm - for 32-bit timers present on S5PC100, S5PV210,
+			  Exynos4210 rev0 SoCs
+    samsung,exynos4210-pwm - for 32-bit timers present on Exynos4210,
+                          Exynos4x12 and Exynos5250 SoCs
+- reg: base address and size of register area
+- interrupts: list of timer interrupts (one interrupt per timer, starting at
+  timer 0)
+- #pwm-cells: number of cells used for PWM specifier - must be 3
+   the specifier format is as follows:
+     - phandle to PWM controller node
+     - index of PWM channel (from 0 to 4)
+     - PWM signal period in nanoseconds
+     - bitmask of optional PWM flags:
+        0x1 - invert PWM signal
+
+Optional properties:
+- samsung,pwm-outputs: list of PWM channels used as PWM outputs on particular
+    platform - an array of up to 5 elements being indices of PWM channels
+    (from 0 to 4), the order does not matter.
+
+Example:
+	pwm at 7f006000 {
+		compatible = "samsung,s3c6400-pwm";
+		reg = <0x7f006000 0x1000>;
+		interrupt-parent = <&vic0>;
+		interrupts = <23>, <24>, <25>, <27>, <28>;
+		samsung,pwm-outputs = <0>, <1>;
+		#pwm-cells = <3>;
+	}
-- 
1.8.2.1



From t.figa at samsung.com  Tue Apr 23 11:46:23 2013
From: t.figa at samsung.com (Tomasz Figa)
Date: Tue, 23 Apr 2013 17:46:23 +0200
Subject: [PATCH v3 02/13] clocksource: samsung_pwm_timer: Let platforms select
 the driver
In-Reply-To: <1366731994-7478-1-git-send-email-t.figa@samsung.com>
References: <1366731994-7478-1-git-send-email-t.figa@samsung.com>
Message-ID: <1366731994-7478-3-git-send-email-t.figa@samsung.com>

This patch modifies the way of enabling the driver to let the platforms
select it in their Kconfig instead of specifying particular platforms in
Kconfig entry of the driver.

Signed-off-by: Tomasz Figa <t.figa at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
---
 drivers/clocksource/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index f261ddc..4700305 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -78,7 +78,7 @@ config CLKSRC_EXYNOS_MCT
 	  Support for Multi Core Timer controller on Exynos SoCs.
 
 config CLKSRC_SAMSUNG_PWM
-	def_bool ARCH_EXYNOS4
+	bool
 	depends on OF
 	select CLKSRC_MMIO
 	help
-- 
1.8.2.1



From t.figa at samsung.com  Tue Apr 23 11:46:24 2013
From: t.figa at samsung.com (Tomasz Figa)
Date: Tue, 23 Apr 2013 17:46:24 +0200
Subject: [PATCH v3 03/13] clocksource: samsung_pwm_timer: Make PWM spinlock
 global
In-Reply-To: <1366731994-7478-1-git-send-email-t.figa@samsung.com>
References: <1366731994-7478-1-git-send-email-t.figa@samsung.com>
Message-ID: <1366731994-7478-4-git-send-email-t.figa@samsung.com>

This patch makes the PWM spinlock global and exports it to allow using
it in Samsung PWM driver (will be reworked to use proper synchronization
in further patches).

Signed-off-by: Tomasz Figa <t.figa at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
---
 drivers/clocksource/samsung_pwm_timer.c | 24 +++++++++++++-----------
 include/clocksource/samsung_pwm.h       |  2 ++
 2 files changed, 15 insertions(+), 11 deletions(-)

diff --git a/drivers/clocksource/samsung_pwm_timer.c b/drivers/clocksource/samsung_pwm_timer.c
index 1752457..d9048b8 100644
--- a/drivers/clocksource/samsung_pwm_timer.c
+++ b/drivers/clocksource/samsung_pwm_timer.c
@@ -49,6 +49,9 @@
 #define TCON_INVERT(chan)		(1 << (4 * (chan) + 2))
 #define TCON_AUTORELOAD(chan)		(1 << (4 * (chan) + 3))
 
+DEFINE_SPINLOCK(samsung_pwm_lock);
+EXPORT_SYMBOL(samsung_pwm_lock);
+
 struct samsung_timer_source {
 	unsigned int event_id;
 	unsigned int source_id;
@@ -72,14 +75,14 @@ static void samsung_timer_set_prescale(struct samsung_pwm *pwm,
 	if (channel >= 2)
 		shift = TCFG0_PRESCALER1_SHIFT;
 
-	spin_lock_irqsave(&pwm->slock, flags);
+	spin_lock_irqsave(&samsung_pwm_lock, flags);
 
 	reg = readl(pwm->base + REG_TCFG0);
 	reg &= ~(TCFG0_PRESCALER_MASK << shift);
 	reg |= (prescale - 1) << shift;
 	writel(reg, pwm->base + REG_TCFG0);
 
-	spin_unlock_irqrestore(&pwm->slock, flags);
+	spin_unlock_irqrestore(&samsung_pwm_lock, flags);
 }
 
 static void samsung_timer_set_divisor(struct samsung_pwm *pwm,
@@ -92,14 +95,14 @@ static void samsung_timer_set_divisor(struct samsung_pwm *pwm,
 
 	bits = (fls(divisor) - 1) - pwm->variant.div_base;
 
-	spin_lock_irqsave(&pwm->slock, flags);
+	spin_lock_irqsave(&samsung_pwm_lock, flags);
 
 	reg = readl(pwm->base + REG_TCFG1);
 	reg &= ~(TCFG1_MUX_MASK << shift);
 	reg |= bits << shift;
 	writel(reg, pwm->base + REG_TCFG1);
 
-	spin_unlock_irqrestore(&pwm->slock, flags);
+	spin_unlock_irqrestore(&samsung_pwm_lock, flags);
 }
 
 static void samsung_time_stop(unsigned int channel)
@@ -110,13 +113,13 @@ static void samsung_time_stop(unsigned int channel)
 	if (channel > 0)
 		++channel;
 
-	spin_lock_irqsave(&pwm->slock, flags);
+	spin_lock_irqsave(&samsung_pwm_lock, flags);
 
 	tcon = __raw_readl(pwm->base + REG_TCON);
 	tcon &= ~TCON_START(channel);
 	__raw_writel(tcon, pwm->base + REG_TCON);
 
-	spin_unlock_irqrestore(&pwm->slock, flags);
+	spin_unlock_irqrestore(&samsung_pwm_lock, flags);
 }
 
 static void samsung_time_setup(unsigned int channel, unsigned long tcnt)
@@ -128,7 +131,7 @@ static void samsung_time_setup(unsigned int channel, unsigned long tcnt)
 	if (tcon_chan > 0)
 		++tcon_chan;
 
-	spin_lock_irqsave(&pwm->slock, flags);
+	spin_lock_irqsave(&samsung_pwm_lock, flags);
 
 	tcon = __raw_readl(pwm->base + REG_TCON);
 
@@ -141,7 +144,7 @@ static void samsung_time_setup(unsigned int channel, unsigned long tcnt)
 	__raw_writel(tcnt, pwm->base + REG_TCMPB(channel));
 	__raw_writel(tcon, pwm->base + REG_TCON);
 
-	spin_unlock_irqrestore(&pwm->slock, flags);
+	spin_unlock_irqrestore(&samsung_pwm_lock, flags);
 }
 
 static void samsung_time_start(unsigned int channel, bool periodic)
@@ -152,7 +155,7 @@ static void samsung_time_start(unsigned int channel, bool periodic)
 	if (channel > 0)
 		++channel;
 
-	spin_lock_irqsave(&pwm->slock, flags);
+	spin_lock_irqsave(&samsung_pwm_lock, flags);
 
 	tcon = __raw_readl(pwm->base + REG_TCON);
 
@@ -166,7 +169,7 @@ static void samsung_time_start(unsigned int channel, bool periodic)
 
 	__raw_writel(tcon, pwm->base + REG_TCON);
 
-	spin_unlock_irqrestore(&pwm->slock, flags);
+	spin_unlock_irqrestore(&samsung_pwm_lock, flags);
 }
 
 static int samsung_set_next_event(unsigned long cycles,
@@ -394,7 +397,6 @@ static void __init samsung_pwm_alloc(struct device_node *np,
 		return;
 	}
 	memcpy(&pwm->variant, variant, sizeof(pwm->variant));
-	spin_lock_init(&pwm->slock);
 	for (i = 0; i < SAMSUNG_PWM_NUM; ++i)
 		pwm->irq[i] = irq_of_parse_and_map(np, i);
 
diff --git a/include/clocksource/samsung_pwm.h b/include/clocksource/samsung_pwm.h
index eff8668..399d241 100644
--- a/include/clocksource/samsung_pwm.h
+++ b/include/clocksource/samsung_pwm.h
@@ -23,6 +23,8 @@
 struct platform_device;
 struct device_node;
 
+extern spinlock_t samsung_pwm_lock;
+
 struct samsung_pwm_variant {
 	u8 bits;
 	u8 div_base;
-- 
1.8.2.1



From t.figa at samsung.com  Tue Apr 23 11:46:25 2013
From: t.figa at samsung.com (Tomasz Figa)
Date: Tue, 23 Apr 2013 17:46:25 +0200
Subject: [PATCH v3 04/13] clocksource: samsung_pwm_timer: Keep all driver data
 in a structure
In-Reply-To: <1366731994-7478-1-git-send-email-t.figa@samsung.com>
References: <1366731994-7478-1-git-send-email-t.figa@samsung.com>
Message-ID: <1366731994-7478-5-git-send-email-t.figa@samsung.com>

This patch modifies the driver to keep all its private data consistently
in a single struct, instead of keeping part as separate variables.

Signed-off-by: Tomasz Figa <t.figa at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
---
 drivers/clocksource/samsung_pwm_timer.c | 157 +++++++++++++++-----------------
 1 file changed, 74 insertions(+), 83 deletions(-)

diff --git a/drivers/clocksource/samsung_pwm_timer.c b/drivers/clocksource/samsung_pwm_timer.c
index d9048b8..e3257fa 100644
--- a/drivers/clocksource/samsung_pwm_timer.c
+++ b/drivers/clocksource/samsung_pwm_timer.c
@@ -52,21 +52,25 @@
 DEFINE_SPINLOCK(samsung_pwm_lock);
 EXPORT_SYMBOL(samsung_pwm_lock);
 
-struct samsung_timer_source {
+struct samsung_pwm_clocksource {
+	void __iomem *base;
+	unsigned int irq[SAMSUNG_PWM_NUM];
+	struct samsung_pwm_variant variant;
+
+	struct clk *timerclk;
+
 	unsigned int event_id;
 	unsigned int source_id;
 	unsigned int tcnt_max;
 	unsigned int tscaler_div;
 	unsigned int tdiv;
+
+	unsigned long clock_count_per_tick;
 };
 
-static struct samsung_pwm *pwm;
-static struct clk *timerclk;
-static struct samsung_timer_source timer_source;
-static unsigned long clock_count_per_tick;
+static struct samsung_pwm_clocksource pwm;
 
-static void samsung_timer_set_prescale(struct samsung_pwm *pwm,
-					unsigned int channel, u16 prescale)
+static void samsung_timer_set_prescale(unsigned int channel, u16 prescale)
 {
 	unsigned long flags;
 	u8 shift = 0;
@@ -77,30 +81,29 @@ static void samsung_timer_set_prescale(struct samsung_pwm *pwm,
 
 	spin_lock_irqsave(&samsung_pwm_lock, flags);
 
-	reg = readl(pwm->base + REG_TCFG0);
+	reg = readl(pwm.base + REG_TCFG0);
 	reg &= ~(TCFG0_PRESCALER_MASK << shift);
 	reg |= (prescale - 1) << shift;
-	writel(reg, pwm->base + REG_TCFG0);
+	writel(reg, pwm.base + REG_TCFG0);
 
 	spin_unlock_irqrestore(&samsung_pwm_lock, flags);
 }
 
-static void samsung_timer_set_divisor(struct samsung_pwm *pwm,
-					unsigned int channel, u8 divisor)
+static void samsung_timer_set_divisor(unsigned int channel, u8 divisor)
 {
 	u8 shift = TCFG1_SHIFT(channel);
 	unsigned long flags;
 	u32 reg;
 	u8 bits;
 
-	bits = (fls(divisor) - 1) - pwm->variant.div_base;
+	bits = (fls(divisor) - 1) - pwm.variant.div_base;
 
 	spin_lock_irqsave(&samsung_pwm_lock, flags);
 
-	reg = readl(pwm->base + REG_TCFG1);
+	reg = readl(pwm.base + REG_TCFG1);
 	reg &= ~(TCFG1_MUX_MASK << shift);
 	reg |= bits << shift;
-	writel(reg, pwm->base + REG_TCFG1);
+	writel(reg, pwm.base + REG_TCFG1);
 
 	spin_unlock_irqrestore(&samsung_pwm_lock, flags);
 }
@@ -115,9 +118,9 @@ static void samsung_time_stop(unsigned int channel)
 
 	spin_lock_irqsave(&samsung_pwm_lock, flags);
 
-	tcon = __raw_readl(pwm->base + REG_TCON);
+	tcon = __raw_readl(pwm.base + REG_TCON);
 	tcon &= ~TCON_START(channel);
-	__raw_writel(tcon, pwm->base + REG_TCON);
+	__raw_writel(tcon, pwm.base + REG_TCON);
 
 	spin_unlock_irqrestore(&samsung_pwm_lock, flags);
 }
@@ -133,16 +136,16 @@ static void samsung_time_setup(unsigned int channel, unsigned long tcnt)
 
 	spin_lock_irqsave(&samsung_pwm_lock, flags);
 
-	tcon = __raw_readl(pwm->base + REG_TCON);
+	tcon = __raw_readl(pwm.base + REG_TCON);
 
 	tcnt--;
 
 	tcon &= ~(TCON_START(tcon_chan) | TCON_AUTORELOAD(tcon_chan));
 	tcon |= TCON_MANUALUPDATE(tcon_chan);
 
-	__raw_writel(tcnt, pwm->base + REG_TCNTB(channel));
-	__raw_writel(tcnt, pwm->base + REG_TCMPB(channel));
-	__raw_writel(tcon, pwm->base + REG_TCON);
+	__raw_writel(tcnt, pwm.base + REG_TCNTB(channel));
+	__raw_writel(tcnt, pwm.base + REG_TCMPB(channel));
+	__raw_writel(tcon, pwm.base + REG_TCON);
 
 	spin_unlock_irqrestore(&samsung_pwm_lock, flags);
 }
@@ -157,7 +160,7 @@ static void samsung_time_start(unsigned int channel, bool periodic)
 
 	spin_lock_irqsave(&samsung_pwm_lock, flags);
 
-	tcon = __raw_readl(pwm->base + REG_TCON);
+	tcon = __raw_readl(pwm.base + REG_TCON);
 
 	tcon &= ~TCON_MANUALUPDATE(channel);
 	tcon |= TCON_START(channel);
@@ -167,7 +170,7 @@ static void samsung_time_start(unsigned int channel, bool periodic)
 	else
 		tcon &= ~TCON_AUTORELOAD(channel);
 
-	__raw_writel(tcon, pwm->base + REG_TCON);
+	__raw_writel(tcon, pwm.base + REG_TCON);
 
 	spin_unlock_irqrestore(&samsung_pwm_lock, flags);
 }
@@ -175,8 +178,8 @@ static void samsung_time_start(unsigned int channel, bool periodic)
 static int samsung_set_next_event(unsigned long cycles,
 				struct clock_event_device *evt)
 {
-	samsung_time_setup(timer_source.event_id, cycles);
-	samsung_time_start(timer_source.event_id, false);
+	samsung_time_setup(pwm.event_id, cycles);
+	samsung_time_start(pwm.event_id, false);
 
 	return 0;
 }
@@ -184,23 +187,23 @@ static int samsung_set_next_event(unsigned long cycles,
 static void samsung_timer_resume(void)
 {
 	/* event timer restart */
-	samsung_time_setup(timer_source.event_id, clock_count_per_tick);
-	samsung_time_start(timer_source.event_id, true);
+	samsung_time_setup(pwm.event_id, pwm.clock_count_per_tick);
+	samsung_time_start(pwm.event_id, true);
 
 	/* source timer restart */
-	samsung_time_setup(timer_source.source_id, timer_source.tcnt_max);
-	samsung_time_start(timer_source.source_id, true);
+	samsung_time_setup(pwm.source_id, pwm.tcnt_max);
+	samsung_time_start(pwm.source_id, true);
 }
 
 static void samsung_set_mode(enum clock_event_mode mode,
 				struct clock_event_device *evt)
 {
-	samsung_time_stop(timer_source.event_id);
+	samsung_time_stop(pwm.event_id);
 
 	switch (mode) {
 	case CLOCK_EVT_MODE_PERIODIC:
-		samsung_time_setup(timer_source.event_id, clock_count_per_tick);
-		samsung_time_start(timer_source.event_id, true);
+		samsung_time_setup(pwm.event_id, pwm.clock_count_per_tick);
+		samsung_time_start(pwm.event_id, true);
 		break;
 
 	case CLOCK_EVT_MODE_ONESHOT:
@@ -228,9 +231,9 @@ static irqreturn_t samsung_clock_event_isr(int irq, void *dev_id)
 {
 	struct clock_event_device *evt = dev_id;
 
-	if (pwm->variant.has_tint_cstat) {
-		u32 mask = (1 << timer_source.event_id);
-		writel(mask | (mask << 5), pwm->base + REG_TINT_CSTAT);
+	if (pwm.variant.has_tint_cstat) {
+		u32 mask = (1 << pwm.event_id);
+		writel(mask | (mask << 5), pwm.base + REG_TINT_CSTAT);
 	}
 
 	evt->event_handler(evt);
@@ -251,39 +254,37 @@ static void __init samsung_clockevent_init(void)
 	unsigned long clock_rate;
 	unsigned int irq_number;
 
-	pclk = clk_get_rate(timerclk);
+	pclk = clk_get_rate(pwm.timerclk);
 
-	samsung_timer_set_prescale(pwm, timer_source.event_id,
-						timer_source.tscaler_div);
-	samsung_timer_set_divisor(pwm, timer_source.event_id,
-						timer_source.tdiv);
+	samsung_timer_set_prescale(pwm.event_id, pwm.tscaler_div);
+	samsung_timer_set_divisor(pwm.event_id, pwm.tdiv);
 
-	clock_rate = pclk / (timer_source.tscaler_div * timer_source.tdiv);
-	clock_count_per_tick = clock_rate / HZ;
+	clock_rate = pclk / (pwm.tscaler_div * pwm.tdiv);
+	pwm.clock_count_per_tick = clock_rate / HZ;
 
 	time_event_device.cpumask = cpumask_of(0);
 	clockevents_config_and_register(&time_event_device, clock_rate, 1, -1);
 
-	irq_number = pwm->irq[timer_source.event_id];
+	irq_number = pwm.irq[pwm.event_id];
 	setup_irq(irq_number, &samsung_clock_event_irq);
 
-	if (pwm->variant.has_tint_cstat) {
-		u32 mask = (1 << timer_source.event_id);
-		writel(mask | (mask << 5), pwm->base + REG_TINT_CSTAT);
+	if (pwm.variant.has_tint_cstat) {
+		u32 mask = (1 << pwm.event_id);
+		writel(mask | (mask << 5), pwm.base + REG_TINT_CSTAT);
 	}
 }
 
 static void __iomem *samsung_timer_reg(void)
 {
-	switch (timer_source.source_id) {
+	switch (pwm.source_id) {
 	case 0:
 	case 1:
 	case 2:
 	case 3:
-		return pwm->base + timer_source.source_id * 0x0c + 0x14;
+		return pwm.base + pwm.source_id * 0x0c + 0x14;
 
 	case 4:
-		return pwm->base + 0x40;
+		return pwm.base + 0x40;
 
 	default:
 		BUG();
@@ -314,23 +315,21 @@ static void __init samsung_clocksource_init(void)
 	unsigned long clock_rate;
 	int ret;
 
-	pclk = clk_get_rate(timerclk);
+	pclk = clk_get_rate(pwm.timerclk);
 
-	samsung_timer_set_prescale(pwm, timer_source.source_id,
-						timer_source.tscaler_div);
-	samsung_timer_set_divisor(pwm, timer_source.source_id,
-						timer_source.tdiv);
+	samsung_timer_set_prescale(pwm.source_id, pwm.tscaler_div);
+	samsung_timer_set_divisor(pwm.source_id, pwm.tdiv);
 
-	clock_rate = pclk / (timer_source.tscaler_div * timer_source.tdiv);
+	clock_rate = pclk / (pwm.tscaler_div * pwm.tdiv);
 
-	samsung_time_setup(timer_source.source_id, timer_source.tcnt_max);
-	samsung_time_start(timer_source.source_id, true);
+	samsung_time_setup(pwm.source_id, pwm.tcnt_max);
+	samsung_time_start(pwm.source_id, true);
 
 	setup_sched_clock(samsung_read_sched_clock,
-						pwm->variant.bits, clock_rate);
+						pwm.variant.bits, clock_rate);
 
 	ret = clocksource_mmio_init(reg, "samsung_clocksource_timer",
-					clock_rate, 250, pwm->variant.bits,
+					clock_rate, 250, pwm.variant.bits,
 					clocksource_mmio_readl_down);
 	if (ret)
 		panic("samsung_clocksource_timer: can't register clocksource\n");
@@ -338,19 +337,19 @@ static void __init samsung_clocksource_init(void)
 
 static void __init samsung_timer_resources(void)
 {
-	timerclk = clk_get(NULL, "timers");
-	if (IS_ERR(timerclk))
+	pwm.timerclk = clk_get(NULL, "timers");
+	if (IS_ERR(pwm.timerclk))
 		panic("failed to get timers clock for timer");
 
-	clk_prepare_enable(timerclk);
+	clk_prepare_enable(pwm.timerclk);
 
-	timer_source.tcnt_max = (1UL << pwm->variant.bits) - 1;
-	if (pwm->variant.bits == 16) {
-		timer_source.tscaler_div = 25;
-		timer_source.tdiv = 2;
+	pwm.tcnt_max = (1UL << pwm.variant.bits) - 1;
+	if (pwm.variant.bits == 16) {
+		pwm.tscaler_div = 25;
+		pwm.tdiv = 2;
 	} else {
-		timer_source.tscaler_div = 2;
-		timer_source.tdiv = 1;
+		pwm.tscaler_div = 2;
+		pwm.tdiv = 1;
 	}
 }
 
@@ -362,20 +361,17 @@ static void __init samsung_pwm_clocksource_init(void)
 	u8 mask;
 	int channel;
 
-	if (!pwm)
-		panic("no pwm clocksource device found");
-
-	mask = ~pwm->variant.output_mask & ((1 << SAMSUNG_PWM_NUM) - 1);
+	mask = ~pwm.variant.output_mask & ((1 << SAMSUNG_PWM_NUM) - 1);
 	channel = fls(mask) - 1;
 	if (channel < 0)
 		panic("failed to find PWM channel for clocksource");
-	timer_source.source_id = channel;
+	pwm.source_id = channel;
 
 	mask &= ~(1 << channel);
 	channel = fls(mask) - 1;
 	if (channel < 0)
 		panic("failed to find PWM channel for clock event");
-	timer_source.event_id = channel;
+	pwm.event_id = channel;
 
 	samsung_timer_resources();
 	samsung_clockevent_init();
@@ -391,14 +387,9 @@ static void __init samsung_pwm_alloc(struct device_node *np,
 	u32 val;
 	int i;
 
-	pwm = kzalloc(sizeof(*pwm), GFP_KERNEL);
-	if (!pwm) {
-		pr_err("%s: could not allocate PWM device struct\n", __func__);
-		return;
-	}
-	memcpy(&pwm->variant, variant, sizeof(pwm->variant));
+	memcpy(&pwm.variant, variant, sizeof(pwm.variant));
 	for (i = 0; i < SAMSUNG_PWM_NUM; ++i)
-		pwm->irq[i] = irq_of_parse_and_map(np, i);
+		pwm.irq[i] = irq_of_parse_and_map(np, i);
 
 	of_property_for_each_u32(np, "samsung,pwm-outputs", prop, cur, val) {
 		if (val >= SAMSUNG_PWM_NUM) {
@@ -406,7 +397,7 @@ static void __init samsung_pwm_alloc(struct device_node *np,
 								__func__);
 			continue;
 		}
-		pwm->variant.output_mask |= 1 << val;
+		pwm.variant.output_mask |= 1 << val;
 	}
 
 	of_address_to_resource(np, 0, &res);
@@ -416,8 +407,8 @@ static void __init samsung_pwm_alloc(struct device_node *np,
 		return;
 	}
 
-	pwm->base = ioremap(res.start, resource_size(&res));
-	if (!pwm->base) {
+	pwm.base = ioremap(res.start, resource_size(&res));
+	if (!pwm.base) {
 		pr_err("%s: failed to map PWM registers\n", __func__);
 		release_mem_region(res.start, resource_size(&res));
 		return;
-- 
1.8.2.1



From t.figa at samsung.com  Tue Apr 23 11:46:26 2013
From: t.figa at samsung.com (Tomasz Figa)
Date: Tue, 23 Apr 2013 17:46:26 +0200
Subject: [PATCH v3 05/13] clocksource: samsung_pwm_timer: Drop unused
 samsung_pwm struct
In-Reply-To: <1366731994-7478-1-git-send-email-t.figa@samsung.com>
References: <1366731994-7478-1-git-send-email-t.figa@samsung.com>
Message-ID: <1366731994-7478-6-git-send-email-t.figa@samsung.com>

This patch removes the unused samsung_pwm struct from public header.

Signed-off-by: Tomasz Figa <t.figa at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
---
 include/clocksource/samsung_pwm.h | 10 ----------
 1 file changed, 10 deletions(-)

diff --git a/include/clocksource/samsung_pwm.h b/include/clocksource/samsung_pwm.h
index 399d241..b1d8fe7 100644
--- a/include/clocksource/samsung_pwm.h
+++ b/include/clocksource/samsung_pwm.h
@@ -20,9 +20,6 @@
 
 #define SAMSUNG_PWM_NUM		5
 
-struct platform_device;
-struct device_node;
-
 extern spinlock_t samsung_pwm_lock;
 
 struct samsung_pwm_variant {
@@ -33,11 +30,4 @@ struct samsung_pwm_variant {
 	bool has_tint_cstat;
 };
 
-struct samsung_pwm {
-	struct samsung_pwm_variant variant;
-	spinlock_t slock;
-	void __iomem *base;
-	int irq[SAMSUNG_PWM_NUM];
-};
-
 #endif /* __CLOCKSOURCE_SAMSUNG_PWM_H */
-- 
1.8.2.1



From t.figa at samsung.com  Tue Apr 23 11:46:27 2013
From: t.figa at samsung.com (Tomasz Figa)
Date: Tue, 23 Apr 2013 17:46:27 +0200
Subject: [PATCH v3 06/13] clocksource: samsung_pwm_timer: Add support for
 non-DT platforms
In-Reply-To: <1366731994-7478-1-git-send-email-t.figa@samsung.com>
References: <1366731994-7478-1-git-send-email-t.figa@samsung.com>
Message-ID: <1366731994-7478-7-git-send-email-t.figa@samsung.com>

This patch extends the driver to support platforms that still use legacy
ATAGS-based boot, without device tree, by providing an exported function
that can be used from platform code to initialize the clocksource.

Signed-off-by: Tomasz Figa <t.figa at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
---
 drivers/clocksource/Kconfig             |  1 -
 drivers/clocksource/samsung_pwm_timer.c | 16 ++++++++++++++--
 include/clocksource/samsung_pwm.h       |  3 +++
 3 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index 4700305..f151c6c 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -79,7 +79,6 @@ config CLKSRC_EXYNOS_MCT
 
 config CLKSRC_SAMSUNG_PWM
 	bool
-	depends on OF
 	select CLKSRC_MMIO
 	help
 	  This is a new clocksource driver for the PWM timer found in
diff --git a/drivers/clocksource/samsung_pwm_timer.c b/drivers/clocksource/samsung_pwm_timer.c
index e3257fa..9f4bd6a 100644
--- a/drivers/clocksource/samsung_pwm_timer.c
+++ b/drivers/clocksource/samsung_pwm_timer.c
@@ -356,7 +356,7 @@ static void __init samsung_timer_resources(void)
 /*
  * PWM master driver
  */
-static void __init samsung_pwm_clocksource_init(void)
+static void __init _samsung_pwm_clocksource_init(void)
 {
 	u8 mask;
 	int channel;
@@ -378,6 +378,17 @@ static void __init samsung_pwm_clocksource_init(void)
 	samsung_clocksource_init();
 }
 
+void __init samsung_pwm_clocksource_init(void __iomem *base,
+			unsigned int *irqs, struct samsung_pwm_variant *variant)
+{
+	pwm.base = base;
+	memcpy(&pwm.variant, variant, sizeof(pwm.variant));
+	memcpy(pwm.irq, irqs, SAMSUNG_PWM_NUM * sizeof(*irqs));
+
+	_samsung_pwm_clocksource_init();
+}
+
+#ifdef CONFIG_CLKSRC_OF
 static void __init samsung_pwm_alloc(struct device_node *np,
 				     const struct samsung_pwm_variant *variant)
 {
@@ -414,7 +425,7 @@ static void __init samsung_pwm_alloc(struct device_node *np,
 		return;
 	}
 
-	samsung_pwm_clocksource_init();
+	_samsung_pwm_clocksource_init();
 }
 
 static const struct samsung_pwm_variant s3c24xx_variant = {
@@ -468,3 +479,4 @@ static void __init s5p_pwm_clocksource_init(struct device_node *np)
 	samsung_pwm_alloc(np, &s5p_variant);
 }
 CLOCKSOURCE_OF_DECLARE(s5pc100_pwm, "samsung,s5pc100-pwm", s5p_pwm_clocksource_init);
+#endif
diff --git a/include/clocksource/samsung_pwm.h b/include/clocksource/samsung_pwm.h
index b1d8fe7..5c449c8 100644
--- a/include/clocksource/samsung_pwm.h
+++ b/include/clocksource/samsung_pwm.h
@@ -30,4 +30,7 @@ struct samsung_pwm_variant {
 	bool has_tint_cstat;
 };
 
+void samsung_pwm_clocksource_init(void __iomem *base,
+		unsigned int *irqs, struct samsung_pwm_variant *variant);
+
 #endif /* __CLOCKSOURCE_SAMSUNG_PWM_H */
-- 
1.8.2.1



From t.figa at samsung.com  Tue Apr 23 11:46:28 2013
From: t.figa at samsung.com (Tomasz Figa)
Date: Tue, 23 Apr 2013 17:46:28 +0200
Subject: [PATCH v3 07/13] clocksource: samsung_pwm_timer: Use proper
 clockevents max_delta
In-Reply-To: <1366731994-7478-1-git-send-email-t.figa@samsung.com>
References: <1366731994-7478-1-git-send-email-t.figa@samsung.com>
Message-ID: <1366731994-7478-8-git-send-email-t.figa@samsung.com>

This patch replaces hardcoded -1 argument passed to
clockevents_config_and_register() with tcnt_max calculated based on
variant data.

This fixes invalid max delta configuration for 16-bit timers of s3c24xx.

Signed-off-by: Tomasz Figa <t.figa at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
---
 drivers/clocksource/samsung_pwm_timer.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/clocksource/samsung_pwm_timer.c b/drivers/clocksource/samsung_pwm_timer.c
index 9f4bd6a..cb86615 100644
--- a/drivers/clocksource/samsung_pwm_timer.c
+++ b/drivers/clocksource/samsung_pwm_timer.c
@@ -263,7 +263,8 @@ static void __init samsung_clockevent_init(void)
 	pwm.clock_count_per_tick = clock_rate / HZ;
 
 	time_event_device.cpumask = cpumask_of(0);
-	clockevents_config_and_register(&time_event_device, clock_rate, 1, -1);
+	clockevents_config_and_register(&time_event_device,
+						clock_rate, 1, pwm.tcnt_max);
 
 	irq_number = pwm.irq[pwm.event_id];
 	setup_irq(irq_number, &samsung_clock_event_irq);
-- 
1.8.2.1



From t.figa at samsung.com  Tue Apr 23 11:46:29 2013
From: t.figa at samsung.com (Tomasz Figa)
Date: Tue, 23 Apr 2013 17:46:29 +0200
Subject: [PATCH v3 08/13] clocksource: samsung_pwm_timer: Correct programming
 of clock events
In-Reply-To: <1366731994-7478-1-git-send-email-t.figa@samsung.com>
References: <1366731994-7478-1-git-send-email-t.figa@samsung.com>
Message-ID: <1366731994-7478-9-git-send-email-t.figa@samsung.com>

In current code, the tick count value programmed to the hardware is
always decremented by one. This is reasonable for periodic mode, since
there is one extra tick between 0 and COUNT (after reloading), but it
makes oneshot events happen 1 tick earlier than requested, because the
interrupt is triggered on transition from 1 to 0.

This patch removes the decrementation from PWM channel setup code and
moves it instead to periodic timer setup, to make both periodic and
oneshot modes work correctly.

Signed-off-by: Tomasz Figa <t.figa at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
---
 drivers/clocksource/samsung_pwm_timer.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/clocksource/samsung_pwm_timer.c b/drivers/clocksource/samsung_pwm_timer.c
index cb86615..92b2f13 100644
--- a/drivers/clocksource/samsung_pwm_timer.c
+++ b/drivers/clocksource/samsung_pwm_timer.c
@@ -138,8 +138,6 @@ static void samsung_time_setup(unsigned int channel, unsigned long tcnt)
 
 	tcon = __raw_readl(pwm.base + REG_TCON);
 
-	tcnt--;
-
 	tcon &= ~(TCON_START(tcon_chan) | TCON_AUTORELOAD(tcon_chan));
 	tcon |= TCON_MANUALUPDATE(tcon_chan);
 
@@ -187,7 +185,7 @@ static int samsung_set_next_event(unsigned long cycles,
 static void samsung_timer_resume(void)
 {
 	/* event timer restart */
-	samsung_time_setup(pwm.event_id, pwm.clock_count_per_tick);
+	samsung_time_setup(pwm.event_id, pwm.clock_count_per_tick - 1);
 	samsung_time_start(pwm.event_id, true);
 
 	/* source timer restart */
@@ -202,7 +200,7 @@ static void samsung_set_mode(enum clock_event_mode mode,
 
 	switch (mode) {
 	case CLOCK_EVT_MODE_PERIODIC:
-		samsung_time_setup(pwm.event_id, pwm.clock_count_per_tick);
+		samsung_time_setup(pwm.event_id, pwm.clock_count_per_tick - 1);
 		samsung_time_start(pwm.event_id, true);
 		break;
 
-- 
1.8.2.1



From t.figa at samsung.com  Tue Apr 23 11:46:30 2013
From: t.figa at samsung.com (Tomasz Figa)
Date: Tue, 23 Apr 2013 17:46:30 +0200
Subject: [PATCH v3 09/13] clocksource: samsung_pwm_timer: Work around rounding
 errors in clockevents core
In-Reply-To: <1366731994-7478-1-git-send-email-t.figa@samsung.com>
References: <1366731994-7478-1-git-send-email-t.figa@samsung.com>
Message-ID: <1366731994-7478-10-git-send-email-t.figa@samsung.com>

Due to rounding errors in clockevents core (in conversions between ticks
and nsecs), it might happen that the set_next_event callback gets called
with cycles = 0, causing the code to incorrectly program the PWM timer.

This patch modifies the callback to program the timer for 1 tick, if
received tick count value is 0.

Signed-off-by: Tomasz Figa <t.figa at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
---
 drivers/clocksource/samsung_pwm_timer.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/drivers/clocksource/samsung_pwm_timer.c b/drivers/clocksource/samsung_pwm_timer.c
index 92b2f13..0234c8d 100644
--- a/drivers/clocksource/samsung_pwm_timer.c
+++ b/drivers/clocksource/samsung_pwm_timer.c
@@ -176,6 +176,19 @@ static void samsung_time_start(unsigned int channel, bool periodic)
 static int samsung_set_next_event(unsigned long cycles,
 				struct clock_event_device *evt)
 {
+	/*
+	 * This check is needed to account for internal rounding
+	 * errors inside clockevents core, which might result in
+	 * passing cycles = 0, which in turn would not generate any
+	 * timer interrupt and hang the system.
+	 *
+	 * Another solution would be to set up the clockevent device
+	 * with min_delta = 2, but this would unnecessarily increase
+	 * the minimum sleep period.
+	 */
+	if (!cycles)
+		cycles = 1;
+
 	samsung_time_setup(pwm.event_id, cycles);
 	samsung_time_start(pwm.event_id, false);
 
-- 
1.8.2.1



From t.figa at samsung.com  Tue Apr 23 11:46:31 2013
From: t.figa at samsung.com (Tomasz Figa)
Date: Tue, 23 Apr 2013 17:46:31 +0200
Subject: [PATCH v3 10/13] ARM: SAMSUNG: Do not register legacy timer interrupts
 on Exynos
In-Reply-To: <1366731994-7478-1-git-send-email-t.figa@samsung.com>
References: <1366731994-7478-1-git-send-email-t.figa@samsung.com>
Message-ID: <1366731994-7478-11-git-send-email-t.figa@samsung.com>

This patch removes legacy PWM timer interrupt initialization from
exynos{4,5}_init_irq() functions, since it conflicts with internal
interrupt handling of the new PWM clocksource driver.

Signed-off-by: Tomasz Figa <t.figa at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
---
 arch/arm/mach-exynos/common.c | 15 ---------------
 arch/arm/plat-samsung/Kconfig |  4 ++--
 2 files changed, 2 insertions(+), 17 deletions(-)

diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
index 64ef39e..9574498 100644
--- a/arch/arm/mach-exynos/common.c
+++ b/arch/arm/mach-exynos/common.c
@@ -492,13 +492,6 @@ void __init exynos4_init_irq(void)
 		combiner_init(S5P_VA_COMBINER_BASE, NULL,
 			      max_combiner_nr(), COMBINER_IRQ(0, 0));
 
-	/*
-	 * The parameters of s5p_init_irq() are for VIC init.
-	 * Theses parameters should be NULL and 0 because EXYNOS4
-	 * uses GIC instead of VIC.
-	 */
-	s5p_init_irq(NULL, 0);
-
 	gic_arch_extn.irq_set_wake = s3c_irq_wake;
 }
 
@@ -507,14 +500,6 @@ void __init exynos5_init_irq(void)
 #ifdef CONFIG_OF
 	irqchip_init();
 #endif
-	/*
-	 * The parameters of s5p_init_irq() are for VIC init.
-	 * Theses parameters should be NULL and 0 because EXYNOS4
-	 * uses GIC instead of VIC.
-	 */
-	if (!of_machine_is_compatible("samsung,exynos5440"))
-		s5p_init_irq(NULL, 0);
-
 	gic_arch_extn.irq_set_wake = s3c_irq_wake;
 }
 
diff --git a/arch/arm/plat-samsung/Kconfig b/arch/arm/plat-samsung/Kconfig
index 53e7eeb..04410da 100644
--- a/arch/arm/plat-samsung/Kconfig
+++ b/arch/arm/plat-samsung/Kconfig
@@ -97,9 +97,9 @@ config SAMSUNG_IRQ_VIC_TIMER
          Internal configuration to build the VIC timer interrupt code.
 
 config S5P_IRQ
-	def_bool (ARCH_S5P64X0 || ARCH_S5PC100 || ARCH_S5PV210 || ARCH_EXYNOS)
+	def_bool (ARCH_S5P64X0 || ARCH_S5PC100 || ARCH_S5PV210)
 	help
-	  Support common interrup part for ARCH_S5P and ARCH_EXYNOS SoCs
+	  Support common interrupt part for ARCH_S5P SoCs
 
 config S5P_EXT_INT
 	bool
-- 
1.8.2.1



From t.figa at samsung.com  Tue Apr 23 11:46:32 2013
From: t.figa at samsung.com (Tomasz Figa)
Date: Tue, 23 Apr 2013 17:46:32 +0200
Subject: [PATCH v3 11/13] ARM: EXYNOS: Fix support of Exynos4210 rev0 SoC
In-Reply-To: <1366731994-7478-1-git-send-email-t.figa@samsung.com>
References: <1366731994-7478-1-git-send-email-t.figa@samsung.com>
Message-ID: <1366731994-7478-12-git-send-email-t.figa@samsung.com>

This patch extends exynos_init_time() function to handle Exynos4210 rev0
SoC, which differs in availability of system timers and needs different
clocksource initialization.

This makes it possible to use exynos_init_time() function as init_time
callback for all Exynos-based boards, including Universal_C210, which
originally had to use samsung_timer_init().

Signed-off-by: Tomasz Figa <t.figa at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
---
 arch/arm/mach-exynos/Kconfig               |  3 ++-
 arch/arm/mach-exynos/common.c              | 30 +++++++++++++++++++++++++++++-
 arch/arm/mach-exynos/common.h              |  2 ++
 arch/arm/mach-exynos/mach-universal_c210.c |  5 ++---
 4 files changed, 35 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index eefea36..f7af1e0 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -268,6 +268,7 @@ config MACH_ARMLEX4210
 config MACH_UNIVERSAL_C210
 	bool "Mobile UNIVERSAL_C210 Board"
 	select CLKSRC_MMIO
+	select CLKSRC_SAMSUNG_PWM
 	select CPU_EXYNOS4210
 	select EXYNOS4_SETUP_FIMC
 	select EXYNOS4_SETUP_FIMD0
@@ -299,7 +300,6 @@ config MACH_UNIVERSAL_C210
 	select S5P_DEV_TV
 	select S5P_GPIO_INT
 	select S5P_SETUP_MIPIPHY
-	select SAMSUNG_HRT
 	help
 	  Machine support for Samsung Mobile Universal S5PC210 Reference
 	  Board.
@@ -428,6 +428,7 @@ config MACH_EXYNOS4_DT
 	depends on ARCH_EXYNOS4
 	select ARM_AMBA
 	select CLKSRC_OF
+	select CLKSRC_SAMSUNG_PWM if CPU_EXYNOS4210
 	select CPU_EXYNOS4210
 	select KEYBOARD_SAMSUNG if INPUT_KEYBOARD
 	select PINCTRL
diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
index 9574498..52c024f 100644
--- a/arch/arm/mach-exynos/common.c
+++ b/arch/arm/mach-exynos/common.c
@@ -10,12 +10,14 @@
  */
 
 #include <linux/kernel.h>
+#include <linux/bitops.h>
 #include <linux/interrupt.h>
 #include <linux/irq.h>
 #include <linux/irqchip.h>
 #include <linux/io.h>
 #include <linux/device.h>
 #include <linux/gpio.h>
+#include <clocksource/samsung_pwm.h>
 #include <linux/sched.h>
 #include <linux/serial_core.h>
 #include <linux/of.h>
@@ -445,8 +447,27 @@ static void __init exynos5440_map_io(void)
 	iotable_init(exynos5440_iodesc0, ARRAY_SIZE(exynos5440_iodesc0));
 }
 
+static struct samsung_pwm_variant exynos4_pwm_variant = {
+	.bits		= 32,
+	.div_base	= 0,
+	.has_tint_cstat	= true,
+	.tclk_mask	= 0,
+};
+
+void __init exynos_set_timer_source(u8 channels)
+{
+	exynos4_pwm_variant.output_mask = BIT(SAMSUNG_PWM_NUM) - 1;
+	exynos4_pwm_variant.output_mask &= ~channels;
+}
+
 void __init exynos_init_time(void)
 {
+	unsigned int timer_irqs[SAMSUNG_PWM_NUM] = {
+		EXYNOS4_IRQ_TIMER0_VIC, EXYNOS4_IRQ_TIMER1_VIC,
+		EXYNOS4_IRQ_TIMER2_VIC, EXYNOS4_IRQ_TIMER3_VIC,
+		EXYNOS4_IRQ_TIMER4_VIC,
+	};
+
 	if (of_have_populated_dt()) {
 #ifdef CONFIG_OF
 		of_clk_init(NULL);
@@ -458,7 +479,14 @@ void __init exynos_init_time(void)
 		exynos4_clk_init(NULL, !soc_is_exynos4210(), S5P_VA_CMU, readl(S5P_VA_CHIPID + 8) & 1);
 		exynos4_clk_register_fixed_ext(xxti_f, xusbxti_f);
 #endif
-		mct_init(S5P_VA_SYSTIMER, EXYNOS4_IRQ_MCT_G0, EXYNOS4_IRQ_MCT_L0, EXYNOS4_IRQ_MCT_L1);
+#ifdef CONFIG_CLKSRC_SAMSUNG_PWM
+		if (soc_is_exynos4210() && samsung_rev() == EXYNOS4210_REV_0)
+			samsung_pwm_clocksource_init(S3C_VA_TIMER,
+					timer_irqs, &exynos4_pwm_variant);
+		else
+#endif
+			mct_init(S5P_VA_SYSTIMER, EXYNOS4_IRQ_MCT_G0,
+					EXYNOS4_IRQ_MCT_L0, EXYNOS4_IRQ_MCT_L1);
 	}
 }
 
diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
index 60dd35c..11fc1e2 100644
--- a/arch/arm/mach-exynos/common.h
+++ b/arch/arm/mach-exynos/common.h
@@ -32,6 +32,8 @@ void exynos4_clk_register_fixed_ext(unsigned long, unsigned long);
 
 void exynos_firmware_init(void);
 
+void exynos_set_timer_source(u8 channels);
+
 #ifdef CONFIG_PM_GENERIC_DOMAINS
 int exynos_pm_late_initcall(void);
 #else
diff --git a/arch/arm/mach-exynos/mach-universal_c210.c b/arch/arm/mach-exynos/mach-universal_c210.c
index 020e1f4..6ca31c4 100644
--- a/arch/arm/mach-exynos/mach-universal_c210.c
+++ b/arch/arm/mach-exynos/mach-universal_c210.c
@@ -41,7 +41,6 @@
 #include <plat/mfc.h>
 #include <plat/sdhci.h>
 #include <plat/fimc-core.h>
-#include <plat/samsung-time.h>
 #include <plat/camport.h>
 
 #include <mach/map.h>
@@ -1117,7 +1116,7 @@ static void __init universal_map_io(void)
 {
 	exynos_init_io(NULL, 0);
 	s3c24xx_init_uarts(universal_uartcfgs, ARRAY_SIZE(universal_uartcfgs));
-	samsung_set_timer_source(SAMSUNG_PWM2, SAMSUNG_PWM4);
+	exynos_set_timer_source(BIT(2) | BIT(4));
 	xxti_f = 0;
 	xusbxti_f = 24000000;
 }
@@ -1177,7 +1176,7 @@ MACHINE_START(UNIVERSAL_C210, "UNIVERSAL_C210")
 	.map_io		= universal_map_io,
 	.init_machine	= universal_machine_init,
 	.init_late	= exynos_init_late,
-	.init_time	= samsung_timer_init,
+	.init_time	= exynos_init_time,
 	.reserve        = &universal_reserve,
 	.restart	= exynos4_restart,
 MACHINE_END
-- 
1.8.2.1



From t.figa at samsung.com  Tue Apr 23 11:46:33 2013
From: t.figa at samsung.com (Tomasz Figa)
Date: Tue, 23 Apr 2013 17:46:33 +0200
Subject: [PATCH v3 12/13] ARM: dts: exynos4: Add node for PWM device
In-Reply-To: <1366731994-7478-1-git-send-email-t.figa@samsung.com>
References: <1366731994-7478-1-git-send-email-t.figa@samsung.com>
Message-ID: <1366731994-7478-13-git-send-email-t.figa@samsung.com>

This patch adds device tree node for PWM block present on Exynos 4 SoCs.

Signed-off-by: Tomasz Figa <t.figa at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
---
 arch/arm/boot/dts/exynos4.dtsi | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index efd441a..bed40ee 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -338,6 +338,14 @@
 		status = "disabled";
 	};
 
+	pwm at 139D0000 {
+		compatible = "samsung,exynos4210-pwm";
+		reg = <0x139D0000 0x1000>;
+		interrupts = <0 37 0>, <0 38 0>, <0 39 0>, <0 40 0>, <0 41 0>;
+		#pwm-cells = <2>;
+		status = "disabled";
+	};
+
 	amba {
 		#address-cells = <1>;
 		#size-cells = <1>;
-- 
1.8.2.1



From t.figa at samsung.com  Tue Apr 23 11:46:34 2013
From: t.figa at samsung.com (Tomasz Figa)
Date: Tue, 23 Apr 2013 17:46:34 +0200
Subject: [PATCH v3 13/13] ARM: dts: exynos4210: Add basic dts file for
 universal_c210 board
In-Reply-To: <1366731994-7478-1-git-send-email-t.figa@samsung.com>
References: <1366731994-7478-1-git-send-email-t.figa@samsung.com>
Message-ID: <1366731994-7478-14-git-send-email-t.figa@samsung.com>

This patch adds basic device tree sources for Universal C210 board.

Currently support includes:
- eMMC
- serial
- max8952 and max8998 voltage regulators.
- gpio-keys

More support will be added in further patches.

Signed-off-by: Tomasz Figa <t.figa at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
---
 arch/arm/boot/dts/Makefile                      |   1 +
 arch/arm/boot/dts/exynos4210-universal_c210.dts | 352 ++++++++++++++++++++++++
 2 files changed, 353 insertions(+)
 create mode 100644 arch/arm/boot/dts/exynos4210-universal_c210.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 8fd41b3..6647274 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -49,6 +49,7 @@ dtb-$(CONFIG_ARCH_DOVE) += dove-cm-a510.dtb \
 dtb-$(CONFIG_ARCH_EXYNOS) += exynos4210-origen.dtb \
 	exynos4210-smdkv310.dtb \
 	exynos4210-trats.dtb \
+	exynos4210-universal_c210.dtb \
 	exynos4412-odroidx.dtb \
 	exynos4412-smdk4412.dtb \
 	exynos4412-origen.dtb \
diff --git a/arch/arm/boot/dts/exynos4210-universal_c210.dts b/arch/arm/boot/dts/exynos4210-universal_c210.dts
new file mode 100644
index 0000000..345cdb5
--- /dev/null
+++ b/arch/arm/boot/dts/exynos4210-universal_c210.dts
@@ -0,0 +1,352 @@
+/*
+ * Samsung's Exynos4210 based Universal C210 board device tree source
+ *
+ * Copyright (c) 2012-2013 Samsung Electronics Co., Ltd.
+ *		http://www.samsung.com
+ *
+ * Device tree source file for Samsung's Universal C210 board which is based on
+ * Samsung's Exynos4210 rev0 SoC.
+ *
+ * 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.
+*/
+
+/dts-v1/;
+/include/ "exynos4210.dtsi"
+
+/ {
+	model = "Samsung Universal C210 based on Exynos4210 rev0";
+	compatible = "samsung,universal_c210", "samsung,exynos4210";
+
+	memory {
+		reg =  <0x40000000 0x10000000
+			0x50000000 0x10000000>;
+	};
+
+	chosen {
+		bootargs = "console=ttySAC2,115200N8 root=/dev/mmcblk0p5 rw rootwait earlyprintk panic=5 maxcpus=1";
+	};
+
+	mct at 10050000 {
+		compatible = "none";
+	};
+
+	fixed-rate-clocks {
+		xxti {
+			compatible = "samsung,clock-xxti";
+			clock-frequency = <0>;
+		};
+
+		xusbxti {
+			compatible = "samsung,clock-xusbxti";
+			clock-frequency = <24000000>;
+		};
+	};
+
+	vemmc_reg: voltage-regulator {
+	        compatible = "regulator-fixed";
+		regulator-name = "VMEM_VDD_2_8V";
+		regulator-min-microvolt = <2800000>;
+		regulator-max-microvolt = <2800000>;
+		gpio = <&gpe1 3 0>;
+		enable-active-high;
+	};
+
+	sdhci_emmc: sdhci at 12510000 {
+		bus-width = <8>;
+		non-removable;
+		pinctrl-0 = <&sd0_clk &sd0_cmd &sd0_bus8>;
+		pinctrl-names = "default";
+		vmmc-supply = <&vemmc_reg>;
+		status = "okay";
+	};
+
+	serial at 13800000 {
+		status = "okay";
+	};
+
+	serial at 13810000 {
+		status = "okay";
+	};
+
+	serial at 13820000 {
+		status = "okay";
+	};
+
+	serial at 13830000 {
+		status = "okay";
+	};
+
+	gpio-keys {
+		compatible = "gpio-keys";
+
+		vol-up-key {
+			gpios = <&gpx2 0 1>;
+			linux,code = <115>;
+			label = "volume up";
+			debounce-interval = <1>;
+		};
+
+		vol-down-key {
+			gpios = <&gpx2 1 1>;
+			linux,code = <114>;
+			label = "volume down";
+			debounce-interval = <1>;
+		};
+
+		config-key {
+			gpios = <&gpx2 2 1>;
+			linux,code = <171>;
+			label = "config";
+			debounce-interval = <1>;
+			gpio-key,wakeup;
+		};
+
+		camera-key {
+			gpios = <&gpx2 3 1>;
+			linux,code = <212>;
+			label = "camera";
+			debounce-interval = <1>;
+		};
+
+		power-key {
+			gpios = <&gpx2 7 1>;
+			linux,code = <116>;
+			label = "power";
+			debounce-interval = <1>;
+			gpio-key,wakeup;
+		};
+
+		ok-key {
+			gpios = <&gpx3 5 1>;
+			linux,code = <352>;
+			label = "ok";
+			debounce-interval = <1>;
+		};
+	};
+
+	tsp_reg: voltage-regulator {
+	        compatible = "regulator-fixed";
+		regulator-name = "TSP_2_8V";
+		regulator-min-microvolt = <2800000>;
+		regulator-max-microvolt = <2800000>;
+		gpio = <&gpe2 3 0>;
+		enable-active-high;
+	};
+
+	i2c at 13890000 {
+		samsung,i2c-sda-delay = <100>;
+		samsung,i2c-slave-addr = <0x10>;
+		samsung,i2c-max-bus-freq = <100000>;
+		pinctrl-0 = <&i2c3_bus>;
+		pinctrl-names = "default";
+		status = "okay";
+
+		tsp at 4a {
+			/* TBD: Atmel maXtouch touchscreen */
+			reg = <0x4a>;
+		};
+	};
+
+	i2c at 138B0000 {
+		samsung,i2c-sda-delay = <100>;
+		samsung,i2c-slave-addr = <0x10>;
+		samsung,i2c-max-bus-freq = <100000>;
+		pinctrl-0 = <&i2c5_bus>;
+		pinctrl-names = "default";
+		status = "okay";
+
+		vdd_arm_reg: pmic at 60 {
+			compatible = "maxim,max8952";
+			reg = <0x60>;
+
+			max8952,vid-gpios = <&gpx0 3 0>, <&gpx0 4 0>;
+			max8952,default-mode = <0>;
+			max8952,dvs-mode-microvolt = <1250000>, <1200000>,
+							<1050000>, <950000>;
+			max8952,sync-freq = <0>;
+			max8952,ramp-speed = <0>;
+
+			regulator-name = "vdd_arm";
+			regulator-min-microvolt = <770000>;
+			regulator-max-microvolt = <1400000>;
+			regulator-always-on;
+			regulator-boot-on;
+		};
+
+		pmic at 66 {
+			compatible = "national,lp3974";
+			reg = <0x66>;
+
+			max8998,pmic-buck1-default-dvs-idx = <0>;
+			max8998,pmic-buck1-dvs-gpios = <&gpx0 5 0>,
+							<&gpx0 6 0>;
+			max8998,pmic-buck1-dvs-voltage = <1100000>, <1000000>,
+							<1100000>, <1000000>;
+
+			max8998,pmic-buck2-default-dvs-idx = <0>;
+			max8998,pmic-buck2-dvs-gpio = <&gpe2 0 0>;
+			max8998,pmic-buck2-dvs-voltage = <1200000>, <1100000>;
+
+			regulators {
+				ldo2_reg: LDO2 {
+					regulator-name = "VALIVE_1.2V";
+					regulator-min-microvolt = <1200000>;
+					regulator-max-microvolt = <1200000>;
+					regulator-always-on;
+				};
+
+				ldo3_reg: LDO3 {
+					regulator-name = "VUSB+MIPI_1.1V";
+					regulator-min-microvolt = <1100000>;
+					regulator-max-microvolt = <1100000>;
+				};
+
+				ldo4_reg: LDO4 {
+					regulator-name = "VADC_3.3V";
+					regulator-min-microvolt = <3300000>;
+					regulator-max-microvolt = <3300000>;
+				};
+
+				ldo5_reg: LDO5 {
+					regulator-name = "VTF_2.8V";
+					regulator-min-microvolt = <2800000>;
+					regulator-max-microvolt = <2800000>;
+				};
+
+				ldo6_reg: LDO6 {
+					regulator-name = "LDO6";
+					regulator-min-microvolt = <2000000>;
+					regulator-max-microvolt = <2000000>;
+				};
+
+				ldo7_reg: LDO7 {
+					regulator-name = "VLCD+VMIPI_1.8V";
+					regulator-min-microvolt = <1800000>;
+					regulator-max-microvolt = <1800000>;
+				};
+
+				ldo8_reg: LDO8 {
+					regulator-name = "VUSB+VDAC_3.3V";
+					regulator-min-microvolt = <3300000>;
+					regulator-max-microvolt = <3300000>;
+				};
+
+				ldo9_reg: LDO9 {
+					regulator-name = "VCC_2.8V";
+					regulator-min-microvolt = <2800000>;
+					regulator-max-microvolt = <2800000>;
+					regulator-always-on;
+				};
+
+				ldo10_reg: LDO10 {
+					regulator-name = "VPLL_1.1V";
+					regulator-min-microvolt = <1100000>;
+					regulator-max-microvolt = <1100000>;
+					regulator-boot-on;
+					regulator-always-on;
+				};
+
+				ldo11_reg: LDO11 {
+					regulator-name = "CAM_AF_3.3V";
+					regulator-min-microvolt = <3300000>;
+					regulator-max-microvolt = <3300000>;
+				};
+
+				ldo12_reg: LDO12 {
+					regulator-name = "PS_2.8V";
+					regulator-min-microvolt = <2800000>;
+					regulator-max-microvolt = <2800000>;
+				};
+
+				ldo13_reg: LDO13 {
+					regulator-name = "VHIC_1.2V";
+					regulator-min-microvolt = <1200000>;
+					regulator-max-microvolt = <1200000>;
+				};
+
+				ldo14_reg: LDO14 {
+					regulator-name = "CAM_I_HOST_1.8V";
+					regulator-min-microvolt = <1800000>;
+					regulator-max-microvolt = <1800000>;
+				};
+
+				ldo15_reg: LDO15 {
+					regulator-name = "CAM_S_DIG+FM33_CORE_1.2V";
+					regulator-min-microvolt = <1200000>;
+					regulator-max-microvolt = <1200000>;
+				};
+
+				ldo16_reg: LDO16 {
+					regulator-name = "CAM_S_ANA_2.8V";
+					regulator-min-microvolt = <2800000>;
+					regulator-max-microvolt = <2800000>;
+				};
+
+				ldo17_reg: LDO17 {
+					regulator-name = "VCC_3.0V_LCD";
+					regulator-min-microvolt = <3000000>;
+					regulator-max-microvolt = <3000000>;
+				};
+
+				buck1_reg: BUCK1 {
+					regulator-name = "VINT_1.1V";
+					regulator-min-microvolt = <750000>;
+					regulator-max-microvolt = <1500000>;
+					regulator-boot-on;
+					regulator-always-on;
+				};
+
+				buck2_reg: BUCK2 {
+					regulator-name = "VG3D_1.1V";
+					regulator-min-microvolt = <750000>;
+					regulator-max-microvolt = <1500000>;
+					regulator-boot-on;
+				};
+
+				buck3_reg: BUCK3 {
+					regulator-name = "VCC_1.8V";
+					regulator-min-microvolt = <1800000>;
+					regulator-max-microvolt = <1800000>;
+					regulator-always-on;
+				};
+
+				buck4_reg: BUCK4 {
+					regulator-name = "VMEM_1.2V";
+					regulator-min-microvolt = <1200000>;
+					regulator-max-microvolt = <1200000>;
+					regulator-always-on;
+				};
+
+				ap32khz_reg: EN32KHz-AP {
+					regulator-name = "32KHz AP";
+					regulator-always-on;
+				};
+
+				cp32khz_reg: EN32KHz-CP {
+					regulator-name = "32KHz CP";
+				};
+
+				vichg_reg: ENVICHG {
+					regulator-name = "VICHG";
+				};
+
+				safeout1_reg: ESAFEOUT1 {
+					regulator-name = "SAFEOUT1";
+					regulator-always-on;
+				};
+
+				safeout2_reg: ESAFEOUT2 {
+					regulator-name = "SAFEOUT2";
+					regulator-boot-on;
+				};
+			};
+		};
+	};
+
+	pwm at 139D0000 {
+		compatible = "samsung,s5p6440-pwm";
+		status = "okay";
+	};
+};
-- 
1.8.2.1



From sergei.shtylyov at cogentembedded.com  Tue Apr 23 11:53:41 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Tue, 23 Apr 2013 19:53:41 +0400
Subject: [PATCH v5 0/3] Add USB support to R8A7778/BOCK-W
Message-ID: <201304231953.42505.sergei.shtylyov@cogentembedded.com>

Hello.

   Here's the set of 3 patches against the Simon Horman's 'renesas.git' repo,
'renesas-next-20130422' tag and the R8A7779/Marzen patchset I've posted.
 It was created to add support of R8A7778/BOCK-W USB to the platform code and
the USB common PHY driver, and so spans both arch/arm/mach-shmobile/ and
drivers/usb/phy/ subtrees.

[1/3] rcar-phy: add R8A7778 support
[2/3] ARM: shmobile: r8a7778: add USB support
[3/3] ARM: shmobile: BOCK-W: add USB support

The patch #4 (ARM: shmobile: BOCK-W: enable USB in defconfig) that has been
already merged, is not reposted.

WBR, Sergei


From arnd at arndb.de  Tue Apr 23 11:54:32 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 23 Apr 2013 17:54:32 +0200
Subject: [PATCH] usb: phy: phy core cannot yet be a module
In-Reply-To: <1366732475-479886-1-git-send-email-arnd@arndb.de>
References: <1366732475-479886-1-git-send-email-arnd@arndb.de>
Message-ID: <1366732475-479886-2-git-send-email-arnd@arndb.de>

A lot of platform code calls into the usb phy core at the moment, which
does not work if it is built as a loadable module. This will hopefully
change when those platforms are all converted to DT based probing,
but for now, the easiest solution is to change it from "tristate"
to "bool".

This solves at least these ARM allmodconfig build errors:

arch/arm/mach-imx/built-in.o: In function `imx_otg_ulpi_create':
arch/arm/mach-imx/ulpi.c:117: undefined reference to `otg_ulpi_create'
arch/arm/mach-omap2/built-in.o: In function `usbhs_init_phys':
arch/arm/mach-omap2/usb-host.c:652: undefined reference to `usb_bind_phy'
arch/arm/mach-omap2/built-in.o: In function `omap_2430sdp_init':
arch/arm/mach-omap2/board-2430sdp.c:236: undefined reference to `usb_bind_phy'
arch/arm/mach-omap2/built-in.o: In function `omap3_beagle_init':
arch/arm/mach-omap2/board-omap3beagle.c:554: undefined reference to `usb_bind_phy'
arch/arm/mach-omap2/built-in.o: In function `devkit8000_init':
arch/arm/mach-omap2/board-devkit8000.c:596: undefined reference to `usb_bind_phy'
arch/arm/mach-omap2/built-in.o: In function `omap_ldp_init':
arch/arm/mach-omap2/board-ldp.c:379: undefined reference to `usb_bind_phy'
drivers/built-in.o: In function `ab8500_charger_probe':
drivers/power/ab8500_charger.c:3629: undefined reference to `usb_get_phy'
drivers/power/ab8500_charger.c:3706: undefined reference to `usb_put_phy'
drivers/built-in.o: In function `ab8500_charger_remove':
drivers/power/ab8500_charger.c:3411: undefined reference to `usb_put_phy'

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Cc: Felipe Balbi <balbi at ti.com>
Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
Cc: linux-usb at vger.kernel.org
---
 drivers/usb/phy/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index 21153d1..371d0e7 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -2,7 +2,7 @@
 # Physical Layer USB driver configuration
 #
 menuconfig USB_PHY
-	tristate "USB Physical Layer drivers"
+	bool "USB Physical Layer drivers"
 	help
 	  USB controllers (those which are host, device or DRD) need a
 	  device to handle the physical layer signalling, commonly called
-- 
1.8.1.2



From arnd at arndb.de  Tue Apr 23 11:54:33 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 23 Apr 2013 17:54:33 +0200
Subject: [PATCH] ASoC: don't call of_dma_request_slave_channel directly
In-Reply-To: <1366732475-479886-1-git-send-email-arnd@arndb.de>
References: <1366732475-479886-1-git-send-email-arnd@arndb.de>
Message-ID: <1366732475-479886-3-git-send-email-arnd@arndb.de>

The exported interface for device drivers is dma_request_slave_channel,
not of_dma_request_slave_channel. The former does not depend on device
tree but also works with ACPI and other interfaces providing an
abstraction for DMA channels.

This fixes link errors when building ALSA as a loadable module.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Cc: alsa-devel at alsa-project.org
Cc: Lars-Peter Clausen <lars at metafoo.de>
Cc: Shawn Guo <shawn.guo at linaro.org>
Cc: Mark Brown <broonie at opensource.wolfsonmicro.com>
---
 sound/soc/soc-generic-dmaengine-pcm.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/sound/soc/soc-generic-dmaengine-pcm.c b/sound/soc/soc-generic-dmaengine-pcm.c
index 5fd5ed4..8ee9859 100644
--- a/sound/soc/soc-generic-dmaengine-pcm.c
+++ b/sound/soc/soc-generic-dmaengine-pcm.c
@@ -219,19 +219,20 @@ static const char * const dmaengine_pcm_dma_channel_names[] = {
 };
 
 static void dmaengine_pcm_request_chan_of(struct dmaengine_pcm *pcm,
-	struct device_node *of_node)
+	struct device *dev)
 {
 	unsigned int i;
+	struct device_node *of_node = dev->of_node;
 
 	if ((pcm->flags & SND_DMAENGINE_PCM_FLAG_NO_DT) || !of_node)
 		return;
 
 	if (pcm->flags & SND_DMAENGINE_PCM_FLAG_HALF_DUPLEX) {
-		pcm->chan[0] = of_dma_request_slave_channel(of_node, "tx_rx");
+		pcm->chan[0] = dma_request_slave_channel(dev, "tx_rx");
 		pcm->chan[1] = pcm->chan[0];
 	} else {
 		for (i = SNDRV_PCM_STREAM_PLAYBACK; i <= SNDRV_PCM_STREAM_CAPTURE; i++) {
-			pcm->chan[i] = of_dma_request_slave_channel(of_node,
+			pcm->chan[i] = dma_request_slave_channel(dev,
 					dmaengine_pcm_dma_channel_names[i]);
 		}
 	}
@@ -255,7 +256,7 @@ int snd_dmaengine_pcm_register(struct device *dev,
 	pcm->config = config;
 	pcm->flags = flags;
 
-	dmaengine_pcm_request_chan_of(pcm, dev->of_node);
+	dmaengine_pcm_request_chan_of(pcm, dev);
 
 	if (flags & SND_DMAENGINE_PCM_FLAG_NO_RESIDUE)
 		return snd_soc_add_platform(dev, &pcm->platform,
-- 
1.8.1.2



From arnd at arndb.de  Tue Apr 23 11:54:35 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 23 Apr 2013 17:54:35 +0200
Subject: [PATCH] clocksource: kona: adapt to CLOCKSOURCE_OF_DECLARE change
In-Reply-To: <1366732475-479886-1-git-send-email-arnd@arndb.de>
References: <1366732475-479886-1-git-send-email-arnd@arndb.de>
Message-ID: <1366732475-479886-5-git-send-email-arnd@arndb.de>

The CLOCKSOURCE_OF_DECLARE functions now take a device_node pointer
as their argument, as of the clksrc/cleanup branch in arm-soc.
This patch adapts the bcm_kona_timer driver to the new interface.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Cc: Christian Daudt <csd at broadcom.com>
Cc: John Stultz <john.stultz at linaro.org>
---
 drivers/clocksource/bcm_kona_timer.c | 15 ++++-----------
 1 file changed, 4 insertions(+), 11 deletions(-)

diff --git a/drivers/clocksource/bcm_kona_timer.c b/drivers/clocksource/bcm_kona_timer.c
index 350f493..ba3d859 100644
--- a/drivers/clocksource/bcm_kona_timer.c
+++ b/drivers/clocksource/bcm_kona_timer.c
@@ -103,16 +103,10 @@ static const struct of_device_id bcm_timer_ids[] __initconst = {
 	{},
 };
 
-static void __init kona_timers_init(void)
+static void __init kona_timers_init(struct device_node *node)
 {
-	struct device_node *node;
 	u32 freq;
 
-	node = of_find_matching_node(NULL, bcm_timer_ids);
-
-	if (!node)
-		panic("No timer");
-
 	if (!of_property_read_u32(node, "clock-frequency", &freq))
 		arch_timer_rate = freq;
 	else
@@ -199,13 +193,12 @@ static struct irqaction kona_timer_irq = {
 	.handler = kona_timer_interrupt,
 };
 
-static void __init kona_timer_init(void)
+static void __init kona_timer_init(struct device_node *node)
 {
-	kona_timers_init();
+	kona_timers_init(node);
 	kona_timer_clockevents_init();
 	setup_irq(timers.tmr_irq, &kona_timer_irq);
 	kona_timer_set_next_event((arch_timer_rate / HZ), NULL);
 }
 
-CLOCKSOURCE_OF_DECLARE(bcm_kona, "bcm,kona-timer",
-	kona_timer_init);
+CLOCKSOURCE_OF_DECLARE(bcm_kona, "bcm,kona-timer", kona_timer_init);
-- 
1.8.1.2



From arnd at arndb.de  Tue Apr 23 11:54:34 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 23 Apr 2013 17:54:34 +0200
Subject: [PATCH] hwrng: bcm2835: fix MODULE_LICENSE tag
In-Reply-To: <1366732475-479886-1-git-send-email-arnd@arndb.de>
References: <1366732475-479886-1-git-send-email-arnd@arndb.de>
Message-ID: <1366732475-479886-4-git-send-email-arnd@arndb.de>

The MODULE_LICENSE macro invocation must use either "GPL" or "GPL v2",
but not "GPLv2" in order to be detected by the module loader.

This fixes the allmodconfig build error:

FATAL: modpost: GPL-incompatible module bcm2835-rng.ko uses GPL-only symbol 'platform_driver_unregister'

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Cc: Dom Cobley <popcornmix at gmail.com>
Cc: Lubomir Rintel <lkundrak at v3.sk>
Cc: Stephen Warren <swarren at wwwdotorg.org>
Cc: Matt Mackall <mpm at selenic.com>
Cc: linux-rpi-kernel at lists.infradead.org
Cc: Herbert Xu <herbert at gondor.apana.org.au>
---
 drivers/char/hw_random/bcm2835-rng.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/char/hw_random/bcm2835-rng.c b/drivers/char/hw_random/bcm2835-rng.c
index eb7f147..43577ca 100644
--- a/drivers/char/hw_random/bcm2835-rng.c
+++ b/drivers/char/hw_random/bcm2835-rng.c
@@ -110,4 +110,4 @@ module_platform_driver(bcm2835_rng_driver);
 
 MODULE_AUTHOR("Lubomir Rintel <lkundrak at v3.sk>");
 MODULE_DESCRIPTION("BCM2835 Random Number Generator (RNG) driver");
-MODULE_LICENSE("GPLv2");
+MODULE_LICENSE("GPL v2");
-- 
1.8.1.2



From arnd at arndb.de  Tue Apr 23 11:54:31 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 23 Apr 2013 17:54:31 +0200
Subject: [PATCH] ARM: allmodconfig regressions in linux-next
Message-ID: <1366732475-479886-1-git-send-email-arnd@arndb.de>

Hi everyone,

These are a couple of simple patches to fix bugs that break allyesconfig
and that are only present in linux-next at the moment. Please apply
to the appropriate trees or provide feedback!

Arnd Bergmann (5):
  mfd: ab8500: remove broken ab8500_debug_register_interrupt logic
  usb: phy: phy core cannot yet be a module
  ASoC: don't call of_dma_request_slave_channel directly
  hwrng: bcm2835: fix MODULE_LICENSE tag
  clocksource: kona: adapt to CLOCKSOURCE_OF_DECLARE change

 drivers/char/hw_random/bcm2835-rng.c  |  2 +-
 drivers/clocksource/bcm_kona_timer.c  | 15 ++++-----------
 drivers/mfd/ab8500-debugfs.c          | 10 ----------
 drivers/usb/phy/Kconfig               |  2 +-
 sound/soc/soc-generic-dmaengine-pcm.c |  9 +++++----
 5 files changed, 11 insertions(+), 27 deletions(-)

Cc: Christian Daudt <csd at broadcom.com>
Cc: Dom Cobley <popcornmix at gmail.com>
Cc: Felipe Balbi <balbi at ti.com>
Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
Cc: Herbert Xu <herbert at gondor.apana.org.au>
Cc: John Stultz <john.stultz at linaro.org>
Cc: Jonas ABERG <jonas.aberg at stericsson.com>
Cc: Lars-Peter Clausen <lars at metafoo.de>
Cc: Lee Jones <lee.jones at linaro.org>
Cc: Linus Walleij <linus.walleij at stericsson.com>
Cc: Lubomir Rintel <lkundrak at v3.sk>
Cc: Mark Brown <broonie at opensource.wolfsonmicro.com>
Cc: Matt Mackall <mpm at selenic.com>
Cc: Mattias WALLIN <mattias.wallin at stericsson.com>
Cc: Per FORLIN <per.forlin at stericsson.com>
Cc: Samuel Ortiz <sameo at linux.intel.com>
Cc: Shawn Guo <shawn.guo at linaro.org>
Cc: Stephen Warren <swarren at wwwdotorg.org>
Cc: alsa-devel at alsa-project.org
Cc: linux-rpi-kernel at lists.infradead.org
Cc: linux-usb at vger.kernel.org
Cc: srinidhi kasagar <srinidhi.kasagar at stericsson.com>
-- 
1.8.1.2



From broonie at kernel.org  Tue Apr 23 11:56:30 2013
From: broonie at kernel.org (Mark Brown)
Date: Tue, 23 Apr 2013 16:56:30 +0100
Subject: [PATCH] ASoC: don't call of_dma_request_slave_channel directly
In-Reply-To: <1366732475-479886-3-git-send-email-arnd@arndb.de>
References: <1366732475-479886-1-git-send-email-arnd@arndb.de>
 <1366732475-479886-3-git-send-email-arnd@arndb.de>
Message-ID: <20130423155629.GS5019@opensource.wolfsonmicro.com>

On Tue, Apr 23, 2013 at 05:54:33PM +0200, Arnd Bergmann wrote:
> The exported interface for device drivers is dma_request_slave_channel,
> not of_dma_request_slave_channel. The former does not depend on device
> tree but also works with ACPI and other interfaces providing an
> abstraction for DMA channels.

> This fixes link errors when building ALSA as a loadable module.

This has already been changed separately, I'm surprised this applies
against current code.  Though one does have to wonder why it's in the
header file if it's not a supported API...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130423/81bf0488/attachment.sig>

From sergei.shtylyov at cogentembedded.com  Tue Apr 23 12:00:47 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Tue, 23 Apr 2013 20:00:47 +0400
Subject: [PATCH v5 2/3] ARM: shmobile: r8a7778: add USB support
In-Reply-To: <201304231953.42505.sergei.shtylyov@cogentembedded.com>
References: <201304231953.42505.sergei.shtylyov@cogentembedded.com>
Message-ID: <201304232000.47768.sergei.shtylyov@cogentembedded.com>

Add USB clock and EHCI, OHCI, and USB PHY platform devices for R8A7778 SoC;  add
a function to register PHY device with board-specific platform data and register
EHCI and OHCI platfrom devices from the init_late() board method.

Also,  don't forget to enable CONFIG_ARCH_HAS_[EO]HCI options for R8A7778 SoC in
Kconfig...

The patch has been tested on the BOCK-W board.

Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

---
Changes since version 4:
- annotated USB resources and '[eo]hci_info' as '__initdata' since they're
  kmemdup()'ed while registering the platform devices anyway;
- refreshed the patch.

Changes since version 3:
- resolved reject in the 'clock-r8a7778.c' file, refreshed the patch.

Changes since version 2:
- refreshed the patch.

Changes since the original posting:
- resolved rejects in the 'clock-r8a7778.c' file;
- lowercased the SoC name in the subject.

 arch/arm/mach-shmobile/Kconfig                |    2 
 arch/arm/mach-shmobile/clock-r8a7778.c        |    4 
 arch/arm/mach-shmobile/include/mach/r8a7778.h |    3 
 arch/arm/mach-shmobile/setup-r8a7778.c        |  108 ++++++++++++++++++++++++++
 4 files changed, 117 insertions(+)

Index: renesas/arch/arm/mach-shmobile/Kconfig
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/Kconfig
+++ renesas/arch/arm/mach-shmobile/Kconfig
@@ -41,6 +41,8 @@ config ARCH_R8A7778
 	select CPU_V7
 	select SH_CLK_CPG
 	select ARM_GIC
+	select USB_ARCH_HAS_EHCI
+	select USB_ARCH_HAS_OHCI
 
 config ARCH_R8A7779
 	bool "R-Car H1 (R8A77790)"
Index: renesas/arch/arm/mach-shmobile/clock-r8a7778.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/clock-r8a7778.c
+++ renesas/arch/arm/mach-shmobile/clock-r8a7778.c
@@ -105,6 +105,7 @@ static struct clk *main_clks[] = {
 enum {
 	MSTP323, MSTP322, MSTP321,
 	MSTP114,
+	MSTP100,
 	MSTP026, MSTP025, MSTP024, MSTP023, MSTP022, MSTP021,
 	MSTP016, MSTP015,
 	MSTP_NR };
@@ -114,6 +115,7 @@ static struct clk mstp_clks[MSTP_NR] = {
 	[MSTP322] = SH_CLK_MSTP32(&p_clk, MSTPCR3, 22, 0), /* SDHI1 */
 	[MSTP321] = SH_CLK_MSTP32(&p_clk, MSTPCR3, 21, 0), /* SDHI2 */
 	[MSTP114] = SH_CLK_MSTP32(&p_clk, MSTPCR1, 14, 0), /* Ether */
+	[MSTP100] = SH_CLK_MSTP32(&p_clk, MSTPCR1,  0, 0), /* USB0/1 */
 	[MSTP026] = SH_CLK_MSTP32(&p_clk, MSTPCR0, 26, 0), /* SCIF0 */
 	[MSTP025] = SH_CLK_MSTP32(&p_clk, MSTPCR0, 25, 0), /* SCIF1 */
 	[MSTP024] = SH_CLK_MSTP32(&p_clk, MSTPCR0, 24, 0), /* SCIF2 */
@@ -130,6 +132,8 @@ static struct clk_lookup lookups[] = {
 	CLKDEV_DEV_ID("sh_mobile_sdhi.1", &mstp_clks[MSTP322]), /* SDHI1 */
 	CLKDEV_DEV_ID("sh_mobile_sdhi.2", &mstp_clks[MSTP321]), /* SDHI2 */
 	CLKDEV_DEV_ID("sh-eth",	&mstp_clks[MSTP114]), /* Ether */
+	CLKDEV_DEV_ID("ehci-platform", &mstp_clks[MSTP100]), /* USB EHCI port0/1 */
+	CLKDEV_DEV_ID("ohci-platform", &mstp_clks[MSTP100]), /* USB OHCI port0/1 */
 	CLKDEV_DEV_ID("sh-sci.0", &mstp_clks[MSTP026]), /* SCIF0 */
 	CLKDEV_DEV_ID("sh-sci.1", &mstp_clks[MSTP025]), /* SCIF1 */
 	CLKDEV_DEV_ID("sh-sci.2", &mstp_clks[MSTP024]), /* SCIF2 */
Index: renesas/arch/arm/mach-shmobile/include/mach/r8a7778.h
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/include/mach/r8a7778.h
+++ renesas/arch/arm/mach-shmobile/include/mach/r8a7778.h
@@ -20,10 +20,13 @@
 
 #include <linux/mmc/sh_mobile_sdhi.h>
 #include <linux/sh_eth.h>
+#include <linux/usb/rcar-phy.h>
 
 extern void r8a7778_add_standard_devices(void);
 extern void r8a7778_add_standard_devices_dt(void);
 extern void r8a7778_add_ether_device(struct sh_eth_plat_data *pdata);
+extern void r8a7778_add_usb_phy_device(struct rcar_phy_platform_data *pdata);
+extern void r8a7778_init_late(void);
 extern void r8a7778_init_delay(void);
 extern void r8a7778_init_irq(void);
 extern void r8a7778_init_irq_dt(void);
Index: renesas/arch/arm/mach-shmobile/setup-r8a7778.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/setup-r8a7778.c
+++ renesas/arch/arm/mach-shmobile/setup-r8a7778.c
@@ -30,6 +30,12 @@
 #include <linux/irqchip.h>
 #include <linux/serial_sci.h>
 #include <linux/sh_timer.h>
+#include <linux/pm_runtime.h>
+#include <linux/usb/phy.h>
+#include <linux/usb/hcd.h>
+#include <linux/usb/ehci_pdriver.h>
+#include <linux/usb/ohci_pdriver.h>
+#include <linux/dma-mapping.h>
 #include <mach/irqs.h>
 #include <mach/r8a7778.h>
 #include <mach/common.h>
@@ -89,6 +95,99 @@ static struct sh_timer_config sh_tmu1_pl
 		&sh_tmu##idx##_platform_data,		\
 		sizeof(sh_tmu##idx##_platform_data))
 
+/* USB PHY */
+static struct resource usb_phy_resources[] __initdata = {
+	DEFINE_RES_MEM(0xffe70800, 0x100),
+	DEFINE_RES_MEM(0xffe76000, 0x100),
+};
+
+void __init r8a7778_add_usb_phy_device(struct rcar_phy_platform_data *pdata)
+{
+	platform_device_register_resndata(&platform_bus, "rcar_usb_phy", -1,
+					  usb_phy_resources,
+					  ARRAY_SIZE(usb_phy_resources),
+					  pdata, sizeof(*pdata));
+}
+
+/* USB */
+static struct usb_phy *phy;
+
+static int usb_power_on(struct platform_device *pdev)
+{
+	if (!phy)
+		return -EIO;
+
+	pm_runtime_enable(&pdev->dev);
+	pm_runtime_get_sync(&pdev->dev);
+
+	usb_phy_init(phy);
+
+	return 0;
+}
+
+static void usb_power_off(struct platform_device *pdev)
+{
+	if (!phy)
+		return;
+
+	usb_phy_shutdown(phy);
+
+	pm_runtime_put_sync(&pdev->dev);
+	pm_runtime_disable(&pdev->dev);
+}
+
+static int ehci_init_internal_buffer(struct usb_hcd *hcd)
+{
+	/*
+	 * Below are recommended values from the datasheet;
+	 * see [USB :: Setting of EHCI Internal Buffer].
+	 */
+	/* EHCI IP internal buffer setting */
+	iowrite32(0x00ff0040, hcd->regs + 0x0094);
+	/* EHCI IP internal buffer enable */
+	iowrite32(0x00000001, hcd->regs + 0x009C);
+
+	return 0;
+}
+
+static struct usb_ehci_pdata ehci_pdata __initdata = {
+	.power_on	= usb_power_on,
+	.power_off	= usb_power_off,
+	.power_suspend	= usb_power_off,
+	.pre_setup	= ehci_init_internal_buffer,
+};
+
+static struct resource ehci_resources[] __initdata = {
+	DEFINE_RES_MEM(0xffe70000, 0x400),
+	DEFINE_RES_IRQ(gic_iid(0x4c)),
+};
+
+static struct usb_ohci_pdata ohci_pdata __initdata = {
+	.power_on	= usb_power_on,
+	.power_off	= usb_power_off,
+	.power_suspend	= usb_power_off,
+};
+
+static struct resource ohci_resources[] __initdata = {
+	DEFINE_RES_MEM(0xffe70400, 0x400),
+	DEFINE_RES_IRQ(gic_iid(0x4c)),
+};
+
+#define USB_PLATFORM_INFO(hci)					\
+static struct platform_device_info hci##_info __initdata = {	\
+	.parent		= &platform_bus,			\
+	.name		= #hci "-platform",			\
+	.id		= -1,					\
+	.res		= hci##_resources,			\
+	.num_res	= ARRAY_SIZE(hci##_resources),		\
+	.data		= &hci##_pdata,				\
+	.size_data	= sizeof(hci##_pdata),			\
+	.dma_mask	= DMA_BIT_MASK(32),			\
+}
+
+USB_PLATFORM_INFO(ehci);
+USB_PLATFORM_INFO(ohci);
+
 /* Ether */
 static struct resource ether_resources[] = {
 	DEFINE_RES_MEM(0xfde00000, 0x400),
@@ -197,6 +296,14 @@ void __init r8a7778_add_standard_devices
 	r8a7778_register_tmu(1);
 }
 
+void __init r8a7778_init_late(void)
+{
+	phy = usb_get_phy(USB_PHY_TYPE_USB2);
+
+	platform_device_register_full(&ehci_info);
+	platform_device_register_full(&ohci_info);
+}
+
 static struct renesas_intc_irqpin_config irqpin_platform_data = {
 	.irq_base = irq_pin(0), /* IRQ0 -> IRQ3 */
 	.sense_bitfield_width = 2,
@@ -310,6 +417,7 @@ DT_MACHINE_START(R8A7778_DT, "Generic R8
 	.init_machine	= r8a7778_add_standard_devices_dt,
 	.init_time	= shmobile_timer_init,
 	.dt_compat	= r8a7778_compat_dt,
+	.init_late      = r8a7778_init_late,
 MACHINE_END
 
 #endif /* CONFIG_USE_OF */


From sergei.shtylyov at cogentembedded.com  Tue Apr 23 12:03:41 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Tue, 23 Apr 2013 20:03:41 +0400
Subject: [PATCH v5 3/3] ARM: shmobile: BOCK-W: add USB support
In-Reply-To: <201304231953.42505.sergei.shtylyov@cogentembedded.com>
References: <201304231953.42505.sergei.shtylyov@cogentembedded.com>
Message-ID: <201304232003.41838.sergei.shtylyov@cogentembedded.com>

Register the USB PHY device from bockw_init(), passing the platform  data to it.
Set machine's init_late() method to r8a7778_init_late() in order for [EO]HCI to
get registered too...

The patch has been tested on the BOCK-W board.

Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

---
Changes since version 4:
- annotated 'usb_phy_platform_data' as '__initdata' since it's kmemdup()'ed
  while registering the platform device anyway;
- refreshed the patch.

Changes since version 3:
- removed initializer for 'usb_phy_platform_data' letting it be set to all 0s;
- refreshed the patch.

Changes since version 2:
- refreshed the patch.

Changes since the original posting:
- removed initializer for no longer existing field in 'usb_phy_platform_data',
  modified the comment to the 'ferrite_bead' field initializer.

 arch/arm/mach-shmobile/board-bockw.c |    4 ++++
 1 file changed, 4 insertions(+)

Index: renesas/arch/arm/mach-shmobile/board-bockw.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/board-bockw.c
+++ renesas/arch/arm/mach-shmobile/board-bockw.c
@@ -63,6 +63,8 @@ static struct sh_mobile_sdhi_info sdhi0_
 	.tmio_flags	= TMIO_MMC_HAS_IDLE_WAIT,
 };
 
+static struct rcar_phy_platform_data usb_phy_platform_data __initdata;
+
 static const struct pinctrl_map bockw_pinctrl_map[] = {
 	/* SCIF0 */
 	PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.0", "pfc-r8a7778",
@@ -91,6 +93,7 @@ static void __init bockw_init(void)
 	r8a7778_clock_init();
 	r8a7778_init_irq_extpin(1);
 	r8a7778_add_standard_devices();
+	r8a7778_add_usb_phy_device(&usb_phy_platform_data);
 
 	pinctrl_register_mappings(bockw_pinctrl_map,
 				  ARRAY_SIZE(bockw_pinctrl_map));
@@ -146,4 +149,5 @@ DT_MACHINE_START(BOCKW_DT, "bockw")
 	.init_machine	= bockw_init,
 	.init_time	= shmobile_timer_init,
 	.dt_compat	= bockw_boards_compat_dt,
+	.init_late      = r8a7778_init_late,
 MACHINE_END


From balbi at ti.com  Tue Apr 23 12:07:59 2013
From: balbi at ti.com (Felipe Balbi)
Date: Tue, 23 Apr 2013 19:07:59 +0300
Subject: [PATCH] usb: phy: phy core cannot yet be a module
In-Reply-To: <1366732475-479886-2-git-send-email-arnd@arndb.de>
References: <1366732475-479886-1-git-send-email-arnd@arndb.de>
 <1366732475-479886-2-git-send-email-arnd@arndb.de>
Message-ID: <20130423160759.GF15177@arwen.pp.htv.fi>

Hi,

On Tue, Apr 23, 2013 at 05:54:32PM +0200, Arnd Bergmann wrote:
> A lot of platform code calls into the usb phy core at the moment, which
> does not work if it is built as a loadable module. This will hopefully
> change when those platforms are all converted to DT based probing,
> but for now, the easiest solution is to change it from "tristate"
> to "bool".
> 
> This solves at least these ARM allmodconfig build errors:
> 
> arch/arm/mach-imx/built-in.o: In function `imx_otg_ulpi_create':
> arch/arm/mach-imx/ulpi.c:117: undefined reference to `otg_ulpi_create'
> arch/arm/mach-omap2/built-in.o: In function `usbhs_init_phys':
> arch/arm/mach-omap2/usb-host.c:652: undefined reference to `usb_bind_phy'
> arch/arm/mach-omap2/built-in.o: In function `omap_2430sdp_init':
> arch/arm/mach-omap2/board-2430sdp.c:236: undefined reference to `usb_bind_phy'
> arch/arm/mach-omap2/built-in.o: In function `omap3_beagle_init':
> arch/arm/mach-omap2/board-omap3beagle.c:554: undefined reference to `usb_bind_phy'
> arch/arm/mach-omap2/built-in.o: In function `devkit8000_init':
> arch/arm/mach-omap2/board-devkit8000.c:596: undefined reference to `usb_bind_phy'
> arch/arm/mach-omap2/built-in.o: In function `omap_ldp_init':
> arch/arm/mach-omap2/board-ldp.c:379: undefined reference to `usb_bind_phy'
> drivers/built-in.o: In function `ab8500_charger_probe':
> drivers/power/ab8500_charger.c:3629: undefined reference to `usb_get_phy'
> drivers/power/ab8500_charger.c:3706: undefined reference to `usb_put_phy'
> drivers/built-in.o: In function `ab8500_charger_remove':
> drivers/power/ab8500_charger.c:3411: undefined reference to `usb_put_phy'
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Cc: Felipe Balbi <balbi at ti.com>
> Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
> Cc: linux-usb at vger.kernel.org
> ---
>  drivers/usb/phy/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
> index 21153d1..371d0e7 100644
> --- a/drivers/usb/phy/Kconfig
> +++ b/drivers/usb/phy/Kconfig
> @@ -2,7 +2,7 @@
>  # Physical Layer USB driver configuration
>  #
>  menuconfig USB_PHY
> -	tristate "USB Physical Layer drivers"
> +	bool "USB Physical Layer drivers"

looks like this is the only way, indeed. Do you need on the merge window
on can this wait until -rc1 ? I just sent a pull request to Greg with
urgent fixes for the merge window.

Greg, if you want to take this one as a patch, go for it:

Acked-by: Felipe Balbi <balbi at ti.com>

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130423/036f247a/attachment.sig>

From arnd at arndb.de  Tue Apr 23 12:11:35 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 23 Apr 2013 18:11:35 +0200
Subject: [PATCH] usb: phy: phy core cannot yet be a module
In-Reply-To: <20130423160759.GF15177@arwen.pp.htv.fi>
References: <1366732475-479886-1-git-send-email-arnd@arndb.de>
 <1366732475-479886-2-git-send-email-arnd@arndb.de>
 <20130423160759.GF15177@arwen.pp.htv.fi>
Message-ID: <201304231811.35692.arnd@arndb.de>

On Tuesday 23 April 2013, Felipe Balbi wrote:
> looks like this is the only way, indeed. Do you need on the merge window
> on can this wait until -rc1 ? I just sent a pull request to Greg with
> urgent fixes for the merge window.
> 
> Greg, if you want to take this one as a patch, go for it:
> 
> Acked-by: Felipe Balbi <balbi at ti.com>

It's not relevant for real-life scenarios, it's fine as long as this
makes it into 3.10.

	Arnd


From balbi at ti.com  Tue Apr 23 12:12:25 2013
From: balbi at ti.com (Felipe Balbi)
Date: Tue, 23 Apr 2013 19:12:25 +0300
Subject: [PATCH] usb: phy: phy core cannot yet be a module
In-Reply-To: <201304231811.35692.arnd@arndb.de>
References: <1366732475-479886-1-git-send-email-arnd@arndb.de>
 <1366732475-479886-2-git-send-email-arnd@arndb.de>
 <20130423160759.GF15177@arwen.pp.htv.fi>
 <201304231811.35692.arnd@arndb.de>
Message-ID: <20130423161225.GH15177@arwen.pp.htv.fi>

Hi,

On Tue, Apr 23, 2013 at 06:11:35PM +0200, Arnd Bergmann wrote:
> On Tuesday 23 April 2013, Felipe Balbi wrote:
> > looks like this is the only way, indeed. Do you need on the merge window
> > on can this wait until -rc1 ? I just sent a pull request to Greg with
> > urgent fixes for the merge window.
> > 
> > Greg, if you want to take this one as a patch, go for it:
> > 
> > Acked-by: Felipe Balbi <balbi at ti.com>
> 
> It's not relevant for real-life scenarios, it's fine as long as this
> makes it into 3.10.

sure, I can take this on -rc1 then.

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130423/4b0bef5f/attachment-0001.sig>

From sergei.shtylyov at cogentembedded.com  Tue Apr 23 12:12:57 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Tue, 23 Apr 2013 20:12:57 +0400
Subject: [PATCH v3 0/1] Add I2C support to R8A7778/BOCK-W
Message-ID: <201304232012.57619.sergei.shtylyov@cogentembedded.com>

Hello.

   Here's the patch against the Simon Horman's 'renesas.git' repo,
'renesas-next-20130422' tag and my recent yet unapplied USB patches.
Here we add I2C support to the R8A7778 platform code. This will be
important in the future for the VIN driver since the video decoder chip is
controlled via I2C bus #0 on BOCK-W. 

[1/1] ARM: shmobile: r8a7778: add I2C support

The patch #2 (ARM: shmobile: BOCK-W: enable I2C in defconfig) has been
already merged, and so not reposted.

WBR, Sergei


From sergei.shtylyov at cogentembedded.com  Tue Apr 23 12:15:59 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Tue, 23 Apr 2013 20:15:59 +0400
Subject: [PATCH v3 1/1] ARM: shmobile: r8a7778: add I2C support
In-Reply-To: <201304232012.57619.sergei.shtylyov@cogentembedded.com>
References: <201304232012.57619.sergei.shtylyov@cogentembedded.com>
Message-ID: <201304232015.59697.sergei.shtylyov@cogentembedded.com>

From: Vladimir Barinov <vladimir.barinov at cogentembedded.com>

Add I2C clocks and platform devices for R8A7778 SoC.
Don't forget to also add the peripheral clock which the I2C driver uses.

Signed-off-by: Vladimir Barinov <vladimir.barinov at cogentembedded.com>
[Sergei: changed the registration function to platform_device_register_simple(),
annotated I2C resources as '__initdata', regrouped MSTPxxx *enum* members, added
the copyright.]
Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>

---
Changes since version 2:
- annotated I2C resources as '__initdata' since they're kmemdup()'ed while
  registering the platform devices anyway;
- refreshed the patch.

Changes since the original posting:
- regrouped MSTPxxx *enum* members;
- resolved reject in the 'clock-r8a7778.c' file, refreshed the patch;
- added an ACK from Kuninori Morimoto.

 arch/arm/mach-shmobile/clock-r8a7778.c |   14 +++++++++++++-
 arch/arm/mach-shmobile/setup-r8a7778.c |   32 ++++++++++++++++++++++++++++++++
 2 files changed, 45 insertions(+), 1 deletion(-)

Index: renesas/arch/arm/mach-shmobile/clock-r8a7778.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/clock-r8a7778.c
+++ renesas/arch/arm/mach-shmobile/clock-r8a7778.c
@@ -3,6 +3,7 @@
  *
  * Copyright (C) 2013  Renesas Solutions Corp.
  * Copyright (C) 2013  Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
+ * Copyright (C) 2013  Cogent Embedded, Inc.
  *
  * based on r8a7779
  *
@@ -106,7 +107,8 @@ enum {
 	MSTP323, MSTP322, MSTP321,
 	MSTP114,
 	MSTP100,
-	MSTP026, MSTP025, MSTP024, MSTP023, MSTP022, MSTP021,
+	MSTP030, MSTP029,
+	MSTP028, MSTP027, MSTP026, MSTP025, MSTP024, MSTP023, MSTP022, MSTP021,
 	MSTP016, MSTP015,
 	MSTP_NR };
 
@@ -116,6 +118,10 @@ static struct clk mstp_clks[MSTP_NR] = {
 	[MSTP321] = SH_CLK_MSTP32(&p_clk, MSTPCR3, 21, 0), /* SDHI2 */
 	[MSTP114] = SH_CLK_MSTP32(&p_clk, MSTPCR1, 14, 0), /* Ether */
 	[MSTP100] = SH_CLK_MSTP32(&p_clk, MSTPCR1,  0, 0), /* USB0/1 */
+	[MSTP030] = SH_CLK_MSTP32(&p_clk, MSTPCR0, 30, 0), /* I2C0 */
+	[MSTP029] = SH_CLK_MSTP32(&p_clk, MSTPCR0, 29, 0), /* I2C1 */
+	[MSTP028] = SH_CLK_MSTP32(&p_clk, MSTPCR0, 28, 0), /* I2C2 */
+	[MSTP027] = SH_CLK_MSTP32(&p_clk, MSTPCR0, 27, 0), /* I2C3 */
 	[MSTP026] = SH_CLK_MSTP32(&p_clk, MSTPCR0, 26, 0), /* SCIF0 */
 	[MSTP025] = SH_CLK_MSTP32(&p_clk, MSTPCR0, 25, 0), /* SCIF1 */
 	[MSTP024] = SH_CLK_MSTP32(&p_clk, MSTPCR0, 24, 0), /* SCIF2 */
@@ -127,6 +133,8 @@ static struct clk mstp_clks[MSTP_NR] = {
 };
 
 static struct clk_lookup lookups[] = {
+	CLKDEV_CON_ID("peripheral_clk", &p_clk),
+
 	/* MSTP32 clocks */
 	CLKDEV_DEV_ID("sh_mobile_sdhi.0", &mstp_clks[MSTP323]), /* SDHI0 */
 	CLKDEV_DEV_ID("sh_mobile_sdhi.1", &mstp_clks[MSTP322]), /* SDHI1 */
@@ -134,6 +142,10 @@ static struct clk_lookup lookups[] = {
 	CLKDEV_DEV_ID("sh-eth",	&mstp_clks[MSTP114]), /* Ether */
 	CLKDEV_DEV_ID("ehci-platform", &mstp_clks[MSTP100]), /* USB EHCI port0/1 */
 	CLKDEV_DEV_ID("ohci-platform", &mstp_clks[MSTP100]), /* USB OHCI port0/1 */
+	CLKDEV_DEV_ID("i2c-rcar.0", &mstp_clks[MSTP030]), /* I2C0 */
+	CLKDEV_DEV_ID("i2c-rcar.1", &mstp_clks[MSTP029]), /* I2C1 */
+	CLKDEV_DEV_ID("i2c-rcar.2", &mstp_clks[MSTP028]), /* I2C2 */
+	CLKDEV_DEV_ID("i2c-rcar.3", &mstp_clks[MSTP027]), /* I2C3 */
 	CLKDEV_DEV_ID("sh-sci.0", &mstp_clks[MSTP026]), /* SCIF0 */
 	CLKDEV_DEV_ID("sh-sci.1", &mstp_clks[MSTP025]), /* SCIF1 */
 	CLKDEV_DEV_ID("sh-sci.2", &mstp_clks[MSTP024]), /* SCIF2 */
Index: renesas/arch/arm/mach-shmobile/setup-r8a7778.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/setup-r8a7778.c
+++ renesas/arch/arm/mach-shmobile/setup-r8a7778.c
@@ -95,6 +95,33 @@ static struct sh_timer_config sh_tmu1_pl
 		&sh_tmu##idx##_platform_data,		\
 		sizeof(sh_tmu##idx##_platform_data))
 
+/* I2C */
+static struct resource i2c0_resources[] __initdata = {
+	DEFINE_RES_MEM(0xffc70000, 0x1000),
+	DEFINE_RES_IRQ(gic_iid(0x63)),
+};
+
+static struct resource i2c1_resources[] __initdata = {
+	DEFINE_RES_MEM(0xffc71000, 0x1000),
+	DEFINE_RES_IRQ(gic_iid(0x6e)),
+};
+
+static struct resource i2c2_resources[] __initdata = {
+	DEFINE_RES_MEM(0xffc72000, 0x1000),
+	DEFINE_RES_IRQ(gic_iid(0x6c)),
+};
+
+static struct resource i2c3_resources[] __initdata = {
+	DEFINE_RES_MEM(0xffc73000, 0x1000),
+	DEFINE_RES_IRQ(gic_iid(0x6d)),
+};
+
+#define r8a7778_register_i2c(idx)			\
+	platform_device_register_simple(		\
+		"i2c-rcar", idx,			\
+		i2c##idx##_resources,			\
+		ARRAY_SIZE(i2c##idx##_resources))
+
 /* USB PHY */
 static struct resource usb_phy_resources[] __initdata = {
 	DEFINE_RES_MEM(0xffe70800, 0x100),
@@ -294,6 +321,11 @@ void __init r8a7778_add_standard_devices
 
 	r8a7778_register_tmu(0);
 	r8a7778_register_tmu(1);
+
+	r8a7778_register_i2c(0);
+	r8a7778_register_i2c(1);
+	r8a7778_register_i2c(2);
+	r8a7778_register_i2c(3);
 }
 
 void __init r8a7778_init_late(void)


From kgene.kim at samsung.com  Tue Apr 23 12:19:37 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Wed, 24 Apr 2013 01:19:37 +0900
Subject: [GIT PULL] Late Exynos stuff for v3.10
Message-ID: <5176B499.1000208@samsung.com>

The following changes since commit 58a7bbf75442ea439a4d3b7993ad87023e406063:

   ARM: dts: add PDMA0 changes for exynos5440 (2013-04-09 01:39:27 +0900)

are available in the git repository at:

   git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git 
tags/late-exynos-for-v3.10

for you to fetch changes up to 9007025f3438ec3bdea02439e760585345102b8d:

   ARM: dts: Disable the RTC by default on exynos5 (2013-04-24 00:32:28 
+0900)

----------------------------------------------------------------
This includes late exynos stuff for v3.10 1) keypad for smdk4412 and 
origen4412 boards 2) adds mfc clock entries for exynos4 3) enables 
usb2phy, usb3phy and dwc3-exynos for exynos5250 4) enables tmu for 
exynos4210 5) support chip id with dt

----------------------------------------------------------------
Doug Anderson (1):
       ARM: dts: Disable the RTC by default on exynos5

Girish K S (1):
       ARM: EXYNOS: force MAC ip to 32bit DMA

Sachin Kamat (7):
       ARM: dts: Remove keypad entries from exynos4x12-pinctrl.dtsi
       ARM: dts: Add keypad entries to Exynos4412 based Origen
       ARM: dts: Add keypad entries to SMDK4412
       ARM: dts: Add MFC clock entries for exynos4
       ARM: dts: Update MFC documentation for clock entries
       ARM: dts: Add TMU clock entries to exynos4210.dtsi
       ARM: dts: Enable TMU on Origen4210 board

Thomas Abraham (4):
       ARM: dts: add mshc controller node for Exynos4x12 SoCs
       ARM: EXYNOS: Add a platform bus notifier to set dma masks for 
Exynos5440
       ARM: EXYNOS: Create virtual I/O mapping for Chip-ID controller 
using device tree
       ARM: dts: Add chip-id controller node on Exynos4/5 SoC

Vivek Gautam (5):
       ARM: dts: Enabling samsung-usb2phy driver for exynos5250
       ARM: dts: Enabling samsung-usb3phy driver for exynos5250
       ARM: dts: Add device tree bindings for dwc3-exynos
       ARM: dts: Enabling dwc3-exynos driver for exynos5250
       ARM: EXYNOS: Enable XHCI support on exynos5

  .../devicetree/bindings/media/s5p-mfc.txt          |  5 ++
  .../devicetree/bindings/usb/exynos-usb.txt         | 34 +++++++++
  arch/arm/boot/dts/exynos4.dtsi                     |  7 ++
  arch/arm/boot/dts/exynos4210-origen.dts            |  4 +
  arch/arm/boot/dts/exynos4210.dtsi                  |  3 +
  arch/arm/boot/dts/exynos4412-origen.dts            | 62 +++++++++++++++
  arch/arm/boot/dts/exynos4412-smdk4412.dts          | 87 
++++++++++++++++++++++
  arch/arm/boot/dts/exynos4412.dtsi                  |  8 ++
  arch/arm/boot/dts/exynos4x12-pinctrl.dtsi          | 56 --------------
  arch/arm/boot/dts/exynos5250.dtsi                  | 51 +++++++++++++
  arch/arm/boot/dts/exynos5440.dtsi                  |  1 +
  arch/arm/mach-exynos/Kconfig                       |  1 +
  arch/arm/mach-exynos/common.c                      | 53 +++++++------
  arch/arm/mach-exynos/include/mach/map.h            |  1 -
  arch/arm/mach-exynos/mach-exynos5-dt.c             | 28 +++++++
  15 files changed, 321 insertions(+), 80 deletions(-)

Hi Arnd and Olof,

As I said, last my pull-request at 4/10 included most of above changes. 
So would be nice if you could pull this and small patches added on top 
of that though.

If any problems, please kindly let me know.

Thanks.

- Kukjin


From gregkh at linuxfoundation.org  Tue Apr 23 12:26:04 2013
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Tue, 23 Apr 2013 09:26:04 -0700
Subject: [PATCH] usb: phy: phy core cannot yet be a module
In-Reply-To: <20130423160759.GF15177@arwen.pp.htv.fi>
References: <1366732475-479886-1-git-send-email-arnd@arndb.de>
 <1366732475-479886-2-git-send-email-arnd@arndb.de>
 <20130423160759.GF15177@arwen.pp.htv.fi>
Message-ID: <20130423162604.GA6983@kroah.com>

On Tue, Apr 23, 2013 at 07:07:59PM +0300, Felipe Balbi wrote:
> Hi,
> 
> On Tue, Apr 23, 2013 at 05:54:32PM +0200, Arnd Bergmann wrote:
> > A lot of platform code calls into the usb phy core at the moment, which
> > does not work if it is built as a loadable module. This will hopefully
> > change when those platforms are all converted to DT based probing,
> > but for now, the easiest solution is to change it from "tristate"
> > to "bool".
> > 
> > This solves at least these ARM allmodconfig build errors:
> > 
> > arch/arm/mach-imx/built-in.o: In function `imx_otg_ulpi_create':
> > arch/arm/mach-imx/ulpi.c:117: undefined reference to `otg_ulpi_create'
> > arch/arm/mach-omap2/built-in.o: In function `usbhs_init_phys':
> > arch/arm/mach-omap2/usb-host.c:652: undefined reference to `usb_bind_phy'
> > arch/arm/mach-omap2/built-in.o: In function `omap_2430sdp_init':
> > arch/arm/mach-omap2/board-2430sdp.c:236: undefined reference to `usb_bind_phy'
> > arch/arm/mach-omap2/built-in.o: In function `omap3_beagle_init':
> > arch/arm/mach-omap2/board-omap3beagle.c:554: undefined reference to `usb_bind_phy'
> > arch/arm/mach-omap2/built-in.o: In function `devkit8000_init':
> > arch/arm/mach-omap2/board-devkit8000.c:596: undefined reference to `usb_bind_phy'
> > arch/arm/mach-omap2/built-in.o: In function `omap_ldp_init':
> > arch/arm/mach-omap2/board-ldp.c:379: undefined reference to `usb_bind_phy'
> > drivers/built-in.o: In function `ab8500_charger_probe':
> > drivers/power/ab8500_charger.c:3629: undefined reference to `usb_get_phy'
> > drivers/power/ab8500_charger.c:3706: undefined reference to `usb_put_phy'
> > drivers/built-in.o: In function `ab8500_charger_remove':
> > drivers/power/ab8500_charger.c:3411: undefined reference to `usb_put_phy'
> > 
> > Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> > Cc: Felipe Balbi <balbi at ti.com>
> > Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
> > Cc: linux-usb at vger.kernel.org
> > ---
> >  drivers/usb/phy/Kconfig | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
> > index 21153d1..371d0e7 100644
> > --- a/drivers/usb/phy/Kconfig
> > +++ b/drivers/usb/phy/Kconfig
> > @@ -2,7 +2,7 @@
> >  # Physical Layer USB driver configuration
> >  #
> >  menuconfig USB_PHY
> > -	tristate "USB Physical Layer drivers"
> > +	bool "USB Physical Layer drivers"
> 
> looks like this is the only way, indeed. Do you need on the merge window
> on can this wait until -rc1 ? I just sent a pull request to Greg with
> urgent fixes for the merge window.
> 
> Greg, if you want to take this one as a patch, go for it:
> 
> Acked-by: Felipe Balbi <balbi at ti.com>

I'll take this now, thanks.

greg k-h


From dave.martin at linaro.org  Tue Apr 23 12:28:07 2013
From: dave.martin at linaro.org (Dave Martin)
Date: Tue, 23 Apr 2013 17:28:07 +0100
Subject: [RFC PATCH] drivers: bus: add ARM CCI support
In-Reply-To: <1366725128.8473.21.camel@computer5.home>
References: <1365691679-28674-1-git-send-email-lorenzo.pieralisi@arm.com>
 <1365691679-28674-2-git-send-email-lorenzo.pieralisi@arm.com>
 <1366725128.8473.21.camel@computer5.home>
Message-ID: <20130423162807.GA2461@linaro.org>

On Tue, Apr 23, 2013 at 02:52:08PM +0100, Jon Medhurst (Tixy) wrote:
> On Thu, 2013-04-11 at 15:47 +0100, Lorenzo Pieralisi wrote:
> [...]

[...]

> > diff --git a/drivers/bus/arm-cci.c b/drivers/bus/arm-cci.c
> > +/*
> > + * cci_port_control()
> > + *	@port = index of the port to setup
> > + *	@enable = if true enables the port, if false disables it
> > + */
> > +static void notrace cci_port_control(unsigned int port, bool enable)
> > +{
> > +	void __iomem *base = ports[port].base;
> > +
> > +	if (!base)
> > +		return;
> > +
> > +	writel_relaxed(enable, base + CCI_PORT_CTRL);
> 
> If enable is bool (0 or 1) then this is going to set snoops as specified
> but is always going to clear DVM broadcast as that is controlled by bit1
> of the register. So, does the API need specifying different to allow the
> caller to choose DVM state as well, or does this function need to assume
> DVM and snoops state should be equal? I.e.
> 
> 	writel_relaxed(enable ? 0x3 : 0x0, base + CCI_PORT_CTRL);

Some #defines for that magic "3" would be a good idea too.  Ultimately we
may want independent control over snoops and DVM, but I think that could
be done later as an extension to the code, if needed.  We don't expect
there to be a large number of callers for this code...

Cheers
---Dave



From systemprogrammierung.brunner at gmail.com  Tue Apr 23 12:18:47 2013
From: systemprogrammierung.brunner at gmail.com (Markus Brunner)
Date: Tue, 23 Apr 2013 18:18:47 +0200
Subject: [PATCH] remove vlan tags in CPSW dual emac mode
Message-ID: <4699400.vD3TdgH1nR@localhost>

If operating in dual emac mode all packets sent by the CPSW contain vlan headers with the reserved VID 0, 
which gets stripped away by all somewhat recent Linux versions. Operating systems without that behaviour will fail to communicate. 
This patch fixes that behaviour by disabling the VLAN_AWARE mode as already described by the comment above.

Signed-off-by: Markus Brunner <systemprogrammierung.brunner at gmail.com>
Tested-by: Mark Jackson <mpfj at newflow.co.uk>

---
--- linux-3.9-rc8.orig/drivers/net/ethernet/ti/cpsw.c	2013-04-23 17:26:11.000000000 +0200
+++ linux-3.9-rc8/drivers/net/ethernet/ti/cpsw.c	2013-04-23 17:36:25.000000000 +0200
@@ -751,9 +751,9 @@ static void cpsw_init_host_port(struct c
 	/* switch to vlan unaware mode */
 	cpsw_ale_control_set(priv->ale, priv->host_port, ALE_VLAN_AWARE,
 			     CPSW_ALE_VLAN_AWARE);
 	control_reg = readl(&priv->regs->control);
-	control_reg |= CPSW_VLAN_AWARE;
+	control_reg &= ~CPSW_VLAN_AWARE;
 	writel(control_reg, &priv->regs->control);
 	fifo_mode = (priv->data.dual_emac) ? CPSW_FIFO_DUAL_MAC_MODE :
 		     CPSW_FIFO_NORMAL_MODE;
 	writel(fifo_mode, &priv->host_port_regs->tx_in_ctl);


From arnd at arndb.de  Tue Apr 23 12:30:33 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 23 Apr 2013 18:30:33 +0200
Subject: [PATCH 01/21] Turn off -Wmaybe-uninitialized when building with -Os
In-Reply-To: <1366734653-488286-1-git-send-email-arnd@arndb.de>
References: <1366734653-488286-1-git-send-email-arnd@arndb.de>
Message-ID: <1366734653-488286-2-git-send-email-arnd@arndb.de>

gcc-4.7 and higher add a lot of false positive warnings about
potential uses of uninitialized warnings, but only when optimizing
for size (-Os). This is the default when building allyesconfig,
which turns on CONFIG_CC_OPTIMIZE_FOR_SIZE.

In order to avoid getting a lot of patches that initialize such
variables and accidentally hide real errors along the way, let's
just turn off this warning on the respective gcc versions
when building with size optimizations. The -Wmaybe-uninitialized
option was introduced in the same gcc version (4.7) that is now
causing the false positives, so there is no effect on older compilers.

A side effect is that when building with CONFIG_CC_OPTIMIZE_FOR_SIZE,
we might now see /fewer/ warnings about possibly uninitialized
warnings than with -O2, but that is still much better than seeing
warnings known to be bogus.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index 46263d8..dc87b2e 100644
--- a/Makefile
+++ b/Makefile
@@ -571,7 +571,7 @@ endif # $(dot-config)
 all: vmlinux
 
 ifdef CONFIG_CC_OPTIMIZE_FOR_SIZE
-KBUILD_CFLAGS	+= -Os
+KBUILD_CFLAGS	+= -Os $(call cc-disable-warning,maybe-uninitialized,)
 else
 KBUILD_CFLAGS	+= -O2
 endif
-- 
1.8.1.2



From arnd at arndb.de  Tue Apr 23 12:30:38 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 23 Apr 2013 18:30:38 +0200
Subject: [PATCH 06/21] ARM: tegra: call cpu_do_idle from C code
In-Reply-To: <1366734653-488286-1-git-send-email-arnd@arndb.de>
References: <1366734653-488286-1-git-send-email-arnd@arndb.de>
Message-ID: <1366734653-488286-7-git-send-email-arnd@arndb.de>

When building a kernel for multiple CPU architecture levels,
cpu_do_idle() is a macro for an indirect function call, which
cannot be called from assembly code as Tegra does.

Adding a trivial C wrapper for this function lets us build
a tegra kernel with ARMv6 support enabled.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Cc: Joseph Lo <josephl at nvidia.com>
Cc: Stephen Warren <swarren at nvidia.com>
---
 arch/arm/mach-tegra/pm.c            | 5 +++++
 arch/arm/mach-tegra/sleep-tegra20.S | 2 +-
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-tegra/pm.c b/arch/arm/mach-tegra/pm.c
index 523604d..398e932 100644
--- a/arch/arm/mach-tegra/pm.c
+++ b/arch/arm/mach-tegra/pm.c
@@ -181,6 +181,11 @@ bool tegra_set_cpu_in_lp2(int phy_cpu_id)
 	return last_cpu;
 }
 
+int tegra_cpu_do_idle(void)
+{
+	return cpu_do_idle();
+}
+
 static int tegra_sleep_cpu(unsigned long v2p)
 {
 	/* Switch to the identity mapping. */
diff --git a/arch/arm/mach-tegra/sleep-tegra20.S b/arch/arm/mach-tegra/sleep-tegra20.S
index 9f6bfafd..e3f2417 100644
--- a/arch/arm/mach-tegra/sleep-tegra20.S
+++ b/arch/arm/mach-tegra/sleep-tegra20.S
@@ -197,7 +197,7 @@ ENTRY(tegra20_sleep_cpu_secondary_finish)
 	mov	r3, #CPU_RESETTABLE
 	str	r3, [r0]
 
-	bl	cpu_do_idle
+	bl	tegra_cpu_do_idle
 
 	/*
 	 * cpu may be reset while in wfi, which will return through
-- 
1.8.1.2



From arnd at arndb.de  Tue Apr 23 12:30:36 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 23 Apr 2013 18:30:36 +0200
Subject: [PATCH 04/21] ARM: kvm: define KVM_ARM_MAX_VCPUS unconditionally
In-Reply-To: <1366734653-488286-1-git-send-email-arnd@arndb.de>
References: <1366734653-488286-1-git-send-email-arnd@arndb.de>
Message-ID: <1366734653-488286-5-git-send-email-arnd@arndb.de>

The CONFIG_KVM_ARM_MAX_VCPUS symbol is needed in order to build the
kernel/context_tracking.c code, which includes the vgic data structures
implictly through the kvm headers. Definining the symbol to zero
on builds without KVM resolves this build error:

In file included from include/linux/kvm_host.h:33:0,
                 from kernel/context_tracking.c:18:
arch/arm/include/asm/kvm_host.h:28:23: warning: "CONFIG_KVM_ARM_MAX_VCPUS" is not defined [-Wundef]
 #define KVM_MAX_VCPUS CONFIG_KVM_ARM_MAX_VCPUS
                       ^
arch/arm/include/asm/kvm_vgic.h:34:24: note: in expansion of macro 'KVM_MAX_VCPUS'
 #define VGIC_MAX_CPUS  KVM_MAX_VCPUS
                        ^
arch/arm/include/asm/kvm_vgic.h:38:6: note: in expansion of macro 'VGIC_MAX_CPUS'
 #if (VGIC_MAX_CPUS > 8)
      ^
In file included from arch/arm/include/asm/kvm_host.h:41:0,
                 from include/linux/kvm_host.h:33,
                 from kernel/context_tracking.c:18:
arch/arm/include/asm/kvm_vgic.h:59:11: error: 'CONFIG_KVM_ARM_MAX_VCPUS' undeclared here (not in a function)
  } percpu[VGIC_MAX_CPUS];
           ^

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Cc: Marc Zyngier <marc.zyngier at arm.com>
Cc: Christoffer Dall <cdall at cs.columbia.edu>
Cc: Will Deacon <will.deacon at arm.com>
---
 arch/arm/kvm/Kconfig | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/kvm/Kconfig b/arch/arm/kvm/Kconfig
index 49dd64e..370e1a8 100644
--- a/arch/arm/kvm/Kconfig
+++ b/arch/arm/kvm/Kconfig
@@ -41,9 +41,9 @@ config KVM_ARM_HOST
 	  Provides host support for ARM processors.
 
 config KVM_ARM_MAX_VCPUS
-	int "Number maximum supported virtual CPUs per VM"
-	depends on KVM_ARM_HOST
-	default 4
+	int "Number maximum supported virtual CPUs per VM" if KVM_ARM_HOST
+	default 4 if KVM_ARM_HOST
+	default 0
 	help
 	  Static number of max supported virtual CPUs per VM.
 
-- 
1.8.1.2



From arnd at arndb.de  Tue Apr 23 12:30:37 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 23 Apr 2013 18:30:37 +0200
Subject: [PATCH 05/21] ARM: OMAP2+: add dependencies on ARCH_MULTI_V6/V7
In-Reply-To: <1366734653-488286-1-git-send-email-arnd@arndb.de>
References: <1366734653-488286-1-git-send-email-arnd@arndb.de>
Message-ID: <1366734653-488286-6-git-send-email-arnd@arndb.de>

CONFIG_ARCH_OMAP2PLUS depends on (ARCH_MULTI_V6 || ARCH_MULTI_V7) as of
a0694861 "ARM: OMAP2+: Enable ARCH_MULTIPLATFORM support", but the
individual OMAP2/3/4/5 and AM33XX platforms can all be selected independent
of what we are building for, which is a bug and prevents us from easily
building e.g. an ARMv7-only defconfig.

This makes ARCH_OMAP2 depend on ARCH_MULTI_V6 and the others depend on
ARCH_MULTI_V7, to ensure we really only build the platforms for the
CPUs we have enabled in the global multiplatform configuration step.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Cc: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
Cc: Tony Lindgren <tony at atomide.com>
---
 arch/arm/mach-omap2/Kconfig | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 8111cd9..552341d 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -55,6 +55,7 @@ config SOC_HAS_REALTIME_COUNTER
 config ARCH_OMAP2
 	bool "TI OMAP2"
 	depends on ARCH_OMAP2PLUS
+	depends on ARCH_MULTI_V6
 	default y
 	select CPU_V6
 	select MULTI_IRQ_HANDLER
@@ -64,6 +65,7 @@ config ARCH_OMAP2
 config ARCH_OMAP3
 	bool "TI OMAP3"
 	depends on ARCH_OMAP2PLUS
+	depends on ARCH_MULTI_V7
 	default y
 	select ARCH_HAS_OPP
 	select ARM_CPU_SUSPEND if PM
@@ -80,6 +82,7 @@ config ARCH_OMAP4
 	bool "TI OMAP4"
 	default y
 	depends on ARCH_OMAP2PLUS
+	depends on ARCH_MULTI_V7
 	select ARCH_HAS_OPP
 	select ARCH_NEEDS_CPU_IDLE_COUPLED if SMP
 	select ARM_CPU_SUSPEND if PM
@@ -99,6 +102,7 @@ config ARCH_OMAP4
 
 config SOC_OMAP5
 	bool "TI OMAP5"
+	depends on ARCH_MULTI_V7
 	select ARM_CPU_SUSPEND if PM
 	select ARM_GIC
 	select CPU_V7
@@ -135,6 +139,7 @@ config SOC_TI81XX
 
 config SOC_AM33XX
 	bool "AM33XX support"
+	depends on ARCH_MULTI_V7
 	default y
 	select ARM_CPU_SUSPEND if PM
 	select CPU_V7
-- 
1.8.1.2



From arnd at arndb.de  Tue Apr 23 12:30:43 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 23 Apr 2013 18:30:43 +0200
Subject: [PATCH 11/21] drm/tilcdc: use only a single module device table
In-Reply-To: <1366734653-488286-1-git-send-email-arnd@arndb.de>
References: <1366734653-488286-1-git-send-email-arnd@arndb.de>
Message-ID: <1366734653-488286-12-git-send-email-arnd@arndb.de>

The tilcdc driver fails to be built as a module because of extraneous
MODULE_DEVICE_TABLE entries:

drivers/gpu/drm/tilcdc/tilcdc_slave.o:(.data+0x54): multiple definition of `__mod_of_device_table'
drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54): first defined here
drivers/gpu/drm/tilcdc/tilcdc_panel.o:(.data+0x54): multiple definition of `__mod_of_device_table'
drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54): first defined here
drivers/gpu/drm/tilcdc/tilcdc_drv.o:(.data+0x184): multiple definition of `__mod_of_device_table'
drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54): first defined here

Since the entire point of these entries is to make the module autoload
when one of the devices is present, it's enough to keep the one entry
for "ti,am33xx-tilcdc", which should always be there if any of the
others are.

Cc: Rob Clark <robdclark at gmail.com>
Cc: Dave Airlie <airlied at linux.ie>
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 drivers/gpu/drm/tilcdc/tilcdc_panel.c  | 1 -
 drivers/gpu/drm/tilcdc/tilcdc_slave.c  | 1 -
 drivers/gpu/drm/tilcdc/tilcdc_tfp410.c | 1 -
 3 files changed, 3 deletions(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_panel.c b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
index 580b74e..eb99f42 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_panel.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
@@ -413,7 +413,6 @@ static struct of_device_id panel_of_match[] = {
 		{ .compatible = "ti,tilcdc,panel", },
 		{ },
 };
-MODULE_DEVICE_TABLE(of, panel_of_match);
 
 struct platform_driver panel_driver = {
 	.probe = panel_probe,
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_slave.c b/drivers/gpu/drm/tilcdc/tilcdc_slave.c
index 568dc1c..db1d2fc 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_slave.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_slave.c
@@ -353,7 +353,6 @@ static struct of_device_id slave_of_match[] = {
 		{ .compatible = "ti,tilcdc,slave", },
 		{ },
 };
-MODULE_DEVICE_TABLE(of, slave_of_match);
 
 struct platform_driver slave_driver = {
 	.probe = slave_probe,
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c b/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
index 58d487b..a36788f 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
@@ -396,7 +396,6 @@ static struct of_device_id tfp410_of_match[] = {
 		{ .compatible = "ti,tilcdc,tfp410", },
 		{ },
 };
-MODULE_DEVICE_TABLE(of, tfp410_of_match);
 
 struct platform_driver tfp410_driver = {
 	.probe = tfp410_probe,
-- 
1.8.1.2



From arnd at arndb.de  Tue Apr 23 12:30:44 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 23 Apr 2013 18:30:44 +0200
Subject: [PATCH 12/21] mmc: sdhci-tegra: fix MODULE_DEVICE_TABLE
In-Reply-To: <1366734653-488286-1-git-send-email-arnd@arndb.de>
References: <1366734653-488286-1-git-send-email-arnd@arndb.de>
Message-ID: <1366734653-488286-13-git-send-email-arnd@arndb.de>

The symbol referenced in MODULE_DEVICE_TABLE must match the actual
table, otherwise we get a build error like

sdhci-tegra.c:206:34: error: '__mod_of_device_table' aliased to undefined symbol 'sdhci_dt_ids'

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Cc: Stephen Warren <swarren at nvidia.com>
Cc: Chris Ball <cjb at laptop.org>
---
 drivers/mmc/host/sdhci-tegra.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mmc/host/sdhci-tegra.c b/drivers/mmc/host/sdhci-tegra.c
index 08b06e9..85052bf 100644
--- a/drivers/mmc/host/sdhci-tegra.c
+++ b/drivers/mmc/host/sdhci-tegra.c
@@ -214,7 +214,7 @@ static const struct of_device_id sdhci_tegra_dt_match[] = {
 #endif
 	{}
 };
-MODULE_DEVICE_TABLE(of, sdhci_dt_ids);
+MODULE_DEVICE_TABLE(of, sdhci_tegra_dt_match);
 
 static void sdhci_tegra_parse_dt(struct device *dev,
 					struct sdhci_tegra *tegra_host)
-- 
1.8.1.2



From arnd at arndb.de  Tue Apr 23 12:30:34 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 23 Apr 2013 18:30:34 +0200
Subject: [PATCH 02/21] ARM: compressed/head.S: work around new binutils warning
In-Reply-To: <1366734653-488286-1-git-send-email-arnd@arndb.de>
References: <1366734653-488286-1-git-send-email-arnd@arndb.de>
Message-ID: <1366734653-488286-3-git-send-email-arnd@arndb.de>

In August 2012, Matthew Gretton-Dann checked a change into binutils
labelled "Error on obsolete & warn on deprecated registers", apparently as
part of ARMv8 support. Apparently, this was supposed to emit the message
"Warning: This coprocessor register access is deprecated in ARMv8" when
using certain mcr/mrc instructions and building for ARMv8. Unfortunately,
the message that is actually emitted appears to be '(null)', which is
less helpful in comparison.

Even more unfortunately, this is biting us on every single kernel
build with a new gas, because arch/arm/boot/compressed/head.S and some
other files in that directory are built with -march=all since kernel
commit 80cec14a8 "[ARM] Add -march=all to assembly file build in
arch/arm/boot/compressed" back in v2.6.28.

This patch reverts Russell's nice solution and replaces it with a more
complex one that sprinkles .arch statements inside of the head.S file
in functions that are executed in different architecture levels, which
seems to solve the original problem just as well, and gets rid of the
new one, too.

Without this patch, building anything results in:

arch/arm/boot/compressed/head.S: Assembler messages:
arch/arm/boot/compressed/head.S:565: Warning: (null)
arch/arm/boot/compressed/head.S:676: Warning: (null)
arch/arm/boot/compressed/head.S:698: Warning: (null)
arch/arm/boot/compressed/head.S:722: Warning: (null)
arch/arm/boot/compressed/head.S:726: Warning: (null)
arch/arm/boot/compressed/head.S:957: Warning: (null)
arch/arm/boot/compressed/head.S:996: Warning: (null)
arch/arm/boot/compressed/head.S:997: Warning: (null)
arch/arm/boot/compressed/head.S:1027: Warning: (null)
arch/arm/boot/compressed/head.S:1035: Warning: (null)
arch/arm/boot/compressed/head.S:1046: Warning: (null)
arch/arm/boot/compressed/head.S:1060: Warning: (null)
arch/arm/boot/compressed/head.S:1092: Warning: (null)
arch/arm/boot/compressed/head.S:1094: Warning: (null)
arch/arm/boot/compressed/head.S:1095: Warning: (null)
arch/arm/boot/compressed/head.S:1102: Warning: (null)
arch/arm/boot/compressed/head.S:1134: Warning: (null)

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Cc: Matthew Gretton-Dann <matthew.gretton-dann at arm.com>
Cc: Russell King <rmk+kernel at arm.linux.org.uk>
---
 arch/arm/boot/compressed/Makefile |  2 +-
 arch/arm/boot/compressed/head.S   | 12 ++++++++++++
 2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile
index afed28e..27f3604 100644
--- a/arch/arm/boot/compressed/Makefile
+++ b/arch/arm/boot/compressed/Makefile
@@ -121,7 +121,7 @@ KBUILD_CFLAGS = $(subst -pg, , $(ORIG_CFLAGS))
 endif
 
 ccflags-y := -fpic -mno-single-pic-base -fno-builtin -I$(obj)
-asflags-y := -Wa,-march=all -DZIMAGE
+asflags-y := -DZIMAGE
 
 # Supply kernel BSS size to the decompressor via a linker symbol.
 KBSS_SZ = $(shell $(CROSS_COMPILE)size $(obj)/../../../../vmlinux | \
diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
index fe4d9c3..3b0b21a 100644
--- a/arch/arm/boot/compressed/head.S
+++ b/arch/arm/boot/compressed/head.S
@@ -548,6 +548,7 @@ cache_on:	mov	r3, #8			@ cache_on function
  * to cover all 32bit address and cacheable and bufferable.
  */
 __armv4_mpu_cache_on:
+		.arch armv4
 		mov	r0, #0x3f		@ 4G, the whole
 		mcr	p15, 0, r0, c6, c7, 0	@ PR7 Area Setting
 		mcr 	p15, 0, r0, c6, c7, 1
@@ -655,6 +656,7 @@ ENDPROC(__setup_mmu)
 @ Enable unaligned access on v6, to allow better code generation
 @ for the decompressor C code:
 __armv6_mmu_cache_on:
+		.arch armv6
 		mrc	p15, 0, r0, c1, c0, 0	@ read SCTLR
 		bic	r0, r0, #2		@ A (no unaligned access fault)
 		orr	r0, r0, #1 << 22	@ U (v6 unaligned access model)
@@ -663,11 +665,13 @@ __armv6_mmu_cache_on:
 
 __arm926ejs_mmu_cache_on:
 #ifdef CONFIG_CPU_DCACHE_WRITETHROUGH
+		.arch armv5
 		mov	r0, #4			@ put dcache in WT mode
 		mcr	p15, 7, r0, c15, c0, 0
 #endif
 
 __armv4_mmu_cache_on:
+		.arch armv4
 		mov	r12, lr
 #ifdef CONFIG_MMU
 		mov	r6, #CB_BITS | 0x12	@ U
@@ -688,6 +692,7 @@ __armv4_mmu_cache_on:
 		mov	pc, r12
 
 __armv7_mmu_cache_on:
+		.arch armv7-a
 		mov	r12, lr
 #ifdef CONFIG_MMU
 		mrc	p15, 0, r11, c0, c1, 4	@ read ID_MMFR0
@@ -1031,6 +1036,7 @@ cache_clean_flush:
 		mov	r3, #16
 		b	call_cache_fn
 
+		.arch armv4
 __armv4_mpu_cache_flush:
 		mov	r2, #1
 		mov	r3, #0
@@ -1056,6 +1062,7 @@ __fa526_cache_flush:
 		mov	pc, lr
 
 __armv6_mmu_cache_flush:
+		.arch armv6
 		mov	r1, #0
 		mcr	p15, 0, r1, c7, c14, 0	@ clean+invalidate D
 		mcr	p15, 0, r1, c7, c5, 0	@ invalidate I+BTB
@@ -1063,6 +1070,7 @@ __armv6_mmu_cache_flush:
 		mcr	p15, 0, r1, c7, c10, 4	@ drain WB
 		mov	pc, lr
 
+		.arch armv7-a
 __armv7_mmu_cache_flush:
 		mrc	p15, 0, r10, c0, c1, 5	@ read ID_MMFR1
 		tst	r10, #0xf << 16		@ hierarchical cache (ARMv7)
@@ -1123,6 +1131,7 @@ iflush:
 		mcr	p15, 0, r10, c7, c5, 4	@ ISB
 		mov	pc, lr
 
+		.arch armv5
 __armv5tej_mmu_cache_flush:
 1:		mrc	p15, 0, r15, c7, c14, 3	@ test,clean,invalidate D cache
 		bne	1b
@@ -1130,6 +1139,7 @@ __armv5tej_mmu_cache_flush:
 		mcr	p15, 0, r0, c7, c10, 4	@ drain WB
 		mov	pc, lr
 
+		.arch armv4
 __armv4_mmu_cache_flush:
 		mov	r2, #64*1024		@ default: 32K dcache size (*2)
 		mov	r11, #32		@ default: 32 byte line size
@@ -1168,6 +1178,8 @@ __armv3_mpu_cache_flush:
 		mcr	p15, 0, r1, c7, c0, 0	@ invalidate whole cache v3
 		mov	pc, lr
 
+		.arch armv4
+
 /*
  * Various debugging routines for printing hex characters and
  * memory, which again must be relocatable.
-- 
1.8.1.2



From arnd at arndb.de  Tue Apr 23 12:30:49 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 23 Apr 2013 18:30:49 +0200
Subject: [PATCH 17/21] tty/serial/sirf: fix MODULE_DEVICE_TABLE
In-Reply-To: <1366734653-488286-1-git-send-email-arnd@arndb.de>
References: <1366734653-488286-1-git-send-email-arnd@arndb.de>
Message-ID: <1366734653-488286-18-git-send-email-arnd@arndb.de>

This fixes building the sirfsorc-uart driver as a loadable module,
which uses an incorrect MODULE_DEVICE_TABLE, by changing the reference to the
correct symbol.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
Cc: Jiri Slaby <jslaby at suse.cz>
---
 drivers/tty/serial/sirfsoc_uart.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/tty/serial/sirfsoc_uart.c b/drivers/tty/serial/sirfsoc_uart.c
index 6bbfe99..03465b6 100644
--- a/drivers/tty/serial/sirfsoc_uart.c
+++ b/drivers/tty/serial/sirfsoc_uart.c
@@ -758,7 +758,7 @@ static struct of_device_id sirfsoc_uart_ids[] = {
 	{ .compatible = "sirf,marco-uart", },
 	{}
 };
-MODULE_DEVICE_TABLE(of, sirfsoc_serial_of_match);
+MODULE_DEVICE_TABLE(of, sirfsoc_uart_ids);
 
 static struct platform_driver sirfsoc_uart_driver = {
 	.probe		= sirfsoc_uart_probe,
-- 
1.8.1.2



From arnd at arndb.de  Tue Apr 23 12:30:35 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 23 Apr 2013 18:30:35 +0200
Subject: [PATCH 03/21] ARM: use optimized do_div only for EABI
In-Reply-To: <1366734653-488286-1-git-send-email-arnd@arndb.de>
References: <1366734653-488286-1-git-send-email-arnd@arndb.de>
Message-ID: <1366734653-488286-4-git-send-email-arnd@arndb.de>

In OABI configurations, some uses of the do_div function
cause gcc to run out of registers. To work around that,
we can force the use of the out-of-line version for
configurations that build a OABI kernel.

Without this patch, building netx_defconfig results in:

net/core/pktgen.c: In function 'pktgen_if_show':
net/core/pktgen.c:682:2775: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm'
net/core/pktgen.c:682:3153: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm'
net/core/pktgen.c:682:2775: error: 'asm' operand has impossible constraints
net/core/pktgen.c:682:3153: error: 'asm' operand has impossible constraints

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Cc: Russell King <linux at arm.linux.org.uk>
---
 arch/arm/include/asm/div64.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/div64.h b/arch/arm/include/asm/div64.h
index fe92ccf..191ada6 100644
--- a/arch/arm/include/asm/div64.h
+++ b/arch/arm/include/asm/div64.h
@@ -46,7 +46,7 @@
 	__rem;							\
 })
 
-#if __GNUC__ < 4
+#if __GNUC__ < 4 || !defined(CONFIG_AEABI)
 
 /*
  * gcc versions earlier than 4.0 are simply too problematic for the
-- 
1.8.1.2



From arnd at arndb.de  Tue Apr 23 12:30:48 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 23 Apr 2013 18:30:48 +0200
Subject: [PATCH 16/21] staging/zsmalloc: don't use pgtable-mapping from modules
In-Reply-To: <1366734653-488286-1-git-send-email-arnd@arndb.de>
References: <1366734653-488286-1-git-send-email-arnd@arndb.de>
Message-ID: <1366734653-488286-17-git-send-email-arnd@arndb.de>

Building zsmalloc as a module does not work on ARM because it uses
an interface that is not exported:

ERROR: "flush_tlb_kernel_range" [drivers/staging/zsmalloc/zsmalloc.ko] undefined!

Since this is only used as a performance optimization and only on ARM,
we can avoid the problem simply by not using that optimization when
building zsmalloc it is a loadable module.

flush_tlb_kernel_range is often an inline function, but out of the
architectures that use an extern function, only powerpc exports
it.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
Cc: Seth Jennings <sjenning at linux.vnet.ibm.com>
Cc: Nitin Gupta <ngupta at vflare.org>
---
 drivers/staging/zsmalloc/zsmalloc-main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/zsmalloc/zsmalloc-main.c b/drivers/staging/zsmalloc/zsmalloc-main.c
index e78d262..291c1d8 100644
--- a/drivers/staging/zsmalloc/zsmalloc-main.c
+++ b/drivers/staging/zsmalloc/zsmalloc-main.c
@@ -225,7 +225,7 @@ struct zs_pool {
  * so that USE_PGTABLE_MAPPING is defined. This causes zsmalloc to use
  * page table mapping rather than copying for object mapping.
 */
-#if defined(CONFIG_ARM)
+#if defined(CONFIG_ARM) && !defined(MODULE)
 #define USE_PGTABLE_MAPPING
 #endif
 
-- 
1.8.1.2



From arnd at arndb.de  Tue Apr 23 12:30:47 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 23 Apr 2013 18:30:47 +0200
Subject: [PATCH 15/21] staging: comedi/dawboard2000: use mdelay for large
 delays
In-Reply-To: <1366734653-488286-1-git-send-email-arnd@arndb.de>
References: <1366734653-488286-1-git-send-email-arnd@arndb.de>
Message-ID: <1366734653-488286-16-git-send-email-arnd@arndb.de>

On ARM, it is not legal to pass values larger than 2ms into udelay(),
and mdelay() must be used instead, to avoid this build error:

ERROR: "__bad_udelay" [drivers/staging/comedi/drivers/daqboard2000.ko]
undefined!

On a related note, any use of mdelay() or large udelay() numbers should
be carefully reviewed, and replaced with msleep() or a different
implementation that does not rely on delaying the work.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Cc: H Hartley Sweeten <hsweeten at visionengravers.com>
Cc: Ian Abbott <abbotti at mev.co.uk>
Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
---
 drivers/staging/comedi/drivers/daqboard2000.c | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/staging/comedi/drivers/daqboard2000.c b/drivers/staging/comedi/drivers/daqboard2000.c
index 50b450f..b213e36 100644
--- a/drivers/staging/comedi/drivers/daqboard2000.c
+++ b/drivers/staging/comedi/drivers/daqboard2000.c
@@ -462,9 +462,9 @@ static void daqboard2000_resetLocalBus(struct comedi_device *dev)
 	struct daqboard2000_private *devpriv = dev->private;
 
 	writel(DAQBOARD2000_SECRLocalBusHi, devpriv->plx + 0x6c);
-	udelay(10000);
+	mdelay(10);
 	writel(DAQBOARD2000_SECRLocalBusLo, devpriv->plx + 0x6c);
-	udelay(10000);
+	mdelay(10);
 }
 
 static void daqboard2000_reloadPLX(struct comedi_device *dev)
@@ -472,11 +472,11 @@ static void daqboard2000_reloadPLX(struct comedi_device *dev)
 	struct daqboard2000_private *devpriv = dev->private;
 
 	writel(DAQBOARD2000_SECRReloadLo, devpriv->plx + 0x6c);
-	udelay(10000);
+	mdelay(10);
 	writel(DAQBOARD2000_SECRReloadHi, devpriv->plx + 0x6c);
-	udelay(10000);
+	mdelay(10);
 	writel(DAQBOARD2000_SECRReloadLo, devpriv->plx + 0x6c);
-	udelay(10000);
+	mdelay(10);
 }
 
 static void daqboard2000_pulseProgPin(struct comedi_device *dev)
@@ -484,9 +484,9 @@ static void daqboard2000_pulseProgPin(struct comedi_device *dev)
 	struct daqboard2000_private *devpriv = dev->private;
 
 	writel(DAQBOARD2000_SECRProgPinHi, devpriv->plx + 0x6c);
-	udelay(10000);
+	mdelay(10);
 	writel(DAQBOARD2000_SECRProgPinLo, devpriv->plx + 0x6c);
-	udelay(10000);	/* Not in the original code, but I like symmetry... */
+	mdelay(10);	/* Not in the original code, but I like symmetry... */
 }
 
 static int daqboard2000_pollCPLD(struct comedi_device *dev, int mask)
-- 
1.8.1.2



From arnd at arndb.de  Tue Apr 23 12:30:53 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 23 Apr 2013 18:30:53 +0200
Subject: [PATCH 21/21] mtd: omap2: allow bulding as a module
In-Reply-To: <1366734653-488286-1-git-send-email-arnd@arndb.de>
References: <1366734653-488286-1-git-send-email-arnd@arndb.de>
Message-ID: <1366734653-488286-22-git-send-email-arnd@arndb.de>

The omap2 nand device driver calls into the the elm code, which can
be a loadable module, and in that case it cannot be built-in itself.
I can see no reason why the omap2 driver cannot also be a module,
so let's make the option "tristate" in Kconfig to fix this allmodconfig
build error:

ERROR: "elm_config" [drivers/mtd/nand/omap2.ko] undefined!
ERROR: "elm_decode_bch_error_page" [drivers/mtd/nand/omap2.ko] undefined!

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Cc: David Woodhouse <dwmw2 at infradead.org>
Cc: Artem Bityutskiy <artem.bityutskiy at linux.intel.com>
Cc: Tony Lindgren <tony at atomide.com>
Cc: Afzal Mohammed <afzal at ti.com>
Cc: Russell King <rmk+kernel at arm.linux.org.uk>
Cc: linux-mtd at lists.infradead.org
---
 drivers/mtd/nand/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 81bf5e5..106b55e 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -109,7 +109,7 @@ config MTD_NAND_OMAP2
 
 config MTD_NAND_OMAP_BCH
 	depends on MTD_NAND && MTD_NAND_OMAP2 && ARCH_OMAP3
-	bool "Enable support for hardware BCH error correction"
+	tristate "Enable support for hardware BCH error correction"
 	default n
 	select BCH
 	select BCH_CONST_PARAMS
-- 
1.8.1.2



From arnd at arndb.de  Tue Apr 23 12:30:50 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 23 Apr 2013 18:30:50 +0200
Subject: [PATCH 18/21] usb: phy: tegra: don't call into tegra-ehci directly
In-Reply-To: <1366734653-488286-1-git-send-email-arnd@arndb.de>
References: <1366734653-488286-1-git-send-email-arnd@arndb.de>
Message-ID: <1366734653-488286-19-git-send-email-arnd@arndb.de>

Both phy-tegra-usb.c and ehci-tegra.c export symbols used by the other one,
which does not work if one of them or both are loadable modules, resulting
in an error like:

drivers/built-in.o: In function `utmi_phy_clk_disable':
drivers/usb/phy/phy-tegra-usb.c:302: undefined reference to `tegra_ehci_set_phcd'
drivers/built-in.o: In function `utmi_phy_clk_enable':
drivers/usb/phy/phy-tegra-usb.c:324: undefined reference to `tegra_ehci_set_phcd'
drivers/built-in.o: In function `utmi_phy_power_on':
drivers/usb/phy/phy-tegra-usb.c:447: undefined reference to `tegra_ehci_set_pts'

This turns the interface into a one-way dependency by letting the tegra ehci
driver pass two function pointers for callbacks that need to be called by
the phy driver.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Cc: Venu Byravarasu <vbyravarasu at nvidia.com>
Cc: Alan Stern <stern at rowland.harvard.edu>
Cc: Felipe Balbi <balbi at ti.com>
Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
Cc: Stephen Warren <swarren at nvidia.com>
Cc: linux-usb at vger.kernel.org
---
 drivers/usb/host/ehci-tegra.c     | 10 +++++-----
 drivers/usb/phy/tegra_usb_phy.c   | 13 +++++++++----
 include/linux/usb/tegra_usb_phy.h | 10 +++++-----
 3 files changed, 19 insertions(+), 14 deletions(-)

diff --git a/drivers/usb/host/ehci-tegra.c b/drivers/usb/host/ehci-tegra.c
index 568aecc..07419e4 100644
--- a/drivers/usb/host/ehci-tegra.c
+++ b/drivers/usb/host/ehci-tegra.c
@@ -610,7 +610,7 @@ static const struct dev_pm_ops tegra_ehci_pm_ops = {
 /* Bits of PORTSC1, which will get cleared by writing 1 into them */
 #define TEGRA_PORTSC1_RWC_BITS (PORT_CSC | PORT_PEC | PORT_OCC)
 
-void tegra_ehci_set_pts(struct usb_phy *x, u8 pts_val)
+static void tegra_ehci_set_pts(struct usb_phy *x, u8 pts_val)
 {
 	unsigned long val;
 	struct usb_hcd *hcd = bus_to_hcd(x->otg->host);
@@ -621,9 +621,8 @@ void tegra_ehci_set_pts(struct usb_phy *x, u8 pts_val)
 	val |= TEGRA_USB_PORTSC1_PTS(pts_val & 3);
 	writel(val, base + TEGRA_USB_PORTSC1);
 }
-EXPORT_SYMBOL_GPL(tegra_ehci_set_pts);
 
-void tegra_ehci_set_phcd(struct usb_phy *x, bool enable)
+static void tegra_ehci_set_phcd(struct usb_phy *x, bool enable)
 {
 	unsigned long val;
 	struct usb_hcd *hcd = bus_to_hcd(x->otg->host);
@@ -636,7 +635,6 @@ void tegra_ehci_set_phcd(struct usb_phy *x, bool enable)
 		val &= ~TEGRA_USB_PORTSC1_PHCD;
 	writel(val, base + TEGRA_USB_PORTSC1);
 }
-EXPORT_SYMBOL_GPL(tegra_ehci_set_phcd);
 
 static u64 tegra_ehci_dma_mask = DMA_BIT_MASK(32);
 
@@ -733,7 +731,9 @@ static int tegra_ehci_probe(struct platform_device *pdev)
 
 	tegra->phy = tegra_usb_phy_open(&pdev->dev, instance, hcd->regs,
 					pdata->phy_config,
-					TEGRA_USB_PHY_MODE_HOST);
+					TEGRA_USB_PHY_MODE_HOST,
+					&tegra_ehci_set_pts,
+					tegra_ehci_set_phcd);
 	if (IS_ERR(tegra->phy)) {
 		dev_err(&pdev->dev, "Failed to open USB phy\n");
 		err = -ENXIO;
diff --git a/drivers/usb/phy/tegra_usb_phy.c b/drivers/usb/phy/tegra_usb_phy.c
index 5487d38..17d8112 100644
--- a/drivers/usb/phy/tegra_usb_phy.c
+++ b/drivers/usb/phy/tegra_usb_phy.c
@@ -299,7 +299,7 @@ static void utmi_phy_clk_disable(struct tegra_usb_phy *phy)
 		val &= ~USB_SUSP_SET;
 		writel(val, base + USB_SUSP_CTRL);
 	} else
-		tegra_ehci_set_phcd(&phy->u_phy, true);
+		phy->set_phcd(&phy->u_phy, true);
 
 	if (utmi_wait_register(base + USB_SUSP_CTRL, USB_PHY_CLK_VALID, 0) < 0)
 		pr_err("%s: timeout waiting for phy to stabilize\n", __func__);
@@ -321,7 +321,7 @@ static void utmi_phy_clk_enable(struct tegra_usb_phy *phy)
 		val &= ~USB_SUSP_CLR;
 		writel(val, base + USB_SUSP_CTRL);
 	} else
-		tegra_ehci_set_phcd(&phy->u_phy, false);
+		phy->set_phcd(&phy->u_phy, false);
 
 	if (utmi_wait_register(base + USB_SUSP_CTRL, USB_PHY_CLK_VALID,
 						     USB_PHY_CLK_VALID))
@@ -444,7 +444,7 @@ static int utmi_phy_power_on(struct tegra_usb_phy *phy)
 	utmi_phy_clk_enable(phy);
 
 	if (!phy->is_legacy_phy)
-		tegra_ehci_set_pts(&phy->u_phy, 0);
+		phy->set_pts(&phy->u_phy, 0);
 
 	return 0;
 }
@@ -688,7 +688,10 @@ static int	tegra_usb_phy_suspend(struct usb_phy *x, int suspend)
 }
 
 struct tegra_usb_phy *tegra_usb_phy_open(struct device *dev, int instance,
-	void __iomem *regs, void *config, enum tegra_usb_phy_mode phy_mode)
+	void __iomem *regs, void *config, enum tegra_usb_phy_mode phy_mode,
+	void (*set_pts)(struct usb_phy *x, u8 pts_val),
+	void (*set_phcd)(struct usb_phy *x, bool enable))
+
 {
 	struct tegra_usb_phy *phy;
 	unsigned long parent_rate;
@@ -707,6 +710,8 @@ struct tegra_usb_phy *tegra_usb_phy_open(struct device *dev, int instance,
 	phy->dev = dev;
 	phy->is_legacy_phy =
 		of_property_read_bool(np, "nvidia,has-legacy-mode");
+	phy->set_pts = set_pts;
+	phy->set_phcd = set_phcd;
 	err = of_property_match_string(np, "phy_type", "ulpi");
 	if (err < 0)
 		phy->is_ulpi_phy = false;
diff --git a/include/linux/usb/tegra_usb_phy.h b/include/linux/usb/tegra_usb_phy.h
index 9ebebe9..1b7519a 100644
--- a/include/linux/usb/tegra_usb_phy.h
+++ b/include/linux/usb/tegra_usb_phy.h
@@ -61,10 +61,14 @@ struct tegra_usb_phy {
 	struct device *dev;
 	bool is_legacy_phy;
 	bool is_ulpi_phy;
+	void (*set_pts)(struct usb_phy *x, u8 pts_val);
+	void (*set_phcd)(struct usb_phy *x, bool enable);
 };
 
 struct tegra_usb_phy *tegra_usb_phy_open(struct device *dev, int instance,
-	void __iomem *regs, void *config, enum tegra_usb_phy_mode phy_mode);
+	void __iomem *regs, void *config, enum tegra_usb_phy_mode phy_mode,
+	void (*set_pts)(struct usb_phy *x, u8 pts_val),
+	void (*set_phcd)(struct usb_phy *x, bool enable));
 
 void tegra_usb_phy_preresume(struct usb_phy *phy);
 
@@ -75,8 +79,4 @@ void tegra_ehci_phy_restore_start(struct usb_phy *phy,
 
 void tegra_ehci_phy_restore_end(struct usb_phy *phy);
 
-void tegra_ehci_set_pts(struct usb_phy *x, u8 pts_val);
-
-void tegra_ehci_set_phcd(struct usb_phy *x, bool enable);
-
 #endif /* __TEGRA_USB_PHY_H */
-- 
1.8.1.2



From arnd at arndb.de  Tue Apr 23 12:30:40 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 23 Apr 2013 18:30:40 +0200
Subject: [PATCH 08/21] ASoC: ux500: forward declare msp_i2s_platform_data
In-Reply-To: <1366734653-488286-1-git-send-email-arnd@arndb.de>
References: <1366734653-488286-1-git-send-email-arnd@arndb.de>
Message-ID: <1366734653-488286-9-git-send-email-arnd@arndb.de>

We get a lot of build warnings from the msp driver like:

In file included from sound/soc/ux500/ux500_msp_dai.h:21:0,
                 from sound/soc/ux500/mop500.c:25:
sound/soc/ux500/ux500_msp_i2s.h:546:11: warning: 'struct msp_i2s_platform_data' declared inside parameter list [enabled by default]
    struct msp_i2s_platform_data *platform_data);
           ^
sound/soc/ux500/ux500_msp_i2s.h:546:11: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default]

The easiest solution is to add a declaration of the struct name.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Cc: Mark Brown <broonie at opensource.wolfsonmicro.com>
Cc: Lee Jones <lee.jones at linaro.org>
Cc: Ola Lilja <ola.o.lilja at stericsson.com>
Cc: alsa-devel at alsa-project.org
---
 sound/soc/ux500/ux500_msp_i2s.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sound/soc/ux500/ux500_msp_i2s.h b/sound/soc/ux500/ux500_msp_i2s.h
index 1311c0d..6f3e3dc 100644
--- a/sound/soc/ux500/ux500_msp_i2s.h
+++ b/sound/soc/ux500/ux500_msp_i2s.h
@@ -543,6 +543,7 @@ struct ux500_msp_dma_params {
 	struct stedma40_chan_cfg *dma_cfg;
 };
 
+struct msp_i2s_platform_data;
 int ux500_msp_i2s_init_msp(struct platform_device *pdev,
 			struct ux500_msp **msp_p,
 			struct msp_i2s_platform_data *platform_data);
-- 
1.8.1.2



From arnd at arndb.de  Tue Apr 23 12:30:46 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 23 Apr 2013 18:30:46 +0200
Subject: [PATCH 14/21] staging: nvec: allow modular build
In-Reply-To: <1366734653-488286-1-git-send-email-arnd@arndb.de>
References: <1366734653-488286-1-git-send-email-arnd@arndb.de>
Message-ID: <1366734653-488286-15-git-send-email-arnd@arndb.de>

The serio code can be a loadable module, which in turn means that nvec
also has to be a module, so mark it as "tristate" in Kconfig.

drivers/built-in.o: In function `nvec_mouse_remove':
drivers/staging/nvec/nvec_ps2.c:136: undefined reference to `serio_unregister_port'
drivers/built-in.o: In function `nvec_mouse_probe':
drivers/staging/nvec/nvec_ps2.c:126: undefined reference to `__serio_register_port'
drivers/built-in.o: In function `nvec_ps2_notifier':
drivers/staging/nvec/nvec_ps2.c:84: undefined reference to `serio_interrupt'
drivers/staging/nvec/nvec_ps2.c:91: undefined reference to `serio_interrupt'

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Cc: Marc Dietrich <marvin24 at gmx.de>
Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
---
 drivers/staging/nvec/Kconfig | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/nvec/Kconfig b/drivers/staging/nvec/Kconfig
index f779fdc..7e61ada 100644
--- a/drivers/staging/nvec/Kconfig
+++ b/drivers/staging/nvec/Kconfig
@@ -1,5 +1,5 @@
 config MFD_NVEC
-	bool "NV Tegra Embedded Controller SMBus Interface"
+	tristate "NV Tegra Embedded Controller SMBus Interface"
 	depends on I2C && GPIOLIB && ARCH_TEGRA
 	select MFD_CORE
 	help
@@ -7,28 +7,28 @@ config MFD_NVEC
 	    controller.
 
 config KEYBOARD_NVEC
-	bool "Keyboard on nVidia compliant EC"
+	tristate "Keyboard on nVidia compliant EC"
 	depends on MFD_NVEC && INPUT
 	help
 	  Say Y here to enable support for a keyboard connected to 
 	  a nVidia compliant embedded controller.
 
 config SERIO_NVEC_PS2
-	bool "PS2 on nVidia EC"
+	tristate "PS2 on nVidia EC"
 	depends on MFD_NVEC && SERIO
 	help
 	  Say Y here to enable support for a Touchpad / Mouse connected
 	  to a nVidia compliant embedded controller.
 
 config NVEC_POWER
-	bool "NVEC charger and battery"
+	tristate "NVEC charger and battery"
 	depends on MFD_NVEC && POWER_SUPPLY
 	help
 	  Say Y to enable support for battery and charger interface for
 	  nVidia compliant embedded controllers.
 
 config NVEC_PAZ00
-	bool "Support for OEM specific functions on Compal PAZ00 based devices"
+	tristate "Support for OEM specific functions on Compal PAZ00 based devices"
 	depends on MFD_NVEC && LEDS_CLASS
 	help
 	  Say Y to enable control of the yellow side leds on Compal PAZ00 based
-- 
1.8.1.2



From arnd at arndb.de  Tue Apr 23 12:30:52 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 23 Apr 2013 18:30:52 +0200
Subject: [PATCH 20/21] MFD: ab8500: export ab8500_gpadc_sw_hw_convert properly
In-Reply-To: <1366734653-488286-1-git-send-email-arnd@arndb.de>
References: <1366734653-488286-1-git-send-email-arnd@arndb.de>
Message-ID: <1366734653-488286-21-git-send-email-arnd@arndb.de>

Apparently the ab8500_gpadc_sw_hw_convert function got renamed
from ab8500_gpadc_convert to ab8500_gpadc_sw_hw_convert in
commit 734823462 "mfd: ab8500-gpadc: Add gpadc hw conversion",
but the export for this function did not get changed at the
same time, causing this allyesconfig error:

ERROR: "ab8500_gpadc_sw_hw_convert" [drivers/hwmon/ab8500.ko] undefined!

This patch fixes the export.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Cc: M'boumba Cedric Madianga <cedric.madianga at stericsson.com>
Cc: Lee Jones <lee.jones at linaro.org>
Cc: Mattias WALLIN <mattias.wallin at stericsson.com>
Cc: Michel JAOUEN <michel.jaouen at stericsson.com>
Cc: Samuel Ortiz <sameo at linux.intel.com>
---
 drivers/mfd/ab8500-gpadc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mfd/ab8500-gpadc.c b/drivers/mfd/ab8500-gpadc.c
index 5f341a5..184df96 100644
--- a/drivers/mfd/ab8500-gpadc.c
+++ b/drivers/mfd/ab8500-gpadc.c
@@ -269,7 +269,7 @@ int ab8500_gpadc_convert(struct ab8500_gpadc *gpadc, u8 channel)
 
 	return voltage;
 }
-EXPORT_SYMBOL(ab8500_gpadc_convert);
+EXPORT_SYMBOL(ab8500_gpadc_sw_hw_convert);
 
 /**
  * ab8500_gpadc_read_raw() - gpadc read
-- 
1.8.1.2



From arnd at arndb.de  Tue Apr 23 12:30:51 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 23 Apr 2013 18:30:51 +0200
Subject: [PATCH 19/21] usb: phy: don't mark usb_bind_phy as __init
In-Reply-To: <1366734653-488286-1-git-send-email-arnd@arndb.de>
References: <1366734653-488286-1-git-send-email-arnd@arndb.de>
Message-ID: <1366734653-488286-20-git-send-email-arnd@arndb.de>

It makes no sense for a symbol to be both exported and marked __init,
because any users in modules would be calling this function after
it gets discarded. Further, this patch revolves a section mismatch
warning from usbhs_init_phys(), which is intentionally not marked
__init:

WARNING: vmlinux.o(.text+0x413f8): Section mismatch in reference from
the function usbhs_init_phys() to the function .init.text:usb_bind_phy()

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Cc: Alan Stern <stern at rowland.harvard.edu>
Cc: Felipe Balbi <balbi at ti.com>
Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
Cc: linux-usb at vger.kernel.org
---
 drivers/usb/otg/otg.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/otg/otg.c b/drivers/usb/otg/otg.c
index 2bd03d2..77346cf 100644
--- a/drivers/usb/otg/otg.c
+++ b/drivers/usb/otg/otg.c
@@ -414,7 +414,7 @@ EXPORT_SYMBOL(usb_remove_phy);
  *
  * To be used by platform specific initialization code.
  */
-int __init usb_bind_phy(const char *dev_name, u8 index,
+int usb_bind_phy(const char *dev_name, u8 index,
 				const char *phy_dev_name)
 {
 	struct usb_phy_bind *phy_bind;
-- 
1.8.1.2



From arnd at arndb.de  Tue Apr 23 12:30:39 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 23 Apr 2013 18:30:39 +0200
Subject: [PATCH 07/21] ARM: tegra: unify tegra_idle_device definitions
In-Reply-To: <1366734653-488286-1-git-send-email-arnd@arndb.de>
References: <1366734653-488286-1-git-send-email-arnd@arndb.de>
Message-ID: <1366734653-488286-8-git-send-email-arnd@arndb.de>

The three tegra variants (20, 30, 114) each define their own per-cpu
variable for tegra_idle_device, which causes link errors when you
build the kernel for more than one of them:

cpuidle-tegra30.o:(.discard+0x0): multiple definition of `__pcpu_unique_tegra_idle_device'
cpuidle-tegra20.o:(.discard+0x0): first defined here
cpuidle-tegra114.o:(.discard+0x0): multiple definition of `__pcpu_unique_tegra_idle_device'
cpuidle-tegra20.o:(.discard+0x0): first defined here

By moving the variable into the common cpuidle.c file, we save a little
bit of object code size and avoid that warning.
As a bonus, this patch also removes the unused "drv" variables in each
of the three files that caused a warning since 0697598db "ARM: tegra:
cpuidle: remove useless initialization".

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Cc: Stephen Warren <swarren at nvidia.com>
Cc: Joseph Lo <josephl at nvidia.com>
Cc: Daniel Lezcano <daniel.lezcano at linaro.org>
Cc: Rafael J. Wysocki <rafael.j.wysocki at intel.com>
---
 arch/arm/mach-tegra/cpuidle-tegra114.c | 5 ++---
 arch/arm/mach-tegra/cpuidle-tegra20.c  | 4 +---
 arch/arm/mach-tegra/cpuidle-tegra30.c  | 4 +---
 arch/arm/mach-tegra/cpuidle.c          | 2 ++
 arch/arm/mach-tegra/cpuidle.h          | 4 ++++
 5 files changed, 10 insertions(+), 9 deletions(-)

diff --git a/arch/arm/mach-tegra/cpuidle-tegra114.c b/arch/arm/mach-tegra/cpuidle-tegra114.c
index 0f4e8c4..09067a1 100644
--- a/arch/arm/mach-tegra/cpuidle-tegra114.c
+++ b/arch/arm/mach-tegra/cpuidle-tegra114.c
@@ -20,6 +20,8 @@
 
 #include <asm/cpuidle.h>
 
+#include "cpuidle.h"
+
 static struct cpuidle_driver tegra_idle_driver = {
 	.name = "tegra_idle",
 	.owner = THIS_MODULE,
@@ -30,14 +32,11 @@ static struct cpuidle_driver tegra_idle_driver = {
 	},
 };
 
-static DEFINE_PER_CPU(struct cpuidle_device, tegra_idle_device);
-
 int __init tegra114_cpuidle_init(void)
 {
 	int ret;
 	unsigned int cpu;
 	struct cpuidle_device *dev;
-	struct cpuidle_driver *drv = &tegra_idle_driver;
 
 	ret = cpuidle_register_driver(&tegra_idle_driver);
 	if (ret) {
diff --git a/arch/arm/mach-tegra/cpuidle-tegra20.c b/arch/arm/mach-tegra/cpuidle-tegra20.c
index 825ced4..c811328 100644
--- a/arch/arm/mach-tegra/cpuidle-tegra20.c
+++ b/arch/arm/mach-tegra/cpuidle-tegra20.c
@@ -36,6 +36,7 @@
 #include "iomap.h"
 #include "irq.h"
 #include "flowctrl.h"
+#include "cpuidle.h"
 
 #ifdef CONFIG_PM_SLEEP
 static bool abort_flag;
@@ -67,8 +68,6 @@ static struct cpuidle_driver tegra_idle_driver = {
 	.en_core_tk_irqen = 1,
 };
 
-static DEFINE_PER_CPU(struct cpuidle_device, tegra_idle_device);
-
 #ifdef CONFIG_PM_SLEEP
 #ifdef CONFIG_SMP
 static void __iomem *pmc = IO_ADDRESS(TEGRA_PMC_BASE);
@@ -220,7 +219,6 @@ int __init tegra20_cpuidle_init(void)
 	int ret;
 	unsigned int cpu;
 	struct cpuidle_device *dev;
-	struct cpuidle_driver *drv = &tegra_idle_driver;
 
 #ifdef CONFIG_PM_SLEEP
 	tegra_tear_down_cpu = tegra20_tear_down_cpu;
diff --git a/arch/arm/mach-tegra/cpuidle-tegra30.c b/arch/arm/mach-tegra/cpuidle-tegra30.c
index 8b50cf4..6187478 100644
--- a/arch/arm/mach-tegra/cpuidle-tegra30.c
+++ b/arch/arm/mach-tegra/cpuidle-tegra30.c
@@ -33,6 +33,7 @@
 
 #include "pm.h"
 #include "sleep.h"
+#include "cpuidle.h"
 
 #ifdef CONFIG_PM_SLEEP
 static int tegra30_idle_lp2(struct cpuidle_device *dev,
@@ -65,8 +66,6 @@ static struct cpuidle_driver tegra_idle_driver = {
 	},
 };
 
-static DEFINE_PER_CPU(struct cpuidle_device, tegra_idle_device);
-
 #ifdef CONFIG_PM_SLEEP
 static bool tegra30_cpu_cluster_power_down(struct cpuidle_device *dev,
 					   struct cpuidle_driver *drv,
@@ -160,7 +159,6 @@ int __init tegra30_cpuidle_init(void)
 	int ret;
 	unsigned int cpu;
 	struct cpuidle_device *dev;
-	struct cpuidle_driver *drv = &tegra_idle_driver;
 
 #ifdef CONFIG_PM_SLEEP
 	tegra_tear_down_cpu = tegra30_tear_down_cpu;
diff --git a/arch/arm/mach-tegra/cpuidle.c b/arch/arm/mach-tegra/cpuidle.c
index 4b744c4..1bac560 100644
--- a/arch/arm/mach-tegra/cpuidle.c
+++ b/arch/arm/mach-tegra/cpuidle.c
@@ -27,6 +27,8 @@
 #include "fuse.h"
 #include "cpuidle.h"
 
+DEFINE_PER_CPU(struct cpuidle_device, tegra_idle_device);
+
 static int __init tegra_cpuidle_init(void)
 {
 	int ret;
diff --git a/arch/arm/mach-tegra/cpuidle.h b/arch/arm/mach-tegra/cpuidle.h
index d733f75..a4c5f17 100644
--- a/arch/arm/mach-tegra/cpuidle.h
+++ b/arch/arm/mach-tegra/cpuidle.h
@@ -17,6 +17,10 @@
 #ifndef __MACH_TEGRA_CPUIDLE_H
 #define __MACH_TEGRA_CPUIDLE_H
 
+#include <linux/cpuidle.h>
+
+DECLARE_PER_CPU(struct cpuidle_device, tegra_idle_device);
+
 #ifdef CONFIG_ARCH_TEGRA_2x_SOC
 int tegra20_cpuidle_init(void);
 #else
-- 
1.8.1.2



From arnd at arndb.de  Tue Apr 23 12:30:45 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 23 Apr 2013 18:30:45 +0200
Subject: [PATCH 13/21] misc: mark spear13xx-pcie-gadget as broken
In-Reply-To: <1366734653-488286-1-git-send-email-arnd@arndb.de>
References: <1366734653-488286-1-git-send-email-arnd@arndb.de>
Message-ID: <1366734653-488286-14-git-send-email-arnd@arndb.de>

This driver was merged in 2.6.38 but never actually compiled because
it depends on the <mach/pcie.h> header that has not made it into the
kernel. Starting with Linux-3.10, this results in "allyesconfig"
build errors, since spear13xx can now be enabled with the default
"multiplatform" platform on ARM. Let's mark it as broken for now.
If it doesn't get fixed, we can drop it completely.

Cc: Pratyush Anand <pratyush.anand at st.com>
Cc: Randy Dunlap <randy.dunlap at oracle.com>
Cc: Jesse Barnes <jbarnes at virtuousgeek.org>
Cc: Viresh Kumar <viresh.kumar at st.com>
Cc: Shiraz Hashim <shiraz.hashim at st.com>
Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 drivers/misc/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index e83fdfe..c74b13b 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -398,7 +398,7 @@ config DS1682
 
 config SPEAR13XX_PCIE_GADGET
 	bool "PCIe gadget support for SPEAr13XX platform"
-	depends on ARCH_SPEAR13XX
+	depends on ARCH_SPEAR13XX && BROKEN
 	default n
 	help
 	 This option enables gadget support for PCIe controller. If
-- 
1.8.1.2



From arnd at arndb.de  Tue Apr 23 12:30:41 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 23 Apr 2013 18:30:41 +0200
Subject: [PATCH 09/21] spi/sirf: fix MODULE_DEVICE_TABLE
In-Reply-To: <1366734653-488286-1-git-send-email-arnd@arndb.de>
References: <1366734653-488286-1-git-send-email-arnd@arndb.de>
Message-ID: <1366734653-488286-10-git-send-email-arnd@arndb.de>

This fixes building the spi-sirf driver as a loadable module, which uses
an incorrect MODULE_DEVICE_TABLE, by changing the reference to the
correct symbol.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Cc: Grant Likely <grant.likely at secretlab.ca>
Cc: Mark Brown <broonie at kernel.org>
Cc: spi-devel-general at lists.sourceforge.net
Cc: Barry Song <Baohua.Song at csr.com>
---
 drivers/spi/spi-sirf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/spi/spi-sirf.c b/drivers/spi/spi-sirf.c
index f59d417..0808cd5 100644
--- a/drivers/spi/spi-sirf.c
+++ b/drivers/spi/spi-sirf.c
@@ -660,7 +660,7 @@ static const struct of_device_id spi_sirfsoc_of_match[] = {
 	{ .compatible = "sirf,marco-spi", },
 	{}
 };
-MODULE_DEVICE_TABLE(of, sirfsoc_spi_of_match);
+MODULE_DEVICE_TABLE(of, spi_sirfsoc_of_match);
 
 static struct platform_driver spi_sirfsoc_driver = {
 	.driver = {
-- 
1.8.1.2



From arnd at arndb.de  Tue Apr 23 12:30:32 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 23 Apr 2013 18:30:32 +0200
Subject: [PATCH 00/21] ARM build fixes for 3.10
Message-ID: <1366734653-488286-1-git-send-email-arnd@arndb.de>

Hi everyone,

This is a set of bug fixes for build errors and warnings I am
seeing in the various defconfigs and/or allmodconfig builds
on linux-next. The majority of these showed up because we now
include a lot more platforms in allmodconfig than we used to.

Please apply to appropriate maintainer trees or provide
feedback, I can take care of the rest sending those through
arm-soc that I get no feedback on.

	Arnd

Arnd Bergmann (21):
  Turn off -Wmaybe-uninitialized when building with -Os
  ARM: compressed/head.S: work around new binutils warning
  ARM: use optimized do_div only for EABI
  ARM: kvm: define KVM_ARM_MAX_VCPUS unconditionally
  ARM: OMAP2+: add dependencies on ARCH_MULTI_V6/V7
  ARM: tegra: call cpu_do_idle from C code
  ARM: tegra: unify tegra_idle_device definitions
  ASoC: ux500: forward declare msp_i2s_platform_data
  spi/sirf: fix MODULE_DEVICE_TABLE
  ssb: fix alignment of struct bcma_device_id
  drm/tilcdc: use only a single module device table
  mmc: sdhci-tegra: fix MODULE_DEVICE_TABLE
  misc: mark spear13xx-pcie-gadget as broken
  staging: nvec: allow modular build
  staging: comedi/dawboard2000: use mdelay for large delays
  staging/zsmalloc: don't use pgtable-mapping from modules
  tty/serial/sirf: fix MODULE_DEVICE_TABLE
  usb: phy: tegra: don't call into tegra-ehci directly
  usb: phy: don't mark usb_bind_phy as __init
  MFD: ab8500: export ab8500_gpadc_sw_hw_convert properly
  mtd: omap2: allow bulding as a module

 Makefile                                      |  2 +-
 arch/arm/boot/compressed/Makefile             |  2 +-
 arch/arm/boot/compressed/head.S               | 12 ++++++++++++
 arch/arm/include/asm/div64.h                  |  2 +-
 arch/arm/kvm/Kconfig                          |  6 +++---
 arch/arm/mach-omap2/Kconfig                   |  5 +++++
 arch/arm/mach-tegra/cpuidle-tegra114.c        |  5 ++---
 arch/arm/mach-tegra/cpuidle-tegra20.c         |  4 +---
 arch/arm/mach-tegra/cpuidle-tegra30.c         |  4 +---
 arch/arm/mach-tegra/cpuidle.c                 |  2 ++
 arch/arm/mach-tegra/cpuidle.h                 |  4 ++++
 arch/arm/mach-tegra/pm.c                      |  5 +++++
 arch/arm/mach-tegra/sleep-tegra20.S           |  2 +-
 drivers/gpu/drm/tilcdc/tilcdc_panel.c         |  1 -
 drivers/gpu/drm/tilcdc/tilcdc_slave.c         |  1 -
 drivers/gpu/drm/tilcdc/tilcdc_tfp410.c        |  1 -
 drivers/mfd/ab8500-gpadc.c                    |  2 +-
 drivers/misc/Kconfig                          |  2 +-
 drivers/mmc/host/sdhci-tegra.c                |  2 +-
 drivers/mtd/nand/Kconfig                      |  2 +-
 drivers/spi/spi-sirf.c                        |  2 +-
 drivers/staging/comedi/drivers/daqboard2000.c | 14 +++++++-------
 drivers/staging/nvec/Kconfig                  | 10 +++++-----
 drivers/staging/zsmalloc/zsmalloc-main.c      |  2 +-
 drivers/tty/serial/sirfsoc_uart.c             |  2 +-
 drivers/usb/host/ehci-tegra.c                 | 10 +++++-----
 drivers/usb/otg/otg.c                         |  2 +-
 drivers/usb/phy/tegra_usb_phy.c               | 13 +++++++++----
 include/linux/mod_devicetable.h               |  5 +++--
 include/linux/usb/tegra_usb_phy.h             | 10 +++++-----
 sound/soc/ux500/ux500_msp_i2s.h               |  1 +
 31 files changed, 82 insertions(+), 55 deletions(-)

-- 
1.8.1.2

Cc: Alan Stern <stern at rowland.harvard.edu>
Cc: Artem Bityutskiy <artem.bityutskiy at linux.intel.com>
Cc: Chris Ball <cjb at laptop.org>
Cc: Dave Airlie <airlied at linux.ie>
Cc: David Woodhouse <dwmw2 at infradead.org>
Cc: Felipe Balbi <balbi at ti.com>
Cc: Grant Likely <grant.likely at secretlab.ca>
Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
Cc: Mark Brown <broonie at kernel.org>
Cc: Russell King <linux at arm.linux.org.uk>
Cc: Samuel Ortiz <sameo at linux.intel.com>
Cc: Stephen Warren <swarren at nvidia.com>
Cc: Tony Lindgren <tony at atomide.com>
Cc: Viresh Kumar <viresh.kumar at st.com>
Cc: alsa-devel at alsa-project.org
Cc: dri-devel at lists.freedesktop.org
Cc: linux-mtd at lists.infradead.org
Cc: linux-usb at vger.kernel.org
Cc: spi-devel-general at lists.sourceforge.net


From sboyd at codeaurora.org  Tue Apr 23 12:34:50 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Tue, 23 Apr 2013 09:34:50 -0700
Subject: [PATCH 0/4] ARM 64 bit sched_clock take #2
In-Reply-To: <5175A1B8.1090202@gmail.com>
References: <51709FD7.8050408@gmail.com>
 <1366417746-24990-1-git-send-email-sboyd@codeaurora.org>
 <51756CB6.5060607@linaro.org> <5175A1B8.1090202@gmail.com>
Message-ID: <5176B82A.9070003@codeaurora.org>

On 04/22/13 13:46, Rob Herring wrote:
> On 04/22/2013 12:00 PM, John Stultz wrote:
>> On 04/19/2013 05:29 PM, Stephen Boyd wrote:
>>> This is what I was thinking. I don't see why we can't move this to
>>> generic code and have arm64 use it too. Those patches will follow once
>>> I find an arm64
>>> compiler.
>> I think moving this to generic code sounds like a good idea. You could
>> probably also prototype and test the 64bit code with x86_64, using the
>> TSC counter.
> I agree this should all be common, but I'd like to see the common
> version first. That is not going to make it for 3.10. For 3.10, the
> immediate need is to fix suspend and initial time for the arch timer. I
> think this should be fixed locally in arch timer code for 3.10. The
> alternative is to revert linux-next commit 023796b9be3a77481cd5 (ARM:
> arch_timer: use full 64-bit counter for sched_clock) which will cause
> the arch timer to not be used as sched_clock if another higher frequency
> sched_clock is registered.

This would make sense to me if we were already in the 3.10-rc1 or rc2
phase, but this code isn't even in Linus' tree yet. Why can't we just
fix it properly before sending off to Linus? Obviously this is up to the
maintainers to decide, so if we can't fix it properly with this patch
series I propose we revert like you say.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation



From arnd at arndb.de  Tue Apr 23 12:30:42 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 23 Apr 2013 18:30:42 +0200
Subject: [PATCH 10/21] ssb: fix alignment of struct bcma_device_id
In-Reply-To: <1366734653-488286-1-git-send-email-arnd@arndb.de>
References: <1366734653-488286-1-git-send-email-arnd@arndb.de>
Message-ID: <1366734653-488286-11-git-send-email-arnd@arndb.de>

The ARM OABI and EABI disagree on the alignment of structures
with small members, so module init tools may interpret the
ssb device table incorrectly, as shown  by this warning when
building the b43 device driver in an OABI kernel:

FATAL: drivers/net/wireless/b43/b43: sizeof(struct ssb_device_id)=6 is
not a modulo of the size of section __mod_ssb_device_table=88.

Forcing the default (EABI) alignment on the structure makes this
problem go away. Since the ssb_device_id may have the same problem,
better fix both structures.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Cc: Russell King <linux at arm.linux.org.uk>
Cc: John W. Linville <linville at tuxdriver.com>
Cc: Michael Buesch <mb at bu3sch.de>
Cc: Larry Finger <Larry.Finger at lwfinger.net>
---
 include/linux/mod_devicetable.h | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
index 779cf7c..ce363a5 100644
--- a/include/linux/mod_devicetable.h
+++ b/include/linux/mod_devicetable.h
@@ -360,7 +360,8 @@ struct ssb_device_id {
 	__u16	vendor;
 	__u16	coreid;
 	__u8	revision;
-};
+	__u8	__pad;
+} __attribute__((packed, aligned(2)));
 #define SSB_DEVICE(_vendor, _coreid, _revision)  \
 	{ .vendor = _vendor, .coreid = _coreid, .revision = _revision, }
 #define SSB_DEVTABLE_END  \
@@ -376,7 +377,7 @@ struct bcma_device_id {
 	__u16	id;
 	__u8	rev;
 	__u8	class;
-};
+} __attribute__((packed,aligned(2)));
 #define BCMA_CORE(_manuf, _id, _rev, _class)  \
 	{ .manuf = _manuf, .id = _id, .rev = _rev, .class = _class, }
 #define BCMA_CORETABLE_END  \
-- 
1.8.1.2



From stern at rowland.harvard.edu  Tue Apr 23 12:42:23 2013
From: stern at rowland.harvard.edu (Alan Stern)
Date: Tue, 23 Apr 2013 12:42:23 -0400 (EDT)
Subject: [PATCH 18/21] usb: phy: tegra: don't call into tegra-ehci directly
In-Reply-To: <1366734653-488286-19-git-send-email-arnd@arndb.de>
Message-ID: <Pine.LNX.4.44L0.1304231239220.1679-100000@iolanthe.rowland.org>

On Tue, 23 Apr 2013, Arnd Bergmann wrote:

> Both phy-tegra-usb.c and ehci-tegra.c export symbols used by the other one,
> which does not work if one of them or both are loadable modules, resulting
> in an error like:
> 
> drivers/built-in.o: In function `utmi_phy_clk_disable':
> drivers/usb/phy/phy-tegra-usb.c:302: undefined reference to `tegra_ehci_set_phcd'
> drivers/built-in.o: In function `utmi_phy_clk_enable':
> drivers/usb/phy/phy-tegra-usb.c:324: undefined reference to `tegra_ehci_set_phcd'
> drivers/built-in.o: In function `utmi_phy_power_on':
> drivers/usb/phy/phy-tegra-usb.c:447: undefined reference to `tegra_ehci_set_pts'
> 
> This turns the interface into a one-way dependency by letting the tegra ehci
> driver pass two function pointers for callbacks that need to be called by
> the phy driver.

> @@ -733,7 +731,9 @@ static int tegra_ehci_probe(struct platform_device *pdev)
>  
>  	tegra->phy = tegra_usb_phy_open(&pdev->dev, instance, hcd->regs,
>  					pdata->phy_config,
> -					TEGRA_USB_PHY_MODE_HOST);
> +					TEGRA_USB_PHY_MODE_HOST,
> +					&tegra_ehci_set_pts,
> +					tegra_ehci_set_phcd);

Does the compiler warn about the unnecessary '&'?  In any case, it
looks strange to have one function pointer with an '&' and another
without.

Aside from that minor detail, the ehci-tegra.c changes are fine.

Alan Stern



From cjb at laptop.org  Tue Apr 23 12:46:15 2013
From: cjb at laptop.org (Chris Ball)
Date: Tue, 23 Apr 2013 12:46:15 -0400
Subject: [PATCH 12/21] mmc: sdhci-tegra: fix MODULE_DEVICE_TABLE
In-Reply-To: <1366734653-488286-13-git-send-email-arnd@arndb.de> (Arnd
 Bergmann's message of "Tue, 23 Apr 2013 18:30:44 +0200")
References: <1366734653-488286-1-git-send-email-arnd@arndb.de>
 <1366734653-488286-13-git-send-email-arnd@arndb.de>
Message-ID: <87bo95tctk.fsf@octavius.laptop.org>

Hi Arnd,

On Tue, Apr 23 2013, Arnd Bergmann wrote:
> The symbol referenced in MODULE_DEVICE_TABLE must match the actual
> table, otherwise we get a build error like
>
> sdhci-tegra.c:206:34: error: '__mod_of_device_table' aliased to undefined symbol 'sdhci_dt_ids'
>
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Cc: Stephen Warren <swarren at nvidia.com>
> Cc: Chris Ball <cjb at laptop.org>
> ---
>  drivers/mmc/host/sdhci-tegra.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/host/sdhci-tegra.c b/drivers/mmc/host/sdhci-tegra.c
> index 08b06e9..85052bf 100644
> --- a/drivers/mmc/host/sdhci-tegra.c
> +++ b/drivers/mmc/host/sdhci-tegra.c
> @@ -214,7 +214,7 @@ static const struct of_device_id sdhci_tegra_dt_match[] = {
>  #endif
>  	{}
>  };
> -MODULE_DEVICE_TABLE(of, sdhci_dt_ids);
> +MODULE_DEVICE_TABLE(of, sdhci_tegra_dt_match);
>  
>  static void sdhci_tegra_parse_dt(struct device *dev,
>  					struct sdhci_tegra *tegra_host)

I was going to take this, but it doesn't apply to mmc-next or
linux-next, because the #endif in your first line of context isn't
present in those trees -- which tree is this based on?

Sounds like it might make more sense for you to take this; if so:
Acked-by: Chris Ball <cjb at laptop.org>

Thanks,

- Chris.
-- 
Chris Ball   <cjb at laptop.org>   <http://printf.net/>
One Laptop Per Child


From hartleys at visionengravers.com  Tue Apr 23 12:46:46 2013
From: hartleys at visionengravers.com (H Hartley Sweeten)
Date: Tue, 23 Apr 2013 11:46:46 -0500
Subject: [PATCH 15/21] staging: comedi/dawboard2000: use mdelay for
 large delays
In-Reply-To: <1366734653-488286-16-git-send-email-arnd@arndb.de>
References: <1366734653-488286-1-git-send-email-arnd@arndb.de>
 <1366734653-488286-16-git-send-email-arnd@arndb.de>
Message-ID: <ADE657CA350FB648AAC2C43247A983F0021D422D5F61@AUSP01VMBX24.collaborationhost.net>

On Tuesday, April 23, 2013 9:31 AM, Arnd Bergmann wrote:
> Subject: [PATCH 15/21] staging: comedi/dawboard2000: use mdelay for large delays

Nit.. Typo in subject.

> On ARM, it is not legal to pass values larger than 2ms into udelay(),
> and mdelay() must be used instead, to avoid this build error:
>
> ERROR: "__bad_udelay" [drivers/staging/comedi/drivers/daqboard2000.ko]
> undefined!
>
> On a related note, any use of mdelay() or large udelay() numbers should
> be carefully reviewed, and replaced with msleep() or a different
> implementation that does not rely on delaying the work.
>
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Cc: H Hartley Sweeten <hsweeten at visionengravers.com>
> Cc: Ian Abbott <abbotti at mev.co.uk>
> Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>

Reviewed-by: H Hartley Sweeten <hsweeten at visionengravers.com>

Thanks,
Hartley


From daniel.lezcano at linaro.org  Tue Apr 23 12:56:09 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Tue, 23 Apr 2013 18:56:09 +0200
Subject: [PATCH 07/21] ARM: tegra: unify tegra_idle_device definitions
In-Reply-To: <1366734653-488286-8-git-send-email-arnd@arndb.de>
References: <1366734653-488286-1-git-send-email-arnd@arndb.de>
 <1366734653-488286-8-git-send-email-arnd@arndb.de>
Message-ID: <5176BD29.1000405@linaro.org>

On 04/23/2013 06:30 PM, Arnd Bergmann wrote:
> The three tegra variants (20, 30, 114) each define their own per-cpu
> variable for tegra_idle_device, which causes link errors when you
> build the kernel for more than one of them:
> 
> cpuidle-tegra30.o:(.discard+0x0): multiple definition of `__pcpu_unique_tegra_idle_device'
> cpuidle-tegra20.o:(.discard+0x0): first defined here
> cpuidle-tegra114.o:(.discard+0x0): multiple definition of `__pcpu_unique_tegra_idle_device'
> cpuidle-tegra20.o:(.discard+0x0): first defined here
> 
> By moving the variable into the common cpuidle.c file, we save a little
> bit of object code size and avoid that warning.
> As a bonus, this patch also removes the unused "drv" variables in each
> of the three files that caused a warning since 0697598db "ARM: tegra:
> cpuidle: remove useless initialization".
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Cc: Stephen Warren <swarren at nvidia.com>
> Cc: Joseph Lo <josephl at nvidia.com>
> Cc: Daniel Lezcano <daniel.lezcano at linaro.org>
> Cc: Rafael J. Wysocki <rafael.j.wysocki at intel.com>
> ---

Hi Arnd,

the patch sounds good but I think the side effect of the consolidation
patchset [1] fixed that.

You can find these fixes in Rafael's tree:

https://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/commit/?h=linux-next&id=4c637b2175a0dc65d533494225525c6c82d73293

https://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/commit/?h=linux-next&id=e158f9da6974cc11bfab2246a9b10021af0e0d8a

https://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/commit/?h=linux-next&id=c5106c9dea9a6022ab84c6cb1d4a0b19fc5af0e2

https://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/commit/?h=linux-next&id=f040c26ffaa5e56f2bca427c719c9601a02e70e5

[1] http://www.spinics.net/lists/arm-kernel/msg239811.html

>  arch/arm/mach-tegra/cpuidle-tegra114.c | 5 ++---
>  arch/arm/mach-tegra/cpuidle-tegra20.c  | 4 +---
>  arch/arm/mach-tegra/cpuidle-tegra30.c  | 4 +---
>  arch/arm/mach-tegra/cpuidle.c          | 2 ++
>  arch/arm/mach-tegra/cpuidle.h          | 4 ++++
>  5 files changed, 10 insertions(+), 9 deletions(-)
> 
> diff --git a/arch/arm/mach-tegra/cpuidle-tegra114.c b/arch/arm/mach-tegra/cpuidle-tegra114.c
> index 0f4e8c4..09067a1 100644
> --- a/arch/arm/mach-tegra/cpuidle-tegra114.c
> +++ b/arch/arm/mach-tegra/cpuidle-tegra114.c
> @@ -20,6 +20,8 @@
>  
>  #include <asm/cpuidle.h>
>  
> +#include "cpuidle.h"
> +
>  static struct cpuidle_driver tegra_idle_driver = {
>  	.name = "tegra_idle",
>  	.owner = THIS_MODULE,
> @@ -30,14 +32,11 @@ static struct cpuidle_driver tegra_idle_driver = {
>  	},
>  };
>  
> -static DEFINE_PER_CPU(struct cpuidle_device, tegra_idle_device);
> -
>  int __init tegra114_cpuidle_init(void)
>  {
>  	int ret;
>  	unsigned int cpu;
>  	struct cpuidle_device *dev;
> -	struct cpuidle_driver *drv = &tegra_idle_driver;
>  
>  	ret = cpuidle_register_driver(&tegra_idle_driver);
>  	if (ret) {
> diff --git a/arch/arm/mach-tegra/cpuidle-tegra20.c b/arch/arm/mach-tegra/cpuidle-tegra20.c
> index 825ced4..c811328 100644
> --- a/arch/arm/mach-tegra/cpuidle-tegra20.c
> +++ b/arch/arm/mach-tegra/cpuidle-tegra20.c
> @@ -36,6 +36,7 @@
>  #include "iomap.h"
>  #include "irq.h"
>  #include "flowctrl.h"
> +#include "cpuidle.h"
>  
>  #ifdef CONFIG_PM_SLEEP
>  static bool abort_flag;
> @@ -67,8 +68,6 @@ static struct cpuidle_driver tegra_idle_driver = {
>  	.en_core_tk_irqen = 1,
>  };
>  
> -static DEFINE_PER_CPU(struct cpuidle_device, tegra_idle_device);
> -
>  #ifdef CONFIG_PM_SLEEP
>  #ifdef CONFIG_SMP
>  static void __iomem *pmc = IO_ADDRESS(TEGRA_PMC_BASE);
> @@ -220,7 +219,6 @@ int __init tegra20_cpuidle_init(void)
>  	int ret;
>  	unsigned int cpu;
>  	struct cpuidle_device *dev;
> -	struct cpuidle_driver *drv = &tegra_idle_driver;
>  
>  #ifdef CONFIG_PM_SLEEP
>  	tegra_tear_down_cpu = tegra20_tear_down_cpu;
> diff --git a/arch/arm/mach-tegra/cpuidle-tegra30.c b/arch/arm/mach-tegra/cpuidle-tegra30.c
> index 8b50cf4..6187478 100644
> --- a/arch/arm/mach-tegra/cpuidle-tegra30.c
> +++ b/arch/arm/mach-tegra/cpuidle-tegra30.c
> @@ -33,6 +33,7 @@
>  
>  #include "pm.h"
>  #include "sleep.h"
> +#include "cpuidle.h"
>  
>  #ifdef CONFIG_PM_SLEEP
>  static int tegra30_idle_lp2(struct cpuidle_device *dev,
> @@ -65,8 +66,6 @@ static struct cpuidle_driver tegra_idle_driver = {
>  	},
>  };
>  
> -static DEFINE_PER_CPU(struct cpuidle_device, tegra_idle_device);
> -
>  #ifdef CONFIG_PM_SLEEP
>  static bool tegra30_cpu_cluster_power_down(struct cpuidle_device *dev,
>  					   struct cpuidle_driver *drv,
> @@ -160,7 +159,6 @@ int __init tegra30_cpuidle_init(void)
>  	int ret;
>  	unsigned int cpu;
>  	struct cpuidle_device *dev;
> -	struct cpuidle_driver *drv = &tegra_idle_driver;
>  
>  #ifdef CONFIG_PM_SLEEP
>  	tegra_tear_down_cpu = tegra30_tear_down_cpu;
> diff --git a/arch/arm/mach-tegra/cpuidle.c b/arch/arm/mach-tegra/cpuidle.c
> index 4b744c4..1bac560 100644
> --- a/arch/arm/mach-tegra/cpuidle.c
> +++ b/arch/arm/mach-tegra/cpuidle.c
> @@ -27,6 +27,8 @@
>  #include "fuse.h"
>  #include "cpuidle.h"
>  
> +DEFINE_PER_CPU(struct cpuidle_device, tegra_idle_device);
> +
>  static int __init tegra_cpuidle_init(void)
>  {
>  	int ret;
> diff --git a/arch/arm/mach-tegra/cpuidle.h b/arch/arm/mach-tegra/cpuidle.h
> index d733f75..a4c5f17 100644
> --- a/arch/arm/mach-tegra/cpuidle.h
> +++ b/arch/arm/mach-tegra/cpuidle.h
> @@ -17,6 +17,10 @@
>  #ifndef __MACH_TEGRA_CPUIDLE_H
>  #define __MACH_TEGRA_CPUIDLE_H
>  
> +#include <linux/cpuidle.h>
> +
> +DECLARE_PER_CPU(struct cpuidle_device, tegra_idle_device);
> +
>  #ifdef CONFIG_ARCH_TEGRA_2x_SOC
>  int tegra20_cpuidle_init(void);
>  #else
> 


-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From sergei.shtylyov at cogentembedded.com  Tue Apr 23 13:06:44 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Tue, 23 Apr 2013 21:06:44 +0400
Subject: [PATCH v3 0/4] R-Car VIN driver with R8A7779/Marzen support
Message-ID: <201304232106.45889.sergei.shtylyov@cogentembedded.com>

Hello.

   Here's the set of 4 patches against the Simon Horman's 'renesas.git' repo,
'renesas-next-20130422' tag and my recent yet unapplied USB patches. Here we
add the VIN (Video In) driver and its platform code working on the R8A7779/
Marzen with ADV7180 I2C video decoder. The driver patch also applies without
issues to Mauro's 'media_tree.git'...

[1/4] V4L2: soc_camera: Renesas R-Car VIN driver
[2/4] ARM: shmobile: r8a7779: add VIN support
[3/4] ARM: shmobile: Marzen: add VIN and ADV7180 support
[4/4] ARM: shmobile: Marzen: enable VIN and ADV7180 in defconfig

WBR, Sergei


From sergei.shtylyov at cogentembedded.com  Tue Apr 23 13:10:59 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Tue, 23 Apr 2013 21:10:59 +0400
Subject: [PATCH v3 2/4] ARM: shmobile: r8a7779: add VIN support
In-Reply-To: <201304232106.45889.sergei.shtylyov@cogentembedded.com>
References: <201304232106.45889.sergei.shtylyov@cogentembedded.com>
Message-ID: <201304232110.59718.sergei.shtylyov@cogentembedded.com>

From: Vladimir Barinov <vladimir.barinov at cogentembedded.com>

Add VIN clocks and platform devices for R8A7779 SoC; add function to register
the VIN platform devices.

Signed-off-by: Vladimir Barinov <vladimir.barinov at cogentembedded.com>
[Sergei: added 'id' parameter check to r8a7779_add_vin_device(), renamed some
variables, annotated vin[01]_resources[] and 'vin[01]_info' as '__initdata'.]
Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

---
Changes since version 2:
- annotated vin[01]_resources[] and 'vin[01]_info' as '__initdata' since they're
  kmemdup()'ed while registering the platform devices anyway;

Changes since the original posting:
- added 'id' parameter check to r8a7779_add_vin_device().

 arch/arm/mach-shmobile/clock-r8a7779.c        |   10 ++++++
 arch/arm/mach-shmobile/include/mach/r8a7779.h |    3 ++
 arch/arm/mach-shmobile/setup-r8a7779.c        |   38 ++++++++++++++++++++++++++
 3 files changed, 51 insertions(+)

Index: renesas/arch/arm/mach-shmobile/clock-r8a7779.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/clock-r8a7779.c
+++ renesas/arch/arm/mach-shmobile/clock-r8a7779.c
@@ -112,7 +112,9 @@ static struct clk *main_clks[] = {
 };
 
 enum { MSTP323, MSTP322, MSTP321, MSTP320,
+	MSTP120,
 	MSTP116, MSTP115, MSTP114,
+	MSTP110, MSTP109, MSTP108,
 	MSTP103, MSTP101, MSTP100,
 	MSTP030,
 	MSTP029, MSTP028, MSTP027, MSTP026, MSTP025, MSTP024, MSTP023, MSTP022, MSTP021,
@@ -125,9 +127,13 @@ static struct clk mstp_clks[MSTP_NR] = {
 	[MSTP322] = SH_CLK_MSTP32(&clkp_clk, MSTPCR3, 22, 0), /* SDHI1 */
 	[MSTP321] = SH_CLK_MSTP32(&clkp_clk, MSTPCR3, 21, 0), /* SDHI2 */
 	[MSTP320] = SH_CLK_MSTP32(&clkp_clk, MSTPCR3, 20, 0), /* SDHI3 */
+	[MSTP120] = SH_CLK_MSTP32(&clks_clk, MSTPCR1, 20, 0), /* VIN3 */
 	[MSTP116] = SH_CLK_MSTP32(&clkp_clk, MSTPCR1, 16, 0), /* PCIe */
 	[MSTP115] = SH_CLK_MSTP32(&clkp_clk, MSTPCR1, 15, 0), /* SATA */
 	[MSTP114] = SH_CLK_MSTP32(&clkp_clk, MSTPCR1, 14, 0), /* Ether */
+	[MSTP110] = SH_CLK_MSTP32(&clks_clk, MSTPCR1, 10, 0), /* VIN0 */
+	[MSTP109] = SH_CLK_MSTP32(&clks_clk, MSTPCR1,  9, 0), /* VIN1 */
+	[MSTP108] = SH_CLK_MSTP32(&clks_clk, MSTPCR1,  8, 0), /* VIN2 */
 	[MSTP103] = SH_CLK_MSTP32(&clks_clk, MSTPCR1,  3, 0), /* DU */
 	[MSTP101] = SH_CLK_MSTP32(&clkp_clk, MSTPCR1,  1, 0), /* USB2 */
 	[MSTP100] = SH_CLK_MSTP32(&clkp_clk, MSTPCR1,  0, 0), /* USB0/1 */
@@ -162,10 +168,14 @@ static struct clk_lookup lookups[] = {
 	CLKDEV_CON_ID("peripheral_clk",	&clkp_clk),
 
 	/* MSTP32 clocks */
+	CLKDEV_DEV_ID("rcar_vin.3", &mstp_clks[MSTP120]), /* VIN3 */
 	CLKDEV_DEV_ID("rcar-pcie", &mstp_clks[MSTP116]), /* PCIe */
 	CLKDEV_DEV_ID("sata_rcar", &mstp_clks[MSTP115]), /* SATA */
 	CLKDEV_DEV_ID("fc600000.sata", &mstp_clks[MSTP115]), /* SATA w/DT */
 	CLKDEV_DEV_ID("sh-eth", &mstp_clks[MSTP114]), /* Ether */
+	CLKDEV_DEV_ID("rcar_vin.0", &mstp_clks[MSTP110]), /* VIN0 */
+	CLKDEV_DEV_ID("rcar_vin.1", &mstp_clks[MSTP109]), /* VIN1 */
+	CLKDEV_DEV_ID("rcar_vin.2", &mstp_clks[MSTP108]), /* VIN2 */
 	CLKDEV_DEV_ID("ehci-platform.1", &mstp_clks[MSTP101]), /* USB EHCI port2 */
 	CLKDEV_DEV_ID("ohci-platform.1", &mstp_clks[MSTP101]), /* USB OHCI port2 */
 	CLKDEV_DEV_ID("ehci-platform.0", &mstp_clks[MSTP100]), /* USB EHCI port0/1 */
Index: renesas/arch/arm/mach-shmobile/include/mach/r8a7779.h
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/include/mach/r8a7779.h
+++ renesas/arch/arm/mach-shmobile/include/mach/r8a7779.h
@@ -5,6 +5,7 @@
 #include <linux/pm_domain.h>
 #include <linux/sh_eth.h>
 #include <linux/usb/rcar-phy.h>
+#include <linux/platform_data/camera-rcar.h>
 
 struct platform_device;
 
@@ -35,6 +36,8 @@ extern void r8a7779_add_standard_devices
 extern void r8a7779_add_standard_devices_dt(void);
 extern void r8a7779_add_ether_device(struct sh_eth_plat_data *pdata);
 extern void r8a7779_add_usb_phy_device(struct rcar_phy_platform_data *pdata);
+extern void r8a7779_add_vin_device(int idx,
+				   struct rcar_vin_platform_data *pdata);
 extern void r8a7779_init_late(void);
 extern void r8a7779_clock_init(void);
 extern void r8a7779_pinmux_init(void);
Index: renesas/arch/arm/mach-shmobile/setup-r8a7779.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/setup-r8a7779.c
+++ renesas/arch/arm/mach-shmobile/setup-r8a7779.c
@@ -559,6 +559,33 @@ static struct resource ether_resources[]
 	},
 };
 
+#define R8A7779_VIN(idx) \
+static struct resource vin##idx##_resources[] __initdata = {		\
+	DEFINE_RES_MEM(0xffc50000 + 0x1000 * (idx), 0x1000),		\
+	DEFINE_RES_IRQ(gic_iid(0x5f + (idx))),				\
+};									\
+									\
+static struct platform_device_info vin##idx##_info __initdata = {	\
+	.parent		= &platform_bus,				\
+	.name		= "rcar_vin",					\
+	.id		= idx,						\
+	.res		= vin##idx##_resources,				\
+	.num_res	= ARRAY_SIZE(vin##idx##_resources),		\
+	.dma_mask	= DMA_BIT_MASK(32),				\
+}
+
+R8A7779_VIN(0);
+R8A7779_VIN(1);
+R8A7779_VIN(2);
+R8A7779_VIN(3);
+
+static struct platform_device_info *vin_info_table[] __initdata = {
+	&vin0_info,
+	&vin1_info,
+	&vin2_info,
+	&vin3_info,
+};
+
 static struct platform_device *r8a7779_devices_dt[] __initdata = {
 	&scif0_device,
 	&scif1_device,
@@ -610,6 +637,17 @@ void __init r8a7779_add_usb_phy_device(s
 					  pdata, sizeof(*pdata));
 }
 
+void __init r8a7779_add_vin_device(int id,
+				   struct rcar_vin_platform_data *pdata)
+{
+	BUG_ON(id < 0 || id > 3);
+
+	vin_info_table[id]->data = pdata;
+	vin_info_table[id]->size_data = sizeof(struct rcar_vin_platform_data);
+
+	platform_device_register_full(vin_info_table[id]);
+}
+
 /* do nothing for !CONFIG_SMP or !CONFIG_HAVE_TWD */
 void __init __weak r8a7779_register_twd(void) { }
 


From sergei.shtylyov at cogentembedded.com  Tue Apr 23 13:13:29 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Tue, 23 Apr 2013 21:13:29 +0400
Subject: [PATCH v3 3/4] ARM: shmobile: Marzen: add VIN and ADV7180 support
In-Reply-To: <201304232106.45889.sergei.shtylyov@cogentembedded.com>
References: <201304232106.45889.sergei.shtylyov@cogentembedded.com>
Message-ID: <201304232113.30512.sergei.shtylyov@cogentembedded.com>

From: Vladimir Barinov <vladimir.barinov at cogentembedded.com>

Add ADV7180 platform devices on the Marzen board, configure VIN1/3 pins, and
register VIN1/3 devices with the ADV7180 specific platform data.

Signed-off-by: Vladimir Barinov <vladimir.barinov at cogentembedded.com>
[Sergei: removed superfluous tabulation and inserted empty lines in the  macro
definition, updated the copyrights, annotated VIN platform data as '__initdata']
Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

---
Changes since version 2:
- annotated 'vin_platform_data' as '__initdata' since they're kmemdup()'ed while
  registering the platform devices anyway.

Changes since the original posting:
- used a macro to define the camera platform devices;
- updated the copyrights;
- refreshed the patch.

 arch/arm/mach-shmobile/board-marzen.c |   44 +++++++++++++++++++++++++++++++++-
 1 file changed, 43 insertions(+), 1 deletion(-)

Index: renesas/arch/arm/mach-shmobile/board-marzen.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/board-marzen.c
+++ renesas/arch/arm/mach-shmobile/board-marzen.c
@@ -1,8 +1,9 @@
 /*
  * marzen board support
  *
- * Copyright (C) 2011  Renesas Solutions Corp.
+ * Copyright (C) 2011, 2013  Renesas Solutions Corp.
  * Copyright (C) 2011  Magnus Damm
+ * Copyright (C) 2013  Cogent Embedded, Inc.
  *
  * 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
@@ -37,6 +38,7 @@
 #include <linux/mmc/host.h>
 #include <linux/mmc/sh_mobile_sdhi.h>
 #include <linux/mfd/tmio.h>
+#include <media/soc_camera.h>
 #include <mach/hardware.h>
 #include <mach/r8a7779.h>
 #include <mach/common.h>
@@ -178,12 +180,40 @@ static struct platform_device leds_devic
 	},
 };
 
+static struct rcar_vin_platform_data vin_platform_data __initdata = {
+	.flags	= RCAR_VIN_BT656,
+};
+
+#define MARZEN_CAMERA(idx)					\
+static struct i2c_board_info camera##idx##_info = {		\
+	I2C_BOARD_INFO("adv7180", 0x20 + (idx)),		\
+};								\
+								\
+static struct soc_camera_link iclink##idx##_adv7180 = {		\
+	.bus_id		= 1 + 2 * (idx),			\
+	.i2c_adapter_id	= 0,					\
+	.board_info	= &camera##idx##_info,			\
+};								\
+								\
+static struct platform_device camera##idx##_device = {		\
+	.name	= "soc-camera-pdrv",				\
+	.id	= idx,						\
+	.dev	= {						\
+		.platform_data	= &iclink##idx##_adv7180,	\
+	},							\
+};
+
+MARZEN_CAMERA(0);
+MARZEN_CAMERA(1);
+
 static struct platform_device *marzen_devices[] __initdata = {
 	&eth_device,
 	&sdhi0_device,
 	&thermal_device,
 	&hspi_device,
 	&leds_device,
+	&camera0_device,
+	&camera1_device,
 };
 
 static const struct pinctrl_map marzen_pinctrl_map[] = {
@@ -219,6 +249,16 @@ static const struct pinctrl_map marzen_p
 	/* USB2 */
 	PIN_MAP_MUX_GROUP_DEFAULT("ehci-platform.1", "pfc-r8a7779",
 				  "usb2", "usb2"),
+	/* VIN1 */
+	PIN_MAP_MUX_GROUP_DEFAULT("rcar_vin.1", "pfc-r8a7779",
+				  "vin1_clk", "vin1"),
+	PIN_MAP_MUX_GROUP_DEFAULT("rcar_vin.1", "pfc-r8a7779",
+				  "vin1_data8", "vin1"),
+	/* VIN3 */
+	PIN_MAP_MUX_GROUP_DEFAULT("rcar_vin.3", "pfc-r8a7779",
+				  "vin3_clk", "vin3"),
+	PIN_MAP_MUX_GROUP_DEFAULT("rcar_vin.3", "pfc-r8a7779",
+				  "vin3_data8", "vin3"),
 };
 
 static void __init marzen_init(void)
@@ -235,6 +275,8 @@ static void __init marzen_init(void)
 
 	r8a7779_add_standard_devices();
 	r8a7779_add_usb_phy_device(&usb_phy_platform_data);
+	r8a7779_add_vin_device(1, &vin_platform_data);
+	r8a7779_add_vin_device(3, &vin_platform_data);
 	platform_add_devices(marzen_devices, ARRAY_SIZE(marzen_devices));
 }
 


From tony at atomide.com  Tue Apr 23 13:14:38 2013
From: tony at atomide.com (Tony Lindgren)
Date: Tue, 23 Apr 2013 10:14:38 -0700
Subject: [GIT PULL] omap dss board clean-up for v3.10 merge window
In-Reply-To: <5174F593.20705@ti.com>
References: <20130418033936.GC10155@atomide.com>
 <20130419184518.GA30836@quad.lixom.net> <5174F593.20705@ti.com>
Message-ID: <20130423171438.GC10155@atomide.com>

* Tomi Valkeinen <tomi.valkeinen at ti.com> [130422 01:37]:
> On 2013-04-19 21:45, Olof Johansson wrote:
> > Hi,
> > 
> > On Wed, Apr 17, 2013 at 08:39:37PM -0700, Tony Lindgren wrote:
> >> The following changes since commit 07961ac7c0ee8b546658717034fe692fd12eefa9:
> >>
> >>   Linux 3.9-rc5 (2013-03-31 15:12:43 -0700)
> >>
> >> are available in the git repository at:
> >>
> >>   git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.10/dss-signed
> > 
> > 
> > Merged, but not happy about it.
> 
> Thanks.
> 
> > As mentioned on IRC, I was going to let this one be until 3.11, but it sounds
> > like it will cause regressions in DSS if we don't merge it.
> 
> Yes, that's true. The branch has been unchanged and in linux-next, so
> merging it late shouldn't cause any bigger issues. But I understand it's
> quite late, and I should've pushed the branch forward much earlier.
> Sorry about that.
> 
> > This is an indication that the work wasn't done right on the DSS rework.
> > Ideally the old configurations through platform_data should have been left in
> > for a release to give the boards a window to convert over without regressing
> > functionality. Tomi, please don't do it this way in the future since it's
> > painful for everybody to deal with.
> 
> I've been trying to keep everything working even if parts of the whole
> series go through different trees. I've been very strict on that things
> must compile, but keeping display working if only half of the series is
> merged is rather difficult at times.
> 
> For this series, I think it could've been done, but it would have
> required adding hacks, or some kind of "bool new_pdata" fields so that
> the driver understand what to do. And duplicate code to manage the
> different platform data versions.
> 
> In the near future we'll get rid of the current custom omapdss panel
> device, and use the standard platform/i2c/etc devices for the panel. The
> only way to do that while keeping everything running is to clone the
> panel drivers, one handling the old one and the other handling the new one.
> 
> All this makes me spend lots of time doing extra work, that in no way
> improves the driver. Its only for the purpose of getting arch changes
> through one tree, and driver changes through the other. And this makes
> the patches much more difficult to follow, as the related changes are in
> separate series, and there may be extra crud just to handle this separation.
> 
> So while I think it is a good habit to push the arch changes and driver
> changes separately, my question is, should that rule be followed to the
> extreme? Can I just keep all the changes in one branch if separating the
> arch and driver changes would end up with cloning files or lots of extra
> code?

Shread branches are just fine. In most cases it's possible to add new
pdata and then remove the old pdata later on with follow-up patches.
 
> Of course, I don't know what DRM maintainer thinks of merging arch
> changes through his tree, so that's also open.

No let's not go there, Linus T already complained about the conflicts
between drivers/net and arch/arm/*omap*/ code few merge windows ago.
We need to remove the driver dependencies to the arch/arm code, otherwise
the merging requires way too much work from multiple maintainers. That
does not scale well and often leads into merge errors that could have
been avoided in the first place.

Of course the real solution here is to get things moved over to DT
based booting and then we don't have any of these dependencies as the
.dts changes can get merged separately from the driver changes.

Regards,

Tony


From sergei.shtylyov at cogentembedded.com  Tue Apr 23 13:15:23 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Tue, 23 Apr 2013 21:15:23 +0400
Subject: [PATCH v3 4/4] ARM: shmobile: Marzen: enable VIN and ADV7180 in
 defconfig
In-Reply-To: <201304232106.45889.sergei.shtylyov@cogentembedded.com>
References: <201304232106.45889.sergei.shtylyov@cogentembedded.com>
Message-ID: <201304232115.24523.sergei.shtylyov@cogentembedded.com>

From: Vladimir Barinov <vladimir.barinov at cogentembedded.com>

Add the VIN and ADV7180 drivers to 'marzen_defconfig'.

Signed-off-by: Vladimir Barinov <vladimir.barinov at cogentembedded.com>
Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

---
 arch/arm/configs/marzen_defconfig |    7 +++++++
 1 file changed, 7 insertions(+)

Index: renesas/arch/arm/configs/marzen_defconfig
===================================================================
--- renesas.orig/arch/arm/configs/marzen_defconfig
+++ renesas/arch/arm/configs/marzen_defconfig
@@ -84,6 +84,13 @@ CONFIG_GPIO_RCAR=y
 CONFIG_THERMAL=y
 CONFIG_RCAR_THERMAL=y
 CONFIG_SSB=y
+CONFIG_MEDIA_SUPPORT=y
+CONFIG_MEDIA_CAMERA_SUPPORT=y
+CONFIG_V4L_PLATFORM_DRIVERS=y
+CONFIG_SOC_CAMERA=y
+CONFIG_VIDEO_RCAR_VIN=y
+# CONFIG_MEDIA_SUBDRV_AUTOSELECT is not set
+CONFIG_VIDEO_ADV7180=y
 CONFIG_USB=y
 CONFIG_USB_RCAR_PHY=y
 CONFIG_MMC=y


From gregkh at linuxfoundation.org  Tue Apr 23 13:17:02 2013
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Tue, 23 Apr 2013 10:17:02 -0700
Subject: [PATCH 18/21] usb: phy: tegra: don't call into tegra-ehci directly
In-Reply-To: <1366734653-488286-19-git-send-email-arnd@arndb.de>
References: <1366734653-488286-1-git-send-email-arnd@arndb.de>
 <1366734653-488286-19-git-send-email-arnd@arndb.de>
Message-ID: <20130423171701.GA31397@kroah.com>

On Tue, Apr 23, 2013 at 06:30:50PM +0200, Arnd Bergmann wrote:
> Both phy-tegra-usb.c and ehci-tegra.c export symbols used by the other one,
> which does not work if one of them or both are loadable modules, resulting
> in an error like:
> 
> drivers/built-in.o: In function `utmi_phy_clk_disable':
> drivers/usb/phy/phy-tegra-usb.c:302: undefined reference to `tegra_ehci_set_phcd'
> drivers/built-in.o: In function `utmi_phy_clk_enable':
> drivers/usb/phy/phy-tegra-usb.c:324: undefined reference to `tegra_ehci_set_phcd'
> drivers/built-in.o: In function `utmi_phy_power_on':
> drivers/usb/phy/phy-tegra-usb.c:447: undefined reference to `tegra_ehci_set_pts'
> 
> This turns the interface into a one-way dependency by letting the tegra ehci
> driver pass two function pointers for callbacks that need to be called by
> the phy driver.
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Cc: Venu Byravarasu <vbyravarasu at nvidia.com>
> Cc: Alan Stern <stern at rowland.harvard.edu>
> Cc: Felipe Balbi <balbi at ti.com>
> Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
> Cc: Stephen Warren <swarren at nvidia.com>
> Cc: linux-usb at vger.kernel.org
> ---
>  drivers/usb/host/ehci-tegra.c     | 10 +++++-----
>  drivers/usb/phy/tegra_usb_phy.c   | 13 +++++++++----
>  include/linux/usb/tegra_usb_phy.h | 10 +++++-----
>  3 files changed, 19 insertions(+), 14 deletions(-)

Not all of these files are in my usb-next tree, so I can't take this
patch, sorry.

greg k-h


From gregkh at linuxfoundation.org  Tue Apr 23 13:17:34 2013
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Tue, 23 Apr 2013 10:17:34 -0700
Subject: [PATCH 19/21] usb: phy: don't mark usb_bind_phy as __init
In-Reply-To: <1366734653-488286-20-git-send-email-arnd@arndb.de>
References: <1366734653-488286-1-git-send-email-arnd@arndb.de>
 <1366734653-488286-20-git-send-email-arnd@arndb.de>
Message-ID: <20130423171734.GA31432@kroah.com>

On Tue, Apr 23, 2013 at 06:30:51PM +0200, Arnd Bergmann wrote:
> It makes no sense for a symbol to be both exported and marked __init,
> because any users in modules would be calling this function after
> it gets discarded. Further, this patch revolves a section mismatch
> warning from usbhs_init_phys(), which is intentionally not marked
> __init:
> 
> WARNING: vmlinux.o(.text+0x413f8): Section mismatch in reference from
> the function usbhs_init_phys() to the function .init.text:usb_bind_phy()
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Cc: Alan Stern <stern at rowland.harvard.edu>
> Cc: Felipe Balbi <balbi at ti.com>
> Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
> Cc: linux-usb at vger.kernel.org
> ---
>  drivers/usb/otg/otg.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

What tree has this file?  It's not mine :(



From sergei.shtylyov at cogentembedded.com  Tue Apr 23 13:18:42 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Tue, 23 Apr 2013 21:18:42 +0400
Subject: [PATCH v3 0/5] OKI ML86V7667 driver and R8A7778/BOCK-W VIN support
Message-ID: <201304232118.43686.sergei.shtylyov@cogentembedded.com>

Hello.

   Here's the set of 5 patches against the Simon Horman's 'renesas.git' repo,
'renesas-next-20130422' tag and my recent yet unapplied patches. Here we
add the OKI ML86V7667 video decoder driver and the VIN platform code working on
the R8A7778/BOCK-W with ML86V7667. The driver patch also applies (with offsets)
to Mauro's 'media_tree.git'...

[1/5] V4L2: I2C: ML86V7667 video decoder driver
[2/5] sh-pfc: r8a7778: add VIN pin groups
[3/5] ARM: shmobile: r8a7778: add VIN support
[4/5] ARM: shmobile: BOCK-W: add VIN and ML86V7667 support
[5/5] ARM: shmobile: BOCK-W: enable VIN and ML86V7667 in defconfig

WBR, Sergei


From sergei.shtylyov at cogentembedded.com  Tue Apr 23 13:21:34 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Tue, 23 Apr 2013 21:21:34 +0400
Subject: [PATCH v3 1/5] V4L2: I2C: ML86V7667 video decoder driver
In-Reply-To: <201304232118.43686.sergei.shtylyov@cogentembedded.com>
References: <201304232118.43686.sergei.shtylyov@cogentembedded.com>
Message-ID: <201304232121.35180.sergei.shtylyov@cogentembedded.com>

From: Vladimir Barinov <vladimir.barinov at cogentembedded.com>

Add OKI Semiconductor ML86V7667 video decoder driver.

Signed-off-by: Vladimir Barinov <vladimir.barinov at cogentembedded.com>
[Sergei: added v4l2_device_unregister_subdev() call to the error cleanup path of
ml86v7667_probe(); some cleanup.]
Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

---
Changes since version 2:
- removed now unused #include;
- fixed querystd() method to return currently detected video standard;
- switched from using V4L2_STD_[PAL|NTSC] to using V4L2_STD_[625_50|525_60].

Changes since the original posting:
- fixed ACCC_CHROMA_CB_MASK;
- got rid of the autodetection feature;
- removed querystd() method calls from other methods;
- removed deprecated g_chip_ident() method.

 drivers/media/i2c/Kconfig     |    9 
 drivers/media/i2c/Makefile    |    1 
 drivers/media/i2c/ml86v7667.c |  480 ++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 490 insertions(+)

Index: renesas/drivers/media/i2c/Kconfig
===================================================================
--- renesas.orig/drivers/media/i2c/Kconfig
+++ renesas/drivers/media/i2c/Kconfig
@@ -227,6 +227,15 @@ config VIDEO_KS0127
 	  To compile this driver as a module, choose M here: the
 	  module will be called ks0127.
 
+config VIDEO_ML86V7667
+	tristate "OKI ML86V7667 video decoder"
+	depends on VIDEO_V4L2 && I2C
+	---help---
+	  Support for the OKI Semiconductor ML86V7667 video decoder.
+
+	  To compile this driver as a module, choose M here: the
+	  module will be called ml86v7667.
+
 config VIDEO_SAA7110
 	tristate "Philips SAA7110 video decoder"
 	depends on VIDEO_V4L2 && I2C
Index: renesas/drivers/media/i2c/Makefile
===================================================================
--- renesas.orig/drivers/media/i2c/Makefile
+++ renesas/drivers/media/i2c/Makefile
@@ -64,3 +64,4 @@ obj-$(CONFIG_VIDEO_AS3645A)	+= as3645a.o
 obj-$(CONFIG_VIDEO_SMIAPP_PLL)	+= smiapp-pll.o
 obj-$(CONFIG_VIDEO_AK881X)		+= ak881x.o
 obj-$(CONFIG_VIDEO_IR_I2C)  += ir-kbd-i2c.o
+obj-$(CONFIG_VIDEO_ML86V7667)	+= ml86v7667.o
Index: renesas/drivers/media/i2c/ml86v7667.c
===================================================================
--- /dev/null
+++ renesas/drivers/media/i2c/ml86v7667.c
@@ -0,0 +1,480 @@
+/*
+ * OKI Semiconductor ML86V7667 video decoder driver
+ *
+ * Author: Vladimir Barinov <source at cogentembedded.com>
+ * Copyright (C) 2013 Cogent Embedded, Inc.
+ * Copyright (C) 2013 Renesas Solutions Corp.
+ *
+ * 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.
+ */
+
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/i2c.h>
+#include <linux/slab.h>
+#include <linux/videodev2.h>
+#include <media/v4l2-subdev.h>
+#include <media/v4l2-device.h>
+#include <media/v4l2-ioctl.h>
+#include <media/v4l2-ctrls.h>
+
+#define DRV_NAME "ml86v7667"
+
+/* Subaddresses */
+#define MRA_REG			0x00 /* Mode Register A */
+#define MRC_REG			0x02 /* Mode Register C */
+#define LUMC_REG		0x0C /* Luminance Control */
+#define CLC_REG			0x10 /* Contrast level control */
+#define SSEPL_REG		0x11 /* Sync separation level */
+#define CHRCA_REG		0x12 /* Chrominance Control A */
+#define ACCC_REG		0x14 /* ACC Loop filter & Chrominance control */
+#define ACCRC_REG		0x15 /* ACC Reference level control */
+#define HUE_REG			0x16 /* Hue control */
+#define ADC2_REG		0x1F /* ADC Register 2 */
+#define PLLR1_REG		0x20 /* PLL Register 1 */
+#define STATUS_REG		0x2C /* STATUS Register */
+
+/* Mode Register A register bits */
+#define MRA_OUTPUT_MODE_MASK	(3 << 6)
+#define MRA_ITUR_BT601		(1 << 6)
+#define MRA_ITUR_BT656		(0 << 6)
+#define MRA_INPUT_MODE_MASK	(7 << 3)
+#define MRA_PAL_BT601		(4 << 3)
+#define MRA_NTSC_BT601		(0 << 3)
+#define MRA_REGISTER_MODE	(1 << 0)
+
+/* Mode Register C register bits */
+#define MRC_AUTOSELECT		(1 << 7)
+
+/* Luminance Control register bits */
+#define LUMC_ONOFF_SHIFT	7
+#define LUMC_ONOFF_MASK		(1 << 7)
+
+/* Contrast level control register bits */
+#define CLC_CONTRAST_ONOFF	(1 << 7)
+#define CLC_CONTRAST_MASK	0x0F
+
+/* Sync separation level register bits */
+#define SSEPL_LUMINANCE_ONOFF	(1 << 7)
+#define SSEPL_LUMINANCE_MASK	0x7F
+
+/* Chrominance Control A register bits */
+#define CHRCA_MODE_SHIFT	6
+#define CHRCA_MODE_MASK		(1 << 6)
+
+/* ACC Loop filter & Chrominance control register bits */
+#define ACCC_CHROMA_CR_SHIFT	3
+#define ACCC_CHROMA_CR_MASK	(7 << 3)
+#define ACCC_CHROMA_CB_SHIFT	0
+#define ACCC_CHROMA_CB_MASK	(7 << 0)
+
+/* ACC Reference level control register bits */
+#define ACCRC_CHROMA_MASK	0xfc
+#define ACCRC_CHROMA_SHIFT	2
+
+/* ADC Register 2 register bits */
+#define ADC2_CLAMP_VOLTAGE_MASK	(7 << 1)
+#define ADC2_CLAMP_VOLTAGE(n)	((n & 7) << 1)
+
+/* PLL Register 1 register bits */
+#define PLLR1_FIXED_CLOCK	(1 << 7)
+
+/* STATUS Register register bits */
+#define STATUS_HLOCK_DETECT	(1 << 3)
+#define STATUS_NTSCPAL		(1 << 2)
+
+struct ml86v7667_priv {
+	struct v4l2_subdev		sd;
+	struct v4l2_ctrl_handler	hdl;
+	struct v4l2_mbus_framefmt	fmt;
+	v4l2_std_id			std;
+};
+
+static inline struct ml86v7667_priv *to_ml86v7667(struct v4l2_subdev *subdev)
+{
+	return container_of(subdev, struct ml86v7667_priv, sd);
+}
+
+static inline struct v4l2_subdev *to_sd(struct v4l2_ctrl *ctrl)
+{
+	return &container_of(ctrl->handler, struct ml86v7667_priv, hdl)->sd;
+}
+
+static int ml86v7667_mask_set(struct i2c_client *client, const u8 reg,
+			      const u8 mask, const u8 data)
+{
+	int val = i2c_smbus_read_byte_data(client, reg);
+	if (val < 0)
+		return val;
+
+	val = (val & ~mask) | (data & mask);
+	return i2c_smbus_write_byte_data(client, reg, val);
+}
+
+static int ml86v7667_s_ctrl(struct v4l2_ctrl *ctrl)
+{
+	struct v4l2_subdev *sd = to_sd(ctrl);
+	struct i2c_client *client = v4l2_get_subdevdata(sd);
+	int ret = 0;
+
+	switch (ctrl->id) {
+	case V4L2_CID_BRIGHTNESS:
+		ret = ml86v7667_mask_set(client, SSEPL_REG,
+					 SSEPL_LUMINANCE_MASK, ctrl->val);
+		break;
+	case V4L2_CID_CONTRAST:
+		ret = ml86v7667_mask_set(client, CLC_REG,
+					 CLC_CONTRAST_MASK, ctrl->val);
+		break;
+	case V4L2_CID_CHROMA_GAIN:
+		ret = ml86v7667_mask_set(client, ACCRC_REG, ACCRC_CHROMA_MASK,
+					 ctrl->val << ACCRC_CHROMA_SHIFT);
+		break;
+	case V4L2_CID_HUE:
+		ret = ml86v7667_mask_set(client, HUE_REG, ~0, ctrl->val);
+		break;
+	case V4L2_CID_RED_BALANCE:
+		ret = ml86v7667_mask_set(client, ACCC_REG,
+					 ACCC_CHROMA_CR_MASK,
+					 ctrl->val << ACCC_CHROMA_CR_SHIFT);
+		break;
+	case V4L2_CID_BLUE_BALANCE:
+		ret = ml86v7667_mask_set(client, ACCC_REG,
+					 ACCC_CHROMA_CB_MASK,
+					 ctrl->val << ACCC_CHROMA_CB_SHIFT);
+		break;
+	case V4L2_CID_SHARPNESS:
+		ret = ml86v7667_mask_set(client, LUMC_REG,
+					 LUMC_ONOFF_MASK,
+					 ctrl->val << LUMC_ONOFF_SHIFT);
+		break;
+	case V4L2_CID_COLOR_KILLER:
+		ret = ml86v7667_mask_set(client, CHRCA_REG,
+					 CHRCA_MODE_MASK,
+					 ctrl->val << CHRCA_MODE_SHIFT);
+		break;
+	}
+
+	return 0;
+}
+
+static int ml86v7667_querystd(struct v4l2_subdev *sd, v4l2_std_id *std)
+{
+	struct i2c_client *client = v4l2_get_subdevdata(sd);
+	int status;
+
+	status = i2c_smbus_read_byte_data(client, STATUS_REG);
+	if (status < 0)
+		return status;
+
+	if (!(status & STATUS_HLOCK_DETECT))
+		return V4L2_STD_UNKNOWN;
+
+	*std = status & STATUS_NTSCPAL ? V4L2_STD_625_50 : V4L2_STD_525_60;
+
+	return 0;
+}
+
+static int ml86v7667_g_input_status(struct v4l2_subdev *sd, u32 *status)
+{
+	struct i2c_client *client = v4l2_get_subdevdata(sd);
+	int status_reg;
+
+	status_reg = i2c_smbus_read_byte_data(client, STATUS_REG);
+	if (status_reg < 0)
+		return status_reg;
+
+	*status = status_reg & STATUS_HLOCK_DETECT ? 0 : V4L2_IN_ST_NO_SIGNAL;
+
+	return 0;
+}
+
+static int ml86v7667_enum_mbus_fmt(struct v4l2_subdev *sd, unsigned int index,
+				   enum v4l2_mbus_pixelcode *code)
+{
+	if (index > 0)
+		return -EINVAL;
+
+	*code = V4L2_MBUS_FMT_YUYV8_2X8;
+
+	return 0;
+}
+
+static int ml86v7667_try_mbus_fmt(struct v4l2_subdev *sd,
+				  struct v4l2_mbus_framefmt *fmt)
+{
+	struct ml86v7667_priv *priv = to_ml86v7667(sd);
+
+	fmt->code = V4L2_MBUS_FMT_YUYV8_2X8;
+	fmt->colorspace = V4L2_COLORSPACE_SMPTE170M;
+	fmt->field = V4L2_FIELD_INTERLACED;
+	fmt->width = 720;
+	fmt->height = priv->std & V4L2_STD_525_60 ? 480 : 576;
+
+	return 0;
+}
+
+static int ml86v7667_g_mbus_fmt(struct v4l2_subdev *sd,
+				struct v4l2_mbus_framefmt *fmt)
+{
+	struct ml86v7667_priv *priv = to_ml86v7667(sd);
+
+	*fmt = priv->fmt;
+
+	return 0;
+}
+
+static int ml86v7667_s_mbus_fmt(struct v4l2_subdev *sd,
+				struct v4l2_mbus_framefmt *fmt)
+{
+	struct ml86v7667_priv *priv = to_ml86v7667(sd);
+
+	ml86v7667_try_mbus_fmt(sd, fmt);
+	priv->fmt = *fmt;
+
+	return 0;
+}
+
+static int ml86v7667_cropcap(struct v4l2_subdev *sd, struct v4l2_cropcap *a)
+{
+	struct ml86v7667_priv *priv = to_ml86v7667(sd);
+
+	a->bounds.left = 0;
+	a->bounds.top = 0;
+	a->bounds.width = 720;
+	a->bounds.height = priv->std & V4L2_STD_525_60 ? 480 : 576;
+	a->defrect = a->bounds;
+	a->type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
+	a->pixelaspect.numerator = 1;
+	a->pixelaspect.denominator = 1;
+
+	return 0;
+}
+
+static int ml86v7667_g_mbus_config(struct v4l2_subdev *sd,
+				   struct v4l2_mbus_config *cfg)
+{
+	cfg->flags = V4L2_MBUS_MASTER | V4L2_MBUS_PCLK_SAMPLE_RISING |
+		     V4L2_MBUS_DATA_ACTIVE_HIGH;
+	cfg->type = V4L2_MBUS_BT656;
+
+	return 0;
+}
+
+static int ml86v7667_s_std(struct v4l2_subdev *sd, v4l2_std_id std)
+{
+	struct ml86v7667_priv *priv = to_ml86v7667(sd);
+	struct i2c_client *client = v4l2_get_subdevdata(&priv->sd);
+	int ret;
+	u8 mode;
+
+	/* PAL/NTSC ITU-R BT.601 input mode */
+	mode = std & V4L2_STD_525_60 ? MRA_NTSC_BT601 : MRA_PAL_BT601;
+	ret = ml86v7667_mask_set(client, MRA_REG, MRA_INPUT_MODE_MASK, mode);
+	if (ret < 0)
+		return ret;
+
+	priv->std = std;
+
+	return 0;
+}
+
+#ifdef CONFIG_VIDEO_ADV_DEBUG
+static int ml86v7667_g_register(struct v4l2_subdev *sd,
+				struct v4l2_dbg_register *reg)
+{
+	struct i2c_client *client = v4l2_get_subdevdata(sd);
+	int ret;
+
+	if (!v4l2_chip_match_i2c_client(client, &reg->match))
+		return -EINVAL;
+	if (!capable(CAP_SYS_ADMIN))
+		return -EPERM;
+
+	ret = i2c_smbus_read_byte_data(client, (u8)reg->reg);
+	if (ret < 0)
+		return ret;
+
+	reg->val = ret;
+	reg->size = sizeof(u8);
+
+	return 0;
+}
+
+static int ml86v7667_s_register(struct v4l2_subdev *sd,
+				struct v4l2_dbg_register *reg)
+{
+	struct i2c_client *client = v4l2_get_subdevdata(sd);
+
+	if (!v4l2_chip_match_i2c_client(client, &reg->match))
+		return -EINVAL;
+	if (!capable(CAP_SYS_ADMIN))
+		return -EPERM;
+
+	return i2c_smbus_write_byte_data(client, (u8)reg->reg, (u8)reg->val);
+}
+#endif
+
+static const struct v4l2_ctrl_ops ml86v7667_ctrl_ops = {
+	.s_ctrl = ml86v7667_s_ctrl,
+};
+
+static struct v4l2_subdev_video_ops ml86v7667_subdev_video_ops = {
+	.querystd = ml86v7667_querystd,
+	.g_input_status = ml86v7667_g_input_status,
+	.enum_mbus_fmt = ml86v7667_enum_mbus_fmt,
+	.try_mbus_fmt = ml86v7667_try_mbus_fmt,
+	.g_mbus_fmt = ml86v7667_g_mbus_fmt,
+	.s_mbus_fmt = ml86v7667_s_mbus_fmt,
+	.cropcap = ml86v7667_cropcap,
+	.g_mbus_config = ml86v7667_g_mbus_config,
+};
+
+static struct v4l2_subdev_core_ops ml86v7667_subdev_core_ops = {
+	.s_std = ml86v7667_s_std,
+#ifdef CONFIG_VIDEO_ADV_DEBUG
+	.g_register = ml86v7667_g_register,
+	.s_register = ml86v7667_s_register,
+#endif
+};
+
+static struct v4l2_subdev_ops ml86v7667_subdev_ops = {
+	.core = &ml86v7667_subdev_core_ops,
+	.video = &ml86v7667_subdev_video_ops,
+};
+
+static int ml86v7667_init(struct ml86v7667_priv *priv)
+{
+	struct i2c_client *client = v4l2_get_subdevdata(&priv->sd);
+	int val;
+	int ret;
+
+	/* BT.656-4 output mode, register mode */
+	ret = ml86v7667_mask_set(client, MRA_REG,
+				 MRA_OUTPUT_MODE_MASK | MRA_REGISTER_MODE,
+				 MRA_ITUR_BT656 | MRA_REGISTER_MODE);
+
+	/* PLL circuit fixed clock, 32MHz */
+	ret |= ml86v7667_mask_set(client, PLLR1_REG, PLLR1_FIXED_CLOCK,
+				  PLLR1_FIXED_CLOCK);
+
+	/* ADC2 clamping voltage maximum  */
+	ret |= ml86v7667_mask_set(client, ADC2_REG, ADC2_CLAMP_VOLTAGE_MASK,
+				  ADC2_CLAMP_VOLTAGE(7));
+
+	/* enable luminance function */
+	ret |= ml86v7667_mask_set(client, SSEPL_REG, SSEPL_LUMINANCE_ONOFF,
+				  SSEPL_LUMINANCE_ONOFF);
+
+	/* enable contrast function */
+	ret |= ml86v7667_mask_set(client, CLC_REG, CLC_CONTRAST_ONOFF, 0);
+
+	/*
+	 * PAL/NTSC autodetection is enabled after reset,
+	 * set the autodetected std in manual std mode and
+	 * disable autodetection
+	 */
+	val = i2c_smbus_read_byte_data(client, STATUS_REG);
+	if (val < 0)
+		return val;
+
+	priv->std = val & STATUS_NTSCPAL ? V4L2_STD_625_50 : V4L2_STD_525_60;
+	ret |= ml86v7667_mask_set(client, MRC_REG, MRC_AUTOSELECT, 0);
+
+	val = priv->std & V4L2_STD_525_60 ? MRA_NTSC_BT601 : MRA_PAL_BT601;
+	ret |= ml86v7667_mask_set(client, MRA_REG, MRA_INPUT_MODE_MASK, val);
+
+	return ret;
+}
+
+static int ml86v7667_probe(struct i2c_client *client,
+			   const struct i2c_device_id *did)
+{
+	struct ml86v7667_priv *priv;
+	int ret;
+
+	if (!i2c_check_functionality(client->adapter, I2C_FUNC_SMBUS_BYTE_DATA))
+		return -EIO;
+
+	priv = devm_kzalloc(&client->dev, sizeof(*priv), GFP_KERNEL);
+	if (!priv)
+		return -ENOMEM;
+
+	v4l2_i2c_subdev_init(&priv->sd, client, &ml86v7667_subdev_ops);
+
+	v4l2_ctrl_handler_init(&priv->hdl, 8);
+	v4l2_ctrl_new_std(&priv->hdl, &ml86v7667_ctrl_ops,
+			  V4L2_CID_BRIGHTNESS, -64, 63, 1, 0);
+	v4l2_ctrl_new_std(&priv->hdl, &ml86v7667_ctrl_ops,
+			  V4L2_CID_CONTRAST, -8, 7, 1, 0);
+	v4l2_ctrl_new_std(&priv->hdl, &ml86v7667_ctrl_ops,
+			  V4L2_CID_CHROMA_GAIN, -32, 31, 1, 0);
+	v4l2_ctrl_new_std(&priv->hdl, &ml86v7667_ctrl_ops,
+			  V4L2_CID_HUE, -128, 127, 1, 0);
+	v4l2_ctrl_new_std(&priv->hdl, &ml86v7667_ctrl_ops,
+			  V4L2_CID_RED_BALANCE, -4, 3, 1, 0);
+	v4l2_ctrl_new_std(&priv->hdl, &ml86v7667_ctrl_ops,
+			  V4L2_CID_BLUE_BALANCE, -4, 3, 1, 0);
+	v4l2_ctrl_new_std(&priv->hdl, &ml86v7667_ctrl_ops,
+			  V4L2_CID_SHARPNESS, 0, 1, 1, 0);
+	v4l2_ctrl_new_std(&priv->hdl, &ml86v7667_ctrl_ops,
+			  V4L2_CID_COLOR_KILLER, 0, 1, 1, 0);
+	priv->sd.ctrl_handler = &priv->hdl;
+
+	ret = priv->hdl.error;
+	if (ret)
+		goto cleanup;
+
+	v4l2_ctrl_handler_setup(&priv->hdl);
+
+	ret = ml86v7667_init(priv);
+	if (ret)
+		goto cleanup;
+
+	v4l_info(client, "chip found @ 0x%02x (%s)\n",
+		 client->addr, client->adapter->name);
+	return 0;
+
+cleanup:
+	v4l2_ctrl_handler_free(&priv->hdl);
+	v4l2_device_unregister_subdev(&priv->sd);
+	v4l_err(client, "failed to probe @ 0x%02x (%s)\n",
+		client->addr, client->adapter->name);
+	return ret;
+}
+
+static int ml86v7667_remove(struct i2c_client *client)
+{
+	struct v4l2_subdev *sd = i2c_get_clientdata(client);
+	struct ml86v7667_priv *priv = to_ml86v7667(sd);
+
+	v4l2_ctrl_handler_free(&priv->hdl);
+	v4l2_device_unregister_subdev(&priv->sd);
+
+	return 0;
+}
+
+static const struct i2c_device_id ml86v7667_id[] = {
+	{DRV_NAME, 0},
+	{},
+};
+MODULE_DEVICE_TABLE(i2c, ml86v7667_id);
+
+static struct i2c_driver ml86v7667_i2c_driver = {
+	.driver = {
+		.name	= DRV_NAME,
+		.owner	= THIS_MODULE,
+	},
+	.probe		= ml86v7667_probe,
+	.remove		= ml86v7667_remove,
+	.id_table	= ml86v7667_id,
+};
+
+module_i2c_driver(ml86v7667_i2c_driver);
+
+MODULE_DESCRIPTION("OKI Semiconductor ML86V7667 video decoder driver");
+MODULE_AUTHOR("Vladimir Barinov");
+MODULE_LICENSE("GPL");



From tony at atomide.com  Tue Apr 23 13:23:53 2013
From: tony at atomide.com (Tony Lindgren)
Date: Tue, 23 Apr 2013 10:23:53 -0700
Subject: Multiple issues with omap4 panda es in linux next
In-Reply-To: <5176A45B.5@ti.com>
References: <20130419171318.GK10155@atomide.com> <5174F7A8.7070308@ti.com>
 <20130422180316.GA10155@atomide.com> <5176A45B.5@ti.com>
Message-ID: <20130423172353.GD10155@atomide.com>

* Kishon Vijay Abraham I <kishon at ti.com> [130423 08:15]:
> >>>2. MUSB fails with legacy booting and DT on panda es
> >>>
> >>>With both legacy and DT booting I get something like:
> >>>
> >>>HS USB OTG: no transceiver configured
> >>>musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with status -517
> >>
> >>The dt should work fine with https://patchwork.kernel.org/patch/2423061/.
> >
> >OK thanks for checking that.
> >
> >>But non-dt has got a real issue. We were using usb_bind_phy() for
> >>binding the controller with the PHY (we use device names). But in
> >>linux-next the device names have changed because of using
> >>PLATFORM_DEVID_AUTO. We can modify the usb_bind_phy() calls to use
> >>the new device names, But I suspect the device names can change
> >>again. Not sure what we can do here :-(
> >
> >Let's do a minimal fix for v3.10. Then we'll make omap4 DT only for
> >v3.11 and that problem is solved for good.
> 
> Have posted a patch https://patchwork.kernel.org/patch/2475521/ for
> getting MUSB functional in omap4 panda.

OK thanks. Paul it seems that this patch is still queued in one of
your branches?

Let me know if you want me to pick that one up for fixes for the
merge window, or if you have multiple patches to pull.

Regards,

Tony


From cdall at cs.columbia.edu  Tue Apr 23 13:29:11 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Tue, 23 Apr 2013 10:29:11 -0700
Subject: [PATCH 04/21] ARM: kvm: define KVM_ARM_MAX_VCPUS unconditionally
In-Reply-To: <1366734653-488286-5-git-send-email-arnd@arndb.de>
References: <1366734653-488286-1-git-send-email-arnd@arndb.de>
 <1366734653-488286-5-git-send-email-arnd@arndb.de>
Message-ID: <CAEDV+gKEf5-uau8WxxuMk0+p0N5ba2AMKj8-O6kbZv1OiWDVpQ@mail.gmail.com>

On Tue, Apr 23, 2013 at 9:30 AM, Arnd Bergmann <arnd at arndb.de> wrote:
> The CONFIG_KVM_ARM_MAX_VCPUS symbol is needed in order to build the
> kernel/context_tracking.c code, which includes the vgic data structures
> implictly through the kvm headers. Definining the symbol to zero
> on builds without KVM resolves this build error:
>
> In file included from include/linux/kvm_host.h:33:0,
>                  from kernel/context_tracking.c:18:
> arch/arm/include/asm/kvm_host.h:28:23: warning: "CONFIG_KVM_ARM_MAX_VCPUS" is not defined [-Wundef]
>  #define KVM_MAX_VCPUS CONFIG_KVM_ARM_MAX_VCPUS
>                        ^
> arch/arm/include/asm/kvm_vgic.h:34:24: note: in expansion of macro 'KVM_MAX_VCPUS'
>  #define VGIC_MAX_CPUS  KVM_MAX_VCPUS
>                         ^
> arch/arm/include/asm/kvm_vgic.h:38:6: note: in expansion of macro 'VGIC_MAX_CPUS'
>  #if (VGIC_MAX_CPUS > 8)
>       ^
> In file included from arch/arm/include/asm/kvm_host.h:41:0,
>                  from include/linux/kvm_host.h:33,
>                  from kernel/context_tracking.c:18:
> arch/arm/include/asm/kvm_vgic.h:59:11: error: 'CONFIG_KVM_ARM_MAX_VCPUS' undeclared here (not in a function)
>   } percpu[VGIC_MAX_CPUS];
>            ^
>
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Cc: Marc Zyngier <marc.zyngier at arm.com>
> Cc: Christoffer Dall <cdall at cs.columbia.edu>
> Cc: Will Deacon <will.deacon at arm.com>
> ---
>  arch/arm/kvm/Kconfig | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/kvm/Kconfig b/arch/arm/kvm/Kconfig
> index 49dd64e..370e1a8 100644
> --- a/arch/arm/kvm/Kconfig
> +++ b/arch/arm/kvm/Kconfig
> @@ -41,9 +41,9 @@ config KVM_ARM_HOST
>           Provides host support for ARM processors.
>
>  config KVM_ARM_MAX_VCPUS
> -       int "Number maximum supported virtual CPUs per VM"
> -       depends on KVM_ARM_HOST
> -       default 4
> +       int "Number maximum supported virtual CPUs per VM" if KVM_ARM_HOST
> +       default 4 if KVM_ARM_HOST
> +       default 0
>         help
>           Static number of max supported virtual CPUs per VM.
>
> --
> 1.8.1.2
>

Acked-by: Christoffer Dall <cdall at cs.columbia.edu>


From mugunthanvnm at ti.com  Tue Apr 23 13:29:34 2013
From: mugunthanvnm at ti.com (Mugunthan V N)
Date: Tue, 23 Apr 2013 22:59:34 +0530
Subject: [PATCH] remove vlan tags in CPSW dual emac mode
In-Reply-To: <4699400.vD3TdgH1nR@localhost>
References: <4699400.vD3TdgH1nR@localhost>
Message-ID: <5176C4FE.4080305@ti.com>

On 4/23/2013 9:48 PM, Markus Brunner wrote:
> If operating in dual emac mode all packets sent by the CPSW contain vlan headers with the reserved VID 0,
> which gets stripped away by all somewhat recent Linux versions. Operating systems without that behaviour will fail to communicate.
> This patch fixes that behaviour by disabling the VLAN_AWARE mode as already described by the comment above.
>
> Signed-off-by: Markus Brunner <systemprogrammierung.brunner at gmail.com>
> Tested-by: Mark Jackson <mpfj at newflow.co.uk>
>
> ---
> --- linux-3.9-rc8.orig/drivers/net/ethernet/ti/cpsw.c	2013-04-23 17:26:11.000000000 +0200
> +++ linux-3.9-rc8/drivers/net/ethernet/ti/cpsw.c	2013-04-23 17:36:25.000000000 +0200
> @@ -751,9 +751,9 @@ static void cpsw_init_host_port(struct c
>   	/* switch to vlan unaware mode */
>   	cpsw_ale_control_set(priv->ale, priv->host_port, ALE_VLAN_AWARE,
>   			     CPSW_ALE_VLAN_AWARE);
>   	control_reg = readl(&priv->regs->control);
> -	control_reg |= CPSW_VLAN_AWARE;
> +	control_reg &= ~CPSW_VLAN_AWARE;
>   	writel(control_reg, &priv->regs->control);
>   	fifo_mode = (priv->data.dual_emac) ? CPSW_FIFO_DUAL_MAC_MODE :
>   		     CPSW_FIFO_NORMAL_MODE;
>   	writel(fifo_mode, &priv->host_port_regs->tx_in_ctl);
Disabling VLAN aware mode will enable switching mode and the feature of
separating the two down stream port is lost with this patch
Please check TRM for more info in *14.3.2.10.2 Dual Mac Mode* chapter

Regards
Mugunthan V N


From sergei.shtylyov at cogentembedded.com  Tue Apr 23 13:29:40 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Tue, 23 Apr 2013 21:29:40 +0400
Subject: [PATCH v3 3/5] ARM: shmobile: r8a7778: add VIN support
In-Reply-To: <201304232118.43686.sergei.shtylyov@cogentembedded.com>
References: <201304232118.43686.sergei.shtylyov@cogentembedded.com>
Message-ID: <201304232129.40773.sergei.shtylyov@cogentembedded.com>

From: Vladimir Barinov <vladimir.barinov at cogentembedded.com>

Add VIN clocks and platform devices on R8A7778 SoC; add function to register
the VIN platform devices.

Signed-off-by: Vladimir Barinov <vladimir.barinov at cogentembedded.com>
[Sergei: added 'id' parameter check to r8a7779_add_vin_device(), used '*pdata'
in *sizeof* operator there, renamed some variables, annotated 'vin[01]_info' and
vin[01]_resources[] as '__initdata'.]
Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

---
Changes from version 2:
- annotated 'vin[01]_info' and vin[01]_resources[] as '__initdata' since they're
  kmemdup()'ed while registering the platform devices anyway;
- refreshed the patch.

 arch/arm/mach-shmobile/clock-r8a7778.c        |    5 +++
 arch/arm/mach-shmobile/include/mach/r8a7778.h |    3 ++
 arch/arm/mach-shmobile/setup-r8a7778.c        |   33 ++++++++++++++++++++++++++
 3 files changed, 41 insertions(+)

Index: renesas/arch/arm/mach-shmobile/clock-r8a7778.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/clock-r8a7778.c
+++ renesas/arch/arm/mach-shmobile/clock-r8a7778.c
@@ -106,6 +106,7 @@ static struct clk *main_clks[] = {
 enum {
 	MSTP323, MSTP322, MSTP321,
 	MSTP114,
+	MSTP110, MSTP109,
 	MSTP100,
 	MSTP030, MSTP029,
 	MSTP028, MSTP027, MSTP026, MSTP025, MSTP024, MSTP023, MSTP022, MSTP021,
@@ -117,6 +118,8 @@ static struct clk mstp_clks[MSTP_NR] = {
 	[MSTP322] = SH_CLK_MSTP32(&p_clk, MSTPCR3, 22, 0), /* SDHI1 */
 	[MSTP321] = SH_CLK_MSTP32(&p_clk, MSTPCR3, 21, 0), /* SDHI2 */
 	[MSTP114] = SH_CLK_MSTP32(&p_clk, MSTPCR1, 14, 0), /* Ether */
+	[MSTP110] = SH_CLK_MSTP32(&s_clk, MSTPCR1, 10, 0), /* VIN0 */
+	[MSTP109] = SH_CLK_MSTP32(&s_clk, MSTPCR1,  9, 0), /* VIN1 */
 	[MSTP100] = SH_CLK_MSTP32(&p_clk, MSTPCR1,  0, 0), /* USB0/1 */
 	[MSTP030] = SH_CLK_MSTP32(&p_clk, MSTPCR0, 30, 0), /* I2C0 */
 	[MSTP029] = SH_CLK_MSTP32(&p_clk, MSTPCR0, 29, 0), /* I2C1 */
@@ -140,6 +143,8 @@ static struct clk_lookup lookups[] = {
 	CLKDEV_DEV_ID("sh_mobile_sdhi.1", &mstp_clks[MSTP322]), /* SDHI1 */
 	CLKDEV_DEV_ID("sh_mobile_sdhi.2", &mstp_clks[MSTP321]), /* SDHI2 */
 	CLKDEV_DEV_ID("sh-eth",	&mstp_clks[MSTP114]), /* Ether */
+	CLKDEV_DEV_ID("rcar_vin.0", &mstp_clks[MSTP110]), /* VIN0 */
+	CLKDEV_DEV_ID("rcar_vin.1", &mstp_clks[MSTP109]), /* VIN1 */
 	CLKDEV_DEV_ID("ehci-platform", &mstp_clks[MSTP100]), /* USB EHCI port0/1 */
 	CLKDEV_DEV_ID("ohci-platform", &mstp_clks[MSTP100]), /* USB OHCI port0/1 */
 	CLKDEV_DEV_ID("i2c-rcar.0", &mstp_clks[MSTP030]), /* I2C0 */
Index: renesas/arch/arm/mach-shmobile/include/mach/r8a7778.h
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/include/mach/r8a7778.h
+++ renesas/arch/arm/mach-shmobile/include/mach/r8a7778.h
@@ -21,11 +21,14 @@
 #include <linux/mmc/sh_mobile_sdhi.h>
 #include <linux/sh_eth.h>
 #include <linux/usb/rcar-phy.h>
+#include <linux/platform_data/camera-rcar.h>
 
 extern void r8a7778_add_standard_devices(void);
 extern void r8a7778_add_standard_devices_dt(void);
 extern void r8a7778_add_ether_device(struct sh_eth_plat_data *pdata);
 extern void r8a7778_add_usb_phy_device(struct rcar_phy_platform_data *pdata);
+extern void r8a7778_add_vin_device(int id,
+				   struct rcar_vin_platform_data *pdata);
 extern void r8a7778_init_late(void);
 extern void r8a7778_init_delay(void);
 extern void r8a7778_init_irq(void);
Index: renesas/arch/arm/mach-shmobile/setup-r8a7778.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/setup-r8a7778.c
+++ renesas/arch/arm/mach-shmobile/setup-r8a7778.c
@@ -299,6 +299,39 @@ void __init r8a7778_sdhi_init(int id,
 		info, sizeof(*info));
 }
 
+/* VIN */
+#define R8A7778_VIN(idx)						\
+static struct resource vin##idx##_resources[] __initdata = {		\
+	DEFINE_RES_MEM(0xffc50000 + 0x1000 * (idx), 0x1000),		\
+	DEFINE_RES_IRQ(gic_iid(0x5a)),					\
+};									\
+									\
+static struct platform_device_info vin##idx##_info __initdata = {	\
+	.parent		= &platform_bus,				\
+	.name		= "rcar_vin",					\
+	.id		= idx,						\
+	.res		= vin##idx##_resources,				\
+	.num_res	= ARRAY_SIZE(vin##idx##_resources),		\
+	.dma_mask	= DMA_BIT_MASK(32),				\
+}
+
+R8A7778_VIN(0);
+R8A7778_VIN(1);
+
+static struct platform_device_info *vin_info_table[] __initdata = {
+	&vin0_info,
+	&vin1_info,
+};
+
+void __init r8a7778_add_vin_device(int id, struct rcar_vin_platform_data *pdata)
+{
+	BUG_ON(id < 0 || id > 1);
+
+	vin_info_table[id]->data = pdata;
+	vin_info_table[id]->size_data = sizeof(*pdata);
+	platform_device_register_full(vin_info_table[id]);
+}
+
 void __init r8a7778_add_standard_devices(void)
 {
 	int i;



From tony at atomide.com  Tue Apr 23 13:31:07 2013
From: tony at atomide.com (Tony Lindgren)
Date: Tue, 23 Apr 2013 10:31:07 -0700
Subject: Multiple issues with omap4 panda es in linux next
In-Reply-To: <51769248.60602@ti.com>
References: <20130419171318.GK10155@atomide.com> <5174FE16.6080307@ti.com>
 <51750FF8.6000401@ti.com> <51752B48.50700@ti.com>
 <20130422180822.GB10155@atomide.com> <51769248.60602@ti.com>
Message-ID: <20130423173107.GE10155@atomide.com>

* Grygorii Strashko <grygorii.strashko at ti.com> [130423 06:59]:
> 
> I've posted two patches to fix I2C/TWL initialization and they should fix
> DSS indirectly (if not - DSS need to be shifted to init later).
> lkml.org/lkml/2013/4/23/215
> lkml.org/lkml/2013/4/23/217

OK, thanks. We may want to wait a bit on those, but I'll reply to
that thread.

> In addition, It seems, possibly :), drivers/Makefile might need to
> be changed a bit:
> - move generic drivers framework to be initialized first ("base", "clk");
> - move "i2c" buses initialization as early as possible (but after
> "pinctrl" and "gpio")
> - move "mfd" initialization before "regulators"
> - move "video" initialization down after "regulators" (as minimum).

I doubt that we want to start messing with the current ordering
of the drivers/Makefile. That always breaks something else, and
the real fix is to get -EPROBE_DEFER to work for us.

With the DSS there are way too many dependencies to various other
drivers to try to initialize it early. We're better off just fixing
it to work with -EPROBE_DEFER.

Regards,

Tony


From cdall at cs.columbia.edu  Tue Apr 23 13:32:31 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Tue, 23 Apr 2013 10:32:31 -0700
Subject: [PATCH 04/21] ARM: kvm: define KVM_ARM_MAX_VCPUS unconditionally
In-Reply-To: <CAEDV+gKEf5-uau8WxxuMk0+p0N5ba2AMKj8-O6kbZv1OiWDVpQ@mail.gmail.com>
References: <1366734653-488286-1-git-send-email-arnd@arndb.de>
 <1366734653-488286-5-git-send-email-arnd@arndb.de>
 <CAEDV+gKEf5-uau8WxxuMk0+p0N5ba2AMKj8-O6kbZv1OiWDVpQ@mail.gmail.com>
Message-ID: <CAEDV+gKsdEKzbq3f-hSBK7bFdFRvuqYfcfU9Rs27hpyykxjoPw@mail.gmail.com>

On Tue, Apr 23, 2013 at 10:29 AM, Christoffer Dall
<cdall at cs.columbia.edu> wrote:
> On Tue, Apr 23, 2013 at 9:30 AM, Arnd Bergmann <arnd at arndb.de> wrote:
>> The CONFIG_KVM_ARM_MAX_VCPUS symbol is needed in order to build the
>> kernel/context_tracking.c code, which includes the vgic data structures
>> implictly through the kvm headers. Definining the symbol to zero
>> on builds without KVM resolves this build error:
>>
>> In file included from include/linux/kvm_host.h:33:0,
>>                  from kernel/context_tracking.c:18:
>> arch/arm/include/asm/kvm_host.h:28:23: warning: "CONFIG_KVM_ARM_MAX_VCPUS" is not defined [-Wundef]
>>  #define KVM_MAX_VCPUS CONFIG_KVM_ARM_MAX_VCPUS
>>                        ^
>> arch/arm/include/asm/kvm_vgic.h:34:24: note: in expansion of macro 'KVM_MAX_VCPUS'
>>  #define VGIC_MAX_CPUS  KVM_MAX_VCPUS
>>                         ^
>> arch/arm/include/asm/kvm_vgic.h:38:6: note: in expansion of macro 'VGIC_MAX_CPUS'
>>  #if (VGIC_MAX_CPUS > 8)
>>       ^
>> In file included from arch/arm/include/asm/kvm_host.h:41:0,
>>                  from include/linux/kvm_host.h:33,
>>                  from kernel/context_tracking.c:18:
>> arch/arm/include/asm/kvm_vgic.h:59:11: error: 'CONFIG_KVM_ARM_MAX_VCPUS' undeclared here (not in a function)
>>   } percpu[VGIC_MAX_CPUS];
>>            ^
>>
>> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
>> Cc: Marc Zyngier <marc.zyngier at arm.com>
>> Cc: Christoffer Dall <cdall at cs.columbia.edu>
>> Cc: Will Deacon <will.deacon at arm.com>
>> ---
>>  arch/arm/kvm/Kconfig | 6 +++---
>>  1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/arm/kvm/Kconfig b/arch/arm/kvm/Kconfig
>> index 49dd64e..370e1a8 100644
>> --- a/arch/arm/kvm/Kconfig
>> +++ b/arch/arm/kvm/Kconfig
>> @@ -41,9 +41,9 @@ config KVM_ARM_HOST
>>           Provides host support for ARM processors.
>>
>>  config KVM_ARM_MAX_VCPUS
>> -       int "Number maximum supported virtual CPUs per VM"
>> -       depends on KVM_ARM_HOST
>> -       default 4
>> +       int "Number maximum supported virtual CPUs per VM" if KVM_ARM_HOST
>> +       default 4 if KVM_ARM_HOST
>> +       default 0
>>         help
>>           Static number of max supported virtual CPUs per VM.
>>
>> --
>> 1.8.1.2
>>
>
> Acked-by: Christoffer Dall <cdall at cs.columbia.edu>

actually let me just pull that into my tree. thanks.


From sergei.shtylyov at cogentembedded.com  Tue Apr 23 13:32:52 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Tue, 23 Apr 2013 21:32:52 +0400
Subject: [PATCH v3 4/5] ARM: shmobile: BOCK-W: add VIN and ML86V7667 support
In-Reply-To: <201304232118.43686.sergei.shtylyov@cogentembedded.com>
References: <201304232118.43686.sergei.shtylyov@cogentembedded.com>
Message-ID: <201304232132.52741.sergei.shtylyov@cogentembedded.com>

From: Vladimir Barinov <vladimir.barinov at cogentembedded.com>

Add ML86V7667 platform devices on BOCK-W board, configure VIN0/1 pins, and
register VIN0/1 devices with the ML86V7667 specific platform data.

Signed-off-by: Vladimir Barinov <vladimir.barinov at cogentembedded.com>
[Sergei: some macro/comment cleanup; updated the copyrights, removed duplicate
#include, annotated all platform data as '__initdata'.]
Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

---
Changes since version 2:
- removed duplicate #include <linux/pinctrl/machine.h>;
- annotated all platform data as '__initdata' since they're kmemdup()'ed while
  registering the platform devices anyway;
- resolved rejects, refreshed the patch.

 arch/arm/mach-shmobile/board-bockw.c |   39 +++++++++++++++++++++++++++++++++++
 1 file changed, 39 insertions(+)

Index: renesas/arch/arm/mach-shmobile/board-bockw.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/board-bockw.c
+++ renesas/arch/arm/mach-shmobile/board-bockw.c
@@ -3,6 +3,7 @@
  *
  * Copyright (C) 2013  Renesas Solutions Corp.
  * Copyright (C) 2013  Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
+ * Copyright (C) 2013  Cogent Embedded, Inc.
  *
  * 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
@@ -25,6 +26,7 @@
 #include <linux/regulator/fixed.h>
 #include <linux/regulator/machine.h>
 #include <linux/smsc911x.h>
+#include <media/soc_camera.h>
 #include <mach/common.h>
 #include <mach/irqs.h>
 #include <mach/r8a7778.h>
@@ -65,6 +67,25 @@ static struct sh_mobile_sdhi_info sdhi0_
 
 static struct rcar_phy_platform_data usb_phy_platform_data __initdata;
 
+static struct rcar_vin_platform_data vin_platform_data __initdata = {
+	.flags	= RCAR_VIN_BT656,
+};
+
+/* In the default configuration both decoders reside on I2C bus 0 */
+#define BOCKW_CAMERA(idx)						\
+static struct i2c_board_info camera##idx##_info = {			\
+	I2C_BOARD_INFO("ml86v7667", 0x41 + 2 * (idx)),			\
+};									\
+									\
+static struct soc_camera_link iclink##idx##_ml86v7667 __initdata = {	\
+	.bus_id		= idx,						\
+	.i2c_adapter_id	= 0,						\
+	.board_info	= &camera##idx##_info,				\
+};
+
+BOCKW_CAMERA(0);
+BOCKW_CAMERA(1);
+
 static const struct pinctrl_map bockw_pinctrl_map[] = {
 	/* SCIF0 */
 	PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.0", "pfc-r8a7778",
@@ -80,6 +101,16 @@ static const struct pinctrl_map bockw_pi
 				  "sdhi0_data4", "sdhi0"),
 	PIN_MAP_MUX_GROUP_DEFAULT("sh_mobile_sdhi.0", "pfc-r8a7778",
 				  "sdhi0_wp", "sdhi0"),
+	/* VIN0 */
+	PIN_MAP_MUX_GROUP_DEFAULT("rcar_vin.0", "pfc-r8a7778",
+				  "vin0_clk", "vin0"),
+	PIN_MAP_MUX_GROUP_DEFAULT("rcar_vin.0", "pfc-r8a7778",
+				  "vin0_data8", "vin0"),
+	/* VIN1 */
+	PIN_MAP_MUX_GROUP_DEFAULT("rcar_vin.1", "pfc-r8a7778",
+				  "vin1_clk", "vin1"),
+	PIN_MAP_MUX_GROUP_DEFAULT("rcar_vin.1", "pfc-r8a7778",
+				  "vin1_data8", "vin1"),
 };
 
 #define FPGA	0x18200000
@@ -94,6 +125,14 @@ static void __init bockw_init(void)
 	r8a7778_init_irq_extpin(1);
 	r8a7778_add_standard_devices();
 	r8a7778_add_usb_phy_device(&usb_phy_platform_data);
+	r8a7778_add_vin_device(0, &vin_platform_data);
+	r8a7778_add_vin_device(1, &vin_platform_data);
+	platform_device_register_data(&platform_bus, "soc-camera-pdrv", 0,
+				      &iclink0_ml86v7667,
+				      sizeof(iclink0_ml86v7667));
+	platform_device_register_data(&platform_bus, "soc-camera-pdrv", 1,
+				      &iclink1_ml86v7667,
+				      sizeof(iclink1_ml86v7667));
 
 	pinctrl_register_mappings(bockw_pinctrl_map,
 				  ARRAY_SIZE(bockw_pinctrl_map));



From sergei.shtylyov at cogentembedded.com  Tue Apr 23 13:34:51 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Tue, 23 Apr 2013 21:34:51 +0400
Subject: [PATCH v3 5/5] ARM: shmobile: BOCK-W: enable VIN and ML86V7667 in
 defconfig
In-Reply-To: <201304232118.43686.sergei.shtylyov@cogentembedded.com>
References: <201304232118.43686.sergei.shtylyov@cogentembedded.com>
Message-ID: <201304232134.52153.sergei.shtylyov@cogentembedded.com>

From: Vladimir Barinov <vladimir.barinov at cogentembedded.com>

Add the VIN and ML86V7667 drivers to 'bockw_defconfig'.

Signed-off-by: Vladimir Barinov <vladimir.barinov at cogentembedded.com>
Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

---
 arch/arm/configs/bockw_defconfig |    7 +++++++
 1 file changed, 7 insertions(+)

Index: renesas/arch/arm/configs/bockw_defconfig
===================================================================
--- renesas.orig/arch/arm/configs/bockw_defconfig
+++ renesas/arch/arm/configs/bockw_defconfig
@@ -76,6 +76,13 @@ CONFIG_SERIAL_SH_SCI_CONSOLE=y
 # CONFIG_HWMON is not set
 CONFIG_I2C=y
 CONFIG_I2C_RCAR=y
+CONFIG_MEDIA_SUPPORT=y
+CONFIG_MEDIA_CAMERA_SUPPORT=y
+CONFIG_V4L_PLATFORM_DRIVERS=y
+CONFIG_SOC_CAMERA=y
+CONFIG_VIDEO_RCAR_VIN=y
+# CONFIG_MEDIA_SUBDRV_AUTOSELECT is not set
+CONFIG_VIDEO_ML86V7667=y
 CONFIG_USB=y
 CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
 CONFIG_USB_EHCI_HCD=y



From tony at atomide.com  Tue Apr 23 13:36:23 2013
From: tony at atomide.com (Tony Lindgren)
Date: Tue, 23 Apr 2013 10:36:23 -0700
Subject: [PATCH] ARM: OMAP4: change the device names in usb_bind_phy
In-Reply-To: <1366697656-14315-1-git-send-email-kishon@ti.com>
References: <1366697656-14315-1-git-send-email-kishon@ti.com>
Message-ID: <20130423173623.GG10155@atomide.com>

* Kishon Vijay Abraham I <kishon at ti.com> [130422 23:19]:
> After the device names are created using PLATFORM_DEVID_AUTO, the old
> device names given in usb_bind_phy are no longer valid causing the musb
> controller not to get the phy reference. Updated the usb_bind_phy with
> the new device names to get MUSB functional in omap4 panda.

Thanks will apply this into omap-for-v3.10/fixes.

Regards,

Tony
 
> Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
> ---
> Tested in OMAP4 PANDA.
>  arch/arm/mach-omap2/board-4430sdp.c    |    2 +-
>  arch/arm/mach-omap2/board-omap4panda.c |    2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c
> index 00d7290..56a9a4f 100644
> --- a/arch/arm/mach-omap2/board-4430sdp.c
> +++ b/arch/arm/mach-omap2/board-4430sdp.c
> @@ -730,7 +730,7 @@ static void __init omap_4430sdp_init(void)
>  	omap4_sdp4430_wifi_init();
>  	omap4_twl6030_hsmmc_init(mmc);
>  
> -	usb_bind_phy("musb-hdrc.0.auto", 0, "omap-usb2.1.auto");
> +	usb_bind_phy("musb-hdrc.2.auto", 0, "omap-usb2.3.auto");
>  	usb_musb_init(&musb_board_data);
>  
>  	status = omap_ethernet_init();
> diff --git a/arch/arm/mach-omap2/board-omap4panda.c b/arch/arm/mach-omap2/board-omap4panda.c
> index a71ad34..1e2c75e 100644
> --- a/arch/arm/mach-omap2/board-omap4panda.c
> +++ b/arch/arm/mach-omap2/board-omap4panda.c
> @@ -435,7 +435,7 @@ static void __init omap4_panda_init(void)
>  	omap_sdrc_init(NULL, NULL);
>  	omap4_twl6030_hsmmc_init(mmc);
>  	omap4_ehci_init();
> -	usb_bind_phy("musb-hdrc.0.auto", 0, "omap-usb2.1.auto");
> +	usb_bind_phy("musb-hdrc.2.auto", 0, "omap-usb2.3.auto");
>  	usb_musb_init(&musb_board_data);
>  	omap4_panda_display_init();
>  }
> -- 
> 1.7.10.4
> 


From s.hauer at pengutronix.de  Tue Apr 23 13:43:59 2013
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Tue, 23 Apr 2013 19:43:59 +0200
Subject: [RFC][PATCH] video: imx: Select VIDEOMODE_HELPERS
In-Reply-To: <201304231229.48511.marex@denx.de>
References: <1366666110-9585-1-git-send-email-marex@denx.de>
 <201304230157.47992.marex@denx.de>
 <20130423050745.GO32299@pengutronix.de>
 <201304231229.48511.marex@denx.de>
Message-ID: <20130423174359.GT32299@pengutronix.de>

On Tue, Apr 23, 2013 at 12:29:48PM +0200, Marek Vasut wrote:
> Dear Sascha Hauer,
> 
> > On Tue, Apr 23, 2013 at 01:57:47AM +0200, Marek Vasut wrote:
> > > Dear Fabio Estevam,
> > > 
> > > > Hi Marek,
> > > > 
> > > > On Mon, Apr 22, 2013 at 6:28 PM, Marek Vasut <marex at denx.de> wrote:
> > > > > Without this, I get the following problem when building kernel:
> > > > > 
> > > > > drivers/built-in.o: In function `imx_pd_connector_get_modes':
> > > > > /linux-2.6/drivers/staging/imx-drm/parallel-display.c:78: undefined
> > > > > reference to `of_get_drm_display_mode' make: *** [vmlinux] Error 1
> > > > > 
> > > > > NOTE: I think this patch is almost absolutely not correct.
> > > > > 
> > > > > Signed-off-by: Marek Vasut <marex at denx.de>
> > > > > Cc: Sascha Hauer <s.hauer at pengutronix.de>
> > > > > Cc: Philipp Zabel <p.zabel at pengutronix.de>
> > > > > Cc: Fabio Estevam <fabio.estevam at freescale.com>
> > > > 
> > > > Patch looks good, but you should have copied Greg Kroah-Hartman, as he
> > > > is the one who takes patches into staging.
> > > 
> > > I'm not sure if the select is at correct symbol, I dont think it is.
> > 
> > No it's not. The parallel display driver needs it, not the i.MX drm
> > support in general.
> 
> Yep, I expected this coming, thus RFC. I'll roll out new patch and move this to 
> parallel display, ok?

ok

Sascha


-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From olof at lixom.net  Tue Apr 23 13:59:34 2013
From: olof at lixom.net (Olof Johansson)
Date: Tue, 23 Apr 2013 10:59:34 -0700
Subject: [GIT PULL] OMAP PM cleanups for v3.10
In-Reply-To: <20130410181452.GG10155@atomide.com>
References: <87ehej1ena.fsf@linaro.org>
 <20130410181452.GG10155@atomide.com>
Message-ID: <20130423175934.GA6728@quad.lixom.net>

On Wed, Apr 10, 2013 at 11:14:52AM -0700, Tony Lindgren wrote:
> Hi,
> 
> Added Olof to cc, I suggest Olof pull this directly as we're starting
> to run out of time.

Hi,

I'm terribly sorry for dropping this one on the floor, in spite of repeated
pings from Tony. :(

If it wasn't for the fact that we're pushing back on some of the other
late submissions I'd be open to taking this, but to be fair it makes
more sense to merge it right after -rc1. The changes don't look like
they're truly critical for 3.10, and you should still be able to use
this as a base for your 3.11 changes, so hopefully this doesn't cause
too much trouble.

So, please resend right after the merge window closes.


-Olof


From sergei.shtylyov at cogentembedded.com  Tue Apr 23 14:00:06 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Tue, 23 Apr 2013 22:00:06 +0400
Subject: [PATCH v3 4/4] ARM: shmobile: BOCK-W: enable USB in defconfig
In-Reply-To: <20130422040043.GJ15680@verge.net.au>
References: <201304170135.10251.sergei.shtylyov@cogentembedded.com>
 <20130418140552.GO20929@verge.net.au> <5170789D.5020108@cogentembedded.com>
 <20130419021414.GB25718@verge.net.au> <5171A7D8.2010000@cogentembedded.com>
 <20130422040043.GJ15680@verge.net.au>
Message-ID: <5176CC26.8010705@cogentembedded.com>

Hello.

On 04/22/2013 08:00 AM, Simon Horman wrote:

>>>>>> Enable USB platform EHCI/OHCI and common PHY drivers in 'bockw_defconfig'.
>>>>>> Enable USB storage driver and SCSI disk driver that it needs as well...
>>>>>>
>>>>>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
>>>>> I realise that this is not going to be useful until the rest
>>>>> of the series has been merged. But regardless I have pre-emptively
>>>>> queued it up for v3.11 in the defconfig-bockw branch.
>>>>>> ---
>>>>>>   arch/arm/configs/bockw_defconfig |   11 ++++++++++-
>>>>>>   1 file changed, 10 insertions(+), 1 deletion(-)
>>>>>>
>>>>>> Index: renesas/arch/arm/configs/bockw_defconfig
>>>>>> ===================================================================
>>>>>> --- renesas.orig/arch/arm/configs/bockw_defconfig
>>>>>> +++ renesas/arch/arm/configs/bockw_defconfig
>>>>>> @@ -48,6 +48,8 @@ CONFIG_DEVTMPFS_MOUNT=y
>>>>>>   # CONFIG_STANDALONE is not set
>>>>>>   # CONFIG_PREVENT_FIRMWARE_BUILD is not set
>>>>>>   # CONFIG_FW_LOADER is not set
>>>>>> +CONFIG_SCSI=y
>>>>>> +CONFIG_BLK_DEV_SD=y
>>>>>>   CONFIG_NETDEVICES=y
>>>>>>   # CONFIG_NET_CADENCE is not set
>>>>>>   # CONFIG_NET_VENDOR_BROADCOM is not set
>>>>>> @@ -71,7 +73,14 @@ CONFIG_SERIAL_SH_SCI_NR_UARTS=6
>>>>>>   CONFIG_SERIAL_SH_SCI_CONSOLE=y
>>>>>>   # CONFIG_HW_RANDOM is not set
>>>>>>   # CONFIG_HWMON is not set
>>>>>> -# CONFIG_USB_SUPPORT is not set
>>>>>> +CONFIG_USB=y
>>>>>> +CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
>>>>>> +CONFIG_USB_EHCI_HCD=y
>>>>>> +CONFIG_USB_OHCI_HCD=y
>>>>>> +CONFIG_USB_OHCI_HCD_PLATFORM=y
>>>>>> +CONFIG_USB_EHCI_HCD_PLATFORM=y
>>>>>> +CONFIG_USB_STORAGE=y
>>>>>> +CONFIG_USB_RCAR_PHY=y
>>>>>>
>>>>     Unfortunately, you've made a mistake in this last line of the patch:
>>>> you've truncated it to just "CONFIG_USB_RCAR". :-(
>>>>     Will you correct it?
>>> Sorry about that, I will fix it.
>>      Sorry to say, but you fixed it the wrong way; now it's:
>>
>> +CONFIG_USB_RCAR=y
>>
>> instead of:
>>
>> +CONFIG_USB_RCAR_PHY=y
> Sorry for my carelessness.
> I will forcibly push the following:
>
>  From 26b78f5c9ad1e4809f6d0a5547e4eab222f53f23 Mon Sep 17 00:00:00 2001
> From: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
> Date: Wed, 17 Apr 2013 01:35:09 +0400
> Subject: [PATCH] ARM: shmobile: BOCK-W: enable USB in defconfig
>
> Enable USB platform EHCI/OHCI and common PHY drivers in 'bockw_defconfig'.
> Enable USB storage driver and SCSI disk driver that it needs as well...
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
> Signed-off-by: Simon Horman <horms+renesas at verge.net.au>

    Third time's a charm, as they say. :-)

WBR, Sergei



From tony at atomide.com  Tue Apr 23 14:01:46 2013
From: tony at atomide.com (Tony Lindgren)
Date: Tue, 23 Apr 2013 11:01:46 -0700
Subject: [PATCH 05/21] ARM: OMAP2+: add dependencies on ARCH_MULTI_V6/V7
In-Reply-To: <1366734653-488286-6-git-send-email-arnd@arndb.de>
References: <1366734653-488286-1-git-send-email-arnd@arndb.de>
 <1366734653-488286-6-git-send-email-arnd@arndb.de>
Message-ID: <20130423180146.GI10155@atomide.com>

* Arnd Bergmann <arnd at arndb.de> [130423 09:36]:
> CONFIG_ARCH_OMAP2PLUS depends on (ARCH_MULTI_V6 || ARCH_MULTI_V7) as of
> a0694861 "ARM: OMAP2+: Enable ARCH_MULTIPLATFORM support", but the
> individual OMAP2/3/4/5 and AM33XX platforms can all be selected independent
> of what we are building for, which is a bug and prevents us from easily
> building e.g. an ARMv7-only defconfig.
> 
> This makes ARCH_OMAP2 depend on ARCH_MULTI_V6 and the others depend on
> ARCH_MULTI_V7, to ensure we really only build the platforms for the
> CPUs we have enabled in the global multiplatform configuration step.
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Cc: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>

Acked-by: Tony Lindgren <tony at atomide.com>



From tony at atomide.com  Tue Apr 23 14:03:20 2013
From: tony at atomide.com (Tony Lindgren)
Date: Tue, 23 Apr 2013 11:03:20 -0700
Subject: [PATCH 21/21] mtd: omap2: allow bulding as a module
In-Reply-To: <1366734653-488286-22-git-send-email-arnd@arndb.de>
References: <1366734653-488286-1-git-send-email-arnd@arndb.de>
 <1366734653-488286-22-git-send-email-arnd@arndb.de>
Message-ID: <20130423180320.GJ10155@atomide.com>

* Arnd Bergmann <arnd at arndb.de> [130423 09:37]:
> The omap2 nand device driver calls into the the elm code, which can
> be a loadable module, and in that case it cannot be built-in itself.
> I can see no reason why the omap2 driver cannot also be a module,
> so let's make the option "tristate" in Kconfig to fix this allmodconfig
> build error:
> 
> ERROR: "elm_config" [drivers/mtd/nand/omap2.ko] undefined!
> ERROR: "elm_decode_bch_error_page" [drivers/mtd/nand/omap2.ko] undefined!
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Cc: David Woodhouse <dwmw2 at infradead.org>
> Cc: Artem Bityutskiy <artem.bityutskiy at linux.intel.com>
> Cc: Tony Lindgren <tony at atomide.com>
> Cc: Afzal Mohammed <afzal at ti.com>
> Cc: Russell King <rmk+kernel at arm.linux.org.uk>
> Cc: linux-mtd at lists.infradead.org
> ---
>  drivers/mtd/nand/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
> index 81bf5e5..106b55e 100644
> --- a/drivers/mtd/nand/Kconfig
> +++ b/drivers/mtd/nand/Kconfig
> @@ -109,7 +109,7 @@ config MTD_NAND_OMAP2
>  
>  config MTD_NAND_OMAP_BCH
>  	depends on MTD_NAND && MTD_NAND_OMAP2 && ARCH_OMAP3
> -	bool "Enable support for hardware BCH error correction"
> +	tristate "Enable support for hardware BCH error correction"
>  	default n
>  	select BCH
>  	select BCH_CONST_PARAMS

Acked-by: Tony Lindgren <tony at atomide.com>

While at it, you could also drop the "default n" as that's
the default anyways.

Regards,

Tony


From olof at lixom.net  Tue Apr 23 14:11:09 2013
From: olof at lixom.net (Olof Johansson)
Date: Tue, 23 Apr 2013 11:11:09 -0700
Subject: [PATCH 4/4] arm64: Add initial DTS for APM X-Gene Storm SOC and
 APM Mustang board
In-Reply-To: <1366442131-26094-5-git-send-email-vkale@apm.com>
References: <1366442131-26094-1-git-send-email-vkale@apm.com>
 <1366442131-26094-5-git-send-email-vkale@apm.com>
Message-ID: <20130423181109.GA6850@quad.lixom.net>

On Sat, Apr 20, 2013 at 12:45:31PM +0530, Vinayak Kale wrote:

> +	gic: interrupt-controller at 78010000 {
> +		compatible = "arm,cortex-a15-gic", "arm,cortex-a9-gic";
> +		#interrupt-cells = <3>;
> +		interrupt-controller;
> +		reg = <0x0 0x78010000 0x0 0x1000>,	/* GIC Dist */
> +		      <0x0 0x78020000 0x0 0x1000>,	/* GIC CPU */
> +		      <0x0 0x78040000 0x0 0x2000>,	/* GIC VCPU Control */
> +		      <0x0 0x78060000 0x0 0x2000>;	/* GIC VCPU */
> +		interrupts = <1 9 0xf04>;	/* GIC Maintenence IRQ */
> +	};

Others have commented on other compatible fields, so it's my turn. :-)

Is this the exact same GIC that's used with A15? I don't think it is? It might
make more sense to use a new compatible field and add it to the driver.

Also, other platforms have removed the a9 fallback, so even if you happen to
have an a15-compatible gic, in this case you should at least take out the a9
string.


-Olof


From mpfj-list at newflow.co.uk  Tue Apr 23 14:15:45 2013
From: mpfj-list at newflow.co.uk (Mark Jackson)
Date: Tue, 23 Apr 2013 19:15:45 +0100
Subject: [PATCH] remove vlan tags in CPSW dual emac mode
In-Reply-To: <5176C4FE.4080305@ti.com>
References: <4699400.vD3TdgH1nR@localhost> <5176C4FE.4080305@ti.com>
Message-ID: <5176CFD1.1090307@newflow.co.uk>

On 23/04/13 18:29, Mugunthan V N wrote:
> On 4/23/2013 9:48 PM, Markus Brunner wrote:
>> If operating in dual emac mode all packets sent by the CPSW contain
>> vlan headers with the reserved VID 0,
>> which gets stripped away by all somewhat recent Linux versions.
>> Operating systems without that behaviour will fail to communicate.
>> This patch fixes that behaviour by disabling the VLAN_AWARE mode as
>> already described by the comment above.
>>
>> Signed-off-by: Markus Brunner <systemprogrammierung.brunner at gmail.com>
>> Tested-by: Mark Jackson <mpfj at newflow.co.uk>
>>
>> ---
>> --- linux-3.9-rc8.orig/drivers/net/ethernet/ti/cpsw.c    2013-04-23
>> 17:26:11.000000000 +0200
>> +++ linux-3.9-rc8/drivers/net/ethernet/ti/cpsw.c    2013-04-23
>> 17:36:25.000000000 +0200
>> @@ -751,9 +751,9 @@ static void cpsw_init_host_port(struct c
>>       /* switch to vlan unaware mode */
>>       cpsw_ale_control_set(priv->ale, priv->host_port, ALE_VLAN_AWARE,
>>                    CPSW_ALE_VLAN_AWARE);
>>       control_reg = readl(&priv->regs->control);
>> -    control_reg |= CPSW_VLAN_AWARE;
>> +    control_reg &= ~CPSW_VLAN_AWARE;
>>       writel(control_reg, &priv->regs->control);
>>       fifo_mode = (priv->data.dual_emac) ? CPSW_FIFO_DUAL_MAC_MODE :
>>                CPSW_FIFO_NORMAL_MODE;
>>       writel(fifo_mode, &priv->host_port_regs->tx_in_ctl);
> Disabling VLAN aware mode will enable switching mode and the feature of
> separating the two down stream port is lost with this patch
> Please check TRM for more info in *14.3.2.10.2 Dual Mac Mode* chapter

In that case, I'm confused as the comment in the source code just above
states "switch to vlan *unaware* mode".

Just so that we've not all missed something silly, here's my .dts file
and .config file.

Mugunthan, can you check they both appear to have the correct settings
for dual emac mode ?

Cheers
Mark J.
---
/*
 * Copyright (C) 2013 Newflow Ltd - http://www.newflow.co.uk/
 *
 * 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.
 */
/dts-v1/;

/include/ "am33xx.dtsi"

/ {
	model = "Newflow AM335x NanoBone";
	compatible = "ti,am33xx";

	cpus {
		cpu at 0 {
			cpu0-supply = <&dcdc2_reg>;
		};
	};

	memory {
		device_type = "memory";
		reg = <0x80000000 0x10000000>; /* 256 MB */
	};

	am33xx_pinmux: pinmux at 44e10800 {
		pinctrl-names = "default";
		pinctrl-0 = <&mpfj_pins>;

		mpfj_pins: mpfj_pins {
			pinctrl-single,pins = <
				0x15c 0x7	/* spi0_cs0.gpio0_5, OUTPUT | MODE7 */
			>;
		};

		gpmc_pins: gpmc_pins {
			pinctrl-single,pins = <
				0x0 0x30	/* gpmc_ad0.gpmc_ad0, INPUT | PULLUP | MODE0 */
				0x4 0x30	/* gpmc_ad1.gpmc_ad1, INPUT | PULLUP | MODE0 */
				0x8 0x30	/* gpmc_ad2.gpmc_ad2, INPUT | PULLUP | MODE0 */
				0xc 0x30	/* gpmc_ad3.gpmc_ad3, INPUT | PULLUP | MODE0 */
				0x10 0x30	/* gpmc_ad4.gpmc_ad4, INPUT | PULLUP | MODE0 */
				0x14 0x30	/* gpmc_ad5.gpmc_ad5, INPUT | PULLUP | MODE0 */
				0x18 0x30	/* gpmc_ad6.gpmc_ad6, INPUT | PULLUP | MODE0 */
				0x1c 0x30	/* gpmc_ad7.gpmc_ad7, INPUT | PULLUP | MODE0 */
				0x20 0x30	/* gpmc_ad8.gpmc_ad8, INPUT | PULLUP | MODE0 */
				0x24 0x30	/* gpmc_ad9.gpmc_ad9, INPUT | PULLUP | MODE0 */
				0x28 0x30	/* gpmc_ad10.gpmc_ad10, INPUT | PULLUP | MODE0 */
				0x2c 0x30	/* gpmc_ad11.gpmc_ad11, INPUT | PULLUP | MODE0 */
				0x30 0x30	/* gpmc_ad12.gpmc_ad12, INPUT | PULLUP | MODE0 */
				0x34 0x30	/* gpmc_ad13.gpmc_ad13, INPUT | PULLUP | MODE0 */
				0x38 0x30	/* gpmc_ad14.gpmc_ad14, INPUT | PULLUP | MODE0 */
				0x3c 0x30	/* gpmc_ad15.gpmc_ad15, INPUT | PULLUP | MODE0 */

				0x70 0x30	/* gpmc_wait0.gpmc_wait0, INPUT | PULLUP | MODE0 */
				0x7c 0x10	/* gpmc_csn0.gpmc_csn0, OUTPUT_PULLUP | MODE0 */
				0x80 0x10	/* gpmc_csn1.gpmc_csn1, OUTPUT_PULLUP | MODE0 */
				0x84 0x10	/* gpmc_csn2.gpmc_csn2, OUTPUT_PULLUP | MODE0 */
				0x88 0x10	/* gpmc_csn3.gpmc_csn3, OUTPUT_PULLUP | MODE0 */

				0x90 0x10	/* gpmc_advn_ale.gpmc_advn_ale, OUTPUT_PULLUP | MODE0 */
				0x94 0x10	/* gpmc_oen_ren.gpmc_oen_ren, OUTPUT_PULLUP | MODE0 */
				0x98 0x10	/* gpmc_wen.gpmc_wen, OUTPUT_PULLUP | MODE0 */
				0x9c 0x10	/* gpmc_ben0_cle.gpmc_ben0_cle, OUTPUT_PULLUP | MODE0 */

				0xa4 0x11	/* lcd_data1.gpmc_a1, OUTPUT_PULLUP | MODE1 */
				0xa8 0x11	/* lcd_data2.gpmc_a2, OUTPUT_PULLUP | MODE1 */
				0xac 0x11	/* lcd_data3.gpmc_a3, OUTPUT_PULLUP | MODE1 */
				0xb0 0x11	/* lcd_data4.gpmc_a4, OUTPUT_PULLUP | MODE1 */
				0xb4 0x11	/* lcd_data5.gpmc_a5, OUTPUT_PULLUP | MODE1 */
				0xb8 0x11	/* lcd_data6.gpmc_a6, OUTPUT_PULLUP | MODE1 */
				0xbc 0x11	/* lcd_data7.gpmc_a7, OUTPUT_PULLUP | MODE1 */

				0xe0 0x11	/* lcd_vsync.gpmc_a8, OUTPUT_PULLUP | MODE1 */
				0xe4 0x11	/* lcd_hsync.gpmc_a9, OUTPUT_PULLUP | MODE1 */
				0xe8 0x11	/* lcd_pclk.gpmc_a10, OUTPUT_PULLUP | MODE1 */
			>;
		};

		i2c1_pins: i2c1_pins {
			pinctrl-single,pins = <
				0x188 0x60	/* i2c0_sda.i2c0_sda, SLEWSLOW | INPUT | PULLDOWN | MODE0 */
				0x18c 0x60	/* i2c0_scl.i2c0_scl, SLEWSLOW | INPUT | PULLDOWN | MODE0 */
			>;
		};

		uart0_pins: uart0_pins {
			pinctrl-single,pins = <
				0x170 0x30	/* uart0_rxd.uart0_rxd, INPUT | MODE0 */
				0x174 0x08	/* uart0_txd.uart0_txd, OUTPUT | MODE0 */
			>;
		};

		uart1_pins: uart1_pins {
			pinctrl-single,pins = <
				0x178 0x0f	/* uart1_ctsn.uart1_ctsn, OUTPUT | MODE7 */
				0x17c 0x0f	/* uart1_rtsn.uart1_rtsn, OUTPUT | MODE7 */
				0x180 0x30	/* uart1_rxd.uart1_rxd, INPUT | MODE0 */
				0x184 0x08	/* uart1_txd.uart1_txd, OUTPUT | MODE0 */
			>;
		};

		uart2_pins: uart2_pins {
			pinctrl-single,pins = <
				0xc0 0x0f	/* lcd_data8.gpio2[14], OUTPUT | MODE7 */
				0xc4 0x0f	/* lcd_data9.gpio2[15], OUTPUT | MODE7 */
				0x150 0x31	/* spi0_sclk.uart2_rxd, INPUT | MODE1 */
				0x154 0x09	/* spi0_d0.uart2_txd, OUTPUT | MODE1 */
			>;
		};

		uart3_pins: uart3_pins {
			pinctrl-single,pins = <
				0x160 0x31	/* spi0_cs1.uart3_rxd, INPUT | MODE1 */
				0x164 0x09	/* ecap0_in_pwm0_out.uart3_txd, OUTPUT | MODE1 */
				0xc8 0x37	/* lcd_data10.gpio2[16], INPUT | PULLUP | MODE7 */
				0xcc 0x0f	/* lcd_data11.gpio2[17], OUTPUT | MODE7 */
			>;
		};

		uart4_pins: uart4_pins {
			pinctrl-single,pins = <
				0xd0 0x37	/* lcd_data12.gpio0[8], INPUT | PULLUP | MODE7 */
				0xd4 0x0f	/* lcd_data13.gpio0[9], OUTPUT | MODE7 */
				0x168 0x31	/* uart0_ctsn.uart4_rxd, INPUT | MODE1 */
				0x16c 0x09	/* uart0_rtsn.uart4_txd, OUTPUT | MODE1 */
			>;
		};

		uart5_pins: uart5_pins {
			pinctrl-single,pins = <
				0xd8 0x34	/* lcd_data14.uart5_rxd, INPUT | MODE4 */
				0x144 0x0b	/* rmiii1_refclk.uart5_txd, OUTPUT | MODE3 */
			>;
		};
	};

	ocp {
		uart1: serial at 44e09000 {
			pinctrl-names = "default";
			pinctrl-0 = <&uart0_pins>;
			status = "okay";
		};

		uart2: serial at 48022000 {
			pinctrl-names = "default";
			pinctrl-0 = <&uart1_pins>;
			status = "okay";
		};

		uart3: serial at 48024000 {
			pinctrl-names = "default";
			pinctrl-0 = <&uart2_pins>;
			status = "okay";
		};

		uart4: serial at 481a6000 {
			pinctrl-names = "default";
			pinctrl-0 = <&uart3_pins>;
			status = "okay";
		};

		uart5: serial at 481a8000 {
			pinctrl-names = "default";
			pinctrl-0 = <&uart4_pins>;
			status = "okay";
		};

		uart6: serial at 481aa000 {
			pinctrl-names = "default";
			pinctrl-0 = <&uart5_pins>;
			status = "okay";
		};

		i2c1: i2c at 44e0b000 {
			status = "okay";
			pinctrl-names = "default";
			clock-frequency = <400000>;
			pinctrl-names = "default";
			pinctrl-0 = <&i2c1_pins>;

			gpio at 20 {
				compatible = "mcp,mcp23017";
				reg = <0x20>;
			};

			tps: tps at 24 {
				reg = <0x24>;
			};

			eeprom at 53 {
				compatible = "mcp,24c02";
				reg = <0x53>;
				pagesize = <8>;
			};

			rtc at 68 {
				compatible = "dallas,ds1307";
				reg = <0x68>;
			};
		};

		elm: elm at 48080000 {
			status = "okay";
		};

		gpmc: gpmc at 50000000 {
			compatible = "ti,am3352-gpmc";
			ti,hwmods = "gpmc";
			status = "okay";
			gpmc,num-waitpins = <2>;
			pinctrl-names = "default";
			pinctrl-0 = <&gpmc_pins>;

			#address-cells = <2>;
			#size-cells = <1>;
			ranges = <0 0 0x08000000 0x10000000>,	/* CS0: NAND 256M */
				 <3 0 0x18000000 0x04000000>;	/* CS3: NOR 64M */

			nand at 0,0 {
				linux,mtd-name= "micron,mt29f2g08abaea";
				reg = <0 0x00000000 0x10000000>; /* CS0, offset 0 */
				nand-bus-width = <8>;
				ti,nand-ecc-opt = "bch8";

				gpmc,device-nand;
				gpmc,device-width = <1>;
				gpmc,wait-pin = <0>;

				gpmc,sync-clk = <0>;
				gpmc,cs-on = <0>;
				gpmc,cs-rd-off = <44>;
				gpmc,cs-wr-off = <44>;
				gpmc,adv-on = <6>;
				gpmc,adv-rd-off = <34>;
				gpmc,adv-wr-off = <44>;
				gpmc,we-off = <40>;
				gpmc,oe-off = <54>;
				gpmc,access = <64>;
				gpmc,rd-cycle = <82>;
				gpmc,wr-cycle = <82>;
				gpmc,wr-access = <40>;
				gpmc,wr-data-mux-bus = <0>;

				#address-cells = <1>;
				#size-cells = <1>;
				elm_id = <&elm>;

				/*
				MTD partition table
				===================
				+------------+-->0x00000000-> SPL start         (SPL copy on 1st block)
				|            |
				|            |-->0x0001FFFF-> SPL end
				|            |-->0x00020000-> SPL.backup1 start (SPL copy on 2nd block)
				|            |
				|            |-->0x0003FFFF-> SPL.backup1 end
				|            |-->0x00040000-> SPL.backup2 start (SPL copy on 3rd block)
				|            |
				|            |-->0x0005FFFF-> SPL.backup2 end
				|            |-->0x00060000-> SPL.backup3 start (SPL copy on 4th block)
				|            |
				|            |-->0x0007FFFF-> SPL.backup3 end
				|            |-->0x00080000-> U-Boot start
				|            |
				|            |-->0x001DFFFF-> U-Boot end
				|            |-->0x001E0000-> ENV start
				|            |
				|            |-->0x001FFFFF-> ENV end
				|            |-->0x00200000-> File system start
				|            |
				|            |-->0x041FFFFF-> File system end
				|            |-->0x04200000-> Data storage start
				|            |
				+------------+-->0x10000000-> NAND end (Free end)
				*/
				partition at 0 {
					label = "spl1";
					reg = <0x00000000 0x00020000>; /* 128KB */
				};

				partition at 1 {
					label = "spl2";
					reg = <0x00020000 0x00020000>; /* 128KB */
				};

				partition at 2 {
					label = "spl3";
					reg = <0x00040000 0x00020000>; /* 128KB */
				};

				partition at 3 {
					label = "spl4";
					reg = <0x00060000 0x00020000>; /* 128KB */
				};

				partition at 4 {
					label = "boot";
					reg = <0x00080000 0x00160000>; /* 1408KB */
				};

				partition at 5 {
					label = "env";
					reg = <0x001e0000 0x00020000>; /* 128KB */
				};

				partition at 6 {
					label = "rootfs";
					reg = <0x00200000 0x04000000>; /* 64MB */
				};

				partition at 7 {
					label = "data";
					reg = <0x04200000 0x0be00000>; /* 190MB */
				};
			};

			nor at 1,0 {
				reg = <3 0x00000000 0x04000000>;
				compatible = "cfi-flash";
				linux,mtd-name = "spansion,s29gl064n90t";
				bank-width = <2>;

				gpmc,mux-add-data;

				gpmc,sync-clk = <0>;
				gpmc,cs-on = <10>;
				gpmc,cs-rd-off = <150>;
				gpmc,cs-wr-off = <150>;
				gpmc,adv-on = <10>;
				gpmc,adv-rd-off = <10>;
				gpmc,adv-wr-off = <10>;
				gpmc,oe-on = <30>;
				gpmc,oe-off = <150>;
				gpmc,we-on = <30>;
				gpmc,we-off = <150>;
				gpmc,rd-cycle = <150>;
				gpmc,wr-cycle = <150>;
				gpmc,access = <130>;
				gpmc,page-burst-access = <10>;
				gpmc,cycle2cycle-diff = <1>;
				gpmc,cycle2cycle-same = <1>;
				gpmc,cycle2cycle-delay = <10>;
				gpmc,wr-data-mux-bus = <60>;

				#address-cells = <1>;
				#size-cells = <1>;
				elm_id = <&elm>;

				partition at 0 {
					label = "data";
					reg = <0x00000000 0x04000000>;
				};
			};
		};

		mac: ethernet at 4a100000 {
			dual_emac = <1>;

			cpsw_emac0: slave at 4a100200 {
				dual_emac_res_vlan = <1>;
			};

			cpsw_emac1: slave at 4a100300 {
				dual_emac_res_vlan = <2>;
			};
		};
	};

	leds {
		compatible = "gpio-leds";

		led at 0 {
			label = "nanobone:green:usr1";
			gpios = <&gpio1 5 0>;
			default-state = "off";
		};
	};
};

/include/ "tps65217.dtsi"

&tps {
	regulators {
		dcdc1_reg: regulator at 0 {
			regulator-always-on;
		};

		dcdc2_reg: regulator at 1 {
			/* VDD_MPU voltage limits 0.95V - 1.26V with +/-4% tolerance */
			regulator-name = "vdd_mpu";
			regulator-min-microvolt = <925000>;
			regulator-max-microvolt = <1325000>;
			regulator-boot-on;
			regulator-always-on;
		};

		dcdc3_reg: regulator at 2 {
			/* VDD_CORE voltage limits 0.95V - 1.1V with +/-4% tolerance */
			regulator-name = "vdd_core";
			regulator-min-microvolt = <925000>;
			regulator-max-microvolt = <1150000>;
			regulator-boot-on;
			regulator-always-on;
		};

		ldo1_reg: regulator at 3 {
			regulator-always-on;
		};

		ldo2_reg: regulator at 4 {
			regulator-always-on;
		};

		ldo3_reg: regulator at 5 {
			regulator-always-on;
		};

		ldo4_reg: regulator at 6 {
			regulator-always-on;
		};
	};
};

&cpsw_emac0 {
	phy_id = <&davinci_mdio>, <0>;
};

&cpsw_emac1 {
	phy_id = <&davinci_mdio>, <1>;
};
---
#
# Automatically generated file; DO NOT EDIT.
# Linux/arm 3.9.0-rc7 Kernel Configuration
#
CONFIG_ARM=y
CONFIG_SYS_SUPPORTS_APM_EMULATION=y
CONFIG_GENERIC_GPIO=y
CONFIG_HAVE_PROC_CPU=y
CONFIG_NO_IOPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_RWSEM_GENERIC_SPINLOCK=y
CONFIG_ARCH_HAS_CPUFREQ=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_VECTORS_BASE=0xffff0000
CONFIG_ARM_PATCH_PHYS_VIRT=y
CONFIG_GENERIC_BUG=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y

#
# General setup
#
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
# CONFIG_FHANDLE is not set
# CONFIG_AUDIT is not set
CONFIG_HAVE_GENERIC_HARDIRQS=y

#
# IRQ subsystem
#
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_HARDIRQS_SW_RESEND=y
CONFIG_GENERIC_IRQ_CHIP=y
CONFIG_IRQ_DOMAIN=y
# CONFIG_IRQ_DOMAIN_DEBUG is not set
CONFIG_SPARSE_IRQ=y
# CONFIG_ALWAYS_USE_PERSISTENT_CLOCK is not set
CONFIG_KTIME_SCALAR=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y

#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y

#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
# CONFIG_TASKSTATS is not set

#
# RCU Subsystem
#
CONFIG_TINY_RCU=y
# CONFIG_PREEMPT_RCU is not set
# CONFIG_RCU_STALL_COMMON is not set
# CONFIG_TREE_RCU_TRACE is not set
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=16
# CONFIG_CGROUPS is not set
# CONFIG_CHECKPOINT_RESTORE is not set
# CONFIG_NAMESPACES is not set
CONFIG_UIDGID_CONVERTED=y
# CONFIG_UIDGID_STRICT_TYPE_CHECKS is not set
# CONFIG_SCHED_AUTOGROUP is not set
# CONFIG_SYSFS_DEPRECATED is not set
# CONFIG_RELAY is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_RD_GZIP=y
# CONFIG_RD_BZIP2 is not set
# CONFIG_RD_LZMA is not set
# CONFIG_RD_XZ is not set
# CONFIG_RD_LZO is not set
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
CONFIG_EXPERT=y
CONFIG_HAVE_UID16=y
CONFIG_UID16=y
# CONFIG_SYSCTL_SYSCALL is not set
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_AIO=y
# CONFIG_EMBEDDED is not set
CONFIG_HAVE_PERF_EVENTS=y
CONFIG_PERF_USE_VMALLOC=y

#
# Kernel Performance Events And Counters
#
CONFIG_PERF_EVENTS=y
# CONFIG_DEBUG_PERF_USE_VMALLOC is not set
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_COMPAT_BRK=y
CONFIG_SLAB=y
# CONFIG_SLUB is not set
# CONFIG_SLOB is not set
CONFIG_PROFILING=y
CONFIG_OPROFILE=y
CONFIG_HAVE_OPROFILE=y
# CONFIG_JUMP_LABEL is not set
# CONFIG_HAVE_64BIT_ALIGNED_ACCESS is not set
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
CONFIG_HAVE_ARCH_TRACEHOOK=y
CONFIG_HAVE_DMA_ATTRS=y
CONFIG_HAVE_DMA_CONTIGUOUS=y
CONFIG_GENERIC_SMP_IDLE_THREAD=y
CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y
CONFIG_HAVE_CLK=y
CONFIG_HAVE_DMA_API_DEBUG=y
CONFIG_HAVE_HW_BREAKPOINT=y
CONFIG_HAVE_ARCH_JUMP_LABEL=y
CONFIG_ARCH_WANT_IPC_PARSE_VERSION=y
CONFIG_HAVE_ARCH_SECCOMP_FILTER=y
CONFIG_HAVE_MOD_ARCH_SPECIFIC=y
CONFIG_MODULES_USE_ELF_REL=y
CONFIG_CLONE_BACKWARDS=y
CONFIG_OLD_SIGSUSPEND3=y
CONFIG_OLD_SIGACTION=y

#
# GCOV-based kernel profiling
#
# CONFIG_GCOV_KERNEL is not set
CONFIG_HAVE_GENERIC_DMA_COHERENT=y
CONFIG_SLABINFO=y
CONFIG_RT_MUTEXES=y
CONFIG_BASE_SMALL=0
# CONFIG_MODULES is not set
CONFIG_BLOCK=y
CONFIG_LBDAF=y
# CONFIG_BLK_DEV_BSG is not set
# CONFIG_BLK_DEV_BSGLIB is not set
# CONFIG_BLK_DEV_INTEGRITY is not set

#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
# CONFIG_OSF_PARTITION is not set
# CONFIG_AMIGA_PARTITION is not set
# CONFIG_ATARI_PARTITION is not set
# CONFIG_MAC_PARTITION is not set
CONFIG_MSDOS_PARTITION=y
# CONFIG_BSD_DISKLABEL is not set
# CONFIG_MINIX_SUBPARTITION is not set
# CONFIG_SOLARIS_X86_PARTITION is not set
# CONFIG_UNIXWARE_DISKLABEL is not set
# CONFIG_LDM_PARTITION is not set
# CONFIG_SGI_PARTITION is not set
# CONFIG_ULTRIX_PARTITION is not set
# CONFIG_SUN_PARTITION is not set
# CONFIG_KARMA_PARTITION is not set
CONFIG_EFI_PARTITION=y
# CONFIG_SYSV68_PARTITION is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_DEFAULT_DEADLINE is not set
CONFIG_DEFAULT_CFQ=y
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="cfq"
CONFIG_UNINLINE_SPIN_UNLOCK=y
CONFIG_FREEZER=y

#
# System Type
#
CONFIG_MMU=y
CONFIG_ARCH_MULTIPLATFORM=y
# CONFIG_ARCH_INTEGRATOR is not set
# CONFIG_ARCH_REALVIEW is not set
# CONFIG_ARCH_VERSATILE is not set
# CONFIG_ARCH_AT91 is not set
# CONFIG_ARCH_BCM2835 is not set
# CONFIG_ARCH_CNS3XXX is not set
# CONFIG_ARCH_CLPS711X is not set
# CONFIG_ARCH_GEMINI is not set
# CONFIG_ARCH_SIRF is not set
# CONFIG_ARCH_EBSA110 is not set
# CONFIG_ARCH_EP93XX is not set
# CONFIG_ARCH_FOOTBRIDGE is not set
# CONFIG_ARCH_MXS is not set
# CONFIG_ARCH_NETX is not set
# CONFIG_ARCH_H720X is not set
# CONFIG_ARCH_IOP13XX is not set
# CONFIG_ARCH_IOP32X is not set
# CONFIG_ARCH_IOP33X is not set
# CONFIG_ARCH_IXP4XX is not set
# CONFIG_ARCH_DOVE is not set
# CONFIG_ARCH_KIRKWOOD is not set
# CONFIG_ARCH_MV78XX0 is not set
# CONFIG_ARCH_ORION5X is not set
# CONFIG_ARCH_MMP is not set
# CONFIG_ARCH_KS8695 is not set
# CONFIG_ARCH_W90X900 is not set
# CONFIG_ARCH_LPC32XX is not set
# CONFIG_ARCH_TEGRA is not set
# CONFIG_ARCH_PXA is not set
# CONFIG_ARCH_MSM is not set
# CONFIG_ARCH_SHMOBILE is not set
# CONFIG_ARCH_RPC is not set
# CONFIG_ARCH_SA1100 is not set
# CONFIG_ARCH_S3C24XX is not set
# CONFIG_ARCH_S3C64XX is not set
# CONFIG_ARCH_S5P64X0 is not set
# CONFIG_ARCH_S5PC100 is not set
# CONFIG_ARCH_S5PV210 is not set
# CONFIG_ARCH_EXYNOS is not set
# CONFIG_ARCH_SHARK is not set
# CONFIG_ARCH_U300 is not set
# CONFIG_ARCH_U8500 is not set
# CONFIG_ARCH_NOMADIK is not set
# CONFIG_PLAT_SPEAR is not set
# CONFIG_ARCH_DAVINCI is not set
# CONFIG_ARCH_OMAP1 is not set

#
# Multiple platform selection
#

#
# CPU Core family selection
#
# CONFIG_ARCH_MULTI_V6 is not set
CONFIG_ARCH_MULTI_V7=y
CONFIG_ARCH_MULTI_V6_V7=y
# CONFIG_ARCH_MULTI_CPU_AUTO is not set
# CONFIG_ARCH_MVEBU is not set
# CONFIG_ARCH_BCM is not set
# CONFIG_GPIO_PCA953X is not set
# CONFIG_ARCH_HIGHBANK is not set
# CONFIG_ARCH_MXC is not set

#
# TI OMAP Common Features
#

#
# OMAP Feature Selections
#
CONFIG_OMAP_RESET_CLOCKS=y
CONFIG_OMAP_MUX=y
CONFIG_OMAP_MUX_DEBUG=y
CONFIG_OMAP_MUX_WARNINGS=y
CONFIG_OMAP_32K_TIMER=y
# CONFIG_OMAP3_L2_AUX_SECURE_SAVE_RESTORE is not set
CONFIG_OMAP_DM_TIMER=y
CONFIG_OMAP_PM_NOOP=y
CONFIG_MACH_OMAP_GENERIC=y
CONFIG_ARCH_OMAP=y
CONFIG_ARCH_OMAP2PLUS=y

#
# TI OMAP2/3/4 Specific Features
#
CONFIG_ARCH_OMAP2PLUS_TYPICAL=y
CONFIG_SOC_HAS_OMAP2_SDRC=y
# CONFIG_ARCH_OMAP2 is not set
CONFIG_ARCH_OMAP3=y
# CONFIG_ARCH_OMAP4 is not set
# CONFIG_SOC_OMAP5 is not set
# CONFIG_SOC_OMAP3430 is not set
CONFIG_SOC_TI81XX=y
CONFIG_SOC_AM33XX=y

#
# OMAP Board Type
#
# CONFIG_MACH_OMAP3_BEAGLE is not set
# CONFIG_MACH_DEVKIT8000 is not set
# CONFIG_MACH_OMAP_LDP is not set
# CONFIG_MACH_OMAP3530_LV_SOM is not set
# CONFIG_MACH_OMAP3_TORPEDO is not set
# CONFIG_MACH_OVERO is not set
# CONFIG_MACH_OMAP3EVM is not set
# CONFIG_MACH_OMAP3517EVM is not set
# CONFIG_MACH_CRANEBOARD is not set
# CONFIG_MACH_OMAP3_PANDORA is not set
# CONFIG_MACH_TOUCHBOOK is not set
# CONFIG_MACH_OMAP_3430SDP is not set
# CONFIG_MACH_NOKIA_RM680 is not set
# CONFIG_MACH_NOKIA_RX51 is not set
# CONFIG_MACH_OMAP_ZOOM2 is not set
# CONFIG_MACH_OMAP_ZOOM3 is not set
# CONFIG_MACH_CM_T35 is not set
# CONFIG_MACH_CM_T3517 is not set
# CONFIG_MACH_IGEP0020 is not set
# CONFIG_MACH_IGEP0030 is not set
# CONFIG_MACH_SBC3530 is not set
# CONFIG_MACH_OMAP_3630SDP is not set
# CONFIG_MACH_TI8168EVM is not set
# CONFIG_MACH_TI8148EVM is not set
# CONFIG_OMAP3_EMU is not set
# CONFIG_OMAP3_SDRC_AC_TIMING is not set
# CONFIG_ARCH_SOCFPGA is not set
# CONFIG_ARCH_SUNXI is not set
CONFIG_ARCH_VEXPRESS=y

#
# Versatile Express platform type
#
# CONFIG_ARCH_VEXPRESS_CORTEX_A5_A9_ERRATA is not set
# CONFIG_ARCH_VEXPRESS_CA9X4 is not set
CONFIG_PLAT_VERSATILE_CLCD=y
CONFIG_PLAT_VERSATILE_SCHED_CLOCK=y
# CONFIG_ARCH_VIRT is not set
# CONFIG_ARCH_WM8850 is not set
# CONFIG_ARCH_ZYNQ is not set
CONFIG_PLAT_VERSATILE=y
CONFIG_ARM_TIMER_SP804=y

#
# Processor Type
#
CONFIG_CPU_V7=y
CONFIG_CPU_32v6K=y
CONFIG_CPU_32v7=y
CONFIG_CPU_ABRT_EV7=y
CONFIG_CPU_PABRT_V7=y
CONFIG_CPU_CACHE_V7=y
CONFIG_CPU_CACHE_VIPT=y
CONFIG_CPU_COPY_V6=y
CONFIG_CPU_TLB_V7=y
CONFIG_CPU_HAS_ASID=y
CONFIG_CPU_CP15=y
CONFIG_CPU_CP15_MMU=y

#
# Processor Features
#
# CONFIG_ARM_LPAE is not set
# CONFIG_ARCH_PHYS_ADDR_T_64BIT is not set
CONFIG_ARM_THUMB=y
CONFIG_ARM_THUMBEE=y
CONFIG_ARM_VIRT_EXT=y
# CONFIG_SWP_EMULATE is not set
# CONFIG_CPU_ICACHE_DISABLE is not set
# CONFIG_CPU_DCACHE_DISABLE is not set
# CONFIG_CPU_BPREDICT_DISABLE is not set
CONFIG_OUTER_CACHE=y
CONFIG_OUTER_CACHE_SYNC=y
CONFIG_MIGHT_HAVE_CACHE_L2X0=y
CONFIG_CACHE_L2X0=y
CONFIG_CACHE_PL310=y
CONFIG_ARM_L1_CACHE_SHIFT_6=y
CONFIG_ARM_L1_CACHE_SHIFT=6
CONFIG_ARM_DMA_MEM_BUFFERABLE=y
CONFIG_ARM_NR_BANKS=8
CONFIG_MULTI_IRQ_HANDLER=y
# CONFIG_ARM_ERRATA_430973 is not set
CONFIG_PL310_ERRATA_588369=y
CONFIG_ARM_ERRATA_720789=y
CONFIG_PL310_ERRATA_727915=y
# CONFIG_PL310_ERRATA_753970 is not set
# CONFIG_ARM_ERRATA_754322 is not set
# CONFIG_PL310_ERRATA_769419 is not set
# CONFIG_ARM_ERRATA_775420 is not set
CONFIG_ICST=y

#
# Bus support
#
CONFIG_ARM_AMBA=y
# CONFIG_PCI_SYSCALL is not set
# CONFIG_PCCARD is not set

#
# Kernel Features
#
CONFIG_HAVE_SMP=y
# CONFIG_SMP is not set
CONFIG_HAVE_ARM_ARCH_TIMER=y
CONFIG_VMSPLIT_3G=y
# CONFIG_VMSPLIT_2G is not set
# CONFIG_VMSPLIT_1G is not set
CONFIG_PAGE_OFFSET=0xC0000000
# CONFIG_ARM_PSCI is not set
CONFIG_ARCH_NR_GPIO=0
CONFIG_PREEMPT_NONE=y
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT is not set
CONFIG_HZ=100
CONFIG_SCHED_HRTICK=y
# CONFIG_THUMB2_KERNEL is not set
CONFIG_AEABI=y
CONFIG_OABI_COMPAT=y
CONFIG_ARCH_HAS_HOLES_MEMORYMODEL=y
# CONFIG_ARCH_SPARSEMEM_DEFAULT is not set
# CONFIG_ARCH_SELECT_MEMORY_MODEL is not set
CONFIG_HAVE_ARCH_PFN_VALID=y
CONFIG_HIGHMEM=y
# CONFIG_HIGHPTE is not set
CONFIG_HW_PERF_EVENTS=y
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
CONFIG_HAVE_MEMBLOCK=y
# CONFIG_HAVE_BOOTMEM_INFO_NODE is not set
CONFIG_PAGEFLAGS_EXTENDED=y
CONFIG_SPLIT_PTLOCK_CPUS=999999
CONFIG_COMPACTION=y
CONFIG_MIGRATION=y
# CONFIG_PHYS_ADDR_T_64BIT is not set
CONFIG_ZONE_DMA_FLAG=0
CONFIG_BOUNCE=y
# CONFIG_KSM is not set
CONFIG_DEFAULT_MMAP_MIN_ADDR=4096
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_NEED_PER_CPU_KM=y
# CONFIG_CLEANCACHE is not set
# CONFIG_FRONTSWAP is not set
CONFIG_FORCE_MAX_ZONEORDER=12
CONFIG_ALIGNMENT_TRAP=y
# CONFIG_UACCESS_WITH_MEMCPY is not set
# CONFIG_SECCOMP is not set
# CONFIG_CC_STACKPROTECTOR is not set
# CONFIG_XEN is not set

#
# Boot options
#
CONFIG_USE_OF=y
CONFIG_ATAGS=y
# CONFIG_DEPRECATED_PARAM_STRUCT is not set
CONFIG_ZBOOT_ROM_TEXT=0x0
CONFIG_ZBOOT_ROM_BSS=0x0
CONFIG_ARM_APPENDED_DTB=y
CONFIG_ARM_ATAG_DTB_COMPAT=y
CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER=y
# CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND is not set
CONFIG_CMDLINE="root=/dev/mmcblk0p2 rootwait console=ttyO2,115200"
CONFIG_CMDLINE_FROM_BOOTLOADER=y
# CONFIG_CMDLINE_EXTEND is not set
# CONFIG_CMDLINE_FORCE is not set
CONFIG_KEXEC=y
CONFIG_ATAGS_PROC=y
# CONFIG_CRASH_DUMP is not set
CONFIG_AUTO_ZRELADDR=y

#
# CPU Power Management
#

#
# CPU Frequency scaling
#
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_TABLE=y
CONFIG_CPU_FREQ_STAT=y
# CONFIG_CPU_FREQ_STAT_DETAILS is not set
CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y
# CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set
CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
# CONFIG_CPU_FREQ_GOV_POWERSAVE is not set
# CONFIG_CPU_FREQ_GOV_USERSPACE is not set
# CONFIG_CPU_FREQ_GOV_ONDEMAND is not set
# CONFIG_CPU_FREQ_GOV_CONSERVATIVE is not set
# CONFIG_GENERIC_CPUFREQ_CPU0 is not set

#
# ARM CPU frequency scaling drivers
#
CONFIG_ARM_OMAP2PLUS_CPUFREQ=y
# CONFIG_ARM_EXYNOS4210_CPUFREQ is not set
# CONFIG_ARM_EXYNOS4X12_CPUFREQ is not set
# CONFIG_ARM_EXYNOS5250_CPUFREQ is not set
# CONFIG_ARM_KIRKWOOD_CPUFREQ is not set
# CONFIG_CPU_IDLE is not set
# CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED is not set

#
# Floating point emulation
#

#
# At least one emulation must be selected
#
CONFIG_FPE_NWFPE=y
# CONFIG_FPE_NWFPE_XP is not set
# CONFIG_FPE_FASTFPE is not set
CONFIG_VFP=y
CONFIG_VFPv3=y
CONFIG_NEON=y

#
# Userspace binary formats
#
CONFIG_BINFMT_ELF=y
CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE=y
CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS=y
CONFIG_HAVE_AOUT=y
# CONFIG_BINFMT_AOUT is not set
CONFIG_BINFMT_MISC=y
CONFIG_COREDUMP=y

#
# Power management options
#
CONFIG_SUSPEND=y
CONFIG_SUSPEND_FREEZER=y
CONFIG_PM_SLEEP=y
# CONFIG_PM_AUTOSLEEP is not set
# CONFIG_PM_WAKELOCKS is not set
CONFIG_PM_RUNTIME=y
CONFIG_PM=y
CONFIG_PM_DEBUG=y
# CONFIG_PM_ADVANCED_DEBUG is not set
# CONFIG_PM_TEST_SUSPEND is not set
CONFIG_PM_SLEEP_DEBUG=y
# CONFIG_APM_EMULATION is not set
CONFIG_ARCH_HAS_OPP=y
CONFIG_PM_OPP=y
CONFIG_PM_CLK=y
CONFIG_CPU_PM=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARM_CPU_SUSPEND=y
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
# CONFIG_PACKET_DIAG is not set
CONFIG_UNIX=y
# CONFIG_UNIX_DIAG is not set
CONFIG_XFRM=y
CONFIG_XFRM_ALGO=y
CONFIG_XFRM_USER=y
# CONFIG_XFRM_SUB_POLICY is not set
CONFIG_XFRM_MIGRATE=y
# CONFIG_XFRM_STATISTICS is not set
CONFIG_NET_KEY=y
CONFIG_NET_KEY_MIGRATE=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
# CONFIG_IP_ADVANCED_ROUTER is not set
CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
CONFIG_IP_PNP_BOOTP=y
CONFIG_IP_PNP_RARP=y
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE_DEMUX is not set
# CONFIG_IP_MROUTE is not set
# CONFIG_ARPD is not set
# CONFIG_SYN_COOKIES is not set
# CONFIG_NET_IPVTI is not set
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
# CONFIG_INET_IPCOMP is not set
# CONFIG_INET_XFRM_TUNNEL is not set
# CONFIG_INET_TUNNEL is not set
CONFIG_INET_XFRM_MODE_TRANSPORT=y
CONFIG_INET_XFRM_MODE_TUNNEL=y
CONFIG_INET_XFRM_MODE_BEET=y
# CONFIG_INET_LRO is not set
CONFIG_INET_DIAG=y
CONFIG_INET_TCP_DIAG=y
# CONFIG_INET_UDP_DIAG is not set
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_CUBIC=y
CONFIG_DEFAULT_TCP_CONG="cubic"
# CONFIG_TCP_MD5SIG is not set
# CONFIG_IPV6 is not set
# CONFIG_NETLABEL is not set
# CONFIG_NETWORK_SECMARK is not set
# CONFIG_NETWORK_PHY_TIMESTAMPING is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
CONFIG_NETFILTER_ADVANCED=y

#
# Core Netfilter Configuration
#
# CONFIG_NETFILTER_NETLINK_ACCT is not set
# CONFIG_NETFILTER_NETLINK_QUEUE is not set
# CONFIG_NETFILTER_NETLINK_LOG is not set
# CONFIG_NF_CONNTRACK is not set
# CONFIG_NETFILTER_XTABLES is not set
# CONFIG_IP_VS is not set

#
# IP: Netfilter Configuration
#
# CONFIG_NF_DEFRAG_IPV4 is not set
# CONFIG_IP_NF_IPTABLES is not set
# CONFIG_IP_NF_ARPTABLES is not set
# CONFIG_IP_DCCP is not set
# CONFIG_IP_SCTP is not set
# CONFIG_RDS is not set
# CONFIG_TIPC is not set
# CONFIG_ATM is not set
# CONFIG_L2TP is not set
# CONFIG_BRIDGE is not set
CONFIG_HAVE_NET_DSA=y
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_PHONET is not set
# CONFIG_IEEE802154 is not set
# CONFIG_NET_SCHED is not set
# CONFIG_DCB is not set
CONFIG_DNS_RESOLVER=y
# CONFIG_BATMAN_ADV is not set
# CONFIG_OPENVSWITCH is not set
# CONFIG_VSOCKETS is not set
CONFIG_BQL=y

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_HAMRADIO is not set
# CONFIG_CAN is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
# CONFIG_AF_RXRPC is not set
CONFIG_WIRELESS=y
CONFIG_CFG80211=y
# CONFIG_NL80211_TESTMODE is not set
# CONFIG_CFG80211_DEVELOPER_WARNINGS is not set
# CONFIG_CFG80211_REG_DEBUG is not set
# CONFIG_CFG80211_CERTIFICATION_ONUS is not set
CONFIG_CFG80211_DEFAULT_PS=y
# CONFIG_CFG80211_DEBUGFS is not set
# CONFIG_CFG80211_INTERNAL_REGDB is not set
# CONFIG_CFG80211_WEXT is not set
# CONFIG_LIB80211 is not set
CONFIG_MAC80211=y
CONFIG_MAC80211_HAS_RC=y
CONFIG_MAC80211_RC_PID=y
CONFIG_MAC80211_RC_MINSTREL=y
CONFIG_MAC80211_RC_MINSTREL_HT=y
CONFIG_MAC80211_RC_DEFAULT_PID=y
# CONFIG_MAC80211_RC_DEFAULT_MINSTREL is not set
CONFIG_MAC80211_RC_DEFAULT="pid"
# CONFIG_MAC80211_MESH is not set
# CONFIG_MAC80211_LEDS is not set
# CONFIG_MAC80211_DEBUGFS is not set
# CONFIG_MAC80211_MESSAGE_TRACING is not set
# CONFIG_MAC80211_DEBUG_MENU is not set
# CONFIG_WIMAX is not set
# CONFIG_RFKILL is not set
# CONFIG_RFKILL_REGULATOR is not set
# CONFIG_NET_9P is not set
# CONFIG_CAIF is not set
# CONFIG_CEPH_LIB is not set
# CONFIG_NFC is not set
CONFIG_HAVE_BPF_JIT=y

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
CONFIG_FIRMWARE_IN_KERNEL=y
CONFIG_EXTRA_FIRMWARE=""
CONFIG_FW_LOADER_USER_HELPER=y
# CONFIG_DEBUG_DRIVER is not set
# CONFIG_DEBUG_DEVRES is not set
# CONFIG_SYS_HYPERVISOR is not set
# CONFIG_GENERIC_CPU_DEVICES is not set
CONFIG_REGMAP=y
CONFIG_REGMAP_I2C=y
# CONFIG_DMA_SHARED_BUFFER is not set
# CONFIG_CMA is not set

#
# Bus devices
#
# CONFIG_OMAP_OCP2SCP is not set
CONFIG_OMAP_INTERCONNECT=y
CONFIG_CONNECTOR=y
CONFIG_PROC_EVENTS=y
CONFIG_MTD=y
# CONFIG_MTD_REDBOOT_PARTS is not set
# CONFIG_MTD_CMDLINE_PARTS is not set
# CONFIG_MTD_AFS_PARTS is not set
CONFIG_MTD_OF_PARTS=y
# CONFIG_MTD_AR7_PARTS is not set

#
# User Modules And Translation Layers
#
CONFIG_MTD_CHAR=y
CONFIG_MTD_BLKDEVS=y
# CONFIG_MTD_BLOCK is not set
# CONFIG_MTD_BLOCK_RO is not set
# CONFIG_FTL is not set
# CONFIG_NFTL is not set
# CONFIG_INFTL is not set
# CONFIG_RFD_FTL is not set
# CONFIG_SSFDC is not set
# CONFIG_SM_FTL is not set
# CONFIG_MTD_OOPS is not set
# CONFIG_MTD_SWAP is not set

#
# RAM/ROM/Flash chip drivers
#
CONFIG_MTD_CFI=y
# CONFIG_MTD_JEDECPROBE is not set
CONFIG_MTD_GEN_PROBE=y
# CONFIG_MTD_CFI_ADV_OPTIONS is not set
CONFIG_MTD_MAP_BANK_WIDTH_1=y
CONFIG_MTD_MAP_BANK_WIDTH_2=y
CONFIG_MTD_MAP_BANK_WIDTH_4=y
# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set
CONFIG_MTD_CFI_I1=y
CONFIG_MTD_CFI_I2=y
# CONFIG_MTD_CFI_I4 is not set
# CONFIG_MTD_CFI_I8 is not set
# CONFIG_MTD_CFI_INTELEXT is not set
CONFIG_MTD_CFI_AMDSTD=y
# CONFIG_MTD_CFI_STAA is not set
CONFIG_MTD_CFI_UTIL=y
CONFIG_MTD_RAM=y
# CONFIG_MTD_ROM is not set
# CONFIG_MTD_ABSENT is not set

#
# Mapping drivers for chip access
#
# CONFIG_MTD_COMPLEX_MAPPINGS is not set
# CONFIG_MTD_PHYSMAP is not set
CONFIG_MTD_PHYSMAP_OF=y
CONFIG_MTD_PLATRAM=y

#
# Self-contained MTD device drivers
#
# CONFIG_MTD_DATAFLASH is not set
# CONFIG_MTD_M25P80 is not set
# CONFIG_MTD_SST25L is not set
# CONFIG_MTD_SLRAM is not set
# CONFIG_MTD_PHRAM is not set
# CONFIG_MTD_MTDRAM is not set
# CONFIG_MTD_BLOCK2MTD is not set

#
# Disk-On-Chip Device Drivers
#
# CONFIG_MTD_DOC2000 is not set
# CONFIG_MTD_DOC2001 is not set
# CONFIG_MTD_DOC2001PLUS is not set
# CONFIG_MTD_DOCG3 is not set
CONFIG_BCH_CONST_M=13
CONFIG_BCH_CONST_T=8
CONFIG_MTD_NAND_ECC=y
# CONFIG_MTD_NAND_ECC_SMC is not set
CONFIG_MTD_NAND=y
# CONFIG_MTD_NAND_ECC_BCH is not set
# CONFIG_MTD_SM_COMMON is not set
# CONFIG_MTD_NAND_MUSEUM_IDS is not set
# CONFIG_MTD_NAND_DENALI is not set
# CONFIG_MTD_NAND_GPIO is not set
CONFIG_MTD_NAND_OMAP2=y
CONFIG_MTD_NAND_OMAP_BCH=y
CONFIG_MTD_NAND_OMAP_BCH8=y
# CONFIG_MTD_NAND_OMAP_BCH4 is not set
CONFIG_MTD_NAND_IDS=y
# CONFIG_MTD_NAND_DISKONCHIP is not set
# CONFIG_MTD_NAND_DOCG4 is not set
# CONFIG_MTD_NAND_NANDSIM is not set
# CONFIG_MTD_NAND_PLATFORM is not set
# CONFIG_MTD_ALAUDA is not set
# CONFIG_MTD_ONENAND is not set

#
# LPDDR flash memory drivers
#
# CONFIG_MTD_LPDDR is not set
CONFIG_MTD_UBI=y
CONFIG_MTD_UBI_WL_THRESHOLD=4096
CONFIG_MTD_UBI_BEB_LIMIT=20
# CONFIG_MTD_UBI_FASTMAP is not set
# CONFIG_MTD_UBI_GLUEBI is not set
CONFIG_DTC=y
CONFIG_OF=y

#
# Device Tree and Open Firmware support
#
CONFIG_PROC_DEVICETREE=y
# CONFIG_OF_SELFTEST is not set
CONFIG_OF_FLATTREE=y
CONFIG_OF_EARLY_FLATTREE=y
CONFIG_OF_ADDRESS=y
CONFIG_OF_IRQ=y
CONFIG_OF_DEVICE=y
CONFIG_OF_I2C=y
CONFIG_OF_NET=y
CONFIG_OF_MDIO=y
CONFIG_OF_MTD=y
# CONFIG_PARPORT is not set
CONFIG_BLK_DEV=y
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_LOOP_MIN_COUNT=8
# CONFIG_BLK_DEV_CRYPTOLOOP is not set
# CONFIG_BLK_DEV_DRBD is not set
# CONFIG_BLK_DEV_NBD is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=16384
# CONFIG_BLK_DEV_XIP is not set
# CONFIG_CDROM_PKTCDVD is not set
# CONFIG_ATA_OVER_ETH is not set
# CONFIG_MG_DISK is not set
# CONFIG_BLK_DEV_RBD is not set

#
# Misc devices
#
# CONFIG_SENSORS_LIS3LV02D is not set
# CONFIG_AD525X_DPOT is not set
# CONFIG_ATMEL_PWM is not set
# CONFIG_ICS932S401 is not set
# CONFIG_ATMEL_SSC is not set
# CONFIG_ENCLOSURE_SERVICES is not set
# CONFIG_APDS9802ALS is not set
# CONFIG_ISL29003 is not set
# CONFIG_ISL29020 is not set
# CONFIG_SENSORS_TSL2550 is not set
# CONFIG_SENSORS_BH1780 is not set
# CONFIG_SENSORS_BH1770 is not set
# CONFIG_SENSORS_APDS990X is not set
# CONFIG_HMC6352 is not set
# CONFIG_DS1682 is not set
# CONFIG_TI_DAC7512 is not set
# CONFIG_ARM_CHARLCD is not set
# CONFIG_BMP085_I2C is not set
# CONFIG_BMP085_SPI is not set
# CONFIG_USB_SWITCH_FSA9480 is not set
# CONFIG_LATTICE_ECP3_CONFIG is not set
# CONFIG_C2PORT is not set

#
# EEPROM support
#
CONFIG_EEPROM_AT24=y
# CONFIG_EEPROM_AT25 is not set
# CONFIG_EEPROM_LEGACY is not set
# CONFIG_EEPROM_MAX6875 is not set
# CONFIG_EEPROM_93CX6 is not set
# CONFIG_EEPROM_93XX46 is not set

#
# Texas Instruments shared transport line discipline
#
# CONFIG_TI_ST is not set
# CONFIG_SENSORS_LIS3_SPI is not set
# CONFIG_SENSORS_LIS3_I2C is not set

#
# Altera FPGA firmware download module
#
# CONFIG_ALTERA_STAPL is not set

#
# SCSI device support
#
CONFIG_SCSI_MOD=y
# CONFIG_RAID_ATTRS is not set
# CONFIG_SCSI is not set
# CONFIG_SCSI_DMA is not set
# CONFIG_SCSI_NETLINK is not set
CONFIG_HAVE_PATA_PLATFORM=y
# CONFIG_ATA is not set
# CONFIG_MD is not set
CONFIG_NETDEVICES=y
CONFIG_NET_CORE=y
# CONFIG_BONDING is not set
# CONFIG_DUMMY is not set
# CONFIG_EQUALIZER is not set
CONFIG_MII=y
# CONFIG_NET_TEAM is not set
# CONFIG_MACVLAN is not set
# CONFIG_VXLAN is not set
# CONFIG_NETCONSOLE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set
# CONFIG_TUN is not set
# CONFIG_VETH is not set

#
# CAIF transport drivers
#

#
# Distributed Switch Architecture drivers
#
# CONFIG_NET_DSA_MV88E6XXX is not set
# CONFIG_NET_DSA_MV88E6060 is not set
# CONFIG_NET_DSA_MV88E6XXX_NEED_PPU is not set
# CONFIG_NET_DSA_MV88E6131 is not set
# CONFIG_NET_DSA_MV88E6123_61_65 is not set
CONFIG_ETHERNET=y
# CONFIG_NET_CADENCE is not set
# CONFIG_NET_VENDOR_BROADCOM is not set
# CONFIG_NET_CALXEDA_XGMAC is not set
# CONFIG_NET_VENDOR_CIRRUS is not set
# CONFIG_DM9000 is not set
# CONFIG_DNET is not set
# CONFIG_NET_VENDOR_FARADAY is not set
# CONFIG_NET_VENDOR_INTEL is not set
# CONFIG_NET_VENDOR_MARVELL is not set
# CONFIG_NET_VENDOR_MICREL is not set
# CONFIG_NET_VENDOR_MICROCHIP is not set
# CONFIG_NET_VENDOR_NATSEMI is not set
# CONFIG_ETHOC is not set
# CONFIG_NET_VENDOR_SEEQ is not set
# CONFIG_NET_VENDOR_SMSC is not set
# CONFIG_NET_VENDOR_STMICRO is not set
CONFIG_NET_VENDOR_TI=y
CONFIG_TI_DAVINCI_EMAC=y
CONFIG_TI_DAVINCI_MDIO=y
CONFIG_TI_DAVINCI_CPDMA=y
CONFIG_TI_CPSW=y
# CONFIG_TI_CPTS is not set
# CONFIG_NET_VENDOR_WIZNET is not set
CONFIG_PHYLIB=y

#
# MII PHY device drivers
#
# CONFIG_AT803X_PHY is not set
# CONFIG_AMD_PHY is not set
# CONFIG_MARVELL_PHY is not set
# CONFIG_DAVICOM_PHY is not set
# CONFIG_QSEMI_PHY is not set
# CONFIG_LXT_PHY is not set
# CONFIG_CICADA_PHY is not set
# CONFIG_VITESSE_PHY is not set
CONFIG_SMSC_PHY=y
# CONFIG_BROADCOM_PHY is not set
# CONFIG_BCM87XX_PHY is not set
# CONFIG_ICPLUS_PHY is not set
# CONFIG_REALTEK_PHY is not set
# CONFIG_NATIONAL_PHY is not set
# CONFIG_STE10XP is not set
# CONFIG_LSI_ET1011C_PHY is not set
# CONFIG_MICREL_PHY is not set
# CONFIG_FIXED_PHY is not set
# CONFIG_MDIO_BITBANG is not set
# CONFIG_MDIO_BUS_MUX_GPIO is not set
# CONFIG_MDIO_BUS_MUX_MMIOREG is not set
# CONFIG_MICREL_KS8995MA is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set

#
# USB Network Adapters
#
# CONFIG_USB_CATC is not set
# CONFIG_USB_KAWETH is not set
# CONFIG_USB_PEGASUS is not set
# CONFIG_USB_RTL8150 is not set
CONFIG_USB_USBNET=y
CONFIG_USB_NET_AX8817X=y
# CONFIG_USB_NET_AX88179_178A is not set
CONFIG_USB_NET_CDCETHER=y
# CONFIG_USB_NET_CDC_EEM is not set
CONFIG_USB_NET_CDC_NCM=y
# CONFIG_USB_NET_CDC_MBIM is not set
# CONFIG_USB_NET_DM9601 is not set
# CONFIG_USB_NET_SMSC75XX is not set
CONFIG_USB_NET_SMSC95XX=y
# CONFIG_USB_NET_GL620A is not set
CONFIG_USB_NET_NET1080=y
# CONFIG_USB_NET_PLUSB is not set
# CONFIG_USB_NET_MCS7830 is not set
# CONFIG_USB_NET_RNDIS_HOST is not set
CONFIG_USB_NET_CDC_SUBSET=y
CONFIG_USB_ALI_M5632=y
CONFIG_USB_AN2720=y
CONFIG_USB_BELKIN=y
CONFIG_USB_ARMLINUX=y
CONFIG_USB_EPSON2888=y
CONFIG_USB_KC2190=y
CONFIG_USB_NET_ZAURUS=y
# CONFIG_USB_NET_CX82310_ETH is not set
# CONFIG_USB_NET_KALMIA is not set
# CONFIG_USB_NET_QMI_WWAN is not set
# CONFIG_USB_NET_INT51X1 is not set
# CONFIG_USB_IPHETH is not set
# CONFIG_USB_SIERRA_NET is not set
# CONFIG_USB_VL600 is not set
CONFIG_WLAN=y
# CONFIG_LIBERTAS_THINFIRM is not set
# CONFIG_AT76C50X_USB is not set
# CONFIG_USB_ZD1201 is not set
# CONFIG_USB_NET_RNDIS_WLAN is not set
# CONFIG_RTL8187 is not set
# CONFIG_MAC80211_HWSIM is not set
# CONFIG_ATH_CARDS is not set
# CONFIG_B43 is not set
# CONFIG_B43LEGACY is not set
# CONFIG_BRCMFMAC is not set
# CONFIG_HOSTAP is not set
# CONFIG_LIBERTAS is not set
# CONFIG_P54_COMMON is not set
CONFIG_RT2X00=y
# CONFIG_RT2500USB is not set
# CONFIG_RT73USB is not set
CONFIG_RT2800USB=y
CONFIG_RT2800USB_RT33XX=y
CONFIG_RT2800USB_RT35XX=y
# CONFIG_RT2800USB_RT53XX is not set
# CONFIG_RT2800USB_UNKNOWN is not set
CONFIG_RT2800_LIB=y
CONFIG_RT2X00_LIB_USB=y
CONFIG_RT2X00_LIB=y
CONFIG_RT2X00_LIB_FIRMWARE=y
CONFIG_RT2X00_LIB_CRYPTO=y
CONFIG_RT2X00_LIB_LEDS=y
# CONFIG_RT2X00_DEBUG is not set
# CONFIG_RTLWIFI is not set
# CONFIG_WL_TI is not set
# CONFIG_ZD1211RW is not set
# CONFIG_MWIFIEX is not set

#
# Enable WiMAX (Networking options) to see the WiMAX drivers
#
# CONFIG_WAN is not set
# CONFIG_ISDN is not set

#
# Input device support
#
CONFIG_INPUT=y
# CONFIG_INPUT_FF_MEMLESS is not set
# CONFIG_INPUT_POLLDEV is not set
# CONFIG_INPUT_SPARSEKMAP is not set
# CONFIG_INPUT_MATRIXKMAP is not set

#
# Userland interfaces
#
# CONFIG_INPUT_MOUSEDEV is not set
# CONFIG_INPUT_JOYDEV is not set
# CONFIG_INPUT_EVDEV is not set
# CONFIG_INPUT_EVBUG is not set

#
# Input Device Drivers
#
# CONFIG_INPUT_KEYBOARD is not set
# CONFIG_INPUT_MOUSE is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TABLET is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
# CONFIG_INPUT_MISC is not set

#
# Hardware I/O ports
#
# CONFIG_SERIO is not set
# CONFIG_GAMEPORT is not set

#
# Character devices
#
CONFIG_TTY=y
CONFIG_VT=y
CONFIG_CONSOLE_TRANSLATIONS=y
CONFIG_VT_CONSOLE=y
CONFIG_VT_CONSOLE_SLEEP=y
CONFIG_HW_CONSOLE=y
CONFIG_VT_HW_CONSOLE_BINDING=y
CONFIG_UNIX98_PTYS=y
# CONFIG_DEVPTS_MULTIPLE_INSTANCES is not set
# CONFIG_LEGACY_PTYS is not set
# CONFIG_SERIAL_NONSTANDARD is not set
# CONFIG_N_GSM is not set
# CONFIG_TRACE_SINK is not set
CONFIG_DEVKMEM=y

#
# Serial drivers
#
CONFIG_SERIAL_8250=y
# CONFIG_SERIAL_8250_DEPRECATED_OPTIONS is not set
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_8250_DMA=y
CONFIG_SERIAL_8250_NR_UARTS=32
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
CONFIG_SERIAL_8250_EXTENDED=y
CONFIG_SERIAL_8250_MANY_PORTS=y
CONFIG_SERIAL_8250_SHARE_IRQ=y
CONFIG_SERIAL_8250_DETECT_IRQ=y
CONFIG_SERIAL_8250_RSA=y
# CONFIG_SERIAL_8250_DW is not set
# CONFIG_SERIAL_8250_EM is not set

#
# Non-8250 serial port support
#
# CONFIG_SERIAL_AMBA_PL010 is not set
# CONFIG_SERIAL_AMBA_PL011 is not set
# CONFIG_SERIAL_MAX3100 is not set
# CONFIG_SERIAL_MAX310X is not set
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
# CONFIG_SERIAL_OF_PLATFORM is not set
CONFIG_SERIAL_OMAP=y
CONFIG_SERIAL_OMAP_CONSOLE=y
# CONFIG_SERIAL_SCCNXP is not set
# CONFIG_SERIAL_TIMBERDALE is not set
# CONFIG_SERIAL_ALTERA_JTAGUART is not set
# CONFIG_SERIAL_ALTERA_UART is not set
# CONFIG_SERIAL_IFX6X60 is not set
# CONFIG_SERIAL_XILINX_PS_UART is not set
# CONFIG_SERIAL_ARC is not set
# CONFIG_TTY_PRINTK is not set
# CONFIG_HVC_DCC is not set
# CONFIG_IPMI_HANDLER is not set
CONFIG_HW_RANDOM=y
# CONFIG_HW_RANDOM_TIMERIOMEM is not set
# CONFIG_HW_RANDOM_ATMEL is not set
# CONFIG_HW_RANDOM_EXYNOS is not set
# CONFIG_R3964 is not set
# CONFIG_RAW_DRIVER is not set
# CONFIG_TCG_TPM is not set
CONFIG_I2C=y
CONFIG_I2C_BOARDINFO=y
CONFIG_I2C_COMPAT=y
CONFIG_I2C_CHARDEV=y
# CONFIG_I2C_MUX is not set
CONFIG_I2C_HELPER_AUTO=y

#
# I2C Hardware Bus support
#

#
# I2C system bus drivers (mostly embedded / system-on-chip)
#
# CONFIG_I2C_CBUS_GPIO is not set
# CONFIG_I2C_DESIGNWARE_PLATFORM is not set
# CONFIG_I2C_GPIO is not set
# CONFIG_I2C_NOMADIK is not set
# CONFIG_I2C_OCORES is not set
CONFIG_I2C_OMAP=y
# CONFIG_I2C_PCA_PLATFORM is not set
# CONFIG_I2C_PXA_PCI is not set
# CONFIG_I2C_SIMTEC is not set
# CONFIG_I2C_VERSATILE is not set
# CONFIG_I2C_XILINX is not set

#
# External I2C/SMBus adapter drivers
#
# CONFIG_I2C_DIOLAN_U2C is not set
# CONFIG_I2C_PARPORT_LIGHT is not set
# CONFIG_I2C_TAOS_EVM is not set
# CONFIG_I2C_TINY_USB is not set

#
# Other I2C/SMBus bus drivers
#
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
CONFIG_SPI=y
# CONFIG_SPI_DEBUG is not set
CONFIG_SPI_MASTER=y

#
# SPI Master Controller Drivers
#
# CONFIG_SPI_ALTERA is not set
# CONFIG_SPI_BITBANG is not set
# CONFIG_SPI_GPIO is not set
# CONFIG_SPI_OC_TINY is not set
CONFIG_SPI_OMAP24XX=y
# CONFIG_SPI_PL022 is not set
# CONFIG_SPI_PXA2XX_PCI is not set
# CONFIG_SPI_SC18IS602 is not set
# CONFIG_SPI_XCOMM is not set
# CONFIG_SPI_XILINX is not set
# CONFIG_SPI_DESIGNWARE is not set

#
# SPI Protocol Masters
#
# CONFIG_SPI_SPIDEV is not set
# CONFIG_SPI_TLE62X0 is not set
# CONFIG_HSI is not set

#
# PPS support
#
# CONFIG_PPS is not set

#
# PPS generators support
#

#
# PTP clock support
#
# CONFIG_PTP_1588_CLOCK is not set

#
# Enable PHYLIB and NETWORK_PHY_TIMESTAMPING to see the additional clocks.
#
# CONFIG_PTP_1588_CLOCK_PCH is not set
CONFIG_PINCTRL=y

#
# Pin controllers
#
CONFIG_PINMUX=y
CONFIG_PINCONF=y
# CONFIG_DEBUG_PINCTRL is not set
CONFIG_PINCTRL_SINGLE=y
# CONFIG_PINCTRL_EXYNOS is not set
# CONFIG_PINCTRL_EXYNOS5440 is not set
CONFIG_ARCH_HAVE_CUSTOM_GPIO_H=y
CONFIG_ARCH_REQUIRE_GPIOLIB=y
CONFIG_GPIO_DEVRES=y
CONFIG_GPIOLIB=y
CONFIG_OF_GPIO=y
CONFIG_DEBUG_GPIO=y
CONFIG_GPIO_SYSFS=y

#
# Memory mapped GPIO drivers:
#
# CONFIG_GPIO_GENERIC_PLATFORM is not set
# CONFIG_GPIO_EM is not set
# CONFIG_GPIO_PL061 is not set
# CONFIG_GPIO_TS5500 is not set

#
# I2C GPIO expanders:
#
# CONFIG_GPIO_MAX7300 is not set
# CONFIG_GPIO_MAX732X is not set
# CONFIG_GPIO_PCF857X is not set
# CONFIG_GPIO_SX150X is not set
# CONFIG_GPIO_TWL4030 is not set
# CONFIG_GPIO_ADP5588 is not set
# CONFIG_GPIO_ADNP is not set

#
# PCI GPIO expanders:
#

#
# SPI GPIO expanders:
#
# CONFIG_GPIO_MAX7301 is not set
CONFIG_GPIO_MCP23S08=y
# CONFIG_GPIO_MC33880 is not set
# CONFIG_GPIO_74X164 is not set

#
# AC97 GPIO expanders:
#

#
# MODULbus GPIO expanders:
#

#
# USB GPIO expanders:
#
# CONFIG_W1 is not set
# CONFIG_POWER_SUPPLY is not set
# CONFIG_POWER_AVS is not set
# CONFIG_HWMON is not set
# CONFIG_THERMAL is not set
CONFIG_WATCHDOG=y
CONFIG_WATCHDOG_CORE=y
# CONFIG_WATCHDOG_NOWAYOUT is not set

#
# Watchdog Device Drivers
#
# CONFIG_SOFT_WATCHDOG is not set
# CONFIG_ARM_SP805_WATCHDOG is not set
# CONFIG_DW_WATCHDOG is not set
CONFIG_OMAP_WATCHDOG=y
CONFIG_TWL4030_WATCHDOG=y
# CONFIG_MAX63XX_WATCHDOG is not set

#
# USB-based Watchdog Cards
#
# CONFIG_USBPCWATCHDOG is not set
CONFIG_SSB_POSSIBLE=y

#
# Sonics Silicon Backplane
#
# CONFIG_SSB is not set
CONFIG_BCMA_POSSIBLE=y

#
# Broadcom specific AMBA
#
# CONFIG_BCMA is not set

#
# Multifunction device drivers
#
CONFIG_MFD_CORE=y
# CONFIG_MFD_88PM860X is not set
# CONFIG_MFD_88PM800 is not set
# CONFIG_MFD_88PM805 is not set
# CONFIG_MFD_SM501 is not set
# CONFIG_MFD_ASIC3 is not set
# CONFIG_MFD_TI_AM335X_TSCADC is not set
# CONFIG_HTC_EGPIO is not set
# CONFIG_HTC_PASIC3 is not set
# CONFIG_HTC_I2CPLD is not set
# CONFIG_MFD_LM3533 is not set
# CONFIG_TPS6105X is not set
# CONFIG_TPS65010 is not set
# CONFIG_TPS6507X is not set
CONFIG_MFD_TPS65217=y
# CONFIG_MFD_TPS6586X is not set
# CONFIG_MFD_TPS65910 is not set
# CONFIG_MFD_TPS65912_I2C is not set
# CONFIG_MFD_TPS65912_SPI is not set
# CONFIG_MFD_TPS80031 is not set
CONFIG_TWL4030_CORE=y
# CONFIG_TWL4030_MADC is not set
CONFIG_TWL4030_POWER=y
# CONFIG_MFD_TWL4030_AUDIO is not set
# CONFIG_TWL6040_CORE is not set
# CONFIG_MFD_STMPE is not set
# CONFIG_MFD_TC3589X is not set
# CONFIG_MFD_TMIO is not set
# CONFIG_MFD_T7L66XB is not set
# CONFIG_MFD_SMSC is not set
# CONFIG_MFD_TC6387XB is not set
# CONFIG_MFD_TC6393XB is not set
# CONFIG_PMIC_DA903X is not set
# CONFIG_MFD_DA9052_SPI is not set
# CONFIG_MFD_DA9052_I2C is not set
# CONFIG_MFD_DA9055 is not set
# CONFIG_PMIC_ADP5520 is not set
# CONFIG_MFD_LP8788 is not set
# CONFIG_MFD_MAX77686 is not set
# CONFIG_MFD_MAX77693 is not set
# CONFIG_MFD_MAX8907 is not set
# CONFIG_MFD_MAX8925 is not set
# CONFIG_MFD_MAX8997 is not set
# CONFIG_MFD_MAX8998 is not set
# CONFIG_MFD_SEC_CORE is not set
# CONFIG_MFD_ARIZONA_I2C is not set
# CONFIG_MFD_ARIZONA_SPI is not set
# CONFIG_MFD_WM8400 is not set
# CONFIG_MFD_WM831X_I2C is not set
# CONFIG_MFD_WM831X_SPI is not set
# CONFIG_MFD_WM8350_I2C is not set
# CONFIG_MFD_WM8994 is not set
# CONFIG_MFD_PCF50633 is not set
# CONFIG_MFD_MC13XXX_SPI is not set
# CONFIG_MFD_MC13XXX_I2C is not set
# CONFIG_ABX500_CORE is not set
# CONFIG_EZX_PCAP is not set
# CONFIG_MFD_WL1273_CORE is not set
# CONFIG_MFD_TPS65090 is not set
# CONFIG_MFD_AAT2870_CORE is not set
# CONFIG_MFD_RC5T583 is not set
# CONFIG_MFD_SYSCON is not set
# CONFIG_MFD_PALMAS is not set
# CONFIG_MFD_VIPERBOARD is not set
# CONFIG_MFD_RETU is not set
# CONFIG_MFD_AS3711 is not set
CONFIG_VEXPRESS_CONFIG=y
CONFIG_REGULATOR=y
# CONFIG_REGULATOR_DEBUG is not set
# CONFIG_REGULATOR_DUMMY is not set
CONFIG_REGULATOR_FIXED_VOLTAGE=y
# CONFIG_REGULATOR_VIRTUAL_CONSUMER is not set
# CONFIG_REGULATOR_USERSPACE_CONSUMER is not set
# CONFIG_REGULATOR_GPIO is not set
# CONFIG_REGULATOR_AD5398 is not set
# CONFIG_REGULATOR_FAN53555 is not set
# CONFIG_REGULATOR_ISL6271A is not set
# CONFIG_REGULATOR_MAX1586 is not set
# CONFIG_REGULATOR_MAX8649 is not set
# CONFIG_REGULATOR_MAX8660 is not set
# CONFIG_REGULATOR_MAX8952 is not set
# CONFIG_REGULATOR_MAX8973 is not set
# CONFIG_REGULATOR_LP3971 is not set
# CONFIG_REGULATOR_LP3972 is not set
# CONFIG_REGULATOR_LP872X is not set
# CONFIG_REGULATOR_LP8755 is not set
# CONFIG_REGULATOR_TPS51632 is not set
# CONFIG_REGULATOR_TPS62360 is not set
CONFIG_REGULATOR_TPS65023=y
CONFIG_REGULATOR_TPS6507X=y
CONFIG_REGULATOR_TPS65217=y
# CONFIG_REGULATOR_TPS6524X is not set
CONFIG_REGULATOR_TWL4030=y
# CONFIG_REGULATOR_VEXPRESS is not set
# CONFIG_MEDIA_SUPPORT is not set

#
# Graphics support
#
# CONFIG_DRM is not set
# CONFIG_VGASTATE is not set
# CONFIG_VIDEO_OUTPUT_CONTROL is not set
# CONFIG_OF_DISPLAY_TIMING is not set
# CONFIG_OF_VIDEOMODE is not set
# CONFIG_FB is not set
# CONFIG_OMAP2_DSS is not set
# CONFIG_EXYNOS_VIDEO is not set
# CONFIG_BACKLIGHT_LCD_SUPPORT is not set

#
# Console display driver support
#
CONFIG_DUMMY_CONSOLE=y
# CONFIG_SOUND is not set

#
# HID support
#
CONFIG_HID=y
# CONFIG_HIDRAW is not set
# CONFIG_UHID is not set
CONFIG_HID_GENERIC=y

#
# Special HID drivers
#
# CONFIG_HID_A4TECH is not set
# CONFIG_HID_ACRUX is not set
# CONFIG_HID_APPLE is not set
# CONFIG_HID_AUREAL is not set
# CONFIG_HID_BELKIN is not set
# CONFIG_HID_CHERRY is not set
# CONFIG_HID_CHICONY is not set
# CONFIG_HID_CYPRESS is not set
# CONFIG_HID_DRAGONRISE is not set
# CONFIG_HID_EMS_FF is not set
# CONFIG_HID_EZKEY is not set
# CONFIG_HID_HOLTEK is not set
# CONFIG_HID_KEYTOUCH is not set
# CONFIG_HID_KYE is not set
# CONFIG_HID_UCLOGIC is not set
# CONFIG_HID_WALTOP is not set
# CONFIG_HID_GYRATION is not set
# CONFIG_HID_TWINHAN is not set
# CONFIG_HID_KENSINGTON is not set
# CONFIG_HID_LCPOWER is not set
# CONFIG_HID_LENOVO_TPKBD is not set
# CONFIG_HID_LOGITECH is not set
# CONFIG_HID_MICROSOFT is not set
# CONFIG_HID_MONTEREY is not set
# CONFIG_HID_MULTITOUCH is not set
# CONFIG_HID_NTRIG is not set
# CONFIG_HID_ORTEK is not set
# CONFIG_HID_PANTHERLORD is not set
# CONFIG_HID_PETALYNX is not set
# CONFIG_HID_PICOLCD is not set
# CONFIG_HID_PRIMAX is not set
# CONFIG_HID_ROCCAT is not set
# CONFIG_HID_SAITEK is not set
# CONFIG_HID_SAMSUNG is not set
# CONFIG_HID_SONY is not set
# CONFIG_HID_SPEEDLINK is not set
# CONFIG_HID_STEELSERIES is not set
# CONFIG_HID_SUNPLUS is not set
# CONFIG_HID_GREENASIA is not set
# CONFIG_HID_SMARTJOYPLUS is not set
# CONFIG_HID_TIVO is not set
# CONFIG_HID_TOPSEED is not set
# CONFIG_HID_THINGM is not set
# CONFIG_HID_THRUSTMASTER is not set
# CONFIG_HID_ZEROPLUS is not set
# CONFIG_HID_ZYDACRON is not set
# CONFIG_HID_SENSOR_HUB is not set

#
# USB HID support
#
CONFIG_USB_HID=y
# CONFIG_HID_PID is not set
# CONFIG_USB_HIDDEV is not set

#
# I2C HID support
#
# CONFIG_I2C_HID is not set
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB_ARCH_HAS_EHCI=y
# CONFIG_USB_ARCH_HAS_XHCI is not set
CONFIG_USB_SUPPORT=y
CONFIG_USB_COMMON=y
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB=y
CONFIG_USB_DEBUG=y
CONFIG_USB_ANNOUNCE_NEW_DEVICES=y

#
# Miscellaneous USB options
#
# CONFIG_USB_DYNAMIC_MINORS is not set
CONFIG_USB_SUSPEND=y
# CONFIG_USB_OTG is not set
# CONFIG_USB_OTG_WHITELIST is not set
# CONFIG_USB_OTG_BLACKLIST_HUB is not set
# CONFIG_USB_DWC3 is not set
CONFIG_USB_MON=y
# CONFIG_USB_WUSB_CBAF is not set

#
# USB Host Controller Drivers
#
# CONFIG_USB_C67X00_HCD is not set
# CONFIG_USB_EHCI_HCD is not set
# CONFIG_USB_OXU210HP_HCD is not set
# CONFIG_USB_ISP116X_HCD is not set
# CONFIG_USB_ISP1760_HCD is not set
# CONFIG_USB_ISP1362_HCD is not set
# CONFIG_USB_OHCI_HCD is not set
# CONFIG_USB_SL811_HCD is not set
# CONFIG_USB_R8A66597_HCD is not set
# CONFIG_USB_CHIPIDEA is not set

#
# USB Device Class drivers
#
# CONFIG_USB_ACM is not set
# CONFIG_USB_PRINTER is not set
CONFIG_USB_WDM=y
# CONFIG_USB_TMC is not set

#
# NOTE: USB_STORAGE depends on SCSI but BLK_DEV_SD may
#

#
# also be needed; see USB_STORAGE Help for more info
#

#
# USB Imaging devices
#
# CONFIG_USB_MDC800 is not set

#
# USB port drivers
#
# CONFIG_USB_SERIAL is not set

#
# USB Miscellaneous drivers
#
# CONFIG_USB_EMI62 is not set
# CONFIG_USB_EMI26 is not set
# CONFIG_USB_ADUTUX is not set
# CONFIG_USB_SEVSEG is not set
# CONFIG_USB_RIO500 is not set
# CONFIG_USB_LEGOTOWER is not set
# CONFIG_USB_LCD is not set
# CONFIG_USB_LED is not set
# CONFIG_USB_CYPRESS_CY7C63 is not set
# CONFIG_USB_CYTHERM is not set
# CONFIG_USB_IDMOUSE is not set
# CONFIG_USB_FTDI_ELAN is not set
# CONFIG_USB_APPLEDISPLAY is not set
# CONFIG_USB_LD is not set
# CONFIG_USB_TRANCEVIBRATOR is not set
# CONFIG_USB_IOWARRIOR is not set
CONFIG_USB_TEST=y
# CONFIG_USB_ISIGHTFW is not set
# CONFIG_USB_YUREX is not set
# CONFIG_USB_EZUSB_FX2 is not set
# CONFIG_USB_HSIC_USB3503 is not set

#
# USB Physical Layer drivers
#
# CONFIG_OMAP_USB2 is not set
# CONFIG_OMAP_USB3 is not set
# CONFIG_OMAP_CONTROL_USB is not set
# CONFIG_USB_ISP1301 is not set
# CONFIG_USB_RCAR_PHY is not set
# CONFIG_USB_GADGET is not set

#
# OTG and related infrastructure
#
# CONFIG_USB_GPIO_VBUS is not set
# CONFIG_USB_ULPI is not set
# CONFIG_NOP_USB_XCEIV is not set
CONFIG_MMC=y
# CONFIG_MMC_DEBUG is not set
CONFIG_MMC_UNSAFE_RESUME=y
# CONFIG_MMC_CLKGATE is not set

#
# MMC/SD/SDIO Card Drivers
#
CONFIG_MMC_BLOCK=y
CONFIG_MMC_BLOCK_MINORS=8
CONFIG_MMC_BLOCK_BOUNCE=y
CONFIG_SDIO_UART=y
# CONFIG_MMC_TEST is not set

#
# MMC/SD/SDIO Host Controller Drivers
#
# CONFIG_MMC_ARMMMCI is not set
# CONFIG_MMC_SDHCI is not set
# CONFIG_MMC_SDHCI_PXAV3 is not set
# CONFIG_MMC_SDHCI_PXAV2 is not set
CONFIG_MMC_OMAP=y
CONFIG_MMC_OMAP_HS=y
# CONFIG_MMC_DW is not set
# CONFIG_MMC_VUB300 is not set
# CONFIG_MMC_USHC is not set
# CONFIG_MEMSTICK is not set
CONFIG_NEW_LEDS=y
CONFIG_LEDS_CLASS=y

#
# LED drivers
#
# CONFIG_LEDS_LM3530 is not set
# CONFIG_LEDS_LM3642 is not set
# CONFIG_LEDS_PCA9532 is not set
CONFIG_LEDS_GPIO=y
# CONFIG_LEDS_LP3944 is not set
# CONFIG_LEDS_LP5521 is not set
# CONFIG_LEDS_LP5523 is not set
# CONFIG_LEDS_PCA955X is not set
# CONFIG_LEDS_PCA9633 is not set
# CONFIG_LEDS_DAC124S085 is not set
# CONFIG_LEDS_REGULATOR is not set
# CONFIG_LEDS_BD2802 is not set
# CONFIG_LEDS_LT3593 is not set
# CONFIG_LEDS_RENESAS_TPU is not set
# CONFIG_LEDS_TCA6507 is not set
# CONFIG_LEDS_LM355x is not set
# CONFIG_LEDS_OT200 is not set
# CONFIG_LEDS_BLINKM is not set
# CONFIG_LEDS_TRIGGERS is not set

#
# LED Triggers
#
# CONFIG_ACCESSIBILITY is not set
# CONFIG_EDAC is not set
CONFIG_RTC_LIB=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_HCTOSYS=y
CONFIG_RTC_SYSTOHC=y
CONFIG_RTC_HCTOSYS_DEVICE="rtc0"
# CONFIG_RTC_DEBUG is not set

#
# RTC interfaces
#
CONFIG_RTC_INTF_SYSFS=y
CONFIG_RTC_INTF_PROC=y
CONFIG_RTC_INTF_DEV=y
# CONFIG_RTC_INTF_DEV_UIE_EMUL is not set
# CONFIG_RTC_DRV_TEST is not set

#
# I2C RTC drivers
#
CONFIG_RTC_DRV_DS1307=y
# CONFIG_RTC_DRV_DS1374 is not set
# CONFIG_RTC_DRV_DS1672 is not set
# CONFIG_RTC_DRV_DS3232 is not set
# CONFIG_RTC_DRV_MAX6900 is not set
# CONFIG_RTC_DRV_RS5C372 is not set
# CONFIG_RTC_DRV_ISL1208 is not set
# CONFIG_RTC_DRV_ISL12022 is not set
# CONFIG_RTC_DRV_X1205 is not set
# CONFIG_RTC_DRV_PCF8523 is not set
# CONFIG_RTC_DRV_PCF8563 is not set
# CONFIG_RTC_DRV_PCF8583 is not set
# CONFIG_RTC_DRV_M41T80 is not set
# CONFIG_RTC_DRV_BQ32K is not set
# CONFIG_RTC_DRV_TWL4030 is not set
# CONFIG_RTC_DRV_S35390A is not set
# CONFIG_RTC_DRV_FM3130 is not set
# CONFIG_RTC_DRV_RX8581 is not set
# CONFIG_RTC_DRV_RX8025 is not set
# CONFIG_RTC_DRV_EM3027 is not set
# CONFIG_RTC_DRV_RV3029C2 is not set

#
# SPI RTC drivers
#
# CONFIG_RTC_DRV_M41T93 is not set
# CONFIG_RTC_DRV_M41T94 is not set
# CONFIG_RTC_DRV_DS1305 is not set
# CONFIG_RTC_DRV_DS1390 is not set
# CONFIG_RTC_DRV_MAX6902 is not set
# CONFIG_RTC_DRV_R9701 is not set
# CONFIG_RTC_DRV_RS5C348 is not set
# CONFIG_RTC_DRV_DS3234 is not set
# CONFIG_RTC_DRV_PCF2123 is not set
# CONFIG_RTC_DRV_RX4581 is not set

#
# Platform RTC drivers
#
# CONFIG_RTC_DRV_CMOS is not set
# CONFIG_RTC_DRV_DS1286 is not set
# CONFIG_RTC_DRV_DS1511 is not set
# CONFIG_RTC_DRV_DS1553 is not set
# CONFIG_RTC_DRV_DS1742 is not set
# CONFIG_RTC_DRV_STK17TA8 is not set
# CONFIG_RTC_DRV_M48T86 is not set
# CONFIG_RTC_DRV_M48T35 is not set
# CONFIG_RTC_DRV_M48T59 is not set
# CONFIG_RTC_DRV_MSM6242 is not set
# CONFIG_RTC_DRV_BQ4802 is not set
# CONFIG_RTC_DRV_RP5C01 is not set
# CONFIG_RTC_DRV_V3020 is not set
# CONFIG_RTC_DRV_DS2404 is not set

#
# on-CPU RTC drivers
#
# CONFIG_RTC_DRV_OMAP is not set
# CONFIG_RTC_DRV_PL030 is not set
# CONFIG_RTC_DRV_PL031 is not set
# CONFIG_RTC_DRV_SNVS is not set

#
# HID Sensor RTC drivers
#
# CONFIG_RTC_DRV_HID_SENSOR_TIME is not set
CONFIG_DMADEVICES=y
# CONFIG_DMADEVICES_DEBUG is not set

#
# DMA Devices
#
# CONFIG_AMBA_PL08X is not set
# CONFIG_DW_DMAC is not set
# CONFIG_TIMB_DMA is not set
# CONFIG_PL330_DMA is not set
CONFIG_DMA_OMAP=y
CONFIG_DMA_ENGINE=y
CONFIG_DMA_VIRTUAL_CHANNELS=y
CONFIG_DMA_OF=y

#
# DMA Clients
#
# CONFIG_NET_DMA is not set
# CONFIG_ASYNC_TX_DMA is not set
# CONFIG_DMATEST is not set
# CONFIG_AUXDISPLAY is not set
# CONFIG_UIO is not set

#
# Virtio drivers
#
# CONFIG_VIRTIO_MMIO is not set

#
# Microsoft Hyper-V guest support
#
# CONFIG_STAGING is not set
CONFIG_CLKDEV_LOOKUP=y
CONFIG_HAVE_CLK_PREPARE=y
CONFIG_COMMON_CLK=y

#
# Common Clock Framework
#
# CONFIG_COMMON_CLK_DEBUG is not set
CONFIG_COMMON_CLK_VERSATILE=y

#
# Hardware Spinlock drivers
#
CONFIG_CLKSRC_MMIO=y
CONFIG_ARM_ARCH_TIMER=y
# CONFIG_MAILBOX is not set
CONFIG_IOMMU_SUPPORT=y
CONFIG_OF_IOMMU=y
# CONFIG_OMAP_IOMMU is not set

#
# Remoteproc drivers
#
# CONFIG_STE_MODEM_RPROC is not set

#
# Rpmsg drivers
#
# CONFIG_VIRT_DRIVERS is not set
# CONFIG_PM_DEVFREQ is not set
# CONFIG_EXTCON is not set
# CONFIG_MEMORY is not set
# CONFIG_IIO is not set
# CONFIG_PWM is not set
CONFIG_IRQCHIP=y
CONFIG_ARM_GIC=y
# CONFIG_IPACK_BUS is not set

#
# File systems
#
CONFIG_DCACHE_WORD_ACCESS=y
CONFIG_EXT2_FS=y
# CONFIG_EXT2_FS_XATTR is not set
# CONFIG_EXT2_FS_XIP is not set
CONFIG_EXT3_FS=y
CONFIG_EXT3_DEFAULTS_TO_ORDERED=y
# CONFIG_EXT3_FS_XATTR is not set
# CONFIG_EXT4_FS is not set
CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
# CONFIG_XFS_FS is not set
# CONFIG_GFS2_FS is not set
# CONFIG_BTRFS_FS is not set
# CONFIG_NILFS2_FS is not set
# CONFIG_FS_POSIX_ACL is not set
CONFIG_FILE_LOCKING=y
CONFIG_FSNOTIFY=y
CONFIG_DNOTIFY=y
CONFIG_INOTIFY_USER=y
# CONFIG_FANOTIFY is not set
# CONFIG_QUOTA is not set
# CONFIG_QUOTACTL is not set
# CONFIG_AUTOFS4_FS is not set
# CONFIG_FUSE_FS is not set

#
# Caches
#
# CONFIG_FSCACHE is not set

#
# CD-ROM/DVD Filesystems
#
# CONFIG_ISO9660_FS is not set
# CONFIG_UDF_FS is not set

#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=y
CONFIG_VFAT_FS=y
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
# CONFIG_NTFS_FS is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_SYSCTL=y
CONFIG_PROC_PAGE_MONITOR=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
# CONFIG_TMPFS_POSIX_ACL is not set
# CONFIG_TMPFS_XATTR is not set
# CONFIG_HUGETLB_PAGE is not set
# CONFIG_CONFIGFS_FS is not set
CONFIG_MISC_FILESYSTEMS=y
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_ECRYPT_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_JFFS2_FS is not set
CONFIG_UBIFS_FS=y
CONFIG_UBIFS_FS_ADVANCED_COMPR=y
CONFIG_UBIFS_FS_LZO=y
# CONFIG_UBIFS_FS_ZLIB is not set
# CONFIG_LOGFS is not set
# CONFIG_CRAMFS is not set
# CONFIG_SQUASHFS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_OMFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_QNX6FS_FS is not set
# CONFIG_ROMFS_FS is not set
# CONFIG_PSTORE is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set
# CONFIG_F2FS_FS is not set
CONFIG_NETWORK_FILESYSTEMS=y
CONFIG_NFS_FS=y
CONFIG_NFS_V2=y
CONFIG_NFS_V3=y
# CONFIG_NFS_V3_ACL is not set
# CONFIG_NFS_V4 is not set
# CONFIG_NFS_SWAP is not set
CONFIG_ROOT_NFS=y
# CONFIG_NFSD is not set
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=y
# CONFIG_SUNRPC_DEBUG is not set
# CONFIG_CEPH_FS is not set
# CONFIG_CIFS is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
CONFIG_NLS_CODEPAGE_437=y
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
# CONFIG_NLS_CODEPAGE_850 is not set
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
# CONFIG_NLS_ASCII is not set
CONFIG_NLS_ISO8859_1=y
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
# CONFIG_NLS_ISO8859_15 is not set
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
# CONFIG_NLS_MAC_ROMAN is not set
# CONFIG_NLS_MAC_CELTIC is not set
# CONFIG_NLS_MAC_CENTEURO is not set
# CONFIG_NLS_MAC_CROATIAN is not set
# CONFIG_NLS_MAC_CYRILLIC is not set
# CONFIG_NLS_MAC_GAELIC is not set
# CONFIG_NLS_MAC_GREEK is not set
# CONFIG_NLS_MAC_ICELAND is not set
# CONFIG_NLS_MAC_INUIT is not set
# CONFIG_NLS_MAC_ROMANIAN is not set
# CONFIG_NLS_MAC_TURKISH is not set
# CONFIG_NLS_UTF8 is not set

#
# Kernel hacking
#
CONFIG_PRINTK_TIME=y
CONFIG_DEFAULT_MESSAGE_LOGLEVEL=4
CONFIG_ENABLE_WARN_DEPRECATED=y
CONFIG_ENABLE_MUST_CHECK=y
CONFIG_FRAME_WARN=1024
CONFIG_MAGIC_SYSRQ=y
# CONFIG_STRIP_ASM_SYMS is not set
# CONFIG_READABLE_ASM is not set
# CONFIG_UNUSED_SYMBOLS is not set
CONFIG_DEBUG_FS=y
# CONFIG_HEADERS_CHECK is not set
# CONFIG_DEBUG_SECTION_MISMATCH is not set
CONFIG_DEBUG_KERNEL=y
# CONFIG_DEBUG_SHIRQ is not set
# CONFIG_LOCKUP_DETECTOR is not set
# CONFIG_PANIC_ON_OOPS is not set
CONFIG_PANIC_ON_OOPS_VALUE=0
# CONFIG_DETECT_HUNG_TASK is not set
CONFIG_SCHED_DEBUG=y
CONFIG_SCHEDSTATS=y
CONFIG_TIMER_STATS=y
# CONFIG_DEBUG_OBJECTS is not set
# CONFIG_DEBUG_SLAB is not set
CONFIG_HAVE_DEBUG_KMEMLEAK=y
# CONFIG_DEBUG_KMEMLEAK is not set
# CONFIG_DEBUG_RT_MUTEXES is not set
# CONFIG_RT_MUTEX_TESTER is not set
CONFIG_DEBUG_SPINLOCK=y
CONFIG_DEBUG_MUTEXES=y
CONFIG_DEBUG_LOCK_ALLOC=y
CONFIG_PROVE_LOCKING=y
CONFIG_LOCKDEP=y
# CONFIG_LOCK_STAT is not set
# CONFIG_DEBUG_LOCKDEP is not set
CONFIG_TRACE_IRQFLAGS=y
# CONFIG_DEBUG_ATOMIC_SLEEP is not set
# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set
CONFIG_STACKTRACE=y
# CONFIG_DEBUG_STACK_USAGE is not set
# CONFIG_DEBUG_KOBJECT is not set
# CONFIG_DEBUG_HIGHMEM is not set
# CONFIG_DEBUG_BUGVERBOSE is not set
CONFIG_DEBUG_INFO=y
# CONFIG_DEBUG_INFO_REDUCED is not set
# CONFIG_DEBUG_VM is not set
# CONFIG_DEBUG_WRITECOUNT is not set
# CONFIG_DEBUG_MEMORY_INIT is not set
# CONFIG_DEBUG_LIST is not set
# CONFIG_TEST_LIST_SORT is not set
# CONFIG_DEBUG_SG is not set
# CONFIG_DEBUG_NOTIFIERS is not set
# CONFIG_DEBUG_CREDENTIALS is not set
# CONFIG_BOOT_PRINTK_DELAY is not set

#
# RCU Debugging
#
# CONFIG_PROVE_RCU is not set
# CONFIG_SPARSE_RCU_POINTER is not set
# CONFIG_RCU_TORTURE_TEST is not set
# CONFIG_RCU_TRACE is not set
# CONFIG_BACKTRACE_SELF_TEST is not set
# CONFIG_DEBUG_BLOCK_EXT_DEVT is not set
# CONFIG_DEBUG_FORCE_WEAK_PER_CPU is not set
# CONFIG_LKDTM is not set
# CONFIG_NOTIFIER_ERROR_INJECTION is not set
# CONFIG_FAULT_INJECTION is not set
# CONFIG_LATENCYTOP is not set
# CONFIG_DEBUG_PAGEALLOC is not set
CONFIG_HAVE_FUNCTION_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y
CONFIG_HAVE_DYNAMIC_FTRACE=y
CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y
CONFIG_HAVE_SYSCALL_TRACEPOINTS=y
CONFIG_HAVE_C_RECORDMCOUNT=y
CONFIG_TRACE_CLOCK=y
CONFIG_RING_BUFFER=y
CONFIG_RING_BUFFER_ALLOW_SWAP=y
CONFIG_TRACING_SUPPORT=y
CONFIG_FTRACE=y
# CONFIG_FUNCTION_TRACER is not set
# CONFIG_IRQSOFF_TRACER is not set
# CONFIG_SCHED_TRACER is not set
# CONFIG_ENABLE_DEFAULT_TRACERS is not set
# CONFIG_FTRACE_SYSCALLS is not set
# CONFIG_TRACER_SNAPSHOT is not set
CONFIG_BRANCH_PROFILE_NONE=y
# CONFIG_PROFILE_ANNOTATED_BRANCHES is not set
# CONFIG_PROFILE_ALL_BRANCHES is not set
# CONFIG_STACK_TRACER is not set
# CONFIG_BLK_DEV_IO_TRACE is not set
# CONFIG_PROBE_EVENTS is not set
# CONFIG_RING_BUFFER_BENCHMARK is not set
# CONFIG_DYNAMIC_DEBUG is not set
# CONFIG_DMA_API_DEBUG is not set
# CONFIG_ATOMIC64_SELFTEST is not set
# CONFIG_SAMPLES is not set
CONFIG_HAVE_ARCH_KGDB=y
# CONFIG_KGDB is not set
# CONFIG_TEST_KSTRTOX is not set
# CONFIG_STRICT_DEVMEM is not set
CONFIG_ARM_UNWIND=y
# CONFIG_DEBUG_USER is not set
CONFIG_DEBUG_LL=y
CONFIG_DEBUG_OMAP2PLUS_UART=y
# CONFIG_DEBUG_VEXPRESS_UART0_DETECT is not set
# CONFIG_DEBUG_VEXPRESS_UART0_CA9 is not set
# CONFIG_DEBUG_VEXPRESS_UART0_RS1 is not set
# CONFIG_DEBUG_ICEDCC is not set
# CONFIG_DEBUG_SEMIHOSTING is not set
# CONFIG_DEBUG_OMAP2UART1 is not set
# CONFIG_DEBUG_OMAP2UART2 is not set
# CONFIG_DEBUG_OMAP2UART3 is not set
# CONFIG_DEBUG_OMAP3UART3 is not set
# CONFIG_DEBUG_OMAP4UART3 is not set
# CONFIG_DEBUG_OMAP3UART4 is not set
# CONFIG_DEBUG_OMAP4UART4 is not set
# CONFIG_DEBUG_TI81XXUART1 is not set
# CONFIG_DEBUG_TI81XXUART2 is not set
# CONFIG_DEBUG_TI81XXUART3 is not set
CONFIG_DEBUG_AM33XXUART1=y
# CONFIG_DEBUG_ZOOM_UART is not set
CONFIG_DEBUG_LL_INCLUDE="debug/omap2plus.S"
CONFIG_EARLY_PRINTK=y
# CONFIG_OC_ETM is not set
# CONFIG_PID_IN_CONTEXTIDR is not set

#
# Security options
#
CONFIG_KEYS=y
# CONFIG_ENCRYPTED_KEYS is not set
# CONFIG_KEYS_DEBUG_PROC_KEYS is not set
# CONFIG_SECURITY_DMESG_RESTRICT is not set
CONFIG_SECURITY=y
# CONFIG_SECURITYFS is not set
# CONFIG_SECURITY_NETWORK is not set
# CONFIG_SECURITY_PATH is not set
# CONFIG_SECURITY_SMACK is not set
# CONFIG_SECURITY_TOMOYO is not set
# CONFIG_SECURITY_APPARMOR is not set
# CONFIG_SECURITY_YAMA is not set
# CONFIG_IMA is not set
# CONFIG_EVM is not set
CONFIG_DEFAULT_SECURITY_DAC=y
CONFIG_DEFAULT_SECURITY=""
CONFIG_CRYPTO=y

#
# Crypto core or helper
#
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_ALGAPI2=y
CONFIG_CRYPTO_AEAD2=y
CONFIG_CRYPTO_BLKCIPHER=y
CONFIG_CRYPTO_BLKCIPHER2=y
CONFIG_CRYPTO_HASH=y
CONFIG_CRYPTO_HASH2=y
CONFIG_CRYPTO_RNG2=y
CONFIG_CRYPTO_PCOMP2=y
CONFIG_CRYPTO_MANAGER=y
CONFIG_CRYPTO_MANAGER2=y
# CONFIG_CRYPTO_USER is not set
CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=y
# CONFIG_CRYPTO_GF128MUL is not set
# CONFIG_CRYPTO_NULL is not set
CONFIG_CRYPTO_WORKQUEUE=y
# CONFIG_CRYPTO_CRYPTD is not set
# CONFIG_CRYPTO_AUTHENC is not set

#
# Authenticated Encryption with Associated Data
#
# CONFIG_CRYPTO_CCM is not set
# CONFIG_CRYPTO_GCM is not set
# CONFIG_CRYPTO_SEQIV is not set

#
# Block modes
#
# CONFIG_CRYPTO_CBC is not set
# CONFIG_CRYPTO_CTR is not set
# CONFIG_CRYPTO_CTS is not set
CONFIG_CRYPTO_ECB=y
# CONFIG_CRYPTO_LRW is not set
# CONFIG_CRYPTO_PCBC is not set
# CONFIG_CRYPTO_XTS is not set

#
# Hash modes
#
# CONFIG_CRYPTO_HMAC is not set
# CONFIG_CRYPTO_XCBC is not set
# CONFIG_CRYPTO_VMAC is not set

#
# Digest
#
CONFIG_CRYPTO_CRC32C=y
# CONFIG_CRYPTO_CRC32 is not set
# CONFIG_CRYPTO_GHASH is not set
# CONFIG_CRYPTO_MD4 is not set
CONFIG_CRYPTO_MD5=y
CONFIG_CRYPTO_MICHAEL_MIC=y
# CONFIG_CRYPTO_RMD128 is not set
# CONFIG_CRYPTO_RMD160 is not set
# CONFIG_CRYPTO_RMD256 is not set
# CONFIG_CRYPTO_RMD320 is not set
CONFIG_CRYPTO_SHA1=y
# CONFIG_CRYPTO_SHA1_ARM is not set
CONFIG_CRYPTO_SHA256=y
# CONFIG_CRYPTO_SHA512 is not set
# CONFIG_CRYPTO_TGR192 is not set
# CONFIG_CRYPTO_WP512 is not set

#
# Ciphers
#
CONFIG_CRYPTO_AES=y
# CONFIG_CRYPTO_AES_ARM is not set
# CONFIG_CRYPTO_ANUBIS is not set
CONFIG_CRYPTO_ARC4=y
# CONFIG_CRYPTO_BLOWFISH is not set
# CONFIG_CRYPTO_CAMELLIA is not set
# CONFIG_CRYPTO_CAST5 is not set
# CONFIG_CRYPTO_CAST6 is not set
# CONFIG_CRYPTO_DES is not set
# CONFIG_CRYPTO_FCRYPT is not set
# CONFIG_CRYPTO_KHAZAD is not set
# CONFIG_CRYPTO_SALSA20 is not set
# CONFIG_CRYPTO_SEED is not set
# CONFIG_CRYPTO_SERPENT is not set
# CONFIG_CRYPTO_TEA is not set
# CONFIG_CRYPTO_TWOFISH is not set

#
# Compression
#
CONFIG_CRYPTO_DEFLATE=y
# CONFIG_CRYPTO_ZLIB is not set
CONFIG_CRYPTO_LZO=y

#
# Random Number Generation
#
# CONFIG_CRYPTO_ANSI_CPRNG is not set
# CONFIG_CRYPTO_USER_API_HASH is not set
# CONFIG_CRYPTO_USER_API_SKCIPHER is not set
# CONFIG_CRYPTO_HW is not set
# CONFIG_ASYMMETRIC_KEY_TYPE is not set
# CONFIG_BINARY_PRINTF is not set

#
# Library routines
#
CONFIG_BITREVERSE=y
CONFIG_GENERIC_STRNCPY_FROM_USER=y
CONFIG_GENERIC_STRNLEN_USER=y
CONFIG_GENERIC_PCI_IOMAP=y
CONFIG_GENERIC_IO=y
CONFIG_CRC_CCITT=y
CONFIG_CRC16=y
CONFIG_CRC_T10DIF=y
CONFIG_CRC_ITU_T=y
CONFIG_CRC32=y
# CONFIG_CRC32_SELFTEST is not set
CONFIG_CRC32_SLICEBY8=y
# CONFIG_CRC32_SLICEBY4 is not set
# CONFIG_CRC32_SARWATE is not set
# CONFIG_CRC32_BIT is not set
CONFIG_CRC7=y
CONFIG_LIBCRC32C=y
# CONFIG_CRC8 is not set
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
CONFIG_LZO_COMPRESS=y
CONFIG_LZO_DECOMPRESS=y
# CONFIG_XZ_DEC is not set
# CONFIG_XZ_DEC_BCJ is not set
CONFIG_DECOMPRESS_GZIP=y
CONFIG_BCH=y
CONFIG_BCH_CONST_PARAMS=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_DMA=y
CONFIG_DQL=y
CONFIG_NLATTR=y
CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE=y
CONFIG_AVERAGE=y
# CONFIG_CORDIC is not set
# CONFIG_DDR is not set
# CONFIG_VIRTUALIZATION is not set


From tony at atomide.com  Tue Apr 23 14:17:54 2013
From: tony at atomide.com (Tony Lindgren)
Date: Tue, 23 Apr 2013 11:17:54 -0700
Subject: Query on pinctrl usage for DT nodes
In-Reply-To: <51763B7B.707@ti.com>
References: <CA+V-a8uiPwsAD--OHFAE=i2ed+-wbXm4p2deZXr92+Zv6GDS1w@mail.gmail.com>
 <515C5C76.3080009@wwwdotorg.org>
 <CA+V-a8t3wtP77DdeUoQHKMjAuWmV+ude+1J3UjJmMTqobgStjA@mail.gmail.com>
 <5162FD4A.1030909@wwwdotorg.org>
 <CA+V-a8vwdCkyMqiynj5BodXbjwJ=e4qNb-29FhLweqbjc7DBQA@mail.gmail.com>
 <5165A22B.4070200@wwwdotorg.org>
 <20130410203408.GP10155@atomide.com> <516BB99F.2080502@ti.com>
 <20130416213232.GU10155@atomide.com> <51763B7B.707@ti.com>
Message-ID: <20130423181753.GK10155@atomide.com>

* Peter Ujfalusi <peter.ujfalusi at ti.com> [130423 00:47]:
> On 04/16/2013 11:32 PM, Tony Lindgren wrote:
> > * Peter Ujfalusi <peter.ujfalusi at ti.com> [130415 01:30]:
> >> On 04/10/2013 10:34 PM, Tony Lindgren wrote:
> >>> Yeah how about just change the pintctrl-single,bits register
> >>> naming to be register + bit?  Something like 0xdeadbeef.0 and
> >>> 0xdeadbeef.1 and so on.
> >>
> >> Something like this might work I think. It is going to be a bit tricky IMHO
> >> since we might need span out new 'register' every time a device requests for a
> >> new pinctrl-single,bits for already used register in the
> >> pinctrl-single,bit-per-mux area. In this way we still can make sure that
> >> certain bit are only used by a single driver.
> > 
> > OK. If it's one bit per mux type register we should be able to create
> > the right amount of entries based on the submask in pinctrs-single,bit?
> 
> Right now it seams to be true that we have one bit per mux (in DEVCONF0 on
> OMAP3 for example). So that would work fine, but There could be different
> registers around with more than one bit per mux.

Yes you are right, we should cover that case too. But maybe we
can wait until we have such an example :)
 
> Another way to deal with this is to:
> in case of pinctrl-single,bit-per-mux we assume one bit per mux and create
> entries based on the pinctrl-single,function-mask's bits.
> 
> In case we have more than one bit for the mux in the register we could have
> optional property stating the number of different muxes handled by the register.

Yes that's doable.
 
> One bit per mux type:
> 
> control_devconf0: pinmux at 48002274 {
>         compatible = "pinctrl-single";
>         reg = <0x48002274 4>;   /* Single register */
>         #address-cells = <1>;
>         #size-cells = <0>;
>         pinctrl-single,bit-per-mux;
>         pinctrl-single,register-width = <32>;
>         pinctrl-single,function-mask = <0x5F>;
> };
> 
> Results six entries.

Yup, I think this is the way to go for now, see below..
 
> control_devconf0: pinmux at 48002274 {
>         compatible = "pinctrl-single";
>         reg = <0x48002274 4>;   /* Single register */
>         #address-cells = <1>;
>         #size-cells = <0>;
>         pinctrl-single,bit-per-mux;
>         pinctrl-single,functions-in-register = <3>;
>         pinctrl-single,register-width = <32>;
>         pinctrl-single,function-mask = <0x5F>;
> };
> 
> Will results three entries.

..but let's not add this. The reason why I'd like to postpone adding
pinctrl-single,functions-in-register is because we may be able to
do it automatically.

If it was just the naming is the issue, we could use the submask
for the naming the bits with something like 0x0x48002274-3-1 and
0x0x48002274-1-1.

But I think currently the pinctrl framework expects a static pin
table, so we can't create these entries dynamically when the
consumer driver starts using the bits. So the right fix there
would be to improve the pinctrl framework to allow adding pins
dynamically, see some of the REVISIT comments in pinctrl-single.c.

> In both cases we still need to test overlaps in the handled bits.

Yes that's missing too.

So how about we do the following for now:

1. Fix the pinctrl-single,bits naming to use 0x0x48002274-1-1 to
   represent the bit range

2. Automatically create entries for each bit and don't yet support
   bit ranges except in the naming for future use

3. Add something to check the overlaps in the submasks

4. Assume we have one-bit-per-mux until we have a real example,
   then improve the pinctrl framework to allow adding pins 
   dynamically as the consumer driver probes. Or if there are
   other issues, add the pinctrl-single,functions-in-register
   property at that point.

Regards,

Tony


From broonie at kernel.org  Tue Apr 23 14:25:29 2013
From: broonie at kernel.org (Mark Brown)
Date: Tue, 23 Apr 2013 19:25:29 +0100
Subject: [PATCH 08/21] ASoC: ux500: forward declare msp_i2s_platform_data
In-Reply-To: <1366734653-488286-9-git-send-email-arnd@arndb.de>
References: <1366734653-488286-1-git-send-email-arnd@arndb.de>
 <1366734653-488286-9-git-send-email-arnd@arndb.de>
Message-ID: <20130423182528.GT5019@opensource.wolfsonmicro.com>

On Tue, Apr 23, 2013 at 06:30:40PM +0200, Arnd Bergmann wrote:
> We get a lot of build warnings from the msp driver like:

Applied, thanks.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130423/5fb32573/attachment.sig>

From broonie at kernel.org  Tue Apr 23 14:27:24 2013
From: broonie at kernel.org (Mark Brown)
Date: Tue, 23 Apr 2013 19:27:24 +0100
Subject: [PATCH 09/21] spi/sirf: fix MODULE_DEVICE_TABLE
In-Reply-To: <1366734653-488286-10-git-send-email-arnd@arndb.de>
References: <1366734653-488286-1-git-send-email-arnd@arndb.de>
 <1366734653-488286-10-git-send-email-arnd@arndb.de>
Message-ID: <20130423182724.GU5019@opensource.wolfsonmicro.com>

On Tue, Apr 23, 2013 at 06:30:41PM +0200, Arnd Bergmann wrote:
> This fixes building the spi-sirf driver as a loadable module, which uses
> an incorrect MODULE_DEVICE_TABLE, by changing the reference to the
> correct symbol.

Applied, thanks.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130423/372e6fbb/attachment.sig>

From broonie at kernel.org  Tue Apr 23 14:30:25 2013
From: broonie at kernel.org (Mark Brown)
Date: Tue, 23 Apr 2013 19:30:25 +0100
Subject: [PATCH v8 1/8] spi/spi-atmel: add physical base address
In-Reply-To: <1364968662-23763-1-git-send-email-wenyou.yang@atmel.com>
References: <1364968581-23700-1-git-send-email-wenyou.yang@atmel.com>
 <1364968662-23763-1-git-send-email-wenyou.yang@atmel.com>
Message-ID: <20130423183025.GV5019@opensource.wolfsonmicro.com>

On Wed, Apr 03, 2013 at 01:57:42PM +0800, Wenyou Yang wrote:
> From: Nicolas Ferre <nicolas.ferre at atmel.com>
> 
> Needed for future use with dmaengine enabled driver.

Applied, thanks.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130423/97820491/attachment.sig>

From broonie at kernel.org  Tue Apr 23 14:30:42 2013
From: broonie at kernel.org (Mark Brown)
Date: Tue, 23 Apr 2013 19:30:42 +0100
Subject: [PATCH v8 2/8] spi/spi-atmel: add flag to controller data for
 lock operations
In-Reply-To: <1364968716-23848-1-git-send-email-wenyou.yang@atmel.com>
References: <1364968581-23700-1-git-send-email-wenyou.yang@atmel.com>
 <1364968716-23848-1-git-send-email-wenyou.yang@atmel.com>
Message-ID: <20130423183042.GW5019@opensource.wolfsonmicro.com>

On Wed, Apr 03, 2013 at 01:58:36PM +0800, Wenyou Yang wrote:
> From: Nicolas Ferre <nicolas.ferre at atmel.com>
> 
> Will allow to drop the lock during DMA operations.

Applied, thanks.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130423/2ac58be6/attachment.sig>

From broonie at kernel.org  Tue Apr 23 14:33:01 2013
From: broonie at kernel.org (Mark Brown)
Date: Tue, 23 Apr 2013 19:33:01 +0100
Subject: [PATCH v8 3/8] spi/spi-atmel: add dmaengine support
In-Reply-To: <20130403102332.GA4633@lnx-rg>
References: <1364968581-23700-1-git-send-email-wenyou.yang@atmel.com>
 <1364968759-24036-1-git-send-email-wenyou.yang@atmel.com>
 <20130403102332.GA4633@lnx-rg>
Message-ID: <20130423183301.GX5019@opensource.wolfsonmicro.com>

On Wed, Apr 03, 2013 at 12:23:35PM +0200, Richard GENOUD wrote:

Richard, delete irrelevant context from your mails - it makes it much
easier to find the content you added.

> On [mer., 03.04.2013 13:59:19], Wenyou Yang wrote:

> As I did some work on that one:
> Signed-off-by: Richard Genoud <richard.genoud at gmail.com>
> 
> BUT, there's one thing not working (at least for me !):
> With DMA enabled, using spidev.
> if we use the ioctl SPI_IOC_MESSAGE(x) (tested with x=3):

I'd been expecting an updated series with this rolled in?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130423/86a7f8bb/attachment.sig>

From khilman at linaro.org  Tue Apr 23 14:47:06 2013
From: khilman at linaro.org (Kevin Hilman)
Date: Tue, 23 Apr 2013 11:47:06 -0700
Subject: [GIT PULL] OMAP PM cleanups for v3.10
In-Reply-To: <20130423175934.GA6728@quad.lixom.net> (Olof Johansson's message
 of "Tue, 23 Apr 2013 10:59:34 -0700")
References: <87ehej1ena.fsf@linaro.org> <20130410181452.GG10155@atomide.com>
 <20130423175934.GA6728@quad.lixom.net>
Message-ID: <8761zd6q51.fsf@linaro.org>

Olof Johansson <olof at lixom.net> writes:

> On Wed, Apr 10, 2013 at 11:14:52AM -0700, Tony Lindgren wrote:
>> Hi,
>> 
>> Added Olof to cc, I suggest Olof pull this directly as we're starting
>> to run out of time.
>
> Hi,
>
> I'm terribly sorry for dropping this one on the floor, in spite of repeated
> pings from Tony. :(

Your sins will be absolved by the beer you hand me at the next
conference. ;)

> If it wasn't for the fact that we're pushing back on some of the other
> late submissions I'd be open to taking this, but to be fair it makes
> more sense to merge it right after -rc1. The changes don't look like
> they're truly critical for 3.10, and you should still be able to use
> this as a base for your 3.11 changes, so hopefully this doesn't cause
> too much trouble.

Yeah, this is mostly cleanup in preparation for OMAP5, so not extrememly
urgent.

> So, please resend right after the merge window closes.

OK, will do.

Kevin


From arnd at arndb.de  Tue Apr 23 14:55:32 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 23 Apr 2013 20:55:32 +0200
Subject: [PATCH 12/21] mmc: sdhci-tegra: fix MODULE_DEVICE_TABLE
In-Reply-To: <87bo95tctk.fsf@octavius.laptop.org>
References: <1366734653-488286-1-git-send-email-arnd@arndb.de>
 <1366734653-488286-13-git-send-email-arnd@arndb.de>
 <87bo95tctk.fsf@octavius.laptop.org>
Message-ID: <201304232055.32715.arnd@arndb.de>

The symbol referenced in MODULE_DEVICE_TABLE must match the actual
table, otherwise we get a build error like

sdhci-tegra.c:206:34: error: '__mod_of_device_table' aliased to undefined symbol 'sdhci_dt_ids'

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Cc: Stephen Warren <swarren at nvidia.com>
Cc: Chris Ball <cjb at laptop.org>
---
On Tuesday 23 April 2013, Chris Ball wrote:

> I was going to take this, but it doesn't apply to mmc-next or
> linux-next, because the #endif in your first line of context isn't
> present in those trees -- which tree is this based on?

I based it on 3.9-rc8.

> Sounds like it might make more sense for you to take this; if so:
> Acked-by: Chris Ball <cjb at laptop.org>

This is the rebased version on linux-next. I think it's better if you
take it, otherwise we just create a merge conflict for Linus.

diff --git a/drivers/mmc/host/sdhci-tegra.c b/drivers/mmc/host/sdhci-tegra.c
index 45048d1..e0dba74 100644
--- a/drivers/mmc/host/sdhci-tegra.c
+++ b/drivers/mmc/host/sdhci-tegra.c
@@ -203,7 +203,7 @@ static const struct of_device_id sdhci_tegra_dt_match[] = {
 	{ .compatible = "nvidia,tegra20-sdhci", .data = &soc_data_tegra20 },
 	{}
 };
-MODULE_DEVICE_TABLE(of, sdhci_dt_ids);
+MODULE_DEVICE_TABLE(of, sdhci_tegra_dt_match);
 
 static void sdhci_tegra_parse_dt(struct device *dev)
 {


From arnd at arndb.de  Tue Apr 23 14:57:36 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 23 Apr 2013 20:57:36 +0200
Subject: [PATCH 07/21] ARM: tegra: unify tegra_idle_device definitions
In-Reply-To: <5176BD29.1000405@linaro.org>
References: <1366734653-488286-1-git-send-email-arnd@arndb.de>
 <1366734653-488286-8-git-send-email-arnd@arndb.de>
 <5176BD29.1000405@linaro.org>
Message-ID: <201304232057.37055.arnd@arndb.de>

On Tuesday 23 April 2013, Daniel Lezcano wrote:
> the patch sounds good but I think the side effect of the consolidation
> patchset [1] fixed that.
> 
> You can find these fixes in Rafael's tree:
> 
> https://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/commit/?h=linux-next&amp;id=4c637b2175a0dc65d533494225525c6c82d73293
> 
> https://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/commit/?h=linux-next&amp;id=e158f9da6974cc11bfab2246a9b10021af0e0d8a
> 
> https://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/commit/?h=linux-next&amp;id=c5106c9dea9a6022ab84c6cb1d4a0b19fc5af0e2
> 
> https://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/commit/?h=linux-next&amp;id=f040c26ffaa5e56f2bca427c719c9601a02e70e5
> 
> [1] http://www.spinics.net/lists/arm-kernel/msg239811.html
> 

Ah. Is that not in linux-next? I created the patch today based on the latest
linux-next from today (Tuesday).

	Arnd


From arnd at arndb.de  Tue Apr 23 15:02:20 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 23 Apr 2013 21:02:20 +0200
Subject: [PATCH 18/21] usb: phy: tegra: don't call into tegra-ehci directly
In-Reply-To: <Pine.LNX.4.44L0.1304231239220.1679-100000@iolanthe.rowland.org>
References: <Pine.LNX.4.44L0.1304231239220.1679-100000@iolanthe.rowland.org>
Message-ID: <201304232102.20573.arnd@arndb.de>

On Tuesday 23 April 2013, Alan Stern wrote:
> On Tue, 23 Apr 2013, Arnd Bergmann wrote:

> > @@ -733,7 +731,9 @@ static int tegra_ehci_probe(struct platform_device *pdev)
> >  
> >  	tegra->phy = tegra_usb_phy_open(&pdev->dev, instance, hcd->regs,
> >  					pdata->phy_config,
> > -					TEGRA_USB_PHY_MODE_HOST);
> > +					TEGRA_USB_PHY_MODE_HOST,
> > +					&tegra_ehci_set_pts,
> > +					tegra_ehci_set_phcd);
> 
> Does the compiler warn about the unnecessary '&'? 

No, AFAIK, both variants are equally acceptable C.

> In any case, it
> looks strange to have one function pointer with an '&' and another
> without.

Yes, that was certainly not intentional. I've removed the '&' now.

> Aside from that minor detail, the ehci-tegra.c changes are fine.

Ok, thanks for the feedback.

	Arnd


From arnd at arndb.de  Tue Apr 23 15:05:40 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 23 Apr 2013 21:05:40 +0200
Subject: [PATCH v2] usb: phy: tegra: don't call into tegra-ehci directly
In-Reply-To: <20130423171701.GA31397@kroah.com>
References: <1366734653-488286-1-git-send-email-arnd@arndb.de>
 <1366734653-488286-19-git-send-email-arnd@arndb.de>
 <20130423171701.GA31397@kroah.com>
Message-ID: <201304232105.40254.arnd@arndb.de>

Both phy-tegra-usb.c and ehci-tegra.c export symbols used by the other one,
which does not work if one of them or both are loadable modules, resulting
in an error like:

drivers/built-in.o: In function `utmi_phy_clk_disable':
drivers/usb/phy/phy-tegra-usb.c:302: undefined reference to `tegra_ehci_set_phcd'
drivers/built-in.o: In function `utmi_phy_clk_enable':
drivers/usb/phy/phy-tegra-usb.c:324: undefined reference to `tegra_ehci_set_phcd'
drivers/built-in.o: In function `utmi_phy_power_on':
drivers/usb/phy/phy-tegra-usb.c:447: undefined reference to `tegra_ehci_set_pts'

This turns the interface into a one-way dependency by letting the tegra ehci
driver pass two function pointers for callbacks that need to be called by
the phy driver.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Cc: Venu Byravarasu <vbyravarasu at nvidia.com>
Cc: Alan Stern <stern at rowland.harvard.edu>
Cc: Felipe Balbi <balbi at ti.com>
Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
Cc: Stephen Warren <swarren at nvidia.com>
Cc: linux-usb at vger.kernel.org

---
On Tuesday 23 April 2013, Greg Kroah-Hartman wrote:

> >  drivers/usb/host/ehci-tegra.c     | 10 +++++-----
> >  drivers/usb/phy/tegra_usb_phy.c   | 13 +++++++++----
> >  include/linux/usb/tegra_usb_phy.h | 10 +++++-----
> >  3 files changed, 19 insertions(+), 14 deletions(-)
> 
> Not all of these files are in my usb-next tree, so I can't take this
> patch, sorry.

Right. I created the patch again linux-next but then rebased the series
to 3.9-rc8 for submission. I had not realized that the files got renamed
between the trees.

	Arnd

 drivers/usb/host/ehci-tegra.c     | 10 +++++-----
 drivers/usb/phy/phy-tegra-usb.c   | 13 +++++++++----
 include/linux/usb/tegra_usb_phy.h | 10 +++++-----
 3 files changed, 19 insertions(+), 14 deletions(-)

diff --git a/drivers/usb/host/ehci-tegra.c b/drivers/usb/host/ehci-tegra.c
index ed201ae..e3eddc3 100644
--- a/drivers/usb/host/ehci-tegra.c
+++ b/drivers/usb/host/ehci-tegra.c
@@ -611,7 +611,7 @@ static const struct dev_pm_ops tegra_ehci_pm_ops = {
 /* Bits of PORTSC1, which will get cleared by writing 1 into them */
 #define TEGRA_PORTSC1_RWC_BITS (PORT_CSC | PORT_PEC | PORT_OCC)
 
-void tegra_ehci_set_pts(struct usb_phy *x, u8 pts_val)
+static void tegra_ehci_set_pts(struct usb_phy *x, u8 pts_val)
 {
 	unsigned long val;
 	struct usb_hcd *hcd = bus_to_hcd(x->otg->host);
@@ -622,9 +622,8 @@ void tegra_ehci_set_pts(struct usb_phy *x, u8 pts_val)
 	val |= TEGRA_USB_PORTSC1_PTS(pts_val & 3);
 	writel(val, base + TEGRA_USB_PORTSC1);
 }
-EXPORT_SYMBOL_GPL(tegra_ehci_set_pts);
 
-void tegra_ehci_set_phcd(struct usb_phy *x, bool enable)
+static void tegra_ehci_set_phcd(struct usb_phy *x, bool enable)
 {
 	unsigned long val;
 	struct usb_hcd *hcd = bus_to_hcd(x->otg->host);
@@ -637,7 +636,6 @@ void tegra_ehci_set_phcd(struct usb_phy *x, bool enable)
 		val &= ~TEGRA_USB_PORTSC1_PHCD;
 	writel(val, base + TEGRA_USB_PORTSC1);
 }
-EXPORT_SYMBOL_GPL(tegra_ehci_set_phcd);
 
 static u64 tegra_ehci_dma_mask = DMA_BIT_MASK(32);
 
@@ -738,7 +736,9 @@ static int tegra_ehci_probe(struct platform_device *pdev)
 
 	tegra->phy = tegra_usb_phy_open(&pdev->dev, instance, hcd->regs,
 					pdata->phy_config,
-					TEGRA_USB_PHY_MODE_HOST);
+					TEGRA_USB_PHY_MODE_HOST,
+					tegra_ehci_set_pts,
+					tegra_ehci_set_phcd);
 	if (IS_ERR(tegra->phy)) {
 		dev_err(&pdev->dev, "Failed to open USB phy\n");
 		err = -ENXIO;
diff --git a/drivers/usb/phy/phy-tegra-usb.c b/drivers/usb/phy/phy-tegra-usb.c
index 5487d38..17d8112 100644
--- a/drivers/usb/phy/phy-tegra-usb.c
+++ b/drivers/usb/phy/phy-tegra-usb.c
@@ -299,7 +299,7 @@ static void utmi_phy_clk_disable(struct tegra_usb_phy *phy)
 		val &= ~USB_SUSP_SET;
 		writel(val, base + USB_SUSP_CTRL);
 	} else
-		tegra_ehci_set_phcd(&phy->u_phy, true);
+		phy->set_phcd(&phy->u_phy, true);
 
 	if (utmi_wait_register(base + USB_SUSP_CTRL, USB_PHY_CLK_VALID, 0) < 0)
 		pr_err("%s: timeout waiting for phy to stabilize\n", __func__);
@@ -321,7 +321,7 @@ static void utmi_phy_clk_enable(struct tegra_usb_phy *phy)
 		val &= ~USB_SUSP_CLR;
 		writel(val, base + USB_SUSP_CTRL);
 	} else
-		tegra_ehci_set_phcd(&phy->u_phy, false);
+		phy->set_phcd(&phy->u_phy, false);
 
 	if (utmi_wait_register(base + USB_SUSP_CTRL, USB_PHY_CLK_VALID,
 						     USB_PHY_CLK_VALID))
@@ -444,7 +444,7 @@ static int utmi_phy_power_on(struct tegra_usb_phy *phy)
 	utmi_phy_clk_enable(phy);
 
 	if (!phy->is_legacy_phy)
-		tegra_ehci_set_pts(&phy->u_phy, 0);
+		phy->set_pts(&phy->u_phy, 0);
 
 	return 0;
 }
@@ -688,7 +688,10 @@ static int	tegra_usb_phy_suspend(struct usb_phy *x, int suspend)
 }
 
 struct tegra_usb_phy *tegra_usb_phy_open(struct device *dev, int instance,
-	void __iomem *regs, void *config, enum tegra_usb_phy_mode phy_mode)
+	void __iomem *regs, void *config, enum tegra_usb_phy_mode phy_mode,
+	void (*set_pts)(struct usb_phy *x, u8 pts_val),
+	void (*set_phcd)(struct usb_phy *x, bool enable))
+
 {
 	struct tegra_usb_phy *phy;
 	unsigned long parent_rate;
@@ -707,6 +710,8 @@ struct tegra_usb_phy *tegra_usb_phy_open(struct device *dev, int instance,
 	phy->dev = dev;
 	phy->is_legacy_phy =
 		of_property_read_bool(np, "nvidia,has-legacy-mode");
+	phy->set_pts = set_pts;
+	phy->set_phcd = set_phcd;
 	err = of_property_match_string(np, "phy_type", "ulpi");
 	if (err < 0)
 		phy->is_ulpi_phy = false;
diff --git a/include/linux/usb/tegra_usb_phy.h b/include/linux/usb/tegra_usb_phy.h
index 9ebebe9..1b7519a 100644
--- a/include/linux/usb/tegra_usb_phy.h
+++ b/include/linux/usb/tegra_usb_phy.h
@@ -61,10 +61,14 @@ struct tegra_usb_phy {
 	struct device *dev;
 	bool is_legacy_phy;
 	bool is_ulpi_phy;
+	void (*set_pts)(struct usb_phy *x, u8 pts_val);
+	void (*set_phcd)(struct usb_phy *x, bool enable);
 };
 
 struct tegra_usb_phy *tegra_usb_phy_open(struct device *dev, int instance,
-	void __iomem *regs, void *config, enum tegra_usb_phy_mode phy_mode);
+	void __iomem *regs, void *config, enum tegra_usb_phy_mode phy_mode,
+	void (*set_pts)(struct usb_phy *x, u8 pts_val),
+	void (*set_phcd)(struct usb_phy *x, bool enable));
 
 void tegra_usb_phy_preresume(struct usb_phy *phy);
 
@@ -75,8 +79,4 @@ void tegra_ehci_phy_restore_start(struct usb_phy *phy,
 
 void tegra_ehci_phy_restore_end(struct usb_phy *phy);
 
-void tegra_ehci_set_pts(struct usb_phy *x, u8 pts_val);
-
-void tegra_ehci_set_phcd(struct usb_phy *x, bool enable);
-
 #endif /* __TEGRA_USB_PHY_H */


From arnd at arndb.de  Tue Apr 23 15:07:21 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 23 Apr 2013 21:07:21 +0200
Subject: [PATCH v2] usb: phy: don't mark usb_bind_phy as __init
In-Reply-To: <20130423171734.GA31432@kroah.com>
References: <1366734653-488286-1-git-send-email-arnd@arndb.de>
 <1366734653-488286-20-git-send-email-arnd@arndb.de>
 <20130423171734.GA31432@kroah.com>
Message-ID: <201304232107.22084.arnd@arndb.de>

It makes no sense for a symbol to be both exported and marked __init,
because any users in modules would be calling this function after
it gets discarded. Further, this patch revolves a section mismatch
warning from usbhs_init_phys(), which is intentionally not marked
__init:

WARNING: vmlinux.o(.text+0x413f8): Section mismatch in reference from
the function usbhs_init_phys() to the function .init.text:usb_bind_phy()

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Cc: Alan Stern <stern at rowland.harvard.edu>
Cc: Felipe Balbi <balbi at ti.com>
Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
Cc: linux-usb at vger.kernel.org
---

v2: rebased on linux-next

diff --git a/drivers/usb/phy/phy.c b/drivers/usb/phy/phy.c
index f52c006..a9984c7 100644
--- a/drivers/usb/phy/phy.c
+++ b/drivers/usb/phy/phy.c
@@ -413,7 +413,7 @@ EXPORT_SYMBOL_GPL(usb_remove_phy);
  *
  * To be used by platform specific initialization code.
  */
-int __init usb_bind_phy(const char *dev_name, u8 index,
+int usb_bind_phy(const char *dev_name, u8 index,
 				const char *phy_dev_name)
 {
 	struct usb_phy_bind *phy_bind;


From cjb at laptop.org  Tue Apr 23 15:07:35 2013
From: cjb at laptop.org (Chris Ball)
Date: Tue, 23 Apr 2013 15:07:35 -0400
Subject: [PATCH 12/21] mmc: sdhci-tegra: fix MODULE_DEVICE_TABLE
In-Reply-To: <201304232055.32715.arnd@arndb.de> (Arnd Bergmann's message of
 "Tue, 23 Apr 2013 20:55:32 +0200")
References: <1366734653-488286-1-git-send-email-arnd@arndb.de>
 <1366734653-488286-13-git-send-email-arnd@arndb.de>
 <87bo95tctk.fsf@octavius.laptop.org>
 <201304232055.32715.arnd@arndb.de>
Message-ID: <8738uht6a0.fsf@octavius.laptop.org>

Hi,

On Tue, Apr 23 2013, Arnd Bergmann wrote:
>> I was going to take this, but it doesn't apply to mmc-next or
>> linux-next, because the #endif in your first line of context isn't
>> present in those trees -- which tree is this based on?
>
> I based it on 3.9-rc8.

Thanks, I should have thought of that; applied to mmc-next for 3.10.

- Chris.
-- 
Chris Ball   <cjb at laptop.org>   <http://printf.net/>
One Laptop Per Child


From s-anna at ti.com  Tue Apr 23 15:20:07 2013
From: s-anna at ti.com (Anna, Suman)
Date: Tue, 23 Apr 2013 19:20:07 +0000
Subject: [PATCHv3 00/14] drivers: mailbox: framework creation
In-Reply-To: <CABb+yY1x4x_A+QtGG9ohsLPgs8c3nEVnd_ExJBGOOR8=6YLPFA@mail.gmail.com>
References: <1363145021-14339-1-git-send-email-s-anna@ti.com>
 <CABb+yY0RYkVeo2Sb4WsDJY0jf17488FEz0d2CB994eQaSOEsVg@mail.gmail.com>
 <37C860A02101E749A747FA2D3C1E3C504A5DF7@DLEE11.ent.ti.com>
 <CABb+yY1x4x_A+QtGG9ohsLPgs8c3nEVnd_ExJBGOOR8=6YLPFA@mail.gmail.com>
Message-ID: <37C860A02101E749A747FA2D3C1E3C504A63B4@DLEE11.ent.ti.com>

Hi Jassi,

> 
> On Mon, Apr 22, 2013 at 9:26 PM, Anna, Suman <s-anna at ti.com> wrote:
> >>
> >> a) No documentation. Usually the header would have proper
> >> documentation of data structures and info for users of both side of the api.
> >
> > I will fix the documentation portion for 3.10. I will also add a TODO as part of the
> documentation so that it highlights the gaps and work-items.
> >
> >>
> >> b) The api is not scalable. The assumption of just one IPC controller
> >> in the platform is hardcoded.
> >
> > Yes, this is a major concern and I will be handling this in the upcoming patches .
> The current code was primarily based on moving the OMAP mailbox code and
> expanding it to support the ST DBX500 mailbox. As it is today, it doesn't scale to
> support multiple IP instances/controllers.
> >
> >>
> >> c) There seems to be no consistent design - mailbox_ops has 12 callback
> hooks.
> >> Some, save_ctx, restore_ctx, enable_irq, disable_irq are exported for
> >> no apparent reason (legacy of a legacy - OMAP), while other hooks are
> >> kept private to the api.
> >> I believe OMAP had valid reasons to make IPC clients save/restore
> >> context of the IPC controller, but I don't think that is the case in
> >> general. I2C client drivers don't save/restore context of I2C
> >> controller's, why should IPC's?  Similarly enable/disable_irq of the controller
> seem too intrusive for a client driver.
> >
> > Yep, these are exported because of the OMAP legacy TIDSPBRIDGE stack, and
> should vanish with the addition of runtime_pm support.
> >
> >>
> >> mailbox_ops.mailbox_type_t makes no sense to me. At least not without
> >> documentation, though I doubt any amount of documentation could help
> >> it - mailbox.c doesn't even read the member. Btw, isn't every mailbox
> >> a MBOX_SHARED_MEM_TYPE? A part of data passed via FIFO/REG could
> >> point to location in shared memory that might have full
> >> command/payload for the message. Or did I get the meaning of
> >> MBOX_SHARED_MEM_TYPE wrong in the absence of documentation?
> >
> > Yes, this needs to be removed, it is a carry-over from the OMAP mailbox code.
> >
> >>
> >> The api seems to worry too much about the low-level details of the
> >> IPC controller (save/restore context, enable/disable_irq and
> >> ack_irq), while it fails to provide a tight well-defined interface to client drivers.
> >>
> >> There are also some code issues, which might come as replies to
> >> respective patches.
> >
> > Thanks for the review of the patches. I will await your comments, and will
> address them as incremental patches.
> >
> So we agree
> a) Documentation is missing.
> b) mailbox_type_t, save_ctx, restore_ctx, ack_irq, enable_irq, disable_irq need
> to be removed.

The mailbox_type_t can be removed right away, but for others, we should give some time for current users to migrate before we remove it completely. 

> c) Support for more than one IPC controllers is needed.
> 
> Out of 11 exported functions, we'll be left with the 5 trivial ones
> mailbox_un/register, mailbox_get/put and mailbox_msg_send.
> mailbox_msg_send_no_irq and mailbox_msg_send_receive_no_irq are STE(?)
> specific quirky requirements, which should be possible to simulate over the
> mailbox API if designed well.

Loic can comment on the existing xxx_no_irq API. The pl320_transmit is somewhat similar to mailbox_msg_send_receive_no_irq, without the irq part.

> 
> Documentation wise, we'd need documentation for what we finally wanna have,
> not the current implementation.
> 
> There are also some desired features in a good API:-
> 
> a) The API should be simple and efficient, i.e, submission of requests by clients
> and notifications of data received by the API should be possible from atomic
> context - most of the IPC is going to be about exchanging 'commands'. The API
> shouldn't add to the latencies.

I think we will have need for both types. It really depends on the purpose of the IPC h/w - some would be simple messaging and may not need the atomic constraints. Sure enough, atomic context is the stricter one, so we can add that. I don't see any users of it currently though.

> 
> b) It would be very useful to allow submission of a new request from the
> completion callback of last one.
> 
> c) The request/free/ack_irq on behalf of the IPC controller driver should be no
> business of the API. The API design should only assume a simple but generic
> enough h/w model beneath it and provide support to h/w that doesn't have an
> expected feature.
>  For example, API should assume the IPC controller can detect and report when
> the remote asserts Ready-To-Receive (RTR). This is when the API callbacks
> .tx_done(mssg) on the client. If some h/w doesn't have RTR assertion interrupt,
> the API should provide optional feature to poll the controller periodically.

Some of these are already part of the mailbox ops. FWIW, I don?t see a need for a .tx_done callback, as this state can really be maintained by the driver implementation itself. The mailbox_msg_send can return an error appropriately based on whether the h/w is ready or not. The current code has the support for queuing up a certain number of messages in case the h/w is busy, but I am planning to change this to a device-based property so that they can choose if it needs that support or not.

> 
> (d) The 'struct mailbox_msg' should be just an opaque void* - the client/protocol
> driver typecasts to void* the IPC controller specific message structure. API
> shouldn't aim the impossible of providing a generic message format.

The size parameter would still be needed. Depending on the h/w, it can be just an u32 or a series of bytes, and even in the latter case, it is not guaranteed that all messages transmitted will occupy the entire h/w shared memory data packet. I can see the current header field getting absorbed into the opaque void * structure for the ST mailbox driver. The size and ptr together provide a very generic message format.

> 
> (a) and (b) are already proved to be useful and supported by a similar API -
> DMAEngine.
> 
> As you see there would be not much of the present left eventually. So I wonder
> if should sculpt a new api out of TI's or start from scratch?
> One of my controllers is similar to 'pl320' (which you left out converting to the
> API). I am in process of implementing all this assuming it is OK to keep a controller
> out of this API :)  So maybe we can collaborate on a new implementation from
> scratch.

This series missed the 3.9 merge window, and is currently slated for getting merged into 3.10. The PL320 made it into 3.9 itself (I wasn't aware of it until I saw it in mainline) and created the drivers/mailbox folder.  I would think it would be relatively straight-forward to adopt it to the mailbox API, as it has only 3 API. We should be doing incremental changes on top of this series, as most of the base API would still be the same. The current series is helping out with couple of efforts, the breaking up of the PRCMU code and on the multiplatform support for OMAP with mailbox enabled. We can definitely collaborate on the improvements. Andy Green would also be interested, as he is also looking into adopting the mailbox API.

Regards
Suman

From marvin24 at gmx.de  Tue Apr 23 15:21:06 2013
From: marvin24 at gmx.de (Marc Dietrich)
Date: Tue, 23 Apr 2013 21:21:06 +0200
Subject: [PATCH 14/21] staging: nvec: allow modular build
In-Reply-To: <1366734653-488286-15-git-send-email-arnd@arndb.de>
References: <1366734653-488286-1-git-send-email-arnd@arndb.de>
 <1366734653-488286-15-git-send-email-arnd@arndb.de>
Message-ID: <4082180.JXNz6TsAKc@ax5200p>

Arnd,

On Tuesday 23 April 2013 18:30:46 Arnd Bergmann wrote:
> The serio code can be a loadable module, which in turn means that nvec
> also has to be a module, so mark it as "tristate" in Kconfig.

oh, I didn't saw this randconfig error posting. NVEC isn't prepared for 
modularized builds yet (it's on the TODO list though). So better say SERIO=y 
here. Looking a bit closer, there is other stuff which can also be a module 
(GPIOLIB, I2C, ...) so these also need a =y.

Should a post a patch?

Marc
 
> drivers/built-in.o: In function `nvec_mouse_remove':
> drivers/staging/nvec/nvec_ps2.c:136: undefined reference to
> `serio_unregister_port' drivers/built-in.o: In function `nvec_mouse_probe':
> drivers/staging/nvec/nvec_ps2.c:126: undefined reference to
> `__serio_register_port' drivers/built-in.o: In function
> `nvec_ps2_notifier':
> drivers/staging/nvec/nvec_ps2.c:84: undefined reference to `serio_interrupt'
> drivers/staging/nvec/nvec_ps2.c:91: undefined reference to
> `serio_interrupt'
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Cc: Marc Dietrich <marvin24 at gmx.de>
> Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
> ---
>  drivers/staging/nvec/Kconfig | 10 +++++-----
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/staging/nvec/Kconfig b/drivers/staging/nvec/Kconfig
> index f779fdc..7e61ada 100644
> --- a/drivers/staging/nvec/Kconfig
> +++ b/drivers/staging/nvec/Kconfig
> @@ -1,5 +1,5 @@
>  config MFD_NVEC
> -	bool "NV Tegra Embedded Controller SMBus Interface"
> +	tristate "NV Tegra Embedded Controller SMBus Interface"
>  	depends on I2C && GPIOLIB && ARCH_TEGRA
>  	select MFD_CORE
>  	help
> @@ -7,28 +7,28 @@ config MFD_NVEC
>  	    controller.
> 
>  config KEYBOARD_NVEC
> -	bool "Keyboard on nVidia compliant EC"
> +	tristate "Keyboard on nVidia compliant EC"
>  	depends on MFD_NVEC && INPUT
>  	help
>  	  Say Y here to enable support for a keyboard connected to
>  	  a nVidia compliant embedded controller.
> 
>  config SERIO_NVEC_PS2
> -	bool "PS2 on nVidia EC"
> +	tristate "PS2 on nVidia EC"
>  	depends on MFD_NVEC && SERIO
>  	help
>  	  Say Y here to enable support for a Touchpad / Mouse connected
>  	  to a nVidia compliant embedded controller.
> 
>  config NVEC_POWER
> -	bool "NVEC charger and battery"
> +	tristate "NVEC charger and battery"
>  	depends on MFD_NVEC && POWER_SUPPLY
>  	help
>  	  Say Y to enable support for battery and charger interface for
>  	  nVidia compliant embedded controllers.
> 
>  config NVEC_PAZ00
> -	bool "Support for OEM specific functions on Compal PAZ00 based devices"
> +	tristate "Support for OEM specific functions on Compal PAZ00 based
> devices" depends on MFD_NVEC && LEDS_CLASS
>  	help
>  	  Say Y to enable control of the yellow side leds on Compal PAZ00 based


From elezegarcia at gmail.com  Tue Apr 23 15:21:26 2013
From: elezegarcia at gmail.com (Ezequiel Garcia)
Date: Tue, 23 Apr 2013 16:21:26 -0300
Subject: [PATCH] drivers: memory: Introduce Marvell EBU Device Bus driver
Message-ID: <1366744886-3019-1-git-send-email-elezegarcia@gmail.com>

From: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>

Marvell EBU SoCs such as Armada 370/XP, Orion5x (88f5xxx) and
Discovery (mv78xx0) supports a Device Bus controller to access several
kinds of memories and I/O devices (NOR, NAND, SRAM, FPGA).

This commit adds a driver to handle this controller. So far only
Armada 370, Armada XP and Discovery SoCs are supported.

The driver must be registered through a device tree node;
as explained in the binding document.

For each child node in the device tree, this driver will:
  * set timing parameters
  * register a child device
  * setup an address decoding window, using the mbus driver

Keep in mind the address decoding window setup is only a temporary hack.
This code will be removed from this devbus driver as soon as a proper device
tree binding for the mbus driver is added.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
Acked-by: Arnd Bergmann <arnd at arndb.de>
---
Hi Greg,

This patch Applies on today linux-next.
I don't know if we are still in time for you to take this
and merge it into v3.10.

All of the DT related changes are in linux-next through arm-soc,
but this driver was left out and, unless you take it, will
get queued for v3.11. So it's up to you.

 .../bindings/memory-controllers/mvebu-devbus.txt   | 156 ++++++++++
 drivers/memory/Kconfig                             |  10 +
 drivers/memory/Makefile                            |   1 +
 drivers/memory/mvebu-devbus.c                      | 340 +++++++++++++++++++++
 4 files changed, 507 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/memory-controllers/mvebu-devbus.txt
 create mode 100644 drivers/memory/mvebu-devbus.c

diff --git a/Documentation/devicetree/bindings/memory-controllers/mvebu-devbus.txt b/Documentation/devicetree/bindings/memory-controllers/mvebu-devbus.txt
new file mode 100644
index 0000000..653c90c
--- /dev/null
+++ b/Documentation/devicetree/bindings/memory-controllers/mvebu-devbus.txt
@@ -0,0 +1,156 @@
+Device tree bindings for MVEBU Device Bus controllers
+
+The Device Bus controller available in some Marvell's SoC allows to control
+different types of standard memory and I/O devices such as NOR, NAND, and FPGA.
+The actual devices are instantiated from the child nodes of a Device Bus node.
+
+Required properties:
+
+ - compatible:          Currently only Armada 370/XP SoC are supported,
+                        with this compatible string:
+
+                        marvell,mvebu-devbus
+
+ - reg:                 A resource specifier for the register space.
+                        This is the base address of a chip select within
+			the controller's register space.
+                        (see the example below)
+
+ - #address-cells:      Must be set to 1
+ - #size-cells:         Must be set to 1
+ - ranges:              Must be set up to reflect the memory layout with four
+                        integer values for each chip-select line in use:
+                        0 <physical address of mapping> <size>
+
+Mandatory timing properties for child nodes:
+
+Read parameters:
+
+ - devbus,turn-off-ps:  Defines the time during which the controller does not
+                        drive the AD bus after the completion of a device read.
+                        This prevents contentions on the Device Bus after a read
+                        cycle from a slow device.
+
+ - devbus,bus-width:    Defines the bus width (e.g. <16>)
+
+ - devbus,badr-skew-ps: Defines the time delay from from A[2:0] toggle,
+                        to read data sample. This parameter is useful for
+                        synchronous pipelined devices, where the address
+                        precedes the read data by one or two cycles.
+
+ - devbus,acc-first-ps: Defines the time delay from the negation of
+                        ALE[0] to the cycle that the first read data is sampled
+                        by the controller.
+
+ - devbus,acc-next-ps:  Defines the time delay between the cycle that
+                        samples data N and the cycle that samples data N+1
+                        (in burst accesses).
+
+ - devbus,rd-setup-ps:  Defines the time delay between DEV_CSn assertion to
+			DEV_OEn assertion. If set to 0 (default),
+                        DEV_OEn and DEV_CSn are asserted at the same cycle.
+                        This parameter has no affect on <acc-first-ps> parameter
+                        (no affect on first data sample). Set <rd-setup-ps>
+                        to a value smaller than <acc-first-ps>.
+
+ - devbus,rd-hold-ps:   Defines the time between the last data sample to the
+			de-assertion of DEV_CSn. If set to 0 (default),
+			DEV_OEn and DEV_CSn are de-asserted at the same cycle
+			(the cycle of the last data sample).
+                        This parameter has no affect on DEV_OEn de-assertion.
+                        DEV_OEn is always de-asserted the next cycle after
+                        last data sampled. Also this parameter has no
+                        affect on <turn-off-ps> parameter.
+                        Set <rd-hold-ps> to a value smaller than <turn-off-ps>.
+
+Write parameters:
+
+ - devbus,ale-wr-ps:    Defines the time delay from the ALE[0] negation cycle
+			to the DEV_WEn assertion.
+
+ - devbus,wr-low-ps:    Defines the time during which DEV_WEn is active.
+                        A[2:0] and Data are kept valid as long as DEV_WEn
+                        is active. This parameter defines the setup time of
+                        address and data to DEV_WEn rise.
+
+ - devbus,wr-high-ps:   Defines the time during which DEV_WEn is kept
+                        inactive (high) between data beats of a burst write.
+                        DEV_A[2:0] and Data are kept valid (do not toggle) for
+                        <wr-high-ps> - <tick> ps.
+			This parameter defines the hold time of address and
+			data after DEV_WEn rise.
+
+ - devbus,sync-enable: Synchronous device enable.
+                       1: True
+                       0: False
+
+An example for an Armada XP GP board, with a 16 MiB NOR device as child
+is showed below. Note that the Device Bus driver is in charge of allocating
+the mbus address decoding window for each of its child devices.
+The window is created using the chip select specified in the child
+device node together with the base address and size specified in the ranges
+property. For instance, in the example below the allocated decoding window
+will start at base address 0xf0000000, with a size 0x1000000 (16 MiB)
+for chip select 0 (a.k.a DEV_BOOTCS).
+
+This address window handling is done in this mvebu-devbus only as a temporary
+solution. It will be removed when the support for mbus device tree binding is
+added.
+
+The reg property implicitly specifies the chip select as this:
+
+  0x10400: DEV_BOOTCS
+  0x10408: DEV_CS0
+  0x10410: DEV_CS1
+  0x10418: DEV_CS2
+  0x10420: DEV_CS3
+
+Example:
+
+	devbus-bootcs at d0010400 {
+		status = "okay";
+		ranges = <0 0xf0000000 0x1000000>; /* @addr 0xf0000000, size 0x1000000 */
+		#address-cells = <1>;
+		#size-cells = <1>;
+
+		/* Device Bus parameters are required */
+
+		/* Read parameters */
+		devbus,bus-width    = <8>;
+		devbus,turn-off-ps  = <60000>;
+		devbus,badr-skew-ps = <0>;
+		devbus,acc-first-ps = <124000>;
+		devbus,acc-next-ps  = <248000>;
+		devbus,rd-setup-ps  = <0>;
+		devbus,rd-hold-ps   = <0>;
+
+		/* Write parameters */
+		devbus,sync-enable = <0>;
+		devbus,wr-high-ps  = <60000>;
+		devbus,wr-low-ps   = <60000>;
+		devbus,ale-wr-ps   = <60000>;
+
+		flash at 0 {
+			compatible = "cfi-flash";
+
+			/* 16 MiB */
+			reg = <0 0x1000000>;
+			bank-width = <2>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+
+			/*
+			 * We split the 16 MiB in two partitions,
+			 * just as an example.
+			 */
+			partition at 0 {
+				label = "First";
+				reg = <0 0x800000>;
+			};
+
+			partition at 800000 {
+				label = "Second";
+				reg = <0x800000 0x800000>;
+			};
+		};
+	};
diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig
index 067f311..29a11db 100644
--- a/drivers/memory/Kconfig
+++ b/drivers/memory/Kconfig
@@ -20,6 +20,16 @@ config TI_EMIF
 	  parameters and other settings during frequency, voltage and
 	  temperature changes
 
+config MVEBU_DEVBUS
+	bool "Marvell EBU Device Bus Controller"
+	default y
+	depends on PLAT_ORION && OF
+	help
+	  This driver is for the Device Bus controller available in some
+	  Marvell EBU SoCs such as Discovery (mv78xx0), Orion (88f5xxx) and
+	  Armada 370 and Armada XP. This controller allows to handle flash
+	  devices such as NOR, NAND, SRAM, and FPGA.
+
 config TEGRA20_MC
 	bool "Tegra20 Memory Controller(MC) driver"
 	default y
diff --git a/drivers/memory/Makefile b/drivers/memory/Makefile
index 9cce5d7..969d923 100644
--- a/drivers/memory/Makefile
+++ b/drivers/memory/Makefile
@@ -6,5 +6,6 @@ ifeq ($(CONFIG_DDR),y)
 obj-$(CONFIG_OF)		+= of_memory.o
 endif
 obj-$(CONFIG_TI_EMIF)		+= emif.o
+obj-$(CONFIG_MVEBU_DEVBUS)	+= mvebu-devbus.o
 obj-$(CONFIG_TEGRA20_MC)	+= tegra20-mc.o
 obj-$(CONFIG_TEGRA30_MC)	+= tegra30-mc.o
diff --git a/drivers/memory/mvebu-devbus.c b/drivers/memory/mvebu-devbus.c
new file mode 100644
index 0000000..978e8e3
--- /dev/null
+++ b/drivers/memory/mvebu-devbus.c
@@ -0,0 +1,340 @@
+/*
+ * Marvell EBU SoC Device Bus Controller
+ * (memory controller for NOR/NAND/SRAM/FPGA devices)
+ *
+ * Copyright (C) 2013 Marvell
+ *
+ * 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 version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
+ *
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/slab.h>
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/clk.h>
+#include <linux/mbus.h>
+#include <linux/of_platform.h>
+#include <linux/of_address.h>
+#include <linux/platform_device.h>
+
+/* Register definitions */
+#define DEV_WIDTH_BIT		30
+#define BADR_SKEW_BIT		28
+#define RD_HOLD_BIT		23
+#define ACC_NEXT_BIT		17
+#define RD_SETUP_BIT		12
+#define ACC_FIRST_BIT		6
+
+#define SYNC_ENABLE_BIT		24
+#define WR_HIGH_BIT		16
+#define WR_LOW_BIT		8
+
+#define READ_PARAM_OFFSET	0x0
+#define WRITE_PARAM_OFFSET	0x4
+
+static const char * const devbus_wins[] = {
+	"devbus-boot",
+	"devbus-cs0",
+	"devbus-cs1",
+	"devbus-cs2",
+	"devbus-cs3",
+};
+
+struct devbus_read_params {
+	u32 bus_width;
+	u32 badr_skew;
+	u32 turn_off;
+	u32 acc_first;
+	u32 acc_next;
+	u32 rd_setup;
+	u32 rd_hold;
+};
+
+struct devbus_write_params {
+	u32 sync_enable;
+	u32 wr_high;
+	u32 wr_low;
+	u32 ale_wr;
+};
+
+struct devbus {
+	struct device *dev;
+	void __iomem *base;
+	unsigned long tick_ps;
+};
+
+static int get_timing_param_ps(struct devbus *devbus,
+			       struct device_node *node,
+			       const char *name,
+			       u32 *ticks)
+{
+	u32 time_ps;
+	int err;
+
+	err = of_property_read_u32(node, name, &time_ps);
+	if (err < 0) {
+		dev_err(devbus->dev, "%s has no '%s' property\n",
+			name, node->full_name);
+		return err;
+	}
+
+	*ticks = (time_ps + devbus->tick_ps - 1) / devbus->tick_ps;
+
+	dev_dbg(devbus->dev, "%s: %u ps -> 0x%x\n",
+		name, time_ps, *ticks);
+	return 0;
+}
+
+static int devbus_set_timing_params(struct devbus *devbus,
+				    struct device_node *node)
+{
+	struct devbus_read_params r;
+	struct devbus_write_params w;
+	u32 value;
+	int err;
+
+	dev_dbg(devbus->dev, "Setting timing parameter, tick is %lu ps\n",
+		devbus->tick_ps);
+
+	/* Get read timings */
+	err = of_property_read_u32(node, "devbus,bus-width", &r.bus_width);
+	if (err < 0) {
+		dev_err(devbus->dev,
+			"%s has no 'devbus,bus-width' property\n",
+			node->full_name);
+		return err;
+	}
+	/* Convert bit width to byte width */
+	r.bus_width /= 8;
+
+	err = get_timing_param_ps(devbus, node, "devbus,badr-skew-ps",
+				 &r.badr_skew);
+	if (err < 0)
+		return err;
+
+	err = get_timing_param_ps(devbus, node, "devbus,turn-off-ps",
+				 &r.turn_off);
+	if (err < 0)
+		return err;
+
+	err = get_timing_param_ps(devbus, node, "devbus,acc-first-ps",
+				 &r.acc_first);
+	if (err < 0)
+		return err;
+
+	err = get_timing_param_ps(devbus, node, "devbus,acc-next-ps",
+				 &r.acc_next);
+	if (err < 0)
+		return err;
+
+	err = get_timing_param_ps(devbus, node, "devbus,rd-setup-ps",
+				 &r.rd_setup);
+	if (err < 0)
+		return err;
+
+	err = get_timing_param_ps(devbus, node, "devbus,rd-hold-ps",
+				 &r.rd_hold);
+	if (err < 0)
+		return err;
+
+	/* Get write timings */
+	err = of_property_read_u32(node, "devbus,sync-enable",
+				  &w.sync_enable);
+	if (err < 0) {
+		dev_err(devbus->dev,
+			"%s has no 'devbus,sync-enable' property\n",
+			node->full_name);
+		return err;
+	}
+
+	err = get_timing_param_ps(devbus, node, "devbus,ale-wr-ps",
+				 &w.ale_wr);
+	if (err < 0)
+		return err;
+
+	err = get_timing_param_ps(devbus, node, "devbus,wr-low-ps",
+				 &w.wr_low);
+	if (err < 0)
+		return err;
+
+	err = get_timing_param_ps(devbus, node, "devbus,wr-high-ps",
+				 &w.wr_high);
+	if (err < 0)
+		return err;
+
+	/* Set read timings */
+	value = r.bus_width << DEV_WIDTH_BIT |
+		r.badr_skew << BADR_SKEW_BIT |
+		r.rd_hold   << RD_HOLD_BIT   |
+		r.acc_next  << ACC_NEXT_BIT  |
+		r.rd_setup  << RD_SETUP_BIT  |
+		r.acc_first << ACC_FIRST_BIT |
+		r.turn_off;
+
+	dev_dbg(devbus->dev, "read parameters register 0x%p = 0x%x\n",
+		devbus->base + READ_PARAM_OFFSET,
+		value);
+
+	writel(value, devbus->base + READ_PARAM_OFFSET);
+
+	/* Set write timings */
+	value = w.sync_enable  << SYNC_ENABLE_BIT |
+		w.wr_low       << WR_LOW_BIT      |
+		w.wr_high      << WR_HIGH_BIT     |
+		w.ale_wr;
+
+	dev_dbg(devbus->dev, "write parameters register: 0x%p = 0x%x\n",
+		devbus->base + WRITE_PARAM_OFFSET,
+		value);
+
+	writel(value, devbus->base + WRITE_PARAM_OFFSET);
+
+	return 0;
+}
+
+static int mvebu_devbus_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct device_node *node = pdev->dev.of_node;
+	struct device_node *parent;
+	struct devbus *devbus;
+	struct resource *res;
+	struct clk *clk;
+	unsigned long rate;
+	const __be32 *ranges;
+	int err, cs;
+	int addr_cells, p_addr_cells, size_cells;
+	int ranges_len, tuple_len;
+	u32 base, size;
+
+	devbus = devm_kzalloc(&pdev->dev, sizeof(struct devbus), GFP_KERNEL);
+	if (!devbus)
+		return -ENOMEM;
+
+	devbus->dev = dev;
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	devbus->base = devm_ioremap_resource(&pdev->dev, res);
+	if (IS_ERR(devbus->base))
+		return PTR_ERR(devbus->base);
+
+	clk = devm_clk_get(&pdev->dev, NULL);
+	if (IS_ERR(clk))
+		return PTR_ERR(clk);
+	clk_prepare_enable(clk);
+
+	/*
+	 * Obtain clock period in picoseconds,
+	 * we need this in order to convert timing
+	 * parameters from cycles to picoseconds.
+	 */
+	rate = clk_get_rate(clk) / 1000;
+	devbus->tick_ps = 1000000000 / rate;
+
+	/* Read the device tree node and set the new timing parameters */
+	err = devbus_set_timing_params(devbus, node);
+	if (err < 0)
+		return err;
+
+	/*
+	 * Allocate an address window for this device.
+	 * If the device probing fails, then we won't be able to
+	 * remove the allocated address decoding window.
+	 *
+	 * FIXME: This is only a temporary hack! We need to do this here
+	 * because we still don't have device tree bindings for mbus.
+	 * Once that support is added, we will declare these address windows
+	 * statically in the device tree, and remove the window configuration
+	 * from here.
+	 */
+
+	/*
+	 * Get the CS to choose the window string.
+	 * This is a bit hacky, but it will be removed once the
+	 * address windows are declared in the device tree.
+	 */
+	cs = (((unsigned long)devbus->base) % 0x400) / 8;
+
+	/*
+	 * Parse 'ranges' property to obtain a (base,size) window tuple.
+	 * This will be removed once the address windows
+	 * are declared in the device tree.
+	 */
+	parent = of_get_parent(node);
+	if (!parent)
+		return -EINVAL;
+
+	p_addr_cells = of_n_addr_cells(parent);
+	of_node_put(parent);
+
+	addr_cells = of_n_addr_cells(node);
+	size_cells = of_n_size_cells(node);
+	tuple_len = (p_addr_cells + addr_cells + size_cells) * sizeof(__be32);
+
+	ranges = of_get_property(node, "ranges", &ranges_len);
+	if (ranges == NULL || ranges_len != tuple_len)
+		return -EINVAL;
+
+	base = of_translate_address(node, ranges + addr_cells);
+	if (base == OF_BAD_ADDR)
+		return -EINVAL;
+	size = of_read_number(ranges + addr_cells + p_addr_cells, size_cells);
+
+	/*
+	 * Create an mbus address windows.
+	 * FIXME: Remove this, together with the above code, once the
+	 * address windows are declared in the device tree.
+	 */
+	err = mvebu_mbus_add_window(devbus_wins[cs], base, size);
+	if (err < 0)
+		return err;
+
+	/*
+	 * We need to create a child device explicitly from here to
+	 * guarantee that the child will be probed after the timing
+	 * parameters for the bus are written.
+	 */
+	err = of_platform_populate(node, NULL, NULL, dev);
+	if (err < 0) {
+		mvebu_mbus_del_window(base, size);
+		return err;
+	}
+
+	return 0;
+}
+
+static const struct of_device_id mvebu_devbus_of_match[] = {
+	{ .compatible = "marvell,mvebu-devbus" },
+	{},
+};
+MODULE_DEVICE_TABLE(of, mvebu_devbus_of_match);
+
+static struct platform_driver mvebu_devbus_driver = {
+	.probe		= mvebu_devbus_probe,
+	.driver		= {
+		.name	= "mvebu-devbus",
+		.owner	= THIS_MODULE,
+		.of_match_table = mvebu_devbus_of_match,
+	},
+};
+
+static int __init mvebu_devbus_init(void)
+{
+	return platform_driver_register(&mvebu_devbus_driver);
+}
+module_init(mvebu_devbus_init);
+
+MODULE_LICENSE("GPL v2");
+MODULE_AUTHOR("Ezequiel Garcia <ezequiel.garcia at free-electrons.com>");
+MODULE_DESCRIPTION("Marvell EBU SoC Device Bus controller");
-- 
1.8.1.5



From linux at arm.linux.org.uk  Tue Apr 23 15:19:27 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Tue, 23 Apr 2013 20:19:27 +0100
Subject: [PATCH v4 01/15] ARM: multi-cluster PM: secondary kernel entry
 code
In-Reply-To: <1360041732-17936-2-git-send-email-nicolas.pitre@linaro.org>
References: <1360041732-17936-1-git-send-email-nicolas.pitre@linaro.org>
 <1360041732-17936-2-git-send-email-nicolas.pitre@linaro.org>
Message-ID: <20130423191927.GA5316@n2100.arm.linux.org.uk>

On Tue, Feb 05, 2013 at 12:21:58AM -0500, Nicolas Pitre wrote:
> +#include <asm/mcpm_entry.h>
> +#include <asm/barrier.h>
> +#include <asm/proc-fns.h>
> +#include <asm/cacheflush.h>
> +
> +extern volatile unsigned long mcpm_entry_vectors[MAX_NR_CLUSTERS][MAX_CPUS_PER_CLUSTER];

This should not be volatile.  You should know by now the stance in the
Linux community against using volatile on data declarations.  See
Documentation/volatile-considered-harmful.txt to remind yourself of
the reasoning.

> +
> +void mcpm_set_entry_vector(unsigned cpu, unsigned cluster, void *ptr)
> +{
> +	unsigned long val = ptr ? virt_to_phys(ptr) : 0;
> +	mcpm_entry_vectors[cluster][cpu] = val;
> +	__cpuc_flush_dcache_area((void *)&mcpm_entry_vectors[cluster][cpu], 4);
> +	outer_clean_range(__pa(&mcpm_entry_vectors[cluster][cpu]),
> +			  __pa(&mcpm_entry_vectors[cluster][cpu + 1]));

And really, if the write hasn't been done by the compiler prior to calling
__cpuc_flush_dcache_area() then we're into really bad problems.


From arnd at arndb.de  Tue Apr 23 15:31:07 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 23 Apr 2013 21:31:07 +0200
Subject: [PATCH 05/21] ARM: OMAP2+: add dependencies on ARCH_MULTI_V6/V7
In-Reply-To: <20130423180146.GI10155@atomide.com>
References: <1366734653-488286-1-git-send-email-arnd@arndb.de>
 <1366734653-488286-6-git-send-email-arnd@arndb.de>
 <20130423180146.GI10155@atomide.com>
Message-ID: <201304232131.07512.arnd@arndb.de>

On Tuesday 23 April 2013, Tony Lindgren wrote:
> * Arnd Bergmann <arnd at arndb.de> [130423 09:36]:
> > CONFIG_ARCH_OMAP2PLUS depends on (ARCH_MULTI_V6 || ARCH_MULTI_V7) as of
> > a0694861 "ARM: OMAP2+: Enable ARCH_MULTIPLATFORM support", but the
> > individual OMAP2/3/4/5 and AM33XX platforms can all be selected independent
> > of what we are building for, which is a bug and prevents us from easily
> > building e.g. an ARMv7-only defconfig.
> > 
> > This makes ARCH_OMAP2 depend on ARCH_MULTI_V6 and the others depend on
> > ARCH_MULTI_V7, to ensure we really only build the platforms for the
> > CPUs we have enabled in the global multiplatform configuration step.
> > 
> > Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> > Cc: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
> 
> Acked-by: Tony Lindgren <tony at atomide.com>
> 
Thanks, I've now applied it to the next/fixes-non-critical branch.

	Arnd


From balbi at ti.com  Tue Apr 23 15:30:46 2013
From: balbi at ti.com (Felipe Balbi)
Date: Tue, 23 Apr 2013 22:30:46 +0300
Subject: [PATCH v2] usb: phy: don't mark usb_bind_phy as __init
In-Reply-To: <201304232107.22084.arnd@arndb.de>
References: <1366734653-488286-1-git-send-email-arnd@arndb.de>
 <1366734653-488286-20-git-send-email-arnd@arndb.de>
 <20130423171734.GA31432@kroah.com>
 <201304232107.22084.arnd@arndb.de>
Message-ID: <20130423193046.GC13453@arwen.pp.htv.fi>

On Tue, Apr 23, 2013 at 09:07:21PM +0200, Arnd Bergmann wrote:
> It makes no sense for a symbol to be both exported and marked __init,
> because any users in modules would be calling this function after
> it gets discarded. Further, this patch revolves a section mismatch
> warning from usbhs_init_phys(), which is intentionally not marked
> __init:
> 
> WARNING: vmlinux.o(.text+0x413f8): Section mismatch in reference from
> the function usbhs_init_phys() to the function .init.text:usb_bind_phy()
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Cc: Alan Stern <stern at rowland.harvard.edu>
> Cc: Felipe Balbi <balbi at ti.com>
> Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
> Cc: linux-usb at vger.kernel.org
> ---
> 
> v2: rebased on linux-next

not needed, Greg already has a patch doing exactly this in usb-next.

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130423/a005dd4f/attachment.sig>

From linux at arm.linux.org.uk  Tue Apr 23 15:31:22 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Tue, 23 Apr 2013 20:31:22 +0100
Subject: [PATCH v4 06/15] ARM: mcpm: generic SMP secondary bringup and
 hotplug support
In-Reply-To: <1360041732-17936-7-git-send-email-nicolas.pitre@linaro.org>
References: <1360041732-17936-1-git-send-email-nicolas.pitre@linaro.org>
 <1360041732-17936-7-git-send-email-nicolas.pitre@linaro.org>
Message-ID: <20130423193122.GB5316@n2100.arm.linux.org.uk>

On Tue, Feb 05, 2013 at 12:22:03AM -0500, Nicolas Pitre wrote:
> +static void mcpm_cpu_die(unsigned int cpu)
> +{
> +	unsigned int mpidr, pcpu, pcluster;
> +	mpidr = read_cpuid_mpidr();
> +	pcpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
> +	pcluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
> +	mcpm_set_entry_vector(pcpu, pcluster, NULL);
> +	mcpm_cpu_power_down();

How are dirty caches handled here for the dying CPU?  Bear in mind at the
moment, all that is left to the smp platform implementation, but I don't
see anything in your patch set so far which handles this.

This is going to be especially important as we're moving that into the
generic CPU hotplug code out of the platform code.


From nicolas.pitre at linaro.org  Tue Apr 23 15:34:08 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Tue, 23 Apr 2013 15:34:08 -0400 (EDT)
Subject: [PATCH v4 01/15] ARM: multi-cluster PM: secondary kernel entry
 code
In-Reply-To: <20130423191927.GA5316@n2100.arm.linux.org.uk>
References: <1360041732-17936-1-git-send-email-nicolas.pitre@linaro.org>
 <1360041732-17936-2-git-send-email-nicolas.pitre@linaro.org>
 <20130423191927.GA5316@n2100.arm.linux.org.uk>
Message-ID: <alpine.LFD.2.03.1304231524120.17375@syhkavp.arg>

On Tue, 23 Apr 2013, Russell King - ARM Linux wrote:

> On Tue, Feb 05, 2013 at 12:21:58AM -0500, Nicolas Pitre wrote:
> > +#include <asm/mcpm_entry.h>
> > +#include <asm/barrier.h>
> > +#include <asm/proc-fns.h>
> > +#include <asm/cacheflush.h>
> > +
> > +extern volatile unsigned long mcpm_entry_vectors[MAX_NR_CLUSTERS][MAX_CPUS_PER_CLUSTER];
> 
> This should not be volatile.  You should know by now the stance in the
> Linux community against using volatile on data declarations.  See
> Documentation/volatile-considered-harmful.txt to remind yourself of
> the reasoning.

That document says:

|The key point to understand with regard to volatile is that its purpose 
|is to suppress optimization, which is almost never what one really 
|wants to do.

Turns out that this is exactly what we want here: suppress optimization.

However ...

> > +
> > +void mcpm_set_entry_vector(unsigned cpu, unsigned cluster, void *ptr)
> > +{
> > +	unsigned long val = ptr ? virt_to_phys(ptr) : 0;
> > +	mcpm_entry_vectors[cluster][cpu] = val;
> > +	__cpuc_flush_dcache_area((void *)&mcpm_entry_vectors[cluster][cpu], 4);
> > +	outer_clean_range(__pa(&mcpm_entry_vectors[cluster][cpu]),
> > +			  __pa(&mcpm_entry_vectors[cluster][cpu + 1]));
> 
> And really, if the write hasn't been done by the compiler prior to calling
> __cpuc_flush_dcache_area() then we're into really bad problems.

That is indeed true.  The memory might have been uncacheable at some 
point and then the volatile was necessary in that case.

I removed it in my tree.


Nicolas


From nicolas.pitre at linaro.org  Tue Apr 23 15:36:39 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Tue, 23 Apr 2013 15:36:39 -0400 (EDT)
Subject: [PATCH v4 06/15] ARM: mcpm: generic SMP secondary bringup and
 hotplug support
In-Reply-To: <20130423193122.GB5316@n2100.arm.linux.org.uk>
References: <1360041732-17936-1-git-send-email-nicolas.pitre@linaro.org>
 <1360041732-17936-7-git-send-email-nicolas.pitre@linaro.org>
 <20130423193122.GB5316@n2100.arm.linux.org.uk>
Message-ID: <alpine.LFD.2.03.1304231535280.17375@syhkavp.arg>

On Tue, 23 Apr 2013, Russell King - ARM Linux wrote:

> On Tue, Feb 05, 2013 at 12:22:03AM -0500, Nicolas Pitre wrote:
> > +static void mcpm_cpu_die(unsigned int cpu)
> > +{
> > +	unsigned int mpidr, pcpu, pcluster;
> > +	mpidr = read_cpuid_mpidr();
> > +	pcpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
> > +	pcluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
> > +	mcpm_set_entry_vector(pcpu, pcluster, NULL);
> > +	mcpm_cpu_power_down();
> 
> How are dirty caches handled here for the dying CPU?  Bear in mind at the
> moment, all that is left to the smp platform implementation, but I don't
> see anything in your patch set so far which handles this.
> 
> This is going to be especially important as we're moving that into the
> generic CPU hotplug code out of the platform code.

The cache is handled in the machine specific backend accessed through 
mcpm_cpu_power_down().  See the DCSCB related patches later in the 
series.


Nicolas


From linux at arm.linux.org.uk  Tue Apr 23 15:38:05 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Tue, 23 Apr 2013 20:38:05 +0100
Subject: [PATCH v4 11/15] drivers/bus: add ARM CCI support
In-Reply-To: <1360041732-17936-12-git-send-email-nicolas.pitre@linaro.org>
References: <1360041732-17936-1-git-send-email-nicolas.pitre@linaro.org>
 <1360041732-17936-12-git-send-email-nicolas.pitre@linaro.org>
Message-ID: <20130423193805.GC5316@n2100.arm.linux.org.uk>

On Tue, Feb 05, 2013 at 12:22:08AM -0500, Nicolas Pitre wrote:
> +void disable_cci(int cluster)
> +{
> +	u32 slave_reg = cluster ? CCI400_KF_OFFSET : CCI400_EAG_OFFSET;
> +	writel_relaxed(0x0, info->baseaddr + slave_reg);
> +
> +	while (readl_relaxed(info->baseaddr + CCI_STATUS_OFFSET)
> +						& STATUS_CHANGE_PENDING)
> +			barrier();
> +}
> +EXPORT_SYMBOL_GPL(disable_cci);

This will blow up if the cci driver hasn't been probed - which I guess is
fine.

> +
> +static int cci_driver_probe(struct platform_device *pdev)
> +{
> +	struct resource *res;
> +	int ret = 0;
> +
> +	info = kzalloc(sizeof(*info), GFP_KERNEL);
> +	if (!info) {
> +		dev_err(&pdev->dev, "unable to allocate mem\n");
> +		return -ENOMEM;
> +	}
> +
> +	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +	if (!res) {
> +		dev_err(&pdev->dev, "No memory resource\n");
> +		ret = -EINVAL;
> +		goto mem_free;
> +	}
> +
> +	if (!request_mem_region(res->start, resource_size(res),
> +				dev_name(&pdev->dev))) {
> +		dev_err(&pdev->dev, "address 0x%x in use\n", (u32) res->start);
> +		ret = -EBUSY;
> +		goto mem_free;
> +	}
> +
> +	info->baseaddr = ioremap(res->start, resource_size(res));

As we are moving stuff over to the devm_* APIs, it would be a good idea to
avoid introducing new code not using those APIs - otherwise it just creates
yet more churn, something which Linus objects to.  Can we please try in
future to avoid creating stuff which then needs to be subsequently modified
for the latest ways to do stuff...


From linux at arm.linux.org.uk  Tue Apr 23 15:40:07 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Tue, 23 Apr 2013 20:40:07 +0100
Subject: [PATCH v4 12/15] ARM: CCI: ensure powerdown-time data is
 flushed from cache
In-Reply-To: <1360041732-17936-13-git-send-email-nicolas.pitre@linaro.org>
References: <1360041732-17936-1-git-send-email-nicolas.pitre@linaro.org>
 <1360041732-17936-13-git-send-email-nicolas.pitre@linaro.org>
Message-ID: <20130423194007.GD5316@n2100.arm.linux.org.uk>

On Tue, Feb 05, 2013 at 12:22:09AM -0500, Nicolas Pitre wrote:
> +	/*
> +	 * Multi-cluster systems may need this data when non-coherent, during
> +	 * cluster power-up/power-down. Make sure it reaches main memory:
> +	 */
> +	__cpuc_flush_dcache_area(info, sizeof *info);
> +	__cpuc_flush_dcache_area(&info, sizeof info);
> +	outer_clean_range(virt_to_phys(info), virt_to_phys(info + 1));
> +	outer_clean_range(virt_to_phys(&info), virt_to_phys(&info + 1));

This seems to be a recurring theme throughout these patches.  What it's
saying is that we need a proper way to do this, rather than keep on
open coding this same thing time and time again.  So, it's do something
about that rather than having to go back and rework all this stuff later,
creating "pointless churn" that Linus really hates.


From arnd at arndb.de  Tue Apr 23 15:41:03 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 23 Apr 2013 21:41:03 +0200
Subject: [PATCH 14/21] staging: nvec: allow modular build
In-Reply-To: <4082180.JXNz6TsAKc@ax5200p>
References: <1366734653-488286-1-git-send-email-arnd@arndb.de>
 <1366734653-488286-15-git-send-email-arnd@arndb.de>
 <4082180.JXNz6TsAKc@ax5200p>
Message-ID: <201304232141.04123.arnd@arndb.de>

On Tuesday 23 April 2013, Marc Dietrich wrote:
> On Tuesday 23 April 2013 18:30:46 Arnd Bergmann wrote:
> > The serio code can be a loadable module, which in turn means that nvec
> > also has to be a module, so mark it as "tristate" in Kconfig.
> 
> oh, I didn't saw this randconfig error posting. NVEC isn't prepared for 
> modularized builds yet (it's on the TODO list though). So better say SERIO=y 
> here. Looking a bit closer, there is other stuff which can also be a module 
> (GPIOLIB, I2C, ...) so these also need a =y.

What is the problem with building it as a module? It looks all fine in that
regard.

I also did not see any problems with the other symbols, but that may be
because they get turned on as built-in even in allmodconfig. Marking it
as tristate certainly avoids the problem altogether.

> Should a post a patch?

If you have follow-on patches, they need to go on top now, since Greg
already took this patch.

	Arnd


From mikedunn at newsguy.com  Tue Apr 23 15:42:48 2013
From: mikedunn at newsguy.com (Mike Dunn)
Date: Tue, 23 Apr 2013 12:42:48 -0700
Subject: gpio-pxa initcall level change and machine init breakage
In-Reply-To: <CACRpkdbk24kR75fanvXVAocnuozNq_=jWDSPHPCWhbZCOrN5_Q@mail.gmail.com>
References: <5172B398.7060706@newsguy.com>
 <CAD6h2NSRA9w7GZLQGgK-+TvEAsxwOHow5_26JyVUA6YQyj3OQg@mail.gmail.com>
 <517466F6.3000003@newsguy.com>
 <CAD6h2NSy0=3P-PHdCiJJQG_jvGaFnr7uex+Uxs=0F-VsUxtPWg@mail.gmail.com>
 <CACRpkdbk24kR75fanvXVAocnuozNq_=jWDSPHPCWhbZCOrN5_Q@mail.gmail.com>
Message-ID: <5176E438.80800@newsguy.com>

On 04/23/2013 12:26 AM, Linus Walleij wrote:
> On Mon, Apr 22, 2013 at 2:58 AM, Haojian Zhuang
> <haojian.zhuang at linaro.org> wrote:
>> On 22 April 2013 06:23, Mike Dunn <mikedunn at newsguy.com> wrote:
>>> Will the big guy see this?  Only posted to linux-arm-kernel ML.
>>>
>>> Thanks Haojian,
>>> Mike
> 
> I guess Haojian is referring to me, not Torvalds ...


Oops, sorry Linus.  Note that the other Linus has the patch in his official tree.

[...]


> 
> How hard is it to fix the real problem?
> 
> I'm looking at arch/arm/mach-pxa/palmtreo.c, would
> something like this solve the problem:
> 
>>From 5acf99a576f563d48ca5d25b9e5a1bcdd09331eb Mon Sep 17 00:00:00 2001
> From: Linus Walleij <linus.walleij at linaro.org>
> Date: Tue, 23 Apr 2013 09:24:43 +0200
> Subject: [PATCH] ARM: pxa: set up Treo GPIOs using device initcall
> 
> This augments the Treo setup to grab LCD GPIOs at device_initcall()
> level instead of at init_machine() time, and propagates any
> returned errors so that deferred probe will work.


Thanks for the patch.  I am not having initial success, but will troubleshoot
tomorrow morning.

On a more general note... I'm surprised that gpiolib can not run earlier, for
something so low-level.  The kernel documentation on gpio talks about running
early.  I'm not involved in nor knowledgeable of the pinctrl/gpio work so I
won't question the need.  I'll probably be able to educate myself some more
tomorrow.

Thanks again,
Mike


From linux at arm.linux.org.uk  Tue Apr 23 15:42:37 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Tue, 23 Apr 2013 20:42:37 +0100
Subject: [PATCH v4 15/15] ARM: vexpress: Select multi-cluster SMP
 operation if required
In-Reply-To: <1360041732-17936-16-git-send-email-nicolas.pitre@linaro.org>
References: <1360041732-17936-1-git-send-email-nicolas.pitre@linaro.org>
 <1360041732-17936-16-git-send-email-nicolas.pitre@linaro.org>
Message-ID: <20130423194237.GE5316@n2100.arm.linux.org.uk>

On Tue, Feb 05, 2013 at 12:22:12AM -0500, Nicolas Pitre wrote:
> +void __init vexpress_smp_init_ops(void)
> +{
> +	struct smp_operations *ops = &vexpress_smp_ops;
> +#ifdef CONFIG_CLUSTER_PM
> +	extern struct smp_operations mcpm_smp_ops;
> +	if(of_find_compatible_node(NULL, NULL, "arm,cci"))
> +		ops = &mcpm_smp_ops;

Hmm, so these patches haven't been subjected to checkpatch treatment?
As a seasoned kernel programmer, I'm surprised you haven't checked that
already.


From arnd at arndb.de  Tue Apr 23 15:46:19 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 23 Apr 2013 21:46:19 +0200
Subject: [PATCH v2] usb: phy: don't mark usb_bind_phy as __init
In-Reply-To: <20130423193046.GC13453@arwen.pp.htv.fi>
References: <1366734653-488286-1-git-send-email-arnd@arndb.de>
 <201304232107.22084.arnd@arndb.de> <20130423193046.GC13453@arwen.pp.htv.fi>
Message-ID: <201304232146.20011.arnd@arndb.de>

On Tuesday 23 April 2013, Felipe Balbi wrote:
> On Tue, Apr 23, 2013 at 09:07:21PM +0200, Arnd Bergmann wrote:
> > It makes no sense for a symbol to be both exported and marked __init,
> > because any users in modules would be calling this function after
> > it gets discarded. Further, this patch revolves a section mismatch
> > warning from usbhs_init_phys(), which is intentionally not marked
> > __init:
> > 
> > WARNING: vmlinux.o(.text+0x413f8): Section mismatch in reference from
> > the function usbhs_init_phys() to the function .init.text:usb_bind_phy()
> > 
> > Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> > Cc: Alan Stern <stern at rowland.harvard.edu>
> > Cc: Felipe Balbi <balbi at ti.com>
> > Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
> > Cc: linux-usb at vger.kernel.org
> > ---
> > 
> > v2: rebased on linux-next
> 
> not needed, Greg already has a patch doing exactly this in usb-next.

Right, I see it now. I had checked today's linux-next but not usb-next
or any of the other trees for stuff that was just applied today.

	Arnd


From gregkh at linuxfoundation.org  Tue Apr 23 15:48:22 2013
From: gregkh at linuxfoundation.org (Greg KH)
Date: Tue, 23 Apr 2013 12:48:22 -0700
Subject: [PATCH] drivers: memory: Introduce Marvell EBU Device Bus driver
In-Reply-To: <1366744886-3019-1-git-send-email-elezegarcia@gmail.com>
References: <1366744886-3019-1-git-send-email-elezegarcia@gmail.com>
Message-ID: <20130423194822.GA7214@kroah.com>

On Tue, Apr 23, 2013 at 04:21:26PM -0300, Ezequiel Garcia wrote:
> From: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
> 
> Marvell EBU SoCs such as Armada 370/XP, Orion5x (88f5xxx) and
> Discovery (mv78xx0) supports a Device Bus controller to access several
> kinds of memories and I/O devices (NOR, NAND, SRAM, FPGA).
> 
> This commit adds a driver to handle this controller. So far only
> Armada 370, Armada XP and Discovery SoCs are supported.
> 
> The driver must be registered through a device tree node;
> as explained in the binding document.
> 
> For each child node in the device tree, this driver will:
>   * set timing parameters
>   * register a child device
>   * setup an address decoding window, using the mbus driver
> 
> Keep in mind the address decoding window setup is only a temporary hack.
> This code will be removed from this devbus driver as soon as a proper device
> tree binding for the mbus driver is added.
> 
> Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
> Acked-by: Arnd Bergmann <arnd at arndb.de>
> ---
> Hi Greg,
> 
> This patch Applies on today linux-next.
> I don't know if we are still in time for you to take this
> and merge it into v3.10.
> 
> All of the DT related changes are in linux-next through arm-soc,
> but this driver was left out and, unless you take it, will
> get queued for v3.11. So it's up to you.

It's way too late for new drivers for 3.10, sorry.  I'll hold on to this
and merge it to my trees after 3.10-rc1 is out for inclusion in 3.11.

thanks,

greg k-h


From nicolas.pitre at linaro.org  Tue Apr 23 15:53:39 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Tue, 23 Apr 2013 15:53:39 -0400 (EDT)
Subject: [PATCH v4 11/15] drivers/bus: add ARM CCI support
In-Reply-To: <20130423193805.GC5316@n2100.arm.linux.org.uk>
References: <1360041732-17936-1-git-send-email-nicolas.pitre@linaro.org>
 <1360041732-17936-12-git-send-email-nicolas.pitre@linaro.org>
 <20130423193805.GC5316@n2100.arm.linux.org.uk>
Message-ID: <alpine.LFD.2.03.1304231545350.17375@syhkavp.arg>

On Tue, 23 Apr 2013, Russell King - ARM Linux wrote:

> On Tue, Feb 05, 2013 at 12:22:08AM -0500, Nicolas Pitre wrote:
> > +void disable_cci(int cluster)
> > +{
> > +	u32 slave_reg = cluster ? CCI400_KF_OFFSET : CCI400_EAG_OFFSET;
> > +	writel_relaxed(0x0, info->baseaddr + slave_reg);
> > +
> > +	while (readl_relaxed(info->baseaddr + CCI_STATUS_OFFSET)
> > +						& STATUS_CHANGE_PENDING)
> > +			barrier();
> > +}
> > +EXPORT_SYMBOL_GPL(disable_cci);
> 
> This will blow up if the cci driver hasn't been probed - which I guess is
> fine.
> 
> > +
> > +static int cci_driver_probe(struct platform_device *pdev)
> > +{
> > +	struct resource *res;
> > +	int ret = 0;
> > +
> > +	info = kzalloc(sizeof(*info), GFP_KERNEL);
> > +	if (!info) {
> > +		dev_err(&pdev->dev, "unable to allocate mem\n");
> > +		return -ENOMEM;
> > +	}
> > +
> > +	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > +	if (!res) {
> > +		dev_err(&pdev->dev, "No memory resource\n");
> > +		ret = -EINVAL;
> > +		goto mem_free;
> > +	}
> > +
> > +	if (!request_mem_region(res->start, resource_size(res),
> > +				dev_name(&pdev->dev))) {
> > +		dev_err(&pdev->dev, "address 0x%x in use\n", (u32) res->start);
> > +		ret = -EBUSY;
> > +		goto mem_free;
> > +	}
> > +
> > +	info->baseaddr = ioremap(res->start, resource_size(res));
> 
> As we are moving stuff over to the devm_* APIs, it would be a good idea to
> avoid introducing new code not using those APIs - otherwise it just creates
> yet more churn, something which Linus objects to.  Can we please try in
> future to avoid creating stuff which then needs to be subsequently modified
> for the latest ways to do stuff...

This driver is not part of the MCPM pull request.  It was provided to 
illustrate how the MCPM layer is meant to be used.  The on-going 
discussion about CPU/cluster/CCI deviice tree bindings by Lorenzo will 
significantly enhance this driver.  And given the current timing it is 
likely that the enhanced driver will simply replace this one during the 
next cycle, so we should take your comment into account.


Nicolas


From ezequiel.garcia at free-electrons.com  Tue Apr 23 15:55:58 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Tue, 23 Apr 2013 16:55:58 -0300
Subject: [PATCH] drivers: memory: Introduce Marvell EBU Device Bus driver
In-Reply-To: <20130423194822.GA7214@kroah.com>
References: <1366744886-3019-1-git-send-email-elezegarcia@gmail.com>
 <20130423194822.GA7214@kroah.com>
Message-ID: <20130423195556.GA3335@localhost>

On Tue, Apr 23, 2013 at 12:48:22PM -0700, Greg KH wrote:
> On Tue, Apr 23, 2013 at 04:21:26PM -0300, Ezequiel Garcia wrote:
> > From: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
> > 
> > Marvell EBU SoCs such as Armada 370/XP, Orion5x (88f5xxx) and
> > Discovery (mv78xx0) supports a Device Bus controller to access several
> > kinds of memories and I/O devices (NOR, NAND, SRAM, FPGA).
> > 
> > This commit adds a driver to handle this controller. So far only
> > Armada 370, Armada XP and Discovery SoCs are supported.
> > 
> > The driver must be registered through a device tree node;
> > as explained in the binding document.
> > 
> > For each child node in the device tree, this driver will:
> >   * set timing parameters
> >   * register a child device
> >   * setup an address decoding window, using the mbus driver
> > 
> > Keep in mind the address decoding window setup is only a temporary hack.
> > This code will be removed from this devbus driver as soon as a proper device
> > tree binding for the mbus driver is added.
> > 
> > Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
> > Acked-by: Arnd Bergmann <arnd at arndb.de>
> > ---
> > Hi Greg,
> > 
> > This patch Applies on today linux-next.
> > I don't know if we are still in time for you to take this
> > and merge it into v3.10.
> > 
> > All of the DT related changes are in linux-next through arm-soc,
> > but this driver was left out and, unless you take it, will
> > get queued for v3.11. So it's up to you.
> 
> It's way too late for new drivers for 3.10, sorry.  I'll hold on to this
> and merge it to my trees after 3.10-rc1 is out for inclusion in 3.11.
> 

That's fine, no problem.

-- 
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com


From marvin24 at gmx.de  Tue Apr 23 15:55:48 2013
From: marvin24 at gmx.de (Marc Dietrich)
Date: Tue, 23 Apr 2013 21:55:48 +0200
Subject: [PATCH 14/21] staging: nvec: allow modular build
In-Reply-To: <201304232141.04123.arnd@arndb.de>
References: <1366734653-488286-1-git-send-email-arnd@arndb.de>
 <4082180.JXNz6TsAKc@ax5200p> <201304232141.04123.arnd@arndb.de>
Message-ID: <1373204.GiWOFfjzyB@ax5200p>

On Tuesday 23 April 2013 21:41:03 Arnd Bergmann wrote:
> On Tuesday 23 April 2013, Marc Dietrich wrote:
> > On Tuesday 23 April 2013 18:30:46 Arnd Bergmann wrote:
> > > The serio code can be a loadable module, which in turn means that nvec
> > > also has to be a module, so mark it as "tristate" in Kconfig.
> > 
> > oh, I didn't saw this randconfig error posting. NVEC isn't prepared for
> > modularized builds yet (it's on the TODO list though). So better say
> > SERIO=y here. Looking a bit closer, there is other stuff which can also
> > be a module (GPIOLIB, I2C, ...) so these also need a =y.
> 
> What is the problem with building it as a module? It looks all fine in that
> regard.

It builds, but I haven't tried out it yet. At least the mfd children need to 
unregister the event notifier I guess. Anyway, I have no time to test this 
now, so I prefer to force =y for the dependencies for now.

> I also did not see any problems with the other symbols, but that may be
> because they get turned on as built-in even in allmodconfig. Marking it
> as tristate certainly avoids the problem altogether.
> 
> > Should a post a patch?
> 
> If you have follow-on patches, they need to go on top now, since Greg
> already took this patch.

arrr, I wonder why Greg thought that a 4 minute review time is enough :-(
I'll try to post a patch tomorrow then.

Marc



From nicolas.pitre at linaro.org  Tue Apr 23 15:56:35 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Tue, 23 Apr 2013 15:56:35 -0400 (EDT)
Subject: [PATCH v4 15/15] ARM: vexpress: Select multi-cluster SMP operation
 if required
In-Reply-To: <20130423194237.GE5316@n2100.arm.linux.org.uk>
References: <1360041732-17936-1-git-send-email-nicolas.pitre@linaro.org>
 <1360041732-17936-16-git-send-email-nicolas.pitre@linaro.org>
 <20130423194237.GE5316@n2100.arm.linux.org.uk>
Message-ID: <alpine.LFD.2.03.1304231554560.17375@syhkavp.arg>

On Tue, 23 Apr 2013, Russell King - ARM Linux wrote:

> On Tue, Feb 05, 2013 at 12:22:12AM -0500, Nicolas Pitre wrote:
> > +void __init vexpress_smp_init_ops(void)
> > +{
> > +	struct smp_operations *ops = &vexpress_smp_ops;
> > +#ifdef CONFIG_CLUSTER_PM
> > +	extern struct smp_operations mcpm_smp_ops;
> > +	if(of_find_compatible_node(NULL, NULL, "arm,cci"))
> > +		ops = &mcpm_smp_ops;
> 
> Hmm, so these patches haven't been subjected to checkpatch treatment?
> As a seasoned kernel programmer, I'm surprised you haven't checked that
> already.

They have and fixes applied, although after this set was posted.  I 
didn't think it was worth a repost.


Nicolas


From plagnioj at jcrosoft.com  Tue Apr 23 15:52:59 2013
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Tue, 23 Apr 2013 21:52:59 +0200
Subject: [RFC PATCH v2 03/13] ARM: mach-at91: cpus/cpu node dts updates
In-Reply-To: <20130423135304.GG22946@e102568-lin.cambridge.arm.com>
References: <1366644455-16550-1-git-send-email-lorenzo.pieralisi@arm.com>
 <1366644455-16550-4-git-send-email-lorenzo.pieralisi@arm.com>
 <51768892.7060807@gmail.com>
 <20130423135304.GG22946@e102568-lin.cambridge.arm.com>
Message-ID: <20130423195259.GJ4998@game.jcrosoft.org>

On 14:53 Tue 23 Apr     , Lorenzo Pieralisi wrote:
> On Tue, Apr 23, 2013 at 02:11:46PM +0100, Rob Herring wrote:
> > On 04/22/2013 10:27 AM, Lorenzo Pieralisi wrote:
> > > This patch updates the in-kernel dts files according to the latest cpus
> > > and cpu bindings updates for ARM.
> > > 
> > > Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
> > > ---
> > >  arch/arm/boot/dts/at91sam9260.dtsi | 2 +-
> > >  arch/arm/boot/dts/at91sam9263.dtsi | 2 +-
> > >  arch/arm/boot/dts/at91sam9g45.dtsi | 2 +-
> > >  arch/arm/boot/dts/at91sam9n12.dtsi | 2 +-
> > >  4 files changed, 4 insertions(+), 4 deletions(-)
> > > 
> > > diff --git a/arch/arm/boot/dts/at91sam9260.dtsi b/arch/arm/boot/dts/at91sam9260.dtsi
> > > index cb7bcc5..2e9de85 100644
> > > --- a/arch/arm/boot/dts/at91sam9260.dtsi
> > > +++ b/arch/arm/boot/dts/at91sam9260.dtsi
> > > @@ -33,7 +33,7 @@
> > >  	};
> > >  	cpus {
> > >  		cpu at 0 {
> > > -			compatible = "arm,arm926ejs";
> > > +			compatible = "arm,arm926";
> > 
> > I don't understand why you are doing this. If this does not match the
> > documentation, fix the documentation. We can't continue on changing dts
> > files without reqard to breaking compatibility.
> 
> IMHO compatibility is already broken. There are a number of dts in the
> kernel missing cpus and cpu nodes, others with cpu nodes missing
> device_type = "cpu", missing cpu nodes compatible properties and the list
> goes on and on. Those files got merged in the kernel before bindings were
> properly defined for ARM so at that point in time the only reference was the
> ePAPR and still, it was not followed (eg my broken patch above fails to add
> device_type = "cpu" to the cpu node, should I change the documentation (ePAPR)
> to make the dts above compliant ? I do not think so, I reckon we should fix
> all dts and force them to comply with the ePAPR and the in-kernel bindings).
> 
> If we do not set in stone the bindings and draw a line now, this stuff will
> go wild, it is already in a state that I do not like much.
> 
> The reason we are patching the compatible property above is to avoid having
> compatible properties containing suffixes for CPUs, we do not deem that
> necessary, see:
> 
> http://lists.infradead.org/pipermail/linux-arm-kernel/2013-January/145305.html
> 
> That's just my opinion, open to change it to find a proper solution to this
> issue as long as we make progress.

I do not agree when you set the compatible you need to be preceise the cpu is
a arm926ejs not a arm926

Best Regards,
J/
> 
> Thanks for the review,
> Lorenzo
> 
> > 
> > Rob
> > 
> > >  		};
> > >  	};
> > >  
> > > diff --git a/arch/arm/boot/dts/at91sam9263.dtsi b/arch/arm/boot/dts/at91sam9263.dtsi
> > > index 271d4de..25c4725 100644
> > > --- a/arch/arm/boot/dts/at91sam9263.dtsi
> > > +++ b/arch/arm/boot/dts/at91sam9263.dtsi
> > > @@ -30,7 +30,7 @@
> > >  	};
> > >  	cpus {
> > >  		cpu at 0 {
> > > -			compatible = "arm,arm926ejs";
> > > +			compatible = "arm,arm926";
> > >  		};
> > >  	};
> > >  
> > > diff --git a/arch/arm/boot/dts/at91sam9g45.dtsi b/arch/arm/boot/dts/at91sam9g45.dtsi
> > > index 6b1d4ca..cf647d1 100644
> > > --- a/arch/arm/boot/dts/at91sam9g45.dtsi
> > > +++ b/arch/arm/boot/dts/at91sam9g45.dtsi
> > > @@ -36,7 +36,7 @@
> > >  	};
> > >  	cpus {
> > >  		cpu at 0 {
> > > -			compatible = "arm,arm926ejs";
> > > +			compatible = "arm,arm926";
> > >  		};
> > >  	};
> > >  
> > > diff --git a/arch/arm/boot/dts/at91sam9n12.dtsi b/arch/arm/boot/dts/at91sam9n12.dtsi
> > > index 7750f98..d531ae3 100644
> > > --- a/arch/arm/boot/dts/at91sam9n12.dtsi
> > > +++ b/arch/arm/boot/dts/at91sam9n12.dtsi
> > > @@ -32,7 +32,7 @@
> > >  	};
> > >  	cpus {
> > >  		cpu at 0 {
> > > -			compatible = "arm,arm926ejs";
> > > +			compatible = "arm,arm926";
> > >  		};
> > >  	};
> > >  
> > > 
> > 
> > 
> 
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss


From sergei.shtylyov at cogentembedded.com  Tue Apr 23 16:03:51 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Wed, 24 Apr 2013 00:03:51 +0400
Subject: [PATCH 04/10] usb: musb: ux500: harden checks for platform data
In-Reply-To: <1366729394-11406-5-git-send-email-lee.jones@linaro.org>
References: <1366729394-11406-1-git-send-email-lee.jones@linaro.org>
 <1366729394-11406-5-git-send-email-lee.jones@linaro.org>
Message-ID: <5176E927.908@cogentembedded.com>

Hello.

On 04/23/2013 07:03 PM, Lee Jones wrote:

> In its current state, the ux500-musb driver uses platform data pointers
> blindly with no prior checking. If no platform data pointer is passed
> this will Oops the kernel. In this patch we ensure platform data and
> board data are present prior to using them.
>
> Cc: Felipe Balbi <balbi at ti.com>
> Cc: linux-usb at vger.kernel.org
> Signed-off-by: Lee Jones <lee.jones at linaro.org>
> ---
>   drivers/usb/musb/ux500_dma.c |   11 ++++++++---
>   1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/usb/musb/ux500_dma.c b/drivers/usb/musb/ux500_dma.c
> index c75e07a..02b4a6e 100644
> --- a/drivers/usb/musb/ux500_dma.c
> +++ b/drivers/usb/musb/ux500_dma.c
> @@ -287,7 +287,7 @@ static int ux500_dma_controller_start(struct dma_controller *c)
>   	struct musb *musb = controller->private_data;
>   	struct device *dev = musb->controller;
>   	struct musb_hdrc_platform_data *plat = dev->platform_data;
> -	struct ux500_musb_board_data *data = plat->board_data;
> +	struct ux500_musb_board_data *data;
>   	struct dma_channel *dma_channel = NULL;
>   	u32 ch_num;
>   	u8 dir;
> @@ -297,14 +297,19 @@ static int ux500_dma_controller_start(struct dma_controller *c)

[...]

>   
>   	/* Prepare the loop for RX channels */
>   	channel_array = controller->rx_channel;
> -	param_array = data->dma_rx_param_array;
> +	param_array = (data) ? data->dma_rx_param_array : NULL;

    Why enclose a simple variable in parens?

>   
>   	for (dir = 0; dir < 2; dir++) {
>   		for (ch_num = 0;
> @@ -337,7 +342,7 @@ static int ux500_dma_controller_start(struct dma_controller *c)
>   
>   		/* Prepare the loop for TX channels */
>   		channel_array = controller->tx_channel;
> -		param_array = data->dma_tx_param_array;
> +		param_array = (data) ? data->dma_tx_param_array : NULL;

    Again, why?

WBR, Sergei



From linux at arm.linux.org.uk  Tue Apr 23 16:04:29 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Tue, 23 Apr 2013 21:04:29 +0100
Subject: [PATCH v4 00/15] multi-cluster power management
In-Reply-To: <1360041732-17936-1-git-send-email-nicolas.pitre@linaro.org>
References: <1360041732-17936-1-git-send-email-nicolas.pitre@linaro.org>
Message-ID: <20130423200429.GF5316@n2100.arm.linux.org.uk>

On Tue, Feb 05, 2013 at 12:21:57AM -0500, Nicolas Pitre wrote:
> This is version 4 of the patch series required to safely power up
> and down CPUs in a cluster as can be found in b.L systems.  If nothing
> major is reported, I'll send a pull request to Russell for this set
> very soon.

Okay, so from spending an hour or so quickly scanning these patches,
on the face of it there are only a few comments I have which I'm very
surprised that your exhaustive team of apparant reviewers didn't
already catch.

The biggest disappointment so far in this patch set is finding the
re-use of the repeated cache handling stuff - when I've already made
my feelings _well_ known towards re-using existing cache APIs (which
are designed to handle a _purpose_) for different purposes "just
because" they appear to do what you need on a particular CPU.  I've
stated my objection to this kind of behaviour many times in the past,
I've even _purposely_ broken stuff (mtd stuff) when that's happened in
the past, and I've not changed my views on this one bit.  It's really
surprising to me that someone who has been around for such a long time,
and who knows my views on this, is pushing a patch set which goes
against that, and somehow thinks that I won't have a problem with
it... really?

What I suggest for the time being is to provide new inline function(s)
in arch/arm/include/cacheflush.h which are purposed for your application,
document them in that file, and call the implementation you're currently
using.  That means if we do have to change it in the future (for example,
we don't need to do anything in the dcache flushing stuff) we don't have
to hunt through all the code to find _your_ different use of that function
and fix it - we can just fix it in one place and we have the reference
there for what your code expects.

Again, this is nothing new - I've made my position on this kind of stuff
_exceedingly_ plain in the past.


That all said, my biggest concern so far from this set is the independent
issue of moving the cache handling into generic code, so that we avoid
the existing problem where every platform ends up implementing that stuff
time and time again - and the impact that will have on this MCPM code.

Currently as I see it, the two things are mutually incompatible with
each other - and having discussed with Will, we'd come to the conclusion
that I'd merge what I had because the comments alone on how the cpu
hotplug stuff is supposed to work are a valuable improvement, even
though the code changes don't completely solve all the issues.

However, MCPMm gets in the way of that.  So... that presents a dilema...
it's a case of this or that but not both.  Or do you think MCPM can
survive with additional LOUIS flushing before the cpu die callback is
called?


From gregkh at linuxfoundation.org  Tue Apr 23 16:05:55 2013
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Tue, 23 Apr 2013 13:05:55 -0700
Subject: [PATCH 14/21] staging: nvec: allow modular build
In-Reply-To: <1373204.GiWOFfjzyB@ax5200p>
References: <1366734653-488286-1-git-send-email-arnd@arndb.de>
 <4082180.JXNz6TsAKc@ax5200p> <201304232141.04123.arnd@arndb.de>
 <1373204.GiWOFfjzyB@ax5200p>
Message-ID: <20130423200555.GA31383@kroah.com>

On Tue, Apr 23, 2013 at 09:55:48PM +0200, Marc Dietrich wrote:
> On Tuesday 23 April 2013 21:41:03 Arnd Bergmann wrote:
> > On Tuesday 23 April 2013, Marc Dietrich wrote:
> > > On Tuesday 23 April 2013 18:30:46 Arnd Bergmann wrote:
> > > > The serio code can be a loadable module, which in turn means that nvec
> > > > also has to be a module, so mark it as "tristate" in Kconfig.
> > > 
> > > oh, I didn't saw this randconfig error posting. NVEC isn't prepared for
> > > modularized builds yet (it's on the TODO list though). So better say
> > > SERIO=y here. Looking a bit closer, there is other stuff which can also
> > > be a module (GPIOLIB, I2C, ...) so these also need a =y.
> > 
> > What is the problem with building it as a module? It looks all fine in that
> > regard.
> 
> It builds, but I haven't tried out it yet. At least the mfd children need to 
> unregister the event notifier I guess. Anyway, I have no time to test this 
> now, so I prefer to force =y for the dependencies for now.
> 
> > I also did not see any problems with the other symbols, but that may be
> > because they get turned on as built-in even in allmodconfig. Marking it
> > as tristate certainly avoids the problem altogether.
> > 
> > > Should a post a patch?
> > 
> > If you have follow-on patches, they need to go on top now, since Greg
> > already took this patch.
> 
> arrr, I wonder why Greg thought that a 4 minute review time is enough :-(

It was longer than 4 minutes...

I trust Arnd, and it's only a staging driver, what's the worse thing
that could happen to it?  :)

> I'll try to post a patch tomorrow then.

That would be great.

thanks,

greg k-h


From linux at arm.linux.org.uk  Tue Apr 23 16:09:08 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Tue, 23 Apr 2013 21:09:08 +0100
Subject: [PATCH v4 01/15] ARM: multi-cluster PM: secondary kernel entry
 code
In-Reply-To: <alpine.LFD.2.03.1304231524120.17375@syhkavp.arg>
References: <1360041732-17936-1-git-send-email-nicolas.pitre@linaro.org>
 <1360041732-17936-2-git-send-email-nicolas.pitre@linaro.org>
 <20130423191927.GA5316@n2100.arm.linux.org.uk>
 <alpine.LFD.2.03.1304231524120.17375@syhkavp.arg>
Message-ID: <20130423200908.GX14496@n2100.arm.linux.org.uk>

On Tue, Apr 23, 2013 at 03:34:08PM -0400, Nicolas Pitre wrote:
> On Tue, 23 Apr 2013, Russell King - ARM Linux wrote:
> 
> > On Tue, Feb 05, 2013 at 12:21:58AM -0500, Nicolas Pitre wrote:
> > > +#include <asm/mcpm_entry.h>
> > > +#include <asm/barrier.h>
> > > +#include <asm/proc-fns.h>
> > > +#include <asm/cacheflush.h>
> > > +
> > > +extern volatile unsigned long mcpm_entry_vectors[MAX_NR_CLUSTERS][MAX_CPUS_PER_CLUSTER];
> > 
> > This should not be volatile.  You should know by now the stance in the
> > Linux community against using volatile on data declarations.  See
> > Documentation/volatile-considered-harmful.txt to remind yourself of
> > the reasoning.
> 
> That document says:
> 
> |The key point to understand with regard to volatile is that its purpose 
> |is to suppress optimization, which is almost never what one really 
> |wants to do.
> 
> Turns out that this is exactly what we want here: suppress optimization.

What optimization are you trying to suppress in the function below?

> However ...
> 
> > > +
> > > +void mcpm_set_entry_vector(unsigned cpu, unsigned cluster, void *ptr)
> > > +{
> > > +	unsigned long val = ptr ? virt_to_phys(ptr) : 0;
> > > +	mcpm_entry_vectors[cluster][cpu] = val;
> > > +	__cpuc_flush_dcache_area((void *)&mcpm_entry_vectors[cluster][cpu], 4);
> > > +	outer_clean_range(__pa(&mcpm_entry_vectors[cluster][cpu]),
> > > +			  __pa(&mcpm_entry_vectors[cluster][cpu + 1]));
> > 
> > And really, if the write hasn't been done by the compiler prior to calling
> > __cpuc_flush_dcache_area() then we're into really bad problems.
> 
> That is indeed true.  The memory might have been uncacheable at some 
> point and then the volatile was necessary in that case.

I don't buy the argument about it being uncachable - the compiler doesn't
know that, and the cacheability of the memory really doesn't change the
code that the compiler produces.

Moreover, the compiler can't really reorder the store to
mcpm_entry_vectors[cluster][cpu] with the calls to the cache flushing
anyway - and as the compiler has no clue what those calls are doing
so it has to ensure that the results of the preceding code is visible
to some "unknown code" which it can't see.  Therefore, it practically
has no option but to issue the store before calling those cache flush
functions.

Also... consider using sizeof() rather than constant 4.


From arnd at arndb.de  Tue Apr 23 16:14:18 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 23 Apr 2013 22:14:18 +0200
Subject: [PATCH 14/21] staging: nvec: allow modular build
In-Reply-To: <1373204.GiWOFfjzyB@ax5200p>
References: <1366734653-488286-1-git-send-email-arnd@arndb.de>
 <201304232141.04123.arnd@arndb.de> <1373204.GiWOFfjzyB@ax5200p>
Message-ID: <201304232214.18254.arnd@arndb.de>

On Tuesday 23 April 2013, Marc Dietrich wrote:
> It builds, but I haven't tried out it yet. At least the mfd children need to 
> unregister the event notifier I guess. Anyway, I have no time to test this 
> now, so I prefer to force =y for the dependencies for now.

Ah, so you can load it fine, but not safely unload it? In that case I think
it's better to leave it as tristate but remove the module_exit() function to
prevent unloading.

You'll have to change the module_platform_driver() back into a manual
module_init() function to register the driver, but that sounds like
the cleanest solution aside from fixing the notifier calls.

	Arnd


From nicolas.pitre at linaro.org  Tue Apr 23 16:19:58 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Tue, 23 Apr 2013 16:19:58 -0400 (EDT)
Subject: [PATCH v4 01/15] ARM: multi-cluster PM: secondary kernel entry
 code
In-Reply-To: <20130423200908.GX14496@n2100.arm.linux.org.uk>
References: <1360041732-17936-1-git-send-email-nicolas.pitre@linaro.org>
 <1360041732-17936-2-git-send-email-nicolas.pitre@linaro.org>
 <20130423191927.GA5316@n2100.arm.linux.org.uk>
 <alpine.LFD.2.03.1304231524120.17375@syhkavp.arg>
 <20130423200908.GX14496@n2100.arm.linux.org.uk>
Message-ID: <alpine.LFD.2.03.1304231615140.17375@syhkavp.arg>

On Tue, 23 Apr 2013, Russell King - ARM Linux wrote:

> On Tue, Apr 23, 2013 at 03:34:08PM -0400, Nicolas Pitre wrote:
> > On Tue, 23 Apr 2013, Russell King - ARM Linux wrote:
> > 
> > > On Tue, Feb 05, 2013 at 12:21:58AM -0500, Nicolas Pitre wrote:
> > > > +#include <asm/mcpm_entry.h>
> > > > +#include <asm/barrier.h>
> > > > +#include <asm/proc-fns.h>
> > > > +#include <asm/cacheflush.h>
> > > > +
> > > > +extern volatile unsigned long mcpm_entry_vectors[MAX_NR_CLUSTERS][MAX_CPUS_PER_CLUSTER];
> > > 
> > > This should not be volatile.  You should know by now the stance in the
> > > Linux community against using volatile on data declarations.  See
> > > Documentation/volatile-considered-harmful.txt to remind yourself of
> > > the reasoning.
> > 
> > That document says:
> > 
> > |The key point to understand with regard to volatile is that its purpose 
> > |is to suppress optimization, which is almost never what one really 
> > |wants to do.
> > 
> > Turns out that this is exactly what we want here: suppress optimization.
> 
> What optimization are you trying to suppress in the function below?

Ordering of writes to this memory wrt other code in case the above 
function was inlined.  But as I said this is a moot point now.

> > However ...
> > 
> > > > +
> > > > +void mcpm_set_entry_vector(unsigned cpu, unsigned cluster, void *ptr)
> > > > +{
> > > > +	unsigned long val = ptr ? virt_to_phys(ptr) : 0;
> > > > +	mcpm_entry_vectors[cluster][cpu] = val;
> > > > +	__cpuc_flush_dcache_area((void *)&mcpm_entry_vectors[cluster][cpu], 4);
> > > > +	outer_clean_range(__pa(&mcpm_entry_vectors[cluster][cpu]),
> > > > +			  __pa(&mcpm_entry_vectors[cluster][cpu + 1]));
> > > 
> > > And really, if the write hasn't been done by the compiler prior to calling
> > > __cpuc_flush_dcache_area() then we're into really bad problems.
> > 
> > That is indeed true.  The memory might have been uncacheable at some 
> > point and then the volatile was necessary in that case.
> 
> I don't buy the argument about it being uncachable - the compiler doesn't
> know that, and the cacheability of the memory really doesn't change the
> code that the compiler produces.

My point is that the memory is now cacheable these days, which requires 
explicit cache maintenance for the writes to hit main memory.  That 
cache maintenance acts as a barrier the volatile used to be before that 
cache maintenance call was there.

> Also... consider using sizeof() rather than constant 4.

Sure.


Nicolas


From marvin24 at gmx.de  Tue Apr 23 16:21:03 2013
From: marvin24 at gmx.de (Marc Dietrich)
Date: Tue, 23 Apr 2013 22:21:03 +0200
Subject: [PATCH 14/21] staging: nvec: allow modular build
In-Reply-To: <201304232214.18254.arnd@arndb.de>
References: <1366734653-488286-1-git-send-email-arnd@arndb.de>
 <1373204.GiWOFfjzyB@ax5200p> <201304232214.18254.arnd@arndb.de>
Message-ID: <11391915.IGaQsBJu0i@ax5200p>

On Tuesday 23 April 2013 22:14:18 Arnd Bergmann wrote:
> On Tuesday 23 April 2013, Marc Dietrich wrote:
> > It builds, but I haven't tried out it yet. At least the mfd children need
> > to unregister the event notifier I guess. Anyway, I have no time to test
> > this now, so I prefer to force =y for the dependencies for now.
> 
> Ah, so you can load it fine, but not safely unload it? In that case I think
> it's better to leave it as tristate but remove the module_exit() function to
> prevent unloading.
> 
> You'll have to change the module_platform_driver() back into a manual
> module_init() function to register the driver, but that sounds like
> the cleanest solution aside from fixing the notifier calls.

ok, I'll look into it - maybe I can also fix unloading.

Thanks!

Marc




From nicolas.pitre at linaro.org  Tue Apr 23 17:03:06 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Tue, 23 Apr 2013 17:03:06 -0400 (EDT)
Subject: [PATCH v4 00/15] multi-cluster power management
In-Reply-To: <20130423200429.GF5316@n2100.arm.linux.org.uk>
References: <1360041732-17936-1-git-send-email-nicolas.pitre@linaro.org>
 <20130423200429.GF5316@n2100.arm.linux.org.uk>
Message-ID: <alpine.LFD.2.03.1304231657150.17375@syhkavp.arg>

On Tue, 23 Apr 2013, Russell King - ARM Linux wrote:

> What I suggest for the time being is to provide new inline function(s)
> in arch/arm/include/cacheflush.h which are purposed for your application,
> document them in that file, and call the implementation you're currently
> using.  That means if we do have to change it in the future (for example,
> we don't need to do anything in the dcache flushing stuff) we don't have
> to hunt through all the code to find _your_ different use of that function
> and fix it - we can just fix it in one place and we have the reference
> there for what your code expects.

What about the patch below?  Once you tell me it is fine to you I'll 
adapt the MCPM series to it.

----- >8
From: Nicolas Pitre <nicolas.pitre at linaro.org>
Date: Tue, 23 Apr 2013 16:45:40 -0400
Subject: [PATCH] ARM: cacheflush: add synchronization helpers for mixed cache state accesses

Algorithms used by the MCPM layer rely on state variables which are
accessed while the cache is either active or inactive, depending
on the code path and the active state.

This patch introduces generic cache maintenance helpers to provide the
necessary cache synchronization for such state variables to always hit
main memory in a ordered way.

Signed-off-by: Nicolas Pitre <nico at linaro.org>

diff --git a/arch/arm/include/asm/cacheflush.h b/arch/arm/include/asm/cacheflush.h
index e1489c54cd..bff71388e7 100644
--- a/arch/arm/include/asm/cacheflush.h
+++ b/arch/arm/include/asm/cacheflush.h
@@ -363,4 +363,79 @@ static inline void flush_cache_vunmap(unsigned long start, unsigned long end)
 		flush_cache_all();
 }
 
+/*
+ * Memory synchronization helpers for mixed cached vs non cached accesses.
+ *
+ * Some synchronization algorithms have to set states in memory with the
+ * cache enabled or disabled depending on the code path.  It is crucial
+ * to always ensure proper cache maintenance to update main memory right
+ * away in that case.
+ *
+ * Any cached write must be followed by a cache clean operation.
+ * Any cached read must be preceded by a cache invalidate operation.
+ * Yet, in the read case, a cache flush i.e. atomic clean+invalidate
+ * operation is needed to avoid discarding possible concurrent writes to the
+ * accessed memory.
+ *
+ * Also, in order to prevent a cached writer from interfering with an
+ * adjacent non-cached writer, each state variable must be located to
+ * a separate cache line.
+ */
+
+/*
+ * This needs to be >= the max cache writeback size of all
+ * supported platforms included in the current kernel configuration.
+ * This is used to align state variables to their own cache lines.
+ */
+#define __CACHE_WRITEBACK_ORDER 6  /* guessed from existing platforms */
+#define __CACHE_WRITEBACK_GRANULE (1 << __CACHE_WRITEBACK_ORDER)
+
+/*
+ * There is no __cpuc_clean_dcache_area but we use it anyway for
+ * code intent clarity, and alias it to __cpuc_flush_dcache_area.
+ */
+#define __cpuc_clean_dcache_area __cpuc_flush_dcache_area
+
+/*
+ * Ensure preceding writes to *p by this CPU are visible to
+ * subsequent reads by other CPUs:
+ */
+static inline void __sync_cache_range_w(volatile void *p, size_t size)
+{
+	char *_p = (char *)p;
+
+	__cpuc_clean_dcache_area(_p, size);
+	outer_clean_range(__pa(_p), __pa(_p + size));
+}
+
+/*
+ * Ensure preceding writes to *p by other CPUs are visible to
+ * subsequent reads by this CPU.  We must be careful not to
+ * discard data simultaneously written by another CPU, hence the
+ * usage of flush rather than invalidate operations.
+ */
+static inline void __sync_cache_range_r(volatile void *p, size_t size)
+{
+	char *_p = (char *)p;
+
+#ifdef CONFIG_OUTER_CACHE
+	if (outer_cache.flush_range) {
+		/*
+		 * Ensure dirty data migrated from other CPUs into our cache
+		 * are cleaned out safely before the outer cache is cleaned:
+		 */
+		__cpuc_clean_dcache_area(_p, size);
+
+		/* Clean and invalidate stale data for *p from outer ... */
+		outer_flush_range(__pa(_p), __pa(_p + size));
+	}
+#endif
+
+	/* ... and inner cache: */
+	__cpuc_flush_dcache_area(_p, size);
+}
+
+#define sync_cache_w(ptr) __sync_cache_range_w(ptr, sizeof *(ptr))
+#define sync_cache_r(ptr) __sync_cache_range_r(ptr, sizeof *(ptr))
+
 #endif


From nicolas.pitre at linaro.org  Tue Apr 23 17:11:48 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Tue, 23 Apr 2013 17:11:48 -0400 (EDT)
Subject: [PATCH v4 00/15] multi-cluster power management
In-Reply-To: <20130423200429.GF5316@n2100.arm.linux.org.uk>
References: <1360041732-17936-1-git-send-email-nicolas.pitre@linaro.org>
 <20130423200429.GF5316@n2100.arm.linux.org.uk>
Message-ID: <alpine.LFD.2.03.1304231703390.17375@syhkavp.arg>

On Tue, 23 Apr 2013, Russell King - ARM Linux wrote:

> That all said, my biggest concern so far from this set is the independent
> issue of moving the cache handling into generic code, so that we avoid
> the existing problem where every platform ends up implementing that stuff
> time and time again - and the impact that will have on this MCPM code.
> 
> Currently as I see it, the two things are mutually incompatible with
> each other - and having discussed with Will, we'd come to the conclusion
> that I'd merge what I had because the comments alone on how the cpu
> hotplug stuff is supposed to work are a valuable improvement, even
> though the code changes don't completely solve all the issues.
> 
> However, MCPMm gets in the way of that.  So... that presents a dilema...
> it's a case of this or that but not both.  Or do you think MCPM can
> survive with additional LOUIS flushing before the cpu die callback is
> called?

We can have both for now.  MCPM most certainly can survive it.

The cache should be mostly clean when the machine backend flushes up to 
LOUIS in that case so that shouldn't be very costly to do it again. And 
the removing of a CPU via the hotplug path is hardly a performance 
critical operation.


Nicolas


From gmbnomis at gmail.com  Tue Apr 23 17:22:25 2013
From: gmbnomis at gmail.com (Simon Baatz)
Date: Tue, 23 Apr 2013 23:22:25 +0200
Subject: [PATCH 1/3] mmc: mvsdio: Support inverted CD and WP GPIO lines
In-Reply-To: <87sj2iteue.fsf@octavius.laptop.org>
References: <1366660500-26835-1-git-send-email-gmbnomis@gmail.com>
 <1366660500-26835-2-git-send-email-gmbnomis@gmail.com>
 <87wqrutjss.fsf@octavius.laptop.org>
 <20130422203723.GI29947@lunn.ch>
 <20130422210949.GJ25724@titan.lakedaemon.net>
 <20130422214543.GJ29947@lunn.ch>
 <87sj2iteue.fsf@octavius.laptop.org>
Message-ID: <20130423212224.GA29507@schnuecks.de>

Hi Chris, Guennadi,

On Mon, Apr 22, 2013 at 05:50:17PM -0400, Chris Ball wrote:
> Hi,
> 
> On Mon, Apr 22 2013, Andrew Lunn wrote:
> >> Nothing else really jumps out though.  Where either of these what you
> >> were thinking of?
> >
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2012-December/138514.html
> >
> > and
> >
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2012-December/138513.html
> 
> These patches move mvsdio to slot-gpio, which is a prerequisite for
> using the shared mmc_of_parse(), but they don't go all the way to
> using mmc_of_parse().

That's nice functionality, I was not aware of that. I will convert this
to mmc_of_parse() once I find some time.

One question already: Why does mmc_of_parse() not return errors to
the caller?  If, for example, a GPIO line was given for CD in the DT,
but it could not be obtained, shouldn't the caller at least have the
possibility to handle this as an error?  (mvsdio currently
aborts the probe if it can't get the GPIO line).

- Simon


From arnd at arndb.de  Tue Apr 23 17:23:27 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 23 Apr 2013 23:23:27 +0200
Subject: [PATCH] ARM: OMAP: remove unused variable
In-Reply-To: <1363818875-15978-1-git-send-email-robherring2@gmail.com>
References: <1363818875-15978-1-git-send-email-robherring2@gmail.com>
Message-ID: <201304232323.27751.arnd@arndb.de>

ARM: OMAP: remove unused variable
    
Commit 0583fe478a7 "ARM: convert arm/arm64 arch timer to use CLKSRC_OF init"
has left the omap5_realtime_timer_init() function with a stale variable and
broken whitespace. This fixes both.
    
Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
I've applied this patch on top of the timer cleanup series

diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 7dd6453..686e498 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -618,12 +618,10 @@ OMAP_SYS_32K_TIMER_INIT(5, 1, OMAP4_32K_SOURCE, "ti,timer-alwon",
 			2, OMAP4_MPU_SOURCE);
 void __init omap5_realtime_timer_init(void)
 {
-	int err;
-
 	omap5_sync32k_timer_init();
 	realtime_counter_init();
 
-        clocksource_of_init();
+	clocksource_of_init();
 }
 #endif /* CONFIG_SOC_OMAP5 */
 


From tony at atomide.com  Tue Apr 23 17:26:07 2013
From: tony at atomide.com (Tony Lindgren)
Date: Tue, 23 Apr 2013 14:26:07 -0700
Subject: [PATCH] ARM: OMAP: remove unused variable
In-Reply-To: <201304232323.27751.arnd@arndb.de>
References: <1363818875-15978-1-git-send-email-robherring2@gmail.com>
 <201304232323.27751.arnd@arndb.de>
Message-ID: <20130423212607.GL10155@atomide.com>

* Arnd Bergmann <arnd at arndb.de> [130423 14:28]:
> ARM: OMAP: remove unused variable
>     
> Commit 0583fe478a7 "ARM: convert arm/arm64 arch timer to use CLKSRC_OF init"
> has left the omap5_realtime_timer_init() function with a stale variable and
> broken whitespace. This fixes both.
>     
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> ---
> I've applied this patch on top of the timer cleanup series

OK thanks.

Tony
 
> diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
> index 7dd6453..686e498 100644
> --- a/arch/arm/mach-omap2/timer.c
> +++ b/arch/arm/mach-omap2/timer.c
> @@ -618,12 +618,10 @@ OMAP_SYS_32K_TIMER_INIT(5, 1, OMAP4_32K_SOURCE, "ti,timer-alwon",
>  			2, OMAP4_MPU_SOURCE);
>  void __init omap5_realtime_timer_init(void)
>  {
> -	int err;
> -
>  	omap5_sync32k_timer_init();
>  	realtime_counter_init();
>  
> -        clocksource_of_init();
> +	clocksource_of_init();
>  }
>  #endif /* CONFIG_SOC_OMAP5 */
>  


From tony at atomide.com  Tue Apr 23 17:31:52 2013
From: tony at atomide.com (Tony Lindgren)
Date: Tue, 23 Apr 2013 14:31:52 -0700
Subject: Multiple issues with omap4 panda es in linux next
In-Reply-To: <20130423172353.GD10155@atomide.com>
References: <20130419171318.GK10155@atomide.com> <5174F7A8.7070308@ti.com>
 <20130422180316.GA10155@atomide.com> <5176A45B.5@ti.com>
 <20130423172353.GD10155@atomide.com>
Message-ID: <20130423213151.GM10155@atomide.com>

* Tony Lindgren <tony at atomide.com> [130423 10:28]:
> * Kishon Vijay Abraham I <kishon at ti.com> [130423 08:15]:
> > >>>2. MUSB fails with legacy booting and DT on panda es
> > >>>
> > >>>With both legacy and DT booting I get something like:
> > >>>
> > >>>HS USB OTG: no transceiver configured
> > >>>musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with status -517
> > >>
> > >>The dt should work fine with https://patchwork.kernel.org/patch/2423061/.
> > >
> > >OK thanks for checking that.
> > >
> > >>But non-dt has got a real issue. We were using usb_bind_phy() for
> > >>binding the controller with the PHY (we use device names). But in
> > >>linux-next the device names have changed because of using
> > >>PLATFORM_DEVID_AUTO. We can modify the usb_bind_phy() calls to use
> > >>the new device names, But I suspect the device names can change
> > >>again. Not sure what we can do here :-(
> > >
> > >Let's do a minimal fix for v3.10. Then we'll make omap4 DT only for
> > >v3.11 and that problem is solved for good.
> > 
> > Have posted a patch https://patchwork.kernel.org/patch/2475521/ for
> > getting MUSB functional in omap4 panda.
> 
> OK thanks. Paul it seems that this patch is still queued in one of
> your branches?
> 
> Let me know if you want me to pick that one up for fixes for the
> merge window, or if you have multiple patches to pull.

Oops this I already have sitting in omap-for-v3.9-rc6/fixes.. Let's
see if that can still get merged. Looks like I forgot to send off
that one, sorry about that.

Regards,

Tony


From tony at atomide.com  Tue Apr 23 17:45:45 2013
From: tony at atomide.com (Tony Lindgren)
Date: Tue, 23 Apr 2013 14:45:45 -0700
Subject: [GIT PULL] musb regression on omap4 for v3.9
Message-ID: <20130423214544.GN10155@atomide.com>


The following changes since commit 31880c37c11e28cb81c70757e38392b42e695dc6:

  Linux 3.9-rc6 (2013-04-07 20:49:54 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.9-rc6/fixes-signed

for you to fetch changes up to f4d7a536faa43f30d87f701268db76b8433a2a8b:

  ARM: OMAP4: hwmod data: make 'ocp2scp_usb_phy_phy_48m" as the main clock (2013-04-10 13:26:07 -0700)

----------------------------------------------------------------
One MUSB regression fix that I forgot to send earlier. Without
this MUSB no longer works on omap4 based devices.

----------------------------------------------------------------
Kishon Vijay Abraham I (1):
      ARM: OMAP4: hwmod data: make 'ocp2scp_usb_phy_phy_48m" as the main clock

 arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 18 +++++++++++-------
 1 file changed, 11 insertions(+), 7 deletions(-)


From linux at arm.linux.org.uk  Tue Apr 23 17:46:10 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Tue, 23 Apr 2013 22:46:10 +0100
Subject: [PATCH v4 00/15] multi-cluster power management
In-Reply-To: <alpine.LFD.2.03.1304231657150.17375@syhkavp.arg>
References: <1360041732-17936-1-git-send-email-nicolas.pitre@linaro.org>
 <20130423200429.GF5316@n2100.arm.linux.org.uk>
 <alpine.LFD.2.03.1304231657150.17375@syhkavp.arg>
Message-ID: <20130423214610.GY14496@n2100.arm.linux.org.uk>

On Tue, Apr 23, 2013 at 05:03:06PM -0400, Nicolas Pitre wrote:
> On Tue, 23 Apr 2013, Russell King - ARM Linux wrote:
> 
> > What I suggest for the time being is to provide new inline function(s)
> > in arch/arm/include/cacheflush.h which are purposed for your application,
> > document them in that file, and call the implementation you're currently
> > using.  That means if we do have to change it in the future (for example,
> > we don't need to do anything in the dcache flushing stuff) we don't have
> > to hunt through all the code to find _your_ different use of that function
> > and fix it - we can just fix it in one place and we have the reference
> > there for what your code expects.
> 
> What about the patch below?  Once you tell me it is fine to you I'll 
> adapt the MCPM series to it.

Yes, that looks like a saner solution.  Thanks.


From catalin.marinas at arm.com  Tue Apr 23 17:54:31 2013
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Tue, 23 Apr 2013 22:54:31 +0100
Subject: ARM: 7684/1: errata: Workaround for Cortex-A15 erratum 798181
 (TLBI/DSB operations)
In-Reply-To: <20130423100332.GA23407@arm.com>
References: <alpine.LFD.2.03.1304221641340.17375@syhkavp.arg>
 <20130423100332.GA23407@arm.com>
Message-ID: <20130423215431.GA46270@MacBook-Pro.local>

On Tue, Apr 23, 2013 at 11:03:32AM +0100, Catalin Marinas wrote:
> On Mon, Apr 22, 2013 at 10:29:32PM +0100, Nicolas Pitre wrote:
> > The kernel spits out this on every fork():
> > 
> > BUG: using smp_processor_id() in preemptible [00000000] code: bash/1419
> > caller is broadcast_tlb_mm_a15_erratum+0x94/0xfc
> > [<c0014640>] (unwind_backtrace+0x0/0xf8) from [<c02074ec>] (debug_smp_processor_id+0xc4/0xe8)
> > [<c02074ec>] (debug_smp_processor_id+0xc4/0xe8) from [<c0013a3c>] (broadcast_tlb_mm_a15_erratum+0x94/0xfc)
> > [<c0013a3c>] (broadcast_tlb_mm_a15_erratum+0x94/0xfc) from [<c0020f28>] (dup_mm+0x30c/0x41c)
> > [<c0020f28>] (dup_mm+0x30c/0x41c) from [<c00217a4>] (copy_process.part.56+0x724/0xe20)
> > [<c00217a4>] (copy_process.part.56+0x724/0xe20) from [<c0021f54>] (do_fork+0x90/0x320)
> > [<c0021f54>] (do_fork+0x90/0x320) from [<c000e240>] (ret_fast_syscall+0x0/0x30)
> 
> So it needs preemption disabled, see below.
> 
> I'll double-check with the hardware guys whether the dummy TLBI can
> happen on any CPU (if we get preempted), otherwise I'll have to disable
> the preemption around both the local_flush_tlb_*() and broadcast_tlb_*()
> functions.

It looks like we have a slight problem even without this erratum. The
TLB invalidate and subsequent DSB must take place on the same CPU,
otherwise there is no guarantee that the broadcast TLB operation has
been completed on the other CPUs. We may get a DSB as part of a
spin_unlock during thread switching but it's safer to either add an
explicit DSB via __switch_to() or disable preemption during
flush_tlb_*() operations. I would go for the former since we have a
similar situation with cache maintenance. I'll check tomorrow.

-- 
Catalin


From nicolas.pitre at linaro.org  Tue Apr 23 17:56:03 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Tue, 23 Apr 2013 17:56:03 -0400 (EDT)
Subject: [PATCH v4 00/15] multi-cluster power management
In-Reply-To: <20130423214610.GY14496@n2100.arm.linux.org.uk>
References: <1360041732-17936-1-git-send-email-nicolas.pitre@linaro.org>
 <20130423200429.GF5316@n2100.arm.linux.org.uk>
 <alpine.LFD.2.03.1304231657150.17375@syhkavp.arg>
 <20130423214610.GY14496@n2100.arm.linux.org.uk>
Message-ID: <alpine.LFD.2.03.1304231755370.17375@syhkavp.arg>

On Tue, 23 Apr 2013, Russell King - ARM Linux wrote:

> On Tue, Apr 23, 2013 at 05:03:06PM -0400, Nicolas Pitre wrote:
> > On Tue, 23 Apr 2013, Russell King - ARM Linux wrote:
> > 
> > > What I suggest for the time being is to provide new inline function(s)
> > > in arch/arm/include/cacheflush.h which are purposed for your application,
> > > document them in that file, and call the implementation you're currently
> > > using.  That means if we do have to change it in the future (for example,
> > > we don't need to do anything in the dcache flushing stuff) we don't have
> > > to hunt through all the code to find _your_ different use of that function
> > > and fix it - we can just fix it in one place and we have the reference
> > > there for what your code expects.
> > 
> > What about the patch below?  Once you tell me it is fine to you I'll 
> > adapt the MCPM series to it.
> 
> Yes, that looks like a saner solution.  Thanks.

May I add your ACK to the patch?


Nicolas


From daniel.lezcano at linaro.org  Tue Apr 23 18:04:13 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Wed, 24 Apr 2013 00:04:13 +0200
Subject: [PATCH 07/21] ARM: tegra: unify tegra_idle_device definitions
In-Reply-To: <201304232057.37055.arnd@arndb.de>
References: <1366734653-488286-1-git-send-email-arnd@arndb.de>
 <1366734653-488286-8-git-send-email-arnd@arndb.de>
 <5176BD29.1000405@linaro.org> <201304232057.37055.arnd@arndb.de>
Message-ID: <5177055D.1060307@linaro.org>

On 04/23/2013 08:57 PM, Arnd Bergmann wrote:
> On Tuesday 23 April 2013, Daniel Lezcano wrote:
>> the patch sounds good but I think the side effect of the consolidation
>> patchset [1] fixed that.
>>
>> You can find these fixes in Rafael's tree:
>>
>> https://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/commit/?h=linux-next&amp;id=4c637b2175a0dc65d533494225525c6c82d73293
>>
>> https://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/commit/?h=linux-next&amp;id=e158f9da6974cc11bfab2246a9b10021af0e0d8a
>>
>> https://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/commit/?h=linux-next&amp;id=c5106c9dea9a6022ab84c6cb1d4a0b19fc5af0e2
>>
>> https://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/commit/?h=linux-next&amp;id=f040c26ffaa5e56f2bca427c719c9601a02e70e5
>>
>> [1] http://www.spinics.net/lists/arm-kernel/msg239811.html
>>
> 
> Ah. Is that not in linux-next? I created the patch today based on the latest
> linux-next from today (Tuesday).

Ah, ok. Actually the patches were taken by Rafael right today. So it is
possible the changes were not reflected in linux-next yet.


-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From arno at natisbad.org  Tue Apr 23 18:05:43 2013
From: arno at natisbad.org (Arnaud Ebalard)
Date: Wed, 24 Apr 2013 00:05:43 +0200
Subject: [PATCHv1 0/3] hwmon: GMT G72/G763 PWM fan controller
References: <cover.1366322287.git.arno@natisbad.org>
 <4f4a821bbc61e2da28fd70553fd717ada255097d.1366322287.git.arno@natisbad.org>
 <20130419043555.GA14124@roeck-us.net>
Message-ID: <cover.1366753420.git.arno@natisbad.org>

Hi,

This series adds support for GMT G762/G763. This work is based on a
basic version for 2.6.31 kernel developed Olivier Mouchet (kept as
author for this reason in g762.c) for LaCie NAS. Updates have been
performed to run on recent kernels. Supported has been completed and
additional features added: ability to configure various characteristics
from .dts file, better initialization, alarms and error reporting
support, gear mode, polarity, fan pulse per revolution, fan startup
voltage control. The following detailed datasheet has been used as a
basis for this work:

  http://natisbad.org/NAS/refs/GMT_EDS-762_763-080710-0.2.pdf

The patch was developed for and tested against the GMT G762 fan
controller used in a Netgear ReadyNAS Duo v2 (kirkwood 88F6282-based
NAS). This is the main reason for the device tree bindings provided in
first patch. The patches are against current ARM tree; tell me if you
need me to rebase it against something else.

Patch 2 and 3 provides documentation for the driver and DT bindings, 
respectively.

I hope the comments provided on v0 have all been correctly taken into
account. A list of changes is provided below.

Comments welcome,

Cheers,

a+

Changes since v0:
    Removed forward declaration 
    Used bool for 'valid' field instead of bit field.
    Protected macro args
    Fixed typo in subject line
    Added mention for G763 support in Kconfig
    Fixed typo in driver name in Kconfig
    Do not use DRVNAME in i2c_device_id g762_id[] 
    Following discussions, kept DEVICE_ATTR (i.e. no switch to SENSOR_DEVICE_ATTR)
    Removed useless casts when flipping bit values
    Sanity check user input value (e.g. to prevent 256 to silenty become 0)
    Added extra lines for multiline comments when needed
    Removed various testing knobs
    Make removed knobs available via DT
    Passed checkpatch script on the patch
    Removed useless lock protection againt clk setting
    Moved all setter at the beginning of the file
    Removed bad (u16) casts in g762_write_value() calls
    Added config structure and helpers
    Provide specific helper to overload config from dts


Arnaud Ebalard (3):
  Add support for GMT G762/G763 PWM fan controller
  Add documentation for g762 driver
  Add DT documentation for g762 driver

 Documentation/devicetree/bindings/hwmon/g762.txt |   57 ++
 Documentation/hwmon/g762                         |   67 ++
 drivers/hwmon/Kconfig                            |   10 +
 drivers/hwmon/Makefile                           |    1 +
 drivers/hwmon/g762.c                             | 1058 ++++++++++++++++++++++
 5 files changed, 1193 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/hwmon/g762.txt
 create mode 100644 Documentation/hwmon/g762
 create mode 100644 drivers/hwmon/g762.c

-- 
1.7.10.4



From arno at natisbad.org  Tue Apr 23 18:05:56 2013
From: arno at natisbad.org (Arnaud Ebalard)
Date: Wed, 24 Apr 2013 00:05:56 +0200
Subject: [PATCHv1 1/3] hwmon: Add support for GMT G762/G763 PWM fan controller
In-Reply-To: <cover.1366753420.git.arno@natisbad.org>
References: <cover.1366322287.git.arno@natisbad.org>
 <4f4a821bbc61e2da28fd70553fd717ada255097d.1366322287.git.arno@natisbad.org>
 <20130419043555.GA14124@roeck-us.net>
Message-ID: <63961d39aee9db94767f28fd441312bec2029473.1366753420.git.arno@natisbad.org>


Signed-off-by: Arnaud Ebalard <arno at natisbad.org>
Tested-by: Arnaud Ebalard <arno at natisbad.org>
---
 drivers/hwmon/Kconfig  |   10 +
 drivers/hwmon/Makefile |    1 +
 drivers/hwmon/g762.c   | 1058 ++++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 1069 insertions(+)
 create mode 100644 drivers/hwmon/g762.c

diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 89ac1cb..cb4879c 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -423,6 +423,16 @@ config SENSORS_G760A
 	  This driver can also be built as a module.  If so, the module
 	  will be called g760a.
 
+config SENSORS_G762
+	tristate "GMT G762 and G763"
+	depends on I2C
+	help
+	  If you say yes here you get support for Global Mixed-mode
+	  Technology Inc G762 and G763 fan speed PWM controller chips.
+
+	  This driver can also be built as a module.  If so, the module
+	  will be called g762.
+
 config SENSORS_GL518SM
 	tristate "Genesys Logic GL518SM"
 	depends on I2C
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index 8d6d97e..4b49504 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -57,6 +57,7 @@ obj-$(CONFIG_SENSORS_F75375S)	+= f75375s.o
 obj-$(CONFIG_SENSORS_FAM15H_POWER) += fam15h_power.o
 obj-$(CONFIG_SENSORS_FSCHMD)	+= fschmd.o
 obj-$(CONFIG_SENSORS_G760A)	+= g760a.o
+obj-$(CONFIG_SENSORS_G762)	+= g762.o
 obj-$(CONFIG_SENSORS_GL518SM)	+= gl518sm.o
 obj-$(CONFIG_SENSORS_GL520SM)	+= gl520sm.o
 obj-$(CONFIG_SENSORS_GPIO_FAN)	+= gpio-fan.o
diff --git a/drivers/hwmon/g762.c b/drivers/hwmon/g762.c
new file mode 100644
index 0000000..810b019
--- /dev/null
+++ b/drivers/hwmon/g762.c
@@ -0,0 +1,1058 @@
+/*
+ * g762 - Driver for the Global Mixed-mode Technology Inc. fan speed PWM
+ *        controller chips from G762 family, i.e. G762 and G763
+ *
+ * Copyright (C) 2013, Arnaud EBALARD <arno at natisbad.org>
+ *
+ * This work is based on a basic version for 2.6.31 kernel developed
+ * by Olivier Mouchet for LaCie NAS. Updates have been performed to run
+ * on recent kernels. Additional features have been added. Ability to
+ * configure various characteristics via .dts file has been added.
+ * Detailed datasheet on which this development is based is available
+ * here:
+ *
+ *  http://natisbad.org/NAS/refs/GMT_EDS-762_763-080710-0.2.pdf
+ *
+ * Headers from previous developments have been kept below:
+ *
+ * Copyright (c) 2009 LaCie
+ *
+ * Author: Olivier Mouchet <olivier.mouchet at gmail.com>
+ *
+ * based on g760a code written by Herbert Valerio Riedel <hvr at gnu.org>
+ * Copyright (C) 2007  Herbert Valerio Riedel <hvr at gnu.org>
+ *
+ * g762: minimal datasheet available at:
+ *       http://www.gmt.com.tw/product/datasheet/EDS-762_3.pdf
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+
+#include <linux/device.h>
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/slab.h>
+#include <linux/jiffies.h>
+#include <linux/i2c.h>
+#include <linux/hwmon.h>
+#include <linux/hwmon-sysfs.h>
+#include <linux/err.h>
+#include <linux/mutex.h>
+#include <linux/kernel.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+
+#define DRVNAME "g762"
+
+static const struct i2c_device_id g762_id[] = {
+	{ "g762", 0 },
+	{ "g763", 0 },
+	{ }
+};
+MODULE_DEVICE_TABLE(i2c, g762_id);
+
+enum g762_regs {
+	G762_REG_SET_CNT  = 0x00,
+	G762_REG_ACT_CNT  = 0x01,
+	G762_REG_FAN_STA  = 0x02,
+	G762_REG_SET_OUT  = 0x03,
+	G762_REG_FAN_CMD1 = 0x04,
+	G762_REG_FAN_CMD2 = 0x05,
+};
+
+/* Config register bits */
+#define G762_REG_FAN_CMD1_DET_FAN_FAIL  0x80 /* enable fan_fail signal */
+#define G762_REG_FAN_CMD1_DET_FAN_OOC   0x40 /* enable fan_out_of_control */
+#define G762_REG_FAN_CMD1_OUT_MODE      0x20 /* out mode, pwm or dac */
+#define G762_REG_FAN_CMD1_FAN_MODE      0x10 /* fan mode: close or open loop */
+#define G762_REG_FAN_CMD1_CLK_DIV_ID1   0x08 /* clock divisor value */
+#define G762_REG_FAN_CMD1_CLK_DIV_ID0   0x04
+#define G762_REG_FAN_CMD1_PWM_POLARITY  0x02 /* pwm polarity */
+#define G762_REG_FAN_CMD1_PULSE_PER_REV 0x01 /* pulse per fan revolution */
+
+#define G762_REG_FAN_CMD2_GEAR_MODE_1   0x08 /* fan gear mode */
+#define G762_REG_FAN_CMD2_GEAR_MODE_0   0x04
+#define G762_REG_FAN_CMD2_FAN_STARTV_1  0x02 /* fan startup voltage */
+#define G762_REG_FAN_CMD2_FAN_STARTV_0  0x01
+
+#define G762_REG_FAN_STA_FAIL           0x02 /* fan fail */
+#define G762_REG_FAN_STA_OOC            0x01 /* fan out of control */
+
+/* config register values */
+#define OUT_MODE_PWM            1
+#define OUT_MODE_DAC            0
+
+#define FAN_MODE_CLOSED_LOOP    2
+#define FAN_MODE_OPEN_LOOP      1
+
+/* register data is read (and cached) at most once per second */
+#define G762_UPDATE_INTERVAL (HZ)
+
+/*
+ * extract pulse count per fan revolution value (2 or 4) from given
+ * FAN_CMD1 register value
+ */
+#define PULSE_FROM_REG(reg) \
+	((((reg) & G762_REG_FAN_CMD1_PULSE_PER_REV)+1) << 1)
+
+/*
+ * extract fan clock divisor (1, 2, 4 or 8) from given FAN_CMD1
+ * register value
+ */
+#define CLKDIV_FROM_REG(reg) \
+	(1 << (((reg) & (G762_REG_FAN_CMD1_CLK_DIV_ID0 |	\
+			 G762_REG_FAN_CMD1_CLK_DIV_ID1)) >> 2))
+
+/*
+ * extract fan gear mode value (0, 1 or 2) from given FAN_CMD2
+ * register value
+ */
+#define GEARMODE_FROM_REG(reg) \
+	(1 << (((reg) & (G762_REG_FAN_CMD2_GEAR_MODE_0 |	\
+			 G762_REG_FAN_CMD2_GEAR_MODE_1)) >> 2))
+
+struct g762_data {
+	struct i2c_client *client;
+	struct device *hwmon_dev;
+
+	/* update mutex */
+	struct mutex update_lock;
+
+	/* board specific parameters. */
+	u32 clk; /* default 32kHz */
+
+	/* g762 register cache */
+	bool valid;
+	unsigned long last_updated; /* in jiffies */
+
+	u8 set_cnt;  /* RPM cmd in close loop control */
+	u8 act_cnt;  /* formula: cnt = (CLK * 30)/(rpm * P) */
+	u8 fan_sta;  /* bit 0: set when actual fan speed is more than
+		      *        25% outside requested fan speed
+		      * bit 1: set when no transition occurs on fan
+		      *        pin for 0.7s
+		      */
+	u8 set_out;  /* output voltage/PWM duty in open loop control */
+	u8 fan_cmd1; /*   0: FG_PLS_ID0 FG pulses count per revolution
+		      *      0: 2 counts per revolution
+		      *      1: 4 counts per revolution
+		      *   1: PWM_POLARITY 1: negative_duty
+		      *                   0: positive_duty
+		      * 2,3: [FG_CLOCK_ID0, FG_CLK_ID1]
+		      *         00: Divide fan clock by 1
+		      *         01: Divide fan clock by 2
+		      *         10: Divide fan clock by 4
+		      *         11: Divide fan clock by 8
+		      *   4: FAN_MODE 1:close-loop, 0:open-loop
+		      *   5: OUT_MODE 1:PWM, 0:DAC
+		      *   6: DET_FAN_OOC enable "fan ooc" status
+		      *   7: DET_FAN_FAIL enable "fan fail" status
+		      */
+	u8 fan_cmd2; /* 0,1: FAN_STARTV 0,1,2,3 -> 0,32,64,96 dac_code
+		      * 2,3: FG_GEAR_MODE
+		      *         00: div = 1
+		      *         01: div = 2
+		      *         10: div = 4
+		      *   4: Mask ALERT# (g763 only)
+		      */
+};
+
+/*
+ * sysfs PWM interface uses value from 0 to 255 when g762 FAN_SET_CNT register
+ * uses values from 255 (off) to 0 (full speed).
+ */
+#define PWM_FROM_CNT(cnt)	(0xff-(cnt))
+#define PWM_TO_CNT(pwm)		(0xff-(pwm))
+
+/*
+ * Convert count value from fan controller register into fan speed RPM value.
+ * Note that the datasheet documents a basic formula. Influence of additional
+ * parameters have been infered from examples in the datasheet and tests:
+ * fan clock divisor, fan gear mode.
+ */
+static inline unsigned int rpm_from_cnt(u8 cnt, u32 clk, u16 p,
+					u8 clk_div, u8 gear_mode)
+{
+	if (cnt == 0 || cnt == 0xff)
+		return 0;
+
+	return (clk*30*(gear_mode+1))/(cnt*p*clk_div);
+}
+
+/* Convert fan RPM value from sysfs into count value */
+static inline unsigned char cnt_from_rpm(u32 rpm, u32 clk, u16 p,
+					 u8 clk_div, u8 gear_mode)
+{
+	return (rpm == 0) ? 0xff : (clk*30*(gear_mode+1))/(rpm*p*clk_div);
+}
+
+static inline int g762_read_value(struct i2c_client *client,
+				  enum g762_regs reg)
+{
+	return i2c_smbus_read_byte_data(client, reg);
+}
+
+static inline int g762_write_value(struct i2c_client *client,
+				   enum g762_regs reg, u8 value)
+{
+	return i2c_smbus_write_byte_data(client, reg, value);
+}
+
+/* helper to grab and cache data, at most one time per second */
+static struct g762_data *g762_update_client(struct device *dev)
+{
+	struct i2c_client *client = to_i2c_client(dev);
+	struct g762_data *data = i2c_get_clientdata(client);
+
+	mutex_lock(&data->update_lock);
+	if (time_after(jiffies, data->last_updated + G762_UPDATE_INTERVAL) ||
+	    unlikely(!data->valid)) {
+		data->set_cnt =  g762_read_value(client, G762_REG_SET_CNT);
+		data->act_cnt =  g762_read_value(client, G762_REG_ACT_CNT);
+		data->fan_sta =  g762_read_value(client, G762_REG_FAN_STA);
+		data->set_out =  g762_read_value(client, G762_REG_SET_OUT);
+		data->fan_cmd1 = g762_read_value(client, G762_REG_FAN_CMD1);
+		data->fan_cmd2 = g762_read_value(client, G762_REG_FAN_CMD2);
+
+		data->last_updated = jiffies;
+		data->valid = 1;
+	}
+	mutex_unlock(&data->update_lock);
+
+	return data;
+}
+
+
+
+/*
+ * helpers for passing hardware characteristics via DT. Some of those
+ * are also used by sysfs handlers (write function) later in the file.
+ */
+
+
+/* Set pwm mode. Accepts either 0 (pwm mode) or 1 (linear mode) */
+static int do_set_pwm_mode(struct device *dev, unsigned long val)
+{
+	struct i2c_client *client = to_i2c_client(dev);
+	struct g762_data *data = g762_update_client(dev);
+	int ret = 0;
+
+	mutex_lock(&data->update_lock);
+	switch (val) {
+	case OUT_MODE_PWM:
+		data->fan_cmd1 |= G762_REG_FAN_CMD1_OUT_MODE;
+		break;
+	case OUT_MODE_DAC: /* i.e. linear mode */
+		data->fan_cmd1 &= ~G762_REG_FAN_CMD1_OUT_MODE;
+		break;
+	default:
+		ret = -EINVAL;
+		goto out;
+	}
+	g762_write_value(client, G762_REG_FAN_CMD1, data->fan_cmd1);
+ out:
+	mutex_unlock(&data->update_lock);
+
+	return ret;
+}
+
+/*
+ * Set reference clock. Accepted values are between 0 and 0xffffff.
+ * Note that this is an internal parameter, i.e. value is not passed
+ * to the device.
+ */
+static int do_set_pwm_freq(struct device *dev, unsigned long val)
+{
+	struct i2c_client *client = to_i2c_client(dev);
+	struct g762_data *data = i2c_get_clientdata(client);
+	int ret = -EINVAL;
+
+	if (val <= 0xffffff) {
+		data->clk = val;
+		ret = 0;
+	}
+
+	return ret;
+}
+
+/* Set fan clock divisor. Accepted values are 1, 2, 4 and 8. */
+static int do_set_fan_div(struct device *dev, unsigned long val)
+{
+	struct i2c_client *client = to_i2c_client(dev);
+	struct g762_data *data = g762_update_client(dev);
+	int ret = 0;
+
+	mutex_lock(&data->update_lock);
+	switch (val) {
+	case 1:
+		data->fan_cmd1 &= ~G762_REG_FAN_CMD1_CLK_DIV_ID0;
+		data->fan_cmd1 &= ~G762_REG_FAN_CMD1_CLK_DIV_ID1;
+		break;
+	case 2:
+		data->fan_cmd1 |=  G762_REG_FAN_CMD1_CLK_DIV_ID0;
+		data->fan_cmd1 &= ~G762_REG_FAN_CMD1_CLK_DIV_ID1;
+		break;
+	case 4:
+		data->fan_cmd1 &= ~G762_REG_FAN_CMD1_CLK_DIV_ID0;
+		data->fan_cmd1 |=  G762_REG_FAN_CMD1_CLK_DIV_ID1;
+		break;
+	case 8:
+		data->fan_cmd1 |=  G762_REG_FAN_CMD1_CLK_DIV_ID0;
+		data->fan_cmd1 |=  G762_REG_FAN_CMD1_CLK_DIV_ID1;
+		break;
+	default:
+		ret = -EINVAL;
+		goto out;
+	}
+	g762_write_value(client, G762_REG_FAN_CMD1, data->fan_cmd1);
+ out:
+	mutex_unlock(&data->update_lock);
+
+	return ret;
+}
+
+/* Set fan gear mode. Accepted values are either 0, 1 or 2. */
+static int do_set_fan_gear_mode(struct device *dev, unsigned long val)
+{
+	struct i2c_client *client = to_i2c_client(dev);
+	struct g762_data *data = g762_update_client(dev);
+	int ret = 0;
+
+	mutex_lock(&data->update_lock);
+	switch (val) {
+	case 0:
+		data->fan_cmd2 &= ~G762_REG_FAN_CMD2_GEAR_MODE_0;
+		data->fan_cmd2 &= ~G762_REG_FAN_CMD2_GEAR_MODE_1;
+		break;
+	case 1:
+		data->fan_cmd2 |=  G762_REG_FAN_CMD2_GEAR_MODE_0;
+		data->fan_cmd2 &= ~G762_REG_FAN_CMD2_GEAR_MODE_1;
+		break;
+	case 2:
+		data->fan_cmd2 &= ~G762_REG_FAN_CMD2_GEAR_MODE_0;
+		data->fan_cmd2 |=  G762_REG_FAN_CMD2_GEAR_MODE_1;
+		break;
+	default:
+		ret = -EINVAL;
+		goto out;
+	}
+	g762_write_value(client, G762_REG_FAN_CMD2, data->fan_cmd2);
+ out:
+	mutex_unlock(&data->update_lock);
+
+	return ret;
+}
+
+/* Set pulse per revolution value. Accepts either 2 or 4. */
+static int do_set_fan_pulses(struct device *dev, unsigned long val)
+{
+	struct i2c_client *client = to_i2c_client(dev);
+	struct g762_data *data = g762_update_client(dev);
+	int ret = 0;
+
+	mutex_lock(&data->update_lock);
+	switch (val) {
+	case 2:
+		data->fan_cmd1 &= ~G762_REG_FAN_CMD1_PULSE_PER_REV;
+		break;
+	case 4:
+		data->fan_cmd1 |=  G762_REG_FAN_CMD1_PULSE_PER_REV;
+		break;
+	default:
+		ret = -EINVAL;
+		goto out;
+	}
+	g762_write_value(client, G762_REG_FAN_CMD1, data->fan_cmd1);
+ out:
+	mutex_unlock(&data->update_lock);
+
+	return ret;
+}
+
+/* Set fan mode. Accepts either 1 (open loop) or 2 (closed loop). */
+static int do_set_pwm_enable(struct device *dev, unsigned long val)
+{
+	struct i2c_client *client = to_i2c_client(dev);
+	struct g762_data *data = g762_update_client(dev);
+	int ret = 0;
+
+	mutex_lock(&data->update_lock);
+	switch (val) {
+	case FAN_MODE_OPEN_LOOP:
+		data->fan_cmd1 &= ~G762_REG_FAN_CMD1_FAN_MODE;
+		break;
+	case FAN_MODE_CLOSED_LOOP:
+		data->fan_cmd1 |=  G762_REG_FAN_CMD1_FAN_MODE;
+		break;
+	default:
+		ret = -EINVAL;
+		goto out;
+	}
+
+	g762_write_value(client, G762_REG_FAN_CMD1, data->fan_cmd1);
+ out:
+	mutex_unlock(&data->update_lock);
+
+	return ret;
+}
+
+/* Set pwm polarity (0 for negative duty, 1 for positive duty) */
+static int do_set_pwm_polarity(struct device *dev, unsigned long val)
+{
+	struct i2c_client *client = to_i2c_client(dev);
+	struct g762_data *data = g762_update_client(dev);
+	int ret = 0;
+
+	mutex_lock(&data->update_lock);
+	switch (val) {
+	case 0: /* i.e. negative duty */
+		data->fan_cmd1 &= ~G762_REG_FAN_CMD1_PWM_POLARITY;
+		break;
+	case 1: /* i.e. positive duty */
+		data->fan_cmd1 |=  G762_REG_FAN_CMD1_PWM_POLARITY;
+		break;
+	default:
+		ret = -EINVAL;
+		goto out;
+	}
+	g762_write_value(client, G762_REG_FAN_CMD1, data->fan_cmd1);
+ out:
+	mutex_unlock(&data->update_lock);
+
+	return ret;
+}
+
+/*
+ * Set pwm value. Accepted values are between 0 and 255. Note that the
+ * internal register used for setting the value depends ont the fan
+ * mode of the device.
+ */
+static int do_set_pwm(struct device *dev, unsigned long val)
+{
+	struct i2c_client *client = to_i2c_client(dev);
+	struct g762_data *data = g762_update_client(dev);
+	int ret = -EINVAL;
+
+	mutex_lock(&data->update_lock);
+	if (val > 255)
+		goto out;
+
+	if (data->fan_cmd1 & G762_REG_FAN_CMD1_FAN_MODE) { /* closed-loop */
+		data->set_cnt = PWM_TO_CNT(val);
+		g762_write_value(client, G762_REG_SET_CNT, (u8)val);
+	} else {                                           /* open-loop */
+		data->set_out = val;
+		g762_write_value(client, G762_REG_SET_OUT, (u8)val);
+	}
+
+	ret = 0;
+ out:
+	mutex_unlock(&data->update_lock);
+
+	return ret;
+}
+
+/* Set fan RPM value. This only makes sense in closed-loop mode. */
+static int do_set_fan_target(struct device *dev, unsigned long val)
+{
+	struct i2c_client *client = to_i2c_client(dev);
+	struct g762_data *data = g762_update_client(dev);
+	int ret = -EINVAL;
+
+	mutex_lock(&data->update_lock);
+	if (data->fan_cmd1 & G762_REG_FAN_CMD1_FAN_MODE) { /* closed-loop */
+		data->set_cnt = cnt_from_rpm(val, data->clk,
+					     PULSE_FROM_REG(data->fan_cmd1),
+					     CLKDIV_FROM_REG(data->fan_cmd1),
+					     GEARMODE_FROM_REG(data->fan_cmd2));
+		g762_write_value(client, G762_REG_SET_CNT, data->set_cnt);
+		ret = 0;
+	}
+	mutex_unlock(&data->update_lock);
+
+	return ret;
+}
+
+/* Enable/disable fan failure detection. Accepted values are 1 and 0. */
+static int do_fan_failure_detection_toggle(struct device *dev,
+					   unsigned long enable)
+{
+	struct i2c_client *client = to_i2c_client(dev);
+	struct g762_data *data = g762_update_client(dev);
+	int ret = 0;
+
+	mutex_lock(&data->update_lock);
+	switch (enable) {
+	case 0:
+		data->fan_cmd1 &= ~G762_REG_FAN_CMD1_DET_FAN_FAIL;
+		break;
+	case 1:
+		data->fan_cmd1 |=  G762_REG_FAN_CMD1_DET_FAN_FAIL;
+		break;
+	default:
+		ret = -EINVAL;
+		goto out;
+	}
+	g762_write_value(client, G762_REG_FAN_CMD1, data->fan_cmd1);
+ out:
+	mutex_unlock(&data->update_lock);
+
+	return ret;
+}
+
+/* Enable/disable fan out of control detection. Accepted values are 1 and 0 */
+static int do_fan_ooc_detection_toggle(struct device *dev, unsigned int enable)
+{
+	struct i2c_client *client = to_i2c_client(dev);
+	struct g762_data *data = g762_update_client(dev);
+	int ret = 0;
+
+	mutex_lock(&data->update_lock);
+	switch (enable) {
+	case 0:
+		data->fan_cmd1 &= ~G762_REG_FAN_CMD1_DET_FAN_OOC;
+		break;
+	case 1:
+		data->fan_cmd1 |=  G762_REG_FAN_CMD1_DET_FAN_OOC;
+		break;
+	default:
+		ret = -EINVAL;
+		goto out;
+	}
+	g762_write_value(client, G762_REG_FAN_CMD1, data->fan_cmd1);
+ out:
+	mutex_unlock(&data->update_lock);
+
+	return ret;
+}
+
+/* Set startup voltage. Accepted values are either 0, 1, 2 or 3. */
+static int do_set_fan_startv(struct device *dev, unsigned long val)
+{
+	struct i2c_client *client = to_i2c_client(dev);
+	struct g762_data *data = g762_update_client(dev);
+	int ret = 0;
+
+	mutex_lock(&data->update_lock);
+	switch (val) {
+	case 0:
+		data->fan_cmd2 &= ~G762_REG_FAN_CMD2_FAN_STARTV_0;
+		data->fan_cmd2 &= ~G762_REG_FAN_CMD2_FAN_STARTV_1;
+		break;
+	case 1:
+		data->fan_cmd2 |=  G762_REG_FAN_CMD2_FAN_STARTV_0;
+		data->fan_cmd2 &= ~G762_REG_FAN_CMD2_FAN_STARTV_1;
+		break;
+	case 2:
+		data->fan_cmd2 &= ~G762_REG_FAN_CMD2_FAN_STARTV_0;
+		data->fan_cmd2 |=  G762_REG_FAN_CMD2_FAN_STARTV_1;
+		break;
+	case 3:
+		data->fan_cmd2 |=  G762_REG_FAN_CMD2_FAN_STARTV_0;
+		data->fan_cmd2 |=  G762_REG_FAN_CMD2_FAN_STARTV_1;
+		break;
+	default:
+		ret = -EINVAL;
+		goto out;
+	}
+	g762_write_value(client, G762_REG_FAN_CMD2, data->fan_cmd2);
+ out:
+	mutex_unlock(&data->update_lock);
+
+	return ret;
+}
+
+
+
+/*
+ * Configuration-related definitions
+ */
+
+struct g762_config {
+	u32 fan_startv;
+	u32 fan_gear_mode;
+	u32 fan_div;
+	u32 fan_pulses;
+	u32 fan_target;
+	u32 pwm_polarity;
+	u32 pwm_enable;
+	u32 pwm_freq;
+	u32 pwm_mode;
+};
+
+/*
+ * g762 default values: it is assumed that the fan is set for a 32KHz clock
+ * source, a fan clock divisor of 1 and two pulses per revolution. Default
+ * fan driving mode is linear mode (g762/g763 also support PWM mode). Note
+ * the specific init value for properties which may be left unmodified.
+ */
+#define G762_DEFAULT_CLK            32768
+#define G762_DEFAULT_FAN_DIV        1
+#define G762_DEFAULT_FAN_PULSES     2
+#define G762_DEFAULT_OUT_MODE       0
+#define G762_DEFAULT_FAN_MODE       2
+#define G762_DEFAULT_FAN_STARTV     1
+#define G762_DEFAULT_FAN_GEAR_MODE  0
+#define G762_DEFAULT_FAN_POLARITY   0
+#define G762_UNTOUCHED_VAL          0xffffffff
+
+static void g762_config_init(struct g762_config *conf)
+{
+	conf->pwm_enable = G762_DEFAULT_FAN_MODE;
+	conf->pwm_mode = G762_DEFAULT_OUT_MODE;
+	conf->pwm_freq = G762_DEFAULT_CLK;
+	conf->pwm_polarity = G762_DEFAULT_FAN_POLARITY;
+	conf->fan_pulses = G762_DEFAULT_FAN_PULSES;
+	conf->fan_div = G762_DEFAULT_FAN_DIV;
+	conf->fan_startv = G762_DEFAULT_FAN_STARTV;
+	conf->fan_gear_mode = G762_DEFAULT_FAN_GEAR_MODE;
+	conf->fan_target = G762_UNTOUCHED_VAL;
+}
+
+static inline int g762_one_prop_commit(struct i2c_client *client,
+				       u32 pval, const char *pname,
+				       int (*psetter)(struct device *dev,
+						      unsigned long val))
+{
+	int ret = 0;
+
+	if ((pval != G762_UNTOUCHED_VAL) && (*psetter)(&client->dev, pval)) {
+		dev_info(&client->dev, "unable to set %s (%d)\n", pname, pval);
+		ret = -EINVAL;
+	}
+
+	return ret;
+}
+
+static int g762_config_commit(struct i2c_client *client,
+			      struct g762_config *conf)
+{
+	int ret = 0;
+
+	if (g762_one_prop_commit(client, conf->pwm_mode,
+				 "pwm_mode", &do_set_pwm_mode) ||
+	    g762_one_prop_commit(client, conf->pwm_enable,
+				 "pwm_enable", &do_set_pwm_enable) ||
+	    g762_one_prop_commit(client, conf->fan_div,
+				 "fan_div", &do_set_fan_div) ||
+	    g762_one_prop_commit(client, conf->fan_pulses,
+				 "fan_pulses", &do_set_fan_pulses) ||
+	    g762_one_prop_commit(client, conf->pwm_freq,
+				 "pwm_freq", &do_set_pwm_freq) ||
+	    g762_one_prop_commit(client, conf->fan_gear_mode,
+				 "fan_gear_mode", &do_set_fan_gear_mode) ||
+	    g762_one_prop_commit(client, conf->pwm_polarity,
+				 "pwm_polarity", &do_set_pwm_polarity) ||
+	    g762_one_prop_commit(client, conf->fan_startv,
+				 "fan_startv", &do_set_fan_startv) ||
+	    g762_one_prop_commit(client, conf->fan_target,
+				 "fan_target", &do_set_fan_target)) {
+		ret = -EINVAL;
+	}
+
+	return ret;
+}
+
+
+/*
+ * Helpers to import hardware characteristics from .dts file and overload
+ * default config values.
+ */
+
+#ifdef CONFIG_OF
+static struct of_device_id g762_dt_match[] = {
+	{ .compatible = "gmt,g762" },
+	{ .compatible = "gmt,g763" },
+	{ },
+};
+
+static inline void g762_of_import_one_prop(struct i2c_client *client,
+					   u32 *dest, const char *pname)
+{
+	const __be32 *prop;
+	int len;
+
+	prop = of_get_property(client->dev.of_node, pname, &len);
+	if (prop && len == sizeof(u32)) {
+		*dest = be32_to_cpu(prop[0]);
+		dev_info(&client->dev, "found %s (%d)\n", pname, *dest);
+	}
+}
+
+static void g762_config_of_overload(struct i2c_client *client,
+				    struct g762_config *conf)
+{
+	if (!client->dev.of_node)
+		return;
+
+	g762_of_import_one_prop(client, &conf->fan_gear_mode, "fan_gear_mode");
+	g762_of_import_one_prop(client, &conf->pwm_polarity, "pwm_polarity");
+	g762_of_import_one_prop(client, &conf->fan_startv, "fan_startv");
+	g762_of_import_one_prop(client, &conf->pwm_freq, "pwm_freq");
+	g762_of_import_one_prop(client, &conf->fan_div, "fan_div");
+	g762_of_import_one_prop(client, &conf->fan_pulses, "fan_pulses");
+	g762_of_import_one_prop(client, &conf->pwm_mode, "pwm_mode");
+	g762_of_import_one_prop(client, &conf->fan_target, "fan_target");
+	g762_of_import_one_prop(client, &conf->pwm_enable, "pwm_enable");
+}
+#else
+static void g762_config_of_overload(struct i2c_client *client,
+				    struct g762_config *conf) { };
+#endif
+
+
+
+/*
+ * sysfs attributes
+ */
+
+
+/*
+ * Read function for fan1_input sysfs file. Return current fan RPM value, or
+ * 0 if fan is out of control
+ */
+static ssize_t get_fan_rpm(struct device *dev, struct device_attribute *da,
+			   char *buf)
+{
+	struct g762_data *data = g762_update_client(dev);
+	unsigned int rpm = 0;
+
+	mutex_lock(&data->update_lock);
+	/* reverse logic: fan out of control reporting is enabled low */
+	if (data->fan_sta & G762_REG_FAN_STA_OOC) {
+		rpm = rpm_from_cnt(data->act_cnt, data->clk,
+				   PULSE_FROM_REG(data->fan_cmd1),
+				   CLKDIV_FROM_REG(data->fan_cmd1),
+				   GEARMODE_FROM_REG(data->fan_cmd2));
+	}
+	mutex_unlock(&data->update_lock);
+
+	return sprintf(buf, "%u\n", rpm);
+}
+
+
+/*
+ * Read and write functions for pwm1_mode sysfs file. Get and set fan speed
+ * control mode i.e. pwm (1) or linear (0).
+ */
+static ssize_t get_pwm_mode(struct device *dev, struct device_attribute *da,
+			    char *buf)
+{
+	struct g762_data *data = g762_update_client(dev);
+	int pwm_mode;
+
+	pwm_mode = (data->fan_cmd1 & G762_REG_FAN_CMD1_OUT_MODE) ? 1 : 0;
+
+	return sprintf(buf, "%d\n", pwm_mode);
+}
+
+static ssize_t set_pwm_mode(struct device *dev, struct device_attribute *da,
+			    const char *buf, size_t count)
+{
+	unsigned long val;
+
+	if (kstrtoul(buf, 10, &val) || do_set_pwm_mode(dev, val))
+		return -EINVAL;
+
+	return count;
+}
+
+
+/*
+ * Read and write functions for fan1_div sysfs file. Get and set fan
+ * controller prescaler value
+ */
+static ssize_t get_fan_div(struct device *dev,
+			       struct device_attribute *da, char *buf)
+{
+	struct g762_data *data = g762_update_client(dev);
+
+	return sprintf(buf, "%d\n", CLKDIV_FROM_REG(data->fan_cmd1));
+}
+
+static ssize_t set_fan_div(struct device *dev,
+			       struct device_attribute *da,
+			       const char *buf, size_t count)
+{
+	unsigned long val;
+
+	if (kstrtoul(buf, 10, &val) || do_set_fan_div(dev, val))
+		return -EINVAL;
+
+	return count;
+}
+
+
+/*
+ * Following documentation about hwmon's sysfs interface, a pwm1_enable node
+ * should accept followings:
+ *
+ *  0 : no fan speed control (i.e. fan at full speed)
+ *  1 : manual fan speed control enabled (use pwm[1-*]) (open-loop)
+ *  2+: automatic fan speed control enabled (use fan[1-*]_enable)(close-loop)
+ *
+ * but we do not accept 0 as "no-control" mode is not supported by g762,
+ * -EINVAL is returned in this case.
+ */
+static ssize_t get_pwm_enable(struct device *dev,
+			      struct device_attribute *da, char *buf)
+{
+	struct g762_data *data = g762_update_client(dev);
+	int fan_mode;
+
+	fan_mode = (data->fan_cmd1 & G762_REG_FAN_CMD1_FAN_MODE) ? 2 : 1;
+
+	return sprintf(buf, "%d\n", fan_mode);
+}
+
+static ssize_t set_pwm_enable(struct device *dev,
+			      struct device_attribute *da,
+			      const char *buf, size_t count)
+{
+	unsigned long val;
+
+	if (kstrtoul(buf, 10, &val) || do_set_pwm_enable(dev, val))
+		return -EINVAL;
+
+	return count;
+}
+
+
+/*
+ * Get/set the fan speed in open-loop mode using pwm1 sysfs file. Speed is
+ * given as a relative value from 0 to 255, where 255 is maximum speed. Note
+ * that this is done by writing directly to the chip's DAC, it won't change
+ * the closed loop speed set by fan1_target. Also note that due to rounding
+ * errors it is possible that you don't read back exactly the value you have
+ * set.
+ */
+static ssize_t get_pwm(struct device *dev, struct device_attribute *da,
+		       char *buf)
+{
+	struct g762_data *data = g762_update_client(dev);
+	int val;
+
+	mutex_lock(&data->update_lock);
+	if (data->fan_cmd1 & G762_REG_FAN_CMD1_FAN_MODE) { /* closed-loop */
+		val = PWM_FROM_CNT(data->set_cnt);
+	} else {                                            /* open-loop */
+		val = data->set_out;
+	}
+	mutex_unlock(&data->update_lock);
+
+	return sprintf(buf, "%d\n", val);
+}
+
+static ssize_t set_pwm(struct device *dev, struct device_attribute *da,
+		       const char *buf, size_t count)
+{
+	unsigned long val;
+
+	if (kstrtoul(buf, 10, &val) || do_set_pwm(dev, val))
+		return -EINVAL;
+
+	return count;
+}
+
+
+/*
+ * Get/set the fan speed in closed-loop mode using fan1_target sysfs file. Speed
+ * is given as a rpm value, then G762 will automatically regulate the fan speed
+ * using pulses from fan tachometer.
+ *
+ * Refer to rpm_from_cnt implementation to get info about count number
+ * calculation.
+ *
+ * Also note that due to rounding errors it is possible that you don't read
+ * back exactly the value you have set.
+ */
+static ssize_t get_fan_target(struct device *dev, struct device_attribute *da,
+			      char *buf)
+{
+	struct g762_data *data = g762_update_client(dev);
+	unsigned int rpm;
+	ssize_t err;
+
+	mutex_lock(&data->update_lock);
+	if (data->fan_cmd1 & G762_REG_FAN_CMD1_FAN_MODE) { /* closed-loop */
+		rpm = rpm_from_cnt(data->set_cnt, data->clk,
+				   PULSE_FROM_REG(data->fan_cmd1),
+				   CLKDIV_FROM_REG(data->fan_cmd1),
+				   GEARMODE_FROM_REG(data->fan_cmd2));
+		err = sprintf(buf, "%u\n", rpm);
+	} else {                                           /* open-loop */
+		err = -EINVAL;
+	}
+	mutex_unlock(&data->update_lock);
+
+	return err;
+}
+
+static ssize_t set_fan_target(struct device *dev, struct device_attribute *da,
+			      const char *buf, size_t count)
+{
+	unsigned long val;
+
+	if (kstrtoul(buf, 10, &val) || do_set_fan_target(dev, val))
+		return -EINVAL;
+
+	return count;
+}
+
+
+/* read function for fan1_fault sysfs file. */
+static ssize_t get_fan_failure(struct device *dev, struct device_attribute *da,
+			       char *buf)
+{
+	struct g762_data *data = g762_update_client(dev);
+	unsigned int val;
+
+	val = (data->fan_sta & G762_REG_FAN_STA_FAIL) ? 1 : 0;
+
+	return sprintf(buf, "%u\n", val);
+}
+
+
+/* read function for fan1_alarm sysfs file. */
+static ssize_t get_fan_ooc(struct device *dev, struct device_attribute *da,
+			   char *buf)
+{
+	struct g762_data *data = g762_update_client(dev);
+	unsigned int val;
+
+	/* ooc condition is enabled low */
+	val = (data->fan_sta & G762_REG_FAN_STA_OOC) ? 0 : 1;
+
+	return sprintf(buf, "%u\n", val);
+}
+
+
+static DEVICE_ATTR(pwm1, S_IWUSR | S_IRUGO,
+		   get_pwm, set_pwm);
+static DEVICE_ATTR(pwm1_mode, S_IWUSR | S_IRUGO,
+		   get_pwm_mode, set_pwm_mode);
+static DEVICE_ATTR(pwm1_enable, S_IWUSR | S_IRUGO,
+		   get_pwm_enable, set_pwm_enable);
+
+static DEVICE_ATTR(fan1_input, S_IRUGO,
+		   get_fan_rpm, NULL);
+static DEVICE_ATTR(fan1_alarm, S_IRUGO,
+		   get_fan_ooc, NULL);
+static DEVICE_ATTR(fan1_fault, S_IRUGO,
+		   get_fan_failure, NULL);
+static DEVICE_ATTR(fan1_target, S_IWUSR | S_IRUGO,
+		   get_fan_target, set_fan_target);
+static DEVICE_ATTR(fan1_div, S_IWUSR | S_IRUGO,
+		   get_fan_div, set_fan_div);
+
+/* Driver data */
+static struct attribute *g762_attributes[] = {
+	&dev_attr_fan1_input.attr,
+	&dev_attr_fan1_alarm.attr,
+	&dev_attr_fan1_fault.attr,
+	&dev_attr_fan1_target.attr,
+	&dev_attr_fan1_div.attr,
+	&dev_attr_pwm1.attr,
+	&dev_attr_pwm1_mode.attr,
+	&dev_attr_pwm1_enable.attr,
+	NULL
+};
+
+static const struct attribute_group g762_group = {
+	.attrs = g762_attributes,
+};
+
+static int g762_probe(struct i2c_client *client, const struct i2c_device_id *id)
+{
+	struct g762_data *data;
+	struct g762_config conf;
+	int err = 0;
+
+	if (!i2c_check_functionality(client->adapter,
+				     I2C_FUNC_SMBUS_BYTE_DATA)) {
+		err = -ENODEV;
+		goto out;
+	}
+
+	data = devm_kzalloc(&client->dev, sizeof(struct g762_data), GFP_KERNEL);
+	if (!data) {
+		err = -ENOMEM;
+		goto out;
+	}
+	i2c_set_clientdata(client, data);
+
+	data->client = client;
+	mutex_init(&data->update_lock);
+
+	/* Enable fan protection and fan fail detection by default */
+	do_fan_ooc_detection_toggle(&client->dev, 1);
+	do_fan_failure_detection_toggle(&client->dev, 1);
+
+	/*
+	 * Set default configuration values before passing the structure
+	 * to OF helpers to overload them using those provided by .dts
+	 * file (if any). Final config is then commited.
+	 */
+	g762_config_init(&conf);
+	g762_config_of_overload(client, &conf);
+	err = g762_config_commit(client, &conf);
+	if (err)
+		goto out;
+
+	/* Register sysfs hooks */
+	err = sysfs_create_group(&client->dev.kobj, &g762_group);
+	if (err)
+		goto out;
+
+	data->hwmon_dev = (struct device *)hwmon_device_register(&client->dev);
+	if (IS_ERR(data->hwmon_dev)) {
+		err = PTR_ERR(data->hwmon_dev);
+		sysfs_remove_group(&client->dev.kobj, &g762_group);
+		goto out;
+	}
+
+	dev_info(&data->client->dev, "device successfully initialized\n");
+
+ out:
+	return err;
+}
+
+static int g762_remove(struct i2c_client *client)
+{
+	struct g762_data *data = i2c_get_clientdata(client);
+
+	hwmon_device_unregister(data->hwmon_dev);
+	sysfs_remove_group(&client->dev.kobj, &g762_group);
+
+	dev_info(&data->client->dev, "device successfully removed\n");
+	return 0;
+}
+
+static struct i2c_driver g762_driver = {
+	.driver = {
+		.name = DRVNAME,
+		.owner = THIS_MODULE,
+		.of_match_table = of_match_ptr(g762_dt_match),
+	},
+	.probe	  = g762_probe,
+	.remove	  = g762_remove,
+	.id_table = g762_id,
+};
+
+module_i2c_driver(g762_driver);
+
+MODULE_AUTHOR("Olivier Mouchet <olivier.mouchet at gmail.com>");
+MODULE_DESCRIPTION("GMT G762 driver");
+MODULE_LICENSE("GPL");
-- 
1.7.10.4



From arno at natisbad.org  Tue Apr 23 18:06:08 2013
From: arno at natisbad.org (Arnaud Ebalard)
Date: Wed, 24 Apr 2013 00:06:08 +0200
Subject: [PATCHv1 2/3] hwmon: Add documentation for g762 driver
In-Reply-To: <cover.1366753420.git.arno@natisbad.org>
References: <cover.1366322287.git.arno@natisbad.org>
 <4f4a821bbc61e2da28fd70553fd717ada255097d.1366322287.git.arno@natisbad.org>
 <20130419043555.GA14124@roeck-us.net>
Message-ID: <24acd174f829d211f5d4c1b8631ffc3f8dd97910.1366753420.git.arno@natisbad.org>


Signed-off-by: Arnaud Ebalard <arno at natisbad.org>
---
 Documentation/hwmon/g762 |   67 ++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 67 insertions(+)
 create mode 100644 Documentation/hwmon/g762

diff --git a/Documentation/hwmon/g762 b/Documentation/hwmon/g762
new file mode 100644
index 0000000..5015829
--- /dev/null
+++ b/Documentation/hwmon/g762
@@ -0,0 +1,67 @@
+Kernel driver g762
+==================
+
+This documentation is based on G760a one, GMT G762 datasheet available
+at http://natisbad.org/NAS/ref/GMT_EDS-762_763-080710-0.2.pdf (used
+for the development of the driver) and sysfs bindings described in
+Documentation/hwmon/sysfs-interface.
+
+The GMT G762 Fan Speed PWM Controller is connected directly to a fan
+and performs closed-loop or open-loop control of the fan speed. Two
+modes - PWM or linear - are supported by the device.
+
+The following entries are available to the user in a subdirectory of
+/sys/bus/i2c/drivers/g762/ to control the operation of the device.
+This can be done manually using the following entries but is usually
+done via a userland daemon like fancontrol.
+
+Note that those entries do not provide ways to setup the specific
+hardware characteristics of the system (reference clock, pulses per
+fan revolution, ...); Those can be modified via devicetree bindings
+documented in Documentation/devicetree/bindings/hwmon/g762.txt.
+
+
+  fan1_target: set desired fan speed. This only makes sense in closed-loop
+            fan speed control (i.e. when pwm1_enable is set to 2).
+
+  fan1_input: provide current fan rotation value in RPM as reported by
+            the fan to the device.
+
+  fan1_div: fan clock divisor. Supported value are 1, 2, 4 and 8. Default
+            value is 1.
+
+  fan1_gear_mode: fan gear mode. Supported values are 0, 1 and 2. Default
+            value is 0. The value is a characteristic of the system
+            and a higher value can be set for more precisely control
+            fans with a high rotation speed. Note that this affects the
+            measurable speed range, not the read value.
+
+  fan1_fault: reports fan failure, i.e. no transition on fan gear pin for
+            about 0.7s (if the fan is not voluntarily set off).
+
+  fan1_alarm: in closed-loop control mode, if fan RPM value is 25% out
+            of the programmed value for over 6 seconds 'fan1_alarm' is
+            set to 1.
+
+  pwm1: get or set PWM fan control value. This is an integer value
+            between 0 and 255. 0 stops the fan, 255 makes it run at
+            full speed.
+
+  pwm1_enable: set current fan speed control mode i.e. 1 for manual fan
+            speed control (open-loop), 2 for automatic fan speed control
+            (closed-loop).
+
+  pwm1_mode: set or get fan driving mode: 1 for PWM mode, 0 for linear
+            mode. Default is linear mode.
+
+
+In PWM mode ('pwm1_mode' set to 1), the fan speed is programmed either by
+setting a value between 0 and 255 via 'pwm1' entry (0 stops the fan, 255
+makes it run at full speed). This can also be done by passing the
+expected RPM value via 'fan1_target'. Current fan speed value can be
+retrieved via 'fan1_input'. This fan speed value is computed based on
+the parameters associated with the physical characteristics of the
+system: a reference clock source frequency, a number of pulses per fan
+revolution, etc.
+
+Note that the driver will update its values at most once per second.
-- 
1.7.10.4



From arno at natisbad.org  Tue Apr 23 18:06:20 2013
From: arno at natisbad.org (Arnaud Ebalard)
Date: Wed, 24 Apr 2013 00:06:20 +0200
Subject: [PATCHv1 3/3] hwmon: Add DT documentation for g762 driver
In-Reply-To: <cover.1366753420.git.arno@natisbad.org>
References: <cover.1366322287.git.arno@natisbad.org>
 <4f4a821bbc61e2da28fd70553fd717ada255097d.1366322287.git.arno@natisbad.org>
 <20130419043555.GA14124@roeck-us.net>
Message-ID: <6ee748f450ba2a80c87aba08c0672105e2800f93.1366753420.git.arno@natisbad.org>


Signed-off-by: Arnaud Ebalard <arno at natisbad.org>
---
 Documentation/devicetree/bindings/hwmon/g762.txt |   57 ++++++++++++++++++++++
 1 file changed, 57 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/hwmon/g762.txt

diff --git a/Documentation/devicetree/bindings/hwmon/g762.txt b/Documentation/devicetree/bindings/hwmon/g762.txt
new file mode 100644
index 0000000..87d7cf5
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/g762.txt
@@ -0,0 +1,57 @@
+GMT G762/G763 PWM Fan controller
+
+Required node properties:
+
+ - "compatible": must be either "gmt,g762" or "gmt,g763"
+ - "reg": I2C bus address of the device
+
+Optional properties:
+
+ - "pwm_mode": fan driving mode. 1 for PWM mode, 0 for linear. Default
+               value is 0, i.e. linear.
+
+ - "pwm_enable": fan speed control. 1 for open-loop, 2 for closed-loop.
+               Default value is 2, i.e. closed-loop.
+
+ - "pwm_freq": reference clock frequency for PWM mode in Hz. Default is
+               32768.
+
+ - "fan_pulses": number of pulses per fan revolution. Supported values
+               are 2 and 4. Default is 2.
+
+ - "fan_div": fan clock frequency divisor value. Supported values are 1,
+               2, 4 and 8. Default is 1.
+
+ - "fan_target": initial target fan speed in RPM. By default, current
+               value is not modified. Only works in closed-loop fan speed
+	       control, i.e. when pwm_enable has already been set to 2.
+
+ - "fan_startv": fan startup voltage. Accepted values are 0, 1, 2 and 3.
+               Default value is 1. The higher the more.
+
+ - "pwm_polarity": pwm polarity. Accepted values are 0 (positive duty)
+               and 1 (negative duty). Default is 0 i.e. positive duty.
+
+ - "fan_gear_mode": fan gear mode. Supported values are 0, 1 and 2.
+               Default is 0.
+
+
+Additional information on operational parameters for the device is available
+in Documentation/hwmon/g762. A detailed datasheet for the device is available
+at http://natisbad.org/NAS/refs/GMT_EDS-762_763-080710-0.2.pdf.
+
+Example g762 node:
+
+   g762: g762 at 3e {
+        compatible = "gmt,g762";
+   	reg = <0x3e>;
+   	pwm_mode = <1>;      /* closed-loop control */
+   	pwm_enable = <2>;    /* PWM mode */
+   	pwm_freq = <8192>;   /* PWM reference clock freq */
+   	fan_pulses = <2>;    /* 2 pulses per rev */
+   	fan_div = <2>;       /* fan clock divisor */
+   	fan_target = <2000>; /* target fan speed at 2000 RPM */
+        fan_gear_mode = <0>; /* default */
+        fan_startv = <1>;    /* default */
+        pwm_polarity = <0>;  /* default */
+   };
-- 
1.7.10.4



From kgene.kim at samsung.com  Tue Apr 23 18:09:27 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Wed, 24 Apr 2013 07:09:27 +0900
Subject: [GIT PULL] Late Exynos stuff for v3.10
In-Reply-To: <5176B499.1000208@samsung.com>
References: <5176B499.1000208@samsung.com>
Message-ID: <51770697.7080504@samsung.com>

On 04/24/13 01:19, Kukjin Kim wrote:
> The following changes since commit
> 58a7bbf75442ea439a4d3b7993ad87023e406063:
>
> ARM: dts: add PDMA0 changes for exynos5440 (2013-04-09 01:39:27 +0900)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
> tags/late-exynos-for-v3.10
>
> for you to fetch changes up to 9007025f3438ec3bdea02439e760585345102b8d:
>
> ARM: dts: Disable the RTC by default on exynos5 (2013-04-24 00:32:28 +0900)
>
> ----------------------------------------------------------------
> This includes late exynos stuff for v3.10 1) keypad for smdk4412 and
> origen4412 boards 2) adds mfc clock entries for exynos4 3) enables
> usb2phy, usb3phy and dwc3-exynos for exynos5250 4) enables tmu for
> exynos4210 5) support chip id with dt
>
> ----------------------------------------------------------------
> Doug Anderson (1):
> ARM: dts: Disable the RTC by default on exynos5
>
> Girish K S (1):
> ARM: EXYNOS: force MAC ip to 32bit DMA
>
> Sachin Kamat (7):
> ARM: dts: Remove keypad entries from exynos4x12-pinctrl.dtsi
> ARM: dts: Add keypad entries to Exynos4412 based Origen
> ARM: dts: Add keypad entries to SMDK4412
> ARM: dts: Add MFC clock entries for exynos4
> ARM: dts: Update MFC documentation for clock entries
> ARM: dts: Add TMU clock entries to exynos4210.dtsi
> ARM: dts: Enable TMU on Origen4210 board
>
> Thomas Abraham (4):
> ARM: dts: add mshc controller node for Exynos4x12 SoCs
> ARM: EXYNOS: Add a platform bus notifier to set dma masks for Exynos5440
> ARM: EXYNOS: Create virtual I/O mapping for Chip-ID controller using
> device tree
> ARM: dts: Add chip-id controller node on Exynos4/5 SoC
>
> Vivek Gautam (5):
> ARM: dts: Enabling samsung-usb2phy driver for exynos5250
> ARM: dts: Enabling samsung-usb3phy driver for exynos5250
> ARM: dts: Add device tree bindings for dwc3-exynos
> ARM: dts: Enabling dwc3-exynos driver for exynos5250
> ARM: EXYNOS: Enable XHCI support on exynos5
>
> .../devicetree/bindings/media/s5p-mfc.txt | 5 ++
> .../devicetree/bindings/usb/exynos-usb.txt | 34 +++++++++
> arch/arm/boot/dts/exynos4.dtsi | 7 ++
> arch/arm/boot/dts/exynos4210-origen.dts | 4 +
> arch/arm/boot/dts/exynos4210.dtsi | 3 +
> arch/arm/boot/dts/exynos4412-origen.dts | 62 +++++++++++++++
> arch/arm/boot/dts/exynos4412-smdk4412.dts | 87 ++++++++++++++++++++++
> arch/arm/boot/dts/exynos4412.dtsi | 8 ++
> arch/arm/boot/dts/exynos4x12-pinctrl.dtsi | 56 --------------
> arch/arm/boot/dts/exynos5250.dtsi | 51 +++++++++++++
> arch/arm/boot/dts/exynos5440.dtsi | 1 +
> arch/arm/mach-exynos/Kconfig | 1 +
> arch/arm/mach-exynos/common.c | 53 +++++++------
> arch/arm/mach-exynos/include/mach/map.h | 1 -
> arch/arm/mach-exynos/mach-exynos5-dt.c | 28 +++++++
> 15 files changed, 321 insertions(+), 80 deletions(-)
>
> Hi Arnd and Olof,
>
> As I said, last my pull-request at 4/10 included most of above changes.
> So would be nice if you could pull this and small patches added on top
> of that though.
>
> If any problems, please kindly let me know.
>
Arnd, Olof,

Since above request should be too late, so I did sort out like 
following. I think, it should be fine to you ;-) Sorry for noise.

Note that others will be queued for v3.11.

Thanks.

- Kukjin

  The following changes since commit 
58a7bbf75442ea439a4d3b7993ad87023e406063:

    ARM: dts: add PDMA0 changes for exynos5440 (2013-04-09 01:39:27 +0900)

  are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
  tags/late-exynos-v2-for-v3.10

  for you to fetch changes up to 1ec583759692013c4576d557904b595e9f3953dd:

    ARM: dts: Disable the RTC by default on exynos5 (2013-04-24 06:58:21 
+0900)

  ----------------------------------------------------------------
  This includes late exynos stuff for v3.10 and 2nd version for pull 
request 1) enables usb2phy, usb3phy and dwc3-exynos for exynos5250 2) 
support chip id with dt

  ----------------------------------------------------------------
  Doug Anderson (1):
        ARM: dts: Disable the RTC by default on exynos5

  Thomas Abraham (3):
        ARM: dts: add mshc controller node for Exynos4x12 SoCs
        ARM: EXYNOS: Create virtual I/O mapping for Chip-ID controller 
using device tree
        ARM: dts: Add chip-id controller node on Exynos4/5 SoC

  Vivek Gautam (5):
        ARM: dts: Enabling samsung-usb2phy driver for exynos5250
        ARM: dts: Enabling samsung-usb3phy driver for exynos5250
        ARM: dts: Add device tree bindings for dwc3-exynos
        ARM: dts: Enabling dwc3-exynos driver for exynos5250
        ARM: EXYNOS: Enable XHCI support on exynos5

   .../devicetree/bindings/usb/exynos-usb.txt         | 34 ++++++++++++++
   arch/arm/boot/dts/exynos4.dtsi                     |  5 ++
   arch/arm/boot/dts/exynos4412.dtsi                  |  8 ++++
   arch/arm/boot/dts/exynos5250.dtsi                  | 51 
+++++++++++++++++++++


From jason at lakedaemon.net  Tue Apr 23 18:23:05 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Tue, 23 Apr 2013 18:23:05 -0400
Subject: [PATCHv1 3/3] hwmon: Add DT documentation for g762 driver
In-Reply-To: <6ee748f450ba2a80c87aba08c0672105e2800f93.1366753420.git.arno@natisbad.org>
References: <cover.1366753420.git.arno@natisbad.org>
 <6ee748f450ba2a80c87aba08c0672105e2800f93.1366753420.git.arno@natisbad.org>
Message-ID: <20130423222305.GD13884@titan.lakedaemon.net>

On Wed, Apr 24, 2013 at 12:06:20AM +0200, Arnaud Ebalard wrote:
> 
> Signed-off-by: Arnaud Ebalard <arno at natisbad.org>
> ---
>  Documentation/devicetree/bindings/hwmon/g762.txt |   57 ++++++++++++++++++++++
>  1 file changed, 57 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/hwmon/g762.txt
> 
> diff --git a/Documentation/devicetree/bindings/hwmon/g762.txt b/Documentation/devicetree/bindings/hwmon/g762.txt
> new file mode 100644
> index 0000000..87d7cf5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/hwmon/g762.txt
> @@ -0,0 +1,57 @@
> +GMT G762/G763 PWM Fan controller
> +
> +Required node properties:
> +
> + - "compatible": must be either "gmt,g762" or "gmt,g763"
> + - "reg": I2C bus address of the device
> +
> +Optional properties:
> +
> + - "pwm_mode": fan driving mode. 1 for PWM mode, 0 for linear. Default
> +               value is 0, i.e. linear.
> +
> + - "pwm_enable": fan speed control. 1 for open-loop, 2 for closed-loop.
> +               Default value is 2, i.e. closed-loop.
> +
> + - "pwm_freq": reference clock frequency for PWM mode in Hz. Default is
> +               32768.
> +
> + - "fan_pulses": number of pulses per fan revolution. Supported values
> +               are 2 and 4. Default is 2.
> +
> + - "fan_div": fan clock frequency divisor value. Supported values are 1,
> +               2, 4 and 8. Default is 1.
> +
> + - "fan_target": initial target fan speed in RPM. By default, current
> +               value is not modified. Only works in closed-loop fan speed
> +	       control, i.e. when pwm_enable has already been set to 2.
> +
> + - "fan_startv": fan startup voltage. Accepted values are 0, 1, 2 and 3.
> +               Default value is 1. The higher the more.
> +
> + - "pwm_polarity": pwm polarity. Accepted values are 0 (positive duty)
> +               and 1 (negative duty). Default is 0 i.e. positive duty.
> +
> + - "fan_gear_mode": fan gear mode. Supported values are 0, 1 and 2.
> +               Default is 0.
> +
> +
> +Additional information on operational parameters for the device is available
> +in Documentation/hwmon/g762. A detailed datasheet for the device is available
> +at http://natisbad.org/NAS/refs/GMT_EDS-762_763-080710-0.2.pdf.
> +
> +Example g762 node:
> +
> +   g762: g762 at 3e {
> +        compatible = "gmt,g762";
> +   	reg = <0x3e>;
> +   	pwm_mode = <1>;      /* closed-loop control */
> +   	pwm_enable = <2>;    /* PWM mode */
> +   	pwm_freq = <8192>;   /* PWM reference clock freq */
> +   	fan_pulses = <2>;    /* 2 pulses per rev */
> +   	fan_div = <2>;       /* fan clock divisor */
> +   	fan_target = <2000>; /* target fan speed at 2000 RPM */
> +        fan_gear_mode = <0>; /* default */
> +        fan_startv = <1>;    /* default */
> +        pwm_polarity = <0>;  /* default */
> +   };

I was just giving this quick overview and noticed that you have
leading whitespace issues in the above block...

thx,

Jason,


From nerv at dawncrow.de  Tue Apr 23 18:42:22 2013
From: nerv at dawncrow.de (=?ISO-8859-1?Q?Andr=E9_Hentschel?=)
Date: Wed, 24 Apr 2013 00:42:22 +0200
Subject: [PATCHv2] arm: Preserve TPIDRURW on context switch
In-Reply-To: <20130423091536.GB17593@mudshark.cambridge.arm.com>
References: <517168BB.3070903@dawncrow.de>
 <20130422143616.GP14496@n2100.arm.linux.org.uk>
 <20130422151836.GA15665@mudshark.cambridge.arm.com>
 <5175A697.3080308@dawncrow.de>
 <20130423091536.GB17593@mudshark.cambridge.arm.com>
Message-ID: <51770E4E.2040003@dawncrow.de>

Am 23.04.2013 11:15, schrieb Will Deacon:
> On Mon, Apr 22, 2013 at 10:07:35PM +0100, Andr? Hentschel wrote:
>> Am 22.04.2013 17:18, schrieb Will Deacon:
>>> On Mon, Apr 22, 2013 at 03:36:16PM +0100, Russell King - ARM Linux wrote:
>>>> On Fri, Apr 19, 2013 at 05:54:35PM +0200, Andr? Hentschel wrote:
>>>>> From: =?UTF-8?q?Andr=C3=A9=20Hentschel?= <nerv at dawncrow.de>
>>>>>
>>>>> There are more and more applications coming to WinRT, Wine could support them,
>>>>> but mostly they expect to have the thread environment block (TEB) in TPIDRURW.
>>>>> This register must be preserved per thread instead of being cleared.
>>>>>
>>>>> Signed-off-by: Andr? Hentschel <nerv at dawncrow.de>
>>>>
>>>> This actually makes things less efficient all round, because you
>>>> now use the value immediately after loading, which means it will cause
>>>> pipeline stalls, certainly on older CPUs.
>>>>
>>>> Could you please rework the patch to try avoiding soo many modifications
>>>> to the way things have been done here?
>>>
>>> copy_thread also needs updating so that the *register* value for the parent
>>> is copied to the child, since the parent may have written the register
>>> after the last context-switch, meaning that tp_value is out-of-date.
>>
>> Thank you both for reviewing.
>>
>> I guess you mostly mean "ldr	r6, [r2, #TI_CPU_DOMAIN]".
>> I just thought about old CPUs and remembered again that we at Wine
>> need that patch only on v7 (and later). So is it ok to introduce a set_tls_v7
>> in tls.h and make use of CONFIG_CPU_V7 compile-time check in
>> the changed files and in the copy_thread function?
> 
> No, we should support this feature on any CPU with the TPIDRURW register,
> otherwise it's going to get really confusing for userspace.

Sure, remembered that today.

>> Do i need any further flag checks in copy_thread or can i use the
>> compile-time check to add unconditional code?
> 
> You could introduce `get' tls functions, which don't do anything for CPUs
> without the relevant registers.

Before i have another round of testing and patch formatting/sending,
what about the untested patch below?


diff --git a/arch/arm/include/asm/thread_info.h b/arch/arm/include/asm/thread_info.h
index cddda1f..bb5b48d 100644
--- a/arch/arm/include/asm/thread_info.h
+++ b/arch/arm/include/asm/thread_info.h
@@ -58,7 +58,7 @@ struct thread_info {
 	struct cpu_context_save	cpu_context;	/* cpu context */
 	__u32			syscall;	/* syscall number */
 	__u8			used_cp[16];	/* thread used copro */
-	unsigned long		tp_value;
+	unsigned long		tp_value[2];
 #ifdef CONFIG_CRUNCH
 	struct crunch_state	crunchstate;
 #endif
diff --git a/arch/arm/include/asm/tls.h b/arch/arm/include/asm/tls.h
index 73409e6..1c10163 100644
--- a/arch/arm/include/asm/tls.h
+++ b/arch/arm/include/asm/tls.h
@@ -2,13 +2,30 @@
 #define __ASMARM_TLS_H
 
 #ifdef __ASSEMBLY__
+	.macro get_tls2_none, tp, tmp1
+	.endm
+
+	.macro get_tls2_v6k, tp, tmp1
+	mrc	p15, 0, \tmp1, c13, c0, 2		@ get user r/w TLS register
+	str	\tmp1, [\tp, #4]
+	.endm
+
+	.macro get_tls2_v6, tp, tmp1
+	ldr	\tmp1, =elf_hwcap
+	ldr	\tmp1, [\tmp1, #0]
+	tst	\tmp1, #HWCAP_TLS		@ hardware TLS available?
+	mrcne	p15, 0, \tmp1, c13, c0, 2		@ get user r/w TLS register
+	strne	\tmp1, [\tp, #4]
+	.endm
+
+
 	.macro set_tls_none, tp, tmp1, tmp2
 	.endm
 
 	.macro set_tls_v6k, tp, tmp1, tmp2
-	mcr	p15, 0, \tp, c13, c0, 3		@ set TLS register
-	mov	\tmp1, #0
-	mcr	p15, 0, \tmp1, c13, c0, 2	@ clear user r/w TLS register
+	ldrd	\tmp1, \tmp2, [\tp]
+	mcr	p15, 0, \tmp1, c13, c0, 3	@ set user r/o TLS register
+	mcr	p15, 0, \tmp2, c13, c0, 2	@ set user r/w TLS register
 	.endm
 
 	.macro set_tls_v6, tp, tmp1, tmp2
@@ -16,33 +33,39 @@
 	ldr	\tmp1, [\tmp1, #0]
 	mov	\tmp2, #0xffff0fff
 	tst	\tmp1, #HWCAP_TLS		@ hardware TLS available?
-	mcrne	p15, 0, \tp, c13, c0, 3		@ yes, set TLS register
-	movne	\tmp1, #0
-	mcrne	p15, 0, \tmp1, c13, c0, 2	@ clear user r/w TLS register
-	streq	\tp, [\tmp2, #-15]		@ set TLS value at 0xffff0ff0
+	ldrdne	\tmp1, \tmp2, [\tp]
+	ldreq	\tmp1, [\tp]
+	mcrne	p15, 0, \tmp1, c13, c0, 3	@ yes, set user r/o TLS register
+	mcrne	p15, 0, \tmp2, c13, c0, 2	@ set user r/w TLS register
+	streq	\tmp1, [\tmp2, #-15]		@ set TLS value at 0xffff0ff0
 	.endm
 
 	.macro set_tls_software, tp, tmp1, tmp2
-	mov	\tmp1, #0xffff0fff
-	str	\tp, [\tmp1, #-15]		@ set TLS value at 0xffff0ff0
+	ldr	\tmp1, [\tp]
+	mov	\tmp2, #0xffff0fff
+	str	\tmp1, [\tmp2, #-15]		@ set TLS value at 0xffff0ff0
 	.endm
 #endif
 
 #ifdef CONFIG_TLS_REG_EMUL
 #define tls_emu		1
 #define has_tls_reg		1
+#define get_tls2		get_tls2_none
 #define set_tls		set_tls_none
 #elif defined(CONFIG_CPU_V6)
 #define tls_emu		0
 #define has_tls_reg		(elf_hwcap & HWCAP_TLS)
+#define get_tls2		get_tls2_v6
 #define set_tls		set_tls_v6
 #elif defined(CONFIG_CPU_32v6K)
 #define tls_emu		0
 #define has_tls_reg		1
+#define get_tls2		get_tls2_v6k
 #define set_tls		set_tls_v6k
 #else
 #define tls_emu		0
 #define has_tls_reg		0
+#define get_tls2		get_tls2_none
 #define set_tls		set_tls_software
 #endif
 
diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
index 0f82098..097686b 100644
--- a/arch/arm/kernel/entry-armv.S
+++ b/arch/arm/kernel/entry-armv.S
@@ -728,7 +728,7 @@ ENTRY(__switch_to)
  UNWIND(.fnstart	)
  UNWIND(.cantunwind	)
 	add	ip, r1, #TI_CPU_SAVE
-	ldr	r3, [r2, #TI_TP_VALUE]
+	add	r3, r1, #TI_TP_VALUE
  ARM(	stmia	ip!, {r4 - sl, fp, sp, lr} )	@ Store most regs on stack
  THUMB(	stmia	ip!, {r4 - sl, fp}	   )	@ Store most regs on stack
  THUMB(	str	sp, [ip], #4		   )
@@ -736,6 +736,8 @@ ENTRY(__switch_to)
 #ifdef CONFIG_CPU_USE_DOMAINS
 	ldr	r6, [r2, #TI_CPU_DOMAIN]
 #endif
+	get_tls2	r3, r4
+	add	r3, r2, #TI_TP_VALUE
 	set_tls	r3, r4, r5
 #if defined(CONFIG_CC_STACKPROTECTOR) && !defined(CONFIG_SMP)
 	ldr	r7, [r2, #TI_TASK]
diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c
index 047d3e4..6138eb1 100644
--- a/arch/arm/kernel/process.c
+++ b/arch/arm/kernel/process.c
@@ -395,7 +395,8 @@ copy_thread(unsigned long clone_flags, unsigned long stack_start,
 	clear_ptrace_hw_breakpoint(p);
 
 	if (clone_flags & CLONE_SETTLS)
-		thread->tp_value = childregs->ARM_r3;
+		thread->tp_value[0] = childregs->ARM_r3;
+	thread->tp_value[1] = current_thread_info()->tp_value[1];
 
 	thread_notify(THREAD_NOTIFY_COPY, thread);
 
diff --git a/arch/arm/kernel/ptrace.c b/arch/arm/kernel/ptrace.c
index 03deeff..2bc1514 100644
--- a/arch/arm/kernel/ptrace.c
+++ b/arch/arm/kernel/ptrace.c
@@ -849,7 +849,7 @@ long arch_ptrace(struct task_struct *child, long request,
 #endif
 
 		case PTRACE_GET_THREAD_AREA:
-			ret = put_user(task_thread_info(child)->tp_value,
+			ret = put_user(task_thread_info(child)->tp_value[0],
 				       datap);
 			break;
 
diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
index 1c08911..f9d6259 100644
--- a/arch/arm/kernel/traps.c
+++ b/arch/arm/kernel/traps.c
@@ -588,7 +588,7 @@ asmlinkage int arm_syscall(int no, struct pt_regs *regs)
 		return regs->ARM_r0;
 
 	case NR(set_tls):
-		thread->tp_value = regs->ARM_r0;
+		thread->tp_value[0] = regs->ARM_r0;
 		if (tls_emu)
 			return 0;
 		if (has_tls_reg) {
@@ -706,7 +706,7 @@ static int get_tp_trap(struct pt_regs *regs, unsigned int instr)
 	int reg = (instr >> 12) & 15;
 	if (reg == 15)
 		return 1;
-	regs->uregs[reg] = current_thread_info()->tp_value;
+	regs->uregs[reg] = current_thread_info()->tp_value[0];
 	regs->ARM_pc += 4;
 	return 0;
 }



From linux at arm.linux.org.uk  Tue Apr 23 18:44:41 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Tue, 23 Apr 2013 23:44:41 +0100
Subject: [PATCH v4 00/15] multi-cluster power management
In-Reply-To: <alpine.LFD.2.03.1304231755370.17375@syhkavp.arg>
References: <1360041732-17936-1-git-send-email-nicolas.pitre@linaro.org>
 <20130423200429.GF5316@n2100.arm.linux.org.uk>
 <alpine.LFD.2.03.1304231657150.17375@syhkavp.arg>
 <20130423214610.GY14496@n2100.arm.linux.org.uk>
 <alpine.LFD.2.03.1304231755370.17375@syhkavp.arg>
Message-ID: <20130423224441.GZ14496@n2100.arm.linux.org.uk>

On Tue, Apr 23, 2013 at 05:56:03PM -0400, Nicolas Pitre wrote:
> On Tue, 23 Apr 2013, Russell King - ARM Linux wrote:
> 
> > On Tue, Apr 23, 2013 at 05:03:06PM -0400, Nicolas Pitre wrote:
> > > On Tue, 23 Apr 2013, Russell King - ARM Linux wrote:
> > > 
> > > > What I suggest for the time being is to provide new inline function(s)
> > > > in arch/arm/include/cacheflush.h which are purposed for your application,
> > > > document them in that file, and call the implementation you're currently
> > > > using.  That means if we do have to change it in the future (for example,
> > > > we don't need to do anything in the dcache flushing stuff) we don't have
> > > > to hunt through all the code to find _your_ different use of that function
> > > > and fix it - we can just fix it in one place and we have the reference
> > > > there for what your code expects.
> > > 
> > > What about the patch below?  Once you tell me it is fine to you I'll 
> > > adapt the MCPM series to it.
> > 
> > Yes, that looks like a saner solution.  Thanks.
> 
> May I add your ACK to the patch?

Yes, sure.

Acked-by: Russell King <rmk+kernel at arm.linux.org.uk>


From rjw at sisk.pl  Tue Apr 23 18:59:26 2013
From: rjw at sisk.pl (Rafael J. Wysocki)
Date: Wed, 24 Apr 2013 00:59:26 +0200
Subject: [PATCH 07/18] cpufreq: s3c24xx: move cpufreq driver to
 drivers/cpufreq
In-Reply-To: <5176A807.2090005@samsung.com>
References: <cover.1365079581.git.viresh.kumar@linaro.org>
 <1769336.FkfMpuXqqb@vostro.rjw.lan> <5176A807.2090005@samsung.com>
Message-ID: <2264237.NUtkmvZG3W@vostro.rjw.lan>

On Wednesday, April 24, 2013 12:25:59 AM Kukjin Kim wrote:
> On 04/05/13 20:36, Rafael J. Wysocki wrote:
> > On Friday, April 05, 2013 12:36:34 PM Viresh Kumar wrote:
> >> On 5 April 2013 12:18, Kukjin Kim<kgene.kim at samsung.com>  wrote:
> >>> Basically, this moving looks good to me, but should be re-worked based on
> >>> for-next of samsung tree because this touches too many samsung stuff so this
> >>> should be sent to upstream via samsung tree.
> >>
> >> Hmm... Its already applied in Rafael's tree. But it doesn't mean that
> >> it can't be
> >> moved to your tree if there is a issue.
> >
> > Well, I'm dropping it.  Please merge via the Samsung tree.
> >
> 
> Oops, I missed, maybe I have no more chance to send this to upstream for 
> upcoming merge window :-(
> 
> Rafael, please take this patch with my ack in your tree, sorry for noise.
> 
> Acked-by: Kukjin Kim <kgene.kim at samsung.com>
> 
> If any problems, please kindly let me know.

Well, I suppose I can take the original patch, but then it will conflict with
your tree during merge.  Is that not a problem?

Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.


From ohaugan at codeaurora.org  Tue Apr 23 18:54:53 2013
From: ohaugan at codeaurora.org (Olav Haugan)
Date: Tue, 23 Apr 2013 15:54:53 -0700
Subject: [PATCH] documentation: iommu: add description of ARM System MMU
 binding
In-Reply-To: <20130418190131.GA12344@mudshark.cambridge.arm.com>
References: <1365094259-24847-1-git-send-email-will.deacon@arm.com>
 <515F37C1.4000109@codeaurora.org>
 <20130408092535.GA17476@mudshark.cambridge.arm.com>
 <5162F87A.7070409@codeaurora.org>
 <20130410173732.GQ26992@mudshark.cambridge.arm.com>
 <5169C7D1.8070300@codeaurora.org>
 <20130415131341.GG9827@mudshark.cambridge.arm.com>
 <516D9602.2010404@codeaurora.org>
 <20130418190131.GA12344@mudshark.cambridge.arm.com>
Message-ID: <5177113D.7060300@codeaurora.org>

Hi Will,

On 4/18/2013 12:01 PM, Will Deacon wrote:
> On Tue, Apr 16, 2013 at 07:18:42PM +0100, Olav Haugan wrote:
>> On 4/15/2013 6:13 AM, Will Deacon wrote:
>>> If so, doesn't that strongly tie your video driver to the SMMU?
>>
>> Isn't this more or less what you are doing in DT where you associate
>> specific devices with an IOMMU (mmu-masters)?
> 
> No. The device-tree describes the *hardware*, as per usual. The StreamIDs
> are fixed properties of the SoC and we can't change them from Linux, so we
> describe all of the StreamIDs upstream of each SMMU so that we can program
> the thing. There's no way to generic way to discover them.

I meant that you are putting phandles to bus masters in the device tree
that use/need the SMMU for VA2PA translation. Doesn't this put a
dependency on the bus master devices? How will this work? Lets say that
we have a device during bootup that needs to use the SMMU (such as a
display processor [DP]). Don't you have cyclic dependency? The SMMU
device needs the DP device (phandle) but the DP device needs the SMMU to
initialize its device driver?

>>> This seems to be where we differ. My anticipated use-case is that a domain
>>> is allocated, which defines an empty address space. Masters are then
>>> attached to the domain by passing their struct device, so this may
>>> correspond to a DMA controller or a video core, in your case. The context
>>> bank is allocated dynamically when the first device is added to the
>>> domain, and then it is subsequently shared between all the masters in that
>>> domain.
>>
>> I feel that there are some limitation with this. Maybe you can address
>> the following:
>>
>> 1) What if you want two context banks in one domain (shared page table)?
> 
> Why would a page table shared between devices require multiple context
> banks? Multiple SMRs and S2CRs, sure, but they would ultimately point at the
> same context bank (and hence same address space).

What if you want to have 2 different VMID's being generated? Also, what
about TLB management? If I have two context banks I can invalidate only
entries associated with 1 of the context banks (if VMID differ for the
two context banks).

>> 2) What if a master (device) needs to use 2 or more context banks?
> 
> If a master needs to be in two address spaces at once, then it will need to
> attach it's StreamIDs to different domains. You can't place a single
> StreamID in two address spaces (this is an architectural constraint).

Yes, you would have a separate domain. I am just wondering how I would
model this in DT using the bindings that you are proposing? How does it
work? The bindings specify bus masters to StreamIDs. So if I call attach
with the master device you will allocate a context bank and program the
StreamIDs as specified in the DT. So now if I want to have another
context bank associated with the same master device what do I do? I call
into attach with a new domain but with the same master device but the
master device is already attached to a context/domain.

Thanks,

Olav Haugan

-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation


From cdall at cs.columbia.edu  Tue Apr 23 18:57:33 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Tue, 23 Apr 2013 15:57:33 -0700
Subject: [PATCH v3 03/32] arm64: KVM: HYP mode idmap support
In-Reply-To: <1365437854-30214-4-git-send-email-marc.zyngier@arm.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
 <1365437854-30214-4-git-send-email-marc.zyngier@arm.com>
Message-ID: <20130423225733.GA20569@gmail.com>



On Mon, Apr 8, 2013 at 9:17 AM, Marc Zyngier <marc.zyngier at arm.com> wrote:
> Add the necessary infrastructure for identity-mapped HYP page
> tables. Idmap-ed code must be in the ".hyp.idmap.text" linker
> section.
>
> The rest of the HYP ends up in ".hyp.text".
>
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> ---
>  arch/arm64/kernel/vmlinux.lds.S | 16 ++++++++++++++++
>  1 file changed, 16 insertions(+)
>
> diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
> index 3fae2be..855d43d 100644
> --- a/arch/arm64/kernel/vmlinux.lds.S
> +++ b/arch/arm64/kernel/vmlinux.lds.S
> @@ -17,6 +17,15 @@ ENTRY(stext)
>
>  jiffies = jiffies_64;
>
> +#define HYPERVISOR_TEXT                                        \
> +       . = ALIGN(2048);                                \

why align to 2048?  Comment?

are you changing this to the same idea as for the 32-bit code to reduce the kernel size?

> +       VMLINUX_SYMBOL(__hyp_idmap_text_start) = .;     \
> +       *(.hyp.idmap.text)                              \
> +       VMLINUX_SYMBOL(__hyp_idmap_text_end) = .;       \
> +       VMLINUX_SYMBOL(__hyp_text_start) = .;           \
> +       *(.hyp.text)                                    \
> +       VMLINUX_SYMBOL(__hyp_text_end) = .;
> +
>  SECTIONS
>  {
>         /*
> @@ -49,6 +58,7 @@ SECTIONS
>                         TEXT_TEXT
>                         SCHED_TEXT
>                         LOCK_TEXT
> +                       HYPERVISOR_TEXT
>                         *(.fixup)
>                         *(.gnu.warning)
>                 . = ALIGN(16);
> @@ -124,3 +134,9 @@ SECTIONS
>         STABS_DEBUG
>         .comment 0 : { *(.comment) }
>  }
> +
> +/*
> + * The HYP init code can't be more than a page long.
> + */
> +ASSERT(((__hyp_idmap_text_start + PAGE_SIZE) >= __hyp_idmap_text_end),
> +       "HYP init code too big")
> --
> 1.8.1.4
>
>
>
> _______________________________________________
> kvmarm mailing list
> kvmarm at lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm


From cdall at cs.columbia.edu  Tue Apr 23 18:57:58 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Tue, 23 Apr 2013 15:57:58 -0700
Subject: [PATCH v3 07/32] arm64: KVM: fault injection into a guest
In-Reply-To: <1365437854-30214-8-git-send-email-marc.zyngier@arm.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
 <1365437854-30214-8-git-send-email-marc.zyngier@arm.com>
Message-ID: <20130423225758.GB20569@gmail.com>

On Mon, Apr 08, 2013 at 05:17:09PM +0100, Marc Zyngier wrote:
> Implement the injection of a fault (undefined, data abort or
> prefetch abort) into a 64bit guest.
> 
> Reviewed-by: Christopher Covington <cov at codeaurora.org>
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> ---
>  arch/arm64/kvm/inject_fault.c | 118 ++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 118 insertions(+)
>  create mode 100644 arch/arm64/kvm/inject_fault.c
> 
> diff --git a/arch/arm64/kvm/inject_fault.c b/arch/arm64/kvm/inject_fault.c
> new file mode 100644
> index 0000000..2ff3b78
> --- /dev/null
> +++ b/arch/arm64/kvm/inject_fault.c
> @@ -0,0 +1,118 @@
> +/*
> + * Fault injection for 64bit guests.
> + *
> + * Copyright (C) 2012,2013 - ARM Ltd
> + * Author: Marc Zyngier <marc.zyngier at arm.com>
> + *
> + * Based on arch/arm/kvm/emulate.c
> + * Copyright (C) 2012 - Virtual Open Systems and Columbia University
> + * Author: Christoffer Dall <c.dall at virtualopensystems.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.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +#include <linux/kvm_host.h>
> +#include <asm/kvm_emulate.h>
> +#include <asm/esr.h>
> +
> +static void inject_abt64(struct kvm_vcpu *vcpu, bool is_iabt, unsigned long addr)
> +{
> +	unsigned long cpsr = *vcpu_cpsr(vcpu);
> +	int is_aarch32;
> +	u32 esr = 0;
> +
> +	is_aarch32 = vcpu_mode_is_32bit(vcpu);
> +
> +	*vcpu_spsr(vcpu) = cpsr;
> +	*vcpu_elr_el1(vcpu) = *vcpu_pc(vcpu);
> +
> +	*vcpu_cpsr(vcpu) = PSR_MODE_EL1h | PSR_A_BIT | PSR_F_BIT | PSR_I_BIT;
> +	*vcpu_pc(vcpu) = vcpu_sys_reg(vcpu, VBAR_EL1) + 0x200;

consider a define for the 0x200?

> +
> +	vcpu_sys_reg(vcpu, FAR_EL1) = addr;
> +
> +	/*
> +	 * Build an {i,d}abort, depending on the level and the
> +	 * instruction set. Report an external synchronous abort.
> +	 */
> +	if (kvm_vcpu_trap_il_is32bit(vcpu))
> +		esr |= ESR_EL1_IL;
> +
> +	if (is_aarch32 || (cpsr & PSR_MODE_MASK) == PSR_MODE_EL0t)
> +		esr |= (ESR_EL1_EC_IABT_EL0 << ESR_EL1_EC_SHIFT);
> +	else
> +		esr |= (ESR_EL1_EC_IABT_EL1 << ESR_EL1_EC_SHIFT);

why is it assumed that the abort must come from EL0 if the vcpu is in
aarch32 mode?

> +
> +	if (!is_iabt)
> +		esr |= ESR_EL1_EC_DABT_EL0;

this is slightly confusing unless you actually look at the definitions
and realize that or'ing on that extra bit works both in i- and d-abt
cases.

> +
> +	vcpu_sys_reg(vcpu, ESR_EL1) = esr | 0x10; /* External abort */
> +}
> +
> +static void inject_undef64(struct kvm_vcpu *vcpu)
> +{
> +	unsigned long cpsr = *vcpu_cpsr(vcpu);
> +	u32 esr = (ESR_EL1_EC_UNKNOWN << ESR_EL1_EC_SHIFT);
> +
> +	*vcpu_spsr(vcpu) = cpsr;
> +	*vcpu_elr_el1(vcpu) = *vcpu_pc(vcpu);
> +
> +	*vcpu_cpsr(vcpu) = PSR_MODE_EL1h | PSR_F_BIT | PSR_I_BIT;

would it make sense to have a define for a common set of these bits or
is this explicitly defined per exception type in the specs?

> +	*vcpu_pc(vcpu) = vcpu_sys_reg(vcpu, VBAR_EL1) + 0x200;
> +
> +	/*
> +	 * Build an unknown exception, depending on the instruction
> +	 * set.
> +	 */
> +	if (kvm_vcpu_trap_il_is32bit(vcpu))
> +		esr |= ESR_EL1_IL;
> +
> +	vcpu_sys_reg(vcpu, ESR_EL1) = esr;
> +}
> +
> +/**
> + * kvm_inject_dabt - inject a data abort into the guest
> + * @vcpu: The VCPU to receive the undefined exception
> + * @addr: The address to report in the DFAR
> + *
> + * It is assumed that this code is called from the VCPU thread and that the
> + * VCPU therefore is not currently executing guest code.
> + */
> +void kvm_inject_dabt(struct kvm_vcpu *vcpu, unsigned long addr)
> +{
> +	inject_abt64(vcpu, false, addr);
> +}
> +
> +/**
> + * kvm_inject_pabt - inject a prefetch abort into the guest
> + * @vcpu: The VCPU to receive the undefined exception
> + * @addr: The address to report in the DFAR
> + *
> + * It is assumed that this code is called from the VCPU thread and that the
> + * VCPU therefore is not currently executing guest code.
> + */
> +void kvm_inject_pabt(struct kvm_vcpu *vcpu, unsigned long addr)
> +{
> +	inject_abt64(vcpu, true, addr);
> +}
> +
> +/**
> + * kvm_inject_undefined - inject an undefined instruction into the guest
> + *
> + * It is assumed that this code is called from the VCPU thread and that the
> + * VCPU therefore is not currently executing guest code.
> + */
> +void kvm_inject_undefined(struct kvm_vcpu *vcpu)
> +{
> +	inject_undef64(vcpu);
> +}
> -- 
> 1.8.1.4
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


From cdall at cs.columbia.edu  Tue Apr 23 18:58:16 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Tue, 23 Apr 2013 15:58:16 -0700
Subject: [PATCH v3 08/32] arm64: KVM: architecture specific MMU backend
In-Reply-To: <1365437854-30214-9-git-send-email-marc.zyngier@arm.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
 <1365437854-30214-9-git-send-email-marc.zyngier@arm.com>
Message-ID: <20130423225816.GC20569@gmail.com>

On Mon, Apr 08, 2013 at 05:17:10PM +0100, Marc Zyngier wrote:
> Define the arm64 specific MMU backend:
> - HYP/kernel VA offset
> - S2 4/64kB definitions
> - S2 page table populating and flushing
> - icache cleaning
> 
> Reviewed-by: Christopher Covington <cov at codeaurora.org>
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> ---
>  arch/arm64/include/asm/kvm_mmu.h | 136 +++++++++++++++++++++++++++++++++++++++
>  1 file changed, 136 insertions(+)
>  create mode 100644 arch/arm64/include/asm/kvm_mmu.h
> 
> diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h
> new file mode 100644
> index 0000000..2eb2230
> --- /dev/null
> +++ b/arch/arm64/include/asm/kvm_mmu.h
> @@ -0,0 +1,136 @@
> +/*
> + * Copyright (C) 2012,2013 - ARM Ltd
> + * Author: Marc Zyngier <marc.zyngier at arm.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.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +#ifndef __ARM64_KVM_MMU_H__
> +#define __ARM64_KVM_MMU_H__
> +
> +#include <asm/page.h>
> +#include <asm/memory.h>
> +
> +/*
> + * As we only have the TTBR0_EL2 register, we cannot express
> + * "negative" addresses. This makes it impossible to directly share
> + * mappings with the kernel.
> + *
> + * Instead, give the HYP mode its own VA region at a fixed offset from
> + * the kernel by just masking the top bits (which are all ones for a
> + * kernel address).

For some reason I keep choking on this, despite it being very simple.
We're just defining a different PAGE_OFFSET, right? Why not do a hard
define as:

#define HYP_PAGE_OFFSET_MASK	0x0000ffffffffffff
#define HYP_PAGE_OFFSET		0x0000ffc000000000

...or change the second paragraph of the comment to say
that we definethe HYP_PAGE_OFFSET to be 0x 0000ffc0 00000000.

> + */
> +#define HYP_PAGE_OFFSET_SHIFT	VA_BITS
> +#define HYP_PAGE_OFFSET_MASK	((UL(1) << HYP_PAGE_OFFSET_SHIFT) - 1)

In any case, is there a reason for the HYP_PAGE_OFFSET_SHIFT
indirection? It may be simpler without...

> +#define HYP_PAGE_OFFSET		(PAGE_OFFSET & HYP_PAGE_OFFSET_MASK)
> +
> +/*
> + * Our virtual mapping for the idmap-ed MMU-enable code. Must be
> + * shared across all the page-tables. Conveniently, we use the last
> + * possible page, where no kernel mapping will ever exist.
> + */
> +#define TRAMPOLINE_VA		(HYP_PAGE_OFFSET_MASK & PAGE_MASK)

hmmm, ok, here it's kind of nice to have that define correlation, so
maybe it's not cleaner.  Something should be improved here in the define
or the comment to make it more clear.  Perhaps just adding the real
constants in the comment or in Documentation/arm64/memory.txt would
help.

> +
> +#ifdef __ASSEMBLY__
> +
> +/*
> + * Convert a kernel VA into a HYP VA.
> + * reg: VA to be converted.
> + */
> +.macro kern_hyp_va	reg
> +	and	\reg, \reg, #HYP_PAGE_OFFSET_MASK
> +.endm
> +
> +#else
> +
> +#include <asm/cacheflush.h>
> +
> +#define KERN_TO_HYP(kva)	((unsigned long)kva - PAGE_OFFSET + HYP_PAGE_OFFSET)
> +
> +/*
> + * Align KVM with the kernel's view of physical memory. Should be
> + * 40bit IPA, with PGD being 8kB aligned.
> + */
> +#define KVM_PHYS_SHIFT	PHYS_MASK_SHIFT
> +#define KVM_PHYS_SIZE	(1UL << KVM_PHYS_SHIFT)
> +#define KVM_PHYS_MASK	(KVM_PHYS_SIZE - 1UL)
> +
> +#ifdef CONFIG_ARM64_64K_PAGES
> +#define PAGE_LEVELS	2
> +#define BITS_PER_LEVEL	13
> +#else  /* 4kB pages */
> +#define PAGE_LEVELS	3
> +#define BITS_PER_LEVEL	9
> +#endif

What are the semantics of these defines exactly? They should be
S2_PAGE_LEVELS and make some assumptions of the VTCR_EL2.SL0 field
right?

> +
> +/* Make sure we get the right size, and thus the right alignment */

this comment is not particularly helpful, something explaining why the
max() thingy below makes sense would be more so :)  I really can't
follow the BITS_PER_S2_PGD and PTRS_PER_S2_PGD defines.

> +#define BITS_PER_S2_PGD (KVM_PHYS_SHIFT - (PAGE_LEVELS - 1) * BITS_PER_LEVEL - PAGE_SHIFT)
> +#define PTRS_PER_S2_PGD (1 << max(BITS_PER_LEVEL, BITS_PER_S2_PGD))
> +#define S2_PGD_ORDER	get_order(PTRS_PER_S2_PGD * sizeof(pgd_t))
> +#define S2_PGD_SIZE	(1 << S2_PGD_ORDER)
> +
> +int create_hyp_mappings(void *from, void *to);
> +int create_hyp_io_mappings(void *from, void *to, phys_addr_t);
> +void free_hyp_pgds(void);
> +
> +int kvm_alloc_stage2_pgd(struct kvm *kvm);
> +void kvm_free_stage2_pgd(struct kvm *kvm);
> +int kvm_phys_addr_ioremap(struct kvm *kvm, phys_addr_t guest_ipa,
> +			  phys_addr_t pa, unsigned long size);
> +
> +int kvm_handle_guest_abort(struct kvm_vcpu *vcpu, struct kvm_run *run);
> +
> +void kvm_mmu_free_memory_caches(struct kvm_vcpu *vcpu);
> +
> +phys_addr_t kvm_mmu_get_httbr(void);
> +phys_addr_t kvm_mmu_get_boot_httbr(void);
> +phys_addr_t kvm_get_idmap_vector(void);
> +int kvm_mmu_init(void);
> +void kvm_clear_hyp_idmap(void);
> +
> +#define	kvm_set_pte(ptep, pte)		set_pte(ptep, pte)

I noticed that this doesn't do any cache cleaning.  Are the MMU page
table walks guaranteed to be coherent with the MMU on arm64?

> +
> +static inline bool kvm_is_write_fault(unsigned long esr)
> +{
> +	unsigned long esr_ec = esr >> ESR_EL2_EC_SHIFT;
> +
> +	if (esr_ec == ESR_EL2_EC_IABT)
> +		return false;
> +
> +	if ((esr & ESR_EL2_ISV) && !(esr & ESR_EL2_WNR))
> +		return false;
> +
> +	return true;
> +}
> +
> +static inline void kvm_clean_pgd(pgd_t *pgd) {}
> +static inline void kvm_clean_pmd_entry(pmd_t *pmd) {}
> +static inline void kvm_clean_pte(pte_t *pte) {}
> +
> +static inline void kvm_set_s2pte_writable(pte_t *pte)
> +{
> +	pte_val(*pte) |= PTE_S2_RDWR;
> +}
> +
> +struct kvm;
> +
> +static inline void coherent_icache_guest_page(struct kvm *kvm, gfn_t gfn)
> +{
> +	unsigned long hva = gfn_to_hva(kvm, gfn);
> +	flush_icache_range(hva, hva + PAGE_SIZE);
> +}
> +
> +#define kvm_flush_dcache_to_poc(a,l)	__flush_dcache_area((a), (l))
> +
> +#endif /* __ASSEMBLY__ */
> +#endif /* __ARM64_KVM_MMU_H__ */
> -- 
> 1.8.1.4
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


From cdall at cs.columbia.edu  Tue Apr 23 18:59:21 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Tue, 23 Apr 2013 15:59:21 -0700
Subject: [PATCH v3 11/32] arm64: KVM: CPU specific system registers
 handling
In-Reply-To: <5168307E.2080700@arm.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
 <1365437854-30214-12-git-send-email-marc.zyngier@arm.com>
 <20130410170624.GL26992@mudshark.cambridge.arm.com>
 <5168307E.2080700@arm.com>
Message-ID: <20130423225921.GD20569@gmail.com>

On Fri, Apr 12, 2013 at 05:04:14PM +0100, Marc Zyngier wrote:
> On 10/04/13 18:06, Will Deacon wrote:
> > On Mon, Apr 08, 2013 at 05:17:13PM +0100, Marc Zyngier wrote:
> >> Add the support code for CPU specific system registers. Not much
> >> here yet.
> >>
> >> Reviewed-by: Christopher Covington <cov at codeaurora.org>
> >> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> >> ---
> >>  arch/arm64/kvm/sys_regs_generic_v8.c | 85 ++++++++++++++++++++++++++++++++++++
> >>  1 file changed, 85 insertions(+)
> >>  create mode 100644 arch/arm64/kvm/sys_regs_generic_v8.c
> >>
> >> diff --git a/arch/arm64/kvm/sys_regs_generic_v8.c b/arch/arm64/kvm/sys_regs_generic_v8.c
> >> new file mode 100644
> >> index 0000000..d4e8039
> >> --- /dev/null
> >> +++ b/arch/arm64/kvm/sys_regs_generic_v8.c
> >> @@ -0,0 +1,85 @@
> >> +/*
> >> + * Copyright (C) 2012,2013 - ARM Ltd
> >> + * Author: Marc Zyngier <marc.zyngier at arm.com>
> >> + *
> >> + * Based on arch/arm/kvm/coproc_a15.c:
> >> + * Copyright (C) 2012 - Virtual Open Systems and Columbia University
> >> + * Authors: Rusty Russell <rusty at rustcorp.au>
> >> + *          Christoffer Dall <c.dall at virtualopensystems.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.
> >> + *
> >> + * This program is distributed in the hope that it will be useful,
> >> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> >> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> >> + * GNU General Public License for more details.
> >> + *
> >> + * You should have received a copy of the GNU General Public License
> >> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
> >> + */
> >> +#include <linux/kvm_host.h>
> >> +#include <asm/cputype.h>
> >> +#include <asm/kvm_arm.h>
> >> +#include <asm/kvm_asm.h>
> >> +#include <asm/kvm_host.h>
> >> +#include <asm/kvm_emulate.h>
> >> +#include <asm/kvm_coproc.h>
> >> +#include <linux/init.h>
> >> +
> >> +#include "sys_regs.h"
> >> +
> >> +static bool access_actlr(struct kvm_vcpu *vcpu,
> >> +			 const struct sys_reg_params *p,
> >> +			 const struct sys_reg_desc *r)
> >> +{
> >> +	if (p->is_write)
> >> +		return ignore_write(vcpu, p);
> >> +
> >> +	*vcpu_reg(vcpu, p->Rt) = vcpu_sys_reg(vcpu, ACTLR_EL1);
> >> +	return true;
> >> +}
> >> +
> >> +static void reset_actlr(struct kvm_vcpu *vcpu, const struct sys_reg_desc *r)
> >> +{
> >> +	u64 actlr;
> >> +
> >> +	asm volatile("mrs %0, actlr_el1\n" : "=r" (actlr));
> >> +	vcpu_sys_reg(vcpu, ACTLR_EL1) = actlr;
> >> +}
> > 
> > Do we actually need this? If so, there are likely other registers (things
> > like the ectlr) that should be considered too.
> 
> I'm focussing on the architected registers, and only those. ECTLR is
> implementation dependent, and is not specified as an architected sysreg.
> 
> As this is one of the registers that we trap (TACR set in HCR_EL2), we
> have to emulate it. Now, maybe it is not that useful to trap it (nobody
> uses that code path yet).
> 
why is this even in a generic_v8 file then? Should it not be able to be
handled generically in the sys_regs file and only when you have specific
meanings of the register for a specific core should you add something
like this file?

I think it's preferred to have something that traps and shouts than
something that may or may not work (ie. just allowing the guest to read
the register directly), but you guys know better than me what kind of
things can be exposed through this register in the future.


From cdall at cs.columbia.edu  Tue Apr 23 18:59:37 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Tue, 23 Apr 2013 15:59:37 -0700
Subject: [PATCH v3 15/32] arm64: KVM: guest one-reg interface
In-Reply-To: <1365437854-30214-16-git-send-email-marc.zyngier@arm.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
 <1365437854-30214-16-git-send-email-marc.zyngier@arm.com>
Message-ID: <20130423225937.GE20569@gmail.com>

On Mon, Apr 08, 2013 at 05:17:17PM +0100, Marc Zyngier wrote:
> Let userspace play with the guest registers.
> 
> Reviewed-by: Christopher Covington <cov at codeaurora.org>
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> ---
>  arch/arm64/kvm/guest.c | 254 +++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 254 insertions(+)
>  create mode 100644 arch/arm64/kvm/guest.c
> 
> diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
> new file mode 100644
> index 0000000..47d3729
> --- /dev/null
> +++ b/arch/arm64/kvm/guest.c
> @@ -0,0 +1,254 @@
> +/*
> + * Copyright (C) 2012,2013 - ARM Ltd
> + * Author: Marc Zyngier <marc.zyngier at arm.com>
> + *
> + * Derived from arch/arm/kvm/guest.c:
> + * Copyright (C) 2012 - Virtual Open Systems and Columbia University
> + * Author: Christoffer Dall <c.dall at virtualopensystems.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.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +#include <linux/errno.h>
> +#include <linux/err.h>
> +#include <linux/kvm_host.h>
> +#include <linux/module.h>
> +#include <linux/vmalloc.h>
> +#include <linux/fs.h>
> +#include <asm/cputype.h>
> +#include <asm/uaccess.h>
> +#include <asm/kvm.h>
> +#include <asm/kvm_asm.h>
> +#include <asm/kvm_emulate.h>
> +#include <asm/kvm_coproc.h>
> +
> +struct kvm_stats_debugfs_item debugfs_entries[] = {
> +	{ NULL }
> +};
> +
> +int kvm_arch_vcpu_setup(struct kvm_vcpu *vcpu)
> +{
> +	vcpu->arch.hcr_el2 = HCR_GUEST_FLAGS;
> +	return 0;
> +}
> +
> +static u64 core_reg_offset_from_id(u64 id)
> +{
> +	return id & ~(KVM_REG_ARCH_MASK | KVM_REG_SIZE_MASK | KVM_REG_ARM_CORE);
> +}
> +
> +static int get_core_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> +{
> +	__u32 __user *uaddr = (__u32 __user *)(unsigned long)reg->addr;
> +	struct kvm_regs *regs = vcpu_gp_regs(vcpu);
> +	int nr_regs = sizeof(*regs) / sizeof(__u32);

eh, arent' your regs 64 bit?  Or are you 32-bit indexing into a 64-bit
structure?  If so, this needs to be described in a big fat comment
somewhere, which I couldn't even see looking forward in the patch series
for the documentation part.

Seems to me you'd want to remove the fp_regs from the core regs and just
use a 64-bit indexing and have a separate category for the fp stuff...

> +	u32 off;
> +
> +	/* Our ID is an index into the kvm_regs struct. */
> +	off = core_reg_offset_from_id(reg->id);
> +	if (off >= nr_regs ||
> +	    (off + (KVM_REG_SIZE(reg->id) / sizeof(__u32))) >= nr_regs)

According to your documentation you will always save/restore 32-bit
registers here, so the desijunction shouldn't be necessary, nor will it
be if you just base everything on 64-bit here.

> +		return -ENOENT;
> +
> +	if (copy_to_user(uaddr, ((u32 *)regs) + off, KVM_REG_SIZE(reg->id)))
> +		return -EFAULT;
> +
> +	return 0;
> +}
> +
> +static int set_core_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> +{
> +	__u32 __user *uaddr = (__u32 __user *)(unsigned long)reg->addr;
> +	struct kvm_regs *regs = vcpu_gp_regs(vcpu);
> +	int nr_regs = sizeof(*regs) / sizeof(__u32);

same concern here

> +	void *valp;
> +	u64 off;
> +	int err = 0;
> +
> +	/* Our ID is an index into the kvm_regs struct. */
> +	off = core_reg_offset_from_id(reg->id);
> +	if (off >= nr_regs ||
> +	    (off + (KVM_REG_SIZE(reg->id) / sizeof(__u32))) >= nr_regs)
> +		return -ENOENT;
> +
> +	valp = kmalloc(KVM_REG_SIZE(reg->id), GFP_KERNEL);
> +	if (!valp)
> +		return -ENOMEM;

Why are you dynamically allocating this?  Do you ever have anything
larger than a 64 bit core register? Just put that on the stack.

> +
> +	if (copy_from_user(valp, uaddr, KVM_REG_SIZE(reg->id))) {
> +		err = -EFAULT;
> +		goto out;
> +	}
> +
> +	if (off == KVM_REG_ARM_CORE_REG(regs.pstate)) {
> +		unsigned long mode = (*(unsigned long *)valp) & COMPAT_PSR_MODE_MASK;
> +		switch (mode) {
> +		case PSR_MODE_EL0t:
> +		case PSR_MODE_EL1t:
> +		case PSR_MODE_EL1h:
> +			break;
> +		default:
> +			err = -EINVAL;
> +			goto out;
> +		}
> +	}
> +
> +	memcpy((u32 *)regs + off, valp, KVM_REG_SIZE(reg->id));
> +out:
> +	kfree(valp);
> +	return err;
> +}
> +
> +int kvm_arch_vcpu_ioctl_get_regs(struct kvm_vcpu *vcpu, struct kvm_regs *regs)
> +{
> +	return -EINVAL;
> +}
> +
> +int kvm_arch_vcpu_ioctl_set_regs(struct kvm_vcpu *vcpu, struct kvm_regs *regs)
> +{
> +	return -EINVAL;
> +}
> +
> +static unsigned long num_core_regs(void)
> +{
> +	return sizeof(struct kvm_regs) / sizeof(unsigned long);
> +}
> +
> +/**
> + * kvm_arm_num_regs - how many registers do we present via KVM_GET_ONE_REG
> + *
> + * This is for all registers.
> + */
> +unsigned long kvm_arm_num_regs(struct kvm_vcpu *vcpu)
> +{
> +	return num_core_regs() + kvm_arm_num_sys_reg_descs(vcpu);
> +}
> +
> +/**
> + * kvm_arm_copy_reg_indices - get indices of all registers.
> + *
> + * We do core registers right here, then we apppend system regs.
> + */
> +int kvm_arm_copy_reg_indices(struct kvm_vcpu *vcpu, u64 __user *uindices)
> +{
> +	unsigned int i;
> +	const u64 core_reg = KVM_REG_ARM64 | KVM_REG_SIZE_U64 | KVM_REG_ARM_CORE;
> +
> +	for (i = 0; i < sizeof(struct kvm_regs)/sizeof(unsigned long); i++) {

nit: spaces around the division
nit: the kvm_regs struct uses __u64, so would be slightly more coherent
     to use that for the sizeof(...) as well

> +		if (put_user(core_reg | i, uindices))
> +			return -EFAULT;
> +		uindices++;
> +	}
> +
> +	return kvm_arm_copy_sys_reg_indices(vcpu, uindices);
> +}
> +
> +int kvm_arm_get_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> +{
> +	/* We currently use nothing arch-specific in upper 32 bits */
> +	if ((reg->id & ~KVM_REG_SIZE_MASK) >> 32 != KVM_REG_ARM64 >> 32)
> +		return -EINVAL;
> +
> +	/* Register group 16 means we want a core register. */
> +	if ((reg->id & KVM_REG_ARM_COPROC_MASK) == KVM_REG_ARM_CORE)
> +		return get_core_reg(vcpu, reg);
> +
> +	return kvm_arm_sys_reg_get_reg(vcpu, reg);
> +}
> +
> +int kvm_arm_set_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> +{
> +	/* We currently use nothing arch-specific in upper 32 bits */
> +	if ((reg->id & ~KVM_REG_SIZE_MASK) >> 32 != KVM_REG_ARM64 >> 32)
> +		return -EINVAL;
> +
> +	/* Register group 16 means we set a core register. */
> +	if ((reg->id & KVM_REG_ARM_COPROC_MASK) == KVM_REG_ARM_CORE)
> +		return set_core_reg(vcpu, reg);
> +
> +	return kvm_arm_sys_reg_set_reg(vcpu, reg);
> +}
> +
> +int kvm_arch_vcpu_ioctl_get_sregs(struct kvm_vcpu *vcpu,
> +				  struct kvm_sregs *sregs)
> +{
> +	return -EINVAL;
> +}
> +
> +int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu,
> +				  struct kvm_sregs *sregs)
> +{
> +	return -EINVAL;
> +}
> +
> +int __attribute_const__ kvm_target_cpu(void)
> +{
> +	unsigned long implementor = read_cpuid_implementor();
> +	unsigned long part_number = read_cpuid_part_number();
> +
> +	if (implementor != ARM_CPU_IMP_ARM)
> +		return -EINVAL;
> +
> +	switch (part_number) {
> +	case ARM_CPU_PART_AEM_V8:
> +		return KVM_ARM_TARGET_AEM_V8;
> +	case ARM_CPU_PART_FOUNDATION:
> +		return KVM_ARM_TARGET_FOUNDATION_V8;
> +	case ARM_CPU_PART_CORTEX_A57:
> +		/* Currently handled by the generic backend */

Seems like a slightly off place to keep this comment...

> +		return KVM_ARM_TARGET_CORTEX_A57;
> +	default:
> +		return -EINVAL;
> +	}
> +}
> +
> +int kvm_vcpu_set_target(struct kvm_vcpu *vcpu,
> +			const struct kvm_vcpu_init *init)
> +{
> +	unsigned int i;
> +	int phys_target = kvm_target_cpu();
> +
> +	if (init->target != phys_target)
> +		return -EINVAL;
> +
> +	vcpu->arch.target = phys_target;
> +	bitmap_zero(vcpu->arch.features, KVM_VCPU_MAX_FEATURES);
> +
> +	/* -ENOENT for unknown features, -EINVAL for invalid combinations. */
> +	for (i = 0; i < sizeof(init->features)*8; i++) {
> +		if (init->features[i / 32] & (1 << (i % 32))) {
> +			if (i >= KVM_VCPU_MAX_FEATURES)
> +				return -ENOENT;
> +			set_bit(i, vcpu->arch.features);
> +		}
> +	}
> +
> +	/* Now we know what it is, we can reset it. */
> +	return kvm_reset_vcpu(vcpu);
> +}
> +
> +int kvm_arch_vcpu_ioctl_get_fpu(struct kvm_vcpu *vcpu, struct kvm_fpu *fpu)
> +{
> +	return -EINVAL;
> +}
> +
> +int kvm_arch_vcpu_ioctl_set_fpu(struct kvm_vcpu *vcpu, struct kvm_fpu *fpu)
> +{
> +	return -EINVAL;
> +}
> +
> +int kvm_arch_vcpu_ioctl_translate(struct kvm_vcpu *vcpu,
> +				  struct kvm_translation *tr)
> +{
> +	return -EINVAL;
> +}
> -- 
> 1.8.1.4
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


From cdall at cs.columbia.edu  Tue Apr 23 18:59:58 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Tue, 23 Apr 2013 15:59:58 -0700
Subject: [PATCH v3 17/32] arm64: KVM: HYP mode world switch implementation
In-Reply-To: <1365437854-30214-18-git-send-email-marc.zyngier@arm.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
 <1365437854-30214-18-git-send-email-marc.zyngier@arm.com>
Message-ID: <20130423225958.GF20569@gmail.com>

On Mon, Apr 08, 2013 at 05:17:19PM +0100, Marc Zyngier wrote:
> The HYP mode world switch in all its glory.
> 
> Implements save/restore of host/guest registers, EL2 trapping,
> IPA resolution, and additional services (tlb invalidation).
> 
> Reviewed-by: Christopher Covington <cov at codeaurora.org>
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> ---
>  arch/arm64/kernel/asm-offsets.c |  34 +++
>  arch/arm64/kvm/hyp.S            | 602 ++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 636 insertions(+)
>  create mode 100644 arch/arm64/kvm/hyp.S
> 
> diff --git a/arch/arm64/kernel/asm-offsets.c b/arch/arm64/kernel/asm-offsets.c
> index a2a4d81..666e231 100644
> --- a/arch/arm64/kernel/asm-offsets.c
> +++ b/arch/arm64/kernel/asm-offsets.c
> @@ -21,6 +21,7 @@
>  #include <linux/sched.h>
>  #include <linux/mm.h>
>  #include <linux/dma-mapping.h>
> +#include <linux/kvm_host.h>
>  #include <asm/thread_info.h>
>  #include <asm/memory.h>
>  #include <asm/cputable.h>
> @@ -104,5 +105,38 @@ int main(void)
>    BLANK();
>    DEFINE(TZ_MINWEST,		offsetof(struct timezone, tz_minuteswest));
>    DEFINE(TZ_DSTTIME,		offsetof(struct timezone, tz_dsttime));
> +  BLANK();
> +#ifdef CONFIG_KVM_ARM_HOST
> +  DEFINE(VCPU_CONTEXT,		offsetof(struct kvm_vcpu, arch.ctxt));
> +  DEFINE(CPU_GP_REGS,		offsetof(struct kvm_cpu_context, gp_regs));
> +  DEFINE(CPU_USER_PT_REGS,	offsetof(struct kvm_regs, regs));
> +  DEFINE(CPU_FP_REGS,		offsetof(struct kvm_regs, fp_regs));
> +  DEFINE(CPU_SP_EL1,		offsetof(struct kvm_regs, sp_el1));
> +  DEFINE(CPU_ELR_EL1,		offsetof(struct kvm_regs, elr_el1));
> +  DEFINE(CPU_SPSR,		offsetof(struct kvm_regs, spsr));
> +  DEFINE(CPU_SYSREGS,		offsetof(struct kvm_cpu_context, sys_regs));
> +  DEFINE(VCPU_ESR_EL2,		offsetof(struct kvm_vcpu, arch.fault.esr_el2));
> +  DEFINE(VCPU_FAR_EL2,		offsetof(struct kvm_vcpu, arch.fault.far_el2));
> +  DEFINE(VCPU_HPFAR_EL2,	offsetof(struct kvm_vcpu, arch.fault.hpfar_el2));
> +  DEFINE(VCPU_HCR_EL2,		offsetof(struct kvm_vcpu, arch.hcr_el2));
> +  DEFINE(VCPU_IRQ_LINES,	offsetof(struct kvm_vcpu, arch.irq_lines));
> +  DEFINE(VCPU_HOST_CONTEXT,	offsetof(struct kvm_vcpu, arch.host_cpu_context));
> +  DEFINE(VCPU_TIMER_CNTV_CTL,	offsetof(struct kvm_vcpu, arch.timer_cpu.cntv_ctl));
> +  DEFINE(VCPU_TIMER_CNTV_CVAL,	offsetof(struct kvm_vcpu, arch.timer_cpu.cntv_cval));
> +  DEFINE(KVM_TIMER_CNTVOFF,	offsetof(struct kvm, arch.timer.cntvoff));
> +  DEFINE(KVM_TIMER_ENABLED,	offsetof(struct kvm, arch.timer.enabled));
> +  DEFINE(VCPU_KVM,		offsetof(struct kvm_vcpu, kvm));
> +  DEFINE(VCPU_VGIC_CPU,		offsetof(struct kvm_vcpu, arch.vgic_cpu));
> +  DEFINE(VGIC_CPU_HCR,		offsetof(struct vgic_cpu, vgic_hcr));
> +  DEFINE(VGIC_CPU_VMCR,		offsetof(struct vgic_cpu, vgic_vmcr));
> +  DEFINE(VGIC_CPU_MISR,		offsetof(struct vgic_cpu, vgic_misr));
> +  DEFINE(VGIC_CPU_EISR,		offsetof(struct vgic_cpu, vgic_eisr));
> +  DEFINE(VGIC_CPU_ELRSR,	offsetof(struct vgic_cpu, vgic_elrsr));
> +  DEFINE(VGIC_CPU_APR,		offsetof(struct vgic_cpu, vgic_apr));
> +  DEFINE(VGIC_CPU_LR,		offsetof(struct vgic_cpu, vgic_lr));
> +  DEFINE(VGIC_CPU_NR_LR,	offsetof(struct vgic_cpu, nr_lr));
> +  DEFINE(KVM_VTTBR,		offsetof(struct kvm, arch.vttbr));
> +  DEFINE(KVM_VGIC_VCTRL,	offsetof(struct kvm, arch.vgic.vctrl_base));
> +#endif
>    return 0;
>  }
> diff --git a/arch/arm64/kvm/hyp.S b/arch/arm64/kvm/hyp.S
> new file mode 100644
> index 0000000..c745d20
> --- /dev/null
> +++ b/arch/arm64/kvm/hyp.S
> @@ -0,0 +1,602 @@
> +/*
> + * Copyright (C) 2012,2013 - ARM Ltd
> + * Author: Marc Zyngier <marc.zyngier at arm.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.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +#include <linux/linkage.h>
> +#include <linux/irqchip/arm-gic.h>
> +
> +#include <asm/assembler.h>
> +#include <asm/memory.h>
> +#include <asm/asm-offsets.h>
> +#include <asm/fpsimdmacros.h>
> +#include <asm/kvm.h>
> +#include <asm/kvm_asm.h>
> +#include <asm/kvm_arm.h>
> +#include <asm/kvm_mmu.h>
> +
> +#define CPU_GP_REG_OFFSET(x)	(CPU_GP_REGS + x)
> +#define CPU_XREG_OFFSET(x)	CPU_GP_REG_OFFSET(CPU_USER_PT_REGS + 8*x)
> +#define CPU_SPSR_OFFSET(x)	CPU_GP_REG_OFFSET(CPU_SPSR + 8*x)
> +#define CPU_SYSREG_OFFSET(x)	(CPU_SYSREGS + 8*x)
> +
> +	.text
> +	.pushsection	.hyp.text, "ax"
> +	.align	PAGE_SHIFT
> +
> +__kvm_hyp_code_start:
> +	.globl __kvm_hyp_code_start
> +
> +.macro save_common_regs
> +	// x2: base address for cpu context
> +	// x3: tmp register

what's with the C99 style comments? Standard for arm64 assembly?

> +
> +	add	x3, x2, #CPU_XREG_OFFSET(19)
> +	stp	x19, x20, [x3]
> +	stp	x21, x22, [x3, #16]
> +	stp	x23, x24, [x3, #32]
> +	stp	x25, x26, [x3, #48]
> +	stp	x27, x28, [x3, #64]
> +	stp	x29, lr, [x3, #80]
> +
> +	mrs	x19, sp_el0
> +	mrs	x20, elr_el2		// EL1 PC
> +	mrs	x21, spsr_el2		// EL1 pstate
> +
> +	stp	x19, x20, [x3, #96]
> +	str	x21, [x3, #112]
> +
> +	mrs	x22, sp_el1
> +	mrs	x23, elr_el1
> +	mrs	x24, spsr_el1
> +
> +	str	x22, [x2, #CPU_GP_REG_OFFSET(CPU_SP_EL1)]
> +	str	x23, [x2, #CPU_GP_REG_OFFSET(CPU_ELR_EL1)]
> +	str	x24, [x2, #CPU_SPSR_OFFSET(KVM_SPSR_EL1)]
> +.endm
> +
> +.macro restore_common_regs
> +	// x2: base address for cpu context
> +	// x3: tmp register
> +
> +	ldr	x22, [x2, #CPU_GP_REG_OFFSET(CPU_SP_EL1)]
> +	ldr	x23, [x2, #CPU_GP_REG_OFFSET(CPU_ELR_EL1)]
> +	ldr	x24, [x2, #CPU_SPSR_OFFSET(KVM_SPSR_EL1)]
> +
> +	msr	sp_el1, x22
> +	msr	elr_el1, x23
> +	msr	spsr_el1, x24
> +
> +	add	x3, x2, #CPU_XREG_OFFSET(31)    // SP_EL0
> +	ldp	x19, x20, [x3]
> +	ldr	x21, [x3, #16]
> +
> +	msr	sp_el0, x19
> +	msr	elr_el2, x20 				// EL1 PC
> +	msr	spsr_el2, x21 				// EL1 pstate
> +
> +	add	x3, x2, #CPU_XREG_OFFSET(19)
> +	ldp	x19, x20, [x3]
> +	ldp	x21, x22, [x3, #16]
> +	ldp	x23, x24, [x3, #32]
> +	ldp	x25, x26, [x3, #48]
> +	ldp	x27, x28, [x3, #64]
> +	ldp	x29, lr, [x3, #80]
> +.endm
> +
> +.macro save_host_regs
> +	save_common_regs
> +.endm
> +
> +.macro restore_host_regs
> +	restore_common_regs
> +.endm
> +
> +.macro save_fpsimd
> +	// x2: cpu context address
> +	// x3, x4: tmp regs
> +	add	x3, x2, #CPU_GP_REG_OFFSET(CPU_FP_REGS)
> +	fpsimd_save x3, 4
> +.endm
> +
> +.macro restore_fpsimd
> +	// x2: cpu context address
> +	// x3, x4: tmp regs
> +	add	x3, x2, #CPU_GP_REG_OFFSET(CPU_FP_REGS)
> +	fpsimd_restore x3, 4
> +.endm
> +
> +.macro save_guest_regs
> +	// x0 is the vcpu address
> +	// x1 is the return code, do not corrupt!
> +	// x2 is the cpu context
> +	// x3 is a tmp register
> +	// Guest's x0-x3 are on the stack
> +
> +	// Compute base to save registers
> +	add	x3, x2, #CPU_XREG_OFFSET(4)
> +	stp	x4, x5, [x3]
> +	stp	x6, x7, [x3, #16]
> +	stp	x8, x9, [x3, #32]
> +	stp	x10, x11, [x3, #48]
> +	stp	x12, x13, [x3, #64]
> +	stp	x14, x15, [x3, #80]
> +	stp	x16, x17, [x3, #96]
> +	str	x18, [x3, #112]
> +
> +	pop	x6, x7			// x2, x3
> +	pop	x4, x5			// x0, x1
> +
> +	add	x3, x2, #CPU_XREG_OFFSET(0)
> +	stp	x4, x5, [x3]
> +	stp	x6, x7, [x3, #16]
> +
> +	save_common_regs
> +.endm
> +
> +.macro restore_guest_regs
> +	// x0 is the vcpu address.
> +	// x2 is the cpu context
> +	// x3 is a tmp register
> +
> +	// Prepare x0-x3 for later restore
> +	add	x3, x2, #CPU_XREG_OFFSET(0)
> +	ldp	x4, x5, [x3]
> +	ldp	x6, x7, [x3, #16]
> +	push	x4, x5		// Push x0-x3 on the stack
> +	push	x6, x7
> +
> +	// x4-x18
> +	ldp	x4, x5, [x3, #32]
> +	ldp	x6, x7, [x3, #48]
> +	ldp	x8, x9, [x3, #64]
> +	ldp	x10, x11, [x3, #80]
> +	ldp	x12, x13, [x3, #96]
> +	ldp	x14, x15, [x3, #112]
> +	ldp	x16, x17, [x3, #128]
> +	ldr	x18, [x3, #144]
> +
> +	// x19-x29, lr, sp*, elr*, spsr*
> +	restore_common_regs
> +
> +	// Last bits of the 64bit state
> +	pop	x2, x3
> +	pop	x0, x1
> +
> +	// Do not touch any register after this!
> +.endm
> +
> +/*
> + * Macros to perform system register save/restore.
> + *
> + * Ordering here is absolutely critical, and must be kept consistent
> + * in {save,restore}_sysregs, {save,restore}_guest_32bit_state,
> + * and in kvm_asm.h.
> + *
> + * In other words, don't touch any of these unless you know what
> + * you are doing.
> + */
> +.macro save_sysregs
> +	// x2: base address for cpu context
> +	// x3: tmp register
> +
> +	add	x3, x2, #CPU_SYSREG_OFFSET(MPIDR_EL1)
> +
> +	mrs	x4,	vmpidr_el2
> +	mrs	x5,	csselr_el1
> +	mrs	x6,	sctlr_el1
> +	mrs	x7,	actlr_el1
> +	mrs	x8,	cpacr_el1
> +	mrs	x9,	ttbr0_el1
> +	mrs	x10,	ttbr1_el1
> +	mrs	x11,	tcr_el1
> +	mrs	x12,	esr_el1
> +	mrs	x13, 	afsr0_el1
> +	mrs	x14,	afsr1_el1
> +	mrs	x15,	far_el1
> +	mrs	x16,	mair_el1
> +	mrs	x17,	vbar_el1
> +	mrs	x18,	contextidr_el1
> +	mrs	x19,	tpidr_el0
> +	mrs	x20,	tpidrro_el0
> +	mrs	x21,	tpidr_el1
> +	mrs	x22, 	amair_el1
> +	mrs	x23, 	cntkctl_el1
> +
> +	stp	x4, x5, [x3]
> +	stp	x6, x7, [x3, #16]
> +	stp	x8, x9, [x3, #32]
> +	stp	x10, x11, [x3, #48]
> +	stp	x12, x13, [x3, #64]
> +	stp	x14, x15, [x3, #80]
> +	stp	x16, x17, [x3, #96]
> +	stp	x18, x19, [x3, #112]
> +	stp	x20, x21, [x3, #128]
> +	stp	x22, x23, [x3, #144]
> +.endm
> +
> +.macro restore_sysregs
> +	// x2: base address for cpu context
> +	// x3: tmp register
> +
> +	add	x3, x2, #CPU_SYSREG_OFFSET(MPIDR_EL1)
> +
> +	ldp	x4, x5, [x3]
> +	ldp	x6, x7, [x3, #16]
> +	ldp	x8, x9, [x3, #32]
> +	ldp	x10, x11, [x3, #48]
> +	ldp	x12, x13, [x3, #64]
> +	ldp	x14, x15, [x3, #80]
> +	ldp	x16, x17, [x3, #96]
> +	ldp	x18, x19, [x3, #112]
> +	ldp	x20, x21, [x3, #128]
> +	ldp	x22, x23, [x3, #144]
> +
> +	msr	vmpidr_el2,	x4
> +	msr	csselr_el1,	x5
> +	msr	sctlr_el1,	x6
> +	msr	actlr_el1,	x7
> +	msr	cpacr_el1,	x8
> +	msr	ttbr0_el1,	x9
> +	msr	ttbr1_el1,	x10
> +	msr	tcr_el1,	x11
> +	msr	esr_el1,	x12
> +	msr	afsr0_el1,	x13
> +	msr	afsr1_el1,	x14
> +	msr	far_el1,	x15
> +	msr	mair_el1,	x16
> +	msr	vbar_el1,	x17
> +	msr	contextidr_el1,	x18
> +	msr	tpidr_el0,	x19
> +	msr	tpidrro_el0,	x20
> +	msr	tpidr_el1,	x21
> +	msr	amair_el1,	x22
> +	msr	cntkctl_el1,	x23
> +.endm
> +
> +.macro activate_traps
> +	ldr	x2, [x0, #VCPU_IRQ_LINES]
> +	ldr	x1, [x0, #VCPU_HCR_EL2]
> +	orr	x2, x2, x1
> +	msr	hcr_el2, x2
> +
> +	ldr	x2, =(CPTR_EL2_TTA)
> +	msr	cptr_el2, x2
> +
> +	ldr	x2, =(1 << 15)	// Trap CP15 Cr=15
> +	msr	hstr_el2, x2
> +
> +	mrs	x2, mdcr_el2
> +	and	x2, x2, #MDCR_EL2_HPMN_MASK
> +	orr	x2, x2, #(MDCR_EL2_TPM | MDCR_EL2_TPMCR)
> +	msr	mdcr_el2, x2
> +.endm
> +
> +.macro deactivate_traps
> +	mov	x2, #HCR_RW
> +	msr	hcr_el2, x2
> +	msr	cptr_el2, xzr
> +	msr	hstr_el2, xzr
> +
> +	mrs	x2, mdcr_el2
> +	and	x2, x2, #MDCR_EL2_HPMN_MASK
> +	msr	mdcr_el2, x2
> +.endm
> +
> +.macro activate_vm
> +	ldr	x1, [x0, #VCPU_KVM]
> +	kern_hyp_va	x1
> +	ldr	x2, [x1, #KVM_VTTBR]
> +	msr	vttbr_el2, x2
> +.endm
> +
> +.macro deactivate_vm
> +	msr	vttbr_el2, xzr
> +.endm
> +
> +__save_sysregs:
> +	save_sysregs
> +	ret
> +
> +__restore_sysregs:
> +	restore_sysregs
> +	ret
> +
> +__save_fpsimd:
> +	save_fpsimd
> +	ret
> +
> +__restore_fpsimd:
> +	restore_fpsimd
> +	ret
> +
> +/*
> + * u64 __kvm_vcpu_run(struct kvm_vcpu *vcpu);
> + *
> + * This is the world switch. The first half of the function
> + * deals with entering the guest, and anything from __kvm_vcpu_return
> + * to the end of the function deals with reentering the host.
> + * On the enter path, only x0 (vcpu pointer) must be preserved until
> + * the last moment. On the exit path, x0 (vcpu pointer) and x1 (exception
> + * code) must both be preserved until the epilogue.
> + * In both cases, x2 points to the CPU context we're saving/restoring from/to.
> + */
> +ENTRY(__kvm_vcpu_run)
> +	kern_hyp_va	x0
> +	msr	tpidr_el2, x0	// Save the vcpu register
> +
> +	// Host context
> +	ldr	x2, [x0, #VCPU_HOST_CONTEXT]
> +	kern_hyp_va x2
> +
> +	save_host_regs
> +	bl __save_fpsimd
> +	bl __save_sysregs
> +
> +	activate_traps
> +	activate_vm
> +
> +	// Guest context
> +	add	x2, x0, #VCPU_CONTEXT
> +
> +	bl __restore_sysregs
> +	bl __restore_fpsimd
> +	restore_guest_regs
> +
> +	// That's it, no more messing around.
> +	clrex
> +	eret
> +
> +__kvm_vcpu_return:
> +	// Assume x0 is the vcpu pointer, x1 the return code
> +	// Guest's x0-x3 are on the stack
> +
> +	// Guest context
> +	add	x2, x0, #VCPU_CONTEXT
> +
> +	save_guest_regs
> +	bl __save_fpsimd
> +	bl __save_sysregs
> +
> +	deactivate_traps
> +	deactivate_vm
> +
> +	// Host context
> +	ldr	x2, [x0, #VCPU_HOST_CONTEXT]
> +	kern_hyp_va x2
> +
> +	bl __restore_sysregs
> +	bl __restore_fpsimd
> +	restore_host_regs
> +	mov	x0, x1
> +	clrex
> +	ret
> +END(__kvm_vcpu_run)
> +
> +// void __kvm_tlb_flush_vmid_ipa(struct kvm *kvm, phys_addr_t ipa);
> +ENTRY(__kvm_tlb_flush_vmid_ipa)
> +	kern_hyp_va	x0
> +	ldr	x2, [x0, #KVM_VTTBR]
> +	msr	vttbr_el2, x2
> +	isb
> +
> +	/*
> +	 * We could do so much better if we had the VA as well.
> +	 * Instead, we invalidate Stage-2 for this IPA, and the
> +	 * whole of Stage-1. Weep...
> +	 */
> +	tlbi	ipas2e1is, x1
> +	dsb	sy
> +	tlbi	vmalle1is
> +	dsb	sy
> +	isb
> +
> +	msr	vttbr_el2, xzr
> +	isb
> +	ret
> +ENDPROC(__kvm_tlb_flush_vmid_ipa)
> +
> +ENTRY(__kvm_flush_vm_context)
> +	tlbi	alle1is
> +	ic	ialluis
> +	dsb	sy
> +	isb
> +	ret
> +ENDPROC(__kvm_flush_vm_context)
> +
> +__kvm_hyp_panic:
> +	adr	x0, __hyp_panic_str
> +	adr	x1, 1f
> +	ldp	x2, x3, [x1]
> +	sub	x0, x0, x2
> +	add	x0, x0, x3
> +	mrs	x1, spsr_el2
> +	mrs	x2, elr_el2
> +	mrs	x3, esr_el2
> +	mrs	x4, far_el2
> +	mrs	x5, hpfar_el2
> +	mrs	x6, tpidr_el2
> +
> +	mov	lr, #(PSR_F_BIT | PSR_I_BIT | PSR_A_BIT | PSR_D_BIT |\
> +		      PSR_MODE_EL1h)
> +	msr	spsr_el2, lr
> +	ldr	lr, =panic
> +	msr	elr_el2, lr
> +	eret
> +
> +	.align	3
> +1:	.quad	HYP_PAGE_OFFSET
> +	.quad	PAGE_OFFSET
> +ENDPROC(__kvm_hyp_panic)
> +
> +__hyp_panic_str:
> +	.ascii	"HYP panic:\nPS:%08x PC:%p ESR:%p\nFAR:%p HPFAR:%p VCPU:%p\n\0"
> +
> +	.align	2
> +
> +ENTRY(kvm_call_hyp)
> +	hvc	#0
> +	ret
> +ENDPROC(kvm_call_hyp)
> +
> +.macro invalid_vector	label, target
> +	.align	2
> +\label:
> +	b \target
> +ENDPROC(\label)
> +.endm
> +
> +	/* None of these should ever happen */
> +	invalid_vector	el2t_sync_invalid, __kvm_hyp_panic
> +	invalid_vector	el2t_irq_invalid, __kvm_hyp_panic
> +	invalid_vector	el2t_fiq_invalid, __kvm_hyp_panic
> +	invalid_vector	el2t_error_invalid, __kvm_hyp_panic
> +	invalid_vector	el2h_sync_invalid, __kvm_hyp_panic
> +	invalid_vector	el2h_irq_invalid, __kvm_hyp_panic
> +	invalid_vector	el2h_fiq_invalid, __kvm_hyp_panic
> +	invalid_vector	el2h_error_invalid, __kvm_hyp_panic
> +	invalid_vector	el1_sync_invalid, __kvm_hyp_panic
> +	invalid_vector	el1_irq_invalid, __kvm_hyp_panic
> +	invalid_vector	el1_fiq_invalid, __kvm_hyp_panic
> +	invalid_vector	el1_error_invalid, __kvm_hyp_panic
> +
> +el1_sync:					// Guest trapped into EL2
> +	push	x0, x1
> +	push	x2, x3
> +
> +	mrs	x1, esr_el2
> +	lsr	x2, x1, #ESR_EL2_EC_SHIFT
> +
> +	cmp	x2, #ESR_EL2_EC_HVC64
> +	b.ne	el1_trap
> +
> +	mrs	x3, vttbr_el2			// If vttbr is valid, the 64bit guest
> +	cbnz	x3, el1_trap			// called HVC
> +
> +	/* Here, we're pretty sure the host called HVC. */
> +	pop	x2, x3
> +	pop	x0, x1
> +
> +	push	lr, xzr
> +
> +	/*
> +	 * Compute the function address in EL2, and shuffle the parameters.
> +	 */
> +	kern_hyp_va	x0
> +	mov	lr, x0
> +	mov	x0, x1
> +	mov	x1, x2
> +	mov	x2, x3
> +	blr	lr
> +
> +	pop	lr, xzr
> +	eret
> +
> +el1_trap:
> +	/*
> +	 * x1: ESR
> +	 * x2: ESR_EC
> +	 */
> +	cmp	x2, #ESR_EL2_EC_DABT
> +	mov	x0, #ESR_EL2_EC_IABT
> +	ccmp	x2, x0, #4, ne
> +	b.ne	1f		// Not an abort we care about

why do we get the hpfar_el2 if it's not an abort (or is this for a
special type of abort) ?

> +
> +	/* This is an abort. Check for permission fault */
> +	and	x2, x1, #ESR_EL2_FSC_TYPE
> +	cmp	x2, #FSC_PERM
> +	b.ne	1f		// Not a permission fault
> +
> +	/*
> +	 * Check for Stage-1 page table walk, which is guaranteed
> +	 * to give a valid HPFAR_EL2.
> +	 */
> +	tbnz	x1, #7, 1f	// S1PTW is set
> +
> +	/*
> +	 * Permission fault, HPFAR_EL2 is invalid.
> +	 * Resolve the IPA the hard way using the guest VA.
> +	 * We always perform an EL1 lookup, as we already
> +	 * went through Stage-1.
> +	 */

What does the last sentence mean exactly?

> +	mrs	x3, far_el2
> +	at	s1e1r, x3
> +	isb
> +
> +	/* Read result */
> +	mrs	x3, par_el1
> +	tbnz	x3, #1, 3f		// Bail out if we failed the translation
> +	ubfx	x3, x3, #12, #36	// Extract IPA
> +	lsl	x3, x3, #4		// and present it like HPFAR
> +	b	2f
> +
> +1:	mrs	x3, hpfar_el2
> +
> +2:	mrs	x0, tpidr_el2
> +	mrs	x2, far_el2
> +	str	x1, [x0, #VCPU_ESR_EL2]
> +	str	x2, [x0, #VCPU_FAR_EL2]
> +	str	x3, [x0, #VCPU_HPFAR_EL2]
> +
> +	mov	x1, #ARM_EXCEPTION_TRAP
> +	b	__kvm_vcpu_return
> +
> +	/*
> +	 * Translation failed. Just return to the guest and
> +	 * let it fault again. Another CPU is probably playing
> +	 * behind our back.
> +	 */

This actually makes me wonder if this is a potential DOS attack from
guests (on the 32-bit code as well), or are we sure that an asynchronous
timer interrupt to the host will always creep in between e.g. a tight
loop playing this trick on us?

> +3:	pop	x2, x3
> +	pop	x0, x1
> +
> +	eret
> +
> +el1_irq:
> +	push	x0, x1
> +	push	x2, x3
> +	mrs	x0, tpidr_el2
> +	mov	x1, #ARM_EXCEPTION_IRQ
> +	b	__kvm_vcpu_return
> +
> +	.ltorg
> +
> +	.align 11
> +
> +ENTRY(__kvm_hyp_vector)
> +	ventry	el2t_sync_invalid		// Synchronous EL2t
> +	ventry	el2t_irq_invalid		// IRQ EL2t
> +	ventry	el2t_fiq_invalid		// FIQ EL2t
> +	ventry	el2t_error_invalid		// Error EL2t
> +
> +	ventry	el2h_sync_invalid		// Synchronous EL2h
> +	ventry	el2h_irq_invalid		// IRQ EL2h
> +	ventry	el2h_fiq_invalid		// FIQ EL2h
> +	ventry	el2h_error_invalid		// Error EL2h
> +
> +	ventry	el1_sync			// Synchronous 64-bit EL1
> +	ventry	el1_irq				// IRQ 64-bit EL1
> +	ventry	el1_fiq_invalid			// FIQ 64-bit EL1
> +	ventry	el1_error_invalid		// Error 64-bit EL1
> +
> +	ventry	el1_sync			// Synchronous 32-bit EL1
> +	ventry	el1_irq				// IRQ 32-bit EL1
> +	ventry	el1_fiq_invalid			// FIQ 32-bit EL1
> +	ventry	el1_error_invalid		// Error 32-bit EL1
> +ENDPROC(__kvm_hyp_vector)
> +
> +__kvm_hyp_code_end:
> +	.globl	__kvm_hyp_code_end
> +
> +	.popsection
> -- 
> 1.8.1.4
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


From cdall at cs.columbia.edu  Tue Apr 23 19:00:12 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Tue, 23 Apr 2013 16:00:12 -0700
Subject: [PATCH v3 19/32] arm64: KVM: Plug the VGIC
In-Reply-To: <1365437854-30214-20-git-send-email-marc.zyngier@arm.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
 <1365437854-30214-20-git-send-email-marc.zyngier@arm.com>
Message-ID: <20130423230012.GG20569@gmail.com>

On Mon, Apr 08, 2013 at 05:17:21PM +0100, Marc Zyngier wrote:
> Add support for the in-kernel GIC emulation. The include file
> is a complete duplicate of the 32bit one - something to fix
> at one point.

seems like something that should be fixed sooner as opposed to later...
Is it hard?

> 
> Reviewed-by: Christopher Covington <cov at codeaurora.org>
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> ---
>  arch/arm64/include/asm/kvm_vgic.h | 156 ++++++++++++++++++++++++++++++++++++++
>  arch/arm64/kvm/hyp.S              |  88 +++++++++++++++++++++
>  2 files changed, 244 insertions(+)
>  create mode 100644 arch/arm64/include/asm/kvm_vgic.h
> 
> diff --git a/arch/arm64/include/asm/kvm_vgic.h b/arch/arm64/include/asm/kvm_vgic.h
> new file mode 100644
> index 0000000..f353f22
> --- /dev/null
> +++ b/arch/arm64/include/asm/kvm_vgic.h
> @@ -0,0 +1,156 @@
> +/*
> + * Copyright (C) 2012 ARM Ltd.
> + * Author: Marc Zyngier <marc.zyngier at arm.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.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +#ifndef __ARM64_KVM_VGIC_H
> +#define __ARM64_KVM_VGIC_H
> +
> +#include <linux/kernel.h>
> +#include <linux/kvm.h>
> +#include <linux/irqreturn.h>
> +#include <linux/spinlock.h>
> +#include <linux/types.h>
> +#include <linux/irqchip/arm-gic.h>
> +
> +#define VGIC_NR_IRQS		128
> +#define VGIC_NR_SGIS		16
> +#define VGIC_NR_PPIS		16
> +#define VGIC_NR_PRIVATE_IRQS	(VGIC_NR_SGIS + VGIC_NR_PPIS)
> +#define VGIC_NR_SHARED_IRQS	(VGIC_NR_IRQS - VGIC_NR_PRIVATE_IRQS)
> +#define VGIC_MAX_CPUS		KVM_MAX_VCPUS
> +
> +/* Sanity checks... */
> +#if (VGIC_MAX_CPUS > 8)
> +#error	Invalid number of CPU interfaces
> +#endif
> +
> +#if (VGIC_NR_IRQS & 31)
> +#error "VGIC_NR_IRQS must be a multiple of 32"
> +#endif
> +
> +#if (VGIC_NR_IRQS > 1024)
> +#error "VGIC_NR_IRQS must be <= 1024"
> +#endif
> +
> +/*
> + * The GIC distributor registers describing interrupts have two parts:
> + * - 32 per-CPU interrupts (SGI + PPI)
> + * - a bunch of shared interrupts (SPI)
> + */
> +struct vgic_bitmap {
> +	union {
> +		u32 reg[VGIC_NR_PRIVATE_IRQS / 32];
> +		DECLARE_BITMAP(reg_ul, VGIC_NR_PRIVATE_IRQS);
> +	} percpu[VGIC_MAX_CPUS];
> +	union {
> +		u32 reg[VGIC_NR_SHARED_IRQS / 32];
> +		DECLARE_BITMAP(reg_ul, VGIC_NR_SHARED_IRQS);
> +	} shared;
> +};
> +
> +struct vgic_bytemap {
> +	u32 percpu[VGIC_MAX_CPUS][VGIC_NR_PRIVATE_IRQS / 4];
> +	u32 shared[VGIC_NR_SHARED_IRQS  / 4];
> +};
> +
> +struct vgic_dist {
> +	spinlock_t		lock;
> +	bool			ready;
> +
> +	/* Virtual control interface mapping */
> +	void __iomem		*vctrl_base;
> +
> +	/* Distributor and vcpu interface mapping in the guest */
> +	phys_addr_t		vgic_dist_base;
> +	phys_addr_t		vgic_cpu_base;
> +
> +	/* Distributor enabled */
> +	u32			enabled;
> +
> +	/* Interrupt enabled (one bit per IRQ) */
> +	struct vgic_bitmap	irq_enabled;
> +
> +	/* Interrupt 'pin' level */
> +	struct vgic_bitmap	irq_state;
> +
> +	/* Level-triggered interrupt in progress */
> +	struct vgic_bitmap	irq_active;
> +
> +	/* Interrupt priority. Not used yet. */
> +	struct vgic_bytemap	irq_priority;
> +
> +	/* Level/edge triggered */
> +	struct vgic_bitmap	irq_cfg;
> +
> +	/* Source CPU per SGI and target CPU */
> +	u8			irq_sgi_sources[VGIC_MAX_CPUS][16];
> +
> +	/* Target CPU for each IRQ */
> +	u8			irq_spi_cpu[VGIC_NR_SHARED_IRQS];
> +	struct vgic_bitmap	irq_spi_target[VGIC_MAX_CPUS];
> +
> +	/* Bitmap indicating which CPU has something pending */
> +	unsigned long		irq_pending_on_cpu;
> +};
> +
> +struct vgic_cpu {
> +	/* per IRQ to LR mapping */
> +	u8		vgic_irq_lr_map[VGIC_NR_IRQS];
> +
> +	/* Pending interrupts on this VCPU */
> +	DECLARE_BITMAP(	pending_percpu, VGIC_NR_PRIVATE_IRQS);
> +	DECLARE_BITMAP(	pending_shared, VGIC_NR_SHARED_IRQS);
> +
> +	/* Bitmap of used/free list registers */
> +	DECLARE_BITMAP(	lr_used, 64);
> +
> +	/* Number of list registers on this CPU */
> +	int		nr_lr;
> +
> +	/* CPU vif control registers for world switch */
> +	u32		vgic_hcr;
> +	u32		vgic_vmcr;
> +	u32		vgic_misr;	/* Saved only */
> +	u32		vgic_eisr[2];	/* Saved only */
> +	u32		vgic_elrsr[2];	/* Saved only */
> +	u32		vgic_apr;
> +	u32		vgic_lr[64];	/* A15 has only 4... */
> +};
> +
> +#define LR_EMPTY	0xff
> +
> +struct kvm;
> +struct kvm_vcpu;
> +struct kvm_run;
> +struct kvm_exit_mmio;
> +
> +int kvm_vgic_set_addr(struct kvm *kvm, unsigned long type, u64 addr);
> +int kvm_vgic_hyp_init(void);
> +int kvm_vgic_init(struct kvm *kvm);
> +int kvm_vgic_create(struct kvm *kvm);
> +int kvm_vgic_vcpu_init(struct kvm_vcpu *vcpu);
> +void kvm_vgic_flush_hwstate(struct kvm_vcpu *vcpu);
> +void kvm_vgic_sync_hwstate(struct kvm_vcpu *vcpu);
> +int kvm_vgic_inject_irq(struct kvm *kvm, int cpuid, unsigned int irq_num,
> +			bool level);
> +int kvm_vgic_vcpu_pending_irq(struct kvm_vcpu *vcpu);
> +bool vgic_handle_mmio(struct kvm_vcpu *vcpu, struct kvm_run *run,
> +		      struct kvm_exit_mmio *mmio);
> +
> +#define irqchip_in_kernel(k)	(!!((k)->arch.vgic.vctrl_base))
> +#define vgic_initialized(k)	((k)->arch.vgic.ready)
> +
> +#endif
> diff --git a/arch/arm64/kvm/hyp.S b/arch/arm64/kvm/hyp.S
> index c745d20..cc3192e 100644
> --- a/arch/arm64/kvm/hyp.S
> +++ b/arch/arm64/kvm/hyp.S
> @@ -306,6 +306,90 @@ __kvm_hyp_code_start:
>  	msr	vttbr_el2, xzr
>  .endm
>  
> +/*
> + * Save the VGIC CPU state into memory
> + * x0: Register pointing to VCPU struct
> + * Do not corrupt x1!!!
> + */
> +.macro save_vgic_state
> +	/* Get VGIC VCTRL base into x2 */
> +	ldr	x2, [x0, #VCPU_KVM]
> +	kern_hyp_va	x2
> +	ldr	x2, [x2, #KVM_VGIC_VCTRL]
> +	kern_hyp_va	x2
> +	cbz	x2, 2f		// disabled
> +
> +	/* Compute the address of struct vgic_cpu */
> +	add	x3, x0, #VCPU_VGIC_CPU
> +
> +	/* Save all interesting registers */
> +	ldr	w4, [x2, #GICH_HCR]
> +	ldr	w5, [x2, #GICH_VMCR]
> +	ldr	w6, [x2, #GICH_MISR]
> +	ldr	w7, [x2, #GICH_EISR0]
> +	ldr	w8, [x2, #GICH_EISR1]
> +	ldr	w9, [x2, #GICH_ELRSR0]
> +	ldr	w10, [x2, #GICH_ELRSR1]
> +	ldr	w11, [x2, #GICH_APR]
> +
> +	str	w4, [x3, #VGIC_CPU_HCR]
> +	str	w5, [x3, #VGIC_CPU_VMCR]
> +	str	w6, [x3, #VGIC_CPU_MISR]
> +	str	w7, [x3, #VGIC_CPU_EISR]
> +	str	w8, [x3, #(VGIC_CPU_EISR + 4)]
> +	str	w9, [x3, #VGIC_CPU_ELRSR]
> +	str	w10, [x3, #(VGIC_CPU_ELRSR + 4)]
> +	str	w11, [x3, #VGIC_CPU_APR]
> +
> +	/* Clear GICH_HCR */
> +	str	wzr, [x2, #GICH_HCR]
> +
> +	/* Save list registers */
> +	add	x2, x2, #GICH_LR0
> +	ldr	w4, [x3, #VGIC_CPU_NR_LR]
> +	add	x3, x3, #VGIC_CPU_LR
> +1:	ldr	w5, [x2], #4
> +	str	w5, [x3], #4
> +	sub	w4, w4, #1
> +	cbnz	w4, 1b
> +2:
> +.endm
> +
> +/*
> + * Restore the VGIC CPU state from memory
> + * x0: Register pointing to VCPU struct
> + */
> +.macro restore_vgic_state
> +	/* Get VGIC VCTRL base into x2 */
> +	ldr	x2, [x0, #VCPU_KVM]
> +	kern_hyp_va	x2
> +	ldr	x2, [x2, #KVM_VGIC_VCTRL]
> +	kern_hyp_va	x2
> +	cbz	x2, 2f		// disabled
> +
> +	/* Compute the address of struct vgic_cpu */
> +	add	x3, x0, #VCPU_VGIC_CPU
> +
> +	/* We only restore a minimal set of registers */
> +	ldr	w4, [x3, #VGIC_CPU_HCR]
> +	ldr	w5, [x3, #VGIC_CPU_VMCR]
> +	ldr	w6, [x3, #VGIC_CPU_APR]
> +
> +	str	w4, [x2, #GICH_HCR]
> +	str	w5, [x2, #GICH_VMCR]
> +	str	w6, [x2, #GICH_APR]
> +
> +	/* Restore list registers */
> +	add	x2, x2, #GICH_LR0
> +	ldr	w4, [x3, #VGIC_CPU_NR_LR]
> +	add	x3, x3, #VGIC_CPU_LR
> +1:	ldr	w5, [x3], #4
> +	str	w5, [x2], #4
> +	sub	w4, w4, #1
> +	cbnz	w4, 1b
> +2:
> +.endm
> +
>  __save_sysregs:
>  	save_sysregs
>  	ret
> @@ -348,6 +432,8 @@ ENTRY(__kvm_vcpu_run)
>  	activate_traps
>  	activate_vm
>  
> +	restore_vgic_state
> +
>  	// Guest context
>  	add	x2, x0, #VCPU_CONTEXT
>  
> @@ -370,6 +456,8 @@ __kvm_vcpu_return:
>  	bl __save_fpsimd
>  	bl __save_sysregs
>  
> +	save_vgic_state
> +
>  	deactivate_traps
>  	deactivate_vm
>  
> -- 
> 1.8.1.4
> 
> 
> 
> _______________________________________________
> kvmarm mailing list
> kvmarm at lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm


From cdall at cs.columbia.edu  Tue Apr 23 19:00:24 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Tue, 23 Apr 2013 16:00:24 -0700
Subject: [PATCH v3 20/32] arm64: KVM: Plug the arch timer
In-Reply-To: <1365437854-30214-21-git-send-email-marc.zyngier@arm.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
 <1365437854-30214-21-git-send-email-marc.zyngier@arm.com>
Message-ID: <20130423230024.GH20569@gmail.com>

On Mon, Apr 08, 2013 at 05:17:22PM +0100, Marc Zyngier wrote:
> Add support for the in-kernel timer emulation. The include file
> is a complete duplicate of the 32bit one - something to fix
> at one point.

again, I'd really like to see this fixed before we merge the code...

> 
> Reviewed-by: Christopher Covington <cov at codeaurora.org>
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> ---
>  arch/arm/kvm/arch_timer.c               |  1 +
>  arch/arm64/include/asm/kvm_arch_timer.h | 58 +++++++++++++++++++++++++++++++++
>  arch/arm64/kvm/hyp.S                    | 56 +++++++++++++++++++++++++++++++
>  3 files changed, 115 insertions(+)
>  create mode 100644 arch/arm64/include/asm/kvm_arch_timer.h
> 
> diff --git a/arch/arm/kvm/arch_timer.c b/arch/arm/kvm/arch_timer.c
> index c55b608..49a7516 100644
> --- a/arch/arm/kvm/arch_timer.c
> +++ b/arch/arm/kvm/arch_timer.c
> @@ -195,6 +195,7 @@ static struct notifier_block kvm_timer_cpu_nb = {
>  
>  static const struct of_device_id arch_timer_of_match[] = {
>  	{ .compatible	= "arm,armv7-timer",	},
> +	{ .compatible	= "arm,armv8-timer",	},
>  	{},
>  };
>  
> diff --git a/arch/arm64/include/asm/kvm_arch_timer.h b/arch/arm64/include/asm/kvm_arch_timer.h
> new file mode 100644
> index 0000000..eb02273
> --- /dev/null
> +++ b/arch/arm64/include/asm/kvm_arch_timer.h
> @@ -0,0 +1,58 @@
> +/*
> + * Copyright (C) 2012 ARM Ltd.
> + * Author: Marc Zyngier <marc.zyngier at arm.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.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +#ifndef __ARM64_KVM_ARCH_TIMER_H
> +#define __ARM64_KVM_ARCH_TIMER_H
> +
> +#include <linux/clocksource.h>
> +#include <linux/hrtimer.h>
> +#include <linux/workqueue.h>
> +
> +struct arch_timer_kvm {
> +	/* Is the timer enabled */
> +	bool			enabled;
> +
> +	/* Virtual offset, restored only */
> +	cycle_t			cntvoff;
> +};
> +
> +struct arch_timer_cpu {
> +	/* Background timer used when the guest is not running */
> +	struct hrtimer			timer;
> +
> +	/* Work queued with the above timer expires */
> +	struct work_struct		expired;
> +
> +	/* Background timer active */
> +	bool				armed;
> +
> +	/* Timer IRQ */
> +	const struct kvm_irq_level	*irq;
> +
> +	/* Registers: control register, timer value */
> +	u32				cntv_ctl;	/* Saved/restored */
> +	cycle_t				cntv_cval;	/* Saved/restored */
> +};
> +
> +int kvm_timer_hyp_init(void);
> +int kvm_timer_init(struct kvm *kvm);
> +void kvm_timer_vcpu_init(struct kvm_vcpu *vcpu);
> +void kvm_timer_flush_hwstate(struct kvm_vcpu *vcpu);
> +void kvm_timer_sync_hwstate(struct kvm_vcpu *vcpu);
> +void kvm_timer_vcpu_terminate(struct kvm_vcpu *vcpu);
> +
> +#endif
> diff --git a/arch/arm64/kvm/hyp.S b/arch/arm64/kvm/hyp.S
> index cc3192e..25da0b5 100644
> --- a/arch/arm64/kvm/hyp.S
> +++ b/arch/arm64/kvm/hyp.S
> @@ -390,6 +390,60 @@ __kvm_hyp_code_start:
>  2:
>  .endm
>  
> +.macro save_timer_state
> +	// x0: vcpu pointer
> +	ldr	x2, [x0, #VCPU_KVM]
> +	kern_hyp_va x2
> +	ldr	w3, [x2, #KVM_TIMER_ENABLED]
> +	cbz	w3, 1f
> +
> +	mrs	x3, cntv_ctl_el0
> +	and	x3, x3, #3
> +	str	w3, [x0, #VCPU_TIMER_CNTV_CTL]
> +	bic	x3, x3, #1		// Clear Enable
> +	msr	cntv_ctl_el0, x3
> +
> +	isb
> +
> +	mrs	x3, cntv_cval_el0
> +	str	x3, [x0, #VCPU_TIMER_CNTV_CVAL]
> +
> +1:
> +	// Allow physical timer/counter access for the host
> +	mrs	x2, cnthctl_el2
> +	orr	x2, x2, #3
> +	msr	cnthctl_el2, x2
> +
> +	// Clear cntvoff for the host
> +	msr	cntvoff_el2, xzr
> +.endm
> +
> +.macro restore_timer_state
> +	// x0: vcpu pointer
> +	// Disallow physical timer access for the guest
> +	// Physical counter access is allowed
> +	mrs	x2, cnthctl_el2
> +	orr	x2, x2, #1
> +	bic	x2, x2, #2
> +	msr	cnthctl_el2, x2
> +
> +	ldr	x2, [x0, #VCPU_KVM]
> +	kern_hyp_va x2
> +	ldr	w3, [x2, #KVM_TIMER_ENABLED]
> +	cbz	w3, 1f
> +
> +	ldr	x3, [x2, #KVM_TIMER_CNTVOFF]
> +	msr	cntvoff_el2, x3
> +	ldr	x2, [x0, #VCPU_TIMER_CNTV_CVAL]
> +	msr	cntv_cval_el0, x2
> +	isb
> +
> +	ldr	w2, [x0, #VCPU_TIMER_CNTV_CTL]
> +	and	x2, x2, #3
> +	msr	cntv_ctl_el0, x2
> +1:
> +.endm
> +
>  __save_sysregs:
>  	save_sysregs
>  	ret
> @@ -433,6 +487,7 @@ ENTRY(__kvm_vcpu_run)
>  	activate_vm
>  
>  	restore_vgic_state
> +	restore_timer_state
>  
>  	// Guest context
>  	add	x2, x0, #VCPU_CONTEXT
> @@ -456,6 +511,7 @@ __kvm_vcpu_return:
>  	bl __save_fpsimd
>  	bl __save_sysregs
>  
> +	save_timer_state
>  	save_vgic_state
>  
>  	deactivate_traps
> -- 
> 1.8.1.4
> 
> 
> 
> _______________________________________________
> kvmarm mailing list
> kvmarm at lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm


From cdall at cs.columbia.edu  Tue Apr 23 19:00:39 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Tue, 23 Apr 2013 16:00:39 -0700
Subject: [PATCH v3 24/32] arm64: KVM: 32bit GP register access
In-Reply-To: <1365437854-30214-25-git-send-email-marc.zyngier@arm.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
 <1365437854-30214-25-git-send-email-marc.zyngier@arm.com>
Message-ID: <20130423230039.GI20569@gmail.com>

On Mon, Apr 08, 2013 at 05:17:26PM +0100, Marc Zyngier wrote:
> Allow access to the 32bit register file through the usual API.
> 
> Reviewed-by: Christopher Covington <cov at codeaurora.org>
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> ---
>  arch/arm64/include/asm/kvm_emulate.h |  17 +++-
>  arch/arm64/kvm/Makefile              |   2 +-
>  arch/arm64/kvm/regmap.c              | 168 +++++++++++++++++++++++++++++++++++
>  3 files changed, 184 insertions(+), 3 deletions(-)
>  create mode 100644 arch/arm64/kvm/regmap.c
> 
> diff --git a/arch/arm64/include/asm/kvm_emulate.h b/arch/arm64/include/asm/kvm_emulate.h
> index 2dcfa74..37a6567 100644
> --- a/arch/arm64/include/asm/kvm_emulate.h
> +++ b/arch/arm64/include/asm/kvm_emulate.h
> @@ -28,6 +28,9 @@
>  #include <asm/kvm_mmio.h>
>  #include <asm/ptrace.h>
>  
> +unsigned long *vcpu_reg32(const struct kvm_vcpu *vcpu, u8 reg_num);
> +unsigned long *vcpu_spsr32(const struct kvm_vcpu *vcpu);
> +
>  void kvm_inject_undefined(struct kvm_vcpu *vcpu);
>  void kvm_inject_dabt(struct kvm_vcpu *vcpu, unsigned long addr);
>  void kvm_inject_pabt(struct kvm_vcpu *vcpu, unsigned long addr);
> @@ -49,7 +52,7 @@ static inline unsigned long *vcpu_cpsr(const struct kvm_vcpu *vcpu)
>  
>  static inline bool vcpu_mode_is_32bit(const struct kvm_vcpu *vcpu)
>  {
> -	return false;	/* 32bit? Bahhh... */
> +	return !!(*vcpu_cpsr(vcpu) & PSR_MODE32_BIT);

nit: you don't need the '!!': it's a bool

>  }
>  
>  static inline bool kvm_condition_valid(const struct kvm_vcpu *vcpu)
> @@ -64,28 +67,38 @@ static inline void kvm_skip_instr(struct kvm_vcpu *vcpu, bool is_wide_instr)
>  
>  static inline void vcpu_set_thumb(struct kvm_vcpu *vcpu)
>  {
> +	*vcpu_cpsr(vcpu) |= COMPAT_PSR_T_BIT;
>  }
>  
>  static inline unsigned long *vcpu_reg(const struct kvm_vcpu *vcpu, u8 reg_num)
>  {
> +	if (vcpu_mode_is_32bit(vcpu))
> +		return vcpu_reg32(vcpu, reg_num);
> +
>  	return (unsigned long *)&vcpu_gp_regs(vcpu)->regs.regs[reg_num];
>  }
>  
>  /* Get vcpu SPSR for current mode */
>  static inline unsigned long *vcpu_spsr(const struct kvm_vcpu *vcpu)
>  {
> +	if (vcpu_mode_is_32bit(vcpu))
> +		return vcpu_spsr32(vcpu);
> +
>  	return (unsigned long *)&vcpu_gp_regs(vcpu)->spsr[KVM_SPSR_EL1];
>  }
>  
>  static inline bool kvm_vcpu_reg_is_pc(const struct kvm_vcpu *vcpu, int reg)
>  {
> -	return false;
> +	return (vcpu_mode_is_32bit(vcpu)) && reg == 15;
>  }
>  
>  static inline bool vcpu_mode_priv(const struct kvm_vcpu *vcpu)
>  {
>  	u32 mode = *vcpu_cpsr(vcpu) & PSR_MODE_MASK;
>  
> +	if (vcpu_mode_is_32bit(vcpu))
> +		return mode > COMPAT_PSR_MODE_USR;
> +
>  	return mode != PSR_MODE_EL0t;
>  }
>  
> diff --git a/arch/arm64/kvm/Makefile b/arch/arm64/kvm/Makefile
> index be9eb3833..1668448 100644
> --- a/arch/arm64/kvm/Makefile
> +++ b/arch/arm64/kvm/Makefile
> @@ -11,7 +11,7 @@ obj-$(CONFIG_KVM_ARM_HOST) += kvm.o
>  kvm-$(CONFIG_KVM_ARM_HOST) += $(addprefix ../../../virt/kvm/, kvm_main.o coalesced_mmio.o)
>  kvm-$(CONFIG_KVM_ARM_HOST) += $(addprefix ../../../arch/arm/kvm/, arm.o mmu.o mmio.o psci.o perf.o)
>  
> -kvm-$(CONFIG_KVM_ARM_HOST) += inject_fault.o
> +kvm-$(CONFIG_KVM_ARM_HOST) += inject_fault.o regmap.o
>  kvm-$(CONFIG_KVM_ARM_HOST) += hyp.o hyp-init.o handle_exit.o
>  kvm-$(CONFIG_KVM_ARM_HOST) += guest.o reset.o sys_regs.o sys_regs_generic_v8.o
>  
> diff --git a/arch/arm64/kvm/regmap.c b/arch/arm64/kvm/regmap.c
> new file mode 100644
> index 0000000..bbc6ae3
> --- /dev/null
> +++ b/arch/arm64/kvm/regmap.c
> @@ -0,0 +1,168 @@
> +/*
> + * Copyright (C) 2012,2013 - ARM Ltd
> + * Author: Marc Zyngier <marc.zyngier at arm.com>
> + *
> + * Derived from arch/arm/kvm/emulate.c:
> + * Copyright (C) 2012 - Virtual Open Systems and Columbia University
> + * Author: Christoffer Dall <c.dall at virtualopensystems.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.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +#include <linux/mm.h>
> +#include <linux/kvm_host.h>
> +#include <asm/kvm_emulate.h>
> +#include <asm/ptrace.h>
> +
> +#define VCPU_NR_MODES 6
> +#define REG_OFFSET(_reg) \
> +	(offsetof(struct user_pt_regs, _reg) / sizeof(unsigned long))
> +
> +#define USR_REG_OFFSET(R) REG_OFFSET(compat_usr(R))
> +
> +static const unsigned long vcpu_reg_offsets[VCPU_NR_MODES][16] = {
> +	/* USR Registers */
> +	{
> +		USR_REG_OFFSET(0), USR_REG_OFFSET(1), USR_REG_OFFSET(2),
> +		USR_REG_OFFSET(3), USR_REG_OFFSET(4), USR_REG_OFFSET(5),
> +		USR_REG_OFFSET(6), USR_REG_OFFSET(7), USR_REG_OFFSET(8),
> +		USR_REG_OFFSET(9), USR_REG_OFFSET(10), USR_REG_OFFSET(11),
> +		USR_REG_OFFSET(12), USR_REG_OFFSET(13),	USR_REG_OFFSET(14),
> +		REG_OFFSET(pc)
> +	},
> +
> +	/* FIQ Registers */
> +	{
> +		USR_REG_OFFSET(0), USR_REG_OFFSET(1), USR_REG_OFFSET(2),
> +		USR_REG_OFFSET(3), USR_REG_OFFSET(4), USR_REG_OFFSET(5),
> +		USR_REG_OFFSET(6), USR_REG_OFFSET(7),
> +		REG_OFFSET(compat_r8_fiq),  /* r8 */
> +		REG_OFFSET(compat_r9_fiq),  /* r9 */
> +		REG_OFFSET(compat_r10_fiq), /* r10 */
> +		REG_OFFSET(compat_r11_fiq), /* r11 */
> +		REG_OFFSET(compat_r12_fiq), /* r12 */
> +		REG_OFFSET(compat_sp_fiq),  /* r13 */
> +		REG_OFFSET(compat_lr_fiq),  /* r14 */
> +		REG_OFFSET(pc)
> +	},
> +
> +	/* IRQ Registers */
> +	{
> +		USR_REG_OFFSET(0), USR_REG_OFFSET(1), USR_REG_OFFSET(2),
> +		USR_REG_OFFSET(3), USR_REG_OFFSET(4), USR_REG_OFFSET(5),
> +		USR_REG_OFFSET(6), USR_REG_OFFSET(7), USR_REG_OFFSET(8),
> +		USR_REG_OFFSET(9), USR_REG_OFFSET(10), USR_REG_OFFSET(11),
> +		USR_REG_OFFSET(12),
> +		REG_OFFSET(compat_sp_irq), /* r13 */
> +		REG_OFFSET(compat_lr_irq), /* r14 */
> +		REG_OFFSET(pc)
> +	},
> +
> +	/* SVC Registers */
> +	{
> +		USR_REG_OFFSET(0), USR_REG_OFFSET(1), USR_REG_OFFSET(2),
> +		USR_REG_OFFSET(3), USR_REG_OFFSET(4), USR_REG_OFFSET(5),
> +		USR_REG_OFFSET(6), USR_REG_OFFSET(7), USR_REG_OFFSET(8),
> +		USR_REG_OFFSET(9), USR_REG_OFFSET(10), USR_REG_OFFSET(11),
> +		USR_REG_OFFSET(12),
> +		REG_OFFSET(compat_sp_svc), /* r13 */
> +		REG_OFFSET(compat_lr_svc), /* r14 */
> +		REG_OFFSET(pc)
> +	},
> +
> +	/* ABT Registers */
> +	{
> +		USR_REG_OFFSET(0), USR_REG_OFFSET(1), USR_REG_OFFSET(2),
> +		USR_REG_OFFSET(3), USR_REG_OFFSET(4), USR_REG_OFFSET(5),
> +		USR_REG_OFFSET(6), USR_REG_OFFSET(7), USR_REG_OFFSET(8),
> +		USR_REG_OFFSET(9), USR_REG_OFFSET(10), USR_REG_OFFSET(11),
> +		USR_REG_OFFSET(12),
> +		REG_OFFSET(compat_sp_abt), /* r13 */
> +		REG_OFFSET(compat_lr_abt), /* r14 */
> +		REG_OFFSET(pc)
> +	},
> +
> +	/* UND Registers */
> +	{
> +		USR_REG_OFFSET(0), USR_REG_OFFSET(1), USR_REG_OFFSET(2),
> +		USR_REG_OFFSET(3), USR_REG_OFFSET(4), USR_REG_OFFSET(5),
> +		USR_REG_OFFSET(6), USR_REG_OFFSET(7), USR_REG_OFFSET(8),
> +		USR_REG_OFFSET(9), USR_REG_OFFSET(10), USR_REG_OFFSET(11),
> +		USR_REG_OFFSET(12),
> +		REG_OFFSET(compat_sp_und), /* r13 */
> +		REG_OFFSET(compat_lr_und), /* r14 */
> +		REG_OFFSET(pc)
> +	},
> +};
> +
> +/*
> + * Return a pointer to the register number valid in the current mode of
> + * the virtual CPU.
> + */
> +unsigned long *vcpu_reg32(const struct kvm_vcpu *vcpu, u8 reg_num)
> +{
> +	unsigned long *reg_array = (unsigned long *)&vcpu->arch.ctxt.gp_regs.regs;
> +	unsigned long mode = *vcpu_cpsr(vcpu) & COMPAT_PSR_MODE_MASK;
> +
> +	switch (mode) {
> +	case COMPAT_PSR_MODE_USR ... COMPAT_PSR_MODE_SVC:
> +		mode &= ~PSR_MODE32_BIT; /* 0 ... 3 */
> +		break;
> +
> +	case COMPAT_PSR_MODE_ABT:
> +		mode = 4;
> +		break;
> +
> +	case COMPAT_PSR_MODE_UND:
> +		mode = 5;
> +		break;
> +
> +	case COMPAT_PSR_MODE_SYS:
> +		mode = 0;	/* SYS maps to USR */
> +		break;
> +
> +	default:
> +		BUG();
> +	}
> +
> +	return reg_array + vcpu_reg_offsets[mode][reg_num];
> +}
> +
> +/*
> + * Return the SPSR for the current mode of the virtual CPU.
> + */
> +unsigned long *vcpu_spsr32(const struct kvm_vcpu *vcpu)
> +{
> +	unsigned long mode = *vcpu_cpsr(vcpu) & COMPAT_PSR_MODE_MASK;
> +	switch (mode) {
> +	case COMPAT_PSR_MODE_SVC:
> +		mode = KVM_SPSR_SVC;
> +		break;
> +	case COMPAT_PSR_MODE_ABT:
> +		mode = KVM_SPSR_ABT;
> +		break;
> +	case COMPAT_PSR_MODE_UND:
> +		mode = KVM_SPSR_UND;
> +		break;
> +	case COMPAT_PSR_MODE_IRQ:
> +		mode = KVM_SPSR_IRQ;
> +		break;
> +	case COMPAT_PSR_MODE_FIQ:
> +		mode = KVM_SPSR_FIQ;
> +		break;
> +	default:
> +		BUG();
> +	}
> +
> +	return (unsigned long *)&vcpu_gp_regs(vcpu)->spsr[mode];
> +}
> -- 
> 1.8.1.4
> 
> 
> 
> _______________________________________________
> kvmarm mailing list
> kvmarm at lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm


From cdall at cs.columbia.edu  Tue Apr 23 19:00:57 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Tue, 23 Apr 2013 16:00:57 -0700
Subject: [PATCH v3 25/32] arm64: KVM: 32bit conditional execution emulation
In-Reply-To: <1365437854-30214-26-git-send-email-marc.zyngier@arm.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
 <1365437854-30214-26-git-send-email-marc.zyngier@arm.com>
Message-ID: <20130423230057.GJ20569@gmail.com>

On Mon, Apr 08, 2013 at 05:17:27PM +0100, Marc Zyngier wrote:
> As conditional instructions can trap on AArch32, add the thinest
> possible emulation layer to keep 32bit guests happy.
> 
> Reviewed-by: Christopher Covington <cov at codeaurora.org>
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> ---
>  arch/arm64/include/asm/kvm_emulate.h |  13 ++-
>  arch/arm64/kvm/Makefile              |   2 +-
>  arch/arm64/kvm/emulate.c             | 154 +++++++++++++++++++++++++++++++++++
>  3 files changed, 166 insertions(+), 3 deletions(-)
>  create mode 100644 arch/arm64/kvm/emulate.c
> 
> diff --git a/arch/arm64/include/asm/kvm_emulate.h b/arch/arm64/include/asm/kvm_emulate.h
> index 37a6567..8d4ab33 100644
> --- a/arch/arm64/include/asm/kvm_emulate.h
> +++ b/arch/arm64/include/asm/kvm_emulate.h
> @@ -31,6 +31,9 @@
>  unsigned long *vcpu_reg32(const struct kvm_vcpu *vcpu, u8 reg_num);
>  unsigned long *vcpu_spsr32(const struct kvm_vcpu *vcpu);
>  
> +bool kvm_condition_valid32(const struct kvm_vcpu *vcpu);
> +void kvm_skip_instr32(struct kvm_vcpu *vcpu, bool is_wide_instr);
> +
>  void kvm_inject_undefined(struct kvm_vcpu *vcpu);
>  void kvm_inject_dabt(struct kvm_vcpu *vcpu, unsigned long addr);
>  void kvm_inject_pabt(struct kvm_vcpu *vcpu, unsigned long addr);
> @@ -57,12 +60,18 @@ static inline bool vcpu_mode_is_32bit(const struct kvm_vcpu *vcpu)
>  
>  static inline bool kvm_condition_valid(const struct kvm_vcpu *vcpu)
>  {
> -	return true;	/* No conditionals on arm64 */
> +	if (vcpu_mode_is_32bit(vcpu))
> +		return kvm_condition_valid32(vcpu);
> +
> +	return true;
>  }
>  
>  static inline void kvm_skip_instr(struct kvm_vcpu *vcpu, bool is_wide_instr)
>  {
> -	*vcpu_pc(vcpu) += 4;
> +	if (vcpu_mode_is_32bit(vcpu))
> +		kvm_skip_instr32(vcpu, is_wide_instr);
> +	else
> +		*vcpu_pc(vcpu) += 4;
>  }
>  
>  static inline void vcpu_set_thumb(struct kvm_vcpu *vcpu)
> diff --git a/arch/arm64/kvm/Makefile b/arch/arm64/kvm/Makefile
> index 1668448..88c6639 100644
> --- a/arch/arm64/kvm/Makefile
> +++ b/arch/arm64/kvm/Makefile
> @@ -11,7 +11,7 @@ obj-$(CONFIG_KVM_ARM_HOST) += kvm.o
>  kvm-$(CONFIG_KVM_ARM_HOST) += $(addprefix ../../../virt/kvm/, kvm_main.o coalesced_mmio.o)
>  kvm-$(CONFIG_KVM_ARM_HOST) += $(addprefix ../../../arch/arm/kvm/, arm.o mmu.o mmio.o psci.o perf.o)
>  
> -kvm-$(CONFIG_KVM_ARM_HOST) += inject_fault.o regmap.o
> +kvm-$(CONFIG_KVM_ARM_HOST) += emulate.o inject_fault.o regmap.o
>  kvm-$(CONFIG_KVM_ARM_HOST) += hyp.o hyp-init.o handle_exit.o
>  kvm-$(CONFIG_KVM_ARM_HOST) += guest.o reset.o sys_regs.o sys_regs_generic_v8.o
>  
> diff --git a/arch/arm64/kvm/emulate.c b/arch/arm64/kvm/emulate.c
> new file mode 100644
> index 0000000..01d4713
> --- /dev/null
> +++ b/arch/arm64/kvm/emulate.c
> @@ -0,0 +1,154 @@
> +/*
> + * (not much of an) Emulation layer for 32bit guests.
> + *
> + * Copyright (C) 2012 - Virtual Open Systems and Columbia University
> + * Author: Christoffer Dall <c.dall at virtualopensystems.com>

don't you want to add yourself here?

> + *
> + * 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.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +#include <linux/kvm_host.h>
> +#include <asm/kvm_emulate.h>
> +
> +/*
> + * stolen from arch/arm/kernel/opcodes.c
> + *
> + * condition code lookup table
> + * index into the table is test code: EQ, NE, ... LT, GT, AL, NV
> + *
> + * bit position in short is condition code: NZCV
> + */
> +static const unsigned short cc_map[16] = {
> +	0xF0F0,			/* EQ == Z set            */
> +	0x0F0F,			/* NE                     */
> +	0xCCCC,			/* CS == C set            */
> +	0x3333,			/* CC                     */
> +	0xFF00,			/* MI == N set            */
> +	0x00FF,			/* PL                     */
> +	0xAAAA,			/* VS == V set            */
> +	0x5555,			/* VC                     */
> +	0x0C0C,			/* HI == C set && Z clear */
> +	0xF3F3,			/* LS == C clear || Z set */
> +	0xAA55,			/* GE == (N==V)           */
> +	0x55AA,			/* LT == (N!=V)           */
> +	0x0A05,			/* GT == (!Z && (N==V))   */
> +	0xF5FA,			/* LE == (Z || (N!=V))    */
> +	0xFFFF,			/* AL always              */
> +	0			/* NV                     */
> +};
> +
> +static int kvm_vcpu_get_condition(const struct kvm_vcpu *vcpu)
> +{
> +	u32 esr = kvm_vcpu_get_hsr(vcpu);
> +
> +	if (esr & ESR_EL2_CV)
> +		return (esr & ESR_EL2_COND) >> ESR_EL2_COND_SHIFT;
> +
> +	return -1;
> +}
> +
> +/*
> + * Check if a trapped instruction should have been executed or not.
> + */
> +bool kvm_condition_valid32(const struct kvm_vcpu *vcpu)
> +{
> +	unsigned long cpsr;
> +	u32 cpsr_cond;
> +	int cond;
> +
> +	/* Top two bits non-zero?  Unconditional. */
> +	if (kvm_vcpu_get_hsr(vcpu) >> 30)
> +		return true;
> +
> +	/* Is condition field valid? */
> +	cond = kvm_vcpu_get_condition(vcpu);
> +	if (cond == 0xE)
> +		return true;
> +
> +	cpsr = *vcpu_cpsr(vcpu);
> +
> +	if (cond < 0) {
> +		/* This can happen in Thumb mode: examine IT state. */
> +		unsigned long it;
> +
> +		it = ((cpsr >> 8) & 0xFC) | ((cpsr >> 25) & 0x3);
> +
> +		/* it == 0 => unconditional. */
> +		if (it == 0)
> +			return true;
> +
> +		/* The cond for this insn works out as the top 4 bits. */
> +		cond = (it >> 4);
> +	}
> +
> +	cpsr_cond = cpsr >> 28;
> +
> +	if (!((cc_map[cond] >> cpsr_cond) & 1))
> +		return false;
> +
> +	return true;
> +}
> +
> +/**
> + * adjust_itstate - adjust ITSTATE when emulating instructions in IT-block
> + * @vcpu:	The VCPU pointer
> + *
> + * When exceptions occur while instructions are executed in Thumb IF-THEN
> + * blocks, the ITSTATE field of the CPSR is not advanved (updated), so we have

s/advanved/advanced/

> + * to do this little bit of work manually. The fields map like this:
> + *
> + * IT[7:0] -> CPSR[26:25],CPSR[15:10]
> + */
> +static void kvm_adjust_itstate(struct kvm_vcpu *vcpu)
> +{
> +	unsigned long itbits, cond;
> +	unsigned long cpsr = *vcpu_cpsr(vcpu);
> +	bool is_arm = !(cpsr & COMPAT_PSR_T_BIT);
> +
> +	BUG_ON(is_arm && (cpsr & COMPAT_PSR_IT_MASK));
> +
> +	if (!(cpsr & COMPAT_PSR_IT_MASK))
> +		return;
> +
> +	cond = (cpsr & 0xe000) >> 13;
> +	itbits = (cpsr & 0x1c00) >> (10 - 2);
> +	itbits |= (cpsr & (0x3 << 25)) >> 25;
> +
> +	/* Perform ITAdvance (see page A-52 in ARM DDI 0406C) */

That's actually page A2-52 to be a little more precise...

> +	if ((itbits & 0x7) == 0)
> +		itbits = cond = 0;
> +	else
> +		itbits = (itbits << 1) & 0x1f;
> +
> +	cpsr &= ~COMPAT_PSR_IT_MASK;
> +	cpsr |= cond << 13;
> +	cpsr |= (itbits & 0x1c) << (10 - 2);
> +	cpsr |= (itbits & 0x3) << 25;
> +	*vcpu_cpsr(vcpu) = cpsr;
> +}
> +
> +/**
> + * kvm_skip_instr - skip a trapped instruction and proceed to the next
> + * @vcpu: The vcpu pointer
> + */
> +void kvm_skip_instr32(struct kvm_vcpu *vcpu, bool is_wide_instr)
> +{
> +	bool is_thumb;
> +
> +	is_thumb = !!(*vcpu_cpsr(vcpu) & COMPAT_PSR_T_BIT);

again we don't need the '!!' when it's a bool.

> +	if (is_thumb && !is_wide_instr)
> +		*vcpu_pc(vcpu) += 2;
> +	else
> +		*vcpu_pc(vcpu) += 4;
> +	kvm_adjust_itstate(vcpu);
> +}
> -- 
> 1.8.1.4
> 
> 
> 
> _______________________________________________
> kvmarm mailing list
> kvmarm at lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm


From cdall at cs.columbia.edu  Tue Apr 23 19:01:38 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Tue, 23 Apr 2013 16:01:38 -0700
Subject: [PATCH v3 10/32] arm64: KVM: system register handling
In-Reply-To: <1365437854-30214-11-git-send-email-marc.zyngier@arm.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
 <1365437854-30214-11-git-send-email-marc.zyngier@arm.com>
Message-ID: <20130423230138.GK20569@gmail.com>

On Mon, Apr 08, 2013 at 05:17:12PM +0100, Marc Zyngier wrote:
> Provide 64bit system register handling, modeled after the cp15
> handling for ARM.
>
> Reviewed-by: Christopher Covington <cov at codeaurora.org>
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> ---
>  arch/arm64/include/asm/kvm_coproc.h |  51 +++
>  arch/arm64/include/uapi/asm/kvm.h   |  29 ++
>  arch/arm64/kvm/sys_regs.c           | 871 ++++++++++++++++++++++++++++++++++++
>  arch/arm64/kvm/sys_regs.h           | 138 ++++++
>  include/uapi/linux/kvm.h            |   1 +
>  5 files changed, 1090 insertions(+)
>  create mode 100644 arch/arm64/include/asm/kvm_coproc.h
>  create mode 100644 arch/arm64/kvm/sys_regs.c
>  create mode 100644 arch/arm64/kvm/sys_regs.h
>
> diff --git a/arch/arm64/include/asm/kvm_coproc.h b/arch/arm64/include/asm/kvm_coproc.h
> new file mode 100644
> index 0000000..9b4477a
> --- /dev/null
> +++ b/arch/arm64/include/asm/kvm_coproc.h
> @@ -0,0 +1,51 @@
> +/*
> + * Copyright (C) 2012,2013 - ARM Ltd
> + * Author: Marc Zyngier <marc.zyngier at arm.com>
> + *
> + * Derived from arch/arm/include/asm/kvm_coproc.h
> + * Copyright (C) 2012 Rusty Russell IBM Corporation
> + *
> + * 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.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +#ifndef __ARM64_KVM_COPROC_H__
> +#define __ARM64_KVM_COPROC_H__
> +
> +#include <linux/kvm_host.h>
> +
> +void kvm_reset_sys_regs(struct kvm_vcpu *vcpu);
> +
> +struct kvm_sys_reg_table {
> + const struct sys_reg_desc *table;
> + size_t num;
> +};
> +
> +struct kvm_sys_reg_target_table {
> + struct kvm_sys_reg_table table64;
> +};
> +
> +void kvm_register_target_sys_reg_table(unsigned int target,
> +       struct kvm_sys_reg_target_table *table);
> +
> +int kvm_handle_sys_reg(struct kvm_vcpu *vcpu, struct kvm_run *run);
> +
> +#define kvm_coproc_table_init kvm_sys_reg_table_init
> +void kvm_sys_reg_table_init(void);
> +
> +struct kvm_one_reg;
> +int kvm_arm_copy_sys_reg_indices(struct kvm_vcpu *vcpu, u64 __user *uindices);
> +int kvm_arm_sys_reg_get_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *);
> +int kvm_arm_sys_reg_set_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *);
> +unsigned long kvm_arm_num_sys_reg_descs(struct kvm_vcpu *vcpu);
> +
> +#endif /* __ARM64_KVM_COPROC_H__ */
> diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
> index 4e64570..ebac919 100644
> --- a/arch/arm64/include/uapi/asm/kvm.h
> +++ b/arch/arm64/include/uapi/asm/kvm.h
> @@ -92,6 +92,35 @@ struct kvm_sync_regs {
>  struct kvm_arch_memory_slot {
>  };
>  
> +/* If you need to interpret the index values, here is the key: */
> +#define KVM_REG_ARM_COPROC_MASK 0x000000000FFF0000
> +#define KVM_REG_ARM_COPROC_SHIFT 16
> +
> +/* Normal registers are mapped as coprocessor 16. */
> +#define KVM_REG_ARM_CORE (0x0010 << KVM_REG_ARM_COPROC_SHIFT)
> +#define KVM_REG_ARM_CORE_REG(name) (offsetof(struct kvm_regs, name) / sizeof(__u32))
> +
> +/* Some registers need more space to represent values. */
> +#define KVM_REG_ARM_DEMUX (0x0011 << KVM_REG_ARM_COPROC_SHIFT)
> +#define KVM_REG_ARM_DEMUX_ID_MASK 0x000000000000FF00
> +#define KVM_REG_ARM_DEMUX_ID_SHIFT 8
> +#define KVM_REG_ARM_DEMUX_ID_CCSIDR (0x00 << KVM_REG_ARM_DEMUX_ID_SHIFT)
> +#define KVM_REG_ARM_DEMUX_VAL_MASK 0x00000000000000FF
> +#define KVM_REG_ARM_DEMUX_VAL_SHIFT 0
> +
> +/* AArch64 system registers */
> +#define KVM_REG_ARM64_SYSREG (0x0013 << KVM_REG_ARM_COPROC_SHIFT)
> +#define KVM_REG_ARM64_SYSREG_OP0_MASK 0x000000000000c000
> +#define KVM_REG_ARM64_SYSREG_OP0_SHIFT 14
> +#define KVM_REG_ARM64_SYSREG_OP1_MASK 0x0000000000003800
> +#define KVM_REG_ARM64_SYSREG_OP1_SHIFT 11
> +#define KVM_REG_ARM64_SYSREG_CRN_MASK 0x0000000000000780
> +#define KVM_REG_ARM64_SYSREG_CRN_SHIFT 7
> +#define KVM_REG_ARM64_SYSREG_CRM_MASK 0x0000000000000078
> +#define KVM_REG_ARM64_SYSREG_CRM_SHIFT 3
> +#define KVM_REG_ARM64_SYSREG_OP2_MASK 0x0000000000000007
> +#define KVM_REG_ARM64_SYSREG_OP2_SHIFT 0
> +
>  /* KVM_IRQ_LINE irq field index values */
>  #define KVM_ARM_IRQ_TYPE_SHIFT 24
>  #define KVM_ARM_IRQ_TYPE_MASK 0xff
> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> new file mode 100644
> index 0000000..9df3b32
> --- /dev/null
> +++ b/arch/arm64/kvm/sys_regs.c
> @@ -0,0 +1,871 @@
> +/*
> + * Copyright (C) 2012,2013 - ARM Ltd
> + * Author: Marc Zyngier <marc.zyngier at arm.com>
> + *
> + * Derived from arch/arm/kvm/coproc.c:
> + * Copyright (C) 2012 - Virtual Open Systems and Columbia University
> + * Authors: Rusty Russell <rusty at rustcorp.com.au>
> + *          Christoffer Dall <c.dall at virtualopensystems.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.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +#include <linux/mm.h>
> +#include <linux/kvm_host.h>
> +#include <linux/uaccess.h>
> +#include <asm/kvm_arm.h>
> +#include <asm/kvm_host.h>
> +#include <asm/kvm_emulate.h>
> +#include <asm/kvm_coproc.h>
> +#include <asm/cacheflush.h>
> +#include <asm/cputype.h>
> +#include <trace/events/kvm.h>
> +
> +#include "sys_regs.h"
> +
> +/*
> + * All of this file is extremly similar to the ARM coproc.c, but the
> + * types are different. My gut feeling is that it should be pretty
> + * easy to merge, but that would be an ABI breakage -- again. VFP
> + * would also need to be abstracted.
> + */

What API would we break here by sharing more of the code? Can you
elaborate.

VFP should probably be separated into its own file on the arm side as
well in any case.

> +
> +/* 3 bits per cache level, as per CLIDR, but non-existent caches always 0 */
> +static u32 cache_levels;
> +
> +/* CSSELR values; used to index KVM_REG_ARM_DEMUX_ID_CCSIDR */
> +#define CSSELR_MAX 12
> +
> +/* Which cache CCSIDR represents depends on CSSELR value. */
> +static u32 get_ccsidr(u32 csselr)
> +{
> + u32 ccsidr;
> +
> + /* Make sure noone else changes CSSELR during this! */
> + local_irq_disable();
> + /* Put value into CSSELR */
> + asm volatile("msr csselr_el1, %x0" : : "r" (csselr));
> + /* Read result out of CCSIDR */
> + asm volatile("mrs %0, ccsidr_el1" : "=r" (ccsidr));
> + local_irq_enable();
> +
> + return ccsidr;
> +}
> +
> +static void do_dc_cisw(u32 val)
> +{
> + asm volatile("dc cisw, %x0" : : "r" (val));
> +}
> +
> +static void do_dc_csw(u32 val)
> +{
> + asm volatile("dc csw, %x0" : : "r" (val));
> +}
> +
> +/* See note at ARM ARM B1.14.4 */
> +static bool access_dcsw(struct kvm_vcpu *vcpu,
> + const struct sys_reg_params *p,
> + const struct sys_reg_desc *r)
> +{
> + unsigned long val;
> + int cpu;
> +
> + cpu = get_cpu();

you have that unbalanced get_cpu here again, but you know that
already...

> +
> + if (!p->is_write)
> + return read_from_write_only(vcpu, p);
> +
> + cpumask_setall(&vcpu->arch.require_dcache_flush);
> + cpumask_clear_cpu(cpu, &vcpu->arch.require_dcache_flush);
> +
> + /* If we were already preempted, take the long way around */
> + if (cpu != vcpu->arch.last_pcpu) {
> + flush_cache_all();
> + goto done;
> + }
> +
> + val = *vcpu_reg(vcpu, p->Rt);
> +
> + switch (p->CRm) {
> + case 6: /* Upgrade DCISW to DCCISW, as per HCR.SWIO */
> + case 14: /* DCCISW */
> + do_dc_cisw(val);
> + break;
> +
> + case 10: /* DCCSW */
> + do_dc_csw(val);
> + break;
> + }
> +
> +done:
> + put_cpu();
> +
> + return true;
> +}
> +
> +/*
> + * We could trap ID_DFR0 and tell the guest we don't support performance
> + * monitoring.  Unfortunately the patch to make the kernel check ID_DFR0 was
> + * NAKed, so it will read the PMCR anyway.
> + *
> + * Therefore we tell the guest we have 0 counters.  Unfortunately, we
> + * must always support PMCCNTR (the cycle counter): we just RAZ/WI for
> + * all PM registers, which doesn't crash the guest kernel at least.
> + */
> +static bool pm_fake(struct kvm_vcpu *vcpu,
> +    const struct sys_reg_params *p,
> +    const struct sys_reg_desc *r)
> +{
> + if (p->is_write)
> + return ignore_write(vcpu, p);
> + else
> + return read_zero(vcpu, p);
> +}
> +
> +static void reset_amair_el1(struct kvm_vcpu *vcpu, const struct sys_reg_desc *r)
> +{
> + u64 amair;
> +
> + asm volatile("mrs %0, amair_el1\n" : "=r" (amair));
> + vcpu_sys_reg(vcpu, AMAIR_EL1) = amair;
> +}
> +
> +static void reset_mpidr(struct kvm_vcpu *vcpu, const struct sys_reg_desc *r)
> +{
> + /*
> + * Simply map the vcpu_id into the Aff0 field of the MPIDR.
> + */
> + vcpu_sys_reg(vcpu, MPIDR_EL1) = (1 << 31) | (vcpu->vcpu_id & 0xff);
> +}
> +
> +/*
> + * Architected system registers.
> + * Important: Must be sorted ascending by Op0, Op1, CRn, CRm, Op2
> + */
> +static const struct sys_reg_desc sys_reg_descs[] = {
> + /* DC ISW */
> + { Op0(0b01), Op1(0b000), CRn(0b0111), CRm(0b0110), Op2(0b010),
> +  access_dcsw },
> + /* DC CSW */
> + { Op0(0b01), Op1(0b000), CRn(0b0111), CRm(0b1010), Op2(0b010),
> +  access_dcsw },
> + /* DC CISW */
> + { Op0(0b01), Op1(0b000), CRn(0b0111), CRm(0b1110), Op2(0b010),
> +  access_dcsw },
> +
> + /* MPIDR_EL1 */
> + { Op0(0b11), Op1(0b000), CRn(0b0000), CRm(0b0000), Op2(0b101),
> +  NULL, reset_mpidr, MPIDR_EL1 },
> + /* SCTLR_EL1 */
> + { Op0(0b11), Op1(0b000), CRn(0b0001), CRm(0b0000), Op2(0b000),
> +  NULL, reset_val, SCTLR_EL1, 0x00C50078 },
> + /* CPACR_EL1 */
> + { Op0(0b11), Op1(0b000), CRn(0b0001), CRm(0b0000), Op2(0b010),
> +  NULL, reset_val, CPACR_EL1, 0 },
> + /* TTBR0_EL1 */
> + { Op0(0b11), Op1(0b000), CRn(0b0010), CRm(0b0000), Op2(0b000),
> +  NULL, reset_unknown, TTBR0_EL1 },
> + /* TTBR1_EL1 */
> + { Op0(0b11), Op1(0b000), CRn(0b0010), CRm(0b0000), Op2(0b001),
> +  NULL, reset_unknown, TTBR1_EL1 },
> + /* TCR_EL1 */
> + { Op0(0b11), Op1(0b000), CRn(0b0010), CRm(0b0000), Op2(0b010),
> +  NULL, reset_val, TCR_EL1, 0 },
> +
> + /* AFSR0_EL1 */
> + { Op0(0b11), Op1(0b000), CRn(0b0101), CRm(0b0001), Op2(0b000),
> +  NULL, reset_unknown, AFSR0_EL1 },
> + /* AFSR1_EL1 */
> + { Op0(0b11), Op1(0b000), CRn(0b0101), CRm(0b0001), Op2(0b001),
> +  NULL, reset_unknown, AFSR1_EL1 },
> + /* ESR_EL1 */
> + { Op0(0b11), Op1(0b000), CRn(0b0101), CRm(0b0010), Op2(0b000),
> +  NULL, reset_unknown, ESR_EL1 },
> + /* FAR_EL1 */
> + { Op0(0b11), Op1(0b000), CRn(0b0110), CRm(0b0000), Op2(0b000),
> +  NULL, reset_unknown, FAR_EL1 },
> +
> + /* PMINTENSET_EL1 */
> + { Op0(0b11), Op1(0b000), CRn(0b1001), CRm(0b1110), Op2(0b001),
> +  pm_fake },
> + /* PMINTENCLR_EL1 */
> + { Op0(0b11), Op1(0b000), CRn(0b1001), CRm(0b1110), Op2(0b010),
> +  pm_fake },
> +
> + /* MAIR_EL1 */
> + { Op0(0b11), Op1(0b000), CRn(0b1010), CRm(0b0010), Op2(0b000),
> +  NULL, reset_unknown, MAIR_EL1 },
> + /* AMAIR_EL1 */
> + { Op0(0b11), Op1(0b000), CRn(0b1010), CRm(0b0011), Op2(0b000),
> +  NULL, reset_amair_el1, AMAIR_EL1 },
> +
> + /* VBAR_EL1 */
> + { Op0(0b11), Op1(0b000), CRn(0b1100), CRm(0b0000), Op2(0b000),
> +  NULL, reset_val, VBAR_EL1, 0 },
> + /* CONTEXTIDR_EL1 */
> + { Op0(0b11), Op1(0b000), CRn(0b1101), CRm(0b0000), Op2(0b001),
> +  NULL, reset_val, CONTEXTIDR_EL1, 0 },
> + /* TPIDR_EL1 */
> + { Op0(0b11), Op1(0b000), CRn(0b1101), CRm(0b0000), Op2(0b100),
> +  NULL, reset_unknown, TPIDR_EL1 },
> +
> + /* CNTKCTL_EL1 */
> + { Op0(0b11), Op1(0b000), CRn(0b1110), CRm(0b0001), Op2(0b000),
> +  NULL, reset_val, CNTKCTL_EL1, 0},
> +
> + /* CSSELR_EL1 */
> + { Op0(0b11), Op1(0b010), CRn(0b0000), CRm(0b0000), Op2(0b000),
> +  NULL, reset_unknown, CSSELR_EL1 },
> +
> + /* PMCR_EL0 */
> + { Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b000),
> +  pm_fake },
> + /* PMCNTENSET_EL0 */
> + { Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b001),
> +  pm_fake },
> + /* PMCNTENCLR_EL0 */
> + { Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b010),
> +  pm_fake },
> + /* PMOVSCLR_EL0 */
> + { Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b011),
> +  pm_fake },
> + /* PMSWINC_EL0 */
> + { Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b100),
> +  pm_fake },
> + /* PMSELR_EL0 */
> + { Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b101),
> +  pm_fake },
> + /* PMCEID0_EL0 */
> + { Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b110),
> +  pm_fake },
> + /* PMCEID1_EL0 */
> + { Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b111),
> +  pm_fake },
> + /* PMCCNTR_EL0 */
> + { Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1101), Op2(0b000),
> +  pm_fake },
> + /* PMXEVTYPER_EL0 */
> + { Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1101), Op2(0b001),
> +  pm_fake },
> + /* PMXEVCNTR_EL0 */
> + { Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1101), Op2(0b010),
> +  pm_fake },
> + /* PMUSERENR_EL0 */
> + { Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1110), Op2(0b000),
> +  pm_fake },
> + /* PMOVSSET_EL0 */
> + { Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1110), Op2(0b011),
> +  pm_fake },
> +
> + /* TPIDR_EL0 */
> + { Op0(0b11), Op1(0b011), CRn(0b1101), CRm(0b0000), Op2(0b010),
> +  NULL, reset_unknown, TPIDR_EL0 },
> + /* TPIDRRO_EL0 */
> + { Op0(0b11), Op1(0b011), CRn(0b1101), CRm(0b0000), Op2(0b011),
> +  NULL, reset_unknown, TPIDRRO_EL0 },
> +};
> +
> +/* Target specific emulation tables */
> +static struct kvm_sys_reg_target_table *target_tables[KVM_ARM_NUM_TARGETS];
> +
> +void kvm_register_target_sys_reg_table(unsigned int target,
> +       struct kvm_sys_reg_target_table *table)
> +{
> + target_tables[target] = table;
> +}
> +
> +/* Get specific register table for this target. */
> +static const struct sys_reg_desc *get_target_table(unsigned target, size_t *num)
> +{
> + struct kvm_sys_reg_target_table *table;
> +
> + table = target_tables[target];
> + *num = table->table64.num;
> + return table->table64.table;
> +}
> +
> +static const struct sys_reg_desc *find_reg(const struct sys_reg_params *params,
> + const struct sys_reg_desc table[],
> + unsigned int num)
> +{
> + unsigned int i;
> +
> + for (i = 0; i < num; i++) {
> + const struct sys_reg_desc *r = &table[i];
> +
> + if (params->Op0 != r->Op0)
> + continue;
> + if (params->Op1 != r->Op1)
> + continue;
> + if (params->CRn != r->CRn)
> + continue;
> + if (params->CRm != r->CRm)
> + continue;
> + if (params->Op2 != r->Op2)
> + continue;
> +
> + return r;
> + }
> + return NULL;
> +}
> +
> +static int emulate_sys_reg(struct kvm_vcpu *vcpu,
> +   const struct sys_reg_params *params)
> +{
> + size_t num;
> + const struct sys_reg_desc *table, *r;
> +
> + table = get_target_table(vcpu->arch.target, &num);
> +
> + /* Search target-specific then generic table. */
> + r = find_reg(params, table, num);
> + if (!r)
> + r = find_reg(params, sys_reg_descs, ARRAY_SIZE(sys_reg_descs));
> +
> + if (likely(r)) {
> + /* If we don't have an accessor, we should never get here! */
> + BUG_ON(!r->access);

that's a little rough, you don't have to stop the entire host kernel...

> +
> + if (likely(r->access(vcpu, params, r))) {
> + /* Skip instruction, since it was emulated */
> + kvm_skip_instr(vcpu, kvm_vcpu_trap_il_is32bit(vcpu));
> + return 1;
> + }
> + /* If access function fails, it should complain. */
> + } else {
> + kvm_err("Unsupported guest sys_reg access at: %lx\n",
> + *vcpu_pc(vcpu));
> + print_sys_reg_instr(params);
> + }
> + kvm_inject_undefined(vcpu);
> + return 1;
> +}
> +
> +static void reset_sys_reg_descs(struct kvm_vcpu *vcpu,
> +      const struct sys_reg_desc *table, size_t num)
> +{
> + unsigned long i;
> +
> + for (i = 0; i < num; i++)
> + if (table[i].reset)
> + table[i].reset(vcpu, &table[i]);
> +}
> +
> +/**
> + * kvm_handle_sys_reg -- handles a mrs/msr trap on a guest sys_reg access
> + * @vcpu: The VCPU pointer
> + * @run:  The kvm_run struct
> + */
> +int kvm_handle_sys_reg(struct kvm_vcpu *vcpu, struct kvm_run *run)
> +{
> + struct sys_reg_params params;
> + unsigned long esr = kvm_vcpu_get_hsr(vcpu);
> +
> + params.Op0 = (esr >> 20) & 3;
> + params.Op1 = (esr >> 14) & 0x7;
> + params.CRn = (esr >> 10) & 0xf;
> + params.CRm = (esr >> 1) & 0xf;
> + params.Op2 = (esr >> 17) & 0x7;
> + params.Rt = (esr >> 5) & 0x1f;
> + params.is_write = !(esr & 1);
> +
> + return emulate_sys_reg(vcpu, &params);
> +}
> +
> +/******************************************************************************
> + * Userspace API
> + *****************************************************************************/
> +
> +static bool index_to_params(u64 id, struct sys_reg_params *params)
> +{
> + switch (id & KVM_REG_SIZE_MASK) {
> + case KVM_REG_SIZE_U64:
> + /* Any unused index bits means it's not valid. */
> + if (id & ~(KVM_REG_ARCH_MASK | KVM_REG_SIZE_MASK
> +      | KVM_REG_ARM_COPROC_MASK
> +      | KVM_REG_ARM64_SYSREG_OP0_MASK
> +      | KVM_REG_ARM64_SYSREG_OP1_MASK
> +      | KVM_REG_ARM64_SYSREG_CRN_MASK
> +      | KVM_REG_ARM64_SYSREG_CRM_MASK
> +      | KVM_REG_ARM64_SYSREG_OP2_MASK))
> + return false;
> + params->Op0 = ((id & KVM_REG_ARM64_SYSREG_OP0_MASK)
> +       >> KVM_REG_ARM64_SYSREG_OP0_SHIFT);
> + params->Op1 = ((id & KVM_REG_ARM64_SYSREG_OP1_MASK)
> +       >> KVM_REG_ARM64_SYSREG_OP1_SHIFT);
> + params->CRn = ((id & KVM_REG_ARM64_SYSREG_CRN_MASK)
> +       >> KVM_REG_ARM64_SYSREG_CRN_SHIFT);
> + params->CRm = ((id & KVM_REG_ARM64_SYSREG_CRM_MASK)
> +       >> KVM_REG_ARM64_SYSREG_CRM_SHIFT);
> + params->Op2 = ((id & KVM_REG_ARM64_SYSREG_OP2_MASK)
> +       >> KVM_REG_ARM64_SYSREG_OP2_SHIFT);
> + return true;
> + default:
> + return false;
> + }
> +}
> +
> +/* Decode an index value, and find the sys_reg_desc entry. */
> +static const struct sys_reg_desc *index_to_sys_reg_desc(struct kvm_vcpu *vcpu,
> +    u64 id)
> +{
> + size_t num;
> + const struct sys_reg_desc *table, *r;
> + struct sys_reg_params params;
> +
> + /* We only do sys_reg for now. */
> + if ((id & KVM_REG_ARM_COPROC_MASK) != KVM_REG_ARM64_SYSREG)
> + return NULL;
> +
> + if (!index_to_params(id, &params))
> + return NULL;
> +
> + table = get_target_table(vcpu->arch.target, &num);
> + r = find_reg(&params, table, num);
> + if (!r)
> + r = find_reg(&params, sys_reg_descs, ARRAY_SIZE(sys_reg_descs));
> +
> + /* Not saved in the sys_reg array? */
> + if (r && !r->reg)
> + r = NULL;
> +
> + return r;
> +}
> +
> +/*
> + * These are the invariant sys_reg registers: we let the guest see the
> + * host versions of these, so they're part of the guest state.
> + *
> + * A future CPU may provide a mechanism to present different values to
> + * the guest, or a future kvm may trap them.
> + */
> +
> +#define FUNCTION_INVARIANT(reg) \
> + static void get_##reg(struct kvm_vcpu *v, \
> +      const struct sys_reg_desc *r) \
> + { \
> + u64 val; \
> + \
> + asm volatile("mrs %0, " __stringify(reg) "\n" \
> +     : "=r" (val)); \
> + ((struct sys_reg_desc *)r)->val = val; \
> + }
> +
> +FUNCTION_INVARIANT(midr_el1)
> +FUNCTION_INVARIANT(ctr_el0)
> +FUNCTION_INVARIANT(revidr_el1)
> +FUNCTION_INVARIANT(id_pfr0_el1)
> +FUNCTION_INVARIANT(id_pfr1_el1)
> +FUNCTION_INVARIANT(id_dfr0_el1)
> +FUNCTION_INVARIANT(id_afr0_el1)
> +FUNCTION_INVARIANT(id_mmfr0_el1)
> +FUNCTION_INVARIANT(id_mmfr1_el1)
> +FUNCTION_INVARIANT(id_mmfr2_el1)
> +FUNCTION_INVARIANT(id_mmfr3_el1)
> +FUNCTION_INVARIANT(id_isar0_el1)
> +FUNCTION_INVARIANT(id_isar1_el1)
> +FUNCTION_INVARIANT(id_isar2_el1)
> +FUNCTION_INVARIANT(id_isar3_el1)
> +FUNCTION_INVARIANT(id_isar4_el1)
> +FUNCTION_INVARIANT(id_isar5_el1)
> +FUNCTION_INVARIANT(clidr_el1)
> +FUNCTION_INVARIANT(aidr_el1)
> +
> +/* ->val is filled in by kvm_invariant_sys_reg_table_init() */

kvm_sys_reg_table_init ?

> +static struct sys_reg_desc invariant_sys_regs[] = {
> + { Op0(0b11), Op1(0b000), CRn(0b0000), CRm(0b0000), Op2(0b000),
> +  NULL, get_midr_el1 },
> + { Op0(0b11), Op1(0b000), CRn(0b0000), CRm(0b0000), Op2(0b110),
> +  NULL, get_revidr_el1 },
> + { Op0(0b11), Op1(0b000), CRn(0b0000), CRm(0b0001), Op2(0b000),
> +  NULL, get_id_pfr0_el1 },
> + { Op0(0b11), Op1(0b000), CRn(0b0000), CRm(0b0001), Op2(0b001),
> +  NULL, get_id_pfr1_el1 },
> + { Op0(0b11), Op1(0b000), CRn(0b0000), CRm(0b0001), Op2(0b010),
> +  NULL, get_id_dfr0_el1 },
> + { Op0(0b11), Op1(0b000), CRn(0b0000), CRm(0b0001), Op2(0b011),
> +  NULL, get_id_afr0_el1 },
> + { Op0(0b11), Op1(0b000), CRn(0b0000), CRm(0b0001), Op2(0b100),
> +  NULL, get_id_mmfr0_el1 },
> + { Op0(0b11), Op1(0b000), CRn(0b0000), CRm(0b0001), Op2(0b101),
> +  NULL, get_id_mmfr1_el1 },
> + { Op0(0b11), Op1(0b000), CRn(0b0000), CRm(0b0001), Op2(0b110),
> +  NULL, get_id_mmfr2_el1 },
> + { Op0(0b11), Op1(0b000), CRn(0b0000), CRm(0b0001), Op2(0b111),
> +  NULL, get_id_mmfr3_el1 },
> + { Op0(0b11), Op1(0b000), CRn(0b0000), CRm(0b0010), Op2(0b000),
> +  NULL, get_id_isar0_el1 },
> + { Op0(0b11), Op1(0b000), CRn(0b0000), CRm(0b0010), Op2(0b001),
> +  NULL, get_id_isar1_el1 },
> + { Op0(0b11), Op1(0b000), CRn(0b0000), CRm(0b0010), Op2(0b010),
> +  NULL, get_id_isar2_el1 },
> + { Op0(0b11), Op1(0b000), CRn(0b0000), CRm(0b0010), Op2(0b011),
> +  NULL, get_id_isar3_el1 },
> + { Op0(0b11), Op1(0b000), CRn(0b0000), CRm(0b0010), Op2(0b100),
> +  NULL, get_id_isar4_el1 },
> + { Op0(0b11), Op1(0b000), CRn(0b0000), CRm(0b0010), Op2(0b101),
> +  NULL, get_id_isar5_el1 },
> + { Op0(0b11), Op1(0b001), CRn(0b0000), CRm(0b0000), Op2(0b001),
> +  NULL, get_clidr_el1 },
> + { Op0(0b11), Op1(0b001), CRn(0b0000), CRm(0b0000), Op2(0b111),
> +  NULL, get_aidr_el1 },
> + { Op0(0b11), Op1(0b011), CRn(0b0000), CRm(0b0000), Op2(0b001),
> +  NULL, get_ctr_el0 },
> +};

would you consider using spaces instead of tabs here, this becomes completely unreadable on an 80 chars display...

> +
> +static int reg_from_user(void *val, const void __user *uaddr, u64 id)
> +{
> + /* This Just Works because we are little endian. */
> + if (copy_from_user(val, uaddr, KVM_REG_SIZE(id)) != 0)
> + return -EFAULT;
> + return 0;
> +}
> +
> +static int reg_to_user(void __user *uaddr, const void *val, u64 id)
> +{
> + /* This Just Works because we are little endian. */
> + if (copy_to_user(uaddr, val, KVM_REG_SIZE(id)) != 0)
> + return -EFAULT;
> + return 0;
> +}
> +
> +static int get_invariant_sys_reg(u64 id, void __user *uaddr)
> +{
> + struct sys_reg_params params;
> + const struct sys_reg_desc *r;
> +
> + if (!index_to_params(id, &params))
> + return -ENOENT;
> +
> + r = find_reg(&params, invariant_sys_regs, ARRAY_SIZE(invariant_sys_regs));
> + if (!r)
> + return -ENOENT;
> +
> + return reg_to_user(uaddr, &r->val, id);
> +}
> +
> +static int set_invariant_sys_reg(u64 id, void __user *uaddr)
> +{
> + struct sys_reg_params params;
> + const struct sys_reg_desc *r;
> + int err;
> + u64 val = 0; /* Make sure high bits are 0 for 32-bit regs */
> +
> + if (!index_to_params(id, &params))
> + return -ENOENT;
> + r = find_reg(&params, invariant_sys_regs, ARRAY_SIZE(invariant_sys_regs));
> + if (!r)
> + return -ENOENT;
> +
> + err = reg_from_user(&val, uaddr, id);
> + if (err)
> + return err;
> +
> + /* This is what we mean by invariant: you can't change it. */
> + if (r->val != val)
> + return -EINVAL;
> +
> + return 0;
> +}
> +
> +static bool is_valid_cache(u32 val)
> +{
> + u32 level, ctype;
> +
> + if (val >= CSSELR_MAX)
> + return -ENOENT;
> +
> + /* Bottom bit is Instruction or Data bit.  Next 3 bits are level. */
> +        level = (val >> 1);
> +        ctype = (cache_levels >> (level * 3)) & 7;

replace spaces with tab here

> +
> + switch (ctype) {
> + case 0: /* No cache */
> + return false;
> + case 1: /* Instruction cache only */
> + return (val & 1);
> + case 2: /* Data cache only */
> + case 4: /* Unified cache */
> + return !(val & 1);
> + case 3: /* Separate instruction and data caches */
> + return true;
> + default: /* Reserved: we can't know instruction or data. */
> + return false;
> + }
> +}
> +
> +static int demux_c15_get(u64 id, void __user *uaddr)
> +{
> + u32 val;
> + u32 __user *uval = uaddr;
> +
> + /* Fail if we have unknown bits set. */
> + if (id & ~(KVM_REG_ARCH_MASK|KVM_REG_SIZE_MASK|KVM_REG_ARM_COPROC_MASK
> +   | ((1 << KVM_REG_ARM_COPROC_SHIFT)-1)))
> + return -ENOENT;
> +
> + switch (id & KVM_REG_ARM_DEMUX_ID_MASK) {
> + case KVM_REG_ARM_DEMUX_ID_CCSIDR:
> + if (KVM_REG_SIZE(id) != 4)
> + return -ENOENT;
> + val = (id & KVM_REG_ARM_DEMUX_VAL_MASK)
> + >> KVM_REG_ARM_DEMUX_VAL_SHIFT;
> + if (!is_valid_cache(val))
> + return -ENOENT;
> +
> + return put_user(get_ccsidr(val), uval);
> + default:
> + return -ENOENT;
> + }
> +}
> +
> +static int demux_c15_set(u64 id, void __user *uaddr)
> +{
> + u32 val, newval;
> + u32 __user *uval = uaddr;
> +
> + /* Fail if we have unknown bits set. */
> + if (id & ~(KVM_REG_ARCH_MASK|KVM_REG_SIZE_MASK|KVM_REG_ARM_COPROC_MASK
> +   | ((1 << KVM_REG_ARM_COPROC_SHIFT)-1)))
> + return -ENOENT;
> +
> + switch (id & KVM_REG_ARM_DEMUX_ID_MASK) {
> + case KVM_REG_ARM_DEMUX_ID_CCSIDR:
> + if (KVM_REG_SIZE(id) != 4)
> + return -ENOENT;
> + val = (id & KVM_REG_ARM_DEMUX_VAL_MASK)
> + >> KVM_REG_ARM_DEMUX_VAL_SHIFT;
> + if (!is_valid_cache(val))
> + return -ENOENT;
> +
> + if (get_user(newval, uval))
> + return -EFAULT;
> +
> + /* This is also invariant: you can't change it. */
> + if (newval != get_ccsidr(val))
> + return -EINVAL;
> + return 0;
> + default:
> + return -ENOENT;
> + }
> +}
> +
> +int kvm_arm_sys_reg_get_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> +{
> + const struct sys_reg_desc *r;
> + void __user *uaddr = (void __user *)(unsigned long)reg->addr;
> +
> + if ((reg->id & KVM_REG_ARM_COPROC_MASK) == KVM_REG_ARM_DEMUX)
> + return demux_c15_get(reg->id, uaddr);
> +
> + r = index_to_sys_reg_desc(vcpu, reg->id);
> + if (!r)
> + return get_invariant_sys_reg(reg->id, uaddr);
> +
> + /* Note: copies two regs if size is 64 bit. */

is this still true?

> + return reg_to_user(uaddr, &vcpu_sys_reg(vcpu, r->reg), reg->id);
> +}
> +
> +int kvm_arm_sys_reg_set_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> +{
> + const struct sys_reg_desc *r;
> + void __user *uaddr = (void __user *)(unsigned long)reg->addr;
> +
> + if ((reg->id & KVM_REG_ARM_COPROC_MASK) == KVM_REG_ARM_DEMUX)
> + return demux_c15_set(reg->id, uaddr);
> +
> + r = index_to_sys_reg_desc(vcpu, reg->id);
> + if (!r)
> + return set_invariant_sys_reg(reg->id, uaddr);
> +
> + /* Note: copies two regs if size is 64 bit */

is this still true?

> + return reg_from_user(&vcpu_sys_reg(vcpu, r->reg), uaddr, reg->id);
> +}
> +
> +static unsigned int num_demux_regs(void)
> +{
> + unsigned int i, count = 0;
> +
> + for (i = 0; i < CSSELR_MAX; i++)
> + if (is_valid_cache(i))
> + count++;
> +
> + return count;
> +}
> +
> +static int write_demux_regids(u64 __user *uindices)
> +{
> + u64 val = KVM_REG_ARM | KVM_REG_SIZE_U32 | KVM_REG_ARM_DEMUX;
> + unsigned int i;
> +
> + val |= KVM_REG_ARM_DEMUX_ID_CCSIDR;
> + for (i = 0; i < CSSELR_MAX; i++) {
> + if (!is_valid_cache(i))
> + continue;
> + if (put_user(val | i, uindices))
> + return -EFAULT;
> + uindices++;
> + }
> + return 0;
> +}
> +
> +static u64 sys_reg_to_index(const struct sys_reg_desc *reg)
> +{
> + return (KVM_REG_ARM64 | KVM_REG_SIZE_U64 |
> + KVM_REG_ARM64_SYSREG |
> + (reg->Op0 << KVM_REG_ARM64_SYSREG_OP0_SHIFT) |
> + (reg->Op1 << KVM_REG_ARM64_SYSREG_OP1_SHIFT) |
> + (reg->CRn << KVM_REG_ARM64_SYSREG_CRN_SHIFT) |
> + (reg->CRm << KVM_REG_ARM64_SYSREG_CRM_SHIFT) |
> + (reg->Op2 << KVM_REG_ARM64_SYSREG_OP2_SHIFT));
> +}
> +
> +static bool copy_reg_to_user(const struct sys_reg_desc *reg, u64 __user **uind)
> +{
> + if (!*uind)
> + return true;
> +
> + if (put_user(sys_reg_to_index(reg), *uind))
> + return false;
> +
> + (*uind)++;
> + return true;
> +}
> +
> +/* Assumed ordered tables, see kvm_sys_reg_table_init. */
> +static int walk_sys_regs(struct kvm_vcpu *vcpu, u64 __user *uind)
> +{
> + const struct sys_reg_desc *i1, *i2, *end1, *end2;
> + unsigned int total = 0;
> + size_t num;
> +
> + /* We check for duplicates here, to allow arch-specific overrides. */
> + i1 = get_target_table(vcpu->arch.target, &num);
> + end1 = i1 + num;
> + i2 = sys_reg_descs;
> + end2 = sys_reg_descs + ARRAY_SIZE(sys_reg_descs);
> +
> + BUG_ON(i1 == end1 || i2 == end2);
> +
> + /* Walk carefully, as both tables may refer to the same register. */
> + while (i1 || i2) {
> + int cmp = cmp_sys_reg(i1, i2);
> + /* target-specific overrides generic entry. */
> + if (cmp <= 0) {
> + /* Ignore registers we trap but don't save. */
> + if (i1->reg) {
> + if (!copy_reg_to_user(i1, &uind))
> + return -EFAULT;
> + total++;
> + }
> + } else {
> + /* Ignore registers we trap but don't save. */
> + if (i2->reg) {
> + if (!copy_reg_to_user(i2, &uind))
> + return -EFAULT;
> + total++;
> + }
> + }
> +
> + if (cmp <= 0 && ++i1 == end1)
> + i1 = NULL;
> + if (cmp >= 0 && ++i2 == end2)
> + i2 = NULL;
> + }
> + return total;
> +}
> +
> +unsigned long kvm_arm_num_sys_reg_descs(struct kvm_vcpu *vcpu)
> +{
> + return ARRAY_SIZE(invariant_sys_regs)
> + + num_demux_regs()
> + + walk_sys_regs(vcpu, (u64 __user *)NULL);
> +}
> +
> +int kvm_arm_copy_sys_reg_indices(struct kvm_vcpu *vcpu, u64 __user *uindices)
> +{
> + unsigned int i;
> + int err;
> +
> + /* Then give them all the invariant registers' indices. */
> + for (i = 0; i < ARRAY_SIZE(invariant_sys_regs); i++) {
> + if (put_user(sys_reg_to_index(&invariant_sys_regs[i]), uindices))
> + return -EFAULT;
> + uindices++;
> + }
> +
> + err = walk_sys_regs(vcpu, uindices);
> + if (err < 0)
> + return err;
> + uindices += err;
> +
> + return write_demux_regids(uindices);
> +}
> +
> +void kvm_sys_reg_table_init(void)
> +{
> + unsigned int i;
> + struct sys_reg_desc clidr;
> +
> + /* Make sure tables are unique and in order. */
> + for (i = 1; i < ARRAY_SIZE(sys_reg_descs); i++)
> + BUG_ON(cmp_sys_reg(&sys_reg_descs[i-1], &sys_reg_descs[i]) >= 0);
> +
> + /* We abuse the reset function to overwrite the table itself. */
> + for (i = 0; i < ARRAY_SIZE(invariant_sys_regs); i++)
> + invariant_sys_regs[i].reset(NULL, &invariant_sys_regs[i]);
> +
> + /*
> + * CLIDR format is awkward, so clean it up.  See ARM B4.1.20:
> + *
> + *   If software reads the Cache Type fields from Ctype1
> + *   upwards, once it has seen a value of 0b000, no caches
> + *   exist at further-out levels of the hierarchy. So, for
> + *   example, if Ctype3 is the first Cache Type field with a
> + *   value of 0b000, the values of Ctype4 to Ctype7 must be
> + *   ignored.
> + */
> + get_clidr_el1(NULL, &clidr); /* Ugly... */
> + cache_levels = clidr.val;
> + for (i = 0; i < 7; i++)
> + if (((cache_levels >> (i*3)) & 7) == 0)
> + break;
> + /* Clear all higher bits. */
> + cache_levels &= (1 << (i*3))-1;
> +}
> +
> +/**
> + * kvm_reset_sys_regs - sets system registers to reset value
> + * @vcpu: The VCPU pointer
> + *
> + * This function finds the right table above and sets the registers on the
> + * virtual CPU struct to their architecturally defined reset values.
> + */
> +void kvm_reset_sys_regs(struct kvm_vcpu *vcpu)
> +{
> + size_t num;
> + const struct sys_reg_desc *table;
> +
> + /* Catch someone adding a register without putting in reset entry. */
> + memset(&vcpu->arch.ctxt.sys_regs, 0x42, sizeof(vcpu->arch.ctxt.sys_regs));
> +
> + /* Generic chip reset first (so target could override). */
> + reset_sys_reg_descs(vcpu, sys_reg_descs, ARRAY_SIZE(sys_reg_descs));
> +
> + table = get_target_table(vcpu->arch.target, &num);
> + reset_sys_reg_descs(vcpu, table, num);
> +
> + for (num = 1; num < NR_SYS_REGS; num++)
> + if (vcpu_sys_reg(vcpu, num) == 0x4242424242424242)
> + panic("Didn't reset vcpu_sys_reg(%zi)", num);
> +}
> diff --git a/arch/arm64/kvm/sys_regs.h b/arch/arm64/kvm/sys_regs.h
> new file mode 100644
> index 0000000..d50d372
> --- /dev/null
> +++ b/arch/arm64/kvm/sys_regs.h
> @@ -0,0 +1,138 @@
> +/*
> + * Copyright (C) 2012,2013 - ARM Ltd
> + * Author: Marc Zyngier <marc.zyngier at arm.com>
> + *
> + * Derived from arch/arm/kvm/coproc.h
> + * Copyright (C) 2012 - Virtual Open Systems and Columbia University
> + * Authors: Christoffer Dall <c.dall at virtualopensystems.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.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +#ifndef __ARM64_KVM_SYS_REGS_LOCAL_H__
> +#define __ARM64_KVM_SYS_REGS_LOCAL_H__
> +
> +struct sys_reg_params {
> + u8 Op0;
> + u8 Op1;
> + u8 CRn;
> + u8 CRm;
> + u8 Op2;
> + u8 Rt;
> + bool is_write;
> +};
> +
> +struct sys_reg_desc {
> + /* MRS/MSR instruction which accesses it. */
> + u8 Op0;
> + u8 Op1;
> + u8 CRn;
> + u8 CRm;
> + u8 Op2;
> +
> + /* Trapped access from guest, if non-NULL. */
> + bool (*access)(struct kvm_vcpu *,
> +       const struct sys_reg_params *,
> +       const struct sys_reg_desc *);
> +
> + /* Initialization for vcpu. */
> + void (*reset)(struct kvm_vcpu *, const struct sys_reg_desc *);
> +
> + /* Index into sys_reg[], or 0 if we don't need to save it. */
> + int reg;
> +
> + /* Value (usually reset value) */
> + u64 val;
> +};
> +
> +static inline void print_sys_reg_instr(const struct sys_reg_params *p)
> +{
> + /* Look, we even formatted it for you to paste into the table! */
> + kvm_pr_unimpl(" { Op0(%2u), Op1(%2u), CRn(%2u), CRm(%2u), Op2(%2u), func_%s },\n",
> +      p->Op0, p->Op1, p->CRn, p->CRm, p->Op2, p->is_write ? "write" : "read");
> +}
> +
> +static inline bool ignore_write(struct kvm_vcpu *vcpu,
> + const struct sys_reg_params *p)
> +{
> + return true;
> +}
> +
> +static inline bool read_zero(struct kvm_vcpu *vcpu,
> +     const struct sys_reg_params *p)
> +{
> + *vcpu_reg(vcpu, p->Rt) = 0;
> + return true;
> +}
> +
> +static inline bool write_to_read_only(struct kvm_vcpu *vcpu,
> +      const struct sys_reg_params *params)
> +{
> + kvm_debug("sys_reg write to read-only register at: %lx\n",
> +  *vcpu_pc(vcpu));
> + print_sys_reg_instr(params);
> + return false;
> +}
> +
> +static inline bool read_from_write_only(struct kvm_vcpu *vcpu,
> + const struct sys_reg_params *params)
> +{
> + kvm_debug("sys_reg read to write-only register at: %lx\n",
> +  *vcpu_pc(vcpu));
> + print_sys_reg_instr(params);
> + return false;
> +}
> +
> +/* Reset functions */
> +static inline void reset_unknown(struct kvm_vcpu *vcpu,
> + const struct sys_reg_desc *r)
> +{
> + BUG_ON(!r->reg);
> + BUG_ON(r->reg >= NR_SYS_REGS);
> + vcpu_sys_reg(vcpu, r->reg) = 0x1de7ec7edbadc0deULL;
> +}
> +
> +static inline void reset_val(struct kvm_vcpu *vcpu, const struct sys_reg_desc *r)
> +{
> + BUG_ON(!r->reg);
> + BUG_ON(r->reg >= NR_SYS_REGS);
> + vcpu_sys_reg(vcpu, r->reg) = r->val;
> +}
> +
> +static inline int cmp_sys_reg(const struct sys_reg_desc *i1,
> +      const struct sys_reg_desc *i2)
> +{
> + BUG_ON(i1 == i2);
> + if (!i1)
> + return 1;
> + else if (!i2)
> + return -1;
> + if (i1->Op0 != i2->Op0)
> + return i1->Op0 - i2->Op0;
> + if (i1->Op1 != i2->Op1)
> + return i1->Op1 - i2->Op1;
> + if (i1->CRn != i2->CRn)
> + return i1->CRn - i2->CRn;
> + if (i1->CRm != i2->CRm)
> + return i1->CRm - i2->CRm;
> + return i1->Op2 - i2->Op2;
> +}
> +
> +
> +#define Op0(_x) .Op0 = _x
> +#define Op1(_x) .Op1 = _x
> +#define CRn(_x) .CRn = _x
> +#define CRm(_x) .CRm = _x
> +#define Op2(_x) .Op2 = _x
> +
> +#endif /* __ARM64_KVM_SYS_REGS_LOCAL_H__ */
> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> index 3c56ba3..2bf42b0 100644
> --- a/include/uapi/linux/kvm.h
> +++ b/include/uapi/linux/kvm.h
> @@ -782,6 +782,7 @@ struct kvm_dirty_tlb {
>  #define KVM_REG_IA64 0x3000000000000000ULL
>  #define KVM_REG_ARM 0x4000000000000000ULL
>  #define KVM_REG_S390 0x5000000000000000ULL
> +#define KVM_REG_ARM64 0x6000000000000000ULL
>  
>  #define KVM_REG_SIZE_SHIFT 52
>  #define KVM_REG_SIZE_MASK 0x00f0000000000000ULL
> --
> 1.8.1.4
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


From cdall at cs.columbia.edu  Tue Apr 23 19:01:59 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Tue, 23 Apr 2013 16:01:59 -0700
Subject: [PATCH v3 26/32] arm64: KVM: 32bit handling of coprocessor traps
In-Reply-To: <1365437854-30214-27-git-send-email-marc.zyngier@arm.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
 <1365437854-30214-27-git-send-email-marc.zyngier@arm.com>
Message-ID: <20130423230159.GL20569@gmail.com>

On Mon, Apr 08, 2013 at 05:17:28PM +0100, Marc Zyngier wrote:
> Provide the necessary infrastructure to trap coprocessor accesses that
> occur when running 32bit guests.
> 
> Also wire SMC and HVC trapped in 32bit mode while were at it.
> 
> Reviewed-by: Christopher Covington <cov at codeaurora.org>
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> ---
>  arch/arm64/include/asm/kvm_coproc.h |   5 +
>  arch/arm64/kvm/handle_exit.c        |   7 ++
>  arch/arm64/kvm/sys_regs.c           | 178 ++++++++++++++++++++++++++++++++++--
>  3 files changed, 183 insertions(+), 7 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/kvm_coproc.h b/arch/arm64/include/asm/kvm_coproc.h
> index 9b4477a..9a59301 100644
> --- a/arch/arm64/include/asm/kvm_coproc.h
> +++ b/arch/arm64/include/asm/kvm_coproc.h
> @@ -32,11 +32,16 @@ struct kvm_sys_reg_table {
>  
>  struct kvm_sys_reg_target_table {
>  	struct kvm_sys_reg_table table64;
> +	struct kvm_sys_reg_table table32;
>  };
>  
>  void kvm_register_target_sys_reg_table(unsigned int target,
>  				       struct kvm_sys_reg_target_table *table);
>  
> +int kvm_handle_cp14_load_store(struct kvm_vcpu *vcpu, struct kvm_run *run);
> +int kvm_handle_cp14_access(struct kvm_vcpu *vcpu, struct kvm_run *run);
> +int kvm_handle_cp15_32(struct kvm_vcpu *vcpu, struct kvm_run *run);
> +int kvm_handle_cp15_64(struct kvm_vcpu *vcpu, struct kvm_run *run);
>  int kvm_handle_sys_reg(struct kvm_vcpu *vcpu, struct kvm_run *run);
>  
>  #define kvm_coproc_table_init kvm_sys_reg_table_init
> diff --git a/arch/arm64/kvm/handle_exit.c b/arch/arm64/kvm/handle_exit.c
> index 4766b7f..9beaca03 100644
> --- a/arch/arm64/kvm/handle_exit.c
> +++ b/arch/arm64/kvm/handle_exit.c
> @@ -62,6 +62,13 @@ static int kvm_handle_wfi(struct kvm_vcpu *vcpu, struct kvm_run *run)
>  
>  static exit_handle_fn arm_exit_handlers[] = {
>  	[ESR_EL2_EC_WFI]	= kvm_handle_wfi,
> +	[ESR_EL2_EC_CP15_32]	= kvm_handle_cp15_32,
> +	[ESR_EL2_EC_CP15_64]	= kvm_handle_cp15_64,
> +	[ESR_EL2_EC_CP14_MR]	= kvm_handle_cp14_access,
> +	[ESR_EL2_EC_CP14_LS]	= kvm_handle_cp14_load_store,
> +	[ESR_EL2_EC_CP14_64]	= kvm_handle_cp14_access,
> +	[ESR_EL2_EC_HVC32]	= handle_hvc,
> +	[ESR_EL2_EC_SMC32]	= handle_smc,
>  	[ESR_EL2_EC_HVC64]	= handle_hvc,
>  	[ESR_EL2_EC_SMC64]	= handle_smc,
>  	[ESR_EL2_EC_SYS64]	= kvm_handle_sys_reg,
> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> index 9df3b32..0303218 100644
> --- a/arch/arm64/kvm/sys_regs.c
> +++ b/arch/arm64/kvm/sys_regs.c
> @@ -38,6 +38,10 @@
>   * types are different. My gut feeling is that it should be pretty
>   * easy to merge, but that would be an ABI breakage -- again. VFP
>   * would also need to be abstracted.
> + *
> + * For AArch32, we only take care of what is being trapped. Anything
> + * that has to do with init and userspace access has to go via the
> + * 64bit interface.
>   */
>  
>  /* 3 bits per cache level, as per CLIDR, but non-existent caches always 0 */
> @@ -163,6 +167,16 @@ static const struct sys_reg_desc sys_reg_descs[] = {
>  	{ Op0(0b01), Op1(0b000), CRn(0b0111), CRm(0b1110), Op2(0b010),
>  	  access_dcsw },
>  
> +	/* TEECR32_EL1 */
> +	{ Op0(0b10), Op1(0b010), CRn(0b0000), CRm(0b0000), Op2(0b000),
> +	  NULL, reset_val, TEECR32_EL1, 0 },
> +	/* TEEHBR32_EL1 */
> +	{ Op0(0b10), Op1(0b010), CRn(0b0001), CRm(0b0000), Op2(0b000),
> +	  NULL, reset_val, TEEHBR32_EL1, 0 },
> +	/* DBGVCR32_EL2 */
> +	{ Op0(0b10), Op1(0b100), CRn(0b0000), CRm(0b0111), Op2(0b000),
> +	  NULL, reset_val, DBGVCR32_EL2, 0 },
> +
>  	/* MPIDR_EL1 */
>  	{ Op0(0b11), Op1(0b000), CRn(0b0000), CRm(0b0000), Op2(0b101),
>  	  NULL, reset_mpidr, MPIDR_EL1 },
> @@ -273,6 +287,39 @@ static const struct sys_reg_desc sys_reg_descs[] = {
>  	/* TPIDRRO_EL0 */
>  	{ Op0(0b11), Op1(0b011), CRn(0b1101), CRm(0b0000), Op2(0b011),
>  	  NULL, reset_unknown, TPIDRRO_EL0 },
> +
> +	/* DACR32_EL2 */
> +	{ Op0(0b11), Op1(0b100), CRn(0b0011), CRm(0b0000), Op2(0b000),
> +	  NULL, reset_unknown, DACR32_EL2 },
> +	/* IFSR32_EL2 */
> +	{ Op0(0b11), Op1(0b100), CRn(0b0101), CRm(0b0000), Op2(0b001),
> +	  NULL, reset_unknown, IFSR32_EL2 },
> +	/* FPEXC32_EL2 */
> +	{ Op0(0b11), Op1(0b100), CRn(0b0101), CRm(0b0011), Op2(0b000),
> +	  NULL, reset_val, FPEXC32_EL2, 0x70 },
> +};
> +
> +/* Trapped cp15 registers */
> +static const struct sys_reg_desc cp15_regs[] = {
> +	/*
> +	 * DC{C,I,CI}SW operations:
> +	 */
> +	{ Op1( 0), CRn( 7), CRm( 6), Op2( 2), access_dcsw },
> +	{ Op1( 0), CRn( 7), CRm(10), Op2( 2), access_dcsw },
> +	{ Op1( 0), CRn( 7), CRm(14), Op2( 2), access_dcsw },
> +	{ Op1( 0), CRn( 9), CRm(12), Op2( 0), pm_fake },
> +	{ Op1( 0), CRn( 9), CRm(12), Op2( 1), pm_fake },
> +	{ Op1( 0), CRn( 9), CRm(12), Op2( 2), pm_fake },
> +	{ Op1( 0), CRn( 9), CRm(12), Op2( 3), pm_fake },
> +	{ Op1( 0), CRn( 9), CRm(12), Op2( 5), pm_fake },
> +	{ Op1( 0), CRn( 9), CRm(12), Op2( 6), pm_fake },
> +	{ Op1( 0), CRn( 9), CRm(12), Op2( 7), pm_fake },
> +	{ Op1( 0), CRn( 9), CRm(13), Op2( 0), pm_fake },
> +	{ Op1( 0), CRn( 9), CRm(13), Op2( 1), pm_fake },
> +	{ Op1( 0), CRn( 9), CRm(13), Op2( 2), pm_fake },
> +	{ Op1( 0), CRn( 9), CRm(14), Op2( 0), pm_fake },
> +	{ Op1( 0), CRn( 9), CRm(14), Op2( 1), pm_fake },
> +	{ Op1( 0), CRn( 9), CRm(14), Op2( 2), pm_fake },
>  };
>  
>  /* Target specific emulation tables */
> @@ -285,13 +332,20 @@ void kvm_register_target_sys_reg_table(unsigned int target,
>  }
>  
>  /* Get specific register table for this target. */
> -static const struct sys_reg_desc *get_target_table(unsigned target, size_t *num)
> +static const struct sys_reg_desc *get_target_table(unsigned target,
> +						   bool mode_is_64,
> +						   size_t *num)
>  {
>  	struct kvm_sys_reg_target_table *table;
>  
>  	table = target_tables[target];
> -	*num = table->table64.num;
> -	return table->table64.table;
> +	if (mode_is_64) {
> +		*num = table->table64.num;
> +		return table->table64.table;
> +	} else {
> +		*num = table->table32.num;
> +		return table->table32.table;
> +	}
>  }
>  
>  static const struct sys_reg_desc *find_reg(const struct sys_reg_params *params,
> @@ -319,13 +373,123 @@ static const struct sys_reg_desc *find_reg(const struct sys_reg_params *params,
>  	return NULL;
>  }
>  
> +int kvm_handle_cp14_load_store(struct kvm_vcpu *vcpu, struct kvm_run *run)
> +{
> +	kvm_inject_undefined(vcpu);
> +	return 1;
> +}
> +
> +int kvm_handle_cp14_access(struct kvm_vcpu *vcpu, struct kvm_run *run)
> +{
> +	kvm_inject_undefined(vcpu);
> +	return 1;
> +}
> +
> +static int emulate_cp15(struct kvm_vcpu *vcpu,
> +			const struct sys_reg_params *params)
> +{
> +	size_t num;
> +	const struct sys_reg_desc *table, *r;
> +
> +	table = get_target_table(vcpu->arch.target, false, &num);
> +
> +	/* Search target-specific then generic table. */
> +	r = find_reg(params, table, num);
> +	if (!r)
> +		r = find_reg(params, cp15_regs, ARRAY_SIZE(cp15_regs));
> +
> +	if (likely(r)) {
> +		/* If we don't have an accessor, we should never get here! */
> +		BUG_ON(!r->access);

again not quite sure if this warrants a crash of the entire host.

> +
> +		if (likely(r->access(vcpu, params, r))) {
> +			/* Skip instruction, since it was emulated */
> +			kvm_skip_instr(vcpu, kvm_vcpu_trap_il_is32bit(vcpu));
> +			return 1;
> +		}
> +		/* If access function fails, it should complain. */
> +	} else {
> +		kvm_err("Unsupported guest CP15 access at: %08lx\n",
> +			*vcpu_pc(vcpu));
> +		print_sys_reg_instr(params);
> +	}
> +	kvm_inject_undefined(vcpu);
> +	return 1;
> +}
> +
> +/**
> + * kvm_handle_cp15_64 -- handles a mrrc/mcrr trap on a guest CP15 access
> + * @vcpu: The VCPU pointer
> + * @run:  The kvm_run struct
> + */
> +int kvm_handle_cp15_64(struct kvm_vcpu *vcpu, struct kvm_run *run)
> +{
> +	struct sys_reg_params params;
> +	u32 hsr = kvm_vcpu_get_hsr(vcpu);
> +	int Rt2 = (hsr >> 10) & 0xf;
> +	int ret;
> +
> +	params.CRm = (hsr >> 1) & 0xf;
> +	params.Rt = (hsr >> 5) & 0xf;
> +	params.is_write = ((hsr & 1) == 0);
> +
> +	params.Op0 = 0;
> +	params.Op1 = (hsr >> 16) & 0xf;
> +	params.Op2 = 0;
> +	params.CRn = 0;
> +
> +	/*
> +	 * Massive hack here. Store Rt2 in the top 32bits so we only
> +	 * have one register to deal with. As we use the same trap
> +	 * backends between AArch32 and AArch64, we get away with it.
> +	 */
> +	if (params.is_write) {
> +		u64 val = *vcpu_reg(vcpu, params.Rt);
> +		val &= 0xffffffff;
> +		val |= *vcpu_reg(vcpu, Rt2) << 32;
> +		*vcpu_reg(vcpu, params.Rt) = val;
> +	}
> +
> +	ret = emulate_cp15(vcpu, &params);
> +
> +	/* Reverse hack here */

nit: consider changing the wording to something like 'Similar hack for
reads here', so readers don't think you are trying to reverse the hack
you did above.

> +	if (ret && !params.is_write) {
> +		u64 val = *vcpu_reg(vcpu, params.Rt);
> +		val >>= 32;
> +		*vcpu_reg(vcpu, Rt2) = val;

actually the emulate_cp15 should probably be turned into a void and the
ret check could go away, same thing on the 32-bit side.

> +	}
> +
> +	return ret;
> +}
> +
> +/**
> + * kvm_handle_cp15_32 -- handles a mrc/mcr trap on a guest CP15 access
> + * @vcpu: The VCPU pointer
> + * @run:  The kvm_run struct
> + */
> +int kvm_handle_cp15_32(struct kvm_vcpu *vcpu, struct kvm_run *run)
> +{
> +	struct sys_reg_params params;
> +	u32 hsr = kvm_vcpu_get_hsr(vcpu);
> +
> +	params.CRm = (hsr >> 1) & 0xf;
> +	params.Rt  = (hsr >> 5) & 0xf;
> +	params.is_write = ((hsr & 1) == 0);
> +	params.CRn = (hsr >> 10) & 0xf;
> +	params.Op0 = 0;
> +	params.Op1 = (hsr >> 14) & 0x7;
> +	params.Op2 = (hsr >> 17) & 0x7;
> +
> +	return emulate_cp15(vcpu, &params);
> +}
> +
>  static int emulate_sys_reg(struct kvm_vcpu *vcpu,
>  			   const struct sys_reg_params *params)
>  {
>  	size_t num;
>  	const struct sys_reg_desc *table, *r;
>  
> -	table = get_target_table(vcpu->arch.target, &num);
> +	table = get_target_table(vcpu->arch.target, true, &num);
>  
>  	/* Search target-specific then generic table. */
>  	r = find_reg(params, table, num);
> @@ -430,7 +594,7 @@ static const struct sys_reg_desc *index_to_sys_reg_desc(struct kvm_vcpu *vcpu,
>  	if (!index_to_params(id, &params))
>  		return NULL;
>  
> -	table = get_target_table(vcpu->arch.target, &num);
> +	table = get_target_table(vcpu->arch.target, true, &num);
>  	r = find_reg(&params, table, num);
>  	if (!r)
>  		r = find_reg(&params, sys_reg_descs, ARRAY_SIZE(sys_reg_descs));
> @@ -750,7 +914,7 @@ static int walk_sys_regs(struct kvm_vcpu *vcpu, u64 __user *uind)
>  	size_t num;
>  
>  	/* We check for duplicates here, to allow arch-specific overrides. */
> -	i1 = get_target_table(vcpu->arch.target, &num);
> +	i1 = get_target_table(vcpu->arch.target, true, &num);
>  	end1 = i1 + num;
>  	i2 = sys_reg_descs;
>  	end2 = sys_reg_descs + ARRAY_SIZE(sys_reg_descs);
> @@ -862,7 +1026,7 @@ void kvm_reset_sys_regs(struct kvm_vcpu *vcpu)
>  	/* Generic chip reset first (so target could override). */
>  	reset_sys_reg_descs(vcpu, sys_reg_descs, ARRAY_SIZE(sys_reg_descs));
>  
> -	table = get_target_table(vcpu->arch.target, &num);
> +	table = get_target_table(vcpu->arch.target, true, &num);
>  	reset_sys_reg_descs(vcpu, table, num);
>  
>  	for (num = 1; num < NR_SYS_REGS; num++)
> -- 
> 1.8.1.4
> 
> 
> 
> _______________________________________________
> kvmarm mailing list
> kvmarm at lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm


From cdall at cs.columbia.edu  Tue Apr 23 19:02:14 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Tue, 23 Apr 2013 16:02:14 -0700
Subject: [PATCH v3 29/32] arm64: KVM: 32bit guest fault injection
In-Reply-To: <1365437854-30214-30-git-send-email-marc.zyngier@arm.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
 <1365437854-30214-30-git-send-email-marc.zyngier@arm.com>
Message-ID: <20130423230214.GM20569@gmail.com>

On Mon, Apr 08, 2013 at 05:17:31PM +0100, Marc Zyngier wrote:
> Add fault injection capability for 32bit guests.

looks ok, but seems we are duplicating some functionality here, but I
realize it may not be that easy to share due to different define names
for things like PSR_X_BIT...  Did you look further into this?

> 
> Reviewed-by: Christopher Covington <cov at codeaurora.org>
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> ---
>  arch/arm64/kvm/inject_fault.c | 79 ++++++++++++++++++++++++++++++++++++++++++-
>  1 file changed, 78 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/kvm/inject_fault.c b/arch/arm64/kvm/inject_fault.c
> index 2ff3b78..083cfd5 100644
> --- a/arch/arm64/kvm/inject_fault.c
> +++ b/arch/arm64/kvm/inject_fault.c
> @@ -1,5 +1,5 @@
>  /*
> - * Fault injection for 64bit guests.
> + * Fault injection for both 32 and 64bit guests.
>   *
>   * Copyright (C) 2012,2013 - ARM Ltd
>   * Author: Marc Zyngier <marc.zyngier at arm.com>
> @@ -25,6 +25,74 @@
>  #include <asm/kvm_emulate.h>
>  #include <asm/esr.h>
>  
> +static void prepare_fault32(struct kvm_vcpu *vcpu, u32 mode, u32 vect_offset)
> +{
> +	unsigned long cpsr;
> +	unsigned long new_spsr_value = *vcpu_cpsr(vcpu);
> +	bool is_thumb = (new_spsr_value & COMPAT_PSR_T_BIT);
> +	u32 return_offset = (is_thumb) ? 4 : 0;
> +	u32 sctlr = vcpu_cp15(vcpu, c1_SCTLR);
> +
> +	cpsr = mode | COMPAT_PSR_I_BIT;
> +
> +	if (sctlr & (1 << 30))
> +		cpsr |= COMPAT_PSR_T_BIT;
> +	if (sctlr & (1 << 25))
> +		cpsr |= COMPAT_PSR_E_BIT;
> +
> +	*vcpu_cpsr(vcpu) = cpsr;
> +
> +	/* Note: These now point to the banked copies */
> +	*vcpu_spsr(vcpu) = new_spsr_value;
> +	*vcpu_reg(vcpu, 14) = *vcpu_pc(vcpu) + return_offset;
> +
> +	/* Branch to exception vector */
> +	if (sctlr & (1 << 13))
> +		vect_offset += 0xffff0000;
> +	else /* always have security exceptions */
> +		vect_offset += vcpu_cp15(vcpu, c12_VBAR);
> +
> +	*vcpu_pc(vcpu) = vect_offset;
> +}
> +
> +static void inject_undef32(struct kvm_vcpu *vcpu)
> +{
> +	prepare_fault32(vcpu, COMPAT_PSR_MODE_UND, 4);
> +}
> +
> +/*
> + * Modelled after TakeDataAbortException() and TakePrefetchAbortException
> + * pseudocode.
> + */
> +static void inject_abt32(struct kvm_vcpu *vcpu, bool is_pabt,
> +			 unsigned long addr)
> +{
> +	u32 vect_offset;
> +	u32 *far, *fsr;
> +	bool is_lpae;
> +
> +	if (is_pabt) {
> +		vect_offset = 12;
> +		far = &vcpu_cp15(vcpu, c6_IFAR);
> +		fsr = &vcpu_cp15(vcpu, c5_IFSR);
> +	} else { /* !iabt */
> +		vect_offset = 16;
> +		far = &vcpu_cp15(vcpu, c6_DFAR);
> +		fsr = &vcpu_cp15(vcpu, c5_DFSR);
> +	}
> +
> +	prepare_fault32(vcpu, COMPAT_PSR_MODE_ABT | COMPAT_PSR_A_BIT, vect_offset);
> +
> +	*far = addr;
> +
> +	/* Give the guest an IMPLEMENTATION DEFINED exception */
> +	is_lpae = (vcpu_cp15(vcpu, c2_TTBCR) >> 31);
> +	if (is_lpae)
> +		*fsr = 1 << 9 | 0x34;
> +	else
> +		*fsr = 0x14;
> +}
> +
>  static void inject_abt64(struct kvm_vcpu *vcpu, bool is_iabt, unsigned long addr)
>  {
>  	unsigned long cpsr = *vcpu_cpsr(vcpu);
> @@ -90,6 +158,9 @@ static void inject_undef64(struct kvm_vcpu *vcpu)
>   */
>  void kvm_inject_dabt(struct kvm_vcpu *vcpu, unsigned long addr)
>  {
> +	if (!(vcpu->arch.hcr_el2 & HCR_RW))
> +		inject_abt32(vcpu, false, addr);
> +
>  	inject_abt64(vcpu, false, addr);
>  }
>  
> @@ -103,6 +174,9 @@ void kvm_inject_dabt(struct kvm_vcpu *vcpu, unsigned long addr)
>   */
>  void kvm_inject_pabt(struct kvm_vcpu *vcpu, unsigned long addr)
>  {
> +	if (!(vcpu->arch.hcr_el2 & HCR_RW))
> +		inject_abt32(vcpu, true, addr);
> +
>  	inject_abt64(vcpu, true, addr);
>  }
>  
> @@ -114,5 +188,8 @@ void kvm_inject_pabt(struct kvm_vcpu *vcpu, unsigned long addr)
>   */
>  void kvm_inject_undefined(struct kvm_vcpu *vcpu)
>  {
> +	if (!(vcpu->arch.hcr_el2 & HCR_RW))
> +		inject_undef32(vcpu);
> +
>  	inject_undef64(vcpu);
>  }
> -- 
> 1.8.1.4
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


From cdall at cs.columbia.edu  Tue Apr 23 19:02:29 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Tue, 23 Apr 2013 16:02:29 -0700
Subject: [PATCH v3 30/32] arm64: KVM: enable initialization of a 32bit vcpu
In-Reply-To: <1365437854-30214-31-git-send-email-marc.zyngier@arm.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
 <1365437854-30214-31-git-send-email-marc.zyngier@arm.com>
Message-ID: <20130423230229.GN20569@gmail.com>

On Mon, Apr 08, 2013 at 05:17:32PM +0100, Marc Zyngier wrote:
> Wire the init of a 32bit vcpu by allowing 32bit modes in pstate,
> and providing sensible defaults out of reset state.
> 
> This feature is of course conditioned by the presence of 32bit
> capability on the physical CPU, and is checked by the KVM_CAP_ARM_EL1_32BIT
> capability.
> 
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> ---
>  arch/arm64/include/asm/kvm_host.h |  2 +-
>  arch/arm64/include/uapi/asm/kvm.h |  1 +
>  arch/arm64/kvm/guest.c            |  6 ++++++
>  arch/arm64/kvm/reset.c            | 25 ++++++++++++++++++++++++-
>  include/uapi/linux/kvm.h          |  1 +
>  5 files changed, 33 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index d44064d..c3ec107 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -34,7 +34,7 @@
>  #include <asm/kvm_vgic.h>
>  #include <asm/kvm_arch_timer.h>
>  
> -#define KVM_VCPU_MAX_FEATURES 1
> +#define KVM_VCPU_MAX_FEATURES 2
>  
>  /* We don't currently support large pages. */
>  #define KVM_HPAGE_GFN_SHIFT(x)	0
> diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
> index 5b1110c..5031f42 100644
> --- a/arch/arm64/include/uapi/asm/kvm.h
> +++ b/arch/arm64/include/uapi/asm/kvm.h
> @@ -75,6 +75,7 @@ struct kvm_regs {
>  #define KVM_VGIC_V2_CPU_SIZE		0x2000
>  
>  #define KVM_ARM_VCPU_POWER_OFF		0 /* CPU is started in OFF state */
> +#define KVM_ARM_VCPU_EL1_32BIT		1 /* CPU running a 32bit VM */
>  
>  struct kvm_vcpu_init {
>  	__u32 target;
> diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
> index 47d3729..74ef7d5 100644
> --- a/arch/arm64/kvm/guest.c
> +++ b/arch/arm64/kvm/guest.c
> @@ -93,6 +93,12 @@ static int set_core_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
>  	if (off == KVM_REG_ARM_CORE_REG(regs.pstate)) {
>  		unsigned long mode = (*(unsigned long *)valp) & COMPAT_PSR_MODE_MASK;
>  		switch (mode) {
> +		case COMPAT_PSR_MODE_USR:
> +		case COMPAT_PSR_MODE_FIQ:
> +		case COMPAT_PSR_MODE_IRQ:
> +		case COMPAT_PSR_MODE_SVC:
> +		case COMPAT_PSR_MODE_ABT:
> +		case COMPAT_PSR_MODE_UND:
>  		case PSR_MODE_EL0t:
>  		case PSR_MODE_EL1t:
>  		case PSR_MODE_EL1h:
> diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
> index bc33e76..a282d35 100644
> --- a/arch/arm64/kvm/reset.c
> +++ b/arch/arm64/kvm/reset.c
> @@ -35,11 +35,27 @@ static struct kvm_regs default_regs_reset = {
>  	.regs.pstate = PSR_MODE_EL1h | PSR_A_BIT | PSR_I_BIT | PSR_F_BIT,
>  };
>  
> +static struct kvm_regs default_regs_reset32 = {
> +	.regs.pstate = (COMPAT_PSR_MODE_SVC | COMPAT_PSR_A_BIT |
> +			COMPAT_PSR_I_BIT | COMPAT_PSR_F_BIT),
> +};
> +
> +static bool cpu_has_32bit_el1(void)
> +{
> +	u64 pfr0;
> +
> +	pfr0 = read_cpuid(ID_AA64PFR0_EL1);
> +	return !!(pfr0 & 0x20);

again we don't need the double negation

> +}
> +
>  int kvm_arch_dev_ioctl_check_extention(long ext)
>  {
>  	int r;
>  
>  	switch (ext) {
> +	case KVM_CAP_ARM_EL1_32BIT:
> +		r = cpu_has_32bit_el1();
> +		break;
>  	default:
>  		r = 0;
>  	}
> @@ -62,7 +78,14 @@ int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
>  
>  	switch (vcpu->arch.target) {
>  	default:
> -		cpu_reset = &default_regs_reset;
> +		if (test_bit(KVM_ARM_VCPU_EL1_32BIT, vcpu->arch.features)) {
> +			if (!cpu_has_32bit_el1())
> +				return -EINVAL;

I'm not sure EINVAL is appropriate here, the value specified was not
incorrect, it's that the hardware doesn't support it. ENXIO, ENODEV, and
add that in Documentation/virtual/kvm/api.txt ?

> +			cpu_reset = &default_regs_reset32;
> +			vcpu->arch.hcr_el2 &= ~HCR_RW;
> +		} else {
> +			cpu_reset = &default_regs_reset;
> +		}
>  		break;
>  	}
>  
> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> index 2bf42b0..ce05763 100644
> --- a/include/uapi/linux/kvm.h
> +++ b/include/uapi/linux/kvm.h
> @@ -665,6 +665,7 @@ struct kvm_ppc_smmu_info {
>  #define KVM_CAP_PPC_EPR 86
>  #define KVM_CAP_ARM_PSCI 87
>  #define KVM_CAP_ARM_SET_DEVICE_ADDR 88
> +#define KVM_CAP_ARM_EL1_32BIT 89
>  
>  #ifdef KVM_CAP_IRQ_ROUTING
>  
> -- 
> 1.8.1.4
> 
> 
> 
> _______________________________________________
> kvmarm mailing list
> kvmarm at lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm


From cdall at cs.columbia.edu  Tue Apr 23 19:02:52 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Tue, 23 Apr 2013 16:02:52 -0700
Subject: [PATCH v3 31/32] arm64: KVM: userspace API documentation
In-Reply-To: <1365437854-30214-32-git-send-email-marc.zyngier@arm.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
 <1365437854-30214-32-git-send-email-marc.zyngier@arm.com>
Message-ID: <20130423230252.GO20569@gmail.com>

On Mon, Apr 08, 2013 at 05:17:33PM +0100, Marc Zyngier wrote:
> Unsurprisingly, the arm64 userspace API is extremely similar to
> the 32bit one, the only significant difference being the ONE_REG
> register mapping.
> 
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> ---
>  Documentation/virtual/kvm/api.txt | 55 +++++++++++++++++++++++++--------------
>  1 file changed, 36 insertions(+), 19 deletions(-)
> 
> diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
> index 119358d..7c3385e 100644
> --- a/Documentation/virtual/kvm/api.txt
> +++ b/Documentation/virtual/kvm/api.txt
> @@ -280,7 +280,7 @@ kvm_run' (see below).
>  4.11 KVM_GET_REGS
>  
>  Capability: basic
> -Architectures: all except ARM
> +Architectures: all except ARM, arm64
>  Type: vcpu ioctl
>  Parameters: struct kvm_regs (out)
>  Returns: 0 on success, -1 on error
> @@ -301,7 +301,7 @@ struct kvm_regs {
>  4.12 KVM_SET_REGS
>  
>  Capability: basic
> -Architectures: all except ARM
> +Architectures: all except ARM, arm64
>  Type: vcpu ioctl
>  Parameters: struct kvm_regs (in)
>  Returns: 0 on success, -1 on error
> @@ -587,7 +587,7 @@ struct kvm_fpu {
>  4.24 KVM_CREATE_IRQCHIP
>  
>  Capability: KVM_CAP_IRQCHIP
> -Architectures: x86, ia64, ARM
> +Architectures: x86, ia64, ARM, arm64
>  Type: vm ioctl
>  Parameters: none
>  Returns: 0 on success, -1 on error
> @@ -595,14 +595,14 @@ Returns: 0 on success, -1 on error
>  Creates an interrupt controller model in the kernel.  On x86, creates a virtual
>  ioapic, a virtual PIC (two PICs, nested), and sets up future vcpus to have a
>  local APIC.  IRQ routing for GSIs 0-15 is set to both PIC and IOAPIC; GSI 16-23
> -only go to the IOAPIC.  On ia64, a IOSAPIC is created. On ARM, a GIC is
> +only go to the IOAPIC.  On ia64, a IOSAPIC is created. On ARM/arm64, a GIC is
>  created.
>  
>  
>  4.25 KVM_IRQ_LINE
>  
>  Capability: KVM_CAP_IRQCHIP
> -Architectures: x86, ia64, arm
> +Architectures: x86, ia64, arm, arm64
>  Type: vm ioctl
>  Parameters: struct kvm_irq_level
>  Returns: 0 on success, -1 on error
> @@ -612,9 +612,10 @@ On some architectures it is required that an interrupt controller model has
>  been previously created with KVM_CREATE_IRQCHIP.  Note that edge-triggered
>  interrupts require the level to be set to 1 and then back to 0.
>  
> -ARM can signal an interrupt either at the CPU level, or at the in-kernel irqchip
> -(GIC), and for in-kernel irqchip can tell the GIC to use PPIs designated for
> -specific cpus.  The irq field is interpreted like this:
> +ARM/arm64 can signal an interrupt either at the CPU level, or at the
> +in-kernel irqchip (GIC), and for in-kernel irqchip can tell the GIC to
> +use PPIs designated for specific cpus.  The irq field is interpreted
> +like this:
>  
>   ?bits:  | 31 ... 24 | 23  ... 16 | 15    ...    0 |
>    field: | irq_type  | vcpu_index |     irq_id     |
> @@ -1802,6 +1803,19 @@ ARM 32-bit VFP control registers have the following id bit patterns:
>  ARM 64-bit FP registers have the following id bit patterns:
>    0x4002 0000 0012 0 <regno:12>
>  
> +
> +arm64 registers are mapped using the lower 32 bits. The upper 16 of
> +that is the register group type, or coprocessor number:
> +
> +arm64 core/FP-SIMD registers have the following id bit patterns:
> +  0x6002 0000 0010 <index into the kvm_regs struct:16>
> +
> +arm64 CCSIDR registers are demultiplexed by CSSELR value:
> +  0x6002 0000 0011 00 <csselr:8>
> +
> +arm64 system registers have the following id bit patterns:
> +  0x6002 0000 0013 <op0:2> <op1:3> <crn:4> <crm:4> <op2:3>
> +

I think these size encodings are 4 bits off, and not accurate for for
the core registers, which have variable sizes, which should be indicated
here (unless you decide for a separate category as per my other
comment).

>  4.69 KVM_GET_ONE_REG
>  
>  Capability: KVM_CAP_ONE_REG
> @@ -2165,7 +2179,7 @@ valid entries found.
>  4.77 KVM_ARM_VCPU_INIT
>  
>  Capability: basic
> -Architectures: arm
> +Architectures: arm, arm64
>  Type: vcpu ioctl
>  Parameters: struct struct kvm_vcpu_init (in)
>  Returns: 0 on success; -1 on error
> @@ -2184,12 +2198,14 @@ should be created before this ioctl is invoked.
>  Possible features:
>  	- KVM_ARM_VCPU_POWER_OFF: Starts the CPU in a power-off state.
>  	  Depends on KVM_CAP_ARM_PSCI.
> +	- KVM_ARM_VCPU_EL1_32BIT: Starts the CPU in a 32bit mode.
> +	  Depends on KVM_CAP_ARM_EL1_32BIT (arm64 only).
>  
>  
>  4.78 KVM_GET_REG_LIST
>  
>  Capability: basic
> -Architectures: arm
> +Architectures: arm, arm64
>  Type: vcpu ioctl
>  Parameters: struct kvm_reg_list (in/out)
>  Returns: 0 on success; -1 on error
> @@ -2209,7 +2225,7 @@ KVM_GET_ONE_REG/KVM_SET_ONE_REG calls.
>  4.80 KVM_ARM_SET_DEVICE_ADDR
>  
>  Capability: KVM_CAP_ARM_SET_DEVICE_ADDR
> -Architectures: arm
> +Architectures: arm, arm64
>  Type: vm ioctl
>  Parameters: struct kvm_arm_device_address (in)
>  Returns: 0 on success, -1 on error
> @@ -2230,18 +2246,19 @@ can access emulated or directly exposed devices, which the host kernel needs
>  to know about. The id field is an architecture specific identifier for a
>  specific device.
>  
> -ARM divides the id field into two parts, a device id and an address type id
> -specific to the individual device.
> +ARM/arm64 divides the id field into two parts, a device id and an
> +address type id specific to the individual device.
>  
>   ?bits:  | 63        ...       32 | 31    ...    16 | 15    ...    0 |
>    field: |        0x00000000      |     device id   |  addr type id  |
>  
> -ARM currently only require this when using the in-kernel GIC support for the
> -hardware VGIC features, using KVM_ARM_DEVICE_VGIC_V2 as the device id.  When
> -setting the base address for the guest's mapping of the VGIC virtual CPU
> -and distributor interface, the ioctl must be called after calling
> -KVM_CREATE_IRQCHIP, but before calling KVM_RUN on any of the VCPUs.  Calling
> -this ioctl twice for any of the base addresses will return -EEXIST.
> +ARM/arm64 currently only require this when using the in-kernel GIC
> +support for the hardware VGIC features, using KVM_ARM_DEVICE_VGIC_V2
> +as the device id.  When setting the base address for the guest's
> +mapping of the VGIC virtual CPU and distributor interface, the ioctl
> +must be called after calling KVM_CREATE_IRQCHIP, but before calling
> +KVM_RUN on any of the VCPUs.  Calling this ioctl twice for any of the
> +base addresses will return -EEXIST.
>  
>  
>  5. The kvm_run structure
> -- 
> 1.8.1.4
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


From cdall at cs.columbia.edu  Tue Apr 23 19:04:09 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Tue, 23 Apr 2013 16:04:09 -0700
Subject: [PATCH v3 00/32] Port of KVM to arm64
In-Reply-To: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <20130423230409.GA32157@gmail.com>

On Mon, Apr 08, 2013 at 05:17:02PM +0100, Marc Zyngier wrote:
> This series contains the third version of KVM for arm64.
> 
> It depends on the following branches/series:
> - git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch64.git soc-armv8-model
>   Catalin's platform support branch for v8 models
> - git://github.com/columbia/linux-kvm-arm.git kvm-arm-fixes
>   mostly reworking the 32bit port to accomodate for arm64
> - git://github.com/columbia/linux-kvm-arm.git kvm-arm-next
>   adding perf support
> - http://lists.infradead.org/pipermail/linux-arm-kernel/2013-April/161381.html
>   reworking the whole init procedure for KVM/ARM
> - http://lists.infradead.org/pipermail/linux-arm-kernel/2013-April/161395.html
>   more 32bit rework
> 
> The code is unsurprisingly extremely similar to the KVM/arm code, and
> a lot of it is actually shared with the 32bit version. Some of the
> include files are duplicated though (I'm definitely willing to fix
> that).
> 
> In terms of features:
> - Support for 4k and 64k pages
> - Support for 32bit and 64bit guests
> - PSCI support for SMP booting
> 
> Testing has been done on both AEMv8 and Foundation models, with
> various 32 and 64bit guests running a variety of distributions (OE,
> Ubuntu and openSUSE for 64bit, Debian and Ubuntu on 32bit).
> 
> The patches are also available on the following branch:
> git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git kvm-arm64/kvm

Hi Marc,

Nice job! I finally got through this series, and besides the mostly
cosmetic comments it looks pretty good to me.  I hope we can do slightly
more code sharing between the two platforms before a merge (especially
the identical header files and some of the fault injection stuff), but I
realize there may be technical reasons that make this hard to
accomplish.  Definitely kudos on being so feature complete that early.

I haven't been able to verify every bit and piece of control registers
and such, since I don't have the necessary docs, but from what I can
gather this looks pretty good, so, assuming you address the comments I
gave (especially at the least clearly commenting on the index into the
kvm_regs struct):

	Acked-by: Christoffer Dall <cdall at cs.columbia.edu>

-Christoffer

> 
> As we do not have a 64bit QEMU port, it has been tested using
> kvmtools. Note that some of the changes have broken the userspace ABI
> in v2, and you must update and rebuild your kvmtools (the previous
> version won't work anymore):
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git kvm-arm64/kvmtool
> 
> >From v2:
> - Dropped the idmap code and use the new KVM/ARM boot protocol
> - New KVM_CAP_ARM_EL1_32BIT capability to let userspace detect if EL1
>   is 32bit capable
> - Fixed a bug in arch/arm/entry.S, where EL0/EL1 breakpoint handling was
>   mixed up (spotted by Catalin Marinas)
> - Some sparse fixes (courtesy of Geoff Levand)
> - Dropped the "shared" attribute from device mappings (spotted by Catalin)
> - Add API documentation
> - Add MAINTAINERS entry
> 
> >From v1:
> - Rework of the world-switch to use common structure between host and
>   guests (suggested by Christopher Covington)
> - Some additional constants to make the EL1 fault injection clearer
>   (suggested by Christopher Covington)
> - Use of __u64 instead of "unsigned long" in the userspace API
>   (suggested by Michael S. Tsirkin)
> - Move the FP/SIMD registers into the "core" registers, dropping the
>   specific accessors.
> - Generic MPIDR implementation (suggested by Christopher Covington)
> - Cleaner handling of the various host implementations
> 
> Marc Zyngier (32):
>   arm64: add explicit symbols to ESR_EL1 decoding
>   arm64: KVM: define HYP and Stage-2 translation page flags
>   arm64: KVM: HYP mode idmap support
>   arm64: KVM: EL2 register definitions
>   arm64: KVM: system register definitions for 64bit guests
>   arm64: KVM: Basic ESR_EL2 helpers and vcpu register access
>   arm64: KVM: fault injection into a guest
>   arm64: KVM: architecture specific MMU backend
>   arm64: KVM: user space interface
>   arm64: KVM: system register handling
>   arm64: KVM: CPU specific system registers handling
>   arm64: KVM: virtual CPU reset
>   arm64: KVM: kvm_arch and kvm_vcpu_arch definitions
>   arm64: KVM: MMIO access backend
>   arm64: KVM: guest one-reg interface
>   arm64: KVM: hypervisor initialization code
>   arm64: KVM: HYP mode world switch implementation
>   arm64: KVM: Exit handling
>   arm64: KVM: Plug the VGIC
>   arm64: KVM: Plug the arch timer
>   arm64: KVM: PSCI implementation
>   arm64: KVM: Build system integration
>   arm64: KVM: define 32bit specific registers
>   arm64: KVM: 32bit GP register access
>   arm64: KVM: 32bit conditional execution emulation
>   arm64: KVM: 32bit handling of coprocessor traps
>   arm64: KVM: CPU specific 32bit coprocessor access
>   arm64: KVM: 32bit specific register world switch
>   arm64: KVM: 32bit guest fault injection
>   arm64: KVM: enable initialization of a 32bit vcpu
>   arm64: KVM: userspace API documentation
>   arm64: KVM: MAINTAINERS update
> 
>  Documentation/virtual/kvm/api.txt       |   55 +-
>  MAINTAINERS                             |    9 +
>  arch/arm/kvm/arch_timer.c               |    1 +
>  arch/arm64/Kconfig                      |    2 +
>  arch/arm64/Makefile                     |    2 +-
>  arch/arm64/include/asm/esr.h            |   55 ++
>  arch/arm64/include/asm/kvm_arch_timer.h |   58 ++
>  arch/arm64/include/asm/kvm_arm.h        |  243 ++++++++
>  arch/arm64/include/asm/kvm_asm.h        |  104 ++++
>  arch/arm64/include/asm/kvm_coproc.h     |   56 ++
>  arch/arm64/include/asm/kvm_emulate.h    |  185 ++++++
>  arch/arm64/include/asm/kvm_host.h       |  202 ++++++
>  arch/arm64/include/asm/kvm_mmio.h       |   59 ++
>  arch/arm64/include/asm/kvm_mmu.h        |  136 ++++
>  arch/arm64/include/asm/kvm_psci.h       |   23 +
>  arch/arm64/include/asm/kvm_vgic.h       |  156 +++++
>  arch/arm64/include/asm/pgtable-hwdef.h  |   13 +
>  arch/arm64/include/asm/pgtable.h        |   12 +
>  arch/arm64/include/uapi/asm/kvm.h       |  168 +++++
>  arch/arm64/kernel/asm-offsets.c         |   34 +
>  arch/arm64/kernel/entry.S               |   53 +-
>  arch/arm64/kernel/vmlinux.lds.S         |   16 +
>  arch/arm64/kvm/Kconfig                  |   59 ++
>  arch/arm64/kvm/Makefile                 |   19 +
>  arch/arm64/kvm/emulate.c                |  154 +++++
>  arch/arm64/kvm/guest.c                  |  260 ++++++++
>  arch/arm64/kvm/handle_exit.c            |  124 ++++
>  arch/arm64/kvm/hyp-init.S               |  112 ++++
>  arch/arm64/kvm/hyp.S                    |  816 ++++++++++++++++++++++++
>  arch/arm64/kvm/inject_fault.c           |  195 ++++++
>  arch/arm64/kvm/regmap.c                 |  168 +++++
>  arch/arm64/kvm/reset.c                  |   99 +++
>  arch/arm64/kvm/sys_regs.c               | 1035 +++++++++++++++++++++++++++++++
>  arch/arm64/kvm/sys_regs.h               |  138 +++++
>  arch/arm64/kvm/sys_regs_generic_v8.c    |   95 +++
>  include/uapi/linux/kvm.h                |    2 +
>  36 files changed, 4872 insertions(+), 46 deletions(-)
>  create mode 100644 arch/arm64/include/asm/esr.h
>  create mode 100644 arch/arm64/include/asm/kvm_arch_timer.h
>  create mode 100644 arch/arm64/include/asm/kvm_arm.h
>  create mode 100644 arch/arm64/include/asm/kvm_asm.h
>  create mode 100644 arch/arm64/include/asm/kvm_coproc.h
>  create mode 100644 arch/arm64/include/asm/kvm_emulate.h
>  create mode 100644 arch/arm64/include/asm/kvm_host.h
>  create mode 100644 arch/arm64/include/asm/kvm_mmio.h
>  create mode 100644 arch/arm64/include/asm/kvm_mmu.h
>  create mode 100644 arch/arm64/include/asm/kvm_psci.h
>  create mode 100644 arch/arm64/include/asm/kvm_vgic.h
>  create mode 100644 arch/arm64/include/uapi/asm/kvm.h
>  create mode 100644 arch/arm64/kvm/Kconfig
>  create mode 100644 arch/arm64/kvm/Makefile
>  create mode 100644 arch/arm64/kvm/emulate.c
>  create mode 100644 arch/arm64/kvm/guest.c
>  create mode 100644 arch/arm64/kvm/handle_exit.c
>  create mode 100644 arch/arm64/kvm/hyp-init.S
>  create mode 100644 arch/arm64/kvm/hyp.S
>  create mode 100644 arch/arm64/kvm/inject_fault.c
>  create mode 100644 arch/arm64/kvm/regmap.c
>  create mode 100644 arch/arm64/kvm/reset.c
>  create mode 100644 arch/arm64/kvm/sys_regs.c
>  create mode 100644 arch/arm64/kvm/sys_regs.h
>  create mode 100644 arch/arm64/kvm/sys_regs_generic_v8.c
> 
> -- 
> 1.8.1.4
> 
> 
> 
> _______________________________________________
> kvmarm mailing list
> kvmarm at lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm


From cdall at cs.columbia.edu  Tue Apr 23 19:07:05 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Tue, 23 Apr 2013 16:07:05 -0700
Subject: [kvmarm] [PATCH 09/29] arm64: KVM: system register handling
In-Reply-To: <40f45d8ddae65e29a6145bbe5c96d0bb@localhost>
References: <1362455265-24165-1-git-send-email-marc.zyngier@arm.com>
 <1362455265-24165-10-git-send-email-marc.zyngier@arm.com>
 <2CF940F9-4643-4C32-8A71-23DAD18EE9FA@suse.de>
 <40f45d8ddae65e29a6145bbe5c96d0bb@localhost>
Message-ID: <CAEDV+gKjL=XDBXpC+Dh18yf7MwKhKiAVWZiU_1tgaLUJQkV-vg@mail.gmail.com>

On Mon, Mar 25, 2013 at 1:19 AM, Marc Zyngier <marc.zyngier at arm.com> wrote:
> Hi Alex,
>
> On Thu, 7 Mar 2013 11:30:20 +0100, Alexander Graf <agraf at suse.de> wrote:
>> On 05.03.2013, at 04:47, Marc Zyngier wrote:
>>
>>> Provide 64bit system register handling, modeled after the cp15
>>> handling for ARM.
>>>
>>> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
>>> ---
>
> [...]
>
>>> +static int emulate_sys_reg(struct kvm_vcpu *vcpu,
>>> +                       const struct sys_reg_params *params)
>>> +{
>>> +    size_t num;
>>> +    const struct sys_reg_desc *table, *r;
>>> +
>>> +    table = get_target_table(vcpu->arch.target, &num);
>>> +
>>> +    /* Search target-specific then generic table. */
>>> +    r = find_reg(params, table, num);
>>> +    if (!r)
>>> +            r = find_reg(params, sys_reg_descs, ARRAY_SIZE(sys_reg_descs));
>>
>> Searching through the whole list sounds quite slow. Especially since the
>> TLS register is at the very bottom of it.
>>
>> Can't you make this a simple switch() statement through a bit of #define
>> and maybe #include magic? After all, the sysreg target encoding is all
> part
>> of the opcode. And from my experience in the PPC instruction emulator,
>> switch()es are _a lot_ faster than any other way of lookup I've tried.
>
> So I've had a go at implementing this, and decided it is not worth the
> effort if we want to preserve the same level of functionality (ONE_REG
> discovery, sanity checking at VM startup...).
>
> Granted, we would gain a faster trap handling. But look at what we're
> actually trapping, and how often this happens. Almost nothing, almost
> never. So, until shown that we spend too much time iterating over the
> sys_reg_desc array, I'll keep it simple.
>
> This is not to say that there's no optimization to be made. Quite the
> opposite! Just that this particular one seems a bit overkill.
>
> Anyway, thanks for pushing me into pondering this! :-)
>
totally late in the game here, but I saw you discussed this briefly on
IRC as well, and I completely agree with Marc here, we have much
bigger fish to fry. On all the measurements I did on the 32-bit side,
this doesn't even begin to show up on the radar.

vgic man, vgic!

-Christoffer


From tony at atomide.com  Tue Apr 23 19:16:06 2013
From: tony at atomide.com (Tony Lindgren)
Date: Tue, 23 Apr 2013 16:16:06 -0700
Subject: Multiple issues with omap4 panda es in linux next
In-Reply-To: <20130423213151.GM10155@atomide.com>
References: <20130419171318.GK10155@atomide.com> <5174F7A8.7070308@ti.com>
 <20130422180316.GA10155@atomide.com> <5176A45B.5@ti.com>
 <20130423172353.GD10155@atomide.com>
 <20130423213151.GM10155@atomide.com>
Message-ID: <20130423231605.GO10155@atomide.com>

* Tony Lindgren <tony at atomide.com> [130423 14:37]:
> * Tony Lindgren <tony at atomide.com> [130423 10:28]:
> > * Kishon Vijay Abraham I <kishon at ti.com> [130423 08:15]:
> > > >>>2. MUSB fails with legacy booting and DT on panda es
> > > >>>
> > > >>>With both legacy and DT booting I get something like:
> > > >>>
> > > >>>HS USB OTG: no transceiver configured
> > > >>>musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with status -517
> > > >>
> > > >>The dt should work fine with https://patchwork.kernel.org/patch/2423061/.
> > > >
> > > >OK thanks for checking that.

Kishon, I think there's also some other issue remaining
in linux next with MUSB and DT. I'm still getting the
"HS USB OTG: no transceiver configured" although the nop
xceiv is compiled in. Maybe give it a try against linux
next?

Regards,

Tony


From andy.green at linaro.org  Tue Apr 23 19:30:02 2013
From: andy.green at linaro.org (Andy Green)
Date: Wed, 24 Apr 2013 07:30:02 +0800
Subject: [PATCHv3 00/14] drivers: mailbox: framework creation
In-Reply-To: <37C860A02101E749A747FA2D3C1E3C504A63B4@DLEE11.ent.ti.com>
References: <1363145021-14339-1-git-send-email-s-anna@ti.com>
 <CABb+yY0RYkVeo2Sb4WsDJY0jf17488FEz0d2CB994eQaSOEsVg@mail.gmail.com>
 <37C860A02101E749A747FA2D3C1E3C504A5DF7@DLEE11.ent.ti.com>
 <CABb+yY1x4x_A+QtGG9ohsLPgs8c3nEVnd_ExJBGOOR8=6YLPFA@mail.gmail.com>
 <37C860A02101E749A747FA2D3C1E3C504A63B4@DLEE11.ent.ti.com>
Message-ID: <5177197A.4050104@linaro.org>

On 24/04/13 03:20, the mail apparently from Anna, Suman included:

Hi Suman -

> This series missed the 3.9 merge window, and is currently slated for
> getting merged into 3.10. The PL320 made it into 3.9 itself (I wasn't
> aware of it until I saw it in mainline) and created the
> drivers/mailbox folder.  I would think it would be relatively
> straight-forward to adopt it to the mailbox API, as it has only 3
> API. We should be doing incremental changes on top of this series, as
> most of the base API would still be the same. The current series is
> helping out with couple of efforts, the breaking up of the PRCMU code
> and on the multiplatform support for OMAP with mailbox enabled. We
> can definitely collaborate on the improvements. Andy Green would also
> be interested, as he is also looking into adopting the mailbox API.

To clarify Jassi works on my team, after I wrote two Mailbox drivers for 
two different IP on the chips we're working on, I handed them off to him 
and Jassi's working on further integration using those drivers.  So 
we're both doing the same thing.

 From my POV I am very happy you made the new API - before that there 
was only PL320 sitting there and nothing you could call an API.  Once I 
understood the approach (no docs was a bit painful) I was able to 
implement both drivers we needed with what you have.

The main problem I have with it we discussed in direct mail previously, 
since we have two different mailbox IP, we need to improve the register 
/ unregister so it can cope, right now it's unnecessarily limited to one 
mailbox driver.

That "there can only be one" approach also leaked out into the drivers 
having filescope statics for things that should have been instantiated 
per-mailbox device (including device naming as literals, rather than 
mbox%d needed if there can be multiple drivers).  In my driver 
implementations I moved them to live in the per-device priv struct and 
stored the names in there too.

The other point I mentioned before was the FIFO, it's always there and 
size set by CONFIG_ stuff.  Actually it would be better if it was set 
per mailbox or per mailbox driver at runtime.  For one of the IPs, we 
will have another driver mediating access to the mailbox that enforces a 
single client access covering possibly multiple mailbox messages.  Under 
those conditions, a fifo isn't really meaningful.  But that's less of a 
problem.

As I say I was very happy to see you addressing the lack of an API, 
Jassi though is working deeper with it than just making the mailbox 
drivers as I did; he's using the API from other consumer drivers so he 
may have a different set of concerns or, looking at what he's written 
here, opportunities.

-Andy

-- 
Andy Green | Fujitsu Landing Team Leader
Linaro.org ? Open source software for ARM SoCs | Follow Linaro
http://facebook.com/pages/Linaro/155974581091106  -
http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog


From akpm at linux-foundation.org  Tue Apr 23 19:43:03 2013
From: akpm at linux-foundation.org (Andrew Morton)
Date: Tue, 23 Apr 2013 16:43:03 -0700
Subject: [PATCH V2 1/3] seccomp: add generic code for jitted seccomp
 filters.
In-Reply-To: <51752D98.8070709@freebox.fr>
References: <1363618233-6375-1-git-send-email-nschichan@freebox.fr>
 <1363618233-6375-2-git-send-email-nschichan@freebox.fr>
 <20130417145628.88058f0f3104ab9ae551ddd3@linux-foundation.org>
 <51752D98.8070709@freebox.fr>
Message-ID: <20130423164303.d2eb663c4a1becea4a185087@linux-foundation.org>

On Mon, 22 Apr 2013 14:31:20 +0200 Nicolas Schichan <nschichan at freebox.fr> wrote:

> On 04/17/2013 11:56 PM, Andrew Morton wrote:
> > This patch is killing me.
> >
> >> --- a/include/linux/seccomp.h
> >> +++ b/include/linux/seccomp.h
> >> @@ -6,6 +6,7 @@
> >>   #ifdef CONFIG_SECCOMP
> >>
> >>   #include <linux/thread_info.h>
> >> +#include <linux/filter.h>
> >>   #include <asm/seccomp.h>
> >
> > In file included from include/linux/compat.h:18,
> >                   from include/linux/filter.h:9,
> >                   from include/linux/seccomp.h:9,
> >                   from include/linux/sched.h:39,
> >                   from arch/x86/kernel/asm-offsets.c:9:
> > /usr/src/25/arch/x86/include/asm/compat.h: In function 'arch_compat_alloc_user_space':
> > /usr/src/25/arch/x86/include/asm/compat.h:301: error: dereferencing pointer to incomplete type
> >
> > Problem is, compat.h's arch_compat_alloc_user_space() needs sched.h for
> > task_struct but as you can see from the above include tree, sched.h
> > includes seccomp.h and everything falls over.  The preprocessed code
> > contains the definition of arch_compat_alloc_user_space() *before* the
> > definition of task_struct.
> >
> > This is a basic x86_64 "make clean; make allmodconfig; make".
> 
> Hi,
> 
> Would including <uapi/linux/filter.h> instead of <linux/filter.h> in seccomp.h 
> be an acceptable solution ?
> 
> I have tried that and (with an additional forward declaration of struct 
> sk_buff) an x86_64 "make clean; make allmodconfig" run finishes succesfully.
> 
> If that's ok with you, I can resend the serie with that fix.

It would be better to make the code and include tangle less complex,
rather than more complex.

Did we really need to move the `struct seccomp_filter' definition into
the header file?  afaict that wasn't really necessary - we can add a
few helper functions to kernel/seccomp.c and then have the remote code
treat seccomp_filter in an opaque fashion rather than directly poking
at its internals.


btw, what on earth is going on with seccomp_jit_free()?  It does
disturbing undocumented typecasting and it punts the module_free into a
kernel thread for mysterious, undocumented and possibly buggy reasons.

I realize it just copies bpf_jit_free().  The same observations apply there.


From mcgrof at do-not-panic.com  Tue Apr 23 19:49:17 2013
From: mcgrof at do-not-panic.com (Luis R. Rodriguez)
Date: Tue, 23 Apr 2013 16:49:17 -0700
Subject: Central Linux ARM wiki
In-Reply-To: <CAB=NE6VEmnVGtdU=kbWnDwq0TXSs-UcFgcxCKE1QptZWteBqiA@mail.gmail.com>
References: <CAB=NE6VEmnVGtdU=kbWnDwq0TXSs-UcFgcxCKE1QptZWteBqiA@mail.gmail.com>
Message-ID: <CAB=NE6XDUFx-MrrhwXpcjSUjEFLVgOpTSnMh_25mgZdfW7abSA@mail.gmail.com>

On Mon, Apr 8, 2013 at 2:04 PM, Luis R. Rodriguez
<mcgrof at do-not-panic.com> wrote:
> Do we have a central place to centrally document ARM development
> upstream? I'd like to start using a central place to start documenting
> things for some stuff I'd like to work on and I don't want to use any
> vendor specific stuff. Are we go happy with using elinux.org ? If so
> can we add a reference to that as the place for ARM development from
> wiki.kernel.org ?

I haven't heard any complaints, so Konstantin, can we refer elinux.org
from wiki.kernel.org as the wiki for ARM development ?

  Luis


From lauraa at codeaurora.org  Tue Apr 23 19:51:38 2013
From: lauraa at codeaurora.org (Laura Abbott)
Date: Tue, 23 Apr 2013 16:51:38 -0700
Subject: [PATCH] arm: mm: Use phys_addr_t properly for ioremap functions
Message-ID: <1366761098-4485-1-git-send-email-lauraa@codeaurora.org>

Several of the ioremap functions use unsigned long in places
resulting in truncation if physical addresses greater than
4G are passed in. Change the types appropriately.

Signed-off-by: Laura Abbott <lauraa at codeaurora.org>
---
 arch/arm/include/asm/io.h |    8 ++++----
 arch/arm/mm/ioremap.c     |   12 ++++++------
 2 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/arch/arm/include/asm/io.h b/arch/arm/include/asm/io.h
index c1295c4..70d82ec 100644
--- a/arch/arm/include/asm/io.h
+++ b/arch/arm/include/asm/io.h
@@ -119,16 +119,16 @@ extern void __raw_readsl(const void __iomem *addr, void *data, int longlen);
  */
 extern void __iomem *__arm_ioremap_pfn_caller(unsigned long, unsigned long,
 	size_t, unsigned int, void *);
-extern void __iomem *__arm_ioremap_caller(unsigned long, size_t, unsigned int,
+extern void __iomem *__arm_ioremap_caller(phys_addr_t, size_t, unsigned int,
 	void *);
 
 extern void __iomem *__arm_ioremap_pfn(unsigned long, unsigned long, size_t, unsigned int);
-extern void __iomem *__arm_ioremap(unsigned long, size_t, unsigned int);
-extern void __iomem *__arm_ioremap_exec(unsigned long, size_t, bool cached);
+extern void __iomem *__arm_ioremap(phys_addr_t, size_t, unsigned int);
+extern void __iomem *__arm_ioremap_exec(phys_addr_t, size_t, bool cached);
 extern void __iounmap(volatile void __iomem *addr);
 extern void __arm_iounmap(volatile void __iomem *addr);
 
-extern void __iomem * (*arch_ioremap_caller)(unsigned long, size_t,
+extern void __iomem * (*arch_ioremap_caller)(phys_addr_t, size_t,
 	unsigned int, void *);
 extern void (*arch_iounmap)(volatile void __iomem *);
 
diff --git a/arch/arm/mm/ioremap.c b/arch/arm/mm/ioremap.c
index 8df41e2..07b6f6c 100644
--- a/arch/arm/mm/ioremap.c
+++ b/arch/arm/mm/ioremap.c
@@ -280,11 +280,11 @@ void __iomem * __arm_ioremap_pfn_caller(unsigned long pfn,
 	return (void __iomem *) (offset + addr);
 }
 
-void __iomem *__arm_ioremap_caller(unsigned long phys_addr, size_t size,
+void __iomem *__arm_ioremap_caller(phys_addr_t phys_addr, size_t size,
 	unsigned int mtype, void *caller)
 {
-	unsigned long last_addr;
- 	unsigned long offset = phys_addr & ~PAGE_MASK;
+	phys_addr_t last_addr;
+	phys_addr_t offset = phys_addr & ~PAGE_MASK;
  	unsigned long pfn = __phys_to_pfn(phys_addr);
 
  	/*
@@ -316,12 +316,12 @@ __arm_ioremap_pfn(unsigned long pfn, unsigned long offset, size_t size,
 }
 EXPORT_SYMBOL(__arm_ioremap_pfn);
 
-void __iomem * (*arch_ioremap_caller)(unsigned long, size_t,
+void __iomem * (*arch_ioremap_caller)(phys_addr_t, size_t,
 				      unsigned int, void *) =
 	__arm_ioremap_caller;
 
 void __iomem *
-__arm_ioremap(unsigned long phys_addr, size_t size, unsigned int mtype)
+__arm_ioremap(phys_addr_t phys_addr, size_t size, unsigned int mtype)
 {
 	return arch_ioremap_caller(phys_addr, size, mtype,
 		__builtin_return_address(0));
@@ -336,7 +336,7 @@ EXPORT_SYMBOL(__arm_ioremap);
  * CONFIG_GENERIC_ALLOCATOR for allocating external memory.
  */
 void __iomem *
-__arm_ioremap_exec(unsigned long phys_addr, size_t size, bool cached)
+__arm_ioremap_exec(phys_addr_t phys_addr, size_t size, bool cached)
 {
 	unsigned int mtype;
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From syin at broadcom.com  Tue Apr 23 19:55:40 2013
From: syin at broadcom.com (Sherman Yin)
Date: Tue, 23 Apr 2013 16:55:40 -0700
Subject: [PATCH v2] ARM: Fix l2x0_init log message
In-Reply-To: <5ddc968feee3af6c462b24ca53eeeb11bbb7b7a3>
References: <5ddc968feee3af6c462b24ca53eeeb11bbb7b7a3>
Message-ID: <1366761340-6550-1-git-send-email-syin@broadcom.com>

In the log at the end of l2x0_init(), "ways" and "l2x0_size" should be derived
from the most recently read value from the AUX register.  Previously, these
were derived from the earlier value of the AUX register with modifications by
the function paramters aux_val and aux_mask.

Signed-off-by: Sherman Yin <syin at broadcom.com>
---
v2: Corrected switch statement

arch/arm/mm/cache-l2x0.c |   39 +++++++++++++++++++++++++++++++--------
 1 file changed, 31 insertions(+), 8 deletions(-)

diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index c465fac..ca50099 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -376,14 +376,6 @@ void __init l2x0_init(void __iomem *base, u32 aux_val, u32 aux_mask)
 	l2x0_way_mask = (1 << ways) - 1;
 
 	/*
-	 * L2 cache Size =  Way size * Number of ways
-	 */
-	way_size = (aux & L2X0_AUX_CTRL_WAY_SIZE_MASK) >> 17;
-	way_size = 1 << (way_size + way_size_shift);
-
-	l2x0_size = ways * way_size * SZ_1K;
-
-	/*
 	 * Check if l2x0 controller is already enabled.
 	 * If you are booting from non-secure mode
 	 * accessing the below registers will fault.
@@ -417,6 +409,37 @@ void __init l2x0_init(void __iomem *base, u32 aux_val, u32 aux_mask)
 		outer_cache.disable = l2x0_disable;
 	}
 
+	/* Update number of ways based on aux ctrl register value */
+	switch (cache_id & L2X0_CACHE_ID_PART_MASK) {
+	case L2X0_CACHE_ID_PART_L310:
+		if (aux & (1 << 16))
+			ways = 16;
+		else
+			ways = 8;
+		break;
+	case L2X0_CACHE_ID_PART_L210:
+		ways = (aux >> 13) & 0xf;
+		break;
+
+	case AURORA_CACHE_ID:
+		ways = (aux >> 13) & 0xf;
+		ways = 2 << ((ways + 1) >> 2);
+		way_size_shift = AURORA_WAY_SIZE_SHIFT;
+		break;
+	default:
+		/* Assume unknown chips have 8 ways */
+		ways = 8;
+		break;
+	}
+
+	/*
+	 * L2 cache Size =  Way size * Number of ways
+	 */
+	way_size = (aux & L2X0_AUX_CTRL_WAY_SIZE_MASK) >> 17;
+	way_size = 1 << (way_size + way_size_shift);
+
+	l2x0_size = ways * way_size * SZ_1K;
+
 	printk(KERN_INFO "%s cache controller enabled\n", type);
 	printk(KERN_INFO "l2x0: %d ways, CACHE_ID 0x%08x, AUX_CTRL 0x%08x, Cache size: %d B\n",
 			ways, cache_id, aux, l2x0_size);
-- 
1.7.9.5




From olof at lixom.net  Tue Apr 23 20:06:38 2013
From: olof at lixom.net (Olof Johansson)
Date: Tue, 23 Apr 2013 17:06:38 -0700
Subject: [GIT PULL] Late Exynos stuff for v3.10
In-Reply-To: <51770697.7080504@samsung.com>
References: <5176B499.1000208@samsung.com>
 <51770697.7080504@samsung.com>
Message-ID: <20130424000638.GA9067@quad.lixom.net>

Hi,

On Wed, Apr 24, 2013 at 07:09:27AM +0900, Kukjin Kim wrote:

> Arnd, Olof,
> 
> Since above request should be too late, so I did sort out like
> following. I think, it should be fine to you ;-) Sorry for noise.
> 
> Note that others will be queued for v3.11.
> 

[..]


>  ----------------------------------------------------------------
>  This includes late exynos stuff for v3.10 and 2nd version for pull
> request 1) enables usb2phy, usb3phy and dwc3-exynos for exynos5250
> 2) support chip id with dt
> 
>  ----------------------------------------------------------------
>  Doug Anderson (1):
>        ARM: dts: Disable the RTC by default on exynos5
> 
>  Thomas Abraham (3):
>        ARM: dts: add mshc controller node for Exynos4x12 SoCs
>        ARM: EXYNOS: Create virtual I/O mapping for Chip-ID
> controller using device tree
>        ARM: dts: Add chip-id controller node on Exynos4/5 SoC
> 
>  Vivek Gautam (5):
>        ARM: dts: Enabling samsung-usb2phy driver for exynos5250
>        ARM: dts: Enabling samsung-usb3phy driver for exynos5250
>        ARM: dts: Add device tree bindings for dwc3-exynos
>        ARM: dts: Enabling dwc3-exynos driver for exynos5250
>        ARM: EXYNOS: Enable XHCI support on exynos5


Can I please ask you to make our life a little easier by telling us what the
specific problems these patches solve are? What I am looking for is something
along the lines of:

--

This branch includes some last-minute enablements of DT contents for features
that are queued for 3.10:
 - USB PHY drivers on Exynos 5250
 - MMC (mshc) on Exynos 4x12
 - XCHI (USB 3.0) on Exynos 5250

It also contains a fix to disable RTC on exynos [because ... you fill in this
part].

--

It doesn't have to be something super-elaborate, but I'd like it to be sort of
self-documenting in a way that I don't have to look through the series of
patches to get an overview of what's in the branch. Of course we'll also do
that to review the code, but having the description there makes things easier
for us to tell if we should even be looking at it, etc.



Thanks!

-Olof


From marex at denx.de  Tue Apr 23 20:31:49 2013
From: marex at denx.de (Marek Vasut)
Date: Wed, 24 Apr 2013 02:31:49 +0200
Subject: [RFC][PATCH] video: imx: Select VIDEOMODE_HELPERS
In-Reply-To: <1366702862.4365.2.camel@pizza.hi.pengutronix.de>
References: <1366666110-9585-1-git-send-email-marex@denx.de>
 <201304230157.47992.marex@denx.de>
 <1366702862.4365.2.camel@pizza.hi.pengutronix.de>
Message-ID: <201304240231.49579.marex@denx.de>

Hi Philipp,

> Hi Marek,
> 
> Am Dienstag, den 23.04.2013, 01:57 +0200 schrieb Marek Vasut:
> > Dear Fabio Estevam,
> > 
> > > Hi Marek,
> > > 
> > > On Mon, Apr 22, 2013 at 6:28 PM, Marek Vasut <marex at denx.de> wrote:
> > > > Without this, I get the following problem when building kernel:
> > > > 
> > > > drivers/built-in.o: In function `imx_pd_connector_get_modes':
> > > > /linux-2.6/drivers/staging/imx-drm/parallel-display.c:78: undefined
> > > > reference to `of_get_drm_display_mode' make: *** [vmlinux] Error 1
> > > > 
> > > > NOTE: I think this patch is almost absolutely not correct.
> > > > 
> > > > Signed-off-by: Marek Vasut <marex at denx.de>
> > > > Cc: Sascha Hauer <s.hauer at pengutronix.de>
> > > > Cc: Philipp Zabel <p.zabel at pengutronix.de>
> > > > Cc: Fabio Estevam <fabio.estevam at freescale.com>
> > > 
> > > Patch looks good, but you should have copied Greg Kroah-Hartman, as he
> > > is the one who takes patches into staging.
> > 
> > I'm not sure if the select is at correct symbol, I dont think it is.
> 
> OF_VIDEOMODE is the correct one. The implementation of
> of_get_drm_display_mode in drivers/gpu/drm/drm_modes.c depends on it.

I really need VIDEOMODE_HELPERS, not OF_VIDEOMODE. If I select only 
OF_VIDEOMODE, I still get the issue above.

Check drivers/gpu/drm/drm_modes.c , it's protected by CONFIG_VIDEOMODE_HELPERS

Best regards,
Marek Vasut


From lauraa at codeaurora.org  Tue Apr 23 20:50:49 2013
From: lauraa at codeaurora.org (Laura Abbott)
Date: Tue, 23 Apr 2013 17:50:49 -0700
Subject: [PATCH] of: Set the DMA mask to 64 bits on ARM LPAE systems
Message-ID: <1366764649-10342-1-git-send-email-lauraa@codeaurora.org>

By default on ARM systems, the coherent DMA mask (lowest
address) is set to ~0 or 0xFFFFFFFFFFFFFFFF. Currently,
of_platform_device_create_pdata sets the coherent DMA mask to
32 bits. This prevents coherent dma allocations from working by default
without clients setting the DMA mask. Rather than make every client
on an LPAE system set the mask, set the mask to a 64 bit value on
ARM LPAE systems.

Signed-off-by: Laura Abbott <lauraa at codeaurora.org>
---
 drivers/of/platform.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index 0970505..18b69c1 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -214,7 +214,11 @@ struct platform_device *of_platform_device_create_pdata(
 #if defined(CONFIG_MICROBLAZE)
 	dev->archdata.dma_mask = 0xffffffffUL;
 #endif
+#ifdef CONFIG_ARM_LPAE
+	dev->dev.coherent_dma_mask = DMA_BIT_MASK(64);
+#else
 	dev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
+#endif
 	dev->dev.bus = &platform_bus_type;
 	dev->dev.platform_data = platform_data;
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From shawn.guo at linaro.org  Tue Apr 23 21:11:55 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Wed, 24 Apr 2013 09:11:55 +0800
Subject: [PATCH] ASoC: don't call of_dma_request_slave_channel directly
In-Reply-To: <1366732475-479886-3-git-send-email-arnd@arndb.de>
References: <1366732475-479886-1-git-send-email-arnd@arndb.de>
 <1366732475-479886-3-git-send-email-arnd@arndb.de>
Message-ID: <20130424011153.GA2319@shlinux1.ap.freescale.net>

On Tue, Apr 23, 2013 at 05:54:33PM +0200, Arnd Bergmann wrote:
> The exported interface for device drivers is dma_request_slave_channel,
> not of_dma_request_slave_channel. The former does not depend on device
> tree but also works with ACPI and other interfaces providing an
> abstraction for DMA channels.
> 
> This fixes link errors when building ALSA as a loadable module.
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>

I had already sent a similar patch [1] for that.

Shawn

[1] http://thread.gmane.org/gmane.linux.alsa.devel/107568/

> Cc: alsa-devel at alsa-project.org
> Cc: Lars-Peter Clausen <lars at metafoo.de>
> Cc: Shawn Guo <shawn.guo at linaro.org>
> Cc: Mark Brown <broonie at opensource.wolfsonmicro.com>
> ---
>  sound/soc/soc-generic-dmaengine-pcm.c | 9 +++++----
>  1 file changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/sound/soc/soc-generic-dmaengine-pcm.c b/sound/soc/soc-generic-dmaengine-pcm.c
> index 5fd5ed4..8ee9859 100644
> --- a/sound/soc/soc-generic-dmaengine-pcm.c
> +++ b/sound/soc/soc-generic-dmaengine-pcm.c
> @@ -219,19 +219,20 @@ static const char * const dmaengine_pcm_dma_channel_names[] = {
>  };
>  
>  static void dmaengine_pcm_request_chan_of(struct dmaengine_pcm *pcm,
> -	struct device_node *of_node)
> +	struct device *dev)
>  {
>  	unsigned int i;
> +	struct device_node *of_node = dev->of_node;
>  
>  	if ((pcm->flags & SND_DMAENGINE_PCM_FLAG_NO_DT) || !of_node)
>  		return;
>  
>  	if (pcm->flags & SND_DMAENGINE_PCM_FLAG_HALF_DUPLEX) {
> -		pcm->chan[0] = of_dma_request_slave_channel(of_node, "tx_rx");
> +		pcm->chan[0] = dma_request_slave_channel(dev, "tx_rx");
>  		pcm->chan[1] = pcm->chan[0];
>  	} else {
>  		for (i = SNDRV_PCM_STREAM_PLAYBACK; i <= SNDRV_PCM_STREAM_CAPTURE; i++) {
> -			pcm->chan[i] = of_dma_request_slave_channel(of_node,
> +			pcm->chan[i] = dma_request_slave_channel(dev,
>  					dmaengine_pcm_dma_channel_names[i]);
>  		}
>  	}
> @@ -255,7 +256,7 @@ int snd_dmaengine_pcm_register(struct device *dev,
>  	pcm->config = config;
>  	pcm->flags = flags;
>  
> -	dmaengine_pcm_request_chan_of(pcm, dev->of_node);
> +	dmaengine_pcm_request_chan_of(pcm, dev);
>  
>  	if (flags & SND_DMAENGINE_PCM_FLAG_NO_RESIDUE)
>  		return snd_soc_add_platform(dev, &pcm->platform,
> -- 
> 1.8.1.2
> 



From festevam at gmail.com  Tue Apr 23 22:39:13 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Tue, 23 Apr 2013 23:39:13 -0300
Subject: [PATCH V4] ARM: i.MX5: Allow DT clock providers
In-Reply-To: <20130423122007.GE27475@S2101-09.ap.freescale.net>
References: <20130423091633.22088.58225.stgit@localhost>
 <20130423122007.GE27475@S2101-09.ap.freescale.net>
Message-ID: <CAOMZO5CDPwwA2LhugUBxABz9dZXgLG7F3_osMDiiPO+5odzvsg@mail.gmail.com>

On Tue, Apr 23, 2013 at 9:20 AM, Shawn Guo <shawn.guo at linaro.org> wrote:

> Applied with a small fixup below.

Into which branch, please? I could not find it in your tree.

I will submit a series that depend on this one.


From festevam at gmail.com  Tue Apr 23 22:48:31 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Tue, 23 Apr 2013 23:48:31 -0300
Subject: [RFC][PATCH] video: imx: Select VIDEOMODE_HELPERS
In-Reply-To: <1366702862.4365.2.camel@pizza.hi.pengutronix.de>
References: <1366666110-9585-1-git-send-email-marex@denx.de>
 <CAOMZO5Av8RyptoxAQ13Psxjjd4nhHVbEJoVm6SqyLr55bPmSng@mail.gmail.com>
 <201304230157.47992.marex@denx.de>
 <1366702862.4365.2.camel@pizza.hi.pengutronix.de>
Message-ID: <CAOMZO5DtupVZv0iUtEptEoi2QJzddiwjq=vw9iZyBQhpcvVwHw@mail.gmail.com>

Hi Philipp,

On Tue, Apr 23, 2013 at 4:41 AM, Philipp Zabel <p.zabel at pengutronix.de> wrote:

> OF_VIDEOMODE is the correct one. The implementation of
> of_get_drm_display_mode in drivers/gpu/drm/drm_modes.c depends on it.

The symbol OF_VIDEOMODE has been deprecated.

Regards,

Fabio Estevam


From vapier at gentoo.org  Tue Apr 23 22:51:46 2013
From: vapier at gentoo.org (Mike Frysinger)
Date: Tue, 23 Apr 2013 22:51:46 -0400
Subject: [PATCH] ARM: footbridge: fix overlapping PCI mappings
In-Reply-To: <201304200203.04719.vapier@gentoo.org>
References: <201304200203.04719.vapier@gentoo.org>
Message-ID: <1366771906-16640-1-git-send-email-vapier@gentoo.org>

Commit 8ef6e6201b26cb9fde79c1baa08145af6aca2815 (ARM: footbridge: use
fixed PCI i/o mapping) broke booting on my netwinder.  Before that,
everything boots fine.  Since then, it crashes on boot.

With earlyprintk, I see it BUG-ing like so:
kernel BUG at lib/ioremap.c:27!
Internal error: Oops - BUG: 0 [#1] ARM
...
[<c0139b54>] (ioremap_page_range+0x128/0x154) from [<c02e6a6c>] (dc21285_setup+0xd0/0x114)
[<c02e6a6c>] (dc21285_setup+0xd0/0x114) from [<c02e4874>] (pci_common_init+0xa0/0x298)
[<c02e4874>] (pci_common_init+0xa0/0x298) from [<c02e793c>] (netwinder_pci_init+0xc/0x18)
[<c02e793c>] (netwinder_pci_init+0xc/0x18) from [<c02e27d0>] (do_one_initcall+0xb4/0x180)
...

Russell points out it's because of overlapping PCI mappings that was
added with the aforementioned commit.  Rob thought the code would re-use
the static mapping, but that turns out to not be the case and instead
hits the BUG further down.

After deleting this hunk as suggested by Russel, the system boots up fine
again and all my PCI devices work (IDE, ethernet, the DC21285).

Signed-off-by: Mike Frysinger <vapier at gentoo.org>
---
 arch/arm/mach-footbridge/dc21285.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/arm/mach-footbridge/dc21285.c b/arch/arm/mach-footbridge/dc21285.c
index a7cd2cf..3490a24 100644
--- a/arch/arm/mach-footbridge/dc21285.c
+++ b/arch/arm/mach-footbridge/dc21285.c
@@ -276,8 +276,6 @@ int __init dc21285_setup(int nr, struct pci_sys_data *sys)
 
 	sys->mem_offset  = DC21285_PCI_MEM;
 
-	pci_ioremap_io(0, DC21285_PCI_IO);
-
 	pci_add_resource_offset(&sys->resources, &res[0], sys->mem_offset);
 	pci_add_resource_offset(&sys->resources, &res[1], sys->mem_offset);
 
-- 
1.8.2.1



From josephl at nvidia.com  Tue Apr 23 22:55:18 2013
From: josephl at nvidia.com (Joseph Lo)
Date: Wed, 24 Apr 2013 10:55:18 +0800
Subject: [PATCH 06/21] ARM: tegra: call cpu_do_idle from C code
In-Reply-To: <1366734653-488286-7-git-send-email-arnd@arndb.de>
References: <1366734653-488286-1-git-send-email-arnd@arndb.de>
 <1366734653-488286-7-git-send-email-arnd@arndb.de>
Message-ID: <1366772118.18275.2.camel@jlo-ubuntu-64.nvidia.com>

On Wed, 2013-04-24 at 00:30 +0800, Arnd Bergmann wrote:
> When building a kernel for multiple CPU architecture levels,
> cpu_do_idle() is a macro for an indirect function call, which
> cannot be called from assembly code as Tegra does.
> 
> Adding a trivial C wrapper for this function lets us build
> a tegra kernel with ARMv6 support enabled.
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Cc: Joseph Lo <josephl at nvidia.com>
> Cc: Stephen Warren <swarren at nvidia.com>
> ---

Hi Arnd,

Thanks for fixing.

Tested-by: Joseph Lo <josephl at nvidia.com>

Joseph



From josephl at nvidia.com  Tue Apr 23 22:56:35 2013
From: josephl at nvidia.com (Joseph Lo)
Date: Wed, 24 Apr 2013 10:56:35 +0800
Subject: [PATCH 07/21] ARM: tegra: unify tegra_idle_device definitions
In-Reply-To: <5177055D.1060307@linaro.org>
References: <1366734653-488286-1-git-send-email-arnd@arndb.de>
 <1366734653-488286-8-git-send-email-arnd@arndb.de>
 <5176BD29.1000405@linaro.org> <201304232057.37055.arnd@arndb.de>
 <5177055D.1060307@linaro.org>
Message-ID: <1366772195.18275.3.camel@jlo-ubuntu-64.nvidia.com>

On Wed, 2013-04-24 at 06:04 +0800, Daniel Lezcano wrote:
> On 04/23/2013 08:57 PM, Arnd Bergmann wrote:
> > On Tuesday 23 April 2013, Daniel Lezcano wrote:
> >> the patch sounds good but I think the side effect of the consolidation
> >> patchset [1] fixed that.
> >>
> >> You can find these fixes in Rafael's tree:
> >>
> >> https://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/commit/?h=linux-next&amp;id=4c637b2175a0dc65d533494225525c6c82d73293
> >>
> >> https://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/commit/?h=linux-next&amp;id=e158f9da6974cc11bfab2246a9b10021af0e0d8a
> >>
> >> https://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/commit/?h=linux-next&amp;id=c5106c9dea9a6022ab84c6cb1d4a0b19fc5af0e2
> >>
> >> https://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/commit/?h=linux-next&amp;id=f040c26ffaa5e56f2bca427c719c9601a02e70e5
> >>
> >> [1] http://www.spinics.net/lists/arm-kernel/msg239811.html
> >>
> > 
> > Ah. Is that not in linux-next? I created the patch today based on the latest
> > linux-next from today (Tuesday).
> 
> Ah, ok. Actually the patches were taken by Rafael right today. So it is
> possible the changes were not reflected in linux-next yet.
> 
Hi Arnd and Daniel,

Thanks for taking care this.:)

Joseph



From viresh.kumar at linaro.org  Tue Apr 23 23:20:27 2013
From: viresh.kumar at linaro.org (Viresh Kumar)
Date: Wed, 24 Apr 2013 08:50:27 +0530
Subject: [PATCH 13/21] misc: mark spear13xx-pcie-gadget as broken
In-Reply-To: <1366734653-488286-14-git-send-email-arnd@arndb.de>
References: <1366734653-488286-1-git-send-email-arnd@arndb.de>
 <1366734653-488286-14-git-send-email-arnd@arndb.de>
Message-ID: <CAOh2x=nEqqnPjmSVOMTx1oKvCPmZaGDUAb6sOOmMhJb-XemBCw@mail.gmail.com>

On Tue, Apr 23, 2013 at 10:00 PM, Arnd Bergmann <arnd at arndb.de> wrote:
> This driver was merged in 2.6.38 but never actually compiled because
> it depends on the <mach/pcie.h> header that has not made it into the
> kernel. Starting with Linux-3.10, this results in "allyesconfig"
> build errors, since spear13xx can now be enabled with the default
> "multiplatform" platform on ARM. Let's mark it as broken for now.
> If it doesn't get fixed, we can drop it completely.
>
> Cc: Pratyush Anand <pratyush.anand at st.com>
> Cc: Randy Dunlap <randy.dunlap at oracle.com>
> Cc: Jesse Barnes <jbarnes at virtuousgeek.org>
> Cc: Viresh Kumar <viresh.kumar at st.com>
> Cc: Shiraz Hashim <shiraz.hashim at st.com>
> Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> ---
>  drivers/misc/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Acked-by: Viresh Kumar <viresh.kumar at linaro.org>

@Pratyush: Please see if we can get it fixed soon.


From olof at lixom.net  Tue Apr 23 23:34:32 2013
From: olof at lixom.net (Olof Johansson)
Date: Tue, 23 Apr 2013 20:34:32 -0700
Subject: Exynos regressions w.r.t. config and debuggability due to
 multiplatform
Message-ID: <CAOesGMgRsa-AvbEZCc1=_ovaZMaG0S-CDok2MDp_zu5yderAYw@mail.gmail.com>

Arnd,

I think we should hold off on multiplatform for exynos until it works
better, i.e. 3.11.

First, the defconfig we have in our out-of-tree build system now
builds a broken kernel since it doesn't set ARCH_EXYNOS_SINGLE. As a
result, exynos gets turned off. It's quite awkward to switch between
pre- and post-multiplatform configs, which makes bisecting and other
error finding hard. I'm sure this will hit other downstream users too.

What's even more frustrating is that I can't turn on DEBUG_LL, since
serial drivers depend on PLAT_SAMSUNG, and that is no longer set.

Seems like we'll have a really broken 3.10 if we merge what we have
now. More bake time is definitely needed. :(


-Olof


From gang.chen at asianux.com  Tue Apr 23 23:44:29 2013
From: gang.chen at asianux.com (Chen Gang)
Date: Wed, 24 Apr 2013 11:44:29 +0800
Subject: [PATCH] arm64: compiling issue, need add include/asm/vga.h file
Message-ID: <5177551D.8090007@asianux.com>


For compiling with allmodconfig, need vga.h file, so copy it from arm32.

The related information:
  aarch64-linux-gnu-gcc -Wp,-MD,drivers/gpu/drm/.drm_irq.o.d  -nostdinc -isystem /usr/bin/../lib/gcc/aarch64-linux-gnu/4.7.3/include -I/root/linux-next/arch/arm64/include -Iarch/arm64/include/generated  -Iinclude -I/root/linux-next/arch/arm64/include/uapi -Iarch/arm64/include/generated/uapi -I/root/linux-next/include/uapi -Iinclude/generated/uapi -include /root/linux-next/include/linux/kconfig.h -D__KERNEL__ -mlittle-endian -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Wno-format-security -fno-delete-null-pointer-checks -Os -mgeneral-regs-only -fno-reorder-blocks -fno-ipa-cp-clone -fno-partial-inlining -Wframe-larger-than=2048 -fno-stack-protector -Wno-unused-but-set-variable -fno-omit-frame-pointer -fno-optimize-sibling-calls -g -femit-struct-debug-baseonly -fno-var-tracking -fno-inline-functions-called-once -Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow -fconserve-stack -DCC_HAV
 E_ASM_GOT
O -Iinclude/drm -W   -DMODULE  -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(drm_irq)"  -D"KBUILD_MODNAME=KBUILD_STR(drm)" -c -o drivers/gpu/drm/.tmp_drm_irq.o drivers/gpu/drm/drm_irq.c

The related error:
include/video/vga.h: At top level:
include/video/vga.h:22:21: fatal error: asm/vga.h: No such file or directory
compilation terminated.
make[3]: *** [drivers/gpu/drm/drm_irq.o] Error 1
make[2]: *** [drivers/gpu/drm] Error 2
make[1]: *** [drivers/gpu] Error 2
make: *** [drivers] Error 2


Signed-off-by: root <root at dhcp122.asianux.net>
---
 arch/arm64/include/asm/vga.h | 13 +++++++++++++
 1 file changed, 13 insertions(+)
 create mode 100644 arch/arm64/include/asm/vga.h

diff --git a/arch/arm64/include/asm/vga.h b/arch/arm64/include/asm/vga.h
new file mode 100644
index 0000000..91f4021
--- /dev/null
+++ b/arch/arm64/include/asm/vga.h
@@ -0,0 +1,13 @@
+#ifndef ASMARM_VGA_H
+#define ASMARM_VGA_H
+
+#include <linux/io.h>
+
+extern unsigned long vga_base;
+
+#define VGA_MAP_MEM(x,s)	(vga_base + (x))
+
+#define vga_readb(x)	(*((volatile unsigned char *)x))
+#define vga_writeb(x,y)	(*((volatile unsigned char *)y) = (x))
+
+#endif
-- 
1.7.11.7


From nicolas.pitre at linaro.org  Wed Apr 24 00:11:26 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Wed, 24 Apr 2013 00:11:26 -0400 (EDT)
Subject: [PATCH v4 00/15] multi-cluster power management
In-Reply-To: <20130423224441.GZ14496@n2100.arm.linux.org.uk>
References: <1360041732-17936-1-git-send-email-nicolas.pitre@linaro.org>
 <20130423200429.GF5316@n2100.arm.linux.org.uk>
 <alpine.LFD.2.03.1304231657150.17375@syhkavp.arg>
 <20130423214610.GY14496@n2100.arm.linux.org.uk>
 <alpine.LFD.2.03.1304231755370.17375@syhkavp.arg>
 <20130423224441.GZ14496@n2100.arm.linux.org.uk>
Message-ID: <alpine.LFD.2.03.1304232327120.17375@syhkavp.arg>

On Tue, 23 Apr 2013, Russell King - ARM Linux wrote:

> On Tue, Apr 23, 2013 at 05:56:03PM -0400, Nicolas Pitre wrote:
> > On Tue, 23 Apr 2013, Russell King - ARM Linux wrote:
> > 
> > > On Tue, Apr 23, 2013 at 05:03:06PM -0400, Nicolas Pitre wrote:
> > > > On Tue, 23 Apr 2013, Russell King - ARM Linux wrote:
> > > > 
> > > > > What I suggest for the time being is to provide new inline function(s)
> > > > > in arch/arm/include/cacheflush.h which are purposed for your application,
> > > > > document them in that file, and call the implementation you're currently
> > > > > using.  That means if we do have to change it in the future (for example,
> > > > > we don't need to do anything in the dcache flushing stuff) we don't have
> > > > > to hunt through all the code to find _your_ different use of that function
> > > > > and fix it - we can just fix it in one place and we have the reference
> > > > > there for what your code expects.
> > > > 
> > > > What about the patch below?  Once you tell me it is fine to you I'll 
> > > > adapt the MCPM series to it.
> > > 
> > > Yes, that looks like a saner solution.  Thanks.
> > 
> > May I add your ACK to the patch?
> 
> Yes, sure.
> 
> Acked-by: Russell King <rmk+kernel at arm.linux.org.uk>

Thanks.  I've adapted the series to this, and mcpm_set_entry_vector() 
now looks like this:

+extern unsigned long mcpm_entry_vectors[MAX_NR_CLUSTERS][MAX_CPUS_PER_CLUSTER];
+
+void mcpm_set_entry_vector(unsigned cpu, unsigned cluster, void *ptr)
+{
+	unsigned long val = ptr ? virt_to_phys(ptr) : 0;
+	mcpm_entry_vectors[cluster][cpu] = val;
+	sync_cache_w(&mcpm_entry_vectors[cluster][cpu]);
+}

Similarly for the CCI driver:

+	/*
+	 * Multi-cluster systems may need this data when non-coherent, during
+	 * cluster power-up/power-down. Make sure it reaches main memory:
+	 */
+	sync_cache_w(info);
+	sync_cache_w(&info);

This is also much prettier.

Assorted small changes for comments that followed the v4 post have been 
integrated as well.  I don't think they justify a repost of the whole 
thing though.  They are:

- Replace custom cache sync helpers with the sync_cache_*() ones from 
  cacheflush.h.

- Remove volatile annotations since explicit cache ops act as memory 
  barriers now.

- Rename mcpm_entry.h to mcpm.h since this is not solely about entry but
  more general.

- Export the __CACHE_WRITEBACK_* constants via asm_offsets.h since 
  they're needed by assembly code.

- Add some more comments and clarify some existing ones.

I managed to retest this on RTSM after fighting with the license system.

The latest MCPM patches are available here:

  git://git.linaro.org/people/nico/linux mcpm

Diffstat:

 Documentation/arm/cluster-pm-race-avoidance.txt | 498 ++++++++++++++++++
 Documentation/arm/vlocks.txt                    | 211 ++++++++
 arch/arm/Kconfig                                |   8 +
 arch/arm/common/Makefile                        |   1 +
 arch/arm/common/mcpm_entry.c                    | 263 +++++++++
 arch/arm/common/mcpm_head.S                     | 219 ++++++++
 arch/arm/common/mcpm_platsmp.c                  |  92 ++++
 arch/arm/common/vlock.S                         | 108 ++++
 arch/arm/common/vlock.h                         |  29 +
 arch/arm/include/asm/cacheflush.h               |  75 +++
 arch/arm/include/asm/mcpm.h                     | 209 ++++++++
 arch/arm/kernel/asm-offsets.c                   |   4 +
 12 files changed, 1717 insertions(+)

The corresponding DCSCB support for RTSM is here:

  git://git.linaro.org/people/nico/linux mcpm+dcscb

although that part is probably more suitable for ARM-SOC.

Do you want those patches to be posted again, or should I send a new 
pull request?


Nicolas


From gang.chen at asianux.com  Wed Apr 24 00:12:35 2013
From: gang.chen at asianux.com (Chen Gang)
Date: Wed, 24 Apr 2013 12:12:35 +0800
Subject: [PATCH] ARM: Kconfig: let ARM9TDMI and ARM7TDMI invisible.
In-Reply-To: <5174D4FA.70404@asianux.com>
References: <514FB202.3040807@asianux.com> <515BFA8D.2000204@asianux.com>
 <20130403101018.GE11040@mudshark.cambridge.arm.com>
 <515C047A.9010906@asianux.com> <516E6A8E.3000001@asianux.com>
 <20130417100243.GV14496@n2100.arm.linux.org.uk> <5174D4FA.70404@asianux.com>
Message-ID: <51775BB3.6000607@asianux.com>


If CONFIG_MMU is disabled, it will let ARM9TDMI and ARM7TDMI visible,
but in fact, only AT91X40 need ARM7TDMI, so not need let them visible.

Signed-off-by: Chen Gang <gang.chen at asianux.com>
---
 arch/arm/mach-at91/Kconfig.non_dt |    1 +
 arch/arm/mm/Kconfig               |    4 ++--
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-at91/Kconfig.non_dt
b/arch/arm/mach-at91/Kconfig.non_dt
index 6c24985..dc972e1 100644
--- a/arch/arm/mach-at91/Kconfig.non_dt
+++ b/arch/arm/mach-at91/Kconfig.non_dt
@@ -47,6 +47,7 @@ config ARCH_AT91X40
 	select ARCH_USES_GETTIMEOFFSET
 	select MULTI_IRQ_HANDLER
 	select SPARSE_IRQ
+	select CPU_ARM7TDMI

 endchoice

diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
index 9e8101e..3397d05 100644
--- a/arch/arm/mm/Kconfig
+++ b/arch/arm/mm/Kconfig
@@ -6,7 +6,7 @@ comment "Processor Type"

 # ARM7TDMI
 config CPU_ARM7TDMI
-	bool "Support ARM7TDMI processor"
+	bool
 	depends on !MMU
 	select CPU_32v4T
 	select CPU_ABRT_LV4T
@@ -56,7 +56,7 @@ config CPU_ARM740T

 # ARM9TDMI
 config CPU_ARM9TDMI
-	bool "Support ARM9TDMI processor"
+	bool
 	depends on !MMU
 	select CPU_32v4T
 	select CPU_ABRT_NOMMU
-- 
1.7.7.6


From gang.chen at asianux.com  Wed Apr 24 00:16:10 2013
From: gang.chen at asianux.com (Chen Gang)
Date: Wed, 24 Apr 2013 12:16:10 +0800
Subject: [PATCH] ARM: Kconfig: let ARM9TDMI and ARM7TDMI invisible.
In-Reply-To: <51775BB3.6000607@asianux.com>
References: <514FB202.3040807@asianux.com> <515BFA8D.2000204@asianux.com>
 <20130403101018.GE11040@mudshark.cambridge.arm.com>
 <515C047A.9010906@asianux.com> <516E6A8E.3000001@asianux.com>
 <20130417100243.GV14496@n2100.arm.linux.org.uk> <5174D4FA.70404@asianux.com>
 <51775BB3.6000607@asianux.com>
Message-ID: <51775C8A.2090701@asianux.com>


Oh, sorry, I forgot to disable word wrap, I should send patch v2 again.

For this patch itself, I just copy it from Russell's and Arnd's, and
want it to be applied.


On 2013?04?24? 12:12, Chen Gang wrote:
> 
> If CONFIG_MMU is disabled, it will let ARM9TDMI and ARM7TDMI visible,
> but in fact, only AT91X40 need ARM7TDMI, so not need let them visible.
> 
> Signed-off-by: Chen Gang <gang.chen at asianux.com>
> ---
>  arch/arm/mach-at91/Kconfig.non_dt |    1 +
>  arch/arm/mm/Kconfig               |    4 ++--
>  2 files changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/mach-at91/Kconfig.non_dt
> b/arch/arm/mach-at91/Kconfig.non_dt
> index 6c24985..dc972e1 100644
> --- a/arch/arm/mach-at91/Kconfig.non_dt
> +++ b/arch/arm/mach-at91/Kconfig.non_dt
> @@ -47,6 +47,7 @@ config ARCH_AT91X40
>  	select ARCH_USES_GETTIMEOFFSET
>  	select MULTI_IRQ_HANDLER
>  	select SPARSE_IRQ
> +	select CPU_ARM7TDMI
> 
>  endchoice
> 
> diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
> index 9e8101e..3397d05 100644
> --- a/arch/arm/mm/Kconfig
> +++ b/arch/arm/mm/Kconfig
> @@ -6,7 +6,7 @@ comment "Processor Type"
> 
>  # ARM7TDMI
>  config CPU_ARM7TDMI
> -	bool "Support ARM7TDMI processor"
> +	bool
>  	depends on !MMU
>  	select CPU_32v4T
>  	select CPU_ABRT_LV4T
> @@ -56,7 +56,7 @@ config CPU_ARM740T
> 
>  # ARM9TDMI
>  config CPU_ARM9TDMI
> -	bool "Support ARM9TDMI processor"
> +	bool
>  	depends on !MMU
>  	select CPU_32v4T
>  	select CPU_ABRT_NOMMU
> 


-- 
Chen Gang

Asianux Corporation


From gang.chen at asianux.com  Wed Apr 24 00:20:24 2013
From: gang.chen at asianux.com (Chen Gang)
Date: Wed, 24 Apr 2013 12:20:24 +0800
Subject: [PATCH v2] ARM: Kconfig: let ARM9TDMI and ARM7TDMI invisible.
In-Reply-To: <51775BB3.6000607@asianux.com>
References: <51775BB3.6000607@asianux.com>
Message-ID: <51775D88.2000406@asianux.com>


If CONFIG_MMU is disabled, it will let ARM9TDMI and ARM7TDMI visible,
but in fact, only AT91X40 need ARM7TDMI, so need not let them visible.

Signed-off-by: Chen Gang <gang.chen at asianux.com>
---
 arch/arm/mach-at91/Kconfig.non_dt |    1 +
 arch/arm/mm/Kconfig               |    4 ++--
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-at91/Kconfig.non_dt b/arch/arm/mach-at91/Kconfig.non_dt
index 6c24985..dc972e1 100644
--- a/arch/arm/mach-at91/Kconfig.non_dt
+++ b/arch/arm/mach-at91/Kconfig.non_dt
@@ -47,6 +47,7 @@ config ARCH_AT91X40
 	select ARCH_USES_GETTIMEOFFSET
 	select MULTI_IRQ_HANDLER
 	select SPARSE_IRQ
+	select CPU_ARM7TDMI
 
 endchoice
 
diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
index 9e8101e..3397d05 100644
--- a/arch/arm/mm/Kconfig
+++ b/arch/arm/mm/Kconfig
@@ -6,7 +6,7 @@ comment "Processor Type"
 
 # ARM7TDMI
 config CPU_ARM7TDMI
-	bool "Support ARM7TDMI processor"
+	bool
 	depends on !MMU
 	select CPU_32v4T
 	select CPU_ABRT_LV4T
@@ -56,7 +56,7 @@ config CPU_ARM740T
 
 # ARM9TDMI
 config CPU_ARM9TDMI
-	bool "Support ARM9TDMI processor"
+	bool
 	depends on !MMU
 	select CPU_32v4T
 	select CPU_ABRT_NOMMU
-- 
1.7.7.6



From jaswinder.singh at linaro.org  Wed Apr 24 00:39:17 2013
From: jaswinder.singh at linaro.org (Jassi Brar)
Date: Wed, 24 Apr 2013 10:09:17 +0530
Subject: [PATCHv3 00/14] drivers: mailbox: framework creation
In-Reply-To: <37C860A02101E749A747FA2D3C1E3C504A63B4@DLEE11.ent.ti.com>
References: <1363145021-14339-1-git-send-email-s-anna@ti.com>
 <CABb+yY0RYkVeo2Sb4WsDJY0jf17488FEz0d2CB994eQaSOEsVg@mail.gmail.com>
 <37C860A02101E749A747FA2D3C1E3C504A5DF7@DLEE11.ent.ti.com>
 <CABb+yY1x4x_A+QtGG9ohsLPgs8c3nEVnd_ExJBGOOR8=6YLPFA@mail.gmail.com>
 <37C860A02101E749A747FA2D3C1E3C504A63B4@DLEE11.ent.ti.com>
Message-ID: <CAJe_ZhehnniZd730jjiOLrHozq8TOJZgFYLqUe4KqgBiQEu8PA@mail.gmail.com>

Hi Suman,

[please limit replies to not more than 80 columns per line]

On 24 April 2013 00:50, Anna, Suman <s-anna at ti.com> wrote:

>>
>> Documentation wise, we'd need documentation for what we finally wanna have,
>> not the current implementation.
>>
>> There are also some desired features in a good API:-
>>
>> a) The API should be simple and efficient, i.e, submission of requests by clients
>> and notifications of data received by the API should be possible from atomic
>> context - most of the IPC is going to be about exchanging 'commands'. The API
>> shouldn't add to the latencies.
>
> I think we will have need for both types. It really depends on the purpose of the IPC h/w - some would be simple messaging and may not need the atomic constraints. Sure enough, atomic context is the stricter one, so we can add that. I don't see any users of it currently though.
>
IMHO the API authors should take the other POV :  if _majority_ of
clients _require_ non-atomic context, only then the API should support
non-atomic version of the calls too. Otherwise let the minority of
drivers schedule their sleepable tasks from the API's atomic
callbacks.
 The non-atomic API falls flat should just a single client comes with
very low latency requirements.

>>  For example, API should assume the IPC controller can detect and report when
>> the remote asserts Ready-To-Receive (RTR). This is when the API callbacks
>> .tx_done(mssg) on the client. If some h/w doesn't have RTR assertion interrupt,
>> the API should provide optional feature to poll the controller periodically.
>
> Some of these are already part of the mailbox ops. FWIW, I don?t see a need for a .tx_done callback, as this state can really be maintained by the driver implementation itself. The mailbox_msg_send can return an error appropriately based on whether the h/w is ready or not. The current code has the support for queuing up a certain number of messages in case the h/w is busy, but I am planning to change this to a device-based property so that they can choose if it needs that support or not.
>
Not really. The TI's api does buffer requests from a client but it
does not tell the client when the message is actually sent to the
remote over the h/w channel.

 Consider this example for better understanding, I must send a
particular packet to the remote before I could, say, shutdown
properly. The client calls mailbox_msg_send which queues the packet
because the h/w was busy. Since the api does not inform the client
about packet transmission, the client does not know when to shutdown
(the packet may have been sent instantly or it may lie on the queue
for a long time).
 How do you fix this without tx_done callback method?


>>
>> (d) The 'struct mailbox_msg' should be just an opaque void* - the client/protocol
>> driver typecasts to void* the IPC controller specific message structure. API
>> shouldn't aim the impossible of providing a generic message format.
>
> The size parameter would still be needed. Depending on the h/w, it can be just an u32 or a series of bytes, and even in the latter case, it is not guaranteed that all messages transmitted will occupy the entire h/w shared memory data packet. I can see the current header field getting absorbed into the opaque void * structure for the ST mailbox driver. The size and ptr together provide a very generic message format.
>
I am not sure about it. The API has no purpose for the .size (it's
between the controller and the client driver).
Controllers that could send variable length packets could define the
packets format for clients as
 struct foo_packet {
         int size;
         .......
 }
and exchange as typecasted to void* via the API. And this is just one
way of doing it.
The point being, the API should only pass pointer to packet info
between controller and client drivers.

>>
>> As you see there would be not much of the present left eventually. So I wonder
>> if should sculpt a new api out of TI's or start from scratch?
>> One of my controllers is similar to 'pl320' (which you left out converting to the
>> API). I am in process of implementing all this assuming it is OK to keep a controller
>> out of this API :)  So maybe we can collaborate on a new implementation from
>> scratch.
>
> This series missed the 3.9 merge window, and is currently slated for getting merged into 3.10. The PL320 made it into 3.9 itself (I wasn't aware of it until I saw it in mainline) and created the drivers/mailbox folder.  I would think it would be relatively straight-forward to adopt it to the mailbox API, as it has only 3 API. We should be doing incremental changes on top of this series, as most of the base API would still be the same. The current series is helping out with couple of efforts, the breaking up of the PRCMU code and on the multiplatform support for OMAP with mailbox enabled. We can definitely collaborate on the improvements. Andy Green would also be interested, as he is also looking into adopting the mailbox API.
>
I don't think it should into 3.10 just because it missed the 3.9
window, when its quality is doubted.
I am going to have to live with IPC controller code for sometime now,
so I care that I build upon a sound API. And I am more than happy to
help on a proper implementation.

Regards,
Jassi


From pekon at ti.com  Wed Apr 24 01:34:21 2013
From: pekon at ti.com (Gupta, Pekon)
Date: Wed, 24 Apr 2013 05:34:21 +0000
Subject: [PATCH 21/21] mtd: omap2: allow bulding as a module
In-Reply-To: <20130423180320.GJ10155@atomide.com>
References: <1366734653-488286-1-git-send-email-arnd@arndb.de>
 <1366734653-488286-22-git-send-email-arnd@arndb.de>
 <20130423180320.GJ10155@atomide.com>
Message-ID: <20980858CB6D3A4BAE95CA194937D5E73E9BCFAE@DBDE04.ent.ti.com>

> * Arnd Bergmann <arnd at arndb.de> [130423 09:37]:
> > The omap2 nand device driver calls into the the elm code, which can
> > be a loadable module, and in that case it cannot be built-in itself.
> > I can see no reason why the omap2 driver cannot also be a module,
> > so let's make the option "tristate" in Kconfig to fix this allmodconfig
> > build error:
> >
> > ERROR: "elm_config" [drivers/mtd/nand/omap2.ko] undefined!
> > ERROR: "elm_decode_bch_error_page" [drivers/mtd/nand/omap2.ko]
> undefined!
> >
[Pekon]: 
ELM module is required in for Hardware based ECC correction for 
NAND devices. And this driver has a very small foot-print.

The only cases this drives would _not_ be used are:
(a) Using S/W based ECC scheme, which have vey high CPU utilization
(b) Using single bit ECC scheme, which are becoming obsolete due to
 increasing NAND densities.
For most of the cases ELM module will be used with nand-driver. So
there should be no harm in having this module as built-in, if not used
in 10% of the use-cases.

Thus I think it's better to keep this module tied to GPMC module, 
rather than independent control via KConfig.
And user should just selects which ECC scheme he would like to
use via DT, without worrying about KConfig options.

I'm working in cleaning up omap2-nand driver to remove some 
redundancies. So would like to know your feedback on same..


with regards, pekon


From linux at prisktech.co.nz  Wed Apr 24 01:38:19 2013
From: linux at prisktech.co.nz (Tony Prisk)
Date: Wed, 24 Apr 2013 17:38:19 +1200
Subject: [PATCH 0/3] dts: v8500: Cleanups for 3.10
Message-ID: <1366781902-13025-1-git-send-email-linux@prisktech.co.nz>

Arnd, Olof,

This is probably a bit late for 3.10 now but its just a bunch of cleanups for
the arch-vt8500 devicetree SoC and board files, and the addition of a new
dts for the VIA APC8750.

Regards
Tony P

Tony Prisk (3):
  dts: vt8500: Fix invalid/missing cpu nodes for soc files.
  dts: vt8500: Add devicetree support for WM8750 SoC and APC8750 board
  dts: vt8500: Update serial nodes and disable by default in SoC files

 arch/arm/boot/dts/Makefile           |    1 +
 arch/arm/boot/dts/vt8500-bv07.dts    |    4 +
 arch/arm/boot/dts/vt8500.dtsi        |   29 ++-
 arch/arm/boot/dts/wm8505-ref.dts     |    4 +
 arch/arm/boot/dts/wm8505.dtsi        |   35 +++-
 arch/arm/boot/dts/wm8650-mid.dts     |    4 +
 arch/arm/boot/dts/wm8650.dtsi        |   21 +-
 arch/arm/boot/dts/wm8750-apc8750.dts |   30 +++
 arch/arm/boot/dts/wm8750.dtsi        |  355 ++++++++++++++++++++++++++++++++++
 arch/arm/boot/dts/wm8850-w70v2.dts   |    4 +
 arch/arm/boot/dts/wm8850.dtsi        |   23 ++-
 11 files changed, 492 insertions(+), 18 deletions(-)
 create mode 100644 arch/arm/boot/dts/wm8750-apc8750.dts
 create mode 100644 arch/arm/boot/dts/wm8750.dtsi

-- 
1.7.9.5



From linux at prisktech.co.nz  Wed Apr 24 01:38:20 2013
From: linux at prisktech.co.nz (Tony Prisk)
Date: Wed, 24 Apr 2013 17:38:20 +1200
Subject: [PATCH 1/3] dts: vt8500: Fix invalid/missing cpu nodes for soc files.
In-Reply-To: <1366781902-13025-1-git-send-email-linux@prisktech.co.nz>
References: <1366781902-13025-1-git-send-email-linux@prisktech.co.nz>
Message-ID: <1366781902-13025-2-git-send-email-linux@prisktech.co.nz>

vt8500, wm8650 and wm8850 have no cpu node specified.
wm8505 has a cpu node which contains an invalid compatible string, and
is missing the other required properties.

Signed-off-by: Tony Prisk <linux at prisktech.co.nz>
---
 arch/arm/boot/dts/vt8500.dtsi |   10 ++++++++++
 arch/arm/boot/dts/wm8505.dtsi |    8 ++++++--
 arch/arm/boot/dts/wm8650.dtsi |   10 ++++++++++
 arch/arm/boot/dts/wm8850.dtsi |   11 +++++++++++
 4 files changed, 37 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/vt8500.dtsi b/arch/arm/boot/dts/vt8500.dtsi
index cf31ced..e35590e 100644
--- a/arch/arm/boot/dts/vt8500.dtsi
+++ b/arch/arm/boot/dts/vt8500.dtsi
@@ -11,6 +11,16 @@
 / {
 	compatible = "via,vt8500";
 
+	cpus {
+		#size-cells = <0>;
+		#address-cells = <1>;
+
+		cpu {
+			device_type = "cpu";
+			compatible = "arm,arm926";
+		};
+	};
+
 	soc {
 		#address-cells = <1>;
 		#size-cells = <1>;
diff --git a/arch/arm/boot/dts/wm8505.dtsi b/arch/arm/boot/dts/wm8505.dtsi
index e74a1c0..dc21d13 100644
--- a/arch/arm/boot/dts/wm8505.dtsi
+++ b/arch/arm/boot/dts/wm8505.dtsi
@@ -12,8 +12,12 @@
 	compatible = "wm,wm8505";
 
 	cpus {
-		cpu at 0 {
-			compatible = "arm,arm926ejs";
+		#size-cells = <0>;
+		#address-cells = <1>;
+
+		cpu {
+			device_type = "cpu";
+			compatible = "arm,arm926";
 		};
 	};
 
diff --git a/arch/arm/boot/dts/wm8650.dtsi b/arch/arm/boot/dts/wm8650.dtsi
index db3c0a1..f4cd55e 100644
--- a/arch/arm/boot/dts/wm8650.dtsi
+++ b/arch/arm/boot/dts/wm8650.dtsi
@@ -11,6 +11,16 @@
 / {
 	compatible = "wm,wm8650";
 
+	cpus {
+		#size-cells = <0>;
+		#address-cells = <1>;
+
+		cpu {
+			device_type = "cpu";
+			compatible = "arm,arm926";
+		};
+	};
+
 	soc {
 		#address-cells = <1>;
 		#size-cells = <1>;
diff --git a/arch/arm/boot/dts/wm8850.dtsi b/arch/arm/boot/dts/wm8850.dtsi
index e8cbfdc..4b56aa0 100644
--- a/arch/arm/boot/dts/wm8850.dtsi
+++ b/arch/arm/boot/dts/wm8850.dtsi
@@ -11,6 +11,17 @@
 / {
 	compatible = "wm,wm8850";
 
+	cpus {
+		#size-cells = <0>;
+		#address-cells = <1>;
+
+		cpu at 0 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a9";
+			reg = <0x0>;
+		};
+	};
+
 	aliases {
 		serial0 = &uart0;
 		serial1 = &uart1;
-- 
1.7.9.5



From linux at prisktech.co.nz  Wed Apr 24 01:38:21 2013
From: linux at prisktech.co.nz (Tony Prisk)
Date: Wed, 24 Apr 2013 17:38:21 +1200
Subject: [PATCH 2/3] dts: vt8500: Add devicetree support for WM8750 SoC and
 APC8750 board
In-Reply-To: <1366781902-13025-1-git-send-email-linux@prisktech.co.nz>
References: <1366781902-13025-1-git-send-email-linux@prisktech.co.nz>
Message-ID: <1366781902-13025-3-git-send-email-linux@prisktech.co.nz>

This patch adds support for the WonderMedia WM8750 SoC and the VIA
APC8750 board.

Signed-off-by: Tony Prisk <linux at prisktech.co.nz>
---
 arch/arm/boot/dts/Makefile           |    1 +
 arch/arm/boot/dts/wm8750-apc8750.dts |   26 +++
 arch/arm/boot/dts/wm8750.dtsi        |  349 ++++++++++++++++++++++++++++++++++
 3 files changed, 376 insertions(+)
 create mode 100644 arch/arm/boot/dts/wm8750-apc8750.dts
 create mode 100644 arch/arm/boot/dts/wm8750.dtsi

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 9c62558..389536e 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -173,6 +173,7 @@ dtb-$(CONFIG_ARCH_VEXPRESS) += vexpress-v2p-ca5s.dtb \
 dtb-$(CONFIG_ARCH_VT8500) += vt8500-bv07.dtb \
 	wm8505-ref.dtb \
 	wm8650-mid.dtb \
+	wm8750-apc8750.dtb \
 	wm8850-w70v2.dtb
 dtb-$(CONFIG_ARCH_ZYNQ) += zynq-zc702.dtb
 
diff --git a/arch/arm/boot/dts/wm8750-apc8750.dts b/arch/arm/boot/dts/wm8750-apc8750.dts
new file mode 100644
index 0000000..62675eb
--- /dev/null
+++ b/arch/arm/boot/dts/wm8750-apc8750.dts
@@ -0,0 +1,26 @@
+/*
+ * wm8750-apc8750.dts
+ *  - Device tree file for VIA APC8750
+ *
+ * Copyright (C) 2012 Tony Prisk <linux at prisktech.co.nz>
+ *
+ * Licensed under GPLv2 or later
+ */
+
+/dts-v1/;
+/include/ "wm8750.dtsi"
+
+/ {
+	model = "VIA APC8750";
+};
+
+&pinctrl {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c>;
+
+	i2c: i2c {
+		wm,pins = <168 169 170 171>;
+		wm,function = <2>;	/* alt */
+		wm,pull = <2>;	/* pull-up */
+	};
+};
diff --git a/arch/arm/boot/dts/wm8750.dtsi b/arch/arm/boot/dts/wm8750.dtsi
new file mode 100644
index 0000000..81683fa
--- /dev/null
+++ b/arch/arm/boot/dts/wm8750.dtsi
@@ -0,0 +1,349 @@
+/*
+ * wm8750.dtsi - Device tree file for Wondermedia WM8750 SoC
+ *
+ * Copyright (C) 2012 Tony Prisk <linux at prisktech.co.nz>
+ *
+ * Licensed under GPLv2 or later
+ */
+
+/include/ "skeleton.dtsi"
+
+/ {
+	compatible = "wm,wm8750";
+
+	cpus {
+		#size-cells = <0>;
+		#address-cells = <1>;
+
+		cpu {
+			device_type = "cpu";
+			compatible = "arm,arm1176";
+		};
+	};
+
+	aliases {
+		serial0 = &uart0;
+		serial1 = &uart1;
+		serial2 = &uart2;
+		serial3 = &uart3;
+		serial4 = &uart4;
+		serial5 = &uart5;
+		i2c0 = &i2c_0;
+		i2c1 = &i2c_1;
+	};
+
+	soc {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		compatible = "simple-bus";
+		ranges;
+		interrupt-parent = <&intc0>;
+
+		intc0: interrupt-controller at d8140000 {
+			compatible = "via,vt8500-intc";
+			interrupt-controller;
+			reg = <0xd8140000 0x10000>;
+			#interrupt-cells = <1>;
+		};
+
+		/* Secondary IC cascaded to intc0 */
+		intc1: interrupt-controller at d8150000 {
+			compatible = "via,vt8500-intc";
+			interrupt-controller;
+			#interrupt-cells = <1>;
+			reg = <0xD8150000 0x10000>;
+			interrupts = <56 57 58 59 60 61 62 63>;
+		};
+
+		pinctrl: pinctrl at d8110000 {
+			compatible = "wm,wm8750-pinctrl";
+			reg = <0xd8110000 0x10000>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			gpio-controller;
+			#gpio-cells = <2>;
+		};
+
+		pmc at d8130000 {
+			compatible = "via,vt8500-pmc";
+			reg = <0xd8130000 0x1000>;
+
+			clocks {
+				#address-cells = <1>;
+				#size-cells = <0>;
+
+				ref24: ref24M {
+					#clock-cells = <0>;
+					compatible = "fixed-clock";
+					clock-frequency = <24000000>;
+				};
+
+				ref25: ref25M {
+					#clock-cells = <0>;
+					compatible = "fixed-clock";
+					clock-frequency = <25000000>;
+				};
+
+				plla: plla {
+					#clock-cells = <0>;
+					compatible = "wm,wm8750-pll-clock";
+					clocks = <&ref25>;
+					reg = <0x200>;
+				};
+
+				pllb: pllb {
+					#clock-cells = <0>;
+					compatible = "wm,wm8750-pll-clock";
+					clocks = <&ref25>;
+					reg = <0x204>;
+				};
+
+				pllc: pllc {
+					#clock-cells = <0>;
+					compatible = "wm,wm8750-pll-clock";
+					clocks = <&ref25>;
+					reg = <0x208>;
+				};
+
+				plld: plld {
+					#clock-cells = <0>;
+					compatible = "wm,wm8750-pll-clock";
+					clocks = <&ref25>;
+					reg = <0x20C>;
+				};
+
+				plle: plle {
+					#clock-cells = <0>;
+					compatible = "wm,wm8750-pll-clock";
+					clocks = <&ref25>;
+					reg = <0x210>;
+				};
+
+				clkarm: arm {
+					#clock-cells = <0>;
+					compatible = "via,vt8500-device-clock";
+					clocks = <&plla>;
+					divisor-reg = <0x300>;
+				};
+
+				clkahb: ahb {
+					#clock-cells = <0>;
+					compatible = "via,vt8500-device-clock";
+					clocks = <&pllb>;
+					divisor-reg = <0x304>;
+				};
+
+				clkddr: ddr {
+					#clock-cells = <0>;
+					compatible = "via,vt8500-device-clock";
+					clocks = <&plld>;
+					divisor-reg = <0x310>;
+				};
+
+				clkuart0: uart0 {
+					#clock-cells = <0>;
+					compatible = "via,vt8500-device-clock";
+					clocks = <&ref24>;
+					enable-reg = <0x254>;
+					enable-bit = <24>;
+				};
+
+				clkuart1: uart1 {
+					#clock-cells = <0>;
+					compatible = "via,vt8500-device-clock";
+					clocks = <&ref24>;
+					enable-reg = <0x254>;
+					enable-bit = <25>;
+				};
+
+                                clkuart2: uart2 {
+                                        #clock-cells = <0>;
+                                        compatible = "via,vt8500-device-clock";
+                                        clocks = <&ref24>;
+                                        enable-reg = <0x254>;
+                                        enable-bit = <26>;
+                                };
+
+                                clkuart3: uart3 {
+                                        #clock-cells = <0>;
+                                        compatible = "via,vt8500-device-clock";
+                                        clocks = <&ref24>;
+                                        enable-reg = <0x254>;
+                                        enable-bit = <27>;
+                                };
+
+                                clkuart4: uart4 {
+                                        #clock-cells = <0>;
+                                        compatible = "via,vt8500-device-clock";
+                                        clocks = <&ref24>;
+                                        enable-reg = <0x254>;
+                                        enable-bit = <28>;
+                                };
+
+                                clkuart5: uart5 {
+                                        #clock-cells = <0>;
+                                        compatible = "via,vt8500-device-clock";
+                                        clocks = <&ref24>;
+                                        enable-reg = <0x254>;
+                                        enable-bit = <29>;
+                                };
+
+				clkpwm: pwm {
+					#clock-cells = <0>;
+					compatible = "via,vt8500-device-clock";
+					clocks = <&pllb>;
+					divisor-reg = <0x350>;
+					enable-reg = <0x250>;
+					enable-bit = <17>;
+				};
+
+				clksdhc: sdhc {
+					#clock-cells = <0>;
+					compatible = "via,vt8500-device-clock";
+					clocks = <&pllb>;
+					divisor-reg = <0x330>;
+					divisor-mask = <0x3f>;
+					enable-reg = <0x250>;
+					enable-bit = <0>;
+				};
+
+				clksf: sf {
+					#clock-cells = <0>;
+					compatible = "via,vt8500-device-clock";
+					clocks = <&pllb>;
+					divisor-reg = <0x314>;
+					enable-reg = <0x254>;
+					enable-bit = <23>;
+				};
+
+				clki2c0: i2c0clk {
+					#clock-cells = <0>;
+					compatible = "via,vt8500-device-clock";
+					clocks = <&pllb>;
+					divisor-reg = <0x3A0>;
+					enable-reg = <0x250>;
+					enable-bit = <8>;
+				};
+
+				clki2c1: i2c1clk {
+					#clock-cells = <0>;
+					compatible = "via,vt8500-device-clock";
+					clocks = <&pllb>;
+					divisor-reg = <0x3A4>;
+					enable-reg = <0x250>;
+					enable-bit = <9>;
+				};
+			};
+		};
+
+		sf at d8002000 {
+			compatible = "wm,wm8505-sf";
+			reg = <0xd8002000 0x400>;
+			clocks = <&clksf>;
+		};
+
+		pwm: pwm at d8220000 {
+			#pwm-cells = <3>;
+			compatible = "via,vt8500-pwm";
+			reg = <0xd8220000 0x100>;
+			clocks = <&clkpwm>;
+		};
+
+		timer at d8130100 {
+			compatible = "via,vt8500-timer";
+			reg = <0xd8130100 0x28>;
+			interrupts = <36>;
+		};
+
+		ehci at d8007900 {
+			compatible = "via,vt8500-ehci";
+			reg = <0xd8007900 0x200>;
+			interrupts = <26>;
+		};
+
+		uhci at d8007b00 {
+			compatible = "platform-uhci";
+			reg = <0xd8007b00 0x200>;
+			interrupts = <26>;
+		};
+
+		uhci at d8008d00 {
+			compatible = "platform-uhci";
+			reg = <0xd8008d00 0x200>;
+			interrupts = <26>;
+		};
+
+		uart0: uart at d8200000 {
+			compatible = "via,vt8500-uart";
+			reg = <0xd8200000 0x1040>;
+			interrupts = <32>;
+			clocks = <&clkuart0>;
+		};
+
+		uart1: uart at d82b0000 {
+			compatible = "via,vt8500-uart";
+			reg = <0xd82b0000 0x1040>;
+			interrupts = <33>;
+			clocks = <&clkuart1>;
+		};
+
+                uart2: uart at d8210000 {
+                        compatible = "via,vt8500-uart";
+                        reg = <0xd8210000 0x1040>;
+                        interrupts = <47>;
+                        clocks = <&clkuart2>;
+                };
+
+                uart3: uart at d82c0000 {
+                        compatible = "via,vt8500-uart";
+                        reg = <0xd82c0000 0x1040>;
+                        interrupts = <50>;
+                        clocks = <&clkuart3>;
+                };
+
+                uart4: uart at d8370000 {
+                        compatible = "via,vt8500-uart";
+                        reg = <0xd8370000 0x1040>;
+                        interrupts = <30>;
+                        clocks = <&clkuart4>;
+                };
+
+                uart5: uart at d8380000 {
+                        compatible = "via,vt8500-uart";
+                        reg = <0xd8380000 0x1040>;
+                        interrupts = <43>;
+                        clocks = <&clkuart5>;
+                };
+
+		rtc at d8100000 {
+			compatible = "via,vt8500-rtc";
+			reg = <0xd8100000 0x10000>;
+			interrupts = <48>;
+		};
+
+		sdhc at d800a000 {
+			compatible = "wm,wm8505-sdhc";
+			reg = <0xd800a000 0x1000>;
+			interrupts = <20 21>;
+			clocks = <&clksdhc>;
+			bus-width = <4>;
+			sdon-inverted;
+		};
+
+		i2c_0: i2c at d8280000 {
+			compatible = "wm,wm8505-i2c";
+			reg = <0xd8280000 0x1000>;
+			interrupts = <19>;
+			clocks = <&clki2c0>;
+			clock-frequency = <400000>;
+		};
+
+		i2c_1: i2c at d8320000 {
+			compatible = "wm,wm8505-i2c";
+			reg = <0xd8320000 0x1000>;
+			interrupts = <18>;
+			clocks = <&clki2c1>;
+			clock-frequency = <400000>;
+		};
+	};
+};
-- 
1.7.9.5



From linux at prisktech.co.nz  Wed Apr 24 01:38:22 2013
From: linux at prisktech.co.nz (Tony Prisk)
Date: Wed, 24 Apr 2013 17:38:22 +1200
Subject: [PATCH 3/3] dts: vt8500: Update serial nodes and disable by default
 in SoC files
In-Reply-To: <1366781902-13025-1-git-send-email-linux@prisktech.co.nz>
References: <1366781902-13025-1-git-send-email-linux@prisktech.co.nz>
Message-ID: <1366781902-13025-4-git-send-email-linux@prisktech.co.nz>

Missing aliases for uarts on vt8500, wm8505, wm8650 added.
Nodes incorrectly labelled uart at .., changed to serial at ... on all SoCs.
Set each uarts default status = "disabled" as they generally don't exist.

For each board file, we only need to enable uart0 as no other uarts are
physically present on any of these boards.

Signed-off-by: Tony Prisk <linux at prisktech.co.nz>
---
 arch/arm/boot/dts/vt8500-bv07.dts    |    4 ++++
 arch/arm/boot/dts/vt8500.dtsi        |   19 +++++++++++++++----
 arch/arm/boot/dts/wm8505-ref.dts     |    4 ++++
 arch/arm/boot/dts/wm8505.dtsi        |   27 +++++++++++++++++++++------
 arch/arm/boot/dts/wm8650-mid.dts     |    4 ++++
 arch/arm/boot/dts/wm8650.dtsi        |   11 +++++++++--
 arch/arm/boot/dts/wm8750-apc8750.dts |    4 ++++
 arch/arm/boot/dts/wm8750.dtsi        |   18 ++++++++++++------
 arch/arm/boot/dts/wm8850-w70v2.dts   |    4 ++++
 arch/arm/boot/dts/wm8850.dtsi        |   12 ++++++++----
 10 files changed, 85 insertions(+), 22 deletions(-)

diff --git a/arch/arm/boot/dts/vt8500-bv07.dts b/arch/arm/boot/dts/vt8500-bv07.dts
index 567cf4e..faabc9c 100644
--- a/arch/arm/boot/dts/vt8500-bv07.dts
+++ b/arch/arm/boot/dts/vt8500-bv07.dts
@@ -34,3 +34,7 @@
 		};
 	};
 };
+
+&uart0 {
+	status = "okay";
+};
diff --git a/arch/arm/boot/dts/vt8500.dtsi b/arch/arm/boot/dts/vt8500.dtsi
index e35590e..4908222 100644
--- a/arch/arm/boot/dts/vt8500.dtsi
+++ b/arch/arm/boot/dts/vt8500.dtsi
@@ -21,6 +21,13 @@
 		};
 	};
 
+	aliases {
+		serial0 = &uart0;
+		serial1 = &uart1;
+		serial2 = &uart2;
+		serial3 = &uart3;
+	};
+
 	soc {
 		#address-cells = <1>;
 		#size-cells = <1>;
@@ -121,32 +128,36 @@
 			reg = <0xd8050400 0x100>;
 		};
 
-		uart at d8200000 {
+		uart0: serial at d8200000 {
 			compatible = "via,vt8500-uart";
 			reg = <0xd8200000 0x1040>;
 			interrupts = <32>;
 			clocks = <&clkuart0>;
+			status = "disabled";
 		};
 
-		uart at d82b0000 {
+		uart1: serial at d82b0000 {
 			compatible = "via,vt8500-uart";
 			reg = <0xd82b0000 0x1040>;
 			interrupts = <33>;
 			clocks = <&clkuart1>;
+			status = "disabled";
 		};
 
-		uart at d8210000 {
+		uart2: serial at d8210000 {
 			compatible = "via,vt8500-uart";
 			reg = <0xd8210000 0x1040>;
 			interrupts = <47>;
 			clocks = <&clkuart2>;
+			status = "disabled";
 		};
 
-		uart at d82c0000 {
+		uart3: serial at d82c0000 {
 			compatible = "via,vt8500-uart";
 			reg = <0xd82c0000 0x1040>;
 			interrupts = <50>;
 			clocks = <&clkuart3>;
+			status = "disabled";
 		};
 
 		rtc at d8100000 {
diff --git a/arch/arm/boot/dts/wm8505-ref.dts b/arch/arm/boot/dts/wm8505-ref.dts
index fd4e248..acb996f 100644
--- a/arch/arm/boot/dts/wm8505-ref.dts
+++ b/arch/arm/boot/dts/wm8505-ref.dts
@@ -34,3 +34,7 @@
 		};
 	};
 };
+
+&uart0 {
+	status = "okay";
+};
diff --git a/arch/arm/boot/dts/wm8505.dtsi b/arch/arm/boot/dts/wm8505.dtsi
index dc21d13..e5076d5 100644
--- a/arch/arm/boot/dts/wm8505.dtsi
+++ b/arch/arm/boot/dts/wm8505.dtsi
@@ -21,6 +21,15 @@
 		};
 	};
 
+ 	aliases {
+		serial0 = &uart0;
+		serial1 = &uart1;
+		serial2 = &uart2;
+		serial3 = &uart3;
+		serial4 = &uart4;
+		serial5 = &uart5;
+ 	};
+
 	soc {
 		#address-cells = <1>;
 		#size-cells = <1>;
@@ -144,46 +153,52 @@
 			reg = <0xd8050400 0x100>;
 		};
 
-		uart at d8200000 {
+		uart0: serial at d8200000 {
 			compatible = "via,vt8500-uart";
 			reg = <0xd8200000 0x1040>;
 			interrupts = <32>;
 			clocks = <&clkuart0>;
+			status = "disabled";
 		};
 
-		uart at d82b0000 {
+		uart1: serial at d82b0000 {
 			compatible = "via,vt8500-uart";
 			reg = <0xd82b0000 0x1040>;
 			interrupts = <33>;
 			clocks = <&clkuart1>;
+			status = "disabled";
 		};
 
-		uart at d8210000 {
+		uart2: serial at d8210000 {
 			compatible = "via,vt8500-uart";
 			reg = <0xd8210000 0x1040>;
 			interrupts = <47>;
 			clocks = <&clkuart2>;
+			status = "disabled";
 		};
 
-		uart at d82c0000 {
+		uart3: serial at d82c0000 {
 			compatible = "via,vt8500-uart";
 			reg = <0xd82c0000 0x1040>;
 			interrupts = <50>;
 			clocks = <&clkuart3>;
+			status = "disabled";
 		};
 
-		uart at d8370000 {
+		uart4: serial at d8370000 {
 			compatible = "via,vt8500-uart";
 			reg = <0xd8370000 0x1040>;
 			interrupts = <31>;
 			clocks = <&clkuart4>;
+			status = "disabled";
 		};
 
-		uart at d8380000 {
+		uart5: serial at d8380000 {
 			compatible = "via,vt8500-uart";
 			reg = <0xd8380000 0x1040>;
 			interrupts = <30>;
 			clocks = <&clkuart5>;
+			status = "disabled";
 		};
 
 		rtc at d8100000 {
diff --git a/arch/arm/boot/dts/wm8650-mid.dts b/arch/arm/boot/dts/wm8650-mid.dts
index cefd938..fec12f1 100644
--- a/arch/arm/boot/dts/wm8650-mid.dts
+++ b/arch/arm/boot/dts/wm8650-mid.dts
@@ -34,3 +34,7 @@
 		};
 	};
 };
+
+&uart0 {
+	status = "okay";
+};
diff --git a/arch/arm/boot/dts/wm8650.dtsi b/arch/arm/boot/dts/wm8650.dtsi
index f4cd55e..8e099a8 100644
--- a/arch/arm/boot/dts/wm8650.dtsi
+++ b/arch/arm/boot/dts/wm8650.dtsi
@@ -21,6 +21,11 @@
 		};
 	};
 
+ 	aliases {
+		serial0 = &uart0;
+		serial1 = &uart1;
+	};
+
 	soc {
 		#address-cells = <1>;
 		#size-cells = <1>;
@@ -150,18 +155,20 @@
 			reg = <0xd8050400 0x100>;
 		};
 
-		uart at d8200000 {
+		uart0: serial at d8200000 {
 			compatible = "via,vt8500-uart";
 			reg = <0xd8200000 0x1040>;
 			interrupts = <32>;
 			clocks = <&clkuart0>;
+			status = "disabled";
 		};
 
-		uart at d82b0000 {
+		uart1: serial at d82b0000 {
 			compatible = "via,vt8500-uart";
 			reg = <0xd82b0000 0x1040>;
 			interrupts = <33>;
 			clocks = <&clkuart1>;
+			status = "disabled";
 		};
 
 		rtc at d8100000 {
diff --git a/arch/arm/boot/dts/wm8750-apc8750.dts b/arch/arm/boot/dts/wm8750-apc8750.dts
index 62675eb..37e4a40 100644
--- a/arch/arm/boot/dts/wm8750-apc8750.dts
+++ b/arch/arm/boot/dts/wm8750-apc8750.dts
@@ -24,3 +24,7 @@
 		wm,pull = <2>;	/* pull-up */
 	};
 };
+
+&uart0 {
+	status = "okay";
+};
diff --git a/arch/arm/boot/dts/wm8750.dtsi b/arch/arm/boot/dts/wm8750.dtsi
index 81683fa..c048c04 100644
--- a/arch/arm/boot/dts/wm8750.dtsi
+++ b/arch/arm/boot/dts/wm8750.dtsi
@@ -273,46 +273,52 @@
 			interrupts = <26>;
 		};
 
-		uart0: uart at d8200000 {
+		uart0: serial at d8200000 {
 			compatible = "via,vt8500-uart";
 			reg = <0xd8200000 0x1040>;
 			interrupts = <32>;
 			clocks = <&clkuart0>;
+			status = "disabled";
 		};
 
-		uart1: uart at d82b0000 {
+		uart1: serial at d82b0000 {
 			compatible = "via,vt8500-uart";
 			reg = <0xd82b0000 0x1040>;
 			interrupts = <33>;
 			clocks = <&clkuart1>;
+			status = "disabled";
 		};
 
-                uart2: uart at d8210000 {
+                uart2: serial at d8210000 {
                         compatible = "via,vt8500-uart";
                         reg = <0xd8210000 0x1040>;
                         interrupts = <47>;
                         clocks = <&clkuart2>;
+			status = "disabled";
                 };
 
-                uart3: uart at d82c0000 {
+                uart3: serial at d82c0000 {
                         compatible = "via,vt8500-uart";
                         reg = <0xd82c0000 0x1040>;
                         interrupts = <50>;
                         clocks = <&clkuart3>;
+			status = "disabled";
                 };
 
-                uart4: uart at d8370000 {
+                uart4: serial at d8370000 {
                         compatible = "via,vt8500-uart";
                         reg = <0xd8370000 0x1040>;
                         interrupts = <30>;
                         clocks = <&clkuart4>;
+			status = "disabled";
                 };
 
-                uart5: uart at d8380000 {
+                uart5: serial at d8380000 {
                         compatible = "via,vt8500-uart";
                         reg = <0xd8380000 0x1040>;
                         interrupts = <43>;
                         clocks = <&clkuart5>;
+			status = "disabled";
                 };
 
 		rtc at d8100000 {
diff --git a/arch/arm/boot/dts/wm8850-w70v2.dts b/arch/arm/boot/dts/wm8850-w70v2.dts
index fcc660c..5b96ba2 100644
--- a/arch/arm/boot/dts/wm8850-w70v2.dts
+++ b/arch/arm/boot/dts/wm8850-w70v2.dts
@@ -45,3 +45,7 @@
 		default-brightness-level = <5>;
 	};
 };
+
+&uart0 {
+	status = "okay";
+};
diff --git a/arch/arm/boot/dts/wm8850.dtsi b/arch/arm/boot/dts/wm8850.dtsi
index 4b56aa0..b5d36e1 100644
--- a/arch/arm/boot/dts/wm8850.dtsi
+++ b/arch/arm/boot/dts/wm8850.dtsi
@@ -189,32 +189,36 @@
 			interrupts = <26>;
 		};
 
-		uart0: uart at d8200000 {
+		uart0: serial at d8200000 {
 			compatible = "via,vt8500-uart";
 			reg = <0xd8200000 0x1040>;
 			interrupts = <32>;
 			clocks = <&clkuart0>;
+			status = "disabled";
 		};
 
-		uart1: uart at d82b0000 {
+		uart1: serial at d82b0000 {
 			compatible = "via,vt8500-uart";
 			reg = <0xd82b0000 0x1040>;
 			interrupts = <33>;
 			clocks = <&clkuart1>;
+			status = "disabled";
 		};
 
-                uart2: uart at d8210000 {
+                uart2: serial at d8210000 {
                         compatible = "via,vt8500-uart";
                         reg = <0xd8210000 0x1040>;
                         interrupts = <47>;
                         clocks = <&clkuart2>;
+			status = "disabled";
                 };
 
-                uart3: uart at d82c0000 {
+                uart3: serial at d82c0000 {
                         compatible = "via,vt8500-uart";
                         reg = <0xd82c0000 0x1040>;
                         interrupts = <50>;
                         clocks = <&clkuart3>;
+			status = "disabled";
                 };
 
 		rtc at d8100000 {
-- 
1.7.9.5



From andrew at lunn.ch  Wed Apr 24 01:37:58 2013
From: andrew at lunn.ch (Andrew Lunn)
Date: Wed, 24 Apr 2013 07:37:58 +0200
Subject: [PATCHv1 1/3] hwmon: Add support for GMT G762/G763 PWM fan
 controller
In-Reply-To: <63961d39aee9db94767f28fd441312bec2029473.1366753420.git.arno@natisbad.org>
References: <cover.1366753420.git.arno@natisbad.org>
 <63961d39aee9db94767f28fd441312bec2029473.1366753420.git.arno@natisbad.org>
Message-ID: <20130424053758.GC8710@lunn.ch>

On Wed, Apr 24, 2013 at 12:05:56AM +0200, Arnaud Ebalard wrote:
> 
> Signed-off-by: Arnaud Ebalard <arno at natisbad.org>
> Tested-by: Arnaud Ebalard <arno at natisbad.org>
> ---
>  drivers/hwmon/Kconfig  |   10 +
>  drivers/hwmon/Makefile |    1 +
>  drivers/hwmon/g762.c   | 1058 ++++++++++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 1069 insertions(+)
>  create mode 100644 drivers/hwmon/g762.c
> 
> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
> index 89ac1cb..cb4879c 100644
> --- a/drivers/hwmon/Kconfig
> +++ b/drivers/hwmon/Kconfig
> @@ -423,6 +423,16 @@ config SENSORS_G760A
>  	  This driver can also be built as a module.  If so, the module
>  	  will be called g760a.
>  
> +config SENSORS_G762
> +	tristate "GMT G762 and G763"
> +	depends on I2C
> +	help
> +	  If you say yes here you get support for Global Mixed-mode
> +	  Technology Inc G762 and G763 fan speed PWM controller chips.
> +
> +	  This driver can also be built as a module.  If so, the module
> +	  will be called g762.
> +
>  config SENSORS_GL518SM
>  	tristate "Genesys Logic GL518SM"
>  	depends on I2C
> diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
> index 8d6d97e..4b49504 100644
> --- a/drivers/hwmon/Makefile
> +++ b/drivers/hwmon/Makefile
> @@ -57,6 +57,7 @@ obj-$(CONFIG_SENSORS_F75375S)	+= f75375s.o
>  obj-$(CONFIG_SENSORS_FAM15H_POWER) += fam15h_power.o
>  obj-$(CONFIG_SENSORS_FSCHMD)	+= fschmd.o
>  obj-$(CONFIG_SENSORS_G760A)	+= g760a.o
> +obj-$(CONFIG_SENSORS_G762)	+= g762.o
>  obj-$(CONFIG_SENSORS_GL518SM)	+= gl518sm.o
>  obj-$(CONFIG_SENSORS_GL520SM)	+= gl520sm.o
>  obj-$(CONFIG_SENSORS_GPIO_FAN)	+= gpio-fan.o
> diff --git a/drivers/hwmon/g762.c b/drivers/hwmon/g762.c
> new file mode 100644
> index 0000000..810b019
> --- /dev/null
> +++ b/drivers/hwmon/g762.c
> @@ -0,0 +1,1058 @@
> +/*
> + * g762 - Driver for the Global Mixed-mode Technology Inc. fan speed PWM
> + *        controller chips from G762 family, i.e. G762 and G763
> + *
> + * Copyright (C) 2013, Arnaud EBALARD <arno at natisbad.org>
> + *
> + * This work is based on a basic version for 2.6.31 kernel developed
> + * by Olivier Mouchet for LaCie NAS. Updates have been performed to run
> + * on recent kernels. Additional features have been added. Ability to
> + * configure various characteristics via .dts file has been added.
> + * Detailed datasheet on which this development is based is available
> + * here:
> + *
> + *  http://natisbad.org/NAS/refs/GMT_EDS-762_763-080710-0.2.pdf
> + *
> + * Headers from previous developments have been kept below:
> + *
> + * Copyright (c) 2009 LaCie
> + *
> + * Author: Olivier Mouchet <olivier.mouchet at gmail.com>
> + *
> + * based on g760a code written by Herbert Valerio Riedel <hvr at gnu.org>
> + * Copyright (C) 2007  Herbert Valerio Riedel <hvr at gnu.org>
> + *
> + * g762: minimal datasheet available at:
> + *       http://www.gmt.com.tw/product/datasheet/EDS-762_3.pdf
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
> + */
> +
> +#include <linux/device.h>
> +#include <linux/module.h>
> +#include <linux/init.h>
> +#include <linux/slab.h>
> +#include <linux/jiffies.h>
> +#include <linux/i2c.h>
> +#include <linux/hwmon.h>
> +#include <linux/hwmon-sysfs.h>
> +#include <linux/err.h>
> +#include <linux/mutex.h>
> +#include <linux/kernel.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>
> +
> +#define DRVNAME "g762"
> +
> +static const struct i2c_device_id g762_id[] = {
> +	{ "g762", 0 },
> +	{ "g763", 0 },
> +	{ }
> +};
> +MODULE_DEVICE_TABLE(i2c, g762_id);
> +
> +enum g762_regs {
> +	G762_REG_SET_CNT  = 0x00,
> +	G762_REG_ACT_CNT  = 0x01,
> +	G762_REG_FAN_STA  = 0x02,
> +	G762_REG_SET_OUT  = 0x03,
> +	G762_REG_FAN_CMD1 = 0x04,
> +	G762_REG_FAN_CMD2 = 0x05,
> +};
> +
> +/* Config register bits */
> +#define G762_REG_FAN_CMD1_DET_FAN_FAIL  0x80 /* enable fan_fail signal */
> +#define G762_REG_FAN_CMD1_DET_FAN_OOC   0x40 /* enable fan_out_of_control */
> +#define G762_REG_FAN_CMD1_OUT_MODE      0x20 /* out mode, pwm or dac */
> +#define G762_REG_FAN_CMD1_FAN_MODE      0x10 /* fan mode: close or open loop */
> +#define G762_REG_FAN_CMD1_CLK_DIV_ID1   0x08 /* clock divisor value */
> +#define G762_REG_FAN_CMD1_CLK_DIV_ID0   0x04
> +#define G762_REG_FAN_CMD1_PWM_POLARITY  0x02 /* pwm polarity */
> +#define G762_REG_FAN_CMD1_PULSE_PER_REV 0x01 /* pulse per fan revolution */
> +
> +#define G762_REG_FAN_CMD2_GEAR_MODE_1   0x08 /* fan gear mode */
> +#define G762_REG_FAN_CMD2_GEAR_MODE_0   0x04
> +#define G762_REG_FAN_CMD2_FAN_STARTV_1  0x02 /* fan startup voltage */
> +#define G762_REG_FAN_CMD2_FAN_STARTV_0  0x01
> +
> +#define G762_REG_FAN_STA_FAIL           0x02 /* fan fail */
> +#define G762_REG_FAN_STA_OOC            0x01 /* fan out of control */
> +
> +/* config register values */
> +#define OUT_MODE_PWM            1
> +#define OUT_MODE_DAC            0
> +
> +#define FAN_MODE_CLOSED_LOOP    2
> +#define FAN_MODE_OPEN_LOOP      1
> +
> +/* register data is read (and cached) at most once per second */
> +#define G762_UPDATE_INTERVAL (HZ)
> +
> +/*
> + * extract pulse count per fan revolution value (2 or 4) from given
> + * FAN_CMD1 register value
> + */
> +#define PULSE_FROM_REG(reg) \
> +	((((reg) & G762_REG_FAN_CMD1_PULSE_PER_REV)+1) << 1)
> +
> +/*
> + * extract fan clock divisor (1, 2, 4 or 8) from given FAN_CMD1
> + * register value
> + */
> +#define CLKDIV_FROM_REG(reg) \
> +	(1 << (((reg) & (G762_REG_FAN_CMD1_CLK_DIV_ID0 |	\
> +			 G762_REG_FAN_CMD1_CLK_DIV_ID1)) >> 2))
> +
> +/*
> + * extract fan gear mode value (0, 1 or 2) from given FAN_CMD2
> + * register value
> + */
> +#define GEARMODE_FROM_REG(reg) \
> +	(1 << (((reg) & (G762_REG_FAN_CMD2_GEAR_MODE_0 |	\
> +			 G762_REG_FAN_CMD2_GEAR_MODE_1)) >> 2))
> +
> +struct g762_data {
> +	struct i2c_client *client;
> +	struct device *hwmon_dev;
> +
> +	/* update mutex */
> +	struct mutex update_lock;
> +
> +	/* board specific parameters. */
> +	u32 clk; /* default 32kHz */
> +
> +	/* g762 register cache */
> +	bool valid;
> +	unsigned long last_updated; /* in jiffies */
> +
> +	u8 set_cnt;  /* RPM cmd in close loop control */
> +	u8 act_cnt;  /* formula: cnt = (CLK * 30)/(rpm * P) */
> +	u8 fan_sta;  /* bit 0: set when actual fan speed is more than
> +		      *        25% outside requested fan speed
> +		      * bit 1: set when no transition occurs on fan
> +		      *        pin for 0.7s
> +		      */
> +	u8 set_out;  /* output voltage/PWM duty in open loop control */
> +	u8 fan_cmd1; /*   0: FG_PLS_ID0 FG pulses count per revolution
> +		      *      0: 2 counts per revolution
> +		      *      1: 4 counts per revolution
> +		      *   1: PWM_POLARITY 1: negative_duty
> +		      *                   0: positive_duty
> +		      * 2,3: [FG_CLOCK_ID0, FG_CLK_ID1]
> +		      *         00: Divide fan clock by 1
> +		      *         01: Divide fan clock by 2
> +		      *         10: Divide fan clock by 4
> +		      *         11: Divide fan clock by 8
> +		      *   4: FAN_MODE 1:close-loop, 0:open-loop
> +		      *   5: OUT_MODE 1:PWM, 0:DAC
> +		      *   6: DET_FAN_OOC enable "fan ooc" status
> +		      *   7: DET_FAN_FAIL enable "fan fail" status
> +		      */
> +	u8 fan_cmd2; /* 0,1: FAN_STARTV 0,1,2,3 -> 0,32,64,96 dac_code
> +		      * 2,3: FG_GEAR_MODE
> +		      *         00: div = 1
> +		      *         01: div = 2
> +		      *         10: div = 4
> +		      *   4: Mask ALERT# (g763 only)
> +		      */

You could consider using regmap for holding this cache.

http://elceurope2012.sched.org/event/100619b669ce5767341624253aa03659?iframe=no&w=900&sidebar=yes&bg=no#.UXdspHLQ5jM

http://elinux.org/ELCE_Europe_2012_Presentations

Nice documentation by the way.

> +/*
> + * Helpers to import hardware characteristics from .dts file and overload
> + * default config values.
> + */
> +
> +#ifdef CONFIG_OF

Can the driver be used without device tree? Would it be simpler to
 just add depends OF in the Kconfig entry?

 Andrew


From kishon at ti.com  Wed Apr 24 01:41:52 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Wed, 24 Apr 2013 11:11:52 +0530
Subject: Multiple issues with omap4 panda es in linux next
In-Reply-To: <20130423231605.GO10155@atomide.com>
References: <20130419171318.GK10155@atomide.com> <5174F7A8.7070308@ti.com>
 <20130422180316.GA10155@atomide.com> <5176A45B.5@ti.com>
 <20130423172353.GD10155@atomide.com> <20130423213151.GM10155@atomide.com>
 <20130423231605.GO10155@atomide.com>
Message-ID: <517770A0.4000609@ti.com>

Hi Tony,

On Wednesday 24 April 2013 04:46 AM, Tony Lindgren wrote:
> * Tony Lindgren <tony at atomide.com> [130423 14:37]:
>> * Tony Lindgren <tony at atomide.com> [130423 10:28]:
>>> * Kishon Vijay Abraham I <kishon at ti.com> [130423 08:15]:
>>>>>>> 2. MUSB fails with legacy booting and DT on panda es
>>>>>>>
>>>>>>> With both legacy and DT booting I get something like:
>>>>>>>
>>>>>>> HS USB OTG: no transceiver configured
>>>>>>> musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with status -517
>>>>>>
>>>>>> The dt should work fine with https://patchwork.kernel.org/patch/2423061/.
>>>>>
>>>>> OK thanks for checking that.
>
> Kishon, I think there's also some other issue remaining
> in linux next with MUSB and DT. I'm still getting the
> "HS USB OTG: no transceiver configured" although the nop
> xceiv is compiled in. Maybe give it a try against linux
> next?

For OMAP4 MUSB, you'll need omap-usb2 phy. I've attached my .config.

Thanks
Kishon
-------------- next part --------------
#
# Automatically generated file; DO NOT EDIT.
# Linux/arm 3.9.0-rc7 Kernel Configuration
#
CONFIG_ARM=y
CONFIG_SYS_SUPPORTS_APM_EMULATION=y
CONFIG_HAVE_PROC_CPU=y
CONFIG_NO_IOPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_RWSEM_GENERIC_SPINLOCK=y
CONFIG_ARCH_HAS_CPUFREQ=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_VECTORS_BASE=0xffff0000
CONFIG_ARM_PATCH_PHYS_VIRT=y
CONFIG_GENERIC_BUG=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y

#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
# CONFIG_FHANDLE is not set
# CONFIG_AUDIT is not set
CONFIG_HAVE_GENERIC_HARDIRQS=y

#
# IRQ subsystem
#
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_HARDIRQS_SW_RESEND=y
CONFIG_GENERIC_IRQ_CHIP=y
CONFIG_IRQ_DOMAIN=y
# CONFIG_IRQ_DOMAIN_DEBUG is not set
CONFIG_SPARSE_IRQ=y
# CONFIG_ALWAYS_USE_PERSISTENT_CLOCK is not set
CONFIG_KTIME_SCALAR=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_ARCH_HAS_TICK_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y

#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_PERIODIC_HZ=y
# CONFIG_NO_HZ_IDLE is not set
CONFIG_HIGH_RES_TIMERS=y

#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
# CONFIG_TASKSTATS is not set

#
# RCU Subsystem
#
CONFIG_TREE_RCU=y
# CONFIG_PREEMPT_RCU is not set
CONFIG_RCU_STALL_COMMON=y
# CONFIG_RCU_USER_QS is not set
CONFIG_RCU_FANOUT=32
CONFIG_RCU_FANOUT_LEAF=16
# CONFIG_RCU_FANOUT_EXACT is not set
# CONFIG_TREE_RCU_TRACE is not set
# CONFIG_RCU_NOCB_CPU is not set
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=16
# CONFIG_CGROUPS is not set
# CONFIG_CHECKPOINT_RESTORE is not set
# CONFIG_NAMESPACES is not set
CONFIG_UIDGID_CONVERTED=y
# CONFIG_UIDGID_STRICT_TYPE_CHECKS is not set
# CONFIG_SCHED_AUTOGROUP is not set
# CONFIG_SYSFS_DEPRECATED is not set
# CONFIG_RELAY is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE="/nfs/newfs"
CONFIG_INITRAMFS_ROOT_UID=0
CONFIG_INITRAMFS_ROOT_GID=0
CONFIG_RD_GZIP=y
# CONFIG_RD_BZIP2 is not set
# CONFIG_RD_LZMA is not set
# CONFIG_RD_XZ is not set
# CONFIG_RD_LZO is not set
# CONFIG_RD_LZ4 is not set
CONFIG_INITRAMFS_COMPRESSION_NONE=y
# CONFIG_INITRAMFS_COMPRESSION_GZIP is not set
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
CONFIG_EXPERT=y
CONFIG_HAVE_UID16=y
CONFIG_UID16=y
# CONFIG_SYSCTL_SYSCALL is not set
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_AIO=y
# CONFIG_EMBEDDED is not set
CONFIG_HAVE_PERF_EVENTS=y
CONFIG_PERF_USE_VMALLOC=y

#
# Kernel Performance Events And Counters
#
CONFIG_PERF_EVENTS=y
# CONFIG_DEBUG_PERF_USE_VMALLOC is not set
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_COMPAT_BRK=y
CONFIG_SLAB=y
# CONFIG_SLUB is not set
# CONFIG_SLOB is not set
CONFIG_PROFILING=y
CONFIG_TRACEPOINTS=y
CONFIG_OPROFILE=y
CONFIG_HAVE_OPROFILE=y
CONFIG_KPROBES=y
# CONFIG_JUMP_LABEL is not set
# CONFIG_HAVE_64BIT_ALIGNED_ACCESS is not set
CONFIG_KRETPROBES=y
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
CONFIG_HAVE_ARCH_TRACEHOOK=y
CONFIG_HAVE_DMA_ATTRS=y
CONFIG_HAVE_DMA_CONTIGUOUS=y
CONFIG_USE_GENERIC_SMP_HELPERS=y
CONFIG_GENERIC_SMP_IDLE_THREAD=y
CONFIG_GENERIC_IDLE_LOOP=y
CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y
CONFIG_HAVE_CLK=y
CONFIG_HAVE_DMA_API_DEBUG=y
CONFIG_HAVE_HW_BREAKPOINT=y
CONFIG_HAVE_ARCH_JUMP_LABEL=y
CONFIG_ARCH_WANT_IPC_PARSE_VERSION=y
CONFIG_HAVE_ARCH_SECCOMP_FILTER=y
CONFIG_HAVE_CONTEXT_TRACKING=y
CONFIG_HAVE_MOD_ARCH_SPECIFIC=y
CONFIG_MODULES_USE_ELF_REL=y
CONFIG_CLONE_BACKWARDS=y
CONFIG_OLD_SIGSUSPEND3=y
CONFIG_OLD_SIGACTION=y

#
# GCOV-based kernel profiling
#
# CONFIG_GCOV_KERNEL is not set
CONFIG_HAVE_GENERIC_DMA_COHERENT=y
CONFIG_SLABINFO=y
CONFIG_RT_MUTEXES=y
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
CONFIG_MODULE_FORCE_LOAD=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
CONFIG_MODVERSIONS=y
CONFIG_MODULE_SRCVERSION_ALL=y
# CONFIG_MODULE_SIG is not set
CONFIG_STOP_MACHINE=y
CONFIG_BLOCK=y
CONFIG_LBDAF=y
# CONFIG_BLK_DEV_BSG is not set
# CONFIG_BLK_DEV_BSGLIB is not set
# CONFIG_BLK_DEV_INTEGRITY is not set

#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
# CONFIG_OSF_PARTITION is not set
# CONFIG_AMIGA_PARTITION is not set
# CONFIG_ATARI_PARTITION is not set
# CONFIG_MAC_PARTITION is not set
CONFIG_MSDOS_PARTITION=y
# CONFIG_BSD_DISKLABEL is not set
# CONFIG_MINIX_SUBPARTITION is not set
# CONFIG_SOLARIS_X86_PARTITION is not set
# CONFIG_UNIXWARE_DISKLABEL is not set
# CONFIG_LDM_PARTITION is not set
# CONFIG_SGI_PARTITION is not set
# CONFIG_ULTRIX_PARTITION is not set
# CONFIG_SUN_PARTITION is not set
# CONFIG_KARMA_PARTITION is not set
CONFIG_EFI_PARTITION=y
# CONFIG_SYSV68_PARTITION is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_DEFAULT_DEADLINE is not set
CONFIG_DEFAULT_CFQ=y
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="cfq"
CONFIG_UNINLINE_SPIN_UNLOCK=y
CONFIG_FREEZER=y

#
# System Type
#
CONFIG_MMU=y
CONFIG_ARCH_MULTIPLATFORM=y
# CONFIG_ARCH_INTEGRATOR is not set
# CONFIG_ARCH_REALVIEW is not set
# CONFIG_ARCH_VERSATILE is not set
# CONFIG_ARCH_AT91 is not set
# CONFIG_ARCH_CLPS711X is not set
# CONFIG_ARCH_GEMINI is not set
# CONFIG_ARCH_EBSA110 is not set
# CONFIG_ARCH_EP93XX is not set
# CONFIG_ARCH_FOOTBRIDGE is not set
# CONFIG_ARCH_NETX is not set
# CONFIG_ARCH_IOP13XX is not set
# CONFIG_ARCH_IOP32X is not set
# CONFIG_ARCH_IOP33X is not set
# CONFIG_ARCH_IXP4XX is not set
# CONFIG_ARCH_DOVE is not set
# CONFIG_ARCH_KIRKWOOD is not set
# CONFIG_ARCH_MV78XX0 is not set
# CONFIG_ARCH_ORION5X is not set
# CONFIG_ARCH_MMP is not set
# CONFIG_ARCH_KS8695 is not set
# CONFIG_ARCH_W90X900 is not set
# CONFIG_ARCH_LPC32XX is not set
# CONFIG_ARCH_PXA is not set
# CONFIG_ARCH_MSM is not set
# CONFIG_ARCH_SHMOBILE is not set
# CONFIG_ARCH_RPC is not set
# CONFIG_ARCH_SA1100 is not set
# CONFIG_ARCH_S3C24XX is not set
# CONFIG_ARCH_S3C64XX is not set
# CONFIG_ARCH_S5P64X0 is not set
# CONFIG_ARCH_S5PC100 is not set
# CONFIG_ARCH_S5PV210 is not set
# CONFIG_ARCH_EXYNOS is not set
# CONFIG_ARCH_SHARK is not set
# CONFIG_ARCH_U300 is not set
# CONFIG_ARCH_DAVINCI is not set
# CONFIG_ARCH_OMAP1 is not set

#
# Multiple platform selection
#

#
# CPU Core family selection
#
# CONFIG_ARCH_MULTI_V6 is not set
CONFIG_ARCH_MULTI_V7=y
CONFIG_ARCH_MULTI_V6_V7=y
# CONFIG_ARCH_MULTI_CPU_AUTO is not set
# CONFIG_ARCH_MVEBU is not set
# CONFIG_ARCH_BCM is not set
# CONFIG_GPIO_PCA953X is not set
# CONFIG_KEYBOARD_GPIO_POLLED is not set
# CONFIG_ARCH_HIGHBANK is not set
# CONFIG_ARCH_MXC is not set

#
# TI OMAP Common Features
#

#
# OMAP Feature Selections
#
CONFIG_OMAP_DEBUG_DEVICES=y
CONFIG_OMAP_DEBUG_LEDS=y
CONFIG_OMAP_RESET_CLOCKS=y
CONFIG_OMAP_MUX=y
CONFIG_OMAP_MUX_DEBUG=y
CONFIG_OMAP_MUX_WARNINGS=y
CONFIG_OMAP_32K_TIMER=y
# CONFIG_OMAP3_L2_AUX_SECURE_SAVE_RESTORE is not set
CONFIG_OMAP_DM_TIMER=y
CONFIG_OMAP_PM_NOOP=y
CONFIG_MACH_OMAP_GENERIC=y
CONFIG_ARCH_OMAP=y
CONFIG_ARCH_OMAP2PLUS=y

#
# TI OMAP2/3/4 Specific Features
#
CONFIG_ARCH_OMAP2PLUS_TYPICAL=y
CONFIG_SOC_HAS_OMAP2_SDRC=y
CONFIG_SOC_HAS_REALTIME_COUNTER=y
CONFIG_ARCH_OMAP2=y
CONFIG_ARCH_OMAP3=y
CONFIG_ARCH_OMAP4=y
CONFIG_SOC_OMAP5=y

#
# OMAP Core Type
#
CONFIG_SOC_OMAP2420=y
CONFIG_SOC_OMAP2430=y
CONFIG_SOC_OMAP3430=y
CONFIG_SOC_TI81XX=y
CONFIG_SOC_AM33XX=y
CONFIG_OMAP_PACKAGE_ZAF=y
CONFIG_OMAP_PACKAGE_ZAC=y
CONFIG_OMAP_PACKAGE_CBB=y
CONFIG_OMAP_PACKAGE_CUS=y
CONFIG_OMAP_PACKAGE_CBP=y
CONFIG_OMAP_PACKAGE_CBL=y
CONFIG_OMAP_PACKAGE_CBS=y

#
# OMAP Board Type
#
CONFIG_MACH_OMAP2_TUSB6010=y
CONFIG_MACH_OMAP_H4=y
CONFIG_MACH_OMAP_2430SDP=y
CONFIG_MACH_OMAP3_BEAGLE=y
CONFIG_MACH_DEVKIT8000=y
CONFIG_MACH_OMAP_LDP=y
CONFIG_MACH_OMAP3530_LV_SOM=y
CONFIG_MACH_OMAP3_TORPEDO=y
CONFIG_MACH_OVERO=y
CONFIG_MACH_OMAP3EVM=y
CONFIG_MACH_OMAP3517EVM=y
# CONFIG_MACH_CRANEBOARD is not set
CONFIG_MACH_OMAP3_PANDORA=y
CONFIG_MACH_TOUCHBOOK=y
CONFIG_MACH_OMAP_3430SDP=y
CONFIG_MACH_NOKIA_N800=y
CONFIG_MACH_NOKIA_N810=y
CONFIG_MACH_NOKIA_N810_WIMAX=y
CONFIG_MACH_NOKIA_N8X0=y
CONFIG_MACH_NOKIA_RM680=y
CONFIG_MACH_NOKIA_RX51=y
CONFIG_MACH_OMAP_ZOOM2=y
CONFIG_MACH_OMAP_ZOOM3=y
CONFIG_MACH_CM_T35=y
CONFIG_MACH_CM_T3517=y
CONFIG_MACH_CM_T3730=y
CONFIG_MACH_IGEP0020=y
CONFIG_MACH_IGEP0030=y
CONFIG_MACH_SBC3530=y
CONFIG_MACH_OMAP_3630SDP=y
CONFIG_MACH_TI8168EVM=y
CONFIG_MACH_TI8148EVM=y
CONFIG_MACH_OMAP_4430SDP=y
CONFIG_MACH_OMAP4_PANDA=y
# CONFIG_OMAP3_EMU is not set
# CONFIG_OMAP3_SDRC_AC_TIMING is not set
# CONFIG_ARCH_SOCFPGA is not set
# CONFIG_PLAT_SPEAR is not set
# CONFIG_ARCH_SUNXI is not set
# CONFIG_ARCH_SIRF is not set
# CONFIG_ARCH_TEGRA is not set
# CONFIG_ARCH_U8500 is not set
CONFIG_ARCH_VEXPRESS=y

#
# Versatile Express platform type
#
CONFIG_ARCH_VEXPRESS_CORTEX_A5_A9_ERRATA=y
CONFIG_ARCH_VEXPRESS_CA9X4=y
CONFIG_PLAT_VERSATILE_CLCD=y
CONFIG_PLAT_VERSATILE_SCHED_CLOCK=y
# CONFIG_ARCH_VIRT is not set
# CONFIG_ARCH_WM8850 is not set
# CONFIG_ARCH_ZYNQ is not set
CONFIG_PLAT_VERSATILE=y
CONFIG_ARM_TIMER_SP804=y

#
# Processor Type
#
CONFIG_CPU_V6=y
CONFIG_CPU_V7=y
CONFIG_CPU_32v6=y
CONFIG_CPU_32v6K=y
CONFIG_CPU_32v7=y
CONFIG_CPU_ABRT_EV6=y
CONFIG_CPU_ABRT_EV7=y
CONFIG_CPU_PABRT_V6=y
CONFIG_CPU_PABRT_V7=y
CONFIG_CPU_CACHE_V6=y
CONFIG_CPU_CACHE_V7=y
CONFIG_CPU_CACHE_VIPT=y
CONFIG_CPU_COPY_V6=y
CONFIG_CPU_TLB_V6=y
CONFIG_CPU_TLB_V7=y
CONFIG_CPU_HAS_ASID=y
CONFIG_CPU_CP15=y
CONFIG_CPU_CP15_MMU=y
CONFIG_CPU_USE_DOMAINS=y

#
# Processor Features
#
# CONFIG_ARCH_PHYS_ADDR_T_64BIT is not set
CONFIG_ARM_THUMB=y
CONFIG_ARM_THUMBEE=y
CONFIG_ARM_VIRT_EXT=y
# CONFIG_CPU_ICACHE_DISABLE is not set
# CONFIG_CPU_DCACHE_DISABLE is not set
# CONFIG_CPU_BPREDICT_DISABLE is not set
CONFIG_OUTER_CACHE=y
CONFIG_OUTER_CACHE_SYNC=y
CONFIG_MIGHT_HAVE_CACHE_L2X0=y
CONFIG_CACHE_L2X0=y
CONFIG_ARM_L1_CACHE_SHIFT_6=y
CONFIG_ARM_L1_CACHE_SHIFT=6
CONFIG_ARM_DMA_MEM_BUFFERABLE=y
CONFIG_ARM_NR_BANKS=8
CONFIG_MULTI_IRQ_HANDLER=y
# CONFIG_ARM_ERRATA_326103 is not set
CONFIG_ARM_ERRATA_411920=y
# CONFIG_ARM_ERRATA_430973 is not set
CONFIG_PL310_ERRATA_588369=y
CONFIG_ARM_ERRATA_720789=y
CONFIG_PL310_ERRATA_727915=y
CONFIG_ARM_ERRATA_754322=y
# CONFIG_ARM_ERRATA_754327 is not set
# CONFIG_ARM_ERRATA_764369 is not set
# CONFIG_PL310_ERRATA_769419 is not set
CONFIG_ARM_ERRATA_775420=y
# CONFIG_ARM_ERRATA_798181 is not set
CONFIG_ICST=y

#
# Bus support
#
CONFIG_ARM_AMBA=y
# CONFIG_PCI_SYSCALL is not set
# CONFIG_PCCARD is not set

#
# Kernel Features
#
CONFIG_HAVE_SMP=y
CONFIG_SMP=y
CONFIG_SMP_ON_UP=y
CONFIG_ARM_CPU_TOPOLOGY=y
# CONFIG_SCHED_MC is not set
# CONFIG_SCHED_SMT is not set
CONFIG_HAVE_ARM_SCU=y
CONFIG_HAVE_ARM_ARCH_TIMER=y
CONFIG_HAVE_ARM_TWD=y
CONFIG_VMSPLIT_3G=y
# CONFIG_VMSPLIT_2G is not set
# CONFIG_VMSPLIT_1G is not set
CONFIG_PAGE_OFFSET=0xC0000000
CONFIG_NR_CPUS=2
CONFIG_HOTPLUG_CPU=y
# CONFIG_ARM_PSCI is not set
CONFIG_LOCAL_TIMERS=y
CONFIG_ARCH_NR_GPIO=512
CONFIG_PREEMPT_NONE=y
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT is not set
CONFIG_HZ=100
CONFIG_SCHED_HRTICK=y
CONFIG_AEABI=y
CONFIG_OABI_COMPAT=y
CONFIG_ARCH_HAS_HOLES_MEMORYMODEL=y
# CONFIG_ARCH_SPARSEMEM_DEFAULT is not set
# CONFIG_ARCH_SELECT_MEMORY_MODEL is not set
CONFIG_HAVE_ARCH_PFN_VALID=y
CONFIG_HIGHMEM=y
# CONFIG_HIGHPTE is not set
CONFIG_HW_PERF_EVENTS=y
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
CONFIG_HAVE_MEMBLOCK=y
CONFIG_MEMORY_ISOLATION=y
# CONFIG_HAVE_BOOTMEM_INFO_NODE is not set
CONFIG_PAGEFLAGS_EXTENDED=y
CONFIG_SPLIT_PTLOCK_CPUS=999999
CONFIG_COMPACTION=y
CONFIG_MIGRATION=y
# CONFIG_PHYS_ADDR_T_64BIT is not set
CONFIG_ZONE_DMA_FLAG=0
CONFIG_BOUNCE=y
# CONFIG_KSM is not set
CONFIG_DEFAULT_MMAP_MIN_ADDR=4096
CONFIG_CROSS_MEMORY_ATTACH=y
# CONFIG_CLEANCACHE is not set
# CONFIG_FRONTSWAP is not set
CONFIG_FORCE_MAX_ZONEORDER=12
CONFIG_ALIGNMENT_TRAP=y
# CONFIG_UACCESS_WITH_MEMCPY is not set
# CONFIG_SECCOMP is not set
# CONFIG_CC_STACKPROTECTOR is not set

#
# Boot options
#
CONFIG_USE_OF=y
CONFIG_ATAGS=y
# CONFIG_DEPRECATED_PARAM_STRUCT is not set
CONFIG_ZBOOT_ROM_TEXT=0x0
CONFIG_ZBOOT_ROM_BSS=0x0
CONFIG_ARM_APPENDED_DTB=y
CONFIG_ARM_ATAG_DTB_COMPAT=y
CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER=y
# CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND is not set
CONFIG_CMDLINE="root=/dev/mmcblk0p2 rootwait console=ttyO2,115200"
CONFIG_CMDLINE_FROM_BOOTLOADER=y
# CONFIG_CMDLINE_EXTEND is not set
# CONFIG_CMDLINE_FORCE is not set
CONFIG_KEXEC=y
CONFIG_ATAGS_PROC=y
# CONFIG_CRASH_DUMP is not set
CONFIG_AUTO_ZRELADDR=y

#
# CPU Power Management
#

#
# CPU Frequency scaling
#
# CONFIG_CPU_FREQ is not set
# CONFIG_CPU_IDLE is not set
CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED=y

#
# Floating point emulation
#

#
# At least one emulation must be selected
#
CONFIG_FPE_NWFPE=y
# CONFIG_FPE_NWFPE_XP is not set
# CONFIG_FPE_FASTFPE is not set
CONFIG_VFP=y
CONFIG_VFPv3=y
CONFIG_NEON=y

#
# Userspace binary formats
#
CONFIG_BINFMT_ELF=y
CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE=y
CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS=y
CONFIG_BINFMT_SCRIPT=y
CONFIG_HAVE_AOUT=y
# CONFIG_BINFMT_AOUT is not set
CONFIG_BINFMT_MISC=y
CONFIG_COREDUMP=y

#
# Power management options
#
CONFIG_SUSPEND=y
CONFIG_SUSPEND_FREEZER=y
CONFIG_PM_SLEEP=y
CONFIG_PM_SLEEP_SMP=y
# CONFIG_PM_AUTOSLEEP is not set
# CONFIG_PM_WAKELOCKS is not set
CONFIG_PM_RUNTIME=y
CONFIG_PM=y
CONFIG_PM_DEBUG=y
# CONFIG_PM_ADVANCED_DEBUG is not set
# CONFIG_PM_TEST_SUSPEND is not set
CONFIG_PM_SLEEP_DEBUG=y
# CONFIG_APM_EMULATION is not set
CONFIG_ARCH_HAS_OPP=y
CONFIG_PM_OPP=y
CONFIG_PM_CLK=y
CONFIG_CPU_PM=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARM_CPU_SUSPEND=y
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
# CONFIG_PACKET_DIAG is not set
CONFIG_UNIX=y
# CONFIG_UNIX_DIAG is not set
CONFIG_XFRM=y
CONFIG_XFRM_ALGO=y
CONFIG_XFRM_USER=y
# CONFIG_XFRM_SUB_POLICY is not set
CONFIG_XFRM_MIGRATE=y
# CONFIG_XFRM_STATISTICS is not set
CONFIG_NET_KEY=y
CONFIG_NET_KEY_MIGRATE=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
# CONFIG_IP_ADVANCED_ROUTER is not set
CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
CONFIG_IP_PNP_BOOTP=y
CONFIG_IP_PNP_RARP=y
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE_DEMUX is not set
# CONFIG_NET_IP_TUNNEL is not set
# CONFIG_IP_MROUTE is not set
# CONFIG_ARPD is not set
# CONFIG_SYN_COOKIES is not set
# CONFIG_NET_IPVTI is not set
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
# CONFIG_INET_IPCOMP is not set
# CONFIG_INET_XFRM_TUNNEL is not set
# CONFIG_INET_TUNNEL is not set
CONFIG_INET_XFRM_MODE_TRANSPORT=y
CONFIG_INET_XFRM_MODE_TUNNEL=y
CONFIG_INET_XFRM_MODE_BEET=y
# CONFIG_INET_LRO is not set
CONFIG_INET_DIAG=y
CONFIG_INET_TCP_DIAG=y
# CONFIG_INET_UDP_DIAG is not set
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_CUBIC=y
CONFIG_DEFAULT_TCP_CONG="cubic"
# CONFIG_TCP_MD5SIG is not set
# CONFIG_IPV6 is not set
# CONFIG_NETLABEL is not set
# CONFIG_NETWORK_SECMARK is not set
# CONFIG_NETWORK_PHY_TIMESTAMPING is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
CONFIG_NETFILTER_ADVANCED=y

#
# Core Netfilter Configuration
#
# CONFIG_NETFILTER_NETLINK_ACCT is not set
# CONFIG_NETFILTER_NETLINK_QUEUE is not set
# CONFIG_NETFILTER_NETLINK_LOG is not set
# CONFIG_NF_CONNTRACK is not set
# CONFIG_NETFILTER_XTABLES is not set
# CONFIG_IP_VS is not set

#
# IP: Netfilter Configuration
#
# CONFIG_NF_DEFRAG_IPV4 is not set
# CONFIG_IP_NF_IPTABLES is not set
# CONFIG_IP_NF_ARPTABLES is not set
# CONFIG_IP_DCCP is not set
# CONFIG_IP_SCTP is not set
# CONFIG_RDS is not set
# CONFIG_TIPC is not set
# CONFIG_ATM is not set
# CONFIG_L2TP is not set
# CONFIG_BRIDGE is not set
CONFIG_HAVE_NET_DSA=y
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_PHONET is not set
# CONFIG_IEEE802154 is not set
# CONFIG_NET_SCHED is not set
# CONFIG_DCB is not set
CONFIG_DNS_RESOLVER=y
# CONFIG_BATMAN_ADV is not set
# CONFIG_OPENVSWITCH is not set
# CONFIG_VSOCKETS is not set
# CONFIG_NETLINK_DIAG is not set
CONFIG_RPS=y
CONFIG_RFS_ACCEL=y
CONFIG_XPS=y
CONFIG_BQL=y
# CONFIG_BPF_JIT is not set

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_NET_TCPPROBE is not set
# CONFIG_NET_DROP_MONITOR is not set
# CONFIG_HAMRADIO is not set
CONFIG_CAN=m
CONFIG_CAN_RAW=m
CONFIG_CAN_BCM=m
CONFIG_CAN_GW=m

#
# CAN Device Drivers
#
# CONFIG_CAN_VCAN is not set
# CONFIG_CAN_SLCAN is not set
CONFIG_CAN_DEV=m
CONFIG_CAN_CALC_BITTIMING=y
# CONFIG_CAN_LEDS is not set
# CONFIG_CAN_AT91 is not set
# CONFIG_CAN_TI_HECC is not set
# CONFIG_CAN_MCP251X is not set
# CONFIG_CAN_GRCAN is not set
# CONFIG_CAN_SJA1000 is not set
CONFIG_CAN_C_CAN=m
CONFIG_CAN_C_CAN_PLATFORM=m
# CONFIG_CAN_CC770 is not set

#
# CAN USB interfaces
#
# CONFIG_CAN_EMS_USB is not set
# CONFIG_CAN_ESD_USB2 is not set
# CONFIG_CAN_KVASER_USB is not set
# CONFIG_CAN_PEAK_USB is not set
# CONFIG_CAN_8DEV_USB is not set
# CONFIG_CAN_SOFTING is not set
# CONFIG_CAN_DEBUG_DEVICES is not set
# CONFIG_IRDA is not set
CONFIG_BT=m
# CONFIG_BT_RFCOMM is not set
# CONFIG_BT_BNEP is not set
# CONFIG_BT_HIDP is not set

#
# Bluetooth device drivers
#
# CONFIG_BT_HCIBTUSB is not set
# CONFIG_BT_HCIBTSDIO is not set
CONFIG_BT_HCIUART=m
CONFIG_BT_HCIUART_H4=y
CONFIG_BT_HCIUART_BCSP=y
# CONFIG_BT_HCIUART_ATH3K is not set
CONFIG_BT_HCIUART_LL=y
# CONFIG_BT_HCIUART_3WIRE is not set
CONFIG_BT_HCIBCM203X=m
CONFIG_BT_HCIBPA10X=m
# CONFIG_BT_HCIBFUSB is not set
# CONFIG_BT_HCIVHCI is not set
# CONFIG_BT_MRVL is not set
# CONFIG_AF_RXRPC is not set
CONFIG_WIRELESS=y
CONFIG_WIRELESS_EXT=y
CONFIG_WEXT_CORE=y
CONFIG_WEXT_PROC=y
CONFIG_WEXT_SPY=y
CONFIG_CFG80211=m
# CONFIG_NL80211_TESTMODE is not set
# CONFIG_CFG80211_DEVELOPER_WARNINGS is not set
# CONFIG_CFG80211_REG_DEBUG is not set
# CONFIG_CFG80211_CERTIFICATION_ONUS is not set
CONFIG_CFG80211_DEFAULT_PS=y
# CONFIG_CFG80211_DEBUGFS is not set
# CONFIG_CFG80211_INTERNAL_REGDB is not set
# CONFIG_CFG80211_WEXT is not set
CONFIG_LIB80211=m
# CONFIG_LIB80211_DEBUG is not set
CONFIG_MAC80211=m
CONFIG_MAC80211_HAS_RC=y
CONFIG_MAC80211_RC_PID=y
CONFIG_MAC80211_RC_MINSTREL=y
CONFIG_MAC80211_RC_MINSTREL_HT=y
CONFIG_MAC80211_RC_DEFAULT_PID=y
# CONFIG_MAC80211_RC_DEFAULT_MINSTREL is not set
CONFIG_MAC80211_RC_DEFAULT="pid"
# CONFIG_MAC80211_MESH is not set
# CONFIG_MAC80211_LEDS is not set
# CONFIG_MAC80211_DEBUGFS is not set
# CONFIG_MAC80211_MESSAGE_TRACING is not set
# CONFIG_MAC80211_DEBUG_MENU is not set
# CONFIG_WIMAX is not set
# CONFIG_RFKILL is not set
# CONFIG_RFKILL_REGULATOR is not set
# CONFIG_NET_9P is not set
# CONFIG_CAIF is not set
# CONFIG_CEPH_LIB is not set
# CONFIG_NFC is not set
CONFIG_HAVE_BPF_JIT=y

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
CONFIG_FIRMWARE_IN_KERNEL=y
CONFIG_EXTRA_FIRMWARE=""
CONFIG_FW_LOADER_USER_HELPER=y
# CONFIG_DEBUG_DRIVER is not set
# CONFIG_DEBUG_DEVRES is not set
# CONFIG_SYS_HYPERVISOR is not set
# CONFIG_GENERIC_CPU_DEVICES is not set
CONFIG_SOC_BUS=y
CONFIG_REGMAP=y
CONFIG_REGMAP_I2C=y
CONFIG_REGMAP_SPI=m
CONFIG_REGMAP_IRQ=y
# CONFIG_DMA_SHARED_BUFFER is not set
CONFIG_CMA=y
# CONFIG_CMA_DEBUG is not set

#
# Default contiguous memory area size:
#
CONFIG_CMA_SIZE_MBYTES=16
CONFIG_CMA_SIZE_SEL_MBYTES=y
# CONFIG_CMA_SIZE_SEL_PERCENTAGE is not set
# CONFIG_CMA_SIZE_SEL_MIN is not set
# CONFIG_CMA_SIZE_SEL_MAX is not set
CONFIG_CMA_ALIGNMENT=8
CONFIG_CMA_AREAS=7

#
# Bus devices
#
CONFIG_OMAP_OCP2SCP=y
CONFIG_OMAP_INTERCONNECT=y
CONFIG_CONNECTOR=y
CONFIG_PROC_EVENTS=y
CONFIG_MTD=y
# CONFIG_MTD_TESTS is not set
# CONFIG_MTD_REDBOOT_PARTS is not set
CONFIG_MTD_CMDLINE_PARTS=y
# CONFIG_MTD_AFS_PARTS is not set
CONFIG_MTD_OF_PARTS=y
# CONFIG_MTD_AR7_PARTS is not set

#
# User Modules And Translation Layers
#
CONFIG_MTD_BLKDEVS=y
CONFIG_MTD_BLOCK=y
# CONFIG_FTL is not set
# CONFIG_NFTL is not set
# CONFIG_INFTL is not set
# CONFIG_RFD_FTL is not set
# CONFIG_SSFDC is not set
# CONFIG_SM_FTL is not set
CONFIG_MTD_OOPS=y
# CONFIG_MTD_SWAP is not set

#
# RAM/ROM/Flash chip drivers
#
CONFIG_MTD_CFI=y
# CONFIG_MTD_JEDECPROBE is not set
CONFIG_MTD_GEN_PROBE=y
# CONFIG_MTD_CFI_ADV_OPTIONS is not set
CONFIG_MTD_MAP_BANK_WIDTH_1=y
CONFIG_MTD_MAP_BANK_WIDTH_2=y
CONFIG_MTD_MAP_BANK_WIDTH_4=y
# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set
CONFIG_MTD_CFI_I1=y
CONFIG_MTD_CFI_I2=y
# CONFIG_MTD_CFI_I4 is not set
# CONFIG_MTD_CFI_I8 is not set
CONFIG_MTD_CFI_INTELEXT=y
# CONFIG_MTD_CFI_AMDSTD is not set
# CONFIG_MTD_CFI_STAA is not set
CONFIG_MTD_CFI_UTIL=y
# CONFIG_MTD_RAM is not set
# CONFIG_MTD_ROM is not set
# CONFIG_MTD_ABSENT is not set

#
# Mapping drivers for chip access
#
# CONFIG_MTD_COMPLEX_MAPPINGS is not set
# CONFIG_MTD_PHYSMAP is not set
# CONFIG_MTD_PHYSMAP_OF is not set
# CONFIG_MTD_PLATRAM is not set

#
# Self-contained MTD device drivers
#
# CONFIG_MTD_DATAFLASH is not set
# CONFIG_MTD_M25P80 is not set
# CONFIG_MTD_SST25L is not set
# CONFIG_MTD_SLRAM is not set
# CONFIG_MTD_PHRAM is not set
# CONFIG_MTD_MTDRAM is not set
# CONFIG_MTD_BLOCK2MTD is not set

#
# Disk-On-Chip Device Drivers
#
# CONFIG_MTD_DOCG3 is not set
CONFIG_MTD_NAND_ECC=y
# CONFIG_MTD_NAND_ECC_SMC is not set
CONFIG_MTD_NAND=y
# CONFIG_MTD_NAND_ECC_BCH is not set
# CONFIG_MTD_SM_COMMON is not set
# CONFIG_MTD_NAND_DENALI is not set
# CONFIG_MTD_NAND_GPIO is not set
CONFIG_MTD_NAND_OMAP2=y
# CONFIG_MTD_NAND_OMAP_BCH is not set
CONFIG_MTD_NAND_IDS=y
# CONFIG_MTD_NAND_DISKONCHIP is not set
# CONFIG_MTD_NAND_DOCG4 is not set
# CONFIG_MTD_NAND_NANDSIM is not set
# CONFIG_MTD_NAND_PLATFORM is not set
# CONFIG_MTD_ALAUDA is not set
CONFIG_MTD_ONENAND=y
CONFIG_MTD_ONENAND_VERIFY_WRITE=y
# CONFIG_MTD_ONENAND_GENERIC is not set
CONFIG_MTD_ONENAND_OMAP2=y
# CONFIG_MTD_ONENAND_OTP is not set
# CONFIG_MTD_ONENAND_2X_PROGRAM is not set

#
# LPDDR flash memory drivers
#
# CONFIG_MTD_LPDDR is not set
CONFIG_MTD_UBI=y
CONFIG_MTD_UBI_WL_THRESHOLD=4096
CONFIG_MTD_UBI_BEB_LIMIT=20
# CONFIG_MTD_UBI_FASTMAP is not set
# CONFIG_MTD_UBI_GLUEBI is not set
CONFIG_DTC=y
CONFIG_OF=y

#
# Device Tree and Open Firmware support
#
CONFIG_PROC_DEVICETREE=y
# CONFIG_OF_SELFTEST is not set
CONFIG_OF_FLATTREE=y
CONFIG_OF_EARLY_FLATTREE=y
CONFIG_OF_ADDRESS=y
CONFIG_OF_IRQ=y
CONFIG_OF_DEVICE=y
CONFIG_OF_I2C=y
CONFIG_OF_NET=y
CONFIG_OF_MDIO=y
CONFIG_OF_MTD=y
# CONFIG_PARPORT is not set
CONFIG_BLK_DEV=y
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_LOOP_MIN_COUNT=8
# CONFIG_BLK_DEV_CRYPTOLOOP is not set
# CONFIG_BLK_DEV_DRBD is not set
# CONFIG_BLK_DEV_NBD is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=16384
# CONFIG_BLK_DEV_XIP is not set
# CONFIG_CDROM_PKTCDVD is not set
# CONFIG_ATA_OVER_ETH is not set
# CONFIG_MG_DISK is not set
# CONFIG_BLK_DEV_RBD is not set
# CONFIG_BLOCKCONSOLE is not set

#
# Misc devices
#
CONFIG_SENSORS_LIS3LV02D=m
# CONFIG_AD525X_DPOT is not set
# CONFIG_ATMEL_PWM is not set
# CONFIG_DUMMY_IRQ is not set
# CONFIG_ICS932S401 is not set
# CONFIG_ATMEL_SSC is not set
# CONFIG_ENCLOSURE_SERVICES is not set
# CONFIG_APDS9802ALS is not set
# CONFIG_ISL29003 is not set
# CONFIG_ISL29020 is not set
CONFIG_SENSORS_TSL2550=m
# CONFIG_SENSORS_BH1780 is not set
# CONFIG_SENSORS_BH1770 is not set
# CONFIG_SENSORS_APDS990X is not set
# CONFIG_HMC6352 is not set
# CONFIG_DS1682 is not set
# CONFIG_TI_DAC7512 is not set
# CONFIG_ARM_CHARLCD is not set
CONFIG_BMP085=y
CONFIG_BMP085_I2C=m
# CONFIG_BMP085_SPI is not set
# CONFIG_USB_SWITCH_FSA9480 is not set
# CONFIG_LATTICE_ECP3_CONFIG is not set
# CONFIG_SRAM is not set
# CONFIG_C2PORT is not set

#
# EEPROM support
#
# CONFIG_EEPROM_AT24 is not set
# CONFIG_EEPROM_AT25 is not set
# CONFIG_EEPROM_LEGACY is not set
# CONFIG_EEPROM_MAX6875 is not set
CONFIG_EEPROM_93CX6=y
# CONFIG_EEPROM_93XX46 is not set

#
# Texas Instruments shared transport line discipline
#
# CONFIG_TI_ST is not set
# CONFIG_SENSORS_LIS3_SPI is not set
CONFIG_SENSORS_LIS3_I2C=m

#
# Altera FPGA firmware download module
#
# CONFIG_ALTERA_STAPL is not set

#
# SCSI device support
#
CONFIG_SCSI_MOD=y
# CONFIG_RAID_ATTRS is not set
CONFIG_SCSI=y
CONFIG_SCSI_DMA=y
# CONFIG_SCSI_TGT is not set
# CONFIG_SCSI_NETLINK is not set
CONFIG_SCSI_PROC_FS=y

#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=y
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
# CONFIG_BLK_DEV_SR is not set
# CONFIG_CHR_DEV_SG is not set
# CONFIG_CHR_DEV_SCH is not set
CONFIG_SCSI_MULTI_LUN=y
# CONFIG_SCSI_CONSTANTS is not set
# CONFIG_SCSI_LOGGING is not set
CONFIG_SCSI_SCAN_ASYNC=y

#
# SCSI Transports
#
# CONFIG_SCSI_SPI_ATTRS is not set
# CONFIG_SCSI_FC_ATTRS is not set
# CONFIG_SCSI_ISCSI_ATTRS is not set
# CONFIG_SCSI_SAS_ATTRS is not set
# CONFIG_SCSI_SAS_LIBSAS is not set
# CONFIG_SCSI_SRP_ATTRS is not set
CONFIG_SCSI_LOWLEVEL=y
# CONFIG_ISCSI_TCP is not set
# CONFIG_ISCSI_BOOT_SYSFS is not set
# CONFIG_SCSI_UFSHCD is not set
# CONFIG_LIBFC is not set
# CONFIG_LIBFCOE is not set
# CONFIG_SCSI_DEBUG is not set
# CONFIG_SCSI_DH is not set
# CONFIG_SCSI_OSD_INITIATOR is not set
CONFIG_HAVE_PATA_PLATFORM=y
# CONFIG_ATA is not set
CONFIG_MD=y
# CONFIG_BLK_DEV_MD is not set
# CONFIG_BCACHE is not set
# CONFIG_BLK_DEV_DM is not set
# CONFIG_TARGET_CORE is not set
CONFIG_NETDEVICES=y
CONFIG_NET_CORE=y
# CONFIG_BONDING is not set
# CONFIG_DUMMY is not set
# CONFIG_EQUALIZER is not set
CONFIG_MII=y
# CONFIG_NET_TEAM is not set
# CONFIG_MACVLAN is not set
# CONFIG_VXLAN is not set
# CONFIG_NETCONSOLE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set
# CONFIG_TUN is not set
# CONFIG_VETH is not set

#
# CAIF transport drivers
#

#
# Distributed Switch Architecture drivers
#
# CONFIG_NET_DSA_MV88E6XXX is not set
# CONFIG_NET_DSA_MV88E6060 is not set
# CONFIG_NET_DSA_MV88E6XXX_NEED_PPU is not set
# CONFIG_NET_DSA_MV88E6131 is not set
# CONFIG_NET_DSA_MV88E6123_61_65 is not set
CONFIG_ETHERNET=y
CONFIG_NET_CADENCE=y
# CONFIG_ARM_AT91_ETHER is not set
# CONFIG_MACB is not set
CONFIG_NET_VENDOR_BROADCOM=y
# CONFIG_B44 is not set
# CONFIG_NET_CALXEDA_XGMAC is not set
CONFIG_NET_VENDOR_CIRRUS=y
# CONFIG_CS89x0 is not set
# CONFIG_DM9000 is not set
# CONFIG_DNET is not set
CONFIG_NET_VENDOR_FARADAY=y
# CONFIG_FTMAC100 is not set
# CONFIG_FTGMAC100 is not set
CONFIG_NET_VENDOR_INTEL=y
CONFIG_NET_VENDOR_I825XX=y
CONFIG_NET_VENDOR_MARVELL=y
# CONFIG_MVMDIO is not set
CONFIG_NET_VENDOR_MICREL=y
# CONFIG_KS8842 is not set
CONFIG_KS8851=y
CONFIG_KS8851_MLL=y
CONFIG_NET_VENDOR_MICROCHIP=y
# CONFIG_ENC28J60 is not set
CONFIG_NET_VENDOR_NATSEMI=y
CONFIG_NET_VENDOR_8390=y
# CONFIG_AX88796 is not set
# CONFIG_ETHOC is not set
CONFIG_NET_VENDOR_SEEQ=y
CONFIG_NET_VENDOR_SMSC=y
CONFIG_SMC91X=y
# CONFIG_SMC911X is not set
CONFIG_SMSC911X=y
# CONFIG_SMSC911X_ARCH_HOOKS is not set
CONFIG_NET_VENDOR_STMICRO=y
# CONFIG_STMMAC_ETH is not set
CONFIG_NET_VENDOR_TI=y
# CONFIG_TI_DAVINCI_EMAC is not set
CONFIG_TI_DAVINCI_MDIO=y
CONFIG_TI_DAVINCI_CPDMA=y
CONFIG_TI_CPSW=y
# CONFIG_TI_CPTS is not set
CONFIG_NET_VENDOR_WIZNET=y
# CONFIG_WIZNET_W5100 is not set
# CONFIG_WIZNET_W5300 is not set
CONFIG_PHYLIB=y

#
# MII PHY device drivers
#
# CONFIG_AT803X_PHY is not set
# CONFIG_AMD_PHY is not set
# CONFIG_MARVELL_PHY is not set
# CONFIG_DAVICOM_PHY is not set
# CONFIG_QSEMI_PHY is not set
# CONFIG_LXT_PHY is not set
# CONFIG_CICADA_PHY is not set
# CONFIG_VITESSE_PHY is not set
CONFIG_SMSC_PHY=y
# CONFIG_BROADCOM_PHY is not set
# CONFIG_BCM87XX_PHY is not set
# CONFIG_ICPLUS_PHY is not set
# CONFIG_REALTEK_PHY is not set
# CONFIG_NATIONAL_PHY is not set
# CONFIG_STE10XP is not set
# CONFIG_LSI_ET1011C_PHY is not set
# CONFIG_MICREL_PHY is not set
# CONFIG_FIXED_PHY is not set
# CONFIG_MDIO_BITBANG is not set
# CONFIG_MDIO_BUS_MUX_GPIO is not set
# CONFIG_MDIO_BUS_MUX_MMIOREG is not set
# CONFIG_MICREL_KS8995MA is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set

#
# USB Network Adapters
#
# CONFIG_USB_CATC is not set
# CONFIG_USB_KAWETH is not set
# CONFIG_USB_PEGASUS is not set
# CONFIG_USB_RTL8150 is not set
CONFIG_USB_USBNET=y
CONFIG_USB_NET_AX8817X=y
CONFIG_USB_NET_AX88179_178A=y
CONFIG_USB_NET_CDCETHER=y
# CONFIG_USB_NET_CDC_EEM is not set
CONFIG_USB_NET_CDC_NCM=y
# CONFIG_USB_NET_CDC_MBIM is not set
# CONFIG_USB_NET_DM9601 is not set
# CONFIG_USB_NET_SMSC75XX is not set
CONFIG_USB_NET_SMSC95XX=y
# CONFIG_USB_NET_GL620A is not set
CONFIG_USB_NET_NET1080=y
# CONFIG_USB_NET_PLUSB is not set
# CONFIG_USB_NET_MCS7830 is not set
# CONFIG_USB_NET_RNDIS_HOST is not set
CONFIG_USB_NET_CDC_SUBSET=y
CONFIG_USB_ALI_M5632=y
CONFIG_USB_AN2720=y
CONFIG_USB_BELKIN=y
CONFIG_USB_ARMLINUX=y
CONFIG_USB_EPSON2888=y
CONFIG_USB_KC2190=y
CONFIG_USB_NET_ZAURUS=y
# CONFIG_USB_NET_CX82310_ETH is not set
# CONFIG_USB_NET_KALMIA is not set
# CONFIG_USB_NET_QMI_WWAN is not set
# CONFIG_USB_NET_INT51X1 is not set
# CONFIG_USB_IPHETH is not set
# CONFIG_USB_SIERRA_NET is not set
# CONFIG_USB_VL600 is not set
CONFIG_WLAN=y
# CONFIG_LIBERTAS_THINFIRM is not set
# CONFIG_AT76C50X_USB is not set
# CONFIG_USB_ZD1201 is not set
# CONFIG_USB_NET_RNDIS_WLAN is not set
# CONFIG_RTL8187 is not set
# CONFIG_MAC80211_HWSIM is not set
# CONFIG_ATH_CARDS is not set
# CONFIG_B43 is not set
# CONFIG_B43LEGACY is not set
# CONFIG_BRCMFMAC is not set
# CONFIG_HOSTAP is not set
CONFIG_LIBERTAS=m
CONFIG_LIBERTAS_USB=m
CONFIG_LIBERTAS_SDIO=m
# CONFIG_LIBERTAS_SPI is not set
CONFIG_LIBERTAS_DEBUG=y
# CONFIG_LIBERTAS_MESH is not set
# CONFIG_P54_COMMON is not set
# CONFIG_RT2X00 is not set
# CONFIG_RTLWIFI is not set
# CONFIG_WL_TI is not set
# CONFIG_ZD1211RW is not set
# CONFIG_MWIFIEX is not set

#
# Enable WiMAX (Networking options) to see the WiMAX drivers
#
# CONFIG_WAN is not set
# CONFIG_ISDN is not set

#
# Input device support
#
CONFIG_INPUT=y
# CONFIG_INPUT_FF_MEMLESS is not set
CONFIG_INPUT_POLLDEV=m
# CONFIG_INPUT_SPARSEKMAP is not set
CONFIG_INPUT_MATRIXKMAP=y

#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
CONFIG_INPUT_JOYDEV=y
CONFIG_INPUT_EVDEV=y
# CONFIG_INPUT_EVBUG is not set

#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
# CONFIG_KEYBOARD_ADP5588 is not set
# CONFIG_KEYBOARD_ADP5589 is not set
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_KEYBOARD_QT1070 is not set
# CONFIG_KEYBOARD_QT2160 is not set
# CONFIG_KEYBOARD_LKKBD is not set
CONFIG_KEYBOARD_GPIO=y
# CONFIG_KEYBOARD_TCA6416 is not set
# CONFIG_KEYBOARD_TCA8418 is not set
CONFIG_KEYBOARD_MATRIX=m
# CONFIG_KEYBOARD_LM8323 is not set
# CONFIG_KEYBOARD_LM8333 is not set
# CONFIG_KEYBOARD_MAX7359 is not set
# CONFIG_KEYBOARD_MCS is not set
# CONFIG_KEYBOARD_MPR121 is not set
# CONFIG_KEYBOARD_NEWTON is not set
# CONFIG_KEYBOARD_OPENCORES is not set
# CONFIG_KEYBOARD_SAMSUNG is not set
# CONFIG_KEYBOARD_STOWAWAY is not set
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_OMAP4 is not set
CONFIG_KEYBOARD_TWL4030=y
# CONFIG_KEYBOARD_XTKBD is not set
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
CONFIG_MOUSE_PS2_ALPS=y
CONFIG_MOUSE_PS2_LOGIPS2PP=y
CONFIG_MOUSE_PS2_SYNAPTICS=y
CONFIG_MOUSE_PS2_CYPRESS=y
CONFIG_MOUSE_PS2_TRACKPOINT=y
# CONFIG_MOUSE_PS2_ELANTECH is not set
# CONFIG_MOUSE_PS2_SENTELIC is not set
# CONFIG_MOUSE_PS2_TOUCHKIT is not set
# CONFIG_MOUSE_SERIAL is not set
# CONFIG_MOUSE_APPLETOUCH is not set
# CONFIG_MOUSE_BCM5974 is not set
# CONFIG_MOUSE_CYAPA is not set
# CONFIG_MOUSE_VSXXXAA is not set
# CONFIG_MOUSE_GPIO is not set
# CONFIG_MOUSE_SYNAPTICS_I2C is not set
# CONFIG_MOUSE_SYNAPTICS_USB is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TABLET is not set
CONFIG_INPUT_TOUCHSCREEN=y
CONFIG_TOUCHSCREEN_ADS7846=y
# CONFIG_TOUCHSCREEN_AD7877 is not set
# CONFIG_TOUCHSCREEN_AD7879 is not set
# CONFIG_TOUCHSCREEN_ATMEL_MXT is not set
# CONFIG_TOUCHSCREEN_AUO_PIXCIR is not set
# CONFIG_TOUCHSCREEN_BU21013 is not set
# CONFIG_TOUCHSCREEN_CY8CTMG110 is not set
# CONFIG_TOUCHSCREEN_CYTTSP_CORE is not set
# CONFIG_TOUCHSCREEN_DYNAPRO is not set
# CONFIG_TOUCHSCREEN_HAMPSHIRE is not set
# CONFIG_TOUCHSCREEN_EETI is not set
# CONFIG_TOUCHSCREEN_EGALAX is not set
# CONFIG_TOUCHSCREEN_FUJITSU is not set
# CONFIG_TOUCHSCREEN_ILI210X is not set
# CONFIG_TOUCHSCREEN_GUNZE is not set
# CONFIG_TOUCHSCREEN_ELO is not set
# CONFIG_TOUCHSCREEN_WACOM_W8001 is not set
# CONFIG_TOUCHSCREEN_WACOM_I2C is not set
# CONFIG_TOUCHSCREEN_MAX11801 is not set
# CONFIG_TOUCHSCREEN_MCS5000 is not set
# CONFIG_TOUCHSCREEN_MMS114 is not set
# CONFIG_TOUCHSCREEN_MTOUCH is not set
# CONFIG_TOUCHSCREEN_INEXIO is not set
# CONFIG_TOUCHSCREEN_MK712 is not set
# CONFIG_TOUCHSCREEN_PENMOUNT is not set
# CONFIG_TOUCHSCREEN_EDT_FT5X06 is not set
# CONFIG_TOUCHSCREEN_TOUCHRIGHT is not set
# CONFIG_TOUCHSCREEN_TOUCHWIN is not set
# CONFIG_TOUCHSCREEN_PIXCIR is not set
# CONFIG_TOUCHSCREEN_USB_COMPOSITE is not set
# CONFIG_TOUCHSCREEN_TOUCHIT213 is not set
# CONFIG_TOUCHSCREEN_TSC_SERIO is not set
# CONFIG_TOUCHSCREEN_TSC2005 is not set
# CONFIG_TOUCHSCREEN_TSC2007 is not set
# CONFIG_TOUCHSCREEN_W90X900 is not set
# CONFIG_TOUCHSCREEN_ST1232 is not set
# CONFIG_TOUCHSCREEN_TPS6507X is not set
CONFIG_INPUT_MISC=y
# CONFIG_INPUT_AD714X is not set
# CONFIG_INPUT_BMA150 is not set
# CONFIG_INPUT_MMA8450 is not set
# CONFIG_INPUT_MPU3050 is not set
# CONFIG_INPUT_GP2A is not set
# CONFIG_INPUT_GPIO_TILT_POLLED is not set
# CONFIG_INPUT_ATI_REMOTE2 is not set
# CONFIG_INPUT_KEYSPAN_REMOTE is not set
# CONFIG_INPUT_KXTJ9 is not set
# CONFIG_INPUT_POWERMATE is not set
# CONFIG_INPUT_YEALINK is not set
# CONFIG_INPUT_CM109 is not set
CONFIG_INPUT_TWL4030_PWRBUTTON=y
# CONFIG_INPUT_TWL4030_VIBRA is not set
# CONFIG_INPUT_UINPUT is not set
# CONFIG_INPUT_PCF8574 is not set
# CONFIG_INPUT_GPIO_ROTARY_ENCODER is not set
# CONFIG_INPUT_ADXL34X is not set
# CONFIG_INPUT_IMS_PCU is not set
# CONFIG_INPUT_CMA3000 is not set

#
# Hardware I/O ports
#
CONFIG_SERIO=y
CONFIG_SERIO_SERPORT=y
# CONFIG_SERIO_AMBAKMI is not set
CONFIG_SERIO_LIBPS2=y
# CONFIG_SERIO_RAW is not set
# CONFIG_SERIO_ALTERA_PS2 is not set
# CONFIG_SERIO_PS2MULT is not set
# CONFIG_SERIO_ARC_PS2 is not set
# CONFIG_SERIO_APBPS2 is not set
# CONFIG_GAMEPORT is not set

#
# Character devices
#
CONFIG_TTY=y
CONFIG_VT=y
CONFIG_CONSOLE_TRANSLATIONS=y
CONFIG_VT_CONSOLE=y
CONFIG_VT_CONSOLE_SLEEP=y
CONFIG_HW_CONSOLE=y
CONFIG_VT_HW_CONSOLE_BINDING=y
CONFIG_UNIX98_PTYS=y
# CONFIG_DEVPTS_MULTIPLE_INSTANCES is not set
# CONFIG_LEGACY_PTYS is not set
# CONFIG_SERIAL_NONSTANDARD is not set
# CONFIG_N_GSM is not set
# CONFIG_TRACE_SINK is not set
CONFIG_DEVKMEM=y

#
# Serial drivers
#
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_DEPRECATED_OPTIONS=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_8250_DMA=y
CONFIG_SERIAL_8250_NR_UARTS=32
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
CONFIG_SERIAL_8250_EXTENDED=y
CONFIG_SERIAL_8250_MANY_PORTS=y
CONFIG_SERIAL_8250_SHARE_IRQ=y
CONFIG_SERIAL_8250_DETECT_IRQ=y
CONFIG_SERIAL_8250_RSA=y
# CONFIG_SERIAL_8250_DW is not set
# CONFIG_SERIAL_8250_EM is not set

#
# Non-8250 serial port support
#
# CONFIG_SERIAL_AMBA_PL010 is not set
CONFIG_SERIAL_AMBA_PL011=y
CONFIG_SERIAL_AMBA_PL011_CONSOLE=y
# CONFIG_SERIAL_MAX3100 is not set
# CONFIG_SERIAL_MAX310X is not set
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
# CONFIG_SERIAL_OF_PLATFORM is not set
CONFIG_SERIAL_OMAP=y
CONFIG_SERIAL_OMAP_CONSOLE=y
# CONFIG_SERIAL_SCCNXP is not set
# CONFIG_SERIAL_TIMBERDALE is not set
# CONFIG_SERIAL_ALTERA_JTAGUART is not set
# CONFIG_SERIAL_ALTERA_UART is not set
# CONFIG_SERIAL_IFX6X60 is not set
# CONFIG_SERIAL_XILINX_PS_UART is not set
# CONFIG_SERIAL_ARC is not set
# CONFIG_TTY_PRINTK is not set
# CONFIG_HVC_DCC is not set
# CONFIG_IPMI_HANDLER is not set
CONFIG_HW_RANDOM=y
# CONFIG_HW_RANDOM_TIMERIOMEM is not set
# CONFIG_HW_RANDOM_ATMEL is not set
CONFIG_HW_RANDOM_OMAP=y
# CONFIG_HW_RANDOM_EXYNOS is not set
# CONFIG_R3964 is not set
# CONFIG_RAW_DRIVER is not set
# CONFIG_TCG_TPM is not set
CONFIG_I2C=y
CONFIG_I2C_BOARDINFO=y
CONFIG_I2C_COMPAT=y
CONFIG_I2C_CHARDEV=y
# CONFIG_I2C_MUX is not set
CONFIG_I2C_HELPER_AUTO=y

#
# I2C Hardware Bus support
#

#
# I2C system bus drivers (mostly embedded / system-on-chip)
#
# CONFIG_I2C_CBUS_GPIO is not set
# CONFIG_I2C_DESIGNWARE_PLATFORM is not set
# CONFIG_I2C_GPIO is not set
# CONFIG_I2C_NOMADIK is not set
# CONFIG_I2C_OCORES is not set
CONFIG_I2C_OMAP=y
# CONFIG_I2C_PCA_PLATFORM is not set
# CONFIG_I2C_PXA_PCI is not set
# CONFIG_I2C_SIMTEC is not set
# CONFIG_I2C_VERSATILE is not set
# CONFIG_I2C_XILINX is not set

#
# External I2C/SMBus adapter drivers
#
# CONFIG_I2C_DIOLAN_U2C is not set
# CONFIG_I2C_PARPORT_LIGHT is not set
# CONFIG_I2C_TAOS_EVM is not set
# CONFIG_I2C_TINY_USB is not set

#
# Other I2C/SMBus bus drivers
#
# CONFIG_I2C_STUB is not set
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
CONFIG_SPI=y
# CONFIG_SPI_DEBUG is not set
CONFIG_SPI_MASTER=y

#
# SPI Master Controller Drivers
#
# CONFIG_SPI_ALTERA is not set
# CONFIG_SPI_BITBANG is not set
# CONFIG_SPI_GPIO is not set
# CONFIG_SPI_FSL_SPI is not set
# CONFIG_SPI_OC_TINY is not set
CONFIG_SPI_OMAP24XX=y
# CONFIG_SPI_PL022 is not set
# CONFIG_SPI_PXA2XX_PCI is not set
# CONFIG_SPI_SC18IS602 is not set
# CONFIG_SPI_XCOMM is not set
# CONFIG_SPI_XILINX is not set
# CONFIG_SPI_DESIGNWARE is not set

#
# SPI Protocol Masters
#
# CONFIG_SPI_SPIDEV is not set
# CONFIG_SPI_TLE62X0 is not set

#
# Qualcomm MSM SSBI bus support
#
# CONFIG_SSBI is not set
# CONFIG_HSI is not set

#
# PPS support
#
# CONFIG_PPS is not set

#
# PPS generators support
#

#
# PTP clock support
#
# CONFIG_PTP_1588_CLOCK is not set

#
# Enable PHYLIB and NETWORK_PHY_TIMESTAMPING to see the additional clocks.
#
# CONFIG_PTP_1588_CLOCK_PCH is not set
CONFIG_PINCTRL=y

#
# Pin controllers
#
CONFIG_PINMUX=y
CONFIG_PINCONF=y
CONFIG_GENERIC_PINCONF=y
# CONFIG_DEBUG_PINCTRL is not set
CONFIG_PINCTRL_SINGLE=y
# CONFIG_PINCTRL_EXYNOS is not set
# CONFIG_PINCTRL_EXYNOS5440 is not set
CONFIG_ARCH_HAVE_CUSTOM_GPIO_H=y
CONFIG_ARCH_REQUIRE_GPIOLIB=y
CONFIG_GPIO_DEVRES=y
CONFIG_GPIOLIB=y
CONFIG_OF_GPIO=y
CONFIG_DEBUG_GPIO=y
CONFIG_GPIO_SYSFS=y

#
# Memory mapped GPIO drivers:
#
# CONFIG_GPIO_GENERIC_PLATFORM is not set
# CONFIG_GPIO_EM is not set
# CONFIG_GPIO_PL061 is not set
# CONFIG_GPIO_RCAR is not set
# CONFIG_GPIO_TS5500 is not set

#
# I2C GPIO expanders:
#
# CONFIG_GPIO_MAX7300 is not set
# CONFIG_GPIO_MAX732X is not set
# CONFIG_GPIO_PCF857X is not set
# CONFIG_GPIO_SX150X is not set
CONFIG_GPIO_TWL4030=y
# CONFIG_GPIO_ADP5588 is not set
# CONFIG_GPIO_ADNP is not set

#
# PCI GPIO expanders:
#

#
# SPI GPIO expanders:
#
# CONFIG_GPIO_MAX7301 is not set
# CONFIG_GPIO_MCP23S08 is not set
# CONFIG_GPIO_MC33880 is not set
# CONFIG_GPIO_74X164 is not set

#
# AC97 GPIO expanders:
#

#
# MODULbus GPIO expanders:
#
# CONFIG_GPIO_TPS65910 is not set

#
# USB GPIO expanders:
#
CONFIG_W1=y
CONFIG_W1_CON=y

#
# 1-wire Bus Masters
#
# CONFIG_W1_MASTER_DS2490 is not set
# CONFIG_W1_MASTER_DS2482 is not set
# CONFIG_W1_MASTER_DS1WM is not set
# CONFIG_W1_MASTER_GPIO is not set
# CONFIG_HDQ_MASTER_OMAP is not set

#
# 1-wire Slaves
#
# CONFIG_W1_SLAVE_THERM is not set
# CONFIG_W1_SLAVE_SMEM is not set
# CONFIG_W1_SLAVE_DS2408 is not set
# CONFIG_W1_SLAVE_DS2413 is not set
# CONFIG_W1_SLAVE_DS2423 is not set
# CONFIG_W1_SLAVE_DS2431 is not set
# CONFIG_W1_SLAVE_DS2433 is not set
# CONFIG_W1_SLAVE_DS2760 is not set
# CONFIG_W1_SLAVE_DS2780 is not set
# CONFIG_W1_SLAVE_DS2781 is not set
# CONFIG_W1_SLAVE_DS28E04 is not set
# CONFIG_W1_SLAVE_BQ27000 is not set
CONFIG_POWER_SUPPLY=y
# CONFIG_POWER_SUPPLY_DEBUG is not set
# CONFIG_PDA_POWER is not set
# CONFIG_TEST_POWER is not set
# CONFIG_BATTERY_DS2780 is not set
# CONFIG_BATTERY_DS2781 is not set
# CONFIG_BATTERY_DS2782 is not set
# CONFIG_BATTERY_SBS is not set
# CONFIG_BATTERY_BQ27x00 is not set
# CONFIG_BATTERY_MAX17040 is not set
# CONFIG_BATTERY_MAX17042 is not set
# CONFIG_CHARGER_ISP1704 is not set
# CONFIG_CHARGER_MAX8903 is not set
# CONFIG_CHARGER_TWL4030 is not set
# CONFIG_CHARGER_LP8727 is not set
# CONFIG_CHARGER_GPIO is not set
# CONFIG_CHARGER_MANAGER is not set
# CONFIG_CHARGER_BQ2415X is not set
# CONFIG_CHARGER_SMB347 is not set
# CONFIG_BATTERY_GOLDFISH is not set
CONFIG_POWER_RESET=y
# CONFIG_POWER_RESET_GPIO is not set
# CONFIG_POWER_RESET_RESTART is not set
CONFIG_POWER_RESET_VEXPRESS=y
# CONFIG_POWER_AVS is not set
CONFIG_HWMON=y
# CONFIG_HWMON_VID is not set
# CONFIG_HWMON_DEBUG_CHIP is not set

#
# Native drivers
#
# CONFIG_SENSORS_AD7314 is not set
# CONFIG_SENSORS_AD7414 is not set
# CONFIG_SENSORS_AD7418 is not set
# CONFIG_SENSORS_ADCXX is not set
# CONFIG_SENSORS_ADM1021 is not set
# CONFIG_SENSORS_ADM1025 is not set
# CONFIG_SENSORS_ADM1026 is not set
# CONFIG_SENSORS_ADM1029 is not set
# CONFIG_SENSORS_ADM1031 is not set
# CONFIG_SENSORS_ADM9240 is not set
# CONFIG_SENSORS_ADT7310 is not set
# CONFIG_SENSORS_ADT7410 is not set
# CONFIG_SENSORS_ADT7411 is not set
# CONFIG_SENSORS_ADT7462 is not set
# CONFIG_SENSORS_ADT7470 is not set
# CONFIG_SENSORS_ADT7475 is not set
# CONFIG_SENSORS_ASC7621 is not set
# CONFIG_SENSORS_ATXP1 is not set
# CONFIG_SENSORS_DS620 is not set
# CONFIG_SENSORS_DS1621 is not set
# CONFIG_SENSORS_F71805F is not set
# CONFIG_SENSORS_F71882FG is not set
# CONFIG_SENSORS_F75375S is not set
# CONFIG_SENSORS_G760A is not set
# CONFIG_SENSORS_GL518SM is not set
# CONFIG_SENSORS_GL520SM is not set
# CONFIG_SENSORS_GPIO_FAN is not set
# CONFIG_SENSORS_HIH6130 is not set
# CONFIG_SENSORS_IT87 is not set
# CONFIG_SENSORS_JC42 is not set
# CONFIG_SENSORS_LINEAGE is not set
# CONFIG_SENSORS_LM63 is not set
# CONFIG_SENSORS_LM70 is not set
# CONFIG_SENSORS_LM73 is not set
CONFIG_SENSORS_LM75=m
# CONFIG_SENSORS_LM77 is not set
# CONFIG_SENSORS_LM78 is not set
# CONFIG_SENSORS_LM80 is not set
# CONFIG_SENSORS_LM83 is not set
# CONFIG_SENSORS_LM85 is not set
# CONFIG_SENSORS_LM87 is not set
# CONFIG_SENSORS_LM90 is not set
# CONFIG_SENSORS_LM92 is not set
# CONFIG_SENSORS_LM93 is not set
# CONFIG_SENSORS_LTC4151 is not set
# CONFIG_SENSORS_LTC4215 is not set
# CONFIG_SENSORS_LTC4245 is not set
# CONFIG_SENSORS_LTC4261 is not set
# CONFIG_SENSORS_LM95234 is not set
# CONFIG_SENSORS_LM95241 is not set
# CONFIG_SENSORS_LM95245 is not set
# CONFIG_SENSORS_MAX1111 is not set
# CONFIG_SENSORS_MAX16065 is not set
# CONFIG_SENSORS_MAX1619 is not set
# CONFIG_SENSORS_MAX1668 is not set
# CONFIG_SENSORS_MAX197 is not set
# CONFIG_SENSORS_MAX6639 is not set
# CONFIG_SENSORS_MAX6642 is not set
# CONFIG_SENSORS_MAX6650 is not set
# CONFIG_SENSORS_MAX6697 is not set
# CONFIG_SENSORS_MCP3021 is not set
# CONFIG_SENSORS_NCT6775 is not set
# CONFIG_SENSORS_PC87360 is not set
# CONFIG_SENSORS_PC87427 is not set
# CONFIG_SENSORS_PCF8591 is not set
# CONFIG_PMBUS is not set
# CONFIG_SENSORS_SHT15 is not set
# CONFIG_SENSORS_SHT21 is not set
# CONFIG_SENSORS_SMM665 is not set
# CONFIG_SENSORS_DME1737 is not set
# CONFIG_SENSORS_EMC1403 is not set
# CONFIG_SENSORS_EMC2103 is not set
# CONFIG_SENSORS_EMC6W201 is not set
# CONFIG_SENSORS_SMSC47M1 is not set
# CONFIG_SENSORS_SMSC47M192 is not set
# CONFIG_SENSORS_SMSC47B397 is not set
# CONFIG_SENSORS_SCH56XX_COMMON is not set
# CONFIG_SENSORS_SCH5627 is not set
# CONFIG_SENSORS_SCH5636 is not set
# CONFIG_SENSORS_ADS1015 is not set
# CONFIG_SENSORS_ADS7828 is not set
# CONFIG_SENSORS_ADS7871 is not set
# CONFIG_SENSORS_AMC6821 is not set
# CONFIG_SENSORS_INA209 is not set
# CONFIG_SENSORS_INA2XX is not set
# CONFIG_SENSORS_THMC50 is not set
# CONFIG_SENSORS_TMP102 is not set
# CONFIG_SENSORS_TMP401 is not set
# CONFIG_SENSORS_TMP421 is not set
# CONFIG_SENSORS_VEXPRESS is not set
# CONFIG_SENSORS_VT1211 is not set
# CONFIG_SENSORS_W83781D is not set
# CONFIG_SENSORS_W83791D is not set
# CONFIG_SENSORS_W83792D is not set
# CONFIG_SENSORS_W83793 is not set
# CONFIG_SENSORS_W83795 is not set
# CONFIG_SENSORS_W83L785TS is not set
# CONFIG_SENSORS_W83L786NG is not set
# CONFIG_SENSORS_W83627HF is not set
# CONFIG_SENSORS_W83627EHF is not set
# CONFIG_THERMAL is not set
CONFIG_WATCHDOG=y
CONFIG_WATCHDOG_CORE=y
# CONFIG_WATCHDOG_NOWAYOUT is not set

#
# Watchdog Device Drivers
#
# CONFIG_SOFT_WATCHDOG is not set
# CONFIG_ARM_SP805_WATCHDOG is not set
# CONFIG_DW_WATCHDOG is not set
# CONFIG_MPCORE_WATCHDOG is not set
CONFIG_OMAP_WATCHDOG=y
CONFIG_TWL4030_WATCHDOG=y
# CONFIG_MAX63XX_WATCHDOG is not set

#
# USB-based Watchdog Cards
#
# CONFIG_USBPCWATCHDOG is not set
CONFIG_SSB_POSSIBLE=y

#
# Sonics Silicon Backplane
#
# CONFIG_SSB is not set
CONFIG_BCMA_POSSIBLE=y

#
# Broadcom specific AMBA
#
# CONFIG_BCMA is not set

#
# Multifunction device drivers
#
CONFIG_MFD_CORE=y
# CONFIG_MFD_AS3711 is not set
# CONFIG_PMIC_ADP5520 is not set
# CONFIG_MFD_AAT2870_CORE is not set
# CONFIG_MFD_CROS_EC is not set
# CONFIG_MFD_ASIC3 is not set
# CONFIG_PMIC_DA903X is not set
# CONFIG_MFD_DA9052_SPI is not set
# CONFIG_MFD_DA9052_I2C is not set
# CONFIG_MFD_DA9055 is not set
# CONFIG_MFD_MC13XXX_SPI is not set
# CONFIG_MFD_MC13XXX_I2C is not set
# CONFIG_HTC_EGPIO is not set
# CONFIG_HTC_PASIC3 is not set
# CONFIG_HTC_I2CPLD is not set
# CONFIG_MFD_88PM800 is not set
# CONFIG_MFD_88PM805 is not set
# CONFIG_MFD_88PM860X is not set
# CONFIG_MFD_MAX77686 is not set
# CONFIG_MFD_MAX77693 is not set
# CONFIG_MFD_MAX8907 is not set
# CONFIG_MFD_MAX8925 is not set
# CONFIG_MFD_MAX8997 is not set
# CONFIG_MFD_MAX8998 is not set
# CONFIG_EZX_PCAP is not set
# CONFIG_MFD_VIPERBOARD is not set
# CONFIG_MFD_RETU is not set
# CONFIG_MFD_PCF50633 is not set
# CONFIG_MFD_RC5T583 is not set
# CONFIG_MFD_SEC_CORE is not set
# CONFIG_MFD_SM501 is not set
# CONFIG_MFD_SMSC is not set
# CONFIG_ABX500_CORE is not set
# CONFIG_MFD_STMPE is not set
# CONFIG_MFD_SYSCON is not set
# CONFIG_MFD_TI_AM335X_TSCADC is not set
# CONFIG_MFD_LP8788 is not set
# CONFIG_MFD_PALMAS is not set
# CONFIG_TPS6105X is not set
# CONFIG_TPS65010 is not set
# CONFIG_TPS6507X is not set
# CONFIG_MFD_TPS65090 is not set
CONFIG_MFD_TPS65217=y
# CONFIG_MFD_TPS6586X is not set
CONFIG_MFD_TPS65910=y
# CONFIG_MFD_TPS65912 is not set
# CONFIG_MFD_TPS65912_I2C is not set
# CONFIG_MFD_TPS65912_SPI is not set
# CONFIG_MFD_TPS80031 is not set
CONFIG_TWL4030_CORE=y
# CONFIG_TWL4030_MADC is not set
CONFIG_TWL4030_POWER=y
CONFIG_MFD_TWL4030_AUDIO=y
# CONFIG_TWL6040_CORE is not set
CONFIG_MENELAUS=y
# CONFIG_MFD_WL1273_CORE is not set
# CONFIG_MFD_SI476X_CORE is not set
# CONFIG_MFD_LM3533 is not set
# CONFIG_MFD_TC3589X is not set
# CONFIG_MFD_TMIO is not set
# CONFIG_MFD_T7L66XB is not set
# CONFIG_MFD_TC6387XB is not set
# CONFIG_MFD_TC6393XB is not set
# CONFIG_MFD_ARIZONA_I2C is not set
# CONFIG_MFD_ARIZONA_SPI is not set
# CONFIG_MFD_WM8400 is not set
# CONFIG_MFD_WM831X_I2C is not set
# CONFIG_MFD_WM831X_SPI is not set
# CONFIG_MFD_WM8350_I2C is not set
# CONFIG_MFD_WM8994 is not set
CONFIG_VEXPRESS_CONFIG=y
CONFIG_REGULATOR=y
# CONFIG_REGULATOR_DEBUG is not set
# CONFIG_REGULATOR_DUMMY is not set
CONFIG_REGULATOR_FIXED_VOLTAGE=y
# CONFIG_REGULATOR_VIRTUAL_CONSUMER is not set
# CONFIG_REGULATOR_USERSPACE_CONSUMER is not set
# CONFIG_REGULATOR_GPIO is not set
# CONFIG_REGULATOR_AD5398 is not set
# CONFIG_REGULATOR_FAN53555 is not set
# CONFIG_REGULATOR_ISL6271A is not set
# CONFIG_REGULATOR_MAX1586 is not set
# CONFIG_REGULATOR_MAX8649 is not set
# CONFIG_REGULATOR_MAX8660 is not set
# CONFIG_REGULATOR_MAX8952 is not set
# CONFIG_REGULATOR_MAX8973 is not set
# CONFIG_REGULATOR_LP3971 is not set
# CONFIG_REGULATOR_LP3972 is not set
# CONFIG_REGULATOR_LP872X is not set
# CONFIG_REGULATOR_LP8755 is not set
# CONFIG_REGULATOR_TPS51632 is not set
# CONFIG_REGULATOR_TPS62360 is not set
CONFIG_REGULATOR_TPS65023=y
CONFIG_REGULATOR_TPS6507X=y
CONFIG_REGULATOR_TPS65217=y
# CONFIG_REGULATOR_TPS6524X is not set
CONFIG_REGULATOR_TPS65910=y
CONFIG_REGULATOR_TWL4030=y
# CONFIG_REGULATOR_VEXPRESS is not set
# CONFIG_MEDIA_SUPPORT is not set

#
# Graphics support
#
# CONFIG_DRM is not set
# CONFIG_VGASTATE is not set
# CONFIG_VIDEO_OUTPUT_CONTROL is not set
CONFIG_FB=y
CONFIG_FIRMWARE_EDID=y
# CONFIG_FB_DDC is not set
# CONFIG_FB_BOOT_VESA_SUPPORT is not set
CONFIG_FB_CFB_FILLRECT=m
CONFIG_FB_CFB_COPYAREA=m
CONFIG_FB_CFB_IMAGEBLIT=m
# CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set
# CONFIG_FB_SYS_FILLRECT is not set
# CONFIG_FB_SYS_COPYAREA is not set
# CONFIG_FB_SYS_IMAGEBLIT is not set
# CONFIG_FB_FOREIGN_ENDIAN is not set
# CONFIG_FB_SYS_FOPS is not set
# CONFIG_FB_SVGALIB is not set
# CONFIG_FB_MACMODES is not set
# CONFIG_FB_BACKLIGHT is not set
CONFIG_FB_MODE_HELPERS=y
CONFIG_FB_TILEBLITTING=y

#
# Frame buffer hardware drivers
#
# CONFIG_FB_ARMCLCD is not set
# CONFIG_FB_UVESA is not set
# CONFIG_FB_S1D13XXX is not set
# CONFIG_FB_TMIO is not set
# CONFIG_FB_SMSCUFX is not set
# CONFIG_FB_UDL is not set
# CONFIG_FB_GOLDFISH is not set
# CONFIG_FB_VIRTUAL is not set
# CONFIG_FB_METRONOME is not set
# CONFIG_FB_BROADSHEET is not set
# CONFIG_FB_AUO_K190X is not set
# CONFIG_FB_SIMPLE is not set
CONFIG_OMAP2_VRFB=y
CONFIG_OMAP2_DSS=m
# CONFIG_OMAP2_DSS_DEBUG is not set
# CONFIG_OMAP2_DSS_DEBUGFS is not set
CONFIG_OMAP2_DSS_DPI=y
CONFIG_OMAP2_DSS_RFBI=y
CONFIG_OMAP2_DSS_VENC=y
CONFIG_OMAP4_DSS_HDMI=y
CONFIG_OMAP2_DSS_SDI=y
CONFIG_OMAP2_DSS_DSI=y
CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK=0
CONFIG_OMAP2_DSS_SLEEP_AFTER_VENC_RESET=y
CONFIG_FB_OMAP2=m
CONFIG_FB_OMAP2_DEBUG_SUPPORT=y
CONFIG_FB_OMAP2_NUM_FBS=3

#
# OMAP2/3 Display Device Drivers
#
CONFIG_PANEL_GENERIC_DPI=m
CONFIG_PANEL_TFP410=m
# CONFIG_PANEL_LGPHILIPS_LB035Q02 is not set
CONFIG_PANEL_SHARP_LS037V7DW01=m
CONFIG_PANEL_NEC_NL8048HL11_01B=m
# CONFIG_PANEL_PICODLP is not set
CONFIG_PANEL_TAAL=m
CONFIG_PANEL_TPO_TD043MTEA1=m
CONFIG_PANEL_ACX565AKM=m
# CONFIG_PANEL_N8X0 is not set
# CONFIG_EXYNOS_VIDEO is not set
CONFIG_BACKLIGHT_LCD_SUPPORT=y
CONFIG_LCD_CLASS_DEVICE=y
# CONFIG_LCD_L4F00242T03 is not set
# CONFIG_LCD_LMS283GF05 is not set
# CONFIG_LCD_LTV350QV is not set
# CONFIG_LCD_ILI922X is not set
# CONFIG_LCD_ILI9320 is not set
# CONFIG_LCD_TDO24M is not set
# CONFIG_LCD_VGG2432A4 is not set
CONFIG_LCD_PLATFORM=y
# CONFIG_LCD_S6E63M0 is not set
# CONFIG_LCD_LD9040 is not set
# CONFIG_LCD_AMS369FG06 is not set
# CONFIG_LCD_LMS501KF03 is not set
# CONFIG_LCD_HX8357 is not set
CONFIG_BACKLIGHT_CLASS_DEVICE=m
CONFIG_BACKLIGHT_GENERIC=m
# CONFIG_BACKLIGHT_ADP8860 is not set
# CONFIG_BACKLIGHT_ADP8870 is not set
# CONFIG_BACKLIGHT_LM3630 is not set
# CONFIG_BACKLIGHT_LM3639 is not set
# CONFIG_BACKLIGHT_LP855X is not set
# CONFIG_BACKLIGHT_PANDORA is not set
# CONFIG_BACKLIGHT_TPS65217 is not set

#
# Console display driver support
#
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
# CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY is not set
CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y
CONFIG_FONTS=y
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y
# CONFIG_FONT_6x11 is not set
# CONFIG_FONT_7x14 is not set
# CONFIG_FONT_PEARL_8x8 is not set
# CONFIG_FONT_ACORN_8x8 is not set
# CONFIG_FONT_MINI_4x6 is not set
# CONFIG_FONT_SUN8x16 is not set
# CONFIG_FONT_SUN12x22 is not set
# CONFIG_FONT_10x18 is not set
CONFIG_LOGO=y
CONFIG_LOGO_LINUX_MONO=y
CONFIG_LOGO_LINUX_VGA16=y
CONFIG_LOGO_LINUX_CLUT224=y
# CONFIG_FB_SSD1307 is not set
CONFIG_SOUND=m
CONFIG_SOUND_OSS_CORE=y
CONFIG_SOUND_OSS_CORE_PRECLAIM=y
CONFIG_SND=m
CONFIG_SND_TIMER=m
CONFIG_SND_PCM=m
CONFIG_SND_HWDEP=m
CONFIG_SND_RAWMIDI=m
CONFIG_SND_COMPRESS_OFFLOAD=m
CONFIG_SND_JACK=y
# CONFIG_SND_SEQUENCER is not set
CONFIG_SND_OSSEMUL=y
CONFIG_SND_MIXER_OSS=m
CONFIG_SND_PCM_OSS=m
CONFIG_SND_PCM_OSS_PLUGINS=y
# CONFIG_SND_HRTIMER is not set
# CONFIG_SND_DYNAMIC_MINORS is not set
CONFIG_SND_SUPPORT_OLD_API=y
CONFIG_SND_VERBOSE_PROCFS=y
CONFIG_SND_VERBOSE_PRINTK=y
CONFIG_SND_DEBUG=y
# CONFIG_SND_DEBUG_VERBOSE is not set
# CONFIG_SND_PCM_XRUN_DEBUG is not set
# CONFIG_SND_RAWMIDI_SEQ is not set
# CONFIG_SND_OPL3_LIB_SEQ is not set
# CONFIG_SND_OPL4_LIB_SEQ is not set
# CONFIG_SND_SBAWE_SEQ is not set
# CONFIG_SND_EMU10K1_SEQ is not set
CONFIG_SND_DRIVERS=y
# CONFIG_SND_DUMMY is not set
# CONFIG_SND_ALOOP is not set
# CONFIG_SND_MTPAV is not set
# CONFIG_SND_SERIAL_U16550 is not set
# CONFIG_SND_MPU401 is not set
CONFIG_SND_ARM=y
# CONFIG_SND_ARMAACI is not set
CONFIG_SND_SPI=y
CONFIG_SND_USB=y
CONFIG_SND_USB_AUDIO=m
# CONFIG_SND_USB_UA101 is not set
# CONFIG_SND_USB_CAIAQ is not set
# CONFIG_SND_USB_6FIRE is not set
CONFIG_SND_SOC=m
CONFIG_SND_SOC_DMAENGINE_PCM=y
# CONFIG_SND_ATMEL_SOC is not set
# CONFIG_SND_DESIGNWARE_I2S is not set
CONFIG_SND_OMAP_SOC=m
CONFIG_SND_OMAP_SOC_MCBSP=m
# CONFIG_SND_OMAP_SOC_N810 is not set
# CONFIG_SND_OMAP_SOC_RX51 is not set
# CONFIG_SND_OMAP_SOC_AM3517EVM is not set
CONFIG_SND_OMAP_SOC_OMAP_TWL4030=m
# CONFIG_SND_OMAP_SOC_OMAP_HDMI is not set
CONFIG_SND_OMAP_SOC_OMAP3_PANDORA=m
CONFIG_SND_SOC_I2C_AND_SPI=m
# CONFIG_SND_SOC_ALL_CODECS is not set
CONFIG_SND_SOC_TWL4030=m
# CONFIG_SND_SIMPLE_CARD is not set
# CONFIG_SOUND_PRIME is not set

#
# HID support
#
CONFIG_HID=y
# CONFIG_HID_BATTERY_STRENGTH is not set
# CONFIG_HIDRAW is not set
# CONFIG_UHID is not set
CONFIG_HID_GENERIC=y

#
# Special HID drivers
#
# CONFIG_HID_A4TECH is not set
# CONFIG_HID_ACRUX is not set
# CONFIG_HID_APPLE is not set
# CONFIG_HID_AUREAL is not set
# CONFIG_HID_BELKIN is not set
# CONFIG_HID_CHERRY is not set
# CONFIG_HID_CHICONY is not set
# CONFIG_HID_PRODIKEYS is not set
# CONFIG_HID_CYPRESS is not set
# CONFIG_HID_DRAGONRISE is not set
# CONFIG_HID_EMS_FF is not set
# CONFIG_HID_ELECOM is not set
# CONFIG_HID_EZKEY is not set
# CONFIG_HID_HOLTEK is not set
# CONFIG_HID_KEYTOUCH is not set
# CONFIG_HID_KYE is not set
# CONFIG_HID_UCLOGIC is not set
# CONFIG_HID_WALTOP is not set
# CONFIG_HID_GYRATION is not set
# CONFIG_HID_ICADE is not set
# CONFIG_HID_TWINHAN is not set
# CONFIG_HID_KENSINGTON is not set
# CONFIG_HID_LCPOWER is not set
# CONFIG_HID_LENOVO_TPKBD is not set
# CONFIG_HID_LOGITECH is not set
# CONFIG_HID_MAGICMOUSE is not set
# CONFIG_HID_MICROSOFT is not set
# CONFIG_HID_MONTEREY is not set
# CONFIG_HID_MULTITOUCH is not set
# CONFIG_HID_NTRIG is not set
# CONFIG_HID_ORTEK is not set
# CONFIG_HID_PANTHERLORD is not set
# CONFIG_HID_PETALYNX is not set
# CONFIG_HID_PICOLCD is not set
# CONFIG_HID_PRIMAX is not set
# CONFIG_HID_PS3REMOTE is not set
# CONFIG_HID_ROCCAT is not set
# CONFIG_HID_SAITEK is not set
# CONFIG_HID_SAMSUNG is not set
# CONFIG_HID_SONY is not set
# CONFIG_HID_SPEEDLINK is not set
# CONFIG_HID_STEELSERIES is not set
# CONFIG_HID_SUNPLUS is not set
# CONFIG_HID_GREENASIA is not set
# CONFIG_HID_SMARTJOYPLUS is not set
# CONFIG_HID_TIVO is not set
# CONFIG_HID_TOPSEED is not set
# CONFIG_HID_THINGM is not set
# CONFIG_HID_THRUSTMASTER is not set
# CONFIG_HID_WACOM is not set
# CONFIG_HID_WIIMOTE is not set
# CONFIG_HID_ZEROPLUS is not set
# CONFIG_HID_ZYDACRON is not set
# CONFIG_HID_SENSOR_HUB is not set

#
# USB HID support
#
CONFIG_USB_HID=y
# CONFIG_HID_PID is not set
# CONFIG_USB_HIDDEV is not set

#
# I2C HID support
#
# CONFIG_I2C_HID is not set
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB_ARCH_HAS_EHCI=y
# CONFIG_USB_ARCH_HAS_XHCI is not set
CONFIG_USB_SUPPORT=y
CONFIG_USB_COMMON=y
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB=y
CONFIG_USB_DEBUG=y
CONFIG_USB_ANNOUNCE_NEW_DEVICES=y

#
# Miscellaneous USB options
#
CONFIG_USB_DEFAULT_PERSIST=y
# CONFIG_USB_DYNAMIC_MINORS is not set
# CONFIG_USB_OTG_WHITELIST is not set
# CONFIG_USB_OTG_BLACKLIST_HUB is not set
CONFIG_USB_MON=y
# CONFIG_USB_WUSB_CBAF is not set

#
# USB Host Controller Drivers
#
# CONFIG_USB_C67X00_HCD is not set
# CONFIG_USB_EHCI_HCD is not set
# CONFIG_USB_OXU210HP_HCD is not set
# CONFIG_USB_ISP116X_HCD is not set
# CONFIG_USB_ISP1760_HCD is not set
# CONFIG_USB_ISP1362_HCD is not set
# CONFIG_USB_OHCI_HCD is not set
# CONFIG_USB_SL811_HCD is not set
# CONFIG_USB_R8A66597_HCD is not set
CONFIG_USB_MUSB_HDRC=y
# CONFIG_USB_MUSB_TUSB6010 is not set
CONFIG_USB_MUSB_OMAP2PLUS=y
# CONFIG_USB_MUSB_AM35X is not set
# CONFIG_USB_MUSB_DSPS is not set
# CONFIG_USB_MUSB_UX500 is not set
# CONFIG_USB_INVENTRA_DMA is not set
CONFIG_MUSB_PIO_ONLY=y
# CONFIG_USB_RENESAS_USBHS is not set

#
# USB Device Class drivers
#
# CONFIG_USB_ACM is not set
# CONFIG_USB_PRINTER is not set
CONFIG_USB_WDM=y
# CONFIG_USB_TMC is not set

#
# NOTE: USB_STORAGE depends on SCSI but BLK_DEV_SD may
#

#
# also be needed; see USB_STORAGE Help for more info
#
CONFIG_USB_STORAGE=y
# CONFIG_USB_STORAGE_DEBUG is not set
# CONFIG_USB_STORAGE_REALTEK is not set
# CONFIG_USB_STORAGE_DATAFAB is not set
# CONFIG_USB_STORAGE_FREECOM is not set
# CONFIG_USB_STORAGE_ISD200 is not set
# CONFIG_USB_STORAGE_USBAT is not set
# CONFIG_USB_STORAGE_SDDR09 is not set
# CONFIG_USB_STORAGE_SDDR55 is not set
# CONFIG_USB_STORAGE_JUMPSHOT is not set
# CONFIG_USB_STORAGE_ALAUDA is not set
# CONFIG_USB_STORAGE_ONETOUCH is not set
# CONFIG_USB_STORAGE_KARMA is not set
# CONFIG_USB_STORAGE_CYPRESS_ATACB is not set
# CONFIG_USB_STORAGE_ENE_UB6250 is not set

#
# USB Imaging devices
#
# CONFIG_USB_MDC800 is not set
# CONFIG_USB_MICROTEK is not set
# CONFIG_USB_DWC3 is not set
# CONFIG_USB_CHIPIDEA is not set

#
# USB port drivers
#
# CONFIG_USB_SERIAL is not set

#
# USB Miscellaneous drivers
#
# CONFIG_USB_EMI62 is not set
# CONFIG_USB_EMI26 is not set
# CONFIG_USB_ADUTUX is not set
# CONFIG_USB_SEVSEG is not set
# CONFIG_USB_RIO500 is not set
# CONFIG_USB_LEGOTOWER is not set
# CONFIG_USB_LCD is not set
# CONFIG_USB_LED is not set
# CONFIG_USB_CYPRESS_CY7C63 is not set
# CONFIG_USB_CYTHERM is not set
# CONFIG_USB_IDMOUSE is not set
# CONFIG_USB_FTDI_ELAN is not set
# CONFIG_USB_APPLEDISPLAY is not set
# CONFIG_USB_SISUSBVGA is not set
# CONFIG_USB_LD is not set
# CONFIG_USB_TRANCEVIBRATOR is not set
# CONFIG_USB_IOWARRIOR is not set
CONFIG_USB_TEST=y
# CONFIG_USB_ISIGHTFW is not set
# CONFIG_USB_YUREX is not set
# CONFIG_USB_EZUSB_FX2 is not set
# CONFIG_USB_HSIC_USB3503 is not set
CONFIG_USB_PHY=y
# CONFIG_NOP_USB_XCEIV is not set
CONFIG_OMAP_CONTROL_USB=y
CONFIG_OMAP_USB2=y
CONFIG_OMAP_USB3=y
# CONFIG_SAMSUNG_USBPHY is not set
# CONFIG_SAMSUNG_USB2PHY is not set
# CONFIG_SAMSUNG_USB3PHY is not set
CONFIG_TWL4030_USB=y
CONFIG_TWL6030_USB=y
# CONFIG_USB_GPIO_VBUS is not set
# CONFIG_USB_ISP1301 is not set
# CONFIG_USB_RCAR_PHY is not set
# CONFIG_USB_ULPI is not set
CONFIG_USB_GADGET=y
CONFIG_USB_GADGET_DEBUG=y
CONFIG_USB_GADGET_DEBUG_FILES=y
CONFIG_USB_GADGET_DEBUG_FS=y
CONFIG_USB_GADGET_VBUS_DRAW=2
CONFIG_USB_GADGET_STORAGE_NUM_BUFFERS=2

#
# USB Peripheral Controller
#
# CONFIG_USB_FUSB300 is not set
# CONFIG_USB_R8A66597 is not set
# CONFIG_USB_PXA27X is not set
# CONFIG_USB_MV_UDC is not set
# CONFIG_USB_MV_U3D is not set
CONFIG_USB_GADGET_MUSB_HDRC=y
# CONFIG_USB_M66592 is not set
# CONFIG_USB_NET2272 is not set
# CONFIG_USB_DUMMY_HCD is not set
CONFIG_USB_LIBCOMPOSITE=y
CONFIG_USB_F_SS_LB=y
CONFIG_USB_ZERO=y
# CONFIG_USB_AUDIO is not set
# CONFIG_USB_ETH is not set
# CONFIG_USB_G_NCM is not set
# CONFIG_USB_GADGETFS is not set
# CONFIG_USB_FUNCTIONFS is not set
# CONFIG_USB_MASS_STORAGE is not set
# CONFIG_USB_G_SERIAL is not set
# CONFIG_USB_MIDI_GADGET is not set
# CONFIG_USB_G_PRINTER is not set
# CONFIG_USB_CDC_COMPOSITE is not set
# CONFIG_USB_G_ACM_MS is not set
# CONFIG_USB_G_MULTI is not set
# CONFIG_USB_G_HID is not set
# CONFIG_USB_G_DBGP is not set
CONFIG_MMC=y
# CONFIG_MMC_DEBUG is not set
CONFIG_MMC_UNSAFE_RESUME=y
# CONFIG_MMC_CLKGATE is not set

#
# MMC/SD/SDIO Card Drivers
#
CONFIG_MMC_BLOCK=y
CONFIG_MMC_BLOCK_MINORS=8
CONFIG_MMC_BLOCK_BOUNCE=y
CONFIG_SDIO_UART=y
# CONFIG_MMC_TEST is not set

#
# MMC/SD/SDIO Host Controller Drivers
#
CONFIG_MMC_ARMMMCI=y
# CONFIG_MMC_SDHCI is not set
# CONFIG_MMC_SDHCI_PXAV3 is not set
# CONFIG_MMC_SDHCI_PXAV2 is not set
CONFIG_MMC_OMAP=y
CONFIG_MMC_OMAP_HS=y
# CONFIG_MMC_DW is not set
# CONFIG_MMC_VUB300 is not set
# CONFIG_MMC_USHC is not set
# CONFIG_MEMSTICK is not set
CONFIG_NEW_LEDS=y
CONFIG_LEDS_CLASS=y

#
# LED drivers
#
# CONFIG_LEDS_LM3530 is not set
# CONFIG_LEDS_LM3642 is not set
# CONFIG_LEDS_PCA9532 is not set
CONFIG_LEDS_GPIO=y
# CONFIG_LEDS_LP3944 is not set
# CONFIG_LEDS_LP5521 is not set
# CONFIG_LEDS_LP5523 is not set
# CONFIG_LEDS_LP5562 is not set
# CONFIG_LEDS_PCA955X is not set
# CONFIG_LEDS_PCA9633 is not set
# CONFIG_LEDS_DAC124S085 is not set
# CONFIG_LEDS_REGULATOR is not set
# CONFIG_LEDS_BD2802 is not set
# CONFIG_LEDS_LT3593 is not set
# CONFIG_LEDS_RENESAS_TPU is not set
# CONFIG_LEDS_TCA6507 is not set
# CONFIG_LEDS_LM355x is not set
# CONFIG_LEDS_OT200 is not set
# CONFIG_LEDS_BLINKM is not set

#
# LED Triggers
#
CONFIG_LEDS_TRIGGERS=y
CONFIG_LEDS_TRIGGER_TIMER=y
CONFIG_LEDS_TRIGGER_ONESHOT=y
CONFIG_LEDS_TRIGGER_HEARTBEAT=y
CONFIG_LEDS_TRIGGER_BACKLIGHT=y
CONFIG_LEDS_TRIGGER_CPU=y
CONFIG_LEDS_TRIGGER_GPIO=y
CONFIG_LEDS_TRIGGER_DEFAULT_ON=y

#
# iptables trigger is under Netfilter config (LED target)
#
# CONFIG_LEDS_TRIGGER_TRANSIENT is not set
# CONFIG_LEDS_TRIGGER_CAMERA is not set
# CONFIG_ACCESSIBILITY is not set
# CONFIG_EDAC is not set
CONFIG_RTC_LIB=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_HCTOSYS=y
CONFIG_RTC_SYSTOHC=y
CONFIG_RTC_HCTOSYS_DEVICE="rtc0"
# CONFIG_RTC_DEBUG is not set

#
# RTC interfaces
#
CONFIG_RTC_INTF_SYSFS=y
CONFIG_RTC_INTF_PROC=y
CONFIG_RTC_INTF_DEV=y
# CONFIG_RTC_INTF_DEV_UIE_EMUL is not set
# CONFIG_RTC_DRV_TEST is not set

#
# I2C RTC drivers
#
# CONFIG_RTC_DRV_DS1307 is not set
# CONFIG_RTC_DRV_DS1374 is not set
# CONFIG_RTC_DRV_DS1672 is not set
# CONFIG_RTC_DRV_DS3232 is not set
# CONFIG_RTC_DRV_MAX6900 is not set
# CONFIG_RTC_DRV_RS5C372 is not set
# CONFIG_RTC_DRV_ISL1208 is not set
# CONFIG_RTC_DRV_ISL12022 is not set
# CONFIG_RTC_DRV_X1205 is not set
# CONFIG_RTC_DRV_PCF8523 is not set
# CONFIG_RTC_DRV_PCF8563 is not set
# CONFIG_RTC_DRV_PCF8583 is not set
# CONFIG_RTC_DRV_M41T80 is not set
# CONFIG_RTC_DRV_BQ32K is not set
CONFIG_RTC_DRV_TWL92330=y
CONFIG_RTC_DRV_TWL4030=y
# CONFIG_RTC_DRV_TPS65910 is not set
# CONFIG_RTC_DRV_S35390A is not set
# CONFIG_RTC_DRV_FM3130 is not set
# CONFIG_RTC_DRV_RX8581 is not set
# CONFIG_RTC_DRV_RX8025 is not set
# CONFIG_RTC_DRV_EM3027 is not set
# CONFIG_RTC_DRV_RV3029C2 is not set

#
# SPI RTC drivers
#
# CONFIG_RTC_DRV_M41T93 is not set
# CONFIG_RTC_DRV_M41T94 is not set
# CONFIG_RTC_DRV_DS1305 is not set
# CONFIG_RTC_DRV_DS1390 is not set
# CONFIG_RTC_DRV_MAX6902 is not set
# CONFIG_RTC_DRV_R9701 is not set
# CONFIG_RTC_DRV_RS5C348 is not set
# CONFIG_RTC_DRV_DS3234 is not set
# CONFIG_RTC_DRV_PCF2123 is not set
# CONFIG_RTC_DRV_RX4581 is not set

#
# Platform RTC drivers
#
# CONFIG_RTC_DRV_CMOS is not set
# CONFIG_RTC_DRV_DS1286 is not set
# CONFIG_RTC_DRV_DS1511 is not set
# CONFIG_RTC_DRV_DS1553 is not set
# CONFIG_RTC_DRV_DS1742 is not set
# CONFIG_RTC_DRV_STK17TA8 is not set
# CONFIG_RTC_DRV_M48T86 is not set
# CONFIG_RTC_DRV_M48T35 is not set
# CONFIG_RTC_DRV_M48T59 is not set
# CONFIG_RTC_DRV_MSM6242 is not set
# CONFIG_RTC_DRV_BQ4802 is not set
# CONFIG_RTC_DRV_RP5C01 is not set
# CONFIG_RTC_DRV_V3020 is not set
# CONFIG_RTC_DRV_DS2404 is not set

#
# on-CPU RTC drivers
#
CONFIG_RTC_DRV_OMAP=y
# CONFIG_RTC_DRV_PL030 is not set
# CONFIG_RTC_DRV_PL031 is not set
# CONFIG_RTC_DRV_SNVS is not set

#
# HID Sensor RTC drivers
#
# CONFIG_RTC_DRV_HID_SENSOR_TIME is not set
CONFIG_DMADEVICES=y
# CONFIG_DMADEVICES_DEBUG is not set

#
# DMA Devices
#
# CONFIG_AMBA_PL08X is not set
# CONFIG_DW_DMAC is not set
# CONFIG_TIMB_DMA is not set
# CONFIG_PL330_DMA is not set
CONFIG_DMA_OMAP=y
CONFIG_DMA_ENGINE=y
CONFIG_DMA_VIRTUAL_CHANNELS=y
CONFIG_DMA_OF=y

#
# DMA Clients
#
# CONFIG_NET_DMA is not set
# CONFIG_ASYNC_TX_DMA is not set
# CONFIG_DMATEST is not set
# CONFIG_AUXDISPLAY is not set
# CONFIG_UIO is not set
# CONFIG_VIRT_DRIVERS is not set

#
# Virtio drivers
#
# CONFIG_VIRTIO_MMIO is not set

#
# Microsoft Hyper-V guest support
#
# CONFIG_STAGING is not set
CONFIG_CLKDEV_LOOKUP=y
CONFIG_HAVE_CLK_PREPARE=y
CONFIG_COMMON_CLK=y

#
# Common Clock Framework
#
# CONFIG_COMMON_CLK_DEBUG is not set
CONFIG_COMMON_CLK_VERSATILE=y
# CONFIG_COMMON_CLK_SI5351 is not set

#
# Hardware Spinlock drivers
#
# CONFIG_HWSPINLOCK_OMAP is not set
CONFIG_CLKSRC_OF=y
CONFIG_CLKSRC_MMIO=y
CONFIG_ARM_ARCH_TIMER=y
# CONFIG_MAILBOX is not set
CONFIG_IOMMU_SUPPORT=y
CONFIG_OF_IOMMU=y
# CONFIG_OMAP_IOMMU is not set

#
# Remoteproc drivers
#
# CONFIG_STE_MODEM_RPROC is not set

#
# Rpmsg drivers
#
# CONFIG_PM_DEVFREQ is not set
# CONFIG_EXTCON is not set
# CONFIG_MEMORY is not set
# CONFIG_IIO is not set
# CONFIG_PWM is not set
CONFIG_IRQCHIP=y
CONFIG_ARM_GIC=y
# CONFIG_IPACK_BUS is not set
# CONFIG_RESET_CONTROLLER is not set

#
# File systems
#
CONFIG_DCACHE_WORD_ACCESS=y
CONFIG_EXT2_FS=y
# CONFIG_EXT2_FS_XATTR is not set
# CONFIG_EXT2_FS_XIP is not set
CONFIG_EXT3_FS=y
CONFIG_EXT3_DEFAULTS_TO_ORDERED=y
# CONFIG_EXT3_FS_XATTR is not set
CONFIG_EXT4_FS=y
# CONFIG_EXT4_FS_POSIX_ACL is not set
# CONFIG_EXT4_FS_SECURITY is not set
# CONFIG_EXT4_DEBUG is not set
CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
CONFIG_JBD2=y
# CONFIG_JBD2_DEBUG is not set
CONFIG_FS_MBCACHE=y
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
# CONFIG_XFS_FS is not set
# CONFIG_GFS2_FS is not set
# CONFIG_OCFS2_FS is not set
# CONFIG_BTRFS_FS is not set
# CONFIG_NILFS2_FS is not set
CONFIG_FS_POSIX_ACL=y
CONFIG_FILE_LOCKING=y
CONFIG_FSNOTIFY=y
CONFIG_DNOTIFY=y
CONFIG_INOTIFY_USER=y
# CONFIG_FANOTIFY is not set
CONFIG_QUOTA=y
# CONFIG_QUOTA_NETLINK_INTERFACE is not set
CONFIG_PRINT_QUOTA_WARNING=y
# CONFIG_QUOTA_DEBUG is not set
CONFIG_QUOTA_TREE=y
# CONFIG_QFMT_V1 is not set
CONFIG_QFMT_V2=y
CONFIG_QUOTACTL=y
# CONFIG_AUTOFS4_FS is not set
# CONFIG_FUSE_FS is not set

#
# Caches
#
# CONFIG_FSCACHE is not set

#
# CD-ROM/DVD Filesystems
#
# CONFIG_ISO9660_FS is not set
# CONFIG_UDF_FS is not set

#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=y
CONFIG_VFAT_FS=y
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
# CONFIG_NTFS_FS is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_SYSCTL=y
CONFIG_PROC_PAGE_MONITOR=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
# CONFIG_TMPFS_POSIX_ACL is not set
# CONFIG_TMPFS_XATTR is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_CONFIGFS_FS=y
CONFIG_MISC_FILESYSTEMS=y
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_ECRYPT_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
CONFIG_JFFS2_FS=y
CONFIG_JFFS2_FS_DEBUG=0
CONFIG_JFFS2_FS_WRITEBUFFER=y
# CONFIG_JFFS2_FS_WBUF_VERIFY is not set
CONFIG_JFFS2_SUMMARY=y
CONFIG_JFFS2_FS_XATTR=y
CONFIG_JFFS2_FS_POSIX_ACL=y
CONFIG_JFFS2_FS_SECURITY=y
CONFIG_JFFS2_COMPRESSION_OPTIONS=y
CONFIG_JFFS2_ZLIB=y
CONFIG_JFFS2_LZO=y
CONFIG_JFFS2_RTIME=y
CONFIG_JFFS2_RUBIN=y
# CONFIG_JFFS2_CMODE_NONE is not set
CONFIG_JFFS2_CMODE_PRIORITY=y
# CONFIG_JFFS2_CMODE_SIZE is not set
# CONFIG_JFFS2_CMODE_FAVOURLZO is not set
CONFIG_UBIFS_FS=y
# CONFIG_UBIFS_FS_ADVANCED_COMPR is not set
CONFIG_UBIFS_FS_LZO=y
CONFIG_UBIFS_FS_ZLIB=y
# CONFIG_LOGFS is not set
CONFIG_CRAMFS=y
# CONFIG_SQUASHFS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_OMFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_QNX6FS_FS is not set
# CONFIG_ROMFS_FS is not set
# CONFIG_PSTORE is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set
# CONFIG_F2FS_FS is not set
CONFIG_NETWORK_FILESYSTEMS=y
CONFIG_NFS_FS=y
CONFIG_NFS_V2=y
CONFIG_NFS_V3=y
CONFIG_NFS_V3_ACL=y
CONFIG_NFS_V4=y
# CONFIG_NFS_SWAP is not set
# CONFIG_NFS_V4_1 is not set
CONFIG_ROOT_NFS=y
# CONFIG_NFS_USE_LEGACY_DNS is not set
CONFIG_NFS_USE_KERNEL_DNS=y
# CONFIG_NFSD is not set
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_NFS_ACL_SUPPORT=y
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=y
CONFIG_SUNRPC_GSS=y
# CONFIG_SUNRPC_DEBUG is not set
# CONFIG_CEPH_FS is not set
# CONFIG_CIFS is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
CONFIG_NLS_CODEPAGE_437=y
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
# CONFIG_NLS_CODEPAGE_850 is not set
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
# CONFIG_NLS_ASCII is not set
CONFIG_NLS_ISO8859_1=y
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
# CONFIG_NLS_ISO8859_15 is not set
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
# CONFIG_NLS_MAC_ROMAN is not set
# CONFIG_NLS_MAC_CELTIC is not set
# CONFIG_NLS_MAC_CENTEURO is not set
# CONFIG_NLS_MAC_CROATIAN is not set
# CONFIG_NLS_MAC_CYRILLIC is not set
# CONFIG_NLS_MAC_GAELIC is not set
# CONFIG_NLS_MAC_GREEK is not set
# CONFIG_NLS_MAC_ICELAND is not set
# CONFIG_NLS_MAC_INUIT is not set
# CONFIG_NLS_MAC_ROMANIAN is not set
# CONFIG_NLS_MAC_TURKISH is not set
# CONFIG_NLS_UTF8 is not set
# CONFIG_DLM is not set

#
# Kernel hacking
#
CONFIG_PRINTK_TIME=y
CONFIG_DEFAULT_MESSAGE_LOGLEVEL=4
CONFIG_ENABLE_WARN_DEPRECATED=y
CONFIG_ENABLE_MUST_CHECK=y
CONFIG_FRAME_WARN=1024
CONFIG_MAGIC_SYSRQ=y
# CONFIG_STRIP_ASM_SYMS is not set
# CONFIG_READABLE_ASM is not set
# CONFIG_UNUSED_SYMBOLS is not set
CONFIG_DEBUG_FS=y
# CONFIG_HEADERS_CHECK is not set
# CONFIG_DEBUG_SECTION_MISMATCH is not set
CONFIG_DEBUG_KERNEL=y
# CONFIG_DEBUG_SHIRQ is not set
# CONFIG_LOCKUP_DETECTOR is not set
# CONFIG_PANIC_ON_OOPS is not set
CONFIG_PANIC_ON_OOPS_VALUE=0
# CONFIG_DETECT_HUNG_TASK is not set
CONFIG_SCHED_DEBUG=y
CONFIG_SCHEDSTATS=y
CONFIG_TIMER_STATS=y
# CONFIG_DEBUG_OBJECTS is not set
# CONFIG_DEBUG_SLAB is not set
CONFIG_HAVE_DEBUG_KMEMLEAK=y
# CONFIG_DEBUG_KMEMLEAK is not set
# CONFIG_DEBUG_RT_MUTEXES is not set
# CONFIG_RT_MUTEX_TESTER is not set
CONFIG_DEBUG_SPINLOCK=y
CONFIG_DEBUG_MUTEXES=y
CONFIG_DEBUG_LOCK_ALLOC=y
CONFIG_PROVE_LOCKING=y
CONFIG_LOCKDEP=y
# CONFIG_LOCK_STAT is not set
# CONFIG_DEBUG_LOCKDEP is not set
CONFIG_TRACE_IRQFLAGS=y
# CONFIG_DEBUG_ATOMIC_SLEEP is not set
# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set
CONFIG_STACKTRACE=y
# CONFIG_DEBUG_STACK_USAGE is not set
# CONFIG_DEBUG_KOBJECT is not set
# CONFIG_DEBUG_HIGHMEM is not set
# CONFIG_DEBUG_BUGVERBOSE is not set
CONFIG_DEBUG_INFO=y
# CONFIG_DEBUG_INFO_REDUCED is not set
# CONFIG_DEBUG_VM is not set
# CONFIG_DEBUG_WRITECOUNT is not set
# CONFIG_DEBUG_MEMORY_INIT is not set
# CONFIG_DEBUG_LIST is not set
# CONFIG_TEST_LIST_SORT is not set
# CONFIG_DEBUG_SG is not set
# CONFIG_DEBUG_NOTIFIERS is not set
# CONFIG_DEBUG_CREDENTIALS is not set
# CONFIG_BOOT_PRINTK_DELAY is not set

#
# RCU Debugging
#
# CONFIG_PROVE_RCU is not set
# CONFIG_SPARSE_RCU_POINTER is not set
# CONFIG_RCU_TORTURE_TEST is not set
CONFIG_RCU_CPU_STALL_TIMEOUT=21
# CONFIG_RCU_CPU_STALL_INFO is not set
# CONFIG_RCU_TRACE is not set
# CONFIG_KPROBES_SANITY_TEST is not set
# CONFIG_BACKTRACE_SELF_TEST is not set
# CONFIG_DEBUG_BLOCK_EXT_DEVT is not set
# CONFIG_DEBUG_FORCE_WEAK_PER_CPU is not set
# CONFIG_DEBUG_PER_CPU_MAPS is not set
# CONFIG_LKDTM is not set
# CONFIG_NOTIFIER_ERROR_INJECTION is not set
# CONFIG_FAULT_INJECTION is not set
# CONFIG_DEBUG_PAGEALLOC is not set
CONFIG_NOP_TRACER=y
CONFIG_HAVE_FUNCTION_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y
CONFIG_HAVE_DYNAMIC_FTRACE=y
CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y
CONFIG_HAVE_SYSCALL_TRACEPOINTS=y
CONFIG_HAVE_C_RECORDMCOUNT=y
CONFIG_TRACE_CLOCK=y
CONFIG_RING_BUFFER=y
CONFIG_EVENT_TRACING=y
CONFIG_CONTEXT_SWITCH_TRACER=y
CONFIG_RING_BUFFER_ALLOW_SWAP=y
CONFIG_TRACING=y
CONFIG_TRACING_SUPPORT=y
CONFIG_FTRACE=y
# CONFIG_FUNCTION_TRACER is not set
# CONFIG_IRQSOFF_TRACER is not set
# CONFIG_SCHED_TRACER is not set
# CONFIG_ENABLE_DEFAULT_TRACERS is not set
# CONFIG_FTRACE_SYSCALLS is not set
# CONFIG_TRACER_SNAPSHOT is not set
CONFIG_BRANCH_PROFILE_NONE=y
# CONFIG_PROFILE_ANNOTATED_BRANCHES is not set
# CONFIG_PROFILE_ALL_BRANCHES is not set
# CONFIG_STACK_TRACER is not set
# CONFIG_BLK_DEV_IO_TRACE is not set
CONFIG_KPROBE_EVENT=y
CONFIG_PROBE_EVENTS=y
# CONFIG_RING_BUFFER_BENCHMARK is not set
# CONFIG_RING_BUFFER_STARTUP_TEST is not set
# CONFIG_RBTREE_TEST is not set
# CONFIG_INTERVAL_TREE_TEST is not set
# CONFIG_DYNAMIC_DEBUG is not set
# CONFIG_DMA_API_DEBUG is not set
# CONFIG_ATOMIC64_SELFTEST is not set
# CONFIG_SAMPLES is not set
CONFIG_HAVE_ARCH_KGDB=y
# CONFIG_KGDB is not set
# CONFIG_TEST_STRING_HELPERS is not set
# CONFIG_TEST_KSTRTOX is not set
# CONFIG_STRICT_DEVMEM is not set
CONFIG_ARM_UNWIND=y
# CONFIG_DEBUG_USER is not set
# CONFIG_DEBUG_LL is not set
CONFIG_DEBUG_LL_INCLUDE="mach/debug-macro.S"
CONFIG_UNCOMPRESS_INCLUDE="debug/uncompress.h"
# CONFIG_OC_ETM is not set
# CONFIG_ARM_KPROBES_TEST is not set
# CONFIG_PID_IN_CONTEXTIDR is not set

#
# Security options
#
CONFIG_KEYS=y
# CONFIG_ENCRYPTED_KEYS is not set
# CONFIG_KEYS_DEBUG_PROC_KEYS is not set
# CONFIG_SECURITY_DMESG_RESTRICT is not set
CONFIG_SECURITY=y
# CONFIG_SECURITYFS is not set
# CONFIG_SECURITY_NETWORK is not set
# CONFIG_SECURITY_PATH is not set
# CONFIG_SECURITY_SMACK is not set
# CONFIG_SECURITY_TOMOYO is not set
# CONFIG_SECURITY_APPARMOR is not set
# CONFIG_SECURITY_YAMA is not set
# CONFIG_IMA is not set
# CONFIG_EVM is not set
CONFIG_DEFAULT_SECURITY_DAC=y
CONFIG_DEFAULT_SECURITY=""
CONFIG_CRYPTO=y

#
# Crypto core or helper
#
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_ALGAPI2=y
CONFIG_CRYPTO_AEAD2=y
CONFIG_CRYPTO_BLKCIPHER=m
CONFIG_CRYPTO_BLKCIPHER2=y
CONFIG_CRYPTO_HASH=y
CONFIG_CRYPTO_HASH2=y
CONFIG_CRYPTO_RNG2=y
CONFIG_CRYPTO_PCOMP2=y
CONFIG_CRYPTO_MANAGER=m
CONFIG_CRYPTO_MANAGER2=y
# CONFIG_CRYPTO_USER is not set
CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=y
# CONFIG_CRYPTO_GF128MUL is not set
# CONFIG_CRYPTO_NULL is not set
# CONFIG_CRYPTO_PCRYPT is not set
CONFIG_CRYPTO_WORKQUEUE=y
# CONFIG_CRYPTO_CRYPTD is not set
# CONFIG_CRYPTO_AUTHENC is not set
# CONFIG_CRYPTO_TEST is not set

#
# Authenticated Encryption with Associated Data
#
# CONFIG_CRYPTO_CCM is not set
# CONFIG_CRYPTO_GCM is not set
# CONFIG_CRYPTO_SEQIV is not set

#
# Block modes
#
# CONFIG_CRYPTO_CBC is not set
# CONFIG_CRYPTO_CTR is not set
# CONFIG_CRYPTO_CTS is not set
CONFIG_CRYPTO_ECB=m
# CONFIG_CRYPTO_LRW is not set
# CONFIG_CRYPTO_PCBC is not set
# CONFIG_CRYPTO_XTS is not set

#
# Hash modes
#
# CONFIG_CRYPTO_CMAC is not set
# CONFIG_CRYPTO_HMAC is not set
# CONFIG_CRYPTO_XCBC is not set
# CONFIG_CRYPTO_VMAC is not set

#
# Digest
#
CONFIG_CRYPTO_CRC32C=y
# CONFIG_CRYPTO_CRC32 is not set
# CONFIG_CRYPTO_GHASH is not set
# CONFIG_CRYPTO_MD4 is not set
# CONFIG_CRYPTO_MD5 is not set
CONFIG_CRYPTO_MICHAEL_MIC=y
# CONFIG_CRYPTO_RMD128 is not set
# CONFIG_CRYPTO_RMD160 is not set
# CONFIG_CRYPTO_RMD256 is not set
# CONFIG_CRYPTO_RMD320 is not set
# CONFIG_CRYPTO_SHA1 is not set
# CONFIG_CRYPTO_SHA1_ARM is not set
CONFIG_CRYPTO_SHA256=m
# CONFIG_CRYPTO_SHA512 is not set
# CONFIG_CRYPTO_TGR192 is not set
# CONFIG_CRYPTO_WP512 is not set

#
# Ciphers
#
CONFIG_CRYPTO_AES=y
# CONFIG_CRYPTO_AES_ARM is not set
# CONFIG_CRYPTO_ANUBIS is not set
CONFIG_CRYPTO_ARC4=m
# CONFIG_CRYPTO_BLOWFISH is not set
# CONFIG_CRYPTO_CAMELLIA is not set
# CONFIG_CRYPTO_CAST5 is not set
# CONFIG_CRYPTO_CAST6 is not set
# CONFIG_CRYPTO_DES is not set
# CONFIG_CRYPTO_FCRYPT is not set
# CONFIG_CRYPTO_KHAZAD is not set
# CONFIG_CRYPTO_SALSA20 is not set
# CONFIG_CRYPTO_SEED is not set
# CONFIG_CRYPTO_SERPENT is not set
# CONFIG_CRYPTO_TEA is not set
# CONFIG_CRYPTO_TWOFISH is not set

#
# Compression
#
CONFIG_CRYPTO_DEFLATE=y
# CONFIG_CRYPTO_ZLIB is not set
CONFIG_CRYPTO_LZO=y
# CONFIG_CRYPTO_LZ4 is not set
# CONFIG_CRYPTO_LZ4HC is not set

#
# Random Number Generation
#
# CONFIG_CRYPTO_ANSI_CPRNG is not set
# CONFIG_CRYPTO_USER_API_HASH is not set
# CONFIG_CRYPTO_USER_API_SKCIPHER is not set
CONFIG_CRYPTO_HW=y
# CONFIG_CRYPTO_DEV_OMAP_SHAM is not set
# CONFIG_CRYPTO_DEV_OMAP_AES is not set
# CONFIG_ASYMMETRIC_KEY_TYPE is not set
CONFIG_BINARY_PRINTF=y

#
# Library routines
#
CONFIG_BITREVERSE=y
CONFIG_GENERIC_STRNCPY_FROM_USER=y
CONFIG_GENERIC_STRNLEN_USER=y
CONFIG_GENERIC_PCI_IOMAP=y
CONFIG_GENERIC_IO=y
CONFIG_CRC_CCITT=y
CONFIG_CRC16=y
CONFIG_CRC_T10DIF=y
CONFIG_CRC_ITU_T=y
CONFIG_CRC32=y
# CONFIG_CRC32_SELFTEST is not set
CONFIG_CRC32_SLICEBY8=y
# CONFIG_CRC32_SLICEBY4 is not set
# CONFIG_CRC32_SARWATE is not set
# CONFIG_CRC32_BIT is not set
CONFIG_CRC7=y
CONFIG_LIBCRC32C=y
# CONFIG_CRC8 is not set
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
CONFIG_LZO_COMPRESS=y
CONFIG_LZO_DECOMPRESS=y
# CONFIG_XZ_DEC is not set
# CONFIG_XZ_DEC_BCJ is not set
CONFIG_DECOMPRESS_GZIP=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_DMA=y
CONFIG_CPU_RMAP=y
CONFIG_DQL=y
CONFIG_NLATTR=y
CONFIG_GENERIC_ATOMIC64=y
CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE=y
CONFIG_AVERAGE=y
# CONFIG_CORDIC is not set
# CONFIG_DDR is not set
CONFIG_OID_REGISTRY=y
# CONFIG_VIRTUALIZATION is not set

From arno at natisbad.org  Wed Apr 24 01:43:51 2013
From: arno at natisbad.org (Arnaud Ebalard)
Date: Wed, 24 Apr 2013 07:43:51 +0200
Subject: [PATCHv1 3/3] hwmon: Add DT documentation for g762 driver
In-Reply-To: <20130423222305.GD13884@titan.lakedaemon.net> (Jason Cooper's
 message of "Tue, 23 Apr 2013 18:23:05 -0400")
References: <cover.1366753420.git.arno@natisbad.org>
 <6ee748f450ba2a80c87aba08c0672105e2800f93.1366753420.git.arno@natisbad.org>
 <20130423222305.GD13884@titan.lakedaemon.net>
Message-ID: <87r4i0fppk.fsf@natisbad.org>

Hi Jason,

Jason Cooper <jason at lakedaemon.net> writes:

>> +Example g762 node:
>> +
>> +   g762: g762 at 3e {
>> +        compatible = "gmt,g762";
>> +   	reg = <0x3e>;
>> +   	pwm_mode = <1>;      /* closed-loop control */
>> +   	pwm_enable = <2>;    /* PWM mode */
>> +   	pwm_freq = <8192>;   /* PWM reference clock freq */
>> +   	fan_pulses = <2>;    /* 2 pulses per rev */
>> +   	fan_div = <2>;       /* fan clock divisor */
>> +   	fan_target = <2000>; /* target fan speed at 2000 RPM */
>> +        fan_gear_mode = <0>; /* default */
>> +        fan_startv = <1>;    /* default */
>> +        pwm_polarity = <0>;  /* default */
>> +   };
>
> I was just giving this quick overview and noticed that you have
> leading whitespace issues in the above block...

Will fix that in next round. Sorry for that and thanks for your time.

Cheers,

a+


From vkale at apm.com  Wed Apr 24 02:21:24 2013
From: vkale at apm.com (Vinayak Kale)
Date: Wed, 24 Apr 2013 11:51:24 +0530
Subject: [PATCH 4/4] arm64: Add initial DTS for APM X-Gene Storm SOC and
 APM Mustang board
In-Reply-To: <20130423181109.GA6850@quad.lixom.net>
References: <1366442131-26094-1-git-send-email-vkale@apm.com>
 <1366442131-26094-5-git-send-email-vkale@apm.com>
 <20130423181109.GA6850@quad.lixom.net>
Message-ID: <CAPrCYkfq=ypk+3=FamZQgMhaxMHDzsSFdsNByMoq1H=kLSY8YA@mail.gmail.com>

On Tue, Apr 23, 2013 at 11:41 PM, Olof Johansson <olof at lixom.net> wrote:
> On Sat, Apr 20, 2013 at 12:45:31PM +0530, Vinayak Kale wrote:
>
>> +     gic: interrupt-controller at 78010000 {
>> +             compatible = "arm,cortex-a15-gic", "arm,cortex-a9-gic";
>> +             #interrupt-cells = <3>;
>> +             interrupt-controller;
>> +             reg = <0x0 0x78010000 0x0 0x1000>,      /* GIC Dist */
>> +                   <0x0 0x78020000 0x0 0x1000>,      /* GIC CPU */
>> +                   <0x0 0x78040000 0x0 0x2000>,      /* GIC VCPU Control */
>> +                   <0x0 0x78060000 0x0 0x2000>;      /* GIC VCPU */
>> +             interrupts = <1 9 0xf04>;       /* GIC Maintenence IRQ */
>> +     };
>
> Others have commented on other compatible fields, so it's my turn. :-)
>
> Is this the exact same GIC that's used with A15? I don't think it is? It might
> make more sense to use a new compatible field and add it to the driver.
>
> Also, other platforms have removed the a9 fallback, so even if you happen to
> have an a15-compatible gic, in this case you should at least take out the a9
> string.
>
Okay, will remove a9-gic string. Our's is a15-compatible gic, will use
a15 string.
>
> -Olof
Thanks
-Vinayak


From chao.xie at marvell.com  Wed Apr 24 02:23:14 2013
From: chao.xie at marvell.com (Chao Xie)
Date: Wed, 24 Apr 2013 02:23:14 -0400
Subject: [V9 PATCH 00/12] mv-usb phy driver
Message-ID: <1366784606-1813-1-git-send-email-chao.xie@marvell.com>

The patches create the mv-usb phy driver

The patches remove the callbacks in the platform data for phy
initialization and shutdown, and directly write a phy driver
and make udc/ehci/otg to call it.

  usb: phy: protect phy init and shutdown for mutiple deivces
  usb: phy: mv_usb2: add PHY driver for marvell usb2 controller
Above patches are marvell usb PHY driver support.

  usb: gadget: mv_udc: use PHY driver for udc
  usb: ehci: ehci-mv: use PHY driver for ehci
  usb: phy: phy-mv-usb: use USB2 PHY driver for otg
Above patches modify the udc/ehci/otg drivers to make use of PHY
driver.

  usb: mv_u3d: usb phy drivers for phy operation
Above patch is the fix for marvel usb3 gadget driver. It will make
use of PHY driver.

  arm: mmp2: change the defintion of usb devices
  arm: pxa910: change the defintion of usb devices
  arm: ttc_dkb: modify usb support
  arm: mmp: remove unused usb devices
  arm: brownstone: add usb support for the board
Above patches are the changes from SOCes.

  usb: mv_usb: remove the phy callbacks in pdata
Above patch finally remove the callbacks for PHY in pdata.

V2->V1:
  Change the Signed-off-by to be right email address

v3->v2
  re-format the patches to new code base

v4->v3
  1. make mv udc gadget driver depend on ARCH_PXA and ARCH_MMP
  2. remove __devinit and __devexit
  3. make the driver compiled successful if CONFIG_MV_USB2_PHY is not defined.
  The modified patches are
  usb: gadget: mv_udc: make mv_udc depends on ARCH_MMP or ARCH_PXA
  usb: phy: mv_usb2: add PHY driver for marvell usb2 controller

v5->v4
  make the struct mv_usb2_extern_chip member ->head to be
  struct atomic_notifier_head instead of struct atomic_notifier_head *.

v6->v5
  the bug fix patches are merged.
  Removed the dependcy of ARCH_MMP and ARCH_PXA, and make the driver can be
  compiled for x86.
  The device tree support patches need modification, remove them from this
  patch series, and they will be submitted in another series.


v7->v6
  Use usb_add_phy_dev and related APIs to add PHY drivers.
  Removed the device tree support in PHY driver. It will be added in another
  patch series.

v8->v7
  bugs fix in phy driver.
  directly use devm_usb_get_phy_dev return value for error return.

v9->v8
  Remove u2o_xxx.
  Add prefix for register definition
  Move mutex to common PHY layer
  Use module_platform_driver() to register driver
  Use usleep_range to replace udelay

Chao Xie (12):
  usb: phy: protect phy init and shutdown for mutiple deivces
  usb: phy: mv_usb2: add PHY driver for marvell usb2 controller
  usb: gadget: mv_udc: use PHY driver for udc
  usb: ehci: ehci-mv: use PHY driver for ehci
  usb: phy: phy-mv-usb: use USB2 PHY driver for otg
  usb: mv_u3d: usb phy drivers for phy operation
  arm: mmp2: change the defintion of usb devices
  arm: pxa910: change the defintion of usb devices
  arm: ttc_dkb: modify usb support
  arm: mmp: remove unused usb devices
  arm: brownstone: add usb support for the board
  usb: mv_usb: remove the phy callbacks in pdata

 arch/arm/mach-mmp/brownstone.c          |   56 +++++
 arch/arm/mach-mmp/include/mach/mmp2.h   |    4 +
 arch/arm/mach-mmp/include/mach/pxa910.h |    7 +-
 arch/arm/mach-mmp/mmp2.c                |    4 +
 arch/arm/mach-mmp/pxa910.c              |    4 +
 arch/arm/mach-mmp/ttc_dkb.c             |   39 +++-
 drivers/usb/gadget/mv_u3d.h             |    3 +-
 drivers/usb/gadget/mv_u3d_core.c        |   54 ++---
 drivers/usb/gadget/mv_udc.h             |    2 +-
 drivers/usb/gadget/mv_udc_core.c        |   50 ++---
 drivers/usb/host/ehci-mv.c              |   49 ++---
 drivers/usb/phy/Kconfig                 |    6 +
 drivers/usb/phy/Makefile                |    1 +
 drivers/usb/phy/phy-mv-usb.c            |   53 ++---
 drivers/usb/phy/phy-mv-usb.h            |    2 +-
 drivers/usb/phy/phy-mv-usb2.c           |  380 +++++++++++++++++++++++++++++++
 drivers/usb/phy/phy.c                   |    6 +
 include/linux/platform_data/mv_usb.h    |    3 -
 include/linux/usb/mv_usb2.h             |   29 +++
 include/linux/usb/phy.h                 |   22 ++-
 20 files changed, 624 insertions(+), 150 deletions(-)
 create mode 100644 drivers/usb/phy/phy-mv-usb2.c
 create mode 100644 include/linux/usb/mv_usb2.h

-- 
1.7.4.1



From chao.xie at marvell.com  Wed Apr 24 02:23:16 2013
From: chao.xie at marvell.com (Chao Xie)
Date: Wed, 24 Apr 2013 02:23:16 -0400
Subject: [V9 PATCH 02/12] usb: phy: mv_usb2: add PHY driver for marvell usb2
 controller
In-Reply-To: <1366784606-1813-1-git-send-email-chao.xie@marvell.com>
References: <1366784606-1813-1-git-send-email-chao.xie@marvell.com>
Message-ID: <1366784606-1813-3-git-send-email-chao.xie@marvell.com>

The PHY is seperated from usb controller.
The usb controller used in marvell pxa168/pxa910/mmp2 are same,
but PHY initialization may be different.
the usb controller can support udc/otg/ehci, and for each of
the mode, it need PHY to initialized before use the controller.
Direclty writing the phy driver will make the usb controller
driver to be simple and portable.
The PHY driver will be used by marvell udc/otg/ehci.

Signed-off-by: Chao Xie <chao.xie at marvell.com>
---
 drivers/usb/phy/Kconfig       |    9 +
 drivers/usb/phy/Makefile      |    1 +
 drivers/usb/phy/phy-mv-usb2.c |  379 +++++++++++++++++++++++++++++++++++++++++
 include/linux/usb/mv_usb2.h   |   29 +++
 4 files changed, 418 insertions(+), 0 deletions(-)
 create mode 100644 drivers/usb/phy/phy-mv-usb2.c
 create mode 100644 include/linux/usb/mv_usb2.h

diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index 372db48..bdc7603 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -170,6 +170,15 @@ config USB_MV_OTG
 
 	  To compile this driver as a module, choose M here.
 
+config MV_USB2_PHY
+	tristate "Marvell USB 2.0 PHY Driver"
+	help
+	  Enable this to support Marvell USB 2.0 phy driver for Marvell
+	  SoC. This driver will do the PHY initialization and shutdown.
+	  The PHY driver will be used by Marvell udc/ehci/otg driver.
+
+	  To compile this driver as a module, choose M here.
+
 config USB_MXS_PHY
 	tristate "Freescale MXS USB PHY support"
 	depends on ARCH_MXC || ARCH_MXS
diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
index 33863c0..90cc5f5 100644
--- a/drivers/usb/phy/Makefile
+++ b/drivers/usb/phy/Makefile
@@ -26,6 +26,7 @@ obj-$(CONFIG_USB_EHCI_TEGRA)		+= phy-tegra-usb.o
 obj-$(CONFIG_USB_GPIO_VBUS)		+= phy-gpio-vbus-usb.o
 obj-$(CONFIG_USB_ISP1301)		+= phy-isp1301.o
 obj-$(CONFIG_USB_MSM_OTG)		+= phy-msm-usb.o
+obj-$(CONFIG_MV_USB2_PHY)		+= phy-mv-usb2.o
 obj-$(CONFIG_USB_MV_OTG)		+= phy-mv-usb.o
 obj-$(CONFIG_USB_MXS_PHY)		+= phy-mxs-usb.o
 obj-$(CONFIG_USB_RCAR_PHY)		+= phy-rcar-usb.o
diff --git a/drivers/usb/phy/phy-mv-usb2.c b/drivers/usb/phy/phy-mv-usb2.c
new file mode 100644
index 0000000..43459ef
--- /dev/null
+++ b/drivers/usb/phy/phy-mv-usb2.c
@@ -0,0 +1,379 @@
+/*
+ * Copyright (C) 2013 Marvell Inc.
+ *
+ * Author:
+ *	Chao Xie <xiechao.mail at gmail.com>
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include <linux/resource.h>
+#include <linux/delay.h>
+#include <linux/slab.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/io.h>
+#include <linux/err.h>
+#include <linux/clk.h>
+#include <linux/export.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/platform_data/mv_usb.h>
+#include <linux/usb/phy.h>
+#include <linux/usb/mv_usb2.h>
+
+/* phy regs */
+/* for pxa910 and mmp2, there is no revision register */
+#define MV_USB2_UTMI_REVISION		0x0
+#define MV_USB2_UTMI_CTRL		0x4
+#define MV_USB2_UTMI_PLL		0x8
+#define MV_USB2_UTMI_TX			0xc
+#define MV_USB2_UTMI_RX			0x10
+#define MV_USB2_UTMI_IVREF		0x14
+#define MV_USB2_UTMI_T0			0x18
+#define MV_USB2_UTMI_T1			0x1c
+#define MV_USB2_UTMI_T2			0x20
+#define MV_USB2_UTMI_T3			0x24
+#define MV_USB2_UTMI_T4			0x28
+#define MV_USB2_UTMI_T5			0x2c
+#define MV_USB2_UTMI_RESERVE		0x30
+#define MV_USB2_UTMI_USB_INT		0x34
+#define MV_USB2_UTMI_DBG_CTL		0x38
+#define MV_USB2_UTMI_OTG_ADDON		0x3c
+
+/* For UTMICTRL Register */
+#define MV_USB2_UTMI_CTRL_USB_CLK_EN			(1 << 31)
+/* pxa168 */
+#define MV_USB2_UTMI_CTRL_SUSPEND_SET1			(1 << 30)
+#define MV_USB2_UTMI_CTRL_SUSPEND_SET2			(1 << 29)
+#define MV_USB2_UTMI_CTRL_RXBUF_PDWN			(1 << 24)
+#define MV_USB2_UTMI_CTRL_TXBUF_PDWN			(1 << 11)
+
+#define MV_USB2_UTMI_CTRL_INPKT_DELAY_SHIFT		30
+#define MV_USB2_UTMI_CTRL_INPKT_DELAY_SOF_SHIFT		28
+#define MV_USB2_UTMI_CTRL_PU_REF_SHIFT			20
+#define MV_USB2_UTMI_CTRL_ARC_PULLDN_SHIFT		12
+#define MV_USB2_UTMI_CTRL_PLL_PWR_UP_SHIFT		1
+#define MV_USB2_UTMI_CTRL_PWR_UP_SHIFT			0
+
+/* For UTMI_PLL Register */
+#define MV_USB2_UTMI_PLL_PLLCALI12_SHIFT		29
+#define MV_USB2_UTMI_PLL_PLLCALI12_MASK			(0x3 << 29)
+
+#define MV_USB2_UTMI_PLL_PLLVDD18_SHIFT			27
+#define MV_USB2_UTMI_PLL_PLLVDD18_MASK			(0x3 << 27)
+
+#define MV_USB2_UTMI_PLL_PLLVDD12_SHIFT			25
+#define MV_USB2_UTMI_PLL_PLLVDD12_MASK			(0x3 << 25)
+
+#define MV_USB2_UTMI_PLL_PLL_READY			(0x1 << 23)
+#define MV_USB2_UTMI_PLL_KVCO_EXT			(0x1 << 22)
+#define MV_USB2_UTMI_PLL_VCOCAL_START			(0x1 << 21)
+
+#define MV_USB2_UTMI_PLL_KVCO_SHIFT			15
+#define MV_USB2_UTMI_PLL_KVCO_MASK			(0x7 << 15)
+
+#define MV_USB2_UTMI_PLL_ICP_SHIFT			12
+#define MV_USB2_UTMI_PLL_ICP_MASK			(0x7 << 12)
+
+#define MV_USB2_UTMI_PLL_FBDIV_SHIFT			4
+#define MV_USB2_UTMI_PLL_FBDIV_MASK			(0xFF << 4)
+
+#define MV_USB2_UTMI_PLL_REFDIV_SHIFT			0
+#define MV_USB2_UTMI_PLL_REFDIV_MASK			(0xF << 0)
+
+/* For UTMI_TX Register */
+#define MV_USB2_UTMI_TX_REG_EXT_FS_RCAL_SHIFT		27
+#define MV_USB2_UTMI_TX_REG_EXT_FS_RCAL_MASK		(0xf << 27)
+
+#define MV_USB2_UTMI_TX_REG_EXT_FS_RCAL_EN_SHIFT	26
+#define MV_USB2_UTMI_TX_REG_EXT_FS_RCAL_EN_MASK		(0x1 << 26)
+
+#define MV_USB2_UTMI_TX_TXVDD12_SHIFT			22
+#define MV_USB2_UTMI_TX_TXVDD12_MASK			(0x3 << 22)
+
+#define MV_USB2_UTMI_TX_CK60_PHSEL_SHIFT		17
+#define MV_USB2_UTMI_TX_CK60_PHSEL_MASK			(0xf << 17)
+
+#define MV_USB2_UTMI_TX_IMPCAL_VTH_SHIFT		14
+#define MV_USB2_UTMI_TX_IMPCAL_VTH_MASK			(0x7 << 14)
+
+#define MV_USB2_UTMI_TX_REG_RCAL_START			(0x1 << 12)
+
+#define MV_USB2_UTMI_TX_LOW_VDD_EN_SHIFT		11
+
+#define MV_USB2_UTMI_TX_AMP_SHIFT			0
+#define MV_USB2_UTMI_TX_AMP_MASK			(0x7 << 0)
+
+/* For UTMI_RX Register */
+#define MV_USB2_UTMI_RX_REG_SQ_LENGTH_SHIFT		15
+#define MV_USB2_UTMI_RX_REG_SQ_LENGTH_MASK		(0x3 << 15)
+
+#define MV_USB2_UTMI_RX_SQ_THRESH_SHIFT			4
+#define MV_USB2_UTMI_RX_SQ_THRESH_MASK			(0xf << 4)
+
+/* For UTMI_OTG_ADDON Register. Only for pxa168 */
+#define MV_USB2_UTMI_OTG_ADDON_OTG_ON			(1 << 0)
+
+enum mv_usb2_phy_type {
+	PXA168_USB,
+	PXA910_USB,
+	MMP2_USB,
+};
+
+static int _mv_usb2_phy_init(struct mv_usb2_phy *mv_phy)
+{
+	struct platform_device *pdev = mv_phy->pdev;
+	unsigned int loops = 0;
+	void __iomem *base = mv_phy->base;
+	unsigned int val;
+
+	val = readl(base + MV_USB2_UTMI_CTRL);
+	/* Initialize the USB PHY power */
+	if (mv_phy->type == PXA910_USB) {
+		val |= (1 << MV_USB2_UTMI_CTRL_INPKT_DELAY_SOF_SHIFT)
+			| (1 << MV_USB2_UTMI_CTRL_PU_REF_SHIFT);
+	}
+
+	val |= (1 << MV_USB2_UTMI_CTRL_PLL_PWR_UP_SHIFT)
+		| (1 << MV_USB2_UTMI_CTRL_PWR_UP_SHIFT);
+	writel(val, base + MV_USB2_UTMI_CTRL);
+
+	/* UTMI_PLL settings */
+	val = readl(base + MV_USB2_UTMI_PLL);
+	val &= ~(MV_USB2_UTMI_PLL_PLLVDD18_MASK
+		| MV_USB2_UTMI_PLL_PLLVDD12_MASK
+		| MV_USB2_UTMI_PLL_PLLCALI12_MASK
+		| MV_USB2_UTMI_PLL_FBDIV_MASK
+		| MV_USB2_UTMI_PLL_REFDIV_MASK
+		| MV_USB2_UTMI_PLL_ICP_MASK
+		| MV_USB2_UTMI_PLL_KVCO_MASK
+		| MV_USB2_UTMI_PLL_VCOCAL_START);
+
+	val |= (0xee << MV_USB2_UTMI_PLL_FBDIV_SHIFT)
+		| (0xb << MV_USB2_UTMI_PLL_REFDIV_SHIFT)
+		| (3 << MV_USB2_UTMI_PLL_PLLVDD18_SHIFT)
+		| (3 << MV_USB2_UTMI_PLL_PLLVDD12_SHIFT)
+		| (3 << MV_USB2_UTMI_PLL_PLLCALI12_SHIFT)
+		| (1 << MV_USB2_UTMI_PLL_ICP_SHIFT)
+		| (3 << MV_USB2_UTMI_PLL_KVCO_SHIFT);
+	writel(val, base + MV_USB2_UTMI_PLL);
+
+	/* UTMI_TX */
+	val = readl(base + MV_USB2_UTMI_TX);
+	val &= ~(MV_USB2_UTMI_TX_REG_EXT_FS_RCAL_EN_MASK
+		| MV_USB2_UTMI_TX_TXVDD12_MASK
+		| MV_USB2_UTMI_TX_CK60_PHSEL_MASK
+		| MV_USB2_UTMI_TX_IMPCAL_VTH_MASK
+		| MV_USB2_UTMI_TX_REG_EXT_FS_RCAL_MASK
+		| MV_USB2_UTMI_TX_AMP_MASK
+		| MV_USB2_UTMI_TX_REG_RCAL_START);
+	val |= (3 << MV_USB2_UTMI_TX_TXVDD12_SHIFT)
+		| (4 << MV_USB2_UTMI_TX_CK60_PHSEL_SHIFT)
+		| (4 << MV_USB2_UTMI_TX_IMPCAL_VTH_SHIFT)
+		| (8 << MV_USB2_UTMI_TX_REG_EXT_FS_RCAL_SHIFT)
+		| (3 << MV_USB2_UTMI_TX_AMP_SHIFT);
+	writel(val, base + MV_USB2_UTMI_TX);
+
+	/* UTMI_RX */
+	val = readl(base + MV_USB2_UTMI_RX);
+	val &= ~(MV_USB2_UTMI_RX_SQ_THRESH_MASK
+		| MV_USB2_UTMI_RX_REG_SQ_LENGTH_MASK);
+	val |= (7 << MV_USB2_UTMI_RX_SQ_THRESH_SHIFT)
+		| (2 << MV_USB2_UTMI_RX_REG_SQ_LENGTH_SHIFT);
+	writel(val, base + MV_USB2_UTMI_RX);
+
+	/* UTMI_IVREF */
+	if (mv_phy->type == PXA168_USB)
+		/*
+		 * Fixing Microsoft Altair board interface with NEC hub issue -
+		 * Set UTMI_IVREF from 0x4a3 to 0x4bf.
+		 */
+		writel(0x4bf, base + MV_USB2_UTMI_IVREF);
+
+	/*
+	 * Toggle VCOCAL_START bit of UTMI_PLL. It is active at rising edge.
+	 * It is low level by UTMI_PLL initialization above.
+	 */
+	val = readl(base + MV_USB2_UTMI_PLL);
+	/*
+	 * Delay 200us for low level, and 40us for high level.
+	 * Make sure we can get a effective rising edege.
+	 * It should be set to low after issue rising edge.
+	 * The delay value is suggested by DE.
+	 */
+	usleep_range(200, 300);
+	val |= MV_USB2_UTMI_PLL_VCOCAL_START;
+	writel(val, base + MV_USB2_UTMI_PLL);
+	usleep_range(40, 50);
+	val &= ~MV_USB2_UTMI_PLL_VCOCAL_START;
+	writel(val, base + MV_USB2_UTMI_PLL);
+
+	/*
+	 * Toggle REG_RCAL_START bit of UTMI_TX.
+	 * it is low level by UTMI_TX initialization above.
+	 */
+	val = readl(base + MV_USB2_UTMI_TX);
+	/* same as VCOCAL_START, except it is triggered by low->high->low */
+	usleep_range(400, 500);
+	val |= MV_USB2_UTMI_TX_REG_RCAL_START;
+	writel(val, base + MV_USB2_UTMI_TX);
+	usleep_range(40, 50);
+	val &= ~MV_USB2_UTMI_TX_REG_RCAL_START;
+	writel(val, base + MV_USB2_UTMI_TX);
+	usleep_range(400, 500);
+
+	/* Make sure PHY PLL is ready */
+	loops = 0;
+	while (1) {
+		val = readl(base + MV_USB2_UTMI_PLL);
+		if (val & MV_USB2_UTMI_PLL_PLL_READY)
+			break;
+		usleep_range(1000, 1100);
+		loops++;
+		if (loops > 100) {
+			dev_warn(&pdev->dev, "calibrate timeout, UTMI_PLL %x\n",
+				 readl(base + MV_USB2_UTMI_PLL));
+			return -ETIME;
+		}
+	}
+
+	if (mv_phy->type == PXA168_USB) {
+		val = readl(base + MV_USB2_UTMI_RESERVE);
+		val |= (1 << 5);
+		writel(val, base + MV_USB2_UTMI_RESERVE);
+		/* Turn on UTMI PHY OTG extension */
+		writel(MV_USB2_UTMI_OTG_ADDON_OTG_ON,
+		       base + MV_USB2_UTMI_OTG_ADDON);
+	}
+
+	return 0;
+}
+
+static int _mv_usb2_phy_shutdown(struct mv_usb2_phy *mv_phy)
+{
+	void __iomem *base = mv_phy->base;
+	unsigned int val;
+
+	if (mv_phy->type == PXA168_USB)
+		writel(0, base + MV_USB2_UTMI_OTG_ADDON);
+
+	val = readl(base + MV_USB2_UTMI_CTRL);
+	val &= ~(MV_USB2_UTMI_CTRL_RXBUF_PDWN
+		| MV_USB2_UTMI_CTRL_TXBUF_PDWN
+		| MV_USB2_UTMI_CTRL_USB_CLK_EN
+		| (1 << MV_USB2_UTMI_CTRL_PWR_UP_SHIFT)
+		| (1 << MV_USB2_UTMI_CTRL_PLL_PWR_UP_SHIFT));
+
+	writel(val, base + MV_USB2_UTMI_CTRL);
+
+	return 0;
+}
+
+static int mv_usb2_phy_init(struct usb_phy *phy)
+{
+	struct mv_usb2_phy *mv_phy = container_of(phy, struct mv_usb2_phy, phy);
+
+	clk_prepare_enable(mv_phy->clk);
+	_mv_usb2_phy_init(mv_phy);
+
+	return 0;
+}
+
+static void mv_usb2_phy_shutdown(struct usb_phy *phy)
+{
+	struct mv_usb2_phy *mv_phy = container_of(phy, struct mv_usb2_phy, phy);
+
+	_mv_usb2_phy_shutdown(mv_phy);
+	clk_disable_unprepare(mv_phy->clk);
+}
+
+static int mv_usb2_phy_probe(struct platform_device *pdev)
+{
+	struct mv_usb2_phy *mv_phy;
+	struct resource *r;
+	const struct platform_device_id *id;
+
+	mv_phy = devm_kzalloc(&pdev->dev, sizeof(*mv_phy), GFP_KERNEL);
+	if (mv_phy == NULL) {
+		dev_err(&pdev->dev, "failed to allocate memory\n");
+		return -ENOMEM;
+	}
+
+	id = platform_get_device_id(pdev);
+
+	if (id == NULL) {
+		dev_err(&pdev->dev, "missing id_entry\n");
+		return -ENODEV;
+	}
+
+	mv_phy->type = (unsigned int)(id->driver_data);
+	mv_phy->clk = devm_clk_get(&pdev->dev, NULL);
+	if (IS_ERR(mv_phy->clk)) {
+		dev_err(&pdev->dev, "failed to get clock.\n");
+		return PTR_ERR(mv_phy->clk);
+	}
+	r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	if (r == NULL) {
+		dev_err(&pdev->dev, "no phy I/O memory resource defined\n");
+		return -ENODEV;
+	}
+	mv_phy->base = devm_ioremap_resource(&pdev->dev, r);
+	if (mv_phy->base == NULL) {
+		dev_err(&pdev->dev, "error map register base\n");
+		return -EBUSY;
+	}
+
+	mv_phy->phy.dev = &pdev->dev;
+	mv_phy->phy.label = "mv-usb2";
+	mv_phy->phy.type = USB_PHY_TYPE_USB2;
+	mv_phy->phy.init = mv_usb2_phy_init;
+	mv_phy->phy.shutdown = mv_usb2_phy_shutdown;
+
+	usb_add_phy_dev(&mv_phy->phy);
+
+	platform_set_drvdata(pdev, mv_phy);
+
+	return 0;
+}
+
+static int mv_usb2_phy_remove(struct platform_device *pdev)
+{
+	struct mv_usb2_phy *mv_phy = platform_get_drvdata(pdev);
+
+	usb_remove_phy(&mv_phy->phy);
+
+	platform_set_drvdata(pdev, NULL);
+
+	return 0;
+}
+
+static struct platform_device_id mv_usb2_phy_ids[] = {
+	{ .name = "pxa168-usb-phy",	.driver_data = PXA168_USB },
+	{ .name = "pxa910-usb-phy",	.driver_data = PXA910_USB },
+	{ .name = "mmp2-usb-phy",	.driver_data = MMP2_USB },
+	{}
+};
+
+static struct platform_driver mv_usb2_phy_driver = {
+	.probe	= mv_usb2_phy_probe,
+	.remove = mv_usb2_phy_remove,
+	.driver = {
+		.name   = "pxa168-usb-phy",
+	},
+	.id_table = mv_usb2_phy_ids,
+};
+
+module_platform_driver(mv_usb2_phy_driver);
+MODULE_ALIAS("platform: mv_usb2");
+MODULE_AUTHOR("Marvell Inc.");
+MODULE_DESCRIPTION("Marvell USB2 phy driver");
+MODULE_LICENSE("GPL v2");
diff --git a/include/linux/usb/mv_usb2.h b/include/linux/usb/mv_usb2.h
new file mode 100644
index 0000000..dfabd4e
--- /dev/null
+++ b/include/linux/usb/mv_usb2.h
@@ -0,0 +1,29 @@
+/*
+ * Copyright (C) 2013 Marvell Inc.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#ifndef __MV_USB2_H
+#define __MV_USB2_H
+
+#define MV_USB2_PHY_INDEX	0
+#define MV_USB2_OTG_PHY_INDEX	1
+
+struct mv_usb2_phy {
+	struct usb_phy		phy;
+	struct platform_device	*pdev;
+	unsigned int		type;
+	void __iomem		*base;
+	struct clk		*clk;
+};
+
+#endif
-- 
1.7.4.1



From chao.xie at marvell.com  Wed Apr 24 02:23:19 2013
From: chao.xie at marvell.com (Chao Xie)
Date: Wed, 24 Apr 2013 02:23:19 -0400
Subject: [V9 PATCH 05/12] usb: phy: phy-mv-usb: use USB2 PHY driver for otg
In-Reply-To: <1366784606-1813-1-git-send-email-chao.xie@marvell.com>
References: <1366784606-1813-1-git-send-email-chao.xie@marvell.com>
Message-ID: <1366784606-1813-6-git-send-email-chao.xie@marvell.com>

Originaly, otg driver will call the callbacks in platform data
for PHY initialization and shut down.
With PHY driver, it will call the APIs provided by PHY driver
for PHY initialization and shut down. It removes the callbacks
in platform data, and at same time it removes one block in the
way of enabling device tree for otg driver.

Signed-off-by: Chao Xie <chao.xie at marvell.com>
---
 drivers/usb/phy/phy-mv-usb.c |   53 ++++++++++++++++++-----------------------
 drivers/usb/phy/phy-mv-usb.h |    2 +-
 2 files changed, 24 insertions(+), 31 deletions(-)

diff --git a/drivers/usb/phy/phy-mv-usb.c b/drivers/usb/phy/phy-mv-usb.c
index c987bbe..9938904 100644
--- a/drivers/usb/phy/phy-mv-usb.c
+++ b/drivers/usb/phy/phy-mv-usb.c
@@ -25,6 +25,7 @@
 #include <linux/usb/otg.h>
 #include <linux/usb/gadget.h>
 #include <linux/usb/hcd.h>
+#include <linux/usb/mv_usb2.h>
 #include <linux/platform_data/mv_usb.h>
 
 #include "phy-mv-usb.h"
@@ -255,15 +256,14 @@ static int mv_otg_enable_internal(struct mv_otg *mvotg)
 	dev_dbg(&mvotg->pdev->dev, "otg enabled\n");
 
 	otg_clock_enable(mvotg);
-	if (mvotg->pdata->phy_init) {
-		retval = mvotg->pdata->phy_init(mvotg->phy_regs);
-		if (retval) {
-			dev_err(&mvotg->pdev->dev,
-				"init phy error %d\n", retval);
-			otg_clock_disable(mvotg);
-			return retval;
-		}
+	retval = usb_phy_init(mvotg->outer_phy);
+	if (retval) {
+		dev_err(&mvotg->pdev->dev,
+			"failed to initialize phy %d\n", retval);
+		otg_clock_disable(mvotg);
+		return retval;
 	}
+
 	mvotg->active = 1;
 
 	return 0;
@@ -282,8 +282,7 @@ static void mv_otg_disable_internal(struct mv_otg *mvotg)
 {
 	if (mvotg->active) {
 		dev_dbg(&mvotg->pdev->dev, "otg disabled\n");
-		if (mvotg->pdata->phy_deinit)
-			mvotg->pdata->phy_deinit(mvotg->phy_regs);
+		usb_phy_shutdown(mvotg->outer_phy);
 		otg_clock_disable(mvotg);
 		mvotg->active = 0;
 	}
@@ -715,6 +714,7 @@ static int mv_otg_probe(struct platform_device *pdev)
 	/* OTG common part */
 	mvotg->pdev = pdev;
 	mvotg->phy.dev = &pdev->dev;
+	mvotg->phy.type = USB_PHY_TYPE_USB2;
 	mvotg->phy.otg = otg;
 	mvotg->phy.label = driver_name;
 	mvotg->phy.state = OTG_STATE_UNDEFINED;
@@ -727,23 +727,8 @@ static int mv_otg_probe(struct platform_device *pdev)
 	for (i = 0; i < OTG_TIMER_NUM; i++)
 		init_timer(&mvotg->otg_ctrl.timer[i]);
 
-	r = platform_get_resource_byname(mvotg->pdev,
-					 IORESOURCE_MEM, "phyregs");
-	if (r == NULL) {
-		dev_err(&pdev->dev, "no phy I/O memory resource defined\n");
-		retval = -ENODEV;
-		goto err_destroy_workqueue;
-	}
-
-	mvotg->phy_regs = devm_ioremap(&pdev->dev, r->start, resource_size(r));
-	if (mvotg->phy_regs == NULL) {
-		dev_err(&pdev->dev, "failed to map phy I/O memory\n");
-		retval = -EFAULT;
-		goto err_destroy_workqueue;
-	}
-
-	r = platform_get_resource_byname(mvotg->pdev,
-					 IORESOURCE_MEM, "capregs");
+	r = platform_get_resource(mvotg->pdev,
+					 IORESOURCE_MEM, 0);
 	if (r == NULL) {
 		dev_err(&pdev->dev, "no I/O memory resource defined\n");
 		retval = -ENODEV;
@@ -757,6 +742,14 @@ static int mv_otg_probe(struct platform_device *pdev)
 		goto err_destroy_workqueue;
 	}
 
+	mvotg->outer_phy = devm_usb_get_phy_dev(&pdev->dev, MV_USB2_PHY_INDEX);
+	if (IS_ERR_OR_NULL(mvotg->outer_phy)) {
+		retval = PTR_ERR(mvotg->outer_phy);
+		if (retval != -EPROBE_DEFER)
+			dev_err(&pdev->dev, "can not find outer phy\n");
+		goto err_destroy_workqueue;
+	}
+
 	/* we will acces controller register, so enable the udc controller */
 	retval = mv_otg_enable_internal(mvotg);
 	if (retval) {
@@ -816,7 +809,7 @@ static int mv_otg_probe(struct platform_device *pdev)
 		goto err_disable_clk;
 	}
 
-	retval = usb_add_phy(&mvotg->phy, USB_PHY_TYPE_USB2);
+	retval = usb_add_phy_dev(&mvotg->phy);
 	if (retval < 0) {
 		dev_err(&pdev->dev, "can't register transceiver, %d\n",
 			retval);
@@ -827,7 +820,7 @@ static int mv_otg_probe(struct platform_device *pdev)
 	if (retval < 0) {
 		dev_dbg(&pdev->dev,
 			"Can't register sysfs attr group: %d\n", retval);
-		goto err_remove_phy;
+		goto err_remove_otg_phy;
 	}
 
 	spin_lock_init(&mvotg->wq_lock);
@@ -842,7 +835,7 @@ static int mv_otg_probe(struct platform_device *pdev)
 
 	return 0;
 
-err_remove_phy:
+err_remove_otg_phy:
 	usb_remove_phy(&mvotg->phy);
 err_disable_clk:
 	mv_otg_disable_internal(mvotg);
diff --git a/drivers/usb/phy/phy-mv-usb.h b/drivers/usb/phy/phy-mv-usb.h
index 551da6e..6df6219 100644
--- a/drivers/usb/phy/phy-mv-usb.h
+++ b/drivers/usb/phy/phy-mv-usb.h
@@ -137,10 +137,10 @@ struct mv_otg_regs {
 
 struct mv_otg {
 	struct usb_phy phy;
+	struct usb_phy *outer_phy;
 	struct mv_otg_ctrl otg_ctrl;
 
 	/* base address */
-	void __iomem *phy_regs;
 	void __iomem *cap_regs;
 	struct mv_otg_regs __iomem *op_regs;
 
-- 
1.7.4.1



From chao.xie at marvell.com  Wed Apr 24 02:23:18 2013
From: chao.xie at marvell.com (Chao Xie)
Date: Wed, 24 Apr 2013 02:23:18 -0400
Subject: [V9 PATCH 04/12] usb: ehci: ehci-mv: use PHY driver for ehci
In-Reply-To: <1366784606-1813-1-git-send-email-chao.xie@marvell.com>
References: <1366784606-1813-1-git-send-email-chao.xie@marvell.com>
Message-ID: <1366784606-1813-5-git-send-email-chao.xie@marvell.com>

Originaly, ehci driver will call the callbacks in platform data
for PHY initialization and shut down.
With PHY driver, it will call the APIs provided by PHY driver
for PHY initialization and shut down. It removes the callbacks
in platform data, and at same time it removes one block in the
way of enabling device tree for ehci driver.

Signed-off-by: Chao Xie <chao.xie at marvell.com>
---
 drivers/usb/host/ehci-mv.c |   49 +++++++++++++++----------------------------
 1 files changed, 17 insertions(+), 32 deletions(-)

diff --git a/drivers/usb/host/ehci-mv.c b/drivers/usb/host/ehci-mv.c
index 6bad41a..adfc11f 100644
--- a/drivers/usb/host/ehci-mv.c
+++ b/drivers/usb/host/ehci-mv.c
@@ -15,17 +15,18 @@
 #include <linux/clk.h>
 #include <linux/err.h>
 #include <linux/usb/otg.h>
+#include <linux/usb/mv_usb2.h>
 #include <linux/platform_data/mv_usb.h>
 
 #define CAPLENGTH_MASK         (0xff)
 
 struct ehci_hcd_mv {
 	struct usb_hcd *hcd;
+	struct usb_phy *phy;
 
 	/* Which mode does this ehci running OTG/Host ? */
 	int mode;
 
-	void __iomem *phy_regs;
 	void __iomem *cap_regs;
 	void __iomem *op_regs;
 
@@ -48,22 +49,15 @@ static void ehci_clock_disable(struct ehci_hcd_mv *ehci_mv)
 
 static int mv_ehci_enable(struct ehci_hcd_mv *ehci_mv)
 {
-	int retval;
-
 	ehci_clock_enable(ehci_mv);
-	if (ehci_mv->pdata->phy_init) {
-		retval = ehci_mv->pdata->phy_init(ehci_mv->phy_regs);
-		if (retval)
-			return retval;
-	}
 
-	return 0;
+	return usb_phy_init(ehci_mv->phy);
 }
 
 static void mv_ehci_disable(struct ehci_hcd_mv *ehci_mv)
 {
-	if (ehci_mv->pdata->phy_deinit)
-		ehci_mv->pdata->phy_deinit(ehci_mv->phy_regs);
+	usb_phy_shutdown(ehci_mv->phy);
+
 	ehci_clock_disable(ehci_mv);
 }
 
@@ -169,22 +163,7 @@ static int mv_ehci_probe(struct platform_device *pdev)
 		goto err_clear_drvdata;
 	}
 
-	r = platform_get_resource_byname(pdev, IORESOURCE_MEM, "phyregs");
-	if (r == NULL) {
-		dev_err(&pdev->dev, "no phy I/O memory resource defined\n");
-		retval = -ENODEV;
-		goto err_clear_drvdata;
-	}
-
-	ehci_mv->phy_regs = devm_ioremap(&pdev->dev, r->start,
-					 resource_size(r));
-	if (ehci_mv->phy_regs == 0) {
-		dev_err(&pdev->dev, "failed to map phy I/O memory\n");
-		retval = -EFAULT;
-		goto err_clear_drvdata;
-	}
-
-	r = platform_get_resource_byname(pdev, IORESOURCE_MEM, "capregs");
+	r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 	if (!r) {
 		dev_err(&pdev->dev, "no I/O memory resource defined\n");
 		retval = -ENODEV;
@@ -199,6 +178,14 @@ static int mv_ehci_probe(struct platform_device *pdev)
 		goto err_clear_drvdata;
 	}
 
+	ehci_mv->phy = devm_usb_get_phy_dev(&pdev->dev, MV_USB2_PHY_INDEX);
+	if (IS_ERR_OR_NULL(ehci_mv->phy)) {
+		retval = PTR_ERR(ehci_mv->phy);
+		if (retval != -EPROBE_DEFER)
+			dev_err(&pdev->dev, "failed to get the outer phy\n");
+		goto err_clear_drvdata;
+	}
+
 	retval = mv_ehci_enable(ehci_mv);
 	if (retval) {
 		dev_err(&pdev->dev, "init phy error %d\n", retval);
@@ -225,14 +212,15 @@ static int mv_ehci_probe(struct platform_device *pdev)
 
 	ehci_mv->mode = pdata->mode;
 	if (ehci_mv->mode == MV_USB_MODE_OTG) {
-		ehci_mv->otg = devm_usb_get_phy(&pdev->dev, USB_PHY_TYPE_USB2);
+		ehci_mv->otg = devm_usb_get_phy_dev(&pdev->dev,
+						MV_USB2_OTG_PHY_INDEX);
 		if (IS_ERR(ehci_mv->otg)) {
 			retval = PTR_ERR(ehci_mv->otg);
 
 			if (retval == -ENXIO)
 				dev_info(&pdev->dev, "MV_USB_MODE_OTG "
 						"must have CONFIG_USB_PHY enabled\n");
-			else
+			else if (retval != -EPROBE_DEFER)
 				dev_err(&pdev->dev,
 						"unable to find transceiver\n");
 			goto err_disable_clk;
@@ -259,9 +247,6 @@ static int mv_ehci_probe(struct platform_device *pdev)
 		}
 	}
 
-	if (pdata->private_init)
-		pdata->private_init(ehci_mv->op_regs, ehci_mv->phy_regs);
-
 	dev_info(&pdev->dev,
 		 "successful find EHCI device with regs 0x%p irq %d"
 		 " working in %s mode\n", hcd->regs, hcd->irq,
-- 
1.7.4.1



From chao.xie at marvell.com  Wed Apr 24 02:23:20 2013
From: chao.xie at marvell.com (Chao Xie)
Date: Wed, 24 Apr 2013 02:23:20 -0400
Subject: [V9 PATCH 06/12] usb: mv_u3d: usb phy drivers for phy operation
In-Reply-To: <1366784606-1813-1-git-send-email-chao.xie@marvell.com>
References: <1366784606-1813-1-git-send-email-chao.xie@marvell.com>
Message-ID: <1366784606-1813-7-git-send-email-chao.xie@marvell.com>

The phy_init and phy_deinit APIs are removed from the pdata.
Directly get the phy driver and invoke the callbacks of phy
drivers for phy initialization and shutdown.

Signed-off-by: Chao Xie <chao.xie at marvell.com>
---
 drivers/usb/gadget/mv_u3d.h      |    3 +-
 drivers/usb/gadget/mv_u3d_core.c |   54 ++++++++++++++-----------------------
 2 files changed, 23 insertions(+), 34 deletions(-)

diff --git a/drivers/usb/gadget/mv_u3d.h b/drivers/usb/gadget/mv_u3d.h
index e32a787..0a0c7e3 100644
--- a/drivers/usb/gadget/mv_u3d.h
+++ b/drivers/usb/gadget/mv_u3d.h
@@ -251,7 +251,6 @@ struct mv_u3d {
 	struct mv_u3d_cap_regs __iomem	*cap_regs;
 	struct mv_u3d_op_regs __iomem	*op_regs;
 	struct mv_u3d_vuc_regs __iomem	*vuc_regs;
-	void __iomem			*phy_regs;
 
 	unsigned int			max_eps;
 	struct mv_u3d_ep_context	*ep_context;
@@ -283,6 +282,8 @@ struct mv_u3d {
 	struct mv_usb_addon_irq *vbus;
 	unsigned int		power;
 
+	struct usb_phy		*phy;
+
 	struct clk		*clk;
 };
 
diff --git a/drivers/usb/gadget/mv_u3d_core.c b/drivers/usb/gadget/mv_u3d_core.c
index 58288e9..bb92c5b 100644
--- a/drivers/usb/gadget/mv_u3d_core.c
+++ b/drivers/usb/gadget/mv_u3d_core.c
@@ -24,6 +24,7 @@
 #include <linux/device.h>
 #include <linux/usb/ch9.h>
 #include <linux/usb/gadget.h>
+#include <linux/usb/phy.h>
 #include <linux/pm.h>
 #include <linux/io.h>
 #include <linux/irq.h>
@@ -1109,7 +1110,6 @@ static int mv_u3d_controller_reset(struct mv_u3d *u3d)
 
 static int mv_u3d_enable(struct mv_u3d *u3d)
 {
-	struct mv_usb_platform_data *pdata = u3d->dev->platform_data;
 	int retval;
 
 	if (u3d->active)
@@ -1122,14 +1122,12 @@ static int mv_u3d_enable(struct mv_u3d *u3d)
 
 	dev_dbg(u3d->dev, "enable u3d\n");
 	clk_enable(u3d->clk);
-	if (pdata->phy_init) {
-		retval = pdata->phy_init(u3d->phy_regs);
-		if (retval) {
-			dev_err(u3d->dev,
-				"init phy error %d\n", retval);
-			clk_disable(u3d->clk);
-			return retval;
-		}
+	retval = usb_phy_init(u3d->phy);
+	if (retval) {
+		dev_err(u3d->dev,
+			"init phy error %d\n", retval);
+		clk_disable(u3d->clk);
+		return retval;
 	}
 	u3d->active = 1;
 
@@ -1138,11 +1136,9 @@ static int mv_u3d_enable(struct mv_u3d *u3d)
 
 static void mv_u3d_disable(struct mv_u3d *u3d)
 {
-	struct mv_usb_platform_data *pdata = u3d->dev->platform_data;
 	if (u3d->clock_gating && u3d->active) {
 		dev_dbg(u3d->dev, "disable u3d\n");
-		if (pdata->phy_deinit)
-			pdata->phy_deinit(u3d->phy_regs);
+		usb_phy_shutdown(u3d->phy);
 		clk_disable(u3d->clk);
 		u3d->active = 0;
 	}
@@ -1246,7 +1242,6 @@ static int mv_u3d_start(struct usb_gadget *g,
 		struct usb_gadget_driver *driver)
 {
 	struct mv_u3d *u3d = container_of(g, struct mv_u3d, gadget);
-	struct mv_usb_platform_data *pdata = u3d->dev->platform_data;
 	unsigned long flags;
 
 	if (u3d->driver)
@@ -1256,8 +1251,7 @@ static int mv_u3d_start(struct usb_gadget *g,
 
 	if (!u3d->clock_gating) {
 		clk_enable(u3d->clk);
-		if (pdata->phy_init)
-			pdata->phy_init(u3d->phy_regs);
+		usb_phy_init(u3d->phy);
 	}
 
 	/* hook up the driver ... */
@@ -1277,7 +1271,6 @@ static int mv_u3d_stop(struct usb_gadget *g,
 		struct usb_gadget_driver *driver)
 {
 	struct mv_u3d *u3d = container_of(g, struct mv_u3d, gadget);
-	struct mv_usb_platform_data *pdata = u3d->dev->platform_data;
 	unsigned long flags;
 
 	u3d->vbus_valid_detect = 0;
@@ -1285,8 +1278,7 @@ static int mv_u3d_stop(struct usb_gadget *g,
 
 	/* enable clock to access controller register */
 	clk_enable(u3d->clk);
-	if (pdata->phy_init)
-		pdata->phy_init(u3d->phy_regs);
+	usb_phy_init(u3d->phy);
 
 	mv_u3d_controller_stop(u3d);
 	/* stop all usb activities */
@@ -1294,8 +1286,7 @@ static int mv_u3d_stop(struct usb_gadget *g,
 	mv_u3d_stop_activity(u3d, driver);
 	mv_u3d_disable(u3d);
 
-	if (pdata->phy_deinit)
-		pdata->phy_deinit(u3d->phy_regs);
+	usb_phy_shutdown(u3d->phy);
 	clk_disable(u3d->clk);
 
 	spin_unlock_irqrestore(&u3d->lock, flags);
@@ -1827,7 +1818,7 @@ static int mv_u3d_probe(struct platform_device *dev)
 		goto err_get_clk;
 	}
 
-	r = platform_get_resource_byname(dev, IORESOURCE_MEM, "capregs");
+	r = platform_get_resource_byname(dev, IORESOURCE_MEM, 0);
 	if (!r) {
 		dev_err(&dev->dev, "no I/O memory resource defined\n");
 		retval = -ENODEV;
@@ -1846,15 +1837,14 @@ static int mv_u3d_probe(struct platform_device *dev)
 			(unsigned long) u3d->cap_regs);
 	}
 
-	/* we will access controller register, so enable the u3d controller */
-	clk_enable(u3d->clk);
+	u3d->phy = devm_usb_get_phy(&dev->dev, USB_PHY_TYPE_USB3);
+	if (IS_ERR_OR_NULL(u3d->phy))
+		goto err_u3d_enable;
 
-	if (pdata->phy_init) {
-		retval = pdata->phy_init(u3d->phy_regs);
-		if (retval) {
-			dev_err(&dev->dev, "init phy error %d\n", retval);
-			goto err_u3d_enable;
-		}
+	retval = usb_phy_init(u3d->phy);
+	if (retval) {
+		dev_err(&dev->dev, "init phy error %d\n", retval);
+		goto err_u3d_enable;
 	}
 
 	u3d->op_regs = (struct mv_u3d_op_regs __iomem *)(u3d->cap_regs
@@ -1872,8 +1862,7 @@ static int mv_u3d_probe(struct platform_device *dev)
 	mv_u3d_controller_stop(u3d);
 	iowrite32(0xFFFFFFFF, &u3d->vuc_regs->intrcause);
 
-	if (pdata->phy_deinit)
-		pdata->phy_deinit(u3d->phy_regs);
+	usb_phy_shutdown(u3d->phy);
 	clk_disable(u3d->clk);
 
 	size = u3d->max_eps * sizeof(struct mv_u3d_ep_context) * 2;
@@ -1988,8 +1977,7 @@ err_alloc_trb_pool:
 	dma_free_coherent(&dev->dev, u3d->ep_context_size,
 		u3d->ep_context, u3d->ep_context_dma);
 err_alloc_ep_context:
-	if (pdata->phy_deinit)
-		pdata->phy_deinit(u3d->phy_regs);
+	usb_phy_shutdown(u3d->phy);
 	clk_disable(u3d->clk);
 err_u3d_enable:
 	iounmap(u3d->cap_regs);
-- 
1.7.4.1



From chao.xie at marvell.com  Wed Apr 24 02:23:23 2013
From: chao.xie at marvell.com (Chao Xie)
Date: Wed, 24 Apr 2013 02:23:23 -0400
Subject: [V9 PATCH 09/12] arm: ttc_dkb: modify usb support
In-Reply-To: <1366784606-1813-1-git-send-email-chao.xie@marvell.com>
References: <1366784606-1813-1-git-send-email-chao.xie@marvell.com>
Message-ID: <1366784606-1813-10-git-send-email-chao.xie@marvell.com>

for ttc_dkb board, we use phy driver for usb support.
Modify the usb support for udc/otg/ehci support.

Signed-off-by: Chao Xie <chao.xie at marvell.com>
---
 arch/arm/mach-mmp/ttc_dkb.c |   39 ++++++++++++++++++++++++++++++---------
 1 files changed, 30 insertions(+), 9 deletions(-)

diff --git a/arch/arm/mach-mmp/ttc_dkb.c b/arch/arm/mach-mmp/ttc_dkb.c
index 6528a5f..c8b9ed8 100644
--- a/arch/arm/mach-mmp/ttc_dkb.c
+++ b/arch/arm/mach-mmp/ttc_dkb.c
@@ -18,6 +18,8 @@
 #include <linux/i2c/pca953x.h>
 #include <linux/gpio.h>
 #include <linux/mfd/88pm860x.h>
+#include <linux/usb/phy.h>
+#include <linux/usb/mv_usb2.h>
 #include <linux/platform_data/mv_usb.h>
 #include <linux/spi/spi.h>
 #include <linux/delay.h>
@@ -29,7 +31,6 @@
 #include <mach/mfp-pxa910.h>
 #include <mach/pxa910.h>
 #include <mach/irqs.h>
-#include <mach/regs-usb.h>
 
 #include "common.h"
 
@@ -166,8 +167,6 @@ static struct mv_usb_platform_data ttc_usb_pdata = {
 	.vbus		= NULL,
 	.mode		= MV_USB_MODE_OTG,
 	.otg_force_a_bus_req = 1,
-	.phy_init	= pxa_usb_phy_init,
-	.phy_deinit	= pxa_usb_phy_deinit,
 	.set_vbus	= NULL,
 };
 #endif
@@ -280,19 +279,41 @@ static void __init ttc_dkb_init(void)
 	pxa910_add_twsi(0, NULL, ARRAY_AND_SIZE(ttc_dkb_i2c_info));
 	platform_add_devices(ARRAY_AND_SIZE(ttc_dkb_devices));
 
+#ifdef CONFIG_USB_SUPPORT
+	pxa_register_device(&pxa910_device_u2ophy, NULL, 0);
+#endif
+
 #ifdef CONFIG_USB_MV_UDC
-	pxa168_device_u2o.dev.platform_data = &ttc_usb_pdata;
-	platform_device_register(&pxa168_device_u2o);
+	/* for usb2 phy */
+	usb_bind_phy(pxa910_device_u2o.drv_name, MV_USB2_PHY_INDEX,
+		     pxa910_device_u2ophy.drv_name);
+#ifdef CONFIG_USB_MV_OTG
+	/* for usb2 otg phy */
+	usb_bind_phy(pxa910_device_u2o.drv_name, MV_USB2_OTG_PHY_INDEX,
+		     pxa910_device_u2ootg.drv_name);
+#endif
+	pxa_register_device(&pxa910_device_u2o, &ttc_usb_pdata,
+			    sizeof(ttc_usb_pdata));
 #endif
 
 #ifdef CONFIG_USB_EHCI_MV_U2O
-	pxa168_device_u2oehci.dev.platform_data = &ttc_usb_pdata;
-	platform_device_register(&pxa168_device_u2oehci);
+	/* for usb2 phy */
+	usb_bind_phy(pxa910_device_u2oehci.drv_name, MV_USB2_PHY_INDEX,
+		     pxa910_device_u2ophy.drv_name);
+#ifdef CONFIG_USB_MV_OTG
+	/* for usb2 otg phy */
+	usb_bind_phy(pxa910_device_u2oehci.drv_name, MV_USB2_OTG_PHY_INDEX,
+		     pxa910_device_u2ootg.drv_name);
+#endif
+	pxa_register_device(&pxa910_device_u2oehci, &ttc_usb_pdata,
+			    sizeof(ttc_usb_pdata));
 #endif
 
 #ifdef CONFIG_USB_MV_OTG
-	pxa168_device_u2ootg.dev.platform_data = &ttc_usb_pdata;
-	platform_device_register(&pxa168_device_u2ootg);
+	usb_bind_phy(pxa910_device_u2ootg.drv_name, MV_USB2_PHY_INDEX,
+		     pxa910_device_u2ophy.drv_name);
+	pxa_register_device(&pxa910_device_u2ootg, &ttc_usb_pdata,
+			    sizeof(ttc_usb_pdata));
 #endif
 
 #ifdef CONFIG_MMP_DISP
-- 
1.7.4.1



From chao.xie at marvell.com  Wed Apr 24 02:23:22 2013
From: chao.xie at marvell.com (Chao Xie)
Date: Wed, 24 Apr 2013 02:23:22 -0400
Subject: [V9 PATCH 08/12] arm: pxa910: change the defintion of usb devices
In-Reply-To: <1366784606-1813-1-git-send-email-chao.xie@marvell.com>
References: <1366784606-1813-1-git-send-email-chao.xie@marvell.com>
Message-ID: <1366784606-1813-9-git-send-email-chao.xie@marvell.com>

because phy is seperated from the usb controller driver,
we can use the common pxa_device_desc for device register.

Signed-off-by: Chao Xie <chao.xie at marvell.com>
---
 arch/arm/mach-mmp/include/mach/pxa910.h |    4 ++++
 arch/arm/mach-mmp/pxa910.c              |    4 ++++
 2 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-mmp/include/mach/pxa910.h b/arch/arm/mach-mmp/include/mach/pxa910.h
index b914afa..c695982 100644
--- a/arch/arm/mach-mmp/include/mach/pxa910.h
+++ b/arch/arm/mach-mmp/include/mach/pxa910.h
@@ -22,6 +22,10 @@ extern struct pxa_device_desc pxa910_device_nand;
 extern struct platform_device pxa168_device_u2o;
 extern struct platform_device pxa168_device_u2ootg;
 extern struct platform_device pxa168_device_u2oehci;
+extern struct pxa_device_desc pxa910_device_u2o;
+extern struct pxa_device_desc pxa910_device_u2ootg;
+extern struct pxa_device_desc pxa910_device_u2oehci;
+extern struct pxa_device_desc pxa910_device_u2ophy;
 extern struct pxa_device_desc pxa910_device_disp;
 extern struct pxa_device_desc pxa910_device_fb;
 extern struct pxa_device_desc pxa910_device_panel;
diff --git a/arch/arm/mach-mmp/pxa910.c b/arch/arm/mach-mmp/pxa910.c
index 36cb321..28fdce5 100644
--- a/arch/arm/mach-mmp/pxa910.c
+++ b/arch/arm/mach-mmp/pxa910.c
@@ -134,6 +134,10 @@ PXA910_DEVICE(pwm2, "pxa910-pwm", 1, NONE, 0xd401a400, 0x10);
 PXA910_DEVICE(pwm3, "pxa910-pwm", 2, NONE, 0xd401a800, 0x10);
 PXA910_DEVICE(pwm4, "pxa910-pwm", 3, NONE, 0xd401ac00, 0x10);
 PXA910_DEVICE(nand, "pxa3xx-nand", -1, NAND, 0xd4283000, 0x80, 97, 99);
+PXA910_DEVICE(u2ophy, "pxa910-usb-phy", -1, NONE, 0xd4207000, 0x1ff);
+PXA910_DEVICE(u2o, "mv-udc", -1, USB1, 0xd4208100, 0x1ff);
+PXA910_DEVICE(u2ootg, "mv-otg", -1, USB1, 0xd4208100, 0x1ff);
+PXA910_DEVICE(u2oehci, "mv-ehci", -1, USB1, 0xd4208100, 0x1ff);
 PXA910_DEVICE(disp, "mmp-disp", 0, LCD, 0xd420b000, 0x1ec);
 PXA910_DEVICE(fb, "mmp-fb", -1, NONE, 0, 0);
 PXA910_DEVICE(panel, "tpo-hvga", -1, NONE, 0, 0);
-- 
1.7.4.1



From chao.xie at marvell.com  Wed Apr 24 02:23:25 2013
From: chao.xie at marvell.com (Chao Xie)
Date: Wed, 24 Apr 2013 02:23:25 -0400
Subject: [V9 PATCH 11/12] arm: brownstone: add usb support for the board
In-Reply-To: <1366784606-1813-1-git-send-email-chao.xie@marvell.com>
References: <1366784606-1813-1-git-send-email-chao.xie@marvell.com>
Message-ID: <1366784606-1813-12-git-send-email-chao.xie@marvell.com>

for brownstone board, add the udc/otg/ehci support

Signed-off-by: Chao Xie <chao.xie at marvell.com>
---
 arch/arm/mach-mmp/brownstone.c |   56 ++++++++++++++++++++++++++++++++++++++++
 1 files changed, 56 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-mmp/brownstone.c b/arch/arm/mach-mmp/brownstone.c
index 2358011..aed553a 100644
--- a/arch/arm/mach-mmp/brownstone.c
+++ b/arch/arm/mach-mmp/brownstone.c
@@ -18,6 +18,9 @@
 #include <linux/regulator/max8649.h>
 #include <linux/regulator/fixed.h>
 #include <linux/mfd/max8925.h>
+#include <linux/usb/phy.h>
+#include <linux/usb/mv_usb2.h>
+#include <linux/platform_data/mv_usb.h>
 
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
@@ -195,6 +198,20 @@ static struct sram_platdata mmp2_isram_platdata = {
 	.granularity	= SRAM_GRANULARITY,
 };
 
+#ifdef CONFIG_USB_SUPPORT
+
+#if defined(CONFIG_USB_MV_UDC) || defined(CONFIG_USB_EHCI_MV_U2O)
+
+static struct mv_usb_platform_data brownstone_usb_pdata = {
+	.vbus		= NULL,
+	.mode		= MV_USB_MODE_OTG,
+	.otg_force_a_bus_req = 1,
+	.set_vbus	= NULL,
+};
+#endif
+#endif
+
+
 static void __init brownstone_init(void)
 {
 	mfp_config(ARRAY_AND_SIZE(brownstone_pin_config));
@@ -211,6 +228,45 @@ static void __init brownstone_init(void)
 
 	/* enable 5v regulator */
 	platform_device_register(&brownstone_v_5vp_device);
+
+#ifdef CONFIG_USB_SUPPORT
+	pxa_register_device(&mmp2_device_u2ophy, NULL, 0);
+#endif
+
+#ifdef CONFIG_USB_MV_UDC
+	/* for usb2 phy */
+	usb_bind_phy(mmp2_device_u2o.drv_name, MV_USB2_PHY_INDEX,
+		     mmp2_device_u2ophy.drv_name);
+#ifdef CONFIG_USB_MV_OTG
+	/* for usb2 otg phy */
+	usb_bind_phy(mmp2_device_u2o.drv_name, MV_USB2_OTG_PHY_INDEX,
+		     mmp2_device_u2ootg.drv_name);
+#endif
+	pxa_register_device(&mmp2_device_u2o, &brownstone_usb_pdata,
+			    sizeof(brownstone_usb_pdata));
+#endif
+
+#ifdef CONFIG_USB_EHCI_MV_U2O
+	/* for usb2 phy */
+	usb_bind_phy(mmp2_device_u2oehci.dev_name, MV_USB2_PHY_INDEX,
+		     mmp2_device_u2ophy.dev_name);
+#ifdef CONFIG_USB_MV_OTG
+	/* for usb2 otg phy */
+	usb_bind_phy(mmp2_device_u2oehci.drv_name, MV_USB2_OTG_PHY_INDEX,
+		     mmp2_device_u2ootg.drv_name);
+#endif
+	pxa_register_device(&mmp2_device_u2oehci, &brownstone_usb_pdata,
+			    sizeof(brownstone_usb_pdata));
+#endif
+
+#ifdef CONFIG_USB_MV_OTG
+	/* for usb2 phy */
+	usb_bind_phy(mmp2_device_u2ootg.dev_name, MV_USB2_PHY_INDEX,
+		     mmp2_device_u2ophy.dev_name);
+	pxa_register_device(&mmp2_device_u2ootg, &brownstone_usb_pdata,
+			    sizeof(brownstone_usb_pdata));
+#endif
+
 }
 
 MACHINE_START(BROWNSTONE, "Brownstone Development Platform")
-- 
1.7.4.1



From chao.xie at marvell.com  Wed Apr 24 02:23:24 2013
From: chao.xie at marvell.com (Chao Xie)
Date: Wed, 24 Apr 2013 02:23:24 -0400
Subject: [V9 PATCH 10/12] arm: mmp: remove unused usb devices
In-Reply-To: <1366784606-1813-1-git-send-email-chao.xie@marvell.com>
References: <1366784606-1813-1-git-send-email-chao.xie@marvell.com>
Message-ID: <1366784606-1813-11-git-send-email-chao.xie@marvell.com>

We defined new usb devices for usb ehci/udc/otg/phy.
So remove the old definitions.

Signed-off-by: Chao Xie <chao.xie at marvell.com>
---
 arch/arm/mach-mmp/include/mach/pxa910.h |    3 ---
 1 files changed, 0 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-mmp/include/mach/pxa910.h b/arch/arm/mach-mmp/include/mach/pxa910.h
index c695982..d17ffee 100644
--- a/arch/arm/mach-mmp/include/mach/pxa910.h
+++ b/arch/arm/mach-mmp/include/mach/pxa910.h
@@ -19,9 +19,6 @@ extern struct pxa_device_desc pxa910_device_pwm2;
 extern struct pxa_device_desc pxa910_device_pwm3;
 extern struct pxa_device_desc pxa910_device_pwm4;
 extern struct pxa_device_desc pxa910_device_nand;
-extern struct platform_device pxa168_device_u2o;
-extern struct platform_device pxa168_device_u2ootg;
-extern struct platform_device pxa168_device_u2oehci;
 extern struct pxa_device_desc pxa910_device_u2o;
 extern struct pxa_device_desc pxa910_device_u2ootg;
 extern struct pxa_device_desc pxa910_device_u2oehci;
-- 
1.7.4.1



From chao.xie at marvell.com  Wed Apr 24 02:23:15 2013
From: chao.xie at marvell.com (Chao Xie)
Date: Wed, 24 Apr 2013 02:23:15 -0400
Subject: [V9 PATCH 01/12] usb: phy: protect phy init and shutdown for mutiple
 deivces
In-Reply-To: <1366784606-1813-1-git-send-email-chao.xie@marvell.com>
References: <1366784606-1813-1-git-send-email-chao.xie@marvell.com>
Message-ID: <1366784606-1813-2-git-send-email-chao.xie@marvell.com>

Some USB devices will share same phy, so make the ->init
and ->shutdown to be protected.
Only first device will initialize the phy, and only last device
can shutdown phy.

Signed-off-by: Chao Xie <chao.xie at marvell.com>
---
 drivers/usb/phy/phy.c   |    6 ++++++
 include/linux/usb/phy.h |   22 ++++++++++++++++++----
 2 files changed, 24 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/phy/phy.c b/drivers/usb/phy/phy.c
index f52c006..168332b 100644
--- a/drivers/usb/phy/phy.c
+++ b/drivers/usb/phy/phy.c
@@ -329,6 +329,9 @@ int usb_add_phy(struct usb_phy *x, enum usb_phy_type type)
 		return -EINVAL;
 	}
 
+	mutex_init(&x->phy_mutex);
+	x->refcount = 0;
+
 	spin_lock_irqsave(&phy_lock, flags);
 
 	list_for_each_entry(phy, &phy_list, head) {
@@ -367,6 +370,9 @@ int usb_add_phy_dev(struct usb_phy *x)
 		return -EINVAL;
 	}
 
+	mutex_init(&x->phy_mutex);
+	x->refcount = 0;
+
 	spin_lock_irqsave(&phy_lock, flags);
 	list_for_each_entry(phy_bind, &phy_bind_list, list)
 		if (!(strcmp(phy_bind->phy_dev_name, dev_name(x->dev))))
diff --git a/include/linux/usb/phy.h b/include/linux/usb/phy.h
index 6b5978f..98d7e60 100644
--- a/include/linux/usb/phy.h
+++ b/include/linux/usb/phy.h
@@ -87,6 +87,14 @@ struct usb_phy {
 	/* to support controllers that have multiple transceivers */
 	struct list_head	head;
 
+	/*
+	 * PHY may be shared by multiple devices.
+	 * mutex and refcount are used to make sure PHY only initialize or
+	 * shutdown once.
+	 */
+	struct mutex		phy_mutex;
+	unsigned int		refcount;
+
 	/* initialize/shutdown the OTG controller */
 	int	(*init)(struct usb_phy *x);
 	void	(*shutdown)(struct usb_phy *x);
@@ -150,17 +158,23 @@ static inline int usb_phy_io_write(struct usb_phy *x, u32 val, u32 reg)
 static inline int
 usb_phy_init(struct usb_phy *x)
 {
-	if (x->init)
-		return x->init(x);
+	int ret = 0;
 
-	return 0;
+	mutex_lock(&x->phy_mutex);
+	if (x->refcount++ == 0 && x->init)
+		ret = x->init(x);
+	mutex_unlock(&x->phy_mutex);
+
+	return ret;
 }
 
 static inline void
 usb_phy_shutdown(struct usb_phy *x)
 {
-	if (x->shutdown)
+	mutex_lock(&x->phy_mutex);
+	if (--x->refcount == 0 && x->shutdown)
 		x->shutdown(x);
+	mutex_unlock(&x->phy_mutex);
 }
 
 static inline int
-- 
1.7.4.1



From chao.xie at marvell.com  Wed Apr 24 02:23:17 2013
From: chao.xie at marvell.com (Chao Xie)
Date: Wed, 24 Apr 2013 02:23:17 -0400
Subject: [V9 PATCH 03/12] usb: gadget: mv_udc: use PHY driver for udc
In-Reply-To: <1366784606-1813-1-git-send-email-chao.xie@marvell.com>
References: <1366784606-1813-1-git-send-email-chao.xie@marvell.com>
Message-ID: <1366784606-1813-4-git-send-email-chao.xie@marvell.com>

Originaly, udc driver will call the callbacks in platform data
for PHY initialization and shut down.
With PHY driver, it will call the APIs provided by PHY driver
for PHY initialization and shut down. It removes the callbacks
in platform data, and at same time it removes one block in the
way of enabling device tree for udc driver.

Signed-off-by: Chao Xie <chao.xie at marvell.com>
---
 drivers/usb/gadget/mv_udc.h      |    2 +-
 drivers/usb/gadget/mv_udc_core.c |   50 +++++++++++++-------------------------
 2 files changed, 18 insertions(+), 34 deletions(-)

diff --git a/drivers/usb/gadget/mv_udc.h b/drivers/usb/gadget/mv_udc.h
index be77f20..02f36fe 100644
--- a/drivers/usb/gadget/mv_udc.h
+++ b/drivers/usb/gadget/mv_udc.h
@@ -180,7 +180,6 @@ struct mv_udc {
 
 	struct mv_cap_regs __iomem	*cap_regs;
 	struct mv_op_regs __iomem	*op_regs;
-	void __iomem                    *phy_regs;
 	unsigned int			max_eps;
 	struct mv_dqh			*ep_dqh;
 	size_t				ep_dqh_size;
@@ -217,6 +216,7 @@ struct mv_udc {
 	struct work_struct	vbus_work;
 	struct workqueue_struct *qwork;
 
+	struct usb_phy		*phy;
 	struct usb_phy		*transceiver;
 
 	struct mv_usb_platform_data     *pdata;
diff --git a/drivers/usb/gadget/mv_udc_core.c b/drivers/usb/gadget/mv_udc_core.c
index c2a5702..a6beef6 100644
--- a/drivers/usb/gadget/mv_udc_core.c
+++ b/drivers/usb/gadget/mv_udc_core.c
@@ -35,6 +35,7 @@
 #include <linux/platform_device.h>
 #include <linux/clk.h>
 #include <linux/platform_data/mv_usb.h>
+#include <linux/usb/mv_usb2.h>
 #include <asm/unaligned.h>
 
 #include "mv_udc.h"
@@ -1083,15 +1084,14 @@ static int mv_udc_enable_internal(struct mv_udc *udc)
 
 	dev_dbg(&udc->dev->dev, "enable udc\n");
 	udc_clock_enable(udc);
-	if (udc->pdata->phy_init) {
-		retval = udc->pdata->phy_init(udc->phy_regs);
-		if (retval) {
-			dev_err(&udc->dev->dev,
-				"init phy error %d\n", retval);
-			udc_clock_disable(udc);
-			return retval;
-		}
+	retval = usb_phy_init(udc->phy);
+	if (retval) {
+		dev_err(&udc->dev->dev,
+			"init phy error %d\n", retval);
+		udc_clock_disable(udc);
+		return retval;
 	}
+
 	udc->active = 1;
 
 	return 0;
@@ -1109,8 +1109,7 @@ static void mv_udc_disable_internal(struct mv_udc *udc)
 {
 	if (udc->active) {
 		dev_dbg(&udc->dev->dev, "disable udc\n");
-		if (udc->pdata->phy_deinit)
-			udc->pdata->phy_deinit(udc->phy_regs);
+		usb_phy_shutdown(udc->phy);
 		udc_clock_disable(udc);
 		udc->active = 0;
 	}
@@ -2124,17 +2123,10 @@ static int mv_udc_probe(struct platform_device *pdev)
 	udc->dev = pdev;
 
 	if (pdata->mode == MV_USB_MODE_OTG) {
-		udc->transceiver = devm_usb_get_phy(&pdev->dev,
-					USB_PHY_TYPE_USB2);
-		if (IS_ERR(udc->transceiver)) {
-			retval = PTR_ERR(udc->transceiver);
-
-			if (retval == -ENXIO)
-				return retval;
-
-			udc->transceiver = NULL;
-			return -EPROBE_DEFER;
-		}
+		udc->transceiver = devm_usb_get_phy_dev(&pdev->dev,
+					MV_USB2_OTG_PHY_INDEX);
+		if (IS_ERR_OR_NULL(udc->transceiver))
+			return PTR_ERR(udc->transceiver);
 	}
 
 	/* udc only have one sysclk. */
@@ -2142,7 +2134,7 @@ static int mv_udc_probe(struct platform_device *pdev)
 	if (IS_ERR(udc->clk))
 		return PTR_ERR(udc->clk);
 
-	r = platform_get_resource_byname(udc->dev, IORESOURCE_MEM, "capregs");
+	r = platform_get_resource(udc->dev, IORESOURCE_MEM, 0);
 	if (r == NULL) {
 		dev_err(&pdev->dev, "no I/O memory resource defined\n");
 		return -ENODEV;
@@ -2155,17 +2147,9 @@ static int mv_udc_probe(struct platform_device *pdev)
 		return -EBUSY;
 	}
 
-	r = platform_get_resource_byname(udc->dev, IORESOURCE_MEM, "phyregs");
-	if (r == NULL) {
-		dev_err(&pdev->dev, "no phy I/O memory resource defined\n");
-		return -ENODEV;
-	}
-
-	udc->phy_regs = ioremap(r->start, resource_size(r));
-	if (udc->phy_regs == NULL) {
-		dev_err(&pdev->dev, "failed to map phy I/O memory\n");
-		return -EBUSY;
-	}
+	udc->phy = devm_usb_get_phy_dev(&pdev->dev, MV_USB2_PHY_INDEX);
+	if (IS_ERR_OR_NULL(udc->phy))
+		return PTR_ERR(udc->phy);
 
 	/* we will acces controller register, so enable the clk */
 	retval = mv_udc_enable_internal(udc);
-- 
1.7.4.1



From chao.xie at marvell.com  Wed Apr 24 02:23:21 2013
From: chao.xie at marvell.com (Chao Xie)
Date: Wed, 24 Apr 2013 02:23:21 -0400
Subject: [V9 PATCH 07/12] arm: mmp2: change the defintion of usb devices
In-Reply-To: <1366784606-1813-1-git-send-email-chao.xie@marvell.com>
References: <1366784606-1813-1-git-send-email-chao.xie@marvell.com>
Message-ID: <1366784606-1813-8-git-send-email-chao.xie@marvell.com>

add the udc/otg/ehci devices for mmp2

Signed-off-by: Chao Xie <chao.xie at marvell.com>
---
 arch/arm/mach-mmp/include/mach/mmp2.h |    4 ++++
 arch/arm/mach-mmp/mmp2.c              |    4 ++++
 2 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-mmp/include/mach/mmp2.h b/arch/arm/mach-mmp/include/mach/mmp2.h
index 0764f4e..95b6bd7 100644
--- a/arch/arm/mach-mmp/include/mach/mmp2.h
+++ b/arch/arm/mach-mmp/include/mach/mmp2.h
@@ -29,6 +29,10 @@ extern struct pxa_device_desc mmp2_device_sdh2;
 extern struct pxa_device_desc mmp2_device_sdh3;
 extern struct pxa_device_desc mmp2_device_asram;
 extern struct pxa_device_desc mmp2_device_isram;
+extern struct pxa_device_desc mmp2_device_u2o;
+extern struct pxa_device_desc mmp2_device_u2ootg;
+extern struct pxa_device_desc mmp2_device_u2oehci;
+extern struct pxa_device_desc mmp2_device_u2ophy;
 
 extern struct platform_device mmp2_device_gpio;
 
diff --git a/arch/arm/mach-mmp/mmp2.c b/arch/arm/mach-mmp/mmp2.c
index d94d114..e7b7642 100644
--- a/arch/arm/mach-mmp/mmp2.c
+++ b/arch/arm/mach-mmp/mmp2.c
@@ -149,6 +149,10 @@ MMP2_DEVICE(sdh3, "sdhci-pxav3", 3, MMC4, 0xd4281800, 0x120);
 MMP2_DEVICE(asram, "asram", -1, NONE, 0xe0000000, 0x4000);
 /* 0xd1000000 ~ 0xd101ffff is reserved for secure processor */
 MMP2_DEVICE(isram, "isram", -1, NONE, 0xd1020000, 0x18000);
+MMP2_DEVICE(u2ophy, "mmp2-usb-phy", -1, NONE, 0xd4207000, 0x1ff);
+MMP2_DEVICE(u2o, "mv-udc", -1, USB_OTG, 0xd4208100, 0x1ff);
+MMP2_DEVICE(u2ootg, "mv-otg", -1, USB_OTG, 0xd4208100, 0x1ff);
+MMP2_DEVICE(u2oehci, "mv-ehci", -1, USB_OTG, 0xd4208100, 0x1ff);
 
 struct resource mmp2_resource_gpio[] = {
 	{
-- 
1.7.4.1



From chao.xie at marvell.com  Wed Apr 24 02:23:26 2013
From: chao.xie at marvell.com (Chao Xie)
Date: Wed, 24 Apr 2013 02:23:26 -0400
Subject: [V9 PATCH 12/12] usb: mv_usb: remove the phy callbacks in pdata
In-Reply-To: <1366784606-1813-1-git-send-email-chao.xie@marvell.com>
References: <1366784606-1813-1-git-send-email-chao.xie@marvell.com>
Message-ID: <1366784606-1813-13-git-send-email-chao.xie@marvell.com>

The phy initialization code will be done by phy driver.

Signed-off-by: Chao Xie <chao.xie at marvell.com>
---
 include/linux/platform_data/mv_usb.h |    3 ---
 1 files changed, 0 insertions(+), 3 deletions(-)

diff --git a/include/linux/platform_data/mv_usb.h b/include/linux/platform_data/mv_usb.h
index 98b7925..b4b5d6f 100644
--- a/include/linux/platform_data/mv_usb.h
+++ b/include/linux/platform_data/mv_usb.h
@@ -45,9 +45,6 @@ struct mv_usb_platform_data {
 	/* Force a_bus_req to be asserted */
 	 unsigned int    otg_force_a_bus_req:1;
 
-	int	(*phy_init)(void __iomem *regbase);
-	void	(*phy_deinit)(void __iomem *regbase);
 	int	(*set_vbus)(unsigned int vbus);
-	int     (*private_init)(void __iomem *opregs, void __iomem *phyregs);
 };
 #endif
-- 
1.7.4.1



From lee.jones at linaro.org  Wed Apr 24 02:53:44 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Wed, 24 Apr 2013 07:53:44 +0100
Subject: [PATCH 04/10] usb: musb: ux500: harden checks for platform data
In-Reply-To: <5176E927.908@cogentembedded.com>
References: <1366729394-11406-1-git-send-email-lee.jones@linaro.org>
 <1366729394-11406-5-git-send-email-lee.jones@linaro.org>
 <5176E927.908@cogentembedded.com>
Message-ID: <20130424065344.GB17416@gmail.com>

Hi Sergei,

> >  	struct musb_hdrc_platform_data *plat = dev->platform_data;
> >-	struct ux500_musb_board_data *data = plat->board_data;
> >+	struct ux500_musb_board_data *data;

> >-	param_array = data->dma_rx_param_array;
> >+	param_array = (data) ? data->dma_rx_param_array : NULL;
> 
>    Why enclose a simple variable in parens?

Because 'data' is a pointer, so it contains a memory location, but if
'plat->board_data' is NULL, then 'data' will be NULL (essentially
memory location 0x00000000).

So if we were to read-in to 'struct ux500_musb_board_data *data', by
index 'dma_rx_param_array', which I believe is '0' in this case:

struct ux500_musb_board_data {
        void    **dma_rx_param_array;
        void    **dma_tx_param_array;
        bool (*dma_filter)(struct dma_chan *chan, void *filter_param);
};

... then we're saying take the data from this memory location:

param_array = *((0x00000000)->(0x0));

Which will cause a kernel Oops, due to the fact that address 0x0 isn't
allocated to us, so you get something like:

"Unable to handle kernel NULL pointer dereference at virtual address 00000000"

Hope that helps.

Kind regards,
Lee

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From sfr at canb.auug.org.au  Wed Apr 24 02:54:17 2013
From: sfr at canb.auug.org.au (Stephen Rothwell)
Date: Wed, 24 Apr 2013 16:54:17 +1000
Subject: linux-next: manual merge of the arm-soc tree with the pm tree
Message-ID: <20130424165417.5e2b74a01728d307e454750f@canb.auug.org.au>

Hi all,

Today's linux-next merge of the arm-soc tree got a conflict in
arch/arm/mach-exynos/cpuidle.c between commit 554c06ba3ee2 ("cpuidle:
remove en_core_tk_irqen flag") from the pm tree and commit 2eb89f893e44
("ARM: EXYNOS: factor out the idle states") from the arm-soc tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr at canb.auug.org.au

diff --cc arch/arm/mach-exynos/cpuidle.c
index 498a7a2,e2689d1..0000000
--- a/arch/arm/mach-exynos/cpuidle.c
+++ b/arch/arm/mach-exynos/cpuidle.c
@@@ -58,6 -46,20 +46,19 @@@ static DEFINE_PER_CPU(struct cpuidle_de
  static struct cpuidle_driver exynos4_idle_driver = {
  	.name			= "exynos4_idle",
  	.owner			= THIS_MODULE,
 -	.en_core_tk_irqen	= 1,
+ 	.states = {
+ 		[0] = ARM_CPUIDLE_WFI_STATE,
+ 		[1] = {
+ 			.enter			= exynos4_enter_lowpower,
+ 			.exit_latency		= 300,
+ 			.target_residency	= 100000,
+ 			.flags			= CPUIDLE_FLAG_TIME_VALID,
+ 			.name			= "C1",
+ 			.desc			= "ARM power down",
+ 		},
+ 	},
+ 	.state_count = 2,
+ 	.safe_state_index = 0,
  };
  
  /* Ext-GIC nIRQ/nFIQ is the only wakeup source in AFTR */
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130424/af841451/attachment.sig>

From maxime.ripard at free-electrons.com  Wed Apr 24 03:15:03 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Wed, 24 Apr 2013 09:15:03 +0200
Subject: [RFC PATCH v2 11/13] ARM: mach-sunxi: cpus/cpu nodes dts updates
In-Reply-To: <1366644455-16550-12-git-send-email-lorenzo.pieralisi@arm.com>
References: <1366644455-16550-1-git-send-email-lorenzo.pieralisi@arm.com>
 <1366644455-16550-12-git-send-email-lorenzo.pieralisi@arm.com>
Message-ID: <51778677.908@free-electrons.com>

Hi Lorenzo,

Le 22/04/2013 17:27, Lorenzo Pieralisi a ?crit :
> This patch updates the in-kernel dts files according to the latest cpus
> and cpu bindings updates for ARM.
> 
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
> ---
>  arch/arm/boot/dts/sunxi.dtsi | 4 ++++
>  1 file changed, 4 insertions(+)

Just to let you know, this file won't exist anymore in 3.10, and has
been split out in sun4i-a10.dtsi and sun5i-a13.dtsi. You'll obviously
need to change both when rebasing.

Other than that,
Acked-By: Maxime Ripard <maxime.ripard at free-electrons.com>

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


From loic.pallardy at st.com  Wed Apr 24 03:39:39 2013
From: loic.pallardy at st.com (Loic PALLARDY)
Date: Wed, 24 Apr 2013 09:39:39 +0200
Subject: [PATCHv3 00/14] drivers: mailbox: framework creation
In-Reply-To: <37C860A02101E749A747FA2D3C1E3C504A63B4@DLEE11.ent.ti.com>
References: <1363145021-14339-1-git-send-email-s-anna@ti.com>
 <CABb+yY0RYkVeo2Sb4WsDJY0jf17488FEz0d2CB994eQaSOEsVg@mail.gmail.com>
 <37C860A02101E749A747FA2D3C1E3C504A5DF7@DLEE11.ent.ti.com>
 <CABb+yY1x4x_A+QtGG9ohsLPgs8c3nEVnd_ExJBGOOR8=6YLPFA@mail.gmail.com>
 <37C860A02101E749A747FA2D3C1E3C504A63B4@DLEE11.ent.ti.com>
Message-ID: <51778C3B.7010501@st.com>

Hi Jassi, Suman,

On 04/23/2013 09:20 PM, Anna, Suman wrote:
> Hi Jassi,
>
>>
>> On Mon, Apr 22, 2013 at 9:26 PM, Anna, Suman<s-anna at ti.com>  wrote:
>>>>
>>>> a) No documentation. Usually the header would have proper
>>>> documentation of data structures and info for users of both side of the api.
>>>
>>> I will fix the documentation portion for 3.10. I will also add a TODO as part of the
>> documentation so that it highlights the gaps and work-items.
>>>
>>>>
>>>> b) The api is not scalable. The assumption of just one IPC controller
>>>> in the platform is hardcoded.
>>>
>>> Yes, this is a major concern and I will be handling this in the upcoming patches .
>> The current code was primarily based on moving the OMAP mailbox code and
>> expanding it to support the ST DBX500 mailbox. As it is today, it doesn't scale to
>> support multiple IP instances/controllers.
>>>
>>>>
>>>> c) There seems to be no consistent design - mailbox_ops has 12 callback
>> hooks.
>>>> Some, save_ctx, restore_ctx, enable_irq, disable_irq are exported for
>>>> no apparent reason (legacy of a legacy - OMAP), while other hooks are
>>>> kept private to the api.
>>>> I believe OMAP had valid reasons to make IPC clients save/restore
>>>> context of the IPC controller, but I don't think that is the case in
>>>> general. I2C client drivers don't save/restore context of I2C
>>>> controller's, why should IPC's?  Similarly enable/disable_irq of the controller
>> seem too intrusive for a client driver.
>>>
>>> Yep, these are exported because of the OMAP legacy TIDSPBRIDGE stack, and
>> should vanish with the addition of runtime_pm support.
>>>
>>>>
>>>> mailbox_ops.mailbox_type_t makes no sense to me. At least not without
>>>> documentation, though I doubt any amount of documentation could help
>>>> it - mailbox.c doesn't even read the member. Btw, isn't every mailbox
>>>> a MBOX_SHARED_MEM_TYPE? A part of data passed via FIFO/REG could
>>>> point to location in shared memory that might have full
>>>> command/payload for the message. Or did I get the meaning of
>>>> MBOX_SHARED_MEM_TYPE wrong in the absence of documentation?
>>>
>>> Yes, this needs to be removed, it is a carry-over from the OMAP mailbox code.
>>>
>>>>
>>>> The api seems to worry too much about the low-level details of the
>>>> IPC controller (save/restore context, enable/disable_irq and
>>>> ack_irq), while it fails to provide a tight well-defined interface to client drivers.
>>>>
>>>> There are also some code issues, which might come as replies to
>>>> respective patches.
>>>
>>> Thanks for the review of the patches. I will await your comments, and will
>> address them as incremental patches.
>>>
>> So we agree
>> a) Documentation is missing.
>> b) mailbox_type_t, save_ctx, restore_ctx, ack_irq, enable_irq, disable_irq need
>> to be removed.
>
> The mailbox_type_t can be removed right away, but for others, we should give some time for current users to migrate before we remove it completely.
>
>> c) Support for more than one IPC controllers is needed.
>>
>> Out of 11 exported functions, we'll be left with the 5 trivial ones
>> mailbox_un/register, mailbox_get/put and mailbox_msg_send.
>> mailbox_msg_send_no_irq and mailbox_msg_send_receive_no_irq are STE(?)
>> specific quirky requirements, which should be possible to simulate over the
>> mailbox API if designed well.
>
> Loic can comment on the existing xxx_no_irq API. The pl320_transmit is somewhat similar to mailbox_msg_send_receive_no_irq, without the irq part.
>
Yes, the xxx_no_irq API has been introduced to answer some STE 
requirements. It must be possible to send some message under atomic 
context for different reasons (latency, during idle/suspend procedures...).
This is not the best way to do, but the goal was to preserve TI legacy 
in a first step. As explained by Suman, this patch series is coming from 
the original TI mailbox framework and is modified step by step to fit 
with all platforms.

>>
>> Documentation wise, we'd need documentation for what we finally wanna have,
>> not the current implementation.
>>
>> There are also some desired features in a good API:-
>>
>> a) The API should be simple and efficient, i.e, submission of requests by clients
>> and notifications of data received by the API should be possible from atomic
>> context - most of the IPC is going to be about exchanging 'commands'. The API
>> shouldn't add to the latencies.
>
> I think we will have need for both types. It really depends on the purpose of the IPC h/w - some would be simple messaging and may not need the atomic constraints. Sure enough, atomic context is the stricter one, so we can add that. I don't see any users of it currently though.
>
>>
>> b) It would be very useful to allow submission of a new request from the
>> completion callback of last one.
>>
>> c) The request/free/ack_irq on behalf of the IPC controller driver should be no
>> business of the API. The API design should only assume a simple but generic
>> enough h/w model beneath it and provide support to h/w that doesn't have an
>> expected feature.
>>   For example, API should assume the IPC controller can detect and report when
>> the remote asserts Ready-To-Receive (RTR). This is when the API callbacks
>> .tx_done(mssg) on the client. If some h/w doesn't have RTR assertion interrupt,
>> the API should provide optional feature to poll the controller periodically.
>
> Some of these are already part of the mailbox ops. FWIW, I don?t see a need for a .tx_done callback, as this state can really be maintained by the driver implementation itself. The mailbox_msg_send can return an error appropriately based on whether the h/w is ready or not. The current code has the support for queuing up a certain number of messages in case the h/w is busy, but I am planning to change this to a device-based property so that they can choose if it needs that support or not.
>
>>
>> (d) The 'struct mailbox_msg' should be just an opaque void* - the client/protocol
>> driver typecasts to void* the IPC controller specific message structure. API
>> shouldn't aim the impossible of providing a generic message format.
>
> The size parameter would still be needed. Depending on the h/w, it can be just an u32 or a series of bytes, and even in the latter case, it is not guaranteed that all messages transmitted will occupy the entire h/w shared memory data packet. I can see the current header field getting absorbed into the opaque void * structure for the ST mailbox driver. The size and ptr together provide a very generic message format.
That's something we discussed with Suman. The mailbox framework should 
be independent from message format. Since mailbox could be base don a 
shared mem or an hw fifo, message size is mandatory to transmit the 
right number of data.

Regards,
Loic
>
>>
>> (a) and (b) are already proved to be useful and supported by a similar API -
>> DMAEngine.
>>
>> As you see there would be not much of the present left eventually. So I wonder
>> if should sculpt a new api out of TI's or start from scratch?
>> One of my controllers is similar to 'pl320' (which you left out converting to the
>> API). I am in process of implementing all this assuming it is OK to keep a controller
>> out of this API :)  So maybe we can collaborate on a new implementation from
>> scratch.
>
> This series missed the 3.9 merge window, and is currently slated for getting merged into 3.10. The PL320 made it into 3.9 itself (I wasn't aware of it until I saw it in mainline) and created the drivers/mailbox folder.  I would think it would be relatively straight-forward to adopt it to the mailbox API, as it has only 3 API. We should be doing incremental changes on top of this series, as most of the base API would still be the same. The current series is helping out with couple of efforts, the breaking up of the PRCMU code and on the multiplatform support for OMAP with mailbox enabled. We can definitely collaborate on the improvements. Andy Green would also be interested, as he is also looking into adopting the mailbox API.
>
> Regards
> Suman

From lee.jones at linaro.org  Wed Apr 24 03:41:46 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Wed, 24 Apr 2013 08:41:46 +0100
Subject: [PATCH 08/10 v2] ARM: ux500: Populate the ux500-musb Device Tree entry
In-Reply-To: <1366729394-11406-9-git-send-email-lee.jones@linaro.org>
References: <1366729394-11406-1-git-send-email-lee.jones@linaro.org>
 <1366729394-11406-9-git-send-email-lee.jones@linaro.org>
Message-ID: <20130424074146.GC17416@gmail.com>

This patch provides all the information to successfully probe() and
correctly configure the ux500-musb device driver for DMA.
    
Signed-off-by: Lee Jones <lee.jones at linaro.org>

diff --git a/arch/arm/boot/dts/dbx5x0.dtsi b/arch/arm/boot/dts/dbx5x0.dtsi
index 86b35a1..838214c 100644
--- a/arch/arm/boot/dts/dbx5x0.dtsi
+++ b/arch/arm/boot/dts/dbx5x0.dtsi
@@ -175,11 +175,40 @@
 			prcm = <&prcmu>;
 		};
 
-		usb at a03e0000 {
+		usb_per5 at a03e0000 {
 			compatible = "stericsson,db8500-musb",
 				"mentor,musb";
 			reg = <0xa03e0000 0x10000>;
 			interrupts = <0 23 0x4>;
+			interrupt-names = "mc";
+
+			dr_mode = "otg";
+
+			dmas = <&dma 38 0 0x2>, /* Logical - DevToMem */
+			       <&dma 38 0 0x0>, /* Logical - MemToDev */
+			       <&dma 37 0 0x2>, /* Logical - DevToMem */
+			       <&dma 37 0 0x0>, /* Logical - MemToDev */
+			       <&dma 36 0 0x2>, /* Logical - DevToMem */
+			       <&dma 36 0 0x0>, /* Logical - MemToDev */
+			       <&dma 19 0 0x2>, /* Logical - DevToMem */
+			       <&dma 19 0 0x0>, /* Logical - MemToDev */
+			       <&dma 18 0 0x2>, /* Logical - DevToMem */
+			       <&dma 18 0 0x0>, /* Logical - MemToDev */
+			       <&dma 17 0 0x2>, /* Logical - DevToMem */
+			       <&dma 17 0 0x0>, /* Logical - MemToDev */
+			       <&dma 16 0 0x2>, /* Logical - DevToMem */
+			       <&dma 16 0 0x0>, /* Logical - MemToDev */
+			       <&dma 39 0 0x2>, /* Logical - DevToMem */
+			       <&dma 39 0 0x0>; /* Logical - MemToDev */
+
+			dma-names = "iep_1_9",  "oep_1_9",
+				    "iep_2_10", "oep_2_10",
+				    "iep_3_11", "oep_3_11",
+				    "iep_4_12", "oep_4_12",
+				    "iep_5_13", "oep_5_13",
+				    "iep_6_14", "oep_6_14",
+				    "iep_7_15", "oep_7_15",
+				    "iep_8",    "oep_8";
 		};
 
 		dma: dma-controller at 801C0000 {


From lee.jones at linaro.org  Wed Apr 24 03:43:36 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Wed, 24 Apr 2013 08:43:36 +0100
Subject: [PATCH 06/10 v2] usb: musb: ux500: add device tree probing support
In-Reply-To: <1366729394-11406-7-git-send-email-lee.jones@linaro.org>
References: <1366729394-11406-1-git-send-email-lee.jones@linaro.org>
 <1366729394-11406-7-git-send-email-lee.jones@linaro.org>
Message-ID: <20130424074336.GD17416@gmail.com>

usb: musb: ux500: add device tree probing support

This patch will allow ux500-musb to be probed and configured solely from
configuration found in Device Tree.

Cc: Felipe Balbi <balbi at ti.com>
Cc: linux-usb at vger.kernel.org
Signed-off-by: Lee Jones <lee.jones at linaro.org>

diff --git a/Documentation/devicetree/bindings/usb/ux500-usb.txt b/Documentation/devicetree/bindings/usb/ux500-usb.txt
new file mode 100644
index 0000000..330d6ec
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/ux500-usb.txt
@@ -0,0 +1,50 @@
+Ux500 MUSB
+
+Required properties:
+ - compatible : Should be "stericsson,db8500-musb"
+ - reg        : Offset and length of registers
+ - interrupts : Interrupt; mode, number and trigger
+ - dr_mode    : Dual-role; either host mode "host", peripheral mode "peripheral"
+                or both "otg"
+
+Optional properties:
+ - dmas       : A list of dma channels;
+                dma-controller, event-line, fixed-channel, flags
+ - dma-names  : An ordered list of channel names affiliated to the above
+
+Example:
+
+usb_per5 at a03e0000 {
+	compatible = "stericsson,db8500-musb", "mentor,musb";
+	reg = <0xa03e0000 0x10000>;
+	interrupts = <0 23 0x4>;
+	interrupt-names = "mc";
+
+	dr_mode = "otg";
+
+	dmas = <&dma 38 0 0x2>, /* Logical - DevToMem */
+	       <&dma 38 0 0x0>, /* Logical - MemToDev */
+	       <&dma 37 0 0x2>, /* Logical - DevToMem */
+	       <&dma 37 0 0x0>, /* Logical - MemToDev */
+	       <&dma 36 0 0x2>, /* Logical - DevToMem */
+	       <&dma 36 0 0x0>, /* Logical - MemToDev */
+	       <&dma 19 0 0x2>, /* Logical - DevToMem */
+	       <&dma 19 0 0x0>, /* Logical - MemToDev */
+	       <&dma 18 0 0x2>, /* Logical - DevToMem */
+	       <&dma 18 0 0x0>, /* Logical - MemToDev */
+	       <&dma 17 0 0x2>, /* Logical - DevToMem */
+	       <&dma 17 0 0x0>, /* Logical - MemToDev */
+	       <&dma 16 0 0x2>, /* Logical - DevToMem */
+	       <&dma 16 0 0x0>, /* Logical - MemToDev */
+	       <&dma 39 0 0x2>, /* Logical - DevToMem */
+	       <&dma 39 0 0x0>; /* Logical - MemToDev */
+
+	dma-names = "iep_1_9",  "oep_1_9",
+		    "iep_2_10", "oep_2_10",
+		    "iep_3_11", "oep_3_11",
+		    "iep_4_12", "oep_4_12",
+		    "iep_5_13", "oep_5_13",
+		    "iep_6_14", "oep_6_14",
+		    "iep_7_15", "oep_7_15",
+		    "iep_8",    "oep_8";
+};
diff --git a/drivers/usb/musb/ux500.c b/drivers/usb/musb/ux500.c
index 7ddb132..5ff304c 100644
--- a/drivers/usb/musb/ux500.c
+++ b/drivers/usb/musb/ux500.c
@@ -25,6 +25,7 @@
 #include <linux/clk.h>
 #include <linux/err.h>
 #include <linux/io.h>
+#include <linux/of.h>
 #include <linux/platform_device.h>
 
 #include "musb_core.h"
@@ -88,14 +89,57 @@ static const struct musb_platform_ops ux500_ops = {
 	.exit		= ux500_musb_exit,
 };
 
+static struct musb_hdrc_platform_data *
+ux500_of_probe(struct platform_device *pdev, struct device_node *np)
+{
+	struct musb_hdrc_platform_data *pdata;
+	const char *mode;
+	int strlen;
+
+	pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
+	if (!pdata)
+		return NULL;
+
+	mode = of_get_property(np, "dr_mode", &strlen);
+	if (!mode) {
+		dev_err(&pdev->dev, "No 'dr_mode' property found\n");
+		return NULL;
+	}
+
+	if (strlen > 0) {
+		if (!strcmp(mode, "host"))
+			pdata->mode = MUSB_HOST;
+		if (!strcmp(mode, "otg"))
+			pdata->mode = MUSB_OTG;
+		if (!strcmp(mode, "peripheral"))
+			pdata->mode = MUSB_PERIPHERAL;
+	}
+
+	return pdata;
+}
+
 static int ux500_probe(struct platform_device *pdev)
 {
 	struct musb_hdrc_platform_data	*pdata = pdev->dev.platform_data;
+	struct device_node		*np = pdev->dev.of_node;
 	struct platform_device		*musb;
 	struct ux500_glue		*glue;
 	struct clk			*clk;
 	int				ret = -ENOMEM;
 
+	if (!pdata) {
+		if (np) {
+			pdata = ux500_of_probe(pdev, np);
+			if (!pdata)
+				goto err0;
+
+			pdev->dev.platform_data = pdata;
+		} else {
+			dev_err(&pdev->dev, "no pdata or device tree found\n");
+			goto err0;
+		}
+	}
+
 	glue = kzalloc(sizeof(*glue), GFP_KERNEL);
 	if (!glue) {
 		dev_err(&pdev->dev, "failed to allocate glue context\n");
@@ -124,6 +168,7 @@ static int ux500_probe(struct platform_device *pdev)
 	musb->dev.parent		= &pdev->dev;
 	musb->dev.dma_mask		= &pdev->dev.coherent_dma_mask;
 	musb->dev.coherent_dma_mask	= pdev->dev.coherent_dma_mask;
+	musb->dev.of_node		= pdev->dev.of_node;
 
 	glue->dev			= &pdev->dev;
 	glue->musb			= musb;
@@ -222,12 +267,18 @@ static const struct dev_pm_ops ux500_pm_ops = {
 #define DEV_PM_OPS	NULL
 #endif
 
+static const struct of_device_id ux500_match[] = {
+        { .compatible = "stericsson,db8500-musb", },
+        {}
+};
+
 static struct platform_driver ux500_driver = {
 	.probe		= ux500_probe,
 	.remove		= ux500_remove,
 	.driver		= {
 		.name	= "musb-ux500",
 		.pm	= DEV_PM_OPS,
+		.of_match_table = ux500_match,
 	},
 };


From horms at verge.net.au  Wed Apr 24 03:49:04 2013
From: horms at verge.net.au (Simon Horman)
Date: Wed, 24 Apr 2013 16:49:04 +0900
Subject: [PATCH v3 1/2] ARM: shmobile: r8a7740: Add Suspend-To-RAM A3SM
In-Reply-To: <1366196190-14011-1-git-send-email-hechtb+renesas@gmail.com>
References: <1366196190-14011-1-git-send-email-hechtb+renesas@gmail.com>
Message-ID: <20130424074904.GG847@verge.net.au>

On Wed, Apr 17, 2013 at 12:56:29PM +0200, Bastian Hecht wrote:
> We add 2 Suspend to RAM modes:
> - A3SM PLL0 on/off:     Power domain A3SM that contains the ARM core
>                         and the 2nd level cache with either PLL0 on
>                         or off
> 
> As the suspend to memory mechanism we use A3SM PLL off. A3SM PLL on
> is included here too, so CPUIdle can use both power down modes (not
> included in this patch).
> 
> The setup of the SYSC regarding the external IRQs is taken from
> pm-sh7372.c from Magnus Damm.
> 
> Signed-off-by: Bastian Hecht <hechtb+renesas at gmail.com>
> ---
> v3:
> 
> We now stubbornly loop until the SoC really shuts down when we issue
> the WFI command.

Hi Bastian,

could you let me know what the status of this series is.
Is it ready to be queued-up for v3.11?


From tomi.valkeinen at ti.com  Wed Apr 24 03:56:28 2013
From: tomi.valkeinen at ti.com (Tomi Valkeinen)
Date: Wed, 24 Apr 2013 10:56:28 +0300
Subject: [GIT PULL] omap dss board clean-up for v3.10 merge window
In-Reply-To: <20130423171438.GC10155@atomide.com>
References: <20130418033936.GC10155@atomide.com>
 <20130419184518.GA30836@quad.lixom.net> <5174F593.20705@ti.com>
 <20130423171438.GC10155@atomide.com>
Message-ID: <5177902C.5070407@ti.com>

On 2013-04-23 20:14, Tony Lindgren wrote:
> * Tomi Valkeinen <tomi.valkeinen at ti.com> [130422 01:37]:

>> So while I think it is a good habit to push the arch changes and driver
>> changes separately, my question is, should that rule be followed to the
>> extreme? Can I just keep all the changes in one branch if separating the
>> arch and driver changes would end up with cloning files or lots of extra
>> code?
> 
> Shread branches are just fine. In most cases it's possible to add new
> pdata and then remove the old pdata later on with follow-up patches.

Yes, that's what I've been doing. But it's not possible in all cases,
and in some cases it's just really difficult/laborious.

I'll soon need to change the dss panel device model, and the only way I
can see that would allow us to keep everything running if only arch or
driver changes are merged, is to create a copy of all the omap display
drivers, and change the copy for the new dss device model.

And that's obviously a terrible way to do it.

So presuming I need to have the dss changes in separate arch and driver
series, and everything should run fine even if only the other half is
merged, then, well, I have no idea how to proceed. I'll continue looking
at this, but it's a bit frustrating to spend most of my time trying to
twist the code to accommodate the merging process, instead of making the
code work.

That said, this dss device model change should be a one time thing.
After it's done, these merging-problems should be greatly reduced.

>> Of course, I don't know what DRM maintainer thinks of merging arch
>> changes through his tree, so that's also open.
> 
> No let's not go there, Linus T already complained about the conflicts
> between drivers/net and arch/arm/*omap*/ code few merge windows ago.
> We need to remove the driver dependencies to the arch/arm code, otherwise
> the merging requires way too much work from multiple maintainers. That
> does not scale well and often leads into merge errors that could have
> been avoided in the first place.
> 
> Of course the real solution here is to get things moved over to DT
> based booting and then we don't have any of these dependencies as the
> .dts changes can get merged separately from the driver changes.

It will remove compile time dependencies, but we'll still have runtime
dependencies just like we do now.

 Tomi


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130424/dfaf82bb/attachment.sig>

From lee.jones at linaro.org  Wed Apr 24 03:52:12 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Wed, 24 Apr 2013 08:52:12 +0100
Subject: [PATCH] ARM: ux500: Supply a DTS file for the u8540 platform
In-Reply-To: <CACRpkdZWuw9O3-wr=g1AehZqmBR1YJ353w9ANfBTHhr5mRiwiw@mail.gmail.com>
References: <1364908916-29803-1-git-send-email-lee.jones@linaro.org>
 <1364908916-29803-3-git-send-email-lee.jones@linaro.org>
 <CACRpkdafSvT5Xb=7sqnkRHcc4UKkVzr8jzThMgWn6459RDmKGw@mail.gmail.com>
 <20130404072907.GB3004@gmail.com>
 <CACRpkdZWuw9O3-wr=g1AehZqmBR1YJ353w9ANfBTHhr5mRiwiw@mail.gmail.com>
Message-ID: <20130424075212.GE17416@gmail.com>

On Tue, 23 Apr 2013, Linus Walleij wrote:

> On Thu, Apr 4, 2013 at 9:29 AM, Lee Jones <lee.jones at linaro.org> wrote:
> 
> > This is a skeleton DTS file which only enables serial. Just using
> > this simple file yields a terminal when booting u8540.
> >
> > Signed-off-by: Lee Jones <lee.jones at linaro.org>
> 
> Now, wait... this doesn't work.

This is very strange and not what I see in my branch.

> > +/ {
> > +  model = "ST-Ericsson U8540 platform with Device Tree";
> > +  compatible = "st-ericsson,u8540";
> > +
> > +       memory {
> > +              reg = <0x00000000 0x20000000>;
> > +              };
> 
> Funny whitespace. Use tabs ...

This a single tab in my branch/editor.

> > +       soc-u9500 {
> 
> Please rename this not just "soc"

Done.

> > +                 uart at 80120000 {
> > +                                       status = "okay";
> > +                                              };
> > +
> > +               uart at 80121000 {
> > +                               status = "okay";
> > +                                      };
> > +
> > +               uart at 80007000 {
> > +                               status = "okay";
> > +                                      };
> > +                                      };
> > +};
> 
> The whitespace looks a bit funny compared to the
> old patch, what happened here?
> 
> It also has the side effect that patch 5/9 does not
> apply... By the way, since I already applied 4/9, please
> squash 5/9 into this patch to avoid problems.

It's quite common for issues to occur when patches are taken
out-of-order. As I work with topic branches, my preference would
normally be to fix issues with the patch-set as a whole until Acks are
obtained for all of the patches, then either send a pull-request or to
have all of the patches taken from the MLs in order.

> Finally, please patch arch/arm/boot/dts/Makefile
> in the obvious way so that the DTB gets compiled.

Ah  yes. Good spot.

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From jaswinder.singh at linaro.org  Wed Apr 24 03:59:46 2013
From: jaswinder.singh at linaro.org (Jassi Brar)
Date: Wed, 24 Apr 2013 13:29:46 +0530
Subject: [PATCHv3 00/14] drivers: mailbox: framework creation
In-Reply-To: <51778C3B.7010501@st.com>
References: <1363145021-14339-1-git-send-email-s-anna@ti.com>
 <CABb+yY0RYkVeo2Sb4WsDJY0jf17488FEz0d2CB994eQaSOEsVg@mail.gmail.com>
 <37C860A02101E749A747FA2D3C1E3C504A5DF7@DLEE11.ent.ti.com>
 <CABb+yY1x4x_A+QtGG9ohsLPgs8c3nEVnd_ExJBGOOR8=6YLPFA@mail.gmail.com>
 <37C860A02101E749A747FA2D3C1E3C504A63B4@DLEE11.ent.ti.com>
 <51778C3B.7010501@st.com>
Message-ID: <CAJe_ZhfF93wWuUBktnt8eBnYR6fauUngViALuopfeiQ7P_N1uA@mail.gmail.com>

Hi Loic,

On 24 April 2013 13:09, Loic PALLARDY <loic.pallardy at st.com> wrote:
> Hi Jassi, Suman,
>
> Yes, the xxx_no_irq API has been introduced to answer some STE
> requirements. It must be possible to send some message under atomic
> context for different reasons (latency, during idle/suspend procedures...).
> This is not the best way to do, but the goal was to preserve TI legacy
> in a first step. As explained by Suman, this patch series is coming from
> the original TI mailbox framework and is modified step by step to fit
> with all platforms.
>
IMHO a better way is to introduce a clean generically designed API and
convert the existing drivers one at time. Let the TI drivers work as
such for a while until someone converts them to the common API.
Cloning and then complete organ transplantation seems a very
inefficient way to have something new ;)

>>>
>>> (d) The 'struct mailbox_msg' should be just an opaque void* - the client/protocol
>>> driver typecasts to void* the IPC controller specific message structure. API
>>> shouldn't aim the impossible of providing a generic message format.
>>
>> The size parameter would still be needed. Depending on the h/w, it can be just an u32 or a series of bytes, and even in the latter case, it is not guaranteed that all messages transmitted will occupy the entire h/w shared memory data packet. I can see the current header field getting absorbed into the opaque void * structure for the ST mailbox driver. The size and ptr together provide a very generic message format.
> That's something we discussed with Suman. The mailbox framework should
> be independent from message format. Since mailbox could be base don a
> shared mem or an hw fifo, message size is mandatory to transmit the
> right number of data.
>
I too believe the "mailbox framework should be independent from
message format" but _also_ that .size doesn't have to be a part of the
standard format.
Maybe it will help if I know what you guys mean by "shared mem" or an
"hw fifo" mailbox?

Thanks
-Jassi


From mpa at pengutronix.de  Wed Apr 24 04:08:13 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Wed, 24 Apr 2013 10:08:13 +0200
Subject: [PATCH 1/2] drivers/video: Kconfig, fix mxsfb build
In-Reply-To: <1366790894-20426-1-git-send-email-mpa@pengutronix.de>
References: <1366790894-20426-1-git-send-email-mpa@pengutronix.de>
Message-ID: <1366790894-20426-2-git-send-email-mpa@pengutronix.de>

From: Markus Pargmann <mpargmann at allfex.org>

Kernel build fails with commit 669406534b4abb827d1bdc39bb5e2d5255818ae2

This patch replaces OF_VIDEOMODE symbol by VIDEOMODE_HELPERS.

Signed-off-by: Markus Pargmann <mpargmann at allfex.org>
---
 drivers/video/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index d8ecc52..6246056 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -2429,7 +2429,7 @@ config FB_MXS
 	select FB_CFB_COPYAREA
 	select FB_CFB_IMAGEBLIT
 	select FB_MODE_HELPERS
-	select OF_VIDEOMODE
+	select VIDEOMODE_HELPERS
 	help
 	  Framebuffer support for the MXS SoC.
 
-- 
1.8.1.5



From mpa at pengutronix.de  Wed Apr 24 04:08:14 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Wed, 24 Apr 2013 10:08:14 +0200
Subject: [PATCH 2/2] drivers/video: mxs-fb: Fix build, use renamed function
In-Reply-To: <1366790894-20426-1-git-send-email-mpa@pengutronix.de>
References: <1366790894-20426-1-git-send-email-mpa@pengutronix.de>
Message-ID: <1366790894-20426-3-git-send-email-mpa@pengutronix.de>

From: Markus Pargmann <mpargmann at allfex.org>

Kernel build fails with commit 669406534b4abb827d1bdc39bb5e2d5255818ae2

This patch renames videomode_from_timing to videomode_from_timings and
vm.data_flags to vm.flags.

Signed-off-by: Markus Pargmann <mpargmann at allfex.org>
---
 drivers/video/mxsfb.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/video/mxsfb.c b/drivers/video/mxsfb.c
index 1b2c26d..d78827e 100644
--- a/drivers/video/mxsfb.c
+++ b/drivers/video/mxsfb.c
@@ -777,16 +777,16 @@ static int mxsfb_init_fbinfo_dt(struct mxsfb_info *host)
 		struct videomode vm;
 		struct fb_videomode fb_vm;
 
-		ret = videomode_from_timing(timings, &vm, i);
+		ret = videomode_from_timings(timings, &vm, i);
 		if (ret < 0)
 			goto put_timings_node;
 		ret = fb_videomode_from_videomode(&vm, &fb_vm);
 		if (ret < 0)
 			goto put_timings_node;
 
-		if (vm.data_flags & DISPLAY_FLAGS_DE_HIGH)
+		if (vm.flags & DISPLAY_FLAGS_DE_HIGH)
 			host->sync |= MXSFB_SYNC_DATA_ENABLE_HIGH_ACT;
-		if (vm.data_flags & DISPLAY_FLAGS_PIXDATA_NEGEDGE)
+		if (vm.flags & DISPLAY_FLAGS_PIXDATA_NEGEDGE)
 			host->sync |= MXSFB_SYNC_DOTCLK_FALLING_ACT;
 		fb_add_videomode(&fb_vm, &fb_info->modelist);
 	}
-- 
1.8.1.5



From mpa at pengutronix.de  Wed Apr 24 04:08:12 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Wed, 24 Apr 2013 10:08:12 +0200
Subject: [PATCH 0/2] drivers/video: mxs-fb: build fixes
Message-ID: <1366790894-20426-1-git-send-email-mpa@pengutronix.de>

Hi,

mxs-fb commit

669406534b4abb827d1bdc39bb5e2d5255818ae2 video: mxsfb: get display timings from device tree

creates a build failure together with those commits:

a38884f681a4d044befd30d9f3d19a0821bae63a videomode: simplify videomode Kconfig and Makefile
6cd2c7db41eab204b6474534df4ca68a7dc53d86 videomode: videomode_from_timing work

All of them are in linux-next, so mxs-fb fails to build there.

Regards,

Markus




From loic.pallardy at st.com  Wed Apr 24 04:08:36 2013
From: loic.pallardy at st.com (Loic PALLARDY)
Date: Wed, 24 Apr 2013 10:08:36 +0200
Subject: [PATCHv3 00/14] drivers: mailbox: framework creation
In-Reply-To: <CAJe_ZhehnniZd730jjiOLrHozq8TOJZgFYLqUe4KqgBiQEu8PA@mail.gmail.com>
References: <1363145021-14339-1-git-send-email-s-anna@ti.com>
 <CABb+yY0RYkVeo2Sb4WsDJY0jf17488FEz0d2CB994eQaSOEsVg@mail.gmail.com>
 <37C860A02101E749A747FA2D3C1E3C504A5DF7@DLEE11.ent.ti.com>
 <CABb+yY1x4x_A+QtGG9ohsLPgs8c3nEVnd_ExJBGOOR8=6YLPFA@mail.gmail.com>
 <37C860A02101E749A747FA2D3C1E3C504A63B4@DLEE11.ent.ti.com>
 <CAJe_ZhehnniZd730jjiOLrHozq8TOJZgFYLqUe4KqgBiQEu8PA@mail.gmail.com>
Message-ID: <51779304.4040003@st.com>

Hi Jassi,

On 04/24/2013 06:39 AM, Jassi Brar wrote:
> Hi Suman,
>
> [please limit replies to not more than 80 columns per line]
>
> On 24 April 2013 00:50, Anna, Suman<s-anna at ti.com>  wrote:
>
>>>
>>> Documentation wise, we'd need documentation for what we finally wanna have,
>>> not the current implementation.
>>>
>>> There are also some desired features in a good API:-
>>>
>>> a) The API should be simple and efficient, i.e, submission of requests by clients
>>> and notifications of data received by the API should be possible from atomic
>>> context - most of the IPC is going to be about exchanging 'commands'. The API
>>> shouldn't add to the latencies.
>>
>> I think we will have need for both types. It really depends on the purpose of the IPC h/w - some would be simple messaging and may not need the atomic constraints. Sure enough, atomic context is the stricter one, so we can add that. I don't see any users of it currently though.
>>
> IMHO the API authors should take the other POV :  if _majority_ of
> clients _require_ non-atomic context, only then the API should support
> non-atomic version of the calls too. Otherwise let the minority of
> drivers schedule their sleepable tasks from the API's atomic
> callbacks.
>   The non-atomic API falls flat should just a single client comes with
> very low latency requirements.

In fact there are different situations for the non/atomic requirements 
(at least from ST POV)
- one mailbox could be non-atomic only (blocking if we reuse notifier 
wording)
- one mailbox could be atomic only
- one mailbox could be both depending on the context and usage (example: 
in the case of ST, one mailbox is used to access the analogue baseband, 
there is no particular atomic requirement for that except during 
register dump called form panic context)

For the 3rd point I agree with you, it should be considered as atomic 
and up to driver to schedule a sleepable task...

I have an internal implementation in which each mailbox is declared 
either atomic or blocking.
Depending on this parameter, the behavior of the mbox_send_mbox is 
changed...

>
>>>   For example, API should assume the IPC controller can detect and report when
>>> the remote asserts Ready-To-Receive (RTR). This is when the API callbacks
>>> .tx_done(mssg) on the client. If some h/w doesn't have RTR assertion interrupt,
>>> the API should provide optional feature to poll the controller periodically.
>>
>> Some of these are already part of the mailbox ops. FWIW, I don?t see a need for a .tx_done callback, as this state can really be maintained by the driver implementation itself. The mailbox_msg_send can return an error appropriately based on whether the h/w is ready or not. The current code has the support for queuing up a certain number of messages in case the h/w is busy, but I am planning to change this to a device-based property so that they can choose if it needs that support or not.
>>
> Not really. The TI's api does buffer requests from a client but it
> does not tell the client when the message is actually sent to the
> remote over the h/w channel.
>
>   Consider this example for better understanding, I must send a
> particular packet to the remote before I could, say, shutdown
> properly. The client calls mailbox_msg_send which queues the packet
> because the h/w was busy. Since the api does not inform the client
> about packet transmission, the client does not know when to shutdown
> (the packet may have been sent instantly or it may lie on the queue
> for a long time).
>   How do you fix this without tx_done callback method?
>
This mechanism was preserved to be compatibility with TI DSP bridge. But 
my initial proposal was to remove it, simply because today all mailbox 
customers consider that message is sent or not after calling 
mbox_send_message function.

>
>>>
>>> (d) The 'struct mailbox_msg' should be just an opaque void* - the client/protocol
>>> driver typecasts to void* the IPC controller specific message structure. API
>>> shouldn't aim the impossible of providing a generic message format.
>>
>> The size parameter would still be needed. Depending on the h/w, it can be just an u32 or a series of bytes, and even in the latter case, it is not guaranteed that all messages transmitted will occupy the entire h/w shared memory data packet. I can see the current header field getting absorbed into the opaque void * structure for the ST mailbox driver. The size and ptr together provide a very generic message format.
>>
> I am not sure about it. The API has no purpose for the .size (it's
> between the controller and the client driver).
> Controllers that could send variable length packets could define the
> packets format for clients as
>   struct foo_packet {
>           int size;
>           .......
>   }
> and exchange as typecasted to void* via the API. And this is just one
> way of doing it.
> The point being, the API should only pass pointer to packet info
> between controller and client drivers.
No today the size is used to store the message in the fifo and that's 
done by the framework.
If you decide to remove the fifo mechanism inherit for TI legacy, in 
that case yes the mailbox framework doesn't matter about message format 
and size.
>
>>>
>>> As you see there would be not much of the present left eventually. So I wonder
>>> if should sculpt a new api out of TI's or start from scratch?
>>> One of my controllers is similar to 'pl320' (which you left out converting to the
>>> API). I am in process of implementing all this assuming it is OK to keep a controller
>>> out of this API :)  So maybe we can collaborate on a new implementation from
>>> scratch.
>>
>> This series missed the 3.9 merge window, and is currently slated for getting merged into 3.10. The PL320 made it into 3.9 itself (I wasn't aware of it until I saw it in mainline) and created the drivers/mailbox folder.  I would think it would be relatively straight-forward to adopt it to the mailbox API, as it has only 3 API. We should be doing incremental changes on top of this series, as most of the base API would still be the same. The current series is helping out with couple of efforts, the breaking up of the PRCMU code and on the multiplatform support for OMAP with mailbox enabled. We can definitely collaborate on the improvements. Andy Green would also be interested, as he is also looking into adopting the mailbox API.
>>
> I don't think it should into 3.10 just because it missed the 3.9
> window, when its quality is doubted.
> I am going to have to live with IPC controller code for sometime now,
> so I care that I build upon a sound API. And I am more than happy to
> help on a proper implementation.
>
I'm really happy to see some new mailbox framework clients coming with 
new requirements to improve the solution.
Just for the story, mailbox framework topic was addressed during Linaro 
Copenhagen Connect and at the time being it was decided to reuse TI 
solution in a first time and then to improve it...

Regards,
Loic

> Regards,
> Jassi

From catalin.marinas at arm.com  Wed Apr 24 04:22:37 2013
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Wed, 24 Apr 2013 09:22:37 +0100
Subject: [PATCH] arm64: compiling issue, need add include/asm/vga.h file
In-Reply-To: <5177551D.8090007@asianux.com>
References: <5177551D.8090007@asianux.com>
Message-ID: <20130424082237.GA23397@arm.com>

On Wed, Apr 24, 2013 at 04:44:29AM +0100, Chen Gang wrote:
> For compiling with allmodconfig, need vga.h file, so copy it from arm32.

I would rather use the generic vga.h. We don't even have a vga_base
defined.

-- 
Catalin


From mpa at pengutronix.de  Wed Apr 24 04:22:50 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Wed, 24 Apr 2013 10:22:50 +0200
Subject: [PATCH 0/2] drivers/video: mxs-fb: build fixes
In-Reply-To: <1366790894-20426-1-git-send-email-mpa@pengutronix.de>
References: <1366790894-20426-1-git-send-email-mpa@pengutronix.de>
Message-ID: <1366791772-11133-1-git-send-email-mpa@pengutronix.de>

Sorry, I messed up the email addresses in the last two patches, the following
two are exactly the same just with the correct addresses.

Regards,

Markus



From mpa at pengutronix.de  Wed Apr 24 04:22:51 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Wed, 24 Apr 2013 10:22:51 +0200
Subject: [PATCH 1/2] drivers/video: Kconfig, fix mxsfb build
In-Reply-To: <1366791772-11133-1-git-send-email-mpa@pengutronix.de>
References: <1366790894-20426-1-git-send-email-mpa@pengutronix.de>
 <1366791772-11133-1-git-send-email-mpa@pengutronix.de>
Message-ID: <1366791772-11133-2-git-send-email-mpa@pengutronix.de>

Kernel build fails with commit 669406534b4abb827d1bdc39bb5e2d5255818ae2

This patch replaces OF_VIDEOMODE symbol by VIDEOMODE_HELPERS.

Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
---
 drivers/video/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index d8ecc52..6246056 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -2429,7 +2429,7 @@ config FB_MXS
 	select FB_CFB_COPYAREA
 	select FB_CFB_IMAGEBLIT
 	select FB_MODE_HELPERS
-	select OF_VIDEOMODE
+	select VIDEOMODE_HELPERS
 	help
 	  Framebuffer support for the MXS SoC.
 
-- 
1.8.1.5



From mpa at pengutronix.de  Wed Apr 24 04:22:52 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Wed, 24 Apr 2013 10:22:52 +0200
Subject: [PATCH 2/2] drivers/video: mxs-fb: Fix build, use renamed function
In-Reply-To: <1366791772-11133-1-git-send-email-mpa@pengutronix.de>
References: <1366790894-20426-1-git-send-email-mpa@pengutronix.de>
 <1366791772-11133-1-git-send-email-mpa@pengutronix.de>
Message-ID: <1366791772-11133-3-git-send-email-mpa@pengutronix.de>

Kernel build fails with commit 669406534b4abb827d1bdc39bb5e2d5255818ae2

This patch renames videomode_from_timing to videomode_from_timings and
vm.data_flags to vm.flags.

Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
---
 drivers/video/mxsfb.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/video/mxsfb.c b/drivers/video/mxsfb.c
index 1b2c26d..d78827e 100644
--- a/drivers/video/mxsfb.c
+++ b/drivers/video/mxsfb.c
@@ -777,16 +777,16 @@ static int mxsfb_init_fbinfo_dt(struct mxsfb_info *host)
 		struct videomode vm;
 		struct fb_videomode fb_vm;
 
-		ret = videomode_from_timing(timings, &vm, i);
+		ret = videomode_from_timings(timings, &vm, i);
 		if (ret < 0)
 			goto put_timings_node;
 		ret = fb_videomode_from_videomode(&vm, &fb_vm);
 		if (ret < 0)
 			goto put_timings_node;
 
-		if (vm.data_flags & DISPLAY_FLAGS_DE_HIGH)
+		if (vm.flags & DISPLAY_FLAGS_DE_HIGH)
 			host->sync |= MXSFB_SYNC_DATA_ENABLE_HIGH_ACT;
-		if (vm.data_flags & DISPLAY_FLAGS_PIXDATA_NEGEDGE)
+		if (vm.flags & DISPLAY_FLAGS_PIXDATA_NEGEDGE)
 			host->sync |= MXSFB_SYNC_DOTCLK_FALLING_ACT;
 		fb_add_videomode(&fb_vm, &fb_info->modelist);
 	}
-- 
1.8.1.5



From p.zabel at pengutronix.de  Wed Apr 24 04:22:43 2013
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Wed, 24 Apr 2013 10:22:43 +0200
Subject: [RFC][PATCH] video: imx: Select VIDEOMODE_HELPERS
In-Reply-To: <201304240231.49579.marex@denx.de>
References: <1366666110-9585-1-git-send-email-marex@denx.de>
 <201304230157.47992.marex@denx.de>
 <1366702862.4365.2.camel@pizza.hi.pengutronix.de>
 <201304240231.49579.marex@denx.de>
Message-ID: <1366791763.4089.3.camel@pizza.hi.pengutronix.de>

Hi Marek,

Am Mittwoch, den 24.04.2013, 02:31 +0200 schrieb Marek Vasut:
> Hi Philipp,
> 
> > Hi Marek,
> > 
> > Am Dienstag, den 23.04.2013, 01:57 +0200 schrieb Marek Vasut:
> > > Dear Fabio Estevam,
> > > 
> > > > Hi Marek,
> > > > 
> > > > On Mon, Apr 22, 2013 at 6:28 PM, Marek Vasut <marex at denx.de> wrote:
> > > > > Without this, I get the following problem when building kernel:
> > > > > 
> > > > > drivers/built-in.o: In function `imx_pd_connector_get_modes':
> > > > > /linux-2.6/drivers/staging/imx-drm/parallel-display.c:78: undefined
> > > > > reference to `of_get_drm_display_mode' make: *** [vmlinux] Error 1
> > > > > 
> > > > > NOTE: I think this patch is almost absolutely not correct.
> > > > > 
> > > > > Signed-off-by: Marek Vasut <marex at denx.de>
> > > > > Cc: Sascha Hauer <s.hauer at pengutronix.de>
> > > > > Cc: Philipp Zabel <p.zabel at pengutronix.de>
> > > > > Cc: Fabio Estevam <fabio.estevam at freescale.com>
> > > > 
> > > > Patch looks good, but you should have copied Greg Kroah-Hartman, as he
> > > > is the one who takes patches into staging.
> > > 
> > > I'm not sure if the select is at correct symbol, I dont think it is.
> > 
> > OF_VIDEOMODE is the correct one. The implementation of
> > of_get_drm_display_mode in drivers/gpu/drm/drm_modes.c depends on it.
> 
> I really need VIDEOMODE_HELPERS, not OF_VIDEOMODE. If I select only 
> OF_VIDEOMODE, I still get the issue above.
> 
> Check drivers/gpu/drm/drm_modes.c , it's protected by CONFIG_VIDEOMODE_HELPERS

Indeed, I was looking at the wrong checkout. Sorry for the noise.

regards
Philipp



From lee.jones at linaro.org  Wed Apr 24 04:35:09 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Wed, 24 Apr 2013 09:35:09 +0100
Subject: [PATCH 21/32] dmaengine: ste_dma40: Also report the number of
 logical channels
In-Reply-To: <20130422105245.GG14496@n2100.arm.linux.org.uk>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-22-git-send-email-lee.jones@linaro.org>
 <20130422093631.GE24632@intel.com>
 <20130422101455.GH3432@gmail.com>
 <20130422094842.GL24632@intel.com>
 <20130422103715.GK3432@gmail.com>
 <20130422105245.GG14496@n2100.arm.linux.org.uk>
Message-ID: <20130424083509.GF17416@gmail.com>

On Mon, 22 Apr 2013, Russell King - ARM Linux wrote:

> On Mon, Apr 22, 2013 at 11:37:15AM +0100, Lee Jones wrote:
> > On Mon, 22 Apr 2013, Vinod Koul wrote:
> > 
> > > On Mon, Apr 22, 2013 at 11:14:55AM +0100, Lee Jones wrote:
> > > > On Mon, 22 Apr 2013, Vinod Koul wrote:
> > > > 
> > > > > On Thu, Apr 18, 2013 at 11:12:03AM +0100, Lee Jones wrote:
> > > > > > +	dev_info(&pdev->dev, "hardware revision: %d @ 0x%x with "
> > > > > > +		"%d physical channels and %d logical channels\n",
> > > > > > +		rev, res->start, num_phy_chans, num_log_chans);
> > > > > Splitting log messages across lines is bad idea and sacrifces readablity... also
> > > > > wasnt splitting logging to multiple lines emit checkpatch warn
> 
> Yes, but for a different reason...
> 
> > > > You also get a check-patch error if your lines are over 80 chars.
> > > No, you get a warn
> > 
> > You only get a warning for this too:
> > 
> >  WARNING: quoted string split across lines
> > #33: FILE: drivers/dma/ste_dma40.c:3204:
> > +	dev_info(&pdev->dev, "hardware revision: %d @ 0x%x with "
> > +		"%d physical channels and %d logical channels\n",
> 
> From coding style: "However, never break user-visible strings such as
> printk messages, because that breaks the ability to grep for them."
> 
> You can argue that you wouldn't grep for the above string - but consider
> if you grepped for "hardware revision.*channels" to try and find the
> above message, which would be a reasonable thing to try if you got lots
> of hits on just "hardware revision".

Okay, this I understand. I'll fixup.

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From loic.pallardy at st.com  Wed Apr 24 04:39:05 2013
From: loic.pallardy at st.com (Loic PALLARDY)
Date: Wed, 24 Apr 2013 10:39:05 +0200
Subject: [PATCHv3 00/14] drivers: mailbox: framework creation
In-Reply-To: <CAJe_ZhfF93wWuUBktnt8eBnYR6fauUngViALuopfeiQ7P_N1uA@mail.gmail.com>
References: <1363145021-14339-1-git-send-email-s-anna@ti.com>
 <CABb+yY0RYkVeo2Sb4WsDJY0jf17488FEz0d2CB994eQaSOEsVg@mail.gmail.com>
 <37C860A02101E749A747FA2D3C1E3C504A5DF7@DLEE11.ent.ti.com>
 <CABb+yY1x4x_A+QtGG9ohsLPgs8c3nEVnd_ExJBGOOR8=6YLPFA@mail.gmail.com>
 <37C860A02101E749A747FA2D3C1E3C504A63B4@DLEE11.ent.ti.com>
 <51778C3B.7010501@st.com>
 <CAJe_ZhfF93wWuUBktnt8eBnYR6fauUngViALuopfeiQ7P_N1uA@mail.gmail.com>
Message-ID: <51779A29.2040109@st.com>

Hi Jassi,

On 04/24/2013 09:59 AM, Jassi Brar wrote:
> Hi Loic,
>
> On 24 April 2013 13:09, Loic PALLARDY<loic.pallardy at st.com>  wrote:
>> Hi Jassi, Suman,
>>
>> Yes, the xxx_no_irq API has been introduced to answer some STE
>> requirements. It must be possible to send some message under atomic
>> context for different reasons (latency, during idle/suspend procedures...).
>> This is not the best way to do, but the goal was to preserve TI legacy
>> in a first step. As explained by Suman, this patch series is coming from
>> the original TI mailbox framework and is modified step by step to fit
>> with all platforms.
>>
> IMHO a better way is to introduce a clean generically designed API and
> convert the existing drivers one at time. Let the TI drivers work as
> such for a while until someone converts them to the common API.
> Cloning and then complete organ transplantation seems a very
> inefficient way to have something new ;)
>
As explained in previous mail, it was not the decision taken during 
Linaro Copenhagen Connect to restart from scratch, mainly because only 
ST and TI were interested by such framework at the time being.

>>>>
>>>> (d) The 'struct mailbox_msg' should be just an opaque void* - the client/protocol
>>>> driver typecasts to void* the IPC controller specific message structure. API
>>>> shouldn't aim the impossible of providing a generic message format.
>>>
>>> The size parameter would still be needed. Depending on the h/w, it can be just an u32 or a series of bytes, and even in the latter case, it is not guaranteed that all messages transmitted will occupy the entire h/w shared memory data packet. I can see the current header field getting absorbed into the opaque void * structure for the ST mailbox driver. The size and ptr together provide a very generic message format.
>> That's something we discussed with Suman. The mailbox framework should
>> be independent from message format. Since mailbox could be base don a
>> shared mem or an hw fifo, message size is mandatory to transmit the
>> right number of data.
>>
> I too believe the "mailbox framework should be independent from
> message format" but _also_ that .size doesn't have to be a part of the
> standard format.
> Maybe it will help if I know what you guys mean by "shared mem" or an
> "hw fifo" mailbox?
>
Hw fifo means that you what a HW IP which contains x bytes fifo.
When you write one byte in the fifo, an interrupt is automatically 
raised and caught by coprocessor which should read fifo on its side to 
empty it. In that case, Tx RTR is mandatory.
Shared mem, means that mailbox is made up of a cross interrupt + a 
status register (may be optional) + a shared memory in which messages 
are exchanged.
After writing message in shared mem, CPU has to raise the cross 
interrupt itself. In case flow control is less important...

/Loic
> Thanks
> -Jassi

From lee.jones at linaro.org  Wed Apr 24 04:39:44 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Wed, 24 Apr 2013 09:39:44 +0100
Subject: [PATCH 21/32 v2] dmaengine: ste_dma40: Also report the number of
 logical channels
In-Reply-To: <1366279934-30761-22-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-22-git-send-email-lee.jones@linaro.org>
Message-ID: <20130424083944.GG17416@gmail.com>

dmaengine: ste_dma40: Also report the number of logical channels

Now we know the total of physical and logical channels, we may as
well report them within the information log.

Before:
dma40 dma40.0: hardware revision: 3 @ 0x801c0000 with 8 physical channels

After:
<as above ...> and 256 logical channels

Cc: Vinod Koul <vinod.koul at intel.com>
Cc: Dan Williams <djbw at fb.com>
Cc: Per Forlin <per.forlin at stericsson.com>
Cc: Rabin Vincent <rabin at rab.in>
Signed-off-by: Lee Jones <lee.jones at linaro.org>

diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index 4c6df0e..d5a15ec 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -3200,8 +3200,9 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
 
 	num_log_chans = num_phy_chans * D40_MAX_LOG_CHAN_PER_PHY;
 
-	dev_info(&pdev->dev, "hardware revision: %d @ 0x%x with %d physical channels\n",
-		 rev, res->start, num_phy_chans);
+	dev_info(&pdev->dev,
+		 "hardware rev: %d @ 0x%x with %d physical chans and %d logical chans\n",
+		 rev, res->start, num_phy_chans, num_log_chans);
 
 	base = kzalloc(ALIGN(sizeof(struct d40_base), 4) +
 		       (num_phy_chans + num_log_chans + ARRAY_SIZE(dma40_memcpy_channels)) *


From gang.chen at asianux.com  Wed Apr 24 04:44:54 2013
From: gang.chen at asianux.com (Chen Gang)
Date: Wed, 24 Apr 2013 16:44:54 +0800
Subject: [PATCH] arm64: compiling issue, need add include/asm/vga.h file
In-Reply-To: <20130424082237.GA23397@arm.com>
References: <5177551D.8090007@asianux.com> <20130424082237.GA23397@arm.com>
Message-ID: <51779B86.4030306@asianux.com>

On 2013?04?24? 16:22, Catalin Marinas wrote:
> On Wed, Apr 24, 2013 at 04:44:29AM +0100, Chen Gang wrote:
>> For compiling with allmodconfig, need vga.h file, so copy it from arm32.
> 
> I would rather use the generic vga.h. We don't even have a vga_base
> defined.
> 

OK, thanks. I need send patch v2.

-- 
Chen Gang

Asianux Corporation


From lee.jones at linaro.org  Wed Apr 24 04:49:12 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Wed, 24 Apr 2013 09:49:12 +0100
Subject: [PATCH 08/32 v2] dmaengine: ste_dma40: Remove home-brew MAX() macro
In-Reply-To: <1366279934-30761-9-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-9-git-send-email-lee.jones@linaro.org>
Message-ID: <20130424084912.GH17416@gmail.com>

The current implementation of the DMA40's local MAX() macro evaluates
its arguments more times than is necessary and it not type checked.
This patch strips replaces it with a new, more efficient constant.

Cc: Vinod Koul <vinod.koul at intel.com>
Cc: Dan Williams <djbw at fb.com>
Cc: Per Forlin <per.forlin at stericsson.com>
Cc: Rabin Vincent <rabin at rab.in>
Reported-by: Harvey Harrison <harvey.harrison at gmail.com>
Signed-off-by: Lee Jones <lee.jones at linaro.org>

diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index cc93416..a1984d2 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -53,8 +53,6 @@
 #define D40_ALLOC_PHY		BIT(30)
 #define D40_ALLOC_LOG_FREE	0
 
-#define MAX(a, b) (((a) < (b)) ? (b) : (a))
-
 #define D40_IS_SRC(dir)  (dir == STEDMA40_PERIPH_TO_MEM)
 #define D40_IS_DST(dir) ((dir == STEDMA40_MEM_TO_PERIPH) || \
 			 (dir == STEDMA40_MEM_TO_MEM))
@@ -206,6 +204,9 @@ static u32 d40_backup_regs_chan[] = {
 	D40_CHAN_REG_SDLNK,
 };
 
+#define BACKUP_REGS_SZ_MAX ((BACKUP_REGS_SZ_V4A > BACKUP_REGS_SZ_V4B) ? \
+			     BACKUP_REGS_SZ_V4A : BACKUP_REGS_SZ_V4B)
+
 /**
  * struct d40_interrupt_lookup - lookup table for interrupt handler
  *
@@ -569,7 +570,7 @@ struct d40_base {
 	resource_size_t			  lcpa_size;
 	struct kmem_cache		 *desc_slab;
 	u32				  reg_val_backup[BACKUP_REGS_SZ];
-	u32				  reg_val_backup_v4[MAX(BACKUP_REGS_SZ_V4A, BACKUP_REGS_SZ_V4B)];
+	u32				  reg_val_backup_v4[BACKUP_REGS_SZ_MAX];
 	u32				 *reg_val_backup_chan;
 	u16				  gcc_pwr_off_mask;
 	bool				  initialized;


From lee.jones at linaro.org  Wed Apr 24 04:51:21 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Wed, 24 Apr 2013 09:51:21 +0100
Subject: [PATCH 15/32] dmaengine: ste_dma40: Separate Logical Global
 Interrupt Mask (GIM) unmasking
In-Reply-To: <20130422104012.GL3432@gmail.com>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-16-git-send-email-lee.jones@linaro.org>
 <20130422095130.GM24632@intel.com>
 <20130422104012.GL3432@gmail.com>
Message-ID: <20130424085121.GI17416@gmail.com>

On Mon, 22 Apr 2013, Lee Jones wrote:

> > >  void d40_phy_cfg(struct stedma40_chan_cfg *cfg,
> > >  		 u32 *src_cfg, u32 *dst_cfg, bool is_log)
> > > @@ -107,11 +113,6 @@ void d40_phy_cfg(struct stedma40_chan_cfg *cfg,
> > >  			src |= 1 << D40_SREG_CFG_PRI_POS;
> > >  			dst |= 1 << D40_SREG_CFG_PRI_POS;
> > shouldnt these be converted to BIT() macro and in gim_unmask above?
> > Driver needs to be consistent in doing things
> 
> Absolutely they do. I haven't converted ste_dma40_ll.c to BIT yet
> though. I have this on my TODO and it will happen in the next
> patch-set.

Vinod, are you happy to Ack this on the proviso that I follow it up
with a subsequent patch converting the ste_dma40_ll driver to BIT()?

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From lee.jones at linaro.org  Wed Apr 24 04:53:58 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Wed, 24 Apr 2013 09:53:58 +0100
Subject: [PATCH 05/32] dmaengine: ste_dma40: Supply macros to resolve
 'src' and 'dst' directions
In-Reply-To: <20130422102748.GJ3432@gmail.com>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-6-git-send-email-lee.jones@linaro.org>
 <20130422094250.GJ24632@intel.com>
 <20130422102748.GJ3432@gmail.com>
Message-ID: <20130424085358.GJ17416@gmail.com>

On Mon, 22 Apr 2013, Lee Jones wrote:

> On Mon, 22 Apr 2013, Vinod Koul wrote:
> 
> > On Thu, Apr 18, 2013 at 11:11:47AM +0100, Lee Jones wrote:
> > > There are lots of lengthy if() statements located sporadically up and
> > > down the driver. This simple macro should make many of them a little
> > > simpler to decipher. The remainder have to stay in place, as they
> > > detail slightly more specific settings.
> > I would like these to be DMAENGINE_IS_SRC...
> 
> I don't understand, as they're DMA40 specific?
> 
> > and this patch use the defines provided in dmaengine
> 
> I think a subsequent patch doing he following would be more suitable:
> 
> s/STEDMA40_MEM_TO_MEM/DMA_MEM_TO_MEM/
> s/STEDMA40_MEM_TO_PERIPH/DMA_MEM_TO_DEV/
> s/STEDMA40_PERIPH_TO_MEM/DMA_DEV_TO_MEM/
> s/STEDMA40_PERIPH_TO_PERIPH/DMA_DEV_TO_DEV/
> 
> If you don't mind?

Are you happy to Ack this one too if I follow up with a subsequent
patch converting all STEDMA direction defines over to the generic DMA
ones? There are also quite a lot in platform data that I'd like to
convert too.

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From lee.jones at linaro.org  Wed Apr 24 04:55:07 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Wed, 24 Apr 2013 09:55:07 +0100
Subject: [PATCH 17/32] dmaengine: ste_dma40: Remove redundant argument
 from d40_phy_cfg()
In-Reply-To: <20130422093423.GD24632@intel.com>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-18-git-send-email-lee.jones@linaro.org>
 <20130422093423.GD24632@intel.com>
Message-ID: <20130424085507.GK17416@gmail.com>

> > +	if ((cfg->dir ==  STEDMA40_PERIPH_TO_MEM) ||
> > +	    (cfg->dir == STEDMA40_PERIPH_TO_PERIPH)) {
> Why would you need your own direction defines, I see that there is not much
> diff between these and what dmaengine defines, so perhpas you could use
> those?

Same with these ones, subsequent patch?

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From jaswinder.singh at linaro.org  Wed Apr 24 04:56:40 2013
From: jaswinder.singh at linaro.org (Jassi Brar)
Date: Wed, 24 Apr 2013 14:26:40 +0530
Subject: [PATCHv3 00/14] drivers: mailbox: framework creation
In-Reply-To: <51779304.4040003@st.com>
References: <1363145021-14339-1-git-send-email-s-anna@ti.com>
 <CABb+yY0RYkVeo2Sb4WsDJY0jf17488FEz0d2CB994eQaSOEsVg@mail.gmail.com>
 <37C860A02101E749A747FA2D3C1E3C504A5DF7@DLEE11.ent.ti.com>
 <CABb+yY1x4x_A+QtGG9ohsLPgs8c3nEVnd_ExJBGOOR8=6YLPFA@mail.gmail.com>
 <37C860A02101E749A747FA2D3C1E3C504A63B4@DLEE11.ent.ti.com>
 <CAJe_ZhehnniZd730jjiOLrHozq8TOJZgFYLqUe4KqgBiQEu8PA@mail.gmail.com>
 <51779304.4040003@st.com>
Message-ID: <CAJe_ZhdZv5LW6kdwyPtJe69mfW6t=WQ4OJnG2H4sUhibattN2A@mail.gmail.com>

Hi -

On 24 April 2013 13:38, Loic PALLARDY <loic.pallardy at st.com> wrote:
> Hi Jassi,
>
> On 04/24/2013 06:39 AM, Jassi Brar wrote:

>>   The non-atomic API falls flat should just a single client comes with
>> very low latency requirements.
>
> In fact there are different situations for the non/atomic requirements
> (at least from ST POV)
> - one mailbox could be non-atomic only (blocking if we reuse notifier
> wording)
> - one mailbox could be atomic only
> - one mailbox could be both depending on the context and usage (example:
> in the case of ST, one mailbox is used to access the analogue baseband,
> there is no particular atomic requirement for that except during
> register dump called form panic context)
>
> For the 3rd point I agree with you, it should be considered as atomic
> and up to driver to schedule a sleepable task...
>
> I have an internal implementation in which each mailbox is declared
> either atomic or blocking.
> Depending on this parameter, the behavior of the mbox_send_mbox is
> changed...
>
I am only talking about the nature of the API, which I think should as
fast as possible by providing atomic functions (except
mailbox_get/put).
If a controller needs to do sleep-prone tasks, let it schedule those
from API's atomic callbacks.
If a client needs to blink leds after receiving/sending a message, let
it schedule a work for that from API's atomic callback.
Majority of scenarios will simply be a client populating a structure
and pass it onto the controller driver which only need to program a
few registers to put the message on the h/w link.


>>   Consider this example for better understanding, I must send a
>> particular packet to the remote before I could, say, shutdown
>> properly. The client calls mailbox_msg_send which queues the packet
>> because the h/w was busy. Since the api does not inform the client
>> about packet transmission, the client does not know when to shutdown
>> (the packet may have been sent instantly or it may lie on the queue
>> for a long time).
>>   How do you fix this without tx_done callback method?
>>
> This mechanism was preserved to be compatibility with TI DSP bridge. But
> my initial proposal was to remove it, simply because today all mailbox
> customers consider that message is sent or not after calling
> mbox_send_message function.
>
Yeah, I too sense a lot of badness is inherited.

>>>
>>> The size parameter would still be needed. Depending on the h/w, it can be just an u32 or a series of bytes, and even in the latter case, it is not guaranteed that all messages transmitted will occupy the entire h/w shared memory data packet. I can see the current header field getting absorbed into the opaque void * structure for the ST mailbox driver. The size and ptr together provide a very generic message format.
>>>
>> I am not sure about it. The API has no purpose for the .size (it's
>> between the controller and the client driver).
>> Controllers that could send variable length packets could define the
>> packets format for clients as
>>   struct foo_packet {
>>           int size;
>>           .......
>>   }
>> and exchange as typecasted to void* via the API. And this is just one
>> way of doing it.
>> The point being, the API should only pass pointer to packet info
>> between controller and client drivers.
> No today the size is used to store the message in the fifo and that's
> done by the framework.
> If you decide to remove the fifo mechanism inherit for TI legacy, in
> that case yes the mailbox framework doesn't matter about message format
> and size.
>
Of course I desperately want to get rid of the TI legacy stuff in the
common api, that will simply not work on many platforms. My 'shutdown'
example above may be real for some platform.

>>
> I'm really happy to see some new mailbox framework clients coming with
> new requirements to improve the solution.
> Just for the story, mailbox framework topic was addressed during Linaro
> Copenhagen Connect and at the time being it was decided to reuse TI
> solution in a first time and then to improve it...
>
At the time my idea of mailbox was simply a tin box with a lock and a slit.
On a serious note, someone very important pointed out that things
discussed during events like Linaro shouldn't be taken as the
consensus of the community. "We" should have put it up for discussion
on the mailing lists.

>> Maybe it will help if I know what you guys mean by "shared mem" or an
>> "hw fifo" mailbox?
>>
> Hw fifo means that you what a HW IP which contains x bytes fifo.
> When you write one byte in the fifo, an interrupt is automatically
> raised and caught by coprocessor which should read fifo on its side to
> empty it. In that case, Tx RTR is mandatory.
> Shared mem, means that mailbox is made up of a cross interrupt + a
> status register (may be optional) + a shared memory in which messages
> are exchanged.
> After writing message in shared mem, CPU has to raise the cross
> interrupt itself. In case flow control is less important...
>
Well, I have a yet another type of controller where the IRQ status
register provides the data to be exchanged. Anyways I still maintain
that all three(or any more) controller types need not bother the API
with the size of message. The size should be a mandatory member of the
controller specific packet format that will be used by the client to
exchange data with it.

Regards,
-Jassi


From linus.walleij at linaro.org  Wed Apr 24 04:58:18 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Wed, 24 Apr 2013 10:58:18 +0200
Subject: [PATCH] pinctrl: move subsystem mutex to pinctrl_dev struct
In-Reply-To: <5165636F.2000602@st.com>
References: <1363189479-11240-1-git-send-email-linus.walleij@stericsson.com>
 <5140C3F5.9030406@wwwdotorg.org> <514201F1.6080508@st.com>
 <CACRpkdZ_Np-NMwO+nVLYnyUWPcidHq-MN8Ls0YMr4WxTLCLKjw@mail.gmail.com>
 <515381AC.4050206@wwwdotorg.org> <5165636F.2000602@st.com>
Message-ID: <CACRpkdYDqknA11E+9erixP+SLV4LDgVmmJ3CcJOnTRbfOZr9Bg@mail.gmail.com>

On Wed, Apr 10, 2013 at 3:04 PM, Patrice CHOTARD <patrice.chotard at st.com> wrote:
> On 03/28/2013 12:33 AM, Stephen Warren wrote:

>>>> I don't understand the link between maps and pinctrl_select(),
>>>> pinctrl_select_state_locked() doesn't touch the map.
>>
>> Yes, pinctrl_select() shouldn't touch the map since it's already been
>> parsed.
>>
>> But if there's a per-pinctrl-driver lock, then pinctrl_select() needs to
>> lock all those locks for each driver referenced by a struct
>> pinctrl_state entry.
>>
>> Perhaps it doesn't need to hold more than one of those at a time though;
>> that might help remove any possibility of deadlock.
>
> Ok, regarding pinctrl_select(), i will propose a new patch version which
> hold the per-pincontrol-driver lock referenced by each struct
> pinctrl_state entry.

I've tested this (with a newer patch from Patrice) and it regresses
on the U300 platform.

pinctrl_select_state() calls pinconf_apply_setting, which
calls ops->pin_config_set(), which needs to figure out the
GPIO range for this pin and calls back into core function
pinctrl_find_gpio_range_from_pin(), which again takes
the pctldev mutex -> deadlock.

What I do not understand is this: both pinctrl_lookup_state()
and pinctrl_select_state() are taking (today) the global
pinctrl mutex. Patrice's patch moves this to take the dev list
mutex.

Taking the dev list mutex is not correct since we're only
dealing with the isolated struct pinctrl * at this point.
I think. Unless the idea is to protect agains the device
being removed underneath.

I don't see the point in taking either mutex actually and
what it's protecting against. If it's just protecting against the
pinctrl device being removed during state selection, doing
that will cause *way* bigger problems anyway (think of all
the devices that have struct pinctrl * around!) so it's not
the way forward anyway. The struct pinctrl * was designed
to be floating around independently of the devices since
forever.

pinctrl_unregister() calls pinctrl_put_locked() on all pinctrl
handles, at which point it should scream if any of these are
in use and that is the big problem with removing the pinctrl
devices - the system as a whole just need to make sure
there are no users left, it cannot be guaranteed with
mutexes.

I just removed those two mutexes (in pinctrl_lookup_state
and pinctrl_select_state), will send the modified
version of Patrice's patch soon-ish.

Yours,
Linus Walleij


From mpa at pengutronix.de  Wed Apr 24 05:00:02 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Wed, 24 Apr 2013 11:00:02 +0200
Subject: [PATCH 0/2] drivers/video: mxs-fb: build fixes
In-Reply-To: <1366790894-20426-1-git-send-email-mpa@pengutronix.de>
References: <1366790894-20426-1-git-send-email-mpa@pengutronix.de>
Message-ID: <20130424090002.GB3973@pengutronix.de>

On Wed, Apr 24, 2013 at 10:08:12AM +0200, Markus Pargmann wrote:
> Hi,
> 
> mxs-fb commit
> 
> 669406534b4abb827d1bdc39bb5e2d5255818ae2 video: mxsfb: get display timings from device tree
> 
> creates a build failure together with those commits:
> 
> a38884f681a4d044befd30d9f3d19a0821bae63a videomode: simplify videomode Kconfig and Makefile
> 6cd2c7db41eab204b6474534df4ca68a7dc53d86 videomode: videomode_from_timing work
> 
> All of them are in linux-next, so mxs-fb fails to build there.
> 
> Regards,
> 
> Markus
> 
> 
> 

Sorry for the noise. This was already fixed and queued for 3.10-rc.

Regards,

Markus

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From linus.walleij at stericsson.com  Wed Apr 24 05:01:59 2013
From: linus.walleij at stericsson.com (Linus Walleij)
Date: Wed, 24 Apr 2013 11:01:59 +0200
Subject: [PATCH v2] pinctrl: move subsystem mutex to pinctrl_dev struct
Message-ID: <1366794119-766-1-git-send-email-linus.walleij@stericsson.com>

From: Patrice Chotard <patrice.chotard at st.com>

This mutex avoids deadlock in case of use of multiple pin
controllers. Before this modification, by using a global
mutex, deadlock appeared when, for example, a call to
pinctrl_pins_show() locked the pinctrl_mutex, called the
ops->pin_dbg_show of a particular pin controller. If this
pin controller needs I2C access to retrieve configuration
information and I2C driver is using pinctrl to drive its
pins, a call to pinctrl_select_state() try to lock again
pinctrl_mutex which leads to a deadlock.

Notice that the mutex grab from the two direction functions
was moved into pinctrl_gpio_direction().

For several cases, we can't replace pinctrl_mutex by
pctldev->mutex, because at this stage, pctldev is
not accessible :
	- pinctrl_get()/pinctrl_put()
	- pinctrl_register_maps()

So add respectively pinctrl_list_mutex and
pinctrl_maps_mutex in order to protect
pinctrl_list and pinctrl_maps list instead.

Reintroduce pinctrldev_list_mutex in
find_pinctrl_by_of_node(),
pinctrl_find_and_add_gpio_range()
pinctrl_request_gpio(), pinctrl_free_gpio(),
pinctrl_gpio_direction(), pinctrl_devices_show(),
pinctrl_register() and pinctrl_unregister() to
protect pinctrldev_list.

Changes v1->v2
- pinctrl_select_state_locked() is removed, all lock mechanism
  is located inside pinctrl_select_state(). When parsing
  the state->setting list, take the per-pin-controller driver
  lock. (Patrice).
- Introduce pinctrldev_list_mutex to protect pinctrldev_list
  in all functions which parse or modify pictrldev_list.
  (Patrice).
- move find_pinctrl_by_of_node() from pinctrl/devicetree.c to
  pinctrl/core.c in order to protect pinctrldev_list.
  (Patrice).
- Sink mutex:es into some functions and remove some _locked
  variants down to where the lists are actually accessed to
  make things simpler. (Linus)
- Drop *all* mutexes completely from pinctrl_lookup_state()
  and pinctrl_select_state() - no relevant mutex was taken
  and it was unclear what this was protecting against. (Linus)

Reported by : Seraphin Bonnaffe <seraphin.bonnaffe at stericsson.com>
Signed-off-by: Patrice Chotard <patrice.chotard at st.com>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 drivers/pinctrl/core.c       | 266 +++++++++++++++++++++++--------------------
 drivers/pinctrl/core.h       |   6 +-
 drivers/pinctrl/devicetree.c |  15 +--
 drivers/pinctrl/pinconf.c    |  46 ++++----
 drivers/pinctrl/pinmux.c     |   8 +-
 5 files changed, 176 insertions(+), 165 deletions(-)

diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
index 8b832ce..37cd774 100644
--- a/drivers/pinctrl/core.c
+++ b/drivers/pinctrl/core.c
@@ -40,11 +40,17 @@
 
 static bool pinctrl_dummy_state;
 
-/* Mutex taken by all entry points */
-DEFINE_MUTEX(pinctrl_mutex);
+/* Mutex taken to protect pinctrl_list */
+DEFINE_MUTEX(pinctrl_list_mutex);
+
+/* Mutex taken to protect pinctrl_maps */
+DEFINE_MUTEX(pinctrl_maps_mutex);
+
+/* Mutex taken to protect pinctrldev_list */
+DEFINE_MUTEX(pinctrldev_list_mutex);
 
 /* Global list of pin control devices (struct pinctrl_dev) */
-LIST_HEAD(pinctrldev_list);
+static LIST_HEAD(pinctrldev_list);
 
 /* List of pin controller handles (struct pinctrl) */
 static LIST_HEAD(pinctrl_list);
@@ -111,6 +117,23 @@ struct pinctrl_dev *get_pinctrl_dev_from_devname(const char *devname)
 	return found ? pctldev : NULL;
 }
 
+struct pinctrl_dev *get_pinctrl_dev_from_of_node(struct device_node *np)
+{
+	struct pinctrl_dev *pctldev;
+
+	mutex_lock(&pinctrldev_list_mutex);
+
+	list_for_each_entry(pctldev, &pinctrldev_list, node)
+		if (pctldev->dev->of_node == np) {
+			mutex_unlock(&pinctrldev_list_mutex);
+			return pctldev;
+		}
+
+	mutex_lock(&pinctrldev_list_mutex);
+
+	return NULL;
+}
+
 /**
  * pin_get_from_name() - look up a pin number from a name
  * @pctldev: the pin control device to lookup the pin on
@@ -170,9 +193,9 @@ bool pin_is_valid(struct pinctrl_dev *pctldev, int pin)
 	if (pin < 0)
 		return false;
 
-	mutex_lock(&pinctrl_mutex);
+	mutex_lock(&pctldev->mutex);
 	pindesc = pin_desc_get(pctldev, pin);
-	mutex_unlock(&pinctrl_mutex);
+	mutex_unlock(&pctldev->mutex);
 
 	return pindesc != NULL;
 }
@@ -269,15 +292,17 @@ pinctrl_match_gpio_range(struct pinctrl_dev *pctldev, unsigned gpio)
 {
 	struct pinctrl_gpio_range *range = NULL;
 
+	mutex_lock(&pctldev->mutex);
 	/* Loop over the ranges */
 	list_for_each_entry(range, &pctldev->gpio_ranges, node) {
 		/* Check if we're in the valid range */
 		if (gpio >= range->base &&
 		    gpio < range->base + range->npins) {
+			mutex_unlock(&pctldev->mutex);
 			return range;
 		}
 	}
-
+	mutex_unlock(&pctldev->mutex);
 	return NULL;
 }
 
@@ -361,9 +386,9 @@ static int pinctrl_get_device_gpio_range(unsigned gpio,
 void pinctrl_add_gpio_range(struct pinctrl_dev *pctldev,
 			    struct pinctrl_gpio_range *range)
 {
-	mutex_lock(&pinctrl_mutex);
+	mutex_lock(&pctldev->mutex);
 	list_add_tail(&range->node, &pctldev->gpio_ranges);
-	mutex_unlock(&pinctrl_mutex);
+	mutex_unlock(&pctldev->mutex);
 }
 EXPORT_SYMBOL_GPL(pinctrl_add_gpio_range);
 
@@ -381,17 +406,25 @@ EXPORT_SYMBOL_GPL(pinctrl_add_gpio_ranges);
 struct pinctrl_dev *pinctrl_find_and_add_gpio_range(const char *devname,
 		struct pinctrl_gpio_range *range)
 {
-	struct pinctrl_dev *pctldev = get_pinctrl_dev_from_devname(devname);
+	struct pinctrl_dev *pctldev;
+
+	mutex_lock(&pinctrldev_list_mutex);
+
+	pctldev = get_pinctrl_dev_from_devname(devname);
 
 	/*
 	 * If we can't find this device, let's assume that is because
 	 * it has not probed yet, so the driver trying to register this
 	 * range need to defer probing.
 	 */
-	if (!pctldev)
+	if (!pctldev) {
+		mutex_unlock(&pinctrldev_list_mutex);
 		return ERR_PTR(-EPROBE_DEFER);
-
+	}
 	pinctrl_add_gpio_range(pctldev, range);
+
+	mutex_unlock(&pinctrldev_list_mutex);
+
 	return pctldev;
 }
 EXPORT_SYMBOL_GPL(pinctrl_find_and_add_gpio_range);
@@ -407,14 +440,17 @@ pinctrl_find_gpio_range_from_pin(struct pinctrl_dev *pctldev,
 {
 	struct pinctrl_gpio_range *range = NULL;
 
+	mutex_lock(&pctldev->mutex);
 	/* Loop over the ranges */
 	list_for_each_entry(range, &pctldev->gpio_ranges, node) {
 		/* Check if we're in the valid range */
 		if (pin >= range->pin_base &&
 		    pin < range->pin_base + range->npins) {
+			mutex_unlock(&pctldev->mutex);
 			return range;
 		}
 	}
+	mutex_unlock(&pctldev->mutex);
 
 	return NULL;
 }
@@ -428,9 +464,9 @@ EXPORT_SYMBOL_GPL(pinctrl_find_gpio_range_from_pin);
 void pinctrl_remove_gpio_range(struct pinctrl_dev *pctldev,
 			       struct pinctrl_gpio_range *range)
 {
-	mutex_lock(&pinctrl_mutex);
+	mutex_lock(&pctldev->mutex);
 	list_del(&range->node);
-	mutex_unlock(&pinctrl_mutex);
+	mutex_unlock(&pctldev->mutex);
 }
 EXPORT_SYMBOL_GPL(pinctrl_remove_gpio_range);
 
@@ -481,13 +517,13 @@ int pinctrl_request_gpio(unsigned gpio)
 	int ret;
 	int pin;
 
-	mutex_lock(&pinctrl_mutex);
+	mutex_lock(&pinctrldev_list_mutex);
 
 	ret = pinctrl_get_device_gpio_range(gpio, &pctldev, &range);
 	if (ret) {
 		if (pinctrl_ready_for_gpio_range(gpio))
 			ret = 0;
-		mutex_unlock(&pinctrl_mutex);
+		mutex_unlock(&pinctrldev_list_mutex);
 		return ret;
 	}
 
@@ -496,7 +532,7 @@ int pinctrl_request_gpio(unsigned gpio)
 
 	ret = pinmux_request_gpio(pctldev, range, pin, gpio);
 
-	mutex_unlock(&pinctrl_mutex);
+	mutex_unlock(&pinctrldev_list_mutex);
 	return ret;
 }
 EXPORT_SYMBOL_GPL(pinctrl_request_gpio);
@@ -516,20 +552,22 @@ void pinctrl_free_gpio(unsigned gpio)
 	int ret;
 	int pin;
 
-	mutex_lock(&pinctrl_mutex);
+	mutex_lock(&pinctrldev_list_mutex);
 
 	ret = pinctrl_get_device_gpio_range(gpio, &pctldev, &range);
 	if (ret) {
-		mutex_unlock(&pinctrl_mutex);
+		mutex_unlock(&pinctrldev_list_mutex);
 		return;
 	}
+	mutex_lock(&pctldev->mutex);
 
 	/* Convert to the pin controllers number space */
 	pin = gpio - range->base + range->pin_base;
 
 	pinmux_free_gpio(pctldev, pin, range);
 
-	mutex_unlock(&pinctrl_mutex);
+	mutex_unlock(&pctldev->mutex);
+	mutex_unlock(&pinctrldev_list_mutex);
 }
 EXPORT_SYMBOL_GPL(pinctrl_free_gpio);
 
@@ -540,14 +578,24 @@ static int pinctrl_gpio_direction(unsigned gpio, bool input)
 	int ret;
 	int pin;
 
+	mutex_lock(&pinctrldev_list_mutex);
+
 	ret = pinctrl_get_device_gpio_range(gpio, &pctldev, &range);
-	if (ret)
+	if (ret) {
+		mutex_unlock(&pinctrldev_list_mutex);
 		return ret;
+	}
+
+	mutex_lock(&pctldev->mutex);
 
 	/* Convert to the pin controllers number space */
 	pin = gpio - range->base + range->pin_base;
+	ret = pinmux_gpio_direction(pctldev, range, pin, input);
+
+	mutex_unlock(&pctldev->mutex);
+	mutex_unlock(&pinctrldev_list_mutex);
 
-	return pinmux_gpio_direction(pctldev, range, pin, input);
+	return ret;
 }
 
 /**
@@ -560,11 +608,7 @@ static int pinctrl_gpio_direction(unsigned gpio, bool input)
  */
 int pinctrl_gpio_direction_input(unsigned gpio)
 {
-	int ret;
-	mutex_lock(&pinctrl_mutex);
-	ret = pinctrl_gpio_direction(gpio, true);
-	mutex_unlock(&pinctrl_mutex);
-	return ret;
+	return pinctrl_gpio_direction(gpio, true);
 }
 EXPORT_SYMBOL_GPL(pinctrl_gpio_direction_input);
 
@@ -578,11 +622,7 @@ EXPORT_SYMBOL_GPL(pinctrl_gpio_direction_input);
  */
 int pinctrl_gpio_direction_output(unsigned gpio)
 {
-	int ret;
-	mutex_lock(&pinctrl_mutex);
-	ret = pinctrl_gpio_direction(gpio, false);
-	mutex_unlock(&pinctrl_mutex);
-	return ret;
+	return pinctrl_gpio_direction(gpio, false);
 }
 EXPORT_SYMBOL_GPL(pinctrl_gpio_direction_output);
 
@@ -685,14 +725,18 @@ static struct pinctrl *find_pinctrl(struct device *dev)
 {
 	struct pinctrl *p;
 
+	mutex_lock(&pinctrl_list_mutex);
 	list_for_each_entry(p, &pinctrl_list, node)
-		if (p->dev == dev)
+		if (p->dev == dev) {
+			mutex_unlock(&pinctrl_list_mutex);
 			return p;
+		}
 
+	mutex_unlock(&pinctrl_list_mutex);
 	return NULL;
 }
 
-static void pinctrl_put_locked(struct pinctrl *p, bool inlist);
+static void pinctrl_free(struct pinctrl *p, bool inlist);
 
 static struct pinctrl *create_pinctrl(struct device *dev)
 {
@@ -725,6 +769,7 @@ static struct pinctrl *create_pinctrl(struct device *dev)
 
 	devname = dev_name(dev);
 
+	mutex_lock(&pinctrl_maps_mutex);
 	/* Iterate over the pin control maps to locate the right ones */
 	for_each_maps(maps_node, i, map) {
 		/* Map must be for this device */
@@ -746,13 +791,16 @@ static struct pinctrl *create_pinctrl(struct device *dev)
 		 * an -EPROBE_DEFER later, as that is the worst case.
 		 */
 		if (ret == -EPROBE_DEFER) {
-			pinctrl_put_locked(p, false);
+			pinctrl_free(p, false);
+			mutex_unlock(&pinctrl_maps_mutex);
 			return ERR_PTR(ret);
 		}
 	}
+	mutex_unlock(&pinctrl_maps_mutex);
+
 	if (ret < 0) {
 		/* If some other error than deferral occured, return here */
-		pinctrl_put_locked(p, false);
+		pinctrl_free(p, false);
 		return ERR_PTR(ret);
 	}
 
@@ -764,7 +812,11 @@ static struct pinctrl *create_pinctrl(struct device *dev)
 	return p;
 }
 
-static struct pinctrl *pinctrl_get_locked(struct device *dev)
+/**
+ * pinctrl_get() - retrieves the pinctrl handle for a device
+ * @dev: the device to obtain the handle for
+ */
+struct pinctrl *pinctrl_get(struct device *dev)
 {
 	struct pinctrl *p;
 
@@ -785,21 +837,6 @@ static struct pinctrl *pinctrl_get_locked(struct device *dev)
 
 	return create_pinctrl(dev);
 }
-
-/**
- * pinctrl_get() - retrieves the pinctrl handle for a device
- * @dev: the device to obtain the handle for
- */
-struct pinctrl *pinctrl_get(struct device *dev)
-{
-	struct pinctrl *p;
-
-	mutex_lock(&pinctrl_mutex);
-	p = pinctrl_get_locked(dev);
-	mutex_unlock(&pinctrl_mutex);
-
-	return p;
-}
 EXPORT_SYMBOL_GPL(pinctrl_get);
 
 static void pinctrl_free_setting(bool disable_setting,
@@ -820,11 +857,12 @@ static void pinctrl_free_setting(bool disable_setting,
 	}
 }
 
-static void pinctrl_put_locked(struct pinctrl *p, bool inlist)
+static void pinctrl_free(struct pinctrl *p, bool inlist)
 {
 	struct pinctrl_state *state, *n1;
 	struct pinctrl_setting *setting, *n2;
 
+	mutex_lock(&pinctrl_list_mutex);
 	list_for_each_entry_safe(state, n1, &p->states, node) {
 		list_for_each_entry_safe(setting, n2, &state->settings, node) {
 			pinctrl_free_setting(state == p->state, setting);
@@ -840,6 +878,7 @@ static void pinctrl_put_locked(struct pinctrl *p, bool inlist)
 	if (inlist)
 		list_del(&p->node);
 	kfree(p);
+	mutex_unlock(&pinctrl_list_mutex);
 }
 
 /**
@@ -850,7 +889,7 @@ static void pinctrl_release(struct kref *kref)
 {
 	struct pinctrl *p = container_of(kref, struct pinctrl, users);
 
-	pinctrl_put_locked(p, true);
+	pinctrl_free(p, true);
 }
 
 /**
@@ -859,14 +898,17 @@ static void pinctrl_release(struct kref *kref)
  */
 void pinctrl_put(struct pinctrl *p)
 {
-	mutex_lock(&pinctrl_mutex);
 	kref_put(&p->users, pinctrl_release);
-	mutex_unlock(&pinctrl_mutex);
 }
 EXPORT_SYMBOL_GPL(pinctrl_put);
 
-static struct pinctrl_state *pinctrl_lookup_state_locked(struct pinctrl *p,
-							 const char *name)
+/**
+ * pinctrl_lookup_state() - retrieves a state handle from a pinctrl handle
+ * @p: the pinctrl handle to retrieve the state from
+ * @name: the state name to retrieve
+ */
+struct pinctrl_state *pinctrl_lookup_state(struct pinctrl *p,
+						 const char *name)
 {
 	struct pinctrl_state *state;
 
@@ -883,26 +925,14 @@ static struct pinctrl_state *pinctrl_lookup_state_locked(struct pinctrl *p,
 
 	return state;
 }
+EXPORT_SYMBOL_GPL(pinctrl_lookup_state);
 
 /**
- * pinctrl_lookup_state() - retrieves a state handle from a pinctrl handle
- * @p: the pinctrl handle to retrieve the state from
- * @name: the state name to retrieve
+ * pinctrl_select_state() - select/activate/program a pinctrl state to HW
+ * @p: the pinctrl handle for the device that requests configuration
+ * @state: the state handle to select/activate/program
  */
-struct pinctrl_state *pinctrl_lookup_state(struct pinctrl *p, const char *name)
-{
-	struct pinctrl_state *s;
-
-	mutex_lock(&pinctrl_mutex);
-	s = pinctrl_lookup_state_locked(p, name);
-	mutex_unlock(&pinctrl_mutex);
-
-	return s;
-}
-EXPORT_SYMBOL_GPL(pinctrl_lookup_state);
-
-static int pinctrl_select_state_locked(struct pinctrl *p,
-				       struct pinctrl_state *state)
+int pinctrl_select_state(struct pinctrl *p, struct pinctrl_state *state)
 {
 	struct pinctrl_setting *setting, *setting2;
 	struct pinctrl_state *old_state = p->state;
@@ -956,8 +986,9 @@ static int pinctrl_select_state_locked(struct pinctrl *p,
 			break;
 		}
 
-		if (ret < 0)
+		if (ret < 0) {
 			goto unapply_new_state;
+		}
 	}
 
 	p->state = state;
@@ -983,28 +1014,11 @@ unapply_new_state:
 
 	/* There's no infinite recursive loop here because p->state is NULL */
 	if (old_state)
-		pinctrl_select_state_locked(p, old_state);
+		pinctrl_select_state(p, old_state);
 
 	return ret;
 }
 
-/**
- * pinctrl_select() - select/activate/program a pinctrl state to HW
- * @p: the pinctrl handle for the device that requests configuratio
- * @state: the state handle to select/activate/program
- */
-int pinctrl_select_state(struct pinctrl *p, struct pinctrl_state *state)
-{
-	int ret;
-
-	mutex_lock(&pinctrl_mutex);
-	ret = pinctrl_select_state_locked(p, state);
-	mutex_unlock(&pinctrl_mutex);
-
-	return ret;
-}
-EXPORT_SYMBOL_GPL(pinctrl_select_state);
-
 static void devm_pinctrl_release(struct device *dev, void *res)
 {
 	pinctrl_put(*(struct pinctrl **)res);
@@ -1129,10 +1143,10 @@ int pinctrl_register_map(struct pinctrl_map const *maps, unsigned num_maps,
 	}
 
 	if (!locked)
-		mutex_lock(&pinctrl_mutex);
+		mutex_lock(&pinctrl_maps_mutex);
 	list_add_tail(&maps_node->node, &pinctrl_maps);
 	if (!locked)
-		mutex_unlock(&pinctrl_mutex);
+		mutex_unlock(&pinctrl_maps_mutex);
 
 	return 0;
 }
@@ -1154,12 +1168,15 @@ void pinctrl_unregister_map(struct pinctrl_map const *map)
 {
 	struct pinctrl_maps *maps_node;
 
+	mutex_lock(&pinctrl_maps_mutex);
 	list_for_each_entry(maps_node, &pinctrl_maps, node) {
 		if (maps_node->maps == map) {
 			list_del(&maps_node->node);
+			mutex_unlock(&pinctrl_maps_mutex);
 			return;
 		}
 	}
+	mutex_unlock(&pinctrl_maps_mutex);
 }
 
 /**
@@ -1196,7 +1213,7 @@ static int pinctrl_pins_show(struct seq_file *s, void *what)
 
 	seq_printf(s, "registered pins: %d\n", pctldev->desc->npins);
 
-	mutex_lock(&pinctrl_mutex);
+	mutex_lock(&pctldev->mutex);
 
 	/* The pin number can be retrived from the pin controller descriptor */
 	for (i = 0; i < pctldev->desc->npins; i++) {
@@ -1218,7 +1235,7 @@ static int pinctrl_pins_show(struct seq_file *s, void *what)
 		seq_puts(s, "\n");
 	}
 
-	mutex_unlock(&pinctrl_mutex);
+	mutex_unlock(&pctldev->mutex);
 
 	return 0;
 }
@@ -1229,8 +1246,9 @@ static int pinctrl_groups_show(struct seq_file *s, void *what)
 	const struct pinctrl_ops *ops = pctldev->desc->pctlops;
 	unsigned ngroups, selector = 0;
 
+	mutex_lock(&pctldev->mutex);
+
 	ngroups = ops->get_groups_count(pctldev);
-	mutex_lock(&pinctrl_mutex);
 
 	seq_puts(s, "registered pin groups:\n");
 	while (selector < ngroups) {
@@ -1251,7 +1269,7 @@ static int pinctrl_groups_show(struct seq_file *s, void *what)
 			for (i = 0; i < num_pins; i++) {
 				pname = pin_get_name(pctldev, pins[i]);
 				if (WARN_ON(!pname)) {
-					mutex_unlock(&pinctrl_mutex);
+					mutex_unlock(&pctldev->mutex);
 					return -EINVAL;
 				}
 				seq_printf(s, "pin %d (%s)\n", pins[i], pname);
@@ -1261,7 +1279,7 @@ static int pinctrl_groups_show(struct seq_file *s, void *what)
 		selector++;
 	}
 
-	mutex_unlock(&pinctrl_mutex);
+	mutex_unlock(&pctldev->mutex);
 
 	return 0;
 }
@@ -1273,7 +1291,7 @@ static int pinctrl_gpioranges_show(struct seq_file *s, void *what)
 
 	seq_puts(s, "GPIO ranges handled:\n");
 
-	mutex_lock(&pinctrl_mutex);
+	mutex_lock(&pctldev->mutex);
 
 	/* Loop over the ranges */
 	list_for_each_entry(range, &pctldev->gpio_ranges, node) {
@@ -1284,7 +1302,7 @@ static int pinctrl_gpioranges_show(struct seq_file *s, void *what)
 			   (range->pin_base + range->npins - 1));
 	}
 
-	mutex_unlock(&pinctrl_mutex);
+	mutex_unlock(&pctldev->mutex);
 
 	return 0;
 }
@@ -1295,7 +1313,7 @@ static int pinctrl_devices_show(struct seq_file *s, void *what)
 
 	seq_puts(s, "name [pinmux] [pinconf]\n");
 
-	mutex_lock(&pinctrl_mutex);
+	mutex_lock(&pinctrldev_list_mutex);
 
 	list_for_each_entry(pctldev, &pinctrldev_list, node) {
 		seq_printf(s, "%s ", pctldev->desc->name);
@@ -1310,7 +1328,7 @@ static int pinctrl_devices_show(struct seq_file *s, void *what)
 		seq_puts(s, "\n");
 	}
 
-	mutex_unlock(&pinctrl_mutex);
+	mutex_unlock(&pinctrldev_list_mutex);
 
 	return 0;
 }
@@ -1339,8 +1357,7 @@ static int pinctrl_maps_show(struct seq_file *s, void *what)
 
 	seq_puts(s, "Pinctrl maps:\n");
 
-	mutex_lock(&pinctrl_mutex);
-
+	mutex_lock(&pinctrl_maps_mutex);
 	for_each_maps(maps_node, i, map) {
 		seq_printf(s, "device %s\nstate %s\ntype %s (%d)\n",
 			   map->dev_name, map->name, map_type(map->type),
@@ -1364,8 +1381,7 @@ static int pinctrl_maps_show(struct seq_file *s, void *what)
 
 		seq_printf(s, "\n");
 	}
-
-	mutex_unlock(&pinctrl_mutex);
+	mutex_unlock(&pinctrl_maps_mutex);
 
 	return 0;
 }
@@ -1378,7 +1394,7 @@ static int pinctrl_show(struct seq_file *s, void *what)
 
 	seq_puts(s, "Requested pin control handlers their pinmux maps:\n");
 
-	mutex_lock(&pinctrl_mutex);
+	mutex_lock(&pinctrl_list_mutex);
 
 	list_for_each_entry(p, &pinctrl_list, node) {
 		seq_printf(s, "device: %s current state: %s\n",
@@ -1410,7 +1426,7 @@ static int pinctrl_show(struct seq_file *s, void *what)
 		}
 	}
 
-	mutex_unlock(&pinctrl_mutex);
+	mutex_unlock(&pinctrl_list_mutex);
 
 	return 0;
 }
@@ -1596,6 +1612,7 @@ struct pinctrl_dev *pinctrl_register(struct pinctrl_desc *pctldesc,
 	INIT_RADIX_TREE(&pctldev->pin_desc_tree, GFP_KERNEL);
 	INIT_LIST_HEAD(&pctldev->gpio_ranges);
 	pctldev->dev = dev;
+	mutex_init(&pctldev->mutex);
 
 	/* check core ops for sanity */
 	if (pinctrl_check_ops(pctldev)) {
@@ -1625,38 +1642,37 @@ struct pinctrl_dev *pinctrl_register(struct pinctrl_desc *pctldesc,
 		goto out_err;
 	}
 
-	mutex_lock(&pinctrl_mutex);
-
+	mutex_lock(&pinctrldev_list_mutex);
 	list_add_tail(&pctldev->node, &pinctrldev_list);
+	mutex_unlock(&pinctrldev_list_mutex);
+
+	pctldev->p = pinctrl_get(pctldev->dev);
 
-	pctldev->p = pinctrl_get_locked(pctldev->dev);
 	if (!IS_ERR(pctldev->p)) {
 		pctldev->hog_default =
-			pinctrl_lookup_state_locked(pctldev->p,
-						    PINCTRL_STATE_DEFAULT);
+			pinctrl_lookup_state(pctldev->p, PINCTRL_STATE_DEFAULT);
 		if (IS_ERR(pctldev->hog_default)) {
 			dev_dbg(dev, "failed to lookup the default state\n");
 		} else {
-			if (pinctrl_select_state_locked(pctldev->p,
+			if (pinctrl_select_state(pctldev->p,
 						pctldev->hog_default))
 				dev_err(dev,
 					"failed to select default state\n");
 		}
 
 		pctldev->hog_sleep =
-			pinctrl_lookup_state_locked(pctldev->p,
+			pinctrl_lookup_state(pctldev->p,
 						    PINCTRL_STATE_SLEEP);
 		if (IS_ERR(pctldev->hog_sleep))
 			dev_dbg(dev, "failed to lookup the sleep state\n");
 	}
 
-	mutex_unlock(&pinctrl_mutex);
-
 	pinctrl_init_device_debugfs(pctldev);
 
 	return pctldev;
 
 out_err:
+	mutex_destroy(&pctldev->mutex);
 	kfree(pctldev);
 	return NULL;
 }
@@ -1674,12 +1690,13 @@ void pinctrl_unregister(struct pinctrl_dev *pctldev)
 	if (pctldev == NULL)
 		return;
 
-	pinctrl_remove_device_debugfs(pctldev);
+	mutex_lock(&pinctrldev_list_mutex);
+	mutex_lock(&pctldev->mutex);
 
-	mutex_lock(&pinctrl_mutex);
+	pinctrl_remove_device_debugfs(pctldev);
 
 	if (!IS_ERR(pctldev->p))
-		pinctrl_put_locked(pctldev->p, true);
+		pinctrl_put(pctldev->p);
 
 	/* TODO: check that no pinmuxes are still active? */
 	list_del(&pctldev->node);
@@ -1690,9 +1707,10 @@ void pinctrl_unregister(struct pinctrl_dev *pctldev)
 	list_for_each_entry_safe(range, n, &pctldev->gpio_ranges, node)
 		list_del(&range->node);
 
+	mutex_unlock(&pctldev->mutex);
+	mutex_destroy(&pctldev->mutex);
 	kfree(pctldev);
-
-	mutex_unlock(&pinctrl_mutex);
+	mutex_unlock(&pinctrldev_list_mutex);
 }
 EXPORT_SYMBOL_GPL(pinctrl_unregister);
 
diff --git a/drivers/pinctrl/core.h b/drivers/pinctrl/core.h
index 6d3d400..75476b3 100644
--- a/drivers/pinctrl/core.h
+++ b/drivers/pinctrl/core.h
@@ -33,6 +33,7 @@ struct pinctrl_gpio_range;
  * @p: result of pinctrl_get() for this device
  * @hog_default: default state for pins hogged by this device
  * @hog_sleep: sleep state for pins hogged by this device
+ * @mutex: mutex taken on each pin controller specific action
  * @device_root: debugfs root for this device
  */
 struct pinctrl_dev {
@@ -46,6 +47,7 @@ struct pinctrl_dev {
 	struct pinctrl *p;
 	struct pinctrl_state *hog_default;
 	struct pinctrl_state *hog_sleep;
+	struct mutex mutex;
 #ifdef CONFIG_DEBUG_FS
 	struct dentry *device_root;
 #endif
@@ -168,6 +170,7 @@ struct pinctrl_maps {
 };
 
 struct pinctrl_dev *get_pinctrl_dev_from_devname(const char *dev_name);
+struct pinctrl_dev *get_pinctrl_dev_from_of_node(struct device_node *np);
 int pin_get_from_name(struct pinctrl_dev *pctldev, const char *name);
 const char *pin_get_name(struct pinctrl_dev *pctldev, const unsigned pin);
 int pinctrl_get_group_selector(struct pinctrl_dev *pctldev,
@@ -186,8 +189,7 @@ void pinctrl_unregister_map(struct pinctrl_map const *map);
 extern int pinctrl_force_sleep(struct pinctrl_dev *pctldev);
 extern int pinctrl_force_default(struct pinctrl_dev *pctldev);
 
-extern struct mutex pinctrl_mutex;
-extern struct list_head pinctrldev_list;
+extern struct mutex pinctrl_maps_mutex;
 extern struct list_head pinctrl_maps;
 
 #define for_each_maps(_maps_node_, _i_, _map_) \
diff --git a/drivers/pinctrl/devicetree.c b/drivers/pinctrl/devicetree.c
index c7b7cb4..340fb4e 100644
--- a/drivers/pinctrl/devicetree.c
+++ b/drivers/pinctrl/devicetree.c
@@ -95,22 +95,11 @@ static int dt_remember_or_free_map(struct pinctrl *p, const char *statename,
 	return pinctrl_register_map(map, num_maps, false, true);
 }
 
-static struct pinctrl_dev *find_pinctrl_by_of_node(struct device_node *np)
-{
-	struct pinctrl_dev *pctldev;
-
-	list_for_each_entry(pctldev, &pinctrldev_list, node)
-		if (pctldev->dev->of_node == np)
-			return pctldev;
-
-	return NULL;
-}
-
 struct pinctrl_dev *of_pinctrl_get(struct device_node *np)
 {
 	struct pinctrl_dev *pctldev;
 
-	pctldev = find_pinctrl_by_of_node(np);
+	pctldev = get_pinctrl_dev_from_of_node(np);
 	if (!pctldev)
 		return NULL;
 
@@ -138,7 +127,7 @@ static int dt_to_map_one_config(struct pinctrl *p, const char *statename,
 			/* OK let's just assume this will appear later then */
 			return -EPROBE_DEFER;
 		}
-		pctldev = find_pinctrl_by_of_node(np_pctldev);
+		pctldev = get_pinctrl_dev_from_of_node(np_pctldev);
 		if (pctldev)
 			break;
 		/* Do not defer probing of hogs (circular loop) */
diff --git a/drivers/pinctrl/pinconf.c b/drivers/pinctrl/pinconf.c
index 6f14b62..3578667 100644
--- a/drivers/pinctrl/pinconf.c
+++ b/drivers/pinctrl/pinconf.c
@@ -89,14 +89,14 @@ int pin_config_get(const char *dev_name, const char *name,
 	struct pinctrl_dev *pctldev;
 	int pin;
 
-	mutex_lock(&pinctrl_mutex);
-
 	pctldev = get_pinctrl_dev_from_devname(dev_name);
 	if (!pctldev) {
 		pin = -EINVAL;
-		goto unlock;
+		return pin;
 	}
 
+	mutex_lock(&pctldev->mutex);
+
 	pin = pin_get_from_name(pctldev, name);
 	if (pin < 0)
 		goto unlock;
@@ -104,7 +104,7 @@ int pin_config_get(const char *dev_name, const char *name,
 	pin = pin_config_get_for_pin(pctldev, pin, config);
 
 unlock:
-	mutex_unlock(&pinctrl_mutex);
+	mutex_unlock(&pctldev->mutex);
 	return pin;
 }
 EXPORT_SYMBOL(pin_config_get);
@@ -145,14 +145,14 @@ int pin_config_set(const char *dev_name, const char *name,
 	struct pinctrl_dev *pctldev;
 	int pin, ret;
 
-	mutex_lock(&pinctrl_mutex);
-
 	pctldev = get_pinctrl_dev_from_devname(dev_name);
 	if (!pctldev) {
 		ret = -EINVAL;
-		goto unlock;
+		return ret;
 	}
 
+	mutex_lock(&pctldev->mutex);
+
 	pin = pin_get_from_name(pctldev, name);
 	if (pin < 0) {
 		ret = pin;
@@ -162,7 +162,7 @@ int pin_config_set(const char *dev_name, const char *name,
 	ret = pin_config_set_for_pin(pctldev, pin, config);
 
 unlock:
-	mutex_unlock(&pinctrl_mutex);
+	mutex_unlock(&pctldev->mutex);
 	return ret;
 }
 EXPORT_SYMBOL(pin_config_set);
@@ -174,13 +174,14 @@ int pin_config_group_get(const char *dev_name, const char *pin_group,
 	const struct pinconf_ops *ops;
 	int selector, ret;
 
-	mutex_lock(&pinctrl_mutex);
-
 	pctldev = get_pinctrl_dev_from_devname(dev_name);
 	if (!pctldev) {
 		ret = -EINVAL;
-		goto unlock;
+		return ret;
 	}
+
+	mutex_lock(&pctldev->mutex);
+
 	ops = pctldev->desc->confops;
 
 	if (!ops || !ops->pin_config_group_get) {
@@ -200,7 +201,7 @@ int pin_config_group_get(const char *dev_name, const char *pin_group,
 	ret = ops->pin_config_group_get(pctldev, selector, config);
 
 unlock:
-	mutex_unlock(&pinctrl_mutex);
+	mutex_unlock(&pctldev->mutex);
 	return ret;
 }
 EXPORT_SYMBOL(pin_config_group_get);
@@ -217,13 +218,14 @@ int pin_config_group_set(const char *dev_name, const char *pin_group,
 	int ret;
 	int i;
 
-	mutex_lock(&pinctrl_mutex);
-
 	pctldev = get_pinctrl_dev_from_devname(dev_name);
 	if (!pctldev) {
 		ret = -EINVAL;
-		goto unlock;
+		return ret;
 	}
+
+	mutex_lock(&pctldev->mutex);
+
 	ops = pctldev->desc->confops;
 	pctlops = pctldev->desc->pctlops;
 
@@ -279,7 +281,7 @@ int pin_config_group_set(const char *dev_name, const char *pin_group,
 	ret = 0;
 
 unlock:
-	mutex_unlock(&pinctrl_mutex);
+	mutex_unlock(&pctldev->mutex);
 
 	return ret;
 }
@@ -487,7 +489,7 @@ static int pinconf_pins_show(struct seq_file *s, void *what)
 	seq_puts(s, "Pin config settings per pin\n");
 	seq_puts(s, "Format: pin (name): configs\n");
 
-	mutex_lock(&pinctrl_mutex);
+	mutex_lock(&pctldev->mutex);
 
 	/* The pin number can be retrived from the pin controller descriptor */
 	for (i = 0; i < pctldev->desc->npins; i++) {
@@ -507,7 +509,7 @@ static int pinconf_pins_show(struct seq_file *s, void *what)
 		seq_printf(s, "\n");
 	}
 
-	mutex_unlock(&pinctrl_mutex);
+	mutex_unlock(&pctldev->mutex);
 
 	return 0;
 }
@@ -608,7 +610,7 @@ static int pinconf_dbg_config_print(struct seq_file *s, void *d)
 	bool found = false;
 	unsigned long config;
 
-	mutex_lock(&pinctrl_mutex);
+	mutex_lock(&pctldev->mutex);
 
 	/* Parse the pinctrl map and look for the elected pin/state */
 	for_each_maps(maps_node, i, map) {
@@ -657,7 +659,7 @@ static int pinconf_dbg_config_print(struct seq_file *s, void *d)
 		confops->pin_config_config_dbg_show(pctldev, s, config);
 
 exit:
-	mutex_unlock(&pinctrl_mutex);
+	mutex_unlock(&pctldev->mutex);
 
 	return 0;
 }
@@ -747,7 +749,7 @@ static int pinconf_dbg_config_write(struct file *file,
 		return -EINVAL;
 	strncpy(config, token, MAX_NAME_LEN);
 
-	mutex_lock(&pinctrl_mutex);
+	mutex_lock(&pinctrl_maps_mutex);
 
 	/* Parse the pinctrl map and look for the selected dev/state/pin */
 	for_each_maps(maps_node, i, map) {
@@ -785,7 +787,7 @@ static int pinconf_dbg_config_write(struct file *file,
 	}
 
 exit:
-	mutex_unlock(&pinctrl_mutex);
+	mutex_unlock(&pinctrl_maps_mutex);
 
 	return count;
 }
diff --git a/drivers/pinctrl/pinmux.c b/drivers/pinctrl/pinmux.c
index bd83c8b..88cc509 100644
--- a/drivers/pinctrl/pinmux.c
+++ b/drivers/pinctrl/pinmux.c
@@ -506,7 +506,7 @@ static int pinmux_functions_show(struct seq_file *s, void *what)
 	if (!pmxops)
 		return 0;
 
-	mutex_lock(&pinctrl_mutex);
+	mutex_lock(&pctldev->mutex);
 	nfuncs = pmxops->get_functions_count(pctldev);
 	while (func_selector < nfuncs) {
 		const char *func = pmxops->get_function_name(pctldev,
@@ -530,7 +530,7 @@ static int pinmux_functions_show(struct seq_file *s, void *what)
 		func_selector++;
 	}
 
-	mutex_unlock(&pinctrl_mutex);
+	mutex_unlock(&pctldev->mutex);
 
 	return 0;
 }
@@ -548,7 +548,7 @@ static int pinmux_pins_show(struct seq_file *s, void *what)
 	seq_puts(s, "Pinmux settings per pin\n");
 	seq_puts(s, "Format: pin (name): mux_owner gpio_owner hog?\n");
 
-	mutex_lock(&pinctrl_mutex);
+	mutex_lock(&pctldev->mutex);
 
 	/* The pin number can be retrived from the pin controller descriptor */
 	for (i = 0; i < pctldev->desc->npins; i++) {
@@ -583,7 +583,7 @@ static int pinmux_pins_show(struct seq_file *s, void *what)
 			seq_printf(s, "\n");
 	}
 
-	mutex_unlock(&pinctrl_mutex);
+	mutex_unlock(&pctldev->mutex);
 
 	return 0;
 }
-- 
1.7.11.3



From arno at natisbad.org  Wed Apr 24 05:06:57 2013
From: arno at natisbad.org (Arnaud Ebalard)
Date: Wed, 24 Apr 2013 11:06:57 +0200
Subject: [PATCHv1 1/3] hwmon: Add support for GMT G762/G763 PWM fan
 controller
References: <cover.1366753420.git.arno@natisbad.org>
 <63961d39aee9db94767f28fd441312bec2029473.1366753420.git.arno@natisbad.org>
 <20130424053758.GC8710@lunn.ch>
Message-ID: <87obd4wb4e.fsf@natisbad.org>

Hi Andrew,

Andrew Lunn <andrew at lunn.ch> writes:

>> +struct g762_data {
>> +	struct i2c_client *client;
>> +	struct device *hwmon_dev;
>> +
>> +	/* update mutex */
>> +	struct mutex update_lock;
>> +
>> +	/* board specific parameters. */
>> +	u32 clk; /* default 32kHz */
>> +
>> +	/* g762 register cache */
>> +	bool valid;
>> +	unsigned long last_updated; /* in jiffies */
>> +
>> +	u8 set_cnt;  /* RPM cmd in close loop control */
>> +	u8 act_cnt;  /* formula: cnt = (CLK * 30)/(rpm * P) */
>> +	u8 fan_sta;  /* bit 0: set when actual fan speed is more than
>> +		      *        25% outside requested fan speed
>> +		      * bit 1: set when no transition occurs on fan
>> +		      *        pin for 0.7s
>> +		      */
>> +	u8 set_out;  /* output voltage/PWM duty in open loop control */
>> +	u8 fan_cmd1; /*   0: FG_PLS_ID0 FG pulses count per revolution
>> +		      *      0: 2 counts per revolution
>> +		      *      1: 4 counts per revolution
>> +		      *   1: PWM_POLARITY 1: negative_duty
>> +		      *                   0: positive_duty
>> +		      * 2,3: [FG_CLOCK_ID0, FG_CLK_ID1]
>> +		      *         00: Divide fan clock by 1
>> +		      *         01: Divide fan clock by 2
>> +		      *         10: Divide fan clock by 4
>> +		      *         11: Divide fan clock by 8
>> +		      *   4: FAN_MODE 1:close-loop, 0:open-loop
>> +		      *   5: OUT_MODE 1:PWM, 0:DAC
>> +		      *   6: DET_FAN_OOC enable "fan ooc" status
>> +		      *   7: DET_FAN_FAIL enable "fan fail" status
>> +		      */
>> +	u8 fan_cmd2; /* 0,1: FAN_STARTV 0,1,2,3 -> 0,32,64,96 dac_code
>> +		      * 2,3: FG_GEAR_MODE
>> +		      *         00: div = 1
>> +		      *         01: div = 2
>> +		      *         10: div = 4
>> +		      *   4: Mask ALERT# (g763 only)
>> +		      */
>
> You could consider using regmap for holding this cache.
>
> http://elceurope2012.sched.org/event/100619b669ce5767341624253aa03659?iframe=no&w=900&sidebar=yes&bg=no#.UXdspHLQ5jM
>
> http://elinux.org/ELCE_Europe_2012_Presentations

Interesting. As I am not yet familiar w/ regmap I would prefer having
the driver accepted during merge window with current data structure and
then convert it to regmap. But I will take a look (e.g. will study
fca1dd03 for instance). Thanks for the pointers. 

>> +/*
>> + * Helpers to import hardware characteristics from .dts file and overload
>> + * default config values.
>> + */
>> +
>> +#ifdef CONFIG_OF
>
> Can the driver be used without device tree? Would it be simpler to
>  just add depends OF in the Kconfig entry?

It can be used if the default params (or those configured by u-boot I
guess) fit your needs. I think it would be fairly easy to extend the
driver later to expose g762_config struct to allow parameters to be set
w/o using OF. If someone wants to do that, I think it is better to not
depend on OF in Kconfig at the moment but I have not strong argument
other that that one. I'll let you decide.

Cheers,

a+


From vkale at apm.com  Wed Apr 24 05:06:56 2013
From: vkale at apm.com (Vinayak Kale)
Date: Wed, 24 Apr 2013 14:36:56 +0530
Subject: [PATCH V3 0/4] arm64: Initial patch-set for APM X-Gene SOC family
Message-ID: <1366794420-17849-1-git-send-email-vkale@apm.com>

These are initial patches for APM X-Gene SOC family.
This patch-set is based on soc-armv8-model branch of git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch64.git

Changelog:

-V3:
 * added compatible field for board in dts file
 * made the model name string more descriptive in dts file
 * fixed the compatible field for cpu nodes in dts file
 * removed 'arm,cortex-a9-gic' fallback string from compatible field of gic node in dts file

-V2:
 * set NR_CPUS in arch/arm64/Kconfig based on selected targets
 * use default defconfig instead of xgene_defconfig
 * added 'apm-' prefix to dts filenames
 * fixed #address-cells in /cpus node in dts file
 * fixed cpu node naming under /cpus node in dts file
 * fixed serial device node name in dts file

-V1: Initial post

Vinayak Kale (4):
  arm64: Add Kconfig option for APM X-Gene SOC family
  arm64: Enable APM X-Gene SOC family in the defconfig
  arm64: Add defines for APM ARMv8 implementation
  arm64: Add initial DTS for APM X-Gene Storm SOC and APM Mustang board

 arch/arm64/Kconfig                  |    7 ++
 arch/arm64/boot/dts/Makefile        |    1 +
 arch/arm64/boot/dts/apm-mustang.dts |   26 ++++++++
 arch/arm64/boot/dts/apm-storm.dtsi  |  116 +++++++++++++++++++++++++++++++++++
 arch/arm64/configs/defconfig        |    4 +
 arch/arm64/include/asm/cputype.h    |    3 +
 6 files changed, 157 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm64/boot/dts/apm-mustang.dts
 create mode 100644 arch/arm64/boot/dts/apm-storm.dtsi

-- 
1.7.4.1



From vkale at apm.com  Wed Apr 24 05:06:57 2013
From: vkale at apm.com (Vinayak Kale)
Date: Wed, 24 Apr 2013 14:36:57 +0530
Subject: [PATCH V3 1/4] arm64: Add Kconfig option for APM X-Gene SOC family
In-Reply-To: <1366794420-17849-1-git-send-email-vkale@apm.com>
References: <1366794420-17849-1-git-send-email-vkale@apm.com>
Message-ID: <1366794420-17849-2-git-send-email-vkale@apm.com>

This patch adds arm64/Kconfig option for APM X-Gene SOC family.

Signed-off-by: Kumar Sankaran <ksankaran at apm.com>
Signed-off-by: Loc Ho <lho at apm.com>
Signed-off-by: Feng Kan <fkan at apm.com>
---
 arch/arm64/Kconfig |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 43b0e9f..16d0198 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -114,6 +114,11 @@ config ARCH_VEXPRESS
 	  This enables support for the ARMv8 software model (Versatile
 	  Express).
 
+config ARCH_XGENE
+	bool "AppliedMicro X-Gene SOC Family"
+	help
+	  This enables support for AppliedMicro X-Gene SOC Family
+
 endmenu
 
 menu "Bus support"
@@ -153,6 +158,8 @@ config NR_CPUS
 	int "Maximum number of CPUs (2-32)"
 	range 2 32
 	depends on SMP
+	# These have to remain sorted largest to smallest
+	default "8" if ARCH_XGENE
 	default "4"
 
 source kernel/Kconfig.preempt
-- 
1.7.4.1



From vkale at apm.com  Wed Apr 24 05:06:58 2013
From: vkale at apm.com (Vinayak Kale)
Date: Wed, 24 Apr 2013 14:36:58 +0530
Subject: [PATCH V3 2/4] arm64: Enable APM X-Gene SOC family in the defconfig
In-Reply-To: <1366794420-17849-1-git-send-email-vkale@apm.com>
References: <1366794420-17849-1-git-send-email-vkale@apm.com>
Message-ID: <1366794420-17849-3-git-send-email-vkale@apm.com>

This patch enables APM X-Gene SOC family in the defconfig. It also enables 8250 serial driver needed by X-Gene SOC family.

Signed-off-by: Kumar Sankaran <ksankaran at apm.com>
Signed-off-by: Loc Ho <lho at apm.com>
Signed-off-by: Feng Kan <fkan at apm.com>
---
 arch/arm64/configs/defconfig |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 09bef29..7dfad0a 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -23,6 +23,7 @@ CONFIG_MODULES=y
 CONFIG_MODULE_UNLOAD=y
 # CONFIG_BLK_DEV_BSG is not set
 # CONFIG_IOSCHED_DEADLINE is not set
+CONFIG_ARCH_XGENE=y
 CONFIG_SMP=y
 CONFIG_PREEMPT_VOLUNTARY=y
 CONFIG_CMDLINE="console=ttyAMA0"
@@ -52,6 +53,9 @@ CONFIG_INPUT_EVDEV=y
 # CONFIG_SERIO_I8042 is not set
 # CONFIG_SERIO_SERPORT is not set
 CONFIG_LEGACY_PTY_COUNT=16
+CONFIG_SERIAL_8250=y
+CONFIG_SERIAL_8250_CONSOLE=y
+CONFIG_SERIAL_OF_PLATFORM=y
 # CONFIG_HW_RANDOM is not set
 # CONFIG_HWMON is not set
 CONFIG_FB=y
-- 
1.7.4.1



From vkale at apm.com  Wed Apr 24 05:06:59 2013
From: vkale at apm.com (Vinayak Kale)
Date: Wed, 24 Apr 2013 14:36:59 +0530
Subject: [PATCH V3 3/4] arm64: Add defines for APM ARMv8 implementation
In-Reply-To: <1366794420-17849-1-git-send-email-vkale@apm.com>
References: <1366794420-17849-1-git-send-email-vkale@apm.com>
Message-ID: <1366794420-17849-4-git-send-email-vkale@apm.com>

This patch adds defines for APM CPU implementer ID and APM CPU part numbers in asm/cputype.h

Signed-off-by: Kumar Sankaran <ksankaran at apm.com>
Signed-off-by: Loc Ho <lho at apm.com>
Signed-off-by: Feng Kan <fkan at apm.com>
---
 arch/arm64/include/asm/cputype.h |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h
index cf27494..5fe138e 100644
--- a/arch/arm64/include/asm/cputype.h
+++ b/arch/arm64/include/asm/cputype.h
@@ -37,11 +37,14 @@
 })
 
 #define ARM_CPU_IMP_ARM		0x41
+#define ARM_CPU_IMP_APM		0x50
 
 #define ARM_CPU_PART_AEM_V8	0xD0F0
 #define ARM_CPU_PART_FOUNDATION	0xD000
 #define ARM_CPU_PART_CORTEX_A57	0xD070
 
+#define APM_CPU_PART_POTENZA	0x0000
+
 #ifndef __ASSEMBLY__
 
 /*
-- 
1.7.4.1



From vkale at apm.com  Wed Apr 24 05:07:00 2013
From: vkale at apm.com (Vinayak Kale)
Date: Wed, 24 Apr 2013 14:37:00 +0530
Subject: [PATCH V3 4/4] arm64: Add initial DTS for APM X-Gene Storm SOC and
 APM Mustang board
In-Reply-To: <1366794420-17849-1-git-send-email-vkale@apm.com>
References: <1366794420-17849-1-git-send-email-vkale@apm.com>
Message-ID: <1366794420-17849-5-git-send-email-vkale@apm.com>

This patch adds initial DTS files required for APM Mustang board.

Signed-off-by: Kumar Sankaran <ksankaran at apm.com>
Signed-off-by: Loc Ho <lho at apm.com>
Signed-off-by: Feng Kan <fkan at apm.com>
---
 arch/arm64/boot/dts/Makefile        |    1 +
 arch/arm64/boot/dts/apm-mustang.dts |   26 ++++++++
 arch/arm64/boot/dts/apm-storm.dtsi  |  116 +++++++++++++++++++++++++++++++++++
 3 files changed, 143 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm64/boot/dts/apm-mustang.dts
 create mode 100644 arch/arm64/boot/dts/apm-storm.dtsi

diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
index 68457e9..c52bdb0 100644
--- a/arch/arm64/boot/dts/Makefile
+++ b/arch/arm64/boot/dts/Makefile
@@ -1,4 +1,5 @@
 dtb-$(CONFIG_ARCH_VEXPRESS) += rtsm_ve-aemv8a.dtb foundation-v8.dtb
+dtb-$(CONFIG_ARCH_XGENE) += apm-mustang.dtb
 
 targets += dtbs
 targets += $(dtb-y)
diff --git a/arch/arm64/boot/dts/apm-mustang.dts b/arch/arm64/boot/dts/apm-mustang.dts
new file mode 100644
index 0000000..1247ca1
--- /dev/null
+++ b/arch/arm64/boot/dts/apm-mustang.dts
@@ -0,0 +1,26 @@
+/*
+ * dts file for AppliedMicro (APM) Mustang Board
+ *
+ * Copyright (C) 2013, Applied Micro Circuits Corporation
+ *
+ * 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/ "apm-storm.dtsi"
+
+/ {
+	model = "APM X-Gene Mustang board";
+	compatible = "apm,mustang", "apm,xgene-storm";
+
+	chosen { };
+
+	memory {
+		device_type = "memory";
+		reg = < 0x1 0x00000000 0x0 0x80000000 >; /* Updated by bootloader */
+	};
+};
diff --git a/arch/arm64/boot/dts/apm-storm.dtsi b/arch/arm64/boot/dts/apm-storm.dtsi
new file mode 100644
index 0000000..bfdc578
--- /dev/null
+++ b/arch/arm64/boot/dts/apm-storm.dtsi
@@ -0,0 +1,116 @@
+/*
+ * dts file for AppliedMicro (APM) X-Gene Storm SOC
+ *
+ * Copyright (C) 2013, Applied Micro Circuits Corporation
+ *
+ * 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.
+ */
+
+/ {
+	compatible = "apm,xgene-storm";
+	interrupt-parent = <&gic>;
+	#address-cells = <2>;
+	#size-cells = <2>;
+
+	cpus {
+		#address-cells = <2>;
+		#size-cells = <0>;
+
+		cpu at 000 {
+			device_type = "cpu";
+			compatible = "apm,potenza", "arm,armv8";
+			reg = <0x0 0x000>;
+			enable-method = "spin-table";
+			cpu-release-addr = <0x1 0x0000fff8>;
+		};
+		cpu at 001 {
+			device_type = "cpu";
+			compatible = "apm,potenza", "arm,armv8";
+			reg = <0x0 0x001>;
+			enable-method = "spin-table";
+			cpu-release-addr = <0x1 0x0000fff8>;
+		};
+		cpu at 100 {
+			device_type = "cpu";
+			compatible = "apm,potenza", "arm,armv8";
+			reg = <0x0 0x100>;
+			enable-method = "spin-table";
+			cpu-release-addr = <0x1 0x0000fff8>;
+		};
+		cpu at 101 {
+			device_type = "cpu";
+			compatible = "apm,potenza", "arm,armv8";
+			reg = <0x0 0x101>;
+			enable-method = "spin-table";
+			cpu-release-addr = <0x1 0x0000fff8>;
+		};
+		cpu at 200 {
+			device_type = "cpu";
+			compatible = "apm,potenza", "arm,armv8";
+			reg = <0x0 0x200>;
+			enable-method = "spin-table";
+			cpu-release-addr = <0x1 0x0000fff8>;
+		};
+		cpu at 201 {
+			device_type = "cpu";
+			compatible = "apm,potenza", "arm,armv8";
+			reg = <0x0 0x201>;
+			enable-method = "spin-table";
+			cpu-release-addr = <0x1 0x0000fff8>;
+		};
+		cpu at 300 {
+			device_type = "cpu";
+			compatible = "apm,potenza", "arm,armv8";
+			reg = <0x0 0x300>;
+			enable-method = "spin-table";
+			cpu-release-addr = <0x1 0x0000fff8>;
+		};
+		cpu at 301 {
+			device_type = "cpu";
+			compatible = "apm,potenza", "arm,armv8";
+			reg = <0x0 0x301>;
+			enable-method = "spin-table";
+			cpu-release-addr = <0x1 0x0000fff8>;
+		};
+	};
+
+	gic: interrupt-controller at 78010000 {
+		compatible = "arm,cortex-a15-gic";
+		#interrupt-cells = <3>;
+		interrupt-controller;
+		reg = <0x0 0x78010000 0x0 0x1000>,	/* GIC Dist */
+		      <0x0 0x78020000 0x0 0x1000>,	/* GIC CPU */
+		      <0x0 0x78040000 0x0 0x2000>,	/* GIC VCPU Control */
+		      <0x0 0x78060000 0x0 0x2000>;	/* GIC VCPU */
+		interrupts = <1 9 0xf04>;	/* GIC Maintenence IRQ */
+	};
+
+	timer {
+		compatible = "arm,armv8-timer";
+		interrupts = <1 0 0xff01>,	/* Secure Phys IRQ */
+			     <1 13 0xff01>,	/* Non-secure Phys IRQ */
+			     <1 14 0xff01>,	/* Virt IRQ */
+			     <1 15 0xff01>;	/* Hyp IRQ */
+		clock-frequency = <50000000>;
+	};
+
+	soc {
+		compatible = "simple-bus";
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
+
+		serial0: serial at 1c020000 {
+			device_type = "serial";
+			compatible = "ns16550";
+			reg = <0 0x1c020000 0x0 0x1000>;
+			reg-shift = <2>;
+			clock-frequency = <10000000>; /* Updated by bootloader */
+			interrupt-parent = <&gic>;
+			interrupts = <0x0 0x4c 0x4>;
+		};
+	};
+};
-- 
1.7.4.1



From dave.martin at linaro.org  Wed Apr 24 05:10:18 2013
From: dave.martin at linaro.org (Dave Martin)
Date: Wed, 24 Apr 2013 10:10:18 +0100
Subject: [PATCH v4 03/15] ARM: mcpm: introduce helpers for platform
 coherency exit/setup
In-Reply-To: <20130405230017.GC14308@quad.lixom.net>
References: <1360041732-17936-1-git-send-email-nicolas.pitre@linaro.org>
 <1360041732-17936-4-git-send-email-nicolas.pitre@linaro.org>
 <20130405230017.GC14308@quad.lixom.net>
Message-ID: <20130424091007.GA2664@linaro.org>

On Fri, Apr 05, 2013 at 04:00:17PM -0700, Olof Johansson wrote:
> Hi,
> 
> Just two nits below. One could be fixed incrementally, the other is
> a longer-term potential cleanup.
> 
> On Tue, Feb 05, 2013 at 12:22:00AM -0500, Nicolas Pitre wrote:
> 
> > diff --git a/arch/arm/include/asm/mcpm_entry.h b/arch/arm/include/asm/mcpm_entry.h
> > index 3286d5eb91..e76652209d 100644
> > --- a/arch/arm/include/asm/mcpm_entry.h
> > +++ b/arch/arm/include/asm/mcpm_entry.h
> > @@ -15,8 +15,37 @@
> >  #define MAX_CPUS_PER_CLUSTER	4
> >  #define MAX_NR_CLUSTERS		2
> >  
> > +/* Definitions for mcpm_sync_struct */
> > +#define CPU_DOWN		0x11
> > +#define CPU_COMING_UP		0x12
> > +#define CPU_UP			0x13
> > +#define CPU_GOING_DOWN		0x14
> > +
> > +#define CLUSTER_DOWN		0x21
> > +#define CLUSTER_UP		0x22
> > +#define CLUSTER_GOING_DOWN	0x23
> > +
> > +#define INBOUND_NOT_COMING_UP	0x31
> > +#define INBOUND_COMING_UP	0x32
> > +
> > +/* This is a complete guess. */
> > +#define __CACHE_WRITEBACK_ORDER	6
> > +#define __CACHE_WRITEBACK_GRANULE (1 << __CACHE_WRITEBACK_ORDER)
> 
> Something a little more educational could be useful here. It needs to
> be the max writeback/line size of the supported platforms of the binary
> kernel, i.e. if someone builds an SoC with 128-byte L2 cache lines this
> guess will break.

Will commented on the same thing.  Ideally, a suitable definition should
get selected through Kconfig.

The guess specified here is adequate for known b.L platforms, but a
better framework for configuring this is desirable.

My original comment here is certainly not very informative though --
I'll post a clarification.

> > +/* Offsets for the mcpm_sync_struct members, for use in asm: */
> > +#define MCPM_SYNC_CLUSTER_CPUS	0
> > +#define MCPM_SYNC_CPU_SIZE	__CACHE_WRITEBACK_GRANULE
> > +#define MCPM_SYNC_CLUSTER_CLUSTER \
> > +	(MCPM_SYNC_CLUSTER_CPUS + MCPM_SYNC_CPU_SIZE * MAX_CPUS_PER_CLUSTER)
> > +#define MCPM_SYNC_CLUSTER_INBOUND \
> > +	(MCPM_SYNC_CLUSTER_CLUSTER + __CACHE_WRITEBACK_GRANULE)
> > +#define MCPM_SYNC_CLUSTER_SIZE \
> > +	(MCPM_SYNC_CLUSTER_INBOUND + __CACHE_WRITEBACK_GRANULE)
> > +
> >  #ifndef __ASSEMBLY__
> >  
> > +#include <linux/types.h>
> > +
> >  /*
> >   * Platform specific code should use this symbol to set up secondary
> >   * entry location for processors to use when released from reset.
> > @@ -123,5 +152,39 @@ struct mcpm_platform_ops {
> >   */
> >  int __init mcpm_platform_register(const struct mcpm_platform_ops *ops);
> >  
> > +/* Synchronisation structures for coordinating safe cluster setup/teardown: */
> > +
> > +/*
> > + * When modifying this structure, make sure you update the MCPM_SYNC_ defines
> > + * to match.
> > + */
> 
> It would be nice to introduce something like arch/powerpc/kernel/asm-offsets.c
> on ARM to generate the ASM-side automatically from the C struct instead for
> this and other cases, but that's unrelated to this addition.

ARM already has its own asm-offsets, and we actually used this in an earlier
version of the patches.  However, this felt like pollution of that file for
not a lot of benefit.  Does powerpc have a problem with asm-offsets becoming
a dumping ground for random junk, or is there a better way to organise it?

Cheers
---Dave

> > +struct mcpm_sync_struct {
> > +	/* individual CPU states */
> > +	struct {
> > +		volatile s8 cpu __aligned(__CACHE_WRITEBACK_GRANULE);
> > +	} cpus[MAX_CPUS_PER_CLUSTER];
> > +
> > +	/* cluster state */
> > +	volatile s8 cluster __aligned(__CACHE_WRITEBACK_GRANULE);
> > +
> > +	/* inbound-side state */
> > +	volatile s8 inbound __aligned(__CACHE_WRITEBACK_GRANULE);
> > +};
> 
> 
> -Olof


From richard.genoud at gmail.com  Wed Apr 24 05:27:44 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Wed, 24 Apr 2013 11:27:44 +0200
Subject: [PATCH v8 3/8] spi/spi-atmel: add dmaengine support
In-Reply-To: <20130423183301.GX5019@opensource.wolfsonmicro.com>
References: <1364968581-23700-1-git-send-email-wenyou.yang@atmel.com>
 <1364968759-24036-1-git-send-email-wenyou.yang@atmel.com>
 <20130403102332.GA4633@lnx-rg>
 <20130423183301.GX5019@opensource.wolfsonmicro.com>
Message-ID: <CACQ1gAh8QyZReJF2nQLQYSrYLv0vCw_ZS5rLg+S39LbbMJQyxQ@mail.gmail.com>

2013/4/23 Mark Brown <broonie at kernel.org>:
> On Wed, Apr 03, 2013 at 12:23:35PM +0200, Richard GENOUD wrote:
>
> Richard, delete irrelevant context from your mails - it makes it much
> easier to find the content you added.
>
>> On [mer., 03.04.2013 13:59:19], Wenyou Yang wrote:
>
>> As I did some work on that one:
>> Signed-off-by: Richard Genoud <richard.genoud at gmail.com>
>>
>> BUT, there's one thing not working (at least for me !):
>> With DMA enabled, using spidev.
>> if we use the ioctl SPI_IOC_MESSAGE(x) (tested with x=3):
>
> I'd been expecting an updated series with this rolled in?

I did some more test with spidev and a MISO-MOSI loop as Wenyou suggested.

It's ok for me, on kernel 3.9-rc8 sam9g35, I didn't see any error.

Signed-off-by: Richard Genoud <richard.genoud at gmail.com>
Tested-by: Richard Genoud <richard.genoud at gmail.com>


From lorenzo.pieralisi at arm.com  Wed Apr 24 05:29:14 2013
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Wed, 24 Apr 2013 10:29:14 +0100
Subject: [RFC PATCH v2 03/13] ARM: mach-at91: cpus/cpu node dts updates
In-Reply-To: <20130423195259.GJ4998@game.jcrosoft.org>
References: <1366644455-16550-1-git-send-email-lorenzo.pieralisi@arm.com>
 <1366644455-16550-4-git-send-email-lorenzo.pieralisi@arm.com>
 <51768892.7060807@gmail.com>
 <20130423135304.GG22946@e102568-lin.cambridge.arm.com>
 <20130423195259.GJ4998@game.jcrosoft.org>
Message-ID: <20130424092914.GA1561@e102568-lin.cambridge.arm.com>

On Tue, Apr 23, 2013 at 08:52:59PM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 14:53 Tue 23 Apr     , Lorenzo Pieralisi wrote:
> > On Tue, Apr 23, 2013 at 02:11:46PM +0100, Rob Herring wrote:
> > > On 04/22/2013 10:27 AM, Lorenzo Pieralisi wrote:
> > > > This patch updates the in-kernel dts files according to the latest cpus
> > > > and cpu bindings updates for ARM.
> > > > 
> > > > Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
> > > > ---
> > > >  arch/arm/boot/dts/at91sam9260.dtsi | 2 +-
> > > >  arch/arm/boot/dts/at91sam9263.dtsi | 2 +-
> > > >  arch/arm/boot/dts/at91sam9g45.dtsi | 2 +-
> > > >  arch/arm/boot/dts/at91sam9n12.dtsi | 2 +-
> > > >  4 files changed, 4 insertions(+), 4 deletions(-)
> > > > 
> > > > diff --git a/arch/arm/boot/dts/at91sam9260.dtsi b/arch/arm/boot/dts/at91sam9260.dtsi
> > > > index cb7bcc5..2e9de85 100644
> > > > --- a/arch/arm/boot/dts/at91sam9260.dtsi
> > > > +++ b/arch/arm/boot/dts/at91sam9260.dtsi
> > > > @@ -33,7 +33,7 @@
> > > >  	};
> > > >  	cpus {
> > > >  		cpu at 0 {
> > > > -			compatible = "arm,arm926ejs";
> > > > +			compatible = "arm,arm926";
> > > 
> > > I don't understand why you are doing this. If this does not match the
> > > documentation, fix the documentation. We can't continue on changing dts
> > > files without reqard to breaking compatibility.
> > 
> > IMHO compatibility is already broken. There are a number of dts in the
> > kernel missing cpus and cpu nodes, others with cpu nodes missing
> > device_type = "cpu", missing cpu nodes compatible properties and the list
> > goes on and on. Those files got merged in the kernel before bindings were
> > properly defined for ARM so at that point in time the only reference was the
> > ePAPR and still, it was not followed (eg my broken patch above fails to add
> > device_type = "cpu" to the cpu node, should I change the documentation (ePAPR)
> > to make the dts above compliant ? I do not think so, I reckon we should fix
> > all dts and force them to comply with the ePAPR and the in-kernel bindings).
> > 
> > If we do not set in stone the bindings and draw a line now, this stuff will
> > go wild, it is already in a state that I do not like much.
> > 
> > The reason we are patching the compatible property above is to avoid having
> > compatible properties containing suffixes for CPUs, we do not deem that
> > necessary, see:
> > 
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2013-January/145305.html
> > 
> > That's just my opinion, open to change it to find a proper solution to this
> > issue as long as we make progress.
> 
> I do not agree when you set the compatible you need to be preceise the cpu is
> a arm926ejs not a arm926

I updated the bindings with all processor variants so that we will all
be happy again (I hope). My comments still stand though and these dts need
patching, I am posting the required changes in v3.

Lorenzo



From marc.zyngier at arm.com  Wed Apr 24 05:33:15 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 24 Apr 2013 10:33:15 +0100
Subject: [PATCH v3 11/32] arm64: KVM: CPU specific system registers
 handling
In-Reply-To: <20130423225921.GD20569@gmail.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
 <1365437854-30214-12-git-send-email-marc.zyngier@arm.com>
 <20130410170624.GL26992@mudshark.cambridge.arm.com>
 <5168307E.2080700@arm.com> <20130423225921.GD20569@gmail.com>
Message-ID: <5177A6DB.1080607@arm.com>

On 23/04/13 23:59, Christoffer Dall wrote:
> On Fri, Apr 12, 2013 at 05:04:14PM +0100, Marc Zyngier wrote:
>> On 10/04/13 18:06, Will Deacon wrote:
>>> On Mon, Apr 08, 2013 at 05:17:13PM +0100, Marc Zyngier wrote:
>>>> Add the support code for CPU specific system registers. Not much
>>>> here yet.
>>>>
>>>> Reviewed-by: Christopher Covington <cov at codeaurora.org>
>>>> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
>>>> ---
>>>>  arch/arm64/kvm/sys_regs_generic_v8.c | 85 ++++++++++++++++++++++++++++++++++++
>>>>  1 file changed, 85 insertions(+)
>>>>  create mode 100644 arch/arm64/kvm/sys_regs_generic_v8.c
>>>>
>>>> diff --git a/arch/arm64/kvm/sys_regs_generic_v8.c b/arch/arm64/kvm/sys_regs_generic_v8.c
>>>> new file mode 100644
>>>> index 0000000..d4e8039
>>>> --- /dev/null
>>>> +++ b/arch/arm64/kvm/sys_regs_generic_v8.c
>>>> @@ -0,0 +1,85 @@
>>>> +/*
>>>> + * Copyright (C) 2012,2013 - ARM Ltd
>>>> + * Author: Marc Zyngier <marc.zyngier at arm.com>
>>>> + *
>>>> + * Based on arch/arm/kvm/coproc_a15.c:
>>>> + * Copyright (C) 2012 - Virtual Open Systems and Columbia University
>>>> + * Authors: Rusty Russell <rusty at rustcorp.au>
>>>> + *          Christoffer Dall <c.dall at virtualopensystems.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.
>>>> + *
>>>> + * This program is distributed in the hope that it will be useful,
>>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>>>> + * GNU General Public License for more details.
>>>> + *
>>>> + * You should have received a copy of the GNU General Public License
>>>> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
>>>> + */
>>>> +#include <linux/kvm_host.h>
>>>> +#include <asm/cputype.h>
>>>> +#include <asm/kvm_arm.h>
>>>> +#include <asm/kvm_asm.h>
>>>> +#include <asm/kvm_host.h>
>>>> +#include <asm/kvm_emulate.h>
>>>> +#include <asm/kvm_coproc.h>
>>>> +#include <linux/init.h>
>>>> +
>>>> +#include "sys_regs.h"
>>>> +
>>>> +static bool access_actlr(struct kvm_vcpu *vcpu,
>>>> +			 const struct sys_reg_params *p,
>>>> +			 const struct sys_reg_desc *r)
>>>> +{
>>>> +	if (p->is_write)
>>>> +		return ignore_write(vcpu, p);
>>>> +
>>>> +	*vcpu_reg(vcpu, p->Rt) = vcpu_sys_reg(vcpu, ACTLR_EL1);
>>>> +	return true;
>>>> +}
>>>> +
>>>> +static void reset_actlr(struct kvm_vcpu *vcpu, const struct sys_reg_desc *r)
>>>> +{
>>>> +	u64 actlr;
>>>> +
>>>> +	asm volatile("mrs %0, actlr_el1\n" : "=r" (actlr));
>>>> +	vcpu_sys_reg(vcpu, ACTLR_EL1) = actlr;
>>>> +}
>>>
>>> Do we actually need this? If so, there are likely other registers (things
>>> like the ectlr) that should be considered too.
>>
>> I'm focussing on the architected registers, and only those. ECTLR is
>> implementation dependent, and is not specified as an architected sysreg.
>>
>> As this is one of the registers that we trap (TACR set in HCR_EL2), we
>> have to emulate it. Now, maybe it is not that useful to trap it (nobody
>> uses that code path yet).
>>
> why is this even in a generic_v8 file then? Should it not be able to be
> handled generically in the sys_regs file and only when you have specific
> meanings of the register for a specific core should you add something
> like this file?

That would be a possibility. But I'd rather have a separate file that
describes targets, rather then stuffing this into sys_regs.c (which is
already too big for my taste), and have the implementation defined
registers there.

The AEMv8/Foundation being "generic" implementations of ARMv8, I'm
giving them their own target file. The A57 mention in this file is just
a temporary hack until I get to boot the stuff on a real A57.

> I think it's preferred to have something that traps and shouts than
> something that may or may not work (ie. just allowing the guest to read
> the register directly), but you guys know better than me what kind of
> things can be exposed through this register in the future.

At least for the models, this handling of ACTLR_EL1 should be correct.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...



From marc.zyngier at arm.com  Wed Apr 24 05:36:18 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 24 Apr 2013 10:36:18 +0100
Subject: [PATCH v3 03/32] arm64: KVM: HYP mode idmap support
In-Reply-To: <20130423225733.GA20569@gmail.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
 <1365437854-30214-4-git-send-email-marc.zyngier@arm.com>
 <20130423225733.GA20569@gmail.com>
Message-ID: <5177A792.9030001@arm.com>

On 23/04/13 23:57, Christoffer Dall wrote:
> 
> 
> On Mon, Apr 8, 2013 at 9:17 AM, Marc Zyngier <marc.zyngier at arm.com> wrote:
>> Add the necessary infrastructure for identity-mapped HYP page
>> tables. Idmap-ed code must be in the ".hyp.idmap.text" linker
>> section.
>>
>> The rest of the HYP ends up in ".hyp.text".
>>
>> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
>> ---
>>  arch/arm64/kernel/vmlinux.lds.S | 16 ++++++++++++++++
>>  1 file changed, 16 insertions(+)
>>
>> diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
>> index 3fae2be..855d43d 100644
>> --- a/arch/arm64/kernel/vmlinux.lds.S
>> +++ b/arch/arm64/kernel/vmlinux.lds.S
>> @@ -17,6 +17,15 @@ ENTRY(stext)
>>
>>  jiffies = jiffies_64;
>>
>> +#define HYPERVISOR_TEXT                                        \
>> +       . = ALIGN(2048);                                \
> 
> why align to 2048?  Comment?

Vectors require a 2kB alignment. I'll add a comment to that effect.

> are you changing this to the same idea as for the 32-bit code to reduce the kernel size?

The mechanism is exactly the same indeed. Only the alignment
requirements are (massively) different.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...



From hechtb at gmail.com  Wed Apr 24 05:36:33 2013
From: hechtb at gmail.com (Bastian Hecht)
Date: Wed, 24 Apr 2013 11:36:33 +0200
Subject: [PATCH v3 1/2] ARM: shmobile: r8a7740: Add Suspend-To-RAM A3SM
In-Reply-To: <20130424074904.GG847@verge.net.au>
References: <1366196190-14011-1-git-send-email-hechtb+renesas@gmail.com>
 <20130424074904.GG847@verge.net.au>
Message-ID: <CABYn4swtOdJG18833FLXifeuVsL4R5vUzGjAg5Fv8r==CT5HBw@mail.gmail.com>

2013/4/24 Simon Horman <horms at verge.net.au>:
> On Wed, Apr 17, 2013 at 12:56:29PM +0200, Bastian Hecht wrote:
>> We add 2 Suspend to RAM modes:
>> - A3SM PLL0 on/off:     Power domain A3SM that contains the ARM core
>>                         and the 2nd level cache with either PLL0 on
>>                         or off
>>
>> As the suspend to memory mechanism we use A3SM PLL off. A3SM PLL on
>> is included here too, so CPUIdle can use both power down modes (not
>> included in this patch).
>>
>> The setup of the SYSC regarding the external IRQs is taken from
>> pm-sh7372.c from Magnus Damm.
>>
>> Signed-off-by: Bastian Hecht <hechtb+renesas at gmail.com>
>> ---
>> v3:
>>
>> We now stubbornly loop until the SoC really shuts down when we issue
>> the WFI command.
>
> Hi Bastian,
>
> could you let me know what the status of this series is.
> Is it ready to be queued-up for v3.11?

Hello Simon!

I consider it stable and as there are no more comments, I would be
happy if you queued it up.

Thanks,

Bastian


From girishks2000 at gmail.com  Wed Apr 24 05:37:47 2013
From: girishks2000 at gmail.com (Girish KS)
Date: Wed, 24 Apr 2013 15:07:47 +0530
Subject: [PATCH 1/3] spi: s3c64xx: added support for polling mode
In-Reply-To: <20130423151511.GR5019@opensource.wolfsonmicro.com>
References: <1366614565-3743-1-git-send-email-ks.giri@samsung.com>
 <1366614565-3743-2-git-send-email-ks.giri@samsung.com>
 <20130423151511.GR5019@opensource.wolfsonmicro.com>
Message-ID: <CAKrE-KcGecFNnyKj9AdDYwBOw_OO4o_V2DMjHmYX092fh4EQgw@mail.gmail.com>

On Tue, Apr 23, 2013 at 8:45 PM, Mark Brown <broonie at kernel.org> wrote:
> On Mon, Apr 22, 2013 at 12:39:23PM +0530, Girish K S wrote:
>> From: Girish K S <girishks2000 at gmail.com>
>>
>> The 64xx spi driver supports partial polling mode.
>> Only the last chunk of the transfer length is transferred
>> or recieved in polling mode.
>
> This appears to have a very noticable negative impact on SPI performance
> on my S3C6410 based system.  Not delved into it to test why but are you
> sure it's not mistakenly selecting polling?

If forced to polling you should see this message "Unable to get SPI rx
dma resource. Switching to poll mode". same if Tx dma resource is not
available from platform data.
Anyways let me cross check again on my tested systems.


From girishks2000 at gmail.com  Wed Apr 24 05:39:38 2013
From: girishks2000 at gmail.com (Girish KS)
Date: Wed, 24 Apr 2013 15:09:38 +0530
Subject: [PATCH 2/3] spi: s3c64xx: Added provision for dedicated cs pin
In-Reply-To: <20130423144256.GP5019@opensource.wolfsonmicro.com>
References: <1366614565-3743-1-git-send-email-ks.giri@samsung.com>
 <1366614565-3743-3-git-send-email-ks.giri@samsung.com>
 <20130423144256.GP5019@opensource.wolfsonmicro.com>
Message-ID: <CAKrE-KdJZHzVH-0sRkP2hyPBcn9CMiqgQBcrZTap6zwVuAhZLQ@mail.gmail.com>

On Tue, Apr 23, 2013 at 8:12 PM, Mark Brown <broonie at kernel.org> wrote:
> On Mon, Apr 22, 2013 at 12:39:24PM +0530, Girish K S wrote:
>> From: Girish K S <girishks2000 at gmail.com>
>>
>> The existing driver supports gpio based /cs signal.
>> For controller's that have one device per controller,
>> the slave device's /cs signal might be internally controlled
>> by the chip select bit of slave select register. They are not
>> externally asserted/deasserted using gpio pin.
>
> This doesn't build:
>
> drivers/spi/spi-s3c64xx.c: In function 's3c64xx_get_slave_ctrldata':
> drivers/spi/spi-s3c64xx.c:1023: error: 'sdd' undeclared (first use in this function)
> drivers/spi/spi-s3c64xx.c:1023: error: (Each undeclared identifier is reported only once
> drivers/spi/spi-s3c64xx.c:1023: error: for each function it appears in.)

Ohhhhhh. Sorry. forgot to commit the changes before patch generation


From andriy.shevchenko at linux.intel.com  Wed Apr 24 05:40:36 2013
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Wed, 24 Apr 2013 12:40:36 +0300
Subject: [PATCH 04/11] dmaengine: dw_dmac: simplify master selection
In-Reply-To: <1366796443-7083-1-git-send-email-andriy.shevchenko@linux.intel.com>
References: <1366796443-7083-1-git-send-email-andriy.shevchenko@linux.intel.com>
Message-ID: <1366796443-7083-4-git-send-email-andriy.shevchenko@linux.intel.com>

From: Arnd Bergmann <arnd at arndb.de>

The patch to add the common DMA binding added a dummy dw_dma_slave
structure into the dw_dma_chan structure in order to configure the
masters correctly. It turns out that this can be simplified if we
pick the DMA masters in the dwc_alloc_chan_resources function instead
and save them in the dw_dma_chan structure directly.

This could be simplified further once all users that today use
dw_dma_slave for configuration get converted to device tree based
setup instead.

(Upstream commit id: f776076b9fa82d630651c9af56359d80fce86d68)

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Signed-off-by: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
Acked-by: Viresh Kumar <viresh.kumar at linaro.org>
Cc: linux-arm-kernel at lists.infradead.org
Acked-by: Arnd Bergmann <arnd at arndb.de>
Signed-off-by: Vinod Koul <vinod.koul at intel.com>
---
 drivers/dma/dw_dmac.c      |   76 +++++++++++++++++---------------------------
 drivers/dma/dw_dmac_regs.h |    5 ++-
 2 files changed, 33 insertions(+), 48 deletions(-)

diff --git a/drivers/dma/dw_dmac.c b/drivers/dma/dw_dmac.c
index 274fd7d..951ef5b 100644
--- a/drivers/dma/dw_dmac.c
+++ b/drivers/dma/dw_dmac.c
@@ -49,29 +49,22 @@ static inline unsigned int dwc_get_sms(struct dw_dma_slave *slave)
 	return slave ? slave->src_master : 1;
 }
 
-#define SRC_MASTER	0
-#define DST_MASTER	1
-
-static inline unsigned int dwc_get_master(struct dma_chan *chan, int master)
+static inline void dwc_set_masters(struct dw_dma_chan *dwc)
 {
-	struct dw_dma *dw = to_dw_dma(chan->device);
-	struct dw_dma_slave *dws = chan->private;
-	unsigned int m;
-
-	if (master == SRC_MASTER)
-		m = dwc_get_sms(dws);
-	else
-		m = dwc_get_dms(dws);
+	struct dw_dma *dw = to_dw_dma(dwc->chan.device);
+	struct dw_dma_slave *dws = dwc->chan.private;
+	unsigned char mmax = dw->nr_masters - 1;
 
-	return min_t(unsigned int, dw->nr_masters - 1, m);
+	if (dwc->request_line == ~0) {
+		dwc->src_master = min_t(unsigned char, mmax, dwc_get_sms(dws));
+		dwc->dst_master = min_t(unsigned char, mmax, dwc_get_dms(dws));
+	}
 }
 
 #define DWC_DEFAULT_CTLLO(_chan) ({				\
 		struct dw_dma_chan *_dwc = to_dw_dma_chan(_chan);	\
 		struct dma_slave_config	*_sconfig = &_dwc->dma_sconfig;	\
 		bool _is_slave = is_slave_direction(_dwc->direction);	\
-		int _dms = dwc_get_master(_chan, DST_MASTER);		\
-		int _sms = dwc_get_master(_chan, SRC_MASTER);		\
 		u8 _smsize = _is_slave ? _sconfig->src_maxburst :	\
 			DW_DMA_MSIZE_16;			\
 		u8 _dmsize = _is_slave ? _sconfig->dst_maxburst :	\
@@ -81,8 +74,8 @@ static inline unsigned int dwc_get_master(struct dma_chan *chan, int master)
 		 | DWC_CTLL_SRC_MSIZE(_smsize)			\
 		 | DWC_CTLL_LLP_D_EN				\
 		 | DWC_CTLL_LLP_S_EN				\
-		 | DWC_CTLL_DMS(_dms)				\
-		 | DWC_CTLL_SMS(_sms));				\
+		 | DWC_CTLL_DMS(_dwc->dst_master)		\
+		 | DWC_CTLL_SMS(_dwc->src_master));		\
 	})
 
 /*
@@ -92,13 +85,6 @@ static inline unsigned int dwc_get_master(struct dma_chan *chan, int master)
  */
 #define NR_DESCS_PER_CHANNEL	64
 
-static inline unsigned int dwc_get_data_width(struct dma_chan *chan, int master)
-{
-	struct dw_dma *dw = to_dw_dma(chan->device);
-
-	return dw->data_width[dwc_get_master(chan, master)];
-}
-
 /*----------------------------------------------------------------------*/
 
 static struct device *chan2dev(struct dma_chan *chan)
@@ -172,13 +158,7 @@ static void dwc_initialize(struct dw_dma_chan *dwc)
 	if (dwc->initialized == true)
 		return;
 
-	if (dws && dws->cfg_hi == ~0 && dws->cfg_lo == ~0) {
-		/* Autoconfigure based on request line from DT */
-		if (dwc->direction == DMA_MEM_TO_DEV)
-			cfghi = DWC_CFGH_DST_PER(dwc->request_line);
-		else if (dwc->direction == DMA_DEV_TO_MEM)
-			cfghi = DWC_CFGH_SRC_PER(dwc->request_line);
-	} else if (dws) {
+	if (dws) {
 		/*
 		 * We need controller-specific data to set up slave
 		 * transfers.
@@ -189,9 +169,9 @@ static void dwc_initialize(struct dw_dma_chan *dwc)
 		cfglo |= dws->cfg_lo & ~DWC_CFGL_CH_PRIOR_MASK;
 	} else {
 		if (dwc->direction == DMA_MEM_TO_DEV)
-			cfghi = DWC_CFGH_DST_PER(dwc->dma_sconfig.slave_id);
+			cfghi = DWC_CFGH_DST_PER(dwc->request_line);
 		else if (dwc->direction == DMA_DEV_TO_MEM)
-			cfghi = DWC_CFGH_SRC_PER(dwc->dma_sconfig.slave_id);
+			cfghi = DWC_CFGH_SRC_PER(dwc->request_line);
 	}
 
 	channel_writel(dwc, CFG_LO, cfglo);
@@ -745,6 +725,7 @@ dwc_prep_dma_memcpy(struct dma_chan *chan, dma_addr_t dest, dma_addr_t src,
 		size_t len, unsigned long flags)
 {
 	struct dw_dma_chan	*dwc = to_dw_dma_chan(chan);
+	struct dw_dma		*dw = to_dw_dma(chan->device);
 	struct dw_desc		*desc;
 	struct dw_desc		*first;
 	struct dw_desc		*prev;
@@ -767,8 +748,8 @@ dwc_prep_dma_memcpy(struct dma_chan *chan, dma_addr_t dest, dma_addr_t src,
 
 	dwc->direction = DMA_MEM_TO_MEM;
 
-	data_width = min_t(unsigned int, dwc_get_data_width(chan, SRC_MASTER),
-			   dwc_get_data_width(chan, DST_MASTER));
+	data_width = min_t(unsigned int, dw->data_width[dwc->src_master],
+			   dw->data_width[dwc->dst_master]);
 
 	src_width = dst_width = min_t(unsigned int, data_width,
 				      dwc_fast_fls(src | dest | len));
@@ -826,6 +807,7 @@ dwc_prep_slave_sg(struct dma_chan *chan, struct scatterlist *sgl,
 		unsigned long flags, void *context)
 {
 	struct dw_dma_chan	*dwc = to_dw_dma_chan(chan);
+	struct dw_dma		*dw = to_dw_dma(chan->device);
 	struct dma_slave_config	*sconfig = &dwc->dma_sconfig;
 	struct dw_desc		*prev;
 	struct dw_desc		*first;
@@ -859,7 +841,7 @@ dwc_prep_slave_sg(struct dma_chan *chan, struct scatterlist *sgl,
 		ctllo |= sconfig->device_fc ? DWC_CTLL_FC(DW_DMA_FC_P_M2P) :
 			DWC_CTLL_FC(DW_DMA_FC_D_M2P);
 
-		data_width = dwc_get_data_width(chan, SRC_MASTER);
+		data_width = dw->data_width[dwc->src_master];
 
 		for_each_sg(sgl, sg, sg_len, i) {
 			struct dw_desc	*desc;
@@ -919,7 +901,7 @@ slave_sg_todev_fill_desc:
 		ctllo |= sconfig->device_fc ? DWC_CTLL_FC(DW_DMA_FC_P_P2M) :
 			DWC_CTLL_FC(DW_DMA_FC_D_P2M);
 
-		data_width = dwc_get_data_width(chan, DST_MASTER);
+		data_width = dw->data_width[dwc->dst_master];
 
 		for_each_sg(sgl, sg, sg_len, i) {
 			struct dw_desc	*desc;
@@ -1020,6 +1002,10 @@ set_runtime_config(struct dma_chan *chan, struct dma_slave_config *sconfig)
 	memcpy(&dwc->dma_sconfig, sconfig, sizeof(*sconfig));
 	dwc->direction = sconfig->direction;
 
+	/* Take the request line from slave_id member */
+	if (dwc->request_line == ~0)
+		dwc->request_line = sconfig->slave_id;
+
 	convert_burst(&dwc->dma_sconfig.src_maxburst);
 	convert_burst(&dwc->dma_sconfig.dst_maxburst);
 	convert_slave_id(dwc);
@@ -1170,6 +1156,8 @@ static int dwc_alloc_chan_resources(struct dma_chan *chan)
 	 * doesn't mean what you think it means), and status writeback.
 	 */
 
+	dwc_set_masters(dwc);
+
 	spin_lock_irqsave(&dwc->lock, flags);
 	i = dwc->descs_allocated;
 	while (dwc->descs_allocated < NR_DESCS_PER_CHANNEL) {
@@ -1227,6 +1215,7 @@ static void dwc_free_chan_resources(struct dma_chan *chan)
 	list_splice_init(&dwc->free_list, &list);
 	dwc->descs_allocated = 0;
 	dwc->initialized = false;
+	dwc->request_line = ~0;
 
 	/* Disable interrupts */
 	channel_clear_bit(dw, MASK.XFER, dwc->mask);
@@ -1254,23 +1243,15 @@ struct dw_dma_of_filter_args {
 static bool dw_dma_of_filter(struct dma_chan *chan, void *param)
 {
 	struct dw_dma_chan *dwc = to_dw_dma_chan(chan);
-	struct dw_dma *dw = to_dw_dma(chan->device);
 	struct dw_dma_of_filter_args *fargs = param;
-	struct dw_dma_slave *dws = &dwc->slave;
 
 	/* Ensure the device matches our channel */
         if (chan->device != &fargs->dw->dma)
                 return false;
 
-	dws->dma_dev	= dw->dma.dev;
-	dws->cfg_hi	= ~0;
-	dws->cfg_lo	= ~0;
-	dws->src_master	= fargs->src;
-	dws->dst_master	= fargs->dst;
-
 	dwc->request_line = fargs->req;
-
-	chan->private = dws;
+	dwc->src_master	= fargs->src;
+	dwc->dst_master	= fargs->dst;
 
 	return true;
 }
@@ -1784,6 +1765,7 @@ static int dw_probe(struct platform_device *pdev)
 		channel_clear_bit(dw, CH_EN, dwc->mask);
 
 		dwc->direction = DMA_TRANS_NONE;
+		dwc->request_line = ~0;
 
 		/* Hardware configuration */
 		if (autocfg) {
diff --git a/drivers/dma/dw_dmac_regs.h b/drivers/dma/dw_dmac_regs.h
index 4d02c36..9b0e12e 100644
--- a/drivers/dma/dw_dmac_regs.h
+++ b/drivers/dma/dw_dmac_regs.h
@@ -212,8 +212,11 @@ struct dw_dma_chan {
 	/* hardware configuration */
 	unsigned int		block_size;
 	bool			nollp;
+
+	/* custom slave configuration */
 	unsigned int		request_line;
-	struct dw_dma_slave	slave;
+	unsigned char		src_master;
+	unsigned char		dst_master;
 
 	/* configuration passed via DMA_SLAVE_CONFIG */
 	struct dma_slave_config dma_sconfig;
-- 
1.7.10.4



From will.deacon at arm.com  Wed Apr 24 05:42:51 2013
From: will.deacon at arm.com (Will Deacon)
Date: Wed, 24 Apr 2013 10:42:51 +0100
Subject: [PATCHv2] arm: Preserve TPIDRURW on context switch
In-Reply-To: <51770E4E.2040003@dawncrow.de>
References: <517168BB.3070903@dawncrow.de>
 <20130422143616.GP14496@n2100.arm.linux.org.uk>
 <20130422151836.GA15665@mudshark.cambridge.arm.com>
 <5175A697.3080308@dawncrow.de>
 <20130423091536.GB17593@mudshark.cambridge.arm.com>
 <51770E4E.2040003@dawncrow.de>
Message-ID: <20130424094251.GA21850@mudshark.cambridge.arm.com>

Hi Andrew,

On Tue, Apr 23, 2013 at 11:42:22PM +0100, Andr? Hentschel wrote:
> Am 23.04.2013 11:15, schrieb Will Deacon:
> > You could introduce `get' tls functions, which don't do anything for CPUs
> > without the relevant registers.
> 
> Before i have another round of testing and patch formatting/sending,
> what about the untested patch below?

Ok. Comments inline.

> diff --git a/arch/arm/include/asm/thread_info.h b/arch/arm/include/asm/thread_info.h
> index cddda1f..bb5b48d 100644
> --- a/arch/arm/include/asm/thread_info.h
> +++ b/arch/arm/include/asm/thread_info.h
> @@ -58,7 +58,7 @@ struct thread_info {
>  	struct cpu_context_save	cpu_context;	/* cpu context */
>  	__u32			syscall;	/* syscall number */
>  	__u8			used_cp[16];	/* thread used copro */
> -	unsigned long		tp_value;
> +	unsigned long		tp_value[2];
>  #ifdef CONFIG_CRUNCH
>  	struct crunch_state	crunchstate;
>  #endif
> diff --git a/arch/arm/include/asm/tls.h b/arch/arm/include/asm/tls.h
> index 73409e6..1c10163 100644
> --- a/arch/arm/include/asm/tls.h
> +++ b/arch/arm/include/asm/tls.h
> @@ -2,13 +2,30 @@
>  #define __ASMARM_TLS_H
>  
>  #ifdef __ASSEMBLY__
> +	.macro get_tls2_none, tp, tmp1
> +	.endm

Cosmetic, but these are really horrible macro names.

> +	.macro get_tls2_v6k, tp, tmp1
> +	mrc	p15, 0, \tmp1, c13, c0, 2		@ get user r/w TLS register
> +	str	\tmp1, [\tp, #4]
> +	.endm
> +
> +	.macro get_tls2_v6, tp, tmp1
> +	ldr	\tmp1, =elf_hwcap
> +	ldr	\tmp1, [\tmp1, #0]
> +	tst	\tmp1, #HWCAP_TLS		@ hardware TLS available?
> +	mrcne	p15, 0, \tmp1, c13, c0, 2		@ get user r/w TLS register
> +	strne	\tmp1, [\tp, #4]

You could factor out some of this hwcap checking now that it's used by both
set and get.

> +	.endm
> +
> +
>  	.macro set_tls_none, tp, tmp1, tmp2
>  	.endm
>  
>  	.macro set_tls_v6k, tp, tmp1, tmp2
> -	mcr	p15, 0, \tp, c13, c0, 3		@ set TLS register
> -	mov	\tmp1, #0
> -	mcr	p15, 0, \tmp1, c13, c0, 2	@ clear user r/w TLS register
> +	ldrd	\tmp1, \tmp2, [\tp]
> +	mcr	p15, 0, \tmp1, c13, c0, 3	@ set user r/o TLS register
> +	mcr	p15, 0, \tmp2, c13, c0, 2	@ set user r/w TLS register
>  	.endm
>  
>  	.macro set_tls_v6, tp, tmp1, tmp2
> @@ -16,33 +33,39 @@
>  	ldr	\tmp1, [\tmp1, #0]
>  	mov	\tmp2, #0xffff0fff
>  	tst	\tmp1, #HWCAP_TLS		@ hardware TLS available?
> -	mcrne	p15, 0, \tp, c13, c0, 3		@ yes, set TLS register
> -	movne	\tmp1, #0
> -	mcrne	p15, 0, \tmp1, c13, c0, 2	@ clear user r/w TLS register
> -	streq	\tp, [\tmp2, #-15]		@ set TLS value at 0xffff0ff0
> +	ldrdne	\tmp1, \tmp2, [\tp]

Does this work for big-endian CPUs?

> +	ldreq	\tmp1, [\tp]
> +	mcrne	p15, 0, \tmp1, c13, c0, 3	@ yes, set user r/o TLS register
> +	mcrne	p15, 0, \tmp2, c13, c0, 2	@ set user r/w TLS register
> +	streq	\tmp1, [\tmp2, #-15]		@ set TLS value at 0xffff0ff0
>  	.endm
>  
>  	.macro set_tls_software, tp, tmp1, tmp2
> -	mov	\tmp1, #0xffff0fff
> -	str	\tp, [\tmp1, #-15]		@ set TLS value at 0xffff0ff0
> +	ldr	\tmp1, [\tp]
> +	mov	\tmp2, #0xffff0fff
> +	str	\tmp1, [\tmp2, #-15]		@ set TLS value at 0xffff0ff0
>  	.endm
>  #endif
>  
>  #ifdef CONFIG_TLS_REG_EMUL
>  #define tls_emu		1
>  #define has_tls_reg		1
> +#define get_tls2		get_tls2_none
>  #define set_tls		set_tls_none
>  #elif defined(CONFIG_CPU_V6)
>  #define tls_emu		0
>  #define has_tls_reg		(elf_hwcap & HWCAP_TLS)
> +#define get_tls2		get_tls2_v6
>  #define set_tls		set_tls_v6
>  #elif defined(CONFIG_CPU_32v6K)
>  #define tls_emu		0
>  #define has_tls_reg		1
> +#define get_tls2		get_tls2_v6k
>  #define set_tls		set_tls_v6k
>  #else
>  #define tls_emu		0
>  #define has_tls_reg		0
> +#define get_tls2		get_tls2_none
>  #define set_tls		set_tls_software
>  #endif
>  
> diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
> index 0f82098..097686b 100644
> --- a/arch/arm/kernel/entry-armv.S
> +++ b/arch/arm/kernel/entry-armv.S
> @@ -728,7 +728,7 @@ ENTRY(__switch_to)
>   UNWIND(.fnstart	)
>   UNWIND(.cantunwind	)
>  	add	ip, r1, #TI_CPU_SAVE
> -	ldr	r3, [r2, #TI_TP_VALUE]
> +	add	r3, r1, #TI_TP_VALUE
>   ARM(	stmia	ip!, {r4 - sl, fp, sp, lr} )	@ Store most regs on stack
>   THUMB(	stmia	ip!, {r4 - sl, fp}	   )	@ Store most regs on stack
>   THUMB(	str	sp, [ip], #4		   )
> @@ -736,6 +736,8 @@ ENTRY(__switch_to)
>  #ifdef CONFIG_CPU_USE_DOMAINS
>  	ldr	r6, [r2, #TI_CPU_DOMAIN]
>  #endif
> +	get_tls2	r3, r4
> +	add	r3, r2, #TI_TP_VALUE
>  	set_tls	r3, r4, r5
>  #if defined(CONFIG_CC_STACKPROTECTOR) && !defined(CONFIG_SMP)
>  	ldr	r7, [r2, #TI_TASK]
> diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c
> index 047d3e4..6138eb1 100644
> --- a/arch/arm/kernel/process.c
> +++ b/arch/arm/kernel/process.c
> @@ -395,7 +395,8 @@ copy_thread(unsigned long clone_flags, unsigned long stack_start,
>  	clear_ptrace_hw_breakpoint(p);
>  
>  	if (clone_flags & CLONE_SETTLS)
> -		thread->tp_value = childregs->ARM_r3;
> +		thread->tp_value[0] = childregs->ARM_r3;
> +	thread->tp_value[1] = current_thread_info()->tp_value[1];
>

This still isn't correct. Imagine the following sequence of events:

  - Task foo writes its TPIDRURW register from userspace and then issues a
    fork() system call. No context switch occurs between these two events.

  - We start creating the child task, bar, and end up in copy_thread with
    the `thread' pointing at foo's struct thread_info, which contains the
    *old* TPIDRURW value.

  - We copy out the stale value into bar, which is then scheduled with an
    old TPIDRURW value.

The solution is to reload the value sitting in the register in copy_thread,
rather than relying on the thread_info being up-to-date. That's why I
previously suggested not using asm macros for the getters.

>  	thread_notify(THREAD_NOTIFY_COPY, thread);
>  
> diff --git a/arch/arm/kernel/ptrace.c b/arch/arm/kernel/ptrace.c
> index 03deeff..2bc1514 100644
> --- a/arch/arm/kernel/ptrace.c
> +++ b/arch/arm/kernel/ptrace.c
> @@ -849,7 +849,7 @@ long arch_ptrace(struct task_struct *child, long request,
>  #endif
>  
>  		case PTRACE_GET_THREAD_AREA:
> -			ret = put_user(task_thread_info(child)->tp_value,
> +			ret = put_user(task_thread_info(child)->tp_value[0],
>  				       datap);
>  			break;

I'm guessing debuggers don't care about the new TLS value, or do we need a
new ptrace request?

Will


From broonie at opensource.wolfsonmicro.com  Wed Apr 24 05:54:30 2013
From: broonie at opensource.wolfsonmicro.com (Mark Brown)
Date: Wed, 24 Apr 2013 10:54:30 +0100
Subject: [PATCH 13/23] regulator: ab3100: refactor probe to use IDs
In-Reply-To: <1366624634-6579-1-git-send-email-linus.walleij@stericsson.com>
References: <1366624634-6579-1-git-send-email-linus.walleij@stericsson.com>
Message-ID: <20130424095430.GA5019@opensource.wolfsonmicro.com>

On Mon, Apr 22, 2013 at 11:57:14AM +0200, Linus Walleij wrote:
> From: Linus Walleij <linus.walleij at linaro.org>
> 
> This refactors the AB3100 regulator probe to use regulator IDs
> and pass this to a separate registration function. This works
> much smoother when migrating to device tree, as we can use a
> match table with this regulator ID encoded in the .driver_data.

Applied, thanks.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130424/6d5c23cf/attachment-0001.sig>

From broonie at opensource.wolfsonmicro.com  Wed Apr 24 05:54:51 2013
From: broonie at opensource.wolfsonmicro.com (Mark Brown)
Date: Wed, 24 Apr 2013 10:54:51 +0100
Subject: [PATCH 14/23] regulator: ab3100: device tree support
In-Reply-To: <1366624645-6614-1-git-send-email-linus.walleij@stericsson.com>
References: <1366624645-6614-1-git-send-email-linus.walleij@stericsson.com>
Message-ID: <20130424095451.GB5019@opensource.wolfsonmicro.com>

On Mon, Apr 22, 2013 at 11:57:25AM +0200, Linus Walleij wrote:
> From: Linus Walleij <linus.walleij at linaro.org>
> 
> This implements device tree support for the AB3100 regulators
> driver. The initial settings are moved out of platform data

Applied, thanks.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130424/1a834bce/attachment.sig>

From will.deacon at arm.com  Wed Apr 24 05:55:01 2013
From: will.deacon at arm.com (Will Deacon)
Date: Wed, 24 Apr 2013 10:55:01 +0100
Subject: [PATCH] documentation: iommu: add description of ARM System MMU
 binding
In-Reply-To: <5177113D.7060300@codeaurora.org>
References: <1365094259-24847-1-git-send-email-will.deacon@arm.com>
 <515F37C1.4000109@codeaurora.org>
 <20130408092535.GA17476@mudshark.cambridge.arm.com>
 <5162F87A.7070409@codeaurora.org>
 <20130410173732.GQ26992@mudshark.cambridge.arm.com>
 <5169C7D1.8070300@codeaurora.org>
 <20130415131341.GG9827@mudshark.cambridge.arm.com>
 <516D9602.2010404@codeaurora.org>
 <20130418190131.GA12344@mudshark.cambridge.arm.com>
 <5177113D.7060300@codeaurora.org>
Message-ID: <20130424095501.GC21850@mudshark.cambridge.arm.com>

On Tue, Apr 23, 2013 at 11:54:53PM +0100, Olav Haugan wrote:
> Hi Will,

Hello again,

> On 4/18/2013 12:01 PM, Will Deacon wrote:
> > No. The device-tree describes the *hardware*, as per usual. The StreamIDs
> > are fixed properties of the SoC and we can't change them from Linux, so we
> > describe all of the StreamIDs upstream of each SMMU so that we can program
> > the thing. There's no way to generic way to discover them.
> 
> I meant that you are putting phandles to bus masters in the device tree
> that use/need the SMMU for VA2PA translation. Doesn't this put a
> dependency on the bus master devices? How will this work? Lets say that
> we have a device during bootup that needs to use the SMMU (such as a
> display processor [DP]). Don't you have cyclic dependency? The SMMU
> device needs the DP device (phandle) but the DP device needs the SMMU to
> initialize its device driver?

That's a problem you have with the driver model anyway. The SMMU must be
registered on the same bus as the device before it can be used and the
devices must be added to that bus before they can be attached to a domain.

Getting phandles has no dependencies on anything -- the only dependency is
that the device is added to the bus on which the SMMU sits, just like every
other IOMMU driver.

> > Why would a page table shared between devices require multiple context
> > banks? Multiple SMRs and S2CRs, sure, but they would ultimately point at the
> > same context bank (and hence same address space).
> 
> What if you want to have 2 different VMID's being generated? Also, what
> about TLB management? If I have two context banks I can invalidate only
> entries associated with 1 of the context banks (if VMID differ for the
> two context banks).

Huh? We allocate one VMID per domain. If you want more VMIDs, use more
domains. TLB invalidation is per-domain, so there's no issue there.

> > If a master needs to be in two address spaces at once, then it will need to
> > attach it's StreamIDs to different domains. You can't place a single
> > StreamID in two address spaces (this is an architectural constraint).
> 
> Yes, you would have a separate domain. I am just wondering how I would
> model this in DT using the bindings that you are proposing? How does it
> work? The bindings specify bus masters to StreamIDs. So if I call attach
> with the master device you will allocate a context bank and program the
> StreamIDs as specified in the DT. So now if I want to have another
> context bank associated with the same master device what do I do? I call
> into attach with a new domain but with the same master device but the
> master device is already attached to a context/domain.

Why would you want to place a StreamID into two domains? That doesn't make
any sense and isn't even supported by the architecture (things like
conflicting SMR entries may not even be reported).

Will


From broonie at kernel.org  Wed Apr 24 06:00:32 2013
From: broonie at kernel.org (Mark Brown)
Date: Wed, 24 Apr 2013 11:00:32 +0100
Subject: [PATCH v8 3/8] spi/spi-atmel: add dmaengine support
In-Reply-To: <1364968759-24036-1-git-send-email-wenyou.yang@atmel.com>
References: <1364968581-23700-1-git-send-email-wenyou.yang@atmel.com>
 <1364968759-24036-1-git-send-email-wenyou.yang@atmel.com>
Message-ID: <20130424100032.GC5019@opensource.wolfsonmicro.com>

On Wed, Apr 03, 2013 at 01:59:19PM +0800, Wenyou Yang wrote:
> From: Nicolas Ferre <nicolas.ferre at atmel.com>
> 
> Add dmaengine support.
> 
> Using "has_dma_support" member of struct is used to select
> the transfer mode: dmaengine or pdc.

Applied, thanks.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130424/0f961c57/attachment.sig>

From broonie at kernel.org  Wed Apr 24 06:01:18 2013
From: broonie at kernel.org (Mark Brown)
Date: Wed, 24 Apr 2013 11:01:18 +0100
Subject: [PATCH v8 4/8] spi/spi-atmel: BUG: fix doesn' support 16 bits
 transfers using PIO
In-Reply-To: <1364968805-24090-1-git-send-email-wenyou.yang@atmel.com>
References: <1364968581-23700-1-git-send-email-wenyou.yang@atmel.com>
 <1364968805-24090-1-git-send-email-wenyou.yang@atmel.com>
Message-ID: <20130424100118.GD5019@opensource.wolfsonmicro.com>

On Wed, Apr 03, 2013 at 02:00:05PM +0800, Wenyou Yang wrote:
> From: Richard Genoud <richard.genoud at gmail.com>
> 
> Fix using PIO transfer mode only support 8 bits transfer, doesn't support 16 bits.

This doesn't apply to my -next branch, please check and regenerate.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130424/fbe9789d/attachment.sig>

From broonie at kernel.org  Wed Apr 24 06:02:31 2013
From: broonie at kernel.org (Mark Brown)
Date: Wed, 24 Apr 2013 11:02:31 +0100
Subject: [PATCH v8 5/8] ARM: at91: add clocks for spi dt entries
In-Reply-To: <1364968882-24132-1-git-send-email-wenyou.yang@atmel.com>
References: <1364968581-23700-1-git-send-email-wenyou.yang@atmel.com>
 <1364968882-24132-1-git-send-email-wenyou.yang@atmel.com>
Message-ID: <20130424100231.GE5019@opensource.wolfsonmicro.com>

On Wed, Apr 03, 2013 at 02:01:22PM +0800, Wenyou Yang wrote:
> From: Richard Genoud <richard.genoud at gmail.com>

Applied, thanks.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130424/47e5189c/attachment.sig>

From broonie at kernel.org  Wed Apr 24 06:03:58 2013
From: broonie at kernel.org (Mark Brown)
Date: Wed, 24 Apr 2013 11:03:58 +0100
Subject: [PATCH v8 6/8] ARM: dts: add spi nodes for atmel SoC
In-Reply-To: <1364968938-24198-1-git-send-email-wenyou.yang@atmel.com>
References: <1364968581-23700-1-git-send-email-wenyou.yang@atmel.com>
 <1364968938-24198-1-git-send-email-wenyou.yang@atmel.com>
Message-ID: <20130424100358.GF5019@opensource.wolfsonmicro.com>

On Wed, Apr 03, 2013 at 02:02:18PM +0800, Wenyou Yang wrote:
> From: Richard Genoud <richard.genoud at gmail.com>
> 
> Signed-off-by: Richard Genoud <richard.genoud at gmail.com>

Applied, thanks.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130424/c731ec53/attachment.sig>

From marc.zyngier at arm.com  Wed Apr 24 06:04:06 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 24 Apr 2013 11:04:06 +0100
Subject: [PATCH v3 07/32] arm64: KVM: fault injection into a guest
In-Reply-To: <20130423225758.GB20569@gmail.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
 <1365437854-30214-8-git-send-email-marc.zyngier@arm.com>
 <20130423225758.GB20569@gmail.com>
Message-ID: <5177AE16.6080509@arm.com>

On 23/04/13 23:57, Christoffer Dall wrote:
> On Mon, Apr 08, 2013 at 05:17:09PM +0100, Marc Zyngier wrote:
>> Implement the injection of a fault (undefined, data abort or
>> prefetch abort) into a 64bit guest.
>>
>> Reviewed-by: Christopher Covington <cov at codeaurora.org>
>> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
>> ---
>>  arch/arm64/kvm/inject_fault.c | 118 ++++++++++++++++++++++++++++++++++++++++++
>>  1 file changed, 118 insertions(+)
>>  create mode 100644 arch/arm64/kvm/inject_fault.c
>>
>> diff --git a/arch/arm64/kvm/inject_fault.c b/arch/arm64/kvm/inject_fault.c
>> new file mode 100644
>> index 0000000..2ff3b78
>> --- /dev/null
>> +++ b/arch/arm64/kvm/inject_fault.c
>> @@ -0,0 +1,118 @@
>> +/*
>> + * Fault injection for 64bit guests.
>> + *
>> + * Copyright (C) 2012,2013 - ARM Ltd
>> + * Author: Marc Zyngier <marc.zyngier at arm.com>
>> + *
>> + * Based on arch/arm/kvm/emulate.c
>> + * Copyright (C) 2012 - Virtual Open Systems and Columbia University
>> + * Author: Christoffer Dall <c.dall at virtualopensystems.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.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
>> + */
>> +
>> +#include <linux/kvm_host.h>
>> +#include <asm/kvm_emulate.h>
>> +#include <asm/esr.h>
>> +
>> +static void inject_abt64(struct kvm_vcpu *vcpu, bool is_iabt, unsigned long addr)
>> +{
>> +	unsigned long cpsr = *vcpu_cpsr(vcpu);
>> +	int is_aarch32;
>> +	u32 esr = 0;
>> +
>> +	is_aarch32 = vcpu_mode_is_32bit(vcpu);
>> +
>> +	*vcpu_spsr(vcpu) = cpsr;
>> +	*vcpu_elr_el1(vcpu) = *vcpu_pc(vcpu);
>> +
>> +	*vcpu_cpsr(vcpu) = PSR_MODE_EL1h | PSR_A_BIT | PSR_F_BIT | PSR_I_BIT;
>> +	*vcpu_pc(vcpu) = vcpu_sys_reg(vcpu, VBAR_EL1) + 0x200;
> 
> consider a define for the 0x200?

Yeah, I think Will already mentioned this.

>> +
>> +	vcpu_sys_reg(vcpu, FAR_EL1) = addr;
>> +
>> +	/*
>> +	 * Build an {i,d}abort, depending on the level and the
>> +	 * instruction set. Report an external synchronous abort.
>> +	 */
>> +	if (kvm_vcpu_trap_il_is32bit(vcpu))
>> +		esr |= ESR_EL1_IL;
>> +
>> +	if (is_aarch32 || (cpsr & PSR_MODE_MASK) == PSR_MODE_EL0t)
>> +		esr |= (ESR_EL1_EC_IABT_EL0 << ESR_EL1_EC_SHIFT);
>> +	else
>> +		esr |= (ESR_EL1_EC_IABT_EL1 << ESR_EL1_EC_SHIFT);
> 
> why is it assumed that the abort must come from EL0 if the vcpu is in
> aarch32 mode?

We're injecting a fault into a VM that runs with a 64bit EL1. So if we
end-up faulting in 32bit code, it must come from EL0.

>> +
>> +	if (!is_iabt)
>> +		esr |= ESR_EL1_EC_DABT_EL0;
> 
> this is slightly confusing unless you actually look at the definitions
> and realize that or'ing on that extra bit works both in i- and d-abt
> cases.

Blame Christopher for that, he came up with the idea... ;-)

>> +
>> +	vcpu_sys_reg(vcpu, ESR_EL1) = esr | 0x10; /* External abort */
>> +}
>> +
>> +static void inject_undef64(struct kvm_vcpu *vcpu)
>> +{
>> +	unsigned long cpsr = *vcpu_cpsr(vcpu);
>> +	u32 esr = (ESR_EL1_EC_UNKNOWN << ESR_EL1_EC_SHIFT);
>> +
>> +	*vcpu_spsr(vcpu) = cpsr;
>> +	*vcpu_elr_el1(vcpu) = *vcpu_pc(vcpu);
>> +
>> +	*vcpu_cpsr(vcpu) = PSR_MODE_EL1h | PSR_F_BIT | PSR_I_BIT;
> 
> would it make sense to have a define for a common set of these bits or
> is this explicitly defined per exception type in the specs?

Maybe. Not sure that would be any clearer though...

	M.
-- 
Jazz is not dead. It just smells funny...



From broonie at kernel.org  Wed Apr 24 06:04:15 2013
From: broonie at kernel.org (Mark Brown)
Date: Wed, 24 Apr 2013 11:04:15 +0100
Subject: [PATCH v8 7/8] ARM: dts: add spi nodes for the atmel boards
In-Reply-To: <1364968986-24236-1-git-send-email-wenyou.yang@atmel.com>
References: <1364968581-23700-1-git-send-email-wenyou.yang@atmel.com>
 <1364968986-24236-1-git-send-email-wenyou.yang@atmel.com>
Message-ID: <20130424100415.GG5019@opensource.wolfsonmicro.com>

On Wed, Apr 03, 2013 at 02:03:05PM +0800, Wenyou Yang wrote:
> From: Richard Genoud <richard.genoud at gmail.com>

Applied, thanks.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130424/24b87419/attachment.sig>

From simon.guinot at sequanux.org  Wed Apr 24 06:04:59 2013
From: simon.guinot at sequanux.org (Simon Guinot)
Date: Wed, 24 Apr 2013 12:04:59 +0200
Subject: [PATCHv1 1/3] hwmon: Add support for GMT G762/G763 PWM fan
 controller
In-Reply-To: <87obd4wb4e.fsf@natisbad.org>
References: <cover.1366753420.git.arno@natisbad.org>
 <63961d39aee9db94767f28fd441312bec2029473.1366753420.git.arno@natisbad.org>
 <20130424053758.GC8710@lunn.ch> <87obd4wb4e.fsf@natisbad.org>
Message-ID: <20130424100458.GA17771@kw.sim.vm.gnt>

On Wed, Apr 24, 2013 at 11:06:57AM +0200, Arnaud Ebalard wrote:
> Hi Andrew,
> 
> Andrew Lunn <andrew at lunn.ch> writes:
> 
> >> +struct g762_data {
> >> +	struct i2c_client *client;
> >> +	struct device *hwmon_dev;
> >> +
> >> +	/* update mutex */
> >> +	struct mutex update_lock;
> >> +
> >> +	/* board specific parameters. */
> >> +	u32 clk; /* default 32kHz */
> >> +
> >> +	/* g762 register cache */
> >> +	bool valid;
> >> +	unsigned long last_updated; /* in jiffies */
> >> +
> >> +	u8 set_cnt;  /* RPM cmd in close loop control */
> >> +	u8 act_cnt;  /* formula: cnt = (CLK * 30)/(rpm * P) */
> >> +	u8 fan_sta;  /* bit 0: set when actual fan speed is more than
> >> +		      *        25% outside requested fan speed
> >> +		      * bit 1: set when no transition occurs on fan
> >> +		      *        pin for 0.7s
> >> +		      */
> >> +	u8 set_out;  /* output voltage/PWM duty in open loop control */
> >> +	u8 fan_cmd1; /*   0: FG_PLS_ID0 FG pulses count per revolution
> >> +		      *      0: 2 counts per revolution
> >> +		      *      1: 4 counts per revolution
> >> +		      *   1: PWM_POLARITY 1: negative_duty
> >> +		      *                   0: positive_duty
> >> +		      * 2,3: [FG_CLOCK_ID0, FG_CLK_ID1]
> >> +		      *         00: Divide fan clock by 1
> >> +		      *         01: Divide fan clock by 2
> >> +		      *         10: Divide fan clock by 4
> >> +		      *         11: Divide fan clock by 8
> >> +		      *   4: FAN_MODE 1:close-loop, 0:open-loop
> >> +		      *   5: OUT_MODE 1:PWM, 0:DAC
> >> +		      *   6: DET_FAN_OOC enable "fan ooc" status
> >> +		      *   7: DET_FAN_FAIL enable "fan fail" status
> >> +		      */
> >> +	u8 fan_cmd2; /* 0,1: FAN_STARTV 0,1,2,3 -> 0,32,64,96 dac_code
> >> +		      * 2,3: FG_GEAR_MODE
> >> +		      *         00: div = 1
> >> +		      *         01: div = 2
> >> +		      *         10: div = 4
> >> +		      *   4: Mask ALERT# (g763 only)
> >> +		      */
> >
> > You could consider using regmap for holding this cache.
> >
> > http://elceurope2012.sched.org/event/100619b669ce5767341624253aa03659?iframe=no&w=900&sidebar=yes&bg=no#.UXdspHLQ5jM
> >
> > http://elinux.org/ELCE_Europe_2012_Presentations
> 
> Interesting. As I am not yet familiar w/ regmap I would prefer having
> the driver accepted during merge window with current data structure and
> then convert it to regmap. But I will take a look (e.g. will study
> fca1dd03 for instance). Thanks for the pointers. 
> 
> >> +/*
> >> + * Helpers to import hardware characteristics from .dts file and overload
> >> + * default config values.
> >> + */
> >> +
> >> +#ifdef CONFIG_OF
> >
> > Can the driver be used without device tree? Would it be simpler to
> >  just add depends OF in the Kconfig entry?
> 
> It can be used if the default params (or those configured by u-boot I
> guess) fit your needs. I think it would be fairly easy to extend the
> driver later to expose g762_config struct to allow parameters to be set
> w/o using OF. If someone wants to do that, I think it is better to not
> depend on OF in Kconfig at the moment but I have not strong argument
> other that that one. I'll let you decide.

A g762 device is embedded on the 2Big Network v2 board (net2big_v2),
which is not DT compliant. Then, I think it could be nice to allow
device registration from board setup files.

Regards,

Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130424/4eb49d91/attachment.sig>

From broonie at kernel.org  Wed Apr 24 06:05:32 2013
From: broonie at kernel.org (Mark Brown)
Date: Wed, 24 Apr 2013 11:05:32 +0100
Subject: [PATCH v8 8/8] ARM: dts: add pinctrl property for spi node for
 atmel SoC
In-Reply-To: <1364969032-24281-1-git-send-email-wenyou.yang@atmel.com>
References: <1364968581-23700-1-git-send-email-wenyou.yang@atmel.com>
 <1364969032-24281-1-git-send-email-wenyou.yang@atmel.com>
Message-ID: <20130424100532.GH5019@opensource.wolfsonmicro.com>

On Wed, Apr 03, 2013 at 02:03:52PM +0800, Wenyou Yang wrote:
> Signed-off-by: Wenyou Yang <wenyou.yang at atmel.com>

Applied, thanks.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130424/ed415327/attachment.sig>

From horms at verge.net.au  Wed Apr 24 06:07:59 2013
From: horms at verge.net.au (Simon Horman)
Date: Wed, 24 Apr 2013 19:07:59 +0900
Subject: [PATCH v3 1/2] ARM: shmobile: r8a7740: Add Suspend-To-RAM A3SM
In-Reply-To: <CABYn4swtOdJG18833FLXifeuVsL4R5vUzGjAg5Fv8r==CT5HBw@mail.gmail.com>
References: <1366196190-14011-1-git-send-email-hechtb+renesas@gmail.com>
 <20130424074904.GG847@verge.net.au>
 <CABYn4swtOdJG18833FLXifeuVsL4R5vUzGjAg5Fv8r==CT5HBw@mail.gmail.com>
Message-ID: <20130424100759.GA19399@verge.net.au>

On Wed, Apr 24, 2013 at 11:36:33AM +0200, Bastian Hecht wrote:
> 2013/4/24 Simon Horman <horms at verge.net.au>:
> > On Wed, Apr 17, 2013 at 12:56:29PM +0200, Bastian Hecht wrote:
> >> We add 2 Suspend to RAM modes:
> >> - A3SM PLL0 on/off:     Power domain A3SM that contains the ARM core
> >>                         and the 2nd level cache with either PLL0 on
> >>                         or off
> >>
> >> As the suspend to memory mechanism we use A3SM PLL off. A3SM PLL on
> >> is included here too, so CPUIdle can use both power down modes (not
> >> included in this patch).
> >>
> >> The setup of the SYSC regarding the external IRQs is taken from
> >> pm-sh7372.c from Magnus Damm.
> >>
> >> Signed-off-by: Bastian Hecht <hechtb+renesas at gmail.com>
> >> ---
> >> v3:
> >>
> >> We now stubbornly loop until the SoC really shuts down when we issue
> >> the WFI command.
> >
> > Hi Bastian,
> >
> > could you let me know what the status of this series is.
> > Is it ready to be queued-up for v3.11?
> 
> Hello Simon!
> 
> I consider it stable and as there are no more comments, I would be
> happy if you queued it up.

Thanks, I will see about doing so tomorrow.


From broonie at opensource.wolfsonmicro.com  Wed Apr 24 06:21:13 2013
From: broonie at opensource.wolfsonmicro.com (Mark Brown)
Date: Wed, 24 Apr 2013 11:21:13 +0100
Subject: [PATCH 15/23] ARM: u300: set up board power from device tree
In-Reply-To: <1366624656-6648-1-git-send-email-linus.walleij@stericsson.com>
References: <1366624656-6648-1-git-send-email-linus.walleij@stericsson.com>
Message-ID: <20130424102113.GI5019@opensource.wolfsonmicro.com>

On Mon, Apr 22, 2013 at 11:57:36AM +0200, Linus Walleij wrote:

> Hi Mark, this was especially tricky due to the absence of a
> function to get a named regulator without a device node. After
> some cleverness introducing a node for the board akin to the
> solution I did for Nomadik, this seems to be an acceptable way
> forward, any other suggestions welcome.

I would expect this to be bound based on the board name that appears in
the device tree which (given the way this stuff mostly works) I'd expect
to have a device node available.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130424/3a4ae311/attachment.sig>

From gang.chen at asianux.com  Wed Apr 24 06:20:32 2013
From: gang.chen at asianux.com (Chen Gang)
Date: Wed, 24 Apr 2013 18:20:32 +0800
Subject: [PATCH v2] arm64: compiling issue, need add include/asm/vga.h file
In-Reply-To: <20130424082237.GA23397@arm.com>
References: <5177551D.8090007@asianux.com> <20130424082237.GA23397@arm.com>
Message-ID: <5177B1F0.10106@asianux.com>


For compiling with allmodconfig, need vga.h file, so generate it which
just only include the asm-generic one.

It is firstly used by drivers/gpu/drm/drm_irq.c.

The related error:
include/video/vga.h:22:21: fatal error: asm/vga.h: No such file or directory

Signed-off-by: Chen Gang <gang.chen at asianux.com>
---
 arch/arm64/include/asm/vga.h |   21 +++++++++++++++++++++
 1 files changed, 21 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm64/include/asm/vga.h

diff --git a/arch/arm64/include/asm/vga.h b/arch/arm64/include/asm/vga.h
new file mode 100644
index 0000000..1c49d51
--- /dev/null
+++ b/arch/arm64/include/asm/vga.h
@@ -0,0 +1,21 @@
+/*
+ * Copyright (C) 2012 ARM Ltd.
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
+ */
+#ifndef ASMARM_VGA_H
+#define ASMARM_VGA_H
+
+#include <asm-generic/vga.h>
+
+#endif /* ASMARM_VGA_H */
-- 
1.7.7.6


From will.deacon at arm.com  Wed Apr 24 06:23:27 2013
From: will.deacon at arm.com (Will Deacon)
Date: Wed, 24 Apr 2013 11:23:27 +0100
Subject: [PATCH v2] arm64: compiling issue, need add include/asm/vga.h file
In-Reply-To: <5177B1F0.10106@asianux.com>
References: <5177551D.8090007@asianux.com> <20130424082237.GA23397@arm.com>
 <5177B1F0.10106@asianux.com>
Message-ID: <20130424102327.GF21850@mudshark.cambridge.arm.com>

On Wed, Apr 24, 2013 at 11:20:32AM +0100, Chen Gang wrote:
> 
> For compiling with allmodconfig, need vga.h file, so generate it which
> just only include the asm-generic one.
> 
> It is firstly used by drivers/gpu/drm/drm_irq.c.
> 
> The related error:
> include/video/vga.h:22:21: fatal error: asm/vga.h: No such file or directory
> 
> Signed-off-by: Chen Gang <gang.chen at asianux.com>
> ---
>  arch/arm64/include/asm/vga.h |   21 +++++++++++++++++++++
>  1 files changed, 21 insertions(+), 0 deletions(-)
>  create mode 100644 arch/arm64/include/asm/vga.h
> 
> diff --git a/arch/arm64/include/asm/vga.h b/arch/arm64/include/asm/vga.h
> new file mode 100644
> index 0000000..1c49d51
> --- /dev/null
> +++ b/arch/arm64/include/asm/vga.h
> @@ -0,0 +1,21 @@
> +/*
> + * Copyright (C) 2012 ARM Ltd.
> + *
> + * 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.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
> + */
> +#ifndef ASMARM_VGA_H
> +#define ASMARM_VGA_H
> +
> +#include <asm-generic/vga.h>
> +
> +#endif /* ASMARM_VGA_H */

Can't you just add this as a generic-y entry in asm/Kbuild?

Will


From francescolavra.fl at gmail.com  Wed Apr 24 06:30:49 2013
From: francescolavra.fl at gmail.com (Francesco Lavra)
Date: Wed, 24 Apr 2013 12:30:49 +0200
Subject: [Linaro-mm-sig] [RFC/PATCH v2 2/2] drivers: dma-contiguous: add
 initialization from device tree
In-Reply-To: <1365679330-2514-3-git-send-email-m.szyprowski@samsung.com>
References: <1365679330-2514-1-git-send-email-m.szyprowski@samsung.com>
 <1365679330-2514-3-git-send-email-m.szyprowski@samsung.com>
Message-ID: <5177B459.1080009@gmail.com>

On 04/11/2013 01:22 PM, Marek Szyprowski wrote:
> diff --git a/drivers/base/dma-contiguous.c b/drivers/base/dma-contiguous.c
> index 01fe743..6a8abab 100644
> --- a/drivers/base/dma-contiguous.c
> +++ b/drivers/base/dma-contiguous.c
[...]
> +void scan_cma_nodes(void)

Should be declared static.

> +{
> +	struct device_node *parent = of_find_node_by_path("/chosen/contiguous-memory");
> +	struct device_node *child;
> +
> +	if (!parent)
> +		return;
> +
> +	for_each_child_of_node(parent, child) {
> +		struct cma *cma = NULL;
> +		int i;
> +
> +		for (i=0; i<cma_area_count; i++)
> +			if (strstr(child->full_name, cma_areas[i].full_name))
> +				cma = &cma_areas[i];
> +		if (!cma)
> +			continue;
> +
> +		for (i=0;; i++) {
> +			struct device_node *node;
> +			node = of_parse_phandle(child, "device", i);
> +			if (!node)
> +				break;
> +
> +			cma_maps[cma_map_count].cma = cma;
> +			cma_maps[cma_map_count].node = node;
> +			cma_map_count++;
> +		}

of_parse_phandle() requires of_node_put() to be called when done with
the device node.
Also, of_node_put() should be called on the parent node as well.

> +	}
> +}

--
Francesco


From catalin.marinas at arm.com  Wed Apr 24 06:42:31 2013
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Wed, 24 Apr 2013 11:42:31 +0100
Subject: [PATCH v2] arm64: compiling issue, need add include/asm/vga.h file
In-Reply-To: <5177B1F0.10106@asianux.com>
References: <5177551D.8090007@asianux.com> <20130424082237.GA23397@arm.com>
 <5177B1F0.10106@asianux.com>
Message-ID: <20130424104231.GJ23397@arm.com>

On Wed, Apr 24, 2013 at 11:20:32AM +0100, Chen Gang wrote:
> For compiling with allmodconfig, need vga.h file, so generate it which
> just only include the asm-generic one.
> 
> It is firstly used by drivers/gpu/drm/drm_irq.c.
> 
> The related error:
> include/video/vga.h:22:21: fatal error: asm/vga.h: No such file or directory
> 
> Signed-off-by: Chen Gang <gang.chen at asianux.com>
> ---
>  arch/arm64/include/asm/vga.h |   21 +++++++++++++++++++++
>  1 files changed, 21 insertions(+), 0 deletions(-)
>  create mode 100644 arch/arm64/include/asm/vga.h

As Will said, please use asm/Kbuild.

> diff --git a/arch/arm64/include/asm/vga.h b/arch/arm64/include/asm/vga.h
> new file mode 100644
> index 0000000..1c49d51
> --- /dev/null
> +++ b/arch/arm64/include/asm/vga.h
> @@ -0,0 +1,21 @@
> +/*
> + * Copyright (C) 2012 ARM Ltd.

ARM copyright? You either work for ARM or there is a copyright
assignment between you and ARM ;)

-- 
Catalin


From arno at natisbad.org  Wed Apr 24 06:50:12 2013
From: arno at natisbad.org (Arnaud Ebalard)
Date: Wed, 24 Apr 2013 12:50:12 +0200
Subject: [PATCHv1 1/3] hwmon: Add support for GMT G762/G763 PWM fan
 controller
In-Reply-To: <20130424100458.GA17771@kw.sim.vm.gnt> (Simon Guinot's message of
 "Wed, 24 Apr 2013 12:04:59 +0200")
References: <cover.1366753420.git.arno@natisbad.org>
 <63961d39aee9db94767f28fd441312bec2029473.1366753420.git.arno@natisbad.org>
 <20130424053758.GC8710@lunn.ch> <87obd4wb4e.fsf@natisbad.org>
 <20130424100458.GA17771@kw.sim.vm.gnt>
Message-ID: <87ehe06w4b.fsf@natisbad.org>

Hi Simon,

Simon Guinot <simon.guinot at sequanux.org> writes:

>> It can be used if the default params (or those configured by u-boot I
>> guess) fit your needs. I think it would be fairly easy to extend the
>> driver later to expose g762_config struct to allow parameters to be set
>> w/o using OF. If someone wants to do that, I think it is better to not
>> depend on OF in Kconfig at the moment but I have not strong argument
>> other that that one. I'll let you decide.
>
> A g762 device is embedded on the 2Big Network v2 board (net2big_v2),
> which is not DT compliant. Then, I think it could be nice to allow
> device registration from board setup files.

ok, I will try and provide that for v2 then. :-)

Cheers,

a+


From gang.chen at asianux.com  Wed Apr 24 06:50:01 2013
From: gang.chen at asianux.com (Chen Gang)
Date: Wed, 24 Apr 2013 18:50:01 +0800
Subject: [PATCH v2] arm64: compiling issue, need add include/asm/vga.h file
In-Reply-To: <20130424102327.GF21850@mudshark.cambridge.arm.com>
References: <5177551D.8090007@asianux.com> <20130424082237.GA23397@arm.com>
 <5177B1F0.10106@asianux.com>
 <20130424102327.GF21850@mudshark.cambridge.arm.com>
Message-ID: <5177B8D9.3030607@asianux.com>

On 2013?04?24? 18:23, Will Deacon wrote:
> On Wed, Apr 24, 2013 at 11:20:32AM +0100, Chen Gang wrote:
>> > 
>> > For compiling with allmodconfig, need vga.h file, so generate it which
>> > just only include the asm-generic one.
>> > 
>> > It is firstly used by drivers/gpu/drm/drm_irq.c.
>> > 
>> > The related error:
>> > include/video/vga.h:22:21: fatal error: asm/vga.h: No such file or directory
>> > 
>> > Signed-off-by: Chen Gang <gang.chen at asianux.com>
>> > ---
>> >  arch/arm64/include/asm/vga.h |   21 +++++++++++++++++++++
>> >  1 files changed, 21 insertions(+), 0 deletions(-)
>> >  create mode 100644 arch/arm64/include/asm/vga.h
>> > 
>> > diff --git a/arch/arm64/include/asm/vga.h b/arch/arm64/include/asm/vga.h
>> > new file mode 100644
>> > index 0000000..1c49d51
>> > --- /dev/null
>> > +++ b/arch/arm64/include/asm/vga.h
>> > @@ -0,0 +1,21 @@
>> > +/*
>> > + * Copyright (C) 2012 ARM Ltd.
>> > + *
>> > + * 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.
>> > + *
>> > + * This program is distributed in the hope that it will be useful,
>> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> > + * GNU General Public License for more details.
>> > + *
>> > + * You should have received a copy of the GNU General Public License
>> > + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
>> > + */
>> > +#ifndef ASMARM_VGA_H
>> > +#define ASMARM_VGA_H
>> > +
>> > +#include <asm-generic/vga.h>
>> > +
>> > +#endif /* ASMARM_VGA_H */
> Can't you just add this as a generic-y entry in asm/Kbuild?

OK, thanks, I need send patch v3.

-- 
Chen Gang

Asianux Corporation


From gang.chen at asianux.com  Wed Apr 24 06:51:22 2013
From: gang.chen at asianux.com (Chen Gang)
Date: Wed, 24 Apr 2013 18:51:22 +0800
Subject: [PATCH v2] arm64: compiling issue, need add include/asm/vga.h file
In-Reply-To: <20130424104231.GJ23397@arm.com>
References: <5177551D.8090007@asianux.com> <20130424082237.GA23397@arm.com>
 <5177B1F0.10106@asianux.com> <20130424104231.GJ23397@arm.com>
Message-ID: <5177B92A.5030004@asianux.com>

On 2013?04?24? 18:42, Catalin Marinas wrote:
> On Wed, Apr 24, 2013 at 11:20:32AM +0100, Chen Gang wrote:
>> For compiling with allmodconfig, need vga.h file, so generate it which
>> just only include the asm-generic one.
>>
>> It is firstly used by drivers/gpu/drm/drm_irq.c.
>>
>> The related error:
>> include/video/vga.h:22:21: fatal error: asm/vga.h: No such file or directory
>>
>> Signed-off-by: Chen Gang <gang.chen at asianux.com>
>> ---
>>  arch/arm64/include/asm/vga.h |   21 +++++++++++++++++++++
>>  1 files changed, 21 insertions(+), 0 deletions(-)
>>  create mode 100644 arch/arm64/include/asm/vga.h
> 
> As Will said, please use asm/Kbuild.
> 

OK, I will send.

>> diff --git a/arch/arm64/include/asm/vga.h b/arch/arm64/include/asm/vga.h
>> new file mode 100644
>> index 0000000..1c49d51
>> --- /dev/null
>> +++ b/arch/arm64/include/asm/vga.h
>> @@ -0,0 +1,21 @@
>> +/*
>> + * Copyright (C) 2012 ARM Ltd.
> 
> ARM copyright? You either work for ARM or there is a copyright
> assignment between you and ARM ;)
> 

:-)

-- 
Chen Gang

Asianux Corporation


From lee.jones at linaro.org  Wed Apr 24 06:58:42 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Wed, 24 Apr 2013 11:58:42 +0100
Subject: [PATCH] mmc: mmci: Allow MMCI to request channels with information
 acquired from DT
Message-ID: <1366801122-13302-1-git-send-email-lee.jones@linaro.org>

Currently, if DMA information isn't passed from platform data, then DMA
will not be used. This patch allows DMA information obtained though Device
Tree to be used as well.

Cc: Russell King <linux at arm.linux.org.uk>
Cc: Chris Ball <cjb at laptop.org>
Cc: linux-mmc at vger.kernel.org
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 drivers/mmc/host/mmci.c |   43 ++++++++++++++++++++++---------------------
 1 file changed, 22 insertions(+), 21 deletions(-)

diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index 372e921..ecd256b 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -304,10 +304,8 @@ static void mmci_dma_setup(struct mmci_host *host)
 	const char *rxname, *txname;
 	dma_cap_mask_t mask;
 
-	if (!plat || !plat->dma_filter) {
-		dev_info(mmc_dev(host->mmc), "no DMA platform data\n");
-		return;
-	}
+	host->dma_rx_channel = dma_request_slave_channel(dev, "rx");
+	host->dma_tx_channel = dma_request_slave_channel(dev, "tx");
 
 	/* initialize pre request cookie */
 	host->next_data.cookie = 1;
@@ -316,30 +314,33 @@ static void mmci_dma_setup(struct mmci_host *host)
 	dma_cap_zero(mask);
 	dma_cap_set(DMA_SLAVE, mask);
 
-	/*
-	 * If only an RX channel is specified, the driver will
-	 * attempt to use it bidirectionally, however if it is
-	 * is specified but cannot be located, DMA will be disabled.
-	 */
-	if (plat->dma_rx_param) {
-		host->dma_rx_channel = dma_request_channel(mask,
+	if (plat && plat->dma_filter) {
+		if (!host->dma_rx_channel && plat->dma_rx_param) {
+			host->dma_rx_channel = dma_request_channel(mask,
 							   plat->dma_filter,
 							   plat->dma_rx_param);
-		/* E.g if no DMA hardware is present */
-		if (!host->dma_rx_channel)
-			dev_err(mmc_dev(host->mmc), "no RX DMA channel\n");
-	}
+			/* E.g if no DMA hardware is present */
+			if (!host->dma_rx_channel)
+				dev_err(mmc_dev(host->mmc), "no RX DMA channel\n");
+		}
 
-	if (plat->dma_tx_param) {
-		host->dma_tx_channel = dma_request_channel(mask,
+		if (!host->dma_tx_channel && plat->dma_tx_param) {
+			host->dma_tx_channel = dma_request_channel(mask,
 							   plat->dma_filter,
 							   plat->dma_tx_param);
-		if (!host->dma_tx_channel)
-			dev_warn(mmc_dev(host->mmc), "no TX DMA channel\n");
-	} else {
-		host->dma_tx_channel = host->dma_rx_channel;
+			if (!host->dma_tx_channel)
+				dev_warn(mmc_dev(host->mmc), "no TX DMA channel\n");
+		}
 	}
 
+	/*
+	 * If only an RX channel is specified, the driver will
+	 * attempt to use it bidirectionally, however if it is
+	 * is specified but cannot be located, DMA will be disabled.
+	 */
+	if (host->dma_rx_channel && !host->dma_tx_channel)
+		host->dma_tx_channel = host->dma_rx_channel;
+
 	if (host->dma_rx_channel)
 		rxname = dma_chan_name(host->dma_rx_channel);
 	else
-- 
1.7.10.4



From gang.chen at asianux.com  Wed Apr 24 06:58:24 2013
From: gang.chen at asianux.com (Chen Gang)
Date: Wed, 24 Apr 2013 18:58:24 +0800
Subject: [PATCH v3] arm64: compiling issue, need add include/asm/vga.h file
In-Reply-To: <20130424102327.GF21850@mudshark.cambridge.arm.com>
References: <5177551D.8090007@asianux.com> <20130424082237.GA23397@arm.com>
 <5177B1F0.10106@asianux.com>
 <20130424102327.GF21850@mudshark.cambridge.arm.com>
Message-ID: <5177BAD0.9000500@asianux.com>


For compiling with allmodconfig, need vga.h file, so generate it which
just only include the asm-generic one.

It is firstly used by drivers/gpu/drm/drm_irq.c.

The related error:
include/video/vga.h:22:21: fatal error: asm/vga.h: No such file or directory


Signed-off-by: Chen Gang <gang.chen at asianux.com>
---
 arch/arm64/include/asm/Kbuild |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/arm64/include/asm/Kbuild b/arch/arm64/include/asm/Kbuild
index a13a4a4..79a642d 100644
--- a/arch/arm64/include/asm/Kbuild
+++ b/arch/arm64/include/asm/Kbuild
@@ -48,4 +48,5 @@ generic-y += trace_clock.h
 generic-y += types.h
 generic-y += unaligned.h
 generic-y += user.h
+generic-y += vga.h
 generic-y += xor.h
-- 
1.7.7.6


From Ian.Campbell at citrix.com  Wed Apr 24 06:48:45 2013
From: Ian.Campbell at citrix.com (Ian Campbell)
Date: Wed, 24 Apr 2013 11:48:45 +0100
Subject: [RFC] device-tree.git automatic sync from linux.git
Message-ID: <1366800525.20256.266.camel@zakaz.uk.xensource.com>

Hi,

First off apologies for the large CC list -- I think this catches the
arch list for all the arches with device tree source in the tree.

Various folks have expressed an interest in eventually splitting the
device tree bindings out of the Linux git repository into a separate
tree. This should help reduce the cross talk between the code and the
bindings and to make it difficult to accidentally "co-evolve" the
bindings and the code (i.e. break compatibility) etc. There are also
other projects (such as Xen) which would also like to use device-tree as
an OS agnostic description of the hardware.

I was talking to Grant about this at this Spring's LinaroConnect in Hong
Kong and as a first step he was interested in a device-tree.git
repository which is automatically kept insync with the main Linux tree.
Somehow I found myself volunteering to set up that tree.

An RFC repository can be found at:
        http://xenbits.xen.org/gitweb/?p=people/ianc/device-tree-rebasing.git

This is created using git filter-branch and retains the full history for
the device tree source files up to v3.9-rc8.

The master branch contains everything including the required build
infrastructure while upstream/master and upstream/dts contain the most
recently converted upstream master branch and the pristine converted
version respectively. Each upstream tag T is paired with a tag T-dts
which is the converted version of that tag.

Note that the tree will be potentially rebasing (hence the name) for the
time being while I'm still smoothing out the conversion process.

The paths to include in the conversion are described in
scripts/rewrite-paths.sed. The generic cases are:
        arch/ARCH/boot/dts/*.dts and *.dts? (for dtsi and dtsp etc)
	arch/ARCH/boot/*.dts and *.dts?
        arch/ARCH/include/dts/* (currently unused?)
which become src/ARCH/*.dts and *.dts? plus src/ARCH/include/*

There are also some special cases for some arches which don't follow
this pattern and for older versions of the kernel which were less
consistent. The paths were gleaned from git ls-tree + grep on every tag
in the tree, so if a file was added and moved between two rcs then the
original path may not be covered (so the move will look like it just
adds the files).

In principal this supports the new .dtsp files and includes the required
include paths in the conversion but none of them seem to be in mainline
yet, so we'll have to see!

The initial conversion took in excess of 40 hours (running out of a
ramdisk) so even if the result is stable in terms of commit ids etc a
fresh conversion every time isn't an option for a ~daily sync so I had
to create a slightly hacked around git-filter-branch (found in
scripts/git-filter-branch) to support incremental filtering, which I
intend to send to the git folks soon. 

Please let me know what you think.

Ian.

[0] real    2533m32.142s
    user    2393m35.039s
    sys     343m44.385s




From marc.zyngier at arm.com  Wed Apr 24 07:03:10 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 24 Apr 2013 12:03:10 +0100
Subject: [PATCH v3 08/32] arm64: KVM: architecture specific MMU backend
In-Reply-To: <20130423225816.GC20569@gmail.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
 <1365437854-30214-9-git-send-email-marc.zyngier@arm.com>
 <20130423225816.GC20569@gmail.com>
Message-ID: <5177BBEE.1090209@arm.com>

On 23/04/13 23:58, Christoffer Dall wrote:
> On Mon, Apr 08, 2013 at 05:17:10PM +0100, Marc Zyngier wrote:
>> Define the arm64 specific MMU backend:
>> - HYP/kernel VA offset
>> - S2 4/64kB definitions
>> - S2 page table populating and flushing
>> - icache cleaning
>>
>> Reviewed-by: Christopher Covington <cov at codeaurora.org>
>> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
>> ---
>>  arch/arm64/include/asm/kvm_mmu.h | 136 +++++++++++++++++++++++++++++++++++++++
>>  1 file changed, 136 insertions(+)
>>  create mode 100644 arch/arm64/include/asm/kvm_mmu.h
>>
>> diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h
>> new file mode 100644
>> index 0000000..2eb2230
>> --- /dev/null
>> +++ b/arch/arm64/include/asm/kvm_mmu.h
>> @@ -0,0 +1,136 @@
>> +/*
>> + * Copyright (C) 2012,2013 - ARM Ltd
>> + * Author: Marc Zyngier <marc.zyngier at arm.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.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
>> + */
>> +
>> +#ifndef __ARM64_KVM_MMU_H__
>> +#define __ARM64_KVM_MMU_H__
>> +
>> +#include <asm/page.h>
>> +#include <asm/memory.h>
>> +
>> +/*
>> + * As we only have the TTBR0_EL2 register, we cannot express
>> + * "negative" addresses. This makes it impossible to directly share
>> + * mappings with the kernel.
>> + *
>> + * Instead, give the HYP mode its own VA region at a fixed offset from
>> + * the kernel by just masking the top bits (which are all ones for a
>> + * kernel address).
> 
> For some reason I keep choking on this, despite it being very simple.
> We're just defining a different PAGE_OFFSET, right? Why not do a hard
> define as:
> 
> #define HYP_PAGE_OFFSET_MASK	0x0000ffffffffffff
> #define HYP_PAGE_OFFSET		0x0000ffc000000000
> 
> ...or change the second paragraph of the comment to say
> that we definethe HYP_PAGE_OFFSET to be 0x 0000ffc0 00000000.

One of these days, VA_BITS will change to accommodate for more virtual
space. When that day comes, I don't want to touch any of this because it
did hurt enough when writing it. As such, I'll refrain from hardcoding
anything.

I don't mind a comment, though.

>> + */
>> +#define HYP_PAGE_OFFSET_SHIFT	VA_BITS
>> +#define HYP_PAGE_OFFSET_MASK	((UL(1) << HYP_PAGE_OFFSET_SHIFT) - 1)
> 
> In any case, is there a reason for the HYP_PAGE_OFFSET_SHIFT
> indirection? It may be simpler without...

It is common practice to have XXX_SHIFT and XXX_MASK together.

>> +#define HYP_PAGE_OFFSET		(PAGE_OFFSET & HYP_PAGE_OFFSET_MASK)
>> +
>> +/*
>> + * Our virtual mapping for the idmap-ed MMU-enable code. Must be
>> + * shared across all the page-tables. Conveniently, we use the last
>> + * possible page, where no kernel mapping will ever exist.
>> + */
>> +#define TRAMPOLINE_VA		(HYP_PAGE_OFFSET_MASK & PAGE_MASK)
> 
> hmmm, ok, here it's kind of nice to have that define correlation, so
> maybe it's not cleaner.  Something should be improved here in the define
> or the comment to make it more clear.  Perhaps just adding the real
> constants in the comment or in Documentation/arm64/memory.txt would
> help.

Yes, I plan to write something there.

>> +
>> +#ifdef __ASSEMBLY__
>> +
>> +/*
>> + * Convert a kernel VA into a HYP VA.
>> + * reg: VA to be converted.
>> + */
>> +.macro kern_hyp_va	reg
>> +	and	\reg, \reg, #HYP_PAGE_OFFSET_MASK
>> +.endm
>> +
>> +#else
>> +
>> +#include <asm/cacheflush.h>
>> +
>> +#define KERN_TO_HYP(kva)	((unsigned long)kva - PAGE_OFFSET + HYP_PAGE_OFFSET)
>> +
>> +/*
>> + * Align KVM with the kernel's view of physical memory. Should be
>> + * 40bit IPA, with PGD being 8kB aligned.
>> + */
>> +#define KVM_PHYS_SHIFT	PHYS_MASK_SHIFT
>> +#define KVM_PHYS_SIZE	(1UL << KVM_PHYS_SHIFT)
>> +#define KVM_PHYS_MASK	(KVM_PHYS_SIZE - 1UL)
>> +
>> +#ifdef CONFIG_ARM64_64K_PAGES
>> +#define PAGE_LEVELS	2
>> +#define BITS_PER_LEVEL	13
>> +#else  /* 4kB pages */
>> +#define PAGE_LEVELS	3
>> +#define BITS_PER_LEVEL	9
>> +#endif
> 
> What are the semantics of these defines exactly? They should be
> S2_PAGE_LEVELS and make some assumptions of the VTCR_EL2.SL0 field
> right?

Indeed, we assume SL0 is always 1, just like for the kernel. As for the
semantics, I though they were pretty obvious...

PAGE_LEVELS is just that, the number of page levels. BITS_PER_LEVEL is
the number of bits you need to index a particular level.

>> +
>> +/* Make sure we get the right size, and thus the right alignment */
> 
> this comment is not particularly helpful, something explaining why the
> max() thingy below makes sense would be more so :)  I really can't
> follow the BITS_PER_S2_PGD and PTRS_PER_S2_PGD defines.

Admittedly, they are a bit convoluted:

>> +#define BITS_PER_S2_PGD (KVM_PHYS_SHIFT - (PAGE_LEVELS - 1) * BITS_PER_LEVEL - PAGE_SHIFT)

This is how many bits of index you need in a PGD. With a 40bit IPA and a
4kB page size, you end up with a 10 bit index.

>> +#define PTRS_PER_S2_PGD (1 << max(BITS_PER_LEVEL, BITS_PER_S2_PGD))

Now, in order to allocate your PGD, you need to find out how many
pointers your PGD is going to contain. The max() is make sure we
allocate at least a full page worth of pointers.

>> +#define S2_PGD_ORDER	get_order(PTRS_PER_S2_PGD * sizeof(pgd_t))
>> +#define S2_PGD_SIZE	(1 << S2_PGD_ORDER)
>> +
>> +int create_hyp_mappings(void *from, void *to);
>> +int create_hyp_io_mappings(void *from, void *to, phys_addr_t);
>> +void free_hyp_pgds(void);
>> +
>> +int kvm_alloc_stage2_pgd(struct kvm *kvm);
>> +void kvm_free_stage2_pgd(struct kvm *kvm);
>> +int kvm_phys_addr_ioremap(struct kvm *kvm, phys_addr_t guest_ipa,
>> +			  phys_addr_t pa, unsigned long size);
>> +
>> +int kvm_handle_guest_abort(struct kvm_vcpu *vcpu, struct kvm_run *run);
>> +
>> +void kvm_mmu_free_memory_caches(struct kvm_vcpu *vcpu);
>> +
>> +phys_addr_t kvm_mmu_get_httbr(void);
>> +phys_addr_t kvm_mmu_get_boot_httbr(void);
>> +phys_addr_t kvm_get_idmap_vector(void);
>> +int kvm_mmu_init(void);
>> +void kvm_clear_hyp_idmap(void);
>> +
>> +#define	kvm_set_pte(ptep, pte)		set_pte(ptep, pte)
> 
> I noticed that this doesn't do any cache cleaning.  Are the MMU page
> table walks guaranteed to be coherent with the MMU on arm64?

I suppose you meant the cache. In this case, yes. The hardware page
table walker must snoop the caches.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...



From catalin.marinas at arm.com  Wed Apr 24 07:05:12 2013
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Wed, 24 Apr 2013 12:05:12 +0100
Subject: [PATCH v3] arm64: compiling issue, need add include/asm/vga.h file
In-Reply-To: <5177BAD0.9000500@asianux.com>
References: <5177551D.8090007@asianux.com> <20130424082237.GA23397@arm.com>
 <5177B1F0.10106@asianux.com>
 <20130424102327.GF21850@mudshark.cambridge.arm.com>
 <5177BAD0.9000500@asianux.com>
Message-ID: <20130424110511.GK23397@arm.com>

On Wed, Apr 24, 2013 at 11:58:24AM +0100, Chen Gang wrote:
> 
> For compiling with allmodconfig, need vga.h file, so generate it which
> just only include the asm-generic one.
> 
> It is firstly used by drivers/gpu/drm/drm_irq.c.
> 
> The related error:
> include/video/vga.h:22:21: fatal error: asm/vga.h: No such file or directory
> 
> 
> Signed-off-by: Chen Gang <gang.chen at asianux.com>

Looks fine. Thanks.

-- 
Catalin


From gang.chen at asianux.com  Wed Apr 24 07:06:03 2013
From: gang.chen at asianux.com (Chen Gang)
Date: Wed, 24 Apr 2013 19:06:03 +0800
Subject: [PATCH v3] arm64: compiling issue, need add include/asm/vga.h file
In-Reply-To: <20130424110511.GK23397@arm.com>
References: <5177551D.8090007@asianux.com> <20130424082237.GA23397@arm.com>
 <5177B1F0.10106@asianux.com>
 <20130424102327.GF21850@mudshark.cambridge.arm.com>
 <5177BAD0.9000500@asianux.com> <20130424110511.GK23397@arm.com>
Message-ID: <5177BC9B.1060103@asianux.com>

On 2013?04?24? 19:05, Catalin Marinas wrote:
> On Wed, Apr 24, 2013 at 11:58:24AM +0100, Chen Gang wrote:
>> > 
>> > For compiling with allmodconfig, need vga.h file, so generate it which
>> > just only include the asm-generic one.
>> > 
>> > It is firstly used by drivers/gpu/drm/drm_irq.c.
>> > 
>> > The related error:
>> > include/video/vga.h:22:21: fatal error: asm/vga.h: No such file or directory
>> > 
>> > 
>> > Signed-off-by: Chen Gang <gang.chen at asianux.com>
> Looks fine. Thanks.

Thanks, too.

-- 
Chen Gang

Asianux Corporation


From will.deacon at arm.com  Wed Apr 24 07:10:02 2013
From: will.deacon at arm.com (Will Deacon)
Date: Wed, 24 Apr 2013 12:10:02 +0100
Subject: [PATCH v3 08/32] arm64: KVM: architecture specific MMU backend
In-Reply-To: <5177BBEE.1090209@arm.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
 <1365437854-30214-9-git-send-email-marc.zyngier@arm.com>
 <20130423225816.GC20569@gmail.com> <5177BBEE.1090209@arm.com>
Message-ID: <20130424111002.GJ21850@mudshark.cambridge.arm.com>

On Wed, Apr 24, 2013 at 12:03:10PM +0100, Marc Zyngier wrote:
> On 23/04/13 23:58, Christoffer Dall wrote:
> > I noticed that this doesn't do any cache cleaning.  Are the MMU page
> > table walks guaranteed to be coherent with the MMU on arm64?
> 
> I suppose you meant the cache. In this case, yes. The hardware page
> table walker must snoop the caches.

Also, for ARMv7, SMP implies that the hardware walker snoops the cache. I
recently upstreamed some patches for this (see "ARM: 7691/1: mm: kill unused
TLB_CAN_READ_FROM_L1_CACHE and use ALT_SMP instead" in -next), so you might
want to check if there are any remaining, redundant flushes in kvm for ARMv7.

Will


From marc.zyngier at arm.com  Wed Apr 24 07:27:39 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 24 Apr 2013 12:27:39 +0100
Subject: [PATCH v3 15/32] arm64: KVM: guest one-reg interface
In-Reply-To: <20130423225937.GE20569@gmail.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
 <1365437854-30214-16-git-send-email-marc.zyngier@arm.com>
 <20130423225937.GE20569@gmail.com>
Message-ID: <5177C1AB.3090301@arm.com>

On 23/04/13 23:59, Christoffer Dall wrote:
> On Mon, Apr 08, 2013 at 05:17:17PM +0100, Marc Zyngier wrote:
>> Let userspace play with the guest registers.
>>
>> Reviewed-by: Christopher Covington <cov at codeaurora.org>
>> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
>> ---
>>  arch/arm64/kvm/guest.c | 254 +++++++++++++++++++++++++++++++++++++++++++++++++
>>  1 file changed, 254 insertions(+)
>>  create mode 100644 arch/arm64/kvm/guest.c
>>
>> diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
>> new file mode 100644
>> index 0000000..47d3729
>> --- /dev/null
>> +++ b/arch/arm64/kvm/guest.c
>> @@ -0,0 +1,254 @@
>> +/*
>> + * Copyright (C) 2012,2013 - ARM Ltd
>> + * Author: Marc Zyngier <marc.zyngier at arm.com>
>> + *
>> + * Derived from arch/arm/kvm/guest.c:
>> + * Copyright (C) 2012 - Virtual Open Systems and Columbia University
>> + * Author: Christoffer Dall <c.dall at virtualopensystems.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.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
>> + */
>> +
>> +#include <linux/errno.h>
>> +#include <linux/err.h>
>> +#include <linux/kvm_host.h>
>> +#include <linux/module.h>
>> +#include <linux/vmalloc.h>
>> +#include <linux/fs.h>
>> +#include <asm/cputype.h>
>> +#include <asm/uaccess.h>
>> +#include <asm/kvm.h>
>> +#include <asm/kvm_asm.h>
>> +#include <asm/kvm_emulate.h>
>> +#include <asm/kvm_coproc.h>
>> +
>> +struct kvm_stats_debugfs_item debugfs_entries[] = {
>> +	{ NULL }
>> +};
>> +
>> +int kvm_arch_vcpu_setup(struct kvm_vcpu *vcpu)
>> +{
>> +	vcpu->arch.hcr_el2 = HCR_GUEST_FLAGS;
>> +	return 0;
>> +}
>> +
>> +static u64 core_reg_offset_from_id(u64 id)
>> +{
>> +	return id & ~(KVM_REG_ARCH_MASK | KVM_REG_SIZE_MASK | KVM_REG_ARM_CORE);
>> +}
>> +
>> +static int get_core_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
>> +{
>> +	__u32 __user *uaddr = (__u32 __user *)(unsigned long)reg->addr;
>> +	struct kvm_regs *regs = vcpu_gp_regs(vcpu);
>> +	int nr_regs = sizeof(*regs) / sizeof(__u32);
> 
> eh, arent' your regs 64 bit?  Or are you 32-bit indexing into a 64-bit
> structure?  If so, this needs to be described in a big fat comment
> somewhere, which I couldn't even see looking forward in the patch series
> for the documentation part.

As you noticed below, we have a mix of 32/64/128bit fields there. The
index is indeed on 32bit boundary.

> Seems to me you'd want to remove the fp_regs from the core regs and just
> use a 64-bit indexing and have a separate category for the fp stuff...

Hell no! ;-)

FP is mandatory on arm64, and I'm not going down the road of having
separate structures for that. 32bit has historical baggage to deal with,
but not arm64.

This is the register set, and if the ONE_REG API is too cumbersome to
deal with it, then lets change ONE_REG instead (yes, I can run faster
than you think... ;-).

>> +	u32 off;
>> +
>> +	/* Our ID is an index into the kvm_regs struct. */
>> +	off = core_reg_offset_from_id(reg->id);
>> +	if (off >= nr_regs ||
>> +	    (off + (KVM_REG_SIZE(reg->id) / sizeof(__u32))) >= nr_regs)
> 
> According to your documentation you will always save/restore 32-bit
> registers here, so the desijunction shouldn't be necessary, nor will it
> be if you just base everything on 64-bit here.

No. Your *offset* is a 32bit index. The size can be anything, and you
want to make sure you don't read/write past the kvm_regs structure.

>> +		return -ENOENT;
>> +
>> +	if (copy_to_user(uaddr, ((u32 *)regs) + off, KVM_REG_SIZE(reg->id)))
>> +		return -EFAULT;
>> +
>> +	return 0;
>> +}
>> +
>> +static int set_core_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
>> +{
>> +	__u32 __user *uaddr = (__u32 __user *)(unsigned long)reg->addr;
>> +	struct kvm_regs *regs = vcpu_gp_regs(vcpu);
>> +	int nr_regs = sizeof(*regs) / sizeof(__u32);
> 
> same concern here

Same answer.

> 
>> +	void *valp;
>> +	u64 off;
>> +	int err = 0;
>> +
>> +	/* Our ID is an index into the kvm_regs struct. */
>> +	off = core_reg_offset_from_id(reg->id);
>> +	if (off >= nr_regs ||
>> +	    (off + (KVM_REG_SIZE(reg->id) / sizeof(__u32))) >= nr_regs)
>> +		return -ENOENT;
>> +
>> +	valp = kmalloc(KVM_REG_SIZE(reg->id), GFP_KERNEL);
>> +	if (!valp)
>> +		return -ENOMEM;
> 
> Why are you dynamically allocating this?  Do you ever have anything
> larger than a 64 bit core register? Just put that on the stack.

Look at what a ONE_REG access can be: up to 1kB. I'm not allocating that
on the stack.

>> +
>> +	if (copy_from_user(valp, uaddr, KVM_REG_SIZE(reg->id))) {
>> +		err = -EFAULT;
>> +		goto out;
>> +	}
>> +
>> +	if (off == KVM_REG_ARM_CORE_REG(regs.pstate)) {
>> +		unsigned long mode = (*(unsigned long *)valp) & COMPAT_PSR_MODE_MASK;
>> +		switch (mode) {
>> +		case PSR_MODE_EL0t:
>> +		case PSR_MODE_EL1t:
>> +		case PSR_MODE_EL1h:
>> +			break;
>> +		default:
>> +			err = -EINVAL;
>> +			goto out;
>> +		}
>> +	}
>> +
>> +	memcpy((u32 *)regs + off, valp, KVM_REG_SIZE(reg->id));
>> +out:
>> +	kfree(valp);
>> +	return err;
>> +}
>> +
>> +int kvm_arch_vcpu_ioctl_get_regs(struct kvm_vcpu *vcpu, struct kvm_regs *regs)
>> +{
>> +	return -EINVAL;
>> +}
>> +
>> +int kvm_arch_vcpu_ioctl_set_regs(struct kvm_vcpu *vcpu, struct kvm_regs *regs)
>> +{
>> +	return -EINVAL;
>> +}
>> +
>> +static unsigned long num_core_regs(void)
>> +{
>> +	return sizeof(struct kvm_regs) / sizeof(unsigned long);
>> +}
>> +
>> +/**
>> + * kvm_arm_num_regs - how many registers do we present via KVM_GET_ONE_REG
>> + *
>> + * This is for all registers.
>> + */
>> +unsigned long kvm_arm_num_regs(struct kvm_vcpu *vcpu)
>> +{
>> +	return num_core_regs() + kvm_arm_num_sys_reg_descs(vcpu);
>> +}
>> +
>> +/**
>> + * kvm_arm_copy_reg_indices - get indices of all registers.
>> + *
>> + * We do core registers right here, then we apppend system regs.
>> + */
>> +int kvm_arm_copy_reg_indices(struct kvm_vcpu *vcpu, u64 __user *uindices)
>> +{
>> +	unsigned int i;
>> +	const u64 core_reg = KVM_REG_ARM64 | KVM_REG_SIZE_U64 | KVM_REG_ARM_CORE;
>> +
>> +	for (i = 0; i < sizeof(struct kvm_regs)/sizeof(unsigned long); i++) {
> 
> nit: spaces around the division
> nit: the kvm_regs struct uses __u64, so would be slightly more coherent
>      to use that for the sizeof(...) as well

Actually, it should be __u32, as that is an index into the kvm_regs
structure.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...



From marc.zyngier at arm.com  Wed Apr 24 07:39:39 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 24 Apr 2013 12:39:39 +0100
Subject: [PATCH v3 17/32] arm64: KVM: HYP mode world switch implementation
In-Reply-To: <20130423225958.GF20569@gmail.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
 <1365437854-30214-18-git-send-email-marc.zyngier@arm.com>
 <20130423225958.GF20569@gmail.com>
Message-ID: <5177C47B.6090502@arm.com>

On 23/04/13 23:59, Christoffer Dall wrote:
> On Mon, Apr 08, 2013 at 05:17:19PM +0100, Marc Zyngier wrote:
>> The HYP mode world switch in all its glory.
>>
>> Implements save/restore of host/guest registers, EL2 trapping,
>> IPA resolution, and additional services (tlb invalidation).
>>
>> Reviewed-by: Christopher Covington <cov at codeaurora.org>
>> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
>> ---
>>  arch/arm64/kernel/asm-offsets.c |  34 +++
>>  arch/arm64/kvm/hyp.S            | 602 ++++++++++++++++++++++++++++++++++++++++
>>  2 files changed, 636 insertions(+)
>>  create mode 100644 arch/arm64/kvm/hyp.S
>>

[...]

>> diff --git a/arch/arm64/kvm/hyp.S b/arch/arm64/kvm/hyp.S
>> new file mode 100644
>> index 0000000..c745d20
>> --- /dev/null
>> +++ b/arch/arm64/kvm/hyp.S
>> @@ -0,0 +1,602 @@
>> +/*
>> + * Copyright (C) 2012,2013 - ARM Ltd
>> + * Author: Marc Zyngier <marc.zyngier at arm.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.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
>> + */
>> +
>> +#include <linux/linkage.h>
>> +#include <linux/irqchip/arm-gic.h>
>> +
>> +#include <asm/assembler.h>
>> +#include <asm/memory.h>
>> +#include <asm/asm-offsets.h>
>> +#include <asm/fpsimdmacros.h>
>> +#include <asm/kvm.h>
>> +#include <asm/kvm_asm.h>
>> +#include <asm/kvm_arm.h>
>> +#include <asm/kvm_mmu.h>
>> +
>> +#define CPU_GP_REG_OFFSET(x) (CPU_GP_REGS + x)
>> +#define CPU_XREG_OFFSET(x)   CPU_GP_REG_OFFSET(CPU_USER_PT_REGS + 8*x)
>> +#define CPU_SPSR_OFFSET(x)   CPU_GP_REG_OFFSET(CPU_SPSR + 8*x)
>> +#define CPU_SYSREG_OFFSET(x) (CPU_SYSREGS + 8*x)
>> +
>> +     .text
>> +     .pushsection    .hyp.text, "ax"
>> +     .align  PAGE_SHIFT
>> +
>> +__kvm_hyp_code_start:
>> +     .globl __kvm_hyp_code_start
>> +
>> +.macro save_common_regs
>> +     // x2: base address for cpu context
>> +     // x3: tmp register
> 
> what's with the C99 style comments? Standard for arm64 assembly?

Yes. The toolchain guys got rid of '@' as a single line comment delimiter.

[...]

>> +el1_sync:                                    // Guest trapped into EL2
>> +     push    x0, x1
>> +     push    x2, x3
>> +
>> +     mrs     x1, esr_el2
>> +     lsr     x2, x1, #ESR_EL2_EC_SHIFT
>> +
>> +     cmp     x2, #ESR_EL2_EC_HVC64
>> +     b.ne    el1_trap
>> +
>> +     mrs     x3, vttbr_el2                   // If vttbr is valid, the 64bit guest
>> +     cbnz    x3, el1_trap                    // called HVC
>> +
>> +     /* Here, we're pretty sure the host called HVC. */
>> +     pop     x2, x3
>> +     pop     x0, x1
>> +
>> +     push    lr, xzr
>> +
>> +     /*
>> +      * Compute the function address in EL2, and shuffle the parameters.
>> +      */
>> +     kern_hyp_va     x0
>> +     mov     lr, x0
>> +     mov     x0, x1
>> +     mov     x1, x2
>> +     mov     x2, x3
>> +     blr     lr
>> +
>> +     pop     lr, xzr
>> +     eret
>> +
>> +el1_trap:
>> +     /*
>> +      * x1: ESR
>> +      * x2: ESR_EC
>> +      */
>> +     cmp     x2, #ESR_EL2_EC_DABT
>> +     mov     x0, #ESR_EL2_EC_IABT
>> +     ccmp    x2, x0, #4, ne
>> +     b.ne    1f              // Not an abort we care about
> 
> why do we get the hpfar_el2 if it's not an abort (or is this for a
> special type of abort) ?

No, we could actually avoid saving HPFAR_EL2 altogether in this case.

>> +
>> +     /* This is an abort. Check for permission fault */
>> +     and     x2, x1, #ESR_EL2_FSC_TYPE
>> +     cmp     x2, #FSC_PERM
>> +     b.ne    1f              // Not a permission fault
>> +
>> +     /*
>> +      * Check for Stage-1 page table walk, which is guaranteed
>> +      * to give a valid HPFAR_EL2.
>> +      */
>> +     tbnz    x1, #7, 1f      // S1PTW is set
>> +
>> +     /*
>> +      * Permission fault, HPFAR_EL2 is invalid.
>> +      * Resolve the IPA the hard way using the guest VA.
>> +      * We always perform an EL1 lookup, as we already
>> +      * went through Stage-1.
>> +      */
> 
> What does the last sentence mean exactly?

It means that the Stage-1 translation already validated the memory
access rights. As such, we can use the EL1 translation regime, and don't
have to distinguish between EL0 and EL1 access.

>> +     mrs     x3, far_el2
>> +     at      s1e1r, x3
>> +     isb
>> +
>> +     /* Read result */
>> +     mrs     x3, par_el1
>> +     tbnz    x3, #1, 3f              // Bail out if we failed the translation
>> +     ubfx    x3, x3, #12, #36        // Extract IPA
>> +     lsl     x3, x3, #4              // and present it like HPFAR
>> +     b       2f
>> +
>> +1:   mrs     x3, hpfar_el2
>> +
>> +2:   mrs     x0, tpidr_el2
>> +     mrs     x2, far_el2
>> +     str     x1, [x0, #VCPU_ESR_EL2]
>> +     str     x2, [x0, #VCPU_FAR_EL2]
>> +     str     x3, [x0, #VCPU_HPFAR_EL2]
>> +
>> +     mov     x1, #ARM_EXCEPTION_TRAP
>> +     b       __kvm_vcpu_return
>> +
>> +     /*
>> +      * Translation failed. Just return to the guest and
>> +      * let it fault again. Another CPU is probably playing
>> +      * behind our back.
>> +      */
> 
> This actually makes me wonder if this is a potential DOS attack from
> guests (on the 32-bit code as well), or are we sure that an asynchronous
> timer interrupt to the host will always creep in between e.g. a tight
> loop playing this trick on us?

Host interrupts will fire as soon as you eret into the guest. At that
point, the (malicious) guest will be scheduled out, just like a normal
process.

	M.
-- 
Jazz is not dead. It just smells funny...



From shawn.guo at linaro.org  Wed Apr 24 07:43:06 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Wed, 24 Apr 2013 19:43:06 +0800
Subject: [PATCH V4] ARM: i.MX5: Allow DT clock providers
In-Reply-To: <CAOMZO5CDPwwA2LhugUBxABz9dZXgLG7F3_osMDiiPO+5odzvsg@mail.gmail.com>
References: <20130423091633.22088.58225.stgit@localhost>
 <20130423122007.GE27475@S2101-09.ap.freescale.net>
 <CAOMZO5CDPwwA2LhugUBxABz9dZXgLG7F3_osMDiiPO+5odzvsg@mail.gmail.com>
Message-ID: <CAAQ0ZWQdsSVz0bLmR1rQtzp_r2iOxzxRXSN7k8-oMKtHBiWGXA@mail.gmail.com>

On Tue, Apr 23, 2013 at 11:39:13PM -0300, Fabio Estevam wrote:
> On Tue, Apr 23, 2013 at 9:20 AM, Shawn Guo <shawn.guo at linaro.org> wrote:
>
> > Applied with a small fixup below.
>
> Into which branch, please? I could not find it in your tree.

Just pushed branch imx/soc-3.11 for that.

Shawn


From marc.zyngier at arm.com  Wed Apr 24 07:43:21 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 24 Apr 2013 12:43:21 +0100
Subject: [PATCH v3 19/32] arm64: KVM: Plug the VGIC
In-Reply-To: <20130423230012.GG20569@gmail.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
 <1365437854-30214-20-git-send-email-marc.zyngier@arm.com>
 <20130423230012.GG20569@gmail.com>
Message-ID: <5177C559.9070806@arm.com>

On 24/04/13 00:00, Christoffer Dall wrote:
> On Mon, Apr 08, 2013 at 05:17:21PM +0100, Marc Zyngier wrote:
>> Add support for the in-kernel GIC emulation. The include file
>> is a complete duplicate of the 32bit one - something to fix
>> at one point.
> 
> seems like something that should be fixed sooner as opposed to later...
> Is it hard?

Hard? No. Disgusting? Yes.

You need to find a common location for the files. Something like
virt/kvm/arm/vgic.h? The x86/ia64 guys already have virt/kvm/ioapic.h as
a (bad) precedent.

While your at it, you could put a lot of the common code there as well.

	M.
-- 
Jazz is not dead. It just smells funny...



From marc.zyngier at arm.com  Wed Apr 24 07:43:51 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 24 Apr 2013 12:43:51 +0100
Subject: [PATCH v3 20/32] arm64: KVM: Plug the arch timer
In-Reply-To: <20130423230024.GH20569@gmail.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
 <1365437854-30214-21-git-send-email-marc.zyngier@arm.com>
 <20130423230024.GH20569@gmail.com>
Message-ID: <5177C577.2050209@arm.com>

On 24/04/13 00:00, Christoffer Dall wrote:
> On Mon, Apr 08, 2013 at 05:17:22PM +0100, Marc Zyngier wrote:
>> Add support for the in-kernel timer emulation. The include file
>> is a complete duplicate of the 32bit one - something to fix
>> at one point.
> 
> again, I'd really like to see this fixed before we merge the code...

Feel free to suggest a solution. None of the one I tried are nice.

	M.
-- 
Jazz is not dead. It just smells funny...



From shawn.guo at linaro.org  Wed Apr 24 07:49:45 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Wed, 24 Apr 2013 19:49:45 +0800
Subject: [PATCH 0/2] drivers/video: mxs-fb: build fixes
In-Reply-To: <1366790894-20426-1-git-send-email-mpa@pengutronix.de>
References: <1366790894-20426-1-git-send-email-mpa@pengutronix.de>
Message-ID: <20130424114943.GA2736@S2101-09.ap.freescale.net>

On Wed, Apr 24, 2013 at 10:08:12AM +0200, Markus Pargmann wrote:
> Hi,
> 
> mxs-fb commit
> 
> 669406534b4abb827d1bdc39bb5e2d5255818ae2 video: mxsfb: get display timings from device tree
> 
> creates a build failure together with those commits:
> 
> a38884f681a4d044befd30d9f3d19a0821bae63a videomode: simplify videomode Kconfig and Makefile
> 6cd2c7db41eab204b6474534df4ca68a7dc53d86 videomode: videomode_from_timing work
> 
> All of them are in linux-next, so mxs-fb fails to build there.

Fabio already had a patch [1] for that.  I will send it mainline during
3.10-rc.

Shawn

[1] http://thread.gmane.org/gmane.linux.ports.arm.kernel/230938



From prabhakar.csengg at gmail.com  Wed Apr 24 08:00:02 2013
From: prabhakar.csengg at gmail.com (Prabhakar Lad)
Date: Wed, 24 Apr 2013 17:30:02 +0530
Subject: [PATCH 0/6] Davinci fbdev driver and enable it for DMx platform
Message-ID: <1366804808-22720-1-git-send-email-prabhakar.csengg@gmail.com>

From: Lad, Prabhakar <prabhakar.csengg at gmail.com>

This patch series adds an fbdev driver for Texas
Instruments Davinci SoC.The display subsystem consists
of OSD and VENC, with OSD supporting 2 RGb planes and 
2 video planes.
http://focus.ti.com/general/docs/lit/
getliterature.tsp?literatureNumber=sprue37d&fileType=pdf

A good amount of the OSD and VENC enabling code is
present in the kernel, and this patch series adds the 
fbdev interface.

The fbdev driver exports 4 nodes representing each
plane to the user - from fb0 to fb3.


Lad, Prabhakar (6):
  media: davinci: vpbe: fix checkpatch warning for CamelCase
  media: davinci: vpbe: enable vpbe for fbdev addition
  davinci: vpbe: add fbdev driver
  ARM: davinci: dm355: enable fbdev driver
  ARM: davinci: dm365: enable fbdev driver
  ARM: davinci: dm644x: enable fbdev driver

 arch/arm/mach-davinci/dm355.c                 |   24 +-
 arch/arm/mach-davinci/dm365.c                 |   10 +
 arch/arm/mach-davinci/dm644x.c                |   10 +
 drivers/media/platform/davinci/vpbe_display.c |    8 +-
 drivers/media/platform/davinci/vpbe_osd.c     |  820 ++++++++-
 drivers/media/platform/davinci/vpbe_venc.c    |   43 +
 drivers/video/Kconfig                         |   12 +
 drivers/video/Makefile                        |    1 +
 drivers/video/davincifb.c                     | 2523 +++++++++++++++++++++++++
 drivers/video/davincifb.h                     |  194 ++
 include/media/davinci/vpbe_osd.h              |   66 +-
 include/media/davinci/vpbe_venc.h             |   21 +
 12 files changed, 3702 insertions(+), 30 deletions(-)
 create mode 100644 drivers/video/davincifb.c
 create mode 100644 drivers/video/davincifb.h

-- 
1.7.4.1



From prabhakar.csengg at gmail.com  Wed Apr 24 08:00:03 2013
From: prabhakar.csengg at gmail.com (Prabhakar Lad)
Date: Wed, 24 Apr 2013 17:30:03 +0530
Subject: [PATCH 1/6] media: davinci: vpbe: fix checkpatch warning for CamelCase
In-Reply-To: <1366804808-22720-1-git-send-email-prabhakar.csengg@gmail.com>
References: <1366804808-22720-1-git-send-email-prabhakar.csengg@gmail.com>
Message-ID: <1366804808-22720-2-git-send-email-prabhakar.csengg@gmail.com>

From: Lad, Prabhakar <prabhakar.csengg at gmail.com>

This patch fixes checkpatch warning to avoid CamelCase.

Signed-off-by: Lad, Prabhakar <prabhakar.csengg at gmail.com>
---
 drivers/media/platform/davinci/vpbe_display.c |    2 +-
 drivers/media/platform/davinci/vpbe_osd.c     |   24 ++++++++++++------------
 include/media/davinci/vpbe_osd.h              |    4 ++--
 3 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/drivers/media/platform/davinci/vpbe_display.c b/drivers/media/platform/davinci/vpbe_display.c
index 1802f11..1c4ba89 100644
--- a/drivers/media/platform/davinci/vpbe_display.c
+++ b/drivers/media/platform/davinci/vpbe_display.c
@@ -929,7 +929,7 @@ static int vpbe_display_s_fmt(struct file *file, void *priv,
 	cfg->interlaced = vpbe_dev->current_timings.interlaced;
 
 	if (V4L2_PIX_FMT_UYVY == pixfmt->pixelformat)
-		cfg->pixfmt = PIXFMT_YCbCrI;
+		cfg->pixfmt = PIXFMT_YCBCRI;
 
 	/* Change of the default pixel format for both video windows */
 	if (V4L2_PIX_FMT_NV12 == pixfmt->pixelformat) {
diff --git a/drivers/media/platform/davinci/vpbe_osd.c b/drivers/media/platform/davinci/vpbe_osd.c
index 396a51c..6ed82e8 100644
--- a/drivers/media/platform/davinci/vpbe_osd.c
+++ b/drivers/media/platform/davinci/vpbe_osd.c
@@ -119,7 +119,7 @@ static inline u32 osd_modify(struct osd_state *sd, u32 mask, u32 val,
 #define is_rgb_pixfmt(pixfmt) \
 	(((pixfmt) == PIXFMT_RGB565) || ((pixfmt) == PIXFMT_RGB888))
 #define is_yc_pixfmt(pixfmt) \
-	(((pixfmt) == PIXFMT_YCbCrI) || ((pixfmt) == PIXFMT_YCrCbI) || \
+	(((pixfmt) == PIXFMT_YCBCRI) || ((pixfmt) == PIXFMT_YCRCBI) || \
 	((pixfmt) == PIXFMT_NV12))
 #define MAX_WIN_SIZE OSD_VIDWIN0XP_V0X
 #define MAX_LINE_LENGTH (OSD_VIDWIN0OFST_V0LO << 5)
@@ -360,8 +360,8 @@ static void _osd_enable_color_key(struct osd_state *sd,
 			osd_write(sd, colorkey & OSD_TRANSPVALL_RGBL,
 				  OSD_TRANSPVALL);
 		break;
-	case PIXFMT_YCbCrI:
-	case PIXFMT_YCrCbI:
+	case PIXFMT_YCBCRI:
+	case PIXFMT_YCRCBI:
 		if (sd->vpbe_type == VPBE_VERSION_3)
 			osd_modify(sd, OSD_TRANSPVALU_Y, colorkey,
 				   OSD_TRANSPVALU);
@@ -813,8 +813,8 @@ static int try_layer_config(struct osd_state *sd, enum osd_layer layer,
 		if (osd->vpbe_type == VPBE_VERSION_1)
 			bad_config = !is_vid_win(layer);
 		break;
-	case PIXFMT_YCbCrI:
-	case PIXFMT_YCrCbI:
+	case PIXFMT_YCBCRI:
+	case PIXFMT_YCRCBI:
 		bad_config = !is_vid_win(layer);
 		break;
 	case PIXFMT_RGB888:
@@ -950,9 +950,9 @@ static void _osd_set_cbcr_order(struct osd_state *sd,
 	 * The caller must ensure that all windows using YC pixfmt use the same
 	 * Cb/Cr order.
 	 */
-	if (pixfmt == PIXFMT_YCbCrI)
+	if (pixfmt == PIXFMT_YCBCRI)
 		osd_clear(sd, OSD_MODE_CS, OSD_MODE);
-	else if (pixfmt == PIXFMT_YCrCbI)
+	else if (pixfmt == PIXFMT_YCRCBI)
 		osd_set(sd, OSD_MODE_CS, OSD_MODE);
 }
 
@@ -981,8 +981,8 @@ static void _osd_set_layer_config(struct osd_state *sd, enum osd_layer layer,
 				winmd |= (2 << OSD_OSDWIN0MD_BMP0MD_SHIFT);
 				_osd_enable_rgb888_pixblend(sd, OSDWIN_OSD0);
 				break;
-			case PIXFMT_YCbCrI:
-			case PIXFMT_YCrCbI:
+			case PIXFMT_YCBCRI:
+			case PIXFMT_YCRCBI:
 				winmd |= (3 << OSD_OSDWIN0MD_BMP0MD_SHIFT);
 				break;
 			default:
@@ -1128,8 +1128,8 @@ static void _osd_set_layer_config(struct osd_state *sd, enum osd_layer layer,
 					_osd_enable_rgb888_pixblend(sd,
 							OSDWIN_OSD1);
 					break;
-				case PIXFMT_YCbCrI:
-				case PIXFMT_YCrCbI:
+				case PIXFMT_YCBCRI:
+				case PIXFMT_YCRCBI:
 					winmd |=
 					    (3 << OSD_OSDWIN1MD_BMP1MD_SHIFT);
 					break;
@@ -1508,7 +1508,7 @@ static int osd_initialize(struct osd_state *osd)
 	_osd_init(osd);
 
 	/* set default Cb/Cr order */
-	osd->yc_pixfmt = PIXFMT_YCbCrI;
+	osd->yc_pixfmt = PIXFMT_YCBCRI;
 
 	if (osd->vpbe_type == VPBE_VERSION_3) {
 		/*
diff --git a/include/media/davinci/vpbe_osd.h b/include/media/davinci/vpbe_osd.h
index 42628fc..de59364 100644
--- a/include/media/davinci/vpbe_osd.h
+++ b/include/media/davinci/vpbe_osd.h
@@ -82,9 +82,9 @@ enum osd_pix_format {
 	PIXFMT_4BPP,
 	PIXFMT_8BPP,
 	PIXFMT_RGB565,
-	PIXFMT_YCbCrI,
+	PIXFMT_YCBCRI,
 	PIXFMT_RGB888,
-	PIXFMT_YCrCbI,
+	PIXFMT_YCRCBI,
 	PIXFMT_NV12,
 	PIXFMT_OSD_ATTR,
 };
-- 
1.7.4.1



From prabhakar.csengg at gmail.com  Wed Apr 24 08:00:04 2013
From: prabhakar.csengg at gmail.com (Prabhakar Lad)
Date: Wed, 24 Apr 2013 17:30:04 +0530
Subject: [PATCH 2/6] media: davinci: vpbe: enable vpbe for fbdev addition
In-Reply-To: <1366804808-22720-1-git-send-email-prabhakar.csengg@gmail.com>
References: <1366804808-22720-1-git-send-email-prabhakar.csengg@gmail.com>
Message-ID: <1366804808-22720-3-git-send-email-prabhakar.csengg@gmail.com>

From: Lad, Prabhakar <prabhakar.csengg at gmail.com>

enable the venc, osd and vpbe display driver for addition
of fbdev driver. Mainly includes fbdev ops structure inclusion,
palette and osd layer related functionality for OSD block.

Signed-off-by: Lad, Prabhakar <prabhakar.csengg at gmail.com>
---
 drivers/media/platform/davinci/vpbe_display.c |    6 +
 drivers/media/platform/davinci/vpbe_osd.c     |  796 ++++++++++++++++++++++++-
 drivers/media/platform/davinci/vpbe_venc.c    |   43 ++
 include/media/davinci/vpbe_osd.h              |   62 ++
 include/media/davinci/vpbe_venc.h             |   21 +
 5 files changed, 920 insertions(+), 8 deletions(-)

diff --git a/drivers/media/platform/davinci/vpbe_display.c b/drivers/media/platform/davinci/vpbe_display.c
index 1c4ba89..0341dcc 100644
--- a/drivers/media/platform/davinci/vpbe_display.c
+++ b/drivers/media/platform/davinci/vpbe_display.c
@@ -121,10 +121,12 @@ static void vpbe_isr_odd_field(struct vpbe_display *disp_obj,
 static irqreturn_t venc_isr(int irq, void *arg)
 {
 	struct vpbe_display *disp_dev = (struct vpbe_display *)arg;
+	struct vpbe_device *vpbe_dev = disp_dev->vpbe_dev;
 	struct vpbe_layer *layer;
 	static unsigned last_event;
 	unsigned event = 0;
 	int fid;
+	int ret;
 	int i;
 
 	if ((NULL == arg) || (NULL == disp_dev->dev[0]))
@@ -195,6 +197,10 @@ static irqreturn_t venc_isr(int irq, void *arg)
 				vpbe_isr_odd_field(disp_dev, layer);
 		}
 	}
+	ret = v4l2_subdev_call(vpbe_dev->venc, core, ioctl, VENC_INTERRUPT,
+				&event);
+	if (ret < 0)
+		v4l2_err(&vpbe_dev->v4l2_dev, "Error in getting Field ID 0\n");
 
 	return IRQ_HANDLED;
 }
diff --git a/drivers/media/platform/davinci/vpbe_osd.c b/drivers/media/platform/davinci/vpbe_osd.c
index 6ed82e8..455b0ca 100644
--- a/drivers/media/platform/davinci/vpbe_osd.c
+++ b/drivers/media/platform/davinci/vpbe_osd.c
@@ -175,6 +175,13 @@ static int _osd_dm6446_vid0_pingpong(struct osd_state *sd,
 	return 0;
 }
 
+static int osd_get_field_inversion(struct osd_state *sd)
+{
+	struct osd_state *osd = sd;
+
+	return osd->field_inversion;
+}
+
 static void _osd_set_field_inversion(struct osd_state *sd, int enable)
 {
 	unsigned fsinv = 0;
@@ -185,6 +192,365 @@ static void _osd_set_field_inversion(struct osd_state *sd, int enable)
 	osd_modify(sd, OSD_MODE_FSINV, fsinv, OSD_MODE);
 }
 
+static void osd_set_field_inversion(struct osd_state *sd, int enable)
+{
+	struct osd_state *osd = sd;
+	unsigned long flags;
+
+	spin_lock_irqsave(&osd->lock, flags);
+
+	osd->field_inversion = (enable != 0);
+	_osd_set_field_inversion(sd, enable);
+
+	osd->pingpong = _osd_dm6446_vid0_pingpong(sd, osd->field_inversion,
+					osd->win[WIN_VID0].fb_base_phys,
+						  &osd->win[WIN_VID0].lconfig);
+
+	spin_unlock_irqrestore(&osd->lock, flags);
+}
+
+static void osd_get_background(struct osd_state *sd, enum osd_clut *clut,
+				 unsigned char *clut_index)
+{
+	struct osd_state *osd = sd;
+	unsigned long flags;
+
+	spin_lock_irqsave(&osd->lock, flags);
+
+	*clut = osd->backg_clut;
+	*clut_index = osd->backg_clut_index;
+
+	spin_unlock_irqrestore(&osd->lock, flags);
+}
+
+static void _osd_set_background(struct osd_state *sd, enum osd_clut clut,
+				unsigned char clut_index)
+{
+	u32 mode = 0;
+
+	if (clut == RAM_CLUT)
+		mode |= OSD_MODE_BCLUT;
+	mode |= clut_index;
+	osd_modify(sd, OSD_MODE_BCLUT | OSD_MODE_CABG, mode, OSD_MODE);
+}
+
+static void osd_set_background(struct osd_state *sd, enum osd_clut clut,
+			       unsigned char clut_index)
+{
+	struct osd_state *osd = sd;
+	unsigned long flags;
+	spin_lock_irqsave(&osd->lock, flags);
+
+	osd->backg_clut = clut;
+	osd->backg_clut_index = clut_index;
+	_osd_set_background(sd, clut, clut_index);
+
+	spin_unlock_irqrestore(&osd->lock, flags);
+}
+
+static int osd_get_interpolation_filter(struct osd_state *sd)
+{
+	struct osd_state *osd = sd;
+
+	return osd->interpolation_filter;
+}
+
+static void _osd_set_interpolation_filter(struct osd_state *sd, int filter)
+{
+	struct osd_state *osd = sd;
+
+	if (osd->vpbe_type == VPBE_VERSION_3 ||
+	    osd->vpbe_type == VPBE_VERSION_2)
+		osd_clear(sd, OSD_EXTMODE_EXPMDSEL, OSD_EXTMODE);
+
+	osd_modify(sd, OSD_MODE_EF, filter ? OSD_MODE_EF : 0, OSD_MODE);
+}
+
+static void osd_set_interpolation_filter(struct osd_state *sd, int filter)
+{
+	struct osd_state *osd = sd;
+	unsigned long flags;
+
+	spin_lock_irqsave(&osd->lock, flags);
+
+	osd->interpolation_filter = (filter != 0);
+	_osd_set_interpolation_filter(sd, filter);
+
+	spin_unlock_irqrestore(&osd->lock, flags);
+}
+
+static void osd_get_cursor_config(struct osd_state *sd,
+				  struct osd_cursor_config *cursor)
+{
+	struct osd_state *osd = sd;
+	unsigned long flags;
+
+	spin_lock_irqsave(&osd->lock, flags);
+
+	*cursor = osd->cursor.config;
+
+	spin_unlock_irqrestore(&osd->lock, flags);
+}
+
+static void _osd_set_cursor_config(struct osd_state *sd,
+				   const struct osd_cursor_config *cursor)
+{
+	struct osd_state *osd = sd;
+	unsigned rectcur = 0;
+
+	osd_write(sd, cursor->xsize, OSD_CURXL);
+	osd_write(sd, cursor->xpos, OSD_CURXP);
+
+	if (cursor->interlaced) {
+		osd_write(sd, cursor->ypos >> 1, OSD_CURYP);
+		if (osd->vpbe_type == VPBE_VERSION_1)
+			/* Must add 1 to ysize due to device erratum. */
+			osd_write(sd, (cursor->ysize >> 1) + 1, OSD_CURYL);
+		else
+			osd_write(sd, cursor->ysize >> 1, OSD_CURYL);
+	} else {
+		osd_write(sd, cursor->ypos, OSD_CURYP);
+		if (osd->vpbe_type == VPBE_VERSION_1)
+			/* Must add 1 to ysize due to device erratum. */
+			osd_write(sd, cursor->ysize + 1, OSD_CURYL);
+		else
+			osd_write(sd, cursor->ysize, OSD_CURYL);
+	}
+
+	if (cursor->clut == RAM_CLUT)
+		rectcur |= OSD_RECTCUR_CLUTSR;
+
+	rectcur |= (cursor->clut_index << OSD_RECTCUR_RCAD_SHIFT);
+	rectcur |= (cursor->h_width << OSD_RECTCUR_RCHW_SHIFT);
+	rectcur |= (cursor->v_width << OSD_RECTCUR_RCVW_SHIFT);
+	osd_modify(sd, OSD_RECTCUR_RCAD | OSD_RECTCUR_CLUTSR |
+		   OSD_RECTCUR_RCHW | OSD_RECTCUR_RCVW, rectcur, OSD_RECTCUR);
+}
+
+static void osd_set_cursor_config(struct osd_state *sd,
+				  struct osd_cursor_config *cursor)
+{
+	struct osd_state *osd = sd;
+	unsigned long flags;
+
+	spin_lock_irqsave(&osd->lock, flags);
+
+	cursor->xpos = min_t(unsigned, cursor->xpos, (unsigned)OSD_CURXP_RCSX);
+	cursor->ypos = min_t(unsigned, cursor->ypos, (unsigned)OSD_CURYP_RCSY);
+	cursor->xsize =
+		min_t(unsigned, cursor->xsize, (unsigned)OSD_CURXL_RCSW);
+	cursor->ysize =
+		min_t(unsigned, cursor->ysize, (unsigned)OSD_CURYL_RCSH);
+	cursor->interlaced = (cursor->interlaced != 0);
+	if (cursor->interlaced) {
+		cursor->ysize &= ~1;
+		cursor->ypos &= ~1;
+	}
+	cursor->h_width &= (OSD_RECTCUR_RCHW >> OSD_RECTCUR_RCHW_SHIFT);
+	cursor->v_width &= (OSD_RECTCUR_RCVW >> OSD_RECTCUR_RCVW_SHIFT);
+	cursor->clut = (cursor->clut == RAM_CLUT) ? RAM_CLUT : ROM_CLUT;
+
+	osd->cursor.config = *cursor;
+	_osd_set_cursor_config(sd, cursor);
+
+	spin_unlock_irqrestore(&osd->lock, flags);
+}
+
+static int osd_cursor_is_enabled(struct osd_state *sd)
+{
+	struct osd_state *osd = sd;
+
+	return osd->cursor.is_enabled;
+}
+
+static void _osd_cursor_disable(struct osd_state *sd)
+{
+	osd_clear(sd, OSD_RECTCUR_RCACT, OSD_RECTCUR);
+}
+
+static void osd_cursor_disable(struct osd_state *sd)
+{
+	struct osd_state *osd = sd;
+	unsigned long flags;
+
+	spin_lock_irqsave(&osd->lock, flags);
+
+	osd->cursor.is_enabled = 0;
+	_osd_cursor_disable(sd);
+
+	spin_unlock_irqrestore(&osd->lock, flags);
+}
+
+static void _osd_cursor_enable(struct osd_state *sd)
+{
+	osd_set(sd, OSD_RECTCUR_RCACT, OSD_RECTCUR);
+}
+
+static void osd_cursor_enable(struct osd_state *sd)
+{
+	struct osd_state *osd = sd;
+	unsigned long flags;
+
+	spin_lock_irqsave(&osd->lock, flags);
+
+	osd->cursor.is_enabled = 1;
+	_osd_cursor_enable(sd);
+
+	spin_unlock_irqrestore(&osd->lock, flags);
+}
+
+static void osd_get_vid_expansion(struct osd_state *sd,
+				  enum osd_h_exp_ratio *h_exp,
+				  enum osd_v_exp_ratio *v_exp)
+{
+	struct osd_state *osd = sd;
+	unsigned long flags;
+
+	spin_lock_irqsave(&osd->lock, flags);
+
+	*h_exp = osd->vid_h_exp;
+	*v_exp = osd->vid_v_exp;
+
+	spin_unlock_irqrestore(&osd->lock, flags);
+}
+
+static void _osd_set_vid_expansion(struct osd_state *sd,
+				   enum osd_h_exp_ratio h_exp,
+				   enum osd_v_exp_ratio v_exp)
+{
+	struct osd_state *osd = sd;
+	u32 mode = 0;
+	u32 extmode = 0;
+
+	switch (h_exp) {
+	case H_EXP_OFF:
+		break;
+	case H_EXP_9_OVER_8:
+		mode |= OSD_MODE_VHRSZ;
+		break;
+	case H_EXP_3_OVER_2:
+		extmode |= OSD_EXTMODE_VIDHRSZ15;
+		break;
+	}
+
+	switch (v_exp) {
+	case V_EXP_OFF:
+		break;
+	case V_EXP_6_OVER_5:
+		mode |= OSD_MODE_VVRSZ;
+		break;
+	}
+
+	if (osd->vpbe_type == VPBE_VERSION_3 ||
+	    osd->vpbe_type == VPBE_VERSION_2)
+		osd_modify(sd, OSD_EXTMODE_VIDHRSZ15, extmode, OSD_EXTMODE);
+
+	osd_modify(sd, OSD_MODE_VHRSZ | OSD_MODE_VVRSZ, mode, OSD_MODE);
+}
+
+static int osd_set_vid_expansion(struct osd_state *sd,
+				 enum osd_h_exp_ratio h_exp,
+				 enum osd_v_exp_ratio v_exp)
+{
+	struct osd_state *osd = sd;
+	unsigned long flags;
+
+	if (h_exp == H_EXP_3_OVER_2 && (osd->vpbe_type == VPBE_VERSION_1))
+		return -EINVAL;
+
+	spin_lock_irqsave(&osd->lock, flags);
+
+	osd->vid_h_exp = h_exp;
+	osd->vid_v_exp = v_exp;
+	_osd_set_vid_expansion(sd, h_exp, v_exp);
+
+	spin_unlock_irqrestore(&osd->lock, flags);
+	return 0;
+}
+
+static void osd_get_osd_expansion(struct osd_state *sd,
+				  enum osd_h_exp_ratio *h_exp,
+				  enum osd_v_exp_ratio *v_exp)
+{
+	struct osd_state *osd = sd;
+	unsigned long flags;
+
+	spin_lock_irqsave(&osd->lock, flags);
+
+	*h_exp = osd->osd_h_exp;
+	*v_exp = osd->osd_v_exp;
+
+	spin_unlock_irqrestore(&osd->lock, flags);
+}
+
+static void _osd_set_osd_expansion(struct osd_state *sd,
+				   enum osd_h_exp_ratio h_exp,
+				   enum osd_v_exp_ratio v_exp)
+{
+	struct osd_state *osd = sd;
+	u32 mode = 0;
+	u32 extmode = 0;
+
+	switch (h_exp) {
+	case H_EXP_OFF:
+		break;
+	case H_EXP_9_OVER_8:
+		mode |= OSD_MODE_OHRSZ;
+		break;
+	case H_EXP_3_OVER_2:
+		extmode |= OSD_EXTMODE_OSDHRSZ15;
+		break;
+	}
+
+	switch (v_exp) {
+	case V_EXP_OFF:
+		break;
+	case V_EXP_6_OVER_5:
+		mode |= OSD_MODE_OVRSZ;
+		break;
+	}
+
+	if (osd->vpbe_type == VPBE_VERSION_3 ||
+	    osd->vpbe_type == VPBE_VERSION_2)
+		osd_modify(sd, OSD_EXTMODE_OSDHRSZ15, extmode, OSD_EXTMODE);
+
+	osd_modify(sd, OSD_MODE_OHRSZ | OSD_MODE_OVRSZ, mode, OSD_MODE);
+}
+
+static int osd_set_osd_expansion(struct osd_state *sd,
+				 enum osd_h_exp_ratio h_exp,
+				 enum osd_v_exp_ratio v_exp)
+{
+	struct osd_state *osd = sd;
+	unsigned long flags;
+
+	if (h_exp == H_EXP_3_OVER_2 && (osd->vpbe_type == VPBE_VERSION_1))
+		return -EINVAL;
+
+	spin_lock_irqsave(&osd->lock, flags);
+
+	osd->osd_h_exp = h_exp;
+	osd->osd_v_exp = v_exp;
+	_osd_set_osd_expansion(sd, h_exp, v_exp);
+
+	spin_unlock_irqrestore(&osd->lock, flags);
+	return 0;
+}
+
+static void osd_get_blink_attribute(struct osd_state *sd, int *enable,
+				    enum osd_blink_interval *blink)
+{
+	struct osd_state *osd = sd;
+	unsigned long flags;
+
+	spin_lock_irqsave(&osd->lock, flags);
+
+	*enable = osd->is_blinking;
+	*blink = osd->blink;
+
+	spin_unlock_irqrestore(&osd->lock, flags);
+}
+
 static void _osd_set_blink_attribute(struct osd_state *sd, int enable,
 				     enum osd_blink_interval blink)
 {
@@ -199,6 +565,29 @@ static void _osd_set_blink_attribute(struct osd_state *sd, int enable,
 		  OSD_OSDATRMD);
 }
 
+static void osd_set_blink_attribute(struct osd_state *sd, int enable,
+				    enum osd_blink_interval blink)
+{
+	struct osd_state *osd = sd;
+	unsigned long flags;
+
+	spin_lock_irqsave(&osd->lock, flags);
+
+	osd->is_blinking = (enable != 0);
+	osd->blink = blink;
+	if (osd->win[WIN_OSD1].lconfig.pixfmt == PIXFMT_OSD_ATTR)
+		_osd_set_blink_attribute(sd, enable, blink);
+
+	spin_unlock_irqrestore(&osd->lock, flags);
+}
+
+static enum osd_rom_clut osd_get_rom_clut(struct osd_state *sd)
+{
+	struct osd_state *osd = sd;
+
+	return osd->rom_clut;
+}
+
 static void _osd_set_rom_clut(struct osd_state *sd,
 			      enum osd_rom_clut rom_clut)
 {
@@ -208,6 +597,150 @@ static void _osd_set_rom_clut(struct osd_state *sd,
 		osd_set(sd, OSD_MISCCTL_RSEL, OSD_MISCCTL);
 }
 
+static void osd_set_rom_clut(struct osd_state *sd,
+			     enum osd_rom_clut rom_clut)
+{
+	struct osd_state *osd = sd;
+	unsigned long flags;
+
+	spin_lock_irqsave(&osd->lock, flags);
+
+	osd->rom_clut = rom_clut;
+	_osd_set_rom_clut(sd, rom_clut);
+
+	spin_unlock_irqrestore(&osd->lock, flags);
+}
+
+static void _osd_set_clut_ycbcr(struct osd_state *sd,
+				unsigned char clut_index,
+				unsigned char y, unsigned char cb,
+				unsigned char cr)
+{
+	/* wait until any previous writes to the CLUT RAM have completed */
+	while (osd_read(sd, OSD_MISCCTL) & OSD_MISCCTL_CPBSY)
+		cpu_relax();
+
+	osd_write(sd, (y << OSD_CLUTRAMYCB_Y_SHIFT) | cb, OSD_CLUTRAMYCB);
+	osd_write(sd, (cr << OSD_CLUTRAMCR_CR_SHIFT) | clut_index,
+		  OSD_CLUTRAMCR);
+}
+
+static void osd_set_clut_ycbcr(struct osd_state *sd,
+			       unsigned char clut_index, unsigned char y,
+			       unsigned char cb, unsigned char cr)
+{
+	struct osd_state *osd = sd;
+	unsigned long flags;
+
+	spin_lock_irqsave(&osd->lock, flags);
+
+	osd->clut_ram[clut_index][0] = y;
+	osd->clut_ram[clut_index][1] = cb;
+	osd->clut_ram[clut_index][2] = cr;
+	_osd_set_clut_ycbcr(sd, clut_index, y, cb, cr);
+
+	spin_unlock_irqrestore(&osd->lock, flags);
+}
+
+static void _osd_rgb_to_ycbcr(const unsigned char rgb[3],
+			      unsigned char ycbcr[3])
+{
+	int y, cb, cr;
+	int r = rgb[0];
+	int g = rgb[1];
+	int b = rgb[2];
+	/*
+	 * This conversion matrix corresponds to the conversion matrix used
+	 * by the OSD to convert RGB values to YCbCr values.  All coefficients
+	 * have been scaled by a factor of 2^22.
+	 */
+	static const int rgb_to_ycbcr[3][3] = {
+		{1250330, 2453618, 490352},
+		{-726093, -1424868, 2150957},
+		{2099836, -1750086, -349759}
+	};
+
+	y = rgb_to_ycbcr[0][0] * r + rgb_to_ycbcr[0][1] * g +
+			rgb_to_ycbcr[0][2] * b;
+	cb = rgb_to_ycbcr[1][0] * r + rgb_to_ycbcr[1][1] * g +
+			rgb_to_ycbcr[1][2] * b;
+	cr = rgb_to_ycbcr[2][0] * r + rgb_to_ycbcr[2][1] * g +
+			rgb_to_ycbcr[2][2] * b;
+
+	/* round and scale */
+	y = ((y + (1 << 21)) >> 22);
+	cb = ((cb + (1 << 21)) >> 22) + 128;
+	cr = ((cr + (1 << 21)) >> 22) + 128;
+
+	/* clip */
+	y = (y < 0) ? 0 : y;
+	y = (y > 255) ? 255 : y;
+	cb = (cb < 0) ? 0 : cb;
+	cb = (cb > 255) ? 255 : cb;
+	cr = (cr < 0) ? 0 : cr;
+	cr = (cr > 255) ? 255 : cr;
+
+	ycbcr[0] = y;
+	ycbcr[1] = cb;
+	ycbcr[2] = cr;
+}
+
+static void osd_set_clut_rgb(struct osd_state *sd, unsigned char clut_index,
+			     unsigned char r, unsigned char g, unsigned char b)
+{
+	struct osd_state *osd = sd;
+	unsigned char rgb[3], ycbcr[3];
+	unsigned long flags;
+
+	rgb[0] = r;
+	rgb[1] = g;
+	rgb[2] = b;
+	_osd_rgb_to_ycbcr(rgb, ycbcr);
+
+	spin_lock_irqsave(&osd->lock, flags);
+
+	osd->clut_ram[clut_index][0] = ycbcr[0];
+	osd->clut_ram[clut_index][1] = ycbcr[1];
+	osd->clut_ram[clut_index][2] = ycbcr[2];
+	_osd_set_clut_ycbcr(sd, clut_index, ycbcr[0], ycbcr[1], ycbcr[2]);
+
+	spin_unlock_irqrestore(&osd->lock, flags);
+}
+
+static unsigned char osd_get_palette_map(struct osd_state *sd,
+					 enum osd_win_layer osdwin,
+					 unsigned char pixel_value)
+{
+	struct osd_state *osd = sd;
+	enum osd_layer layer =
+	    (osdwin == OSDWIN_OSD0) ? WIN_OSD0 : WIN_OSD1;
+	struct osd_window_state *win = &osd->win[layer];
+	struct osd_osdwin_state *osdwin_state = &osd->osdwin[osdwin];
+	unsigned char clut_index;
+	unsigned long flags;
+
+	spin_lock_irqsave(&osd->lock, flags);
+
+	switch (win->lconfig.pixfmt) {
+	case PIXFMT_1BPP:
+		clut_index = osdwin_state->palette_map[pixel_value & 0x1];
+		break;
+	case PIXFMT_2BPP:
+		clut_index = osdwin_state->palette_map[pixel_value & 0x3];
+		break;
+	case PIXFMT_4BPP:
+		clut_index = osdwin_state->palette_map[pixel_value & 0xf];
+		break;
+	default:
+		clut_index = 0;
+		break;
+	}
+
+	spin_unlock_irqrestore(&osd->lock, flags);
+
+	return clut_index;
+}
+
 static void _osd_set_palette_map(struct osd_state *sd,
 				 enum osd_win_layer osdwin,
 				 unsigned char pixel_value,
@@ -257,14 +790,55 @@ static void _osd_set_palette_map(struct osd_state *sd,
 	osd_modify(sd, bmp_mask, clut_index << bmp_shift, bmp_offset);
 }
 
+static void osd_set_palette_map(struct osd_state *sd,
+				enum osd_win_layer osdwin,
+				unsigned char pixel_value,
+				unsigned char clut_index)
+{
+	struct osd_state *osd = sd;
+	enum osd_layer layer =
+	    (osdwin == OSDWIN_OSD0) ? WIN_OSD0 : WIN_OSD1;
+	struct osd_window_state *win = &osd->win[layer];
+	struct osd_osdwin_state *osdwin_state = &osd->osdwin[osdwin];
+	unsigned long flags;
+
+	spin_lock_irqsave(&osd->lock, flags);
+
+	switch (win->lconfig.pixfmt) {
+	case PIXFMT_1BPP:
+		osdwin_state->palette_map[pixel_value & 0x1] = clut_index;
+		break;
+	case PIXFMT_2BPP:
+		osdwin_state->palette_map[pixel_value & 0x3] = clut_index;
+		break;
+	case PIXFMT_4BPP:
+		osdwin_state->palette_map[pixel_value & 0xf] = clut_index;
+		break;
+	default:
+		spin_unlock_irqrestore(&osd->lock, flags);
+		return;
+	}
+
+	_osd_set_palette_map(sd, osdwin, pixel_value, clut_index,
+			     win->lconfig.pixfmt);
+
+	spin_unlock_irqrestore(&osd->lock, flags);
+}
+
+static int osd_get_rec601_attenuation(struct osd_state *sd,
+				      enum osd_win_layer osdwin)
+{
+	struct osd_state *osd = sd;
+	struct osd_osdwin_state *osdwin_state = &osd->osdwin[osdwin];
+
+	return osdwin_state->rec601_attenuation;
+}
+
 static void _osd_set_rec601_attenuation(struct osd_state *sd,
 					enum osd_win_layer osdwin, int enable)
 {
 	switch (osdwin) {
 	case OSDWIN_OSD0:
-		osd_modify(sd, OSD_OSDWIN0MD_ATN0E,
-			  enable ? OSD_OSDWIN0MD_ATN0E : 0,
-			  OSD_OSDWIN0MD);
 		if (sd->vpbe_type == VPBE_VERSION_1)
 			osd_modify(sd, OSD_OSDWIN0MD_ATN0E,
 				  enable ? OSD_OSDWIN0MD_ATN0E : 0,
@@ -276,9 +850,6 @@ static void _osd_set_rec601_attenuation(struct osd_state *sd,
 				  OSD_EXTMODE);
 		break;
 	case OSDWIN_OSD1:
-		osd_modify(sd, OSD_OSDWIN1MD_ATN1E,
-			  enable ? OSD_OSDWIN1MD_ATN1E : 0,
-			  OSD_OSDWIN1MD);
 		if (sd->vpbe_type == VPBE_VERSION_1)
 			osd_modify(sd, OSD_OSDWIN1MD_ATN1E,
 				  enable ? OSD_OSDWIN1MD_ATN1E : 0,
@@ -292,6 +863,35 @@ static void _osd_set_rec601_attenuation(struct osd_state *sd,
 	}
 }
 
+static void osd_set_rec601_attenuation(struct osd_state *sd,
+				       enum osd_win_layer osdwin,
+				       int enable)
+{
+	struct osd_state *osd = sd;
+	enum osd_layer layer =
+	    (osdwin == OSDWIN_OSD0) ? WIN_OSD0 : WIN_OSD1;
+	struct osd_window_state *win = &osd->win[layer];
+	struct osd_osdwin_state *osdwin_state = &osd->osdwin[osdwin];
+	unsigned long flags;
+
+	spin_lock_irqsave(&osd->lock, flags);
+
+	osdwin_state->rec601_attenuation = (enable != 0);
+	if (win->lconfig.pixfmt != PIXFMT_OSD_ATTR)
+		_osd_set_rec601_attenuation(sd, osdwin, enable);
+
+	spin_unlock_irqrestore(&osd->lock, flags);
+}
+
+static enum osd_blending_factor
+osd_get_blending_factor(struct osd_state *sd, enum osd_win_layer osdwin)
+{
+	struct osd_state *osd = sd;
+	struct osd_osdwin_state *osdwin_state = &osd->osdwin[osdwin];
+
+	return osdwin_state->blend;
+}
+
 static void _osd_set_blending_factor(struct osd_state *sd,
 				     enum osd_win_layer osdwin,
 				     enum osd_blending_factor blend)
@@ -308,6 +908,25 @@ static void _osd_set_blending_factor(struct osd_state *sd,
 	}
 }
 
+static void osd_set_blending_factor(struct osd_state *sd,
+				    enum osd_win_layer osdwin,
+				    enum osd_blending_factor blend)
+{
+	struct osd_state *osd = sd;
+	enum osd_layer layer =
+	    (osdwin == OSDWIN_OSD0) ? WIN_OSD0 : WIN_OSD1;
+	struct osd_window_state *win = &osd->win[layer];
+	struct osd_osdwin_state *osdwin_state = &osd->osdwin[osdwin];
+	unsigned long flags;
+
+	spin_lock_irqsave(&osd->lock, flags);
+
+	osdwin_state->blend = blend;
+	if (win->lconfig.pixfmt != PIXFMT_OSD_ATTR)
+		_osd_set_blending_factor(sd, osdwin, blend);
+	spin_unlock_irqrestore(&osd->lock, flags);
+}
+
 static void _osd_enable_rgb888_pixblend(struct osd_state *sd,
 					enum osd_win_layer osdwin)
 {
@@ -388,6 +1007,28 @@ static void _osd_enable_color_key(struct osd_state *sd,
 	}
 }
 
+static void osd_enable_color_key(struct osd_state *sd,
+				 enum osd_win_layer osdwin,
+				 unsigned colorkey)
+{
+	struct osd_state *osd = sd;
+	enum osd_layer layer =
+	    (osdwin == OSDWIN_OSD0) ? WIN_OSD0 : WIN_OSD1;
+	struct osd_window_state *win = &osd->win[layer];
+	struct osd_osdwin_state *osdwin_state = &osd->osdwin[osdwin];
+	unsigned long flags;
+
+	spin_lock_irqsave(&osd->lock, flags);
+
+	osdwin_state->colorkey_blending = 1;
+	osdwin_state->colorkey = colorkey;
+	if (win->lconfig.pixfmt != PIXFMT_OSD_ATTR)
+		_osd_enable_color_key(sd, osdwin, colorkey,
+				      win->lconfig.pixfmt);
+
+	spin_unlock_irqrestore(&osd->lock, flags);
+}
+
 static void _osd_disable_color_key(struct osd_state *sd,
 				   enum osd_win_layer osdwin)
 {
@@ -421,6 +1062,69 @@ static void _osd_set_osd_clut(struct osd_state *sd,
 	}
 }
 
+static void osd_disable_color_key(struct osd_state *sd,
+				  enum osd_win_layer osdwin)
+{
+	struct osd_state *osd = sd;
+	enum osd_layer layer =
+	    (osdwin == OSDWIN_OSD0) ? WIN_OSD0 : WIN_OSD1;
+	struct osd_window_state *win = &osd->win[layer];
+	struct osd_osdwin_state *osdwin_state = &osd->osdwin[osdwin];
+	unsigned long flags;
+
+	spin_lock_irqsave(&osd->lock, flags);
+
+	osdwin_state->colorkey_blending = 0;
+	if (win->lconfig.pixfmt != PIXFMT_OSD_ATTR)
+		_osd_disable_color_key(sd, osdwin);
+
+	spin_unlock_irqrestore(&osd->lock, flags);
+}
+
+static void osd_set_osd_clut(struct osd_state *sd, enum osd_win_layer osdwin,
+			     enum osd_clut clut)
+{
+	struct osd_state *osd = sd;
+	enum osd_layer layer =
+	    (osdwin == OSDWIN_OSD0) ? WIN_OSD0 : WIN_OSD1;
+	struct osd_window_state *win = &osd->win[layer];
+	struct osd_osdwin_state *osdwin_state = &osd->osdwin[osdwin];
+	unsigned long flags;
+
+	spin_lock_irqsave(&osd->lock, flags);
+
+	osdwin_state->clut = clut;
+	if (win->lconfig.pixfmt != PIXFMT_OSD_ATTR)
+		_osd_set_osd_clut(sd, osdwin, clut);
+
+	spin_unlock_irqrestore(&osd->lock, flags);
+}
+
+static enum osd_clut osd_get_osd_clut(struct osd_state *sd,
+				      enum osd_win_layer osdwin)
+{
+	struct osd_state *osd = sd;
+	struct osd_osdwin_state *osdwin_state = &osd->osdwin[osdwin];
+
+	return osdwin_state->clut;
+}
+
+static void osd_get_zoom(struct osd_state *sd, enum osd_layer layer,
+			 enum osd_zoom_factor *h_zoom,
+			 enum osd_zoom_factor *v_zoom)
+{
+	struct osd_state *osd = sd;
+	struct osd_window_state *win = &osd->win[layer];
+	unsigned long flags;
+
+	spin_lock_irqsave(&osd->lock, flags);
+
+	*h_zoom = win->h_zoom;
+	*v_zoom = win->v_zoom;
+
+	spin_unlock_irqrestore(&osd->lock, flags);
+}
+
 static void _osd_set_zoom(struct osd_state *sd, enum osd_layer layer,
 			  enum osd_zoom_factor h_zoom,
 			  enum osd_zoom_factor v_zoom)
@@ -454,6 +1158,31 @@ static void _osd_set_zoom(struct osd_state *sd, enum osd_layer layer,
 		break;
 	}
 }
+static void osd_set_zoom(struct osd_state *sd, enum osd_layer layer,
+			 enum osd_zoom_factor h_zoom,
+			 enum osd_zoom_factor v_zoom)
+{
+	struct osd_state *osd = sd;
+	struct osd_window_state *win = &osd->win[layer];
+	unsigned long flags;
+
+	spin_lock_irqsave(&osd->lock, flags);
+
+	win->h_zoom = h_zoom;
+	win->v_zoom = v_zoom;
+	_osd_set_zoom(sd, layer, h_zoom, v_zoom);
+
+	spin_unlock_irqrestore(&osd->lock, flags);
+}
+
+
+static int osd_layer_is_enabled(struct osd_state *sd, enum osd_layer layer)
+{
+	struct osd_state *osd = sd;
+	struct osd_window_state *win = &osd->win[layer];
+
+	return win->is_enabled;
+}
 
 static void _osd_disable_layer(struct osd_state *sd, enum osd_layer layer)
 {
@@ -497,7 +1226,7 @@ static void osd_disable_layer(struct osd_state *sd, enum osd_layer layer)
 static void _osd_enable_attribute_mode(struct osd_state *sd)
 {
 	/* enable attribute mode for OSD1 */
-	osd_set(sd, OSD_OSDWIN1MD_OASW, OSD_OSDWIN1MD);
+	osd_set(sd, OSD_OSDWIN1MD_OASW | OSD_OSDWIN1MD_OACT1, OSD_OSDWIN1MD);
 }
 
 static void _osd_enable_layer(struct osd_state *sd, enum osd_layer layer)
@@ -811,7 +1540,7 @@ static int try_layer_config(struct osd_state *sd, enum osd_layer layer,
 	case PIXFMT_8BPP:
 	case PIXFMT_RGB565:
 		if (osd->vpbe_type == VPBE_VERSION_1)
-			bad_config = !is_vid_win(layer);
+			bad_config = !is_osd_win(layer);
 		break;
 	case PIXFMT_YCBCRI:
 	case PIXFMT_YCRCBI:
@@ -910,6 +1639,22 @@ static int try_layer_config(struct osd_state *sd, enum osd_layer layer,
 	return 0;
 }
 
+static int osd_try_layer_config(struct osd_state *sd, enum osd_layer layer,
+				struct osd_layer_config *lconfig)
+{
+	struct osd_state *osd = sd;
+	int reject_config;
+	unsigned long flags;
+
+	spin_lock_irqsave(&osd->lock, flags);
+
+	reject_config = try_layer_config(sd, layer, lconfig);
+
+	spin_unlock_irqrestore(&osd->lock, flags);
+
+	return reject_config;
+}
+
 static void _osd_disable_vid_rgb888(struct osd_state *sd)
 {
 	/*
@@ -1530,16 +2275,51 @@ static int osd_initialize(struct osd_state *osd)
 }
 
 static const struct vpbe_osd_ops osd_ops = {
+	.set_clut_ycbcr = osd_set_clut_ycbcr,
+	.set_clut_rgb = osd_set_clut_rgb,
+	.set_osd_clut = osd_set_osd_clut,
+	.get_osd_clut = osd_get_osd_clut,
+	.enable_color_key = osd_enable_color_key,
+	.disable_color_key = osd_disable_color_key,
+	.set_blending_factor = osd_set_blending_factor,
+	.get_blending_factor = osd_get_blending_factor,
+	.set_rec601_attenuation = osd_set_rec601_attenuation,
+	.get_rec601_attenuation = osd_get_rec601_attenuation,
+	.set_palette_map = osd_set_palette_map,
+	.get_palette_map = osd_get_palette_map,
+	.set_blink_attribute = osd_set_blink_attribute,
+	.get_blink_attribute = osd_get_blink_attribute,
+	.cursor_enable = osd_cursor_enable,
+	.cursor_disable = osd_cursor_disable,
+	.cursor_is_enabled = osd_cursor_is_enabled,
+	.set_cursor_config = osd_set_cursor_config,
+	.get_cursor_config = osd_get_cursor_config,
+	.set_field_inversion = osd_set_field_inversion,
+	.get_field_inversion = osd_get_field_inversion,
 	.initialize = osd_initialize,
 	.request_layer = osd_request_layer,
 	.release_layer = osd_release_layer,
 	.enable_layer = osd_enable_layer,
 	.disable_layer = osd_disable_layer,
+	.layer_is_enabled = osd_layer_is_enabled,
 	.set_layer_config = osd_set_layer_config,
+	.try_layer_config = osd_try_layer_config,
 	.get_layer_config = osd_get_layer_config,
 	.start_layer = osd_start_layer,
 	.set_left_margin = osd_set_left_margin,
 	.set_top_margin = osd_set_top_margin,
+	.set_interpolation_filter = osd_set_interpolation_filter,
+	.get_interpolation_filter = osd_get_interpolation_filter,
+	.set_osd_expansion = osd_set_osd_expansion,
+	.get_osd_expansion = osd_get_osd_expansion,
+	.set_vid_expansion = osd_set_vid_expansion,
+	.get_vid_expansion = osd_get_vid_expansion,
+	.set_zoom = osd_set_zoom,
+	.get_zoom = osd_get_zoom,
+	.set_background = osd_set_background,
+	.get_background = osd_get_background,
+	.set_rom_clut = osd_set_rom_clut,
+	.get_rom_clut = osd_get_rom_clut,
 };
 
 static int osd_probe(struct platform_device *pdev)
diff --git a/drivers/media/platform/davinci/vpbe_venc.c b/drivers/media/platform/davinci/vpbe_venc.c
index 87eef9b..787a3ca 100644
--- a/drivers/media/platform/davinci/vpbe_venc.c
+++ b/drivers/media/platform/davinci/vpbe_venc.c
@@ -24,6 +24,7 @@
 #include <linux/platform_device.h>
 #include <linux/videodev2.h>
 #include <linux/slab.h>
+#include <linux/v4l2-dv-timings.h>
 
 #include <mach/hardware.h>
 #include <mach/mux.h>
@@ -31,6 +32,7 @@
 
 #include <linux/io.h>
 
+#include <media/v4l2-mediabus.h>
 #include <media/davinci/vpbe_types.h>
 #include <media/davinci/vpbe_venc.h>
 #include <media/davinci/vpss.h>
@@ -66,6 +68,7 @@ struct venc_state {
 	struct v4l2_subdev sd;
 	struct venc_callback *callback;
 	struct venc_platform_data *pdata;
+	enum v4l2_mbus_pixelcode if_params;
 	struct device *pdev;
 	u32 output;
 	v4l2_std_id std;
@@ -539,6 +542,10 @@ static long venc_ioctl(struct v4l2_subdev *sd,
 			unsigned int cmd,
 			void *arg)
 {
+	struct venc_callback *next, *prev, *callback;
+	struct venc_state *venc = to_state(sd);
+	unsigned long flags;
+	unsigned event = 0;
 	u32 val;
 
 	switch (cmd) {
@@ -547,6 +554,42 @@ static long venc_ioctl(struct v4l2_subdev *sd,
 		*((int *)arg) = ((val & VENC_VSTAT_FIDST) ==
 		VENC_VSTAT_FIDST);
 		break;
+	case VENC_REG_CALLBACK:
+		spin_lock_irqsave(&venc->lock, flags);
+		callback = (struct venc_callback *)arg;
+		next = venc->callback;
+		venc->callback = callback;
+		callback->next = next;
+		spin_unlock_irqrestore(&venc->lock, flags);
+		break;
+	case VENC_UNREG_CALLBACK:
+		spin_lock_irqsave(&venc->lock, flags);
+		callback = (struct venc_callback *)arg;
+		prev = venc->callback;
+		if (!prev)
+			return -EINVAL;
+
+		if (prev == callback) {
+			venc->callback = callback->next;
+		} else {
+			while (prev->next && (prev->next != callback))
+				prev = prev->next;
+			if (!prev->next)
+				return -EINVAL;
+			else
+				prev->next = callback->next;
+		}
+		spin_unlock_irqrestore(&venc->lock, flags);
+		break;
+	case VENC_INTERRUPT:
+		callback = venc->callback;
+		event = *((unsigned *)arg);
+		while (callback) {
+			if (callback->mask & event)
+				callback->handler(event, callback->arg);
+		callback = callback->next;
+		}
+		break;
 	default:
 		v4l2_err(sd, "Wrong IOCTL cmd\n");
 		break;
diff --git a/include/media/davinci/vpbe_osd.h b/include/media/davinci/vpbe_osd.h
index de59364..3df34c6 100644
--- a/include/media/davinci/vpbe_osd.h
+++ b/include/media/davinci/vpbe_osd.h
@@ -327,14 +327,59 @@ struct osd_cursor_state {
 struct osd_state;
 
 struct vpbe_osd_ops {
+	void (*set_clut_ycbcr)(struct osd_state *sd,
+			       unsigned char clut_index, unsigned char y,
+			       unsigned char cb, unsigned char cr);
+	void (*set_clut_rgb)(struct osd_state *sd, unsigned char clut_index,
+			     unsigned char r, unsigned char g,
+			     unsigned char b);
+	void (*set_osd_clut)(struct osd_state *sd, enum osd_win_layer osdwin,
+			     enum osd_clut clut);
+	enum osd_clut (*get_osd_clut)(struct osd_state *sd,
+				      enum osd_win_layer osdwin);
+	void (*enable_color_key)(struct osd_state *sd,
+				 enum osd_win_layer osdwin, unsigned colorkey);
+	void (*disable_color_key)(struct osd_state *sd,
+				  enum osd_win_layer osdwin);
+	void (*set_blending_factor)(struct osd_state *sd,
+				    enum osd_win_layer osdwin,
+				    enum osd_blending_factor blend);
+	enum osd_blending_factor (*get_blending_factor)(struct osd_state *sd,
+				  enum osd_win_layer osdwin);
+	void (*set_rec601_attenuation)(struct osd_state *sd,
+				  enum osd_win_layer osdwin, int enable);
+	int (*get_rec601_attenuation)(struct osd_state *sd,
+				  enum osd_win_layer osdwin);
+	void (*set_palette_map)(struct osd_state *sd,
+				enum osd_win_layer osdwin,
+				unsigned char pixel_value,
+				unsigned char clut_index);
+	unsigned char (*get_palette_map)(struct osd_state *sd,
+			enum osd_win_layer osdwin, unsigned char pixel_value);
+	void (*set_blink_attribute)(struct osd_state *sd, int enable,
+				    enum osd_blink_interval blink);
+	void (*get_blink_attribute)(struct osd_state *sd, int *enable,
+				    enum osd_blink_interval *blink);
+	void (*cursor_enable)(struct osd_state *sd);
+	void (*cursor_disable)(struct osd_state *sd);
+	int (*cursor_is_enabled)(struct osd_state *sd);
+	void (*set_cursor_config)(struct osd_state *sd,
+			  struct osd_cursor_config *cursor);
+	void (*get_cursor_config)(struct osd_state *sd,
+			  struct osd_cursor_config *cursor);
+	void (*set_field_inversion)(struct osd_state *sd, int enable);
+	int (*get_field_inversion)(struct osd_state *sd);
 	int (*initialize)(struct osd_state *sd);
 	int (*request_layer)(struct osd_state *sd, enum osd_layer layer);
 	void (*release_layer)(struct osd_state *sd, enum osd_layer layer);
 	int (*enable_layer)(struct osd_state *sd, enum osd_layer layer,
 			    int otherwin);
 	void (*disable_layer)(struct osd_state *sd, enum osd_layer layer);
+	int (*layer_is_enabled)(struct osd_state *sd, enum osd_layer layer);
 	int (*set_layer_config)(struct osd_state *sd, enum osd_layer layer,
 				struct osd_layer_config *lconfig);
+	int (*try_layer_config)(struct osd_state *sd, enum osd_layer layer,
+				struct osd_layer_config *lconfig);
 	void (*get_layer_config)(struct osd_state *sd, enum osd_layer layer,
 				 struct osd_layer_config *lconfig);
 	void (*start_layer)(struct osd_state *sd, enum osd_layer layer,
@@ -343,6 +388,13 @@ struct vpbe_osd_ops {
 	void (*set_left_margin)(struct osd_state *sd, u32 val);
 	void (*set_top_margin)(struct osd_state *sd, u32 val);
 	void (*set_interpolation_filter)(struct osd_state *sd, int filter);
+	int (*get_interpolation_filter)(struct osd_state *sd);
+	int (*set_osd_expansion)(struct osd_state *sd,
+				 enum osd_h_exp_ratio h_exp,
+				 enum osd_v_exp_ratio v_exp);
+	void (*get_osd_expansion)(struct osd_state *sd,
+				  enum osd_h_exp_ratio *h_exp,
+				  enum osd_v_exp_ratio *v_exp);
 	int (*set_vid_expansion)(struct osd_state *sd,
 					enum osd_h_exp_ratio h_exp,
 					enum osd_v_exp_ratio v_exp);
@@ -352,6 +404,16 @@ struct vpbe_osd_ops {
 	void (*set_zoom)(struct osd_state *sd, enum osd_layer layer,
 				enum osd_zoom_factor h_zoom,
 				enum osd_zoom_factor v_zoom);
+	void (*get_zoom)(struct osd_state *sd, enum osd_layer layer,
+			 enum osd_zoom_factor *h_zoom,
+			 enum osd_zoom_factor *v_zoom);
+	void (*set_background)(struct osd_state *sd, enum osd_clut clut,
+			       unsigned char clut_index);
+	void (*get_background)(struct osd_state *sd, enum osd_clut *clut,
+			      unsigned char *clut_index);
+	void (*set_rom_clut)(struct osd_state *sd,
+			     enum osd_rom_clut rom_clut);
+	enum osd_rom_clut (*get_rom_clut)(struct osd_state *sd);
 };
 
 struct osd_state {
diff --git a/include/media/davinci/vpbe_venc.h b/include/media/davinci/vpbe_venc.h
index 476fafc..98d73a9 100644
--- a/include/media/davinci/vpbe_venc.h
+++ b/include/media/davinci/vpbe_venc.h
@@ -29,6 +29,24 @@
 #define VENC_FIRST_FIELD	BIT(1)
 #define VENC_SECOND_FIELD	BIT(2)
 
+/**
+ * struct venc_callback
+ * @next: used internally by the venc driver to maintain a linked list of
+ *        callbacks
+ * @mask: a bitmask specifying the venc event(s) for which the
+ *        callback will be invoked
+ * @handler: the callback routine
+ * @arg: a null pointer that is passed as the second argument to the callback
+ *       routine
+ */
+struct venc_callback {
+	struct venc_callback *next;
+	char *owner;
+	unsigned mask;
+	void (*handler) (unsigned event, void *arg);
+	void *arg;
+};
+
 struct venc_platform_data {
 	int (*setup_pinmux)(enum v4l2_mbus_pixelcode if_type,
 			    int field);
@@ -42,6 +60,9 @@ struct venc_platform_data {
 
 enum venc_ioctls {
 	VENC_GET_FLD = 1,
+	VENC_REG_CALLBACK,
+	VENC_UNREG_CALLBACK,
+	VENC_INTERRUPT,
 };
 
 /* exported functions */
-- 
1.7.4.1



From prabhakar.csengg at gmail.com  Wed Apr 24 08:00:06 2013
From: prabhakar.csengg at gmail.com (Prabhakar Lad)
Date: Wed, 24 Apr 2013 17:30:06 +0530
Subject: [PATCH 4/6] ARM: davinci: dm355: enable fbdev driver
In-Reply-To: <1366804808-22720-1-git-send-email-prabhakar.csengg@gmail.com>
References: <1366804808-22720-1-git-send-email-prabhakar.csengg@gmail.com>
Message-ID: <1366804808-22720-5-git-send-email-prabhakar.csengg@gmail.com>

From: Lad, Prabhakar <prabhakar.csengg at gmail.com>

This patch enables fbdev driver by creating fbdev device and register it.
Alongside renames 'vpfe_capture_dma_mask' to 'dm355_video_dma_mask' for better
clarity since it was reused by capture and diplay aswell.

Signed-off-by: Lad, Prabhakar <prabhakar.csengg at gmail.com>
---
 arch/arm/mach-davinci/dm355.c |   24 +++++++++++++++++-------
 1 files changed, 17 insertions(+), 7 deletions(-)

diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index bf9a9d4..fe50814 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -714,7 +714,7 @@ static struct resource vpfe_resources[] = {
 	},
 };
 
-static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32);
+static u64 dm355_video_dma_mask = DMA_BIT_MASK(32);
 static struct resource dm355_ccdc_resource[] = {
 	/* CCDC Base address */
 	{
@@ -729,7 +729,7 @@ static struct platform_device dm355_ccdc_dev = {
 	.num_resources  = ARRAY_SIZE(dm355_ccdc_resource),
 	.resource       = dm355_ccdc_resource,
 	.dev = {
-		.dma_mask               = &vpfe_capture_dma_mask,
+		.dma_mask               = &dm355_video_dma_mask,
 		.coherent_dma_mask      = DMA_BIT_MASK(32),
 		.platform_data		= dm355_ccdc_setup_pinmux,
 	},
@@ -741,7 +741,7 @@ static struct platform_device vpfe_capture_dev = {
 	.num_resources	= ARRAY_SIZE(vpfe_resources),
 	.resource	= vpfe_resources,
 	.dev = {
-		.dma_mask		= &vpfe_capture_dma_mask,
+		.dma_mask		= &dm355_video_dma_mask,
 		.coherent_dma_mask	= DMA_BIT_MASK(32),
 	},
 };
@@ -760,7 +760,7 @@ static struct platform_device dm355_osd_dev = {
 	.num_resources	= ARRAY_SIZE(dm355_osd_resources),
 	.resource	= dm355_osd_resources,
 	.dev		= {
-		.dma_mask		= &vpfe_capture_dma_mask,
+		.dma_mask		= &dm355_video_dma_mask,
 		.coherent_dma_mask	= DMA_BIT_MASK(32),
 	},
 };
@@ -855,7 +855,16 @@ static struct platform_device dm355_vpbe_display = {
 	.num_resources	= ARRAY_SIZE(dm355_v4l2_disp_resources),
 	.resource	= dm355_v4l2_disp_resources,
 	.dev		= {
-		.dma_mask		= &vpfe_capture_dma_mask,
+		.dma_mask		= &dm355_video_dma_mask,
+		.coherent_dma_mask	= DMA_BIT_MASK(32),
+	},
+};
+
+static struct platform_device dm355_davincifb = {
+	.name		= "davinci-vpbe-fb",
+	.id		= -1,
+	.dev		= {
+		.dma_mask		= &dm355_video_dma_mask,
 		.coherent_dma_mask	= DMA_BIT_MASK(32),
 	},
 };
@@ -871,7 +880,7 @@ static struct platform_device dm355_venc_dev = {
 	.num_resources	= ARRAY_SIZE(dm355_venc_resources),
 	.resource	= dm355_venc_resources,
 	.dev		= {
-		.dma_mask		= &vpfe_capture_dma_mask,
+		.dma_mask		= &dm355_video_dma_mask,
 		.coherent_dma_mask	= DMA_BIT_MASK(32),
 		.platform_data		= (void *)&dm355_venc_pdata,
 	},
@@ -881,7 +890,7 @@ static struct platform_device dm355_vpbe_dev = {
 	.name		= "vpbe_controller",
 	.id		= -1,
 	.dev		= {
-		.dma_mask		= &vpfe_capture_dma_mask,
+		.dma_mask		= &dm355_video_dma_mask,
 		.coherent_dma_mask	= DMA_BIT_MASK(32),
 	},
 };
@@ -1023,6 +1032,7 @@ int __init dm355_init_video(struct vpfe_config *vpfe_cfg,
 		platform_device_register(&dm355_venc_dev);
 		platform_device_register(&dm355_vpbe_dev);
 		platform_device_register(&dm355_vpbe_display);
+		platform_device_register(&dm355_davincifb);
 	}
 
 	return 0;
-- 
1.7.4.1



From prabhakar.csengg at gmail.com  Wed Apr 24 08:00:07 2013
From: prabhakar.csengg at gmail.com (Prabhakar Lad)
Date: Wed, 24 Apr 2013 17:30:07 +0530
Subject: [PATCH 5/6] ARM: davinci: dm365: enable fbdev driver
In-Reply-To: <1366804808-22720-1-git-send-email-prabhakar.csengg@gmail.com>
References: <1366804808-22720-1-git-send-email-prabhakar.csengg@gmail.com>
Message-ID: <1366804808-22720-6-git-send-email-prabhakar.csengg@gmail.com>

From: Lad, Prabhakar <prabhakar.csengg at gmail.com>

This patch enables fbdev driver by creating fbdev device and register it.

Signed-off-by: Lad, Prabhakar <prabhakar.csengg at gmail.com>
---
 arch/arm/mach-davinci/dm365.c |   10 ++++++++++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index ff771ce..b06623c 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -1349,6 +1349,15 @@ static struct platform_device dm365_vpbe_display = {
 	},
 };
 
+static struct platform_device dm365_davincifb = {
+	.name           = "davinci-vpbe-fb",
+	.id             = -1,
+	.dev            = {
+		.dma_mask		= &dm365_video_dma_mask,
+		.coherent_dma_mask	= DMA_BIT_MASK(32),
+	},
+};
+
 struct venc_platform_data dm365_venc_pdata = {
 	.setup_pinmux	= dm365_vpbe_setup_pinmux,
 	.setup_clock	= dm365_venc_setup_clock,
@@ -1392,6 +1401,7 @@ int __init dm365_init_video(struct vpfe_config *vpfe_cfg,
 		platform_device_register(&dm365_venc_dev);
 		platform_device_register(&dm365_vpbe_dev);
 		platform_device_register(&dm365_vpbe_display);
+		platform_device_register(&dm365_davincifb);
 	}
 
 	return 0;
-- 
1.7.4.1



From prabhakar.csengg at gmail.com  Wed Apr 24 08:00:05 2013
From: prabhakar.csengg at gmail.com (Prabhakar Lad)
Date: Wed, 24 Apr 2013 17:30:05 +0530
Subject: [PATCH 3/6] davinci: vpbe: add fbdev driver
In-Reply-To: <1366804808-22720-1-git-send-email-prabhakar.csengg@gmail.com>
References: <1366804808-22720-1-git-send-email-prabhakar.csengg@gmail.com>
Message-ID: <1366804808-22720-4-git-send-email-prabhakar.csengg@gmail.com>

From: Lad, Prabhakar <prabhakar.csengg at gmail.com>

add the fbdev driver for DMX which uses an OSD layer
with RGB565/RGB888 support and an attribute window which can
also be doubled as another RGB565 window. The fbdev supports
fb0 and fb2 for  OSD0 and OSD1, and also supports video windows
with fb1 and fb3.

Signed-off-by: Lad, Prabhakar <prabhakar.csengg at gmail.com>
---
 drivers/video/Kconfig     |   12 +
 drivers/video/Makefile    |    1 +
 drivers/video/davincifb.c | 2523 +++++++++++++++++++++++++++++++++++++++++++++
 drivers/video/davincifb.h |  194 ++++
 4 files changed, 2730 insertions(+), 0 deletions(-)
 create mode 100644 drivers/video/davincifb.c
 create mode 100644 drivers/video/davincifb.h

diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 4c1546f..fa264a3 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -2451,6 +2451,18 @@ config FB_PUV3_UNIGFX
 	  Choose this option if you want to use the Unigfx device as a
 	  framebuffer device. Without the support of PCI & AGP.
 
+config FB_DAVINCI_DMX
+	tristate "Davinci Framebuffer driver"
+	depends on FB && ARCH_DAVINCI
+	select VIDEO_DMXXX_VPBE
+	select FB_CFB_FILLRECT
+	select FB_CFB_COPYAREA
+	select FB_CFB_IMAGEBLIT
+	help
+		Enables Davinci Framebuffer driver on a DMX device
+		To compile this driver as a module, choose M here: the
+		module will be called vpbe_fb.
+
 source "drivers/video/omap/Kconfig"
 source "drivers/video/omap2/Kconfig"
 source "drivers/video/exynos/Kconfig"
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 9df3873..bf4f5f2 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -165,6 +165,7 @@ obj-$(CONFIG_FB_MX3)		  += mx3fb.o
 obj-$(CONFIG_FB_DA8XX)		  += da8xx-fb.o
 obj-$(CONFIG_FB_MXS)		  += mxsfb.o
 obj-$(CONFIG_FB_SSD1307)	  += ssd1307fb.o
+obj-$(CONFIG_FB_DAVINCI_DMX)	  += davincifb.o
 
 # the test framebuffer is last
 obj-$(CONFIG_FB_VIRTUAL)          += vfb.o
diff --git a/drivers/video/davincifb.c b/drivers/video/davincifb.c
new file mode 100644
index 0000000..59b6cf7
--- /dev/null
+++ b/drivers/video/davincifb.c
@@ -0,0 +1,2523 @@
+/*
+ * Copyright (C) 2007 MontaVista Software Inc.
+ * Copyright (C) 2013 Texas Instruments Inc
+ *
+ * Andy Lowe (alowe at mvista.com), MontaVista Software
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option)any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include <linux/fb.h>
+#include <linux/dma-mapping.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+
+#include <mach/cputype.h>
+
+#include <media/davinci/vpbe.h>
+#include <media/davinci/vpbe_types.h>
+#include <media/v4l2-subdev.h>
+
+#include "davincifb.h"
+
+static struct osd_state *osd_device;
+
+/* return non-zero if the info structure corresponds to OSD0 or OSD1 */
+static int is_osd_win(const struct fb_info *info)
+{
+	const struct vpbe_dm_win_info *win = info->par;
+
+	if (win->layer == WIN_OSD0 || win->layer == WIN_OSD1)
+		return 1;
+	return 0;
+}
+
+/* return non-zero if the info structure corresponds to VID0 or VID1 */
+#define is_vid_win(info) (!is_osd_win(info))
+
+/*
+ * Convert a framebuffer info pointer to a osd_layer enumeration.
+ * It is up to the caller to verify that the info structure corresponds to
+ * either OSD0 or OSD1.
+ */
+static enum osd_layer fb_info_to_osd_enum(const struct fb_info *info)
+{
+	const struct vpbe_dm_win_info *win = info->par;
+
+	if (win->layer == WIN_OSD1)
+		return OSDWIN_OSD1;
+	return OSDWIN_OSD0;
+}
+
+/* macros for testing fb_var_screeninfo attributes */
+#define is_attribute_mode(var) (((var)->bits_per_pixel == 4) && \
+	((var)->nonstd != 0))
+#define is_yuv(var) ((((var)->bits_per_pixel == 16) || \
+	((var)->bits_per_pixel == 8)) && \
+	((var)->nonstd != 0))
+#define is_window_interlaced(var) (((var)->vmode & FB_VMODE_INTERLACED) \
+	== FB_VMODE_INTERLACED)
+
+/* macros for testing fb_videomode attributes */
+#define is_display_interlaced(mode) (((mode)->vmode & FB_VMODE_INTERLACED) \
+	== FB_VMODE_INTERLACED)
+
+static unsigned int fb_cbcr_ofst;
+
+/*
+ * Convert an fb_var_screeninfo struct to a Davinci display layer configuration.
+ * lconfig->xpos, lconfig->ypos, and lconfig->line_length are not modified
+ * because no information about them is contained in var.
+ * The value of the yc_pixfmt argument is returned in lconfig->pixfmt if a
+ * the var specifies a YC pixel format.  The value of yc_pixfmt must be either
+ * PIXFMT_YCBCRI or PIXFMT_YCRCBI.
+ */
+static void convert_fb_var_to_osd(const struct fb_var_screeninfo *var,
+				  struct osd_layer_config *lconfig,
+				  enum osd_pix_format yc_pixfmt)
+{
+	lconfig->xsize = var->xres;
+	lconfig->ysize = var->yres;
+	lconfig->interlaced = is_window_interlaced(var);
+
+	switch (var->bits_per_pixel) {
+	case 1:
+		lconfig->pixfmt = PIXFMT_1BPP;
+		break;
+	case 2:
+		lconfig->pixfmt = PIXFMT_2BPP;
+		break;
+	case 4:
+		if (is_attribute_mode(var))
+			lconfig->pixfmt = PIXFMT_OSD_ATTR;
+		else
+			lconfig->pixfmt = PIXFMT_4BPP;
+		break;
+	case 8:
+		if (is_yuv(var))
+			lconfig->pixfmt = PIXFMT_NV12;
+		else
+			lconfig->pixfmt = PIXFMT_8BPP;
+		break;
+	case 16:
+	default:
+		if (is_yuv(var))
+			lconfig->pixfmt = yc_pixfmt;
+		else
+			lconfig->pixfmt = PIXFMT_RGB565;
+		break;
+	case 24:
+	case 32:
+		lconfig->pixfmt = PIXFMT_RGB888;
+		break;
+	}
+}
+
+/*
+ * Convert an fb_info struct to a OSD display layer configuration.
+ */
+static void convert_fb_info_to_osd(const struct fb_info *info,
+				   struct osd_layer_config *lconfig)
+{
+	const struct vpbe_dm_win_info *win = info->par;
+
+	lconfig->line_length = info->fix.line_length;
+	lconfig->xpos = win->xpos;
+	lconfig->ypos = win->ypos;
+	convert_fb_var_to_osd(&info->var, lconfig, win->dm->yc_pixfmt);
+}
+
+/*
+ * Convert a OSD display layer configuration to var info.
+ * The following members of var are not modified:
+ *	var->xres_virtual
+ *	var->yres_virtual
+ *	var->xoffset
+ *	var->yoffset
+ *	var->pixclock
+ *	var->left_margin
+ *	var->right_margin
+ *	var->upper_margin
+ *	var->lower_margin
+ *	var->hsync_len
+ *	var->vsync_len
+ *	var->sync
+ * Only bit 0 of var->vmode (FB_VMODE_INTERLACED) is modified.  All other bits
+ * of var->vmode are retained.
+ */
+static void convert_osd_to_fb_var(const struct osd_layer_config *lconfig,
+				  struct fb_var_screeninfo *var)
+{
+	var->xres = lconfig->xsize;
+	var->yres = lconfig->ysize;
+	if (lconfig->interlaced)
+		var->vmode |= FB_VMODE_INTERLACED;
+	else
+		var->vmode &= ~FB_VMODE_INTERLACED;
+
+	var->red.offset = 0;
+	var->green.offset = 0;
+	var->blue.offset = 0;
+	var->red.msb_right = 0;
+	var->green.msb_right = 0;
+	var->blue.msb_right = 0;
+	var->transp.offset = 0;
+	var->transp.length = 0;
+	var->transp.msb_right = 0;
+	var->nonstd = 0;
+
+	if (lconfig->pixfmt == PIXFMT_1BPP ||
+	    lconfig->pixfmt == PIXFMT_2BPP ||
+	    lconfig->pixfmt == PIXFMT_4BPP ||
+	    lconfig->pixfmt == PIXFMT_8BPP) {
+		var->red.length = var->bits_per_pixel;
+		var->green.length = var->bits_per_pixel;
+		var->blue.length = var->bits_per_pixel;
+	}
+
+	switch (lconfig->pixfmt) {
+	case PIXFMT_1BPP:
+		var->bits_per_pixel = 1;
+		break;
+	case PIXFMT_2BPP:
+		var->bits_per_pixel = 2;
+		break;
+	case PIXFMT_4BPP:
+		var->bits_per_pixel = 4;
+		break;
+	case PIXFMT_8BPP:
+		var->bits_per_pixel = 8;
+		break;
+	case PIXFMT_RGB565:
+		var->bits_per_pixel = 16;
+		var->red.offset = 11;
+		var->red.length = 5;
+		var->green.offset = 5;
+		var->green.length = 6;
+		var->blue.offset = 0;
+		var->blue.length = 5;
+		break;
+	case PIXFMT_YCBCRI:
+	case PIXFMT_YCRCBI:
+		var->bits_per_pixel = 16;
+		var->red.length = 0;
+		var->green.length = 0;
+		var->blue.length = 0;
+		var->nonstd = 1;
+		break;
+	case PIXFMT_NV12:
+		if (cpu_is_davinci_dm365()) {
+			var->bits_per_pixel = 8;
+			var->red.length = 0;
+			var->green.length = 0;
+			var->blue.length = 0;
+			var->nonstd = 1;
+		}
+	case PIXFMT_RGB888:
+		if (cpu_is_davinci_dm644x()) {
+			var->bits_per_pixel = 24;
+			var->red.offset = 0;
+			var->red.length = 8;
+			var->green.offset = 8;
+			var->green.length = 8;
+			var->blue.offset = 16;
+			var->blue.length = 8;
+		} else {
+			var->bits_per_pixel = 32;
+			var->red.offset = 16;
+			var->red.length = 8;
+			var->green.offset = 8;
+			var->green.length = 8;
+			var->blue.offset = 0;
+			var->blue.length = 8;
+			var->transp.offset = 24;
+			var->transp.length = 3;
+		}
+		break;
+	case PIXFMT_OSD_ATTR:
+		var->bits_per_pixel = 4;
+		var->red.length = 0;
+		var->green.length = 0;
+		var->blue.length = 0;
+		var->nonstd = 1;
+		break;
+	}
+
+	var->grayscale = 0;
+	var->activate = FB_ACTIVATE_NOW;
+	var->height = 0;
+	var->width = 0;
+	var->accel_flags = 0;
+	var->rotate = 0;
+}
+
+/*
+ * Get the video mode from the encoder manager.
+ */
+static int get_video_mode(struct vpbe_device *vpbe_dev,
+			  struct fb_videomode *mode)
+{
+	struct vpbe_enc_mode_info mode_info;
+	int ret;
+
+	memset(&mode_info, 0, sizeof(mode_info));
+	memset(mode, 0, sizeof(*mode));
+
+	ret = vpbe_dev->ops.get_mode_info(vpbe_dev, &mode_info);
+	if (ret < 0)
+		return ret;
+
+	mode->name = mode_info.name;
+	if (mode_info.fps.denominator) {
+		unsigned fps_1000;	/* frames per 1000 seconds */
+		unsigned lps;	/* lines per second */
+		unsigned pps;	/* pixels per second */
+		unsigned vtotal;	/* total lines per frame */
+		unsigned htotal;	/* total pixels per line */
+		unsigned interlace = (mode_info.interlaced) ? 2 : 1;
+
+		fps_1000 = (1000 * mode_info.fps.numerator +
+		     mode_info.fps.denominator / 2) / mode_info.fps.denominator;
+
+		mode->refresh = (interlace * fps_1000 + 1000 / 2) / 1000;
+
+		vtotal = mode_info.yres + mode_info.lower_margin +
+		    mode_info.vsync_len + mode_info.upper_margin;
+		lps = (fps_1000 * vtotal + 1000 / 2) / 1000;
+
+		htotal = mode_info.xres + mode_info.right_margin +
+		    mode_info.hsync_len + mode_info.left_margin;
+		pps = lps * htotal;
+
+		if (pps)
+			mode->pixclock =
+				((1000000000UL + pps / 2) / pps) * 1000;
+	}
+	mode->xres = mode_info.xres;
+	mode->yres = mode_info.yres;
+	mode->left_margin = mode_info.left_margin;
+	mode->right_margin = mode_info.right_margin;
+	mode->upper_margin = mode_info.upper_margin;
+	mode->lower_margin = mode_info.lower_margin;
+	mode->hsync_len = mode_info.hsync_len;
+	mode->vsync_len = mode_info.vsync_len;
+	if (mode_info.flags & (1 << 0))
+		mode->sync |= FB_SYNC_HOR_HIGH_ACT;
+	if (mode_info.flags & (1 << 1))
+		mode->sync |= FB_SYNC_VERT_HIGH_ACT;
+	if ((mode_info.timings_type & VPBE_ENC_STD) ||
+	    (mode_info.timings_type & VPBE_ENC_DV_TIMINGS))
+		mode->sync |= FB_SYNC_BROADCAST;
+	if (mode_info.interlaced)
+		mode->vmode |= FB_VMODE_INTERLACED;
+
+	return 0;
+}
+
+/*
+ * Set a video mode with the encoder manager.
+ */
+static int set_video_mode(struct vpbe_device *vpbe_dev,
+			  struct fb_videomode *mode)
+{
+	struct vpbe_enc_mode_info mode_info;
+	int ret;
+
+	ret = vpbe_dev->ops.get_mode_info(vpbe_dev, &mode_info);
+	if (ret < 0)
+		return ret;
+
+	mode_info.name = (unsigned char *)mode->name;
+	mode_info.fps.numerator = 0;
+	mode_info.fps.denominator = 0;
+	if (mode->pixclock && mode->xres && mode->yres) {
+		unsigned fps_1000;	/* frames per 1000 seconds */
+		unsigned lps;	/* lines per second */
+		unsigned pps;	/* pixels per second */
+		unsigned vtotal;	/* total lines per frame */
+		unsigned htotal;	/* total pixels per line */
+
+		pps = ((1000000000UL + mode->pixclock / 2) / mode->pixclock) *
+								1000;
+
+		htotal = mode->xres + mode->right_margin + mode->hsync_len +
+						mode->left_margin;
+		lps = (pps + htotal / 2) / htotal;
+
+		vtotal = mode->yres + mode->lower_margin + mode->vsync_len +
+						mode->upper_margin;
+		fps_1000 = (lps * 1000 + vtotal / 2) / vtotal;
+
+		mode_info.fps.numerator = fps_1000;
+		mode_info.fps.denominator = 1000;
+
+		/*
+		 * 1000 == 2*2*2*5*5*5, so factor out any common multiples of 2
+		 * or 5
+		 */
+		while ((((mode_info.fps.numerator / 2) * 2) ==
+			mode_info.fps.numerator) &&
+			(((mode_info.fps.denominator / 2) * 2) ==
+			   mode_info.fps.denominator)) {
+			mode_info.fps.numerator = mode_info.fps.numerator / 2;
+			mode_info.fps.denominator =
+			    mode_info.fps.denominator / 2;
+		}
+		while ((((mode_info.fps.numerator / 5) * 5) ==
+			mode_info.fps.numerator) &&
+			(((mode_info.fps.denominator / 5) * 5) ==
+			   mode_info.fps.denominator)) {
+			mode_info.fps.numerator = mode_info.fps.numerator / 5;
+			mode_info.fps.denominator =
+			    mode_info.fps.denominator / 5;
+		}
+	}
+	mode_info.xres = mode->xres;
+	mode_info.yres = mode->yres;
+	mode_info.left_margin = mode->left_margin;
+	mode_info.right_margin = mode->right_margin;
+	mode_info.upper_margin = mode->upper_margin;
+	mode_info.lower_margin = mode->lower_margin;
+	mode_info.hsync_len = mode->hsync_len;
+	mode_info.vsync_len = mode->vsync_len;
+	if (mode->sync & FB_SYNC_HOR_HIGH_ACT)
+		mode_info.flags |= (1 << 0);
+	else
+		mode_info.flags &= ~(1 << 0);
+	if (mode->sync & FB_SYNC_VERT_HIGH_ACT)
+		mode_info.flags |= (1 << 1);
+	else
+		mode_info.flags &= ~(1 << 1);
+	/*
+	 * seems like a flag std is used in earlier version of the driver to
+	 * indicate if it is a standard timings non standard timings. We use
+	 * timings_type for the same.
+	 */
+	if (mode->sync & FB_SYNC_BROADCAST)
+		mode_info.timings_type = VPBE_ENC_TIMINGS_INVALID;
+	else
+		mode_info.timings_type = VPBE_ENC_DV_TIMINGS;
+	if (mode->vmode & FB_VMODE_INTERLACED)
+		mode_info.interlaced = 1;
+	else
+		mode_info.interlaced = 0;
+
+	ret = vpbe_dev->ops.set_mode(vpbe_dev, &mode_info);
+
+	return ret;
+}
+
+/*
+ * Construct an fb_var_screeninfo structure from an fb_videomode structure
+ * describing the display and a osd_layer_config structure describing a window.
+ * The following members of var not modified:
+ *	var->xoffset
+ *	var->yoffset
+ *	var->xres_virtual
+ *	var->yres_virtual
+ * The following members of var are loaded with values derived from mode:
+ *	var->pixclock
+ *	var->left_margin
+ *	var->hsync_len
+ *	var->vsync_len
+ *	var->right_margin
+ *	var->upper_margin
+ *	var->lower_margin
+ *	var->sync
+ *	var->vmode (all bits except bit 0: FB_VMODE_INTERLACED)
+ * The following members of var are loaded with values derived from lconfig:
+ *	var->xres
+ *	var->yres
+ *	var->bits_per_pixel
+ *	var->red
+ *	var->green
+ *	var->blue
+ *	var->transp
+ *	var->nonstd
+ *	var->grayscale
+ *	var->activate
+ *	var->height
+ *	var->width
+ *	var->accel_flags
+ *	var->rotate
+ *	var->vmode (only bit 0: FB_VMODE_INTERLACED)
+ *
+ * If the display resolution (xres and yres) specified in mode matches the
+ * window resolution specified in lconfig, then the display timing info returned
+ * in var is valid and var->pixclock will be the value derived from mode.
+ * If the display resolution does not match the window resolution, then
+ * var->pixclock will be set to 0 to indicate that the display timing info
+ * returned in var is not valid.
+ *
+ * mode and lconfig are not modified.
+ */
+static void construct_fb_var(struct fb_var_screeninfo *var,
+			     struct fb_videomode *mode,
+			     struct osd_layer_config *lconfig)
+{
+	fb_videomode_to_var(var, mode);
+	convert_osd_to_fb_var(lconfig, var);
+	if (lconfig->xsize != mode->xres || lconfig->ysize != mode->yres)
+		var->pixclock = 0;
+}
+
+/*
+ * Update the values in an fb_fix_screeninfo structure based on the values in an
+ * fb_var_screeninfo structure.
+ * The following members of fix are updated:
+ *	fix->visual
+ *	fix->xpanstep
+ *	fix->ypanstep
+ *	fix->ywrapstep
+ *	fix->line_length
+ * All other members of fix are unmodified.
+ */
+static void update_fix_info(const struct fb_var_screeninfo *var,
+			    struct fb_fix_screeninfo *fix)
+{
+	fix->visual = (var->bits_per_pixel > 8) ? FB_VISUAL_TRUECOLOR :
+						FB_VISUAL_PSEUDOCOLOR;
+	/*
+	 * xpanstep must correspond to a multiple of the 32-byte cache line size
+	 */
+	switch (var->bits_per_pixel) {
+	case 1:
+	case 2:
+	case 4:
+	case 8:
+	case 12:
+	case 16:
+	case 32:
+		fix->xpanstep = (8 * 32) / var->bits_per_pixel;
+		break;
+	case 24:
+		fix->xpanstep = 32;	/* 32 pixels = 3 cache lines */
+		break;
+	default:
+		fix->xpanstep = 0;
+		break;
+	}
+	fix->ypanstep = 1;
+	fix->ywrapstep = 0;
+	fix->line_length = (var->xres_virtual * var->bits_per_pixel + 7) / 8;
+	/* line_length must be a multiple of the 32-byte cache line size */
+	fix->line_length = ((fix->line_length + 31) / 32) * 32;
+}
+
+/*
+ * Determine if the window configuration specified by var will fit in a
+ * framebuffer of size fb_size.
+ * Returns 1 if the window will fit in the framebuffer, or 0 otherwise.
+ */
+static int window_will_fit_framebuffer(const struct fb_var_screeninfo *var,
+				       unsigned fb_size)
+{
+	unsigned line_length;
+
+	line_length = (var->bits_per_pixel * var->xres_virtual + 7) / 8;
+	/* line length must be a multiple of the cache line size (32) */
+	line_length = ((line_length + 31) / 32) * 32;
+
+	if (var->yres_virtual * line_length <= fb_size)
+		return 1;
+	return 0;
+}
+
+/*
+ * FBIO_WAITFORVSYNC handler
+ */
+static int davincifb_wait_for_vsync(struct fb_info *info)
+{
+	struct vpbe_dm_win_info *win = info->par;
+	unsigned long cnt;
+	wait_queue_t wq;
+	int ret;
+
+	init_waitqueue_entry(&wq, current);
+
+	cnt = win->dm->vsync_cnt;
+	ret = wait_event_interruptible_timeout(win->dm->vsync_wait,
+			cnt != win->dm->vsync_cnt, win->dm->timeout);
+	if (ret < 0)
+		return ret;
+	if (ret == 0)
+		return -ETIMEDOUT;
+
+	return 0;
+}
+
+static void davincifb_vsync_callback(unsigned event, void *arg)
+{
+	struct vpbe_dm_info *dm = (struct vpbe_dm_info *)arg;
+	static unsigned last_event;
+	unsigned long addr = 0;
+
+	event &= ~VENC_END_OF_FRAME;
+	if (event == last_event) {
+		/* progressive */
+		xchg(&addr, dm->win[WIN_OSD0].sdram_address);
+		if (addr) {
+			osd_device->ops.start_layer(osd_device,
+					dm->win[WIN_OSD0].layer,
+					dm->win[WIN_OSD0].sdram_address,
+					fb_cbcr_ofst);
+			dm->win[WIN_OSD0].sdram_address = 0;
+		}
+		addr = 0;
+		xchg(&addr, dm->win[WIN_OSD1].sdram_address);
+		if (addr) {
+			osd_device->ops.start_layer(osd_device,
+					dm->win[WIN_OSD1].layer,
+					dm->win[WIN_OSD1].sdram_address,
+					fb_cbcr_ofst);
+			dm->win[WIN_OSD1].sdram_address = 0;
+		}
+		addr = 0;
+		xchg(&addr, dm->win[WIN_VID0].sdram_address);
+		if (addr) {
+			osd_device->ops.start_layer(osd_device,
+					dm->win[WIN_VID0].layer,
+					dm->win[WIN_VID0].sdram_address,
+					fb_cbcr_ofst);
+			dm->win[WIN_VID0].sdram_address = 0;
+		}
+		addr = 0;
+		xchg(&addr, dm->win[WIN_VID1].sdram_address);
+		if (addr) {
+			osd_device->ops.start_layer(osd_device,
+					dm->win[WIN_VID1].layer,
+					dm->win[WIN_VID1].sdram_address,
+					fb_cbcr_ofst);
+
+			dm->win[WIN_VID1].sdram_address = 0;
+		}
+		++dm->vsync_cnt;
+		wake_up_interruptible(&dm->vsync_wait);
+		last_event = event;
+		return;
+	}
+	/* interlaced */
+	if (!(event & VENC_SECOND_FIELD)) {
+		++dm->vsync_cnt;
+		wake_up_interruptible(&dm->vsync_wait);
+		last_event = event;
+		return;
+	}
+	xchg(&addr, dm->win[WIN_OSD0].sdram_address);
+	if (addr) {
+		osd_device->ops.start_layer(osd_device,
+				dm->win[WIN_OSD0].layer,
+				dm->win[WIN_OSD0].sdram_address,
+				fb_cbcr_ofst);
+
+		dm->win[WIN_OSD0].sdram_address = 0;
+	}
+	addr = 0;
+	xchg(&addr, dm->win[WIN_OSD1].sdram_address);
+	if (addr) {
+		osd_device->ops.start_layer(osd_device,
+				dm->win[WIN_OSD1].layer,
+				dm->win[WIN_OSD1].sdram_address,
+				fb_cbcr_ofst);
+		dm->win[WIN_OSD1].sdram_address = 0;
+	}
+	addr = 0;
+	xchg(&addr, dm->win[WIN_VID0].sdram_address);
+	if (addr) {
+		osd_device->ops.start_layer(osd_device,
+				dm->win[WIN_VID0].layer,
+				dm->win[WIN_VID0].sdram_address,
+				fb_cbcr_ofst);
+		dm->win[WIN_VID0].sdram_address = 0;
+	}
+	addr = 0;
+	xchg(&addr, dm->win[WIN_VID1].sdram_address);
+	if (addr) {
+		osd_device->ops.start_layer(osd_device,
+				dm->win[WIN_VID1].layer,
+				dm->win[WIN_VID1].sdram_address,
+				fb_cbcr_ofst);
+		dm->win[WIN_VID1].sdram_address = 0;
+	}
+	last_event = event;
+}
+
+/*
+ * FBIO_SETATTRIBUTE handler
+ *
+ * This ioctl is deprecated.  The user can write the attribute values directly
+ * to the OSD1 framebuffer.
+ *
+ * Set a uniform attribute value over a rectangular area on the attribute
+ * window. The attribute value (0 to 15) is passed through the fb_fillrect's
+ * color parameter.  r->dx and r->width must both be even.  If not, they are
+ * rounded down.
+ */
+static int davincifb_set_attr_blend(struct fb_info *info, struct fb_fillrect *r)
+{
+	struct fb_var_screeninfo *var = &info->var;
+	struct vpbe_dm_win_info *win = info->par;
+	char __iomem *start;
+	u32 width_bytes;
+	u8 blend;
+
+	if (win->layer != WIN_OSD1)
+		return -EINVAL;
+	if (!is_attribute_mode(var))
+		return -EINVAL;
+
+	if (r->dx + r->width > var->xres_virtual)
+		return -EINVAL;
+	if (r->dy + r->height > var->yres_virtual)
+		return -EINVAL;
+	if (r->color > 15)
+		return -EINVAL;
+	width_bytes = (r->width * var->bits_per_pixel) / 8;
+	start = info->screen_base + r->dy * info->fix.line_length +
+				(r->dx * var->bits_per_pixel) / 8;
+
+	blend = (((u8) r->color & 0xf) << 4) | ((u8) r->color);
+	while (r->height--) {
+		memset(start, blend, width_bytes);
+		start += info->fix.line_length * 3;
+	}
+
+	return 0;
+}
+
+/*
+ * FBIO_SETPOSX handler
+ */
+static int davincifb_setposx(struct fb_info *info, unsigned xpos)
+{
+	struct fb_var_screeninfo *var = &info->var;
+	struct vpbe_dm_win_info *win = info->par;
+	unsigned old_xpos = win->xpos;
+	struct fb_var_screeninfo v;
+	int retval;
+
+	if (!win->own_window)
+		return -ENODEV;
+
+	memcpy(&v, var, sizeof(v));
+	win->xpos = xpos;
+	retval = info->fbops->fb_check_var(&v, info);
+	if (retval) {
+		win->xpos = old_xpos;
+		return retval;
+	}
+
+	/* update the window position */
+	memcpy(var, &v, sizeof(v));
+	retval = info->fbops->fb_set_par(info);
+
+	return retval;
+}
+
+/*
+ * FBIO_SETPOSY handler
+ */
+static int davincifb_setposy(struct fb_info *info, unsigned ypos)
+{
+	struct fb_var_screeninfo *var = &info->var;
+	struct vpbe_dm_win_info *win = info->par;
+	unsigned old_ypos = win->ypos;
+	struct fb_var_screeninfo v;
+	int retval;
+
+	if (!win->own_window)
+		return -ENODEV;
+
+	memcpy(&v, var, sizeof(v));
+	win->ypos = ypos;
+	retval = info->fbops->fb_check_var(&v, info);
+	if (retval) {
+		win->ypos = old_ypos;
+		return retval;
+	}
+
+	/* update the window position */
+	memcpy(var, &v, sizeof(v));
+	retval = info->fbops->fb_set_par(info);
+
+	return retval;
+}
+
+/*
+ * FBIO_SETZOOM handler
+ */
+static int davincifb_set_zoom(struct fb_info *info, struct zoom_params *zoom)
+{
+	struct vpbe_dm_win_info *win = info->par;
+	enum osd_zoom_factor h_zoom, v_zoom;
+
+	if (!win->own_window)
+		return -ENODEV;
+
+	switch (zoom->zoom_h) {
+	case 0:
+		h_zoom = ZOOM_X1;
+		break;
+	case 1:
+		h_zoom = ZOOM_X2;
+		break;
+	case 2:
+		h_zoom = ZOOM_X4;
+		break;
+	default:
+		return -EINVAL;
+	}
+
+	switch (zoom->zoom_v) {
+	case 0:
+		v_zoom = ZOOM_X1;
+		break;
+	case 1:
+		v_zoom = ZOOM_X2;
+		break;
+	case 2:
+		v_zoom = ZOOM_X4;
+		break;
+	default:
+		return -EINVAL;
+	}
+	osd_device->ops.set_zoom(osd_device,
+			 win->layer, h_zoom, v_zoom);
+	return 0;
+}
+
+/*
+ * FBIO_ENABLE_DISABLE_WIN handler
+ *
+ * This ioctl is deprecated.  Use the standard FBIOBLANK ioctl instead.
+ */
+static int davincifb_enable_disable_win(struct fb_info *info, int enable)
+{
+	struct vpbe_dm_win_info *win = info->par;
+	int retval = 0;
+
+	if (!win->own_window)
+		return -ENODEV;
+
+	if (!enable) {
+		win->display_window = 0;
+		osd_device->ops.disable_layer(osd_device, win->layer);
+		return retval;
+	}
+	win->display_window = 1;
+	retval = info->fbops->fb_check_var(&info->var, info);
+	if (retval)
+		return retval;
+	retval = info->fbops->fb_set_par(info);
+	return retval;
+}
+
+/*
+ * FBIO_SET_BITMAP_BLEND_FACTOR handler
+ */
+static int
+davincifb_bitmap_set_blend_factor(struct fb_info *info,
+				  struct vpbe_bitmap_blend_params *para)
+{
+	enum osd_layer osdwin = fb_info_to_osd_enum(info);
+
+	if (!is_osd_win(info))
+		return -EINVAL;
+
+	if (para->bf > OSD_8_VID_0)
+		return -EINVAL;
+
+	osd_device->ops.set_blending_factor(osd_device, osdwin, para->bf);
+	if (para->enable_colorkeying)
+		osd_device->ops.enable_color_key(osd_device,
+				 osdwin, para->colorkey);
+	else
+		osd_device->ops.disable_color_key(osd_device, osdwin);
+	return 0;
+}
+
+/*
+ * FBIO_SET_BITMAP_WIN_RAM_CLUT handler
+ *
+ * This ioctl is deprecated.  Use the standard framebuffer ioctl FBIOPUTCMAP
+ * instead.  Note that FBIOPUTCMAP colors are expressed in RGB space instead of
+ * YCbCr space.
+ */
+static int
+davincifb_bitmap_set_ram_clut(struct fb_info *info,
+			      unsigned char ram_clut[256][3])
+{
+	int i;
+
+	if (!is_osd_win(info))
+		return -EINVAL;
+
+	for (i = 0; i < 256; i++)
+		osd_device->ops.set_clut_ycbcr(osd_device, i, ram_clut[i][0],
+				ram_clut[i][1], ram_clut[i][2]);
+
+	return 0;
+}
+
+/*
+ * FBIO_ENABLE_DISABLE_ATTRIBUTE_WIN handler
+ *
+ * This ioctl is deprecated.  Attribute mode can be enabled via the standard
+ * framebuffer ioctl FBIOPUT_VSCREENINFO by setting var->bits_per_pixel to 4
+ * and var->nonstd to a non-zero value.  Attribute mode can be disabled by using
+ * FBIOPUT_VSCREENINFO to set a standard pixel format.
+ *
+ * The enabled/disabled status of OSD1 is unchanged by this ioctl.  To avoid
+ * display glitches, you should disable OSD1 prior to calling this ioctl.
+ *
+ * When enabling attribute mode, var->bits_per_pixel is set to 4.  var->xres,
+ * var->yres, var->xres_virtual, var->yres_virtual, win->xpos, and win->ypos are
+ * all copied from OSD0.  var->xoffset and var->yoffset are set to 0.
+ * fix->line_length is updated to be consistent with 4 bits per pixel.  No
+ * changes are made to the OSD1 configuration if OSD1 is already in attribute
+ * mode.
+ *
+ * When disabling attribute mode, the window geometry is unchanged.
+ * var->bits_per_pixel remains set to 4.  No changes are made to the OSD1
+ * configuration if OSD1 is not in attribute mode.
+ */
+static int
+davincifb_enable_disable_attribute_window(struct fb_info *info, u32 flag)
+{
+	struct fb_var_screeninfo *var = &info->var;
+	struct vpbe_dm_win_info *win = info->par;
+	struct osd_layer_config lconfig;
+	struct fb_var_screeninfo v;
+	int retval;
+
+	if (win->layer != WIN_OSD1)
+		return -EINVAL;
+
+	/* return with no error if there is nothing to do */
+	if ((is_attribute_mode(var) && flag) ||
+	    (!is_attribute_mode(var) && !flag))
+		return 0;
+
+	/* start with the current OSD1 var */
+	memcpy(&v, var, sizeof(v));
+
+	if (flag) {
+		/* enable attribute mode */
+		const struct vpbe_dm_win_info *osd0 = &win->dm->win[WIN_OSD0];
+		const struct fb_var_screeninfo *osd0_var = &osd0->info->var;
+		unsigned old_xpos = win->xpos;
+		unsigned old_ypos = win->ypos;
+		/* get the OSD0 window configuration */
+		convert_fb_var_to_osd(osd0_var, &lconfig, win->dm->yc_pixfmt);
+		/* change the pixfmt to attribute mode */
+		lconfig.pixfmt = PIXFMT_OSD_ATTR;
+		/* update the var for OSD1 */
+		convert_osd_to_fb_var(&lconfig, &v);
+		/* copy xres_virtual and yres_virtual from OSD0 */
+		v.xres_virtual = osd0_var->xres_virtual;
+		v.yres_virtual = osd0_var->yres_virtual;
+		/* zero xoffset and yoffset */
+		v.xoffset = 0;
+		v.yoffset = 0;
+		/* copy xpos and ypos from OSD0 */
+		win->xpos = osd0->xpos;
+		win->ypos = osd0->ypos;
+
+		retval = info->fbops->fb_check_var(&v, info);
+		if (retval) {
+			win->xpos = old_xpos;
+			win->ypos = old_ypos;
+			return retval;
+		}
+
+		/*
+		 * Enable attribute mode by replacing info->var and calling
+		 * the fb_set_par method to activate it.
+		 */
+		memcpy(var, &v, sizeof(v));
+		retval = info->fbops->fb_set_par(info);
+		return retval;
+	}
+	/* disable attribute mode */
+	/* get the current OSD1 window configuration */
+	convert_fb_var_to_osd(var, &lconfig, win->dm->yc_pixfmt);
+	/* change the pixfmt to 4-bits-per-pixel bitmap */
+	lconfig.pixfmt = PIXFMT_4BPP;
+	/* update the var for OSD1 */
+	convert_osd_to_fb_var(&lconfig, &v);
+
+	retval = info->fbops->fb_check_var(&v, info);
+	if (retval)
+		return retval;
+
+	/*
+	  * Disable attribute mode by replacing info->var and calling
+	  * the fb_set_par method to activate it.
+	  */
+	memcpy(var, &v, sizeof(v));
+	retval = info->fbops->fb_set_par(info);
+	return retval;
+}
+
+/*
+ * FBIO_GET_BLINK_INTERVAL handler
+ */
+static int
+davincifb_get_blinking(struct fb_info *info,
+		       struct vpbe_blink_option *blink_option)
+{
+	struct vpbe_dm_win_info *win = info->par;
+	enum osd_blink_interval blink;
+	int enabled;
+
+	if (win->layer != WIN_OSD1)
+		return -EINVAL;
+
+	osd_device->ops.get_blink_attribute(osd_device, &enabled, &blink);
+	blink_option->blinking = enabled;
+	blink_option->interval = blink;
+
+	return 0;
+}
+
+/*
+ * FBIO_SET_BLINK_INTERVAL handler
+ */
+static int
+davincifb_set_blinking(struct fb_info *info,
+		       struct vpbe_blink_option *blink_option)
+{
+	struct vpbe_dm_win_info *win = info->par;
+
+	if (win->layer != WIN_OSD1)
+		return -EINVAL;
+
+	if (blink_option->interval > BLINK_X4)
+		return -EINVAL;
+	osd_device->ops.set_blink_attribute(osd_device,
+			 blink_option->blinking, blink_option->interval);
+
+	return 0;
+}
+
+/*
+ * FBIO_GET_VIDEO_CONFIG_PARAMS handler
+ *
+ * Despite the name, this ioctl can be used on both video windows and OSD
+ * (bitmap) windows.
+ */
+static int
+davincifb_get_vid_params(struct fb_info *info,
+			 struct vpbe_video_config_params *vid_conf_params)
+{
+	struct vpbe_dm_win_info *win = info->par;
+	enum osd_h_exp_ratio h_exp;
+	enum osd_v_exp_ratio v_exp;
+
+	if (!win->own_window)
+		return -ENODEV;
+
+	if (is_vid_win(info))
+		osd_device->ops.get_vid_expansion(osd_device,
+				 &h_exp, &v_exp);
+	else
+		osd_device->ops.get_osd_expansion(osd_device,
+				 &h_exp, &v_exp);
+
+	vid_conf_params->cb_cr_order =
+	    (win->dm->yc_pixfmt == PIXFMT_YCBCRI) ? 0 : 1;
+	vid_conf_params->exp_info.horizontal = h_exp;
+	vid_conf_params->exp_info.vertical = v_exp;
+
+	return 0;
+}
+
+/*
+ * FBIO_SET_VIDEO_CONFIG_PARAMS handler
+ *
+ * Despite the name, this ioctl can be used on both video windows and OSD
+ * (bitmap) windows.
+ *
+ * NOTE: If the cb_cr_order is changed, it won't take effect until an
+ * FBIOPUT_VSCREENINFO ioctl is executed on a window with a YC pixel format.
+ */
+static int
+davincifb_set_vid_params(struct fb_info *info,
+			 struct vpbe_video_config_params *vid_conf_params)
+{
+	struct vpbe_dm_win_info *win = info->par;
+	enum osd_h_exp_ratio h_exp;
+	enum osd_v_exp_ratio v_exp;
+
+	if (!win->own_window)
+		return -ENODEV;
+
+	if (vid_conf_params->exp_info.horizontal > H_EXP_3_OVER_2)
+		return -EINVAL;
+
+	if (vid_conf_params->exp_info.vertical > V_EXP_6_OVER_5)
+		return -EINVAL;
+
+	win->dm->yc_pixfmt =
+	    vid_conf_params->cb_cr_order ? PIXFMT_YCRCBI : PIXFMT_YCBCRI;
+
+	h_exp = vid_conf_params->exp_info.horizontal;
+	v_exp = vid_conf_params->exp_info.vertical;
+	if (is_vid_win(info))
+		osd_device->ops.set_vid_expansion(osd_device,
+				 h_exp, v_exp);
+	else
+		osd_device->ops.set_osd_expansion(osd_device,
+				 h_exp, v_exp);
+
+	return 0;
+}
+
+/*
+ * FBIO_GET_BITMAP_CONFIG_PARAMS handler
+ */
+static int
+davincifb_bitmap_get_params(struct fb_info *info,
+			    struct vpbe_bitmap_config_params*
+			    bitmap_conf_params)
+{
+	enum osd_layer osdwin = fb_info_to_osd_enum(info);
+	enum osd_clut clut;
+
+	if (!is_osd_win(info))
+		return -EINVAL;
+
+	clut = osd_device->ops.get_osd_clut(osd_device, osdwin);
+	if (clut == ROM_CLUT)
+		bitmap_conf_params->clut_select =
+			osd_device->ops.get_rom_clut(osd_device);
+	else
+		bitmap_conf_params->clut_select = 2;
+
+	bitmap_conf_params->attenuation_enable =
+	    osd_device->ops.get_rec601_attenuation(osd_device,
+			     osdwin);
+
+	memset(&bitmap_conf_params->clut_idx, 0,
+	       sizeof(bitmap_conf_params->clut_idx));
+
+	switch (info->var.bits_per_pixel) {
+	case 1:
+		bitmap_conf_params->clut_idx.for_1bit_bitmap.bitmap_val_0 =
+		    osd_device->ops.get_palette_map(osd_device,
+				     osdwin, 0);
+		bitmap_conf_params->clut_idx.for_1bit_bitmap.bitmap_val_1 =
+		    osd_device->ops.get_palette_map(osd_device,
+				     osdwin, 1);
+		break;
+	case 2:
+		bitmap_conf_params->clut_idx.for_2bit_bitmap.bitmap_val_0 =
+		    osd_device->ops.get_palette_map(osd_device,
+				     osdwin, 0);
+		bitmap_conf_params->clut_idx.for_2bit_bitmap.bitmap_val_1 =
+		    osd_device->ops.get_palette_map(osd_device,
+				     osdwin, 1);
+
+		bitmap_conf_params->clut_idx.for_2bit_bitmap.bitmap_val_2 =
+		    osd_device->ops.get_palette_map(osd_device,
+				     osdwin, 2);
+		bitmap_conf_params->clut_idx.for_2bit_bitmap.bitmap_val_3 =
+		    osd_device->ops.get_palette_map(osd_device,
+				     osdwin, 3);
+		break;
+	case 4:
+		bitmap_conf_params->clut_idx.for_4bit_bitmap.bitmap_val_0 =
+		    osd_device->ops.get_palette_map(osd_device,
+				     osdwin, 0);
+		bitmap_conf_params->clut_idx.for_4bit_bitmap.bitmap_val_1 =
+		    osd_device->ops.get_palette_map(osd_device,
+				     osdwin, 1);
+		bitmap_conf_params->clut_idx.for_4bit_bitmap.bitmap_val_2 =
+		    osd_device->ops.get_palette_map(osd_device,
+				     osdwin, 2);
+		bitmap_conf_params->clut_idx.for_4bit_bitmap.bitmap_val_3 =
+		    osd_device->ops.get_palette_map(osd_device,
+				     osdwin, 3);
+		bitmap_conf_params->clut_idx.for_4bit_bitmap.bitmap_val_4 =
+		    osd_device->ops.get_palette_map(osd_device,
+				     osdwin, 4);
+		bitmap_conf_params->clut_idx.for_4bit_bitmap.bitmap_val_5 =
+		    osd_device->ops.get_palette_map(osd_device,
+				     osdwin, 5);
+		bitmap_conf_params->clut_idx.for_4bit_bitmap.bitmap_val_6 =
+		    osd_device->ops.get_palette_map(osd_device,
+				     osdwin, 6);
+
+		bitmap_conf_params->clut_idx.for_4bit_bitmap.bitmap_val_7 =
+		    osd_device->ops.get_palette_map(osd_device,
+						    osdwin, 7);
+		bitmap_conf_params->clut_idx.for_4bit_bitmap.bitmap_val_8 =
+		    osd_device->ops.get_palette_map(osd_device,
+				     osdwin, 8);
+		bitmap_conf_params->clut_idx.for_4bit_bitmap.bitmap_val_9 =
+		    osd_device->ops.get_palette_map(osd_device,
+				     osdwin, 9);
+
+		bitmap_conf_params->clut_idx.for_4bit_bitmap.bitmap_val_10 =
+		    osd_device->ops.get_palette_map(osd_device,
+				     osdwin, 10);
+
+		bitmap_conf_params->clut_idx.for_4bit_bitmap.bitmap_val_11 =
+		    osd_device->ops.get_palette_map(osd_device,
+				     osdwin, 11);
+
+		bitmap_conf_params->clut_idx.for_4bit_bitmap.bitmap_val_12 =
+		    osd_device->ops.get_palette_map(osd_device,
+				     osdwin, 12);
+		bitmap_conf_params->clut_idx.for_4bit_bitmap.bitmap_val_13 =
+		    osd_device->ops.get_palette_map(osd_device,
+				     osdwin, 13);
+		bitmap_conf_params->clut_idx.for_4bit_bitmap.bitmap_val_14 =
+		    osd_device->ops.get_palette_map(osd_device,
+				     osdwin, 14);
+		bitmap_conf_params->clut_idx.for_4bit_bitmap.bitmap_val_15 =
+		    osd_device->ops.get_palette_map(osd_device,
+				     osdwin, 15);
+		break;
+	default:
+		break;
+	}
+
+	return 0;
+}
+
+/*
+ * FBIO_SET_BITMAP_CONFIG_PARAMS handler
+ *
+ * The palette map is ignored unless the color depth is set to 1, 2, or 4 bits
+ * per pixel.  A default palette map is supplied for these color depths where
+ * the clut index is equal to the pixel value.  It is not necessary to change
+ * the default palette map when using the RAM clut, because the RAM clut values
+ * can be changed.  It is only necessary to modify the default palette map when
+ * using a ROM clut.
+ */
+static int
+davincifb_bitmap_set_params(struct fb_info *info,
+			    struct vpbe_bitmap_config_params*
+			    bitmap_conf_params)
+{
+	enum osd_layer osdwin = fb_info_to_osd_enum(info);
+	enum osd_clut clut = ROM_CLUT;
+
+	if (!is_osd_win(info))
+		return -EINVAL;
+
+	if (bitmap_conf_params->clut_select == 0)
+		osd_device->ops.set_rom_clut(osd_device, ROM_CLUT0);
+	else if (bitmap_conf_params->clut_select == 1)
+		osd_device->ops.set_rom_clut(osd_device, ROM_CLUT1);
+	else if (bitmap_conf_params->clut_select == 2)
+		clut = RAM_CLUT;
+	else
+		return -EINVAL;
+
+	osd_device->ops.set_osd_clut(osd_device, osdwin, clut);
+
+	osd_device->ops.set_rec601_attenuation(osd_device, osdwin,
+				bitmap_conf_params->attenuation_enable);
+
+	switch (info->var.bits_per_pixel) {
+	case 1:
+		osd_device->ops.set_palette_map(osd_device,
+				 osdwin, 0, bitmap_conf_params->clut_idx.
+				 for_1bit_bitmap.bitmap_val_0);
+		osd_device->ops.set_palette_map(osd_device,
+				 osdwin, 1, bitmap_conf_params->clut_idx.
+				 for_1bit_bitmap.bitmap_val_1);
+		break;
+	case 2:
+		osd_device->ops.set_palette_map(osd_device,
+				 osdwin, 0, bitmap_conf_params->clut_idx.
+				 for_2bit_bitmap.bitmap_val_0);
+		osd_device->ops.set_palette_map(osd_device,
+				 osdwin, 1, bitmap_conf_params->clut_idx.
+				 for_2bit_bitmap.bitmap_val_1);
+		osd_device->ops.set_palette_map(osd_device,
+				 osdwin, 2, bitmap_conf_params->clut_idx.
+				 for_2bit_bitmap.bitmap_val_2);
+		osd_device->ops.set_palette_map(osd_device,
+				 osdwin, 3, bitmap_conf_params->clut_idx.
+				 for_2bit_bitmap.bitmap_val_3);
+
+		break;
+	case 4:
+		osd_device->ops.set_palette_map(osd_device,
+				 osdwin, 0, bitmap_conf_params->clut_idx.
+				 for_4bit_bitmap.bitmap_val_0);
+		osd_device->ops.set_palette_map(osd_device,
+				 osdwin, 1, bitmap_conf_params->clut_idx.
+				 for_4bit_bitmap.bitmap_val_1);
+		osd_device->ops.set_palette_map(osd_device,
+				 osdwin, 2, bitmap_conf_params->clut_idx.
+				 for_4bit_bitmap.bitmap_val_2);
+		osd_device->ops.set_palette_map(osd_device,
+				 osdwin, 3, bitmap_conf_params->clut_idx.
+				 for_4bit_bitmap.bitmap_val_3);
+		osd_device->ops.set_palette_map(osd_device,
+				 osdwin, 4, bitmap_conf_params->clut_idx.
+				 for_4bit_bitmap.bitmap_val_4);
+		osd_device->ops.set_palette_map(osd_device,
+				 osdwin, 5, bitmap_conf_params->clut_idx.
+				 for_4bit_bitmap.bitmap_val_5);
+		osd_device->ops.set_palette_map(osd_device,
+				 osdwin, 6, bitmap_conf_params->clut_idx.
+				 for_4bit_bitmap.bitmap_val_6);
+		osd_device->ops.set_palette_map(osd_device,
+				 osdwin, 7, bitmap_conf_params->clut_idx.
+				 for_4bit_bitmap.bitmap_val_7);
+		osd_device->ops.set_palette_map(osd_device,
+				 osdwin, 8, bitmap_conf_params->clut_idx.
+				 for_4bit_bitmap.bitmap_val_8);
+		osd_device->ops.set_palette_map(osd_device,
+				 osdwin, 9, bitmap_conf_params->clut_idx.
+				 for_4bit_bitmap.bitmap_val_9);
+		osd_device->ops.set_palette_map(osd_device,
+				 osdwin, 10, bitmap_conf_params->clut_idx.
+				 for_4bit_bitmap.bitmap_val_10);
+		osd_device->ops.set_palette_map(osd_device,
+				 osdwin, 11, bitmap_conf_params->clut_idx.
+				 for_4bit_bitmap.bitmap_val_11);
+		osd_device->ops.set_palette_map(osd_device,
+				 osdwin, 12, bitmap_conf_params->clut_idx.
+				 for_4bit_bitmap.bitmap_val_12);
+		osd_device->ops.set_palette_map(osd_device,
+				 osdwin, 13, bitmap_conf_params->clut_idx.
+				 for_4bit_bitmap.bitmap_val_13);
+		osd_device->ops.set_palette_map(osd_device,
+				 osdwin, 14, bitmap_conf_params->clut_idx.
+				 for_4bit_bitmap.bitmap_val_14);
+		osd_device->ops.set_palette_map(osd_device,
+				 osdwin, 15, bitmap_conf_params->clut_idx.
+				 for_4bit_bitmap.bitmap_val_15);
+
+		break;
+	default:
+		break;
+	}
+
+	return 0;
+}
+
+/*
+ * FBIO_SET_BACKG_COLOR handler
+ */
+static int
+davincifb_set_backg_color(struct fb_info *info,
+			  struct vpbe_backg_color *backg_color)
+{
+	enum osd_clut clut = ROM_CLUT;
+
+	if (backg_color->clut_select == 0)
+		osd_device->ops.set_rom_clut(osd_device, ROM_CLUT0);
+	else if (backg_color->clut_select == 1)
+		osd_device->ops.set_rom_clut(osd_device, ROM_CLUT1);
+	else if (backg_color->clut_select == 2)
+		clut = RAM_CLUT;
+	else
+		return -EINVAL;
+
+	osd_device->ops.set_background(osd_device, clut,
+			 backg_color->color_offset);
+
+	return 0;
+}
+
+/*
+ * FBIO_SETPOS handler
+ */
+static int
+davincifb_setpos(struct fb_info *info,
+		 struct vpbe_window_position *win_pos)
+{
+	struct vpbe_dm_win_info *win = info->par;
+	struct fb_var_screeninfo *var = &info->var;
+	unsigned old_xpos = win->xpos;
+	unsigned old_ypos = win->ypos;
+	struct fb_var_screeninfo v;
+	int retval;
+
+	if (!win->own_window)
+		return -ENODEV;
+
+	memcpy(&v, var, sizeof(v));
+	win->xpos = win_pos->xpos;
+	win->ypos = win_pos->ypos;
+	retval = info->fbops->fb_check_var(&v, info);
+	if (retval) {
+		win->xpos = old_xpos;
+		win->ypos = old_ypos;
+		return retval;
+	}
+	/* update the window position */
+	memcpy(var, &v, sizeof(v));
+	retval = info->fbops->fb_set_par(info);
+
+	return retval;
+}
+
+/*
+ * FBIO_SET_CURSOR handler
+ */
+static int
+davincifb_set_cursor_params(struct fb_info *info,
+			    struct fb_cursor *fbcursor)
+{
+	struct osd_cursor_config cursor;
+
+	if (!fbcursor->enable) {
+		osd_device->ops.cursor_disable(osd_device);
+		return 0;
+	}
+
+	cursor.xsize = fbcursor->image.width;
+	cursor.ysize = fbcursor->image.height;
+	cursor.xpos = fbcursor->image.dx;
+	cursor.ypos = fbcursor->image.dy;
+	cursor.interlaced = is_window_interlaced(&info->var);
+	cursor.h_width =
+	    (fbcursor->image.depth > 7) ? 7 : fbcursor->image.depth;
+	cursor.v_width = cursor.h_width;
+	cursor.clut = ROM_CLUT;
+	cursor.clut_index = fbcursor->image.fg_color;
+	osd_device->ops.set_cursor_config(osd_device, &cursor);
+	osd_device->ops.cursor_enable(osd_device);
+
+	return 0;
+}
+
+static int
+davincifb_ioctl(struct fb_info *info, unsigned int cmd,	unsigned long arg)
+{
+	struct vpbe_bitmap_config_params bitmap_conf_params;
+	struct vpbe_video_config_params vid_conf_params;
+	struct vpbe_bitmap_blend_params blend_para;
+	struct vpbe_dm_win_info *win = info->par;
+	void __user *argp = (void __user *)arg;
+	struct vpbe_blink_option blink_option;
+	struct vpbe_backg_color backg_color;
+	struct vpbe_window_position win_pos;
+	struct fb_fillrect rect;
+	struct zoom_params zoom;
+	struct fb_cursor cursor;
+	int retval = 0;
+
+	switch (cmd) {
+	case FBIO_WAITFORVSYNC:
+		/* This ioctl accepts an integer argument to specify a
+		 * display.  We only support one display, so we will
+		 * simply ignore the argument.
+		 */
+		return davincifb_wait_for_vsync(info);
+
+	case FBIO_SETATTRIBUTE:
+		if (copy_from_user(&rect, argp, sizeof(rect)))
+			return -EFAULT;
+		return davincifb_set_attr_blend(info, &rect);
+
+	case FBIO_SETPOSX:
+		return davincifb_setposx(info, arg);
+
+	case FBIO_SETPOSY:
+		return davincifb_setposy(info, arg);
+
+	case FBIO_SETZOOM:
+		if (copy_from_user(&zoom, argp, sizeof(zoom)))
+			return -EFAULT;
+		return davincifb_set_zoom(info, &zoom);
+
+	case FBIO_ENABLE_DISABLE_WIN:
+		return davincifb_enable_disable_win(info, arg);
+
+	case FBIO_SET_BITMAP_BLEND_FACTOR:
+		if (copy_from_user(&blend_para, argp, sizeof(blend_para)))
+			return -EFAULT;
+		return davincifb_bitmap_set_blend_factor(info, &blend_para);
+
+	case FBIO_SET_BITMAP_WIN_RAM_CLUT:
+		if (copy_from_user(win->dm->ram_clut[0], argp, RAM_CLUT_SIZE))
+			return -EFAULT;
+		return davincifb_bitmap_set_ram_clut(info, win->dm->ram_clut);
+
+	case FBIO_ENABLE_DISABLE_ATTRIBUTE_WIN:
+		return davincifb_enable_disable_attribute_window(info, arg);
+
+	case FBIO_GET_BLINK_INTERVAL:
+		retval = davincifb_get_blinking(info, &blink_option);
+		if (retval < 0)
+			return retval;
+		if (copy_to_user(argp, &blink_option, sizeof(blink_option)))
+			return -EFAULT;
+		return 0;
+
+	case FBIO_SET_BLINK_INTERVAL:
+		if (copy_from_user(&blink_option, argp, sizeof(blink_option)))
+			return -EFAULT;
+		return davincifb_set_blinking(info, &blink_option);
+
+	case FBIO_GET_VIDEO_CONFIG_PARAMS:
+		retval = davincifb_get_vid_params(info, &vid_conf_params);
+		if (retval < 0)
+			return retval;
+		if (copy_to_user
+		    (argp, &vid_conf_params, sizeof(vid_conf_params)))
+			return -EFAULT;
+		return 0;
+
+	case FBIO_SET_VIDEO_CONFIG_PARAMS:
+		if (copy_from_user
+		    (&vid_conf_params, argp, sizeof(vid_conf_params)))
+			return -EFAULT;
+		return davincifb_set_vid_params(info, &vid_conf_params);
+
+	case FBIO_GET_BITMAP_CONFIG_PARAMS:
+		retval = davincifb_bitmap_get_params(info, &bitmap_conf_params);
+		if (retval < 0)
+			return retval;
+		if (copy_to_user
+		    (argp, &bitmap_conf_params, sizeof(bitmap_conf_params)))
+			return -EFAULT;
+		return 0;
+
+	case FBIO_SET_BITMAP_CONFIG_PARAMS:
+		if (copy_from_user
+		    (&bitmap_conf_params, argp, sizeof(bitmap_conf_params)))
+			return -EFAULT;
+		return davincifb_bitmap_set_params(info, &bitmap_conf_params);
+
+	case FBIO_SET_BACKG_COLOR:
+		if (copy_from_user(&backg_color, argp, sizeof(backg_color)))
+			return -EFAULT;
+		return davincifb_set_backg_color(info, &backg_color);
+
+	case FBIO_SETPOS:
+		if (copy_from_user(&win_pos, argp, sizeof(win_pos)))
+			return -EFAULT;
+		return davincifb_setpos(info, &win_pos);
+
+	case FBIO_SET_CURSOR:
+		if (copy_from_user(&cursor, argp, sizeof(cursor)))
+			return -EFAULT;
+		return davincifb_set_cursor_params(info, &cursor);
+
+	default:
+		return -EINVAL;
+	}
+}
+
+static int
+davincifb_check_var(struct fb_var_screeninfo *var, struct fb_info *info)
+{
+	struct vpbe_dm_win_info *win = info->par;
+	struct fb_videomode *mode = &win->dm->mode;
+	struct osd_layer_config lconfig;
+	struct fb_fix_screeninfo fix;
+
+	/*
+	 * Get an updated copy of the video mode from the encoder manager, just
+	 * in case the display has been switched.
+	 */
+	get_video_mode(win->dm->vpbe_dev, mode);
+
+	/*
+	 * xres, yres, xres_virtual, or yres_virtual equal to zero is treated as
+	 * a special case.  It indicates that the window should be disabled.  If
+	 * the window is a video window, it will also be released.
+	 */
+	if (var->xres == 0 || var->yres == 0 ||
+	    var->xres_virtual == 0 || var->yres_virtual == 0) {
+		var->xres = 0;
+		var->yres = 0;
+		var->xres_virtual = 0;
+		var->yres_virtual = 0;
+		return 0;
+	}
+
+	switch (var->bits_per_pixel) {
+	case 1:
+	case 2:
+	case 4:
+	case 8:
+	case 16:
+		break;
+	case 24:
+		if (cpu_is_davinci_dm355())
+			return -EINVAL;
+		break;
+	case 32:
+		if (cpu_is_davinci_dm644x())
+			return -EINVAL;
+		break;
+	default:
+		return -EINVAL;
+	}
+	if (var->xres_virtual < var->xres || var->yres_virtual < var->yres)
+		return -EINVAL;
+	if (var->xoffset > var->xres_virtual - var->xres)
+		return -EINVAL;
+	if (var->yoffset > var->yres_virtual - var->yres)
+		return -EINVAL;
+	if (mode->xres < var->xres || mode->yres < var->yres)
+		return -EINVAL;
+	if (win->xpos > mode->xres - var->xres)
+		return -EINVAL;
+	if (win->ypos > mode->yres - var->yres)
+		return -EINVAL;
+	convert_fb_var_to_osd(var, &lconfig, win->dm->yc_pixfmt);
+
+	update_fix_info(var, &fix);
+	lconfig.line_length = fix.line_length;
+	lconfig.xpos = win->xpos;
+	lconfig.ypos = win->ypos;
+	/* xoffset must be a multiple of xpanstep */
+	if (var->xoffset & ~(fix.xpanstep - 1))
+		return -EINVAL;
+
+	/* check if we have enough video memory to support this mode */
+	if (!window_will_fit_framebuffer(var, info->fix.smem_len))
+		return -EINVAL;
+	/* see if the OSD manager approves of this configuration */
+	if (osd_device->ops.try_layer_config(osd_device, win->layer, &lconfig))
+		return -EINVAL;
+	/*
+	 * Reject this var if the OSD manager would have to modify the window
+	 * geometry to make it work.
+	 */
+	if (lconfig.xsize != var->xres || lconfig.ysize != var->yres)
+		return -EINVAL;
+	if (lconfig.xpos != win->xpos || lconfig.ypos != win->ypos)
+		return -EINVAL;
+	/*
+	 * At this point we have accepted the var, so now we convert our layer
+	 * configuration struct back to the var in order to make all of the
+	 * pixel format and geometry values consistent.  The var timing values
+	 * will be unmodified, as we have no way to verify them.
+	 */
+	convert_osd_to_fb_var(&lconfig, var);
+	return 0;
+}
+
+static int davincifb_set_par(struct fb_info *info)
+{
+	struct vpbe_dm_win_info *win = info->par;
+	struct vpbe_device *vpbe_dev = win->dm->vpbe_dev;
+	struct fb_var_screeninfo *var = &info->var;
+	struct osd_layer_config lconfig;
+	struct fb_videomode mode;
+	unsigned start;
+
+	/* update the fix info to be consistent with the var */
+	update_fix_info(var, &info->fix);
+	convert_fb_info_to_osd(info, &lconfig);
+
+	/* See if we need to pass the timing values to the encoder manager. */
+	memcpy(&mode, &win->dm->mode, sizeof(mode));
+	fb_var_to_videomode(&mode, var);
+	mode.name = win->dm->mode.name;
+	if (mode.xres == win->dm->mode.xres && mode.yres ==
+		win->dm->mode.yres && mode.pixclock != 0 &&
+		!fb_mode_is_equal(&mode, &win->dm->mode)) {
+		/*
+		 * If the timing parameters from the var are different than the
+		 * timing parameters from the encoder, try to update the
+		 * timing parameters with the encoder manager.
+		 */
+		set_video_mode(vpbe_dev, &mode);
+	}
+	/* update our copy of the encoder video mode */
+	get_video_mode(vpbe_dev, &win->dm->mode);
+
+	/*
+	 * Update the var with the encoder timing info.  The window geometry
+	 * will be preserved.
+	 */
+	construct_fb_var(var, &win->dm->mode, &lconfig);
+
+	/* need to update interlaced since the mode may have changed */
+	lconfig.interlaced = win->dm->mode.vmode;
+	var->vmode = win->dm->mode.vmode;
+	/*
+	 * xres, yres, xres_virtual, or yres_virtual equal to zero is treated as
+	 * a special case.  It indicates that the window should be disabled.  If
+	 * the window is a video window, it will also be released.
+	 * Note that we disable the window, but we do not set the
+	 * win->disable_window flag.  This allows the window to be re-enabled
+	 * simply by using the FBIOPUT_VSCREENINFO ioctl to set a valid
+	 * configuration.
+	 */
+	if (lconfig.xsize == 0 || lconfig.ysize == 0) {
+		if (win->own_window) {
+			osd_device->ops.disable_layer(osd_device, win->layer);
+			if (is_vid_win(info)) {
+				win->own_window = 0;
+				osd_device->ops.release_layer(osd_device,
+							      win->layer);
+			}
+		}
+		return 0;
+	}
+
+	/*
+	 * If we don't currently own this window, we must claim it from the OSD
+	 * manager.
+	 */
+	if (!win->own_window) {
+		if (osd_device->ops.request_layer(osd_device, win->layer))
+			return -ENODEV;
+		win->own_window = 1;
+	}
+
+	if (!win->own_window) {
+		if (osd_device->ops.request_layer(osd_device, win->layer))
+			return -ENODEV;
+		win->own_window = 1;
+	}
+
+	/* DM365 YUV420 Planar */
+	if (cpu_is_davinci_dm365() && info->var.bits_per_pixel == 8 &&
+	    (win->layer == WIN_VID0 || win->layer == WIN_VID1))
+		start = info->fix.smem_start + (var->xoffset * 12) / 8 +
+			var->yoffset * 3 / 2 * info->fix.line_length;
+	else
+		start = info->fix.smem_start + (var->xoffset *
+			var->bits_per_pixel) / 8 + var->yoffset *
+			info->fix.line_length;
+
+	osd_device->ops.set_layer_config(osd_device, win->layer, &lconfig);
+	osd_device->ops.start_layer(osd_device, win->layer, start,
+						fb_cbcr_ofst);
+	if (win->display_window)
+		osd_device->ops.enable_layer(osd_device,
+				 win->layer, 0);
+
+	return 0;
+}
+
+/*
+ * This macro converts a 16-bit color passed to fb_setcolreg to the width
+ * supported by the pixel format.
+ */
+#define CNVT_TOHW(val, width) ((((val)<<(width))+0x7FFF-(val))>>16)
+
+static int davincifb_setcolreg(unsigned regno, unsigned red, unsigned green,
+			       unsigned blue, unsigned transp,
+			       struct fb_info *info)
+{
+	unsigned r;
+	unsigned g;
+	unsigned b;
+	unsigned t;
+
+	/* no. of hw registers */
+	if (regno >= 256)
+		return -EINVAL;
+
+	/*
+	 * An RGB color palette isn't applicable to a window with a YUV pixel
+	 * format or to a window in attribute mode.
+	 */
+	if (is_yuv(&info->var) || is_attribute_mode(&info->var))
+		return -EINVAL;
+
+	switch (info->fix.visual) {
+	case FB_VISUAL_TRUECOLOR:
+		r = CNVT_TOHW(red, info->var.red.length);
+		g = CNVT_TOHW(green, info->var.green.length);
+		b = CNVT_TOHW(blue, info->var.blue.length);
+		t = CNVT_TOHW(transp, info->var.transp.length);
+		break;
+	case FB_VISUAL_PSEUDOCOLOR:
+	default:
+		r = CNVT_TOHW(red, 8);
+		g = CNVT_TOHW(green, 8);
+		b = CNVT_TOHW(blue, 8);
+		t = 0;
+		break;
+	}
+
+	/* Truecolor has hardware independent palette */
+	if (info->fix.visual == FB_VISUAL_TRUECOLOR) {
+		u32 v;
+
+		if (regno >= 16)
+			return -EINVAL;
+
+		v = (r << info->var.red.offset) |
+		    (g << info->var.green.offset) |
+		    (b << info->var.blue.offset) |
+		    (t << info->var.transp.offset);
+
+		switch (info->var.bits_per_pixel) {
+		case 16:
+			((u16 *)info->pseudo_palette)[regno] = v;
+			break;
+		case 24:
+		case 32:
+			((u32 *)info->pseudo_palette)[regno] = v;
+			break;
+		}
+		return 0;
+	}
+
+	if (!is_osd_win(info))
+		return -EINVAL;
+
+	osd_device->ops.set_clut_rgb(osd_device, regno, r, g, b);
+
+	return 0;
+}
+
+static int venc_is_second_field(struct vpbe_device *vpbe_dev)
+{
+	int ret;
+	int val = 0;
+	ret = v4l2_subdev_call(vpbe_dev->venc, core, ioctl, VENC_GET_FLD,
+				&val);
+	if (ret < 0)
+		dev_err(vpbe_dev->pdev, "Error in getting Field ID 0\n");
+	return val;
+}
+
+/*
+ * davincifb_pan_display(): Pan the display using the `xoffset' and `yoffset'
+ *                          fields of the `var' structure.  We don't support
+ *                          wrapping and ignore the FB_VMODE_YWRAP flag.
+ */
+static int
+davincifb_pan_display(struct fb_var_screeninfo *var, struct fb_info *info)
+{
+	struct vpbe_dm_win_info *win = info->par;
+	struct vpbe_device *vpbe_dev = win->dm->vpbe_dev;
+	unsigned start;
+
+	if (!win->own_window)
+		return -ENODEV;
+
+	if (var->xoffset > info->var.xres_virtual - info->var.xres)
+		return -EINVAL;
+	if (var->yoffset > info->var.yres_virtual - info->var.yres)
+		return -EINVAL;
+
+	/* xoffset must be a multiple of xpanstep */
+	if (var->xoffset & ~(info->fix.xpanstep - 1))
+		return -EINVAL;
+
+	/* For DM365 video windows:
+	 * using bits_per_pixel to calculate start/offset address
+	 * needs to be changed for YUV420 planar format since
+	 * it is 8. But consider CbCr the real (avg) bits per pixel
+	 * is 12. line_length is calcuate using 8, so offset needs
+	 * to time 1.5 to take C plane into account.
+	 */
+	if (cpu_is_davinci_dm365() && info->var.bits_per_pixel == 8 &&
+	    (win->layer == WIN_VID0 || win->layer == WIN_VID1))
+		start = info->fix.smem_start + (var->xoffset * 12) / 8 +
+			var->yoffset * 3 / 2 * info->fix.line_length;
+	else
+		start = info->fix.smem_start + (var->xoffset *
+			info->var.bits_per_pixel) / 8 + var->yoffset *
+			info->fix.line_length;
+
+	if (venc_is_second_field(vpbe_dev))
+		osd_device->ops.start_layer(osd_device, win->layer, start,
+					    fb_cbcr_ofst);
+	else
+		win->sdram_address = start;
+
+	return 0;
+}
+
+/*
+ * davincifb_blank(): Blank the screen if blank_mode != 0, else unblank.
+ */
+int davincifb_blank(int blank_mode, struct fb_info *info)
+{
+	struct vpbe_dm_win_info *win = info->par;
+	int retval = 0;
+
+	if (!win->own_window)
+		return -ENODEV;
+
+	if (blank_mode) {
+		win->display_window = 0;
+		osd_device->ops.disable_layer(osd_device, win->layer);
+		return retval;
+	}
+	win->display_window = 1;
+	retval = info->fbops->fb_check_var(&info->var, info);
+	if (retval)
+		return retval;
+	retval = info->fbops->fb_set_par(info);
+	return retval;
+}
+
+/*
+ *  Frame buffer operations
+ */
+static struct fb_ops vpbe_fb_ops = {
+	.owner = THIS_MODULE,
+	.fb_check_var = davincifb_check_var,
+	.fb_set_par = davincifb_set_par,
+	.fb_setcolreg = davincifb_setcolreg,
+	.fb_blank = davincifb_blank,
+	.fb_pan_display = davincifb_pan_display,
+	.fb_fillrect = cfb_fillrect,
+	.fb_copyarea = cfb_copyarea,
+	.fb_imageblit = cfb_imageblit,
+	.fb_rotate = NULL,
+	.fb_sync = NULL,
+	.fb_ioctl = davincifb_ioctl,
+};
+
+static void davincifb_release_window(struct device *dev,
+				     struct vpbe_dm_win_info *win)
+{
+	struct fb_info *info = win->info;
+
+	if (info) {
+		unregister_framebuffer(info);
+		win->info = NULL;
+	}
+
+	if (win->own_window) {
+		osd_device->ops.release_layer(osd_device,
+				 win->layer);
+		win->own_window = 0;
+	}
+	win->display_window = 0;
+
+	if (info) {
+		dma_free_coherent(dev, info->fix.smem_len, info->screen_base,
+				  info->fix.smem_start);
+		fb_dealloc_cmap(&info->cmap);
+		kfree(info);
+	}
+}
+
+static int davincifb_init_window(struct device *dev,
+				 struct vpbe_dm_win_info *win,
+				 struct osd_layer_config *lconfig,
+				 unsigned fb_size, const char *name)
+{
+	struct fb_info *info;
+	int err = 0;
+
+	if (!fb_size)
+		return 0;
+
+	info = kzalloc(sizeof(*info), GFP_KERNEL);
+	if (!info) {
+		dev_err(dev, "%s: Can't allocate memory for fb_info struct.\n",
+			name);
+		return -ENOMEM;
+	}
+
+	win->info = info;
+	/* initialize fb_info */
+	info->par = win;
+	info->flags = FBINFO_DEFAULT | FBINFO_HWACCEL_COPYAREA |
+		FBINFO_HWACCEL_FILLRECT | FBINFO_HWACCEL_IMAGEBLIT |
+		FBINFO_HWACCEL_XPAN | FBINFO_HWACCEL_YPAN;
+	info->fbops = &vpbe_fb_ops;
+	info->screen_size = fb_size;
+	info->pseudo_palette = win->pseudo_palette;
+	if (fb_alloc_cmap(&info->cmap, 256, 0) < 0) {
+		dev_err(dev, "%s: Can't allocate color map.\n", name);
+		err = -ENODEV;
+		goto cmap_out;
+	}
+
+	/* initialize fb_fix_screeninfo */
+	strlcpy(info->fix.id, name, sizeof(info->fix.id));
+	info->fix.smem_len = fb_size;
+	info->fix.type = FB_TYPE_PACKED_PIXELS;
+
+	/* allocate the framebuffer */
+	info->screen_base =
+		dma_alloc_coherent(dev, info->fix.smem_len,
+				   (dma_addr_t *)&info->fix.smem_start,
+				   GFP_KERNEL | GFP_DMA);
+	if (!info->screen_base) {
+		dev_err(dev, "%s: dma_alloc_coherent failed\n", name);
+		err = -ENOMEM;
+		goto fb_alloc_out;
+	}
+
+	/*
+	 * Fill the framebuffer with zeros unless it is an OSD1 window in
+	 * attribute mode, in which case we fill it with 0x77 to make the OSD0
+	 * pixels opaque.
+	 */
+	memset(info->screen_base,
+	       (lconfig->pixfmt == PIXFMT_OSD_ATTR) ? 0x77 : 0,
+	       info->fix.smem_len);
+
+	/* initialize fb_var_screeninfo */
+	construct_fb_var(&info->var, &win->dm->mode, lconfig);
+	win->xpos = lconfig->xpos;
+	win->ypos = lconfig->ypos;
+	info->var.xres_virtual = info->var.xres;
+	info->var.yres_virtual = info->var.yres;
+
+	/* update the fix info to be consistent with the var */
+	update_fix_info(&info->var, &info->fix);
+
+	/*
+	 * Request ownership of the window from the OSD manager unless this is
+	 * a video window and the window size is 0.
+	 */
+
+	if ((is_osd_win(info) || (info->var.xres != 0 && info->var.yres !=
+	    0)) && !osd_device->ops.request_layer(osd_device, win->layer)) {
+			win->own_window = 1;
+	}
+	/* bail out if this is an OSD window and we don't own it */
+	if (is_osd_win(info) && !win->own_window) {
+		dev_err(dev,
+			"%s:Failed to obtain ownership of OSD window\n", name);
+		err = -ENODEV;
+		goto own_out;
+	}
+
+	win->display_window = 1;
+
+	if (win->own_window) {
+		/* check if our initial window configuration is valid */
+		if (info->fbops->fb_check_var(&info->var, info))
+			dev_warn(dev,
+				 "%s:Initial window configuration is invalid\n",
+				 name);
+		else
+			info->fbops->fb_set_par(info);
+	}
+
+	/* register the framebuffer */
+	if (register_framebuffer(info)) {
+		dev_err(dev, "%s: Failed to register framebuffer.\n", name);
+		err = -ENODEV;
+		goto register_out;
+	}
+
+	dev_info(dev, "%s: %dx%dx%d@%d,%d with framebuffer size %dKB\n",
+		 info->fix.id, info->var.xres, info->var.yres,
+		 info->var.bits_per_pixel, win->xpos, win->ypos,
+		 info->fix.smem_len >> 10);
+
+	return 0;
+
+register_out:
+	if (win->own_window)
+		osd_device->ops.release_layer(osd_device,
+				 win->layer);
+	win->own_window = 0;
+own_out:
+	dma_free_coherent(dev, info->fix.smem_len, info->screen_base,
+			  info->fix.smem_start);
+fb_alloc_out:
+	fb_dealloc_cmap(&info->cmap);
+cmap_out:
+	kfree(info);
+
+	return err;
+}
+
+static int davincifb_remove(struct platform_device *pdev)
+{
+	struct vpbe_dm_info *dm = platform_get_drvdata(pdev);
+	struct vpbe_device *vpbe_dev = dm->vpbe_dev;
+
+	platform_set_drvdata(pdev, NULL);
+
+	v4l2_subdev_call(vpbe_dev->venc, core, ioctl,
+			 VENC_UNREG_CALLBACK, &dm->vsync_callback);
+
+	davincifb_release_window(&pdev->dev, &dm->win[WIN_VID1]);
+	davincifb_release_window(&pdev->dev, &dm->win[WIN_OSD1]);
+	davincifb_release_window(&pdev->dev, &dm->win[WIN_VID0]);
+	davincifb_release_window(&pdev->dev, &dm->win[WIN_OSD0]);
+	kfree(dm);
+
+	return 0;
+}
+
+/*
+ * Return the maximum number of bytes per screen for a display layer at a
+ * resolution specified by an fb_videomode struct.
+ */
+static unsigned davincifb_max_screen_size(enum osd_layer layer,
+					  const struct fb_videomode *mode)
+{
+	unsigned max_bpp = 32;
+	unsigned line_length;
+	unsigned size;
+
+	switch (layer) {
+	case WIN_OSD0:
+	case WIN_OSD1:
+		if (cpu_is_davinci_dm355())
+			max_bpp = 32;
+		else
+			max_bpp = 16;
+		break;
+	case WIN_VID0:
+	case WIN_VID1:
+		if (cpu_is_davinci_dm355())
+			max_bpp = 16;
+		else
+			max_bpp = 24;
+		break;
+	}
+
+	line_length = (mode->xres * max_bpp + 7) / 8;
+	line_length = ((line_length + 31) / 32) * 32;
+	size = mode->yres * line_length;
+
+	return size;
+}
+
+static void parse_win_params(struct vpbe_dm_win_info *win,
+			     struct osd_layer_config *lconfig,
+			     unsigned *fb_size, char *opt)
+{
+	char *s, *p, c = 0;
+	unsigned bits_per_pixel;
+
+	if (!opt)
+		return;
+
+	/* xsize */
+	p = strpbrk(opt, "x,@");
+	if (p)
+		c = *p;
+	s = strsep(&opt, "x,@");
+	if (s == NULL)
+		return;
+	if (*s && kstrtoul(s, 0, (long unsigned*)&lconfig->xsize))
+		goto parse_error;
+	if (!p || !opt)
+		return;
+
+	/* ysize */
+	if (c == 'x') {
+		p = strpbrk(opt, "x,@");
+		if (p)
+			c = *p;
+		s = strsep(&opt, "x,@");
+		if (s == NULL)
+			return;
+		if (*s && kstrtoul(s, 0, (long unsigned*)&lconfig->ysize))
+			goto parse_error;
+		if (!p || !opt)
+			return;
+	}
+
+	/* bits per pixel */
+	if (c == 'x') {
+		p = strpbrk(opt, ",@");
+		if (p)
+			c = *p;
+		s = strsep(&opt, ",@");
+		if (s == NULL)
+			return;
+		if (*s) {
+			if (kstrtoul(s, 0, (long unsigned*)&bits_per_pixel))
+				goto parse_error;
+			switch (bits_per_pixel) {
+			case 1:
+				if (win->layer == WIN_OSD0 ||
+				    win->layer == WIN_OSD1)
+					lconfig->pixfmt = PIXFMT_1BPP;
+				break;
+			case 2:
+				if (win->layer == WIN_OSD0 ||
+				    win->layer == WIN_OSD1)
+					lconfig->pixfmt = PIXFMT_2BPP;
+				break;
+			case 4:
+				if (win->layer == WIN_OSD0 ||
+				    win->layer == WIN_OSD1)
+					lconfig->pixfmt = PIXFMT_4BPP;
+				break;
+			case 8:
+				if (win->layer == WIN_OSD0 ||
+				    win->layer == WIN_OSD1)
+					lconfig->pixfmt = PIXFMT_8BPP;
+				if (cpu_is_davinci_dm365())
+					if (win->layer == WIN_VID0 ||
+					    win->layer == WIN_VID1)
+						lconfig->pixfmt = PIXFMT_NV12;
+				break;
+			case 16:
+				if (win->layer == WIN_OSD0 ||
+				    win->layer == WIN_OSD1)
+					lconfig->pixfmt = PIXFMT_RGB565;
+				else
+					lconfig->pixfmt = win->dm->yc_pixfmt;
+				break;
+			case 24:
+				if (cpu_is_davinci_dm644x() &&
+				    (win->layer == WIN_VID0 ||
+				     win->layer == WIN_VID1))
+					lconfig->pixfmt = PIXFMT_RGB888;
+				break;
+			case 32:
+				if (cpu_is_davinci_dm355() &&
+				    (win->layer == WIN_OSD0 ||
+				     win->layer == WIN_OSD1))
+					lconfig->pixfmt = PIXFMT_RGB888;
+				break;
+			default:
+				break;
+			}
+		}
+		if (!p || !opt)
+			return;
+	}
+
+	/* framebuffer size */
+	if (c == ',') {
+		p = strpbrk(opt, "@");
+		if (p)
+			c = *p;
+		s = strsep(&opt, "@");
+		if (s == NULL)
+			return;
+		if (*s) {
+			*fb_size = simple_strtoul(s, &s, 0);
+			if (*s == 'K')
+				*fb_size <<= 10;
+			if (*s == 'M')
+				*fb_size <<= 20;
+		}
+		if (!p || !opt)
+			return;
+	}
+
+	/* xpos */
+	if (c == '@') {
+		p = strpbrk(opt, ",");
+		if (p)
+			c = *p;
+		s = strsep(&opt, ",");
+		if (s == NULL)
+			return;
+		if (*s && kstrtoul(s, 0, (long unsigned*)&lconfig->xpos))
+			goto parse_error;
+		if (!p || !opt)
+			return;
+	}
+
+	/* ypos */
+	if (c == ',') {
+		s = opt;
+		if (*s && kstrtoul(s, 0, (long unsigned*)&lconfig->ypos))
+			goto parse_error;
+	}
+
+	return;
+parse_error:
+	pr_err("davincifb bootparams parse error\n");
+}
+
+/*
+ * Pass boot-time options by adding the following string to the boot params:
+ *	video=vpbe_fb:options
+ * Valid options:
+ *	osd0=[MxNxP,S at X,Y]
+ *      osd1=[MxNxP,S at X,Y]
+ *	vid0=[off|MxNxP,S at X,Y]
+ *	vid1=[off|MxNxP,S at X,Y]
+ *		MxN are the horizontal and vertical window size
+ *		P is the color depth (bits per pixel)
+ *		S is the framebuffer size with a size suffix such as 'K' or 'M'
+ *		X,Y are the window position
+ *
+ * Only video windows can be turned off.  Turning off a video window means that
+ * no framebuffer device will be registered for it,
+ *
+ * To cause a window to be supported by the framebuffer driver but not displayed
+ * initially, pass a value of 0 struct vpbe_dm_win_info *win = info->par;
+ * struct vpbe_device *vpbe_dev = win->dm->vpbe_dev; for the window size.
+ *
+ * For example:
+ *      video=vpbe_fb:osd0=720x480x16 at 0,0:osd1=720x480:vid0=off:vid1=off
+ *
+ * This routine returns 1 if the window is to be turned off, or 0 otherwise.
+ */
+static int
+davincifb_get_default_win_config(struct device *dev,
+				 struct vpbe_dm_win_info *win,
+				 struct osd_layer_config *lconfig,
+				 unsigned *fb_size,
+				 const char *options)
+{
+	const char *win_names[] = { "osd0=", "vid0=", "osd1=", "vid1=" };
+	static char opt_buf[128];
+	const char *this_opt;
+	const char *next_opt;
+	int this_len;
+	int opt_len;
+
+	/* supply default values for lconfig and fb_size */
+	switch (win->layer) {
+	case WIN_OSD0:
+		lconfig->pixfmt = PIXFMT_RGB565;
+		lconfig->xsize = win->dm->mode.xres;
+		lconfig->ysize = win->dm->mode.yres;
+		break;
+	case WIN_OSD1:
+		lconfig->pixfmt = PIXFMT_OSD_ATTR;
+		lconfig->xsize = win->dm->mode.xres;
+		lconfig->ysize = win->dm->mode.yres;
+		break;
+	case WIN_VID0:
+	case WIN_VID1:
+		lconfig->pixfmt = win->dm->yc_pixfmt;
+		lconfig->xsize = 0;
+		lconfig->ysize = 0;
+		break;
+	}
+	lconfig->xpos = 0;
+	lconfig->ypos = 0;
+
+	lconfig->interlaced = is_display_interlaced(&win->dm->mode);
+	*fb_size = davincifb_max_screen_size(win->layer, &win->dm->mode);
+
+	next_opt = options;
+	while ((this_opt = next_opt)) {
+		this_len = strcspn(this_opt, ":");
+		next_opt = strpbrk(this_opt, ":");
+		if (next_opt)
+			++next_opt;
+
+		opt_len = strlen(win_names[win->layer]);
+		if (this_len >= opt_len) {
+			if (strncmp(this_opt, win_names[win->layer], opt_len))
+				continue;
+			this_len -= opt_len;
+			this_opt += opt_len;
+			if ((this_len >= strlen("off")) &&
+			    !strncmp(this_opt, "off", strlen("off")))
+				return 1;
+			else {
+				strlcpy(opt_buf, this_opt,
+					min_t(int, sizeof(opt_buf),
+					      this_len + 1));
+				parse_win_params(win, lconfig, fb_size,
+						 opt_buf);
+				return 0;
+			}
+		}
+	}
+
+	return 0;
+}
+
+/*
+ *     Module parameter definitions
+ */
+static char *options = "";
+
+module_param(options, charp, S_IRUGO);
+
+static int davincifb_callback_init(struct device *dev, void *data)
+{
+	struct platform_device *pdev = to_platform_device(dev);
+	struct vpbe_dm_info *dm = (struct vpbe_dm_info *)data;
+
+	if (strcmp("vpbe_controller", pdev->name) == 0)
+		dm->vpbe_dev = platform_get_drvdata(pdev);
+
+	return 0;
+}
+
+static int davincifb_device_get(struct device *dev, void *data)
+{
+	struct platform_device *pdev = to_platform_device(dev);
+	if (strstr(pdev->name, "vpbe-osd") != NULL)
+		osd_device = platform_get_drvdata(pdev);
+
+	return 0;
+}
+
+static int davincifb_probe(struct platform_device *pdev)
+{
+	struct osd_layer_config lconfig;
+	struct device_driver *drv;
+	struct vpbe_dm_info *dm;
+	unsigned fb_size;
+	int err;
+
+	dm = kzalloc(sizeof(*dm), GFP_KERNEL);
+	if (!dm) {
+		dev_err(&pdev->dev, "Can't allocate memory for driver state.\n");
+		return -ENOMEM;
+	}
+
+	/*
+	 * Scan all the platform devices to find the vpbe
+	 * controller device and get the vpbe_dev object
+	 */
+	drv = driver_find("vpbe_controller", &platform_bus_type);
+	err = driver_for_each_device(drv, NULL, dm, davincifb_callback_init);
+	if ((err < 0) || (dm->vpbe_dev == NULL))
+		return -ENODEV;
+
+	if (!dm->vpbe_dev->initialized) {
+		dev_err(&pdev->dev, "vpbe controller not initialized\n");
+		return -ENODEV;
+	}
+
+	err = bus_for_each_dev(&platform_bus_type, NULL, NULL,
+			davincifb_device_get);
+	if (err < 0)
+		return err;
+
+	platform_set_drvdata(pdev, dm);
+
+	/* get the video mode from the encoder manager */
+	get_video_mode(dm->vpbe_dev, &dm->mode);
+
+	/* set the default Cb/Cr order */
+	dm->yc_pixfmt = PIXFMT_YCBCRI;
+
+	/* initialize OSD0 */
+	dm->win[WIN_OSD0].layer = WIN_OSD0;
+	dm->win[WIN_OSD0].dm = dm;
+	dm->win[WIN_OSD0].sdram_address = 0;
+	davincifb_get_default_win_config(&pdev->dev, &dm->win[WIN_OSD0],
+					 &lconfig, &fb_size, options);
+	err = davincifb_init_window(&pdev->dev, &dm->win[WIN_OSD0],
+				    &lconfig, fb_size, OSD0_FBNAME);
+	if (err)
+		goto osd0_out;
+
+	/* initialize VID0 */
+	dm->win[WIN_VID0].layer = WIN_VID0;
+	dm->win[WIN_VID0].dm = dm;
+	dm->win[WIN_VID0].sdram_address = 0;
+	if (!davincifb_get_default_win_config(&pdev->dev, &dm->win[WIN_VID0],
+					      &lconfig, &fb_size, options)) {
+		err = davincifb_init_window(&pdev->dev, &dm->win[WIN_VID0],
+					    &lconfig, fb_size, VID0_FBNAME);
+		if (err)
+			goto vid0_out;
+	}
+
+	/* initialize OSD1 */
+	dm->win[WIN_OSD1].layer = WIN_OSD1;
+	dm->win[WIN_OSD1].dm = dm;
+	dm->win[WIN_OSD1].sdram_address = 0;
+	davincifb_get_default_win_config(&pdev->dev, &dm->win[WIN_OSD1],
+					 &lconfig, &fb_size, options);
+	err =
+	    davincifb_init_window(&pdev->dev, &dm->win[WIN_OSD1],
+				  &lconfig, fb_size, OSD1_FBNAME);
+	if (err)
+		goto osd1_out;
+
+	/* initialize VID1 */
+	dm->win[WIN_VID1].layer = WIN_VID1;
+	dm->win[WIN_VID1].dm = dm;
+	dm->win[WIN_VID1].sdram_address = 0;
+	if (!davincifb_get_default_win_config(&pdev->dev, &dm->win[WIN_VID1],
+					      &lconfig, &fb_size, options)) {
+		err = davincifb_init_window(&pdev->dev, &dm->win[WIN_VID1],
+					    &lconfig, fb_size, VID1_FBNAME);
+		if (err)
+			goto vid1_out;
+	}
+
+	/* initialize the vsync wait queue */
+	init_waitqueue_head(&dm->vsync_wait);
+	dm->timeout = HZ / 5;
+
+	/* register the end-of-frame callback */
+	dm->vsync_callback.mask = VENC_FIRST_FIELD |
+	    VENC_SECOND_FIELD | VENC_END_OF_FRAME;
+
+	dm->vsync_callback.handler = davincifb_vsync_callback;
+	dm->vsync_callback.arg = dm;
+
+	v4l2_subdev_call(dm->vpbe_dev->venc, core, ioctl,
+			 VENC_REG_CALLBACK, &dm->vsync_callback);
+
+	dev_info(&pdev->dev, "Davinci VPBE FB Driver probe success\n");
+
+	return 0;
+
+vid1_out:
+	davincifb_release_window(&pdev->dev, &dm->win[WIN_OSD1]);
+osd1_out:
+	davincifb_release_window(&pdev->dev, &dm->win[WIN_VID0]);
+vid0_out:
+	davincifb_release_window(&pdev->dev, &dm->win[WIN_OSD0]);
+osd0_out:
+	kfree(dm);
+
+	return err;
+}
+
+static struct platform_driver davincifb_driver = {
+	.driver = {
+		.name = "davinci-vpbe-fb",
+		.owner = THIS_MODULE,
+		.bus = &platform_bus_type,
+	},
+	.probe = davincifb_probe,
+	.remove = davincifb_remove,
+};
+
+
+static int __init davincifb_init(void)
+{
+#ifndef MODULE
+	{
+		char *names[] = { "vpbe_fb", "dm64xxfb", "dm355fb" };
+		int i, num_names = 3;
+
+		for (i = 0; i < num_names; i++) {
+			if (fb_get_options(names[i], &options)) {
+				pr_err("Disabled on command-line.\n");
+				return -ENODEV;
+			}
+			if (options)
+				break;
+		}
+	}
+#endif
+	/* Register the driver with LDM */
+	if (platform_driver_register(&davincifb_driver)) {
+		pr_err("failed to register vpbe_fb driver\n");
+		return -ENODEV;
+	}
+	return 0;
+}
+
+static void __exit davincifb_cleanup(void)
+{
+	platform_driver_unregister(&davincifb_driver);
+}
+
+late_initcall(davincifb_init);
+module_exit(davincifb_cleanup);
+
+MODULE_DESCRIPTION("TI VPBE Framebuffer driver");
+MODULE_AUTHOR("Texas Instruments Ltd");
+MODULE_LICENSE("GPL");
diff --git a/drivers/video/davincifb.h b/drivers/video/davincifb.h
new file mode 100644
index 0000000..8166b9d9
--- /dev/null
+++ b/drivers/video/davincifb.h
@@ -0,0 +1,194 @@
+/*
+ * Copyright (C) 2009 MontaVista Software Inc.
+ * Copyright (C) 2013 Texas Instruments Inc
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option)any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#ifndef DAVINCIFB_H
+#define DAVINCIFB_H
+
+/* There are 4 framebuffer devices, one per window. */
+#define OSD0_FBNAME "dm_osd0_fb"
+#define OSD1_FBNAME "dm_osd1_fb"
+#define VID0_FBNAME "dm_vid0_fb"
+#define VID1_FBNAME "dm_vid1_fb"
+
+/*  Structure for each window */
+struct vpbe_dm_win_info {
+	struct fb_info *info;
+	struct vpbe_dm_info *dm;
+	enum osd_layer layer;
+	unsigned xpos;
+	unsigned ypos;
+	unsigned own_window; /* Does the framebuffer driver own this window? */
+	unsigned display_window;
+	unsigned sdram_address;
+	unsigned int pseudo_palette[16];
+};
+
+/*
+ * Structure for the driver holding information of windows,
+ *  memory base addresses etc.
+ */
+struct vpbe_dm_info {
+	struct vpbe_dm_win_info win[4];
+
+	wait_queue_head_t vsync_wait;
+	unsigned int vsync_cnt;
+	int timeout;
+	struct venc_callback vsync_callback;
+
+	unsigned char ram_clut[256][3];
+	enum osd_pix_format yc_pixfmt;
+
+	struct fb_videomode mode;
+	struct vpbe_device *vpbe_dev;
+};
+
+struct zoom_params {
+	u_int32_t window_id;
+	u_int32_t zoom_h;
+	u_int32_t zoom_v;
+};
+
+/* Structure for transparency and the blending factor for the bitmap window */
+struct vpbe_bitmap_blend_params {
+	unsigned int colorkey;	/* color key to be blended */
+	unsigned int enable_colorkeying;	/* enable color keying */
+	unsigned int bf;	/* valid range from 0 to 7 only. */
+};
+
+/*  Structure for window expansion  */
+struct vpbe_win_expansion {
+	unsigned char horizontal;
+	unsigned char  vertical;	/* 1: Enable 0:disable */
+};
+
+/*  Structure for OSD window blinking options */
+struct vpbe_blink_option {
+	unsigned char blinking;	/* 1: Enable blinking 0: Disable */
+	unsigned int interval;	/* Valid only if blinking is 1 */
+};
+
+/*  Structure for background color  */
+struct vpbe_backg_color {
+	/* 2: RAM CLUT 1:ROM1 CLUT 0:ROM0 CLUT */
+	unsigned char clut_select;
+	unsigned char color_offset;	/* index of color */
+};
+
+/*  Structure for Video window configurable parameters  */
+struct vpbe_video_config_params {
+	/* Cb/Cr order in input data for a pixel. */
+	unsigned char cb_cr_order;	/*    0: cb cr  1:  cr cb */
+	/* HZ/VT Expansion enable disable */
+	struct vpbe_win_expansion exp_info;
+};
+
+/*
+ * Union of structures giving the CLUT index for the 1, 2, 4 bit bitmap values
+ */
+union vpbe_clut_idx {
+	struct _for_4bit_bitmap {
+		unsigned char bitmap_val_0;
+		unsigned char bitmap_val_1;
+		unsigned char bitmap_val_2;
+		unsigned char bitmap_val_3;
+		unsigned char bitmap_val_4;
+		unsigned char bitmap_val_5;
+		unsigned char bitmap_val_6;
+		unsigned char bitmap_val_7;
+		unsigned char bitmap_val_8;
+		unsigned char bitmap_val_9;
+		unsigned char bitmap_val_10;
+		unsigned char bitmap_val_11;
+		unsigned char bitmap_val_12;
+		unsigned char bitmap_val_13;
+		unsigned char bitmap_val_14;
+		unsigned char bitmap_val_15;
+	} for_4bit_bitmap;
+	struct _for_2bit_bitmap {
+		unsigned char bitmap_val_0;
+		unsigned char dummy0[4];
+		unsigned char bitmap_val_1;
+		unsigned char dummy1[4];
+		unsigned char bitmap_val_2;
+		unsigned char dummy2[4];
+		unsigned char bitmap_val_3;
+	} for_2bit_bitmap;
+	struct _for_1bit_bitmap {
+		unsigned char bitmap_val_0;
+		unsigned char dummy0[14];
+		unsigned char bitmap_val_1;
+	} for_1bit_bitmap;
+};
+
+/* Structure for bitmap window configurable parameters */
+struct vpbe_bitmap_config_params {
+	/* Only for bitmap width = 1,2,4 bits */
+	union vpbe_clut_idx clut_idx;
+	/* Attenuation value for YUV o/p for bitmap window */
+	unsigned char attenuation_enable;
+	/* 0: ROM DM270, 1:ROM DM320, 2:RAM CLUT */
+	unsigned char clut_select;
+};
+
+/* Structure to hold window position */
+struct vpbe_window_position {
+	unsigned int xpos;	/* X position of the window */
+	unsigned int ypos;	/* Y position of the window */
+};
+
+#define	RAM_CLUT_SIZE	(256*3)
+
+#define FBIO_SETATTRIBUTE	_IOW('F', 0x21, struct fb_fillrect)
+#define FBIO_SETPOSX		_IOW('F', 0x22, u_int32_t)
+#define FBIO_SETPOSY		_IOW('F', 0x23, u_int32_t)
+#define FBIO_SETZOOM		_IOW('F', 0x24, struct zoom_params)
+#define FBIO_ENABLE_DISABLE_WIN		\
+	_IOW('F', 0x30, unsigned char)
+#define FBIO_SET_BITMAP_BLEND_FACTOR	\
+	_IOW('F', 0x31, struct vpbe_bitmap_blend_params)
+#define FBIO_SET_BITMAP_WIN_RAM_CLUT	\
+	_IOW('F', 0x32, unsigned char[RAM_CLUT_SIZE])
+#define FBIO_ENABLE_DISABLE_ATTRIBUTE_WIN \
+	_IOW('F', 0x33, unsigned int)
+#define FBIO_GET_BLINK_INTERVAL		\
+	_IOR('F', 0x34, struct vpbe_blink_option)
+#define FBIO_SET_BLINK_INTERVAL		\
+	_IOW('F', 0x35, struct vpbe_blink_option)
+#define FBIO_GET_VIDEO_CONFIG_PARAMS	\
+	_IOR('F', 0x36, struct vpbe_video_config_params)
+#define FBIO_SET_VIDEO_CONFIG_PARAMS	\
+	_IOW('F', 0x37, struct vpbe_video_config_params)
+#define FBIO_GET_BITMAP_CONFIG_PARAMS	\
+	_IOR('F', 0x38, struct vpbe_bitmap_config_params)
+#define FBIO_SET_BITMAP_CONFIG_PARAMS	\
+	_IOW('F', 0x39, struct vpbe_bitmap_config_params)
+#define FBIO_SET_BACKG_COLOR		\
+	_IOW('F', 0x47, struct vpbe_backg_color)
+#define FBIO_SETPOS			\
+	_IOW('F', 0x49, u_int32_t)
+#define FBIO_SET_CURSOR			\
+	_IOW('F', 0x50, struct fb_cursor)
+
+/*  Window ID definitions */
+#define OSD0 0
+#define VID0 1
+#define OSD1 2
+#define VID1 3
+
+#endif		/* DAVINCIFB_H */
-- 
1.7.4.1



From prabhakar.csengg at gmail.com  Wed Apr 24 08:00:08 2013
From: prabhakar.csengg at gmail.com (Prabhakar Lad)
Date: Wed, 24 Apr 2013 17:30:08 +0530
Subject: [PATCH 6/6] ARM: davinci: dm644x: enable fbdev driver
In-Reply-To: <1366804808-22720-1-git-send-email-prabhakar.csengg@gmail.com>
References: <1366804808-22720-1-git-send-email-prabhakar.csengg@gmail.com>
Message-ID: <1366804808-22720-7-git-send-email-prabhakar.csengg@gmail.com>

From: Lad, Prabhakar <prabhakar.csengg at gmail.com>

This patch enables fbdev driver by creating fbdev device and register it.

Signed-off-by: Lad, Prabhakar <prabhakar.csengg at gmail.com>
---
 arch/arm/mach-davinci/dm644x.c |   10 ++++++++++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index c2a9273..a4fee07 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -745,6 +745,15 @@ static struct platform_device dm644x_vpbe_display = {
 	},
 };
 
+static struct platform_device dm644x_davincifb = {
+	.name           = "davinci-vpbe-fb",
+	.id             = -1,
+	.dev            = {
+		.dma_mask		= &dm644x_video_dma_mask,
+		.coherent_dma_mask	= DMA_BIT_MASK(32),
+	},
+};
+
 static struct venc_platform_data dm644x_venc_pdata = {
 	.setup_clock	= dm644x_venc_setup_clock,
 };
@@ -909,6 +918,7 @@ int __init dm644x_init_video(struct vpfe_config *vpfe_cfg,
 		platform_device_register(&dm644x_venc_dev);
 		platform_device_register(&dm644x_vpbe_dev);
 		platform_device_register(&dm644x_vpbe_display);
+		platform_device_register(&dm644x_davincifb);
 	}
 
 	return 0;
-- 
1.7.4.1



From arnd at arndb.de  Wed Apr 24 08:35:50 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed, 24 Apr 2013 14:35:50 +0200
Subject: [PATCH 04/11] dmaengine: dw_dmac: simplify master selection
In-Reply-To: <1366796443-7083-4-git-send-email-andriy.shevchenko@linux.intel.com>
References: <1366796443-7083-1-git-send-email-andriy.shevchenko@linux.intel.com>
 <1366796443-7083-4-git-send-email-andriy.shevchenko@linux.intel.com>
Message-ID: <201304241435.50963.arnd@arndb.de>

On Wednesday 24 April 2013, Andy Shevchenko wrote:
> From: Arnd Bergmann <arnd at arndb.de>
> 
> The patch to add the common DMA binding added a dummy dw_dma_slave
> structure into the dw_dma_chan structure in order to configure the
> masters correctly. It turns out that this can be simplified if we
> pick the DMA masters in the dwc_alloc_chan_resources function instead
> and save them in the dw_dma_chan structure directly.
> 
> This could be simplified further once all users that today use
> dw_dma_slave for configuration get converted to device tree based
> setup instead.
> 
> (Upstream commit id: f776076b9fa82d630651c9af56359d80fce86d68)
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
> Acked-by: Viresh Kumar <viresh.kumar at linaro.org>
> Cc: linux-arm-kernel at lists.infradead.org
> Acked-by: Arnd Bergmann <arnd at arndb.de>
> Signed-off-by: Vinod Koul <vinod.koul at intel.com>

Hi Andy,

Did you intend that to get sent to everyone, or just forget to
pass --suppress-cc=all to git-send-email?

	Arnd


From plagnioj at jcrosoft.com  Wed Apr 24 08:45:20 2013
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Wed, 24 Apr 2013 14:45:20 +0200
Subject: [RFC PATCH v2 03/13] ARM: mach-at91: cpus/cpu node dts updates
In-Reply-To: <20130424092914.GA1561@e102568-lin.cambridge.arm.com>
References: <1366644455-16550-1-git-send-email-lorenzo.pieralisi@arm.com>
 <1366644455-16550-4-git-send-email-lorenzo.pieralisi@arm.com>
 <51768892.7060807@gmail.com>
 <20130423135304.GG22946@e102568-lin.cambridge.arm.com>
 <20130423195259.GJ4998@game.jcrosoft.org>
 <20130424092914.GA1561@e102568-lin.cambridge.arm.com>
Message-ID: <20130424124520.GK4998@game.jcrosoft.org>

On 10:29 Wed 24 Apr     , Lorenzo Pieralisi wrote:
> On Tue, Apr 23, 2013 at 08:52:59PM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > On 14:53 Tue 23 Apr     , Lorenzo Pieralisi wrote:
> > > On Tue, Apr 23, 2013 at 02:11:46PM +0100, Rob Herring wrote:
> > > > On 04/22/2013 10:27 AM, Lorenzo Pieralisi wrote:
> > > > > This patch updates the in-kernel dts files according to the latest cpus
> > > > > and cpu bindings updates for ARM.
> > > > > 
> > > > > Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
> > > > > ---
> > > > >  arch/arm/boot/dts/at91sam9260.dtsi | 2 +-
> > > > >  arch/arm/boot/dts/at91sam9263.dtsi | 2 +-
> > > > >  arch/arm/boot/dts/at91sam9g45.dtsi | 2 +-
> > > > >  arch/arm/boot/dts/at91sam9n12.dtsi | 2 +-
> > > > >  4 files changed, 4 insertions(+), 4 deletions(-)
> > > > > 
> > > > > diff --git a/arch/arm/boot/dts/at91sam9260.dtsi b/arch/arm/boot/dts/at91sam9260.dtsi
> > > > > index cb7bcc5..2e9de85 100644
> > > > > --- a/arch/arm/boot/dts/at91sam9260.dtsi
> > > > > +++ b/arch/arm/boot/dts/at91sam9260.dtsi
> > > > > @@ -33,7 +33,7 @@
> > > > >  	};
> > > > >  	cpus {
> > > > >  		cpu at 0 {
> > > > > -			compatible = "arm,arm926ejs";
> > > > > +			compatible = "arm,arm926";
> > > > 
> > > > I don't understand why you are doing this. If this does not match the
> > > > documentation, fix the documentation. We can't continue on changing dts
> > > > files without reqard to breaking compatibility.
> > > 
> > > IMHO compatibility is already broken. There are a number of dts in the
> > > kernel missing cpus and cpu nodes, others with cpu nodes missing
> > > device_type = "cpu", missing cpu nodes compatible properties and the list
> > > goes on and on. Those files got merged in the kernel before bindings were
> > > properly defined for ARM so at that point in time the only reference was the
> > > ePAPR and still, it was not followed (eg my broken patch above fails to add
> > > device_type = "cpu" to the cpu node, should I change the documentation (ePAPR)
> > > to make the dts above compliant ? I do not think so, I reckon we should fix
> > > all dts and force them to comply with the ePAPR and the in-kernel bindings).
> > > 
> > > If we do not set in stone the bindings and draw a line now, this stuff will
> > > go wild, it is already in a state that I do not like much.
> > > 
> > > The reason we are patching the compatible property above is to avoid having
> > > compatible properties containing suffixes for CPUs, we do not deem that
> > > necessary, see:
> > > 
> > > http://lists.infradead.org/pipermail/linux-arm-kernel/2013-January/145305.html
> > > 
> > > That's just my opinion, open to change it to find a proper solution to this
> > > issue as long as we make progress.
> > 
> > I do not agree when you set the compatible you need to be preceise the cpu is
> > a arm926ejs not a arm926
> 
> I updated the bindings with all processor variants so that we will all
> be happy again (I hope). My comments still stand though and these dts need
> patching, I am posting the required changes in v3.

ok tks put me in Cc for at91

Best Regards,
J.
> 
> Lorenzo
> 


From arnd at arndb.de  Wed Apr 24 08:52:10 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed, 24 Apr 2013 14:52:10 +0200
Subject: [PATCH] ASoC: don't call of_dma_request_slave_channel directly
In-Reply-To: <20130424011153.GA2319@shlinux1.ap.freescale.net>
References: <1366732475-479886-1-git-send-email-arnd@arndb.de>
 <1366732475-479886-3-git-send-email-arnd@arndb.de>
 <20130424011153.GA2319@shlinux1.ap.freescale.net>
Message-ID: <201304241452.10298.arnd@arndb.de>

On Wednesday 24 April 2013, Shawn Guo wrote:
> On Tue, Apr 23, 2013 at 05:54:33PM +0200, Arnd Bergmann wrote:
> > The exported interface for device drivers is dma_request_slave_channel,
> > not of_dma_request_slave_channel. The former does not depend on device
> > tree but also works with ACPI and other interfaces providing an
> > abstraction for DMA channels.
> > 
> > This fixes link errors when building ALSA as a loadable module.
> > 
> > Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> 
> I had already sent a similar patch [1] for that.
> 

Yes, I see it in linux-next now.

Thanks,

	Arnd


From marc.zyngier at arm.com  Wed Apr 24 09:06:41 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 24 Apr 2013 14:06:41 +0100
Subject: [PATCH v3 24/32] arm64: KVM: 32bit GP register access
In-Reply-To: <20130423230039.GI20569@gmail.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
 <1365437854-30214-25-git-send-email-marc.zyngier@arm.com>
 <20130423230039.GI20569@gmail.com>
Message-ID: <5177D8E1.6010903@arm.com>

On 24/04/13 00:00, Christoffer Dall wrote:
> On Mon, Apr 08, 2013 at 05:17:26PM +0100, Marc Zyngier wrote:
>> Allow access to the 32bit register file through the usual API.
>>
>> Reviewed-by: Christopher Covington <cov at codeaurora.org>
>> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
>> ---
>>  arch/arm64/include/asm/kvm_emulate.h |  17 +++-
>>  arch/arm64/kvm/Makefile              |   2 +-
>>  arch/arm64/kvm/regmap.c              | 168 +++++++++++++++++++++++++++++++++++
>>  3 files changed, 184 insertions(+), 3 deletions(-)
>>  create mode 100644 arch/arm64/kvm/regmap.c
>>
>> diff --git a/arch/arm64/include/asm/kvm_emulate.h b/arch/arm64/include/asm/kvm_emulate.h
>> index 2dcfa74..37a6567 100644
>> --- a/arch/arm64/include/asm/kvm_emulate.h
>> +++ b/arch/arm64/include/asm/kvm_emulate.h
>> @@ -28,6 +28,9 @@
>>  #include <asm/kvm_mmio.h>
>>  #include <asm/ptrace.h>
>>  
>> +unsigned long *vcpu_reg32(const struct kvm_vcpu *vcpu, u8 reg_num);
>> +unsigned long *vcpu_spsr32(const struct kvm_vcpu *vcpu);
>> +
>>  void kvm_inject_undefined(struct kvm_vcpu *vcpu);
>>  void kvm_inject_dabt(struct kvm_vcpu *vcpu, unsigned long addr);
>>  void kvm_inject_pabt(struct kvm_vcpu *vcpu, unsigned long addr);
>> @@ -49,7 +52,7 @@ static inline unsigned long *vcpu_cpsr(const struct kvm_vcpu *vcpu)
>>  
>>  static inline bool vcpu_mode_is_32bit(const struct kvm_vcpu *vcpu)
>>  {
>> -	return false;	/* 32bit? Bahhh... */
>> +	return !!(*vcpu_cpsr(vcpu) & PSR_MODE32_BIT);
> 
> nit: you don't need the '!!': it's a bool

No it is not. It is a bitwise and, turned into a bool.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...



From marc.zyngier at arm.com  Wed Apr 24 09:13:37 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 24 Apr 2013 14:13:37 +0100
Subject: [PATCH v3 25/32] arm64: KVM: 32bit conditional execution emulation
In-Reply-To: <20130423230057.GJ20569@gmail.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
 <1365437854-30214-26-git-send-email-marc.zyngier@arm.com>
 <20130423230057.GJ20569@gmail.com>
Message-ID: <5177DA81.3020400@arm.com>

On 24/04/13 00:00, Christoffer Dall wrote:
> On Mon, Apr 08, 2013 at 05:17:27PM +0100, Marc Zyngier wrote:
>> As conditional instructions can trap on AArch32, add the thinest
>> possible emulation layer to keep 32bit guests happy.
>>
>> Reviewed-by: Christopher Covington <cov at codeaurora.org>
>> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
>> ---
>>  arch/arm64/include/asm/kvm_emulate.h |  13 ++-
>>  arch/arm64/kvm/Makefile              |   2 +-
>>  arch/arm64/kvm/emulate.c             | 154 +++++++++++++++++++++++++++++++++++
>>  3 files changed, 166 insertions(+), 3 deletions(-)
>>  create mode 100644 arch/arm64/kvm/emulate.c
>>
>> diff --git a/arch/arm64/include/asm/kvm_emulate.h b/arch/arm64/include/asm/kvm_emulate.h
>> index 37a6567..8d4ab33 100644
>> --- a/arch/arm64/include/asm/kvm_emulate.h
>> +++ b/arch/arm64/include/asm/kvm_emulate.h
>> @@ -31,6 +31,9 @@
>>  unsigned long *vcpu_reg32(const struct kvm_vcpu *vcpu, u8 reg_num);
>>  unsigned long *vcpu_spsr32(const struct kvm_vcpu *vcpu);
>>  
>> +bool kvm_condition_valid32(const struct kvm_vcpu *vcpu);
>> +void kvm_skip_instr32(struct kvm_vcpu *vcpu, bool is_wide_instr);
>> +
>>  void kvm_inject_undefined(struct kvm_vcpu *vcpu);
>>  void kvm_inject_dabt(struct kvm_vcpu *vcpu, unsigned long addr);
>>  void kvm_inject_pabt(struct kvm_vcpu *vcpu, unsigned long addr);
>> @@ -57,12 +60,18 @@ static inline bool vcpu_mode_is_32bit(const struct kvm_vcpu *vcpu)
>>  
>>  static inline bool kvm_condition_valid(const struct kvm_vcpu *vcpu)
>>  {
>> -	return true;	/* No conditionals on arm64 */
>> +	if (vcpu_mode_is_32bit(vcpu))
>> +		return kvm_condition_valid32(vcpu);
>> +
>> +	return true;
>>  }
>>  
>>  static inline void kvm_skip_instr(struct kvm_vcpu *vcpu, bool is_wide_instr)
>>  {
>> -	*vcpu_pc(vcpu) += 4;
>> +	if (vcpu_mode_is_32bit(vcpu))
>> +		kvm_skip_instr32(vcpu, is_wide_instr);
>> +	else
>> +		*vcpu_pc(vcpu) += 4;
>>  }
>>  
>>  static inline void vcpu_set_thumb(struct kvm_vcpu *vcpu)
>> diff --git a/arch/arm64/kvm/Makefile b/arch/arm64/kvm/Makefile
>> index 1668448..88c6639 100644
>> --- a/arch/arm64/kvm/Makefile
>> +++ b/arch/arm64/kvm/Makefile
>> @@ -11,7 +11,7 @@ obj-$(CONFIG_KVM_ARM_HOST) += kvm.o
>>  kvm-$(CONFIG_KVM_ARM_HOST) += $(addprefix ../../../virt/kvm/, kvm_main.o coalesced_mmio.o)
>>  kvm-$(CONFIG_KVM_ARM_HOST) += $(addprefix ../../../arch/arm/kvm/, arm.o mmu.o mmio.o psci.o perf.o)
>>  
>> -kvm-$(CONFIG_KVM_ARM_HOST) += inject_fault.o regmap.o
>> +kvm-$(CONFIG_KVM_ARM_HOST) += emulate.o inject_fault.o regmap.o
>>  kvm-$(CONFIG_KVM_ARM_HOST) += hyp.o hyp-init.o handle_exit.o
>>  kvm-$(CONFIG_KVM_ARM_HOST) += guest.o reset.o sys_regs.o sys_regs_generic_v8.o
>>  
>> diff --git a/arch/arm64/kvm/emulate.c b/arch/arm64/kvm/emulate.c
>> new file mode 100644
>> index 0000000..01d4713
>> --- /dev/null
>> +++ b/arch/arm64/kvm/emulate.c
>> @@ -0,0 +1,154 @@
>> +/*
>> + * (not much of an) Emulation layer for 32bit guests.
>> + *
>> + * Copyright (C) 2012 - Virtual Open Systems and Columbia University
>> + * Author: Christoffer Dall <c.dall at virtualopensystems.com>
> 
> don't you want to add yourself here?

There's really nothing I actually wrote here. Most of it is your code,
and the rest comes from other parts of arch/arm.

I guess I could always mention myself for the ESR_EL2_* macros... ;-)

>> + *
>> + * 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.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
>> + */
>> +
>> +#include <linux/kvm_host.h>
>> +#include <asm/kvm_emulate.h>
>> +
>> +/*
>> + * stolen from arch/arm/kernel/opcodes.c
>> + *
>> + * condition code lookup table
>> + * index into the table is test code: EQ, NE, ... LT, GT, AL, NV
>> + *
>> + * bit position in short is condition code: NZCV
>> + */
>> +static const unsigned short cc_map[16] = {
>> +	0xF0F0,			/* EQ == Z set            */
>> +	0x0F0F,			/* NE                     */
>> +	0xCCCC,			/* CS == C set            */
>> +	0x3333,			/* CC                     */
>> +	0xFF00,			/* MI == N set            */
>> +	0x00FF,			/* PL                     */
>> +	0xAAAA,			/* VS == V set            */
>> +	0x5555,			/* VC                     */
>> +	0x0C0C,			/* HI == C set && Z clear */
>> +	0xF3F3,			/* LS == C clear || Z set */
>> +	0xAA55,			/* GE == (N==V)           */
>> +	0x55AA,			/* LT == (N!=V)           */
>> +	0x0A05,			/* GT == (!Z && (N==V))   */
>> +	0xF5FA,			/* LE == (Z || (N!=V))    */
>> +	0xFFFF,			/* AL always              */
>> +	0			/* NV                     */
>> +};
>> +
>> +static int kvm_vcpu_get_condition(const struct kvm_vcpu *vcpu)
>> +{
>> +	u32 esr = kvm_vcpu_get_hsr(vcpu);
>> +
>> +	if (esr & ESR_EL2_CV)
>> +		return (esr & ESR_EL2_COND) >> ESR_EL2_COND_SHIFT;
>> +
>> +	return -1;
>> +}
>> +
>> +/*
>> + * Check if a trapped instruction should have been executed or not.
>> + */
>> +bool kvm_condition_valid32(const struct kvm_vcpu *vcpu)
>> +{
>> +	unsigned long cpsr;
>> +	u32 cpsr_cond;
>> +	int cond;
>> +
>> +	/* Top two bits non-zero?  Unconditional. */
>> +	if (kvm_vcpu_get_hsr(vcpu) >> 30)
>> +		return true;
>> +
>> +	/* Is condition field valid? */
>> +	cond = kvm_vcpu_get_condition(vcpu);
>> +	if (cond == 0xE)
>> +		return true;
>> +
>> +	cpsr = *vcpu_cpsr(vcpu);
>> +
>> +	if (cond < 0) {
>> +		/* This can happen in Thumb mode: examine IT state. */
>> +		unsigned long it;
>> +
>> +		it = ((cpsr >> 8) & 0xFC) | ((cpsr >> 25) & 0x3);
>> +
>> +		/* it == 0 => unconditional. */
>> +		if (it == 0)
>> +			return true;
>> +
>> +		/* The cond for this insn works out as the top 4 bits. */
>> +		cond = (it >> 4);
>> +	}
>> +
>> +	cpsr_cond = cpsr >> 28;
>> +
>> +	if (!((cc_map[cond] >> cpsr_cond) & 1))
>> +		return false;
>> +
>> +	return true;
>> +}
>> +
>> +/**
>> + * adjust_itstate - adjust ITSTATE when emulating instructions in IT-block
>> + * @vcpu:	The VCPU pointer
>> + *
>> + * When exceptions occur while instructions are executed in Thumb IF-THEN
>> + * blocks, the ITSTATE field of the CPSR is not advanved (updated), so we have
> 
> s/advanved/advanced/

See? You actually hold the copyright on that spelling mistake! ;-)
> 
>> + * to do this little bit of work manually. The fields map like this:
>> + *
>> + * IT[7:0] -> CPSR[26:25],CPSR[15:10]
>> + */
>> +static void kvm_adjust_itstate(struct kvm_vcpu *vcpu)
>> +{
>> +	unsigned long itbits, cond;
>> +	unsigned long cpsr = *vcpu_cpsr(vcpu);
>> +	bool is_arm = !(cpsr & COMPAT_PSR_T_BIT);
>> +
>> +	BUG_ON(is_arm && (cpsr & COMPAT_PSR_IT_MASK));
>> +
>> +	if (!(cpsr & COMPAT_PSR_IT_MASK))
>> +		return;
>> +
>> +	cond = (cpsr & 0xe000) >> 13;
>> +	itbits = (cpsr & 0x1c00) >> (10 - 2);
>> +	itbits |= (cpsr & (0x3 << 25)) >> 25;
>> +
>> +	/* Perform ITAdvance (see page A-52 in ARM DDI 0406C) */
> 
> That's actually page A2-52 to be a little more precise...

Yup. Feel free to update the 32bit code as well... ;-)

>> +	if ((itbits & 0x7) == 0)
>> +		itbits = cond = 0;
>> +	else
>> +		itbits = (itbits << 1) & 0x1f;
>> +
>> +	cpsr &= ~COMPAT_PSR_IT_MASK;
>> +	cpsr |= cond << 13;
>> +	cpsr |= (itbits & 0x1c) << (10 - 2);
>> +	cpsr |= (itbits & 0x3) << 25;
>> +	*vcpu_cpsr(vcpu) = cpsr;
>> +}
>> +
>> +/**
>> + * kvm_skip_instr - skip a trapped instruction and proceed to the next
>> + * @vcpu: The vcpu pointer
>> + */
>> +void kvm_skip_instr32(struct kvm_vcpu *vcpu, bool is_wide_instr)
>> +{
>> +	bool is_thumb;
>> +
>> +	is_thumb = !!(*vcpu_cpsr(vcpu) & COMPAT_PSR_T_BIT);
> 
> again we don't need the '!!' when it's a bool.

I'm still not prepared to consider a bitwise and as a bool, and I'm
happy for the !! to make the conversion to a bool completely obvious.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...



From mpa at pengutronix.de  Wed Apr 24 09:26:21 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Wed, 24 Apr 2013 15:26:21 +0200
Subject: [PATCH v4 2/2] video: imxfb: Add DT support
In-Reply-To: <20130422155125.GI4998@game.jcrosoft.org>
References: <1366290183-367-1-git-send-email-mpa@pengutronix.de>
 <1366290183-367-3-git-send-email-mpa@pengutronix.de>
 <20130418160614.GF4998@game.jcrosoft.org>
 <20130421081115.GA31179@pengutronix.de>
 <20130422155125.GI4998@game.jcrosoft.org>
Message-ID: <20130424132621.GG3973@pengutronix.de>

On Mon, Apr 22, 2013 at 05:51:25PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 10:11 Sun 21 Apr     , Markus Pargmann wrote:
> > On Thu, Apr 18, 2013 at 06:06:14PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > > On 15:03 Thu 18 Apr     , Markus Pargmann wrote:
> > > > Add devicetree support for imx framebuffer driver. It uses the generic
> > > > display bindings and helper functions.
> > > > 
> > > > Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
> > > > Cc: Fabio Estevam <festevam at gmail.com>
> > > > Cc: Mark Rutland <mark.rutland at arm.com>
> > > > ---
> > > > 
> > > > Notes:
> > > >     Changes in v4:
> > > >     - Remove eukrea specific dmacr property.
> > > >     - Add optional dmacr property. If not present, the dmacr reset value is not
> > > >       changed.
> > > >     
> > > >     Changes in v3:
> > > >     - Fix returncodes of of_read_mode function and print error messages
> > > >     - Introduce a lower bound check for bits per pixel
> > > >     - Calculate correct bytes per pixel value before using it for the calculation of
> > > >     	memory size
> > > >     - Change DT property names
> > > >     
> > > >     Changes in v2:
> > > >     - Removed pwmr register property
> > > >     - Cleanup of devicetree binding documentation
> > > >     - Use default values for pwmr and lscr1
> > > > 
> > > >  .../devicetree/bindings/video/fsl,imx-fb.txt       |  51 ++++++
> > > >  drivers/video/imxfb.c                              | 194 +++++++++++++++++----
> > > >  2 files changed, 210 insertions(+), 35 deletions(-)
> > > >  create mode 100644 Documentation/devicetree/bindings/video/fsl,imx-fb.txt
> > > > 
> > > > diff --git a/Documentation/devicetree/bindings/video/fsl,imx-fb.txt b/Documentation/devicetree/bindings/video/fsl,imx-fb.txt
> > > > new file mode 100644
> > > > index 0000000..aff16a4
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/video/fsl,imx-fb.txt
> > > > @@ -0,0 +1,51 @@
> > > > +Freescale imx21 Framebuffer
> > > > +
> > > > +This framebuffer driver supports devices imx1, imx21, imx25, and imx27.
> > > > +
> > > > +Required properties:
> > > > +- compatible : "fsl,<chip>-fb", chip should be imx1 or imx21
> > > > +- reg : Should contain 1 register ranges(address and length)
> > > > +- interrupts : One interrupt of the fb dev
> > > > +
> > > > +Required nodes:
> > > > +- display: Phandle to a display node as described in
> > > > +	Documentation/devicetree/bindings/video/display-timing.txt
> > > > +	Additional, the display node has to define properties:
> > > > +	- fsl,bpp: Bits per pixel
> > > > +	- fsl,pcr: LCDC PCR value
> > > > +
> > > > +Optional properties:
> > > > +- fsl,dmacr: DMA Control Register value. This is optional. By default, the
> > > > +	register is not modified as recommended by the datasheet.
> > > > +- fsl,lscr1: LCDC Sharp Configuration Register value.
> > > > +
> > > > +Example:
> > > > +
> > > > +	imxfb: fb at 10021000 {
> > > > +		compatible = "fsl,imx27-fb", "fsl,imx21-fb";
> > > you put both when in the doc you request one
> > 
> > Thanks, fixed.
> > 
> > > > +		interrupts = <61>;
> > > > +		reg = <0x10021000 0x1000>;
> > > > +		display = <&display0>;
> > > > +	};
> > > > +
> > > > +	...
> > > > +
> > > > +	display0: display0 {
> > > > +		model = "Primeview-PD050VL1";
> > > > +		native-mode = <&timing_disp0>;
> > > > +		fsl,bpp = <16>;		/* non-standard but required */
> > > there is a generic binding bit-per-pixel use a cross other IP
> > 
> > I can't find a generic binding for that. There are only 2 other drivers
> > using a "bpp" property, but they both use it within different contexts.
> > tilcdc panel uses it within a "panel-info" property and via,vt8500-fb
> > within modes. So I think it would be better to use a clear distinction
> > because there is no generic binding. That was also suggested in comments
> > on version 2 of this patch:
> > https://patchwork.kernel.org/patch/2220511/
> 
> via use bits-per-pixel
> atmel ditto
> mxs ditto IIRC
> 
> Best Regards,
> J.

Thanks, I renamed fsl,bpp to bits-per-pixel in v5.

Regards,

Markus

> > 
> > Regards,
> > 
> > Markus
> > 
> > > > +		fsl,pcr = <0xf0c88080>;	/* non-standard but required */
> > > > +		display-timings {
> > > > +			timing_disp0: 640x480 {
> > > > +				hactive = <640>;
> > > > +				vactive = <480>;
> > > > +				hback-porch = <112>;
> > > > +				hfront-porch = <36>;
> > > > +				hsync-len = <32>;
> > > > +				vback-porch = <33>;
> > > > +				vfront-porch = <33>;
> > > > +				vsync-len = <2>;
> > > > +				clock-frequency = <25000000>;
> > > > +			};
> > > > +		};
> > > > +	};
> > > > diff --git a/drivers/video/imxfb.c b/drivers/video/imxfb.c
> > > > index ef2b587..e0230f8 100644
> > > > --- a/drivers/video/imxfb.c
> > > > +++ b/drivers/video/imxfb.c
> > > > @@ -32,6 +32,12 @@
> > > >  #include <linux/io.h>
> > > >  #include <linux/math64.h>
> > > >  #include <linux/uaccess.h>
> > > > +#include <linux/of.h>
> > > > +#include <linux/of_device.h>
> > > > +
> > > > +#include <video/of_display_timing.h>
> > > > +#include <video/of_videomode.h>
> > > > +#include <video/videomode.h>
> > > >  
> > > >  #include <linux/platform_data/video-imxfb.h>
> > > >  
> > > > @@ -117,10 +123,11 @@
> > > >  #define LGWCR_GWAV(alpha)	(((alpha) & 0xff) << 24)
> > > >  #define LGWCR_GWE	(1 << 22)
> > > >  
> > > > +#define IMXFB_LSCR1_DEFAULT 0x00120300
> > > > +
> > > >  /* Used fb-mode. Can be set on kernel command line, therefore file-static. */
> > > >  static const char *fb_mode;
> > > >  
> > > > -
> > > >  /*
> > > >   * These are the bitfields for each
> > > >   * display depth that we support.
> > > > @@ -192,6 +199,19 @@ static struct platform_device_id imxfb_devtype[] = {
> > > >  };
> > > >  MODULE_DEVICE_TABLE(platform, imxfb_devtype);
> > > >  
> > > > +static struct of_device_id imxfb_of_dev_id[] = {
> > > > +	{
> > > > +		.compatible = "fsl,imx1-fb",
> > > > +		.data = &imxfb_devtype[IMX1_FB],
> > > > +	}, {
> > > > +		.compatible = "fsl,imx21-fb",
> > > > +		.data = &imxfb_devtype[IMX21_FB],
> > > > +	}, {
> > > > +		/* sentinel */
> > > > +	}
> > > > +};
> > > > +MODULE_DEVICE_TABLE(of, imxfb_of_dev_id);
> > > > +
> > > >  static inline int is_imx1_fb(struct imxfb_info *fbi)
> > > >  {
> > > >  	return fbi->devtype == IMX1_FB;
> > > > @@ -324,6 +344,9 @@ static const struct imx_fb_videomode *imxfb_find_mode(struct imxfb_info *fbi)
> > > >  	struct imx_fb_videomode *m;
> > > >  	int i;
> > > >  
> > > > +	if (!fb_mode)
> > > > +		return &fbi->mode[0];
> > > > +
> > > >  	for (i = 0, m = &fbi->mode[0]; i < fbi->num_modes; i++, m++) {
> > > >  		if (!strcmp(m->mode.name, fb_mode))
> > > >  			return m;
> > > > @@ -479,6 +502,9 @@ static int imxfb_bl_update_status(struct backlight_device *bl)
> > > >  	struct imxfb_info *fbi = bl_get_data(bl);
> > > >  	int brightness = bl->props.brightness;
> > > >  
> > > > +	if (!fbi->pwmr)
> > > > +		return 0;
> > > > +
> > > >  	if (bl->props.power != FB_BLANK_UNBLANK)
> > > >  		brightness = 0;
> > > >  	if (bl->props.fb_blank != FB_BLANK_UNBLANK)
> > > > @@ -719,10 +745,14 @@ static int imxfb_activate_var(struct fb_var_screeninfo *var, struct fb_info *inf
> > > >  
> > > >  	writel(fbi->pcr, fbi->regs + LCDC_PCR);
> > > >  #ifndef PWMR_BACKLIGHT_AVAILABLE
> > > > -	writel(fbi->pwmr, fbi->regs + LCDC_PWMR);
> > > > +	if (fbi->pwmr)
> > > > +		writel(fbi->pwmr, fbi->regs + LCDC_PWMR);
> > > >  #endif
> > > >  	writel(fbi->lscr1, fbi->regs + LCDC_LSCR1);
> > > > -	writel(fbi->dmacr, fbi->regs + LCDC_DMACR);
> > > > +
> > > > +	/* dmacr = 0 is no valid value, as we need DMA control marks. */
> > > > +	if (fbi->dmacr)
> > > > +		writel(fbi->dmacr, fbi->regs + LCDC_DMACR);
> > > >  
> > > >  	return 0;
> > > >  }
> > > > @@ -758,13 +788,12 @@ static int imxfb_resume(struct platform_device *dev)
> > > >  #define imxfb_resume	NULL
> > > >  #endif
> > > >  
> > > > -static int __init imxfb_init_fbinfo(struct platform_device *pdev)
> > > > +static int imxfb_init_fbinfo(struct platform_device *pdev)
> > > >  {
> > > >  	struct imx_fb_platform_data *pdata = pdev->dev.platform_data;
> > > >  	struct fb_info *info = dev_get_drvdata(&pdev->dev);
> > > >  	struct imxfb_info *fbi = info->par;
> > > > -	struct imx_fb_videomode *m;
> > > > -	int i;
> > > > +	struct device_node *np;
> > > >  
> > > >  	pr_debug("%s\n",__func__);
> > > >  
> > > > @@ -795,41 +824,95 @@ static int __init imxfb_init_fbinfo(struct platform_device *pdev)
> > > >  	info->fbops			= &imxfb_ops;
> > > >  	info->flags			= FBINFO_FLAG_DEFAULT |
> > > >  					  FBINFO_READS_FAST;
> > > > -	info->var.grayscale		= pdata->cmap_greyscale;
> > > > -	fbi->cmap_inverse		= pdata->cmap_inverse;
> > > > -	fbi->cmap_static		= pdata->cmap_static;
> > > > -	fbi->lscr1			= pdata->lscr1;
> > > > -	fbi->dmacr			= pdata->dmacr;
> > > > -	fbi->pwmr			= pdata->pwmr;
> > > > -	fbi->lcd_power			= pdata->lcd_power;
> > > > -	fbi->backlight_power		= pdata->backlight_power;
> > > > -
> > > > -	for (i = 0, m = &pdata->mode[0]; i < pdata->num_modes; i++, m++)
> > > > -		info->fix.smem_len = max_t(size_t, info->fix.smem_len,
> > > > -				m->mode.xres * m->mode.yres * m->bpp / 8);
> > > > +	if (pdata) {
> > > > +		info->var.grayscale		= pdata->cmap_greyscale;
> > > > +		fbi->cmap_inverse		= pdata->cmap_inverse;
> > > > +		fbi->cmap_static		= pdata->cmap_static;
> > > > +		fbi->lscr1			= pdata->lscr1;
> > > > +		fbi->dmacr			= pdata->dmacr;
> > > > +		fbi->pwmr			= pdata->pwmr;
> > > > +		fbi->lcd_power			= pdata->lcd_power;
> > > > +		fbi->backlight_power		= pdata->backlight_power;
> > > > +	} else {
> > > > +		np = pdev->dev.of_node;
> > > > +		info->var.grayscale = of_property_read_bool(np,
> > > > +						"cmap-greyscale");
> > > > +		fbi->cmap_inverse = of_property_read_bool(np, "cmap-inverse");
> > > > +		fbi->cmap_static = of_property_read_bool(np, "cmap-static");
> > > > +
> > > > +		fbi->lscr1 = IMXFB_LSCR1_DEFAULT;
> > > > +		of_property_read_u32(np, "fsl,lscr1", &fbi->lscr1);
> > > > +
> > > > +		of_property_read_u32(np, "fsl,dmacr", &fbi->dmacr);
> > > > +
> > > > +		/* These two function pointers could be used by some specific
> > > > +		 * platforms. */
> > > > +		fbi->lcd_power = NULL;
> > > > +		fbi->backlight_power = NULL;
> > > > +	}
> > > > +
> > > > +	return 0;
> > > > +}
> > > > +
> > > > +static int imxfb_of_read_mode(struct device *dev, struct device_node *np,
> > > > +		struct imx_fb_videomode *imxfb_mode)
> > > > +{
> > > > +	int ret;
> > > > +	struct fb_videomode *of_mode = &imxfb_mode->mode;
> > > > +	u32 bpp;
> > > > +	u32 pcr;
> > > > +
> > > > +	ret = of_property_read_string(np, "model", &of_mode->name);
> > > > +	if (ret)
> > > > +		of_mode->name = NULL;
> > > > +
> > > > +	ret = of_get_fb_videomode(np, of_mode, OF_USE_NATIVE_MODE);
> > > > +	if (ret) {
> > > > +		dev_err(dev, "Failed to get videomode from DT\n");
> > > > +		return ret;
> > > > +	}
> > > > +
> > > > +	ret = of_property_read_u32(np, "fsl,bpp", &bpp);
> > > > +	ret |= of_property_read_u32(np, "fsl,pcr", &pcr);
> > > > +
> > > > +	if (ret) {
> > > > +		dev_err(dev, "Failed to read bpp and pcr from DT\n");
> > > > +		return -EINVAL;
> > > > +	}
> > > > +
> > > > +	if (bpp < 1 || bpp > 255) {
> > > > +		dev_err(dev, "Bits per pixel have to be between 1 and 255\n");
> > > > +		return -EINVAL;
> > > > +	}
> > > > +
> > > > +	imxfb_mode->bpp = bpp;
> > > > +	imxfb_mode->pcr = pcr;
> > > >  
> > > >  	return 0;
> > > >  }
> > > >  
> > > > -static int __init imxfb_probe(struct platform_device *pdev)
> > > > +static int imxfb_probe(struct platform_device *pdev)
> > > >  {
> > > >  	struct imxfb_info *fbi;
> > > >  	struct fb_info *info;
> > > >  	struct imx_fb_platform_data *pdata;
> > > >  	struct resource *res;
> > > > +	struct imx_fb_videomode *m;
> > > > +	const struct of_device_id *of_id;
> > > >  	int ret, i;
> > > > +	int bytes_per_pixel;
> > > >  
> > > >  	dev_info(&pdev->dev, "i.MX Framebuffer driver\n");
> > > >  
> > > > +	of_id = of_match_device(imxfb_of_dev_id, &pdev->dev);
> > > > +	if (of_id)
> > > > +		pdev->id_entry = of_id->data;
> > > > +
> > > >  	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > > >  	if (!res)
> > > >  		return -ENODEV;
> > > >  
> > > >  	pdata = pdev->dev.platform_data;
> > > > -	if (!pdata) {
> > > > -		dev_err(&pdev->dev,"No platform_data available\n");
> > > > -		return -ENOMEM;
> > > > -	}
> > > >  
> > > >  	info = framebuffer_alloc(sizeof(struct imxfb_info), &pdev->dev);
> > > >  	if (!info)
> > > > @@ -837,15 +920,55 @@ static int __init imxfb_probe(struct platform_device *pdev)
> > > >  
> > > >  	fbi = info->par;
> > > >  
> > > > -	if (!fb_mode)
> > > > -		fb_mode = pdata->mode[0].mode.name;
> > > > -
> > > >  	platform_set_drvdata(pdev, info);
> > > >  
> > > >  	ret = imxfb_init_fbinfo(pdev);
> > > >  	if (ret < 0)
> > > >  		goto failed_init;
> > > >  
> > > > +	if (pdata) {
> > > > +		if (!fb_mode)
> > > > +			fb_mode = pdata->mode[0].mode.name;
> > > > +
> > > > +		fbi->mode = pdata->mode;
> > > > +		fbi->num_modes = pdata->num_modes;
> > > > +	} else {
> > > > +		struct device_node *display_np;
> > > > +		fb_mode = NULL;
> > > > +
> > > > +		display_np = of_parse_phandle(pdev->dev.of_node, "display", 0);
> > > > +		if (!display_np) {
> > > > +			dev_err(&pdev->dev, "No display defined in devicetree\n");
> > > > +			ret = -EINVAL;
> > > > +			goto failed_of_parse;
> > > > +		}
> > > > +
> > > > +		/*
> > > > +		 * imxfb does not support more modes, we choose only the native
> > > > +		 * mode.
> > > > +		 */
> > > > +		fbi->num_modes = 1;
> > > > +
> > > > +		fbi->mode = devm_kzalloc(&pdev->dev,
> > > > +				sizeof(struct imx_fb_videomode), GFP_KERNEL);
> > > > +		if (!fbi->mode) {
> > > > +			ret = -ENOMEM;
> > > > +			goto failed_of_parse;
> > > > +		}
> > > > +
> > > > +		ret = imxfb_of_read_mode(&pdev->dev, display_np, fbi->mode);
> > > > +		if (ret)
> > > > +			goto failed_of_parse;
> > > > +	}
> > > > +
> > > > +	/* Calculate maximum bytes used per pixel. In most cases this should
> > > > +	 * be the same as m->bpp/8 */
> > > > +	m = &fbi->mode[0];
> > > > +	bytes_per_pixel = (m->bpp + 7) / 8;
> > > > +	for (i = 0; i < fbi->num_modes; i++, m++)
> > > > +		info->fix.smem_len = max_t(size_t, info->fix.smem_len,
> > > > +				m->mode.xres * m->mode.yres * bytes_per_pixel);
> > > > +
> > > >  	res = request_mem_region(res->start, resource_size(res),
> > > >  				DRIVER_NAME);
> > > >  	if (!res) {
> > > > @@ -878,7 +1001,8 @@ static int __init imxfb_probe(struct platform_device *pdev)
> > > >  		goto failed_ioremap;
> > > >  	}
> > > >  
> > > > -	if (!pdata->fixed_screen_cpu) {
> > > > +	/* Seems not being used by anyone, so no support for oftree */
> > > > +	if (!pdata || !pdata->fixed_screen_cpu) {
> > > >  		fbi->map_size = PAGE_ALIGN(info->fix.smem_len);
> > > >  		fbi->map_cpu = dma_alloc_writecombine(&pdev->dev,
> > > >  				fbi->map_size, &fbi->map_dma, GFP_KERNEL);
> > > > @@ -903,18 +1027,16 @@ static int __init imxfb_probe(struct platform_device *pdev)
> > > >  		info->fix.smem_start = fbi->screen_dma;
> > > >  	}
> > > >  
> > > > -	if (pdata->init) {
> > > > +	if (pdata && pdata->init) {
> > > >  		ret = pdata->init(fbi->pdev);
> > > >  		if (ret)
> > > >  			goto failed_platform_init;
> > > >  	}
> > > >  
> > > > -	fbi->mode = pdata->mode;
> > > > -	fbi->num_modes = pdata->num_modes;
> > > >  
> > > >  	INIT_LIST_HEAD(&info->modelist);
> > > > -	for (i = 0; i < pdata->num_modes; i++)
> > > > -		fb_add_videomode(&pdata->mode[i].mode, &info->modelist);
> > > > +	for (i = 0; i < fbi->num_modes; i++)
> > > > +		fb_add_videomode(&fbi->mode[i].mode, &info->modelist);
> > > >  
> > > >  	/*
> > > >  	 * This makes sure that our colour bitfield
> > > > @@ -944,10 +1066,10 @@ static int __init imxfb_probe(struct platform_device *pdev)
> > > >  failed_register:
> > > >  	fb_dealloc_cmap(&info->cmap);
> > > >  failed_cmap:
> > > > -	if (pdata->exit)
> > > > +	if (pdata && pdata->exit)
> > > >  		pdata->exit(fbi->pdev);
> > > >  failed_platform_init:
> > > > -	if (!pdata->fixed_screen_cpu)
> > > > +	if (pdata && !pdata->fixed_screen_cpu)
> > > >  		dma_free_writecombine(&pdev->dev,fbi->map_size,fbi->map_cpu,
> > > >  			fbi->map_dma);
> > > >  failed_map:
> > > > @@ -956,6 +1078,7 @@ failed_ioremap:
> > > >  failed_getclock:
> > > >  	release_mem_region(res->start, resource_size(res));
> > > >  failed_req:
> > > > +failed_of_parse:
> > > >  	kfree(info->pseudo_palette);
> > > >  failed_init:
> > > >  	platform_set_drvdata(pdev, NULL);
> > > > @@ -980,7 +1103,7 @@ static int imxfb_remove(struct platform_device *pdev)
> > > >  	unregister_framebuffer(info);
> > > >  
> > > >  	pdata = pdev->dev.platform_data;
> > > > -	if (pdata->exit)
> > > > +	if (pdata && pdata->exit)
> > > >  		pdata->exit(fbi->pdev);
> > > >  
> > > >  	fb_dealloc_cmap(&info->cmap);
> > > > @@ -1009,6 +1132,7 @@ static struct platform_driver imxfb_driver = {
> > > >  	.shutdown	= imxfb_shutdown,
> > > >  	.driver		= {
> > > >  		.name	= DRIVER_NAME,
> > > > +		.of_match_table = imxfb_of_dev_id,
> > > >  	},
> > > >  	.id_table	= imxfb_devtype,
> > > >  };
> > > > -- 
> > > > 1.8.1.5
> > > > 
> > > 
> > 
> > -- 
> > Pengutronix e.K.                           |                             |
> > Industrial Linux Solutions                 | http://www.pengutronix.de/  |
> > Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
> > Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
> 

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From daniel.lezcano at linaro.org  Wed Apr 24 09:34:23 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Wed, 24 Apr 2013 15:34:23 +0200
Subject: [PATCH] cpuidle: add maintainer entry
Message-ID: <1366810463-17495-1-git-send-email-daniel.lezcano@linaro.org>

Currently the cpuidle drivers are spread across the different archs.

The patch submission for cpuidle are following different path: the cpuidle core
code goes to linux-pm, the ARM drivers goes to arm-soc or the SoC specific
tree, sh goes through sh arch tree, pseries goes through PowerPC and
finally intel goes through Len's tree while acpi_idle goes under linux-pm.

That makes difficult to consolidate the code and to propagate modifications
from the cpuidle core to the different drivers.

Hopefully, a movement has initiated to put the cpuidle drivers into the
drivers/cpuidle directory like cpuidle-calxeda.c and cpuidle-kirkwood.c

Add an explicit maintainer entry in the MAINTAINER to clarify the situation
and prevent new cpuidle drivers to goes to an arch directory.

The upstreaming process is unchanged: Rafael takes the patches to merge them
into its tree but with the acked-by from the driver's maintainer. So the header
must contains the name of the maintainer.

This organization will be the same than cpufreq.

Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
---
 MAINTAINERS                        |    7 +++++++
 drivers/cpuidle/cpuidle-calxeda.c  |    4 +++-
 drivers/cpuidle/cpuidle-kirkwood.c |    5 +++--
 3 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 61677c3..effa0f3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2206,6 +2206,13 @@ S:	Maintained
 F:	drivers/cpufreq/
 F:	include/linux/cpufreq.h
 
+CPUIDLE DRIVERS
+M:	Rafael J. Wysocki <rjw at sisk.pl>
+L:	linux-pm at vger.kernel.org
+S:	Maintained
+F:	drivers/cpuidle/*
+F:	include/linux/cpuidle.h
+
 CPU FREQUENCY DRIVERS - ARM BIG LITTLE
 M:	Viresh Kumar <viresh.kumar at linaro.org>
 M:	Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
diff --git a/drivers/cpuidle/cpuidle-calxeda.c b/drivers/cpuidle/cpuidle-calxeda.c
index e344b56..2378c39 100644
--- a/drivers/cpuidle/cpuidle-calxeda.c
+++ b/drivers/cpuidle/cpuidle-calxeda.c
@@ -1,7 +1,6 @@
 /*
  * Copyright 2012 Calxeda, Inc.
  *
- * Based on arch/arm/plat-mxc/cpuidle.c:
  * Copyright 2012 Freescale Semiconductor, Inc.
  * Copyright 2012 Linaro Ltd.
  *
@@ -16,6 +15,9 @@
  *
  * You should have received a copy of the GNU General Public License along with
  * this program.  If not, see <http://www.gnu.org/licenses/>.
+ *
+ * Author    : Rob Herring <rob.herring at calxeda.com>
+ * Maintainer: Rob Herring <rob.herring at calxeda.com>
  */
 
 #include <linux/cpuidle.h>
diff --git a/drivers/cpuidle/cpuidle-kirkwood.c b/drivers/cpuidle/cpuidle-kirkwood.c
index 53290e1..521b0a7 100644
--- a/drivers/cpuidle/cpuidle-kirkwood.c
+++ b/drivers/cpuidle/cpuidle-kirkwood.c
@@ -1,6 +1,4 @@
 /*
- * arch/arm/mach-kirkwood/cpuidle.c
- *
  * CPU idle Marvell Kirkwood SoCs
  *
  * This file is licensed under the terms of the GNU General Public
@@ -11,6 +9,9 @@
  * to implement two idle states -
  * #1 wait-for-interrupt
  * #2 wait-for-interrupt and DDR self refresh
+ *
+ * Maintainer: Jason Cooper <jason at lakedaemon.net>
+ * Maintainer: Andrew Lunn <andrew at lunn.ch>
  */
 
 #include <linux/kernel.h>
-- 
1.7.9.5



From andriy.shevchenko at linux.intel.com  Wed Apr 24 09:35:42 2013
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Wed, 24 Apr 2013 16:35:42 +0300
Subject: [PATCH 04/11] dmaengine: dw_dmac: simplify master selection
In-Reply-To: <201304241435.50963.arnd@arndb.de>
References: <1366796443-7083-1-git-send-email-andriy.shevchenko@linux.intel.com>
 <1366796443-7083-4-git-send-email-andriy.shevchenko@linux.intel.com>
 <201304241435.50963.arnd@arndb.de>
Message-ID: <1366810542.31721.21.camel@smile>

On Wed, 2013-04-24 at 14:35 +0200, Arnd Bergmann wrote: 
> On Wednesday 24 April 2013, Andy Shevchenko wrote:
> > From: Arnd Bergmann <arnd at arndb.de>
> > 
> > The patch to add the common DMA binding added a dummy dw_dma_slave
> > structure into the dw_dma_chan structure in order to configure the
> > masters correctly. It turns out that this can be simplified if we
> > pick the DMA masters in the dwc_alloc_chan_resources function instead
> > and save them in the dw_dma_chan structure directly.
> > 
> > This could be simplified further once all users that today use
> > dw_dma_slave for configuration get converted to device tree based
> > setup instead.
> > 
> > (Upstream commit id: f776076b9fa82d630651c9af56359d80fce86d68)
> > 
> > Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> > Signed-off-by: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
> > Acked-by: Viresh Kumar <viresh.kumar at linaro.org>
> > Cc: linux-arm-kernel at lists.infradead.org
> > Acked-by: Arnd Bergmann <arnd at arndb.de>
> > Signed-off-by: Vinod Koul <vinod.koul at intel.com>
> 
> Hi Andy,
> 
> Did you intend that to get sent to everyone, or just forget to
> pass --suppress-cc=all to git-send-email?

Second. Sorry for spam.


-- 
Andy Shevchenko <andriy.shevchenko at linux.intel.com>
Intel Finland Oy


From marc.zyngier at arm.com  Wed Apr 24 09:37:30 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 24 Apr 2013 14:37:30 +0100
Subject: [PATCH v3 10/32] arm64: KVM: system register handling
In-Reply-To: <20130423230138.GK20569@gmail.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
 <1365437854-30214-11-git-send-email-marc.zyngier@arm.com>
 <20130423230138.GK20569@gmail.com>
Message-ID: <5177E01A.1030908@arm.com>

On 24/04/13 00:01, Christoffer Dall wrote:
> On Mon, Apr 08, 2013 at 05:17:12PM +0100, Marc Zyngier wrote:
>> Provide 64bit system register handling, modeled after the cp15
>> handling for ARM.
>>
>> Reviewed-by: Christopher Covington <cov at codeaurora.org>
>> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
>> ---
>>  arch/arm64/include/asm/kvm_coproc.h |  51 +++
>>  arch/arm64/include/uapi/asm/kvm.h   |  29 ++
>>  arch/arm64/kvm/sys_regs.c           | 871 ++++++++++++++++++++++++++++++++++++
>>  arch/arm64/kvm/sys_regs.h           | 138 ++++++
>>  include/uapi/linux/kvm.h            |   1 +
>>  5 files changed, 1090 insertions(+)
>>  create mode 100644 arch/arm64/include/asm/kvm_coproc.h
>>  create mode 100644 arch/arm64/kvm/sys_regs.c
>>  create mode 100644 arch/arm64/kvm/sys_regs.h
>>
>> diff --git a/arch/arm64/include/asm/kvm_coproc.h b/arch/arm64/include/asm/kvm_coproc.h
>> new file mode 100644
>> index 0000000..9b4477a
>> --- /dev/null
>> +++ b/arch/arm64/include/asm/kvm_coproc.h
>> @@ -0,0 +1,51 @@
>> +/*
>> + * Copyright (C) 2012,2013 - ARM Ltd
>> + * Author: Marc Zyngier <marc.zyngier at arm.com>
>> + *
>> + * Derived from arch/arm/include/asm/kvm_coproc.h
>> + * Copyright (C) 2012 Rusty Russell IBM Corporation
>> + *
>> + * 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.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
>> + */
>> +
>> +#ifndef __ARM64_KVM_COPROC_H__
>> +#define __ARM64_KVM_COPROC_H__
>> +
>> +#include <linux/kvm_host.h>
>> +
>> +void kvm_reset_sys_regs(struct kvm_vcpu *vcpu);
>> +
>> +struct kvm_sys_reg_table {
>> + const struct sys_reg_desc *table;
>> + size_t num;
>> +};
>> +
>> +struct kvm_sys_reg_target_table {
>> + struct kvm_sys_reg_table table64;
>> +};
>> +
>> +void kvm_register_target_sys_reg_table(unsigned int target,
>> +       struct kvm_sys_reg_target_table *table);
>> +
>> +int kvm_handle_sys_reg(struct kvm_vcpu *vcpu, struct kvm_run *run);
>> +
>> +#define kvm_coproc_table_init kvm_sys_reg_table_init
>> +void kvm_sys_reg_table_init(void);
>> +
>> +struct kvm_one_reg;
>> +int kvm_arm_copy_sys_reg_indices(struct kvm_vcpu *vcpu, u64 __user *uindices);
>> +int kvm_arm_sys_reg_get_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *);
>> +int kvm_arm_sys_reg_set_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *);
>> +unsigned long kvm_arm_num_sys_reg_descs(struct kvm_vcpu *vcpu);
>> +
>> +#endif /* __ARM64_KVM_COPROC_H__ */
>> diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
>> index 4e64570..ebac919 100644
>> --- a/arch/arm64/include/uapi/asm/kvm.h
>> +++ b/arch/arm64/include/uapi/asm/kvm.h
>> @@ -92,6 +92,35 @@ struct kvm_sync_regs {
>>  struct kvm_arch_memory_slot {
>>  };
>>
>> +/* If you need to interpret the index values, here is the key: */
>> +#define KVM_REG_ARM_COPROC_MASK 0x000000000FFF0000
>> +#define KVM_REG_ARM_COPROC_SHIFT 16
>> +
>> +/* Normal registers are mapped as coprocessor 16. */
>> +#define KVM_REG_ARM_CORE (0x0010 << KVM_REG_ARM_COPROC_SHIFT)
>> +#define KVM_REG_ARM_CORE_REG(name) (offsetof(struct kvm_regs, name) / sizeof(__u32))
>> +
>> +/* Some registers need more space to represent values. */
>> +#define KVM_REG_ARM_DEMUX (0x0011 << KVM_REG_ARM_COPROC_SHIFT)
>> +#define KVM_REG_ARM_DEMUX_ID_MASK 0x000000000000FF00
>> +#define KVM_REG_ARM_DEMUX_ID_SHIFT 8
>> +#define KVM_REG_ARM_DEMUX_ID_CCSIDR (0x00 << KVM_REG_ARM_DEMUX_ID_SHIFT)
>> +#define KVM_REG_ARM_DEMUX_VAL_MASK 0x00000000000000FF
>> +#define KVM_REG_ARM_DEMUX_VAL_SHIFT 0
>> +
>> +/* AArch64 system registers */
>> +#define KVM_REG_ARM64_SYSREG (0x0013 << KVM_REG_ARM_COPROC_SHIFT)
>> +#define KVM_REG_ARM64_SYSREG_OP0_MASK 0x000000000000c000
>> +#define KVM_REG_ARM64_SYSREG_OP0_SHIFT 14
>> +#define KVM_REG_ARM64_SYSREG_OP1_MASK 0x0000000000003800
>> +#define KVM_REG_ARM64_SYSREG_OP1_SHIFT 11
>> +#define KVM_REG_ARM64_SYSREG_CRN_MASK 0x0000000000000780
>> +#define KVM_REG_ARM64_SYSREG_CRN_SHIFT 7
>> +#define KVM_REG_ARM64_SYSREG_CRM_MASK 0x0000000000000078
>> +#define KVM_REG_ARM64_SYSREG_CRM_SHIFT 3
>> +#define KVM_REG_ARM64_SYSREG_OP2_MASK 0x0000000000000007
>> +#define KVM_REG_ARM64_SYSREG_OP2_SHIFT 0
>> +
>>  /* KVM_IRQ_LINE irq field index values */
>>  #define KVM_ARM_IRQ_TYPE_SHIFT 24
>>  #define KVM_ARM_IRQ_TYPE_MASK 0xff
>> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
>> new file mode 100644
>> index 0000000..9df3b32
>> --- /dev/null
>> +++ b/arch/arm64/kvm/sys_regs.c
>> @@ -0,0 +1,871 @@
>> +/*
>> + * Copyright (C) 2012,2013 - ARM Ltd
>> + * Author: Marc Zyngier <marc.zyngier at arm.com>
>> + *
>> + * Derived from arch/arm/kvm/coproc.c:
>> + * Copyright (C) 2012 - Virtual Open Systems and Columbia University
>> + * Authors: Rusty Russell <rusty at rustcorp.com.au>
>> + *          Christoffer Dall <c.dall at virtualopensystems.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.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
>> + */
>> +
>> +#include <linux/mm.h>
>> +#include <linux/kvm_host.h>
>> +#include <linux/uaccess.h>
>> +#include <asm/kvm_arm.h>
>> +#include <asm/kvm_host.h>
>> +#include <asm/kvm_emulate.h>
>> +#include <asm/kvm_coproc.h>
>> +#include <asm/cacheflush.h>
>> +#include <asm/cputype.h>
>> +#include <trace/events/kvm.h>
>> +
>> +#include "sys_regs.h"
>> +
>> +/*
>> + * All of this file is extremly similar to the ARM coproc.c, but the
>> + * types are different. My gut feeling is that it should be pretty
>> + * easy to merge, but that would be an ABI breakage -- again. VFP
>> + * would also need to be abstracted.
>> + */
> 
> What API would we break here by sharing more of the code? Can you
> elaborate.

The sys_regs encoding has 5 fields, while cp15 only has 4. If we change
this, we break the ABI.

> VFP should probably be separated into its own file on the arm side as
> well in any case.
> 
>> +
>> +/* 3 bits per cache level, as per CLIDR, but non-existent caches always 0 */
>> +static u32 cache_levels;
>> +
>> +/* CSSELR values; used to index KVM_REG_ARM_DEMUX_ID_CCSIDR */
>> +#define CSSELR_MAX 12
>> +
>> +/* Which cache CCSIDR represents depends on CSSELR value. */
>> +static u32 get_ccsidr(u32 csselr)
>> +{
>> + u32 ccsidr;
>> +
>> + /* Make sure noone else changes CSSELR during this! */
>> + local_irq_disable();
>> + /* Put value into CSSELR */
>> + asm volatile("msr csselr_el1, %x0" : : "r" (csselr));
>> + /* Read result out of CCSIDR */
>> + asm volatile("mrs %0, ccsidr_el1" : "=r" (ccsidr));
>> + local_irq_enable();
>> +
>> + return ccsidr;
>> +}
>> +
>> +static void do_dc_cisw(u32 val)
>> +{
>> + asm volatile("dc cisw, %x0" : : "r" (val));
>> +}
>> +
>> +static void do_dc_csw(u32 val)
>> +{
>> + asm volatile("dc csw, %x0" : : "r" (val));
>> +}
>> +
>> +/* See note at ARM ARM B1.14.4 */
>> +static bool access_dcsw(struct kvm_vcpu *vcpu,
>> + const struct sys_reg_params *p,
>> + const struct sys_reg_desc *r)
>> +{
>> + unsigned long val;
>> + int cpu;
>> +
>> + cpu = get_cpu();
> 
> you have that unbalanced get_cpu here again, but you know that
> already...

I do. It's fixed in my tree already.

[...]

>> +static int emulate_sys_reg(struct kvm_vcpu *vcpu,
>> +   const struct sys_reg_params *params)
>> +{
>> + size_t num;
>> + const struct sys_reg_desc *table, *r;
>> +
>> + table = get_target_table(vcpu->arch.target, &num);
>> +
>> + /* Search target-specific then generic table. */
>> + r = find_reg(params, table, num);
>> + if (!r)
>> + r = find_reg(params, sys_reg_descs, ARRAY_SIZE(sys_reg_descs));
>> +
>> + if (likely(r)) {
>> + /* If we don't have an accessor, we should never get here! */
>> + BUG_ON(!r->access);
> 
> that's a little rough, you don't have to stop the entire host kernel...

I'm not sure. It means you've decided to trap a sys_reg, but you're not
prepared to handle it... Surely that's a bug.

I'll probably turn that into an UNDEF and a big fat screaming warning,
but you may want to do something about it on the 32bit side too.

[...]

>> +/* ->val is filled in by kvm_invariant_sys_reg_table_init() */
> 
> kvm_sys_reg_table_init ?

Ah, yes. Thanks.

>> +static struct sys_reg_desc invariant_sys_regs[] = {
>> + { Op0(0b11), Op1(0b000), CRn(0b0000), CRm(0b0000), Op2(0b000),
>> +  NULL, get_midr_el1 },
>> + { Op0(0b11), Op1(0b000), CRn(0b0000), CRm(0b0000), Op2(0b110),
>> +  NULL, get_revidr_el1 },
>> + { Op0(0b11), Op1(0b000), CRn(0b0000), CRm(0b0001), Op2(0b000),
>> +  NULL, get_id_pfr0_el1 },
>> + { Op0(0b11), Op1(0b000), CRn(0b0000), CRm(0b0001), Op2(0b001),
>> +  NULL, get_id_pfr1_el1 },
>> + { Op0(0b11), Op1(0b000), CRn(0b0000), CRm(0b0001), Op2(0b010),
>> +  NULL, get_id_dfr0_el1 },
>> + { Op0(0b11), Op1(0b000), CRn(0b0000), CRm(0b0001), Op2(0b011),
>> +  NULL, get_id_afr0_el1 },
>> + { Op0(0b11), Op1(0b000), CRn(0b0000), CRm(0b0001), Op2(0b100),
>> +  NULL, get_id_mmfr0_el1 },
>> + { Op0(0b11), Op1(0b000), CRn(0b0000), CRm(0b0001), Op2(0b101),
>> +  NULL, get_id_mmfr1_el1 },
>> + { Op0(0b11), Op1(0b000), CRn(0b0000), CRm(0b0001), Op2(0b110),
>> +  NULL, get_id_mmfr2_el1 },
>> + { Op0(0b11), Op1(0b000), CRn(0b0000), CRm(0b0001), Op2(0b111),
>> +  NULL, get_id_mmfr3_el1 },
>> + { Op0(0b11), Op1(0b000), CRn(0b0000), CRm(0b0010), Op2(0b000),
>> +  NULL, get_id_isar0_el1 },
>> + { Op0(0b11), Op1(0b000), CRn(0b0000), CRm(0b0010), Op2(0b001),
>> +  NULL, get_id_isar1_el1 },
>> + { Op0(0b11), Op1(0b000), CRn(0b0000), CRm(0b0010), Op2(0b010),
>> +  NULL, get_id_isar2_el1 },
>> + { Op0(0b11), Op1(0b000), CRn(0b0000), CRm(0b0010), Op2(0b011),
>> +  NULL, get_id_isar3_el1 },
>> + { Op0(0b11), Op1(0b000), CRn(0b0000), CRm(0b0010), Op2(0b100),
>> +  NULL, get_id_isar4_el1 },
>> + { Op0(0b11), Op1(0b000), CRn(0b0000), CRm(0b0010), Op2(0b101),
>> +  NULL, get_id_isar5_el1 },
>> + { Op0(0b11), Op1(0b001), CRn(0b0000), CRm(0b0000), Op2(0b001),
>> +  NULL, get_clidr_el1 },
>> + { Op0(0b11), Op1(0b001), CRn(0b0000), CRm(0b0000), Op2(0b111),
>> +  NULL, get_aidr_el1 },
>> + { Op0(0b11), Op1(0b011), CRn(0b0000), CRm(0b0000), Op2(0b001),
>> +  NULL, get_ctr_el0 },
>> +};
> 
> would you consider using spaces instead of tabs here, this becomes completely unreadable on an 80 chars display...

Sure.

[...]

>> +static bool is_valid_cache(u32 val)
>> +{
>> + u32 level, ctype;
>> +
>> + if (val >= CSSELR_MAX)
>> + return -ENOENT;
>> +
>> + /* Bottom bit is Instruction or Data bit.  Next 3 bits are level. */
>> +        level = (val >> 1);
>> +        ctype = (cache_levels >> (level * 3)) & 7;
> 
> replace spaces with tab here

OK.

[...]

>> +int kvm_arm_sys_reg_get_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
>> +{
>> + const struct sys_reg_desc *r;
>> + void __user *uaddr = (void __user *)(unsigned long)reg->addr;
>> +
>> + if ((reg->id & KVM_REG_ARM_COPROC_MASK) == KVM_REG_ARM_DEMUX)
>> + return demux_c15_get(reg->id, uaddr);
>> +
>> + r = index_to_sys_reg_desc(vcpu, reg->id);
>> + if (!r)
>> + return get_invariant_sys_reg(reg->id, uaddr);
>> +
>> + /* Note: copies two regs if size is 64 bit. */
> 
> is this still true?

Hmmm... Not any more. It is actually an arbitrary size, and should be
validated.

	M.
-- 
Jazz is not dead. It just smells funny...



From linux at roeck-us.net  Wed Apr 24 09:38:56 2013
From: linux at roeck-us.net (Guenter Roeck)
Date: Wed, 24 Apr 2013 06:38:56 -0700
Subject: [PATCHv1 1/3] hwmon: Add support for GMT G762/G763 PWM fan
 controller
In-Reply-To: <87obd4wb4e.fsf@natisbad.org>
References: <cover.1366753420.git.arno@natisbad.org>
 <63961d39aee9db94767f28fd441312bec2029473.1366753420.git.arno@natisbad.org>
 <20130424053758.GC8710@lunn.ch> <87obd4wb4e.fsf@natisbad.org>
Message-ID: <20130424133856.GA18851@roeck-us.net>

On Wed, Apr 24, 2013 at 11:06:57AM +0200, Arnaud Ebalard wrote:
> Hi Andrew,
> 
> Andrew Lunn <andrew at lunn.ch> writes:
> 
> >> +struct g762_data {
> >> +	struct i2c_client *client;
> >> +	struct device *hwmon_dev;
> >> +
> >> +	/* update mutex */
> >> +	struct mutex update_lock;
> >> +
> >> +	/* board specific parameters. */
> >> +	u32 clk; /* default 32kHz */
> >> +
> >> +	/* g762 register cache */
> >> +	bool valid;
> >> +	unsigned long last_updated; /* in jiffies */
> >> +
> >> +	u8 set_cnt;  /* RPM cmd in close loop control */
> >> +	u8 act_cnt;  /* formula: cnt = (CLK * 30)/(rpm * P) */
> >> +	u8 fan_sta;  /* bit 0: set when actual fan speed is more than
> >> +		      *        25% outside requested fan speed
> >> +		      * bit 1: set when no transition occurs on fan
> >> +		      *        pin for 0.7s
> >> +		      */
> >> +	u8 set_out;  /* output voltage/PWM duty in open loop control */
> >> +	u8 fan_cmd1; /*   0: FG_PLS_ID0 FG pulses count per revolution
> >> +		      *      0: 2 counts per revolution
> >> +		      *      1: 4 counts per revolution
> >> +		      *   1: PWM_POLARITY 1: negative_duty
> >> +		      *                   0: positive_duty
> >> +		      * 2,3: [FG_CLOCK_ID0, FG_CLK_ID1]
> >> +		      *         00: Divide fan clock by 1
> >> +		      *         01: Divide fan clock by 2
> >> +		      *         10: Divide fan clock by 4
> >> +		      *         11: Divide fan clock by 8
> >> +		      *   4: FAN_MODE 1:close-loop, 0:open-loop
> >> +		      *   5: OUT_MODE 1:PWM, 0:DAC
> >> +		      *   6: DET_FAN_OOC enable "fan ooc" status
> >> +		      *   7: DET_FAN_FAIL enable "fan fail" status
> >> +		      */
> >> +	u8 fan_cmd2; /* 0,1: FAN_STARTV 0,1,2,3 -> 0,32,64,96 dac_code
> >> +		      * 2,3: FG_GEAR_MODE
> >> +		      *         00: div = 1
> >> +		      *         01: div = 2
> >> +		      *         10: div = 4
> >> +		      *   4: Mask ALERT# (g763 only)
> >> +		      */
> >
> > You could consider using regmap for holding this cache.
> >
> > http://elceurope2012.sched.org/event/100619b669ce5767341624253aa03659?iframe=no&w=900&sidebar=yes&bg=no#.UXdspHLQ5jM
> >
> > http://elinux.org/ELCE_Europe_2012_Presentations
> 
> Interesting. As I am not yet familiar w/ regmap I would prefer having
> the driver accepted during merge window with current data structure and
> then convert it to regmap. But I will take a look (e.g. will study
> fca1dd03 for instance). Thanks for the pointers. 
> 
I have not had time for a detailed review, but adding regmap support will not be
a requirement.

Note that it is too late for 3.10, so the driver will have to wait for 3.11.

> >> +/*
> >> + * Helpers to import hardware characteristics from .dts file and overload
> >> + * default config values.
> >> + */
> >> +
> >> +#ifdef CONFIG_OF
> >
> > Can the driver be used without device tree? Would it be simpler to
> >  just add depends OF in the Kconfig entry?
> 
> It can be used if the default params (or those configured by u-boot I
> guess) fit your needs. I think it would be fairly easy to extend the
> driver later to expose g762_config struct to allow parameters to be set
> w/o using OF. If someone wants to do that, I think it is better to not
> depend on OF in Kconfig at the moment but I have not strong argument
> other that that one. I'll let you decide.
> 
Agreed. As long as there are major platforms not supporting device tree,
and as long as device tree overlays are not supported, it must not be made
mandatory. Especially for I2C and SPI devices I reserve the right to be able
test the hardware on an X86 system and not require a reboot to do so.

Guenter


From mpa at pengutronix.de  Wed Apr 24 09:39:09 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Wed, 24 Apr 2013 15:39:09 +0200
Subject: [PATCH v5 0/2] video: imxfb DT support
Message-ID: <1366810751-26860-1-git-send-email-mpa@pengutronix.de>

Hi,

This series adds DT support for imxfb. Changes are listed in the notes section
of each patch.

Regards,

Markus



Christian Hemp (1):
      imxfb: Set alpha value of the framebuffer

Markus Pargmann (1):
      video: imxfb: Add DT support

 Documentation/devicetree/bindings/video/fsl,imx-fb.txt |  51 +++++++++++++
 drivers/video/Kconfig                                  |   2 +
 drivers/video/imxfb.c                                  | 229 +++++++++++++++++++++++++++++++++++++++++++++++---------
 include/linux/platform_data/video-imxfb.h              |   3 +
 4 files changed, 250 insertions(+), 35 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/video/fsl,imx-fb.txt



From mpa at pengutronix.de  Wed Apr 24 09:39:11 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Wed, 24 Apr 2013 15:39:11 +0200
Subject: [PATCH v5 2/2] video: imxfb: Add DT support
In-Reply-To: <1366810751-26860-1-git-send-email-mpa@pengutronix.de>
References: <1366810751-26860-1-git-send-email-mpa@pengutronix.de>
Message-ID: <1366810751-26860-3-git-send-email-mpa@pengutronix.de>

Add devicetree support for imx framebuffer driver. It uses the generic
display bindings and helper functions.

Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
Cc: Fabio Estevam <festevam at gmail.com>
Cc: Mark Rutland <mark.rutland at arm.com>
---

Notes:
    Changed in v5:
    - Fix compatible property of the example
    - Rename property fsl,bpp to bits-per-pixel
    - Add selects for FB_MODE_HELPERS and VIDEOMODE_HELPERS to Kconfig FB_IMX
    
    Changes in v4:
    - Remove eukrea specific dmacr property.
    - Add optional dmacr property. If not present, the dmacr reset value is not
      changed.
    
    Changes in v3:
    - Fix returncodes of of_read_mode function and print error messages
    - Introduce a lower bound check for bits per pixel
    - Calculate correct bytes per pixel value before using it for the calculation of
    	memory size
    - Change DT property names
    
    Changes in v2:
    - Removed pwmr register property
    - Cleanup of devicetree binding documentation
    - Use default values for pwmr and lscr1

 .../devicetree/bindings/video/fsl,imx-fb.txt       |  51 ++++++
 drivers/video/Kconfig                              |   2 +
 drivers/video/imxfb.c                              | 194 +++++++++++++++++----
 3 files changed, 212 insertions(+), 35 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/video/fsl,imx-fb.txt

diff --git a/Documentation/devicetree/bindings/video/fsl,imx-fb.txt b/Documentation/devicetree/bindings/video/fsl,imx-fb.txt
new file mode 100644
index 0000000..46da08d
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/fsl,imx-fb.txt
@@ -0,0 +1,51 @@
+Freescale imx21 Framebuffer
+
+This framebuffer driver supports devices imx1, imx21, imx25, and imx27.
+
+Required properties:
+- compatible : "fsl,<chip>-fb", chip should be imx1 or imx21
+- reg : Should contain 1 register ranges(address and length)
+- interrupts : One interrupt of the fb dev
+
+Required nodes:
+- display: Phandle to a display node as described in
+	Documentation/devicetree/bindings/video/display-timing.txt
+	Additional, the display node has to define properties:
+	- bits-per-pixel: Bits per pixel
+	- fsl,pcr: LCDC PCR value
+
+Optional properties:
+- fsl,dmacr: DMA Control Register value. This is optional. By default, the
+	register is not modified as recommended by the datasheet.
+- fsl,lscr1: LCDC Sharp Configuration Register value.
+
+Example:
+
+	imxfb: fb at 10021000 {
+		compatible = "fsl,imx21-fb";
+		interrupts = <61>;
+		reg = <0x10021000 0x1000>;
+		display = <&display0>;
+	};
+
+	...
+
+	display0: display0 {
+		model = "Primeview-PD050VL1";
+		native-mode = <&timing_disp0>;
+		bits-per-pixel = <16>;
+		fsl,pcr = <0xf0c88080>;	/* non-standard but required */
+		display-timings {
+			timing_disp0: 640x480 {
+				hactive = <640>;
+				vactive = <480>;
+				hback-porch = <112>;
+				hfront-porch = <36>;
+				hsync-len = <32>;
+				vback-porch = <33>;
+				vfront-porch = <33>;
+				vsync-len = <2>;
+				clock-frequency = <25000000>;
+			};
+		};
+	};
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 4c1546f..44b1af4 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -391,6 +391,8 @@ config FB_IMX
 	select FB_CFB_FILLRECT
 	select FB_CFB_COPYAREA
 	select FB_CFB_IMAGEBLIT
+	select FB_MODE_HELPERS
+	select VIDEOMODE_HELPERS
 
 config FB_CYBER2000
 	tristate "CyberPro 2000/2010/5000 support"
diff --git a/drivers/video/imxfb.c b/drivers/video/imxfb.c
index ef2b587..7bb3728 100644
--- a/drivers/video/imxfb.c
+++ b/drivers/video/imxfb.c
@@ -32,6 +32,12 @@
 #include <linux/io.h>
 #include <linux/math64.h>
 #include <linux/uaccess.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+
+#include <video/of_display_timing.h>
+#include <video/of_videomode.h>
+#include <video/videomode.h>
 
 #include <linux/platform_data/video-imxfb.h>
 
@@ -117,10 +123,11 @@
 #define LGWCR_GWAV(alpha)	(((alpha) & 0xff) << 24)
 #define LGWCR_GWE	(1 << 22)
 
+#define IMXFB_LSCR1_DEFAULT 0x00120300
+
 /* Used fb-mode. Can be set on kernel command line, therefore file-static. */
 static const char *fb_mode;
 
-
 /*
  * These are the bitfields for each
  * display depth that we support.
@@ -192,6 +199,19 @@ static struct platform_device_id imxfb_devtype[] = {
 };
 MODULE_DEVICE_TABLE(platform, imxfb_devtype);
 
+static struct of_device_id imxfb_of_dev_id[] = {
+	{
+		.compatible = "fsl,imx1-fb",
+		.data = &imxfb_devtype[IMX1_FB],
+	}, {
+		.compatible = "fsl,imx21-fb",
+		.data = &imxfb_devtype[IMX21_FB],
+	}, {
+		/* sentinel */
+	}
+};
+MODULE_DEVICE_TABLE(of, imxfb_of_dev_id);
+
 static inline int is_imx1_fb(struct imxfb_info *fbi)
 {
 	return fbi->devtype == IMX1_FB;
@@ -324,6 +344,9 @@ static const struct imx_fb_videomode *imxfb_find_mode(struct imxfb_info *fbi)
 	struct imx_fb_videomode *m;
 	int i;
 
+	if (!fb_mode)
+		return &fbi->mode[0];
+
 	for (i = 0, m = &fbi->mode[0]; i < fbi->num_modes; i++, m++) {
 		if (!strcmp(m->mode.name, fb_mode))
 			return m;
@@ -479,6 +502,9 @@ static int imxfb_bl_update_status(struct backlight_device *bl)
 	struct imxfb_info *fbi = bl_get_data(bl);
 	int brightness = bl->props.brightness;
 
+	if (!fbi->pwmr)
+		return 0;
+
 	if (bl->props.power != FB_BLANK_UNBLANK)
 		brightness = 0;
 	if (bl->props.fb_blank != FB_BLANK_UNBLANK)
@@ -719,10 +745,14 @@ static int imxfb_activate_var(struct fb_var_screeninfo *var, struct fb_info *inf
 
 	writel(fbi->pcr, fbi->regs + LCDC_PCR);
 #ifndef PWMR_BACKLIGHT_AVAILABLE
-	writel(fbi->pwmr, fbi->regs + LCDC_PWMR);
+	if (fbi->pwmr)
+		writel(fbi->pwmr, fbi->regs + LCDC_PWMR);
 #endif
 	writel(fbi->lscr1, fbi->regs + LCDC_LSCR1);
-	writel(fbi->dmacr, fbi->regs + LCDC_DMACR);
+
+	/* dmacr = 0 is no valid value, as we need DMA control marks. */
+	if (fbi->dmacr)
+		writel(fbi->dmacr, fbi->regs + LCDC_DMACR);
 
 	return 0;
 }
@@ -758,13 +788,12 @@ static int imxfb_resume(struct platform_device *dev)
 #define imxfb_resume	NULL
 #endif
 
-static int __init imxfb_init_fbinfo(struct platform_device *pdev)
+static int imxfb_init_fbinfo(struct platform_device *pdev)
 {
 	struct imx_fb_platform_data *pdata = pdev->dev.platform_data;
 	struct fb_info *info = dev_get_drvdata(&pdev->dev);
 	struct imxfb_info *fbi = info->par;
-	struct imx_fb_videomode *m;
-	int i;
+	struct device_node *np;
 
 	pr_debug("%s\n",__func__);
 
@@ -795,41 +824,95 @@ static int __init imxfb_init_fbinfo(struct platform_device *pdev)
 	info->fbops			= &imxfb_ops;
 	info->flags			= FBINFO_FLAG_DEFAULT |
 					  FBINFO_READS_FAST;
-	info->var.grayscale		= pdata->cmap_greyscale;
-	fbi->cmap_inverse		= pdata->cmap_inverse;
-	fbi->cmap_static		= pdata->cmap_static;
-	fbi->lscr1			= pdata->lscr1;
-	fbi->dmacr			= pdata->dmacr;
-	fbi->pwmr			= pdata->pwmr;
-	fbi->lcd_power			= pdata->lcd_power;
-	fbi->backlight_power		= pdata->backlight_power;
-
-	for (i = 0, m = &pdata->mode[0]; i < pdata->num_modes; i++, m++)
-		info->fix.smem_len = max_t(size_t, info->fix.smem_len,
-				m->mode.xres * m->mode.yres * m->bpp / 8);
+	if (pdata) {
+		info->var.grayscale		= pdata->cmap_greyscale;
+		fbi->cmap_inverse		= pdata->cmap_inverse;
+		fbi->cmap_static		= pdata->cmap_static;
+		fbi->lscr1			= pdata->lscr1;
+		fbi->dmacr			= pdata->dmacr;
+		fbi->pwmr			= pdata->pwmr;
+		fbi->lcd_power			= pdata->lcd_power;
+		fbi->backlight_power		= pdata->backlight_power;
+	} else {
+		np = pdev->dev.of_node;
+		info->var.grayscale = of_property_read_bool(np,
+						"cmap-greyscale");
+		fbi->cmap_inverse = of_property_read_bool(np, "cmap-inverse");
+		fbi->cmap_static = of_property_read_bool(np, "cmap-static");
+
+		fbi->lscr1 = IMXFB_LSCR1_DEFAULT;
+		of_property_read_u32(np, "fsl,lscr1", &fbi->lscr1);
+
+		of_property_read_u32(np, "fsl,dmacr", &fbi->dmacr);
+
+		/* These two function pointers could be used by some specific
+		 * platforms. */
+		fbi->lcd_power = NULL;
+		fbi->backlight_power = NULL;
+	}
+
+	return 0;
+}
+
+static int imxfb_of_read_mode(struct device *dev, struct device_node *np,
+		struct imx_fb_videomode *imxfb_mode)
+{
+	int ret;
+	struct fb_videomode *of_mode = &imxfb_mode->mode;
+	u32 bpp;
+	u32 pcr;
+
+	ret = of_property_read_string(np, "model", &of_mode->name);
+	if (ret)
+		of_mode->name = NULL;
+
+	ret = of_get_fb_videomode(np, of_mode, OF_USE_NATIVE_MODE);
+	if (ret) {
+		dev_err(dev, "Failed to get videomode from DT\n");
+		return ret;
+	}
+
+	ret = of_property_read_u32(np, "bits-per-pixel", &bpp);
+	ret |= of_property_read_u32(np, "fsl,pcr", &pcr);
+
+	if (ret) {
+		dev_err(dev, "Failed to read bpp and pcr from DT\n");
+		return -EINVAL;
+	}
+
+	if (bpp < 1 || bpp > 255) {
+		dev_err(dev, "Bits per pixel have to be between 1 and 255\n");
+		return -EINVAL;
+	}
+
+	imxfb_mode->bpp = bpp;
+	imxfb_mode->pcr = pcr;
 
 	return 0;
 }
 
-static int __init imxfb_probe(struct platform_device *pdev)
+static int imxfb_probe(struct platform_device *pdev)
 {
 	struct imxfb_info *fbi;
 	struct fb_info *info;
 	struct imx_fb_platform_data *pdata;
 	struct resource *res;
+	struct imx_fb_videomode *m;
+	const struct of_device_id *of_id;
 	int ret, i;
+	int bytes_per_pixel;
 
 	dev_info(&pdev->dev, "i.MX Framebuffer driver\n");
 
+	of_id = of_match_device(imxfb_of_dev_id, &pdev->dev);
+	if (of_id)
+		pdev->id_entry = of_id->data;
+
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 	if (!res)
 		return -ENODEV;
 
 	pdata = pdev->dev.platform_data;
-	if (!pdata) {
-		dev_err(&pdev->dev,"No platform_data available\n");
-		return -ENOMEM;
-	}
 
 	info = framebuffer_alloc(sizeof(struct imxfb_info), &pdev->dev);
 	if (!info)
@@ -837,15 +920,55 @@ static int __init imxfb_probe(struct platform_device *pdev)
 
 	fbi = info->par;
 
-	if (!fb_mode)
-		fb_mode = pdata->mode[0].mode.name;
-
 	platform_set_drvdata(pdev, info);
 
 	ret = imxfb_init_fbinfo(pdev);
 	if (ret < 0)
 		goto failed_init;
 
+	if (pdata) {
+		if (!fb_mode)
+			fb_mode = pdata->mode[0].mode.name;
+
+		fbi->mode = pdata->mode;
+		fbi->num_modes = pdata->num_modes;
+	} else {
+		struct device_node *display_np;
+		fb_mode = NULL;
+
+		display_np = of_parse_phandle(pdev->dev.of_node, "display", 0);
+		if (!display_np) {
+			dev_err(&pdev->dev, "No display defined in devicetree\n");
+			ret = -EINVAL;
+			goto failed_of_parse;
+		}
+
+		/*
+		 * imxfb does not support more modes, we choose only the native
+		 * mode.
+		 */
+		fbi->num_modes = 1;
+
+		fbi->mode = devm_kzalloc(&pdev->dev,
+				sizeof(struct imx_fb_videomode), GFP_KERNEL);
+		if (!fbi->mode) {
+			ret = -ENOMEM;
+			goto failed_of_parse;
+		}
+
+		ret = imxfb_of_read_mode(&pdev->dev, display_np, fbi->mode);
+		if (ret)
+			goto failed_of_parse;
+	}
+
+	/* Calculate maximum bytes used per pixel. In most cases this should
+	 * be the same as m->bpp/8 */
+	m = &fbi->mode[0];
+	bytes_per_pixel = (m->bpp + 7) / 8;
+	for (i = 0; i < fbi->num_modes; i++, m++)
+		info->fix.smem_len = max_t(size_t, info->fix.smem_len,
+				m->mode.xres * m->mode.yres * bytes_per_pixel);
+
 	res = request_mem_region(res->start, resource_size(res),
 				DRIVER_NAME);
 	if (!res) {
@@ -878,7 +1001,8 @@ static int __init imxfb_probe(struct platform_device *pdev)
 		goto failed_ioremap;
 	}
 
-	if (!pdata->fixed_screen_cpu) {
+	/* Seems not being used by anyone, so no support for oftree */
+	if (!pdata || !pdata->fixed_screen_cpu) {
 		fbi->map_size = PAGE_ALIGN(info->fix.smem_len);
 		fbi->map_cpu = dma_alloc_writecombine(&pdev->dev,
 				fbi->map_size, &fbi->map_dma, GFP_KERNEL);
@@ -903,18 +1027,16 @@ static int __init imxfb_probe(struct platform_device *pdev)
 		info->fix.smem_start = fbi->screen_dma;
 	}
 
-	if (pdata->init) {
+	if (pdata && pdata->init) {
 		ret = pdata->init(fbi->pdev);
 		if (ret)
 			goto failed_platform_init;
 	}
 
-	fbi->mode = pdata->mode;
-	fbi->num_modes = pdata->num_modes;
 
 	INIT_LIST_HEAD(&info->modelist);
-	for (i = 0; i < pdata->num_modes; i++)
-		fb_add_videomode(&pdata->mode[i].mode, &info->modelist);
+	for (i = 0; i < fbi->num_modes; i++)
+		fb_add_videomode(&fbi->mode[i].mode, &info->modelist);
 
 	/*
 	 * This makes sure that our colour bitfield
@@ -944,10 +1066,10 @@ static int __init imxfb_probe(struct platform_device *pdev)
 failed_register:
 	fb_dealloc_cmap(&info->cmap);
 failed_cmap:
-	if (pdata->exit)
+	if (pdata && pdata->exit)
 		pdata->exit(fbi->pdev);
 failed_platform_init:
-	if (!pdata->fixed_screen_cpu)
+	if (pdata && !pdata->fixed_screen_cpu)
 		dma_free_writecombine(&pdev->dev,fbi->map_size,fbi->map_cpu,
 			fbi->map_dma);
 failed_map:
@@ -956,6 +1078,7 @@ failed_ioremap:
 failed_getclock:
 	release_mem_region(res->start, resource_size(res));
 failed_req:
+failed_of_parse:
 	kfree(info->pseudo_palette);
 failed_init:
 	platform_set_drvdata(pdev, NULL);
@@ -980,7 +1103,7 @@ static int imxfb_remove(struct platform_device *pdev)
 	unregister_framebuffer(info);
 
 	pdata = pdev->dev.platform_data;
-	if (pdata->exit)
+	if (pdata && pdata->exit)
 		pdata->exit(fbi->pdev);
 
 	fb_dealloc_cmap(&info->cmap);
@@ -1009,6 +1132,7 @@ static struct platform_driver imxfb_driver = {
 	.shutdown	= imxfb_shutdown,
 	.driver		= {
 		.name	= DRIVER_NAME,
+		.of_match_table = imxfb_of_dev_id,
 	},
 	.id_table	= imxfb_devtype,
 };
-- 
1.8.1.5



From mpa at pengutronix.de  Wed Apr 24 09:39:10 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Wed, 24 Apr 2013 15:39:10 +0200
Subject: [PATCH v5 1/2] imxfb: Set alpha value of the framebuffer
In-Reply-To: <1366810751-26860-1-git-send-email-mpa@pengutronix.de>
References: <1366810751-26860-1-git-send-email-mpa@pengutronix.de>
Message-ID: <1366810751-26860-2-git-send-email-mpa@pengutronix.de>

From: Christian Hemp <c.hemp at phytec.de>

Based on Sascha Hauer's patch i.MX27 clock: Do not disable lcd clocks during
startup.
This patch gives a interface to chance the alphavalue of the framebuffer.

Signed-off-by: Christian Hemp <c.hemp at phytec.de>

rebased to 3.7
Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
---
 drivers/video/imxfb.c                     | 35 +++++++++++++++++++++++++++++++
 include/linux/platform_data/video-imxfb.h |  3 +++
 2 files changed, 38 insertions(+)

diff --git a/drivers/video/imxfb.c b/drivers/video/imxfb.c
index 0abf2bf..ef2b587 100644
--- a/drivers/video/imxfb.c
+++ b/drivers/video/imxfb.c
@@ -31,6 +31,7 @@
 #include <linux/dma-mapping.h>
 #include <linux/io.h>
 #include <linux/math64.h>
+#include <linux/uaccess.h>
 
 #include <linux/platform_data/video-imxfb.h>
 
@@ -112,6 +113,10 @@
 #define LCDISR_EOF	(1<<1)
 #define LCDISR_BOF	(1<<0)
 
+#define LCDC_LGWCR	0x64
+#define LGWCR_GWAV(alpha)	(((alpha) & 0xff) << 24)
+#define LGWCR_GWE	(1 << 22)
+
 /* Used fb-mode. Can be set on kernel command line, therefore file-static. */
 static const char *fb_mode;
 
@@ -610,6 +615,35 @@ static int imxfb_blank(int blank, struct fb_info *info)
 	return 0;
 }
 
+static int imxfb_ioctl(struct fb_info *info, unsigned int cmd,
+			unsigned long arg)
+{
+	struct imxfb_info *fbi = info->par;
+	int alpha, ret = 0;
+	unsigned int tmp;
+
+	switch (cmd) {
+	case IMXFB_ALPHA:
+		if (get_user(alpha, (int __user *)arg)) {
+			ret = -EFAULT;
+		} else {
+			tmp = readl(fbi->regs + LCDC_LGWCR);
+			tmp &= ~LGWCR_GWAV(0xff);
+			tmp |= LGWCR_GWAV(alpha);
+			if (!alpha)
+				tmp &= ~LGWCR_GWE;
+			else
+				tmp |= LGWCR_GWE;
+			writel(tmp , fbi->regs + LCDC_LGWCR);
+		}
+		break;
+	default:
+		ret = -EINVAL;
+	}
+
+	return ret;
+}
+
 static struct fb_ops imxfb_ops = {
 	.owner		= THIS_MODULE,
 	.fb_check_var	= imxfb_check_var,
@@ -619,6 +653,7 @@ static struct fb_ops imxfb_ops = {
 	.fb_copyarea	= cfb_copyarea,
 	.fb_imageblit	= cfb_imageblit,
 	.fb_blank	= imxfb_blank,
+	.fb_ioctl	= imxfb_ioctl,
 };
 
 /*
diff --git a/include/linux/platform_data/video-imxfb.h b/include/linux/platform_data/video-imxfb.h
index 9de8f06..ce3875f 100644
--- a/include/linux/platform_data/video-imxfb.h
+++ b/include/linux/platform_data/video-imxfb.h
@@ -51,6 +51,9 @@
 #define DMACR_HM(x)	(((x) & 0xf) << 16)
 #define DMACR_TM(x)	((x) & 0xf)
 
+#define IMXFB_IOW(num, dtype)	_IOW('I', num, dtype)
+#define IMXFB_ALPHA		IMXFB_IOW(31, int)
+
 struct imx_fb_videomode {
 	struct fb_videomode mode;
 	u32 pcr;
-- 
1.8.1.5



From marc.zyngier at arm.com  Wed Apr 24 09:42:04 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 24 Apr 2013 14:42:04 +0100
Subject: [PATCH v3 26/32] arm64: KVM: 32bit handling of coprocessor traps
In-Reply-To: <20130423230159.GL20569@gmail.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
 <1365437854-30214-27-git-send-email-marc.zyngier@arm.com>
 <20130423230159.GL20569@gmail.com>
Message-ID: <5177E12C.8020909@arm.com>

On 24/04/13 00:01, Christoffer Dall wrote:
> On Mon, Apr 08, 2013 at 05:17:28PM +0100, Marc Zyngier wrote:
>> Provide the necessary infrastructure to trap coprocessor accesses that
>> occur when running 32bit guests.
>>
>> Also wire SMC and HVC trapped in 32bit mode while were at it.
>>
>> Reviewed-by: Christopher Covington <cov at codeaurora.org>
>> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
>> ---
>>  arch/arm64/include/asm/kvm_coproc.h |   5 +
>>  arch/arm64/kvm/handle_exit.c        |   7 ++
>>  arch/arm64/kvm/sys_regs.c           | 178 ++++++++++++++++++++++++++++++++++--
>>  3 files changed, 183 insertions(+), 7 deletions(-)
>>
>> diff --git a/arch/arm64/include/asm/kvm_coproc.h b/arch/arm64/include/asm/kvm_coproc.h
>> index 9b4477a..9a59301 100644
>> --- a/arch/arm64/include/asm/kvm_coproc.h
>> +++ b/arch/arm64/include/asm/kvm_coproc.h
>> @@ -32,11 +32,16 @@ struct kvm_sys_reg_table {
>>
>>  struct kvm_sys_reg_target_table {
>>       struct kvm_sys_reg_table table64;
>> +     struct kvm_sys_reg_table table32;
>>  };
>>
>>  void kvm_register_target_sys_reg_table(unsigned int target,
>>                                      struct kvm_sys_reg_target_table *table);
>>
>> +int kvm_handle_cp14_load_store(struct kvm_vcpu *vcpu, struct kvm_run *run);
>> +int kvm_handle_cp14_access(struct kvm_vcpu *vcpu, struct kvm_run *run);
>> +int kvm_handle_cp15_32(struct kvm_vcpu *vcpu, struct kvm_run *run);
>> +int kvm_handle_cp15_64(struct kvm_vcpu *vcpu, struct kvm_run *run);
>>  int kvm_handle_sys_reg(struct kvm_vcpu *vcpu, struct kvm_run *run);
>>
>>  #define kvm_coproc_table_init kvm_sys_reg_table_init
>> diff --git a/arch/arm64/kvm/handle_exit.c b/arch/arm64/kvm/handle_exit.c
>> index 4766b7f..9beaca03 100644
>> --- a/arch/arm64/kvm/handle_exit.c
>> +++ b/arch/arm64/kvm/handle_exit.c
>> @@ -62,6 +62,13 @@ static int kvm_handle_wfi(struct kvm_vcpu *vcpu, struct kvm_run *run)
>>
>>  static exit_handle_fn arm_exit_handlers[] = {
>>       [ESR_EL2_EC_WFI]        = kvm_handle_wfi,
>> +     [ESR_EL2_EC_CP15_32]    = kvm_handle_cp15_32,
>> +     [ESR_EL2_EC_CP15_64]    = kvm_handle_cp15_64,
>> +     [ESR_EL2_EC_CP14_MR]    = kvm_handle_cp14_access,
>> +     [ESR_EL2_EC_CP14_LS]    = kvm_handle_cp14_load_store,
>> +     [ESR_EL2_EC_CP14_64]    = kvm_handle_cp14_access,
>> +     [ESR_EL2_EC_HVC32]      = handle_hvc,
>> +     [ESR_EL2_EC_SMC32]      = handle_smc,
>>       [ESR_EL2_EC_HVC64]      = handle_hvc,
>>       [ESR_EL2_EC_SMC64]      = handle_smc,
>>       [ESR_EL2_EC_SYS64]      = kvm_handle_sys_reg,
>> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
>> index 9df3b32..0303218 100644
>> --- a/arch/arm64/kvm/sys_regs.c
>> +++ b/arch/arm64/kvm/sys_regs.c
>> @@ -38,6 +38,10 @@
>>   * types are different. My gut feeling is that it should be pretty
>>   * easy to merge, but that would be an ABI breakage -- again. VFP
>>   * would also need to be abstracted.
>> + *
>> + * For AArch32, we only take care of what is being trapped. Anything
>> + * that has to do with init and userspace access has to go via the
>> + * 64bit interface.
>>   */
>>
>>  /* 3 bits per cache level, as per CLIDR, but non-existent caches always 0 */
>> @@ -163,6 +167,16 @@ static const struct sys_reg_desc sys_reg_descs[] = {
>>       { Op0(0b01), Op1(0b000), CRn(0b0111), CRm(0b1110), Op2(0b010),
>>         access_dcsw },
>>
>> +     /* TEECR32_EL1 */
>> +     { Op0(0b10), Op1(0b010), CRn(0b0000), CRm(0b0000), Op2(0b000),
>> +       NULL, reset_val, TEECR32_EL1, 0 },
>> +     /* TEEHBR32_EL1 */
>> +     { Op0(0b10), Op1(0b010), CRn(0b0001), CRm(0b0000), Op2(0b000),
>> +       NULL, reset_val, TEEHBR32_EL1, 0 },
>> +     /* DBGVCR32_EL2 */
>> +     { Op0(0b10), Op1(0b100), CRn(0b0000), CRm(0b0111), Op2(0b000),
>> +       NULL, reset_val, DBGVCR32_EL2, 0 },
>> +
>>       /* MPIDR_EL1 */
>>       { Op0(0b11), Op1(0b000), CRn(0b0000), CRm(0b0000), Op2(0b101),
>>         NULL, reset_mpidr, MPIDR_EL1 },
>> @@ -273,6 +287,39 @@ static const struct sys_reg_desc sys_reg_descs[] = {
>>       /* TPIDRRO_EL0 */
>>       { Op0(0b11), Op1(0b011), CRn(0b1101), CRm(0b0000), Op2(0b011),
>>         NULL, reset_unknown, TPIDRRO_EL0 },
>> +
>> +     /* DACR32_EL2 */
>> +     { Op0(0b11), Op1(0b100), CRn(0b0011), CRm(0b0000), Op2(0b000),
>> +       NULL, reset_unknown, DACR32_EL2 },
>> +     /* IFSR32_EL2 */
>> +     { Op0(0b11), Op1(0b100), CRn(0b0101), CRm(0b0000), Op2(0b001),
>> +       NULL, reset_unknown, IFSR32_EL2 },
>> +     /* FPEXC32_EL2 */
>> +     { Op0(0b11), Op1(0b100), CRn(0b0101), CRm(0b0011), Op2(0b000),
>> +       NULL, reset_val, FPEXC32_EL2, 0x70 },
>> +};
>> +
>> +/* Trapped cp15 registers */
>> +static const struct sys_reg_desc cp15_regs[] = {
>> +     /*
>> +      * DC{C,I,CI}SW operations:
>> +      */
>> +     { Op1( 0), CRn( 7), CRm( 6), Op2( 2), access_dcsw },
>> +     { Op1( 0), CRn( 7), CRm(10), Op2( 2), access_dcsw },
>> +     { Op1( 0), CRn( 7), CRm(14), Op2( 2), access_dcsw },
>> +     { Op1( 0), CRn( 9), CRm(12), Op2( 0), pm_fake },
>> +     { Op1( 0), CRn( 9), CRm(12), Op2( 1), pm_fake },
>> +     { Op1( 0), CRn( 9), CRm(12), Op2( 2), pm_fake },
>> +     { Op1( 0), CRn( 9), CRm(12), Op2( 3), pm_fake },
>> +     { Op1( 0), CRn( 9), CRm(12), Op2( 5), pm_fake },
>> +     { Op1( 0), CRn( 9), CRm(12), Op2( 6), pm_fake },
>> +     { Op1( 0), CRn( 9), CRm(12), Op2( 7), pm_fake },
>> +     { Op1( 0), CRn( 9), CRm(13), Op2( 0), pm_fake },
>> +     { Op1( 0), CRn( 9), CRm(13), Op2( 1), pm_fake },
>> +     { Op1( 0), CRn( 9), CRm(13), Op2( 2), pm_fake },
>> +     { Op1( 0), CRn( 9), CRm(14), Op2( 0), pm_fake },
>> +     { Op1( 0), CRn( 9), CRm(14), Op2( 1), pm_fake },
>> +     { Op1( 0), CRn( 9), CRm(14), Op2( 2), pm_fake },
>>  };
>>
>>  /* Target specific emulation tables */
>> @@ -285,13 +332,20 @@ void kvm_register_target_sys_reg_table(unsigned int target,
>>  }
>>
>>  /* Get specific register table for this target. */
>> -static const struct sys_reg_desc *get_target_table(unsigned target, size_t *num)
>> +static const struct sys_reg_desc *get_target_table(unsigned target,
>> +                                                bool mode_is_64,
>> +                                                size_t *num)
>>  {
>>       struct kvm_sys_reg_target_table *table;
>>
>>       table = target_tables[target];
>> -     *num = table->table64.num;
>> -     return table->table64.table;
>> +     if (mode_is_64) {
>> +             *num = table->table64.num;
>> +             return table->table64.table;
>> +     } else {
>> +             *num = table->table32.num;
>> +             return table->table32.table;
>> +     }
>>  }
>>
>>  static const struct sys_reg_desc *find_reg(const struct sys_reg_params *params,
>> @@ -319,13 +373,123 @@ static const struct sys_reg_desc *find_reg(const struct sys_reg_params *params,
>>       return NULL;
>>  }
>>
>> +int kvm_handle_cp14_load_store(struct kvm_vcpu *vcpu, struct kvm_run *run)
>> +{
>> +     kvm_inject_undefined(vcpu);
>> +     return 1;
>> +}
>> +
>> +int kvm_handle_cp14_access(struct kvm_vcpu *vcpu, struct kvm_run *run)
>> +{
>> +     kvm_inject_undefined(vcpu);
>> +     return 1;
>> +}
>> +
>> +static int emulate_cp15(struct kvm_vcpu *vcpu,
>> +                     const struct sys_reg_params *params)
>> +{
>> +     size_t num;
>> +     const struct sys_reg_desc *table, *r;
>> +
>> +     table = get_target_table(vcpu->arch.target, false, &num);
>> +
>> +     /* Search target-specific then generic table. */
>> +     r = find_reg(params, table, num);
>> +     if (!r)
>> +             r = find_reg(params, cp15_regs, ARRAY_SIZE(cp15_regs));
>> +
>> +     if (likely(r)) {
>> +             /* If we don't have an accessor, we should never get here! */
>> +             BUG_ON(!r->access);
> 
> again not quite sure if this warrants a crash of the entire host.
> 
>> +
>> +             if (likely(r->access(vcpu, params, r))) {
>> +                     /* Skip instruction, since it was emulated */
>> +                     kvm_skip_instr(vcpu, kvm_vcpu_trap_il_is32bit(vcpu));
>> +                     return 1;
>> +             }
>> +             /* If access function fails, it should complain. */
>> +     } else {
>> +             kvm_err("Unsupported guest CP15 access at: %08lx\n",
>> +                     *vcpu_pc(vcpu));
>> +             print_sys_reg_instr(params);
>> +     }
>> +     kvm_inject_undefined(vcpu);
>> +     return 1;
>> +}
>> +
>> +/**
>> + * kvm_handle_cp15_64 -- handles a mrrc/mcrr trap on a guest CP15 access
>> + * @vcpu: The VCPU pointer
>> + * @run:  The kvm_run struct
>> + */
>> +int kvm_handle_cp15_64(struct kvm_vcpu *vcpu, struct kvm_run *run)
>> +{
>> +     struct sys_reg_params params;
>> +     u32 hsr = kvm_vcpu_get_hsr(vcpu);
>> +     int Rt2 = (hsr >> 10) & 0xf;
>> +     int ret;
>> +
>> +     params.CRm = (hsr >> 1) & 0xf;
>> +     params.Rt = (hsr >> 5) & 0xf;
>> +     params.is_write = ((hsr & 1) == 0);
>> +
>> +     params.Op0 = 0;
>> +     params.Op1 = (hsr >> 16) & 0xf;
>> +     params.Op2 = 0;
>> +     params.CRn = 0;
>> +
>> +     /*
>> +      * Massive hack here. Store Rt2 in the top 32bits so we only
>> +      * have one register to deal with. As we use the same trap
>> +      * backends between AArch32 and AArch64, we get away with it.
>> +      */
>> +     if (params.is_write) {
>> +             u64 val = *vcpu_reg(vcpu, params.Rt);
>> +             val &= 0xffffffff;
>> +             val |= *vcpu_reg(vcpu, Rt2) << 32;
>> +             *vcpu_reg(vcpu, params.Rt) = val;
>> +     }
>> +
>> +     ret = emulate_cp15(vcpu, &params);
>> +
>> +     /* Reverse hack here */
> 
> nit: consider changing the wording to something like 'Similar hack for
> reads here', so readers don't think you are trying to reverse the hack
> you did above.

Sure.

>> +     if (ret && !params.is_write) {
>> +             u64 val = *vcpu_reg(vcpu, params.Rt);
>> +             val >>= 32;
>> +             *vcpu_reg(vcpu, Rt2) = val;
> 
> actually the emulate_cp15 should probably be turned into a void and the
> ret check could go away, same thing on the 32-bit side.

Well, if we don't BUG_ON() in emulate_cp15, then we do want to return
something that meaningfully shown that we failed to handle the trap.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...



From linus.walleij at linaro.org  Wed Apr 24 09:45:37 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Wed, 24 Apr 2013 15:45:37 +0200
Subject: [PATCH 1/8] dmaengine: ste_dma40: Assign memcpy channels in the
 driver
In-Reply-To: <1365532783-27425-1-git-send-email-lee.jones@linaro.org>
References: <1365532783-27425-1-git-send-email-lee.jones@linaro.org>
Message-ID: <CACRpkdYUT+5J-phV=ez-EkmA9EdfxwmDMApTssi+P3=mSE3cew@mail.gmail.com>

On Tue, Apr 9, 2013 at 8:39 PM, Lee Jones <lee.jones at linaro.org> wrote:

> The channels reserved for memcpy are the same for all currently
> supported platforms. With this in mind, we can ease the platform
> data passing requirement by moving these assignments out from
> platform code and place them directly into the driver.
>
> Cc: Vinod Koul <vinod.koul at intel.com>
> Cc: Dan Williams <djbw at fb.com>
> Cc: Per Forlin <per.forlin at stericsson.com>
> Acked-by: Arnd Bergmann <arnd at arndb.de>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>

(...)

> -/* Reserved event lines for memcpy only */
> -static int dma40_memcpy_event[] = {
> -       DB8500_DMA_MEMCPY_TX_0,
> -       DB8500_DMA_MEMCPY_TX_1,
> -       DB8500_DMA_MEMCPY_TX_2,
> -       DB8500_DMA_MEMCPY_TX_3,
> -       DB8500_DMA_MEMCPY_TX_4,
> -       DB8500_DMA_MEMCPY_TX_5,
> -};

(...)

> +/* Reserved event lines for memcpy only. */
> +static int dma40_memcpy_channels[] = { 56, 57, 58, 59, 60 };

So what's so bad with using the #defines?

I would prefer if you took the entire content of
arch/arm/mach-ux500/ste-dma40-db8500.h
and copied into the DMA driver, so you atleast
have a chance of understanding what these numbers
are about.

Yours,
Linus Walleij


From marc.zyngier at arm.com  Wed Apr 24 09:46:44 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 24 Apr 2013 14:46:44 +0100
Subject: [PATCH v3 29/32] arm64: KVM: 32bit guest fault injection
In-Reply-To: <20130423230214.GM20569@gmail.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
 <1365437854-30214-30-git-send-email-marc.zyngier@arm.com>
 <20130423230214.GM20569@gmail.com>
Message-ID: <5177E244.9000404@arm.com>

On 24/04/13 00:02, Christoffer Dall wrote:
> On Mon, Apr 08, 2013 at 05:17:31PM +0100, Marc Zyngier wrote:
>> Add fault injection capability for 32bit guests.
> 
> looks ok, but seems we are duplicating some functionality here, but I
> realize it may not be that easy to share due to different define names
> for things like PSR_X_BIT...  Did you look further into this?

I did, but as you noticed, the namespaces are different. We could
probably define a set of KVM_AARCH32_* symbols, but I'm not sure it
would be any nicer though.

	M.
-- 
Jazz is not dead. It just smells funny...



From marc.zyngier at arm.com  Wed Apr 24 09:49:55 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 24 Apr 2013 14:49:55 +0100
Subject: [PATCH v3 30/32] arm64: KVM: enable initialization of a 32bit vcpu
In-Reply-To: <20130423230229.GN20569@gmail.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
 <1365437854-30214-31-git-send-email-marc.zyngier@arm.com>
 <20130423230229.GN20569@gmail.com>
Message-ID: <5177E303.7050801@arm.com>

On 24/04/13 00:02, Christoffer Dall wrote:
> On Mon, Apr 08, 2013 at 05:17:32PM +0100, Marc Zyngier wrote:
>> Wire the init of a 32bit vcpu by allowing 32bit modes in pstate,
>> and providing sensible defaults out of reset state.
>>
>> This feature is of course conditioned by the presence of 32bit
>> capability on the physical CPU, and is checked by the KVM_CAP_ARM_EL1_32BIT
>> capability.
>>
>> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
>> ---
>>  arch/arm64/include/asm/kvm_host.h |  2 +-
>>  arch/arm64/include/uapi/asm/kvm.h |  1 +
>>  arch/arm64/kvm/guest.c            |  6 ++++++
>>  arch/arm64/kvm/reset.c            | 25 ++++++++++++++++++++++++-
>>  include/uapi/linux/kvm.h          |  1 +
>>  5 files changed, 33 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
>> index d44064d..c3ec107 100644
>> --- a/arch/arm64/include/asm/kvm_host.h
>> +++ b/arch/arm64/include/asm/kvm_host.h
>> @@ -34,7 +34,7 @@
>>  #include <asm/kvm_vgic.h>
>>  #include <asm/kvm_arch_timer.h>
>>  
>> -#define KVM_VCPU_MAX_FEATURES 1
>> +#define KVM_VCPU_MAX_FEATURES 2
>>  
>>  /* We don't currently support large pages. */
>>  #define KVM_HPAGE_GFN_SHIFT(x)	0
>> diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
>> index 5b1110c..5031f42 100644
>> --- a/arch/arm64/include/uapi/asm/kvm.h
>> +++ b/arch/arm64/include/uapi/asm/kvm.h
>> @@ -75,6 +75,7 @@ struct kvm_regs {
>>  #define KVM_VGIC_V2_CPU_SIZE		0x2000
>>  
>>  #define KVM_ARM_VCPU_POWER_OFF		0 /* CPU is started in OFF state */
>> +#define KVM_ARM_VCPU_EL1_32BIT		1 /* CPU running a 32bit VM */
>>  
>>  struct kvm_vcpu_init {
>>  	__u32 target;
>> diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
>> index 47d3729..74ef7d5 100644
>> --- a/arch/arm64/kvm/guest.c
>> +++ b/arch/arm64/kvm/guest.c
>> @@ -93,6 +93,12 @@ static int set_core_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
>>  	if (off == KVM_REG_ARM_CORE_REG(regs.pstate)) {
>>  		unsigned long mode = (*(unsigned long *)valp) & COMPAT_PSR_MODE_MASK;
>>  		switch (mode) {
>> +		case COMPAT_PSR_MODE_USR:
>> +		case COMPAT_PSR_MODE_FIQ:
>> +		case COMPAT_PSR_MODE_IRQ:
>> +		case COMPAT_PSR_MODE_SVC:
>> +		case COMPAT_PSR_MODE_ABT:
>> +		case COMPAT_PSR_MODE_UND:
>>  		case PSR_MODE_EL0t:
>>  		case PSR_MODE_EL1t:
>>  		case PSR_MODE_EL1h:
>> diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
>> index bc33e76..a282d35 100644
>> --- a/arch/arm64/kvm/reset.c
>> +++ b/arch/arm64/kvm/reset.c
>> @@ -35,11 +35,27 @@ static struct kvm_regs default_regs_reset = {
>>  	.regs.pstate = PSR_MODE_EL1h | PSR_A_BIT | PSR_I_BIT | PSR_F_BIT,
>>  };
>>  
>> +static struct kvm_regs default_regs_reset32 = {
>> +	.regs.pstate = (COMPAT_PSR_MODE_SVC | COMPAT_PSR_A_BIT |
>> +			COMPAT_PSR_I_BIT | COMPAT_PSR_F_BIT),
>> +};
>> +
>> +static bool cpu_has_32bit_el1(void)
>> +{
>> +	u64 pfr0;
>> +
>> +	pfr0 = read_cpuid(ID_AA64PFR0_EL1);
>> +	return !!(pfr0 & 0x20);
> 
> again we don't need the double negation

I still hold that it makes things more readable.

>> +}
>> +
>>  int kvm_arch_dev_ioctl_check_extention(long ext)
>>  {
>>  	int r;
>>  
>>  	switch (ext) {
>> +	case KVM_CAP_ARM_EL1_32BIT:
>> +		r = cpu_has_32bit_el1();
>> +		break;
>>  	default:
>>  		r = 0;
>>  	}
>> @@ -62,7 +78,14 @@ int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
>>  
>>  	switch (vcpu->arch.target) {
>>  	default:
>> -		cpu_reset = &default_regs_reset;
>> +		if (test_bit(KVM_ARM_VCPU_EL1_32BIT, vcpu->arch.features)) {
>> +			if (!cpu_has_32bit_el1())
>> +				return -EINVAL;
> 
> I'm not sure EINVAL is appropriate here, the value specified was not
> incorrect, it's that the hardware doesn't support it. ENXIO, ENODEV, and
> add that in Documentation/virtual/kvm/api.txt ?

Not sure. If you ended up here, it means you tried to start a 32bit
guest on a 64bit-only CPU, despite KVM_CAP_ARM_EL1_32BIT telling you
that your CPU is not 32bit capable.

This is clearly an invalid input, isn't it?

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...



From marc.zyngier at arm.com  Wed Apr 24 09:52:35 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 24 Apr 2013 14:52:35 +0100
Subject: [PATCH v3 31/32] arm64: KVM: userspace API documentation
In-Reply-To: <20130423230252.GO20569@gmail.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
 <1365437854-30214-32-git-send-email-marc.zyngier@arm.com>
 <20130423230252.GO20569@gmail.com>
Message-ID: <5177E3A3.4000600@arm.com>

On 24/04/13 00:02, Christoffer Dall wrote:
> On Mon, Apr 08, 2013 at 05:17:33PM +0100, Marc Zyngier wrote:
>> Unsurprisingly, the arm64 userspace API is extremely similar to
>> the 32bit one, the only significant difference being the ONE_REG
>> register mapping.
>>
>> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>

[...]

>> +
>> +arm64 registers are mapped using the lower 32 bits. The upper 16 of
>> +that is the register group type, or coprocessor number:
>> +
>> +arm64 core/FP-SIMD registers have the following id bit patterns:
>> +  0x6002 0000 0010 <index into the kvm_regs struct:16>
>> +
>> +arm64 CCSIDR registers are demultiplexed by CSSELR value:
>> +  0x6002 0000 0011 00 <csselr:8>
>> +
>> +arm64 system registers have the following id bit patterns:
>> +  0x6002 0000 0013 <op0:2> <op1:3> <crn:4> <crm:4> <op2:3>
>> +
> 
> I think these size encodings are 4 bits off, and not accurate for for
> the core registers, which have variable sizes, which should be indicated
> here (unless you decide for a separate category as per my other
> comment).

Indeed you're right, they're completely wrong. I realized that after
your 32bit patch fixing the same thing...

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...



From jason at lakedaemon.net  Wed Apr 24 09:55:45 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Wed, 24 Apr 2013 09:55:45 -0400
Subject: [PATCH] cpuidle: add maintainer entry
In-Reply-To: <1366810463-17495-1-git-send-email-daniel.lezcano@linaro.org>
References: <1366810463-17495-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <20130424135545.GE13884@titan.lakedaemon.net>

On Wed, Apr 24, 2013 at 03:34:23PM +0200, Daniel Lezcano wrote:
> Currently the cpuidle drivers are spread across the different archs.
> 
> The patch submission for cpuidle are following different path: the cpuidle core
> code goes to linux-pm, the ARM drivers goes to arm-soc or the SoC specific
> tree, sh goes through sh arch tree, pseries goes through PowerPC and
> finally intel goes through Len's tree while acpi_idle goes under linux-pm.
> 
> That makes difficult to consolidate the code and to propagate modifications
> from the cpuidle core to the different drivers.
> 
> Hopefully, a movement has initiated to put the cpuidle drivers into the
> drivers/cpuidle directory like cpuidle-calxeda.c and cpuidle-kirkwood.c
> 
> Add an explicit maintainer entry in the MAINTAINER to clarify the situation
> and prevent new cpuidle drivers to goes to an arch directory.
> 
> The upstreaming process is unchanged: Rafael takes the patches to merge them
> into its tree but with the acked-by from the driver's maintainer. So the header
> must contains the name of the maintainer.
> 
> This organization will be the same than cpufreq.
> 
> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
> ---
>  MAINTAINERS                        |    7 +++++++
>  drivers/cpuidle/cpuidle-calxeda.c  |    4 +++-
>  drivers/cpuidle/cpuidle-kirkwood.c |    5 +++--
>  3 files changed, 13 insertions(+), 3 deletions(-)

For the kirkwood bit:

Acked-by: Jason Cooper <jason at lakedaemon.net>

thx,

Jason.


From sergei.shtylyov at cogentembedded.com  Wed Apr 24 10:00:28 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Wed, 24 Apr 2013 18:00:28 +0400
Subject: [PATCH 04/10] usb: musb: ux500: harden checks for platform data
In-Reply-To: <20130424065344.GB17416@gmail.com>
References: <1366729394-11406-1-git-send-email-lee.jones@linaro.org>
 <1366729394-11406-5-git-send-email-lee.jones@linaro.org>
 <5176E927.908@cogentembedded.com> <20130424065344.GB17416@gmail.com>
Message-ID: <5177E57C.3010802@cogentembedded.com>

Hello.

On 24-04-2013 10:53, Lee Jones wrote:

>>>   	struct musb_hdrc_platform_data *plat = dev->platform_data;
>>> -	struct ux500_musb_board_data *data = plat->board_data;
>>> +	struct ux500_musb_board_data *data;

>>> -	param_array = data->dma_rx_param_array;
>>> +	param_array = (data) ? data->dma_rx_param_array : NULL;

>>     Why enclose a simple variable in parens?

> Because 'data' is a pointer, so it contains a memory location,

    Pointer points to memory location, not contains it.

> but if
> 'plat->board_data' is NULL, then 'data' will be NULL (essentially
> memory location 0x00000000).

    So what?

> So if we were to read-in to 'struct ux500_musb_board_data *data', by
> index 'dma_rx_param_array', which I believe is '0' in this case:

> struct ux500_musb_board_data {
>          void    **dma_rx_param_array;
>          void    **dma_tx_param_array;
>          bool (*dma_filter)(struct dma_chan *chan, void *filter_param);
> };

> ... then we're saying take the data from this memory location:

> param_array = *((0x00000000)->(0x0));

> Which will cause a kernel Oops, due to the fact that address 0x0 isn't
> allocated to us, so you get something like:

> "Unable to handle kernel NULL pointer dereference at virtual address 00000000"

    We're not dereferencing 'data', so I completely fail to follow you.

> Hope that helps.

    Not at all.

> Kind regards,
> Lee

WBR, Sergei



From shawn.guo at linaro.org  Wed Apr 24 10:04:33 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Wed, 24 Apr 2013 22:04:33 +0800
Subject: [PATCH 2/2] dma: imx-sdma: move to generic device tree bindings
In-Reply-To: <1366812273-10833-1-git-send-email-shawn.guo@linaro.org>
References: <1366812273-10833-1-git-send-email-shawn.guo@linaro.org>
Message-ID: <1366812273-10833-3-git-send-email-shawn.guo@linaro.org>

Update imx-sdma driver to adopt generic DMA device tree bindings.  It
calls of_dma_controller_register() with imx-sdma specific of_dma_xlate
to get the generic DMA device tree helper support.  The #dma-cells for
imx-sdma must be 3, which includes request ID, peripheral type and
priority.

The definitions of peripheral type and priority get moved into
include/dt-bindings/dma/imx.h, so that the macros can also be used in
dts files.

The existing way of requesting channel, clients directly call
dma_request_channel(), still work there, and will be removed after
all imx-sdma clients get converted to generic DMA device tree helper.

Signed-off-by: Shawn Guo <shawn.guo at linaro.org>
---
 .../devicetree/bindings/dma/fsl-imx-sdma.txt       |   22 +++++++++++
 drivers/dma/imx-sdma.c                             |   40 ++++++++++++++++++++
 include/dt-bindings/dma/imx.h                      |   29 ++++++++++++++
 include/linux/platform_data/dma-imx.h              |   31 +--------------
 4 files changed, 92 insertions(+), 30 deletions(-)
 create mode 100644 include/dt-bindings/dma/imx.h

diff --git a/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt b/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt
index d1e3f44..053e20e 100644
--- a/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt
+++ b/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt
@@ -4,6 +4,11 @@ Required properties:
 - compatible : Should be "fsl,<chip>-sdma"
 - reg : Should contain SDMA registers location and length
 - interrupts : Should contain SDMA interrupt
+- #dma-cells : Must be <3>.
+  The first cell specifies the DMA request/event ID.  The second and
+  third cell specifies the peripheral type and priority of DMA transfer
+  respectively.  Refer to include/dt-bindings/dma/imx.h for available
+  peripheral types and priorities.
 - fsl,sdma-ram-script-name : Should contain the full path of SDMA RAM
   scripts firmware
 
@@ -13,5 +18,22 @@ sdma at 83fb0000 {
 	compatible = "fsl,imx51-sdma", "fsl,imx35-sdma";
 	reg = <0x83fb0000 0x4000>;
 	interrupts = <6>;
+	#dma-cells = <3>;
 	fsl,sdma-ram-script-name = "sdma-imx51.bin";
 };
+
+DMA clients connected to the i.MX SDMA controller must use the format
+described in the dma.txt file.
+
+Examples:
+
+ssi2: ssi at 70014000 {
+	compatible = "fsl,imx51-ssi", "fsl,imx21-ssi";
+	reg = <0x70014000 0x4000>;
+	interrupts = <30>;
+	clocks = <&clks 49>;
+	dmas = <&sdma 24 DMA_PRIO_HIGH IMX_DMATYPE_SSI_SP>,
+	       <&sdma 25 DMA_PRIO_HIGH IMX_DMATYPE_SSI_SP>;
+	dma-names = "rx", "tx";
+	fsl,fifo-depth = <15>;
+};
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index e57a0c6..f1324da 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -36,6 +36,7 @@
 #include <linux/dmaengine.h>
 #include <linux/of.h>
 #include <linux/of_device.h>
+#include <linux/of_dma.h>
 
 #include <asm/irq.h>
 #include <linux/platform_data/dma-imx-sdma.h>
@@ -1296,6 +1297,35 @@ err_dma_alloc:
 	return ret;
 }
 
+static bool sdma_filter_fn(struct dma_chan *chan, void *fn_param)
+{
+	struct imx_dma_data *data = fn_param;
+
+	if (!imx_dma_is_general_purpose(chan))
+		return false;
+
+	chan->private = data;
+
+	return true;
+}
+
+struct dma_chan *sdma_xlate(struct of_phandle_args *dma_spec,
+			    struct of_dma *ofdma)
+{
+	struct sdma_engine *sdma = ofdma->of_dma_data;
+	dma_cap_mask_t mask = sdma->dma_device.cap_mask;
+	struct imx_dma_data data;
+
+	if (dma_spec->args_count != 3)
+		return NULL;
+
+	data.dma_request = dma_spec->args[0];
+	data.peripheral_type = dma_spec->args[1];
+	data.priority = dma_spec->args[2];
+
+	return dma_request_channel(mask, sdma_filter_fn, &data);
+}
+
 static int __init sdma_probe(struct platform_device *pdev)
 {
 	const struct of_device_id *of_id =
@@ -1443,10 +1473,20 @@ static int __init sdma_probe(struct platform_device *pdev)
 		goto err_init;
 	}
 
+	if (np) {
+		ret = of_dma_controller_register(np, sdma_xlate, sdma);
+		if (ret) {
+			dev_err(&pdev->dev, "failed to register controller\n");
+			goto err_register;
+		}
+	}
+
 	dev_info(sdma->dev, "initialized\n");
 
 	return 0;
 
+err_register:
+	dma_async_device_unregister(&sdma->dma_device);
 err_init:
 	kfree(sdma->script_addrs);
 err_alloc:
diff --git a/include/dt-bindings/dma/imx.h b/include/dt-bindings/dma/imx.h
new file mode 100644
index 0000000..d5de68c
--- /dev/null
+++ b/include/dt-bindings/dma/imx.h
@@ -0,0 +1,29 @@
+/*
+ * This enumerates peripheral types. Used for SDMA.
+ */
+#define IMX_DMATYPE_SSI		0  /* MCU domain SSI */
+#define IMX_DMATYPE_SSI_SP	1  /* Shared SSI */
+#define IMX_DMATYPE_MMC		2  /* MMC */
+#define IMX_DMATYPE_SDHC	3  /* SDHC */
+#define IMX_DMATYPE_UART	4  /* MCU domain UART */
+#define IMX_DMATYPE_UART_SP	5  /* Shared UART */
+#define IMX_DMATYPE_FIRI	6  /* FIRI */
+#define IMX_DMATYPE_CSPI	7  /* MCU domain CSPI */
+#define IMX_DMATYPE_CSPI_SP	8  /* Shared CSPI */
+#define IMX_DMATYPE_SIM		9  /* SIM */
+#define IMX_DMATYPE_ATA		10 /* ATA */
+#define IMX_DMATYPE_CCM		11 /* CCM */
+#define IMX_DMATYPE_EXT		12 /* External peripheral */
+#define IMX_DMATYPE_MSHC	13 /* Memory Stick Host Controller */
+#define IMX_DMATYPE_MSHC_SP	14 /* Shared Memory Stick Host Controller */
+#define IMX_DMATYPE_DSP		15 /* DSP */
+#define IMX_DMATYPE_MEMORY	16 /* Memory */
+#define IMX_DMATYPE_FIFO_MEMORY	17 /* FIFO type Memory */
+#define IMX_DMATYPE_SPDIF	18 /* SPDIF */
+#define IMX_DMATYPE_IPU_MEMORY	19 /* IPU Memory */
+#define IMX_DMATYPE_ASRC	20 /* ASRC */
+#define IMX_DMATYPE_ESAI	21 /* ESAI */
+
+#define DMA_PRIO_HIGH		0
+#define DMA_PRIO_MEDIUM		1
+#define DMA_PRIO_LOW		2
diff --git a/include/linux/platform_data/dma-imx.h b/include/linux/platform_data/dma-imx.h
index 8a8a684..33f7eda 100644
--- a/include/linux/platform_data/dma-imx.h
+++ b/include/linux/platform_data/dma-imx.h
@@ -12,36 +12,7 @@
 #include <linux/scatterlist.h>
 #include <linux/device.h>
 #include <linux/dmaengine.h>
-
-/*
- * This enumerates peripheral types. Used for SDMA.
- */
-#define IMX_DMATYPE_SSI		0  /* MCU domain SSI */
-#define IMX_DMATYPE_SSI_SP	1  /* Shared SSI */
-#define IMX_DMATYPE_MMC		2  /* MMC */
-#define IMX_DMATYPE_SDHC	3  /* SDHC */
-#define IMX_DMATYPE_UART	4  /* MCU domain UART */
-#define IMX_DMATYPE_UART_SP	5  /* Shared UART */
-#define IMX_DMATYPE_FIRI	6  /* FIRI */
-#define IMX_DMATYPE_CSPI	7  /* MCU domain CSPI */
-#define IMX_DMATYPE_CSPI_SP	8  /* Shared CSPI */
-#define IMX_DMATYPE_SIM		9  /* SIM */
-#define IMX_DMATYPE_ATA		10 /* ATA */
-#define IMX_DMATYPE_CCM		11 /* CCM */
-#define IMX_DMATYPE_EXT		12 /* External peripheral */
-#define IMX_DMATYPE_MSHC	13 /* Memory Stick Host Controller */
-#define IMX_DMATYPE_MSHC_SP	14 /* Shared Memory Stick Host Controller */
-#define IMX_DMATYPE_DSP		15 /* DSP */
-#define IMX_DMATYPE_MEMORY	16 /* Memory */
-#define IMX_DMATYPE_FIFO_MEMORY	17 /* FIFO type Memory */
-#define IMX_DMATYPE_SPDIF	18 /* SPDIF */
-#define IMX_DMATYPE_IPU_MEMORY	19 /* IPU Memory */
-#define IMX_DMATYPE_ASRC	20 /* ASRC */
-#define IMX_DMATYPE_ESAI	21 /* ESAI */
-
-#define DMA_PRIO_HIGH		0
-#define DMA_PRIO_MEDIUM		1
-#define DMA_PRIO_LOW		2
+#include <dt-bindings/dma/imx.h>
 
 struct imx_dma_data {
 	int dma_request; /* DMA request line */
-- 
1.7.9.5




From shawn.guo at linaro.org  Wed Apr 24 10:04:32 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Wed, 24 Apr 2013 22:04:32 +0800
Subject: [PATCH 1/2] dma: imx: change enum definitions to macros
In-Reply-To: <1366812273-10833-1-git-send-email-shawn.guo@linaro.org>
References: <1366812273-10833-1-git-send-email-shawn.guo@linaro.org>
Message-ID: <1366812273-10833-2-git-send-email-shawn.guo@linaro.org>

Change enum sdma_peripheral_type and imx_dma_prio to macro definitions
for easing the migration to generic DMA device tree bindings later.

Signed-off-by: Shawn Guo <shawn.guo at linaro.org>
---
 drivers/dma/imx-sdma.c                |    4 +--
 include/linux/platform_data/dma-imx.h |   56 +++++++++++++++------------------
 2 files changed, 28 insertions(+), 32 deletions(-)

diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index 092867b..e57a0c6 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -249,7 +249,7 @@ struct sdma_channel {
 	struct sdma_engine		*sdma;
 	unsigned int			channel;
 	enum dma_transfer_direction		direction;
-	enum sdma_peripheral_type	peripheral_type;
+	int				peripheral_type;
 	unsigned int			event_id0;
 	unsigned int			event_id1;
 	enum dma_slave_buswidth		word_size;
@@ -580,7 +580,7 @@ static irqreturn_t sdma_int_handler(int irq, void *dev_id)
  * sets the pc of SDMA script according to the peripheral type
  */
 static void sdma_get_pc(struct sdma_channel *sdmac,
-		enum sdma_peripheral_type peripheral_type)
+		int peripheral_type)
 {
 	struct sdma_engine *sdma = sdmac->sdma;
 	int per_2_emi = 0, emi_2_per = 0;
diff --git a/include/linux/platform_data/dma-imx.h b/include/linux/platform_data/dma-imx.h
index f6d30cc..8a8a684 100644
--- a/include/linux/platform_data/dma-imx.h
+++ b/include/linux/platform_data/dma-imx.h
@@ -16,40 +16,36 @@
 /*
  * This enumerates peripheral types. Used for SDMA.
  */
-enum sdma_peripheral_type {
-	IMX_DMATYPE_SSI,	/* MCU domain SSI */
-	IMX_DMATYPE_SSI_SP,	/* Shared SSI */
-	IMX_DMATYPE_MMC,	/* MMC */
-	IMX_DMATYPE_SDHC,	/* SDHC */
-	IMX_DMATYPE_UART,	/* MCU domain UART */
-	IMX_DMATYPE_UART_SP,	/* Shared UART */
-	IMX_DMATYPE_FIRI,	/* FIRI */
-	IMX_DMATYPE_CSPI,	/* MCU domain CSPI */
-	IMX_DMATYPE_CSPI_SP,	/* Shared CSPI */
-	IMX_DMATYPE_SIM,	/* SIM */
-	IMX_DMATYPE_ATA,	/* ATA */
-	IMX_DMATYPE_CCM,	/* CCM */
-	IMX_DMATYPE_EXT,	/* External peripheral */
-	IMX_DMATYPE_MSHC,	/* Memory Stick Host Controller */
-	IMX_DMATYPE_MSHC_SP,	/* Shared Memory Stick Host Controller */
-	IMX_DMATYPE_DSP,	/* DSP */
-	IMX_DMATYPE_MEMORY,	/* Memory */
-	IMX_DMATYPE_FIFO_MEMORY,/* FIFO type Memory */
-	IMX_DMATYPE_SPDIF,	/* SPDIF */
-	IMX_DMATYPE_IPU_MEMORY,	/* IPU Memory */
-	IMX_DMATYPE_ASRC,	/* ASRC */
-	IMX_DMATYPE_ESAI,	/* ESAI */
-};
+#define IMX_DMATYPE_SSI		0  /* MCU domain SSI */
+#define IMX_DMATYPE_SSI_SP	1  /* Shared SSI */
+#define IMX_DMATYPE_MMC		2  /* MMC */
+#define IMX_DMATYPE_SDHC	3  /* SDHC */
+#define IMX_DMATYPE_UART	4  /* MCU domain UART */
+#define IMX_DMATYPE_UART_SP	5  /* Shared UART */
+#define IMX_DMATYPE_FIRI	6  /* FIRI */
+#define IMX_DMATYPE_CSPI	7  /* MCU domain CSPI */
+#define IMX_DMATYPE_CSPI_SP	8  /* Shared CSPI */
+#define IMX_DMATYPE_SIM		9  /* SIM */
+#define IMX_DMATYPE_ATA		10 /* ATA */
+#define IMX_DMATYPE_CCM		11 /* CCM */
+#define IMX_DMATYPE_EXT		12 /* External peripheral */
+#define IMX_DMATYPE_MSHC	13 /* Memory Stick Host Controller */
+#define IMX_DMATYPE_MSHC_SP	14 /* Shared Memory Stick Host Controller */
+#define IMX_DMATYPE_DSP		15 /* DSP */
+#define IMX_DMATYPE_MEMORY	16 /* Memory */
+#define IMX_DMATYPE_FIFO_MEMORY	17 /* FIFO type Memory */
+#define IMX_DMATYPE_SPDIF	18 /* SPDIF */
+#define IMX_DMATYPE_IPU_MEMORY	19 /* IPU Memory */
+#define IMX_DMATYPE_ASRC	20 /* ASRC */
+#define IMX_DMATYPE_ESAI	21 /* ESAI */
 
-enum imx_dma_prio {
-	DMA_PRIO_HIGH = 0,
-	DMA_PRIO_MEDIUM = 1,
-	DMA_PRIO_LOW = 2
-};
+#define DMA_PRIO_HIGH		0
+#define DMA_PRIO_MEDIUM		1
+#define DMA_PRIO_LOW		2
 
 struct imx_dma_data {
 	int dma_request; /* DMA request line */
-	enum sdma_peripheral_type peripheral_type;
+	int peripheral_type;
 	int priority;
 };
 
-- 
1.7.9.5




From shawn.guo at linaro.org  Wed Apr 24 10:04:31 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Wed, 24 Apr 2013 22:04:31 +0800
Subject: [PATCH 0/2] dma: imx-sdma: add generic DMA device tree bindings
 support
Message-ID: <1366812273-10833-1-git-send-email-shawn.guo@linaro.org>

The series adds add generic DMA device tree bindings support for
imx-sdma.  The legacy DMA requesting support is still there and will
be removed after all clients get converted to generic DMA DT helper.

Shawn Guo (2):
  dma: imx: change enum definitions to macros
  dma: imx-sdma: move to generic device tree bindings

 .../devicetree/bindings/dma/fsl-imx-sdma.txt       |   22 ++++++++++
 drivers/dma/imx-sdma.c                             |   44 +++++++++++++++++++-
 include/dt-bindings/dma/imx.h                      |   29 +++++++++++++
 include/linux/platform_data/dma-imx.h              |   37 +---------------
 4 files changed, 95 insertions(+), 37 deletions(-)
 create mode 100644 include/dt-bindings/dma/imx.h

-- 
1.7.9.5




From festevam at gmail.com  Wed Apr 24 10:23:04 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Wed, 24 Apr 2013 11:23:04 -0300
Subject: [PATCH 2/2] dma: imx-sdma: move to generic device tree bindings
In-Reply-To: <1366812273-10833-3-git-send-email-shawn.guo@linaro.org>
References: <1366812273-10833-1-git-send-email-shawn.guo@linaro.org>
 <1366812273-10833-3-git-send-email-shawn.guo@linaro.org>
Message-ID: <CAOMZO5BkPTZ7guS1cPeZ+s7vXWh1-9Tf7GyJ6ro6tzOHn_Cm_Q@mail.gmail.com>

On Wed, Apr 24, 2013 at 11:04 AM, Shawn Guo <shawn.guo at linaro.org> wrote:

> +ssi2: ssi at 70014000 {
> +       compatible = "fsl,imx51-ssi", "fsl,imx21-ssi";
> +       reg = <0x70014000 0x4000>;
> +       interrupts = <30>;
> +       clocks = <&clks 49>;
> +       dmas = <&sdma 24 DMA_PRIO_HIGH IMX_DMATYPE_SSI_SP>,
> +              <&sdma 25 DMA_PRIO_HIGH IMX_DMATYPE_SSI_SP>;

The document says:
"third cell specifies the peripheral type and priority of DMA transfer
respectively"

,but what I see in this example is the opposite:

priority of DMA and then peripheral type.


From andrew at lunn.ch  Wed Apr 24 10:23:12 2013
From: andrew at lunn.ch (Andrew Lunn)
Date: Wed, 24 Apr 2013 16:23:12 +0200
Subject: [PATCH] cpuidle: add maintainer entry
In-Reply-To: <1366810463-17495-1-git-send-email-daniel.lezcano@linaro.org>
References: <1366810463-17495-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <20130424142312.GA2824@lunn.ch>

On Wed, Apr 24, 2013 at 03:34:23PM +0200, Daniel Lezcano wrote:
> Currently the cpuidle drivers are spread across the different archs.
> 
> The patch submission for cpuidle are following different path: the cpuidle core
> code goes to linux-pm, the ARM drivers goes to arm-soc or the SoC specific
> tree, sh goes through sh arch tree, pseries goes through PowerPC and
> finally intel goes through Len's tree while acpi_idle goes under linux-pm.
> 
> That makes difficult to consolidate the code and to propagate modifications
> from the cpuidle core to the different drivers.
> 
> Hopefully, a movement has initiated to put the cpuidle drivers into the
> drivers/cpuidle directory like cpuidle-calxeda.c and cpuidle-kirkwood.c
> 
> Add an explicit maintainer entry in the MAINTAINER to clarify the situation
> and prevent new cpuidle drivers to goes to an arch directory.
> 
> The upstreaming process is unchanged: Rafael takes the patches to merge them
> into its tree but with the acked-by from the driver's maintainer. So the header
> must contains the name of the maintainer.
> 
> This organization will be the same than cpufreq.
> 
> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
> ---
>  MAINTAINERS                        |    7 +++++++
>  drivers/cpuidle/cpuidle-calxeda.c  |    4 +++-
>  drivers/cpuidle/cpuidle-kirkwood.c |    5 +++--
>  3 files changed, 13 insertions(+), 3 deletions(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 61677c3..effa0f3 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2206,6 +2206,13 @@ S:	Maintained
>  F:	drivers/cpufreq/
>  F:	include/linux/cpufreq.h
>  
> +CPUIDLE DRIVERS
> +M:	Rafael J. Wysocki <rjw at sisk.pl>
> +L:	linux-pm at vger.kernel.org
> +S:	Maintained
> +F:	drivers/cpuidle/*
> +F:	include/linux/cpuidle.h
> +
>  CPU FREQUENCY DRIVERS - ARM BIG LITTLE
>  M:	Viresh Kumar <viresh.kumar at linaro.org>
>  M:	Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
> diff --git a/drivers/cpuidle/cpuidle-calxeda.c b/drivers/cpuidle/cpuidle-calxeda.c
> index e344b56..2378c39 100644
> --- a/drivers/cpuidle/cpuidle-calxeda.c
> +++ b/drivers/cpuidle/cpuidle-calxeda.c
> @@ -1,7 +1,6 @@
>  /*
>   * Copyright 2012 Calxeda, Inc.
>   *
> - * Based on arch/arm/plat-mxc/cpuidle.c:
>   * Copyright 2012 Freescale Semiconductor, Inc.
>   * Copyright 2012 Linaro Ltd.
>   *
> @@ -16,6 +15,9 @@
>   *
>   * You should have received a copy of the GNU General Public License along with
>   * this program.  If not, see <http://www.gnu.org/licenses/>.
> + *
> + * Author    : Rob Herring <rob.herring at calxeda.com>
> + * Maintainer: Rob Herring <rob.herring at calxeda.com>
>   */
>  
>  #include <linux/cpuidle.h>
> diff --git a/drivers/cpuidle/cpuidle-kirkwood.c b/drivers/cpuidle/cpuidle-kirkwood.c
> index 53290e1..521b0a7 100644
> --- a/drivers/cpuidle/cpuidle-kirkwood.c
> +++ b/drivers/cpuidle/cpuidle-kirkwood.c
> @@ -1,6 +1,4 @@
>  /*
> - * arch/arm/mach-kirkwood/cpuidle.c
> - *
>   * CPU idle Marvell Kirkwood SoCs
>   *
>   * This file is licensed under the terms of the GNU General Public
> @@ -11,6 +9,9 @@
>   * to implement two idle states -
>   * #1 wait-for-interrupt
>   * #2 wait-for-interrupt and DDR self refresh
> + *
> + * Maintainer: Jason Cooper <jason at lakedaemon.net>
> + * Maintainer: Andrew Lunn <andrew at lunn.ch>
>   */
>  

For the Kirkwood part

Acked-by: Andrew Lunn <andrew at lunn.ch>

	  Andrew


From linus.walleij at stericsson.com  Wed Apr 24 10:25:34 2013
From: linus.walleij at stericsson.com (Linus Walleij)
Date: Wed, 24 Apr 2013 16:25:34 +0200
Subject: [PATCH] pinctrl/pinconfig: fix misplaced goto
Message-ID: <1366813534-2460-1-git-send-email-linus.walleij@stericsson.com>

From: Laurent Meunier <laurent.meunier at st.com>

This update contains a basic fix that went unseen through
test and review.

Signed-off-by: Laurent Meunier <laurent.meunier at st.com>
Reviewed-by: Patrice Chotard <patrice.chotard at stericsson.com>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 drivers/pinctrl/pinconf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pinctrl/pinconf.c b/drivers/pinctrl/pinconf.c
index 3578667..c67c37e 100644
--- a/drivers/pinctrl/pinconf.c
+++ b/drivers/pinctrl/pinconf.c
@@ -771,8 +771,8 @@ static int pinconf_dbg_config_write(struct file *file,
 	}
 
 	if (!found) {
-		goto exit;
 		count = -EINVAL;
+		goto exit;
 	}
 
 	if (pctldev)
-- 
1.7.11.3



From dave.martin at linaro.org  Wed Apr 24 10:25:47 2013
From: dave.martin at linaro.org (Dave Martin)
Date: Wed, 24 Apr 2013 15:25:47 +0100
Subject: [PATCH v4 00/15] multi-cluster power management
In-Reply-To: <alpine.LFD.2.03.1304231657150.17375@syhkavp.arg>
References: <1360041732-17936-1-git-send-email-nicolas.pitre@linaro.org>
 <20130423200429.GF5316@n2100.arm.linux.org.uk>
 <alpine.LFD.2.03.1304231657150.17375@syhkavp.arg>
Message-ID: <20130424142547.GB2664@linaro.org>

On Tue, Apr 23, 2013 at 05:03:06PM -0400, Nicolas Pitre wrote:
> On Tue, 23 Apr 2013, Russell King - ARM Linux wrote:
> 
> > What I suggest for the time being is to provide new inline function(s)
> > in arch/arm/include/cacheflush.h which are purposed for your application,
> > document them in that file, and call the implementation you're currently
> > using.  That means if we do have to change it in the future (for example,
> > we don't need to do anything in the dcache flushing stuff) we don't have
> > to hunt through all the code to find _your_ different use of that function
> > and fix it - we can just fix it in one place and we have the reference
> > there for what your code expects.
> 
> What about the patch below?  Once you tell me it is fine to you I'll 
> adapt the MCPM series to it.

This looks appropriate for mcpm's needs, and generic enough for other
code to reuse.  Thanks for that.

Acked-by: Dave Martin <dave.martin at linaro.org>

> 
> ----- >8
> From: Nicolas Pitre <nicolas.pitre at linaro.org>
> Date: Tue, 23 Apr 2013 16:45:40 -0400
> Subject: [PATCH] ARM: cacheflush: add synchronization helpers for mixed cache state accesses
> 
> Algorithms used by the MCPM layer rely on state variables which are
> accessed while the cache is either active or inactive, depending
> on the code path and the active state.
> 
> This patch introduces generic cache maintenance helpers to provide the
> necessary cache synchronization for such state variables to always hit
> main memory in a ordered way.
> 
> Signed-off-by: Nicolas Pitre <nico at linaro.org>
> 
> diff --git a/arch/arm/include/asm/cacheflush.h b/arch/arm/include/asm/cacheflush.h
> index e1489c54cd..bff71388e7 100644
> --- a/arch/arm/include/asm/cacheflush.h
> +++ b/arch/arm/include/asm/cacheflush.h
> @@ -363,4 +363,79 @@ static inline void flush_cache_vunmap(unsigned long start, unsigned long end)
>  		flush_cache_all();
>  }
>  
> +/*
> + * Memory synchronization helpers for mixed cached vs non cached accesses.
> + *
> + * Some synchronization algorithms have to set states in memory with the
> + * cache enabled or disabled depending on the code path.  It is crucial
> + * to always ensure proper cache maintenance to update main memory right
> + * away in that case.
> + *
> + * Any cached write must be followed by a cache clean operation.
> + * Any cached read must be preceded by a cache invalidate operation.
> + * Yet, in the read case, a cache flush i.e. atomic clean+invalidate
> + * operation is needed to avoid discarding possible concurrent writes to the
> + * accessed memory.
> + *
> + * Also, in order to prevent a cached writer from interfering with an
> + * adjacent non-cached writer, each state variable must be located to
> + * a separate cache line.
> + */
> +
> +/*
> + * This needs to be >= the max cache writeback size of all
> + * supported platforms included in the current kernel configuration.
> + * This is used to align state variables to their own cache lines.
> + */
> +#define __CACHE_WRITEBACK_ORDER 6  /* guessed from existing platforms */
> +#define __CACHE_WRITEBACK_GRANULE (1 << __CACHE_WRITEBACK_ORDER)
> +
> +/*
> + * There is no __cpuc_clean_dcache_area but we use it anyway for
> + * code intent clarity, and alias it to __cpuc_flush_dcache_area.
> + */
> +#define __cpuc_clean_dcache_area __cpuc_flush_dcache_area
> +
> +/*
> + * Ensure preceding writes to *p by this CPU are visible to
> + * subsequent reads by other CPUs:
> + */
> +static inline void __sync_cache_range_w(volatile void *p, size_t size)
> +{
> +	char *_p = (char *)p;
> +
> +	__cpuc_clean_dcache_area(_p, size);
> +	outer_clean_range(__pa(_p), __pa(_p + size));
> +}
> +
> +/*
> + * Ensure preceding writes to *p by other CPUs are visible to
> + * subsequent reads by this CPU.  We must be careful not to
> + * discard data simultaneously written by another CPU, hence the
> + * usage of flush rather than invalidate operations.
> + */
> +static inline void __sync_cache_range_r(volatile void *p, size_t size)
> +{
> +	char *_p = (char *)p;
> +
> +#ifdef CONFIG_OUTER_CACHE
> +	if (outer_cache.flush_range) {
> +		/*
> +		 * Ensure dirty data migrated from other CPUs into our cache
> +		 * are cleaned out safely before the outer cache is cleaned:
> +		 */
> +		__cpuc_clean_dcache_area(_p, size);
> +
> +		/* Clean and invalidate stale data for *p from outer ... */
> +		outer_flush_range(__pa(_p), __pa(_p + size));
> +	}
> +#endif
> +
> +	/* ... and inner cache: */
> +	__cpuc_flush_dcache_area(_p, size);
> +}
> +
> +#define sync_cache_w(ptr) __sync_cache_range_w(ptr, sizeof *(ptr))
> +#define sync_cache_r(ptr) __sync_cache_range_r(ptr, sizeof *(ptr))
> +
>  #endif


From arnd at arndb.de  Wed Apr 24 10:26:22 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed, 24 Apr 2013 16:26:22 +0200
Subject: [PATCH 2/2] dma: imx-sdma: move to generic device tree bindings
In-Reply-To: <1366812273-10833-3-git-send-email-shawn.guo@linaro.org>
References: <1366812273-10833-1-git-send-email-shawn.guo@linaro.org>
 <1366812273-10833-3-git-send-email-shawn.guo@linaro.org>
Message-ID: <201304241626.22518.arnd@arndb.de>

On Wednesday 24 April 2013, Shawn Guo wrote:
> +/*
> + * This enumerates peripheral types. Used for SDMA.
> + */
> +#define IMX_DMATYPE_SSI                0  /* MCU domain SSI */
> +#define IMX_DMATYPE_SSI_SP     1  /* Shared SSI */
> +#define IMX_DMATYPE_MMC                2  /* MMC */
> +#define IMX_DMATYPE_SDHC       3  /* SDHC */
> +#define IMX_DMATYPE_UART       4  /* MCU domain UART */
> +#define IMX_DMATYPE_UART_SP    5  /* Shared UART */
> +#define IMX_DMATYPE_FIRI       6  /* FIRI */
> +#define IMX_DMATYPE_CSPI       7  /* MCU domain CSPI */
> +#define IMX_DMATYPE_CSPI_SP    8  /* Shared CSPI */
> +#define IMX_DMATYPE_SIM                9  /* SIM */
> +#define IMX_DMATYPE_ATA                10 /* ATA */
> +#define IMX_DMATYPE_CCM                11 /* CCM */
> +#define IMX_DMATYPE_EXT                12 /* External peripheral */
> +#define IMX_DMATYPE_MSHC       13 /* Memory Stick Host Controller */
> +#define IMX_DMATYPE_MSHC_SP    14 /* Shared Memory Stick Host Controller */
> +#define IMX_DMATYPE_DSP                15 /* DSP */
> +#define IMX_DMATYPE_MEMORY     16 /* Memory */
> +#define IMX_DMATYPE_FIFO_MEMORY        17 /* FIFO type Memory */
> +#define IMX_DMATYPE_SPDIF      18 /* SPDIF */
> +#define IMX_DMATYPE_IPU_MEMORY 19 /* IPU Memory */
> +#define IMX_DMATYPE_ASRC       20 /* ASRC */
> +#define IMX_DMATYPE_ESAI       21 /* ESAI */

These macros don't seem helpful to me, since they are used in only one
place each. Why not put the literal numbers into the dts file directly?

	Arnd


From balbi at ti.com  Wed Apr 24 10:26:15 2013
From: balbi at ti.com (Felipe Balbi)
Date: Wed, 24 Apr 2013 17:26:15 +0300
Subject: [PATCH 04/10] usb: musb: ux500: harden checks for platform data
In-Reply-To: <5177E57C.3010802@cogentembedded.com>
References: <1366729394-11406-1-git-send-email-lee.jones@linaro.org>
 <1366729394-11406-5-git-send-email-lee.jones@linaro.org>
 <5176E927.908@cogentembedded.com>
 <20130424065344.GB17416@gmail.com>
 <5177E57C.3010802@cogentembedded.com>
Message-ID: <20130424142615.GF23081@arwen.pp.htv.fi>

On Wed, Apr 24, 2013 at 06:00:28PM +0400, Sergei Shtylyov wrote:
> Hello.
> 
> On 24-04-2013 10:53, Lee Jones wrote:
> 
> >>>  	struct musb_hdrc_platform_data *plat = dev->platform_data;
> >>>-	struct ux500_musb_board_data *data = plat->board_data;
> >>>+	struct ux500_musb_board_data *data;
> 
> >>>-	param_array = data->dma_rx_param_array;
> >>>+	param_array = (data) ? data->dma_rx_param_array : NULL;
> 
> >>    Why enclose a simple variable in parens?
> 
> >Because 'data' is a pointer, so it contains a memory location,

heh, I don't think you fully understood Sergei's comment. He's asking
why you used:

	param_array = (data) ? data->dma_rx_param_array : NULL;

instead of:

	param_array = data ? data->dma_rx_param_array : NULL;

He's saying, correctly so, that the parens around data is unnecessary.

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130424/be915c41/attachment.sig>

From linus.walleij at linaro.org  Wed Apr 24 10:27:09 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Wed, 24 Apr 2013 16:27:09 +0200
Subject: [PATCH 2/2] pinctrl: samsung: Fix link error with
 CONFIG_PINCTRL_EXYNOS disabled
In-Reply-To: <6940961.67Lk2axxPL@amdc1227>
References: <1366060483-20342-1-git-send-email-tomasz.figa@gmail.com>
 <1398545.9FqHoC0WZW@flatron>
 <CACRpkdbJj9Newk+sCTvJzxA4V2cmJ3hzuQELv7t1wFMhd_Y8+Q@mail.gmail.com>
 <6940961.67Lk2axxPL@amdc1227>
Message-ID: <CACRpkdZmSj-AqUA9kd7NMN6cL2Nxa0EaKoSVkwQSrxhcWEeQtg@mail.gmail.com>

On Tue, Apr 23, 2013 at 2:09 PM, Tomasz Figa <t.figa at samsung.com> wrote:
> On Tuesday 23 of April 2013 14:03:12 Linus Walleij wrote:

>> This does not apply to my "devel" branch in the pinctrl tree.
>>
>> Could you rebase it on that branch?
>>
>> Or is the error not even in my tree?
>
> This one got sent incorrectly due to my mistake. Please try the correct
> version:
>
> [PATCH RESEND 2/2] pinctrl: samsung: Fix link error with CONFIG_PINCTRL_EXYNOS
> disabled

This does not apply either.

Can you please test against the "devel" branch in the pinctrl tree?

Yours,
Linus Walleij


From mpa at pengutronix.de  Wed Apr 24 10:36:33 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Wed, 24 Apr 2013 16:36:33 +0200
Subject: [PATCH v5 04/10] ASoC: fsl-ssi: Add support for imx-pcm-fiq
In-Reply-To: <1366814199-14827-1-git-send-email-mpa@pengutronix.de>
References: <1366814199-14827-1-git-send-email-mpa@pengutronix.de>
Message-ID: <1366814199-14827-5-git-send-email-mpa@pengutronix.de>

Add support for non-dma pcm for imx platforms with imx-pcm-fiq support.
Instead of imx-pcm-audio, in this case imx-pcm-fiq-audio device is added
and the SIER flags are set differently.

We need imx-pcm-fiq for some boards that use an incompatible codec.
imx-pcm-fiq handles those codecs differently and allows to operate with
them. DMA is not possible because some data sent by the codecs, e.g.
wm9712, is not in the datastream. Also some data is mixed up in the
fifos, so that we need to sort them out manually.

Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
---

Notes:
    Changes in v4:
     - Add a comment about the reason why we add a imx-pcm-fiq device.
     - Change commit message to include information about the usage of imx-pcm-fiq
    
    Changes in v3:
     - Rename bool "dma" to "use_dma"

 sound/soc/fsl/fsl_ssi.c | 94 +++++++++++++++++++++++++++++++++++++++++--------
 1 file changed, 80 insertions(+), 14 deletions(-)

diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index 0f0bed6..5165d41 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -8,6 +8,26 @@
  * 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.
+ *
+ *
+ * Some notes why imx-pcm-fiq is used instead of DMA on some boards:
+ *
+ * The i.MX SSI core has some nasty limitations in AC97 mode. While most
+ * sane processor vendors have a FIFO per AC97 slot, the i.MX has only
+ * one FIFO which combines all valid receive slots. We cannot even select
+ * which slots we want to receive. The WM9712 with which this driver
+ * was developed with always sends GPIO status data in slot 12 which
+ * we receive in our (PCM-) data stream. The only chance we have is to
+ * manually skip this data in the FIQ handler. With sampling rates different
+ * from 48000Hz not every frame has valid receive data, so the ratio
+ * between pcm data and GPIO status data changes. Our FIQ handler is not
+ * able to handle this, hence this driver only works with 48000Hz sampling
+ * rate.
+ * Reading and writing AC97 registers is another challenge. The core
+ * provides us status bits when the read register is updated with *another*
+ * value. When we read the same register two times (and the register still
+ * contains the same value) these status bits are not set. We work
+ * around this by not polling these bits but only wait a fixed delay.
  */
 
 #include <linux/init.h>
@@ -121,12 +141,14 @@ struct fsl_ssi_private {
 
 	bool new_binding;
 	bool ssi_on_imx;
+	bool use_dma;
 	struct clk *clk;
 	struct platform_device *imx_pcm_pdev;
 	struct snd_dmaengine_dai_dma_data dma_params_tx;
 	struct snd_dmaengine_dai_dma_data dma_params_rx;
 	struct imx_dma_data filter_data_tx;
 	struct imx_dma_data filter_data_rx;
+	struct imx_pcm_fiq_params fiq_params;
 
 	struct {
 		unsigned int rfrc;
@@ -356,7 +378,12 @@ static int fsl_ssi_startup(struct snd_pcm_substream *substream,
 		 */
 
 		/* Enable the interrupts and DMA requests */
-		write_ssi(SIER_FLAGS, &ssi->sier);
+		if (ssi_private->use_dma)
+			write_ssi(SIER_FLAGS, &ssi->sier);
+		else
+			write_ssi(CCSR_SSI_SIER_TIE | CCSR_SSI_SIER_TFE0_EN |
+					CCSR_SSI_SIER_RIE |
+					CCSR_SSI_SIER_RFF0_EN, &ssi->sier);
 
 		/*
 		 * Set the watermark for transmit FIFI 0 and receive FIFO 0. We
@@ -550,7 +577,7 @@ static int fsl_ssi_dai_probe(struct snd_soc_dai *dai)
 {
 	struct fsl_ssi_private *ssi_private = snd_soc_dai_get_drvdata(dai);
 
-	if (ssi_private->ssi_on_imx) {
+	if (ssi_private->ssi_on_imx && ssi_private->use_dma) {
 		dai->playback_dma_data = &ssi_private->dma_params_tx;
 		dai->capture_dma_data = &ssi_private->dma_params_rx;
 	}
@@ -695,6 +722,8 @@ static int fsl_ssi_probe(struct platform_device *pdev)
 	       sizeof(fsl_ssi_dai_template));
 	ssi_private->cpu_dai_drv.name = ssi_private->name;
 
+	ssi_private->use_dma = !of_property_read_bool(np, "fsl,imx-fiq");
+
 	/* Get the addresses and IRQ */
 	ret = of_address_to_resource(np, 0, &res);
 	if (ret) {
@@ -716,12 +745,15 @@ static int fsl_ssi_probe(struct platform_device *pdev)
 		goto error_iomap;
 	}
 
-	/* The 'name' should not have any slashes in it. */
-	ret = request_irq(ssi_private->irq, fsl_ssi_isr, 0, ssi_private->name,
-			  ssi_private);
-	if (ret < 0) {
-		dev_err(&pdev->dev, "could not claim irq %u\n", ssi_private->irq);
-		goto error_irqmap;
+	if (ssi_private->use_dma) {
+		/* The 'name' should not have any slashes in it. */
+		ret = request_irq(ssi_private->irq, fsl_ssi_isr, 0,
+				ssi_private->name, ssi_private);
+		if (ret < 0) {
+			dev_err(&pdev->dev, "could not claim irq %u\n",
+					ssi_private->irq);
+			goto error_irqmap;
+		}
 	}
 
 	/* Are the RX and the TX clocks locked? */
@@ -770,7 +802,7 @@ static int fsl_ssi_probe(struct platform_device *pdev)
 		 */
 		ret = of_property_read_u32_array(pdev->dev.of_node,
 					"fsl,ssi-dma-events", dma_events, 2);
-		if (ret) {
+		if (ret && !ssi_private->use_dma) {
 			dev_err(&pdev->dev, "could not get dma events\n");
 			goto error_clk;
 		}
@@ -809,12 +841,46 @@ static int fsl_ssi_probe(struct platform_device *pdev)
 	}
 
 	if (ssi_private->ssi_on_imx) {
-		ssi_private->imx_pcm_pdev =
-			platform_device_register_simple("imx-pcm-audio",
+		if (!ssi_private->use_dma) {
+
+			/*
+			 * Some boards use an incompatible codec. To get it
+			 * working, we are using imx-fiq-pcm-audio, that
+			 * can handle those codecs. DMA is not possible in this
+			 * situation.
+			 */
+
+			ssi_private->imx_pcm_pdev = platform_device_alloc(
+							"imx-fiq-pcm-audio",
+							pdev->id);
+			if (!ssi_private->imx_pcm_pdev) {
+				ret = -ENOMEM;
+				goto error_dev;
+			}
+
+			ssi_private->fiq_params.irq = ssi_private->irq;
+			ssi_private->fiq_params.base = ssi_private->ssi;
+			ssi_private->fiq_params.dma_params_rx =
+				&ssi_private->dma_params_rx;
+			ssi_private->fiq_params.dma_params_tx =
+				&ssi_private->dma_params_tx;
+
+			platform_set_drvdata(ssi_private->imx_pcm_pdev,
+					&ssi_private->fiq_params);
+			ret = platform_device_add(ssi_private->imx_pcm_pdev);
+			if (ret) {
+				dev_err(&pdev->dev, "Failed to add imx-fiq-pcm-audio device\n");
+				platform_device_put(ssi_private->imx_pcm_pdev);
+				goto error_dev;
+			}
+		} else {
+			ssi_private->imx_pcm_pdev =
+				platform_device_register_simple("imx-pcm-audio",
 							-1, NULL, 0);
-		if (IS_ERR(ssi_private->imx_pcm_pdev)) {
-			ret = PTR_ERR(ssi_private->imx_pcm_pdev);
-			goto error_dev;
+			if (IS_ERR(ssi_private->imx_pcm_pdev)) {
+				ret = PTR_ERR(ssi_private->imx_pcm_pdev);
+				goto error_dev;
+			}
 		}
 	}
 
-- 
1.8.1.5



From mpa at pengutronix.de  Wed Apr 24 10:36:34 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Wed, 24 Apr 2013 16:36:34 +0200
Subject: [PATCH v5 05/10] ASoC: fsl-ssi: Use generic DMA bindings if possible
In-Reply-To: <1366814199-14827-1-git-send-email-mpa@pengutronix.de>
References: <1366814199-14827-1-git-send-email-mpa@pengutronix.de>
Message-ID: <1366814199-14827-6-git-send-email-mpa@pengutronix.de>

There may be some platforms using fsl-ssi that do not have a DMA driver
with generic DMA bindings. So this patch adds support for the generic
DMA bindings, while still using the old "fsl,dma-events" property if
"dmas" is not found.

Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
---

Notes:
    Changes in v5:
     - Not passing of_node now, instead setting the parent device
    
    Changes in v4:
     - Change TODO comment to a FIXME, to remove the old dma-events property as soon
       as all dma drivers support the generic DMA bindings.

 sound/soc/fsl/fsl_ssi.c | 24 ++++++++++++++----------
 1 file changed, 14 insertions(+), 10 deletions(-)

diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index 5165d41..405497b 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -796,15 +796,19 @@ static int fsl_ssi_probe(struct platform_device *pdev)
 			&ssi_private->filter_data_tx;
 		ssi_private->dma_params_rx.filter_data =
 			&ssi_private->filter_data_rx;
-		/*
-		 * TODO: This is a temporary solution and should be changed
-		 * to use generic DMA binding later when the helplers get in.
-		 */
-		ret = of_property_read_u32_array(pdev->dev.of_node,
+		if (!of_property_read_bool(pdev->dev.of_node, "dmas") &&
+				ssi_private->use_dma) {
+			/*
+			 * FIXME: This is a temporary solution until all
+			 * necessary dma drivers support the generic dma
+			 * bindings.
+			 */
+			ret = of_property_read_u32_array(pdev->dev.of_node,
 					"fsl,ssi-dma-events", dma_events, 2);
-		if (ret && !ssi_private->use_dma) {
-			dev_err(&pdev->dev, "could not get dma events\n");
-			goto error_clk;
+			if (ret && ssi_private->use_dma) {
+				dev_err(&pdev->dev, "could not get dma events but fsl-ssi is configured to use DMA\n");
+				goto error_clk;
+			}
 		}
 
 		shared = of_device_is_compatible(of_get_parent(np),
@@ -875,8 +879,8 @@ static int fsl_ssi_probe(struct platform_device *pdev)
 			}
 		} else {
 			ssi_private->imx_pcm_pdev =
-				platform_device_register_simple("imx-pcm-audio",
-							-1, NULL, 0);
+				platform_device_register_data(&pdev->dev,
+						"imx-pcm-audio", -1, NULL, 0);
 			if (IS_ERR(ssi_private->imx_pcm_pdev)) {
 				ret = PTR_ERR(ssi_private->imx_pcm_pdev);
 				goto error_dev;
-- 
1.8.1.5



From mpa at pengutronix.de  Wed Apr 24 10:36:29 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Wed, 24 Apr 2013 16:36:29 +0200
Subject: [PATCH v5 00/10] ASoC: fsl-ssi: ac97-slave support
Message-ID: <1366814199-14827-1-git-send-email-mpa@pengutronix.de>

Hi,

This series adds DT support for phycore-ac97. It is now based on the pcm dma
cleanups from Lars. Beside ac97 support, the series adds fsl-ssi imx-pcm-fiq
and generic DMA binding handling.

Regards,

Markus

Changes in v5:
 - Pass of_node via parent device to imx-pcm-dma.

Changes in v4:
 - phycore-ac97 uses the iomux functions based on audmux phandle now.
 - fsl-ssi imx-pcm-fiq got some new comments about problems with imx-ssi and
   incompatible codecs

Changes in v3:
 - Rebased onto pcm dma cleanup patches
 - A lot of cleanups for the fsl-ssi ac97 integration
 - Some small changes which are listed in the notes of the patches.

Markus Pargmann (10):
      ASoC: phycore-ac97: Add DT support
      ASoC: imx-pcm-dma: DT support
      ASoC: imx-pcm-fiq: Introduce pcm-fiq-params
      ASoC: fsl-ssi: Add support for imx-pcm-fiq
      ASoC: fsl-ssi: Use generic DMA bindings if possible
      ARM: imx: Export ac97 reset functions
      ASoC: fsl-ssi: imx ac97 support
      ASoC: fsl: Kconfig: Use fsl-ssi for phycore-ac97
      ASoC: fsl: Move fsl-ssi binding doc to sound/
      ASoC: fsl: Update fsl-ssi binding doc

 .../{powerpc/fsl/ssi.txt => sound/fsl,ssi.txt}     |  10 +
 .../bindings/sound/phytec,phycore-ac97.txt         |  14 +
 arch/arm/mach-imx/mach-pca100.c                    |   7 +-
 arch/arm/mach-imx/mach-pcm043.c                    |   7 +-
 sound/soc/fsl/Kconfig                              |   2 +-
 sound/soc/fsl/fsl_ssi.c                            | 510 +++++++++++++++++----
 sound/soc/fsl/imx-pcm-dma.c                        |   4 +-
 sound/soc/fsl/imx-pcm-fiq.c                        |  16 +-
 sound/soc/fsl/imx-pcm.h                            |   9 +
 sound/soc/fsl/imx-ssi.c                            |   7 +-
 sound/soc/fsl/imx-ssi.h                            |   1 +
 sound/soc/fsl/phycore-ac97.c                       | 166 ++++++-
 12 files changed, 631 insertions(+), 122 deletions(-)
 rename Documentation/devicetree/bindings/{powerpc/fsl/ssi.txt => sound/fsl,ssi.txt} (88%)
 create mode 100644 Documentation/devicetree/bindings/sound/phytec,phycore-ac97.txt



From mpa at pengutronix.de  Wed Apr 24 10:36:39 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Wed, 24 Apr 2013 16:36:39 +0200
Subject: [PATCH v5 10/10] ASoC: fsl: Update fsl-ssi binding doc
In-Reply-To: <1366814199-14827-1-git-send-email-mpa@pengutronix.de>
References: <1366814199-14827-1-git-send-email-mpa@pengutronix.de>
Message-ID: <1366814199-14827-11-git-send-email-mpa@pengutronix.de>

Update the fsl-ssi bindings. DMA is no required property anymore and
uses the generic DMA bindings. imx-fiq is a new alternative to DMA

Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
---

Notes:
    Changes in v4:
     - Add a comment about hardware bugs for imx-pcm-fiq
    
    Changes in v3:
     - In previous versions, I removed fsl,playback-dma and capture-dma. But they
       are still in use by fsl_dma.c, so I added them again.

 Documentation/devicetree/bindings/sound/fsl,ssi.txt | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/Documentation/devicetree/bindings/sound/fsl,ssi.txt b/Documentation/devicetree/bindings/sound/fsl,ssi.txt
index 5ff76c9..0375ee0 100644
--- a/Documentation/devicetree/bindings/sound/fsl,ssi.txt
+++ b/Documentation/devicetree/bindings/sound/fsl,ssi.txt
@@ -43,10 +43,20 @@ Required properties:
                     together.  This would still allow different sample sizes,
                     but not different sample rates.
 
+Note that either dmas, dma-names or fsl,imx-fiq are required.
+
 Optional properties:
 - codec-handle:     Phandle to a 'codec' node that defines an audio
                     codec connected to this SSI.  This node is typically
                     a child of an I2C or other control node.
+- dmas:		    Generic dma devicetree binding as described in
+		    Documentation/devicetree/bindings/dma/dma.txt.
+- dma-names:	    Two dmas have to be defined, "tx" and "rx", if fsl,imx-fiq
+		    is not defined.
+- fsl,imx-fiq:	    Bool property. Use imx-pcm-fiq instead of imx-pcm-dma.
+  		    Only necessary for some boards with incompatible
+		    codec. imx-pcm-fiq will manually filter some data from
+		    the codec. It is a workaround for a hardware bug.
 
 Child 'codec' node required properties:
 - compatible:       Compatible list, contains the name of the codec
-- 
1.8.1.5



From mpa at pengutronix.de  Wed Apr 24 10:36:36 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Wed, 24 Apr 2013 16:36:36 +0200
Subject: [PATCH v5 07/10] ASoC: fsl-ssi: imx ac97 support
In-Reply-To: <1366814199-14827-1-git-send-email-mpa@pengutronix.de>
References: <1366814199-14827-1-git-send-email-mpa@pengutronix.de>
Message-ID: <1366814199-14827-8-git-send-email-mpa@pengutronix.de>

This patch copies some parts from imx-ssi to support AC97 on
imx27-pca100 and imx27-pcm043. This is a implementation of the
ac97-slave mode.

For ac97, the registers have to be setup earlier than for other ssi
modes because there is some communication with the external device
before actual streaming. So this patch introduces a fsl_ssi_setup
function to setup the registers at different times.

This patch was tested with imx27-pca100.

Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
---

Notes:
    Changes in v3:
     - Cleanup ac97 code by adding a fsl_ssi_setup function for initial register
       setup. For ac97 the registers have to be setup earlier than in normal
       mode.

 sound/soc/fsl/fsl_ssi.c | 412 +++++++++++++++++++++++++++++++++++++++---------
 1 file changed, 340 insertions(+), 72 deletions(-)

diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index 405497b..755268e 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -141,6 +141,7 @@ struct fsl_ssi_private {
 
 	bool new_binding;
 	bool ssi_on_imx;
+	bool imx_ac97;
 	bool use_dma;
 	struct clk *clk;
 	struct platform_device *imx_pcm_pdev;
@@ -150,6 +151,9 @@ struct fsl_ssi_private {
 	struct imx_dma_data filter_data_rx;
 	struct imx_pcm_fiq_params fiq_params;
 
+	void (*ac97_reset) (struct snd_ac97 *ac97);
+	void (*ac97_warm_reset)(struct snd_ac97 *ac97);
+
 	struct {
 		unsigned int rfrc;
 		unsigned int tfrc;
@@ -321,6 +325,124 @@ static irqreturn_t fsl_ssi_isr(int irq, void *dev_id)
 	return ret;
 }
 
+static int fsl_ssi_setup(struct fsl_ssi_private *ssi_private)
+{
+	struct ccsr_ssi __iomem *ssi = ssi_private->ssi;
+	u8 i2s_mode;
+	u8 wm;
+	int synchronous = ssi_private->cpu_dai_drv.symmetric_rates;
+
+	if (ssi_private->imx_ac97)
+		i2s_mode = CCSR_SSI_SCR_I2S_MODE_NORMAL | CCSR_SSI_SCR_NET;
+	else
+		i2s_mode = CCSR_SSI_SCR_I2S_MODE_SLAVE;
+
+	/*
+	 * Section 16.5 of the MPC8610 reference manual says that the SSI needs
+	 * to be disabled before updating the registers we set here.
+	 */
+	write_ssi_mask(&ssi->scr, CCSR_SSI_SCR_SSIEN, 0);
+
+	/*
+	 * Program the SSI into I2S Slave Non-Network Synchronous mode. Also
+	 * enable the transmit and receive FIFO.
+	 *
+	 * FIXME: Little-endian samples require a different shift dir
+	 */
+	write_ssi_mask(&ssi->scr,
+		CCSR_SSI_SCR_I2S_MODE_MASK | CCSR_SSI_SCR_SYN,
+		CCSR_SSI_SCR_TFR_CLK_DIS |
+		i2s_mode |
+		(synchronous ? CCSR_SSI_SCR_SYN : 0));
+
+	write_ssi(CCSR_SSI_STCR_TXBIT0 | CCSR_SSI_STCR_TFEN0 |
+		 CCSR_SSI_STCR_TFSI | CCSR_SSI_STCR_TEFS |
+		 CCSR_SSI_STCR_TSCKP, &ssi->stcr);
+
+	write_ssi(CCSR_SSI_SRCR_RXBIT0 | CCSR_SSI_SRCR_RFEN0 |
+		 CCSR_SSI_SRCR_RFSI | CCSR_SSI_SRCR_REFS |
+		 CCSR_SSI_SRCR_RSCKP, &ssi->srcr);
+	/*
+	 * The DC and PM bits are only used if the SSI is the clock master.
+	 */
+
+	/*
+	 * Set the watermark for transmit FIFI 0 and receive FIFO 0. We don't
+	 * use FIFO 1. We program the transmit water to signal a DMA transfer
+	 * if there are only two (or fewer) elements left in the FIFO. Two
+	 * elements equals one frame (left channel, right channel). This value,
+	 * however, depends on the depth of the transmit buffer.
+	 *
+	 * We set the watermark on the same level as the DMA burstsize.  For
+	 * fiq it is probably better to use the biggest possible watermark
+	 * size.
+	 */
+	if (ssi_private->use_dma)
+		wm = ssi_private->fifo_depth - 2;
+	else
+		wm = ssi_private->fifo_depth;
+
+	write_ssi(CCSR_SSI_SFCSR_TFWM0(wm) | CCSR_SSI_SFCSR_RFWM0(wm) |
+		CCSR_SSI_SFCSR_TFWM1(wm) | CCSR_SSI_SFCSR_RFWM1(wm),
+		&ssi->sfcsr);
+
+	/*
+	 * For non-ac97 setups, we keep the SSI disabled because if we enable
+	 * it, then the DMA controller will start. It's not supposed to start
+	 * until the SCR.TE (or SCR.RE) bit is set, but it does anyway. The DMA
+	 * controller will transfer one "BWC" of data (i.e. the amount of data
+	 * that the MR.BWC bits are set to). The reason this is bad is because
+	 * at this point, the PCM driver has not finished initializing the DMA
+	 * controller.
+	 */
+
+
+	/*
+	 * For ac97 interrupts are enabled with the startup of the substream
+	 * because it is also running without an active substream. Normally SSI
+	 * is only enabled when there is a substream.
+	 */
+	if (!ssi_private->imx_ac97) {
+		/* Enable the interrupts and DMA requests */
+		if (ssi_private->use_dma)
+			write_ssi(SIER_FLAGS, &ssi->sier);
+		else
+			write_ssi(CCSR_SSI_SIER_TIE | CCSR_SSI_SIER_TFE0_EN |
+					CCSR_SSI_SIER_RIE |
+					CCSR_SSI_SIER_RFF0_EN, &ssi->sier);
+	} else {
+		/*
+		 * Setup the clock control register
+		 */
+		write_ssi(CCSR_SSI_SxCCR_WL(17) | CCSR_SSI_SxCCR_DC(13),
+				&ssi->stccr);
+		write_ssi(CCSR_SSI_SxCCR_WL(17) | CCSR_SSI_SxCCR_DC(13),
+				&ssi->srccr);
+
+		/*
+		 * Enable AC97 mode and startup the SSI
+		 */
+		write_ssi(CCSR_SSI_SACNT_AC97EN | CCSR_SSI_SACNT_FV,
+				&ssi->sacnt);
+		write_ssi(0xff, &ssi->saccdis);
+		write_ssi(0x300, &ssi->saccen);
+
+		/*
+		 * Enable SSI
+		 */
+		write_ssi_mask(&ssi->scr, 0, CCSR_SSI_SCR_SSIEN);
+		write_ssi(CCSR_SSI_SOR_WAIT(3), &ssi->sor);
+
+		/*
+		 * Enable Transmit and Receive
+		 */
+		write_ssi_mask(&ssi->scr, 0, CCSR_SSI_SCR_TE | CCSR_SSI_SCR_RE);
+	}
+
+	return 0;
+}
+
+
 /**
  * fsl_ssi_startup: create a new substream
  *
@@ -342,75 +464,14 @@ static int fsl_ssi_startup(struct snd_pcm_substream *substream,
 	 * and initialize the SSI registers.
 	 */
 	if (!ssi_private->first_stream) {
-		struct ccsr_ssi __iomem *ssi = ssi_private->ssi;
-
 		ssi_private->first_stream = substream;
 
 		/*
-		 * Section 16.5 of the MPC8610 reference manual says that the
-		 * SSI needs to be disabled before updating the registers we set
-		 * here.
-		 */
-		write_ssi_mask(&ssi->scr, CCSR_SSI_SCR_SSIEN, 0);
-
-		/*
-		 * Program the SSI into I2S Slave Non-Network Synchronous mode.
-		 * Also enable the transmit and receive FIFO.
-		 *
-		 * FIXME: Little-endian samples require a different shift dir
-		 */
-		write_ssi_mask(&ssi->scr,
-			CCSR_SSI_SCR_I2S_MODE_MASK | CCSR_SSI_SCR_SYN,
-			CCSR_SSI_SCR_TFR_CLK_DIS | CCSR_SSI_SCR_I2S_MODE_SLAVE
-			| (synchronous ? CCSR_SSI_SCR_SYN : 0));
-
-		write_ssi(CCSR_SSI_STCR_TXBIT0 | CCSR_SSI_STCR_TFEN0 |
-			 CCSR_SSI_STCR_TFSI | CCSR_SSI_STCR_TEFS |
-			 CCSR_SSI_STCR_TSCKP, &ssi->stcr);
-
-		write_ssi(CCSR_SSI_SRCR_RXBIT0 | CCSR_SSI_SRCR_RFEN0 |
-			 CCSR_SSI_SRCR_RFSI | CCSR_SSI_SRCR_REFS |
-			 CCSR_SSI_SRCR_RSCKP, &ssi->srcr);
-
-		/*
-		 * The DC and PM bits are only used if the SSI is the clock
-		 * master.
-		 */
-
-		/* Enable the interrupts and DMA requests */
-		if (ssi_private->use_dma)
-			write_ssi(SIER_FLAGS, &ssi->sier);
-		else
-			write_ssi(CCSR_SSI_SIER_TIE | CCSR_SSI_SIER_TFE0_EN |
-					CCSR_SSI_SIER_RIE |
-					CCSR_SSI_SIER_RFF0_EN, &ssi->sier);
-
-		/*
-		 * Set the watermark for transmit FIFI 0 and receive FIFO 0. We
-		 * don't use FIFO 1.  We program the transmit water to signal a
-		 * DMA transfer if there are only two (or fewer) elements left
-		 * in the FIFO.  Two elements equals one frame (left channel,
-		 * right channel).  This value, however, depends on the depth of
-		 * the transmit buffer.
-		 *
-		 * We program the receive FIFO to notify us if at least two
-		 * elements (one frame) have been written to the FIFO.  We could
-		 * make this value larger (and maybe we should), but this way
-		 * data will be written to memory as soon as it's available.
-		 */
-		write_ssi(CCSR_SSI_SFCSR_TFWM0(ssi_private->fifo_depth - 2) |
-			CCSR_SSI_SFCSR_RFWM0(ssi_private->fifo_depth - 2),
-			&ssi->sfcsr);
-
-		/*
-		 * We keep the SSI disabled because if we enable it, then the
-		 * DMA controller will start.  It's not supposed to start until
-		 * the SCR.TE (or SCR.RE) bit is set, but it does anyway.  The
-		 * DMA controller will transfer one "BWC" of data (i.e. the
-		 * amount of data that the MR.BWC bits are set to).  The reason
-		 * this is bad is because at this point, the PCM driver has not
-		 * finished initializing the DMA controller.
+		 * fsl_ssi_setup was already called by ac97_init earlier if
+		 * the driver is in ac97 mode.
 		 */
+		if (!ssi_private->imx_ac97)
+			fsl_ssi_setup(ssi_private);
 	} else {
 		if (synchronous) {
 			struct snd_pcm_runtime *first_runtime =
@@ -565,8 +626,9 @@ static void fsl_ssi_shutdown(struct snd_pcm_substream *substream,
 
 	/*
 	 * If this is the last active substream, disable the SSI.
+	 * If AC97 is active, we don't want to disable SSI.
 	 */
-	if (!ssi_private->first_stream) {
+	if (!ssi_private->first_stream && !ssi_private->imx_ac97) {
 		struct ccsr_ssi __iomem *ssi = ssi_private->ssi;
 
 		write_ssi_mask(&ssi->scr, CCSR_SSI_SCR_SSIEN, 0);
@@ -615,6 +677,176 @@ static const struct snd_soc_component_driver fsl_ssi_component = {
 	.name		= "fsl-ssi",
 };
 
+/**
+ * fsl_ssi_ac97_trigger: start and stop the AC97 receive/transmit.
+ *
+ * This function is called by ALSA to start, stop, pause, and resume the
+ * transfer of data.
+ */
+static int fsl_ssi_ac97_trigger(struct snd_pcm_substream *substream, int cmd,
+			   struct snd_soc_dai *dai)
+{
+	struct snd_soc_pcm_runtime *rtd = substream->private_data;
+	struct fsl_ssi_private *ssi_private = snd_soc_dai_get_drvdata(rtd->cpu_dai);
+	struct ccsr_ssi __iomem *ssi = ssi_private->ssi;
+
+	switch (cmd) {
+	case SNDRV_PCM_TRIGGER_START:
+	case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
+		if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
+			write_ssi_mask(&ssi->sier, 0, CCSR_SSI_SIER_TIE |
+					CCSR_SSI_SIER_TFE0_EN);
+		else
+			write_ssi_mask(&ssi->sier, 0, CCSR_SSI_SIER_RIE |
+					CCSR_SSI_SIER_RFF0_EN);
+		break;
+
+	case SNDRV_PCM_TRIGGER_STOP:
+	case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
+		if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
+			write_ssi_mask(&ssi->sier, CCSR_SSI_SIER_TIE |
+					CCSR_SSI_SIER_TFE0_EN, 0);
+		else
+			write_ssi_mask(&ssi->sier, CCSR_SSI_SIER_RIE |
+					CCSR_SSI_SIER_RFF0_EN, 0);
+		break;
+
+	default:
+		return -EINVAL;
+	}
+
+	if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
+		write_ssi(CCSR_SSI_SOR_TX_CLR, &ssi->sor);
+	else
+		write_ssi(CCSR_SSI_SOR_RX_CLR, &ssi->sor);
+
+	return 0;
+}
+
+static const struct snd_soc_dai_ops fsl_ssi_ac97_dai_ops = {
+	.startup	= fsl_ssi_startup,
+	.shutdown	= fsl_ssi_shutdown,
+	.trigger	= fsl_ssi_ac97_trigger,
+};
+
+static struct snd_soc_dai_driver fsl_ssi_ac97_dai = {
+	.ac97_control = 1,
+	.playback = {
+		.stream_name = "AC97 Playback",
+		.channels_min = 2,
+		.channels_max = 2,
+		.rates = SNDRV_PCM_RATE_8000_48000,
+		.formats = SNDRV_PCM_FMTBIT_S16_LE,
+	},
+	.capture = {
+		.stream_name = "AC97 Capture",
+		.channels_min = 2,
+		.channels_max = 2,
+		.rates = SNDRV_PCM_RATE_48000,
+		.formats = SNDRV_PCM_FMTBIT_S16_LE,
+	},
+	.ops = &fsl_ssi_ac97_dai_ops,
+};
+
+
+static struct fsl_ssi_private *fsl_ac97_data;
+
+static void fsl_ssi_ac97_init(void)
+{
+	fsl_ssi_setup(fsl_ac97_data);
+}
+
+static void fsl_ssi_ac97_write(struct snd_ac97 *ac97, unsigned short reg,
+		unsigned short val)
+{
+	struct ccsr_ssi *ssi = fsl_ac97_data->ssi;
+	unsigned int lreg;
+	unsigned int lval;
+
+	if (reg > 0x7f)
+		return;
+
+
+	lreg = reg <<  12;
+	write_ssi(lreg, &ssi->sacadd);
+
+	lval = val << 4;
+	write_ssi(lval , &ssi->sacdat);
+
+	write_ssi_mask(&ssi->sacnt, CCSR_SSI_SACNT_RDWR_MASK,
+			CCSR_SSI_SACNT_WR);
+	udelay(100);
+}
+
+static unsigned short fsl_ssi_ac97_read(struct snd_ac97 *ac97,
+		unsigned short reg)
+{
+	struct ccsr_ssi *ssi = fsl_ac97_data->ssi;
+
+	unsigned short val = -1;
+	unsigned int lreg;
+
+	lreg = (reg & 0x7f) <<  12 ;
+	write_ssi(lreg, &ssi->sacadd);
+	write_ssi_mask(&ssi->sacnt, CCSR_SSI_SACNT_RDWR_MASK,
+			CCSR_SSI_SACNT_RD);
+
+	udelay(100);
+
+	val = (read_ssi(&ssi->sacdat) >> 4) & 0xffff;
+
+	return val;
+}
+
+static void fsl_ssi_ac97_reset(struct snd_ac97 *ac97)
+{
+	struct fsl_ssi_private *ssi_private = fsl_ac97_data;
+
+	if (ssi_private->ac97_reset)
+		ssi_private->ac97_reset(ac97);
+	/* First read sometimes fails, do a dummy read */
+	fsl_ssi_ac97_read(ac97, 0);
+}
+
+static void fsl_ssi_ac97_warm_reset(struct snd_ac97 *ac97)
+{
+	struct fsl_ssi_private *ssi_private = fsl_ac97_data;
+
+	if (ssi_private->ac97_warm_reset)
+		ssi_private->ac97_warm_reset(ac97);
+
+	/* First read sometimes fails, do a dummy read */
+	fsl_ssi_ac97_read(ac97, 0);
+}
+
+struct snd_ac97_bus_ops soc_ac97_ops = {
+	.read		= fsl_ssi_ac97_read,
+	.write		= fsl_ssi_ac97_write,
+	.reset		= fsl_ssi_ac97_reset,
+	.warm_reset	= fsl_ssi_ac97_warm_reset
+};
+EXPORT_SYMBOL_GPL(soc_ac97_ops);
+
+/*
+ * Pointer to AC97 reset functions for specific boards
+ */
+#if IS_ENABLED(CONFIG_MACH_PCA100)
+extern void pca100_ac97_cold_reset(struct snd_ac97 *ac97);
+extern void pca100_ac97_warm_reset(struct snd_ac97 *ac97);
+#else
+void pca100_ac97_cold_reset(struct snd_ac97 *ac97) { }
+void pca100_ac97_warm_reset(struct snd_ac97 *ac97) { }
+#endif
+
+#if IS_ENABLED(CONFIG_MACH_PCM043)
+extern void pcm043_ac97_cold_reset(struct snd_ac97 *ac97);
+extern void pcm043_ac97_warm_reset(struct snd_ac97 *ac97);
+#else
+void pcm043_ac97_cold_reset(struct snd_ac97 *ac97) { }
+void pcm043_ac97_warm_reset(struct snd_ac97 *ac97) { }
+#endif
+
+
 /* Show the statistics of a flag only if its interrupt is enabled.  The
  * compiler will optimze this code to a no-op if the interrupt is not
  * enabled.
@@ -691,6 +923,7 @@ static int fsl_ssi_probe(struct platform_device *pdev)
 	struct resource res;
 	char name[64];
 	bool shared;
+	bool ac97 = false;
 
 	/* SSIs that are not connected on the board should have a
 	 *      status = "disabled"
@@ -701,7 +934,13 @@ static int fsl_ssi_probe(struct platform_device *pdev)
 
 	/* We only support the SSI in "I2S Slave" mode */
 	sprop = of_get_property(np, "fsl,mode", NULL);
-	if (!sprop || strcmp(sprop, "i2s-slave")) {
+	if (!sprop) {
+		dev_err(&pdev->dev, "fsl,mode property is necessary\n");
+		return -EINVAL;
+	}
+	if (!strcmp(sprop, "ac97-slave")) {
+		ac97 = true;
+	} else if (strcmp(sprop, "i2s-slave")) {
 		dev_notice(&pdev->dev, "mode %s is unsupported\n", sprop);
 		return -ENODEV;
 	}
@@ -717,13 +956,39 @@ static int fsl_ssi_probe(struct platform_device *pdev)
 
 	strcpy(ssi_private->name, p);
 
-	/* Initialize this copy of the CPU DAI driver structure */
-	memcpy(&ssi_private->cpu_dai_drv, &fsl_ssi_dai_template,
-	       sizeof(fsl_ssi_dai_template));
-	ssi_private->cpu_dai_drv.name = ssi_private->name;
-
 	ssi_private->use_dma = !of_property_read_bool(np, "fsl,imx-fiq");
 
+	if (ac97) {
+		sprop = of_get_property(of_find_node_by_path("/"), "compatible",
+				NULL);
+		p = strrchr(sprop, ',');
+		if (p)
+			sprop = p + 1;
+
+		if (!strcmp(sprop, "imx27-pca100")) {
+			ssi_private->ac97_reset = pca100_ac97_cold_reset;
+			ssi_private->ac97_warm_reset = pca100_ac97_warm_reset;
+		} else if (!strcmp(sprop, "imx27-pcm043")) {
+			ssi_private->ac97_reset = pcm043_ac97_cold_reset;
+			ssi_private->ac97_warm_reset = pcm043_ac97_warm_reset;
+		} else {
+			dev_err(&pdev->dev, "Failed to enable ssi AC97 mode, unknown board.\n");
+			ret = -EINVAL;
+			goto error_kmalloc;
+		}
+
+		memcpy(&ssi_private->cpu_dai_drv, &fsl_ssi_ac97_dai,
+				sizeof(fsl_ssi_ac97_dai));
+
+		fsl_ac97_data = ssi_private;
+		ssi_private->imx_ac97 = true;
+	} else {
+		/* Initialize this copy of the CPU DAI driver structure */
+		memcpy(&ssi_private->cpu_dai_drv, &fsl_ssi_dai_template,
+		       sizeof(fsl_ssi_dai_template));
+	}
+	ssi_private->cpu_dai_drv.name = ssi_private->name;
+
 	/* Get the addresses and IRQ */
 	ret = of_address_to_resource(np, 0, &res);
 	if (ret) {
@@ -920,6 +1185,9 @@ static int fsl_ssi_probe(struct platform_device *pdev)
 	}
 
 done:
+	if (ssi_private->imx_ac97)
+		fsl_ssi_ac97_init();
+
 	return 0;
 
 error_dai:
-- 
1.8.1.5



From mpa at pengutronix.de  Wed Apr 24 10:36:35 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Wed, 24 Apr 2013 16:36:35 +0200
Subject: [PATCH v5 06/10] ARM: imx: Export ac97 reset functions
In-Reply-To: <1366814199-14827-1-git-send-email-mpa@pengutronix.de>
References: <1366814199-14827-1-git-send-email-mpa@pengutronix.de>
Message-ID: <1366814199-14827-7-git-send-email-mpa@pengutronix.de>

Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
---
 arch/arm/mach-imx/mach-pca100.c | 7 +++++--
 arch/arm/mach-imx/mach-pcm043.c | 7 +++++--
 2 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-imx/mach-pca100.c b/arch/arm/mach-imx/mach-pca100.c
index b8b15bb..68badf8 100644
--- a/arch/arm/mach-imx/mach-pca100.c
+++ b/arch/arm/mach-imx/mach-pca100.c
@@ -22,6 +22,7 @@
 #include <linux/i2c.h>
 #include <linux/i2c/at24.h>
 #include <linux/dma-mapping.h>
+#include <linux/export.h>
 #include <linux/spi/spi.h>
 #include <linux/spi/eeprom.h>
 #include <linux/irq.h>
@@ -208,7 +209,7 @@ static const struct spi_imx_master pca100_spi0_data __initconst = {
 	.num_chipselect = ARRAY_SIZE(pca100_spi_cs),
 };
 
-static void pca100_ac97_warm_reset(struct snd_ac97 *ac97)
+void pca100_ac97_warm_reset(struct snd_ac97 *ac97)
 {
 	mxc_gpio_mode(GPIO_PORTC | 20 | GPIO_GPIO | GPIO_OUT);
 	gpio_set_value(GPIO_PORTC + 20, 1);
@@ -217,8 +218,9 @@ static void pca100_ac97_warm_reset(struct snd_ac97 *ac97)
 	mxc_gpio_mode(PC20_PF_SSI1_FS);
 	msleep(2);
 }
+EXPORT_SYMBOL(pca100_ac97_warm_reset);
 
-static void pca100_ac97_cold_reset(struct snd_ac97 *ac97)
+void pca100_ac97_cold_reset(struct snd_ac97 *ac97)
 {
 	mxc_gpio_mode(GPIO_PORTC | 20 | GPIO_GPIO | GPIO_OUT);  /* FS */
 	gpio_set_value(GPIO_PORTC + 20, 0);
@@ -232,6 +234,7 @@ static void pca100_ac97_cold_reset(struct snd_ac97 *ac97)
 	mxc_gpio_mode(PC22_PF_SSI1_TXD);
 	msleep(2);
 }
+EXPORT_SYMBOL(pca100_ac97_cold_reset);
 
 static const struct imx_ssi_platform_data pca100_ssi_pdata __initconst = {
 	.ac97_reset		= pca100_ac97_cold_reset,
diff --git a/arch/arm/mach-imx/mach-pcm043.c b/arch/arm/mach-imx/mach-pcm043.c
index 8ed533f..4f318ca 100644
--- a/arch/arm/mach-imx/mach-pcm043.c
+++ b/arch/arm/mach-imx/mach-pcm043.c
@@ -27,6 +27,7 @@
 #include <linux/i2c/at24.h>
 #include <linux/usb/otg.h>
 #include <linux/usb/ulpi.h>
+#include <linux/export.h>
 
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
@@ -217,7 +218,7 @@ static iomux_v3_cfg_t pcm043_pads[] = {
 #define SD1_GPIO_WP	IMX_GPIO_NR(2, 23)
 #define SD1_GPIO_CD	IMX_GPIO_NR(2, 24)
 
-static void pcm043_ac97_warm_reset(struct snd_ac97 *ac97)
+void pcm043_ac97_warm_reset(struct snd_ac97 *ac97)
 {
 	iomux_v3_cfg_t txfs_gpio = MX35_PAD_STXFS4__GPIO2_31;
 	iomux_v3_cfg_t txfs = MX35_PAD_STXFS4__AUDMUX_AUD4_TXFS;
@@ -239,8 +240,9 @@ static void pcm043_ac97_warm_reset(struct snd_ac97 *ac97)
 	gpio_free(AC97_GPIO_TXFS);
 	mxc_iomux_v3_setup_pad(txfs);
 }
+EXPORT_SYMBOL(pcm043_ac97_warm_reset);
 
-static void pcm043_ac97_cold_reset(struct snd_ac97 *ac97)
+void pcm043_ac97_cold_reset(struct snd_ac97 *ac97)
 {
 	iomux_v3_cfg_t txfs_gpio = MX35_PAD_STXFS4__GPIO2_31;
 	iomux_v3_cfg_t txfs = MX35_PAD_STXFS4__AUDMUX_AUD4_TXFS;
@@ -286,6 +288,7 @@ err1:
 		printk("%s failed with %d\n", __func__, ret);
 	mdelay(1);
 }
+EXPORT_SYMBOL(pcm043_ac97_cold_reset);
 
 static const struct imx_ssi_platform_data pcm043_ssi_pdata __initconst = {
 	.ac97_reset = pcm043_ac97_cold_reset,
-- 
1.8.1.5



From mpa at pengutronix.de  Wed Apr 24 10:36:38 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Wed, 24 Apr 2013 16:36:38 +0200
Subject: [PATCH v5 09/10] ASoC: fsl: Move fsl-ssi binding doc to sound/
In-Reply-To: <1366814199-14827-1-git-send-email-mpa@pengutronix.de>
References: <1366814199-14827-1-git-send-email-mpa@pengutronix.de>
Message-ID: <1366814199-14827-10-git-send-email-mpa@pengutronix.de>

fsl-ssi was located in powerpc/fsl/ssi.txt. This is no powerpc specific
device, so it should be moved to sound/ as it connects to differen audio
codecs.

Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
---
 .../devicetree/bindings/powerpc/fsl/ssi.txt        | 73 ----------------------
 .../devicetree/bindings/sound/fsl,ssi.txt          | 73 ++++++++++++++++++++++
 2 files changed, 73 insertions(+), 73 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/powerpc/fsl/ssi.txt
 create mode 100644 Documentation/devicetree/bindings/sound/fsl,ssi.txt

diff --git a/Documentation/devicetree/bindings/powerpc/fsl/ssi.txt b/Documentation/devicetree/bindings/powerpc/fsl/ssi.txt
deleted file mode 100644
index 5ff76c9..0000000
--- a/Documentation/devicetree/bindings/powerpc/fsl/ssi.txt
+++ /dev/null
@@ -1,73 +0,0 @@
-Freescale Synchronous Serial Interface
-
-The SSI is a serial device that communicates with audio codecs.  It can
-be programmed in AC97, I2S, left-justified, or right-justified modes.
-
-Required properties:
-- compatible:       Compatible list, contains "fsl,ssi".
-- cell-index:       The SSI, <0> = SSI1, <1> = SSI2, and so on.
-- reg:              Offset and length of the register set for the device.
-- 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.  This should be
-                    encoded based on the information in section 2)
-                    depending on the type of interrupt controller you
-                    have.
-- interrupt-parent: The phandle for the interrupt controller that
-                    services interrupts for this device.
-- fsl,mode:         The operating mode for the SSI interface.
-                    "i2s-slave" - I2S mode, SSI is clock slave
-                    "i2s-master" - I2S mode, SSI is clock master
-                    "lj-slave" - left-justified mode, SSI is clock slave
-                    "lj-master" - l.j. mode, SSI is clock master
-                    "rj-slave" - right-justified mode, SSI is clock slave
-                    "rj-master" - r.j., SSI is clock master
-                    "ac97-slave" - AC97 mode, SSI is clock slave
-                    "ac97-master" - AC97 mode, SSI is clock master
-- fsl,playback-dma: Phandle to a node for the DMA channel to use for
-                    playback of audio.  This is typically dictated by SOC
-                    design.  See the notes below.
-- fsl,capture-dma:  Phandle to a node for the DMA channel to use for
-                    capture (recording) of audio.  This is typically dictated
-                    by SOC design.  See the notes below.
-- fsl,fifo-depth:   The number of elements in the transmit and receive FIFOs.
-                    This number is the maximum allowed value for SFCSR[TFWM0].
-- fsl,ssi-asynchronous:
-                    If specified, the SSI is to be programmed in asynchronous
-                    mode.  In this mode, pins SRCK, STCK, SRFS, and STFS must
-                    all be connected to valid signals.  In synchronous mode,
-                    SRCK and SRFS are ignored.  Asynchronous mode allows
-                    playback and capture to use different sample sizes and
-                    sample rates.  Some drivers may require that SRCK and STCK
-                    be connected together, and SRFS and STFS be connected
-                    together.  This would still allow different sample sizes,
-                    but not different sample rates.
-
-Optional properties:
-- codec-handle:     Phandle to a 'codec' node that defines an audio
-                    codec connected to this SSI.  This node is typically
-                    a child of an I2C or other control node.
-
-Child 'codec' node required properties:
-- compatible:       Compatible list, contains the name of the codec
-
-Child 'codec' node optional properties:
-- clock-frequency:  The frequency of the input clock, which typically comes
-                    from an on-board dedicated oscillator.
-
-Notes on fsl,playback-dma and fsl,capture-dma:
-
-On SOCs that have an SSI, specific DMA channels are hard-wired for playback
-and capture.  On the MPC8610, for example, SSI1 must use DMA channel 0 for
-playback and DMA channel 1 for capture.  SSI2 must use DMA channel 2 for
-playback and DMA channel 3 for capture.  The developer can choose which
-DMA controller to use, but the channels themselves are hard-wired.  The
-purpose of these two properties is to represent this hardware design.
-
-The device tree nodes for the DMA channels that are referenced by
-"fsl,playback-dma" and "fsl,capture-dma" must be marked as compatible with
-"fsl,ssi-dma-channel".  The SOC-specific compatible string (e.g.
-"fsl,mpc8610-dma-channel") can remain.  If these nodes are left as
-"fsl,elo-dma-channel" or "fsl,eloplus-dma-channel", then the generic Elo DMA
-drivers (fsldma) will attempt to use them, and it will conflict with the
-sound drivers.
diff --git a/Documentation/devicetree/bindings/sound/fsl,ssi.txt b/Documentation/devicetree/bindings/sound/fsl,ssi.txt
new file mode 100644
index 0000000..5ff76c9
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/fsl,ssi.txt
@@ -0,0 +1,73 @@
+Freescale Synchronous Serial Interface
+
+The SSI is a serial device that communicates with audio codecs.  It can
+be programmed in AC97, I2S, left-justified, or right-justified modes.
+
+Required properties:
+- compatible:       Compatible list, contains "fsl,ssi".
+- cell-index:       The SSI, <0> = SSI1, <1> = SSI2, and so on.
+- reg:              Offset and length of the register set for the device.
+- 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.  This should be
+                    encoded based on the information in section 2)
+                    depending on the type of interrupt controller you
+                    have.
+- interrupt-parent: The phandle for the interrupt controller that
+                    services interrupts for this device.
+- fsl,mode:         The operating mode for the SSI interface.
+                    "i2s-slave" - I2S mode, SSI is clock slave
+                    "i2s-master" - I2S mode, SSI is clock master
+                    "lj-slave" - left-justified mode, SSI is clock slave
+                    "lj-master" - l.j. mode, SSI is clock master
+                    "rj-slave" - right-justified mode, SSI is clock slave
+                    "rj-master" - r.j., SSI is clock master
+                    "ac97-slave" - AC97 mode, SSI is clock slave
+                    "ac97-master" - AC97 mode, SSI is clock master
+- fsl,playback-dma: Phandle to a node for the DMA channel to use for
+                    playback of audio.  This is typically dictated by SOC
+                    design.  See the notes below.
+- fsl,capture-dma:  Phandle to a node for the DMA channel to use for
+                    capture (recording) of audio.  This is typically dictated
+                    by SOC design.  See the notes below.
+- fsl,fifo-depth:   The number of elements in the transmit and receive FIFOs.
+                    This number is the maximum allowed value for SFCSR[TFWM0].
+- fsl,ssi-asynchronous:
+                    If specified, the SSI is to be programmed in asynchronous
+                    mode.  In this mode, pins SRCK, STCK, SRFS, and STFS must
+                    all be connected to valid signals.  In synchronous mode,
+                    SRCK and SRFS are ignored.  Asynchronous mode allows
+                    playback and capture to use different sample sizes and
+                    sample rates.  Some drivers may require that SRCK and STCK
+                    be connected together, and SRFS and STFS be connected
+                    together.  This would still allow different sample sizes,
+                    but not different sample rates.
+
+Optional properties:
+- codec-handle:     Phandle to a 'codec' node that defines an audio
+                    codec connected to this SSI.  This node is typically
+                    a child of an I2C or other control node.
+
+Child 'codec' node required properties:
+- compatible:       Compatible list, contains the name of the codec
+
+Child 'codec' node optional properties:
+- clock-frequency:  The frequency of the input clock, which typically comes
+                    from an on-board dedicated oscillator.
+
+Notes on fsl,playback-dma and fsl,capture-dma:
+
+On SOCs that have an SSI, specific DMA channels are hard-wired for playback
+and capture.  On the MPC8610, for example, SSI1 must use DMA channel 0 for
+playback and DMA channel 1 for capture.  SSI2 must use DMA channel 2 for
+playback and DMA channel 3 for capture.  The developer can choose which
+DMA controller to use, but the channels themselves are hard-wired.  The
+purpose of these two properties is to represent this hardware design.
+
+The device tree nodes for the DMA channels that are referenced by
+"fsl,playback-dma" and "fsl,capture-dma" must be marked as compatible with
+"fsl,ssi-dma-channel".  The SOC-specific compatible string (e.g.
+"fsl,mpc8610-dma-channel") can remain.  If these nodes are left as
+"fsl,elo-dma-channel" or "fsl,eloplus-dma-channel", then the generic Elo DMA
+drivers (fsldma) will attempt to use them, and it will conflict with the
+sound drivers.
-- 
1.8.1.5



From mpa at pengutronix.de  Wed Apr 24 10:36:31 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Wed, 24 Apr 2013 16:36:31 +0200
Subject: [PATCH v5 02/10] ASoC: imx-pcm-dma: DT support
In-Reply-To: <1366814199-14827-1-git-send-email-mpa@pengutronix.de>
References: <1366814199-14827-1-git-send-email-mpa@pengutronix.de>
Message-ID: <1366814199-14827-3-git-send-email-mpa@pengutronix.de>

This patch adds the possibility to pass a of_node as platform_data which
is used by generic-pcm-dma to request a DMA slave channel.

Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
---

Notes:
    Changes in v5:
     - Use dev.parent pointer to get the of_node.

 sound/soc/fsl/imx-pcm-dma.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/sound/soc/fsl/imx-pcm-dma.c b/sound/soc/fsl/imx-pcm-dma.c
index c246fb5..f9577e1 100644
--- a/sound/soc/fsl/imx-pcm-dma.c
+++ b/sound/soc/fsl/imx-pcm-dma.c
@@ -62,9 +62,11 @@ static const struct snd_dmaengine_pcm_config imx_dmaengine_pcm_config = {
 
 int imx_pcm_dma_init(struct platform_device *pdev)
 {
+	if (pdev->dev.parent)
+		pdev->dev.of_node = pdev->dev.parent->of_node;
+
 	return snd_dmaengine_pcm_register(&pdev->dev, &imx_dmaengine_pcm_config,
 		SND_DMAENGINE_PCM_FLAG_NO_RESIDUE |
-		SND_DMAENGINE_PCM_FLAG_NO_DT |
 		SND_DMAENGINE_PCM_FLAG_COMPAT);
 }
 
-- 
1.8.1.5



From mpa at pengutronix.de  Wed Apr 24 10:36:30 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Wed, 24 Apr 2013 16:36:30 +0200
Subject: [PATCH v5 01/10] ASoC: phycore-ac97: Add DT support
In-Reply-To: <1366814199-14827-1-git-send-email-mpa@pengutronix.de>
References: <1366814199-14827-1-git-send-email-mpa@pengutronix.de>
Message-ID: <1366814199-14827-2-git-send-email-mpa@pengutronix.de>

Add devicetree support for this audio soc fabric driver.

DT initialized drivers do not have real device ids, so
imx-pcm-fiq-audio.0 is used without '.0'.

This patch also simplifies the way audmux ports are configured. Before
there was knowledge about the used board. As the audmux driver knows the
used board, we know use the returned errorcodes to correctly set the
audmux port. So this driver does not have to know which board it is
running on.

Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
---

Notes:
    Changes in v4:
     - New property phytec,audmux to check which audmux setup should be
       executed. Checking for fsl,imx21-audmux and fsl,imx31-audmux.
    
    Changes in v3:
     - Add some more information in the commit message.
    
    Changes in v2:
     - Simplify the driver, by combining audmux port configurations. The
       audmux driver actually knows on which platform he is running and
       will return the appropriate error code if we use functions for
       another platform. So we don't need to have the knowledge about it
       in phycore-ac97 and can try both functions. This removes the need
       of different compatibilities and renames it to phycore-ac97.
     - Use a phandle for the cpu_dai link.
     - Add devicetree binding documentation.
     - Rename binding to phytec,phycore-ac97 and fsl,ssi to phytec,ssi
    
    Changes in v2:
     - Simplify the driver, by combining audmux port configurations. The
       audmux driver actually knows on which platform he is running and
       will return the appropriate error code if we use functions for
       another platform. So we don't need to have the knowledge about it
       in phycore-ac97 and can try both functions. This removes the need
       of different compatibilities and renames it to imx27-ac97.
     - Use a phandle for the cpu_dai link.
     - Add devicetree binding documentation.
     - Rename binding to phytec,phycore-ac97 and fsl,ssi to phytec,ssi

 .../bindings/sound/phytec,phycore-ac97.txt         |  14 ++
 sound/soc/fsl/phycore-ac97.c                       | 166 ++++++++++++++++++---
 2 files changed, 158 insertions(+), 22 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/sound/phytec,phycore-ac97.txt

diff --git a/Documentation/devicetree/bindings/sound/phytec,phycore-ac97.txt b/Documentation/devicetree/bindings/sound/phytec,phycore-ac97.txt
new file mode 100644
index 0000000..41201ff
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/phytec,phycore-ac97.txt
@@ -0,0 +1,14 @@
+Phytec phycore AC97
+
+Required properties:
+- compatible: "phytec,phycore-ac97"
+- phytec,ssi: A phandle to the ssi device that is connected to ac97.
+- phytec,audmux: A phandle to the audmux device.
+
+Example:
+
+sound {
+	compatible = "phytec,phycore-ac97";
+	phytec,ssi = <&ssi1>;
+	phytec,audmux = <&audmux>;
+};
diff --git a/sound/soc/fsl/phycore-ac97.c b/sound/soc/fsl/phycore-ac97.c
index f8da6dd..d9f3ac7 100644
--- a/sound/soc/fsl/phycore-ac97.c
+++ b/sound/soc/fsl/phycore-ac97.c
@@ -21,7 +21,10 @@
 
 #include "imx-audmux.h"
 
+#define DRV_NAME "phycore-audio-fabric"
+
 static struct snd_soc_card imx_phycore;
+static struct device_node *phycore_dai_cpu_node;
 
 static struct snd_soc_ops imx_phycore_hifi_ops = {
 };
@@ -32,8 +35,12 @@ static struct snd_soc_dai_link imx_phycore_dai_ac97[] = {
 		.stream_name	= "HiFi",
 		.codec_dai_name		= "wm9712-hifi",
 		.codec_name	= "wm9712-codec",
+#ifdef CONFIG_MACH_IMX27_DT
+		.platform_name	= "imx-fiq-pcm-audio",
+#else
 		.cpu_dai_name	= "imx-ssi.0",
 		.platform_name	= "imx-fiq-pcm-audio.0",
+#endif
 		.ops		= &imx_phycore_hifi_ops,
 	},
 };
@@ -45,35 +52,48 @@ static struct snd_soc_card imx_phycore = {
 	.num_links	= ARRAY_SIZE(imx_phycore_dai_ac97),
 };
 
-static struct platform_device *imx_phycore_snd_ac97_device;
+static void phycore_ac97_imx21_audmux(void)
+{
+	imx_audmux_v1_configure_port(MX27_AUDMUX_HPCR1_SSI0,
+		IMX_AUDMUX_V1_PCR_SYN | /* 4wire mode */
+		IMX_AUDMUX_V1_PCR_TFCSEL(3) |
+		IMX_AUDMUX_V1_PCR_TCLKDIR | /* clock is output */
+		IMX_AUDMUX_V1_PCR_RXDSEL(3));
+	imx_audmux_v1_configure_port(3,
+		IMX_AUDMUX_V1_PCR_SYN | /* 4wire mode */
+		IMX_AUDMUX_V1_PCR_TFCSEL(0) |
+		IMX_AUDMUX_V1_PCR_TFSDIR |
+		IMX_AUDMUX_V1_PCR_RXDSEL(0));
+}
+
+static void phycore_ac97_imx31_audmux(void)
+{
+	imx_audmux_v2_configure_port(3,
+		IMX_AUDMUX_V2_PTCR_SYN | /* 4wire mode */
+		IMX_AUDMUX_V2_PTCR_TFSEL(0) |
+		IMX_AUDMUX_V2_PTCR_TFSDIR,
+		IMX_AUDMUX_V2_PDCR_RXDSEL(0));
+	imx_audmux_v2_configure_port(0,
+		IMX_AUDMUX_V2_PTCR_SYN | /* 4wire mode */
+		IMX_AUDMUX_V2_PTCR_TCSEL(3) |
+		IMX_AUDMUX_V2_PTCR_TCLKDIR, /* clock is output */
+		IMX_AUDMUX_V2_PDCR_RXDSEL(3));
+}
+
 static struct platform_device *imx_phycore_snd_device;
 
+#ifndef CONFIG_MACH_IMX27_DT
+
+static struct platform_device *imx_phycore_snd_ac97_device;
+
 static int __init imx_phycore_init(void)
 {
 	int ret;
 
 	if (machine_is_pca100()) {
-		imx_audmux_v1_configure_port(MX27_AUDMUX_HPCR1_SSI0,
-			IMX_AUDMUX_V1_PCR_SYN | /* 4wire mode */
-			IMX_AUDMUX_V1_PCR_TFCSEL(3) |
-			IMX_AUDMUX_V1_PCR_TCLKDIR | /* clock is output */
-			IMX_AUDMUX_V1_PCR_RXDSEL(3));
-		imx_audmux_v1_configure_port(3,
-			IMX_AUDMUX_V1_PCR_SYN | /* 4wire mode */
-			IMX_AUDMUX_V1_PCR_TFCSEL(0) |
-			IMX_AUDMUX_V1_PCR_TFSDIR |
-			IMX_AUDMUX_V1_PCR_RXDSEL(0));
+		phycore_ac97_imx21_audmux();
 	} else if (machine_is_pcm043()) {
-		imx_audmux_v2_configure_port(3,
-			IMX_AUDMUX_V2_PTCR_SYN | /* 4wire mode */
-			IMX_AUDMUX_V2_PTCR_TFSEL(0) |
-			IMX_AUDMUX_V2_PTCR_TFSDIR,
-			IMX_AUDMUX_V2_PDCR_RXDSEL(0));
-		imx_audmux_v2_configure_port(0,
-			IMX_AUDMUX_V2_PTCR_SYN | /* 4wire mode */
-			IMX_AUDMUX_V2_PTCR_TCSEL(3) |
-			IMX_AUDMUX_V2_PTCR_TCLKDIR, /* clock is output */
-			IMX_AUDMUX_V2_PDCR_RXDSEL(3));
+		phycore_ac97_imx31_audmux();
 	} else {
 		/* return happy. We might run on a totally different machine */
 		return 0;
@@ -120,6 +140,108 @@ static void __exit imx_phycore_exit(void)
 late_initcall(imx_phycore_init);
 module_exit(imx_phycore_exit);
 
+#else  /* !CONFIG_MACH_IMX27_DT */
+
+static const struct of_device_id imx_phycore_ac97_of_dev_id[] = {
+	{
+		.compatible = "phytec,phycore-ac97",
+	}, {
+		/* sentinel */
+	}
+};
+MODULE_DEVICE_TABLE(of, imx_phycore_ac97_of_dev_id);
+
+static int phycore_ac97_setup_devices(struct platform_device *pdev)
+{
+	int ret;
+
+	imx_phycore_snd_device = platform_device_alloc("wm9712-codec", -1);
+	if (!imx_phycore_snd_device)
+		return -ENOMEM;
+
+	ret = platform_device_add(imx_phycore_snd_device);
+	if (ret) {
+		dev_err(&pdev->dev, "ASoC: Platform device allocation failed\n");
+		goto fail1;
+	}
+
+	ret = snd_soc_register_card(&imx_phycore);
+	if (ret) {
+		dev_err(&pdev->dev, "ASoC: soc card registration failed\n");
+		goto fail2;
+	}
+	return 0;
+
+fail2:
+	platform_device_del(imx_phycore_snd_device);
+fail1:
+	platform_device_put(imx_phycore_snd_device);
+	return ret;
+}
+
+static int imx_phycore_ac97_probe(struct platform_device *pdev)
+{
+	int ret;
+	struct device_node *ssi_np;
+	struct device_node *audmux_np;
+
+	imx_phycore.dev = &pdev->dev;
+
+	audmux_np = of_parse_phandle(pdev->dev.of_node, "phytec,audmux", 0);
+	if (!audmux_np) {
+		dev_err(&pdev->dev, "Failed to parse phytec,audmux phandle\n");
+		return -EINVAL;
+	}
+
+	if (of_device_is_compatible(audmux_np, "fsl,imx21-audmux")) {
+		phycore_ac97_imx21_audmux();
+	} else if (of_device_is_compatible(audmux_np, "fsl,imx31-audmux")) {
+		phycore_ac97_imx31_audmux();
+	} else {
+		dev_err(&pdev->dev, "Unknown audmux, failed to setup audmux\n");
+		of_node_put(audmux_np);
+		return -EINVAL;
+	}
+	of_node_put(audmux_np);
+
+	ssi_np = of_parse_phandle(pdev->dev.of_node, "phytec,ssi", 0);
+	if (!ssi_np) {
+		dev_err(&pdev->dev, "No valid ssi phandle found\n");
+		return -EINVAL;
+	}
+
+	imx_phycore_dai_ac97[0].cpu_of_node = ssi_np;
+	phycore_dai_cpu_node = ssi_np;
+
+
+	ret = phycore_ac97_setup_devices(pdev);
+	if (ret)
+		of_node_put(phycore_dai_cpu_node);
+
+	return ret;
+}
+
+static int imx_phycore_ac97_remove(struct platform_device *pdev)
+{
+	of_node_put(phycore_dai_cpu_node);
+	platform_device_unregister(imx_phycore_snd_device);
+	return 0;
+}
+
+static struct platform_driver imx_phycore_ac97_driver = {
+	.probe		= imx_phycore_ac97_probe,
+	.remove		= imx_phycore_ac97_remove,
+	.driver		= {
+		.name	= DRV_NAME,
+		.owner	= THIS_MODULE,
+		.of_match_table = imx_phycore_ac97_of_dev_id,
+	},
+};
+
+module_platform_driver(imx_phycore_ac97_driver);
+
+#endif  /* CONFIG_MACH_IMX27_DT */
+
 MODULE_AUTHOR("Sascha Hauer <s.hauer at pengutronix.de>");
-MODULE_DESCRIPTION("PhyCORE ALSA SoC driver");
+MODULE_DESCRIPTION(DRV_NAME ": PhyCORE ALSA SoC fabric driver");
 MODULE_LICENSE("GPL");
-- 
1.8.1.5



From mpa at pengutronix.de  Wed Apr 24 10:36:32 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Wed, 24 Apr 2013 16:36:32 +0200
Subject: [PATCH v5 03/10] ASoC: imx-pcm-fiq: Introduce pcm-fiq-params
In-Reply-To: <1366814199-14827-1-git-send-email-mpa@pengutronix.de>
References: <1366814199-14827-1-git-send-email-mpa@pengutronix.de>
Message-ID: <1366814199-14827-4-git-send-email-mpa@pengutronix.de>

Cleaner parameter passing for imx-pcm-fiq. Create a seperated fiq-params
struct to pass all arguments.

Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
---

Notes:
    Changes in v3:
     - Using snd_dmaengine_dai_dma_data for dma_params after rebasing onto
       dmaengine cleanups.

 sound/soc/fsl/imx-pcm-fiq.c | 16 +++++++++-------
 sound/soc/fsl/imx-pcm.h     |  9 +++++++++
 sound/soc/fsl/imx-ssi.c     |  7 ++++++-
 sound/soc/fsl/imx-ssi.h     |  1 +
 4 files changed, 25 insertions(+), 8 deletions(-)

diff --git a/sound/soc/fsl/imx-pcm-fiq.c b/sound/soc/fsl/imx-pcm-fiq.c
index 670b96b..c3fdb2f 100644
--- a/sound/soc/fsl/imx-pcm-fiq.c
+++ b/sound/soc/fsl/imx-pcm-fiq.c
@@ -22,6 +22,7 @@
 #include <linux/slab.h>
 
 #include <sound/core.h>
+#include <sound/dmaengine_pcm.h>
 #include <sound/initval.h>
 #include <sound/pcm.h>
 #include <sound/pcm_params.h>
@@ -32,6 +33,7 @@
 #include <linux/platform_data/asoc-imx-ssi.h>
 
 #include "imx-ssi.h"
+#include "imx-pcm.h"
 
 struct imx_pcm_runtime_data {
 	unsigned int period;
@@ -283,7 +285,7 @@ static struct snd_soc_platform_driver imx_soc_platform_fiq = {
 
 int imx_pcm_fiq_init(struct platform_device *pdev)
 {
-	struct imx_ssi *ssi = platform_get_drvdata(pdev);
+	struct imx_pcm_fiq_params *params = platform_get_drvdata(pdev);
 	int ret;
 
 	ret = claim_fiq(&fh);
@@ -292,15 +294,15 @@ int imx_pcm_fiq_init(struct platform_device *pdev)
 		return ret;
 	}
 
-	mxc_set_irq_fiq(ssi->irq, 1);
-	ssi_irq = ssi->irq;
+	mxc_set_irq_fiq(params->irq, 1);
+	ssi_irq = params->irq;
 
-	imx_pcm_fiq = ssi->irq;
+	imx_pcm_fiq = params->irq;
 
-	imx_ssi_fiq_base = (unsigned long)ssi->base;
+	imx_ssi_fiq_base = (unsigned long)params->base;
 
-	ssi->dma_params_tx.maxburst = 4;
-	ssi->dma_params_rx.maxburst = 6;
+	params->dma_params_tx->maxburst = 4;
+	params->dma_params_rx->maxburst = 6;
 
 	ret = snd_soc_register_platform(&pdev->dev, &imx_soc_platform_fiq);
 	if (ret)
diff --git a/sound/soc/fsl/imx-pcm.h b/sound/soc/fsl/imx-pcm.h
index b7fa0d7..f592f23 100644
--- a/sound/soc/fsl/imx-pcm.h
+++ b/sound/soc/fsl/imx-pcm.h
@@ -32,6 +32,15 @@ imx_pcm_dma_params_init_data(struct imx_dma_data *dma_data,
 		dma_data->peripheral_type = IMX_DMATYPE_SSI;
 }
 
+struct imx_pcm_fiq_params {
+	int irq;
+	void __iomem *base;
+
+	/* Pointer to original ssi driver to setup tx rx sizes */
+	struct snd_dmaengine_dai_dma_data *dma_params_rx;
+	struct snd_dmaengine_dai_dma_data *dma_params_tx;
+};
+
 int snd_imx_pcm_mmap(struct snd_pcm_substream *substream,
 		     struct vm_area_struct *vma);
 int imx_pcm_new(struct snd_soc_pcm_runtime *rtd);
diff --git a/sound/soc/fsl/imx-ssi.c b/sound/soc/fsl/imx-ssi.c
index 902fab0..f80f4c7 100644
--- a/sound/soc/fsl/imx-ssi.c
+++ b/sound/soc/fsl/imx-ssi.c
@@ -601,7 +601,12 @@ static int imx_ssi_probe(struct platform_device *pdev)
 		goto failed_pdev_fiq_alloc;
 	}
 
-	platform_set_drvdata(ssi->soc_platform_pdev_fiq, ssi);
+	ssi->fiq_params.irq = ssi->irq;
+	ssi->fiq_params.base = ssi->base;
+	ssi->fiq_params.dma_params_rx = &ssi->dma_params_rx;
+	ssi->fiq_params.dma_params_tx = &ssi->dma_params_tx;
+
+	platform_set_drvdata(ssi->soc_platform_pdev_fiq, &ssi->fiq_params);
 	ret = platform_device_add(ssi->soc_platform_pdev_fiq);
 	if (ret) {
 		dev_err(&pdev->dev, "failed to add platform device\n");
diff --git a/sound/soc/fsl/imx-ssi.h b/sound/soc/fsl/imx-ssi.h
index bb6b3db..20ce7ca 100644
--- a/sound/soc/fsl/imx-ssi.h
+++ b/sound/soc/fsl/imx-ssi.h
@@ -209,6 +209,7 @@ struct imx_ssi {
 	struct snd_dmaengine_dai_dma_data dma_params_tx;
 	struct imx_dma_data filter_data_tx;
 	struct imx_dma_data filter_data_rx;
+	struct imx_pcm_fiq_params fiq_params;
 
 	int enabled;
 
-- 
1.8.1.5



From mpa at pengutronix.de  Wed Apr 24 10:36:37 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Wed, 24 Apr 2013 16:36:37 +0200
Subject: [PATCH v5 08/10] ASoC: fsl: Kconfig: Use fsl-ssi for phycore-ac97
In-Reply-To: <1366814199-14827-1-git-send-email-mpa@pengutronix.de>
References: <1366814199-14827-1-git-send-email-mpa@pengutronix.de>
Message-ID: <1366814199-14827-9-git-send-email-mpa@pengutronix.de>

Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
---
 sound/soc/fsl/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig
index 3843a18..28af843 100644
--- a/sound/soc/fsl/Kconfig
+++ b/sound/soc/fsl/Kconfig
@@ -153,7 +153,7 @@ config SND_SOC_PHYCORE_AC97
 	select SND_SOC_WM9712
 	select SND_SOC_IMX_PCM_FIQ
 	select SND_SOC_IMX_AUDMUX
-	select SND_SOC_IMX_SSI
+	select SND_SOC_FSL_SSI
 	help
 	  Say Y if you want to add support for SoC audio on Phytec phyCORE
 	  and phyCARD boards in AC97 mode
-- 
1.8.1.5



From shawn.guo at linaro.org  Wed Apr 24 10:39:31 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Wed, 24 Apr 2013 22:39:31 +0800
Subject: [PATCH 2/2] dma: imx-sdma: move to generic device tree bindings
In-Reply-To: <CAOMZO5BkPTZ7guS1cPeZ+s7vXWh1-9Tf7GyJ6ro6tzOHn_Cm_Q@mail.gmail.com>
References: <1366812273-10833-1-git-send-email-shawn.guo@linaro.org>
 <1366812273-10833-3-git-send-email-shawn.guo@linaro.org>
 <CAOMZO5BkPTZ7guS1cPeZ+s7vXWh1-9Tf7GyJ6ro6tzOHn_Cm_Q@mail.gmail.com>
Message-ID: <20130424143930.GC2736@S2101-09.ap.freescale.net>

On Wed, Apr 24, 2013 at 11:23:04AM -0300, Fabio Estevam wrote:
> On Wed, Apr 24, 2013 at 11:04 AM, Shawn Guo <shawn.guo at linaro.org> wrote:
> 
> > +ssi2: ssi at 70014000 {
> > +       compatible = "fsl,imx51-ssi", "fsl,imx21-ssi";
> > +       reg = <0x70014000 0x4000>;
> > +       interrupts = <30>;
> > +       clocks = <&clks 49>;
> > +       dmas = <&sdma 24 DMA_PRIO_HIGH IMX_DMATYPE_SSI_SP>,
> > +              <&sdma 25 DMA_PRIO_HIGH IMX_DMATYPE_SSI_SP>;
> 
> The document says:
> "third cell specifies the peripheral type and priority of DMA transfer
> respectively"
> 
> ,but what I see in this example is the opposite:
> 
> priority of DMA and then peripheral type.

Ah, yes.  Will fix it.  Thanks.

Shawn



From shawn.guo at linaro.org  Wed Apr 24 10:43:20 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Wed, 24 Apr 2013 22:43:20 +0800
Subject: [PATCH 2/2] dma: imx-sdma: move to generic device tree bindings
In-Reply-To: <201304241626.22518.arnd@arndb.de>
References: <1366812273-10833-1-git-send-email-shawn.guo@linaro.org>
 <1366812273-10833-3-git-send-email-shawn.guo@linaro.org>
 <201304241626.22518.arnd@arndb.de>
Message-ID: <20130424144318.GD2736@S2101-09.ap.freescale.net>

On Wed, Apr 24, 2013 at 04:26:22PM +0200, Arnd Bergmann wrote:
> On Wednesday 24 April 2013, Shawn Guo wrote:
> > +/*
> > + * This enumerates peripheral types. Used for SDMA.
> > + */
> > +#define IMX_DMATYPE_SSI                0  /* MCU domain SSI */
> > +#define IMX_DMATYPE_SSI_SP     1  /* Shared SSI */
> > +#define IMX_DMATYPE_MMC                2  /* MMC */
> > +#define IMX_DMATYPE_SDHC       3  /* SDHC */
> > +#define IMX_DMATYPE_UART       4  /* MCU domain UART */
> > +#define IMX_DMATYPE_UART_SP    5  /* Shared UART */
> > +#define IMX_DMATYPE_FIRI       6  /* FIRI */
> > +#define IMX_DMATYPE_CSPI       7  /* MCU domain CSPI */
> > +#define IMX_DMATYPE_CSPI_SP    8  /* Shared CSPI */
> > +#define IMX_DMATYPE_SIM                9  /* SIM */
> > +#define IMX_DMATYPE_ATA                10 /* ATA */
> > +#define IMX_DMATYPE_CCM                11 /* CCM */
> > +#define IMX_DMATYPE_EXT                12 /* External peripheral */
> > +#define IMX_DMATYPE_MSHC       13 /* Memory Stick Host Controller */
> > +#define IMX_DMATYPE_MSHC_SP    14 /* Shared Memory Stick Host Controller */
> > +#define IMX_DMATYPE_DSP                15 /* DSP */
> > +#define IMX_DMATYPE_MEMORY     16 /* Memory */
> > +#define IMX_DMATYPE_FIFO_MEMORY        17 /* FIFO type Memory */
> > +#define IMX_DMATYPE_SPDIF      18 /* SPDIF */
> > +#define IMX_DMATYPE_IPU_MEMORY 19 /* IPU Memory */
> > +#define IMX_DMATYPE_ASRC       20 /* ASRC */
> > +#define IMX_DMATYPE_ESAI       21 /* ESAI */
> 
> These macros don't seem helpful to me, since they are used in only one
> place each. Why not put the literal numbers into the dts file directly?

Using macros will help us to:

1) Improve the readability of "dmas" property in dts
2) Keep the values stay in sync between kernel and DT

Shawn



From linus.walleij at linaro.org  Wed Apr 24 10:44:44 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Wed, 24 Apr 2013 16:44:44 +0200
Subject: [PATCH 02/32] dmaengine: ste_dma40: Move default memcpy configs
 into the driver
In-Reply-To: <1366279934-30761-3-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-3-git-send-email-lee.jones@linaro.org>
Message-ID: <CACRpkdbBeyofVs=G3L-jSXuAv8GRYfwfUNPcV3TAfz2B9ACJ3A@mail.gmail.com>

On Thu, Apr 18, 2013 at 12:11 PM, Lee Jones <lee.jones at linaro.org> wrote:

> There are only two default memcpy configurations used for the DMA40
> driver; one for physical memcpy and one for logical memcpy. Instead
> of invariably passing the same configurations though platform data,
> we're moving them into the driver instead.
>
> Cc: Vinod Koul <vinod.koul at intel.com>
> Cc: Dan Williams <djbw at fb.com>
> Cc: Per Forlin <per.forlin at stericsson.com>
> Cc: Rabin Vincent <rabin at rab.in>
> Acked-by: Arnd Bergmann <arnd at arndb.de>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>

Nice!

Acked-by: Linus Walleij <linus.walleij at linaro.org>

Yours,
Linus Walleij


From t.figa at samsung.com  Wed Apr 24 10:47:08 2013
From: t.figa at samsung.com (Tomasz Figa)
Date: Wed, 24 Apr 2013 16:47:08 +0200
Subject: [PATCH 2/2] pinctrl: samsung: Fix link error with
 CONFIG_PINCTRL_EXYNOS disabled
In-Reply-To: <CACRpkdZmSj-AqUA9kd7NMN6cL2Nxa0EaKoSVkwQSrxhcWEeQtg@mail.gmail.com>
References: <1366060483-20342-1-git-send-email-tomasz.figa@gmail.com>
 <6940961.67Lk2axxPL@amdc1227>
 <CACRpkdZmSj-AqUA9kd7NMN6cL2Nxa0EaKoSVkwQSrxhcWEeQtg@mail.gmail.com>
Message-ID: <2113989.KXXvDDhnMa@amdc1227>

On Wednesday 24 of April 2013 16:27:09 Linus Walleij wrote:
> On Tue, Apr 23, 2013 at 2:09 PM, Tomasz Figa <t.figa at samsung.com> wrote:
> > On Tuesday 23 of April 2013 14:03:12 Linus Walleij wrote:
> >> This does not apply to my "devel" branch in the pinctrl tree.
> >> 
> >> Could you rebase it on that branch?
> >> 
> >> Or is the error not even in my tree?
> > 
> > This one got sent incorrectly due to my mistake. Please try the correct
> > version:
> > 
> > [PATCH RESEND 2/2] pinctrl: samsung: Fix link error with
> > CONFIG_PINCTRL_EXYNOS disabled
> 
> This does not apply either.
> 
> Can you please test against the "devel" branch in the pinctrl tree?

Right, it does not apply.

Well, actually it does with git am -3, but it is incorrect, since the problem 
it intends to fix is not present in your tree, but rather is a merge error in 
linux-next in a merge of Kgene's and your tree...

Best regards,
-- 
Tomasz Figa
Samsung Poland R&D Center
SW Solution Development, Kernel and System Framework



From arnd at arndb.de  Wed Apr 24 10:52:48 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed, 24 Apr 2013 16:52:48 +0200
Subject: [PATCH 2/2] dma: imx-sdma: move to generic device tree bindings
In-Reply-To: <20130424144318.GD2736@S2101-09.ap.freescale.net>
References: <1366812273-10833-1-git-send-email-shawn.guo@linaro.org>
 <201304241626.22518.arnd@arndb.de>
 <20130424144318.GD2736@S2101-09.ap.freescale.net>
Message-ID: <201304241652.48951.arnd@arndb.de>

On Wednesday 24 April 2013, Shawn Guo wrote:
> Using macros will help us to:
> 
> 1) Improve the readability of "dmas" property in dts
> 2) Keep the values stay in sync between kernel and DT
> 

I can understand the second part, but I strongly disagree on the first one.
Using symbolic constants in the DT will make it harder to understand because
you now have to look in multiple places to see what you actually put in there.

It makes some sense for the priorities, since they get reused for each
dma specifier.

	Arnd


From linus.walleij at linaro.org  Wed Apr 24 10:54:49 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Wed, 24 Apr 2013 16:54:49 +0200
Subject: [PATCH 03/32 v2] dmaengine: ste_dma40: Use the BIT macro to
 replace ugly '(1 << x)'s
In-Reply-To: <20130418121637.GG27903@gmail.com>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-4-git-send-email-lee.jones@linaro.org>
 <20130418121637.GG27903@gmail.com>
Message-ID: <CACRpkdYCub2GN5okM4NW9E5snwVnGKvnGd02V2qLX=s6R04e9Q@mail.gmail.com>

On Thu, Apr 18, 2013 at 2:16 PM, Lee Jones <lee.jones at linaro.org> wrote:

> The aim is to make the code that little more readable.
>
> Cc: Vinod Koul <vinod.koul at intel.com>
> Cc: Dan Williams <djbw at fb.com>
> Cc: Per Forlin <per.forlin at stericsson.com>
> Cc: Rabin Vincent <rabin at rab.in>
> Acked-by: Arnd Bergmann <arnd at arndb.de>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>
>
> diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
> index 3b83dee..ddf5ff1 100644
> --- a/drivers/dma/ste_dma40.c
> +++ b/drivers/dma/ste_dma40.c
> @@ -49,9 +49,9 @@
>  #define MAX_LCLA_ALLOC_ATTEMPTS 256
>
>  /* Bit markings for allocation map */
> -#define D40_ALLOC_FREE         (1 << 31)
> -#define D40_ALLOC_PHY          (1 << 30)
> -#define D40_ALLOC_LOG_FREE     0
> +#define D40_ALLOC_FREE         BIT(31)
> +#define D40_ALLOC_PHY          BIT(30)
> +#define D40_ALLOC_LOG_FREE     BIT(0)

No. 0 != BIT(0)

Please fix this...

Yours,
Linus Walleij


From arnd at arndb.de  Wed Apr 24 10:56:53 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed, 24 Apr 2013 16:56:53 +0200
Subject: [PATCH 04/10] usb: musb: ux500: harden checks for platform data
In-Reply-To: <CAF2Aj3ga7R3Vti4YB-83T_AsanB3iL34aysAN3MiMWZBvB=z2Q@mail.gmail.com>
References: <1366729394-11406-1-git-send-email-lee.jones@linaro.org>
 <20130424142615.GF23081@arwen.pp.htv.fi>
 <CAF2Aj3ga7R3Vti4YB-83T_AsanB3iL34aysAN3MiMWZBvB=z2Q@mail.gmail.com>
Message-ID: <201304241656.53432.arnd@arndb.de>

On Wednesday 24 April 2013, Lee Jones wrote:
> Yeah, I agree, although does it make a difference?
> 
> Is it evaluated a second time, or does it take up extra cycles by being
> enclosed in parentheses?
> 
> Or is this just a coding style thing?

Just coding style. I agree you should have no parentheses there, but it
does not change the compiled code.

	Arnd


From plagnioj at jcrosoft.com  Wed Apr 24 10:58:06 2013
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Wed, 24 Apr 2013 16:58:06 +0200
Subject: [PATCH 1/3] ARM: at91: dt: add pinctrl pre-processor define
In-Reply-To: <20130424145627.GL4998@game.jcrosoft.org>
References: <20130424145627.GL4998@game.jcrosoft.org>
Message-ID: <1366815488-27976-1-git-send-email-plagnioj@jcrosoft.com>

Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
Cc: Nicolas Ferre <nicolas.ferre at atmel.com>
---
 arch/arm/boot/dts/at91-pinctrl.h |   35 +++++++++++++++++++++++++++++++++++
 1 file changed, 35 insertions(+)
 create mode 100644 arch/arm/boot/dts/at91-pinctrl.h

diff --git a/arch/arm/boot/dts/at91-pinctrl.h b/arch/arm/boot/dts/at91-pinctrl.h
new file mode 100644
index 0000000..d7988b4
--- /dev/null
+++ b/arch/arm/boot/dts/at91-pinctrl.h
@@ -0,0 +1,35 @@
+/*
+ * This header provides constants for most at91 pinctrl bindings.
+ *
+ * Copyright (C) 2013 Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
+ *
+ * GPLv2 only
+ */
+
+#ifndef __DT_BINDINGS_AT91_PINCTRL_H__
+#define __DT_BINDINGS_AT91_PINCTRL_H__
+
+#define AT91_PINCTRL_NONE		(0 << 0)
+#define AT91_PINCTRL_PULL_UP		(1 << 0)
+#define AT91_PINCTRL_MULTI_DRIVE	(1 << 1)
+#define AT91_PINCTRL_DEGLITCH		(1 << 2)
+#define AT91_PINCTRL_PULL_DOWN		(1 << 3)
+#define AT91_PINCTRL_DIS_SCHMIT		(1 << 4)
+#define AT91_PINCTRL_DEBOUNCE		(1 << 16)
+#define AT91_PINCTRL_DEBOUNCE_VA(x)	(x << 17)
+
+#define AT91_PINCTRL_PULL_UP_DEGLITCH	(AT91_PINCTRL_PULL_UP | AT91_PINCTRL_DEGLITCH)
+
+#define AT91_PIOA	0
+#define AT91_PIOB	1
+#define AT91_PIOC	2
+#define AT91_PIOD	3
+#define AT91_PIOE	4
+
+#define AT91_PERIPH_GPIO	0
+#define AT91_PERIPH_A		1
+#define AT91_PERIPH_B		2
+#define AT91_PERIPH_C		3
+#define AT91_PERIPH_D		4
+
+#endif /* __DT_BINDINGS_AT91_PINCTRL_H__ */
-- 
1.7.10.4



From plagnioj at jcrosoft.com  Wed Apr 24 10:58:07 2013
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Wed, 24 Apr 2013 16:58:07 +0200
Subject: [PATCH 2/3] ARM: at91: dt: add AIC pre-processor define
In-Reply-To: <1366815488-27976-1-git-send-email-plagnioj@jcrosoft.com>
References: <20130424145627.GL4998@game.jcrosoft.org>
 <1366815488-27976-1-git-send-email-plagnioj@jcrosoft.com>
Message-ID: <1366815488-27976-2-git-send-email-plagnioj@jcrosoft.com>

Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
Cc: Nicolas Ferre <nicolas.ferre at atmel.com>
---
 arch/arm/boot/dts/at91-aic.h |   19 +++++++++++++++++++
 1 file changed, 19 insertions(+)
 create mode 100644 arch/arm/boot/dts/at91-aic.h

diff --git a/arch/arm/boot/dts/at91-aic.h b/arch/arm/boot/dts/at91-aic.h
new file mode 100644
index 0000000..ed3f8be
--- /dev/null
+++ b/arch/arm/boot/dts/at91-aic.h
@@ -0,0 +1,19 @@
+/*
+ * This header provides constants for most at91 AIC bindings.
+ *
+ * Copyright (C) 2013 Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
+ *
+ * GPLv2 only
+ */
+
+#ifndef __DT_BINDINGS_AT91_AIC_H__
+#define __DT_BINDINGS_AT91_AIC_H__
+
+#define AT91_AIC_LOW_TO_HIGH		(1 < 0)
+#define AT91_AIC_HIGH_TO_LOW		(1 < 1)
+#define AT91_AIC_HIGH			(1 < 2)
+#define AT91_AIC_LOW			(1 < 3)
+
+#define AT91_AIC_LOW_TO_HIGH_OR_HIGH_TO_LOW	(AT91_AIC_LOW_TO_HIGH | AT91_AIC_HIGH_TO_LOW)
+
+#endif /* __DT_BINDINGS_AT91_AIC_H__ */
-- 
1.7.10.4



From arnd at arndb.de  Wed Apr 24 11:03:49 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed, 24 Apr 2013 17:03:49 +0200
Subject: Exynos regressions w.r.t. config and debuggability due to
 multiplatform
In-Reply-To: <CAOesGMgRsa-AvbEZCc1=_ovaZMaG0S-CDok2MDp_zu5yderAYw@mail.gmail.com>
References: <CAOesGMgRsa-AvbEZCc1=_ovaZMaG0S-CDok2MDp_zu5yderAYw@mail.gmail.com>
Message-ID: <201304241703.49864.arnd@arndb.de>

On Wednesday 24 April 2013, Olof Johansson wrote:
> I think we should hold off on multiplatform for exynos until it works
> better, i.e. 3.11.
> 
> First, the defconfig we have in our out-of-tree build system now
> builds a broken kernel since it doesn't set ARCH_EXYNOS_SINGLE. As a
> result, exynos gets turned off. It's quite awkward to switch between
> pre- and post-multiplatform configs, which makes bisecting and other
> error finding hard. I'm sure this will hit other downstream users too.

Hmm, good. point. The idea of the naming was that you actually
/can/ go back and forth across that commit since ARCH_EXYNOS exists
at all times, either as a standalone symbol or as part of multiplatform.

Unfortunately, I did not consider that this stops working for
bisection if we do the change and only make ARCH_EXYNOS_SINGLE
work correctly but leave ARCH_EXYNOS as "depends on BROKEN"
initially. I think you are right that we need to revert bd51de53e1b
"ARM: exynos: enable multiplatform support" in the next/multiplatform
branch, although I don't see a problem with the other commits there.

> What's even more frustrating is that I can't turn on DEBUG_LL, since
> serial drivers depend on PLAT_SAMSUNG, and that is no longer set.

Are you sure? I don't see that problem. PLAT_SAMSUNG should still
get set in both single- and multiplatform configurations, along with
PLAT_SAMSUNG_SINGLE in the case of single-platform exynos.
I've testing DEBUG_LL both in single and multi configurations on
linux-next.

> Seems like we'll have a really broken 3.10 if we merge what we have
> now. More bake time is definitely needed. :(

I think the problems with exynos are elsewhere at the moment, and
Kukjin, Thomas, Tomasz and others have worked hard on getting those
problems fixed. I would suggest we leave the "samsung/exynos-multiplatform"
preparation series scheduled for the first set of pull requests in
next/multiplatform but revert the bd51de53e1b commit in it.

Once the dust settles in the merge window and the exynos multiplatform
patches that are queued up in other trees (serial, spi, video, ...)
have made it upstream, we can decide if the late/multiplatform
series still looks scary or not. If you feel strongly about it and know
that you don't want to merge it then, we can also drop the first part now.

	Arnd


From lee.jones at linaro.org  Wed Apr 24 11:04:06 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Wed, 24 Apr 2013 16:04:06 +0100
Subject: [PATCH 04/10 v2] usb: musb: ux500: harden checks for platform data
In-Reply-To: <1366729394-11406-5-git-send-email-lee.jones@linaro.org>
References: <1366729394-11406-1-git-send-email-lee.jones@linaro.org>
 <1366729394-11406-5-git-send-email-lee.jones@linaro.org>
Message-ID: <20130424150406.GD9652@gmail.com>

In its current state, the ux500-musb driver uses platform data pointers
blindly with no prior checking. If no platform data pointer is passed
this will Oops the kernel. In this patch we ensure platform data and
board data are present prior to using them.

Cc: Felipe Balbi <balbi at ti.com>
Cc: linux-usb at vger.kernel.org
Signed-off-by: Lee Jones <lee.jones at linaro.org>

diff --git a/drivers/usb/musb/ux500_dma.c b/drivers/usb/musb/ux500_dma.c
index c75e07a..8d5128d 100644
--- a/drivers/usb/musb/ux500_dma.c
+++ b/drivers/usb/musb/ux500_dma.c
@@ -287,7 +287,7 @@ static int ux500_dma_controller_start(struct dma_controller *c)
 	struct musb *musb = controller->private_data;
 	struct device *dev = musb->controller;
 	struct musb_hdrc_platform_data *plat = dev->platform_data;
-	struct ux500_musb_board_data *data = plat->board_data;
+	struct ux500_musb_board_data *data;
 	struct dma_channel *dma_channel = NULL;
 	u32 ch_num;
 	u8 dir;
@@ -297,14 +297,19 @@ static int ux500_dma_controller_start(struct dma_controller *c)
 	struct ux500_dma_channel *channel_array;
 	dma_cap_mask_t mask;
 
+	if (!plat) {
+		dev_err(musb->controller, "No platform data\n");
+		return -EINVAL;
+	}
 
+	data = plat->board_data;
 
 	dma_cap_zero(mask);
 	dma_cap_set(DMA_SLAVE, mask);
 
 	/* Prepare the loop for RX channels */
 	channel_array = controller->rx_channel;
-	param_array = data->dma_rx_param_array;
+	param_array = data ? data->dma_rx_param_array : NULL;
 
 	for (dir = 0; dir < 2; dir++) {
 		for (ch_num = 0;
@@ -337,7 +342,7 @@ static int ux500_dma_controller_start(struct dma_controller *c)
 
 		/* Prepare the loop for TX channels */
 		channel_array = controller->tx_channel;
-		param_array = data->dma_tx_param_array;
+		param_array = data ? data->dma_tx_param_array : NULL;
 		is_tx = 1;
 	}


From lee.jones at linaro.org  Wed Apr 24 11:05:21 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Wed, 24 Apr 2013 16:05:21 +0100
Subject: [PATCH 05/10 v2] usb: musb: ux500: attempt to find channels by name
 before using pdata
In-Reply-To: <1366729394-11406-6-git-send-email-lee.jones@linaro.org>
References: <1366729394-11406-1-git-send-email-lee.jones@linaro.org>
 <1366729394-11406-6-git-send-email-lee.jones@linaro.org>
Message-ID: <20130424150521.GE9652@gmail.com>

If we can ever get to a state where we can solely search for DMA channels
by name, this will almost completely alleviate the requirement to pass
copious amounts of information though platform data. Here we take the
first step towards this. The next step will be to enable Device Tree
complete with name<->event_line mapping.

Cc: Felipe Balbi <balbi at ti.com>
Cc: linux-usb at vger.kernel.org
Signed-off-by: Lee Jones <lee.jones at linaro.org>

diff --git a/drivers/usb/musb/ux500_dma.c b/drivers/usb/musb/ux500_dma.c
index 8d5128d..99ad1fe 100644
--- a/drivers/usb/musb/ux500_dma.c
+++ b/drivers/usb/musb/ux500_dma.c
@@ -33,6 +33,11 @@
 #include <linux/platform_data/usb-musb-ux500.h>
 #include "musb_core.h"
 
+static const char *iep_chan_names[] = { "iep_1_9", "iep_2_10", "iep_3_11", "iep_4_12",
+					"iep_5_13", "iep_6_14", "iep_7_15", "iep_8" };
+static const char *oep_chan_names[] = { "oep_1_9", "oep_2_10", "oep_3_11", "oep_4_12",
+					"oep_5_13", "oep_6_14", "oep_7_15", "oep_8" };
+
 struct ux500_dma_channel {
 	struct dma_channel channel;
 	struct ux500_dma_controller *controller;
@@ -289,6 +294,7 @@ static int ux500_dma_controller_start(struct dma_controller *c)
 	struct musb_hdrc_platform_data *plat = dev->platform_data;
 	struct ux500_musb_board_data *data;
 	struct dma_channel *dma_channel = NULL;
+	char **chan_names;
 	u32 ch_num;
 	u8 dir;
 	u8 is_tx = 0;
@@ -310,6 +316,7 @@ static int ux500_dma_controller_start(struct dma_controller *c)
 	/* Prepare the loop for RX channels */
 	channel_array = controller->rx_channel;
 	param_array = data ? data->dma_rx_param_array : NULL;
+	chan_names = (char **)iep_chan_names;
 
 	for (dir = 0; dir < 2; dir++) {
 		for (ch_num = 0;
@@ -325,9 +332,15 @@ static int ux500_dma_controller_start(struct dma_controller *c)
 			dma_channel->status = MUSB_DMA_STATUS_FREE;
 			dma_channel->max_len = SZ_16M;
 
-			ux500_channel->dma_chan = dma_request_channel(mask,
-							data->dma_filter,
-							param_array[ch_num]);
+			ux500_channel->dma_chan =
+				dma_request_slave_channel(dev, chan_names[ch_num]);
+
+			if (!ux500_channel->dma_chan)
+				ux500_channel->dma_chan =
+					dma_request_channel(mask,
+							    data->dma_filter,
+							    param_array[ch_num]);
+
 			if (!ux500_channel->dma_chan) {
 				ERR("Dma pipe allocation error dir=%d ch=%d\n",
 					dir, ch_num);
@@ -343,6 +356,7 @@ static int ux500_dma_controller_start(struct dma_controller *c)
 		/* Prepare the loop for TX channels */
 		channel_array = controller->tx_channel;
 		param_array = data ? data->dma_tx_param_array : NULL;
+		chan_names = (char **)oep_chan_names;
 		is_tx = 1;
 	}


From linus.walleij at linaro.org  Wed Apr 24 11:05:29 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Wed, 24 Apr 2013 17:05:29 +0200
Subject: [PATCH 1/8] dmaengine: ste_dma40: Assign memcpy channels in the
 driver
In-Reply-To: <CAF2Aj3jHPvc=hOcgLq8LONppGtnxUPP96HRPLfCwQ5x4HONUOw@mail.gmail.com>
References: <1365532783-27425-1-git-send-email-lee.jones@linaro.org>
 <CACRpkdYUT+5J-phV=ez-EkmA9EdfxwmDMApTssi+P3=mSE3cew@mail.gmail.com>
 <CAF2Aj3jHPvc=hOcgLq8LONppGtnxUPP96HRPLfCwQ5x4HONUOw@mail.gmail.com>
Message-ID: <CACRpkdZceyOte4vG8QcN5Dy1ooiTT69oOQ1Ud=SffRWbPMXOSg@mail.gmail.com>

On Wed, Apr 24, 2013 at 4:54 PM, Lee Jones <lee.jones at linaro.org> wrote:
> On 24 April 2013 14:45, Linus Walleij <linus.walleij at linaro.org> wrote:
>> On Tue, Apr 9, 2013 at 8:39 PM, Lee Jones <lee.jones at linaro.org> wrote:
>>
>> > The channels reserved for memcpy are the same for all currently
>> > supported platforms. With this in mind, we can ease the platform
>> > data passing requirement by moving these assignments out from
>> > platform code and place them directly into the driver.
>> >
>> > Cc: Vinod Koul <vinod.koul at intel.com>
>> > Cc: Dan Williams <djbw at fb.com>
>> > Cc: Per Forlin <per.forlin at stericsson.com>
>> > Acked-by: Arnd Bergmann <arnd at arndb.de>
>> > Signed-off-by: Lee Jones <lee.jones at linaro.org>
>>
>> (...)
>>
>> > -/* Reserved event lines for memcpy only */
>> > -static int dma40_memcpy_event[] = {
>> > -       DB8500_DMA_MEMCPY_TX_0,
>> > -       DB8500_DMA_MEMCPY_TX_1,
>> > -       DB8500_DMA_MEMCPY_TX_2,
>> > -       DB8500_DMA_MEMCPY_TX_3,
>> > -       DB8500_DMA_MEMCPY_TX_4,
>> > -       DB8500_DMA_MEMCPY_TX_5,
>> > -};
>>
>> (...)
>>
>> > +/* Reserved event lines for memcpy only. */
>> > +static int dma40_memcpy_channels[] = { 56, 57, 58, 59, 60 };
>>
>> So what's so bad with using the #defines?
>>
>> I would prefer if you took the entire content of
>> arch/arm/mach-ux500/ste-dma40-db8500.h
>> and copied into the DMA driver, so you atleast
>> have a chance of understanding what these numbers
>> are about.
>
>
> I did attempt to do that, but Arnd NAK:ed it:
>
> "Hmm, not sure about this one. The slave numbers are not really
> platform_data and I think they should not be exposed to drivers. It
> makes sense to keep the numbers for the memcpy channels in the driver
> itself as they are hardwired in the driver, but the slave channels
> should stay in the platform I think."
>
> ... and I didn't want to duplicate the defines, but I'll so whatever
> you choose.

I don't think I agree.

OK atleast define the numbers with something like
#define DB8500_DMA_MEMCPY_TX_0 56
etc, just hard-coding the numbers is pretty unhelpful, OK?

Ultimately these 5 numbers should (optionally) come in from
the device tree node for the DMA40 itself, maybe a later patch
adds that...?

Yours,
Linus Walleij


From lee.jones at linaro.org  Wed Apr 24 11:08:01 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Wed, 24 Apr 2013 16:08:01 +0100
Subject: [PATCH 03/32 v2] dmaengine: ste_dma40: Use the BIT macro to
 replace ugly '(1 << x)'s
In-Reply-To: <CACRpkdYCub2GN5okM4NW9E5snwVnGKvnGd02V2qLX=s6R04e9Q@mail.gmail.com>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-4-git-send-email-lee.jones@linaro.org>
 <20130418121637.GG27903@gmail.com>
 <CACRpkdYCub2GN5okM4NW9E5snwVnGKvnGd02V2qLX=s6R04e9Q@mail.gmail.com>
Message-ID: <20130424150801.GF9652@gmail.com>

On Wed, 24 Apr 2013, Linus Walleij wrote:

> On Thu, Apr 18, 2013 at 2:16 PM, Lee Jones <lee.jones at linaro.org> wrote:
> 
> > The aim is to make the code that little more readable.
> >
> > Cc: Vinod Koul <vinod.koul at intel.com>
> > Cc: Dan Williams <djbw at fb.com>
> > Cc: Per Forlin <per.forlin at stericsson.com>
> > Cc: Rabin Vincent <rabin at rab.in>
> > Acked-by: Arnd Bergmann <arnd at arndb.de>
> > Signed-off-by: Lee Jones <lee.jones at linaro.org>
> >
> > diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
> > index 3b83dee..ddf5ff1 100644
> > --- a/drivers/dma/ste_dma40.c
> > +++ b/drivers/dma/ste_dma40.c
> > @@ -49,9 +49,9 @@
> >  #define MAX_LCLA_ALLOC_ATTEMPTS 256
> >
> >  /* Bit markings for allocation map */
> > -#define D40_ALLOC_FREE         (1 << 31)
> > -#define D40_ALLOC_PHY          (1 << 30)
> > -#define D40_ALLOC_LOG_FREE     0
> > +#define D40_ALLOC_FREE         BIT(31)
> > +#define D40_ALLOC_PHY          BIT(30)
> > +#define D40_ALLOC_LOG_FREE     BIT(0)
> 
> No. 0 != BIT(0)
> 
> Please fix this...

Good spot.

I've already fixed this though.

I'll send it as a v3 now.

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From lee.jones at linaro.org  Wed Apr 24 11:09:14 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Wed, 24 Apr 2013 16:09:14 +0100
Subject: [PATCH 03/32] dmaengine: ste_dma40: Use the BIT macro to replace
 ugly '(1 << x)'s
In-Reply-To: <1366279934-30761-4-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-4-git-send-email-lee.jones@linaro.org>
Message-ID: <20130424150914.GG9652@gmail.com>

dmaengine: ste_dma40: Use the BIT macro to replace ugly '(1 << x)'s

The aim is to make the code that little more readable.

Acked-by: Vinod Koul <vnod.koul at intel.com>
Acked-by: Arnd Bergmann <arnd at arndb.de>
Signed-off-by: Lee Jones <lee.jones at linaro.org>

diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index 3b83dee..b3a82bf 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -49,8 +49,8 @@
 #define MAX_LCLA_ALLOC_ATTEMPTS 256
 
 /* Bit markings for allocation map */
-#define D40_ALLOC_FREE		(1 << 31)
-#define D40_ALLOC_PHY		(1 << 30)
+#define D40_ALLOC_FREE		BIT(31)
+#define D40_ALLOC_PHY		BIT(30)
 #define D40_ALLOC_LOG_FREE	0
 
 #define MAX(a, b) (((a) < (b)) ? (b) : (a))
@@ -993,12 +993,12 @@ static int d40_size_2_dmalen(int size, u32 data_width1, u32 data_width2)
 	int dmalen;
 	u32 max_w = max(data_width1, data_width2);
 	u32 min_w = min(data_width1, data_width2);
-	u32 seg_max = ALIGN(STEDMA40_MAX_SEG_SIZE << min_w, 1 << max_w);
+	u32 seg_max = ALIGN(STEDMA40_MAX_SEG_SIZE << min_w, BIT(max_w));
 
 	if (seg_max > STEDMA40_MAX_SEG_SIZE)
-		seg_max -= (1 << max_w);
+		seg_max -= BIT(max_w);
 
-	if (!IS_ALIGNED(size, 1 << max_w))
+	if (!IS_ALIGNED(size, BIT(max_w)))
 		return -EINVAL;
 
 	if (size <= seg_max)
@@ -1448,7 +1448,7 @@ static u32 d40_residue(struct d40_chan *d40c)
 			  >> D40_SREG_ELEM_PHY_ECNT_POS;
 	}
 
-	return num_elt * (1 << d40c->dma_cfg.dst_info.data_width);
+	return num_elt << d40c->dma_cfg.dst_info.data_width;
 }
 
 static bool d40_tx_is_linked(struct d40_chan *d40c)
@@ -1722,7 +1722,7 @@ static irqreturn_t d40_handle_interrupt(int irq, void *data)
 		}
 
 		/* ACK interrupt */
-		writel(1 << idx, base->virtbase + il[row].clr);
+		writel(BIT(idx), base->virtbase + il[row].clr);
 
 		spin_lock(&d40c->lock);
 
@@ -1804,9 +1804,9 @@ static int d40_validate_conf(struct d40_chan *d40c,
 	}
 
 	if (d40_psize_2_burst_size(is_log, conf->src_info.psize) *
-	    (1 << conf->src_info.data_width) !=
+	    BIT(conf->src_info.data_width) !=
 	    d40_psize_2_burst_size(is_log, conf->dst_info.psize) *
-	    (1 << conf->dst_info.data_width)) {
+	    BIT(conf->dst_info.data_width)) {
 		/*
 		 * The DMAC hardware only supports
 		 * src (burst x width) == dst (burst x width)
@@ -1848,8 +1848,8 @@ static bool d40_alloc_mask_set(struct d40_phy_res *phy,
 		if (phy->allocated_src == D40_ALLOC_FREE)
 			phy->allocated_src = D40_ALLOC_LOG_FREE;
 
-		if (!(phy->allocated_src & (1 << log_event_line))) {
-			phy->allocated_src |= 1 << log_event_line;
+		if (!(phy->allocated_src & BIT(log_event_line))) {
+			phy->allocated_src |= BIT(log_event_line);
 			goto found;
 		} else
 			goto not_found;
@@ -1860,8 +1860,8 @@ static bool d40_alloc_mask_set(struct d40_phy_res *phy,
 		if (phy->allocated_dst == D40_ALLOC_FREE)
 			phy->allocated_dst = D40_ALLOC_LOG_FREE;
 
-		if (!(phy->allocated_dst & (1 << log_event_line))) {
-			phy->allocated_dst |= 1 << log_event_line;
+		if (!(phy->allocated_dst & BIT(log_event_line))) {
+			phy->allocated_dst |= BIT(log_event_line);
 			goto found;
 		} else
 			goto not_found;
@@ -1891,11 +1891,11 @@ static bool d40_alloc_mask_free(struct d40_phy_res *phy, bool is_src,
 
 	/* Logical channel */
 	if (is_src) {
-		phy->allocated_src &= ~(1 << log_event_line);
+		phy->allocated_src &= ~BIT(log_event_line);
 		if (phy->allocated_src == D40_ALLOC_LOG_FREE)
 			phy->allocated_src = D40_ALLOC_FREE;
 	} else {
-		phy->allocated_dst &= ~(1 << log_event_line);
+		phy->allocated_dst &= ~BIT(log_event_line);
 		if (phy->allocated_dst == D40_ALLOC_LOG_FREE)
 			phy->allocated_dst = D40_ALLOC_FREE;
 	}
@@ -2394,7 +2394,7 @@ static void __d40_set_prio_rt(struct d40_chan *d40c, int dev_type, bool src)
 	u32 rtreg;
 	u32 event = D40_TYPE_TO_EVENT(dev_type);
 	u32 group = D40_TYPE_TO_GROUP(dev_type);
-	u32 bit = 1 << event;
+	u32 bit = BIT(event);
 	u32 prioreg;
 	struct d40_gen_dmac *dmac = &d40c->base->gen_dmac;


From lee.jones at linaro.org  Wed Apr 24 11:11:45 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Wed, 24 Apr 2013 16:11:45 +0100
Subject: [PATCH 03/32 v3] dmaengine: ste_dma40: Use the BIT macro to replace
 ugly '(1 << x)'s
In-Reply-To: <1366279934-30761-4-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-4-git-send-email-lee.jones@linaro.org>
Message-ID: <20130424151145.GH9652@gmail.com>

The aim is to make the code that little more readable.

Acked-by: Vinod Koul <vnod.koul at intel.com>
Acked-by: Arnd Bergmann <arnd at arndb.de>
Signed-off-by: Lee Jones <lee.jones at linaro.org>

diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index 3b83dee..b3a82bf 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -49,8 +49,8 @@
 #define MAX_LCLA_ALLOC_ATTEMPTS 256
 
 /* Bit markings for allocation map */
-#define D40_ALLOC_FREE		(1 << 31)
-#define D40_ALLOC_PHY		(1 << 30)
+#define D40_ALLOC_FREE		BIT(31)
+#define D40_ALLOC_PHY		BIT(30)
 #define D40_ALLOC_LOG_FREE	0
 
 #define MAX(a, b) (((a) < (b)) ? (b) : (a))
@@ -993,12 +993,12 @@ static int d40_size_2_dmalen(int size, u32 data_width1, u32 data_width2)
 	int dmalen;
 	u32 max_w = max(data_width1, data_width2);
 	u32 min_w = min(data_width1, data_width2);
-	u32 seg_max = ALIGN(STEDMA40_MAX_SEG_SIZE << min_w, 1 << max_w);
+	u32 seg_max = ALIGN(STEDMA40_MAX_SEG_SIZE << min_w, BIT(max_w));
 
 	if (seg_max > STEDMA40_MAX_SEG_SIZE)
-		seg_max -= (1 << max_w);
+		seg_max -= BIT(max_w);
 
-	if (!IS_ALIGNED(size, 1 << max_w))
+	if (!IS_ALIGNED(size, BIT(max_w)))
 		return -EINVAL;
 
 	if (size <= seg_max)
@@ -1448,7 +1448,7 @@ static u32 d40_residue(struct d40_chan *d40c)
 			  >> D40_SREG_ELEM_PHY_ECNT_POS;
 	}
 
-	return num_elt * (1 << d40c->dma_cfg.dst_info.data_width);
+	return num_elt << d40c->dma_cfg.dst_info.data_width;
 }
 
 static bool d40_tx_is_linked(struct d40_chan *d40c)
@@ -1722,7 +1722,7 @@ static irqreturn_t d40_handle_interrupt(int irq, void *data)
 		}
 
 		/* ACK interrupt */
-		writel(1 << idx, base->virtbase + il[row].clr);
+		writel(BIT(idx), base->virtbase + il[row].clr);
 
 		spin_lock(&d40c->lock);
 
@@ -1804,9 +1804,9 @@ static int d40_validate_conf(struct d40_chan *d40c,
 	}
 
 	if (d40_psize_2_burst_size(is_log, conf->src_info.psize) *
-	    (1 << conf->src_info.data_width) !=
+	    BIT(conf->src_info.data_width) !=
 	    d40_psize_2_burst_size(is_log, conf->dst_info.psize) *
-	    (1 << conf->dst_info.data_width)) {
+	    BIT(conf->dst_info.data_width)) {
 		/*
 		 * The DMAC hardware only supports
 		 * src (burst x width) == dst (burst x width)
@@ -1848,8 +1848,8 @@ static bool d40_alloc_mask_set(struct d40_phy_res *phy,
 		if (phy->allocated_src == D40_ALLOC_FREE)
 			phy->allocated_src = D40_ALLOC_LOG_FREE;
 
-		if (!(phy->allocated_src & (1 << log_event_line))) {
-			phy->allocated_src |= 1 << log_event_line;
+		if (!(phy->allocated_src & BIT(log_event_line))) {
+			phy->allocated_src |= BIT(log_event_line);
 			goto found;
 		} else
 			goto not_found;
@@ -1860,8 +1860,8 @@ static bool d40_alloc_mask_set(struct d40_phy_res *phy,
 		if (phy->allocated_dst == D40_ALLOC_FREE)
 			phy->allocated_dst = D40_ALLOC_LOG_FREE;
 
-		if (!(phy->allocated_dst & (1 << log_event_line))) {
-			phy->allocated_dst |= 1 << log_event_line;
+		if (!(phy->allocated_dst & BIT(log_event_line))) {
+			phy->allocated_dst |= BIT(log_event_line);
 			goto found;
 		} else
 			goto not_found;
@@ -1891,11 +1891,11 @@ static bool d40_alloc_mask_free(struct d40_phy_res *phy, bool is_src,
 
 	/* Logical channel */
 	if (is_src) {
-		phy->allocated_src &= ~(1 << log_event_line);
+		phy->allocated_src &= ~BIT(log_event_line);
 		if (phy->allocated_src == D40_ALLOC_LOG_FREE)
 			phy->allocated_src = D40_ALLOC_FREE;
 	} else {
-		phy->allocated_dst &= ~(1 << log_event_line);
+		phy->allocated_dst &= ~BIT(log_event_line);
 		if (phy->allocated_dst == D40_ALLOC_LOG_FREE)
 			phy->allocated_dst = D40_ALLOC_FREE;
 	}
@@ -2394,7 +2394,7 @@ static void __d40_set_prio_rt(struct d40_chan *d40c, int dev_type, bool src)
 	u32 rtreg;
 	u32 event = D40_TYPE_TO_EVENT(dev_type);
 	u32 group = D40_TYPE_TO_GROUP(dev_type);
-	u32 bit = 1 << event;
+	u32 bit = BIT(event);
 	u32 prioreg;
 	struct d40_gen_dmac *dmac = &d40c->base->gen_dmac;


From shawn.guo at linaro.org  Wed Apr 24 11:15:46 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Wed, 24 Apr 2013 23:15:46 +0800
Subject: [PATCH 2/2] dma: imx-sdma: move to generic device tree bindings
In-Reply-To: <201304241652.48951.arnd@arndb.de>
References: <1366812273-10833-1-git-send-email-shawn.guo@linaro.org>
 <201304241626.22518.arnd@arndb.de>
 <20130424144318.GD2736@S2101-09.ap.freescale.net>
 <201304241652.48951.arnd@arndb.de>
Message-ID: <20130424151544.GE2736@S2101-09.ap.freescale.net>

On Wed, Apr 24, 2013 at 04:52:48PM +0200, Arnd Bergmann wrote:
> On Wednesday 24 April 2013, Shawn Guo wrote:
> > Using macros will help us to:
> > 
> > 1) Improve the readability of "dmas" property in dts
> > 2) Keep the values stay in sync between kernel and DT
> > 
> 
> I can understand the second part, but I strongly disagree on the first one.
> Using symbolic constants in the DT will make it harder to understand because
> you now have to look in multiple places to see what you actually put in there.

So for example below, I did not use macro for the first cell which is
the DMA request ID, because it's unique for each peripheral.  But
IMX_DMATYPE_SSI_SP will be applied on all 3 SSI controllers on imx51
for 6 times (rx and tx).

	dmas = <&sdma 24 IMX_DMATYPE_SSI_SP DMA_PRIO_HIGH>,
	       <&sdma 25 IMX_DMATYPE_SSI_SP DMA_PRIO_HIGH>;
	dma-names = "rx", "tx";

Shawn

> It makes some sense for the priorities, since they get reused for each
> dma specifier.



From nschichan at freebox.fr  Wed Apr 24 11:52:34 2013
From: nschichan at freebox.fr (Nicolas Schichan)
Date: Wed, 24 Apr 2013 17:52:34 +0200
Subject: [PATCH V2 1/3] seccomp: add generic code for jitted seccomp
 filters.
In-Reply-To: <20130423164303.d2eb663c4a1becea4a185087@linux-foundation.org>
References: <1363618233-6375-1-git-send-email-nschichan@freebox.fr>
 <1363618233-6375-2-git-send-email-nschichan@freebox.fr>
 <20130417145628.88058f0f3104ab9ae551ddd3@linux-foundation.org>
 <51752D98.8070709@freebox.fr>
 <20130423164303.d2eb663c4a1becea4a185087@linux-foundation.org>
Message-ID: <5177FFC2.5020102@freebox.fr>

On 04/24/2013 01:43 AM, Andrew Morton wrote:
> On Mon, 22 Apr 2013 14:31:20 +0200 Nicolas Schichan <nschichan at freebox.fr> wrote:
>> Would including <uapi/linux/filter.h> instead of <linux/filter.h> in seccomp.h
>> be an acceptable solution ?
>>
>> I have tried that and (with an additional forward declaration of struct
>> sk_buff) an x86_64 "make clean; make allmodconfig" run finishes succesfully.
>>
>> If that's ok with you, I can resend the serie with that fix.
>
> It would be better to make the code and include tangle less complex,
> rather than more complex.
>
> Did we really need to move the `struct seccomp_filter' definition into
> the header file?  afaict that wasn't really necessary - we can add a
> few helper functions to kernel/seccomp.c and then have the remote code
> treat seccomp_filter in an opaque fashion rather than directly poking
> at its internals.

Hi,

I will resend a V3 of the patch serie with the accessors.

> btw, what on earth is going on with seccomp_jit_free()?  It does
> disturbing undocumented typecasting and it punts the module_free into a
> kernel thread for mysterious, undocumented and possibly buggy reasons.
>
> I realize it just copies bpf_jit_free().  The same observations apply there.

The reason for this hack for both seccomp filters and socket filters is that 
{seccomp,bpf}_jit_free are called from a softirq. module_free() cannot be 
called directly from softirq, as it will in turn call vfree() which will 
BUG_ON() if in_interrupt() is non zero. So to call module_free(), it is 
therefore required to be in a process context, which is provided by the work 
struct.

Here is the call stack for the socket filter case:

[<c0087bf8>] (vfree+0x28/0x2c) from [<c001fc5c>] (bpf_jit_free+0x10/0x18)
[<c001fc5c>] (bpf_jit_free+0x10/0x18) from 
[<c0231188>](sk_filter_release_rcu+0x10/0x1c)
[<c0231188>] (sk_filter_release_rcu+0x10/0x1c) from [<c0060bb4>] 
(__rcu_process_callbacks+0x98/0xac)
[<c0060bb4>] (__rcu_process_callbacks+0x98/0xac) from [<c0060bd8>] 
(rcu_process_callbacks+0x10/0x20)
[<c0060bd8>] (rcu_process_callbacks+0x10/0x20) from [<c0029498>] 
(__do_softirq+0xbc/0x194)
[<c0029498>] (__do_softirq+0xbc/0x194) from [<c00295b0>] (run_ksoftirqd+0x40/0x64)
[<c00295b0>] (run_ksoftirqd+0x40/0x64) from [<c0041954>] 
(smpboot_thread_fn+0x150/0x15c)
[<c0041954>] (smpboot_thread_fn+0x150/0x15c) from [<c003bb2c>] (kthread+0xa4/0xb0)
[<c003bb2c>] (kthread+0xa4/0xb0) from [<c0013450>] (ret_from_fork+0x14/0x24)

Here is the call stack for the seccomp filter case:

[<c0087c28>] (vfree+0x28/0x2c) from [<c0060834>] (put_seccomp_filter+0x6c/0x84)
[<c0060834>] (put_seccomp_filter+0x6c/0x84) from [<c0020db4>] 
(free_task+0x30/0x50)
[<c0020db4>] (free_task+0x30/0x50) from [<c0060be4>] 
(__rcu_process_callbacks+0x98/0xac)
[<c0060be4>] (__rcu_process_callbacks+0x98/0xac) from [<c0060c08>] 
(rcu_process_callbacks+0x10/0x20)
[<c0060c08>] (rcu_process_callbacks+0x10/0x20) from [<c00294c8>] 
(__do_softirq+0xbc/0x194)
[<c00294c8>] (__do_softirq+0xbc/0x194) from [<c00295e0>] (run_ksoftirqd+0x40/0x64)
[<c00295e0>] (run_ksoftirqd+0x40/0x64) from [<c0041984>] 
(smpboot_thread_fn+0x150/0x15c)
[<c0041984>] (smpboot_thread_fn+0x150/0x15c) from [<c003bb5c>] (kthread+0xa4/0xb0)
[<c003bb5c>] (kthread+0xa4/0xb0) from [<c0013450>] (ret_from_fork+0x14/0x24)

Regards,

-- 
Nicolas Schichan
Freebox SAS


From lee.jones at linaro.org  Wed Apr 24 11:55:47 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Wed, 24 Apr 2013 16:55:47 +0100
Subject: [PATCH v2] mmc: mmci: Allow MMCI to request channels with
 information acquired from DT
In-Reply-To: <1366801122-13302-1-git-send-email-lee.jones@linaro.org>
References: <1366801122-13302-1-git-send-email-lee.jones@linaro.org>
Message-ID: <20130424155547.GA4623@gmail.com>

Currently, if DMA information isn't passed from platform data, then DMA
will not be used. This patch allows DMA information obtained though Device
Tree to be used as well.

Cc: Russell King <linux at arm.linux.org.uk>
Cc: Chris Ball <cjb at laptop.org>
Cc: linux-mmc at vger.kernel.org
Signed-off-by: Lee Jones <lee.jones at linaro.org>

diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index 372e921..45dda46 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -304,10 +304,8 @@ static void mmci_dma_setup(struct mmci_host *host)
 	const char *rxname, *txname;
 	dma_cap_mask_t mask;
 
-	if (!plat || !plat->dma_filter) {
-		dev_info(mmc_dev(host->mmc), "no DMA platform data\n");
-		return;
-	}
+	host->dma_rx_channel = dma_request_slave_channel(mmc_dev(host->mmc), "rx");
+	host->dma_tx_channel = dma_request_slave_channel(mmc_dev(host->mmc), "tx");
 
 	/* initialize pre request cookie */
 	host->next_data.cookie = 1;
@@ -316,30 +314,33 @@ static void mmci_dma_setup(struct mmci_host *host)
 	dma_cap_zero(mask);
 	dma_cap_set(DMA_SLAVE, mask);
 
-	/*
-	 * If only an RX channel is specified, the driver will
-	 * attempt to use it bidirectionally, however if it is
-	 * is specified but cannot be located, DMA will be disabled.
-	 */
-	if (plat->dma_rx_param) {
-		host->dma_rx_channel = dma_request_channel(mask,
+	if (plat && plat->dma_filter) {
+		if (!host->dma_rx_channel && plat->dma_rx_param) {
+			host->dma_rx_channel = dma_request_channel(mask,
 							   plat->dma_filter,
 							   plat->dma_rx_param);
-		/* E.g if no DMA hardware is present */
-		if (!host->dma_rx_channel)
-			dev_err(mmc_dev(host->mmc), "no RX DMA channel\n");
-	}
+			/* E.g if no DMA hardware is present */
+			if (!host->dma_rx_channel)
+				dev_err(mmc_dev(host->mmc), "no RX DMA channel\n");
+		}
 
-	if (plat->dma_tx_param) {
-		host->dma_tx_channel = dma_request_channel(mask,
+		if (!host->dma_tx_channel && plat->dma_tx_param) {
+			host->dma_tx_channel = dma_request_channel(mask,
 							   plat->dma_filter,
 							   plat->dma_tx_param);
-		if (!host->dma_tx_channel)
-			dev_warn(mmc_dev(host->mmc), "no TX DMA channel\n");
-	} else {
-		host->dma_tx_channel = host->dma_rx_channel;
+			if (!host->dma_tx_channel)
+				dev_warn(mmc_dev(host->mmc), "no TX DMA channel\n");
+		}
 	}
 
+	/*
+	 * If only an RX channel is specified, the driver will
+	 * attempt to use it bidirectionally, however if it is
+	 * is specified but cannot be located, DMA will be disabled.
+	 */
+	if (host->dma_rx_channel && !host->dma_tx_channel)
+		host->dma_tx_channel = host->dma_rx_channel;
+
 	if (host->dma_rx_channel)
 		rxname = dma_chan_name(host->dma_rx_channel);
 	else


From t.figa at samsung.com  Wed Apr 24 11:56:57 2013
From: t.figa at samsung.com (Tomasz Figa)
Date: Wed, 24 Apr 2013 17:56:57 +0200
Subject: [PATCH v3 00/13] ARM: EXYNOS: Fix Universal C210 support
In-Reply-To: <1366731994-7478-1-git-send-email-t.figa@samsung.com>
References: <1366731994-7478-1-git-send-email-t.figa@samsung.com>
Message-ID: <1412451.qIYy1KKdql@amdc1227>

On Tuesday 23 of April 2013 17:46:21 Tomasz Figa wrote:
> This series intends to fix support for Universal C210 board in mainline.
> Main difference from other boards based on Exynos 4210 is that hardware
> revision of the SoC used on Universal C210 does not support MCT timers
> and legacy PWM timers must be used instead.
> 
> First (and the biggest) part of the series deals with cleaning up and
> fixing the samsung_pwm_timer clocksource driver, that was posted
> recently by Arnd. In addition the driver is prepared to share the
> hardware with PWM driver that will be reworked later, since it is not
> a component crucial for system operation.
> 
> Second part fixes ATAGS support of Exynos 4210 rev0 SoC, which needs
> different timer initialization, using the new samsung_pwm_timer driver.
> 
> Third and last part adds Device Tree-based support for Universal C210
> board by providing device tree sources for it.
> 
> On Universal C210 board, both with and without DT:
> 
> Tested-by: Tomasz Figa <t.figa at samsung.com>
> 
> Tomasz Figa (13):
>   Documentation: Add device tree bindings for Samsung PWM timers
>   clocksource: samsung_pwm_timer: Let platforms select the driver
>   clocksource: samsung_pwm_timer: Make PWM spinlock global
>   clocksource: samsung_pwm_timer: Keep all driver data in a structure
>   clocksource: samsung_pwm_timer: Drop unused samsung_pwm struct
>   clocksource: samsung_pwm_timer: Add support for non-DT platforms
>   clocksource: samsung_pwm_timer: Use proper clockevents max_delta
>   clocksource: samsung_pwm_timer: Correct programming of clock events
>   clocksource: samsung_pwm_timer: Work around rounding errors in
>     clockevents core
>   ARM: SAMSUNG: Do not register legacy timer interrupts on Exynos
>   ARM: EXYNOS: Fix support of Exynos4210 rev0 SoC
>   ARM: dts: exynos4: Add node for PWM device
>   ARM: dts: exynos4210: Add basic dts file for universal_c210 board
> 
>  .../devicetree/bindings/pwm/pwm-samsung.txt        |  43 +++
>  arch/arm/boot/dts/Makefile                         |   1 +
>  arch/arm/boot/dts/exynos4.dtsi                     |   8 +
>  arch/arm/boot/dts/exynos4210-universal_c210.dts    | 352
> +++++++++++++++++++++ arch/arm/mach-exynos/Kconfig                       | 
>  3 +-
>  arch/arm/mach-exynos/common.c                      |  45 ++-
>  arch/arm/mach-exynos/common.h                      |   2 +
>  arch/arm/mach-exynos/mach-universal_c210.c         |   5 +-
>  arch/arm/plat-samsung/Kconfig                      |   4 +-
>  drivers/clocksource/Kconfig                        |   3 +-
>  drivers/clocksource/samsung_pwm_timer.c            | 215 +++++++------
>  include/clocksource/samsung_pwm.h                  |  11 +-
>  12 files changed, 561 insertions(+), 131 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/pwm/pwm-samsung.txt
>  create mode 100644 arch/arm/boot/dts/exynos4210-universal_c210.dts

Kgene, could you merge this series and send a pull request, please?

Best regards,
-- 
Tomasz Figa
Samsung Poland R&D Center
SW Solution Development, Kernel and System Framework



From mikedunn at newsguy.com  Wed Apr 24 12:07:17 2013
From: mikedunn at newsguy.com (Mike Dunn)
Date: Wed, 24 Apr 2013 09:07:17 -0700
Subject: gpio-pxa initcall level change and machine init breakage
In-Reply-To: <CAD6h2NSRA9w7GZLQGgK-+TvEAsxwOHow5_26JyVUA6YQyj3OQg@mail.gmail.com>
References: <5172B398.7060706@newsguy.com>
 <CAD6h2NSRA9w7GZLQGgK-+TvEAsxwOHow5_26JyVUA6YQyj3OQg@mail.gmail.com>
Message-ID: <51780335.6030100@newsguy.com>

Linus,

The patch you offered yesterday does not fix things on palmtreo, because there
are calls to gpio_request() in another file (palm27x.c) that are made from
init_machine().  I'd be grateful for any insight into how to resolve this.
Please see below...


On 04/20/2013 11:02 PM, Haojian Zhuang wrote:
> On 20 April 2013 23:26, Mike Dunn <mikedunn at newsguy.com> wrote:
>> Hi,
>>
>> After a few months of neglect, I rebased my palm treo 680 kernel with the latest
>> from Linus' official tree, and now all the calls to gpio lib functions
>> (gpio_request(), etc) made from the init_machine() method in struct machine_desc
>> fail.  I tracked this back to commit 6c7e660a27da7494c670bfba21cfeba30457656c
>> dated Jan 23 2013
>>
>>     gpio: pxa: set initcall level to module init
>>
>>     gpio & pinctrl driver are used together. The pinctrl driver is already
>>     launched before gpio driver in Makefile. So set gpio driver to module
>>     init level. Otherwise, the sequence will be inverted.
>>
>>     Signed-off-by: Haojian Zhuang <haojian.zhuang at linaro.org>
>>     Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
>>
>> At the time, Haojian addressed a question about this patch regarding module
>> dependencies, advising use of the deferred probe infrastructure.  But unless I'm
>> mistaken, mine is an initcall level problem, not a dependency issue among driver
>> probes.  Now that gpio-pxa initialization is at the device level (initcall6),
>> calls to gpiolib are no longer possible from init_machine(), which remains at
>> the initcall3 level.
>>
>> I feel like I must be missing something, because a lot of pxa boards call
>> gpiolib from init machine(), so my breakage should not be an isolated case.
>>
>> If I'm not missing anything and the patch is necessary, it looks like one
>> solution would be to move all the initializations that use gpiolib to the
>> init_late method in struct machine_desc, which runs as initcall7.
>>
>> Grateful for any advice!
>>
>> Thanks,
>> Mike
> 
> Actually gpio request should be handled in the driver, not machine platform
> driver. For example, lcd init may request gpio. pxafb.c provides the callback
> to handle it. We need to move code of requesting gpio into the callback.


It appears that some pxa27x drivers will need to be reworked to accomplish this.
 For example, in the case of the pxa27x lcd driver (pxafb), there are callbacks
for turning the lcd and its backlight on and off, but it seems that the gpios
should have already been requested when these run.  The board-specific gpios
*could* be passed to the pxafb driver via platform_data, and the driver could
request them in its probe function, but currently this is not done.

Moving gpiolib calls to init_late() in struct machine_desc, which runs as
initcall7, may also be a solution.


> 
> Since this change breaks current platform, we have to revert it. We still need
> a code cleanup in arch-pxa directory.


Indeed, if I'm not mistaken, at least these boards are now broken:
  - tosa
  - baloon3
  - gumstix
  - hx4700
  - magician
  - mioa701
  - palmtreo/palmcentro
  - palmld
  - palmtc
  - palmz72


> 
> Linus,
> Could you help to revert this commit? Or do I need to send a revert commit
> to you?
> 

Thanks,
Mike


From mturquette at linaro.org  Wed Apr 24 12:28:47 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Wed, 24 Apr 2013 09:28:47 -0700
Subject: [PATCH V4 1/6] clk: OMAP: introduce device tree binding to kernel
 clock data
In-Reply-To: <20130414211917.GA3275@snafu>
References: <1365807278-554-1-git-send-email-nm@ti.com>
 <1365807278-554-2-git-send-email-nm@ti.com>
 <20130412233142.GE10155@atomide.com> <20130412233900.GA1599@kahuna>
 <20130413172210.GM10155@atomide.com> <20130414211917.GA3275@snafu>
Message-ID: <20130424162847.8998.73264@quantum>

Quoting Nishanth Menon (2013-04-14 14:19:17)
> Overall strategy introduced here is simple: a clock node described in
> device tree blob is used to identify the exact clock provided in the
> SoC specific data. This is then linked back using of_clk_add_provider
> to the device node to be accessible by of_clk_get.
> 
> Based on discussion contributions from Roger Quadros, Grygorii Strashko
> and others.
> 
> Cc: Kevin Hilman <khilman at deeprootsystems.com>
> Cc: Mike Turquette <mturquette at linaro.org>
> Cc: Paul Walmsley <paul at pwsan.com>
> [tony at atomide.com: co-developed]
> Signed-off-by: Tony Lindgren <tony at atomide.com>
> Signed-off-by: Nishanth Menon <nm at ti.com>

I can take this into clk-next after the merge window.  Please refresh it
for -rc1 as we discussed on irc.

As an aside, will Tero's series for migrating to drivers/clk/omap[1] and
Rajendra's patch for registering clocks late[2] be refreshed after the
merge window?  It would be nice to combine these efforts.

Thanks,
Mike

[1] http://article.gmane.org/gmane.linux.ports.arm.omap/95948
[2] http://www.spinics.net/lists/arm-kernel/msg231288.html


From pawel.moll at arm.com  Wed Apr 24 12:31:24 2013
From: pawel.moll at arm.com (Pawel Moll)
Date: Wed, 24 Apr 2013 17:31:24 +0100
Subject: [PATCH] mfd: vexpress: Handle pending config transactions
Message-ID: <1366821084-12815-1-git-send-email-pawel.moll@arm.com>

The config transactions "scheduler" was hopelessly broken,
repeating completed transaction instead of picking up
next pending one.

Fixed now. Also improved debug messages.

Signed-off-by: Pawel Moll <pawel.moll at arm.com>
---
 drivers/mfd/vexpress-config.c |   31 ++++++++++++++++++++-----------
 1 file changed, 20 insertions(+), 11 deletions(-)

diff --git a/drivers/mfd/vexpress-config.c b/drivers/mfd/vexpress-config.c
index 3c1723aa..4991db3 100644
--- a/drivers/mfd/vexpress-config.c
+++ b/drivers/mfd/vexpress-config.c
@@ -184,13 +184,14 @@ static int vexpress_config_schedule(struct vexpress_config_trans *trans)
 
 	spin_lock_irqsave(&bridge->transactions_lock, flags);
 
-	vexpress_config_dump_trans("Executing", trans);
-
-	if (list_empty(&bridge->transactions))
+	if (list_empty(&bridge->transactions)) {
+		vexpress_config_dump_trans("Executing", trans);
 		status = bridge->info->func_exec(trans->func->func,
 				trans->offset, trans->write, trans->data);
-	else
+	} else {
+		vexpress_config_dump_trans("Queuing", trans);
 		status = VEXPRESS_CONFIG_STATUS_WAIT;
+	}
 
 	switch (status) {
 	case VEXPRESS_CONFIG_STATUS_DONE:
@@ -217,20 +218,28 @@ void vexpress_config_complete(struct vexpress_config_bridge *bridge,
 
 	trans = list_first_entry(&bridge->transactions,
 			struct vexpress_config_trans, list);
+	trans->status = status;
 	vexpress_config_dump_trans("Completed", trans);
 
-	trans->status = status;
 	list_del(&trans->list);
 
-	if (!list_empty(&bridge->transactions)) {
-		vexpress_config_dump_trans("Pending", trans);
+	complete(&trans->completion);
+
+	while (!list_empty(&bridge->transactions)) {
+		trans = list_first_entry(&bridge->transactions,
+				struct vexpress_config_trans, list);
 
-		bridge->info->func_exec(trans->func->func, trans->offset,
-				trans->write, trans->data);
+		vexpress_config_dump_trans("Executing pending", trans);
+		status = bridge->info->func_exec(trans->func->func,
+				trans->offset, trans->write, trans->data);
+
+		if (status == VEXPRESS_CONFIG_STATUS_DONE)
+			vexpress_config_dump_trans("Finished pending", trans);
+		else
+			break;
 	}
-	spin_unlock_irqrestore(&bridge->transactions_lock, flags);
 
-	complete(&trans->completion);
+	spin_unlock_irqrestore(&bridge->transactions_lock, flags);
 }
 EXPORT_SYMBOL(vexpress_config_complete);
 
-- 
1.7.10.4




From cdall at cs.columbia.edu  Wed Apr 24 12:46:57 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Wed, 24 Apr 2013 09:46:57 -0700
Subject: [PATCH v3 07/32] arm64: KVM: fault injection into a guest
In-Reply-To: <5177AE16.6080509@arm.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
 <1365437854-30214-8-git-send-email-marc.zyngier@arm.com>
 <20130423225758.GB20569@gmail.com> <5177AE16.6080509@arm.com>
Message-ID: <CAEDV+gJverKr2wKV__bMTWT2ePrEmZjXzWhOcwu4Hb4HN3wjjQ@mail.gmail.com>

On Wed, Apr 24, 2013 at 3:04 AM, Marc Zyngier <marc.zyngier at arm.com> wrote:
> On 23/04/13 23:57, Christoffer Dall wrote:
>> On Mon, Apr 08, 2013 at 05:17:09PM +0100, Marc Zyngier wrote:
>>> Implement the injection of a fault (undefined, data abort or
>>> prefetch abort) into a 64bit guest.
>>>
>>> Reviewed-by: Christopher Covington <cov at codeaurora.org>
>>> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
>>> ---
>>>  arch/arm64/kvm/inject_fault.c | 118 ++++++++++++++++++++++++++++++++++++++++++
>>>  1 file changed, 118 insertions(+)
>>>  create mode 100644 arch/arm64/kvm/inject_fault.c
>>>
>>> diff --git a/arch/arm64/kvm/inject_fault.c b/arch/arm64/kvm/inject_fault.c
>>> new file mode 100644
>>> index 0000000..2ff3b78
>>> --- /dev/null
>>> +++ b/arch/arm64/kvm/inject_fault.c
>>> @@ -0,0 +1,118 @@
>>> +/*
>>> + * Fault injection for 64bit guests.
>>> + *
>>> + * Copyright (C) 2012,2013 - ARM Ltd
>>> + * Author: Marc Zyngier <marc.zyngier at arm.com>
>>> + *
>>> + * Based on arch/arm/kvm/emulate.c
>>> + * Copyright (C) 2012 - Virtual Open Systems and Columbia University
>>> + * Author: Christoffer Dall <c.dall at virtualopensystems.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.
>>> + *
>>> + * This program is distributed in the hope that it will be useful,
>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>>> + * GNU General Public License for more details.
>>> + *
>>> + * You should have received a copy of the GNU General Public License
>>> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
>>> + */
>>> +
>>> +#include <linux/kvm_host.h>
>>> +#include <asm/kvm_emulate.h>
>>> +#include <asm/esr.h>
>>> +
>>> +static void inject_abt64(struct kvm_vcpu *vcpu, bool is_iabt, unsigned long addr)
>>> +{
>>> +    unsigned long cpsr = *vcpu_cpsr(vcpu);
>>> +    int is_aarch32;
>>> +    u32 esr = 0;
>>> +
>>> +    is_aarch32 = vcpu_mode_is_32bit(vcpu);
>>> +
>>> +    *vcpu_spsr(vcpu) = cpsr;
>>> +    *vcpu_elr_el1(vcpu) = *vcpu_pc(vcpu);
>>> +
>>> +    *vcpu_cpsr(vcpu) = PSR_MODE_EL1h | PSR_A_BIT | PSR_F_BIT | PSR_I_BIT;
>>> +    *vcpu_pc(vcpu) = vcpu_sys_reg(vcpu, VBAR_EL1) + 0x200;
>>
>> consider a define for the 0x200?
>
> Yeah, I think Will already mentioned this.
>
>>> +
>>> +    vcpu_sys_reg(vcpu, FAR_EL1) = addr;
>>> +
>>> +    /*
>>> +     * Build an {i,d}abort, depending on the level and the
>>> +     * instruction set. Report an external synchronous abort.
>>> +     */
>>> +    if (kvm_vcpu_trap_il_is32bit(vcpu))
>>> +            esr |= ESR_EL1_IL;
>>> +
>>> +    if (is_aarch32 || (cpsr & PSR_MODE_MASK) == PSR_MODE_EL0t)
>>> +            esr |= (ESR_EL1_EC_IABT_EL0 << ESR_EL1_EC_SHIFT);
>>> +    else
>>> +            esr |= (ESR_EL1_EC_IABT_EL1 << ESR_EL1_EC_SHIFT);
>>
>> why is it assumed that the abort must come from EL0 if the vcpu is in
>> aarch32 mode?
>
> We're injecting a fault into a VM that runs with a 64bit EL1. So if we
> end-up faulting in 32bit code, it must come from EL0.
>

ah ok, it could be mentioned in a comment, but meh...

>>> +
>>> +    if (!is_iabt)
>>> +            esr |= ESR_EL1_EC_DABT_EL0;
>>
>> this is slightly confusing unless you actually look at the definitions
>> and realize that or'ing on that extra bit works both in i- and d-abt
>> cases.
>
> Blame Christopher for that, he came up with the idea... ;-)
>

I think this is one of those cases where the compiler should be this
smart, and C should be a little more verbose, but it's not a cardinal
point.

>>> +
>>> +    vcpu_sys_reg(vcpu, ESR_EL1) = esr | 0x10; /* External abort */
>>> +}
>>> +
>>> +static void inject_undef64(struct kvm_vcpu *vcpu)
>>> +{
>>> +    unsigned long cpsr = *vcpu_cpsr(vcpu);
>>> +    u32 esr = (ESR_EL1_EC_UNKNOWN << ESR_EL1_EC_SHIFT);
>>> +
>>> +    *vcpu_spsr(vcpu) = cpsr;
>>> +    *vcpu_elr_el1(vcpu) = *vcpu_pc(vcpu);
>>> +
>>> +    *vcpu_cpsr(vcpu) = PSR_MODE_EL1h | PSR_F_BIT | PSR_I_BIT;
>>
>> would it make sense to have a define for a common set of these bits or
>> is this explicitly defined per exception type in the specs?
>
> Maybe. Not sure that would be any clearer though...
>
>         M.
> --
> Jazz is not dead. It just smells funny...
>
>
> _______________________________________________
> kvmarm mailing list
> kvmarm at lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm


From tony at atomide.com  Wed Apr 24 12:50:05 2013
From: tony at atomide.com (Tony Lindgren)
Date: Wed, 24 Apr 2013 09:50:05 -0700
Subject: [GIT PULL] omap dss board clean-up for v3.10 merge window
In-Reply-To: <5177902C.5070407@ti.com>
References: <20130418033936.GC10155@atomide.com>
 <20130419184518.GA30836@quad.lixom.net> <5174F593.20705@ti.com>
 <20130423171438.GC10155@atomide.com> <5177902C.5070407@ti.com>
Message-ID: <20130424165005.GA5184@atomide.com>

* Tomi Valkeinen <tomi.valkeinen at ti.com> [130424 01:01]:
> On 2013-04-23 20:14, Tony Lindgren wrote:
> > * Tomi Valkeinen <tomi.valkeinen at ti.com> [130422 01:37]:
> 
> >> So while I think it is a good habit to push the arch changes and driver
> >> changes separately, my question is, should that rule be followed to the
> >> extreme? Can I just keep all the changes in one branch if separating the
> >> arch and driver changes would end up with cloning files or lots of extra
> >> code?
> > 
> > Shread branches are just fine. In most cases it's possible to add new
> > pdata and then remove the old pdata later on with follow-up patches.
> 
> Yes, that's what I've been doing. But it's not possible in all cases,
> and in some cases it's just really difficult/laborious.
> 
> I'll soon need to change the dss panel device model, and the only way I
> can see that would allow us to keep everything running if only arch or
> driver changes are merged, is to create a copy of all the omap display
> drivers, and change the copy for the new dss device model.
>
> And that's obviously a terrible way to do it.

Yes that is the case if you have to completely redo the pdata and
cannot get away by just changing the existing pdata.
 
> So presuming I need to have the dss changes in separate arch and driver
> series, and everything should run fine even if only the other half is
> merged, then, well, I have no idea how to proceed. I'll continue looking
> at this, but it's a bit frustrating to spend most of my time trying to
> twist the code to accommodate the merging process, instead of making the
> code work.
>
> That said, this dss device model change should be a one time thing.
> After it's done, these merging-problems should be greatly reduced.

Right, if it's more complex than just changing the pdata then what you've
been doing is probably the best approach. Just needs to be done earlier :)
 
> >> Of course, I don't know what DRM maintainer thinks of merging arch
> >> changes through his tree, so that's also open.
> > 
> > No let's not go there, Linus T already complained about the conflicts
> > between drivers/net and arch/arm/*omap*/ code few merge windows ago.
> > We need to remove the driver dependencies to the arch/arm code, otherwise
> > the merging requires way too much work from multiple maintainers. That
> > does not scale well and often leads into merge errors that could have
> > been avoided in the first place.
> > 
> > Of course the real solution here is to get things moved over to DT
> > based booting and then we don't have any of these dependencies as the
> > .dts changes can get merged separately from the driver changes.
> 
> It will remove compile time dependencies, but we'll still have runtime
> dependencies just like we do now.

Only for adding new features. If the new features are missing from the
.dts changes, the driver should still work with limited features. The
idea is to support DT bindings in the long term.

Regards,

Tony


From cdall at cs.columbia.edu  Wed Apr 24 12:50:38 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Wed, 24 Apr 2013 09:50:38 -0700
Subject: [PATCH v3 08/32] arm64: KVM: architecture specific MMU backend
In-Reply-To: <20130424111002.GJ21850@mudshark.cambridge.arm.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
 <1365437854-30214-9-git-send-email-marc.zyngier@arm.com>
 <20130423225816.GC20569@gmail.com> <5177BBEE.1090209@arm.com>
 <20130424111002.GJ21850@mudshark.cambridge.arm.com>
Message-ID: <CAEDV+gJAyE2teK963iMYujPmyY0fqSZ7kQmq5CiKwvxNKm=SWA@mail.gmail.com>

On Wed, Apr 24, 2013 at 4:10 AM, Will Deacon <will.deacon at arm.com> wrote:
> On Wed, Apr 24, 2013 at 12:03:10PM +0100, Marc Zyngier wrote:
>> On 23/04/13 23:58, Christoffer Dall wrote:
>> > I noticed that this doesn't do any cache cleaning.  Are the MMU page
>> > table walks guaranteed to be coherent with the MMU on arm64?
>>
>> I suppose you meant the cache. In this case, yes. The hardware page
>> table walker must snoop the caches.
>
> Also, for ARMv7, SMP implies that the hardware walker snoops the cache. I
> recently upstreamed some patches for this (see "ARM: 7691/1: mm: kill unused
> TLB_CAN_READ_FROM_L1_CACHE and use ALT_SMP instead" in -next), so you might
> want to check if there are any remaining, redundant flushes in kvm for ARMv7.
>
always on SMP? I thought this was implementation specific and you
could read this in some feature register?

In any case, I'm quite sure we do some unnecessary cleaning in KVM
then, so I'll look at it.


From khilman at linaro.org  Wed Apr 24 12:55:27 2013
From: khilman at linaro.org (Kevin Hilman)
Date: Wed, 24 Apr 2013 09:55:27 -0700
Subject: [PATCH] cpuidle: add maintainer entry
In-Reply-To: <1366810463-17495-1-git-send-email-daniel.lezcano@linaro.org>
 (Daniel Lezcano's message of "Wed, 24 Apr 2013 15:34:23 +0200")
References: <1366810463-17495-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <87k3nr50n4.fsf@linaro.org>

Rafael,

Daniel Lezcano <daniel.lezcano at linaro.org> writes:

[...]

> diff --git a/MAINTAINERS b/MAINTAINERS
> index 61677c3..effa0f3 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2206,6 +2206,13 @@ S:	Maintained
>  F:	drivers/cpufreq/
>  F:	include/linux/cpufreq.h
>  
> +CPUIDLE DRIVERS
> +M:	Rafael J. Wysocki <rjw at sisk.pl>
> +L:	linux-pm at vger.kernel.org
> +S:	Maintained
> +F:	drivers/cpuidle/*
> +F:	include/linux/cpuidle.h

What do you think about having Daniel listed here as a co-maintainer?

He has been driving a significant consolidation effort, and will
continue to do that, so I think he should help take care of this area
and ensure all drivers are moving in the right direction.

Kevin


From cdall at cs.columbia.edu  Wed Apr 24 12:55:57 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Wed, 24 Apr 2013 09:55:57 -0700
Subject: [PATCH v3 08/32] arm64: KVM: architecture specific MMU backend
In-Reply-To: <5177BBEE.1090209@arm.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
 <1365437854-30214-9-git-send-email-marc.zyngier@arm.com>
 <20130423225816.GC20569@gmail.com> <5177BBEE.1090209@arm.com>
Message-ID: <CAEDV+g+H+NFc5gsQYBmQDx598Oz3BHWHcrYhBYsWPbXaVYataA@mail.gmail.com>

On Wed, Apr 24, 2013 at 4:03 AM, Marc Zyngier <marc.zyngier at arm.com> wrote:
> On 23/04/13 23:58, Christoffer Dall wrote:
>> On Mon, Apr 08, 2013 at 05:17:10PM +0100, Marc Zyngier wrote:
>>> Define the arm64 specific MMU backend:
>>> - HYP/kernel VA offset
>>> - S2 4/64kB definitions
>>> - S2 page table populating and flushing
>>> - icache cleaning
>>>
>>> Reviewed-by: Christopher Covington <cov at codeaurora.org>
>>> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
>>> ---
>>>  arch/arm64/include/asm/kvm_mmu.h | 136 +++++++++++++++++++++++++++++++++++++++
>>>  1 file changed, 136 insertions(+)
>>>  create mode 100644 arch/arm64/include/asm/kvm_mmu.h
>>>
>>> diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h
>>> new file mode 100644
>>> index 0000000..2eb2230
>>> --- /dev/null
>>> +++ b/arch/arm64/include/asm/kvm_mmu.h
>>> @@ -0,0 +1,136 @@
>>> +/*
>>> + * Copyright (C) 2012,2013 - ARM Ltd
>>> + * Author: Marc Zyngier <marc.zyngier at arm.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.
>>> + *
>>> + * This program is distributed in the hope that it will be useful,
>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>>> + * GNU General Public License for more details.
>>> + *
>>> + * You should have received a copy of the GNU General Public License
>>> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
>>> + */
>>> +
>>> +#ifndef __ARM64_KVM_MMU_H__
>>> +#define __ARM64_KVM_MMU_H__
>>> +
>>> +#include <asm/page.h>
>>> +#include <asm/memory.h>
>>> +
>>> +/*
>>> + * As we only have the TTBR0_EL2 register, we cannot express
>>> + * "negative" addresses. This makes it impossible to directly share
>>> + * mappings with the kernel.
>>> + *
>>> + * Instead, give the HYP mode its own VA region at a fixed offset from
>>> + * the kernel by just masking the top bits (which are all ones for a
>>> + * kernel address).
>>
>> For some reason I keep choking on this, despite it being very simple.
>> We're just defining a different PAGE_OFFSET, right? Why not do a hard
>> define as:
>>
>> #define HYP_PAGE_OFFSET_MASK  0x0000ffffffffffff
>> #define HYP_PAGE_OFFSET               0x0000ffc000000000
>>
>> ...or change the second paragraph of the comment to say
>> that we definethe HYP_PAGE_OFFSET to be 0x 0000ffc0 00000000.
>
> One of these days, VA_BITS will change to accommodate for more virtual
> space. When that day comes, I don't want to touch any of this because it
> did hurt enough when writing it. As such, I'll refrain from hardcoding
> anything.
>
> I don't mind a comment, though.
>
>>> + */
>>> +#define HYP_PAGE_OFFSET_SHIFT       VA_BITS
>>> +#define HYP_PAGE_OFFSET_MASK        ((UL(1) << HYP_PAGE_OFFSET_SHIFT) - 1)
>>
>> In any case, is there a reason for the HYP_PAGE_OFFSET_SHIFT
>> indirection? It may be simpler without...
>
> It is common practice to have XXX_SHIFT and XXX_MASK together.
>
>>> +#define HYP_PAGE_OFFSET             (PAGE_OFFSET & HYP_PAGE_OFFSET_MASK)
>>> +
>>> +/*
>>> + * Our virtual mapping for the idmap-ed MMU-enable code. Must be
>>> + * shared across all the page-tables. Conveniently, we use the last
>>> + * possible page, where no kernel mapping will ever exist.
>>> + */
>>> +#define TRAMPOLINE_VA               (HYP_PAGE_OFFSET_MASK & PAGE_MASK)
>>
>> hmmm, ok, here it's kind of nice to have that define correlation, so
>> maybe it's not cleaner.  Something should be improved here in the define
>> or the comment to make it more clear.  Perhaps just adding the real
>> constants in the comment or in Documentation/arm64/memory.txt would
>> help.
>
> Yes, I plan to write something there.
>
>>> +
>>> +#ifdef __ASSEMBLY__
>>> +
>>> +/*
>>> + * Convert a kernel VA into a HYP VA.
>>> + * reg: VA to be converted.
>>> + */
>>> +.macro kern_hyp_va  reg
>>> +    and     \reg, \reg, #HYP_PAGE_OFFSET_MASK
>>> +.endm
>>> +
>>> +#else
>>> +
>>> +#include <asm/cacheflush.h>
>>> +
>>> +#define KERN_TO_HYP(kva)    ((unsigned long)kva - PAGE_OFFSET + HYP_PAGE_OFFSET)
>>> +
>>> +/*
>>> + * Align KVM with the kernel's view of physical memory. Should be
>>> + * 40bit IPA, with PGD being 8kB aligned.
>>> + */
>>> +#define KVM_PHYS_SHIFT      PHYS_MASK_SHIFT
>>> +#define KVM_PHYS_SIZE       (1UL << KVM_PHYS_SHIFT)
>>> +#define KVM_PHYS_MASK       (KVM_PHYS_SIZE - 1UL)
>>> +
>>> +#ifdef CONFIG_ARM64_64K_PAGES
>>> +#define PAGE_LEVELS 2
>>> +#define BITS_PER_LEVEL      13
>>> +#else  /* 4kB pages */
>>> +#define PAGE_LEVELS 3
>>> +#define BITS_PER_LEVEL      9
>>> +#endif
>>
>> What are the semantics of these defines exactly? They should be
>> S2_PAGE_LEVELS and make some assumptions of the VTCR_EL2.SL0 field
>> right?
>
> Indeed, we assume SL0 is always 1, just like for the kernel. As for the
> semantics, I though they were pretty obvious...
>

this is all stage2 right? so S2_PAGE_LEVELS may be more clear...

> PAGE_LEVELS is just that, the number of page levels. BITS_PER_LEVEL is
> the number of bits you need to index a particular level.
>
>>> +
>>> +/* Make sure we get the right size, and thus the right alignment */
>>
>> this comment is not particularly helpful, something explaining why the
>> max() thingy below makes sense would be more so :)  I really can't
>> follow the BITS_PER_S2_PGD and PTRS_PER_S2_PGD defines.
>
> Admittedly, they are a bit convoluted:
>
>>> +#define BITS_PER_S2_PGD (KVM_PHYS_SHIFT - (PAGE_LEVELS - 1) * BITS_PER_LEVEL - PAGE_SHIFT)
>
> This is how many bits of index you need in a PGD. With a 40bit IPA and a
> 4kB page size, you end up with a 10 bit index.
>

oh, I see it now, you're basically taking away all the other bits you
know are used to find your address and consider the remaining amount
the necessary number of bits used to index into the PGD. Right? So I
think at least a comment saying that BITS_ indicates bits used for
indexing, not bits for a single entry or something else...

>>> +#define PTRS_PER_S2_PGD (1 << max(BITS_PER_LEVEL, BITS_PER_S2_PGD))
>
> Now, in order to allocate your PGD, you need to find out how many
> pointers your PGD is going to contain. The max() is make sure we
> allocate at least a full page worth of pointers.

I still don't get this, sorry. Can you provide me with the sane
counter example where BITS_PER_S2_PGD is not sufficient?

>
>>> +#define S2_PGD_ORDER        get_order(PTRS_PER_S2_PGD * sizeof(pgd_t))
>>> +#define S2_PGD_SIZE (1 << S2_PGD_ORDER)
>>> +
>>> +int create_hyp_mappings(void *from, void *to);
>>> +int create_hyp_io_mappings(void *from, void *to, phys_addr_t);
>>> +void free_hyp_pgds(void);
>>> +
>>> +int kvm_alloc_stage2_pgd(struct kvm *kvm);
>>> +void kvm_free_stage2_pgd(struct kvm *kvm);
>>> +int kvm_phys_addr_ioremap(struct kvm *kvm, phys_addr_t guest_ipa,
>>> +                      phys_addr_t pa, unsigned long size);
>>> +
>>> +int kvm_handle_guest_abort(struct kvm_vcpu *vcpu, struct kvm_run *run);
>>> +
>>> +void kvm_mmu_free_memory_caches(struct kvm_vcpu *vcpu);
>>> +
>>> +phys_addr_t kvm_mmu_get_httbr(void);
>>> +phys_addr_t kvm_mmu_get_boot_httbr(void);
>>> +phys_addr_t kvm_get_idmap_vector(void);
>>> +int kvm_mmu_init(void);
>>> +void kvm_clear_hyp_idmap(void);
>>> +
>>> +#define     kvm_set_pte(ptep, pte)          set_pte(ptep, pte)
>>
>> I noticed that this doesn't do any cache cleaning.  Are the MMU page
>> table walks guaranteed to be coherent with the MMU on arm64?
>
> I suppose you meant the cache. In this case, yes. The hardware page
> table walker must snoop the caches.
>

yes, that's what I meant. thanks.


From cdall at cs.columbia.edu  Wed Apr 24 13:05:57 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Wed, 24 Apr 2013 10:05:57 -0700
Subject: [PATCH v3 15/32] arm64: KVM: guest one-reg interface
In-Reply-To: <5177C1AB.3090301@arm.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
 <1365437854-30214-16-git-send-email-marc.zyngier@arm.com>
 <20130423225937.GE20569@gmail.com> <5177C1AB.3090301@arm.com>
Message-ID: <CAEDV+gKOTfkmMm9cRwcfSVCVe5rUpeZN979KFb+pyVj_obM3Bg@mail.gmail.com>

On Wed, Apr 24, 2013 at 4:27 AM, Marc Zyngier <marc.zyngier at arm.com> wrote:
> On 23/04/13 23:59, Christoffer Dall wrote:
>> On Mon, Apr 08, 2013 at 05:17:17PM +0100, Marc Zyngier wrote:
>>> Let userspace play with the guest registers.
>>>
>>> Reviewed-by: Christopher Covington <cov at codeaurora.org>
>>> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
>>> ---
>>>  arch/arm64/kvm/guest.c | 254 +++++++++++++++++++++++++++++++++++++++++++++++++
>>>  1 file changed, 254 insertions(+)
>>>  create mode 100644 arch/arm64/kvm/guest.c
>>>
>>> diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
>>> new file mode 100644
>>> index 0000000..47d3729
>>> --- /dev/null
>>> +++ b/arch/arm64/kvm/guest.c
>>> @@ -0,0 +1,254 @@
>>> +/*
>>> + * Copyright (C) 2012,2013 - ARM Ltd
>>> + * Author: Marc Zyngier <marc.zyngier at arm.com>
>>> + *
>>> + * Derived from arch/arm/kvm/guest.c:
>>> + * Copyright (C) 2012 - Virtual Open Systems and Columbia University
>>> + * Author: Christoffer Dall <c.dall at virtualopensystems.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.
>>> + *
>>> + * This program is distributed in the hope that it will be useful,
>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>>> + * GNU General Public License for more details.
>>> + *
>>> + * You should have received a copy of the GNU General Public License
>>> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
>>> + */
>>> +
>>> +#include <linux/errno.h>
>>> +#include <linux/err.h>
>>> +#include <linux/kvm_host.h>
>>> +#include <linux/module.h>
>>> +#include <linux/vmalloc.h>
>>> +#include <linux/fs.h>
>>> +#include <asm/cputype.h>
>>> +#include <asm/uaccess.h>
>>> +#include <asm/kvm.h>
>>> +#include <asm/kvm_asm.h>
>>> +#include <asm/kvm_emulate.h>
>>> +#include <asm/kvm_coproc.h>
>>> +
>>> +struct kvm_stats_debugfs_item debugfs_entries[] = {
>>> +    { NULL }
>>> +};
>>> +
>>> +int kvm_arch_vcpu_setup(struct kvm_vcpu *vcpu)
>>> +{
>>> +    vcpu->arch.hcr_el2 = HCR_GUEST_FLAGS;
>>> +    return 0;
>>> +}
>>> +
>>> +static u64 core_reg_offset_from_id(u64 id)
>>> +{
>>> +    return id & ~(KVM_REG_ARCH_MASK | KVM_REG_SIZE_MASK | KVM_REG_ARM_CORE);
>>> +}
>>> +
>>> +static int get_core_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
>>> +{
>>> +    __u32 __user *uaddr = (__u32 __user *)(unsigned long)reg->addr;
>>> +    struct kvm_regs *regs = vcpu_gp_regs(vcpu);
>>> +    int nr_regs = sizeof(*regs) / sizeof(__u32);
>>
>> eh, arent' your regs 64 bit?  Or are you 32-bit indexing into a 64-bit
>> structure?  If so, this needs to be described in a big fat comment
>> somewhere, which I couldn't even see looking forward in the patch series
>> for the documentation part.
>
> As you noticed below, we have a mix of 32/64/128bit fields there. The
> index is indeed on 32bit boundary.
>
>> Seems to me you'd want to remove the fp_regs from the core regs and just
>> use a 64-bit indexing and have a separate category for the fp stuff...
>
> Hell no! ;-)

easy now

>
> FP is mandatory on arm64, and I'm not going down the road of having
> separate structures for that. 32bit has historical baggage to deal with,
> but not arm64.
>
> This is the register set, and if the ONE_REG API is too cumbersome to
> deal with it, then lets change ONE_REG instead (yes, I can run faster
> than you think... ;-).
>

You chose yourself how to use the fields in ONE_REG, and that's what I
think makes this code a little weird, I don't care that much how the
underlying structure is.  The fact that we (Rusty) used the index into
the 32 bit fields was simply that it was more convenient and quite
unambiguous on the 32-bit side, as opposed to defining in the API
document a specific ID for each register, like the PPC stuff does.

You don't have to follow that on arm64 if it doesn't make sense.
Notice that in the documentation on arm32 (although it had errors in
there) we explicitly specify that all sizes must be 32 bit, so you
need to change that to indicate that it's a variable size and they use
a 32 bit index into variably sized elements, which I think is a super
funky interface, or change it to split it up into more sane categories
and map that onto your internal data structure.

>>> +    u32 off;
>>> +
>>> +    /* Our ID is an index into the kvm_regs struct. */
>>> +    off = core_reg_offset_from_id(reg->id);
>>> +    if (off >= nr_regs ||
>>> +        (off + (KVM_REG_SIZE(reg->id) / sizeof(__u32))) >= nr_regs)
>>
>> According to your documentation you will always save/restore 32-bit
>> registers here, so the desijunction shouldn't be necessary, nor will it
>> be if you just base everything on 64-bit here.
>
> No. Your *offset* is a 32bit index. The size can be anything, and you
> want to make sure you don't read/write past the kvm_regs structure.
>

I see why you need it as things stand now, my point is that if the
interface definition was different you probably don't need it.

>>> +            return -ENOENT;
>>> +
>>> +    if (copy_to_user(uaddr, ((u32 *)regs) + off, KVM_REG_SIZE(reg->id)))
>>> +            return -EFAULT;
>>> +
>>> +    return 0;
>>> +}
>>> +
>>> +static int set_core_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
>>> +{
>>> +    __u32 __user *uaddr = (__u32 __user *)(unsigned long)reg->addr;
>>> +    struct kvm_regs *regs = vcpu_gp_regs(vcpu);
>>> +    int nr_regs = sizeof(*regs) / sizeof(__u32);
>>
>> same concern here
>
> Same answer.
>
>>
>>> +    void *valp;
>>> +    u64 off;
>>> +    int err = 0;
>>> +
>>> +    /* Our ID is an index into the kvm_regs struct. */
>>> +    off = core_reg_offset_from_id(reg->id);
>>> +    if (off >= nr_regs ||
>>> +        (off + (KVM_REG_SIZE(reg->id) / sizeof(__u32))) >= nr_regs)
>>> +            return -ENOENT;
>>> +
>>> +    valp = kmalloc(KVM_REG_SIZE(reg->id), GFP_KERNEL);
>>> +    if (!valp)
>>> +            return -ENOMEM;
>>
>> Why are you dynamically allocating this?  Do you ever have anything
>> larger than a 64 bit core register? Just put that on the stack.
>
> Look at what a ONE_REG access can be: up to 1kB. I'm not allocating that
> on the stack.
>

Of course not, but you don't have 1KB registers do you? You probably
don't want user space accessing your 64 bit regs with a 1KB size, 128
bits should be allocatable on the stack.

>>> +
>>> +    if (copy_from_user(valp, uaddr, KVM_REG_SIZE(reg->id))) {
>>> +            err = -EFAULT;
>>> +            goto out;
>>> +    }
>>> +
>>> +    if (off == KVM_REG_ARM_CORE_REG(regs.pstate)) {
>>> +            unsigned long mode = (*(unsigned long *)valp) & COMPAT_PSR_MODE_MASK;
>>> +            switch (mode) {
>>> +            case PSR_MODE_EL0t:
>>> +            case PSR_MODE_EL1t:
>>> +            case PSR_MODE_EL1h:
>>> +                    break;
>>> +            default:
>>> +                    err = -EINVAL;
>>> +                    goto out;
>>> +            }
>>> +    }
>>> +
>>> +    memcpy((u32 *)regs + off, valp, KVM_REG_SIZE(reg->id));
>>> +out:
>>> +    kfree(valp);
>>> +    return err;
>>> +}
>>> +
>>> +int kvm_arch_vcpu_ioctl_get_regs(struct kvm_vcpu *vcpu, struct kvm_regs *regs)
>>> +{
>>> +    return -EINVAL;
>>> +}
>>> +
>>> +int kvm_arch_vcpu_ioctl_set_regs(struct kvm_vcpu *vcpu, struct kvm_regs *regs)
>>> +{
>>> +    return -EINVAL;
>>> +}
>>> +
>>> +static unsigned long num_core_regs(void)
>>> +{
>>> +    return sizeof(struct kvm_regs) / sizeof(unsigned long);
>>> +}
>>> +
>>> +/**
>>> + * kvm_arm_num_regs - how many registers do we present via KVM_GET_ONE_REG
>>> + *
>>> + * This is for all registers.
>>> + */
>>> +unsigned long kvm_arm_num_regs(struct kvm_vcpu *vcpu)
>>> +{
>>> +    return num_core_regs() + kvm_arm_num_sys_reg_descs(vcpu);
>>> +}
>>> +
>>> +/**
>>> + * kvm_arm_copy_reg_indices - get indices of all registers.
>>> + *
>>> + * We do core registers right here, then we apppend system regs.
>>> + */
>>> +int kvm_arm_copy_reg_indices(struct kvm_vcpu *vcpu, u64 __user *uindices)
>>> +{
>>> +    unsigned int i;
>>> +    const u64 core_reg = KVM_REG_ARM64 | KVM_REG_SIZE_U64 | KVM_REG_ARM_CORE;
>>> +
>>> +    for (i = 0; i < sizeof(struct kvm_regs)/sizeof(unsigned long); i++) {
>>
>> nit: spaces around the division
>> nit: the kvm_regs struct uses __u64, so would be slightly more coherent
>>      to use that for the sizeof(...) as well
>
> Actually, it should be __u32, as that is an index into the kvm_regs
> structure.
>
again, I can only repeat that I think this all becomes quite unintuitive.


From simon.guinot at sequanux.org  Wed Apr 24 13:06:46 2013
From: simon.guinot at sequanux.org (Simon Guinot)
Date: Wed, 24 Apr 2013 19:06:46 +0200
Subject: [PATCHv1 1/3] hwmon: Add support for GMT G762/G763 PWM fan
 controller
In-Reply-To: <63961d39aee9db94767f28fd441312bec2029473.1366753420.git.arno@natisbad.org>
References: <cover.1366753420.git.arno@natisbad.org>
 <63961d39aee9db94767f28fd441312bec2029473.1366753420.git.arno@natisbad.org>
Message-ID: <20130424170646.GB17771@kw.sim.vm.gnt>

On Wed, Apr 24, 2013 at 12:05:56AM +0200, Arnaud Ebalard wrote:
> 
> Signed-off-by: Arnaud Ebalard <arno at natisbad.org>
> Tested-by: Arnaud Ebalard <arno at natisbad.org>

Hi Arnaud,

Thanks for this patch.

I have partially tested this driver (with the default configuration) on
a net2big_v2 board. I say "partially" because on this board, a two wire
fan is connected to the g762. This means that the measure speed and
alarm features as well as the closed-loop mode are not available.
But all what is left seems to work as expected.

See below for a few remarks and questions about the driver code.

> ---
>  drivers/hwmon/Kconfig  |   10 +
>  drivers/hwmon/Makefile |    1 +
>  drivers/hwmon/g762.c   | 1058 ++++++++++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 1069 insertions(+)
>  create mode 100644 drivers/hwmon/g762.c
> 
> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
> index 89ac1cb..cb4879c 100644
> --- a/drivers/hwmon/Kconfig
> +++ b/drivers/hwmon/Kconfig
> @@ -423,6 +423,16 @@ config SENSORS_G760A
>  	  This driver can also be built as a module.  If so, the module
>  	  will be called g760a.
>  
> +config SENSORS_G762
> +	tristate "GMT G762 and G763"
> +	depends on I2C
> +	help
> +	  If you say yes here you get support for Global Mixed-mode
> +	  Technology Inc G762 and G763 fan speed PWM controller chips.
> +
> +	  This driver can also be built as a module.  If so, the module
> +	  will be called g762.
> +
>  config SENSORS_GL518SM
>  	tristate "Genesys Logic GL518SM"
>  	depends on I2C
> diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
> index 8d6d97e..4b49504 100644
> --- a/drivers/hwmon/Makefile
> +++ b/drivers/hwmon/Makefile
> @@ -57,6 +57,7 @@ obj-$(CONFIG_SENSORS_F75375S)	+= f75375s.o
>  obj-$(CONFIG_SENSORS_FAM15H_POWER) += fam15h_power.o
>  obj-$(CONFIG_SENSORS_FSCHMD)	+= fschmd.o
>  obj-$(CONFIG_SENSORS_G760A)	+= g760a.o
> +obj-$(CONFIG_SENSORS_G762)	+= g762.o
>  obj-$(CONFIG_SENSORS_GL518SM)	+= gl518sm.o
>  obj-$(CONFIG_SENSORS_GL520SM)	+= gl520sm.o
>  obj-$(CONFIG_SENSORS_GPIO_FAN)	+= gpio-fan.o
> diff --git a/drivers/hwmon/g762.c b/drivers/hwmon/g762.c
> new file mode 100644
> index 0000000..810b019
> --- /dev/null
> +++ b/drivers/hwmon/g762.c

Snip

> +/* Set pwm mode. Accepts either 0 (pwm mode) or 1 (linear mode) */
> +static int do_set_pwm_mode(struct device *dev, unsigned long val)
> +{
> +	struct i2c_client *client = to_i2c_client(dev);
> +	struct g762_data *data = g762_update_client(dev);
> +	int ret = 0;
> +
> +	mutex_lock(&data->update_lock);
> +	switch (val) {
> +	case OUT_MODE_PWM:
> +		data->fan_cmd1 |= G762_REG_FAN_CMD1_OUT_MODE;
> +		break;
> +	case OUT_MODE_DAC: /* i.e. linear mode */
> +		data->fan_cmd1 &= ~G762_REG_FAN_CMD1_OUT_MODE;
> +		break;
> +	default:
> +		ret = -EINVAL;
> +		goto out;
> +	}
> +	g762_write_value(client, G762_REG_FAN_CMD1, data->fan_cmd1);

I noticed you never check the value returned by the functions
g762_{read,write}_value(). Is that because the functions
i2c_smbus_{read,write}_byte_data() are not likely to fail ?

> + out:
> +	mutex_unlock(&data->update_lock);
> +
> +	return ret;
> +}
> +
> +/*
> + * Set reference clock. Accepted values are between 0 and 0xffffff.
> + * Note that this is an internal parameter, i.e. value is not passed
> + * to the device.
> + */
> +static int do_set_pwm_freq(struct device *dev, unsigned long val)
> +{
> +	struct i2c_client *client = to_i2c_client(dev);
> +	struct g762_data *data = i2c_get_clientdata(client);
> +	int ret = -EINVAL;
> +
> +	if (val <= 0xffffff) {
> +		data->clk = val;
> +		ret = 0;
> +	}
> +
> +	return ret;
> +}
> +
> +/* Set fan clock divisor. Accepted values are 1, 2, 4 and 8. */
> +static int do_set_fan_div(struct device *dev, unsigned long val)
> +{
> +	struct i2c_client *client = to_i2c_client(dev);
> +	struct g762_data *data = g762_update_client(dev);
> +	int ret = 0;
> +
> +	mutex_lock(&data->update_lock);
> +	switch (val) {
> +	case 1:
> +		data->fan_cmd1 &= ~G762_REG_FAN_CMD1_CLK_DIV_ID0;
> +		data->fan_cmd1 &= ~G762_REG_FAN_CMD1_CLK_DIV_ID1;
> +		break;
> +	case 2:
> +		data->fan_cmd1 |=  G762_REG_FAN_CMD1_CLK_DIV_ID0;
> +		data->fan_cmd1 &= ~G762_REG_FAN_CMD1_CLK_DIV_ID1;
> +		break;
> +	case 4:
> +		data->fan_cmd1 &= ~G762_REG_FAN_CMD1_CLK_DIV_ID0;
> +		data->fan_cmd1 |=  G762_REG_FAN_CMD1_CLK_DIV_ID1;
> +		break;
> +	case 8:
> +		data->fan_cmd1 |=  G762_REG_FAN_CMD1_CLK_DIV_ID0;
> +		data->fan_cmd1 |=  G762_REG_FAN_CMD1_CLK_DIV_ID1;
> +		break;
> +	default:
> +		ret = -EINVAL;
> +		goto out;
> +	}
> +	g762_write_value(client, G762_REG_FAN_CMD1, data->fan_cmd1);
> + out:
> +	mutex_unlock(&data->update_lock);
> +
> +	return ret;
> +}
> +
> +/* Set fan gear mode. Accepted values are either 0, 1 or 2. */
> +static int do_set_fan_gear_mode(struct device *dev, unsigned long val)
> +{
> +	struct i2c_client *client = to_i2c_client(dev);
> +	struct g762_data *data = g762_update_client(dev);
> +	int ret = 0;
> +
> +	mutex_lock(&data->update_lock);
> +	switch (val) {
> +	case 0:
> +		data->fan_cmd2 &= ~G762_REG_FAN_CMD2_GEAR_MODE_0;
> +		data->fan_cmd2 &= ~G762_REG_FAN_CMD2_GEAR_MODE_1;
> +		break;
> +	case 1:
> +		data->fan_cmd2 |=  G762_REG_FAN_CMD2_GEAR_MODE_0;
> +		data->fan_cmd2 &= ~G762_REG_FAN_CMD2_GEAR_MODE_1;
> +		break;
> +	case 2:
> +		data->fan_cmd2 &= ~G762_REG_FAN_CMD2_GEAR_MODE_0;
> +		data->fan_cmd2 |=  G762_REG_FAN_CMD2_GEAR_MODE_1;
> +		break;
> +	default:
> +		ret = -EINVAL;
> +		goto out;
> +	}
> +	g762_write_value(client, G762_REG_FAN_CMD2, data->fan_cmd2);
> + out:
> +	mutex_unlock(&data->update_lock);
> +
> +	return ret;
> +}
> +
> +/* Set pulse per revolution value. Accepts either 2 or 4. */
> +static int do_set_fan_pulses(struct device *dev, unsigned long val)
> +{
> +	struct i2c_client *client = to_i2c_client(dev);
> +	struct g762_data *data = g762_update_client(dev);
> +	int ret = 0;
> +
> +	mutex_lock(&data->update_lock);
> +	switch (val) {
> +	case 2:
> +		data->fan_cmd1 &= ~G762_REG_FAN_CMD1_PULSE_PER_REV;
> +		break;
> +	case 4:
> +		data->fan_cmd1 |=  G762_REG_FAN_CMD1_PULSE_PER_REV;
> +		break;
> +	default:
> +		ret = -EINVAL;
> +		goto out;
> +	}
> +	g762_write_value(client, G762_REG_FAN_CMD1, data->fan_cmd1);
> + out:
> +	mutex_unlock(&data->update_lock);
> +
> +	return ret;
> +}
> +
> +/* Set fan mode. Accepts either 1 (open loop) or 2 (closed loop). */
> +static int do_set_pwm_enable(struct device *dev, unsigned long val)
> +{
> +	struct i2c_client *client = to_i2c_client(dev);
> +	struct g762_data *data = g762_update_client(dev);
> +	int ret = 0;
> +
> +	mutex_lock(&data->update_lock);
> +	switch (val) {
> +	case FAN_MODE_OPEN_LOOP:
> +		data->fan_cmd1 &= ~G762_REG_FAN_CMD1_FAN_MODE;
> +		break;
> +	case FAN_MODE_CLOSED_LOOP:
> +		data->fan_cmd1 |=  G762_REG_FAN_CMD1_FAN_MODE;
> +		break;
> +	default:
> +		ret = -EINVAL;
> +		goto out;
> +	}
> +
> +	g762_write_value(client, G762_REG_FAN_CMD1, data->fan_cmd1);
> + out:
> +	mutex_unlock(&data->update_lock);
> +
> +	return ret;
> +}
> +
> +/* Set pwm polarity (0 for negative duty, 1 for positive duty) */
> +static int do_set_pwm_polarity(struct device *dev, unsigned long val)
> +{
> +	struct i2c_client *client = to_i2c_client(dev);
> +	struct g762_data *data = g762_update_client(dev);
> +	int ret = 0;
> +
> +	mutex_lock(&data->update_lock);
> +	switch (val) {
> +	case 0: /* i.e. negative duty */
> +		data->fan_cmd1 &= ~G762_REG_FAN_CMD1_PWM_POLARITY;
> +		break;
> +	case 1: /* i.e. positive duty */
> +		data->fan_cmd1 |=  G762_REG_FAN_CMD1_PWM_POLARITY;
> +		break;
> +	default:
> +		ret = -EINVAL;
> +		goto out;
> +	}
> +	g762_write_value(client, G762_REG_FAN_CMD1, data->fan_cmd1);
> + out:
> +	mutex_unlock(&data->update_lock);
> +
> +	return ret;
> +}
> +
> +/*
> + * Set pwm value. Accepted values are between 0 and 255. Note that the
> + * internal register used for setting the value depends ont the fan
> + * mode of the device.
> + */
> +static int do_set_pwm(struct device *dev, unsigned long val)
> +{
> +	struct i2c_client *client = to_i2c_client(dev);
> +	struct g762_data *data = g762_update_client(dev);
> +	int ret = -EINVAL;
> +
> +	mutex_lock(&data->update_lock);
> +	if (val > 255)
> +		goto out;
> +
> +	if (data->fan_cmd1 & G762_REG_FAN_CMD1_FAN_MODE) { /* closed-loop */
> +		data->set_cnt = PWM_TO_CNT(val);
> +		g762_write_value(client, G762_REG_SET_CNT, (u8)val);
> +	} else {                                           /* open-loop */
> +		data->set_out = val;
> +		g762_write_value(client, G762_REG_SET_OUT, (u8)val);
> +	}
> +
> +	ret = 0;
> + out:
> +	mutex_unlock(&data->update_lock);
> +
> +	return ret;
> +}
> +
> +/* Set fan RPM value. This only makes sense in closed-loop mode. */
> +static int do_set_fan_target(struct device *dev, unsigned long val)
> +{
> +	struct i2c_client *client = to_i2c_client(dev);
> +	struct g762_data *data = g762_update_client(dev);
> +	int ret = -EINVAL;
> +
> +	mutex_lock(&data->update_lock);
> +	if (data->fan_cmd1 & G762_REG_FAN_CMD1_FAN_MODE) { /* closed-loop */
> +		data->set_cnt = cnt_from_rpm(val, data->clk,
> +					     PULSE_FROM_REG(data->fan_cmd1),
> +					     CLKDIV_FROM_REG(data->fan_cmd1),
> +					     GEARMODE_FROM_REG(data->fan_cmd2));
> +		g762_write_value(client, G762_REG_SET_CNT, data->set_cnt);
> +		ret = 0;
> +	}
> +	mutex_unlock(&data->update_lock);
> +
> +	return ret;
> +}
> +
> +/* Enable/disable fan failure detection. Accepted values are 1 and 0. */
> +static int do_fan_failure_detection_toggle(struct device *dev,
> +					   unsigned long enable)
> +{
> +	struct i2c_client *client = to_i2c_client(dev);
> +	struct g762_data *data = g762_update_client(dev);
> +	int ret = 0;
> +
> +	mutex_lock(&data->update_lock);
> +	switch (enable) {
> +	case 0:
> +		data->fan_cmd1 &= ~G762_REG_FAN_CMD1_DET_FAN_FAIL;
> +		break;
> +	case 1:
> +		data->fan_cmd1 |=  G762_REG_FAN_CMD1_DET_FAN_FAIL;
> +		break;
> +	default:
> +		ret = -EINVAL;
> +		goto out;
> +	}
> +	g762_write_value(client, G762_REG_FAN_CMD1, data->fan_cmd1);
> + out:
> +	mutex_unlock(&data->update_lock);
> +
> +	return ret;
> +}
> +
> +/* Enable/disable fan out of control detection. Accepted values are 1 and 0 */
> +static int do_fan_ooc_detection_toggle(struct device *dev, unsigned int enable)
> +{
> +	struct i2c_client *client = to_i2c_client(dev);
> +	struct g762_data *data = g762_update_client(dev);
> +	int ret = 0;
> +
> +	mutex_lock(&data->update_lock);
> +	switch (enable) {
> +	case 0:
> +		data->fan_cmd1 &= ~G762_REG_FAN_CMD1_DET_FAN_OOC;
> +		break;
> +	case 1:
> +		data->fan_cmd1 |=  G762_REG_FAN_CMD1_DET_FAN_OOC;
> +		break;
> +	default:
> +		ret = -EINVAL;
> +		goto out;
> +	}
> +	g762_write_value(client, G762_REG_FAN_CMD1, data->fan_cmd1);
> + out:
> +	mutex_unlock(&data->update_lock);
> +
> +	return ret;
> +}
> +
> +/* Set startup voltage. Accepted values are either 0, 1, 2 or 3. */
> +static int do_set_fan_startv(struct device *dev, unsigned long val)
> +{
> +	struct i2c_client *client = to_i2c_client(dev);
> +	struct g762_data *data = g762_update_client(dev);
> +	int ret = 0;
> +
> +	mutex_lock(&data->update_lock);
> +	switch (val) {
> +	case 0:
> +		data->fan_cmd2 &= ~G762_REG_FAN_CMD2_FAN_STARTV_0;
> +		data->fan_cmd2 &= ~G762_REG_FAN_CMD2_FAN_STARTV_1;
> +		break;
> +	case 1:
> +		data->fan_cmd2 |=  G762_REG_FAN_CMD2_FAN_STARTV_0;
> +		data->fan_cmd2 &= ~G762_REG_FAN_CMD2_FAN_STARTV_1;
> +		break;
> +	case 2:
> +		data->fan_cmd2 &= ~G762_REG_FAN_CMD2_FAN_STARTV_0;
> +		data->fan_cmd2 |=  G762_REG_FAN_CMD2_FAN_STARTV_1;
> +		break;
> +	case 3:
> +		data->fan_cmd2 |=  G762_REG_FAN_CMD2_FAN_STARTV_0;
> +		data->fan_cmd2 |=  G762_REG_FAN_CMD2_FAN_STARTV_1;
> +		break;
> +	default:
> +		ret = -EINVAL;
> +		goto out;
> +	}
> +	g762_write_value(client, G762_REG_FAN_CMD2, data->fan_cmd2);
> + out:
> +	mutex_unlock(&data->update_lock);
> +
> +	return ret;
> +}

It seems to me that all the functions above are more or less using the
same code. For example do_set_fan_pulses, do_set_pwm_enable and
do_set_pwm_polarity are very similar. Then, there is probably room for
some code factorisation ? For example, you could use some functions to
set or clear a mask against a given register. Or something else...

> +
> +
> +
> +/*
> + * Configuration-related definitions
> + */
> +
> +struct g762_config {
> +	u32 fan_startv;
> +	u32 fan_gear_mode;
> +	u32 fan_div;
> +	u32 fan_pulses;
> +	u32 fan_target;
> +	u32 pwm_polarity;
> +	u32 pwm_enable;
> +	u32 pwm_freq;
> +	u32 pwm_mode;
> +};
> +
> +/*
> + * g762 default values: it is assumed that the fan is set for a 32KHz clock
> + * source, a fan clock divisor of 1 and two pulses per revolution. Default
> + * fan driving mode is linear mode (g762/g763 also support PWM mode). Note
> + * the specific init value for properties which may be left unmodified.
> + */
> +#define G762_DEFAULT_CLK            32768
> +#define G762_DEFAULT_FAN_DIV        1
> +#define G762_DEFAULT_FAN_PULSES     2
> +#define G762_DEFAULT_OUT_MODE       0
> +#define G762_DEFAULT_FAN_MODE       2
> +#define G762_DEFAULT_FAN_STARTV     1
> +#define G762_DEFAULT_FAN_GEAR_MODE  0
> +#define G762_DEFAULT_FAN_POLARITY   0
> +#define G762_UNTOUCHED_VAL          0xffffffff
> +
> +static void g762_config_init(struct g762_config *conf)
> +{
> +	conf->pwm_enable = G762_DEFAULT_FAN_MODE;
> +	conf->pwm_mode = G762_DEFAULT_OUT_MODE;
> +	conf->pwm_freq = G762_DEFAULT_CLK;
> +	conf->pwm_polarity = G762_DEFAULT_FAN_POLARITY;
> +	conf->fan_pulses = G762_DEFAULT_FAN_PULSES;
> +	conf->fan_div = G762_DEFAULT_FAN_DIV;
> +	conf->fan_startv = G762_DEFAULT_FAN_STARTV;
> +	conf->fan_gear_mode = G762_DEFAULT_FAN_GEAR_MODE;
> +	conf->fan_target = G762_UNTOUCHED_VAL;
> +}
> +
> +static inline int g762_one_prop_commit(struct i2c_client *client,
> +				       u32 pval, const char *pname,
> +				       int (*psetter)(struct device *dev,
> +						      unsigned long val))
> +{
> +	int ret = 0;
> +
> +	if ((pval != G762_UNTOUCHED_VAL) && (*psetter)(&client->dev, pval)) {
> +		dev_info(&client->dev, "unable to set %s (%d)\n", pname, pval);
> +		ret = -EINVAL;
> +	}
> +
> +	return ret;
> +}
> +
> +static int g762_config_commit(struct i2c_client *client,
> +			      struct g762_config *conf)
> +{
> +	int ret = 0;
> +
> +	if (g762_one_prop_commit(client, conf->pwm_mode,
> +				 "pwm_mode", &do_set_pwm_mode) ||
> +	    g762_one_prop_commit(client, conf->pwm_enable,
> +				 "pwm_enable", &do_set_pwm_enable) ||
> +	    g762_one_prop_commit(client, conf->fan_div,
> +				 "fan_div", &do_set_fan_div) ||
> +	    g762_one_prop_commit(client, conf->fan_pulses,
> +				 "fan_pulses", &do_set_fan_pulses) ||
> +	    g762_one_prop_commit(client, conf->pwm_freq,
> +				 "pwm_freq", &do_set_pwm_freq) ||
> +	    g762_one_prop_commit(client, conf->fan_gear_mode,
> +				 "fan_gear_mode", &do_set_fan_gear_mode) ||
> +	    g762_one_prop_commit(client, conf->pwm_polarity,
> +				 "pwm_polarity", &do_set_pwm_polarity) ||
> +	    g762_one_prop_commit(client, conf->fan_startv,
> +				 "fan_startv", &do_set_fan_startv) ||
> +	    g762_one_prop_commit(client, conf->fan_target,
> +				 "fan_target", &do_set_fan_target)) {

Is that correct ? Here, g762_update_client() is called several times in
a short time interval. This means that the registers are not re-read
after each write operation (only after the first). If the chip updates
internally some registers after a write, then a mismatch between
struct g762_data and the real registers values could happen.

> +		ret = -EINVAL;
> +	}
> +
> +	return ret;
> +}

Snip

> +/*
> + * Get/set the fan speed in open-loop mode using pwm1 sysfs file. Speed is
> + * given as a relative value from 0 to 255, where 255 is maximum speed. Note
> + * that this is done by writing directly to the chip's DAC, it won't change
> + * the closed loop speed set by fan1_target. Also note that due to rounding
> + * errors it is possible that you don't read back exactly the value you have
> + * set.
> + */
> +static ssize_t get_pwm(struct device *dev, struct device_attribute *da,
> +		       char *buf)
> +{
> +	struct g762_data *data = g762_update_client(dev);
> +	int val;
> +
> +	mutex_lock(&data->update_lock);
> +	if (data->fan_cmd1 & G762_REG_FAN_CMD1_FAN_MODE) { /* closed-loop */
> +		val = PWM_FROM_CNT(data->set_cnt);
> +	} else {                                            /* open-loop */
> +		val = data->set_out;
> +	}

I don't think you need to use braces for the above statement.

Regards,

Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130424/9838afdc/attachment-0001.sig>

From cdall at cs.columbia.edu  Wed Apr 24 13:08:05 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Wed, 24 Apr 2013 10:08:05 -0700
Subject: [PATCH v3 17/32] arm64: KVM: HYP mode world switch implementation
In-Reply-To: <5177C47B.6090502@arm.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
 <1365437854-30214-18-git-send-email-marc.zyngier@arm.com>
 <20130423225958.GF20569@gmail.com> <5177C47B.6090502@arm.com>
Message-ID: <CAEDV+gJt7D5NgJJQsFe8YrG+5ErrnAYGDRAdBQBFOx+b=HKapA@mail.gmail.com>

On Wed, Apr 24, 2013 at 4:39 AM, Marc Zyngier <marc.zyngier at arm.com> wrote:
> On 23/04/13 23:59, Christoffer Dall wrote:
>> On Mon, Apr 08, 2013 at 05:17:19PM +0100, Marc Zyngier wrote:
>>> The HYP mode world switch in all its glory.
>>>
>>> Implements save/restore of host/guest registers, EL2 trapping,
>>> IPA resolution, and additional services (tlb invalidation).
>>>
>>> Reviewed-by: Christopher Covington <cov at codeaurora.org>
>>> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
>>> ---
>>>  arch/arm64/kernel/asm-offsets.c |  34 +++
>>>  arch/arm64/kvm/hyp.S            | 602 ++++++++++++++++++++++++++++++++++++++++
>>>  2 files changed, 636 insertions(+)
>>>  create mode 100644 arch/arm64/kvm/hyp.S
>>>
>
> [...]
>
>>> diff --git a/arch/arm64/kvm/hyp.S b/arch/arm64/kvm/hyp.S
>>> new file mode 100644
>>> index 0000000..c745d20
>>> --- /dev/null
>>> +++ b/arch/arm64/kvm/hyp.S
>>> @@ -0,0 +1,602 @@
>>> +/*
>>> + * Copyright (C) 2012,2013 - ARM Ltd
>>> + * Author: Marc Zyngier <marc.zyngier at arm.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.
>>> + *
>>> + * This program is distributed in the hope that it will be useful,
>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>>> + * GNU General Public License for more details.
>>> + *
>>> + * You should have received a copy of the GNU General Public License
>>> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
>>> + */
>>> +
>>> +#include <linux/linkage.h>
>>> +#include <linux/irqchip/arm-gic.h>
>>> +
>>> +#include <asm/assembler.h>
>>> +#include <asm/memory.h>
>>> +#include <asm/asm-offsets.h>
>>> +#include <asm/fpsimdmacros.h>
>>> +#include <asm/kvm.h>
>>> +#include <asm/kvm_asm.h>
>>> +#include <asm/kvm_arm.h>
>>> +#include <asm/kvm_mmu.h>
>>> +
>>> +#define CPU_GP_REG_OFFSET(x) (CPU_GP_REGS + x)
>>> +#define CPU_XREG_OFFSET(x)   CPU_GP_REG_OFFSET(CPU_USER_PT_REGS + 8*x)
>>> +#define CPU_SPSR_OFFSET(x)   CPU_GP_REG_OFFSET(CPU_SPSR + 8*x)
>>> +#define CPU_SYSREG_OFFSET(x) (CPU_SYSREGS + 8*x)
>>> +
>>> +     .text
>>> +     .pushsection    .hyp.text, "ax"
>>> +     .align  PAGE_SHIFT
>>> +
>>> +__kvm_hyp_code_start:
>>> +     .globl __kvm_hyp_code_start
>>> +
>>> +.macro save_common_regs
>>> +     // x2: base address for cpu context
>>> +     // x3: tmp register
>>
>> what's with the C99 style comments? Standard for arm64 assembly?
>
> Yes. The toolchain guys got rid of '@' as a single line comment delimiter.
>
> [...]
>
>>> +el1_sync:                                    // Guest trapped into EL2
>>> +     push    x0, x1
>>> +     push    x2, x3
>>> +
>>> +     mrs     x1, esr_el2
>>> +     lsr     x2, x1, #ESR_EL2_EC_SHIFT
>>> +
>>> +     cmp     x2, #ESR_EL2_EC_HVC64
>>> +     b.ne    el1_trap
>>> +
>>> +     mrs     x3, vttbr_el2                   // If vttbr is valid, the 64bit guest
>>> +     cbnz    x3, el1_trap                    // called HVC
>>> +
>>> +     /* Here, we're pretty sure the host called HVC. */
>>> +     pop     x2, x3
>>> +     pop     x0, x1
>>> +
>>> +     push    lr, xzr
>>> +
>>> +     /*
>>> +      * Compute the function address in EL2, and shuffle the parameters.
>>> +      */
>>> +     kern_hyp_va     x0
>>> +     mov     lr, x0
>>> +     mov     x0, x1
>>> +     mov     x1, x2
>>> +     mov     x2, x3
>>> +     blr     lr
>>> +
>>> +     pop     lr, xzr
>>> +     eret
>>> +
>>> +el1_trap:
>>> +     /*
>>> +      * x1: ESR
>>> +      * x2: ESR_EC
>>> +      */
>>> +     cmp     x2, #ESR_EL2_EC_DABT
>>> +     mov     x0, #ESR_EL2_EC_IABT
>>> +     ccmp    x2, x0, #4, ne
>>> +     b.ne    1f              // Not an abort we care about
>>
>> why do we get the hpfar_el2 if it's not an abort (or is this for a
>> special type of abort) ?
>
> No, we could actually avoid saving HPFAR_EL2 altogether in this case.
>
>>> +
>>> +     /* This is an abort. Check for permission fault */
>>> +     and     x2, x1, #ESR_EL2_FSC_TYPE
>>> +     cmp     x2, #FSC_PERM
>>> +     b.ne    1f              // Not a permission fault
>>> +
>>> +     /*
>>> +      * Check for Stage-1 page table walk, which is guaranteed
>>> +      * to give a valid HPFAR_EL2.
>>> +      */
>>> +     tbnz    x1, #7, 1f      // S1PTW is set
>>> +
>>> +     /*
>>> +      * Permission fault, HPFAR_EL2 is invalid.
>>> +      * Resolve the IPA the hard way using the guest VA.
>>> +      * We always perform an EL1 lookup, as we already
>>> +      * went through Stage-1.
>>> +      */
>>
>> What does the last sentence mean exactly?
>
> It means that the Stage-1 translation already validated the memory
> access rights. As such, we can use the EL1 translation regime, and don't
> have to distinguish between EL0 and EL1 access.
>

ah, right, now I remember this one, I think the comment could say that
more clearly:)

>>> +     mrs     x3, far_el2
>>> +     at      s1e1r, x3
>>> +     isb
>>> +
>>> +     /* Read result */
>>> +     mrs     x3, par_el1
>>> +     tbnz    x3, #1, 3f              // Bail out if we failed the translation
>>> +     ubfx    x3, x3, #12, #36        // Extract IPA
>>> +     lsl     x3, x3, #4              // and present it like HPFAR
>>> +     b       2f
>>> +
>>> +1:   mrs     x3, hpfar_el2
>>> +
>>> +2:   mrs     x0, tpidr_el2
>>> +     mrs     x2, far_el2
>>> +     str     x1, [x0, #VCPU_ESR_EL2]
>>> +     str     x2, [x0, #VCPU_FAR_EL2]
>>> +     str     x3, [x0, #VCPU_HPFAR_EL2]
>>> +
>>> +     mov     x1, #ARM_EXCEPTION_TRAP
>>> +     b       __kvm_vcpu_return
>>> +
>>> +     /*
>>> +      * Translation failed. Just return to the guest and
>>> +      * let it fault again. Another CPU is probably playing
>>> +      * behind our back.
>>> +      */
>>
>> This actually makes me wonder if this is a potential DOS attack from
>> guests (on the 32-bit code as well), or are we sure that an asynchronous
>> timer interrupt to the host will always creep in between e.g. a tight
>> loop playing this trick on us?
>
> Host interrupts will fire as soon as you eret into the guest. At that
> point, the (malicious) guest will be scheduled out, just like a normal
> process.
>
good, thanks.


From cdall at cs.columbia.edu  Wed Apr 24 13:09:44 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Wed, 24 Apr 2013 10:09:44 -0700
Subject: [PATCH v3 24/32] arm64: KVM: 32bit GP register access
In-Reply-To: <5177D8E1.6010903@arm.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
 <1365437854-30214-25-git-send-email-marc.zyngier@arm.com>
 <20130423230039.GI20569@gmail.com> <5177D8E1.6010903@arm.com>
Message-ID: <CAEDV+gLcNQozXrX+9N_Qomjnhs1huKnXxToFTFFPAZkyobOppA@mail.gmail.com>

On Wed, Apr 24, 2013 at 6:06 AM, Marc Zyngier <marc.zyngier at arm.com> wrote:
> On 24/04/13 00:00, Christoffer Dall wrote:
>> On Mon, Apr 08, 2013 at 05:17:26PM +0100, Marc Zyngier wrote:
>>> Allow access to the 32bit register file through the usual API.
>>>
>>> Reviewed-by: Christopher Covington <cov at codeaurora.org>
>>> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
>>> ---
>>>  arch/arm64/include/asm/kvm_emulate.h |  17 +++-
>>>  arch/arm64/kvm/Makefile              |   2 +-
>>>  arch/arm64/kvm/regmap.c              | 168 +++++++++++++++++++++++++++++++++++
>>>  3 files changed, 184 insertions(+), 3 deletions(-)
>>>  create mode 100644 arch/arm64/kvm/regmap.c
>>>
>>> diff --git a/arch/arm64/include/asm/kvm_emulate.h b/arch/arm64/include/asm/kvm_emulate.h
>>> index 2dcfa74..37a6567 100644
>>> --- a/arch/arm64/include/asm/kvm_emulate.h
>>> +++ b/arch/arm64/include/asm/kvm_emulate.h
>>> @@ -28,6 +28,9 @@
>>>  #include <asm/kvm_mmio.h>
>>>  #include <asm/ptrace.h>
>>>
>>> +unsigned long *vcpu_reg32(const struct kvm_vcpu *vcpu, u8 reg_num);
>>> +unsigned long *vcpu_spsr32(const struct kvm_vcpu *vcpu);
>>> +
>>>  void kvm_inject_undefined(struct kvm_vcpu *vcpu);
>>>  void kvm_inject_dabt(struct kvm_vcpu *vcpu, unsigned long addr);
>>>  void kvm_inject_pabt(struct kvm_vcpu *vcpu, unsigned long addr);
>>> @@ -49,7 +52,7 @@ static inline unsigned long *vcpu_cpsr(const struct kvm_vcpu *vcpu)
>>>
>>>  static inline bool vcpu_mode_is_32bit(const struct kvm_vcpu *vcpu)
>>>  {
>>> -    return false;   /* 32bit? Bahhh... */
>>> +    return !!(*vcpu_cpsr(vcpu) & PSR_MODE32_BIT);
>>
>> nit: you don't need the '!!': it's a bool
>
> No it is not. It is a bitwise and, turned into a bool.
>
yeah and the result of the bitwise and will be cast to a bool as per
the function's return value without the use of '!!' or did I read the
C spec wrong?


From cdall at cs.columbia.edu  Wed Apr 24 13:11:56 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Wed, 24 Apr 2013 10:11:56 -0700
Subject: [PATCH v3 25/32] arm64: KVM: 32bit conditional execution emulation
In-Reply-To: <5177DA81.3020400@arm.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
 <1365437854-30214-26-git-send-email-marc.zyngier@arm.com>
 <20130423230057.GJ20569@gmail.com> <5177DA81.3020400@arm.com>
Message-ID: <CAEDV+gKOyckxxZ+wrGCWjEW0k-HR6b_uS0vZ6cH=gLwT1FbJ7w@mail.gmail.com>

On Wed, Apr 24, 2013 at 6:13 AM, Marc Zyngier <marc.zyngier at arm.com> wrote:
> On 24/04/13 00:00, Christoffer Dall wrote:
>> On Mon, Apr 08, 2013 at 05:17:27PM +0100, Marc Zyngier wrote:
>>> As conditional instructions can trap on AArch32, add the thinest
>>> possible emulation layer to keep 32bit guests happy.
>>>
>>> Reviewed-by: Christopher Covington <cov at codeaurora.org>
>>> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
>>> ---
>>>  arch/arm64/include/asm/kvm_emulate.h |  13 ++-
>>>  arch/arm64/kvm/Makefile              |   2 +-
>>>  arch/arm64/kvm/emulate.c             | 154 +++++++++++++++++++++++++++++++++++
>>>  3 files changed, 166 insertions(+), 3 deletions(-)
>>>  create mode 100644 arch/arm64/kvm/emulate.c
>>>
>>> diff --git a/arch/arm64/include/asm/kvm_emulate.h b/arch/arm64/include/asm/kvm_emulate.h
>>> index 37a6567..8d4ab33 100644
>>> --- a/arch/arm64/include/asm/kvm_emulate.h
>>> +++ b/arch/arm64/include/asm/kvm_emulate.h
>>> @@ -31,6 +31,9 @@
>>>  unsigned long *vcpu_reg32(const struct kvm_vcpu *vcpu, u8 reg_num);
>>>  unsigned long *vcpu_spsr32(const struct kvm_vcpu *vcpu);
>>>
>>> +bool kvm_condition_valid32(const struct kvm_vcpu *vcpu);
>>> +void kvm_skip_instr32(struct kvm_vcpu *vcpu, bool is_wide_instr);
>>> +
>>>  void kvm_inject_undefined(struct kvm_vcpu *vcpu);
>>>  void kvm_inject_dabt(struct kvm_vcpu *vcpu, unsigned long addr);
>>>  void kvm_inject_pabt(struct kvm_vcpu *vcpu, unsigned long addr);
>>> @@ -57,12 +60,18 @@ static inline bool vcpu_mode_is_32bit(const struct kvm_vcpu *vcpu)
>>>
>>>  static inline bool kvm_condition_valid(const struct kvm_vcpu *vcpu)
>>>  {
>>> -    return true;    /* No conditionals on arm64 */
>>> +    if (vcpu_mode_is_32bit(vcpu))
>>> +            return kvm_condition_valid32(vcpu);
>>> +
>>> +    return true;
>>>  }
>>>
>>>  static inline void kvm_skip_instr(struct kvm_vcpu *vcpu, bool is_wide_instr)
>>>  {
>>> -    *vcpu_pc(vcpu) += 4;
>>> +    if (vcpu_mode_is_32bit(vcpu))
>>> +            kvm_skip_instr32(vcpu, is_wide_instr);
>>> +    else
>>> +            *vcpu_pc(vcpu) += 4;
>>>  }
>>>
>>>  static inline void vcpu_set_thumb(struct kvm_vcpu *vcpu)
>>> diff --git a/arch/arm64/kvm/Makefile b/arch/arm64/kvm/Makefile
>>> index 1668448..88c6639 100644
>>> --- a/arch/arm64/kvm/Makefile
>>> +++ b/arch/arm64/kvm/Makefile
>>> @@ -11,7 +11,7 @@ obj-$(CONFIG_KVM_ARM_HOST) += kvm.o
>>>  kvm-$(CONFIG_KVM_ARM_HOST) += $(addprefix ../../../virt/kvm/, kvm_main.o coalesced_mmio.o)
>>>  kvm-$(CONFIG_KVM_ARM_HOST) += $(addprefix ../../../arch/arm/kvm/, arm.o mmu.o mmio.o psci.o perf.o)
>>>
>>> -kvm-$(CONFIG_KVM_ARM_HOST) += inject_fault.o regmap.o
>>> +kvm-$(CONFIG_KVM_ARM_HOST) += emulate.o inject_fault.o regmap.o
>>>  kvm-$(CONFIG_KVM_ARM_HOST) += hyp.o hyp-init.o handle_exit.o
>>>  kvm-$(CONFIG_KVM_ARM_HOST) += guest.o reset.o sys_regs.o sys_regs_generic_v8.o
>>>
>>> diff --git a/arch/arm64/kvm/emulate.c b/arch/arm64/kvm/emulate.c
>>> new file mode 100644
>>> index 0000000..01d4713
>>> --- /dev/null
>>> +++ b/arch/arm64/kvm/emulate.c
>>> @@ -0,0 +1,154 @@
>>> +/*
>>> + * (not much of an) Emulation layer for 32bit guests.
>>> + *
>>> + * Copyright (C) 2012 - Virtual Open Systems and Columbia University
>>> + * Author: Christoffer Dall <c.dall at virtualopensystems.com>
>>
>> don't you want to add yourself here?
>
> There's really nothing I actually wrote here. Most of it is your code,
> and the rest comes from other parts of arch/arm.
>
> I guess I could always mention myself for the ESR_EL2_* macros... ;-)
>
>>> + *
>>> + * 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.
>>> + *
>>> + * This program is distributed in the hope that it will be useful,
>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>>> + * GNU General Public License for more details.
>>> + *
>>> + * You should have received a copy of the GNU General Public License
>>> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
>>> + */
>>> +
>>> +#include <linux/kvm_host.h>
>>> +#include <asm/kvm_emulate.h>
>>> +
>>> +/*
>>> + * stolen from arch/arm/kernel/opcodes.c
>>> + *
>>> + * condition code lookup table
>>> + * index into the table is test code: EQ, NE, ... LT, GT, AL, NV
>>> + *
>>> + * bit position in short is condition code: NZCV
>>> + */
>>> +static const unsigned short cc_map[16] = {
>>> +    0xF0F0,                 /* EQ == Z set            */
>>> +    0x0F0F,                 /* NE                     */
>>> +    0xCCCC,                 /* CS == C set            */
>>> +    0x3333,                 /* CC                     */
>>> +    0xFF00,                 /* MI == N set            */
>>> +    0x00FF,                 /* PL                     */
>>> +    0xAAAA,                 /* VS == V set            */
>>> +    0x5555,                 /* VC                     */
>>> +    0x0C0C,                 /* HI == C set && Z clear */
>>> +    0xF3F3,                 /* LS == C clear || Z set */
>>> +    0xAA55,                 /* GE == (N==V)           */
>>> +    0x55AA,                 /* LT == (N!=V)           */
>>> +    0x0A05,                 /* GT == (!Z && (N==V))   */
>>> +    0xF5FA,                 /* LE == (Z || (N!=V))    */
>>> +    0xFFFF,                 /* AL always              */
>>> +    0                       /* NV                     */
>>> +};
>>> +
>>> +static int kvm_vcpu_get_condition(const struct kvm_vcpu *vcpu)
>>> +{
>>> +    u32 esr = kvm_vcpu_get_hsr(vcpu);
>>> +
>>> +    if (esr & ESR_EL2_CV)
>>> +            return (esr & ESR_EL2_COND) >> ESR_EL2_COND_SHIFT;
>>> +
>>> +    return -1;
>>> +}
>>> +
>>> +/*
>>> + * Check if a trapped instruction should have been executed or not.
>>> + */
>>> +bool kvm_condition_valid32(const struct kvm_vcpu *vcpu)
>>> +{
>>> +    unsigned long cpsr;
>>> +    u32 cpsr_cond;
>>> +    int cond;
>>> +
>>> +    /* Top two bits non-zero?  Unconditional. */
>>> +    if (kvm_vcpu_get_hsr(vcpu) >> 30)
>>> +            return true;
>>> +
>>> +    /* Is condition field valid? */
>>> +    cond = kvm_vcpu_get_condition(vcpu);
>>> +    if (cond == 0xE)
>>> +            return true;
>>> +
>>> +    cpsr = *vcpu_cpsr(vcpu);
>>> +
>>> +    if (cond < 0) {
>>> +            /* This can happen in Thumb mode: examine IT state. */
>>> +            unsigned long it;
>>> +
>>> +            it = ((cpsr >> 8) & 0xFC) | ((cpsr >> 25) & 0x3);
>>> +
>>> +            /* it == 0 => unconditional. */
>>> +            if (it == 0)
>>> +                    return true;
>>> +
>>> +            /* The cond for this insn works out as the top 4 bits. */
>>> +            cond = (it >> 4);
>>> +    }
>>> +
>>> +    cpsr_cond = cpsr >> 28;
>>> +
>>> +    if (!((cc_map[cond] >> cpsr_cond) & 1))
>>> +            return false;
>>> +
>>> +    return true;
>>> +}
>>> +
>>> +/**
>>> + * adjust_itstate - adjust ITSTATE when emulating instructions in IT-block
>>> + * @vcpu:   The VCPU pointer
>>> + *
>>> + * When exceptions occur while instructions are executed in Thumb IF-THEN
>>> + * blocks, the ITSTATE field of the CPSR is not advanved (updated), so we have
>>
>> s/advanved/advanced/
>
> See? You actually hold the copyright on that spelling mistake! ;-)
>>
>>> + * to do this little bit of work manually. The fields map like this:
>>> + *
>>> + * IT[7:0] -> CPSR[26:25],CPSR[15:10]
>>> + */
>>> +static void kvm_adjust_itstate(struct kvm_vcpu *vcpu)
>>> +{
>>> +    unsigned long itbits, cond;
>>> +    unsigned long cpsr = *vcpu_cpsr(vcpu);
>>> +    bool is_arm = !(cpsr & COMPAT_PSR_T_BIT);
>>> +
>>> +    BUG_ON(is_arm && (cpsr & COMPAT_PSR_IT_MASK));
>>> +
>>> +    if (!(cpsr & COMPAT_PSR_IT_MASK))
>>> +            return;
>>> +
>>> +    cond = (cpsr & 0xe000) >> 13;
>>> +    itbits = (cpsr & 0x1c00) >> (10 - 2);
>>> +    itbits |= (cpsr & (0x3 << 25)) >> 25;
>>> +
>>> +    /* Perform ITAdvance (see page A-52 in ARM DDI 0406C) */
>>
>> That's actually page A2-52 to be a little more precise...
>
> Yup. Feel free to update the 32bit code as well... ;-)
>
>>> +    if ((itbits & 0x7) == 0)
>>> +            itbits = cond = 0;
>>> +    else
>>> +            itbits = (itbits << 1) & 0x1f;
>>> +
>>> +    cpsr &= ~COMPAT_PSR_IT_MASK;
>>> +    cpsr |= cond << 13;
>>> +    cpsr |= (itbits & 0x1c) << (10 - 2);
>>> +    cpsr |= (itbits & 0x3) << 25;
>>> +    *vcpu_cpsr(vcpu) = cpsr;
>>> +}
>>> +
>>> +/**
>>> + * kvm_skip_instr - skip a trapped instruction and proceed to the next
>>> + * @vcpu: The vcpu pointer
>>> + */
>>> +void kvm_skip_instr32(struct kvm_vcpu *vcpu, bool is_wide_instr)
>>> +{
>>> +    bool is_thumb;
>>> +
>>> +    is_thumb = !!(*vcpu_cpsr(vcpu) & COMPAT_PSR_T_BIT);
>>
>> again we don't need the '!!' when it's a bool.
>
> I'm still not prepared to consider a bitwise and as a bool, and I'm
> happy for the !! to make the conversion to a bool completely obvious.
>
ok, you could also have 4 of them, or maybe 28 of them, just make sure
it's an even number of them ;)


From cdall at cs.columbia.edu  Wed Apr 24 13:14:08 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Wed, 24 Apr 2013 10:14:08 -0700
Subject: [PATCH v3 26/32] arm64: KVM: 32bit handling of coprocessor traps
In-Reply-To: <5177E12C.8020909@arm.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
 <1365437854-30214-27-git-send-email-marc.zyngier@arm.com>
 <20130423230159.GL20569@gmail.com> <5177E12C.8020909@arm.com>
Message-ID: <CAEDV+gJ5caireE_Nz11znqFpV1D3j02Ekt-9tJiN-ueXjhQOHw@mail.gmail.com>

On Wed, Apr 24, 2013 at 6:42 AM, Marc Zyngier <marc.zyngier at arm.com> wrote:
> On 24/04/13 00:01, Christoffer Dall wrote:
>> On Mon, Apr 08, 2013 at 05:17:28PM +0100, Marc Zyngier wrote:
>>> Provide the necessary infrastructure to trap coprocessor accesses that
>>> occur when running 32bit guests.
>>>
>>> Also wire SMC and HVC trapped in 32bit mode while were at it.
>>>
>>> Reviewed-by: Christopher Covington <cov at codeaurora.org>
>>> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
>>> ---
>>>  arch/arm64/include/asm/kvm_coproc.h |   5 +
>>>  arch/arm64/kvm/handle_exit.c        |   7 ++
>>>  arch/arm64/kvm/sys_regs.c           | 178 ++++++++++++++++++++++++++++++++++--
>>>  3 files changed, 183 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/arch/arm64/include/asm/kvm_coproc.h b/arch/arm64/include/asm/kvm_coproc.h
>>> index 9b4477a..9a59301 100644
>>> --- a/arch/arm64/include/asm/kvm_coproc.h
>>> +++ b/arch/arm64/include/asm/kvm_coproc.h
>>> @@ -32,11 +32,16 @@ struct kvm_sys_reg_table {
>>>
>>>  struct kvm_sys_reg_target_table {
>>>       struct kvm_sys_reg_table table64;
>>> +     struct kvm_sys_reg_table table32;
>>>  };
>>>
>>>  void kvm_register_target_sys_reg_table(unsigned int target,
>>>                                      struct kvm_sys_reg_target_table *table);
>>>
>>> +int kvm_handle_cp14_load_store(struct kvm_vcpu *vcpu, struct kvm_run *run);
>>> +int kvm_handle_cp14_access(struct kvm_vcpu *vcpu, struct kvm_run *run);
>>> +int kvm_handle_cp15_32(struct kvm_vcpu *vcpu, struct kvm_run *run);
>>> +int kvm_handle_cp15_64(struct kvm_vcpu *vcpu, struct kvm_run *run);
>>>  int kvm_handle_sys_reg(struct kvm_vcpu *vcpu, struct kvm_run *run);
>>>
>>>  #define kvm_coproc_table_init kvm_sys_reg_table_init
>>> diff --git a/arch/arm64/kvm/handle_exit.c b/arch/arm64/kvm/handle_exit.c
>>> index 4766b7f..9beaca03 100644
>>> --- a/arch/arm64/kvm/handle_exit.c
>>> +++ b/arch/arm64/kvm/handle_exit.c
>>> @@ -62,6 +62,13 @@ static int kvm_handle_wfi(struct kvm_vcpu *vcpu, struct kvm_run *run)
>>>
>>>  static exit_handle_fn arm_exit_handlers[] = {
>>>       [ESR_EL2_EC_WFI]        = kvm_handle_wfi,
>>> +     [ESR_EL2_EC_CP15_32]    = kvm_handle_cp15_32,
>>> +     [ESR_EL2_EC_CP15_64]    = kvm_handle_cp15_64,
>>> +     [ESR_EL2_EC_CP14_MR]    = kvm_handle_cp14_access,
>>> +     [ESR_EL2_EC_CP14_LS]    = kvm_handle_cp14_load_store,
>>> +     [ESR_EL2_EC_CP14_64]    = kvm_handle_cp14_access,
>>> +     [ESR_EL2_EC_HVC32]      = handle_hvc,
>>> +     [ESR_EL2_EC_SMC32]      = handle_smc,
>>>       [ESR_EL2_EC_HVC64]      = handle_hvc,
>>>       [ESR_EL2_EC_SMC64]      = handle_smc,
>>>       [ESR_EL2_EC_SYS64]      = kvm_handle_sys_reg,
>>> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
>>> index 9df3b32..0303218 100644
>>> --- a/arch/arm64/kvm/sys_regs.c
>>> +++ b/arch/arm64/kvm/sys_regs.c
>>> @@ -38,6 +38,10 @@
>>>   * types are different. My gut feeling is that it should be pretty
>>>   * easy to merge, but that would be an ABI breakage -- again. VFP
>>>   * would also need to be abstracted.
>>> + *
>>> + * For AArch32, we only take care of what is being trapped. Anything
>>> + * that has to do with init and userspace access has to go via the
>>> + * 64bit interface.
>>>   */
>>>
>>>  /* 3 bits per cache level, as per CLIDR, but non-existent caches always 0 */
>>> @@ -163,6 +167,16 @@ static const struct sys_reg_desc sys_reg_descs[] = {
>>>       { Op0(0b01), Op1(0b000), CRn(0b0111), CRm(0b1110), Op2(0b010),
>>>         access_dcsw },
>>>
>>> +     /* TEECR32_EL1 */
>>> +     { Op0(0b10), Op1(0b010), CRn(0b0000), CRm(0b0000), Op2(0b000),
>>> +       NULL, reset_val, TEECR32_EL1, 0 },
>>> +     /* TEEHBR32_EL1 */
>>> +     { Op0(0b10), Op1(0b010), CRn(0b0001), CRm(0b0000), Op2(0b000),
>>> +       NULL, reset_val, TEEHBR32_EL1, 0 },
>>> +     /* DBGVCR32_EL2 */
>>> +     { Op0(0b10), Op1(0b100), CRn(0b0000), CRm(0b0111), Op2(0b000),
>>> +       NULL, reset_val, DBGVCR32_EL2, 0 },
>>> +
>>>       /* MPIDR_EL1 */
>>>       { Op0(0b11), Op1(0b000), CRn(0b0000), CRm(0b0000), Op2(0b101),
>>>         NULL, reset_mpidr, MPIDR_EL1 },
>>> @@ -273,6 +287,39 @@ static const struct sys_reg_desc sys_reg_descs[] = {
>>>       /* TPIDRRO_EL0 */
>>>       { Op0(0b11), Op1(0b011), CRn(0b1101), CRm(0b0000), Op2(0b011),
>>>         NULL, reset_unknown, TPIDRRO_EL0 },
>>> +
>>> +     /* DACR32_EL2 */
>>> +     { Op0(0b11), Op1(0b100), CRn(0b0011), CRm(0b0000), Op2(0b000),
>>> +       NULL, reset_unknown, DACR32_EL2 },
>>> +     /* IFSR32_EL2 */
>>> +     { Op0(0b11), Op1(0b100), CRn(0b0101), CRm(0b0000), Op2(0b001),
>>> +       NULL, reset_unknown, IFSR32_EL2 },
>>> +     /* FPEXC32_EL2 */
>>> +     { Op0(0b11), Op1(0b100), CRn(0b0101), CRm(0b0011), Op2(0b000),
>>> +       NULL, reset_val, FPEXC32_EL2, 0x70 },
>>> +};
>>> +
>>> +/* Trapped cp15 registers */
>>> +static const struct sys_reg_desc cp15_regs[] = {
>>> +     /*
>>> +      * DC{C,I,CI}SW operations:
>>> +      */
>>> +     { Op1( 0), CRn( 7), CRm( 6), Op2( 2), access_dcsw },
>>> +     { Op1( 0), CRn( 7), CRm(10), Op2( 2), access_dcsw },
>>> +     { Op1( 0), CRn( 7), CRm(14), Op2( 2), access_dcsw },
>>> +     { Op1( 0), CRn( 9), CRm(12), Op2( 0), pm_fake },
>>> +     { Op1( 0), CRn( 9), CRm(12), Op2( 1), pm_fake },
>>> +     { Op1( 0), CRn( 9), CRm(12), Op2( 2), pm_fake },
>>> +     { Op1( 0), CRn( 9), CRm(12), Op2( 3), pm_fake },
>>> +     { Op1( 0), CRn( 9), CRm(12), Op2( 5), pm_fake },
>>> +     { Op1( 0), CRn( 9), CRm(12), Op2( 6), pm_fake },
>>> +     { Op1( 0), CRn( 9), CRm(12), Op2( 7), pm_fake },
>>> +     { Op1( 0), CRn( 9), CRm(13), Op2( 0), pm_fake },
>>> +     { Op1( 0), CRn( 9), CRm(13), Op2( 1), pm_fake },
>>> +     { Op1( 0), CRn( 9), CRm(13), Op2( 2), pm_fake },
>>> +     { Op1( 0), CRn( 9), CRm(14), Op2( 0), pm_fake },
>>> +     { Op1( 0), CRn( 9), CRm(14), Op2( 1), pm_fake },
>>> +     { Op1( 0), CRn( 9), CRm(14), Op2( 2), pm_fake },
>>>  };
>>>
>>>  /* Target specific emulation tables */
>>> @@ -285,13 +332,20 @@ void kvm_register_target_sys_reg_table(unsigned int target,
>>>  }
>>>
>>>  /* Get specific register table for this target. */
>>> -static const struct sys_reg_desc *get_target_table(unsigned target, size_t *num)
>>> +static const struct sys_reg_desc *get_target_table(unsigned target,
>>> +                                                bool mode_is_64,
>>> +                                                size_t *num)
>>>  {
>>>       struct kvm_sys_reg_target_table *table;
>>>
>>>       table = target_tables[target];
>>> -     *num = table->table64.num;
>>> -     return table->table64.table;
>>> +     if (mode_is_64) {
>>> +             *num = table->table64.num;
>>> +             return table->table64.table;
>>> +     } else {
>>> +             *num = table->table32.num;
>>> +             return table->table32.table;
>>> +     }
>>>  }
>>>
>>>  static const struct sys_reg_desc *find_reg(const struct sys_reg_params *params,
>>> @@ -319,13 +373,123 @@ static const struct sys_reg_desc *find_reg(const struct sys_reg_params *params,
>>>       return NULL;
>>>  }
>>>
>>> +int kvm_handle_cp14_load_store(struct kvm_vcpu *vcpu, struct kvm_run *run)
>>> +{
>>> +     kvm_inject_undefined(vcpu);
>>> +     return 1;
>>> +}
>>> +
>>> +int kvm_handle_cp14_access(struct kvm_vcpu *vcpu, struct kvm_run *run)
>>> +{
>>> +     kvm_inject_undefined(vcpu);
>>> +     return 1;
>>> +}
>>> +
>>> +static int emulate_cp15(struct kvm_vcpu *vcpu,
>>> +                     const struct sys_reg_params *params)
>>> +{
>>> +     size_t num;
>>> +     const struct sys_reg_desc *table, *r;
>>> +
>>> +     table = get_target_table(vcpu->arch.target, false, &num);
>>> +
>>> +     /* Search target-specific then generic table. */
>>> +     r = find_reg(params, table, num);
>>> +     if (!r)
>>> +             r = find_reg(params, cp15_regs, ARRAY_SIZE(cp15_regs));
>>> +
>>> +     if (likely(r)) {
>>> +             /* If we don't have an accessor, we should never get here! */
>>> +             BUG_ON(!r->access);
>>
>> again not quite sure if this warrants a crash of the entire host.
>>
>>> +
>>> +             if (likely(r->access(vcpu, params, r))) {
>>> +                     /* Skip instruction, since it was emulated */
>>> +                     kvm_skip_instr(vcpu, kvm_vcpu_trap_il_is32bit(vcpu));
>>> +                     return 1;
>>> +             }
>>> +             /* If access function fails, it should complain. */
>>> +     } else {
>>> +             kvm_err("Unsupported guest CP15 access at: %08lx\n",
>>> +                     *vcpu_pc(vcpu));
>>> +             print_sys_reg_instr(params);
>>> +     }
>>> +     kvm_inject_undefined(vcpu);
>>> +     return 1;
>>> +}
>>> +
>>> +/**
>>> + * kvm_handle_cp15_64 -- handles a mrrc/mcrr trap on a guest CP15 access
>>> + * @vcpu: The VCPU pointer
>>> + * @run:  The kvm_run struct
>>> + */
>>> +int kvm_handle_cp15_64(struct kvm_vcpu *vcpu, struct kvm_run *run)
>>> +{
>>> +     struct sys_reg_params params;
>>> +     u32 hsr = kvm_vcpu_get_hsr(vcpu);
>>> +     int Rt2 = (hsr >> 10) & 0xf;
>>> +     int ret;
>>> +
>>> +     params.CRm = (hsr >> 1) & 0xf;
>>> +     params.Rt = (hsr >> 5) & 0xf;
>>> +     params.is_write = ((hsr & 1) == 0);
>>> +
>>> +     params.Op0 = 0;
>>> +     params.Op1 = (hsr >> 16) & 0xf;
>>> +     params.Op2 = 0;
>>> +     params.CRn = 0;
>>> +
>>> +     /*
>>> +      * Massive hack here. Store Rt2 in the top 32bits so we only
>>> +      * have one register to deal with. As we use the same trap
>>> +      * backends between AArch32 and AArch64, we get away with it.
>>> +      */
>>> +     if (params.is_write) {
>>> +             u64 val = *vcpu_reg(vcpu, params.Rt);
>>> +             val &= 0xffffffff;
>>> +             val |= *vcpu_reg(vcpu, Rt2) << 32;
>>> +             *vcpu_reg(vcpu, params.Rt) = val;
>>> +     }
>>> +
>>> +     ret = emulate_cp15(vcpu, &params);
>>> +
>>> +     /* Reverse hack here */
>>
>> nit: consider changing the wording to something like 'Similar hack for
>> reads here', so readers don't think you are trying to reverse the hack
>> you did above.
>
> Sure.
>
>>> +     if (ret && !params.is_write) {
>>> +             u64 val = *vcpu_reg(vcpu, params.Rt);
>>> +             val >>= 32;
>>> +             *vcpu_reg(vcpu, Rt2) = val;
>>
>> actually the emulate_cp15 should probably be turned into a void and the
>> ret check could go away, same thing on the 32-bit side.
>
> Well, if we don't BUG_ON() in emulate_cp15, then we do want to return
> something that meaningfully shown that we failed to handle the trap.
>
yeah, but then we should also change the check to be 'if (ret >= 0 &&
...)' since 0 wouldn't be an error, or change emulate_cp15 to return a
bool or the conventional 0 or error code here... So something should
change is all I'm trying to say.


From cdall at cs.columbia.edu  Wed Apr 24 13:15:06 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Wed, 24 Apr 2013 10:15:06 -0700
Subject: [PATCH v3 29/32] arm64: KVM: 32bit guest fault injection
In-Reply-To: <5177E244.9000404@arm.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
 <1365437854-30214-30-git-send-email-marc.zyngier@arm.com>
 <20130423230214.GM20569@gmail.com> <5177E244.9000404@arm.com>
Message-ID: <CAEDV+g+J4NOcfAXB8QzXqo87mMTenK7kyXRPth_gHZBfOv80Ug@mail.gmail.com>

On Wed, Apr 24, 2013 at 6:46 AM, Marc Zyngier <marc.zyngier at arm.com> wrote:
> On 24/04/13 00:02, Christoffer Dall wrote:
>> On Mon, Apr 08, 2013 at 05:17:31PM +0100, Marc Zyngier wrote:
>>> Add fault injection capability for 32bit guests.
>>
>> looks ok, but seems we are duplicating some functionality here, but I
>> realize it may not be that easy to share due to different define names
>> for things like PSR_X_BIT...  Did you look further into this?
>
> I did, but as you noticed, the namespaces are different. We could
> probably define a set of KVM_AARCH32_* symbols, but I'm not sure it
> would be any nicer though.
>
yeah, it's not code that's very likely to change and evolve over time,
so I guess we can live with the duplication...


From cdall at cs.columbia.edu  Wed Apr 24 13:17:32 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Wed, 24 Apr 2013 10:17:32 -0700
Subject: [PATCH v3 30/32] arm64: KVM: enable initialization of a 32bit vcpu
In-Reply-To: <5177E303.7050801@arm.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
 <1365437854-30214-31-git-send-email-marc.zyngier@arm.com>
 <20130423230229.GN20569@gmail.com> <5177E303.7050801@arm.com>
Message-ID: <CAEDV+g+OL+37w9jA8=0WGea5FgW5y3mazqFzv9GLxDgjCe6dtg@mail.gmail.com>

On Wed, Apr 24, 2013 at 6:49 AM, Marc Zyngier <marc.zyngier at arm.com> wrote:
> On 24/04/13 00:02, Christoffer Dall wrote:
>> On Mon, Apr 08, 2013 at 05:17:32PM +0100, Marc Zyngier wrote:
>>> Wire the init of a 32bit vcpu by allowing 32bit modes in pstate,
>>> and providing sensible defaults out of reset state.
>>>
>>> This feature is of course conditioned by the presence of 32bit
>>> capability on the physical CPU, and is checked by the KVM_CAP_ARM_EL1_32BIT
>>> capability.
>>>
>>> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
>>> ---
>>>  arch/arm64/include/asm/kvm_host.h |  2 +-
>>>  arch/arm64/include/uapi/asm/kvm.h |  1 +
>>>  arch/arm64/kvm/guest.c            |  6 ++++++
>>>  arch/arm64/kvm/reset.c            | 25 ++++++++++++++++++++++++-
>>>  include/uapi/linux/kvm.h          |  1 +
>>>  5 files changed, 33 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
>>> index d44064d..c3ec107 100644
>>> --- a/arch/arm64/include/asm/kvm_host.h
>>> +++ b/arch/arm64/include/asm/kvm_host.h
>>> @@ -34,7 +34,7 @@
>>>  #include <asm/kvm_vgic.h>
>>>  #include <asm/kvm_arch_timer.h>
>>>
>>> -#define KVM_VCPU_MAX_FEATURES 1
>>> +#define KVM_VCPU_MAX_FEATURES 2
>>>
>>>  /* We don't currently support large pages. */
>>>  #define KVM_HPAGE_GFN_SHIFT(x)      0
>>> diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
>>> index 5b1110c..5031f42 100644
>>> --- a/arch/arm64/include/uapi/asm/kvm.h
>>> +++ b/arch/arm64/include/uapi/asm/kvm.h
>>> @@ -75,6 +75,7 @@ struct kvm_regs {
>>>  #define KVM_VGIC_V2_CPU_SIZE                0x2000
>>>
>>>  #define KVM_ARM_VCPU_POWER_OFF              0 /* CPU is started in OFF state */
>>> +#define KVM_ARM_VCPU_EL1_32BIT              1 /* CPU running a 32bit VM */
>>>
>>>  struct kvm_vcpu_init {
>>>      __u32 target;
>>> diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
>>> index 47d3729..74ef7d5 100644
>>> --- a/arch/arm64/kvm/guest.c
>>> +++ b/arch/arm64/kvm/guest.c
>>> @@ -93,6 +93,12 @@ static int set_core_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
>>>      if (off == KVM_REG_ARM_CORE_REG(regs.pstate)) {
>>>              unsigned long mode = (*(unsigned long *)valp) & COMPAT_PSR_MODE_MASK;
>>>              switch (mode) {
>>> +            case COMPAT_PSR_MODE_USR:
>>> +            case COMPAT_PSR_MODE_FIQ:
>>> +            case COMPAT_PSR_MODE_IRQ:
>>> +            case COMPAT_PSR_MODE_SVC:
>>> +            case COMPAT_PSR_MODE_ABT:
>>> +            case COMPAT_PSR_MODE_UND:
>>>              case PSR_MODE_EL0t:
>>>              case PSR_MODE_EL1t:
>>>              case PSR_MODE_EL1h:
>>> diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
>>> index bc33e76..a282d35 100644
>>> --- a/arch/arm64/kvm/reset.c
>>> +++ b/arch/arm64/kvm/reset.c
>>> @@ -35,11 +35,27 @@ static struct kvm_regs default_regs_reset = {
>>>      .regs.pstate = PSR_MODE_EL1h | PSR_A_BIT | PSR_I_BIT | PSR_F_BIT,
>>>  };
>>>
>>> +static struct kvm_regs default_regs_reset32 = {
>>> +    .regs.pstate = (COMPAT_PSR_MODE_SVC | COMPAT_PSR_A_BIT |
>>> +                    COMPAT_PSR_I_BIT | COMPAT_PSR_F_BIT),
>>> +};
>>> +
>>> +static bool cpu_has_32bit_el1(void)
>>> +{
>>> +    u64 pfr0;
>>> +
>>> +    pfr0 = read_cpuid(ID_AA64PFR0_EL1);
>>> +    return !!(pfr0 & 0x20);
>>
>> again we don't need the double negation
>
> I still hold that it makes things more readable.
>
>>> +}
>>> +
>>>  int kvm_arch_dev_ioctl_check_extention(long ext)
>>>  {
>>>      int r;
>>>
>>>      switch (ext) {
>>> +    case KVM_CAP_ARM_EL1_32BIT:
>>> +            r = cpu_has_32bit_el1();
>>> +            break;
>>>      default:
>>>              r = 0;
>>>      }
>>> @@ -62,7 +78,14 @@ int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
>>>
>>>      switch (vcpu->arch.target) {
>>>      default:
>>> -            cpu_reset = &default_regs_reset;
>>> +            if (test_bit(KVM_ARM_VCPU_EL1_32BIT, vcpu->arch.features)) {
>>> +                    if (!cpu_has_32bit_el1())
>>> +                            return -EINVAL;
>>
>> I'm not sure EINVAL is appropriate here, the value specified was not
>> incorrect, it's that the hardware doesn't support it. ENXIO, ENODEV, and
>> add that in Documentation/virtual/kvm/api.txt ?
>
> Not sure. If you ended up here, it means you tried to start a 32bit
> guest on a 64bit-only CPU, despite KVM_CAP_ARM_EL1_32BIT telling you
> that your CPU is not 32bit capable.
>
> This is clearly an invalid input, isn't it?
>
check the API documentation for this ioctl, I don't think that's the
type of invalid input meant when describing the meaning of EINVAL. If
you feel strongly about it of course it's no big deal, but I think
EINVAL is so overloaded anyway that telling the user something more
specific would be great, but I'll leave it up to you.


From nschichan at freebox.fr  Wed Apr 24 13:27:06 2013
From: nschichan at freebox.fr (Nicolas Schichan)
Date: Wed, 24 Apr 2013 19:27:06 +0200
Subject: [PATCH V3] Support for JIT in Seccomp BPF filters.
Message-ID: <1366824429-26652-1-git-send-email-nschichan@freebox.fr>

Hi,

This patch serie adds support for jitted seccomp BPF filters, with the
required modifications to make it work on the ARM architecture.

- The first patch in the serie adds the required boiler plate in the
  core kernel seccomp code to invoke the JIT compilation/free code.

- The second patch reworks the ARM BPF JIT code to make the generation
  process less dependent on struct sk_filter.

- The last patch actually implements the ARM part in the BPF jit code.

Some benchmarks, on a 1.6Ghz 88f6282 CPU:

Each system call is tested in two way (fast/slow):

 - on the fast version, the tested system call is accepted immediately
   after checking the architecture (5 BPF instructions).

 - on the slow version, the tested system call is accepted after
   previously checking for 85 syscall (90 instructions, including the
   architecture check).

The tested syscall is invoked in a loop 1000000 time, the reported
time is the time spent in the loop in seconds.

Without Seccomp JIT:

Syscall		Time-Fast  Time-Slow
--------------- ---------- ----------
gettimeofday	0.389	   1.633
getpid		0.406	   1.688
getresuid	1.003	   2.266
getcwd		1.342	   2.128

With Seccomp JIT:

Syscall		Time-Fast  Time-Slow
--------------- ----------- ---------
gettimeofday	0.348	    0.428
getpid		0.365	    0.480
getresuid	0.981	    1.060
getcwd		1.237	    1.294

For reference, the same code without any seccomp filter:

Syscall		Time
--------------- -----
gettimeofday	0.119
getpid		0.137
getresuid	0.747
getcwd		1.021

The activation of the BPF JIT for seccomp is still controled with the
/proc/sys/net/core/bpf_jit_enable sysctl knob.

Those changes are based on the latest rmk-for-next branch.

V2 Changes:
- Document the @bpf_func field in struct seccomp_filter as recommended
  by Kees Cook.
- Invoke seccomp_bpf_load directly from generated code without going
  via a wrapper.

V3 Changes:
- add accessors giving access to the fields in struct seccomp_filter
  as recommended by Andrew Morton. This avoids having to include
  <linux/filter.h> in <linux/seccomp.h>, and fixes broken include
  dependencies on x86_64 allmodconfig build.
- checkpatch fixes (void*) -> (void *)

Regards,


From nschichan at freebox.fr  Wed Apr 24 13:27:07 2013
From: nschichan at freebox.fr (Nicolas Schichan)
Date: Wed, 24 Apr 2013 19:27:07 +0200
Subject: [PATCH V3 1/3] seccomp: add generic code for jitted seccomp filters.
In-Reply-To: <1366824429-26652-1-git-send-email-nschichan@freebox.fr>
References: <1366824429-26652-1-git-send-email-nschichan@freebox.fr>
Message-ID: <1366824429-26652-2-git-send-email-nschichan@freebox.fr>

Architecture must select HAVE_SECCOMP_FILTER_JIT and implement
seccomp_jit_compile() and seccomp_jit_free() if they intend to support
jitted seccomp filters.

Accessors to struct seccomp_filter fields are provided in
<linux/seccomp.h> to be used by the JIT code. With this, the 'struct
seccomp_filter' structure can stay opaque when outside
kernel/seccomp.c.

In a way similar to the net BPF, the jit compilation code is expected
to updates struct seccomp_filter.bpf_func pointer (using the correct
accessor) to the generated code.

Signed-off-by: Nicolas Schichan <nschichan at freebox.fr>
---
 arch/Kconfig            |   14 ++++++++++++++
 include/linux/seccomp.h |   18 ++++++++++++++++++
 kernel/seccomp.c        |   33 ++++++++++++++++++++++++++++++++-
 3 files changed, 64 insertions(+), 1 deletion(-)

diff --git a/arch/Kconfig b/arch/Kconfig
index 1455579..370bc52 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -332,6 +332,10 @@ config HAVE_ARCH_SECCOMP_FILTER
 	  - secure_computing return value is checked and a return value of -1
 	    results in the system call being skipped immediately.
 
+# Used by archs to tell that they support SECCOMP_FILTER_JIT
+config HAVE_SECCOMP_FILTER_JIT
+	bool
+
 config SECCOMP_FILTER
 	def_bool y
 	depends on HAVE_ARCH_SECCOMP_FILTER && SECCOMP && NET
@@ -342,6 +346,16 @@ config SECCOMP_FILTER
 
 	  See Documentation/prctl/seccomp_filter.txt for details.
 
+config SECCOMP_FILTER_JIT
+	bool "enable Seccomp filter Just In Time compiler"
+	depends on HAVE_SECCOMP_FILTER_JIT && BPF_JIT && SECCOMP_FILTER
+	help
+	  Seccomp syscall filtering capabilities are normally handled
+	  by an interpreter. This option allows kernel to generate a native
+	  code when filter is loaded in memory. This should speedup
+	  syscall filtering. Note : Admin should enable this feature
+	  changing /proc/sys/net/core/bpf_jit_enable
+
 config HAVE_CONTEXT_TRACKING
 	bool
 	help
diff --git a/include/linux/seccomp.h b/include/linux/seccomp.h
index 6f19cfd..2793607 100644
--- a/include/linux/seccomp.h
+++ b/include/linux/seccomp.h
@@ -47,6 +47,24 @@ static inline int seccomp_mode(struct seccomp *s)
 	return s->mode;
 }
 
+#ifdef CONFIG_SECCOMP_FILTER_JIT
+extern void seccomp_jit_compile(struct seccomp_filter *fp);
+extern void seccomp_jit_free(struct seccomp_filter *fp);
+
+/*
+ * accessors used by seccomp JIT code to avoid having to declare the
+ * seccomp_filter struct here.
+ */
+unsigned short seccomp_filter_get_len(struct seccomp_filter *fp);
+struct sock_filter *seccomp_filter_get_insns(struct seccomp_filter *fp);
+void seccomp_filter_set_bpf_func(struct seccomp_filter *fp, void *func);
+void *seccomp_filter_get_bpf_func(struct seccomp_filter *fp);
+
+#else
+static inline void seccomp_jit_compile(struct seccomp_filter *fp) { }
+static inline void seccomp_jit_free(struct seccomp_filter *fp) { }
+#endif
+
 #else /* CONFIG_SECCOMP */
 
 #include <linux/errno.h>
diff --git a/kernel/seccomp.c b/kernel/seccomp.c
index b7a1004..2377414 100644
--- a/kernel/seccomp.c
+++ b/kernel/seccomp.c
@@ -39,6 +39,8 @@
  *         is only needed for handling filters shared across tasks.
  * @prev: points to a previously installed, or inherited, filter
  * @len: the number of instructions in the program
+ * @bpf_func: points to either sk_run_filter or the code generated
+ *         by the BPF JIT.
  * @insns: the BPF program instructions to evaluate
  *
  * seccomp_filter objects are organized in a tree linked via the @prev
@@ -55,6 +57,8 @@ struct seccomp_filter {
 	atomic_t usage;
 	struct seccomp_filter *prev;
 	unsigned short len;  /* Instruction count */
+	unsigned int (*bpf_func)(const struct sk_buff *skb,
+				 const struct sock_filter *filter);
 	struct sock_filter insns[];
 };
 
@@ -213,7 +217,7 @@ static u32 seccomp_run_filters(int syscall)
 	 * value always takes priority (ignoring the DATA).
 	 */
 	for (f = current->seccomp.filter; f; f = f->prev) {
-		u32 cur_ret = sk_run_filter(NULL, f->insns);
+		u32 cur_ret = f->bpf_func(NULL, f->insns);
 		if ((cur_ret & SECCOMP_RET_ACTION) < (ret & SECCOMP_RET_ACTION))
 			ret = cur_ret;
 	}
@@ -275,6 +279,9 @@ static long seccomp_attach_filter(struct sock_fprog *fprog)
 	if (ret)
 		goto fail;
 
+	filter->bpf_func = sk_run_filter;
+	seccomp_jit_compile(filter);
+
 	/*
 	 * If there is an existing filter, make it the prev and don't drop its
 	 * task reference.
@@ -332,10 +339,34 @@ void put_seccomp_filter(struct task_struct *tsk)
 	while (orig && atomic_dec_and_test(&orig->usage)) {
 		struct seccomp_filter *freeme = orig;
 		orig = orig->prev;
+		seccomp_jit_free(freeme);
 		kfree(freeme);
 	}
 }
 
+/*
+ * seccomp filter accessors for JIT code.
+ */
+unsigned short seccomp_filter_get_len(struct seccomp_filter *fp)
+{
+	return fp->len;
+}
+
+struct sock_filter *seccomp_filter_get_insns(struct seccomp_filter *fp)
+{
+	return fp->insns;
+}
+
+void seccomp_filter_set_bpf_func(struct seccomp_filter *fp, void *func)
+{
+	fp->bpf_func = func;
+}
+
+void *seccomp_filter_get_bpf_func(struct seccomp_filter *fp)
+{
+	return fp->bpf_func;
+}
+
 /**
  * seccomp_send_sigsys - signals the task to allow in-process syscall emulation
  * @syscall: syscall number to send to userland
-- 
1.7.10.4



From nschichan at freebox.fr  Wed Apr 24 13:27:08 2013
From: nschichan at freebox.fr (Nicolas Schichan)
Date: Wed, 24 Apr 2013 19:27:08 +0200
Subject: [PATCH V3 2/3] ARM: net: bpf_jit: make code generation less dependent
 on struct sk_filter.
In-Reply-To: <1366824429-26652-1-git-send-email-nschichan@freebox.fr>
References: <1366824429-26652-1-git-send-email-nschichan@freebox.fr>
Message-ID: <1366824429-26652-3-git-send-email-nschichan@freebox.fr>

This is in preparation of bpf_jit support for seccomp filters.

Signed-off-by: Nicolas Schichan <nschichan at freebox.fr>
---
 arch/arm/net/bpf_jit_32.c |   46 ++++++++++++++++++++++++++++-----------------
 1 file changed, 29 insertions(+), 17 deletions(-)

diff --git a/arch/arm/net/bpf_jit_32.c b/arch/arm/net/bpf_jit_32.c
index a0bd8a7..bb66a2b 100644
--- a/arch/arm/net/bpf_jit_32.c
+++ b/arch/arm/net/bpf_jit_32.c
@@ -55,7 +55,8 @@
 #define FLAG_NEED_X_RESET	(1 << 0)
 
 struct jit_ctx {
-	const struct sk_filter *skf;
+	unsigned short prog_len;
+	struct sock_filter *prog_insns;
 	unsigned idx;
 	unsigned prologue_bytes;
 	int ret0_fp_idx;
@@ -131,8 +132,8 @@ static u16 saved_regs(struct jit_ctx *ctx)
 {
 	u16 ret = 0;
 
-	if ((ctx->skf->len > 1) ||
-	    (ctx->skf->insns[0].code == BPF_S_RET_A))
+	if ((ctx->prog_len > 1) ||
+	    (ctx->prog_insns[0].code == BPF_S_RET_A))
 		ret |= 1 << r_A;
 
 #ifdef CONFIG_FRAME_POINTER
@@ -181,7 +182,7 @@ static inline bool is_load_to_a(u16 inst)
 static void build_prologue(struct jit_ctx *ctx)
 {
 	u16 reg_set = saved_regs(ctx);
-	u16 first_inst = ctx->skf->insns[0].code;
+	u16 first_inst = ctx->prog_insns[0].code;
 	u16 off;
 
 #ifdef CONFIG_FRAME_POINTER
@@ -279,7 +280,7 @@ static u16 imm_offset(u32 k, struct jit_ctx *ctx)
 		ctx->imms[i] = k;
 
 	/* constants go just after the epilogue */
-	offset =  ctx->offsets[ctx->skf->len];
+	offset =  ctx->offsets[ctx->prog_len];
 	offset += ctx->prologue_bytes;
 	offset += ctx->epilogue_bytes;
 	offset += i * 4;
@@ -419,7 +420,7 @@ static inline void emit_err_ret(u8 cond, struct jit_ctx *ctx)
 		emit(ARM_MOV_R(ARM_R0, ARM_R0), ctx);
 	} else {
 		_emit(cond, ARM_MOV_I(ARM_R0, 0), ctx);
-		_emit(cond, ARM_B(b_imm(ctx->skf->len, ctx)), ctx);
+		_emit(cond, ARM_B(b_imm(ctx->prog_len, ctx)), ctx);
 	}
 }
 
@@ -469,14 +470,13 @@ static inline void update_on_xread(struct jit_ctx *ctx)
 static int build_body(struct jit_ctx *ctx)
 {
 	void *load_func[] = {jit_get_skb_b, jit_get_skb_h, jit_get_skb_w};
-	const struct sk_filter *prog = ctx->skf;
 	const struct sock_filter *inst;
 	unsigned i, load_order, off, condt;
 	int imm12;
 	u32 k;
 
-	for (i = 0; i < prog->len; i++) {
-		inst = &(prog->insns[i]);
+	for (i = 0; i < ctx->prog_len; i++) {
+		inst = &(ctx->prog_insns[i]);
 		/* K as an immediate value operand */
 		k = inst->k;
 
@@ -769,8 +769,8 @@ cmp_x:
 				ctx->ret0_fp_idx = i;
 			emit_mov_i(ARM_R0, k, ctx);
 b_epilogue:
-			if (i != ctx->skf->len - 1)
-				emit(ARM_B(b_imm(prog->len, ctx)), ctx);
+			if (i != ctx->prog_len - 1)
+				emit(ARM_B(b_imm(ctx->prog_len, ctx)), ctx);
 			break;
 		case BPF_S_MISC_TAX:
 			/* X = A */
@@ -858,7 +858,7 @@ b_epilogue:
 }
 
 
-void bpf_jit_compile(struct sk_filter *fp)
+static void __bpf_jit_compile(struct jit_ctx *out_ctx)
 {
 	struct jit_ctx ctx;
 	unsigned tmp_idx;
@@ -867,11 +867,10 @@ void bpf_jit_compile(struct sk_filter *fp)
 	if (!bpf_jit_enable)
 		return;
 
-	memset(&ctx, 0, sizeof(ctx));
-	ctx.skf		= fp;
+	ctx = *out_ctx;
 	ctx.ret0_fp_idx = -1;
 
-	ctx.offsets = kzalloc(4 * (ctx.skf->len + 1), GFP_KERNEL);
+	ctx.offsets = kzalloc(4 * (ctx.prog_len + 1), GFP_KERNEL);
 	if (ctx.offsets == NULL)
 		return;
 
@@ -921,13 +920,26 @@ void bpf_jit_compile(struct sk_filter *fp)
 		print_hex_dump(KERN_INFO, "BPF JIT code: ",
 			       DUMP_PREFIX_ADDRESS, 16, 4, ctx.target,
 			       alloc_size, false);
-
-	fp->bpf_func = (void *)ctx.target;
 out:
 	kfree(ctx.offsets);
+
+	*out_ctx = ctx;
 	return;
 }
 
+void bpf_jit_compile(struct sk_filter *fp)
+{
+	struct jit_ctx ctx;
+
+	memset(&ctx, 0, sizeof(ctx));
+	ctx.prog_len = fp->len;
+	ctx.prog_insns = fp->insns;
+
+	__bpf_jit_compile(&ctx);
+	if (ctx.target)
+		fp->bpf_func = (void *)ctx.target;
+}
+
 static void bpf_jit_free_worker(struct work_struct *work)
 {
 	module_free(NULL, work);
-- 
1.7.10.4



From nschichan at freebox.fr  Wed Apr 24 13:27:09 2013
From: nschichan at freebox.fr (Nicolas Schichan)
Date: Wed, 24 Apr 2013 19:27:09 +0200
Subject: [PATCH V3 3/3] ARM: net: bpf_jit: add support for jitted seccomp
 filters.
In-Reply-To: <1366824429-26652-1-git-send-email-nschichan@freebox.fr>
References: <1366824429-26652-1-git-send-email-nschichan@freebox.fr>
Message-ID: <1366824429-26652-4-git-send-email-nschichan@freebox.fr>

This patch selects HAVE_SECCOMP_FILTER_JIT in the ARM Kconfig file,
implements seccomp_jit_compile() and seccomp_jit_free(), and adds
support for BPF_S_ANC_SECCOMP_LD_W instruction.

BPF_S_ANC_SECCOMP_LD_W instructions trigger the generation of a call
to C function seccomp_bpf_load().

Signed-off-by: Nicolas Schichan <nschichan at freebox.fr>
---
 arch/arm/Kconfig          |    1 +
 arch/arm/net/bpf_jit_32.c |   37 +++++++++++++++++++++++++++++++++++++
 2 files changed, 38 insertions(+)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 60b9876..d2e5d39 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -24,6 +24,7 @@ config ARM
 	select HAVE_ARCH_SECCOMP_FILTER
 	select HAVE_ARCH_TRACEHOOK
 	select HAVE_BPF_JIT
+	select HAVE_SECCOMP_FILTER_JIT
 	select HAVE_C_RECORDMCOUNT
 	select HAVE_DEBUG_KMEMLEAK
 	select HAVE_DMA_API_DEBUG
diff --git a/arch/arm/net/bpf_jit_32.c b/arch/arm/net/bpf_jit_32.c
index bb66a2b..4b89f50 100644
--- a/arch/arm/net/bpf_jit_32.c
+++ b/arch/arm/net/bpf_jit_32.c
@@ -548,6 +548,15 @@ load_common:
 			emit_err_ret(ARM_COND_NE, ctx);
 			emit(ARM_MOV_R(r_A, ARM_R0), ctx);
 			break;
+#ifdef CONFIG_SECCOMP_FILTER_JIT
+		case BPF_S_ANC_SECCOMP_LD_W:
+			ctx->seen |= SEEN_CALL;
+			emit_mov_i(ARM_R3, (u32)seccomp_bpf_load, ctx);
+			emit_mov_i(ARM_R0, k, ctx);
+			emit_blx_r(ARM_R3, ctx);
+			emit(ARM_MOV_R(r_A, ARM_R0), ctx);
+			break;
+#endif
 		case BPF_S_LD_W_IND:
 			load_order = 2;
 			goto load_ind;
@@ -956,3 +965,31 @@ void bpf_jit_free(struct sk_filter *fp)
 		schedule_work(work);
 	}
 }
+
+#ifdef CONFIG_SECCOMP_FILTER_JIT
+void seccomp_jit_compile(struct seccomp_filter *fp)
+{
+	struct jit_ctx ctx;
+
+	memset(&ctx, 0, sizeof(ctx));
+	ctx.prog_len = seccomp_filter_get_len(fp);
+	ctx.prog_insns = seccomp_filter_get_insns(fp);
+
+	__bpf_jit_compile(&ctx);
+	if (ctx.target)
+		seccomp_filter_set_bpf_func(fp, (void *)ctx.target);
+}
+
+void seccomp_jit_free(struct seccomp_filter *fp)
+{
+	struct work_struct *work;
+	void *bpf_func = seccomp_filter_get_bpf_func(fp);
+
+	if (bpf_func != sk_run_filter) {
+		work = (struct work_struct *)bpf_func;
+
+		INIT_WORK(work, bpf_jit_free_worker);
+		schedule_work(work);
+	}
+}
+#endif
-- 
1.7.10.4



From lorenzo.pieralisi at arm.com  Wed Apr 24 13:28:06 2013
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Wed, 24 Apr 2013 18:28:06 +0100
Subject: [RFC PATCH v3 01/17] ARM: DT: kernel: move temporary cpu map stack
 array to static data
In-Reply-To: <1366824502-19729-1-git-send-email-lorenzo.pieralisi@arm.com>
References: <1366824502-19729-1-git-send-email-lorenzo.pieralisi@arm.com>
Message-ID: <1366824502-19729-2-git-send-email-lorenzo.pieralisi@arm.com>

As the number of CPUs increase, the temporary array allocated on the
stack in arm_dt_init_cpu_maps() can become too big and trigger stack
issues.
This patch moves the allocated memory to static __initdata so that stack
data is not used anymore to allocate the temporary array.
Memory is marked as __initdata since it need not be persistent after boot.

Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
---
 arch/arm/kernel/devtree.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
index 70f1bde..f149217 100644
--- a/arch/arm/kernel/devtree.c
+++ b/arch/arm/kernel/devtree.c
@@ -78,11 +78,12 @@ void __init arm_dt_init_cpu_maps(void)
 	 * contain a list of MPIDR[23:0] values where MPIDR[31:24] must
 	 * read as 0.
 	 */
+	static u32 tmp_map[NR_CPUS] __initdata = {
+				[0 ... NR_CPUS-1] = UINT_MAX };
 	struct device_node *cpu, *cpus;
 	u32 i, j, cpuidx = 1;
 	u32 mpidr = is_smp() ? read_cpuid_mpidr() & MPIDR_HWID_BITMASK : 0;
 
-	u32 tmp_map[NR_CPUS] = { [0 ... NR_CPUS-1] = UINT_MAX };
 	bool bootcpu_valid = false;
 	cpus = of_find_node_by_path("/cpus");
 
-- 
1.7.12




From lorenzo.pieralisi at arm.com  Wed Apr 24 13:28:05 2013
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Wed, 24 Apr 2013 18:28:05 +0100
Subject: [RFC PATCH v3 00/17] ARM: DT cpu bindings updates
Message-ID: <1366824502-19729-1-git-send-email-lorenzo.pieralisi@arm.com>

This patchset is an update of a previous posting:

http://lists.infradead.org/pipermail/linux-arm-kernel/2013-April/164587.html

v3 changes:

- More dts fixes of in-kernel dts
- Defined ARM v8 behaviour with different cpus node #address-cells
- Added pre ARM11 processors suffixes in the cpu node compatible list
- Reordered series
- Reworded #address-cells definition
- Added ARM v8 - cores running on AArch32 bindings example
- Moved WARN* calls on one line to prevent grepping issues

v2 changes:

- Reworded DT cpu bindings
- Split the set, with per-mach specific dts updates
- Updated cpu node compatible string list
- Defined behaviour of OS running on v8 in AArch32

The introduction of DT cpus/cpu bindings for ARM requires well established
rules to enforce the reg property definition for 32-bit and 64-bit ARM
processors, inclusive of legacy and current uniprocessor/SMP systems.

ARM 64 bit architecture also requires dtb compiled for 64-bit configurations
to be reused for kernels running in 32 bit mode, so the cpus/cpu bindings
specification must be made compliant to cope with this configuration.

Patch #1 of this series is a fix and is included to have a clean patch
series and should get reviewed and merged separately.

Patch #2-17, along with some kernel fixes related to DT parsing function,
update the cpu node bindings and in kernel dts files to cope with legacy,
current and upcoming ARM systems.

In-kernel device tree source files are updated to comply with the latest
specification, so thorough testing is required in order to validate all
changes on all affected ARM systems, in particular systems with exotic
MPIDR configurations that are likely to break with the changes provided.

Code relying on the reg property size to be 4-bytes must be updated so that
dtbs compiled for 64-bit kernels can also be used to boot a 32-bit system.

Lorenzo Pieralisi (17):
  ARM: DT: kernel: move temporary cpu map stack array to static data
  Documentation: devicetree: arm: cpus/cpu nodes bindings updates
  ARM: dts: am33xx: cpus/cpu nodes dts updates
  ARM: dts: armada-370-xp: cpus/cpu node dts updates
  ARM: dts: at91: cpus/cpu node dts updates
  ARM: dts: exynos5440: cpus/cpu nodes dts updates
  ARM: dts: imx: cpus/cpu nodes dts updates
  ARM: dts: lpc32xx: cpus/cpu nodes dts updates
  ARM: dts: omap: cpus/cpu nodes dts updates
  ARM: dts: picoxcell: cpus/cpu nodes dts updates
  ARM: dts: prima2: cpus/cpu node dts updates
  ARM: dts: pxa2xx: cpus/cpu nodes dts updates
  ARM: dts: r8a7740: cpus/cpu nodes dts updates
  ARM: dts: sh7372: cpus/cpu nodes dts updates
  ARM: dts: spear: cpus/cpu nodes dts updates
  ARM: dts: sunxi: cpus/cpu nodes dts updates
  ARM: DT: kernel: DT cpus/cpu node bindings update

 Documentation/devicetree/bindings/arm/cpus.txt | 457 ++++++++++++++++++++++---
 arch/arm/boot/dts/am33xx.dtsi                  |   4 +
 arch/arm/boot/dts/armada-370-xp.dtsi           |   4 +
 arch/arm/boot/dts/at91rm9200.dtsi              |   6 +-
 arch/arm/boot/dts/at91sam9260.dtsi             |   8 +-
 arch/arm/boot/dts/at91sam9263.dtsi             |   8 +-
 arch/arm/boot/dts/at91sam9g45.dtsi             |   8 +-
 arch/arm/boot/dts/at91sam9n12.dtsi             |   8 +-
 arch/arm/boot/dts/at91sam9x5.dtsi              |   8 +-
 arch/arm/boot/dts/exynos5440.dtsi              |  11 +
 arch/arm/boot/dts/imx23.dtsi                   |   8 +-
 arch/arm/boot/dts/imx28.dtsi                   |   8 +-
 arch/arm/boot/dts/imx6dl.dtsi                  |   2 +
 arch/arm/boot/dts/imx6q.dtsi                   |   1 +
 arch/arm/boot/dts/lpc32xx.dtsi                 |   8 +-
 arch/arm/boot/dts/omap2.dtsi                   |   6 +-
 arch/arm/boot/dts/omap3.dtsi                   |   5 +
 arch/arm/boot/dts/omap4.dtsi                   |   7 +
 arch/arm/boot/dts/omap5.dtsi                   |   7 +
 arch/arm/boot/dts/picoxcell-pc3x2.dtsi         |   8 +-
 arch/arm/boot/dts/picoxcell-pc3x3.dtsi         |   8 +-
 arch/arm/boot/dts/prima2.dtsi                  |   2 +
 arch/arm/boot/dts/pxa2xx.dtsi                  |   7 +-
 arch/arm/boot/dts/r8a7740.dtsi                 |   4 +
 arch/arm/boot/dts/sh7372.dtsi                  |   5 +
 arch/arm/boot/dts/spear13xx.dtsi               |   2 +
 arch/arm/boot/dts/spear3xx.dtsi                |   8 +-
 arch/arm/boot/dts/spear600.dtsi                |   8 +-
 arch/arm/boot/dts/sunxi.dtsi                   |   5 +
 arch/arm/kernel/devtree.c                      |  81 +++--
 30 files changed, 602 insertions(+), 110 deletions(-)

-- 
1.7.12




From lorenzo.pieralisi at arm.com  Wed Apr 24 13:28:13 2013
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Wed, 24 Apr 2013 18:28:13 +0100
Subject: [RFC PATCH v3 08/17] ARM: dts: lpc32xx: cpus/cpu nodes dts updates
In-Reply-To: <1366824502-19729-1-git-send-email-lorenzo.pieralisi@arm.com>
References: <1366824502-19729-1-git-send-email-lorenzo.pieralisi@arm.com>
Message-ID: <1366824502-19729-9-git-send-email-lorenzo.pieralisi@arm.com>

This patch updates the in-kernel dts files according to the latest cpus
and cpu bindings updates for ARM.

Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
---
 arch/arm/boot/dts/lpc32xx.dtsi | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/lpc32xx.dtsi b/arch/arm/boot/dts/lpc32xx.dtsi
index 1582f48..3abebb7 100644
--- a/arch/arm/boot/dts/lpc32xx.dtsi
+++ b/arch/arm/boot/dts/lpc32xx.dtsi
@@ -18,8 +18,12 @@
 	interrupt-parent = <&mic>;
 
 	cpus {
-		cpu at 0 {
-			compatible = "arm,arm926ejs";
+		#address-cells = <0>;
+		#size-cells = <0>;
+
+		cpu {
+			compatible = "arm,arm926ej-s";
+			device_type = "cpu";
 		};
 	};
 
-- 
1.7.12




From lorenzo.pieralisi at arm.com  Wed Apr 24 13:28:12 2013
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Wed, 24 Apr 2013 18:28:12 +0100
Subject: [RFC PATCH v3 07/17] ARM: dts: imx: cpus/cpu nodes dts updates
In-Reply-To: <1366824502-19729-1-git-send-email-lorenzo.pieralisi@arm.com>
References: <1366824502-19729-1-git-send-email-lorenzo.pieralisi@arm.com>
Message-ID: <1366824502-19729-8-git-send-email-lorenzo.pieralisi@arm.com>

This patch updates the in-kernel dts files according to the latest cpus
and cpu bindings updates for ARM.

Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
---
 arch/arm/boot/dts/imx23.dtsi  | 8 ++++++--
 arch/arm/boot/dts/imx28.dtsi  | 8 ++++++--
 arch/arm/boot/dts/imx6dl.dtsi | 2 ++
 arch/arm/boot/dts/imx6q.dtsi  | 1 +
 4 files changed, 15 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/imx23.dtsi b/arch/arm/boot/dts/imx23.dtsi
index 56afcf4..0aae18b 100644
--- a/arch/arm/boot/dts/imx23.dtsi
+++ b/arch/arm/boot/dts/imx23.dtsi
@@ -23,8 +23,12 @@
 	};
 
 	cpus {
-		cpu at 0 {
-			compatible = "arm,arm926ejs";
+		#address-cells = <0>;
+		#size-cells = <0>;
+
+		cpu {
+			compatible = "arm,arm926ej-s";
+			device_type = "cpu";
 		};
 	};
 
diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
index 7ba4966..07f131fc 100644
--- a/arch/arm/boot/dts/imx28.dtsi
+++ b/arch/arm/boot/dts/imx28.dtsi
@@ -32,8 +32,12 @@
 	};
 
 	cpus {
-		cpu at 0 {
-			compatible = "arm,arm926ejs";
+		#address-cells = <0>;
+		#size-cells = <0>;
+
+		cpu {
+			compatible = "arm,arm926ej-s";
+			device_type = "cpu";
 		};
 	};
 
diff --git a/arch/arm/boot/dts/imx6dl.dtsi b/arch/arm/boot/dts/imx6dl.dtsi
index 63fafe2..b76d85e 100644
--- a/arch/arm/boot/dts/imx6dl.dtsi
+++ b/arch/arm/boot/dts/imx6dl.dtsi
@@ -16,12 +16,14 @@
 
 		cpu at 0 {
 			compatible = "arm,cortex-a9";
+			device_type = "cpu";
 			reg = <0>;
 			next-level-cache = <&L2>;
 		};
 
 		cpu at 1 {
 			compatible = "arm,cortex-a9";
+			device_type = "cpu";
 			reg = <1>;
 			next-level-cache = <&L2>;
 		};
diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
index cba021e..65c1b62 100644
--- a/arch/arm/boot/dts/imx6q.dtsi
+++ b/arch/arm/boot/dts/imx6q.dtsi
@@ -17,6 +17,7 @@
 
 		cpu at 0 {
 			compatible = "arm,cortex-a9";
+			device_type = "cpu";
 			reg = <0>;
 			next-level-cache = <&L2>;
 			operating-points = <
-- 
1.7.12




From lorenzo.pieralisi at arm.com  Wed Apr 24 13:28:10 2013
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Wed, 24 Apr 2013 18:28:10 +0100
Subject: [RFC PATCH v3 05/17] ARM: dts: at91: cpus/cpu node dts updates
In-Reply-To: <1366824502-19729-1-git-send-email-lorenzo.pieralisi@arm.com>
References: <1366824502-19729-1-git-send-email-lorenzo.pieralisi@arm.com>
Message-ID: <1366824502-19729-6-git-send-email-lorenzo.pieralisi@arm.com>

This patch updates the in-kernel dts files according to the latest cpus
and cpu bindings updates for ARM.

Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
---
 arch/arm/boot/dts/at91rm9200.dtsi  | 6 +++++-
 arch/arm/boot/dts/at91sam9260.dtsi | 8 ++++++--
 arch/arm/boot/dts/at91sam9263.dtsi | 8 ++++++--
 arch/arm/boot/dts/at91sam9g45.dtsi | 8 ++++++--
 arch/arm/boot/dts/at91sam9n12.dtsi | 8 ++++++--
 arch/arm/boot/dts/at91sam9x5.dtsi  | 8 ++++++--
 6 files changed, 35 insertions(+), 11 deletions(-)

diff --git a/arch/arm/boot/dts/at91rm9200.dtsi b/arch/arm/boot/dts/at91rm9200.dtsi
index b0268a5..f16b3d4 100644
--- a/arch/arm/boot/dts/at91rm9200.dtsi
+++ b/arch/arm/boot/dts/at91rm9200.dtsi
@@ -34,8 +34,12 @@
 		ssc2 = &ssc2;
 	};
 	cpus {
-		cpu at 0 {
+		#address-cells = <0>;
+		#size-cells = <0>;
+
+		cpu {
 			compatible = "arm,arm920t";
+			device_type = "cpu";
 		};
 	};
 
diff --git a/arch/arm/boot/dts/at91sam9260.dtsi b/arch/arm/boot/dts/at91sam9260.dtsi
index cb7bcc5..c4eeef7 100644
--- a/arch/arm/boot/dts/at91sam9260.dtsi
+++ b/arch/arm/boot/dts/at91sam9260.dtsi
@@ -32,8 +32,12 @@
 		ssc0 = &ssc0;
 	};
 	cpus {
-		cpu at 0 {
-			compatible = "arm,arm926ejs";
+		#address-cells = <0>;
+		#size-cells = <0>;
+
+		cpu {
+			compatible = "arm,arm926ej-s";
+			device_type = "cpu";
 		};
 	};
 
diff --git a/arch/arm/boot/dts/at91sam9263.dtsi b/arch/arm/boot/dts/at91sam9263.dtsi
index 271d4de..f3b5c2a 100644
--- a/arch/arm/boot/dts/at91sam9263.dtsi
+++ b/arch/arm/boot/dts/at91sam9263.dtsi
@@ -29,8 +29,12 @@
 		ssc1 = &ssc1;
 	};
 	cpus {
-		cpu at 0 {
-			compatible = "arm,arm926ejs";
+		#address-cells = <0>;
+		#size-cells = <0>;
+
+		cpu {
+			compatible = "arm,arm926ej-s";
+			device_type = "cpu";
 		};
 	};
 
diff --git a/arch/arm/boot/dts/at91sam9g45.dtsi b/arch/arm/boot/dts/at91sam9g45.dtsi
index 6b1d4ca..6c18bd3 100644
--- a/arch/arm/boot/dts/at91sam9g45.dtsi
+++ b/arch/arm/boot/dts/at91sam9g45.dtsi
@@ -35,8 +35,12 @@
 		ssc1 = &ssc1;
 	};
 	cpus {
-		cpu at 0 {
-			compatible = "arm,arm926ejs";
+		#address-cells = <0>;
+		#size-cells = <0>;
+
+		cpu {
+			compatible = "arm,arm926ej-s";
+			device_type = "cpu";
 		};
 	};
 
diff --git a/arch/arm/boot/dts/at91sam9n12.dtsi b/arch/arm/boot/dts/at91sam9n12.dtsi
index 7750f98..c3b11af 100644
--- a/arch/arm/boot/dts/at91sam9n12.dtsi
+++ b/arch/arm/boot/dts/at91sam9n12.dtsi
@@ -31,8 +31,12 @@
 		ssc0 = &ssc0;
 	};
 	cpus {
-		cpu at 0 {
-			compatible = "arm,arm926ejs";
+		#address-cells = <0>;
+		#size-cells = <0>;
+
+		cpu {
+			compatible = "arm,arm926ej-s";
+			device_type = "cpu";
 		};
 	};
 
diff --git a/arch/arm/boot/dts/at91sam9x5.dtsi b/arch/arm/boot/dts/at91sam9x5.dtsi
index aa98e64..6c39d0f 100644
--- a/arch/arm/boot/dts/at91sam9x5.dtsi
+++ b/arch/arm/boot/dts/at91sam9x5.dtsi
@@ -33,8 +33,12 @@
 		ssc0 = &ssc0;
 	};
 	cpus {
-		cpu at 0 {
-			compatible = "arm,arm926ejs";
+		#address-cells = <0>;
+		#size-cells = <0>;
+
+		cpu {
+			compatible = "arm,arm926ej-s";
+			device_type = "cpu";
 		};
 	};
 
-- 
1.7.12




From lorenzo.pieralisi at arm.com  Wed Apr 24 13:28:17 2013
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Wed, 24 Apr 2013 18:28:17 +0100
Subject: [RFC PATCH v3 12/17] ARM: dts: pxa2xx: cpus/cpu nodes dts updates
In-Reply-To: <1366824502-19729-1-git-send-email-lorenzo.pieralisi@arm.com>
References: <1366824502-19729-1-git-send-email-lorenzo.pieralisi@arm.com>
Message-ID: <1366824502-19729-13-git-send-email-lorenzo.pieralisi@arm.com>

This patch updates the in-kernel dts files according to the latest cpus
and cpu bindings updates for ARM.

Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
---
 arch/arm/boot/dts/pxa2xx.dtsi | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/pxa2xx.dtsi b/arch/arm/boot/dts/pxa2xx.dtsi
index f18aad3..a5e90f0 100644
--- a/arch/arm/boot/dts/pxa2xx.dtsi
+++ b/arch/arm/boot/dts/pxa2xx.dtsi
@@ -23,8 +23,11 @@
 	};
 
 	cpus {
-		cpu at 0 {
-			compatible = "arm,xscale";
+		#address-cells = <0>;
+		#size-cells = <0>;
+		cpu {
+			compatible = "marvell,xscale";
+			device_type = "cpu";
 		};
 	};
 
-- 
1.7.12




From lorenzo.pieralisi at arm.com  Wed Apr 24 13:28:19 2013
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Wed, 24 Apr 2013 18:28:19 +0100
Subject: [RFC PATCH v3 14/17] ARM: dts: sh7372: cpus/cpu nodes dts updates
In-Reply-To: <1366824502-19729-1-git-send-email-lorenzo.pieralisi@arm.com>
References: <1366824502-19729-1-git-send-email-lorenzo.pieralisi@arm.com>
Message-ID: <1366824502-19729-15-git-send-email-lorenzo.pieralisi@arm.com>

This patch updates the in-kernel dts files according to the latest cpus
and cpu bindings updates for ARM.

Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
---
 arch/arm/boot/dts/sh7372.dtsi | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/sh7372.dtsi b/arch/arm/boot/dts/sh7372.dtsi
index 677fc60..7bf020e 100644
--- a/arch/arm/boot/dts/sh7372.dtsi
+++ b/arch/arm/boot/dts/sh7372.dtsi
@@ -14,8 +14,13 @@
 	compatible = "renesas,sh7372";
 
 	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
 		cpu at 0 {
 			compatible = "arm,cortex-a8";
+			device_type = "cpu";
+			reg = <0x0>;
 		};
 	};
 };
-- 
1.7.12




From lorenzo.pieralisi at arm.com  Wed Apr 24 13:28:14 2013
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Wed, 24 Apr 2013 18:28:14 +0100
Subject: [RFC PATCH v3 09/17] ARM: dts: omap: cpus/cpu nodes dts updates
In-Reply-To: <1366824502-19729-1-git-send-email-lorenzo.pieralisi@arm.com>
References: <1366824502-19729-1-git-send-email-lorenzo.pieralisi@arm.com>
Message-ID: <1366824502-19729-10-git-send-email-lorenzo.pieralisi@arm.com>

This patch updates the in-kernel dts files according to the latest cpus
and cpu bindings updates for ARM.

Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
---
 arch/arm/boot/dts/omap2.dtsi | 6 +++++-
 arch/arm/boot/dts/omap3.dtsi | 5 +++++
 arch/arm/boot/dts/omap4.dtsi | 7 +++++++
 arch/arm/boot/dts/omap5.dtsi | 7 +++++++
 4 files changed, 24 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/omap2.dtsi b/arch/arm/boot/dts/omap2.dtsi
index 761c4b6..4183027 100644
--- a/arch/arm/boot/dts/omap2.dtsi
+++ b/arch/arm/boot/dts/omap2.dtsi
@@ -21,8 +21,12 @@
 	};
 
 	cpus {
-		cpu at 0 {
+		#address-cells = <0>;
+		#size-cells = <0>;
+
+		cpu {
 			compatible = "arm,arm1136jf-s";
+			device_type = "cpu";
 		};
 	};
 
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 1acc261..b6f6502 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -21,8 +21,13 @@
 	};
 
 	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
 		cpu at 0 {
 			compatible = "arm,cortex-a8";
+			device_type = "cpu";
+			reg = <0x0>;
 		};
 	};
 
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 739bb79..e0f943f 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -28,13 +28,20 @@
 	};
 
 	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
 		cpu at 0 {
 			compatible = "arm,cortex-a9";
+			device_type = "cpu";
 			next-level-cache = <&L2>;
+			reg = <0x0>;
 		};
 		cpu at 1 {
 			compatible = "arm,cortex-a9";
+			device_type = "cpu";
 			next-level-cache = <&L2>;
+			reg = <0x1>;
 		};
 	};
 
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 790bb2a..e3cc688 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -31,8 +31,13 @@
 	};
 
 	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
 		cpu at 0 {
 			compatible = "arm,cortex-a15";
+			device_type = "cpu";
+			reg = <0x0>;
 			timer {
 				compatible = "arm,armv7-timer";
 				/* 14th PPI IRQ, active low level-sensitive */
@@ -42,6 +47,8 @@
 		};
 		cpu at 1 {
 			compatible = "arm,cortex-a15";
+			device_type = "cpu";
+			reg = <0x1>;
 			timer {
 				compatible = "arm,armv7-timer";
 				/* 14th PPI IRQ, active low level-sensitive */
-- 
1.7.12




From lorenzo.pieralisi at arm.com  Wed Apr 24 13:28:11 2013
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Wed, 24 Apr 2013 18:28:11 +0100
Subject: [RFC PATCH v3 06/17] ARM: dts: exynos5440: cpus/cpu nodes dts updates
In-Reply-To: <1366824502-19729-1-git-send-email-lorenzo.pieralisi@arm.com>
References: <1366824502-19729-1-git-send-email-lorenzo.pieralisi@arm.com>
Message-ID: <1366824502-19729-7-git-send-email-lorenzo.pieralisi@arm.com>

This patch updates the in-kernel dts files according to the latest cpus
and cpu bindings updates for ARM.

Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
---
 arch/arm/boot/dts/exynos5440.dtsi | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5440.dtsi b/arch/arm/boot/dts/exynos5440.dtsi
index 5f3562a..fd0966f 100644
--- a/arch/arm/boot/dts/exynos5440.dtsi
+++ b/arch/arm/boot/dts/exynos5440.dtsi
@@ -24,8 +24,13 @@
 	};
 
 	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
 		cpu at 0 {
 			compatible = "arm,cortex-a15";
+			device_type = "cpu";
+			reg = <0x0>;
 			timer {
 				compatible = "arm,armv7-timer";
 				interrupts = <1 13 0xf08>;
@@ -34,6 +39,8 @@
 		};
 		cpu at 1 {
 			compatible = "arm,cortex-a15";
+			device_type = "cpu";
+			reg = <0x1>;
 			timer {
 				compatible = "arm,armv7-timer";
 				interrupts = <1 14 0xf08>;
@@ -42,6 +49,8 @@
 		};
 		cpu at 2 {
 			compatible = "arm,cortex-a15";
+			device_type = "cpu";
+			reg = <0x2>;
 			timer {
 				compatible = "arm,armv7-timer";
 				interrupts = <1 14 0xf08>;
@@ -50,6 +59,8 @@
 		};
 		cpu at 3 {
 			compatible = "arm,cortex-a15";
+			device_type = "cpu";
+			reg = <0x3>;
 			timer {
 				compatible = "arm,armv7-timer";
 				interrupts = <1 14 0xf08>;
-- 
1.7.12




From lorenzo.pieralisi at arm.com  Wed Apr 24 13:28:08 2013
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Wed, 24 Apr 2013 18:28:08 +0100
Subject: [RFC PATCH v3 03/17] ARM: dts: am33xx: cpus/cpu nodes dts updates
In-Reply-To: <1366824502-19729-1-git-send-email-lorenzo.pieralisi@arm.com>
References: <1366824502-19729-1-git-send-email-lorenzo.pieralisi@arm.com>
Message-ID: <1366824502-19729-4-git-send-email-lorenzo.pieralisi@arm.com>

This patch updates the in-kernel dts files according to the latest cpus
and cpu bindings updates for ARM.

Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
---
 arch/arm/boot/dts/am33xx.dtsi | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 0957645..ab1bcf2 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -24,8 +24,12 @@
 	};
 
 	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
 		cpu at 0 {
 			compatible = "arm,cortex-a8";
+			device_type = "cpu";
+			reg = <0>;
 
 			/*
 			 * To consider voltage drop between PMIC and SoC,
-- 
1.7.12




From lorenzo.pieralisi at arm.com  Wed Apr 24 13:28:09 2013
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Wed, 24 Apr 2013 18:28:09 +0100
Subject: [RFC PATCH v3 04/17] ARM: dts: armada-370-xp: cpus/cpu node dts
 updates
In-Reply-To: <1366824502-19729-1-git-send-email-lorenzo.pieralisi@arm.com>
References: <1366824502-19729-1-git-send-email-lorenzo.pieralisi@arm.com>
Message-ID: <1366824502-19729-5-git-send-email-lorenzo.pieralisi@arm.com>

This patch updates the in-kernel dts files according to the latest cpus
and cpu bindings updates for ARM.

Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
---
 arch/arm/boot/dts/armada-370-xp.dtsi | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi b/arch/arm/boot/dts/armada-370-xp.dtsi
index 6f1acc7..f13b47a 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -23,8 +23,12 @@
 	compatible = "marvell,armada-370-xp";
 
 	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
 		cpu at 0 {
 			compatible = "marvell,sheeva-v7";
+			device_type = "cpu";
+			reg = <0>;
 		};
 	};
 
-- 
1.7.12




From lorenzo.pieralisi at arm.com  Wed Apr 24 13:28:16 2013
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Wed, 24 Apr 2013 18:28:16 +0100
Subject: [RFC PATCH v3 11/17] ARM: dts: prima2: cpus/cpu node dts updates
In-Reply-To: <1366824502-19729-1-git-send-email-lorenzo.pieralisi@arm.com>
References: <1366824502-19729-1-git-send-email-lorenzo.pieralisi@arm.com>
Message-ID: <1366824502-19729-12-git-send-email-lorenzo.pieralisi@arm.com>

This patch updates the in-kernel dts files according to the latest cpus
and cpu bindings updates for ARM.

Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
---
 arch/arm/boot/dts/prima2.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/prima2.dtsi b/arch/arm/boot/dts/prima2.dtsi
index 3329719..02edd89 100644
--- a/arch/arm/boot/dts/prima2.dtsi
+++ b/arch/arm/boot/dts/prima2.dtsi
@@ -18,6 +18,8 @@
 		#size-cells = <0>;
 
 		cpu at 0 {
+			compatible = "arm,cortex-a9";
+			device_type = "cpu";
 			reg = <0x0>;
 			d-cache-line-size = <32>;
 			i-cache-line-size = <32>;
-- 
1.7.12




From lorenzo.pieralisi at arm.com  Wed Apr 24 13:28:15 2013
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Wed, 24 Apr 2013 18:28:15 +0100
Subject: [RFC PATCH v3 10/17] ARM: dts: picoxcell: cpus/cpu nodes dts updates
In-Reply-To: <1366824502-19729-1-git-send-email-lorenzo.pieralisi@arm.com>
References: <1366824502-19729-1-git-send-email-lorenzo.pieralisi@arm.com>
Message-ID: <1366824502-19729-11-git-send-email-lorenzo.pieralisi@arm.com>

This patch updates the in-kernel dts files according to the latest cpus
and cpu bindings updates for ARM.

Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
---
 arch/arm/boot/dts/picoxcell-pc3x2.dtsi | 8 ++++----
 arch/arm/boot/dts/picoxcell-pc3x3.dtsi | 8 ++++----
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/arch/arm/boot/dts/picoxcell-pc3x2.dtsi b/arch/arm/boot/dts/picoxcell-pc3x2.dtsi
index f0a8c20..533919e 100644
--- a/arch/arm/boot/dts/picoxcell-pc3x2.dtsi
+++ b/arch/arm/boot/dts/picoxcell-pc3x2.dtsi
@@ -18,13 +18,13 @@
 	#size-cells = <1>;
 
 	cpus {
-		#address-cells = <1>;
+		#address-cells = <0>;
 		#size-cells = <0>;
 
-		cpu at 0 {
-			compatible = "arm,1176jz-s";
+		cpu {
+			compatible = "arm,arm1176jz-s";
+			device_type = "cpu";
 			clock-frequency = <400000000>;
-			reg = <0>;
 			d-cache-line-size = <32>;
 			d-cache-size = <32768>;
 			i-cache-line-size = <32>;
diff --git a/arch/arm/boot/dts/picoxcell-pc3x3.dtsi b/arch/arm/boot/dts/picoxcell-pc3x3.dtsi
index daa962d..ab3e800 100644
--- a/arch/arm/boot/dts/picoxcell-pc3x3.dtsi
+++ b/arch/arm/boot/dts/picoxcell-pc3x3.dtsi
@@ -18,13 +18,13 @@
 	#size-cells = <1>;
 
 	cpus {
-		#address-cells = <1>;
+		#address-cells = <0>;
 		#size-cells = <0>;
 
-		cpu at 0 {
-			compatible = "arm,1176jz-s";
+		cpu {
+			compatible = "arm,arm1176jz-s";
+			device_type = "cpu";
 			cpu-clock = <&arm_clk>, "cpu";
-			reg = <0>;
 			d-cache-line-size = <32>;
 			d-cache-size = <32768>;
 			i-cache-line-size = <32>;
-- 
1.7.12




From lorenzo.pieralisi at arm.com  Wed Apr 24 13:28:21 2013
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Wed, 24 Apr 2013 18:28:21 +0100
Subject: [RFC PATCH v3 16/17] ARM: dts: sunxi: cpus/cpu nodes dts updates
In-Reply-To: <1366824502-19729-1-git-send-email-lorenzo.pieralisi@arm.com>
References: <1366824502-19729-1-git-send-email-lorenzo.pieralisi@arm.com>
Message-ID: <1366824502-19729-17-git-send-email-lorenzo.pieralisi@arm.com>

This patch updates the in-kernel dts files according to the latest cpus
and cpu bindings updates for ARM.

Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
---
 arch/arm/boot/dts/sunxi.dtsi | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/sunxi.dtsi b/arch/arm/boot/dts/sunxi.dtsi
index 8b36abe..9f45ecf 100644
--- a/arch/arm/boot/dts/sunxi.dtsi
+++ b/arch/arm/boot/dts/sunxi.dtsi
@@ -17,8 +17,13 @@
 	interrupt-parent = <&intc>;
 
 	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
 		cpu at 0 {
 			compatible = "arm,cortex-a8";
+			device_type = "cpu";
+			reg = <0x0>;
 		};
 	};
 
-- 
1.7.12




From lorenzo.pieralisi at arm.com  Wed Apr 24 13:28:18 2013
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Wed, 24 Apr 2013 18:28:18 +0100
Subject: [RFC PATCH v3 13/17] ARM: dts: r8a7740: cpus/cpu nodes dts updates
In-Reply-To: <1366824502-19729-1-git-send-email-lorenzo.pieralisi@arm.com>
References: <1366824502-19729-1-git-send-email-lorenzo.pieralisi@arm.com>
Message-ID: <1366824502-19729-14-git-send-email-lorenzo.pieralisi@arm.com>

This patch updates the in-kernel dts files according to the latest cpus
and cpu bindings updates for ARM.

Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
---
 arch/arm/boot/dts/r8a7740.dtsi | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7740.dtsi b/arch/arm/boot/dts/r8a7740.dtsi
index 798fa35..8a831e9 100644
--- a/arch/arm/boot/dts/r8a7740.dtsi
+++ b/arch/arm/boot/dts/r8a7740.dtsi
@@ -14,8 +14,12 @@
 	compatible = "renesas,r8a7740";
 
 	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
 		cpu at 0 {
 			compatible = "arm,cortex-a9";
+			device_type = "cpu";
+			reg = <0x0>;
 		};
 	};
 };
-- 
1.7.12




From lorenzo.pieralisi at arm.com  Wed Apr 24 13:28:20 2013
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Wed, 24 Apr 2013 18:28:20 +0100
Subject: [RFC PATCH v3 15/17] ARM: dts: spear: cpus/cpu nodes dts updates
In-Reply-To: <1366824502-19729-1-git-send-email-lorenzo.pieralisi@arm.com>
References: <1366824502-19729-1-git-send-email-lorenzo.pieralisi@arm.com>
Message-ID: <1366824502-19729-16-git-send-email-lorenzo.pieralisi@arm.com>

This patch updates the in-kernel dts files according to the latest cpus
and cpu bindings updates for ARM.

Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
---
 arch/arm/boot/dts/spear13xx.dtsi | 2 ++
 arch/arm/boot/dts/spear3xx.dtsi  | 8 ++++++--
 arch/arm/boot/dts/spear600.dtsi  | 8 ++++++--
 3 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/spear13xx.dtsi b/arch/arm/boot/dts/spear13xx.dtsi
index b4ca60f..5093d54 100644
--- a/arch/arm/boot/dts/spear13xx.dtsi
+++ b/arch/arm/boot/dts/spear13xx.dtsi
@@ -22,12 +22,14 @@
 
 		cpu at 0 {
 			compatible = "arm,cortex-a9";
+			device_type = "cpu";
 			reg = <0>;
 			next-level-cache = <&L2>;
 		};
 
 		cpu at 1 {
 			compatible = "arm,cortex-a9";
+			device_type = "cpu";
 			reg = <1>;
 			next-level-cache = <&L2>;
 		};
diff --git a/arch/arm/boot/dts/spear3xx.dtsi b/arch/arm/boot/dts/spear3xx.dtsi
index c2a852d..f0e3fcf 100644
--- a/arch/arm/boot/dts/spear3xx.dtsi
+++ b/arch/arm/boot/dts/spear3xx.dtsi
@@ -17,8 +17,12 @@
 	interrupt-parent = <&vic>;
 
 	cpus {
-		cpu at 0 {
-			compatible = "arm,arm926ejs";
+		#address-cells = <0>;
+		#size-cells = <0>;
+
+		cpu {
+			compatible = "arm,arm926ej-s";
+			device_type = "cpu";
 		};
 	};
 
diff --git a/arch/arm/boot/dts/spear600.dtsi b/arch/arm/boot/dts/spear600.dtsi
index 19f99dc..9f60a7b 100644
--- a/arch/arm/boot/dts/spear600.dtsi
+++ b/arch/arm/boot/dts/spear600.dtsi
@@ -15,8 +15,12 @@
 	compatible = "st,spear600";
 
 	cpus {
-		cpu at 0 {
-			compatible = "arm,arm926ejs";
+		#address-cells = <0>;
+		#size-cells = <0>;
+
+		cpu {
+			compatible = "arm,arm926ej-s";
+			device_type = "cpu";
 		};
 	};
 
-- 
1.7.12




From lorenzo.pieralisi at arm.com  Wed Apr 24 13:28:22 2013
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Wed, 24 Apr 2013 18:28:22 +0100
Subject: [RFC PATCH v3 17/17] ARM: DT: kernel: DT cpus/cpu node bindings update
In-Reply-To: <1366824502-19729-1-git-send-email-lorenzo.pieralisi@arm.com>
References: <1366824502-19729-1-git-send-email-lorenzo.pieralisi@arm.com>
Message-ID: <1366824502-19729-18-git-send-email-lorenzo.pieralisi@arm.com>

DT cpu map parsing code must be made compliant with the latest cpus/cpu
nodes bindings updates, hence this patch updates the arm_dt_init_cpu_maps()
function with checks and additional parsing rules.

Uniprocessor systems predating v7 do not parse the cpus node at all
since the reg property is meaningless on those systems.

Device trees for 64-bit systems can be taken as device tree input also
for 64-bit CPUs running in 32-bit mode. The code checks that the reg entries
are zeroed as required in the respective fields and detects automatically
the cpus node #address-cells value so that device tree written for
64-bit ARM platforms (that can have cpus node #address-cells == 2) can still
be taken as input. The correct device tree entries are to be set up by the
boot loader, kernel code just checks that device tree entries in the cpus
node are as expected for a 32-bit CPU (reg[63:24] == 0).

cpu node entries with invalid reg property or containing duplicates are
ignored and the device tree parsing is not stopped anymore when such
entries are encountered, the device tree cpu node entry is just skipped.

A device tree with cpu nodes missing the boot CPU MPIDR is considered a
hard error and the kernel flags this up as a bug to force firmware updates.

Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
---
 arch/arm/kernel/devtree.c | 78 +++++++++++++++++++++++++++++------------------
 1 file changed, 48 insertions(+), 30 deletions(-)

diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
index f149217..b667217 100644
--- a/arch/arm/kernel/devtree.c
+++ b/arch/arm/kernel/devtree.c
@@ -23,6 +23,7 @@
 #include <asm/setup.h>
 #include <asm/page.h>
 #include <asm/smp_plat.h>
+#include <asm/system_info.h>
 #include <asm/mach/arch.h>
 #include <asm/mach-types.h>
 
@@ -81,48 +82,64 @@ void __init arm_dt_init_cpu_maps(void)
 	static u32 tmp_map[NR_CPUS] __initdata = {
 				[0 ... NR_CPUS-1] = UINT_MAX };
 	struct device_node *cpu, *cpus;
-	u32 i, j, cpuidx = 1;
+	u32 i, j, ac, cpuidx = 1;
 	u32 mpidr = is_smp() ? read_cpuid_mpidr() & MPIDR_HWID_BITMASK : 0;
-
+	int len;
 	bool bootcpu_valid = false;
+
 	cpus = of_find_node_by_path("/cpus");
 
-	if (!cpus)
+	if (!cpus || ((cpu_architecture() < CPU_ARCH_ARMv7) && !is_smp()))
 		return;
 
+	if (WARN_ON(of_property_read_u32(cpus, "#address-cells", &ac)))
+		ac = of_n_addr_cells(cpus);
+
 	for_each_child_of_node(cpus, cpu) {
-		u32 hwid;
+		u64 hwid64;
+		u32 hwid32;
+		const __be32 *prop;
 
 		pr_debug(" * %s...\n", cpu->full_name);
 		/*
-		 * A device tree containing CPU nodes with missing "reg"
-		 * properties is considered invalid to build the
-		 * cpu_logical_map.
+		 * A CPU node with missing or wrong "reg" property is
+		 * considered invalid to build a cpu_logical_map entry.
 		 */
-		if (of_property_read_u32(cpu, "reg", &hwid)) {
-			pr_debug(" * %s missing reg property\n",
-				     cpu->full_name);
-			return;
+		prop = of_get_property(cpu, "reg", &len);
+		if (!prop || len < (ac * sizeof(*prop))) {
+			WARN(1, " * %s node missing/wrong reg property, skipped\n",
+				cpu->full_name);
+				goto next;
 		}
-
 		/*
-		 * 8 MSBs must be set to 0 in the DT since the reg property
-		 * defines the MPIDR[23:0].
+		 * Always read reg as u64 value.
+		 * For dts with #address-cells == 1 hwid64[63:32]
+		 * will be set to 0 by of_read_number.
+		 * Toss away the top 32 bits and store value in hwid32.
+		 */
+		hwid32 = hwid64 = of_read_number(prop, ac);
+		/*
+		 * hwid64[63:24] must be always be 0 since the reg
+		 * property defines the MPIDR[23:0] bits regardless
+		 * of the cpus node #address-cells value.
 		 */
-		if (hwid & ~MPIDR_HWID_BITMASK)
-			return;
+		if (hwid64 & ~MPIDR_HWID_BITMASK) {
+			WARN(1, " * %s node reg[63:24] must be 0 on 32-bit dts, got %#016llx, skipped\n",
+				cpu->full_name, hwid64);
+			goto next;
+		}
 
 		/*
 		 * Duplicate MPIDRs are a recipe for disaster.
 		 * Scan all initialized entries and check for
-		 * duplicates. If any is found just bail out.
+		 * duplicates. If any is found just ignore the CPU.
 		 * temp values were initialized to UINT_MAX
 		 * to avoid matching valid MPIDR[23:0] values.
 		 */
 		for (j = 0; j < cpuidx; j++)
-			if (WARN(tmp_map[j] == hwid, "Duplicate /cpu reg "
-						     "properties in the DT\n"))
-				return;
+			if (WARN(tmp_map[j] == hwid32, " * %s node duplicate cpu reg property, skipped\n",
+						       cpu->full_name))
+				goto next;
 
 		/*
 		 * Build a stashed array of MPIDR values. Numbering scheme
@@ -133,26 +150,27 @@ void __init arm_dt_init_cpu_maps(void)
 		 * logical map built from DT is validated and can be used
 		 * to override the map created in smp_setup_processor_id().
 		 */
-		if (hwid == mpidr) {
+		if (hwid32 == mpidr) {
 			i = 0;
 			bootcpu_valid = true;
 		} else {
 			i = cpuidx++;
 		}
 
-		if (WARN(cpuidx > nr_cpu_ids, "DT /cpu %u nodes greater than "
-					       "max cores %u, capping them\n",
-					       cpuidx, nr_cpu_ids)) {
+		if (WARN_ONCE(cpuidx > nr_cpu_ids, "DT cpu %u nodes greater than max cores %u, capping them\n",
+						    cpuidx, nr_cpu_ids)) {
 			cpuidx = nr_cpu_ids;
-			break;
+			goto next;
 		}
 
-		tmp_map[i] = hwid;
+		tmp_map[i] = hwid32;
+next:	;
 	}
-
-	if (WARN(!bootcpu_valid, "DT missing boot CPU MPIDR[23:0], "
-				 "fall back to default cpu_logical_map\n"))
-		return;
+	/*
+	 * A DT missing the boot CPU MPIDR is a really bad omen
+	 * Flag it up as such and force firmware/dtb updates
+	 */
+	BUG_ON(!bootcpu_valid);
 
 	/*
 	 * Since the boot CPU node contains proper data, and all nodes have
-- 
1.7.12




From lorenzo.pieralisi at arm.com  Wed Apr 24 13:28:07 2013
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Wed, 24 Apr 2013 18:28:07 +0100
Subject: [RFC PATCH v3 02/17] Documentation: devicetree: arm: cpus/cpu nodes
 bindings updates
In-Reply-To: <1366824502-19729-1-git-send-email-lorenzo.pieralisi@arm.com>
References: <1366824502-19729-1-git-send-email-lorenzo.pieralisi@arm.com>
Message-ID: <1366824502-19729-3-git-send-email-lorenzo.pieralisi@arm.com>

In order to extend the current cpu nodes bindings to newer CPUs
inclusive of AArch64 and to update support for older ARM CPUs this
patch updates device tree documentation for the cpu nodes bindings.

Main changes:
    - adds 64-bit bindings
    - define usage of #address-cells
    - define 32/64 dts compatibility settings
    - defines behaviour on pre and post v7 uniprocessor systems
    - adds ARM 11MPcore specific reg property definition

Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
---
 Documentation/devicetree/bindings/arm/cpus.txt | 457 ++++++++++++++++++++++---
 1 file changed, 410 insertions(+), 47 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt
index f32494d..00badea 100644
--- a/Documentation/devicetree/bindings/arm/cpus.txt
+++ b/Documentation/devicetree/bindings/arm/cpus.txt
@@ -1,77 +1,440 @@
-* ARM CPUs binding description
+=================
+ARM CPUs bindings
+=================
 
 The device tree allows to describe the layout of CPUs in a system through
 the "cpus" node, which in turn contains a number of subnodes (ie "cpu")
 defining properties for every cpu.
 
-Bindings for CPU nodes follow the ePAPR standard, available from:
-
-http://devicetree.org
-
-For the ARM architecture every CPU node must contain the following properties:
-
-- device_type:	must be "cpu"
-- reg:		property matching the CPU MPIDR[23:0] register bits
-		reg[31:24] bits must be set to 0
-- compatible:	should be one of:
-		"arm,arm1020"
-		"arm,arm1020e"
-		"arm,arm1022"
-		"arm,arm1026"
-		"arm,arm720"
-		"arm,arm740"
-		"arm,arm7tdmi"
-		"arm,arm920"
-		"arm,arm922"
-		"arm,arm925"
-		"arm,arm926"
-		"arm,arm940"
-		"arm,arm946"
-		"arm,arm9tdmi"
-		"arm,cortex-a5"
-		"arm,cortex-a7"
-		"arm,cortex-a8"
-		"arm,cortex-a9"
-		"arm,cortex-a15"
-		"arm,arm1136"
-		"arm,arm1156"
-		"arm,arm1176"
-		"arm,arm11mpcore"
-		"faraday,fa526"
-		"intel,sa110"
-		"intel,sa1100"
-		"marvell,feroceon"
-		"marvell,mohawk"
-		"marvell,xsc3"
-		"marvell,xscale"
-
-Example:
+Bindings for CPU nodes follow the ePAPR v1.1 standard, available from:
+
+https://www.power.org/documentation/epapr-version-1-1/
+
+with updates for 32-bit and 64-bit ARM systems provided in this document.
+
+================================
+Convention used in this document
+================================
+
+This document follows the conventions described in the ePAPR v1.1, with
+the addition:
+
+- square brackets define bitfields, eg reg[7:0] value of the bitfield in
+  the reg property contained in bits 7 down to 0
+
+=====================================
+cpus and cpu node bindings definition
+=====================================
+
+The ARM architecture, in accordance with the ePAPR, requires the cpus and cpu
+nodes to be present and contain the properties described below.
+
+- cpus node
+
+	Description: Container of cpu nodes
+
+	The node name must be "cpus".
+
+	A cpus node must define the following properties:
+
+	- #address-cells
+		Usage: required
+		Value type: <u32>
+
+		Definition depends on ARM architecture version and
+		configuration:
+
+			# On uniprocessor ARM architectures previous to v7
+			  value must be 0.
+			# On 32-bit ARM 11 MPcore, ARM v7 or later systems
+			  value must be 1.
+			# On ARM v8 64-bit systems value must be set to 1
+			  or 2. Refer to the cpu node's reg property
+			  description for allowed configurations.
+
+	- #size-cells
+		Usage: required
+		Value type: <u32>
+		Definition: must be set to 0
+
+- cpu node
+
+	Description: Describes a CPU in an ARM based system
+
+	PROPERTIES
+
+	- device_type
+		Usage: required
+		Value type: <string>
+		Definition: must be "cpu"
+	- reg
+		Usage and definition depend on ARM architecture version and
+		configuration:
+
+			# On uniprocessor ARM architectures previous to v7
+			  this property is optional since they do not define
+			  any register that provides a CPU identifier.
+			  Any value set in the reg property for these CPUs
+			  should be ignored.
+
+			# On ARM 11 MPcore based systems this property is
+			  required and matches the CPUID[11:0] register bits.
+
+			  Bits [11:0] in the reg cell must be set to
+			  bits [11:0] in CPU ID register.
+
+			  All other bits in the reg cell must be set to 0.
+
+			# On 32-bit ARM v7 or later systems this property is
+			  required and matches the CPU MPIDR[23:0] register
+			  bits.
+
+			  Bits [23:0] in the reg cell must be set to
+			  bits [23:0] in MPIDR.
+
+			  All other bits in the reg cell must be set to 0.
+
+			# On ARM v8 64-bit systems, where the reg property
+			  size can be 1 or 2 cells (as defined by cpus node's
+			  #address-cells property), this property is
+			  required and matches:
+
+			  - On systems running the OS in AArch32:
+
+			    * If the cpus node's #address-cells value is 2:
+
+			      The first reg cell must be set to 0.
+
+			      The second reg cell bits [23:0] must be set to
+			      bits [23:0] of MPIDR_EL1.
+
+			      All other bits in the reg cells must be set to 0.
+
+			    * If the cpus node's #address-cells value is 1:
+
+			      Bits [23:0] in the reg cell must be set to
+			      bits [23:0] in MPIDR_EL1.
+
+			      All other bits in the reg cell must be 0.
+
+			  - On systems running the OS in AArch64:
+
+			    * If the cpus node's #address-cells value is 2:
+
+			      The first reg cell bits [7:0] must be set to
+			      bits [39:32] of MPIDR_EL1.
+
+			      The second reg cell bits [23:0] must be set to
+			      bits [23:0] of MPIDR_EL1.
+
+			      All other bits in the reg cells must be set to 0.
+
+			    * If the cpus node's #address-cells value is 1:
+
+			      MPIDR_EL1[63:32] is 0 on all processors in the
+			      system.
+
+			      The reg cell bits [23:0] must be set to
+			      bits [23:0] of MPIDR_EL1.
+
+			      All other bits in the reg cell must be set to 0.
+
+	- compatible:
+		Usage: required
+		Value type: <string>
+		Definition: should be one of:
+			    "arm,arm710t"
+			    "arm,arm720t"
+			    "arm,arm740t"
+			    "arm,arm7ej-s"
+			    "arm,arm7tdmi"
+			    "arm,arm7tdmi-s"
+			    "arm,arm9es"
+			    "arm,arm9ej-s"
+			    "arm,arm920t"
+			    "arm,arm922t"
+			    "arm,arm925"
+			    "arm,arm926e-s"
+			    "arm,arm926ej-s"
+			    "arm,arm940t"
+			    "arm,arm946e-s"
+			    "arm,arm966e-s"
+			    "arm,arm968e-s"
+			    "arm,arm9tdmi"
+			    "arm,arm1020e"
+			    "arm,arm1020t"
+			    "arm,arm1022e"
+			    "arm,arm1026ej-s"
+			    "arm,arm1136j-s"
+			    "arm,arm1136jf-s"
+			    "arm,arm1156t2-s"
+			    "arm,arm1156t2f-s"
+			    "arm,arm1176jzf"
+			    "arm,arm1176jz-s"
+			    "arm,arm1176jzf-s"
+			    "arm,arm11mpcore"
+			    "arm,cortex-a5"
+			    "arm,cortex-a7"
+			    "arm,cortex-a8"
+			    "arm,cortex-a9"
+			    "arm,cortex-a15"
+			    "arm,cortex-a53"
+			    "arm,cortex-a57"
+			    "arm,cortex-m0"
+			    "arm,cortex-m0+"
+			    "arm,cortex-m1"
+			    "arm,cortex-m3"
+			    "arm,cortex-m4"
+			    "arm,cortex-r4"
+			    "arm,cortex-r5"
+			    "arm,cortex-r7"
+			    "faraday,fa526"
+			    "intel,sa110"
+			    "intel,sa1100"
+			    "marvell,feroceon"
+			    "marvell,mohawk"
+			    "marvell,pj4"
+			    "marvell,sheeva-v7"
+			    "marvell,xsc3"
+			    "marvell,xscale"
+			    "qcom,krait"
+			    "qcom,scorpion"
+	- enable-method
+		Value type: <stringlist>
+		Usage and definition depend on ARM architecture version and
+		configuration:
+			# On ARM v8 64-bit systems running the OS in AArch64,
+			  this property is required and must be "spin-table".
+			# On ARM 32-bit systems or ARM v8 systems running
+			  the OS in AArch32 this property is prohibited.
+
+	- cpu-release-addr
+		Usage: required for systems that have an "enable-method"
+		       property value of "spin-table".
+		Value type: <prop-encoded-array>
+		Definition:
+			# On ARM v8 64-bit systems must be a two cell
+			  property identifying a 64-bit zero-initialised
+			  memory location.
+
+Example 1 (dual-cluster big.LITTLE system 32-bit):
 
 	cpus {
 		#size-cells = <0>;
 		#address-cells = <1>;
 
-		CPU0: cpu at 0 {
+		cpu at 0 {
 			device_type = "cpu";
 			compatible = "arm,cortex-a15";
 			reg = <0x0>;
 		};
 
-		CPU1: cpu at 1 {
+		cpu at 1 {
 			device_type = "cpu";
 			compatible = "arm,cortex-a15";
 			reg = <0x1>;
 		};
 
-		CPU2: cpu at 100 {
+		cpu at 100 {
 			device_type = "cpu";
 			compatible = "arm,cortex-a7";
 			reg = <0x100>;
 		};
 
-		CPU3: cpu at 101 {
+		cpu at 101 {
 			device_type = "cpu";
 			compatible = "arm,cortex-a7";
 			reg = <0x101>;
 		};
 	};
+
+Example 2 (Cortex-A8 uniprocessor 32-bit system):
+
+	cpus {
+		#size-cells = <0>;
+		#address-cells = <1>;
+
+		cpu at 0 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a8";
+			reg = <0x0>;
+		};
+	};
+
+Example 3 (ARM 926EJ-S uniprocessor 32-bit system):
+
+	cpus {
+		#size-cells = <0>;
+		#address-cells = <0>;
+
+		cpu {
+			device_type = "cpu";
+			compatible = "arm,arm926ej-s";
+		};
+	};
+
+Example 4 (ARM Cortex-A57 64-bit system running OS in AArch64):
+
+cpus {
+	#size-cells = <0>;
+	#address-cells = <2>;
+
+	cpu at 0 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a57";
+		reg = <0x0 0x0>;
+		enable-method = "spin-table";
+		cpu-release-addr = <0 0x20000000>;
+	};
+
+	cpu at 1 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a57";
+		reg = <0x0 0x1>;
+		enable-method = "spin-table";
+		cpu-release-addr = <0 0x20000000>;
+	};
+
+	cpu at 100 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a57";
+		reg = <0x0 0x100>;
+		enable-method = "spin-table";
+		cpu-release-addr = <0 0x20000000>;
+	};
+
+	cpu at 101 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a57";
+		reg = <0x0 0x101>;
+		enable-method = "spin-table";
+		cpu-release-addr = <0 0x20000000>;
+	};
+
+	cpu at 10000 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a57";
+		reg = <0x0 0x10000>;
+		enable-method = "spin-table";
+		cpu-release-addr = <0 0x20000000>;
+	};
+
+	cpu at 10001 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a57";
+		reg = <0x0 0x10001>;
+		enable-method = "spin-table";
+		cpu-release-addr = <0 0x20000000>;
+	};
+
+	cpu at 10100 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a57";
+		reg = <0x0 0x10100>;
+		enable-method = "spin-table";
+		cpu-release-addr = <0 0x20000000>;
+	};
+
+	cpu at 10101 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a57";
+		reg = <0x0 0x10101>;
+		enable-method = "spin-table";
+		cpu-release-addr = <0 0x20000000>;
+	};
+
+	cpu at 100000000 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a57";
+		reg = <0x1 0x0>;
+		enable-method = "spin-table";
+		cpu-release-addr = <0 0x20000000>;
+	};
+
+	cpu at 100000001 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a57";
+		reg = <0x1 0x1>;
+		enable-method = "spin-table";
+		cpu-release-addr = <0 0x20000000>;
+	};
+
+	cpu at 100000100 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a57";
+		reg = <0x1 0x100>;
+		enable-method = "spin-table";
+		cpu-release-addr = <0 0x20000000>;
+	};
+
+	cpu at 100000101 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a57";
+		reg = <0x1 0x101>;
+		enable-method = "spin-table";
+		cpu-release-addr = <0 0x20000000>;
+	};
+
+	cpu at 100010000 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a57";
+		reg = <0x1 0x10000>;
+		enable-method = "spin-table";
+		cpu-release-addr = <0 0x20000000>;
+	};
+
+	cpu at 100010001 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a57";
+		reg = <0x1 0x10001>;
+		enable-method = "spin-table";
+		cpu-release-addr = <0 0x20000000>;
+	};
+
+	cpu at 100010100 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a57";
+		reg = <0x1 0x10100>;
+		enable-method = "spin-table";
+		cpu-release-addr = <0 0x20000000>;
+	};
+
+	cpu at 100010101 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a57";
+		reg = <0x1 0x10101>;
+		enable-method = "spin-table";
+		cpu-release-addr = <0 0x20000000>;
+	};
+};
+
+Example 5 (ARM Cortex-A57 64-bit system running OS in AArch32):
+
+cpus {
+	#size-cells = <0>;
+	#address-cells = <2>;
+
+	cpu at 0 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a57";
+		reg = <0x0 0x0>;
+	};
+
+	cpu at 1 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a57";
+		reg = <0x0 0x1>;
+	};
+
+	cpu at 100 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a57";
+		reg = <0x0 0x100>;
+	};
+
+	cpu at 101 {
+		device_type = "cpu";
+		compatible = "arm,cortex-a57";
+		reg = <0x0 0x101>;
+	};
+};
-- 
1.7.12




From linux at roeck-us.net  Wed Apr 24 13:32:16 2013
From: linux at roeck-us.net (Guenter Roeck)
Date: Wed, 24 Apr 2013 10:32:16 -0700
Subject: [PATCHv1 2/3] hwmon: Add documentation for g762 driver
In-Reply-To: <24acd174f829d211f5d4c1b8631ffc3f8dd97910.1366753420.git.arno@natisbad.org>
References: <cover.1366753420.git.arno@natisbad.org>
 <24acd174f829d211f5d4c1b8631ffc3f8dd97910.1366753420.git.arno@natisbad.org>
Message-ID: <20130424173216.GA1073@roeck-us.net>

On Wed, Apr 24, 2013 at 12:06:08AM +0200, Arnaud Ebalard wrote:
> 
> Signed-off-by: Arnaud Ebalard <arno at natisbad.org>
> ---
>  Documentation/hwmon/g762 |   67 ++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 67 insertions(+)
>  create mode 100644 Documentation/hwmon/g762
> 
> diff --git a/Documentation/hwmon/g762 b/Documentation/hwmon/g762
> new file mode 100644
> index 0000000..5015829
> --- /dev/null
> +++ b/Documentation/hwmon/g762
> @@ -0,0 +1,67 @@
> +Kernel driver g762
> +==================
> +
> +This documentation is based on G760a one, GMT G762 datasheet available

G760a ? If this refers to Documentation/hwmon/g760a, I think it is just
confusing.

> +at http://natisbad.org/NAS/ref/GMT_EDS-762_763-080710-0.2.pdf (used
> +for the development of the driver) and sysfs bindings described in

I would hope that you used the data sheet for the driver ;), but that
information does not add much if any value here. I would suggest
to drop it. Just point to the data sheet.

> +Documentation/hwmon/sysfs-interface.
> +
> +The GMT G762 Fan Speed PWM Controller is connected directly to a fan
> +and performs closed-loop or open-loop control of the fan speed. Two
> +modes - PWM or linear - are supported by the device.
> +
> +The following entries are available to the user in a subdirectory of
> +/sys/bus/i2c/drivers/g762/ to control the operation of the device.
> +This can be done manually using the following entries but is usually
> +done via a userland daemon like fancontrol.
> +
> +Note that those entries do not provide ways to setup the specific
> +hardware characteristics of the system (reference clock, pulses per
> +fan revolution, ...); Those can be modified via devicetree bindings
> +documented in Documentation/devicetree/bindings/hwmon/g762.txt.
> +
> +
> +  fan1_target: set desired fan speed. This only makes sense in closed-loop
> +            fan speed control (i.e. when pwm1_enable is set to 2).
> +
> +  fan1_input: provide current fan rotation value in RPM as reported by
> +            the fan to the device.
> +
> +  fan1_div: fan clock divisor. Supported value are 1, 2, 4 and 8. Default
> +            value is 1.
> +
> +  fan1_gear_mode: fan gear mode. Supported values are 0, 1 and 2. Default
> +            value is 0. The value is a characteristic of the system
> +            and a higher value can be set for more precisely control
> +            fans with a high rotation speed. Note that this affects the
> +            measurable speed range, not the read value.
> +
This attribute no longer exists.

> +  fan1_fault: reports fan failure, i.e. no transition on fan gear pin for
> +            about 0.7s (if the fan is not voluntarily set off).
> +
> +  fan1_alarm: in closed-loop control mode, if fan RPM value is 25% out
> +            of the programmed value for over 6 seconds 'fan1_alarm' is
> +            set to 1.
> +
> +  pwm1: get or set PWM fan control value. This is an integer value
> +            between 0 and 255. 0 stops the fan, 255 makes it run at
> +            full speed.
> +
> +  pwm1_enable: set current fan speed control mode i.e. 1 for manual fan
> +            speed control (open-loop), 2 for automatic fan speed control
> +            (closed-loop).
> +
> +  pwm1_mode: set or get fan driving mode: 1 for PWM mode, 0 for linear
> +            mode. Default is linear mode.
> +
> +
> +In PWM mode ('pwm1_mode' set to 1), the fan speed is programmed either by
> +setting a value between 0 and 255 via 'pwm1' entry (0 stops the fan, 255
> +makes it run at full speed). This can also be done by passing the
> +expected RPM value via 'fan1_target'. Current fan speed value can be
> +retrieved via 'fan1_input'. This fan speed value is computed based on
> +the parameters associated with the physical characteristics of the
> +system: a reference clock source frequency, a number of pulses per fan
> +revolution, etc.
> +
> +Note that the driver will update its values at most once per second.
> -- 
> 1.7.10.4
> 
> 


From dborkman at redhat.com  Wed Apr 24 13:41:34 2013
From: dborkman at redhat.com (Daniel Borkmann)
Date: Wed, 24 Apr 2013 19:41:34 +0200
Subject: [PATCH V3 2/3] ARM: net: bpf_jit: make code generation less
 dependent on struct sk_filter.
In-Reply-To: <1366824429-26652-3-git-send-email-nschichan@freebox.fr>
References: <1366824429-26652-1-git-send-email-nschichan@freebox.fr>
 <1366824429-26652-3-git-send-email-nschichan@freebox.fr>
Message-ID: <5178194E.5000403@redhat.com>

On 04/24/2013 07:27 PM, Nicolas Schichan wrote:
> This is in preparation of bpf_jit support for seccomp filters.

Please also CC the netdev list for BPF related patches.

Just to give you a heads-up, this might likely lead to a merge
conflict with the net-next tree (commit 79617801ea0c0e66, "filter:
bpf_jit_comp: refactor and unify BPF JIT image dump output").

> Signed-off-by: Nicolas Schichan <nschichan at freebox.fr>
> ---
>   arch/arm/net/bpf_jit_32.c |   46 ++++++++++++++++++++++++++++-----------------
>   1 file changed, 29 insertions(+), 17 deletions(-)
>
> diff --git a/arch/arm/net/bpf_jit_32.c b/arch/arm/net/bpf_jit_32.c
> index a0bd8a7..bb66a2b 100644
> --- a/arch/arm/net/bpf_jit_32.c
> +++ b/arch/arm/net/bpf_jit_32.c
> @@ -55,7 +55,8 @@
>   #define FLAG_NEED_X_RESET	(1 << 0)
>
>   struct jit_ctx {
> -	const struct sk_filter *skf;
> +	unsigned short prog_len;
> +	struct sock_filter *prog_insns;
>   	unsigned idx;
>   	unsigned prologue_bytes;
>   	int ret0_fp_idx;
> @@ -131,8 +132,8 @@ static u16 saved_regs(struct jit_ctx *ctx)
>   {
>   	u16 ret = 0;
>
> -	if ((ctx->skf->len > 1) ||
> -	    (ctx->skf->insns[0].code == BPF_S_RET_A))
> +	if ((ctx->prog_len > 1) ||
> +	    (ctx->prog_insns[0].code == BPF_S_RET_A))
>   		ret |= 1 << r_A;
>
>   #ifdef CONFIG_FRAME_POINTER
> @@ -181,7 +182,7 @@ static inline bool is_load_to_a(u16 inst)
>   static void build_prologue(struct jit_ctx *ctx)
>   {
>   	u16 reg_set = saved_regs(ctx);
> -	u16 first_inst = ctx->skf->insns[0].code;
> +	u16 first_inst = ctx->prog_insns[0].code;
>   	u16 off;
>
>   #ifdef CONFIG_FRAME_POINTER
> @@ -279,7 +280,7 @@ static u16 imm_offset(u32 k, struct jit_ctx *ctx)
>   		ctx->imms[i] = k;
>
>   	/* constants go just after the epilogue */
> -	offset =  ctx->offsets[ctx->skf->len];
> +	offset =  ctx->offsets[ctx->prog_len];
>   	offset += ctx->prologue_bytes;
>   	offset += ctx->epilogue_bytes;
>   	offset += i * 4;
> @@ -419,7 +420,7 @@ static inline void emit_err_ret(u8 cond, struct jit_ctx *ctx)
>   		emit(ARM_MOV_R(ARM_R0, ARM_R0), ctx);
>   	} else {
>   		_emit(cond, ARM_MOV_I(ARM_R0, 0), ctx);
> -		_emit(cond, ARM_B(b_imm(ctx->skf->len, ctx)), ctx);
> +		_emit(cond, ARM_B(b_imm(ctx->prog_len, ctx)), ctx);
>   	}
>   }
>
> @@ -469,14 +470,13 @@ static inline void update_on_xread(struct jit_ctx *ctx)
>   static int build_body(struct jit_ctx *ctx)
>   {
>   	void *load_func[] = {jit_get_skb_b, jit_get_skb_h, jit_get_skb_w};
> -	const struct sk_filter *prog = ctx->skf;
>   	const struct sock_filter *inst;
>   	unsigned i, load_order, off, condt;
>   	int imm12;
>   	u32 k;
>
> -	for (i = 0; i < prog->len; i++) {
> -		inst = &(prog->insns[i]);
> +	for (i = 0; i < ctx->prog_len; i++) {
> +		inst = &(ctx->prog_insns[i]);
>   		/* K as an immediate value operand */
>   		k = inst->k;
>
> @@ -769,8 +769,8 @@ cmp_x:
>   				ctx->ret0_fp_idx = i;
>   			emit_mov_i(ARM_R0, k, ctx);
>   b_epilogue:
> -			if (i != ctx->skf->len - 1)
> -				emit(ARM_B(b_imm(prog->len, ctx)), ctx);
> +			if (i != ctx->prog_len - 1)
> +				emit(ARM_B(b_imm(ctx->prog_len, ctx)), ctx);
>   			break;
>   		case BPF_S_MISC_TAX:
>   			/* X = A */
> @@ -858,7 +858,7 @@ b_epilogue:
>   }
>
>
> -void bpf_jit_compile(struct sk_filter *fp)
> +static void __bpf_jit_compile(struct jit_ctx *out_ctx)
>   {
>   	struct jit_ctx ctx;
>   	unsigned tmp_idx;
> @@ -867,11 +867,10 @@ void bpf_jit_compile(struct sk_filter *fp)
>   	if (!bpf_jit_enable)
>   		return;
>
> -	memset(&ctx, 0, sizeof(ctx));
> -	ctx.skf		= fp;
> +	ctx = *out_ctx;
>   	ctx.ret0_fp_idx = -1;
>
> -	ctx.offsets = kzalloc(4 * (ctx.skf->len + 1), GFP_KERNEL);
> +	ctx.offsets = kzalloc(4 * (ctx.prog_len + 1), GFP_KERNEL);
>   	if (ctx.offsets == NULL)
>   		return;
>
> @@ -921,13 +920,26 @@ void bpf_jit_compile(struct sk_filter *fp)
>   		print_hex_dump(KERN_INFO, "BPF JIT code: ",
>   			       DUMP_PREFIX_ADDRESS, 16, 4, ctx.target,
>   			       alloc_size, false);
> -
> -	fp->bpf_func = (void *)ctx.target;
>   out:
>   	kfree(ctx.offsets);
> +
> +	*out_ctx = ctx;
>   	return;
>   }
>
> +void bpf_jit_compile(struct sk_filter *fp)
> +{
> +	struct jit_ctx ctx;
> +
> +	memset(&ctx, 0, sizeof(ctx));
> +	ctx.prog_len = fp->len;
> +	ctx.prog_insns = fp->insns;
> +
> +	__bpf_jit_compile(&ctx);
> +	if (ctx.target)
> +		fp->bpf_func = (void *)ctx.target;
> +}
> +
>   static void bpf_jit_free_worker(struct work_struct *work)
>   {
>   	module_free(NULL, work);
>


From linux at arm.linux.org.uk  Wed Apr 24 13:46:02 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Wed, 24 Apr 2013 18:46:02 +0100
Subject: [PATCH v2] ARM: Kconfig: let ARM9TDMI and ARM7TDMI invisible.
In-Reply-To: <51775D88.2000406@asianux.com>
References: <51775BB3.6000607@asianux.com> <51775D88.2000406@asianux.com>
Message-ID: <20130424174602.GA14496@n2100.arm.linux.org.uk>

On Wed, Apr 24, 2013 at 12:20:24PM +0800, Chen Gang wrote:
> If CONFIG_MMU is disabled, it will let ARM9TDMI and ARM7TDMI visible,
> but in fact, only AT91X40 need ARM7TDMI, so need not let them visible.

I'll apply it myself this evening.  Can I add:

Tested-by: Chen Gang <gang.chen at asianux.com>

to it?


From robherring2 at gmail.com  Wed Apr 24 13:50:00 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Wed, 24 Apr 2013 12:50:00 -0500
Subject: [PATCH] cpuidle: add maintainer entry
In-Reply-To: <1366810463-17495-1-git-send-email-daniel.lezcano@linaro.org>
References: <1366810463-17495-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <51781B48.30208@gmail.com>

On 04/24/2013 08:34 AM, Daniel Lezcano wrote:
> Currently the cpuidle drivers are spread across the different archs.
> 
> The patch submission for cpuidle are following different path: the cpuidle core
> code goes to linux-pm, the ARM drivers goes to arm-soc or the SoC specific
> tree, sh goes through sh arch tree, pseries goes through PowerPC and
> finally intel goes through Len's tree while acpi_idle goes under linux-pm.
> 
> That makes difficult to consolidate the code and to propagate modifications
> from the cpuidle core to the different drivers.
> 
> Hopefully, a movement has initiated to put the cpuidle drivers into the
> drivers/cpuidle directory like cpuidle-calxeda.c and cpuidle-kirkwood.c
> 
> Add an explicit maintainer entry in the MAINTAINER to clarify the situation
> and prevent new cpuidle drivers to goes to an arch directory.
> 
> The upstreaming process is unchanged: Rafael takes the patches to merge them
> into its tree but with the acked-by from the driver's maintainer. So the header
> must contains the name of the maintainer.

Shouldn't MAINTAINERS contain the driver maintainers too?

> 
> This organization will be the same than cpufreq.
> 
> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
> ---
>  MAINTAINERS                        |    7 +++++++
>  drivers/cpuidle/cpuidle-calxeda.c  |    4 +++-
>  drivers/cpuidle/cpuidle-kirkwood.c |    5 +++--
>  3 files changed, 13 insertions(+), 3 deletions(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 61677c3..effa0f3 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2206,6 +2206,13 @@ S:	Maintained
>  F:	drivers/cpufreq/
>  F:	include/linux/cpufreq.h
>  
> +CPUIDLE DRIVERS
> +M:	Rafael J. Wysocki <rjw at sisk.pl>
> +L:	linux-pm at vger.kernel.org
> +S:	Maintained
> +F:	drivers/cpuidle/*
> +F:	include/linux/cpuidle.h
> +
>  CPU FREQUENCY DRIVERS - ARM BIG LITTLE
>  M:	Viresh Kumar <viresh.kumar at linaro.org>
>  M:	Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
> diff --git a/drivers/cpuidle/cpuidle-calxeda.c b/drivers/cpuidle/cpuidle-calxeda.c
> index e344b56..2378c39 100644
> --- a/drivers/cpuidle/cpuidle-calxeda.c
> +++ b/drivers/cpuidle/cpuidle-calxeda.c
> @@ -1,7 +1,6 @@
>  /*
>   * Copyright 2012 Calxeda, Inc.
>   *
> - * Based on arch/arm/plat-mxc/cpuidle.c:

This file may have moved, but it existed at the time this was committed.
So the comment still applies and documents what part of the file the FSL
and Linaro copyright applies to.

Of course most of what was copied here was the boilerplate which your
patch series removes. The heart of the functionality was developed by me.

>   * Copyright 2012 Freescale Semiconductor, Inc.
>   * Copyright 2012 Linaro Ltd.
>   *
> @@ -16,6 +15,9 @@
>   *
>   * You should have received a copy of the GNU General Public License along with
>   * this program.  If not, see <http://www.gnu.org/licenses/>.
> + *
> + * Author    : Rob Herring <rob.herring at calxeda.com>
> + * Maintainer: Rob Herring <rob.herring at calxeda.com>

As mentioned above, this doesn't seem right.

Rob

>   */
>  
>  #include <linux/cpuidle.h>
> diff --git a/drivers/cpuidle/cpuidle-kirkwood.c b/drivers/cpuidle/cpuidle-kirkwood.c
> index 53290e1..521b0a7 100644
> --- a/drivers/cpuidle/cpuidle-kirkwood.c
> +++ b/drivers/cpuidle/cpuidle-kirkwood.c
> @@ -1,6 +1,4 @@
>  /*
> - * arch/arm/mach-kirkwood/cpuidle.c
> - *
>   * CPU idle Marvell Kirkwood SoCs
>   *
>   * This file is licensed under the terms of the GNU General Public
> @@ -11,6 +9,9 @@
>   * to implement two idle states -
>   * #1 wait-for-interrupt
>   * #2 wait-for-interrupt and DDR self refresh
> + *
> + * Maintainer: Jason Cooper <jason at lakedaemon.net>
> + * Maintainer: Andrew Lunn <andrew at lunn.ch>
>   */
>  
>  #include <linux/kernel.h>
> 



From plagnioj at jcrosoft.com  Wed Apr 24 13:59:59 2013
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Thu, 25 Apr 2013 01:59:59 +0800
Subject: [PATCH v2] ARM: Kconfig: let ARM9TDMI and ARM7TDMI invisible.
In-Reply-To: <20130424174602.GA14496@n2100.arm.linux.org.uk>
References: <51775BB3.6000607@asianux.com> <51775D88.2000406@asianux.com>
 <20130424174602.GA14496@n2100.arm.linux.org.uk>
Message-ID: <8EB7C52E-5044-4B8A-99F2-BCFF9DFDBD2E@jcrosoft.com>


On Apr 25, 2013, at 1:46 AM, Russell King - ARM Linux <linux at arm.linux.org.uk> wrote:

> On Wed, Apr 24, 2013 at 12:20:24PM +0800, Chen Gang wrote:
>> If CONFIG_MMU is disabled, it will let ARM9TDMI and ARM7TDMI visible,
>> but in fact, only AT91X40 need ARM7TDMI, so need not let them visible.
> 
> I'll apply it myself this evening.  Can I add:
> 
> Tested-by: Chen Gang <gang.chen at asianux.com>
you add it mine too

Tested-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>

Best Regards,
J.
> 
> to it?
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel



From viral.vkm at gmail.com  Wed Apr 24 14:07:15 2013
From: viral.vkm at gmail.com (Viral Mehta)
Date: Wed, 24 Apr 2013 23:37:15 +0530
Subject: No subject
Message-ID: <CANX6Damwoz0MSEu5Sb4uKTUhcsC0g+ua1DjuQuMEzXyBOkL7PA@mail.gmail.com>

Hi,

I am using Marvell's ARMADA XP platform in my development environment.

Recently, I faced DMA related issue. While moving data from memory to
the device, I  found that sometimes I am getting Junk data. I looked
further to see if this is related to DMA Sync problem. So, basically,
I have following questions,

1. As per [1] ARMADA has Coherency Fabric that sits between CPU and
other devices and takes care of hardware based I/O cache coherency. Do
we need to enable any support for the same in software ? I am running
3.0.29 based linux kernel. How do I verify that I have all the things
enabled in Linux Kernel.

2. Do I still need to use dma_[map,unamp]_* APIs while copying data to
and from device ?


[1] http://www.marvell.com/embedded-processors/armada-xp/assets/Marvell-ArmadaXP-SoC-product%20brief.pdf

--
Thanks,
Viral Mehta


From stefano.stabellini at eu.citrix.com  Wed Apr 24 14:13:15 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Wed, 24 Apr 2013 19:13:15 +0100
Subject: [Xen-devel] [PATCH v6 1/4] arm: introduce psci_smp_ops
In-Reply-To: <alpine.LFD.2.03.1304221151200.17375@syhkavp.arg>
References: <alpine.DEB.2.02.1304031239550.5078@kaball.uk.xensource.com>
 <1365167495-18508-1-git-send-email-stefano.stabellini@eu.citrix.com>
 <20130418161341.GB14496@n2100.arm.linux.org.uk>
 <alpine.DEB.2.02.1304181714560.7254@kaball.uk.xensource.com>
 <alpine.LFD.2.03.1304181237480.17375@syhkavp.arg>
 <alpine.DEB.2.02.1304181749260.7254@kaball.uk.xensource.com>
 <alpine.LFD.2.03.1304181336280.17375@syhkavp.arg>
 <alpine.DEB.2.02.1304191035360.7254@kaball.uk.xensource.com>
 <alpine.LFD.2.03.1304191146230.17375@syhkavp.arg>
 <1366388166.29403.2.camel@dagon.hellion.org.uk>
 <alpine.LFD.2.03.1304191223280.17375@syhkavp.arg>
 <alpine.DEB.2.02.1304191739120.7254@kaball.uk.xensource.com>
 <1366644069.20256.8.camel@zakaz.uk.xensource.com>
 <alpine.LFD.2.03.1304221151200.17375@syhkavp.arg>
Message-ID: <alpine.DEB.2.02.1304241911420.4180@kaball.uk.xensource.com>

On Mon, 22 Apr 2013, Nicolas Pitre wrote:
> > I think the key thing that non-Xen folks aren't aware of is that
> > although Xen passes the majority of the underlying hardware to the dom0
> > kernel to manage one of the few things it does not expose to guests
> > (where "guests" includes dom0) is the SMP topology of the underlying system.
> 
> I suspect it is unlikely to pass on the DT information about the CCI 
> either.  Which means that, in the case that started this thread, the 
> smp_init function needed by MCPM will simply return false and the next 
> priority in the list i.e. plain PSCI will be initialized instead.
> 
> I don't forsee the need to poke at the hardware directly within 
> ->smp_init, not since everything is moving to DT now.
> 
> Sure there are ways to screw up Xen support from within this hook, but 
> that can be achieved in many other places.  Will Xen take over every 
> possible hooks in the kernel to prevent that from happening?
> 
> So please let's not cry wolf needlessly.

OK, you convinced me :-)
I'll drop the patch.


From stefano.stabellini at eu.citrix.com  Wed Apr 24 14:25:29 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Wed, 24 Apr 2013 19:25:29 +0100
Subject: [PATCH v6 1/4] arm: introduce psci_smp_ops
In-Reply-To: <20130422140601.GH14496@n2100.arm.linux.org.uk>
References: <alpine.DEB.2.02.1304031239550.5078@kaball.uk.xensource.com>
 <1365167495-18508-1-git-send-email-stefano.stabellini@eu.citrix.com>
 <20130418161341.GB14496@n2100.arm.linux.org.uk>
 <alpine.DEB.2.02.1304181714560.7254@kaball.uk.xensource.com>
 <20130422140601.GH14496@n2100.arm.linux.org.uk>
Message-ID: <alpine.DEB.2.02.1304241913280.4180@kaball.uk.xensource.com>

On Mon, 22 Apr 2013, Russell King - ARM Linux wrote:
> > > Now, if the psci stuff can't be relied upon to provide the correct
> > > functionality, then that's a separate problem which needs addressing
> > > differently.
> > > 
> > > This should allow the Xen problem to be resolved, because Xen will
> > > provide the PSCI operations, and it's correct in that case to override
> > > the platform's SMP operations.
> > 
> > Yes, increasing the priority of PSCI helps Xen a lot.
> > In order to completely solve the issue for Xen though, another patch is
> > needed (http://marc.info/?l=linux-kernel&m=136630106201968&w=2) because
> > of the introduction of smp_init.
> 
> Given the way the code in setup.c will work:
> 
> +static bool __init xen_smp_init(void)
> +{
> +#ifdef CONFIG_SMP
> +	/* If we are running on Xen, use PSCI if available.
> +	 * In any case do not try to use the native smp_ops. */
> +	if (psci_smp_available())
> +		smp_set_ops(&psci_smp_ops);
> +#endif
> +	return true;
> +}
> 
> Doesn't this just need to return false, and then we'll drop down to
> using PSCI if those operations are available?

If we are running on Xen, we are sure that the only available mechanism
to boot secondary cpus is PSCI; there is no need to try anything else if
that one is not available. This is way xen_smp_init is returning true
unconditionally.

However I am going to drop the "xen/arm: introduce xen_early_init, use
PSCI on xen" patch linked above entirely, because I'll just assume that
if we are running on Xen smp_init is going to fail and return false. The
next option on the list is PSCI so in theory we won't have to do
anything special to make it work.


From stefano.stabellini at eu.citrix.com  Wed Apr 24 14:38:35 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Wed, 24 Apr 2013 19:38:35 +0100
Subject: [PATCH 0/2 v8] arm: introduce psci_smp_ops
Message-ID: <alpine.DEB.2.02.1304241935010.4180@kaball.uk.xensource.com>

Hi all,
this is the eighth version of the patch series to move virt_smp_ops out
of mach-virt and make it a generic set of reusable PSCI based smp_ops.
psci_smp_ops are preferred over the platform smp_ops.
The last patch introduces smp_init.


Jon Medhurst (1):
      ARM: Enable selection of SMP operations at boot time

Stefano Stabellini (1):
      arm: introduce psci_smp_ops

 arch/arm/include/asm/mach/arch.h |    4 ++
 arch/arm/include/asm/psci.h      |   29 ++++++++++++++++
 arch/arm/kernel/Makefile         |    5 ++-
 arch/arm/kernel/psci.c           |    7 ++--
 arch/arm/kernel/psci_smp.c       |   67 ++++++++++++++++++++++++++++++++++++++
 arch/arm/kernel/setup.c          |    9 ++++-
 arch/arm/mach-virt/Makefile      |    1 -
 arch/arm/mach-virt/platsmp.c     |   58 --------------------------------
 arch/arm/mach-virt/virt.c        |    3 --
 9 files changed, 115 insertions(+), 68 deletions(-)

git://git.kernel.org/pub/scm/linux/kernel/git/sstabellini/xen.git 3.9-rc3-psci-ops-8-tag

Cheers,

Stefano


From stefano.stabellini at eu.citrix.com  Wed Apr 24 14:40:18 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Wed, 24 Apr 2013 19:40:18 +0100
Subject: [PATCH v8 1/2] arm: introduce psci_smp_ops
In-Reply-To: <alpine.DEB.2.02.1304241935010.4180@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1304241935010.4180@kaball.uk.xensource.com>
Message-ID: <1366828819-10745-1-git-send-email-stefano.stabellini@eu.citrix.com>

Rename virt_smp_ops to psci_smp_ops and move them to arch/arm/kernel/psci_smp.c.
Remove mach-virt/platsmp.c, now unused.
Compile psci_smp if CONFIG_ARM_PSCI and CONFIG_SMP.

Add a cpu_die smp_op based on psci_ops.cpu_off.

Initialize PSCI before setting smp_ops in setup_arch.
Use psci_smp_ops if the platform doesn't provide its own smp_ops.

If PSCI is available on the platform, prefer psci_smp_ops over the
platform smp_ops.

Changes in v8:
- merge "prefer psci_smp_ops over mdesc->smp" into this patch.

Changes in v6:
- fixed return values for psci_smp_available and psci_init ifndef
CONFIG_ARM_PSCI.

Changes in v5:
- document psci_operations;
- psci_init returns NULL.

Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
---
 arch/arm/include/asm/psci.h  |   29 ++++++++++++++++++
 arch/arm/kernel/Makefile     |    5 ++-
 arch/arm/kernel/psci.c       |    7 ++--
 arch/arm/kernel/psci_smp.c   |   67 ++++++++++++++++++++++++++++++++++++++++++
 arch/arm/kernel/setup.c      |    7 ++++-
 arch/arm/mach-virt/Makefile  |    1 -
 arch/arm/mach-virt/platsmp.c |   58 ------------------------------------
 arch/arm/mach-virt/virt.c    |    3 --
 8 files changed, 109 insertions(+), 68 deletions(-)
 create mode 100644 arch/arm/kernel/psci_smp.c
 delete mode 100644 arch/arm/mach-virt/platsmp.c

diff --git a/arch/arm/include/asm/psci.h b/arch/arm/include/asm/psci.h
index ce0dbe7..fa44417 100644
--- a/arch/arm/include/asm/psci.h
+++ b/arch/arm/include/asm/psci.h
@@ -23,6 +23,26 @@ struct psci_power_state {
 	u8	affinity_level;
 };
 
+/*
+ * cpu_suspend   Suspend the execution on a CPU
+ * @state        we don't currently describe affinity levels, so just pass 0.
+ * @entry_point  the first instruction to be executed on return
+ * returns 0  success, < 0 on failure
+ *
+ * cpu_off       Power down a CPU
+ * @state        we don't currently describe affinity levels, so just pass 0.
+ * no return on successful call
+ *
+ * cpu_on        Power up a CPU
+ * @cpuid        cpuid of target CPU, as from MPIDR
+ * @entry_point  the first instruction to be executed on return
+ * returns 0  success, < 0 on failure
+ *
+ * migrate       Migrate the context to a different CPU
+ * @cpuid        cpuid of target CPU, as from MPIDR
+ * returns 0  success, < 0 on failure
+ *
+ */
 struct psci_operations {
 	int (*cpu_suspend)(struct psci_power_state state,
 			   unsigned long entry_point);
@@ -32,5 +52,14 @@ struct psci_operations {
 };
 
 extern struct psci_operations psci_ops;
+extern struct smp_operations psci_smp_ops;
+
+#ifdef CONFIG_ARM_PSCI
+void psci_init(void);
+bool psci_smp_available(void);
+#else
+static inline void psci_init(void) { }
+static inline bool psci_smp_available(void) { return false; }
+#endif
 
 #endif /* __ASM_ARM_PSCI_H */
diff --git a/arch/arm/kernel/Makefile b/arch/arm/kernel/Makefile
index 5f3338e..dd9d90a 100644
--- a/arch/arm/kernel/Makefile
+++ b/arch/arm/kernel/Makefile
@@ -82,6 +82,9 @@ obj-$(CONFIG_DEBUG_LL)	+= debug.o
 obj-$(CONFIG_EARLY_PRINTK)	+= early_printk.o
 
 obj-$(CONFIG_ARM_VIRT_EXT)	+= hyp-stub.o
-obj-$(CONFIG_ARM_PSCI)		+= psci.o
+ifeq ($(CONFIG_ARM_PSCI),y)
+obj-y				+= psci.o
+obj-$(CONFIG_SMP)		+= psci_smp.o
+endif
 
 extra-y := $(head-y) vmlinux.lds
diff --git a/arch/arm/kernel/psci.c b/arch/arm/kernel/psci.c
index 3653164..4693188 100644
--- a/arch/arm/kernel/psci.c
+++ b/arch/arm/kernel/psci.c
@@ -158,7 +158,7 @@ static const struct of_device_id psci_of_match[] __initconst = {
 	{},
 };
 
-static int __init psci_init(void)
+void __init psci_init(void)
 {
 	struct device_node *np;
 	const char *method;
@@ -166,7 +166,7 @@ static int __init psci_init(void)
 
 	np = of_find_matching_node(NULL, psci_of_match);
 	if (!np)
-		return 0;
+		return;
 
 	pr_info("probing function IDs from device-tree\n");
 
@@ -206,6 +206,5 @@ static int __init psci_init(void)
 
 out_put_node:
 	of_node_put(np);
-	return 0;
+	return;
 }
-early_initcall(psci_init);
diff --git a/arch/arm/kernel/psci_smp.c b/arch/arm/kernel/psci_smp.c
new file mode 100644
index 0000000..66b0f77
--- /dev/null
+++ b/arch/arm/kernel/psci_smp.c
@@ -0,0 +1,67 @@
+/*
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Copyright (C) 2012 ARM Limited
+ *
+ * Author: Will Deacon <will.deacon at arm.com>
+ */
+
+#include <linux/init.h>
+#include <linux/irqchip/arm-gic.h>
+#include <linux/smp.h>
+#include <linux/of.h>
+
+#include <asm/psci.h>
+#include <asm/smp_plat.h>
+
+extern void secondary_startup(void);
+
+static int __cpuinit psci_boot_secondary(unsigned int cpu,
+					 struct task_struct *idle)
+{
+	if (psci_ops.cpu_on)
+		return psci_ops.cpu_on(cpu_logical_map(cpu),
+				       __pa(secondary_startup));
+	return -ENODEV;
+}
+
+static void __cpuinit psci_secondary_init(unsigned int cpu)
+{
+	gic_secondary_init(0);
+}
+
+#ifdef CONFIG_HOTPLUG_CPU
+void __ref psci_cpu_die(unsigned int cpu)
+{
+       const struct psci_power_state ps = {
+               .type = PSCI_POWER_STATE_TYPE_POWER_DOWN,
+       };
+
+       if (psci_ops.cpu_off)
+               psci_ops.cpu_off(ps);
+
+       /* We should never return */
+       panic("psci: cpu %d failed to shutdown\n", cpu);
+}
+#else
+#define psci_cpu_die NULL
+#endif
+
+bool __init psci_smp_available(void)
+{
+	/* is cpu_on available at least? */
+	return (psci_ops.cpu_on != NULL);
+}
+
+struct smp_operations __initdata psci_smp_ops = {
+	.smp_secondary_init	= psci_secondary_init,
+	.smp_boot_secondary	= psci_boot_secondary,
+	.cpu_die		= psci_cpu_die,
+};
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 3f6cbb2..dad3048 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -36,6 +36,7 @@
 #include <asm/cputype.h>
 #include <asm/elf.h>
 #include <asm/procinfo.h>
+#include <asm/psci.h>
 #include <asm/sections.h>
 #include <asm/setup.h>
 #include <asm/smp_plat.h>
@@ -766,9 +767,13 @@ void __init setup_arch(char **cmdline_p)
 	unflatten_device_tree();
 
 	arm_dt_init_cpu_maps();
+	psci_init();
 #ifdef CONFIG_SMP
 	if (is_smp()) {
-		smp_set_ops(mdesc->smp);
+		if (psci_smp_available())
+			smp_set_ops(&psci_smp_ops);
+		else if (mdesc->smp)
+			smp_set_ops(mdesc->smp);
 		smp_init_cpus();
 	}
 #endif
diff --git a/arch/arm/mach-virt/Makefile b/arch/arm/mach-virt/Makefile
index 042afc1..7ddbfa6 100644
--- a/arch/arm/mach-virt/Makefile
+++ b/arch/arm/mach-virt/Makefile
@@ -3,4 +3,3 @@
 #
 
 obj-y					:= virt.o
-obj-$(CONFIG_SMP)			+= platsmp.o
diff --git a/arch/arm/mach-virt/platsmp.c b/arch/arm/mach-virt/platsmp.c
deleted file mode 100644
index 8badaab..0000000
--- a/arch/arm/mach-virt/platsmp.c
+++ /dev/null
@@ -1,58 +0,0 @@
-/*
- * Dummy Virtual Machine - does what it says on the tin.
- *
- * Copyright (C) 2012 ARM Ltd
- * Author: Will Deacon <will.deacon at arm.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.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program.  If not, see <http://www.gnu.org/licenses/>.
- */
-
-#include <linux/init.h>
-#include <linux/smp.h>
-#include <linux/of.h>
-
-#include <linux/irqchip/arm-gic.h>
-
-#include <asm/psci.h>
-#include <asm/smp_plat.h>
-
-extern void secondary_startup(void);
-
-static void __init virt_smp_init_cpus(void)
-{
-}
-
-static void __init virt_smp_prepare_cpus(unsigned int max_cpus)
-{
-}
-
-static int __cpuinit virt_boot_secondary(unsigned int cpu,
-					 struct task_struct *idle)
-{
-	if (psci_ops.cpu_on)
-		return psci_ops.cpu_on(cpu_logical_map(cpu),
-				       __pa(secondary_startup));
-	return -ENODEV;
-}
-
-static void __cpuinit virt_secondary_init(unsigned int cpu)
-{
-	gic_secondary_init(0);
-}
-
-struct smp_operations __initdata virt_smp_ops = {
-	.smp_init_cpus		= virt_smp_init_cpus,
-	.smp_prepare_cpus	= virt_smp_prepare_cpus,
-	.smp_secondary_init	= virt_secondary_init,
-	.smp_boot_secondary	= virt_boot_secondary,
-};
diff --git a/arch/arm/mach-virt/virt.c b/arch/arm/mach-virt/virt.c
index 31666f6..4438ed0 100644
--- a/arch/arm/mach-virt/virt.c
+++ b/arch/arm/mach-virt/virt.c
@@ -43,12 +43,9 @@ static const char *virt_dt_match[] = {
 	NULL
 };
 
-extern struct smp_operations virt_smp_ops;
-
 DT_MACHINE_START(VIRT, "Dummy Virtual Machine")
 	.init_irq	= irqchip_init,
 	.init_time	= virt_timer_init,
 	.init_machine	= virt_init,
-	.smp		= smp_ops(virt_smp_ops),
 	.dt_compat	= virt_dt_match,
 MACHINE_END
-- 
1.7.2.5



From stefano.stabellini at eu.citrix.com  Wed Apr 24 14:40:19 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Wed, 24 Apr 2013 19:40:19 +0100
Subject: [PATCH v8 2/2] ARM: Enable selection of SMP operations at boot time
In-Reply-To: <alpine.DEB.2.02.1304241935010.4180@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1304241935010.4180@kaball.uk.xensource.com>
Message-ID: <1366828819-10745-2-git-send-email-stefano.stabellini@eu.citrix.com>

From: Jon Medhurst <tixy at linaro.org>

Add a new 'smp_init' hook to machine_desc so platforms can specify a
function to be used to setup smp ops instead of having a statically
defined value.  The hook must return true when smp_ops are initialized.
If false the static mdesc->smp_ops will be used by default.

Signed-off-by: Jon Medhurst <tixy at linaro.org>
Signed-off-by: Nicolas Pitre <nicolas.pitre at linaro.org>
Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
Reviewed-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
---
 arch/arm/include/asm/mach/arch.h |    4 ++++
 arch/arm/kernel/setup.c          |   10 ++++++----
 2 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/arch/arm/include/asm/mach/arch.h b/arch/arm/include/asm/mach/arch.h
index 308ad7d..4669e0b 100644
--- a/arch/arm/include/asm/mach/arch.h
+++ b/arch/arm/include/asm/mach/arch.h
@@ -16,8 +16,10 @@ struct pt_regs;
 struct smp_operations;
 #ifdef CONFIG_SMP
 #define smp_ops(ops) (&(ops))
+#define smp_init_ops(ops) (&(ops))
 #else
 #define smp_ops(ops) (struct smp_operations *)NULL
+#define smp_init_ops(ops) (bool (*)(void))NULL
 #endif
 
 struct machine_desc {
@@ -41,6 +43,8 @@ struct machine_desc {
 	unsigned char		reserve_lp2 :1;	/* never has lp2	*/
 	char			restart_mode;	/* default restart mode	*/
 	struct smp_operations	*smp;		/* SMP operations	*/
+	/* Detect smp_ops dynamically, based on DT */
+	bool			(*smp_init)(void);
 	void			(*fixup)(struct tag *, char **,
 					 struct meminfo *);
 	void			(*reserve)(void);/* reserve mem blocks	*/
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index dad3048..22cc863 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -770,10 +770,12 @@ void __init setup_arch(char **cmdline_p)
 	psci_init();
 #ifdef CONFIG_SMP
 	if (is_smp()) {
-		if (psci_smp_available())
-			smp_set_ops(&psci_smp_ops);
-		else if (mdesc->smp)
-			smp_set_ops(mdesc->smp);
+		if (!mdesc->smp_init || !mdesc->smp_init()) {
+			if (psci_smp_available())
+				smp_set_ops(&psci_smp_ops);
+			else if (mdesc->smp)
+				smp_set_ops(mdesc->smp);
+		}
 		smp_init_cpus();
 	}
 #endif
-- 
1.7.2.5



From marex at denx.de  Wed Apr 24 14:43:59 2013
From: marex at denx.de (Marek Vasut)
Date: Wed, 24 Apr 2013 20:43:59 +0200
Subject: [PATCH V2] video: imx: Select VIDEOMODE_HELPERS for parallel display
Message-ID: <1366829039-12452-1-git-send-email-marex@denx.de>

Without this, I get the following problem when building kernel:

drivers/built-in.o: In function `imx_pd_connector_get_modes':
/linux-2.6/drivers/staging/imx-drm/parallel-display.c:78: undefined reference to `of_get_drm_display_mode'
make: *** [vmlinux] Error 1

Signed-off-by: Marek Vasut <marex at denx.de>
Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
Cc: Sascha Hauer <s.hauer at pengutronix.de>
Cc: Philipp Zabel <p.zabel at pengutronix.de>
Cc: Fabio Estevam <fabio.estevam at freescale.com>
---
 drivers/staging/imx-drm/Kconfig |    1 +
 1 file changed, 1 insertion(+)

V2: Select VIDEOMODE_HELPERS only for parallel display

diff --git a/drivers/staging/imx-drm/Kconfig b/drivers/staging/imx-drm/Kconfig
index 8c9e403..0550f01 100644
--- a/drivers/staging/imx-drm/Kconfig
+++ b/drivers/staging/imx-drm/Kconfig
@@ -19,6 +19,7 @@ config DRM_IMX_FB_HELPER
 config DRM_IMX_PARALLEL_DISPLAY
 	tristate "Support for parallel displays"
 	depends on DRM_IMX
+	select VIDEOMODE_HELPERS
 
 config DRM_IMX_TVE
 	tristate "Support for TV and VGA displays"
-- 
1.7.10.4



From tony at atomide.com  Wed Apr 24 15:08:21 2013
From: tony at atomide.com (Tony Lindgren)
Date: Wed, 24 Apr 2013 12:08:21 -0700
Subject: Multiple issues with omap4 panda es in linux next
In-Reply-To: <517770A0.4000609@ti.com>
References: <20130419171318.GK10155@atomide.com> <5174F7A8.7070308@ti.com>
 <20130422180316.GA10155@atomide.com> <5176A45B.5@ti.com>
 <20130423172353.GD10155@atomide.com>
 <20130423213151.GM10155@atomide.com>
 <20130423231605.GO10155@atomide.com> <517770A0.4000609@ti.com>
Message-ID: <20130424190821.GB5184@atomide.com>

* Kishon Vijay Abraham I <kishon at ti.com> [130423 22:46]:
> Hi Tony,
> 
> On Wednesday 24 April 2013 04:46 AM, Tony Lindgren wrote:
> >* Tony Lindgren <tony at atomide.com> [130423 14:37]:
> >>* Tony Lindgren <tony at atomide.com> [130423 10:28]:
> >>>* Kishon Vijay Abraham I <kishon at ti.com> [130423 08:15]:
> >>>>>>>2. MUSB fails with legacy booting and DT on panda es
> >>>>>>>
> >>>>>>>With both legacy and DT booting I get something like:
> >>>>>>>
> >>>>>>>HS USB OTG: no transceiver configured
> >>>>>>>musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with status -517
> >>>>>>
> >>>>>>The dt should work fine with https://patchwork.kernel.org/patch/2423061/.
> >>>>>
> >>>>>OK thanks for checking that.
> >
> >Kishon, I think there's also some other issue remaining
> >in linux next with MUSB and DT. I'm still getting the
> >"HS USB OTG: no transceiver configured" although the nop
> >xceiv is compiled in. Maybe give it a try against linux
> >next?
> 
> For OMAP4 MUSB, you'll need omap-usb2 phy. I've attached my .config.

Thanks your config helped me to track it down. Looks like I got
the PHYs the wrong way around between EHCI and MUSB..

In any case, I did have omap-usb2 compiled in, but I did not have
OMAP_OCP2SCP=y set. Should OMAP_USB2 depend on that?

Also, looks like MUSB just sits in b_idle mode though, so no more
ID pin interrupt for some reason.

Regards,

Tony


From tony at atomide.com  Wed Apr 24 15:23:30 2013
From: tony at atomide.com (Tony Lindgren)
Date: Wed, 24 Apr 2013 12:23:30 -0700
Subject: Multiple issues with omap4 panda es in linux next
In-Reply-To: <20130424190821.GB5184@atomide.com>
References: <20130419171318.GK10155@atomide.com> <5174F7A8.7070308@ti.com>
 <20130422180316.GA10155@atomide.com> <5176A45B.5@ti.com>
 <20130423172353.GD10155@atomide.com>
 <20130423213151.GM10155@atomide.com>
 <20130423231605.GO10155@atomide.com> <517770A0.4000609@ti.com>
 <20130424190821.GB5184@atomide.com>
Message-ID: <20130424192330.GC5184@atomide.com>

* Tony Lindgren <tony at atomide.com> [130424 12:13]:
> * Kishon Vijay Abraham I <kishon at ti.com> [130423 22:46]:
> > Hi Tony,
> > 
> > On Wednesday 24 April 2013 04:46 AM, Tony Lindgren wrote:
> > >* Tony Lindgren <tony at atomide.com> [130423 14:37]:
> > >>* Tony Lindgren <tony at atomide.com> [130423 10:28]:
> > >>>* Kishon Vijay Abraham I <kishon at ti.com> [130423 08:15]:
> > >>>>>>>2. MUSB fails with legacy booting and DT on panda es
> > >>>>>>>
> > >>>>>>>With both legacy and DT booting I get something like:
> > >>>>>>>
> > >>>>>>>HS USB OTG: no transceiver configured
> > >>>>>>>musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with status -517
> > >>>>>>
> > >>>>>>The dt should work fine with https://patchwork.kernel.org/patch/2423061/.
> > >>>>>
> > >>>>>OK thanks for checking that.
> > >
> > >Kishon, I think there's also some other issue remaining
> > >in linux next with MUSB and DT. I'm still getting the
> > >"HS USB OTG: no transceiver configured" although the nop
> > >xceiv is compiled in. Maybe give it a try against linux
> > >next?
> > 
> > For OMAP4 MUSB, you'll need omap-usb2 phy. I've attached my .config.
> 
> Thanks your config helped me to track it down. Looks like I got
> the PHYs the wrong way around between EHCI and MUSB..
> 
> In any case, I did have omap-usb2 compiled in, but I did not have
> OMAP_OCP2SCP=y set. Should OMAP_USB2 depend on that?
> 
> Also, looks like MUSB just sits in b_idle mode though, so no more
> ID pin interrupt for some reason.

OK looks like I got the ID interrupt going by enabling
CONFIG_TWL6030_USB=y. Still stays in a_idle with no keyboard
after plugging it in, but now changes between a and b mode.

Regards,

Tony


From rabin at rab.in  Wed Apr 24 15:24:05 2013
From: rabin at rab.in (Rabin Vincent)
Date: Wed, 24 Apr 2013 21:24:05 +0200
Subject: [PATCH 03/32 v3] dmaengine: ste_dma40: Use the BIT macro to
 replace ugly '(1 << x)'s
In-Reply-To: <20130424151145.GH9652@gmail.com>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-4-git-send-email-lee.jones@linaro.org>
 <20130424151145.GH9652@gmail.com>
Message-ID: <CAH+eYFBKnEWkcJ+9DxVqnxbPS4QYtswi7Ux0JHnTWYfRFy_5Aw@mail.gmail.com>

2013/4/24 Lee Jones <lee.jones at linaro.org>:
> The aim is to make the code that little more readable.
>
> Acked-by: Vinod Koul <vnod.koul at intel.com>
> Acked-by: Arnd Bergmann <arnd at arndb.de>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>

Please pay closer attention to the semantics of each usage instead of
just replacing all x left shifts of 1 by BIT(x) for "readability".

>         if (seg_max > STEDMA40_MAX_SEG_SIZE)
> -               seg_max -= (1 << max_w);
> +               seg_max -= BIT(max_w);
>
> -       if (!IS_ALIGNED(size, 1 << max_w))
> +       if (!IS_ALIGNED(size, BIT(max_w)))
>                 return -EINVAL;

Here and in all other places where the values are from cfg->data_width,
the semantic purpose of the shift is not for setting a particular bit
but instead for converting the data_width field into the data width
value in bytes.  You should not change these usages to BIT().

It would be instead better to just make the cfg->data_width as the
number of bytes and convert them to the appropriate hardware field
values when the descriptors are constructed.  That of course should be
in another patch.


From stefano.stabellini at eu.citrix.com  Wed Apr 24 15:25:38 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Wed, 24 Apr 2013 20:25:38 +0100
Subject: [PATCH v4 0/7] xen/arm: move to mach-virt and support SMP
Message-ID: <alpine.DEB.2.02.1304242012590.4180@kaball.uk.xensource.com>

Hi all,
this patch series, based on 3.9-rc3, moves xenvm to mach-virt and
implements SMP support in Xen on ARM.

Each patch comes with a detailed changelog.


Changes in v4:
- XEN should select ARM_PSCI;
- update arch/arm/boot/dts/Makefile to build the xenvm dts
  if CONFIG_ARCH_VIRT;
- add a patch to introduce Xen shutdown hypercall support to mach-virt.


Stefano Stabellini (7):
      xen/arm: actually pass a non-NULL percpu pointer to request_percpu_irq
      xen/arm: SMP support
      xen: move the xenvm machine to mach-virt
      xen/arm: implement HYPERVISOR_vcpu_op
      xen/arm: XEN selects ARM_PSCI
      xenvm: add a simple PSCI node and a second cpu
      mach-virt: support Xen hypercalls for shutdown and reboot

 arch/arm/Kconfig                     |    1 +
 arch/arm/boot/dts/Makefile           |    4 +-
 arch/arm/boot/dts/xenvm-4.2.dts      |   13 ++++++++++
 arch/arm/include/asm/xen/hypercall.h |    1 +
 arch/arm/mach-vexpress/v2m.c         |    1 -
 arch/arm/mach-virt/virt.c            |   33 +++++++++++++++++++++++++++
 arch/arm/xen/enlighten.c             |   41 ++++++++++++++++++++++++++++++++-
 arch/arm/xen/hypercall.S             |    1 +
 8 files changed, 90 insertions(+), 5 deletions(-)

git://git.kernel.org/pub/scm/linux/kernel/git/sstabellini/xen.git 3.9-rc3-smp-4-tag

Cheers,

Stefano


From linus.walleij at linaro.org  Wed Apr 24 15:37:37 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Wed, 24 Apr 2013 21:37:37 +0200
Subject: gpio-pxa initcall level change and machine init breakage
In-Reply-To: <5176E438.80800@newsguy.com>
References: <5172B398.7060706@newsguy.com>
 <CAD6h2NSRA9w7GZLQGgK-+TvEAsxwOHow5_26JyVUA6YQyj3OQg@mail.gmail.com>
 <517466F6.3000003@newsguy.com>
 <CAD6h2NSy0=3P-PHdCiJJQG_jvGaFnr7uex+Uxs=0F-VsUxtPWg@mail.gmail.com>
 <CACRpkdbk24kR75fanvXVAocnuozNq_=jWDSPHPCWhbZCOrN5_Q@mail.gmail.com>
 <5176E438.80800@newsguy.com>
Message-ID: <CACRpkdYLCKKZZFi6Y-viPUvrwupJGzfxr3f20a1emp-9qE0YBg@mail.gmail.com>

On Tue, Apr 23, 2013 at 9:42 PM, Mike Dunn <mikedunn at newsguy.com> wrote:

> On a more general note... I'm surprised that gpiolib can not run earlier, for
> something so low-level.

Well I think the patch we're discussing is making it run less early, and it
can actually run as arch_initcall() or similar if you wish (it's up to the
driver).

However that is beside the point, Haojian is still doing the right thing
trying to push this to driver init (==module_init) level. The reason is
that basically all hardware drivers should be initialized at this level
because the other init levels are basically for other things and driver
deps are just shoehorned into them.

Instead of relying on things to be set up early one shall rely on
deferred probe.

Alas, it is not an easy change, and not expected to happen quickly
or painlessly.

Yours,
Linus Walleij


From stefano.stabellini at eu.citrix.com  Wed Apr 24 15:28:15 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Wed, 24 Apr 2013 20:28:15 +0100
Subject: [PATCH v4 7/7] mach-virt: support Xen hypercalls for shutdown and
 reboot
In-Reply-To: <alpine.DEB.2.02.1304242012590.4180@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1304242012590.4180@kaball.uk.xensource.com>
Message-ID: <1366831695-13214-7-git-send-email-stefano.stabellini@eu.citrix.com>

Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
CC: Marc Zyngier <marc.zyngier at arm.com>
CC: will.deacon at arm.com
CC: arnd at arndb.de
CC: rob.herring at calxeda.com
---
 arch/arm/mach-virt/virt.c |   32 ++++++++++++++++++++++++++++++++
 1 files changed, 32 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-virt/virt.c b/arch/arm/mach-virt/virt.c
index 528c05e..ba14321 100644
--- a/arch/arm/mach-virt/virt.c
+++ b/arch/arm/mach-virt/virt.c
@@ -23,13 +23,44 @@
 #include <linux/of_platform.h>
 #include <linux/smp.h>
 
+#include <xen/xen.h>
+#include <xen/interface/sched.h>
+
 #include <asm/arch_timer.h>
 #include <asm/mach/arch.h>
 #include <asm/mach/time.h>
+#include <asm/xen/hypercall.h>
+
+static void virt_restart(char str, const char *cmd)
+{
+#ifdef CONFIG_XEN
+	if (xen_domain()) {
+		struct sched_shutdown r = { .reason = SHUTDOWN_reboot };
+		int rc;
+		rc = HYPERVISOR_sched_op(SCHEDOP_shutdown, &r);
+		if (rc)
+			BUG();
+	}
+#endif
+}
+
+static void virt_power_off(void)
+{
+#ifdef CONFIG_XEN
+	if (xen_domain()) {
+		struct sched_shutdown r = { .reason = SHUTDOWN_poweroff };
+		int rc;
+		rc = HYPERVISOR_sched_op(SCHEDOP_shutdown, &r);
+		if (rc)
+			BUG();
+	}
+#endif
+}
 
 static void __init virt_init(void)
 {
 	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
+	pm_power_off = virt_power_off;
 }
 
 static void __init virt_timer_init(void)
@@ -52,4 +83,5 @@ DT_MACHINE_START(VIRT, "Dummy Virtual Machine")
 	.init_machine	= virt_init,
 	.smp		= smp_ops(virt_smp_ops),
 	.dt_compat	= virt_dt_match,
+	.restart	= virt_restart,
 MACHINE_END
-- 
1.7.2.5



From stefano.stabellini at eu.citrix.com  Wed Apr 24 15:28:11 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Wed, 24 Apr 2013 20:28:11 +0100
Subject: [PATCH v4 3/7] xen: move the xenvm machine to mach-virt
In-Reply-To: <alpine.DEB.2.02.1304242012590.4180@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1304242012590.4180@kaball.uk.xensource.com>
Message-ID: <1366831695-13214-3-git-send-email-stefano.stabellini@eu.citrix.com>

xenvm is based on mach-vexpress, move it to mach-virt.

Changes in v4:
- update the dts Makefile too.

Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
CC: Marc Zyngier <marc.zyngier at arm.com>
CC: will.deacon at arm.com
CC: arnd at arndb.de
CC: rob.herring at calxeda.com
---
 arch/arm/boot/dts/Makefile   |    4 ++--
 arch/arm/mach-vexpress/v2m.c |    1 -
 arch/arm/mach-virt/virt.c    |    1 +
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 9c62558..b6289b7 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -168,8 +168,8 @@ dtb-$(CONFIG_ARCH_TEGRA) += tegra20-harmony.dtb \
 dtb-$(CONFIG_ARCH_VEXPRESS) += vexpress-v2p-ca5s.dtb \
 	vexpress-v2p-ca9.dtb \
 	vexpress-v2p-ca15-tc1.dtb \
-	vexpress-v2p-ca15_a7.dtb \
-	xenvm-4.2.dtb
+	vexpress-v2p-ca15_a7.dtb
+dtb-$(CONFIG_ARCH_VIRT) += xenvm-4.2.dtb
 dtb-$(CONFIG_ARCH_VT8500) += vt8500-bv07.dtb \
 	wm8505-ref.dtb \
 	wm8650-mid.dtb \
diff --git a/arch/arm/mach-vexpress/v2m.c b/arch/arm/mach-vexpress/v2m.c
index 915683c..c43ec78 100644
--- a/arch/arm/mach-vexpress/v2m.c
+++ b/arch/arm/mach-vexpress/v2m.c
@@ -469,7 +469,6 @@ static void __init v2m_dt_init(void)
 
 static const char * const v2m_dt_match[] __initconst = {
 	"arm,vexpress",
-	"xen,xenvm",
 	NULL,
 };
 
diff --git a/arch/arm/mach-virt/virt.c b/arch/arm/mach-virt/virt.c
index 31666f6..528c05e 100644
--- a/arch/arm/mach-virt/virt.c
+++ b/arch/arm/mach-virt/virt.c
@@ -40,6 +40,7 @@ static void __init virt_timer_init(void)
 
 static const char *virt_dt_match[] = {
 	"linux,dummy-virt",
+	"xen,xenvm",
 	NULL
 };
 
-- 
1.7.2.5



From stefano.stabellini at eu.citrix.com  Wed Apr 24 15:28:09 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Wed, 24 Apr 2013 20:28:09 +0100
Subject: [PATCH v4 1/7] xen/arm: actually pass a non-NULL percpu pointer to
 request_percpu_irq
In-Reply-To: <alpine.DEB.2.02.1304242012590.4180@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1304242012590.4180@kaball.uk.xensource.com>
Message-ID: <1366831695-13214-1-git-send-email-stefano.stabellini@eu.citrix.com>

Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
CC: stable at vger.kernel.org
---
 arch/arm/xen/enlighten.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 8dc0605..99ce189 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -239,7 +239,7 @@ static int __init xen_init_events(void)
 	xen_init_IRQ();
 
 	if (request_percpu_irq(xen_events_irq, xen_arm_callback,
-			"events", xen_vcpu)) {
+			"events", &xen_vcpu)) {
 		pr_err("Error requesting IRQ %d\n", xen_events_irq);
 		return -EINVAL;
 	}
-- 
1.7.2.5



From stefano.stabellini at eu.citrix.com  Wed Apr 24 15:28:13 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Wed, 24 Apr 2013 20:28:13 +0100
Subject: [PATCH v4 5/7] xen/arm: XEN selects ARM_PSCI
In-Reply-To: <alpine.DEB.2.02.1304242012590.4180@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1304242012590.4180@kaball.uk.xensource.com>
Message-ID: <1366831695-13214-5-git-send-email-stefano.stabellini@eu.citrix.com>

Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
---
 arch/arm/Kconfig |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 2c3bdce..344e299 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1892,6 +1892,7 @@ config XEN
 	depends on ARM && AEABI && OF
 	depends on CPU_V7 && !CPU_V6
 	depends on !GENERIC_ATOMIC64
+	select ARM_PSCI
 	help
 	  Say Y if you want to run Linux in a Virtual Machine on Xen on ARM.
 
-- 
1.7.2.5



From stefano.stabellini at eu.citrix.com  Wed Apr 24 15:28:14 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Wed, 24 Apr 2013 20:28:14 +0100
Subject: [PATCH v4 6/7] xenvm: add a simple PSCI node and a second cpu
In-Reply-To: <alpine.DEB.2.02.1304242012590.4180@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1304242012590.4180@kaball.uk.xensource.com>
Message-ID: <1366831695-13214-6-git-send-email-stefano.stabellini@eu.citrix.com>

Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
Acked-by: Marc Zyngier <marc.zyngier at arm.com>
CC: rob.herring at calxeda.com
CC: will.deacon at arm.com
CC: arnd at arndb.de
---
 arch/arm/boot/dts/xenvm-4.2.dts |   13 +++++++++++++
 1 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/xenvm-4.2.dts b/arch/arm/boot/dts/xenvm-4.2.dts
index ec3f952..3369151 100644
--- a/arch/arm/boot/dts/xenvm-4.2.dts
+++ b/arch/arm/boot/dts/xenvm-4.2.dts
@@ -29,6 +29,19 @@
 			compatible = "arm,cortex-a15";
 			reg = <0>;
 		};
+
+		cpu at 1 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a15";
+			reg = <1>;
+		};
+	};
+
+	psci {
+		compatible      = "arm,psci";
+		method          = "hvc";
+		cpu_off         = <1>;
+		cpu_on          = <2>;
 	};
 
 	memory at 80000000 {
-- 
1.7.2.5



From stefano.stabellini at eu.citrix.com  Wed Apr 24 15:28:12 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Wed, 24 Apr 2013 20:28:12 +0100
Subject: [PATCH v4 4/7] xen/arm: implement HYPERVISOR_vcpu_op
In-Reply-To: <alpine.DEB.2.02.1304242012590.4180@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1304242012590.4180@kaball.uk.xensource.com>
Message-ID: <1366831695-13214-4-git-send-email-stefano.stabellini@eu.citrix.com>

Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
---
 arch/arm/include/asm/xen/hypercall.h |    1 +
 arch/arm/xen/enlighten.c             |    1 +
 arch/arm/xen/hypercall.S             |    1 +
 3 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/arm/include/asm/xen/hypercall.h b/arch/arm/include/asm/xen/hypercall.h
index 8a82325..799f42e 100644
--- a/arch/arm/include/asm/xen/hypercall.h
+++ b/arch/arm/include/asm/xen/hypercall.h
@@ -46,6 +46,7 @@ int HYPERVISOR_event_channel_op(int cmd, void *arg);
 unsigned long HYPERVISOR_hvm_op(int op, void *arg);
 int HYPERVISOR_memory_op(unsigned int cmd, void *arg);
 int HYPERVISOR_physdev_op(int cmd, void *arg);
+int HYPERVISOR_vcpu_op(int cmd, int vcpuid, void *extra_args);
 
 static inline void
 MULTI_update_va_mapping(struct multicall_entry *mcl, unsigned long va,
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 94bbf3b..b002822 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -295,4 +295,5 @@ EXPORT_SYMBOL_GPL(HYPERVISOR_sched_op);
 EXPORT_SYMBOL_GPL(HYPERVISOR_hvm_op);
 EXPORT_SYMBOL_GPL(HYPERVISOR_memory_op);
 EXPORT_SYMBOL_GPL(HYPERVISOR_physdev_op);
+EXPORT_SYMBOL_GPL(HYPERVISOR_vcpu_op);
 EXPORT_SYMBOL_GPL(privcmd_call);
diff --git a/arch/arm/xen/hypercall.S b/arch/arm/xen/hypercall.S
index 71f7239..199cb2d 100644
--- a/arch/arm/xen/hypercall.S
+++ b/arch/arm/xen/hypercall.S
@@ -87,6 +87,7 @@ HYPERCALL2(event_channel_op);
 HYPERCALL2(hvm_op);
 HYPERCALL2(memory_op);
 HYPERCALL2(physdev_op);
+HYPERCALL3(vcpu_op);
 
 ENTRY(privcmd_call)
 	stmdb sp!, {r4}
-- 
1.7.2.5



From stefano.stabellini at eu.citrix.com  Wed Apr 24 15:28:10 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Wed, 24 Apr 2013 20:28:10 +0100
Subject: [PATCH v4 2/7] xen/arm: SMP support
In-Reply-To: <alpine.DEB.2.02.1304242012590.4180@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1304242012590.4180@kaball.uk.xensource.com>
Message-ID: <1366831695-13214-2-git-send-email-stefano.stabellini@eu.citrix.com>

Map vcpu_info using VCPUOP_register_vcpu_info on secondary cpus.

Call enable_percpu_irq on every cpu.

Changed in v2:
- move the percpu variable argument fix to a separate patch;
- remove unused variable.

Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
---
 arch/arm/xen/enlighten.c |   38 +++++++++++++++++++++++++++++++++++++-
 1 files changed, 37 insertions(+), 1 deletions(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 99ce189..94bbf3b 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -2,6 +2,7 @@
 #include <xen/events.h>
 #include <xen/grant_table.h>
 #include <xen/hvm.h>
+#include <xen/interface/vcpu.h>
 #include <xen/interface/xen.h>
 #include <xen/interface/memory.h>
 #include <xen/interface/hvm/params.h>
@@ -32,6 +33,7 @@ struct shared_info xen_dummy_shared_info;
 struct shared_info *HYPERVISOR_shared_info = (void *)&xen_dummy_shared_info;
 
 DEFINE_PER_CPU(struct vcpu_info *, xen_vcpu);
+DEFINE_PER_CPU(struct vcpu_info, xen_vcpu_info);
 
 /* These are unused until we support booting "pre-ballooned" */
 unsigned long xen_released_pages;
@@ -148,6 +150,32 @@ int xen_unmap_domain_mfn_range(struct vm_area_struct *vma,
 }
 EXPORT_SYMBOL_GPL(xen_unmap_domain_mfn_range);
 
+static int __init xen_secondary_init(unsigned int cpu)
+{
+	struct vcpu_register_vcpu_info info;
+	struct vcpu_info *vcpup;
+	int err;
+
+	if (cpu == 0)
+		return 0;
+
+	pr_info("Xen: initializing cpu%d\n", cpu);
+	vcpup = &per_cpu(xen_vcpu_info, cpu);
+
+	info.mfn = __pa(vcpup) >> PAGE_SHIFT;
+	info.offset = offset_in_page(vcpup);
+
+	err = HYPERVISOR_vcpu_op(VCPUOP_register_vcpu_info, cpu, &info);
+	if (err) {
+		pr_debug("register_vcpu_info failed: err=%d\n", err);
+	} else {
+		/* This cpu is using the registered vcpu info, even if
+		   later ones fail to. */
+		per_cpu(xen_vcpu, cpu) = vcpup;
+	}
+	return 0;
+}
+
 /*
  * see Documentation/devicetree/bindings/arm/xen.txt for the
  * documentation of the Xen Device Tree format.
@@ -163,6 +191,7 @@ static int __init xen_guest_init(void)
 	const char *version = NULL;
 	const char *xen_prefix = "xen,xen-";
 	struct resource res;
+	int i;
 
 	node = of_find_compatible_node(NULL, NULL, "xen,xen");
 	if (!node) {
@@ -216,6 +245,8 @@ static int __init xen_guest_init(void)
 	 * is required to use VCPUOP_register_vcpu_info to place vcpu info
 	 * for secondary CPUs as they are brought up. */
 	per_cpu(xen_vcpu, 0) = &HYPERVISOR_shared_info->vcpu_info[0];
+	for_each_online_cpu(i)
+		xen_secondary_init(i);
 
 	gnttab_init();
 	if (!xen_initial_domain())
@@ -231,6 +262,11 @@ static irqreturn_t xen_arm_callback(int irq, void *arg)
 	return IRQ_HANDLED;
 }
 
+static __init void xen_percpu_enable_events(void *unused)
+{
+	enable_percpu_irq(xen_events_irq, 0);
+}
+
 static int __init xen_init_events(void)
 {
 	if (!xen_domain() || xen_events_irq < 0)
@@ -244,7 +280,7 @@ static int __init xen_init_events(void)
 		return -EINVAL;
 	}
 
-	enable_percpu_irq(xen_events_irq, 0);
+	on_each_cpu(xen_percpu_enable_events, NULL, 0);
 
 	return 0;
 }
-- 
1.7.2.5



From tony at atomide.com  Wed Apr 24 15:44:50 2013
From: tony at atomide.com (Tony Lindgren)
Date: Wed, 24 Apr 2013 12:44:50 -0700
Subject: Multiple issues with omap4 panda es in linux next
In-Reply-To: <20130419171318.GK10155@atomide.com>
References: <20130419171318.GK10155@atomide.com>
Message-ID: <20130424194450.GD5184@atomide.com>

* Tony Lindgren <tony at atomide.com> [130419 10:18]:
> 
> 4. WLAN with wl12xx fails with both legacy and DT booting
> 
> No real output here with the legacy mode, just the usual
> using pinctrl dummy state warning.

The WLAN legacy booting issue was caused by me not having
lib80211 module loaded.

Regards,

Tony


From s.hauer at pengutronix.de  Wed Apr 24 15:45:40 2013
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Wed, 24 Apr 2013 21:45:40 +0200
Subject: [PATCH v5 01/10] ASoC: phycore-ac97: Add DT support
In-Reply-To: <1366814199-14827-2-git-send-email-mpa@pengutronix.de>
References: <1366814199-14827-1-git-send-email-mpa@pengutronix.de>
 <1366814199-14827-2-git-send-email-mpa@pengutronix.de>
Message-ID: <20130424194540.GF32299@pengutronix.de>

Hi Markus,

On Wed, Apr 24, 2013 at 04:36:30PM +0200, Markus Pargmann wrote:
> Add devicetree support for this audio soc fabric driver.
> 
> @@ -32,8 +35,12 @@ static struct snd_soc_dai_link imx_phycore_dai_ac97[] = {
>  		.stream_name	= "HiFi",
>  		.codec_dai_name		= "wm9712-hifi",
>  		.codec_name	= "wm9712-codec",
> +#ifdef CONFIG_MACH_IMX27_DT
> +		.platform_name	= "imx-fiq-pcm-audio",
> +#else
>  		.cpu_dai_name	= "imx-ssi.0",
>  		.platform_name	= "imx-fiq-pcm-audio.0",
> +#endif

This doesn't work properly. Compiling the kernel with IMX27_DT enabled
does not necessarily mean that it also started with dt support.

Personally I am fine with removing platform based support for this
driver if it's too much effort to fix it properly, but we shouldn't
start working with ifdefs here.

Sascha


-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From plagnioj at jcrosoft.com  Wed Apr 24 15:58:20 2013
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Wed, 24 Apr 2013 21:58:20 +0200
Subject: [RFC PATCH v3 02/17] Documentation: devicetree: arm: cpus/cpu
 nodes bindings updates
In-Reply-To: <1366824502-19729-3-git-send-email-lorenzo.pieralisi@arm.com>
References: <1366824502-19729-1-git-send-email-lorenzo.pieralisi@arm.com>
 <1366824502-19729-3-git-send-email-lorenzo.pieralisi@arm.com>
Message-ID: <20130424195820.GM4998@game.jcrosoft.org>

On 18:28 Wed 24 Apr     , Lorenzo Pieralisi wrote:
> In order to extend the current cpu nodes bindings to newer CPUs
> inclusive of AArch64 and to update support for older ARM CPUs this
> patch updates device tree documentation for the cpu nodes bindings.
> 
> Main changes:
>     - adds 64-bit bindings
>     - define usage of #address-cells
>     - define 32/64 dts compatibility settings
>     - defines behaviour on pre and post v7 uniprocessor systems
>     - adds ARM 11MPcore specific reg property definition
> 
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
> ---
>  Documentation/devicetree/bindings/arm/cpus.txt | 457 ++++++++++++++++++++++---
>  1 file changed, 410 insertions(+), 47 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt
> index f32494d..00badea 100644
> --- a/Documentation/devicetree/bindings/arm/cpus.txt
> +++ b/Documentation/devicetree/bindings/arm/cpus.txt
> @@ -1,77 +1,440 @@
> -* ARM CPUs binding description
> +=================
> +ARM CPUs bindings
> +=================
>  
>  The device tree allows to describe the layout of CPUs in a system through
>  the "cpus" node, which in turn contains a number of subnodes (ie "cpu")
>  defining properties for every cpu.
>  
> -Bindings for CPU nodes follow the ePAPR standard, available from:
> -
> -http://devicetree.org
> -
> -For the ARM architecture every CPU node must contain the following properties:
> -
> -- device_type:	must be "cpu"
> -- reg:		property matching the CPU MPIDR[23:0] register bits
> -		reg[31:24] bits must be set to 0
> -- compatible:	should be one of:
> -		"arm,arm1020"
> -		"arm,arm1020e"
> -		"arm,arm1022"
> -		"arm,arm1026"
> -		"arm,arm720"
> -		"arm,arm740"
> -		"arm,arm7tdmi"
> -		"arm,arm920"
> -		"arm,arm922"
> -		"arm,arm925"
> -		"arm,arm926"
> -		"arm,arm940"
> -		"arm,arm946"
> -		"arm,arm9tdmi"
> -		"arm,cortex-a5"
> -		"arm,cortex-a7"
> -		"arm,cortex-a8"
> -		"arm,cortex-a9"
> -		"arm,cortex-a15"
> -		"arm,arm1136"
> -		"arm,arm1156"
> -		"arm,arm1176"
> -		"arm,arm11mpcore"
> -		"faraday,fa526"
> -		"intel,sa110"
> -		"intel,sa1100"
> -		"marvell,feroceon"
> -		"marvell,mohawk"
> -		"marvell,xsc3"
> -		"marvell,xscale"
> -
> -Example:
> +Bindings for CPU nodes follow the ePAPR v1.1 standard, available from:
> +
> +https://www.power.org/documentation/epapr-version-1-1/
> +
> +with updates for 32-bit and 64-bit ARM systems provided in this document.
> +
> +================================
> +Convention used in this document
> +================================
> +
> +This document follows the conventions described in the ePAPR v1.1, with
> +the addition:
> +
> +- square brackets define bitfields, eg reg[7:0] value of the bitfield in
> +  the reg property contained in bits 7 down to 0
> +
> +=====================================
> +cpus and cpu node bindings definition
> +=====================================
> +
> +The ARM architecture, in accordance with the ePAPR, requires the cpus and cpu
> +nodes to be present and contain the properties described below.
> +
> +- cpus node
> +
> +	Description: Container of cpu nodes
> +
> +	The node name must be "cpus".
> +
> +	A cpus node must define the following properties:
> +
> +	- #address-cells
> +		Usage: required
> +		Value type: <u32>
> +
> +		Definition depends on ARM architecture version and
> +		configuration:
> +
> +			# On uniprocessor ARM architectures previous to v7
> +			  value must be 0.
> +			# On 32-bit ARM 11 MPcore, ARM v7 or later systems
> +			  value must be 1.
> +			# On ARM v8 64-bit systems value must be set to 1
> +			  or 2. Refer to the cpu node's reg property
> +			  description for allowed configurations.
> +
> +	- #size-cells
> +		Usage: required
> +		Value type: <u32>
> +		Definition: must be set to 0
> +
> +- cpu node
> +
> +	Description: Describes a CPU in an ARM based system
> +
> +	PROPERTIES
> +
> +	- device_type
> +		Usage: required
> +		Value type: <string>
> +		Definition: must be "cpu"
> +	- reg
> +		Usage and definition depend on ARM architecture version and
> +		configuration:
> +
> +			# On uniprocessor ARM architectures previous to v7
> +			  this property is optional since they do not define
> +			  any register that provides a CPU identifier.
> +			  Any value set in the reg property for these CPUs
> +			  should be ignored.
> +
> +			# On ARM 11 MPcore based systems this property is
> +			  required and matches the CPUID[11:0] register bits.
> +
> +			  Bits [11:0] in the reg cell must be set to
> +			  bits [11:0] in CPU ID register.
> +
> +			  All other bits in the reg cell must be set to 0.
> +
> +			# On 32-bit ARM v7 or later systems this property is
> +			  required and matches the CPU MPIDR[23:0] register
> +			  bits.
> +
> +			  Bits [23:0] in the reg cell must be set to
> +			  bits [23:0] in MPIDR.
> +
> +			  All other bits in the reg cell must be set to 0.
> +
> +			# On ARM v8 64-bit systems, where the reg property
> +			  size can be 1 or 2 cells (as defined by cpus node's
> +			  #address-cells property), this property is
> +			  required and matches:
> +
> +			  - On systems running the OS in AArch32:
> +
> +			    * If the cpus node's #address-cells value is 2:
> +
> +			      The first reg cell must be set to 0.
> +
> +			      The second reg cell bits [23:0] must be set to
> +			      bits [23:0] of MPIDR_EL1.
> +
> +			      All other bits in the reg cells must be set to 0.
> +
> +			    * If the cpus node's #address-cells value is 1:
> +
> +			      Bits [23:0] in the reg cell must be set to
> +			      bits [23:0] in MPIDR_EL1.
> +
> +			      All other bits in the reg cell must be 0.
> +
> +			  - On systems running the OS in AArch64:
> +
> +			    * If the cpus node's #address-cells value is 2:
> +
> +			      The first reg cell bits [7:0] must be set to
> +			      bits [39:32] of MPIDR_EL1.
> +
> +			      The second reg cell bits [23:0] must be set to
> +			      bits [23:0] of MPIDR_EL1.
> +
> +			      All other bits in the reg cells must be set to 0.
> +
> +			    * If the cpus node's #address-cells value is 1:
> +
> +			      MPIDR_EL1[63:32] is 0 on all processors in the
> +			      system.
> +
> +			      The reg cell bits [23:0] must be set to
> +			      bits [23:0] of MPIDR_EL1.
> +
> +			      All other bits in the reg cell must be set to 0.
> +
> +	- compatible:
> +		Usage: required
> +		Value type: <string>
> +		Definition: should be one of:
> +			    "arm,arm710t"
> +			    "arm,arm720t"
> +			    "arm,arm740t"
> +			    "arm,arm7ej-s"
> +			    "arm,arm7tdmi"
> +			    "arm,arm7tdmi-s"
> +			    "arm,arm9es"
> +			    "arm,arm9ej-s"
> +			    "arm,arm920t"
> +			    "arm,arm922t"
> +			    "arm,arm925"
> +			    "arm,arm926e-s"
> +			    "arm,arm926ej-s"
> +			    "arm,arm940t"
> +			    "arm,arm946e-s"
> +			    "arm,arm966e-s"
> +			    "arm,arm968e-s"
> +			    "arm,arm9tdmi"
> +			    "arm,arm1020e"
> +			    "arm,arm1020t"
> +			    "arm,arm1022e"
> +			    "arm,arm1026ej-s"
the common name is arm926ejs / arm1026ejs & co

Best Regards,
J.
> +			    "arm,arm1136j-s"
> +			    "arm,arm1136jf-s"
> +			    "arm,arm1156t2-s"
> +			    "arm,arm1156t2f-s"
> +			    "arm,arm1176jzf"
> +			    "arm,arm1176jz-s"
> +			    "arm,arm1176jzf-s"
> +			    "arm,arm11mpcore"
> +			    "arm,cortex-a5"
> +			    "arm,cortex-a7"
> +			    "arm,cortex-a8"
> +			    "arm,cortex-a9"
> +			    "arm,cortex-a15"
> +			    "arm,cortex-a53"
> +			    "arm,cortex-a57"
> +			    "arm,cortex-m0"
> +			    "arm,cortex-m0+"
> +			    "arm,cortex-m1"
> +			    "arm,cortex-m3"
> +			    "arm,cortex-m4"
> +			    "arm,cortex-r4"
> +			    "arm,cortex-r5"
> +			    "arm,cortex-r7"
> +			    "faraday,fa526"
> +			    "intel,sa110"
> +			    "intel,sa1100"
> +			    "marvell,feroceon"
> +			    "marvell,mohawk"
> +			    "marvell,pj4"
> +			    "marvell,sheeva-v7"
> +			    "marvell,xsc3"
> +			    "marvell,xscale"
> +			    "qcom,krait"
> +			    "qcom,scorpion"
> +	- enable-method
> +		Value type: <stringlist>
> +		Usage and definition depend on ARM architecture version and
> +		configuration:
> +			# On ARM v8 64-bit systems running the OS in AArch64,
> +			  this property is required and must be "spin-table".
> +			# On ARM 32-bit systems or ARM v8 systems running
> +			  the OS in AArch32 this property is prohibited.
> +
> +	- cpu-release-addr
> +		Usage: required for systems that have an "enable-method"
> +		       property value of "spin-table".
> +		Value type: <prop-encoded-array>
> +		Definition:
> +			# On ARM v8 64-bit systems must be a two cell
> +			  property identifying a 64-bit zero-initialised
> +			  memory location.
> +
> +Example 1 (dual-cluster big.LITTLE system 32-bit):
>  
>  	cpus {
>  		#size-cells = <0>;
>  		#address-cells = <1>;
>  
> -		CPU0: cpu at 0 {
> +		cpu at 0 {
>  			device_type = "cpu";
>  			compatible = "arm,cortex-a15";
>  			reg = <0x0>;
>  		};
>  
> -		CPU1: cpu at 1 {
> +		cpu at 1 {
>  			device_type = "cpu";
>  			compatible = "arm,cortex-a15";
>  			reg = <0x1>;
>  		};
>  
> -		CPU2: cpu at 100 {
> +		cpu at 100 {
>  			device_type = "cpu";
>  			compatible = "arm,cortex-a7";
>  			reg = <0x100>;
>  		};
>  
> -		CPU3: cpu at 101 {
> +		cpu at 101 {
>  			device_type = "cpu";
>  			compatible = "arm,cortex-a7";
>  			reg = <0x101>;
>  		};
>  	};
> +
> +Example 2 (Cortex-A8 uniprocessor 32-bit system):
> +
> +	cpus {
> +		#size-cells = <0>;
> +		#address-cells = <1>;
> +
> +		cpu at 0 {
> +			device_type = "cpu";
> +			compatible = "arm,cortex-a8";
> +			reg = <0x0>;
> +		};
> +	};
> +
> +Example 3 (ARM 926EJ-S uniprocessor 32-bit system):
> +
> +	cpus {
> +		#size-cells = <0>;
> +		#address-cells = <0>;
> +
> +		cpu {
> +			device_type = "cpu";
> +			compatible = "arm,arm926ej-s";
> +		};
> +	};
> +
> +Example 4 (ARM Cortex-A57 64-bit system running OS in AArch64):
> +
> +cpus {
> +	#size-cells = <0>;
> +	#address-cells = <2>;
> +
> +	cpu at 0 {
> +		device_type = "cpu";
> +		compatible = "arm,cortex-a57";
> +		reg = <0x0 0x0>;
> +		enable-method = "spin-table";
> +		cpu-release-addr = <0 0x20000000>;
> +	};
> +
> +	cpu at 1 {
> +		device_type = "cpu";
> +		compatible = "arm,cortex-a57";
> +		reg = <0x0 0x1>;
> +		enable-method = "spin-table";
> +		cpu-release-addr = <0 0x20000000>;
> +	};
> +
> +	cpu at 100 {
> +		device_type = "cpu";
> +		compatible = "arm,cortex-a57";
> +		reg = <0x0 0x100>;
> +		enable-method = "spin-table";
> +		cpu-release-addr = <0 0x20000000>;
> +	};
> +
> +	cpu at 101 {
> +		device_type = "cpu";
> +		compatible = "arm,cortex-a57";
> +		reg = <0x0 0x101>;
> +		enable-method = "spin-table";
> +		cpu-release-addr = <0 0x20000000>;
> +	};
> +
> +	cpu at 10000 {
> +		device_type = "cpu";
> +		compatible = "arm,cortex-a57";
> +		reg = <0x0 0x10000>;
> +		enable-method = "spin-table";
> +		cpu-release-addr = <0 0x20000000>;
> +	};
> +
> +	cpu at 10001 {
> +		device_type = "cpu";
> +		compatible = "arm,cortex-a57";
> +		reg = <0x0 0x10001>;
> +		enable-method = "spin-table";
> +		cpu-release-addr = <0 0x20000000>;
> +	};
> +
> +	cpu at 10100 {
> +		device_type = "cpu";
> +		compatible = "arm,cortex-a57";
> +		reg = <0x0 0x10100>;
> +		enable-method = "spin-table";
> +		cpu-release-addr = <0 0x20000000>;
> +	};
> +
> +	cpu at 10101 {
> +		device_type = "cpu";
> +		compatible = "arm,cortex-a57";
> +		reg = <0x0 0x10101>;
> +		enable-method = "spin-table";
> +		cpu-release-addr = <0 0x20000000>;
> +	};
> +
> +	cpu at 100000000 {
> +		device_type = "cpu";
> +		compatible = "arm,cortex-a57";
> +		reg = <0x1 0x0>;
> +		enable-method = "spin-table";
> +		cpu-release-addr = <0 0x20000000>;
> +	};
> +
> +	cpu at 100000001 {
> +		device_type = "cpu";
> +		compatible = "arm,cortex-a57";
> +		reg = <0x1 0x1>;
> +		enable-method = "spin-table";
> +		cpu-release-addr = <0 0x20000000>;
> +	};
> +
> +	cpu at 100000100 {
> +		device_type = "cpu";
> +		compatible = "arm,cortex-a57";
> +		reg = <0x1 0x100>;
> +		enable-method = "spin-table";
> +		cpu-release-addr = <0 0x20000000>;
> +	};
> +
> +	cpu at 100000101 {
> +		device_type = "cpu";
> +		compatible = "arm,cortex-a57";
> +		reg = <0x1 0x101>;
> +		enable-method = "spin-table";
> +		cpu-release-addr = <0 0x20000000>;
> +	};
> +
> +	cpu at 100010000 {
> +		device_type = "cpu";
> +		compatible = "arm,cortex-a57";
> +		reg = <0x1 0x10000>;
> +		enable-method = "spin-table";
> +		cpu-release-addr = <0 0x20000000>;
> +	};
> +
> +	cpu at 100010001 {
> +		device_type = "cpu";
> +		compatible = "arm,cortex-a57";
> +		reg = <0x1 0x10001>;
> +		enable-method = "spin-table";
> +		cpu-release-addr = <0 0x20000000>;
> +	};
> +
> +	cpu at 100010100 {
> +		device_type = "cpu";
> +		compatible = "arm,cortex-a57";
> +		reg = <0x1 0x10100>;
> +		enable-method = "spin-table";
> +		cpu-release-addr = <0 0x20000000>;
> +	};
> +
> +	cpu at 100010101 {
> +		device_type = "cpu";
> +		compatible = "arm,cortex-a57";
> +		reg = <0x1 0x10101>;
> +		enable-method = "spin-table";
> +		cpu-release-addr = <0 0x20000000>;
> +	};
> +};
> +
> +Example 5 (ARM Cortex-A57 64-bit system running OS in AArch32):
> +
> +cpus {
> +	#size-cells = <0>;
> +	#address-cells = <2>;
> +
> +	cpu at 0 {
> +		device_type = "cpu";
> +		compatible = "arm,cortex-a57";
> +		reg = <0x0 0x0>;
> +	};
> +
> +	cpu at 1 {
> +		device_type = "cpu";
> +		compatible = "arm,cortex-a57";
> +		reg = <0x0 0x1>;
> +	};
> +
> +	cpu at 100 {
> +		device_type = "cpu";
> +		compatible = "arm,cortex-a57";
> +		reg = <0x0 0x100>;
> +	};
> +
> +	cpu at 101 {
> +		device_type = "cpu";
> +		compatible = "arm,cortex-a57";
> +		reg = <0x0 0x101>;
> +	};
> +};
> -- 
> 1.7.12
> 
> 


From linux at arm.linux.org.uk  Wed Apr 24 16:25:26 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Wed, 24 Apr 2013 21:25:26 +0100
Subject: [PATCH v4 00/15] multi-cluster power management
In-Reply-To: <alpine.LFD.2.03.1304232327120.17375@syhkavp.arg>
References: <1360041732-17936-1-git-send-email-nicolas.pitre@linaro.org>
 <20130423200429.GF5316@n2100.arm.linux.org.uk>
 <alpine.LFD.2.03.1304231657150.17375@syhkavp.arg>
 <20130423214610.GY14496@n2100.arm.linux.org.uk>
 <alpine.LFD.2.03.1304231755370.17375@syhkavp.arg>
 <20130423224441.GZ14496@n2100.arm.linux.org.uk>
 <alpine.LFD.2.03.1304232327120.17375@syhkavp.arg>
Message-ID: <20130424202526.GB14496@n2100.arm.linux.org.uk>

On Wed, Apr 24, 2013 at 12:11:26AM -0400, Nicolas Pitre wrote:
> The latest MCPM patches are available here:
> 
>   git://git.linaro.org/people/nico/linux mcpm
> 
> Diffstat:
> 
>  Documentation/arm/cluster-pm-race-avoidance.txt | 498 ++++++++++++++++++
>  Documentation/arm/vlocks.txt                    | 211 ++++++++
>  arch/arm/Kconfig                                |   8 +
>  arch/arm/common/Makefile                        |   1 +
>  arch/arm/common/mcpm_entry.c                    | 263 +++++++++
>  arch/arm/common/mcpm_head.S                     | 219 ++++++++
>  arch/arm/common/mcpm_platsmp.c                  |  92 ++++
>  arch/arm/common/vlock.S                         | 108 ++++
>  arch/arm/common/vlock.h                         |  29 +
>  arch/arm/include/asm/cacheflush.h               |  75 +++
>  arch/arm/include/asm/mcpm.h                     | 209 ++++++++
>  arch/arm/kernel/asm-offsets.c                   |   4 +
>  12 files changed, 1717 insertions(+)
> 
> The corresponding DCSCB support for RTSM is here:
> 
>   git://git.linaro.org/people/nico/linux mcpm+dcscb
> 
> although that part is probably more suitable for ARM-SOC.
> 
> Do you want those patches to be posted again, or should I send a new 
> pull request?

I've been doing some further digging in these patches this evening, via
https://git.linaro.org/gitweb?p=people/nico/linux.git;a=shortlog;h=refs/heads/mcpm

I think they're now in pretty good shape and are ready to be pulled.


From arno at natisbad.org  Wed Apr 24 16:28:47 2013
From: arno at natisbad.org (Arnaud Ebalard)
Date: Wed, 24 Apr 2013 22:28:47 +0200
Subject: [PATCHv1 1/3] hwmon: Add support for GMT G762/G763 PWM fan
 controller
In-Reply-To: <20130424133856.GA18851@roeck-us.net> (Guenter Roeck's message of
 "Wed, 24 Apr 2013 06:38:56 -0700")
References: <cover.1366753420.git.arno@natisbad.org>
 <63961d39aee9db94767f28fd441312bec2029473.1366753420.git.arno@natisbad.org>
 <20130424053758.GC8710@lunn.ch> <87obd4wb4e.fsf@natisbad.org>
 <20130424133856.GA18851@roeck-us.net>
Message-ID: <87li878ygw.fsf@natisbad.org>

Hi,

Guenter Roeck <linux at roeck-us.net> writes:

>> > You could consider using regmap for holding this cache.
>> >
>> > http://elceurope2012.sched.org/event/100619b669ce5767341624253aa03659?iframe=no&w=900&sidebar=yes&bg=no#.UXdspHLQ5jM
>> >
>> > http://elinux.org/ELCE_Europe_2012_Presentations
>> 
>> Interesting. As I am not yet familiar w/ regmap I would prefer having
>> the driver accepted during merge window with current data structure and
>> then convert it to regmap. But I will take a look (e.g. will study
>> fca1dd03 for instance). Thanks for the pointers. 
>> 
> I have not had time for a detailed review, but adding regmap support
> will not be a requirement.
>
> Note that it is too late for 3.10, so the driver will have to wait for
> 3.11.

Well, I think I can live with it; The only bad thing is that it kills my
excuses not to spend time on regmap ;-)


>> >> +/*
>> >> + * Helpers to import hardware characteristics from .dts file and overload
>> >> + * default config values.
>> >> + */
>> >> +
>> >> +#ifdef CONFIG_OF
>> >
>> > Can the driver be used without device tree? Would it be simpler to
>> >  just add depends OF in the Kconfig entry?
>> 
>> It can be used if the default params (or those configured by u-boot I
>> guess) fit your needs. I think it would be fairly easy to extend the
>> driver later to expose g762_config struct to allow parameters to be set
>> w/o using OF. If someone wants to do that, I think it is better to not
>> depend on OF in Kconfig at the moment but I have not strong argument
>> other that that one. I'll let you decide.
>> 
> Agreed. As long as there are major platforms not supporting device tree,
> and as long as device tree overlays are not supported, it must not be made
> mandatory. Especially for I2C and SPI devices I reserve the right to be able
> test the hardware on an X86 system and not require a reboot to do so.

Understood. Following Simon's post, I think it's useful to implement
some init function for non DT-enabled platforms. 

a+


From arno at natisbad.org  Wed Apr 24 16:33:24 2013
From: arno at natisbad.org (Arnaud Ebalard)
Date: Wed, 24 Apr 2013 22:33:24 +0200
Subject: [PATCHv1 2/3] hwmon: Add documentation for g762 driver
In-Reply-To: <20130424173216.GA1073@roeck-us.net> (Guenter Roeck's message of
 "Wed, 24 Apr 2013 10:32:16 -0700")
References: <cover.1366753420.git.arno@natisbad.org>
 <24acd174f829d211f5d4c1b8631ffc3f8dd97910.1366753420.git.arno@natisbad.org>
 <20130424173216.GA1073@roeck-us.net>
Message-ID: <87haiv8y97.fsf@natisbad.org>

Hi,

Guenter Roeck <linux at roeck-us.net> writes:

> On Wed, Apr 24, 2013 at 12:06:08AM +0200, Arnaud Ebalard wrote:
>> 
>> Signed-off-by: Arnaud Ebalard <arno at natisbad.org>
>> ---
>>  Documentation/hwmon/g762 |   67 ++++++++++++++++++++++++++++++++++++++++++++++
>>  1 file changed, 67 insertions(+)
>>  create mode 100644 Documentation/hwmon/g762
>> 
>> diff --git a/Documentation/hwmon/g762 b/Documentation/hwmon/g762
>> new file mode 100644
>> index 0000000..5015829
>> --- /dev/null
>> +++ b/Documentation/hwmon/g762
>> @@ -0,0 +1,67 @@
>> +Kernel driver g762
>> +==================
>> +
>> +This documentation is based on G760a one, GMT G762 datasheet available
>
> G760a ? If this refers to Documentation/hwmon/g760a, I think it is just
> confusing.
>
>> +at http://natisbad.org/NAS/ref/GMT_EDS-762_763-080710-0.2.pdf (used
>> +for the development of the driver) and sysfs bindings described in
>
> I would hope that you used the data sheet for the driver ;), but that
> information does not add much if any value here. I would suggest
> to drop it. Just point to the data sheet.
>
>> +  fan1_gear_mode: fan gear mode. Supported values are 0, 1 and 2. Default
>> +            value is 0. The value is a characteristic of the system
>> +            and a higher value can be set for more precisely control
>> +            fans with a high rotation speed. Note that this affects the
>> +            measurable speed range, not the read value.
>> +
> This attribute no longer exists.

All thoses will be fixed in v2.

a+


From laurent.pinchart at ideasonboard.com  Wed Apr 24 17:02:15 2013
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Wed, 24 Apr 2013 23:02:15 +0200
Subject: [PATCH 0/6] Davinci fbdev driver and enable it for DMx platform
In-Reply-To: <1366804808-22720-1-git-send-email-prabhakar.csengg@gmail.com>
References: <1366804808-22720-1-git-send-email-prabhakar.csengg@gmail.com>
Message-ID: <1780031.B4OAypccep@avalon>

Hi Prabhakar,

Thank you for the patch.

On Wednesday 24 April 2013 17:30:02 Prabhakar Lad wrote:
> From: Lad, Prabhakar <prabhakar.csengg at gmail.com>
> 
> This patch series adds an fbdev driver for Texas
> Instruments Davinci SoC.The display subsystem consists
> of OSD and VENC, with OSD supporting 2 RGb planes and
> 2 video planes.
> http://focus.ti.com/general/docs/lit/
> getliterature.tsp?literatureNumber=sprue37d&fileType=pdf
> 
> A good amount of the OSD and VENC enabling code is
> present in the kernel, and this patch series adds the
> fbdev interface.
> 
> The fbdev driver exports 4 nodes representing each
> plane to the user - from fb0 to fb3.

The obvious question is: why not a KMS driver instead ? :-)

> Lad, Prabhakar (6):
>   media: davinci: vpbe: fix checkpatch warning for CamelCase
>   media: davinci: vpbe: enable vpbe for fbdev addition
>   davinci: vpbe: add fbdev driver
>   ARM: davinci: dm355: enable fbdev driver
>   ARM: davinci: dm365: enable fbdev driver
>   ARM: davinci: dm644x: enable fbdev driver
> 
>  arch/arm/mach-davinci/dm355.c                 |   24 +-
>  arch/arm/mach-davinci/dm365.c                 |   10 +
>  arch/arm/mach-davinci/dm644x.c                |   10 +
>  drivers/media/platform/davinci/vpbe_display.c |    8 +-
>  drivers/media/platform/davinci/vpbe_osd.c     |  820 ++++++++-
>  drivers/media/platform/davinci/vpbe_venc.c    |   43 +
>  drivers/video/Kconfig                         |   12 +
>  drivers/video/Makefile                        |    1 +
>  drivers/video/davincifb.c                     | 2523 ++++++++++++++++++++++
>  drivers/video/davincifb.h                     |  194 ++
>  include/media/davinci/vpbe_osd.h              |   66 +-
>  include/media/davinci/vpbe_venc.h             |   21 +
>  12 files changed, 3702 insertions(+), 30 deletions(-)
>  create mode 100644 drivers/video/davincifb.c
>  create mode 100644 drivers/video/davincifb.h

-- 
Regards,

Laurent Pinchart



From lauraa at codeaurora.org  Wed Apr 24 17:35:32 2013
From: lauraa at codeaurora.org (Laura Abbott)
Date: Wed, 24 Apr 2013 14:35:32 -0700
Subject: RFC: Unified DMA allocation algorithms
Message-ID: <51785024.40305@codeaurora.org>

Hi all,

I've been looking at a better way to do custom dma allocation algorithms 
in a similar style to Ion heaps. Most drivers/clients have come up with 
a series of semi-standard ways to get memory (CMA, memblock_reserve, 
discontiguous pages etc.) . As these allocation schemes get more and 
more complex, there needs to be a since place where all clients (Ion 
based driver vs. DRM driver vs. ???)  can independently take advantage 
of any optimizations and call a single API for the backing allocations.

The dma_map_ops take care of almost everything needed for abstraction
but the question is where should new allocation algorithms be located?
Most of the work has been added to either arm/mm/dma-mapping.c or
dma-contiguous.c . My current thought:

1) split out the dma_map_ops currently in dma-mapping.c into separate 
files (dma-mapping-common.c, dma-mapping-iommu.c)
2) Extend dma-contiguous.c to support memblock_reserve memory
3) Place additional algorithms in either arch/arm/mm or 
drivers/base/dma-alloc/ as appropriate to the code. This is the part 
where I'm most unsure about the direction.

I don't have anything written yet but I plan to draft some patches 
assuming the proposed approach sounds reasonable and no one else has 
started on something similar already.

Thoughts? Opinions?

Thanks,
Laura

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation


From syin at broadcom.com  Wed Apr 24 18:03:30 2013
From: syin at broadcom.com (Sherman Yin)
Date: Wed, 24 Apr 2013 15:03:30 -0700
Subject: [PATCH] ARM: Adds pin config API to set all configs in one
 function
Message-ID: <1366841010-2823-1-git-send-email-syin@broadcom.com>

Currently, when setting pin configuration in the pinctrl framework,
pin_config_set() or pin_config_group_set() is called in a loop to set one
configuration at a time for the specified pin or group.

pin_config_set_all() and pin_config_group_set_all() are defined to set all
configurations for the specified pin or group at the same time.  These optional
APIs allow pinctrl drivers to optimize and combine pin configurations to reduce
the number of register writes required to configure a pin.

If both pin_config_set() and pin_config_set_all() are defined by a driver, the
latter takes precedence.  Similarly for pin_config_group_set_all().

Signed-off-by: Sherman Yin <syin at broadcom.com>
---
 drivers/pinctrl/pinconf.c       |   74 ++++++++++++++++++++++++++-------------
 include/linux/pinctrl/pinconf.h |   11 ++++--
 2 files changed, 59 insertions(+), 26 deletions(-)

diff --git a/drivers/pinctrl/pinconf.c b/drivers/pinctrl/pinconf.c
index d611ecf..568e4f2 100644
--- a/drivers/pinctrl/pinconf.c
+++ b/drivers/pinctrl/pinconf.c
@@ -34,7 +34,8 @@ int pinconf_check_ops(struct pinctrl_dev *pctldev)
 		return -EINVAL;
 	}
 	/* We have to be able to config the pins in SOME way */
-	if (!ops->pin_config_set && !ops->pin_config_group_set) {
+	if (!ops->pin_config_set && !ops->pin_config_group_set &&
+		!ops->pin_config_set_all && !ops->pin_config_group_set_all) {
 		dev_err(pctldev->dev,
 			"pinconf has to be able to set a pins config\n");
 		return -EINVAL;
@@ -338,40 +339,65 @@ int pinconf_apply_setting(struct pinctrl_setting const *setting)
 
 	switch (setting->type) {
 	case PIN_MAP_TYPE_CONFIGS_PIN:
-		if (!ops->pin_config_set) {
-			dev_err(pctldev->dev, "missing pin_config_set op\n");
-			return -EINVAL;
-		}
-		for (i = 0; i < setting->data.configs.num_configs; i++) {
-			ret = ops->pin_config_set(pctldev,
-					setting->data.configs.group_or_pin,
-					setting->data.configs.configs[i]);
+		if (ops->pin_config_set_all) {
+			ret = ops->pin_config_set_all(pctldev,
+				&setting->data.configs);
 			if (ret < 0) {
 				dev_err(pctldev->dev,
-					"pin_config_set op failed for pin %d config %08lx\n",
-					setting->data.configs.group_or_pin,
-					setting->data.configs.configs[i]);
+					"pin_config_set_all op failed for pin %d\n",
+					setting->data.configs.group_or_pin);
 				return ret;
 			}
-		}
-		break;
-	case PIN_MAP_TYPE_CONFIGS_GROUP:
-		if (!ops->pin_config_group_set) {
+		} else if (ops->pin_config_set) {
+			for (i = 0; i < setting->data.configs.num_configs; i++) {
+				ret = ops->pin_config_set(pctldev,
+						setting->data.configs.group_or_pin,
+						setting->data.configs.configs[i]);
+				if (ret < 0) {
+					dev_err(pctldev->dev,
+						"pin_config_set op failed for "
+						"pin %d config %08lx\n",
+						setting->data.configs.group_or_pin,
+						setting->data.configs.configs[i]);
+					return ret;
+				}
+			}
+		} else {
 			dev_err(pctldev->dev,
-				"missing pin_config_group_set op\n");
+				"missing pin_config_set or "
+				"pin_config_set_all op\n");
 			return -EINVAL;
 		}
-		for (i = 0; i < setting->data.configs.num_configs; i++) {
-			ret = ops->pin_config_group_set(pctldev,
-					setting->data.configs.group_or_pin,
-					setting->data.configs.configs[i]);
+		break;
+	case PIN_MAP_TYPE_CONFIGS_GROUP:
+		if (ops->pin_config_group_set_all) {
+			ret = ops->pin_config_group_set_all(pctldev,
+					&setting->data.configs);
 			if (ret < 0) {
 				dev_err(pctldev->dev,
-					"pin_config_group_set op failed for group %d config %08lx\n",
-					setting->data.configs.group_or_pin,
-					setting->data.configs.configs[i]);
+					"pin_config_group_set_all op failed for group %d\n",
+					setting->data.configs.group_or_pin);
 				return ret;
 			}
+		} else if (ops->pin_config_group_set) {
+			for (i = 0; i < setting->data.configs.num_configs; i++) {
+				ret = ops->pin_config_group_set(pctldev,
+						setting->data.configs.group_or_pin,
+						setting->data.configs.configs[i]);
+				if (ret < 0) {
+					dev_err(pctldev->dev,
+						"pin_config_group_set op failed "
+						"for group %d config %08lx\n",
+						setting->data.configs.group_or_pin,
+						setting->data.configs.configs[i]);
+					return ret;
+				}
+			}
+		} else {
+			dev_err(pctldev->dev,
+				"missing pin_config_group_set or "
+				"pin_config_group_set_all op\n");
+			return -EINVAL;
 		}
 		break;
 	default:
diff --git a/include/linux/pinctrl/pinconf.h b/include/linux/pinctrl/pinconf.h
index e7a7201..b838756 100644
--- a/include/linux/pinctrl/pinconf.h
+++ b/include/linux/pinctrl/pinconf.h
@@ -16,6 +16,7 @@
 
 struct pinctrl_dev;
 struct seq_file;
+struct pinctrl_setting_configs;
 
 /**
  * struct pinconf_ops - pin config operations, to be implemented by
@@ -25,9 +26,11 @@ struct seq_file;
  * @pin_config_get: get the config of a certain pin, if the requested config
  *	is not available on this controller this should return -ENOTSUPP
  *	and if it is available but disabled it should return -EINVAL
- * @pin_config_set: configure an individual pin
+ * @pin_config_set: apply one configuration to an individual pin
+ * @pin_config_set_all: apply all configurations to an individual pin
  * @pin_config_group_get: get configurations for an entire pin group
- * @pin_config_group_set: configure all pins in a group
+ * @pin_config_group_set: apply one configuration to all pins in a group
+ * @pin_config_group_set_all: apply all configurations to all pins in a group
  * @pin_config_dbg_show: optional debugfs display hook that will provide
  *	per-device info for a certain pin in debugfs
  * @pin_config_group_dbg_show: optional debugfs display hook that will provide
@@ -45,12 +48,16 @@ struct pinconf_ops {
 	int (*pin_config_set) (struct pinctrl_dev *pctldev,
 			       unsigned pin,
 			       unsigned long config);
+	int (*pin_config_set_all) (struct pinctrl_dev *pctldev,
+				   const struct pinctrl_setting_configs *configs);
 	int (*pin_config_group_get) (struct pinctrl_dev *pctldev,
 				     unsigned selector,
 				     unsigned long *config);
 	int (*pin_config_group_set) (struct pinctrl_dev *pctldev,
 				     unsigned selector,
 				     unsigned long config);
+	int (*pin_config_group_set_all) (struct pinctrl_dev *pctldev,
+					 const struct pinctrl_setting_configs *configs);
 	void (*pin_config_dbg_show) (struct pinctrl_dev *pctldev,
 				     struct seq_file *s,
 				     unsigned offset);
-- 
1.7.9.5




From stefano.stabellini at eu.citrix.com  Wed Apr 24 18:14:28 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Wed, 24 Apr 2013 23:14:28 +0100
Subject: [PATCH v4 7/7] mach-virt: support Xen hypercalls for shutdown
 and reboot
In-Reply-To: <1366831695-13214-7-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1304242012590.4180@kaball.uk.xensource.com>
 <1366831695-13214-7-git-send-email-stefano.stabellini@eu.citrix.com>
Message-ID: <alpine.DEB.2.02.1304242301390.4180@kaball.uk.xensource.com>

On Wed, 24 Apr 2013, Stefano Stabellini wrote:
> Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
> CC: Marc Zyngier <marc.zyngier at arm.com>
> CC: will.deacon at arm.com
> CC: arnd at arndb.de
> CC: rob.herring at calxeda.com

Thinking twice about this patch, a less intrusive alternative would be
to set arm_pm_restart and pm_power_off to two xen specific functions
later on from xen_guest_init.

>  arch/arm/mach-virt/virt.c |   32 ++++++++++++++++++++++++++++++++
>  1 files changed, 32 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/mach-virt/virt.c b/arch/arm/mach-virt/virt.c
> index 528c05e..ba14321 100644
> --- a/arch/arm/mach-virt/virt.c
> +++ b/arch/arm/mach-virt/virt.c
> @@ -23,13 +23,44 @@
>  #include <linux/of_platform.h>
>  #include <linux/smp.h>
>  
> +#include <xen/xen.h>
> +#include <xen/interface/sched.h>
> +
>  #include <asm/arch_timer.h>
>  #include <asm/mach/arch.h>
>  #include <asm/mach/time.h>
> +#include <asm/xen/hypercall.h>
> +
> +static void virt_restart(char str, const char *cmd)
> +{
> +#ifdef CONFIG_XEN
> +	if (xen_domain()) {
> +		struct sched_shutdown r = { .reason = SHUTDOWN_reboot };
> +		int rc;
> +		rc = HYPERVISOR_sched_op(SCHEDOP_shutdown, &r);
> +		if (rc)
> +			BUG();
> +	}
> +#endif
> +}
> +
> +static void virt_power_off(void)
> +{
> +#ifdef CONFIG_XEN
> +	if (xen_domain()) {
> +		struct sched_shutdown r = { .reason = SHUTDOWN_poweroff };
> +		int rc;
> +		rc = HYPERVISOR_sched_op(SCHEDOP_shutdown, &r);
> +		if (rc)
> +			BUG();
> +	}
> +#endif
> +}
>  
>  static void __init virt_init(void)
>  {
>  	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
> +	pm_power_off = virt_power_off;
>  }
>  
>  static void __init virt_timer_init(void)
> @@ -52,4 +83,5 @@ DT_MACHINE_START(VIRT, "Dummy Virtual Machine")
>  	.init_machine	= virt_init,
>  	.smp		= smp_ops(virt_smp_ops),
>  	.dt_compat	= virt_dt_match,
> +	.restart	= virt_restart,
>  MACHINE_END
> -- 
> 1.7.2.5
> 


From akpm at linux-foundation.org  Wed Apr 24 18:33:23 2013
From: akpm at linux-foundation.org (Andrew Morton)
Date: Wed, 24 Apr 2013 15:33:23 -0700
Subject: [PATCH V2 1/3] seccomp: add generic code for jitted seccomp
 filters.
In-Reply-To: <5177FFC2.5020102@freebox.fr>
References: <1363618233-6375-1-git-send-email-nschichan@freebox.fr>
 <1363618233-6375-2-git-send-email-nschichan@freebox.fr>
 <20130417145628.88058f0f3104ab9ae551ddd3@linux-foundation.org>
 <51752D98.8070709@freebox.fr>
 <20130423164303.d2eb663c4a1becea4a185087@linux-foundation.org>
 <5177FFC2.5020102@freebox.fr>
Message-ID: <20130424153323.73901c8e026580dc279329b0@linux-foundation.org>

On Wed, 24 Apr 2013 17:52:34 +0200 Nicolas Schichan <nschichan at freebox.fr> wrote:

> > btw, what on earth is going on with seccomp_jit_free()?  It does
> > disturbing undocumented typecasting and it punts the module_free into a
> > kernel thread for mysterious, undocumented and possibly buggy reasons.
> >
> > I realize it just copies bpf_jit_free().  The same observations apply there.
> 
> The reason for this hack for both seccomp filters and socket filters is that 
> {seccomp,bpf}_jit_free are called from a softirq. module_free() cannot be 
> called directly from softirq, as it will in turn call vfree() which will 
> BUG_ON() if in_interrupt() is non zero. So to call module_free(), it is 
> therefore required to be in a process context, which is provided by the work 
> struct.

Well let's explain this to the next sucker who comes along.

From: Andrew Morton <akpm at linux-foundation.org>
Subject: bpf: add comments explaining the schedule_work() operation

Cc: Will Drewry <wad at chromium.org>
Cc: Mircea Gherzan <mgherzan at gmail.com>
Cc: Nicolas Schichan <nschichan at freebox.fr>
Cc: Russell King <linux at arm.linux.org.uk>
Cc: "David S. Miller" <davem at davemloft.net>
Cc: Daniel Borkmann <daniel.borkmann at tik.ee.ethz.ch>
Signed-off-by: Andrew Morton <akpm at linux-foundation.org>
---

 arch/arm/net/bpf_jit_32.c       |    8 ++++++++
 arch/powerpc/net/bpf_jit_comp.c |    4 ++++
 arch/s390/net/bpf_jit_comp.c    |    4 ++++
 arch/sparc/net/bpf_jit_comp.c   |    4 ++++
 arch/x86/net/bpf_jit_comp.c     |    4 ++++
 5 files changed, 24 insertions(+)

diff -puN arch/arm/net/bpf_jit_32.c~a arch/arm/net/bpf_jit_32.c
--- a/arch/arm/net/bpf_jit_32.c~a
+++ a/arch/arm/net/bpf_jit_32.c
@@ -958,6 +958,10 @@ void bpf_jit_free(struct sk_filter *fp)
 	struct work_struct *work;
 
 	if (fp->bpf_func != sk_run_filter) {
+		/*
+		 * bpf_jit_free() can be called from softirq; module_free()
+		 * requires process context.
+		 */
 		work = (struct work_struct *)fp->bpf_func;
 
 		INIT_WORK(work, bpf_jit_free_worker);
@@ -985,6 +989,10 @@ void seccomp_jit_free(struct seccomp_fil
 	void *bpf_func = seccomp_filter_get_bpf_func(fp);
 
 	if (bpf_func != sk_run_filter) {
+		/*
+		 * seccomp_jit_free() can be called from softirq; module_free()
+		 * requires process context.
+		 */
 		work = (struct work_struct *)bpf_func;
 
 		INIT_WORK(work, bpf_jit_free_worker);
diff -puN arch/sparc/net/bpf_jit_comp.c~a arch/sparc/net/bpf_jit_comp.c
--- a/arch/sparc/net/bpf_jit_comp.c~a
+++ a/arch/sparc/net/bpf_jit_comp.c
@@ -817,6 +817,10 @@ static void jit_free_defer(struct work_s
 void bpf_jit_free(struct sk_filter *fp)
 {
 	if (fp->bpf_func != sk_run_filter) {
+		/*
+		 * bpf_jit_free() can be called from softirq; module_free()
+		 * requires process context.
+		 */
 		struct work_struct *work = (struct work_struct *)fp->bpf_func;
 
 		INIT_WORK(work, jit_free_defer);
diff -puN arch/powerpc/net/bpf_jit_comp.c~a arch/powerpc/net/bpf_jit_comp.c
--- a/arch/powerpc/net/bpf_jit_comp.c~a
+++ a/arch/powerpc/net/bpf_jit_comp.c
@@ -699,6 +699,10 @@ static void jit_free_defer(struct work_s
 void bpf_jit_free(struct sk_filter *fp)
 {
 	if (fp->bpf_func != sk_run_filter) {
+		/*
+		 * bpf_jit_free() can be called from softirq; module_free()
+		 * requires process context.
+		 */
 		struct work_struct *work = (struct work_struct *)fp->bpf_func;
 
 		INIT_WORK(work, jit_free_defer);
diff -puN arch/s390/net/bpf_jit_comp.c~a arch/s390/net/bpf_jit_comp.c
--- a/arch/s390/net/bpf_jit_comp.c~a
+++ a/arch/s390/net/bpf_jit_comp.c
@@ -818,6 +818,10 @@ void bpf_jit_free(struct sk_filter *fp)
 
 	if (fp->bpf_func == sk_run_filter)
 		return;
+	/*
+	 * bpf_jit_free() can be called from softirq; module_free() requires
+	 * process context.
+	 */
 	work = (struct work_struct *)fp->bpf_func;
 	INIT_WORK(work, jit_free_defer);
 	schedule_work(work);
diff -puN arch/x86/net/bpf_jit_comp.c~a arch/x86/net/bpf_jit_comp.c
--- a/arch/x86/net/bpf_jit_comp.c~a
+++ a/arch/x86/net/bpf_jit_comp.c
@@ -749,6 +749,10 @@ static void jit_free_defer(struct work_s
 void bpf_jit_free(struct sk_filter *fp)
 {
 	if (fp->bpf_func != sk_run_filter) {
+		/*
+		 * bpf_jit_free() can be called from softirq; module_free()
+		 * requires process context.
+		 */
 		struct work_struct *work = (struct work_struct *)fp->bpf_func;
 
 		INIT_WORK(work, jit_free_defer);
diff -puN include/linux/filter.h~a include/linux/filter.h
diff -puN net/core/filter.c~a net/core/filter.c
_



From linux at prisktech.co.nz  Wed Apr 24 18:39:28 2013
From: linux at prisktech.co.nz (Tony Prisk)
Date: Thu, 25 Apr 2013 10:39:28 +1200
Subject: [PATCH 0/3] dts: v8500: Cleanups for 3.10
In-Reply-To: <1366781902-13025-1-git-send-email-linux@prisktech.co.nz>
References: <1366781902-13025-1-git-send-email-linux@prisktech.co.nz>
Message-ID: <51785F20.704@prisktech.co.nz>

On 24/04/13 17:38, Tony Prisk wrote:
> Arnd, Olof,
>
> This is probably a bit late for 3.10 now but its just a bunch of cleanups for
> the arch-vt8500 devicetree SoC and board files, and the addition of a new
> dts for the VIA APC8750.
>
> Regards
> Tony P
>
> Tony Prisk (3):
>    dts: vt8500: Fix invalid/missing cpu nodes for soc files.
>    dts: vt8500: Add devicetree support for WM8750 SoC and APC8750 board
>    dts: vt8500: Update serial nodes and disable by default in SoC files
>
>   arch/arm/boot/dts/Makefile           |    1 +
>   arch/arm/boot/dts/vt8500-bv07.dts    |    4 +
>   arch/arm/boot/dts/vt8500.dtsi        |   29 ++-
>   arch/arm/boot/dts/wm8505-ref.dts     |    4 +
>   arch/arm/boot/dts/wm8505.dtsi        |   35 +++-
>   arch/arm/boot/dts/wm8650-mid.dts     |    4 +
>   arch/arm/boot/dts/wm8650.dtsi        |   21 +-
>   arch/arm/boot/dts/wm8750-apc8750.dts |   30 +++
>   arch/arm/boot/dts/wm8750.dtsi        |  355 ++++++++++++++++++++++++++++++++++
>   arch/arm/boot/dts/wm8850-w70v2.dts   |    4 +
>   arch/arm/boot/dts/wm8850.dtsi        |   23 ++-
>   11 files changed, 492 insertions(+), 18 deletions(-)
>   create mode 100644 arch/arm/boot/dts/wm8750-apc8750.dts
>   create mode 100644 arch/arm/boot/dts/wm8750.dtsi
>
Don't worry about this patch series - it looks like we are going back to 
926ejs (rather than changing to 926) so I will send out another request 
after the merge window.

Regards
Tony P


From dinguyen at altera.com  Wed Apr 24 18:44:42 2013
From: dinguyen at altera.com (Dinh Nguyen)
Date: Wed, 24 Apr 2013 17:44:42 -0500
Subject: dw_apb_timer_of.c: remove parts that were picoxcell-specific
In-Reply-To: <20130423105827.GA6983@amd.pavel.ucw.cz>
References: <20130423105827.GA6983@amd.pavel.ucw.cz>
Message-ID: <1366843482.29992.4.camel@linux-builds1>

Hi Pavel,

On Tue, 2013-04-23 at 12:58 +0200, ZY - pavel wrote:
> It seems we made a mistake when creating dw_apb_timer_of.c:
> picoxcell sched_clock parts were not related to dw_apb_timer, yet
> we moved them to dw_apb_timer_of, and tried to use them on socfpga.
>     
> This results in system where user/system time is not measured properly,
> as demonstrated by
>     
>     time dd if=/dev/urandom of=/dev/zero bs=100000 count=100
>     
>     .
>     
> So this patch:
>     
>     1) moves picoxcell sched_clock parts back to picoxcell
>     
>     2) adds support to use dw_apb_timer s as sched_clock. Picoxcell could
>     consider switching to these
>     
>     3) adds missing of_node_put() in dw_apb_timer_init().
>     
> Tested on socfpga, soc-next (3.9-rc6) based tree.
>     
> Signed-off-by: Pavel Machek <pavel at denx.de>
> 
> diff --git a/arch/arm/mach-picoxcell/common.c b/arch/arm/mach-picoxcell/common.c
> index 70b441a..22759f5 100644
> --- a/arch/arm/mach-picoxcell/common.c
> +++ b/arch/arm/mach-picoxcell/common.c
> @@ -84,11 +84,39 @@ static void picoxcell_wdt_restart(char mode, const char *cmd)
>  	}
>  }
>  
> +static const struct of_device_id picochip_rtc_ids[] __initconst = {
> +        { .compatible = "picochip,pc3x2-rtc" },
> +        { /* Sentinel */ },
> +};
> +
> +static void __iomem *sched_io_base;
> +
> +static u32 read_sched_clock(void)
> +{
> +        return __raw_readl(sched_io_base);
> +}
> +
> +static void __init timer_init(void)
> +{
> +	u32 rate;
> +
> +	dw_apb_timer_init(0);
> +
> +	sched_timer = of_find_matching_node(timer, osctimer_ids);
> +	if (!sched_timer)
> +		panic("No suitable timer for scheduler clock\n");
> +
> +	timer_get_base_and_rate(sched_timer, &sched_io_base, &rate);
> +	of_node_put(sched_timer);
> +
> +	setup_sched_clock(read_sched_clock, 32, rate);
> +}
> +
>  DT_MACHINE_START(PICOXCELL, "Picochip picoXcell")
>  	.map_io		= picoxcell_map_io,
>  	.nr_irqs	= NR_IRQS_LEGACY,
>  	.init_irq	= irqchip_init,
> -	.init_time	= dw_apb_timer_init,
> +	.init_time	= timer_init,
>  	.init_machine	= picoxcell_init_machine,
>  	.dt_compat	= picoxcell_dt_match,
>  	.restart	= picoxcell_wdt_restart,
> diff --git a/arch/arm/mach-socfpga/socfpga.c b/arch/arm/mach-socfpga/socfpga.c
> index 46a0513..3a030e5 100644
> --- a/arch/arm/mach-socfpga/socfpga.c
> +++ b/arch/arm/mach-socfpga/socfpga.c
> @@ -116,11 +116,17 @@ static const char *altera_dt_match[] = {
>  	NULL
>  };
>  
> +static void __init timer_init(void)
> +{
> +	dw_apb_timer_init(1);
> +}
> +
> +
>  DT_MACHINE_START(SOCFPGA, "Altera SOCFPGA")
>  	.smp		= smp_ops(socfpga_smp_ops),
>  	.map_io		= socfpga_map_io,
>  	.init_irq	= socfpga_init_irq,
> -	.init_time	= dw_apb_timer_init,
> +	.init_time	= timer_init,
>  	.init_machine	= socfpga_cyclone5_init,
>  	.restart	= socfpga_cyclone5_restart,
>  	.dt_compat	= altera_dt_match,
> diff --git a/drivers/clocksource/dw_apb_timer.c b/drivers/clocksource/dw_apb_timer.c
> index 8c2a35f..460ac99 100644
> --- a/drivers/clocksource/dw_apb_timer.c
> +++ b/drivers/clocksource/dw_apb_timer.c
> @@ -21,12 +21,6 @@
>  #define APBT_MIN_PERIOD			4
>  #define APBT_MIN_DELTA_USEC		200
>  
> -#define APBTMR_N_LOAD_COUNT		0x00
> -#define APBTMR_N_CURRENT_VALUE		0x04
> -#define APBTMR_N_CONTROL		0x08
> -#define APBTMR_N_EOI			0x0c
> -#define APBTMR_N_INT_STATUS		0x10
> -
>  #define APBTMRS_INT_STATUS		0xa0
>  #define APBTMRS_EOI			0xa4
>  #define APBTMRS_RAW_INT_STATUS		0xa8
> diff --git a/drivers/clocksource/dw_apb_timer_of.c b/drivers/clocksource/dw_apb_timer_of.c
> index ab09ed3..ac4ea00 100644
> --- a/drivers/clocksource/dw_apb_timer_of.c
> +++ b/drivers/clocksource/dw_apb_timer_of.c
> @@ -57,7 +57,16 @@ static void add_clockevent(struct device_node *event_timer)
>  	dw_apb_clockevent_register(ced);
>  }
>  
> -static void add_clocksource(struct device_node *source_timer)
> +static void __iomem *sched_io_base;
> +
> +/* This is actually same as __apbt_read_clocksource(), but with
> +   different interface */
> +static u32 read_sched_clock_sptimer(void)
> +{
> +	return ~__raw_readl(sched_io_base + APBTMR_N_CURRENT_VALUE);
> +}
> +
> +static void add_clocksource(struct device_node *source_timer, int use_as_scheduler)
>  {
>  	void __iomem *iobase;
>  	struct dw_apb_clocksource *cs;
> @@ -71,45 +80,34 @@ static void add_clocksource(struct device_node *source_timer)
>  
>  	dw_apb_clocksource_start(cs);
>  	dw_apb_clocksource_register(cs);
> -}
>  
> -static void __iomem *sched_io_base;
> -
> -static u32 read_sched_clock(void)
> -{
> -	return __raw_readl(sched_io_base);
> +	if (use_as_scheduler) {
> +		sched_io_base = iobase;
> +		setup_sched_clock(read_sched_clock_sptimer, 32, rate);
> +	}
>  }
>  
> -static const struct of_device_id sptimer_ids[] __initconst = {
> -	{ .compatible = "picochip,pc3x2-rtc" },
> +static const struct of_device_id osctimer_ids[] __initconst = {
> +	{ .compatible = "picochip,pc3x2-timer" },
> +	{ .compatible = "snps,dw-apb-timer-osc" },
>  	{ .compatible = "snps,dw-apb-timer-sp" },
> -	{ /* Sentinel */ },
> +	{  /* Sentinel */ },
>  };
>  
> -static void init_sched_clock(void)
> -{
> -	struct device_node *sched_timer;
> -	u32 rate;
> -
> -	sched_timer = of_find_matching_node(NULL, sptimer_ids);
> -	if (!sched_timer)
> -		panic("No RTC for sched clock to use");
> -
> -	timer_get_base_and_rate(sched_timer, &sched_io_base, &rate);
> -	of_node_put(sched_timer);
> +/*
> +   You don't have to use dw_apb_timer for scheduler clock,
> +   this should also work fine on arm:
>  
> -	setup_sched_clock(read_sched_clock, 32, rate);
> -}
> +  twd_local_timer_of_register();
> +  arch_timer_of_register();                 
> +  arch_timer_sched_clock_init();
> +*/
>  
> -static const struct of_device_id osctimer_ids[] __initconst = {
> -	{ .compatible = "picochip,pc3x2-timer" },
> -	{ .compatible = "snps,dw-apb-timer-osc" },
> -	{},
> -};
>  
> -void __init dw_apb_timer_init(void)
> +void __init dw_apb_timer_init(int use_as_scheduler)
>  {
>  	struct device_node *event_timer, *source_timer;
> +	u32 rate;

You're not using rate anywhere in this function.

drivers/clocksource/dw_apb_timer_of.c: In function ?dw_apb_timer_init?:
drivers/clocksource/dw_apb_timer_of.c:110:6: warning: unused variable
?rate?

>  
>  	event_timer = of_find_matching_node(NULL, osctimer_ids);
>  	if (!event_timer)
> @@ -119,9 +117,8 @@ void __init dw_apb_timer_init(void)
>  	source_timer = of_find_matching_node(event_timer, osctimer_ids);
>  	if (!source_timer)
>  		panic("No timer for clocksource");
> -	add_clocksource(source_timer);
> +	add_clocksource(source_timer, use_as_scheduler);
>  
> +	of_node_put(event_timer);
>  	of_node_put(source_timer);
> -
> -	init_sched_clock();
>  }
> diff --git a/include/linux/dw_apb_timer.h b/include/linux/dw_apb_timer.h
> index dd755ce..d503245 100644
> --- a/include/linux/dw_apb_timer.h
> +++ b/include/linux/dw_apb_timer.h
> @@ -17,6 +17,12 @@
>  #include <linux/clocksource.h>
>  #include <linux/interrupt.h>
>  
> +#define APBTMR_N_LOAD_COUNT		0x00
> +#define APBTMR_N_CURRENT_VALUE		0x04
> +#define APBTMR_N_CONTROL		0x08
> +#define APBTMR_N_EOI			0x0c
> +#define APBTMR_N_INT_STATUS		0x10
> +
>  #define APBTMRS_REG_SIZE       0x14
>  
>  struct dw_apb_timer {
> @@ -53,5 +59,5 @@ void dw_apb_clocksource_start(struct dw_apb_clocksource *dw_cs);
>  cycle_t dw_apb_clocksource_read(struct dw_apb_clocksource *dw_cs);
>  void dw_apb_clocksource_unregister(struct dw_apb_clocksource *dw_cs);
>  
> -extern void dw_apb_timer_init(void);
> +extern void dw_apb_timer_init(int);
>  #endif /* __DW_APB_TIMER_H__ */

On SOCFPGA:

Tested-by: Dinh Nguyen <dinguyen at altera.com>
> 





From olof at lixom.net  Wed Apr 24 18:50:53 2013
From: olof at lixom.net (Olof Johansson)
Date: Wed, 24 Apr 2013 15:50:53 -0700
Subject: [PATCH 0/3] dts: v8500: Cleanups for 3.10
In-Reply-To: <51785F20.704@prisktech.co.nz>
References: <1366781902-13025-1-git-send-email-linux@prisktech.co.nz>
 <51785F20.704@prisktech.co.nz>
Message-ID: <CAOesGMgCobyVwA+7rRQ7j4Y9CRuiTwy2PSPjgbasjXj4Z4c5Ew@mail.gmail.com>

On Wed, Apr 24, 2013 at 3:39 PM, Tony Prisk <linux at prisktech.co.nz> wrote:
> On 24/04/13 17:38, Tony Prisk wrote:
>>
>> Arnd, Olof,
>>
>> This is probably a bit late for 3.10 now but its just a bunch of cleanups
>> for
>> the arch-vt8500 devicetree SoC and board files, and the addition of a new
>> dts for the VIA APC8750.
>>
>> Regards
>> Tony P
>>
>> Tony Prisk (3):
>>    dts: vt8500: Fix invalid/missing cpu nodes for soc files.
>>    dts: vt8500: Add devicetree support for WM8750 SoC and APC8750 board
>>    dts: vt8500: Update serial nodes and disable by default in SoC files
>>
>>   arch/arm/boot/dts/Makefile           |    1 +
>>   arch/arm/boot/dts/vt8500-bv07.dts    |    4 +
>>   arch/arm/boot/dts/vt8500.dtsi        |   29 ++-
>>   arch/arm/boot/dts/wm8505-ref.dts     |    4 +
>>   arch/arm/boot/dts/wm8505.dtsi        |   35 +++-
>>   arch/arm/boot/dts/wm8650-mid.dts     |    4 +
>>   arch/arm/boot/dts/wm8650.dtsi        |   21 +-
>>   arch/arm/boot/dts/wm8750-apc8750.dts |   30 +++
>>   arch/arm/boot/dts/wm8750.dtsi        |  355
>> ++++++++++++++++++++++++++++++++++
>>   arch/arm/boot/dts/wm8850-w70v2.dts   |    4 +
>>   arch/arm/boot/dts/wm8850.dtsi        |   23 ++-
>>   11 files changed, 492 insertions(+), 18 deletions(-)
>>   create mode 100644 arch/arm/boot/dts/wm8750-apc8750.dts
>>   create mode 100644 arch/arm/boot/dts/wm8750.dtsi
>>
> Don't worry about this patch series - it looks like we are going back to
> 926ejs (rather than changing to 926) so I will send out another request
> after the merge window.


Ok, it was definitely late for 3.10 anyway. :) We'll merge after -rc1
if you send a fresh request then.


-Olof


From linux at roeck-us.net  Wed Apr 24 18:47:31 2013
From: linux at roeck-us.net (Guenter Roeck)
Date: Wed, 24 Apr 2013 15:47:31 -0700
Subject: [PATCHv1 1/3] hwmon: Add support for GMT G762/G763 PWM fan
 controller
In-Reply-To: <87li878ygw.fsf@natisbad.org>
References: <cover.1366753420.git.arno@natisbad.org>
 <63961d39aee9db94767f28fd441312bec2029473.1366753420.git.arno@natisbad.org>
 <20130424053758.GC8710@lunn.ch> <87obd4wb4e.fsf@natisbad.org>
 <20130424133856.GA18851@roeck-us.net> <87li878ygw.fsf@natisbad.org>
Message-ID: <20130424224731.GB7767@roeck-us.net>

On Wed, Apr 24, 2013 at 10:28:47PM +0200, Arnaud Ebalard wrote:
> Hi,
> 
> Guenter Roeck <linux at roeck-us.net> writes:
> 
> >> > You could consider using regmap for holding this cache.
> >> >
> >> > http://elceurope2012.sched.org/event/100619b669ce5767341624253aa03659?iframe=no&w=900&sidebar=yes&bg=no#.UXdspHLQ5jM
> >> >
> >> > http://elinux.org/ELCE_Europe_2012_Presentations
> >> 
> >> Interesting. As I am not yet familiar w/ regmap I would prefer having
> >> the driver accepted during merge window with current data structure and
> >> then convert it to regmap. But I will take a look (e.g. will study
> >> fca1dd03 for instance). Thanks for the pointers. 
> >> 
> > I have not had time for a detailed review, but adding regmap support
> > will not be a requirement.
> >
> > Note that it is too late for 3.10, so the driver will have to wait for
> > 3.11.
> 
> Well, I think I can live with it; The only bad thing is that it kills my
> excuses not to spend time on regmap ;-)
> 
Your call.

> 
> >> >> +/*
> >> >> + * Helpers to import hardware characteristics from .dts file and overload
> >> >> + * default config values.
> >> >> + */
> >> >> +
> >> >> +#ifdef CONFIG_OF
> >> >
> >> > Can the driver be used without device tree? Would it be simpler to
> >> >  just add depends OF in the Kconfig entry?
> >> 
> >> It can be used if the default params (or those configured by u-boot I
> >> guess) fit your needs. I think it would be fairly easy to extend the
> >> driver later to expose g762_config struct to allow parameters to be set
> >> w/o using OF. If someone wants to do that, I think it is better to not
> >> depend on OF in Kconfig at the moment but I have not strong argument
> >> other that that one. I'll let you decide.
> >> 
> > Agreed. As long as there are major platforms not supporting device tree,
> > and as long as device tree overlays are not supported, it must not be made
> > mandatory. Especially for I2C and SPI devices I reserve the right to be able
> > test the hardware on an X86 system and not require a reboot to do so.
> 
> Understood. Following Simon's post, I think it's useful to implement
> some init function for non DT-enabled platforms. 
> 
Sure, as long as Simon commits to test it and - if possible - to provide
the necessary platform code.

Guenter


From s-anna at ti.com  Wed Apr 24 19:16:49 2013
From: s-anna at ti.com (Suman Anna)
Date: Wed, 24 Apr 2013 18:16:49 -0500
Subject: [PATCHv3 00/14] drivers: mailbox: framework creation
In-Reply-To: <CAJe_ZhdZv5LW6kdwyPtJe69mfW6t=WQ4OJnG2H4sUhibattN2A@mail.gmail.com>
References: <1363145021-14339-1-git-send-email-s-anna@ti.com>
 <CABb+yY0RYkVeo2Sb4WsDJY0jf17488FEz0d2CB994eQaSOEsVg@mail.gmail.com>
 <37C860A02101E749A747FA2D3C1E3C504A5DF7@DLEE11.ent.ti.com>
 <CABb+yY1x4x_A+QtGG9ohsLPgs8c3nEVnd_ExJBGOOR8=6YLPFA@mail.gmail.com>
 <37C860A02101E749A747FA2D3C1E3C504A63B4@DLEE11.ent.ti.com>
 <CAJe_ZhehnniZd730jjiOLrHozq8TOJZgFYLqUe4KqgBiQEu8PA@mail.gmail.com>
 <51779304.4040003@st.com>
 <CAJe_ZhdZv5LW6kdwyPtJe69mfW6t=WQ4OJnG2H4sUhibattN2A@mail.gmail.com>
Message-ID: <517867E1.7050301@ti.com>

Jassi,

On 04/24/2013 03:56 AM, Jassi Brar wrote:
> Hi -
> 
> On 24 April 2013 13:38, Loic PALLARDY <loic.pallardy at st.com> wrote:
>> Hi Jassi,
>>
>> On 04/24/2013 06:39 AM, Jassi Brar wrote:
> 
>>>   The non-atomic API falls flat should just a single client comes with
>>> very low latency requirements.
>>
>> In fact there are different situations for the non/atomic requirements
>> (at least from ST POV)
>> - one mailbox could be non-atomic only (blocking if we reuse notifier
>> wording)
>> - one mailbox could be atomic only
>> - one mailbox could be both depending on the context and usage (example:
>> in the case of ST, one mailbox is used to access the analogue baseband,
>> there is no particular atomic requirement for that except during
>> register dump called form panic context)
>>
>> For the 3rd point I agree with you, it should be considered as atomic
>> and up to driver to schedule a sleepable task...
>>
>> I have an internal implementation in which each mailbox is declared
>> either atomic or blocking.
>> Depending on this parameter, the behavior of the mbox_send_mbox is
>> changed...
>>
> I am only talking about the nature of the API, which I think should as
> fast as possible by providing atomic functions (except
> mailbox_get/put).
> If a controller needs to do sleep-prone tasks, let it schedule those
> from API's atomic callbacks.
> If a client needs to blink leds after receiving/sending a message, let
> it schedule a work for that from API's atomic callback.
> Majority of scenarios will simply be a client populating a structure
> and pass it onto the controller driver which only need to program a
> few registers to put the message on the h/w link.

I think there are two things here - one is what the client needs to do
upon sending/receiving a message, and the other is what the send API or
the mailbox controller should do when a client tried to send a message
and the controller's shared message/transport is not free (irrespective
of the atomic or non-atomic context). The kfifos in the common driver
code are currently solving the latter problem. The current send API
directly uses the controller to send if it is free, and uses buffering
only when it is busy. But, I see your point that this should should be
the responsibility of the specific controller, or even a property of the
specific mailbox belonging to that controller. This direction would put
most of the onus on the specific controller drivers, and probably the
main API would be very simple. Another factor / attribute to consider is
that a given mailbox may be sharable or exclusive, things are simple if
it is exclusive to a client driver.

> 
> 
>>>   Consider this example for better understanding, I must send a
>>> particular packet to the remote before I could, say, shutdown
>>> properly. The client calls mailbox_msg_send which queues the packet
>>> because the h/w was busy. Since the api does not inform the client
>>> about packet transmission, the client does not know when to shutdown
>>> (the packet may have been sent instantly or it may lie on the queue
>>> for a long time).
>>>   How do you fix this without tx_done callback method?
>>>
>> This mechanism was preserved to be compatibility with TI DSP bridge. But
>> my initial proposal was to remove it, simply because today all mailbox
>> customers consider that message is sent or not after calling
>> mbox_send_message function.
>>
> Yeah, I too sense a lot of badness is inherited.

We are talking two fundamentally different usecases/needs here,
depending on the type of the controller. You seem to be coming from a
usecase where the client driver needs to know when every message is
transmitted (from an atomic context, it is a moot point since either you
are successful or not when transmitting). The example problem you
mentioned maybe very relevant to some hardware, but it hadn't been an
issue on OMAP since the mailbox driver is just for sending messages and
not managing the state of the remote. The remote is a processor in OMAP,
and its state machine is controlled by the remoteproc driver. The remote
has to ack before it can be shutdown. I would imagine that getting a
.tx_done on a particular message is not good enough to know that the
remote is ready for shutdown. I can imagine it to be useful where there
is some inherent knowledge that the client needs to proceed with the
next steps when a message is sent. That said, we need to go with the
stricter one.

> 
>>>>
>>>> The size parameter would still be needed. Depending on the h/w, it can be just an u32 or a series of bytes, and even in the latter case, it is not guaranteed that all messages transmitted will occupy the entire h/w shared memory data packet. I can see the current header field getting absorbed into the opaque void * structure for the ST mailbox driver. The size and ptr together provide a very generic message format.
>>>>
>>> I am not sure about it. The API has no purpose for the .size (it's
>>> between the controller and the client driver).
>>> Controllers that could send variable length packets could define the
>>> packets format for clients as
>>>   struct foo_packet {
>>>           int size;
>>>           .......
>>>   }
>>> and exchange as typecasted to void* via the API. And this is just one
>>> way of doing it.
>>> The point being, the API should only pass pointer to packet info
>>> between controller and client drivers.
>> No today the size is used to store the message in the fifo and that's
>> done by the framework.
>> If you decide to remove the fifo mechanism inherit for TI legacy, in
>> that case yes the mailbox framework doesn't matter about message format
>> and size.
>>

Yep, the size field was a direct need from the buffering needs if the
controller were busy. The Tx RTR in fact was used to flush out the
buffered messages.

> Of course I desperately want to get rid of the TI legacy stuff in the
> common api, that will simply not work on many platforms. My 'shutdown'
> example above may be real for some platform.
> 
>>>
>> I'm really happy to see some new mailbox framework clients coming with
>> new requirements to improve the solution.
>> Just for the story, mailbox framework topic was addressed during Linaro
>> Copenhagen Connect and at the time being it was decided to reuse TI
>> solution in a first time and then to improve it...
>>
> At the time my idea of mailbox was simply a tin box with a lock and a slit.
> On a serious note, someone very important pointed out that things
> discussed during events like Linaro shouldn't be taken as the
> consensus of the community. "We" should have put it up for discussion
> on the mailing lists.
> 
>>> Maybe it will help if I know what you guys mean by "shared mem" or an
>>> "hw fifo" mailbox?
>>>
>> Hw fifo means that you what a HW IP which contains x bytes fifo.
>> When you write one byte in the fifo, an interrupt is automatically
>> raised and caught by coprocessor which should read fifo on its side to
>> empty it. In that case, Tx RTR is mandatory.
>> Shared mem, means that mailbox is made up of a cross interrupt + a
>> status register (may be optional) + a shared memory in which messages
>> are exchanged.
>> After writing message in shared mem, CPU has to raise the cross
>> interrupt itself. In case flow control is less important...
>>
> Well, I have a yet another type of controller where the IRQ status
> register provides the data to be exchanged. Anyways I still maintain
> that all three(or any more) controller types need not bother the API
> with the size of message. The size should be a mandatory member of the
> controller specific packet format that will be used by the client to
> exchange data with it.

I think the discussion on size field is mostly semantics, since it would
be very much relevant if the controller's transport payload is more than
the size of a standard type. It is a non-factor for controllers whose
payload size is a standard type (like for OMAP, where the msg size is
u32). Having 32 bytes of payload, for example, almost always means your
controller packet has to have a size field indicating the actual number
of bytes in the message, and it doesn't matter whether the size is a
register or has to exchanged with the remote as part of the transport
packet structure. My only concern here is that if there can be multiple
clients for a particular mailbox/controller, then all the clients would
have to have an agreement on the controller packet type, and the clients
would mostly have to include the standard mailbox.h as well as a
controller-specific header.

Overall, I see it coming down to following points:
1. Calling contexts: Atomic & non-atomic contexts, with the latter
becoming an extension of the atomic case. I guess this mainly goes with
the controller functional integration - whether it is used for
non-urgent messaging or h/w controller command messages (like PM
usecases?) where .tx_done is relevant.
2. Behavior of the API or controller driver if the controller transport
is busy.
3. Shareable/exclusive nature of a mailbox. If it is shareable, then
duplicating the behavior between clients is not worth it, and this
should be absorbed into the respective controller driver.

regards
Suman



From nicolas.pitre at linaro.org  Wed Apr 24 19:31:00 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Wed, 24 Apr 2013 19:31:00 -0400 (EDT)
Subject: [PATCH v4 00/15] multi-cluster power management
In-Reply-To: <20130424202526.GB14496@n2100.arm.linux.org.uk>
References: <1360041732-17936-1-git-send-email-nicolas.pitre@linaro.org>
 <20130423200429.GF5316@n2100.arm.linux.org.uk>
 <alpine.LFD.2.03.1304231657150.17375@syhkavp.arg>
 <20130423214610.GY14496@n2100.arm.linux.org.uk>
 <alpine.LFD.2.03.1304231755370.17375@syhkavp.arg>
 <20130423224441.GZ14496@n2100.arm.linux.org.uk>
 <alpine.LFD.2.03.1304232327120.17375@syhkavp.arg>
 <20130424202526.GB14496@n2100.arm.linux.org.uk>
Message-ID: <alpine.LFD.2.03.1304241927340.1258@syhkavp.arg>

On Wed, 24 Apr 2013, Russell King - ARM Linux wrote:

> On Wed, Apr 24, 2013 at 12:11:26AM -0400, Nicolas Pitre wrote:
> > The latest MCPM patches are available here:
> > 
> >   git://git.linaro.org/people/nico/linux mcpm
> > 
> > Diffstat:
> > 
> >  Documentation/arm/cluster-pm-race-avoidance.txt | 498 ++++++++++++++++++
> >  Documentation/arm/vlocks.txt                    | 211 ++++++++
> >  arch/arm/Kconfig                                |   8 +
> >  arch/arm/common/Makefile                        |   1 +
> >  arch/arm/common/mcpm_entry.c                    | 263 +++++++++
> >  arch/arm/common/mcpm_head.S                     | 219 ++++++++
> >  arch/arm/common/mcpm_platsmp.c                  |  92 ++++
> >  arch/arm/common/vlock.S                         | 108 ++++
> >  arch/arm/common/vlock.h                         |  29 +
> >  arch/arm/include/asm/cacheflush.h               |  75 +++
> >  arch/arm/include/asm/mcpm.h                     | 209 ++++++++
> >  arch/arm/kernel/asm-offsets.c                   |   4 +
> >  12 files changed, 1717 insertions(+)
> > 
> > The corresponding DCSCB support for RTSM is here:
> > 
> >   git://git.linaro.org/people/nico/linux mcpm+dcscb
> > 
> > although that part is probably more suitable for ARM-SOC.
> > 
> > Do you want those patches to be posted again, or should I send a new 
> > pull request?
> 
> I've been doing some further digging in these patches this evening, via
> https://git.linaro.org/gitweb?p=people/nico/linux.git;a=shortlog;h=refs/heads/mcpm
> 
> I think they're now in pretty good shape and are ready to be pulled.

Great!  Please feel free to pull the mcpm branch.  I've nothing to add 
to it.


Nicolas


From olof at lixom.net  Wed Apr 24 19:33:48 2013
From: olof at lixom.net (Olof Johansson)
Date: Wed, 24 Apr 2013 16:33:48 -0700
Subject: [PATCH] ARM: dts: add pinctrl nodes for Exynos5250 SoC
In-Reply-To: <1355403978-388-1-git-send-email-thomas.abraham@linaro.org>
References: <1355403978-388-1-git-send-email-thomas.abraham@linaro.org>
Message-ID: <20130424233348.GA6603@quad.lixom.net>

On Thu, Dec 13, 2012 at 06:36:18PM +0530, Thomas Abraham wrote:
> Add pinctrl device nodes for Exynos5250 SoC.
> 
> Signed-off-by: Thomas Abraham <thomas.abraham at linaro.org>

Replying to an old email of a patch that has been merged because it seems
horribly broken.


> diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi
> index 581e57a..eb8d610 100644
> --- a/arch/arm/boot/dts/exynos5250.dtsi
> +++ b/arch/arm/boot/dts/exynos5250.dtsi
> @@ -18,6 +18,7 @@
>  */
>  
>  /include/ "skeleton.dtsi"
> +/include/ "exynos5250-pinctrl.dtsi"
>  
>  / {
>  	compatible = "samsung,exynos5250";
> @@ -48,6 +49,8 @@
>  		mshc1 = &dwmmc_1;
>  		mshc2 = &dwmmc_2;
>  		mshc3 = &dwmmc_3;
> +		pinctrl0 = &pinctrl_0;
> +		pinctrl3 = &pinctrl_3;
>  	};
>  
>  	gic:interrupt-controller at 10481000 {
> @@ -79,6 +82,24 @@
>  		interrupts = <0 42 0>;
>  	};
>  
> +	pinctrl_0: pinctrl at 11400000 {
> +		compatible = "samsung,pinctrl-exynos5250";
> +		reg = <0x11400000 0x1000>;
> +		interrupts = <0 46 0>;
> +
> +		wakup_eint: wakeup-interrupt-controller {
> +			compatible = "samsung,exynos4210-wakeup-eint";
> +			interrupt-parent = <&gic>;
> +			interrupts = <0 32 0>;
> +		};

Typo, should be "wakeup_eint". And what happened to #interrupt-cells? And the
interrupt map?

Do you have an example of a tested user or a testcase for this? I'm
trying to get interrupts going on these pins, and it's not looking like
it's even close to working.


-Olof


From linux at roeck-us.net  Wed Apr 24 19:37:39 2013
From: linux at roeck-us.net (Guenter Roeck)
Date: Wed, 24 Apr 2013 16:37:39 -0700
Subject: [PATCHv1 1/3] hwmon: Add support for GMT G762/G763 PWM fan
 controller
In-Reply-To: <63961d39aee9db94767f28fd441312bec2029473.1366753420.git.arno@natisbad.org>
References: <cover.1366753420.git.arno@natisbad.org>
 <63961d39aee9db94767f28fd441312bec2029473.1366753420.git.arno@natisbad.org>
Message-ID: <20130424233739.GC7767@roeck-us.net>

On Wed, Apr 24, 2013 at 12:05:56AM +0200, Arnaud Ebalard wrote:
> 
> Signed-off-by: Arnaud Ebalard <arno at natisbad.org>
> Tested-by: Arnaud Ebalard <arno at natisbad.org>

Tested-by is not needed here; I sure hope you tested your own code.
It is only used if someone else tested it.

> ---
>  drivers/hwmon/Kconfig  |   10 +
>  drivers/hwmon/Makefile |    1 +
>  drivers/hwmon/g762.c   | 1058 ++++++++++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 1069 insertions(+)
>  create mode 100644 drivers/hwmon/g762.c
> 
> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
> index 89ac1cb..cb4879c 100644
> --- a/drivers/hwmon/Kconfig
> +++ b/drivers/hwmon/Kconfig
> @@ -423,6 +423,16 @@ config SENSORS_G760A
>  	  This driver can also be built as a module.  If so, the module
>  	  will be called g760a.
>  
> +config SENSORS_G762
> +	tristate "GMT G762 and G763"
> +	depends on I2C
> +	help
> +	  If you say yes here you get support for Global Mixed-mode
> +	  Technology Inc G762 and G763 fan speed PWM controller chips.
> +
> +	  This driver can also be built as a module.  If so, the module
> +	  will be called g762.
> +
>  config SENSORS_GL518SM
>  	tristate "Genesys Logic GL518SM"
>  	depends on I2C
> diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
> index 8d6d97e..4b49504 100644
> --- a/drivers/hwmon/Makefile
> +++ b/drivers/hwmon/Makefile
> @@ -57,6 +57,7 @@ obj-$(CONFIG_SENSORS_F75375S)	+= f75375s.o
>  obj-$(CONFIG_SENSORS_FAM15H_POWER) += fam15h_power.o
>  obj-$(CONFIG_SENSORS_FSCHMD)	+= fschmd.o
>  obj-$(CONFIG_SENSORS_G760A)	+= g760a.o
> +obj-$(CONFIG_SENSORS_G762)	+= g762.o
>  obj-$(CONFIG_SENSORS_GL518SM)	+= gl518sm.o
>  obj-$(CONFIG_SENSORS_GL520SM)	+= gl520sm.o
>  obj-$(CONFIG_SENSORS_GPIO_FAN)	+= gpio-fan.o
> diff --git a/drivers/hwmon/g762.c b/drivers/hwmon/g762.c
> new file mode 100644
> index 0000000..810b019
> --- /dev/null
> +++ b/drivers/hwmon/g762.c
> @@ -0,0 +1,1058 @@
> +/*
> + * g762 - Driver for the Global Mixed-mode Technology Inc. fan speed PWM
> + *        controller chips from G762 family, i.e. G762 and G763
> + *
> + * Copyright (C) 2013, Arnaud EBALARD <arno at natisbad.org>
> + *
> + * This work is based on a basic version for 2.6.31 kernel developed
> + * by Olivier Mouchet for LaCie NAS. Updates have been performed to run
> + * on recent kernels. Additional features have been added. Ability to
> + * configure various characteristics via .dts file has been added.
> + * Detailed datasheet on which this development is based is available
> + * here:
> + *
> + *  http://natisbad.org/NAS/refs/GMT_EDS-762_763-080710-0.2.pdf
> + *
> + * Headers from previous developments have been kept below:
> + *
> + * Copyright (c) 2009 LaCie
> + *
> + * Author: Olivier Mouchet <olivier.mouchet at gmail.com>
> + *
> + * based on g760a code written by Herbert Valerio Riedel <hvr at gnu.org>
> + * Copyright (C) 2007  Herbert Valerio Riedel <hvr at gnu.org>
> + *
> + * g762: minimal datasheet available at:
> + *       http://www.gmt.com.tw/product/datasheet/EDS-762_3.pdf
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA

Please drop the address.

> + */
> +
> +#include <linux/device.h>
> +#include <linux/module.h>
> +#include <linux/init.h>
> +#include <linux/slab.h>

Is this include needed ?

> +#include <linux/jiffies.h>
> +#include <linux/i2c.h>
> +#include <linux/hwmon.h>
> +#include <linux/hwmon-sysfs.h>
> +#include <linux/err.h>
> +#include <linux/mutex.h>
> +#include <linux/kernel.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>
> +
> +#define DRVNAME "g762"
> +
> +static const struct i2c_device_id g762_id[] = {
> +	{ "g762", 0 },
> +	{ "g763", 0 },
> +	{ }
> +};
> +MODULE_DEVICE_TABLE(i2c, g762_id);
> +
> +enum g762_regs {
> +	G762_REG_SET_CNT  = 0x00,
> +	G762_REG_ACT_CNT  = 0x01,
> +	G762_REG_FAN_STA  = 0x02,
> +	G762_REG_SET_OUT  = 0x03,
> +	G762_REG_FAN_CMD1 = 0x04,
> +	G762_REG_FAN_CMD2 = 0x05,
> +};
> +
> +/* Config register bits */
> +#define G762_REG_FAN_CMD1_DET_FAN_FAIL  0x80 /* enable fan_fail signal */
> +#define G762_REG_FAN_CMD1_DET_FAN_OOC   0x40 /* enable fan_out_of_control */
> +#define G762_REG_FAN_CMD1_OUT_MODE      0x20 /* out mode, pwm or dac */
> +#define G762_REG_FAN_CMD1_FAN_MODE      0x10 /* fan mode: close or open loop */
> +#define G762_REG_FAN_CMD1_CLK_DIV_ID1   0x08 /* clock divisor value */
> +#define G762_REG_FAN_CMD1_CLK_DIV_ID0   0x04
> +#define G762_REG_FAN_CMD1_PWM_POLARITY  0x02 /* pwm polarity */
> +#define G762_REG_FAN_CMD1_PULSE_PER_REV 0x01 /* pulse per fan revolution */
> +
> +#define G762_REG_FAN_CMD2_GEAR_MODE_1   0x08 /* fan gear mode */
> +#define G762_REG_FAN_CMD2_GEAR_MODE_0   0x04
> +#define G762_REG_FAN_CMD2_FAN_STARTV_1  0x02 /* fan startup voltage */
> +#define G762_REG_FAN_CMD2_FAN_STARTV_0  0x01
> +
> +#define G762_REG_FAN_STA_FAIL           0x02 /* fan fail */
> +#define G762_REG_FAN_STA_OOC            0x01 /* fan out of control */
> +
> +/* config register values */
> +#define OUT_MODE_PWM            1
> +#define OUT_MODE_DAC            0
> +
> +#define FAN_MODE_CLOSED_LOOP    2
> +#define FAN_MODE_OPEN_LOOP      1
> +
> +/* register data is read (and cached) at most once per second */
> +#define G762_UPDATE_INTERVAL (HZ)

	( ) are not needed here.

> +
> +/*
> + * extract pulse count per fan revolution value (2 or 4) from given
> + * FAN_CMD1 register value
> + */
> +#define PULSE_FROM_REG(reg) \
> +	((((reg) & G762_REG_FAN_CMD1_PULSE_PER_REV)+1) << 1)
> +
> +/*
> + * extract fan clock divisor (1, 2, 4 or 8) from given FAN_CMD1
> + * register value
> + */
> +#define CLKDIV_FROM_REG(reg) \
> +	(1 << (((reg) & (G762_REG_FAN_CMD1_CLK_DIV_ID0 |	\
> +			 G762_REG_FAN_CMD1_CLK_DIV_ID1)) >> 2))
> +
> +/*
> + * extract fan gear mode value (0, 1 or 2) from given FAN_CMD2
> + * register value
> + */
> +#define GEARMODE_FROM_REG(reg) \
> +	(1 << (((reg) & (G762_REG_FAN_CMD2_GEAR_MODE_0 |	\
> +			 G762_REG_FAN_CMD2_GEAR_MODE_1)) >> 2))
> +
> +struct g762_data {
> +	struct i2c_client *client;
> +	struct device *hwmon_dev;
> +
> +	/* update mutex */
> +	struct mutex update_lock;
> +
> +	/* board specific parameters. */
> +	u32 clk; /* default 32kHz */
> +
> +	/* g762 register cache */
> +	bool valid;
> +	unsigned long last_updated; /* in jiffies */
> +
> +	u8 set_cnt;  /* RPM cmd in close loop control */
> +	u8 act_cnt;  /* formula: cnt = (CLK * 30)/(rpm * P) */
> +	u8 fan_sta;  /* bit 0: set when actual fan speed is more than
> +		      *        25% outside requested fan speed
> +		      * bit 1: set when no transition occurs on fan
> +		      *        pin for 0.7s
> +		      */
> +	u8 set_out;  /* output voltage/PWM duty in open loop control */
> +	u8 fan_cmd1; /*   0: FG_PLS_ID0 FG pulses count per revolution
> +		      *      0: 2 counts per revolution
> +		      *      1: 4 counts per revolution
> +		      *   1: PWM_POLARITY 1: negative_duty
> +		      *                   0: positive_duty
> +		      * 2,3: [FG_CLOCK_ID0, FG_CLK_ID1]
> +		      *         00: Divide fan clock by 1
> +		      *         01: Divide fan clock by 2
> +		      *         10: Divide fan clock by 4
> +		      *         11: Divide fan clock by 8
> +		      *   4: FAN_MODE 1:close-loop, 0:open-loop
> +		      *   5: OUT_MODE 1:PWM, 0:DAC
> +		      *   6: DET_FAN_OOC enable "fan ooc" status
> +		      *   7: DET_FAN_FAIL enable "fan fail" status
> +		      */
> +	u8 fan_cmd2; /* 0,1: FAN_STARTV 0,1,2,3 -> 0,32,64,96 dac_code
> +		      * 2,3: FG_GEAR_MODE
> +		      *         00: div = 1
> +		      *         01: div = 2
> +		      *         10: div = 4
> +		      *   4: Mask ALERT# (g763 only)
> +		      */
> +};
> +
> +/*
> + * sysfs PWM interface uses value from 0 to 255 when g762 FAN_SET_CNT register
> + * uses values from 255 (off) to 0 (full speed).
> + */
> +#define PWM_FROM_CNT(cnt)	(0xff-(cnt))
> +#define PWM_TO_CNT(pwm)		(0xff-(pwm))

Please use standard coding style spacing rules for spaces around bianry
operators (ie space before and behind).

> +
> +/*
> + * Convert count value from fan controller register into fan speed RPM value.
> + * Note that the datasheet documents a basic formula. Influence of additional
> + * parameters have been infered from examples in the datasheet and tests:
> + * fan clock divisor, fan gear mode.
> + */
> +static inline unsigned int rpm_from_cnt(u8 cnt, u32 clk, u16 p,
> +					u8 clk_div, u8 gear_mode)
> +{
> +	if (cnt == 0 || cnt == 0xff)
> +		return 0;
> +
> +	return (clk*30*(gear_mode+1))/(cnt*p*clk_div);
> +}
> +
> +/* Convert fan RPM value from sysfs into count value */
> +static inline unsigned char cnt_from_rpm(u32 rpm, u32 clk, u16 p,
> +					 u8 clk_div, u8 gear_mode)
> +{
> +	return (rpm == 0) ? 0xff : (clk*30*(gear_mode+1))/(rpm*p*clk_div);
> +}
> +
> +static inline int g762_read_value(struct i2c_client *client,
> +				  enum g762_regs reg)
> +{
> +	return i2c_smbus_read_byte_data(client, reg);
> +}
> +
> +static inline int g762_write_value(struct i2c_client *client,
> +				   enum g762_regs reg, u8 value)
> +{
> +	return i2c_smbus_write_byte_data(client, reg, value);
> +}

AFAICS the retrun value from g762_write_value is never checked.
Either check it, or make it a void.

[ I would prefer if you would drop the above two functions entirely;
  I don' see the value in having them ]

> +
> +/* helper to grab and cache data, at most one time per second */
> +static struct g762_data *g762_update_client(struct device *dev)
> +{
> +	struct i2c_client *client = to_i2c_client(dev);
> +	struct g762_data *data = i2c_get_clientdata(client);
> +
> +	mutex_lock(&data->update_lock);
> +	if (time_after(jiffies, data->last_updated + G762_UPDATE_INTERVAL) ||
> +	    unlikely(!data->valid)) {
> +		data->set_cnt =  g762_read_value(client, G762_REG_SET_CNT);
> +		data->act_cnt =  g762_read_value(client, G762_REG_ACT_CNT);
> +		data->fan_sta =  g762_read_value(client, G762_REG_FAN_STA);
> +		data->set_out =  g762_read_value(client, G762_REG_SET_OUT);
> +		data->fan_cmd1 = g762_read_value(client, G762_REG_FAN_CMD1);
> +		data->fan_cmd2 = g762_read_value(client, G762_REG_FAN_CMD2);
> +
> +		data->last_updated = jiffies;
> +		data->valid = 1;

			= true;

Sure you don't want to check for errors ?

> +	}
> +	mutex_unlock(&data->update_lock);
> +
> +	return data;
> +}
> +
> +
> +
One empty line is sufficient.

> +/*
> + * helpers for passing hardware characteristics via DT. Some of those
> + * are also used by sysfs handlers (write function) later in the file.
> + */
> +
> +
Same here and elsewhere.

> +/* Set pwm mode. Accepts either 0 (pwm mode) or 1 (linear mode) */
> +static int do_set_pwm_mode(struct device *dev, unsigned long val)
> +{
> +	struct i2c_client *client = to_i2c_client(dev);
> +	struct g762_data *data = g762_update_client(dev);
> +	int ret = 0;
> +
> +	mutex_lock(&data->update_lock);
> +	switch (val) {
> +	case OUT_MODE_PWM:
> +		data->fan_cmd1 |= G762_REG_FAN_CMD1_OUT_MODE;
> +		break;
> +	case OUT_MODE_DAC: /* i.e. linear mode */
> +		data->fan_cmd1 &= ~G762_REG_FAN_CMD1_OUT_MODE;
> +		break;
> +	default:
> +		ret = -EINVAL;
> +		goto out;
> +	}
> +	g762_write_value(client, G762_REG_FAN_CMD1, data->fan_cmd1);
> + out:
> +	mutex_unlock(&data->update_lock);
> +
> +	return ret;
> +}
> +
> +/*
> + * Set reference clock. Accepted values are between 0 and 0xffffff.
> + * Note that this is an internal parameter, i.e. value is not passed
> + * to the device.
> + */
> +static int do_set_pwm_freq(struct device *dev, unsigned long val)
> +{
> +	struct i2c_client *client = to_i2c_client(dev);
> +	struct g762_data *data = i2c_get_clientdata(client);
> +	int ret = -EINVAL;
> +
Seems to me that

	if (val > 0xffffff)
		return -EINVAL;

	data->clk = val;
	return 0;

would be a bit simpler.

> +	if (val <= 0xffffff) {
> +		data->clk = val;
> +		ret = 0;
> +	}
> +
> +	return ret;
> +}
> +
> +/* Set fan clock divisor. Accepted values are 1, 2, 4 and 8. */
> +static int do_set_fan_div(struct device *dev, unsigned long val)
> +{
> +	struct i2c_client *client = to_i2c_client(dev);
> +	struct g762_data *data = g762_update_client(dev);
> +	int ret = 0;
> +
> +	mutex_lock(&data->update_lock);
> +	switch (val) {
> +	case 1:
> +		data->fan_cmd1 &= ~G762_REG_FAN_CMD1_CLK_DIV_ID0;
> +		data->fan_cmd1 &= ~G762_REG_FAN_CMD1_CLK_DIV_ID1;
> +		break;
> +	case 2:
> +		data->fan_cmd1 |=  G762_REG_FAN_CMD1_CLK_DIV_ID0;
> +		data->fan_cmd1 &= ~G762_REG_FAN_CMD1_CLK_DIV_ID1;
> +		break;
> +	case 4:
> +		data->fan_cmd1 &= ~G762_REG_FAN_CMD1_CLK_DIV_ID0;
> +		data->fan_cmd1 |=  G762_REG_FAN_CMD1_CLK_DIV_ID1;
> +		break;
> +	case 8:
> +		data->fan_cmd1 |=  G762_REG_FAN_CMD1_CLK_DIV_ID0;
> +		data->fan_cmd1 |=  G762_REG_FAN_CMD1_CLK_DIV_ID1;
> +		break;
> +	default:
> +		ret = -EINVAL;
> +		goto out;
> +	}
> +	g762_write_value(client, G762_REG_FAN_CMD1, data->fan_cmd1);
> + out:
> +	mutex_unlock(&data->update_lock);
> +
> +	return ret;
> +}
> +
> +/* Set fan gear mode. Accepted values are either 0, 1 or 2. */
> +static int do_set_fan_gear_mode(struct device *dev, unsigned long val)
> +{
> +	struct i2c_client *client = to_i2c_client(dev);
> +	struct g762_data *data = g762_update_client(dev);
> +	int ret = 0;
> +
> +	mutex_lock(&data->update_lock);
> +	switch (val) {
> +	case 0:
> +		data->fan_cmd2 &= ~G762_REG_FAN_CMD2_GEAR_MODE_0;
> +		data->fan_cmd2 &= ~G762_REG_FAN_CMD2_GEAR_MODE_1;
> +		break;
> +	case 1:
> +		data->fan_cmd2 |=  G762_REG_FAN_CMD2_GEAR_MODE_0;
> +		data->fan_cmd2 &= ~G762_REG_FAN_CMD2_GEAR_MODE_1;
> +		break;
> +	case 2:
> +		data->fan_cmd2 &= ~G762_REG_FAN_CMD2_GEAR_MODE_0;
> +		data->fan_cmd2 |=  G762_REG_FAN_CMD2_GEAR_MODE_1;
> +		break;
> +	default:
> +		ret = -EINVAL;
> +		goto out;
> +	}
> +	g762_write_value(client, G762_REG_FAN_CMD2, data->fan_cmd2);
> + out:
> +	mutex_unlock(&data->update_lock);
> +
> +	return ret;
> +}
> +
> +/* Set pulse per revolution value. Accepts either 2 or 4. */
> +static int do_set_fan_pulses(struct device *dev, unsigned long val)
> +{
> +	struct i2c_client *client = to_i2c_client(dev);
> +	struct g762_data *data = g762_update_client(dev);
> +	int ret = 0;
> +
> +	mutex_lock(&data->update_lock);
> +	switch (val) {
> +	case 2:
> +		data->fan_cmd1 &= ~G762_REG_FAN_CMD1_PULSE_PER_REV;
> +		break;
> +	case 4:
> +		data->fan_cmd1 |=  G762_REG_FAN_CMD1_PULSE_PER_REV;
> +		break;
> +	default:
> +		ret = -EINVAL;
> +		goto out;
> +	}
> +	g762_write_value(client, G762_REG_FAN_CMD1, data->fan_cmd1);
> + out:
> +	mutex_unlock(&data->update_lock);
> +
> +	return ret;
> +}
> +
> +/* Set fan mode. Accepts either 1 (open loop) or 2 (closed loop). */
> +static int do_set_pwm_enable(struct device *dev, unsigned long val)
> +{
> +	struct i2c_client *client = to_i2c_client(dev);
> +	struct g762_data *data = g762_update_client(dev);
> +	int ret = 0;
> +
> +	mutex_lock(&data->update_lock);
> +	switch (val) {
> +	case FAN_MODE_OPEN_LOOP:
> +		data->fan_cmd1 &= ~G762_REG_FAN_CMD1_FAN_MODE;
> +		break;
> +	case FAN_MODE_CLOSED_LOOP:
> +		data->fan_cmd1 |=  G762_REG_FAN_CMD1_FAN_MODE;
> +		break;
> +	default:
> +		ret = -EINVAL;
> +		goto out;
> +	}
> +
> +	g762_write_value(client, G762_REG_FAN_CMD1, data->fan_cmd1);
> + out:
> +	mutex_unlock(&data->update_lock);
> +
> +	return ret;
> +}
> +
> +/* Set pwm polarity (0 for negative duty, 1 for positive duty) */
> +static int do_set_pwm_polarity(struct device *dev, unsigned long val)
> +{
> +	struct i2c_client *client = to_i2c_client(dev);
> +	struct g762_data *data = g762_update_client(dev);
> +	int ret = 0;
> +
> +	mutex_lock(&data->update_lock);
> +	switch (val) {
> +	case 0: /* i.e. negative duty */
> +		data->fan_cmd1 &= ~G762_REG_FAN_CMD1_PWM_POLARITY;
> +		break;
> +	case 1: /* i.e. positive duty */
> +		data->fan_cmd1 |=  G762_REG_FAN_CMD1_PWM_POLARITY;
> +		break;
> +	default:
> +		ret = -EINVAL;
> +		goto out;
> +	}
> +	g762_write_value(client, G762_REG_FAN_CMD1, data->fan_cmd1);
> + out:
> +	mutex_unlock(&data->update_lock);
> +
> +	return ret;
> +}
> +
> +/*
> + * Set pwm value. Accepted values are between 0 and 255. Note that the
> + * internal register used for setting the value depends ont the fan
> + * mode of the device.
> + */
> +static int do_set_pwm(struct device *dev, unsigned long val)
> +{
> +	struct i2c_client *client = to_i2c_client(dev);
> +	struct g762_data *data = g762_update_client(dev);
> +	int ret = -EINVAL;
> +
> +	mutex_lock(&data->update_lock);
> +	if (val > 255)
> +		goto out;
> +
> +	if (data->fan_cmd1 & G762_REG_FAN_CMD1_FAN_MODE) { /* closed-loop */
> +		data->set_cnt = PWM_TO_CNT(val);
> +		g762_write_value(client, G762_REG_SET_CNT, (u8)val);
> +	} else {                                           /* open-loop */
> +		data->set_out = val;
> +		g762_write_value(client, G762_REG_SET_OUT, (u8)val);
> +	}
> +
> +	ret = 0;
> + out:
> +	mutex_unlock(&data->update_lock);
> +
> +	return ret;
> +}
> +
> +/* Set fan RPM value. This only makes sense in closed-loop mode. */
> +static int do_set_fan_target(struct device *dev, unsigned long val)
> +{
> +	struct i2c_client *client = to_i2c_client(dev);
> +	struct g762_data *data = g762_update_client(dev);
> +	int ret = -EINVAL;
> +
> +	mutex_lock(&data->update_lock);
> +	if (data->fan_cmd1 & G762_REG_FAN_CMD1_FAN_MODE) { /* closed-loop */
> +		data->set_cnt = cnt_from_rpm(val, data->clk,
> +					     PULSE_FROM_REG(data->fan_cmd1),
> +					     CLKDIV_FROM_REG(data->fan_cmd1),
> +					     GEARMODE_FROM_REG(data->fan_cmd2));
> +		g762_write_value(client, G762_REG_SET_CNT, data->set_cnt);
> +		ret = 0;
> +	}
That implies that you have to set the mode first, which is undesirable context.
One may want to set the target speed first, then set the mode.

> +	mutex_unlock(&data->update_lock);
> +
> +	return ret;
> +}
> +
> +/* Enable/disable fan failure detection. Accepted values are 1 and 0. */
> +static int do_fan_failure_detection_toggle(struct device *dev,
> +					   unsigned long enable)
> +{
> +	struct i2c_client *client = to_i2c_client(dev);
> +	struct g762_data *data = g762_update_client(dev);
> +	int ret = 0;
> +
> +	mutex_lock(&data->update_lock);
> +	switch (enable) {
> +	case 0:
> +		data->fan_cmd1 &= ~G762_REG_FAN_CMD1_DET_FAN_FAIL;
> +		break;
> +	case 1:
> +		data->fan_cmd1 |=  G762_REG_FAN_CMD1_DET_FAN_FAIL;
> +		break;
> +	default:
> +		ret = -EINVAL;
> +		goto out;
> +	}
> +	g762_write_value(client, G762_REG_FAN_CMD1, data->fan_cmd1);
> + out:
> +	mutex_unlock(&data->update_lock);
> +
> +	return ret;
> +}
> +
> +/* Enable/disable fan out of control detection. Accepted values are 1 and 0 */
> +static int do_fan_ooc_detection_toggle(struct device *dev, unsigned int enable)
> +{
> +	struct i2c_client *client = to_i2c_client(dev);
> +	struct g762_data *data = g762_update_client(dev);
> +	int ret = 0;
> +
> +	mutex_lock(&data->update_lock);
> +	switch (enable) {
> +	case 0:
> +		data->fan_cmd1 &= ~G762_REG_FAN_CMD1_DET_FAN_OOC;
> +		break;
> +	case 1:
> +		data->fan_cmd1 |=  G762_REG_FAN_CMD1_DET_FAN_OOC;
> +		break;
> +	default:
> +		ret = -EINVAL;
> +		goto out;
> +	}
> +	g762_write_value(client, G762_REG_FAN_CMD1, data->fan_cmd1);
> + out:
> +	mutex_unlock(&data->update_lock);
> +
> +	return ret;
> +}
> +
> +/* Set startup voltage. Accepted values are either 0, 1, 2 or 3. */
> +static int do_set_fan_startv(struct device *dev, unsigned long val)
> +{
> +	struct i2c_client *client = to_i2c_client(dev);
> +	struct g762_data *data = g762_update_client(dev);
> +	int ret = 0;
> +
> +	mutex_lock(&data->update_lock);
> +	switch (val) {
> +	case 0:
> +		data->fan_cmd2 &= ~G762_REG_FAN_CMD2_FAN_STARTV_0;
> +		data->fan_cmd2 &= ~G762_REG_FAN_CMD2_FAN_STARTV_1;
> +		break;
> +	case 1:
> +		data->fan_cmd2 |=  G762_REG_FAN_CMD2_FAN_STARTV_0;
> +		data->fan_cmd2 &= ~G762_REG_FAN_CMD2_FAN_STARTV_1;
> +		break;
> +	case 2:
> +		data->fan_cmd2 &= ~G762_REG_FAN_CMD2_FAN_STARTV_0;
> +		data->fan_cmd2 |=  G762_REG_FAN_CMD2_FAN_STARTV_1;
> +		break;
> +	case 3:
> +		data->fan_cmd2 |=  G762_REG_FAN_CMD2_FAN_STARTV_0;
> +		data->fan_cmd2 |=  G762_REG_FAN_CMD2_FAN_STARTV_1;
> +		break;
> +	default:
> +		ret = -EINVAL;
> +		goto out;
> +	}
> +	g762_write_value(client, G762_REG_FAN_CMD2, data->fan_cmd2);
> + out:
> +	mutex_unlock(&data->update_lock);
> +
> +	return ret;
> +}
> +
> +
> +
> +/*
> + * Configuration-related definitions
> + */
> +
> +struct g762_config {
> +	u32 fan_startv;
> +	u32 fan_gear_mode;
> +	u32 fan_div;
> +	u32 fan_pulses;
> +	u32 fan_target;
> +	u32 pwm_polarity;
> +	u32 pwm_enable;
> +	u32 pwm_freq;
> +	u32 pwm_mode;
> +};
> +
> +/*
> + * g762 default values: it is assumed that the fan is set for a 32KHz clock
> + * source, a fan clock divisor of 1 and two pulses per revolution. Default
> + * fan driving mode is linear mode (g762/g763 also support PWM mode). Note
> + * the specific init value for properties which may be left unmodified.
> + */
> +#define G762_DEFAULT_CLK            32768
> +#define G762_DEFAULT_FAN_DIV        1
> +#define G762_DEFAULT_FAN_PULSES     2
> +#define G762_DEFAULT_OUT_MODE       0
> +#define G762_DEFAULT_FAN_MODE       2
> +#define G762_DEFAULT_FAN_STARTV     1
> +#define G762_DEFAULT_FAN_GEAR_MODE  0
> +#define G762_DEFAULT_FAN_POLARITY   0
> +#define G762_UNTOUCHED_VAL          0xffffffff
> +
> +static void g762_config_init(struct g762_config *conf)
> +{
> +	conf->pwm_enable = G762_DEFAULT_FAN_MODE;
> +	conf->pwm_mode = G762_DEFAULT_OUT_MODE;
> +	conf->pwm_freq = G762_DEFAULT_CLK;
> +	conf->pwm_polarity = G762_DEFAULT_FAN_POLARITY;
> +	conf->fan_pulses = G762_DEFAULT_FAN_PULSES;
> +	conf->fan_div = G762_DEFAULT_FAN_DIV;
> +	conf->fan_startv = G762_DEFAULT_FAN_STARTV;
> +	conf->fan_gear_mode = G762_DEFAULT_FAN_GEAR_MODE;
> +	conf->fan_target = G762_UNTOUCHED_VAL;
> +}
> +
> +static inline int g762_one_prop_commit(struct i2c_client *client,
> +				       u32 pval, const char *pname,
> +				       int (*psetter)(struct device *dev,
> +						      unsigned long val))
> +{
> +	int ret = 0;
> +
> +	if ((pval != G762_UNTOUCHED_VAL) && (*psetter)(&client->dev, pval)) {
> +		dev_info(&client->dev, "unable to set %s (%d)\n", pname, pval);

info for an error ?

> +		ret = -EINVAL;
> +	}
> +
> +	return ret;
> +}
> +
> +static int g762_config_commit(struct i2c_client *client,
> +			      struct g762_config *conf)
> +{
> +	int ret = 0;
> +
> +	if (g762_one_prop_commit(client, conf->pwm_mode,
> +				 "pwm_mode", &do_set_pwm_mode) ||
> +	    g762_one_prop_commit(client, conf->pwm_enable,
> +				 "pwm_enable", &do_set_pwm_enable) ||
> +	    g762_one_prop_commit(client, conf->fan_div,
> +				 "fan_div", &do_set_fan_div) ||
> +	    g762_one_prop_commit(client, conf->fan_pulses,
> +				 "fan_pulses", &do_set_fan_pulses) ||
> +	    g762_one_prop_commit(client, conf->pwm_freq,
> +				 "pwm_freq", &do_set_pwm_freq) ||
> +	    g762_one_prop_commit(client, conf->fan_gear_mode,
> +				 "fan_gear_mode", &do_set_fan_gear_mode) ||
> +	    g762_one_prop_commit(client, conf->pwm_polarity,
> +				 "pwm_polarity", &do_set_pwm_polarity) ||
> +	    g762_one_prop_commit(client, conf->fan_startv,
> +				 "fan_startv", &do_set_fan_startv) ||
> +	    g762_one_prop_commit(client, conf->fan_target,
> +				 "fan_target", &do_set_fan_target)) {

& in front of function pointers is not needed.

You'll need to set ->valid to false if you call g762_update_client(),
as the changed configuration will affect readings.

> +		ret = -EINVAL;
> +	}
> +
> +	return ret;
> +}
> +
> +
> +/*
> + * Helpers to import hardware characteristics from .dts file and overload
> + * default config values.
> + */
> +
> +#ifdef CONFIG_OF
> +static struct of_device_id g762_dt_match[] = {
> +	{ .compatible = "gmt,g762" },
> +	{ .compatible = "gmt,g763" },
> +	{ },
> +};
> +
> +static inline void g762_of_import_one_prop(struct i2c_client *client,
> +					   u32 *dest, const char *pname)
> +{
> +	const __be32 *prop;
> +	int len;
> +
> +	prop = of_get_property(client->dev.of_node, pname, &len);
> +	if (prop && len == sizeof(u32)) {
> +		*dest = be32_to_cpu(prop[0]);
> +		dev_info(&client->dev, "found %s (%d)\n", pname, *dest);

Please, no. We don't want to clog the log that much. Make it dev_dbg if you
think you really need it, or drop the message entirely.

> +	}
> +}
> +
> +static void g762_config_of_overload(struct i2c_client *client,
> +				    struct g762_config *conf)
> +{
> +	if (!client->dev.of_node)
> +		return;
> +
> +	g762_of_import_one_prop(client, &conf->fan_gear_mode, "fan_gear_mode");
> +	g762_of_import_one_prop(client, &conf->pwm_polarity, "pwm_polarity");
> +	g762_of_import_one_prop(client, &conf->fan_startv, "fan_startv");
> +	g762_of_import_one_prop(client, &conf->pwm_freq, "pwm_freq");
> +	g762_of_import_one_prop(client, &conf->fan_div, "fan_div");
> +	g762_of_import_one_prop(client, &conf->fan_pulses, "fan_pulses");
> +	g762_of_import_one_prop(client, &conf->pwm_mode, "pwm_mode");
> +	g762_of_import_one_prop(client, &conf->fan_target, "fan_target");
> +	g762_of_import_one_prop(client, &conf->pwm_enable, "pwm_enable");
> +}
> +#else
> +static void g762_config_of_overload(struct i2c_client *client,
> +				    struct g762_config *conf) { };

	; after } not needed

> +#endif
> +
> +
> +
> +/*
> + * sysfs attributes
> + */
> +
> +
> +/*
> + * Read function for fan1_input sysfs file. Return current fan RPM value, or
> + * 0 if fan is out of control
> + */
> +static ssize_t get_fan_rpm(struct device *dev, struct device_attribute *da,
> +			   char *buf)
> +{
> +	struct g762_data *data = g762_update_client(dev);
> +	unsigned int rpm = 0;
> +
> +	mutex_lock(&data->update_lock);
> +	/* reverse logic: fan out of control reporting is enabled low */
> +	if (data->fan_sta & G762_REG_FAN_STA_OOC) {
> +		rpm = rpm_from_cnt(data->act_cnt, data->clk,
> +				   PULSE_FROM_REG(data->fan_cmd1),
> +				   CLKDIV_FROM_REG(data->fan_cmd1),
> +				   GEARMODE_FROM_REG(data->fan_cmd2));
> +	}
> +	mutex_unlock(&data->update_lock);
> +
> +	return sprintf(buf, "%u\n", rpm);
> +}
> +
> +
> +/*
> + * Read and write functions for pwm1_mode sysfs file. Get and set fan speed
> + * control mode i.e. pwm (1) or linear (0).
> + */
I assume you mean "DC mode" ?

> +static ssize_t get_pwm_mode(struct device *dev, struct device_attribute *da,
> +			    char *buf)
> +{
> +	struct g762_data *data = g762_update_client(dev);
> +	int pwm_mode;
> +
> +	pwm_mode = (data->fan_cmd1 & G762_REG_FAN_CMD1_OUT_MODE) ? 1 : 0;
> +
> +	return sprintf(buf, "%d\n", pwm_mode);

	return sprintf(buf, "%d\n",
			!!(data->fan_cmd1 & G762_REG_FAN_CMD1_OUT_MODE));

> +}
> +
> +static ssize_t set_pwm_mode(struct device *dev, struct device_attribute *da,
> +			    const char *buf, size_t count)
> +{
> +	unsigned long val;
> +
> +	if (kstrtoul(buf, 10, &val) || do_set_pwm_mode(dev, val))
> +		return -EINVAL;
> +
> +	return count;
> +}
> +
> +
> +/*
> + * Read and write functions for fan1_div sysfs file. Get and set fan
> + * controller prescaler value
> + */
> +static ssize_t get_fan_div(struct device *dev,
> +			       struct device_attribute *da, char *buf)
> +{
> +	struct g762_data *data = g762_update_client(dev);
> +
> +	return sprintf(buf, "%d\n", CLKDIV_FROM_REG(data->fan_cmd1));
> +}
> +
> +static ssize_t set_fan_div(struct device *dev,
> +			       struct device_attribute *da,
> +			       const char *buf, size_t count)
> +{
> +	unsigned long val;
> +
> +	if (kstrtoul(buf, 10, &val) || do_set_fan_div(dev, val))
> +		return -EINVAL;
> +
> +	return count;
> +}
> +
> +
> +/*
> + * Following documentation about hwmon's sysfs interface, a pwm1_enable node
> + * should accept followings:
> + *
> + *  0 : no fan speed control (i.e. fan at full speed)
> + *  1 : manual fan speed control enabled (use pwm[1-*]) (open-loop)
> + *  2+: automatic fan speed control enabled (use fan[1-*]_enable)(close-loop)
> + *
> + * but we do not accept 0 as "no-control" mode is not supported by g762,
> + * -EINVAL is returned in this case.

Sure is - you can set the fan to full speed and ignore subsequent
requests to change the speed.

> + */
> +static ssize_t get_pwm_enable(struct device *dev,
> +			      struct device_attribute *da, char *buf)
> +{
> +	struct g762_data *data = g762_update_client(dev);
> +	int fan_mode;
> +
> +	fan_mode = (data->fan_cmd1 & G762_REG_FAN_CMD1_FAN_MODE) ? 2 : 1;
> +
> +	return sprintf(buf, "%d\n", fan_mode);
> +}
> +
> +static ssize_t set_pwm_enable(struct device *dev,
> +			      struct device_attribute *da,
> +			      const char *buf, size_t count)
> +{
> +	unsigned long val;
> +
> +	if (kstrtoul(buf, 10, &val) || do_set_pwm_enable(dev, val))
> +		return -EINVAL;
> +
> +	return count;
> +}
> +
> +
> +/*
> + * Get/set the fan speed in open-loop mode using pwm1 sysfs file. Speed is
> + * given as a relative value from 0 to 255, where 255 is maximum speed. Note
> + * that this is done by writing directly to the chip's DAC, it won't change
> + * the closed loop speed set by fan1_target. Also note that due to rounding
> + * errors it is possible that you don't read back exactly the value you have
> + * set.
> + */
> +static ssize_t get_pwm(struct device *dev, struct device_attribute *da,
> +		       char *buf)
> +{
> +	struct g762_data *data = g762_update_client(dev);
> +	int val;
> +
> +	mutex_lock(&data->update_lock);
> +	if (data->fan_cmd1 & G762_REG_FAN_CMD1_FAN_MODE) { /* closed-loop */
> +		val = PWM_FROM_CNT(data->set_cnt);
> +	} else {                                            /* open-loop */
> +		val = data->set_out;
> +	}

Wonder why checkpatch doesn't complain about the { }.

> +	mutex_unlock(&data->update_lock);
> +
> +	return sprintf(buf, "%d\n", val);
> +}
> +
> +static ssize_t set_pwm(struct device *dev, struct device_attribute *da,
> +		       const char *buf, size_t count)
> +{
> +	unsigned long val;
> +
> +	if (kstrtoul(buf, 10, &val) || do_set_pwm(dev, val))
> +		return -EINVAL;
> +
> +	return count;
> +}
> +
> +
> +/*
> + * Get/set the fan speed in closed-loop mode using fan1_target sysfs file. Speed
> + * is given as a rpm value, then G762 will automatically regulate the fan speed
> + * using pulses from fan tachometer.
> + *
> + * Refer to rpm_from_cnt implementation to get info about count number
> + * calculation.
> + *
> + * Also note that due to rounding errors it is possible that you don't read
> + * back exactly the value you have set.
> + */
> +static ssize_t get_fan_target(struct device *dev, struct device_attribute *da,
> +			      char *buf)
> +{
> +	struct g762_data *data = g762_update_client(dev);
> +	unsigned int rpm;
> +	ssize_t err;
> +
> +	mutex_lock(&data->update_lock);
> +	if (data->fan_cmd1 & G762_REG_FAN_CMD1_FAN_MODE) { /* closed-loop */
> +		rpm = rpm_from_cnt(data->set_cnt, data->clk,
> +				   PULSE_FROM_REG(data->fan_cmd1),
> +				   CLKDIV_FROM_REG(data->fan_cmd1),
> +				   GEARMODE_FROM_REG(data->fan_cmd2));
> +		err = sprintf(buf, "%u\n", rpm);
> +	} else {                                           /* open-loop */
> +		err = -EINVAL;

Can't you just return the current value, even if not used ?

If the returned value can differ, you might want to cleat ->valid after setting
it.

> +	}
> +	mutex_unlock(&data->update_lock);
> +
> +	return err;
> +}
> +
> +static ssize_t set_fan_target(struct device *dev, struct device_attribute *da,
> +			      const char *buf, size_t count)
> +{
> +	unsigned long val;
> +
> +	if (kstrtoul(buf, 10, &val) || do_set_fan_target(dev, val))
> +		return -EINVAL;
> +
> +	return count;
> +}
> +
> +
> +/* read function for fan1_fault sysfs file. */
> +static ssize_t get_fan_failure(struct device *dev, struct device_attribute *da,
> +			       char *buf)
> +{
> +	struct g762_data *data = g762_update_client(dev);
> +	unsigned int val;
> +
> +	val = (data->fan_sta & G762_REG_FAN_STA_FAIL) ? 1 : 0;
> +
		You can use the !! trick here again.

> +	return sprintf(buf, "%u\n", val);
> +}
> +
> +
> +/* read function for fan1_alarm sysfs file. */
> +static ssize_t get_fan_ooc(struct device *dev, struct device_attribute *da,
> +			   char *buf)
> +{
> +	struct g762_data *data = g762_update_client(dev);
> +	unsigned int val;
> +
> +	/* ooc condition is enabled low */
> +	val = (data->fan_sta & G762_REG_FAN_STA_OOC) ? 0 : 1;
> +
Same here.

> +	return sprintf(buf, "%u\n", val);
> +}
> +
> +
> +static DEVICE_ATTR(pwm1, S_IWUSR | S_IRUGO,
> +		   get_pwm, set_pwm);
> +static DEVICE_ATTR(pwm1_mode, S_IWUSR | S_IRUGO,
> +		   get_pwm_mode, set_pwm_mode);
> +static DEVICE_ATTR(pwm1_enable, S_IWUSR | S_IRUGO,
> +		   get_pwm_enable, set_pwm_enable);
> +
> +static DEVICE_ATTR(fan1_input, S_IRUGO,
> +		   get_fan_rpm, NULL);
> +static DEVICE_ATTR(fan1_alarm, S_IRUGO,
> +		   get_fan_ooc, NULL);
> +static DEVICE_ATTR(fan1_fault, S_IRUGO,
> +		   get_fan_failure, NULL);
> +static DEVICE_ATTR(fan1_target, S_IWUSR | S_IRUGO,
> +		   get_fan_target, set_fan_target);
> +static DEVICE_ATTR(fan1_div, S_IWUSR | S_IRUGO,
> +		   get_fan_div, set_fan_div);
> +
Most if not all of the above don't need two lines.

> +/* Driver data */
> +static struct attribute *g762_attributes[] = {
> +	&dev_attr_fan1_input.attr,
> +	&dev_attr_fan1_alarm.attr,
> +	&dev_attr_fan1_fault.attr,
> +	&dev_attr_fan1_target.attr,
> +	&dev_attr_fan1_div.attr,
> +	&dev_attr_pwm1.attr,
> +	&dev_attr_pwm1_mode.attr,
> +	&dev_attr_pwm1_enable.attr,
> +	NULL
> +};
> +
> +static const struct attribute_group g762_group = {
> +	.attrs = g762_attributes,
> +};
> +
> +static int g762_probe(struct i2c_client *client, const struct i2c_device_id *id)
> +{
> +	struct g762_data *data;
> +	struct g762_config conf;
> +	int err = 0;

Unnecessary initialization.

> +
> +	if (!i2c_check_functionality(client->adapter,
> +				     I2C_FUNC_SMBUS_BYTE_DATA)) {
> +		err = -ENODEV;

	Just return -ENODEV.

> +		goto out;
> +	}
> +
> +	data = devm_kzalloc(&client->dev, sizeof(struct g762_data), GFP_KERNEL);
> +	if (!data) {
> +		err = -ENOMEM;
> +		goto out;

		Just return -ENOMEM.

> +	}
> +	i2c_set_clientdata(client, data);
> +
> +	data->client = client;
> +	mutex_init(&data->update_lock);
> +
> +	/* Enable fan protection and fan fail detection by default */
> +	do_fan_ooc_detection_toggle(&client->dev, 1);
> +	do_fan_failure_detection_toggle(&client->dev, 1);
> +
> +	/*
> +	 * Set default configuration values before passing the structure
> +	 * to OF helpers to overload them using those provided by .dts
> +	 * file (if any). Final config is then commited.
> +	 */
> +	g762_config_init(&conf);
> +	g762_config_of_overload(client, &conf);
> +	err = g762_config_commit(client, &conf);
> +	if (err)
> +		goto out;

	Just return err.

> +
> +	/* Register sysfs hooks */
> +	err = sysfs_create_group(&client->dev.kobj, &g762_group);
> +	if (err)
> +		goto out;

	just return err.

> +
> +	data->hwmon_dev = (struct device *)hwmon_device_register(&client->dev);
> +	if (IS_ERR(data->hwmon_dev)) {
> +		err = PTR_ERR(data->hwmon_dev);
> +		sysfs_remove_group(&client->dev.kobj, &g762_group);

	sysfs_remove_group() should be in the error exit path, not here.

> +		goto out;
> +	}
> +
> +	dev_info(&data->client->dev, "device successfully initialized\n");
> +
Is that useful ?

> + out:
> +	return err;
> +}
> +
> +static int g762_remove(struct i2c_client *client)
> +{
> +	struct g762_data *data = i2c_get_clientdata(client);
> +
> +	hwmon_device_unregister(data->hwmon_dev);
> +	sysfs_remove_group(&client->dev.kobj, &g762_group);
> +
> +	dev_info(&data->client->dev, "device successfully removed\n");

Is that useful ?

> +	return 0;
> +}
> +
> +static struct i2c_driver g762_driver = {
> +	.driver = {
> +		.name = DRVNAME,
> +		.owner = THIS_MODULE,
> +		.of_match_table = of_match_ptr(g762_dt_match),
> +	},
> +	.probe	  = g762_probe,
> +	.remove	  = g762_remove,
> +	.id_table = g762_id,
> +};
> +
> +module_i2c_driver(g762_driver);
> +
> +MODULE_AUTHOR("Olivier Mouchet <olivier.mouchet at gmail.com>");
> +MODULE_DESCRIPTION("GMT G762 driver");
> +MODULE_LICENSE("GPL");
> -- 
> 1.7.10.4
> 
> 


From horms at verge.net.au  Wed Apr 24 20:06:46 2013
From: horms at verge.net.au (Simon Horman)
Date: Thu, 25 Apr 2013 09:06:46 +0900
Subject: [RFC PATCH v3 14/17] ARM: dts: sh7372: cpus/cpu nodes dts updates
In-Reply-To: <1366824502-19729-15-git-send-email-lorenzo.pieralisi@arm.com>
References: <1366824502-19729-1-git-send-email-lorenzo.pieralisi@arm.com>
 <1366824502-19729-15-git-send-email-lorenzo.pieralisi@arm.com>
Message-ID: <20130425000646.GC31061@verge.net.au>

On Wed, Apr 24, 2013 at 06:28:19PM +0100, Lorenzo Pieralisi wrote:
> This patch updates the in-kernel dts files according to the latest cpus
> and cpu bindings updates for ARM.
> 
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>

Acked-by: Simon Horman <horms+renesas at verge.net.au>

> ---
>  arch/arm/boot/dts/sh7372.dtsi | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/sh7372.dtsi b/arch/arm/boot/dts/sh7372.dtsi
> index 677fc60..7bf020e 100644
> --- a/arch/arm/boot/dts/sh7372.dtsi
> +++ b/arch/arm/boot/dts/sh7372.dtsi
> @@ -14,8 +14,13 @@
>  	compatible = "renesas,sh7372";
>  
>  	cpus {
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
>  		cpu at 0 {
>  			compatible = "arm,cortex-a8";
> +			device_type = "cpu";
> +			reg = <0x0>;
>  		};
>  	};
>  };
> -- 
> 1.7.12
> 
> 


From horms at verge.net.au  Wed Apr 24 20:07:01 2013
From: horms at verge.net.au (Simon Horman)
Date: Thu, 25 Apr 2013 09:07:01 +0900
Subject: [RFC PATCH v3 13/17] ARM: dts: r8a7740: cpus/cpu nodes dts updates
In-Reply-To: <1366824502-19729-14-git-send-email-lorenzo.pieralisi@arm.com>
References: <1366824502-19729-1-git-send-email-lorenzo.pieralisi@arm.com>
 <1366824502-19729-14-git-send-email-lorenzo.pieralisi@arm.com>
Message-ID: <20130425000701.GD31061@verge.net.au>

On Wed, Apr 24, 2013 at 06:28:18PM +0100, Lorenzo Pieralisi wrote:
> This patch updates the in-kernel dts files according to the latest cpus
> and cpu bindings updates for ARM.
> 
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>

Acked-by: Simon Horman <horms+renesas at verge.net.au>

> ---
>  arch/arm/boot/dts/r8a7740.dtsi | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/r8a7740.dtsi b/arch/arm/boot/dts/r8a7740.dtsi
> index 798fa35..8a831e9 100644
> --- a/arch/arm/boot/dts/r8a7740.dtsi
> +++ b/arch/arm/boot/dts/r8a7740.dtsi
> @@ -14,8 +14,12 @@
>  	compatible = "renesas,r8a7740";
>  
>  	cpus {
> +		#address-cells = <1>;
> +		#size-cells = <0>;
>  		cpu at 0 {
>  			compatible = "arm,cortex-a9";
> +			device_type = "cpu";
> +			reg = <0x0>;
>  		};
>  	};
>  };
> -- 
> 1.7.12
> 
> 


From khilman at linaro.org  Wed Apr 24 20:19:13 2013
From: khilman at linaro.org (Kevin Hilman)
Date: Wed, 24 Apr 2013 17:19:13 -0700
Subject: [PATCH] idle: fix hlt/nohlt command-line handling in new generic idle
Message-ID: <1366849153-25564-1-git-send-email-khilman@linaro.org>

commit d1669912 (idle: Implement generic idle function) added a new
generic idle along with support for hlt/nohlt command line options to
override default idle loop behavior.  However, the command-line
processing is never compiled.

The command-line handling is wrapped by CONFIG_GENERIC_IDLE_POLL_SETUP
and arches that use this feature select it in their Kconfigs.
However, no Kconfig definition was created for this option, so it is
never enabled, and therefore command-line override of the idle-loop
behavior is broken after migrating to the generic idle loop.

To fix, add a Kconfig definition for GENERIC_IDLE_POLL_SETUP.

Tested on ARM (OMAP4/Panda) which enables the command-line overrides
by default.

Cc: Thomas Gleixner <tglx at linutronix.de>
Cc: Linus Torvalds <torvalds at linux-foundation.org>
Cc: Rusty Russell <rusty at rustcorp.com.au>
Cc: Paul McKenney <paulmck at linux.vnet.ibm.com>
Cc: Peter Zijlstra <peterz at infradead.org>
Cc: Srivatsa S. Bhat <srivatsa.bhat at linux.vnet.ibm.com>
Cc: Magnus Damm <magnus.damm at gmail.com>
Signed-off-by: Kevin Hilman <khilman at linaro.org>
---
Applies on tip/smp/hotplug where generic idle feature is added

 arch/Kconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/Kconfig b/arch/Kconfig
index 1455579..e0ef57b 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -216,6 +216,9 @@ config USE_GENERIC_SMP_HELPERS
 config GENERIC_SMP_IDLE_THREAD
        bool
 
+config GENERIC_IDLE_POLL_SETUP
+       bool
+
 # Select if arch init_task initializer is different to init/init_task.c
 config ARCH_INIT_TASK
        bool
-- 
1.8.2



From horms at verge.net.au  Wed Apr 24 20:19:37 2013
From: horms at verge.net.au (Simon Horman)
Date: Thu, 25 Apr 2013 09:19:37 +0900
Subject: [PATCH v3 1/2] ARM: shmobile: r8a7740: Add Suspend-To-RAM A3SM
In-Reply-To: <20130424100759.GA19399@verge.net.au>
References: <1366196190-14011-1-git-send-email-hechtb+renesas@gmail.com>
 <20130424074904.GG847@verge.net.au>
 <CABYn4swtOdJG18833FLXifeuVsL4R5vUzGjAg5Fv8r==CT5HBw@mail.gmail.com>
 <20130424100759.GA19399@verge.net.au>
Message-ID: <20130425001937.GA7857@verge.net.au>

On Wed, Apr 24, 2013 at 07:07:59PM +0900, Simon Horman wrote:
> On Wed, Apr 24, 2013 at 11:36:33AM +0200, Bastian Hecht wrote:
> > 2013/4/24 Simon Horman <horms at verge.net.au>:
> > > On Wed, Apr 17, 2013 at 12:56:29PM +0200, Bastian Hecht wrote:
> > >> We add 2 Suspend to RAM modes:
> > >> - A3SM PLL0 on/off:     Power domain A3SM that contains the ARM core
> > >>                         and the 2nd level cache with either PLL0 on
> > >>                         or off
> > >>
> > >> As the suspend to memory mechanism we use A3SM PLL off. A3SM PLL on
> > >> is included here too, so CPUIdle can use both power down modes (not
> > >> included in this patch).
> > >>
> > >> The setup of the SYSC regarding the external IRQs is taken from
> > >> pm-sh7372.c from Magnus Damm.
> > >>
> > >> Signed-off-by: Bastian Hecht <hechtb+renesas at gmail.com>
> > >> ---
> > >> v3:
> > >>
> > >> We now stubbornly loop until the SoC really shuts down when we issue
> > >> the WFI command.
> > >
> > > Hi Bastian,
> > >
> > > could you let me know what the status of this series is.
> > > Is it ready to be queued-up for v3.11?
> > 
> > Hello Simon!
> > 
> > I consider it stable and as there are no more comments, I would be
> > happy if you queued it up.
> 
> Thanks, I will see about doing so tomorrow.

Done, they are queued-up in the soc-r8a7740 branch.


From gang.chen at asianux.com  Wed Apr 24 21:16:14 2013
From: gang.chen at asianux.com (Chen Gang)
Date: Thu, 25 Apr 2013 09:16:14 +0800
Subject: [PATCH v2] ARM: Kconfig: let ARM9TDMI and ARM7TDMI invisible.
In-Reply-To: <20130424174602.GA14496@n2100.arm.linux.org.uk>
References: <51775BB3.6000607@asianux.com> <51775D88.2000406@asianux.com>
 <20130424174602.GA14496@n2100.arm.linux.org.uk>
Message-ID: <517883DE.2080603@asianux.com>

On 2013?04?25? 01:46, Russell King - ARM Linux wrote:
> On Wed, Apr 24, 2013 at 12:20:24PM +0800, Chen Gang wrote:
>> > If CONFIG_MMU is disabled, it will let ARM9TDMI and ARM7TDMI visible,
>> > but in fact, only AT91X40 need ARM7TDMI, so need not let them visible.
> I'll apply it myself this evening.  Can I add:
> 
> Tested-by: Chen Gang <gang.chen at asianux.com>
> 
> to it?
> 
> 

Ok, thanks. this patch is really provided by you (Arnd also provided the
same patch, but it seems a little later than you). And I really only
reported and tested it.

And next, I should continue to find and make another patches for ARM.

Thanks.

-- 
Chen Gang

Asianux Corporation


From gang.chen at asianux.com  Wed Apr 24 21:16:47 2013
From: gang.chen at asianux.com (Chen Gang)
Date: Thu, 25 Apr 2013 09:16:47 +0800
Subject: [PATCH v2] ARM: Kconfig: let ARM9TDMI and ARM7TDMI invisible.
In-Reply-To: <8EB7C52E-5044-4B8A-99F2-BCFF9DFDBD2E@jcrosoft.com>
References: <51775BB3.6000607@asianux.com> <51775D88.2000406@asianux.com>
 <20130424174602.GA14496@n2100.arm.linux.org.uk>
 <8EB7C52E-5044-4B8A-99F2-BCFF9DFDBD2E@jcrosoft.com>
Message-ID: <517883FF.4050206@asianux.com>

On 2013?04?25? 01:59, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On Apr 25, 2013, at 1:46 AM, Russell King - ARM Linux <linux at arm.linux.org.uk> wrote:
> 
>> > On Wed, Apr 24, 2013 at 12:20:24PM +0800, Chen Gang wrote:
>>> >> If CONFIG_MMU is disabled, it will let ARM9TDMI and ARM7TDMI visible,
>>> >> but in fact, only AT91X40 need ARM7TDMI, so need not let them visible.
>> > 
>> > I'll apply it myself this evening.  Can I add:
>> > 
>> > Tested-by: Chen Gang <gang.chen at asianux.com>
> you add it mine too
> 
> Tested-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>

Thanks.

-- 
Chen Gang

Asianux Corporation


From thomas.petazzoni at free-electrons.com  Wed Apr 24 22:04:58 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Thu, 25 Apr 2013 04:04:58 +0200
Subject: dma cache coherency on Armada XP dev board
In-Reply-To: <20130424182202.GK13884@titan.lakedaemon.net>
References: <CANX6Damwoz0MSEu5Sb4uKTUhcsC0g+ua1DjuQuMEzXyBOkL7PA@mail.gmail.com>
 <20130424182202.GK13884@titan.lakedaemon.net>
Message-ID: <20130425040458.1084355f@skate>

Viral, Jason,

On Wed, 24 Apr 2013 14:22:02 -0400, Jason Cooper wrote:

> > Recently, I faced DMA related issue. While moving data from memory
> > to the device, I  found that sometimes I am getting Junk data. I
> > looked further to see if this is related to DMA Sync problem. So,
> > basically, I have following questions,
> > 
> > 1. As per [1] ARMADA has Coherency Fabric that sits between CPU and
> > other devices and takes care of hardware based I/O cache coherency.
> > Do we need to enable any support for the same in software ? I am
> > running 3.0.29 based linux kernel. How do I verify that I have all
> > the things enabled in Linux Kernel.
> 
> 3.0.29 must be a Marvell supplied kernel.  You'd have to ask them,
> unfortunately.  I've added the free-electrons guys as they are
> assisting Marvell with adding ArmadaXP/370 to the mainline kernel.
> 
> My advice is to try building the mainline kernel from kernel.org and
> see if the problem remains.
> 
> Thomas and the guys may be able to help you with specific questions
> regarding the Marvell kernel.

As Jason state, 3.0.29 is a kernel that has been heavily patched by
Marvell, so you should consult your Marvell support to get help with
this kernel. We do only support the mainline kernel for the Armada 370
and Armada XP platforms. Do not hesitate to get back to us if you face
similar issues with the mainline kernel.

Best regards,

Thomas Petazzoni
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From shawn.guo at linaro.org  Wed Apr 24 23:35:20 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Thu, 25 Apr 2013 11:35:20 +0800
Subject: [PATCH v5 01/10] ASoC: phycore-ac97: Add DT support
In-Reply-To: <20130424194540.GF32299@pengutronix.de>
References: <1366814199-14827-1-git-send-email-mpa@pengutronix.de>
 <1366814199-14827-2-git-send-email-mpa@pengutronix.de>
 <20130424194540.GF32299@pengutronix.de>
Message-ID: <20130425033517.GA1276@S2101-09.ap.freescale.net>

On Wed, Apr 24, 2013 at 09:45:40PM +0200, Sascha Hauer wrote:
> Hi Markus,
> 
> On Wed, Apr 24, 2013 at 04:36:30PM +0200, Markus Pargmann wrote:
> > Add devicetree support for this audio soc fabric driver.
> > 
> > @@ -32,8 +35,12 @@ static struct snd_soc_dai_link imx_phycore_dai_ac97[] = {
> >  		.stream_name	= "HiFi",
> >  		.codec_dai_name		= "wm9712-hifi",
> >  		.codec_name	= "wm9712-codec",
> > +#ifdef CONFIG_MACH_IMX27_DT
> > +		.platform_name	= "imx-fiq-pcm-audio",
> > +#else
> >  		.cpu_dai_name	= "imx-ssi.0",
> >  		.platform_name	= "imx-fiq-pcm-audio.0",
> > +#endif
> 
> This doesn't work properly. Compiling the kernel with IMX27_DT enabled
> does not necessarily mean that it also started with dt support.
> 
Right, we should run-time check pdev->dev.of_node to see if it's a DT
boot and set .platform_of_node rather than .platform_name if it is.  But
it's only possible with the cleanup series "ASoC: fsl: imx-pcm driver
cleanup" I just sent being the base.  I hope you can rebase your series
on that :)

Shawn

> Personally I am fine with removing platform based support for this
> driver if it's too much effort to fix it properly, but we shouldn't
> start working with ifdefs here.
> 
> Sascha
> 
> 
> -- 
> Pengutronix e.K.                           |                             |
> Industrial Linux Solutions                 | http://www.pengutronix.de/  |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
> Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |



From shawn.guo at linaro.org  Wed Apr 24 23:50:30 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Thu, 25 Apr 2013 11:50:30 +0800
Subject: [PATCH v5 07/10] ASoC: fsl-ssi: imx ac97 support
In-Reply-To: <1366814199-14827-8-git-send-email-mpa@pengutronix.de>
References: <1366814199-14827-1-git-send-email-mpa@pengutronix.de>
 <1366814199-14827-8-git-send-email-mpa@pengutronix.de>
Message-ID: <20130425035029.GB1276@S2101-09.ap.freescale.net>

On Wed, Apr 24, 2013 at 04:36:36PM +0200, Markus Pargmann wrote:
> +/*
> + * Pointer to AC97 reset functions for specific boards
> + */
> +#if IS_ENABLED(CONFIG_MACH_PCA100)
> +extern void pca100_ac97_cold_reset(struct snd_ac97 *ac97);
> +extern void pca100_ac97_warm_reset(struct snd_ac97 *ac97);
> +#else
> +void pca100_ac97_cold_reset(struct snd_ac97 *ac97) { }
> +void pca100_ac97_warm_reset(struct snd_ac97 *ac97) { }
> +#endif
> +
> +#if IS_ENABLED(CONFIG_MACH_PCM043)
> +extern void pcm043_ac97_cold_reset(struct snd_ac97 *ac97);
> +extern void pcm043_ac97_warm_reset(struct snd_ac97 *ac97);
> +#else
> +void pcm043_ac97_cold_reset(struct snd_ac97 *ac97) { }
> +void pcm043_ac97_warm_reset(struct snd_ac97 *ac97) { }
> +#endif
...
> @@ -717,13 +956,39 @@ static int fsl_ssi_probe(struct platform_device *pdev)
>  
>  	strcpy(ssi_private->name, p);
>  
> -	/* Initialize this copy of the CPU DAI driver structure */
> -	memcpy(&ssi_private->cpu_dai_drv, &fsl_ssi_dai_template,
> -	       sizeof(fsl_ssi_dai_template));
> -	ssi_private->cpu_dai_drv.name = ssi_private->name;
> -
>  	ssi_private->use_dma = !of_property_read_bool(np, "fsl,imx-fiq");
>  
> +	if (ac97) {
> +		sprop = of_get_property(of_find_node_by_path("/"), "compatible",
> +				NULL);
> +		p = strrchr(sprop, ',');
> +		if (p)
> +			sprop = p + 1;
> +
> +		if (!strcmp(sprop, "imx27-pca100")) {
> +			ssi_private->ac97_reset = pca100_ac97_cold_reset;
> +			ssi_private->ac97_warm_reset = pca100_ac97_warm_reset;
> +		} else if (!strcmp(sprop, "imx27-pcm043")) {
> +			ssi_private->ac97_reset = pcm043_ac97_cold_reset;
> +			ssi_private->ac97_warm_reset = pcm043_ac97_warm_reset;
> +		} else {
> +			dev_err(&pdev->dev, "Failed to enable ssi AC97 mode, unknown board.\n");
> +			ret = -EINVAL;
> +			goto error_kmalloc;
> +		}

I do not like these board specific hooks show up in an IP driver
in such way.  Can we work it out in other ways, notification or even
platform_data with auxdata?

Shawn



From jaswinder.singh at linaro.org  Thu Apr 25 01:20:18 2013
From: jaswinder.singh at linaro.org (Jassi Brar)
Date: Thu, 25 Apr 2013 10:50:18 +0530
Subject: [PATCHv3 00/14] drivers: mailbox: framework creation
In-Reply-To: <517867E1.7050301@ti.com>
References: <1363145021-14339-1-git-send-email-s-anna@ti.com>
 <CABb+yY0RYkVeo2Sb4WsDJY0jf17488FEz0d2CB994eQaSOEsVg@mail.gmail.com>
 <37C860A02101E749A747FA2D3C1E3C504A5DF7@DLEE11.ent.ti.com>
 <CABb+yY1x4x_A+QtGG9ohsLPgs8c3nEVnd_ExJBGOOR8=6YLPFA@mail.gmail.com>
 <37C860A02101E749A747FA2D3C1E3C504A63B4@DLEE11.ent.ti.com>
 <CAJe_ZhehnniZd730jjiOLrHozq8TOJZgFYLqUe4KqgBiQEu8PA@mail.gmail.com>
 <51779304.4040003@st.com>
 <CAJe_ZhdZv5LW6kdwyPtJe69mfW6t=WQ4OJnG2H4sUhibattN2A@mail.gmail.com>
 <517867E1.7050301@ti.com>
Message-ID: <CAJe_ZhfDZzq+DzA9XDF3PWFUmwcZnDy-mhE4hLNHmf+V4GhOxw@mail.gmail.com>

On 25 April 2013 04:46, Suman Anna <s-anna at ti.com> wrote:
> On 04/24/2013 03:56 AM, Jassi Brar wrote:
>

> I think there are two things here - one is what the client needs to do
> upon sending/receiving a message, and the other is what the send API or
> the mailbox controller should do when a client tried to send a message
> and the controller's shared message/transport is not free (irrespective
> of the atomic or non-atomic context). The kfifos in the common driver
> code are currently solving the latter problem. The current send API
> directly uses the controller to send if it is free, and uses buffering
> only when it is busy. But, I see your point that this should should be
> the responsibility of the specific controller, or even a property of the
> specific mailbox belonging to that controller. This direction would put
> most of the onus on the specific controller drivers, and probably the
> main API would be very simple. Another factor / attribute to consider is
> that a given mailbox may be sharable or exclusive, things are simple if
> it is exclusive to a client driver.
>
I never suggested we don't use buffering. I too believe the API should
buffer requests but also that it should still do atomic callbacks. The
impact on implementation would be that the queue buffer can not grow
at runtime. But that should be fine because a reasonable size (say 10
or even 50) could be chosen and we allow submission of requests from
tx_done callback.

>
> We are talking two fundamentally different usecases/needs here,
> depending on the type of the controller. You seem to be coming from a
> usecase where the client driver needs to know when every message is
> transmitted (from an atomic context, it is a moot point since either you
> are successful or not when transmitting).
>
I am afraid you are confusing the meaning of 'atomic context' here.
atomic context doesn't mean instant transmission of data, but that the
API calls could be made from even atomic context and that the client &
controller can't sleep in callbacks from the API. So it's not moot.

> The remote
> has to ack before it can be shutdown. I would imagine that getting a
> .tx_done on a particular message is not good enough to know that the
> remote is ready for shutdown. I can imagine it to be useful where there
> is some inherent knowledge that the client needs to proceed with the
> next steps when a message is sent.
>
Of course we are not specifying how the mailbox signals are
interpreted by the remote. It should suffice just to realize that
there exists genuine requirement for a client to know when its message
was received by the remote.

> That said, we need to go with the
> stricter one.
>
Great, that we agree.

> My only concern here is that if there can be multiple
> clients for a particular mailbox/controller, then all the clients would
> have to have an agreement on the controller packet type, and the clients
> would mostly have to include the standard mailbox.h as well as a
> controller-specific header.
>
It's the controller driver that actually puts the data on the bus. So
only it should define the format in which it accepts data from the
clients. Every client should simply populate the packet structure
defined in  my_lovely_controller.h and pass on the struct pointer to
the controller driver via API.
No negotiations for the driver seat among passengers :)

> Overall, I see it coming down to following points:
> 1. Calling contexts: Atomic & non-atomic contexts, with the latter
> becoming an extension of the atomic case. I guess this mainly goes with
> the controller functional integration - whether it is used for
> non-urgent messaging or h/w controller command messages (like PM
> usecases?) where .tx_done is relevant.
>
Urgency or not is a business of the client driver. The API and the
controller driver should not delay things more than absolute
necessary.
.tx_done is not about urgency but about h/w provision of 'ack'.

> 2. Behavior of the API or controller driver if the controller transport
> is busy.
I think we both want requests buffered in the API.

> 3. Shareable/exclusive nature of a mailbox. If it is shareable, then
> duplicating the behavior between clients is not worth it, and this
> should be absorbed into the respective controller driver.
>
I think the mailbox should be exclusively held by a client. That makes
many things simpler. Also remote firmwares won't be always robust
enough to handle commands from different subsystems intermixed. The
API only has to make sure the mailbox_get/put operations are very
thin.

Regards,
Jassi


From shawn.guo at linaro.org  Thu Apr 25 01:44:28 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Thu, 25 Apr 2013 13:44:28 +0800
Subject: [RFC PATCH v3 07/17] ARM: dts: imx: cpus/cpu nodes dts updates
In-Reply-To: <1366824502-19729-8-git-send-email-lorenzo.pieralisi@arm.com>
References: <1366824502-19729-1-git-send-email-lorenzo.pieralisi@arm.com>
 <1366824502-19729-8-git-send-email-lorenzo.pieralisi@arm.com>
Message-ID: <20130425054426.GG1389@S2101-09.ap.freescale.net>

On Wed, Apr 24, 2013 at 06:28:12PM +0100, Lorenzo Pieralisi wrote:
> This patch updates the in-kernel dts files according to the latest cpus
> and cpu bindings updates for ARM.
> 
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
> ---
>  arch/arm/boot/dts/imx23.dtsi  | 8 ++++++--
>  arch/arm/boot/dts/imx28.dtsi  | 8 ++++++--
>  arch/arm/boot/dts/imx6dl.dtsi | 2 ++
>  arch/arm/boot/dts/imx6q.dtsi  | 1 +
>  4 files changed, 15 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/imx23.dtsi b/arch/arm/boot/dts/imx23.dtsi
> index 56afcf4..0aae18b 100644
> --- a/arch/arm/boot/dts/imx23.dtsi
> +++ b/arch/arm/boot/dts/imx23.dtsi
> @@ -23,8 +23,12 @@
>  	};
>  
>  	cpus {
> -		cpu at 0 {
> -			compatible = "arm,arm926ejs";
> +		#address-cells = <0>;
> +		#size-cells = <0>;
> +
> +		cpu {
> +			compatible = "arm,arm926ej-s";
> +			device_type = "cpu";
>  		};
>  	};
>  
> diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
> index 7ba4966..07f131fc 100644
> --- a/arch/arm/boot/dts/imx28.dtsi
> +++ b/arch/arm/boot/dts/imx28.dtsi
> @@ -32,8 +32,12 @@
>  	};
>  
>  	cpus {
> -		cpu at 0 {
> -			compatible = "arm,arm926ejs";
> +		#address-cells = <0>;
> +		#size-cells = <0>;
> +
> +		cpu {
> +			compatible = "arm,arm926ej-s";
> +			device_type = "cpu";
>  		};
>  	};
>  
> diff --git a/arch/arm/boot/dts/imx6dl.dtsi b/arch/arm/boot/dts/imx6dl.dtsi
> index 63fafe2..b76d85e 100644
> --- a/arch/arm/boot/dts/imx6dl.dtsi
> +++ b/arch/arm/boot/dts/imx6dl.dtsi
> @@ -16,12 +16,14 @@
>  
>  		cpu at 0 {
>  			compatible = "arm,cortex-a9";
> +			device_type = "cpu";
>  			reg = <0>;
>  			next-level-cache = <&L2>;
>  		};
>  
>  		cpu at 1 {
>  			compatible = "arm,cortex-a9";
> +			device_type = "cpu";
>  			reg = <1>;
>  			next-level-cache = <&L2>;
>  		};
> diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
> index cba021e..65c1b62 100644
> --- a/arch/arm/boot/dts/imx6q.dtsi
> +++ b/arch/arm/boot/dts/imx6q.dtsi
> @@ -17,6 +17,7 @@
>  
>  		cpu at 0 {
>  			compatible = "arm,cortex-a9";
> +			device_type = "cpu";

Shouldn't this line be added for cpu at 1, cpu at 2 and cpu at 3 too?  Other than
that,

Acked-by: Shawn Guo <shawn.guo at linaro.org>

>  			reg = <0>;
>  			next-level-cache = <&L2>;
>  			operating-points = <
> -- 
> 1.7.12
> 
> 



From daniel.lezcano at linaro.org  Thu Apr 25 02:45:03 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Thu, 25 Apr 2013 08:45:03 +0200
Subject: [PATCH] cpuidle: add maintainer entry
In-Reply-To: <51781B48.30208@gmail.com>
References: <1366810463-17495-1-git-send-email-daniel.lezcano@linaro.org>
 <51781B48.30208@gmail.com>
Message-ID: <5178D0EF.3090004@linaro.org>

On 04/24/2013 07:50 PM, Rob Herring wrote:
> On 04/24/2013 08:34 AM, Daniel Lezcano wrote:
>> Currently the cpuidle drivers are spread across the different archs.
>>
>> The patch submission for cpuidle are following different path: the cpuidle core
>> code goes to linux-pm, the ARM drivers goes to arm-soc or the SoC specific
>> tree, sh goes through sh arch tree, pseries goes through PowerPC and
>> finally intel goes through Len's tree while acpi_idle goes under linux-pm.
>>
>> That makes difficult to consolidate the code and to propagate modifications
>> from the cpuidle core to the different drivers.
>>
>> Hopefully, a movement has initiated to put the cpuidle drivers into the
>> drivers/cpuidle directory like cpuidle-calxeda.c and cpuidle-kirkwood.c
>>
>> Add an explicit maintainer entry in the MAINTAINER to clarify the situation
>> and prevent new cpuidle drivers to goes to an arch directory.
>>
>> The upstreaming process is unchanged: Rafael takes the patches to merge them
>> into its tree but with the acked-by from the driver's maintainer. So the header
>> must contains the name of the maintainer.
> 
> Shouldn't MAINTAINERS contain the driver maintainers too?

It should contains the upstream maintainer for the subsystem, and
optionally a co-maintainer.

The MAINTAINERS file gives informations about the patch submission path.

The file's header should contain the maintainer of the driver, so the
submitted patches will go to the subsystem maintainer for upstreaming
and to the driver maintainer for acked-by.

If you add an entry in MAINTAINERS like:

ARM/CALXEDA HIGHBANK ARCHITECTURE
M:      Rob Herring <rob.herring at calxeda.com>
L:      linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
S:      Maintained
F:      arch/arm/mach-highbank/
+F:	drivers/cpuidle/cpuidle-calxeda.c

That will add confusion while we are trying to clarify the situation
with a single entry point for the patches submission. If someone wants
to submit a patch for this driver, it will look at the MAINTAINERS file
and won't know if it should send the patch against arm-soc or linux-pm.

At some exceptions, this is how is organized the different drivers, for
cpufreq, clocksource, ...

>> This organization will be the same than cpufreq.
>>
>> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
>> ---
>>  MAINTAINERS                        |    7 +++++++
>>  drivers/cpuidle/cpuidle-calxeda.c  |    4 +++-
>>  drivers/cpuidle/cpuidle-kirkwood.c |    5 +++--
>>  3 files changed, 13 insertions(+), 3 deletions(-)
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 61677c3..effa0f3 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -2206,6 +2206,13 @@ S:	Maintained
>>  F:	drivers/cpufreq/
>>  F:	include/linux/cpufreq.h
>>  
>> +CPUIDLE DRIVERS
>> +M:	Rafael J. Wysocki <rjw at sisk.pl>
>> +L:	linux-pm at vger.kernel.org
>> +S:	Maintained
>> +F:	drivers/cpuidle/*
>> +F:	include/linux/cpuidle.h
>> +
>>  CPU FREQUENCY DRIVERS - ARM BIG LITTLE
>>  M:	Viresh Kumar <viresh.kumar at linaro.org>
>>  M:	Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
>> diff --git a/drivers/cpuidle/cpuidle-calxeda.c b/drivers/cpuidle/cpuidle-calxeda.c
>> index e344b56..2378c39 100644
>> --- a/drivers/cpuidle/cpuidle-calxeda.c
>> +++ b/drivers/cpuidle/cpuidle-calxeda.c
>> @@ -1,7 +1,6 @@
>>  /*
>>   * Copyright 2012 Calxeda, Inc.
>>   *
>> - * Based on arch/arm/plat-mxc/cpuidle.c:
> 
> This file may have moved, but it existed at the time this was committed.
> So the comment still applies and documents what part of the file the FSL
> and Linaro copyright applies to.

Ok. As this file moved to arch/arm/mach-imx and changed a lot, may be we
can add the tag #v3.7 in the comment...

> Of course most of what was copied here was the boilerplate which your
> patch series removes. The heart of the functionality was developed by me.
> 
>>   * Copyright 2012 Freescale Semiconductor, Inc.
>>   * Copyright 2012 Linaro Ltd.
>>   *
>> @@ -16,6 +15,9 @@
>>   *
>>   * You should have received a copy of the GNU General Public License along with
>>   * this program.  If not, see <http://www.gnu.org/licenses/>.
>> + *
>> + * Author    : Rob Herring <rob.herring at calxeda.com>
>> + * Maintainer: Rob Herring <rob.herring at calxeda.com>
> 
> As mentioned above, this doesn't seem right.

It is based on Robert Lee's cpuidle driver for imx, but you wrote this
driver, no ?

If I refer to commit be6a98d3f00c292d347465d96acbec9d8c2783cf, you are
author of this driver. Suffice to say the driver was initially based on
imx, which is the case in the top of the header.

I suggest to keep the Author and the Maintainer because if, in the
future, you don't want to maintain anymore the driver and someone wants
to know the initial author of the driver for any reasons, he can check
that in the file header without archaeological digs in the git history.

  -- Daniel

-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From srivatsa.bhat at linux.vnet.ibm.com  Thu Apr 25 02:42:17 2013
From: srivatsa.bhat at linux.vnet.ibm.com (Srivatsa S. Bhat)
Date: Thu, 25 Apr 2013 12:12:17 +0530
Subject: [PATCH] idle: fix hlt/nohlt command-line handling in new generic
 idle
In-Reply-To: <1366849153-25564-1-git-send-email-khilman@linaro.org>
References: <1366849153-25564-1-git-send-email-khilman@linaro.org>
Message-ID: <5178D049.9090303@linux.vnet.ibm.com>

On 04/25/2013 05:49 AM, Kevin Hilman wrote:
> commit d1669912 (idle: Implement generic idle function) added a new
> generic idle along with support for hlt/nohlt command line options to
> override default idle loop behavior.  However, the command-line
> processing is never compiled.
> 
> The command-line handling is wrapped by CONFIG_GENERIC_IDLE_POLL_SETUP
> and arches that use this feature select it in their Kconfigs.
> However, no Kconfig definition was created for this option, so it is
> never enabled, and therefore command-line override of the idle-loop
> behavior is broken after migrating to the generic idle loop.
> 
> To fix, add a Kconfig definition for GENERIC_IDLE_POLL_SETUP.
> 
> Tested on ARM (OMAP4/Panda) which enables the command-line overrides
> by default.
> 
> Cc: Thomas Gleixner <tglx at linutronix.de>
> Cc: Linus Torvalds <torvalds at linux-foundation.org>
> Cc: Rusty Russell <rusty at rustcorp.com.au>
> Cc: Paul McKenney <paulmck at linux.vnet.ibm.com>
> Cc: Peter Zijlstra <peterz at infradead.org>
> Cc: Srivatsa S. Bhat <srivatsa.bhat at linux.vnet.ibm.com>
> Cc: Magnus Damm <magnus.damm at gmail.com>
> Signed-off-by: Kevin Hilman <khilman at linaro.org>
> ---

Reviewed-by: Srivatsa S. Bhat <srivatsa.bhat at linux.vnet.ibm.com>

Regards,
Srivatsa S. Bhat

> Applies on tip/smp/hotplug where generic idle feature is added
>
>  arch/Kconfig | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/arch/Kconfig b/arch/Kconfig
> index 1455579..e0ef57b 100644
> --- a/arch/Kconfig
> +++ b/arch/Kconfig
> @@ -216,6 +216,9 @@ config USE_GENERIC_SMP_HELPERS
>  config GENERIC_SMP_IDLE_THREAD
>         bool
> 
> +config GENERIC_IDLE_POLL_SETUP
> +       bool
> +
>  # Select if arch init_task initializer is different to init/init_task.c
>  config ARCH_INIT_TASK
>         bool
> 



From viresh.kumar at linaro.org  Thu Apr 25 02:49:56 2013
From: viresh.kumar at linaro.org (Viresh Kumar)
Date: Thu, 25 Apr 2013 12:19:56 +0530
Subject: [PATCH] cpuidle: add maintainer entry
In-Reply-To: <5178D0EF.3090004@linaro.org>
References: <1366810463-17495-1-git-send-email-daniel.lezcano@linaro.org>
 <51781B48.30208@gmail.com> <5178D0EF.3090004@linaro.org>
Message-ID: <CAKohpo=Ct7WCBSOqmgk8asVyXWa5o+jqpTwaQgxKVm_XNLfnMA@mail.gmail.com>

On 25 April 2013 12:15, Daniel Lezcano <daniel.lezcano at linaro.org> wrote:
> On 04/24/2013 07:50 PM, Rob Herring wrote:

>> Shouldn't MAINTAINERS contain the driver maintainers too?
>
> It should contains the upstream maintainer for the subsystem, and
> optionally a co-maintainer.
>
> The MAINTAINERS file gives informations about the patch submission path.
>
> The file's header should contain the maintainer of the driver, so the
> submitted patches will go to the subsystem maintainer for upstreaming
> and to the driver maintainer for acked-by.
>
> If you add an entry in MAINTAINERS like:
>
> ARM/CALXEDA HIGHBANK ARCHITECTURE
> M:      Rob Herring <rob.herring at calxeda.com>
> L:      linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
> S:      Maintained
> F:      arch/arm/mach-highbank/
> +F:     drivers/cpuidle/cpuidle-calxeda.c
>
> That will add confusion while we are trying to clarify the situation
> with a single entry point for the patches submission. If someone wants
> to submit a patch for this driver, it will look at the MAINTAINERS file
> and won't know if it should send the patch against arm-soc or linux-pm.

I though otherwise. We can add entry in MAINTAINERS for any module.
Module can be a framework/architecture or a single driver.

Adding entry for cpuidle driver of a architecture as you wrote for calxeda is
wrong as it adds to confusion and so there should be a separate entry for
this driver rather than merging it with arch/ entries.


From rnayak at ti.com  Thu Apr 25 03:01:22 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Thu, 25 Apr 2013 12:31:22 +0530
Subject: [PATCH V4 1/6] clk: OMAP: introduce device tree binding to kernel
 clock data
In-Reply-To: <20130424162847.8998.73264@quantum>
References: <1365807278-554-1-git-send-email-nm@ti.com>
 <1365807278-554-2-git-send-email-nm@ti.com>
 <20130412233142.GE10155@atomide.com> <20130412233900.GA1599@kahuna>
 <20130413172210.GM10155@atomide.com> <20130414211917.GA3275@snafu>
 <20130424162847.8998.73264@quantum>
Message-ID: <5178D4C2.7080400@ti.com>

On Wednesday 24 April 2013 09:58 PM, Mike Turquette wrote:
> Quoting Nishanth Menon (2013-04-14 14:19:17)
>> Overall strategy introduced here is simple: a clock node described in
>> device tree blob is used to identify the exact clock provided in the
>> SoC specific data. This is then linked back using of_clk_add_provider
>> to the device node to be accessible by of_clk_get.
>>
>> Based on discussion contributions from Roger Quadros, Grygorii Strashko
>> and others.
>>
>> Cc: Kevin Hilman <khilman at deeprootsystems.com>
>> Cc: Mike Turquette <mturquette at linaro.org>
>> Cc: Paul Walmsley <paul at pwsan.com>
>> [tony at atomide.com: co-developed]
>> Signed-off-by: Tony Lindgren <tony at atomide.com>
>> Signed-off-by: Nishanth Menon <nm at ti.com>
> 
> I can take this into clk-next after the merge window.  Please refresh it
> for -rc1 as we discussed on irc.
> 
> As an aside, will Tero's series for migrating to drivers/clk/omap[1] and
> Rajendra's patch for registering clocks late[2] be refreshed after the

[2] is already in mainline.

> merge window?  It would be nice to combine these efforts.
> 
> Thanks,
> Mike
> 
> [1] http://article.gmane.org/gmane.linux.ports.arm.omap/95948
> [2] http://www.spinics.net/lists/arm-kernel/msg231288.html
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
> 



From daniel.lezcano at linaro.org  Thu Apr 25 03:06:23 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Thu, 25 Apr 2013 09:06:23 +0200
Subject: [PATCH] cpuidle: add maintainer entry
In-Reply-To: <CAKohpo=Ct7WCBSOqmgk8asVyXWa5o+jqpTwaQgxKVm_XNLfnMA@mail.gmail.com>
References: <1366810463-17495-1-git-send-email-daniel.lezcano@linaro.org>
 <51781B48.30208@gmail.com> <5178D0EF.3090004@linaro.org>
 <CAKohpo=Ct7WCBSOqmgk8asVyXWa5o+jqpTwaQgxKVm_XNLfnMA@mail.gmail.com>
Message-ID: <5178D5EF.9090102@linaro.org>

On 04/25/2013 08:49 AM, Viresh Kumar wrote:
> On 25 April 2013 12:15, Daniel Lezcano <daniel.lezcano at linaro.org> wrote:
>> On 04/24/2013 07:50 PM, Rob Herring wrote:
> 
>>> Shouldn't MAINTAINERS contain the driver maintainers too?
>>
>> It should contains the upstream maintainer for the subsystem, and
>> optionally a co-maintainer.
>>
>> The MAINTAINERS file gives informations about the patch submission path.
>>
>> The file's header should contain the maintainer of the driver, so the
>> submitted patches will go to the subsystem maintainer for upstreaming
>> and to the driver maintainer for acked-by.
>>
>> If you add an entry in MAINTAINERS like:
>>
>> ARM/CALXEDA HIGHBANK ARCHITECTURE
>> M:      Rob Herring <rob.herring at calxeda.com>
>> L:      linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
>> S:      Maintained
>> F:      arch/arm/mach-highbank/
>> +F:     drivers/cpuidle/cpuidle-calxeda.c
>>
>> That will add confusion while we are trying to clarify the situation
>> with a single entry point for the patches submission. If someone wants
>> to submit a patch for this driver, it will look at the MAINTAINERS file
>> and won't know if it should send the patch against arm-soc or linux-pm.
> 
> I though otherwise. We can add entry in MAINTAINERS for any module.
> Module can be a framework/architecture or a single driver.

IMO, there are too much drivers for that. It is simpler for someone to
read the MAINTAINERS file to find the cpuidle drivers goes through
linux-pm. I think we can trust Rafael to ask for the acked-by from the
maintainer of the driver before taking the patches.

> Adding entry for cpuidle driver of a architecture as you wrote for calxeda is
> wrong as it adds to confusion and so there should be a separate entry for
> this driver rather than merging it with arch/ entries.

Yes, actually it was an example to show the confusion we could be facing.

Thanks
  -- Daniel

-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From thomas.abraham at linaro.org  Thu Apr 25 03:38:43 2013
From: thomas.abraham at linaro.org (Thomas Abraham)
Date: Thu, 25 Apr 2013 13:08:43 +0530
Subject: [PATCH] ARM: dts: add pinctrl nodes for Exynos5250 SoC
In-Reply-To: <20130424233348.GA6603@quad.lixom.net>
References: <1355403978-388-1-git-send-email-thomas.abraham@linaro.org>
 <20130424233348.GA6603@quad.lixom.net>
Message-ID: <CAJuYYwTwbYhRO7z8J79g-GM-44Y6A6trkF_z72Kqp+MoBF==+w@mail.gmail.com>

On 25 April 2013 05:03, Olof Johansson <olof at lixom.net> wrote:
> On Thu, Dec 13, 2012 at 06:36:18PM +0530, Thomas Abraham wrote:
>> Add pinctrl device nodes for Exynos5250 SoC.
>>
>> Signed-off-by: Thomas Abraham <thomas.abraham at linaro.org>
>
> Replying to an old email of a patch that has been merged because it seems
> horribly broken.
>
>
>> diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi
>> index 581e57a..eb8d610 100644
>> --- a/arch/arm/boot/dts/exynos5250.dtsi
>> +++ b/arch/arm/boot/dts/exynos5250.dtsi
>> @@ -18,6 +18,7 @@
>>  */
>>
>>  /include/ "skeleton.dtsi"
>> +/include/ "exynos5250-pinctrl.dtsi"
>>
>>  / {
>>       compatible = "samsung,exynos5250";
>> @@ -48,6 +49,8 @@
>>               mshc1 = &dwmmc_1;
>>               mshc2 = &dwmmc_2;
>>               mshc3 = &dwmmc_3;
>> +             pinctrl0 = &pinctrl_0;
>> +             pinctrl3 = &pinctrl_3;
>>       };
>>
>>       gic:interrupt-controller at 10481000 {
>> @@ -79,6 +82,24 @@
>>               interrupts = <0 42 0>;
>>       };
>>
>> +     pinctrl_0: pinctrl at 11400000 {
>> +             compatible = "samsung,pinctrl-exynos5250";
>> +             reg = <0x11400000 0x1000>;
>> +             interrupts = <0 46 0>;
>> +
>> +             wakup_eint: wakeup-interrupt-controller {
>> +                     compatible = "samsung,exynos4210-wakeup-eint";
>> +                     interrupt-parent = <&gic>;
>> +                     interrupts = <0 32 0>;
>> +             };
>
> Typo, should be "wakeup_eint". And what happened to #interrupt-cells? And the
> interrupt map?

Hi Olof,

With the pinctrl driver, there is change in the way the wakeup
interrupts are handled. Each of the four wakeup banks (GPX0 to GPX3)
are now individual interrupt controllers (introduced by Tomasz Figa).
The wakeup interrupts generated by GPX2 and GPX3 are muxed into the <0
32 0> interrupt of GIC.

So the interrupts-cells and interrupt map are not required in the
above node. The label "wakup_eint" can actually to dropped and
probably the node name "wakeup-interrupt-controller" should be renamed
to avoid interpreting it as a interrupt controller node.

>
> Do you have an example of a tested user or a testcase for this? I'm
> trying to get interrupts going on these pins, and it's not looking like
> it's even close to working.

The following is a rudimentary patch with which I have tested wakeup
interrupts GPX0[0] and GPX3[7] on smdk5250 board. The gpio number in
the dts file can be changed to test wakeup interrupt on pins other
than EINT31 (GPX3[7]).

Thanks,
Thomas.

simple patch to test wakeup interrupts on smdk5250 board.
Note: some of the smdk5250 boards may have a faulty SW8 button
(for EINT31) and so EINT31 might not work on those smdk5250
boards.

Signed-off-by: Thomas Abraham <thomas.abraham at linaro.org>
---
 arch/arm/boot/dts/exynos5250-smdk5250.dts |    5 ++
 arch/arm/mach-exynos/Makefile             |    2 +-
 arch/arm/mach-exynos/button-smdk5250.c    |   72 +++++++++++++++++++++++++++++
 3 files changed, 78 insertions(+), 1 deletions(-)
 create mode 100644 arch/arm/mach-exynos/button-smdk5250.c

diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts
b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index 26d856b..eedec6a 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -248,4 +248,9 @@
                        clock-frequency = <24000000>;
                };
        };
+
+       test-wkup {
+               compatible = "test_wkup";
+               gpios = <&gpx3 7 0>;
+       };
 };
diff --git a/arch/arm/mach-exynos/Makefile b/arch/arm/mach-exynos/Makefile
index ef6860b..d7640e3 100644
--- a/arch/arm/mach-exynos/Makefile
+++ b/arch/arm/mach-exynos/Makefile
@@ -44,7 +44,7 @@ obj-$(CONFIG_MACH_SMDK4212)           += mach-smdk4x12.o
 obj-$(CONFIG_MACH_SMDK4412)            += mach-smdk4x12.o

 obj-$(CONFIG_MACH_EXYNOS4_DT)          += mach-exynos4-dt.o
-obj-$(CONFIG_MACH_EXYNOS5_DT)          += mach-exynos5-dt.o
+obj-$(CONFIG_MACH_EXYNOS5_DT)          += mach-exynos5-dt.o button-smdk5250.o

 # device support

diff --git a/arch/arm/mach-exynos/button-smdk5250.c
b/arch/arm/mach-exynos/button-smdk5250.c
new file mode 100644
index 0000000..2dbb5b4
--- /dev/null
+++ b/arch/arm/mach-exynos/button-smdk5250.c
@@ -0,0 +1,72 @@
+/* linux/arch/arm/mach-s5pv310/button-smdkv310.c
+ *
+ * Copyright (c) 2010 Samsung Electronics Co., Ltd.
+ *             http://www.samsung.com/
+ *
+ * Button Driver
+ *
+ * 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/init.h>
+#include <linux/interrupt.h>
+#include <linux/irq.h>
+#include <linux/ioport.h>
+#include <linux/delay.h>
+#include <linux/serial_core.h>
+#include <linux/io.h>
+#include <linux/platform_device.h>
+#include <linux/irq.h>
+#include <linux/gpio.h>
+#include <linux/of.h>
+#include <linux/of_gpio.h>
+
+#include <plat/map-base.h>
+#include <plat/gpio-cfg.h>
+
+#include <mach/regs-gpio.h>
+#include <mach/regs-irq.h>
+
+static irqreturn_t
+s3c_button_interrupt(int irq, void *dev_id)
+{
+       printk("\n %d irq occured \n", irq);
+       return IRQ_HANDLED;
+}
+
+static struct irqaction s3c_button_irq = {
+       .name           = "s3c button Tick",
+       .flags          = IRQF_SHARED ,
+       .handler        = s3c_button_interrupt,
+};
+
+static int __init smdk5250_button_test(void)
+{
+       struct device_node *np;
+       unsigned long gpio;
+       int gpio_irq;
+
+       printk(KERN_INFO "\n\n SMDKV5250 Button init function\n");
+
+       np = of_find_compatible_node(NULL, NULL, "test_wkup");
+       if (!np) {
+               printk("could not find test node.. stopping.\n");
+               return -EINVAL;
+       }
+
+       gpio = of_get_gpio(np, 0);
+       if (!gpio_is_valid(gpio)) {
+               printk("\n gpio_weint_mux gpio is invalid\n");
+               return -EINVAL;
+       }
+
+       gpio_irq = gpio_to_irq(gpio);
+
+       irq_set_irq_type(gpio_irq, IRQ_TYPE_EDGE_BOTH);
+       setup_irq(gpio_irq, &s3c_button_irq);
+
+       return 0;
+}
+late_initcall(smdk5250_button_test);

>
>
> -Olof


From Ian.Campbell at citrix.com  Thu Apr 25 03:48:26 2013
From: Ian.Campbell at citrix.com (Ian Campbell)
Date: Thu, 25 Apr 2013 08:48:26 +0100
Subject: [Xen-devel] [PATCH v6 1/4] arm: introduce psci_smp_ops
In-Reply-To: <alpine.LFD.2.03.1304221151200.17375@syhkavp.arg>
References: <alpine.DEB.2.02.1304031239550.5078@kaball.uk.xensource.com>
 <1365167495-18508-1-git-send-email-stefano.stabellini@eu.citrix.com>
 <20130418161341.GB14496@n2100.arm.linux.org.uk>
 <alpine.DEB.2.02.1304181714560.7254@kaball.uk.xensource.com>
 <alpine.LFD.2.03.1304181237480.17375@syhkavp.arg>
 <alpine.DEB.2.02.1304181749260.7254@kaball.uk.xensource.com>
 <alpine.LFD.2.03.1304181336280.17375@syhkavp.arg>
 <alpine.DEB.2.02.1304191035360.7254@kaball.uk.xensource.com>
 <alpine.LFD.2.03.1304191146230.17375@syhkavp.arg>
 <1366388166.29403.2.camel@dagon.hellion.org.uk>
 <alpine.LFD.2.03.1304191223280.17375@syhkavp.arg>
 <alpine.DEB.2.02.1304191739120.7254@kaball.uk.xensource.com>
 <1366644069.20256.8.camel@zakaz.uk.xensource.com>
 <alpine.LFD.2.03.1304221151200.17375@syhkavp.arg>
Message-ID: <1366876106.20256.399.camel@zakaz.uk.xensource.com>

On Mon, 2013-04-22 at 17:07 +0100, Nicolas Pitre wrote:
> Sure there are ways to screw up Xen support from within this hook, but 
> that can be achieved in many other places.  Will Xen take over every 
> possible hooks in the kernel to prevent that from happening?

In the majority of the other cases we would consider it a bug in Xen for
not exposing these bits of the underlying hardware correctly to dom0,
however the SMP stuff is a bit of a special case for the reasons I
explained earlier which is why we are worrying about it more.

> So please let's not cry wolf needlessly.

Yes, perhaps those worries unfounded at this stage and we should just
run with it and reference this discussion if it turns out to not work
out well in practice.

Ian.



From linus.walleij at linaro.org  Thu Apr 25 04:06:05 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Apr 2013 10:06:05 +0200
Subject: [PATCH 04/32] dmaengine: ste_dma40: Amalgamate DMA source and
 destination channel numbers
In-Reply-To: <1366279934-30761-5-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-5-git-send-email-lee.jones@linaro.org>
Message-ID: <CACRpkdaauDYTdoBHGG9FO4kKqvCYyCrjY8EGWs5gAQWErGW6_A@mail.gmail.com>

On Thu, Apr 18, 2013 at 12:11 PM, Lee Jones <lee.jones at linaro.org> wrote:

> Devices which utilise DMA tend to use the same channel numbers for
> transmitting and receiving. For this reason and the fact that it'll
> decrease the burden of platform data passed to each device, we're
> amalgamating source and destination device types.

I don't think this explains what the patch is actually doing.

Instead describe this:

> @@ -56,8 +54,7 @@ static struct stedma40_chan_cfg msp1_dma_rx = {
>         .high_priority = true,
>         .dir = STEDMA40_PERIPH_TO_MEM,
>
> -       .src_dev_type = DB8500_DMA_DEV30_MSP3_RX,
> -       .dst_dev_type = STEDMA40_DEV_DST_MEMORY,
> +       .dev_type = DB8500_DMA_DEV30_MSP3,
(...)

What the message should say is that we're encoding pairs of
information for sources and destinations. Since every such
entry contains a .dir entry stating the direction of the transfer
it is implicit whether the channel is for RX or TX and this is what
you're exploiting in this patch.

So channel numbers (as mentioned in the commit) is not
the key issue here.

Now we should ask ourselves why it was done like this from
the beginning. The reason is that DMA40 supports device-to-device
DMA, so if you encoded one device in .src_dev_type and another
device in .dst_dev_type and set .dir to
STEDMA40_PERIPH_TO_PERIPH (which as you can see is
defined in <linux/platform_data/dma-ste-dma40.h>) you get a
device to device transfer.

Are we now sacrificing that ability on the altar of simplification?

I actually think not, but that we should do periph-to-periph transfers
in some other way, and that the .dir attribute should go away from
the struct stedma40_chan_cfg as well but I'm not entirely sure.
Someone else?

(...)
> +++ b/arch/arm/mach-ux500/cpu-db8500.c
> @@ -167,25 +167,25 @@ static void __init db8500_add_gpios(struct device *parent)
>  }
>
>  static int usb_db8500_rx_dma_cfg[] = {
> -       DB8500_DMA_DEV38_USB_OTG_IEP_1_9,
> -       DB8500_DMA_DEV37_USB_OTG_IEP_2_10,
> -       DB8500_DMA_DEV36_USB_OTG_IEP_3_11,
> -       DB8500_DMA_DEV19_USB_OTG_IEP_4_12,
> -       DB8500_DMA_DEV18_USB_OTG_IEP_5_13,
> -       DB8500_DMA_DEV17_USB_OTG_IEP_6_14,
> -       DB8500_DMA_DEV16_USB_OTG_IEP_7_15,
> -       DB8500_DMA_DEV39_USB_OTG_IEP_8
> +       DB8500_DMA_DEV38_USB_OTG_IEP_AND_OEP_1_9,
> +       DB8500_DMA_DEV37_USB_OTG_IEP_AND_OEP_2_10,
> +       DB8500_DMA_DEV36_USB_OTG_IEP_AND_OEP_3_11,
> +       DB8500_DMA_DEV19_USB_OTG_IEP_AND_OEP_4_12,
> +       DB8500_DMA_DEV18_USB_OTG_IEP_AND_OEP_5_13,
> +       DB8500_DMA_DEV17_USB_OTG_IEP_AND_OEP_6_14,
> +       DB8500_DMA_DEV16_USB_OTG_IEP_AND_OEP_7_15,
> +       DB8500_DMA_DEV39_USB_OTG_IEP_AND_OEP_8
>  };
>
>  static int usb_db8500_tx_dma_cfg[] = {
> -       DB8500_DMA_DEV38_USB_OTG_OEP_1_9,
> -       DB8500_DMA_DEV37_USB_OTG_OEP_2_10,
> -       DB8500_DMA_DEV36_USB_OTG_OEP_3_11,
> -       DB8500_DMA_DEV19_USB_OTG_OEP_4_12,
> -       DB8500_DMA_DEV18_USB_OTG_OEP_5_13,
> -       DB8500_DMA_DEV17_USB_OTG_OEP_6_14,
> -       DB8500_DMA_DEV16_USB_OTG_OEP_7_15,
> -       DB8500_DMA_DEV39_USB_OTG_OEP_8
> +       DB8500_DMA_DEV38_USB_OTG_IEP_AND_OEP_1_9,
> +       DB8500_DMA_DEV37_USB_OTG_IEP_AND_OEP_2_10,
> +       DB8500_DMA_DEV36_USB_OTG_IEP_AND_OEP_3_11,
> +       DB8500_DMA_DEV19_USB_OTG_IEP_AND_OEP_4_12,
> +       DB8500_DMA_DEV18_USB_OTG_IEP_AND_OEP_5_13,
> +       DB8500_DMA_DEV17_USB_OTG_IEP_AND_OEP_6_14,
> +       DB8500_DMA_DEV16_USB_OTG_IEP_AND_OEP_7_15,
> +       DB8500_DMA_DEV39_USB_OTG_IEP_AND_OEP_8
>  };


If you're doing this change, and after this RX and TX has no semantical
meaning for these lists, join these two config lists
into one.

(...)
> diff --git a/arch/arm/mach-ux500/usb.c b/arch/arm/mach-ux500/usb.c
>  static u32 d40_chan_has_events(struct d40_chan *d40c)
> @@ -1744,8 +1740,6 @@ static int d40_validate_conf(struct d40_chan *d40c,
>                              struct stedma40_chan_cfg *conf)
>  {
>         int res = 0;
> -       u32 dst_event_group = D40_TYPE_TO_GROUP(conf->dst_dev_type);
> -       u32 src_event_group = D40_TYPE_TO_GROUP(conf->src_dev_type);

Please explain why this is not important to check anymore, I'm not
following.

>         if (conf->dir == STEDMA40_MEM_TO_PERIPH &&
> -           dst_event_group == STEDMA40_DEV_DST_MEMORY) {
> -               chan_err(d40c, "Invalid dst\n");
> +           d40c->base->plat_data->dev_tx[conf->dev_type] == 0 &&
> +           d40c->runtime_addr == 0) {
> +               chan_err(d40c, "Invalid TX channel address (%d)\n",
> +                        conf->dev_type);

Like here. We are checking for inconsistency between group
and channel direction, why is it no longer important to check this?

>         if (conf->dir == STEDMA40_PERIPH_TO_MEM &&
> -           src_event_group == STEDMA40_DEV_SRC_MEMORY) {
> -               chan_err(d40c, "Invalid src\n");
> -               res = -EINVAL;
> -       }
> -
> -       if (src_event_group == STEDMA40_DEV_SRC_MEMORY &&
> -           dst_event_group == STEDMA40_DEV_DST_MEMORY && is_log) {
> -               chan_err(d40c, "No event line\n");
> -               res = -EINVAL;
> -       }
> -
> -       if (conf->dir == STEDMA40_PERIPH_TO_PERIPH &&
> -           (src_event_group != dst_event_group)) {
> -               chan_err(d40c, "Invalid event group\n");
> +           d40c->base->plat_data->dev_rx[conf->dev_type] == 0 &&
> +           d40c->runtime_addr == 0) {
> +               chan_err(d40c, "Invalid RX channel address (%d)\n",
> +                        conf->dev_type);

Same here.

(...)
> @@ -2062,7 +2035,7 @@ static int d40_free_dma(struct d40_chan *d40c)
>  {
>
>         int res = 0;
> -       u32 event;
> +       u32 event = D40_TYPE_TO_EVENT(d40c->dma_cfg.dev_type);
>         struct d40_phy_res *phy = d40c->phy_chan;
>         bool is_src;
>
> @@ -2081,13 +2054,11 @@ static int d40_free_dma(struct d40_chan *d40c)
>         }
>
>         if (d40c->dma_cfg.dir == STEDMA40_MEM_TO_PERIPH ||
> -           d40c->dma_cfg.dir == STEDMA40_MEM_TO_MEM) {
> -               event = D40_TYPE_TO_EVENT(d40c->dma_cfg.dst_dev_type);
> +           d40c->dma_cfg.dir == STEDMA40_MEM_TO_MEM)

Why did you just stop checking dma_cfg.dir for == STEDMA40_MEM_TO_MEM
above?

And why is dma_cfg.dir suddenly hardcoded to MEM_TO_MEM??

This seems like a totally unrelated change and should it be done
it need to be a separate patch with a separate explanation
AFAICT.

This seems to happen in some other places too, and I find it
very hard to follow the changes here ... can you please consider
splitting the changes to groups and types semantics into a separate
patch?

Yours,
Linus Walleij


From lee.jones at linaro.org  Thu Apr 25 04:13:38 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Thu, 25 Apr 2013 09:13:38 +0100
Subject: [PATCH 03/32 v3] dmaengine: ste_dma40: Use the BIT macro to
 replace ugly '(1 << x)'s
In-Reply-To: <CAH+eYFBKnEWkcJ+9DxVqnxbPS4QYtswi7Ux0JHnTWYfRFy_5Aw@mail.gmail.com>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-4-git-send-email-lee.jones@linaro.org>
 <20130424151145.GH9652@gmail.com>
 <CAH+eYFBKnEWkcJ+9DxVqnxbPS4QYtswi7Ux0JHnTWYfRFy_5Aw@mail.gmail.com>
Message-ID: <20130425081338.GB4623@gmail.com>

On Wed, 24 Apr 2013, Rabin Vincent wrote:

> 2013/4/24 Lee Jones <lee.jones at linaro.org>:
> > The aim is to make the code that little more readable.
> >
> > Acked-by: Vinod Koul <vnod.koul at intel.com>
> > Acked-by: Arnd Bergmann <arnd at arndb.de>
> > Signed-off-by: Lee Jones <lee.jones at linaro.org>
> 
> Please pay closer attention to the semantics of each usage instead of
> just replacing all x left shifts of 1 by BIT(x) for "readability".
> 
> >         if (seg_max > STEDMA40_MAX_SEG_SIZE)
> > -               seg_max -= (1 << max_w);
> > +               seg_max -= BIT(max_w);
> >
> > -       if (!IS_ALIGNED(size, 1 << max_w))
> > +       if (!IS_ALIGNED(size, BIT(max_w)))
> >                 return -EINVAL;
> 
> Here and in all other places where the values are from cfg->data_width,
> the semantic purpose of the shift is not for setting a particular bit
> but instead for converting the data_width field into the data width
> value in bytes.  You should not change these usages to BIT().
> 
> It would be instead better to just make the cfg->data_width as the
> number of bytes and convert them to the appropriate hardware field
> values when the descriptors are constructed.  That of course should be
> in another patch.

I'll do that. Thanks for the pointer.

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From linus.walleij at linaro.org  Thu Apr 25 04:22:13 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Apr 2013 10:22:13 +0200
Subject: [PATCH 05/32] dmaengine: ste_dma40: Supply macros to resolve
 'src' and 'dst' directions
In-Reply-To: <1366279934-30761-6-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-6-git-send-email-lee.jones@linaro.org>
Message-ID: <CACRpkdYD21VEHZ2825=e7PnATp-tfrL2rg4rKboG-Fq04U162A@mail.gmail.com>

On Thu, Apr 18, 2013 at 12:11 PM, Lee Jones <lee.jones at linaro.org> wrote:

> There are lots of lengthy if() statements located sporadically up and
> down the driver. This simple macro should make many of them a little
> simpler to decipher. The remainder have to stay in place, as they
> detail slightly more specific settings.
>
> Cc: Vinod Koul <vinod.koul at intel.com>
> Cc: Dan Williams <djbw at fb.com>
> Cc: Per Forlin <per.forlin at stericsson.com>
> Cc: Rabin Vincent <rabin at rab.in>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>
(...)

> +#define D40_IS_SRC(dir)  ((dir == STEDMA40_PERIPH_TO_MEM) ? true : false)

And when I reas the code and see D40_IS_SRC, what does that
mean? That the channel is a source of .. what exactly?

The older explicit comparison would be more informative.

> +#define D40_IS_DST(dir) (((dir == STEDMA40_MEM_TO_PERIPH) || \
> +                         (dir == STEDMA40_MEM_TO_MEM)) ? true : false)
> +

The comparison to STEDMA40_MEM_TO_MEM is unintelligible, if I see
that macro it has a very unintuitive name, since it is not just
DST but also SRC.

The latter macro would be named somthing like D40_IS_DST_OR_MEM2MEM
and then it will not simplify the code very much.

You need to come up with something different here, this is just making the
driver harder to understand.

I think this patch should be just dropped.

Yours,
Linus Walleij


From linus.walleij at linaro.org  Thu Apr 25 04:24:49 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Apr 2013 10:24:49 +0200
Subject: [PATCH 06/32] ARM: ux500: Strip out duplicate USB DMA
 configuration
In-Reply-To: <1366279934-30761-7-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-7-git-send-email-lee.jones@linaro.org>
Message-ID: <CACRpkdZ0WTSx814t_N72Mmb=qG+AtW92m2gFvRjg0DTOiQyQLQ@mail.gmail.com>

On Thu, Apr 18, 2013 at 12:11 PM, Lee Jones <lee.jones at linaro.org> wrote:

> For the moment at least, the TX and RX channels for DB8500 USB are
> identical, so this patch generalises them into a single structure
> and passes it twice. Once as the TX and again for the RX configuration.
> We're keeping the infrastructure the same i.e. passing the TX and RX
> separately in case they start to differ on latter incarnations of the
> platform.
>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>

Reviewed-by: Linus Walleij <linus.walleij at linaro.org>

Yours,
Linus Walleij


From linus.walleij at linaro.org  Thu Apr 25 04:26:56 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Apr 2013 10:26:56 +0200
Subject: [PATCH 07/32] ARM: ux500: Supply address location names for the
 DMA40 DMA controller
In-Reply-To: <1366279934-30761-8-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-8-git-send-email-lee.jones@linaro.org>
Message-ID: <CACRpkdbCMjC22WbgE_-Co-hvT704n696Ox8t_6_d2aoxmZyybA@mail.gmail.com>

On Thu, Apr 18, 2013 at 12:11 PM, Lee Jones <lee.jones at linaro.org> wrote:

> The DMA40 controller uses two sets of base addresses. In order to have
> them automatically setup as resources by the Open Format framework we
> have to set names for them. The names have to be the same as the ones
> used to fetch them back out of the resource structure.
>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>

This is OK with Arnds suggested changed, but I want the patch
split off from this series and put into a device-tree-specific patch
series so I can apply this to a branch where I try to keep
all patches to the device tree files. (ux500-devicetree).

Yours,
Linus Walleij


From linus.walleij at linaro.org  Thu Apr 25 04:36:19 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Apr 2013 10:36:19 +0200
Subject: [PATCH 08/32] dmaengine: ste_dma40: Optimise local MAX() macro
In-Reply-To: <1366279934-30761-9-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-9-git-send-email-lee.jones@linaro.org>
Message-ID: <CACRpkdZ9j8Xr2-m6KG_Uet6Hft8xx_WJkKUQpi9QwuoE=9H1NA@mail.gmail.com>

On Thu, Apr 18, 2013 at 12:11 PM, Lee Jones <lee.jones at linaro.org> wrote:

> The current implementation of the DMA40's local MAX() macro evaluates
> its arguments more times than is necessary. This patch strips it
> optimises it to only evaluate what's appropriate.
>
> Cc: Vinod Koul <vinod.koul at intel.com>
> Cc: Dan Williams <djbw at fb.com>
> Cc: Per Forlin <per.forlin at stericsson.com>
> Cc: Rabin Vincent <rabin at rab.in>
> Reported-by: Harvey Harrison <harvey.harrison at gmail.com>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>
(...)
> -#define MAX(a, b) (((a) < (b)) ? (b) : (a))
> +#define MAX(a, b) ((a > b) ? a : b)

Much has been said about this patch already, but notice what it is
used for instead, one single thing at compile-time:

struct d40_base {
(...)
        u32
reg_val_backup_v4[MAX(BACKUP_REGS_SZ_V4A, BACKUP_REGS_SZ_V4B)];
(...)
};

i.e. defining the size of that array at compile-time.

The actual size is figured out in d40_hw_detect_init().

So what about you just devm_kmalloc() that array instead and
delete this macro. That is the real fix.

Yours,
Linus Walleij


From arnd at arndb.de  Thu Apr 25 04:36:52 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 25 Apr 2013 10:36:52 +0200
Subject: [PATCH 04/32] dmaengine: ste_dma40: Amalgamate DMA source and
 destination channel numbers
In-Reply-To: <CACRpkdaauDYTdoBHGG9FO4kKqvCYyCrjY8EGWs5gAQWErGW6_A@mail.gmail.com>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-5-git-send-email-lee.jones@linaro.org>
 <CACRpkdaauDYTdoBHGG9FO4kKqvCYyCrjY8EGWs5gAQWErGW6_A@mail.gmail.com>
Message-ID: <201304251036.52284.arnd@arndb.de>

On Thursday 25 April 2013, Linus Walleij wrote:
> Are we now sacrificing that ability on the altar of simplification?
> 
> I actually think not, but that we should do periph-to-periph transfers
> in some other way, and that the .dir attribute should go away from
> the struct stedma40_chan_cfg as well but I'm not entirely sure.
> Someone else?

The dma-engine core has no support for device-to-device transfers,
and as far as I understand that is neither considered a useful
feature in real life, nor easy to add, so I don't think it matters
much here.

	Arnd


From linus.walleij at linaro.org  Thu Apr 25 04:44:23 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Apr 2013 10:44:23 +0200
Subject: [PATCH 09/32] ARM: ux500: Remove unused 'data_width' attributes
 from SDI DMA configs
In-Reply-To: <1366279934-30761-10-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-10-git-send-email-lee.jones@linaro.org>
Message-ID: <CACRpkdbf03ajQaYujGfimHE+hDVjNLycE3J9Q-W-tzN2EX0fkQ@mail.gmail.com>

On Thu, Apr 18, 2013 at 12:11 PM, Lee Jones <lee.jones at linaro.org> wrote:

> DMA configuration data is now allocated in the MMCI driver, so these
> are just ignored.
>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>

Reviewed-by: Linus Walleij <linus.walleij at linaro.org>

I tried just applying this (since it's pretty stand-alone) but seems to
be dependent on things not yet in Torvalds tree so lets keep it in this
series then...

Yours,
Linus Walleij


From linus.walleij at linaro.org  Thu Apr 25 04:45:04 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Apr 2013 10:45:04 +0200
Subject: [PATCH 10/32] ARM: ux500: Remove unused 'data_width' attributes
 from SSP DMA configs
In-Reply-To: <1366279934-30761-11-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-11-git-send-email-lee.jones@linaro.org>
Message-ID: <CACRpkdYtS9C1cSV7F62geEjUzvQUaMr_cHTrUhiAGoz9Ly98UA@mail.gmail.com>

On Thu, Apr 18, 2013 at 12:11 PM, Lee Jones <lee.jones at linaro.org> wrote:

> DMA configuration data is now allocated in the SSP driver, so these
> are just ignored.
>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>

Reviewed-by: Linus Walleij <linus.walleij at linaro.org>

Yours,
Linus Walleij


From linus.walleij at linaro.org  Thu Apr 25 04:45:47 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Apr 2013 10:45:47 +0200
Subject: [PATCH 11/32] ARM: ux500: Remove unused 'data_width' attributes
 from UART DMA configs
In-Reply-To: <1366279934-30761-12-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-12-git-send-email-lee.jones@linaro.org>
Message-ID: <CACRpkdZLEn9sui9H8CzrdO9YcxhsqBeU_6aqkWsPaR-=h9014A@mail.gmail.com>

On Thu, Apr 18, 2013 at 12:11 PM, Lee Jones <lee.jones at linaro.org> wrote:

> DMA configuration data is now allocated in the UART driver, so these
> are just ignored.
>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>

Reviewed-by: Linus Walleij <linus.walleij at linaro.org>

Yours,
Linus Walleij


From anup.patel at linaro.org  Thu Apr 25 04:45:34 2013
From: anup.patel at linaro.org (Anup Patel)
Date: Thu, 25 Apr 2013 14:15:34 +0530
Subject: [PATCH] ARM: KVM: Allow host virtual timer irq number to be different
 from guest virtual timer irq number
Message-ID: <1366879534-31578-1-git-send-email-anup.patel@linaro.org>

The arch_timer irq numbers (or PPI number) are implementation dependent so, the host virtual timer irq number can be different from guest virtual timer irq number.

Currently, we only have Cortex-A15 guest (for KVM ARMv7) and Cortex-A57 guest (for KVM ARMv8) supported. These guests have virtual timer irq number as 27.

This patch ensures that host virtual timer irq number is read from DTB and guest virtual timer irq is always 27.

Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar at linaro.org>
---
 arch/arm/kvm/arch_timer.c |   18 +++++++++++++-----
 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/arch/arm/kvm/arch_timer.c b/arch/arm/kvm/arch_timer.c
index 49a7516..376abf0 100644
--- a/arch/arm/kvm/arch_timer.c
+++ b/arch/arm/kvm/arch_timer.c
@@ -30,10 +30,18 @@
 
 static struct timecounter *timecounter;
 static struct workqueue_struct *wqueue;
-static struct kvm_irq_level timer_irq = {
+static struct kvm_irq_level host_timer_irq = {
 	.level	= 1,
 };
 
+/* Guest virtual timer irq number will be based on type of guest we emulate. 
+ * For Cortex-A15 & Cortex-A57 guest, virtual timer irq is 27
+ */
+static struct kvm_irq_level guest_timer_irq = {
+	.irq = 27,
+	.level = 1,
+};
+
 static cycle_t kvm_phys_timer_read(void)
 {
 	return timecounter->cc->read(timecounter->cc);
@@ -163,12 +171,12 @@ void kvm_timer_vcpu_init(struct kvm_vcpu *vcpu)
 	INIT_WORK(&timer->expired, kvm_timer_inject_irq_work);
 	hrtimer_init(&timer->timer, CLOCK_MONOTONIC, HRTIMER_MODE_ABS);
 	timer->timer.function = kvm_timer_expire;
-	timer->irq = &timer_irq;
+	timer->irq = &guest_timer_irq;
 }
 
 static void kvm_timer_init_interrupt(void *info)
 {
-	enable_percpu_irq(timer_irq.irq, 0);
+	enable_percpu_irq(host_timer_irq.irq, 0);
 }
 
 
@@ -182,7 +190,7 @@ static int kvm_timer_cpu_notify(struct notifier_block *self,
 		break;
 	case CPU_DYING:
 	case CPU_DYING_FROZEN:
-		disable_percpu_irq(timer_irq.irq);
+		disable_percpu_irq(host_timer_irq.irq);
 		break;
 	}
 
@@ -230,7 +238,7 @@ int kvm_timer_hyp_init(void)
 		goto out;
 	}
 
-	timer_irq.irq = ppi;
+	host_timer_irq.irq = ppi;
 
 	err = register_cpu_notifier(&kvm_timer_cpu_nb);
 	if (err) {
-- 
1.7.9.5



From will.deacon at arm.com  Thu Apr 25 04:47:11 2013
From: will.deacon at arm.com (Will Deacon)
Date: Thu, 25 Apr 2013 09:47:11 +0100
Subject: [PATCH v8 1/2] arm: introduce psci_smp_ops
In-Reply-To: <1366828819-10745-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1304241935010.4180@kaball.uk.xensource.com>
 <1366828819-10745-1-git-send-email-stefano.stabellini@eu.citrix.com>
Message-ID: <20130425084711.GA12848@mudshark.cambridge.arm.com>

Hi Stefano,

On Wed, Apr 24, 2013 at 07:40:18PM +0100, Stefano Stabellini wrote:
> Rename virt_smp_ops to psci_smp_ops and move them to arch/arm/kernel/psci_smp.c.
> Remove mach-virt/platsmp.c, now unused.
> Compile psci_smp if CONFIG_ARM_PSCI and CONFIG_SMP.
> 
> Add a cpu_die smp_op based on psci_ops.cpu_off.
> 
> Initialize PSCI before setting smp_ops in setup_arch.
> Use psci_smp_ops if the platform doesn't provide its own smp_ops.
> 
> If PSCI is available on the platform, prefer psci_smp_ops over the
> platform smp_ops.
> 
> Changes in v8:
> - merge "prefer psci_smp_ops over mdesc->smp" into this patch.
> 
> Changes in v6:
> - fixed return values for psci_smp_available and psci_init ifndef
> CONFIG_ARM_PSCI.
> 
> Changes in v5:
> - document psci_operations;
> - psci_init returns NULL.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
> ---
>  arch/arm/include/asm/psci.h  |   29 ++++++++++++++++++
>  arch/arm/kernel/Makefile     |    5 ++-
>  arch/arm/kernel/psci.c       |    7 ++--
>  arch/arm/kernel/psci_smp.c   |   67 ++++++++++++++++++++++++++++++++++++++++++
>  arch/arm/kernel/setup.c      |    7 ++++-
>  arch/arm/mach-virt/Makefile  |    1 -
>  arch/arm/mach-virt/platsmp.c |   58 ------------------------------------
>  arch/arm/mach-virt/virt.c    |    3 --
>  8 files changed, 109 insertions(+), 68 deletions(-)
>  create mode 100644 arch/arm/kernel/psci_smp.c
>  delete mode 100644 arch/arm/mach-virt/platsmp.c
> 
> diff --git a/arch/arm/include/asm/psci.h b/arch/arm/include/asm/psci.h
> index ce0dbe7..fa44417 100644
> --- a/arch/arm/include/asm/psci.h
> +++ b/arch/arm/include/asm/psci.h
> @@ -23,6 +23,26 @@ struct psci_power_state {
>  	u8	affinity_level;
>  };
>  
> +/*
> + * cpu_suspend   Suspend the execution on a CPU
> + * @state        we don't currently describe affinity levels, so just pass 0.
> + * @entry_point  the first instruction to be executed on return
> + * returns 0  success, < 0 on failure
> + *
> + * cpu_off       Power down a CPU
> + * @state        we don't currently describe affinity levels, so just pass 0.
> + * no return on successful call
> + *
> + * cpu_on        Power up a CPU
> + * @cpuid        cpuid of target CPU, as from MPIDR
> + * @entry_point  the first instruction to be executed on return
> + * returns 0  success, < 0 on failure
> + *
> + * migrate       Migrate the context to a different CPU
> + * @cpuid        cpuid of target CPU, as from MPIDR
> + * returns 0  success, < 0 on failure
> + *
> + */

Can you move these comments into psci-smp.c please? They're really specific
to the implementation there, and if we put them in a header we're lying to
ourselves about the parameters actually described by the PSCI specification.

With that change:

  Acked-by: Will Deacon <will.deacon at arm.com>

Will


From will.deacon at arm.com  Thu Apr 25 04:49:33 2013
From: will.deacon at arm.com (Will Deacon)
Date: Thu, 25 Apr 2013 09:49:33 +0100
Subject: [PATCH v8 2/2] ARM: Enable selection of SMP operations at boot
 time
In-Reply-To: <1366828819-10745-2-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1304241935010.4180@kaball.uk.xensource.com>
 <1366828819-10745-2-git-send-email-stefano.stabellini@eu.citrix.com>
Message-ID: <20130425084933.GB12848@mudshark.cambridge.arm.com>

On Wed, Apr 24, 2013 at 07:40:19PM +0100, Stefano Stabellini wrote:
> From: Jon Medhurst <tixy at linaro.org>
> 
> Add a new 'smp_init' hook to machine_desc so platforms can specify a
> function to be used to setup smp ops instead of having a statically
> defined value.  The hook must return true when smp_ops are initialized.
> If false the static mdesc->smp_ops will be used by default.
> 
> Signed-off-by: Jon Medhurst <tixy at linaro.org>
> Signed-off-by: Nicolas Pitre <nicolas.pitre at linaro.org>
> Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
> Reviewed-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
> ---
>  arch/arm/include/asm/mach/arch.h |    4 ++++
>  arch/arm/kernel/setup.c          |   10 ++++++----
>  2 files changed, 10 insertions(+), 4 deletions(-)

[...]

>  	if (is_smp()) {
> -		if (psci_smp_available())
> -			smp_set_ops(&psci_smp_ops);
> -		else if (mdesc->smp)
> -			smp_set_ops(mdesc->smp);
> +		if (!mdesc->smp_init || !mdesc->smp_init()) {

Minor nit, but this feels backwards to me. We usually return 0 on success,
yet we're saying here that if mdesc->smp_init() returns 0, then we go and
override the smp ops.

Will

> +			if (psci_smp_available())
> +				smp_set_ops(&psci_smp_ops);
> +			else if (mdesc->smp)
> +				smp_set_ops(mdesc->smp);
> +		}
>  		smp_init_cpus();
>  	}
>  #endif
> -- 
> 1.7.2.5
> 
> 


From will.deacon at arm.com  Thu Apr 25 04:54:53 2013
From: will.deacon at arm.com (Will Deacon)
Date: Thu, 25 Apr 2013 09:54:53 +0100
Subject: [PATCH v4 7/7] mach-virt: support Xen hypercalls for shutdown
 and reboot
In-Reply-To: <alpine.DEB.2.02.1304242301390.4180@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1304242012590.4180@kaball.uk.xensource.com>
 <1366831695-13214-7-git-send-email-stefano.stabellini@eu.citrix.com>
 <alpine.DEB.2.02.1304242301390.4180@kaball.uk.xensource.com>
Message-ID: <20130425085452.GC12848@mudshark.cambridge.arm.com>

On Wed, Apr 24, 2013 at 11:14:28PM +0100, Stefano Stabellini wrote:
> On Wed, 24 Apr 2013, Stefano Stabellini wrote:
> > Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
> > CC: Marc Zyngier <marc.zyngier at arm.com>
> > CC: will.deacon at arm.com
> > CC: arnd at arndb.de
> > CC: rob.herring at calxeda.com
> 
> Thinking twice about this patch, a less intrusive alternative would be
> to set arm_pm_restart and pm_power_off to two xen specific functions
> later on from xen_guest_init.

Yes please. We'd like to remove mach-virt/* some day.

Will


From linus.walleij at linaro.org  Thu Apr 25 04:55:46 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Apr 2013 10:55:46 +0200
Subject: [PATCH 04/32] dmaengine: ste_dma40: Amalgamate DMA source and
 destination channel numbers
In-Reply-To: <201304251036.52284.arnd@arndb.de>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-5-git-send-email-lee.jones@linaro.org>
 <CACRpkdaauDYTdoBHGG9FO4kKqvCYyCrjY8EGWs5gAQWErGW6_A@mail.gmail.com>
 <201304251036.52284.arnd@arndb.de>
Message-ID: <CACRpkdY96CKOtE6ByMuz_RAkyOY44RSrfz6Z3OFV6pcFTK3KwQ@mail.gmail.com>

On Thu, Apr 25, 2013 at 10:36 AM, Arnd Bergmann <arnd at arndb.de> wrote:
> On Thursday 25 April 2013, Linus Walleij wrote:
>> Are we now sacrificing that ability on the altar of simplification?
>>
>> I actually think not, but that we should do periph-to-periph transfers
>> in some other way, and that the .dir attribute should go away from
>> the struct stedma40_chan_cfg as well but I'm not entirely sure.
>> Someone else?
>
> The dma-engine core has no support for device-to-device transfers,

It has this: DMA_DEV_TO_DEV (enum dma_transfer_direction)
so it has been thought of. Alas, it is unused for now.

> and as far as I understand that is neither considered a useful
> feature in real life, nor easy to add, so I don't think it matters
> much here.

It is a very useful feature in real life, we used that for PCM transfer
in U300. (I have heard this from other handset vendors too, so it
is a common thing.)

Consider a high-speed on-chip link from a
modem providing audio in (telephony) from the microphone in
one endpoint and audio out on another endpoint.

We just set that up so we connect a hose from the modem
RX to the PCM sink (D/A-codec) and vice versa as long as
the phone conversation is on.

This gives outstanding power performance since the CPU itself
can actually sleep during the enture voicecall, only the DMA
engine if awake.

We just never got around to modifying the DMAengine framework
to support this and integrate it... it is bound to come back to us,
especially with things like ever more accelerators on chips that
provide such autonomous data streams. (I think.)

Yours,
Linus Walleij


From lorenzo.pieralisi at arm.com  Thu Apr 25 04:59:27 2013
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Thu, 25 Apr 2013 09:59:27 +0100
Subject: [RFC PATCH v3 07/17] ARM: dts: imx: cpus/cpu nodes dts updates
In-Reply-To: <20130425054426.GG1389@S2101-09.ap.freescale.net>
References: <1366824502-19729-1-git-send-email-lorenzo.pieralisi@arm.com>
 <1366824502-19729-8-git-send-email-lorenzo.pieralisi@arm.com>
 <20130425054426.GG1389@S2101-09.ap.freescale.net>
Message-ID: <20130425085926.GA25870@e102568-lin.cambridge.arm.com>

On Thu, Apr 25, 2013 at 06:44:28AM +0100, Shawn Guo wrote:
> On Wed, Apr 24, 2013 at 06:28:12PM +0100, Lorenzo Pieralisi wrote:
> > This patch updates the in-kernel dts files according to the latest cpus
> > and cpu bindings updates for ARM.
> > 
> > Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
> > ---
> >  arch/arm/boot/dts/imx23.dtsi  | 8 ++++++--
> >  arch/arm/boot/dts/imx28.dtsi  | 8 ++++++--
> >  arch/arm/boot/dts/imx6dl.dtsi | 2 ++
> >  arch/arm/boot/dts/imx6q.dtsi  | 1 +
> >  4 files changed, 15 insertions(+), 4 deletions(-)
> > 
> > diff --git a/arch/arm/boot/dts/imx23.dtsi b/arch/arm/boot/dts/imx23.dtsi
> > index 56afcf4..0aae18b 100644
> > --- a/arch/arm/boot/dts/imx23.dtsi
> > +++ b/arch/arm/boot/dts/imx23.dtsi
> > @@ -23,8 +23,12 @@
> >  	};
> >  
> >  	cpus {
> > -		cpu at 0 {
> > -			compatible = "arm,arm926ejs";
> > +		#address-cells = <0>;
> > +		#size-cells = <0>;
> > +
> > +		cpu {
> > +			compatible = "arm,arm926ej-s";
> > +			device_type = "cpu";
> >  		};
> >  	};
> >  
> > diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
> > index 7ba4966..07f131fc 100644
> > --- a/arch/arm/boot/dts/imx28.dtsi
> > +++ b/arch/arm/boot/dts/imx28.dtsi
> > @@ -32,8 +32,12 @@
> >  	};
> >  
> >  	cpus {
> > -		cpu at 0 {
> > -			compatible = "arm,arm926ejs";
> > +		#address-cells = <0>;
> > +		#size-cells = <0>;
> > +
> > +		cpu {
> > +			compatible = "arm,arm926ej-s";
> > +			device_type = "cpu";
> >  		};
> >  	};
> >  
> > diff --git a/arch/arm/boot/dts/imx6dl.dtsi b/arch/arm/boot/dts/imx6dl.dtsi
> > index 63fafe2..b76d85e 100644
> > --- a/arch/arm/boot/dts/imx6dl.dtsi
> > +++ b/arch/arm/boot/dts/imx6dl.dtsi
> > @@ -16,12 +16,14 @@
> >  
> >  		cpu at 0 {
> >  			compatible = "arm,cortex-a9";
> > +			device_type = "cpu";
> >  			reg = <0>;
> >  			next-level-cache = <&L2>;
> >  		};
> >  
> >  		cpu at 1 {
> >  			compatible = "arm,cortex-a9";
> > +			device_type = "cpu";
> >  			reg = <1>;
> >  			next-level-cache = <&L2>;
> >  		};
> > diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
> > index cba021e..65c1b62 100644
> > --- a/arch/arm/boot/dts/imx6q.dtsi
> > +++ b/arch/arm/boot/dts/imx6q.dtsi
> > @@ -17,6 +17,7 @@
> >  
> >  		cpu at 0 {
> >  			compatible = "arm,cortex-a9";
> > +			device_type = "cpu";
> 
> Shouldn't this line be added for cpu at 1, cpu at 2 and cpu at 3 too?  Other than
> that,

Yes, you are right, fixed. Thanks for reviewing.

Lorenzo

> 
> Acked-by: Shawn Guo <shawn.guo at linaro.org>
> 
> >  			reg = <0>;
> >  			next-level-cache = <&L2>;
> >  			operating-points = <
> > -- 
> > 1.7.12
> > 
> > 
> 
> 



From linus.walleij at linaro.org  Thu Apr 25 05:00:22 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Apr 2013 11:00:22 +0200
Subject: [PATCH 12/32] ARM: ux500: Remove superfluous 'psize' attribute
 from Audio platform data
In-Reply-To: <1366279934-30761-13-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-13-git-send-email-lee.jones@linaro.org>
Message-ID: <CACRpkdbu-e75rz+BgbfFH7nXMWMTzpFT=k2yhA80jJKv9jpzkQ@mail.gmail.com>

On Thu, Apr 18, 2013 at 12:11 PM, Lee Jones <lee.jones at linaro.org> wrote:

> 'psize' is used to calculate the maximum DMA burst size. However it
> is only taken into consideration when editing the DMA channel's
> configuration. The Audio DMA platform data is only used to allocate
> a channel, not configure it. That will be done at a later date within
> the MSP driver.
>
> We're also removing comments which are no longer required, as
> 'data_width' is no longer set in any device's platform data period.
>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>

Pls CC patches like this to Ola LILJA.

So if I understand correctly this is now handled by
dmaengine_pcm.c, os that right?

Yours,
Linus Walleij


From balbi at ti.com  Thu Apr 25 05:04:47 2013
From: balbi at ti.com (Felipe Balbi)
Date: Thu, 25 Apr 2013 12:04:47 +0300
Subject: Multiple issues with omap4 panda es in linux next
In-Reply-To: <20130424192330.GC5184@atomide.com>
References: <20130419171318.GK10155@atomide.com> <5174F7A8.7070308@ti.com>
 <20130422180316.GA10155@atomide.com> <5176A45B.5@ti.com>
 <20130423172353.GD10155@atomide.com>
 <20130423213151.GM10155@atomide.com>
 <20130423231605.GO10155@atomide.com> <517770A0.4000609@ti.com>
 <20130424190821.GB5184@atomide.com>
 <20130424192330.GC5184@atomide.com>
Message-ID: <20130425090447.GK7889@arwen.pp.htv.fi>

Hi,

On Wed, Apr 24, 2013 at 12:23:30PM -0700, Tony Lindgren wrote:
> * Tony Lindgren <tony at atomide.com> [130424 12:13]:
> > * Kishon Vijay Abraham I <kishon at ti.com> [130423 22:46]:
> > > Hi Tony,
> > > 
> > > On Wednesday 24 April 2013 04:46 AM, Tony Lindgren wrote:
> > > >* Tony Lindgren <tony at atomide.com> [130423 14:37]:
> > > >>* Tony Lindgren <tony at atomide.com> [130423 10:28]:
> > > >>>* Kishon Vijay Abraham I <kishon at ti.com> [130423 08:15]:
> > > >>>>>>>2. MUSB fails with legacy booting and DT on panda es
> > > >>>>>>>
> > > >>>>>>>With both legacy and DT booting I get something like:
> > > >>>>>>>
> > > >>>>>>>HS USB OTG: no transceiver configured
> > > >>>>>>>musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with status -517
> > > >>>>>>
> > > >>>>>>The dt should work fine with https://patchwork.kernel.org/patch/2423061/.
> > > >>>>>
> > > >>>>>OK thanks for checking that.
> > > >
> > > >Kishon, I think there's also some other issue remaining
> > > >in linux next with MUSB and DT. I'm still getting the
> > > >"HS USB OTG: no transceiver configured" although the nop
> > > >xceiv is compiled in. Maybe give it a try against linux
> > > >next?
> > > 
> > > For OMAP4 MUSB, you'll need omap-usb2 phy. I've attached my .config.
> > 
> > Thanks your config helped me to track it down. Looks like I got
> > the PHYs the wrong way around between EHCI and MUSB..
> > 
> > In any case, I did have omap-usb2 compiled in, but I did not have
> > OMAP_OCP2SCP=y set. Should OMAP_USB2 depend on that?
> > 
> > Also, looks like MUSB just sits in b_idle mode though, so no more
> > ID pin interrupt for some reason.
> 
> OK looks like I got the ID interrupt going by enabling
> CONFIG_TWL6030_USB=y. Still stays in a_idle with no keyboard
> after plugging it in, but now changes between a and b mode.

come again, you ground ID pin and have no devices attached ? Then it
should stay in a_idle.

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130425/c2074be5/attachment-0001.sig>

From lee.jones at linaro.org  Thu Apr 25 05:06:12 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Thu, 25 Apr 2013 10:06:12 +0100
Subject: [PATCH 04/32] dmaengine: ste_dma40: Amalgamate DMA source and
 destination channel numbers
In-Reply-To: <CACRpkdaauDYTdoBHGG9FO4kKqvCYyCrjY8EGWs5gAQWErGW6_A@mail.gmail.com>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-5-git-send-email-lee.jones@linaro.org>
 <CACRpkdaauDYTdoBHGG9FO4kKqvCYyCrjY8EGWs5gAQWErGW6_A@mail.gmail.com>
Message-ID: <20130425090612.GC4623@gmail.com>

> > Devices which utilise DMA tend to use the same channel numbers for
> > transmitting and receiving. For this reason and the fact that it'll
> > decrease the burden of platform data passed to each device, we're
> > amalgamating source and destination device types.
> 
> I don't think this explains what the patch is actually doing.
> 
> Instead describe this:
> 
> > @@ -56,8 +54,7 @@ static struct stedma40_chan_cfg msp1_dma_rx = {
> >         .high_priority = true,
> >         .dir = STEDMA40_PERIPH_TO_MEM,
> >
> > -       .src_dev_type = DB8500_DMA_DEV30_MSP3_RX,
> > -       .dst_dev_type = STEDMA40_DEV_DST_MEMORY,
> > +       .dev_type = DB8500_DMA_DEV30_MSP3,
> (...)
> 
> What the message should say is that we're encoding pairs of
> information for sources and destinations. Since every such
> entry contains a .dir entry stating the direction of the transfer
> it is implicit whether the channel is for RX or TX and this is what
> you're exploiting in this patch.
> 
> So channel numbers (as mentioned in the commit) is not
> the key issue here.

Channel numbers should really be device types in the commit
message. I'll expand using your explanation too though.

> Now we should ask ourselves why it was done like this from
> the beginning. The reason is that DMA40 supports device-to-device
> DMA, so if you encoded one device in .src_dev_type and another
> device in .dst_dev_type and set .dir to
> STEDMA40_PERIPH_TO_PERIPH (which as you can see is
> defined in <linux/platform_data/dma-ste-dma40.h>) you get a
> device to device transfer.
> 
> Are we now sacrificing that ability on the altar of simplification?
>
> I actually think not, but that we should do periph-to-periph transfers
> in some other way, and that the .dir attribute should go away from
> the struct stedma40_chan_cfg as well but I'm not entirely sure.
> Someone else?

Although the DMA40 device supports device-to-device transfers, Linux
does not, so this subject is moot AFAICT.

> (...)
> > +++ b/arch/arm/mach-ux500/cpu-db8500.c
> > @@ -167,25 +167,25 @@ static void __init db8500_add_gpios(struct device *parent)
> >  }
> >
> >  static int usb_db8500_rx_dma_cfg[] = {
> > -       DB8500_DMA_DEV38_USB_OTG_IEP_1_9,
> > -       DB8500_DMA_DEV37_USB_OTG_IEP_2_10,
> > -       DB8500_DMA_DEV36_USB_OTG_IEP_3_11,
> > -       DB8500_DMA_DEV19_USB_OTG_IEP_4_12,
> > -       DB8500_DMA_DEV18_USB_OTG_IEP_5_13,
> > -       DB8500_DMA_DEV17_USB_OTG_IEP_6_14,
> > -       DB8500_DMA_DEV16_USB_OTG_IEP_7_15,
> > -       DB8500_DMA_DEV39_USB_OTG_IEP_8
> > +       DB8500_DMA_DEV38_USB_OTG_IEP_AND_OEP_1_9,
> > +       DB8500_DMA_DEV37_USB_OTG_IEP_AND_OEP_2_10,
> > +       DB8500_DMA_DEV36_USB_OTG_IEP_AND_OEP_3_11,
> > +       DB8500_DMA_DEV19_USB_OTG_IEP_AND_OEP_4_12,
> > +       DB8500_DMA_DEV18_USB_OTG_IEP_AND_OEP_5_13,
> > +       DB8500_DMA_DEV17_USB_OTG_IEP_AND_OEP_6_14,
> > +       DB8500_DMA_DEV16_USB_OTG_IEP_AND_OEP_7_15,
> > +       DB8500_DMA_DEV39_USB_OTG_IEP_AND_OEP_8
> >  };
> >
> >  static int usb_db8500_tx_dma_cfg[] = {
> > -       DB8500_DMA_DEV38_USB_OTG_OEP_1_9,
> > -       DB8500_DMA_DEV37_USB_OTG_OEP_2_10,
> > -       DB8500_DMA_DEV36_USB_OTG_OEP_3_11,
> > -       DB8500_DMA_DEV19_USB_OTG_OEP_4_12,
> > -       DB8500_DMA_DEV18_USB_OTG_OEP_5_13,
> > -       DB8500_DMA_DEV17_USB_OTG_OEP_6_14,
> > -       DB8500_DMA_DEV16_USB_OTG_OEP_7_15,
> > -       DB8500_DMA_DEV39_USB_OTG_OEP_8
> > +       DB8500_DMA_DEV38_USB_OTG_IEP_AND_OEP_1_9,
> > +       DB8500_DMA_DEV37_USB_OTG_IEP_AND_OEP_2_10,
> > +       DB8500_DMA_DEV36_USB_OTG_IEP_AND_OEP_3_11,
> > +       DB8500_DMA_DEV19_USB_OTG_IEP_AND_OEP_4_12,
> > +       DB8500_DMA_DEV18_USB_OTG_IEP_AND_OEP_5_13,
> > +       DB8500_DMA_DEV17_USB_OTG_IEP_AND_OEP_6_14,
> > +       DB8500_DMA_DEV16_USB_OTG_IEP_AND_OEP_7_15,
> > +       DB8500_DMA_DEV39_USB_OTG_IEP_AND_OEP_8
> >  };
> 
> 
> If you're doing this change, and after this RX and TX has no semantical
> meaning for these lists, join these two config lists
> into one.

I agree. See patch: ARM: ux500: Strip out duplicate USB DMA configuration

> (...)
> > diff --git a/arch/arm/mach-ux500/usb.c b/arch/arm/mach-ux500/usb.c
> >  static u32 d40_chan_has_events(struct d40_chan *d40c)
> > @@ -1744,8 +1740,6 @@ static int d40_validate_conf(struct d40_chan *d40c,
> >                              struct stedma40_chan_cfg *conf)
> >  {
> >         int res = 0;
> > -       u32 dst_event_group = D40_TYPE_TO_GROUP(conf->dst_dev_type);
> > -       u32 src_event_group = D40_TYPE_TO_GROUP(conf->src_dev_type);
> 
> Please explain why this is not important to check anymore, I'm not
> following.
> 
> >         if (conf->dir == STEDMA40_MEM_TO_PERIPH &&
> > -           dst_event_group == STEDMA40_DEV_DST_MEMORY) {
> > -               chan_err(d40c, "Invalid dst\n");
> > +           d40c->base->plat_data->dev_tx[conf->dev_type] == 0 &&
> > +           d40c->runtime_addr == 0) {
> > +               chan_err(d40c, "Invalid TX channel address (%d)\n",
> > +                        conf->dev_type);
> 
> Like here. We are checking for inconsistency between group
> and channel direction, why is it no longer important to check this?

I'm not entirely sure how this ever worked:

  #define D40_TYPE_TO_GROUP(type) (type / 16)
  #define STEDMA40_DEV_DST_MEMORY (-1)

  (dev_type / 16) == -1

What number would dev_type have to be for this to be true? -16?

> >         if (conf->dir == STEDMA40_PERIPH_TO_MEM &&
> > -           src_event_group == STEDMA40_DEV_SRC_MEMORY) {
> > -               chan_err(d40c, "Invalid src\n");
> > -               res = -EINVAL;
> > -       }

As above.

> > -       if (src_event_group == STEDMA40_DEV_SRC_MEMORY &&
> > -           dst_event_group == STEDMA40_DEV_DST_MEMORY && is_log) {
> > -               chan_err(d40c, "No event line\n");
> > -               res = -EINVAL;
> > -       }

We still check for this.

> > -       if (conf->dir == STEDMA40_PERIPH_TO_PERIPH &&
> > -           (src_event_group != dst_event_group)) {
> > -               chan_err(d40c, "Invalid event group\n");
> > +           d40c->base->plat_data->dev_rx[conf->dev_type] == 0 &&
> > +           d40c->runtime_addr == 0) {
> > +               chan_err(d40c, "Invalid RX channel address (%d)\n",
> > +                        conf->dev_type);
> 
> Same here.

I stopped all 'dev_src/dev_dest' comparisons, as there is only 'dev' now.

> (...)
> > @@ -2062,7 +2035,7 @@ static int d40_free_dma(struct d40_chan *d40c)
> >  {
> >
> >         int res = 0;
> > -       u32 event;
> > +       u32 event = D40_TYPE_TO_EVENT(d40c->dma_cfg.dev_type);
> >         struct d40_phy_res *phy = d40c->phy_chan;
> >         bool is_src;
> >
> > @@ -2081,13 +2054,11 @@ static int d40_free_dma(struct d40_chan *d40c)
> >         }
> >
> >         if (d40c->dma_cfg.dir == STEDMA40_MEM_TO_PERIPH ||
> > -           d40c->dma_cfg.dir == STEDMA40_MEM_TO_MEM) {
> > -               event = D40_TYPE_TO_EVENT(d40c->dma_cfg.dst_dev_type);
> > +           d40c->dma_cfg.dir == STEDMA40_MEM_TO_MEM)
> 
> Why did you just stop checking dma_cfg.dir for == STEDMA40_MEM_TO_MEM
> above?

That's not what this is doing. STEDMA40_MEM_TO_MEM is still there.

This patch is doing this:

+       u32 event = D40_TYPE_TO_EVENT(d40c->dma_cfg.dev_type);
<snip>
-       event = D40_TYPE_TO_EVENT(d40c->dma_cfg.dst_dev_type);
-       event = D40_TYPE_TO_EVENT(d40c->dma_cfg.src_dev_type);

> And why is dma_cfg.dir suddenly hardcoded to MEM_TO_MEM??

It's not. Look again. :)

> This seems like a totally unrelated change and should it be done
> it need to be a separate patch with a separate explanation
> AFAICT.
> 
> This seems to happen in some other places too,

If you could point those out, I'll re-evaluate, or explain.

> and I find it
> very hard to follow the changes here ... can you please consider
> splitting the changes to groups and types semantics into a separate
> patch?

Can you read the patch again and reconsider please?

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From lorenzo.pieralisi at arm.com  Thu Apr 25 05:09:32 2013
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Thu, 25 Apr 2013 10:09:32 +0100
Subject: [RFC PATCH v3 02/17] Documentation: devicetree: arm: cpus/cpu
 nodes bindings updates
In-Reply-To: <20130424195820.GM4998@game.jcrosoft.org>
References: <1366824502-19729-1-git-send-email-lorenzo.pieralisi@arm.com>
 <1366824502-19729-3-git-send-email-lorenzo.pieralisi@arm.com>
 <20130424195820.GM4998@game.jcrosoft.org>
Message-ID: <20130425090931.GB25870@e102568-lin.cambridge.arm.com>

On Wed, Apr 24, 2013 at 08:58:20PM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:

[...]

> > +     - compatible:
> > +             Usage: required
> > +             Value type: <string>
> > +             Definition: should be one of:
> > +                         "arm,arm710t"
> > +                         "arm,arm720t"
> > +                         "arm,arm740t"
> > +                         "arm,arm7ej-s"
> > +                         "arm,arm7tdmi"
> > +                         "arm,arm7tdmi-s"
> > +                         "arm,arm9es"
> > +                         "arm,arm9ej-s"
> > +                         "arm,arm920t"
> > +                         "arm,arm922t"
> > +                         "arm,arm925"
> > +                         "arm,arm926e-s"
> > +                         "arm,arm926ej-s"
> > +                         "arm,arm940t"
> > +                         "arm,arm946e-s"
> > +                         "arm,arm966e-s"
> > +                         "arm,arm968e-s"
> > +                         "arm,arm9tdmi"
> > +                         "arm,arm1020e"
> > +                         "arm,arm1020t"
> > +                         "arm,arm1022e"
> > +                         "arm,arm1026ej-s"
> the common name is arm926ejs / arm1026ejs & co

The TRMs names are arm926ej-s/arm1026ej-s/... and other machs are using that
nomenclature already in dts files, time to consolidate.

Lorenzo



From linus.walleij at linaro.org  Thu Apr 25 05:13:16 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Apr 2013 11:13:16 +0200
Subject: [PATCH 13/32] dmaengine: ste_dma40: Calculate number of logical
 channels from physical ones
In-Reply-To: <1366279934-30761-14-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-14-git-send-email-lee.jones@linaro.org>
Message-ID: <CACRpkdYq9QLRaaysc=izGgi53ogf1oRHuCwWKW+rQBbE_UtfnA@mail.gmail.com>

On Thu, Apr 18, 2013 at 12:11 PM, Lee Jones <lee.jones at linaro.org> wrote:

> This change will cost ~25KB of memory, but it's worth the trade-off,
> as it removes a great deal of overhead. It means that instead of only
> allocating memory for the logical channels in use, it does so for all
> available ones, which is 32 per physical channel. However, this now
> means we can remove some platform data and we don't have to worry
> about adding vendor specific variables to Device Tree.
>
> Cc: Vinod Koul <vinod.koul at intel.com>
> Cc: Dan Williams <djbw at fb.com>
> Cc: Per Forlin <per.forlin at stericsson.com>
> Cc: Rabin Vincent <rabin at rab.in>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>

(...)
>  static struct stedma40_platform_data dma40_plat_data = {
> -       .dev_len = DB8500_DMA_NR_DEV,

So that was set to 64 in the platform...

> -       /* Count the number of logical channels in use */
> -       for (i = 0; i < plat_data->dev_len; i++)
> -               if (plat_data->dev_rx[i] != 0)
> -                       num_log_chans++;
> -
> -       for (i = 0; i < plat_data->dev_len; i++)
> -               if (plat_data->dev_tx[i] != 0)
> -                       num_log_chans++;

And I guess this code snippet made it go down to <= 32 all the time,
correct?

Just want to understand it before I ACK. (The idea is sound.)

I notice there is no check whatsoever of the bounds of
plat_data->dev_[rx|tx]  but that is a different problem I guess...

Yours,
Linus Walleij


From t.figa at samsung.com  Thu Apr 25 05:13:11 2013
From: t.figa at samsung.com (Tomasz Figa)
Date: Thu, 25 Apr 2013 11:13:11 +0200
Subject: [PATCH] ARM: dts: add pinctrl nodes for Exynos5250 SoC
In-Reply-To: <CA+Ln22EafDes5Lrvpwg08HnyNRuo=Z2uHAg6VJDMjNon9=E_qQ@mail.gmail.com>
References: <1355403978-388-1-git-send-email-thomas.abraham@linaro.org>
 <20130424233348.GA6603@quad.lixom.net>
 <CA+Ln22EafDes5Lrvpwg08HnyNRuo=Z2uHAg6VJDMjNon9=E_qQ@mail.gmail.com>
Message-ID: <1915783.V1ojdPclI6@amdc1227>

Oh screw that mobile GMail - seems like it now always sends plain + HTML...

Resending the post from a mail client working properly:

On Thursday 25 of April 2013 10:47:21 Tomasz Figa wrote:

Hi Olof,

W dniu czwartek, 25 kwietnia 2013 u?ytkownik Olof Johansson <olof at lixom.net> 
napisa?:
> On Thu, Dec 13, 2012 at 06:36:18PM +0530, Thomas Abraham wrote:
>> Add pinctrl device nodes for Exynos5250 SoC.
>>
>> Signed-off-by: Thomas Abraham <thomas.abraham at linaro.org>
>
> Replying to an old email of a patch that has been merged because it seems
> horribly broken.
>

As far as I can see in Kgene's tree, newer version of this patch has been 
merged.

I managed to already found a typo in that new version, though. The pinctrl2 
block is located at 0x3860000 not 0x3680000, or at least this is what the 
manual says.

>
>> diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
b/arch/arm/boot/dts/exynos5250.dtsi
>> index 581e57a..eb8d610 100644
>> --- a/arch/arm/boot/dts/exynos5250.dtsi
>> +++ b/arch/arm/boot/dts/exynos5250.dtsi
>> @@ -18,6 +18,7 @@
>>  */
>>
>>  /include/ "skeleton.dtsi"
>> +/include/ "exynos5250-pinctrl.dtsi"
>>
>>  / {
>>       compatible = "samsung,exynos5250";
>> @@ -48,6 +49,8 @@
>>               mshc1 = &dwmmc_1;
>>               mshc2 = &dwmmc_2;
>>               mshc3 = &dwmmc_3;
>> +             pinctrl0 = &pinctrl_0;
>> +             pinctrl3 = &pinctrl_3;
>>       };
>>
>>       gic:interrupt-controller at 10481000 {
>> @@ -79,6 +82,24 @@
>>               interrupts = <0 42 0>;
>>       };
>>
>> +     pinctrl_0: pinctrl at 11400000 {
>> +             compatible = "samsung,pinctrl-exynos5250";
>> +             reg = <0x11400000 0x1000>;
>> +             interrupts = <0 46 0>;
>> +
>> +             wakup_eint: wakeup-interrupt-controller {
>> +                     compatible = "samsung,exynos4210-wakeup-eint";
>> +                     interrupt-parent = <&gic>;
>> +                     interrupts = <0 32 0>;
>> +             };
>
> Typo, should be "wakeup_eint". And what happened to #interrupt-cells? And 
the
> interrupt map?
>
> Do you have an example of a tested user or a testcase for this? I'm
> trying to get interrupts going on these pins, and it's not looking like
> it's even close to working.

I have extensively tested interrupt handling in pinctrl-driver when reworking 
it. Testing was done on Exynos4210 and Exynos4412, but Exynos5250 seems to 
follow exactly the same design of pinctrl block.

Could you specify a bit more precisely what is your use case (GPIO pin, 
driver, device tree node of interrupt user, etc.)?

Best regards,
-- 
Tomasz Figa
Samsung Poland R&D Center
SW Solution Development, Kernel and System Framework



From lee.jones at linaro.org  Thu Apr 25 05:14:28 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Thu, 25 Apr 2013 10:14:28 +0100
Subject: [PATCH 09/32] ARM: ux500: Remove unused 'data_width' attributes
 from SDI DMA configs
In-Reply-To: <CACRpkdbf03ajQaYujGfimHE+hDVjNLycE3J9Q-W-tzN2EX0fkQ@mail.gmail.com>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-10-git-send-email-lee.jones@linaro.org>
 <CACRpkdbf03ajQaYujGfimHE+hDVjNLycE3J9Q-W-tzN2EX0fkQ@mail.gmail.com>
Message-ID: <20130425091428.GD4623@gmail.com>

On Thu, 25 Apr 2013, Linus Walleij wrote:

> On Thu, Apr 18, 2013 at 12:11 PM, Lee Jones <lee.jones at linaro.org> wrote:
> 
> > DMA configuration data is now allocated in the MMCI driver, so these
> > are just ignored.
> >
> > Signed-off-by: Lee Jones <lee.jones at linaro.org>
> 
> Reviewed-by: Linus Walleij <linus.walleij at linaro.org>
> 
> I tried just applying this (since it's pretty stand-alone) but seems to
> be dependent on things not yet in Torvalds tree so lets keep it in this
> series then...

Ideally I'd like to keep them all in the same branch, as it may lead
to confusion/conflicts later down the line (I'm still coding a lot of
this stuff).

Naturally, I'll go with whatever you think is best, but this is my
preference. 

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From lee.jones at linaro.org  Thu Apr 25 05:15:44 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Thu, 25 Apr 2013 10:15:44 +0100
Subject: [PATCH 08/32] dmaengine: ste_dma40: Optimise local MAX() macro
In-Reply-To: <CACRpkdZ9j8Xr2-m6KG_Uet6Hft8xx_WJkKUQpi9QwuoE=9H1NA@mail.gmail.com>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-9-git-send-email-lee.jones@linaro.org>
 <CACRpkdZ9j8Xr2-m6KG_Uet6Hft8xx_WJkKUQpi9QwuoE=9H1NA@mail.gmail.com>
Message-ID: <20130425091544.GE4623@gmail.com>

On Thu, 25 Apr 2013, Linus Walleij wrote:

> On Thu, Apr 18, 2013 at 12:11 PM, Lee Jones <lee.jones at linaro.org> wrote:
> 
> > The current implementation of the DMA40's local MAX() macro evaluates
> > its arguments more times than is necessary. This patch strips it
> > optimises it to only evaluate what's appropriate.
> >
> > Cc: Vinod Koul <vinod.koul at intel.com>
> > Cc: Dan Williams <djbw at fb.com>
> > Cc: Per Forlin <per.forlin at stericsson.com>
> > Cc: Rabin Vincent <rabin at rab.in>
> > Reported-by: Harvey Harrison <harvey.harrison at gmail.com>
> > Signed-off-by: Lee Jones <lee.jones at linaro.org>
> (...)
> > -#define MAX(a, b) (((a) < (b)) ? (b) : (a))
> > +#define MAX(a, b) ((a > b) ? a : b)
> 
> Much has been said about this patch already, but notice what it is
> used for instead, one single thing at compile-time:
> 
> struct d40_base {
> (...)
>         u32
> reg_val_backup_v4[MAX(BACKUP_REGS_SZ_V4A, BACKUP_REGS_SZ_V4B)];
> (...)
> };
> 
> i.e. defining the size of that array at compile-time.
> 
> The actual size is figured out in d40_hw_detect_init().
> 
> So what about you just devm_kmalloc() that array instead and
> delete this macro. That is the real fix.

I'm happy to do it, but please see v2 of this patch first.

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From lee.jones at linaro.org  Thu Apr 25 05:17:44 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Thu, 25 Apr 2013 10:17:44 +0100
Subject: [PATCH 07/32] ARM: ux500: Supply address location names for the
 DMA40 DMA controller
In-Reply-To: <CACRpkdbCMjC22WbgE_-Co-hvT704n696Ox8t_6_d2aoxmZyybA@mail.gmail.com>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-8-git-send-email-lee.jones@linaro.org>
 <CACRpkdbCMjC22WbgE_-Co-hvT704n696Ox8t_6_d2aoxmZyybA@mail.gmail.com>
Message-ID: <20130425091744.GF4623@gmail.com>

On Thu, 25 Apr 2013, Linus Walleij wrote:

> On Thu, Apr 18, 2013 at 12:11 PM, Lee Jones <lee.jones at linaro.org> wrote:
> 
> > The DMA40 controller uses two sets of base addresses. In order to have
> > them automatically setup as resources by the Open Format framework we
> > have to set names for them. The names have to be the same as the ones
> > used to fetch them back out of the resource structure.
> >
> > Signed-off-by: Lee Jones <lee.jones at linaro.org>
> 
> This is OK with Arnds suggested changed, but I want the patch
> split off from this series and put into a device-tree-specific patch
> series so I can apply this to a branch where I try to keep
> all patches to the device tree files. (ux500-devicetree).

Do you want to take this one separately?

Feel free and I'll remove it from this set.

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From linus.walleij at linaro.org  Thu Apr 25 05:17:53 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Apr 2013 11:17:53 +0200
Subject: [PATCH 14/32] dmaengine: ste_dma40: Remove 'always true' checking
In-Reply-To: <1366279934-30761-15-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-15-git-send-email-lee.jones@linaro.org>
Message-ID: <CACRpkdZ5BzmjFNxHrhXVyRhMTMsH4Cq1XRmgiWQjU2e6cCO1bA@mail.gmail.com>

On Thu, Apr 18, 2013 at 12:11 PM, Lee Jones <lee.jones at linaro.org> wrote:

> Before allocating memory for logical channels, the current driver
> checks to see if there are any. Well as the dma40_memcpy_channels[]
> array is always populated, the check is always true. Best to
> remove the check.
>
> Cc: Vinod Koul <vinod.koul at intel.com>
> Cc: Dan Williams <djbw at fb.com>
> Cc: Per Forlin <per.forlin at stericsson.com>
> Cc: Rabin Vincent <rabin at rab.in>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>

(...)

> -       if (num_log_chans + ARRAY_SIZE(dma40_memcpy_channels)) {

So I guess this was changed when moving the memcpy channels
into the driver.

> -               /*
> -                * The max number of logical channels are event lines for all
> -                * src devices and dst devices
> -                */
> -               base->lookup_log_chans = kzalloc(num_log_chans *
> -                                                sizeof(struct d40_chan *),
> -                                                GFP_KERNEL);

And at that point you forgot to rewrite this as
kzalloc((num_log_chans + ARRAY_SIZE(dma40_memcpy_channels)), ...)?

> -               if (!base->lookup_log_chans)
> -                       goto failure;
> -       }
> +       base->lookup_log_chans = kzalloc(num_log_chans *
> +                                        sizeof(struct d40_chan *),
> +                                        GFP_KERNEL);
> +       if (!base->lookup_log_chans)
> +               goto failure;

So this change should also include the memcpy channels.

I'll go back and comment again on the patch moving the
memcpy channels into the driver.

Yours,
Linus Walleij


From lee.jones at linaro.org  Thu Apr 25 05:19:06 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Thu, 25 Apr 2013 10:19:06 +0100
Subject: [PATCH 05/32] dmaengine: ste_dma40: Supply macros to resolve
 'src' and 'dst' directions
In-Reply-To: <CACRpkdYD21VEHZ2825=e7PnATp-tfrL2rg4rKboG-Fq04U162A@mail.gmail.com>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-6-git-send-email-lee.jones@linaro.org>
 <CACRpkdYD21VEHZ2825=e7PnATp-tfrL2rg4rKboG-Fq04U162A@mail.gmail.com>
Message-ID: <20130425091906.GG4623@gmail.com>

On Thu, 25 Apr 2013, Linus Walleij wrote:

> On Thu, Apr 18, 2013 at 12:11 PM, Lee Jones <lee.jones at linaro.org> wrote:
> 
> > There are lots of lengthy if() statements located sporadically up and
> > down the driver. This simple macro should make many of them a little
> > simpler to decipher. The remainder have to stay in place, as they
> > detail slightly more specific settings.
> >
> > Cc: Vinod Koul <vinod.koul at intel.com>
> > Cc: Dan Williams <djbw at fb.com>
> > Cc: Per Forlin <per.forlin at stericsson.com>
> > Cc: Rabin Vincent <rabin at rab.in>
> > Signed-off-by: Lee Jones <lee.jones at linaro.org>
> (...)
> 
> > +#define D40_IS_SRC(dir)  ((dir == STEDMA40_PERIPH_TO_MEM) ? true : false)
> 
> And when I reas the code and see D40_IS_SRC, what does that
> mean? That the channel is a source of .. what exactly?
> 
> The older explicit comparison would be more informative.
> 
> > +#define D40_IS_DST(dir) (((dir == STEDMA40_MEM_TO_PERIPH) || \
> > +                         (dir == STEDMA40_MEM_TO_MEM)) ? true : false)
> > +
> 
> The comparison to STEDMA40_MEM_TO_MEM is unintelligible, if I see
> that macro it has a very unintuitive name, since it is not just
> DST but also SRC.
> 
> The latter macro would be named somthing like D40_IS_DST_OR_MEM2MEM
> and then it will not simplify the code very much.
> 
> You need to come up with something different here, this is just making the
> driver harder to understand.
> 
> I think this patch should be just dropped.

Okay.

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From linus.walleij at linaro.org  Thu Apr 25 05:20:18 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Apr 2013 11:20:18 +0200
Subject: [PATCH 01/32] dmaengine: ste_dma40: Assign memcpy channels in the
 driver
In-Reply-To: <1366279934-30761-2-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-2-git-send-email-lee.jones@linaro.org>
Message-ID: <CACRpkdaMS8RBi7aWyBRRZbf7OpK82C3-79tEaq+A-QU5zbVyxQ@mail.gmail.com>

On Thu, Apr 18, 2013 at 12:11 PM, Lee Jones <lee.jones at linaro.org> wrote:

> The channels reserved for memcpy are the same for all currently
> supported platforms. With this in mind, we can ease the platform
> data passing requirement by moving these assignments out from
> platform code and place them directly into the driver.
>
> Cc: Vinod Koul <vinod.koul at intel.com>
> Cc: Dan Williams <djbw at fb.com>
> Cc: Per Forlin <per.forlin at stericsson.com>
> Cc: Rabin Vincent <rabin at rab.in>
> Acked-by: Arnd Bergmann <arnd at arndb.de>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>

(...)
> -       if (num_log_chans + plat_data->memcpy_len) {
> +       if (num_log_chans + ARRAY_SIZE(dma40_memcpy_channels)) {
>                 /*
>                  * The max number of logical channels are event lines for all
>                  * src devices and dst devices

So as mentioned in review of another patch there is a kzalloc
right below here where you forget to add + ARRAY_SIZE(dma40_memcpy_channels)
please fix this...

Yours,
Linus Walleij


From lee.jones at linaro.org  Thu Apr 25 05:24:13 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Thu, 25 Apr 2013 10:24:13 +0100
Subject: [PATCH 14/32] dmaengine: ste_dma40: Remove 'always true' checking
In-Reply-To: <CACRpkdZ5BzmjFNxHrhXVyRhMTMsH4Cq1XRmgiWQjU2e6cCO1bA@mail.gmail.com>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-15-git-send-email-lee.jones@linaro.org>
 <CACRpkdZ5BzmjFNxHrhXVyRhMTMsH4Cq1XRmgiWQjU2e6cCO1bA@mail.gmail.com>
Message-ID: <20130425092413.GH4623@gmail.com>

On Thu, 25 Apr 2013, Linus Walleij wrote:

> On Thu, Apr 18, 2013 at 12:11 PM, Lee Jones <lee.jones at linaro.org> wrote:
> 
> > Before allocating memory for logical channels, the current driver
> > checks to see if there are any. Well as the dma40_memcpy_channels[]
> > array is always populated, the check is always true. Best to
> > remove the check.
> >
> > Cc: Vinod Koul <vinod.koul at intel.com>
> > Cc: Dan Williams <djbw at fb.com>
> > Cc: Per Forlin <per.forlin at stericsson.com>
> > Cc: Rabin Vincent <rabin at rab.in>
> > Signed-off-by: Lee Jones <lee.jones at linaro.org>
> 
> (...)
> 
> > -       if (num_log_chans + ARRAY_SIZE(dma40_memcpy_channels)) {
> 
> So I guess this was changed when moving the memcpy channels
> into the driver.

Right.

> > -               /*
> > -                * The max number of logical channels are event lines for all
> > -                * src devices and dst devices
> > -                */
> > -               base->lookup_log_chans = kzalloc(num_log_chans *
> > -                                                sizeof(struct d40_chan *),
> > -                                                GFP_KERNEL);
> 
> And at that point you forgot to rewrite this as
> kzalloc((num_log_chans + ARRAY_SIZE(dma40_memcpy_channels)), ...)?

I guess I didn't notice that, yes.

> > -               if (!base->lookup_log_chans)
> > -                       goto failure;
> > -       }
> > +       base->lookup_log_chans = kzalloc(num_log_chans *
> > +                                        sizeof(struct d40_chan *),
> > +                                        GFP_KERNEL);
> > +       if (!base->lookup_log_chans)
> > +               goto failure;
> 
> So this change should also include the memcpy channels.
> 
> I'll go back and comment again on the patch moving the
> memcpy channels into the driver.

Okay, NP.

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From lee.jones at linaro.org  Thu Apr 25 05:29:30 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Thu, 25 Apr 2013 10:29:30 +0100
Subject: [PATCH 13/32] dmaengine: ste_dma40: Calculate number of logical
 channels from physical ones
In-Reply-To: <CACRpkdYq9QLRaaysc=izGgi53ogf1oRHuCwWKW+rQBbE_UtfnA@mail.gmail.com>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-14-git-send-email-lee.jones@linaro.org>
 <CACRpkdYq9QLRaaysc=izGgi53ogf1oRHuCwWKW+rQBbE_UtfnA@mail.gmail.com>
Message-ID: <20130425092930.GI4623@gmail.com>

On Thu, 25 Apr 2013, Linus Walleij wrote:

> On Thu, Apr 18, 2013 at 12:11 PM, Lee Jones <lee.jones at linaro.org> wrote:
> 
> > This change will cost ~25KB of memory, but it's worth the trade-off,
> > as it removes a great deal of overhead. It means that instead of only
> > allocating memory for the logical channels in use, it does so for all
> > available ones, which is 32 per physical channel. However, this now
> > means we can remove some platform data and we don't have to worry
> > about adding vendor specific variables to Device Tree.
> >
> > Cc: Vinod Koul <vinod.koul at intel.com>
> > Cc: Dan Williams <djbw at fb.com>
> > Cc: Per Forlin <per.forlin at stericsson.com>
> > Cc: Rabin Vincent <rabin at rab.in>
> > Signed-off-by: Lee Jones <lee.jones at linaro.org>
> 
> (...)
> >  static struct stedma40_platform_data dma40_plat_data = {
> > -       .dev_len = DB8500_DMA_NR_DEV,
> 
> So that was set to 64 in the platform...
> 
> > -       /* Count the number of logical channels in use */
> > -       for (i = 0; i < plat_data->dev_len; i++)
> > -               if (plat_data->dev_rx[i] != 0)
> > -                       num_log_chans++;
> > -
> > -       for (i = 0; i < plat_data->dev_len; i++)
> > -               if (plat_data->dev_tx[i] != 0)
> > -                       num_log_chans++;
> 
> And I guess this code snippet made it go down to <= 32 all the time,
> correct?

However many were described in dma40_[rx|tx]_map, yes.

> Just want to understand it before I ACK. (The idea is sound.)
> 
> I notice there is no check whatsoever of the bounds of
> plat_data->dev_[rx|tx]  but that is a different problem I guess...

The array is going away anyway, so we don't need to threat.

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From daniel.lezcano at linaro.org  Thu Apr 25 05:35:28 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Thu, 25 Apr 2013 11:35:28 +0200
Subject: [PATCH 1/2] ARM: s3c64xx: cpuidle: use init/exit common routine
In-Reply-To: <1366728077-18988-1-git-send-email-daniel.lezcano@linaro.org>
References: <1366728077-18988-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <5178F8E0.6010606@linaro.org>

On 04/23/2013 04:41 PM, Daniel Lezcano wrote:
> Remove the duplicated code and use the cpuidle common code for initialization.
>
> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
> ---

Hi Kim and Ben,

It is the last patch in the series which was not acked-by.
Rafael is willing to take it in its tree if you ack it.

Are you ok if this patch ?

Thanks
-- Daniel

>  arch/arm/mach-s3c64xx/cpuidle.c |   14 +-------------
>  1 file changed, 1 insertion(+), 13 deletions(-)
>
> diff --git a/arch/arm/mach-s3c64xx/cpuidle.c b/arch/arm/mach-s3c64xx/cpuidle.c
> index 852ff16..3c8ab07 100644
> --- a/arch/arm/mach-s3c64xx/cpuidle.c
> +++ b/arch/arm/mach-s3c64xx/cpuidle.c
> @@ -40,8 +40,6 @@ static int s3c64xx_enter_idle(struct cpuidle_device *dev,
>  	return index;
>  }
>  
> -static DEFINE_PER_CPU(struct cpuidle_device, s3c64xx_cpuidle_device);
> -
>  static struct cpuidle_driver s3c64xx_cpuidle_driver = {
>  	.name	= "s3c64xx_cpuidle",
>  	.owner  = THIS_MODULE,
> @@ -60,16 +58,6 @@ static struct cpuidle_driver s3c64xx_cpuidle_driver = {
>  
>  static int __init s3c64xx_init_cpuidle(void)
>  {
> -	int ret;
> -
> -	cpuidle_register_driver(&s3c64xx_cpuidle_driver);
> -
> -	ret = cpuidle_register_device(&s3c64xx_cpuidle_device);
> -	if (ret) {
> -		pr_err("Failed to register cpuidle device: %d\n", ret);
> -		return ret;
> -	}
> -
> -	return 0;
> +	return cpuidle_register(&s3c64xx_cpuidle_driver, NULL);
>  }
>  device_initcall(s3c64xx_init_cpuidle);


-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From maxime.ripard at free-electrons.com  Thu Apr 25 05:42:06 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Thu, 25 Apr 2013 11:42:06 +0200
Subject: [PATCHv2 0/2] Add support for the Solomon SSD1306 OLED Controller
In-Reply-To: <1366624555-5616-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1366624555-5616-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <5178FA6E.2050709@free-electrons.com>

Hi Andrew,

Le 22/04/2013 11:55, Maxime Ripard a ?crit :
> This patchset adds the needed bits to the ssd1307fb driver to support the
> very similar Solomon SSD1306 controller.
> 
> Since the SSD1307 has been replaced by the SSD1306 in the latest CFA-10036
> production samples, we also need to change the device tree accordingly.

These patches have been around for more than a month and a half now,
without anyone making any comments on it.

I know that you have taken framebuffer patches in the past, especially
the driver that this patch modifies, would you consider merging it
through your tree?

I begin to have patches that depends on this one (the patchset "drivers:
video: Optimisations for the ssd1307fb driver"). I understand that we
are quite close to the 3.10 merge window opening (we even reached the
end of it for the ARM part, so the second patch will only be in 3.11),
but I'd like to make sure that this patch and the others doesn't get
silently ignored.

Thanks,
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


From simon.guinot at sequanux.org  Thu Apr 25 05:58:16 2013
From: simon.guinot at sequanux.org (Simon Guinot)
Date: Thu, 25 Apr 2013 11:58:16 +0200
Subject: [PATCHv1 1/3] hwmon: Add support for GMT G762/G763 PWM fan
 controller
In-Reply-To: <63961d39aee9db94767f28fd441312bec2029473.1366753420.git.arno@natisbad.org>
References: <cover.1366753420.git.arno@natisbad.org>
 <63961d39aee9db94767f28fd441312bec2029473.1366753420.git.arno@natisbad.org>
Message-ID: <20130425095816.GC17771@kw.sim.vm.gnt>

Hi Arnaud,

On Wed, Apr 24, 2013 at 12:05:56AM +0200, Arnaud Ebalard wrote:
> diff --git a/drivers/hwmon/g762.c b/drivers/hwmon/g762.c
> new file mode 100644
> index 0000000..810b019
> --- /dev/null
> +++ b/drivers/hwmon/g762.c

Snip

> +
> +/*
> + * Configuration-related definitions
> + */
> +
> +struct g762_config {
> +	u32 fan_startv;
> +	u32 fan_gear_mode;
> +	u32 fan_div;
> +	u32 fan_pulses;
> +	u32 fan_target;
> +	u32 pwm_polarity;
> +	u32 pwm_enable;
> +	u32 pwm_freq;
> +	u32 pwm_mode;
> +};
> +
> +/*
> + * g762 default values: it is assumed that the fan is set for a 32KHz clock
> + * source, a fan clock divisor of 1 and two pulses per revolution. Default
> + * fan driving mode is linear mode (g762/g763 also support PWM mode). Note
> + * the specific init value for properties which may be left unmodified.
> + */
> +#define G762_DEFAULT_CLK            32768
> +#define G762_DEFAULT_FAN_DIV        1
> +#define G762_DEFAULT_FAN_PULSES     2
> +#define G762_DEFAULT_OUT_MODE       0
> +#define G762_DEFAULT_FAN_MODE       2

Maybe you could use here the same macros as the ones used in the
do_set_* functions:

#define G762_DEFAULT_OUT_MODE		OUT_MODE_DAC
#define G762_DEFAULT_FAN_MODE		FAN_MODE_CLOSED_LOOP

Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130425/3ed71656/attachment.sig>

From stefano.stabellini at eu.citrix.com  Thu Apr 25 06:12:54 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Thu, 25 Apr 2013 11:12:54 +0100
Subject: [PATCH v8 1/2] arm: introduce psci_smp_ops
In-Reply-To: <20130425084711.GA12848@mudshark.cambridge.arm.com>
References: <alpine.DEB.2.02.1304241935010.4180@kaball.uk.xensource.com>
 <1366828819-10745-1-git-send-email-stefano.stabellini@eu.citrix.com>
 <20130425084711.GA12848@mudshark.cambridge.arm.com>
Message-ID: <alpine.DEB.2.02.1304251104090.4180@kaball.uk.xensource.com>

On Thu, 25 Apr 2013, Will Deacon wrote:
> > +/*
> > + * cpu_suspend   Suspend the execution on a CPU
> > + * @state        we don't currently describe affinity levels, so just pass 0.
> > + * @entry_point  the first instruction to be executed on return
> > + * returns 0  success, < 0 on failure
> > + *
> > + * cpu_off       Power down a CPU
> > + * @state        we don't currently describe affinity levels, so just pass 0.
> > + * no return on successful call
> > + *
> > + * cpu_on        Power up a CPU
> > + * @cpuid        cpuid of target CPU, as from MPIDR
> > + * @entry_point  the first instruction to be executed on return
> > + * returns 0  success, < 0 on failure
> > + *
> > + * migrate       Migrate the context to a different CPU
> > + * @cpuid        cpuid of target CPU, as from MPIDR
> > + * returns 0  success, < 0 on failure
> > + *
> > + */
> 
> Can you move these comments into psci-smp.c please? They're really specific
> to the implementation there, and if we put them in a header we're lying to
> ourselves about the parameters actually described by the PSCI specification.

You have a good point about the PSCI spec.

However from the Linux POV these comments should regard the functions
exported by psci_operations, not the firmware interface, this is why I
think it makes sense to keep them in psci.h.
What we are saying is for example that psci_operations.cpu_on returns 0
on success and < 0 on failure, and it takes a cpuid and an entry point
as parameters. We are not saying anything about the firmware interface.

Maybe I should add at the top:

"psci_operations functions and parameters, might different from the
firmware interface:"


From stefano.stabellini at eu.citrix.com  Thu Apr 25 06:14:43 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Thu, 25 Apr 2013 11:14:43 +0100
Subject: [PATCH v4 7/7] mach-virt: support Xen hypercalls for shutdown
 and reboot
In-Reply-To: <20130425085452.GC12848@mudshark.cambridge.arm.com>
References: <alpine.DEB.2.02.1304242012590.4180@kaball.uk.xensource.com>
 <1366831695-13214-7-git-send-email-stefano.stabellini@eu.citrix.com>
 <alpine.DEB.2.02.1304242301390.4180@kaball.uk.xensource.com>
 <20130425085452.GC12848@mudshark.cambridge.arm.com>
Message-ID: <alpine.DEB.2.02.1304251114280.4180@kaball.uk.xensource.com>

On Thu, 25 Apr 2013, Will Deacon wrote:
> On Wed, Apr 24, 2013 at 11:14:28PM +0100, Stefano Stabellini wrote:
> > On Wed, 24 Apr 2013, Stefano Stabellini wrote:
> > > Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
> > > CC: Marc Zyngier <marc.zyngier at arm.com>
> > > CC: will.deacon at arm.com
> > > CC: arnd at arndb.de
> > > CC: rob.herring at calxeda.com
> > 
> > Thinking twice about this patch, a less intrusive alternative would be
> > to set arm_pm_restart and pm_power_off to two xen specific functions
> > later on from xen_guest_init.
> 
> Yes please. We'd like to remove mach-virt/* some day.

I'll do


From simon.guinot at sequanux.org  Thu Apr 25 06:14:50 2013
From: simon.guinot at sequanux.org (Simon Guinot)
Date: Thu, 25 Apr 2013 12:14:50 +0200
Subject: [PATCHv1 1/3] hwmon: Add support for GMT G762/G763 PWM fan
 controller
In-Reply-To: <20130424224731.GB7767@roeck-us.net>
References: <cover.1366753420.git.arno@natisbad.org>
 <63961d39aee9db94767f28fd441312bec2029473.1366753420.git.arno@natisbad.org>
 <20130424053758.GC8710@lunn.ch> <87obd4wb4e.fsf@natisbad.org>
 <20130424133856.GA18851@roeck-us.net> <87li878ygw.fsf@natisbad.org>
 <20130424224731.GB7767@roeck-us.net>
Message-ID: <20130425101450.GD17771@kw.sim.vm.gnt>

On Wed, Apr 24, 2013 at 03:47:31PM -0700, Guenter Roeck wrote:
> On Wed, Apr 24, 2013 at 10:28:47PM +0200, Arnaud Ebalard wrote:
> > Hi,
> > 
> > Guenter Roeck <linux at roeck-us.net> writes:
> > 
> > >> > You could consider using regmap for holding this cache.
> > >> >
> > >> > http://elceurope2012.sched.org/event/100619b669ce5767341624253aa03659?iframe=no&w=900&sidebar=yes&bg=no#.UXdspHLQ5jM
> > >> >
> > >> > http://elinux.org/ELCE_Europe_2012_Presentations
> > >> 
> > >> Interesting. As I am not yet familiar w/ regmap I would prefer having
> > >> the driver accepted during merge window with current data structure and
> > >> then convert it to regmap. But I will take a look (e.g. will study
> > >> fca1dd03 for instance). Thanks for the pointers. 
> > >> 
> > > I have not had time for a detailed review, but adding regmap support
> > > will not be a requirement.
> > >
> > > Note that it is too late for 3.10, so the driver will have to wait for
> > > 3.11.
> > 
> > Well, I think I can live with it; The only bad thing is that it kills my
> > excuses not to spend time on regmap ;-)
> > 
> Your call.
> 
> > 
> > >> >> +/*
> > >> >> + * Helpers to import hardware characteristics from .dts file and overload
> > >> >> + * default config values.
> > >> >> + */
> > >> >> +
> > >> >> +#ifdef CONFIG_OF
> > >> >
> > >> > Can the driver be used without device tree? Would it be simpler to
> > >> >  just add depends OF in the Kconfig entry?
> > >> 
> > >> It can be used if the default params (or those configured by u-boot I
> > >> guess) fit your needs. I think it would be fairly easy to extend the
> > >> driver later to expose g762_config struct to allow parameters to be set
> > >> w/o using OF. If someone wants to do that, I think it is better to not
> > >> depend on OF in Kconfig at the moment but I have not strong argument
> > >> other that that one. I'll let you decide.
> > >> 
> > > Agreed. As long as there are major platforms not supporting device tree,
> > > and as long as device tree overlays are not supported, it must not be made
> > > mandatory. Especially for I2C and SPI devices I reserve the right to be able
> > > test the hardware on an X86 system and not require a reboot to do so.
> > 
> > Understood. Following Simon's post, I think it's useful to implement
> > some init function for non DT-enabled platforms. 
> > 
> Sure, as long as Simon commits to test it and - if possible - to provide
> the necessary platform code.

Hi Guenter,

I commit to do whatever needed to have g762 support on the 2Big Network
v2 and 2Big NAS boards.

But note that I am can't test the options "pwm_enable" and "fan_target".
As we are using a two wire fan on this boards, this options are not
relevant.

Moreover except for the out_mode/pwm_mode setting, I am rather happy
with the default configuration.

Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130425/fdf1f927/attachment-0001.sig>

From stefano.stabellini at eu.citrix.com  Thu Apr 25 06:25:01 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Thu, 25 Apr 2013 11:25:01 +0100
Subject: [PATCH v8 2/2] ARM: Enable selection of SMP operations at boot
 time
In-Reply-To: <20130425084933.GB12848@mudshark.cambridge.arm.com>
References: <alpine.DEB.2.02.1304241935010.4180@kaball.uk.xensource.com>
 <1366828819-10745-2-git-send-email-stefano.stabellini@eu.citrix.com>
 <20130425084933.GB12848@mudshark.cambridge.arm.com>
Message-ID: <alpine.DEB.2.02.1304251123410.4180@kaball.uk.xensource.com>

On Thu, 25 Apr 2013, Will Deacon wrote:
> On Wed, Apr 24, 2013 at 07:40:19PM +0100, Stefano Stabellini wrote:
> > From: Jon Medhurst <tixy at linaro.org>
> > 
> > Add a new 'smp_init' hook to machine_desc so platforms can specify a
> > function to be used to setup smp ops instead of having a statically
> > defined value.  The hook must return true when smp_ops are initialized.
> > If false the static mdesc->smp_ops will be used by default.
> > 
> > Signed-off-by: Jon Medhurst <tixy at linaro.org>
> > Signed-off-by: Nicolas Pitre <nicolas.pitre at linaro.org>
> > Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
> > Reviewed-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
> > ---
> >  arch/arm/include/asm/mach/arch.h |    4 ++++
> >  arch/arm/kernel/setup.c          |   10 ++++++----
> >  2 files changed, 10 insertions(+), 4 deletions(-)
> 
> [...]
> 
> >  	if (is_smp()) {
> > -		if (psci_smp_available())
> > -			smp_set_ops(&psci_smp_ops);
> > -		else if (mdesc->smp)
> > -			smp_set_ops(mdesc->smp);
> > +		if (!mdesc->smp_init || !mdesc->smp_init()) {
> 
> Minor nit, but this feels backwards to me. We usually return 0 on success,
> yet we're saying here that if mdesc->smp_init() returns 0, then we go and
> override the smp ops.

I am OK with changing the interface to return an int instead of a bool,
but given that Nicolas is the main user of smp_init at the moment, I'll
wait for his opinion.


From will.deacon at arm.com  Thu Apr 25 06:45:08 2013
From: will.deacon at arm.com (Will Deacon)
Date: Thu, 25 Apr 2013 11:45:08 +0100
Subject: [PATCH v8 1/2] arm: introduce psci_smp_ops
In-Reply-To: <alpine.DEB.2.02.1304251104090.4180@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1304241935010.4180@kaball.uk.xensource.com>
 <1366828819-10745-1-git-send-email-stefano.stabellini@eu.citrix.com>
 <20130425084711.GA12848@mudshark.cambridge.arm.com>
 <alpine.DEB.2.02.1304251104090.4180@kaball.uk.xensource.com>
Message-ID: <20130425104508.GG12848@mudshark.cambridge.arm.com>

On Thu, Apr 25, 2013 at 11:12:54AM +0100, Stefano Stabellini wrote:
> On Thu, 25 Apr 2013, Will Deacon wrote:
> > > +/*
> > > + * cpu_suspend   Suspend the execution on a CPU
> > > + * @state        we don't currently describe affinity levels, so just pass 0.
> > > + * @entry_point  the first instruction to be executed on return
> > > + * returns 0  success, < 0 on failure
> > > + *
> > > + * cpu_off       Power down a CPU
> > > + * @state        we don't currently describe affinity levels, so just pass 0.
> > > + * no return on successful call
> > > + *
> > > + * cpu_on        Power up a CPU
> > > + * @cpuid        cpuid of target CPU, as from MPIDR
> > > + * @entry_point  the first instruction to be executed on return
> > > + * returns 0  success, < 0 on failure
> > > + *
> > > + * migrate       Migrate the context to a different CPU
> > > + * @cpuid        cpuid of target CPU, as from MPIDR
> > > + * returns 0  success, < 0 on failure
> > > + *
> > > + */
> > 
> > Can you move these comments into psci-smp.c please? They're really specific
> > to the implementation there, and if we put them in a header we're lying to
> > ourselves about the parameters actually described by the PSCI specification.
> 
> You have a good point about the PSCI spec.
> 
> However from the Linux POV these comments should regard the functions
> exported by psci_operations, not the firmware interface, this is why I
> think it makes sense to keep them in psci.h.
> What we are saying is for example that psci_operations.cpu_on returns 0
> on success and < 0 on failure, and it takes a cpuid and an entry point
> as parameters. We are not saying anything about the firmware interface.

I disagree. You're explicitly stating that we pass the `cpuid of target CPU,
as from MPIDR'. That's simply not true -- the firmware could choose any
numbering scheme to identify the CPUs. For KVM and Xen, it *is* the mpidr,
which is why psci-smp.c works at all, but that's where the comment belongs,
not in this header file.

Will


From linus.walleij at linaro.org  Thu Apr 25 07:00:03 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Apr 2013 13:00:03 +0200
Subject: [PATCH 15/32] dmaengine: ste_dma40: Separate Logical Global
 Interrupt Mask (GIM) unmasking
In-Reply-To: <1366279934-30761-16-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-16-git-send-email-lee.jones@linaro.org>
Message-ID: <CACRpkdZ1tSeqcctS138QkRn6PENMrjMyrnkHeMOYaOBW096N1g@mail.gmail.com>

On Thu, Apr 18, 2013 at 12:11 PM, Lee Jones <lee.jones at linaro.org> wrote:

> During the initial setup of a logical channel, it is necessary to unmask
> the GIM in order to receive generated terminal count and error interrupts.
> We're separating out this required code so it will be possible to move
> the remaining code in d40_phy_cfg(), which is mostly runtime configuration
> into the runtime_config() routine.
>
> Cc: Vinod Koul <vinod.koul at intel.com>
> Cc: Dan Williams <djbw at fb.com>
> Cc: Per Forlin <per.forlin at stericsson.com>
> Cc: Rabin Vincent <rabin at rab.in>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>

This commit message needs to reflect the fact that you've observed
that one argument to the d40_phy_cfg() is hardcoded to false in the
runtime config, and that is why we can sink the use into
d40_alloc_chan_resources().

(...)
> @@ -2456,6 +2456,9 @@ static int d40_alloc_chan_resources(struct dma_chan *chan)
>                                 D40_LCPA_CHAN_SIZE + D40_LCPA_CHAN_DST_DELTA;
>         }
>
> +       if (chan_is_logical(d40c))
> +               d40_log_gim_unmask(&d40c->src_def_cfg, &d40c->dst_def_cfg);

The clause right above is already a if (chan_is_logical(c)).
Just insert the function call into that clause.

> +void d40_log_gim_unmask(u32 *src_cfg, u32 *dst_cfg) {
> +
> +       *src_cfg |= 1 << D40_SREG_CFG_LOG_GIM_POS;
> +       *dst_cfg |= 1 << D40_SREG_CFG_LOG_GIM_POS;
> +}

Why create a separate function with two lines which is just called from
one single place?

Just sink this into the d40_alloc_chan_resources() function like that:

if (logical) {
  *d40c->src_def_cfg |= 1 << D40_SREG_CFG_LOG_GIM_POS;
  *d40c->dst_def_cfg |= 1 << D40_SREG_CFG_LOG_GIM_POS;

No need for a separate function and a separate header.

(...)
>  /* Sets up SRC and DST CFG register for both logical and physical channels */
>  void d40_phy_cfg(struct stedma40_chan_cfg *cfg,
>                  u32 *src_cfg, u32 *dst_cfg, bool is_log)

Take this opportunity to:

(A) delete the argument is_log since it has no use whatsoever after this.
    Why pass it at all!

(B) De-indent the if (!is_log) clause... as a natural consequence.

Yours,
Linus Walleij


From mpa at pengutronix.de  Thu Apr 25 07:02:43 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Thu, 25 Apr 2013 13:02:43 +0200
Subject: [PATCH v5 01/10] ASoC: phycore-ac97: Add DT support
In-Reply-To: <20130425033517.GA1276@S2101-09.ap.freescale.net>
References: <1366814199-14827-1-git-send-email-mpa@pengutronix.de>
 <1366814199-14827-2-git-send-email-mpa@pengutronix.de>
 <20130424194540.GF32299@pengutronix.de>
 <20130425033517.GA1276@S2101-09.ap.freescale.net>
Message-ID: <20130425110243.GA27763@pengutronix.de>

On Thu, Apr 25, 2013 at 11:35:20AM +0800, Shawn Guo wrote:
> On Wed, Apr 24, 2013 at 09:45:40PM +0200, Sascha Hauer wrote:
> > Hi Markus,
> > 
> > On Wed, Apr 24, 2013 at 04:36:30PM +0200, Markus Pargmann wrote:
> > > Add devicetree support for this audio soc fabric driver.
> > > 
> > > @@ -32,8 +35,12 @@ static struct snd_soc_dai_link imx_phycore_dai_ac97[] = {
> > >  		.stream_name	= "HiFi",
> > >  		.codec_dai_name		= "wm9712-hifi",
> > >  		.codec_name	= "wm9712-codec",
> > > +#ifdef CONFIG_MACH_IMX27_DT
> > > +		.platform_name	= "imx-fiq-pcm-audio",
> > > +#else
> > >  		.cpu_dai_name	= "imx-ssi.0",
> > >  		.platform_name	= "imx-fiq-pcm-audio.0",
> > > +#endif
> > 
> > This doesn't work properly. Compiling the kernel with IMX27_DT enabled
> > does not necessarily mean that it also started with dt support.
> > 
> Right, we should run-time check pdev->dev.of_node to see if it's a DT
> boot and set .platform_of_node rather than .platform_name if it is.  But
> it's only possible with the cleanup series "ASoC: fsl: imx-pcm driver
> cleanup" I just sent being the base.  I hope you can rebase your series
> on that :)

The current version of phycore-ac97.c is not a driver, it is just a late
init call. So run-time check is not possible unless I modify the old
part to be a driver and add a device to all board init functions using
ac97. (I would prefer dropping the non-DT part in this case ;) )

Yes I rebased this series onto your cleanups, looks good so far and
platform_of_node works finally.

Thanks,

Markus

> 
> Shawn
> 
> > Personally I am fine with removing platform based support for this
> > driver if it's too much effort to fix it properly, but we shouldn't
> > start working with ifdefs here.
> > 
> > Sascha
> > 
> > 
> > -- 
> > Pengutronix e.K.                           |                             |
> > Industrial Linux Solutions                 | http://www.pengutronix.de/  |
> > Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
> > Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
> 
> 

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From stefano.stabellini at eu.citrix.com  Thu Apr 25 07:08:02 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Thu, 25 Apr 2013 12:08:02 +0100
Subject: [PATCH v8 1/2] arm: introduce psci_smp_ops
In-Reply-To: <20130425104508.GG12848@mudshark.cambridge.arm.com>
References: <alpine.DEB.2.02.1304241935010.4180@kaball.uk.xensource.com>
 <1366828819-10745-1-git-send-email-stefano.stabellini@eu.citrix.com>
 <20130425084711.GA12848@mudshark.cambridge.arm.com>
 <alpine.DEB.2.02.1304251104090.4180@kaball.uk.xensource.com>
 <20130425104508.GG12848@mudshark.cambridge.arm.com>
Message-ID: <alpine.DEB.2.02.1304251158080.4180@kaball.uk.xensource.com>

On Thu, 25 Apr 2013, Will Deacon wrote:
> On Thu, Apr 25, 2013 at 11:12:54AM +0100, Stefano Stabellini wrote:
> > On Thu, 25 Apr 2013, Will Deacon wrote:
> > > > +/*
> > > > + * cpu_suspend   Suspend the execution on a CPU
> > > > + * @state        we don't currently describe affinity levels, so just pass 0.
> > > > + * @entry_point  the first instruction to be executed on return
> > > > + * returns 0  success, < 0 on failure
> > > > + *
> > > > + * cpu_off       Power down a CPU
> > > > + * @state        we don't currently describe affinity levels, so just pass 0.
> > > > + * no return on successful call
> > > > + *
> > > > + * cpu_on        Power up a CPU
> > > > + * @cpuid        cpuid of target CPU, as from MPIDR
> > > > + * @entry_point  the first instruction to be executed on return
> > > > + * returns 0  success, < 0 on failure
> > > > + *
> > > > + * migrate       Migrate the context to a different CPU
> > > > + * @cpuid        cpuid of target CPU, as from MPIDR
> > > > + * returns 0  success, < 0 on failure
> > > > + *
> > > > + */
> > > 
> > > Can you move these comments into psci-smp.c please? They're really specific
> > > to the implementation there, and if we put them in a header we're lying to
> > > ourselves about the parameters actually described by the PSCI specification.
> > 
> > You have a good point about the PSCI spec.
> > 
> > However from the Linux POV these comments should regard the functions
> > exported by psci_operations, not the firmware interface, this is why I
> > think it makes sense to keep them in psci.h.
> > What we are saying is for example that psci_operations.cpu_on returns 0
> > on success and < 0 on failure, and it takes a cpuid and an entry point
> > as parameters. We are not saying anything about the firmware interface.
> 
> I disagree. You're explicitly stating that we pass the `cpuid of target CPU,
> as from MPIDR'. That's simply not true -- the firmware could choose any
> numbering scheme to identify the CPUs. For KVM and Xen, it *is* the mpidr,
> which is why psci-smp.c works at all, but that's where the comment belongs,
> not in this header file.

I see, you want to keep psci_operations true to the firmware interface
while explaining that psci_smp makes some assumptions about it.
So the comment should be something like:

/*
 * psci_smp assumes that the following is true about PSCI:
 * 
 * cpu_suspend   Suspend the execution on a CPU
 * @state        we don't currently describe affinity levels, so just pass 0.
 * @entry_point  the first instruction to be executed on return
 * returns 0  success, < 0 on failure
 *
 * cpu_off       Power down a CPU
 * @state        we don't currently describe affinity levels, so just pass 0.
 * no return on successful call
 *
 * cpu_on        Power up a CPU
 * @cpuid        cpuid of target CPU, as from MPIDR
 * @entry_point  the first instruction to be executed on return
 * returns 0  success, < 0 on failure
 *
 * migrate       Migrate the context to a different CPU
 * @cpuid        cpuid of target CPU, as from MPIDR
 * returns 0  success, < 0 on failure
 *
 */


From linus.walleij at linaro.org  Thu Apr 25 07:09:39 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Apr 2013 13:09:39 +0200
Subject: [PATCH 16/32] dmaengine: ste_dma40: Remove unnecessary call to
 d40_phy_cfg()
In-Reply-To: <1366279934-30761-17-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-17-git-send-email-lee.jones@linaro.org>
Message-ID: <CACRpkdbQpiEZ4etyE=mveH8HFughVe_oa81P3QEWWJHPtrxn0g@mail.gmail.com>

On Thu, Apr 18, 2013 at 12:11 PM, Lee Jones <lee.jones at linaro.org> wrote:

> All configuration left in d40_phy_cfg() is runtime configurable and
> there is already a call into it from d40_runtime_config(), so let's
> rely on that.
>
> Cc: Vinod Koul <vinod.koul at intel.com>
> Cc: Dan Williams <djbw at fb.com>
> Cc: Per Forlin <per.forlin at stericsson.com>
> Cc: Rabin Vincent <rabin at rab.in>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>

NAK. Have you really tested this with memcpy()?

The runtime config function is *not* called when doing memcpy
DMA, still the channels used for memcpy need to be configured
obviously. Now you're assuming that every time anyone is using
a DMA channel they will first allocate it, then call the runtime
config. This is not true.

Runtime config is only used when doing dev->mem and
mem->dev DMA.

You may just as well compile in the test program that is there right
in the kernel and run it ... it's good! (DMA Test Client in
menuconfig under drivers/dma engine support...)

There was this other patch not taking the memcpy channels
into the array that I think will also cause a crash when doing
memcpy so I'm pretty sure you're not testing this.

When I test these patches I will run it, and just report
that memcpy doesn't work if it doesn't and then you'll
have to figure it out anyway, so enjoy...

Yours,
Linus Walleij


From will.deacon at arm.com  Thu Apr 25 07:11:25 2013
From: will.deacon at arm.com (Will Deacon)
Date: Thu, 25 Apr 2013 12:11:25 +0100
Subject: [PATCH v8 1/2] arm: introduce psci_smp_ops
In-Reply-To: <alpine.DEB.2.02.1304251158080.4180@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1304241935010.4180@kaball.uk.xensource.com>
 <1366828819-10745-1-git-send-email-stefano.stabellini@eu.citrix.com>
 <20130425084711.GA12848@mudshark.cambridge.arm.com>
 <alpine.DEB.2.02.1304251104090.4180@kaball.uk.xensource.com>
 <20130425104508.GG12848@mudshark.cambridge.arm.com>
 <alpine.DEB.2.02.1304251158080.4180@kaball.uk.xensource.com>
Message-ID: <20130425111125.GI12848@mudshark.cambridge.arm.com>

On Thu, Apr 25, 2013 at 12:08:02PM +0100, Stefano Stabellini wrote:
> On Thu, 25 Apr 2013, Will Deacon wrote:
> > On Thu, Apr 25, 2013 at 11:12:54AM +0100, Stefano Stabellini wrote:
> > > However from the Linux POV these comments should regard the functions
> > > exported by psci_operations, not the firmware interface, this is why I
> > > think it makes sense to keep them in psci.h.
> > > What we are saying is for example that psci_operations.cpu_on returns 0
> > > on success and < 0 on failure, and it takes a cpuid and an entry point
> > > as parameters. We are not saying anything about the firmware interface.
> > 
> > I disagree. You're explicitly stating that we pass the `cpuid of target CPU,
> > as from MPIDR'. That's simply not true -- the firmware could choose any
> > numbering scheme to identify the CPUs. For KVM and Xen, it *is* the mpidr,
> > which is why psci-smp.c works at all, but that's where the comment belongs,
> > not in this header file.
> 
> I see, you want to keep psci_operations true to the firmware interface
> while explaining that psci_smp makes some assumptions about it.

Precisely! :)

> So the comment should be something like:
> 
> /*
>  * psci_smp assumes that the following is true about PSCI:
>  * 
>  * cpu_suspend   Suspend the execution on a CPU
>  * @state        we don't currently describe affinity levels, so just pass 0.
>  * @entry_point  the first instruction to be executed on return
>  * returns 0  success, < 0 on failure
>  *
>  * cpu_off       Power down a CPU
>  * @state        we don't currently describe affinity levels, so just pass 0.
>  * no return on successful call
>  *
>  * cpu_on        Power up a CPU
>  * @cpuid        cpuid of target CPU, as from MPIDR
>  * @entry_point  the first instruction to be executed on return
>  * returns 0  success, < 0 on failure
>  *
>  * migrate       Migrate the context to a different CPU
>  * @cpuid        cpuid of target CPU, as from MPIDR
>  * returns 0  success, < 0 on failure
>  *
>  */

That's certainly better, but I'd still rather see the comment with the
implementation as there's a greater potential for confusion having it here.

Will


From linus.walleij at linaro.org  Thu Apr 25 07:12:47 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Apr 2013 13:12:47 +0200
Subject: [PATCH 17/32] dmaengine: ste_dma40: Remove redundant argument
 from d40_phy_cfg()
In-Reply-To: <1366279934-30761-18-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-18-git-send-email-lee.jones@linaro.org>
Message-ID: <CACRpkdYuV+ZP8nW=PHgiw6KOjM9js9Mwd3-XVXCkH6wq213D0A@mail.gmail.com>

On Thu, Apr 18, 2013 at 12:11 PM, Lee Jones <lee.jones at linaro.org> wrote:

> d40_phy_cfg is now only ever called to configure physical channels, so
> there's no requirement to pass though an argument describing the type
> of channel and to subsequently test for it.
>
> Cc: Vinod Koul <vinod.koul at intel.com>
> Cc: Dan Williams <djbw at fb.com>
> Cc: Per Forlin <per.forlin at stericsson.com>
> Cc: Rabin Vincent <rabin at rab.in>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>

As mentioned, squash this into the patch where this is made redundant,
no point in first making an argument unused in one patch and then
deleting it in another patch.

Yours,
Linus Walleij


From stefano.stabellini at eu.citrix.com  Thu Apr 25 07:13:54 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Thu, 25 Apr 2013 12:13:54 +0100
Subject: [PATCH v8 1/2] arm: introduce psci_smp_ops
In-Reply-To: <20130425111125.GI12848@mudshark.cambridge.arm.com>
References: <alpine.DEB.2.02.1304241935010.4180@kaball.uk.xensource.com>
 <1366828819-10745-1-git-send-email-stefano.stabellini@eu.citrix.com>
 <20130425084711.GA12848@mudshark.cambridge.arm.com>
 <alpine.DEB.2.02.1304251104090.4180@kaball.uk.xensource.com>
 <20130425104508.GG12848@mudshark.cambridge.arm.com>
 <alpine.DEB.2.02.1304251158080.4180@kaball.uk.xensource.com>
 <20130425111125.GI12848@mudshark.cambridge.arm.com>
Message-ID: <alpine.DEB.2.02.1304251212480.4180@kaball.uk.xensource.com>

On Thu, 25 Apr 2013, Will Deacon wrote:
> On Thu, Apr 25, 2013 at 12:08:02PM +0100, Stefano Stabellini wrote:
> > On Thu, 25 Apr 2013, Will Deacon wrote:
> > > On Thu, Apr 25, 2013 at 11:12:54AM +0100, Stefano Stabellini wrote:
> > > > However from the Linux POV these comments should regard the functions
> > > > exported by psci_operations, not the firmware interface, this is why I
> > > > think it makes sense to keep them in psci.h.
> > > > What we are saying is for example that psci_operations.cpu_on returns 0
> > > > on success and < 0 on failure, and it takes a cpuid and an entry point
> > > > as parameters. We are not saying anything about the firmware interface.
> > > 
> > > I disagree. You're explicitly stating that we pass the `cpuid of target CPU,
> > > as from MPIDR'. That's simply not true -- the firmware could choose any
> > > numbering scheme to identify the CPUs. For KVM and Xen, it *is* the mpidr,
> > > which is why psci-smp.c works at all, but that's where the comment belongs,
> > > not in this header file.
> > 
> > I see, you want to keep psci_operations true to the firmware interface
> > while explaining that psci_smp makes some assumptions about it.
> 
> Precisely! :)
> 
> > So the comment should be something like:
> > 
> > /*
> >  * psci_smp assumes that the following is true about PSCI:
> >  * 
> >  * cpu_suspend   Suspend the execution on a CPU
> >  * @state        we don't currently describe affinity levels, so just pass 0.
> >  * @entry_point  the first instruction to be executed on return
> >  * returns 0  success, < 0 on failure
> >  *
> >  * cpu_off       Power down a CPU
> >  * @state        we don't currently describe affinity levels, so just pass 0.
> >  * no return on successful call
> >  *
> >  * cpu_on        Power up a CPU
> >  * @cpuid        cpuid of target CPU, as from MPIDR
> >  * @entry_point  the first instruction to be executed on return
> >  * returns 0  success, < 0 on failure
> >  *
> >  * migrate       Migrate the context to a different CPU
> >  * @cpuid        cpuid of target CPU, as from MPIDR
> >  * returns 0  success, < 0 on failure
> >  *
> >  */
> 
> That's certainly better, but I'd still rather see the comment with the
> implementation as there's a greater potential for confusion having it here.

Yeah, I forgot to write that it was supposed to go in psci_smp.c.
I am OK with that, I'll repost with this change.


From linus.walleij at linaro.org  Thu Apr 25 07:14:18 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Apr 2013 13:14:18 +0200
Subject: [PATCH 17/32] dmaengine: ste_dma40: Remove redundant argument
 from d40_phy_cfg()
In-Reply-To: <20130422101833.GI3432@gmail.com>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-18-git-send-email-lee.jones@linaro.org>
 <20130422093423.GD24632@intel.com>
 <20130422101833.GI3432@gmail.com>
Message-ID: <CACRpkdbsH=vZxMcoeW+RJQsLaKAs_Lzx2pGpbT7fO_Hk90x6Gw@mail.gmail.com>

On Mon, Apr 22, 2013 at 12:18 PM, Lee Jones <lee.jones at linaro.org> wrote:

>> > +   if ((cfg->dir ==  STEDMA40_PERIPH_TO_MEM) ||
>> > +       (cfg->dir == STEDMA40_PERIPH_TO_PERIPH)) {
>>
>> Why would you need your own direction defines, I see that there is not much
>> diff between these and what dmaengine defines, so perhpas you could use
>> those?
>
> I agree. I'll speak to the STE folk.

This is because the driver was written before the dmaengine had
the enum dma_transfer_direction.

A simple search-and-replace patch would do the trick...

Yours,
Linus Walleij


From linus.walleij at linaro.org  Thu Apr 25 07:15:58 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Apr 2013 13:15:58 +0200
Subject: [PATCH 18/32] dmaengine: ste_dma40: Don't configure runtime
 configurable setup during allocate
In-Reply-To: <1366279934-30761-19-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-19-git-send-email-lee.jones@linaro.org>
Message-ID: <CACRpkdbt0NxDoBa9=Y4eq3FH75pnMT_BkE6Tk-15=H0qnQWaHQ@mail.gmail.com>

On Thu, Apr 18, 2013 at 12:12 PM, Lee Jones <lee.jones at linaro.org> wrote:

> Using the dmaengine API, allocating and configuring a channel are two
> separate actions. Here we're removing logical channel configuration from
> the channel allocating routines.

NAK: this is not true for memcpy.

Yours,
Linus Walleij


From linus.walleij at linaro.org  Thu Apr 25 07:17:00 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Apr 2013 13:17:00 +0200
Subject: [PATCH 19/32] dmaengine: ste_dma40: Move more setup into the
 configuration routines
In-Reply-To: <1366279934-30761-20-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-20-git-send-email-lee.jones@linaro.org>
Message-ID: <CACRpkdZKib-pm3QcJ6e4MnPfjvBp1kJUB3QXeb2ie=kUhshdew@mail.gmail.com>

On Thu, Apr 18, 2013 at 12:12 PM, Lee Jones <lee.jones at linaro.org> wrote:

> The less configuration we can do during the allocation of a channel the
> better. As this will mean the likelihood of requiring extra information
> which isn't normally passed through the dma_request_channel() is lessened.
>
> Cc: Vinod Koul <vinod.koul at intel.com>
> Cc: Dan Williams <djbw at fb.com>
> Cc: Per Forlin <per.forlin at stericsson.com>
> Cc: Rabin Vincent <rabin at rab.in>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>

NAK. You're breaking memcpy.

Yours,
Linus Walleij


From linus.walleij at linaro.org  Thu Apr 25 07:17:58 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Apr 2013 13:17:58 +0200
Subject: [PATCH 20/32] dmaengine: ste_dma40: Move rev error-check up to
 revision acquisition
In-Reply-To: <1366279934-30761-21-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-21-git-send-email-lee.jones@linaro.org>
Message-ID: <CACRpkdaEK9fkcqY1So9UdUeeyJbenve+XUyk8ra7ZWQPNhobdg@mail.gmail.com>

On Thu, Apr 18, 2013 at 12:12 PM, Lee Jones <lee.jones at linaro.org> wrote:

> At the moment we fetch the hardware revision, then do some stuff, then
> check whether the revision is correct and return in error if it's not.
> Well we may as well check it as soon as we know what it is, so let's
> move the check right up underneath where we acquire the version.
>
> Cc: Vinod Koul <vinod.koul at intel.com>
> Cc: Dan Williams <djbw at fb.com>
> Cc: Per Forlin <per.forlin at stericsson.com>
> Cc: Rabin Vincent <rabin at rab.in>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>

Reviewed-by: Linus Walleij <linus.walleij at linaro.org>

Yours,
Linus Walleij


From linus.walleij at linaro.org  Thu Apr 25 07:20:20 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Apr 2013 13:20:20 +0200
Subject: [PATCH 21/32 v2] dmaengine: ste_dma40: Also report the number of
 logical channels
In-Reply-To: <20130424083944.GG17416@gmail.com>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-22-git-send-email-lee.jones@linaro.org>
 <20130424083944.GG17416@gmail.com>
Message-ID: <CACRpkdaANF-ZA2wbfMdFcZ-4M0mAnRoJu_hZ07X75Vg_J5LiPA@mail.gmail.com>

On Wed, Apr 24, 2013 at 10:39 AM, Lee Jones <lee.jones at linaro.org> wrote:

> dmaengine: ste_dma40: Also report the number of logical channels
>
> Now we know the total of physical and logical channels, we may as
> well report them within the information log.
>
> Before:
> dma40 dma40.0: hardware revision: 3 @ 0x801c0000 with 8 physical channels
>
> After:
> <as above ...> and 256 logical channels
>
> Cc: Vinod Koul <vinod.koul at intel.com>
> Cc: Dan Williams <djbw at fb.com>
> Cc: Per Forlin <per.forlin at stericsson.com>
> Cc: Rabin Vincent <rabin at rab.in>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>

Reviewed-by: Linus Walleij <linus.walleij at linaro.org>

Yours,
Linus Walleij


From linus.walleij at linaro.org  Thu Apr 25 07:22:28 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Apr 2013 13:22:28 +0200
Subject: [PATCH 22/32] dmaengine: ste_dma40: Allocate plat_data on
 declaration
In-Reply-To: <1366279934-30761-23-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-23-git-send-email-lee.jones@linaro.org>
Message-ID: <CACRpkdaeVN1Ou9zsiDHwv_o6RPEAs8LuYJ_yQafRwLPVS9wtww@mail.gmail.com>

On Thu, Apr 18, 2013 at 12:12 PM, Lee Jones <lee.jones at linaro.org> wrote:

> It's the way that most other drivers do it.
>
> Very trivial clean-up which reduces line count and simplifies code.
>
> Cc: Vinod Koul <vinod.koul at intel.com>
> Cc: Dan Williams <djbw at fb.com>
> Cc: Per Forlin <per.forlin at stericsson.com>
> Cc: Rabin Vincent <rabin at rab.in>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>

Reviewed-by: Linus Walleij <linus.walleij at linaro.org>

Yours,
Linus Walleij


From linus.walleij at linaro.org  Thu Apr 25 07:24:39 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Apr 2013 13:24:39 +0200
Subject: [PATCH 23/32] dmaengine: ste_dma40: Allow driver to be
 probe()able when DT is enabled
In-Reply-To: <1366279934-30761-24-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-24-git-send-email-lee.jones@linaro.org>
Message-ID: <CACRpkdbq3sz-e_ySUYf6a4PiWL4C=Yk=eNFUicUu03pDhJbPig@mail.gmail.com>

On Thu, Apr 18, 2013 at 12:12 PM, Lee Jones <lee.jones at linaro.org> wrote:

> When booting using Device Tree, devices aren't registered in the normal
> way. Instead, they need to be provided with a compatible string which is
> held in an OF Match Table for comparison during start-up. Here we provide
> the compatible string and prepare the driver to not receive a platform
> data pointer.
>
> Cc: Vinod Koul <vinod.koul at intel.com>
> Cc: Dan Williams <djbw at fb.com>
> Cc: Per Forlin <per.forlin at stericsson.com>
> Cc: Rabin Vincent <rabin at rab.in>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>

Reviewed-by: Linus Walleij <linus.walleij at linaro.org>

Yours,
Linus Walleij


From shc_work at mail.ru  Thu Apr 25 07:31:07 2013
From: shc_work at mail.ru (=?UTF-8?B?QWxleGFuZGVyIFNoaXlhbg==?=)
Date: Thu, 25 Apr 2013 15:31:07 +0400
Subject: =?UTF-8?B?UmVbMl06IFtQQVRDSCAxLzJdIEdQSU86IGNscHM3MTF4OiBSZXdyaXRlIGRy?=
 =?UTF-8?B?aXZlciBmb3IgdXNpbmcgZ2VuZXJpYyBHUElPIGNvZGU=?=
In-Reply-To: <20130419140357.GR14496@n2100.arm.linux.org.uk>
References: <1365826900-30136-1-git-send-email-shc_work@mail.ru>
 <20130419140357.GR14496@n2100.arm.linux.org.uk>
Message-ID: <1366889467.845096985@f366.mail.ru>

> On Sat, Apr 13, 2013 at 08:21:39AM +0400, Alexander Shiyan wrote:
> > +static void __init clps711x_add_gpio(void)
> > +{
> > +	const struct resource clps711x_gpio0_res[] = {
> > +		DEFINE_RES_MEM(PADR, SZ_1),
> > +		DEFINE_RES_MEM(PADDR, SZ_1),
> > +	};
...
> Don't do this - this is incredibly wasteful.
> 
> C lesson 1: do not put unmodified initialised structures onto the stack.
> 
> What the C compiler will do with the above is exactly the same as this
> for each structure:
> 
> static const struct resource private_clps711x_gpio4_res[] = {
> 	DEFINE_RES_MEM(PEDR, SZ_1),
> 	DEFINE_RES_MEM(PEDDR, SZ_1),
> };
> 
> static void __init clps711x_add_gpio(void)
> {
> 	const struct resource clps711x_gpio4_res[] = private_clps711x_gpio4_res;
> 	...
> 
> which will in itself be a call out to memcpy, or an inlined memcpy.  Now
> do you see why it's wasteful?  You might as well write the thing in that
> way to start with and safe the additional code to copy the structures.
> 
> The other way to do this, which will probably be far more space efficient:
> 
> static phys_addr_t gpio_addrs[][2] = {
> 	{ PADR, PADDR },
> 	{ PBDR, PBDDR },
> ...
> };
> 
> static void __init clps711x_add_gpio(void)
> {
> 	struct resource gpio_res[2];
> 	unsigned i;
> 
> 	gpio_res[0].flags = IORESOURCE_MEM;
> 	gpio_res[1].flags = IORESOURCE_MEM;
> 
> 	for (i = 0; i < ARRAY_SIZE(gpio_addrs); i++) {
> 		gpio_res[0].start = gpio_addrs[i][0];
> 		gpio_res[0].end = gpio_res[0].start;
> 		gpio_res[1].start = gpio_addrs[i][1];
> 		gpio_res[1].end = gpio_res[1].start;
> 
> 		platform_device_register_simple("clps711x-gpio", i,
> 					gpio_res, ARRAY_SIZE(gpio_res));
> 	}
> }
> 
> which results in smaller storage and most probably also smaller code size
> too.

Very strange results with this change.
So, I add a debug output before "platform_device_register_simple" for
print resource and in "__request_resource" for print parent.
This is output.
gpio 0 [mem 0x80000000] [mem 0x80000040]
resource: root [??? 0xe3a0f000-0x00000000 flags 0xb00000]
clps711x-gpio.0: failed to claim resource 0

The first line is seems correct. But I do not understand why
parent is wrong here. Normally it should be as:
resource: root [mem 0x00000000-0xffffffff].
And it shows normal with my first version.
Have anyone any ideas?
Thanks.

---

From linus.walleij at linaro.org  Thu Apr 25 07:33:41 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Apr 2013 13:33:41 +0200
Subject: [PATCH 24/32 v3] dmaengine: ste_dma40: Supply full Device Tree
 parsing support
In-Reply-To: <20130418141752.GC3959@gmail.com>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-25-git-send-email-lee.jones@linaro.org>
 <20130418121253.GF27903@gmail.com>
 <20130418141752.GC3959@gmail.com>
Message-ID: <CACRpkdZiTCpkhLWiOU3yKJkHgg=od5qc-UemWRB07f7OE+RZ0A@mail.gmail.com>

On Thu, Apr 18, 2013 at 4:17 PM, Lee Jones <lee.jones at linaro.org> wrote:

> Using the new DMA DT bindings and API, we can register the DMA40 driver
> as Device Tree capable. Now, when a client attempts to allocate a
> channel using the DMA DT bindings via its own node, we are able to parse
> the request and allocate a channel in the correct manner.
>
> Cc: Vinod Koul <vinod.koul at intel.com>
> Cc: Dan Williams <djbw at fb.com>
> Cc: Per Forlin <per.forlin at stericsson.com>
> Cc: Rabin Vincent <rabin at rab.in>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>


This needs to be CC: to devicetree-discussed so it can be checked for OS
independence and such... Also consider including Rob Herring on posts.

> diff --git a/Documentation/devicetree/bindings/dma/ste-dma40.txt b/Documentation/devicetree/bindings/dma/ste-dma40.txt
> new file mode 100644
> index 0000000..2679a87
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/dma/ste-dma40.txt
> @@ -0,0 +1,62 @@
> +* DMA40 DMA Controller
> +
> +Required properties:
> +- compatible: "stericsson,dma40"
> +- reg: Address range of the DMAC registers
> +- reg-names: Names of the above areas to use during resource look-up
> +- interrupt: Should contain the DMAC interrupt number
> +- #dma-cells: must be <3>
> +
> +Optional properties:
> +- dma-channels: Number of channels supported by hardware - if not present
> +               the driver will attempt to obtain the information from H/W

I want you to define the memcpy channels in device tree as well.
Right now these are hardcoded into the driver and there is no way
to check whether they happen to overlap with other channels from the
device tree, i.e. a source of confusion.

Please add configuration for the static memcpy channels here.

> +#define D40_DT_FLAGS_MODE(flags)       ((flags >> 0) & 0x1)
> +#define D40_DT_FLAGS_DIR(flags)        ((flags >> 1) & 0x1)
> +#define D40_DT_FLAGS_BIG_ENDIAN(flags) ((flags >> 2) & 0x1)
> +#define D40_DT_FLAGS_FIXED_CHAN(flags) ((flags >> 3) & 0x1)
> +
> +static struct dma_chan *d40_xlate(struct of_phandle_args *dma_spec,
> +                                 struct of_dma *ofdma)
> +{
> +       struct stedma40_chan_cfg cfg;
> +       dma_cap_mask_t cap;
> +       u32 flags;
> +
> +       memset(&cfg, 0, sizeof(struct stedma40_chan_cfg));
> +
> +       dma_cap_zero(cap);
> +       dma_cap_set(DMA_SLAVE, cap);
> +
> +       cfg.dev_type = dma_spec->args[0];
> +       flags = dma_spec->args[2];
> +
> +       switch (D40_DT_FLAGS_MODE(flags)) {
> +       case 0: cfg.mode = STEDMA40_MODE_LOGICAL; break;
> +       case 1: cfg.mode = STEDMA40_MODE_PHYSICAL; break;
> +       }
> +
> +       switch (D40_DT_FLAGS_DIR(flags)) {
> +       case 0:
> +               cfg.dir = STEDMA40_MEM_TO_PERIPH;
> +               cfg.dst_info.big_endian = D40_DT_FLAGS_BIG_ENDIAN(flags);
> +               break;
> +       case 1:
> +               cfg.dir = STEDMA40_PERIPH_TO_MEM;
> +               cfg.src_info.big_endian = D40_DT_FLAGS_BIG_ENDIAN(flags);
> +               break;
> +       }
> +
> +       if (D40_DT_FLAGS_FIXED_CHAN(flags)) {
> +               cfg.phy_channel = dma_spec->args[1];
> +               cfg.use_fixed_channel = true;
> +       }
> +
> +       return dma_request_channel(cap, stedma40_filter, &cfg);
> +}

Nice! But please include handling of the memcpy channels.
(Unclear to me how to do that, but now i becomes your problem ;-)

> +       if (np) {
> +               err = of_dma_controller_register(np, d40_xlate, NULL);
> +               if (err && err != -ENODEV)
> +                       dev_err(&pdev->dev,
> +                               "could not register of_dma_controller\n");
> +       }
> +
>         dev_info(base->dev, "initialized\n");
>         return 0;

Is it really OK to just fall through after failing to register the controller
from the device tree?

Yours,
Linus Walleij


From linus.walleij at linaro.org  Thu Apr 25 07:35:52 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Apr 2013 13:35:52 +0200
Subject: [PATCH 25/32] ARM: ux500: Setup the DMA40 driver's DT node using
 the new DMA API
In-Reply-To: <1366279934-30761-26-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-26-git-send-email-lee.jones@linaro.org>
Message-ID: <CACRpkdYR5CeVLprpjMAp2Vo0hQAP1witQd8pa22ek9OzRFe3yQ@mail.gmail.com>

On Thu, Apr 18, 2013 at 12:12 PM, Lee Jones <lee.jones at linaro.org> wrote:

> The new DMA is now available, so let's use it to setup ST-Ericsson's
> DMA40 driver when Device Tree is enabled.
>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>

This is one of those patches I want to put on a special devicetree
branch, but looks allright, Acked-by: Linus Walleij <linus.walleij at linaro.org>

Yours,
Linus Walleij


From linus.walleij at linaro.org  Thu Apr 25 07:36:46 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Apr 2013 13:36:46 +0200
Subject: [PATCH 26/32] ARM: ux500: Supply UART's DMA configuration via
 Device Tree
In-Reply-To: <1366279934-30761-27-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-27-git-send-email-lee.jones@linaro.org>
Message-ID: <CACRpkdZDQuFDb396fYtjZNr=O-5vrTHs+UwS5bqp8wet1PA93A@mail.gmail.com>

On Thu, Apr 18, 2013 at 12:12 PM, Lee Jones <lee.jones at linaro.org> wrote:

> When requesting a channel, a DMA client needs to pass some pieces of
> information such as; request channel, device type, channel type and
> direction etc. Normally we do this in the form of platform data, but
> when DT is enabled we need to pass it using the driver's bindings
> instead.
>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>

Acked-by: Linus Walleij <linus.walleij at linaro.org>

Yours,
Linus Walleij


From mpa at pengutronix.de  Thu Apr 25 07:37:16 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Thu, 25 Apr 2013 13:37:16 +0200
Subject: [PATCH v5 07/10] ASoC: fsl-ssi: imx ac97 support
In-Reply-To: <20130425035029.GB1276@S2101-09.ap.freescale.net>
References: <1366814199-14827-1-git-send-email-mpa@pengutronix.de>
 <1366814199-14827-8-git-send-email-mpa@pengutronix.de>
 <20130425035029.GB1276@S2101-09.ap.freescale.net>
Message-ID: <20130425113716.GB27763@pengutronix.de>

On Thu, Apr 25, 2013 at 11:50:30AM +0800, Shawn Guo wrote:
> On Wed, Apr 24, 2013 at 04:36:36PM +0200, Markus Pargmann wrote:
> > +/*
> > + * Pointer to AC97 reset functions for specific boards
> > + */
> > +#if IS_ENABLED(CONFIG_MACH_PCA100)
> > +extern void pca100_ac97_cold_reset(struct snd_ac97 *ac97);
> > +extern void pca100_ac97_warm_reset(struct snd_ac97 *ac97);
> > +#else
> > +void pca100_ac97_cold_reset(struct snd_ac97 *ac97) { }
> > +void pca100_ac97_warm_reset(struct snd_ac97 *ac97) { }
> > +#endif
> > +
> > +#if IS_ENABLED(CONFIG_MACH_PCM043)
> > +extern void pcm043_ac97_cold_reset(struct snd_ac97 *ac97);
> > +extern void pcm043_ac97_warm_reset(struct snd_ac97 *ac97);
> > +#else
> > +void pcm043_ac97_cold_reset(struct snd_ac97 *ac97) { }
> > +void pcm043_ac97_warm_reset(struct snd_ac97 *ac97) { }
> > +#endif
> ...
> > @@ -717,13 +956,39 @@ static int fsl_ssi_probe(struct platform_device *pdev)
> >  
> >  	strcpy(ssi_private->name, p);
> >  
> > -	/* Initialize this copy of the CPU DAI driver structure */
> > -	memcpy(&ssi_private->cpu_dai_drv, &fsl_ssi_dai_template,
> > -	       sizeof(fsl_ssi_dai_template));
> > -	ssi_private->cpu_dai_drv.name = ssi_private->name;
> > -
> >  	ssi_private->use_dma = !of_property_read_bool(np, "fsl,imx-fiq");
> >  
> > +	if (ac97) {
> > +		sprop = of_get_property(of_find_node_by_path("/"), "compatible",
> > +				NULL);
> > +		p = strrchr(sprop, ',');
> > +		if (p)
> > +			sprop = p + 1;
> > +
> > +		if (!strcmp(sprop, "imx27-pca100")) {
> > +			ssi_private->ac97_reset = pca100_ac97_cold_reset;
> > +			ssi_private->ac97_warm_reset = pca100_ac97_warm_reset;
> > +		} else if (!strcmp(sprop, "imx27-pcm043")) {
> > +			ssi_private->ac97_reset = pcm043_ac97_cold_reset;
> > +			ssi_private->ac97_warm_reset = pcm043_ac97_warm_reset;
> > +		} else {
> > +			dev_err(&pdev->dev, "Failed to enable ssi AC97 mode, unknown board.\n");
> > +			ret = -EINVAL;
> > +			goto error_kmalloc;
> > +		}
> 
> I do not like these board specific hooks show up in an IP driver
> in such way.  Can we work it out in other ways, notification or even
> platform_data with auxdata?

soc_ac97_ops is a global symbol, so we could setup soc_ac97_ops.reset
and warm_reset in board specific ac97 drivers. For this patch I would
move the assignment of reset functions to phycore-ac97.c which already
is specifically for this codec-ssi combination on the two boards.

Regards,

Markus

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From linus.walleij at linaro.org  Thu Apr 25 07:37:26 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Apr 2013 13:37:26 +0200
Subject: [PATCH 27/32] ARM: ux500: Stop registering DMA40 from platform
 data when DT is enabled
In-Reply-To: <1366279934-30761-28-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-28-git-send-email-lee.jones@linaro.org>
Message-ID: <CACRpkdZiXb-sKW+WhWyFFvXwW1V+EEUhZFLHhZKYh5Utp1tWtw@mail.gmail.com>

On Thu, Apr 18, 2013 at 12:12 PM, Lee Jones <lee.jones at linaro.org> wrote:

> Now the DMA40 has been DT:ed, there's no requirement to register it
> using traditional methods. This is the penultimate device to be DT:ed.
>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>

Acked-by: Linus Walleij <linus.walleij at linaro.org>

Yours,
Linus Walleij


From linus.walleij at linaro.org  Thu Apr 25 07:39:06 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Apr 2013 13:39:06 +0200
Subject: [PATCH 28/32] ARM: ux500: Pass remnant platform data though to
 DMA40 driver
In-Reply-To: <1366279934-30761-29-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-29-git-send-email-lee.jones@linaro.org>
Message-ID: <CACRpkdYrpxt0DZutX=XhYUoj112+m26h60WO-Yf8BOo+ONfNHw@mail.gmail.com>

On Thu, Apr 18, 2013 at 12:12 PM, Lee Jones <lee.jones at linaro.org> wrote:

> Ironically, in order to remove lots of the auxdata assignments, we have
> to add just one more. A lot of them require DMA information to be passed
> into clients for DMA channel allocation, but we now have this capability
> in Device Tree. However, the DMA40 driver still relies on a reverse table
> look-up to obtain DMA addresses. Until all of the clients are converted,
> over to the new API, we're stuck with this.
>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>

As mentioned merge into patch 27, then ACK.

Yours,
Linus Walleij


From linux at arm.linux.org.uk  Thu Apr 25 07:40:41 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Thu, 25 Apr 2013 12:40:41 +0100
Subject: [PATCH 1/2] GPIO: clps711x: Rewrite driver for using generic
 GPIO code
In-Reply-To: <1366889467.845096985@f366.mail.ru>
References: <1365826900-30136-1-git-send-email-shc_work@mail.ru>
 <20130419140357.GR14496@n2100.arm.linux.org.uk>
 <1366889467.845096985@f366.mail.ru>
Message-ID: <20130425114041.GC14496@n2100.arm.linux.org.uk>

On Thu, Apr 25, 2013 at 03:31:07PM +0400, Alexander Shiyan wrote:
> > On Sat, Apr 13, 2013 at 08:21:39AM +0400, Alexander Shiyan wrote:
> > > +static void __init clps711x_add_gpio(void)
> > > +{
> > > +	const struct resource clps711x_gpio0_res[] = {
> > > +		DEFINE_RES_MEM(PADR, SZ_1),
> > > +		DEFINE_RES_MEM(PADDR, SZ_1),
> > > +	};
> ...
> > Don't do this - this is incredibly wasteful.
> > 
> > C lesson 1: do not put unmodified initialised structures onto the stack.
> > 
> > What the C compiler will do with the above is exactly the same as this
> > for each structure:
> > 
> > static const struct resource private_clps711x_gpio4_res[] = {
> > 	DEFINE_RES_MEM(PEDR, SZ_1),
> > 	DEFINE_RES_MEM(PEDDR, SZ_1),
> > };
> > 
> > static void __init clps711x_add_gpio(void)
> > {
> > 	const struct resource clps711x_gpio4_res[] = private_clps711x_gpio4_res;
> > 	...
> > 
> > which will in itself be a call out to memcpy, or an inlined memcpy.  Now
> > do you see why it's wasteful?  You might as well write the thing in that
> > way to start with and safe the additional code to copy the structures.
> > 
> > The other way to do this, which will probably be far more space efficient:
> > 
> > static phys_addr_t gpio_addrs[][2] = {
> > 	{ PADR, PADDR },
> > 	{ PBDR, PBDDR },
> > ...
> > };
> > 
> > static void __init clps711x_add_gpio(void)
> > {
> > 	struct resource gpio_res[2];
> > 	unsigned i;
> > 
> > 	gpio_res[0].flags = IORESOURCE_MEM;
> > 	gpio_res[1].flags = IORESOURCE_MEM;
> > 
> > 	for (i = 0; i < ARRAY_SIZE(gpio_addrs); i++) {
> > 		gpio_res[0].start = gpio_addrs[i][0];
> > 		gpio_res[0].end = gpio_res[0].start;
> > 		gpio_res[1].start = gpio_addrs[i][1];
> > 		gpio_res[1].end = gpio_res[1].start;
> > 
> > 		platform_device_register_simple("clps711x-gpio", i,
> > 					gpio_res, ARRAY_SIZE(gpio_res));
> > 	}
> > }
> > 
> > which results in smaller storage and most probably also smaller code size
> > too.
> 
> Very strange results with this change.
> So, I add a debug output before "platform_device_register_simple" for
> print resource and in "__request_resource" for print parent.
> This is output.
> gpio 0 [mem 0x80000000] [mem 0x80000040]
> resource: root [??? 0xe3a0f000-0x00000000 flags 0xb00000]
> clps711x-gpio.0: failed to claim resource 0
> 
> The first line is seems correct. But I do not understand why
> parent is wrong here. Normally it should be as:
> resource: root [mem 0x00000000-0xffffffff].
> And it shows normal with my first version.
> Have anyone any ideas?

memset(&gpio_res, 0, sizeof(gpio_res));


From linus.walleij at linaro.org  Thu Apr 25 07:41:32 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Apr 2013 13:41:32 +0200
Subject: [PATCH 29/32] ARM: ux500: Stop passing UART's platform data for
 Device Tree boots
In-Reply-To: <1366279934-30761-30-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-30-git-send-email-lee.jones@linaro.org>
Message-ID: <CACRpkdadOsBSB3PNhhmguO5v6VbMMMrjLytYQrtcdY0CsOVKUQ@mail.gmail.com>

On Thu, Apr 18, 2013 at 12:12 PM, Lee Jones <lee.jones at linaro.org> wrote:

> It was required to pass DMA channel configuration information to the
> UART driver before the new DMA API was in place. Now that it is, and
> is fully compatible with Device Tree we can stop doing that.
>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>

Removes a nasty dependency to the board file as well!
Reviewed-by: Linus Walleij <linus.walleij at linaro.org>

Yours,
Linus Walleij


From linus.walleij at linaro.org  Thu Apr 25 07:43:18 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Apr 2013 13:43:18 +0200
Subject: [PATCH 30/32] ARM: ux500: Supply MMC DMA configuration via Device
 Tree
In-Reply-To: <1366279934-30761-31-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-31-git-send-email-lee.jones@linaro.org>
Message-ID: <CACRpkdbYXxkC2y9zCNcMAAmmQ7+3V0Y=hq7zgtp5L=Ts9QzpQQ@mail.gmail.com>

On Thu, Apr 18, 2013 at 12:12 PM, Lee Jones <lee.jones at linaro.org> wrote:

> When requesting a channel, a DMA client needs to pass some pieces of
> information such as; request channel, device type, channel type and
> direction etc. Normally we do this in the form of platform data, but
> when DT is enabled we need to pass it using the driver's bindings
> instead.
>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>

This requires that the pending MMCI patch get merged *first* right?

So you need to make sure Russell will merge that (or ACK it
and include it) before you send any pull requests to me.

Apart from that it looks allright:
Acked-by: Linus Walleij <linus.walleij at linaro.org>

Yours,
Linus Walleij


From linus.walleij at linaro.org  Thu Apr 25 07:44:12 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Apr 2013 13:44:12 +0200
Subject: [PATCH 31/32] ARM: ux500: Stop passing MMC's platform data for
 Device Tree boots
In-Reply-To: <1366279934-30761-32-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-32-git-send-email-lee.jones@linaro.org>
Message-ID: <CACRpkdaF3he9X7fd88TrmtNK8g1U4jUEuy6QpKG0Hg8srXWbng@mail.gmail.com>

On Thu, Apr 18, 2013 at 12:12 PM, Lee Jones <lee.jones at linaro.org> wrote:

> It was required to pass DMA channel configuration information to the
> MMC driver before the new DMA API was in place. Now that it is, and
> is fully compatible with Device Tree we can stop doing that.
>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>

Really nice provided the dependencies are in place.
Reviewed-by: Linus Walleij <linus.walleij at linaro.org>

Yours,
Linus Walleij


From linus.walleij at linaro.org  Thu Apr 25 07:46:22 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Apr 2013 13:46:22 +0200
Subject: [PATCH 32/32] ARM: ux500: Move SDI (MMC) and UART devices under
 more descriptive heading
In-Reply-To: <1366279934-30761-33-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-33-git-send-email-lee.jones@linaro.org>
Message-ID: <CACRpkdbxwPh+j_=CBFeH83n0XHSbcShnZ7Reb54+5cWYL-j3-w@mail.gmail.com>

On Thu, Apr 18, 2013 at 12:12 PM, Lee Jones <lee.jones at linaro.org> wrote:

> Now DMA DT bindings exist and are in use by he MMC and UART drivers, it
> should be possible to remove them from the auxdata structure. However,
> after doing so the drivers fail. Something must be reliant on the dev
> name applied by using auxdata; probably common clk.
>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>

You can remove "probably" from that sentence. Common clock is
still relying on dev_name() to match the device name.

There are some example of how to fix this, I recently sent a patch
series fixing DT probed clocks for the Nomadik, check it out.

Reviewed-by: Linus Walleij <linus.walleij at linaro.org>

Yours,
Linus Walleij


From linus.walleij at linaro.org  Thu Apr 25 07:49:06 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Apr 2013 13:49:06 +0200
Subject: [PATCH 1/9 v2] crypto: ux500/hash - Prepare clock before enabling
 it
In-Reply-To: <20130419122428.GC3432@gmail.com>
References: <1366280825-31136-1-git-send-email-lee.jones@linaro.org>
 <1366280825-31136-2-git-send-email-lee.jones@linaro.org>
 <20130419122428.GC3432@gmail.com>
Message-ID: <CACRpkdYrCA6SduwMJF=7C9hyjP2Or7gxhjVFtLshdzkbYnxX1w@mail.gmail.com>

On Fri, Apr 19, 2013 at 2:24 PM, Lee Jones <lee.jones at linaro.org> wrote:
> Slight change of plan for v2.
>
> Now we're doing a seperate clk_prepare(), as the clk_enable() in the
> previous patch turned out to be called inside a spin_lock().
>
> Arnd, can you confirm your Ack please?

Do you really want letters to Arnd to be part of the commit log?

>
> ---

Note: stuff following the three dashes (---) will be *omitted*
from the change log. This seems to be turned upside-down.

>
> crypto: ux500/hash - Prepare clock before enabling it
>
> If we fail to prepare the ux500-hash clock before enabling it the
> platform will fail to boot. Here we insure this happens.
>
> Cc: Herbert Xu <herbert at gondor.apana.org.au>
> Cc: David S. Miller <davem at davemloft.net>
> Cc: Andreas Westin <andreas.westin at stericsson.com>
> Cc: linux-crypto at vger.kernel.org
> Acked-by: Arnd Bergmann <arnd at arndb.de>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>

Pls include Ulf Hansson <ulf.hansson at linaro.org> on this patch.

Yours,
Linus Walleij


From lee.jones at linaro.org  Thu Apr 25 07:49:31 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Thu, 25 Apr 2013 12:49:31 +0100
Subject: [PATCH 30/32] ARM: ux500: Supply MMC DMA configuration via
 Device Tree
In-Reply-To: <CACRpkdbYXxkC2y9zCNcMAAmmQ7+3V0Y=hq7zgtp5L=Ts9QzpQQ@mail.gmail.com>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-31-git-send-email-lee.jones@linaro.org>
 <CACRpkdbYXxkC2y9zCNcMAAmmQ7+3V0Y=hq7zgtp5L=Ts9QzpQQ@mail.gmail.com>
Message-ID: <20130425114931.GJ4623@gmail.com>

On Thu, 25 Apr 2013, Linus Walleij wrote:

> On Thu, Apr 18, 2013 at 12:12 PM, Lee Jones <lee.jones at linaro.org> wrote:
> 
> > When requesting a channel, a DMA client needs to pass some pieces of
> > information such as; request channel, device type, channel type and
> > direction etc. Normally we do this in the form of platform data, but
> > when DT is enabled we need to pass it using the driver's bindings
> > instead.
> >
> > Signed-off-by: Lee Jones <lee.jones at linaro.org>
> 
> This requires that the pending MMCI patch get merged *first* right?

No, it doesn't. There is no harm in applying this *before*.

It will just lay dormant until it is.

> So you need to make sure Russell will merge that (or ACK it
> and include it) before you send any pull requests to me.
> 
> Apart from that it looks allright:
> Acked-by: Linus Walleij <linus.walleij at linaro.org>

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From linus.walleij at linaro.org  Thu Apr 25 07:55:39 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Apr 2013 13:55:39 +0200
Subject: [PATCH 2/9] crypto: ux500/hash - Set DMA configuration though
 dma_slave_config()
In-Reply-To: <1366280825-31136-3-git-send-email-lee.jones@linaro.org>
References: <1366280825-31136-1-git-send-email-lee.jones@linaro.org>
 <1366280825-31136-3-git-send-email-lee.jones@linaro.org>
Message-ID: <CACRpkda0sE+KgdagN0CsRsoDFR+VoUzh2jaipB_1BtShYpBCcg@mail.gmail.com>

Pls include Magnus.p.persson at stericsson.com on all these crypto/hash
postings.

On Thu, Apr 18, 2013 at 12:26 PM, Lee Jones <lee.jones at linaro.org> wrote:

> The DMA controller currently takes configuration information from
> information passed though dma_channel_request(), but it shouldn't.
> Using the API, the DMA channel should only be configured during
> a dma_slave_config() call.
>
> Cc: Herbert Xu <herbert at gondor.apana.org.au>
> Cc: David S. Miller <davem at davemloft.net>
> Cc: Andreas Westin <andreas.westin at stericsson.com>
> Cc: linux-crypto at vger.kernel.org
> Signed-off-by: Lee Jones <lee.jones at linaro.org>

(...)
>  #define HASH_BLOCK_SIZE                        64
> +#define HASH_DMA_FIFO                  4

This is an address so write 0x0004 here please. Some hex notation atleast.

>  /**
>   * struct hash_device_data - structure for a hash device.
> - * @base:              Pointer to the hardware base address.
> + * @base:              Pointer to virtual base address of the hash device.
> + * @phybase:           Pointer to physical memory location of the hash device.
>   * @list_node:         For inclusion in klist.
>   * @dev:               Pointer to the device dev structure.
>   * @ctx_lock:          Spinlock for current_ctx.
> @@ -361,6 +363,7 @@ struct hash_req_ctx {
>   */
>  struct hash_device_data {
>         struct hash_register __iomem    *base;
> +       phys_addr_t             phybase;

What you pass to the config function is a dma_addr_t actually.

This is the same thing on the platform, but generally:

phys_addr_t = in the address space as the memory controller sees it.
dma_addr_t = in the address space as the DMA controller sees it.

Often the same. Not always. So use dma_addr_t.

Apart from this a real nice patch!

Yours,
Linus Walleij


From linus.walleij at linaro.org  Thu Apr 25 07:56:18 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Apr 2013 13:56:18 +0200
Subject: [PATCH 3/9] ARM: ux500: Stop passing Hash DMA channel config
 information though pdata
In-Reply-To: <1366280825-31136-4-git-send-email-lee.jones@linaro.org>
References: <1366280825-31136-1-git-send-email-lee.jones@linaro.org>
 <1366280825-31136-4-git-send-email-lee.jones@linaro.org>
Message-ID: <CACRpkdZoTD1J7pSfpO37Xhj6NPn86N7fK0zP_dimGYm=B3AUMQ@mail.gmail.com>

On Thu, Apr 18, 2013 at 12:26 PM, Lee Jones <lee.jones at linaro.org> wrote:

> DMA channel configuration information should be setup in the driver.
> The Ux500 Hash driver now does this, so there's no need to send it
> though here too.
>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>

When 2/9 is fixed up:
Reviewed-by: Linus Walleij <linus.walleij at linaro.org>

Yours,
Linus Walleij


From linus.walleij at linaro.org  Thu Apr 25 07:57:50 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Apr 2013 13:57:50 +0200
Subject: [PATCH 4/9 v2] crypto: ux500/cryp - Prepare clock before enabling
 it
In-Reply-To: <20130419122226.GB3432@gmail.com>
References: <1366280825-31136-1-git-send-email-lee.jones@linaro.org>
 <1366280825-31136-5-git-send-email-lee.jones@linaro.org>
 <20130419122226.GB3432@gmail.com>
Message-ID: <CACRpkdZT-XFyDExKVppWi4NEN7XptSex10LCtAHOpZD71nom3g@mail.gmail.com>

On Fri, Apr 19, 2013 at 2:22 PM, Lee Jones <lee.jones at linaro.org> wrote:

> Slight change of plan for v2.
>
> Now we're doing a seperate clk_prepare(), as the clk_enable() in the
> previous patch turned out to be called inside a spin_lock().
>
> Arnd, can you confirm your Ack please?
>
> ----
>
> crypto: ux500/cryp - Prepare clock before enabling it
>
> If we fail to prepare the ux500-cryp clock before enabling it the
> platform will fail to boot. Here we insure this happens.
>
> Cc: Herbert Xu <herbert at gondor.apana.org.au>
> Cc: David S. Miller <davem at davemloft.net>
> Cc: Andreas Westin <andreas.westin at stericsson.com>
> Cc: linux-crypto at vger.kernel.org
> Acked-by: Arnd Bergmann <arnd at arndb.de>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>

Same formatting problems as the other prepare/enable
patch. Include Ulf Hansson.

(Apart from this it looks OK.)

Yours,
Linus Walleij


From linus.walleij at linaro.org  Thu Apr 25 08:00:00 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Apr 2013 14:00:00 +0200
Subject: [PATCH 5/9] crypto: ux500/cryp - Fix compile error
In-Reply-To: <1366280825-31136-6-git-send-email-lee.jones@linaro.org>
References: <1366280825-31136-1-git-send-email-lee.jones@linaro.org>
 <1366280825-31136-6-git-send-email-lee.jones@linaro.org>
Message-ID: <CACRpkdZNFqbHJB7R5zqVzkAn_nV=G+c27YRB7VCQxiMyFTnPbg@mail.gmail.com>

On Thu, Apr 18, 2013 at 12:27 PM, Lee Jones <lee.jones at linaro.org> wrote:

> Clearly this driver hasn't been tested, or even enabled in a while.
>
> drivers/crypto/ux500/cryp/cryp_core.c:1771:3:
>         error: request for member ?pm? in something not a structure or union
>
> Cc: Herbert Xu <herbert at gondor.apana.org.au>
> Cc: David S. Miller <davem at davemloft.net>
> Cc: Andreas Westin <andreas.westin at stericsson.com>
> Cc: linux-crypto at vger.kernel.org
> Signed-off-by: Lee Jones <lee.jones at linaro.org>

NAK. I already fixed this. It is in v3.9-rc7.

Yours,
Linus Walleij


From linus.walleij at linaro.org  Thu Apr 25 08:02:11 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Apr 2013 14:02:11 +0200
Subject: [PATCH 6/9] crypto: ux500/cryp - Set DMA configuration though
 dma_slave_config()
In-Reply-To: <1366280825-31136-7-git-send-email-lee.jones@linaro.org>
References: <1366280825-31136-1-git-send-email-lee.jones@linaro.org>
 <1366280825-31136-7-git-send-email-lee.jones@linaro.org>
Message-ID: <CACRpkdbFgW6bGYt59WtN4r2izuN09AJw4J1cqir82uzFsuMmWQ@mail.gmail.com>

On Thu, Apr 18, 2013 at 12:27 PM, Lee Jones <lee.jones at linaro.org> wrote:

> The DMA controller currently takes configuration information from
> information passed though dma_channel_request(), but it shouldn't.
> Using the API, the DMA channel should only be configured during
> a dma_slave_config() call.
>
> Cc: Herbert Xu <herbert at gondor.apana.org.au>
> Cc: David S. Miller <davem at davemloft.net>
> Cc: Andreas Westin <andreas.westin at stericsson.com>
> Cc: linux-crypto at vger.kernel.org
> Signed-off-by: Lee Jones <lee.jones at linaro.org>

(...)
>  /* Cryp DMA interface */
> +#define HASH_DMA_TX_FIFO       0x08
> +#define HASH_DMA_RX_FIFO       0x10

Yes, this is nice address notation :-)

>  /**
>   * struct cryp_device_data - structure for a cryp device.
> - * @base: Pointer to the hardware base address.
> + * @base: Pointer to virtual base address of the cryp device.
> + * @phybase: Pointer to physical memory location of the cryp device.
>   * @dev: Pointer to the devices dev structure.
>   * @clk: Pointer to the device's clock control.
>   * @pwr_regulator: Pointer to the device's power control.
> @@ -232,6 +236,7 @@ struct cryp_dma {
>   */
>  struct cryp_device_data {
>         struct cryp_register __iomem *base;
> +       phys_addr_t phybase;

Use dma_addr_t. Maybe "phybase" is misleading,
"dmabase" is probably better. (Also applies to the
cryp patch).

Apart from that it looks allright.

Yours,
Linus Walleij


From linus.walleij at linaro.org  Thu Apr 25 08:02:58 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Apr 2013 14:02:58 +0200
Subject: [PATCH 7/9] ARM: ux500: Stop passing Cryp DMA channel config
 information though pdata
In-Reply-To: <1366280825-31136-8-git-send-email-lee.jones@linaro.org>
References: <1366280825-31136-1-git-send-email-lee.jones@linaro.org>
 <1366280825-31136-8-git-send-email-lee.jones@linaro.org>
Message-ID: <CACRpkdaXGGXvjakokLfXTrw5YmdGY9TNs1XO6XF370QQC4Z6Dw@mail.gmail.com>

On Thu, Apr 18, 2013 at 12:27 PM, Lee Jones <lee.jones at linaro.org> wrote:

> DMA channel configuration information should be setup in the driver.
> The Ux500 Cryp driver now does this, so there's no need to send it
> though here too.
>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>

Provided the deps are in place:
Reviewed-by: Linus Walleij <linus.walleij at linaro.org>

Yours,
Linus Walleij


From linus.walleij at linaro.org  Thu Apr 25 08:03:57 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Apr 2013 14:03:57 +0200
Subject: [PATCH 8/9] crypto: ux500/[cryp|hash] - Show successful start-up
 in the bootlog
In-Reply-To: <1366280825-31136-9-git-send-email-lee.jones@linaro.org>
References: <1366280825-31136-1-git-send-email-lee.jones@linaro.org>
 <1366280825-31136-9-git-send-email-lee.jones@linaro.org>
Message-ID: <CACRpkdYLQtdqCmJ_tt=1DtNeeZVWkL+S6tBG74Li9kOkU25b4A@mail.gmail.com>

On Thu, Apr 18, 2013 at 12:27 PM, Lee Jones <lee.jones at linaro.org> wrote:

> The Cryp driver is currently silent and the Hash driver prints the
> name of its probe function unnecessarily. Let's just put a nice
> descriptive one-liner there instead.
>
> Cc: Herbert Xu <herbert at gondor.apana.org.au>
> Cc: David S. Miller <davem at davemloft.net>
> Cc: Andreas Westin <andreas.westin at stericsson.com>
> Cc: linux-crypto at vger.kernel.org
> Signed-off-by: Lee Jones <lee.jones at linaro.org>

Reviewed-by: Linus Walleij <linus.walleij at linaro.org>

Yours,
Linus Walleij


From linus.walleij at linaro.org  Thu Apr 25 08:04:38 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Apr 2013 14:04:38 +0200
Subject: [PATCH 9/9] ARM: ux500: Register Cyrp and Hash platform drivers
 on Snowball
In-Reply-To: <1366280825-31136-10-git-send-email-lee.jones@linaro.org>
References: <1366280825-31136-1-git-send-email-lee.jones@linaro.org>
 <1366280825-31136-10-git-send-email-lee.jones@linaro.org>
Message-ID: <CACRpkdafij8an62xwcZ=TeF7a9Sv6MAuF3RHtkjhrStTygw7PQ@mail.gmail.com>

On Thu, Apr 18, 2013 at 12:27 PM, Lee Jones <lee.jones at linaro.org> wrote:

> These drivers are now operational and even use the latest common clk
> and DMA APIs. There's no reason why we shouldn't start them up now.
>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>

Reviewed-by: Linus Walleij <linus.walleij at linaro.org>

Yours,
Linus Walleij


From linus.walleij at linaro.org  Thu Apr 25 08:09:11 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Apr 2013 14:09:11 +0200
Subject: [PATCH] cpuidle: add maintainer entry
In-Reply-To: <87k3nr50n4.fsf@linaro.org>
References: <1366810463-17495-1-git-send-email-daniel.lezcano@linaro.org>
 <87k3nr50n4.fsf@linaro.org>
Message-ID: <CACRpkdaA8uG5jYyYTbuvzZNRr47EhWHFMLLz+jbiE3FPC1vjmA@mail.gmail.com>

On Wed, Apr 24, 2013 at 6:55 PM, Kevin Hilman <khilman at linaro.org> wrote:
> Rafael,
>
> Daniel Lezcano <daniel.lezcano at linaro.org> writes:
>
> [...]
>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 61677c3..effa0f3 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -2206,6 +2206,13 @@ S:     Maintained
>>  F:   drivers/cpufreq/
>>  F:   include/linux/cpufreq.h
>>
>> +CPUIDLE DRIVERS
>> +M:   Rafael J. Wysocki <rjw at sisk.pl>
>> +L:   linux-pm at vger.kernel.org
>> +S:   Maintained
>> +F:   drivers/cpuidle/*
>> +F:   include/linux/cpuidle.h
>
> What do you think about having Daniel listed here as a co-maintainer?

I second that. He will bring useful embedded knowledge to the
subsystem.

Yours,
Linus Walleij


From linux at arm.linux.org.uk  Thu Apr 25 08:15:04 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Thu, 25 Apr 2013 13:15:04 +0100
Subject: [PATCH] ARM: make cpu_init() notrace
In-Reply-To: <1366654116.3989.16.camel@computer5.home>
References: <1366302046.3388.8.camel@linaro1.home>
 <20130422140711.GI14496@n2100.arm.linux.org.uk>
 <1366654116.3989.16.camel@computer5.home>
Message-ID: <20130425121504.GD14496@n2100.arm.linux.org.uk>

On Mon, Apr 22, 2013 at 07:08:36PM +0100, Jon Medhurst (Tixy) wrote:
> On Mon, 2013-04-22 at 15:07 +0100, Russell King - ARM Linux wrote:
> > On Thu, Apr 18, 2013 at 05:20:46PM +0100, Jon Medhurst (Tixy) wrote:
> > > On resume from CPU power down any trace hooks enabled in cpu_init()
> > > will get called before that function has done set_my_cpu_offset(),
> > > so any use of per-cpu variables by trace hook code will cause bad
> > > things to happen. Prevent this by marking the function notrace.
> > > 
> > > This fixes lockups/crashes seen when enabling function tracer on TC2
> > > with the not yet mainlined cpuidle driver.
> > 
> > Looks sane.  Needs to go to the patch system though.  Not sure if it'll
> > make 3.9 given its proximity (we're on -rc8).
> 
> Added as patch 7700/1. Don't think there is a big rush as the problem
> has probably been there since 3.8 when commit 14318efb (implement
> optimized percpu variable access) started using TPIDRPRW; which is
> presumably lost over CPU power down.

$ pdb getpatch 7700/1 |tr ' ' '_' |less
diff_--git_a/arch/arm/kernel/setup.c_b/arch/arm/kernel/setup.c
index_d343a6c..943cbf0_100644
---_a/arch/arm/kernel/setup.c
+++_b/arch/arm/kernel/setup.c
@@_-390,7_+390,7_@@_static_void___init_feat_v6_fixup(void)
__*
__*_cpu_init_sets_up_the_per-CPU_stacks.
__*/
-void_cpu_init(void)
+void_notrace_cpu_init(void)
_{
________unsigned_int_cpu_=_smp_processor_id();
________struct_stack_*stk_=_&stacks[cpu];

Can you guess why git has a problem appying the above... you seem to
have sent the patch from your mailer, I guess your mailer thinks it
knows better when it comes to what characters should be in your
message... or maybe its a cut'n'paste issue?


From linus.walleij at linaro.org  Thu Apr 25 08:43:16 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Apr 2013 14:43:16 +0200
Subject: [PATCH 04/32] dmaengine: ste_dma40: Amalgamate DMA source and
 destination channel numbers
In-Reply-To: <20130425090612.GC4623@gmail.com>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-5-git-send-email-lee.jones@linaro.org>
 <CACRpkdaauDYTdoBHGG9FO4kKqvCYyCrjY8EGWs5gAQWErGW6_A@mail.gmail.com>
 <20130425090612.GC4623@gmail.com>
Message-ID: <CACRpkdbV8yEK0470q_-DWv6Q0hAG2wGntXFi5kaLUMgm9b=e-Q@mail.gmail.com>

On Thu, Apr 25, 2013 at 11:06 AM, Lee Jones <lee.jones at linaro.org> wrote:

>> Are we now sacrificing that ability on the altar of simplification?
>>
>> I actually think not, but that we should do periph-to-periph transfers
>> in some other way, and that the .dir attribute should go away from
>> the struct stedma40_chan_cfg as well but I'm not entirely sure.
>> Someone else?
>
> Although the DMA40 device supports device-to-device transfers, Linux
> does not, so this subject is moot AFAICT.

So while there is no active usecase, Linux surely has the ambition to do
that as can be seen in:

/**
 * enum dma_transfer_direction - dma transfer mode and direction indicator
 * @DMA_MEM_TO_MEM: Async/Memcpy mode
 * @DMA_MEM_TO_DEV: Slave mode & From Memory to Device
 * @DMA_DEV_TO_MEM: Slave mode & From Device to Memory
 * @DMA_DEV_TO_DEV: Slave mode & From Device to Device
 */
enum dma_transfer_direction {
        DMA_MEM_TO_MEM,
        DMA_MEM_TO_DEV,
        DMA_DEV_TO_MEM,
        DMA_DEV_TO_DEV,
        DMA_TRANS_NONE,
};

I think we need a handshake with Vinod on this.

>> If you're doing this change, and after this RX and TX has no semantical
>> meaning for these lists, join these two config lists
>> into one.
>
> I agree. See patch: ARM: ux500: Strip out duplicate USB DMA configuration

Please squash the applicable portions into this patch then, I don't
particularly like fix-later patchstack patterns, it makes series hard to
review.

>> (...)
>> > diff --git a/arch/arm/mach-ux500/usb.c b/arch/arm/mach-ux500/usb.c
>> >  static u32 d40_chan_has_events(struct d40_chan *d40c)
>> > @@ -1744,8 +1740,6 @@ static int d40_validate_conf(struct d40_chan *d40c,
>> >                              struct stedma40_chan_cfg *conf)
>> >  {
>> >         int res = 0;
>> > -       u32 dst_event_group = D40_TYPE_TO_GROUP(conf->dst_dev_type);
>> > -       u32 src_event_group = D40_TYPE_TO_GROUP(conf->src_dev_type);
>>
>> Please explain why this is not important to check anymore, I'm not
>> following.
>>
>> >         if (conf->dir == STEDMA40_MEM_TO_PERIPH &&
>> > -           dst_event_group == STEDMA40_DEV_DST_MEMORY) {
>> > -               chan_err(d40c, "Invalid dst\n");
>> > +           d40c->base->plat_data->dev_tx[conf->dev_type] == 0 &&
>> > +           d40c->runtime_addr == 0) {
>> > +               chan_err(d40c, "Invalid TX channel address (%d)\n",
>> > +                        conf->dev_type);
>>
>> Like here. We are checking for inconsistency between group
>> and channel direction, why is it no longer important to check this?
>
> I'm not entirely sure how this ever worked:
>
>   #define D40_TYPE_TO_GROUP(type) (type / 16)
>   #define STEDMA40_DEV_DST_MEMORY (-1)
>
>   (dev_type / 16) == -1
>
> What number would dev_type have to be for this to be true? -16?

No, since it's u32 it cannot really represent negative numbers.

This is equivalent:
#define D40_TYPE_TO_GROUP(type) (type >> 4)

As -1 is 0xffffffff in u32 it will compare at best
0x0fffffff to 0xfffffff. And that is non-attainable.

So the line checking event group for == DTEDMA40_DEV_DST_MEMORY
should be  removed in a separate patch prior to this one, with
something like the above as commit message.

We cannot really mix that cleanup into this patch...

>> >         if (conf->dir == STEDMA40_PERIPH_TO_MEM &&
>> > -           src_event_group == STEDMA40_DEV_SRC_MEMORY) {
>> > -               chan_err(d40c, "Invalid src\n");
>> > -               res = -EINVAL;
>> > -       }
>
> As above.

And same comment.

>> > -       if (conf->dir == STEDMA40_PERIPH_TO_PERIPH &&
>> > -           (src_event_group != dst_event_group)) {
>> > -               chan_err(d40c, "Invalid event group\n");
>> > +           d40c->base->plat_data->dev_rx[conf->dev_type] == 0 &&
>> > +           d40c->runtime_addr == 0) {
>> > +               chan_err(d40c, "Invalid RX channel address (%d)\n",
>> > +                        conf->dev_type);
>>
>> Same here.
>
> I stopped all 'dev_src/dev_dest' comparisons, as there is only 'dev' now.

It is checking for:
conf->dir == STEDMA40_PERIPH_TO_PERIPH

As we may want to support DEV_TO_DEV at some point.

Then no longer, and that is not related to $SUBJECT.

>> (...)
>> > @@ -2062,7 +2035,7 @@ static int d40_free_dma(struct d40_chan *d40c)
>> >  {
>> >
>> >         int res = 0;
>> > -       u32 event;
>> > +       u32 event = D40_TYPE_TO_EVENT(d40c->dma_cfg.dev_type);
>> >         struct d40_phy_res *phy = d40c->phy_chan;
>> >         bool is_src;
>> >
>> > @@ -2081,13 +2054,11 @@ static int d40_free_dma(struct d40_chan *d40c)
>> >         }
>> >
>> >         if (d40c->dma_cfg.dir == STEDMA40_MEM_TO_PERIPH ||
>> > -           d40c->dma_cfg.dir == STEDMA40_MEM_TO_MEM) {
>> > -               event = D40_TYPE_TO_EVENT(d40c->dma_cfg.dst_dev_type);
>> > +           d40c->dma_cfg.dir == STEDMA40_MEM_TO_MEM)
>>
>> Why did you just stop checking dma_cfg.dir for == STEDMA40_MEM_TO_MEM
>> above?
>
> That's not what this is doing. STEDMA40_MEM_TO_MEM is still there.
>
>> And why is dma_cfg.dir suddenly hardcoded to MEM_TO_MEM??
>
> It's not. Look again. :)

Argh I misread == MEM_TO_MEM for = MEM_TO_MEM ...
comparison to assignment. Sorry.

>> This seems like a totally unrelated change and should it be done
>> it need to be a separate patch with a separate explanation
>> AFAICT.
>>
>> This seems to happen in some other places too,
>
> If you could point those out, I'll re-evaluate, or explain.

I'm after that the change to omit checks for some impossible
type/group configs need to be a separate patch.

>> and I find it
>> very hard to follow the changes here ... can you please consider
>> splitting the changes to groups and types semantics into a separate
>> patch?
>
> Can you read the patch again and reconsider please?

Yes and now I am even more convinced that the patch needs
to be split.

Yours,
Linus Walleij


From linus.walleij at linaro.org  Thu Apr 25 08:45:54 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Apr 2013 14:45:54 +0200
Subject: [PATCH 07/32] ARM: ux500: Supply address location names for the
 DMA40 DMA controller
In-Reply-To: <20130425091744.GF4623@gmail.com>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-8-git-send-email-lee.jones@linaro.org>
 <CACRpkdbCMjC22WbgE_-Co-hvT704n696Ox8t_6_d2aoxmZyybA@mail.gmail.com>
 <20130425091744.GF4623@gmail.com>
Message-ID: <CACRpkdbhygnrtosb5PRQ_5JbURpeH7pM-xj-m1wLP8Yq3HCLcg@mail.gmail.com>

On Thu, Apr 25, 2013 at 11:17 AM, Lee Jones <lee.jones at linaro.org> wrote:
> On Thu, 25 Apr 2013, Linus Walleij wrote:
>
>> On Thu, Apr 18, 2013 at 12:11 PM, Lee Jones <lee.jones at linaro.org> wrote:
>>
>> > The DMA40 controller uses two sets of base addresses. In order to have
>> > them automatically setup as resources by the Open Format framework we
>> > have to set names for them. The names have to be the same as the ones
>> > used to fetch them back out of the resource structure.
>> >
>> > Signed-off-by: Lee Jones <lee.jones at linaro.org>
>>
>> This is OK with Arnds suggested changed, but I want the patch
>> split off from this series and put into a device-tree-specific patch
>> series so I can apply this to a branch where I try to keep
>> all patches to the device tree files. (ux500-devicetree).
>
> Do you want to take this one separately?
>
> Feel free and I'll remove it from this set.

The problem I'm facing in the ux500 tree is that different changes
to the device tree files are colliding like hell.

So I really need those changes (to those files) to come in
separately. Usually the changes are orthogonal anyway, and
the DT stuff "could" be maintained as if it was out-of-tree.

At the core of that is basically that the DT files have a higher
evolutionary pace than the kernel code and that is straining the
merge model.

Yours,
Linus Walleij


From linus.walleij at linaro.org  Thu Apr 25 08:48:34 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Apr 2013 14:48:34 +0200
Subject: [PATCH 08/32 v2] dmaengine: ste_dma40: Remove home-brew MAX()
 macro
In-Reply-To: <20130424084912.GH17416@gmail.com>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-9-git-send-email-lee.jones@linaro.org>
 <20130424084912.GH17416@gmail.com>
Message-ID: <CACRpkdaaa+gmsimkJVmhwv+zE+4ZmgZQ=AtHPry9=_EMScMC=w@mail.gmail.com>

On Wed, Apr 24, 2013 at 10:49 AM, Lee Jones <lee.jones at linaro.org> wrote:

> The current implementation of the DMA40's local MAX() macro evaluates
> its arguments more times than is necessary and it not type checked.
> This patch strips replaces it with a new, more efficient constant.
>
> Cc: Vinod Koul <vinod.koul at intel.com>
> Cc: Dan Williams <djbw at fb.com>
> Cc: Per Forlin <per.forlin at stericsson.com>
> Cc: Rabin Vincent <rabin at rab.in>
> Reported-by: Harvey Harrison <harvey.harrison at gmail.com>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>

Ah this v2 version is OK, atleast it makes the kernel look nicer.
Acked-by: Linus Walleij <linus.walleij at linaro.org>

Yours,
Linus Walleij


From linus.walleij at linaro.org  Thu Apr 25 08:49:59 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Apr 2013 14:49:59 +0200
Subject: [PATCH 09/32] ARM: ux500: Remove unused 'data_width' attributes
 from SDI DMA configs
In-Reply-To: <20130425091428.GD4623@gmail.com>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-10-git-send-email-lee.jones@linaro.org>
 <CACRpkdbf03ajQaYujGfimHE+hDVjNLycE3J9Q-W-tzN2EX0fkQ@mail.gmail.com>
 <20130425091428.GD4623@gmail.com>
Message-ID: <CACRpkdaeuK0p2SynenQjght9fCzTTJpt+S7hGC6d6ahPHAA7Hw@mail.gmail.com>

On Thu, Apr 25, 2013 at 11:14 AM, Lee Jones <lee.jones at linaro.org> wrote:
> On Thu, 25 Apr 2013, Linus Walleij wrote:
>
>> On Thu, Apr 18, 2013 at 12:11 PM, Lee Jones <lee.jones at linaro.org> wrote:
>>
>> > DMA configuration data is now allocated in the MMCI driver, so these
>> > are just ignored.
>> >
>> > Signed-off-by: Lee Jones <lee.jones at linaro.org>
>>
>> Reviewed-by: Linus Walleij <linus.walleij at linaro.org>
>>
>> I tried just applying this (since it's pretty stand-alone) but seems to
>> be dependent on things not yet in Torvalds tree so lets keep it in this
>> series then...
>
> Ideally I'd like to keep them all in the same branch, as it may lead
> to confusion/conflicts later down the line (I'm still coding a lot of
> this stuff).
>
> Naturally, I'll go with whatever you think is best, but this is my
> preference.

This works find for now, I just want the DT changes kept separately
because I'm in hell with these right now and don't want to end up
there again next merge cycle.

Yours,
Linus Walleij


From linus.walleij at linaro.org  Thu Apr 25 08:51:51 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Apr 2013 14:51:51 +0200
Subject: [PATCH 13/32] dmaengine: ste_dma40: Calculate number of logical
 channels from physical ones
In-Reply-To: <20130425092930.GI4623@gmail.com>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-14-git-send-email-lee.jones@linaro.org>
 <CACRpkdYq9QLRaaysc=izGgi53ogf1oRHuCwWKW+rQBbE_UtfnA@mail.gmail.com>
 <20130425092930.GI4623@gmail.com>
Message-ID: <CACRpkdYywbCeP7wemk2Vy81rm9q3VUbpkN1jUs6UBPLVSOoyHw@mail.gmail.com>

On Thu, Apr 25, 2013 at 11:29 AM, Lee Jones <lee.jones at linaro.org> wrote:
> On Thu, 25 Apr 2013, Linus Walleij wrote:
>
>> On Thu, Apr 18, 2013 at 12:11 PM, Lee Jones <lee.jones at linaro.org> wrote:
>>
>> > This change will cost ~25KB of memory, but it's worth the trade-off,
>> > as it removes a great deal of overhead. It means that instead of only
>> > allocating memory for the logical channels in use, it does so for all
>> > available ones, which is 32 per physical channel. However, this now
>> > means we can remove some platform data and we don't have to worry
>> > about adding vendor specific variables to Device Tree.
>> >
>> > Cc: Vinod Koul <vinod.koul at intel.com>
>> > Cc: Dan Williams <djbw at fb.com>
>> > Cc: Per Forlin <per.forlin at stericsson.com>
>> > Cc: Rabin Vincent <rabin at rab.in>
>> > Signed-off-by: Lee Jones <lee.jones at linaro.org>
>>
>> (...)
>> >  static struct stedma40_platform_data dma40_plat_data = {
>> > -       .dev_len = DB8500_DMA_NR_DEV,
>>
>> So that was set to 64 in the platform...
>>
>> > -       /* Count the number of logical channels in use */
>> > -       for (i = 0; i < plat_data->dev_len; i++)
>> > -               if (plat_data->dev_rx[i] != 0)
>> > -                       num_log_chans++;
>> > -
>> > -       for (i = 0; i < plat_data->dev_len; i++)
>> > -               if (plat_data->dev_tx[i] != 0)
>> > -                       num_log_chans++;
>>
>> And I guess this code snippet made it go down to <= 32 all the time,
>> correct?
>
> However many were described in dma40_[rx|tx]_map, yes.

OK how fragile, but definately not your fault.
Acked-by: Linus Walleij <linus.walleij at linaro.org>

Yours,
Linus Walleij


From linus.walleij at linaro.org  Thu Apr 25 08:56:40 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Apr 2013 14:56:40 +0200
Subject: [PATCH 30/32] ARM: ux500: Supply MMC DMA configuration via Device
 Tree
In-Reply-To: <20130425114931.GJ4623@gmail.com>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-31-git-send-email-lee.jones@linaro.org>
 <CACRpkdbYXxkC2y9zCNcMAAmmQ7+3V0Y=hq7zgtp5L=Ts9QzpQQ@mail.gmail.com>
 <20130425114931.GJ4623@gmail.com>
Message-ID: <CACRpkdbnGbVwqnY=aPU5Jic88v7VAsDWaB0yDU3iMo=YLCd9EQ@mail.gmail.com>

On Thu, Apr 25, 2013 at 1:49 PM, Lee Jones <lee.jones at linaro.org> wrote:
> On Thu, 25 Apr 2013, Linus Walleij wrote:
>
>> On Thu, Apr 18, 2013 at 12:12 PM, Lee Jones <lee.jones at linaro.org> wrote:
>>
>> > When requesting a channel, a DMA client needs to pass some pieces of
>> > information such as; request channel, device type, channel type and
>> > direction etc. Normally we do this in the form of platform data, but
>> > when DT is enabled we need to pass it using the driver's bindings
>> > instead.
>> >
>> > Signed-off-by: Lee Jones <lee.jones at linaro.org>
>>
>> This requires that the pending MMCI patch get merged *first* right?
>
> No, it doesn't. There is no harm in applying this *before*.
>
> It will just lay dormant until it is.

Ah yeah, right. But the patch stripping out the platform data (no 31) will
wreak havoc if applied before the MMCI patch right?

Yours,
Linus Walleij


From marc.zyngier at arm.com  Thu Apr 25 08:59:43 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu, 25 Apr 2013 13:59:43 +0100
Subject: [PATCH v3 08/32] arm64: KVM: architecture specific MMU backend
In-Reply-To: <CAEDV+g+H+NFc5gsQYBmQDx598Oz3BHWHcrYhBYsWPbXaVYataA@mail.gmail.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
 <1365437854-30214-9-git-send-email-marc.zyngier@arm.com>
 <20130423225816.GC20569@gmail.com>	<5177BBEE.1090209@arm.com>
 <CAEDV+g+H+NFc5gsQYBmQDx598Oz3BHWHcrYhBYsWPbXaVYataA@mail.gmail.com>
Message-ID: <517928BF.8090309@arm.com>

On 24/04/13 17:55, Christoffer Dall wrote:
> On Wed, Apr 24, 2013 at 4:03 AM, Marc Zyngier <marc.zyngier at arm.com> wrote:
>> On 23/04/13 23:58, Christoffer Dall wrote:
>>> On Mon, Apr 08, 2013 at 05:17:10PM +0100, Marc Zyngier wrote:
>>>> Define the arm64 specific MMU backend:
>>>> - HYP/kernel VA offset
>>>> - S2 4/64kB definitions
>>>> - S2 page table populating and flushing
>>>> - icache cleaning
>>>>
>>>> Reviewed-by: Christopher Covington <cov at codeaurora.org>
>>>> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
>>>> ---
>>>>  arch/arm64/include/asm/kvm_mmu.h | 136 +++++++++++++++++++++++++++++++++++++++
>>>>  1 file changed, 136 insertions(+)
>>>>  create mode 100644 arch/arm64/include/asm/kvm_mmu.h
>>>>
>>>> diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h
>>>> new file mode 100644
>>>> index 0000000..2eb2230
>>>> --- /dev/null
>>>> +++ b/arch/arm64/include/asm/kvm_mmu.h
>>>> @@ -0,0 +1,136 @@
>>>> +/*
>>>> + * Copyright (C) 2012,2013 - ARM Ltd
>>>> + * Author: Marc Zyngier <marc.zyngier at arm.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.
>>>> + *
>>>> + * This program is distributed in the hope that it will be useful,
>>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>>>> + * GNU General Public License for more details.
>>>> + *
>>>> + * You should have received a copy of the GNU General Public License
>>>> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
>>>> + */
>>>> +
>>>> +#ifndef __ARM64_KVM_MMU_H__
>>>> +#define __ARM64_KVM_MMU_H__
>>>> +
>>>> +#include <asm/page.h>
>>>> +#include <asm/memory.h>
>>>> +
>>>> +/*
>>>> + * As we only have the TTBR0_EL2 register, we cannot express
>>>> + * "negative" addresses. This makes it impossible to directly share
>>>> + * mappings with the kernel.
>>>> + *
>>>> + * Instead, give the HYP mode its own VA region at a fixed offset from
>>>> + * the kernel by just masking the top bits (which are all ones for a
>>>> + * kernel address).
>>>
>>> For some reason I keep choking on this, despite it being very simple.
>>> We're just defining a different PAGE_OFFSET, right? Why not do a hard
>>> define as:
>>>
>>> #define HYP_PAGE_OFFSET_MASK  0x0000ffffffffffff
>>> #define HYP_PAGE_OFFSET               0x0000ffc000000000
>>>
>>> ...or change the second paragraph of the comment to say
>>> that we definethe HYP_PAGE_OFFSET to be 0x 0000ffc0 00000000.
>>
>> One of these days, VA_BITS will change to accommodate for more virtual
>> space. When that day comes, I don't want to touch any of this because it
>> did hurt enough when writing it. As such, I'll refrain from hardcoding
>> anything.
>>
>> I don't mind a comment, though.
>>
>>>> + */
>>>> +#define HYP_PAGE_OFFSET_SHIFT       VA_BITS
>>>> +#define HYP_PAGE_OFFSET_MASK        ((UL(1) << HYP_PAGE_OFFSET_SHIFT) - 1)
>>>
>>> In any case, is there a reason for the HYP_PAGE_OFFSET_SHIFT
>>> indirection? It may be simpler without...
>>
>> It is common practice to have XXX_SHIFT and XXX_MASK together.
>>
>>>> +#define HYP_PAGE_OFFSET             (PAGE_OFFSET & HYP_PAGE_OFFSET_MASK)
>>>> +
>>>> +/*
>>>> + * Our virtual mapping for the idmap-ed MMU-enable code. Must be
>>>> + * shared across all the page-tables. Conveniently, we use the last
>>>> + * possible page, where no kernel mapping will ever exist.
>>>> + */
>>>> +#define TRAMPOLINE_VA               (HYP_PAGE_OFFSET_MASK & PAGE_MASK)
>>>
>>> hmmm, ok, here it's kind of nice to have that define correlation, so
>>> maybe it's not cleaner.  Something should be improved here in the define
>>> or the comment to make it more clear.  Perhaps just adding the real
>>> constants in the comment or in Documentation/arm64/memory.txt would
>>> help.
>>
>> Yes, I plan to write something there.
>>
>>>> +
>>>> +#ifdef __ASSEMBLY__
>>>> +
>>>> +/*
>>>> + * Convert a kernel VA into a HYP VA.
>>>> + * reg: VA to be converted.
>>>> + */
>>>> +.macro kern_hyp_va  reg
>>>> +    and     \reg, \reg, #HYP_PAGE_OFFSET_MASK
>>>> +.endm
>>>> +
>>>> +#else
>>>> +
>>>> +#include <asm/cacheflush.h>
>>>> +
>>>> +#define KERN_TO_HYP(kva)    ((unsigned long)kva - PAGE_OFFSET + HYP_PAGE_OFFSET)
>>>> +
>>>> +/*
>>>> + * Align KVM with the kernel's view of physical memory. Should be
>>>> + * 40bit IPA, with PGD being 8kB aligned.
>>>> + */
>>>> +#define KVM_PHYS_SHIFT      PHYS_MASK_SHIFT
>>>> +#define KVM_PHYS_SIZE       (1UL << KVM_PHYS_SHIFT)
>>>> +#define KVM_PHYS_MASK       (KVM_PHYS_SIZE - 1UL)
>>>> +
>>>> +#ifdef CONFIG_ARM64_64K_PAGES
>>>> +#define PAGE_LEVELS 2
>>>> +#define BITS_PER_LEVEL      13
>>>> +#else  /* 4kB pages */
>>>> +#define PAGE_LEVELS 3
>>>> +#define BITS_PER_LEVEL      9
>>>> +#endif
>>>
>>> What are the semantics of these defines exactly? They should be
>>> S2_PAGE_LEVELS and make some assumptions of the VTCR_EL2.SL0 field
>>> right?
>>
>> Indeed, we assume SL0 is always 1, just like for the kernel. As for the
>> semantics, I though they were pretty obvious...
>>
> 
> this is all stage2 right? so S2_PAGE_LEVELS may be more clear...

It actually applies to both host Stage-1, HYP Stage-1 and guest Stage-2
(we keep all page tables the same on the host side).

>> PAGE_LEVELS is just that, the number of page levels. BITS_PER_LEVEL is
>> the number of bits you need to index a particular level.
>>
>>>> +
>>>> +/* Make sure we get the right size, and thus the right alignment */
>>>
>>> this comment is not particularly helpful, something explaining why the
>>> max() thingy below makes sense would be more so :)  I really can't
>>> follow the BITS_PER_S2_PGD and PTRS_PER_S2_PGD defines.
>>
>> Admittedly, they are a bit convoluted:
>>
>>>> +#define BITS_PER_S2_PGD (KVM_PHYS_SHIFT - (PAGE_LEVELS - 1) * BITS_PER_LEVEL - PAGE_SHIFT)
>>
>> This is how many bits of index you need in a PGD. With a 40bit IPA and a
>> 4kB page size, you end up with a 10 bit index.
>>
> 
> oh, I see it now, you're basically taking away all the other bits you
> know are used to find your address and consider the remaining amount
> the necessary number of bits used to index into the PGD. Right? So I
> think at least a comment saying that BITS_ indicates bits used for
> indexing, not bits for a single entry or something else...
> 
>>>> +#define PTRS_PER_S2_PGD (1 << max(BITS_PER_LEVEL, BITS_PER_S2_PGD))
>>
>> Now, in order to allocate your PGD, you need to find out how many
>> pointers your PGD is going to contain. The max() is make sure we
>> allocate at least a full page worth of pointers.
> 
> I still don't get this, sorry. Can you provide me with the sane
> counter example where BITS_PER_S2_PGD is not sufficient?

Just take the above example, but with a 38 bit IPA. You end up with 8
bit of index, which only gives you half a page worth of pointers. Yet,
the PGD must be at least page aligned, hence using at least
BITS_PER_LEVEL (9 bits in this example).

Admittedly, that's a contrived example, as we don't support 38bit IPAs.
But now try with 64kB pages. A 40bit IPA gives you 11 bits of index in
your PGD. Clearly too short.

Does it make more sense now?

	M.
-- 
Jazz is not dead. It just smells funny...



From linus.walleij at linaro.org  Thu Apr 25 09:01:23 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Apr 2013 15:01:23 +0200
Subject: [PATCH 01/10] usb: musb: ux500: move channel number knowledge
 into the driver
In-Reply-To: <1366729394-11406-2-git-send-email-lee.jones@linaro.org>
References: <1366729394-11406-1-git-send-email-lee.jones@linaro.org>
 <1366729394-11406-2-git-send-email-lee.jones@linaro.org>
Message-ID: <CACRpkdYs_dZoqfMFbXFPgWd2m4ssn8HO9QZf0+_01fM-YBcDrw@mail.gmail.com>

Now that Fabio has written a few patches to this driver I'd like his help
in reviewing this series, can you make sure he gets a copy? Also
please include Praveena and Mian, thanks.

On Tue, Apr 23, 2013 at 5:03 PM, Lee Jones <lee.jones at linaro.org> wrote:

> For all ux500 based platforms the maximum number of end-points are used.
> Move this knowledge into the driver so we can relinquish the burden from
> platform data. This also removes quite a bit of complexity from the driver
> and will aid us when we come to enable the driver for Device Tree.
>
> Cc: Felipe Balbi <balbi at ti.com>
> Cc: linux-usb at vger.kernel.org
> Signed-off-by: Lee Jones <lee.jones at linaro.org>

Looks good to me.
Acked-by: Linus Walleij <linus.walleij at linaro.org>

Yours,
Linus Walleij


From tixy at linaro.org  Thu Apr 25 09:02:45 2013
From: tixy at linaro.org (Jon Medhurst (Tixy))
Date: Thu, 25 Apr 2013 14:02:45 +0100
Subject: [PATCH] mfd: vexpress: Handle pending config transactions
In-Reply-To: <1366821084-12815-1-git-send-email-pawel.moll@arm.com>
References: <1366821084-12815-1-git-send-email-pawel.moll@arm.com>
Message-ID: <1366894965.3528.19.camel@computer5.home>

On Wed, 2013-04-24 at 17:31 +0100, Pawel Moll wrote:
> The config transactions "scheduler" was hopelessly broken,
> repeating completed transaction instead of picking up
> next pending one.
> 
> Fixed now. Also improved debug messages.
> 
> Signed-off-by: Pawel Moll <pawel.moll at arm.com>
> ---
>  drivers/mfd/vexpress-config.c |   31 ++++++++++++++++++++-----------
>  1 file changed, 20 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/mfd/vexpress-config.c b/drivers/mfd/vexpress-config.c
> index 3c1723aa..4991db3 100644
> --- a/drivers/mfd/vexpress-config.c
> +++ b/drivers/mfd/vexpress-config.c
> @@ -184,13 +184,14 @@ static int vexpress_config_schedule(struct vexpress_config_trans *trans)
>  
>  	spin_lock_irqsave(&bridge->transactions_lock, flags);
>  
> -	vexpress_config_dump_trans("Executing", trans);
> -
> -	if (list_empty(&bridge->transactions))
> +	if (list_empty(&bridge->transactions)) {
> +		vexpress_config_dump_trans("Executing", trans);
>  		status = bridge->info->func_exec(trans->func->func,
>  				trans->offset, trans->write, trans->data);
> -	else
> +	} else {
> +		vexpress_config_dump_trans("Queuing", trans);
>  		status = VEXPRESS_CONFIG_STATUS_WAIT;
> +	}
>  
>  	switch (status) {
>  	case VEXPRESS_CONFIG_STATUS_DONE:
> @@ -217,20 +218,28 @@ void vexpress_config_complete(struct vexpress_config_bridge *bridge,
>  
>  	trans = list_first_entry(&bridge->transactions,
>  			struct vexpress_config_trans, list);
> +	trans->status = status;
>  	vexpress_config_dump_trans("Completed", trans);
>  
> -	trans->status = status;
>  	list_del(&trans->list);
>  
> -	if (!list_empty(&bridge->transactions)) {
> -		vexpress_config_dump_trans("Pending", trans);
> +	complete(&trans->completion);
> +
> +	while (!list_empty(&bridge->transactions)) {
> +		trans = list_first_entry(&bridge->transactions,
> +				struct vexpress_config_trans, list);
>  
> -		bridge->info->func_exec(trans->func->func, trans->offset,
> -				trans->write, trans->data);
> +		vexpress_config_dump_trans("Executing pending", trans);
> +		status = bridge->info->func_exec(trans->func->func,
> +				trans->offset, trans->write, trans->data);
> +
> +		if (status == VEXPRESS_CONFIG_STATUS_DONE)
> +			vexpress_config_dump_trans("Finished pending", trans);
> +		else
> +			break;

For each transaction we execute in this loop, don't we also need to do
the actions vexpress_config_complete does? E.g.

	trans->status = status;
	list_del(&trans->list);
	complete(&trans->completion);

except in the case status==VEXPRESS_CONFIG_STATUS_WAIT.

Or, does the call to func_exec cause vexpress_config_complete() to be
called later? (It hadn't better be called synchronously or we get a
deadlock).

Actually, if it is called later, there is still a problem because if the
call to func_exec returns VEXPRESS_CONFIG_STATUS_DONE then the
transaction is left on the list and the while loop will try and execute
it again.

>  	}
> -	spin_unlock_irqrestore(&bridge->transactions_lock, flags);
>  
> -	complete(&trans->completion);
> +	spin_unlock_irqrestore(&bridge->transactions_lock, flags);
>  }
>  EXPORT_SYMBOL(vexpress_config_complete);
>  

-- 
Tixy



From linus.walleij at linaro.org  Thu Apr 25 09:02:56 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Apr 2013 15:02:56 +0200
Subject: [PATCH 02/10] usb: musb: ux500: move the MUSB HDRC configuration
 into the driver
In-Reply-To: <1366729394-11406-3-git-send-email-lee.jones@linaro.org>
References: <1366729394-11406-1-git-send-email-lee.jones@linaro.org>
 <1366729394-11406-3-git-send-email-lee.jones@linaro.org>
Message-ID: <CACRpkdZbHy9CX+b1zUAyuFWw4+9VffG2KVx4CgqdHtHpP4w40A@mail.gmail.com>

On Tue, Apr 23, 2013 at 5:03 PM, Lee Jones <lee.jones at linaro.org> wrote:

> The MUSB HDRC configuration never changes between each of the ux500
> supported platforms, so there's little point passing it though platform
> data. If we set it in the driver instead, we can make good use of it
> when booting with either ATAGs or Device Tree.
>
> Cc: Felipe Balbi <balbi at ti.com>
> Cc: linux-usb at vger.kernel.org
> Signed-off-by: Lee Jones <lee.jones at linaro.org>

Acked-by: Linus Walleij <linus.walleij at linaro.org>

Yours,
Linus Walleij


From linus.walleij at linaro.org  Thu Apr 25 09:04:01 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Apr 2013 15:04:01 +0200
Subject: [PATCH 03/10] usb: musb: ux500: take the dma_mask from
 coherent_dma_mask
In-Reply-To: <1366729394-11406-4-git-send-email-lee.jones@linaro.org>
References: <1366729394-11406-1-git-send-email-lee.jones@linaro.org>
 <1366729394-11406-4-git-send-email-lee.jones@linaro.org>
Message-ID: <CACRpkdZv8b7F6XotTUriP1hOgtabBpCUPyU6D9nYSZQU8x431w@mail.gmail.com>

On Tue, Apr 23, 2013 at 5:03 PM, Lee Jones <lee.jones at linaro.org> wrote:

> The dma_mask will always be the same as the coherent_dma_mask, so let's
> cut down on the platform_data burden and set it as such in the driver.
> This also saves us from supporting it separately when we come to enable
> this driver for Device Tree.
>
> Cc: Felipe Balbi <balbi at ti.com>
> Cc: linux-usb at vger.kernel.org
> Signed-off-by: Lee Jones <lee.jones at linaro.org>

And makes it way more readable too!

Acked-by: Linus Walleij <linus.walleij at linaro.org>

Yours,
Linus Walleij


From linus.walleij at linaro.org  Thu Apr 25 09:06:06 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Apr 2013 15:06:06 +0200
Subject: [PATCH 04/10 v2] usb: musb: ux500: harden checks for platform data
In-Reply-To: <20130424150406.GD9652@gmail.com>
References: <1366729394-11406-1-git-send-email-lee.jones@linaro.org>
 <1366729394-11406-5-git-send-email-lee.jones@linaro.org>
 <20130424150406.GD9652@gmail.com>
Message-ID: <CACRpkdZY7bEH36mMo3fggTuyOhWe-E-YF=BUCt4zBReOzPuk-Q@mail.gmail.com>

On Wed, Apr 24, 2013 at 5:04 PM, Lee Jones <lee.jones at linaro.org> wrote:

> In its current state, the ux500-musb driver uses platform data pointers
> blindly with no prior checking. If no platform data pointer is passed
> this will Oops the kernel. In this patch we ensure platform data and
> board data are present prior to using them.
>
> Cc: Felipe Balbi <balbi at ti.com>
> Cc: linux-usb at vger.kernel.org
> Signed-off-by: Lee Jones <lee.jones at linaro.org>

Acked-by: Linus Walleij <linus.walleij at linaro.org>

Yours,
Linus Walleij


From linus.walleij at linaro.org  Thu Apr 25 09:08:41 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Apr 2013 15:08:41 +0200
Subject: [PATCH 05/10 v2] usb: musb: ux500: attempt to find channels by
 name before using pdata
In-Reply-To: <20130424150521.GE9652@gmail.com>
References: <1366729394-11406-1-git-send-email-lee.jones@linaro.org>
 <1366729394-11406-6-git-send-email-lee.jones@linaro.org>
 <20130424150521.GE9652@gmail.com>
Message-ID: <CACRpkdac6zF0fZfGCkXDAKqc+ZtxvU4RXYMurgcM9612Xj07Yw@mail.gmail.com>

On Wed, Apr 24, 2013 at 5:05 PM, Lee Jones <lee.jones at linaro.org> wrote:

> If we can ever get to a state where we can solely search for DMA channels
> by name, this will almost completely alleviate the requirement to pass
> copious amounts of information though platform data. Here we take the
> first step towards this. The next step will be to enable Device Tree
> complete with name<->event_line mapping.
>
> Cc: Felipe Balbi <balbi at ti.com>
> Cc: linux-usb at vger.kernel.org
> Signed-off-by: Lee Jones <lee.jones at linaro.org>

Looking good, would be nice if Arnd checked it tho.
Acked-by: Linus Walleij <linus.walleij at linaro.org>

Yours,
Linus Walleij


From linux at arm.linux.org.uk  Thu Apr 25 09:09:22 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Thu, 25 Apr 2013 14:09:22 +0100
Subject: [PATCH 04/32] dmaengine: ste_dma40: Amalgamate DMA source and
 destination channel numbers
In-Reply-To: <CACRpkdbV8yEK0470q_-DWv6Q0hAG2wGntXFi5kaLUMgm9b=e-Q@mail.gmail.com>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-5-git-send-email-lee.jones@linaro.org>
 <CACRpkdaauDYTdoBHGG9FO4kKqvCYyCrjY8EGWs5gAQWErGW6_A@mail.gmail.com>
 <20130425090612.GC4623@gmail.com>
 <CACRpkdbV8yEK0470q_-DWv6Q0hAG2wGntXFi5kaLUMgm9b=e-Q@mail.gmail.com>
Message-ID: <20130425130922.GE14496@n2100.arm.linux.org.uk>

On Thu, Apr 25, 2013 at 02:43:16PM +0200, Linus Walleij wrote:
> So while there is no active usecase, Linux surely has the ambition to do
> that as can be seen in:
> 
> /**
>  * enum dma_transfer_direction - dma transfer mode and direction indicator
>  * @DMA_MEM_TO_MEM: Async/Memcpy mode
>  * @DMA_MEM_TO_DEV: Slave mode & From Memory to Device
>  * @DMA_DEV_TO_MEM: Slave mode & From Device to Memory
>  * @DMA_DEV_TO_DEV: Slave mode & From Device to Device
>  */
> enum dma_transfer_direction {
>         DMA_MEM_TO_MEM,
>         DMA_MEM_TO_DEV,
>         DMA_DEV_TO_MEM,
>         DMA_DEV_TO_DEV,
>         DMA_TRANS_NONE,
> };
> 
> I think we need a handshake with Vinod on this.

DEV_TO_DEV was added when the change to dma_transfer_direction happened,
to "fill in" the full pattern.

There's a problem with device to device transfers though - you have to
consider the rate at which the devices produce and consume data, and
whether they both can cope with differing data rates.

Take for instance your audio in to audio out idea - even if they are
both operating at the same bits per sample and sample rate, if they are
independently clocked, chances are that the clocks are not exactly the
same, which means you will either underrun or overrun one of the FIFOs
in the system.


From lee.jones at linaro.org  Thu Apr 25 09:11:29 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Thu, 25 Apr 2013 14:11:29 +0100
Subject: [PATCH 30/32] ARM: ux500: Supply MMC DMA configuration via
 Device Tree
In-Reply-To: <CACRpkdbnGbVwqnY=aPU5Jic88v7VAsDWaB0yDU3iMo=YLCd9EQ@mail.gmail.com>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-31-git-send-email-lee.jones@linaro.org>
 <CACRpkdbYXxkC2y9zCNcMAAmmQ7+3V0Y=hq7zgtp5L=Ts9QzpQQ@mail.gmail.com>
 <20130425114931.GJ4623@gmail.com>
 <CACRpkdbnGbVwqnY=aPU5Jic88v7VAsDWaB0yDU3iMo=YLCd9EQ@mail.gmail.com>
Message-ID: <20130425131129.GK4623@gmail.com>

On Thu, 25 Apr 2013, Linus Walleij wrote:

> On Thu, Apr 25, 2013 at 1:49 PM, Lee Jones <lee.jones at linaro.org> wrote:
> > On Thu, 25 Apr 2013, Linus Walleij wrote:
> >
> >> On Thu, Apr 18, 2013 at 12:12 PM, Lee Jones <lee.jones at linaro.org> wrote:
> >>
> >> > When requesting a channel, a DMA client needs to pass some pieces of
> >> > information such as; request channel, device type, channel type and
> >> > direction etc. Normally we do this in the form of platform data, but
> >> > when DT is enabled we need to pass it using the driver's bindings
> >> > instead.
> >> >
> >> > Signed-off-by: Lee Jones <lee.jones at linaro.org>
> >>
> >> This requires that the pending MMCI patch get merged *first* right?
> >
> > No, it doesn't. There is no harm in applying this *before*.
> >
> > It will just lay dormant until it is.
> 
> Ah yeah, right. But the patch stripping out the platform data (no 31) will
> wreak havoc if applied before the MMCI patch right?

Yes, that will cause problems. It will most likely go into PIO mode.

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From linus.walleij at linaro.org  Thu Apr 25 09:12:06 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Apr 2013 15:12:06 +0200
Subject: [PATCH 06/10 v2] usb: musb: ux500: add device tree probing support
In-Reply-To: <20130424074336.GD17416@gmail.com>
References: <1366729394-11406-1-git-send-email-lee.jones@linaro.org>
 <1366729394-11406-7-git-send-email-lee.jones@linaro.org>
 <20130424074336.GD17416@gmail.com>
Message-ID: <CACRpkdbVRFow2PkZB6YQ-xR4n=YEQHgpekPTN997WnJj0WZwsw@mail.gmail.com>

On Wed, Apr 24, 2013 at 9:43 AM, Lee Jones <lee.jones at linaro.org> wrote:

> usb: musb: ux500: add device tree probing support
>
> This patch will allow ux500-musb to be probed and configured solely from
> configuration found in Device Tree.
>
> Cc: Felipe Balbi <balbi at ti.com>
> Cc: linux-usb at vger.kernel.org
> Signed-off-by: Lee Jones <lee.jones at linaro.org>

This patch needs to be CC: devicetree-discuss.
But looks good to me!
Acked-by: Linus Walleij <linus.walleij at linaro.org>

Yours,
Linus Walleij


From linus.walleij at linaro.org  Thu Apr 25 09:13:02 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Apr 2013 15:13:02 +0200
Subject: [PATCH 07/10] ARM: ux500: Add an auxdata entry for MUSB for
 clock-name look-up
In-Reply-To: <1366729394-11406-8-git-send-email-lee.jones@linaro.org>
References: <1366729394-11406-1-git-send-email-lee.jones@linaro.org>
 <1366729394-11406-8-git-send-email-lee.jones@linaro.org>
Message-ID: <CACRpkdYK0W4wLGSK9akY7Ji4j8EUW=XwO8GCHpkXuLbP-aZW1w@mail.gmail.com>

On Tue, Apr 23, 2013 at 5:03 PM, Lee Jones <lee.jones at linaro.org> wrote:

> The recently DT:ed MUSB driver will require clock-name by device-name
> look-up capability, until common clk has is properly supported by the
> ux500 platform.
>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>

Acked-by: Linus Walleij <linus.walleij at linaro.org>

Yours,
Linus Walleij


From linus.walleij at linaro.org  Thu Apr 25 09:14:35 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Apr 2013 15:14:35 +0200
Subject: [PATCH 08/10 v2] ARM: ux500: Populate the ux500-musb Device Tree
 entry
In-Reply-To: <20130424074146.GC17416@gmail.com>
References: <1366729394-11406-1-git-send-email-lee.jones@linaro.org>
 <1366729394-11406-9-git-send-email-lee.jones@linaro.org>
 <20130424074146.GC17416@gmail.com>
Message-ID: <CACRpkdYUb+DfYs88ygbbc1HwO2Xb2JwLH+9Yxexo5=ArMc2W=A@mail.gmail.com>

On Wed, Apr 24, 2013 at 9:41 AM, Lee Jones <lee.jones at linaro.org> wrote:

> This patch provides all the information to successfully probe() and
> correctly configure the ux500-musb device driver for DMA.
>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>

Acked-by: Linus Walleij <linus.walleij at linaro.org>

Yours,
Linus Walleij


From linus.walleij at linaro.org  Thu Apr 25 09:15:19 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Apr 2013 15:15:19 +0200
Subject: [PATCH 09/10] ARM: ux500: Remove ux500-musb platform registation
 when booting with DT
In-Reply-To: <1366729394-11406-10-git-send-email-lee.jones@linaro.org>
References: <1366729394-11406-1-git-send-email-lee.jones@linaro.org>
 <1366729394-11406-10-git-send-email-lee.jones@linaro.org>
Message-ID: <CACRpkdbKDoTscjxhHw7hTG2xZn_AJa23o19dQcLB7vAdZ156WQ@mail.gmail.com>

On Tue, Apr 23, 2013 at 5:03 PM, Lee Jones <lee.jones at linaro.org> wrote:

> Now the ux500-musb driver has been enabled for Device Tree, there is no
> requirement to register it from platform code.
>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>

Acked-by: Linus Walleij <linus.walleij at linaro.org>

Yours,
Linus Walleij


From linus.walleij at linaro.org  Thu Apr 25 09:16:04 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Apr 2013 15:16:04 +0200
Subject: [PATCH 10/10] ARM: ux500: Remove empty function
 u8500_of_init_devices()
In-Reply-To: <1366729394-11406-11-git-send-email-lee.jones@linaro.org>
References: <1366729394-11406-1-git-send-email-lee.jones@linaro.org>
 <1366729394-11406-11-git-send-email-lee.jones@linaro.org>
Message-ID: <CACRpkdbHm8pdm+hTRHK8d32G4h9u=RBMgsLEmMeBBRGWPai5Ag@mail.gmail.com>

On Tue, Apr 23, 2013 at 5:03 PM, Lee Jones <lee.jones at linaro.org> wrote:

> As promised, now all devices which resided in u8500_of_init_devices()
> have been enabled for Device Tree, we can completely remove it.
>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>

Beautiful.
Acked-by: Linus Walleij <linus.walleij at linaro.org>

Yours,
Linus Walleij


From lee.jones at linaro.org  Thu Apr 25 09:20:25 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Thu, 25 Apr 2013 14:20:25 +0100
Subject: [PATCH 04/32] dmaengine: ste_dma40: Amalgamate DMA source and
 destination channel numbers
In-Reply-To: <CACRpkdbV8yEK0470q_-DWv6Q0hAG2wGntXFi5kaLUMgm9b=e-Q@mail.gmail.com>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-5-git-send-email-lee.jones@linaro.org>
 <CACRpkdaauDYTdoBHGG9FO4kKqvCYyCrjY8EGWs5gAQWErGW6_A@mail.gmail.com>
 <20130425090612.GC4623@gmail.com>
 <CACRpkdbV8yEK0470q_-DWv6Q0hAG2wGntXFi5kaLUMgm9b=e-Q@mail.gmail.com>
Message-ID: <20130425132025.GM4623@gmail.com>

On Thu, 25 Apr 2013, Linus Walleij wrote:

> On Thu, Apr 25, 2013 at 11:06 AM, Lee Jones <lee.jones at linaro.org> wrote:
> 
> >> Are we now sacrificing that ability on the altar of simplification?
> >>
> >> I actually think not, but that we should do periph-to-periph transfers
> >> in some other way, and that the .dir attribute should go away from
> >> the struct stedma40_chan_cfg as well but I'm not entirely sure.
> >> Someone else?
> >
> > Although the DMA40 device supports device-to-device transfers, Linux
> > does not, so this subject is moot AFAICT.
> 
> So while there is no active usecase, Linux surely has the ambition to do
> that as can be seen in:
> 
> /**
>  * enum dma_transfer_direction - dma transfer mode and direction indicator
>  * @DMA_MEM_TO_MEM: Async/Memcpy mode
>  * @DMA_MEM_TO_DEV: Slave mode & From Memory to Device
>  * @DMA_DEV_TO_MEM: Slave mode & From Device to Memory
>  * @DMA_DEV_TO_DEV: Slave mode & From Device to Device
>  */
> enum dma_transfer_direction {
>         DMA_MEM_TO_MEM,
>         DMA_MEM_TO_DEV,
>         DMA_DEV_TO_MEM,
>         DMA_DEV_TO_DEV,
>         DMA_TRANS_NONE,
> };
> 
> I think we need a handshake with Vinod on this.

Sure. He is CC'ed.

> >> If you're doing this change, and after this RX and TX has no semantical
> >> meaning for these lists, join these two config lists
> >> into one.
> >
> > I agree. See patch: ARM: ux500: Strip out duplicate USB DMA configuration
> 
> Please squash the applicable portions into this patch then, I don't
> particularly like fix-later patchstack patterns, it makes series hard to
> review.

Okay.

> >> (...)
> >> > diff --git a/arch/arm/mach-ux500/usb.c b/arch/arm/mach-ux500/usb.c
> >> >  static u32 d40_chan_has_events(struct d40_chan *d40c)
> >> > @@ -1744,8 +1740,6 @@ static int d40_validate_conf(struct d40_chan *d40c,
> >> >                              struct stedma40_chan_cfg *conf)
> >> >  {
> >> >         int res = 0;
> >> > -       u32 dst_event_group = D40_TYPE_TO_GROUP(conf->dst_dev_type);
> >> > -       u32 src_event_group = D40_TYPE_TO_GROUP(conf->src_dev_type);
> >>
> >> Please explain why this is not important to check anymore, I'm not
> >> following.
> >>
> >> >         if (conf->dir == STEDMA40_MEM_TO_PERIPH &&
> >> > -           dst_event_group == STEDMA40_DEV_DST_MEMORY) {
> >> > -               chan_err(d40c, "Invalid dst\n");
> >> > +           d40c->base->plat_data->dev_tx[conf->dev_type] == 0 &&
> >> > +           d40c->runtime_addr == 0) {
> >> > +               chan_err(d40c, "Invalid TX channel address (%d)\n",
> >> > +                        conf->dev_type);
> >>
> >> Like here. We are checking for inconsistency between group
> >> and channel direction, why is it no longer important to check this?
> >
> > I'm not entirely sure how this ever worked:
> >
> >   #define D40_TYPE_TO_GROUP(type) (type / 16)
> >   #define STEDMA40_DEV_DST_MEMORY (-1)
> >
> >   (dev_type / 16) == -1
> >
> > What number would dev_type have to be for this to be true? -16?
> 
> No, since it's u32 it cannot really represent negative numbers.
> 
> This is equivalent:
> #define D40_TYPE_TO_GROUP(type) (type >> 4)
> 
> As -1 is 0xffffffff in u32 it will compare at best
> 0x0fffffff to 0xfffffff. And that is non-attainable.
> 
> So the line checking event group for == DTEDMA40_DEV_DST_MEMORY
> should be  removed in a separate patch prior to this one, with
> something like the above as commit message.
> 
> We cannot really mix that cleanup into this patch...

I'm happy to do that.

> >> >         if (conf->dir == STEDMA40_PERIPH_TO_MEM &&
> >> > -           src_event_group == STEDMA40_DEV_SRC_MEMORY) {
> >> > -               chan_err(d40c, "Invalid src\n");
> >> > -               res = -EINVAL;
> >> > -       }
> >
> > As above.
> 
> And same comment.
> 
> >> > -       if (conf->dir == STEDMA40_PERIPH_TO_PERIPH &&
> >> > -           (src_event_group != dst_event_group)) {
> >> > -               chan_err(d40c, "Invalid event group\n");
> >> > +           d40c->base->plat_data->dev_rx[conf->dev_type] == 0 &&
> >> > +           d40c->runtime_addr == 0) {
> >> > +               chan_err(d40c, "Invalid RX channel address (%d)\n",
> >> > +                        conf->dev_type);
> >>
> >> Same here.
> >
> > I stopped all 'dev_src/dev_dest' comparisons, as there is only 'dev' now.
> 
> It is checking for:
> conf->dir == STEDMA40_PERIPH_TO_PERIPH
> 
> As we may want to support DEV_TO_DEV at some point.
> 
> Then no longer, and that is not related to $SUBJECT.

That's not why I'm removing it. The statement can never be true due to
the fact that the second evaluation (src_event_group != dst_event_group)
can never be true, which is a direct effect of 'THIS_PATCH'.

> >> (...)
> >> > @@ -2062,7 +2035,7 @@ static int d40_free_dma(struct d40_chan *d40c)
> >> >  {
> >> >
> >> >         int res = 0;
> >> > -       u32 event;
> >> > +       u32 event = D40_TYPE_TO_EVENT(d40c->dma_cfg.dev_type);
> >> >         struct d40_phy_res *phy = d40c->phy_chan;
> >> >         bool is_src;
> >> >
> >> > @@ -2081,13 +2054,11 @@ static int d40_free_dma(struct d40_chan *d40c)
> >> >         }
> >> >
> >> >         if (d40c->dma_cfg.dir == STEDMA40_MEM_TO_PERIPH ||
> >> > -           d40c->dma_cfg.dir == STEDMA40_MEM_TO_MEM) {
> >> > -               event = D40_TYPE_TO_EVENT(d40c->dma_cfg.dst_dev_type);
> >> > +           d40c->dma_cfg.dir == STEDMA40_MEM_TO_MEM)
> >>
> >> Why did you just stop checking dma_cfg.dir for == STEDMA40_MEM_TO_MEM
> >> above?
> >
> > That's not what this is doing. STEDMA40_MEM_TO_MEM is still there.
> >
> >> And why is dma_cfg.dir suddenly hardcoded to MEM_TO_MEM??
> >
> > It's not. Look again. :)
> 
> Argh I misread == MEM_TO_MEM for = MEM_TO_MEM ...
> comparison to assignment. Sorry.
> 
> >> This seems like a totally unrelated change and should it be done
> >> it need to be a separate patch with a separate explanation
> >> AFAICT.
> >>
> >> This seems to happen in some other places too,
> >
> > If you could point those out, I'll re-evaluate, or explain.
> 
> I'm after that the change to omit checks for some impossible
> type/group configs need to be a separate patch.
> 
> >> and I find it
> >> very hard to follow the changes here ... can you please consider
> >> splitting the changes to groups and types semantics into a separate
> >> patch?
> >
> > Can you read the patch again and reconsider please?
> 
> Yes and now I am even more convinced that the patch needs
> to be split.
> 
> Yours,
> Linus Walleij

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From lee.jones at linaro.org  Thu Apr 25 09:13:23 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Thu, 25 Apr 2013 14:13:23 +0100
Subject: [PATCH 09/32] ARM: ux500: Remove unused 'data_width' attributes
 from SDI DMA configs
In-Reply-To: <CACRpkdaeuK0p2SynenQjght9fCzTTJpt+S7hGC6d6ahPHAA7Hw@mail.gmail.com>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-10-git-send-email-lee.jones@linaro.org>
 <CACRpkdbf03ajQaYujGfimHE+hDVjNLycE3J9Q-W-tzN2EX0fkQ@mail.gmail.com>
 <20130425091428.GD4623@gmail.com>
 <CACRpkdaeuK0p2SynenQjght9fCzTTJpt+S7hGC6d6ahPHAA7Hw@mail.gmail.com>
Message-ID: <20130425131323.GL4623@gmail.com>

On Thu, 25 Apr 2013, Linus Walleij wrote:

> On Thu, Apr 25, 2013 at 11:14 AM, Lee Jones <lee.jones at linaro.org> wrote:
> > On Thu, 25 Apr 2013, Linus Walleij wrote:
> >
> >> On Thu, Apr 18, 2013 at 12:11 PM, Lee Jones <lee.jones at linaro.org> wrote:
> >>
> >> > DMA configuration data is now allocated in the MMCI driver, so these
> >> > are just ignored.
> >> >
> >> > Signed-off-by: Lee Jones <lee.jones at linaro.org>
> >>
> >> Reviewed-by: Linus Walleij <linus.walleij at linaro.org>
> >>
> >> I tried just applying this (since it's pretty stand-alone) but seems to
> >> be dependent on things not yet in Torvalds tree so lets keep it in this
> >> series then...
> >
> > Ideally I'd like to keep them all in the same branch, as it may lead
> > to confusion/conflicts later down the line (I'm still coding a lot of
> > this stuff).
> >
> > Naturally, I'll go with whatever you think is best, but this is my
> > preference.
> 
> This works find for now, I just want the DT changes kept separately
> because I'm in hell with these right now and don't want to end up
> there again next merge cycle.

Sure. Just let me know what you plan to manually apply and I'll do my
utmost to keep things sane in the patch-set.

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From linus.walleij at linaro.org  Thu Apr 25 09:21:06 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Apr 2013 15:21:06 +0200
Subject: [PATCH 04/32] dmaengine: ste_dma40: Amalgamate DMA source and
 destination channel numbers
In-Reply-To: <20130425130922.GE14496@n2100.arm.linux.org.uk>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-5-git-send-email-lee.jones@linaro.org>
 <CACRpkdaauDYTdoBHGG9FO4kKqvCYyCrjY8EGWs5gAQWErGW6_A@mail.gmail.com>
 <20130425090612.GC4623@gmail.com>
 <CACRpkdbV8yEK0470q_-DWv6Q0hAG2wGntXFi5kaLUMgm9b=e-Q@mail.gmail.com>
 <20130425130922.GE14496@n2100.arm.linux.org.uk>
Message-ID: <CACRpkdZj-3DbcX1LREGKf2RZs4FqbDn6sWkaZ-t67KUKJhZaow@mail.gmail.com>

On Thu, Apr 25, 2013 at 3:09 PM, Russell King - ARM Linux
<linux at arm.linux.org.uk> wrote:

> There's a problem with device to device transfers though - you have to
> consider the rate at which the devices produce and consume data, and
> whether they both can cope with differing data rates.
>
> Take for instance your audio in to audio out idea - even if they are
> both operating at the same bits per sample and sample rate, if they are
> independently clocked, chances are that the clocks are not exactly the
> same, which means you will either underrun or overrun one of the FIFOs
> in the system.

This magically works for us, but yes, I think they had to use the same
clock (simplest solution, anyway).

It is/was a very real usecase, IIRC coming from roundtrip constraints
in the GSM 3GPP spec, wanting to keep the latency as low as possible.
With this scheme there is no more than a FIFO on each end of delay,
which is nice.

Yours,
Linus Walleij


From linus.walleij at linaro.org  Thu Apr 25 09:24:21 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Apr 2013 15:24:21 +0200
Subject: [PATCH 04/32] dmaengine: ste_dma40: Amalgamate DMA source and
 destination channel numbers
In-Reply-To: <20130425132025.GM4623@gmail.com>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-5-git-send-email-lee.jones@linaro.org>
 <CACRpkdaauDYTdoBHGG9FO4kKqvCYyCrjY8EGWs5gAQWErGW6_A@mail.gmail.com>
 <20130425090612.GC4623@gmail.com>
 <CACRpkdbV8yEK0470q_-DWv6Q0hAG2wGntXFi5kaLUMgm9b=e-Q@mail.gmail.com>
 <20130425132025.GM4623@gmail.com>
Message-ID: <CACRpkdbpbQTCxeQ6cCbAkvvQXJMQUhLv8=qcbBgvBVnMDdysOA@mail.gmail.com>

On Thu, Apr 25, 2013 at 3:20 PM, Lee Jones <lee.jones at linaro.org> wrote:
> On Thu, 25 Apr 2013, Linus Walleij wrote:

>> As we may want to support DEV_TO_DEV at some point.
>>
>> Then no longer, and that is not related to $SUBJECT.
>
> That's not why I'm removing it. The statement can never be true due to
> the fact that the second evaluation (src_event_group != dst_event_group)
> can never be true, which is a direct effect of 'THIS_PATCH'.

OK that is correct, I'm fine with this then ... as part of that other
patch dealing with unreacable conditions I keep talking about...

Yours,
Linus Walleij


From linus.walleij at linaro.org  Thu Apr 25 09:26:05 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Apr 2013 15:26:05 +0200
Subject: [PATCH 2/2] pinctrl: samsung: Fix link error with
 CONFIG_PINCTRL_EXYNOS disabled
In-Reply-To: <2113989.KXXvDDhnMa@amdc1227>
References: <1366060483-20342-1-git-send-email-tomasz.figa@gmail.com>
 <6940961.67Lk2axxPL@amdc1227>
 <CACRpkdZmSj-AqUA9kd7NMN6cL2Nxa0EaKoSVkwQSrxhcWEeQtg@mail.gmail.com>
 <2113989.KXXvDDhnMa@amdc1227>
Message-ID: <CACRpkdY61h-H14QYHhADnAz1JRa=8Wbi0aYKSRW21xm4WHOHGA@mail.gmail.com>

On Wed, Apr 24, 2013 at 4:47 PM, Tomasz Figa <t.figa at samsung.com> wrote:
> On Wednesday 24 of April 2013 16:27:09 Linus Walleij wrote:
>> On Tue, Apr 23, 2013 at 2:09 PM, Tomasz Figa <t.figa at samsung.com> wrote:
>> > On Tuesday 23 of April 2013 14:03:12 Linus Walleij wrote:
>> >> This does not apply to my "devel" branch in the pinctrl tree.
>> >>
>> >> Could you rebase it on that branch?
>> >>
>> >> Or is the error not even in my tree?
>> >
>> > This one got sent incorrectly due to my mistake. Please try the correct
>> > version:
>> >
>> > [PATCH RESEND 2/2] pinctrl: samsung: Fix link error with
>> > CONFIG_PINCTRL_EXYNOS disabled
>>
>> This does not apply either.
>>
>> Can you please test against the "devel" branch in the pinctrl tree?
>
> Right, it does not apply.
>
> Well, actually it does with git am -3, but it is incorrect, since the problem
> it intends to fix is not present in your tree, but rather is a merge error in
> linux-next in a merge of Kgene's and your tree...

Oh. Then you have to send the patch to Stephen Rothwell.

Yours,
Linus Walleij


From catalin.marinas at arm.com  Thu Apr 25 09:33:15 2013
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Thu, 25 Apr 2013 14:33:15 +0100
Subject: [PATCH] of: Set the DMA mask to 64 bits on ARM LPAE systems
In-Reply-To: <1366764649-10342-1-git-send-email-lauraa@codeaurora.org>
References: <1366764649-10342-1-git-send-email-lauraa@codeaurora.org>
Message-ID: <20130425133315.GA7157@localhost.cambridge.arm.com>

On Wed, Apr 24, 2013 at 01:50:49AM +0100, Laura Abbott wrote:
> By default on ARM systems, the coherent DMA mask (lowest
> address) is set to ~0 or 0xFFFFFFFFFFFFFFFF. Currently,
> of_platform_device_create_pdata sets the coherent DMA mask to
> 32 bits. This prevents coherent dma allocations from working by default
> without clients setting the DMA mask. Rather than make every client
> on an LPAE system set the mask, set the mask to a 64 bit value on
> ARM LPAE systems.
> 
> Signed-off-by: Laura Abbott <lauraa at codeaurora.org>
> ---
>  drivers/of/platform.c |    4 ++++
>  1 files changed, 4 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/of/platform.c b/drivers/of/platform.c
> index 0970505..18b69c1 100644
> --- a/drivers/of/platform.c
> +++ b/drivers/of/platform.c
> @@ -214,7 +214,11 @@ struct platform_device *of_platform_device_create_pdata(
>  #if defined(CONFIG_MICROBLAZE)
>  	dev->archdata.dma_mask = 0xffffffffUL;
>  #endif
> +#ifdef CONFIG_ARM_LPAE
> +	dev->dev.coherent_dma_mask = DMA_BIT_MASK(64);
> +#else
>  	dev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
> +#endif

I wouldn't add CONFIG_ARM_LPAE checks in here, you can use
CONFIG_ARCH_DMA_ADDR_T_64BIT (types.h uses this for the dma_addr_t
definition).

-- 
Catalin


From mkl at pengutronix.de  Thu Apr 25 09:36:50 2013
From: mkl at pengutronix.de (Marc Kleine-Budde)
Date: Thu, 25 Apr 2013 15:36:50 +0200
Subject: RFC: [PATCH] clocksource: tcb: fix min_delta calculation
In-Reply-To: <1366722524-25991-1-git-send-email-mkl@pengutronix.de>
References: <517687AB.1040309@pengutronix.de>
 <1366722524-25991-1-git-send-email-mkl@pengutronix.de>
Message-ID: <51793172.9030802@pengutronix.de>

On 04/23/2013 03:08 PM, Marc Kleine-Budde wrote:
> The commit
> 
>     77cc982 clocksource: use clockevents_config_and_register() where possible
> 
> switches from manually calculating min_delta_ns (and others) and
> clockevents_register_device() to automatic calculation via
> clockevents_config_and_register(). During this conversation the "+ 1" in
> 
>     min_delta_ns = clockevent_delta2ns(1, &clkevt.clkevt) + 1;
> 
> was lost. This leads to problems with schedule_delayed_work() with a delay of
> "1". Resulting in the work not scheduled in time.
> 
> This patch fixes the problem by increasing the min_delta to "2" ticks.
> 
> Signed-off-by: Marc Kleine-Budde <mkl at pengutronix.de>

Who will take care of this patch?

Marc

> ---
>  drivers/clocksource/tcb_clksrc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/clocksource/tcb_clksrc.c b/drivers/clocksource/tcb_clksrc.c
> index 8a61872..7cf6dc7 100644
> --- a/drivers/clocksource/tcb_clksrc.c
> +++ b/drivers/clocksource/tcb_clksrc.c
> @@ -197,7 +197,7 @@ static void __init setup_clkevents(struct atmel_tc *tc, int clk32k_divisor_idx)
>  
>  	clkevt.clkevt.cpumask = cpumask_of(0);
>  
> -	clockevents_config_and_register(&clkevt.clkevt, 32768, 1, 0xffff);
> +	clockevents_config_and_register(&clkevt.clkevt, 32768, 2, 0xffff);
>  
>  	setup_irq(irq, &tc_irqaction);
>  }
> 


-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130425/6c6ec9f4/attachment.sig>

From Ian.Campbell at citrix.com  Thu Apr 25 09:40:21 2013
From: Ian.Campbell at citrix.com (Ian Campbell)
Date: Thu, 25 Apr 2013 14:40:21 +0100
Subject: [PATCH v4 2/7] xen/arm: SMP support
In-Reply-To: <1366831695-13214-2-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1304242012590.4180@kaball.uk.xensource.com>
 <1366831695-13214-2-git-send-email-stefano.stabellini@eu.citrix.com>
Message-ID: <1366897221.20256.544.camel@zakaz.uk.xensource.com>

On Wed, 2013-04-24 at 20:28 +0100, Stefano Stabellini wrote:
> Map vcpu_info using VCPUOP_register_vcpu_info on secondary cpus.
> 
> Call enable_percpu_irq on every cpu.
> 
> Changed in v2:
> - move the percpu variable argument fix to a separate patch;
> - remove unused variable.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
> ---
>  arch/arm/xen/enlighten.c |   38 +++++++++++++++++++++++++++++++++++++-
>  1 files changed, 37 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> index 99ce189..94bbf3b 100644
> --- a/arch/arm/xen/enlighten.c
> +++ b/arch/arm/xen/enlighten.c
> @@ -2,6 +2,7 @@
>  #include <xen/events.h>
>  #include <xen/grant_table.h>
>  #include <xen/hvm.h>
> +#include <xen/interface/vcpu.h>
>  #include <xen/interface/xen.h>
>  #include <xen/interface/memory.h>
>  #include <xen/interface/hvm/params.h>
> @@ -32,6 +33,7 @@ struct shared_info xen_dummy_shared_info;
>  struct shared_info *HYPERVISOR_shared_info = (void *)&xen_dummy_shared_info;
>  
>  DEFINE_PER_CPU(struct vcpu_info *, xen_vcpu);
> +DEFINE_PER_CPU(struct vcpu_info, xen_vcpu_info);

>  /* These are unused until we support booting "pre-ballooned" */
>  unsigned long xen_released_pages;
> @@ -148,6 +150,32 @@ int xen_unmap_domain_mfn_range(struct vm_area_struct *vma,
>  }
>  EXPORT_SYMBOL_GPL(xen_unmap_domain_mfn_range);
>  
> +static int __init xen_secondary_init(unsigned int cpu)
> +{
> +	struct vcpu_register_vcpu_info info;
> +	struct vcpu_info *vcpup;
> +	int err;
> +
> +	if (cpu == 0)
> +		return 0;
> +
> +	pr_info("Xen: initializing cpu%d\n", cpu);
> +	vcpup = &per_cpu(xen_vcpu_info, cpu);
> +
> +	info.mfn = __pa(vcpup) >> PAGE_SHIFT;
> +	info.offset = offset_in_page(vcpup);

Do you need to somehow guarantee it's not going to cross a page? Maybe
standard C alignment rules make that the case?

> @@ -216,6 +245,8 @@ static int __init xen_guest_init(void)
>  	 * is required to use VCPUOP_register_vcpu_info to place vcpu info
>  	 * for secondary CPUs as they are brought up. */
>  	per_cpu(xen_vcpu, 0) = &HYPERVISOR_shared_info->vcpu_info[0];
> +	for_each_online_cpu(i)
> +		xen_secondary_init(i);
>  
>  	gnttab_init();
>  	if (!xen_initial_domain())
[...]
> @@ -244,7 +280,7 @@ static int __init xen_init_events(void)
>  		return -EINVAL;
>  	}
>  
> -	enable_percpu_irq(xen_events_irq, 0);
> +	on_each_cpu(xen_percpu_enable_events, NULL, 0);

It feels like there ought to be some sort of per-cpu bringup callback
which takes care of these dynamically. Maybe that doesn't matter until
we get vcpu hotplug going?

>  
>  	return 0;
>  }




From linus.walleij at linaro.org  Thu Apr 25 09:40:39 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Apr 2013 15:40:39 +0200
Subject: [PATCH 13/23] regulator: ab3100: refactor probe to use IDs
In-Reply-To: <20130422123749.GJ30351@opensource.wolfsonmicro.com>
References: <1366624634-6579-1-git-send-email-linus.walleij@stericsson.com>
 <20130422123749.GJ30351@opensource.wolfsonmicro.com>
Message-ID: <CACRpkdZkP57POYViehqvfWpn-TrrcYRzgLetdteFzANmw8exBg@mail.gmail.com>

On Mon, Apr 22, 2013 at 2:37 PM, Mark Brown
<broonie at opensource.wolfsonmicro.com> wrote:
> On Mon, Apr 22, 2013 at 11:57:14AM +0200, Linus Walleij wrote:
>
>> Hi Mark, seeking an ACK on this to take it through the
>> ARM SoC tree.
>
> Since the arm-soc tree is locked down now I may as well just apply it so
> it shows up in the merge window?

Yep, saw you picked in these two, thanks!

Linus Walleij


From Ian.Campbell at citrix.com  Thu Apr 25 09:41:18 2013
From: Ian.Campbell at citrix.com (Ian Campbell)
Date: Thu, 25 Apr 2013 14:41:18 +0100
Subject: [PATCH v4 4/7] xen/arm: implement HYPERVISOR_vcpu_op
In-Reply-To: <1366831695-13214-4-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1304242012590.4180@kaball.uk.xensource.com>
 <1366831695-13214-4-git-send-email-stefano.stabellini@eu.citrix.com>
Message-ID: <1366897278.20256.545.camel@zakaz.uk.xensource.com>

On Wed, 2013-04-24 at 20:28 +0100, Stefano Stabellini wrote:
> Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>

Reviewed-by: Ian Campbell <ian.campbell at citrix.com>

> ---
>  arch/arm/include/asm/xen/hypercall.h |    1 +
>  arch/arm/xen/enlighten.c             |    1 +
>  arch/arm/xen/hypercall.S             |    1 +
>  3 files changed, 3 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/include/asm/xen/hypercall.h b/arch/arm/include/asm/xen/hypercall.h
> index 8a82325..799f42e 100644
> --- a/arch/arm/include/asm/xen/hypercall.h
> +++ b/arch/arm/include/asm/xen/hypercall.h
> @@ -46,6 +46,7 @@ int HYPERVISOR_event_channel_op(int cmd, void *arg);
>  unsigned long HYPERVISOR_hvm_op(int op, void *arg);
>  int HYPERVISOR_memory_op(unsigned int cmd, void *arg);
>  int HYPERVISOR_physdev_op(int cmd, void *arg);
> +int HYPERVISOR_vcpu_op(int cmd, int vcpuid, void *extra_args);
>  
>  static inline void
>  MULTI_update_va_mapping(struct multicall_entry *mcl, unsigned long va,
> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> index 94bbf3b..b002822 100644
> --- a/arch/arm/xen/enlighten.c
> +++ b/arch/arm/xen/enlighten.c
> @@ -295,4 +295,5 @@ EXPORT_SYMBOL_GPL(HYPERVISOR_sched_op);
>  EXPORT_SYMBOL_GPL(HYPERVISOR_hvm_op);
>  EXPORT_SYMBOL_GPL(HYPERVISOR_memory_op);
>  EXPORT_SYMBOL_GPL(HYPERVISOR_physdev_op);
> +EXPORT_SYMBOL_GPL(HYPERVISOR_vcpu_op);
>  EXPORT_SYMBOL_GPL(privcmd_call);
> diff --git a/arch/arm/xen/hypercall.S b/arch/arm/xen/hypercall.S
> index 71f7239..199cb2d 100644
> --- a/arch/arm/xen/hypercall.S
> +++ b/arch/arm/xen/hypercall.S
> @@ -87,6 +87,7 @@ HYPERCALL2(event_channel_op);
>  HYPERCALL2(hvm_op);
>  HYPERCALL2(memory_op);
>  HYPERCALL2(physdev_op);
> +HYPERCALL3(vcpu_op);
>  
>  ENTRY(privcmd_call)
>  	stmdb sp!, {r4}




From lee.jones at linaro.org  Thu Apr 25 09:44:02 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Thu, 25 Apr 2013 14:44:02 +0100
Subject: [PATCH 6/9] crypto: ux500/cryp - Set DMA configuration though
 dma_slave_config()
In-Reply-To: <CACRpkdbFgW6bGYt59WtN4r2izuN09AJw4J1cqir82uzFsuMmWQ@mail.gmail.com>
References: <1366280825-31136-1-git-send-email-lee.jones@linaro.org>
 <1366280825-31136-7-git-send-email-lee.jones@linaro.org>
 <CACRpkdbFgW6bGYt59WtN4r2izuN09AJw4J1cqir82uzFsuMmWQ@mail.gmail.com>
Message-ID: <20130425134402.GN4623@gmail.com>

On Thu, 25 Apr 2013, Linus Walleij wrote:

> On Thu, Apr 18, 2013 at 12:27 PM, Lee Jones <lee.jones at linaro.org> wrote:
> 
> > The DMA controller currently takes configuration information from
> > information passed though dma_channel_request(), but it shouldn't.
> > Using the API, the DMA channel should only be configured during
> > a dma_slave_config() call.
> >
> > Cc: Herbert Xu <herbert at gondor.apana.org.au>
> > Cc: David S. Miller <davem at davemloft.net>
> > Cc: Andreas Westin <andreas.westin at stericsson.com>
> > Cc: linux-crypto at vger.kernel.org
> > Signed-off-by: Lee Jones <lee.jones at linaro.org>
> 
> (...)
> >  /* Cryp DMA interface */
> > +#define HASH_DMA_TX_FIFO       0x08
> > +#define HASH_DMA_RX_FIFO       0x10
> 
> Yes, this is nice address notation :-)
> 
> >  /**
> >   * struct cryp_device_data - structure for a cryp device.
> > - * @base: Pointer to the hardware base address.
> > + * @base: Pointer to virtual base address of the cryp device.
> > + * @phybase: Pointer to physical memory location of the cryp device.
> >   * @dev: Pointer to the devices dev structure.
> >   * @clk: Pointer to the device's clock control.
> >   * @pwr_regulator: Pointer to the device's power control.
> > @@ -232,6 +236,7 @@ struct cryp_dma {
> >   */
> >  struct cryp_device_data {
> >         struct cryp_register __iomem *base;
> > +       phys_addr_t phybase;
> 
> Use dma_addr_t. Maybe "phybase" is misleading,
> "dmabase" is probably better. (Also applies to the
> cryp patch).

Accept it's not the dmabase.

It's the phybase (U8500_CRYP1_BASE) i.e. the physical base address of
the device's regs.

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From lee.jones at linaro.org  Thu Apr 25 09:44:43 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Thu, 25 Apr 2013 14:44:43 +0100
Subject: [PATCH 5/9] crypto: ux500/cryp - Fix compile error
In-Reply-To: <CACRpkdZNFqbHJB7R5zqVzkAn_nV=G+c27YRB7VCQxiMyFTnPbg@mail.gmail.com>
References: <1366280825-31136-1-git-send-email-lee.jones@linaro.org>
 <1366280825-31136-6-git-send-email-lee.jones@linaro.org>
 <CACRpkdZNFqbHJB7R5zqVzkAn_nV=G+c27YRB7VCQxiMyFTnPbg@mail.gmail.com>
Message-ID: <20130425134443.GO4623@gmail.com>

On Thu, 25 Apr 2013, Linus Walleij wrote:

> On Thu, Apr 18, 2013 at 12:27 PM, Lee Jones <lee.jones at linaro.org> wrote:
> 
> > Clearly this driver hasn't been tested, or even enabled in a while.
> >
> > drivers/crypto/ux500/cryp/cryp_core.c:1771:3:
> >         error: request for member ?pm? in something not a structure or union
> >
> > Cc: Herbert Xu <herbert at gondor.apana.org.au>
> > Cc: David S. Miller <davem at davemloft.net>
> > Cc: Andreas Westin <andreas.westin at stericsson.com>
> > Cc: linux-crypto at vger.kernel.org
> > Signed-off-by: Lee Jones <lee.jones at linaro.org>
> 
> NAK. I already fixed this. It is in v3.9-rc7.

Yes, I saw it when I rebased. I've dropped the patch.

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From lee.jones at linaro.org  Thu Apr 25 09:46:36 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Thu, 25 Apr 2013 14:46:36 +0100
Subject: [PATCH 1/9 v2] crypto: ux500/hash - Prepare clock before
 enabling it
In-Reply-To: <CACRpkdYrCA6SduwMJF=7C9hyjP2Or7gxhjVFtLshdzkbYnxX1w@mail.gmail.com>
References: <1366280825-31136-1-git-send-email-lee.jones@linaro.org>
 <1366280825-31136-2-git-send-email-lee.jones@linaro.org>
 <20130419122428.GC3432@gmail.com>
 <CACRpkdYrCA6SduwMJF=7C9hyjP2Or7gxhjVFtLshdzkbYnxX1w@mail.gmail.com>
Message-ID: <20130425134636.GP4623@gmail.com>

On Thu, 25 Apr 2013, Linus Walleij wrote:

> On Fri, Apr 19, 2013 at 2:24 PM, Lee Jones <lee.jones at linaro.org> wrote:
> > Slight change of plan for v2.
> >
> > Now we're doing a seperate clk_prepare(), as the clk_enable() in the
> > previous patch turned out to be called inside a spin_lock().
> >
> > Arnd, can you confirm your Ack please?
> 
> Do you really want letters to Arnd to be part of the commit log?
> 
> >
> > ---
> 
> Note: stuff following the three dashes (---) will be *omitted*
> from the change log. This seems to be turned upside-down.

Ah, I didn't know that, thanks.

This patch wasn't due for 'plucking', just reviewing.

> > crypto: ux500/hash - Prepare clock before enabling it
> >
> > If we fail to prepare the ux500-hash clock before enabling it the
> > platform will fail to boot. Here we insure this happens.
> >
> > Cc: Herbert Xu <herbert at gondor.apana.org.au>
> > Cc: David S. Miller <davem at davemloft.net>
> > Cc: Andreas Westin <andreas.westin at stericsson.com>
> > Cc: linux-crypto at vger.kernel.org
> > Acked-by: Arnd Bergmann <arnd at arndb.de>
> > Signed-off-by: Lee Jones <lee.jones at linaro.org>
> 
> Pls include Ulf Hansson <ulf.hansson at linaro.org> on this patch.

Sure.

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From Ian.Campbell at citrix.com  Thu Apr 25 09:48:38 2013
From: Ian.Campbell at citrix.com (Ian Campbell)
Date: Thu, 25 Apr 2013 14:48:38 +0100
Subject: [PATCH v4 1/7] xen/arm: actually pass a non-NULL percpu pointer
 to request_percpu_irq
In-Reply-To: <1366831695-13214-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1304242012590.4180@kaball.uk.xensource.com>
 <1366831695-13214-1-git-send-email-stefano.stabellini@eu.citrix.com>
Message-ID: <1366897718.20256.546.camel@zakaz.uk.xensource.com>

On Wed, 2013-04-24 at 20:28 +0100, Stefano Stabellini wrote:
> Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>

Reviewed-by: Ian Campbell <ian.camjpbell at citrix.com>

> CC: stable at vger.kernel.org
> ---
>  arch/arm/xen/enlighten.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> index 8dc0605..99ce189 100644
> --- a/arch/arm/xen/enlighten.c
> +++ b/arch/arm/xen/enlighten.c
> @@ -239,7 +239,7 @@ static int __init xen_init_events(void)
>  	xen_init_IRQ();
>  
>  	if (request_percpu_irq(xen_events_irq, xen_arm_callback,
> -			"events", xen_vcpu)) {
> +			"events", &xen_vcpu)) {
>  		pr_err("Error requesting IRQ %d\n", xen_events_irq);
>  		return -EINVAL;
>  	}




From tixy at linaro.org  Thu Apr 25 09:50:18 2013
From: tixy at linaro.org (Jon Medhurst (Tixy))
Date: Thu, 25 Apr 2013 14:50:18 +0100
Subject: [PATCH] ARM: make cpu_init() notrace
In-Reply-To: <20130425121504.GD14496@n2100.arm.linux.org.uk>
References: <1366302046.3388.8.camel@linaro1.home>
 <20130422140711.GI14496@n2100.arm.linux.org.uk>
 <1366654116.3989.16.camel@computer5.home>
 <20130425121504.GD14496@n2100.arm.linux.org.uk>
Message-ID: <1366897818.3528.38.camel@computer5.home>

On Thu, 2013-04-25 at 13:15 +0100, Russell King - ARM Linux wrote:

> $ pdb getpatch 7700/1 |tr ' ' '_' |less
> diff_--git_a/arch/arm/kernel/setup.c_b/arch/arm/kernel/setup.c
> index_d343a6c..943cbf0_100644
> ---_a/arch/arm/kernel/setup.c
> +++_b/arch/arm/kernel/setup.c
> @@_-390,7_+390,7_@@_static_void___init_feat_v6_fixup(void)
> __*
> __*_cpu_init_sets_up_the_per-CPU_stacks.
> __*/
> -void_cpu_init(void)
> +void_notrace_cpu_init(void)
> _{
> ________unsigned_int_cpu_=_smp_processor_id();
> ________struct_stack_*stk_=_&stacks[cpu];
> 
> Can you guess why git has a problem appying the above... 

Sorry about that, the user forgot to tell their mailer it was
pre-formatted text. I've sent a fixed version.

Note to self: bcc self on patch submissions and then run them though
'git am' to catch problems before others hit them.

-- 
Tixy



From catalin.marinas at arm.com  Thu Apr 25 09:51:06 2013
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Thu, 25 Apr 2013 14:51:06 +0100
Subject: [PATCH] ARM64: mm: Correct show_pte behaviour.
In-Reply-To: <1366382971-12682-1-git-send-email-steve.capper@linaro.org>
References: <1366382971-12682-1-git-send-email-steve.capper@linaro.org>
Message-ID: <20130425135106.GB7157@localhost.cambridge.arm.com>

On Fri, Apr 19, 2013 at 03:49:31PM +0100, Steve Capper wrote:
> show_pte makes use of the *_none_or_clear_bad style functions. If a
> pgd, pud or pmd is identified as being bad, it will then be cleared.
> 
> As show_pte appears to be called from either the user or kernel
> fault handlers this side effect can lead to unpredictable behaviour;
> especially as TLB entries are not invalidated.
> 
> This patch removes the page table sanitisation from show_pte. If a
> bad pgd, pud or pmd is encountered it is left unmodified.
> 
> Signed-off-by: Steve Capper <steve.capper at linaro.org>

Thanks. Applied.

-- 
Catalin


From khilman at linaro.org  Thu Apr 25 09:58:19 2013
From: khilman at linaro.org (Kevin Hilman)
Date: Thu, 25 Apr 2013 06:58:19 -0700
Subject: Multiple issues with omap4 panda es in linux next
In-Reply-To: <20130419181825.GN10155@atomide.com> (Tony Lindgren's message of
 "Fri, 19 Apr 2013 11:18:26 -0700")
References: <20130419171318.GK10155@atomide.com> <517181B2.9070302@ti.com>
 <20130419174454.GM10155@atomide.com> <517184A2.9020908@ti.com>
 <20130419181825.GN10155@atomide.com>
Message-ID: <87obd21zlw.fsf@linaro.org>

Tony Lindgren <tony at atomide.com> writes:

> * Santosh Shilimkar <santosh.shilimkar at ti.com> [130419 10:56]:
>> On Friday 19 April 2013 11:14 PM, Tony Lindgren wrote:
>> > * Santosh Shilimkar <santosh.shilimkar at ti.com> [130419 10:43]:
>> >> On Friday 19 April 2013 10:43 PM, Tony Lindgren wrote:
>> >>> Hi all,
>> >>>
>> >>> Here's a list of breakage I've noticed so far while trying to
>> >>> use linux next on my pandaboard es. Probably similar issues exist
>> >>> on other boards as well.
>> >>>
>> >>> Ideally we would not have any breakage by the merge window, so
>> >>> let's try to get these fixed ASAP:
>> >>>
>> >>> 1. Serial console broken on panda es booting with DT
>> >>>
>> >>> The symptoms are dmesg output stopping after few lines
>> >>> and only continuing after pressing a key. Does not seem to
>> >>> happen on blaze with DT for some reason. And does not happen
>> >>> on panda es with legacy booting.
>> >>>
>> >> This one is known and reported on list along with fix patches and
>> >> later pull request [1].
>> >>
>> >> Unfortunately with all the testing and everything and patches have
>> >> been on the list for quite some time, feedback on one of the patch
>> >> received was after pull request and then there was no further
>> >> clarification. That series address the same exact issue you have
>> >> mentioned above.
>> > 
>> > OK thanks. I think Paul picked some of those and the plan was
>> > to update the branch? Which one(s) should go into v3.10 as fixes?
>> > 
>> Main in that series was to handle driver sysc handling withing hwmod
>> layer and that is where the series got stuck [2]. Without that support
>> other patches won't fix the issue.
>
> OK it seems that that is still ongoing discussion. For v3.10 we should
> probably just disable PM for omap4 for DT booting so people can use
> it for DT related development.

Disabling PM (and even avoiding WFI using 'nohlt') will not fix this
problem, since it's related to the idle-mode of the IP block itself.

What fixes the problem is the series from Santosh for the SYSC removal.

Santosh, it seems that series combined a fix for this problem with some
cleanup of the hwmod code that Paul had some concerns with.  Is there
any chance you can split up that series into a fix targetted at the
DT-boot UART problem and a feature cleanup for hwmod?

Then we hopefully get this fix into v3.10-rc and work on the hwmod
changes/cleanup for the following merge window.

Kevin



From linus.walleij at linaro.org  Thu Apr 25 10:05:57 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Apr 2013 16:05:57 +0200
Subject: [PATCH 6/9] crypto: ux500/cryp - Set DMA configuration though
 dma_slave_config()
In-Reply-To: <20130425134402.GN4623@gmail.com>
References: <1366280825-31136-1-git-send-email-lee.jones@linaro.org>
 <1366280825-31136-7-git-send-email-lee.jones@linaro.org>
 <CACRpkdbFgW6bGYt59WtN4r2izuN09AJw4J1cqir82uzFsuMmWQ@mail.gmail.com>
 <20130425134402.GN4623@gmail.com>
Message-ID: <CACRpkdaugQO5aMBnfvD8fmYkKbiWsHwvqg3=eARovqFe9MDExw@mail.gmail.com>

On Thu, Apr 25, 2013 at 3:44 PM, Lee Jones <lee.jones at linaro.org> wrote:
> On Thu, 25 Apr 2013, Linus Walleij wrote:
>> On Thu, Apr 18, 2013 at 12:27 PM, Lee Jones <lee.jones at linaro.org> wrote:
>>
>> > The DMA controller currently takes configuration information from
>> > information passed though dma_channel_request(), but it shouldn't.
>> > Using the API, the DMA channel should only be configured during
>> > a dma_slave_config() call.
>> >
>> > Cc: Herbert Xu <herbert at gondor.apana.org.au>
>> > Cc: David S. Miller <davem at davemloft.net>
>> > Cc: Andreas Westin <andreas.westin at stericsson.com>
>> > Cc: linux-crypto at vger.kernel.org
>> > Signed-off-by: Lee Jones <lee.jones at linaro.org>
>>
>> (...)
>> >  /* Cryp DMA interface */
>> > +#define HASH_DMA_TX_FIFO       0x08
>> > +#define HASH_DMA_RX_FIFO       0x10
>>
>> Yes, this is nice address notation :-)
>>
>> >  /**
>> >   * struct cryp_device_data - structure for a cryp device.
>> > - * @base: Pointer to the hardware base address.
>> > + * @base: Pointer to virtual base address of the cryp device.
>> > + * @phybase: Pointer to physical memory location of the cryp device.
>> >   * @dev: Pointer to the devices dev structure.
>> >   * @clk: Pointer to the device's clock control.
>> >   * @pwr_regulator: Pointer to the device's power control.
>> > @@ -232,6 +236,7 @@ struct cryp_dma {
>> >   */
>> >  struct cryp_device_data {
>> >         struct cryp_register __iomem *base;
>> > +       phys_addr_t phybase;
>>
>> Use dma_addr_t. Maybe "phybase" is misleading,
>> "dmabase" is probably better. (Also applies to the
>> cryp patch).
>
> Accept it's not the dmabase.
>
> It's the phybase (U8500_CRYP1_BASE) i.e. the physical base address of
> the device's regs.

So when you assign the src_addr or dst_addr in struct
dmaengine_slave_config in this code,
you notice that this looks like so:

struct dma_slave_config {
        enum dma_transfer_direction direction;
        dma_addr_t src_addr;
        dma_addr_t dst_addr;
        enum dma_slave_buswidth src_addr_width;
        enum dma_slave_buswidth dst_addr_width;
        u32 src_maxburst;
        u32 dst_maxburst;
        bool device_fc;
};

So when you do this:

+       struct dma_slave_config mem2cryp = {
+               .direction = DMA_MEM_TO_DEV,
+               .dst_addr = device_data->phybase + HASH_DMA_TX_FIFO,
+               .dst_addr_width = DMA_SLAVE_BUSWIDTH_2_BYTES,
+               .dst_maxburst = 4,
+        };

on .dst_addr you are effectively casting a phys_addr_t
into a dma_addr_t.

But  we must do this at some point, and now I think
that doing it here may be just as good (because we might
just add a physical-to-dma memory translation if need
be).

So allright.

Yours,
Linus Walleij


From arnd at arndb.de  Thu Apr 25 10:11:39 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 25 Apr 2013 16:11:39 +0200
Subject: [PATCH 6/9] crypto: ux500/cryp - Set DMA configuration though
 dma_slave_config()
In-Reply-To: <20130425134402.GN4623@gmail.com>
References: <1366280825-31136-1-git-send-email-lee.jones@linaro.org>
 <CACRpkdbFgW6bGYt59WtN4r2izuN09AJw4J1cqir82uzFsuMmWQ@mail.gmail.com>
 <20130425134402.GN4623@gmail.com>
Message-ID: <201304251611.39667.arnd@arndb.de>

On Thursday 25 April 2013, Lee Jones wrote:

> > > @@ -232,6 +236,7 @@ struct cryp_dma {
> > >   */
> > >  struct cryp_device_data {
> > >         struct cryp_register __iomem *base;
> > > +       phys_addr_t phybase;
> > 
> > Use dma_addr_t. Maybe "phybase" is misleading,
> > "dmabase" is probably better. (Also applies to the
> > cryp patch).
> 
> Accept it's not the dmabase.
> 
> It's the phybase (U8500_CRYP1_BASE) i.e. the physical base address of
> the device's regs.

Right, this recently came up in a different context and I agree:

The dma engine driver must know the address in its dma space, while the
slave driver has it available in physical space. These two are often the
same, but there is no generic way to convert between the two, especially
if the dma engine resides behind an IOMMU.

The best assumption we can make is that the dma engine driver knows
how to convert between the two. Interestingly the documentation for
dma_slave_config talks about "physical address", while the structure
itself uses a dma_addr_t. Linus Walleij introduced the structure in
c156d0a5b0 "DMAENGINE: generic slave channel control v3", so I assume
he can shed some light on what he was thinking. I assume the documentation
is right but the structure is not and should be converted to use
phys_add_t or resource_size_t.

	Arnd


From tglx at linutronix.de  Thu Apr 25 10:18:51 2013
From: tglx at linutronix.de (Thomas Gleixner)
Date: Thu, 25 Apr 2013 16:18:51 +0200 (CEST)
Subject: RFC: [PATCH] clocksource: tcb: fix min_delta calculation
In-Reply-To: <51793172.9030802@pengutronix.de>
References: <517687AB.1040309@pengutronix.de>
 <1366722524-25991-1-git-send-email-mkl@pengutronix.de>
 <51793172.9030802@pengutronix.de>
Message-ID: <alpine.LFD.2.02.1304251618220.21884@ionos>

On Thu, 25 Apr 2013, Marc Kleine-Budde wrote:

> On 04/23/2013 03:08 PM, Marc Kleine-Budde wrote:
> > The commit
> > 
> >     77cc982 clocksource: use clockevents_config_and_register() where possible
> > 
> > switches from manually calculating min_delta_ns (and others) and
> > clockevents_register_device() to automatic calculation via
> > clockevents_config_and_register(). During this conversation the "+ 1" in
> > 
> >     min_delta_ns = clockevent_delta2ns(1, &clkevt.clkevt) + 1;
> > 
> > was lost. This leads to problems with schedule_delayed_work() with a delay of
> > "1". Resulting in the work not scheduled in time.
> > 
> > This patch fixes the problem by increasing the min_delta to "2" ticks.
> > 
> > Signed-off-by: Marc Kleine-Budde <mkl at pengutronix.de>
> 
> Who will take care of this patch?

If you had cc'ed me in the first place ...
 
> Marc
> 
> > ---
> >  drivers/clocksource/tcb_clksrc.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/clocksource/tcb_clksrc.c b/drivers/clocksource/tcb_clksrc.c
> > index 8a61872..7cf6dc7 100644
> > --- a/drivers/clocksource/tcb_clksrc.c
> > +++ b/drivers/clocksource/tcb_clksrc.c
> > @@ -197,7 +197,7 @@ static void __init setup_clkevents(struct atmel_tc *tc, int clk32k_divisor_idx)
> >  
> >  	clkevt.clkevt.cpumask = cpumask_of(0);
> >  
> > -	clockevents_config_and_register(&clkevt.clkevt, 32768, 1, 0xffff);
> > +	clockevents_config_and_register(&clkevt.clkevt, 32768, 2, 0xffff);
> >  
> >  	setup_irq(irq, &tc_irqaction);
> >  }
> > 
> 
> 
> -- 
> Pengutronix e.K.                  | Marc Kleine-Budde           |
> Industrial Linux Solutions        | Phone: +49-231-2826-924     |
> Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
> Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |
> 
> 


From tglx at linutronix.de  Thu Apr 25 10:21:58 2013
From: tglx at linutronix.de (Thomas Gleixner)
Date: Thu, 25 Apr 2013 16:21:58 +0200 (CEST)
Subject: RFC: [PATCH] clocksource: tcb: fix min_delta calculation
In-Reply-To: <1366722524-25991-1-git-send-email-mkl@pengutronix.de>
References: <517687AB.1040309@pengutronix.de>
 <1366722524-25991-1-git-send-email-mkl@pengutronix.de>
Message-ID: <alpine.LFD.2.02.1304251618590.21884@ionos>

On Tue, 23 Apr 2013, Marc Kleine-Budde wrote:
> The commit
> 
>     77cc982 clocksource: use clockevents_config_and_register() where possible
> 
> switches from manually calculating min_delta_ns (and others) and
> clockevents_register_device() to automatic calculation via
> clockevents_config_and_register(). During this conversation the "+ 1" in
> 
>     min_delta_ns = clockevent_delta2ns(1, &clkevt.clkevt) + 1;
> 
> was lost. This leads to problems with schedule_delayed_work() with a delay of
> "1". Resulting in the work not scheduled in time.

Errm. How is schedule_delayed_work() related to this?

schedule_delayed_work() is jiffies based and has absolutely nothing to
do with clockevents.
 
> This patch fixes the problem by increasing the min_delta to "2" ticks.

This changelog sucks.

> Signed-off-by: Marc Kleine-Budde <mkl at pengutronix.de>
> ---
>  drivers/clocksource/tcb_clksrc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/clocksource/tcb_clksrc.c b/drivers/clocksource/tcb_clksrc.c
> index 8a61872..7cf6dc7 100644
> --- a/drivers/clocksource/tcb_clksrc.c
> +++ b/drivers/clocksource/tcb_clksrc.c
> @@ -197,7 +197,7 @@ static void __init setup_clkevents(struct atmel_tc *tc, int clk32k_divisor_idx)
>  
>  	clkevt.clkevt.cpumask = cpumask_of(0);
>  
> -	clockevents_config_and_register(&clkevt.clkevt, 32768, 1, 0xffff);
> +	clockevents_config_and_register(&clkevt.clkevt, 32768, 2, 0xffff);
>  
>  	setup_irq(irq, &tc_irqaction);
>  }
> -- 
> 1.8.2.rc2
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 


From jlu at pengutronix.de  Thu Apr 25 10:39:38 2013
From: jlu at pengutronix.de (Jan =?ISO-8859-1?Q?L=FCbbe?=)
Date: Thu, 25 Apr 2013 16:39:38 +0200
Subject: [PATCH] ARM: add unwind annotations to ftrace asm
In-Reply-To: <1364076649-16841-1-git-send-email-rabin@rab.in>
References: <1364076649-16841-1-git-send-email-rabin@rab.in>
Message-ID: <1366900778.4158.124.camel@coredoba.hi.pengutronix.de>

On Sat, 2013-03-23 at 23:10 +0100, Rabin Vincent wrote:
> Add unwind annotations to the ftrace assembly code so that the function
> tracer's stacktracing options (func_stack_trace, etc.) work when
> CONFIG_ARM_UNWIND is enabled.
> 
> Signed-off-by: Rabin Vincent <rabin at rab.in>

In my test this fixes func_stack_trace:

== without patch ==
# tracer: function
#
# entries-in-buffer/entries-written: 318/318   #P:1
#
#                              _-------=> irqs-off          
#                            /  _------=> need-resched      
#                            |/  _-----=> need-resched_lazy 
#                            ||/  _----=> hardirq/softirq   
#                            |||/  _---=> preempt-depth     
#                            ||||/  _--=> preempt-lazy-depth
#                            ||||| / _-=> migrate-disable   
#                            |||||| /     delay
#           TASK-PID   CPU#  |||||||    TIMESTAMP  FUNCTION
#              | |       |   |||||||       |         |
              sh-829   [000] d..h1..   838.966903: ktime_get <-tick_sched_timer
              sh-829   [000] d..h1..   838.966933: <stack trace>
 => ftrace_ops_no_ops
 => ftrace_graph_call
              sh-829   [000] d..h1..   838.966979: ktime_get <-clockevents_program_event
              sh-829   [000] d..h1..   838.966990: <stack trace>

== with patch ==
# tracer: function
#
# entries-in-buffer/entries-written: 678/678   #P:1
#
#                              _-------=> irqs-off          
#                            /  _------=> need-resched      
#                            |/  _-----=> need-resched_lazy 
#                            ||/  _----=> hardirq/softirq   
#                            |||/  _---=> preempt-depth     
#                            ||||/  _--=> preempt-lazy-depth
#                            ||||| / _-=> migrate-disable   
#                            |||||| /     delay
#           TASK-PID   CPU#  |||||||    TIMESTAMP  FUNCTION
#              | |       |   |||||||       |         |
              sh-828   [000] d..h2..   108.367156: ktime_get <-tick_sched_timer
              sh-828   [000] d..h2..   108.367224: <stack trace>
 => ftrace_ops_no_ops
 => ftrace_graph_call
 => ktime_get
 => tick_sched_timer
 => __run_hrtimer
 => hrtimer_interrupt
 => omap2_gp_timer_interrupt
 => handle_irq_event_percpu
 => handle_irq_event
 => handle_level_irq
 => generic_handle_irq
 => handle_IRQ
 => omap3_intc_handle_irq
 => __irq_svc
 => sub_preempt_count
 => cap_vm_enough_memory
 => security_vm_enough_memory_mm
 => mmap_region
 => do_mmap_pgoff
 => vm_mmap_pgoff
 => sys_mmap_pgoff
 => ret_fast_syscall

Thanks for this fix!

Regards,
Jan
-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |



From pawel.moll at arm.com  Thu Apr 25 10:40:49 2013
From: pawel.moll at arm.com (Pawel Moll)
Date: Thu, 25 Apr 2013 15:40:49 +0100
Subject: [PATCH] mfd: vexpress: Handle pending config transactions
In-Reply-To: <1366894965.3528.19.camel@computer5.home>
References: <1366821084-12815-1-git-send-email-pawel.moll@arm.com>
 <1366894965.3528.19.camel@computer5.home>
Message-ID: <1366900849.10438.12.camel@hornet>

On Thu, 2013-04-25 at 14:02 +0100, Jon Medhurst (Tixy) wrote:
> > +	while (!list_empty(&bridge->transactions)) {
> > +		trans = list_first_entry(&bridge->transactions,
> > +				struct vexpress_config_trans, list);
> >  
> > -		bridge->info->func_exec(trans->func->func, trans->offset,
> > -				trans->write, trans->data);
> > +		vexpress_config_dump_trans("Executing pending", trans);
> > +		status = bridge->info->func_exec(trans->func->func,
> > +				trans->offset, trans->write, trans->data);
> > +
> > +		if (status == VEXPRESS_CONFIG_STATUS_DONE)
> > +			vexpress_config_dump_trans("Finished pending", trans);
> > +		else
> > +			break;
> 
> For each transaction we execute in this loop, don't we also need to do
> the actions vexpress_config_complete does? E.g.
> 
> 	trans->status = status;
> 	list_del(&trans->list);
> 	complete(&trans->completion);
> 
> except in the case status==VEXPRESS_CONFIG_STATUS_WAIT.

You're completely right. I shouldn't have write this code as the last
thing in the afternoon...

Will send v2.

Pawe?




From nicolas.pitre at linaro.org  Thu Apr 25 10:42:41 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Thu, 25 Apr 2013 10:42:41 -0400 (EDT)
Subject: [PATCH v8 2/2] ARM: Enable selection of SMP operations at boot
 time
In-Reply-To: <20130425084933.GB12848@mudshark.cambridge.arm.com>
References: <alpine.DEB.2.02.1304241935010.4180@kaball.uk.xensource.com>
 <1366828819-10745-2-git-send-email-stefano.stabellini@eu.citrix.com>
 <20130425084933.GB12848@mudshark.cambridge.arm.com>
Message-ID: <alpine.LFD.2.03.1304251040430.1258@syhkavp.arg>

On Thu, 25 Apr 2013, Will Deacon wrote:

> On Wed, Apr 24, 2013 at 07:40:19PM +0100, Stefano Stabellini wrote:
> > From: Jon Medhurst <tixy at linaro.org>
> > 
> > Add a new 'smp_init' hook to machine_desc so platforms can specify a
> > function to be used to setup smp ops instead of having a statically
> > defined value.  The hook must return true when smp_ops are initialized.
> > If false the static mdesc->smp_ops will be used by default.
> > 
> > Signed-off-by: Jon Medhurst <tixy at linaro.org>
> > Signed-off-by: Nicolas Pitre <nicolas.pitre at linaro.org>
> > Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
> > Reviewed-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
> > ---
> >  arch/arm/include/asm/mach/arch.h |    4 ++++
> >  arch/arm/kernel/setup.c          |   10 ++++++----
> >  2 files changed, 10 insertions(+), 4 deletions(-)
> 
> [...]
> 
> >  	if (is_smp()) {
> > -		if (psci_smp_available())
> > -			smp_set_ops(&psci_smp_ops);
> > -		else if (mdesc->smp)
> > -			smp_set_ops(mdesc->smp);
> > +		if (!mdesc->smp_init || !mdesc->smp_init()) {
> 
> Minor nit, but this feels backwards to me. We usually return 0 on success,
> yet we're saying here that if mdesc->smp_init() returns 0, then we go and
> override the smp ops.

It doesn't return 0, but true or false.  So, semantically, if ->smp_init 
returns false, that means it didn't initialize anything.


Nicolas


From shawn.guo at linaro.org  Thu Apr 25 10:43:26 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Thu, 25 Apr 2013 22:43:26 +0800
Subject: [PATCH v2 0/2] dma: imx-sdma: add generic DMA device tree bindings
 support
Message-ID: <1366901008-7593-1-git-send-email-shawn.guo@linaro.org>

Changes since v1:
 * Fix the example typo in bindings doc.  Thanks to Fabio.

Shawn Guo (2):
  dma: imx: change enum definitions to macros
  dma: imx-sdma: move to generic device tree bindings

 .../devicetree/bindings/dma/fsl-imx-sdma.txt       |   22 ++++++++++
 drivers/dma/imx-sdma.c                             |   44 +++++++++++++++++++-
 include/dt-bindings/dma/imx.h                      |   29 +++++++++++++
 include/linux/platform_data/dma-imx.h              |   37 +---------------
 4 files changed, 95 insertions(+), 37 deletions(-)
 create mode 100644 include/dt-bindings/dma/imx.h

-- 
1.7.9.5




From shawn.guo at linaro.org  Thu Apr 25 10:43:27 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Thu, 25 Apr 2013 22:43:27 +0800
Subject: [PATCH v2 1/2] dma: imx: change enum definitions to macros
In-Reply-To: <1366901008-7593-1-git-send-email-shawn.guo@linaro.org>
References: <1366901008-7593-1-git-send-email-shawn.guo@linaro.org>
Message-ID: <1366901008-7593-2-git-send-email-shawn.guo@linaro.org>

Change enum sdma_peripheral_type and imx_dma_prio to macro definitions
for easing the migration to generic DMA device tree bindings later.

Signed-off-by: Shawn Guo <shawn.guo at linaro.org>
---
 drivers/dma/imx-sdma.c                |    4 +--
 include/linux/platform_data/dma-imx.h |   56 +++++++++++++++------------------
 2 files changed, 28 insertions(+), 32 deletions(-)

diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index 092867b..e57a0c6 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -249,7 +249,7 @@ struct sdma_channel {
 	struct sdma_engine		*sdma;
 	unsigned int			channel;
 	enum dma_transfer_direction		direction;
-	enum sdma_peripheral_type	peripheral_type;
+	int				peripheral_type;
 	unsigned int			event_id0;
 	unsigned int			event_id1;
 	enum dma_slave_buswidth		word_size;
@@ -580,7 +580,7 @@ static irqreturn_t sdma_int_handler(int irq, void *dev_id)
  * sets the pc of SDMA script according to the peripheral type
  */
 static void sdma_get_pc(struct sdma_channel *sdmac,
-		enum sdma_peripheral_type peripheral_type)
+		int peripheral_type)
 {
 	struct sdma_engine *sdma = sdmac->sdma;
 	int per_2_emi = 0, emi_2_per = 0;
diff --git a/include/linux/platform_data/dma-imx.h b/include/linux/platform_data/dma-imx.h
index f6d30cc..8a8a684 100644
--- a/include/linux/platform_data/dma-imx.h
+++ b/include/linux/platform_data/dma-imx.h
@@ -16,40 +16,36 @@
 /*
  * This enumerates peripheral types. Used for SDMA.
  */
-enum sdma_peripheral_type {
-	IMX_DMATYPE_SSI,	/* MCU domain SSI */
-	IMX_DMATYPE_SSI_SP,	/* Shared SSI */
-	IMX_DMATYPE_MMC,	/* MMC */
-	IMX_DMATYPE_SDHC,	/* SDHC */
-	IMX_DMATYPE_UART,	/* MCU domain UART */
-	IMX_DMATYPE_UART_SP,	/* Shared UART */
-	IMX_DMATYPE_FIRI,	/* FIRI */
-	IMX_DMATYPE_CSPI,	/* MCU domain CSPI */
-	IMX_DMATYPE_CSPI_SP,	/* Shared CSPI */
-	IMX_DMATYPE_SIM,	/* SIM */
-	IMX_DMATYPE_ATA,	/* ATA */
-	IMX_DMATYPE_CCM,	/* CCM */
-	IMX_DMATYPE_EXT,	/* External peripheral */
-	IMX_DMATYPE_MSHC,	/* Memory Stick Host Controller */
-	IMX_DMATYPE_MSHC_SP,	/* Shared Memory Stick Host Controller */
-	IMX_DMATYPE_DSP,	/* DSP */
-	IMX_DMATYPE_MEMORY,	/* Memory */
-	IMX_DMATYPE_FIFO_MEMORY,/* FIFO type Memory */
-	IMX_DMATYPE_SPDIF,	/* SPDIF */
-	IMX_DMATYPE_IPU_MEMORY,	/* IPU Memory */
-	IMX_DMATYPE_ASRC,	/* ASRC */
-	IMX_DMATYPE_ESAI,	/* ESAI */
-};
+#define IMX_DMATYPE_SSI		0  /* MCU domain SSI */
+#define IMX_DMATYPE_SSI_SP	1  /* Shared SSI */
+#define IMX_DMATYPE_MMC		2  /* MMC */
+#define IMX_DMATYPE_SDHC	3  /* SDHC */
+#define IMX_DMATYPE_UART	4  /* MCU domain UART */
+#define IMX_DMATYPE_UART_SP	5  /* Shared UART */
+#define IMX_DMATYPE_FIRI	6  /* FIRI */
+#define IMX_DMATYPE_CSPI	7  /* MCU domain CSPI */
+#define IMX_DMATYPE_CSPI_SP	8  /* Shared CSPI */
+#define IMX_DMATYPE_SIM		9  /* SIM */
+#define IMX_DMATYPE_ATA		10 /* ATA */
+#define IMX_DMATYPE_CCM		11 /* CCM */
+#define IMX_DMATYPE_EXT		12 /* External peripheral */
+#define IMX_DMATYPE_MSHC	13 /* Memory Stick Host Controller */
+#define IMX_DMATYPE_MSHC_SP	14 /* Shared Memory Stick Host Controller */
+#define IMX_DMATYPE_DSP		15 /* DSP */
+#define IMX_DMATYPE_MEMORY	16 /* Memory */
+#define IMX_DMATYPE_FIFO_MEMORY	17 /* FIFO type Memory */
+#define IMX_DMATYPE_SPDIF	18 /* SPDIF */
+#define IMX_DMATYPE_IPU_MEMORY	19 /* IPU Memory */
+#define IMX_DMATYPE_ASRC	20 /* ASRC */
+#define IMX_DMATYPE_ESAI	21 /* ESAI */
 
-enum imx_dma_prio {
-	DMA_PRIO_HIGH = 0,
-	DMA_PRIO_MEDIUM = 1,
-	DMA_PRIO_LOW = 2
-};
+#define DMA_PRIO_HIGH		0
+#define DMA_PRIO_MEDIUM		1
+#define DMA_PRIO_LOW		2
 
 struct imx_dma_data {
 	int dma_request; /* DMA request line */
-	enum sdma_peripheral_type peripheral_type;
+	int peripheral_type;
 	int priority;
 };
 
-- 
1.7.9.5




From shawn.guo at linaro.org  Thu Apr 25 10:43:28 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Thu, 25 Apr 2013 22:43:28 +0800
Subject: [PATCH v2 2/2] dma: imx-sdma: move to generic device tree bindings
In-Reply-To: <1366901008-7593-1-git-send-email-shawn.guo@linaro.org>
References: <1366901008-7593-1-git-send-email-shawn.guo@linaro.org>
Message-ID: <1366901008-7593-3-git-send-email-shawn.guo@linaro.org>

Update imx-sdma driver to adopt generic DMA device tree bindings.  It
calls of_dma_controller_register() with imx-sdma specific of_dma_xlate
to get the generic DMA device tree helper support.  The #dma-cells for
imx-sdma must be 3, which includes request ID, peripheral type and
priority.

The definitions of peripheral type and priority get moved into
include/dt-bindings/dma/imx.h, so that the macros can also be used in
dts files.

The existing way of requesting channel, clients directly call
dma_request_channel(), still work there, and will be removed after
all imx-sdma clients get converted to generic DMA device tree helper.

Signed-off-by: Shawn Guo <shawn.guo at linaro.org>
---
 .../devicetree/bindings/dma/fsl-imx-sdma.txt       |   22 +++++++++++
 drivers/dma/imx-sdma.c                             |   40 ++++++++++++++++++++
 include/dt-bindings/dma/imx.h                      |   29 ++++++++++++++
 include/linux/platform_data/dma-imx.h              |   31 +--------------
 4 files changed, 92 insertions(+), 30 deletions(-)
 create mode 100644 include/dt-bindings/dma/imx.h

diff --git a/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt b/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt
index d1e3f44..8bd8d35 100644
--- a/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt
+++ b/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt
@@ -4,6 +4,11 @@ Required properties:
 - compatible : Should be "fsl,<chip>-sdma"
 - reg : Should contain SDMA registers location and length
 - interrupts : Should contain SDMA interrupt
+- #dma-cells : Must be <3>.
+  The first cell specifies the DMA request/event ID.  The second and
+  third cell specifies the peripheral type and priority of DMA transfer
+  respectively.  Refer to include/dt-bindings/dma/imx.h for available
+  peripheral types and priorities.
 - fsl,sdma-ram-script-name : Should contain the full path of SDMA RAM
   scripts firmware
 
@@ -13,5 +18,22 @@ sdma at 83fb0000 {
 	compatible = "fsl,imx51-sdma", "fsl,imx35-sdma";
 	reg = <0x83fb0000 0x4000>;
 	interrupts = <6>;
+	#dma-cells = <3>;
 	fsl,sdma-ram-script-name = "sdma-imx51.bin";
 };
+
+DMA clients connected to the i.MX SDMA controller must use the format
+described in the dma.txt file.
+
+Examples:
+
+ssi2: ssi at 70014000 {
+	compatible = "fsl,imx51-ssi", "fsl,imx21-ssi";
+	reg = <0x70014000 0x4000>;
+	interrupts = <30>;
+	clocks = <&clks 49>;
+	dmas = <&sdma 24 IMX_DMATYPE_SSI_SP DMA_PRIO_HIGH>,
+	       <&sdma 25 IMX_DMATYPE_SSI_SP DMA_PRIO_HIGH>;
+	dma-names = "rx", "tx";
+	fsl,fifo-depth = <15>;
+};
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index e57a0c6..f1324da 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -36,6 +36,7 @@
 #include <linux/dmaengine.h>
 #include <linux/of.h>
 #include <linux/of_device.h>
+#include <linux/of_dma.h>
 
 #include <asm/irq.h>
 #include <linux/platform_data/dma-imx-sdma.h>
@@ -1296,6 +1297,35 @@ err_dma_alloc:
 	return ret;
 }
 
+static bool sdma_filter_fn(struct dma_chan *chan, void *fn_param)
+{
+	struct imx_dma_data *data = fn_param;
+
+	if (!imx_dma_is_general_purpose(chan))
+		return false;
+
+	chan->private = data;
+
+	return true;
+}
+
+struct dma_chan *sdma_xlate(struct of_phandle_args *dma_spec,
+			    struct of_dma *ofdma)
+{
+	struct sdma_engine *sdma = ofdma->of_dma_data;
+	dma_cap_mask_t mask = sdma->dma_device.cap_mask;
+	struct imx_dma_data data;
+
+	if (dma_spec->args_count != 3)
+		return NULL;
+
+	data.dma_request = dma_spec->args[0];
+	data.peripheral_type = dma_spec->args[1];
+	data.priority = dma_spec->args[2];
+
+	return dma_request_channel(mask, sdma_filter_fn, &data);
+}
+
 static int __init sdma_probe(struct platform_device *pdev)
 {
 	const struct of_device_id *of_id =
@@ -1443,10 +1473,20 @@ static int __init sdma_probe(struct platform_device *pdev)
 		goto err_init;
 	}
 
+	if (np) {
+		ret = of_dma_controller_register(np, sdma_xlate, sdma);
+		if (ret) {
+			dev_err(&pdev->dev, "failed to register controller\n");
+			goto err_register;
+		}
+	}
+
 	dev_info(sdma->dev, "initialized\n");
 
 	return 0;
 
+err_register:
+	dma_async_device_unregister(&sdma->dma_device);
 err_init:
 	kfree(sdma->script_addrs);
 err_alloc:
diff --git a/include/dt-bindings/dma/imx.h b/include/dt-bindings/dma/imx.h
new file mode 100644
index 0000000..d5de68c
--- /dev/null
+++ b/include/dt-bindings/dma/imx.h
@@ -0,0 +1,29 @@
+/*
+ * This enumerates peripheral types. Used for SDMA.
+ */
+#define IMX_DMATYPE_SSI		0  /* MCU domain SSI */
+#define IMX_DMATYPE_SSI_SP	1  /* Shared SSI */
+#define IMX_DMATYPE_MMC		2  /* MMC */
+#define IMX_DMATYPE_SDHC	3  /* SDHC */
+#define IMX_DMATYPE_UART	4  /* MCU domain UART */
+#define IMX_DMATYPE_UART_SP	5  /* Shared UART */
+#define IMX_DMATYPE_FIRI	6  /* FIRI */
+#define IMX_DMATYPE_CSPI	7  /* MCU domain CSPI */
+#define IMX_DMATYPE_CSPI_SP	8  /* Shared CSPI */
+#define IMX_DMATYPE_SIM		9  /* SIM */
+#define IMX_DMATYPE_ATA		10 /* ATA */
+#define IMX_DMATYPE_CCM		11 /* CCM */
+#define IMX_DMATYPE_EXT		12 /* External peripheral */
+#define IMX_DMATYPE_MSHC	13 /* Memory Stick Host Controller */
+#define IMX_DMATYPE_MSHC_SP	14 /* Shared Memory Stick Host Controller */
+#define IMX_DMATYPE_DSP		15 /* DSP */
+#define IMX_DMATYPE_MEMORY	16 /* Memory */
+#define IMX_DMATYPE_FIFO_MEMORY	17 /* FIFO type Memory */
+#define IMX_DMATYPE_SPDIF	18 /* SPDIF */
+#define IMX_DMATYPE_IPU_MEMORY	19 /* IPU Memory */
+#define IMX_DMATYPE_ASRC	20 /* ASRC */
+#define IMX_DMATYPE_ESAI	21 /* ESAI */
+
+#define DMA_PRIO_HIGH		0
+#define DMA_PRIO_MEDIUM		1
+#define DMA_PRIO_LOW		2
diff --git a/include/linux/platform_data/dma-imx.h b/include/linux/platform_data/dma-imx.h
index 8a8a684..33f7eda 100644
--- a/include/linux/platform_data/dma-imx.h
+++ b/include/linux/platform_data/dma-imx.h
@@ -12,36 +12,7 @@
 #include <linux/scatterlist.h>
 #include <linux/device.h>
 #include <linux/dmaengine.h>
-
-/*
- * This enumerates peripheral types. Used for SDMA.
- */
-#define IMX_DMATYPE_SSI		0  /* MCU domain SSI */
-#define IMX_DMATYPE_SSI_SP	1  /* Shared SSI */
-#define IMX_DMATYPE_MMC		2  /* MMC */
-#define IMX_DMATYPE_SDHC	3  /* SDHC */
-#define IMX_DMATYPE_UART	4  /* MCU domain UART */
-#define IMX_DMATYPE_UART_SP	5  /* Shared UART */
-#define IMX_DMATYPE_FIRI	6  /* FIRI */
-#define IMX_DMATYPE_CSPI	7  /* MCU domain CSPI */
-#define IMX_DMATYPE_CSPI_SP	8  /* Shared CSPI */
-#define IMX_DMATYPE_SIM		9  /* SIM */
-#define IMX_DMATYPE_ATA		10 /* ATA */
-#define IMX_DMATYPE_CCM		11 /* CCM */
-#define IMX_DMATYPE_EXT		12 /* External peripheral */
-#define IMX_DMATYPE_MSHC	13 /* Memory Stick Host Controller */
-#define IMX_DMATYPE_MSHC_SP	14 /* Shared Memory Stick Host Controller */
-#define IMX_DMATYPE_DSP		15 /* DSP */
-#define IMX_DMATYPE_MEMORY	16 /* Memory */
-#define IMX_DMATYPE_FIFO_MEMORY	17 /* FIFO type Memory */
-#define IMX_DMATYPE_SPDIF	18 /* SPDIF */
-#define IMX_DMATYPE_IPU_MEMORY	19 /* IPU Memory */
-#define IMX_DMATYPE_ASRC	20 /* ASRC */
-#define IMX_DMATYPE_ESAI	21 /* ESAI */
-
-#define DMA_PRIO_HIGH		0
-#define DMA_PRIO_MEDIUM		1
-#define DMA_PRIO_LOW		2
+#include <dt-bindings/dma/imx.h>
 
 struct imx_dma_data {
 	int dma_request; /* DMA request line */
-- 
1.7.9.5




From arnd at arndb.de  Thu Apr 25 10:46:27 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 25 Apr 2013 16:46:27 +0200
Subject: [PATCH v3 00/13] ARM: EXYNOS: Fix Universal C210 support
In-Reply-To: <1366731994-7478-1-git-send-email-t.figa@samsung.com>
References: <1366731994-7478-1-git-send-email-t.figa@samsung.com>
Message-ID: <201304251646.28026.arnd@arndb.de>

On Tuesday 23 April 2013, Tomasz Figa wrote:
> This series intends to fix support for Universal C210 board in mainline.
> Main difference from other boards based on Exynos 4210 is that hardware
> revision of the SoC used on Universal C210 does not support MCT timers
> and legacy PWM timers must be used instead.
> 
> First (and the biggest) part of the series deals with cleaning up and
> fixing the samsung_pwm_timer clocksource driver, that was posted
> recently by Arnd. In addition the driver is prepared to share the
> hardware with PWM driver that will be reworked later, since it is not
> a component crucial for system operation.
> 
> Second part fixes ATAGS support of Exynos 4210 rev0 SoC, which needs
> different timer initialization, using the new samsung_pwm_timer driver.
> 
> Third and last part adds Device Tree-based support for Universal C210
> board by providing device tree sources for it.
> 
> On Universal C210 board, both with and without DT:
> 
> Tested-by: Tomasz Figa <t.figa at samsung.com>

Reviewed-by: Arnd Bergmann <arnd at arndb.de>

Olof, Kgene, I think we should have this one in 3.10 since it fixes
a regression. It looks bigger than it really is because I asked Tomasz
to do small patches rather than a single combined patch.

	Arnd


From mkl at pengutronix.de  Thu Apr 25 10:53:57 2013
From: mkl at pengutronix.de (Marc Kleine-Budde)
Date: Thu, 25 Apr 2013 16:53:57 +0200
Subject: RFC: [PATCH] clocksource: tcb: fix min_delta calculation
In-Reply-To: <alpine.LFD.2.02.1304251618590.21884@ionos>
References: <517687AB.1040309@pengutronix.de>
 <1366722524-25991-1-git-send-email-mkl@pengutronix.de>
 <alpine.LFD.2.02.1304251618590.21884@ionos>
Message-ID: <51794385.1030308@pengutronix.de>

On 04/25/2013 04:21 PM, Thomas Gleixner wrote:
> On Tue, 23 Apr 2013, Marc Kleine-Budde wrote:
>> The commit
>>
>>     77cc982 clocksource: use clockevents_config_and_register() where possible
>>
>> switches from manually calculating min_delta_ns (and others) and
>> clockevents_register_device() to automatic calculation via
>> clockevents_config_and_register(). During this conversation the "+ 1" in
>>
>>     min_delta_ns = clockevent_delta2ns(1, &clkevt.clkevt) + 1;
>>
>> was lost. This leads to problems with schedule_delayed_work() with a delay of
>> "1". Resulting in the work not scheduled in time.
> 
> Errm. How is schedule_delayed_work() related to this?

Let me explain:
For other reasons [1], we reverted:

    f23eb2b tty: stop using "delayed_work" in the tty layer

(for reference find the patch below [2]). Which basically means
tty_schedule_flip() uses schedule_delayed_work(&buf->work, 1) instead
of schedule_work(&buf->work) as mainline does.

This works pretty well until v3.8. With v3.9-rc kernel the serial
console gets sluggish. It takes several seconds to abort a "find /" on
a serial console with Ctrl+c. I've bisected the problem down to:

    77cc982 clocksource: use clockevents_config_and_register() where
            possible

A printk shows the subtile difference in the min_delta_ns:

good: setup_clkevents: shift=32 mult=140737 min=30518 max=1999976422
bad:  setup_clkevents: shift=32 mult=140737 min=30517 max=1999976422

Restoring min_delta_ns to the original value, with this hackish patch,
"fixes" the serial problem, too:

diff --git a/drivers/clocksource/tcb_clksrc.c b/drivers/clocksource/tcb_clksrc.c
index 8a61872..30e0a68 100644
--- a/drivers/clocksource/tcb_clksrc.c
+++ b/drivers/clocksource/tcb_clksrc.c
@@ -198,6 +198,7 @@ static void __init setup_clkevents(struct atmel_tc *tc, int clk32k_divisor_idx)
        clkevt.clkevt.cpumask = cpumask_of(0);

        clockevents_config_and_register(&clkevt.clkevt, 32768, 1, 0xffff);
+       clkevt.clkevt.min_delta_ns = clockevent_delta2ns(1, &clkevt.clkevt) + 1;

        setup_irq(irq, &tc_irqaction);
 }

> schedule_delayed_work() is jiffies based and has absolutely nothing to
> do with clockevents.

I'm puzzled, too.

>> This patch fixes the problem by increasing the min_delta to "2" ticks.
> 
> This changelog sucks.
> 
>> Signed-off-by: Marc Kleine-Budde <mkl at pengutronix.de>
>> ---
>>  drivers/clocksource/tcb_clksrc.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/clocksource/tcb_clksrc.c b/drivers/clocksource/tcb_clksrc.c
>> index 8a61872..7cf6dc7 100644
>> --- a/drivers/clocksource/tcb_clksrc.c
>> +++ b/drivers/clocksource/tcb_clksrc.c
>> @@ -197,7 +197,7 @@ static void __init setup_clkevents(struct atmel_tc *tc, int clk32k_divisor_idx)
>>  
>>  	clkevt.clkevt.cpumask = cpumask_of(0);
>>  
>> -	clockevents_config_and_register(&clkevt.clkevt, 32768, 1, 0xffff);
>> +	clockevents_config_and_register(&clkevt.clkevt, 32768, 2, 0xffff);
>>  
>>  	setup_irq(irq, &tc_irqaction);
>>  }

[1] http://permalink.gmane.org/gmane.linux.kernel/1479280

[2]
From e4d43afca06724c6a59b8caac1f5dc07a9974aaa Mon Sep 17 00:00:00 2001
From: Steffen Trumtrar <s.trumtrar at pengutronix.de>
Date: Fri, 5 Apr 2013 16:38:55 +0200
Subject: [PATCH] HACK: tty: Revert stop using "delayed_work" in the tty layer

This patch reverts:

    f23eb2b tty: stop using "delayed_work" in the tty layer

That patch changed the tty buffer flip from beeing handled in a "delayed_work"
to an immediately scheduled "work". The original motivation was to decrease the
latency, this however leads to 15-25 %-points of more load on certain
workloads.

Here, less load is more desired than low latency, thus the patch is reverted
until a mainline accepted solution is found.

See for a detailed discussion see:
http://permalink.gmane.org/gmane.linux.kernel/1479280

Signed-off-by: Steffen Trumtrar <s.trumtrar at pengutronix.de>
Signed-off-by: Marc Kleine-Budde <mkl at pengutronix.de>
---
 drivers/tty/n_tty.c      |  2 +-
 drivers/tty/tty_buffer.c | 12 ++++++------
 drivers/tty/tty_ldisc.c  | 10 +++++-----
 include/linux/tty.h      |  2 +-
 4 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c
index 05e72be..ead46da 100644
--- a/drivers/tty/n_tty.c
+++ b/drivers/tty/n_tty.c
@@ -153,7 +153,7 @@ static void n_tty_set_room(struct tty_struct *tty)
 	if (left && !old_left) {
 		WARN_RATELIMIT(tty->port->itty == NULL,
 				"scheduling with invalid itty\n");
-		schedule_work(&tty->port->buf.work);
+		schedule_delayed_work(&tty->port->buf.work, 1);
 	}
 }
 
diff --git a/drivers/tty/tty_buffer.c b/drivers/tty/tty_buffer.c
index 578aa75..187b874 100644
--- a/drivers/tty/tty_buffer.c
+++ b/drivers/tty/tty_buffer.c
@@ -339,7 +339,7 @@ void tty_schedule_flip(struct tty_port *port)
 	if (buf->tail != NULL)
 		buf->tail->commit = buf->tail->used;
 	spin_unlock_irqrestore(&buf->lock, flags);
-	schedule_work(&buf->work);
+	schedule_delayed_work(&buf->work, 1);
 }
 EXPORT_SYMBOL(tty_schedule_flip);
 
@@ -418,7 +418,7 @@ EXPORT_SYMBOL_GPL(tty_prepare_flip_string_flags);
 
 static void flush_to_ldisc(struct work_struct *work)
 {
-	struct tty_port *port = container_of(work, struct tty_port, buf.work);
+	struct tty_port *port = container_of(work, struct tty_port, buf.work.work);
 	struct tty_bufhead *buf = &port->buf;
 	struct tty_struct *tty;
 	unsigned long 	flags;
@@ -492,7 +492,7 @@ static void flush_to_ldisc(struct work_struct *work)
 void tty_flush_to_ldisc(struct tty_struct *tty)
 {
 	if (!tty->port->low_latency)
-		flush_work(&tty->port->buf.work);
+		flush_delayed_work(&tty->port->buf.work);
 }
 
 /**
@@ -520,9 +520,9 @@ void tty_flip_buffer_push(struct tty_port *port)
 	spin_unlock_irqrestore(&buf->lock, flags);
 
 	if (port->low_latency)
-		flush_to_ldisc(&buf->work);
+		flush_to_ldisc(&buf->work.work);
 	else
-		schedule_work(&buf->work);
+		schedule_delayed_work(&port->buf.work, 1);
 }
 EXPORT_SYMBOL(tty_flip_buffer_push);
 
@@ -545,6 +545,6 @@ void tty_buffer_init(struct tty_port *port)
 	buf->tail = NULL;
 	buf->free = NULL;
 	buf->memory_used = 0;
-	INIT_WORK(&buf->work, flush_to_ldisc);
+	INIT_DELAYED_WORK(&port->buf.work, flush_to_ldisc);
 }
 
diff --git a/drivers/tty/tty_ldisc.c b/drivers/tty/tty_ldisc.c
index d794087..1cb63f1 100644
--- a/drivers/tty/tty_ldisc.c
+++ b/drivers/tty/tty_ldisc.c
@@ -514,7 +514,7 @@ static void tty_ldisc_restore(struct tty_struct *tty, struct tty_ldisc *old)
 static int tty_ldisc_halt(struct tty_struct *tty)
 {
 	clear_bit(TTY_LDISC, &tty->flags);
-	return cancel_work_sync(&tty->port->buf.work);
+	return cancel_delayed_work(&tty->port->buf.work);
 }
 
 /**
@@ -527,7 +527,7 @@ static void tty_ldisc_flush_works(struct tty_struct *tty)
 {
 	flush_work(&tty->hangup_work);
 	flush_work(&tty->SAK_work);
-	flush_work(&tty->port->buf.work);
+	flush_delayed_work(&tty->port->buf.work);
 }
 
 /**
@@ -706,9 +706,9 @@ enable:
 	/* Restart the work queue in case no characters kick it off. Safe if
 	   already running */
 	if (work)
-		schedule_work(&tty->port->buf.work);
+		schedule_delayed_work(&tty->port->buf.work, 1);
 	if (o_work)
-		schedule_work(&o_tty->port->buf.work);
+		schedule_delayed_work(&o_tty->port->buf.work, 1);
 	mutex_unlock(&tty->ldisc_mutex);
 	tty_unlock(tty);
 	return retval;
@@ -819,7 +819,7 @@ void tty_ldisc_hangup(struct tty_struct *tty)
 	 */
 	clear_bit(TTY_LDISC, &tty->flags);
 	tty_unlock(tty);
-	cancel_work_sync(&tty->port->buf.work);
+	cancel_delayed_work(&tty->port->buf.work);
 	mutex_unlock(&tty->ldisc_mutex);
 retry:
 	tty_lock(tty);
diff --git a/include/linux/tty.h b/include/linux/tty.h
index c75d886..f7f6836 100644
--- a/include/linux/tty.h
+++ b/include/linux/tty.h
@@ -52,7 +52,7 @@ struct tty_buffer {
 
 
 struct tty_bufhead {
-	struct work_struct work;
+	struct delayed_work work;
 	spinlock_t lock;
 	struct tty_buffer *head;	/* Queue head */
 	struct tty_buffer *tail;	/* Active buffer */
-- 
1.8.2.rc2

-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130425/a8de572c/attachment.sig>

From nicolas.pitre at linaro.org  Thu Apr 25 10:58:19 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Thu, 25 Apr 2013 10:58:19 -0400 (EDT)
Subject: [PATCH v8 1/2] arm: introduce psci_smp_ops
In-Reply-To: <20130425104508.GG12848@mudshark.cambridge.arm.com>
References: <alpine.DEB.2.02.1304241935010.4180@kaball.uk.xensource.com>
 <1366828819-10745-1-git-send-email-stefano.stabellini@eu.citrix.com>
 <20130425084711.GA12848@mudshark.cambridge.arm.com>
 <alpine.DEB.2.02.1304251104090.4180@kaball.uk.xensource.com>
 <20130425104508.GG12848@mudshark.cambridge.arm.com>
Message-ID: <alpine.LFD.2.03.1304251054420.1258@syhkavp.arg>

On Thu, 25 Apr 2013, Will Deacon wrote:

> On Thu, Apr 25, 2013 at 11:12:54AM +0100, Stefano Stabellini wrote:
> > On Thu, 25 Apr 2013, Will Deacon wrote:
> > > > +/*
> > > > + * cpu_suspend   Suspend the execution on a CPU
> > > > + * @state        we don't currently describe affinity levels, so just pass 0.
> > > > + * @entry_point  the first instruction to be executed on return
> > > > + * returns 0  success, < 0 on failure
> > > > + *
> > > > + * cpu_off       Power down a CPU
> > > > + * @state        we don't currently describe affinity levels, so just pass 0.
> > > > + * no return on successful call
> > > > + *
> > > > + * cpu_on        Power up a CPU
> > > > + * @cpuid        cpuid of target CPU, as from MPIDR
> > > > + * @entry_point  the first instruction to be executed on return
> > > > + * returns 0  success, < 0 on failure
> > > > + *
> > > > + * migrate       Migrate the context to a different CPU
> > > > + * @cpuid        cpuid of target CPU, as from MPIDR
> > > > + * returns 0  success, < 0 on failure
> > > > + *
> > > > + */
> > > 
> > > Can you move these comments into psci-smp.c please? They're really specific
> > > to the implementation there, and if we put them in a header we're lying to
> > > ourselves about the parameters actually described by the PSCI specification.
> > 
> > You have a good point about the PSCI spec.
> > 
> > However from the Linux POV these comments should regard the functions
> > exported by psci_operations, not the firmware interface, this is why I
> > think it makes sense to keep them in psci.h.
> > What we are saying is for example that psci_operations.cpu_on returns 0
> > on success and < 0 on failure, and it takes a cpuid and an entry point
> > as parameters. We are not saying anything about the firmware interface.
> 
> I disagree. You're explicitly stating that we pass the `cpuid of target CPU,
> as from MPIDR'. That's simply not true -- the firmware could choose any
> numbering scheme to identify the CPUs. For KVM and Xen, it *is* the mpidr,
> which is why psci-smp.c works at all, but that's where the comment belongs,
> not in this header file.

At some point, the _kernel_ API for interfacing with the firmware's PSCI 
will have to ensure uniformity somehow.  The PSCI interface code could 
translate the passed MPIDR into whatever the firmware decided to use for 
identifying CPUs if needed, keeping this issue localized.


Nicolas


From tony at atomide.com  Thu Apr 25 11:01:20 2013
From: tony at atomide.com (Tony Lindgren)
Date: Thu, 25 Apr 2013 08:01:20 -0700
Subject: Multiple issues with omap4 panda es in linux next
In-Reply-To: <20130425090447.GK7889@arwen.pp.htv.fi>
References: <5174F7A8.7070308@ti.com> <20130422180316.GA10155@atomide.com>
 <5176A45B.5@ti.com> <20130423172353.GD10155@atomide.com>
 <20130423213151.GM10155@atomide.com>
 <20130423231605.GO10155@atomide.com> <517770A0.4000609@ti.com>
 <20130424190821.GB5184@atomide.com>
 <20130424192330.GC5184@atomide.com>
 <20130425090447.GK7889@arwen.pp.htv.fi>
Message-ID: <20130425150120.GH5184@atomide.com>

* Felipe Balbi <balbi at ti.com> [130425 02:10]:
> On Wed, Apr 24, 2013 at 12:23:30PM -0700, Tony Lindgren wrote:
> > * Tony Lindgren <tony at atomide.com> [130424 12:13]:
> > > * Kishon Vijay Abraham I <kishon at ti.com> [130423 22:46]:
> > > > Hi Tony,
> > > > 
> > > > On Wednesday 24 April 2013 04:46 AM, Tony Lindgren wrote:
> > > > >* Tony Lindgren <tony at atomide.com> [130423 14:37]:
> > > > >>* Tony Lindgren <tony at atomide.com> [130423 10:28]:
> > > > >>>* Kishon Vijay Abraham I <kishon at ti.com> [130423 08:15]:
> > > > >>>>>>>2. MUSB fails with legacy booting and DT on panda es
> > > > >>>>>>>
> > > > >>>>>>>With both legacy and DT booting I get something like:
> > > > >>>>>>>
> > > > >>>>>>>HS USB OTG: no transceiver configured
> > > > >>>>>>>musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with status -517
> > > > >>>>>>
> > > > >>>>>>The dt should work fine with https://patchwork.kernel.org/patch/2423061/.
> > > > >>>>>
> > > > >>>>>OK thanks for checking that.
> > > > >
> > > > >Kishon, I think there's also some other issue remaining
> > > > >in linux next with MUSB and DT. I'm still getting the
> > > > >"HS USB OTG: no transceiver configured" although the nop
> > > > >xceiv is compiled in. Maybe give it a try against linux
> > > > >next?
> > > > 
> > > > For OMAP4 MUSB, you'll need omap-usb2 phy. I've attached my .config.
> > > 
> > > Thanks your config helped me to track it down. Looks like I got
> > > the PHYs the wrong way around between EHCI and MUSB..
> > > 
> > > In any case, I did have omap-usb2 compiled in, but I did not have
> > > OMAP_OCP2SCP=y set. Should OMAP_USB2 depend on that?
> > > 
> > > Also, looks like MUSB just sits in b_idle mode though, so no more
> > > ID pin interrupt for some reason.
> > 
> > OK looks like I got the ID interrupt going by enabling
> > CONFIG_TWL6030_USB=y. Still stays in a_idle with no keyboard
> > after plugging it in, but now changes between a and b mode.
> 
> come again, you ground ID pin and have no devices attached ? Then it
> should stay in a_idle.

After playing with looks like it detects the keyboard after replugging
the cable a few times. So it's not detecting the keyboard every time when
plugged in, but sounds like that's not related to the DT patches. It's
probably the session bit related issues again..

Regards,

Tony


From cdall at cs.columbia.edu  Thu Apr 25 11:13:17 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Thu, 25 Apr 2013 08:13:17 -0700
Subject: [PATCH v3 08/32] arm64: KVM: architecture specific MMU backend
In-Reply-To: <517928BF.8090309@arm.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
 <1365437854-30214-9-git-send-email-marc.zyngier@arm.com>
 <20130423225816.GC20569@gmail.com> <5177BBEE.1090209@arm.com>
 <CAEDV+g+H+NFc5gsQYBmQDx598Oz3BHWHcrYhBYsWPbXaVYataA@mail.gmail.com>
 <517928BF.8090309@arm.com>
Message-ID: <CAEDV+gLtKjzEr_AA+GDXxYoV7o4sVf2g6KtHCYG8bJMhJy5=ag@mail.gmail.com>

On Thu, Apr 25, 2013 at 5:59 AM, Marc Zyngier <marc.zyngier at arm.com> wrote:
> On 24/04/13 17:55, Christoffer Dall wrote:
>> On Wed, Apr 24, 2013 at 4:03 AM, Marc Zyngier <marc.zyngier at arm.com> wrote:
>>> On 23/04/13 23:58, Christoffer Dall wrote:
>>>> On Mon, Apr 08, 2013 at 05:17:10PM +0100, Marc Zyngier wrote:
>>>>> Define the arm64 specific MMU backend:
>>>>> - HYP/kernel VA offset
>>>>> - S2 4/64kB definitions
>>>>> - S2 page table populating and flushing
>>>>> - icache cleaning
>>>>>
>>>>> Reviewed-by: Christopher Covington <cov at codeaurora.org>
>>>>> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
>>>>> ---
>>>>>  arch/arm64/include/asm/kvm_mmu.h | 136 +++++++++++++++++++++++++++++++++++++++
>>>>>  1 file changed, 136 insertions(+)
>>>>>  create mode 100644 arch/arm64/include/asm/kvm_mmu.h
>>>>>
>>>>> diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h
>>>>> new file mode 100644
>>>>> index 0000000..2eb2230
>>>>> --- /dev/null
>>>>> +++ b/arch/arm64/include/asm/kvm_mmu.h
>>>>> @@ -0,0 +1,136 @@
>>>>> +/*
>>>>> + * Copyright (C) 2012,2013 - ARM Ltd
>>>>> + * Author: Marc Zyngier <marc.zyngier at arm.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.
>>>>> + *
>>>>> + * This program is distributed in the hope that it will be useful,
>>>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>>>>> + * GNU General Public License for more details.
>>>>> + *
>>>>> + * You should have received a copy of the GNU General Public License
>>>>> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
>>>>> + */
>>>>> +
>>>>> +#ifndef __ARM64_KVM_MMU_H__
>>>>> +#define __ARM64_KVM_MMU_H__
>>>>> +
>>>>> +#include <asm/page.h>
>>>>> +#include <asm/memory.h>
>>>>> +
>>>>> +/*
>>>>> + * As we only have the TTBR0_EL2 register, we cannot express
>>>>> + * "negative" addresses. This makes it impossible to directly share
>>>>> + * mappings with the kernel.
>>>>> + *
>>>>> + * Instead, give the HYP mode its own VA region at a fixed offset from
>>>>> + * the kernel by just masking the top bits (which are all ones for a
>>>>> + * kernel address).
>>>>
>>>> For some reason I keep choking on this, despite it being very simple.
>>>> We're just defining a different PAGE_OFFSET, right? Why not do a hard
>>>> define as:
>>>>
>>>> #define HYP_PAGE_OFFSET_MASK  0x0000ffffffffffff
>>>> #define HYP_PAGE_OFFSET               0x0000ffc000000000
>>>>
>>>> ...or change the second paragraph of the comment to say
>>>> that we definethe HYP_PAGE_OFFSET to be 0x 0000ffc0 00000000.
>>>
>>> One of these days, VA_BITS will change to accommodate for more virtual
>>> space. When that day comes, I don't want to touch any of this because it
>>> did hurt enough when writing it. As such, I'll refrain from hardcoding
>>> anything.
>>>
>>> I don't mind a comment, though.
>>>
>>>>> + */
>>>>> +#define HYP_PAGE_OFFSET_SHIFT       VA_BITS
>>>>> +#define HYP_PAGE_OFFSET_MASK        ((UL(1) << HYP_PAGE_OFFSET_SHIFT) - 1)
>>>>
>>>> In any case, is there a reason for the HYP_PAGE_OFFSET_SHIFT
>>>> indirection? It may be simpler without...
>>>
>>> It is common practice to have XXX_SHIFT and XXX_MASK together.
>>>
>>>>> +#define HYP_PAGE_OFFSET             (PAGE_OFFSET & HYP_PAGE_OFFSET_MASK)
>>>>> +
>>>>> +/*
>>>>> + * Our virtual mapping for the idmap-ed MMU-enable code. Must be
>>>>> + * shared across all the page-tables. Conveniently, we use the last
>>>>> + * possible page, where no kernel mapping will ever exist.
>>>>> + */
>>>>> +#define TRAMPOLINE_VA               (HYP_PAGE_OFFSET_MASK & PAGE_MASK)
>>>>
>>>> hmmm, ok, here it's kind of nice to have that define correlation, so
>>>> maybe it's not cleaner.  Something should be improved here in the define
>>>> or the comment to make it more clear.  Perhaps just adding the real
>>>> constants in the comment or in Documentation/arm64/memory.txt would
>>>> help.
>>>
>>> Yes, I plan to write something there.
>>>
>>>>> +
>>>>> +#ifdef __ASSEMBLY__
>>>>> +
>>>>> +/*
>>>>> + * Convert a kernel VA into a HYP VA.
>>>>> + * reg: VA to be converted.
>>>>> + */
>>>>> +.macro kern_hyp_va  reg
>>>>> +    and     \reg, \reg, #HYP_PAGE_OFFSET_MASK
>>>>> +.endm
>>>>> +
>>>>> +#else
>>>>> +
>>>>> +#include <asm/cacheflush.h>
>>>>> +
>>>>> +#define KERN_TO_HYP(kva)    ((unsigned long)kva - PAGE_OFFSET + HYP_PAGE_OFFSET)
>>>>> +
>>>>> +/*
>>>>> + * Align KVM with the kernel's view of physical memory. Should be
>>>>> + * 40bit IPA, with PGD being 8kB aligned.
>>>>> + */
>>>>> +#define KVM_PHYS_SHIFT      PHYS_MASK_SHIFT
>>>>> +#define KVM_PHYS_SIZE       (1UL << KVM_PHYS_SHIFT)
>>>>> +#define KVM_PHYS_MASK       (KVM_PHYS_SIZE - 1UL)
>>>>> +
>>>>> +#ifdef CONFIG_ARM64_64K_PAGES
>>>>> +#define PAGE_LEVELS 2
>>>>> +#define BITS_PER_LEVEL      13
>>>>> +#else  /* 4kB pages */
>>>>> +#define PAGE_LEVELS 3
>>>>> +#define BITS_PER_LEVEL      9
>>>>> +#endif
>>>>
>>>> What are the semantics of these defines exactly? They should be
>>>> S2_PAGE_LEVELS and make some assumptions of the VTCR_EL2.SL0 field
>>>> right?
>>>
>>> Indeed, we assume SL0 is always 1, just like for the kernel. As for the
>>> semantics, I though they were pretty obvious...
>>>
>>
>> this is all stage2 right? so S2_PAGE_LEVELS may be more clear...
>
> It actually applies to both host Stage-1, HYP Stage-1 and guest Stage-2
> (we keep all page tables the same on the host side).
>
>>> PAGE_LEVELS is just that, the number of page levels. BITS_PER_LEVEL is
>>> the number of bits you need to index a particular level.
>>>
>>>>> +
>>>>> +/* Make sure we get the right size, and thus the right alignment */
>>>>
>>>> this comment is not particularly helpful, something explaining why the
>>>> max() thingy below makes sense would be more so :)  I really can't
>>>> follow the BITS_PER_S2_PGD and PTRS_PER_S2_PGD defines.
>>>
>>> Admittedly, they are a bit convoluted:
>>>
>>>>> +#define BITS_PER_S2_PGD (KVM_PHYS_SHIFT - (PAGE_LEVELS - 1) * BITS_PER_LEVEL - PAGE_SHIFT)
>>>
>>> This is how many bits of index you need in a PGD. With a 40bit IPA and a
>>> 4kB page size, you end up with a 10 bit index.
>>>
>>
>> oh, I see it now, you're basically taking away all the other bits you
>> know are used to find your address and consider the remaining amount
>> the necessary number of bits used to index into the PGD. Right? So I
>> think at least a comment saying that BITS_ indicates bits used for
>> indexing, not bits for a single entry or something else...
>>
>>>>> +#define PTRS_PER_S2_PGD (1 << max(BITS_PER_LEVEL, BITS_PER_S2_PGD))
>>>
>>> Now, in order to allocate your PGD, you need to find out how many
>>> pointers your PGD is going to contain. The max() is make sure we
>>> allocate at least a full page worth of pointers.
>>
>> I still don't get this, sorry. Can you provide me with the sane
>> counter example where BITS_PER_S2_PGD is not sufficient?
>
> Just take the above example, but with a 38 bit IPA. You end up with 8
> bit of index, which only gives you half a page worth of pointers. Yet,
> the PGD must be at least page aligned, hence using at least
> BITS_PER_LEVEL (9 bits in this example).
>
> Admittedly, that's a contrived example, as we don't support 38bit IPAs.
> But now try with 64kB pages. A 40bit IPA gives you 11 bits of index in
> your PGD. Clearly too short.
>
> Does it make more sense now?
>
yeah, got it, makes sense. I think the point I missed is that we set
the size in order to determine the alignment as well. If you have the
energy a comment to explain that would be nice I think.

Thanks for the explanation.


From balbi at ti.com  Thu Apr 25 11:13:04 2013
From: balbi at ti.com (Felipe Balbi)
Date: Thu, 25 Apr 2013 18:13:04 +0300
Subject: Multiple issues with omap4 panda es in linux next
In-Reply-To: <20130425150120.GH5184@atomide.com>
References: <20130422180316.GA10155@atomide.com> <5176A45B.5@ti.com>
 <20130423172353.GD10155@atomide.com>
 <20130423213151.GM10155@atomide.com>
 <20130423231605.GO10155@atomide.com> <517770A0.4000609@ti.com>
 <20130424190821.GB5184@atomide.com>
 <20130424192330.GC5184@atomide.com>
 <20130425090447.GK7889@arwen.pp.htv.fi>
 <20130425150120.GH5184@atomide.com>
Message-ID: <20130425151304.GK19395@arwen.pp.htv.fi>

HI,

On Thu, Apr 25, 2013 at 08:01:20AM -0700, Tony Lindgren wrote:
> > > > > >>>>>>>2. MUSB fails with legacy booting and DT on panda es
> > > > > >>>>>>>
> > > > > >>>>>>>With both legacy and DT booting I get something like:
> > > > > >>>>>>>
> > > > > >>>>>>>HS USB OTG: no transceiver configured
> > > > > >>>>>>>musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with status -517
> > > > > >>>>>>
> > > > > >>>>>>The dt should work fine with https://patchwork.kernel.org/patch/2423061/.
> > > > > >>>>>
> > > > > >>>>>OK thanks for checking that.
> > > > > >
> > > > > >Kishon, I think there's also some other issue remaining
> > > > > >in linux next with MUSB and DT. I'm still getting the
> > > > > >"HS USB OTG: no transceiver configured" although the nop
> > > > > >xceiv is compiled in. Maybe give it a try against linux
> > > > > >next?
> > > > > 
> > > > > For OMAP4 MUSB, you'll need omap-usb2 phy. I've attached my .config.
> > > > 
> > > > Thanks your config helped me to track it down. Looks like I got
> > > > the PHYs the wrong way around between EHCI and MUSB..
> > > > 
> > > > In any case, I did have omap-usb2 compiled in, but I did not have
> > > > OMAP_OCP2SCP=y set. Should OMAP_USB2 depend on that?
> > > > 
> > > > Also, looks like MUSB just sits in b_idle mode though, so no more
> > > > ID pin interrupt for some reason.
> > > 
> > > OK looks like I got the ID interrupt going by enabling
> > > CONFIG_TWL6030_USB=y. Still stays in a_idle with no keyboard
> > > after plugging it in, but now changes between a and b mode.
> > 
> > come again, you ground ID pin and have no devices attached ? Then it
> > should stay in a_idle.
> 
> After playing with looks like it detects the keyboard after replugging
> the cable a few times. So it's not detecting the keyboard every time when
> plugged in, but sounds like that's not related to the DT patches. It's
> probably the session bit related issues again..

could be, that part definitely needs some clenaning.

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130425/c462710c/attachment.sig>

From shawn.guo at linaro.org  Thu Apr 25 11:18:35 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Thu, 25 Apr 2013 23:18:35 +0800
Subject: [PATCH v2] ARM: imx: replicate the diagnostic register of boot cpu
 into secondary cores
Message-ID: <1366903115-11195-1-git-send-email-shawn.guo@linaro.org>

The diagnostic register holds the errata bits.  Mostly bootloader
does not bring up secondary cores, so that when errata bits are set
in bootloader, they are set only for boot cpu.  But on a SMP
configuration, it should be equally done on every single core.
Set up the diagnostic register for secondary cores by replicating
the register from boot cpu.

Signed-off-by: Shawn Guo <shawn.guo at linaro.org>
---
Changes since v1:
 * Move get_diag_reg() and set_diag_reg() into IMX file, as Will has
   concern to have it be globally available.

 arch/arm/mach-imx/platsmp.c |   27 +++++++++++++++++++++++++++
 1 file changed, 27 insertions(+)

diff --git a/arch/arm/mach-imx/platsmp.c b/arch/arm/mach-imx/platsmp.c
index 7061bde..b13458f 100644
--- a/arch/arm/mach-imx/platsmp.c
+++ b/arch/arm/mach-imx/platsmp.c
@@ -23,6 +23,7 @@
 #define SCU_STANDBY_ENABLE	(1 << 5)
 
 static void __iomem *scu_base;
+static u32 diag_reg;
 
 static struct map_desc scu_io_desc __initdata = {
 	/* .virtual and .pfn are run-time assigned */
@@ -52,6 +53,19 @@ void imx_scu_standby_enable(void)
 	writel_relaxed(val, scu_base);
 }
 
+static inline unsigned int get_diag_reg(void)
+{
+	unsigned int val;
+	asm("mrc p15, 0, %0, c15, c0, 1" : "=r" (val) : : "cc");
+	return val;
+}
+
+static inline void set_diag_reg(unsigned int val)
+{
+	asm volatile("mcr p15, 0, %0, c15, c0, 1" : : "r" (val) : "cc");
+	isb();
+}
+
 static void __cpuinit imx_secondary_init(unsigned int cpu)
 {
 	/*
@@ -60,6 +74,9 @@ static void __cpuinit imx_secondary_init(unsigned int cpu)
 	 * for us: do so
 	 */
 	gic_secondary_init(0);
+
+	/* Replicate the diagnostic register of boot cpu */
+	set_diag_reg(diag_reg);
 }
 
 static int __cpuinit imx_boot_secondary(unsigned int cpu, struct task_struct *idle)
@@ -91,6 +108,16 @@ void imx_smp_prepare(void)
 static void __init imx_smp_prepare_cpus(unsigned int max_cpus)
 {
 	imx_smp_prepare();
+
+	/*
+	 * The diagnostic register holds the errata bits.  Mostly bootloader
+	 * does not bring up secondary cores, so that when errata bits are set
+	 * in bootloader, they are set only for boot cpu.  But on a SMP
+	 * configuration, it should be equally done on every single core.
+	 * Read the register from boot cpu here, and will replicate it into
+	 * secondary cores when booting them.
+	 */
+	diag_reg = get_diag_reg();
 }
 
 struct smp_operations  imx_smp_ops __initdata = {
-- 
1.7.9.5




From will.deacon at arm.com  Thu Apr 25 11:21:52 2013
From: will.deacon at arm.com (Will Deacon)
Date: Thu, 25 Apr 2013 16:21:52 +0100
Subject: [PATCH v2] ARM: imx: replicate the diagnostic register of boot
 cpu into secondary cores
In-Reply-To: <1366903115-11195-1-git-send-email-shawn.guo@linaro.org>
References: <1366903115-11195-1-git-send-email-shawn.guo@linaro.org>
Message-ID: <20130425152152.GA25671@mudshark.cambridge.arm.com>

Hi Shawn,

On Thu, Apr 25, 2013 at 04:18:35PM +0100, Shawn Guo wrote:
> The diagnostic register holds the errata bits.  Mostly bootloader
> does not bring up secondary cores, so that when errata bits are set
> in bootloader, they are set only for boot cpu.  But on a SMP
> configuration, it should be equally done on every single core.
> Set up the diagnostic register for secondary cores by replicating
> the register from boot cpu.
> 
> Signed-off-by: Shawn Guo <shawn.guo at linaro.org>
> ---
> Changes since v1:
>  * Move get_diag_reg() and set_diag_reg() into IMX file, as Will has
>    concern to have it be globally available.
> 
>  arch/arm/mach-imx/platsmp.c |   27 +++++++++++++++++++++++++++
>  1 file changed, 27 insertions(+)
> 
> diff --git a/arch/arm/mach-imx/platsmp.c b/arch/arm/mach-imx/platsmp.c
> index 7061bde..b13458f 100644
> --- a/arch/arm/mach-imx/platsmp.c
> +++ b/arch/arm/mach-imx/platsmp.c
> @@ -23,6 +23,7 @@
>  #define SCU_STANDBY_ENABLE	(1 << 5)
>  
>  static void __iomem *scu_base;
> +static u32 diag_reg;
>  
>  static struct map_desc scu_io_desc __initdata = {
>  	/* .virtual and .pfn are run-time assigned */
> @@ -52,6 +53,19 @@ void imx_scu_standby_enable(void)
>  	writel_relaxed(val, scu_base);
>  }
>  
> +static inline unsigned int get_diag_reg(void)
> +{
> +	unsigned int val;
> +	asm("mrc p15, 0, %0, c15, c0, 1" : "=r" (val) : : "cc");
> +	return val;
> +}
> +
> +static inline void set_diag_reg(unsigned int val)
> +{
> +	asm volatile("mcr p15, 0, %0, c15, c0, 1" : : "r" (val) : "cc");
> +	isb();
> +}

I'm still against setting this register with the MMU enabled. It is a
CPU-specific, undocumented register so it's hard for me to make a case here,
but the feedback from the hardware guys is that this may have unintended
consequences.

Will


From kgene.kim at samsung.com  Thu Apr 25 11:31:01 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Fri, 26 Apr 2013 00:31:01 +0900
Subject: [PATCH 1/2] ARM: s3c64xx: cpuidle: use init/exit common routine
In-Reply-To: <5178F8E0.6010606@linaro.org>
References: <1366728077-18988-1-git-send-email-daniel.lezcano@linaro.org>
 <5178F8E0.6010606@linaro.org>
Message-ID: <51794C35.6070400@samsung.com>

On 04/25/13 18:35, Daniel Lezcano wrote:
> On 04/23/2013 04:41 PM, Daniel Lezcano wrote:
>> Remove the duplicated code and use the cpuidle common code for initialization.
>>
>> Signed-off-by: Daniel Lezcano<daniel.lezcano at linaro.org>
>> ---
>
> Hi Kim and Ben,
>
> It is the last patch in the series which was not acked-by.
> Rafael is willing to take it in its tree if you ack it.
>
> Are you ok if this patch ?
>
Looks OK to me, please go ahead with my ack if you want:

Acked-by: Kukjin Kim <kgene.kim at samsung.com>

Thanks.

- Kukjin


From kgene.kim at samsung.com  Thu Apr 25 11:33:39 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Fri, 26 Apr 2013 00:33:39 +0900
Subject: Exynos regressions w.r.t. config and debuggability due to
 multiplatform
In-Reply-To: <201304241703.49864.arnd@arndb.de>
References: <CAOesGMgRsa-AvbEZCc1=_ovaZMaG0S-CDok2MDp_zu5yderAYw@mail.gmail.com>
 <201304241703.49864.arnd@arndb.de>
Message-ID: <51794CD3.4080807@samsung.com>

On 04/25/13 00:03, Arnd Bergmann wrote:
> On Wednesday 24 April 2013, Olof Johansson wrote:
>> I think we should hold off on multiplatform for exynos until it works
>> better, i.e. 3.11.
>>
I think, this would be better choice for now if it's not urgent...

- Kukjin


From kgene.kim at samsung.com  Thu Apr 25 11:38:56 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Fri, 26 Apr 2013 00:38:56 +0900
Subject: [GIT PULL] Late Exynos stuff for v3.10
In-Reply-To: <20130424000638.GA9067@quad.lixom.net>
References: <5176B499.1000208@samsung.com> <51770697.7080504@samsung.com>
 <20130424000638.GA9067@quad.lixom.net>
Message-ID: <51794E10.1010205@samsung.com>

On 04/24/13 09:06, Olof Johansson wrote:
> Hi,
>
Hi Olof,

> Can I please ask you to make our life a little easier by telling us what the
> specific problems these patches solve are? What I am looking for is something
> along the lines of:
>
> --
>
> This branch includes some last-minute enablements of DT contents for features
> that are queued for 3.10:
>   - USB PHY drivers on Exynos 5250
>   - MMC (mshc) on Exynos 4x12
>   - XCHI (USB 3.0) on Exynos 5250
>
> It also contains a fix to disable RTC on exynos [because ... you fill in this
> part].
>
> --
>
> It doesn't have to be something super-elaborate, but I'd like it to be sort of
> self-documenting in a way that I don't have to look through the series of
> patches to get an overview of what's in the branch. Of course we'll also do
> that to review the code, but having the description there makes things easier
> for us to tell if we should even be looking at it, etc.
>
>
OK, I see. Let me do it more carefully.

And let me send pull-request again for fix and late dt branch with 
separated branches in a couple of hours not including usb stuff...

Thanks.

- Kukjin


From steve.capper at linaro.org  Thu Apr 25 11:45:36 2013
From: steve.capper at linaro.org (Steve Capper)
Date: Thu, 25 Apr 2013 16:45:36 +0100
Subject: [PATCH] ARM64: mm: Correct show_pte behaviour.
In-Reply-To: <20130425135106.GB7157@localhost.cambridge.arm.com>
References: <1366382971-12682-1-git-send-email-steve.capper@linaro.org>
 <20130425135106.GB7157@localhost.cambridge.arm.com>
Message-ID: <20130425154536.GA20820@linaro.org>

On Thu, Apr 25, 2013 at 02:51:06PM +0100, Catalin Marinas wrote:
> Thanks. Applied.
> 
> -- 
> Catalin

Cheers!
-- 
Steve


From kgene.kim at samsung.com  Thu Apr 25 11:48:46 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Fri, 26 Apr 2013 00:48:46 +0900
Subject: [PATCH v3 00/13] ARM: EXYNOS: Fix Universal C210 support
In-Reply-To: <201304251646.28026.arnd@arndb.de>
References: <1366731994-7478-1-git-send-email-t.figa@samsung.com>
 <201304251646.28026.arnd@arndb.de>
Message-ID: <5179505E.8070200@samsung.com>

On 04/25/13 23:46, Arnd Bergmann wrote:

>> On Universal C210 board, both with and without DT:
>>
>> Tested-by: Tomasz Figa<t.figa at samsung.com>
>
> Reviewed-by: Arnd Bergmann<arnd at arndb.de>
>
> Olof, Kgene, I think we should have this one in 3.10 since it fixes
> a regression. It looks bigger than it really is because I asked Tomasz
> to do small patches rather than a single combined patch.
>
Basically, I have no objection, I think, dt for universal_c210 is not 
urgent in v3.10 though, because non-dt will be still supported...

K-Gene


From robherring2 at gmail.com  Thu Apr 25 11:50:27 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Thu, 25 Apr 2013 10:50:27 -0500
Subject: [PATCH] cpuidle: add maintainer entry
In-Reply-To: <5178D5EF.9090102@linaro.org>
References: <1366810463-17495-1-git-send-email-daniel.lezcano@linaro.org>
 <51781B48.30208@gmail.com> <5178D0EF.3090004@linaro.org>
 <CAKohpo=Ct7WCBSOqmgk8asVyXWa5o+jqpTwaQgxKVm_XNLfnMA@mail.gmail.com>
 <5178D5EF.9090102@linaro.org>
Message-ID: <CAL_Jsq+o1kF2GJNX5a01B9nPcq6uVLbpC-3RirU2uJAZ8C-jUg@mail.gmail.com>

On Thu, Apr 25, 2013 at 2:06 AM, Daniel Lezcano
<daniel.lezcano at linaro.org> wrote:
> On 04/25/2013 08:49 AM, Viresh Kumar wrote:
>> On 25 April 2013 12:15, Daniel Lezcano <daniel.lezcano at linaro.org> wrote:
>>> On 04/24/2013 07:50 PM, Rob Herring wrote:
>>
>>>> Shouldn't MAINTAINERS contain the driver maintainers too?
>>>
>>> It should contains the upstream maintainer for the subsystem, and
>>> optionally a co-maintainer.
>>>
>>> The MAINTAINERS file gives informations about the patch submission path.
>>>
>>> The file's header should contain the maintainer of the driver, so the
>>> submitted patches will go to the subsystem maintainer for upstreaming
>>> and to the driver maintainer for acked-by.
>>>
>>> If you add an entry in MAINTAINERS like:
>>>
>>> ARM/CALXEDA HIGHBANK ARCHITECTURE
>>> M:      Rob Herring <rob.herring at calxeda.com>
>>> L:      linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
>>> S:      Maintained
>>> F:      arch/arm/mach-highbank/
>>> +F:     drivers/cpuidle/cpuidle-calxeda.c
>>>
>>> That will add confusion while we are trying to clarify the situation
>>> with a single entry point for the patches submission. If someone wants
>>> to submit a patch for this driver, it will look at the MAINTAINERS file
>>> and won't know if it should send the patch against arm-soc or linux-pm.
>>
>> I though otherwise. We can add entry in MAINTAINERS for any module.
>> Module can be a framework/architecture or a single driver.
>
> IMO, there are too much drivers for that. It is simpler for someone to
> read the MAINTAINERS file to find the cpuidle drivers goes through
> linux-pm. I think we can trust Rafael to ask for the acked-by from the
> maintainer of the driver before taking the patches.

It not a maintainer's job to solicit acks. It is the submitter's job
to Cc the correct people. The maintainer should only check for
necessary CC/acks and bitch at the submitter if they did not use
get_maintainers.pl.

Perhaps the MAINTAINERS file needs to be distributed to scale better
or we need a way to put the maintainer data into the source and be
usable by get_maintainers.pl.

>> Adding entry for cpuidle driver of a architecture as you wrote for calxeda is
>> wrong as it adds to confusion and so there should be a separate entry for
>> this driver rather than merging it with arch/ entries.
>
> Yes, actually it was an example to show the confusion we could be facing.

I'm confused about what is the confusion...

Rob


From kgene.kim at samsung.com  Thu Apr 25 12:15:47 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Fri, 26 Apr 2013 01:15:47 +0900
Subject: linux-next: manual merge of the arm-soc tree with the pm tree
In-Reply-To: <20130424165417.5e2b74a01728d307e454750f@canb.auug.org.au>
References: <20130424165417.5e2b74a01728d307e454750f@canb.auug.org.au>
Message-ID: <517956B3.2000201@samsung.com>

On 04/24/13 15:54, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the arm-soc tree got a conflict in
> arch/arm/mach-exynos/cpuidle.c between commit 554c06ba3ee2 ("cpuidle:
> remove en_core_tk_irqen flag") from the pm tree and commit 2eb89f893e44
> ("ARM: EXYNOS: factor out the idle states") from the arm-soc tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).

Looks OK to me, thanks.

- Kukjin


From daniel.lezcano at linaro.org  Thu Apr 25 12:32:08 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Thu, 25 Apr 2013 18:32:08 +0200
Subject: [PATCH] cpuidle: add maintainer entry
In-Reply-To: <CAL_Jsq+o1kF2GJNX5a01B9nPcq6uVLbpC-3RirU2uJAZ8C-jUg@mail.gmail.com>
References: <1366810463-17495-1-git-send-email-daniel.lezcano@linaro.org>
 <51781B48.30208@gmail.com> <5178D0EF.3090004@linaro.org>
 <CAKohpo=Ct7WCBSOqmgk8asVyXWa5o+jqpTwaQgxKVm_XNLfnMA@mail.gmail.com>
 <5178D5EF.9090102@linaro.org>
 <CAL_Jsq+o1kF2GJNX5a01B9nPcq6uVLbpC-3RirU2uJAZ8C-jUg@mail.gmail.com>
Message-ID: <51795A88.6020608@linaro.org>

On 04/25/2013 05:50 PM, Rob Herring wrote:
> On Thu, Apr 25, 2013 at 2:06 AM, Daniel Lezcano
> <daniel.lezcano at linaro.org> wrote:
>> On 04/25/2013 08:49 AM, Viresh Kumar wrote:
>>> On 25 April 2013 12:15, Daniel Lezcano <daniel.lezcano at linaro.org> wrote:
>>>> On 04/24/2013 07:50 PM, Rob Herring wrote:
>>>
>>>>> Shouldn't MAINTAINERS contain the driver maintainers too?
>>>>
>>>> It should contains the upstream maintainer for the subsystem, and
>>>> optionally a co-maintainer.
>>>>
>>>> The MAINTAINERS file gives informations about the patch submission path.
>>>>
>>>> The file's header should contain the maintainer of the driver, so the
>>>> submitted patches will go to the subsystem maintainer for upstreaming
>>>> and to the driver maintainer for acked-by.
>>>>
>>>> If you add an entry in MAINTAINERS like:
>>>>
>>>> ARM/CALXEDA HIGHBANK ARCHITECTURE
>>>> M:      Rob Herring <rob.herring at calxeda.com>
>>>> L:      linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
>>>> S:      Maintained
>>>> F:      arch/arm/mach-highbank/
>>>> +F:     drivers/cpuidle/cpuidle-calxeda.c
>>>>
>>>> That will add confusion while we are trying to clarify the situation
>>>> with a single entry point for the patches submission. If someone wants
>>>> to submit a patch for this driver, it will look at the MAINTAINERS file
>>>> and won't know if it should send the patch against arm-soc or linux-pm.
>>>
>>> I though otherwise. We can add entry in MAINTAINERS for any module.
>>> Module can be a framework/architecture or a single driver.
>>
>> IMO, there are too much drivers for that. It is simpler for someone to
>> read the MAINTAINERS file to find the cpuidle drivers goes through
>> linux-pm. I think we can trust Rafael to ask for the acked-by from the
>> maintainer of the driver before taking the patches.
> 
> It not a maintainer's job to solicit acks. It is the submitter's job
> to Cc the correct people. The maintainer should only check for
> necessary CC/acks and bitch at the submitter if they did not use
> get_maintainers.pl.

Ok, I was saying exactly the same, but it was misphrased.
I meant, we can be confident Rafael won't accept patches if they are not
acked by the correct people.

> Perhaps the MAINTAINERS file needs to be distributed to scale better
> or we need a way to put the maintainer data into the source and be
> usable by get_maintainers.pl.

Yep, the latter could be a good idea.

>>> Adding entry for cpuidle driver of a architecture as you wrote for calxeda is
>>> wrong as it adds to confusion and so there should be a separate entry for
>>> this driver rather than merging it with arch/ entries.
>>
>> Yes, actually it was an example to show the confusion we could be facing.
> 
> I'm confused about what is the confusion...



-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From kgene.kim at samsung.com  Thu Apr 25 12:40:02 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Fri, 26 Apr 2013 01:40:02 +0900
Subject: [GIT PULL] Samsung fixes-1 for v3.10
Message-ID: <51795C62.8070500@samsung.com>

The following changes since commit 58a7bbf75442ea439a4d3b7993ad87023e406063:

   ARM: dts: add PDMA0 changes for exynos5440 (2013-04-09 01:39:27 +0900)

are available in the git repository at:

   git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git 
tags/samsung-fixes-1-for-v3.10

for you to fetch changes up to bf49cd7f8d560497cf39065a537f4c722e456cbb:

   ARM: dts: Disable the RTC by default on exynos5 (2013-04-26 01:26:54 
+0900)

----------------------------------------------------------------
Disables the RTC by default on exynos5 to remove lots of warnings in the 
kernel boot log and Fixes build warning on exynos4x12

----------------------------------------------------------------
Doug Anderson (1):
       ARM: dts: Disable the RTC by default on exynos5

Thomas Abraham (1):
       ARM: dts: add mshc controller node for Exynos4x12 SoCs

  arch/arm/boot/dts/exynos4412.dtsi | 8 ++++++++
  arch/arm/boot/dts/exynos5250.dtsi | 1 +
  arch/arm/boot/dts/exynos5440.dtsi | 1 +
  3 files changed, 10 insertions(+)


From kgene.kim at samsung.com  Thu Apr 25 12:42:16 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Fri, 26 Apr 2013 01:42:16 +0900
Subject: [GIT PULL] Late Samsung stuff (v3) for v3.10
Message-ID: <51795CE8.2060105@samsung.com>

The following changes since commit 59a7bbf75442ea439a4d3b7993ad87023e406063:

   ARM: dts: add PDMA0 changes for exynos5440 (2013-04-09 01:39:27 +0900)

are available in the git repository at:

   git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git 
tags/late-exynos-v3-for-v3.10

for you to fetch changes up to 096ee6adcfb79a13ae04150023725c8a67e00ae8:

   ARM: dts: Add chip-id controller node on Exynos4/5 SoC (2013-04-26 
01:21:44 +0900)

----------------------------------------------------------------
This allows that device tree enables platform to setup a runtime IO 
mapping for the chip id

----------------------------------------------------------------
Thomas Abraham (2):
       ARM: EXYNOS: Create virtual I/O mapping for Chip-ID controller 
using device tree
       ARM: dts: Add chip-id controller node on Exynos4/5 SoC

  arch/arm/boot/dts/exynos4.dtsi          |  5 ++++
  arch/arm/boot/dts/exynos5250.dtsi       |  5 ++++
  arch/arm/mach-exynos/common.c           | 53 
+++++++++++++++++++--------------
  arch/arm/mach-exynos/include/mach/map.h |  1 -
  4 files changed, 40 insertions(+), 24 deletions(-)


From kgene.kim at samsung.com  Thu Apr 25 12:48:19 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Fri, 26 Apr 2013 01:48:19 +0900
Subject: [PATCH 07/18] cpufreq: s3c24xx: move cpufreq driver to
 drivers/cpufreq
In-Reply-To: <2264237.NUtkmvZG3W@vostro.rjw.lan>
References: <cover.1365079581.git.viresh.kumar@linaro.org>
 <1769336.FkfMpuXqqb@vostro.rjw.lan> <5176A807.2090005@samsung.com>
 <2264237.NUtkmvZG3W@vostro.rjw.lan>
Message-ID: <51795E53.5030908@samsung.com>

On 04/24/13 07:59, Rafael J. Wysocki wrote:

[...]

>> Rafael, please take this patch with my ack in your tree, sorry for noise.
>>
>> Acked-by: Kukjin Kim<kgene.kim at samsung.com>
>>
>> If any problems, please kindly let me know.
>
> Well, I suppose I can take the original patch, but then it will conflict with
> your tree during merge.  Is that not a problem?
>
I think, some conflicts can be occurred but if so, we can fix it before 
merge window.

- Kukjin


From stefano.stabellini at eu.citrix.com  Thu Apr 25 12:48:56 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Thu, 25 Apr 2013 17:48:56 +0100
Subject: [PATCH v4 2/7] xen/arm: SMP support
In-Reply-To: <1366897221.20256.544.camel@zakaz.uk.xensource.com>
References: <alpine.DEB.2.02.1304242012590.4180@kaball.uk.xensource.com>
 <1366831695-13214-2-git-send-email-stefano.stabellini@eu.citrix.com>
 <1366897221.20256.544.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1304251503100.4180@kaball.uk.xensource.com>

On Thu, 25 Apr 2013, Ian Campbell wrote:
> On Wed, 2013-04-24 at 20:28 +0100, Stefano Stabellini wrote:
> > Map vcpu_info using VCPUOP_register_vcpu_info on secondary cpus.
> > 
> > Call enable_percpu_irq on every cpu.
> > 
> > Changed in v2:
> > - move the percpu variable argument fix to a separate patch;
> > - remove unused variable.
> > 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
> > ---
> >  arch/arm/xen/enlighten.c |   38 +++++++++++++++++++++++++++++++++++++-
> >  1 files changed, 37 insertions(+), 1 deletions(-)
> > 
> > diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> > index 99ce189..94bbf3b 100644
> > --- a/arch/arm/xen/enlighten.c
> > +++ b/arch/arm/xen/enlighten.c
> > @@ -2,6 +2,7 @@
> >  #include <xen/events.h>
> >  #include <xen/grant_table.h>
> >  #include <xen/hvm.h>
> > +#include <xen/interface/vcpu.h>
> >  #include <xen/interface/xen.h>
> >  #include <xen/interface/memory.h>
> >  #include <xen/interface/hvm/params.h>
> > @@ -32,6 +33,7 @@ struct shared_info xen_dummy_shared_info;
> >  struct shared_info *HYPERVISOR_shared_info = (void *)&xen_dummy_shared_info;
> >  
> >  DEFINE_PER_CPU(struct vcpu_info *, xen_vcpu);
> > +DEFINE_PER_CPU(struct vcpu_info, xen_vcpu_info);
> 
> >  /* These are unused until we support booting "pre-ballooned" */
> >  unsigned long xen_released_pages;
> > @@ -148,6 +150,32 @@ int xen_unmap_domain_mfn_range(struct vm_area_struct *vma,
> >  }
> >  EXPORT_SYMBOL_GPL(xen_unmap_domain_mfn_range);
> >  
> > +static int __init xen_secondary_init(unsigned int cpu)
> > +{
> > +	struct vcpu_register_vcpu_info info;
> > +	struct vcpu_info *vcpup;
> > +	int err;
> > +
> > +	if (cpu == 0)
> > +		return 0;
> > +
> > +	pr_info("Xen: initializing cpu%d\n", cpu);
> > +	vcpup = &per_cpu(xen_vcpu_info, cpu);
> > +
> > +	info.mfn = __pa(vcpup) >> PAGE_SHIFT;
> > +	info.offset = offset_in_page(vcpup);
> 
> Do you need to somehow guarantee it's not going to cross a page? Maybe
> standard C alignment rules make that the case?

That is a good question, I don't think that DEFINE_PER_CPU makes any
alignment guarantees (standard C alignment aside).
I'll switch to __alloc_percpu that allows me to specify an alignment and
has the advantage of being dynamically allocated.


> > @@ -216,6 +245,8 @@ static int __init xen_guest_init(void)
> >  	 * is required to use VCPUOP_register_vcpu_info to place vcpu info
> >  	 * for secondary CPUs as they are brought up. */
> >  	per_cpu(xen_vcpu, 0) = &HYPERVISOR_shared_info->vcpu_info[0];
> > +	for_each_online_cpu(i)
> > +		xen_secondary_init(i);
> >  
> >  	gnttab_init();
> >  	if (!xen_initial_domain())
> [...]
> > @@ -244,7 +280,7 @@ static int __init xen_init_events(void)
> >  		return -EINVAL;
> >  	}
> >  
> > -	enable_percpu_irq(xen_events_irq, 0);
> > +	on_each_cpu(xen_percpu_enable_events, NULL, 0);
> 
> It feels like there ought to be some sort of per-cpu bringup callback
> which takes care of these dynamically. Maybe that doesn't matter until
> we get vcpu hotplug going?

I suspect there isn't one, considering that on_each_cpu is also used by 
kvm_vgic_hyp_init, kvm_timer_hyp_init and others.


From stefano.stabellini at eu.citrix.com  Thu Apr 25 12:57:11 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Thu, 25 Apr 2013 17:57:11 +0100
Subject: [PATCH v5 0/7] xen/arm: move to mach-virt and support SMP
Message-ID: <alpine.DEB.2.02.1304251750160.4180@kaball.uk.xensource.com>

Hi all,
this patch series, based on 3.9-rc3, moves xenvm to mach-virt,
introduces SMP support in Xen on ARM and implements machine reboot and
power off via Xen sched_op hypercalls.

Each patch comes with a detailed changelog.


The merge window is approaching, this patch series only contains Xen
specific changes for ARM, if anybody has any objections speak now
please.

I would like an ack from an ARM maintainer on patch #4 and #5 since they
touch generic ARM Makefiles.


Changes in v5:
- allocate xen_vcpu_info dynamically, aligning it to the size of the
struct;
- use VCPUOP_register_vcpu_info on cpu0 too;
- set pm_power_off and arm_pm_restart from the Xen specific
intialization code.



Stefano Stabellini (7):
      xen/arm: actually pass a non-NULL percpu pointer to request_percpu_irq
      xen/arm: implement HYPERVISOR_vcpu_op
      xen/arm: SMP support
      xen: move the xenvm machine to mach-virt
      xen/arm: XEN selects ARM_PSCI
      xenvm: add a simple PSCI node and a second cpu
      xen/arm: use sched_op hypercalls for machine reboot and power off

 arch/arm/Kconfig                     |    1 +
 arch/arm/boot/dts/Makefile           |    4 +-
 arch/arm/boot/dts/xenvm-4.2.dts      |   13 ++++++
 arch/arm/include/asm/xen/hypercall.h |    1 +
 arch/arm/mach-vexpress/v2m.c         |    1 -
 arch/arm/mach-virt/virt.c            |    1 +
 arch/arm/xen/enlighten.c             |   75 ++++++++++++++++++++++++++++++---
 arch/arm/xen/hypercall.S             |    1 +
 8 files changed, 87 insertions(+), 10 deletions(-)


git://git.kernel.org/pub/scm/linux/kernel/git/sstabellini/xen.git 3.9-rc3-smp-5-tag

Cheers,

Stefano


From stefano.stabellini at eu.citrix.com  Thu Apr 25 12:57:49 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Thu, 25 Apr 2013 17:57:49 +0100
Subject: [PATCH v5 1/7] xen/arm: actually pass a non-NULL percpu pointer to
 request_percpu_irq
In-Reply-To: <alpine.DEB.2.02.1304251750160.4180@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1304251750160.4180@kaball.uk.xensource.com>
Message-ID: <1366909075-28775-1-git-send-email-stefano.stabellini@eu.citrix.com>

Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
Reviewed-by: Ian Campbell <ian.camjpbell at citrix.com>
CC: stable at vger.kernel.org
---
 arch/arm/xen/enlighten.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 8dc0605..99ce189 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -239,7 +239,7 @@ static int __init xen_init_events(void)
 	xen_init_IRQ();
 
 	if (request_percpu_irq(xen_events_irq, xen_arm_callback,
-			"events", xen_vcpu)) {
+			"events", &xen_vcpu)) {
 		pr_err("Error requesting IRQ %d\n", xen_events_irq);
 		return -EINVAL;
 	}
-- 
1.7.2.5



From stefano.stabellini at eu.citrix.com  Thu Apr 25 12:57:50 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Thu, 25 Apr 2013 17:57:50 +0100
Subject: [PATCH v5 2/7] xen/arm: implement HYPERVISOR_vcpu_op
In-Reply-To: <alpine.DEB.2.02.1304251750160.4180@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1304251750160.4180@kaball.uk.xensource.com>
Message-ID: <1366909075-28775-2-git-send-email-stefano.stabellini@eu.citrix.com>

Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
Reviewed-by: Ian Campbell <ian.campbell at citrix.com>
---
 arch/arm/include/asm/xen/hypercall.h |    1 +
 arch/arm/xen/enlighten.c             |    1 +
 arch/arm/xen/hypercall.S             |    1 +
 3 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/arm/include/asm/xen/hypercall.h b/arch/arm/include/asm/xen/hypercall.h
index 8a82325..799f42e 100644
--- a/arch/arm/include/asm/xen/hypercall.h
+++ b/arch/arm/include/asm/xen/hypercall.h
@@ -46,6 +46,7 @@ int HYPERVISOR_event_channel_op(int cmd, void *arg);
 unsigned long HYPERVISOR_hvm_op(int op, void *arg);
 int HYPERVISOR_memory_op(unsigned int cmd, void *arg);
 int HYPERVISOR_physdev_op(int cmd, void *arg);
+int HYPERVISOR_vcpu_op(int cmd, int vcpuid, void *extra_args);
 
 static inline void
 MULTI_update_va_mapping(struct multicall_entry *mcl, unsigned long va,
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 99ce189..82d5e63 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -259,4 +259,5 @@ EXPORT_SYMBOL_GPL(HYPERVISOR_sched_op);
 EXPORT_SYMBOL_GPL(HYPERVISOR_hvm_op);
 EXPORT_SYMBOL_GPL(HYPERVISOR_memory_op);
 EXPORT_SYMBOL_GPL(HYPERVISOR_physdev_op);
+EXPORT_SYMBOL_GPL(HYPERVISOR_vcpu_op);
 EXPORT_SYMBOL_GPL(privcmd_call);
diff --git a/arch/arm/xen/hypercall.S b/arch/arm/xen/hypercall.S
index 71f7239..199cb2d 100644
--- a/arch/arm/xen/hypercall.S
+++ b/arch/arm/xen/hypercall.S
@@ -87,6 +87,7 @@ HYPERCALL2(event_channel_op);
 HYPERCALL2(hvm_op);
 HYPERCALL2(memory_op);
 HYPERCALL2(physdev_op);
+HYPERCALL3(vcpu_op);
 
 ENTRY(privcmd_call)
 	stmdb sp!, {r4}
-- 
1.7.2.5



From stefano.stabellini at eu.citrix.com  Thu Apr 25 12:57:54 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Thu, 25 Apr 2013 17:57:54 +0100
Subject: [PATCH v5 6/7] xenvm: add a simple PSCI node and a second cpu
In-Reply-To: <alpine.DEB.2.02.1304251750160.4180@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1304251750160.4180@kaball.uk.xensource.com>
Message-ID: <1366909075-28775-6-git-send-email-stefano.stabellini@eu.citrix.com>

Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
Acked-by: Marc Zyngier <marc.zyngier at arm.com>
CC: rob.herring at calxeda.com
CC: will.deacon at arm.com
CC: arnd at arndb.de
---
 arch/arm/boot/dts/xenvm-4.2.dts |   13 +++++++++++++
 1 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/xenvm-4.2.dts b/arch/arm/boot/dts/xenvm-4.2.dts
index ec3f952..3369151 100644
--- a/arch/arm/boot/dts/xenvm-4.2.dts
+++ b/arch/arm/boot/dts/xenvm-4.2.dts
@@ -29,6 +29,19 @@
 			compatible = "arm,cortex-a15";
 			reg = <0>;
 		};
+
+		cpu at 1 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a15";
+			reg = <1>;
+		};
+	};
+
+	psci {
+		compatible      = "arm,psci";
+		method          = "hvc";
+		cpu_off         = <1>;
+		cpu_on          = <2>;
 	};
 
 	memory at 80000000 {
-- 
1.7.2.5



From stefano.stabellini at eu.citrix.com  Thu Apr 25 12:57:53 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Thu, 25 Apr 2013 17:57:53 +0100
Subject: [PATCH v5 5/7] xen/arm: XEN selects ARM_PSCI
In-Reply-To: <alpine.DEB.2.02.1304251750160.4180@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1304251750160.4180@kaball.uk.xensource.com>
Message-ID: <1366909075-28775-5-git-send-email-stefano.stabellini@eu.citrix.com>

Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
---
 arch/arm/Kconfig |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 2c3bdce..344e299 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1892,6 +1892,7 @@ config XEN
 	depends on ARM && AEABI && OF
 	depends on CPU_V7 && !CPU_V6
 	depends on !GENERIC_ATOMIC64
+	select ARM_PSCI
 	help
 	  Say Y if you want to run Linux in a Virtual Machine on Xen on ARM.
 
-- 
1.7.2.5



From stefano.stabellini at eu.citrix.com  Thu Apr 25 12:57:52 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Thu, 25 Apr 2013 17:57:52 +0100
Subject: [PATCH v5 4/7] xen: move the xenvm machine to mach-virt
In-Reply-To: <alpine.DEB.2.02.1304251750160.4180@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1304251750160.4180@kaball.uk.xensource.com>
Message-ID: <1366909075-28775-4-git-send-email-stefano.stabellini@eu.citrix.com>

xenvm is based on mach-vexpress, move it to mach-virt.

Changes in v4:
- update the dts Makefile too.

Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
CC: Marc Zyngier <marc.zyngier at arm.com>
CC: will.deacon at arm.com
CC: arnd at arndb.de
CC: rob.herring at calxeda.com
---
 arch/arm/boot/dts/Makefile   |    4 ++--
 arch/arm/mach-vexpress/v2m.c |    1 -
 arch/arm/mach-virt/virt.c    |    1 +
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 9c62558..b6289b7 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -168,8 +168,8 @@ dtb-$(CONFIG_ARCH_TEGRA) += tegra20-harmony.dtb \
 dtb-$(CONFIG_ARCH_VEXPRESS) += vexpress-v2p-ca5s.dtb \
 	vexpress-v2p-ca9.dtb \
 	vexpress-v2p-ca15-tc1.dtb \
-	vexpress-v2p-ca15_a7.dtb \
-	xenvm-4.2.dtb
+	vexpress-v2p-ca15_a7.dtb
+dtb-$(CONFIG_ARCH_VIRT) += xenvm-4.2.dtb
 dtb-$(CONFIG_ARCH_VT8500) += vt8500-bv07.dtb \
 	wm8505-ref.dtb \
 	wm8650-mid.dtb \
diff --git a/arch/arm/mach-vexpress/v2m.c b/arch/arm/mach-vexpress/v2m.c
index 915683c..c43ec78 100644
--- a/arch/arm/mach-vexpress/v2m.c
+++ b/arch/arm/mach-vexpress/v2m.c
@@ -469,7 +469,6 @@ static void __init v2m_dt_init(void)
 
 static const char * const v2m_dt_match[] __initconst = {
 	"arm,vexpress",
-	"xen,xenvm",
 	NULL,
 };
 
diff --git a/arch/arm/mach-virt/virt.c b/arch/arm/mach-virt/virt.c
index 31666f6..528c05e 100644
--- a/arch/arm/mach-virt/virt.c
+++ b/arch/arm/mach-virt/virt.c
@@ -40,6 +40,7 @@ static void __init virt_timer_init(void)
 
 static const char *virt_dt_match[] = {
 	"linux,dummy-virt",
+	"xen,xenvm",
 	NULL
 };
 
-- 
1.7.2.5



From stefano.stabellini at eu.citrix.com  Thu Apr 25 12:57:55 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Thu, 25 Apr 2013 17:57:55 +0100
Subject: [PATCH v5 7/7] xen/arm: use sched_op hypercalls for machine reboot
 and power off
In-Reply-To: <alpine.DEB.2.02.1304251750160.4180@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1304251750160.4180@kaball.uk.xensource.com>
Message-ID: <1366909075-28775-7-git-send-email-stefano.stabellini@eu.citrix.com>

Changes in v5:
- set pm_power_off and arm_pm_restart from the Xen specific
intialization code.

Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
---
 arch/arm/xen/enlighten.c |   24 ++++++++++++++++++++++++
 1 files changed, 24 insertions(+), 0 deletions(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 6c87d11..9a0a917 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -10,9 +10,12 @@
 #include <xen/platform_pci.h>
 #include <xen/xenbus.h>
 #include <xen/page.h>
+#include <xen/xen.h>
+#include <xen/interface/sched.h>
 #include <xen/xen-ops.h>
 #include <asm/xen/hypervisor.h>
 #include <asm/xen/hypercall.h>
+#include <asm/system_misc.h>
 #include <linux/interrupt.h>
 #include <linux/irqreturn.h>
 #include <linux/module.h>
@@ -173,6 +176,24 @@ static int __init xen_secondary_init(unsigned int cpu)
 	return 0;
 }
 
+static void xen_restart(char str, const char *cmd)
+{
+	struct sched_shutdown r = { .reason = SHUTDOWN_reboot };
+	int rc;
+	rc = HYPERVISOR_sched_op(SCHEDOP_shutdown, &r);
+	if (rc)
+		BUG();
+}
+
+static void xen_power_off(void)
+{
+	struct sched_shutdown r = { .reason = SHUTDOWN_poweroff };
+	int rc;
+	rc = HYPERVISOR_sched_op(SCHEDOP_shutdown, &r);
+	if (rc)
+		BUG();
+}
+
 /*
  * see Documentation/devicetree/bindings/arm/xen.txt for the
  * documentation of the Xen Device Tree format.
@@ -252,6 +273,9 @@ static int __init xen_guest_init(void)
 	if (!xen_initial_domain())
 		xenbus_probe(NULL);
 
+	pm_power_off = xen_power_off;
+	arm_pm_restart = xen_restart;
+
 	return 0;
 }
 core_initcall(xen_guest_init);
-- 
1.7.2.5



From stefano.stabellini at eu.citrix.com  Thu Apr 25 12:57:51 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Thu, 25 Apr 2013 17:57:51 +0100
Subject: [PATCH v5 3/7] xen/arm: SMP support
In-Reply-To: <alpine.DEB.2.02.1304251750160.4180@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1304251750160.4180@kaball.uk.xensource.com>
Message-ID: <1366909075-28775-3-git-send-email-stefano.stabellini@eu.citrix.com>

Map vcpu_info using VCPUOP_register_vcpu_info on all the online vcpus,
make sure the allocated struct doesn't cross a page boundary.

Call enable_percpu_irq on every cpu.

Changes in v5:
- allocate xen_vcpu_info dynamically, aligning it to the size of the
struct;
- use VCPUOP_register_vcpu_info on cpu0 too.

Changed in v2:
- move the percpu variable argument fix to a separate patch;
- remove unused variable.

Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
---
 arch/arm/xen/enlighten.c |   48 ++++++++++++++++++++++++++++++++++++++++-----
 1 files changed, 42 insertions(+), 6 deletions(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 82d5e63..6c87d11 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -2,6 +2,7 @@
 #include <xen/events.h>
 #include <xen/grant_table.h>
 #include <xen/hvm.h>
+#include <xen/interface/vcpu.h>
 #include <xen/interface/xen.h>
 #include <xen/interface/memory.h>
 #include <xen/interface/hvm/params.h>
@@ -32,6 +33,7 @@ struct shared_info xen_dummy_shared_info;
 struct shared_info *HYPERVISOR_shared_info = (void *)&xen_dummy_shared_info;
 
 DEFINE_PER_CPU(struct vcpu_info *, xen_vcpu);
+static struct vcpu_info __percpu *xen_vcpu_info;
 
 /* These are unused until we support booting "pre-ballooned" */
 unsigned long xen_released_pages;
@@ -148,6 +150,29 @@ int xen_unmap_domain_mfn_range(struct vm_area_struct *vma,
 }
 EXPORT_SYMBOL_GPL(xen_unmap_domain_mfn_range);
 
+static int __init xen_secondary_init(unsigned int cpu)
+{
+	struct vcpu_register_vcpu_info info;
+	struct vcpu_info *vcpup;
+	int err;
+
+	pr_info("Xen: initializing cpu%d\n", cpu);
+	vcpup = per_cpu_ptr(xen_vcpu_info, cpu);
+
+	info.mfn = __pa(vcpup) >> PAGE_SHIFT;
+	info.offset = offset_in_page(vcpup);
+
+	err = HYPERVISOR_vcpu_op(VCPUOP_register_vcpu_info, cpu, &info);
+	if (err) {
+		pr_debug("register_vcpu_info failed: err=%d\n", err);
+	} else {
+		/* This cpu is using the registered vcpu info, even if
+		   later ones fail to. */
+		per_cpu(xen_vcpu, cpu) = vcpup;
+	}
+	return 0;
+}
+
 /*
  * see Documentation/devicetree/bindings/arm/xen.txt for the
  * documentation of the Xen Device Tree format.
@@ -163,6 +188,7 @@ static int __init xen_guest_init(void)
 	const char *version = NULL;
 	const char *xen_prefix = "xen,xen-";
 	struct resource res;
+	int i;
 
 	node = of_find_compatible_node(NULL, NULL, "xen,xen");
 	if (!node) {
@@ -209,13 +235,18 @@ static int __init xen_guest_init(void)
 
 	/* xen_vcpu is a pointer to the vcpu_info struct in the shared_info
 	 * page, we use it in the event channel upcall and in some pvclock
-	 * related functions. We don't need the vcpu_info placement
-	 * optimizations because we don't use any pv_mmu or pv_irq op on
-	 * HVM.
+	 * related functions. 
 	 * The shared info contains exactly 1 CPU (the boot CPU). The guest
 	 * is required to use VCPUOP_register_vcpu_info to place vcpu info
-	 * for secondary CPUs as they are brought up. */
-	per_cpu(xen_vcpu, 0) = &HYPERVISOR_shared_info->vcpu_info[0];
+	 * for secondary CPUs as they are brought up.
+	 * For uniformity we use VCPUOP_register_vcpu_info even on cpu0.
+	 */
+	xen_vcpu_info = __alloc_percpu(sizeof(struct vcpu_info),
+			                       sizeof(struct vcpu_info));
+	if (xen_vcpu_info == NULL)
+		return -ENOMEM;
+	for_each_online_cpu(i)
+		xen_secondary_init(i);
 
 	gnttab_init();
 	if (!xen_initial_domain())
@@ -231,6 +262,11 @@ static irqreturn_t xen_arm_callback(int irq, void *arg)
 	return IRQ_HANDLED;
 }
 
+static __init void xen_percpu_enable_events(void *unused)
+{
+	enable_percpu_irq(xen_events_irq, 0);
+}
+
 static int __init xen_init_events(void)
 {
 	if (!xen_domain() || xen_events_irq < 0)
@@ -244,7 +280,7 @@ static int __init xen_init_events(void)
 		return -EINVAL;
 	}
 
-	enable_percpu_irq(xen_events_irq, 0);
+	on_each_cpu(xen_percpu_enable_events, NULL, 0);
 
 	return 0;
 }
-- 
1.7.2.5



From Ian.Campbell at citrix.com  Thu Apr 25 12:59:44 2013
From: Ian.Campbell at citrix.com (Ian Campbell)
Date: Thu, 25 Apr 2013 17:59:44 +0100
Subject: [PATCH v4 2/7] xen/arm: SMP support
In-Reply-To: <alpine.DEB.2.02.1304251503100.4180@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1304242012590.4180@kaball.uk.xensource.com>
 <1366831695-13214-2-git-send-email-stefano.stabellini@eu.citrix.com>
 <1366897221.20256.544.camel@zakaz.uk.xensource.com>
 <alpine.DEB.2.02.1304251503100.4180@kaball.uk.xensource.com>
Message-ID: <1366909184.3142.0.camel@zakaz.uk.xensource.com>


> > > @@ -216,6 +245,8 @@ static int __init xen_guest_init(void)
> > >  	 * is required to use VCPUOP_register_vcpu_info to place vcpu info
> > >  	 * for secondary CPUs as they are brought up. */
> > >  	per_cpu(xen_vcpu, 0) = &HYPERVISOR_shared_info->vcpu_info[0];
> > > +	for_each_online_cpu(i)
> > > +		xen_secondary_init(i);
> > >  
> > >  	gnttab_init();
> > >  	if (!xen_initial_domain())
> > [...]
> > > @@ -244,7 +280,7 @@ static int __init xen_init_events(void)
> > >  		return -EINVAL;
> > >  	}
> > >  
> > > -	enable_percpu_irq(xen_events_irq, 0);
> > > +	on_each_cpu(xen_percpu_enable_events, NULL, 0);
> > 
> > It feels like there ought to be some sort of per-cpu bringup callback
> > which takes care of these dynamically. Maybe that doesn't matter until
> > we get vcpu hotplug going?
> 
> I suspect there isn't one, considering that on_each_cpu is also used by 
> kvm_vgic_hyp_init, kvm_timer_hyp_init and others.

Could we use cpu_notifiers for this?




From lauraa at codeaurora.org  Thu Apr 25 13:09:57 2013
From: lauraa at codeaurora.org (Laura Abbott)
Date: Thu, 25 Apr 2013 10:09:57 -0700
Subject: [PATCH] of: Set the DMA mask to 64 bits on ARM LPAE systems
In-Reply-To: <20130425133315.GA7157@localhost.cambridge.arm.com>
References: <1366764649-10342-1-git-send-email-lauraa@codeaurora.org>
 <20130425133315.GA7157@localhost.cambridge.arm.com>
Message-ID: <51796365.5030405@codeaurora.org>

On 4/25/2013 6:33 AM, Catalin Marinas wrote:
> On Wed, Apr 24, 2013 at 01:50:49AM +0100, Laura Abbott wrote:
>> By default on ARM systems, the coherent DMA mask (lowest
>> address) is set to ~0 or 0xFFFFFFFFFFFFFFFF. Currently,
>> of_platform_device_create_pdata sets the coherent DMA mask to
>> 32 bits. This prevents coherent dma allocations from working by default
>> without clients setting the DMA mask. Rather than make every client
>> on an LPAE system set the mask, set the mask to a 64 bit value on
>> ARM LPAE systems.
>>
>> Signed-off-by: Laura Abbott <lauraa at codeaurora.org>
>> ---
>>   drivers/of/platform.c |    4 ++++
>>   1 files changed, 4 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/of/platform.c b/drivers/of/platform.c
>> index 0970505..18b69c1 100644
>> --- a/drivers/of/platform.c
>> +++ b/drivers/of/platform.c
>> @@ -214,7 +214,11 @@ struct platform_device *of_platform_device_create_pdata(
>>   #if defined(CONFIG_MICROBLAZE)
>>   	dev->archdata.dma_mask = 0xffffffffUL;
>>   #endif
>> +#ifdef CONFIG_ARM_LPAE
>> +	dev->dev.coherent_dma_mask = DMA_BIT_MASK(64);
>> +#else
>>   	dev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
>> +#endif
>
> I wouldn't add CONFIG_ARM_LPAE checks in here, you can use
> CONFIG_ARCH_DMA_ADDR_T_64BIT (types.h uses this for the dma_addr_t
> definition).
>

I thought about this as well but in arch/arm/mm/mm.h:

#ifdef CONFIG_ZONE_DMA
extern phys_addr_t arm_dma_limit;
#else
#define arm_dma_limit ((phys_addr_t)~0)
#endif

arm_dma_limit is explicitly cast to phys_addr_t, which means that 
arm_dma_limit will be always be sizeof(phys_addr_t) regardless of 
sizeof(dma_addr_t). Is it safe to assume that 
CONFIG_ARCH_DMA_ADDR_T_64BIT will always be selected if 
sizeof(phys_addr_t) == 8? If not, we've defeated the point of the patch.

Alternatively, should the type of arm_dma_limit be dma_addr_t instead of 
phys_addr_t?

Thanks,
Laura

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation


From pawel.moll at arm.com  Thu Apr 25 13:14:51 2013
From: pawel.moll at arm.com (Pawel Moll)
Date: Thu, 25 Apr 2013 18:14:51 +0100
Subject: [PATCH v2] mfd: vexpress: Handle pending config transactions
In-Reply-To: <1366821084-12815-1-git-send-email-pawel.moll@arm.com>
References: <1366821084-12815-1-git-send-email-pawel.moll@arm.com>
Message-ID: <1366910091-17971-1-git-send-email-pawel.moll@arm.com>

The config transactions "scheduler" was hopelessly broken,
repeating completed transaction instead of picking up
next pending one.

Fixed now. Also improved debug messages.

Signed-off-by: Pawel Moll <pawel.moll at arm.com>
---
 drivers/mfd/vexpress-config.c |   35 +++++++++++++++++++++--------------
 1 file changed, 21 insertions(+), 14 deletions(-)

diff --git a/drivers/mfd/vexpress-config.c b/drivers/mfd/vexpress-config.c
index 3c1723aa..84ce6b9 100644
--- a/drivers/mfd/vexpress-config.c
+++ b/drivers/mfd/vexpress-config.c
@@ -184,13 +184,14 @@ static int vexpress_config_schedule(struct vexpress_config_trans *trans)
 
 	spin_lock_irqsave(&bridge->transactions_lock, flags);
 
-	vexpress_config_dump_trans("Executing", trans);
-
-	if (list_empty(&bridge->transactions))
+	if (list_empty(&bridge->transactions)) {
+		vexpress_config_dump_trans("Executing", trans);
 		status = bridge->info->func_exec(trans->func->func,
 				trans->offset, trans->write, trans->data);
-	else
+	} else {
+		vexpress_config_dump_trans("Queuing", trans);
 		status = VEXPRESS_CONFIG_STATUS_WAIT;
+	}
 
 	switch (status) {
 	case VEXPRESS_CONFIG_STATUS_DONE:
@@ -212,25 +213,31 @@ void vexpress_config_complete(struct vexpress_config_bridge *bridge,
 {
 	struct vexpress_config_trans *trans;
 	unsigned long flags;
+	const char *message = "Completed";
 
 	spin_lock_irqsave(&bridge->transactions_lock, flags);
 
 	trans = list_first_entry(&bridge->transactions,
 			struct vexpress_config_trans, list);
-	vexpress_config_dump_trans("Completed", trans);
-
 	trans->status = status;
-	list_del(&trans->list);
 
-	if (!list_empty(&bridge->transactions)) {
-		vexpress_config_dump_trans("Pending", trans);
+	do {
+		vexpress_config_dump_trans(message, trans);
+		list_del(&trans->list);
+		complete(&trans->completion);
 
-		bridge->info->func_exec(trans->func->func, trans->offset,
-				trans->write, trans->data);
-	}
-	spin_unlock_irqrestore(&bridge->transactions_lock, flags);
+		if (list_empty(&bridge->transactions))
+			break;
+
+		trans = list_first_entry(&bridge->transactions,
+				struct vexpress_config_trans, list);
+		vexpress_config_dump_trans("Executing pending", trans);
+		trans->status = bridge->info->func_exec(trans->func->func,
+				trans->offset, trans->write, trans->data);
+		message = "Finished pending";
+	} while (trans->status == VEXPRESS_CONFIG_STATUS_DONE);
 
-	complete(&trans->completion);
+	spin_unlock_irqrestore(&bridge->transactions_lock, flags);
 }
 EXPORT_SYMBOL(vexpress_config_complete);
 
-- 
1.7.10.4




From vincent.guittot at linaro.org  Thu Apr 25 13:23:17 2013
From: vincent.guittot at linaro.org (Vincent Guittot)
Date: Thu, 25 Apr 2013 19:23:17 +0200
Subject: [PATCH 01/14] Revert "sched: Introduce temporary FAIR_GROUP_SCHED
 dependency for load-tracking"
In-Reply-To: <1366910611-20048-1-git-send-email-vincent.guittot@linaro.org>
References: <1366910611-20048-1-git-send-email-vincent.guittot@linaro.org>
Message-ID: <1366910611-20048-2-git-send-email-vincent.guittot@linaro.org>

This reverts commit f4e26b120b9de84cb627bc7361ba43cfdc51341f.

Signed-off-by: Vincent Guittot <vincent.guittot at linaro.org>
---
 include/linux/sched.h |    8 +-------
 kernel/sched/core.c   |    7 +------
 kernel/sched/fair.c   |   13 ++-----------
 kernel/sched/sched.h  |    9 +--------
 4 files changed, 5 insertions(+), 32 deletions(-)

diff --git a/include/linux/sched.h b/include/linux/sched.h
index d35d2b6..16b0d18 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1159,13 +1159,7 @@ struct sched_entity {
 	/* rq "owned" by this entity/group: */
 	struct cfs_rq		*my_q;
 #endif
-
-/*
- * Load-tracking only depends on SMP, FAIR_GROUP_SCHED dependency below may be
- * removed when useful for applications beyond shares distribution (e.g.
- * load-balance).
- */
-#if defined(CONFIG_SMP) && defined(CONFIG_FAIR_GROUP_SCHED)
+#ifdef CONFIG_SMP
 	/* Per-entity load-tracking */
 	struct sched_avg	avg;
 #endif
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 67d0465..c8db984 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -1563,12 +1563,7 @@ static void __sched_fork(struct task_struct *p)
 	p->se.vruntime			= 0;
 	INIT_LIST_HEAD(&p->se.group_node);
 
-/*
- * Load-tracking only depends on SMP, FAIR_GROUP_SCHED dependency below may be
- * removed when useful for applications beyond shares distribution (e.g.
- * load-balance).
- */
-#if defined(CONFIG_SMP) && defined(CONFIG_FAIR_GROUP_SCHED)
+#ifdef CONFIG_SMP
 	p->se.avg.runnable_avg_period = 0;
 	p->se.avg.runnable_avg_sum = 0;
 #endif
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 7a33e59..9c2f726 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -1109,8 +1109,7 @@ static inline void update_cfs_shares(struct cfs_rq *cfs_rq)
 }
 #endif /* CONFIG_FAIR_GROUP_SCHED */
 
-/* Only depends on SMP, FAIR_GROUP_SCHED may be removed when useful in lb */
-#if defined(CONFIG_SMP) && defined(CONFIG_FAIR_GROUP_SCHED)
+#ifdef CONFIG_SMP
 /*
  * We choose a half-life close to 1 scheduling period.
  * Note: The tables below are dependent on this value.
@@ -3394,12 +3393,6 @@ unlock:
 }
 
 /*
- * Load-tracking only depends on SMP, FAIR_GROUP_SCHED dependency below may be
- * removed when useful for applications beyond shares distribution (e.g.
- * load-balance).
- */
-#ifdef CONFIG_FAIR_GROUP_SCHED
-/*
  * Called immediately before a task is migrated to a new cpu; task_cpu(p) and
  * cfs_rq_of(p) references at time of call are still valid and identify the
  * previous cpu.  However, the caller only guarantees p->pi_lock is held; no
@@ -3422,7 +3415,6 @@ migrate_task_rq_fair(struct task_struct *p, int next_cpu)
 		atomic64_add(se->avg.load_avg_contrib, &cfs_rq->removed_load);
 	}
 }
-#endif
 #endif /* CONFIG_SMP */
 
 static unsigned long
@@ -6114,9 +6106,8 @@ const struct sched_class fair_sched_class = {
 
 #ifdef CONFIG_SMP
 	.select_task_rq		= select_task_rq_fair,
-#ifdef CONFIG_FAIR_GROUP_SCHED
 	.migrate_task_rq	= migrate_task_rq_fair,
-#endif
+
 	.rq_online		= rq_online_fair,
 	.rq_offline		= rq_offline_fair,
 
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index cc03cfd..7f36024f 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -227,12 +227,6 @@ struct cfs_rq {
 #endif
 
 #ifdef CONFIG_SMP
-/*
- * Load-tracking only depends on SMP, FAIR_GROUP_SCHED dependency below may be
- * removed when useful for applications beyond shares distribution (e.g.
- * load-balance).
- */
-#ifdef CONFIG_FAIR_GROUP_SCHED
 	/*
 	 * CFS Load tracking
 	 * Under CFS, load is tracked on a per-entity basis and aggregated up.
@@ -242,8 +236,7 @@ struct cfs_rq {
 	u64 runnable_load_avg, blocked_load_avg;
 	atomic64_t decay_counter, removed_load;
 	u64 last_decay;
-#endif /* CONFIG_FAIR_GROUP_SCHED */
-/* These always depend on CONFIG_FAIR_GROUP_SCHED */
+
 #ifdef CONFIG_FAIR_GROUP_SCHED
 	u32 tg_runnable_contrib;
 	u64 tg_load_contrib;
-- 
1.7.9.5



From vincent.guittot at linaro.org  Thu Apr 25 13:23:16 2013
From: vincent.guittot at linaro.org (Vincent Guittot)
Date: Thu, 25 Apr 2013 19:23:16 +0200
Subject: [RFC PATCH v4 00/14] sched: packing small tasks
Message-ID: <1366910611-20048-1-git-send-email-vincent.guittot@linaro.org>

Hi,

This patchset takes advantage of the new per-task load tracking that is
available in the kernel for packing the tasks in as few as possible
CPU/Cluster/Core. It has got 2 packing modes:
-The 1st mode packs the small tasks when the system is not too busy. The main
goal is to reduce the power consumption in the low system load use cases by
minimizing the number of power domain that are enabled but it also keeps the
default behavior which is performance oriented.
-The 2nd mode packs all tasks in as few as possible power domains in order to
improve the power consumption of the system but at the cost of possible
performance decrease because of the increase of the rate of ressources sharing
compared to the default mode.

The packing is done in 3 steps (the last step is only applicable for the
agressive packing mode):

The 1st step looks for the best place to pack tasks in a system according to
its topology and it defines a 1st pack buddy CPU for each CPU if there is one
available. The policy for defining a buddy CPU is that we want to pack at
levels where a group of CPU can be power gated independently from others. To
describe this capability, a new flag SD_SHARE_POWERDOMAIN has been introduced,
that is used to indicate whether the groups of CPUs of a scheduling domain
share their power state. By default, this flag is set in all sched_domain in
order to keep unchanged the current behavior of the scheduler and only ARM
platform clears the SD_SHARE_POWERDOMAIN flag for MC and CPU level.

In a 2nd step, the scheduler checks the load average of a task which wakes up
as well as the load average of the buddy CPU and it can decide to migrate the
light tasks on a not busy buddy. This check is done during the wake up because
small tasks tend to wake up between periodic load balance and asynchronously
to each other which prevents the default mechanism to catch and migrate them
efficiently. A light task is defined by a runnable_avg_sum that is less than
20% of the runnable_avg_period. In fact, the former condition encloses 2 ones:
The average CPU load of the task must be less than 20% and the task must have
been runnable less than 10ms when it woke up last time in order to be
electable for the packing migration. So, a task than runs 1 ms each 5ms will
be considered as a small task but a task that runs 50 ms with a period of
500ms, will not.
Then, the business of the buddy CPU depends of the load average for the rq and
the number of running tasks. A CPU with a load average greater than 50% will
be considered as busy CPU whatever the number of running tasks is and this
threshold will be reduced by the number of running tasks in order to not
increase too much the wake up latency of a task. When the buddy CPU is busy,
the scheduler falls back to default CFS policy.

The 3rd step is only used when the agressive packing mode is enable. In this
case, the CPUs pack their tasks in their buddy until they becomes full. Unlike
the previous step, we can't keep the same buddy so we update it during load
balance. During the periodic load balance, the scheduler computes the activity
of the system thanks the runnable_avg_sum and the cpu_power of all CPUs and
then it defines the CPUs that will be used to handle the current activity. The
selected CPUs will be their own buddy and will participate to the default
load balancing mecanism in order to share the tasks in a fair way, whereas the
not selected CPUs will not, and their buddy will be the last selected CPU.
The behavior can be summarized as: The scheduler defines how many CPUs are
required to handle the current activity, keeps the tasks on these CPUS and
perform normal load balancing (or any evolution of the current load balancer
like the use of runnable load avg from Alex https://lkml.org/lkml/2013/4/1/580)
on this limited number of CPUs . Like the other steps, the CPUs are selected to
minimize the number of power domain that must stay on.

Change since V3:

 - Take into account comments on previous version.
 - Add an agressive packing mode and a knob to select between the various mode

Change since V2:

 - Migrate only a task that wakes up
 - Change the light tasks threshold to 20%
 - Change the loaded CPU threshold to not pull tasks if the current number of
   running tasks is null but the load average is already greater than 50%
 - Fix the algorithm for selecting the buddy CPU.

Change since V1:

Patch 2/6
 - Change the flag name which was not clear. The new name is
   SD_SHARE_POWERDOMAIN.
 - Create an architecture dependent function to tune the sched_domain flags
Patch 3/6
 - Fix issues in the algorithm that looks for the best buddy CPU
 - Use pr_debug instead of pr_info
 - Fix for uniprocessor
Patch 4/6
 - Remove the use of usage_avg_sum which has not been merged
Patch 5/6
 - Change the way the coherency of runnable_avg_sum and runnable_avg_period is
   ensured
Patch 6/6
 - Use the arch dependent function to set/clear SD_SHARE_POWERDOMAIN for ARM
   platform

Previous results for v3:

This series has been tested with hackbench on ARM platform and the results
don't show any performance regression

Hackbench             3.9-rc2  +patches
Mean Time (10 tests): 2.048    2.015
stdev               : 0.047    0.068

Previous results for V2:

This series has been tested with MP3 play back on ARM platform:
TC2 HMP (dual CA-15 and 3xCA-7 cluster).

The measurements have been done on an Ubuntu image during 60 seconds of
playback and the result has been normalized to 100.

              | CA15 | CA7  | total |
-------------------------------------
default       |  81  |   97 | 178   |
pack          |  13  |  100 | 113   |
-------------------------------------

Previous results for V1:

The patch-set has been tested on ARM platforms: quad CA-9 SMP and TC2 HMP
(dual CA-15 and 3xCA-7 cluster). For ARM platform, the results have
demonstrated that it's worth packing small tasks at all topology levels.

The performance tests have been done on both platforms with sysbench. The
results don't show any performance regressions. These results are aligned with
the policy which uses the normal behavior with heavy use cases.

test: sysbench --test=cpu --num-threads=N --max-requests=R run

Results below is the average duration of 3 tests on the quad CA-9.
default is the current scheduler behavior (pack buddy CPU is -1)
pack is the scheduler with the pack mechanism

              | default |  pack   |
-----------------------------------
N=8;  R=200   |  3.1999 |  3.1921 |
N=8;  R=2000  | 31.4939 | 31.4844 |
N=12; R=200   |  3.2043 |  3.2084 |
N=12; R=2000  | 31.4897 | 31.4831 |
N=16; R=200   |  3.1774 |  3.1824 |
N=16; R=2000  | 31.4899 | 31.4897 |
-----------------------------------

The power consumption tests have been done only on TC2 platform which has got
accessible power lines and I have used cyclictest to simulate small tasks. The
tests show some power consumption improvements.

test: cyclictest -t 8 -q -e 1000000 -D 20 & cyclictest -t 8 -q -e 1000000 -D 20

The measurements have been done during 16 seconds and the result has been
normalized to 100

              | CA15 | CA7  | total |
-------------------------------------
default       | 100  |  40  | 140   |
pack          |  <1  |  45  | <46   |
-------------------------------------

The A15 cluster is less power efficient than the A7 cluster but if we assume
that the tasks is well spread on both clusters, we can guest estimate that the
power consumption on a dual cluster of CA7 would have been for a default
kernel:

              | CA7  | CA7  | total |
-------------------------------------
default       |  40  |  40  |  80   |
-------------------------------------

Vincent Guittot (14):
  Revert "sched: Introduce temporary FAIR_GROUP_SCHED dependency for
    load-tracking"
  sched: add a new SD_SHARE_POWERDOMAIN flag for sched_domain
  sched: pack small tasks
  sched: pack the idle load balance
  ARM: sched: clear SD_SHARE_POWERDOMAIN
  sched: add a knob to choose the packing level
  sched: agressively pack at wake/fork/exec
  sched: trig ILB on an idle buddy
  sched: evaluate the activity level of the system
  sched: update the buddy CPU
  sched: filter task pull request
  sched: create a new field with available capacity
  sched: update the cpu_power
  sched: force migration on buddy CPU

 arch/arm/kernel/topology.c       |    9 +
 arch/ia64/include/asm/topology.h |    1 +
 arch/tile/include/asm/topology.h |    1 +
 include/linux/sched.h            |   11 +-
 include/linux/sched/sysctl.h     |    8 +
 include/linux/topology.h         |    4 +
 kernel/sched/core.c              |   14 +-
 kernel/sched/fair.c              |  393 +++++++++++++++++++++++++++++++++++---
 kernel/sched/sched.h             |   15 +-
 kernel/sysctl.c                  |   13 ++
 10 files changed, 423 insertions(+), 46 deletions(-)

-- 
1.7.9.5



From vincent.guittot at linaro.org  Thu Apr 25 13:23:19 2013
From: vincent.guittot at linaro.org (Vincent Guittot)
Date: Thu, 25 Apr 2013 19:23:19 +0200
Subject: [PATCH 03/14] sched: pack small tasks
In-Reply-To: <1366910611-20048-1-git-send-email-vincent.guittot@linaro.org>
References: <1366910611-20048-1-git-send-email-vincent.guittot@linaro.org>
Message-ID: <1366910611-20048-4-git-send-email-vincent.guittot@linaro.org>

During the creation of sched_domain, we define a pack buddy CPU for each CPU
when one is available. We want to pack at all levels where a group of CPUs can
be power gated independently from others.
On a system that can't power gate a group of CPUs independently, the flag is
set at all sched_domain level and the buddy is set to -1. This is the default
behavior.

On a dual clusters / dual cores system which can power gate each core and
cluster independently, the buddy configuration will be :

      | Cluster 0   | Cluster 1   |
      | CPU0 | CPU1 | CPU2 | CPU3 |
-----------------------------------
buddy | CPU0 | CPU0 | CPU0 | CPU2 |

If the cores in a cluster can't be power gated independently, the buddy
configuration becomes:

      | Cluster 0   | Cluster 1   |
      | CPU0 | CPU1 | CPU2 | CPU3 |
-----------------------------------
buddy | CPU0 | CPU1 | CPU0 | CPU0 |

Small tasks tend to slip out of the periodic load balance so the best place
to choose to migrate them is during their wake up. The decision is in O(1) as
we only check again one buddy CPU

Signed-off-by: Vincent Guittot <vincent.guittot at linaro.org>
Reviewed-by: Morten Rasmussen <morten.rasmussen at arm.com>
---
 kernel/sched/core.c  |    1 +
 kernel/sched/fair.c  |  132 ++++++++++++++++++++++++++++++++++++++++++++++++++
 kernel/sched/sched.h |    5 ++
 3 files changed, 138 insertions(+)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 3b9861f..c5ef170 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -5664,6 +5664,7 @@ cpu_attach_domain(struct sched_domain *sd, struct root_domain *rd, int cpu)
 	rcu_assign_pointer(rq->sd, sd);
 	destroy_sched_domains(tmp, cpu);
 
+	update_packing_domain(cpu);
 	update_top_cache_domain(cpu);
 }
 
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 9c2f726..6adc57c 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -160,6 +160,76 @@ void sched_init_granularity(void)
 	update_sysctl();
 }
 
+
+#ifdef CONFIG_SMP
+/*
+ * Save the id of the optimal CPU that should be used to pack small tasks
+ * The value -1 is used when no buddy has been found
+ */
+DEFINE_PER_CPU(int, sd_pack_buddy);
+
+/*
+ * Look for the best buddy CPU that can be used to pack small tasks
+ * We make the assumption that it doesn't wort to pack on CPU that share the
+ * same powerline. We look for the 1st sched_domain without the
+ * SD_SHARE_POWERDOMAIN flag. Then we look for the sched_group with the lowest
+ * power per core based on the assumption that their power efficiency is
+ * better
+ */
+void update_packing_domain(int cpu)
+{
+	struct sched_domain *sd;
+	int id = -1;
+
+	sd = highest_flag_domain(cpu, SD_SHARE_POWERDOMAIN);
+	if (!sd)
+		sd = rcu_dereference_check_sched_domain(cpu_rq(cpu)->sd);
+	else
+		sd = sd->parent;
+
+	while (sd && (sd->flags & SD_LOAD_BALANCE)
+		&& !(sd->flags & SD_SHARE_POWERDOMAIN)) {
+		struct sched_group *sg = sd->groups;
+		struct sched_group *pack = sg;
+		struct sched_group *tmp;
+
+		/*
+		 * The sched_domain of a CPU points on the local sched_group
+		 * and this CPU of this local group is a good candidate
+		 */
+		id = cpu;
+
+		/* loop the sched groups to find the best one */
+		for (tmp = sg->next; tmp != sg; tmp = tmp->next) {
+			if (tmp->sgp->power * pack->group_weight >
+					pack->sgp->power * tmp->group_weight)
+				continue;
+
+			if ((tmp->sgp->power * pack->group_weight ==
+					pack->sgp->power * tmp->group_weight)
+			 && (cpumask_first(sched_group_cpus(tmp)) >= id))
+				continue;
+
+			/* we have found a better group */
+			pack = tmp;
+
+			/* Take the 1st CPU of the new group */
+			id = cpumask_first(sched_group_cpus(pack));
+		}
+
+		/* Look for another CPU than itself */
+		if (id != cpu)
+			break;
+
+		sd = sd->parent;
+	}
+
+	pr_debug("CPU%d packing on CPU%d\n", cpu, id);
+	per_cpu(sd_pack_buddy, cpu) = id;
+}
+
+#endif /* CONFIG_SMP */
+
 #if BITS_PER_LONG == 32
 # define WMULT_CONST	(~0UL)
 #else
@@ -3291,6 +3361,64 @@ done:
 	return target;
 }
 
+static bool is_buddy_busy(int cpu)
+{
+	struct rq *rq = cpu_rq(cpu);
+	u32 sum = rq->avg.runnable_avg_sum;
+	u32 period = rq->avg.runnable_avg_period;
+
+	/*
+	 * If a CPU accesses the runnable_avg_sum and runnable_avg_period
+	 * fields of its buddy CPU while the latter updates it, it can get the
+	 * new version of a field and the old version of the other one. This
+	 * can generate erroneous decisions. We don't want to use a lock
+	 * mechanism for ensuring the coherency because of the overhead in
+	 * this critical path.
+	 * The runnable_avg_period of a runqueue tends to the max value in
+	 * less than 345ms after plugging a CPU, which implies that we could
+	 * use the max value instead of reading runnable_avg_period after
+	 * 345ms. During the starting phase, we must ensure a minimum of
+	 * coherency between the fields. A simple rule is runnable_avg_sum <=
+	 * runnable_avg_period.
+	 */
+	sum = min(sum, period);
+
+	/*
+	 * A busy buddy is a CPU with a high load or a small load with a lot of
+	 * running tasks.
+	 */
+	return (sum > (period / (rq->nr_running + 2)));
+}
+
+static bool is_light_task(struct task_struct *p)
+{
+	/* A light task runs less than 20% in average */
+	return ((p->se.avg.runnable_avg_sum  * 5) <
+			(p->se.avg.runnable_avg_period));
+}
+
+static int check_pack_buddy(int cpu, struct task_struct *p)
+{
+	int buddy = per_cpu(sd_pack_buddy, cpu);
+
+	/* No pack buddy for this CPU */
+	if (buddy == -1)
+		return false;
+
+	/* buddy is not an allowed CPU */
+	if (!cpumask_test_cpu(buddy, tsk_cpus_allowed(p)))
+		return false;
+
+	/*
+	 * If the task is a small one and the buddy is not overloaded,
+	 * we use buddy cpu
+	 */
+	if (!is_light_task(p) || is_buddy_busy(buddy))
+		return false;
+
+	return true;
+}
+
 /*
  * sched_balance_self: balance the current task (running on cpu) in domains
  * that have the 'flag' flag set. In practice, this is SD_BALANCE_FORK and
@@ -3319,6 +3447,10 @@ select_task_rq_fair(struct task_struct *p, int sd_flag, int wake_flags)
 		if (cpumask_test_cpu(cpu, tsk_cpus_allowed(p)))
 			want_affine = 1;
 		new_cpu = prev_cpu;
+
+		/* We pack only at wake up and not new task */
+		if (check_pack_buddy(new_cpu, p))
+			return per_cpu(sd_pack_buddy, new_cpu);
 	}
 
 	rcu_read_lock();
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 7f36024f..96b164d 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -872,6 +872,7 @@ extern const struct sched_class idle_sched_class;
 
 extern void trigger_load_balance(struct rq *rq, int cpu);
 extern void idle_balance(int this_cpu, struct rq *this_rq);
+extern void update_packing_domain(int cpu);
 
 #else	/* CONFIG_SMP */
 
@@ -879,6 +880,10 @@ static inline void idle_balance(int cpu, struct rq *rq)
 {
 }
 
+static inline void update_packing_domain(int cpu)
+{
+}
+
 #endif
 
 extern void sysrq_sched_debug_show(void);
-- 
1.7.9.5



From vincent.guittot at linaro.org  Thu Apr 25 13:23:18 2013
From: vincent.guittot at linaro.org (Vincent Guittot)
Date: Thu, 25 Apr 2013 19:23:18 +0200
Subject: [PATCH 02/14] sched: add a new SD_SHARE_POWERDOMAIN flag for
 sched_domain
In-Reply-To: <1366910611-20048-1-git-send-email-vincent.guittot@linaro.org>
References: <1366910611-20048-1-git-send-email-vincent.guittot@linaro.org>
Message-ID: <1366910611-20048-3-git-send-email-vincent.guittot@linaro.org>

This new flag SD_SHARE_POWERDOMAIN is used to reflect whether groups of CPUs
in a sched_domain level can or not reach a different power state. If groups of
cores can be power gated independently, as an example, the flag should be
cleared at CPU level. This information is used to decide if it's worth packing
some tasks in a group of CPUs in order to power gated the other groups instead
of spreading the tasks. The default behavior of the scheduler is to spread
tasks so the flag is set into all sched_domains.

Signed-off-by: Vincent Guittot <vincent.guittot at linaro.org>
Reviewed-by: Morten Rasmussen <morten.rasmussen at arm.com>
---
 arch/ia64/include/asm/topology.h |    1 +
 arch/tile/include/asm/topology.h |    1 +
 include/linux/sched.h            |    1 +
 include/linux/topology.h         |    4 ++++
 kernel/sched/core.c              |    6 ++++++
 5 files changed, 13 insertions(+)

diff --git a/arch/ia64/include/asm/topology.h b/arch/ia64/include/asm/topology.h
index a2496e4..6d0b617 100644
--- a/arch/ia64/include/asm/topology.h
+++ b/arch/ia64/include/asm/topology.h
@@ -65,6 +65,7 @@ void build_cpu_to_node_map(void);
 				| SD_BALANCE_EXEC	\
 				| SD_BALANCE_FORK	\
 				| SD_WAKE_AFFINE,	\
+				| arch_sd_local_flags(0)\
 	.last_balance		= jiffies,		\
 	.balance_interval	= 1,			\
 	.nr_balance_failed	= 0,			\
diff --git a/arch/tile/include/asm/topology.h b/arch/tile/include/asm/topology.h
index d5e86c9..adc87102 100644
--- a/arch/tile/include/asm/topology.h
+++ b/arch/tile/include/asm/topology.h
@@ -71,6 +71,7 @@ static inline const struct cpumask *cpumask_of_node(int node)
 				| 0*SD_WAKE_AFFINE			\
 				| 0*SD_SHARE_CPUPOWER			\
 				| 0*SD_SHARE_PKG_RESOURCES		\
+				| arch_sd_local_flags(0)		\
 				| 0*SD_SERIALIZE			\
 				,					\
 	.last_balance		= jiffies,				\
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 16b0d18..a82cdeb 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -809,6 +809,7 @@ enum cpu_idle_type {
 #define SD_BALANCE_WAKE		0x0010  /* Balance on wakeup */
 #define SD_WAKE_AFFINE		0x0020	/* Wake task to waking CPU */
 #define SD_SHARE_CPUPOWER	0x0080	/* Domain members share cpu power */
+#define SD_SHARE_POWERDOMAIN	0x0100	/* Domain members share power domain */
 #define SD_SHARE_PKG_RESOURCES	0x0200	/* Domain members share cpu pkg resources */
 #define SD_SERIALIZE		0x0400	/* Only a single load balancing instance */
 #define SD_ASYM_PACKING		0x0800  /* Place busy groups earlier in the domain */
diff --git a/include/linux/topology.h b/include/linux/topology.h
index d3cf0d6..3eab293 100644
--- a/include/linux/topology.h
+++ b/include/linux/topology.h
@@ -99,6 +99,8 @@ int arch_update_cpu_topology(void);
 				| 1*SD_WAKE_AFFINE			\
 				| 1*SD_SHARE_CPUPOWER			\
 				| 1*SD_SHARE_PKG_RESOURCES		\
+				| arch_sd_local_flags(SD_SHARE_CPUPOWER|\
+						SD_SHARE_PKG_RESOURCES) \
 				| 0*SD_SERIALIZE			\
 				| 0*SD_PREFER_SIBLING			\
 				| arch_sd_sibling_asym_packing()	\
@@ -131,6 +133,7 @@ int arch_update_cpu_topology(void);
 				| 1*SD_WAKE_AFFINE			\
 				| 0*SD_SHARE_CPUPOWER			\
 				| 1*SD_SHARE_PKG_RESOURCES		\
+				| arch_sd_local_flags(SD_SHARE_PKG_RESOURCES)\
 				| 0*SD_SERIALIZE			\
 				,					\
 	.last_balance		= jiffies,				\
@@ -161,6 +164,7 @@ int arch_update_cpu_topology(void);
 				| 1*SD_WAKE_AFFINE			\
 				| 0*SD_SHARE_CPUPOWER			\
 				| 0*SD_SHARE_PKG_RESOURCES		\
+				| arch_sd_local_flags(0)		\
 				| 0*SD_SERIALIZE			\
 				| 1*SD_PREFER_SIBLING			\
 				,					\
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index c8db984..3b9861f 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -5940,6 +5940,11 @@ int __weak arch_sd_sibling_asym_packing(void)
        return 0*SD_ASYM_PACKING;
 }
 
+int __weak arch_sd_local_flags(int level)
+{
+	return 1*SD_SHARE_POWERDOMAIN;
+}
+
 /*
  * Initializers for schedule domains
  * Non-inlined to reduce accumulated stack pressure in build_sched_domains()
@@ -6129,6 +6134,7 @@ sd_numa_init(struct sched_domain_topology_level *tl, int cpu)
 					| 0*SD_WAKE_AFFINE
 					| 0*SD_SHARE_CPUPOWER
 					| 0*SD_SHARE_PKG_RESOURCES
+					| 1*SD_SHARE_POWERDOMAIN
 					| 1*SD_SERIALIZE
 					| 0*SD_PREFER_SIBLING
 					| sd_local_flags(level)
-- 
1.7.9.5



From vincent.guittot at linaro.org  Thu Apr 25 13:23:20 2013
From: vincent.guittot at linaro.org (Vincent Guittot)
Date: Thu, 25 Apr 2013 19:23:20 +0200
Subject: [PATCH 04/14] sched: pack the idle load balance
In-Reply-To: <1366910611-20048-1-git-send-email-vincent.guittot@linaro.org>
References: <1366910611-20048-1-git-send-email-vincent.guittot@linaro.org>
Message-ID: <1366910611-20048-5-git-send-email-vincent.guittot@linaro.org>

Look for an idle CPU close to the pack buddy CPU whenever possible.
The goal is to prevent the wake up of a CPU which doesn't share the power
domain of the pack buddy CPU.

Signed-off-by: Vincent Guittot <vincent.guittot at linaro.org>
Reviewed-by: Morten Rasmussen <morten.rasmussen at arm.com>
---
 kernel/sched/fair.c |   19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 6adc57c..a985c98 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -5469,7 +5469,26 @@ static struct {
 
 static inline int find_new_ilb(int call_cpu)
 {
+	struct sched_domain *sd;
 	int ilb = cpumask_first(nohz.idle_cpus_mask);
+	int buddy = per_cpu(sd_pack_buddy, call_cpu);
+
+	/*
+	 * If we have a pack buddy CPU, we try to run load balance on a CPU
+	 * that is close to the buddy.
+	 */
+	if (buddy != -1) {
+		for_each_domain(buddy, sd) {
+			if (sd->flags & SD_SHARE_CPUPOWER)
+				continue;
+
+			ilb = cpumask_first_and(sched_domain_span(sd),
+					nohz.idle_cpus_mask);
+
+			if (ilb < nr_cpu_ids)
+				break;
+		}
+	}
 
 	if (ilb < nr_cpu_ids && idle_cpu(ilb))
 		return ilb;
-- 
1.7.9.5



From vincent.guittot at linaro.org  Thu Apr 25 13:23:21 2013
From: vincent.guittot at linaro.org (Vincent Guittot)
Date: Thu, 25 Apr 2013 19:23:21 +0200
Subject: [PATCH 05/14] ARM: sched: clear SD_SHARE_POWERDOMAIN
In-Reply-To: <1366910611-20048-1-git-send-email-vincent.guittot@linaro.org>
References: <1366910611-20048-1-git-send-email-vincent.guittot@linaro.org>
Message-ID: <1366910611-20048-6-git-send-email-vincent.guittot@linaro.org>

The ARM platforms take advantage of packing small tasks on few cores.
This is true even when the cores of a cluster can't be power gated
independantly. So we clear SD_SHARE_POWERDOMAIN at MC and CPU level.

Signed-off-by: Vincent Guittot <vincent.guittot at linaro.org>
Reviewed-by: Morten Rasmussen <morten.rasmussen at arm.com>
---
 arch/arm/kernel/topology.c |    9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/kernel/topology.c b/arch/arm/kernel/topology.c
index 79282eb..f89a4a2 100644
--- a/arch/arm/kernel/topology.c
+++ b/arch/arm/kernel/topology.c
@@ -201,6 +201,15 @@ static inline void update_cpu_power(unsigned int cpuid, unsigned int mpidr) {}
  */
 struct cputopo_arm cpu_topology[NR_CPUS];
 
+int arch_sd_local_flags(int level)
+{
+	/* Powergate at threading level doesn't make sense */
+	if (level & SD_SHARE_CPUPOWER)
+		return 1*SD_SHARE_POWERDOMAIN;
+
+	return 0*SD_SHARE_POWERDOMAIN;
+}
+
 const struct cpumask *cpu_coregroup_mask(int cpu)
 {
 	return &cpu_topology[cpu].core_sibling;
-- 
1.7.9.5



From vincent.guittot at linaro.org  Thu Apr 25 13:23:22 2013
From: vincent.guittot at linaro.org (Vincent Guittot)
Date: Thu, 25 Apr 2013 19:23:22 +0200
Subject: [PATCH 06/14] sched: add a knob to choose the packing level
In-Reply-To: <1366910611-20048-1-git-send-email-vincent.guittot@linaro.org>
References: <1366910611-20048-1-git-send-email-vincent.guittot@linaro.org>
Message-ID: <1366910611-20048-7-git-send-email-vincent.guittot@linaro.org>

There are 3 packing levels:
- the default one only packs the small tasks when the system is not busy
- the none level doesn't pack anything
- the full level uses as few as possible number of CPUs based on the current
  activity of the system

Signed-off-by: Vincent Guittot <vincent.guittot at linaro.org>
---
 include/linux/sched/sysctl.h |    8 ++++++++
 kernel/sched/fair.c          |   12 ++++++++++++
 kernel/sysctl.c              |   13 +++++++++++++
 3 files changed, 33 insertions(+)

diff --git a/include/linux/sched/sysctl.h b/include/linux/sched/sysctl.h
index bf8086b..b72a8b8 100644
--- a/include/linux/sched/sysctl.h
+++ b/include/linux/sched/sysctl.h
@@ -44,6 +44,14 @@ enum sched_tunable_scaling {
 };
 extern enum sched_tunable_scaling sysctl_sched_tunable_scaling;
 
+enum sched_tunable_packing {
+	SCHED_PACKING_NONE,
+	SCHED_PACKING_DEFAULT,
+	SCHED_PACKING_FULL,
+};
+
+extern enum sched_tunable_packing __read_mostly sysctl_sched_packing_mode;
+
 extern unsigned int sysctl_numa_balancing_scan_delay;
 extern unsigned int sysctl_numa_balancing_scan_period_min;
 extern unsigned int sysctl_numa_balancing_scan_period_max;
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index a985c98..98166aa 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -113,6 +113,18 @@ unsigned int __read_mostly sysctl_sched_shares_window = 10000000UL;
 unsigned int sysctl_sched_cfs_bandwidth_slice = 5000UL;
 #endif
 
+#ifdef CONFIG_SMP
+/*
+ * The packing policy of the scheduler
+ *
+ * Options are:
+ * SCHED_PACKING_NONE - No buddy is used for packing some tasks
+ * SCHED_PACKING_DEFAULT - The small tasks are packed on a not busy CPUs
+ * SCHED_PACKING_FULL - All Tasks are packed in a minimum number of CPUs
+ */
+enum sched_tunable_packing sysctl_sched_packing_mode = SCHED_PACKING_DEFAULT;
+
+#endif
 /*
  * Increase the granularity value when there are more CPUs,
  * because with more CPUs the 'effective latency' as visible
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index afc1dc6..ca22f59 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -265,6 +265,8 @@ static int max_wakeup_granularity_ns = NSEC_PER_SEC;	/* 1 second */
 #ifdef CONFIG_SMP
 static int min_sched_tunable_scaling = SCHED_TUNABLESCALING_NONE;
 static int max_sched_tunable_scaling = SCHED_TUNABLESCALING_END-1;
+static int min_sched_packing_mode = SCHED_PACKING_NONE;
+static int max_sched_packing_mode = SCHED_PACKING_FULL-1;
 #endif /* CONFIG_SMP */
 #endif /* CONFIG_SCHED_DEBUG */
 
@@ -281,6 +283,17 @@ static struct ctl_table kern_table[] = {
 		.mode		= 0644,
 		.proc_handler	= proc_dointvec,
 	},
+#ifdef CONFIG_SMP
+	{
+		.procname	= "sched_packing_mode",
+		.data		= &sysctl_sched_packing_mode,
+		.maxlen		= sizeof(enum sched_tunable_packing),
+		.mode		= 0644,
+		.proc_handler	= proc_dointvec,
+		.extra1		= &min_sched_packing_mode,
+		.extra2		= &max_sched_packing_mode,
+	},
+#endif
 #ifdef CONFIG_SCHED_DEBUG
 	{
 		.procname	= "sched_min_granularity_ns",
-- 
1.7.9.5



From vincent.guittot at linaro.org  Thu Apr 25 13:23:23 2013
From: vincent.guittot at linaro.org (Vincent Guittot)
Date: Thu, 25 Apr 2013 19:23:23 +0200
Subject: [PATCH 07/14] sched: agressively pack at wake/fork/exec
In-Reply-To: <1366910611-20048-1-git-send-email-vincent.guittot@linaro.org>
References: <1366910611-20048-1-git-send-email-vincent.guittot@linaro.org>
Message-ID: <1366910611-20048-8-git-send-email-vincent.guittot@linaro.org>

According to the packing policy, the scheduler can pack tasks at different
step:
-SCHED_PACKING_NONE level: we don't pack any task.
-SCHED_PACKING_DEFAULT: we only pack small tasks at wake up when system is not
busy.
-SCHED_PACKING_FULL: we pack tasks at wake up until a CPU becomes full. During
a fork or a exec, we assume that the new task is a full running one and we
look for an idle CPU close to the buddy CPU.

Signed-off-by: Vincent Guittot <vincent.guittot at linaro.org>
---
 kernel/sched/fair.c |   47 ++++++++++++++++++++++++++++++++++++++++++-----
 1 file changed, 42 insertions(+), 5 deletions(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 98166aa..874f330 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -3259,13 +3259,16 @@ static struct sched_group *
 find_idlest_group(struct sched_domain *sd, struct task_struct *p,
 		  int this_cpu, int load_idx)
 {
-	struct sched_group *idlest = NULL, *group = sd->groups;
+	struct sched_group *idlest = NULL, *group = sd->groups, *buddy = NULL;
 	unsigned long min_load = ULONG_MAX, this_load = 0;
 	int imbalance = 100 + (sd->imbalance_pct-100)/2;
+	int buddy_cpu = per_cpu(sd_pack_buddy, this_cpu);
+	int get_buddy = ((sysctl_sched_packing_mode == SCHED_PACKING_FULL) &&
+		!(sd->flags & SD_SHARE_POWERDOMAIN) && (buddy_cpu != -1));
 
 	do {
 		unsigned long load, avg_load;
-		int local_group;
+		int local_group, buddy_group = 0;
 		int i;
 
 		/* Skip over this group if it has no CPUs allowed */
@@ -3276,6 +3279,11 @@ find_idlest_group(struct sched_domain *sd, struct task_struct *p,
 		local_group = cpumask_test_cpu(this_cpu,
 					       sched_group_cpus(group));
 
+		if (get_buddy) {
+			buddy_group = cpumask_test_cpu(buddy_cpu,
+						sched_group_cpus(group));
+		}
+
 		/* Tally up the load of all CPUs in the group */
 		avg_load = 0;
 
@@ -3287,6 +3295,9 @@ find_idlest_group(struct sched_domain *sd, struct task_struct *p,
 				load = target_load(i, load_idx);
 
 			avg_load += load;
+
+			if ((buddy_group) && idle_cpu(i))
+				buddy = group;
 		}
 
 		/* Adjust by relative CPU power of the group */
@@ -3300,6 +3311,9 @@ find_idlest_group(struct sched_domain *sd, struct task_struct *p,
 		}
 	} while (group = group->next, group != sd->groups);
 
+	if (buddy)
+		return buddy;
+
 	if (!idlest || 100*this_load < imbalance*min_load)
 		return NULL;
 	return idlest;
@@ -3402,6 +3416,21 @@ static bool is_buddy_busy(int cpu)
 	return (sum > (period / (rq->nr_running + 2)));
 }
 
+static bool is_buddy_full(int cpu)
+{
+	struct rq *rq = cpu_rq(cpu);
+	u32 sum = rq->avg.runnable_avg_sum;
+	u32 period = rq->avg.runnable_avg_period;
+
+	sum = min(sum, period);
+
+	/*
+	 * A full buddy is a CPU with a sum greater or equal to period
+	 * We keep a margin of 2.4%
+	 */
+	return (sum * 1024 >= period * 1000);
+}
+
 static bool is_light_task(struct task_struct *p)
 {
 	/* A light task runs less than 20% in average */
@@ -3413,6 +3442,9 @@ static int check_pack_buddy(int cpu, struct task_struct *p)
 {
 	int buddy = per_cpu(sd_pack_buddy, cpu);
 
+	if (sysctl_sched_packing_mode == SCHED_PACKING_NONE)
+		return false;
+
 	/* No pack buddy for this CPU */
 	if (buddy == -1)
 		return false;
@@ -3421,14 +3453,19 @@ static int check_pack_buddy(int cpu, struct task_struct *p)
 	if (!cpumask_test_cpu(buddy, tsk_cpus_allowed(p)))
 		return false;
 
+	/* We agressively pack at wake up */
+	if ((sysctl_sched_packing_mode == SCHED_PACKING_FULL)
+	 && !is_buddy_full(buddy))
+		return true;
 	/*
 	 * If the task is a small one and the buddy is not overloaded,
 	 * we use buddy cpu
 	 */
-	if (!is_light_task(p) || is_buddy_busy(buddy))
-		return false;
+	if (is_light_task(p) && !is_buddy_busy(buddy))
+		return true;
+
+	return false;
 
-	return true;
 }
 
 /*
-- 
1.7.9.5



From vincent.guittot at linaro.org  Thu Apr 25 13:23:24 2013
From: vincent.guittot at linaro.org (Vincent Guittot)
Date: Thu, 25 Apr 2013 19:23:24 +0200
Subject: [PATCH 08/14] sched: trig ILB on an idle buddy
In-Reply-To: <1366910611-20048-1-git-send-email-vincent.guittot@linaro.org>
References: <1366910611-20048-1-git-send-email-vincent.guittot@linaro.org>
Message-ID: <1366910611-20048-9-git-send-email-vincent.guittot@linaro.org>

If the buddy CPU is not full and currently idle, we trigger an Idle Load
Balance to give it the opportunity to pull more tasks.

Signed-off-by: Vincent Guittot <vincent.guittot at linaro.org>
---
 kernel/sched/fair.c |   24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 874f330..954adfd 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -5776,6 +5776,26 @@ end:
 	clear_bit(NOHZ_BALANCE_KICK, nohz_flags(this_cpu));
 }
 
+static int check_nohz_buddy(int cpu)
+{
+	int buddy = per_cpu(sd_pack_buddy, cpu);
+
+	if (sysctl_sched_packing_mode != SCHED_PACKING_FULL)
+		return false;
+
+	/* No pack buddy for this CPU */
+	if (buddy == -1)
+		return false;
+
+	if (is_buddy_full(buddy))
+		return false;
+
+	if (cpumask_test_cpu(buddy, nohz.idle_cpus_mask))
+		return true;
+
+	return false;
+}
+
 /*
  * Current heuristic for kicking the idle load balancer in the presence
  * of an idle cpu is the system.
@@ -5813,6 +5833,10 @@ static inline int nohz_kick_needed(struct rq *rq, int cpu)
 	if (rq->nr_running >= 2)
 		goto need_kick;
 
+	/* the buddy is idle and not busy so we can pack */
+	if (check_nohz_buddy(cpu))
+		goto need_kick;
+
 	rcu_read_lock();
 	for_each_domain(cpu, sd) {
 		struct sched_group *sg = sd->groups;
-- 
1.7.9.5



From vincent.guittot at linaro.org  Thu Apr 25 13:23:25 2013
From: vincent.guittot at linaro.org (Vincent Guittot)
Date: Thu, 25 Apr 2013 19:23:25 +0200
Subject: [PATCH 09/14] sched: evaluate the activity level of the system
In-Reply-To: <1366910611-20048-1-git-send-email-vincent.guittot@linaro.org>
References: <1366910611-20048-1-git-send-email-vincent.guittot@linaro.org>
Message-ID: <1366910611-20048-10-git-send-email-vincent.guittot@linaro.org>

We evaluate the activity level of CPUs, groups and domains in order to define
how many CPUs are required to handle the current activity.

Signed-off-by: Vincent Guittot <vincent.guittot at linaro.org>
---
 kernel/sched/fair.c |   19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 954adfd..234ecdd 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -3465,7 +3465,22 @@ static int check_pack_buddy(int cpu, struct task_struct *p)
 		return true;
 
 	return false;
+}
+
+static int get_cpu_activity(int cpu)
+{
+	struct rq *rq = cpu_rq(cpu);
+	u32 sum = rq->avg.runnable_avg_sum;
+	u32 period = rq->avg.runnable_avg_period;
+
+	sum = min(sum, period);
+
+	if (sum == period) {
+		u32 overload = rq->nr_running > 1 ? 1 : 0;
+		return power_of(cpu) + overload;
+	}
 
+	return (sum * power_of(cpu)) / period;
 }
 
 /*
@@ -4355,6 +4370,7 @@ struct sd_lb_stats {
 	struct sched_group *busiest; /* Busiest group in this sd */
 	struct sched_group *this;  /* Local group in this sd */
 	unsigned long total_load;  /* Total load of all groups in sd */
+	unsigned long total_activity;  /* Total activity of all groups in sd */
 	unsigned long total_pwr;   /*	Total power of all groups in sd */
 	unsigned long avg_load;	   /* Average load across all groups in sd */
 
@@ -4383,6 +4399,7 @@ struct sd_lb_stats {
 struct sg_lb_stats {
 	unsigned long avg_load; /*Avg load across the CPUs of the group */
 	unsigned long group_load; /* Total load over the CPUs of the group */
+	unsigned long group_activity; /* Total activity of the group */
 	unsigned long sum_nr_running; /* Nr tasks running in the group */
 	unsigned long sum_weighted_load; /* Weighted load of group's tasks */
 	unsigned long group_capacity;
@@ -4629,6 +4646,7 @@ static inline void update_sg_lb_stats(struct lb_env *env,
 		}
 
 		sgs->group_load += load;
+		sgs->group_activity += get_cpu_activity(i);
 		sgs->sum_nr_running += nr_running;
 		sgs->sum_weighted_load += weighted_cpuload(i);
 		if (idle_cpu(i))
@@ -4752,6 +4770,7 @@ static inline void update_sd_lb_stats(struct lb_env *env,
 			return;
 
 		sds->total_load += sgs.group_load;
+		sds->total_activity += sgs.group_activity;
 		sds->total_pwr += sg->sgp->power;
 
 		/*
-- 
1.7.9.5



From vincent.guittot at linaro.org  Thu Apr 25 13:23:26 2013
From: vincent.guittot at linaro.org (Vincent Guittot)
Date: Thu, 25 Apr 2013 19:23:26 +0200
Subject: [PATCH 10/14] sched: update the buddy CPU
In-Reply-To: <1366910611-20048-1-git-send-email-vincent.guittot@linaro.org>
References: <1366910611-20048-1-git-send-email-vincent.guittot@linaro.org>
Message-ID: <1366910611-20048-11-git-send-email-vincent.guittot@linaro.org>

Periodically updates the buddy of a CPU according to the current activity of
the system. A CPU is its own buddy if it participates to the packing effort.
Otherwise, it points to a CPU that participates to the packing effort.

Signed-off-by: Vincent Guittot <vincent.guittot at linaro.org>
---
 kernel/sched/fair.c |   91 ++++++++++++++++++++++++++++++++++++++++++++++++---
 1 file changed, 86 insertions(+), 5 deletions(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 234ecdd..28f8ea7 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -174,11 +174,17 @@ void sched_init_granularity(void)
 
 
 #ifdef CONFIG_SMP
+static unsigned long power_of(int cpu)
+{
+	return cpu_rq(cpu)->cpu_power;
+}
+
 /*
  * Save the id of the optimal CPU that should be used to pack small tasks
  * The value -1 is used when no buddy has been found
  */
 DEFINE_PER_CPU(int, sd_pack_buddy);
+DEFINE_PER_CPU(struct sched_domain *, sd_pack_domain);
 
 /*
  * Look for the best buddy CPU that can be used to pack small tasks
@@ -237,6 +243,68 @@ void update_packing_domain(int cpu)
 	}
 
 	pr_debug("CPU%d packing on CPU%d\n", cpu, id);
+	per_cpu(sd_pack_domain, cpu) = sd;
+	per_cpu(sd_pack_buddy, cpu) = id;
+}
+
+void update_packing_buddy(int cpu, int activity)
+{
+	struct sched_domain *sd = per_cpu(sd_pack_domain, cpu);
+	struct sched_group *sg, *pack, *tmp;
+	int id = cpu;
+
+	if (!sd)
+		return;
+
+	/*
+	 * The sched_domain of a CPU points on the local sched_group
+	 * and this CPU of this local group is a good candidate
+	 */
+	pack = sg = sd->groups;
+
+	/* loop the sched groups to find the best one */
+	for (tmp = sg->next; tmp != sg; tmp = tmp->next) {
+		if ((tmp->sgp->power * pack->group_weight) >
+			(pack->sgp->power_available * tmp->group_weight))
+			continue;
+
+		if (((tmp->sgp->power * pack->group_weight) ==
+			 (pack->sgp->power * tmp->group_weight))
+		 && (cpumask_first(sched_group_cpus(tmp)) >= id))
+			continue;
+
+		/* we have found a better group */
+		pack = tmp;
+
+		/* Take the 1st CPU of the new group */
+		id = cpumask_first(sched_group_cpus(pack));
+	}
+
+	if ((cpu == id) || (activity <= power_of(id))) {
+		per_cpu(sd_pack_buddy, cpu) = id;
+		return;
+	}
+
+	for (tmp = pack; activity > 0; tmp = tmp->next) {
+		if (tmp->sgp->power > activity) {
+			id = cpumask_first(sched_group_cpus(tmp));
+			activity -= power_of(id);
+			if (cpu == id)
+				activity = 0;
+			while ((activity > 0) && (id < nr_cpu_ids)) {
+				id = cpumask_next(id, sched_group_cpus(tmp));
+				activity -= power_of(id);
+				if (cpu == id)
+					activity = 0;
+			}
+		} else if (cpumask_test_cpu(cpu, sched_group_cpus(tmp))) {
+			id = cpu;
+			activity = 0;
+		} else {
+			activity -= tmp->sgp->power;
+		}
+	}
+
 	per_cpu(sd_pack_buddy, cpu) = id;
 }
 
@@ -3014,11 +3082,6 @@ static unsigned long target_load(int cpu, int type)
 	return max(rq->cpu_load[type-1], total);
 }
 
-static unsigned long power_of(int cpu)
-{
-	return cpu_rq(cpu)->cpu_power;
-}
-
 static unsigned long cpu_avg_load_per_task(int cpu)
 {
 	struct rq *rq = cpu_rq(cpu);
@@ -4740,6 +4803,22 @@ static bool update_sd_pick_busiest(struct lb_env *env,
 	return false;
 }
 
+static void update_plb_buddy(int cpu, int *balance, struct sd_lb_stats *sds,
+		struct sched_domain *sd)
+{
+	int buddy;
+
+	if (sysctl_sched_packing_mode != SCHED_PACKING_FULL)
+		return;
+
+	/* Update my buddy */
+	if (sd == per_cpu(sd_pack_domain, cpu))
+		update_packing_buddy(cpu, sds->total_activity);
+
+	/* Get my new buddy */
+	buddy = per_cpu(sd_pack_buddy, cpu);
+}
+
 /**
  * update_sd_lb_stats - Update sched_domain's statistics for load balancing.
  * @env: The load balancing environment.
@@ -4807,6 +4886,8 @@ static inline void update_sd_lb_stats(struct lb_env *env,
 
 		sg = sg->next;
 	} while (sg != env->sd->groups);
+
+	update_plb_buddy(env->dst_cpu, balance, sds, env->sd);
 }
 
 /**
-- 
1.7.9.5



From vincent.guittot at linaro.org  Thu Apr 25 13:23:27 2013
From: vincent.guittot at linaro.org (Vincent Guittot)
Date: Thu, 25 Apr 2013 19:23:27 +0200
Subject: [PATCH 11/14] sched: filter task pull request
In-Reply-To: <1366910611-20048-1-git-send-email-vincent.guittot@linaro.org>
References: <1366910611-20048-1-git-send-email-vincent.guittot@linaro.org>
Message-ID: <1366910611-20048-12-git-send-email-vincent.guittot@linaro.org>

Only CPUs that participates to the packing effort can pull tasks on a busiest
group.

Signed-off-by: Vincent Guittot <vincent.guittot at linaro.org>
---
 kernel/sched/fair.c |   14 ++++++++++++--
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 28f8ea7..6f63fb9 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -3494,6 +3494,12 @@ static bool is_buddy_full(int cpu)
 	return (sum * 1024 >= period * 1000);
 }
 
+static bool is_my_buddy(int cpu, int buddy)
+{
+	int my_buddy = per_cpu(sd_pack_buddy, cpu);
+	return (my_buddy == -1) || (buddy == my_buddy);
+}
+
 static bool is_light_task(struct task_struct *p)
 {
 	/* A light task runs less than 20% in average */
@@ -4688,8 +4694,8 @@ static inline void update_sg_lb_stats(struct lb_env *env,
 
 		/* Bias balancing toward cpus of our domain */
 		if (local_group) {
-			if (idle_cpu(i) && !first_idle_cpu &&
-					cpumask_test_cpu(i, sched_group_mask(group))) {
+			if (is_my_buddy(i, i) && idle_cpu(i) && !first_idle_cpu
+			 && cpumask_test_cpu(i, sched_group_mask(group))) {
 				first_idle_cpu = 1;
 				balance_cpu = i;
 			}
@@ -4817,6 +4823,10 @@ static void update_plb_buddy(int cpu, int *balance, struct sd_lb_stats *sds,
 
 	/* Get my new buddy */
 	buddy = per_cpu(sd_pack_buddy, cpu);
+
+	/* This CPU doesn't act for agressive packing */
+	if (buddy != cpu)
+		sds->busiest = 0;
 }
 
 /**
-- 
1.7.9.5



From vincent.guittot at linaro.org  Thu Apr 25 13:23:28 2013
From: vincent.guittot at linaro.org (Vincent Guittot)
Date: Thu, 25 Apr 2013 19:23:28 +0200
Subject: [PATCH 12/14] sched: create a new field with available capacity
In-Reply-To: <1366910611-20048-1-git-send-email-vincent.guittot@linaro.org>
References: <1366910611-20048-1-git-send-email-vincent.guittot@linaro.org>
Message-ID: <1366910611-20048-13-git-send-email-vincent.guittot@linaro.org>

This new field power_available reflects the available capacity of a CPU
unlike the cpu_power which reflects the current capacity.

Signed-off-by: Vincent Guittot <vincent.guittot at linaro.org>
---
 include/linux/sched.h |    2 +-
 kernel/sched/fair.c   |   18 +++++++++++++++---
 kernel/sched/sched.h  |    1 +
 3 files changed, 17 insertions(+), 4 deletions(-)

diff --git a/include/linux/sched.h b/include/linux/sched.h
index a82cdeb..03a5143 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -824,7 +824,7 @@ struct sched_group_power {
 	 * CPU power of this group, SCHED_LOAD_SCALE being max power for a
 	 * single CPU.
 	 */
-	unsigned int power, power_orig;
+	unsigned int power, power_orig, power_available;
 	unsigned long next_update;
 	/*
 	 * Number of busy cpus in this group.
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 6f63fb9..756b1e3 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -179,6 +179,11 @@ static unsigned long power_of(int cpu)
 	return cpu_rq(cpu)->cpu_power;
 }
 
+static unsigned long available_of(int cpu)
+{
+	return cpu_rq(cpu)->cpu_available;
+}
+
 /*
  * Save the id of the optimal CPU that should be used to pack small tasks
  * The value -1 is used when no buddy has been found
@@ -4588,6 +4593,9 @@ static void update_cpu_power(struct sched_domain *sd, int cpu)
 	if (!power)
 		power = 1;
 
+	cpu_rq(cpu)->cpu_available = power;
+	sdg->sgp->power_available = power;
+
 	cpu_rq(cpu)->cpu_power = power;
 	sdg->sgp->power = power;
 }
@@ -4596,7 +4604,7 @@ void update_group_power(struct sched_domain *sd, int cpu)
 {
 	struct sched_domain *child = sd->child;
 	struct sched_group *group, *sdg = sd->groups;
-	unsigned long power;
+	unsigned long power, available;
 	unsigned long interval;
 
 	interval = msecs_to_jiffies(sd->balance_interval);
@@ -4608,7 +4616,7 @@ void update_group_power(struct sched_domain *sd, int cpu)
 		return;
 	}
 
-	power = 0;
+	power = available = 0;
 
 	if (child->flags & SD_OVERLAP) {
 		/*
@@ -4618,6 +4626,8 @@ void update_group_power(struct sched_domain *sd, int cpu)
 
 		for_each_cpu(cpu, sched_group_cpus(sdg))
 			power += power_of(cpu);
+			available += available_of(cpu);
+
 	} else  {
 		/*
 		 * !SD_OVERLAP domains can assume that child groups
@@ -4627,11 +4637,13 @@ void update_group_power(struct sched_domain *sd, int cpu)
 		group = child->groups;
 		do {
 			power += group->sgp->power;
+			available += group->sgp->power_available;
 			group = group->next;
 		} while (group != child->groups);
 	}
 
-	sdg->sgp->power_orig = sdg->sgp->power = power;
+	sdg->sgp->power_orig = sdg->sgp->power_available = available;
+	sdg->sgp->power = power;
 }
 
 /*
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 96b164d..2b6eaf9 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -413,6 +413,7 @@ struct rq {
 	struct sched_domain *sd;
 
 	unsigned long cpu_power;
+	unsigned long cpu_available;
 
 	unsigned char idle_balance;
 	/* For active balancing */
-- 
1.7.9.5



From vincent.guittot at linaro.org  Thu Apr 25 13:23:30 2013
From: vincent.guittot at linaro.org (Vincent Guittot)
Date: Thu, 25 Apr 2013 19:23:30 +0200
Subject: [PATCH 14/14] sched: force migration on buddy CPU
In-Reply-To: <1366910611-20048-1-git-send-email-vincent.guittot@linaro.org>
References: <1366910611-20048-1-git-send-email-vincent.guittot@linaro.org>
Message-ID: <1366910611-20048-15-git-send-email-vincent.guittot@linaro.org>

If a CPU that doesn't participate to the packing effort, has at least one
running task, it means that its group is imbalanced and the CPUs can pull this
task.

Signed-off-by: Vincent Guittot <vincent.guittot at linaro.org>
---
 kernel/sched/fair.c |    3 +++
 1 file changed, 3 insertions(+)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 54c1541..f87aed2 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -4729,6 +4729,9 @@ static inline void update_sg_lb_stats(struct lb_env *env,
 				max_nr_running = nr_running;
 			if (min_nr_running > nr_running)
 				min_nr_running = nr_running;
+
+			if (!is_my_buddy(i, i) && nr_running > 0)
+				sgs->group_imb = 1;
 		}
 
 		sgs->group_load += load;
-- 
1.7.9.5



From vincent.guittot at linaro.org  Thu Apr 25 13:23:29 2013
From: vincent.guittot at linaro.org (Vincent Guittot)
Date: Thu, 25 Apr 2013 19:23:29 +0200
Subject: [PATCH 13/14] sched: update the cpu_power
In-Reply-To: <1366910611-20048-1-git-send-email-vincent.guittot@linaro.org>
References: <1366910611-20048-1-git-send-email-vincent.guittot@linaro.org>
Message-ID: <1366910611-20048-14-git-send-email-vincent.guittot@linaro.org>

The cpu_power is updated for CPUs that don't participate to the packing
effort. We consider that their cpu_power is allocated to idleness as it could
be allocated by rt. So the cpu_power that remains available for cfs, is set to
min value (i.e. 1)

Signed-off-by: Vincent Guittot <vincent.guittot at linaro.org>
---
 kernel/sched/fair.c |   35 ++++++++++++++++++++---------------
 1 file changed, 20 insertions(+), 15 deletions(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 756b1e3..54c1541 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -224,12 +224,12 @@ void update_packing_domain(int cpu)
 
 		/* loop the sched groups to find the best one */
 		for (tmp = sg->next; tmp != sg; tmp = tmp->next) {
-			if (tmp->sgp->power * pack->group_weight >
-					pack->sgp->power * tmp->group_weight)
+			if (tmp->sgp->power_available * pack->group_weight >
+				pack->sgp->power_available * tmp->group_weight)
 				continue;
 
-			if ((tmp->sgp->power * pack->group_weight ==
-					pack->sgp->power * tmp->group_weight)
+			if ((tmp->sgp->power_available * pack->group_weight ==
+				pack->sgp->power_available * tmp->group_weight)
 			 && (cpumask_first(sched_group_cpus(tmp)) >= id))
 				continue;
 
@@ -269,12 +269,12 @@ void update_packing_buddy(int cpu, int activity)
 
 	/* loop the sched groups to find the best one */
 	for (tmp = sg->next; tmp != sg; tmp = tmp->next) {
-		if ((tmp->sgp->power * pack->group_weight) >
+		if ((tmp->sgp->power_available * pack->group_weight) >
 			(pack->sgp->power_available * tmp->group_weight))
 			continue;
 
-		if (((tmp->sgp->power * pack->group_weight) ==
-			 (pack->sgp->power * tmp->group_weight))
+		if (((tmp->sgp->power_available * pack->group_weight) ==
+			 (pack->sgp->power_available * tmp->group_weight))
 		 && (cpumask_first(sched_group_cpus(tmp)) >= id))
 			continue;
 
@@ -285,20 +285,20 @@ void update_packing_buddy(int cpu, int activity)
 		id = cpumask_first(sched_group_cpus(pack));
 	}
 
-	if ((cpu == id) || (activity <= power_of(id))) {
+	if ((cpu == id) || (activity <= available_of(id))) {
 		per_cpu(sd_pack_buddy, cpu) = id;
 		return;
 	}
 
 	for (tmp = pack; activity > 0; tmp = tmp->next) {
-		if (tmp->sgp->power > activity) {
+		if (tmp->sgp->power_available > activity) {
 			id = cpumask_first(sched_group_cpus(tmp));
-			activity -= power_of(id);
+			activity -= available_of(id);
 			if (cpu == id)
 				activity = 0;
 			while ((activity > 0) && (id < nr_cpu_ids)) {
 				id = cpumask_next(id, sched_group_cpus(tmp));
-				activity -= power_of(id);
+				activity -= available_of(id);
 				if (cpu == id)
 					activity = 0;
 			}
@@ -306,7 +306,7 @@ void update_packing_buddy(int cpu, int activity)
 			id = cpu;
 			activity = 0;
 		} else {
-			activity -= tmp->sgp->power;
+			activity -= tmp->sgp->power_available;
 		}
 	}
 
@@ -3369,7 +3369,8 @@ find_idlest_group(struct sched_domain *sd, struct task_struct *p,
 		}
 
 		/* Adjust by relative CPU power of the group */
-		avg_load = (avg_load * SCHED_POWER_SCALE) / group->sgp->power;
+		avg_load = (avg_load * SCHED_POWER_SCALE)
+				/ group->sgp->power_available;
 
 		if (local_group) {
 			this_load = avg_load;
@@ -3551,10 +3552,10 @@ static int get_cpu_activity(int cpu)
 
 	if (sum == period) {
 		u32 overload = rq->nr_running > 1 ? 1 : 0;
-		return power_of(cpu) + overload;
+		return available_of(cpu) + overload;
 	}
 
-	return (sum * power_of(cpu)) / period;
+	return (sum * available_of(cpu)) / period;
 }
 
 /*
@@ -4596,8 +4597,12 @@ static void update_cpu_power(struct sched_domain *sd, int cpu)
 	cpu_rq(cpu)->cpu_available = power;
 	sdg->sgp->power_available = power;
 
+	if (!is_my_buddy(cpu, cpu))
+		power = 1;
+
 	cpu_rq(cpu)->cpu_power = power;
 	sdg->sgp->power = power;
+
 }
 
 void update_group_power(struct sched_domain *sd, int cpu)
-- 
1.7.9.5



From arnd at arndb.de  Thu Apr 25 13:28:47 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 25 Apr 2013 19:28:47 +0200
Subject: [PATCH 04/21] ARM: orion5x: include linux/cpu.h
In-Reply-To: <1366910944-3033663-1-git-send-email-arnd@arndb.de>
References: <1366910944-3033663-1-git-send-email-arnd@arndb.de>
Message-ID: <1366910944-3033663-5-git-send-email-arnd@arndb.de>

The linux/cpu.h header is no longer implictly included in this
file, so we need to an #include statement to avoid this build
warning:

arch/arm/mach-orion5x/common.c:339:3: error: implicit declaration of function 'cpu_idle_poll_ctrl' [-Werror=implicit-function-declaration]

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Cc: Jason Cooper <jason at lakedaemon.net>
Cc: Andrew Lunn <andrew at lunn.ch>
---
 arch/arm/mach-orion5x/common.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-orion5x/common.c b/arch/arm/mach-orion5x/common.c
index 664c97d..b97fd67 100644
--- a/arch/arm/mach-orion5x/common.c
+++ b/arch/arm/mach-orion5x/common.c
@@ -19,6 +19,7 @@
 #include <linux/ata_platform.h>
 #include <linux/delay.h>
 #include <linux/clk-provider.h>
+#include <linux/cpu.h>
 #include <net/dsa.h>
 #include <asm/page.h>
 #include <asm/setup.h>
-- 
1.8.1.2



From arnd at arndb.de  Thu Apr 25 13:28:51 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 25 Apr 2013 19:28:51 +0200
Subject: [PATCH 08/21] drm/nouveau: use mdelay instead of large udelay
 constants
In-Reply-To: <1366910944-3033663-1-git-send-email-arnd@arndb.de>
References: <1366910944-3033663-1-git-send-email-arnd@arndb.de>
Message-ID: <1366910944-3033663-9-git-send-email-arnd@arndb.de>

ARM cannot handle udelay for more than 2 miliseconds, so we
should use mdelay instead for those.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Cc: David Airlie <airlied at linux.ie>
Cc: Ben Skeggs <bskeggs at redhat.com>
Cc: dri-devel at lists.freedesktop.org
---
 drivers/gpu/drm/nouveau/core/engine/disp/dacnv50.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/core/engine/disp/dacnv50.c b/drivers/gpu/drm/nouveau/core/engine/disp/dacnv50.c
index d0817d9..ed7415e 100644
--- a/drivers/gpu/drm/nouveau/core/engine/disp/dacnv50.c
+++ b/drivers/gpu/drm/nouveau/core/engine/disp/dacnv50.c
@@ -51,7 +51,8 @@ nv50_dac_sense(struct nv50_disp_priv *priv, int or, u32 loadval)
 	const u32 doff = (or * 0x800);
 	int load = -EINVAL;
 	nv_wr32(priv, 0x61a00c + doff, 0x00100000 | loadval);
-	udelay(9500);
+	mdelay(9);
+	udelay(500);
 	nv_wr32(priv, 0x61a00c + doff, 0x80000000);
 	load = (nv_rd32(priv, 0x61a00c + doff) & 0x38000000) >> 27;
 	nv_wr32(priv, 0x61a00c + doff, 0x00000000);
-- 
1.8.1.2



From arnd at arndb.de  Thu Apr 25 13:28:52 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 25 Apr 2013 19:28:52 +0200
Subject: [PATCH 09/21] drm: export drm_vm_open_locked
In-Reply-To: <1366910944-3033663-1-git-send-email-arnd@arndb.de>
References: <1366910944-3033663-1-git-send-email-arnd@arndb.de>
Message-ID: <1366910944-3033663-10-git-send-email-arnd@arndb.de>

The EXYNOS DRM driver uses drm_vm_open_locked in its mmap() function,
and it can be built as a loadable module, which currently fails.
This exports the symbol from the DRM core to avoid

ERROR: "drm_vm_open_locked" [drivers/gpu/drm/exynos/exynosdrm.ko] undefined!

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Cc: David Airlie <airlied at linux.ie>
Cc: dri-devel at lists.freedesktop.org
Cc: Inki Dae <inki.dae at samsung.com>
Cc: Joonyoung Shim <jy0922.shim at samsung.com>
Cc: Seung-Woo Kim <sw0312.kim at samsung.com>
Cc: Kyungmin Park <kyungmin.park at samsung.com>
---
 drivers/gpu/drm/drm_vm.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/drm_vm.c b/drivers/gpu/drm/drm_vm.c
index db7bd29..1d4f7c9 100644
--- a/drivers/gpu/drm/drm_vm.c
+++ b/drivers/gpu/drm/drm_vm.c
@@ -422,6 +422,7 @@ void drm_vm_open_locked(struct drm_device *dev,
 		list_add(&vma_entry->head, &dev->vmalist);
 	}
 }
+EXPORT_SYMBOL_GPL(drm_vm_open_locked);
 
 static void drm_vm_open(struct vm_area_struct *vma)
 {
-- 
1.8.1.2



From arnd at arndb.de  Thu Apr 25 13:28:56 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 25 Apr 2013 19:28:56 +0200
Subject: [PATCH 13/21] iommu: tegra: print dma_addr_t using %lld
In-Reply-To: <1366910944-3033663-1-git-send-email-arnd@arndb.de>
References: <1366910944-3033663-1-git-send-email-arnd@arndb.de>
Message-ID: <1366910944-3033663-14-git-send-email-arnd@arndb.de>

The code was recently changed to work for builds with a 64 bit
dma_addr_t, but the printk unconditionally uses a format
string for an "long" variable, which is always wrong as
the dma_add_t is now either 'unsigned int' or 'unsigned long long'
depending on configuration.

The easiest solution is to cast the variable to u64 and print
it as a 64 bit value.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Cc: Varun Sethi <Varun.Sethi at freescale.com>
Cc: Joerg Roedel <joro at 8bytes.org>
---
 drivers/iommu/tegra-gart.c | 3 ++-
 drivers/iommu/tegra-smmu.c | 2 +-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/iommu/tegra-gart.c b/drivers/iommu/tegra-gart.c
index 4aec8be..ebbdd82 100644
--- a/drivers/iommu/tegra-gart.c
+++ b/drivers/iommu/tegra-gart.c
@@ -295,7 +295,8 @@ static phys_addr_t gart_iommu_iova_to_phys(struct iommu_domain *domain,
 
 	pa = (pte & GART_PAGE_MASK);
 	if (!pfn_valid(__phys_to_pfn(pa))) {
-		dev_err(gart->dev, "No entry for %08lx:%08x\n", iova, pa);
+		dev_err(gart->dev, "No entry for %08llx:%pa\n",
+				(u64)iova, &pa);
 		gart_dump_table(gart);
 		return -EINVAL;
 	}
diff --git a/drivers/iommu/tegra-smmu.c b/drivers/iommu/tegra-smmu.c
index bc9b599..ef2a120 100644
--- a/drivers/iommu/tegra-smmu.c
+++ b/drivers/iommu/tegra-smmu.c
@@ -772,7 +772,7 @@ static phys_addr_t smmu_iommu_iova_to_phys(struct iommu_domain *domain,
 	pfn = *pte & SMMU_PFN_MASK;
 	WARN_ON(!pfn_valid(pfn));
 	dev_dbg(as->smmu->dev,
-		"iova:%08lx pfn:%08lx asid:%d\n", iova, pfn, as->asid);
+		"iova:%08llx pfn:%08lx asid:%d\n", (u64)iova, pfn, as->asid);
 
 	spin_unlock_irqrestore(&as->lock, flags);
 	return PFN_PHYS(pfn);
-- 
1.8.1.2



From arnd at arndb.de  Thu Apr 25 13:28:49 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 25 Apr 2013 19:28:49 +0200
Subject: [PATCH 06/21] ALSA: ali5451: use mdelay instead of large udelay
 constants
In-Reply-To: <1366910944-3033663-1-git-send-email-arnd@arndb.de>
References: <1366910944-3033663-1-git-send-email-arnd@arndb.de>
Message-ID: <1366910944-3033663-7-git-send-email-arnd@arndb.de>

ARM cannot handle udelay for more than 2 miliseconds, so we
should use mdelay instead for those.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Cc: Takashi Iwai <tiwai at suse.de>
Cc: alsa-devel at alsa-project.org
---
 sound/pci/ali5451/ali5451.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/sound/pci/ali5451/ali5451.c b/sound/pci/ali5451/ali5451.c
index e760af9..53754f5 100644
--- a/sound/pci/ali5451/ali5451.c
+++ b/sound/pci/ali5451/ali5451.c
@@ -451,10 +451,10 @@ static int snd_ali_reset_5451(struct snd_ali *codec)
 	if (pci_dev) {
 		pci_read_config_dword(pci_dev, 0x7c, &dwVal);
 		pci_write_config_dword(pci_dev, 0x7c, dwVal | 0x08000000);
-		udelay(5000);
+		mdelay(5);
 		pci_read_config_dword(pci_dev, 0x7c, &dwVal);
 		pci_write_config_dword(pci_dev, 0x7c, dwVal & 0xf7ffffff);
-		udelay(5000);
+		mdelay(5);
 	}
 	
 	pci_dev = codec->pci;
@@ -463,14 +463,14 @@ static int snd_ali_reset_5451(struct snd_ali *codec)
 	udelay(500);
 	pci_read_config_dword(pci_dev, 0x44, &dwVal);
 	pci_write_config_dword(pci_dev, 0x44, dwVal & 0xfffbffff);
-	udelay(5000);
+	mdelay(5);
 	
 	wCount = 200;
 	while(wCount--) {
 		wReg = snd_ali_codec_peek(codec, 0, AC97_POWERDOWN);
 		if ((wReg & 0x000f) == 0x000f)
 			return 0;
-		udelay(5000);
+		mdelay(5);
 	}
 
 	/* non-fatal if you have a non PM capable codec */
-- 
1.8.1.2



From arnd at arndb.de  Thu Apr 25 13:28:55 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 25 Apr 2013 19:28:55 +0200
Subject: [PATCH 12/21] irqchip: s3c24xx: add missing __init annotations
In-Reply-To: <1366910944-3033663-1-git-send-email-arnd@arndb.de>
References: <1366910944-3033663-1-git-send-email-arnd@arndb.de>
Message-ID: <1366910944-3033663-13-git-send-email-arnd@arndb.de>

The s3c24xx_init_intc and s3c2412_init_irq functions are only called
at init time, and they call functions already marked __init, so they
should be marked in the same way. This was reported as

WARNING: vmlinux.o(.text+0x19e0b4): Section mismatch in reference from the function s3c2412_init_irq() to the function .init.text:s3c24xx_init_intc.constprop.8()
The function s3c2412_init_irq() references
the function __init s3c24xx_init_intc.constprop.8().
This is often because s3c2412_init_irq lacks a __init
annotation or the annotation of s3c24xx_init_intc.constprop.8 is wrong.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Cc: Heiko Stuebner <heiko at sntech.de>
Cc: Kukjin Kim <kgene.kim at samsung.com>
---
 drivers/irqchip/irq-s3c24xx.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/irqchip/irq-s3c24xx.c b/drivers/irqchip/irq-s3c24xx.c
index c8afd7b..bbcc944 100644
--- a/drivers/irqchip/irq-s3c24xx.c
+++ b/drivers/irqchip/irq-s3c24xx.c
@@ -535,7 +535,7 @@ static void s3c24xx_clear_intc(struct s3c_irq_intc *intc)
 	}
 }
 
-static struct s3c_irq_intc *s3c24xx_init_intc(struct device_node *np,
+static struct s3c_irq_intc * __init s3c24xx_init_intc(struct device_node *np,
 				       struct s3c_irq_data *irq_data,
 				       struct s3c_irq_intc *parent,
 				       unsigned long address)
@@ -795,7 +795,7 @@ static struct s3c_irq_data init_s3c2412subint[32] = {
 	{ .type = S3C_IRQTYPE_LEVEL, .parent_irq = 21 }, /* CF */
 };
 
-void s3c2412_init_irq(void)
+void __init s3c2412_init_irq(void)
 {
 	pr_info("S3C2412: IRQ Support\n");
 
-- 
1.8.1.2



From arnd at arndb.de  Thu Apr 25 13:29:02 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 25 Apr 2013 19:29:02 +0200
Subject: [PATCH 19/21] USB: lpc32xx: ISP1301 needs USB_PHY
In-Reply-To: <1366910944-3033663-1-git-send-email-arnd@arndb.de>
References: <1366910944-3033663-1-git-send-email-arnd@arndb.de>
Message-ID: <1366910944-3033663-20-git-send-email-arnd@arndb.de>

The Kconfig entry for USB_LPC32XX unconditionally selects USB_ISP1301,
which is now only visible when USB_PHY is also enabled.

This adds an appropriate dependency and enables USB_PHY in the msm
defconfig, avoiding these build errors:

warning: (USB_LPC32XX) selects USB_ISP1301 which has unmet direct dependencies (USB_SUPPORT && USB_PHY && (USB || USB_GADGET) && I2C)
drivers/built-in.o: In function `usb_hcd_nxp_probe':
drivers/usb/host/ohci-nxp.c:224: undefined reference to `isp1301_get_client'
drivers/built-in.o: In function `lpc32xx_udc_probe':
drivers/usb/gadget/lpc32xx_udc.c:3071: undefined reference to `isp1301_get_client'

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Cc: linux-usb at vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
Cc: Felipe Balbi <balbi at ti.com>
Cc: Roland Stigge <stigge at antcom.de>
---
 arch/arm/configs/lpc32xx_defconfig | 1 +
 drivers/usb/gadget/Kconfig         | 1 +
 2 files changed, 2 insertions(+)

diff --git a/arch/arm/configs/lpc32xx_defconfig b/arch/arm/configs/lpc32xx_defconfig
index 8fee514..398a367 100644
--- a/arch/arm/configs/lpc32xx_defconfig
+++ b/arch/arm/configs/lpc32xx_defconfig
@@ -146,6 +146,7 @@ CONFIG_SND_DEBUG_VERBOSE=y
 # CONFIG_SND_SPI is not set
 CONFIG_SND_SOC=y
 CONFIG_USB=y
+CONFIG_USB_PHY=y
 CONFIG_USB_OHCI_HCD=y
 CONFIG_USB_STORAGE=y
 CONFIG_USB_GADGET=y
diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
index a61d981..f85b427 100644
--- a/drivers/usb/gadget/Kconfig
+++ b/drivers/usb/gadget/Kconfig
@@ -144,6 +144,7 @@ config USB_AT91
 config USB_LPC32XX
 	tristate "LPC32XX USB Peripheral Controller"
 	depends on ARCH_LPC32XX
+	depends on USB_PHY
 	select USB_ISP1301
 	select USB_OTG_UTILS
 	help
-- 
1.8.1.2



From arnd at arndb.de  Thu Apr 25 13:28:57 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 25 Apr 2013 19:28:57 +0200
Subject: [PATCH 14/21] cpufreq: pxa2xx: initialize variables
In-Reply-To: <1366910944-3033663-1-git-send-email-arnd@arndb.de>
References: <1366910944-3033663-1-git-send-email-arnd@arndb.de>
Message-ID: <1366910944-3033663-15-git-send-email-arnd@arndb.de>

gcc-3.8 correctly found that the variables set by find_freq_tables()
are not initialized if this function is called on something other
than a pxa2xx or pxa3xx:

pxa2xx-cpufreq.c: In function 'pxa_verify_policy':
pxa2xx-cpufreq.c:272:6: warning: 'pxa_freqs_table' may be used uninitialized in this function [-Wmaybe-uninitialized]
pxa2xx-cpufreq.c: In function 'pxa_set_target':
pxa2xx-cpufreq.c:345:23: warning: 'pxa_freq_settings' may be used uninitialized in this function [-Wmaybe-uninitialized]

Rather than adding a bogus initialization that would let us
get a little further before crashing, add an explicit BUG().
We know that this code is designed to run on only these cpus,
so this will fix the build warning and give a more helpful
diagnostic if the code ever changes to run on other machines.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Cc: Viresh Kumar <viresh.kumar at linaro.org>
Cc: Rafael J. Wysocki <rafael.j.wysocki at intel.com>
---
 drivers/cpufreq/pxa2xx-cpufreq.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/cpufreq/pxa2xx-cpufreq.c b/drivers/cpufreq/pxa2xx-cpufreq.c
index fe4c55b..9e5bc8e 100644
--- a/drivers/cpufreq/pxa2xx-cpufreq.c
+++ b/drivers/cpufreq/pxa2xx-cpufreq.c
@@ -221,10 +221,11 @@ static void find_freq_tables(struct cpufreq_frequency_table **freq_table,
 			*pxa_freqs = pxa255_turbo_freqs;
 			*freq_table = pxa255_turbo_freq_table;
 		}
-	}
-	if (cpu_is_pxa27x()) {
+	} else if (cpu_is_pxa27x()) {
 		*pxa_freqs = pxa27x_freqs;
 		*freq_table = pxa27x_freq_table;
+	} else {
+		BUG();
 	}
 }
 
-- 
1.8.1.2



From arnd at arndb.de  Thu Apr 25 13:29:03 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 25 Apr 2013 19:29:03 +0200
Subject: [PATCH 20/21] USB: OMAP: ISP1301 needs USB_PHY
In-Reply-To: <1366910944-3033663-1-git-send-email-arnd@arndb.de>
References: <1366910944-3033663-1-git-send-email-arnd@arndb.de>
Message-ID: <1366910944-3033663-21-git-send-email-arnd@arndb.de>

The Kconfig entry for USB_OMAP unconditionally selects USB_ISP1301,
which is now only visible when USB_PHY is also enabled.

This adds an appropriate dependency and enables USB_PHY in the omap1
defconfig, avoiding these build warnings:

warning: (USB_OHCI_HCD && USB_OMAP) selects ISP1301_OMAP which has unmet direct dependencies (USB_SUPPORT && USB_PHY && I2C && ARCH_OMAP_OTG)

Also fix a Makefile typo while we're at it.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Cc: linux-usb at vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
Cc: Felipe Balbi <balbi at ti.com>
---
 arch/arm/configs/omap1_defconfig | 1 +
 drivers/usb/gadget/Kconfig       | 1 +
 drivers/usb/phy/Makefile         | 2 +-
 3 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm/configs/omap1_defconfig b/arch/arm/configs/omap1_defconfig
index 2280d9d..a1ee534 100644
--- a/arch/arm/configs/omap1_defconfig
+++ b/arch/arm/configs/omap1_defconfig
@@ -196,6 +196,7 @@ CONFIG_SND_SOC=y
 CONFIG_SND_OMAP_SOC=y
 # CONFIG_USB_HID is not set
 CONFIG_USB=y
+CONFIG_USB_PHY=y
 CONFIG_USB_DEBUG=y
 CONFIG_USB_DEVICEFS=y
 # CONFIG_USB_DEVICE_CLASS is not set
diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
index f85b427..83300d9 100644
--- a/drivers/usb/gadget/Kconfig
+++ b/drivers/usb/gadget/Kconfig
@@ -196,6 +196,7 @@ config USB_FUSB300
 config USB_OMAP
 	tristate "OMAP USB Device Controller"
 	depends on ARCH_OMAP1
+	depends on USB_PHY
 	select ISP1301_OMAP if MACH_OMAP_H2 || MACH_OMAP_H3 || MACH_OMAP_H4_OTG
 	help
 	   Many Texas Instruments OMAP processors have flexible full
diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
index 33863c0..a9169cb 100644
--- a/drivers/usb/phy/Makefile
+++ b/drivers/usb/phy/Makefile
@@ -11,7 +11,7 @@ obj-$(CONFIG_USB_PHY)			+= phy.o
 obj-$(CONFIG_AB8500_USB)		+= phy-ab8500-usb.o
 phy-fsl-usb2-objs			:= phy-fsl-usb.o phy-fsm-usb.o
 obj-$(CONFIG_FSL_USB2_OTG)		+= phy-fsl-usb2.o
-obj-$(CONFIG_ISP1301_OMAP)		+= phy-isp1301.omap.o
+obj-$(CONFIG_ISP1301_OMAP)		+= phy-isp1301-omap.o
 obj-$(CONFIG_MV_U3D_PHY)		+= phy-mv-u3d-usb.o
 obj-$(CONFIG_NOP_USB_XCEIV)		+= phy-nop.o
 obj-$(CONFIG_OMAP_CONTROL_USB)		+= phy-omap-control.o
-- 
1.8.1.2



From arnd at arndb.de  Thu Apr 25 13:28:58 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 25 Apr 2013 19:28:58 +0200
Subject: [PATCH 15/21] thermal: cooling: avoid uninitialied used gcc warning
In-Reply-To: <1366910944-3033663-1-git-send-email-arnd@arndb.de>
References: <1366910944-3033663-1-git-send-email-arnd@arndb.de>
Message-ID: <1366910944-3033663-16-git-send-email-arnd@arndb.de>

The newly rewritten get_property() function causes a bogus warning
from gcc-3.8, which cannot figure out that "level" is always
initialized at the point where it gets evaluated:

drivers/thermal/cpu_cooling.c: In function 'get_property':
drivers/thermal/cpu_cooling.c:189:37: warning: 'level' may be used uninitialized in this function [-Wmaybe-uninitialized]
   if (property == GET_FREQ && level == j) {
                                     ^

Slightly rearranging the code makes this more obvious and
avoids the warning.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Cc: Zhang Rui <rui.zhang at intel.com>
Cc: Amit Daniel kachhap <amit.daniel at samsung.com>
---
 drivers/thermal/cpu_cooling.c | 17 +++++++++--------
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
index 768b508..34878e6 100644
--- a/drivers/thermal/cpu_cooling.c
+++ b/drivers/thermal/cpu_cooling.c
@@ -165,10 +165,6 @@ static int get_property(unsigned int cpu, unsigned long input,
 		return 0;
 	}
 
-	if (property == GET_FREQ)
-		level = descend ? input : (max_level - input -1);
-
-
 	for (i = 0, j = 0; table[i].frequency != CPUFREQ_TABLE_END; i++) {
 		/* ignore invalid entry */
 		if (table[i].frequency == CPUFREQ_ENTRY_INVALID)
@@ -186,10 +182,15 @@ static int get_property(unsigned int cpu, unsigned long input,
 			*output = descend ? j : (max_level - j - 1);
 			return 0;
 		}
-		if (property == GET_FREQ && level == j) {
-			/* get frequency by level */
-			*output = freq;
-			return 0;
+
+		if (property == GET_FREQ) {
+			level = descend ? input : (max_level - input -1);
+
+			if (level == j) {
+				/* get frequency by level */
+				*output = freq;
+				return 0;
+			}
 		}
 		j++;
 	}
-- 
1.8.1.2



From arnd at arndb.de  Thu Apr 25 13:28:59 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 25 Apr 2013 19:28:59 +0200
Subject: [PATCH 16/21] OF: remove #ifdef from linux/of_platform.h
In-Reply-To: <1366910944-3033663-1-git-send-email-arnd@arndb.de>
References: <1366910944-3033663-1-git-send-email-arnd@arndb.de>
Message-ID: <1366910944-3033663-17-git-send-email-arnd@arndb.de>

A lot of code uses the functions from of_platform.h when built for
devicetree-enabled platforms but can also be built without them.
In order to avoid using #ifdef everywhere in drivers, this
makes all the function declarations visible, which means we
can use "if (IS_ENABLED(CONFIG_OF))" in driver code and get build
coverage over the code but let the compiler drop the reference
in the object code.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Cc: Grant Likely <grant.likely at linaro.org>
Cc: Rob Herring <rob.herring at calxeda.com>
---
 include/linux/of_platform.h | 13 +++----------
 1 file changed, 3 insertions(+), 10 deletions(-)

diff --git a/include/linux/of_platform.h b/include/linux/of_platform.h
index 2a93b64..ff83462 100644
--- a/include/linux/of_platform.h
+++ b/include/linux/of_platform.h
@@ -14,7 +14,6 @@
 #include <linux/device.h>
 #include <linux/mod_devicetable.h>
 
-#ifdef CONFIG_OF_DEVICE
 #include <linux/pm.h>
 #include <linux/of_device.h>
 #include <linux/platform_device.h>
@@ -82,7 +81,6 @@ extern struct platform_device *of_device_alloc(struct device_node *np,
 					 struct device *parent);
 extern struct platform_device *of_find_device_by_node(struct device_node *np);
 
-#ifdef CONFIG_OF_ADDRESS /* device reg helpers depend on OF_ADDRESS */
 /* Platform devices and busses creation */
 extern struct platform_device *of_platform_device_create(struct device_node *np,
 						   const char *bus_id,
@@ -91,17 +89,12 @@ extern struct platform_device *of_platform_device_create(struct device_node *np,
 extern int of_platform_bus_probe(struct device_node *root,
 				 const struct of_device_id *matches,
 				 struct device *parent);
+#ifdef CONFIG_OF_ADDRESS
 extern int of_platform_populate(struct device_node *root,
 				const struct of_device_id *matches,
 				const struct of_dev_auxdata *lookup,
 				struct device *parent);
-#endif /* CONFIG_OF_ADDRESS */
-
-#endif /* CONFIG_OF_DEVICE */
-
-#if !defined(CONFIG_OF_ADDRESS)
-struct of_dev_auxdata;
-struct device_node;
+#else
 static inline int of_platform_populate(struct device_node *root,
 					const struct of_device_id *matches,
 					const struct of_dev_auxdata *lookup,
@@ -109,6 +102,6 @@ static inline int of_platform_populate(struct device_node *root,
 {
 	return -ENODEV;
 }
-#endif /* !CONFIG_OF_ADDRESS */
+#endif
 
 #endif	/* _LINUX_OF_PLATFORM_H */
-- 
1.8.1.2



From arnd at arndb.de  Thu Apr 25 13:29:00 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 25 Apr 2013 19:29:00 +0200
Subject: [PATCH 17/21] X.509: do not emit any informational output
In-Reply-To: <1366910944-3033663-1-git-send-email-arnd@arndb.de>
References: <1366910944-3033663-1-git-send-email-arnd@arndb.de>
Message-ID: <1366910944-3033663-18-git-send-email-arnd@arndb.de>

When building a kernel using 'make -s', I expect to see an empty output,
except for build warnings and errors. The build_OID_registry code
always prints one line when run, which is not helpful to most people
building the kernels, and which makes it harder to automatically
check for build warnings.

Let's just remove the one line output.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Cc: David Howells <dhowells at redhat.com>
Cc: Rusty Russell <rusty at rustcorp.com.au>
---
 lib/build_OID_registry | 2 --
 1 file changed, 2 deletions(-)

diff --git a/lib/build_OID_registry b/lib/build_OID_registry
index dfbdaab..5d98272 100755
--- a/lib/build_OID_registry
+++ b/lib/build_OID_registry
@@ -50,8 +50,6 @@ my @indices = ();
 my @lengths = ();
 my $total_length = 0;
 
-print "Compiling ", $#names + 1, " OIDs\n";
-
 for (my $i = 0; $i <= $#names; $i++) {
     my $name = $names[$i];
     my $oid = $oids[$i];
-- 
1.8.1.2



From arnd at arndb.de  Thu Apr 25 13:29:04 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 25 Apr 2013 19:29:04 +0200
Subject: [PATCH 21/21] USB: OHCI: avoid conflicting platform drivers
In-Reply-To: <1366910944-3033663-1-git-send-email-arnd@arndb.de>
References: <1366910944-3033663-1-git-send-email-arnd@arndb.de>
Message-ID: <1366910944-3033663-22-git-send-email-arnd@arndb.de>

Like the EHCI driver, OHCI supports a large number of different platform
glue drivers by directly including them, which causes problems with
conflicting macro definitions in some cases. As more ARM architecture
specific back-ends are required to coexist in a single build, we should
split those out into separate drivers. Unfortunately, the infrastructure
for that is still under development, so to give us more time, this uses
a separate *_PLATFORM_DRIVER macro for each ARM specific OHCI backend,
just like we already do on PowerPC and some of the other ARM platforms.

In linux-3.10, only the SPEAr and CNS3xxx back-ends would actually conflict
without this patch, but over time we would get more of them, so this
is a way to avoid having to patch the driver every time it breaks. We
should still split out all back-ends into separate loadable modules,
but that work is only needed to improve code size and cleanliness after
this patch, not for correctness.

While we're here, this fixes the incorrectly sorted error path
for the OMAP1 and OMAP3 backends to ensure we always unregister
the exact set of drivers that were registered before erroring out.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Acked-by: Alan Stern <stern at rowland.harvard.edu>
Cc: linux-usb at vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
---
 drivers/usb/host/ohci-hcd.c | 136 ++++++++++++++++++++++++++++++++++++++------
 1 file changed, 118 insertions(+), 18 deletions(-)

diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
index 180a2b0..9e6de95 100644
--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -1102,12 +1102,12 @@ MODULE_LICENSE ("GPL");
 
 #if defined(CONFIG_ARCH_S3C24XX) || defined(CONFIG_ARCH_S3C64XX)
 #include "ohci-s3c2410.c"
-#define PLATFORM_DRIVER		ohci_hcd_s3c2410_driver
+#define S3C2410_PLATFORM_DRIVER	ohci_hcd_s3c2410_driver
 #endif
 
 #ifdef CONFIG_USB_OHCI_EXYNOS
 #include "ohci-exynos.c"
-#define PLATFORM_DRIVER		exynos_ohci_driver
+#define EXYNOS_PLATFORM_DRIVER	exynos_ohci_driver
 #endif
 
 #ifdef CONFIG_USB_OHCI_HCD_OMAP1
@@ -1127,25 +1127,24 @@ MODULE_LICENSE ("GPL");
 
 #ifdef CONFIG_ARCH_EP93XX
 #include "ohci-ep93xx.c"
-#define PLATFORM_DRIVER		ohci_hcd_ep93xx_driver
+#define EP93XX_PLATFORM_DRIVER	ohci_hcd_ep93xx_driver
 #endif
 
 #ifdef CONFIG_ARCH_AT91
 #include "ohci-at91.c"
-#define PLATFORM_DRIVER		ohci_hcd_at91_driver
+#define AT91_PLATFORM_DRIVER	ohci_hcd_at91_driver
 #endif
 
 #ifdef CONFIG_ARCH_LPC32XX
 #include "ohci-nxp.c"
-#define PLATFORM_DRIVER		usb_hcd_nxp_driver
+#define NXP_PLATFORM_DRIVER	usb_hcd_nxp_driver
 #endif
 
 #ifdef CONFIG_ARCH_DAVINCI_DA8XX
 #include "ohci-da8xx.c"
-#define PLATFORM_DRIVER		ohci_hcd_da8xx_driver
+#define DAVINCI_PLATFORM_DRIVER	ohci_hcd_da8xx_driver
 #endif
 
-
 #ifdef CONFIG_USB_OHCI_HCD_PPC_OF
 #include "ohci-ppc-of.c"
 #define OF_PLATFORM_DRIVER	ohci_hcd_ppc_of_driver
@@ -1153,7 +1152,7 @@ MODULE_LICENSE ("GPL");
 
 #ifdef CONFIG_PLAT_SPEAR
 #include "ohci-spear.c"
-#define PLATFORM_DRIVER		spear_ohci_hcd_driver
+#define SPEAR_PLATFORM_DRIVER	spear_ohci_hcd_driver
 #endif
 
 #ifdef CONFIG_PPC_PS3
@@ -1199,7 +1198,14 @@ MODULE_LICENSE ("GPL");
 	!defined(SA1111_DRIVER) &&	\
 	!defined(PS3_SYSTEM_BUS_DRIVER) && \
 	!defined(SM501_OHCI_DRIVER) && \
-	!defined(TMIO_OHCI_DRIVER)
+	!defined(TMIO_OHCI_DRIVER) && \
+	!defined(S3C2410_PLATFORM_DRIVER) && \
+	!defined(EXYNOS_PLATFORM_DRIVER) && \
+	!defined(EP93XX_PLATFORM_DRIVER) && \
+	!defined(AT91_PLATFORM_DRIVER) && \
+	!defined(NXP_PLATFORM_DRIVER) && \
+	!defined(DAVINCI_PLATFORM_DRIVER) && \
+	!defined(SPEAR_PLATFORM_DRIVER)
 #error "missing bus glue for ohci-hcd"
 #endif
 
@@ -1277,9 +1283,79 @@ static int __init ohci_hcd_mod_init(void)
 		goto error_tmio;
 #endif
 
+#ifdef S3C2410_PLATFORM_DRIVER
+	retval = platform_driver_register(&S3C2410_PLATFORM_DRIVER);
+	if (retval < 0)
+		goto error_s3c2410;
+#endif
+
+#ifdef EXYNOS_PLATFORM_DRIVER
+	retval = platform_driver_register(&EXYNOS_PLATFORM_DRIVER);
+	if (retval < 0)
+		goto error_exynos;
+#endif
+
+#ifdef EP93XX_PLATFORM_DRIVER
+	retval = platform_driver_register(&EP93XX_PLATFORM_DRIVER);
+	if (retval < 0)
+		goto error_ep93xx;
+#endif
+
+#ifdef AT91_PLATFORM_DRIVER
+	retval = platform_driver_register(&AT91_PLATFORM_DRIVER);
+	if (retval < 0)
+		goto error_at91;
+#endif
+
+#ifdef NXP_PLATFORM_DRIVER
+	retval = platform_driver_register(&NXP_PLATFORM_DRIVER);
+	if (retval < 0)
+		goto error_nxp;
+#endif
+
+#ifdef DAVINCI_PLATFORM_DRIVER
+	retval = platform_driver_register(&DAVINCI_PLATFORM_DRIVER);
+	if (retval < 0)
+		goto error_davinci;
+#endif
+
+#ifdef SPEAR_PLATFORM_DRIVER
+	retval = platform_driver_register(&SPEAR_PLATFORM_DRIVER);
+	if (retval < 0)
+		goto error_spear;
+#endif
+
 	return retval;
 
 	/* Error path */
+#ifdef SPEAR_PLATFORM_DRIVER
+	platform_driver_unregister(&SPEAR_PLATFORM_DRIVER);
+ error_spear:
+#endif
+#ifdef DAVINCI_PLATFORM_DRIVER
+	platform_driver_unregister(&DAVINCI_PLATFORM_DRIVER);
+ error_davinci:
+#endif
+#ifdef NXP_PLATFORM_DRIVER
+	platform_driver_unregister(&NXP_PLATFORM_DRIVER);
+ error_nxp:
+#endif
+#ifdef AT91_PLATFORM_DRIVER
+	platform_driver_unregister(&AT91_PLATFORM_DRIVER);
+ error_at91:
+#endif
+#ifdef EP93XX_PLATFORM_DRIVER
+	platform_driver_unregister(&EP93XX_PLATFORM_DRIVER);
+ error_ep93xx:
+#endif
+#ifdef EXYNOS_PLATFORM_DRIVER
+	platform_driver_unregister(&EXYNOS_PLATFORM_DRIVER);
+ error_exynos:
+#endif
+#ifdef S3C2410_PLATFORM_DRIVER
+	platform_driver_unregister(&S3C2410_PLATFORM_DRIVER);
+ error_s3c2410:
+#endif
 #ifdef TMIO_OHCI_DRIVER
 	platform_driver_unregister(&TMIO_OHCI_DRIVER);
  error_tmio:
@@ -1300,17 +1376,17 @@ static int __init ohci_hcd_mod_init(void)
 	platform_driver_unregister(&OF_PLATFORM_DRIVER);
  error_of_platform:
 #endif
-#ifdef PLATFORM_DRIVER
-	platform_driver_unregister(&PLATFORM_DRIVER);
- error_platform:
+#ifdef OMAP3_PLATFORM_DRIVER
+	platform_driver_unregister(&OMAP3_PLATFORM_DRIVER);
+ error_omap3_platform:
 #endif
 #ifdef OMAP1_PLATFORM_DRIVER
 	platform_driver_unregister(&OMAP1_PLATFORM_DRIVER);
  error_omap1_platform:
 #endif
-#ifdef OMAP3_PLATFORM_DRIVER
-	platform_driver_unregister(&OMAP3_PLATFORM_DRIVER);
- error_omap3_platform:
+#ifdef PLATFORM_DRIVER
+	platform_driver_unregister(&PLATFORM_DRIVER);
+ error_platform:
 #endif
 #ifdef PS3_SYSTEM_BUS_DRIVER
 	ps3_ohci_driver_unregister(&PS3_SYSTEM_BUS_DRIVER);
@@ -1329,6 +1405,27 @@ module_init(ohci_hcd_mod_init);
 
 static void __exit ohci_hcd_mod_exit(void)
 {
+#ifdef SPEAR_PLATFORM_DRIVER
+	platform_driver_unregister(&SPEAR_PLATFORM_DRIVER);
+#endif
+#ifdef DAVINCI_PLATFORM_DRIVER
+	platform_driver_unregister(&DAVINCI_PLATFORM_DRIVER);
+#endif
+#ifdef NXP_PLATFORM_DRIVER
+	platform_driver_unregister(&NXP_PLATFORM_DRIVER);
+#endif
+#ifdef AT91_PLATFORM_DRIVER
+	platform_driver_unregister(&AT91_PLATFORM_DRIVER);
+#endif
+#ifdef EP93XX_PLATFORM_DRIVER
+	platform_driver_unregister(&EP93XX_PLATFORM_DRIVER);
+#endif
+#ifdef EXYNOS_PLATFORM_DRIVER
+	platform_driver_unregister(&EXYNOS_PLATFORM_DRIVER);
+#endif
+#ifdef S3C2410_PLATFORM_DRIVER
+	platform_driver_unregister(&S3C2410_PLATFORM_DRIVER);
+#endif
 #ifdef TMIO_OHCI_DRIVER
 	platform_driver_unregister(&TMIO_OHCI_DRIVER);
 #endif
@@ -1344,12 +1441,15 @@ static void __exit ohci_hcd_mod_exit(void)
 #ifdef OF_PLATFORM_DRIVER
 	platform_driver_unregister(&OF_PLATFORM_DRIVER);
 #endif
-#ifdef PLATFORM_DRIVER
-	platform_driver_unregister(&PLATFORM_DRIVER);
-#endif
 #ifdef OMAP3_PLATFORM_DRIVER
 	platform_driver_unregister(&OMAP3_PLATFORM_DRIVER);
 #endif
+#ifdef OMAP1_PLATFORM_DRIVER
+	platform_driver_unregister(&OMAP1_PLATFORM_DRIVER);
+#endif
+#ifdef PLATFORM_DRIVER
+	platform_driver_unregister(&PLATFORM_DRIVER);
+#endif
 #ifdef PS3_SYSTEM_BUS_DRIVER
 	ps3_ohci_driver_unregister(&PS3_SYSTEM_BUS_DRIVER);
 #endif
-- 
1.8.1.2



From arnd at arndb.de  Thu Apr 25 13:28:43 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 25 Apr 2013 19:28:43 +0200
Subject: [PATCH 00/21] more arm build fixes
Message-ID: <1366910944-3033663-1-git-send-email-arnd@arndb.de>

Hi subsystem maintainers,

Here is another set of patches that resulted from build testing on
linux-next. Please apply directly into your trees if you agree,
or let me know if I made a mistake.

I can take whatever remains through the arm-soc tree if you prefer
that or I don't hear back.

	Arnd


Arnd Bergmann (21):
  ARM: topology: export cpu_topology
  ARM: default machine descriptor for multiplatform
  ARM: shmobile: don't call irqchip_init unconditionally
  ARM: orion5x: include linux/cpu.h
  atm: he: use mdelay instead of large udelay constants
  ALSA: ali5451: use mdelay instead of large udelay constants
  oss/dmabuf: use dma_map_single
  drm/nouveau: use mdelay instead of large udelay constants
  drm: export drm_vm_open_locked
  [SCSI] nsp32: use mdelay instead of large udelay constants
  irqdomain: export irq_domain_add_simple
  irqchip: s3c24xx: add missing __init annotations
  iommu: tegra: print dma_addr_t using %lld
  cpufreq: pxa2xx: initialize variables
  thermal: cooling: avoid uninitialied used gcc warning
  OF: remove #ifdef from linux/of_platform.h
  X.509: do not emit any informational output
  USB: ehci-msm: USB_MSM_OTG needs USB_PHY
  USB: lpc32xx: ISP1301 needs USB_PHY
  USB: OMAP: ISP1301 needs USB_PHY
  USB: OHCI: avoid conflicting platform drivers

 arch/arm/Kconfig                                   |   1 -
 arch/arm/configs/lpc32xx_defconfig                 |   1 +
 arch/arm/configs/msm_defconfig                     |   1 +
 arch/arm/configs/omap1_defconfig                   |   1 +
 arch/arm/kernel/devtree.c                          |   7 ++
 arch/arm/kernel/setup.c                            |  11 +-
 arch/arm/kernel/topology.c                         |   1 +
 arch/arm/mach-orion5x/common.c                     |   1 +
 arch/arm/mach-shmobile/intc-r8a7740.c              |  13 +-
 drivers/atm/he.c                                   |   2 +-
 drivers/cpufreq/pxa2xx-cpufreq.c                   |   5 +-
 drivers/gpu/drm/drm_vm.c                           |   1 +
 drivers/gpu/drm/nouveau/core/engine/disp/dacnv50.c |   3 +-
 drivers/iommu/tegra-gart.c                         |   3 +-
 drivers/iommu/tegra-smmu.c                         |   2 +-
 drivers/irqchip/irq-s3c24xx.c                      |   4 +-
 drivers/scsi/nsp32.c                               |   2 +-
 drivers/thermal/cpu_cooling.c                      |  17 +--
 drivers/usb/gadget/Kconfig                         |   2 +
 drivers/usb/host/Kconfig                           |   1 +
 drivers/usb/host/ohci-hcd.c                        | 136 ++++++++++++++++++---
 drivers/usb/phy/Makefile                           |   2 +-
 include/linux/of_platform.h                        |  13 +-
 kernel/irq/irqdomain.c                             |   1 +
 lib/build_OID_registry                             |   2 -
 sound/oss/dmabuf.c                                 |   3 +-
 sound/pci/ali5451/ali5451.c                        |   8 +-
 27 files changed, 187 insertions(+), 57 deletions(-)

-- 
1.8.1.2

Cc: "James E.J. Bottomley" <JBottomley at parallels.com>
Cc: Benjamin Herrenschmidt <benh at kernel.crashing.org>
Cc: David Airlie <airlied at linux.ie>
Cc: Felipe Balbi <balbi at ti.com>
Cc: Grant Likely <grant.likely at linaro.org>
Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
Cc: Inki Dae <inki.dae at samsung.com>
Cc: Jason Cooper <jason at lakedaemon.net>
Cc: Joerg Roedel <joro at 8bytes.org>
Cc: Nicolas Pitre <nico at linaro.org>
Cc: Rafael J. Wysocki <rafael.j.wysocki at intel.com>
Cc: Rob Herring <robherring2 at gmail.com>
Cc: Russell King <rmk+kernel at arm.linux.org.uk>
Cc: Simon Horman <horms+renesas at verge.net.au>
Cc: Thomas Gleixner <tglx at linutronix.de>
Cc: Viresh Kumar <viresh.kumar at linaro.org>
Cc: Will Deacon <will.deacon at arm.com>
Cc: alsa-devel at alsa-project.org
Cc: dri-devel at lists.freedesktop.org
Cc: linux-atm-general at lists.sourceforge.net
Cc: linux-scsi at vger.kernel.org
Cc: linux-usb at vger.kernel.org
Cc: netdev at vger.kernel.org


From arnd at arndb.de  Thu Apr 25 13:29:01 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 25 Apr 2013 19:29:01 +0200
Subject: [PATCH 18/21] USB: ehci-msm: USB_MSM_OTG needs USB_PHY
In-Reply-To: <1366910944-3033663-1-git-send-email-arnd@arndb.de>
References: <1366910944-3033663-1-git-send-email-arnd@arndb.de>
Message-ID: <1366910944-3033663-19-git-send-email-arnd@arndb.de>

The Kconfig entry for USB_EHCI_MSM unconditionally selects USB_MSM_OTG,
which is now only visible when USB_PHY is also enabled.

This adds an appropriate dependency and enables USB_PHY in the msm
defconfig, avoiding the Kbuild warning:

warning: (USB_EHCI_MSM) selects USB_MSM_OTG which has unmet direct dependencies (USB_SUPPORT && USB_PHY && (USB || USB_GADGET) && ARCH_MSM)

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Cc: linux-usb at vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
Cc: Felipe Balbi <balbi at ti.com>
Cc: Pavankumar Kondeti <pkondeti at codeaurora.org>
---
 arch/arm/configs/msm_defconfig | 1 +
 drivers/usb/host/Kconfig       | 1 +
 2 files changed, 2 insertions(+)

diff --git a/arch/arm/configs/msm_defconfig b/arch/arm/configs/msm_defconfig
index 44f9291..690b5f9 100644
--- a/arch/arm/configs/msm_defconfig
+++ b/arch/arm/configs/msm_defconfig
@@ -101,6 +101,7 @@ CONFIG_SND_DYNAMIC_MINORS=y
 CONFIG_SND_SOC=y
 CONFIG_HID_BATTERY_STRENGTH=y
 CONFIG_USB=y
+CONFIG_USB_PHY=y
 CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
 CONFIG_USB_MON=y
 CONFIG_USB_EHCI_HCD=y
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index c558472..de94f26 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -188,6 +188,7 @@ config USB_EHCI_HCD_AT91
 config USB_EHCI_MSM
 	tristate "Support for Qualcomm QSD/MSM on-chip EHCI USB controller"
 	depends on ARCH_MSM
+	depends on USB_PHY
 	select USB_EHCI_ROOT_HUB_TT
 	select USB_MSM_OTG
 	---help---
-- 
1.8.1.2



From arnd at arndb.de  Thu Apr 25 13:28:44 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 25 Apr 2013 19:28:44 +0200
Subject: [PATCH 01/21] ARM: topology: export cpu_topology
In-Reply-To: <1366910944-3033663-1-git-send-email-arnd@arndb.de>
References: <1366910944-3033663-1-git-send-email-arnd@arndb.de>
Message-ID: <1366910944-3033663-2-git-send-email-arnd@arndb.de>

The cpu_topology symbol is required by any driver using the topology
interfaces, which leads to a couple of build errors:

ERROR: "cpu_topology" [drivers/net/ethernet/sfc/sfc.ko] undefined!
ERROR: "cpu_topology" [drivers/cpufreq/arm_big_little.ko] undefined!
ERROR: "cpu_topology" [drivers/block/mtip32xx/mtip32xx.ko] undefined!

The obvious solution is to export this symbol.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Cc: Russell King <rmk+kernel at arm.linux.org.uk>
Cc: Will Deacon <will.deacon at arm.com>
Cc: Nicolas Pitre <nico at linaro.org>
Cc: Vincent Guittot <vincent.guittot at linaro.org>
---
 arch/arm/kernel/topology.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/kernel/topology.c b/arch/arm/kernel/topology.c
index f10316b..7ac5714 100644
--- a/arch/arm/kernel/topology.c
+++ b/arch/arm/kernel/topology.c
@@ -200,6 +200,7 @@ static inline void update_cpu_power(unsigned int cpuid, unsigned int mpidr) {}
  * cpu topology table
  */
 struct cputopo_arm cpu_topology[NR_CPUS];
+EXPORT_SYMBOL_GPL(cpu_topology);
 
 const struct cpumask *cpu_coregroup_mask(int cpu)
 {
-- 
1.8.1.2



From arnd at arndb.de  Thu Apr 25 13:28:54 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 25 Apr 2013 19:28:54 +0200
Subject: [PATCH 11/21] irqdomain: export irq_domain_add_simple
In-Reply-To: <1366910944-3033663-1-git-send-email-arnd@arndb.de>
References: <1366910944-3033663-1-git-send-email-arnd@arndb.de>
Message-ID: <1366910944-3033663-12-git-send-email-arnd@arndb.de>

All other irq_domain_add_* functions are exported already, and apparently
this one got left out by mistake, which causes build errors for ARM
allmodconfig kernels:

ERROR: "irq_domain_add_simple" [drivers/gpio/gpio-rcar.ko] undefined!
ERROR: "irq_domain_add_simple" [drivers/gpio/gpio-em.ko] undefined!

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Cc: Benjamin Herrenschmidt <benh at kernel.crashing.org>
Cc: Grant Likely <grant.likely at linaro.org>
Cc: Thomas Gleixner <tglx at linutronix.de>
Cc: Simon Horman <horms+renesas at verge.net.au>
Cc: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Cc: Magnus Damm <damm at opensource.se>
---
 kernel/irq/irqdomain.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index 059a280..c532c15 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -194,6 +194,7 @@ struct irq_domain *irq_domain_add_simple(struct device_node *of_node,
 	/* A linear domain is the default */
 	return irq_domain_add_linear(of_node, size, ops, host_data);
 }
+EXPORT_SYMBOL_GPL(irq_domain_add_simple);
 
 /**
  * irq_domain_add_legacy() - Allocate and register a legacy revmap irq_domain.
-- 
1.8.1.2



From arnd at arndb.de  Thu Apr 25 13:28:45 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 25 Apr 2013 19:28:45 +0200
Subject: [PATCH 02/21] ARM: default machine descriptor for multiplatform
In-Reply-To: <1366910944-3033663-1-git-send-email-arnd@arndb.de>
References: <1366910944-3033663-1-git-send-email-arnd@arndb.de>
Message-ID: <1366910944-3033663-3-git-send-email-arnd@arndb.de>

Since we now have default implementations for init_time and init_irq,
the init_machine callback is the only one that is not yet optional,
but since simple DT based platforms all have the same
of_platform_populate function call in there, we can consolidate them
as well, and then actually boot with a completely empty machine_desc.
Unofortunately we cannot just default to an empty init_machine: We
cannot call of_platform_populate before init_machine because that
does not work in case of auxdata, and we cannot call it after
init_machine either because the machine might need to run code
after adding the devices.

To take the final step, this adds support for booting without defining
any machine_desc whatsoever.

For the case that CONFIG_MULTIPLATFORM is enabled, it adds a
global machine descriptor that never matches any machine but is
used as a fallback if nothing else matches. We assume that without
CONFIG_MULTIPLATFORM, we only want to boot on the systems that the kernel
is built for, so we still retain the build-time warning for missing
machine descriptors and the run-time warning when the platform does not
match in that case.

In the case that we run on a multiplatform kernel and the machine
provides a fully populated device tree, we attempt to keep booting,
hoping that no machine specific callbacks are necessary.

Finally, this also removes the misguided "select ARCH_VEXPRESS" that
was only added to avoid a build error for allnoconfig kernels.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Acked-by: Nicolas Pitre <nico at linaro.org>
Acked-by: Olof Johansson <olof at lixom.net>
Cc: "Russell King - ARM Linux" <linux at arm.linux.org.uk>
Cc: Rob Herring <robherring2 at gmail.com>
---
 arch/arm/Kconfig          |  1 -
 arch/arm/kernel/devtree.c |  7 +++++++
 arch/arm/kernel/setup.c   | 11 ++++++++++-
 3 files changed, 17 insertions(+), 2 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index a0d58a6..8c33760 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -890,7 +890,6 @@ config ARCH_MULTI_V7
 	bool "ARMv7 based platforms (Cortex-A, PJ4, Scorpion, Krait)"
 	default y
 	select ARCH_MULTI_V6_V7
-	select ARCH_VEXPRESS
 	select CPU_V7
 
 config ARCH_MULTI_V6_V7
diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
index 70f1bde..5af04f6 100644
--- a/arch/arm/kernel/devtree.c
+++ b/arch/arm/kernel/devtree.c
@@ -180,6 +180,13 @@ struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys)
 	unsigned long dt_root;
 	const char *model;
 
+#ifdef CONFIG_ARCH_MULTIPLATFORM
+	DT_MACHINE_START(GENERIC_DT, "Generic DT based system")
+	MACHINE_END
+
+	mdesc_best = (struct machine_desc *)&__mach_desc_GENERIC_DT;
+#endif
+
 	if (!dt_phys)
 		return NULL;
 
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 408f446..d039623 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -18,6 +18,7 @@
 #include <linux/bootmem.h>
 #include <linux/seq_file.h>
 #include <linux/screen_info.h>
+#include <linux/of_platform.h>
 #include <linux/init.h>
 #include <linux/kexec.h>
 #include <linux/of_fdt.h>
@@ -672,9 +673,17 @@ struct screen_info screen_info = {
 
 static int __init customize_machine(void)
 {
-	/* customizes platform devices, or adds new ones */
+	/*
+	 * customizes platform devices, or adds new ones
+	 * On DT based machines, we fall back to populating the
+	 * machine from the device tree, if no callback is provided,
+	 * otherwise we would always need an init_machine callback.
+	 */
 	if (machine_desc->init_machine)
 		machine_desc->init_machine();
+	else
+		of_platform_populate(NULL, of_default_bus_match_table,
+					NULL, NULL);
 	return 0;
 }
 arch_initcall(customize_machine);
-- 
1.8.1.2



From arnd at arndb.de  Thu Apr 25 13:28:46 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 25 Apr 2013 19:28:46 +0200
Subject: [PATCH 03/21] ARM: shmobile: don't call irqchip_init unconditionally
In-Reply-To: <1366910944-3033663-1-git-send-email-arnd@arndb.de>
References: <1366910944-3033663-1-git-send-email-arnd@arndb.de>
Message-ID: <1366910944-3033663-4-git-send-email-arnd@arndb.de>

The irqchip_init function is only available when building
with CONFIG_OF enabled, which causes this build failure for
bonito_defconfig:

arch/arm/mach-shmobile/built-in.o: In function `r8a7740_init_irq_of':
:(.init.text+0x580): undefined reference to `irqchip_init'

This makes both the OF and the ATAGS portion of the driver
conditional, which avoids the build error and also results
in smaller object code if not both are enabled, without the
need for an #ifdef.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Cc: Bastian Hecht <hechtb+renesas at gmail.com>
Cc: Simon Horman <horms+renesas at verge.net.au>
Cc: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
---
 arch/arm/mach-shmobile/intc-r8a7740.c | 13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-shmobile/intc-r8a7740.c b/arch/arm/mach-shmobile/intc-r8a7740.c
index 8871f77..5dc57f1 100644
--- a/arch/arm/mach-shmobile/intc-r8a7740.c
+++ b/arch/arm/mach-shmobile/intc-r8a7740.c
@@ -53,14 +53,23 @@ static void __init r8a7740_init_irq_common(void)
 
 void __init r8a7740_init_irq_of(void)
 {
+	if (!IS_ENABLED(CONFIG_OF))
+		return;
+
 	irqchip_init();
 	r8a7740_init_irq_common();
 }
 
 void __init r8a7740_init_irq(void)
 {
-	void __iomem *gic_dist_base = ioremap_nocache(0xc2800000, 0x1000);
-	void __iomem *gic_cpu_base = ioremap_nocache(0xc2000000, 0x1000);
+	void __iomem *gic_dist_base;
+	void __iomem *gic_cpu_base;
+
+	if (!IS_ENABLED(CONFIG_ATAGS))
+		return;
+
+	gic_dist_base = ioremap_nocache(0xc2800000, 0x1000);
+	gic_cpu_base = ioremap_nocache(0xc2000000, 0x1000);
 
 	/* initialize the Generic Interrupt Controller PL390 r0p0 */
 	gic_init(0, 29, gic_dist_base, gic_cpu_base);
-- 
1.8.1.2



From arnd at arndb.de  Thu Apr 25 13:28:53 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 25 Apr 2013 19:28:53 +0200
Subject: [PATCH 10/21] [SCSI] nsp32: use mdelay instead of large udelay
 constants
In-Reply-To: <1366910944-3033663-1-git-send-email-arnd@arndb.de>
References: <1366910944-3033663-1-git-send-email-arnd@arndb.de>
Message-ID: <1366910944-3033663-11-git-send-email-arnd@arndb.de>

ARM cannot handle udelay for more than 2 miliseconds, so we
should use mdelay instead for those.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Cc: GOTO Masanori <gotom at debian.or.jp>
Cc: YOKOTA Hiroshi <yokota at netlab.is.tsukuba.ac.jp>
Cc: "James E.J. Bottomley" <JBottomley at parallels.com>
Cc: linux-scsi at vger.kernel.org
---
 drivers/scsi/nsp32.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/nsp32.c b/drivers/scsi/nsp32.c
index 1e3879d..0665f9c 100644
--- a/drivers/scsi/nsp32.c
+++ b/drivers/scsi/nsp32.c
@@ -2899,7 +2899,7 @@ static void nsp32_do_bus_reset(nsp32_hw_data *data)
 	 * reset SCSI bus
 	 */
 	nsp32_write1(base, SCSI_BUS_CONTROL, BUSCTL_RST);
-	udelay(RESET_HOLD_TIME);
+	mdelay(RESET_HOLD_TIME / 1000);
 	nsp32_write1(base, SCSI_BUS_CONTROL, 0);
 	for(i = 0; i < 5; i++) {
 		intrdat = nsp32_read2(base, IRQ_STATUS); /* dummy read */
-- 
1.8.1.2



From arnd at arndb.de  Thu Apr 25 13:28:50 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 25 Apr 2013 19:28:50 +0200
Subject: [PATCH 07/21] oss/dmabuf: use dma_map_single
In-Reply-To: <1366910944-3033663-1-git-send-email-arnd@arndb.de>
References: <1366910944-3033663-1-git-send-email-arnd@arndb.de>
Message-ID: <1366910944-3033663-8-git-send-email-arnd@arndb.de>

The virt_to_bus/bus_to_virt functions have been deprecated
for as long as I can remember, and they are used in very
few remaining instances, usually in obscure ISA device
drivers. The OSS sound drivers are the only ones that are
still used on the ARM architecture, and only on some of
the earliest StrongARM machines.

The problem for converting the OSS subsystem to use
dma_map_single instead is that the caller of virt_to_bus
does not have a device pointer, since the subsystem has
never been ported to use the common device infrastructure.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Cc: Jaroslav Kysela <perex at perex.cz>
Cc: Takashi Iwai <tiwai at suse.de>
Cc: alsa-devel at alsa-project.org
---
 sound/oss/dmabuf.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/sound/oss/dmabuf.c b/sound/oss/dmabuf.c
index bcc3e8e..a59c888 100644
--- a/sound/oss/dmabuf.c
+++ b/sound/oss/dmabuf.c
@@ -114,7 +114,7 @@ static int sound_alloc_dmap(struct dma_buffparms *dmap)
 		}
 	}
 	dmap->raw_buf = start_addr;
-	dmap->raw_buf_phys = virt_to_bus(start_addr);
+	dmap->raw_buf_phys = dma_map_single(NULL, start_addr, dmap->buffsize, DMA_BIDIRECTIONAL);
 
 	for (page = virt_to_page(start_addr); page <= virt_to_page(end_addr); page++)
 		SetPageReserved(page);
@@ -139,6 +139,7 @@ static void sound_free_dmap(struct dma_buffparms *dmap)
 	for (page = virt_to_page(start_addr); page <= virt_to_page(end_addr); page++)
 		ClearPageReserved(page);
 
+	dma_unmap_single(NULL, dmap->raw_buf_phys, dmap->buffsize, DMA_BIDIRECTIONAL);
 	free_pages((unsigned long) dmap->raw_buf, sz);
 	dmap->raw_buf = NULL;
 }
-- 
1.8.1.2



From arnd at arndb.de  Thu Apr 25 13:28:48 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 25 Apr 2013 19:28:48 +0200
Subject: [PATCH 05/21] atm: he: use mdelay instead of large udelay constants
In-Reply-To: <1366910944-3033663-1-git-send-email-arnd@arndb.de>
References: <1366910944-3033663-1-git-send-email-arnd@arndb.de>
Message-ID: <1366910944-3033663-6-git-send-email-arnd@arndb.de>

ARM cannot handle udelay for more than 2 miliseconds, so we
should use mdelay instead for those.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Cc: Chas Williams <chas at cmf.nrl.navy.mil>
Cc: linux-atm-general at lists.sourceforge.net
Cc: netdev at vger.kernel.org
---
 drivers/atm/he.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/atm/he.c b/drivers/atm/he.c
index d689126..7700061 100644
--- a/drivers/atm/he.c
+++ b/drivers/atm/he.c
@@ -1055,7 +1055,7 @@ static int he_start(struct atm_dev *dev)
 	he_writel(he_dev, 0x0, RESET_CNTL);
 	he_writel(he_dev, 0xff, RESET_CNTL);
 
-	udelay(16*1000);	/* 16 ms */
+	mdelay(16);	/* 16 ms */
 	status = he_readl(he_dev, RESET_CNTL);
 	if ((status & BOARD_RST_STATUS) == 0) {
 		hprintk("reset failed\n");
-- 
1.8.1.2



From arnd at arndb.de  Thu Apr 25 13:31:24 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 25 Apr 2013 19:31:24 +0200
Subject: Exynos regressions w.r.t. config and debuggability due to
 multiplatform
In-Reply-To: <51794CD3.4080807@samsung.com>
References: <CAOesGMgRsa-AvbEZCc1=_ovaZMaG0S-CDok2MDp_zu5yderAYw@mail.gmail.com>
 <201304241703.49864.arnd@arndb.de> <51794CD3.4080807@samsung.com>
Message-ID: <201304251931.25028.arnd@arndb.de>

On Thursday 25 April 2013, Kukjin Kim wrote:
> 
> On 04/25/13 00:03, Arnd Bergmann wrote:
> > On Wednesday 24 April 2013, Olof Johansson wrote:
> >> I think we should hold off on multiplatform for exynos until it works
> >> better, i.e. 3.11.
> >>
> I think, this would be better choice for now if it's not urgent...
> 

I spent a lot of time on it because it's a priority for Linaro, but
that means I'm biased in the question of whether to merge it or not.
It should only get in if you and Olof think it's a good idea.

	Arnd


From sergei.shtylyov at cogentembedded.com  Thu Apr 25 13:32:01 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Thu, 25 Apr 2013 21:32:01 +0400
Subject: [PATCH 1/2] drivers/video: Kconfig, fix mxsfb build
In-Reply-To: <1366791772-11133-2-git-send-email-mpa@pengutronix.de>
References: <1366790894-20426-1-git-send-email-mpa@pengutronix.de>
 <1366791772-11133-1-git-send-email-mpa@pengutronix.de>
 <1366791772-11133-2-git-send-email-mpa@pengutronix.de>
Message-ID: <51796891.3040908@cogentembedded.com>

Hello.

On 24-04-2013 12:22, Markus Pargmann wrote:

> Kernel build fails with commit 669406534b4abb827d1bdc39bb5e2d5255818ae2

   Please also specify the summary line of that commit in parens.

> This patch replaces OF_VIDEOMODE symbol by VIDEOMODE_HELPERS.

> Signed-off-by: Markus Pargmann <mpa at pengutronix.de>

WBR, Sergei




From jason at lakedaemon.net  Thu Apr 25 13:34:45 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Thu, 25 Apr 2013 13:34:45 -0400
Subject: [PATCH 04/21] ARM: orion5x: include linux/cpu.h
In-Reply-To: <1366910944-3033663-5-git-send-email-arnd@arndb.de>
References: <1366910944-3033663-1-git-send-email-arnd@arndb.de>
 <1366910944-3033663-5-git-send-email-arnd@arndb.de>
Message-ID: <20130425173445.GD32497@titan.lakedaemon.net>

On Thu, Apr 25, 2013 at 07:28:47PM +0200, Arnd Bergmann wrote:
> The linux/cpu.h header is no longer implictly included in this
> file, so we need to an #include statement to avoid this build
> warning:
> 
> arch/arm/mach-orion5x/common.c:339:3: error: implicit declaration of function 'cpu_idle_poll_ctrl' [-Werror=implicit-function-declaration]
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Cc: Jason Cooper <jason at lakedaemon.net>
> Cc: Andrew Lunn <andrew at lunn.ch>
> ---
>  arch/arm/mach-orion5x/common.c | 1 +
>  1 file changed, 1 insertion(+)

Acked-by: Jason Cooper <jason at lakedaemon.net>

I imagine it's easiest for you to take this through a branch you already
have set up, so have it.

thx,

Jason.


From robdclark at gmail.com  Thu Apr 25 13:39:32 2013
From: robdclark at gmail.com (Rob Clark)
Date: Thu, 25 Apr 2013 13:39:32 -0400
Subject: [PATCH 11/21] drm/tilcdc: use only a single module device table
In-Reply-To: <1366734653-488286-12-git-send-email-arnd@arndb.de>
References: <1366734653-488286-1-git-send-email-arnd@arndb.de>
 <1366734653-488286-12-git-send-email-arnd@arndb.de>
Message-ID: <CAF6AEGvOmQDvD64=WiGjS1SKeSOOf=5rTefn5c=ciBhaxfhntw@mail.gmail.com>

On Tue, Apr 23, 2013 at 12:30 PM, Arnd Bergmann <arnd at arndb.de> wrote:
> The tilcdc driver fails to be built as a module because of extraneous
> MODULE_DEVICE_TABLE entries:
>
> drivers/gpu/drm/tilcdc/tilcdc_slave.o:(.data+0x54): multiple definition of `__mod_of_device_table'
> drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54): first defined here
> drivers/gpu/drm/tilcdc/tilcdc_panel.o:(.data+0x54): multiple definition of `__mod_of_device_table'
> drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54): first defined here
> drivers/gpu/drm/tilcdc/tilcdc_drv.o:(.data+0x184): multiple definition of `__mod_of_device_table'
> drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54): first defined here
>
> Since the entire point of these entries is to make the module autoload
> when one of the devices is present, it's enough to keep the one entry
> for "ti,am33xx-tilcdc", which should always be there if any of the
> others are.

Thanks Arnd

Acked-By: Rob Clark <robdclark at gmail.com>

> Cc: Rob Clark <robdclark at gmail.com>
> Cc: Dave Airlie <airlied at linux.ie>
> Cc: dri-devel at lists.freedesktop.org
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> ---
>  drivers/gpu/drm/tilcdc/tilcdc_panel.c  | 1 -
>  drivers/gpu/drm/tilcdc/tilcdc_slave.c  | 1 -
>  drivers/gpu/drm/tilcdc/tilcdc_tfp410.c | 1 -
>  3 files changed, 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_panel.c b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
> index 580b74e..eb99f42 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_panel.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
> @@ -413,7 +413,6 @@ static struct of_device_id panel_of_match[] = {
>                 { .compatible = "ti,tilcdc,panel", },
>                 { },
>  };
> -MODULE_DEVICE_TABLE(of, panel_of_match);
>
>  struct platform_driver panel_driver = {
>         .probe = panel_probe,
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_slave.c b/drivers/gpu/drm/tilcdc/tilcdc_slave.c
> index 568dc1c..db1d2fc 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_slave.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_slave.c
> @@ -353,7 +353,6 @@ static struct of_device_id slave_of_match[] = {
>                 { .compatible = "ti,tilcdc,slave", },
>                 { },
>  };
> -MODULE_DEVICE_TABLE(of, slave_of_match);
>
>  struct platform_driver slave_driver = {
>         .probe = slave_probe,
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c b/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
> index 58d487b..a36788f 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
> @@ -396,7 +396,6 @@ static struct of_device_id tfp410_of_match[] = {
>                 { .compatible = "ti,tilcdc,tfp410", },
>                 { },
>  };
> -MODULE_DEVICE_TABLE(of, tfp410_of_match);
>
>  struct platform_driver tfp410_driver = {
>         .probe = tfp410_probe,
> --
> 1.8.1.2
>


From B16395 at freescale.com  Thu Apr 25 13:42:12 2013
From: B16395 at freescale.com (Sethi Varun-B16395)
Date: Thu, 25 Apr 2013 17:42:12 +0000
Subject: [PATCH 13/21] iommu: tegra: print dma_addr_t using %lld
In-Reply-To: <1366910944-3033663-14-git-send-email-arnd@arndb.de>
References: <1366910944-3033663-1-git-send-email-arnd@arndb.de>
 <1366910944-3033663-14-git-send-email-arnd@arndb.de>
Message-ID: <C5ECD7A89D1DC44195F34B25E172658D4BD243@039-SN2MPN1-011.039d.mgd.msft.net>

Hi Arnd,
I already submitted a patch to fix this.
http://permalink.gmane.org/gmane.linux.kernel.iommu/2036

Regards
Varun

> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd at arndb.de]
> Sent: Thursday, April 25, 2013 10:59 PM
> To: linux-arm-kernel at lists.infradead.org
> Cc: linux-kernel at vger.kernel.org; Arnd Bergmann; Sethi Varun-B16395;
> Joerg Roedel
> Subject: [PATCH 13/21] iommu: tegra: print dma_addr_t using %lld
> 
> The code was recently changed to work for builds with a 64 bit
> dma_addr_t, but the printk unconditionally uses a format string for an
> "long" variable, which is always wrong as the dma_add_t is now either
> 'unsigned int' or 'unsigned long long'
> depending on configuration.
> 
> The easiest solution is to cast the variable to u64 and print it as a 64
> bit value.
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Cc: Varun Sethi <Varun.Sethi at freescale.com>
> Cc: Joerg Roedel <joro at 8bytes.org>
> ---
>  drivers/iommu/tegra-gart.c | 3 ++-
>  drivers/iommu/tegra-smmu.c | 2 +-
>  2 files changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/iommu/tegra-gart.c b/drivers/iommu/tegra-gart.c
> index 4aec8be..ebbdd82 100644
> --- a/drivers/iommu/tegra-gart.c
> +++ b/drivers/iommu/tegra-gart.c
> @@ -295,7 +295,8 @@ static phys_addr_t gart_iommu_iova_to_phys(struct
> iommu_domain *domain,
> 
>  	pa = (pte & GART_PAGE_MASK);
>  	if (!pfn_valid(__phys_to_pfn(pa))) {
> -		dev_err(gart->dev, "No entry for %08lx:%08x\n", iova, pa);
> +		dev_err(gart->dev, "No entry for %08llx:%pa\n",
> +				(u64)iova, &pa);
>  		gart_dump_table(gart);
>  		return -EINVAL;
>  	}
> diff --git a/drivers/iommu/tegra-smmu.c b/drivers/iommu/tegra-smmu.c
> index bc9b599..ef2a120 100644
> --- a/drivers/iommu/tegra-smmu.c
> +++ b/drivers/iommu/tegra-smmu.c
> @@ -772,7 +772,7 @@ static phys_addr_t smmu_iommu_iova_to_phys(struct
> iommu_domain *domain,
>  	pfn = *pte & SMMU_PFN_MASK;
>  	WARN_ON(!pfn_valid(pfn));
>  	dev_dbg(as->smmu->dev,
> -		"iova:%08lx pfn:%08lx asid:%d\n", iova, pfn, as->asid);
> +		"iova:%08llx pfn:%08lx asid:%d\n", (u64)iova, pfn, as->asid);
> 
>  	spin_unlock_irqrestore(&as->lock, flags);
>  	return PFN_PHYS(pfn);
> --
> 1.8.1.2
> 




From gregkh at linuxfoundation.org  Thu Apr 25 13:59:50 2013
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Thu, 25 Apr 2013 10:59:50 -0700
Subject: [PATCH 18/21] USB: ehci-msm: USB_MSM_OTG needs USB_PHY
In-Reply-To: <1366910944-3033663-19-git-send-email-arnd@arndb.de>
References: <1366910944-3033663-1-git-send-email-arnd@arndb.de>
 <1366910944-3033663-19-git-send-email-arnd@arndb.de>
Message-ID: <20130425175950.GA14654@kroah.com>

On Thu, Apr 25, 2013 at 07:29:01PM +0200, Arnd Bergmann wrote:
> The Kconfig entry for USB_EHCI_MSM unconditionally selects USB_MSM_OTG,
> which is now only visible when USB_PHY is also enabled.
> 
> This adds an appropriate dependency and enables USB_PHY in the msm
> defconfig, avoiding the Kbuild warning:
> 
> warning: (USB_EHCI_MSM) selects USB_MSM_OTG which has unmet direct dependencies (USB_SUPPORT && USB_PHY && (USB || USB_GADGET) && ARCH_MSM)
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Cc: linux-usb at vger.kernel.org
> Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
> Cc: Felipe Balbi <balbi at ti.com>
> Cc: Pavankumar Kondeti <pkondeti at codeaurora.org>
> ---
>  arch/arm/configs/msm_defconfig | 1 +
>  drivers/usb/host/Kconfig       | 1 +
>  2 files changed, 2 insertions(+)
> 
> diff --git a/arch/arm/configs/msm_defconfig b/arch/arm/configs/msm_defconfig
> index 44f9291..690b5f9 100644
> --- a/arch/arm/configs/msm_defconfig
> +++ b/arch/arm/configs/msm_defconfig
> @@ -101,6 +101,7 @@ CONFIG_SND_DYNAMIC_MINORS=y
>  CONFIG_SND_SOC=y
>  CONFIG_HID_BATTERY_STRENGTH=y
>  CONFIG_USB=y
> +CONFIG_USB_PHY=y
>  CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
>  CONFIG_USB_MON=y
>  CONFIG_USB_EHCI_HCD=y

This part of the patch doesn't apply to my tree, so I can't take it.

> diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
> index c558472..de94f26 100644
> --- a/drivers/usb/host/Kconfig
> +++ b/drivers/usb/host/Kconfig
> @@ -188,6 +188,7 @@ config USB_EHCI_HCD_AT91
>  config USB_EHCI_MSM
>  	tristate "Support for Qualcomm QSD/MSM on-chip EHCI USB controller"
>  	depends on ARCH_MSM
> +	depends on USB_PHY
>  	select USB_EHCI_ROOT_HUB_TT
>  	select USB_MSM_OTG
>  	---help---

But this does, and I'm guessing that it's the more important part, so
I'll just edit it and only take this hunk, ok?

thanks,

greg k-h


From linux at arm.linux.org.uk  Thu Apr 25 13:58:19 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Thu, 25 Apr 2013 18:58:19 +0100
Subject: [PATCH] of: Set the DMA mask to 64 bits on ARM LPAE systems
In-Reply-To: <51796365.5030405@codeaurora.org>
References: <1366764649-10342-1-git-send-email-lauraa@codeaurora.org>
 <20130425133315.GA7157@localhost.cambridge.arm.com>
 <51796365.5030405@codeaurora.org>
Message-ID: <20130425175819.GF14496@n2100.arm.linux.org.uk>

On Thu, Apr 25, 2013 at 10:09:57AM -0700, Laura Abbott wrote:
> I thought about this as well but in arch/arm/mm/mm.h:
>
> #ifdef CONFIG_ZONE_DMA
> extern phys_addr_t arm_dma_limit;
> #else
> #define arm_dma_limit ((phys_addr_t)~0)
> #endif
>
> arm_dma_limit is explicitly cast to phys_addr_t, which means that  
> arm_dma_limit will be always be sizeof(phys_addr_t) regardless of  
> sizeof(dma_addr_t).

This is the size of the DMA zone, which controls the _minimum_ DMA mask
that can be used in the system.  DMA masks must always be greater than
this limit.


From cdall at cs.columbia.edu  Thu Apr 25 14:04:15 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Thu, 25 Apr 2013 11:04:15 -0700
Subject: [PATCH] ARM: KVM: Allow host virtual timer irq number to be
 different from guest virtual timer irq number
In-Reply-To: <1366879534-31578-1-git-send-email-anup.patel@linaro.org>
References: <1366879534-31578-1-git-send-email-anup.patel@linaro.org>
Message-ID: <CAEDV+gLKwrxxdoB9NDBLb7CSnXL1j=O7f=2Y_ftXmLfGtTBnbA@mail.gmail.com>

On Thu, Apr 25, 2013 at 1:45 AM, Anup Patel <anup.patel at linaro.org> wrote:
> The arch_timer irq numbers (or PPI number) are implementation dependent so, the host virtual timer irq number can be different from guest virtual timer irq number.
>
> Currently, we only have Cortex-A15 guest (for KVM ARMv7) and Cortex-A57 guest (for KVM ARMv8) supported. These guests have virtual timer irq number as 27.
>
> This patch ensures that host virtual timer irq number is read from DTB and guest virtual timer irq is always 27.

I don't think this is the right fix.

I prefer not hard-coding this stuff in the kernel, but let user space
decide this. If we have good technical arguments not to do that (such
as knowing that this is always defined per-core and not for an SoC
(ARM guys?) then at least the patch should lookup the target processor
and set the irq number accordingly.

>
> Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar at linaro.org>
> ---
>  arch/arm/kvm/arch_timer.c |   18 +++++++++++++-----
>  1 file changed, 13 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm/kvm/arch_timer.c b/arch/arm/kvm/arch_timer.c
> index 49a7516..376abf0 100644
> --- a/arch/arm/kvm/arch_timer.c
> +++ b/arch/arm/kvm/arch_timer.c
> @@ -30,10 +30,18 @@
>
>  static struct timecounter *timecounter;
>  static struct workqueue_struct *wqueue;
> -static struct kvm_irq_level timer_irq = {
> +static struct kvm_irq_level host_timer_irq = {
>         .level  = 1,
>  };
>
> +/* Guest virtual timer irq number will be based on type of guest we emulate.
> + * For Cortex-A15 & Cortex-A57 guest, virtual timer irq is 27
> + */
> +static struct kvm_irq_level guest_timer_irq = {
> +       .irq = 27,
> +       .level = 1,
> +};
> +
>  static cycle_t kvm_phys_timer_read(void)
>  {
>         return timecounter->cc->read(timecounter->cc);
> @@ -163,12 +171,12 @@ void kvm_timer_vcpu_init(struct kvm_vcpu *vcpu)
>         INIT_WORK(&timer->expired, kvm_timer_inject_irq_work);
>         hrtimer_init(&timer->timer, CLOCK_MONOTONIC, HRTIMER_MODE_ABS);
>         timer->timer.function = kvm_timer_expire;
> -       timer->irq = &timer_irq;
> +       timer->irq = &guest_timer_irq;
>  }
>
>  static void kvm_timer_init_interrupt(void *info)
>  {
> -       enable_percpu_irq(timer_irq.irq, 0);
> +       enable_percpu_irq(host_timer_irq.irq, 0);
>  }
>
>
> @@ -182,7 +190,7 @@ static int kvm_timer_cpu_notify(struct notifier_block *self,
>                 break;
>         case CPU_DYING:
>         case CPU_DYING_FROZEN:
> -               disable_percpu_irq(timer_irq.irq);
> +               disable_percpu_irq(host_timer_irq.irq);
>                 break;
>         }
>
> @@ -230,7 +238,7 @@ int kvm_timer_hyp_init(void)
>                 goto out;
>         }
>
> -       timer_irq.irq = ppi;
> +       host_timer_irq.irq = ppi;
>
>         err = register_cpu_notifier(&kvm_timer_cpu_nb);
>         if (err) {
> --
> 1.7.9.5
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From rjw at sisk.pl  Thu Apr 25 14:12:29 2013
From: rjw at sisk.pl (Rafael J. Wysocki)
Date: Thu, 25 Apr 2013 20:12:29 +0200
Subject: [PATCH 07/18] cpufreq: s3c24xx: move cpufreq driver to
 drivers/cpufreq
In-Reply-To: <51795E53.5030908@samsung.com>
References: <cover.1365079581.git.viresh.kumar@linaro.org>
 <2264237.NUtkmvZG3W@vostro.rjw.lan> <51795E53.5030908@samsung.com>
Message-ID: <1615834.7iOsapYTqY@vostro.rjw.lan>

On Friday, April 26, 2013 01:48:19 AM Kukjin Kim wrote:
> On 04/24/13 07:59, Rafael J. Wysocki wrote:
> 
> [...]
> 
> >> Rafael, please take this patch with my ack in your tree, sorry for noise.
> >>
> >> Acked-by: Kukjin Kim<kgene.kim at samsung.com>
> >>
> >> If any problems, please kindly let me know.
> >
> > Well, I suppose I can take the original patch, but then it will conflict with
> > your tree during merge.  Is that not a problem?
> >
> I think, some conflicts can be occurred but if so, we can fix it before 
> merge window.

Well, how exactly would you like to address them?

Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.


From rafael.j.wysocki at intel.com  Thu Apr 25 14:14:06 2013
From: rafael.j.wysocki at intel.com (Rafael J. Wysocki)
Date: Thu, 25 Apr 2013 20:14:06 +0200
Subject: [PATCH 14/21] cpufreq: pxa2xx: initialize variables
In-Reply-To: <1366910944-3033663-15-git-send-email-arnd@arndb.de>
References: <1366910944-3033663-1-git-send-email-arnd@arndb.de>
 <1366910944-3033663-15-git-send-email-arnd@arndb.de>
Message-ID: <5179726E.9020003@intel.com>

On 4/25/2013 7:28 PM, Arnd Bergmann wrote:
> gcc-3.8 correctly found that the variables set by find_freq_tables()
> are not initialized if this function is called on something other
> than a pxa2xx or pxa3xx:
>
> pxa2xx-cpufreq.c: In function 'pxa_verify_policy':
> pxa2xx-cpufreq.c:272:6: warning: 'pxa_freqs_table' may be used uninitialized in this function [-Wmaybe-uninitialized]
> pxa2xx-cpufreq.c: In function 'pxa_set_target':
> pxa2xx-cpufreq.c:345:23: warning: 'pxa_freq_settings' may be used uninitialized in this function [-Wmaybe-uninitialized]
>
> Rather than adding a bogus initialization that would let us
> get a little further before crashing, add an explicit BUG().
> We know that this code is designed to run on only these cpus,
> so this will fix the build warning and give a more helpful
> diagnostic if the code ever changes to run on other machines.
>
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Cc: Viresh Kumar <viresh.kumar at linaro.org>
> Cc: Rafael J. Wysocki <rafael.j.wysocki at intel.com>

OK, applied.

Can you please CC future cpufreq changes to linux-pm at vger.kernel.org?  
That'd make the handling of them much easier.

Thanks,
Rafael


> ---
>   drivers/cpufreq/pxa2xx-cpufreq.c | 5 +++--
>   1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/cpufreq/pxa2xx-cpufreq.c b/drivers/cpufreq/pxa2xx-cpufreq.c
> index fe4c55b..9e5bc8e 100644
> --- a/drivers/cpufreq/pxa2xx-cpufreq.c
> +++ b/drivers/cpufreq/pxa2xx-cpufreq.c
> @@ -221,10 +221,11 @@ static void find_freq_tables(struct cpufreq_frequency_table **freq_table,
>   			*pxa_freqs = pxa255_turbo_freqs;
>   			*freq_table = pxa255_turbo_freq_table;
>   		}
> -	}
> -	if (cpu_is_pxa27x()) {
> +	} else if (cpu_is_pxa27x()) {
>   		*pxa_freqs = pxa27x_freqs;
>   		*freq_table = pxa27x_freq_table;
> +	} else {
> +		BUG();
>   	}
>   }
>   

---------------------------------------------------------------------
Intel Technology Poland sp. z o.o.
z siedziba w Gdansku
ul. Slowackiego 173
80-298 Gdansk

Sad Rejonowy Gdansk Polnoc w Gdansku, 
VII Wydzial Gospodarczy Krajowego Rejestru Sadowego, 
numer KRS 101882

NIP 957-07-52-316
Kapital zakladowy 200.000 zl

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.



From rjw at sisk.pl  Thu Apr 25 14:27:45 2013
From: rjw at sisk.pl (Rafael J. Wysocki)
Date: Thu, 25 Apr 2013 20:27:45 +0200
Subject: [PATCH] cpuidle: add maintainer entry
In-Reply-To: <CACRpkdaA8uG5jYyYTbuvzZNRr47EhWHFMLLz+jbiE3FPC1vjmA@mail.gmail.com>
References: <1366810463-17495-1-git-send-email-daniel.lezcano@linaro.org>
 <87k3nr50n4.fsf@linaro.org>
 <CACRpkdaA8uG5jYyYTbuvzZNRr47EhWHFMLLz+jbiE3FPC1vjmA@mail.gmail.com>
Message-ID: <9935265.yXMiRQV8Yo@vostro.rjw.lan>

On Thursday, April 25, 2013 02:09:11 PM Linus Walleij wrote:
> On Wed, Apr 24, 2013 at 6:55 PM, Kevin Hilman <khilman at linaro.org> wrote:
> > Rafael,
> >
> > Daniel Lezcano <daniel.lezcano at linaro.org> writes:
> >
> > [...]
> >
> >> diff --git a/MAINTAINERS b/MAINTAINERS
> >> index 61677c3..effa0f3 100644
> >> --- a/MAINTAINERS
> >> +++ b/MAINTAINERS
> >> @@ -2206,6 +2206,13 @@ S:     Maintained
> >>  F:   drivers/cpufreq/
> >>  F:   include/linux/cpufreq.h
> >>
> >> +CPUIDLE DRIVERS
> >> +M:   Rafael J. Wysocki <rjw at sisk.pl>
> >> +L:   linux-pm at vger.kernel.org
> >> +S:   Maintained
> >> +F:   drivers/cpuidle/*
> >> +F:   include/linux/cpuidle.h
> >
> > What do you think about having Daniel listed here as a co-maintainer?
> 
> I second that. He will bring useful embedded knowledge to the
> subsystem.

I'd still like to have a say about the core, but if Daniel is willing to
maintain ARM cpuidle drivers and all of the relevant ARM people agree with
that, that'll be great.

Thanks,
Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.


From peter.maydell at linaro.org  Thu Apr 25 14:19:44 2013
From: peter.maydell at linaro.org (Peter Maydell)
Date: Thu, 25 Apr 2013 19:19:44 +0100
Subject: [PATCH] ARM: KVM: Allow host virtual timer irq number to be
 different from guest virtual timer irq number
In-Reply-To: <CAEDV+gLKwrxxdoB9NDBLb7CSnXL1j=O7f=2Y_ftXmLfGtTBnbA@mail.gmail.com>
References: <1366879534-31578-1-git-send-email-anup.patel@linaro.org>
 <CAEDV+gLKwrxxdoB9NDBLb7CSnXL1j=O7f=2Y_ftXmLfGtTBnbA@mail.gmail.com>
Message-ID: <CAFEAcA_bPHkZX00ccUFg2mUXdmrui3XeBMg-rgxtsE_4-abeiA@mail.gmail.com>

On 25 April 2013 19:04, Christoffer Dall <cdall at cs.columbia.edu> wrote:
> I prefer not hard-coding this stuff in the kernel, but let user space
> decide this. If we have good technical arguments not to do that (such
> as knowing that this is always defined per-core and not for an SoC
> (ARM guys?) then at least the patch should lookup the target processor
> and set the irq number accordingly.

Well, this is all implementation-defined. The ARM ARM mandates
that the generic timers deliver a PPI, and that it must be the
same PPI for all processors in an MP implementation, but not which
PPI. The A15 and A7 happen to both be hardwired to ID27. You could
in theory design a core which let the SoC configure the virtual
timer ID (or let the guest arbitrarily program it, for that
matter, I suppose), though I'm not sure why you'd want to.

I think I'd take the simple approach of saying "the timer PPI
is a fixed property of the guest CPU" unless somebody actually
builds something where it isn't fixed... (for that CPU we
could then define it as a feature argument to KVM_ARM_VCPU_INIT).

thanks
-- PMM


From jason at lakedaemon.net  Thu Apr 25 14:27:32 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Thu, 25 Apr 2013 14:27:32 -0400
Subject: [PATCH 04/21] ARM: orion5x: include linux/cpu.h
In-Reply-To: <20130425173445.GD32497@titan.lakedaemon.net>
References: <1366910944-3033663-1-git-send-email-arnd@arndb.de>
 <1366910944-3033663-5-git-send-email-arnd@arndb.de>
 <20130425173445.GD32497@titan.lakedaemon.net>
Message-ID: <20130425182732.GE32497@titan.lakedaemon.net>

On Thu, Apr 25, 2013 at 01:34:45PM -0400, Jason Cooper wrote:
> On Thu, Apr 25, 2013 at 07:28:47PM +0200, Arnd Bergmann wrote:
> > The linux/cpu.h header is no longer implictly included in this
> > file, so we need to an #include statement to avoid this build
> > warning:
> > 
> > arch/arm/mach-orion5x/common.c:339:3: error: implicit declaration of function 'cpu_idle_poll_ctrl' [-Werror=implicit-function-declaration]
> > 
> > Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> > Cc: Jason Cooper <jason at lakedaemon.net>
> > Cc: Andrew Lunn <andrew at lunn.ch>
> > ---
> >  arch/arm/mach-orion5x/common.c | 1 +
> >  1 file changed, 1 insertion(+)
> 
> Acked-by: Jason Cooper <jason at lakedaemon.net>
> 
> I imagine it's easiest for you to take this through a branch you already
> have set up, so have it.

s/have it/have at it/  :)

thx,

Jason.


From sboyd at codeaurora.org  Thu Apr 25 14:31:27 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Thu, 25 Apr 2013 11:31:27 -0700
Subject: [PATCH/RESEND] ARM: arch_timer: Silence debug preempt warnings
In-Reply-To: <1366241178-16626-1-git-send-email-sboyd@codeaurora.org>
References: <1366241178-16626-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <5179767F.5030405@codeaurora.org>

On 04/17/13 16:26, Stephen Boyd wrote:
> Hot-plugging with CONFIG_DEBUG_PREEMPT=y on a device with arm
> architected timers causes a slew of "using smp_processor_id() in
> preemptible" warnings:
>
>   BUG: using smp_processor_id() in preemptible [00000000] code: sh/111
>   caller is arch_timer_cpu_notify+0x14/0xc8
>
> This happens because sometimes the cpu notifier,
> arch_timer_cpu_notify(), is called in preemptible context and
> other times in non-preemptible context but we use this_cpu_ptr()
> to retrieve the clockevent in all cases. We're only going to
> actually use the pointer in non-preemptible context though, so
> push the this_cpu_ptr() access down into the cases to force the
> checks to occur only in non-preemptible contexts.
>
> Cc: John Stultz <john.stultz at linaro.org>
> Cc: Thomas Gleixner <tglx at linutronix.de>
> Cc: Mark Rutland <mark.rutland at arm.com>
> Acked-by: Marc Zyngier <Marc.Zyngier at arm.com>
> Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
> ---
>
> Resending to arm-soc maintainers instead of timekeeping maintainers. Who
> maintains this driver?

Ping.

>
>  drivers/clocksource/arm_arch_timer.c | 10 ++++++----
>  1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
> index d7ad425..a65a710 100644
> --- a/drivers/clocksource/arm_arch_timer.c
> +++ b/drivers/clocksource/arm_arch_timer.c
> @@ -248,14 +248,16 @@ static void __cpuinit arch_timer_stop(struct clock_event_device *clk)
>  static int __cpuinit arch_timer_cpu_notify(struct notifier_block *self,
>  					   unsigned long action, void *hcpu)
>  {
> -	struct clock_event_device *evt = this_cpu_ptr(arch_timer_evt);
> -
> +	/*
> +	 * Grab cpu pointer in each case to avoid spurious
> +	 * preemptible warnings
> +	 */
>  	switch (action & ~CPU_TASKS_FROZEN) {
>  	case CPU_STARTING:
> -		arch_timer_setup(evt);
> +		arch_timer_setup(this_cpu_ptr(arch_timer_evt));
>  		break;
>  	case CPU_DYING:
> -		arch_timer_stop(evt);
> +		arch_timer_stop(this_cpu_ptr(arch_timer_evt));
>  		break;
>  	}
>  


-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Thu Apr 25 14:35:12 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Thu, 25 Apr 2013 11:35:12 -0700
Subject: [PATCHv2 1/4] Documentation: Add memory mapped ARM architected
 timer binding
In-Reply-To: <516C7231.6060305@codeaurora.org>
References: <1365812863-5367-1-git-send-email-sboyd@codeaurora.org>
 <1365812863-5367-2-git-send-email-sboyd@codeaurora.org>
 <516C6F12.5020208@gmail.com> <516C7231.6060305@codeaurora.org>
Message-ID: <51797760.4040906@codeaurora.org>

Rob,

Can I get your ack on this binding or do you think we need to change
something?

Thanks,
Stephen

On 04/15/13 14:33, Stephen Boyd wrote:
> On 04/15/13 14:20, Rob Herring wrote:
>> On Fri, Apr 12, 2013 at 7:27 PM, Stephen Boyd <sboyd at codeaurora.org> wrote:
>>> @@ -26,3 +30,52 @@ Example:
>>>                              <1 10 0xf08>;
>>>                 clock-frequency = <100000000>;
>>>         };
>>> +
>>> +** Memory mapped timer node properties
>>> +
>>> +- compatible : Should at least contain "arm,armv7-timer-mem".
>> Everything about this timer is architecturally defined? If not, let's
>> use a more specific name.
> I'm not sure I'm following you, but everything described here is part of
> the ARM definition. What would be a more specific name?
>
>>> +
>>> +- clock-frequency : The frequency of the main counter, in Hz. Optional.
>>> +
>>> +- reg : The control frame base address.
>>> +
>>> +Note that #address-cells, #size-cells, and ranges shall be present to ensure
>>> +the CPU can address a frame's registers.
>>> +
>>> +Frame:
>>> +
>>> +- frame-number: 0 to 7.
>> I'd really like to get rid of the frame numbers and sub-nodes. Is the
>> frame number significant to software?
> We need the frame number to read and write registers in the control
> frame (the first base in the parent node). We currently use it to
> determine if a frame has support for the virtual timer by reading the
> CNTTIDR (a register with 4 bits per frame describing capabilities). If
> we wanted to control access to the second view of a frame we would also
> need to configure the CNTPL0ACRn register that pertains to the frame
> we're controlling. Without a frame number we wouldn't know which
> register to write.
>
>>> +- interrupts : Interrupt list for physical and virtual timers in that order.
>>> +  The virtual timer interrupt is optional.
>> Is that optional per frame?
> Yes the virtual and physical timer interrupt is per-frame and the
> virtual interrupt is optional.
>


-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation



From stefano.stabellini at eu.citrix.com  Thu Apr 25 14:45:51 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Thu, 25 Apr 2013 19:45:51 +0100
Subject: [PATCH v4 2/7] xen/arm: SMP support
In-Reply-To: <1366909184.3142.0.camel@zakaz.uk.xensource.com>
References: <alpine.DEB.2.02.1304242012590.4180@kaball.uk.xensource.com>
 <1366831695-13214-2-git-send-email-stefano.stabellini@eu.citrix.com>
 <1366897221.20256.544.camel@zakaz.uk.xensource.com>
 <alpine.DEB.2.02.1304251503100.4180@kaball.uk.xensource.com>
 <1366909184.3142.0.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1304251945290.4180@kaball.uk.xensource.com>

On Thu, 25 Apr 2013, Ian Campbell wrote:
> > > > @@ -216,6 +245,8 @@ static int __init xen_guest_init(void)
> > > >  	 * is required to use VCPUOP_register_vcpu_info to place vcpu info
> > > >  	 * for secondary CPUs as they are brought up. */
> > > >  	per_cpu(xen_vcpu, 0) = &HYPERVISOR_shared_info->vcpu_info[0];
> > > > +	for_each_online_cpu(i)
> > > > +		xen_secondary_init(i);
> > > >  
> > > >  	gnttab_init();
> > > >  	if (!xen_initial_domain())
> > > [...]
> > > > @@ -244,7 +280,7 @@ static int __init xen_init_events(void)
> > > >  		return -EINVAL;
> > > >  	}
> > > >  
> > > > -	enable_percpu_irq(xen_events_irq, 0);
> > > > +	on_each_cpu(xen_percpu_enable_events, NULL, 0);
> > > 
> > > It feels like there ought to be some sort of per-cpu bringup callback
> > > which takes care of these dynamically. Maybe that doesn't matter until
> > > we get vcpu hotplug going?
> > 
> > I suspect there isn't one, considering that on_each_cpu is also used by 
> > kvm_vgic_hyp_init, kvm_timer_hyp_init and others.
> 
> Could we use cpu_notifiers for this?

cpu_notifiers are for cpu hotplug, not for secondary cpu bringup


From cdall at cs.columbia.edu  Thu Apr 25 14:51:19 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Thu, 25 Apr 2013 11:51:19 -0700
Subject: [PATCH] ARM: KVM: Allow host virtual timer irq number to be
 different from guest virtual timer irq number
In-Reply-To: <CAFEAcA_bPHkZX00ccUFg2mUXdmrui3XeBMg-rgxtsE_4-abeiA@mail.gmail.com>
References: <1366879534-31578-1-git-send-email-anup.patel@linaro.org>
 <CAEDV+gLKwrxxdoB9NDBLb7CSnXL1j=O7f=2Y_ftXmLfGtTBnbA@mail.gmail.com>
 <CAFEAcA_bPHkZX00ccUFg2mUXdmrui3XeBMg-rgxtsE_4-abeiA@mail.gmail.com>
Message-ID: <7818033767795756654@unknownmsgid>

On Apr 25, 2013, at 11:20 AM, Peter Maydell <peter.maydell at linaro.org> wrote:

> On 25 April 2013 19:04, Christoffer Dall <cdall at cs.columbia.edu> wrote:
>> I prefer not hard-coding this stuff in the kernel, but let user space
>> decide this. If we have good technical arguments not to do that (such
>> as knowing that this is always defined per-core and not for an SoC
>> (ARM guys?) then at least the patch should lookup the target processor
>> and set the irq number accordingly.
>
> Well, this is all implementation-defined. The ARM ARM mandates
> that the generic timers deliver a PPI, and that it must be the
> same PPI for all processors in an MP implementation, but not which
> PPI. The A15 and A7 happen to both be hardwired to ID27. You could
> in theory design a core which let the SoC configure the virtual
> timer ID (or let the guest arbitrarily program it, for that
> matter, I suppose), though I'm not sure why you'd want to.
>
> I think I'd take the simple approach of saying "the timer PPI
> is a fixed property of the guest CPU" unless somebody actually
> builds something where it isn't fixed... (for that CPU we
> could then define it as a feature argument to KVM_ARM_VCPU_INIT).
>

Ok, let's not bother with user space injection then, but instead of
hard defaulting to two specific cores, please make a switch statement
on the target CPU and log an error on init if it's an unknown core.


From robert.jarzmik at free.fr  Thu Apr 25 15:36:22 2013
From: robert.jarzmik at free.fr (Robert Jarzmik)
Date: Thu, 25 Apr 2013 21:36:22 +0200
Subject: gpio-pxa initcall level change and machine init breakage
References: <5172B398.7060706@newsguy.com>
 <CAD6h2NSRA9w7GZLQGgK-+TvEAsxwOHow5_26JyVUA6YQyj3OQg@mail.gmail.com>
 <517466F6.3000003@newsguy.com>
 <CAD6h2NSy0=3P-PHdCiJJQG_jvGaFnr7uex+Uxs=0F-VsUxtPWg@mail.gmail.com>
 <CACRpkdbk24kR75fanvXVAocnuozNq_=jWDSPHPCWhbZCOrN5_Q@mail.gmail.com>
 <5176E438.80800@newsguy.com>
 <CACRpkdYLCKKZZFi6Y-viPUvrwupJGzfxr3f20a1emp-9qE0YBg@mail.gmail.com>
Message-ID: <87ppxiz9l5.fsf@free.fr>

Linus Walleij <linus.walleij at linaro.org> writes:

> On Tue, Apr 23, 2013 at 9:42 PM, Mike Dunn <mikedunn at newsguy.com> wrote:
>
>> On a more general note... I'm surprised that gpiolib can not run earlier, for
>> something so low-level.
>
> Well I think the patch we're discussing is making it run less early, and it
> can actually run as arch_initcall() or similar if you wish (it's up to the
> driver).
>
> However that is beside the point, Haojian is still doing the right thing
> trying to push this to driver init (==module_init) level. The reason is
> that basically all hardware drivers should be initialized at this level
> because the other init levels are basically for other things and driver
> deps are just shoehorned into them.
>
> Instead of relying on things to be set up early one shall rely on
> deferred probe.
Hi Linus,

Even if that is the long term goal, and I agree with that goal, let me quote
Documentation/gpio.txt : "However, for spinlock-safe GPIOs it's OK to use them
before tasking is enabled, as part of early board setup.".

When gpio abstraction was written, it was assumed GPIO usage was usable in early
platform setup code. As this was granted, we (board maintainers) coded
accordingly.

Now this patch breaks boards. I disagree in having my board code broken without
notice. What I would find less intrusive would be to :
 (a) revert the patch
 (b) inform board maintainers that they must fix their board code (for example
 give them 1 window)
 (c) put back the patch. Board maintainers who did not amend their board
 code cannot say anymore they didn't know it. Board maintainers will also have
 time to rise objections if they think they cannot change their board code
 (which I do not believe is possible, but who knows ...)

Ah and change the Documentation too I think, if you want GPIO to be only usable
from device initcall level.

> Alas, it is not an easy change, and not expected to happen quickly
> or painlessly.
Sure, so let's do it in right order, shall we ?

Cheers.

-- 
Robert

PS: When I say "broken code", in the mioa701 case, my phone doesn't wakeup on
phone calls. Disturbing, isn't it ?


From stigge at antcom.de  Thu Apr 25 15:50:42 2013
From: stigge at antcom.de (Roland Stigge)
Date: Thu, 25 Apr 2013 21:50:42 +0200
Subject: [PATCH 19/21] USB: lpc32xx: ISP1301 needs USB_PHY
In-Reply-To: <1366910944-3033663-20-git-send-email-arnd@arndb.de>
References: <1366910944-3033663-1-git-send-email-arnd@arndb.de>
 <1366910944-3033663-20-git-send-email-arnd@arndb.de>
Message-ID: <51798912.4090108@antcom.de>

On 25/04/13 19:29, Arnd Bergmann wrote:
> The Kconfig entry for USB_LPC32XX unconditionally selects USB_ISP1301,
> which is now only visible when USB_PHY is also enabled.
> 
> This adds an appropriate dependency and enables USB_PHY in the msm
> defconfig, avoiding these build errors:
> 
> warning: (USB_LPC32XX) selects USB_ISP1301 which has unmet direct dependencies (USB_SUPPORT && USB_PHY && (USB || USB_GADGET) && I2C)
> drivers/built-in.o: In function `usb_hcd_nxp_probe':
> drivers/usb/host/ohci-nxp.c:224: undefined reference to `isp1301_get_client'
> drivers/built-in.o: In function `lpc32xx_udc_probe':
> drivers/usb/gadget/lpc32xx_udc.c:3071: undefined reference to `isp1301_get_client'
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Cc: linux-usb at vger.kernel.org
> Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
> Cc: Felipe Balbi <balbi at ti.com>
> Cc: Roland Stigge <stigge at antcom.de>

Tested-by: Roland Stigge <stigge at antcom.de>
Acked-by: Roland Stigge <stigge at antcom.de>

> ---
>  arch/arm/configs/lpc32xx_defconfig | 1 +
>  drivers/usb/gadget/Kconfig         | 1 +
>  2 files changed, 2 insertions(+)
> 
> diff --git a/arch/arm/configs/lpc32xx_defconfig b/arch/arm/configs/lpc32xx_defconfig
> index 8fee514..398a367 100644
> --- a/arch/arm/configs/lpc32xx_defconfig
> +++ b/arch/arm/configs/lpc32xx_defconfig
> @@ -146,6 +146,7 @@ CONFIG_SND_DEBUG_VERBOSE=y
>  # CONFIG_SND_SPI is not set
>  CONFIG_SND_SOC=y
>  CONFIG_USB=y
> +CONFIG_USB_PHY=y
>  CONFIG_USB_OHCI_HCD=y
>  CONFIG_USB_STORAGE=y
>  CONFIG_USB_GADGET=y
> diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
> index a61d981..f85b427 100644
> --- a/drivers/usb/gadget/Kconfig
> +++ b/drivers/usb/gadget/Kconfig
> @@ -144,6 +144,7 @@ config USB_AT91
>  config USB_LPC32XX
>  	tristate "LPC32XX USB Peripheral Controller"
>  	depends on ARCH_LPC32XX
> +	depends on USB_PHY
>  	select USB_ISP1301
>  	select USB_OTG_UTILS
>  	help



From edubezval at gmail.com  Thu Apr 25 16:07:56 2013
From: edubezval at gmail.com (edubezval at gmail.com)
Date: Thu, 25 Apr 2013 16:07:56 -0400
Subject: [PATCH 15/21] thermal: cooling: avoid uninitialied used gcc
 warning
In-Reply-To: <1366910944-3033663-16-git-send-email-arnd@arndb.de>
References: <1366910944-3033663-1-git-send-email-arnd@arndb.de>
 <1366910944-3033663-16-git-send-email-arnd@arndb.de>
Message-ID: <CAC-25o_bmrZZ9n10cBE=ewO7Yr+FmgP2JTYJNr1y=V_9BgcyXQ@mail.gmail.com>

Arnd,

On Thu, Apr 25, 2013 at 1:28 PM, Arnd Bergmann <arnd at arndb.de> wrote:
> The newly rewritten get_property() function causes a bogus warning
> from gcc-3.8, which cannot figure out that "level" is always
> initialized at the point where it gets evaluated:
>
> drivers/thermal/cpu_cooling.c: In function 'get_property':
> drivers/thermal/cpu_cooling.c:189:37: warning: 'level' may be used uninitialized in this function [-Wmaybe-uninitialized]
>    if (property == GET_FREQ && level == j) {
>                                      ^
>
> Slightly rearranging the code makes this more obvious and
> avoids the warning.
>
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Cc: Zhang Rui <rui.zhang at intel.com>
> Cc: Amit Daniel kachhap <amit.daniel at samsung.com>

Rui has merged a patch that removes this bogus compiler warning:
http://git.kernel.org/cgit/linux/kernel/git/rzhang/linux.git/commit/?h=next&id=4469b99743d296e24aefc5f8ed7df1bc9cfbbac8

Though, as not as elegant as your patch, it does the trick. :-)

> ---
>  drivers/thermal/cpu_cooling.c | 17 +++++++++--------
>  1 file changed, 9 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
> index 768b508..34878e6 100644
> --- a/drivers/thermal/cpu_cooling.c
> +++ b/drivers/thermal/cpu_cooling.c
> @@ -165,10 +165,6 @@ static int get_property(unsigned int cpu, unsigned long input,
>                 return 0;
>         }
>
> -       if (property == GET_FREQ)
> -               level = descend ? input : (max_level - input -1);
> -
> -
>         for (i = 0, j = 0; table[i].frequency != CPUFREQ_TABLE_END; i++) {
>                 /* ignore invalid entry */
>                 if (table[i].frequency == CPUFREQ_ENTRY_INVALID)
> @@ -186,10 +182,15 @@ static int get_property(unsigned int cpu, unsigned long input,
>                         *output = descend ? j : (max_level - j - 1);
>                         return 0;
>                 }
> -               if (property == GET_FREQ && level == j) {
> -                       /* get frequency by level */
> -                       *output = freq;
> -                       return 0;
> +
> +               if (property == GET_FREQ) {
> +                       level = descend ? input : (max_level - input -1);
> +
> +                       if (level == j) {
> +                               /* get frequency by level */
> +                               *output = freq;
> +                               return 0;
> +                       }
>                 }
>                 j++;
>         }
> --
> 1.8.1.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/



-- 
Eduardo Bezerra Valentin


From arnd at arndb.de  Thu Apr 25 17:09:03 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 25 Apr 2013 23:09:03 +0200
Subject: [PATCH 15/21] thermal: cooling: avoid uninitialied used gcc
 warning
In-Reply-To: <CAC-25o_bmrZZ9n10cBE=ewO7Yr+FmgP2JTYJNr1y=V_9BgcyXQ@mail.gmail.com>
References: <1366910944-3033663-1-git-send-email-arnd@arndb.de>
 <1366910944-3033663-16-git-send-email-arnd@arndb.de>
 <CAC-25o_bmrZZ9n10cBE=ewO7Yr+FmgP2JTYJNr1y=V_9BgcyXQ@mail.gmail.com>
Message-ID: <201304252309.03613.arnd@arndb.de>

On Thursday 25 April 2013, edubezval at gmail.com wrote:
> Rui has merged a patch that removes this bogus compiler warning:
> http://git.kernel.org/cgit/linux/kernel/git/rzhang/linux.git/commit/?h=next&amp;id=4469b99743d296e24aefc5f8ed7df1bc9cfbbac8
> 
> Though, as not as elegant as your patch, it does the trick. :-)

Ok, works for me.

Looking at the patch however tells me that it has the potential to hide real
bugs if the code is ever changed to actually do an uninitialized access.
It's not very likely in this case, but I generally recommend not to add
any variables at declaration time unless the initialization is to a
meaningful value that the code later uses.

	Arnd


From arnd at arndb.de  Thu Apr 25 17:09:50 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 25 Apr 2013 23:09:50 +0200
Subject: [PATCH 14/21] cpufreq: pxa2xx: initialize variables
In-Reply-To: <5179726E.9020003@intel.com>
References: <1366910944-3033663-1-git-send-email-arnd@arndb.de>
 <1366910944-3033663-15-git-send-email-arnd@arndb.de>
 <5179726E.9020003@intel.com>
Message-ID: <201304252309.50192.arnd@arndb.de>

On Thursday 25 April 2013, Rafael J. Wysocki wrote:
> On 4/25/2013 7:28 PM, Arnd Bergmann wrote:
> > Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> > Cc: Viresh Kumar <viresh.kumar at linaro.org>
> > Cc: Rafael J. Wysocki <rafael.j.wysocki at intel.com>
> 
> OK, applied.
> 
> Can you please CC future cpufreq changes to linux-pm at vger.kernel.org?  
> That'd make the handling of them much easier.

Sure, I'll try to rembember next time. Thanks for applying it
anyway.

	Arnd


From arnd at arndb.de  Thu Apr 25 17:12:59 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 25 Apr 2013 23:12:59 +0200
Subject: [PATCH 18/21] USB: ehci-msm: USB_MSM_OTG needs USB_PHY
In-Reply-To: <20130425175950.GA14654@kroah.com>
References: <1366910944-3033663-1-git-send-email-arnd@arndb.de>
 <1366910944-3033663-19-git-send-email-arnd@arndb.de>
 <20130425175950.GA14654@kroah.com>
Message-ID: <201304252312.59822.arnd@arndb.de>

On Thursday 25 April 2013, Greg Kroah-Hartman wrote:
> > diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
> > index c558472..de94f26 100644
> > --- a/drivers/usb/host/Kconfig
> > +++ b/drivers/usb/host/Kconfig
> > @@ -188,6 +188,7 @@ config USB_EHCI_HCD_AT91
> >  config USB_EHCI_MSM
> >       tristate "Support for Qualcomm QSD/MSM on-chip EHCI USB controller"
> >       depends on ARCH_MSM
> > +     depends on USB_PHY
> >       select USB_EHCI_ROOT_HUB_TT
> >       select USB_MSM_OTG
> >       ---help---
> 
> But this does, and I'm guessing that it's the more important part, so
> I'll just edit it and only take this hunk, ok?

Ok, thanks! Sorry for bothering you with the hand editing. I'll apply
the defconfig change to arm-soc then.

	Arnd


From linus.walleij at linaro.org  Thu Apr 25 17:22:13 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Apr 2013 23:22:13 +0200
Subject: gpio-pxa initcall level change and machine init breakage
In-Reply-To: <87ppxiz9l5.fsf@free.fr>
References: <5172B398.7060706@newsguy.com>
 <CAD6h2NSRA9w7GZLQGgK-+TvEAsxwOHow5_26JyVUA6YQyj3OQg@mail.gmail.com>
 <517466F6.3000003@newsguy.com>
 <CAD6h2NSy0=3P-PHdCiJJQG_jvGaFnr7uex+Uxs=0F-VsUxtPWg@mail.gmail.com>
 <CACRpkdbk24kR75fanvXVAocnuozNq_=jWDSPHPCWhbZCOrN5_Q@mail.gmail.com>
 <5176E438.80800@newsguy.com>
 <CACRpkdYLCKKZZFi6Y-viPUvrwupJGzfxr3f20a1emp-9qE0YBg@mail.gmail.com>
 <87ppxiz9l5.fsf@free.fr>
Message-ID: <CACRpkdYEi7i_kSuUy4dBW-tE4BxifJY5wFdYVyLe6La5=HwEmg@mail.gmail.com>

On Thu, Apr 25, 2013 at 9:36 PM, Robert Jarzmik <robert.jarzmik at free.fr> wrote:

> Now this patch breaks boards. I disagree in having my board code broken without
> notice. What I would find less intrusive would be to :
>  (a) revert the patch

This was done by pull request to Torvalds yesterday ...

>  (b) inform board maintainers that they must fix their board code (for example
>  give them 1 window)
>  (c) put back the patch. Board maintainers who did not amend their board
>  code cannot say anymore they didn't know it. Board maintainers will also have
>  time to rise objections if they think they cannot change their board code
>  (which I do not believe is possible, but who knows ...)

So when it comes to the PXA there is maybe this list of things that
would be nice to change, and this is likely on top of it ... moving the
PXA machines over to device tree would be more important if people
who like them want them so stay around, because non-device tree
platforms will at some point become deprecated, and fixing the platforms
to support device tree will inevitably lead to this problem being fixed
as well.

Yours,
Linus Walleij


From linus.walleij at linaro.org  Thu Apr 25 17:39:18 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Apr 2013 23:39:18 +0200
Subject: [PATCH] pinctrl: document the "GPIO mode" pitfall
In-Reply-To: <2408684.1bsjMDDzMu@avalon>
References: <1363345636-2006-1-git-send-email-linus.walleij@stericsson.com>
 <2408684.1bsjMDDzMu@avalon>
Message-ID: <CACRpkdag=YTeQH=VjW4fQ+G94REWeURhC=ErJxjmSUuP=pKYbA@mail.gmail.com>

On Tue, Apr 23, 2013 at 3:33 PM, Laurent Pinchart
<laurent.pinchart at ideasonboard.com> wrote:

>> +And your machine configuration may look like this:
>> +--------------------------------------------------
>> +
>> +static unsigned long uart_default_mode[] = {
>> +    PIN_CONF_PACKED(PIN_CONFIG_DRIVE_PUSH_PULL, 0),
>> +};
>> +
>> +static unsigned long uart_sleep_mode[] = {
>> +    PIN_CONF_PACKED(PIN_CONFIG_OUTPUT, 0),
>> +};
>
> I'm having a bit of trouble with PIN_CONFIG_DRIVE_PUSH_PULL and
> PIN_CONFIG_OUTPUT. Strictly speaking, when configured in output mode, the pin
> will be in a push-pull configuration.

For your system or for any system? Open drain, open source are also
output modes, and none of them are push-pull.

> Could you clarify the exact scope of the
> two configuration parameters ?

PIN_CONFIG_OUTPUT is left a bit unspecified, but here the
idea was a passive drive, like just connecting the pin to
VDD or GND without any driver stage at all. Maybe I should
patch the documentation since we seem to be the only
user?

In the above case (which is derived from the ABx500) I think what is
happening is that the pin is connected to ground during sleep,
without any enabled driver stages, which saves a lot of power,
since you do not need to bias the totempole during
sleep in that way.

Yours,
Linus Walleij


From robherring2 at gmail.com  Thu Apr 25 17:47:52 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Thu, 25 Apr 2013 16:47:52 -0500
Subject: [PATCHv2 1/4] Documentation: Add memory mapped ARM architected
 timer binding
In-Reply-To: <516C7231.6060305@codeaurora.org>
References: <1365812863-5367-1-git-send-email-sboyd@codeaurora.org>
 <1365812863-5367-2-git-send-email-sboyd@codeaurora.org>
 <516C6F12.5020208@gmail.com> <516C7231.6060305@codeaurora.org>
Message-ID: <5179A488.5050102@gmail.com>

On 04/15/2013 04:33 PM, Stephen Boyd wrote:
> On 04/15/13 14:20, Rob Herring wrote:
>> On Fri, Apr 12, 2013 at 7:27 PM, Stephen Boyd <sboyd at codeaurora.org> wrote:
>>> @@ -26,3 +30,52 @@ Example:
>>>                              <1 10 0xf08>;
>>>                 clock-frequency = <100000000>;
>>>         };
>>> +
>>> +** Memory mapped timer node properties
>>> +
>>> +- compatible : Should at least contain "arm,armv7-timer-mem".
>> Everything about this timer is architecturally defined? If not, let's
>> use a more specific name.
> 
> I'm not sure I'm following you, but everything described here is part of
> the ARM definition. What would be a more specific name?

Something that corresponds to the particular implementation like
cortex-a15 (obviously not an example that has this). I'm fine with
leaving this for now, but would like to see that added when specific SOC
dts are added. Better to be specific in case we need to use it for
something like errata work-arounds. Of course we haven't done that so
far with the arch timer bindings...

>>> +
>>> +- clock-frequency : The frequency of the main counter, in Hz. Optional.
>>> +
>>> +- reg : The control frame base address.
>>> +
>>> +Note that #address-cells, #size-cells, and ranges shall be present to ensure
>>> +the CPU can address a frame's registers.
>>> +
>>> +Frame:
>>> +
>>> +- frame-number: 0 to 7.
>> I'd really like to get rid of the frame numbers and sub-nodes. Is the
>> frame number significant to software?
> 
> We need the frame number to read and write registers in the control
> frame (the first base in the parent node). We currently use it to
> determine if a frame has support for the virtual timer by reading the
> CNTTIDR (a register with 4 bits per frame describing capabilities). If
> we wanted to control access to the second view of a frame we would also
> need to configure the CNTPL0ACRn register that pertains to the frame
> we're controlling. Without a frame number we wouldn't know which
> register to write.

I've gone thru the memory mapped part of the spec now, so I think I
understand things better. I see how the frame number is needed, but...

The control base is only accessible in secure or hyp mode. How does a
guest know that it is a guest and can't map the control base? Seems like
we need to allow a subset of the binding that is just a reg and
interrupts properties without the frame sub nodes.

Rob

> 
>>
>>> +- interrupts : Interrupt list for physical and virtual timers in that order.
>>> +  The virtual timer interrupt is optional.
>> Is that optional per frame?
> 
> Yes the virtual and physical timer interrupt is per-frame and the
> virtual interrupt is optional.
> 



From s-anna at ti.com  Thu Apr 25 18:29:03 2013
From: s-anna at ti.com (Suman Anna)
Date: Thu, 25 Apr 2013 17:29:03 -0500
Subject: [PATCHv3 00/14] drivers: mailbox: framework creation
In-Reply-To: <CAJe_ZhfDZzq+DzA9XDF3PWFUmwcZnDy-mhE4hLNHmf+V4GhOxw@mail.gmail.com>
References: <1363145021-14339-1-git-send-email-s-anna@ti.com>
 <CABb+yY0RYkVeo2Sb4WsDJY0jf17488FEz0d2CB994eQaSOEsVg@mail.gmail.com>
 <37C860A02101E749A747FA2D3C1E3C504A5DF7@DLEE11.ent.ti.com>
 <CABb+yY1x4x_A+QtGG9ohsLPgs8c3nEVnd_ExJBGOOR8=6YLPFA@mail.gmail.com>
 <37C860A02101E749A747FA2D3C1E3C504A63B4@DLEE11.ent.ti.com>
 <CAJe_ZhehnniZd730jjiOLrHozq8TOJZgFYLqUe4KqgBiQEu8PA@mail.gmail.com>
 <51779304.4040003@st.com>
 <CAJe_ZhdZv5LW6kdwyPtJe69mfW6t=WQ4OJnG2H4sUhibattN2A@mail.gmail.com>
 <517867E1.7050301@ti.com>
 <CAJe_ZhfDZzq+DzA9XDF3PWFUmwcZnDy-mhE4hLNHmf+V4GhOxw@mail.gmail.com>
Message-ID: <5179AE2F.3040403@ti.com>

Jassi,

On 04/25/2013 12:20 AM, Jassi Brar wrote:
> On 25 April 2013 04:46, Suman Anna <s-anna at ti.com> wrote:
>> On 04/24/2013 03:56 AM, Jassi Brar wrote:
>>
> 
>> I think there are two things here - one is what the client needs to do
>> upon sending/receiving a message, and the other is what the send API or
>> the mailbox controller should do when a client tried to send a message
>> and the controller's shared message/transport is not free (irrespective
>> of the atomic or non-atomic context). The kfifos in the common driver
>> code are currently solving the latter problem. The current send API
>> directly uses the controller to send if it is free, and uses buffering
>> only when it is busy. But, I see your point that this should should be
>> the responsibility of the specific controller, or even a property of the
>> specific mailbox belonging to that controller. This direction would put
>> most of the onus on the specific controller drivers, and probably the
>> main API would be very simple. Another factor / attribute to consider is
>> that a given mailbox may be sharable or exclusive, things are simple if
>> it is exclusive to a client driver.
>>
> I never suggested we don't use buffering. I too believe the API should
> buffer requests but also that it should still do atomic callbacks. The
> impact on implementation would be that the queue buffer can not grow
> at runtime. But that should be fine because a reasonable size (say 10
> or even 50) could be chosen and we allow submission of requests from
> tx_done callback.

Yeah, even the current kfifo approach doesn't grow the queue buffer at
runtime, and the size of the kfifo is determined at driver init time
based on the controller. If the queue is also full, then you fail
tranmitting right away. OK, I thought you didn't want buffering, if that
is not the case, then the buffering should be within the main driver
code, like it is now, but configurable based on the controller or
mailbox properties. If it is present in individual controller drivers,
then we would be duplicating stuff. Are you envisioning that this be
left to the individual controllers?

> 
>>
>> We are talking two fundamentally different usecases/needs here,
>> depending on the type of the controller. You seem to be coming from a
>> usecase where the client driver needs to know when every message is
>> transmitted (from an atomic context, it is a moot point since either you
>> are successful or not when transmitting).
>>
> I am afraid you are confusing the meaning of 'atomic context' here.
> atomic context doesn't mean instant transmission of data, but that the
> API calls could be made from even atomic context and that the client &
> controller can't sleep in callbacks from the API. So it's not moot.

I understood the atomic context, and the question is about the behavior
of the '.tx_done' callback when sending from atomic context. Is there
such a usecase/need for you in that you want to send a response back
from an atomic context, yet get a callback?

> 
>> The remote
>> has to ack before it can be shutdown. I would imagine that getting a
>> .tx_done on a particular message is not good enough to know that the
>> remote is ready for shutdown. I can imagine it to be useful where there
>> is some inherent knowledge that the client needs to proceed with the
>> next steps when a message is sent.
>>
> Of course we are not specifying how the mailbox signals are
> interpreted by the remote. It should suffice just to realize that
> there exists genuine requirement for a client to know when its message
> was received by the remote.
> 
>> That said, we need to go with the
>> stricter one.
>>
> Great, that we agree.
> 
>> My only concern here is that if there can be multiple
>> clients for a particular mailbox/controller, then all the clients would
>> have to have an agreement on the controller packet type, and the clients
>> would mostly have to include the standard mailbox.h as well as a
>> controller-specific header.
>>
> It's the controller driver that actually puts the data on the bus. So
> only it should define the format in which it accepts data from the
> clients. Every client should simply populate the packet structure
> defined in  my_lovely_controller.h and pass on the struct pointer to
> the controller driver via API.
> No negotiations for the driver seat among passengers :)

OK, I was trying to avoid including my_lovely_controller.h and only
include the standard .h file as a client user, the client would anyway
need to have the intrinsic knowledge of the packet structure. And if you
were to do buffering in the common driver code, you would need the size
field outside. The void *msg packet structure would still be an
understanding between the client and the controller. So, it is a
tradeoff between just using void * and leave the buffering to controller
driver (potential duplication) & using a size and void *, along with
buffering in common driver code.

> 
>> Overall, I see it coming down to following points:
>> 1. Calling contexts: Atomic & non-atomic contexts, with the latter
>> becoming an extension of the atomic case. I guess this mainly goes with
>> the controller functional integration - whether it is used for
>> non-urgent messaging or h/w controller command messages (like PM
>> usecases?) where .tx_done is relevant.
>>
> Urgency or not is a business of the client driver. The API and the
> controller driver should not delay things more than absolute
> necessary.
> .tx_done is not about urgency but about h/w provision of 'ack'.
> 
>> 2. Behavior of the API or controller driver if the controller transport
>> is busy.
> I think we both want requests buffered in the API.
> 
>> 3. Shareable/exclusive nature of a mailbox. If it is shareable, then
>> duplicating the behavior between clients is not worth it, and this
>> should be absorbed into the respective controller driver.
>>
> I think the mailbox should be exclusively held by a client. That makes
> many things simpler. Also remote firmwares won't be always robust
> enough to handle commands from different subsystems intermixed. The
> API only has to make sure the mailbox_get/put operations are very
> thin.

This might be the case for specific remotes where we expect only one
client driver to be responsible for talking to it, but for generic
offloading, you do not want to have this restriction. You do not want
peer clients to go through a single main client, as the latencies or the
infrastructure imposed by the main client may not be suitable for the
other clients. The stricter usecase here would be the shareable mailbox,
and if it is exclusive, as dictated by a controller or device property,
then so be it and things would get simplified for that controller/device.

regards
Suman


From akpm at linux-foundation.org  Thu Apr 25 18:43:56 2013
From: akpm at linux-foundation.org (Andrew Morton)
Date: Thu, 25 Apr 2013 15:43:56 -0700
Subject: [PATCH v3 -next 4/5] x86: Add support for LZ4-compressed kernel
In-Reply-To: <20130306063738.GB4979@Corona>
References: <1362484056-9778-1-git-send-email-kyungsik.lee@lge.com>
 <1362484056-9778-5-git-send-email-kyungsik.lee@lge.com>
 <18eb6ca7-6993-40e9-a58d-116e1f6c37f6@email.android.com>
 <20130306063738.GB4979@Corona>
Message-ID: <20130425154356.4498719b15ccff41aaec0762@linux-foundation.org>

On Wed, 6 Mar 2013 15:37:38 +0900 Kyungsik Lee <kyungsik.lee at lge.com> wrote:

> On Tue, Mar 05, 2013 at 08:13:38AM -0800, H. Peter Anvin wrote:
> > Please add the new magic to Documentation/x86/boot.txt as well.
> 
> Ok, I will update it as soon as the patch set is stabilized.

It's been six weeks.  Please send the update asap.


From sboyd at codeaurora.org  Thu Apr 25 18:48:18 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Thu, 25 Apr 2013 15:48:18 -0700
Subject: [PATCHv2 1/4] Documentation: Add memory mapped ARM architected
 timer binding
In-Reply-To: <5179A488.5050102@gmail.com>
References: <1365812863-5367-1-git-send-email-sboyd@codeaurora.org>
 <1365812863-5367-2-git-send-email-sboyd@codeaurora.org>
 <516C6F12.5020208@gmail.com> <516C7231.6060305@codeaurora.org>
 <5179A488.5050102@gmail.com>
Message-ID: <5179B2B2.8000201@codeaurora.org>

On 04/25/13 14:47, Rob Herring wrote:
> On 04/15/2013 04:33 PM, Stephen Boyd wrote:
>> On 04/15/13 14:20, Rob Herring wrote:
>>> On Fri, Apr 12, 2013 at 7:27 PM, Stephen Boyd <sboyd at codeaurora.org> wrote:
>>>> @@ -26,3 +30,52 @@ Example:
>>>>                              <1 10 0xf08>;
>>>>                 clock-frequency = <100000000>;
>>>>         };
>>>> +
>>>> +** Memory mapped timer node properties
>>>> +
>>>> +- compatible : Should at least contain "arm,armv7-timer-mem".
>>> Everything about this timer is architecturally defined? If not, let's
>>> use a more specific name.
>> I'm not sure I'm following you, but everything described here is part of
>> the ARM definition. What would be a more specific name?
> Something that corresponds to the particular implementation like
> cortex-a15 (obviously not an example that has this). I'm fine with
> leaving this for now, but would like to see that added when specific SOC
> dts are added. Better to be specific in case we need to use it for
> something like errata work-arounds. Of course we haven't done that so
> far with the arch timer bindings...

Agreed. I'm under the impression that most of our compatible fields
should be more specific than they currently are so we can workaround hw
bugs like you say. Perhaps the catch all generic one should just be
"arm,arm-timer-mem" since it isn't tied to any particular CPU type?

>
>>>> +
>>>> +- clock-frequency : The frequency of the main counter, in Hz. Optional.
>>>> +
>>>> +- reg : The control frame base address.
>>>> +
>>>> +Note that #address-cells, #size-cells, and ranges shall be present to ensure
>>>> +the CPU can address a frame's registers.
>>>> +
>>>> +Frame:
>>>> +
>>>> +- frame-number: 0 to 7.
>>> I'd really like to get rid of the frame numbers and sub-nodes. Is the
>>> frame number significant to software?
>> We need the frame number to read and write registers in the control
>> frame (the first base in the parent node). We currently use it to
>> determine if a frame has support for the virtual timer by reading the
>> CNTTIDR (a register with 4 bits per frame describing capabilities). If
>> we wanted to control access to the second view of a frame we would also
>> need to configure the CNTPL0ACRn register that pertains to the frame
>> we're controlling. Without a frame number we wouldn't know which
>> register to write.
> I've gone thru the memory mapped part of the spec now, so I think I
> understand things better. I see how the frame number is needed, but...
>
> The control base is only accessible in secure or hyp mode. How does a
> guest know that it is a guest and can't map the control base? Seems like
> we need to allow a subset of the binding that is just a reg and
> interrupts properties without the frame sub nodes.

I don't see that part. My understanding is that the control base is
accessible in non-secure mode and by the guests. There are certain
registers within that base that are only accessible in secure mode
though: CNTFRQ and CNTNSAR. Also some registers are configurable:
CNTACRn and CNTVOFFN. CNTVOFFN is only accessible in the hypervisor.

We don't really care about CNTFRQ because it's duplicated into each
view. We do care about CNTNSAR. Luckily the spec "just works" there in
the sense that we can use CNTTIDR in conjunction with CNTACRn and
determine if we have access to a frame we're interested in if the
CNTTIDR bits say the frame is present and the CNTACRn register says we
can access it. If not then it must be locked down for secure users.

Unfortunately hardware doesn't have a way to say that a particular frame
is reserved for the hypervisor or the guest kernel/userspace. We need
some help from software, so we have the status property express that a
particular frame is available. We have to assume the DT is going to be
different depending on if you're the hypervisor or the guest. That's a
valid assumption right? Otherwise I hope we can do some trapping of the
guest's mapping to the control base and then rewrite what they read so
that they only see the frame that we want to be available to them.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation



From robherring2 at gmail.com  Thu Apr 25 19:06:21 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Thu, 25 Apr 2013 18:06:21 -0500
Subject: [PATCHv2 1/4] Documentation: Add memory mapped ARM architected
 timer binding
In-Reply-To: <5179B2B2.8000201@codeaurora.org>
References: <1365812863-5367-1-git-send-email-sboyd@codeaurora.org>
 <1365812863-5367-2-git-send-email-sboyd@codeaurora.org>
 <516C6F12.5020208@gmail.com> <516C7231.6060305@codeaurora.org>
 <5179A488.5050102@gmail.com> <5179B2B2.8000201@codeaurora.org>
Message-ID: <5179B6ED.9000301@gmail.com>

On 04/25/2013 05:48 PM, Stephen Boyd wrote:
> On 04/25/13 14:47, Rob Herring wrote:
>> On 04/15/2013 04:33 PM, Stephen Boyd wrote:
>>> On 04/15/13 14:20, Rob Herring wrote:
>>>> On Fri, Apr 12, 2013 at 7:27 PM, Stephen Boyd <sboyd at codeaurora.org> wrote:
>>>>> @@ -26,3 +30,52 @@ Example:
>>>>>                              <1 10 0xf08>;
>>>>>                 clock-frequency = <100000000>;
>>>>>         };
>>>>> +
>>>>> +** Memory mapped timer node properties
>>>>> +
>>>>> +- compatible : Should at least contain "arm,armv7-timer-mem".
>>>> Everything about this timer is architecturally defined? If not, let's
>>>> use a more specific name.
>>> I'm not sure I'm following you, but everything described here is part of
>>> the ARM definition. What would be a more specific name?
>> Something that corresponds to the particular implementation like
>> cortex-a15 (obviously not an example that has this). I'm fine with
>> leaving this for now, but would like to see that added when specific SOC
>> dts are added. Better to be specific in case we need to use it for
>> something like errata work-arounds. Of course we haven't done that so
>> far with the arch timer bindings...
> 
> Agreed. I'm under the impression that most of our compatible fields
> should be more specific than they currently are so we can workaround hw
> bugs like you say. Perhaps the catch all generic one should just be
> "arm,arm-timer-mem" since it isn't tied to any particular CPU type?
> 
>>
>>>>> +
>>>>> +- clock-frequency : The frequency of the main counter, in Hz. Optional.
>>>>> +
>>>>> +- reg : The control frame base address.
>>>>> +
>>>>> +Note that #address-cells, #size-cells, and ranges shall be present to ensure
>>>>> +the CPU can address a frame's registers.
>>>>> +
>>>>> +Frame:
>>>>> +
>>>>> +- frame-number: 0 to 7.
>>>> I'd really like to get rid of the frame numbers and sub-nodes. Is the
>>>> frame number significant to software?
>>> We need the frame number to read and write registers in the control
>>> frame (the first base in the parent node). We currently use it to
>>> determine if a frame has support for the virtual timer by reading the
>>> CNTTIDR (a register with 4 bits per frame describing capabilities). If
>>> we wanted to control access to the second view of a frame we would also
>>> need to configure the CNTPL0ACRn register that pertains to the frame
>>> we're controlling. Without a frame number we wouldn't know which
>>> register to write.
>> I've gone thru the memory mapped part of the spec now, so I think I
>> understand things better. I see how the frame number is needed, but...
>>
>> The control base is only accessible in secure or hyp mode. How does a
>> guest know that it is a guest and can't map the control base? Seems like
>> we need to allow a subset of the binding that is just a reg and
>> interrupts properties without the frame sub nodes.
> 
> I don't see that part. My understanding is that the control base is
> accessible in non-secure mode and by the guests. There are certain
> registers within that base that are only accessible in secure mode
> though: CNTFRQ and CNTNSAR. Also some registers are configurable:
> CNTACRn and CNTVOFFN. CNTVOFFN is only accessible in the hypervisor.

The example is section E.8 seems to say otherwise. Perhaps Mark R can
comment further.

> We don't really care about CNTFRQ because it's duplicated into each
> view. We do care about CNTNSAR. Luckily the spec "just works" there in
> the sense that we can use CNTTIDR in conjunction with CNTACRn and
> determine if we have access to a frame we're interested in if the
> CNTTIDR bits say the frame is present and the CNTACRn register says we
> can access it. If not then it must be locked down for secure users.
> 
> Unfortunately hardware doesn't have a way to say that a particular frame
> is reserved for the hypervisor or the guest kernel/userspace. We need
> some help from software, so we have the status property express that a
> particular frame is available. We have to assume the DT is going to be
> different depending on if you're the hypervisor or the guest. That's a
> valid assumption right? Otherwise I hope we can do some trapping of the
> guest's mapping to the control base and then rewrite what they read so
> that they only see the frame that we want to be available to them.

Yeah, I believe the only way to prevent access within non-secure world
is with the MMU. So I guess the example is just policy that the
hypervisor would/may not create a stage2 mapping. You still have the
same issue that the guest should not be passed the control base. You
could make the reg property optional, but then what do you do with the
node name?

Certainly the guest dtb will be different.

Rob



From laurent.pinchart at ideasonboard.com  Thu Apr 25 19:15:09 2013
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Fri, 26 Apr 2013 01:15:09 +0200
Subject: [PATCH] pinctrl: document the "GPIO mode" pitfall
In-Reply-To: <CACRpkdag=YTeQH=VjW4fQ+G94REWeURhC=ErJxjmSUuP=pKYbA@mail.gmail.com>
References: <1363345636-2006-1-git-send-email-linus.walleij@stericsson.com>
 <2408684.1bsjMDDzMu@avalon>
 <CACRpkdag=YTeQH=VjW4fQ+G94REWeURhC=ErJxjmSUuP=pKYbA@mail.gmail.com>
Message-ID: <1761651.lXztZzrj1S@avalon>

Hi Linus,

On Thursday 25 April 2013 23:39:18 Linus Walleij wrote:
> On Tue, Apr 23, 2013 at 3:33 PM, Laurent Pinchart wrote:
> >> +And your machine configuration may look like this:
> >> +--------------------------------------------------
> >> +
> >> +static unsigned long uart_default_mode[] = {
> >> +    PIN_CONF_PACKED(PIN_CONFIG_DRIVE_PUSH_PULL, 0),
> >> +};
> >> +
> >> +static unsigned long uart_sleep_mode[] = {
> >> +    PIN_CONF_PACKED(PIN_CONFIG_OUTPUT, 0),
> >> +};
> > 
> > I'm having a bit of trouble with PIN_CONFIG_DRIVE_PUSH_PULL and
> > PIN_CONFIG_OUTPUT. Strictly speaking, when configured in output mode, the
> > pin will be in a push-pull configuration.
> 
> For your system or for any system? Open drain, open source are also
> output modes, and none of them are push-pull.

Indeed. I was actually thinking about the opposite, push-pull is output.

> > Could you clarify the exact scope of the two configuration parameters ?
> 
> PIN_CONFIG_OUTPUT is left a bit unspecified, but here the idea was a passive
> drive, like just connecting the pin to VDD or GND without any driver stage
> at all.

Isn't that a driver stage ? :-)

> Maybe I should patch the documentation since we seem to be the only user?
> 
> In the above case (which is derived from the ABx500) I think what is
> happening is that the pin is connected to ground during sleep, without any
> enabled driver stages, which saves a lot of power, since you do not need to
> bias the totempole during sleep in that way.

Right. What is unclear to me is the interaction between OUTPUT and DRIVE_*. 
That's the part I would like to see clarified. Does DRIVE_* imply that the pin 
is driven by the selected function, and OUTPUT imply that the pin is driven to 
a fixed level ? If so, how do you configure the drive type of a pin that will 
be used through the GPIO API ? What about cases where I want to drive the pin 
to a fixed level in a non low-power output mode (for instance because I need 
more current that what the low-power output mode provides) ?

-- 
Regards,

Laurent Pinchart



From sboyd at codeaurora.org  Thu Apr 25 19:25:52 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Thu, 25 Apr 2013 16:25:52 -0700
Subject: [PATCHv2 1/4] Documentation: Add memory mapped ARM architected
 timer binding
In-Reply-To: <5179B6ED.9000301@gmail.com>
References: <1365812863-5367-1-git-send-email-sboyd@codeaurora.org>
 <1365812863-5367-2-git-send-email-sboyd@codeaurora.org>
 <516C6F12.5020208@gmail.com> <516C7231.6060305@codeaurora.org>
 <5179A488.5050102@gmail.com> <5179B2B2.8000201@codeaurora.org>
 <5179B6ED.9000301@gmail.com>
Message-ID: <5179BB80.9060405@codeaurora.org>

On 04/25/13 16:06, Rob Herring wrote:
> On 04/25/2013 05:48 PM, Stephen Boyd wrote:
>
>> We don't really care about CNTFRQ because it's duplicated into each
>> view. We do care about CNTNSAR. Luckily the spec "just works" there in
>> the sense that we can use CNTTIDR in conjunction with CNTACRn and
>> determine if we have access to a frame we're interested in if the
>> CNTTIDR bits say the frame is present and the CNTACRn register says we
>> can access it. If not then it must be locked down for secure users.
>>
>> Unfortunately hardware doesn't have a way to say that a particular frame
>> is reserved for the hypervisor or the guest kernel/userspace. We need
>> some help from software, so we have the status property express that a
>> particular frame is available. We have to assume the DT is going to be
>> different depending on if you're the hypervisor or the guest. That's a
>> valid assumption right? Otherwise I hope we can do some trapping of the
>> guest's mapping to the control base and then rewrite what they read so
>> that they only see the frame that we want to be available to them.
> Yeah, I believe the only way to prevent access within non-secure world
> is with the MMU. So I guess the example is just policy that the
> hypervisor would/may not create a stage2 mapping. You still have the
> same issue that the guest should not be passed the control base. You
> could make the reg property optional, but then what do you do with the
> node name?

I don't follow. Why shouldn't we tell the guest about the hardware
that's there? Shouldn't they be able to safely assume they can access
the control base just like a non-guest kernel running in PL1 would be
able to?

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation



From andy.green at linaro.org  Thu Apr 25 19:51:35 2013
From: andy.green at linaro.org (Andy Green)
Date: Fri, 26 Apr 2013 07:51:35 +0800
Subject: [PATCHv3 00/14] drivers: mailbox: framework creation
In-Reply-To: <5179AE2F.3040403@ti.com>
References: <1363145021-14339-1-git-send-email-s-anna@ti.com>
 <CABb+yY0RYkVeo2Sb4WsDJY0jf17488FEz0d2CB994eQaSOEsVg@mail.gmail.com>
 <37C860A02101E749A747FA2D3C1E3C504A5DF7@DLEE11.ent.ti.com>
 <CABb+yY1x4x_A+QtGG9ohsLPgs8c3nEVnd_ExJBGOOR8=6YLPFA@mail.gmail.com>
 <37C860A02101E749A747FA2D3C1E3C504A63B4@DLEE11.ent.ti.com>
 <CAJe_ZhehnniZd730jjiOLrHozq8TOJZgFYLqUe4KqgBiQEu8PA@mail.gmail.com>
 <51779304.4040003@st.com>
 <CAJe_ZhdZv5LW6kdwyPtJe69mfW6t=WQ4OJnG2H4sUhibattN2A@mail.gmail.com>
 <517867E1.7050301@ti.com>
 <CAJe_ZhfDZzq+DzA9XDF3PWFUmwcZnDy-mhE4hLNHmf+V4GhOxw@mail.gmail.com>
 <5179AE2F.3040403@ti.com>
Message-ID: <5179C187.509@linaro.org>

On 26/04/13 06:29, the mail apparently from Suman Anna included:

Hi -

>>> 3. Shareable/exclusive nature of a mailbox. If it is shareable, then
>>> duplicating the behavior between clients is not worth it, and this
>>> should be absorbed into the respective controller driver.
>>>
>> I think the mailbox should be exclusively held by a client. That makes
>> many things simpler. Also remote firmwares won't be always robust
>> enough to handle commands from different subsystems intermixed. The
>> API only has to make sure the mailbox_get/put operations are very
>> thin.
>
> This might be the case for specific remotes where we expect only one
> client driver to be responsible for talking to it, but for generic
> offloading, you do not want to have this restriction. You do not want
> peer clients to go through a single main client, as the latencies or the
> infrastructure imposed by the main client may not be suitable for the
> other clients. The stricter usecase here would be the shareable mailbox,
> and if it is exclusive, as dictated by a controller or device property,
> then so be it and things would get simplified for that controller/device.

Knowing why Jassi mentioned this, the situation is a bit different than 
what you replied to.  There are in fact multiple client drivers that can 
asynchronously decide to initiate communication on the same mailbox. 
Some of the client need to perform multi-step sequencing and lock the 
mailbox for the duration.

Right now we can implement that by having a driver on top to mediate, 
Jassi is suggesting being able to do the client locking at your layer as 
a primitive will simplify things, not least get rid of the mediation 
driver.  Your layer has concept of completion and notifier already so it 
seems it wouldn't take much more.

-Andy

-- 
Andy Green | Fujitsu Landing Team Leader
Linaro.org ? Open source software for ARM SoCs | Follow Linaro
http://facebook.com/pages/Linaro/155974581091106  - 
http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog


From gotom at sanori.org  Thu Apr 25 20:42:38 2013
From: gotom at sanori.org (Masanori Goto)
Date: Thu, 25 Apr 2013 17:42:38 -0700
Subject: [PATCH 10/21] [SCSI] nsp32: use mdelay instead of large udelay
 constants
In-Reply-To: <1366910944-3033663-11-git-send-email-arnd@arndb.de>
References: <1366910944-3033663-1-git-send-email-arnd@arndb.de>
 <1366910944-3033663-11-git-send-email-arnd@arndb.de>
Message-ID: <CALZLnaFeLcaGM7_McTZ=pKBRnpXk0AvqOTF=1YCqJv-53yk4XQ@mail.gmail.com>

2013/4/25 Arnd Bergmann <arnd at arndb.de>
>
> ARM cannot handle udelay for more than 2 miliseconds, so we
> should use mdelay instead for those.
>

Singed-off-by: GOTO Masanori <gotom at debian.or.jp>

> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Cc: GOTO Masanori <gotom at debian.or.jp>
> Cc: YOKOTA Hiroshi <yokota at netlab.is.tsukuba.ac.jp>
> Cc: "James E.J. Bottomley" <JBottomley at parallels.com>
> Cc: linux-scsi at vger.kernel.org
> ---
>  drivers/scsi/nsp32.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/scsi/nsp32.c b/drivers/scsi/nsp32.c
> index 1e3879d..0665f9c 100644
> --- a/drivers/scsi/nsp32.c
> +++ b/drivers/scsi/nsp32.c
> @@ -2899,7 +2899,7 @@ static void nsp32_do_bus_reset(nsp32_hw_data *data)
>          * reset SCSI bus
>          */
>         nsp32_write1(base, SCSI_BUS_CONTROL, BUSCTL_RST);
> -       udelay(RESET_HOLD_TIME);
> +       mdelay(RESET_HOLD_TIME / 1000);
>         nsp32_write1(base, SCSI_BUS_CONTROL, 0);
>         for(i = 0; i < 5; i++) {
>                 intrdat = nsp32_read2(base, IRQ_STATUS); /* dummy read */
> --
> 1.8.1.2
>


From syin at broadcom.com  Thu Apr 25 20:42:53 2013
From: syin at broadcom.com (Sherman Yin)
Date: Fri, 26 Apr 2013 00:42:53 +0000
Subject: Adding a void * to pinctrl_pin_desc
Message-ID: <051069C10411E24D9749790C498526FA1BCF4FC6@SJEXCHMB12.corp.ad.broadcom.com>

Hi Stephen and LinusW,

As I'm writing my pinctrl driver, I find myself creating an array to hold extra pin-specific information.  In the chip I'm working on, there is a pincfg register for each pin, but the fields of the register are slightly different for different pin types (eg. normal pins vs i2c pins).  I can simply create an array in my driver to hold this information, so I would have a list of PINCTRL_PIN(...) macros to define the pins, and another array to define the pin types - this works perfectly fine.  However, I thought this kind of per-pin data would fit nicely into the pinctrl_pin_desc structure.  Pin groups and pin functions are defined by the driver, so I thought it would be nice if the pin desc have this flexibility as well.  What do you think about expanding the struct to something like this:

struct pinctrl_pin_desc {
	unsigned number;
	const char *name;
	void * pin_data;
};

so that drivers can optionally use pin_data to hold other pin-specific information?  The down side is that with a void *, it may not be too useful if the pin-specific data is very different for each pin.  

Thanks,
Sherman



From horms at verge.net.au  Thu Apr 25 20:48:35 2013
From: horms at verge.net.au (Simon Horman)
Date: Fri, 26 Apr 2013 09:48:35 +0900
Subject: [PATCH 03/21] ARM: shmobile: don't call irqchip_init
 unconditionally
In-Reply-To: <1366910944-3033663-4-git-send-email-arnd@arndb.de>
References: <1366910944-3033663-1-git-send-email-arnd@arndb.de>
 <1366910944-3033663-4-git-send-email-arnd@arndb.de>
Message-ID: <20130426004835.GA20070@verge.net.au>

On Thu, Apr 25, 2013 at 07:28:46PM +0200, Arnd Bergmann wrote:
> The irqchip_init function is only available when building
> with CONFIG_OF enabled, which causes this build failure for
> bonito_defconfig:
> 
> arch/arm/mach-shmobile/built-in.o: In function `r8a7740_init_irq_of':
> :(.init.text+0x580): undefined reference to `irqchip_init'
> 
> This makes both the OF and the ATAGS portion of the driver
> conditional, which avoids the build error and also results
> in smaller object code if not both are enabled, without the
> need for an #ifdef.
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Cc: Bastian Hecht <hechtb+renesas at gmail.com>
> Cc: Simon Horman <horms+renesas at verge.net.au>
> Cc: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
> ---
>  arch/arm/mach-shmobile/intc-r8a7740.c | 13 +++++++++++--
>  1 file changed, 11 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/mach-shmobile/intc-r8a7740.c b/arch/arm/mach-shmobile/intc-r8a7740.c
> index 8871f77..5dc57f1 100644
> --- a/arch/arm/mach-shmobile/intc-r8a7740.c
> +++ b/arch/arm/mach-shmobile/intc-r8a7740.c
> @@ -53,14 +53,23 @@ static void __init r8a7740_init_irq_common(void)
>  
>  void __init r8a7740_init_irq_of(void)
>  {
> +	if (!IS_ENABLED(CONFIG_OF))
> +		return;
> +

In other parts of the shmobile I believe that such code is
guarded by #ifdef CONFIG_OF and I believe not guarding this code in
some way was an oversight.

The above change seems fine to me.

>  	irqchip_init();
>  	r8a7740_init_irq_common();
>  }
>  
>  void __init r8a7740_init_irq(void)
>  {
> -	void __iomem *gic_dist_base = ioremap_nocache(0xc2800000, 0x1000);
> -	void __iomem *gic_cpu_base = ioremap_nocache(0xc2000000, 0x1000);
> +	void __iomem *gic_dist_base;
> +	void __iomem *gic_cpu_base;
> +
> +	if (!IS_ENABLED(CONFIG_ATAGS))
> +		return;
> +
> +	gic_dist_base = ioremap_nocache(0xc2800000, 0x1000);
> +	gic_cpu_base = ioremap_nocache(0xc2000000, 0x1000);
>  
>  	/* initialize the Generic Interrupt Controller PL390 r0p0 */
>  	gic_init(0, 29, gic_dist_base, gic_cpu_base);

This one seems broken as the armadillo800eva board currently uses
it to initialise GIC even if CONFIG_ATAGS is not defined.

I did test the above change on the armadillo800eva board
with the above change and CONFIG_ATAGS disabled, the result was
a boot failure. With the change reverted booting seems fine.


From horms at verge.net.au  Thu Apr 25 20:50:12 2013
From: horms at verge.net.au (Simon Horman)
Date: Fri, 26 Apr 2013 09:50:12 +0900
Subject: [PATCH 11/21] irqdomain: export irq_domain_add_simple
In-Reply-To: <1366910944-3033663-12-git-send-email-arnd@arndb.de>
References: <1366910944-3033663-1-git-send-email-arnd@arndb.de>
 <1366910944-3033663-12-git-send-email-arnd@arndb.de>
Message-ID: <20130426005012.GB20070@verge.net.au>

On Thu, Apr 25, 2013 at 07:28:54PM +0200, Arnd Bergmann wrote:
> All other irq_domain_add_* functions are exported already, and apparently
> this one got left out by mistake, which causes build errors for ARM
> allmodconfig kernels:
> 
> ERROR: "irq_domain_add_simple" [drivers/gpio/gpio-rcar.ko] undefined!
> ERROR: "irq_domain_add_simple" [drivers/gpio/gpio-em.ko] undefined!
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Cc: Benjamin Herrenschmidt <benh at kernel.crashing.org>
> Cc: Grant Likely <grant.likely at linaro.org>
> Cc: Thomas Gleixner <tglx at linutronix.de>
> Cc: Simon Horman <horms+renesas at verge.net.au>
> Cc: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
> Cc: Magnus Damm <damm at opensource.se>

Acked-by: Simon Horman <horms+renesas at verge.net.au>

Grant, could consider taking this one?

> ---
>  kernel/irq/irqdomain.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
> index 059a280..c532c15 100644
> --- a/kernel/irq/irqdomain.c
> +++ b/kernel/irq/irqdomain.c
> @@ -194,6 +194,7 @@ struct irq_domain *irq_domain_add_simple(struct device_node *of_node,
>  	/* A linear domain is the default */
>  	return irq_domain_add_linear(of_node, size, ops, host_data);
>  }
> +EXPORT_SYMBOL_GPL(irq_domain_add_simple);
>  
>  /**
>   * irq_domain_add_legacy() - Allocate and register a legacy revmap irq_domain.
> -- 
> 1.8.1.2
> 


From horms at verge.net.au  Thu Apr 25 22:23:40 2013
From: horms at verge.net.au (Simon Horman)
Date: Fri, 26 Apr 2013 11:23:40 +0900
Subject: [PATCH] ARM: shmobile: lager: Add GPIO LEDs
In-Reply-To: <2538127.Zp8aiG0hQe@avalon>
References: <1366599990-31751-1-git-send-email-horms+renesas@verge.net.au>
 <1761228.8meccMO5Km@avalon> <20130423011524.GE12017@verge.net.au>
 <2538127.Zp8aiG0hQe@avalon>
Message-ID: <20130426022340.GA31993@verge.net.au>

On Tue, Apr 23, 2013 at 12:48:03PM +0200, Laurent Pinchart wrote:
> Hi Simon,
> 
> On Tuesday 23 April 2013 10:15:25 Simon Horman wrote:
> > On Mon, Apr 22, 2013 at 12:00:02PM +0200, Laurent Pinchart wrote:
> > > Hi Simon,
> > > 
> > > Thank you for the patch.
> > > 
> > > On Monday 22 April 2013 12:06:30 Simon Horman wrote:
> > > > The board has 3 LEDs connected to GPIOs. Add a led-gpio device to
> > > > support them.
> > > > 
> > > > Based on "ARM: shmobile: marzen: Add GPIO LEDs" by Laurent Pinchart.
> > > > 
> > > > Cc: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
> > > > Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
> > > > ---
> > > > 
> > > >  arch/arm/mach-shmobile/board-lager.c | 37 +++++++++++++++++++++++++++++
> > > >  1 file changed, 37 insertions(+)
> > > > 
> > > > Tested on lager board.
> > > > Based on the tag renesas-next-20130419 of my renesas tree.
> > > > 
> > > > diff --git a/arch/arm/mach-shmobile/board-lager.c
> > > > b/arch/arm/mach-shmobile/board-lager.c index 6114edd..a8aa04f 100644
> > > > --- a/arch/arm/mach-shmobile/board-lager.c
> > > > +++ b/arch/arm/mach-shmobile/board-lager.c
> > > > @@ -21,13 +21,49 @@
> > > >  #include <linux/interrupt.h>
> > > >  #include <linux/irqchip.h>
> > > >  #include <linux/kernel.h>
> > > > +#include <linux/leds.h>
> > > >  #include <linux/pinctrl/machine.h>
> > > > +#include <linux/platform_data/gpio-rcar.h>
> > > >  #include <linux/platform_device.h>
> > > >  #include <mach/common.h>
> > > >  #include <mach/r8a7790.h>
> > > >  #include <asm/mach-types.h>
> > > >  #include <asm/mach/arch.h>
> > > > 
> > > > +/* LEDS */
> > > > +static struct gpio_led lager_leds[] = {
> > > > +	{
> > > > +		.name		= "led8",
> > > > +		.gpio		= RCAR_GP_PIN(5, 17),
> > > > +		.default_state	= LEDS_GPIO_DEFSTATE_ON,
> > > > +	}, {
> > > > +		.name		= "led7",
> > > > +		.gpio		= RCAR_GP_PIN(4, 23),
> > > > +		.default_state	= LEDS_GPIO_DEFSTATE_ON,
> > > > +	}, {
> > > > +		.name		= "led6",
> > > > +		.gpio		= RCAR_GP_PIN(4, 22),
> > > > +		.default_state	= LEDS_GPIO_DEFSTATE_ON,
> > > 
> > > Just out of curiosity, why is the default state on ?
> > 
> > Only because thats what the marzen code does.
> > Would off be a better choice?
> 
> It would save a little bit of power by default :-)

:^)

I think that I would rather leave it _ON for consistency with
other shmobile board code.


From robherring2 at gmail.com  Thu Apr 25 22:51:10 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Thu, 25 Apr 2013 21:51:10 -0500
Subject: [RFC PATCH v3 02/17] Documentation: devicetree: arm: cpus/cpu
 nodes bindings updates
In-Reply-To: <1366824502-19729-3-git-send-email-lorenzo.pieralisi@arm.com>
References: <1366824502-19729-1-git-send-email-lorenzo.pieralisi@arm.com>
 <1366824502-19729-3-git-send-email-lorenzo.pieralisi@arm.com>
Message-ID: <CAL_JsqL2QOjTffogB6g7VK7oRUwDAmJpr=36uvFXjd+hpBL89A@mail.gmail.com>

On Wed, Apr 24, 2013 at 12:28 PM, Lorenzo Pieralisi
<lorenzo.pieralisi at arm.com> wrote:
> In order to extend the current cpu nodes bindings to newer CPUs
> inclusive of AArch64 and to update support for older ARM CPUs this
> patch updates device tree documentation for the cpu nodes bindings.
>
> Main changes:
>     - adds 64-bit bindings
>     - define usage of #address-cells
>     - define 32/64 dts compatibility settings
>     - defines behaviour on pre and post v7 uniprocessor systems
>     - adds ARM 11MPcore specific reg property definition
>
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
> ---

[...]

> +       - enable-method
> +               Value type: <stringlist>
> +               Usage and definition depend on ARM architecture version and
> +               configuration:
> +                       # On ARM v8 64-bit systems running the OS in AArch64,
> +                         this property is required and must be "spin-table".

What about PSCI?

I don't think the ePAPR spin-table definition is sufficient for ARM.
How do you define wake up by SGI or sev instruction.

> +                       # On ARM 32-bit systems or ARM v8 systems running
> +                         the OS in AArch32 this property is prohibited.

Why?

Rob


From jaswinder.singh at linaro.org  Thu Apr 25 23:46:02 2013
From: jaswinder.singh at linaro.org (Jassi Brar)
Date: Fri, 26 Apr 2013 09:16:02 +0530
Subject: [PATCHv3 00/14] drivers: mailbox: framework creation
In-Reply-To: <5179AE2F.3040403@ti.com>
References: <1363145021-14339-1-git-send-email-s-anna@ti.com>
 <CABb+yY0RYkVeo2Sb4WsDJY0jf17488FEz0d2CB994eQaSOEsVg@mail.gmail.com>
 <37C860A02101E749A747FA2D3C1E3C504A5DF7@DLEE11.ent.ti.com>
 <CABb+yY1x4x_A+QtGG9ohsLPgs8c3nEVnd_ExJBGOOR8=6YLPFA@mail.gmail.com>
 <37C860A02101E749A747FA2D3C1E3C504A63B4@DLEE11.ent.ti.com>
 <CAJe_ZhehnniZd730jjiOLrHozq8TOJZgFYLqUe4KqgBiQEu8PA@mail.gmail.com>
 <51779304.4040003@st.com>
 <CAJe_ZhdZv5LW6kdwyPtJe69mfW6t=WQ4OJnG2H4sUhibattN2A@mail.gmail.com>
 <517867E1.7050301@ti.com>
 <CAJe_ZhfDZzq+DzA9XDF3PWFUmwcZnDy-mhE4hLNHmf+V4GhOxw@mail.gmail.com>
 <5179AE2F.3040403@ti.com>
Message-ID: <CAJe_Zhf4miUm4yTyuwc56kpD8Mu4=vsmX4wdQkFDT96JbKR=MQ@mail.gmail.com>

Hi Suman,

On 26 April 2013 03:59, Suman Anna <s-anna at ti.com> wrote:
> On 04/25/2013 12:20 AM, Jassi Brar wrote:
> tranmitting right away. OK, I thought you didn't want buffering, if that
> is not the case, then the buffering should be within the main driver
> code, like it is now, but configurable based on the controller or
> mailbox properties. If it is present in individual controller drivers,
> then we would be duplicating stuff. Are you envisioning that this be
> left to the individual controllers?
>
Please don't accuse me of such bad visions :)
I never said no-buffering and I never said buffering should be in
controller drivers. In fact I don't remember ever objecting to how
buffering is done in TI's framework.
A controller could service only 1 request at a time so lets give it
just 1 at a time. Let the API handle the complexity of buffering.

>> I am afraid you are confusing the meaning of 'atomic context' here.
>> atomic context doesn't mean instant transmission of data, but that the
>> API calls could be made from even atomic context and that the client &
>> controller can't sleep in callbacks from the API. So it's not moot.
>
> I understood the atomic context, and the question is about the behavior
> of the '.tx_done' callback when sending from atomic context. Is there
> such a usecase/need for you in that you want to send a response back
> from an atomic context, yet get a callback?
>
Let me get in detail...
The TX-Wheel has to tick. Someone has to tell the framework that the
last TX was consumed by the remote and now it's time to submit the
next TX (RX will always be driven by the controller's IRQ so it's
straight).
If the controller h/w gets some interrupt indicating
Remote-RTR/TX-Done then the ticker is driven by controller's TX-IRQ
handler. Otherwise, if the controller does sense RTR but not report
(by reading status in some register but no irq), then API has to poll
it periodically and move the ticker. If the controller can neither
report nor sense RTR, the client/protocol driver must run the ticker
(usually upon receiving some ACK packet on the RX channel).
This TX ticker should be callable from atomic context (controller's
IRQ handler) and calls into callback of the client. It is desirable
that the client be able to submit yet another TX request from the
callback. That way the client can avoid having to schedule work from
the callback if the TX doesn't involve any sleepable task. The scheme
is working very well in DMA-Engine stack.

BTW, TI's RX mechanism too seems broken for common API. Receiving
every few bytes via 'notify' mechanism is very inefficient. Imagine a
platform with no shared memory between co-processors and the local
wants to diagnose the remote by asking critical data at least KBs in
size.
 So when API has nothing to do with received packet and the controller
has to get rid of it asap so as to be able to receive the next, IMHO
there should be short-circuit from controller to client via the API.
No delay, no buffering of RX.


>> It's the controller driver that actually puts the data on the bus. So
>> only it should define the format in which it accepts data from the
>> clients. Every client should simply populate the packet structure
>> defined in  my_lovely_controller.h and pass on the struct pointer to
>> the controller driver via API.
>> No negotiations for the driver seat among passengers :)
>
> OK, I was trying to avoid including my_lovely_controller.h and only
> include the standard .h file as a client user, the client would anyway
> need to have the intrinsic knowledge of the packet structure.
>
Not including my_controller.h doesn't make things standard.
As we know, the client anyway has to have intrinsic knowledge of the
packet structure(which is dictated by the controller), so not
including my_controller.h will only confuse people as to where the
packet info came from?

>>>
>> I think the mailbox should be exclusively held by a client. That makes
>> many things simpler. Also remote firmwares won't be always robust
>> enough to handle commands from different subsystems intermixed. The
>> API only has to make sure the mailbox_get/put operations are very
>> thin.
>
> This might be the case for specific remotes where we expect only one
> client driver to be responsible for talking to it, but for generic
> offloading, you do not want to have this restriction. You do not want
> peer clients to go through a single main client, as the latencies or the
> infrastructure imposed by the main client may not be suitable for the
> other clients. The stricter usecase here would be the shareable mailbox,
> and if it is exclusive, as dictated by a controller or device property,
> then so be it and things would get simplified for that controller/device.
>
Shared Vs Exclusive had been the dilemma of DMAEngine too.
If the controller has physical channels at least as many as clients,
exclusivity is no problem.
Sharing is desirable when the controller has to serve clients more
than its physical channels. We solve that by having the controller
declare exclusive virtual channels and internally scheduling the
requests onto physical channels.
 And as Andy pointed out, some remote-ends may not cope with requests
coming from different subsystems intermixed.

Regards,
-Jassi


From tony at atomide.com  Thu Apr 25 23:52:07 2013
From: tony at atomide.com (Tony Lindgren)
Date: Thu, 25 Apr 2013 20:52:07 -0700
Subject: [PATCH 0/3] WLAN support for omap4 when booted with devicetree
Message-ID: <20130426034858.26065.65118.stgit@muffinssi.local>

Hi all,

Here are some patches against linux next to make WLAN to work with
device tree. Note that we still are initializing wl12xx with pdata,
but so far it looks like only minimal binding for it is needed.

There are various fixes pending posted recently, but at least the
fix "[PATCH] mmc: omap_hsmmc: Fix the DT pbias workaround for MMC
controllers 2 to 5" is needed.

Please test on blaze/sdp if you have a chance, I don't have the
connectivity card on mine.

Regards,

Tony

---

Tony Lindgren (3):
      ARM: OMAP2+: Legacy support for wl12xx when booted with devicetree
      ARM: dts: Add muxing for wl12xx on the SDIO bus for pandaboard
      ARM: dts: Add muxing for wl12xx on the SDIO bus for blaze


 arch/arm/boot/dts/omap4-panda-common.dtsi |   43 ++++++++++++++++++++++++++++-
 arch/arm/boot/dts/omap4-sdp.dts           |   39 ++++++++++++++++++++++++++
 arch/arm/mach-omap2/devices.c             |   39 ++++++++++++++++++++++++++
 3 files changed, 119 insertions(+), 2 deletions(-)

-- 
Signature


From tony at atomide.com  Thu Apr 25 23:52:10 2013
From: tony at atomide.com (Tony Lindgren)
Date: Thu, 25 Apr 2013 20:52:10 -0700
Subject: [PATCH 1/3] ARM: OMAP2+: Legacy support for wl12xx when booted with
 devicetree
In-Reply-To: <20130426034858.26065.65118.stgit@muffinssi.local>
References: <20130426034858.26065.65118.stgit@muffinssi.local>
Message-ID: <20130426035210.26065.39995.stgit@muffinssi.local>

Without WLAN we cannot switch omap4 to use device tree
only booting. This patch can be reverted when the
binding for wl12xx is added.

Cc: Luciano Coelho <coelho at ti.com>
Cc: Benoit Cousson <b-cousson at ti.com>
Cc: Rajendra Nayak <rnayak at ti.com>
Cc: devicetree-discuss at lists.ozlabs.org
Signed-off-by: Tony Lindgren <tony at atomide.com>
---
 arch/arm/mach-omap2/devices.c |   39 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 39 insertions(+)

diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 73762ac..69c520e 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -15,6 +15,7 @@
 #include <linux/io.h>
 #include <linux/clk.h>
 #include <linux/err.h>
+#include <linux/gpio.h>
 #include <linux/slab.h>
 #include <linux/of.h>
 #include <linux/pinctrl/machine.h>
@@ -22,6 +23,7 @@
 #include <linux/platform_data/omap_ocp2scp.h>
 #include <linux/platform_data/mailbox-omap.h>
 #include <linux/usb/omap_control_usb.h>
+#include <linux/wl12xx.h>
 
 #include <asm/mach-types.h>
 #include <asm/mach/map.h>
@@ -640,6 +642,40 @@ static void __init omap_init_ocp2scp(void)
 static inline void omap_init_ocp2scp(void) { }
 #endif
 
+#if IS_ENABLED(CONFIG_WL12XX)
+
+static struct wl12xx_platform_data wl12xx __initdata;
+
+void __init omap_init_wl12xx_of(void)
+{
+	int ret;
+
+	if (!of_have_populated_dt())
+		return;
+
+	if (of_machine_is_compatible("ti,omap4-sdp")) {
+		wl12xx.board_ref_clock = WL12XX_REFCLOCK_26;
+		wl12xx.board_tcxo_clock = WL12XX_TCXOCLOCK_26;
+		wl12xx.irq = gpio_to_irq(53);
+	} else if (of_machine_is_compatible("ti,omap4-panda")) {
+		wl12xx.board_ref_clock = WL12XX_REFCLOCK_38;
+		wl12xx.irq = gpio_to_irq(53);
+	} else {
+		return;
+	}
+
+	ret = wl12xx_set_platform_data(&wl12xx);
+	if (ret) {
+		pr_err("error setting wl12xx data: %d\n", ret);
+		return;
+	}
+}
+#else
+static inline omap_init_wl12xx_of(void)
+{
+}
+#endif
+
 /*-------------------------------------------------------------------------*/
 
 static int __init omap2_init_devices(void)
@@ -664,6 +700,9 @@ static int __init omap2_init_devices(void)
 		omap_init_mcspi();
 		omap_init_sham();
 		omap_init_aes();
+	} else {
+		/* These can be removed when bindings are done */
+		omap_init_wl12xx_of();
 	}
 	omap_init_sti();
 	omap_init_rng();



From tony at atomide.com  Thu Apr 25 23:52:13 2013
From: tony at atomide.com (Tony Lindgren)
Date: Thu, 25 Apr 2013 20:52:13 -0700
Subject: [PATCH 2/3] ARM: dts: Add muxing for wl12xx on the SDIO bus for
 pandaboard
In-Reply-To: <20130426034858.26065.65118.stgit@muffinssi.local>
References: <20130426034858.26065.65118.stgit@muffinssi.local>
Message-ID: <20130426035213.26065.63243.stgit@muffinssi.local>

This is needed to get wl12xx working with device tree based
booting.

Note that we claim the various GPIO inputs in the regulator
as the proper muxing is needed to enable and disable the
regulator.

Also, we want to use non-removable instead of ti,non-removable
as the ti,non-removable also sets no_regulator_off_init which
is really not what we want as then wl12xx won't get powered
up and down which is needed for resetting it.

Cc: Luciano Coelho <coelho at ti.com>
Cc: Benoit Cousson <b-cousson at ti.com>
Cc: Rajendra Nayak <rnayak at ti.com>
Cc: devicetree-discuss at lists.ozlabs.org
Signed-off-by: Tony Lindgren <tony at atomide.com>
---
 arch/arm/boot/dts/omap4-panda-common.dtsi |   43 ++++++++++++++++++++++++++++-
 1 file changed, 42 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 628f744..16b23bf 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -86,6 +86,19 @@
 		clock-names = "main_clk";
 		clock-frequency = <19200000>;
 	};
+
+	/* regulator for wl12xx on sdio5 */
+	wl12xx_vmmc: wl12xx_vmmc {
+		pinctrl-names = "default";
+		pinctrl-0 = <&wl12xx_gpio>;
+		compatible = "regulator-fixed";
+		regulator-name = "vwl1271";
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <1800000>;
+		gpio = <&gpio2 11 0>;
+		startup-delay-us = <70000>;
+		enable-active-high;
+	};
 };
 
 &omap4_pmx_core {
@@ -185,6 +198,30 @@
 			0xf0 0x118     /* i2c4_sda PULLUP | INPUTENABLE | MODE0 */
 		>;
 	};
+
+	/* wl12xx GPIO outputs for WLAN_EN, BT_EN, FM_EN, BT_WAKEUP */
+	wl12xx_gpio: pinmux_wl12xx_gpio {
+		pinctrl-single,pins = <
+			0x26 0x3	/* gpmc_a19.gpio_43 OUTPUT | MODE3 */
+			0x2c 0x3	/* gpmc_a22.gpio_46 OUTPUT | MODE3 */
+			0x30 0xb	/* gpmc_a24.gpio_48 OUTPUT | MODE3 */
+			0x32 0xb	/* gpmc_a25.gpio_49 OUTPUT | MODE3 */
+		>;
+	};
+
+	/* wl12xx GPIO inputs and SDIO pins */
+	wl12xx_pins: pinmux_wl12xx_pins {
+		pinctrl-single,pins = <
+			0x38 0x103	/* gpmc_ncs2.gpio_52 INPUT | MODE3 */
+			0x3a 0x103	/* gpmc_ncs3.gpio_53 INPUT | MODE3 */
+			0x108 0x118	/* sdmmc5_clk.sdmmc5_clk INPUT_PULLUP | MODE0 */
+			0x10a 0x118	/* sdmmc5_cmd.sdmmc5_cmd INPUT_PULLUP | MODE0 */
+			0x10c 0x118	/* sdmmc5_dat0.sdmmc5_dat0 INPUT_PULLUP | MODE0 */
+			0x10e 0x118	/* sdmmc5_dat1.sdmmc5_dat1 INPUT_PULLUP | MODE0 */
+			0x110 0x118	/* sdmmc5_dat2.sdmmc5_dat2 INPUT_PULLUP | MODE0 */
+			0x112 0x118	/* sdmmc5_dat3.sdmmc5_dat3 INPUT_PULLUP | MODE0 */
+      		>;
+	};
 };
 
 &i2c1 {
@@ -264,8 +301,12 @@
 };
 
 &mmc5 {
-	ti,non-removable;
+	pinctrl-names = "default";
+	pinctrl-0 = <&wl12xx_pins>;
+	vmmc-supply = <&wl12xx_vmmc>;
+	non-removable;
 	bus-width = <4>;
+	cap-power-off-card;
 };
 
 &emif1 {



From tony at atomide.com  Thu Apr 25 23:52:16 2013
From: tony at atomide.com (Tony Lindgren)
Date: Thu, 25 Apr 2013 20:52:16 -0700
Subject: [PATCH 3/3] ARM: dts: Add muxing for wl12xx on the SDIO bus for blaze
In-Reply-To: <20130426034858.26065.65118.stgit@muffinssi.local>
References: <20130426034858.26065.65118.stgit@muffinssi.local>
Message-ID: <20130426035216.26065.32776.stgit@muffinssi.local>

This should work assuming the board-4430sdp.c works, but it seems
that I don't have the "1283 PG 2.21 connectivity device" on
my blaze. Anybody got a spare connectivity device for blaze?

Also, if somebody has the schematics, please provide a patch
for the missing GPIO muxes for blaze, see the the panda for
what's currently missing.

Cc: Luciano Coelho <coelho at ti.com>
Cc: Benoit Cousson <b-cousson at ti.com>
Cc: Rajendra Nayak <rnayak at ti.com>
Cc: Ruslan Bilovol <ruslan.bilovol at ti.com>
Cc: devicetree-discuss at lists.ozlabs.org
Signed-off-by: Tony Lindgren <tony at atomide.com>
---
 arch/arm/boot/dts/omap4-sdp.dts |   39 ++++++++++++++++++++++++++++++++++++++-
 1 file changed, 38 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index a35d9cd..c13c483 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -140,6 +140,19 @@
 			"DMic", "Digital Mic",
 			"Digital Mic", "Digital Mic1 Bias";
 	};
+
+	/* regulator for wl12xx on sdio5 */
+	wl12xx_vmmc: wl12xx_vmmc {
+		pinctrl-names = "default";
+		pinctrl-0 = <&wl12xx_gpio>;
+		compatible = "regulator-fixed";
+		regulator-name = "vwl1271";
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <1800000>;
+		gpio = <&gpio2 22 0>;
+		startup-delay-us = <70000>;
+		enable-active-high;
+	};
 };
 
 &omap4_pmx_core {
@@ -275,6 +288,26 @@
 			0xf0 0x118     /* i2c4_sda PULLUP | INPUTENABLE | MODE0 */
 		>;
 	};
+
+	/* wl12xx GPIO output for WLAN_EN */
+	wl12xx_gpio: pinmux_wl12xx_gpio {
+		pinctrl-single,pins = <
+			0x3c 0x3	/* gpmc_nwp.gpio_54 OUTPUT | MODE3 */
+		>;
+	};
+
+	/* wl12xx GPIO inputs and SDIO pins */
+	wl12xx_pins: pinmux_wl12xx_pins {
+		pinctrl-single,pins = <
+			0x3a 0x103	/* gpmc_ncs3.gpio_53 INPUT | MODE3 */
+			0x108 0x118	/* sdmmc5_clk.sdmmc5_clk INPUT_PULLUP | MODE0 */
+			0x10a 0x118	/* sdmmc5_cmd.sdmmc5_cmd INPUT_PULLUP | MODE0 */
+			0x10c 0x118	/* sdmmc5_dat0.sdmmc5_dat0 INPUT_PULLUP | MODE0 */
+			0x10e 0x118	/* sdmmc5_dat1.sdmmc5_dat1 INPUT_PULLUP | MODE0 */
+			0x110 0x118	/* sdmmc5_dat2.sdmmc5_dat2 INPUT_PULLUP | MODE0 */
+			0x112 0x118	/* sdmmc5_dat3.sdmmc5_dat3 INPUT_PULLUP | MODE0 */
+      		>;
+	};
 };
 
 &i2c1 {
@@ -400,8 +433,12 @@
 };
 
 &mmc5 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&wl12xx_pins>;
+	vmmc-supply = <&wl12xx_vmmc>;
+	non-removable;
 	bus-width = <4>;
-	ti,non-removable;
+	cap-power-off-card;
 };
 
 &emif1 {



From shawn.guo at linaro.org  Thu Apr 25 23:52:19 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Fri, 26 Apr 2013 11:52:19 +0800
Subject: [PATCH v2] ARM: imx: replicate the diagnostic register of boot
 cpu into secondary cores
In-Reply-To: <20130425152152.GA25671@mudshark.cambridge.arm.com>
References: <1366903115-11195-1-git-send-email-shawn.guo@linaro.org>
 <20130425152152.GA25671@mudshark.cambridge.arm.com>
Message-ID: <20130426035217.GC7504@S2101-09.ap.freescale.net>

On Thu, Apr 25, 2013 at 04:21:52PM +0100, Will Deacon wrote:
> I'm still against setting this register with the MMU enabled. It is a
> CPU-specific, undocumented register so it's hard for me to make a case here,
> but the feedback from the hardware guys is that this may have unintended
> consequences.

I see that Exynos cpuidle driver has been doing that since Mar last
year.  But I respect your comment and will try to set the register
before MMU is enabled.

Shawn



From shawn.guo at linaro.org  Thu Apr 25 23:57:25 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Fri, 26 Apr 2013 11:57:25 +0800
Subject: [PATCH v3] ARM: imx: replicate the diagnostic register of boot cpu
 into secondary cores
Message-ID: <1366948645-12060-1-git-send-email-shawn.guo@linaro.org>

The diagnostic register holds the errata bits.  Mostly bootloader
does not bring up secondary cores, so that when errata bits are set
in bootloader, they are set only for boot cpu.  But on a SMP
configuration, it should be equally done on every single core.
Set up the diagnostic register for secondary cores by replicating
the register from boot cpu.

Signed-off-by: Shawn Guo <shawn.guo at linaro.org>
---
Changes since v2:
 * Setting secondary cores' diagnostic register before MMU is enabled.

 arch/arm/mach-imx/headsmp.S |   12 ++++++++++++
 arch/arm/mach-imx/platsmp.c |   14 ++++++++++++++
 2 files changed, 26 insertions(+)

diff --git a/arch/arm/mach-imx/headsmp.S b/arch/arm/mach-imx/headsmp.S
index a58c8b0..cd87970 100644
--- a/arch/arm/mach-imx/headsmp.S
+++ b/arch/arm/mach-imx/headsmp.S
@@ -18,8 +18,20 @@
 	.section ".text.head", "ax"
 
 #ifdef CONFIG_SMP
+diag_reg_offset:
+	.word	g_diag_reg - .
+
+	.macro	set_diag_reg
+	adr	r0, diag_reg_offset
+	ldr	r1, [r0]
+	add	r1, r1, r0		@ r1 = physical &g_diag_reg
+	ldr	r0, [r1]
+	mcr	p15, 0, r0, c15, c0, 1	@ write diagnostic register
+	.endm
+
 ENTRY(v7_secondary_startup)
 	bl	v7_invalidate_l1
+	set_diag_reg
 	b	secondary_startup
 ENDPROC(v7_secondary_startup)
 #endif
diff --git a/arch/arm/mach-imx/platsmp.c b/arch/arm/mach-imx/platsmp.c
index 7061bde..abe9d95 100644
--- a/arch/arm/mach-imx/platsmp.c
+++ b/arch/arm/mach-imx/platsmp.c
@@ -13,6 +13,7 @@
 #include <linux/init.h>
 #include <linux/smp.h>
 #include <linux/irqchip/arm-gic.h>
+#include <asm/cacheflush.h>
 #include <asm/page.h>
 #include <asm/smp_scu.h>
 #include <asm/mach/map.h>
@@ -22,6 +23,7 @@
 
 #define SCU_STANDBY_ENABLE	(1 << 5)
 
+u32 g_diag_reg;
 static void __iomem *scu_base;
 
 static struct map_desc scu_io_desc __initdata = {
@@ -91,6 +93,18 @@ void imx_smp_prepare(void)
 static void __init imx_smp_prepare_cpus(unsigned int max_cpus)
 {
 	imx_smp_prepare();
+
+	/*
+	 * The diagnostic register holds the errata bits.  Mostly bootloader
+	 * does not bring up secondary cores, so that when errata bits are set
+	 * in bootloader, they are set only for boot cpu.  But on a SMP
+	 * configuration, it should be equally done on every single core.
+	 * Read the register from boot cpu here, and will replicate it into
+	 * secondary cores when booting them.
+	 */
+	asm("mrc p15, 0, %0, c15, c0, 1" : "=r" (g_diag_reg) : : "cc");
+	__cpuc_flush_dcache_area(&g_diag_reg, sizeof(g_diag_reg));
+	outer_clean_range(__pa(&g_diag_reg), __pa(&g_diag_reg + 1));
 }
 
 struct smp_operations  imx_smp_ops __initdata = {
-- 
1.7.9.5




From s.hauer at pengutronix.de  Fri Apr 26 01:28:50 2013
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Fri, 26 Apr 2013 07:28:50 +0200
Subject: [PATCH V2] video: imx: Select VIDEOMODE_HELPERS for parallel
 display
In-Reply-To: <1366829039-12452-1-git-send-email-marex@denx.de>
References: <1366829039-12452-1-git-send-email-marex@denx.de>
Message-ID: <20130426052850.GP32299@pengutronix.de>

On Wed, Apr 24, 2013 at 08:43:59PM +0200, Marek Vasut wrote:
> Without this, I get the following problem when building kernel:
> 
> drivers/built-in.o: In function `imx_pd_connector_get_modes':
> /linux-2.6/drivers/staging/imx-drm/parallel-display.c:78: undefined reference to `of_get_drm_display_mode'
> make: *** [vmlinux] Error 1
> 
> Signed-off-by: Marek Vasut <marex at denx.de>
> Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
> Cc: Sascha Hauer <s.hauer at pengutronix.de>
> Cc: Philipp Zabel <p.zabel at pengutronix.de>
> Cc: Fabio Estevam <fabio.estevam at freescale.com>

Acked-by: Sascha Hauer <s.hauer at pengutronix.de>

> ---
>  drivers/staging/imx-drm/Kconfig |    1 +
>  1 file changed, 1 insertion(+)
> 
> V2: Select VIDEOMODE_HELPERS only for parallel display
> 
> diff --git a/drivers/staging/imx-drm/Kconfig b/drivers/staging/imx-drm/Kconfig
> index 8c9e403..0550f01 100644
> --- a/drivers/staging/imx-drm/Kconfig
> +++ b/drivers/staging/imx-drm/Kconfig
> @@ -19,6 +19,7 @@ config DRM_IMX_FB_HELPER
>  config DRM_IMX_PARALLEL_DISPLAY
>  	tristate "Support for parallel displays"
>  	depends on DRM_IMX
> +	select VIDEOMODE_HELPERS
>  
>  config DRM_IMX_TVE
>  	tristate "Support for TV and VGA displays"
> -- 
> 1.7.10.4
> 
> 

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From tiwai at suse.de  Fri Apr 26 01:40:00 2013
From: tiwai at suse.de (Takashi Iwai)
Date: Fri, 26 Apr 2013 07:40:00 +0200
Subject: [PATCH 06/21] ALSA: ali5451: use mdelay instead of large udelay
 constants
In-Reply-To: <1366910944-3033663-7-git-send-email-arnd@arndb.de>
References: <1366910944-3033663-1-git-send-email-arnd@arndb.de>
 <1366910944-3033663-7-git-send-email-arnd@arndb.de>
Message-ID: <s5hy5c597f3.wl%tiwai@suse.de>

At Thu, 25 Apr 2013 19:28:49 +0200,
Arnd Bergmann wrote:
> 
> ARM cannot handle udelay for more than 2 miliseconds, so we
> should use mdelay instead for those.
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Cc: Takashi Iwai <tiwai at suse.de>
> Cc: alsa-devel at alsa-project.org

Thanks, applied to sound git tree.


Takashi


> ---
>  sound/pci/ali5451/ali5451.c | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/sound/pci/ali5451/ali5451.c b/sound/pci/ali5451/ali5451.c
> index e760af9..53754f5 100644
> --- a/sound/pci/ali5451/ali5451.c
> +++ b/sound/pci/ali5451/ali5451.c
> @@ -451,10 +451,10 @@ static int snd_ali_reset_5451(struct snd_ali *codec)
>  	if (pci_dev) {
>  		pci_read_config_dword(pci_dev, 0x7c, &dwVal);
>  		pci_write_config_dword(pci_dev, 0x7c, dwVal | 0x08000000);
> -		udelay(5000);
> +		mdelay(5);
>  		pci_read_config_dword(pci_dev, 0x7c, &dwVal);
>  		pci_write_config_dword(pci_dev, 0x7c, dwVal & 0xf7ffffff);
> -		udelay(5000);
> +		mdelay(5);
>  	}
>  	
>  	pci_dev = codec->pci;
> @@ -463,14 +463,14 @@ static int snd_ali_reset_5451(struct snd_ali *codec)
>  	udelay(500);
>  	pci_read_config_dword(pci_dev, 0x44, &dwVal);
>  	pci_write_config_dword(pci_dev, 0x44, dwVal & 0xfffbffff);
> -	udelay(5000);
> +	mdelay(5);
>  	
>  	wCount = 200;
>  	while(wCount--) {
>  		wReg = snd_ali_codec_peek(codec, 0, AC97_POWERDOWN);
>  		if ((wReg & 0x000f) == 0x000f)
>  			return 0;
> -		udelay(5000);
> +		mdelay(5);
>  	}
>  
>  	/* non-fatal if you have a non PM capable codec */
> -- 
> 1.8.1.2
> 


From tiwai at suse.de  Fri Apr 26 01:41:33 2013
From: tiwai at suse.de (Takashi Iwai)
Date: Fri, 26 Apr 2013 07:41:33 +0200
Subject: [PATCH 07/21] oss/dmabuf: use dma_map_single
In-Reply-To: <1366910944-3033663-8-git-send-email-arnd@arndb.de>
References: <1366910944-3033663-1-git-send-email-arnd@arndb.de>
 <1366910944-3033663-8-git-send-email-arnd@arndb.de>
Message-ID: <s5hwqrp97ci.wl%tiwai@suse.de>

At Thu, 25 Apr 2013 19:28:50 +0200,
Arnd Bergmann wrote:
> 
> The virt_to_bus/bus_to_virt functions have been deprecated
> for as long as I can remember, and they are used in very
> few remaining instances, usually in obscure ISA device
> drivers. The OSS sound drivers are the only ones that are
> still used on the ARM architecture, and only on some of
> the earliest StrongARM machines.
> 
> The problem for converting the OSS subsystem to use
> dma_map_single instead is that the caller of virt_to_bus
> does not have a device pointer, since the subsystem has
> never been ported to use the common device infrastructure.
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Cc: Jaroslav Kysela <perex at perex.cz>
> Cc: Takashi Iwai <tiwai at suse.de>
> Cc: alsa-devel at alsa-project.org

Applied now, but the only problem is that it's difficult to test it :)
Let's see.


Thanks!

Takashi

> ---
>  sound/oss/dmabuf.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/sound/oss/dmabuf.c b/sound/oss/dmabuf.c
> index bcc3e8e..a59c888 100644
> --- a/sound/oss/dmabuf.c
> +++ b/sound/oss/dmabuf.c
> @@ -114,7 +114,7 @@ static int sound_alloc_dmap(struct dma_buffparms *dmap)
>  		}
>  	}
>  	dmap->raw_buf = start_addr;
> -	dmap->raw_buf_phys = virt_to_bus(start_addr);
> +	dmap->raw_buf_phys = dma_map_single(NULL, start_addr, dmap->buffsize, DMA_BIDIRECTIONAL);
>  
>  	for (page = virt_to_page(start_addr); page <= virt_to_page(end_addr); page++)
>  		SetPageReserved(page);
> @@ -139,6 +139,7 @@ static void sound_free_dmap(struct dma_buffparms *dmap)
>  	for (page = virt_to_page(start_addr); page <= virt_to_page(end_addr); page++)
>  		ClearPageReserved(page);
>  
> +	dma_unmap_single(NULL, dmap->raw_buf_phys, dmap->buffsize, DMA_BIDIRECTIONAL);
>  	free_pages((unsigned long) dmap->raw_buf, sz);
>  	dmap->raw_buf = NULL;
>  }
> -- 
> 1.8.1.2
> 


From prabhakar.csengg at gmail.com  Fri Apr 26 01:46:28 2013
From: prabhakar.csengg at gmail.com (Prabhakar Lad)
Date: Fri, 26 Apr 2013 11:16:28 +0530
Subject: [PATCH 0/6] Davinci fbdev driver and enable it for DMx platform
In-Reply-To: <1780031.B4OAypccep@avalon>
References: <1366804808-22720-1-git-send-email-prabhakar.csengg@gmail.com>
 <1780031.B4OAypccep@avalon>
Message-ID: <CA+V-a8sLD2dP1RLb8ibZDOsLCP8hhMNUTr-zzU1zx_2ALDaDrg@mail.gmail.com>

Hi Laurent,

On Thu, Apr 25, 2013 at 2:32 AM, Laurent Pinchart
<laurent.pinchart at ideasonboard.com> wrote:
> Hi Prabhakar,
>
> Thank you for the patch.
>
> On Wednesday 24 April 2013 17:30:02 Prabhakar Lad wrote:
>> From: Lad, Prabhakar <prabhakar.csengg at gmail.com>
>>
>> This patch series adds an fbdev driver for Texas
>> Instruments Davinci SoC.The display subsystem consists
>> of OSD and VENC, with OSD supporting 2 RGb planes and
>> 2 video planes.
>> http://focus.ti.com/general/docs/lit/
>> getliterature.tsp?literatureNumber=sprue37d&fileType=pdf
>>
>> A good amount of the OSD and VENC enabling code is
>> present in the kernel, and this patch series adds the
>> fbdev interface.
>>
>> The fbdev driver exports 4 nodes representing each
>> plane to the user - from fb0 to fb3.
>
> The obvious question is: why not a KMS driver instead ? :-)
>
I did go through the KMS model (thanks for pointing to your work and the video)
and it looks like this would require a fair amount of development, at this point
of time I would go with the current implementation and revisit on KMS model
at later point of time.

Regards,
--Prabhakar


From anup at brainfault.org  Fri Apr 26 02:27:57 2013
From: anup at brainfault.org (Anup Patel)
Date: Fri, 26 Apr 2013 11:57:57 +0530
Subject: [PATCH] ARM: KVM: Allow host virtual timer irq number to be
 different from guest virtual timer irq number
In-Reply-To: <7818033767795756654@unknownmsgid>
References: <1366879534-31578-1-git-send-email-anup.patel@linaro.org>
 <CAEDV+gLKwrxxdoB9NDBLb7CSnXL1j=O7f=2Y_ftXmLfGtTBnbA@mail.gmail.com>
 <CAFEAcA_bPHkZX00ccUFg2mUXdmrui3XeBMg-rgxtsE_4-abeiA@mail.gmail.com>
 <7818033767795756654@unknownmsgid>
Message-ID: <CAAhSdy0N4TJYLZWpkKAkvXF560uYzKGKkBe9-8iEDMdjDQKcHQ@mail.gmail.com>

On Fri, Apr 26, 2013 at 12:21 AM, Christoffer Dall
<cdall at cs.columbia.edu> wrote:
> On Apr 25, 2013, at 11:20 AM, Peter Maydell <peter.maydell at linaro.org> wrote:
>
>> On 25 April 2013 19:04, Christoffer Dall <cdall at cs.columbia.edu> wrote:
>>> I prefer not hard-coding this stuff in the kernel, but let user space
>>> decide this. If we have good technical arguments not to do that (such
>>> as knowing that this is always defined per-core and not for an SoC
>>> (ARM guys?) then at least the patch should lookup the target processor
>>> and set the irq number accordingly.
>>
>> Well, this is all implementation-defined. The ARM ARM mandates
>> that the generic timers deliver a PPI, and that it must be the
>> same PPI for all processors in an MP implementation, but not which
>> PPI. The A15 and A7 happen to both be hardwired to ID27. You could
>> in theory design a core which let the SoC configure the virtual
>> timer ID (or let the guest arbitrarily program it, for that
>> matter, I suppose), though I'm not sure why you'd want to.
>>
>> I think I'd take the simple approach of saying "the timer PPI
>> is a fixed property of the guest CPU" unless somebody actually
>> builds something where it isn't fixed... (for that CPU we
>> could then define it as a feature argument to KVM_ARM_VCPU_INIT).
>>
>
> Ok, let's not bother with user space injection then, but instead of
> hard defaulting to two specific cores, please make a switch statement
> on the target CPU and log an error on init if it's an unknown core.

I agree about determing guest ppi from KVM_TARGET_xxxx in
kvm_timer_vcpu_init() but kvm_timer_vcpu_init() is called much before
kvm_vcpu_set_target() so in kvm_timer_vcpu_init() we have
vcpu->arch.target = -1 (unknown).

To handle this issue, we need to determine vcpu timer irq number when
we inject the timer irq first timer for that vcpu.

> _______________________________________________
> kvmarm mailing list
> kvmarm at lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm

-Anup


From coelho at ti.com  Fri Apr 26 02:31:48 2013
From: coelho at ti.com (Luciano Coelho)
Date: Fri, 26 Apr 2013 09:31:48 +0300
Subject: [PATCH 0/3] WLAN support for omap4 when booted with devicetree
In-Reply-To: <20130426034858.26065.65118.stgit@muffinssi.local>
References: <20130426034858.26065.65118.stgit@muffinssi.local>
Message-ID: <1366957908.4029.15.camel@cumari.coelho.fi>

On Thu, 2013-04-25 at 20:52 -0700, Tony Lindgren wrote:
> Hi all,

Hi Tony,


> Here are some patches against linux next to make WLAN to work with
> device tree. Note that we still are initializing wl12xx with pdata,
> but so far it looks like only minimal binding for it is needed.

Thanks for doing this! I've been out on vacation for the past 3 weeks,
so I didn't manage to finish the wl12xx DT stuff in time for 3.10. :(


> There are various fixes pending posted recently, but at least the
> fix "[PATCH] mmc: omap_hsmmc: Fix the DT pbias workaround for MMC
> controllers 2 to 5" is needed.

I managed to apply the OMAP2+ and the blaze patches.  There were
conflicts with the panda patch, so I skipped it for now.  I'll come back
to it a bit later.


> Please test on blaze/sdp if you have a chance, I don't have the
> connectivity card on mine.

I tested this on Blaze and it seems to work fine! The driver gets probed
and I can power the chip on and off (by putting the interface up and
down) without any problems. :)

BTW, did you (or anyone else) manage to get ethernet to work on Blaze
(or Panda) with DT?

-- 
Luca.



From coelho at ti.com  Fri Apr 26 02:32:40 2013
From: coelho at ti.com (Luciano Coelho)
Date: Fri, 26 Apr 2013 09:32:40 +0300
Subject: [PATCH 1/3] ARM: OMAP2+: Legacy support for wl12xx when booted
 with devicetree
In-Reply-To: <20130426035210.26065.39995.stgit@muffinssi.local>
References: <20130426034858.26065.65118.stgit@muffinssi.local>
 <20130426035210.26065.39995.stgit@muffinssi.local>
Message-ID: <1366957960.4029.16.camel@cumari.coelho.fi>

On Thu, 2013-04-25 at 20:52 -0700, Tony Lindgren wrote:
> Without WLAN we cannot switch omap4 to use device tree
> only booting. This patch can be reverted when the
> binding for wl12xx is added.
> 
> Cc: Luciano Coelho <coelho at ti.com>
> Cc: Benoit Cousson <b-cousson at ti.com>
> Cc: Rajendra Nayak <rnayak at ti.com>
> Cc: devicetree-discuss at lists.ozlabs.org
> Signed-off-by: Tony Lindgren <tony at atomide.com>
> ---

Tested-by: Luciano Coelho <coelho at ti.com>

-- 
Luca.



From coelho at ti.com  Fri Apr 26 02:32:59 2013
From: coelho at ti.com (Luciano Coelho)
Date: Fri, 26 Apr 2013 09:32:59 +0300
Subject: [PATCH 3/3] ARM: dts: Add muxing for wl12xx on the SDIO bus for
 blaze
In-Reply-To: <20130426035216.26065.32776.stgit@muffinssi.local>
References: <20130426034858.26065.65118.stgit@muffinssi.local>
 <20130426035216.26065.32776.stgit@muffinssi.local>
Message-ID: <1366957979.4029.17.camel@cumari.coelho.fi>

On Thu, 2013-04-25 at 20:52 -0700, Tony Lindgren wrote:
> This should work assuming the board-4430sdp.c works, but it seems
> that I don't have the "1283 PG 2.21 connectivity device" on
> my blaze. Anybody got a spare connectivity device for blaze?
> 
> Also, if somebody has the schematics, please provide a patch
> for the missing GPIO muxes for blaze, see the the panda for
> what's currently missing.
> 
> Cc: Luciano Coelho <coelho at ti.com>
> Cc: Benoit Cousson <b-cousson at ti.com>
> Cc: Rajendra Nayak <rnayak at ti.com>
> Cc: Ruslan Bilovol <ruslan.bilovol at ti.com>
> Cc: devicetree-discuss at lists.ozlabs.org
> Signed-off-by: Tony Lindgren <tony at atomide.com>
> ---

Tested-by: Luciano Coelho <coelho at ti.com>

-- 
Luca.



From linus.walleij at linaro.org  Fri Apr 26 02:59:20 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Fri, 26 Apr 2013 08:59:20 +0200
Subject: [PATCH 3/5] gpio/omap: Add DT support to GPIO driver
In-Reply-To: <516C31C3.9040505@wwwdotorg.org>
References: <1329321854-24490-1-git-send-email-b-cousson@ti.com>
 <20130302200524.D230F3E1571@localhost> <51391F41.5000303@ti.com>
 <CAAwP0s1CFRO-rf==p5sYs1n0gigMif7wuT8Yv0N_iLUDMrtcOg@mail.gmail.com>
 <CACRpkdYHj-rEF3Rk_CWnmmMw_Amr7m8SgQ=-2zsDYuLeuu3azw@mail.gmail.com>
 <514C79E1.4090106@wwwdotorg.org> <514CE0AB.6060207@ti.com>
 <CACRpkdZmv-rAoKSQYpkHHSMzKJOn5TixVW_P3=m7ZNagBYCUPw@mail.gmail.com>
 <515319D5.20105@wwwdotorg.org>
 <CACRpkdYXVLgCz1Tyu-Ls2V2OTc4R3cGNJhfQJB6Hiz_K9dkZYQ@mail.gmail.com>
 <5155C902.7080207@wwwdotorg.org>
 <CACRpkdYbs4-uudpRUY8e+7icYYkZrfM0kReP3pLL5DMiURJ4dg@mail.gmail.com>
 <5165CB9D.1090202@wwwdotorg.org>
 <CACRpkdYirFNqmGhA4K9CL4ve4NYhs8Rd3SFt1iwW9vHBkrcz8g@mail.gmail.com>
 <51671D7B.5060303@wwwdotorg.org>
 <CACRpkdbf32Ef77GmXk9id9+RRjcDRTr7S+F4nznoeZU8y=BT_Q@mail.gmail.com>
 <51673D70.3010503@wwwdotorg.org>
 <CAAwP0s0e2x33jZQhFRY+Hoo61SFqYKRgWk=1mL2+DNxSDJHz+A@mail.gmail.com>
 <CACRpkda4h+qXTvsirPAS7E7sjXhMLE62q=VDy53W8UchsYjbNg@mail.gmail.com>
 <516C31C3.9040505@wwwdotorg.org>
Message-ID: <CACRpkdZNvTtjto+kpNOvFK-RZb_N8x04=8b-3ZJdO2bnYaBPvQ@mail.gmail.com>

On Mon, Apr 15, 2013 at 6:58 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
> On 04/14/2013 02:53 PM, Linus Walleij wrote:

>> This is a pretty hard design pattern to properly replicate in every such
>> driver is it not?
>
> Well, instead of adding .request_irq() to the irqchip, and then making
> each driver call gpio_request() from the implementation, perhaps you
> could add a .irq_to_gpio() to the irqchip, have the IRQ core call that,
> and if it gets back a non-error response, the IRQ core could call
> gpio_request(). That means that the change to each GPIO+IRQ driver is
> simply to implement a standalone data transformation function
> .irq_to_gpio().
>
> Now, this does re-introduce irq_to_gpio() in some way, but with the
> following advantages:
>
> 1) The implementation is per-controller, not a single global function,
> so isn't introducing any kind of centralized mapping scheme again.
>
> 2) This irq-chip-specific .irq_to_gpio() would only be implemented for
> IRQ+GPIO chips that actually have a 1:1 mapping between GPIOs and IRQs.
> Its potential existence doesn't imply that all IRQ chips need implement
> this; it would be very specifically be for this one particular case.

I sort of like the idea. It'd have to go past Grant and Thomas G though.

A problem is that this will result in the same kind of dilemma that
the pinctrl subsystem has been facing with mapping the global GPIO
numbers back into local numbers (as is the nature of IRQ numbers).
Such as is done by the GPIO ranges in pinctrl.

The good part is that we now know how to actually contain that, even
how to do it in DT.

Yours,
Linus Walleij


From nsekhar at ti.com  Fri Apr 26 03:01:53 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Fri, 26 Apr 2013 12:31:53 +0530
Subject: [PATCH 1/4] ARM: davinci: uart: move to dev_id based clk_get
In-Reply-To: <1365510664-1394-2-git-send-email-prakash.pm@ti.com>
References: <1365510481-32129-1-git-send-email-prakash.pm@ti.com>
 <1365510664-1394-2-git-send-email-prakash.pm@ti.com>
Message-ID: <517A2661.3000605@ti.com>

Hi Prakash,

On 4/9/2013 6:01 PM, Manjunathappa, Prakash wrote:
> For modules having single clock, clk_get should be done with dev_id.
> But current davinci implementation handles multiple instances
> of the UART devices with single platform_device_register. Hence clk_get
> is based on con_id rather than dev_id, this is not correct. Do
> platform_device_register for each instance and clk_get on dev_id.
> 
> Signed-off-by: Manjunathappa, Prakash <prakash.pm at ti.com>
> ---
>  arch/arm/mach-davinci/da830.c                  |    8 ++--
>  arch/arm/mach-davinci/da850.c                  |    8 ++--
>  arch/arm/mach-davinci/devices-da8xx.c          |   40 ++++++++++++++++---
>  arch/arm/mach-davinci/devices-tnetv107x.c      |   35 ++++++++++++++---
>  arch/arm/mach-davinci/dm355.c                  |   48 ++++++++++++++++++-----
>  arch/arm/mach-davinci/dm365.c                  |   35 ++++++++++++----
>  arch/arm/mach-davinci/dm644x.c                 |   48 ++++++++++++++++++-----
>  arch/arm/mach-davinci/dm646x.c                 |   49 +++++++++++++++++++-----
>  arch/arm/mach-davinci/include/mach/da8xx.h     |    2 +-
>  arch/arm/mach-davinci/include/mach/tnetv107x.h |    2 +-
>  arch/arm/mach-davinci/serial.c                 |   19 ++++++---
>  arch/arm/mach-davinci/tnetv107x.c              |    8 ++--
>  12 files changed, 230 insertions(+), 72 deletions(-)

[...]

> diff --git a/arch/arm/mach-davinci/devices-da8xx.c b/arch/arm/mach-davinci/devices-da8xx.c
> index fc50243..eec7132 100644
> --- a/arch/arm/mach-davinci/devices-da8xx.c
> +++ b/arch/arm/mach-davinci/devices-da8xx.c
> @@ -67,7 +67,7 @@
>  void __iomem *da8xx_syscfg0_base;
>  void __iomem *da8xx_syscfg1_base;
>  
> -static struct plat_serial8250_port da8xx_serial_pdata[] = {
> +static struct plat_serial8250_port da8xx_serial_pdata0[] = {

da8xx_serial0_pdata is more appropriate. Likewise for other entries below.

>  	{
>  		.mapbase	= DA8XX_UART0_BASE,
>  		.irq		= IRQ_DA8XX_UARTINT0,
> @@ -77,6 +77,11 @@ static struct plat_serial8250_port da8xx_serial_pdata[] = {
>  		.regshift	= 2,
>  	},
>  	{
> +		.flags	= 0,
> +	},

No need of trailing ',' on sentinel. No need of the zero initialization.
Here and other places below.

> +};
> +static struct plat_serial8250_port da8xx_serial_pdata1[] = {
> +	{
>  		.mapbase	= DA8XX_UART1_BASE,
>  		.irq		= IRQ_DA8XX_UARTINT1,
>  		.flags		= UPF_BOOT_AUTOCONF | UPF_SKIP_TEST |
> @@ -85,6 +90,11 @@ static struct plat_serial8250_port da8xx_serial_pdata[] = {
>  		.regshift	= 2,
>  	},
>  	{
> +		.flags	= 0,
> +	},
> +};
> +static struct plat_serial8250_port da8xx_serial_pdata2[] = {
> +	{
>  		.mapbase	= DA8XX_UART2_BASE,
>  		.irq		= IRQ_DA8XX_UARTINT2,
>  		.flags		= UPF_BOOT_AUTOCONF | UPF_SKIP_TEST |
> @@ -97,11 +107,29 @@ static struct plat_serial8250_port da8xx_serial_pdata[] = {
>  	},
>  };
>  
> -struct platform_device da8xx_serial_device = {
> -	.name	= "serial8250",
> -	.id	= PLAT8250_DEV_PLATFORM,
> -	.dev	= {
> -		.platform_data	= da8xx_serial_pdata,
> +struct platform_device da8xx_serial_device[] = {
> +	{
> +		.name	= "serial8250",
> +		.id	= PLAT8250_DEV_PLATFORM,
> +		.dev	= {
> +			.platform_data	= da8xx_serial_pdata0,
> +		},
> +	},
> +	{
> +		.name	= "serial8250",
> +		.id	= PLAT8250_DEV_PLATFORM1,
> +		.dev	= {
> +			.platform_data	= da8xx_serial_pdata1,
> +		},
> +	},
> +	{
> +		.name	= "serial8250",
> +		.id	= PLAT8250_DEV_PLATFORM2,
> +		.dev	= {
> +			.platform_data	= da8xx_serial_pdata2,
> +		},
> +	},
> +	{
>  	},
>  };

[...]

> diff --git a/arch/arm/mach-davinci/serial.c b/arch/arm/mach-davinci/serial.c
> index f262581..57e6150 100644
> --- a/arch/arm/mach-davinci/serial.c
> +++ b/arch/arm/mach-davinci/serial.c
> @@ -76,7 +76,7 @@ int __init davinci_serial_setup_clk(unsigned instance, unsigned int *rate)
>  	char name[16];
>  	struct clk *clk;
>  	struct davinci_soc_info *soc_info = &davinci_soc_info;
> -	struct device *dev = &soc_info->serial_dev->dev;
> +	struct device *dev = &soc_info->serial_dev[instance].dev;
>  
>  	sprintf(name, "uart%d", instance);
>  	clk = clk_get(dev, name);

Why not pass con_id = NULL now?

> @@ -96,19 +96,25 @@ int __init davinci_serial_setup_clk(unsigned instance, unsigned int *rate)
>  
>  int __init davinci_serial_init(struct davinci_uart_config *info)
>  {
> -	int i, ret;
> +	int i, ret = 0;
>  	struct davinci_soc_info *soc_info = &davinci_soc_info;
> -	struct device *dev = &soc_info->serial_dev->dev;
> -	struct plat_serial8250_port *p = dev->platform_data;
> +	struct device *dev;
> +	struct plat_serial8250_port *p;
>  
>  	/*
>  	 * Make sure the serial ports are muxed on at this point.
>  	 * You have to mux them off in device drivers later on if not needed.
>  	 */
> -	for (i = 0; p->flags; i++, p++) {
> +	for (i = 0; soc_info->serial_dev[i].dev.platform_data != NULL; i++) {
> +		dev = &soc_info->serial_dev[i].dev;
> +		p = dev->platform_data;
>  		if (!(info->enabled_uarts & (1 << i)))
>  			continue;
>  
> +		ret = platform_device_register(&soc_info->serial_dev[i]);
> +		if (ret)
> +			continue;
> +
>  		ret = davinci_serial_setup_clk(i, &p->uartclk);
>  		if (ret)
>  			continue;
> @@ -125,6 +131,5 @@ int __init davinci_serial_init(struct davinci_uart_config *info)
>  		if (p->membase && p->type != PORT_AR7)
>  			davinci_serial_reset(p);
>  	}
> -
> -	return platform_device_register(soc_info->serial_dev);
> +	return ret;
>  }

Now that we are overhauling this part of code, some improvements can be
done. First, get rid of struct davinci_uart_config. None of the board
files use it meaningfully and we know we are not going to have more
board files. Second, make davinci_serial_init() take pointer to serial
platform device directly. This eliminates need for serial_dev in the
soc_info structure (yay!). You might also find that
davinci_serial_setup_clk() can be eliminated as well since there is not
much to do there now.

Thanks,
Sekhar


From sfr at canb.auug.org.au  Fri Apr 26 03:06:49 2013
From: sfr at canb.auug.org.au (Stephen Rothwell)
Date: Fri, 26 Apr 2013 17:06:49 +1000
Subject: linux-next: manual merge of the arm-soc tree with the spi-mb tree
Message-ID: <20130426170649.d21c2d7a74e56d836ff6f04f@canb.auug.org.au>

Hi all,

Today's linux-next merge of the arm-soc tree got a conflict in
arch/arm/boot/dts/at91sam9x5.dtsi between commits d50f88a0c304 ("ARM:
dts: add spi nodes for atmel SoC") and a68b728f7a21 ("ARM: dts: add
pinctrl property for spi node for atmel SoC") from the spi-mb tree and
commits e9a72ee81d58 ("ARM: at91: dt: at91sam9x5: add i2c pinctrl"),
463c9c7bf1f3 ("ARM: at91: dt: at91sam9x5: add i2c-gpio pinctrl") and
b909c6c94462 ("ARM: at91/at91sam9x5: add RTC node") from the arm-soc tree.

I fixed it up (hopefully - see below) and can carry the fix as necessary
(no action is required).

-- 
Cheers,
Stephen Rothwell                    sfr at canb.auug.org.au

diff --cc arch/arm/boot/dts/at91sam9x5.dtsi
index 347b438,284bf24..0000000
--- a/arch/arm/boot/dts/at91sam9x5.dtsi
+++ b/arch/arm/boot/dts/at91sam9x5.dtsi
@@@ -343,23 -343,53 +343,70 @@@
  					};
  				};
  
 +				spi0 {
 +					pinctrl_spi0: spi0-0 {
 +						atmel,pins =
 +							<0 11 0x1 0x0	/* PA11 periph A SPI0_MISO pin */
 +							 0 12 0x1 0x0	/* PA12 periph A SPI0_MOSI pin */
 +							 0 13 0x1 0x0>;	/* PA13 periph A SPI0_SPCK pin */
 +					};
 +				};
 +
 +				spi1 {
 +					pinctrl_spi1: spi1-0 {
 +						atmel,pins =
 +							<0 21 0x2 0x0	/* PA21 periph B SPI1_MISO pin */
 +							 0 22 0x2 0x0	/* PA22 periph B SPI1_MOSI pin */
 +							 0 23 0x2 0x0>;	/* PA23 periph B SPI1_SPCK pin */
 +					};
 +				};
+ 				i2c0 {
+ 					pinctrl_i2c0: i2c0-0 {
+ 						atmel,pins =
+ 							<0 30 0x1 0x0	/* PA30 periph A I2C0 data */
+ 							 0 31 0x1 0x0>;	/* PA31 periph A I2C0 clock */
+ 					};
+ 				};
+ 
+ 				i2c1 {
+ 					pinctrl_i2c1: i2c1-0 {
+ 						atmel,pins =
+ 							<2 0 0x3 0x0	/* PC0 periph C I2C1 data */
+ 							 2 1 0x3 0x0>;	/* PC1 periph C I2C1 clock */
+ 					};
+ 				};
+ 
+ 				i2c2 {
+ 					pinctrl_i2c2: i2c2-0 {
+ 						atmel,pins =
+ 							<1 4 0x2 0x0	/* PB4 periph B I2C2 data */
+ 							 1 5 0x2 0x0>;	/* PB5 periph B I2C2 clock */
+ 					};
+ 				};
+ 
+ 				i2c_gpio0 {
+ 					pinctrl_i2c_gpio0: i2c_gpio0-0 {
+ 						atmel,pins =
+ 							<0 30 0x0 0x2	/* PA30 gpio multidrive I2C0 data */
+ 							 0 31 0x0 0x2>;	/* PA31 gpio multidrive I2C0 clock */
+ 					};
+ 				};
+ 
+ 				i2c_gpio1 {
+ 					pinctrl_i2c_gpio1: i2c_gpio1-0 {
+ 						atmel,pins =
+ 							<2 0 0x0 0x2	/* PC0 gpio multidrive I2C1 data */
+ 							 2 1 0x0 0x2>;	/* PC1 gpio multidrive I2C1 clock */
+ 					};
+ 				};
+ 
+ 				i2c_gpio2 {
+ 					pinctrl_i2c_gpio2: i2c_gpio2-0 {
+ 						atmel,pins =
+ 							<1 4 0x0 0x2	/* PB4 gpio multidrive I2C2 data */
+ 							 1 5 0x0 0x2>;	/* PB5 gpio multidrive I2C2 clock */
+ 					};
+ 				};
  
  				pioA: gpio at fffff400 {
  					compatible = "atmel,at91sam9x5-gpio", "atmel,at91rm9200-gpio";
@@@ -548,27 -587,12 +604,33 @@@
  				};
  			};
  
 +			spi0: spi at f0000000 {
 +				#address-cells = <1>;
 +				#size-cells = <0>;
 +				compatible = "atmel,at91rm9200-spi";
 +				reg = <0xf0000000 0x100>;
 +				interrupts = <13 4 3>;
 +				pinctrl-names = "default";
 +				pinctrl-0 = <&pinctrl_spi0>;
 +				status = "disabled";
 +			};
 +
 +			spi1: spi at f0004000 {
 +				#address-cells = <1>;
 +				#size-cells = <0>;
 +				compatible = "atmel,at91rm9200-spi";
 +				reg = <0xf0004000 0x100>;
 +				interrupts = <14 4 3>;
 +				pinctrl-names = "default";
 +				pinctrl-0 = <&pinctrl_spi1>;
 +				status = "disabled";
 +			};
+ 			rtc at fffffeb0 {
+ 				compatible = "atmel,at91rm9200-rtc";
+ 				reg = <0xfffffeb0 0x40>;
+ 				interrupts = <1 4 7>;
+ 				status = "disabled";
+ 			};
  		};
  
  		nand0: nand at 40000000 {
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130426/00aa3f43/attachment.sig>

From rnayak at ti.com  Fri Apr 26 03:08:31 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Fri, 26 Apr 2013 12:38:31 +0530
Subject: [PATCH 2/8] ARM: OMAP2+: hwmod: Cleanup sidle/mstandby programming
In-Reply-To: <alpine.DEB.2.00.1304230804410.30196@utopia.booyaka.com>
References: <1361354272-18089-1-git-send-email-santosh.shilimkar@ti.com>
 <1361354272-18089-3-git-send-email-santosh.shilimkar@ti.com>
 <alpine.DEB.2.00.1303310053351.6436@utopia.booyaka.com>
 <515947D3.50904@ti.com> <516FD093.1020607@ti.com>
 <alpine.DEB.2.00.1304230804410.30196@utopia.booyaka.com>
Message-ID: <517A27EF.40408@ti.com>

On Tuesday 23 April 2013 01:49 PM, Paul Walmsley wrote:
> Hi Rajendra,
> 
> On Thu, 18 Apr 2013, Rajendra Nayak wrote:
> 
>>>>> _enable_wakeup() and _disable_wakeup() are expected to program the
>>>>> OCP_SYSCONFIG.ENAWAKEUP bit.
>>>>
>>>> These functions were originally intended to take care of everything needed 
>>>> for the IP block to wake up the chip, including the PRCM WKEN programming.  
>>>> ENAWAKEUP is simply one part of that.
>>>>
>>>>> Get rid of the additional sidle/mstandby programming in them, as its 
>>>>> confusing (this is expected to be handled elsewhere as part of 
>>>>> _enable_sysc()/__idle_sysc())
>>>>
>>>> Sorry, why does the expectation exist for the code to enable and disable 
>>>> device wakeup to be part of _enable_sysc()/_idle_sysc(), rather than in 
>>>> functions called by _enable_sysc()/_idle_sysc()?
>>>
>>> It all comes down to if SIDLE_SMART_WKUP/MSTANDBY_SMART_WKUP programming
>>> be considered as 'idlemode' programming or 'enwakeup' programming.
>>> If you consider these are being part of 'enwakeup' progrmming, these should
>>> certainly be handled as part of _enable_wakeup() and _disable_wakeup().
>>>
>>> Today, in some cases, these are *also* handled as part of _enable_sysc()
>>> and _idle_sysc(). The way _enable_wakeup() is invoked from _enable_sysc()
>>> is also very inconsistent. For instance, for any IP which supports
>>> SYSC_HAS_MIDLEMODE and SYSC_HAS_ENAWAKEUP, we invoke _enable_wakeup()
>>> regardless of the MIDLEMODE programmmed.
>>> While in case of the IP supporting SYSC_HAS_SIDLEMODE, _enable_wakeup() is
>>> invoked only when the SIDLEMODE programmed is SMART or SMART_WKUP.
>>>
>>> I understand the cleanups you are suggesting below as part of the movement
>>> of some of these things outside of mach-omap2.
>>> I was more looking at fixing the existing piece so its readable and does
>>> things more consistently.
>>
>> Do you have any further thoughts on how we should do about this?
> 
> Is it possible to implement a solution that preserves _enable_wakeup() and 
> _disable_wakeup() as distinct functions, that can be called by separate 
> wakeup control entry points?
> 
> If it makes sense to change _enable_sysc() so that it doesn't call 
> _enable_wakeup(), but does similar work itself, that's fine with me, as 
> long as there's not too much code duplication.
> 
> It will be good to have the inconsistencies fixed.

Sure, I'll post something on those lines shortly.

regards,
Rajendra
> 
> 
> - Paul
> 



From linus.walleij at linaro.org  Fri Apr 26 03:11:09 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Fri, 26 Apr 2013 09:11:09 +0200
Subject: [PATCH 3/5] gpio/omap: Add DT support to GPIO driver
In-Reply-To: <516C73C6.5050409@ti.com>
References: <1329321854-24490-1-git-send-email-b-cousson@ti.com>
 <51391F41.5000303@ti.com>
 <CAAwP0s1CFRO-rf==p5sYs1n0gigMif7wuT8Yv0N_iLUDMrtcOg@mail.gmail.com>
 <CACRpkdYHj-rEF3Rk_CWnmmMw_Amr7m8SgQ=-2zsDYuLeuu3azw@mail.gmail.com>
 <514C79E1.4090106@wwwdotorg.org> <514CE0AB.6060207@ti.com>
 <CACRpkdZmv-rAoKSQYpkHHSMzKJOn5TixVW_P3=m7ZNagBYCUPw@mail.gmail.com>
 <515319D5.20105@wwwdotorg.org>
 <CACRpkdYXVLgCz1Tyu-Ls2V2OTc4R3cGNJhfQJB6Hiz_K9dkZYQ@mail.gmail.com>
 <5155C902.7080207@wwwdotorg.org>
 <CACRpkdYbs4-uudpRUY8e+7icYYkZrfM0kReP3pLL5DMiURJ4dg@mail.gmail.com>
 <5165CB9D.1090202@wwwdotorg.org>
 <CACRpkdYirFNqmGhA4K9CL4ve4NYhs8Rd3SFt1iwW9vHBkrcz8g@mail.gmail.com>
 <51671D7B.5060303@wwwdotorg.org>
 <CACRpkdbf32Ef77GmXk9id9+RRjcDRTr7S+F4nznoeZU8y=BT_Q@mail.gmail.com>
 <51673D70.3010503@wwwdotorg.org>
 <CAAwP0s0e2x33jZQhFRY+Hoo61SFqYKRgWk=1mL2+DNxSDJHz+A@mail.gmail.com>
 <CACRpkda4h+qXTvsirPAS7E7sjXhMLE62q=VDy53W8UchsYjbNg@mail.gmail.com>
 <516C31C3.9040505@wwwdotorg.org> <516C73C6.5050409@ti.com>
Message-ID: <CACRpkdaDmnDTE_jfz8cvFOrkAUv0mt3mkULGh71HxpRHGz0qJw@mail.gmail.com>

On Mon, Apr 15, 2013 at 11:40 PM, Jon Hunter <jon-hunter at ti.com> wrote:

> I am still concerned about the case where a driver may have already
> called gpio_request() and then calls request_irq(). I think that the
> solution needs to handle cases where the driver may or may not call
> gpio_request() to allocate the gpio.

So take a step back and you see that this is my actual fear and why
I'm so hesitant about this patch to begin with.

I wanted drivers to follow the sequence:
gpio_request(), gpio_to_irq(), request_irq()

Now if request_irq() can implicitly perform gpio_request(), we end
up with a semantic confusing mess like this where we are
uncertain as to whether we should use the irq we obtain elsewhere
(like from a resource on the platform device)) or maybe use
gpio_to_irq() to convert it into an IRQ or not or ...

It is certainly true that for some devices we don't want to know if
the IRQ comes from a hard-wired IRQ line or from a GPIO line
playing the r?le of IRQ controller, so we need to handle that.

But then the drivers need to be consistent, and relying solely on
code review to stop people from doing mixtures like the described
is not working, the subsystem must enforce a proper policy.

Yours,
Linus Walleij


From richard.genoud at gmail.com  Fri Apr 26 03:21:36 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Fri, 26 Apr 2013 09:21:36 +0200
Subject: linux-next: manual merge of the arm-soc tree with the spi-mb tree
In-Reply-To: <20130426170649.d21c2d7a74e56d836ff6f04f@canb.auug.org.au>
References: <20130426170649.d21c2d7a74e56d836ff6f04f@canb.auug.org.au>
Message-ID: <CACQ1gAidYqDm_SHea9jQFGqernZpgT8RuaRSP2N0ZPUX7JYyrA@mail.gmail.com>

2013/4/26 Stephen Rothwell <sfr at canb.auug.org.au>:
> Hi all,
>
> Today's linux-next merge of the arm-soc tree got a conflict in
> arch/arm/boot/dts/at91sam9x5.dtsi between commits d50f88a0c304 ("ARM:
> dts: add spi nodes for atmel SoC") and a68b728f7a21 ("ARM: dts: add
> pinctrl property for spi node for atmel SoC") from the spi-mb tree and
> commits e9a72ee81d58 ("ARM: at91: dt: at91sam9x5: add i2c pinctrl"),
> 463c9c7bf1f3 ("ARM: at91: dt: at91sam9x5: add i2c-gpio pinctrl") and
> b909c6c94462 ("ARM: at91/at91sam9x5: add RTC node") from the arm-soc tree.
>
> I fixed it up (hopefully - see below) and can carry the fix as necessary
> (no action is required).

Hi,

It's all ok for me !

Thanks,

Richard.


From linus.walleij at linaro.org  Fri Apr 26 03:27:10 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Fri, 26 Apr 2013 09:27:10 +0200
Subject: [PATCH 3/5] gpio/omap: Add DT support to GPIO driver
In-Reply-To: <516EC2AF.9090905@wwwdotorg.org>
References: <1329321854-24490-1-git-send-email-b-cousson@ti.com>
 <514CE0AB.6060207@ti.com>
 <CACRpkdZmv-rAoKSQYpkHHSMzKJOn5TixVW_P3=m7ZNagBYCUPw@mail.gmail.com>
 <515319D5.20105@wwwdotorg.org>
 <CACRpkdYXVLgCz1Tyu-Ls2V2OTc4R3cGNJhfQJB6Hiz_K9dkZYQ@mail.gmail.com>
 <5155C902.7080207@wwwdotorg.org>
 <CACRpkdYbs4-uudpRUY8e+7icYYkZrfM0kReP3pLL5DMiURJ4dg@mail.gmail.com>
 <5165CB9D.1090202@wwwdotorg.org>
 <CACRpkdYirFNqmGhA4K9CL4ve4NYhs8Rd3SFt1iwW9vHBkrcz8g@mail.gmail.com>
 <51671D7B.5060303@wwwdotorg.org>
 <CACRpkdbf32Ef77GmXk9id9+RRjcDRTr7S+F4nznoeZU8y=BT_Q@mail.gmail.com>
 <51673D70.3010503@wwwdotorg.org>
 <CAAwP0s0e2x33jZQhFRY+Hoo61SFqYKRgWk=1mL2+DNxSDJHz+A@mail.gmail.com>
 <CACRpkda4h+qXTvsirPAS7E7sjXhMLE62q=VDy53W8UchsYjbNg@mail.gmail.com>
 <516C31C3.9040505@wwwdotorg.org> <516C7C43.3040105@wwwdotorg.org>
 <516C8760.2050500@ti.com> <516D9B05.1000501@wwwdotorg.org>
 <516DA60A.5070000@ti.com> <516DCCA8.3070108@wwwdotorg.org>
 <516DDB4D.9020500@ti.com> <516EC2AF.9090905@wwwdotorg.org>
Message-ID: <CACRpkdaOOrooK7kff2Y-7gH6L6m-MsiU7PfHnqBkPpc=tk_iWA@mail.gmail.com>

On Wed, Apr 17, 2013 at 5:41 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
> On 04/16/2013 05:14 PM, Jon Hunter wrote:

>>> c) I have the feeling that hooking the of_xlate function for this is a
>>> bit of an abuse of the function.
>>
>> I was wondering about that. So I was grep'ing through the various xlate
>> implementations and found this [1]. Also you may recall that in the
>> of_dma_simple_xlate() we call the dma_request_channel() to allocate the
>> channel, which is very similar. However, I don't wish to get a
>> reputation as abusing APIs so would be good to know if this really is
>> abuse or not ;-)
>>
>> Cheers
>> Jon
>>
>> [1] http://permalink.gmane.org/gmane.linux.ports.arm.kernel/195124
>
> Interesting.
>
> This is really something that the core DT and GPIO and IRQ maintainers
> should weigh in on. Hence, changing them from Cc: to To: in this message
> and/or adding them.

So I guess it is OK for a driver or DT node to use a GPIO as IRQ
*only*, and then have the GPIO requested implicitly through the
xlate function in the irqdomain.

It's the use cases where one and the same driver tries to use the
same GPIO line *also* by requesting it using gpio_request()
that madness starts. In such cases the driver deserves to have
an error thrown back at it, as it definately knows the GPIO pin
and can be refactored to use gpio_to_irq() to translate it into
an IRQ rather than having it implicitly done in the xlate function.

You will just have to give the xlate function information about which
GPIOs are used as IRQs only, and only request the GPIO on these.

And I recently suggested a mechanism to do that, and that is
what I called GPIO input-hogs, which means that you mark
(e.g. from the device tree) at probe() of the gpiochip which GPIOs
will only be used as inputs, so as to generate IRQs.

This is perfectly OS-neutral information about the how the
hardware is set up in the system.

If you only allow these hogges inputs to be translated and
requested in the xlate function, everything goes smooth.

It all comes back to this: keep all applicable knowledge in the
system, so it can make proper decisions, don't try to create
mechanisms that will half-guess things.

Yours,
Linus Walleij


From anup.patel at linaro.org  Fri Apr 26 03:21:50 2013
From: anup.patel at linaro.org (Anup Patel)
Date: Fri, 26 Apr 2013 12:51:50 +0530
Subject: [PATCH V2] ARM: KVM: Allow host virtual timer irq number to be
 different from guest virtual timer irq number
Message-ID: <1366960910-27651-1-git-send-email-anup.patel@linaro.org>

The arch_timer irq numbers (or PPI number) are implementation dependent so, the host virtual timer irq number can be different from guest virtual timer irq number.

This patch ensures that host virtual timer irq number is read from DTB and guest virtual timer irq is determined based on guest vcpu target type.

Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar at linaro.org>
---
 arch/arm/include/asm/kvm_host.h |    1 +
 arch/arm/kvm/arch_timer.c       |   25 ++++++++++++++++++-------
 arch/arm/kvm/guest.c            |   15 +++++++++++++++
 3 files changed, 34 insertions(+), 7 deletions(-)

diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
index 57cb786..cdc0551 100644
--- a/arch/arm/include/asm/kvm_host.h
+++ b/arch/arm/include/asm/kvm_host.h
@@ -43,6 +43,7 @@
 struct kvm_vcpu;
 u32 *kvm_vcpu_reg(struct kvm_vcpu *vcpu, u8 reg_num, u32 mode);
 int kvm_target_cpu(void);
+struct kvm_irq_level *kvm_target_timer_irq(struct kvm_vcpu *vcpu);
 int kvm_reset_vcpu(struct kvm_vcpu *vcpu);
 void kvm_reset_coprocs(struct kvm_vcpu *vcpu);
 
diff --git a/arch/arm/kvm/arch_timer.c b/arch/arm/kvm/arch_timer.c
index 49a7516..521cdb9 100644
--- a/arch/arm/kvm/arch_timer.c
+++ b/arch/arm/kvm/arch_timer.c
@@ -30,7 +30,7 @@
 
 static struct timecounter *timecounter;
 static struct workqueue_struct *wqueue;
-static struct kvm_irq_level timer_irq = {
+static struct kvm_irq_level host_timer_irq = {
 	.level	= 1,
 };
 
@@ -65,10 +65,21 @@ static void kvm_timer_inject_irq(struct kvm_vcpu *vcpu)
 {
 	struct arch_timer_cpu *timer = &vcpu->arch.timer_cpu;
 
+	/*
+	 * The vcpu timer irq number cannont be determined in 
+	 * kvm_timer_vcpu_init() because it is called much before
+	 * kvm_vcpu_set_target(). To handle this, we determin
+	 * vcpu timer irq number when we inject the vcpu timer irq
+	 * first time. 
+	 */
+	if (!timer->irq) {
+		timer->irq = kvm_target_timer_irq(vcpu);
+	}
+
 	timer->cntv_ctl |= ARCH_TIMER_CTRL_IT_MASK;
 	kvm_vgic_inject_irq(vcpu->kvm, vcpu->vcpu_id,
-			    vcpu->arch.timer_cpu.irq->irq,
-			    vcpu->arch.timer_cpu.irq->level);
+			    timer->irq->irq,
+			    timer->irq->level);
 }
 
 static irqreturn_t kvm_arch_timer_handler(int irq, void *dev_id)
@@ -163,12 +174,12 @@ void kvm_timer_vcpu_init(struct kvm_vcpu *vcpu)
 	INIT_WORK(&timer->expired, kvm_timer_inject_irq_work);
 	hrtimer_init(&timer->timer, CLOCK_MONOTONIC, HRTIMER_MODE_ABS);
 	timer->timer.function = kvm_timer_expire;
-	timer->irq = &timer_irq;
+	timer->irq = NULL;
 }
 
 static void kvm_timer_init_interrupt(void *info)
 {
-	enable_percpu_irq(timer_irq.irq, 0);
+	enable_percpu_irq(host_timer_irq.irq, 0);
 }
 
 
@@ -182,7 +193,7 @@ static int kvm_timer_cpu_notify(struct notifier_block *self,
 		break;
 	case CPU_DYING:
 	case CPU_DYING_FROZEN:
-		disable_percpu_irq(timer_irq.irq);
+		disable_percpu_irq(host_timer_irq.irq);
 		break;
 	}
 
@@ -230,7 +241,7 @@ int kvm_timer_hyp_init(void)
 		goto out;
 	}
 
-	timer_irq.irq = ppi;
+	host_timer_irq.irq = ppi;
 
 	err = register_cpu_notifier(&kvm_timer_cpu_nb);
 	if (err) {
diff --git a/arch/arm/kvm/guest.c b/arch/arm/kvm/guest.c
index 152d036..d87b05d 100644
--- a/arch/arm/kvm/guest.c
+++ b/arch/arm/kvm/guest.c
@@ -36,6 +36,11 @@ struct kvm_stats_debugfs_item debugfs_entries[] = {
 	{ NULL }
 };
 
+struct kvm_irq_level target_default_timer_irq = {
+	.irq = 27,
+	.level = 1,
+};
+
 int kvm_arch_vcpu_setup(struct kvm_vcpu *vcpu)
 {
 	return 0;
@@ -197,6 +202,16 @@ int __attribute_const__ kvm_target_cpu(void)
 	}
 }
 
+struct kvm_irq_level *kvm_target_timer_irq(struct kvm_vcpu *vcpu)
+{
+	switch (vcpu->arch.target) {
+	case KVM_ARM_TARGET_CORTEX_A15:
+		return &target_default_timer_irq;
+	default:
+		return NULL;
+	};
+}
+
 int kvm_vcpu_set_target(struct kvm_vcpu *vcpu,
 			const struct kvm_vcpu_init *init)
 {
-- 
1.7.9.5



From linus.walleij at linaro.org  Fri Apr 26 03:31:46 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Fri, 26 Apr 2013 09:31:46 +0200
Subject: [PATCH 3/5] gpio/omap: Add DT support to GPIO driver
In-Reply-To: <CAAwP0s0-VNUoeSKaGbvoDeD7m7kZRdp5rCJ7iVpFoFAaQtXcmQ@mail.gmail.com>
References: <1329321854-24490-1-git-send-email-b-cousson@ti.com>
 <514C79E1.4090106@wwwdotorg.org> <514CE0AB.6060207@ti.com>
 <CACRpkdZmv-rAoKSQYpkHHSMzKJOn5TixVW_P3=m7ZNagBYCUPw@mail.gmail.com>
 <515319D5.20105@wwwdotorg.org>
 <CACRpkdYXVLgCz1Tyu-Ls2V2OTc4R3cGNJhfQJB6Hiz_K9dkZYQ@mail.gmail.com>
 <5155C902.7080207@wwwdotorg.org>
 <CACRpkdYbs4-uudpRUY8e+7icYYkZrfM0kReP3pLL5DMiURJ4dg@mail.gmail.com>
 <5165CB9D.1090202@wwwdotorg.org>
 <CACRpkdYirFNqmGhA4K9CL4ve4NYhs8Rd3SFt1iwW9vHBkrcz8g@mail.gmail.com>
 <51671D7B.5060303@wwwdotorg.org>
 <CACRpkdbf32Ef77GmXk9id9+RRjcDRTr7S+F4nznoeZU8y=BT_Q@mail.gmail.com>
 <51673D70.3010503@wwwdotorg.org>
 <CAAwP0s0e2x33jZQhFRY+Hoo61SFqYKRgWk=1mL2+DNxSDJHz+A@mail.gmail.com>
 <CACRpkda4h+qXTvsirPAS7E7sjXhMLE62q=VDy53W8UchsYjbNg@mail.gmail.com>
 <516C31C3.9040505@wwwdotorg.org> <516C7C43.3040105@wwwdotorg.org>
 <516C8760.2050500@ti.com> <516D9B05.1000501@wwwdotorg.org>
 <516DA60A.5070000@ti.com> <516DCCA8.3070108@wwwdotorg.org>
 <516DDB4D.9020500@ti.com>
 <CAAwP0s0-VNUoeSKaGbvoDeD7m7kZRdp5rCJ7iVpFoFAaQtXcmQ@mail.gmail.com>
Message-ID: <CACRpkdaA_7Feuui-S65m--2FfvpoUkfn6b9SoWavAstZUS23ag@mail.gmail.com>

On Wed, Apr 17, 2013 at 2:41 AM, Javier Martinez Canillas
<martinez.javier at gmail.com> wrote:

So:

> +static int omap_gpio_irq_domain_xlate(struct irq_domain *d,
> +                                     struct device_node *ctrlr,
> +                                     const u32 *intspec, unsigned int intsize,
> +                                     irq_hw_number_t *out_hwirq,
> +                                     unsigned int *out_type)
> +{
> +       int ret;
> +       struct gpio_bank *bank = d->host_data;
> +       int gpio = bank->chip.base + intspec[0];
> +
> +       if (WARN_ON(intsize < 2))
> +               return -EINVAL;
> +
> +       ret = gpio_request_one(gpio, GPIOF_IN, ctrlr->full_name);
> +       if (ret)
> +               return ret;

So how to figure out if a device is already requesting this GPIO
on some orthogonal axis?

if (this_gpio_was_hogged_as_input_in_gpiolib) {
   ret = gpio_request_on()...
}

Is my suggestion, then you can explicitly mark which GPIOs
shall have their IRQs implicitly translated to GPIOs and
requested.

Alas, this requires the DTS:es to have this hogging added, but
it is fully backwards-compatible.

Then the applicabl OMAP drivers (like MMC) can be fixed to
do gpio_to_irq() on  their pins instead of using the IRQ
directly.

Yours,
Linus Walleij


From Wenyou.Yang at atmel.com  Fri Apr 26 03:48:51 2013
From: Wenyou.Yang at atmel.com (Yang, Wenyou)
Date: Fri, 26 Apr 2013 07:48:51 +0000
Subject: linux-next: manual merge of the arm-soc tree with the spi-mb tree
In-Reply-To: <20130426170649.d21c2d7a74e56d836ff6f04f@canb.auug.org.au>
References: <20130426170649.d21c2d7a74e56d836ff6f04f@canb.auug.org.au>
Message-ID: <B256D81BAE5131468A838E5D7A24364154234E9D@penmbx02>

Hi,

It is OK for spi

Thanks

Best Regards,
Wenyou Yang

> -----Original Message-----
> From: Stephen Rothwell [mailto:sfr at canb.auug.org.au]
> Sent: 2013?4?26? 15:07
> To: Olof Johansson; Arnd Bergmann; linux-arm-kernel at lists.infradead.org
> Cc: linux-next at vger.kernel.org; linux-kernel at vger.kernel.org; Yang, Wenyou;
> Richard Genoud; Mark Brown; Ferre, Nicolas
> Subject: linux-next: manual merge of the arm-soc tree with the spi-mb tree
> 
> Hi all,
> 
> Today's linux-next merge of the arm-soc tree got a conflict in
> arch/arm/boot/dts/at91sam9x5.dtsi between commits d50f88a0c304 ("ARM:
> dts: add spi nodes for atmel SoC") and a68b728f7a21 ("ARM: dts: add pinctrl
> property for spi node for atmel SoC") from the spi-mb tree and commits
> e9a72ee81d58 ("ARM: at91: dt: at91sam9x5: add i2c pinctrl"),
> 463c9c7bf1f3 ("ARM: at91: dt: at91sam9x5: add i2c-gpio pinctrl") and
> b909c6c94462 ("ARM: at91/at91sam9x5: add RTC node") from the arm-soc
> tree.
> 
> I fixed it up (hopefully - see below) and can carry the fix as necessary (no action
> is required).
> 
> --
> Cheers,
> Stephen Rothwell                    sfr at canb.auug.org.au
> 
> diff --cc arch/arm/boot/dts/at91sam9x5.dtsi index 347b438,284bf24..0000000
> --- a/arch/arm/boot/dts/at91sam9x5.dtsi
> +++ b/arch/arm/boot/dts/at91sam9x5.dtsi
> @@@ -343,23 -343,53 +343,70 @@@
>   					};
>   				};
> 
>  +				spi0 {
>  +					pinctrl_spi0: spi0-0 {
>  +						atmel,pins =
>  +							<0 11 0x1 0x0	/* PA11 periph A SPI0_MISO
> pin */
>  +							 0 12 0x1 0x0	/* PA12 periph A SPI0_MOSI
> pin */
>  +							 0 13 0x1 0x0>;	/* PA13 periph A
> SPI0_SPCK pin */
>  +					};
>  +				};
>  +
>  +				spi1 {
>  +					pinctrl_spi1: spi1-0 {
>  +						atmel,pins =
>  +							<0 21 0x2 0x0	/* PA21 periph B SPI1_MISO
> pin */
>  +							 0 22 0x2 0x0	/* PA22 periph B SPI1_MOSI
> pin */
>  +							 0 23 0x2 0x0>;	/* PA23 periph B
> SPI1_SPCK pin */
>  +					};
>  +				};
> + 				i2c0 {
> + 					pinctrl_i2c0: i2c0-0 {
> + 						atmel,pins =
> + 							<0 30 0x1 0x0	/* PA30 periph A I2C0 data */
> + 							 0 31 0x1 0x0>;	/* PA31 periph A I2C0
> clock */
> + 					};
> + 				};
> +
> + 				i2c1 {
> + 					pinctrl_i2c1: i2c1-0 {
> + 						atmel,pins =
> + 							<2 0 0x3 0x0	/* PC0 periph C I2C1 data */
> + 							 2 1 0x3 0x0>;	/* PC1 periph C I2C1 clock */
> + 					};
> + 				};
> +
> + 				i2c2 {
> + 					pinctrl_i2c2: i2c2-0 {
> + 						atmel,pins =
> + 							<1 4 0x2 0x0	/* PB4 periph B I2C2 data */
> + 							 1 5 0x2 0x0>;	/* PB5 periph B I2C2 clock */
> + 					};
> + 				};
> +
> + 				i2c_gpio0 {
> + 					pinctrl_i2c_gpio0: i2c_gpio0-0 {
> + 						atmel,pins =
> + 							<0 30 0x0 0x2	/* PA30 gpio multidrive I2C0
> data */
> + 							 0 31 0x0 0x2>;	/* PA31 gpio multidrive
> I2C0 clock */
> + 					};
> + 				};
> +
> + 				i2c_gpio1 {
> + 					pinctrl_i2c_gpio1: i2c_gpio1-0 {
> + 						atmel,pins =
> + 							<2 0 0x0 0x2	/* PC0 gpio multidrive I2C1
> data */
> + 							 2 1 0x0 0x2>;	/* PC1 gpio multidrive I2C1
> clock */
> + 					};
> + 				};
> +
> + 				i2c_gpio2 {
> + 					pinctrl_i2c_gpio2: i2c_gpio2-0 {
> + 						atmel,pins =
> + 							<1 4 0x0 0x2	/* PB4 gpio multidrive I2C2
> data */
> + 							 1 5 0x0 0x2>;	/* PB5 gpio multidrive I2C2
> clock */
> + 					};
> + 				};
> 
>   				pioA: gpio at fffff400 {
>   					compatible = "atmel,at91sam9x5-gpio",
> "atmel,at91rm9200-gpio"; @@@ -548,27 -587,12 +604,33 @@@
>   				};
>   			};
> 
>  +			spi0: spi at f0000000 {
>  +				#address-cells = <1>;
>  +				#size-cells = <0>;
>  +				compatible = "atmel,at91rm9200-spi";
>  +				reg = <0xf0000000 0x100>;
>  +				interrupts = <13 4 3>;
>  +				pinctrl-names = "default";
>  +				pinctrl-0 = <&pinctrl_spi0>;
>  +				status = "disabled";
>  +			};
>  +
>  +			spi1: spi at f0004000 {
>  +				#address-cells = <1>;
>  +				#size-cells = <0>;
>  +				compatible = "atmel,at91rm9200-spi";
>  +				reg = <0xf0004000 0x100>;
>  +				interrupts = <14 4 3>;
>  +				pinctrl-names = "default";
>  +				pinctrl-0 = <&pinctrl_spi1>;
>  +				status = "disabled";
>  +			};
> + 			rtc at fffffeb0 {
> + 				compatible = "atmel,at91rm9200-rtc";
> + 				reg = <0xfffffeb0 0x40>;
> + 				interrupts = <1 4 7>;
> + 				status = "disabled";
> + 			};
>   		};
> 
>   		nand0: nand at 40000000 {

From linus.walleij at linaro.org  Fri Apr 26 03:54:39 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Fri, 26 Apr 2013 09:54:39 +0200
Subject: [PATCH] gpio/omap: ensure gpio context is initialised
In-Reply-To: <51709499.8030208@ti.com>
References: <1366230707-32681-1-git-send-email-jon-hunter@ti.com>
 <871ua734mv.fsf@linaro.org> <51707D7C.1050600@ti.com>
 <5170911C.6010507@ti.com> <51709499.8030208@ti.com>
Message-ID: <CACRpkdZ=xdOnVVxEdTALJN-xpsoKGJufirV2EJCbJtGTEmjdVA@mail.gmail.com>

On Fri, Apr 19, 2013 at 2:49 AM, Jon Hunter <jon-hunter at ti.com> wrote:

> From d02ef7b7dfcf8e13bf019aedfdecb38ca3c6749f Mon Sep 17 00:00:00 2001
> From: Jon Hunter <jon-hunter at ti.com>
> Date: Mon, 15 Apr 2013 13:06:54 -0500
> Subject: [PATCH] gpio/omap: ensure gpio context is initialised
>
> Commit a2797be (gpio/omap: force restore if context loss is not
> detectable) broke gpio support for OMAP when booting with device-tree
> because a restore of the gpio context being performed without ever
> initialising the gpio context. In other words, the context restored was
> bad.
>
> This problem could also occur in the non device-tree case, however, it
> is much less likely because when booting without device-tree we can
> detect context loss via a platform specific API and so context restore
> is performed less often.
>
> Nevertheless we should ensure that the gpio context is initialised
> on the first pm-runtime resume for gpio banks that could lose their
> state regardless of whether we are booting with device-tree or not.
>
> The context loss count was being initialised on the first pm-runtime
> suspend following a resume, by populating the get_count_loss_count()
> function pointer after the first pm-runtime resume. To make the code
> more readable and logical, initialise the context loss count on the
> first pm-runtime resume if the context is not yet valid.
>
> Reported-by: Tony Lindgren <tony at atomide.com>
> Signed-off-by: Jon Hunter <jon-hunter at ti.com>

Applied this version with Santosh's and Kevin's ACKs and
Tony's Tested-by, thanks!

Yours,
Linus Walleij


From rui.zhang at intel.com  Fri Apr 26 04:10:39 2013
From: rui.zhang at intel.com (Zhang Rui)
Date: Fri, 26 Apr 2013 16:10:39 +0800
Subject: [PATCH 15/21] thermal: cooling: avoid uninitialied used gcc
 warning
In-Reply-To: <1366910944-3033663-16-git-send-email-arnd@arndb.de>
References: <1366910944-3033663-1-git-send-email-arnd@arndb.de>
 <1366910944-3033663-16-git-send-email-arnd@arndb.de>
Message-ID: <1366963839.2189.1.camel@rzhang1-mobl4>

On Thu, 2013-04-25 at 19:28 +0200, Arnd Bergmann wrote:
> The newly rewritten get_property() function causes a bogus warning
> from gcc-3.8, which cannot figure out that "level" is always
> initialized at the point where it gets evaluated:
> 
> drivers/thermal/cpu_cooling.c: In function 'get_property':
> drivers/thermal/cpu_cooling.c:189:37: warning: 'level' may be used uninitialized in this function [-Wmaybe-uninitialized]
>    if (property == GET_FREQ && level == j) {
>                                      ^
> 
> Slightly rearranging the code makes this more obvious and
> avoids the warning.
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Cc: Zhang Rui <rui.zhang at intel.com>
> Cc: Amit Daniel kachhap <amit.daniel at samsung.com>

we already have a fix for this.
please refer to
https://patchwork.kernel.org/patch/2454891/

thanks for your patch, Arnd!

-rui
> ---
>  drivers/thermal/cpu_cooling.c | 17 +++++++++--------
>  1 file changed, 9 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
> index 768b508..34878e6 100644
> --- a/drivers/thermal/cpu_cooling.c
> +++ b/drivers/thermal/cpu_cooling.c
> @@ -165,10 +165,6 @@ static int get_property(unsigned int cpu, unsigned long input,
>  		return 0;
>  	}
>  
> -	if (property == GET_FREQ)
> -		level = descend ? input : (max_level - input -1);
> -
> -
>  	for (i = 0, j = 0; table[i].frequency != CPUFREQ_TABLE_END; i++) {
>  		/* ignore invalid entry */
>  		if (table[i].frequency == CPUFREQ_ENTRY_INVALID)
> @@ -186,10 +182,15 @@ static int get_property(unsigned int cpu, unsigned long input,
>  			*output = descend ? j : (max_level - j - 1);
>  			return 0;
>  		}
> -		if (property == GET_FREQ && level == j) {
> -			/* get frequency by level */
> -			*output = freq;
> -			return 0;
> +
> +		if (property == GET_FREQ) {
> +			level = descend ? input : (max_level - input -1);
> +
> +			if (level == j) {
> +				/* get frequency by level */
> +				*output = freq;
> +				return 0;
> +			}
>  		}
>  		j++;
>  	}




From linus.walleij at linaro.org  Fri Apr 26 04:13:59 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Fri, 26 Apr 2013 10:13:59 +0200
Subject: [PATCH 20/21] MFD: ab8500: export ab8500_gpadc_sw_hw_convert
 properly
In-Reply-To: <1366734653-488286-21-git-send-email-arnd@arndb.de>
References: <1366734653-488286-1-git-send-email-arnd@arndb.de>
 <1366734653-488286-21-git-send-email-arnd@arndb.de>
Message-ID: <CACRpkda6GpxUf8oPw74A08D0RJKZWir4hqXLjz-fe8Kq02vmDg@mail.gmail.com>

On Tue, Apr 23, 2013 at 6:30 PM, Arnd Bergmann <arnd at arndb.de> wrote:

> Apparently the ab8500_gpadc_sw_hw_convert function got renamed
> from ab8500_gpadc_convert to ab8500_gpadc_sw_hw_convert in
> commit 734823462 "mfd: ab8500-gpadc: Add gpadc hw conversion",
> but the export for this function did not get changed at the
> same time, causing this allyesconfig error:
>
> ERROR: "ab8500_gpadc_sw_hw_convert" [drivers/hwmon/ab8500.ko] undefined!
>
> This patch fixes the export.
>
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Cc: M'boumba Cedric Madianga <cedric.madianga at stericsson.com>
> Cc: Lee Jones <lee.jones at linaro.org>
> Cc: Mattias WALLIN <mattias.wallin at stericsson.com>
> Cc: Michel JAOUEN <michel.jaouen at stericsson.com>
> Cc: Samuel Ortiz <sameo at linux.intel.com>

Acked-by: Linus Walleij <linus.walleij at linaro.org>

Sam -> please pick this...

Yours,
Linus Walleij


From dirk.behme at de.bosch.com  Fri Apr 26 04:13:56 2013
From: dirk.behme at de.bosch.com (Dirk Behme)
Date: Fri, 26 Apr 2013 10:13:56 +0200
Subject: [PATCH 2/2] ARM: i.MX6: add i.MX6 specific L2 cache configuration
In-Reply-To: <1366964036-17275-1-git-send-email-dirk.behme@de.bosch.com>
References: <1366964036-17275-1-git-send-email-dirk.behme@de.bosch.com>
Message-ID: <1366964036-17275-2-git-send-email-dirk.behme@de.bosch.com>

To improve the performance and power consumption add an i.MX6
specific L2 cache initialization.

This configuration is taken from Freescale's kernel patch

"ENGR00153601 [MX6]Adjust L2 cache parameter" [1]

with two additional improvements:

a) The L2X0_POWER_CTRL has only the two bits we set. So no need
   to read the register before. Remove the register read done
   in Freescale's patch.

b) In the L2X0_PREFETCH_CTRL register, besides the double linefill (bit[30]),
   additionally enable the instruction and data prefetch (bit[29-28]).

Signed-off-by: Dirk Behme <dirk.behme at de.bosch.com>
CC: Shawn Guo <shawn.guo at linaro.org>

[1] http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/commit/arch/arm/mach-mx6/mm.c?h=imx_3.0.35_12.09.01&id=814656410b40c67a10b25300e51b0477b2bb96d1
---
 arch/arm/mach-imx/mach-imx6q.c | 36 +++++++++++++++++++++++++++++++++++-
 1 file changed, 35 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-imx/mach-imx6q.c b/arch/arm/mach-imx/mach-imx6q.c
index 9ffd103..cdaeab5 100644
--- a/arch/arm/mach-imx/mach-imx6q.c
+++ b/arch/arm/mach-imx/mach-imx6q.c
@@ -281,9 +281,43 @@ static void __init imx6q_map_io(void)
 	imx_scu_map_io();
 }
 
-static void __init imx6q_init_irq(void)
+#ifdef CONFIG_CACHE_L2X0
+static void __init imx6q_init_l2cache(void)
 {
+	void __iomem *l2x0_base;
+	struct device_node *np;
+	unsigned int val;
+
+	np = of_find_compatible_node(NULL, NULL, "arm,pl310-cache");
+	if (!np)
+		goto out;
+
+	l2x0_base = of_iomap(np, 0);
+	if (!l2x0_base) {
+		of_node_put(np);
+		goto out;
+	}
+
+	/* Configure the L2 PREFETCH and POWER registers */
+	val = readl_relaxed(l2x0_base + L2X0_PREFETCH_CTRL);
+	val |= 0x70800000;
+	writel_relaxed(val, l2x0_base + L2X0_PREFETCH_CTRL);
+	val = L2X0_DYNAMIC_CLK_GATING_EN | L2X0_STNDBY_MODE_EN;
+	writel_relaxed(val, l2x0_base + L2X0_POWER_CTRL);
+
+	iounmap(l2x0_base);
+	of_node_put(np);
+
+out:
 	l2x0_of_init(0, ~0UL);
+}
+#else
+static inline void imx6q_init_l2cache(void) {}
+#endif
+
+static void __init imx6q_init_irq(void)
+{
+	imx6q_init_l2cache();
 	imx_src_init();
 	imx_gpc_init();
 	irqchip_init();
-- 
1.8.2



From dirk.behme at de.bosch.com  Fri Apr 26 04:13:55 2013
From: dirk.behme at de.bosch.com (Dirk Behme)
Date: Fri, 26 Apr 2013 10:13:55 +0200
Subject: [PATCH 1/2] ARM: dts: i.MX6: configure L2 cache data and tag latency
Message-ID: <1366964036-17275-1-git-send-email-dirk.behme@de.bosch.com>

Configure the data and tag latency for the L2 cache. This improves the
system performance.

This configuration is taken from Freescale's kernel patch

"ENGR00153601 [MX6]Adjust L2 cache parameter" [1]

which does

writel(0x132, IO_ADDRESS(L2_BASE_ADDR + L2X0_TAG_LATENCY_CTRL));
writel(0x132, IO_ADDRESS(L2_BASE_ADDR + L2X0_DATA_LATENCY_CTRL));

In this patch we are doing the same via the device tree.

Signed-off-by: Dirk Behme <dirk.behme at de.bosch.com>
CC: Shawn Guo <shawn.guo at linaro.org>

[1] http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/commit/arch/arm/mach-mx6/mm.c?h=imx_3.0.35_12.09.01&id=814656410b40c67a10b25300e51b0477b2bb96d1
---
 arch/arm/boot/dts/imx6qdl.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 281a223..3e8381d 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -100,6 +100,8 @@
 			interrupts = <0 92 0x04>;
 			cache-unified;
 			cache-level = <2>;
+			arm,tag-latency = <4 2 3>;
+			arm,data-latency = <4 2 3>;
 		};
 
 		aips-bus at 02000000 { /* AIPS1 */
-- 
1.8.2



From fabio.baltieri at linaro.org  Fri Apr 26 04:14:52 2013
From: fabio.baltieri at linaro.org (Fabio Baltieri)
Date: Fri, 26 Apr 2013 10:14:52 +0200
Subject: [PATCH] clk: ux500: abx500-clk: rename ux500 audio codec aliases
Message-ID: <1366964092-7672-1-git-send-email-fabio.baltieri@linaro.org>

Change soc-audio related clk_register_clkdev() device names to reflect
the ones actually used in current snd-soc-mop500 and ab8500-codec
drivers.

Cc: Ulf Hansson <ulf.hansson at linaro.org>
Signed-off-by: Fabio Baltieri <fabio.baltieri at linaro.org>
---
 drivers/clk/ux500/abx500-clk.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/clk/ux500/abx500-clk.c b/drivers/clk/ux500/abx500-clk.c
index a0fca00..e7bd62c 100644
--- a/drivers/clk/ux500/abx500-clk.c
+++ b/drivers/clk/ux500/abx500-clk.c
@@ -45,7 +45,7 @@ static int ab8500_reg_clks(struct device *dev)
 				CLK_IS_ROOT);
 	clk_register_clkdev(clk, "sysclk", "ab8500-usb.0");
 	clk_register_clkdev(clk, "sysclk", "ab-iddet.0");
-	clk_register_clkdev(clk, "sysclk", "ab85xx-codec.0");
+	clk_register_clkdev(clk, "sysclk", "snd-soc-mop500.0");
 	clk_register_clkdev(clk, "sysclk", "shrm_bus");
 
 	/* ab8500_sysclk2 */
@@ -70,19 +70,19 @@ static int ab8500_reg_clks(struct device *dev)
 		AB8500_SYSULPCLKCTRL1, AB8500_SYSULPCLKCTRL1_ULPCLKREQ,
 		AB8500_SYSULPCLKCTRL1_ULPCLKREQ,
 		38400000, 9000, CLK_IS_ROOT);
-	clk_register_clkdev(clk, "ulpclk", "ab85xx-codec.0");
+	clk_register_clkdev(clk, "ulpclk", "snd-soc-mop500.0");
 
 	/* ab8500_intclk */
 	clk = clk_reg_sysctrl_set_parent(dev , "intclk", intclk_parents, 2,
 		intclk_reg_sel, intclk_reg_mask, intclk_reg_bits, 0);
-	clk_register_clkdev(clk, "intclk", "ab85xx-codec.0");
+	clk_register_clkdev(clk, "intclk", "snd-soc-mop500.0");
 	clk_register_clkdev(clk, NULL, "ab8500-pwm.1");
 
 	/* ab8500_audioclk */
 	clk = clk_reg_sysctrl_gate(dev , "audioclk", "intclk",
 		AB8500_SYSULPCLKCTRL1, AB8500_SYSULPCLKCTRL1_AUDIOCLKENA,
 		AB8500_SYSULPCLKCTRL1_AUDIOCLKENA, 0, 0);
-	clk_register_clkdev(clk, "audioclk", "ab85xx-codec.0");
+	clk_register_clkdev(clk, "audioclk", "ab8500-codec.0");
 
 	return 0;
 }
-- 
1.8.1.3



From David.Laight at ACULAB.COM  Fri Apr 26 04:21:59 2013
From: David.Laight at ACULAB.COM (David Laight)
Date: Fri, 26 Apr 2013 09:21:59 +0100
Subject: [PATCH 05/21] atm: he: use mdelay instead of large udelay
 constants
In-Reply-To: <1366910944-3033663-6-git-send-email-arnd@arndb.de>
References: <1366910944-3033663-1-git-send-email-arnd@arndb.de>
 <1366910944-3033663-6-git-send-email-arnd@arndb.de>
Message-ID: <AE90C24D6B3A694183C094C60CF0A2F6026B7203@saturn3.aculab.com>

> ARM cannot handle udelay for more than 2 miliseconds, so we
> should use mdelay instead for those.
...
> @@ -1055,7 +1055,7 @@ static int he_start(struct atm_dev *dev)
>  	he_writel(he_dev, 0x0, RESET_CNTL);
>  	he_writel(he_dev, 0xff, RESET_CNTL);
> 
> -	udelay(16*1000);	/* 16 ms */
> +	mdelay(16);	/* 16 ms */
>  	status = he_readl(he_dev, RESET_CNTL);

16ms seems a long time to spin.
I'd have thought a sleep would be more appropriate.
Since this looks like timing a hardware reset pulse
it can't matter if it is somewhat longer.

	David





From linus.walleij at linaro.org  Fri Apr 26 04:28:39 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Fri, 26 Apr 2013 10:28:39 +0200
Subject: [PATCH 6/9] crypto: ux500/cryp - Set DMA configuration though
 dma_slave_config()
In-Reply-To: <201304251611.39667.arnd@arndb.de>
References: <1366280825-31136-1-git-send-email-lee.jones@linaro.org>
 <CACRpkdbFgW6bGYt59WtN4r2izuN09AJw4J1cqir82uzFsuMmWQ@mail.gmail.com>
 <20130425134402.GN4623@gmail.com>
 <201304251611.39667.arnd@arndb.de>
Message-ID: <CACRpkdaBf++gy3sghC-t33uio2+eHp1MrQ2FM0XXBazZTtm3kA@mail.gmail.com>

On Thu, Apr 25, 2013 at 4:11 PM, Arnd Bergmann <arnd at arndb.de> wrote:

> The dma engine driver must know the address in its dma space, while the
> slave driver has it available in physical space. These two are often the
> same, but there is no generic way to convert between the two, especially
> if the dma engine resides behind an IOMMU.
>
> The best assumption we can make is that the dma engine driver knows
> how to convert between the two. Interestingly the documentation for
> dma_slave_config talks about "physical address", while the structure
> itself uses a dma_addr_t. Linus Walleij introduced the structure in
> c156d0a5b0 "DMAENGINE: generic slave channel control v3", so I assume
> he can shed some light on what he was thinking. I assume the documentation
> is right but the structure is not and should be converted to use
> phys_add_t or resource_size_t.

OK I could cook a patch for that, but I think I need some input from
Vinod and/or Russell on this.

It does make sense to me that if anything knows how to map a physical
address into the DMA address space it'll be the DMA engine.

However this rings a bell that there may be a possible relation to
DMA-API, since that API syncs memory buffers to the DMA
address space if there is some MMU inbetween the DMA and the
(ordinary, non-device) memory.

So if we think one step ahead, assuming the DMAC is actually behind
an MMU making it see the device in some other address than the
physical (bus) space, where would the address be resolved?

Yours,
Linus Walleij


From weiyj.lk at gmail.com  Fri Apr 26 04:31:44 2013
From: weiyj.lk at gmail.com (Wei Yongjun)
Date: Fri, 26 Apr 2013 16:31:44 +0800
Subject: [PATCH] ARM: OMAP1: DMA: fix error handling in omap1_system_dma_init()
Message-ID: <CAPgLHd-5cRFtN-rF8c5Jvg9cqE3jvxuOa6KaDgcoYHPM4DhbMQ@mail.gmail.com>

From: Wei Yongjun <yongjun_wei at trendmicro.com.cn>

Add the missing iounmap() before return from omap1_system_dma_init()
in the error handling case.
Also removed platform_device_del() on add resources error case which
cause dup device delete.

Signed-off-by: Wei Yongjun <yongjun_wei at trendmicro.com.cn>
---
no compile test.
---
 arch/arm/mach-omap1/dma.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-omap1/dma.c b/arch/arm/mach-omap1/dma.c
index 1a4e887..68ab858 100644
--- a/arch/arm/mach-omap1/dma.c
+++ b/arch/arm/mach-omap1/dma.c
@@ -301,7 +301,7 @@ static int __init omap1_system_dma_init(void)
 	if (ret) {
 		dev_err(&pdev->dev, "%s: Unable to add resources for %s%d\n",
 			__func__, pdev->name, pdev->id);
-		goto exit_device_put;
+		goto exit_iounmap;
 	}
 
 	p = kzalloc(sizeof(struct omap_system_dma_plat_info), GFP_KERNEL);
@@ -309,7 +309,7 @@ static int __init omap1_system_dma_init(void)
 		dev_err(&pdev->dev, "%s: Unable to allocate 'p' for %s\n",
 			__func__, pdev->name);
 		ret = -ENOMEM;
-		goto exit_device_del;
+		goto exit_iounmap;
 	}
 
 	d = kzalloc(sizeof(struct omap_dma_dev_attr), GFP_KERNEL);
@@ -402,8 +402,8 @@ exit_release_d:
 	kfree(d);
 exit_release_p:
 	kfree(p);
-exit_device_del:
-	platform_device_del(pdev);
+exit_iounmap:
+	iounmap(dma_base);
 exit_device_put:
 	platform_device_put(pdev);
 



From linus.walleij at linaro.org  Fri Apr 26 04:32:38 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Fri, 26 Apr 2013 10:32:38 +0200
Subject: [PATCH] cpuidle: add maintainer entry
In-Reply-To: <9935265.yXMiRQV8Yo@vostro.rjw.lan>
References: <1366810463-17495-1-git-send-email-daniel.lezcano@linaro.org>
 <87k3nr50n4.fsf@linaro.org>
 <CACRpkdaA8uG5jYyYTbuvzZNRr47EhWHFMLLz+jbiE3FPC1vjmA@mail.gmail.com>
 <9935265.yXMiRQV8Yo@vostro.rjw.lan>
Message-ID: <CACRpkdbQcxXzySH70NHMQfQXqMc72GUwvj1KQaxmnLSAbJ17rw@mail.gmail.com>

On Thu, Apr 25, 2013 at 8:27 PM, Rafael J. Wysocki <rjw at sisk.pl> wrote:
> On Thursday, April 25, 2013 02:09:11 PM Linus Walleij wrote:
>> On Wed, Apr 24, 2013 at 6:55 PM, Kevin Hilman <khilman at linaro.org> wrote:

>> > What do you think about having Daniel listed here as a co-maintainer?
>>
>> I second that. He will bring useful embedded knowledge to the
>> subsystem.
>
> I'd still like to have a say about the core, but if Daniel is willing to
> maintain ARM cpuidle drivers and all of the relevant ARM people agree with
> that, that'll be great.

OK Daniel can you post a v2 adding yourself as co-maintainer as well?
Add my Acked-by if you wish.

Yours,
Linus Walleij


From santosh.shilimkar at ti.com  Fri Apr 26 04:40:36 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Fri, 26 Apr 2013 14:10:36 +0530
Subject: Multiple issues with omap4 panda es in linux next
In-Reply-To: <87obd21zlw.fsf@linaro.org>
References: <20130419171318.GK10155@atomide.com> <517181B2.9070302@ti.com>
 <20130419174454.GM10155@atomide.com> <517184A2.9020908@ti.com>
 <20130419181825.GN10155@atomide.com> <87obd21zlw.fsf@linaro.org>
Message-ID: <517A3D84.3000605@ti.com>

On Thursday 25 April 2013 07:28 PM, Kevin Hilman wrote:
> Tony Lindgren <tony at atomide.com> writes:
> 
>> * Santosh Shilimkar <santosh.shilimkar at ti.com> [130419 10:56]:
>>> On Friday 19 April 2013 11:14 PM, Tony Lindgren wrote:
>>>> * Santosh Shilimkar <santosh.shilimkar at ti.com> [130419 10:43]:
>>>>> On Friday 19 April 2013 10:43 PM, Tony Lindgren wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> Here's a list of breakage I've noticed so far while trying to
>>>>>> use linux next on my pandaboard es. Probably similar issues exist
>>>>>> on other boards as well.
>>>>>>
>>>>>> Ideally we would not have any breakage by the merge window, so
>>>>>> let's try to get these fixed ASAP:
>>>>>>
>>>>>> 1. Serial console broken on panda es booting with DT
>>>>>>
>>>>>> The symptoms are dmesg output stopping after few lines
>>>>>> and only continuing after pressing a key. Does not seem to
>>>>>> happen on blaze with DT for some reason. And does not happen
>>>>>> on panda es with legacy booting.
>>>>>>
>>>>> This one is known and reported on list along with fix patches and
>>>>> later pull request [1].
>>>>>
>>>>> Unfortunately with all the testing and everything and patches have
>>>>> been on the list for quite some time, feedback on one of the patch
>>>>> received was after pull request and then there was no further
>>>>> clarification. That series address the same exact issue you have
>>>>> mentioned above.
>>>>
>>>> OK thanks. I think Paul picked some of those and the plan was
>>>> to update the branch? Which one(s) should go into v3.10 as fixes?
>>>>
>>> Main in that series was to handle driver sysc handling withing hwmod
>>> layer and that is where the series got stuck [2]. Without that support
>>> other patches won't fix the issue.
>>
>> OK it seems that that is still ongoing discussion. For v3.10 we should
>> probably just disable PM for omap4 for DT booting so people can use
>> it for DT related development.
> 
> Disabling PM (and even avoiding WFI using 'nohlt') will not fix this
> problem, since it's related to the idle-mode of the IP block itself.
> 
> What fixes the problem is the series from Santosh for the SYSC removal.
> 
> Santosh, it seems that series combined a fix for this problem with some
> cleanup of the hwmod code that Paul had some concerns with.  Is there
> any chance you can split up that series into a fix targetted at the
> DT-boot UART problem and a feature cleanup for hwmod?
> 
> Then we hopefully get this fix into v3.10-rc and work on the hwmod
> changes/cleanup for the following merge window.
> 
That was just one patch which was added so that UART async wakeup
works. Rajendra is cleaning up that patch and post an updated
series which hopefully make the console issue go away.

Regards,
Santosh



From linus.walleij at linaro.org  Fri Apr 26 04:49:12 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Fri, 26 Apr 2013 10:49:12 +0200
Subject: [PATCH] pinctrl: document the "GPIO mode" pitfall
In-Reply-To: <1761651.lXztZzrj1S@avalon>
References: <1363345636-2006-1-git-send-email-linus.walleij@stericsson.com>
 <2408684.1bsjMDDzMu@avalon>
 <CACRpkdag=YTeQH=VjW4fQ+G94REWeURhC=ErJxjmSUuP=pKYbA@mail.gmail.com>
 <1761651.lXztZzrj1S@avalon>
Message-ID: <CACRpkdaMdU4DHWULnSB_dvGk8pTRbirL1HVTGqJ2rwqXR798uQ@mail.gmail.com>

On Fri, Apr 26, 2013 at 1:15 AM, Laurent Pinchart
<laurent.pinchart at ideasonboard.com> wrote:
> On Thursday 25 April 2013 23:39:18 Linus Walleij wrote:
>> On Tue, Apr 23, 2013 at 3:33 PM, Laurent Pinchart wrote:

>> > Could you clarify the exact scope of the two configuration parameters ?
>>
>> PIN_CONFIG_OUTPUT is left a bit unspecified, but here the idea was a passive
>> drive, like just connecting the pin to VDD or GND without any driver stage
>> at all.
>
> Isn't that a driver stage ? :-)

OK something that is not a totempole type drive ...
push/pull surely implies a totempole type design.

> What is unclear to me is the interaction between OUTPUT and DRIVE_*.
> That's the part I would like to see clarified.

I sent some patch now, check it ... hm reported-by still doesn't add
you to CC :-/ better patch git-send-email...

> Does DRIVE_* imply that the pin
> is driven by the selected function, and OUTPUT imply that the pin is driven to
> a fixed level ?

That is unclear, but I suggest DRIVE* implies that everything on the pin
is driven according to that configuration. (Else it is getting ignored...)

OUTPUT would be used when you don't know the particulars or when
the driving cannot be controlled in a fine-grained manner like with the
DRIVE* configs.

Does this make sense?

> If so, how do you configure the drive type of a pin that will
> be used through the GPIO API ?

It is possible to use the pinctrl and GPIO APIs orthogonally.

For example the pinctrl can use hogs to reconfigure the pins
during sleep without intervention from the GPIO API.

So they will be fingering on the same pins registers.
Maybe even the same register (if access can be protected
properly) from different APIs.

> What about cases where I want to drive the pin
> to a fixed level in a non low-power output mode (for instance because I need
> more current that what the low-power output mode provides) ?

Just use pinconfig for that?

Is the usecase something like a power-supplying GPIO pin
and then sometimes you want to provide more power from it?

Then use pinconfig to shunt in the driver stages, and GPIO API
to enable/disable it.

Yours,
Linus Walleij


From vinod.koul at intel.com  Fri Apr 26 04:16:46 2013
From: vinod.koul at intel.com (Vinod Koul)
Date: Fri, 26 Apr 2013 13:46:46 +0530
Subject: [PATCH 6/9] crypto: ux500/cryp - Set DMA configuration though
 dma_slave_config()
In-Reply-To: <CACRpkdaBf++gy3sghC-t33uio2+eHp1MrQ2FM0XXBazZTtm3kA@mail.gmail.com>
References: <1366280825-31136-1-git-send-email-lee.jones@linaro.org>
 <CACRpkdbFgW6bGYt59WtN4r2izuN09AJw4J1cqir82uzFsuMmWQ@mail.gmail.com>
 <20130425134402.GN4623@gmail.com>
 <201304251611.39667.arnd@arndb.de>
 <CACRpkdaBf++gy3sghC-t33uio2+eHp1MrQ2FM0XXBazZTtm3kA@mail.gmail.com>
Message-ID: <20130426081646.GD24632@intel.com>

On Fri, Apr 26, 2013 at 10:28:39AM +0200, Linus Walleij wrote:
> On Thu, Apr 25, 2013 at 4:11 PM, Arnd Bergmann <arnd at arndb.de> wrote:
> 
> > The dma engine driver must know the address in its dma space, while the
> > slave driver has it available in physical space. These two are often the
> > same, but there is no generic way to convert between the two, especially
> > if the dma engine resides behind an IOMMU.
> >
> > The best assumption we can make is that the dma engine driver knows
> > how to convert between the two. Interestingly the documentation for
> > dma_slave_config talks about "physical address", while the structure
> > itself uses a dma_addr_t. Linus Walleij introduced the structure in
> > c156d0a5b0 "DMAENGINE: generic slave channel control v3", so I assume
> > he can shed some light on what he was thinking. I assume the documentation
> > is right but the structure is not and should be converted to use
> > phys_add_t or resource_size_t.
> 
> OK I could cook a patch for that, but I think I need some input from
> Vinod and/or Russell on this.
the dma_slave_config is physical address that should be passed directly to the
controller. Obviosuly it should phys_addr_t :)

The mapping & unmapping of dma buffer (memcpy and memory buffer in this txn) is
required to be performed by the client driver. The dmanegine or dmaengine driver
will not do that for you...

This is true for slave usage and not for async case.
> 
> It does make sense to me that if anything knows how to map a physical
> address into the DMA address space it'll be the DMA engine.
> 
> However this rings a bell that there may be a possible relation to
> DMA-API, since that API syncs memory buffers to the DMA
> address space if there is some MMU inbetween the DMA and the
> (ordinary, non-device) memory.
> 
> So if we think one step ahead, assuming the DMAC is actually behind
> an MMU making it see the device in some other address than the
> physical (bus) space, where would the address be resolved?
> 
> Yours,
> Linus Walleij


From Ian.Campbell at citrix.com  Fri Apr 26 04:51:44 2013
From: Ian.Campbell at citrix.com (Ian Campbell)
Date: Fri, 26 Apr 2013 09:51:44 +0100
Subject: [PATCH v4 2/7] xen/arm: SMP support
In-Reply-To: <alpine.DEB.2.02.1304251945290.4180@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1304242012590.4180@kaball.uk.xensource.com>
 <1366831695-13214-2-git-send-email-stefano.stabellini@eu.citrix.com>
 <1366897221.20256.544.camel@zakaz.uk.xensource.com>
 <alpine.DEB.2.02.1304251503100.4180@kaball.uk.xensource.com>
 <1366909184.3142.0.camel@zakaz.uk.xensource.com>
 <alpine.DEB.2.02.1304251945290.4180@kaball.uk.xensource.com>
Message-ID: <1366966304.3142.33.camel@zakaz.uk.xensource.com>

On Thu, 2013-04-25 at 19:45 +0100, Stefano Stabellini wrote:
> On Thu, 25 Apr 2013, Ian Campbell wrote:
> > > > > @@ -216,6 +245,8 @@ static int __init xen_guest_init(void)
> > > > >  	 * is required to use VCPUOP_register_vcpu_info to place vcpu info
> > > > >  	 * for secondary CPUs as they are brought up. */
> > > > >  	per_cpu(xen_vcpu, 0) = &HYPERVISOR_shared_info->vcpu_info[0];
> > > > > +	for_each_online_cpu(i)
> > > > > +		xen_secondary_init(i);
> > > > >  
> > > > >  	gnttab_init();
> > > > >  	if (!xen_initial_domain())
> > > > [...]
> > > > > @@ -244,7 +280,7 @@ static int __init xen_init_events(void)
> > > > >  		return -EINVAL;
> > > > >  	}
> > > > >  
> > > > > -	enable_percpu_irq(xen_events_irq, 0);
> > > > > +	on_each_cpu(xen_percpu_enable_events, NULL, 0);
> > > > 
> > > > It feels like there ought to be some sort of per-cpu bringup callback
> > > > which takes care of these dynamically. Maybe that doesn't matter until
> > > > we get vcpu hotplug going?
> > > 
> > > I suspect there isn't one, considering that on_each_cpu is also used by 
> > > kvm_vgic_hyp_init, kvm_timer_hyp_init and others.
> > 
> > Could we use cpu_notifiers for this?
> 
> cpu_notifiers are for cpu hotplug, not for secondary cpu bringup

Are you sure they don't also trigger during bringup, because the
distinction is a little bit academic...

Ian.



From linus.walleij at linaro.org  Fri Apr 26 04:52:06 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Fri, 26 Apr 2013 10:52:06 +0200
Subject: Adding a void * to pinctrl_pin_desc
In-Reply-To: <051069C10411E24D9749790C498526FA1BCF4FC6@SJEXCHMB12.corp.ad.broadcom.com>
References: <051069C10411E24D9749790C498526FA1BCF4FC6@SJEXCHMB12.corp.ad.broadcom.com>
Message-ID: <CACRpkdYxJOWYMfwmrEGhqgjushVjWyc=FyKMaZNLnn=0jrTs9A@mail.gmail.com>

On Fri, Apr 26, 2013 at 2:42 AM, Sherman Yin <syin at broadcom.com> wrote:

>  What do you think about expanding the struct to something like this:
>
> struct pinctrl_pin_desc {
>         unsigned number;
>         const char *name;
>         void * pin_data;
> };
>
> so that drivers can optionally use pin_data to hold other pin-specific information?

No don't do this.

Instead:

struct foo_pin_desc {
      struct pinctrl_pin_desc desc;
      ....
      /* Insert my pindata here */
};

Then use container_of() to dereference a struct foo_pin_desc pointer from the
pointer at &foodesc->desc;

Yours,
Linus Walleij


From hechtb at gmail.com  Fri Apr 26 04:52:08 2013
From: hechtb at gmail.com (Bastian Hecht)
Date: Fri, 26 Apr 2013 10:52:08 +0200
Subject: [PATCH 03/21] ARM: shmobile: don't call irqchip_init
 unconditionally
In-Reply-To: <20130426004835.GA20070@verge.net.au>
References: <1366910944-3033663-1-git-send-email-arnd@arndb.de>
 <1366910944-3033663-4-git-send-email-arnd@arndb.de>
 <20130426004835.GA20070@verge.net.au>
Message-ID: <CABYn4sxjpp3yPkjDM9XhX6fyT-g_OoCjcnD1u=5oyb+Y6y=Nmw@mail.gmail.com>

Hello Simon and Arnd,

2013/4/26 Simon Horman <horms at verge.net.au>:
> On Thu, Apr 25, 2013 at 07:28:46PM +0200, Arnd Bergmann wrote:
>> The irqchip_init function is only available when building
>> with CONFIG_OF enabled, which causes this build failure for
>> bonito_defconfig:
>>
>> arch/arm/mach-shmobile/built-in.o: In function `r8a7740_init_irq_of':
>> :(.init.text+0x580): undefined reference to `irqchip_init'
>>
>> This makes both the OF and the ATAGS portion of the driver
>> conditional, which avoids the build error and also results
>> in smaller object code if not both are enabled, without the
>> need for an #ifdef.
>>
>> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
>> Cc: Bastian Hecht <hechtb+renesas at gmail.com>
>> Cc: Simon Horman <horms+renesas at verge.net.au>
>> Cc: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
>> ---
>>  arch/arm/mach-shmobile/intc-r8a7740.c | 13 +++++++++++--
>>  1 file changed, 11 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/mach-shmobile/intc-r8a7740.c b/arch/arm/mach-shmobile/intc-r8a7740.c
>> index 8871f77..5dc57f1 100644
>> --- a/arch/arm/mach-shmobile/intc-r8a7740.c
>> +++ b/arch/arm/mach-shmobile/intc-r8a7740.c
>> @@ -53,14 +53,23 @@ static void __init r8a7740_init_irq_common(void)
>>
>>  void __init r8a7740_init_irq_of(void)
>>  {
>> +     if (!IS_ENABLED(CONFIG_OF))
>> +             return;
>> +
>
> In other parts of the shmobile I believe that such code is
> guarded by #ifdef CONFIG_OF and I believe not guarding this code in
> some way was an oversight.

Yes, sorry, I haven't thought about the dependency of irqchip_init and
CONFIG_OF.

> The above change seems fine to me.
>
>>       irqchip_init();
>>       r8a7740_init_irq_common();
>>  }
>>
>>  void __init r8a7740_init_irq(void)
>>  {
>> -     void __iomem *gic_dist_base = ioremap_nocache(0xc2800000, 0x1000);
>> -     void __iomem *gic_cpu_base = ioremap_nocache(0xc2000000, 0x1000);
>> +     void __iomem *gic_dist_base;
>> +     void __iomem *gic_cpu_base;
>> +
>> +     if (!IS_ENABLED(CONFIG_ATAGS))
>> +             return;
>> +
>> +     gic_dist_base = ioremap_nocache(0xc2800000, 0x1000);
>> +     gic_cpu_base = ioremap_nocache(0xc2000000, 0x1000);
>>
>>       /* initialize the Generic Interrupt Controller PL390 r0p0 */
>>       gic_init(0, 29, gic_dist_base, gic_cpu_base);
>
> This one seems broken as the armadillo800eva board currently uses
> it to initialise GIC even if CONFIG_ATAGS is not defined.
>
> I did test the above change on the armadillo800eva board
> with the above change and CONFIG_ATAGS disabled, the result was
> a boot failure. With the change reverted booting seems fine.

CONFIG_ATAGS and CONFIG_ARM_APPENDED_DTB are two ways to pass the
device tree information, right?
So we run into trouble when we use the later but disable the first.
Is there a reason why you wanted to avoid using two times just "if
(!IS_ENABLED(CONFIG_OF))", Arnd?

Thanks,

 Bastian


From will.deacon at arm.com  Fri Apr 26 04:53:34 2013
From: will.deacon at arm.com (Will Deacon)
Date: Fri, 26 Apr 2013 09:53:34 +0100
Subject: [PATCH 01/21] ARM: topology: export cpu_topology
In-Reply-To: <1366910944-3033663-2-git-send-email-arnd@arndb.de>
References: <1366910944-3033663-1-git-send-email-arnd@arndb.de>
 <1366910944-3033663-2-git-send-email-arnd@arndb.de>
Message-ID: <20130426085333.GA30284@mudshark.cambridge.arm.com>

On Thu, Apr 25, 2013 at 06:28:44PM +0100, Arnd Bergmann wrote:
> The cpu_topology symbol is required by any driver using the topology
> interfaces, which leads to a couple of build errors:
> 
> ERROR: "cpu_topology" [drivers/net/ethernet/sfc/sfc.ko] undefined!
> ERROR: "cpu_topology" [drivers/cpufreq/arm_big_little.ko] undefined!

Are these first two in mainline?

> ERROR: "cpu_topology" [drivers/block/mtip32xx/mtip32xx.ko] undefined!
> 
> The obvious solution is to export this symbol.
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Cc: Russell King <rmk+kernel at arm.linux.org.uk>
> Cc: Will Deacon <will.deacon at arm.com>
> Cc: Nicolas Pitre <nico at linaro.org>
> Cc: Vincent Guittot <vincent.guittot at linaro.org>
> ---
>  arch/arm/kernel/topology.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/kernel/topology.c b/arch/arm/kernel/topology.c
> index f10316b..7ac5714 100644
> --- a/arch/arm/kernel/topology.c
> +++ b/arch/arm/kernel/topology.c
> @@ -200,6 +200,7 @@ static inline void update_cpu_power(unsigned int cpuid, unsigned int mpidr) {}
>   * cpu topology table
>   */
>  struct cputopo_arm cpu_topology[NR_CPUS];
> +EXPORT_SYMBOL_GPL(cpu_topology);


Make sense:

  Acked-by: Will Deacon <will.deacon at arm.com>

Probably best to put it in the patch system.

Will


From linus.walleij at linaro.org  Fri Apr 26 05:07:33 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Fri, 26 Apr 2013 11:07:33 +0200
Subject: [PATCH 6/9] crypto: ux500/cryp - Set DMA configuration though
 dma_slave_config()
In-Reply-To: <20130426081646.GD24632@intel.com>
References: <1366280825-31136-1-git-send-email-lee.jones@linaro.org>
 <CACRpkdbFgW6bGYt59WtN4r2izuN09AJw4J1cqir82uzFsuMmWQ@mail.gmail.com>
 <20130425134402.GN4623@gmail.com>
 <201304251611.39667.arnd@arndb.de>
 <CACRpkdaBf++gy3sghC-t33uio2+eHp1MrQ2FM0XXBazZTtm3kA@mail.gmail.com>
 <20130426081646.GD24632@intel.com>
Message-ID: <CACRpkdYR=eb_oU6+iq0vbkbd_H0O+cccdXDSCR2oev2NEdwMZg@mail.gmail.com>

On Fri, Apr 26, 2013 at 10:16 AM, Vinod Koul <vinod.koul at intel.com> wrote:

>> OK I could cook a patch for that, but I think I need some input from
>> Vinod and/or Russell on this.

> the dma_slave_config is physical address that should be passed directly to the
> controller. Obviosuly it should phys_addr_t :)

OK! Sent a patch for this, check it out.

Yours,
Linus Walleij


From sameo at linux.intel.com  Fri Apr 26 05:23:11 2013
From: sameo at linux.intel.com (Samuel Ortiz)
Date: Fri, 26 Apr 2013 11:23:11 +0200
Subject: [PATCH 20/21] MFD: ab8500: export ab8500_gpadc_sw_hw_convert
 properly
In-Reply-To: <1366734653-488286-21-git-send-email-arnd@arndb.de>
References: <1366734653-488286-1-git-send-email-arnd@arndb.de>
 <1366734653-488286-21-git-send-email-arnd@arndb.de>
Message-ID: <20130426092311.GA5022@zurbaran>

Hi Arnd,

On Tue, Apr 23, 2013 at 06:30:52PM +0200, Arnd Bergmann wrote:
> Apparently the ab8500_gpadc_sw_hw_convert function got renamed
> from ab8500_gpadc_convert to ab8500_gpadc_sw_hw_convert in
> commit 734823462 "mfd: ab8500-gpadc: Add gpadc hw conversion",
> but the export for this function did not get changed at the
> same time, causing this allyesconfig error:
> 
> ERROR: "ab8500_gpadc_sw_hw_convert" [drivers/hwmon/ab8500.ko] undefined!
> 
> This patch fixes the export.
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Cc: M'boumba Cedric Madianga <cedric.madianga at stericsson.com>
> Cc: Lee Jones <lee.jones at linaro.org>
> Cc: Mattias WALLIN <mattias.wallin at stericsson.com>
> Cc: Michel JAOUEN <michel.jaouen at stericsson.com>
> Cc: Samuel Ortiz <sameo at linux.intel.com>
> ---
>  drivers/mfd/ab8500-gpadc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
Applied to mfd-next, thanks.

Cheers,
Samuel.

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


From jg1.han at samsung.com  Fri Apr 26 05:33:06 2013
From: jg1.han at samsung.com (=?ks_c_5601-1987?B?x9HB+LG4?=)
Date: Fri, 26 Apr 2013 18:33:06 +0900
Subject: [PATCH v8 2/3] of/pci: Provide support for parsing PCI DT ranges
 property
In-Reply-To: <1366627295-16964-3-git-send-email-Andrew.Murray@arm.com>
References: <1366627295-16964-1-git-send-email-Andrew.Murray@arm.com>
 <1366627295-16964-3-git-send-email-Andrew.Murray@arm.com>
Message-ID: <000501ce4261$0ef68160$2ce38420$@samsung.com>

On Monday, April 22, 2013 7:42 PM, Andrew Murray wrote:
> 
> This patch factors out common implementation patterns to reduce overall kernel
> code and provide a means for host bridge drivers to directly obtain struct
> resources from the DT's ranges property without relying on architecture specific
> DT handling. This will make it easier to write archiecture independent host bridge
> drivers and mitigate against further duplication of DT parsing code.
> 
> This patch can be used in the following way:
> 
> 	struct of_pci_range_parser parser;
> 	struct of_pci_range range;
> 
> 	if (of_pci_range_parser_init(&parser, np))
> 		; //no ranges property
> 
> 	for_each_of_pci_range(&parser, &range) {
> 
> 		/*
> 			directly access properties of the address range, e.g.:
> 			range.pci_space, range.pci_addr, range.cpu_addr,
> 			range.size, range.flags
> 
> 			alternatively obtain a struct resource, e.g.:
> 			struct resource res;
> 			of_pci_range_to_resource(&range, np, &res);
> 		*/
> 	}
> 
> Additionally the implementation takes care of adjacent ranges and merges them
> into a single range (as was the case with powerpc and microblaze).
> 
> Signed-off-by: Andrew Murray <Andrew.Murray at arm.com>
> Signed-off-by: Liviu Dudau <Liviu.Dudau at arm.com>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> Reviewed-by: Rob Herring <rob.herring at calxeda.com>
> Tested-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> Tested-by: Linus Walleij <linus.walleij at linaro.org>
> Acked-by: Grant Likely <grant.likely at secretlab.ca>


Tested-by: Jingoo Han <jg1.han at samsung.com>

Hi Andrew,

I tested this patch with Exynos5440.
It works properly.
Thank you.

Best regards,
Jingoo Han

> ---
>  drivers/of/address.c       |   67 ++++++++++++++++++++++++++
>  drivers/of/of_pci.c        |  113 +++++++++++++++++---------------------------
>  include/linux/of_address.h |   48 +++++++++++++++++++
>  3 files changed, 158 insertions(+), 70 deletions(-)
> 
> diff --git a/drivers/of/address.c b/drivers/of/address.c
> index 04da786..fdd0636 100644
> --- a/drivers/of/address.c
> +++ b/drivers/of/address.c
> @@ -227,6 +227,73 @@ int of_pci_address_to_resource(struct device_node *dev, int bar,
>  	return __of_address_to_resource(dev, addrp, size, flags, NULL, r);
>  }
>  EXPORT_SYMBOL_GPL(of_pci_address_to_resource);
> +
> +int of_pci_range_parser_init(struct of_pci_range_parser *parser,
> +				struct device_node *node)
> +{
> +	const int na = 3, ns = 2;
> +	int rlen;
> +
> +	parser->node = node;
> +	parser->pna = of_n_addr_cells(node);
> +	parser->np = parser->pna + na + ns;
> +
> +	parser->range = of_get_property(node, "ranges", &rlen);
> +	if (parser->range == NULL)
> +		return -ENOENT;
> +
> +	parser->end = parser->range + rlen / sizeof(__be32);
> +
> +	return 0;
> +}
> +EXPORT_SYMBOL_GPL(of_pci_range_parser_init);
> +
> +struct of_pci_range *of_pci_range_parser_one(struct of_pci_range_parser *parser,
> +						struct of_pci_range *range)
> +{
> +	const int na = 3, ns = 2;
> +
> +	if (!range)
> +		return NULL;
> +
> +	if (!parser->range || parser->range + parser->np > parser->end)
> +		return NULL;
> +
> +	range->pci_space = parser->range[0];
> +	range->flags = of_bus_pci_get_flags(parser->range);
> +	range->pci_addr = of_read_number(parser->range + 1, ns);
> +	range->cpu_addr = of_translate_address(parser->node,
> +				parser->range + na);
> +	range->size = of_read_number(parser->range + parser->pna + na, ns);
> +
> +	parser->range += parser->np;
> +
> +	/* Now consume following elements while they are contiguous */
> +	while (parser->range + parser->np <= parser->end) {
> +		u32 flags, pci_space;
> +		u64 pci_addr, cpu_addr, size;
> +
> +		pci_space = be32_to_cpup(parser->range);
> +		flags = of_bus_pci_get_flags(parser->range);
> +		pci_addr = of_read_number(parser->range + 1, ns);
> +		cpu_addr = of_translate_address(parser->node,
> +				parser->range + na);
> +		size = of_read_number(parser->range + parser->pna + na, ns);
> +
> +		if (flags != range->flags)
> +			break;
> +		if (pci_addr != range->pci_addr + range->size ||
> +		    cpu_addr != range->cpu_addr + range->size)
> +			break;
> +
> +		range->size += size;
> +		parser->range += parser->np;
> +	}
> +
> +	return range;
> +}
> +EXPORT_SYMBOL_GPL(of_pci_range_parser_one);
> +
>  #endif /* CONFIG_PCI */
> 
>  /*
> diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
> index 1626172..3c49ab2 100644
> --- a/drivers/of/of_pci.c
> +++ b/drivers/of/of_pci.c
> @@ -2,6 +2,7 @@
>  #include <linux/export.h>
>  #include <linux/of.h>
>  #include <linux/of_pci.h>
> +#include <linux/of_address.h>
>  #include <asm/prom.h>
> 
>  #if defined(CONFIG_PPC32) || defined(CONFIG_PPC64) || defined(CONFIG_MICROBLAZE)
> @@ -82,67 +83,42 @@ EXPORT_SYMBOL_GPL(of_pci_find_child_device);
>  void pci_process_bridge_OF_ranges(struct pci_controller *hose,
>  				  struct device_node *dev, int primary)
>  {
> -	const u32 *ranges;
> -	int rlen;
> -	int pna = of_n_addr_cells(dev);
> -	int np = pna + 5;
>  	int memno = 0, isa_hole = -1;
> -	u32 pci_space;
> -	unsigned long long pci_addr, cpu_addr, pci_next, cpu_next, size;
>  	unsigned long long isa_mb = 0;
>  	struct resource *res;
> +	struct of_pci_range range;
> +	struct of_pci_range_parser parser;
> 
>  	pr_info("PCI host bridge %s %s ranges:\n",
>  	       dev->full_name, primary ? "(primary)" : "");
> 
> -	/* Get ranges property */
> -	ranges = of_get_property(dev, "ranges", &rlen);
> -	if (ranges == NULL)
> +	/* Check for ranges property */
> +	if (of_pci_range_parser_init(&parser, dev))
>  		return;
> 
> -	/* Parse it */
>  	pr_debug("Parsing ranges property...\n");
> -	while ((rlen -= np * 4) >= 0) {
> +	for_each_of_pci_range(&parser, &range) {
>  		/* Read next ranges element */
> -		pci_space = ranges[0];
> -		pci_addr = of_read_number(ranges + 1, 2);
> -		cpu_addr = of_translate_address(dev, ranges + 3);
> -		size = of_read_number(ranges + pna + 3, 2);
> -
> -		pr_debug("pci_space: 0x%08x pci_addr:0x%016llx ",
> -				pci_space, pci_addr);
> -		pr_debug("cpu_addr:0x%016llx size:0x%016llx\n",
> -					cpu_addr, size);
> -
> -		ranges += np;
> +		pr_debug("pci_space: 0x%08x pci_addr: 0x%016llx ",
> +				range.pci_space, range.pci_addr);
> +		pr_debug("cpu_addr: 0x%016llx size: 0x%016llx\n",
> +				range.cpu_addr, range.size);
> 
>  		/* If we failed translation or got a zero-sized region
>  		 * (some FW try to feed us with non sensical zero sized regions
>  		 * such as power3 which look like some kind of attempt
>  		 * at exposing the VGA memory hole)
>  		 */
> -		if (cpu_addr == OF_BAD_ADDR || size == 0)
> +		if (range.cpu_addr == OF_BAD_ADDR || range.size == 0)
>  			continue;
> 
> -		/* Now consume following elements while they are contiguous */
> -		for (; rlen >= np * sizeof(u32);
> -		     ranges += np, rlen -= np * 4) {
> -			if (ranges[0] != pci_space)
> -				break;
> -			pci_next = of_read_number(ranges + 1, 2);
> -			cpu_next = of_translate_address(dev, ranges + 3);
> -			if (pci_next != pci_addr + size ||
> -			    cpu_next != cpu_addr + size)
> -				break;
> -			size += of_read_number(ranges + pna + 3, 2);
> -		}
> -
>  		/* Act based on address space type */
>  		res = NULL;
> -		switch ((pci_space >> 24) & 0x3) {
> -		case 1:		/* PCI IO space */
> +		switch (range.flags & IORESOURCE_TYPE_BITS) {
> +		case IORESOURCE_IO:
>  			pr_info("  IO 0x%016llx..0x%016llx -> 0x%016llx\n",
> -			       cpu_addr, cpu_addr + size - 1, pci_addr);
> +				range.cpu_addr, range.cpu_addr + range.size - 1,
> +				range.pci_addr);
> 
>  			/* We support only one IO range */
>  			if (hose->pci_io_size) {
> @@ -151,11 +127,12 @@ void pci_process_bridge_OF_ranges(struct pci_controller *hose,
>  			}
>  #if (!IS_ENABLED(CONFIG_64BIT))
>  			/* On 32 bits, limit I/O space to 16MB */
> -			if (size > 0x01000000)
> -				size = 0x01000000;
> +			if (range.size > 0x01000000)
> +				range.size = 0x01000000;
> 
>  			/* 32 bits needs to map IOs here */
> -			hose->io_base_virt = ioremap(cpu_addr, size);
> +			hose->io_base_virt = ioremap(range.cpu_addr,
> +						range.size);
> 
>  			/* Expect trouble if pci_addr is not 0 */
>  			if (primary)
> @@ -165,19 +142,21 @@ void pci_process_bridge_OF_ranges(struct pci_controller *hose,
>  			/* pci_io_size and io_base_phys always represent IO
>  			 * space starting at 0 so we factor in pci_addr
>  			 */
> -			hose->pci_io_size = pci_addr + size;
> -			hose->io_base_phys = cpu_addr - pci_addr;
> +			hose->pci_io_size = range.pci_addr + range.size;
> +			hose->io_base_phys = range.cpu_addr - range.pci_addr;
> 
>  			/* Build resource */
>  			res = &hose->io_resource;
> -			res->flags = IORESOURCE_IO;
> -			res->start = pci_addr;
> +			range.cpu_addr = range.pci_addr;
> +
>  			break;
> -		case 2:		/* PCI Memory space */
> -		case 3:		/* PCI 64 bits Memory space */
> +
> +		case IORESOURCE_MEM:
>  			pr_info(" MEM 0x%016llx..0x%016llx -> 0x%016llx %s\n",
> -			       cpu_addr, cpu_addr + size - 1, pci_addr,
> -			       (pci_space & 0x40000000) ? "Prefetch" : "");
> +				range.cpu_addr, range.cpu_addr + range.size - 1,
> +				range.pci_addr,
> +				(range.pci_space & 0x40000000) ?
> +				"Prefetch" : "");
> 
>  			/* We support only 3 memory ranges */
>  			if (memno >= 3) {
> @@ -185,13 +164,13 @@ void pci_process_bridge_OF_ranges(struct pci_controller *hose,
>  				continue;
>  			}
>  			/* Handles ISA memory hole space here */
> -			if (pci_addr == 0) {
> -				isa_mb = cpu_addr;
> +			if (range.pci_addr == 0) {
> +				isa_mb = range.cpu_addr;
>  				isa_hole = memno;
>  				if (primary || isa_mem_base == 0)
> -					isa_mem_base = cpu_addr;
> -				hose->isa_mem_phys = cpu_addr;
> -				hose->isa_mem_size = size;
> +					isa_mem_base = range.cpu_addr;
> +				hose->isa_mem_phys = range.cpu_addr;
> +				hose->isa_mem_size = range.size;
>  			}
> 
>  			/* We get the PCI/Mem offset from the first range or
> @@ -199,30 +178,24 @@ void pci_process_bridge_OF_ranges(struct pci_controller *hose,
>  			 * hole. If they don't match, bugger.
>  			 */
>  			if (memno == 0 ||
> -			    (isa_hole >= 0 && pci_addr != 0 &&
> +			(isa_hole >= 0 && range.pci_addr != 0 &&
>  			     hose->pci_mem_offset == isa_mb))
> -				hose->pci_mem_offset = cpu_addr - pci_addr;
> -			else if (pci_addr != 0 &&
> -				 hose->pci_mem_offset != cpu_addr - pci_addr) {
> +				hose->pci_mem_offset = range.cpu_addr -
> +							range.pci_addr;
> +			else if (range.pci_addr != 0 &&
> +				hose->pci_mem_offset != range.cpu_addr -
> +							range.pci_addr) {
>  				pr_info(" \\--> Skipped (offset mismatch) !\n");
>  				continue;
>  			}
> 
>  			/* Build resource */
>  			res = &hose->mem_resources[memno++];
> -			res->flags = IORESOURCE_MEM;
> -			if (pci_space & 0x40000000)
> -				res->flags |= IORESOURCE_PREFETCH;
> -			res->start = cpu_addr;
> +
>  			break;
>  		}
> -		if (res != NULL) {
> -			res->name = dev->full_name;
> -			res->end = res->start + size - 1;
> -			res->parent = NULL;
> -			res->sibling = NULL;
> -			res->child = NULL;
> -		}
> +		if (res != NULL)
> +			of_pci_range_to_resource(&range, dev, res);
>  	}
> 
>  	/* If there's an ISA hole and the pci_mem_offset is -not- matching
> diff --git a/include/linux/of_address.h b/include/linux/of_address.h
> index 0506eb5..4c2e6f2 100644
> --- a/include/linux/of_address.h
> +++ b/include/linux/of_address.h
> @@ -4,6 +4,36 @@
>  #include <linux/errno.h>
>  #include <linux/of.h>
> 
> +struct of_pci_range_parser {
> +	struct device_node *node;
> +	const __be32 *range;
> +	const __be32 *end;
> +	int np;
> +	int pna;
> +};
> +
> +struct of_pci_range {
> +	u32 pci_space;
> +	u64 pci_addr;
> +	u64 cpu_addr;
> +	u64 size;
> +	u32 flags;
> +};
> +
> +#define for_each_of_pci_range(parser, range) \
> +	for (; of_pci_range_parser_one(parser, range);)
> +
> +static inline void of_pci_range_to_resource(struct of_pci_range *range,
> +					    struct device_node *np,
> +					    struct resource *res)
> +{
> +	res->flags = range->flags;
> +	res->start = range->cpu_addr;
> +	res->end = range->cpu_addr + range->size - 1;
> +	res->parent = res->child = res->sibling = NULL;
> +	res->name = np->full_name;
> +}
> +
>  #ifdef CONFIG_OF_ADDRESS
>  extern u64 of_translate_address(struct device_node *np, const __be32 *addr);
>  extern bool of_can_translate_address(struct device_node *dev);
> @@ -27,6 +57,11 @@ static inline unsigned long pci_address_to_pio(phys_addr_t addr) { return -1; }
>  #define pci_address_to_pio pci_address_to_pio
>  #endif
> 
> +extern int of_pci_range_parser_init(struct of_pci_range_parser *parser,
> +			struct device_node *node);
> +extern struct of_pci_range *of_pci_range_parser_one(
> +					struct of_pci_range_parser *parser,
> +					struct of_pci_range *range);
>  #else /* CONFIG_OF_ADDRESS */
>  #ifndef of_address_to_resource
>  static inline int of_address_to_resource(struct device_node *dev, int index,
> @@ -53,6 +88,19 @@ static inline const __be32 *of_get_address(struct device_node *dev, int index,
>  {
>  	return NULL;
>  }
> +
> +static inline int of_pci_range_parser_init(struct of_pci_range_parser *parser,
> +			struct device_node *node)
> +{
> +	return -1;
> +}
> +
> +static inline struct of_pci_range *of_pci_range_parser_one(
> +					struct of_pci_range_parser *parser,
> +					struct of_pci_range *range)
> +{
> +	return NULL;
> +}
>  #endif /* CONFIG_OF_ADDRESS */
> 
> 
> --
> 1.7.0.4



From koen at dominion.thruhere.net  Fri Apr 26 05:33:59 2013
From: koen at dominion.thruhere.net (Koen Kooi)
Date: Fri, 26 Apr 2013 11:33:59 +0200
Subject: [PATCH 1/3] ARM: OMAP2+: Legacy support for wl12xx when booted
 with devicetree
In-Reply-To: <20130426035210.26065.39995.stgit@muffinssi.local>
References: <20130426034858.26065.65118.stgit@muffinssi.local>
 <20130426035210.26065.39995.stgit@muffinssi.local>
Message-ID: <0104F687-1726-476D-B2DF-7E72223B127A@dominion.thruhere.net>


Op 26 apr. 2013, om 05:52 heeft Tony Lindgren <tony at atomide.com> het volgende geschreven:

> Without WLAN we cannot switch omap4 to use device tree
> only booting. This patch can be reverted when the
> binding for wl12xx is added.

How much boards am I allowed to add to this? I need to get the wl12xx wifi expansionboards for beagleboard, beagleboard xM and beaglebone working with DT :)

regards,

Koen

From arnd at arndb.de  Fri Apr 26 05:34:54 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 26 Apr 2013 11:34:54 +0200
Subject: [PATCH 6/9] crypto: ux500/cryp - Set DMA configuration though
 dma_slave_config()
In-Reply-To: <CACRpkdaBf++gy3sghC-t33uio2+eHp1MrQ2FM0XXBazZTtm3kA@mail.gmail.com>
References: <1366280825-31136-1-git-send-email-lee.jones@linaro.org>
 <201304251611.39667.arnd@arndb.de>
 <CACRpkdaBf++gy3sghC-t33uio2+eHp1MrQ2FM0XXBazZTtm3kA@mail.gmail.com>
Message-ID: <1412321.eb7x7S18CK@wuerfel>

On Friday 26 April 2013 10:28:39 Linus Walleij wrote:
> 
> However this rings a bell that there may be a possible relation to
> DMA-API, since that API syncs memory buffers to the DMA
> address space if there is some MMU inbetween the DMA and the
> (ordinary, non-device) memory.
> 
> So if we think one step ahead, assuming the DMAC is actually behind
> an MMU making it see the device in some other address than the
> physical (bus) space, where would the address be resolved?

We don't currently have the infrastructure for that I think.
The dma-mapping API has some of the required parts but not all,
in particular it's only designed for mapping pages from the linear
kernel memory into the bus address space, not for devices.

The iommu API could do it for devices that have an IOMMU, but
it's not the best fit, because it does not abstract away the
presence of an IOMMU.

Another missing part is parsing the "dma-ranges" properties in
device tree, which you need to do if the address space translation
is not 1:1, and to find out which side of the IOMMU the DMA master
is connected to: if it's on the bus side, you need 1:1 mapping
and if it's on the host side, you need an IO page table entry.

	Arnd


From arnd at arndb.de  Fri Apr 26 05:39:20 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 26 Apr 2013 11:39:20 +0200
Subject: [PATCH 6/9] crypto: ux500/cryp - Set DMA configuration though
 dma_slave_config()
In-Reply-To: <20130426081646.GD24632@intel.com>
References: <1366280825-31136-1-git-send-email-lee.jones@linaro.org>
 <CACRpkdaBf++gy3sghC-t33uio2+eHp1MrQ2FM0XXBazZTtm3kA@mail.gmail.com>
 <20130426081646.GD24632@intel.com>
Message-ID: <1457204.tIrKjcEogd@wuerfel>

On Friday 26 April 2013 13:46:46 Vinod Koul wrote:
> 
> The mapping & unmapping of dma buffer (memcpy and memory buffer in this txn) is
> required to be performed by the client driver. The dmanegine or dmaengine driver
> will not do that for you...

I've been wondering about this part: since we need to pass the 'struct device' of
the dma engine (rather than the slave) into dma_map_single, what is the official
way to do that? Should the slave driver just rely on dma_chan->device->dev to
work correctly for the purpose of dma-mapping.h interfaces?

	Arnd


From linux at arm.linux.org.uk  Fri Apr 26 05:41:23 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Fri, 26 Apr 2013 10:41:23 +0100
Subject: [PATCH 6/9] crypto: ux500/cryp - Set DMA configuration though
 dma_slave_config()
In-Reply-To: <20130426081646.GD24632@intel.com>
References: <1366280825-31136-1-git-send-email-lee.jones@linaro.org>
 <CACRpkdbFgW6bGYt59WtN4r2izuN09AJw4J1cqir82uzFsuMmWQ@mail.gmail.com>
 <20130425134402.GN4623@gmail.com> <201304251611.39667.arnd@arndb.de>
 <CACRpkdaBf++gy3sghC-t33uio2+eHp1MrQ2FM0XXBazZTtm3kA@mail.gmail.com>
 <20130426081646.GD24632@intel.com>
Message-ID: <20130426094123.GG14496@n2100.arm.linux.org.uk>

On Fri, Apr 26, 2013 at 01:46:46PM +0530, Vinod Koul wrote:
> On Fri, Apr 26, 2013 at 10:28:39AM +0200, Linus Walleij wrote:
> > On Thu, Apr 25, 2013 at 4:11 PM, Arnd Bergmann <arnd at arndb.de> wrote:
> > 
> > > The dma engine driver must know the address in its dma space, while the
> > > slave driver has it available in physical space. These two are often the
> > > same, but there is no generic way to convert between the two, especially
> > > if the dma engine resides behind an IOMMU.
> > >
> > > The best assumption we can make is that the dma engine driver knows
> > > how to convert between the two. Interestingly the documentation for
> > > dma_slave_config talks about "physical address", while the structure
> > > itself uses a dma_addr_t. Linus Walleij introduced the structure in
> > > c156d0a5b0 "DMAENGINE: generic slave channel control v3", so I assume
> > > he can shed some light on what he was thinking. I assume the documentation
> > > is right but the structure is not and should be converted to use
> > > phys_add_t or resource_size_t.
> > 
> > OK I could cook a patch for that, but I think I need some input from
> > Vinod and/or Russell on this.
> the dma_slave_config is physical address that should be passed directly to the
> controller. Obviosuly it should phys_addr_t :)

What you've just said is actually confusing.

"physical address" is normally the term used to describe the addresses
seen to the RAM.  phys_addr_t describes this.  This is not necessarily
what needs to be programmed into the DMA controller.

For RAM addresses, they must be mapped via the DMA API - and this gives
you a dma_addr_t.

"DMA address" is the address to be programmed into a DMA controller to
access a particular address in RAM or device, and has type dma_addr_t.
When you're programming a DMA controller to access a device, you are
clearly telling it the address on the _DMA controller's bus_ to access
that register, which may or may not be the same as the physical address.

There are platforms in existence where phys_addr_t can be 32-bit but
dma_addr_t can be 64-bit.  Getting this stuff wrong can cause problems.


From linux at arm.linux.org.uk  Fri Apr 26 05:44:30 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Fri, 26 Apr 2013 10:44:30 +0100
Subject: [PATCH 6/9] crypto: ux500/cryp - Set DMA configuration though
 dma_slave_config()
In-Reply-To: <1457204.tIrKjcEogd@wuerfel>
References: <1366280825-31136-1-git-send-email-lee.jones@linaro.org>
 <CACRpkdaBf++gy3sghC-t33uio2+eHp1MrQ2FM0XXBazZTtm3kA@mail.gmail.com>
 <20130426081646.GD24632@intel.com> <1457204.tIrKjcEogd@wuerfel>
Message-ID: <20130426094430.GH14496@n2100.arm.linux.org.uk>

On Fri, Apr 26, 2013 at 11:39:20AM +0200, Arnd Bergmann wrote:
> On Friday 26 April 2013 13:46:46 Vinod Koul wrote:
> > 
> > The mapping & unmapping of dma buffer (memcpy and memory buffer in this txn) is
> > required to be performed by the client driver. The dmanegine or dmaengine driver
> > will not do that for you...
> 
> I've been wondering about this part: since we need to pass the 'struct device' of
> the dma engine (rather than the slave) into dma_map_single, what is the official
> way to do that? Should the slave driver just rely on dma_chan->device->dev to
> work correctly for the purpose of dma-mapping.h interfaces?

Yes.


From marc.zyngier at arm.com  Fri Apr 26 05:47:25 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Fri, 26 Apr 2013 11:47:25 +0200
Subject: [PATCH V2] ARM: KVM: Allow host virtual timer irq number to be
 different from guest virtual timer irq number
In-Reply-To: <1366960910-27651-1-git-send-email-anup.patel@linaro.org>
References: <1366960910-27651-1-git-send-email-anup.patel@linaro.org>
Message-ID: <3b52361974a390cff0bb0bc26b4a3b54@localhost>

Hi Anup,

On Fri, 26 Apr 2013 12:51:50 +0530, Anup Patel <anup.patel at linaro.org>
wrote:
> The arch_timer irq numbers (or PPI number) are implementation dependent
> so, the host virtual timer irq number can be different from guest
virtual
> timer irq number.
> 
> This patch ensures that host virtual timer irq number is read from DTB
and
> guest virtual timer irq is determined based on guest vcpu target type.

One word about communication first: Please keep me cc-ed on anything that
has to do with with vgic and timers. I'm the author of the code, I intend
to look after it, and this has some direct impact on the arm64 port. Thank
you.

> Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar at linaro.org>

Who is the author of this patch? You or Pranavkumar? If it is you, then
your Signed-off line should be present. If not, then there should be a
"From:" line at the beginning of the commit message.

> ---
>  arch/arm/include/asm/kvm_host.h |    1 +
>  arch/arm/kvm/arch_timer.c       |   25 ++++++++++++++++++-------
>  arch/arm/kvm/guest.c            |   15 +++++++++++++++
>  3 files changed, 34 insertions(+), 7 deletions(-)
> 
> diff --git a/arch/arm/include/asm/kvm_host.h
> b/arch/arm/include/asm/kvm_host.h
> index 57cb786..cdc0551 100644
> --- a/arch/arm/include/asm/kvm_host.h
> +++ b/arch/arm/include/asm/kvm_host.h
> @@ -43,6 +43,7 @@
>  struct kvm_vcpu;
>  u32 *kvm_vcpu_reg(struct kvm_vcpu *vcpu, u8 reg_num, u32 mode);
>  int kvm_target_cpu(void);
> +struct kvm_irq_level *kvm_target_timer_irq(struct kvm_vcpu *vcpu);
>  int kvm_reset_vcpu(struct kvm_vcpu *vcpu);
>  void kvm_reset_coprocs(struct kvm_vcpu *vcpu);
>  
> diff --git a/arch/arm/kvm/arch_timer.c b/arch/arm/kvm/arch_timer.c
> index 49a7516..521cdb9 100644
> --- a/arch/arm/kvm/arch_timer.c
> +++ b/arch/arm/kvm/arch_timer.c
> @@ -30,7 +30,7 @@
>  
>  static struct timecounter *timecounter;
>  static struct workqueue_struct *wqueue;
> -static struct kvm_irq_level timer_irq = {
> +static struct kvm_irq_level host_timer_irq = {
>  	.level	= 1,
>  };
>  
> @@ -65,10 +65,21 @@ static void kvm_timer_inject_irq(struct kvm_vcpu
*vcpu)
>  {
>  	struct arch_timer_cpu *timer = &vcpu->arch.timer_cpu;
>  
> +	/*
> +	 * The vcpu timer irq number cannont be determined in 
> +	 * kvm_timer_vcpu_init() because it is called much before
> +	 * kvm_vcpu_set_target(). To handle this, we determin
> +	 * vcpu timer irq number when we inject the vcpu timer irq
> +	 * first time. 
> +	 */
> +	if (!timer->irq) {
> +		timer->irq = kvm_target_timer_irq(vcpu);
> +	}

Please, not yet another of these. We already have kvm_vcpu_first_run_init
that collects all the "do this on first vcpu run" kind of thing.

>  	timer->cntv_ctl |= ARCH_TIMER_CTRL_IT_MASK;
>  	kvm_vgic_inject_irq(vcpu->kvm, vcpu->vcpu_id,
> -			    vcpu->arch.timer_cpu.irq->irq,
> -			    vcpu->arch.timer_cpu.irq->level);
> +			    timer->irq->irq,
> +			    timer->irq->level);
>  }
>  
>  static irqreturn_t kvm_arch_timer_handler(int irq, void *dev_id)
> @@ -163,12 +174,12 @@ void kvm_timer_vcpu_init(struct kvm_vcpu *vcpu)
>  	INIT_WORK(&timer->expired, kvm_timer_inject_irq_work);
>  	hrtimer_init(&timer->timer, CLOCK_MONOTONIC, HRTIMER_MODE_ABS);
>  	timer->timer.function = kvm_timer_expire;
> -	timer->irq = &timer_irq;
> +	timer->irq = NULL;
>  }

So with the above in mind, how about moving the call to
kvm_timer_vcpu_init into kvm_vcpu_first_run_init, and do the init once and
for all?

>  static void kvm_timer_init_interrupt(void *info)
>  {
> -	enable_percpu_irq(timer_irq.irq, 0);
> +	enable_percpu_irq(host_timer_irq.irq, 0);
>  }
>  
>  
> @@ -182,7 +193,7 @@ static int kvm_timer_cpu_notify(struct
notifier_block
> *self,
>  		break;
>  	case CPU_DYING:
>  	case CPU_DYING_FROZEN:
> -		disable_percpu_irq(timer_irq.irq);
> +		disable_percpu_irq(host_timer_irq.irq);
>  		break;
>  	}
>  
> @@ -230,7 +241,7 @@ int kvm_timer_hyp_init(void)
>  		goto out;
>  	}
>  
> -	timer_irq.irq = ppi;
> +	host_timer_irq.irq = ppi;
>  
>  	err = register_cpu_notifier(&kvm_timer_cpu_nb);
>  	if (err) {
> diff --git a/arch/arm/kvm/guest.c b/arch/arm/kvm/guest.c
> index 152d036..d87b05d 100644
> --- a/arch/arm/kvm/guest.c
> +++ b/arch/arm/kvm/guest.c
> @@ -36,6 +36,11 @@ struct kvm_stats_debugfs_item debugfs_entries[] = {
>  	{ NULL }
>  };
>  
> +struct kvm_irq_level target_default_timer_irq = {
> +	.irq = 27,
> +	.level = 1,
> +};

Don't call it default, as it is A15 specific. Also make it static.

>  int kvm_arch_vcpu_setup(struct kvm_vcpu *vcpu)
>  {
>  	return 0;
> @@ -197,6 +202,16 @@ int __attribute_const__ kvm_target_cpu(void)
>  	}
>  }
>  
> +struct kvm_irq_level *kvm_target_timer_irq(struct kvm_vcpu *vcpu)
> +{
> +	switch (vcpu->arch.target) {
> +	case KVM_ARM_TARGET_CORTEX_A15:
> +		return &target_default_timer_irq;
> +	default:
> +		return NULL;

And what do you do once you've returned NULL? Let the kernel crash?
Also, we now have a second path that tests the target (the first one is in
reset.c

Actually, scratch all the above, and move the irq assignment to reset.c.
It is probably the best place for it.

Thanks,

        M.
-- 
Fast, cheap, reliable. Pick two.


From catalin.marinas at arm.com  Fri Apr 26 06:00:02 2013
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Fri, 26 Apr 2013 11:00:02 +0100
Subject: [PATCH] of: Set the DMA mask to 64 bits on ARM LPAE systems
In-Reply-To: <51796365.5030405@codeaurora.org>
References: <1366764649-10342-1-git-send-email-lauraa@codeaurora.org>
 <20130425133315.GA7157@localhost.cambridge.arm.com>
 <51796365.5030405@codeaurora.org>
Message-ID: <20130426100001.GB5007@localhost.cambridge.arm.com>

On Thu, Apr 25, 2013 at 06:09:57PM +0100, Laura Abbott wrote:
> On 4/25/2013 6:33 AM, Catalin Marinas wrote:
> > On Wed, Apr 24, 2013 at 01:50:49AM +0100, Laura Abbott wrote:
> >> By default on ARM systems, the coherent DMA mask (lowest
> >> address) is set to ~0 or 0xFFFFFFFFFFFFFFFF. Currently,
> >> of_platform_device_create_pdata sets the coherent DMA mask to
> >> 32 bits. This prevents coherent dma allocations from working by default
> >> without clients setting the DMA mask. Rather than make every client
> >> on an LPAE system set the mask, set the mask to a 64 bit value on
> >> ARM LPAE systems.
> >>
> >> Signed-off-by: Laura Abbott <lauraa at codeaurora.org>
> >> ---
> >>   drivers/of/platform.c |    4 ++++
> >>   1 files changed, 4 insertions(+), 0 deletions(-)
> >>
> >> diff --git a/drivers/of/platform.c b/drivers/of/platform.c
> >> index 0970505..18b69c1 100644
> >> --- a/drivers/of/platform.c
> >> +++ b/drivers/of/platform.c
> >> @@ -214,7 +214,11 @@ struct platform_device *of_platform_device_create_pdata(
> >>   #if defined(CONFIG_MICROBLAZE)
> >>   	dev->archdata.dma_mask = 0xffffffffUL;
> >>   #endif
> >> +#ifdef CONFIG_ARM_LPAE
> >> +	dev->dev.coherent_dma_mask = DMA_BIT_MASK(64);
> >> +#else
> >>   	dev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
> >> +#endif
> >
> > I wouldn't add CONFIG_ARM_LPAE checks in here, you can use
> > CONFIG_ARCH_DMA_ADDR_T_64BIT (types.h uses this for the dma_addr_t
> > definition).
> >
> 
> I thought about this as well but in arch/arm/mm/mm.h:
> 
> #ifdef CONFIG_ZONE_DMA
> extern phys_addr_t arm_dma_limit;
> #else
> #define arm_dma_limit ((phys_addr_t)~0)
> #endif

Russell replied already on the meaning of this variable, so I don't
think its type is relevant here. It is also used when calling
dma_contiguous_reserve() which takes a phys_addr_t.

> arm_dma_limit is explicitly cast to phys_addr_t, which means that 
> arm_dma_limit will be always be sizeof(phys_addr_t) regardless of 
> sizeof(dma_addr_t). Is it safe to assume that 
> CONFIG_ARCH_DMA_ADDR_T_64BIT will always be selected if 
> sizeof(phys_addr_t) == 8? If not, we've defeated the point of the patch.

sizeof(dma_addr_t) <= sizeof(phys_addr_t). I had this discussion with
Russell when upstreaming the LPAE patches and the conclusion was that
while the phys_addr_t is 64-bit with LPAE, the dma_addr_t size is a
feature of the SoC and must be selected independently. However, I think
with multi-platform support and LPAE enabled, we should probably set the
dma_addr_t to 64-bit.

> Alternatively, should the type of arm_dma_limit be dma_addr_t instead of 
> phys_addr_t?

arm_dma_limit should be phys_addr_t since this is an address as seen by
the CPU. dma_addr_t OTOH is a bus address as seen by the device. You can
in theory have a DMA buffer with physical address beyond 32-bit (from a
CPU perspective) but with a bus address withing 32-bit as seen by the
device.

There is some confusion in the kernel (you can google for past
discussions) around the meaning of the DMA mask. If your RAM starts at
0, it doesn't matter much and there are several such assumptions in the
kernel.

So I still consider that you should use #ifdef
CONFIG_ARCH_DMA_ADDR_T_64BIT and select this option on your platform.

-- 
Catalin


From vincent.guittot at linaro.org  Fri Apr 26 06:00:58 2013
From: vincent.guittot at linaro.org (Vincent Guittot)
Date: Fri, 26 Apr 2013 12:00:58 +0200
Subject: [PATCH 11/14] sched: filter task pull request
In-Reply-To: <1366910611-20048-12-git-send-email-vincent.guittot@linaro.org>
References: <1366910611-20048-1-git-send-email-vincent.guittot@linaro.org>
 <1366910611-20048-12-git-send-email-vincent.guittot@linaro.org>
Message-ID: <CAKfTPtCUvKmTHzyVRCkGyM-nWOSWP8OUzMgyCyzPEXf1NoxsQQ@mail.gmail.com>

Part of this patch is missing, the fix below is needed

@@ -3497,7 +3497,9 @@ static bool is_buddy_full(int cpu)
 static bool is_my_buddy(int cpu, int buddy)
 {
  int my_buddy = per_cpu(sd_pack_buddy, cpu);
- return (my_buddy == -1) || (buddy == my_buddy);
+
+ return ((sysctl_sched_packing_mode == SCHED_PACKING_FULL) &&
+               ((my_buddy == -1) || (buddy == my_buddy)));
 }

 static bool is_light_task(struct task_struct *p)


On 25 April 2013 19:23, Vincent Guittot <vincent.guittot at linaro.org> wrote:
> Only CPUs that participates to the packing effort can pull tasks on a busiest
> group.
>
> Signed-off-by: Vincent Guittot <vincent.guittot at linaro.org>
> ---
>  kernel/sched/fair.c |   14 ++++++++++++--
>  1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 28f8ea7..6f63fb9 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -3494,6 +3494,12 @@ static bool is_buddy_full(int cpu)
>         return (sum * 1024 >= period * 1000);
>  }
>
> +static bool is_my_buddy(int cpu, int buddy)
> +{
> +       int my_buddy = per_cpu(sd_pack_buddy, cpu);
> +       return (my_buddy == -1) || (buddy == my_buddy);
> +}
> +
>  static bool is_light_task(struct task_struct *p)
>  {
>         /* A light task runs less than 20% in average */
> @@ -4688,8 +4694,8 @@ static inline void update_sg_lb_stats(struct lb_env *env,
>
>                 /* Bias balancing toward cpus of our domain */
>                 if (local_group) {
> -                       if (idle_cpu(i) && !first_idle_cpu &&
> -                                       cpumask_test_cpu(i, sched_group_mask(group))) {
> +                       if (is_my_buddy(i, i) && idle_cpu(i) && !first_idle_cpu
> +                        && cpumask_test_cpu(i, sched_group_mask(group))) {
>                                 first_idle_cpu = 1;
>                                 balance_cpu = i;
>                         }
> @@ -4817,6 +4823,10 @@ static void update_plb_buddy(int cpu, int *balance, struct sd_lb_stats *sds,
>
>         /* Get my new buddy */
>         buddy = per_cpu(sd_pack_buddy, cpu);
> +
> +       /* This CPU doesn't act for agressive packing */
> +       if (buddy != cpu)
> +               sds->busiest = 0;
>  }
>
>  /**
> --
> 1.7.9.5
>


From lorenzo.pieralisi at arm.com  Fri Apr 26 06:18:40 2013
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Fri, 26 Apr 2013 11:18:40 +0100
Subject: [RFC PATCH v3 02/17] Documentation: devicetree: arm: cpus/cpu
 nodes bindings updates
In-Reply-To: <CAL_JsqL2QOjTffogB6g7VK7oRUwDAmJpr=36uvFXjd+hpBL89A@mail.gmail.com>
References: <1366824502-19729-1-git-send-email-lorenzo.pieralisi@arm.com>
 <1366824502-19729-3-git-send-email-lorenzo.pieralisi@arm.com>
 <CAL_JsqL2QOjTffogB6g7VK7oRUwDAmJpr=36uvFXjd+hpBL89A@mail.gmail.com>
Message-ID: <20130426101839.GA3093@e102568-lin.cambridge.arm.com>

On Fri, Apr 26, 2013 at 03:51:10AM +0100, Rob Herring wrote:
> On Wed, Apr 24, 2013 at 12:28 PM, Lorenzo Pieralisi
> <lorenzo.pieralisi at arm.com> wrote:
> > In order to extend the current cpu nodes bindings to newer CPUs
> > inclusive of AArch64 and to update support for older ARM CPUs this
> > patch updates device tree documentation for the cpu nodes bindings.
> >
> > Main changes:
> >     - adds 64-bit bindings
> >     - define usage of #address-cells
> >     - define 32/64 dts compatibility settings
> >     - defines behaviour on pre and post v7 uniprocessor systems
> >     - adds ARM 11MPcore specific reg property definition
> >
> > Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
> > ---
> 
> [...]
> 
> > +       - enable-method
> > +               Value type: <stringlist>
> > +               Usage and definition depend on ARM architecture version and
> > +               configuration:
> > +                       # On ARM v8 64-bit systems running the OS in AArch64,
> > +                         this property is required and must be "spin-table".
> 
> What about PSCI?

I should add it, at least for ARM v8.

> I don't think the ePAPR spin-table definition is sufficient for ARM.
> How do you define wake up by SGI or sev instruction.

I think Will described the wfe/sev mechanism in:

Documentation/arm64/booting.txt

and the ePAPR does the same in 5.5.2.2/5.5.2.3. Since this is a document
describing cpus/cpu nodes bindings I assume that description does not
belong here. Question is: do we need to specify an ARM implementation
specific enable-method to describe SGI/sev wake-up (ePAPR 5.5.3) ?

> > +                       # On ARM 32-bit systems or ARM v8 systems running
> > +                         the OS in AArch32 this property is prohibited.
> 
> Why?

Because if we define it optional with no possible set of values basically
it can be whatever string. I could define it optional with the same
allowed values as ARM v8 even if it is currently ignored, at least in Linux,
until PSCI implementations get merged.

Thanks,
Lorenzo



From linus.walleij at linaro.org  Fri Apr 26 06:18:59 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Fri, 26 Apr 2013 12:18:59 +0200
Subject: [PATCH] ARM: Adds pin config API to set all configs in one
 function
In-Reply-To: <1366841010-2823-1-git-send-email-syin@broadcom.com>
References: <1366841010-2823-1-git-send-email-syin@broadcom.com>
Message-ID: <CACRpkdbT7f8ujCHZxKg26iMKcrAb+_yHW_2YsZwkoo892rkgTA@mail.gmail.com>

On Thu, Apr 25, 2013 at 12:03 AM, Sherman Yin <syin at broadcom.com> wrote:

> Currently, when setting pin configuration in the pinctrl framework,
> pin_config_set() or pin_config_group_set() is called in a loop to set one
> configuration at a time for the specified pin or group.
>
> pin_config_set_all() and pin_config_group_set_all() are defined to set all
> configurations for the specified pin or group at the same time.  These optional
> APIs allow pinctrl drivers to optimize and combine pin configurations to reduce
> the number of register writes required to configure a pin.
>
> If both pin_config_set() and pin_config_set_all() are defined by a driver, the
> latter takes precedence.  Similarly for pin_config_group_set_all().
>
> Signed-off-by: Sherman Yin <syin at broadcom.com>

NAK, sorry.

We discussed this already at the creation of the pinctrl framework.

What you should do is to add an optional pin_config_set_complete()
and pin_config_group_set_complete()
callback that is called after the framework has iterated over all
configs.

This way the responsibility to resolve the sequence of config
calls and validate the validity of that sequence is pushed down
to the driver, it may do this incrementally or at pin_config_set_complete()
and then write the resulting config to the hardware as an
effect of pin_config_set_complete().

The driver takes care of caching intermediate settings for the pin
until the complete() callback is called.

Can you devise a patch like this instead?

I am also very hesitant to merge this if there is no code using
it, i.e. if you don't have a corresponding driver to submit
at the same time, it will not be merged, as I don't like to
maintain dead code.

Yours,
Linus Walleij


From peterz at infradead.org  Fri Apr 26 06:18:49 2013
From: peterz at infradead.org (Peter Zijlstra)
Date: Fri, 26 Apr 2013 12:18:49 +0200
Subject: [RFC PATCH v3 3/6] sched: pack small tasks
In-Reply-To: <5152C83F.6060509@linux.vnet.ibm.com>
References: <1363955155-18382-1-git-send-email-vincent.guittot@linaro.org>
 <1363955155-18382-4-git-send-email-vincent.guittot@linaro.org>
 <1364300782.5053.6.camel@laptop>
 <5152C83F.6060509@linux.vnet.ibm.com>
Message-ID: <20130426101849.GD8669@dyad.programming.kicks-ass.net>

On Wed, Mar 27, 2013 at 03:51:51PM +0530, Preeti U Murthy wrote:
> Hi,
> 
> On 03/26/2013 05:56 PM, Peter Zijlstra wrote:
> > On Fri, 2013-03-22 at 13:25 +0100, Vincent Guittot wrote:
> >> +static bool is_buddy_busy(int cpu)
> >> +{
> >> +       struct rq *rq = cpu_rq(cpu);
> >> +
> >> +       /*
> >> +        * A busy buddy is a CPU with a high load or a small load with
> >> a lot of
> >> +        * running tasks.
> >> +        */
> >> +       return (rq->avg.runnable_avg_sum >
> >> +                       (rq->avg.runnable_avg_period / (rq->nr_running
> >> + 2)));
> >> +}
> > 
> > Why does the comment talk about load but we don't see it in the
> > equation. Also, why does nr_running matter at all? I thought we'd
> > simply bother with utilization, if fully utilized we're done etc..
> > 
> 
> Peter, lets say the run-queue has 50% utilization and is running 2
> tasks. And we wish to find out if it is busy. We would compare this
> metric with the cpu power, which lets say is 100.
> 
> rq->util * 100 < cpu_of(rq)->power.
> 
> In the above scenario would we declare the cpu _not_busy? Or would we do
> the following:
> 
> (rq->util * 100) * #nr_running <  cpu_of(rq)->power and conclude that it
> is just enough _busy_ to not take on more processes?

That is just confused... ->power doesn't have anything to do with a per-cpu
measure. ->power is a inter-cpu measure of relative compute capacity.

Mixing in nr_running confuses things even more; it doesn't matter how many
tasks it takes to push utilization up to 100%; once its there the cpu simply
cannot run more.

So colour me properly confused..


From anup.patel at linaro.org  Fri Apr 26 06:12:57 2013
From: anup.patel at linaro.org (Anup Patel)
Date: Fri, 26 Apr 2013 15:42:57 +0530
Subject: [PATCH V2] ARM: KVM: Allow host virtual timer irq number to be
 different from guest virtual timer irq number
In-Reply-To: <3b52361974a390cff0bb0bc26b4a3b54@localhost>
References: <1366960910-27651-1-git-send-email-anup.patel@linaro.org>
 <3b52361974a390cff0bb0bc26b4a3b54@localhost>
Message-ID: <CALrVBktcs+Zwmqdi3JfCudF9TN1rSRSRokB=BJJh60jEmJna-A@mail.gmail.com>

Hi Marc,

On 26 April 2013 15:17, Marc Zyngier <marc.zyngier at arm.com> wrote:
> Hi Anup,
>
> On Fri, 26 Apr 2013 12:51:50 +0530, Anup Patel <anup.patel at linaro.org>
> wrote:
>> The arch_timer irq numbers (or PPI number) are implementation dependent
>> so, the host virtual timer irq number can be different from guest
> virtual
>> timer irq number.
>>
>> This patch ensures that host virtual timer irq number is read from DTB
> and
>> guest virtual timer irq is determined based on guest vcpu target type.
>
> One word about communication first: Please keep me cc-ed on anything that
> has to do with with vgic and timers. I'm the author of the code, I intend
> to look after it, and this has some direct impact on the arm64 port. Thank
> you.

Sure, I'll CC you for arch_timer and vgic changes.

>
>> Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar at linaro.org>
>
> Who is the author of this patch? You or Pranavkumar? If it is you, then
> your Signed-off line should be present. If not, then there should be a
> "From:" line at the beginning of the commit message.

I really thought "From" is implicit and the sender of the email is the author.

Pranav has co-authored this patch hence his signed-off by him.

Anyways, I will put signed-off by me and Pranav both.

>
>> ---
>>  arch/arm/include/asm/kvm_host.h |    1 +
>>  arch/arm/kvm/arch_timer.c       |   25 ++++++++++++++++++-------
>>  arch/arm/kvm/guest.c            |   15 +++++++++++++++
>>  3 files changed, 34 insertions(+), 7 deletions(-)
>>
>> diff --git a/arch/arm/include/asm/kvm_host.h
>> b/arch/arm/include/asm/kvm_host.h
>> index 57cb786..cdc0551 100644
>> --- a/arch/arm/include/asm/kvm_host.h
>> +++ b/arch/arm/include/asm/kvm_host.h
>> @@ -43,6 +43,7 @@
>>  struct kvm_vcpu;
>>  u32 *kvm_vcpu_reg(struct kvm_vcpu *vcpu, u8 reg_num, u32 mode);
>>  int kvm_target_cpu(void);
>> +struct kvm_irq_level *kvm_target_timer_irq(struct kvm_vcpu *vcpu);
>>  int kvm_reset_vcpu(struct kvm_vcpu *vcpu);
>>  void kvm_reset_coprocs(struct kvm_vcpu *vcpu);
>>
>> diff --git a/arch/arm/kvm/arch_timer.c b/arch/arm/kvm/arch_timer.c
>> index 49a7516..521cdb9 100644
>> --- a/arch/arm/kvm/arch_timer.c
>> +++ b/arch/arm/kvm/arch_timer.c
>> @@ -30,7 +30,7 @@
>>
>>  static struct timecounter *timecounter;
>>  static struct workqueue_struct *wqueue;
>> -static struct kvm_irq_level timer_irq = {
>> +static struct kvm_irq_level host_timer_irq = {
>>       .level  = 1,
>>  };
>>
>> @@ -65,10 +65,21 @@ static void kvm_timer_inject_irq(struct kvm_vcpu
> *vcpu)
>>  {
>>       struct arch_timer_cpu *timer = &vcpu->arch.timer_cpu;
>>
>> +     /*
>> +      * The vcpu timer irq number cannont be determined in
>> +      * kvm_timer_vcpu_init() because it is called much before
>> +      * kvm_vcpu_set_target(). To handle this, we determin
>> +      * vcpu timer irq number when we inject the vcpu timer irq
>> +      * first time.
>> +      */
>> +     if (!timer->irq) {
>> +             timer->irq = kvm_target_timer_irq(vcpu);
>> +     }
>
> Please, not yet another of these. We already have kvm_vcpu_first_run_init
> that collects all the "do this on first vcpu run" kind of thing.
>
>>       timer->cntv_ctl |= ARCH_TIMER_CTRL_IT_MASK;
>>       kvm_vgic_inject_irq(vcpu->kvm, vcpu->vcpu_id,
>> -                         vcpu->arch.timer_cpu.irq->irq,
>> -                         vcpu->arch.timer_cpu.irq->level);
>> +                         timer->irq->irq,
>> +                         timer->irq->level);
>>  }
>>
>>  static irqreturn_t kvm_arch_timer_handler(int irq, void *dev_id)
>> @@ -163,12 +174,12 @@ void kvm_timer_vcpu_init(struct kvm_vcpu *vcpu)
>>       INIT_WORK(&timer->expired, kvm_timer_inject_irq_work);
>>       hrtimer_init(&timer->timer, CLOCK_MONOTONIC, HRTIMER_MODE_ABS);
>>       timer->timer.function = kvm_timer_expire;
>> -     timer->irq = &timer_irq;
>> +     timer->irq = NULL;
>>  }
>
> So with the above in mind, how about moving the call to
> kvm_timer_vcpu_init into kvm_vcpu_first_run_init, and do the init once and
> for all?

Yes, this would be even more cleaner.

>
>>  static void kvm_timer_init_interrupt(void *info)
>>  {
>> -     enable_percpu_irq(timer_irq.irq, 0);
>> +     enable_percpu_irq(host_timer_irq.irq, 0);
>>  }
>>
>>
>> @@ -182,7 +193,7 @@ static int kvm_timer_cpu_notify(struct
> notifier_block
>> *self,
>>               break;
>>       case CPU_DYING:
>>       case CPU_DYING_FROZEN:
>> -             disable_percpu_irq(timer_irq.irq);
>> +             disable_percpu_irq(host_timer_irq.irq);
>>               break;
>>       }
>>
>> @@ -230,7 +241,7 @@ int kvm_timer_hyp_init(void)
>>               goto out;
>>       }
>>
>> -     timer_irq.irq = ppi;
>> +     host_timer_irq.irq = ppi;
>>
>>       err = register_cpu_notifier(&kvm_timer_cpu_nb);
>>       if (err) {
>> diff --git a/arch/arm/kvm/guest.c b/arch/arm/kvm/guest.c
>> index 152d036..d87b05d 100644
>> --- a/arch/arm/kvm/guest.c
>> +++ b/arch/arm/kvm/guest.c
>> @@ -36,6 +36,11 @@ struct kvm_stats_debugfs_item debugfs_entries[] = {
>>       { NULL }
>>  };
>>
>> +struct kvm_irq_level target_default_timer_irq = {
>> +     .irq = 27,
>> +     .level = 1,
>> +};
>
> Don't call it default, as it is A15 specific. Also make it static.

Sure, will update this.

>
>>  int kvm_arch_vcpu_setup(struct kvm_vcpu *vcpu)
>>  {
>>       return 0;
>> @@ -197,6 +202,16 @@ int __attribute_const__ kvm_target_cpu(void)
>>       }
>>  }
>>
>> +struct kvm_irq_level *kvm_target_timer_irq(struct kvm_vcpu *vcpu)
>> +{
>> +     switch (vcpu->arch.target) {
>> +     case KVM_ARM_TARGET_CORTEX_A15:
>> +             return &target_default_timer_irq;
>> +     default:
>> +             return NULL;
>
> And what do you do once you've returned NULL? Let the kernel crash?
> Also, we now have a second path that tests the target (the first one is in
> reset.c

Actually, this function is expected to be called as part of VCPU init
and if we get NULL then we should fail the VCPU init.

>
> Actually, scratch all the above, and move the irq assignment to reset.c.
> It is probably the best place for it.

Sure, I will try this and send another patch which addresses all comments.

>
> Thanks,
>
>         M.
> --
> Fast, cheap, reliable. Pick two.

Regards,
Anup


From stefano.stabellini at eu.citrix.com  Fri Apr 26 06:27:00 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Fri, 26 Apr 2013 11:27:00 +0100
Subject: [PATCH v4 2/7] xen/arm: SMP support
In-Reply-To: <1366966304.3142.33.camel@zakaz.uk.xensource.com>
References: <alpine.DEB.2.02.1304242012590.4180@kaball.uk.xensource.com>
 <1366831695-13214-2-git-send-email-stefano.stabellini@eu.citrix.com>
 <1366897221.20256.544.camel@zakaz.uk.xensource.com>
 <alpine.DEB.2.02.1304251503100.4180@kaball.uk.xensource.com>
 <1366909184.3142.0.camel@zakaz.uk.xensource.com>
 <alpine.DEB.2.02.1304251945290.4180@kaball.uk.xensource.com>
 <1366966304.3142.33.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1304261125440.4180@kaball.uk.xensource.com>

On Fri, 26 Apr 2013, Ian Campbell wrote:
> On Thu, 2013-04-25 at 19:45 +0100, Stefano Stabellini wrote:
> > On Thu, 25 Apr 2013, Ian Campbell wrote:
> > > > > > @@ -216,6 +245,8 @@ static int __init xen_guest_init(void)
> > > > > >  	 * is required to use VCPUOP_register_vcpu_info to place vcpu info
> > > > > >  	 * for secondary CPUs as they are brought up. */
> > > > > >  	per_cpu(xen_vcpu, 0) = &HYPERVISOR_shared_info->vcpu_info[0];
> > > > > > +	for_each_online_cpu(i)
> > > > > > +		xen_secondary_init(i);
> > > > > >  
> > > > > >  	gnttab_init();
> > > > > >  	if (!xen_initial_domain())
> > > > > [...]
> > > > > > @@ -244,7 +280,7 @@ static int __init xen_init_events(void)
> > > > > >  		return -EINVAL;
> > > > > >  	}
> > > > > >  
> > > > > > -	enable_percpu_irq(xen_events_irq, 0);
> > > > > > +	on_each_cpu(xen_percpu_enable_events, NULL, 0);
> > > > > 
> > > > > It feels like there ought to be some sort of per-cpu bringup callback
> > > > > which takes care of these dynamically. Maybe that doesn't matter until
> > > > > we get vcpu hotplug going?
> > > > 
> > > > I suspect there isn't one, considering that on_each_cpu is also used by 
> > > > kvm_vgic_hyp_init, kvm_timer_hyp_init and others.
> > > 
> > > Could we use cpu_notifiers for this?
> > 
> > cpu_notifiers are for cpu hotplug, not for secondary cpu bringup
> 
> Are you sure they don't also trigger during bringup, because the
> distinction is a little bit academic...

My mistake, they do run on secondary cpus, but not in our case because
xen_guest_init is called *after* cpu_notifiers are called.
So, they are too early for Xen.


From Ian.Campbell at citrix.com  Fri Apr 26 06:30:56 2013
From: Ian.Campbell at citrix.com (Ian Campbell)
Date: Fri, 26 Apr 2013 11:30:56 +0100
Subject: [PATCH v4 2/7] xen/arm: SMP support
In-Reply-To: <alpine.DEB.2.02.1304261125440.4180@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1304242012590.4180@kaball.uk.xensource.com>
 <1366831695-13214-2-git-send-email-stefano.stabellini@eu.citrix.com>
 <1366897221.20256.544.camel@zakaz.uk.xensource.com>
 <alpine.DEB.2.02.1304251503100.4180@kaball.uk.xensource.com>
 <1366909184.3142.0.camel@zakaz.uk.xensource.com>
 <alpine.DEB.2.02.1304251945290.4180@kaball.uk.xensource.com>
 <1366966304.3142.33.camel@zakaz.uk.xensource.com>
 <alpine.DEB.2.02.1304261125440.4180@kaball.uk.xensource.com>
Message-ID: <1366972256.3142.60.camel@zakaz.uk.xensource.com>

On Fri, 2013-04-26 at 11:27 +0100, Stefano Stabellini wrote:
> On Fri, 26 Apr 2013, Ian Campbell wrote:
> > On Thu, 2013-04-25 at 19:45 +0100, Stefano Stabellini wrote:
> > > On Thu, 25 Apr 2013, Ian Campbell wrote:
> > > > > > > @@ -216,6 +245,8 @@ static int __init xen_guest_init(void)
> > > > > > >  	 * is required to use VCPUOP_register_vcpu_info to place vcpu info
> > > > > > >  	 * for secondary CPUs as they are brought up. */
> > > > > > >  	per_cpu(xen_vcpu, 0) = &HYPERVISOR_shared_info->vcpu_info[0];
> > > > > > > +	for_each_online_cpu(i)
> > > > > > > +		xen_secondary_init(i);
> > > > > > >  
> > > > > > >  	gnttab_init();
> > > > > > >  	if (!xen_initial_domain())
> > > > > > [...]
> > > > > > > @@ -244,7 +280,7 @@ static int __init xen_init_events(void)
> > > > > > >  		return -EINVAL;
> > > > > > >  	}
> > > > > > >  
> > > > > > > -	enable_percpu_irq(xen_events_irq, 0);
> > > > > > > +	on_each_cpu(xen_percpu_enable_events, NULL, 0);
> > > > > > 
> > > > > > It feels like there ought to be some sort of per-cpu bringup callback
> > > > > > which takes care of these dynamically. Maybe that doesn't matter until
> > > > > > we get vcpu hotplug going?
> > > > > 
> > > > > I suspect there isn't one, considering that on_each_cpu is also used by 
> > > > > kvm_vgic_hyp_init, kvm_timer_hyp_init and others.
> > > > 
> > > > Could we use cpu_notifiers for this?
> > > 
> > > cpu_notifiers are for cpu hotplug, not for secondary cpu bringup
> > 
> > Are you sure they don't also trigger during bringup, because the
> > distinction is a little bit academic...
> 
> My mistake, they do run on secondary cpus, but not in our case because
> xen_guest_init is called *after* cpu_notifiers are called.
> So, they are too early for Xen.

Another reason to consider calling xen_guest_init much earlier then
IMHO. although we can live with the solution you have now I suppose.

Ian.



From peterz at infradead.org  Fri Apr 26 06:30:19 2013
From: peterz at infradead.org (Peter Zijlstra)
Date: Fri, 26 Apr 2013 12:30:19 +0200
Subject: [RFC PATCH v3 3/6] sched: pack small tasks
In-Reply-To: <CAKfTPtCphgnT6_WSdHJR+_GcdfroL+OFhiqsr_rBFx5=apkTVQ@mail.gmail.com>
References: <1363955155-18382-1-git-send-email-vincent.guittot@linaro.org>
 <1363955155-18382-4-git-send-email-vincent.guittot@linaro.org>
 <1364300782.5053.6.camel@laptop>
 <5152C83F.6060509@linux.vnet.ibm.com>
 <CAKfTPtCphgnT6_WSdHJR+_GcdfroL+OFhiqsr_rBFx5=apkTVQ@mail.gmail.com>
Message-ID: <20130426103019.GE8669@dyad.programming.kicks-ass.net>

On Wed, Mar 27, 2013 at 12:00:40PM +0100, Vincent Guittot wrote:
> On 27 March 2013 11:21, Preeti U Murthy <preeti at linux.vnet.ibm.com> wrote:
> > Hi,
> >
> > On 03/26/2013 05:56 PM, Peter Zijlstra wrote:
> >> On Fri, 2013-03-22 at 13:25 +0100, Vincent Guittot wrote:
> >>> +static bool is_buddy_busy(int cpu)
> >>> +{
> >>> +       struct rq *rq = cpu_rq(cpu);
> >>> +
> >>> +       /*
> >>> +        * A busy buddy is a CPU with a high load or a small load with
> >>> a lot of
> >>> +        * running tasks.
> >>> +        */
> >>> +       return (rq->avg.runnable_avg_sum >
> >>> +                       (rq->avg.runnable_avg_period / (rq->nr_running
> >>> + 2)));
> >>> +}
> >>
> >> Why does the comment talk about load but we don't see it in the
> >> equation. Also, why does nr_running matter at all? I thought we'd
> >> simply bother with utilization, if fully utilized we're done etc..
> 
> By load, I mean : 100 * avg.runnable_avg_sum / avg.runnable_avg_period
> In addition, i take into account the number of tasks already in the
> runqueue in order to define the business of a CPU. A CPU with a load
> of 50% without any tasks in the runqeue in not busy at this time and
> we can migrate tasks on it but if the CPU already has 2 tasks in its
> runqueue, it means that newly wake up task will have to share the CPU
> with other tasks so we consider that the CPU is already busy and we
> will fall back to default behavior. The equation considers that a CPU
> is not busy if
> 100 * avg.runnable_avg_sum / avg.runnable_avg_period < 100 / (nr_running + 2)

I'm still somewhat confused by all this. So raising nr_running will lower the
required utilization to be considered busy. Suppose we have 50 tasks running,
all at 1% utilization (bulk wakeup) we'd consider the cpu busy, even though its
picking its nose for half the time.


I'm assuming it's mean to limit process latency or so? Why are you concerned
with that? This seems like an arbitrary power vs performance tweak without
solid effidence its needed or even wanted.


From stefano.stabellini at eu.citrix.com  Fri Apr 26 06:33:50 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Fri, 26 Apr 2013 11:33:50 +0100
Subject: [PATCH v4 2/7] xen/arm: SMP support
In-Reply-To: <1366972256.3142.60.camel@zakaz.uk.xensource.com>
References: <alpine.DEB.2.02.1304242012590.4180@kaball.uk.xensource.com>
 <1366831695-13214-2-git-send-email-stefano.stabellini@eu.citrix.com>
 <1366897221.20256.544.camel@zakaz.uk.xensource.com>
 <alpine.DEB.2.02.1304251503100.4180@kaball.uk.xensource.com>
 <1366909184.3142.0.camel@zakaz.uk.xensource.com>
 <alpine.DEB.2.02.1304251945290.4180@kaball.uk.xensource.com>
 <1366966304.3142.33.camel@zakaz.uk.xensource.com>
 <alpine.DEB.2.02.1304261125440.4180@kaball.uk.xensource.com>
 <1366972256.3142.60.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1304261132470.4180@kaball.uk.xensource.com>

On Fri, 26 Apr 2013, Ian Campbell wrote:
> On Fri, 2013-04-26 at 11:27 +0100, Stefano Stabellini wrote:
> > On Fri, 26 Apr 2013, Ian Campbell wrote:
> > > On Thu, 2013-04-25 at 19:45 +0100, Stefano Stabellini wrote:
> > > > On Thu, 25 Apr 2013, Ian Campbell wrote:
> > > > > > > > @@ -216,6 +245,8 @@ static int __init xen_guest_init(void)
> > > > > > > >  	 * is required to use VCPUOP_register_vcpu_info to place vcpu info
> > > > > > > >  	 * for secondary CPUs as they are brought up. */
> > > > > > > >  	per_cpu(xen_vcpu, 0) = &HYPERVISOR_shared_info->vcpu_info[0];
> > > > > > > > +	for_each_online_cpu(i)
> > > > > > > > +		xen_secondary_init(i);
> > > > > > > >  
> > > > > > > >  	gnttab_init();
> > > > > > > >  	if (!xen_initial_domain())
> > > > > > > [...]
> > > > > > > > @@ -244,7 +280,7 @@ static int __init xen_init_events(void)
> > > > > > > >  		return -EINVAL;
> > > > > > > >  	}
> > > > > > > >  
> > > > > > > > -	enable_percpu_irq(xen_events_irq, 0);
> > > > > > > > +	on_each_cpu(xen_percpu_enable_events, NULL, 0);
> > > > > > > 
> > > > > > > It feels like there ought to be some sort of per-cpu bringup callback
> > > > > > > which takes care of these dynamically. Maybe that doesn't matter until
> > > > > > > we get vcpu hotplug going?
> > > > > > 
> > > > > > I suspect there isn't one, considering that on_each_cpu is also used by 
> > > > > > kvm_vgic_hyp_init, kvm_timer_hyp_init and others.
> > > > > 
> > > > > Could we use cpu_notifiers for this?
> > > > 
> > > > cpu_notifiers are for cpu hotplug, not for secondary cpu bringup
> > > 
> > > Are you sure they don't also trigger during bringup, because the
> > > distinction is a little bit academic...
> > 
> > My mistake, they do run on secondary cpus, but not in our case because
> > xen_guest_init is called *after* cpu_notifiers are called.
> > So, they are too early for Xen.
> 
> Another reason to consider calling xen_guest_init much earlier then
> IMHO. although we can live with the solution you have now I suppose.

Yeah, moving the call to xen_guest_init earlier might be a good idea,
but I wouldn't want to do it in this patch series, at this point of the
Linux release cycle.


From preeti at linux.vnet.ibm.com  Fri Apr 26 06:32:27 2013
From: preeti at linux.vnet.ibm.com (Preeti U Murthy)
Date: Fri, 26 Apr 2013 16:02:27 +0530
Subject: [RFC PATCH v3 3/6] sched: pack small tasks
In-Reply-To: <20130426101849.GD8669@dyad.programming.kicks-ass.net>
References: <1363955155-18382-1-git-send-email-vincent.guittot@linaro.org>
 <1363955155-18382-4-git-send-email-vincent.guittot@linaro.org>
 <1364300782.5053.6.camel@laptop> <5152C83F.6060509@linux.vnet.ibm.com>
 <20130426101849.GD8669@dyad.programming.kicks-ass.net>
Message-ID: <517A57BB.8000009@linux.vnet.ibm.com>

Hi Peter,

On 04/26/2013 03:48 PM, Peter Zijlstra wrote:
> On Wed, Mar 27, 2013 at 03:51:51PM +0530, Preeti U Murthy wrote:
>> Hi,
>>
>> On 03/26/2013 05:56 PM, Peter Zijlstra wrote:
>>> On Fri, 2013-03-22 at 13:25 +0100, Vincent Guittot wrote:
>>>> +static bool is_buddy_busy(int cpu)
>>>> +{
>>>> +       struct rq *rq = cpu_rq(cpu);
>>>> +
>>>> +       /*
>>>> +        * A busy buddy is a CPU with a high load or a small load with
>>>> a lot of
>>>> +        * running tasks.
>>>> +        */
>>>> +       return (rq->avg.runnable_avg_sum >
>>>> +                       (rq->avg.runnable_avg_period / (rq->nr_running
>>>> + 2)));
>>>> +}
>>>
>>> Why does the comment talk about load but we don't see it in the
>>> equation. Also, why does nr_running matter at all? I thought we'd
>>> simply bother with utilization, if fully utilized we're done etc..
>>>
>>
>> Peter, lets say the run-queue has 50% utilization and is running 2
>> tasks. And we wish to find out if it is busy. We would compare this
>> metric with the cpu power, which lets say is 100.
>>
>> rq->util * 100 < cpu_of(rq)->power.
>>
>> In the above scenario would we declare the cpu _not_busy? Or would we do
>> the following:
>>
>> (rq->util * 100) * #nr_running <  cpu_of(rq)->power and conclude that it
>> is just enough _busy_ to not take on more processes?
> 
> That is just confused... ->power doesn't have anything to do with a per-cpu
> measure. ->power is a inter-cpu measure of relative compute capacity.

Ok.

> 
> Mixing in nr_running confuses things even more; it doesn't matter how many
> tasks it takes to push utilization up to 100%; once its there the cpu simply
> cannot run more.

True, this is from the perspective of the CPU. But will not the tasks on
this CPU get throttled if, you find the utilization of this CPU < 100%
and decide to put more tasks on it?

Regards
Preeti U Murthy




From heiko at sntech.de  Fri Apr 26 06:39:38 2013
From: heiko at sntech.de (Heiko =?utf-8?q?St=C3=BCbner?=)
Date: Fri, 26 Apr 2013 12:39:38 +0200
Subject: [PATCH 12/21] irqchip: s3c24xx: add missing __init annotations
In-Reply-To: <1366910944-3033663-13-git-send-email-arnd@arndb.de>
References: <1366910944-3033663-1-git-send-email-arnd@arndb.de>
 <1366910944-3033663-13-git-send-email-arnd@arndb.de>
Message-ID: <201304261239.38737.heiko@sntech.de>

Am Donnerstag, 25. April 2013, 19:28:55 schrieb Arnd Bergmann:
> The s3c24xx_init_intc and s3c2412_init_irq functions are only called
> at init time, and they call functions already marked __init, so they
> should be marked in the same way. This was reported as
> 
> WARNING: vmlinux.o(.text+0x19e0b4): Section mismatch in reference from the
> function s3c2412_init_irq() to the function
> .init.text:s3c24xx_init_intc.constprop.8() The function s3c2412_init_irq()
> references
> the function __init s3c24xx_init_intc.constprop.8().
> This is often because s3c2412_init_irq lacks a __init
> annotation or the annotation of s3c24xx_init_intc.constprop.8 is wrong.
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Cc: Heiko Stuebner <heiko at sntech.de>
> Cc: Kukjin Kim <kgene.kim at samsung.com>

Yeah, it seems "someone" forgot these, thanks for catching this.

Acked-by: Heiko Stuebner <heiko at sntech.de>


> ---
>  drivers/irqchip/irq-s3c24xx.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/irqchip/irq-s3c24xx.c b/drivers/irqchip/irq-s3c24xx.c
> index c8afd7b..bbcc944 100644
> --- a/drivers/irqchip/irq-s3c24xx.c
> +++ b/drivers/irqchip/irq-s3c24xx.c
> @@ -535,7 +535,7 @@ static void s3c24xx_clear_intc(struct s3c_irq_intc
> *intc) }
>  }
> 
> -static struct s3c_irq_intc *s3c24xx_init_intc(struct device_node *np,
> +static struct s3c_irq_intc * __init s3c24xx_init_intc(struct device_node
> *np, struct s3c_irq_data *irq_data,
>  				       struct s3c_irq_intc *parent,
>  				       unsigned long address)
> @@ -795,7 +795,7 @@ static struct s3c_irq_data init_s3c2412subint[32] = {
>  	{ .type = S3C_IRQTYPE_LEVEL, .parent_irq = 21 }, /* CF */
>  };
> 
> -void s3c2412_init_irq(void)
> +void __init s3c2412_init_irq(void)
>  {
>  	pr_info("S3C2412: IRQ Support\n");



From stefano.stabellini at eu.citrix.com  Fri Apr 26 06:41:32 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Fri, 26 Apr 2013 11:41:32 +0100
Subject: [PATCH v5 0/7] xen/arm: move to mach-virt and support SMP
In-Reply-To: <alpine.DEB.2.02.1304251750160.4180@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1304251750160.4180@kaball.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1304261134330.4180@kaball.uk.xensource.com>

Arnd, Olof,
during the last few merge windows Konrad has always sent the Xen ARM
patches to Linus via his tree, but this time (3.10 merge window), after
consulting with Konrad I am thinking of sending to Linus the pull
request myself.

Arnd, are you OK with this patch series?

It's all very Xen specific and it is already in linux-next.
The only non-Xen files that are touched are arch/arm/Kconfig, to select
ARM_PSCI on XEN, and arch/arm/boot/dts/Makefile, to build the xenvm DTB
if CONFIG_ARCH_VIRT.

Cheers,

Stefano


On Thu, 25 Apr 2013, Stefano Stabellini wrote:
> Hi all,
> this patch series, based on 3.9-rc3, moves xenvm to mach-virt,
> introduces SMP support in Xen on ARM and implements machine reboot and
> power off via Xen sched_op hypercalls.
> 
> Each patch comes with a detailed changelog.
> 
> 
> The merge window is approaching, this patch series only contains Xen
> specific changes for ARM, if anybody has any objections speak now
> please.
> 
> I would like an ack from an ARM maintainer on patch #4 and #5 since they
> touch generic ARM Makefiles.
> 
> 
> Changes in v5:
> - allocate xen_vcpu_info dynamically, aligning it to the size of the
> struct;
> - use VCPUOP_register_vcpu_info on cpu0 too;
> - set pm_power_off and arm_pm_restart from the Xen specific
> intialization code.
> 
> 
> 
> Stefano Stabellini (7):
>       xen/arm: actually pass a non-NULL percpu pointer to request_percpu_irq
>       xen/arm: implement HYPERVISOR_vcpu_op
>       xen/arm: SMP support
>       xen: move the xenvm machine to mach-virt
>       xen/arm: XEN selects ARM_PSCI
>       xenvm: add a simple PSCI node and a second cpu
>       xen/arm: use sched_op hypercalls for machine reboot and power off
> 
>  arch/arm/Kconfig                     |    1 +
>  arch/arm/boot/dts/Makefile           |    4 +-
>  arch/arm/boot/dts/xenvm-4.2.dts      |   13 ++++++
>  arch/arm/include/asm/xen/hypercall.h |    1 +
>  arch/arm/mach-vexpress/v2m.c         |    1 -
>  arch/arm/mach-virt/virt.c            |    1 +
>  arch/arm/xen/enlighten.c             |   75 ++++++++++++++++++++++++++++++---
>  arch/arm/xen/hypercall.S             |    1 +
>  8 files changed, 87 insertions(+), 10 deletions(-)
> 
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/sstabellini/xen.git 3.9-rc3-smp-5-tag
> 
> Cheers,
> 
> Stefano
> 


From catalin.marinas at arm.com  Fri Apr 26 06:45:06 2013
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Fri, 26 Apr 2013 11:45:06 +0100
Subject: [PATCH v4 1/7] ARM: KVM: simplify HYP mapping population
In-Reply-To: <1365790327-2138-2-git-send-email-marc.zyngier@arm.com>
References: <1365790327-2138-1-git-send-email-marc.zyngier@arm.com>
 <1365790327-2138-2-git-send-email-marc.zyngier@arm.com>
Message-ID: <20130426104506.GD5007@localhost.cambridge.arm.com>

On Fri, Apr 12, 2013 at 07:12:01PM +0100, Marc Zyngier wrote:
> diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
> index 2f12e40..3003321 100644
> --- a/arch/arm/kvm/mmu.c
> +++ b/arch/arm/kvm/mmu.c
...
> -static int __create_hyp_mappings(void *from, void *to, unsigned long *pfn_base)
> +static int __create_hyp_mappings(pgd_t *pgdp,
> +				 unsigned long start, unsigned long end,
> +				 unsigned long pfn, pgprot_t prot)
>  {
> -	unsigned long start = (unsigned long)from;
> -	unsigned long end = (unsigned long)to;
>  	pgd_t *pgd;
>  	pud_t *pud;
>  	pmd_t *pmd;
> @@ -209,21 +181,14 @@ static int __create_hyp_mappings(void *from, void *to, unsigned long *pfn_base)
>  
>  	if (start >= end)
>  		return -EINVAL;
> -	/* Check for a valid kernel memory mapping */
> -	if (!pfn_base && (!virt_addr_valid(from) || !virt_addr_valid(to - 1)))
> -		return -EINVAL;
> -	/* Check for a valid kernel IO mapping */
> -	if (pfn_base && (!is_vmalloc_addr(from) || !is_vmalloc_addr(to - 1)))
> -		return -EINVAL;
>  
>  	mutex_lock(&kvm_hyp_pgd_mutex);
> -	for (addr = start; addr < end; addr = next) {
> -		unsigned long hyp_addr = KERN_TO_HYP(addr);
> -		pgd = hyp_pgd + pgd_index(hyp_addr);
> -		pud = pud_offset(pgd, hyp_addr);
> +	for (addr = start & PAGE_MASK; addr < end; addr = next) {
> +		pgd = pgdp + pgd_index(addr);
> +		pud = pud_offset(pgd, addr);
>  
>  		if (pud_none_or_clear_bad(pud)) {
> -			pmd = pmd_alloc_one(NULL, hyp_addr);
> +			pmd = pmd_alloc_one(NULL, addr);
>  			if (!pmd) {
>  				kvm_err("Cannot allocate Hyp pmd\n");
>  				err = -ENOMEM;
> @@ -233,9 +198,10 @@ static int __create_hyp_mappings(void *from, void *to, unsigned long *pfn_base)
>  		}
>  
>  		next = pgd_addr_end(addr, end);
> -		err = create_hyp_pmd_mappings(pud, addr, next, pfn_base);
> +		err = create_hyp_pmd_mappings(pud, addr, next, pfn, prot);

I would add another indirection function here like
create_hyp_pud_mappings() if we are to share this code with arm64. If
written correctly, the compiler should turn it into no-op. But here you
just make the assumption that pgd/pud are the same.

(it can be additional patch at some point if you already prepared these
patches for upstream)

-- 
Catalin


From tixy at linaro.org  Fri Apr 26 06:51:28 2013
From: tixy at linaro.org (Jon Medhurst (Tixy))
Date: Fri, 26 Apr 2013 11:51:28 +0100
Subject: [PATCH v2] mfd: vexpress: Handle pending config transactions
In-Reply-To: <1366910091-17971-1-git-send-email-pawel.moll@arm.com>
References: <1366821084-12815-1-git-send-email-pawel.moll@arm.com>
 <1366910091-17971-1-git-send-email-pawel.moll@arm.com>
Message-ID: <1366973488.3385.18.camel@linaro1.home>

On Thu, 2013-04-25 at 18:14 +0100, Pawel Moll wrote:
> The config transactions "scheduler" was hopelessly broken,
> repeating completed transaction instead of picking up
> next pending one.
> 
> Fixed now. Also improved debug messages.
> 
> Signed-off-by: Pawel Moll <pawel.moll at arm.com>

Yes, looks really fixed now. :-)

Reviewed-by: Jon Medhurst <tixy at linaro.org>

> ---
>  drivers/mfd/vexpress-config.c |   35 +++++++++++++++++++++--------------
>  1 file changed, 21 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/mfd/vexpress-config.c b/drivers/mfd/vexpress-config.c
> index 3c1723aa..84ce6b9 100644
> --- a/drivers/mfd/vexpress-config.c
> +++ b/drivers/mfd/vexpress-config.c
> @@ -184,13 +184,14 @@ static int vexpress_config_schedule(struct vexpress_config_trans *trans)
>  
>  	spin_lock_irqsave(&bridge->transactions_lock, flags);
>  
> -	vexpress_config_dump_trans("Executing", trans);
> -
> -	if (list_empty(&bridge->transactions))
> +	if (list_empty(&bridge->transactions)) {
> +		vexpress_config_dump_trans("Executing", trans);
>  		status = bridge->info->func_exec(trans->func->func,
>  				trans->offset, trans->write, trans->data);
> -	else
> +	} else {
> +		vexpress_config_dump_trans("Queuing", trans);
>  		status = VEXPRESS_CONFIG_STATUS_WAIT;
> +	}
>  
>  	switch (status) {
>  	case VEXPRESS_CONFIG_STATUS_DONE:
> @@ -212,25 +213,31 @@ void vexpress_config_complete(struct vexpress_config_bridge *bridge,
>  {
>  	struct vexpress_config_trans *trans;
>  	unsigned long flags;
> +	const char *message = "Completed";
>  
>  	spin_lock_irqsave(&bridge->transactions_lock, flags);
>  
>  	trans = list_first_entry(&bridge->transactions,
>  			struct vexpress_config_trans, list);
> -	vexpress_config_dump_trans("Completed", trans);
> -
>  	trans->status = status;
> -	list_del(&trans->list);
>  
> -	if (!list_empty(&bridge->transactions)) {
> -		vexpress_config_dump_trans("Pending", trans);
> +	do {
> +		vexpress_config_dump_trans(message, trans);
> +		list_del(&trans->list);
> +		complete(&trans->completion);
>  
> -		bridge->info->func_exec(trans->func->func, trans->offset,
> -				trans->write, trans->data);
> -	}
> -	spin_unlock_irqrestore(&bridge->transactions_lock, flags);
> +		if (list_empty(&bridge->transactions))
> +			break;
> +
> +		trans = list_first_entry(&bridge->transactions,
> +				struct vexpress_config_trans, list);
> +		vexpress_config_dump_trans("Executing pending", trans);
> +		trans->status = bridge->info->func_exec(trans->func->func,
> +				trans->offset, trans->write, trans->data);
> +		message = "Finished pending";
> +	} while (trans->status == VEXPRESS_CONFIG_STATUS_DONE);
>  
> -	complete(&trans->completion);
> +	spin_unlock_irqrestore(&bridge->transactions_lock, flags);
>  }
>  EXPORT_SYMBOL(vexpress_config_complete);
>  




From daniel.lezcano at linaro.org  Fri Apr 26 06:53:06 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Fri, 26 Apr 2013 12:53:06 +0200
Subject: [PATCH] cpuidle: add maintainer entry
In-Reply-To: <CACRpkdbQcxXzySH70NHMQfQXqMc72GUwvj1KQaxmnLSAbJ17rw@mail.gmail.com>
References: <1366810463-17495-1-git-send-email-daniel.lezcano@linaro.org>
 <87k3nr50n4.fsf@linaro.org>
 <CACRpkdaA8uG5jYyYTbuvzZNRr47EhWHFMLLz+jbiE3FPC1vjmA@mail.gmail.com>
 <9935265.yXMiRQV8Yo@vostro.rjw.lan>
 <CACRpkdbQcxXzySH70NHMQfQXqMc72GUwvj1KQaxmnLSAbJ17rw@mail.gmail.com>
Message-ID: <517A5C92.6040800@linaro.org>

On 04/26/2013 10:32 AM, Linus Walleij wrote:
> On Thu, Apr 25, 2013 at 8:27 PM, Rafael J. Wysocki <rjw at sisk.pl> wrote:
>> On Thursday, April 25, 2013 02:09:11 PM Linus Walleij wrote:
>>> On Wed, Apr 24, 2013 at 6:55 PM, Kevin Hilman <khilman at linaro.org> wrote:
> 
>>>> What do you think about having Daniel listed here as a co-maintainer?
>>>
>>> I second that. He will bring useful embedded knowledge to the
>>> subsystem.
>>
>> I'd still like to have a say about the core, but if Daniel is willing to
>> maintain ARM cpuidle drivers and all of the relevant ARM people agree with
>> that, that'll be great.
> 
> OK Daniel can you post a v2 adding yourself as co-maintainer as well?
> Add my Acked-by if you wish.

Sure, I can help and ensure the drivers are going to the right
direction, especially the ARM drivers. I will add also Rafael's git tree
link.

Thanks
  -- Daniel


-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From rnayak at ti.com  Fri Apr 26 06:54:51 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Fri, 26 Apr 2013 16:24:51 +0530
Subject: [PATCH v2 2/6] ARM: OMAP2+: hwmod: Add a new flag to handle SIDLE in
 SWSUP only in active
In-Reply-To: <1366973695-2088-1-git-send-email-rnayak@ti.com>
References: <1366973695-2088-1-git-send-email-rnayak@ti.com>
Message-ID: <1366973695-2088-3-git-send-email-rnayak@ti.com>

Some IPs (like UART) need the sidle mode to be controlled in SW only
while they are active. Once they go inactive, they need the IP to be
put back in HW control so they are also wakeup capable.

The flag HWMOD_SWSUP_SIDLE takes care of IPs which need the sidle
mode to be *always* controlled in SWSUP. We now have a need to control
IPs sidle mode in SWSUP only while its active.

So define a new flag 'HWMOD_SWSUP_SIDLE_ACT' to help the framework
know about these new IP requirements.

Tested-by: Vaibhav Bedia <vaibhav.bedia at ti.com>
Tested-by: Sourav Poddar <sourav.poddar at ti.com>
Signed-off-by: Rajendra Nayak <rnayak at ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
---
 arch/arm/mach-omap2/omap_hwmod.c |    3 ++-
 arch/arm/mach-omap2/omap_hwmod.h |    4 ++++
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index bf84686..fdb5bb3 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1353,7 +1353,8 @@ static void _enable_sysc(struct omap_hwmod *oh)
 
 	clkdm = _get_clkdm(oh);
 	if (sf & SYSC_HAS_SIDLEMODE) {
-		if (oh->flags & HWMOD_SWSUP_SIDLE) {
+		if (oh->flags & HWMOD_SWSUP_SIDLE ||
+		    oh->flags & HWMOD_SWSUP_SIDLE_ACT) {
 			idlemode = HWMOD_IDLEMODE_NO;
 		} else {
 			if (sf & SYSC_HAS_ENAWAKEUP)
diff --git a/arch/arm/mach-omap2/omap_hwmod.h b/arch/arm/mach-omap2/omap_hwmod.h
index 28f4dea..da6b6ce 100644
--- a/arch/arm/mach-omap2/omap_hwmod.h
+++ b/arch/arm/mach-omap2/omap_hwmod.h
@@ -459,6 +459,9 @@ struct omap_hwmod_omap4_prcm {
  *     correctly, or this is being abused to deal with some PM latency
  *     issues -- but we're currently suffering from a shortage of
  *     folks who are able to track these issues down properly.
+ * HWMOD_SWSUP_SIDLE_ACT: omap_hwmod code should manually bring the module
+ *     out of idle, but rely on smart-idle to the put it back in idle,
+ *     so the wakeups are still functional (Only known case for now is UART)
  */
 #define HWMOD_SWSUP_SIDLE			(1 << 0)
 #define HWMOD_SWSUP_MSTANDBY			(1 << 1)
@@ -471,6 +474,7 @@ struct omap_hwmod_omap4_prcm {
 #define HWMOD_16BIT_REG				(1 << 8)
 #define HWMOD_EXT_OPT_MAIN_CLK			(1 << 9)
 #define HWMOD_BLOCK_WFI				(1 << 10)
+#define HWMOD_SWSUP_SIDLE_ACT			(1 << 11)
 
 /*
  * omap_hwmod._int_flags definitions
-- 
1.7.9.5



From rnayak at ti.com  Fri Apr 26 06:54:55 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Fri, 26 Apr 2013 16:24:55 +0530
Subject: [PATCH v2 6/6] ARM: OMAP2+: hwmod: Remove sysc slave idle and auto
 idle apis
In-Reply-To: <1366973695-2088-1-git-send-email-rnayak@ti.com>
References: <1366973695-2088-1-git-send-email-rnayak@ti.com>
Message-ID: <1366973695-2088-7-git-send-email-rnayak@ti.com>

From: Santosh Shilimkar <santosh.shilimkar at ti.com>

With the OMAP serial driver sysc cleanup patches in this series, we can
now remove the hwmod external apis for sysc fiddling.

While at this, also remove unused sysc auto idle api from hwmod code.

Tested-by: Vaibhav Bedia <vaibhav.bedia at ti.com>
Tested-by: Sourav Poddar <sourav.poddar at ti.com>
Signed-off-by: Rajendra nayak <rnayak at ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
---
 arch/arm/mach-omap2/omap_hwmod.c |   68 --------------------------------------
 arch/arm/mach-omap2/omap_hwmod.h |    3 --
 2 files changed, 71 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index fdb5bb3..937e349 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -2249,42 +2249,6 @@ static int _idle(struct omap_hwmod *oh)
 }
 
 /**
- * omap_hwmod_set_ocp_autoidle - set the hwmod's OCP autoidle bit
- * @oh: struct omap_hwmod *
- * @autoidle: desired AUTOIDLE bitfield value (0 or 1)
- *
- * Sets the IP block's OCP autoidle bit in hardware, and updates our
- * local copy. Intended to be used by drivers that require
- * direct manipulation of the AUTOIDLE bits.
- * Returns -EINVAL if @oh is null or is not in the ENABLED state, or passes
- * along the return value from _set_module_autoidle().
- *
- * Any users of this function should be scrutinized carefully.
- */
-int omap_hwmod_set_ocp_autoidle(struct omap_hwmod *oh, u8 autoidle)
-{
-	u32 v;
-	int retval = 0;
-	unsigned long flags;
-
-	if (!oh || oh->_state != _HWMOD_STATE_ENABLED)
-		return -EINVAL;
-
-	spin_lock_irqsave(&oh->_lock, flags);
-
-	v = oh->_sysc_cache;
-
-	retval = _set_module_autoidle(oh, autoidle, &v);
-
-	if (!retval)
-		_write_sysconfig(v, oh);
-
-	spin_unlock_irqrestore(&oh->_lock, flags);
-
-	return retval;
-}
-
-/**
  * _shutdown - shutdown an omap_hwmod
  * @oh: struct omap_hwmod *
  *
@@ -3145,38 +3109,6 @@ error:
 }
 
 /**
- * omap_hwmod_set_slave_idlemode - set the hwmod's OCP slave idlemode
- * @oh: struct omap_hwmod *
- * @idlemode: SIDLEMODE field bits (shifted to bit 0)
- *
- * Sets the IP block's OCP slave idlemode in hardware, and updates our
- * local copy.  Intended to be used by drivers that have some erratum
- * that requires direct manipulation of the SIDLEMODE bits.  Returns
- * -EINVAL if @oh is null, or passes along the return value from
- * _set_slave_idlemode().
- *
- * XXX Does this function have any current users?  If not, we should
- * remove it; it is better to let the rest of the hwmod code handle this.
- * Any users of this function should be scrutinized carefully.
- */
-int omap_hwmod_set_slave_idlemode(struct omap_hwmod *oh, u8 idlemode)
-{
-	u32 v;
-	int retval = 0;
-
-	if (!oh)
-		return -EINVAL;
-
-	v = oh->_sysc_cache;
-
-	retval = _set_slave_idlemode(oh, idlemode, &v);
-	if (!retval)
-		_write_sysconfig(v, oh);
-
-	return retval;
-}
-
-/**
  * omap_hwmod_lookup - look up a registered omap_hwmod by name
  * @name: name of the omap_hwmod to look up
  *
diff --git a/arch/arm/mach-omap2/omap_hwmod.h b/arch/arm/mach-omap2/omap_hwmod.h
index da6b6ce..777710a 100644
--- a/arch/arm/mach-omap2/omap_hwmod.h
+++ b/arch/arm/mach-omap2/omap_hwmod.h
@@ -640,9 +640,6 @@ int omap_hwmod_read_hardreset(struct omap_hwmod *oh, const char *name);
 int omap_hwmod_enable_clocks(struct omap_hwmod *oh);
 int omap_hwmod_disable_clocks(struct omap_hwmod *oh);
 
-int omap_hwmod_set_slave_idlemode(struct omap_hwmod *oh, u8 idlemode);
-int omap_hwmod_set_ocp_autoidle(struct omap_hwmod *oh, u8 autoidle);
-
 int omap_hwmod_reset(struct omap_hwmod *oh);
 void omap_hwmod_ocp_barrier(struct omap_hwmod *oh);
 
-- 
1.7.9.5



From rnayak at ti.com  Fri Apr 26 06:54:49 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Fri, 26 Apr 2013 16:24:49 +0530
Subject: [PATCH v2 0/6] ARM;
 OMAP2+: hwmod and SERIAL: Remove sysc handling from driver
Message-ID: <1366973695-2088-1-git-send-email-rnayak@ti.com>

changes in v2:
---
1. Addressed the concerns from Paul Wamsley around cleanups in
_enable_wakeup()/_disable_wakeup(), and left them intact
2. Updates in changelogs in the serial patch about changes
needed when dma support is added back for serial
3. Dropped 1/8 from v1 since its already pulled in

The patches are based of 'fixes-non-critical' branch of
'git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap' tree
since patch 1/8 from v1 was pulled in here.

Patches can be found here:
git://github.com/rrnayak/linux.git sysc-cleanups
---

OMAP UART IP needs manual idle modes based on functional state of the
IP. Currently this is handled by the driver with function pointers
implemented in platform code.

This however breaks in case of device tree because of missing
idle handling. 

The series tries to address the issue and tries to remove complete
sysc handling from serial driver.

Patches has been tested on OMAP4430 SDP and OMAP5 EVM where the console
sluggishness was observed without idle mode handling. CPUIDLE and
suspend tested ok on these devices.

Thanks to Vaibhav Bedia for testing on Beaglebone(AM33XX) with suspend and
also the UART async wakeup from suspend.

Thanks to Sourav Poddar for Beagle XM(OMAP3630) devices testing with
retention and offmode in Idle and suspend for non-DT builds.

Serial driver platform code still has one more function pointer
left which is used to trigger io_ring(). This one needs some
discussion with pincontrol driver folks on how to implement
such a feature with generic pincontrol driver.

Rajendra Nayak (2):
  ARM: OMAP2+: hwmod: Fix sidle programming in
    _enable_sysc()/_idle_sysc()
  ARM: OMAP2+: hwmod: Add a new flag to handle SIDLE in SWSUP only in
    active

Santosh Shilimkar (4):
  ARM: OMAP2+: hwmod-data: UART IP needs software control to manage
    sidle modes
  SERIAL: OMAP: Remove the slave idle handling from the driver
  ARM: OMAP2+: serial: Remove the un-used slave idle hooks
  ARM: OMAP2+: hwmod: Remove sysc slave idle and auto idle apis

 arch/arm/mach-omap2/omap_hwmod.c                   |  111 +++++---------------
 arch/arm/mach-omap2/omap_hwmod.h                   |    7 +-
 arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c |    3 +
 arch/arm/mach-omap2/omap_hwmod_33xx_data.c         |    6 ++
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c         |    4 +
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c         |    6 +-
 arch/arm/mach-omap2/serial.c                       |   31 ------
 drivers/tty/serial/omap-serial.c                   |   23 ----
 include/linux/platform_data/serial-omap.h          |    2 -
 9 files changed, 48 insertions(+), 145 deletions(-)

-- 
1.7.9.5



From rnayak at ti.com  Fri Apr 26 06:54:52 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Fri, 26 Apr 2013 16:24:52 +0530
Subject: [PATCH v2 3/6] ARM: OMAP2+: hwmod-data: UART IP needs software
 control to manage sidle modes
In-Reply-To: <1366973695-2088-1-git-send-email-rnayak@ti.com>
References: <1366973695-2088-1-git-send-email-rnayak@ti.com>
Message-ID: <1366973695-2088-4-git-send-email-rnayak@ti.com>

From: Santosh Shilimkar <santosh.shilimkar at ti.com>

OMAP UART IP needs software control for slave idle modes based on functional
state of the IP. i.e The IP slave idle settings should be set to 'noidle' when
being used and then put back to 'smart_idle' when unused. Currently this is
handled by the driver with function pointers implemented in platform code.
This however breaks in case of device tree because of missing idle handling
APIs.

Previous patches in this series added a flag HWMOD_SWSUP_SIDLE_ACTIVE which
takes care of the mentioned requirement. Hence add the flag for all UART IPs
to take advantage of feature supported by framework.

Subsequent patches removes the slave idle handling from driver code.

Tested-by: Vaibhav Bedia <vaibhav.bedia at ti.com>
Tested-by: Sourav Poddar <sourav.poddar at ti.com>
Signed-off-by: Rajendra Nayak <rnayak at ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
---
 arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c |    3 +++
 arch/arm/mach-omap2/omap_hwmod_33xx_data.c         |    6 ++++++
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c         |    4 ++++
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c         |    6 +++++-
 4 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c b/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
index e596117..d96daed 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
@@ -512,6 +512,7 @@ struct omap_hwmod omap2xxx_uart1_hwmod = {
 	.mpu_irqs	= omap2_uart1_mpu_irqs,
 	.sdma_reqs	= omap2_uart1_sdma_reqs,
 	.main_clk	= "uart1_fck",
+	.flags		= HWMOD_SWSUP_SIDLE_ACT,
 	.prcm		= {
 		.omap2 = {
 			.module_offs = CORE_MOD,
@@ -531,6 +532,7 @@ struct omap_hwmod omap2xxx_uart2_hwmod = {
 	.mpu_irqs	= omap2_uart2_mpu_irqs,
 	.sdma_reqs	= omap2_uart2_sdma_reqs,
 	.main_clk	= "uart2_fck",
+	.flags		= HWMOD_SWSUP_SIDLE_ACT,
 	.prcm		= {
 		.omap2 = {
 			.module_offs = CORE_MOD,
@@ -550,6 +552,7 @@ struct omap_hwmod omap2xxx_uart3_hwmod = {
 	.mpu_irqs	= omap2_uart3_mpu_irqs,
 	.sdma_reqs	= omap2_uart3_sdma_reqs,
 	.main_clk	= "uart3_fck",
+	.flags		= HWMOD_SWSUP_SIDLE_ACT,
 	.prcm		= {
 		.omap2 = {
 			.module_offs = CORE_MOD,
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index 31bea1c..35fb58c 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -1969,6 +1969,7 @@ static struct omap_hwmod am33xx_uart1_hwmod = {
 	.name		= "uart1",
 	.class		= &uart_class,
 	.clkdm_name	= "l4_wkup_clkdm",
+	.flags		= HWMOD_SWSUP_SIDLE_ACT,
 	.mpu_irqs	= am33xx_uart1_irqs,
 	.sdma_reqs	= uart1_edma_reqs,
 	.main_clk	= "dpll_per_m2_div4_wkupdm_ck",
@@ -1989,6 +1990,7 @@ static struct omap_hwmod am33xx_uart2_hwmod = {
 	.name		= "uart2",
 	.class		= &uart_class,
 	.clkdm_name	= "l4ls_clkdm",
+	.flags		= HWMOD_SWSUP_SIDLE_ACT,
 	.mpu_irqs	= am33xx_uart2_irqs,
 	.sdma_reqs	= uart1_edma_reqs,
 	.main_clk	= "dpll_per_m2_div4_ck",
@@ -2016,6 +2018,7 @@ static struct omap_hwmod am33xx_uart3_hwmod = {
 	.name		= "uart3",
 	.class		= &uart_class,
 	.clkdm_name	= "l4ls_clkdm",
+	.flags		= HWMOD_SWSUP_SIDLE_ACT,
 	.mpu_irqs	= am33xx_uart3_irqs,
 	.sdma_reqs	= uart3_edma_reqs,
 	.main_clk	= "dpll_per_m2_div4_ck",
@@ -2036,6 +2039,7 @@ static struct omap_hwmod am33xx_uart4_hwmod = {
 	.name		= "uart4",
 	.class		= &uart_class,
 	.clkdm_name	= "l4ls_clkdm",
+	.flags		= HWMOD_SWSUP_SIDLE_ACT,
 	.mpu_irqs	= am33xx_uart4_irqs,
 	.sdma_reqs	= uart1_edma_reqs,
 	.main_clk	= "dpll_per_m2_div4_ck",
@@ -2056,6 +2060,7 @@ static struct omap_hwmod am33xx_uart5_hwmod = {
 	.name		= "uart5",
 	.class		= &uart_class,
 	.clkdm_name	= "l4ls_clkdm",
+	.flags		= HWMOD_SWSUP_SIDLE_ACT,
 	.mpu_irqs	= am33xx_uart5_irqs,
 	.sdma_reqs	= uart1_edma_reqs,
 	.main_clk	= "dpll_per_m2_div4_ck",
@@ -2076,6 +2081,7 @@ static struct omap_hwmod am33xx_uart6_hwmod = {
 	.name		= "uart6",
 	.class		= &uart_class,
 	.clkdm_name	= "l4ls_clkdm",
+	.flags		= HWMOD_SWSUP_SIDLE_ACT,
 	.mpu_irqs	= am33xx_uart6_irqs,
 	.sdma_reqs	= uart1_edma_reqs,
 	.main_clk	= "dpll_per_m2_div4_ck",
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index ac7e03e..f4858d1 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -490,6 +490,7 @@ static struct omap_hwmod omap3xxx_uart1_hwmod = {
 	.mpu_irqs	= omap2_uart1_mpu_irqs,
 	.sdma_reqs	= omap2_uart1_sdma_reqs,
 	.main_clk	= "uart1_fck",
+	.flags		= HWMOD_SWSUP_SIDLE_ACT,
 	.prcm		= {
 		.omap2 = {
 			.module_offs = CORE_MOD,
@@ -508,6 +509,7 @@ static struct omap_hwmod omap3xxx_uart2_hwmod = {
 	.mpu_irqs	= omap2_uart2_mpu_irqs,
 	.sdma_reqs	= omap2_uart2_sdma_reqs,
 	.main_clk	= "uart2_fck",
+	.flags		= HWMOD_SWSUP_SIDLE_ACT,
 	.prcm		= {
 		.omap2 = {
 			.module_offs = CORE_MOD,
@@ -526,6 +528,7 @@ static struct omap_hwmod omap3xxx_uart3_hwmod = {
 	.mpu_irqs	= omap2_uart3_mpu_irqs,
 	.sdma_reqs	= omap2_uart3_sdma_reqs,
 	.main_clk	= "uart3_fck",
+	.flags		= HWMOD_SWSUP_SIDLE_ACT,
 	.prcm		= {
 		.omap2 = {
 			.module_offs = OMAP3430_PER_MOD,
@@ -555,6 +558,7 @@ static struct omap_hwmod omap36xx_uart4_hwmod = {
 	.mpu_irqs	= uart4_mpu_irqs,
 	.sdma_reqs	= uart4_sdma_reqs,
 	.main_clk	= "uart4_fck",
+	.flags		= HWMOD_SWSUP_SIDLE_ACT,
 	.prcm		= {
 		.omap2 = {
 			.module_offs = OMAP3430_PER_MOD,
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 0e47d2e..f81e976 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -3424,6 +3424,7 @@ static struct omap_hwmod omap44xx_uart1_hwmod = {
 	.name		= "uart1",
 	.class		= &omap44xx_uart_hwmod_class,
 	.clkdm_name	= "l4_per_clkdm",
+	.flags		= HWMOD_SWSUP_SIDLE_ACT,
 	.mpu_irqs	= omap44xx_uart1_irqs,
 	.sdma_reqs	= omap44xx_uart1_sdma_reqs,
 	.main_clk	= "func_48m_fclk",
@@ -3452,6 +3453,7 @@ static struct omap_hwmod omap44xx_uart2_hwmod = {
 	.name		= "uart2",
 	.class		= &omap44xx_uart_hwmod_class,
 	.clkdm_name	= "l4_per_clkdm",
+	.flags		= HWMOD_SWSUP_SIDLE_ACT,
 	.mpu_irqs	= omap44xx_uart2_irqs,
 	.sdma_reqs	= omap44xx_uart2_sdma_reqs,
 	.main_clk	= "func_48m_fclk",
@@ -3480,7 +3482,8 @@ static struct omap_hwmod omap44xx_uart3_hwmod = {
 	.name		= "uart3",
 	.class		= &omap44xx_uart_hwmod_class,
 	.clkdm_name	= "l4_per_clkdm",
-	.flags		= HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET,
+	.flags		= HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET |
+				HWMOD_SWSUP_SIDLE_ACT,
 	.mpu_irqs	= omap44xx_uart3_irqs,
 	.sdma_reqs	= omap44xx_uart3_sdma_reqs,
 	.main_clk	= "func_48m_fclk",
@@ -3509,6 +3512,7 @@ static struct omap_hwmod omap44xx_uart4_hwmod = {
 	.name		= "uart4",
 	.class		= &omap44xx_uart_hwmod_class,
 	.clkdm_name	= "l4_per_clkdm",
+	.flags		= HWMOD_SWSUP_SIDLE_ACT,
 	.mpu_irqs	= omap44xx_uart4_irqs,
 	.sdma_reqs	= omap44xx_uart4_sdma_reqs,
 	.main_clk	= "func_48m_fclk",
-- 
1.7.9.5



From rnayak at ti.com  Fri Apr 26 06:54:50 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Fri, 26 Apr 2013 16:24:50 +0530
Subject: [PATCH v2 1/6] ARM: OMAP2+: hwmod: Fix sidle programming in
 _enable_sysc()/_idle_sysc()
In-Reply-To: <1366973695-2088-1-git-send-email-rnayak@ti.com>
References: <1366973695-2088-1-git-send-email-rnayak@ti.com>
Message-ID: <1366973695-2088-2-git-send-email-rnayak@ti.com>

_enable_sysc() and _idle_sysc() handle the midle mode programming correctly
and program HWMOD_IDLEMODE_SMART or HWMOD_IDLEMODE_SMART_WKUP respectively
for supported IPs (The ones which support hardware controlled midle modes)

However the same programming logic is missing when it comes to sidle mode
programming. Here they seem to just set HWMOD_IDLEMODE_SMART (Again for the
ones which support hardware controlled sidle modes)

This problem was hidden due to the fact that a call to _enable_wakeup()
in those same functions would overwrite the idlemodes and program them
correctly (to HWMOD_IDLEMODE_SMART_WKUP in the supported cases)

So fix the sidlemode handling correctly in these functions and handle the
_enable_wakeup() for SIDLEMODE supported IPs same as the way its handled
for MIDLEMODE supported ones.

Tested-by: Vaibhav Bedia <vaibhav.bedia at ti.com>
Tested-by: Sourav Poddar <sourav.poddar at ti.com>
Signed-off-by: Rajendra Nayak <rnayak at ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
---
 arch/arm/mach-omap2/omap_hwmod.c |   42 +++++++++++++++++++++++---------------
 1 file changed, 25 insertions(+), 17 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index e5cafed..bf84686 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1353,13 +1353,26 @@ static void _enable_sysc(struct omap_hwmod *oh)
 
 	clkdm = _get_clkdm(oh);
 	if (sf & SYSC_HAS_SIDLEMODE) {
+		if (oh->flags & HWMOD_SWSUP_SIDLE) {
+			idlemode = HWMOD_IDLEMODE_NO;
+		} else {
+			if (sf & SYSC_HAS_ENAWAKEUP)
+				_enable_wakeup(oh, &v);
+			if (oh->class->sysc->idlemodes & SIDLE_SMART_WKUP)
+				idlemode = HWMOD_IDLEMODE_SMART_WKUP;
+			else
+				idlemode = HWMOD_IDLEMODE_SMART;
+		}
+
+		/*
+		 * This is special handling for some IPs like
+		 * 32k sync timer. Force them to idle!
+		 */
 		clkdm_act = (clkdm && clkdm->flags & CLKDM_ACTIVE_WITH_MPU);
 		if (clkdm_act && !(oh->class->sysc->idlemodes &
 				   (SIDLE_SMART | SIDLE_SMART_WKUP)))
 			idlemode = HWMOD_IDLEMODE_FORCE;
-		else
-			idlemode = (oh->flags & HWMOD_SWSUP_SIDLE) ?
-				HWMOD_IDLEMODE_NO : HWMOD_IDLEMODE_SMART;
+
 		_set_slave_idlemode(oh, idlemode, &v);
 	}
 
@@ -1386,10 +1399,6 @@ static void _enable_sysc(struct omap_hwmod *oh)
 	    (sf & SYSC_HAS_CLOCKACTIVITY))
 		_set_clockactivity(oh, oh->class->sysc->clockact, &v);
 
-	/* If slave is in SMARTIDLE, also enable wakeup */
-	if ((sf & SYSC_HAS_SIDLEMODE) && !(oh->flags & HWMOD_SWSUP_SIDLE))
-		_enable_wakeup(oh, &v);
-
 	_write_sysconfig(v, oh);
 
 	/*
@@ -1425,13 +1434,16 @@ static void _idle_sysc(struct omap_hwmod *oh)
 	sf = oh->class->sysc->sysc_flags;
 
 	if (sf & SYSC_HAS_SIDLEMODE) {
-		/* XXX What about HWMOD_IDLEMODE_SMART_WKUP? */
-		if (oh->flags & HWMOD_SWSUP_SIDLE ||
-		    !(oh->class->sysc->idlemodes &
-		      (SIDLE_SMART | SIDLE_SMART_WKUP)))
+		if (oh->flags & HWMOD_SWSUP_SIDLE) {
 			idlemode = HWMOD_IDLEMODE_FORCE;
-		else
-			idlemode = HWMOD_IDLEMODE_SMART;
+		} else {
+			if (sf & SYSC_HAS_ENAWAKEUP)
+				_enable_wakeup(oh, &v);
+			if (oh->class->sysc->idlemodes & SIDLE_SMART_WKUP)
+				idlemode = HWMOD_IDLEMODE_SMART_WKUP;
+			else
+				idlemode = HWMOD_IDLEMODE_SMART;
+		}
 		_set_slave_idlemode(oh, idlemode, &v);
 	}
 
@@ -1449,10 +1461,6 @@ static void _idle_sysc(struct omap_hwmod *oh)
 		_set_master_standbymode(oh, idlemode, &v);
 	}
 
-	/* If slave is in SMARTIDLE, also enable wakeup */
-	if ((sf & SYSC_HAS_SIDLEMODE) && !(oh->flags & HWMOD_SWSUP_SIDLE))
-		_enable_wakeup(oh, &v);
-
 	_write_sysconfig(v, oh);
 }
 
-- 
1.7.9.5



From rnayak at ti.com  Fri Apr 26 06:54:54 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Fri, 26 Apr 2013 16:24:54 +0530
Subject: [PATCH v2 5/6] ARM: OMAP2+: serial: Remove the un-used slave idle
 hooks
In-Reply-To: <1366973695-2088-1-git-send-email-rnayak@ti.com>
References: <1366973695-2088-1-git-send-email-rnayak@ti.com>
Message-ID: <1366973695-2088-6-git-send-email-rnayak@ti.com>

From: Santosh Shilimkar <santosh.shilimkar at ti.com>

UART IP idle handling now taken care by runtime pm backend(hwmod) indirectly
and OMAP serial driver is also cleaned up accordingly.

So remove the un-used slave idle platforms hooks now.

Tested-by: Vaibhav Bedia <vaibhav.bedia at ti.com>
Tested-by: Sourav Poddar <sourav.poddar at ti.com>
Signed-off-by: Rajendra nayak <rnayak at ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
---
 arch/arm/mach-omap2/serial.c |   31 -------------------------------
 1 file changed, 31 deletions(-)

diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 8396b5b..f660156 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -95,38 +95,9 @@ static void omap_uart_enable_wakeup(struct device *dev, bool enable)
 		omap_hwmod_disable_wakeup(od->hwmods[0]);
 }
 
-/*
- * Errata i291: [UART]:Cannot Acknowledge Idle Requests
- * in Smartidle Mode When Configured for DMA Operations.
- * WA: configure uart in force idle mode.
- */
-static void omap_uart_set_noidle(struct device *dev)
-{
-	struct platform_device *pdev = to_platform_device(dev);
-	struct omap_device *od = to_omap_device(pdev);
-
-	omap_hwmod_set_slave_idlemode(od->hwmods[0], HWMOD_IDLEMODE_NO);
-}
-
-static void omap_uart_set_smartidle(struct device *dev)
-{
-	struct platform_device *pdev = to_platform_device(dev);
-	struct omap_device *od = to_omap_device(pdev);
-	u8 idlemode;
-
-	if (od->hwmods[0]->class->sysc->idlemodes & SIDLE_SMART_WKUP)
-		idlemode = HWMOD_IDLEMODE_SMART_WKUP;
-	else
-		idlemode = HWMOD_IDLEMODE_SMART;
-
-	omap_hwmod_set_slave_idlemode(od->hwmods[0], idlemode);
-}
-
 #else
 static void omap_uart_enable_wakeup(struct device *dev, bool enable)
 {}
-static void omap_uart_set_noidle(struct device *dev) {}
-static void omap_uart_set_smartidle(struct device *dev) {}
 #endif /* CONFIG_PM */
 
 #ifdef CONFIG_OMAP_MUX
@@ -299,8 +270,6 @@ void __init omap_serial_init_port(struct omap_board_data *bdata,
 	omap_up.uartclk = OMAP24XX_BASE_BAUD * 16;
 	omap_up.flags = UPF_BOOT_AUTOCONF;
 	omap_up.get_context_loss_count = omap_pm_get_dev_context_loss_count;
-	omap_up.set_forceidle = omap_uart_set_smartidle;
-	omap_up.set_noidle = omap_uart_set_noidle;
 	omap_up.enable_wakeup = omap_uart_enable_wakeup;
 	omap_up.dma_rx_buf_size = info->dma_rx_buf_size;
 	omap_up.dma_rx_timeout = info->dma_rx_timeout;
-- 
1.7.9.5



From rnayak at ti.com  Fri Apr 26 06:54:53 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Fri, 26 Apr 2013 16:24:53 +0530
Subject: [PATCH v2 4/6] SERIAL: OMAP: Remove the slave idle handling from the
 driver
In-Reply-To: <1366973695-2088-1-git-send-email-rnayak@ti.com>
References: <1366973695-2088-1-git-send-email-rnayak@ti.com>
Message-ID: <1366973695-2088-5-git-send-email-rnayak@ti.com>

From: Santosh Shilimkar <santosh.shilimkar at ti.com>

UART IP slave idle handling now taken care by runtime pm backend(hwmod layer)
so remove the hackery from the driver.

As discussed on the list, in future if dma mode needs to be brought
back to this driver, UART sysc handling needs to be updated in
framework such a way that no-idle/force idle profile can be supported.
Given the broken dma mode for OMAP uarts, its very unlikely.

Acked-by: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
Tested-by: Vaibhav Bedia <vaibhav.bedia at ti.com>
Tested-by: Sourav Poddar <sourav.poddar at ti.com>
Signed-off-by: Rajendra nayak <rnayak at ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
---
 drivers/tty/serial/omap-serial.c          |   23 -----------------------
 include/linux/platform_data/serial-omap.h |    2 --
 2 files changed, 25 deletions(-)

diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 4dc4140..08332f3 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -202,26 +202,6 @@ static int serial_omap_get_context_loss_count(struct uart_omap_port *up)
 	return pdata->get_context_loss_count(up->dev);
 }
 
-static void serial_omap_set_forceidle(struct uart_omap_port *up)
-{
-	struct omap_uart_port_info *pdata = up->dev->platform_data;
-
-	if (!pdata || !pdata->set_forceidle)
-		return;
-
-	pdata->set_forceidle(up->dev);
-}
-
-static void serial_omap_set_noidle(struct uart_omap_port *up)
-{
-	struct omap_uart_port_info *pdata = up->dev->platform_data;
-
-	if (!pdata || !pdata->set_noidle)
-		return;
-
-	pdata->set_noidle(up->dev);
-}
-
 static void serial_omap_enable_wakeup(struct uart_omap_port *up, bool enable)
 {
 	struct omap_uart_port_info *pdata = up->dev->platform_data;
@@ -298,8 +278,6 @@ static void serial_omap_stop_tx(struct uart_port *port)
 		serial_out(up, UART_IER, up->ier);
 	}
 
-	serial_omap_set_forceidle(up);
-
 	pm_runtime_mark_last_busy(up->dev);
 	pm_runtime_put_autosuspend(up->dev);
 }
@@ -364,7 +342,6 @@ static void serial_omap_start_tx(struct uart_port *port)
 
 	pm_runtime_get_sync(up->dev);
 	serial_omap_enable_ier_thri(up);
-	serial_omap_set_noidle(up);
 	pm_runtime_mark_last_busy(up->dev);
 	pm_runtime_put_autosuspend(up->dev);
 }
diff --git a/include/linux/platform_data/serial-omap.h b/include/linux/platform_data/serial-omap.h
index ff9b0aa..c860c1b 100644
--- a/include/linux/platform_data/serial-omap.h
+++ b/include/linux/platform_data/serial-omap.h
@@ -43,8 +43,6 @@ struct omap_uart_port_info {
 	int			DTR_present;
 
 	int (*get_context_loss_count)(struct device *);
-	void (*set_forceidle)(struct device *);
-	void (*set_noidle)(struct device *);
 	void (*enable_wakeup)(struct device *, bool);
 };
 
-- 
1.7.9.5



From peterz at infradead.org  Fri Apr 26 06:54:31 2013
From: peterz at infradead.org (Peter Zijlstra)
Date: Fri, 26 Apr 2013 12:54:31 +0200
Subject: [RFC PATCH v3 5/6] sched: pack the idle load balance
In-Reply-To: <5176A932.5050506@linux.intel.com>
References: <1363955155-18382-1-git-send-email-vincent.guittot@linaro.org>
 <1363955155-18382-6-git-send-email-vincent.guittot@linaro.org>
 <1364302359.5053.21.camel@laptop>
 <CAKfTPtD=_oS5gJeynUG=ft-Y1zEdxZEMhUPH9hSXx+H2pi4xgA@mail.gmail.com>
 <1364308932.5053.46.camel@laptop>
 <CAKfTPtArtgkH5MU_xFAKjLDS-i32g2qQMdvyW=LLkG84tH8Hhg@mail.gmail.com>
 <5174CE96.3060805@linux.vnet.ibm.com>
 <CAKfTPtCCCifC=c+xjjnAH_HSqkR80PiQoddQKXPHuZwZawbvcA@mail.gmail.com>
 <5175F09E.1000304@intel.com> <5176A932.5050506@linux.intel.com>
Message-ID: <20130426105431.GF8669@dyad.programming.kicks-ass.net>

On Tue, Apr 23, 2013 at 08:30:58AM -0700, Arjan van de Ven wrote:
> For x86 we should not be setting such flag then; we don't have a way for some cpu packages to
> go to an extra deep power state if they're completely idle.
> (this afaik is true for both Intel and AMD)

You say 'some'; this implies we do for others, right?

We can dynamically set the required flags in the arch setup when it makes sense.


From marc.zyngier at arm.com  Fri Apr 26 06:59:02 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Fri, 26 Apr 2013 11:59:02 +0100
Subject: [PATCH v4 1/7] ARM: KVM: simplify HYP mapping population
In-Reply-To: <20130426104506.GD5007@localhost.cambridge.arm.com>
References: <1365790327-2138-1-git-send-email-marc.zyngier@arm.com>
 <1365790327-2138-2-git-send-email-marc.zyngier@arm.com>
 <20130426104506.GD5007@localhost.cambridge.arm.com>
Message-ID: <517A5DF6.1070009@arm.com>

On 26/04/13 11:45, Catalin Marinas wrote:
> On Fri, Apr 12, 2013 at 07:12:01PM +0100, Marc Zyngier wrote:
>> diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
>> index 2f12e40..3003321 100644
>> --- a/arch/arm/kvm/mmu.c
>> +++ b/arch/arm/kvm/mmu.c
> ...
>> -static int __create_hyp_mappings(void *from, void *to, unsigned long *pfn_base)
>> +static int __create_hyp_mappings(pgd_t *pgdp,
>> +				 unsigned long start, unsigned long end,
>> +				 unsigned long pfn, pgprot_t prot)
>>  {
>> -	unsigned long start = (unsigned long)from;
>> -	unsigned long end = (unsigned long)to;
>>  	pgd_t *pgd;
>>  	pud_t *pud;
>>  	pmd_t *pmd;
>> @@ -209,21 +181,14 @@ static int __create_hyp_mappings(void *from, void *to, unsigned long *pfn_base)
>>  
>>  	if (start >= end)
>>  		return -EINVAL;
>> -	/* Check for a valid kernel memory mapping */
>> -	if (!pfn_base && (!virt_addr_valid(from) || !virt_addr_valid(to - 1)))
>> -		return -EINVAL;
>> -	/* Check for a valid kernel IO mapping */
>> -	if (pfn_base && (!is_vmalloc_addr(from) || !is_vmalloc_addr(to - 1)))
>> -		return -EINVAL;
>>  
>>  	mutex_lock(&kvm_hyp_pgd_mutex);
>> -	for (addr = start; addr < end; addr = next) {
>> -		unsigned long hyp_addr = KERN_TO_HYP(addr);
>> -		pgd = hyp_pgd + pgd_index(hyp_addr);
>> -		pud = pud_offset(pgd, hyp_addr);
>> +	for (addr = start & PAGE_MASK; addr < end; addr = next) {
>> +		pgd = pgdp + pgd_index(addr);
>> +		pud = pud_offset(pgd, addr);
>>  
>>  		if (pud_none_or_clear_bad(pud)) {
>> -			pmd = pmd_alloc_one(NULL, hyp_addr);
>> +			pmd = pmd_alloc_one(NULL, addr);
>>  			if (!pmd) {
>>  				kvm_err("Cannot allocate Hyp pmd\n");
>>  				err = -ENOMEM;
>> @@ -233,9 +198,10 @@ static int __create_hyp_mappings(void *from, void *to, unsigned long *pfn_base)
>>  		}
>>  
>>  		next = pgd_addr_end(addr, end);
>> -		err = create_hyp_pmd_mappings(pud, addr, next, pfn_base);
>> +		err = create_hyp_pmd_mappings(pud, addr, next, pfn, prot);
> 
> I would add another indirection function here like
> create_hyp_pud_mappings() if we are to share this code with arm64. If
> written correctly, the compiler should turn it into no-op. But here you
> just make the assumption that pgd/pud are the same.

Yes, it is a problem that is present across most of KVM/arm[64]. In
general, the code assumes that PUD is folded into PGD.

0> (it can be additional patch at some point if you already prepared these
> patches for upstream)

It is my intention to have an additional patch series that adds proper
PUD handling, so we could properly support 4 level page tables without
any other change.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...



From coelho at ti.com  Fri Apr 26 07:00:32 2013
From: coelho at ti.com (Luciano Coelho)
Date: Fri, 26 Apr 2013 14:00:32 +0300
Subject: [PATCH 1/3] ARM: OMAP2+: Legacy support for wl12xx when booted
 with devicetree
In-Reply-To: <0104F687-1726-476D-B2DF-7E72223B127A@dominion.thruhere.net>
References: <20130426034858.26065.65118.stgit@muffinssi.local>
 <20130426035210.26065.39995.stgit@muffinssi.local>
 <0104F687-1726-476D-B2DF-7E72223B127A@dominion.thruhere.net>
Message-ID: <1366974032.4029.31.camel@cumari.coelho.fi>

Hi Koen,

On Fri, 2013-04-26 at 11:33 +0200, Koen Kooi wrote:
> Op 26 apr. 2013, om 05:52 heeft Tony Lindgren <tony at atomide.com> het volgende geschreven:
> 
> > Without WLAN we cannot switch omap4 to use device tree
> > only booting. This patch can be reverted when the
> > binding for wl12xx is added.
> 
> How much boards am I allowed to add to this? I need to get the wl12xx wifi expansionboards for beagleboard, beagleboard xM and beaglebone working with DT :)

Do you know where I can get a wl12xx wifi expansion board for
beaglebone?

-- 
Luca.



From daniel.lezcano at linaro.org  Fri Apr 26 07:05:44 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Fri, 26 Apr 2013 13:05:44 +0200
Subject: [V2 PATCH] cpuidle: add maintainer entry
Message-ID: <1366974344-26064-1-git-send-email-daniel.lezcano@linaro.org>

Currently the cpuidle drivers are spread across the different archs.

The patch submission for cpuidle are following different path: the cpuidle core
code goes to linux-pm, the ARM drivers goes to arm-soc or the SoC specific
tree, sh goes through sh arch tree, pseries goes through PowerPC and
finally intel goes through Len's tree while acpi_idle goes under linux-pm.

That makes difficult to consolidate the code and to propagate modifications
from the cpuidle core to the different drivers.

Hopefully, a movement has initiated to put the cpuidle drivers into the
drivers/cpuidle directory like cpuidle-calxeda.c and cpuidle-kirkwood.c

Add an explicit maintainer entry in the MAINTAINER to clarify the situation
and prevent new cpuidle drivers to goes to an arch directory.

The upstreaming process is unchanged: Rafael takes the patches to merge them
into its tree but with the acked-by from the driver's maintainer. So the header
must contains the name of the maintainer.

This organization will be the same than cpufreq.

Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
Acked-by: Linus Walleij <linus.walleij at linaro.org>
Acked-by: Andrew Lunn <andrew at lunn.ch>  #for kirkwood
Acked-by: Jason Cooper <jason at lakedaemon.net> #for kirkwood
---
 MAINTAINERS                        |    9 +++++++++
 drivers/cpuidle/cpuidle-calxeda.c  |    4 +++-
 drivers/cpuidle/cpuidle-kirkwood.c |    5 +++--
 3 files changed, 15 insertions(+), 3 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 61677c3..45ee6dc 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2217,6 +2217,15 @@ F:	drivers/cpufreq/arm_big_little.h
 F:	drivers/cpufreq/arm_big_little.c
 F:	drivers/cpufreq/arm_big_little_dt.c
 
+CPUIDLE DRIVERS
+M:	Rafael J. Wysocki <rjw at sisk.pl>
+M:	Daniel Lezcano <daniel.lezcano at linaro.org>
+L:	linux-pm at vger.kernel.org
+S:	Maintained
+T:	git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git
+F:	drivers/cpuidle/*
+F:	include/linux/cpuidle.h
+
 CPUID/MSR DRIVER
 M:	"H. Peter Anvin" <hpa at zytor.com>
 S:	Maintained
diff --git a/drivers/cpuidle/cpuidle-calxeda.c b/drivers/cpuidle/cpuidle-calxeda.c
index e344b56..2233791 100644
--- a/drivers/cpuidle/cpuidle-calxeda.c
+++ b/drivers/cpuidle/cpuidle-calxeda.c
@@ -1,7 +1,7 @@
 /*
  * Copyright 2012 Calxeda, Inc.
  *
- * Based on arch/arm/plat-mxc/cpuidle.c:
+ * Based on arch/arm/plat-mxc/cpuidle.c: #v3.7
  * Copyright 2012 Freescale Semiconductor, Inc.
  * Copyright 2012 Linaro Ltd.
  *
@@ -16,6 +16,8 @@
  *
  * You should have received a copy of the GNU General Public License along with
  * this program.  If not, see <http://www.gnu.org/licenses/>.
+ *
+ * Maintainer: Rob Herring <rob.herring at calxeda.com>
  */
 
 #include <linux/cpuidle.h>
diff --git a/drivers/cpuidle/cpuidle-kirkwood.c b/drivers/cpuidle/cpuidle-kirkwood.c
index 53290e1..521b0a7 100644
--- a/drivers/cpuidle/cpuidle-kirkwood.c
+++ b/drivers/cpuidle/cpuidle-kirkwood.c
@@ -1,6 +1,4 @@
 /*
- * arch/arm/mach-kirkwood/cpuidle.c
- *
  * CPU idle Marvell Kirkwood SoCs
  *
  * This file is licensed under the terms of the GNU General Public
@@ -11,6 +9,9 @@
  * to implement two idle states -
  * #1 wait-for-interrupt
  * #2 wait-for-interrupt and DDR self refresh
+ *
+ * Maintainer: Jason Cooper <jason at lakedaemon.net>
+ * Maintainer: Andrew Lunn <andrew at lunn.ch>
  */
 
 #include <linux/kernel.h>
-- 
1.7.9.5



From pranavkumar at linaro.org  Fri Apr 26 07:04:54 2013
From: pranavkumar at linaro.org (Pranavkumar Sawargaonkar)
Date: Fri, 26 Apr 2013 16:34:54 +0530
Subject: [PATCH 0/2] Early printk support for virtio console devices.
Message-ID: <1366974299-17877-1-git-send-email-pranavkumar@linaro.org>

This patch-set implements early printk support for virtio console devices without using any hypercalls.

The current virtio early printk code in kernel expects that hypervisor will provide some mechanism generally a hypercall to support early printk. This patch-set does not break existing hypercall based early print support.

This implementation adds:
1. Early writeonly register named early_wr in virtio console's config space.
2. Host feature flags namely VIRTIO_CONSOLE_F_EARLY_WRITE for telling guest about early-write capability in console device.

Early write mechanism:
1. When a guest wants to out some character, it has to simply write the character to early_wr register in config space of virtio console device.

Pranavkumar Sawargaonkar (2):
  virtio: console: Add early writeonly register to config space
  arm64: earlyprintk support for virtio-mmio console

 Documentation/virtual/virtio-spec.txt |   13 ++++++++++--
 arch/arm64/kernel/early_printk.c      |   35 +++++++++++++++++++++++++++++++++
 include/uapi/linux/virtio_console.h   |    3 +++
 3 files changed, 49 insertions(+), 2 deletions(-)

-- 
1.7.9.5



From catalin.marinas at arm.com  Fri Apr 26 07:05:58 2013
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Fri, 26 Apr 2013 12:05:58 +0100
Subject: [PATCH v4 5/7] ARM: KVM: rework HYP page table freeing
In-Reply-To: <1365790327-2138-6-git-send-email-marc.zyngier@arm.com>
References: <1365790327-2138-1-git-send-email-marc.zyngier@arm.com>
 <1365790327-2138-6-git-send-email-marc.zyngier@arm.com>
Message-ID: <20130426110558.GE5007@localhost.cambridge.arm.com>

On Fri, Apr 12, 2013 at 07:12:05PM +0100, Marc Zyngier wrote:
> diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
> index bfc5927..7464824 100644
> --- a/arch/arm/kvm/mmu.c
> +++ b/arch/arm/kvm/mmu.c
...
> +static void clear_pmd_entry(pmd_t *pmd)
> +{
> +	pte_t *pte_table = pte_offset_kernel(pmd, 0);
> +	pmd_clear(pmd);
> +	pte_free_kernel(NULL, pte_table);
> +	put_page(virt_to_page(pmd));
> +}
...
>  static void unmap_stage2_range(struct kvm *kvm, phys_addr_t start, u64 size)

Is there a chance that this function (or the other unmapping function
for Hyp pages) is called on an active stage 2 table (VTTBR pointing to
this pgd)? If yes, than you probably have to follow the mmu_gather
mechanism of freeing page table pages to avoid speculative loads.
Basically flushing the TLB between pmd_clear and pte_free_kernel.

-- 
Catalin


From pranavkumar at linaro.org  Fri Apr 26 07:04:55 2013
From: pranavkumar at linaro.org (Pranavkumar Sawargaonkar)
Date: Fri, 26 Apr 2013 16:34:55 +0530
Subject: [PATCH 1/2] virtio: console: Add early writeonly register to config
 space
In-Reply-To: <1366974299-17877-1-git-send-email-pranavkumar@linaro.org>
References: <1366974299-17877-1-git-send-email-pranavkumar@linaro.org>
Message-ID: <1366974299-17877-2-git-send-email-pranavkumar@linaro.org>

This patch adds a early_wr register (writeonly) in config space of virtio console device which can be used for debugging.

The patch also updates virtio-spec in Documentation to reflect this feature addition in virtio console.

Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar at linaro.org>
Signed-off-by: Anup Patel <anup.patel at linaro.org>
---
 Documentation/virtual/virtio-spec.txt |   13 +++++++++++--
 include/uapi/linux/virtio_console.h   |    3 +++
 2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/Documentation/virtual/virtio-spec.txt b/Documentation/virtual/virtio-spec.txt
index 0d6ec85..bc4e8b5 100644
--- a/Documentation/virtual/virtio-spec.txt
+++ b/Documentation/virtual/virtio-spec.txt
@@ -1927,11 +1927,18 @@ Ports 2 onwards only if VIRTIO_CONSOLE_F_MULTIPORT is set
     ports; configuration fields nr_ports and max_nr_ports are
     valid and control virtqueues will be used.
 
+  VIRTIO_CONSOLE_F_EARLY_WRITE(2) Device has support for early
+  write. Configuration field early_wr is valid.
+
   Device configuration layout The size of the console is supplied
   in the configuration space if the VIRTIO_CONSOLE_F_SIZE feature
   is set. Furthermore, if the VIRTIO_CONSOLE_F_MULTIPORT feature
   is set, the maximum number of ports supported by the device can
-  be fetched.struct virtio_console_config {
+  be fetched. If VIRTIO_CONSOLE_F_EARLY_WRITE is set then one can
+  use early write to output single character without initializing
+  virtio queues.
+
+  struct virtio_console_config {
 
 	u16 cols;
 
@@ -1941,7 +1948,9 @@ Ports 2 onwards only if VIRTIO_CONSOLE_F_MULTIPORT is set
 
 	u32 max_nr_ports;
 
-};
+	u32 early_wr;
+
+  };
 
   Device Initialization
 
diff --git a/include/uapi/linux/virtio_console.h b/include/uapi/linux/virtio_console.h
index ee13ab6..7cd84b5 100644
--- a/include/uapi/linux/virtio_console.h
+++ b/include/uapi/linux/virtio_console.h
@@ -38,6 +38,7 @@
 /* Feature bits */
 #define VIRTIO_CONSOLE_F_SIZE	0	/* Does host provide console size? */
 #define VIRTIO_CONSOLE_F_MULTIPORT 1	/* Does host provide multiple ports? */
+#define VIRTIO_CONSOLE_F_EARLY_WRITE 2	/* Does host support early write? */
 
 #define VIRTIO_CONSOLE_BAD_ID		(~(u32)0)
 
@@ -48,6 +49,8 @@ struct virtio_console_config {
 	__u16 rows;
 	/* max. number of ports this device can hold */
 	__u32 max_nr_ports;
+	/* early write register */
+	__u32 early_wr;
 } __attribute__((packed));
 
 /*
-- 
1.7.9.5



From pranavkumar at linaro.org  Fri Apr 26 07:04:56 2013
From: pranavkumar at linaro.org (Pranavkumar Sawargaonkar)
Date: Fri, 26 Apr 2013 16:34:56 +0530
Subject: [PATCH 2/2] arm64: earlyprintk support for virtio-mmio console
In-Reply-To: <1366974299-17877-1-git-send-email-pranavkumar@linaro.org>
References: <1366974299-17877-1-git-send-email-pranavkumar@linaro.org>
Message-ID: <1366974299-17877-3-git-send-email-pranavkumar@linaro.org>

This patch implements earlyprintk based on virtio console using early_wr config register.

Kernel args for using this will be: earlyprintk=virtio-console,<phys_address>

Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar at linaro.org>
Signed-off-by: Anup Patel <anup.patel at linaro.org>
---
 arch/arm64/kernel/early_printk.c |   35 +++++++++++++++++++++++++++++++++++
 1 file changed, 35 insertions(+)

diff --git a/arch/arm64/kernel/early_printk.c b/arch/arm64/kernel/early_printk.c
index ac974f4..52ac6b0 100644
--- a/arch/arm64/kernel/early_printk.c
+++ b/arch/arm64/kernel/early_printk.c
@@ -25,6 +25,9 @@
 
 #include <linux/amba/serial.h>
 #include <linux/serial_reg.h>
+#include <linux/virtio_ids.h>
+#include <linux/virtio_mmio.h>
+#include <linux/virtio_console.h>
 
 static void __iomem *early_base;
 static void (*printch)(char ch);
@@ -53,6 +56,37 @@ static void smh_printch(char ch)
 }
 
 /*
+ * VIRTIO MMIO console single character Tx.
+ */
+static void virtio_console_printch(char ch)
+{
+	u32 tmp;
+	static u32 init_done;
+	static u32 can_write;
+	struct virtio_console_config *p = early_base + VIRTIO_MMIO_CONFIG;
+
+	if (!init_done) {
+		tmp = readl_relaxed(early_base + VIRTIO_MMIO_DEVICE_ID);
+		if (tmp != VIRTIO_ID_CONSOLE) {
+			init_done = 1;
+			return;
+		}
+
+		tmp = readl_relaxed(early_base + VIRTIO_MMIO_HOST_FEATURES);
+		if (!(tmp & (1 << VIRTIO_CONSOLE_F_EARLY_WRITE))) {
+			init_done = 1;
+			return;
+		}
+
+		init_done = 1;
+		can_write = 1;
+	}
+
+	if (can_write)
+		writeb_relaxed(ch, &p->early_wr);
+}
+
+/*
  * 8250/16550 (8-bit aligned registers) single character TX.
  */
 static void uart8250_8bit_printch(char ch)
@@ -82,6 +116,7 @@ static const struct earlycon_match earlycon_match[] __initconst = {
 	{ .name = "smh", .printch = smh_printch, },
 	{ .name = "uart8250-8bit", .printch = uart8250_8bit_printch, },
 	{ .name = "uart8250-32bit", .printch = uart8250_32bit_printch, },
+	{ .name = "virtio-console", .printch = virtio_console_printch, },
 	{}
 };
 
-- 
1.7.9.5



From mark.rutland at arm.com  Fri Apr 26 07:09:29 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Fri, 26 Apr 2013 12:09:29 +0100
Subject: [PATCHv2 1/4] Documentation: Add memory mapped ARM architected
 timer binding
In-Reply-To: <5179B6ED.9000301@gmail.com>
References: <1365812863-5367-1-git-send-email-sboyd@codeaurora.org>
 <1365812863-5367-2-git-send-email-sboyd@codeaurora.org>
 <516C6F12.5020208@gmail.com> <516C7231.6060305@codeaurora.org>
 <5179A488.5050102@gmail.com> <5179B2B2.8000201@codeaurora.org>
 <5179B6ED.9000301@gmail.com>
Message-ID: <20130426110929.GB11648@e106331-lin.cambridge.arm.com>

On Fri, Apr 26, 2013 at 12:06:21AM +0100, Rob Herring wrote:
> On 04/25/2013 05:48 PM, Stephen Boyd wrote:
> > On 04/25/13 14:47, Rob Herring wrote:
> >> On 04/15/2013 04:33 PM, Stephen Boyd wrote:
> >>> On 04/15/13 14:20, Rob Herring wrote:
> >>>> On Fri, Apr 12, 2013 at 7:27 PM, Stephen Boyd <sboyd at codeaurora.org> wrote:
> >>>>> @@ -26,3 +30,52 @@ Example:
> >>>>>                              <1 10 0xf08>;
> >>>>>                 clock-frequency = <100000000>;
> >>>>>         };
> >>>>> +
> >>>>> +** Memory mapped timer node properties
> >>>>> +
> >>>>> +- compatible : Should at least contain "arm,armv7-timer-mem".
> >>>> Everything about this timer is architecturally defined? If not, let's
> >>>> use a more specific name.
> >>> I'm not sure I'm following you, but everything described here is part of
> >>> the ARM definition. What would be a more specific name?
> >> Something that corresponds to the particular implementation like
> >> cortex-a15 (obviously not an example that has this). I'm fine with
> >> leaving this for now, but would like to see that added when specific SOC
> >> dts are added. Better to be specific in case we need to use it for
> >> something like errata work-arounds. Of course we haven't done that so
> >> far with the arch timer bindings...
> > 
> > Agreed. I'm under the impression that most of our compatible fields
> > should be more specific than they currently are so we can workaround hw
> > bugs like you say. Perhaps the catch all generic one should just be
> > "arm,arm-timer-mem" since it isn't tied to any particular CPU type?
> > 
> >>
> >>>>> +
> >>>>> +- clock-frequency : The frequency of the main counter, in Hz. Optional.
> >>>>> +
> >>>>> +- reg : The control frame base address.
> >>>>> +
> >>>>> +Note that #address-cells, #size-cells, and ranges shall be present to ensure
> >>>>> +the CPU can address a frame's registers.
> >>>>> +
> >>>>> +Frame:
> >>>>> +
> >>>>> +- frame-number: 0 to 7.
> >>>> I'd really like to get rid of the frame numbers and sub-nodes. Is the
> >>>> frame number significant to software?
> >>> We need the frame number to read and write registers in the control
> >>> frame (the first base in the parent node). We currently use it to
> >>> determine if a frame has support for the virtual timer by reading the
> >>> CNTTIDR (a register with 4 bits per frame describing capabilities). If
> >>> we wanted to control access to the second view of a frame we would also
> >>> need to configure the CNTPL0ACRn register that pertains to the frame
> >>> we're controlling. Without a frame number we wouldn't know which
> >>> register to write.
> >> I've gone thru the memory mapped part of the spec now, so I think I
> >> understand things better. I see how the frame number is needed, but...
> >>
> >> The control base is only accessible in secure or hyp mode. How does a
> >> guest know that it is a guest and can't map the control base? Seems like
> >> we need to allow a subset of the binding that is just a reg and
> >> interrupts properties without the frame sub nodes.
> > 
> > I don't see that part. My understanding is that the control base is
> > accessible in non-secure mode and by the guests. There are certain
> > registers within that base that are only accessible in secure mode
> > though: CNTFRQ and CNTNSAR. Also some registers are configurable:
> > CNTACRn and CNTVOFFN. CNTVOFFN is only accessible in the hypervisor.
> 
> The example is section E.8 seems to say otherwise. Perhaps Mark R can
> comment further.

I believe E.8 is an example system, not the general case.

However, I don't see anything limiting accesses to CNTVOFFn to the hypervisor.
As far as I can see, if the guest has access to the CNTCTLBase frame, it has
the same access privileges as the host (and hypervisor).

CNTACRn and CNTVOFFn only seem to be configurable with regard to
secure/non-secure accesses.

> 
> > We don't really care about CNTFRQ because it's duplicated into each
> > view. We do care about CNTNSAR. Luckily the spec "just works" there in
> > the sense that we can use CNTTIDR in conjunction with CNTACRn and
> > determine if we have access to a frame we're interested in if the
> > CNTTIDR bits say the frame is present and the CNTACRn register says we
> > can access it. If not then it must be locked down for secure users.
> > 
> > Unfortunately hardware doesn't have a way to say that a particular frame
> > is reserved for the hypervisor or the guest kernel/userspace. We need
> > some help from software, so we have the status property express that a
> > particular frame is available. We have to assume the DT is going to be
> > different depending on if you're the hypervisor or the guest. That's a
> > valid assumption right? Otherwise I hope we can do some trapping of the
> > guest's mapping to the control base and then rewrite what they read so
> > that they only see the frame that we want to be available to them.
> 
> Yeah, I believe the only way to prevent access within non-secure world
> is with the MMU. So I guess the example is just policy that the
> hypervisor would/may not create a stage2 mapping. You still have the
> same issue that the guest should not be passed the control base. You
> could make the reg property optional, but then what do you do with the
> node name?

I'm not sure on if and how we'd want to expose this to guests. I'm adding Marc
Zyngier to Cc, he may have some relevant thoughts.

Mark.


From coelho at ti.com  Fri Apr 26 07:16:26 2013
From: coelho at ti.com (Luciano Coelho)
Date: Fri, 26 Apr 2013 14:16:26 +0300
Subject: [PATCH 1/3] ARM: OMAP2+: Legacy support for wl12xx when booted
 with devicetree
In-Reply-To: <1366974032.4029.31.camel@cumari.coelho.fi>
References: <20130426034858.26065.65118.stgit@muffinssi.local>
 <20130426035210.26065.39995.stgit@muffinssi.local>
 <0104F687-1726-476D-B2DF-7E72223B127A@dominion.thruhere.net>
 <1366974032.4029.31.camel@cumari.coelho.fi>
Message-ID: <1366974986.4029.32.camel@cumari.coelho.fi>

On Fri, 2013-04-26 at 14:00 +0300, Luciano Coelho wrote:
> Hi Koen,
> 
> On Fri, 2013-04-26 at 11:33 +0200, Koen Kooi wrote:
> > Op 26 apr. 2013, om 05:52 heeft Tony Lindgren <tony at atomide.com> het volgende geschreven:
> > 
> > > Without WLAN we cannot switch omap4 to use device tree
> > > only booting. This patch can be reverted when the
> > > binding for wl12xx is added.
> > 
> > How much boards am I allowed to add to this? I need to get the wl12xx wifi expansionboards for beagleboard, beagleboard xM and beaglebone working with DT :)
> 
> Do you know where I can get a wl12xx wifi expansion board for
> beaglebone?

Uhmmm, never mind.  I somehow thought this was with the WiLink 8 chip,
but you said wl12xx, so it's not. ;)

-- 
Luca.



From agraf at suse.de  Fri Apr 26 07:19:50 2013
From: agraf at suse.de (Alexander Graf)
Date: Fri, 26 Apr 2013 13:19:50 +0200
Subject: [PATCH 0/2] Early printk support for virtio console devices.
In-Reply-To: <1366974299-17877-1-git-send-email-pranavkumar@linaro.org>
References: <1366974299-17877-1-git-send-email-pranavkumar@linaro.org>
Message-ID: <BA2076A6-0688-4E5C-85F9-A9CA8FD75782@suse.de>


On 26.04.2013, at 13:04, Pranavkumar Sawargaonkar wrote:

> This patch-set implements early printk support for virtio console devices without using any hypercalls.
> 
> The current virtio early printk code in kernel expects that hypervisor will provide some mechanism generally a hypercall to support early printk. This patch-set does not break existing hypercall based early print support.
> 
> This implementation adds:
> 1. Early writeonly register named early_wr in virtio console's config space.
> 2. Host feature flags namely VIRTIO_CONSOLE_F_EARLY_WRITE for telling guest about early-write capability in console device.
> 
> Early write mechanism:
> 1. When a guest wants to out some character, it has to simply write the character to early_wr register in config space of virtio console device.

I won't nack this patch set, but I'll definitely express that I'm not happy with it.

MMIO registers are handled by a different layer than the virtio console itself. After the virtio refactoring in QEMU, they will be completely separate drivers. So we'll be in a similar mess with early printk as we are on the s390-virtio machine, where early printk is done through hypercalls and thus we can't directly link it to the console output.

I still don't see what the issue is with just implementing a small irq-less virtio driver for early printk.


Alex



From cb at sgoc.de  Fri Apr 26 07:20:15 2013
From: cb at sgoc.de (Christoph G. Baumann)
Date: Fri, 26 Apr 2013 13:20:15 +0200
Subject: [PATCH 2/2] crypto: added support for fsl-dcp on iMX23,28,50
In-Reply-To: <1366975215-5420-1-git-send-email-cb@sgoc.de>
References: <1366975215-5420-1-git-send-email-cb@sgoc.de>
Message-ID: <1366975215-5420-3-git-send-email-cb@sgoc.de>

From: "Christoph G. Baumann" <cb at sgoc.de>

This patch contains modified files.

Signed-off-by: "Christoph G. Baumann" <cb at sgoc.de>
---
 arch/arm/boot/dts/imx28.dtsi |    2 +-
 drivers/staging/Kconfig      |    2 ++
 drivers/staging/Makefile     |    1 +
 3 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
index 7ba4966..2bec573 100644
--- a/arch/arm/boot/dts/imx28.dtsi
+++ b/arch/arm/boot/dts/imx28.dtsi
@@ -664,9 +664,9 @@
 			};
 
 			dcp at 80028000 {
+                                compatible = "fsl,fsl-dcp";
 				reg = <0x80028000 0x2000>;
 				interrupts = <52 53 54>;
-				status = "disabled";
 			};
 
 			pxp at 8002a000 {
diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig
index 093f10c..b3cf08b 100644
--- a/drivers/staging/Kconfig
+++ b/drivers/staging/Kconfig
@@ -140,4 +140,6 @@ source "drivers/staging/zcache/Kconfig"
 
 source "drivers/staging/goldfish/Kconfig"
 
+source "drivers/staging/crypto/Kconfig"
+
 endif # STAGING
diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile
index fa41b04..6875e3e 100644
--- a/drivers/staging/Makefile
+++ b/drivers/staging/Makefile
@@ -62,3 +62,4 @@ obj-$(CONFIG_SB105X)		+= sb105x/
 obj-$(CONFIG_FIREWIRE_SERIAL)	+= fwserial/
 obj-$(CONFIG_ZCACHE)		+= zcache/
 obj-$(CONFIG_GOLDFISH)		+= goldfish/
+obj-$(CONFIG_CRYPTO_HW)		+= crypto/
-- 
1.7.9.5



From cb at sgoc.de  Fri Apr 26 07:20:14 2013
From: cb at sgoc.de (Christoph G. Baumann)
Date: Fri, 26 Apr 2013 13:20:14 +0200
Subject: [PATCH 1/2] crypto: added support for fsl-dcp on iMX23,28,50
In-Reply-To: <1366975215-5420-1-git-send-email-cb@sgoc.de>
References: <1366975215-5420-1-git-send-email-cb@sgoc.de>
Message-ID: <1366975215-5420-2-git-send-email-cb@sgoc.de>

From: "Christoph G. Baumann" <cb at sgoc.de>

This patch contains added files

Signed-off-by: "Christoph G. Baumann" <cb at sgoc.de>
---
 drivers/staging/crypto/Kconfig               |   15 +
 drivers/staging/crypto/Makefile              |    1 +
 drivers/staging/crypto/fsl-dcp.c             | 1790 ++++++++++++++++++++++++++
 drivers/staging/crypto/fsl-dcp.h             |  739 +++++++++++
 include/linux/fsl/fsl-dcp_bootstream_ioctl.h |   32 +
 5 files changed, 2577 insertions(+)
 create mode 100644 drivers/staging/crypto/Kconfig
 create mode 100644 drivers/staging/crypto/Makefile
 create mode 100644 drivers/staging/crypto/fsl-dcp.c
 create mode 100644 drivers/staging/crypto/fsl-dcp.h
 create mode 100644 include/linux/fsl/fsl-dcp_bootstream_ioctl.h

diff --git a/drivers/staging/crypto/Kconfig b/drivers/staging/crypto/Kconfig
new file mode 100644
index 0000000..acf2cf9
--- /dev/null
+++ b/drivers/staging/crypto/Kconfig
@@ -0,0 +1,15 @@
+config CRYPTO_DEV_FSL_DCP
+	tristate "Support for the DCP engine"
+	depends on SOC_IMX23 || SOC_IMX28 || SOC_IMX50
+  select CRYPTO_HW
+	select CRYPTO_ALGAPI
+  select CRYPTO_SHA256
+	select CRYPTO_AES
+	select CRYPTO_BLKCIPHER
+	help
+	  Say 'Y' here to use the DCP AES and SHA
+	  engine for the CryptoAPI algorithms.
+
+	  To compile this driver as a module, choose M here: the module
+	  will be called fsl-dcp.
+
diff --git a/drivers/staging/crypto/Makefile b/drivers/staging/crypto/Makefile
new file mode 100644
index 0000000..06eabdf
--- /dev/null
+++ b/drivers/staging/crypto/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_CRYPTO_DEV_FSL_DCP) += fsl-dcp.o
diff --git a/drivers/staging/crypto/fsl-dcp.c b/drivers/staging/crypto/fsl-dcp.c
new file mode 100644
index 0000000..9d27ebe
--- /dev/null
+++ b/drivers/staging/crypto/fsl-dcp.c
@@ -0,0 +1,1790 @@
+/*
+ * Copyright (C) 2008-2010 Freescale Semiconductor, Inc.
+ */
+/*
+ * adapted to Kernel version 3.7 by Christoph G. Baumann <cgb at debian.org>
+ */
+/*
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+/*
+ * Based on geode-aes.c
+ * Copyright (C) 2004-2006, Advanced Micro Devices, Inc.
+ */
+
+#include <linux/slab.h>
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/errno.h>
+#include <linux/bitops.h>
+#include <linux/crypto.h>
+#include <linux/spinlock.h>
+#include <linux/miscdevice.h>
+#include <linux/platform_device.h>
+#include <linux/err.h>
+#include <linux/sysfs.h>
+#include <linux/fs.h>
+#include <crypto/algapi.h>
+#include <crypto/aes.h>
+#include <crypto/sha.h>
+#include <crypto/hash.h>
+#include <crypto/internal/hash.h>
+#include <linux/dma-mapping.h>
+#include <linux/interrupt.h>
+#include <linux/delay.h>
+#include <linux/uaccess.h>
+#include <linux/clk.h>
+#include <linux/io.h>
+#include <linux/delay.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_device.h>
+
+#include <asm/cacheflush.h>
+#include <mach/hardware.h>
+#include <linux/fsl/fsl-dcp_bootstream_ioctl.h>
+#include "fsl-dcp.h"
+
+/* Following data only used by DCP bootstream interface */
+struct dcpboot_dma_area {
+	struct dcp_hw_packet hw_packet;
+	uint16_t block[16];
+};
+
+struct dcp {
+	struct device *dev;
+	spinlock_t lock;
+	struct mutex op_mutex[DCP_NUM_CHANNELS];
+	struct completion op_wait[DCP_NUM_CHANNELS];
+	int wait[DCP_NUM_CHANNELS];
+	int dcp_vmi_irq;
+	int dcp_irq;
+	u32 dcp_regs_base;
+	ulong clock_state;
+	bool chan_in_use[DCP_NUM_CHANNELS];
+
+	/* Following buffers used in hashing to meet 64-byte len alignment */
+	char *buf1;
+	char *buf2;
+	dma_addr_t buf1_phys;
+	dma_addr_t buf2_phys;
+	struct dcp_hash_coherent_block *buf1_desc;
+	struct dcp_hash_coherent_block *buf2_desc;
+	struct dcp_hash_coherent_block *user_buf_desc;
+
+	/* Following data only used by DCP bootstream interface */
+	struct dcpboot_dma_area *dcpboot_dma_area;
+	dma_addr_t dcpboot_dma_area_phys;
+};
+
+/* cipher flags */
+#define DCP_ENC	0x0001
+#define DCP_DEC	0x0002
+#define DCP_ECB	0x0004
+#define DCP_CBC	0x0008
+#define DCP_CBC_INIT	0x0010
+#define DCP_OTPKEY	0x0020
+
+/* hash flags */
+#define DCP_INIT	0x0001
+#define DCP_UPDATE	0x0002
+#define DCP_FINAL	0x0004
+
+#define DCP_AES	0x1000
+#define DCP_SHA1	0x2000
+#define DCP_CRC32	0x3000
+#define DCP_COPY	0x4000
+#define DCP_FILL	0x5000
+#define DCP_MODE_MASK	0xf000
+
+/* clock defines */
+#define CLOCK_ON	1
+#define CLOCK_OFF	0
+
+struct dcp_op {
+
+	unsigned int flags;
+
+	void *src;
+	dma_addr_t src_phys;
+
+	void *dst;
+	dma_addr_t dst_phys;
+
+	int len;
+
+	/* the key contains the IV for block modes */
+	union {
+		struct {
+			u8 key[2 * AES_KEYSIZE_128] __aligned(32);
+			dma_addr_t key_phys;
+			int keylen;
+		} cipher;
+		struct {
+			u8 digest[SHA256_DIGEST_SIZE] __aligned(32);
+			dma_addr_t digest_phys;
+			int digestlen;
+			int init;
+		} hash;
+	};
+
+	union {
+		struct crypto_blkcipher *blk;
+		struct crypto_cipher *cip;
+		struct crypto_hash *hash;
+	} fallback;
+
+	struct dcp_hw_packet pkt __aligned(32);
+};
+
+struct dcp_hash_coherent_block {
+	struct dcp_hw_packet pkt[1] __aligned(32);
+	u8 digest[SHA256_DIGEST_SIZE] __aligned(32);
+	unsigned int len;
+	dma_addr_t src_phys;
+	void *src;
+	void *dst;
+	dma_addr_t my_phys;
+	u32 hash_sel;
+	struct dcp_hash_coherent_block *next;
+};
+
+struct dcp_hash_op {
+
+	unsigned int flags;
+
+	/* the key contains the IV for block modes */
+	union {
+		struct {
+			u8 key[2 * AES_KEYSIZE_128] __aligned(32);
+			dma_addr_t key_phys;
+			int keylen;
+		} cipher;
+		struct {
+			u8 digest[SHA256_DIGEST_SIZE] __aligned(32);
+			dma_addr_t digest_phys;
+			int digestlen;
+			int init;
+		} hash;
+	};
+
+	u32 length;
+	struct dcp_hash_coherent_block *head_desc;
+	struct dcp_hash_coherent_block *tail_desc;
+};
+
+/* only one */
+static struct dcp *global_sdcp;
+
+static void dcp_clock(struct dcp *sdcp, ulong state, bool force)
+{
+	u32 chan;
+	struct clk *clk = clk_get(sdcp->dev, "dcp_clk");
+
+	/* unless force is true (used during suspend/resume), if any
+	 * channel is running, then clk is already on, and must stay on */
+	if (!force) {
+		for (chan = 0; chan < DCP_NUM_CHANNELS; chan++) {
+			if (sdcp->chan_in_use[chan])
+				goto exit;
+		}
+	}
+
+	if (state == CLOCK_OFF) {
+		/* gate at clock source */
+		if (!IS_ERR(clk)) {
+			clk_disable(clk);
+		/* gate at DCP */
+		} else {
+			__raw_writel(BM_DCP_CTRL_CLKGATE,
+			(void *)(sdcp->dcp_regs_base + HW_DCP_CTRL_SET));
+		}
+
+		sdcp->clock_state = CLOCK_OFF;
+
+	} else {
+		/* ungate at clock source */
+		if (!IS_ERR(clk)) {
+			clk_enable(clk);
+		/* ungate at DCP */
+		} else {
+			__raw_writel(BM_DCP_CTRL_CLKGATE,
+			(void *)(sdcp->dcp_regs_base + HW_DCP_CTRL_CLR));
+		}
+
+		sdcp->clock_state = CLOCK_ON;
+	}
+
+ exit:
+	return;
+}
+
+static void dcp_perform_op(struct dcp_op *op)
+{
+	struct dcp *sdcp = global_sdcp;
+	struct mutex *mutex;
+	struct dcp_hw_packet *pkt;
+	int chan;
+	u32 pkt1, pkt2;
+	unsigned long timeout;
+	dma_addr_t pkt_phys;
+	u32 stat;
+
+	pkt1 = BM_DCP_PACKET1_DECR_SEMAPHORE | BM_DCP_PACKET1_INTERRUPT;
+
+	switch (op->flags & DCP_MODE_MASK) {
+
+	case DCP_AES:
+
+		chan = CIPHER_CHAN;
+
+		/* key is at the payload */
+		pkt1 |= BM_DCP_PACKET1_ENABLE_CIPHER;
+		if ((op->flags & DCP_OTPKEY) == 0)
+			pkt1 |= BM_DCP_PACKET1_PAYLOAD_KEY;
+		if (op->flags & DCP_ENC)
+			pkt1 |= BM_DCP_PACKET1_CIPHER_ENCRYPT;
+		if (op->flags & DCP_CBC_INIT)
+			pkt1 |= BM_DCP_PACKET1_CIPHER_INIT;
+
+		pkt2 = BF(0, DCP_PACKET2_CIPHER_CFG) |
+		    BF(0, DCP_PACKET2_KEY_SELECT) |
+		    BF(BV_DCP_PACKET2_CIPHER_SELECT__AES128,
+		       DCP_PACKET2_CIPHER_SELECT);
+
+		if (op->flags & DCP_ECB)
+			pkt2 |= BF(BV_DCP_PACKET2_CIPHER_MODE__ECB,
+				   DCP_PACKET2_CIPHER_MODE);
+		else if (op->flags & DCP_CBC)
+			pkt2 |= BF(BV_DCP_PACKET2_CIPHER_MODE__CBC,
+				   DCP_PACKET2_CIPHER_MODE);
+
+		break;
+
+	case DCP_SHA1:
+
+		chan = HASH_CHAN;
+
+		pkt1 |= BM_DCP_PACKET1_ENABLE_HASH;
+		if (op->flags & DCP_INIT)
+			pkt1 |= BM_DCP_PACKET1_HASH_INIT;
+		if (op->flags & DCP_FINAL) {
+			pkt1 |= BM_DCP_PACKET1_HASH_TERM;
+			BUG_ON(op->hash.digest == NULL);
+		}
+
+		pkt2 = BF(BV_DCP_PACKET2_HASH_SELECT__SHA1,
+			  DCP_PACKET2_HASH_SELECT);
+		break;
+
+	default:
+		dev_err(sdcp->dev, "Unsupported mode\n");
+		return;
+	}
+
+	mutex = &sdcp->op_mutex[chan];
+	pkt = &op->pkt;
+
+	pkt->next = 0;
+	pkt->pkt1 = pkt1;
+	pkt->pkt2 = pkt2;
+	pkt->src = (u32) op->src_phys;
+	pkt->dst = (u32) op->dst_phys;
+	pkt->size = op->len;
+	pkt->payload = chan == CIPHER_CHAN ?
+	    (u32) op->cipher.key_phys : (u32) op->hash.digest_phys;
+	pkt->stat = 0;
+
+	pkt_phys = dma_map_single(sdcp->dev, pkt, sizeof(*pkt),
+				  DMA_BIDIRECTIONAL);
+	if (dma_mapping_error(sdcp->dev, pkt_phys)) {
+		dev_err(sdcp->dev, "Unable to map packet descriptor\n");
+		return;
+	}
+
+	/* submit the work */
+	mutex_lock(mutex);
+	dcp_clock(sdcp, CLOCK_ON, false);
+	sdcp->chan_in_use[chan] = true;
+
+	__raw_writel(-1, (void *)(sdcp->dcp_regs_base
+				+ HW_DCP_CH_N_STAT_CLR(chan)));
+
+	/* Load the work packet pointer and bump the channel semaphore */
+	__raw_writel((u32) pkt_phys, (void *)(sdcp->dcp_regs_base
+					+ HW_DCP_CH_N_CMDPTR(chan)));
+
+	/* XXX wake from interrupt instead of looping */
+	timeout = jiffies + msecs_to_jiffies(1000);
+
+	sdcp->wait[chan] = 0;
+	__raw_writel(BF(1, DCP_CH_N_SEMA_INCREMENT),
+			(void *)(sdcp->dcp_regs_base + HW_DCP_CH_N_SEMA(chan)));
+	while (time_before(jiffies, timeout) && sdcp->wait[chan] == 0)
+		cpu_relax();
+
+	if (!time_before(jiffies, timeout)) {
+		dev_err(sdcp->dev, "Timeout while waiting STAT 0x%08x\n",
+			__raw_readl((void *)(sdcp->dcp_regs_base
+						+ HW_DCP_STAT)));
+		goto out;
+	}
+
+	stat =
+	    __raw_readl((void *)(sdcp->dcp_regs_base + HW_DCP_CH_N_STAT(chan)));
+	if ((stat & 0xff) != 0) {
+		dev_err(sdcp->dev, "Channel stat error 0x%02x\n",
+			__raw_readl((void *)(sdcp->dcp_regs_base
+				+ (HW_DCP_CH_N_STAT(chan) & 0xff))));
+	}
+
+ out:
+	sdcp->chan_in_use[chan] = false;
+	dcp_clock(sdcp, CLOCK_OFF, false);
+	mutex_unlock(mutex);
+	dma_unmap_single(sdcp->dev, pkt_phys, sizeof(*pkt), DMA_TO_DEVICE);
+}
+
+static int dcp_aes_setkey_cip(struct crypto_tfm *tfm, const u8 *key,
+			      unsigned int len)
+{
+	struct dcp_op *op = crypto_tfm_ctx(tfm);
+	unsigned int ret;
+
+	op->cipher.keylen = len;
+
+	if (len == AES_KEYSIZE_128) {
+		memcpy(op->cipher.key, key, len);
+		return 0;
+	}
+
+	if (len != AES_KEYSIZE_192 && len != AES_KEYSIZE_256) {
+		/* not supported at all */
+		tfm->crt_flags |= CRYPTO_TFM_RES_BAD_KEY_LEN;
+		return -EINVAL;
+	}
+
+	/*
+	 * The requested key size is not supported by HW, do a fallback
+	 */
+	op->fallback.blk->base.crt_flags &= ~CRYPTO_TFM_REQ_MASK;
+	op->fallback.blk->base.crt_flags |= (tfm->crt_flags &
+					     CRYPTO_TFM_REQ_MASK);
+
+	ret = crypto_cipher_setkey(op->fallback.cip, key, len);
+	if (ret) {
+		tfm->crt_flags &= ~CRYPTO_TFM_RES_MASK;
+		tfm->crt_flags |= (op->fallback.blk->base.crt_flags &
+				   CRYPTO_TFM_RES_MASK);
+	}
+	return ret;
+}
+
+static void dcp_aes_encrypt(struct crypto_tfm *tfm, u8 *out, const u8 *in)
+{
+	struct dcp *sdcp = global_sdcp;
+	struct dcp_op *op = crypto_tfm_ctx(tfm);
+
+	if (unlikely(op->cipher.keylen != AES_KEYSIZE_128)) {
+		crypto_cipher_encrypt_one(op->fallback.cip, out, in);
+		return;
+	}
+
+	op->src = (void *)in;
+	op->dst = (void *)out;
+	op->flags = DCP_AES | DCP_ENC | DCP_ECB;
+	op->len = AES_KEYSIZE_128;
+
+	/* map the data */
+	op->src_phys = dma_map_single(sdcp->dev, (void *)in,
+					AES_KEYSIZE_128, DMA_TO_DEVICE);
+	if (dma_mapping_error(sdcp->dev, op->src_phys)) {
+		dev_err(sdcp->dev, "Unable to map source\n");
+		return;
+	}
+
+	op->dst_phys = dma_map_single(sdcp->dev, out, AES_KEYSIZE_128,
+				      DMA_FROM_DEVICE);
+	if (dma_mapping_error(sdcp->dev, op->dst_phys)) {
+		dev_err(sdcp->dev, "Unable to map dest\n");
+		goto err_unmap_src;
+	}
+
+	op->cipher.key_phys = dma_map_single(sdcp->dev, op->cipher.key,
+						AES_KEYSIZE_128, DMA_TO_DEVICE);
+	if (dma_mapping_error(sdcp->dev, op->cipher.key_phys)) {
+		dev_err(sdcp->dev, "Unable to map key\n");
+		goto err_unmap_dst;
+	}
+
+	/* perform the operation */
+	dcp_perform_op(op);
+
+	dma_unmap_single(sdcp->dev, op->cipher.key_phys, AES_KEYSIZE_128,
+			 DMA_TO_DEVICE);
+ err_unmap_dst:
+	dma_unmap_single(sdcp->dev, op->dst_phys, op->len, DMA_FROM_DEVICE);
+ err_unmap_src:
+	dma_unmap_single(sdcp->dev, op->src_phys, op->len, DMA_TO_DEVICE);
+}
+
+static void dcp_aes_decrypt(struct crypto_tfm *tfm, u8 *out, const u8 *in)
+{
+	struct dcp *sdcp = global_sdcp;
+	struct dcp_op *op = crypto_tfm_ctx(tfm);
+
+	if (unlikely(op->cipher.keylen != AES_KEYSIZE_128)) {
+		crypto_cipher_decrypt_one(op->fallback.cip, out, in);
+		return;
+	}
+
+	op->src = (void *)in;
+	op->dst = (void *)out;
+	op->flags = DCP_AES | DCP_DEC | DCP_ECB;
+	op->len = AES_KEYSIZE_128;
+
+	/* map the data */
+	op->src_phys = dma_map_single(sdcp->dev, (void *)in, AES_KEYSIZE_128,
+				      DMA_TO_DEVICE);
+	if (dma_mapping_error(sdcp->dev, op->src_phys)) {
+		dev_err(sdcp->dev, "Unable to map source\n");
+		return;
+	}
+
+	op->dst_phys = dma_map_single(sdcp->dev, out, AES_KEYSIZE_128,
+				      DMA_FROM_DEVICE);
+	if (dma_mapping_error(sdcp->dev, op->dst_phys)) {
+		dev_err(sdcp->dev, "Unable to map dest\n");
+		goto err_unmap_src;
+	}
+
+	op->cipher.key_phys = dma_map_single(sdcp->dev, op->cipher.key,
+					     AES_KEYSIZE_128, DMA_TO_DEVICE);
+	if (dma_mapping_error(sdcp->dev, op->cipher.key_phys)) {
+		dev_err(sdcp->dev, "Unable to map key\n");
+		goto err_unmap_dst;
+	}
+
+	/* perform the operation */
+	dcp_perform_op(op);
+
+	dma_unmap_single(sdcp->dev, op->cipher.key_phys, AES_KEYSIZE_128,
+			 DMA_TO_DEVICE);
+ err_unmap_dst:
+	dma_unmap_single(sdcp->dev, op->dst_phys, op->len, DMA_FROM_DEVICE);
+ err_unmap_src:
+	dma_unmap_single(sdcp->dev, op->src_phys, op->len, DMA_TO_DEVICE);
+}
+
+static int fallback_init_cip(struct crypto_tfm *tfm)
+{
+	const char *name = tfm->__crt_alg->cra_name;
+	struct dcp_op *op = crypto_tfm_ctx(tfm);
+
+	op->fallback.cip = crypto_alloc_cipher(name, 0,
+					       CRYPTO_ALG_ASYNC |
+					       CRYPTO_ALG_NEED_FALLBACK);
+
+	if (IS_ERR(op->fallback.cip))
+		return PTR_ERR(op->fallback.cip);
+
+	return 0;
+}
+
+static void fallback_exit_cip(struct crypto_tfm *tfm)
+{
+	struct dcp_op *op = crypto_tfm_ctx(tfm);
+
+	crypto_free_cipher(op->fallback.cip);
+	op->fallback.cip = NULL;
+}
+
+static struct crypto_alg dcp_aes_alg = {
+	.cra_name = "aes",
+	.cra_driver_name = "dcp-aes",
+	.cra_priority = 300,
+	.cra_alignmask = 15,
+	.cra_flags = CRYPTO_ALG_TYPE_CIPHER | CRYPTO_ALG_NEED_FALLBACK,
+	.cra_init = fallback_init_cip,
+	.cra_exit = fallback_exit_cip,
+	.cra_blocksize = AES_KEYSIZE_128,
+	.cra_ctxsize = sizeof(struct dcp_op),
+	.cra_module = THIS_MODULE,
+	.cra_list = LIST_HEAD_INIT(dcp_aes_alg.cra_list),
+	.cra_u = {
+		  .cipher = {
+			     .cia_min_keysize = AES_MIN_KEY_SIZE,
+			     .cia_max_keysize = AES_MAX_KEY_SIZE,
+			     .cia_setkey = dcp_aes_setkey_cip,
+			     .cia_encrypt = dcp_aes_encrypt,
+			     .cia_decrypt = dcp_aes_decrypt}
+		  }
+};
+
+static int dcp_aes_setkey_blk(struct crypto_tfm *tfm, const u8 *key,
+			      unsigned int len)
+{
+	struct dcp_op *op = crypto_tfm_ctx(tfm);
+	unsigned int ret;
+
+	op->cipher.keylen = len;
+
+	if (len == AES_KEYSIZE_128) {
+		memcpy(op->cipher.key, key, len);
+		return 0;
+	}
+
+	if (len != AES_KEYSIZE_192 && len != AES_KEYSIZE_256) {
+		/* not supported at all */
+		tfm->crt_flags |= CRYPTO_TFM_RES_BAD_KEY_LEN;
+		return -EINVAL;
+	}
+
+	/*
+	 * The requested key size is not supported by HW, do a fallback
+	 */
+	op->fallback.blk->base.crt_flags &= ~CRYPTO_TFM_REQ_MASK;
+	op->fallback.blk->base.crt_flags |= (tfm->crt_flags &
+					     CRYPTO_TFM_REQ_MASK);
+
+	ret = crypto_blkcipher_setkey(op->fallback.blk, key, len);
+	if (ret) {
+		tfm->crt_flags &= ~CRYPTO_TFM_RES_MASK;
+		tfm->crt_flags |= (op->fallback.blk->base.crt_flags &
+				   CRYPTO_TFM_RES_MASK);
+	}
+	return ret;
+}
+
+static int fallback_blk_dec(struct blkcipher_desc *desc,
+			    struct scatterlist *dst, struct scatterlist *src,
+			    unsigned int nbytes)
+{
+	unsigned int ret;
+	struct crypto_blkcipher *tfm;
+	struct dcp_op *op = crypto_blkcipher_ctx(desc->tfm);
+
+	tfm = desc->tfm;
+	desc->tfm = op->fallback.blk;
+
+	ret = crypto_blkcipher_decrypt_iv(desc, dst, src, nbytes);
+
+	desc->tfm = tfm;
+	return ret;
+}
+
+static int fallback_blk_enc(struct blkcipher_desc *desc,
+			    struct scatterlist *dst, struct scatterlist *src,
+			    unsigned int nbytes)
+{
+	unsigned int ret;
+	struct crypto_blkcipher *tfm;
+	struct dcp_op *op = crypto_blkcipher_ctx(desc->tfm);
+
+	tfm = desc->tfm;
+	desc->tfm = op->fallback.blk;
+
+	ret = crypto_blkcipher_encrypt_iv(desc, dst, src, nbytes);
+
+	desc->tfm = tfm;
+	return ret;
+}
+
+static int fallback_init_blk(struct crypto_tfm *tfm)
+{
+	const char *name = tfm->__crt_alg->cra_name;
+	struct dcp_op *op = crypto_tfm_ctx(tfm);
+
+	op->fallback.blk = crypto_alloc_blkcipher(name, 0,
+						  CRYPTO_ALG_ASYNC |
+						  CRYPTO_ALG_NEED_FALLBACK);
+
+	if (IS_ERR(op->fallback.blk))
+		return PTR_ERR(op->fallback.blk);
+
+	return 0;
+}
+
+static void fallback_exit_blk(struct crypto_tfm *tfm)
+{
+	struct dcp_op *op = crypto_tfm_ctx(tfm);
+
+	crypto_free_blkcipher(op->fallback.blk);
+	op->fallback.blk = NULL;
+}
+
+static int
+dcp_aes_ecb_decrypt(struct blkcipher_desc *desc,
+		    struct scatterlist *dst, struct scatterlist *src,
+		    unsigned int nbytes)
+{
+	struct dcp *sdcp = global_sdcp;
+	struct dcp_op *op = crypto_blkcipher_ctx(desc->tfm);
+	struct blkcipher_walk walk;
+	int err;
+
+	if (unlikely(op->cipher.keylen != AES_KEYSIZE_128))
+		return fallback_blk_dec(desc, dst, src, nbytes);
+
+	blkcipher_walk_init(&walk, dst, src, nbytes);
+
+	/* key needs to be mapped only once */
+	op->cipher.key_phys = dma_map_single(sdcp->dev, op->cipher.key,
+					     AES_KEYSIZE_128, DMA_TO_DEVICE);
+	if (dma_mapping_error(sdcp->dev, op->cipher.key_phys)) {
+		dev_err(sdcp->dev, "Unable to map key\n");
+		return -ENOMEM;
+	}
+
+	err = blkcipher_walk_virt(desc, &walk);
+	while (err == 0 && (nbytes = walk.nbytes) > 0) {
+		op->src = walk.src.virt.addr, op->dst = walk.dst.virt.addr;
+		op->flags = DCP_AES | DCP_DEC | DCP_ECB;
+		op->len = nbytes - (nbytes % AES_KEYSIZE_128);
+
+		/* map the data */
+		op->src_phys = dma_map_single(sdcp->dev, op->src, op->len,
+					      DMA_TO_DEVICE);
+		if (dma_mapping_error(sdcp->dev, op->src_phys)) {
+			dev_err(sdcp->dev, "Unable to map source\n");
+			err = -ENOMEM;
+			break;
+		}
+
+		op->dst_phys = dma_map_single(sdcp->dev, op->dst, op->len,
+					      DMA_FROM_DEVICE);
+		if (dma_mapping_error(sdcp->dev, op->dst_phys)) {
+			dma_unmap_single(sdcp->dev, op->src_phys, op->len,
+					 DMA_TO_DEVICE);
+			dev_err(sdcp->dev, "Unable to map dest\n");
+			err = -ENOMEM;
+			break;
+		}
+
+		/* perform! */
+		dcp_perform_op(op);
+
+		dma_unmap_single(sdcp->dev, op->dst_phys, op->len,
+				 DMA_FROM_DEVICE);
+		dma_unmap_single(sdcp->dev, op->src_phys, op->len,
+				 DMA_TO_DEVICE);
+
+		nbytes -= op->len;
+		err = blkcipher_walk_done(desc, &walk, nbytes);
+	}
+
+	dma_unmap_single(sdcp->dev, op->cipher.key_phys, AES_KEYSIZE_128,
+			 DMA_TO_DEVICE);
+
+	return err;
+}
+
+static int
+dcp_aes_ecb_encrypt(struct blkcipher_desc *desc,
+		    struct scatterlist *dst, struct scatterlist *src,
+		    unsigned int nbytes)
+{
+	struct dcp *sdcp = global_sdcp;
+	struct dcp_op *op = crypto_blkcipher_ctx(desc->tfm);
+	struct blkcipher_walk walk;
+	int err, ret;
+
+	if (unlikely(op->cipher.keylen != AES_KEYSIZE_128))
+		return fallback_blk_enc(desc, dst, src, nbytes);
+
+	blkcipher_walk_init(&walk, dst, src, nbytes);
+
+	/* key needs to be mapped only once */
+	op->cipher.key_phys = dma_map_single(sdcp->dev, op->cipher.key,
+					     AES_KEYSIZE_128, DMA_TO_DEVICE);
+	if (dma_mapping_error(sdcp->dev, op->cipher.key_phys)) {
+		dev_err(sdcp->dev, "Unable to map key\n");
+		return -ENOMEM;
+	}
+
+	err = blkcipher_walk_virt(desc, &walk);
+
+	err = 0;
+	while (err == 0 && (nbytes = walk.nbytes) > 0) {
+		op->src = walk.src.virt.addr, op->dst = walk.dst.virt.addr;
+		op->flags = DCP_AES | DCP_ENC | DCP_ECB;
+		op->len = nbytes - (nbytes % AES_KEYSIZE_128);
+
+		/* map the data */
+		op->src_phys = dma_map_single(sdcp->dev, op->src, op->len,
+					      DMA_TO_DEVICE);
+		if (dma_mapping_error(sdcp->dev, op->src_phys)) {
+			dev_err(sdcp->dev, "Unable to map source\n");
+			err = -ENOMEM;
+			break;
+		}
+
+		op->dst_phys = dma_map_single(sdcp->dev, op->dst, op->len,
+					      DMA_FROM_DEVICE);
+		if (dma_mapping_error(sdcp->dev, op->dst_phys)) {
+			dma_unmap_single(sdcp->dev, op->src_phys, op->len,
+					 DMA_TO_DEVICE);
+			dev_err(sdcp->dev, "Unable to map dest\n");
+			err = -ENOMEM;
+			break;
+		}
+
+		/* perform! */
+		dcp_perform_op(op);
+
+		dma_unmap_single(sdcp->dev, op->dst_phys, op->len,
+				 DMA_FROM_DEVICE);
+		dma_unmap_single(sdcp->dev, op->src_phys, op->len,
+				 DMA_TO_DEVICE);
+
+		nbytes -= op->len;
+		ret = blkcipher_walk_done(desc, &walk, nbytes);
+	}
+
+	dma_unmap_single(sdcp->dev, op->cipher.key_phys, AES_KEYSIZE_128,
+			 DMA_TO_DEVICE);
+
+	return err;
+}
+
+static struct crypto_alg dcp_aes_ecb_alg = {
+	.cra_name = "ecb(aes)",
+	.cra_driver_name = "dcp-ecb-aes",
+	.cra_priority = 400,
+	.cra_alignmask = 15,
+	.cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER | CRYPTO_ALG_NEED_FALLBACK,
+	.cra_init = fallback_init_blk,
+	.cra_exit = fallback_exit_blk,
+	.cra_blocksize = AES_KEYSIZE_128,
+	.cra_ctxsize = sizeof(struct dcp_op),
+	.cra_type = &crypto_blkcipher_type,
+	.cra_module = THIS_MODULE,
+	.cra_list = LIST_HEAD_INIT(dcp_aes_ecb_alg.cra_list),
+	.cra_u = {
+		  .blkcipher = {
+				.min_keysize = AES_MIN_KEY_SIZE,
+				.max_keysize = AES_MAX_KEY_SIZE,
+				.setkey = dcp_aes_setkey_blk,
+				.encrypt = dcp_aes_ecb_encrypt,
+				.decrypt = dcp_aes_ecb_decrypt}
+		  }
+};
+
+static int
+dcp_aes_cbc_decrypt(struct blkcipher_desc *desc,
+		    struct scatterlist *dst, struct scatterlist *src,
+		    unsigned int nbytes)
+{
+	struct dcp *sdcp = global_sdcp;
+	struct dcp_op *op = crypto_blkcipher_ctx(desc->tfm);
+	struct blkcipher_walk walk;
+	int err, blockno;
+
+	if (unlikely(op->cipher.keylen != AES_KEYSIZE_128))
+		return fallback_blk_dec(desc, dst, src, nbytes);
+
+	blkcipher_walk_init(&walk, dst, src, nbytes);
+
+	blockno = 0;
+	err = blkcipher_walk_virt(desc, &walk);
+	while (err == 0 && (nbytes = walk.nbytes) > 0) {
+		op->src = walk.src.virt.addr, op->dst = walk.dst.virt.addr;
+		op->flags = DCP_AES | DCP_DEC | DCP_CBC;
+		if (blockno == 0) {
+			op->flags |= DCP_CBC_INIT;
+			memcpy(op->cipher.key + AES_KEYSIZE_128, walk.iv,
+			       AES_KEYSIZE_128);
+		}
+		op->len = nbytes - (nbytes % AES_KEYSIZE_128);
+
+		/* key (+iv) needs to be mapped only once */
+		op->cipher.key_phys = dma_map_single(sdcp->dev, op->cipher.key,
+						     AES_KEYSIZE_128 * 2,
+						     DMA_BIDIRECTIONAL);
+		if (dma_mapping_error(sdcp->dev, op->cipher.key_phys)) {
+			dev_err(sdcp->dev, "Unable to map key\n");
+			err = -ENOMEM;
+			break;
+		}
+
+		/* map the data */
+		op->src_phys = dma_map_single(sdcp->dev, op->src, op->len,
+					      DMA_TO_DEVICE);
+		if (dma_mapping_error(sdcp->dev, op->src_phys)) {
+			dma_unmap_single(sdcp->dev, op->cipher.key_phys,
+					 AES_KEYSIZE_128 * 2,
+					 DMA_BIDIRECTIONAL);
+			dev_err(sdcp->dev, "Unable to map source\n");
+			err = -ENOMEM;
+			break;
+		}
+
+		op->dst_phys = dma_map_single(sdcp->dev, op->dst, op->len,
+					      DMA_FROM_DEVICE);
+		if (dma_mapping_error(sdcp->dev, op->dst_phys)) {
+			dma_unmap_single(sdcp->dev, op->cipher.key_phys,
+					 AES_KEYSIZE_128 * 2,
+					 DMA_BIDIRECTIONAL);
+			dma_unmap_single(sdcp->dev, op->src_phys, op->len,
+					 DMA_TO_DEVICE);
+			dev_err(sdcp->dev, "Unable to map dest\n");
+			err = -ENOMEM;
+			break;
+		}
+
+		/* perform! */
+		dcp_perform_op(op);
+
+		dma_unmap_single(sdcp->dev, op->cipher.key_phys,
+				 AES_KEYSIZE_128 * 2, DMA_BIDIRECTIONAL);
+		dma_unmap_single(sdcp->dev, op->dst_phys, op->len,
+				 DMA_FROM_DEVICE);
+		dma_unmap_single(sdcp->dev, op->src_phys, op->len,
+				 DMA_TO_DEVICE);
+
+		nbytes -= op->len;
+		err = blkcipher_walk_done(desc, &walk, nbytes);
+
+		blockno++;
+	}
+
+	return err;
+}
+
+static int
+dcp_aes_cbc_encrypt(struct blkcipher_desc *desc,
+		    struct scatterlist *dst, struct scatterlist *src,
+		    unsigned int nbytes)
+{
+	struct dcp *sdcp = global_sdcp;
+	struct dcp_op *op = crypto_blkcipher_ctx(desc->tfm);
+	struct blkcipher_walk walk;
+	int err, ret, blockno;
+
+	if (unlikely(op->cipher.keylen != AES_KEYSIZE_128))
+		return fallback_blk_enc(desc, dst, src, nbytes);
+
+	blkcipher_walk_init(&walk, dst, src, nbytes);
+
+	blockno = 0;
+
+	err = blkcipher_walk_virt(desc, &walk);
+	while (err == 0 && (nbytes = walk.nbytes) > 0) {
+		op->src = walk.src.virt.addr, op->dst = walk.dst.virt.addr;
+		op->flags = DCP_AES | DCP_ENC | DCP_CBC;
+		if (blockno == 0) {
+			op->flags |= DCP_CBC_INIT;
+			memcpy(op->cipher.key + AES_KEYSIZE_128, walk.iv,
+			       AES_KEYSIZE_128);
+		}
+		op->len = nbytes - (nbytes % AES_KEYSIZE_128);
+
+		/* key needs to be mapped only once */
+		op->cipher.key_phys = dma_map_single(sdcp->dev, op->cipher.key,
+						     AES_KEYSIZE_128 * 2,
+						     DMA_BIDIRECTIONAL);
+		if (dma_mapping_error(sdcp->dev, op->cipher.key_phys)) {
+			dev_err(sdcp->dev, "Unable to map key\n");
+			return -ENOMEM;
+		}
+
+		/* map the data */
+		op->src_phys = dma_map_single(sdcp->dev, op->src, op->len,
+					      DMA_TO_DEVICE);
+		if (dma_mapping_error(sdcp->dev, op->src_phys)) {
+			dma_unmap_single(sdcp->dev, op->cipher.key_phys,
+					 AES_KEYSIZE_128 * 2,
+					 DMA_BIDIRECTIONAL);
+			dev_err(sdcp->dev, "Unable to map source\n");
+			err = -ENOMEM;
+			break;
+		}
+
+		op->dst_phys = dma_map_single(sdcp->dev, op->dst, op->len,
+					      DMA_FROM_DEVICE);
+		if (dma_mapping_error(sdcp->dev, op->dst_phys)) {
+			dma_unmap_single(sdcp->dev, op->cipher.key_phys,
+					 AES_KEYSIZE_128 * 2,
+					 DMA_BIDIRECTIONAL);
+			dma_unmap_single(sdcp->dev, op->src_phys, op->len,
+					 DMA_TO_DEVICE);
+			dev_err(sdcp->dev, "Unable to map dest\n");
+			err = -ENOMEM;
+			break;
+		}
+
+		/* perform! */
+		dcp_perform_op(op);
+
+		dma_unmap_single(sdcp->dev, op->cipher.key_phys,
+				 AES_KEYSIZE_128 * 2, DMA_BIDIRECTIONAL);
+		dma_unmap_single(sdcp->dev, op->dst_phys, op->len,
+				 DMA_FROM_DEVICE);
+		dma_unmap_single(sdcp->dev, op->src_phys, op->len,
+				 DMA_TO_DEVICE);
+
+		nbytes -= op->len;
+		ret = blkcipher_walk_done(desc, &walk, nbytes);
+
+		blockno++;
+	}
+
+	return err;
+}
+
+static struct crypto_alg dcp_aes_cbc_alg = {
+	.cra_name = "cbc(aes)",
+	.cra_driver_name = "dcp-cbc-aes",
+	.cra_priority = 400,
+	.cra_alignmask = 15,
+	.cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER | CRYPTO_ALG_NEED_FALLBACK,
+	.cra_init = fallback_init_blk,
+	.cra_exit = fallback_exit_blk,
+	.cra_blocksize = AES_KEYSIZE_128,
+	.cra_ctxsize = sizeof(struct dcp_op),
+	.cra_type = &crypto_blkcipher_type,
+	.cra_module = THIS_MODULE,
+	.cra_list = LIST_HEAD_INIT(dcp_aes_cbc_alg.cra_list),
+	.cra_u = {
+		  .blkcipher = {
+				.min_keysize = AES_MIN_KEY_SIZE,
+				.max_keysize = AES_MAX_KEY_SIZE,
+				.setkey = dcp_aes_setkey_blk,
+				.encrypt = dcp_aes_cbc_encrypt,
+				.decrypt = dcp_aes_cbc_decrypt,
+				.ivsize = AES_KEYSIZE_128,
+				}
+		  }
+};
+
+static int dcp_perform_hash_op(struct dcp_hash_coherent_block *input,
+			       u32 num_desc, bool init, bool terminate)
+{
+	struct dcp *sdcp = global_sdcp;
+	int chan;
+	struct dcp_hw_packet *pkt;
+	struct dcp_hash_coherent_block *hw;
+	unsigned long timeout;
+	u32 stat;
+	int descno, mapped;
+
+	chan = HASH_CHAN;
+
+	hw = input;
+	pkt = hw->pkt;
+
+	for (descno = 0; descno < num_desc; descno++) {
+
+		if (descno != 0) {
+
+			/* set next ptr and CHAIN bit in last packet */
+			pkt->next = hw->next->my_phys
+			+ offsetof(struct dcp_hash_coherent_block, pkt[0]);
+			pkt->pkt1 |= BM_DCP_PACKET1_CHAIN;
+
+			/* iterate to next descriptor */
+			hw = hw->next;
+			pkt = hw->pkt;
+		}
+
+		pkt->pkt1 = BM_DCP_PACKET1_DECR_SEMAPHORE |
+		    BM_DCP_PACKET1_ENABLE_HASH;
+
+		if (init && descno == 0)
+			pkt->pkt1 |= BM_DCP_PACKET1_HASH_INIT;
+
+		pkt->pkt2 = BF(hw->hash_sel, DCP_PACKET2_HASH_SELECT);
+
+		/* no need to flush buf1 or buf2, which are uncached */
+		if (hw->src != sdcp->buf1 && hw->src != sdcp->buf2) {
+
+			/* we have to flush the cache for the buffer */
+			hw->src_phys = dma_map_single(sdcp->dev,
+						      hw->src, hw->len,
+						      DMA_TO_DEVICE);
+
+			if (dma_mapping_error(sdcp->dev, hw->src_phys)) {
+				dev_err(sdcp->dev, "Unable to map source\n");
+
+				/* unmap any previous mapped buffers */
+				for (mapped = 0, hw = input; mapped < descno;
+				     mapped++) {
+
+					if (mapped != 0)
+						hw = hw->next;
+					if (hw->src != sdcp->buf1 &&
+					    hw->src != sdcp->buf2)
+						dma_unmap_single(sdcp->dev,
+								 hw->src_phys,
+								 hw->len,
+								 DMA_TO_DEVICE);
+				}
+
+				return -EFAULT;
+			}
+		}
+
+		pkt->src = (u32) hw->src_phys;
+		pkt->dst = 0;
+		pkt->size = hw->len;
+		pkt->payload = 0;
+		pkt->stat = 0;
+
+		/* set HASH_TERM bit on last buf if terminate was set */
+		if (terminate && (descno == (num_desc - 1))) {
+			pkt->pkt1 |= BM_DCP_PACKET1_HASH_TERM;
+
+			memset(input->digest, 0, sizeof(input->digest));
+
+			/* set payload ptr to the 1st buffer's digest */
+			pkt->payload = (u32) input->my_phys +
+			    offsetof(struct dcp_hash_coherent_block, digest);
+		}
+	}
+
+	/* submit the work */
+	__raw_writel(-1, (void *)(sdcp->dcp_regs_base
+					+ HW_DCP_CH_N_STAT_CLR(chan)));
+
+	mb();
+	/* Load the 1st descriptor's physical address */
+	__raw_writel((u32) input->my_phys
+			+ offsetof(struct dcp_hash_coherent_block, pkt[0]),
+			(void *)(sdcp->dcp_regs_base
+			+ HW_DCP_CH_N_CMDPTR(chan)));
+
+	/* XXX wake from interrupt instead of looping */
+	timeout = jiffies + msecs_to_jiffies(1000);
+
+	/* write num_desc into sema register */
+	__raw_writel(BF(num_desc, DCP_CH_N_SEMA_INCREMENT),
+			(void *)(sdcp->dcp_regs_base + HW_DCP_CH_N_SEMA(chan)));
+
+	while (time_before(jiffies, timeout)
+		&& (__raw_readl((void *)(sdcp->dcp_regs_base
+			+ ((HW_DCP_CH_N_SEMA(chan) >> 16) & 0xff))) != 0)) {
+		cpu_relax();
+	}
+
+	if (!time_before(jiffies, timeout)) {
+		dev_err(sdcp->dev, "Timeout while waiting STAT 0x%08x\n",
+			__raw_readl((void *)(sdcp->dcp_regs_base
+						+ HW_DCP_STAT)));
+	}
+
+	stat =
+	    __raw_readl((void *)(sdcp->dcp_regs_base + HW_DCP_CH_N_STAT(chan)));
+	if ((stat & 0xff) != 0) {
+		dev_err(sdcp->dev, "Channel stat error 0x%02x\n",
+				__raw_readl((void *)(sdcp->dcp_regs_base
+					+ (HW_DCP_CH_N_STAT(chan) & 0xff))));
+	}
+
+	/* unmap all src buffers */
+	for (descno = 0, hw = input; descno < num_desc; descno++) {
+		if (descno != 0)
+			hw = hw->next;
+
+		if (hw->src != sdcp->buf1 && hw->src != sdcp->buf2) {
+			dma_unmap_single(sdcp->dev, hw->src_phys,
+					hw->len, DMA_TO_DEVICE);
+		}
+	}
+
+	return 0;
+
+}
+
+static int dcp_sha_init(struct shash_desc *desc)
+{
+	struct dcp *sdcp = global_sdcp;
+	struct dcp_hash_op *op = shash_desc_ctx(desc);
+	struct mutex *mutex = &sdcp->op_mutex[HASH_CHAN];
+
+	mutex_lock(mutex);
+	dcp_clock(sdcp, CLOCK_ON, false);
+	sdcp->chan_in_use[HASH_CHAN] = true;
+
+	op->length = 0;
+
+	/* reset the lengths and the pointers of buffer descriptors */
+	sdcp->buf1_desc->len = 0;
+	sdcp->buf1_desc->src = sdcp->buf1;
+	sdcp->buf2_desc->len = 0;
+	sdcp->buf2_desc->src = sdcp->buf2;
+	op->head_desc = sdcp->buf1_desc;
+	op->tail_desc = sdcp->buf2_desc;
+
+	return 0;
+}
+
+static int dcp_sha_update(struct shash_desc *desc, const u8 *data,
+			  unsigned int length)
+{
+	struct dcp *sdcp = global_sdcp;
+	struct dcp_hash_op *op = shash_desc_ctx(desc);
+	struct dcp_hash_coherent_block *temp;
+	u32 rem_bytes, bytes_borrowed, hash_sel;
+	int ret = 0;
+
+	if (strcmp(desc->tfm->base.__crt_alg->cra_name, "sha1") == 0)
+		hash_sel = BV_DCP_PACKET2_HASH_SELECT__SHA1;
+	else
+		hash_sel = BV_DCP_PACKET2_HASH_SELECT__SHA256;
+
+	sdcp->user_buf_desc->src = (void *)data;
+	sdcp->user_buf_desc->len = length;
+
+	op->tail_desc->len = 0;
+
+	/* check if any pending data from previous updates */
+	if (op->head_desc->len) {
+
+		/* borrow from this buffer to make it 64 bytes */
+		bytes_borrowed = min(64 - op->head_desc->len,
+				     sdcp->user_buf_desc->len);
+
+		/* copy n bytes to head */
+		memcpy(op->head_desc->src + op->head_desc->len,
+		       sdcp->user_buf_desc->src, bytes_borrowed);
+		op->head_desc->len += bytes_borrowed;
+
+		/* update current buffer's src and len */
+		sdcp->user_buf_desc->src += bytes_borrowed;
+		sdcp->user_buf_desc->len -= bytes_borrowed;
+	}
+
+	/* Is current buffer unaligned to 64 byte length?
+	 * Each buffer's length must be a multiple of 64 bytes for DCP
+	 */
+	rem_bytes = sdcp->user_buf_desc->len % 64;
+
+	/* if length is unaligned, copy remainder to tail */
+	if (rem_bytes) {
+
+		memcpy(op->tail_desc->src, (sdcp->user_buf_desc->src +
+					    sdcp->user_buf_desc->len -
+					    rem_bytes), rem_bytes);
+
+		/* update length of current buffer */
+		sdcp->user_buf_desc->len -= rem_bytes;
+
+		op->tail_desc->len = rem_bytes;
+	}
+
+	/* do not send to DCP if length is < 64 */
+	if ((op->head_desc->len + sdcp->user_buf_desc->len) >= 64) {
+
+		/* set hash alg to be used (SHA1 or SHA256) */
+		op->head_desc->hash_sel = hash_sel;
+		sdcp->user_buf_desc->hash_sel = hash_sel;
+
+		if (op->head_desc->len) {
+			op->head_desc->next = sdcp->user_buf_desc;
+
+			ret = dcp_perform_hash_op(op->head_desc,
+						  sdcp->user_buf_desc->
+						  len ? 2 : 1, op->length == 0,
+						  false);
+		} else {
+			ret = dcp_perform_hash_op(sdcp->user_buf_desc, 1,
+						  op->length == 0, false);
+		}
+
+		op->length += op->head_desc->len + sdcp->user_buf_desc->len;
+		op->head_desc->len = 0;
+	}
+
+	/* if tail has bytes, make it the head for next time */
+	if (op->tail_desc->len) {
+		temp = op->head_desc;
+		op->head_desc = op->tail_desc;
+		op->tail_desc = temp;
+	}
+
+	/* hash_sel to be used by final function */
+	op->head_desc->hash_sel = hash_sel;
+
+	return ret;
+}
+
+static int dcp_sha_final(struct shash_desc *desc, u8 *out)
+{
+	struct dcp_hash_op *op = shash_desc_ctx(desc);
+	const uint8_t *digest;
+	struct dcp *sdcp = global_sdcp;
+	u32 i, digest_len;
+	struct mutex *mutex = &sdcp->op_mutex[HASH_CHAN];
+	int ret = 0;
+
+	/* Send the leftover bytes in head, which can be length 0,
+	 * but DCP still produces hash result in payload ptr.
+	 * Last data bytes need not be 64-byte multiple.
+	 */
+	ret = dcp_perform_hash_op(op->head_desc, 1, op->length == 0, true);
+
+	op->length += op->head_desc->len;
+
+	digest_len = (op->head_desc->hash_sel ==
+		      BV_DCP_PACKET2_HASH_SELECT__SHA1) ? SHA1_DIGEST_SIZE :
+	    SHA256_DIGEST_SIZE;
+
+	/* hardware reverses the digest (for some unexplicable reason) */
+	digest = op->head_desc->digest + digest_len;
+	for (i = 0; i < digest_len; i++)
+		*out++ = *--digest;
+
+	sdcp->chan_in_use[HASH_CHAN] = false;
+	dcp_clock(sdcp, CLOCK_OFF, false);
+	mutex_unlock(mutex);
+
+	return ret;
+}
+
+static struct shash_alg dcp_sha1_alg = {
+	.init = dcp_sha_init,
+	.update = dcp_sha_update,
+	.final = dcp_sha_final,
+	.descsize = sizeof(struct dcp_hash_op),
+	.digestsize = SHA1_DIGEST_SIZE,
+	.base = {
+		 .cra_name = "sha1",
+		 .cra_driver_name = "sha1-dcp",
+		 .cra_priority = 300,
+		 .cra_blocksize = SHA1_BLOCK_SIZE,
+		 .cra_ctxsize = sizeof(struct dcp_hash_op),
+		 .cra_module = THIS_MODULE,
+		 }
+};
+
+static struct shash_alg dcp_sha256_alg = {
+	.init = dcp_sha_init,
+	.update = dcp_sha_update,
+	.final = dcp_sha_final,
+	.descsize = sizeof(struct dcp_hash_op),
+	.digestsize = SHA256_DIGEST_SIZE,
+	.base = {
+		 .cra_name = "sha256",
+		 .cra_driver_name = "sha256-dcp",
+		 .cra_priority = 300,
+		 .cra_blocksize = SHA256_BLOCK_SIZE,
+		 .cra_ctxsize = sizeof(struct dcp_hash_op),
+		 .cra_module = THIS_MODULE,
+		 }
+};
+
+static irqreturn_t dcp_common_irq(int irq, void *context)
+{
+	struct dcp *sdcp = context;
+	u32 msk;
+
+	/* check */
+	msk =  __raw_readl((void *)(sdcp->dcp_regs_base + HW_DCP_STAT))
+					& BF(0x0f, DCP_STAT_IRQ);
+	if (msk == 0)
+		return IRQ_NONE;
+
+	/* clear this channel */
+	__raw_writel(msk, (void *)(sdcp->dcp_regs_base + HW_DCP_STAT_CLR));
+	if (msk & BF(0x01, DCP_STAT_IRQ))
+		sdcp->wait[0]++;
+	if (msk & BF(0x02, DCP_STAT_IRQ))
+		sdcp->wait[1]++;
+	if (msk & BF(0x04, DCP_STAT_IRQ))
+		sdcp->wait[2]++;
+	if (msk & BF(0x08, DCP_STAT_IRQ))
+		sdcp->wait[3]++;
+
+	return IRQ_HANDLED;
+}
+
+static irqreturn_t dcp_vmi_irq(int irq, void *context)
+{
+	return dcp_common_irq(irq, context);
+}
+
+static irqreturn_t dcp_irq(int irq, void *context)
+{
+	return dcp_common_irq(irq, context);
+}
+
+/* DCP bootstream verification interface: uses OTP key for crypto */
+static long dcp_bootstream_ioctl(struct file *file, unsigned int cmd,
+				 unsigned long arg)
+{
+	struct dcp *sdcp = global_sdcp;
+	struct dcpboot_dma_area *da = sdcp->dcpboot_dma_area;
+	void __user *argp = (void __user *)arg;
+	int chan = ROM_DCP_CHAN;
+	unsigned long timeout;
+	struct mutex *mutex;
+	int retval;
+
+	/* be paranoid */
+	if (sdcp == NULL)
+		return -EBADF;
+
+	if (cmd != DBS_ENC && cmd != DBS_DEC)
+		return -EINVAL;
+
+	/* copy to (aligned) block */
+	if (copy_from_user(da->block, argp, 16))
+		return -EFAULT;
+
+	mutex = &sdcp->op_mutex[chan];
+	mutex_lock(mutex);
+	dcp_clock(sdcp, CLOCK_ON, false);
+	sdcp->chan_in_use[chan] = true;
+
+	__raw_writel(-1, (void *)(sdcp->dcp_regs_base
+					+ HW_DCP_CH_N_STAT_CLR(ROM_DCP_CHAN)));
+	__raw_writel(BF(ROM_DCP_CHAN_MASK, DCP_STAT_IRQ),
+			(void *)(sdcp->dcp_regs_base + HW_DCP_STAT_CLR));
+
+	da->hw_packet.next = 0;
+	da->hw_packet.pkt1 = BM_DCP_PACKET1_DECR_SEMAPHORE |
+	    BM_DCP_PACKET1_ENABLE_CIPHER | BM_DCP_PACKET1_OTP_KEY |
+	    BM_DCP_PACKET1_INTERRUPT |
+	    (cmd == DBS_ENC ? BM_DCP_PACKET1_CIPHER_ENCRYPT : 0);
+	da->hw_packet.pkt2 = BF(0, DCP_PACKET2_CIPHER_CFG) |
+	    BF(0, DCP_PACKET2_KEY_SELECT) |
+	    BF(BV_DCP_PACKET2_CIPHER_MODE__ECB, DCP_PACKET2_CIPHER_MODE) |
+	    BF(BV_DCP_PACKET2_CIPHER_SELECT__AES128, DCP_PACKET2_CIPHER_SELECT);
+	da->hw_packet.src = sdcp->dcpboot_dma_area_phys +
+	    offsetof(struct dcpboot_dma_area, block);
+	da->hw_packet.dst = da->hw_packet.src;	/* in-place */
+	da->hw_packet.size = 16;
+	da->hw_packet.payload = 0;
+	da->hw_packet.stat = 0;
+
+	/* Load the work packet pointer and bump the channel semaphore */
+	__raw_writel(sdcp->dcpboot_dma_area_phys
+			+ offsetof(struct dcpboot_dma_area, hw_packet),
+			(void *)(sdcp->dcp_regs_base
+			+ HW_DCP_CH_N_CMDPTR(ROM_DCP_CHAN)));
+
+	sdcp->wait[chan] = 0;
+	__raw_writel(BF(1, DCP_CH_N_SEMA_INCREMENT),
+			(void *)(sdcp->dcp_regs_base
+			+ HW_DCP_CH_N_SEMA(ROM_DCP_CHAN)));
+
+	timeout = jiffies + msecs_to_jiffies(100);
+
+	while (time_before(jiffies, timeout) && sdcp->wait[chan] == 0)
+		cpu_relax();
+
+	if (!time_before(jiffies, timeout)) {
+		dev_err(sdcp->dev,
+			"Timeout while waiting for operation to complete\n");
+		retval = -ETIMEDOUT;
+		goto exit;
+	}
+
+	if (__raw_readl((void *)(sdcp->dcp_regs_base
+			+ (HW_DCP_CH_N_STAT(ROM_DCP_CHAN) & 0xff))) != 0) {
+		dev_err(sdcp->dev, "Channel stat error 0x%02x\n",
+			__raw_readl((void *)(sdcp->dcp_regs_base
+				+ (HW_DCP_CH_N_STAT(ROM_DCP_CHAN) & 0xff))));
+		retval = -EFAULT;
+		goto exit;
+	}
+
+	if (copy_to_user(argp, da->block, 16)) {
+		retval = -EFAULT;
+		goto exit;
+	}
+
+	retval = 0;
+
+ exit:
+	sdcp->chan_in_use[chan] = false;
+	dcp_clock(sdcp, CLOCK_OFF, false);
+	mutex_unlock(mutex);
+	return retval;
+}
+
+static const struct file_operations dcp_bootstream_fops = {
+	.owner = THIS_MODULE,
+	.unlocked_ioctl = dcp_bootstream_ioctl,
+};
+
+static struct miscdevice dcp_bootstream_misc = {
+	.minor = MISC_DYNAMIC_MINOR,
+	.name = "dcpboot",
+	.fops = &dcp_bootstream_fops,
+};
+
+static int dcp_probe(struct platform_device *pdev)
+{
+	struct dcp *sdcp = NULL;
+	struct resource *r;
+	int i, ret;
+	dma_addr_t hw_phys;
+
+	if (global_sdcp != NULL) {
+		dev_err(&pdev->dev, "Only one instance allowed\n");
+		ret = -ENODEV;
+		goto err;
+	}
+
+	/* allocate memory */
+	sdcp = kzalloc(sizeof(*sdcp), GFP_KERNEL);
+	if (sdcp == NULL) {
+		dev_err(&pdev->dev, "Failed to allocate structure\n");
+		ret = -ENOMEM;
+		goto err;
+	}
+
+	sdcp->dev = &pdev->dev;
+	spin_lock_init(&sdcp->lock);
+
+	for (i = 0; i < DCP_NUM_CHANNELS; i++) {
+		mutex_init(&sdcp->op_mutex[i]);
+		init_completion(&sdcp->op_wait[i]);
+		sdcp->chan_in_use[i] = false;
+	}
+
+	platform_set_drvdata(pdev, sdcp);
+
+	r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	if (!r) {
+		dev_err(&pdev->dev, "failed to get IORESOURCE_MEM\n");
+		ret = -ENXIO;
+		goto err_kfree;
+	}
+	sdcp->dcp_regs_base = (u32) ioremap(r->start, r->end - r->start + 1);
+	dcp_clock(sdcp, CLOCK_ON, true);
+
+	/* Soft reset and remove the clock gate */
+	__raw_writel(BM_DCP_CTRL_SFTRST, (void *)(sdcp->dcp_regs_base
+							+ HW_DCP_CTRL_SET));
+
+	/* At 24Mhz, it takes no more than 4 clocks (160 ns) Maximum for
+	 * the part to reset, reading the register twice should
+	 * be sufficient to get 4 clks delay.
+	 */
+	__raw_readl((void *)(sdcp->dcp_regs_base + HW_DCP_CTRL));
+	__raw_readl((void *)(sdcp->dcp_regs_base + HW_DCP_CTRL));
+
+	__raw_writel(BM_DCP_CTRL_SFTRST | BM_DCP_CTRL_CLKGATE,
+			(void *)(sdcp->dcp_regs_base + HW_DCP_CTRL_CLR));
+
+	/* Initialize control registers */
+	__raw_writel(DCP_CTRL_INIT, (void *)(sdcp->dcp_regs_base
+							+ HW_DCP_CTRL));
+	__raw_writel(DCP_CHANNELCTRL_INIT,
+			(void *)(sdcp->dcp_regs_base + HW_DCP_CHANNELCTRL));
+
+	/* We do not enable context switching. Give the context
+	 * buffer pointer an illegal address so if context switching is
+	 * inadvertantly enabled, the dcp will return an error instead of
+	 * trashing good memory. The dcp dma cannot access rom, so any rom
+	 * address will do.
+	 */
+	__raw_writel(0xFFFF0000, (void *)(sdcp->dcp_regs_base
+						+ HW_DCP_CONTEXT));
+
+	for (i = 0; i < DCP_NUM_CHANNELS; i++) {
+		__raw_writel(-1, (void *)(sdcp->dcp_regs_base
+					+ HW_DCP_CH_N_STAT_CLR(i)));
+	}
+	__raw_writel(-1, (void *)(sdcp->dcp_regs_base + HW_DCP_STAT_CLR));
+
+	r = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
+	if (!r) {
+		dev_err(&pdev->dev, "can't get IRQ resource (0)\n");
+		ret = -EIO;
+		goto err_gate_clk;
+	}
+	sdcp->dcp_vmi_irq = r->start;
+	ret = request_irq(sdcp->dcp_vmi_irq, dcp_vmi_irq, 0, "dcp", sdcp);
+	if (ret != 0) {
+		dev_err(&pdev->dev, "can't request_irq (0)\n");
+		goto err_gate_clk;
+	}
+
+	r = platform_get_resource(pdev, IORESOURCE_IRQ, 1);
+	if (!r) {
+		dev_err(&pdev->dev, "can't get IRQ resource (1)\n");
+		ret = -EIO;
+		goto err_free_irq0;
+	}
+	sdcp->dcp_irq = r->start;
+	ret = request_irq(sdcp->dcp_irq, dcp_irq, 0, "dcp", sdcp);
+	if (ret != 0) {
+		dev_err(&pdev->dev, "can't request_irq (1)\n");
+		goto err_free_irq0;
+	}
+
+	global_sdcp = sdcp;
+
+	ret = crypto_register_alg(&dcp_aes_alg);
+	if (ret != 0) {
+		dev_err(&pdev->dev, "Failed to register aes crypto\n");
+		goto err_free_irq1;
+	}
+
+	ret = crypto_register_alg(&dcp_aes_ecb_alg);
+	if (ret != 0) {
+		dev_err(&pdev->dev, "Failed to register aes ecb crypto\n");
+		goto err_unregister_aes;
+	}
+
+	ret = crypto_register_alg(&dcp_aes_cbc_alg);
+	if (ret != 0) {
+		dev_err(&pdev->dev, "Failed to register aes cbc crypto\n");
+		goto err_unregister_aes_ecb;
+	}
+
+	/* Allocate the descriptor to be used for user buffer
+	 * passed in by the "update" function from Crypto API
+	 */
+	sdcp->user_buf_desc = dma_alloc_coherent(sdcp->dev,
+						sizeof(
+						struct dcp_hash_coherent_block),
+						&hw_phys, GFP_KERNEL);
+	if (sdcp->user_buf_desc == NULL) {
+		dev_err(&pdev->dev, "Error allocating coherent block\n");
+		ret = -ENOMEM;
+		goto err_unregister_aes_cbc;
+	}
+
+	sdcp->user_buf_desc->my_phys = hw_phys;
+
+	/* Allocate 2 buffers (head & tail) & its descriptors to deal with
+	 * buffer lengths that are not 64 byte aligned, except for the
+	 * last one.
+	 */
+	sdcp->buf1 = dma_alloc_coherent(sdcp->dev,
+					64, &sdcp->buf1_phys, GFP_KERNEL);
+	if (sdcp->buf1 == NULL) {
+		dev_err(&pdev->dev, "Error allocating coherent block\n");
+		ret = -ENOMEM;
+		goto err_unregister_aes_cbc;
+	}
+
+	sdcp->buf2 = dma_alloc_coherent(sdcp->dev,
+					64, &sdcp->buf2_phys, GFP_KERNEL);
+	if (sdcp->buf2 == NULL) {
+		dev_err(&pdev->dev, "Error allocating coherent block\n");
+		ret = -ENOMEM;
+		goto err_unregister_aes_cbc;
+	}
+
+	sdcp->buf1_desc = dma_alloc_coherent(sdcp->dev,
+					     sizeof(struct
+						    dcp_hash_coherent_block),
+					     &hw_phys, GFP_KERNEL);
+	if (sdcp->buf1_desc == NULL) {
+		dev_err(&pdev->dev, "Error allocating coherent block\n");
+		ret = -ENOMEM;
+		goto err_unregister_aes_cbc;
+	}
+
+	sdcp->buf1_desc->my_phys = hw_phys;
+	sdcp->buf1_desc->src = (void *)sdcp->buf1;
+	sdcp->buf1_desc->src_phys = sdcp->buf1_phys;
+
+	sdcp->buf2_desc = dma_alloc_coherent(sdcp->dev,
+					     sizeof(struct
+						    dcp_hash_coherent_block),
+					     &hw_phys, GFP_KERNEL);
+	if (sdcp->buf2_desc == NULL) {
+		dev_err(&pdev->dev, "Error allocating coherent block\n");
+		ret = -ENOMEM;
+		goto err_unregister_aes_cbc;
+	}
+
+	sdcp->buf2_desc->my_phys = hw_phys;
+	sdcp->buf2_desc->src = (void *)sdcp->buf2;
+	sdcp->buf2_desc->src_phys = sdcp->buf2_phys;
+
+	ret = crypto_register_shash(&dcp_sha1_alg);
+	if (ret != 0) {
+		dev_err(&pdev->dev, "Failed to register sha1 hash\n");
+		goto err_unregister_aes_cbc;
+	}
+
+	if (__raw_readl((void *)(sdcp->dcp_regs_base +
+			       HW_DCP_CAPABILITY1)) &
+	    BF_DCP_CAPABILITY1_HASH_ALGORITHMS
+	    (BV_DCP_CAPABILITY1_HASH_ALGORITHMS__SHA256)) {
+
+		ret = crypto_register_shash(&dcp_sha256_alg);
+		if (ret != 0) {
+			dev_err(&pdev->dev, "Failed to register sha256 hash\n");
+			goto err_unregister_sha1;
+		}
+	}
+
+	/* register dcpboot interface to allow apps (such as kobs-ng) to
+	 * verify files (such as the bootstream) using the OTP key for crypto */
+	ret = misc_register(&dcp_bootstream_misc);
+	if (ret != 0) {
+		dev_err(&pdev->dev, "Unable to register misc device\n");
+		goto err_unregister_sha1;
+	}
+
+	sdcp->dcpboot_dma_area = dma_alloc_coherent(&pdev->dev,
+						    sizeof(*sdcp->
+							   dcpboot_dma_area),
+						    &sdcp->
+						    dcpboot_dma_area_phys,
+						    GFP_KERNEL);
+	if (sdcp->dcpboot_dma_area == NULL) {
+		dev_err(&pdev->dev,
+		"Unable to allocate DMAable memory for dcpboot interface\n");
+		goto err_dereg;
+	}
+
+	dcp_clock(sdcp, CLOCK_OFF, false);
+	dev_notice(&pdev->dev, "DCP crypto enabled.!\n");
+	return 0;
+
+ err_dereg:
+	misc_deregister(&dcp_bootstream_misc);
+ err_unregister_sha1:
+	crypto_unregister_shash(&dcp_sha1_alg);
+ err_unregister_aes_cbc:
+	crypto_unregister_alg(&dcp_aes_cbc_alg);
+ err_unregister_aes_ecb:
+	crypto_unregister_alg(&dcp_aes_ecb_alg);
+ err_unregister_aes:
+	crypto_unregister_alg(&dcp_aes_alg);
+ err_free_irq1:
+	free_irq(sdcp->dcp_irq, sdcp);
+ err_free_irq0:
+	free_irq(sdcp->dcp_vmi_irq, sdcp);
+ err_gate_clk:
+	dcp_clock(sdcp, CLOCK_OFF, false);
+ err_kfree:
+	kfree(sdcp);
+ err:
+
+	return ret;
+}
+
+static int dcp_remove(struct platform_device *pdev)
+{
+	struct dcp *sdcp;
+
+	sdcp = platform_get_drvdata(pdev);
+	platform_set_drvdata(pdev, NULL);
+
+	dcp_clock(sdcp, CLOCK_ON, false);
+
+	free_irq(sdcp->dcp_irq, sdcp);
+	free_irq(sdcp->dcp_vmi_irq, sdcp);
+
+	/* if head and tail buffers were allocated, free them */
+	if (sdcp->buf1) {
+		dma_free_coherent(sdcp->dev, 64, sdcp->buf1, sdcp->buf1_phys);
+		dma_free_coherent(sdcp->dev, 64, sdcp->buf2, sdcp->buf2_phys);
+
+		dma_free_coherent(sdcp->dev,
+				  sizeof(struct dcp_hash_coherent_block),
+				  sdcp->buf1_desc, sdcp->buf1_desc->my_phys);
+
+		dma_free_coherent(sdcp->dev,
+				  sizeof(struct dcp_hash_coherent_block),
+				  sdcp->buf2_desc, sdcp->buf2_desc->my_phys);
+
+		dma_free_coherent(sdcp->dev,
+				  sizeof(struct dcp_hash_coherent_block),
+				  sdcp->user_buf_desc,
+				  sdcp->user_buf_desc->my_phys);
+	}
+
+	if (sdcp->dcpboot_dma_area) {
+		dma_free_coherent(&pdev->dev, sizeof(*sdcp->dcpboot_dma_area),
+				  sdcp->dcpboot_dma_area,
+				  sdcp->dcpboot_dma_area_phys);
+		misc_deregister(&dcp_bootstream_misc);
+	}
+
+	crypto_unregister_shash(&dcp_sha1_alg);
+
+	if (__raw_readl((void *)(sdcp->dcp_regs_base + HW_DCP_CAPABILITY1))
+				& BF_DCP_CAPABILITY1_HASH_ALGORITHMS(
+				BV_DCP_CAPABILITY1_HASH_ALGORITHMS__SHA256)) {
+		crypto_unregister_shash(&dcp_sha256_alg);
+	}
+
+	crypto_unregister_alg(&dcp_aes_cbc_alg);
+	crypto_unregister_alg(&dcp_aes_ecb_alg);
+	crypto_unregister_alg(&dcp_aes_alg);
+
+	dcp_clock(sdcp, CLOCK_OFF, true);
+	iounmap((void *)sdcp->dcp_regs_base);
+	kfree(sdcp);
+	global_sdcp = NULL;
+
+	return 0;
+}
+
+static int dcp_suspend(struct platform_device *pdev, pm_message_t state)
+{
+#ifdef CONFIG_PM
+	struct dcp *sdcp = platform_get_drvdata(pdev);
+
+	if (sdcp->clock_state == CLOCK_ON) {
+		dcp_clock(sdcp, CLOCK_OFF, true);
+		/* indicate that clock needs to be turned on upon resume */
+		sdcp->clock_state = CLOCK_ON;
+	}
+#endif
+	return 0;
+}
+
+static int dcp_resume(struct platform_device *pdev)
+{
+#ifdef CONFIG_PM
+	struct dcp *sdcp = platform_get_drvdata(pdev);
+
+	/* if clock was on prior to suspend, turn it back on */
+	if (sdcp->clock_state == CLOCK_ON)
+		dcp_clock(sdcp, CLOCK_ON, true);
+#endif
+	return 0;
+}
+
+static const struct of_device_id mxs_dcp_dt_ids[] = {
+	{.compatible = "fsl,fsl-dcp", .data = NULL,},
+	{ /* sentinel */ }
+};
+
+MODULE_DEVICE_TABLE(of, mxs_dcp_dt_ids);
+
+static struct platform_driver dcp_driver = {
+	.probe = dcp_probe,
+	.remove = dcp_remove,
+	.suspend = dcp_suspend,
+	.resume = dcp_resume,
+	.driver = {
+		   .name = "fsl-dcp",
+		   .owner = THIS_MODULE,
+		   .of_match_table = mxs_dcp_dt_ids,
+		   },
+};
+
+static int __init dcp_init(void)
+{
+	return platform_driver_register(&dcp_driver);
+}
+
+static void __exit dcp_exit(void)
+{
+	platform_driver_unregister(&dcp_driver);
+}
+
+MODULE_AUTHOR("Pantelis Antoniou <pantelis at embeddedalley.com>");
+MODULE_DESCRIPTION("DCP Crypto Driver");
+MODULE_LICENSE("GPL");
+
+module_init(dcp_init);
+module_exit(dcp_exit);
diff --git a/drivers/staging/crypto/fsl-dcp.h b/drivers/staging/crypto/fsl-dcp.h
new file mode 100644
index 0000000..3b21c09
--- /dev/null
+++ b/drivers/staging/crypto/fsl-dcp.h
@@ -0,0 +1,739 @@
+/*
+ * Copyright 2008-2010 Freescale Semiconductor, Inc. All Rights Reserved.
+ */
+
+/*
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+#ifndef DCP_H_
+#define DCP_H_
+
+/* cipher flags */
+#define DCP_ENC	0x0001
+#define DCP_DEC	0x0002
+#define DCP_ECB	0x0004
+#define DCP_CBC	0x0008
+#define DCP_CBC_INIT	0x0010
+#define DCP_OTPKEY	0x0020
+
+/* hash flags */
+#define DCP_INIT	0x0001
+#define DCP_UPDATE	0x0002
+#define DCP_FINAL	0x0004
+
+#define DCP_AES	0x1000
+#define DCP_SHA1	0x2000
+#define DCP_CRC32	0x3000
+#define DCP_COPY	0x4000
+#define DCP_FILL	0x5000
+#define DCP_MODE_MASK	0xf000
+
+/* clock defines */
+#define CLOCK_ON	1
+#define CLOCK_OFF	0
+
+#define CIPHER_CHAN	1
+#define CIPHER_MASK	(1 << CIPHER_CHAN)
+
+#define HASH_CHAN	0
+#define HASH_MASK	(1 << HASH_CHAN)
+
+/* DCP boostream interface uses this channel (same as the ROM) */
+#define ROM_DCP_CHAN 3
+#define ROM_DCP_CHAN_MASK (1 << ROM_DCP_CHAN)
+
+#define ALL_MASK	(CIPHER_MASK | HASH_MASK | ROM_DCP_CHAN_MASK)
+
+/* Defines the initialization value for the dcp control register */
+#define DCP_CTRL_INIT \
+	(BM_DCP_CTRL_GATHER_RESIDUAL_WRITES | \
+	BM_DCP_CTRL_ENABLE_CONTEXT_CACHING | \
+	BV_DCP_CTRL_CHANNEL_INTERRUPT_ENABLE__CH0 | \
+	BV_DCP_CTRL_CHANNEL_INTERRUPT_ENABLE__CH1 | \
+	BV_DCP_CTRL_CHANNEL_INTERRUPT_ENABLE__CH2 | \
+	BV_DCP_CTRL_CHANNEL_INTERRUPT_ENABLE__CH3)
+
+/* Defines the initialization value for the dcp channel control register */
+#define DCP_CHANNELCTRL_INIT \
+	BF(ALL_MASK, DCP_CHANNELCTRL_ENABLE_CHANNEL)
+
+/* DCP work packet 1 value for encryption */
+#define DCP_PKT1_ENCRYPT \
+	(BM_DCP_PACKET1_DECR_SEMAPHORE | \
+	BM_DCP_PACKET1_ENABLE_CIPHER | \
+	BM_DCP_PACKET1_CIPHER_ENCRYPT | \
+	BM_DCP_PACKET1_CIPHER_INIT)
+
+/* DCP work packet 1 value for decryption */
+#define DCP_PKT1_DECRYPT \
+	(BM_DCP_PACKET1_DECR_SEMAPHORE | \
+	BM_DCP_PACKET1_ENABLE_CIPHER | \
+	BM_DCP_PACKET1_CIPHER_INIT)
+
+/* DCP (decryption) work packet definition */
+struct dcp_hw_packet {
+	uint32_t next;    /* next dcp work packet address */
+	uint32_t pkt1;    /* dcp work packet 1 (control 0) */
+	uint32_t pkt2;    /* dcp work packet 2 (control 1) */
+	uint32_t src;     /* source buffer address */
+	uint32_t dst;     /* destination buffer address */
+	uint32_t size;    /* buffer size in bytes */
+	uint32_t payload; /* payload buffer address */
+	uint32_t stat;    /* dcp status (written by dcp) */
+};
+
+#define DCP_NUM_CHANNELS 4
+
+/* DCP Register definitions */
+
+#ifndef BF
+#define BF(value, field) (((value) << BP_##field) & BM_##field)
+#endif
+
+#define REGS_DCP_SIZE 0x00002000
+
+#define HW_DCP_CTRL	(0x00000000)
+#define HW_DCP_CTRL_SET	(0x00000004)
+#define HW_DCP_CTRL_CLR	(0x00000008)
+#define HW_DCP_CTRL_TOG	(0x0000000c)
+
+#define BM_DCP_CTRL_SFTRST	0x80000000
+#define BM_DCP_CTRL_CLKGATE	0x40000000
+#define BM_DCP_CTRL_PRESENT_CRYPTO	0x20000000
+#define BV_DCP_CTRL_PRESENT_CRYPTO__PRESENT 0x1
+#define BV_DCP_CTRL_PRESENT_CRYPTO__ABSENT  0x0
+#define BM_DCP_CTRL_PRESENT_CSC	0x10000000
+#define BV_DCP_CTRL_PRESENT_CSC__PRESENT 0x1
+#define BV_DCP_CTRL_PRESENT_CSC__ABSENT  0x0
+#define BP_DCP_CTRL_RSVD1	24
+#define BM_DCP_CTRL_RSVD1	0x0F000000
+#define BF_DCP_CTRL_RSVD1(v)  \
+		(((v) << 24) & BM_DCP_CTRL_RSVD1)
+#define BM_DCP_CTRL_GATHER_RESIDUAL_WRITES	0x00800000
+#define BM_DCP_CTRL_ENABLE_CONTEXT_CACHING	0x00400000
+#define BM_DCP_CTRL_ENABLE_CONTEXT_SWITCHING	0x00200000
+#define BP_DCP_CTRL_RSVD0	9
+#define BM_DCP_CTRL_RSVD0	0x001FFE00
+#define BF_DCP_CTRL_RSVD0(v)  \
+		(((v) << 9) & BM_DCP_CTRL_RSVD0)
+#define BM_DCP_CTRL_CSC_INTERRUPT_ENABLE	0x00000100
+#define BP_DCP_CTRL_CHANNEL_INTERRUPT_ENABLE	0
+#define BM_DCP_CTRL_CHANNEL_INTERRUPT_ENABLE	0x000000FF
+#define BF_DCP_CTRL_CHANNEL_INTERRUPT_ENABLE(v)  \
+		(((v) << 0) & BM_DCP_CTRL_CHANNEL_INTERRUPT_ENABLE)
+#define BV_DCP_CTRL_CHANNEL_INTERRUPT_ENABLE__CH0 0x01
+#define BV_DCP_CTRL_CHANNEL_INTERRUPT_ENABLE__CH1 0x02
+#define BV_DCP_CTRL_CHANNEL_INTERRUPT_ENABLE__CH2 0x04
+#define BV_DCP_CTRL_CHANNEL_INTERRUPT_ENABLE__CH3 0x08
+
+#define HW_DCP_STAT	(0x00000010)
+#define HW_DCP_STAT_SET	(0x00000014)
+#define HW_DCP_STAT_CLR	(0x00000018)
+#define HW_DCP_STAT_TOG	(0x0000001c)
+
+#define BP_DCP_STAT_RSVD2	29
+#define BM_DCP_STAT_RSVD2	0xE0000000
+#define BF_DCP_STAT_RSVD2(v) \
+		(((v) << 29) & BM_DCP_STAT_RSVD2)
+#define BM_DCP_STAT_OTP_KEY_READY	0x10000000
+#define BP_DCP_STAT_CUR_CHANNEL	24
+#define BM_DCP_STAT_CUR_CHANNEL	0x0F000000
+#define BF_DCP_STAT_CUR_CHANNEL(v)  \
+		(((v) << 24) & BM_DCP_STAT_CUR_CHANNEL)
+#define BV_DCP_STAT_CUR_CHANNEL__NONE 0x0
+#define BV_DCP_STAT_CUR_CHANNEL__CH0  0x1
+#define BV_DCP_STAT_CUR_CHANNEL__CH1  0x2
+#define BV_DCP_STAT_CUR_CHANNEL__CH2  0x3
+#define BV_DCP_STAT_CUR_CHANNEL__CH3  0x4
+#define BV_DCP_STAT_CUR_CHANNEL__CSC  0x8
+#define BP_DCP_STAT_READY_CHANNELS	16
+#define BM_DCP_STAT_READY_CHANNELS	0x00FF0000
+#define BF_DCP_STAT_READY_CHANNELS(v)  \
+		(((v) << 16) & BM_DCP_STAT_READY_CHANNELS)
+#define BV_DCP_STAT_READY_CHANNELS__CH0 0x01
+#define BV_DCP_STAT_READY_CHANNELS__CH1 0x02
+#define BV_DCP_STAT_READY_CHANNELS__CH2 0x04
+#define BV_DCP_STAT_READY_CHANNELS__CH3 0x08
+#define BP_DCP_STAT_RSVD1	9
+#define BM_DCP_STAT_RSVD1	0x0000FE00
+#define BF_DCP_STAT_RSVD1(v)  \
+		(((v) << 9) & BM_DCP_STAT_RSVD1)
+#define BM_DCP_STAT_CSCIRQ	0x00000100
+#define BP_DCP_STAT_RSVD0	4
+#define BM_DCP_STAT_RSVD0	0x000000F0
+#define BF_DCP_STAT_RSVD0(v)  \
+		(((v) << 4) & BM_DCP_STAT_RSVD0)
+#define BP_DCP_STAT_IRQ	0
+#define BM_DCP_STAT_IRQ	0x0000000F
+#define BF_DCP_STAT_IRQ(v)  \
+		(((v) << 0) & BM_DCP_STAT_IRQ)
+
+#define HW_DCP_CHANNELCTRL	(0x00000020)
+#define HW_DCP_CHANNELCTRL_SET	(0x00000024)
+#define HW_DCP_CHANNELCTRL_CLR	(0x00000028)
+#define HW_DCP_CHANNELCTRL_TOG	(0x0000002c)
+
+#define BP_DCP_CHANNELCTRL_RSVD	19
+#define BM_DCP_CHANNELCTRL_RSVD	0xFFF80000
+#define BF_DCP_CHANNELCTRL_RSVD(v) \
+		(((v) << 19) & BM_DCP_CHANNELCTRL_RSVD)
+#define BP_DCP_CHANNELCTRL_CSC_PRIORITY	17
+#define BM_DCP_CHANNELCTRL_CSC_PRIORITY	0x00060000
+#define BF_DCP_CHANNELCTRL_CSC_PRIORITY(v)  \
+		(((v) << 17) & BM_DCP_CHANNELCTRL_CSC_PRIORITY)
+#define BV_DCP_CHANNELCTRL_CSC_PRIORITY__HIGH       0x3
+#define BV_DCP_CHANNELCTRL_CSC_PRIORITY__MED        0x2
+#define BV_DCP_CHANNELCTRL_CSC_PRIORITY__LOW        0x1
+#define BV_DCP_CHANNELCTRL_CSC_PRIORITY__BACKGROUND 0x0
+#define BM_DCP_CHANNELCTRL_CH0_IRQ_MERGED	0x00010000
+#define BP_DCP_CHANNELCTRL_HIGH_PRIORITY_CHANNEL	8
+#define BM_DCP_CHANNELCTRL_HIGH_PRIORITY_CHANNEL	0x0000FF00
+#define BF_DCP_CHANNELCTRL_HIGH_PRIORITY_CHANNEL(v)  \
+		(((v) << 8) & BM_DCP_CHANNELCTRL_HIGH_PRIORITY_CHANNEL)
+#define BV_DCP_CHANNELCTRL_HIGH_PRIORITY_CHANNEL__CH0 0x01
+#define BV_DCP_CHANNELCTRL_HIGH_PRIORITY_CHANNEL__CH1 0x02
+#define BV_DCP_CHANNELCTRL_HIGH_PRIORITY_CHANNEL__CH2 0x04
+#define BV_DCP_CHANNELCTRL_HIGH_PRIORITY_CHANNEL__CH3 0x08
+#define BP_DCP_CHANNELCTRL_ENABLE_CHANNEL	0
+#define BM_DCP_CHANNELCTRL_ENABLE_CHANNEL	0x000000FF
+#define BF_DCP_CHANNELCTRL_ENABLE_CHANNEL(v)  \
+		(((v) << 0) & BM_DCP_CHANNELCTRL_ENABLE_CHANNEL)
+#define BV_DCP_CHANNELCTRL_ENABLE_CHANNEL__CH0 0x01
+#define BV_DCP_CHANNELCTRL_ENABLE_CHANNEL__CH1 0x02
+#define BV_DCP_CHANNELCTRL_ENABLE_CHANNEL__CH2 0x04
+#define BV_DCP_CHANNELCTRL_ENABLE_CHANNEL__CH3 0x08
+
+#define HW_DCP_CAPABILITY0	(0x00000030)
+
+#define BM_DCP_CAPABILITY0_DISABLE_DECRYPT	0x80000000
+#define BM_DCP_CAPABILITY0_ENABLE_TZONE	0x40000000
+#define BP_DCP_CAPABILITY0_RSVD	12
+#define BM_DCP_CAPABILITY0_RSVD	0x3FFFF000
+#define BF_DCP_CAPABILITY0_RSVD(v)  \
+		(((v) << 12) & BM_DCP_CAPABILITY0_RSVD)
+#define BP_DCP_CAPABILITY0_NUM_CHANNELS	8
+#define BM_DCP_CAPABILITY0_NUM_CHANNELS	0x00000F00
+#define BF_DCP_CAPABILITY0_NUM_CHANNELS(v)  \
+		(((v) << 8) & BM_DCP_CAPABILITY0_NUM_CHANNELS)
+#define BP_DCP_CAPABILITY0_NUM_KEYS	0
+#define BM_DCP_CAPABILITY0_NUM_KEYS	0x000000FF
+#define BF_DCP_CAPABILITY0_NUM_KEYS(v)  \
+		(((v) << 0) & BM_DCP_CAPABILITY0_NUM_KEYS)
+
+#define HW_DCP_CAPABILITY1	(0x00000040)
+
+#define BP_DCP_CAPABILITY1_HASH_ALGORITHMS	16
+#define BM_DCP_CAPABILITY1_HASH_ALGORITHMS	0xFFFF0000
+#define BF_DCP_CAPABILITY1_HASH_ALGORITHMS(v) \
+		(((v) << 16) & BM_DCP_CAPABILITY1_HASH_ALGORITHMS)
+#define BV_DCP_CAPABILITY1_HASH_ALGORITHMS__SHA1  0x0001
+#define BV_DCP_CAPABILITY1_HASH_ALGORITHMS__CRC32 0x0002
+#define BV_DCP_CAPABILITY1_HASH_ALGORITHMS__SHA256  0x0004
+#define BP_DCP_CAPABILITY1_CIPHER_ALGORITHMS	0
+#define BM_DCP_CAPABILITY1_CIPHER_ALGORITHMS	0x0000FFFF
+#define BF_DCP_CAPABILITY1_CIPHER_ALGORITHMS(v)  \
+		(((v) << 0) & BM_DCP_CAPABILITY1_CIPHER_ALGORITHMS)
+#define BV_DCP_CAPABILITY1_CIPHER_ALGORITHMS__AES128 0x0001
+
+#define HW_DCP_CONTEXT	(0x00000050)
+
+#define BP_DCP_CONTEXT_ADDR	0
+#define BM_DCP_CONTEXT_ADDR	0xFFFFFFFF
+#define BF_DCP_CONTEXT_ADDR(v)	(v)
+
+#define HW_DCP_KEY	(0x00000060)
+
+#define BP_DCP_KEY_RSVD	8
+#define BM_DCP_KEY_RSVD	0xFFFFFF00
+#define BF_DCP_KEY_RSVD(v) \
+		(((v) << 8) & BM_DCP_KEY_RSVD)
+#define BP_DCP_KEY_RSVD_INDEX	6
+#define BM_DCP_KEY_RSVD_INDEX	0x000000C0
+#define BF_DCP_KEY_RSVD_INDEX(v)  \
+		(((v) << 6) & BM_DCP_KEY_RSVD_INDEX)
+#define BP_DCP_KEY_INDEX	4
+#define BM_DCP_KEY_INDEX	0x00000030
+#define BF_DCP_KEY_INDEX(v)  \
+		(((v) << 4) & BM_DCP_KEY_INDEX)
+#define BP_DCP_KEY_RSVD_SUBWORD	2
+#define BM_DCP_KEY_RSVD_SUBWORD	0x0000000C
+#define BF_DCP_KEY_RSVD_SUBWORD(v)  \
+		(((v) << 2) & BM_DCP_KEY_RSVD_SUBWORD)
+#define BP_DCP_KEY_SUBWORD	0
+#define BM_DCP_KEY_SUBWORD	0x00000003
+#define BF_DCP_KEY_SUBWORD(v)  \
+		(((v) << 0) & BM_DCP_KEY_SUBWORD)
+
+#define HW_DCP_KEYDATA	(0x00000070)
+
+#define BP_DCP_KEYDATA_DATA	0
+#define BM_DCP_KEYDATA_DATA	0xFFFFFFFF
+#define BF_DCP_KEYDATA_DATA(v)	(v)
+
+#define HW_DCP_PACKET0	(0x00000080)
+
+#define BP_DCP_PACKET0_ADDR	0
+#define BM_DCP_PACKET0_ADDR	0xFFFFFFFF
+#define BF_DCP_PACKET0_ADDR(v)	(v)
+
+#define HW_DCP_PACKET1	(0x00000090)
+
+#define BP_DCP_PACKET1_TAG	24
+#define BM_DCP_PACKET1_TAG	0xFF000000
+#define BF_DCP_PACKET1_TAG(v) \
+		(((v) << 24) & BM_DCP_PACKET1_TAG)
+#define BM_DCP_PACKET1_OUTPUT_WORDSWAP	0x00800000
+#define BM_DCP_PACKET1_OUTPUT_BYTESWAP	0x00400000
+#define BM_DCP_PACKET1_INPUT_WORDSWAP	0x00200000
+#define BM_DCP_PACKET1_INPUT_BYTESWAP	0x00100000
+#define BM_DCP_PACKET1_KEY_WORDSWAP	0x00080000
+#define BM_DCP_PACKET1_KEY_BYTESWAP	0x00040000
+#define BM_DCP_PACKET1_TEST_SEMA_IRQ	0x00020000
+#define BM_DCP_PACKET1_CONSTANT_FILL	0x00010000
+#define BM_DCP_PACKET1_HASH_OUTPUT	0x00008000
+#define BV_DCP_PACKET1_HASH_OUTPUT__INPUT  0x00
+#define BV_DCP_PACKET1_HASH_OUTPUT__OUTPUT 0x01
+#define BM_DCP_PACKET1_CHECK_HASH	0x00004000
+#define BM_DCP_PACKET1_HASH_TERM	0x00002000
+#define BM_DCP_PACKET1_HASH_INIT	0x00001000
+#define BM_DCP_PACKET1_PAYLOAD_KEY	0x00000800
+#define BM_DCP_PACKET1_OTP_KEY	0x00000400
+#define BM_DCP_PACKET1_CIPHER_INIT	0x00000200
+#define BM_DCP_PACKET1_CIPHER_ENCRYPT	0x00000100
+#define BV_DCP_PACKET1_CIPHER_ENCRYPT__ENCRYPT 0x01
+#define BV_DCP_PACKET1_CIPHER_ENCRYPT__DECRYPT 0x00
+#define BM_DCP_PACKET1_ENABLE_BLIT	0x00000080
+#define BM_DCP_PACKET1_ENABLE_HASH	0x00000040
+#define BM_DCP_PACKET1_ENABLE_CIPHER	0x00000020
+#define BM_DCP_PACKET1_ENABLE_MEMCOPY	0x00000010
+#define BM_DCP_PACKET1_CHAIN_CONTIGUOUS	0x00000008
+#define BM_DCP_PACKET1_CHAIN	0x00000004
+#define BM_DCP_PACKET1_DECR_SEMAPHORE	0x00000002
+#define BM_DCP_PACKET1_INTERRUPT	0x00000001
+
+#define HW_DCP_PACKET2	(0x000000a0)
+
+#define BP_DCP_PACKET2_CIPHER_CFG	24
+#define BM_DCP_PACKET2_CIPHER_CFG	0xFF000000
+#define BF_DCP_PACKET2_CIPHER_CFG(v) \
+		(((v) << 24) & BM_DCP_PACKET2_CIPHER_CFG)
+#define BP_DCP_PACKET2_RSVD	20
+#define BM_DCP_PACKET2_RSVD	0x00F00000
+#define BF_DCP_PACKET2_RSVD(v)  \
+		(((v) << 20) & BM_DCP_PACKET2_RSVD)
+#define BP_DCP_PACKET2_HASH_SELECT	16
+#define BM_DCP_PACKET2_HASH_SELECT	0x000F0000
+#define BF_DCP_PACKET2_HASH_SELECT(v)  \
+		(((v) << 16) & BM_DCP_PACKET2_HASH_SELECT)
+#define BV_DCP_PACKET2_HASH_SELECT__SHA1  0x00
+#define BV_DCP_PACKET2_HASH_SELECT__CRC32 0x01
+#define BV_DCP_PACKET2_HASH_SELECT__SHA256  0x02
+#define BP_DCP_PACKET2_KEY_SELECT	8
+#define BM_DCP_PACKET2_KEY_SELECT	0x0000FF00
+#define BF_DCP_PACKET2_KEY_SELECT(v)  \
+		(((v) << 8) & BM_DCP_PACKET2_KEY_SELECT)
+#define BP_DCP_PACKET2_CIPHER_MODE	4
+#define BM_DCP_PACKET2_CIPHER_MODE	0x000000F0
+#define BF_DCP_PACKET2_CIPHER_MODE(v)  \
+		(((v) << 4) & BM_DCP_PACKET2_CIPHER_MODE)
+#define BV_DCP_PACKET2_CIPHER_MODE__ECB 0x00
+#define BV_DCP_PACKET2_CIPHER_MODE__CBC 0x01
+#define BP_DCP_PACKET2_CIPHER_SELECT	0
+#define BM_DCP_PACKET2_CIPHER_SELECT	0x0000000F
+#define BF_DCP_PACKET2_CIPHER_SELECT(v)  \
+		(((v) << 0) & BM_DCP_PACKET2_CIPHER_SELECT)
+#define BV_DCP_PACKET2_CIPHER_SELECT__AES128 0x00
+
+#define HW_DCP_PACKET3	(0x000000b0)
+
+#define BP_DCP_PACKET3_ADDR	0
+#define BM_DCP_PACKET3_ADDR	0xFFFFFFFF
+#define BF_DCP_PACKET3_ADDR(v)	(v)
+
+#define HW_DCP_PACKET4	(0x000000c0)
+
+#define BP_DCP_PACKET4_ADDR	0
+#define BM_DCP_PACKET4_ADDR	0xFFFFFFFF
+#define BF_DCP_PACKET4_ADDR(v)	(v)
+
+#define HW_DCP_PACKET5	(0x000000d0)
+
+#define BP_DCP_PACKET5_COUNT	0
+#define BM_DCP_PACKET5_COUNT	0xFFFFFFFF
+#define BF_DCP_PACKET5_COUNT(v)	(v)
+
+#define HW_DCP_PACKET6	(0x000000e0)
+
+#define BP_DCP_PACKET6_ADDR	0
+#define BM_DCP_PACKET6_ADDR	0xFFFFFFFF
+#define BF_DCP_PACKET6_ADDR(v)	(v)
+
+/*
+ *  multi-register-define name HW_DCP_CH_N_CMDPTR
+ *              base 0x00000100
+ *              count 4
+ *              offset 0x40
+ */
+#define HW_DCP_CH_N_CMDPTR(n)	(0x00000100 + (n) * 0x40)
+
+#define BP_DCP_CH_N_CMDPTR_ADDR	0
+#define BM_DCP_CH_N_CMDPTR_ADDR	0xFFFFFFFF
+#define BF_DCP_CH_N_CMDPTR_ADDR(v)	(v)
+
+/*
+ *  multi-register-define name HW_DCP_CH_N_SEMA
+ *              base 0x00000110
+ *              count 4
+ *              offset 0x40
+ */
+#define HW_DCP_CH_N_SEMA(n)	(0x00000110 + (n) * 0x40)
+
+#define BP_DCP_CH_N_SEMA_RSVD2	24
+#define BM_DCP_CH_N_SEMA_RSVD2	0xFF000000
+#define BF_DCP_CH_N_SEMA_RSVD2(v) \
+		(((v) << 24) & BM_DCP_CH_N_SEMA_RSVD2)
+#define BP_DCP_CH_N_SEMA_VALUE	16
+#define BM_DCP_CH_N_SEMA_VALUE	0x00FF0000
+#define BF_DCP_CH_N_SEMA_VALUE(v)  \
+		(((v) << 16) & BM_DCP_CH_N_SEMA_VALUE)
+#define BP_DCP_CH_N_SEMA_RSVD1	8
+#define BM_DCP_CH_N_SEMA_RSVD1	0x0000FF00
+#define BF_DCP_CH_N_SEMA_RSVD1(v)  \
+		(((v) << 8) & BM_DCP_CH_N_SEMA_RSVD1)
+#define BP_DCP_CH_N_SEMA_INCREMENT	0
+#define BM_DCP_CH_N_SEMA_INCREMENT	0x000000FF
+#define BF_DCP_CH_N_SEMA_INCREMENT(v)  \
+		(((v) << 0) & BM_DCP_CH_N_SEMA_INCREMENT)
+
+/*
+ *  multi-register-define name HW_DCP_CH_N_STAT
+ *              base 0x00000120
+ *              count 4
+ *              offset 0x40
+ */
+#define HW_DCP_CH_N_STAT(n)	(0x00000120 + (n) * 0x40)
+#define HW_DCP_CH_N_STAT_SET(n)	(0x00000124 + (n) * 0x40)
+#define HW_DCP_CH_N_STAT_CLR(n)	(0x00000128 + (n) * 0x40)
+#define HW_DCP_CH_N_STAT_TOG(n)	(0x0000012c + (n) * 0x40)
+
+#define BP_DCP_CH_N_STAT_TAG	24
+#define BM_DCP_CH_N_STAT_TAG	0xFF000000
+#define BF_DCP_CH_N_STAT_TAG(v) \
+		(((v) << 24) & BM_DCP_CH_N_STAT_TAG)
+#define BP_DCP_CH_N_STAT_ERROR_CODE	16
+#define BM_DCP_CH_N_STAT_ERROR_CODE	0x00FF0000
+#define BF_DCP_CH_N_STAT_ERROR_CODE(v)  \
+		(((v) << 16) & BM_DCP_CH_N_STAT_ERROR_CODE)
+#define BV_DCP_CH_N_STAT_ERROR_CODE__NEXT_CHAIN_IS_0 0x01
+#define BV_DCP_CH_N_STAT_ERROR_CODE__NO_CHAIN        0x02
+#define BV_DCP_CH_N_STAT_ERROR_CODE__CONTEXT_ERROR   0x03
+#define BV_DCP_CH_N_STAT_ERROR_CODE__PAYLOAD_ERROR   0x04
+#define BV_DCP_CH_N_STAT_ERROR_CODE__INVALID_MODE    0x05
+#define BP_DCP_CH_N_STAT_RSVD0	7
+#define BM_DCP_CH_N_STAT_RSVD0	0x0000FF80
+#define BF_DCP_CH_N_STAT_RSVD0(v)  \
+		(((v) << 7) & BM_DCP_CH_N_STAT_RSVD0)
+#define BM_DCP_CH_N_STAT_ERROR_PAGEFAULT	0x00000040
+#define BM_DCP_CH_N_STAT_ERROR_DST	0x00000020
+#define BM_DCP_CH_N_STAT_ERROR_SRC	0x00000010
+#define BM_DCP_CH_N_STAT_ERROR_PACKET	0x00000008
+#define BM_DCP_CH_N_STAT_ERROR_SETUP	0x00000004
+#define BM_DCP_CH_N_STAT_HASH_MISMATCH	0x00000002
+#define BM_DCP_CH_N_STAT_RSVD_COMPLETE	0x00000001
+
+/*
+ *  multi-register-define name HW_DCP_CH_N_OPTS
+ *              base 0x00000130
+ *              count 4
+ *              offset 0x40
+ */
+#define HW_DCP_CH_N_OPTS(n)	(0x00000130 + (n) * 0x40)
+#define HW_DCP_CH_N_OPTS_SET(n)	(0x00000134 + (n) * 0x40)
+#define HW_DCP_CH_N_OPTS_CLR(n)	(0x00000138 + (n) * 0x40)
+#define HW_DCP_CH_N_OPTS_TOG(n)	(0x0000013c + (n) * 0x40)
+
+#define BP_DCP_CH_N_OPTS_RSVD	16
+#define BM_DCP_CH_N_OPTS_RSVD	0xFFFF0000
+#define BF_DCP_CH_N_OPTS_RSVD(v) \
+		(((v) << 16) & BM_DCP_CH_N_OPTS_RSVD)
+#define BP_DCP_CH_N_OPTS_RECOVERY_TIMER	0
+#define BM_DCP_CH_N_OPTS_RECOVERY_TIMER	0x0000FFFF
+#define BF_DCP_CH_N_OPTS_RECOVERY_TIMER(v)  \
+		(((v) << 0) & BM_DCP_CH_N_OPTS_RECOVERY_TIMER)
+
+#define HW_DCP_CSCCTRL0	(0x00000300)
+#define HW_DCP_CSCCTRL0_SET	(0x00000304)
+#define HW_DCP_CSCCTRL0_CLR	(0x00000308)
+#define HW_DCP_CSCCTRL0_TOG	(0x0000030c)
+
+#define BP_DCP_CSCCTRL0_RSVD1	16
+#define BM_DCP_CSCCTRL0_RSVD1	0xFFFF0000
+#define BF_DCP_CSCCTRL0_RSVD1(v) \
+		(((v) << 16) & BM_DCP_CSCCTRL0_RSVD1)
+#define BM_DCP_CSCCTRL0_CLIP	0x00008000
+#define BM_DCP_CSCCTRL0_UPSAMPLE	0x00004000
+#define BM_DCP_CSCCTRL0_SCALE	0x00002000
+#define BM_DCP_CSCCTRL0_ROTATE	0x00001000
+#define BM_DCP_CSCCTRL0_SUBSAMPLE	0x00000800
+#define BM_DCP_CSCCTRL0_DELTA	0x00000400
+#define BP_DCP_CSCCTRL0_RGB_FORMAT	8
+#define BM_DCP_CSCCTRL0_RGB_FORMAT	0x00000300
+#define BF_DCP_CSCCTRL0_RGB_FORMAT(v)  \
+		(((v) << 8) & BM_DCP_CSCCTRL0_RGB_FORMAT)
+#define BV_DCP_CSCCTRL0_RGB_FORMAT__RGB16_565 0x0
+#define BV_DCP_CSCCTRL0_RGB_FORMAT__YCbCrI    0x1
+#define BV_DCP_CSCCTRL0_RGB_FORMAT__RGB24     0x2
+#define BV_DCP_CSCCTRL0_RGB_FORMAT__YUV422I   0x3
+#define BP_DCP_CSCCTRL0_YUV_FORMAT	4
+#define BM_DCP_CSCCTRL0_YUV_FORMAT	0x000000F0
+#define BF_DCP_CSCCTRL0_YUV_FORMAT(v)  \
+		(((v) << 4) & BM_DCP_CSCCTRL0_YUV_FORMAT)
+#define BV_DCP_CSCCTRL0_YUV_FORMAT__YUV420 0x0
+#define BV_DCP_CSCCTRL0_YUV_FORMAT__YUV422 0x2
+#define BP_DCP_CSCCTRL0_RSVD0	1
+#define BM_DCP_CSCCTRL0_RSVD0	0x0000000E
+#define BF_DCP_CSCCTRL0_RSVD0(v)  \
+		(((v) << 1) & BM_DCP_CSCCTRL0_RSVD0)
+#define BM_DCP_CSCCTRL0_ENABLE	0x00000001
+
+#define HW_DCP_CSCSTAT	(0x00000310)
+#define HW_DCP_CSCSTAT_SET	(0x00000314)
+#define HW_DCP_CSCSTAT_CLR	(0x00000318)
+#define HW_DCP_CSCSTAT_TOG	(0x0000031c)
+
+#define BP_DCP_CSCSTAT_RSVD3	24
+#define BM_DCP_CSCSTAT_RSVD3	0xFF000000
+#define BF_DCP_CSCSTAT_RSVD3(v) \
+		(((v) << 24) & BM_DCP_CSCSTAT_RSVD3)
+#define BP_DCP_CSCSTAT_ERROR_CODE	16
+#define BM_DCP_CSCSTAT_ERROR_CODE	0x00FF0000
+#define BF_DCP_CSCSTAT_ERROR_CODE(v)  \
+		(((v) << 16) & BM_DCP_CSCSTAT_ERROR_CODE)
+#define BV_DCP_CSCSTAT_ERROR_CODE__LUMA0_FETCH_ERROR_Y0 0x01
+#define BV_DCP_CSCSTAT_ERROR_CODE__LUMA1_FETCH_ERROR_Y1 0x02
+#define BV_DCP_CSCSTAT_ERROR_CODE__CHROMA_FETCH_ERROR_U 0x03
+#define BV_DCP_CSCSTAT_ERROR_CODE__CHROMA_FETCH_ERROR_V 0x04
+#define BP_DCP_CSCSTAT_RSVD2	7
+#define BM_DCP_CSCSTAT_RSVD2	0x0000FF80
+#define BF_DCP_CSCSTAT_RSVD2(v)  \
+		(((v) << 7) & BM_DCP_CSCSTAT_RSVD2)
+#define BM_DCP_CSCSTAT_ERROR_PAGEFAULT	0x00000040
+#define BM_DCP_CSCSTAT_ERROR_DST	0x00000020
+#define BM_DCP_CSCSTAT_ERROR_SRC	0x00000010
+#define BM_DCP_CSCSTAT_RSVD1	0x00000008
+#define BM_DCP_CSCSTAT_ERROR_SETUP	0x00000004
+#define BM_DCP_CSCSTAT_RSVD0	0x00000002
+#define BM_DCP_CSCSTAT_COMPLETE	0x00000001
+
+#define HW_DCP_CSCOUTBUFPARAM	(0x00000320)
+
+#define BP_DCP_CSCOUTBUFPARAM_RSVD1	24
+#define BM_DCP_CSCOUTBUFPARAM_RSVD1	0xFF000000
+#define BF_DCP_CSCOUTBUFPARAM_RSVD1(v) \
+		(((v) << 24) & BM_DCP_CSCOUTBUFPARAM_RSVD1)
+#define BP_DCP_CSCOUTBUFPARAM_FIELD_SIZE	12
+#define BM_DCP_CSCOUTBUFPARAM_FIELD_SIZE	0x00FFF000
+#define BF_DCP_CSCOUTBUFPARAM_FIELD_SIZE(v)  \
+		(((v) << 12) & BM_DCP_CSCOUTBUFPARAM_FIELD_SIZE)
+#define BP_DCP_CSCOUTBUFPARAM_LINE_SIZE	0
+#define BM_DCP_CSCOUTBUFPARAM_LINE_SIZE	0x00000FFF
+#define BF_DCP_CSCOUTBUFPARAM_LINE_SIZE(v)  \
+		(((v) << 0) & BM_DCP_CSCOUTBUFPARAM_LINE_SIZE)
+
+#define HW_DCP_CSCINBUFPARAM	(0x00000330)
+
+#define BP_DCP_CSCINBUFPARAM_RSVD1	12
+#define BM_DCP_CSCINBUFPARAM_RSVD1	0xFFFFF000
+#define BF_DCP_CSCINBUFPARAM_RSVD1(v) \
+		(((v) << 12) & BM_DCP_CSCINBUFPARAM_RSVD1)
+#define BP_DCP_CSCINBUFPARAM_LINE_SIZE	0
+#define BM_DCP_CSCINBUFPARAM_LINE_SIZE	0x00000FFF
+#define BF_DCP_CSCINBUFPARAM_LINE_SIZE(v)  \
+		(((v) << 0) & BM_DCP_CSCINBUFPARAM_LINE_SIZE)
+
+#define HW_DCP_CSCRGB	(0x00000340)
+
+#define BP_DCP_CSCRGB_ADDR	0
+#define BM_DCP_CSCRGB_ADDR	0xFFFFFFFF
+#define BF_DCP_CSCRGB_ADDR(v)	(v)
+
+#define HW_DCP_CSCLUMA	(0x00000350)
+
+#define BP_DCP_CSCLUMA_ADDR	0
+#define BM_DCP_CSCLUMA_ADDR	0xFFFFFFFF
+#define BF_DCP_CSCLUMA_ADDR(v)	(v)
+
+#define HW_DCP_CSCCHROMAU	(0x00000360)
+
+#define BP_DCP_CSCCHROMAU_ADDR	0
+#define BM_DCP_CSCCHROMAU_ADDR	0xFFFFFFFF
+#define BF_DCP_CSCCHROMAU_ADDR(v)	(v)
+
+#define HW_DCP_CSCCHROMAV	(0x00000370)
+
+#define BP_DCP_CSCCHROMAV_ADDR	0
+#define BM_DCP_CSCCHROMAV_ADDR	0xFFFFFFFF
+#define BF_DCP_CSCCHROMAV_ADDR(v)	(v)
+
+#define HW_DCP_CSCCOEFF0	(0x00000380)
+
+#define BP_DCP_CSCCOEFF0_RSVD1	26
+#define BM_DCP_CSCCOEFF0_RSVD1	0xFC000000
+#define BF_DCP_CSCCOEFF0_RSVD1(v) \
+		(((v) << 26) & BM_DCP_CSCCOEFF0_RSVD1)
+#define BP_DCP_CSCCOEFF0_C0	16
+#define BM_DCP_CSCCOEFF0_C0	0x03FF0000
+#define BF_DCP_CSCCOEFF0_C0(v)  \
+		(((v) << 16) & BM_DCP_CSCCOEFF0_C0)
+#define BP_DCP_CSCCOEFF0_UV_OFFSET	8
+#define BM_DCP_CSCCOEFF0_UV_OFFSET	0x0000FF00
+#define BF_DCP_CSCCOEFF0_UV_OFFSET(v)  \
+		(((v) << 8) & BM_DCP_CSCCOEFF0_UV_OFFSET)
+#define BP_DCP_CSCCOEFF0_Y_OFFSET	0
+#define BM_DCP_CSCCOEFF0_Y_OFFSET	0x000000FF
+#define BF_DCP_CSCCOEFF0_Y_OFFSET(v)  \
+		(((v) << 0) & BM_DCP_CSCCOEFF0_Y_OFFSET)
+
+#define HW_DCP_CSCCOEFF1	(0x00000390)
+
+#define BP_DCP_CSCCOEFF1_RSVD1	26
+#define BM_DCP_CSCCOEFF1_RSVD1	0xFC000000
+#define BF_DCP_CSCCOEFF1_RSVD1(v) \
+		(((v) << 26) & BM_DCP_CSCCOEFF1_RSVD1)
+#define BP_DCP_CSCCOEFF1_C1	16
+#define BM_DCP_CSCCOEFF1_C1	0x03FF0000
+#define BF_DCP_CSCCOEFF1_C1(v)  \
+		(((v) << 16) & BM_DCP_CSCCOEFF1_C1)
+#define BP_DCP_CSCCOEFF1_RSVD0	10
+#define BM_DCP_CSCCOEFF1_RSVD0	0x0000FC00
+#define BF_DCP_CSCCOEFF1_RSVD0(v)  \
+		(((v) << 10) & BM_DCP_CSCCOEFF1_RSVD0)
+#define BP_DCP_CSCCOEFF1_C4	0
+#define BM_DCP_CSCCOEFF1_C4	0x000003FF
+#define BF_DCP_CSCCOEFF1_C4(v)  \
+		(((v) << 0) & BM_DCP_CSCCOEFF1_C4)
+
+#define HW_DCP_CSCCOEFF2	(0x000003a0)
+
+#define BP_DCP_CSCCOEFF2_RSVD1	26
+#define BM_DCP_CSCCOEFF2_RSVD1	0xFC000000
+#define BF_DCP_CSCCOEFF2_RSVD1(v) \
+		(((v) << 26) & BM_DCP_CSCCOEFF2_RSVD1)
+#define BP_DCP_CSCCOEFF2_C2	16
+#define BM_DCP_CSCCOEFF2_C2	0x03FF0000
+#define BF_DCP_CSCCOEFF2_C2(v)  \
+		(((v) << 16) & BM_DCP_CSCCOEFF2_C2)
+#define BP_DCP_CSCCOEFF2_RSVD0	10
+#define BM_DCP_CSCCOEFF2_RSVD0	0x0000FC00
+#define BF_DCP_CSCCOEFF2_RSVD0(v)  \
+		(((v) << 10) & BM_DCP_CSCCOEFF2_RSVD0)
+#define BP_DCP_CSCCOEFF2_C3	0
+#define BM_DCP_CSCCOEFF2_C3	0x000003FF
+#define BF_DCP_CSCCOEFF2_C3(v)  \
+		(((v) << 0) & BM_DCP_CSCCOEFF2_C3)
+
+#define HW_DCP_CSCCLIP	(0x000003d0)
+
+#define BP_DCP_CSCCLIP_RSVD1	24
+#define BM_DCP_CSCCLIP_RSVD1	0xFF000000
+#define BF_DCP_CSCCLIP_RSVD1(v) \
+		(((v) << 24) & BM_DCP_CSCCLIP_RSVD1)
+#define BP_DCP_CSCCLIP_HEIGHT	12
+#define BM_DCP_CSCCLIP_HEIGHT	0x00FFF000
+#define BF_DCP_CSCCLIP_HEIGHT(v)  \
+		(((v) << 12) & BM_DCP_CSCCLIP_HEIGHT)
+#define BP_DCP_CSCCLIP_WIDTH	0
+#define BM_DCP_CSCCLIP_WIDTH	0x00000FFF
+#define BF_DCP_CSCCLIP_WIDTH(v)  \
+		(((v) << 0) & BM_DCP_CSCCLIP_WIDTH)
+
+#define HW_DCP_CSCXSCALE	(0x000003e0)
+
+#define BP_DCP_CSCXSCALE_RSVD1	26
+#define BM_DCP_CSCXSCALE_RSVD1	0xFC000000
+#define BF_DCP_CSCXSCALE_RSVD1(v) \
+		(((v) << 26) & BM_DCP_CSCXSCALE_RSVD1)
+#define BP_DCP_CSCXSCALE_INT	24
+#define BM_DCP_CSCXSCALE_INT	0x03000000
+#define BF_DCP_CSCXSCALE_INT(v)  \
+		(((v) << 24) & BM_DCP_CSCXSCALE_INT)
+#define BP_DCP_CSCXSCALE_FRAC	12
+#define BM_DCP_CSCXSCALE_FRAC	0x00FFF000
+#define BF_DCP_CSCXSCALE_FRAC(v)  \
+		(((v) << 12) & BM_DCP_CSCXSCALE_FRAC)
+#define BP_DCP_CSCXSCALE_WIDTH	0
+#define BM_DCP_CSCXSCALE_WIDTH	0x00000FFF
+#define BF_DCP_CSCXSCALE_WIDTH(v)  \
+		(((v) << 0) & BM_DCP_CSCXSCALE_WIDTH)
+
+#define HW_DCP_CSCYSCALE	(0x000003f0)
+
+#define BP_DCP_CSCYSCALE_RSVD1	26
+#define BM_DCP_CSCYSCALE_RSVD1	0xFC000000
+#define BF_DCP_CSCYSCALE_RSVD1(v) \
+		(((v) << 26) & BM_DCP_CSCYSCALE_RSVD1)
+#define BP_DCP_CSCYSCALE_INT	24
+#define BM_DCP_CSCYSCALE_INT	0x03000000
+#define BF_DCP_CSCYSCALE_INT(v)  \
+		(((v) << 24) & BM_DCP_CSCYSCALE_INT)
+#define BP_DCP_CSCYSCALE_FRAC	12
+#define BM_DCP_CSCYSCALE_FRAC	0x00FFF000
+#define BF_DCP_CSCYSCALE_FRAC(v)  \
+		(((v) << 12) & BM_DCP_CSCYSCALE_FRAC)
+#define BP_DCP_CSCYSCALE_HEIGHT	0
+#define BM_DCP_CSCYSCALE_HEIGHT	0x00000FFF
+#define BF_DCP_CSCYSCALE_HEIGHT(v)  \
+		(((v) << 0) & BM_DCP_CSCYSCALE_HEIGHT)
+
+#define HW_DCP_DBGSELECT	(0x00000400)
+
+#define BP_DCP_DBGSELECT_RSVD	8
+#define BM_DCP_DBGSELECT_RSVD	0xFFFFFF00
+#define BF_DCP_DBGSELECT_RSVD(v) \
+		(((v) << 8) & BM_DCP_DBGSELECT_RSVD)
+#define BP_DCP_DBGSELECT_INDEX	0
+#define BM_DCP_DBGSELECT_INDEX	0x000000FF
+#define BF_DCP_DBGSELECT_INDEX(v)  \
+		(((v) << 0) & BM_DCP_DBGSELECT_INDEX)
+#define BV_DCP_DBGSELECT_INDEX__CONTROL 0x01
+#define BV_DCP_DBGSELECT_INDEX__OTPKEY0 0x10
+#define BV_DCP_DBGSELECT_INDEX__OTPKEY1 0x11
+#define BV_DCP_DBGSELECT_INDEX__OTPKEY2 0x12
+#define BV_DCP_DBGSELECT_INDEX__OTPKEY3 0x13
+
+#define HW_DCP_DBGDATA	(0x00000410)
+
+#define BP_DCP_DBGDATA_DATA	0
+#define BM_DCP_DBGDATA_DATA	0xFFFFFFFF
+#define BF_DCP_DBGDATA_DATA(v)	(v)
+
+#define HW_DCP_PAGETABLE	(0x00000420)
+
+#define BP_DCP_PAGETABLE_BASE	2
+#define BM_DCP_PAGETABLE_BASE	0xFFFFFFFC
+#define BF_DCP_PAGETABLE_BASE(v) \
+		(((v) << 2) & BM_DCP_PAGETABLE_BASE)
+#define BM_DCP_PAGETABLE_FLUSH	0x00000002
+#define BM_DCP_PAGETABLE_ENABLE	0x00000001
+
+#define HW_DCP_VERSION	(0x00000430)
+
+#define BP_DCP_VERSION_MAJOR	24
+#define BM_DCP_VERSION_MAJOR	0xFF000000
+#define BF_DCP_VERSION_MAJOR(v) \
+		(((v) << 24) & BM_DCP_VERSION_MAJOR)
+#define BP_DCP_VERSION_MINOR	16
+#define BM_DCP_VERSION_MINOR	0x00FF0000
+#define BF_DCP_VERSION_MINOR(v)  \
+		(((v) << 16) & BM_DCP_VERSION_MINOR)
+#define BP_DCP_VERSION_STEP	0
+#define BM_DCP_VERSION_STEP	0x0000FFFF
+#define BF_DCP_VERSION_STEP(v)  \
+		(((v) << 0) & BM_DCP_VERSION_STEP)
+
+#endif
diff --git a/include/linux/fsl/fsl-dcp_bootstream_ioctl.h b/include/linux/fsl/fsl-dcp_bootstream_ioctl.h
new file mode 100644
index 0000000..2859a8d
--- /dev/null
+++ b/include/linux/fsl/fsl-dcp_bootstream_ioctl.h
@@ -0,0 +1,32 @@
+/*
+ * Freescale DCP driver for bootstream update. Only handles the OTP KEY
+ * case and can only encrypt/decrypt.
+ *
+ * Author: Pantelis Antoniou <pantelis at embeddedalley.com>
+ *
+ * Copyright (C) 2008-2010 Freescale Semiconductor, Inc. All Rights Reserved.
+ * Copyright 2008 Embedded Alley Solutions, Inc All Rights Reserved.
+ */
+
+/*
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+#ifndef DCP_BOOTSTREAM_IOCTL_H
+#define DCP_BOOTSTREAM_IOCTL_H
+
+/* remember to have included the proper _IO definition
+ * file before hand.
+ * For user space it's <sys/ioctl.h>
+ */
+
+#define DBS_IOCTL_BASE   'd'
+
+#define DBS_ENC _IOW(DBS_IOCTL_BASE, 0x00, uint8_t[16])
+#define DBS_DEC _IOW(DBS_IOCTL_BASE, 0x01, uint8_t[16])
+
+#endif
-- 
1.7.9.5



From cb at sgoc.de  Fri Apr 26 07:20:13 2013
From: cb at sgoc.de (Christoph G. Baumann)
Date: Fri, 26 Apr 2013 13:20:13 +0200
Subject: [PATCH 0/2] crypto: added support for fsl-dcp on iMX23,28,50
Message-ID: <1366975215-5420-1-git-send-email-cb@sgoc.de>

From: "Christoph G. Baumann" <cb at sgoc.de>

This patch is based on the original driver by Freescale.
The driver gives access to the DCP crypto core which can accelerate
AES and SHA operations.
It was ported to the current API and sanitized to please checkpatch.pl.

Christoph G. Baumann (2):
  crypto: added support for fsl-dcp on iMX23,28,50
  crypto: added support for fsl-dcp on iMX23,28,50

 arch/arm/boot/dts/imx28.dtsi                 |    2 +-
 drivers/staging/Kconfig                      |    2 +
 drivers/staging/Makefile                     |    1 +
 drivers/staging/crypto/Kconfig               |   15 +
 drivers/staging/crypto/Makefile              |    1 +
 drivers/staging/crypto/fsl-dcp.c             | 1790 ++++++++++++++++++++++++++
 drivers/staging/crypto/fsl-dcp.h             |  739 +++++++++++
 include/linux/fsl/fsl-dcp_bootstream_ioctl.h |   32 +
 8 files changed, 2581 insertions(+), 1 deletion(-)
 create mode 100644 drivers/staging/crypto/Kconfig
 create mode 100644 drivers/staging/crypto/Makefile
 create mode 100644 drivers/staging/crypto/fsl-dcp.c
 create mode 100644 drivers/staging/crypto/fsl-dcp.h
 create mode 100644 include/linux/fsl/fsl-dcp_bootstream_ioctl.h

-- 
1.7.9.5



From peter.maydell at linaro.org  Fri Apr 26 07:33:50 2013
From: peter.maydell at linaro.org (Peter Maydell)
Date: Fri, 26 Apr 2013 12:33:50 +0100
Subject: [PATCH 0/2] Early printk support for virtio console devices.
In-Reply-To: <BA2076A6-0688-4E5C-85F9-A9CA8FD75782@suse.de>
References: <1366974299-17877-1-git-send-email-pranavkumar@linaro.org>
 <BA2076A6-0688-4E5C-85F9-A9CA8FD75782@suse.de>
Message-ID: <CAFEAcA_xmrHTvR7FxUr3PCKBJY-hZnkeBcqyHksTB4-hqOZS0w@mail.gmail.com>

On 26 April 2013 12:19, Alexander Graf <agraf at suse.de> wrote:
> MMIO registers are handled by a different layer than the virtio
> console itself. After the virtio refactoring in QEMU, they will
> be completely separate drivers.

Good point -- we don't really want to be mixing up the
transport and the backend. You can see it in the kvmtool
patch, in fact -- it introduces an "if this is virtio-console"
special case into the mmio.c file which previously was
entirely backend agnostic.

thanks
-- PMM


From vincent.guittot at linaro.org  Fri Apr 26 07:34:32 2013
From: vincent.guittot at linaro.org (Vincent Guittot)
Date: Fri, 26 Apr 2013 13:34:32 +0200
Subject: [RFC PATCH v3 3/6] sched: pack small tasks
In-Reply-To: <20130426103019.GE8669@dyad.programming.kicks-ass.net>
References: <1363955155-18382-1-git-send-email-vincent.guittot@linaro.org>
 <1363955155-18382-4-git-send-email-vincent.guittot@linaro.org>
 <1364300782.5053.6.camel@laptop>
 <5152C83F.6060509@linux.vnet.ibm.com>
 <CAKfTPtCphgnT6_WSdHJR+_GcdfroL+OFhiqsr_rBFx5=apkTVQ@mail.gmail.com>
 <20130426103019.GE8669@dyad.programming.kicks-ass.net>
Message-ID: <CAKfTPtAWctPEz+TO-zaJCYbn0m=3vahCJ6-jK65O5Qe06MfOXA@mail.gmail.com>

On 26 April 2013 12:30, Peter Zijlstra <peterz at infradead.org> wrote:
> On Wed, Mar 27, 2013 at 12:00:40PM +0100, Vincent Guittot wrote:
>> On 27 March 2013 11:21, Preeti U Murthy <preeti at linux.vnet.ibm.com> wrote:
>> > Hi,
>> >
>> > On 03/26/2013 05:56 PM, Peter Zijlstra wrote:
>> >> On Fri, 2013-03-22 at 13:25 +0100, Vincent Guittot wrote:
>> >>> +static bool is_buddy_busy(int cpu)
>> >>> +{
>> >>> +       struct rq *rq = cpu_rq(cpu);
>> >>> +
>> >>> +       /*
>> >>> +        * A busy buddy is a CPU with a high load or a small load with
>> >>> a lot of
>> >>> +        * running tasks.
>> >>> +        */
>> >>> +       return (rq->avg.runnable_avg_sum >
>> >>> +                       (rq->avg.runnable_avg_period / (rq->nr_running
>> >>> + 2)));
>> >>> +}
>> >>
>> >> Why does the comment talk about load but we don't see it in the
>> >> equation. Also, why does nr_running matter at all? I thought we'd
>> >> simply bother with utilization, if fully utilized we're done etc..
>>
>> By load, I mean : 100 * avg.runnable_avg_sum / avg.runnable_avg_period
>> In addition, i take into account the number of tasks already in the
>> runqueue in order to define the business of a CPU. A CPU with a load
>> of 50% without any tasks in the runqeue in not busy at this time and
>> we can migrate tasks on it but if the CPU already has 2 tasks in its
>> runqueue, it means that newly wake up task will have to share the CPU
>> with other tasks so we consider that the CPU is already busy and we
>> will fall back to default behavior. The equation considers that a CPU
>> is not busy if
>> 100 * avg.runnable_avg_sum / avg.runnable_avg_period < 100 / (nr_running + 2)
>
> I'm still somewhat confused by all this. So raising nr_running will lower the
> required utilization to be considered busy. Suppose we have 50 tasks running,
> all at 1% utilization (bulk wakeup) we'd consider the cpu busy, even though its
> picking its nose for half the time.
>
>
> I'm assuming it's mean to limit process latency or so? Why are you concerned
> with that? This seems like an arbitrary power vs performance tweak without
> solid effidence its needed or even wanted.

Yes the goal was to limit the wake up latency because this version was
only trying to modify the scheduler behavior when the system was not
busy in order to pack the small tasks like background activities but
without decreasing the performance so we were concerned by wakeup
latency.

The new version proposes a more aggressive mode that packs all tasks
until CPUs becomes full.

Vincent


From pavel at denx.de  Fri Apr 26 07:36:51 2013
From: pavel at denx.de (Pavel Machek)
Date: Fri, 26 Apr 2013 13:36:51 +0200
Subject: dw_apb_timer_of.c: remove parts that were picoxcell-specific
In-Reply-To: <1366843482.29992.4.camel@linux-builds1>
References: <20130423105827.GA6983@amd.pavel.ucw.cz>
 <1366843482.29992.4.camel@linux-builds1>
Message-ID: <20130426113651.GA16289@amd.pavel.ucw.cz>

Hi!

> > -void __init dw_apb_timer_init(void)
> > +void __init dw_apb_timer_init(int use_as_scheduler)
> >  {
> >  	struct device_node *event_timer, *source_timer;
> > +	u32 rate;
> 
> You're not using rate anywhere in this function.
> 
> drivers/clocksource/dw_apb_timer_of.c: In function ?dw_apb_timer_init?:
> drivers/clocksource/dw_apb_timer_of.c:110:6: warning: unused variable
> ?rate?

Thanks, fixed.

> >  struct dw_apb_timer {
> > @@ -53,5 +59,5 @@ void dw_apb_clocksource_start(struct dw_apb_clocksource *dw_cs);
> >  cycle_t dw_apb_clocksource_read(struct dw_apb_clocksource *dw_cs);
> >  void dw_apb_clocksource_unregister(struct dw_apb_clocksource *dw_cs);
> >  
> > -extern void dw_apb_timer_init(void);
> > +extern void dw_apb_timer_init(int);
> >  #endif /* __DW_APB_TIMER_H__ */
> 
> On SOCFPGA:
> 
> Tested-by: Dinh Nguyen <dinguyen at altera.com>

Thanks! New patch is going out in few minutes.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


From lee.jones at linaro.org  Fri Apr 26 07:39:47 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Fri, 26 Apr 2013 12:39:47 +0100
Subject: [PATCH 03/32 v4] dmaengine: ste_dma40: Use the BIT macro to replace
 ugly '(1 << x)'s
In-Reply-To: <1366279934-30761-4-git-send-email-lee.jones@linaro.org>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-4-git-send-email-lee.jones@linaro.org>
Message-ID: <20130426113947.GB31899@gmail.com>

The aim is to make the code that little more readable.
    
Acked-by: Vinod Koul <vnod.koul at intel.com>
Acked-by: Arnd Bergmann <arnd at arndb.de>
Signed-off-by: Lee Jones <lee.jones at linaro.org>

diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index d7e926d..78511ef 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -54,8 +54,8 @@
 #define MAX_LCLA_ALLOC_ATTEMPTS 256
 
 /* Bit markings for allocation map */
-#define D40_ALLOC_FREE		(1 << 31)
-#define D40_ALLOC_PHY		(1 << 30)
+#define D40_ALLOC_FREE		BIT(31)
+#define D40_ALLOC_PHY		BIT(30)
 #define D40_ALLOC_LOG_FREE	0
 
 #define D40_IS_SRC(dir)  (dir == STEDMA40_PERIPH_TO_MEM)
@@ -1728,7 +1728,7 @@ static irqreturn_t d40_handle_interrupt(int irq, void *data)
 		}
 
 		/* ACK interrupt */
-		writel(1 << idx, base->virtbase + il[row].clr);
+		writel(BIT(idx), base->virtbase + il[row].clr);
 
 		spin_lock(&d40c->lock);
 
@@ -1818,8 +1818,8 @@ static bool d40_alloc_mask_set(struct d40_phy_res *phy,
 		if (phy->allocated_src == D40_ALLOC_FREE)
 			phy->allocated_src = D40_ALLOC_LOG_FREE;
 
-		if (!(phy->allocated_src & (1 << log_event_line))) {
-			phy->allocated_src |= 1 << log_event_line;
+		if (!(phy->allocated_src & BIT(log_event_line))) {
+			phy->allocated_src |= BIT(log_event_line);
 			goto found;
 		} else
 			goto not_found;
@@ -1830,8 +1830,8 @@ static bool d40_alloc_mask_set(struct d40_phy_res *phy,
 		if (phy->allocated_dst == D40_ALLOC_FREE)
 			phy->allocated_dst = D40_ALLOC_LOG_FREE;
 
-		if (!(phy->allocated_dst & (1 << log_event_line))) {
-			phy->allocated_dst |= 1 << log_event_line;
+		if (!(phy->allocated_dst & BIT(log_event_line))) {
+			phy->allocated_dst |= BIT(log_event_line);
 			goto found;
 		} else
 			goto not_found;
@@ -1861,11 +1861,11 @@ static bool d40_alloc_mask_free(struct d40_phy_res *phy, bool is_src,
 
 	/* Logical channel */
 	if (is_src) {
-		phy->allocated_src &= ~(1 << log_event_line);
+		phy->allocated_src &= ~BIT(log_event_line);
 		if (phy->allocated_src == D40_ALLOC_LOG_FREE)
 			phy->allocated_src = D40_ALLOC_FREE;
 	} else {
-		phy->allocated_dst &= ~(1 << log_event_line);
+		phy->allocated_dst &= ~BIT(log_event_line);
 		if (phy->allocated_dst == D40_ALLOC_LOG_FREE)
 			phy->allocated_dst = D40_ALLOC_FREE;
 	}
@@ -2333,7 +2333,7 @@ static void __d40_set_prio_rt(struct d40_chan *d40c, int dev_type, bool src)
 	u32 rtreg;
 	u32 event = D40_TYPE_TO_EVENT(dev_type);
 	u32 group = D40_TYPE_TO_GROUP(dev_type);
-	u32 bit = 1 << event;
+	u32 bit = BIT(event);
 	u32 prioreg;
 	struct d40_gen_dmac *dmac = &d40c->base->gen_dmac;


From mark.rutland at arm.com  Fri Apr 26 07:48:11 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Fri, 26 Apr 2013 12:48:11 +0100
Subject: [RFC PATCH v3 02/17] Documentation: devicetree: arm: cpus/cpu
 nodes bindings updates
In-Reply-To: <20130426101839.GA3093@e102568-lin.cambridge.arm.com>
References: <1366824502-19729-1-git-send-email-lorenzo.pieralisi@arm.com>
 <1366824502-19729-3-git-send-email-lorenzo.pieralisi@arm.com>
 <CAL_JsqL2QOjTffogB6g7VK7oRUwDAmJpr=36uvFXjd+hpBL89A@mail.gmail.com>
 <20130426101839.GA3093@e102568-lin.cambridge.arm.com>
Message-ID: <20130426114811.GD11648@e106331-lin.cambridge.arm.com>

On Fri, Apr 26, 2013 at 11:18:40AM +0100, Lorenzo Pieralisi wrote:
> On Fri, Apr 26, 2013 at 03:51:10AM +0100, Rob Herring wrote:
> > On Wed, Apr 24, 2013 at 12:28 PM, Lorenzo Pieralisi
> > <lorenzo.pieralisi at arm.com> wrote:
> > > In order to extend the current cpu nodes bindings to newer CPUs
> > > inclusive of AArch64 and to update support for older ARM CPUs this
> > > patch updates device tree documentation for the cpu nodes bindings.
> > >
> > > Main changes:
> > >     - adds 64-bit bindings
> > >     - define usage of #address-cells
> > >     - define 32/64 dts compatibility settings
> > >     - defines behaviour on pre and post v7 uniprocessor systems
> > >     - adds ARM 11MPcore specific reg property definition
> > >
> > > Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
> > > ---
> > 
> > [...]
> > 
> > > +       - enable-method
> > > +               Value type: <stringlist>
> > > +               Usage and definition depend on ARM architecture version and
> > > +               configuration:
> > > +                       # On ARM v8 64-bit systems running the OS in AArch64,
> > > +                         this property is required and must be "spin-table".
> > 
> > What about PSCI?
> 
> I should add it, at least for ARM v8.

It's worth noting KVM uses it on v7 too, so it should be available for CPUs
that are v7+.

> 
> > I don't think the ePAPR spin-table definition is sufficient for ARM.
> > How do you define wake up by SGI or sev instruction.
> 
> I think Will described the wfe/sev mechanism in:
> 
> Documentation/arm64/booting.txt
> 
> and the ePAPR does the same in 5.5.2.2/5.5.2.3. Since this is a document
> describing cpus/cpu nodes bindings I assume that description does not
> belong here. Question is: do we need to specify an ARM implementation
> specific enable-method to describe SGI/sev wake-up (ePAPR 5.5.3) ?
> 
> > > +                       # On ARM 32-bit systems or ARM v8 systems running
> > > +                         the OS in AArch32 this property is prohibited.
> > 
> > Why?
> 
> Because if we define it optional with no possible set of values basically
> it can be whatever string. I could define it optional with the same
> allowed values as ARM v8 even if it is currently ignored, at least in Linux,
> until PSCI implementations get merged.

I believe kvmtool sets the enable-method to "psci" on v7, though I may be
mistaken. Adding Marc to Cc as he knows better.

Cheers,
Mark.


From rjw at sisk.pl  Fri Apr 26 08:03:56 2013
From: rjw at sisk.pl (Rafael J. Wysocki)
Date: Fri, 26 Apr 2013 14:03:56 +0200
Subject: [PATCH 1/2] ARM: s3c64xx: cpuidle: use init/exit common routine
In-Reply-To: <51794C35.6070400@samsung.com>
References: <1366728077-18988-1-git-send-email-daniel.lezcano@linaro.org>
 <5178F8E0.6010606@linaro.org> <51794C35.6070400@samsung.com>
Message-ID: <2024174.Hoa4RbDIF3@vostro.rjw.lan>

On Friday, April 26, 2013 12:31:01 AM Kukjin Kim wrote:
> On 04/25/13 18:35, Daniel Lezcano wrote:
> > On 04/23/2013 04:41 PM, Daniel Lezcano wrote:
> >> Remove the duplicated code and use the cpuidle common code for initialization.
> >>
> >> Signed-off-by: Daniel Lezcano<daniel.lezcano at linaro.org>
> >> ---
> >
> > Hi Kim and Ben,
> >
> > It is the last patch in the series which was not acked-by.
> > Rafael is willing to take it in its tree if you ack it.
> >
> > Are you ok if this patch ?
> >
> Looks OK to me, please go ahead with my ack if you want:
> 
> Acked-by: Kukjin Kim <kgene.kim at samsung.com>

Applied.

Thanks,
Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.


From rjw at sisk.pl  Fri Apr 26 08:05:23 2013
From: rjw at sisk.pl (Rafael J. Wysocki)
Date: Fri, 26 Apr 2013 14:05:23 +0200
Subject: [V2 PATCH] cpuidle: add maintainer entry
In-Reply-To: <1366974344-26064-1-git-send-email-daniel.lezcano@linaro.org>
References: <1366974344-26064-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1816154.nn5b7kMrPv@vostro.rjw.lan>

On Friday, April 26, 2013 01:05:44 PM Daniel Lezcano wrote:
> Currently the cpuidle drivers are spread across the different archs.
> 
> The patch submission for cpuidle are following different path: the cpuidle core
> code goes to linux-pm, the ARM drivers goes to arm-soc or the SoC specific
> tree, sh goes through sh arch tree, pseries goes through PowerPC and
> finally intel goes through Len's tree while acpi_idle goes under linux-pm.
> 
> That makes difficult to consolidate the code and to propagate modifications
> from the cpuidle core to the different drivers.
> 
> Hopefully, a movement has initiated to put the cpuidle drivers into the
> drivers/cpuidle directory like cpuidle-calxeda.c and cpuidle-kirkwood.c
> 
> Add an explicit maintainer entry in the MAINTAINER to clarify the situation
> and prevent new cpuidle drivers to goes to an arch directory.
> 
> The upstreaming process is unchanged: Rafael takes the patches to merge them
> into its tree but with the acked-by from the driver's maintainer. So the header
> must contains the name of the maintainer.
> 
> This organization will be the same than cpufreq.

Applied (with modified changelog).

One consequence of this is that I'll be asking you to ACK changes in
ARM cpuidle drivers. :-)

Thanks,
Rafael


> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
> Acked-by: Linus Walleij <linus.walleij at linaro.org>
> Acked-by: Andrew Lunn <andrew at lunn.ch>  #for kirkwood
> Acked-by: Jason Cooper <jason at lakedaemon.net> #for kirkwood
> ---
>  MAINTAINERS                        |    9 +++++++++
>  drivers/cpuidle/cpuidle-calxeda.c  |    4 +++-
>  drivers/cpuidle/cpuidle-kirkwood.c |    5 +++--
>  3 files changed, 15 insertions(+), 3 deletions(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 61677c3..45ee6dc 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2217,6 +2217,15 @@ F:	drivers/cpufreq/arm_big_little.h
>  F:	drivers/cpufreq/arm_big_little.c
>  F:	drivers/cpufreq/arm_big_little_dt.c
>  
> +CPUIDLE DRIVERS
> +M:	Rafael J. Wysocki <rjw at sisk.pl>
> +M:	Daniel Lezcano <daniel.lezcano at linaro.org>
> +L:	linux-pm at vger.kernel.org
> +S:	Maintained
> +T:	git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git
> +F:	drivers/cpuidle/*
> +F:	include/linux/cpuidle.h
> +
>  CPUID/MSR DRIVER
>  M:	"H. Peter Anvin" <hpa at zytor.com>
>  S:	Maintained
> diff --git a/drivers/cpuidle/cpuidle-calxeda.c b/drivers/cpuidle/cpuidle-calxeda.c
> index e344b56..2233791 100644
> --- a/drivers/cpuidle/cpuidle-calxeda.c
> +++ b/drivers/cpuidle/cpuidle-calxeda.c
> @@ -1,7 +1,7 @@
>  /*
>   * Copyright 2012 Calxeda, Inc.
>   *
> - * Based on arch/arm/plat-mxc/cpuidle.c:
> + * Based on arch/arm/plat-mxc/cpuidle.c: #v3.7
>   * Copyright 2012 Freescale Semiconductor, Inc.
>   * Copyright 2012 Linaro Ltd.
>   *
> @@ -16,6 +16,8 @@
>   *
>   * You should have received a copy of the GNU General Public License along with
>   * this program.  If not, see <http://www.gnu.org/licenses/>.
> + *
> + * Maintainer: Rob Herring <rob.herring at calxeda.com>
>   */
>  
>  #include <linux/cpuidle.h>
> diff --git a/drivers/cpuidle/cpuidle-kirkwood.c b/drivers/cpuidle/cpuidle-kirkwood.c
> index 53290e1..521b0a7 100644
> --- a/drivers/cpuidle/cpuidle-kirkwood.c
> +++ b/drivers/cpuidle/cpuidle-kirkwood.c
> @@ -1,6 +1,4 @@
>  /*
> - * arch/arm/mach-kirkwood/cpuidle.c
> - *
>   * CPU idle Marvell Kirkwood SoCs
>   *
>   * This file is licensed under the terms of the GNU General Public
> @@ -11,6 +9,9 @@
>   * to implement two idle states -
>   * #1 wait-for-interrupt
>   * #2 wait-for-interrupt and DDR self refresh
> + *
> + * Maintainer: Jason Cooper <jason at lakedaemon.net>
> + * Maintainer: Andrew Lunn <andrew at lunn.ch>
>   */
>  
>  #include <linux/kernel.h>
> 
-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.


From anup.patel at linaro.org  Fri Apr 26 08:06:16 2013
From: anup.patel at linaro.org (Anup Patel)
Date: Fri, 26 Apr 2013 17:36:16 +0530
Subject: [PATCH 0/2] Early printk support for virtio console devices.
In-Reply-To: <CAFEAcA_xmrHTvR7FxUr3PCKBJY-hZnkeBcqyHksTB4-hqOZS0w@mail.gmail.com>
References: <1366974299-17877-1-git-send-email-pranavkumar@linaro.org>
 <BA2076A6-0688-4E5C-85F9-A9CA8FD75782@suse.de>
 <CAFEAcA_xmrHTvR7FxUr3PCKBJY-hZnkeBcqyHksTB4-hqOZS0w@mail.gmail.com>
Message-ID: <CALrVBkuOmu4u9egdzzfn1tU9B-CFe3w85HZQ9s2gpKvYnaSqvA@mail.gmail.com>

On 26 April 2013 17:03, Peter Maydell <peter.maydell at linaro.org> wrote:
> On 26 April 2013 12:19, Alexander Graf <agraf at suse.de> wrote:
>> MMIO registers are handled by a different layer than the virtio
>> console itself. After the virtio refactoring in QEMU, they will
>> be completely separate drivers.
>
> Good point -- we don't really want to be mixing up the
> transport and the backend. You can see it in the kvmtool
> patch, in fact -- it introduces an "if this is virtio-console"
> special case into the mmio.c file which previously was
> entirely backend agnostic.

Well, we can always have virtio device specific config registers
handle by virtio device backends and generic virtio config register
handled by transport.

kvmtool patch is hacky because it does not provide virtio device
specific config read/write callbacks.

>
> thanks
> -- PMM
> _______________________________________________
> kvmarm mailing list
> kvmarm at lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm

--Anup


From vincent.guittot at linaro.org  Fri Apr 26 08:08:27 2013
From: vincent.guittot at linaro.org (Vincent Guittot)
Date: Fri, 26 Apr 2013 14:08:27 +0200
Subject: [RFC PATCH v4 00/14] sched: packing small tasks
In-Reply-To: <1366910611-20048-1-git-send-email-vincent.guittot@linaro.org>
References: <1366910611-20048-1-git-send-email-vincent.guittot@linaro.org>
Message-ID: <CAKfTPtAekZSMKjVQEzdN1Dhz_TfJwG=6Fw9ZNbcNdQyg5zQuaQ@mail.gmail.com>

Hi,

The patches are available in this git tree:
git://git.linaro.org/people/vingu/kernel.git sched-pack-small-tasks-v4-fixed

Vincent

On 25 April 2013 19:23, Vincent Guittot <vincent.guittot at linaro.org> wrote:
> Hi,
>
> This patchset takes advantage of the new per-task load tracking that is
> available in the kernel for packing the tasks in as few as possible
> CPU/Cluster/Core. It has got 2 packing modes:
> -The 1st mode packs the small tasks when the system is not too busy. The main
> goal is to reduce the power consumption in the low system load use cases by
> minimizing the number of power domain that are enabled but it also keeps the
> default behavior which is performance oriented.
> -The 2nd mode packs all tasks in as few as possible power domains in order to
> improve the power consumption of the system but at the cost of possible
> performance decrease because of the increase of the rate of ressources sharing
> compared to the default mode.
>
> The packing is done in 3 steps (the last step is only applicable for the
> agressive packing mode):
>
> The 1st step looks for the best place to pack tasks in a system according to
> its topology and it defines a 1st pack buddy CPU for each CPU if there is one
> available. The policy for defining a buddy CPU is that we want to pack at
> levels where a group of CPU can be power gated independently from others. To
> describe this capability, a new flag SD_SHARE_POWERDOMAIN has been introduced,
> that is used to indicate whether the groups of CPUs of a scheduling domain
> share their power state. By default, this flag is set in all sched_domain in
> order to keep unchanged the current behavior of the scheduler and only ARM
> platform clears the SD_SHARE_POWERDOMAIN flag for MC and CPU level.
>
> In a 2nd step, the scheduler checks the load average of a task which wakes up
> as well as the load average of the buddy CPU and it can decide to migrate the
> light tasks on a not busy buddy. This check is done during the wake up because
> small tasks tend to wake up between periodic load balance and asynchronously
> to each other which prevents the default mechanism to catch and migrate them
> efficiently. A light task is defined by a runnable_avg_sum that is less than
> 20% of the runnable_avg_period. In fact, the former condition encloses 2 ones:
> The average CPU load of the task must be less than 20% and the task must have
> been runnable less than 10ms when it woke up last time in order to be
> electable for the packing migration. So, a task than runs 1 ms each 5ms will
> be considered as a small task but a task that runs 50 ms with a period of
> 500ms, will not.
> Then, the business of the buddy CPU depends of the load average for the rq and
> the number of running tasks. A CPU with a load average greater than 50% will
> be considered as busy CPU whatever the number of running tasks is and this
> threshold will be reduced by the number of running tasks in order to not
> increase too much the wake up latency of a task. When the buddy CPU is busy,
> the scheduler falls back to default CFS policy.
>
> The 3rd step is only used when the agressive packing mode is enable. In this
> case, the CPUs pack their tasks in their buddy until they becomes full. Unlike
> the previous step, we can't keep the same buddy so we update it during load
> balance. During the periodic load balance, the scheduler computes the activity
> of the system thanks the runnable_avg_sum and the cpu_power of all CPUs and
> then it defines the CPUs that will be used to handle the current activity. The
> selected CPUs will be their own buddy and will participate to the default
> load balancing mecanism in order to share the tasks in a fair way, whereas the
> not selected CPUs will not, and their buddy will be the last selected CPU.
> The behavior can be summarized as: The scheduler defines how many CPUs are
> required to handle the current activity, keeps the tasks on these CPUS and
> perform normal load balancing (or any evolution of the current load balancer
> like the use of runnable load avg from Alex https://lkml.org/lkml/2013/4/1/580)
> on this limited number of CPUs . Like the other steps, the CPUs are selected to
> minimize the number of power domain that must stay on.
>
> Change since V3:
>
>  - Take into account comments on previous version.
>  - Add an agressive packing mode and a knob to select between the various mode
>
> Change since V2:
>
>  - Migrate only a task that wakes up
>  - Change the light tasks threshold to 20%
>  - Change the loaded CPU threshold to not pull tasks if the current number of
>    running tasks is null but the load average is already greater than 50%
>  - Fix the algorithm for selecting the buddy CPU.
>
> Change since V1:
>
> Patch 2/6
>  - Change the flag name which was not clear. The new name is
>    SD_SHARE_POWERDOMAIN.
>  - Create an architecture dependent function to tune the sched_domain flags
> Patch 3/6
>  - Fix issues in the algorithm that looks for the best buddy CPU
>  - Use pr_debug instead of pr_info
>  - Fix for uniprocessor
> Patch 4/6
>  - Remove the use of usage_avg_sum which has not been merged
> Patch 5/6
>  - Change the way the coherency of runnable_avg_sum and runnable_avg_period is
>    ensured
> Patch 6/6
>  - Use the arch dependent function to set/clear SD_SHARE_POWERDOMAIN for ARM
>    platform
>
> Previous results for v3:
>
> This series has been tested with hackbench on ARM platform and the results
> don't show any performance regression
>
> Hackbench             3.9-rc2  +patches
> Mean Time (10 tests): 2.048    2.015
> stdev               : 0.047    0.068
>
> Previous results for V2:
>
> This series has been tested with MP3 play back on ARM platform:
> TC2 HMP (dual CA-15 and 3xCA-7 cluster).
>
> The measurements have been done on an Ubuntu image during 60 seconds of
> playback and the result has been normalized to 100.
>
>               | CA15 | CA7  | total |
> -------------------------------------
> default       |  81  |   97 | 178   |
> pack          |  13  |  100 | 113   |
> -------------------------------------
>
> Previous results for V1:
>
> The patch-set has been tested on ARM platforms: quad CA-9 SMP and TC2 HMP
> (dual CA-15 and 3xCA-7 cluster). For ARM platform, the results have
> demonstrated that it's worth packing small tasks at all topology levels.
>
> The performance tests have been done on both platforms with sysbench. The
> results don't show any performance regressions. These results are aligned with
> the policy which uses the normal behavior with heavy use cases.
>
> test: sysbench --test=cpu --num-threads=N --max-requests=R run
>
> Results below is the average duration of 3 tests on the quad CA-9.
> default is the current scheduler behavior (pack buddy CPU is -1)
> pack is the scheduler with the pack mechanism
>
>               | default |  pack   |
> -----------------------------------
> N=8;  R=200   |  3.1999 |  3.1921 |
> N=8;  R=2000  | 31.4939 | 31.4844 |
> N=12; R=200   |  3.2043 |  3.2084 |
> N=12; R=2000  | 31.4897 | 31.4831 |
> N=16; R=200   |  3.1774 |  3.1824 |
> N=16; R=2000  | 31.4899 | 31.4897 |
> -----------------------------------
>
> The power consumption tests have been done only on TC2 platform which has got
> accessible power lines and I have used cyclictest to simulate small tasks. The
> tests show some power consumption improvements.
>
> test: cyclictest -t 8 -q -e 1000000 -D 20 & cyclictest -t 8 -q -e 1000000 -D 20
>
> The measurements have been done during 16 seconds and the result has been
> normalized to 100
>
>               | CA15 | CA7  | total |
> -------------------------------------
> default       | 100  |  40  | 140   |
> pack          |  <1  |  45  | <46   |
> -------------------------------------
>
> The A15 cluster is less power efficient than the A7 cluster but if we assume
> that the tasks is well spread on both clusters, we can guest estimate that the
> power consumption on a dual cluster of CA7 would have been for a default
> kernel:
>
>               | CA7  | CA7  | total |
> -------------------------------------
> default       |  40  |  40  |  80   |
> -------------------------------------
>
> Vincent Guittot (14):
>   Revert "sched: Introduce temporary FAIR_GROUP_SCHED dependency for
>     load-tracking"
>   sched: add a new SD_SHARE_POWERDOMAIN flag for sched_domain
>   sched: pack small tasks
>   sched: pack the idle load balance
>   ARM: sched: clear SD_SHARE_POWERDOMAIN
>   sched: add a knob to choose the packing level
>   sched: agressively pack at wake/fork/exec
>   sched: trig ILB on an idle buddy
>   sched: evaluate the activity level of the system
>   sched: update the buddy CPU
>   sched: filter task pull request
>   sched: create a new field with available capacity
>   sched: update the cpu_power
>   sched: force migration on buddy CPU
>
>  arch/arm/kernel/topology.c       |    9 +
>  arch/ia64/include/asm/topology.h |    1 +
>  arch/tile/include/asm/topology.h |    1 +
>  include/linux/sched.h            |   11 +-
>  include/linux/sched/sysctl.h     |    8 +
>  include/linux/topology.h         |    4 +
>  kernel/sched/core.c              |   14 +-
>  kernel/sched/fair.c              |  393 +++++++++++++++++++++++++++++++++++---
>  kernel/sched/sched.h             |   15 +-
>  kernel/sysctl.c                  |   13 ++
>  10 files changed, 423 insertions(+), 46 deletions(-)
>
> --
> 1.7.9.5
>


From pavel at denx.de  Fri Apr 26 08:14:34 2013
From: pavel at denx.de (Pavel Machek)
Date: Fri, 26 Apr 2013 14:14:34 +0200
Subject: dw_apb_timer_of.c: remove parts that were picoxcell-specific
Message-ID: <20130426121433.GA16249@amd.pavel.ucw.cz>

It seems we made a mistake when creating dw_apb_timer_of.c:
picoxcell sched_clock parts were not related to dw_apb_timer, yet
we moved them to dw_apb_timer_of, and tried to use them on socfpga.
    
This results in system where user/system time is not measured properly,
as demonstrated by
    
    time dd if=/dev/urandom of=/dev/zero bs=100000 count=100
    
    .
    
So this patch:
    
    1) moves picoxcell sched_clock parts back to picoxcell
    
    2) adds support to use dw_apb_timer s as sched_clock. Picoxcell could
    consider switching to these
    
    3) adds missing of_node_put() in dw_apb_timer_init().
    
Tested on socfpga, soc-next (3.9-rc6) based tree.
    
Signed-off-by: Pavel Machek <pavel at denx.de>
Tested-by: Dinh Nguyen <dinguyen at altera.com>

---

I think this is ready to go to soc-next tree. Please apply,
									Pavel


diff --git a/arch/arm/mach-picoxcell/common.c b/arch/arm/mach-picoxcell/common.c
index 70b441a..22759f5 100644
--- a/arch/arm/mach-picoxcell/common.c
+++ b/arch/arm/mach-picoxcell/common.c
@@ -84,11 +84,39 @@ static void picoxcell_wdt_restart(char mode, const char *cmd)
 	}
 }
 
+static const struct of_device_id picochip_rtc_ids[] __initconst = {
+        { .compatible = "picochip,pc3x2-rtc" },
+        { /* Sentinel */ },
+};
+
+static void __iomem *sched_io_base;
+
+static u32 read_sched_clock(void)
+{
+        return __raw_readl(sched_io_base);
+}
+
+static void __init timer_init(void)
+{
+	u32 rate;
+
+	dw_apb_timer_init(0);
+
+	sched_timer = of_find_matching_node(timer, osctimer_ids);
+	if (!sched_timer)
+		panic("No suitable timer for scheduler clock\n");
+
+	timer_get_base_and_rate(sched_timer, &sched_io_base, &rate);
+	of_node_put(sched_timer);
+
+	setup_sched_clock(read_sched_clock, 32, rate);
+}
+
 DT_MACHINE_START(PICOXCELL, "Picochip picoXcell")
 	.map_io		= picoxcell_map_io,
 	.nr_irqs	= NR_IRQS_LEGACY,
 	.init_irq	= irqchip_init,
-	.init_time	= dw_apb_timer_init,
+	.init_time	= timer_init,
 	.init_machine	= picoxcell_init_machine,
 	.dt_compat	= picoxcell_dt_match,
 	.restart	= picoxcell_wdt_restart,
diff --git a/arch/arm/mach-socfpga/socfpga.c b/arch/arm/mach-socfpga/socfpga.c
index 46a0513..3a030e5 100644
--- a/arch/arm/mach-socfpga/socfpga.c
+++ b/arch/arm/mach-socfpga/socfpga.c
@@ -116,11 +116,17 @@ static const char *altera_dt_match[] = {
 	NULL
 };
 
+static void __init timer_init(void)
+{
+	dw_apb_timer_init(1);
+}
+
+
 DT_MACHINE_START(SOCFPGA, "Altera SOCFPGA")
 	.smp		= smp_ops(socfpga_smp_ops),
 	.map_io		= socfpga_map_io,
 	.init_irq	= socfpga_init_irq,
-	.init_time	= dw_apb_timer_init,
+	.init_time	= timer_init,
 	.init_machine	= socfpga_cyclone5_init,
 	.restart	= socfpga_cyclone5_restart,
 	.dt_compat	= altera_dt_match,
diff --git a/drivers/clocksource/dw_apb_timer.c b/drivers/clocksource/dw_apb_timer.c
index 8c2a35f..460ac99 100644
--- a/drivers/clocksource/dw_apb_timer.c
+++ b/drivers/clocksource/dw_apb_timer.c
@@ -21,12 +21,6 @@
 #define APBT_MIN_PERIOD			4
 #define APBT_MIN_DELTA_USEC		200
 
-#define APBTMR_N_LOAD_COUNT		0x00
-#define APBTMR_N_CURRENT_VALUE		0x04
-#define APBTMR_N_CONTROL		0x08
-#define APBTMR_N_EOI			0x0c
-#define APBTMR_N_INT_STATUS		0x10
-
 #define APBTMRS_INT_STATUS		0xa0
 #define APBTMRS_EOI			0xa4
 #define APBTMRS_RAW_INT_STATUS		0xa8
diff --git a/drivers/clocksource/dw_apb_timer_of.c b/drivers/clocksource/dw_apb_timer_of.c
index ab09ed3..ac4ea00 100644
--- a/drivers/clocksource/dw_apb_timer_of.c
+++ b/drivers/clocksource/dw_apb_timer_of.c
@@ -57,7 +57,16 @@ static void add_clockevent(struct device_node *event_timer)
 	dw_apb_clockevent_register(ced);
 }
 
-static void add_clocksource(struct device_node *source_timer)
+static void __iomem *sched_io_base;
+
+/* This is actually same as __apbt_read_clocksource(), but with
+   different interface */
+static u32 read_sched_clock_sptimer(void)
+{
+	return ~__raw_readl(sched_io_base + APBTMR_N_CURRENT_VALUE);
+}
+
+static void add_clocksource(struct device_node *source_timer, int use_as_scheduler)
 {
 	void __iomem *iobase;
 	struct dw_apb_clocksource *cs;
@@ -71,45 +80,33 @@ static void add_clocksource(struct device_node *source_timer)
 
 	dw_apb_clocksource_start(cs);
 	dw_apb_clocksource_register(cs);
-}
 
-static void __iomem *sched_io_base;
-
-static u32 read_sched_clock(void)
-{
-	return __raw_readl(sched_io_base);
+	if (use_as_scheduler) {
+		sched_io_base = iobase;
+		setup_sched_clock(read_sched_clock_sptimer, 32, rate);
+	}
 }
 
-static const struct of_device_id sptimer_ids[] __initconst = {
-	{ .compatible = "picochip,pc3x2-rtc" },
+static const struct of_device_id osctimer_ids[] __initconst = {
+	{ .compatible = "picochip,pc3x2-timer" },
+	{ .compatible = "snps,dw-apb-timer-osc" },
 	{ .compatible = "snps,dw-apb-timer-sp" },
-	{ /* Sentinel */ },
+	{  /* Sentinel */ },
 };
 
-static void init_sched_clock(void)
-{
-	struct device_node *sched_timer;
-	u32 rate;
-
-	sched_timer = of_find_matching_node(NULL, sptimer_ids);
-	if (!sched_timer)
-		panic("No RTC for sched clock to use");
-
-	timer_get_base_and_rate(sched_timer, &sched_io_base, &rate);
-	of_node_put(sched_timer);
+/*
+   You don't have to use dw_apb_timer for scheduler clock,
+   this should also work fine on arm:
 
-	setup_sched_clock(read_sched_clock, 32, rate);
-}
+  twd_local_timer_of_register();
+  arch_timer_of_register();                 
+  arch_timer_sched_clock_init();
+*/
 
-static const struct of_device_id osctimer_ids[] __initconst = {
-	{ .compatible = "picochip,pc3x2-timer" },
-	{ .compatible = "snps,dw-apb-timer-osc" },
-	{},
-};
 
-void __init dw_apb_timer_init(void)
+void __init dw_apb_timer_init(int use_as_scheduler)
 {
 	struct device_node *event_timer, *source_timer;
 
 	event_timer = of_find_matching_node(NULL, osctimer_ids);
 	if (!event_timer)
@@ -119,9 +117,8 @@ void __init dw_apb_timer_init(void)
 	source_timer = of_find_matching_node(event_timer, osctimer_ids);
 	if (!source_timer)
 		panic("No timer for clocksource");
-	add_clocksource(source_timer);
+	add_clocksource(source_timer, use_as_scheduler);
 
+	of_node_put(event_timer);
 	of_node_put(source_timer);
-
-	init_sched_clock();
 }
diff --git a/include/linux/dw_apb_timer.h b/include/linux/dw_apb_timer.h
index dd755ce..d503245 100644
--- a/include/linux/dw_apb_timer.h
+++ b/include/linux/dw_apb_timer.h
@@ -17,6 +17,12 @@
 #include <linux/clocksource.h>
 #include <linux/interrupt.h>
 
+#define APBTMR_N_LOAD_COUNT		0x00
+#define APBTMR_N_CURRENT_VALUE		0x04
+#define APBTMR_N_CONTROL		0x08
+#define APBTMR_N_EOI			0x0c
+#define APBTMR_N_INT_STATUS		0x10
+
 #define APBTMRS_REG_SIZE       0x14
 
 struct dw_apb_timer {
@@ -53,5 +59,5 @@ void dw_apb_clocksource_start(struct dw_apb_clocksource *dw_cs);
 cycle_t dw_apb_clocksource_read(struct dw_apb_clocksource *dw_cs);
 void dw_apb_clocksource_unregister(struct dw_apb_clocksource *dw_cs);
 
-extern void dw_apb_timer_init(void);
+extern void dw_apb_timer_init(int);
 #endif /* __DW_APB_TIMER_H__ */

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


From marc.zyngier at arm.com  Fri Apr 26 08:16:12 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Fri, 26 Apr 2013 13:16:12 +0100
Subject: [RFC PATCH v3 02/17] Documentation: devicetree: arm: cpus/cpu
 nodes bindings updates
In-Reply-To: <20130426114811.GD11648@e106331-lin.cambridge.arm.com>
References: <1366824502-19729-1-git-send-email-lorenzo.pieralisi@arm.com>
 <1366824502-19729-3-git-send-email-lorenzo.pieralisi@arm.com>
 <CAL_JsqL2QOjTffogB6g7VK7oRUwDAmJpr=36uvFXjd+hpBL89A@mail.gmail.com>
 <20130426101839.GA3093@e102568-lin.cambridge.arm.com>
 <20130426114811.GD11648@e106331-lin.cambridge.arm.com>
Message-ID: <517A700C.2030102@arm.com>

On 26/04/13 12:48, Mark Rutland wrote:
> On Fri, Apr 26, 2013 at 11:18:40AM +0100, Lorenzo Pieralisi wrote:
>> On Fri, Apr 26, 2013 at 03:51:10AM +0100, Rob Herring wrote:
>>> On Wed, Apr 24, 2013 at 12:28 PM, Lorenzo Pieralisi
>>> <lorenzo.pieralisi at arm.com> wrote:
>>>> In order to extend the current cpu nodes bindings to newer CPUs
>>>> inclusive of AArch64 and to update support for older ARM CPUs this
>>>> patch updates device tree documentation for the cpu nodes bindings.
>>>>
>>>> Main changes:
>>>>     - adds 64-bit bindings
>>>>     - define usage of #address-cells
>>>>     - define 32/64 dts compatibility settings
>>>>     - defines behaviour on pre and post v7 uniprocessor systems
>>>>     - adds ARM 11MPcore specific reg property definition
>>>>
>>>> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
>>>> ---
>>>
>>> [...]
>>>
>>>> +       - enable-method
>>>> +               Value type: <stringlist>
>>>> +               Usage and definition depend on ARM architecture version and
>>>> +               configuration:
>>>> +                       # On ARM v8 64-bit systems running the OS in AArch64,
>>>> +                         this property is required and must be "spin-table".
>>>
>>> What about PSCI?
>>
>> I should add it, at least for ARM v8.
> 
> It's worth noting KVM uses it on v7 too, so it should be available for CPUs
> that are v7+.
> 
>>
>>> I don't think the ePAPR spin-table definition is sufficient for ARM.
>>> How do you define wake up by SGI or sev instruction.
>>
>> I think Will described the wfe/sev mechanism in:
>>
>> Documentation/arm64/booting.txt
>>
>> and the ePAPR does the same in 5.5.2.2/5.5.2.3. Since this is a document
>> describing cpus/cpu nodes bindings I assume that description does not
>> belong here. Question is: do we need to specify an ARM implementation
>> specific enable-method to describe SGI/sev wake-up (ePAPR 5.5.3) ?
>>
>>>> +                       # On ARM 32-bit systems or ARM v8 systems running
>>>> +                         the OS in AArch32 this property is prohibited.
>>>
>>> Why?
>>
>> Because if we define it optional with no possible set of values basically
>> it can be whatever string. I could define it optional with the same
>> allowed values as ARM v8 even if it is currently ignored, at least in Linux,
>> until PSCI implementations get merged.
> 
> I believe kvmtool sets the enable-method to "psci" on v7, though I may be
> mistaken. Adding Marc to Cc as he knows better.

Indeed, kvmtool feeds the exact same DT to an ARMv7 guest:

[...]
		cpu at 1 {
			device_type = "cpu";
			compatible = "arm,cortex-a15";
			enable-method = "psci";
			reg = <0x1>;
		};
[...]

The 32bit kernel doesn't check it, though.

	M.
-- 
Jazz is not dead. It just smells funny...



From fabio.baltieri at linaro.org  Fri Apr 26 08:17:13 2013
From: fabio.baltieri at linaro.org (Fabio Baltieri)
Date: Fri, 26 Apr 2013 14:17:13 +0200
Subject: [PATCH 0/5] various ab8500 fixes
Message-ID: <1366978638-967-1-git-send-email-fabio.baltieri@linaro.org>

Hi Samuel,

this series contains various fixes I found on the current -next ab8500
driver(s).

Patches 1 and 2 are just sparse warning, patch 3 drops reference to a
superseeded driver and last two makes ab8500-sysctrl works again without
an explicit ab8500->sysctrl defined, as it is in current kernel.

Thanks,
Fabio


Fabio Baltieri (5):
  mfd: abx500-core: fix sparse warning
  mfd: ab8500-sysctrl: fix sparse warning
  mfd: ab8500: drop references to ab8500-leds
  mfd: ab8500-sysctrl: set sysctrl_dev during probe
  mfd: ab8500-sysctrl: let sysctrl driver work without pdata

 drivers/mfd/ab8500-core.c    | 13 -------------
 drivers/mfd/ab8500-sysctrl.c |  9 +++++----
 drivers/mfd/abx500-core.c    |  2 +-
 3 files changed, 6 insertions(+), 18 deletions(-)

-- 
1.8.1.3



From fabio.baltieri at linaro.org  Fri Apr 26 08:17:14 2013
From: fabio.baltieri at linaro.org (Fabio Baltieri)
Date: Fri, 26 Apr 2013 14:17:14 +0200
Subject: [PATCH 1/5] mfd: abx500-core: fix sparse warning
In-Reply-To: <1366978638-967-1-git-send-email-fabio.baltieri@linaro.org>
References: <1366978638-967-1-git-send-email-fabio.baltieri@linaro.org>
Message-ID: <1366978638-967-2-git-send-email-fabio.baltieri@linaro.org>

Fix sparse warning:

drivers/mfd/abx500-core.c:159:38: warning: Using plain integer as NULL pointer

Signed-off-by: Fabio Baltieri <fabio.baltieri at linaro.org>
---
 drivers/mfd/abx500-core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mfd/abx500-core.c b/drivers/mfd/abx500-core.c
index 9818afb..3714acb 100644
--- a/drivers/mfd/abx500-core.c
+++ b/drivers/mfd/abx500-core.c
@@ -156,7 +156,7 @@ EXPORT_SYMBOL(abx500_startup_irq_enabled);
 void abx500_dump_all_banks(void)
 {
 	struct abx500_ops *ops;
-	struct device dummy_child = {0};
+	struct device dummy_child = {NULL};
 	struct abx500_device_entry *dev_entry;
 
 	list_for_each_entry(dev_entry, &abx500_list, list) {
-- 
1.8.1.3



From fabio.baltieri at linaro.org  Fri Apr 26 08:17:15 2013
From: fabio.baltieri at linaro.org (Fabio Baltieri)
Date: Fri, 26 Apr 2013 14:17:15 +0200
Subject: [PATCH 2/5] mfd: ab8500-sysctrl: fix sparse warning
In-Reply-To: <1366978638-967-1-git-send-email-fabio.baltieri@linaro.org>
References: <1366978638-967-1-git-send-email-fabio.baltieri@linaro.org>
Message-ID: <1366978638-967-3-git-send-email-fabio.baltieri@linaro.org>

Fix sparse warning:

drivers/mfd/ab8500-sysctrl.c:26:6: warning: symbol 'ab8500_power_off' was not declared. Should it be static?

Signed-off-by: Fabio Baltieri <fabio.baltieri at linaro.org>
---
 drivers/mfd/ab8500-sysctrl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mfd/ab8500-sysctrl.c b/drivers/mfd/ab8500-sysctrl.c
index fbca1ce..640495e 100644
--- a/drivers/mfd/ab8500-sysctrl.c
+++ b/drivers/mfd/ab8500-sysctrl.c
@@ -23,7 +23,7 @@
 
 static struct device *sysctrl_dev;
 
-void ab8500_power_off(void)
+static void ab8500_power_off(void)
 {
 	sigset_t old;
 	sigset_t all;
-- 
1.8.1.3



From fabio.baltieri at linaro.org  Fri Apr 26 08:17:16 2013
From: fabio.baltieri at linaro.org (Fabio Baltieri)
Date: Fri, 26 Apr 2013 14:17:16 +0200
Subject: [PATCH 3/5] mfd: ab8500: drop references to ab8500-leds
In-Reply-To: <1366978638-967-1-git-send-email-fabio.baltieri@linaro.org>
References: <1366978638-967-1-git-send-email-fabio.baltieri@linaro.org>
Message-ID: <1366978638-967-4-git-send-email-fabio.baltieri@linaro.org>

The ab8500-leds driver has never been upstreamed and was replaced by a
PWM framework based driver, so these references are not needed anymore.

Signed-off-by: Fabio Baltieri <fabio.baltieri at linaro.org>
---
 drivers/mfd/ab8500-core.c | 13 -------------
 1 file changed, 13 deletions(-)

diff --git a/drivers/mfd/ab8500-core.c b/drivers/mfd/ab8500-core.c
index 8e8a016..dd41ae2 100644
--- a/drivers/mfd/ab8500-core.c
+++ b/drivers/mfd/ab8500-core.c
@@ -1089,10 +1089,6 @@ static struct mfd_cell ab8500_devs[] = {
 		.id = 3,
 	},
 	{
-		.name = "ab8500-leds",
-		.of_compatible = "stericsson,ab8500-leds",
-	},
-	{
 		.name = "ab8500-denc",
 		.of_compatible = "stericsson,ab8500-denc",
 	},
@@ -1161,9 +1157,6 @@ static struct mfd_cell ab9540_devs[] = {
 		.id = 1,
 	},
 	{
-		.name = "ab8500-leds",
-	},
-	{
 		.name = "abx500-temp",
 		.num_resources = ARRAY_SIZE(ab8500_temp_resources),
 		.resources = ab8500_temp_resources,
@@ -1231,9 +1224,6 @@ static struct mfd_cell ab8505_devs[] = {
 		.id = 1,
 	},
 	{
-		.name = "ab8500-leds",
-	},
-	{
 		.name = "ab8500-gpio",
 	},
 	{
@@ -1294,9 +1284,6 @@ static struct mfd_cell ab8540_devs[] = {
 		.id = 1,
 	},
 	{
-		.name = "ab8500-leds",
-	},
-	{
 		.name = "abx500-temp",
 		.num_resources = ARRAY_SIZE(ab8500_temp_resources),
 		.resources = ab8500_temp_resources,
-- 
1.8.1.3



From fabio.baltieri at linaro.org  Fri Apr 26 08:17:17 2013
From: fabio.baltieri at linaro.org (Fabio Baltieri)
Date: Fri, 26 Apr 2013 14:17:17 +0200
Subject: [PATCH 4/5] mfd: ab8500-sysctrl: set sysctrl_dev during probe
In-Reply-To: <1366978638-967-1-git-send-email-fabio.baltieri@linaro.org>
References: <1366978638-967-1-git-send-email-fabio.baltieri@linaro.org>
Message-ID: <1366978638-967-5-git-send-email-fabio.baltieri@linaro.org>

The driver requires sysctrl_dev to be set at probe, as it's used by
other driver functions.  This was dropped by mistake in:

2377e52 mfd: ab8500-sysctrl: Error check clean up

making all driver functions fail.

Signed-off-by: Fabio Baltieri <fabio.baltieri at linaro.org>
---
 drivers/mfd/ab8500-sysctrl.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/mfd/ab8500-sysctrl.c b/drivers/mfd/ab8500-sysctrl.c
index 640495e..b851692 100644
--- a/drivers/mfd/ab8500-sysctrl.c
+++ b/drivers/mfd/ab8500-sysctrl.c
@@ -191,6 +191,8 @@ static int ab8500_sysctrl_probe(struct platform_device *pdev)
 	if (!(plat && plat->sysctrl))
 		return -EINVAL;
 
+	sysctrl_dev = &pdev->dev;
+
 	if (plat->pm_power_off)
 		pm_power_off = ab8500_power_off;
 
-- 
1.8.1.3



From fabio.baltieri at linaro.org  Fri Apr 26 08:17:18 2013
From: fabio.baltieri at linaro.org (Fabio Baltieri)
Date: Fri, 26 Apr 2013 14:17:18 +0200
Subject: [PATCH 5/5] mfd: ab8500-sysctrl: let sysctrl driver work without pdata
In-Reply-To: <1366978638-967-1-git-send-email-fabio.baltieri@linaro.org>
References: <1366978638-967-1-git-send-email-fabio.baltieri@linaro.org>
Message-ID: <1366978638-967-6-git-send-email-fabio.baltieri@linaro.org>

A check for a valid plat->sysctrl was introduced in:

2377e52 mfd: ab8500-sysctrl: Error check clean up

but the driver works just fine even without that initialization data.
This patch removes the check and let the driver go ahead with probe.

Signed-off-by: Fabio Baltieri <fabio.baltieri at linaro.org>
---
 drivers/mfd/ab8500-sysctrl.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/mfd/ab8500-sysctrl.c b/drivers/mfd/ab8500-sysctrl.c
index b851692..eadae4d 100644
--- a/drivers/mfd/ab8500-sysctrl.c
+++ b/drivers/mfd/ab8500-sysctrl.c
@@ -104,7 +104,7 @@ void ab8500_restart(char mode, const char *cmd)
 
 	plat = dev_get_platdata(sysctrl_dev->parent);
 	pdata = plat->sysctrl;
-	if (pdata->reboot_reason_code)
+	if (pdata && pdata->reboot_reason_code)
 		reason = pdata->reboot_reason_code(cmd);
 	else
 		pr_warn("[%s] No reboot reason set. Default reason %d\n",
@@ -188,7 +188,7 @@ static int ab8500_sysctrl_probe(struct platform_device *pdev)
 
 	plat = dev_get_platdata(pdev->dev.parent);
 
-	if (!(plat && plat->sysctrl))
+	if (!plat)
 		return -EINVAL;
 
 	sysctrl_dev = &pdev->dev;
@@ -197,7 +197,6 @@ static int ab8500_sysctrl_probe(struct platform_device *pdev)
 		pm_power_off = ab8500_power_off;
 
 	pdata = plat->sysctrl;
-
 	if (pdata) {
 		int last, ret, i, j;
 
-- 
1.8.1.3



From lee.jones at linaro.org  Fri Apr 26 07:38:09 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Fri, 26 Apr 2013 12:38:09 +0100
Subject: [PATCH 1/6] dmaengine: Refactor the DMA40 driver - continued
Message-ID: <1366976295-11728-1-git-send-email-lee.jones@linaro.org>

This is a continuation of the first "dmaengine: Refactor the DMA40 driver"
patch-set. It encompasses some recommendations given during the review of
it's predecessor.

 arch/arm/mach-ux500/board-mop500-audio.c    |   12 +++++-----
 arch/arm/mach-ux500/board-mop500-sdi.c      |   16 ++++++-------
 arch/arm/mach-ux500/board-mop500.c          |   22 ++++++++---------
 arch/arm/mach-ux500/usb.c                   |    4 ++--
 drivers/dma/ste_dma40.c                     |   99 +++++++++++++++++++++++++++++++++-------------------------------------------
 drivers/dma/ste_dma40_ll.c                  |  122 ++++++++++++++++++++++++++++++++++++++++++++++++++++++----------------------------------------
 include/linux/platform_data/dma-ste-dma40.h |   19 ++-------------
 sound/soc/ux500/ux500_pcm.c                 |   10 ++++----
 8 files changed, 147 insertions(+), 157 deletions(-)



From lee.jones at linaro.org  Fri Apr 26 07:38:10 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Fri, 26 Apr 2013 12:38:10 +0100
Subject: [PATCH 1/6] ARM: ux500: Replace ST-E's home-brew DMA direction
 definition with the generic one
In-Reply-To: <1366976295-11728-1-git-send-email-lee.jones@linaro.org>
References: <1366976295-11728-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1366976295-11728-2-git-send-email-lee.jones@linaro.org>

STEDMA40_*_TO_* direction definitions are identical in all but name to
the pre-defined generic DMA_*_TO_* ones. Let's make things easy by not
duplicating such things.

Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/mach-ux500/board-mop500-audio.c |   12 ++++++------
 arch/arm/mach-ux500/board-mop500-sdi.c   |   16 ++++++++--------
 arch/arm/mach-ux500/board-mop500.c       |   22 +++++++++++-----------
 arch/arm/mach-ux500/usb.c                |    4 ++--
 4 files changed, 27 insertions(+), 27 deletions(-)

diff --git a/arch/arm/mach-ux500/board-mop500-audio.c b/arch/arm/mach-ux500/board-mop500-audio.c
index 972bec0..4bd4d0f 100644
--- a/arch/arm/mach-ux500/board-mop500-audio.c
+++ b/arch/arm/mach-ux500/board-mop500-audio.c
@@ -22,13 +22,13 @@
 
 static struct stedma40_chan_cfg msp0_dma_rx = {
 	.high_priority = true,
-	.dir = STEDMA40_PERIPH_TO_MEM,
+	.dir = DMA_DEV_TO_MEM,
 	.dev_type = DB8500_DMA_DEV31_MSP0_SLIM0_CH0,
 };
 
 static struct stedma40_chan_cfg msp0_dma_tx = {
 	.high_priority = true,
-	.dir = STEDMA40_MEM_TO_PERIPH,
+	.dir = DMA_MEM_TO_DEV,
 	.dev_type = DB8500_DMA_DEV31_MSP0_SLIM0_CH0,
 };
 
@@ -40,13 +40,13 @@ struct msp_i2s_platform_data msp0_platform_data = {
 
 static struct stedma40_chan_cfg msp1_dma_rx = {
 	.high_priority = true,
-	.dir = STEDMA40_PERIPH_TO_MEM,
+	.dir = DMA_DEV_TO_MEM,
 	.dev_type = DB8500_DMA_DEV30_MSP3,
 };
 
 static struct stedma40_chan_cfg msp1_dma_tx = {
 	.high_priority = true,
-	.dir = STEDMA40_MEM_TO_PERIPH,
+	.dir = DMA_MEM_TO_DEV,
 	.dev_type = DB8500_DMA_DEV30_MSP1,
 };
 
@@ -58,13 +58,13 @@ struct msp_i2s_platform_data msp1_platform_data = {
 
 static struct stedma40_chan_cfg msp2_dma_rx = {
 	.high_priority = true,
-	.dir = STEDMA40_PERIPH_TO_MEM,
+	.dir = DMA_DEV_TO_MEM,
 	.dev_type = DB8500_DMA_DEV14_MSP2,
 };
 
 static struct stedma40_chan_cfg msp2_dma_tx = {
 	.high_priority = true,
-	.dir = STEDMA40_MEM_TO_PERIPH,
+	.dir = DMA_MEM_TO_DEV,
 	.dev_type = DB8500_DMA_DEV14_MSP2,
 	.use_fixed_channel = true,
 	.phy_channel = 1,
diff --git a/arch/arm/mach-ux500/board-mop500-sdi.c b/arch/arm/mach-ux500/board-mop500-sdi.c
index 553ace6..381acd0 100644
--- a/arch/arm/mach-ux500/board-mop500-sdi.c
+++ b/arch/arm/mach-ux500/board-mop500-sdi.c
@@ -63,13 +63,13 @@ static int mop500_sdi0_ios_handler(struct device *dev, struct mmc_ios *ios)
 #ifdef CONFIG_STE_DMA40
 struct stedma40_chan_cfg mop500_sdi0_dma_cfg_rx = {
 	.mode = STEDMA40_MODE_LOGICAL,
-	.dir = STEDMA40_PERIPH_TO_MEM,
+	.dir = DMA_DEV_TO_MEM,
 	.dev_type = DB8500_DMA_DEV29_SD_MM0,
 };
 
 static struct stedma40_chan_cfg mop500_sdi0_dma_cfg_tx = {
 	.mode = STEDMA40_MODE_LOGICAL,
-	.dir = STEDMA40_MEM_TO_PERIPH,
+	.dir = DMA_MEM_TO_DEV,
 	.dev_type = DB8500_DMA_DEV29_SD_MM0,
 };
 #endif
@@ -128,13 +128,13 @@ void mop500_sdi_tc35892_init(struct device *parent)
 #ifdef CONFIG_STE_DMA40
 static struct stedma40_chan_cfg sdi1_dma_cfg_rx = {
 	.mode = STEDMA40_MODE_LOGICAL,
-	.dir = STEDMA40_PERIPH_TO_MEM,
+	.dir = DMA_DEV_TO_MEM,
 	.dev_type = DB8500_DMA_DEV32_SD_MM1,
 };
 
 static struct stedma40_chan_cfg sdi1_dma_cfg_tx = {
 	.mode = STEDMA40_MODE_LOGICAL,
-	.dir = STEDMA40_MEM_TO_PERIPH,
+	.dir = DMA_MEM_TO_DEV,
 	.dev_type = DB8500_DMA_DEV32_SD_MM1,
 };
 #endif
@@ -159,13 +159,13 @@ struct mmci_platform_data mop500_sdi1_data = {
 #ifdef CONFIG_STE_DMA40
 struct stedma40_chan_cfg mop500_sdi2_dma_cfg_rx = {
 	.mode = STEDMA40_MODE_LOGICAL,
-	.dir = STEDMA40_PERIPH_TO_MEM,
+	.dir = DMA_DEV_TO_MEM,
 	.dev_type =  DB8500_DMA_DEV28_SD_MM2,
 };
 
 static struct stedma40_chan_cfg mop500_sdi2_dma_cfg_tx = {
 	.mode = STEDMA40_MODE_LOGICAL,
-	.dir = STEDMA40_MEM_TO_PERIPH,
+	.dir = DMA_MEM_TO_DEV,
 	.dev_type = DB8500_DMA_DEV28_SD_MM2,
 };
 #endif
@@ -191,13 +191,13 @@ struct mmci_platform_data mop500_sdi2_data = {
 #ifdef CONFIG_STE_DMA40
 struct stedma40_chan_cfg mop500_sdi4_dma_cfg_rx = {
 	.mode = STEDMA40_MODE_LOGICAL,
-	.dir = STEDMA40_PERIPH_TO_MEM,
+	.dir = DMA_DEV_TO_MEM,
 	.dev_type =  DB8500_DMA_DEV42_SD_MM4,
 };
 
 static struct stedma40_chan_cfg mop500_sdi4_dma_cfg_tx = {
 	.mode = STEDMA40_MODE_LOGICAL,
-	.dir = STEDMA40_MEM_TO_PERIPH,
+	.dir = DMA_MEM_TO_DEV,
 	.dev_type = DB8500_DMA_DEV42_SD_MM4,
 };
 #endif
diff --git a/arch/arm/mach-ux500/board-mop500.c b/arch/arm/mach-ux500/board-mop500.c
index 3866fa8..65abf8d 100644
--- a/arch/arm/mach-ux500/board-mop500.c
+++ b/arch/arm/mach-ux500/board-mop500.c
@@ -451,19 +451,19 @@ void mop500_snowball_ethernet_clock_enable(void)
 
 static struct cryp_platform_data u8500_cryp1_platform_data = {
 		.mem_to_engine = {
-				.dir = STEDMA40_MEM_TO_PERIPH,
+				.dir = DMA_MEM_TO_DEV,
 				.dev_type = DB8500_DMA_DEV48_CAC1,
 				.mode = STEDMA40_MODE_LOGICAL,
 		},
 		.engine_to_mem = {
-				.dir = STEDMA40_PERIPH_TO_MEM,
+				.dir = DMA_DEV_TO_MEM,
 				.dev_type = DB8500_DMA_DEV48_CAC1,
 				.mode = STEDMA40_MODE_LOGICAL,
 		}
 };
 
 static struct stedma40_chan_cfg u8500_hash_dma_cfg_tx = {
-		.dir = STEDMA40_MEM_TO_PERIPH,
+		.dir = DMA_MEM_TO_DEV,
 		.dev_type = DB8500_DMA_DEV50_HAC1_TX,
 		.mode = STEDMA40_MODE_LOGICAL,
 };
@@ -481,13 +481,13 @@ static struct platform_device *mop500_platform_devs[] __initdata = {
 #ifdef CONFIG_STE_DMA40
 static struct stedma40_chan_cfg ssp0_dma_cfg_rx = {
 	.mode = STEDMA40_MODE_LOGICAL,
-	.dir = STEDMA40_PERIPH_TO_MEM,
+	.dir = DMA_DEV_TO_MEM,
 	.dev_type = DB8500_DMA_DEV8_SSP0,
 };
 
 static struct stedma40_chan_cfg ssp0_dma_cfg_tx = {
 	.mode = STEDMA40_MODE_LOGICAL,
-	.dir = STEDMA40_MEM_TO_PERIPH,
+	.dir = DMA_MEM_TO_DEV,
 	.dev_type = DB8500_DMA_DEV8_SSP0,
 };
 #endif
@@ -516,37 +516,37 @@ static void __init mop500_spi_init(struct device *parent)
 #ifdef CONFIG_STE_DMA40
 static struct stedma40_chan_cfg uart0_dma_cfg_rx = {
 	.mode = STEDMA40_MODE_LOGICAL,
-	.dir = STEDMA40_PERIPH_TO_MEM,
+	.dir = DMA_DEV_TO_MEM,
 	.dev_type = DB8500_DMA_DEV13_UART0,
 };
 
 static struct stedma40_chan_cfg uart0_dma_cfg_tx = {
 	.mode = STEDMA40_MODE_LOGICAL,
-	.dir = STEDMA40_MEM_TO_PERIPH,
+	.dir = DMA_MEM_TO_DEV,
 	.dev_type = DB8500_DMA_DEV13_UART0,
 };
 
 static struct stedma40_chan_cfg uart1_dma_cfg_rx = {
 	.mode = STEDMA40_MODE_LOGICAL,
-	.dir = STEDMA40_PERIPH_TO_MEM,
+	.dir = DMA_DEV_TO_MEM,
 	.dev_type = DB8500_DMA_DEV12_UART1,
 };
 
 static struct stedma40_chan_cfg uart1_dma_cfg_tx = {
 	.mode = STEDMA40_MODE_LOGICAL,
-	.dir = STEDMA40_MEM_TO_PERIPH,
+	.dir = DMA_MEM_TO_DEV,
 	.dev_type = DB8500_DMA_DEV12_UART1,
 };
 
 static struct stedma40_chan_cfg uart2_dma_cfg_rx = {
 	.mode = STEDMA40_MODE_LOGICAL,
-	.dir = STEDMA40_PERIPH_TO_MEM,
+	.dir = DMA_DEV_TO_MEM,
 	.dev_type = DB8500_DMA_DEV11_UART2,
 };
 
 static struct stedma40_chan_cfg uart2_dma_cfg_tx = {
 	.mode = STEDMA40_MODE_LOGICAL,
-	.dir = STEDMA40_MEM_TO_PERIPH,
+	.dir = DMA_MEM_TO_DEV,
 	.dev_type = DB8500_DMA_DEV11_UART2,
 };
 #endif
diff --git a/arch/arm/mach-ux500/usb.c b/arch/arm/mach-ux500/usb.c
index e6c4a05..88e0a77 100644
--- a/arch/arm/mach-ux500/usb.c
+++ b/arch/arm/mach-ux500/usb.c
@@ -14,12 +14,12 @@
 
 #define MUSB_DMA40_RX_CH { \
 		.mode = STEDMA40_MODE_LOGICAL, \
-		.dir = STEDMA40_PERIPH_TO_MEM, \
+		.dir = DMA_DEV_TO_MEM, \
 	}
 
 #define MUSB_DMA40_TX_CH { \
 		.mode = STEDMA40_MODE_LOGICAL, \
-		.dir = STEDMA40_MEM_TO_PERIPH, \
+		.dir = DMA_MEM_TO_DEV, \
 	}
 
 static struct stedma40_chan_cfg musb_dma_rx_ch[UX500_MUSB_DMA_NUM_RX_TX_CHANNELS]
-- 
1.7.10.4



From lee.jones at linaro.org  Fri Apr 26 07:38:12 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Fri, 26 Apr 2013 12:38:12 +0100
Subject: [PATCH 3/6] ARM: ux500: Remove recently unused stedma40_xfer_dir enums
In-Reply-To: <1366976295-11728-1-git-send-email-lee.jones@linaro.org>
References: <1366976295-11728-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1366976295-11728-4-git-send-email-lee.jones@linaro.org>

We're now using the transfer direction definitions provided by the DMA
sub-system, so the home-brew ones have become obsolete.

Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 include/linux/platform_data/dma-ste-dma40.h |   10 +---------
 1 file changed, 1 insertion(+), 9 deletions(-)

diff --git a/include/linux/platform_data/dma-ste-dma40.h b/include/linux/platform_data/dma-ste-dma40.h
index 288dc24..54ddca6 100644
--- a/include/linux/platform_data/dma-ste-dma40.h
+++ b/include/linux/platform_data/dma-ste-dma40.h
@@ -77,14 +77,6 @@ enum stedma40_periph_data_width {
 	STEDMA40_DOUBLEWORD_WIDTH = STEDMA40_ESIZE_64_BIT
 };
 
-enum stedma40_xfer_dir {
-	STEDMA40_MEM_TO_MEM = 1,
-	STEDMA40_MEM_TO_PERIPH,
-	STEDMA40_PERIPH_TO_MEM,
-	STEDMA40_PERIPH_TO_PERIPH
-};
-
-
 /**
  * struct stedma40_half_channel_info - dst/src channel configuration
  *
@@ -120,7 +112,7 @@ struct stedma40_half_channel_info {
  *
  */
 struct stedma40_chan_cfg {
-	enum stedma40_xfer_dir			 dir;
+	enum dma_transfer_direction		 dir;
 	bool					 high_priority;
 	bool					 realtime;
 	enum stedma40_mode			 mode;
-- 
1.7.10.4



From lee.jones at linaro.org  Fri Apr 26 07:38:11 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Fri, 26 Apr 2013 12:38:11 +0100
Subject: [PATCH 2/6] dmaengine: ste_dma40: Replace ST-E's home-brew DMA
 direction defs with generic ones
In-Reply-To: <1366976295-11728-1-git-send-email-lee.jones@linaro.org>
References: <1366976295-11728-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1366976295-11728-3-git-send-email-lee.jones@linaro.org>

STEDMA40_*_TO_* direction definitions are identical in all but name to
the pre-defined generic DMA_*_TO_* ones. Let's make things easy by not
duplicating such things.

Cc: Vinod Koul <vinod.koul at intel.com>
Cc: Dan Williams <djbw at fb.com>
Cc: Per Forlin <per.forlin at stericsson.com>
Cc: Rabin Vincent <rabin at rab.in>
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 drivers/dma/ste_dma40.c    |   36 ++++++++++++++++++------------------
 drivers/dma/ste_dma40_ll.c |   24 ++++++++++++------------
 2 files changed, 30 insertions(+), 30 deletions(-)

diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index 78511ef..7239b90 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -58,9 +58,9 @@
 #define D40_ALLOC_PHY		BIT(30)
 #define D40_ALLOC_LOG_FREE	0
 
-#define D40_IS_SRC(dir)  (dir == STEDMA40_PERIPH_TO_MEM)
-#define D40_IS_DST(dir) ((dir == STEDMA40_MEM_TO_PERIPH) || \
-			 (dir == STEDMA40_MEM_TO_MEM))
+#define D40_IS_SRC(dir)  (dir == DMA_DEV_TO_MEM)
+#define D40_IS_DST(dir) ((dir == DMA_MEM_TO_DEV) || \
+			 (dir == DMA_MEM_TO_MEM))
 
 /* Reserved event lines for memcpy only. */
 static int dma40_memcpy_channels[] = { 56, 57, 58, 59, 60 };
@@ -68,7 +68,7 @@ static int dma40_memcpy_channels[] = { 56, 57, 58, 59, 60 };
 /* Default configuration for physcial memcpy */
 struct stedma40_chan_cfg dma40_memcpy_conf_phy = {
 	.mode = STEDMA40_MODE_PHYSICAL,
-	.dir = STEDMA40_MEM_TO_MEM,
+	.dir = DMA_MEM_TO_MEM,
 
 	.src_info.data_width = STEDMA40_BYTE_WIDTH,
 	.src_info.psize = STEDMA40_PSIZE_PHY_1,
@@ -82,7 +82,7 @@ struct stedma40_chan_cfg dma40_memcpy_conf_phy = {
 /* Default configuration for logical memcpy */
 struct stedma40_chan_cfg dma40_memcpy_conf_log = {
 	.mode = STEDMA40_MODE_LOGICAL,
-	.dir = STEDMA40_MEM_TO_MEM,
+	.dir = DMA_MEM_TO_MEM,
 
 	.src_info.data_width = STEDMA40_BYTE_WIDTH,
 	.src_info.psize = STEDMA40_PSIZE_LOG_1,
@@ -1302,7 +1302,7 @@ static void d40_config_set_event(struct d40_chan *d40c,
 
 	/* Enable event line connected to device (or memcpy) */
 	if (D40_IS_SRC(d40c->dma_cfg.dir) ||
-	    (d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_PERIPH))
+	    (d40c->dma_cfg.dir == DMA_DEV_TO_DEV))
 		__d40_config_set_event(d40c, event_type, event,
 				       D40_CHAN_REG_SSLNK);
 
@@ -1764,7 +1764,7 @@ static int d40_validate_conf(struct d40_chan *d40c,
 		res = -EINVAL;
 	}
 
-	if (conf->dir == STEDMA40_PERIPH_TO_PERIPH) {
+	if (conf->dir == DMA_DEV_TO_DEV) {
 		/*
 		 * DMAC HW supports it. Will be added to this driver,
 		 * in case any dma client requires it.
@@ -1910,7 +1910,7 @@ static int d40_allocate_channel(struct d40_chan *d40c, bool *first_phy_user)
 	event_line = D40_TYPE_TO_EVENT(dev_type);
 
 	if (!is_log) {
-		if (dir == STEDMA40_MEM_TO_MEM) {
+		if (dir == DMA_MEM_TO_MEM) {
 			/* Find physical half channel */
 			if (d40c->dma_cfg.use_fixed_channel) {
 				i = d40c->dma_cfg.phy_channel;
@@ -2365,11 +2365,11 @@ static void d40_set_prio_realtime(struct d40_chan *d40c)
 		return;
 
 	if (D40_IS_SRC(d40c->dma_cfg.dir) ||
-	    (d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_PERIPH))
+	    (d40c->dma_cfg.dir == DMA_DEV_TO_DEV))
 		__d40_set_prio_rt(d40c, d40c->dma_cfg.dev_type, true);
 
-	if ((d40c->dma_cfg.dir ==  STEDMA40_MEM_TO_PERIPH) ||
-	    (d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_PERIPH))
+	if ((d40c->dma_cfg.dir ==  DMA_MEM_TO_DEV) ||
+	    (d40c->dma_cfg.dir == DMA_DEV_TO_DEV))
 		__d40_set_prio_rt(d40c, d40c->dma_cfg.dev_type, false);
 }
 
@@ -2400,11 +2400,11 @@ static struct dma_chan *d40_xlate(struct of_phandle_args *dma_spec,
 
 	switch (D40_DT_FLAGS_DIR(flags)) {
 	case 0:
-		cfg.dir = STEDMA40_MEM_TO_PERIPH;
+		cfg.dir = DMA_MEM_TO_DEV;
 		cfg.dst_info.big_endian = D40_DT_FLAGS_BIG_ENDIAN(flags);
 		break;
 	case 1:
-		cfg.dir = STEDMA40_PERIPH_TO_MEM;
+		cfg.dir = DMA_DEV_TO_MEM;
 		cfg.src_info.big_endian = D40_DT_FLAGS_BIG_ENDIAN(flags);
 		break;
 	}
@@ -2712,12 +2712,12 @@ static int d40_set_runtime_config(struct dma_chan *chan,
 	if (config->direction == DMA_DEV_TO_MEM) {
 		config_addr = config->src_addr;
 
-		if (cfg->dir != STEDMA40_PERIPH_TO_MEM)
+		if (cfg->dir != DMA_DEV_TO_MEM)
 			dev_dbg(d40c->base->dev,
 				"channel was not configured for peripheral "
 				"to memory transfer (%d) overriding\n",
 				cfg->dir);
-		cfg->dir = STEDMA40_PERIPH_TO_MEM;
+		cfg->dir = DMA_DEV_TO_MEM;
 
 		/* Configure the memory side */
 		if (dst_addr_width == DMA_SLAVE_BUSWIDTH_UNDEFINED)
@@ -2728,12 +2728,12 @@ static int d40_set_runtime_config(struct dma_chan *chan,
 	} else if (config->direction == DMA_MEM_TO_DEV) {
 		config_addr = config->dst_addr;
 
-		if (cfg->dir != STEDMA40_MEM_TO_PERIPH)
+		if (cfg->dir != DMA_MEM_TO_DEV)
 			dev_dbg(d40c->base->dev,
 				"channel was not configured for memory "
 				"to peripheral transfer (%d) overriding\n",
 				cfg->dir);
-		cfg->dir = STEDMA40_MEM_TO_PERIPH;
+		cfg->dir = DMA_MEM_TO_DEV;
 
 		/* Configure the memory side */
 		if (src_addr_width == DMA_SLAVE_BUSWIDTH_UNDEFINED)
@@ -2784,7 +2784,7 @@ static int d40_set_runtime_config(struct dma_chan *chan,
 
 	/* Fill in register values */
 	if (chan_is_logical(d40c)) {
-		if (d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_MEM)
+		if (d40c->dma_cfg.dir == DMA_DEV_TO_MEM)
 			d40c->lcpa = d40c->base->lcpa_base +
 				d40c->dma_cfg.dev_type * D40_LCPA_CHAN_SIZE;
 		else
diff --git a/drivers/dma/ste_dma40_ll.c b/drivers/dma/ste_dma40_ll.c
index 9ab9dff..1e4b571 100644
--- a/drivers/dma/ste_dma40_ll.c
+++ b/drivers/dma/ste_dma40_ll.c
@@ -18,23 +18,23 @@ void d40_log_cfg(struct stedma40_chan_cfg *cfg,
 	u32 l1 = 0; /* src */
 
 	/* src is mem? -> increase address pos */
-	if (cfg->dir ==  STEDMA40_MEM_TO_PERIPH ||
-	    cfg->dir ==  STEDMA40_MEM_TO_MEM)
+	if (cfg->dir ==  DMA_MEM_TO_DEV ||
+	    cfg->dir ==  DMA_MEM_TO_MEM)
 		l1 |= 1 << D40_MEM_LCSP1_SCFG_INCR_POS;
 
 	/* dst is mem? -> increase address pos */
-	if (cfg->dir ==  STEDMA40_PERIPH_TO_MEM ||
-	    cfg->dir ==  STEDMA40_MEM_TO_MEM)
+	if (cfg->dir ==  DMA_DEV_TO_MEM ||
+	    cfg->dir ==  DMA_MEM_TO_MEM)
 		l3 |= 1 << D40_MEM_LCSP3_DCFG_INCR_POS;
 
 	/* src is hw? -> master port 1 */
-	if (cfg->dir ==  STEDMA40_PERIPH_TO_MEM ||
-	    cfg->dir ==  STEDMA40_PERIPH_TO_PERIPH)
+	if (cfg->dir ==  DMA_DEV_TO_MEM ||
+	    cfg->dir ==  DMA_DEV_TO_DEV)
 		l1 |= 1 << D40_MEM_LCSP1_SCFG_MST_POS;
 
 	/* dst is hw? -> master port 1 */
-	if (cfg->dir ==  STEDMA40_MEM_TO_PERIPH ||
-	    cfg->dir ==  STEDMA40_PERIPH_TO_PERIPH)
+	if (cfg->dir ==  DMA_MEM_TO_DEV ||
+	    cfg->dir ==  DMA_DEV_TO_DEV)
 		l3 |= 1 << D40_MEM_LCSP3_DCFG_MST_POS;
 
 	l3 |= 1 << D40_MEM_LCSP3_DCFG_EIM_POS;
@@ -61,8 +61,8 @@ void d40_phy_cfg(struct stedma40_chan_cfg *cfg, u32 *src_cfg, u32 *dst_cfg)
 	u32 src = 0;
 	u32 dst = 0;
 
-	if ((cfg->dir ==  STEDMA40_PERIPH_TO_MEM) ||
-	    (cfg->dir == STEDMA40_PERIPH_TO_PERIPH)) {
+	if ((cfg->dir == DMA_DEV_TO_MEM) ||
+	    (cfg->dir == DMA_DEV_TO_DEV)) {
 		/* Set master port to 1 */
 		src |= 1 << D40_SREG_CFG_MST_POS;
 		src |= D40_TYPE_TO_EVENT(cfg->dev_type);
@@ -72,8 +72,8 @@ void d40_phy_cfg(struct stedma40_chan_cfg *cfg, u32 *src_cfg, u32 *dst_cfg)
 		else
 			src |= 3 << D40_SREG_CFG_PHY_TM_POS;
 	}
-	if ((cfg->dir ==  STEDMA40_MEM_TO_PERIPH) ||
-	    (cfg->dir == STEDMA40_PERIPH_TO_PERIPH)) {
+	if ((cfg->dir == DMA_MEM_TO_DEV) ||
+	    (cfg->dir == DMA_DEV_TO_DEV)) {
 		/* Set master port to 1 */
 		dst |= 1 << D40_SREG_CFG_MST_POS;
 		dst |= D40_TYPE_TO_EVENT(cfg->dev_type);
-- 
1.7.10.4



From lee.jones at linaro.org  Fri Apr 26 07:38:13 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Fri, 26 Apr 2013 12:38:13 +0100
Subject: [PATCH 4/6] dmaengine: ste_dma40_ll: Use the BIT macro to replace
 ugly '(1 << x)'s
In-Reply-To: <1366976295-11728-1-git-send-email-lee.jones@linaro.org>
References: <1366976295-11728-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1366976295-11728-5-git-send-email-lee.jones@linaro.org>

The aim is to make the code that little more readable.

Cc: Vinod Koul <vinod.koul at intel.com>
Cc: Dan Williams <djbw at fb.com>
Cc: Per Forlin <per.forlin at stericsson.com>
Cc: Rabin Vincent <rabin at rab.in>
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 drivers/dma/ste_dma40_ll.c |   48 ++++++++++++++++++++++----------------------
 1 file changed, 24 insertions(+), 24 deletions(-)

diff --git a/drivers/dma/ste_dma40_ll.c b/drivers/dma/ste_dma40_ll.c
index 1e4b571..dd7eb66 100644
--- a/drivers/dma/ste_dma40_ll.c
+++ b/drivers/dma/ste_dma40_ll.c
@@ -20,28 +20,28 @@ void d40_log_cfg(struct stedma40_chan_cfg *cfg,
 	/* src is mem? -> increase address pos */
 	if (cfg->dir ==  DMA_MEM_TO_DEV ||
 	    cfg->dir ==  DMA_MEM_TO_MEM)
-		l1 |= 1 << D40_MEM_LCSP1_SCFG_INCR_POS;
+		l1 |= BIT(D40_MEM_LCSP1_SCFG_INCR_POS);
 
 	/* dst is mem? -> increase address pos */
 	if (cfg->dir ==  DMA_DEV_TO_MEM ||
 	    cfg->dir ==  DMA_MEM_TO_MEM)
-		l3 |= 1 << D40_MEM_LCSP3_DCFG_INCR_POS;
+		l3 |= BIT(D40_MEM_LCSP3_DCFG_INCR_POS);
 
 	/* src is hw? -> master port 1 */
 	if (cfg->dir ==  DMA_DEV_TO_MEM ||
 	    cfg->dir ==  DMA_DEV_TO_DEV)
-		l1 |= 1 << D40_MEM_LCSP1_SCFG_MST_POS;
+		l1 |= BIT(D40_MEM_LCSP1_SCFG_MST_POS);
 
 	/* dst is hw? -> master port 1 */
 	if (cfg->dir ==  DMA_MEM_TO_DEV ||
 	    cfg->dir ==  DMA_DEV_TO_DEV)
-		l3 |= 1 << D40_MEM_LCSP3_DCFG_MST_POS;
+		l3 |= BIT(D40_MEM_LCSP3_DCFG_MST_POS);
 
-	l3 |= 1 << D40_MEM_LCSP3_DCFG_EIM_POS;
+	l3 |= BIT(D40_MEM_LCSP3_DCFG_EIM_POS);
 	l3 |= cfg->dst_info.psize << D40_MEM_LCSP3_DCFG_PSIZE_POS;
 	l3 |= cfg->dst_info.data_width << D40_MEM_LCSP3_DCFG_ESIZE_POS;
 
-	l1 |= 1 << D40_MEM_LCSP1_SCFG_EIM_POS;
+	l1 |= BIT(D40_MEM_LCSP1_SCFG_EIM_POS);
 	l1 |= cfg->src_info.psize << D40_MEM_LCSP1_SCFG_PSIZE_POS;
 	l1 |= cfg->src_info.data_width << D40_MEM_LCSP1_SCFG_ESIZE_POS;
 
@@ -52,8 +52,8 @@ void d40_log_cfg(struct stedma40_chan_cfg *cfg,
 
 void d40_log_gim_unmask(u32 *src_cfg, u32 *dst_cfg) {
 
-	*src_cfg |= 1 << D40_SREG_CFG_LOG_GIM_POS;
-	*dst_cfg |= 1 << D40_SREG_CFG_LOG_GIM_POS;
+	*src_cfg |= BIT(D40_SREG_CFG_LOG_GIM_POS);
+	*dst_cfg |= BIT(D40_SREG_CFG_LOG_GIM_POS);
 }
 
 void d40_phy_cfg(struct stedma40_chan_cfg *cfg, u32 *src_cfg, u32 *dst_cfg)
@@ -64,39 +64,39 @@ void d40_phy_cfg(struct stedma40_chan_cfg *cfg, u32 *src_cfg, u32 *dst_cfg)
 	if ((cfg->dir == DMA_DEV_TO_MEM) ||
 	    (cfg->dir == DMA_DEV_TO_DEV)) {
 		/* Set master port to 1 */
-		src |= 1 << D40_SREG_CFG_MST_POS;
+		src |= BIT(D40_SREG_CFG_MST_POS);
 		src |= D40_TYPE_TO_EVENT(cfg->dev_type);
 
 		if (cfg->src_info.flow_ctrl == STEDMA40_NO_FLOW_CTRL)
-			src |= 1 << D40_SREG_CFG_PHY_TM_POS;
+			src |= BIT(D40_SREG_CFG_PHY_TM_POS);
 		else
 			src |= 3 << D40_SREG_CFG_PHY_TM_POS;
 	}
 	if ((cfg->dir == DMA_MEM_TO_DEV) ||
 	    (cfg->dir == DMA_DEV_TO_DEV)) {
 		/* Set master port to 1 */
-		dst |= 1 << D40_SREG_CFG_MST_POS;
+		dst |= BIT(D40_SREG_CFG_MST_POS);
 		dst |= D40_TYPE_TO_EVENT(cfg->dev_type);
 
 		if (cfg->dst_info.flow_ctrl == STEDMA40_NO_FLOW_CTRL)
-			dst |= 1 << D40_SREG_CFG_PHY_TM_POS;
+			dst |= BIT(D40_SREG_CFG_PHY_TM_POS);
 		else
 			dst |= 3 << D40_SREG_CFG_PHY_TM_POS;
 	}
 	/* Interrupt on end of transfer for destination */
-	dst |= 1 << D40_SREG_CFG_TIM_POS;
+	dst |= BIT(D40_SREG_CFG_TIM_POS);
 
 	/* Generate interrupt on error */
-	src |= 1 << D40_SREG_CFG_EIM_POS;
-	dst |= 1 << D40_SREG_CFG_EIM_POS;
+	src |= BIT(D40_SREG_CFG_EIM_POS);
+	dst |= BIT(D40_SREG_CFG_EIM_POS);
 
 	/* PSIZE */
 	if (cfg->src_info.psize != STEDMA40_PSIZE_PHY_1) {
-		src |= 1 << D40_SREG_CFG_PHY_PEN_POS;
+		src |= BIT(D40_SREG_CFG_PHY_PEN_POS);
 		src |= cfg->src_info.psize << D40_SREG_CFG_PSIZE_POS;
 	}
 	if (cfg->dst_info.psize != STEDMA40_PSIZE_PHY_1) {
-		dst |= 1 << D40_SREG_CFG_PHY_PEN_POS;
+		dst |= BIT(D40_SREG_CFG_PHY_PEN_POS);
 		dst |= cfg->dst_info.psize << D40_SREG_CFG_PSIZE_POS;
 	}
 
@@ -106,14 +106,14 @@ void d40_phy_cfg(struct stedma40_chan_cfg *cfg, u32 *src_cfg, u32 *dst_cfg)
 
 	/* Set the priority bit to high for the physical channel */
 	if (cfg->high_priority) {
-		src |= 1 << D40_SREG_CFG_PRI_POS;
-		dst |= 1 << D40_SREG_CFG_PRI_POS;
+		src |= BIT(D40_SREG_CFG_PRI_POS);
+		dst |= BIT(D40_SREG_CFG_PRI_POS);
 	}
 
 	if (cfg->src_info.big_endian)
-		src |= 1 << D40_SREG_CFG_LBE_POS;
+		src |= BIT(D40_SREG_CFG_LBE_POS);
 	if (cfg->dst_info.big_endian)
-		dst |= 1 << D40_SREG_CFG_LBE_POS;
+		dst |= BIT(D40_SREG_CFG_LBE_POS);
 
 	*src_cfg = src;
 	*dst_cfg = dst;
@@ -163,15 +163,15 @@ static int d40_phy_fill_lli(struct d40_phy_lli *lli,
 
 	/* If this scatter list entry is the last one, no next link */
 	if (next_lli == 0)
-		lli->reg_lnk = 0x1 << D40_SREG_LNK_PHY_TCP_POS;
+		lli->reg_lnk = BIT(D40_SREG_LNK_PHY_TCP_POS);
 	else
 		lli->reg_lnk = next_lli;
 
 	/* Set/clear interrupt generation on this link item.*/
 	if (term_int)
-		lli->reg_cfg |= 0x1 << D40_SREG_CFG_TIM_POS;
+		lli->reg_cfg |= BIT(D40_SREG_CFG_TIM_POS);
 	else
-		lli->reg_cfg &= ~(0x1 << D40_SREG_CFG_TIM_POS);
+		lli->reg_cfg &= ~BIT(D40_SREG_CFG_TIM_POS);
 
 	/* Post link */
 	lli->reg_lnk |= 0 << D40_SREG_LNK_PHY_PRE_POS;
-- 
1.7.10.4



From lee.jones at linaro.org  Fri Apr 26 07:38:15 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Fri, 26 Apr 2013 12:38:15 +0100
Subject: [PATCH 6/6] dmaengine: ste_dma40_ll: Replace meaningless register set
 with comment
In-Reply-To: <1366976295-11728-1-git-send-email-lee.jones@linaro.org>
References: <1366976295-11728-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1366976295-11728-7-git-send-email-lee.jones@linaro.org>

Unsure of the author's intentions, rather than just removing the nop,
we're replacing it with a comment containing the possible intention
of the statement OR:ing with 0.

Cc: Vinod Koul <vinod.koul at intel.com>
Cc: Dan Williams <djbw at fb.com>
Cc: Per Forlin <per.forlin at stericsson.com>
Cc: Rabin Vincent <rabin at rab.in>
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 drivers/dma/ste_dma40_ll.c |    6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/dma/ste_dma40_ll.c b/drivers/dma/ste_dma40_ll.c
index ec03000..f2e15ac 100644
--- a/drivers/dma/ste_dma40_ll.c
+++ b/drivers/dma/ste_dma40_ll.c
@@ -189,8 +189,10 @@ static int d40_phy_fill_lli(struct d40_phy_lli *lli,
 	else
 		lli->reg_cfg &= ~BIT(D40_SREG_CFG_TIM_POS);
 
-	/* Post link */
-	lli->reg_lnk |= 0 << D40_SREG_LNK_PHY_PRE_POS;
+	/*
+	 * Post link - D40_SREG_LNK_PHY_PRE_POS = 0
+	 * Relink happens after transfer completion.
+	 */
 
 	return 0;
 }
-- 
1.7.10.4



From lee.jones at linaro.org  Fri Apr 26 07:38:14 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Fri, 26 Apr 2013 12:38:14 +0100
Subject: [PATCH 5/6] dmaengine: ste_dma40: Convert data_width from register
 bit format to value
In-Reply-To: <1366976295-11728-1-git-send-email-lee.jones@linaro.org>
References: <1366976295-11728-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1366976295-11728-6-git-send-email-lee.jones@linaro.org>

When a DMA client requests and configures a DMA channel, it requests
data_width in Bytes. The DMA40 driver then swiftly converts it over to
the necessary register bit value. Unfortunately, for any subsequent
calculations we have to shift '1' by the bit pattern (1 << data_width)
times to make any sense of it.

This patch flips the semantics on its head and only converts the value
to its respective register bit pattern when writing to registers. This
way we can use the true data_width (in Bytes) value.

Cc: Vinod Koul <vinod.koul at intel.com>
Cc: Dan Williams <djbw at fb.com>
Cc: Per Forlin <per.forlin at stericsson.com>
Cc: Rabin Vincent <rabin at rab.in>
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 drivers/dma/ste_dma40.c                     |   63 +++++++++++----------------
 drivers/dma/ste_dma40_ll.c                  |   44 +++++++++++++------
 include/linux/platform_data/dma-ste-dma40.h |    9 +---
 sound/soc/ux500/ux500_pcm.c                 |   10 ++---
 4 files changed, 61 insertions(+), 65 deletions(-)

diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index 7239b90..efcd32d 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -70,11 +70,11 @@ struct stedma40_chan_cfg dma40_memcpy_conf_phy = {
 	.mode = STEDMA40_MODE_PHYSICAL,
 	.dir = DMA_MEM_TO_MEM,
 
-	.src_info.data_width = STEDMA40_BYTE_WIDTH,
+	.src_info.data_width = DMA_SLAVE_BUSWIDTH_1_BYTE,
 	.src_info.psize = STEDMA40_PSIZE_PHY_1,
 	.src_info.flow_ctrl = STEDMA40_NO_FLOW_CTRL,
 
-	.dst_info.data_width = STEDMA40_BYTE_WIDTH,
+	.dst_info.data_width = DMA_SLAVE_BUSWIDTH_1_BYTE,
 	.dst_info.psize = STEDMA40_PSIZE_PHY_1,
 	.dst_info.flow_ctrl = STEDMA40_NO_FLOW_CTRL,
 };
@@ -84,11 +84,11 @@ struct stedma40_chan_cfg dma40_memcpy_conf_log = {
 	.mode = STEDMA40_MODE_LOGICAL,
 	.dir = DMA_MEM_TO_MEM,
 
-	.src_info.data_width = STEDMA40_BYTE_WIDTH,
+	.src_info.data_width = DMA_SLAVE_BUSWIDTH_1_BYTE,
 	.src_info.psize = STEDMA40_PSIZE_LOG_1,
 	.src_info.flow_ctrl = STEDMA40_NO_FLOW_CTRL,
 
-	.dst_info.data_width = STEDMA40_BYTE_WIDTH,
+	.dst_info.data_width = DMA_SLAVE_BUSWIDTH_1_BYTE,
 	.dst_info.psize = STEDMA40_PSIZE_LOG_1,
 	.dst_info.flow_ctrl = STEDMA40_NO_FLOW_CTRL,
 };
@@ -995,20 +995,21 @@ static int d40_psize_2_burst_size(bool is_log, int psize)
 
 /*
  * The dma only supports transmitting packages up to
- * STEDMA40_MAX_SEG_SIZE << data_width. Calculate the total number of
- * dma elements required to send the entire sg list
+ * STEDMA40_MAX_SEG_SIZE * data_width, where data_width is stored in Bytes.
+ *
+ * Calculate the total number of dma elements required to send the entire sg list.
  */
 static int d40_size_2_dmalen(int size, u32 data_width1, u32 data_width2)
 {
 	int dmalen;
 	u32 max_w = max(data_width1, data_width2);
 	u32 min_w = min(data_width1, data_width2);
-	u32 seg_max = ALIGN(STEDMA40_MAX_SEG_SIZE << min_w, 1 << max_w);
+	u32 seg_max = ALIGN(STEDMA40_MAX_SEG_SIZE * min_w, max_w);
 
 	if (seg_max > STEDMA40_MAX_SEG_SIZE)
-		seg_max -= (1 << max_w);
+		seg_max -= max_w;
 
-	if (!IS_ALIGNED(size, 1 << max_w))
+	if (!IS_ALIGNED(size, max_w))
 		return -EINVAL;
 
 	if (size <= seg_max)
@@ -1454,7 +1455,7 @@ static u32 d40_residue(struct d40_chan *d40c)
 			  >> D40_SREG_ELEM_PHY_ECNT_POS;
 	}
 
-	return num_elt * (1 << d40c->dma_cfg.dst_info.data_width);
+	return num_elt * d40c->dma_cfg.dst_info.data_width;
 }
 
 static bool d40_tx_is_linked(struct d40_chan *d40c)
@@ -1774,9 +1775,9 @@ static int d40_validate_conf(struct d40_chan *d40c,
 	}
 
 	if (d40_psize_2_burst_size(is_log, conf->src_info.psize) *
-	    (1 << conf->src_info.data_width) !=
+	    conf->src_info.data_width !=
 	    d40_psize_2_burst_size(is_log, conf->dst_info.psize) *
-	    (1 << conf->dst_info.data_width)) {
+	    conf->dst_info.data_width) {
 		/*
 		 * The DMAC hardware only supports
 		 * src (burst x width) == dst (burst x width)
@@ -2639,33 +2640,10 @@ static void d40_terminate_all(struct dma_chan *chan)
 static int
 dma40_config_to_halfchannel(struct d40_chan *d40c,
 			    struct stedma40_half_channel_info *info,
-			    enum dma_slave_buswidth width,
 			    u32 maxburst)
 {
-	enum stedma40_periph_data_width addr_width;
 	int psize;
 
-	switch (width) {
-	case DMA_SLAVE_BUSWIDTH_1_BYTE:
-		addr_width = STEDMA40_BYTE_WIDTH;
-		break;
-	case DMA_SLAVE_BUSWIDTH_2_BYTES:
-		addr_width = STEDMA40_HALFWORD_WIDTH;
-		break;
-	case DMA_SLAVE_BUSWIDTH_4_BYTES:
-		addr_width = STEDMA40_WORD_WIDTH;
-		break;
-	case DMA_SLAVE_BUSWIDTH_8_BYTES:
-		addr_width = STEDMA40_DOUBLEWORD_WIDTH;
-		break;
-	default:
-		dev_err(d40c->base->dev,
-			"illegal peripheral address width "
-			"requested (%d)\n",
-			width);
-		return -EINVAL;
-	}
-
 	if (chan_is_logical(d40c)) {
 		if (maxburst >= 16)
 			psize = STEDMA40_PSIZE_LOG_16;
@@ -2686,7 +2664,6 @@ dma40_config_to_halfchannel(struct d40_chan *d40c,
 			psize = STEDMA40_PSIZE_PHY_1;
 	}
 
-	info->data_width = addr_width;
 	info->psize = psize;
 	info->flow_ctrl = STEDMA40_NO_FLOW_CTRL;
 
@@ -2770,14 +2747,24 @@ static int d40_set_runtime_config(struct dma_chan *chan,
 		src_maxburst = dst_maxburst * dst_addr_width / src_addr_width;
 	}
 
+	/* Only valid widths are; 1, 2, 4 and 8. */
+	if (src_addr_width <= DMA_SLAVE_BUSWIDTH_UNDEFINED ||
+	    src_addr_width >  DMA_SLAVE_BUSWIDTH_8_BYTES   ||
+	    dst_addr_width <= DMA_SLAVE_BUSWIDTH_UNDEFINED ||
+	    dst_addr_width >  DMA_SLAVE_BUSWIDTH_8_BYTES   ||
+	    ((src_addr_width > 1) && (src_addr_width & 1)) ||
+	    ((dst_addr_width > 1) && (dst_addr_width & 1)))
+		return -EINVAL;
+
+	cfg->src_info.data_width = src_addr_width;
+	cfg->dst_info.data_width = dst_addr_width;
+
 	ret = dma40_config_to_halfchannel(d40c, &cfg->src_info,
-					  src_addr_width,
 					  src_maxburst);
 	if (ret)
 		return ret;
 
 	ret = dma40_config_to_halfchannel(d40c, &cfg->dst_info,
-					  dst_addr_width,
 					  dst_maxburst);
 	if (ret)
 		return ret;
diff --git a/drivers/dma/ste_dma40_ll.c b/drivers/dma/ste_dma40_ll.c
index dd7eb66..ec03000 100644
--- a/drivers/dma/ste_dma40_ll.c
+++ b/drivers/dma/ste_dma40_ll.c
@@ -10,6 +10,18 @@
 
 #include "ste_dma40_ll.h"
 
+u8 d40_width_to_bits(enum dma_slave_buswidth width)
+{
+	if (width == DMA_SLAVE_BUSWIDTH_1_BYTE)
+		return STEDMA40_ESIZE_8_BIT;
+	else if (width == DMA_SLAVE_BUSWIDTH_2_BYTES)
+		return STEDMA40_ESIZE_16_BIT;
+	else if (width == DMA_SLAVE_BUSWIDTH_8_BYTES)
+		return STEDMA40_ESIZE_64_BIT;
+	else
+		return STEDMA40_ESIZE_32_BIT;
+}
+
 /* Sets up proper LCSP1 and LCSP3 register for a logical channel */
 void d40_log_cfg(struct stedma40_chan_cfg *cfg,
 		 u32 *lcsp1, u32 *lcsp3)
@@ -39,11 +51,13 @@ void d40_log_cfg(struct stedma40_chan_cfg *cfg,
 
 	l3 |= BIT(D40_MEM_LCSP3_DCFG_EIM_POS);
 	l3 |= cfg->dst_info.psize << D40_MEM_LCSP3_DCFG_PSIZE_POS;
-	l3 |= cfg->dst_info.data_width << D40_MEM_LCSP3_DCFG_ESIZE_POS;
+	l3 |= d40_width_to_bits(cfg->dst_info.data_width)
+		<< D40_MEM_LCSP3_DCFG_ESIZE_POS;
 
 	l1 |= BIT(D40_MEM_LCSP1_SCFG_EIM_POS);
 	l1 |= cfg->src_info.psize << D40_MEM_LCSP1_SCFG_PSIZE_POS;
-	l1 |= cfg->src_info.data_width << D40_MEM_LCSP1_SCFG_ESIZE_POS;
+	l1 |= d40_width_to_bits(cfg->src_info.data_width)
+		<< D40_MEM_LCSP1_SCFG_ESIZE_POS;
 
 	*lcsp1 = l1;
 	*lcsp3 = l3;
@@ -101,8 +115,10 @@ void d40_phy_cfg(struct stedma40_chan_cfg *cfg, u32 *src_cfg, u32 *dst_cfg)
 	}
 
 	/* Element size */
-	src |= cfg->src_info.data_width << D40_SREG_CFG_ESIZE_POS;
-	dst |= cfg->dst_info.data_width << D40_SREG_CFG_ESIZE_POS;
+	src |= d40_width_to_bits(cfg->src_info.data_width)
+		<< D40_SREG_CFG_ESIZE_POS;
+	dst |= d40_width_to_bits(cfg->dst_info.data_width)
+		<< D40_SREG_CFG_ESIZE_POS;
 
 	/* Set the priority bit to high for the physical channel */
 	if (cfg->high_priority) {
@@ -139,23 +155,23 @@ static int d40_phy_fill_lli(struct d40_phy_lli *lli,
 		num_elems = 2 << psize;
 
 	/* Must be aligned */
-	if (!IS_ALIGNED(data, 0x1 << data_width))
+	if (!IS_ALIGNED(data, data_width))
 		return -EINVAL;
 
 	/* Transfer size can't be smaller than (num_elms * elem_size) */
-	if (data_size < num_elems * (0x1 << data_width))
+	if (data_size < num_elems * data_width)
 		return -EINVAL;
 
 	/* The number of elements. IE now many chunks */
-	lli->reg_elt = (data_size >> data_width) << D40_SREG_ELEM_PHY_ECNT_POS;
+	lli->reg_elt = (data_size / data_width) << D40_SREG_ELEM_PHY_ECNT_POS;
 
 	/*
 	 * Distance to next element sized entry.
 	 * Usually the size of the element unless you want gaps.
 	 */
 	if (addr_inc)
-		lli->reg_elt |= (0x1 << data_width) <<
-			D40_SREG_ELEM_PHY_EIDX_POS;
+		lli->reg_elt |= d40_width_to_bits(data_width)
+			<< D40_SREG_ELEM_PHY_EIDX_POS;
 
 	/* Where the data is */
 	lli->reg_ptr = data;
@@ -183,16 +199,16 @@ static int d40_seg_size(int size, int data_width1, int data_width2)
 {
 	u32 max_w = max(data_width1, data_width2);
 	u32 min_w = min(data_width1, data_width2);
-	u32 seg_max = ALIGN(STEDMA40_MAX_SEG_SIZE << min_w, 1 << max_w);
+	u32 seg_max = ALIGN(STEDMA40_MAX_SEG_SIZE * min_w, max_w);
 
 	if (seg_max > STEDMA40_MAX_SEG_SIZE)
-		seg_max -= (1 << max_w);
+		seg_max -= max_w;
 
 	if (size <= seg_max)
 		return size;
 
 	if (size <= 2 * seg_max)
-		return ALIGN(size / 2, 1 << max_w);
+		return ALIGN(size / 2, max_w);
 
 	return seg_max;
 }
@@ -358,10 +374,10 @@ static void d40_log_fill_lli(struct d40_log_lli *lli,
 	lli->lcsp13 = reg_cfg;
 
 	/* The number of elements to transfer */
-	lli->lcsp02 = ((data_size >> data_width) <<
+	lli->lcsp02 = ((data_size / data_width) <<
 		       D40_MEM_LCSP0_ECNT_POS) & D40_MEM_LCSP0_ECNT_MASK;
 
-	BUG_ON((data_size >> data_width) > STEDMA40_MAX_SEG_SIZE);
+	BUG_ON((data_size / data_width) > STEDMA40_MAX_SEG_SIZE);
 
 	/* 16 LSBs address of the current element */
 	lli->lcsp02 |= data & D40_MEM_LCSP0_SPTR_MASK;
diff --git a/include/linux/platform_data/dma-ste-dma40.h b/include/linux/platform_data/dma-ste-dma40.h
index 54ddca6..ceba6dc 100644
--- a/include/linux/platform_data/dma-ste-dma40.h
+++ b/include/linux/platform_data/dma-ste-dma40.h
@@ -70,13 +70,6 @@ enum stedma40_flow_ctrl {
 	STEDMA40_FLOW_CTRL,
 };
 
-enum stedma40_periph_data_width {
-	STEDMA40_BYTE_WIDTH = STEDMA40_ESIZE_8_BIT,
-	STEDMA40_HALFWORD_WIDTH = STEDMA40_ESIZE_16_BIT,
-	STEDMA40_WORD_WIDTH = STEDMA40_ESIZE_32_BIT,
-	STEDMA40_DOUBLEWORD_WIDTH = STEDMA40_ESIZE_64_BIT
-};
-
 /**
  * struct stedma40_half_channel_info - dst/src channel configuration
  *
@@ -87,7 +80,7 @@ enum stedma40_periph_data_width {
  */
 struct stedma40_half_channel_info {
 	bool big_endian;
-	enum stedma40_periph_data_width data_width;
+	enum dma_slave_buswidth data_width;
 	int psize;
 	enum stedma40_flow_ctrl flow_ctrl;
 };
diff --git a/sound/soc/ux500/ux500_pcm.c b/sound/soc/ux500/ux500_pcm.c
index 846fa82..b897733 100644
--- a/sound/soc/ux500/ux500_pcm.c
+++ b/sound/soc/ux500/ux500_pcm.c
@@ -125,21 +125,21 @@ static int ux500_pcm_open(struct snd_pcm_substream *substream)
 	runtime->hw = (stream_id == SNDRV_PCM_STREAM_PLAYBACK) ?
 		ux500_pcm_hw_playback : ux500_pcm_hw_capture;
 
-	mem_data_width = STEDMA40_HALFWORD_WIDTH;
+	mem_data_width = DMA_SLAVE_BUSWIDTH_2_BYTES;
 
 	dma_params = snd_soc_dai_get_dma_data(dai, substream);
 	switch (dma_params->data_size) {
 	case 32:
-		per_data_width = STEDMA40_WORD_WIDTH;
+		per_data_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
 		break;
 	case 16:
-		per_data_width = STEDMA40_HALFWORD_WIDTH;
+		per_data_width = DMA_SLAVE_BUSWIDTH_2_BYTES;
 		break;
 	case 8:
-		per_data_width = STEDMA40_BYTE_WIDTH;
+		per_data_width = DMA_SLAVE_BUSWIDTH_1_BYTE;
 		break;
 	default:
-		per_data_width = STEDMA40_WORD_WIDTH;
+		per_data_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
 		dev_warn(rtd->platform->dev,
 			"%s: Unknown data-size (%d)! Assuming 32 bits.\n",
 			__func__, dma_params->data_size);
-- 
1.7.10.4



From peterz at infradead.org  Fri Apr 26 08:30:02 2013
From: peterz at infradead.org (Peter Zijlstra)
Date: Fri, 26 Apr 2013 14:30:02 +0200
Subject: [PATCH 03/14] sched: pack small tasks
In-Reply-To: <1366910611-20048-4-git-send-email-vincent.guittot@linaro.org>
References: <1366910611-20048-1-git-send-email-vincent.guittot@linaro.org>
 <1366910611-20048-4-git-send-email-vincent.guittot@linaro.org>
Message-ID: <20130426123002.GA13464@dyad.programming.kicks-ass.net>

On Thu, Apr 25, 2013 at 07:23:19PM +0200, Vincent Guittot wrote:
> During the creation of sched_domain, we define a pack buddy CPU for each CPU
> when one is available. We want to pack at all levels where a group of CPUs can
> be power gated independently from others.
> On a system that can't power gate a group of CPUs independently, the flag is
> set at all sched_domain level and the buddy is set to -1. This is the default
> behavior.
> 
> On a dual clusters / dual cores system which can power gate each core and
> cluster independently, the buddy configuration will be :
> 
>       | Cluster 0   | Cluster 1   |
>       | CPU0 | CPU1 | CPU2 | CPU3 |
> -----------------------------------
> buddy | CPU0 | CPU0 | CPU0 | CPU2 |
> 
> If the cores in a cluster can't be power gated independently, the buddy
> configuration becomes:
> 
>       | Cluster 0   | Cluster 1   |
>       | CPU0 | CPU1 | CPU2 | CPU3 |
> -----------------------------------
> buddy | CPU0 | CPU1 | CPU0 | CPU0 |
> 
> Small tasks tend to slip out of the periodic load balance so the best place
> to choose to migrate them is during their wake up. The decision is in O(1) as
> we only check again one buddy CPU


So I really don't get the point of this buddy stuff, even for light load non
performance impact stuff you want to do.

The moment you judge cpu0 busy you'll bail, even though its perfectly doable
(and desirable afaict) to continue stacking light tasks on cpu1 instead of
waking up cpu2/3.

So what's wrong with keeping a single light-wake target cpu selection and
updating it appropriately?

Also where/how does the nohz balance cpu criteria not match the light-wake
target criteria?


From arnd at arndb.de  Fri Apr 26 08:33:59 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 26 Apr 2013 14:33:59 +0200
Subject: [PATCH 0/2] Early printk support for virtio console devices.
In-Reply-To: <CALrVBkuOmu4u9egdzzfn1tU9B-CFe3w85HZQ9s2gpKvYnaSqvA@mail.gmail.com>
References: <1366974299-17877-1-git-send-email-pranavkumar@linaro.org>
 <CAFEAcA_xmrHTvR7FxUr3PCKBJY-hZnkeBcqyHksTB4-hqOZS0w@mail.gmail.com>
 <CALrVBkuOmu4u9egdzzfn1tU9B-CFe3w85HZQ9s2gpKvYnaSqvA@mail.gmail.com>
Message-ID: <1577576.O1Cm2pf5KD@wuerfel>

On Friday 26 April 2013 17:36:16 Anup Patel wrote:
> On 26 April 2013 17:03, Peter Maydell <peter.maydell at linaro.org> wrote:
> > On 26 April 2013 12:19, Alexander Graf <agraf at suse.de> wrote:
> >> MMIO registers are handled by a different layer than the virtio
> >> console itself. After the virtio refactoring in QEMU, they will
> >> be completely separate drivers.
> >
> > Good point -- we don't really want to be mixing up the
> > transport and the backend. You can see it in the kvmtool
> > patch, in fact -- it introduces an "if this is virtio-console"
> > special case into the mmio.c file which previously was
> > entirely backend agnostic.
> 
> Well, we can always have virtio device specific config registers
> handle by virtio device backends and generic virtio config register
> handled by transport.
> 
> kvmtool patch is hacky because it does not provide virtio device
> specific config read/write callbacks.

Couldn't kvmtool implement the interface used by smh_printch()
for early output instead?

Or if that's not a fitting inteface, maybe a psci call for writing
a character to the console?

	Arnd


From mikedunn at newsguy.com  Fri Apr 26 08:38:57 2013
From: mikedunn at newsguy.com (Mike Dunn)
Date: Fri, 26 Apr 2013 05:38:57 -0700
Subject: gpio-pxa initcall level change and machine init breakage
In-Reply-To: <87ppxiz9l5.fsf@free.fr>
References: <5172B398.7060706@newsguy.com>
 <CAD6h2NSRA9w7GZLQGgK-+TvEAsxwOHow5_26JyVUA6YQyj3OQg@mail.gmail.com>
 <517466F6.3000003@newsguy.com>
 <CAD6h2NSy0=3P-PHdCiJJQG_jvGaFnr7uex+Uxs=0F-VsUxtPWg@mail.gmail.com>
 <CACRpkdbk24kR75fanvXVAocnuozNq_=jWDSPHPCWhbZCOrN5_Q@mail.gmail.com>
 <5176E438.80800@newsguy.com>
 <CACRpkdYLCKKZZFi6Y-viPUvrwupJGzfxr3f20a1emp-9qE0YBg@mail.gmail.com>
 <87ppxiz9l5.fsf@free.fr>
Message-ID: <517A7561.1080606@newsguy.com>

On 04/25/2013 12:36 PM, Robert Jarzmik wrote:
> Linus Walleij <linus.walleij at linaro.org> writes:
> 
>> On Tue, Apr 23, 2013 at 9:42 PM, Mike Dunn <mikedunn at newsguy.com> wrote:
>>
>>> On a more general note... I'm surprised that gpiolib can not run earlier, for
>>> something so low-level.
>>
>> Well I think the patch we're discussing is making it run less early, and it
>> can actually run as arch_initcall() or similar if you wish (it's up to the
>> driver).
>>
>> However that is beside the point, Haojian is still doing the right thing
>> trying to push this to driver init (==module_init) level. The reason is
>> that basically all hardware drivers should be initialized at this level
>> because the other init levels are basically for other things and driver
>> deps are just shoehorned into them.
>>
>> Instead of relying on things to be set up early one shall rely on
>> deferred probe.
> Hi Linus,
> 
> Even if that is the long term goal, and I agree with that goal, let me quote
> Documentation/gpio.txt : "However, for spinlock-safe GPIOs it's OK to use them
> before tasking is enabled, as part of early board setup.".
> 
> When gpio abstraction was written, it was assumed GPIO usage was usable in early
> platform setup code. As this was granted, we (board maintainers) coded
> accordingly.
> 
> Now this patch breaks boards. I disagree in having my board code broken without
> notice. What I would find less intrusive would be to :
>  (a) revert the patch
>  (b) inform board maintainers that they must fix their board code (for example
>  give them 1 window)
>  (c) put back the patch. Board maintainers who did not amend their board
>  code cannot say anymore they didn't know it. Board maintainers will also have
>  time to rise objections if they think they cannot change their board code
>  (which I do not believe is possible, but who knows ...)


Yes, thank you Robert.  More than a few boards were broken.  Old architectures
get no respect ;)

Some drivers may need rework, not just board support code.  For the pxa27x lcd
driver (pxafb), I am thinking that the board will have to pass a callback
function to the driver by way of platform_data, which the driver will call from
its probe function.  Advice gratefully received!


> Ah and change the Documentation too I think, if you want GPIO to be only usable
> from device initcall level.


As Linus mentioned, it depends on the driver.  There is no standard initcall
level for them.  Do 'grep initcall drivers/gpio/*.c' and you'll see the variety.
 This is a problem with the gpio abstraction that should be addressed, at least
in the documentation.  I wouldn't mind helping, but I'm pretty clueless at this
point.

Thanks,
Mike


From peterz at infradead.org  Fri Apr 26 08:38:27 2013
From: peterz at infradead.org (Peter Zijlstra)
Date: Fri, 26 Apr 2013 14:38:27 +0200
Subject: [PATCH 03/14] sched: pack small tasks
In-Reply-To: <1366910611-20048-4-git-send-email-vincent.guittot@linaro.org>
References: <1366910611-20048-1-git-send-email-vincent.guittot@linaro.org>
 <1366910611-20048-4-git-send-email-vincent.guittot@linaro.org>
Message-ID: <20130426123827.GB13464@dyad.programming.kicks-ass.net>

On Thu, Apr 25, 2013 at 07:23:19PM +0200, Vincent Guittot wrote:

> +static bool is_buddy_busy(int cpu)
> +{
> +	struct rq *rq = cpu_rq(cpu);
> +	u32 sum = rq->avg.runnable_avg_sum;
> +	u32 period = rq->avg.runnable_avg_period;
> +
> +	/*
> +	 * If a CPU accesses the runnable_avg_sum and runnable_avg_period
> +	 * fields of its buddy CPU while the latter updates it, it can get the
> +	 * new version of a field and the old version of the other one. This
> +	 * can generate erroneous decisions. We don't want to use a lock
> +	 * mechanism for ensuring the coherency because of the overhead in
> +	 * this critical path.
> +	 * The runnable_avg_period of a runqueue tends to the max value in
> +	 * less than 345ms after plugging a CPU, which implies that we could
> +	 * use the max value instead of reading runnable_avg_period after
> +	 * 345ms. During the starting phase, we must ensure a minimum of
> +	 * coherency between the fields. A simple rule is runnable_avg_sum <=
> +	 * runnable_avg_period.
> +	 */
> +	sum = min(sum, period);
> +
> +	/*
> +	 * A busy buddy is a CPU with a high load or a small load with a lot of
> +	 * running tasks.
> +	 */
> +	return (sum > (period / (rq->nr_running + 2)));
> +}


I'm still not sold on the entire nr_running thing and the comment doesn't say
why you're doing it.

I'm fairly sure there's software out there that wakes a gazillion threads at a
time only for a gazillion-1 to go back to sleep immediately. Patterns like that
completely defeat your heuristic.

Does that matter... I don't know.

What happens if you keep this thing simple and only put a cap on utilization
(say 80%) and drop the entire nr_running magic? Have you seen it make an actual
difference or did it just seem like a good (TM) thing to do?

> +static bool is_light_task(struct task_struct *p)
> +{
> +	/* A light task runs less than 20% in average */
> +	return ((p->se.avg.runnable_avg_sum  * 5) <
> +			(p->se.avg.runnable_avg_period));
> +}

There superfluous () and ' ' in there. Also why 20%.. seemed like a good
number? Do we want a SCHED_DEBUG sysctl for that?


From jamie at jamieiles.com  Fri Apr 26 08:41:28 2013
From: jamie at jamieiles.com (Jamie Iles)
Date: Fri, 26 Apr 2013 13:41:28 +0100
Subject: dw_apb_timer_of.c: remove parts that were picoxcell-specific
In-Reply-To: <20130426121433.GA16249@amd.pavel.ucw.cz>
References: <20130426121433.GA16249@amd.pavel.ucw.cz>
Message-ID: <20130426124128.GB6946@page>

Hi Pavel,

On Fri, Apr 26, 2013 at 02:14:34PM +0200, Pavel Machek wrote:
> diff --git a/arch/arm/mach-picoxcell/common.c b/arch/arm/mach-picoxcell/common.c
> index 70b441a..22759f5 100644
> --- a/arch/arm/mach-picoxcell/common.c
> +++ b/arch/arm/mach-picoxcell/common.c
> @@ -84,11 +84,39 @@ static void picoxcell_wdt_restart(char mode, const char *cmd)
>  	}
>  }
>  
> +static const struct of_device_id picochip_rtc_ids[] __initconst = {
> +        { .compatible = "picochip,pc3x2-rtc" },
> +        { /* Sentinel */ },
> +};
> +
> +static void __iomem *sched_io_base;
> +
> +static u32 read_sched_clock(void)
> +{
> +        return __raw_readl(sched_io_base);
> +}
> +
> +static void __init timer_init(void)
> +{
> +	u32 rate;
> +
> +	dw_apb_timer_init(0);
> +
> +	sched_timer = of_find_matching_node(timer, osctimer_ids);
> +	if (!sched_timer)
> +		panic("No suitable timer for scheduler clock\n");
> +
> +	timer_get_base_and_rate(sched_timer, &sched_io_base, &rate);
> +	of_node_put(sched_timer);

This doesn't work as osctimer_ids is private to the dw_apb_timer files 
as is timer_get_base_and_rate.  The other timer is unused in picoxcell 
though so dw_apb_timer_init(1), something like the patch below on top of 
yours.

Thanks,

Jamie


diff --git i/arch/arm/mach-picoxcell/common.c w/arch/arm/mach-picoxcell/common.c
index 1484841..a92d203 100644
--- i/arch/arm/mach-picoxcell/common.c
+++ w/arch/arm/mach-picoxcell/common.c
@@ -82,32 +82,9 @@ static void picoxcell_wdt_restart(char mode, const char *cmd)
 	}
 }
 
-static const struct of_device_id picochip_rtc_ids[] __initconst = {
-        { .compatible = "picochip,pc3x2-rtc" },
-        { /* Sentinel */ },
-};
-
-static void __iomem *sched_io_base;
-
-static u32 read_sched_clock(void)
-{
-        return __raw_readl(sched_io_base);
-}
-
 static void __init timer_init(void)
 {
-	u32 rate;
-
-	dw_apb_timer_init(0);
-
-	sched_timer = of_find_matching_node(timer, osctimer_ids);
-	if (!sched_timer)
-		panic("No suitable timer for scheduler clock\n");
-
-	timer_get_base_and_rate(sched_timer, &sched_io_base, &rate);
-	of_node_put(sched_timer);
-
-	setup_sched_clock(read_sched_clock, 32, rate);
+	dw_apb_timer_init(1);
 }
 
 DT_MACHINE_START(PICOXCELL, "Picochip picoXcell")


From peterz at infradead.org  Fri Apr 26 08:49:32 2013
From: peterz at infradead.org (Peter Zijlstra)
Date: Fri, 26 Apr 2013 14:49:32 +0200
Subject: [PATCH 04/14] sched: pack the idle load balance
In-Reply-To: <1366910611-20048-5-git-send-email-vincent.guittot@linaro.org>
References: <1366910611-20048-1-git-send-email-vincent.guittot@linaro.org>
 <1366910611-20048-5-git-send-email-vincent.guittot@linaro.org>
Message-ID: <20130426124931.GC13464@dyad.programming.kicks-ass.net>

On Thu, Apr 25, 2013 at 07:23:20PM +0200, Vincent Guittot wrote:
> Look for an idle CPU close to the pack buddy CPU whenever possible.
> The goal is to prevent the wake up of a CPU which doesn't share the power
> domain of the pack buddy CPU.
> 
> Signed-off-by: Vincent Guittot <vincent.guittot at linaro.org>
> Reviewed-by: Morten Rasmussen <morten.rasmussen at arm.com>
> ---
>  kernel/sched/fair.c |   19 +++++++++++++++++++
>  1 file changed, 19 insertions(+)
> 
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 6adc57c..a985c98 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -5469,7 +5469,26 @@ static struct {
>  
>  static inline int find_new_ilb(int call_cpu)
>  {
> +	struct sched_domain *sd;
>  	int ilb = cpumask_first(nohz.idle_cpus_mask);
> +	int buddy = per_cpu(sd_pack_buddy, call_cpu);
> +
> +	/*
> +	 * If we have a pack buddy CPU, we try to run load balance on a CPU
> +	 * that is close to the buddy.
> +	 */
> +	if (buddy != -1) {
> +		for_each_domain(buddy, sd) {
> +			if (sd->flags & SD_SHARE_CPUPOWER)
> +				continue;
> +
> +			ilb = cpumask_first_and(sched_domain_span(sd),
> +					nohz.idle_cpus_mask);
> +
> +			if (ilb < nr_cpu_ids)
> +				break;
> +		}
> +	}
>  
>  	if (ilb < nr_cpu_ids && idle_cpu(ilb))
>  		return ilb;

Ha! and here you hope people won't put multiple big-little clusters in a single
machine? :-)





From anup.patel at linaro.org  Fri Apr 26 08:59:45 2013
From: anup.patel at linaro.org (Anup Patel)
Date: Fri, 26 Apr 2013 18:29:45 +0530
Subject: [PATCH 0/2] Early printk support for virtio console devices.
In-Reply-To: <1577576.O1Cm2pf5KD@wuerfel>
References: <1366974299-17877-1-git-send-email-pranavkumar@linaro.org>
 <CAFEAcA_xmrHTvR7FxUr3PCKBJY-hZnkeBcqyHksTB4-hqOZS0w@mail.gmail.com>
 <CALrVBkuOmu4u9egdzzfn1tU9B-CFe3w85HZQ9s2gpKvYnaSqvA@mail.gmail.com>
 <1577576.O1Cm2pf5KD@wuerfel>
Message-ID: <CALrVBkuyby_KY_M+yp0e=PLk=7_W_kSxxm62YYSwwp8rwLsCAQ@mail.gmail.com>

On 26 April 2013 18:03, Arnd Bergmann <arnd at arndb.de> wrote:
> On Friday 26 April 2013 17:36:16 Anup Patel wrote:
>> On 26 April 2013 17:03, Peter Maydell <peter.maydell at linaro.org> wrote:
>> > On 26 April 2013 12:19, Alexander Graf <agraf at suse.de> wrote:
>> >> MMIO registers are handled by a different layer than the virtio
>> >> console itself. After the virtio refactoring in QEMU, they will
>> >> be completely separate drivers.
>> >
>> > Good point -- we don't really want to be mixing up the
>> > transport and the backend. You can see it in the kvmtool
>> > patch, in fact -- it introduces an "if this is virtio-console"
>> > special case into the mmio.c file which previously was
>> > entirely backend agnostic.
>>
>> Well, we can always have virtio device specific config registers
>> handle by virtio device backends and generic virtio config register
>> handled by transport.
>>
>> kvmtool patch is hacky because it does not provide virtio device
>> specific config read/write callbacks.
>
> Couldn't kvmtool implement the interface used by smh_printch()
> for early output instead?
>
> Or if that's not a fitting inteface, maybe a psci call for writing
> a character to the console?
>
>         Arnd

I am curious about how smh-based or hypercall-based early prints would
be handled in following scenario:

"A board is running KVM ARM enabled kernel and linux console on serial
port. Now a user remotely connects to the board via telnet/ssh and
launches a VM with smh-based or hypercall-based earlyprintk."

In the above scenario, will smh-based or hypercall-based earlyprints
appear to user on remote shell or not ?

--Anup


From peterz at infradead.org  Fri Apr 26 09:08:35 2013
From: peterz at infradead.org (Peter Zijlstra)
Date: Fri, 26 Apr 2013 15:08:35 +0200
Subject: [PATCH 07/14] sched: agressively pack at wake/fork/exec
In-Reply-To: <1366910611-20048-8-git-send-email-vincent.guittot@linaro.org>
References: <1366910611-20048-1-git-send-email-vincent.guittot@linaro.org>
 <1366910611-20048-8-git-send-email-vincent.guittot@linaro.org>
Message-ID: <20130426130835.GA13964@dyad.programming.kicks-ass.net>

On Thu, Apr 25, 2013 at 07:23:23PM +0200, Vincent Guittot wrote:
> According to the packing policy, the scheduler can pack tasks at different
> step:
> -SCHED_PACKING_NONE level: we don't pack any task.
> -SCHED_PACKING_DEFAULT: we only pack small tasks at wake up when system is not
> busy.
> -SCHED_PACKING_FULL: we pack tasks at wake up until a CPU becomes full. During
> a fork or a exec, we assume that the new task is a full running one and we
> look for an idle CPU close to the buddy CPU.

This changelog is very short on explaining how it will go about achieving these
goals.

> Signed-off-by: Vincent Guittot <vincent.guittot at linaro.org>
> ---
>  kernel/sched/fair.c |   47 ++++++++++++++++++++++++++++++++++++++++++-----
>  1 file changed, 42 insertions(+), 5 deletions(-)
> 
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 98166aa..874f330 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -3259,13 +3259,16 @@ static struct sched_group *
>  find_idlest_group(struct sched_domain *sd, struct task_struct *p,


So for packing into power domains, wouldn't you typically pick the busiest non-
full domain to fill from other non-full?

Picking the idlest non-full seems like it would generate a ping-pong or not
actually pack anything.


From vincent.guittot at linaro.org  Fri Apr 26 09:16:33 2013
From: vincent.guittot at linaro.org (Vincent Guittot)
Date: Fri, 26 Apr 2013 15:16:33 +0200
Subject: [PATCH 03/14] sched: pack small tasks
In-Reply-To: <20130426123002.GA13464@dyad.programming.kicks-ass.net>
References: <1366910611-20048-1-git-send-email-vincent.guittot@linaro.org>
 <1366910611-20048-4-git-send-email-vincent.guittot@linaro.org>
 <20130426123002.GA13464@dyad.programming.kicks-ass.net>
Message-ID: <CAKfTPtBTs17yc_Ff9Es2m6kmvsqidwFjAxYbR0sMJSFBeGGA6A@mail.gmail.com>

On 26 April 2013 14:30, Peter Zijlstra <peterz at infradead.org> wrote:
> On Thu, Apr 25, 2013 at 07:23:19PM +0200, Vincent Guittot wrote:
>> During the creation of sched_domain, we define a pack buddy CPU for each CPU
>> when one is available. We want to pack at all levels where a group of CPUs can
>> be power gated independently from others.
>> On a system that can't power gate a group of CPUs independently, the flag is
>> set at all sched_domain level and the buddy is set to -1. This is the default
>> behavior.
>>
>> On a dual clusters / dual cores system which can power gate each core and
>> cluster independently, the buddy configuration will be :
>>
>>       | Cluster 0   | Cluster 1   |
>>       | CPU0 | CPU1 | CPU2 | CPU3 |
>> -----------------------------------
>> buddy | CPU0 | CPU0 | CPU0 | CPU2 |
>>
>> If the cores in a cluster can't be power gated independently, the buddy
>> configuration becomes:
>>
>>       | Cluster 0   | Cluster 1   |
>>       | CPU0 | CPU1 | CPU2 | CPU3 |
>> -----------------------------------
>> buddy | CPU0 | CPU1 | CPU0 | CPU0 |
>>
>> Small tasks tend to slip out of the periodic load balance so the best place
>> to choose to migrate them is during their wake up. The decision is in O(1) as
>> we only check again one buddy CPU
>
>
> So I really don't get the point of this buddy stuff, even for light load non
> performance impact stuff you want to do.
>
> The moment you judge cpu0 busy you'll bail, even though its perfectly doable
> (and desirable afaict) to continue stacking light tasks on cpu1 instead of
> waking up cpu2/3.
>
> So what's wrong with keeping a single light-wake target cpu selection and
> updating it appropriately?

I have tried to follow the same kind of tasks migration as during load
balance: 1 CPU in a power domain group migrates tasks with other
groups.

>
> Also where/how does the nohz balance cpu criteria not match the light-wake
> target criteria?

The nohz balance cpu is an idle cpu but it doesn't mean that it's the
target cpu which will be sometime busy with the light tasks.


From peterz at infradead.org  Fri Apr 26 09:15:32 2013
From: peterz at infradead.org (Peter Zijlstra)
Date: Fri, 26 Apr 2013 15:15:32 +0200
Subject: [PATCH 08/14] sched: trig ILB on an idle buddy
In-Reply-To: <1366910611-20048-9-git-send-email-vincent.guittot@linaro.org>
References: <1366910611-20048-1-git-send-email-vincent.guittot@linaro.org>
 <1366910611-20048-9-git-send-email-vincent.guittot@linaro.org>
Message-ID: <20130426131532.GB13964@dyad.programming.kicks-ass.net>

On Thu, Apr 25, 2013 at 07:23:24PM +0200, Vincent Guittot wrote:
> If the buddy CPU is not full and currently idle, we trigger an Idle Load
> Balance to give it the opportunity to pull more tasks.
> 
> Signed-off-by: Vincent Guittot <vincent.guittot at linaro.org>
> ---
>  kernel/sched/fair.c |   24 ++++++++++++++++++++++++
>  1 file changed, 24 insertions(+)
> 
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 874f330..954adfd 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -5776,6 +5776,26 @@ end:
>  	clear_bit(NOHZ_BALANCE_KICK, nohz_flags(this_cpu));
>  }
>  
> +static int check_nohz_buddy(int cpu)
> +{
> +	int buddy = per_cpu(sd_pack_buddy, cpu);
> +
> +	if (sysctl_sched_packing_mode != SCHED_PACKING_FULL)
> +		return false;
> +
> +	/* No pack buddy for this CPU */
> +	if (buddy == -1)
> +		return false;
> +
> +	if (is_buddy_full(buddy))
> +		return false;
> +
> +	if (cpumask_test_cpu(buddy, nohz.idle_cpus_mask))
> +		return true;
> +
> +	return false;

return cpumask_test_cpu(..); ?

> +}
> +
>  /*
>   * Current heuristic for kicking the idle load balancer in the presence
>   * of an idle cpu is the system.
> @@ -5813,6 +5833,10 @@ static inline int nohz_kick_needed(struct rq *rq, int cpu)
>  	if (rq->nr_running >= 2)
>  		goto need_kick;
>  
> +	/* the buddy is idle and not busy so we can pack */
> +	if (check_nohz_buddy(cpu))
> +		goto need_kick;
> +
>  	rcu_read_lock();
>  	for_each_domain(cpu, sd) {
>  		struct sched_group *sg = sd->groups;

Bah.. this code is so confusing.. nohz_balance_kick(cpu) won't actually kick
@cpu.

Again.. suppose we're a big cpu (2) and our little buddy cpu (0) is busy, we
miss an opportunity to kick the other little cpu into gear (1) and maybe take
the big core out.




From will.deacon at arm.com  Fri Apr 26 09:21:30 2013
From: will.deacon at arm.com (Will Deacon)
Date: Fri, 26 Apr 2013 14:21:30 +0100
Subject: [PATCH v3] ARM: imx: replicate the diagnostic register of boot
 cpu into secondary cores
In-Reply-To: <1366948645-12060-1-git-send-email-shawn.guo@linaro.org>
References: <1366948645-12060-1-git-send-email-shawn.guo@linaro.org>
Message-ID: <20130426132130.GE30858@mudshark.cambridge.arm.com>

Hi Shawn,

Thanks for respinning this without the MMU enabled.

On Fri, Apr 26, 2013 at 04:57:25AM +0100, Shawn Guo wrote:
> The diagnostic register holds the errata bits.  Mostly bootloader
> does not bring up secondary cores, so that when errata bits are set
> in bootloader, they are set only for boot cpu.  But on a SMP
> configuration, it should be equally done on every single core.
> Set up the diagnostic register for secondary cores by replicating
> the register from boot cpu.
> 
> Signed-off-by: Shawn Guo <shawn.guo at linaro.org>
> ---
> Changes since v2:
>  * Setting secondary cores' diagnostic register before MMU is enabled.
> 
>  arch/arm/mach-imx/headsmp.S |   12 ++++++++++++
>  arch/arm/mach-imx/platsmp.c |   14 ++++++++++++++
>  2 files changed, 26 insertions(+)
> 
> diff --git a/arch/arm/mach-imx/headsmp.S b/arch/arm/mach-imx/headsmp.S
> index a58c8b0..cd87970 100644
> --- a/arch/arm/mach-imx/headsmp.S
> +++ b/arch/arm/mach-imx/headsmp.S
> @@ -18,8 +18,20 @@
>  	.section ".text.head", "ax"
>  
>  #ifdef CONFIG_SMP
> +diag_reg_offset:
> +	.word	g_diag_reg - .
> +
> +	.macro	set_diag_reg
> +	adr	r0, diag_reg_offset
> +	ldr	r1, [r0]
> +	add	r1, r1, r0		@ r1 = physical &g_diag_reg
> +	ldr	r0, [r1]
> +	mcr	p15, 0, r0, c15, c0, 1	@ write diagnostic register
> +	.endm

Why not re-read the register directly, rather than mrc on the current core?
I feel uneasy about blindly copying one CPU's diagnostic bits into another.
It would also make the code simpler.

Will


From coelho at ti.com  Fri Apr 26 09:23:23 2013
From: coelho at ti.com (Luciano Coelho)
Date: Fri, 26 Apr 2013 16:23:23 +0300
Subject: [PATCH 2/3] ARM: dts: Add muxing for wl12xx on the SDIO bus for
 pandaboard
In-Reply-To: <20130426035213.26065.63243.stgit@muffinssi.local>
References: <20130426034858.26065.65118.stgit@muffinssi.local>
 <20130426035213.26065.63243.stgit@muffinssi.local>
Message-ID: <1366982603.4029.42.camel@cumari.coelho.fi>

On Thu, 2013-04-25 at 20:52 -0700, Tony Lindgren wrote:
> This is needed to get wl12xx working with device tree based
> booting.
> 
> Note that we claim the various GPIO inputs in the regulator
> as the proper muxing is needed to enable and disable the
> regulator.
> 
> Also, we want to use non-removable instead of ti,non-removable
> as the ti,non-removable also sets no_regulator_off_init which
> is really not what we want as then wl12xx won't get powered
> up and down which is needed for resetting it.
> 
> Cc: Luciano Coelho <coelho at ti.com>
> Cc: Benoit Cousson <b-cousson at ti.com>
> Cc: Rajendra Nayak <rnayak at ti.com>
> Cc: devicetree-discuss at lists.ozlabs.org
> Signed-off-by: Tony Lindgren <tony at atomide.com>
> ---

I tried this now and it seems to work fine too.  So:

Tested-by: Luciano Coelho <coelho at ti.com>

Except that with linux-next I'm getting some problems with the
interrupts when trying to use wl12xx.  It's not related to this patch
though, and I'm investigating it right now.

Also, I found one small whitespace problem in this patch:

[...]
> +	/* wl12xx GPIO inputs and SDIO pins */
> +	wl12xx_pins: pinmux_wl12xx_pins {
> +		pinctrl-single,pins = <
> +			0x38 0x103	/* gpmc_ncs2.gpio_52 INPUT | MODE3 */
> +			0x3a 0x103	/* gpmc_ncs3.gpio_53 INPUT | MODE3 */
> +			0x108 0x118	/* sdmmc5_clk.sdmmc5_clk INPUT_PULLUP | MODE0 */
> +			0x10a 0x118	/* sdmmc5_cmd.sdmmc5_cmd INPUT_PULLUP | MODE0 */
> +			0x10c 0x118	/* sdmmc5_dat0.sdmmc5_dat0 INPUT_PULLUP | MODE0 */
> +			0x10e 0x118	/* sdmmc5_dat1.sdmmc5_dat1 INPUT_PULLUP | MODE0 */
> +			0x110 0x118	/* sdmmc5_dat2.sdmmc5_dat2 INPUT_PULLUP | MODE0 */
> +			0x112 0x118	/* sdmmc5_dat3.sdmmc5_dat3 INPUT_PULLUP | MODE0 */
> +      		>;

git am reports a "space before tab in indent" here.


-- 
Luca.



From anup.patel at linaro.org  Fri Apr 26 09:27:27 2013
From: anup.patel at linaro.org (Anup Patel)
Date: Fri, 26 Apr 2013 18:57:27 +0530
Subject: [PATCH V3] ARM: KVM: Allow host virtual timer irq number to be
 different from guest virtual timer irq number
Message-ID: <1366982847-11028-1-git-send-email-anup.patel@linaro.org>

The arch_timer irq numbers (or PPI number) are implementation dependent so, the host virtual timer irq number can be different from guest virtual timer irq number.

This patch ensures that host virtual timer irq number is read from DTB and guest virtual timer irq is determined based on guest vcpu target type.

Signed-off-by: Anup Patel <anup.patel at linaro.org>
Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar at linaro.org>
---
 arch/arm/include/asm/kvm_arch_timer.h |    7 +++++++
 arch/arm/include/asm/kvm_host.h       |    1 +
 arch/arm/kvm/arch_timer.c             |   32 +++++++++++++++++++++++++-------
 arch/arm/kvm/guest.c                  |   15 +++++++++++++++
 arch/arm/kvm/reset.c                  |    4 +++-
 5 files changed, 51 insertions(+), 8 deletions(-)

diff --git a/arch/arm/include/asm/kvm_arch_timer.h b/arch/arm/include/asm/kvm_arch_timer.h
index 68cb9e1..c5c135b 100644
--- a/arch/arm/include/asm/kvm_arch_timer.h
+++ b/arch/arm/include/asm/kvm_arch_timer.h
@@ -61,6 +61,7 @@ struct arch_timer_cpu {
 #ifdef CONFIG_KVM_ARM_TIMER
 int kvm_timer_hyp_init(void);
 int kvm_timer_init(struct kvm *kvm);
+int kvm_timer_vcpu_reset(struct kvm_vcpu *vcpu);
 void kvm_timer_vcpu_init(struct kvm_vcpu *vcpu);
 void kvm_timer_flush_hwstate(struct kvm_vcpu *vcpu);
 void kvm_timer_sync_hwstate(struct kvm_vcpu *vcpu);
@@ -76,7 +77,13 @@ static inline int kvm_timer_init(struct kvm *kvm)
 	return 0;
 }
 
+static int kvm_timer_vcpu_reset(struct kvm_vcpu *vcpu)
+{
+	return 0;
+}
+
 static inline void kvm_timer_vcpu_init(struct kvm_vcpu *vcpu) {}
+
 static inline void kvm_timer_flush_hwstate(struct kvm_vcpu *vcpu) {}
 static inline void kvm_timer_sync_hwstate(struct kvm_vcpu *vcpu) {}
 static inline void kvm_timer_vcpu_terminate(struct kvm_vcpu *vcpu) {}
diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
index 57cb786..cdc0551 100644
--- a/arch/arm/include/asm/kvm_host.h
+++ b/arch/arm/include/asm/kvm_host.h
@@ -43,6 +43,7 @@
 struct kvm_vcpu;
 u32 *kvm_vcpu_reg(struct kvm_vcpu *vcpu, u8 reg_num, u32 mode);
 int kvm_target_cpu(void);
+struct kvm_irq_level *kvm_target_timer_irq(struct kvm_vcpu *vcpu);
 int kvm_reset_vcpu(struct kvm_vcpu *vcpu);
 void kvm_reset_coprocs(struct kvm_vcpu *vcpu);
 
diff --git a/arch/arm/kvm/arch_timer.c b/arch/arm/kvm/arch_timer.c
index 49a7516..e558115 100644
--- a/arch/arm/kvm/arch_timer.c
+++ b/arch/arm/kvm/arch_timer.c
@@ -30,7 +30,7 @@
 
 static struct timecounter *timecounter;
 static struct workqueue_struct *wqueue;
-static struct kvm_irq_level timer_irq = {
+static struct kvm_irq_level host_timer_irq = {
 	.level	= 1,
 };
 
@@ -67,8 +67,8 @@ static void kvm_timer_inject_irq(struct kvm_vcpu *vcpu)
 
 	timer->cntv_ctl |= ARCH_TIMER_CTRL_IT_MASK;
 	kvm_vgic_inject_irq(vcpu->kvm, vcpu->vcpu_id,
-			    vcpu->arch.timer_cpu.irq->irq,
-			    vcpu->arch.timer_cpu.irq->level);
+			    timer->irq->irq,
+			    timer->irq->level);
 }
 
 static irqreturn_t kvm_arch_timer_handler(int irq, void *dev_id)
@@ -156,6 +156,24 @@ void kvm_timer_sync_hwstate(struct kvm_vcpu *vcpu)
 	timer_arm(timer, ns);
 }
 
+int kvm_timer_vcpu_reset(struct kvm_vcpu *vcpu)
+{
+	struct arch_timer_cpu *timer = &vcpu->arch.timer_cpu;
+
+	/*
+	 * The vcpu timer irq number cannot be determined in 
+	 * kvm_timer_vcpu_init() because it is called much before
+	 * kvm_vcpu_set_target(). To handle this, we determine
+	 * vcpu timer irq number when the vcpu is resetted.
+	 */
+	timer->irq = kvm_target_timer_irq(vcpu);
+	if (!timer->irq) {
+		return -ENODEV;
+	}
+
+	return 0;
+}
+
 void kvm_timer_vcpu_init(struct kvm_vcpu *vcpu)
 {
 	struct arch_timer_cpu *timer = &vcpu->arch.timer_cpu;
@@ -163,12 +181,12 @@ void kvm_timer_vcpu_init(struct kvm_vcpu *vcpu)
 	INIT_WORK(&timer->expired, kvm_timer_inject_irq_work);
 	hrtimer_init(&timer->timer, CLOCK_MONOTONIC, HRTIMER_MODE_ABS);
 	timer->timer.function = kvm_timer_expire;
-	timer->irq = &timer_irq;
+	timer->irq = NULL;
 }
 
 static void kvm_timer_init_interrupt(void *info)
 {
-	enable_percpu_irq(timer_irq.irq, 0);
+	enable_percpu_irq(host_timer_irq.irq, 0);
 }
 
 
@@ -182,7 +200,7 @@ static int kvm_timer_cpu_notify(struct notifier_block *self,
 		break;
 	case CPU_DYING:
 	case CPU_DYING_FROZEN:
-		disable_percpu_irq(timer_irq.irq);
+		disable_percpu_irq(host_timer_irq.irq);
 		break;
 	}
 
@@ -230,7 +248,7 @@ int kvm_timer_hyp_init(void)
 		goto out;
 	}
 
-	timer_irq.irq = ppi;
+	host_timer_irq.irq = ppi;
 
 	err = register_cpu_notifier(&kvm_timer_cpu_nb);
 	if (err) {
diff --git a/arch/arm/kvm/guest.c b/arch/arm/kvm/guest.c
index 152d036..6fbc988 100644
--- a/arch/arm/kvm/guest.c
+++ b/arch/arm/kvm/guest.c
@@ -36,6 +36,11 @@ struct kvm_stats_debugfs_item debugfs_entries[] = {
 	{ NULL }
 };
 
+static struct kvm_irq_level target_cortex_a15_timer_irq = {
+	.irq = 27,
+	.level = 1,
+};
+
 int kvm_arch_vcpu_setup(struct kvm_vcpu *vcpu)
 {
 	return 0;
@@ -197,6 +202,16 @@ int __attribute_const__ kvm_target_cpu(void)
 	}
 }
 
+struct kvm_irq_level *kvm_target_timer_irq(struct kvm_vcpu *vcpu)
+{
+	switch (vcpu->arch.target) {
+	case KVM_ARM_TARGET_CORTEX_A15:
+		return &target_cortex_a15_timer_irq;
+	default:
+		return NULL;
+	};
+}
+
 int kvm_vcpu_set_target(struct kvm_vcpu *vcpu,
 			const struct kvm_vcpu_init *init)
 {
diff --git a/arch/arm/kvm/reset.c b/arch/arm/kvm/reset.c
index b80256b..655e567 100644
--- a/arch/arm/kvm/reset.c
+++ b/arch/arm/kvm/reset.c
@@ -26,6 +26,7 @@
 #include <asm/cputype.h>
 #include <asm/kvm_arm.h>
 #include <asm/kvm_coproc.h>
+#include <asm/kvm_arch_timer.h>
 
 /******************************************************************************
  * Cortex-A15 Reset Values
@@ -70,5 +71,6 @@ int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
 	/* Reset CP15 registers */
 	kvm_reset_coprocs(vcpu);
 
-	return 0;
+	/* Reset arch_timer context */
+	return kvm_timer_vcpu_reset(vcpu);
 }
-- 
1.7.9.5



From linus.walleij at linaro.org  Fri Apr 26 09:28:37 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Fri, 26 Apr 2013 15:28:37 +0200
Subject: [PATCH 01/23] ARM: u300: fix ages old copy/paste bug
In-Reply-To: <201304221334.04160.arnd@arndb.de>
References: <1366624283-6122-1-git-send-email-linus.walleij@stericsson.com>
 <201304221334.04160.arnd@arndb.de>
Message-ID: <CACRpkdYnk1L3z19yQUJciKOOLUGV_rj3f231-jFKYjcE41kRsw@mail.gmail.com>

On Mon, Apr 22, 2013 at 1:34 PM, Arnd Bergmann <arnd at arndb.de> wrote:
> On Monday 22 April 2013, Linus Walleij wrote:
>> From: Linus Walleij <linus.walleij at linaro.org>
>>
>> The UART1 is on the fast AHB bridge, not on the slow bus.
>>
>> Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
>
> Do you want to mark this for stable?
>
> While there are not a lot of people that would need the fix, I think
> we should do it by habit in cases that fit the stable rules.

OK you're right. I'm sending this one separately to
arm at kernel.org as a fix and marked as stable.

Yours,
Linus Walleij


From linus.walleij at stericsson.com  Fri Apr 26 09:29:55 2013
From: linus.walleij at stericsson.com (Linus Walleij)
Date: Fri, 26 Apr 2013 15:29:55 +0200
Subject: [PATCH] ARM: u300: fix ages old copy/paste bug
Message-ID: <1366982995-10870-1-git-send-email-linus.walleij@stericsson.com>

From: Linus Walleij <linus.walleij at linaro.org>

The UART1 is on the fast AHB bridge, not on the slow bus.

Cc: stable at vger.kernel.org
Acked-by: Arnd Bergmann <arnd at arndb.de>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
Hi ARM SoC folks, as discussed with Arnd, please apply
this patch directly for fixes.
---
 arch/arm/mach-u300/include/mach/u300-regs.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-u300/include/mach/u300-regs.h b/arch/arm/mach-u300/include/mach/u300-regs.h
index 1e49d90..0320495 100644
--- a/arch/arm/mach-u300/include/mach/u300-regs.h
+++ b/arch/arm/mach-u300/include/mach/u300-regs.h
@@ -95,7 +95,7 @@
 #define U300_SPI_BASE			(U300_FAST_PER_PHYS_BASE+0x6000)
 
 /* Fast UART1 on U335 only */
-#define U300_UART1_BASE			(U300_SLOW_PER_PHYS_BASE+0x7000)
+#define U300_UART1_BASE			(U300_FAST_PER_PHYS_BASE+0x7000)
 
 /*
  * SLOW peripherals
-- 
1.7.11.3



From chas at cmf.nrl.navy.mil  Fri Apr 26 09:12:20 2013
From: chas at cmf.nrl.navy.mil (chas williams - CONTRACTOR)
Date: Fri, 26 Apr 2013 09:12:20 -0400
Subject: [PATCH 05/21] atm: he: use mdelay instead of large udelay
 constants
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6026B7203@saturn3.aculab.com>
References: <1366910944-3033663-1-git-send-email-arnd@arndb.de>
 <1366910944-3033663-6-git-send-email-arnd@arndb.de>
 <AE90C24D6B3A694183C094C60CF0A2F6026B7203@saturn3.aculab.com>
Message-ID: <20130426091220.468cf59e@thirdoffive.cmf.nrl.navy.mil>

On Fri, 26 Apr 2013 09:21:59 +0100
"David Laight" <David.Laight at ACULAB.COM> wrote:

> > ARM cannot handle udelay for more than 2 miliseconds, so we
> > should use mdelay instead for those.
> ...
> > @@ -1055,7 +1055,7 @@ static int he_start(struct atm_dev *dev)
> >  	he_writel(he_dev, 0x0, RESET_CNTL);
> >  	he_writel(he_dev, 0xff, RESET_CNTL);
> > 
> > -	udelay(16*1000);	/* 16 ms */
> > +	mdelay(16);	/* 16 ms */
> >  	status = he_readl(he_dev, RESET_CNTL);
> 
> 16ms seems a long time to spin.
> I'd have thought a sleep would be more appropriate.
> Since this looks like timing a hardware reset pulse
> it can't matter if it is somewhat longer.

Yes, I wrote this bit some time ago when I was less wise. The
programmer's guide doesn't say how long to sleep, so the value isn't
critical.  It just has to be "long enough".  An msleep() would be fine
here.


From anup.patel at linaro.org  Fri Apr 26 09:32:16 2013
From: anup.patel at linaro.org (Anup Patel)
Date: Fri, 26 Apr 2013 19:02:16 +0530
Subject: [PATCH] arm64: KVM: Add kvm_target_timer_irq() for arch_timer
Message-ID: <1366983136-11147-1-git-send-email-anup.patel@linaro.org>

This patch adds kvm_target_timer_irq() for KVM ARM64 which determines guest virtual timer ppi number based on vcpu target type.

The patch also updates kvm_vcpu_reset() so that arch_timer is resetted on every vcpu reset.

Signed-off-by: Anup Patel <anup.patel at linaro.org>
Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar at linaro.org>
---
 arch/arm64/include/asm/kvm_host.h |    1 +
 arch/arm64/kvm/guest.c            |   17 +++++++++++++++++
 arch/arm64/kvm/reset.c            |   13 +++++++++++++
 3 files changed, 31 insertions(+)

diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 77eec44..23e185d 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -43,6 +43,7 @@
 
 struct kvm_vcpu;
 int kvm_target_cpu(void);
+struct kvm_irq_level *kvm_target_timer_irq(struct kvm_vcpu *vcpu);
 int kvm_reset_vcpu(struct kvm_vcpu *vcpu);
 int kvm_arch_dev_ioctl_check_extension(long ext);
 
diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
index 8dc349b..ac9ec08 100644
--- a/arch/arm64/kvm/guest.c
+++ b/arch/arm64/kvm/guest.c
@@ -36,6 +36,11 @@ struct kvm_stats_debugfs_item debugfs_entries[] = {
 	{ NULL }
 };
 
+static struct kvm_irq_level target_cortex_a57_timer_irq = {
+	.irq = 27,
+	.level = 1,
+};
+
 int kvm_arch_vcpu_setup(struct kvm_vcpu *vcpu)
 {
 	vcpu->arch.hcr_el2 = HCR_GUEST_FLAGS;
@@ -224,6 +229,18 @@ int __attribute_const__ kvm_target_cpu(void)
 	}
 }
 
+struct kvm_irq_level *kvm_target_timer_irq(struct kvm_vcpu *vcpu)
+{
+	switch (vcpu->arch.target) {
+	case KVM_ARM_TARGET_AEM_V8:
+	case KVM_ARM_TARGET_FOUNDATION_V8:
+	case KVM_ARM_TARGET_CORTEX_A57:
+		return &target_cortex_a57_timer_irq;
+	default:
+		return NULL;
+	};
+}
+
 int kvm_vcpu_set_target(struct kvm_vcpu *vcpu,
 			const struct kvm_vcpu_init *init)
 {
diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
index 64e0740..45f1f10 100644
--- a/arch/arm64/kvm/reset.c
+++ b/arch/arm64/kvm/reset.c
@@ -28,6 +28,14 @@
 #include <asm/kvm_arm.h>
 #include <asm/kvm_coproc.h>
 
+#ifdef CONFIG_KVM_ARM_TIMER
+/*
+ * We cannont directly include arm/include/asm/kvm_arch_timer.h here so,
+ * forward declaring required functions
+ */
+extern int kvm_timer_vcpu_reset(struct kvm_vcpu *vcpu);
+#endif
+
 /*
  * ARMv8 Reset Values
  */
@@ -95,5 +103,10 @@ int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
 	/* Reset system registers */
 	kvm_reset_sys_regs(vcpu);
 
+#ifdef CONFIG_KVM_ARM_TIMER
+	/* Reset arch_timer context */
+	return kvm_timer_vcpu_reset(vcpu);
+#else
 	return 0;
+#endif
 }
-- 
1.7.9.5



From vincent.guittot at linaro.org  Fri Apr 26 09:38:20 2013
From: vincent.guittot at linaro.org (Vincent Guittot)
Date: Fri, 26 Apr 2013 15:38:20 +0200
Subject: [PATCH 03/14] sched: pack small tasks
In-Reply-To: <20130426123827.GB13464@dyad.programming.kicks-ass.net>
References: <1366910611-20048-1-git-send-email-vincent.guittot@linaro.org>
 <1366910611-20048-4-git-send-email-vincent.guittot@linaro.org>
 <20130426123827.GB13464@dyad.programming.kicks-ass.net>
Message-ID: <CAKfTPtBe1Qu7mtao-i=MZj_c2ZBOk-3q7brn5fjx3_feQB4-GA@mail.gmail.com>

On 26 April 2013 14:38, Peter Zijlstra <peterz at infradead.org> wrote:
> On Thu, Apr 25, 2013 at 07:23:19PM +0200, Vincent Guittot wrote:
>
>> +static bool is_buddy_busy(int cpu)
>> +{
>> +     struct rq *rq = cpu_rq(cpu);
>> +     u32 sum = rq->avg.runnable_avg_sum;
>> +     u32 period = rq->avg.runnable_avg_period;
>> +
>> +     /*
>> +      * If a CPU accesses the runnable_avg_sum and runnable_avg_period
>> +      * fields of its buddy CPU while the latter updates it, it can get the
>> +      * new version of a field and the old version of the other one. This
>> +      * can generate erroneous decisions. We don't want to use a lock
>> +      * mechanism for ensuring the coherency because of the overhead in
>> +      * this critical path.
>> +      * The runnable_avg_period of a runqueue tends to the max value in
>> +      * less than 345ms after plugging a CPU, which implies that we could
>> +      * use the max value instead of reading runnable_avg_period after
>> +      * 345ms. During the starting phase, we must ensure a minimum of
>> +      * coherency between the fields. A simple rule is runnable_avg_sum <=
>> +      * runnable_avg_period.
>> +      */
>> +     sum = min(sum, period);
>> +
>> +     /*
>> +      * A busy buddy is a CPU with a high load or a small load with a lot of
>> +      * running tasks.
>> +      */
>> +     return (sum > (period / (rq->nr_running + 2)));
>> +}
>
>
> I'm still not sold on the entire nr_running thing and the comment doesn't say
> why you're doing it.

The main goal is really to minimize the scheduling latency of tasks.
If the cpu already has dozens of task in its runqueue the scheduling
latency can become quite huge. In this case it's worth using another
core

>
> I'm fairly sure there's software out there that wakes a gazillion threads at a
> time only for a gazillion-1 to go back to sleep immediately. Patterns like that
> completely defeat your heuristic.
>
> Does that matter... I don't know.
>
> What happens if you keep this thing simple and only put a cap on utilization
> (say 80%) and drop the entire nr_running magic? Have you seen it make an actual
> difference or did it just seem like a good (TM) thing to do?

It was a efficient way

>
>> +static bool is_light_task(struct task_struct *p)
>> +{
>> +     /* A light task runs less than 20% in average */
>> +     return ((p->se.avg.runnable_avg_sum  * 5) <
>> +                     (p->se.avg.runnable_avg_period));
>> +}
>
> There superfluous () and ' ' in there. Also why 20%.. seemed like a good
> number? Do we want a SCHED_DEBUG sysctl for that?

I have chosen 20% because it will ensure that the packing mechanism
will only apply on tasks that match the 2 following conditions:
- less than 10 ms during the last single run
- and for those tasks less than 20% of the time in average

These tasks are nearly never catch by the periodic load balance and
they are so small that the overall scheduling latency is nearly not
impacted while the cpu is not too busy


From linus.walleij at linaro.org  Fri Apr 26 09:38:45 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Fri, 26 Apr 2013 15:38:45 +0200
Subject: [PATCH 03/23] ARM: u300: device tree support for the timer
In-Reply-To: <201304221336.21921.arnd@arndb.de>
References: <1366624304-6190-1-git-send-email-linus.walleij@stericsson.com>
 <201304221336.21921.arnd@arndb.de>
Message-ID: <CACRpkdbfDwhKA77aUbXhk5sZ0prxR-ic5dntCaAiNjKNBGo_wg@mail.gmail.com>

On Mon, Apr 22, 2013 at 1:36 PM, Arnd Bergmann <arnd at arndb.de> wrote:
> On Monday 22 April 2013, Linus Walleij wrote:
>> +#ifdef CONFIG_OF
>> +       struct device_node *timer = NULL;
>> +
>> +       timer = of_find_node_by_path("/timer0 at c0014000");
>> +       if (timer) {
>> +               struct resource irq_res;
>> +
>> +               u300_timer_base = of_iomap(timer, 0);
>> +               /* Get the IRQ for the GP1 timer */
>> +               irq = of_irq_to_resource(timer, 2, &irq_res);
>> +       }
>> +#endif
>
> Do you need the #ifdef? The functions should be defined in a way that
> removes this code if CONFIG_OF is not defined.

Actually not, this happens without CONFIG_OF:

  CC      arch/arm/mach-u300/timer.o
/home/elinwal/linux-stericsson/arch/arm/mach-u300/timer.c: In function
'u300_timer_init':
/home/elinwal/linux-stericsson/arch/arm/mach-u300/timer.c:371:2:
error: implicit declaration of function 'of_find_node_by_path'
[-Werror=implicit-function-declaration]
/home/elinwal/linux-stericsson/arch/arm/mach-u300/timer.c:371:8:
warning: assignment makes pointer from integer without a cast [enabled
by default]
/home/elinwal/linux-stericsson/arch/arm/mach-u300/timer.c:377:3:
error: implicit declaration of function 'of_irq_to_resource'
[-Werror=implicit-function-declaration]
cc1: some warnings being treated as errors

make[3]: *** [arch/arm/mach-u300/timer.o] Error 1
make[2]: *** [arch/arm/mach-u300] Error 2
make[2]: *** Waiting for unfinished jobs....

Maybe it's just a bug that these don't have the proper stubs in <linux/of.h>?

Or is there a deeper idea behind this? (CC some OF ppl.)

Yours,
Linus Walleij


From lee.jones at linaro.org  Fri Apr 26 09:42:14 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Fri, 26 Apr 2013 14:42:14 +0100
Subject: [PATCH 32/32] ARM: ux500: Move SDI (MMC) and UART devices under
 more descriptive heading
In-Reply-To: <CACRpkdbxwPh+j_=CBFeH83n0XHSbcShnZ7Reb54+5cWYL-j3-w@mail.gmail.com>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-33-git-send-email-lee.jones@linaro.org>
 <CACRpkdbxwPh+j_=CBFeH83n0XHSbcShnZ7Reb54+5cWYL-j3-w@mail.gmail.com>
Message-ID: <20130426134214.GC31899@gmail.com>

On Thu, 25 Apr 2013, Linus Walleij wrote:

> On Thu, Apr 18, 2013 at 12:12 PM, Lee Jones <lee.jones at linaro.org> wrote:
> 
> > Now DMA DT bindings exist and are in use by he MMC and UART drivers, it
> > should be possible to remove them from the auxdata structure. However,
> > after doing so the drivers fail. Something must be reliant on the dev
> > name applied by using auxdata; probably common clk.
> >
> > Signed-off-by: Lee Jones <lee.jones at linaro.org>
> 
> You can remove "probably" from that sentence. Common clock is
> still relying on dev_name() to match the device name.
> 
> There are some example of how to fix this, I recently sent a patch
> series fixing DT probed clocks for the Nomadik, check it out.

You could have me some time here by giving me the $SUBJECT. :)

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From robherring2 at gmail.com  Fri Apr 26 09:44:06 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Fri, 26 Apr 2013 08:44:06 -0500
Subject: [PATCH 03/23] ARM: u300: device tree support for the timer
In-Reply-To: <CACRpkdbfDwhKA77aUbXhk5sZ0prxR-ic5dntCaAiNjKNBGo_wg@mail.gmail.com>
References: <1366624304-6190-1-git-send-email-linus.walleij@stericsson.com>
 <201304221336.21921.arnd@arndb.de>
 <CACRpkdbfDwhKA77aUbXhk5sZ0prxR-ic5dntCaAiNjKNBGo_wg@mail.gmail.com>
Message-ID: <517A84A6.4090108@gmail.com>

On 04/26/2013 08:38 AM, Linus Walleij wrote:
> On Mon, Apr 22, 2013 at 1:36 PM, Arnd Bergmann <arnd at arndb.de> wrote:
>> On Monday 22 April 2013, Linus Walleij wrote:
>>> +#ifdef CONFIG_OF
>>> +       struct device_node *timer = NULL;
>>> +
>>> +       timer = of_find_node_by_path("/timer0 at c0014000");
>>> +       if (timer) {
>>> +               struct resource irq_res;
>>> +
>>> +               u300_timer_base = of_iomap(timer, 0);
>>> +               /* Get the IRQ for the GP1 timer */
>>> +               irq = of_irq_to_resource(timer, 2, &irq_res);
>>> +       }
>>> +#endif
>>
>> Do you need the #ifdef? The functions should be defined in a way that
>> removes this code if CONFIG_OF is not defined.
> 
> Actually not, this happens without CONFIG_OF:
> 
>   CC      arch/arm/mach-u300/timer.o
> /home/elinwal/linux-stericsson/arch/arm/mach-u300/timer.c: In function
> 'u300_timer_init':
> /home/elinwal/linux-stericsson/arch/arm/mach-u300/timer.c:371:2:
> error: implicit declaration of function 'of_find_node_by_path'
> [-Werror=implicit-function-declaration]
> /home/elinwal/linux-stericsson/arch/arm/mach-u300/timer.c:371:8:
> warning: assignment makes pointer from integer without a cast [enabled
> by default]
> /home/elinwal/linux-stericsson/arch/arm/mach-u300/timer.c:377:3:
> error: implicit declaration of function 'of_irq_to_resource'
> [-Werror=implicit-function-declaration]
> cc1: some warnings being treated as errors
> 
> make[3]: *** [arch/arm/mach-u300/timer.o] Error 1
> make[2]: *** [arch/arm/mach-u300] Error 2
> make[2]: *** Waiting for unfinished jobs....
> 
> Maybe it's just a bug that these don't have the proper stubs in <linux/of.h>?
> 
> Or is there a deeper idea behind this? (CC some OF ppl.)

Yes, you could add empty function, but searching by path is probably not
the right thing to do. Why not use clocksource_of_init? That's what all
the cool kids are doing now. Is there some special feature of the timer
at this address? If so, then add a property to describe that feature and
key off of that plus the compatible prop.

Rob

> 
> Yours,
> Linus Walleij
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
> 



From marc.zyngier at arm.com  Fri Apr 26 09:47:12 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Fri, 26 Apr 2013 14:47:12 +0100
Subject: [PATCH V3] ARM: KVM: Allow host virtual timer irq number to be
 different from guest virtual timer irq number
In-Reply-To: <1366982847-11028-1-git-send-email-anup.patel@linaro.org>
References: <1366982847-11028-1-git-send-email-anup.patel@linaro.org>
Message-ID: <517A8560.6070005@arm.com>

On 26/04/13 14:27, Anup Patel wrote:
> The arch_timer irq numbers (or PPI number) are implementation dependent so, the host virtual timer irq number can be different from guest virtual timer irq number.
> 
> This patch ensures that host virtual timer irq number is read from DTB and guest virtual timer irq is determined based on guest vcpu target type.
> 
> Signed-off-by: Anup Patel <anup.patel at linaro.org>
> Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar at linaro.org>
> ---
>  arch/arm/include/asm/kvm_arch_timer.h |    7 +++++++
>  arch/arm/include/asm/kvm_host.h       |    1 +
>  arch/arm/kvm/arch_timer.c             |   32 +++++++++++++++++++++++++-------
>  arch/arm/kvm/guest.c                  |   15 +++++++++++++++
>  arch/arm/kvm/reset.c                  |    4 +++-
>  5 files changed, 51 insertions(+), 8 deletions(-)
> 
> diff --git a/arch/arm/include/asm/kvm_arch_timer.h b/arch/arm/include/asm/kvm_arch_timer.h
> index 68cb9e1..c5c135b 100644
> --- a/arch/arm/include/asm/kvm_arch_timer.h
> +++ b/arch/arm/include/asm/kvm_arch_timer.h
> @@ -61,6 +61,7 @@ struct arch_timer_cpu {
>  #ifdef CONFIG_KVM_ARM_TIMER
>  int kvm_timer_hyp_init(void);
>  int kvm_timer_init(struct kvm *kvm);
> +int kvm_timer_vcpu_reset(struct kvm_vcpu *vcpu);
>  void kvm_timer_vcpu_init(struct kvm_vcpu *vcpu);
>  void kvm_timer_flush_hwstate(struct kvm_vcpu *vcpu);
>  void kvm_timer_sync_hwstate(struct kvm_vcpu *vcpu);
> @@ -76,7 +77,13 @@ static inline int kvm_timer_init(struct kvm *kvm)
>  	return 0;
>  }
>  
> +static int kvm_timer_vcpu_reset(struct kvm_vcpu *vcpu)
> +{
> +	return 0;
> +}
> +
>  static inline void kvm_timer_vcpu_init(struct kvm_vcpu *vcpu) {}
> +
>  static inline void kvm_timer_flush_hwstate(struct kvm_vcpu *vcpu) {}
>  static inline void kvm_timer_sync_hwstate(struct kvm_vcpu *vcpu) {}
>  static inline void kvm_timer_vcpu_terminate(struct kvm_vcpu *vcpu) {}
> diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
> index 57cb786..cdc0551 100644
> --- a/arch/arm/include/asm/kvm_host.h
> +++ b/arch/arm/include/asm/kvm_host.h
> @@ -43,6 +43,7 @@
>  struct kvm_vcpu;
>  u32 *kvm_vcpu_reg(struct kvm_vcpu *vcpu, u8 reg_num, u32 mode);
>  int kvm_target_cpu(void);
> +struct kvm_irq_level *kvm_target_timer_irq(struct kvm_vcpu *vcpu);
>  int kvm_reset_vcpu(struct kvm_vcpu *vcpu);
>  void kvm_reset_coprocs(struct kvm_vcpu *vcpu);
>  
> diff --git a/arch/arm/kvm/arch_timer.c b/arch/arm/kvm/arch_timer.c
> index 49a7516..e558115 100644
> --- a/arch/arm/kvm/arch_timer.c
> +++ b/arch/arm/kvm/arch_timer.c
> @@ -30,7 +30,7 @@
>  
>  static struct timecounter *timecounter;
>  static struct workqueue_struct *wqueue;
> -static struct kvm_irq_level timer_irq = {
> +static struct kvm_irq_level host_timer_irq = {
>  	.level	= 1,
>  };
>  
> @@ -67,8 +67,8 @@ static void kvm_timer_inject_irq(struct kvm_vcpu *vcpu)
>  
>  	timer->cntv_ctl |= ARCH_TIMER_CTRL_IT_MASK;
>  	kvm_vgic_inject_irq(vcpu->kvm, vcpu->vcpu_id,
> -			    vcpu->arch.timer_cpu.irq->irq,
> -			    vcpu->arch.timer_cpu.irq->level);
> +			    timer->irq->irq,
> +			    timer->irq->level);
>  }
>  
>  static irqreturn_t kvm_arch_timer_handler(int irq, void *dev_id)
> @@ -156,6 +156,24 @@ void kvm_timer_sync_hwstate(struct kvm_vcpu *vcpu)
>  	timer_arm(timer, ns);
>  }
>  
> +int kvm_timer_vcpu_reset(struct kvm_vcpu *vcpu)

If you change this function to:
int kvm_timer_vcpu_reset(struct kvm_vcpu *vcpu, struct kvm_irq_level *irq)

...

> +{
> +	struct arch_timer_cpu *timer = &vcpu->arch.timer_cpu;
> +
> +	/*
> +	 * The vcpu timer irq number cannot be determined in 
> +	 * kvm_timer_vcpu_init() because it is called much before
> +	 * kvm_vcpu_set_target(). To handle this, we determine
> +	 * vcpu timer irq number when the vcpu is resetted.
> +	 */
> +	timer->irq = kvm_target_timer_irq(vcpu);
> +	if (!timer->irq) {
> +		return -ENODEV;
> +	}
> +
> +	return 0;
> +}
> +
>  void kvm_timer_vcpu_init(struct kvm_vcpu *vcpu)
>  {
>  	struct arch_timer_cpu *timer = &vcpu->arch.timer_cpu;
> @@ -163,12 +181,12 @@ void kvm_timer_vcpu_init(struct kvm_vcpu *vcpu)
>  	INIT_WORK(&timer->expired, kvm_timer_inject_irq_work);
>  	hrtimer_init(&timer->timer, CLOCK_MONOTONIC, HRTIMER_MODE_ABS);
>  	timer->timer.function = kvm_timer_expire;
> -	timer->irq = &timer_irq;
> +	timer->irq = NULL;
>  }
>  
>  static void kvm_timer_init_interrupt(void *info)
>  {
> -	enable_percpu_irq(timer_irq.irq, 0);
> +	enable_percpu_irq(host_timer_irq.irq, 0);
>  }
>  
>  
> @@ -182,7 +200,7 @@ static int kvm_timer_cpu_notify(struct notifier_block *self,
>  		break;
>  	case CPU_DYING:
>  	case CPU_DYING_FROZEN:
> -		disable_percpu_irq(timer_irq.irq);
> +		disable_percpu_irq(host_timer_irq.irq);
>  		break;
>  	}
>  
> @@ -230,7 +248,7 @@ int kvm_timer_hyp_init(void)
>  		goto out;
>  	}
>  
> -	timer_irq.irq = ppi;
> +	host_timer_irq.irq = ppi;
>  
>  	err = register_cpu_notifier(&kvm_timer_cpu_nb);
>  	if (err) {
> diff --git a/arch/arm/kvm/guest.c b/arch/arm/kvm/guest.c
> index 152d036..6fbc988 100644
> --- a/arch/arm/kvm/guest.c
> +++ b/arch/arm/kvm/guest.c
> @@ -36,6 +36,11 @@ struct kvm_stats_debugfs_item debugfs_entries[] = {
>  	{ NULL }
>  };
>  
> +static struct kvm_irq_level target_cortex_a15_timer_irq = {
> +	.irq = 27,
> +	.level = 1,
> +};

... Move this to reset.c ...

>  int kvm_arch_vcpu_setup(struct kvm_vcpu *vcpu)
>  {
>  	return 0;
> @@ -197,6 +202,16 @@ int __attribute_const__ kvm_target_cpu(void)
>  	}
>  }
>  
> +struct kvm_irq_level *kvm_target_timer_irq(struct kvm_vcpu *vcpu)
> +{
> +	switch (vcpu->arch.target) {
> +	case KVM_ARM_TARGET_CORTEX_A15:
> +		return &target_cortex_a15_timer_irq;
> +	default:
> +		return NULL;
> +	};
> +}

... drop this ...

>  int kvm_vcpu_set_target(struct kvm_vcpu *vcpu,
>  			const struct kvm_vcpu_init *init)
>  {
> diff --git a/arch/arm/kvm/reset.c b/arch/arm/kvm/reset.c
> index b80256b..655e567 100644
> --- a/arch/arm/kvm/reset.c
> +++ b/arch/arm/kvm/reset.c
> @@ -26,6 +26,7 @@
>  #include <asm/cputype.h>
>  #include <asm/kvm_arm.h>
>  #include <asm/kvm_coproc.h>
> +#include <asm/kvm_arch_timer.h>
>  
>  /******************************************************************************
>   * Cortex-A15 Reset Values
> @@ -70,5 +71,6 @@ int kvm_reset_vcpu(struct kvm_vcpu *vcpu)

...

In	case KVM_ARM_TARGET_CORTEX_A15:
[...]
	timer_irq = &target_cortex_a15_timer_irq;

...

>  	/* Reset CP15 registers */
>  	kvm_reset_coprocs(vcpu);
>  
> -	return 0;
> +	/* Reset arch_timer context */
> +	return kvm_timer_vcpu_reset(vcpu);

... and call kvm_timer_vcpu_reset(vcpu, timer_irq)

it would look much better.

	M.
-- 
Jazz is not dead. It just smells funny...



From shawn.guo at linaro.org  Fri Apr 26 09:47:24 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Fri, 26 Apr 2013 21:47:24 +0800
Subject: [PATCH v3] ARM: imx: replicate the diagnostic register of boot
 cpu into secondary cores
In-Reply-To: <20130426132130.GE30858@mudshark.cambridge.arm.com>
References: <1366948645-12060-1-git-send-email-shawn.guo@linaro.org>
 <20130426132130.GE30858@mudshark.cambridge.arm.com>
Message-ID: <20130426134722.GA1943@S2101-09.ap.freescale.net>

On Fri, Apr 26, 2013 at 02:21:30PM +0100, Will Deacon wrote:
> > diff --git a/arch/arm/mach-imx/headsmp.S b/arch/arm/mach-imx/headsmp.S
> > index a58c8b0..cd87970 100644
> > --- a/arch/arm/mach-imx/headsmp.S
> > +++ b/arch/arm/mach-imx/headsmp.S
> > @@ -18,8 +18,20 @@
> >  	.section ".text.head", "ax"
> >  
> >  #ifdef CONFIG_SMP
> > +diag_reg_offset:
> > +	.word	g_diag_reg - .
> > +
> > +	.macro	set_diag_reg
> > +	adr	r0, diag_reg_offset
> > +	ldr	r1, [r0]
> > +	add	r1, r1, r0		@ r1 = physical &g_diag_reg
> > +	ldr	r0, [r1]
> > +	mcr	p15, 0, r0, c15, c0, 1	@ write diagnostic register
> > +	.endm
> 
> Why not re-read the register directly, rather than mrc on the current core?

I do not understand the comment.  What do you mean by "re-read"?  Read
the register on secondary cores will only return us 0, as bootloader
only sets up the register on cpu0.  The macro set_diag_reg only runs on
secondary cores to copy cpu0's diagnostic bits.  I think it's safe on
SMP.

Shawn

> I feel uneasy about blindly copying one CPU's diagnostic bits into another.
> It would also make the code simpler.



From vincent.guittot at linaro.org  Fri Apr 26 09:47:33 2013
From: vincent.guittot at linaro.org (Vincent Guittot)
Date: Fri, 26 Apr 2013 15:47:33 +0200
Subject: [PATCH 04/14] sched: pack the idle load balance
In-Reply-To: <20130426124931.GC13464@dyad.programming.kicks-ass.net>
References: <1366910611-20048-1-git-send-email-vincent.guittot@linaro.org>
 <1366910611-20048-5-git-send-email-vincent.guittot@linaro.org>
 <20130426124931.GC13464@dyad.programming.kicks-ass.net>
Message-ID: <CAKfTPtB0B8gM7C75D6EwWxQV_PRYpo+q48ywY26k8KVHx+oiqA@mail.gmail.com>

On 26 April 2013 14:49, Peter Zijlstra <peterz at infradead.org> wrote:
> On Thu, Apr 25, 2013 at 07:23:20PM +0200, Vincent Guittot wrote:
>> Look for an idle CPU close to the pack buddy CPU whenever possible.
>> The goal is to prevent the wake up of a CPU which doesn't share the power
>> domain of the pack buddy CPU.
>>
>> Signed-off-by: Vincent Guittot <vincent.guittot at linaro.org>
>> Reviewed-by: Morten Rasmussen <morten.rasmussen at arm.com>
>> ---
>>  kernel/sched/fair.c |   19 +++++++++++++++++++
>>  1 file changed, 19 insertions(+)
>>
>> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
>> index 6adc57c..a985c98 100644
>> --- a/kernel/sched/fair.c
>> +++ b/kernel/sched/fair.c
>> @@ -5469,7 +5469,26 @@ static struct {
>>
>>  static inline int find_new_ilb(int call_cpu)
>>  {
>> +     struct sched_domain *sd;
>>       int ilb = cpumask_first(nohz.idle_cpus_mask);
>> +     int buddy = per_cpu(sd_pack_buddy, call_cpu);
>> +
>> +     /*
>> +      * If we have a pack buddy CPU, we try to run load balance on a CPU
>> +      * that is close to the buddy.
>> +      */
>> +     if (buddy != -1) {
>> +             for_each_domain(buddy, sd) {
>> +                     if (sd->flags & SD_SHARE_CPUPOWER)
>> +                             continue;
>> +
>> +                     ilb = cpumask_first_and(sched_domain_span(sd),
>> +                                     nohz.idle_cpus_mask);
>> +
>> +                     if (ilb < nr_cpu_ids)
>> +                             break;
>> +             }
>> +     }
>>
>>       if (ilb < nr_cpu_ids && idle_cpu(ilb))
>>               return ilb;
>
> Ha! and here you hope people won't put multiple big-little clusters in a single
> machine? :-)

yes, we will probably face this situation sooner or later but the
other little clusters will probably be not less close than the local
big cluster from a power domain point of view.
That's why i look for the small sched_domain level to the largest one

>
>
>


From marc.zyngier at arm.com  Fri Apr 26 09:49:09 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Fri, 26 Apr 2013 14:49:09 +0100
Subject: [PATCH] arm64: KVM: Add kvm_target_timer_irq() for arch_timer
In-Reply-To: <1366983136-11147-1-git-send-email-anup.patel@linaro.org>
References: <1366983136-11147-1-git-send-email-anup.patel@linaro.org>
Message-ID: <517A85D5.1050704@arm.com>

On 26/04/13 14:32, Anup Patel wrote:
> This patch adds kvm_target_timer_irq() for KVM ARM64 which determines guest virtual timer ppi number based on vcpu target type.
> 
> The patch also updates kvm_vcpu_reset() so that arch_timer is resetted on every vcpu reset.
> 
> Signed-off-by: Anup Patel <anup.patel at linaro.org>
> Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar at linaro.org>

Same remarks as the 32bit version, plus...

> ---
>  arch/arm64/include/asm/kvm_host.h |    1 +
>  arch/arm64/kvm/guest.c            |   17 +++++++++++++++++
>  arch/arm64/kvm/reset.c            |   13 +++++++++++++
>  3 files changed, 31 insertions(+)
> 
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index 77eec44..23e185d 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -43,6 +43,7 @@
>  
>  struct kvm_vcpu;
>  int kvm_target_cpu(void);
> +struct kvm_irq_level *kvm_target_timer_irq(struct kvm_vcpu *vcpu);
>  int kvm_reset_vcpu(struct kvm_vcpu *vcpu);
>  int kvm_arch_dev_ioctl_check_extension(long ext);
>  
> diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
> index 8dc349b..ac9ec08 100644
> --- a/arch/arm64/kvm/guest.c
> +++ b/arch/arm64/kvm/guest.c
> @@ -36,6 +36,11 @@ struct kvm_stats_debugfs_item debugfs_entries[] = {
>  	{ NULL }
>  };
>  
> +static struct kvm_irq_level target_cortex_a57_timer_irq = {
> +	.irq = 27,
> +	.level = 1,
> +};
> +
>  int kvm_arch_vcpu_setup(struct kvm_vcpu *vcpu)
>  {
>  	vcpu->arch.hcr_el2 = HCR_GUEST_FLAGS;
> @@ -224,6 +229,18 @@ int __attribute_const__ kvm_target_cpu(void)
>  	}
>  }
>  
> +struct kvm_irq_level *kvm_target_timer_irq(struct kvm_vcpu *vcpu)
> +{
> +	switch (vcpu->arch.target) {
> +	case KVM_ARM_TARGET_AEM_V8:
> +	case KVM_ARM_TARGET_FOUNDATION_V8:
> +	case KVM_ARM_TARGET_CORTEX_A57:
> +		return &target_cortex_a57_timer_irq;
> +	default:
> +		return NULL;
> +	};
> +}
> +
>  int kvm_vcpu_set_target(struct kvm_vcpu *vcpu,
>  			const struct kvm_vcpu_init *init)
>  {
> diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
> index 64e0740..45f1f10 100644
> --- a/arch/arm64/kvm/reset.c
> +++ b/arch/arm64/kvm/reset.c
> @@ -28,6 +28,14 @@
>  #include <asm/kvm_arm.h>
>  #include <asm/kvm_coproc.h>
>  
> +#ifdef CONFIG_KVM_ARM_TIMER

arm64 mandates the architected timers, so no need to #ifdef anything.

> +/*
> + * We cannont directly include arm/include/asm/kvm_arch_timer.h here so,

What's wrong with arch/arm64/include/asm/kvm_arch_timer.h???

> + * forward declaring required functions
> + */
> +extern int kvm_timer_vcpu_reset(struct kvm_vcpu *vcpu);
> +#endif
> +
>  /*
>   * ARMv8 Reset Values
>   */
> @@ -95,5 +103,10 @@ int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
>  	/* Reset system registers */
>  	kvm_reset_sys_regs(vcpu);
>  
> +#ifdef CONFIG_KVM_ARM_TIMER
> +	/* Reset arch_timer context */
> +	return kvm_timer_vcpu_reset(vcpu);
> +#else
>  	return 0;
> +#endif
>  }
> 


-- 
Jazz is not dead. It just smells funny...



From fabio.baltieri at linaro.org  Fri Apr 26 09:49:15 2013
From: fabio.baltieri at linaro.org (Fabio Baltieri)
Date: Fri, 26 Apr 2013 15:49:15 +0200
Subject: [PATCH 00/10] usb: musb: ux500: pathe the way for Device Tree
 enablement
In-Reply-To: <1366729394-11406-1-git-send-email-lee.jones@linaro.org>
References: <1366729394-11406-1-git-send-email-lee.jones@linaro.org>
Message-ID: <20130426134915.GA19558@balto.lan>

Hi Lee,

On Tue, Apr 23, 2013 at 04:03:04PM +0100, Lee Jones wrote:
> In this patch-set we firstly ease the burden on data being passed from
> platform data, then start to build up support to finally enable Device
> Tree.

The whole series looks good to me, nice job!!

Acked-by: Fabio Baltieri <fabio.baltieri at linaro.org>

I was not able to apply the patches though, as I can imagine that there
are some dependencies with your other dma40 series.  If you can provide a
tree I would be happy to run some test for both host and device mode.
I still have a bunch of USB cables and adapters tangled together on my
desk ready for that.

Fabio

-- 
Fabio Baltieri


From linus.walleij at stericsson.com  Fri Apr 26 09:56:45 2013
From: linus.walleij at stericsson.com (Linus Walleij)
Date: Fri, 26 Apr 2013 15:56:45 +0200
Subject: [PATCH 05/23 v2] pinctrl: coh901: add device tree support
Message-ID: <1366984605-23951-1-git-send-email-linus.walleij@stericsson.com>

From: Linus Walleij <linus.walleij at linaro.org>

This makes it possible to probe the COH901 pinctrl driver from
the device tree, and assigned the device tree node in the
gpio_chip so we can look up cross-references from the device
tree. Start grabbing the per-port (bank) IRQs by index instead
of by name so we don't have to look up the IRQs by name going
forward.

Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
ChangeLog v1->v2:
- Alter the driver to look up IRQ by index.
- Alter the bindings accordingly.
---
 .../devicetree/bindings/gpio/gpio-stericsson-coh901.txt      |  7 +++++++
 drivers/pinctrl/pinctrl-coh901.c                             | 12 ++++++++++--
 2 files changed, 17 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/gpio/gpio-stericsson-coh901.txt

diff --git a/Documentation/devicetree/bindings/gpio/gpio-stericsson-coh901.txt b/Documentation/devicetree/bindings/gpio/gpio-stericsson-coh901.txt
new file mode 100644
index 0000000..fd665b4
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-stericsson-coh901.txt
@@ -0,0 +1,7 @@
+ST-Ericsson COH 901 571/3 GPIO controller
+
+Required properties:
+- compatible: Compatible property value should be "stericsson,gpio-coh901"
+- reg: Physical base address of the controller and length of memory mapped
+  region.
+- interrupts: the 0...n interrupts assigned to the different GPIO ports/banks.
diff --git a/drivers/pinctrl/pinctrl-coh901.c b/drivers/pinctrl/pinctrl-coh901.c
index 8b7e7bc..4152ca2 100644
--- a/drivers/pinctrl/pinctrl-coh901.c
+++ b/drivers/pinctrl/pinctrl-coh901.c
@@ -770,8 +770,7 @@ static int __init u300_gpio_probe(struct platform_device *pdev)
 		port->number = portno;
 		port->gpio = gpio;
 
-		port->irq = platform_get_irq_byname(pdev,
-						    port->name);
+		port->irq = platform_get_irq(pdev, portno);
 
 		dev_dbg(gpio->dev, "register IRQ %d for port %s\n", port->irq,
 			port->name);
@@ -808,6 +807,9 @@ static int __init u300_gpio_probe(struct platform_device *pdev)
 	}
 	dev_dbg(gpio->dev, "initialized %d GPIO ports\n", portno);
 
+#ifdef CONFIG_OF_GPIO
+	gpio->chip.of_node = pdev->dev.of_node;
+#endif
 	err = gpiochip_add(&gpio->chip);
 	if (err) {
 		dev_err(gpio->dev, "unable to add gpiochip: %d\n", err);
@@ -861,9 +863,15 @@ static int __exit u300_gpio_remove(struct platform_device *pdev)
 	return 0;
 }
 
+static const struct of_device_id u300_gpio_match[] = {
+	{ .compatible = "stericsson,gpio-coh901" },
+	{},
+};
+
 static struct platform_driver u300_gpio_driver = {
 	.driver		= {
 		.name	= "u300-gpio",
+		.of_match_table = u300_gpio_match,
 	},
 	.remove		= __exit_p(u300_gpio_remove),
 };
-- 
1.7.11.3



From arnd at arndb.de  Fri Apr 26 10:04:44 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 26 Apr 2013 16:04:44 +0200
Subject: [PATCH V3 2/3] ARM: net: bpf_jit: make code generation less
 dependent on struct sk_filter.
In-Reply-To: <1366824429-26652-3-git-send-email-nschichan@freebox.fr>
References: <1366824429-26652-1-git-send-email-nschichan@freebox.fr>
 <1366824429-26652-3-git-send-email-nschichan@freebox.fr>
Message-ID: <3592414.M8kQZLCXlW@wuerfel>

On Wednesday 24 April 2013 19:27:08 Nicolas Schichan wrote:
> @@ -858,7 +858,7 @@ b_epilogue:
>  }
>  
>  
> -void bpf_jit_compile(struct sk_filter *fp)
> +static void __bpf_jit_compile(struct jit_ctx *out_ctx)
>  {
>         struct jit_ctx ctx;
>         unsigned tmp_idx;
> @@ -867,11 +867,10 @@ void bpf_jit_compile(struct sk_filter *fp)
>         if (!bpf_jit_enable)
>                 return;
>  
> -       memset(&ctx, 0, sizeof(ctx));
> -       ctx.skf         = fp;
> +       ctx = *out_ctx;
>         ctx.ret0_fp_idx = -1;
>  
> -       ctx.offsets = kzalloc(4 * (ctx.skf->len + 1), GFP_KERNEL);
> +       ctx.offsets = kzalloc(4 * (ctx.prog_len + 1), GFP_KERNEL);
>         if (ctx.offsets == NULL)
>                 return;
>  
> @@ -921,13 +920,26 @@ void bpf_jit_compile(struct sk_filter *fp)
>                 print_hex_dump(KERN_INFO, "BPF JIT code: ",
>                                DUMP_PREFIX_ADDRESS, 16, 4, ctx.target,
>                                alloc_size, false);
> -
> -       fp->bpf_func = (void *)ctx.target;
>  out:
>         kfree(ctx.offsets);
> +
> +       *out_ctx = ctx;
>         return;

This part of the patch, in combination with 79617801e "filter: bpf_jit_comp:
refactor and unify BPF JIT image dump output" is now causing build errors
in linux-next:

arch/arm/net/bpf_jit_32.c: In function '__bpf_jit_compile':
arch/arm/net/bpf_jit_32.c:930:16: error: 'fp' undeclared (first use in this function)
   bpf_jit_dump(fp->len, alloc_size, 2, ctx.target);
                ^


	Arnd


From linus.walleij at stericsson.com  Fri Apr 26 10:05:22 2013
From: linus.walleij at stericsson.com (Linus Walleij)
Date: Fri, 26 Apr 2013 16:05:22 +0200
Subject: [PATCH 06/23 v2] ARM: u300: basic device tree support
Message-ID: <1366985122-28479-1-git-send-email-linus.walleij@stericsson.com>

From: Linus Walleij <linus.walleij at linaro.org>

This register the most basic peripherals and makes the
U300 boot to prompt from a device tree.

Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
ChangeLog v1->v2:
- Rename nodes in accordance with review comments from Arnd:
  - timer0 at x -> timer at x
  - gpioN at x -> gpio at x
  - pinctrl0 at x -> pinctrl at x
  - intc at 0xx -> interrupt-controller at x
  - uart at x -> serial at x
---
 Documentation/devicetree/bindings/arm/ste-u300.txt |  9 +++
 arch/arm/boot/dts/Makefile                         |  1 +
 arch/arm/boot/dts/ste-u300.dts                     | 86 ++++++++++++++++++++++
 arch/arm/mach-u300/core.c                          | 80 ++++++++++++++++++++
 4 files changed, 176 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/ste-u300.txt
 create mode 100644 arch/arm/boot/dts/ste-u300.dts

diff --git a/Documentation/devicetree/bindings/arm/ste-u300.txt b/Documentation/devicetree/bindings/arm/ste-u300.txt
new file mode 100644
index 0000000..222dca5
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/ste-u300.txt
@@ -0,0 +1,9 @@
+ST-Ericsson U300 Device Tree Bindings
+
+For various board the "board" node may contain specific properties
+that pertain to this particular board, such as board-specific GPIOs
+or board power regulator supplies.
+
+Required root node property:
+
+compatible="stericsson,u300";
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 9c62558..369fba7 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -165,6 +165,7 @@ dtb-$(CONFIG_ARCH_TEGRA) += tegra20-harmony.dtb \
 	tegra30-cardhu-a04.dtb \
 	tegra114-dalmore.dtb \
 	tegra114-pluto.dtb
+dtb-$(CONFIG_ARCH_U300) += ste-u300.dtb
 dtb-$(CONFIG_ARCH_VEXPRESS) += vexpress-v2p-ca5s.dtb \
 	vexpress-v2p-ca9.dtb \
 	vexpress-v2p-ca15-tc1.dtb \
diff --git a/arch/arm/boot/dts/ste-u300.dts b/arch/arm/boot/dts/ste-u300.dts
new file mode 100644
index 0000000..9e423eb
--- /dev/null
+++ b/arch/arm/boot/dts/ste-u300.dts
@@ -0,0 +1,86 @@
+/*
+ * Device Tree for the ST-Ericsson U300 Machine and SoC
+ */
+
+/dts-v1/;
+/include/ "skeleton.dtsi"
+
+/ {
+	model = "ST-Ericsson U300";
+	compatible = "stericsson,u300";
+	#address-cells = <1>;
+	#size-cells = <1>;
+
+	chosen {
+		bootargs = "root=/dev/ram0 console=ttyAMA0,115200n8 earlyprintk";
+	};
+
+	aliases {
+		serial0 = &uart0;
+		serial1 = &uart1;
+        };
+
+	memory {
+		reg = <0x48000000 0x03c00000>;
+	};
+
+	timer: timer at c0014000 {
+		compatible = "stericsson,u300-apptimer";
+		reg = <0xc0014000 0x1000>;
+		interrupt-parent = <&vica>;
+		interrupts = <24 25 26 27>;
+	};
+
+	gpio: gpio at c0016000 {
+		compatible = "stericsson,gpio-coh901";
+		reg = <0xc0016000 0x1000>;
+		interrupt-parent = <&vicb>;
+		interrupts = <0 1 2 18 21 22 23>;
+		interrupt-names = "gpio0", "gpio1", "gpio2", "gpio3",
+				"gpio4", "gpio5", "gpio6";
+		interrupt-controller;
+		#interrupt-cells = <2>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
+	pinctrl: pinctrl at c0011000 {
+		compatible = "stericsson,pinctrl-u300";
+		reg = <0xc0011000 0x1000>;
+	};
+
+	amba {
+		compatible = "arm,amba-bus";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges;
+
+		vica: interrupt-controller at a0001000 {
+			compatible = "arm,versatile-vic";
+			interrupt-controller;
+			#interrupt-cells = <1>;
+			reg = <0xa0001000 0x20>;
+		};
+
+		vicb: interrupt-controller at a0002000 {
+			compatible = "arm,versatile-vic";
+			interrupt-controller;
+			#interrupt-cells = <1>;
+			reg = <0xa0002000 0x20>;
+		};
+
+		uart0: serial at c0013000 {
+			compatible = "arm,pl011", "arm,primecell";
+			reg = <0xc0013000 0x1000>;
+			interrupt-parent = <&vica>;
+			interrupts = <22>;
+		};
+
+		uart1: serial at c0007000 {
+			compatible = "arm,pl011", "arm,primecell";
+			reg = <0xc0007000 0x1000>;
+			interrupt-parent = <&vicb>;
+			interrupts = <20>;
+		};
+	};
+};
diff --git a/arch/arm/mach-u300/core.c b/arch/arm/mach-u300/core.c
index a683d17..5b42983 100644
--- a/arch/arm/mach-u300/core.c
+++ b/arch/arm/mach-u300/core.c
@@ -33,6 +33,8 @@
 #include <linux/platform_data/pinctrl-coh901.h>
 #include <linux/platform_data/dma-coh901318.h>
 #include <linux/irqchip/arm-vic.h>
+#include <linux/irqchip.h>
+#include <linux/of_platform.h>
 
 #include <asm/types.h>
 #include <asm/setup.h>
@@ -698,3 +700,81 @@ MACHINE_START(U300, "Ericsson AB U335 S335/B335 Prototype Board")
 	.init_machine	= u300_init_machine,
 	.restart	= u300_restart,
 MACHINE_END
+
+#ifdef CONFIG_OF
+
+/* These are mostly to get the right device names for the clock lookups */
+static struct of_dev_auxdata u300_auxdata_lookup[] __initdata = {
+	OF_DEV_AUXDATA("stericsson,pinctrl-u300", U300_SYSCON_BASE,
+		"pinctrl-u300", NULL),
+	OF_DEV_AUXDATA("stericsson,gpio-coh901", U300_GPIO_BASE,
+		"u300-gpio", &u300_gpio_plat),
+	OF_DEV_AUXDATA("arm,primecell", U300_UART0_BASE,
+		"uart0", &uart0_plat_data),
+	OF_DEV_AUXDATA("arm,primecell", U300_UART1_BASE,
+		"uart1", &uart1_plat_data),
+	OF_DEV_AUXDATA("arm,primecell", U300_MMCSD_BASE,
+		"mmci", &mmcsd_platform_data),
+	{ /* sentinel */ },
+};
+
+static void __init u300_init_irq_dt(void)
+{
+	struct clk *clk;
+
+	/* initialize clocking early, we want to clock the INTCON */
+	u300_clk_init(U300_SYSCON_VBASE);
+
+	/* Bootstrap EMIF and SEMI clocks */
+	clk = clk_get_sys("pl172", NULL);
+	BUG_ON(IS_ERR(clk));
+	clk_prepare_enable(clk);
+	clk = clk_get_sys("semi", NULL);
+	BUG_ON(IS_ERR(clk));
+	clk_prepare_enable(clk);
+
+	/* Clock the interrupt controller */
+	clk = clk_get_sys("intcon", NULL);
+	BUG_ON(IS_ERR(clk));
+	clk_prepare_enable(clk);
+
+	irqchip_init();
+}
+
+static void __init u300_init_machine_dt(void)
+{
+	u16 val;
+
+	/* Check what platform we run and print some status information */
+	u300_init_check_chip();
+
+	u300_assign_physmem();
+
+	/* Initialize pinmuxing */
+	pinctrl_register_mappings(u300_pinmux_map,
+				  ARRAY_SIZE(u300_pinmux_map));
+
+	of_platform_populate(NULL, of_default_bus_match_table,
+			u300_auxdata_lookup, NULL);
+
+	/* Enable SEMI self refresh */
+	val = readw(U300_SYSCON_VBASE + U300_SYSCON_SMCR) |
+		U300_SYSCON_SMCR_SEMI_SREFREQ_ENABLE;
+	writew(val, U300_SYSCON_VBASE + U300_SYSCON_SMCR);
+}
+
+static const char * u300_board_compat[] = {
+	"stericsson,u300",
+	NULL,
+};
+
+DT_MACHINE_START(U300_DT, "U300 S335/B335 (Device Tree)")
+	.map_io		= u300_map_io,
+	.init_irq	= u300_init_irq_dt,
+	.init_time	= u300_timer_init,
+	.init_machine	= u300_init_machine_dt,
+	.restart	= u300_restart,
+	.dt_compat      = u300_board_compat,
+MACHINE_END
+
+#endif /* CONFIG_OF */
-- 
1.7.11.3



From sameo at linux.intel.com  Fri Apr 26 10:13:23 2013
From: sameo at linux.intel.com (Samuel Ortiz)
Date: Fri, 26 Apr 2013 16:13:23 +0200
Subject: [PATCH v2] mfd: vexpress: Handle pending config transactions
In-Reply-To: <1366910091-17971-1-git-send-email-pawel.moll@arm.com>
References: <1366821084-12815-1-git-send-email-pawel.moll@arm.com>
 <1366910091-17971-1-git-send-email-pawel.moll@arm.com>
Message-ID: <20130426141323.GA4796@zurbaran>

Hi Pawel,

On Thu, Apr 25, 2013 at 06:14:51PM +0100, Pawel Moll wrote:
> The config transactions "scheduler" was hopelessly broken,
> repeating completed transaction instead of picking up
> next pending one.
> 
> Fixed now. Also improved debug messages.
> 
> Signed-off-by: Pawel Moll <pawel.moll at arm.com>
> ---
>  drivers/mfd/vexpress-config.c |   35 +++++++++++++++++++++--------------
>  1 file changed, 21 insertions(+), 14 deletions(-)
Applied and pushed, thanks.

Cheers,
Samuel.

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


From vincent.guittot at linaro.org  Fri Apr 26 10:23:10 2013
From: vincent.guittot at linaro.org (Vincent Guittot)
Date: Fri, 26 Apr 2013 16:23:10 +0200
Subject: [PATCH 07/14] sched: agressively pack at wake/fork/exec
In-Reply-To: <20130426130835.GA13964@dyad.programming.kicks-ass.net>
References: <1366910611-20048-1-git-send-email-vincent.guittot@linaro.org>
 <1366910611-20048-8-git-send-email-vincent.guittot@linaro.org>
 <20130426130835.GA13964@dyad.programming.kicks-ass.net>
Message-ID: <CAKfTPtCCX+wue+EupB=0firvaA8mZAFpGwtPOb43BUCNKOfJxg@mail.gmail.com>

On 26 April 2013 15:08, Peter Zijlstra <peterz at infradead.org> wrote:
> On Thu, Apr 25, 2013 at 07:23:23PM +0200, Vincent Guittot wrote:
>> According to the packing policy, the scheduler can pack tasks at different
>> step:
>> -SCHED_PACKING_NONE level: we don't pack any task.
>> -SCHED_PACKING_DEFAULT: we only pack small tasks at wake up when system is not
>> busy.
>> -SCHED_PACKING_FULL: we pack tasks at wake up until a CPU becomes full. During
>> a fork or a exec, we assume that the new task is a full running one and we
>> look for an idle CPU close to the buddy CPU.
>
> This changelog is very short on explaining how it will go about achieving these
> goals.

I could move some explanation of the cover letter inside the commit :
 In this case, the CPUs pack their tasks in their buddy until they
becomes full. Unlike
the previous step, we can't keep the same buddy so we update it during load
balance. During the periodic load balance, the scheduler computes the activity
of the system thanks the runnable_avg_sum and the cpu_power of all CPUs and
then it defines the CPUs that will be used to handle the current activity. The
selected CPUs will be their own buddy and will participate to the default
load balancing mecanism in order to share the tasks in a fair way, whereas the
not selected CPUs will not, and their buddy will be the last selected CPU.
The behavior can be summarized as: The scheduler defines how many CPUs are
required to handle the current activity, keeps the tasks on these CPUS and
perform normal load balancing

>
>> Signed-off-by: Vincent Guittot <vincent.guittot at linaro.org>
>> ---
>>  kernel/sched/fair.c |   47 ++++++++++++++++++++++++++++++++++++++++++-----
>>  1 file changed, 42 insertions(+), 5 deletions(-)
>>
>> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
>> index 98166aa..874f330 100644
>> --- a/kernel/sched/fair.c
>> +++ b/kernel/sched/fair.c
>> @@ -3259,13 +3259,16 @@ static struct sched_group *
>>  find_idlest_group(struct sched_domain *sd, struct task_struct *p,
>
>

A task that wakes up will be caught by the function check_pack_buddy
in order to stay in the CPUs that participates to the packing effort.
We will use the find_idlest_group only for fork/exec tasks which are
considered as full running tasks so we looks for the idlest CPU close
to the buddy.

> So for packing into power domains, wouldn't you typically pick the busiest non-
> full domain to fill from other non-full?
>
> Picking the idlest non-full seems like it would generate a ping-pong or not
> actually pack anything.


From lee.jones at linaro.org  Fri Apr 26 10:28:10 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Fri, 26 Apr 2013 15:28:10 +0100
Subject: [PATCH 04/32] dmaengine: ste_dma40: Amalgamate DMA source and
 destination channel numbers
In-Reply-To: <CACRpkdbpbQTCxeQ6cCbAkvvQXJMQUhLv8=qcbBgvBVnMDdysOA@mail.gmail.com>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-5-git-send-email-lee.jones@linaro.org>
 <CACRpkdaauDYTdoBHGG9FO4kKqvCYyCrjY8EGWs5gAQWErGW6_A@mail.gmail.com>
 <20130425090612.GC4623@gmail.com>
 <CACRpkdbV8yEK0470q_-DWv6Q0hAG2wGntXFi5kaLUMgm9b=e-Q@mail.gmail.com>
 <20130425132025.GM4623@gmail.com>
 <CACRpkdbpbQTCxeQ6cCbAkvvQXJMQUhLv8=qcbBgvBVnMDdysOA@mail.gmail.com>
Message-ID: <20130426142810.GD31899@gmail.com>

On Thu, 25 Apr 2013, Linus Walleij wrote:

> On Thu, Apr 25, 2013 at 3:20 PM, Lee Jones <lee.jones at linaro.org> wrote:
> > On Thu, 25 Apr 2013, Linus Walleij wrote:
> 
> >> As we may want to support DEV_TO_DEV at some point.
> >>
> >> Then no longer, and that is not related to $SUBJECT.
> >
> > That's not why I'm removing it. The statement can never be true due to
> > the fact that the second evaluation (src_event_group != dst_event_group)
> > can never be true, which is a direct effect of 'THIS_PATCH'.
> 
> OK that is correct, I'm fine with this then ... as part of that other
> patch dealing with unreacable conditions I keep talking about...

Just looking at this now.

Although I agree that the "dst_event_group == STEDMA40_DEV_DST_MEMORY
(-16)" issue can/should be split out prior, I don't think this
"(src_event_group != dst_event_group)" should be, as it is a direct
result of the code that's being changed in this patch here. It makes
no sense to remove it before this patch, as it's still valid and
removing it afterwards violates your break-now, fix-later stipulation.

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From linus.walleij at stericsson.com  Fri Apr 26 10:33:53 2013
From: linus.walleij at stericsson.com (Linus Walleij)
Date: Fri, 26 Apr 2013 16:33:53 +0200
Subject: [PATCH 09/23 v2] watchdog: coh901327: devicetree support
Message-ID: <1366986833-7158-1-git-send-email-linus.walleij@stericsson.com>

From: Linus Walleij <linus.walleij at linaro.org>

This adds support for probing the COH 901 327 watchdog from
the device tree and also adds associated bindings.

Cc: Wim Van Sebroeck <wim at iguana.be>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
ChangeLog v1->v2: augment driver to call watchdog_init_timeout()
 so we can also set the timeout from the device tree, as per
 suggestion from Guenter Roeck.

Hi Wim, I'm seeking an ACK on this patch to take it into
ARM SoC along with the patches making use of this new
binding.
---
 .../bindings/watchdog/stericsson-coh901327.txt        | 19 +++++++++++++++++++
 drivers/watchdog/coh901327_wdt.c                      | 12 +++++++++---
 2 files changed, 28 insertions(+), 3 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/watchdog/stericsson-coh901327.txt

diff --git a/Documentation/devicetree/bindings/watchdog/stericsson-coh901327.txt b/Documentation/devicetree/bindings/watchdog/stericsson-coh901327.txt
new file mode 100644
index 0000000..8ffb88e
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/stericsson-coh901327.txt
@@ -0,0 +1,19 @@
+ST-Ericsson COH 901 327 Watchdog timer
+
+Required properties:
+- compatible: must be "stericsson,coh901327".
+- reg: physical base address of the controller and length of memory mapped
+  region.
+- interrupts: the interrupt used for the watchdog timeout warning.
+
+Optional properties:
+- timeout-sec: contains the watchdog timeout in seconds.
+
+Example:
+
+watchdog: watchdog at c0012000 {
+	compatible = "stericsson,coh901327";
+	reg = <0xc0012000 0x1000>;
+	interrupts = <3>;
+	timeout-sec = <60>;
+};
diff --git a/drivers/watchdog/coh901327_wdt.c b/drivers/watchdog/coh901327_wdt.c
index b9b8a8b..4bd070f 100644
--- a/drivers/watchdog/coh901327_wdt.c
+++ b/drivers/watchdog/coh901327_wdt.c
@@ -354,9 +354,9 @@ static int __init coh901327_probe(struct platform_device *pdev)
 
 	clk_disable(clk);
 
-	if (margin < 1 || margin > 327)
-		margin = 60;
-	coh901327_wdt.timeout = margin;
+	ret = watchdog_init_timeout(&coh901327_wdt, margin, &pdev->dev);
+	if (ret < 0)
+		coh901327_wdt.timeout = 60;
 
 	ret = watchdog_register_device(&coh901327_wdt);
 	if (ret == 0)
@@ -441,10 +441,16 @@ void coh901327_watchdog_reset(void)
 	/* Return and await doom */
 }
 
+static const struct of_device_id coh901327_dt_match[] = {
+	{ .compatible = "stericsson,coh901327" },
+	{},
+};
+
 static struct platform_driver coh901327_driver = {
 	.driver = {
 		.owner	= THIS_MODULE,
 		.name	= "coh901327_wdog",
+		.of_match_table = coh901327_dt_match,
 	},
 	.remove		= __exit_p(coh901327_remove),
 	.suspend	= coh901327_suspend,
-- 
1.7.11.3



From arnd at arndb.de  Fri Apr 26 10:43:32 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 26 Apr 2013 16:43:32 +0200
Subject: [PATCH v2] pinctrl: move subsystem mutex to pinctrl_dev struct
In-Reply-To: <1366794119-766-1-git-send-email-linus.walleij@stericsson.com>
References: <1366794119-766-1-git-send-email-linus.walleij@stericsson.com>
Message-ID: <2852417.oyEN2DhaoE@wuerfel>

On Wednesday 24 April 2013 11:01:59 Linus Walleij wrote:
>  /**
> - * pinctrl_lookup_state() - retrieves a state handle from a pinctrl handle
> - * @p: the pinctrl handle to retrieve the state from
> - * @name: the state name to retrieve
> + * pinctrl_select_state() - select/activate/program a pinctrl state to HW
> + * @p: the pinctrl handle for the device that requests configuration
> + * @state: the state handle to select/activate/program
>   */
> -struct pinctrl_state *pinctrl_lookup_state(struct pinctrl *p, const char *name)
> -{
> -       struct pinctrl_state *s;
> -
> -       mutex_lock(&pinctrl_mutex);
> -       s = pinctrl_lookup_state_locked(p, name);
> -       mutex_unlock(&pinctrl_mutex);
> -
> -       return s;
> -}
> -EXPORT_SYMBOL_GPL(pinctrl_lookup_state);
> -
> -static int pinctrl_select_state_locked(struct pinctrl *p,
> -                                      struct pinctrl_state *state)
> +int pinctrl_select_state(struct pinctrl *p, struct pinctrl_state *state)
>  {
>         struct p


This showed up in linux-next and broke a lot of driver modules, since you
remove the EXPORT_SYMBOL_GPL(pinctrl_lookup_state) line.

	Arnd


From vincent.guittot at linaro.org  Fri Apr 26 10:52:50 2013
From: vincent.guittot at linaro.org (Vincent Guittot)
Date: Fri, 26 Apr 2013 16:52:50 +0200
Subject: [PATCH 08/14] sched: trig ILB on an idle buddy
In-Reply-To: <20130426131532.GB13964@dyad.programming.kicks-ass.net>
References: <1366910611-20048-1-git-send-email-vincent.guittot@linaro.org>
 <1366910611-20048-9-git-send-email-vincent.guittot@linaro.org>
 <20130426131532.GB13964@dyad.programming.kicks-ass.net>
Message-ID: <CAKfTPtCJzoYNEDu4WJWs0LraL59r8ZDuavBv9rypRKJiX4ZL7g@mail.gmail.com>

On 26 April 2013 15:15, Peter Zijlstra <peterz at infradead.org> wrote:
> On Thu, Apr 25, 2013 at 07:23:24PM +0200, Vincent Guittot wrote:
>> If the buddy CPU is not full and currently idle, we trigger an Idle Load
>> Balance to give it the opportunity to pull more tasks.
>>
>> Signed-off-by: Vincent Guittot <vincent.guittot at linaro.org>
>> ---
>>  kernel/sched/fair.c |   24 ++++++++++++++++++++++++
>>  1 file changed, 24 insertions(+)
>>
>> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
>> index 874f330..954adfd 100644
>> --- a/kernel/sched/fair.c
>> +++ b/kernel/sched/fair.c
>> @@ -5776,6 +5776,26 @@ end:
>>       clear_bit(NOHZ_BALANCE_KICK, nohz_flags(this_cpu));
>>  }
>>
>> +static int check_nohz_buddy(int cpu)
>> +{
>> +     int buddy = per_cpu(sd_pack_buddy, cpu);
>> +
>> +     if (sysctl_sched_packing_mode != SCHED_PACKING_FULL)
>> +             return false;
>> +
>> +     /* No pack buddy for this CPU */
>> +     if (buddy == -1)
>> +             return false;
>> +
>> +     if (is_buddy_full(buddy))
>> +             return false;
>> +
>> +     if (cpumask_test_cpu(buddy, nohz.idle_cpus_mask))
>> +             return true;
>> +
>> +     return false;
>
> return cpumask_test_cpu(..); ?

right

>
>> +}
>> +
>>  /*
>>   * Current heuristic for kicking the idle load balancer in the presence
>>   * of an idle cpu is the system.
>> @@ -5813,6 +5833,10 @@ static inline int nohz_kick_needed(struct rq *rq, int cpu)
>>       if (rq->nr_running >= 2)
>>               goto need_kick;
>>
>> +     /* the buddy is idle and not busy so we can pack */
>> +     if (check_nohz_buddy(cpu))
>> +             goto need_kick;
>> +
>>       rcu_read_lock();
>>       for_each_domain(cpu, sd) {
>>               struct sched_group *sg = sd->groups;
>
> Bah.. this code is so confusing.. nohz_balance_kick(cpu) won't actually kick
> @cpu.
>
> Again.. suppose we're a big cpu (2) and our little buddy cpu (0) is busy, we
> miss an opportunity to kick the other little cpu into gear (1) and maybe take
> the big core out.

You're right that we can miss an opportunity but it means that cpus
allocated to packing effort are full and a new buddy cpu is going to
be allocated and will pull the task a bit later.


>
>


From anup at brainfault.org  Fri Apr 26 10:48:54 2013
From: anup at brainfault.org (Anup Patel)
Date: Fri, 26 Apr 2013 20:18:54 +0530
Subject: [PATCH V3] ARM: KVM: Allow host virtual timer irq number to be
 different from guest virtual timer irq number
In-Reply-To: <517A8560.6070005@arm.com>
References: <1366982847-11028-1-git-send-email-anup.patel@linaro.org>
 <517A8560.6070005@arm.com>
Message-ID: <CAAhSdy3XVRVp62xeuPp6Dum1OwvgmF1UKqwTqABUp71WS7ronw@mail.gmail.com>

On Fri, Apr 26, 2013 at 7:17 PM, Marc Zyngier <marc.zyngier at arm.com> wrote:
> On 26/04/13 14:27, Anup Patel wrote:
>> The arch_timer irq numbers (or PPI number) are implementation dependent so, the host virtual timer irq number can be different from guest virtual timer irq number.
>>
>> This patch ensures that host virtual timer irq number is read from DTB and guest virtual timer irq is determined based on guest vcpu target type.
>>
>> Signed-off-by: Anup Patel <anup.patel at linaro.org>
>> Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar at linaro.org>
>> ---
>>  arch/arm/include/asm/kvm_arch_timer.h |    7 +++++++
>>  arch/arm/include/asm/kvm_host.h       |    1 +
>>  arch/arm/kvm/arch_timer.c             |   32 +++++++++++++++++++++++++-------
>>  arch/arm/kvm/guest.c                  |   15 +++++++++++++++
>>  arch/arm/kvm/reset.c                  |    4 +++-
>>  5 files changed, 51 insertions(+), 8 deletions(-)
>>
>> diff --git a/arch/arm/include/asm/kvm_arch_timer.h b/arch/arm/include/asm/kvm_arch_timer.h
>> index 68cb9e1..c5c135b 100644
>> --- a/arch/arm/include/asm/kvm_arch_timer.h
>> +++ b/arch/arm/include/asm/kvm_arch_timer.h
>> @@ -61,6 +61,7 @@ struct arch_timer_cpu {
>>  #ifdef CONFIG_KVM_ARM_TIMER
>>  int kvm_timer_hyp_init(void);
>>  int kvm_timer_init(struct kvm *kvm);
>> +int kvm_timer_vcpu_reset(struct kvm_vcpu *vcpu);
>>  void kvm_timer_vcpu_init(struct kvm_vcpu *vcpu);
>>  void kvm_timer_flush_hwstate(struct kvm_vcpu *vcpu);
>>  void kvm_timer_sync_hwstate(struct kvm_vcpu *vcpu);
>> @@ -76,7 +77,13 @@ static inline int kvm_timer_init(struct kvm *kvm)
>>       return 0;
>>  }
>>
>> +static int kvm_timer_vcpu_reset(struct kvm_vcpu *vcpu)
>> +{
>> +     return 0;
>> +}
>> +
>>  static inline void kvm_timer_vcpu_init(struct kvm_vcpu *vcpu) {}
>> +
>>  static inline void kvm_timer_flush_hwstate(struct kvm_vcpu *vcpu) {}
>>  static inline void kvm_timer_sync_hwstate(struct kvm_vcpu *vcpu) {}
>>  static inline void kvm_timer_vcpu_terminate(struct kvm_vcpu *vcpu) {}
>> diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
>> index 57cb786..cdc0551 100644
>> --- a/arch/arm/include/asm/kvm_host.h
>> +++ b/arch/arm/include/asm/kvm_host.h
>> @@ -43,6 +43,7 @@
>>  struct kvm_vcpu;
>>  u32 *kvm_vcpu_reg(struct kvm_vcpu *vcpu, u8 reg_num, u32 mode);
>>  int kvm_target_cpu(void);
>> +struct kvm_irq_level *kvm_target_timer_irq(struct kvm_vcpu *vcpu);
>>  int kvm_reset_vcpu(struct kvm_vcpu *vcpu);
>>  void kvm_reset_coprocs(struct kvm_vcpu *vcpu);
>>
>> diff --git a/arch/arm/kvm/arch_timer.c b/arch/arm/kvm/arch_timer.c
>> index 49a7516..e558115 100644
>> --- a/arch/arm/kvm/arch_timer.c
>> +++ b/arch/arm/kvm/arch_timer.c
>> @@ -30,7 +30,7 @@
>>
>>  static struct timecounter *timecounter;
>>  static struct workqueue_struct *wqueue;
>> -static struct kvm_irq_level timer_irq = {
>> +static struct kvm_irq_level host_timer_irq = {
>>       .level  = 1,
>>  };
>>
>> @@ -67,8 +67,8 @@ static void kvm_timer_inject_irq(struct kvm_vcpu *vcpu)
>>
>>       timer->cntv_ctl |= ARCH_TIMER_CTRL_IT_MASK;
>>       kvm_vgic_inject_irq(vcpu->kvm, vcpu->vcpu_id,
>> -                         vcpu->arch.timer_cpu.irq->irq,
>> -                         vcpu->arch.timer_cpu.irq->level);
>> +                         timer->irq->irq,
>> +                         timer->irq->level);
>>  }
>>
>>  static irqreturn_t kvm_arch_timer_handler(int irq, void *dev_id)
>> @@ -156,6 +156,24 @@ void kvm_timer_sync_hwstate(struct kvm_vcpu *vcpu)
>>       timer_arm(timer, ns);
>>  }
>>
>> +int kvm_timer_vcpu_reset(struct kvm_vcpu *vcpu)
>
> If you change this function to:
> int kvm_timer_vcpu_reset(struct kvm_vcpu *vcpu, struct kvm_irq_level *irq)
>
> ...
>
>> +{
>> +     struct arch_timer_cpu *timer = &vcpu->arch.timer_cpu;
>> +
>> +     /*
>> +      * The vcpu timer irq number cannot be determined in
>> +      * kvm_timer_vcpu_init() because it is called much before
>> +      * kvm_vcpu_set_target(). To handle this, we determine
>> +      * vcpu timer irq number when the vcpu is resetted.
>> +      */
>> +     timer->irq = kvm_target_timer_irq(vcpu);
>> +     if (!timer->irq) {
>> +             return -ENODEV;
>> +     }
>> +
>> +     return 0;
>> +}
>> +
>>  void kvm_timer_vcpu_init(struct kvm_vcpu *vcpu)
>>  {
>>       struct arch_timer_cpu *timer = &vcpu->arch.timer_cpu;
>> @@ -163,12 +181,12 @@ void kvm_timer_vcpu_init(struct kvm_vcpu *vcpu)
>>       INIT_WORK(&timer->expired, kvm_timer_inject_irq_work);
>>       hrtimer_init(&timer->timer, CLOCK_MONOTONIC, HRTIMER_MODE_ABS);
>>       timer->timer.function = kvm_timer_expire;
>> -     timer->irq = &timer_irq;
>> +     timer->irq = NULL;
>>  }
>>
>>  static void kvm_timer_init_interrupt(void *info)
>>  {
>> -     enable_percpu_irq(timer_irq.irq, 0);
>> +     enable_percpu_irq(host_timer_irq.irq, 0);
>>  }
>>
>>
>> @@ -182,7 +200,7 @@ static int kvm_timer_cpu_notify(struct notifier_block *self,
>>               break;
>>       case CPU_DYING:
>>       case CPU_DYING_FROZEN:
>> -             disable_percpu_irq(timer_irq.irq);
>> +             disable_percpu_irq(host_timer_irq.irq);
>>               break;
>>       }
>>
>> @@ -230,7 +248,7 @@ int kvm_timer_hyp_init(void)
>>               goto out;
>>       }
>>
>> -     timer_irq.irq = ppi;
>> +     host_timer_irq.irq = ppi;
>>
>>       err = register_cpu_notifier(&kvm_timer_cpu_nb);
>>       if (err) {
>> diff --git a/arch/arm/kvm/guest.c b/arch/arm/kvm/guest.c
>> index 152d036..6fbc988 100644
>> --- a/arch/arm/kvm/guest.c
>> +++ b/arch/arm/kvm/guest.c
>> @@ -36,6 +36,11 @@ struct kvm_stats_debugfs_item debugfs_entries[] = {
>>       { NULL }
>>  };
>>
>> +static struct kvm_irq_level target_cortex_a15_timer_irq = {
>> +     .irq = 27,
>> +     .level = 1,
>> +};
>
> ... Move this to reset.c ...
>
>>  int kvm_arch_vcpu_setup(struct kvm_vcpu *vcpu)
>>  {
>>       return 0;
>> @@ -197,6 +202,16 @@ int __attribute_const__ kvm_target_cpu(void)
>>       }
>>  }
>>
>> +struct kvm_irq_level *kvm_target_timer_irq(struct kvm_vcpu *vcpu)
>> +{
>> +     switch (vcpu->arch.target) {
>> +     case KVM_ARM_TARGET_CORTEX_A15:
>> +             return &target_cortex_a15_timer_irq;
>> +     default:
>> +             return NULL;
>> +     };
>> +}
>
> ... drop this ...
>
>>  int kvm_vcpu_set_target(struct kvm_vcpu *vcpu,
>>                       const struct kvm_vcpu_init *init)
>>  {
>> diff --git a/arch/arm/kvm/reset.c b/arch/arm/kvm/reset.c
>> index b80256b..655e567 100644
>> --- a/arch/arm/kvm/reset.c
>> +++ b/arch/arm/kvm/reset.c
>> @@ -26,6 +26,7 @@
>>  #include <asm/cputype.h>
>>  #include <asm/kvm_arm.h>
>>  #include <asm/kvm_coproc.h>
>> +#include <asm/kvm_arch_timer.h>
>>
>>  /******************************************************************************
>>   * Cortex-A15 Reset Values
>> @@ -70,5 +71,6 @@ int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
>
> ...
>
> In      case KVM_ARM_TARGET_CORTEX_A15:
> [...]
>         timer_irq = &target_cortex_a15_timer_irq;
>
> ...
>
>>       /* Reset CP15 registers */
>>       kvm_reset_coprocs(vcpu);
>>
>> -     return 0;
>> +     /* Reset arch_timer context */
>> +     return kvm_timer_vcpu_reset(vcpu);
>
> ... and call kvm_timer_vcpu_reset(vcpu, timer_irq)
>
> it would look much better.
>
>         M.
> --
> Jazz is not dead. It just smells funny...
>
>
> _______________________________________________
> kvmarm mailing list
> kvmarm at lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm

Sure, I incorporate all above comments and send revised patch.

Regards,
Anup


From linus.walleij at linaro.org  Fri Apr 26 10:59:37 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Fri, 26 Apr 2013 16:59:37 +0200
Subject: [PATCH v2] pinctrl: move subsystem mutex to pinctrl_dev struct
In-Reply-To: <2852417.oyEN2DhaoE@wuerfel>
References: <1366794119-766-1-git-send-email-linus.walleij@stericsson.com>
 <2852417.oyEN2DhaoE@wuerfel>
Message-ID: <CACRpkdb0XgSB7bCxZUhNyTW6KmcQzqz5KMRbnMzYfQ5HSmRzBw@mail.gmail.com>

On Fri, Apr 26, 2013 at 4:43 PM, Arnd Bergmann <arnd at arndb.de> wrote:
> On Wednesday 24 April 2013 11:01:59 Linus Walleij wrote:
>>  /**
>> - * pinctrl_lookup_state() - retrieves a state handle from a pinctrl handle
>> - * @p: the pinctrl handle to retrieve the state from
>> - * @name: the state name to retrieve
>> + * pinctrl_select_state() - select/activate/program a pinctrl state to HW
>> + * @p: the pinctrl handle for the device that requests configuration
>> + * @state: the state handle to select/activate/program
>>   */
>> -struct pinctrl_state *pinctrl_lookup_state(struct pinctrl *p, const char *name)
>> -{
>> -       struct pinctrl_state *s;
>> -
>> -       mutex_lock(&pinctrl_mutex);
>> -       s = pinctrl_lookup_state_locked(p, name);
>> -       mutex_unlock(&pinctrl_mutex);
>> -
>> -       return s;
>> -}
>> -EXPORT_SYMBOL_GPL(pinctrl_lookup_state);
>> -
>> -static int pinctrl_select_state_locked(struct pinctrl *p,
>> -                                      struct pinctrl_state *state)
>> +int pinctrl_select_state(struct pinctrl *p, struct pinctrl_state *state)
>>  {
>>         struct p
>
>
> This showed up in linux-next and broke a lot of driver modules, since you
> remove the EXPORT_SYMBOL_GPL(pinctrl_lookup_state) line.

No that one is just moved ... I think you're seeing that
pinctrl_select_state() has lost its export. I'll fix this up
and send a v3.

Yours,
Linus Walleij


From arjan at linux.intel.com  Fri Apr 26 11:00:43 2013
From: arjan at linux.intel.com (Arjan van de Ven)
Date: Fri, 26 Apr 2013 08:00:43 -0700
Subject: [RFC PATCH v4 00/14] sched: packing small tasks
In-Reply-To: <1366910611-20048-1-git-send-email-vincent.guittot@linaro.org>
References: <1366910611-20048-1-git-send-email-vincent.guittot@linaro.org>
Message-ID: <517A969B.5040606@linux.intel.com>

On 4/25/2013 10:23 AM, Vincent Guittot wrote:
> Hi,
>
> This patchset takes advantage of the new per-task load tracking that is
> available in the kernel for packing the tasks in as few as possible
> CPU/Cluster/Core. It has got 2 packing modes:
> -The 1st mode packs the small tasks when the system is not too busy. The main
> goal is to reduce the power consumption in the low system load use cases by
> minimizing the number of power domain that are enabled but it also keeps the
> default behavior which is performance oriented.
> -The 2nd mode packs all tasks in as few as possible power domains in order to
> improve the power consumption of the system but at the cost of possible
> performance decrease because of the increase of the rate of ressources sharing
> compared to the default mode.


so I got to ask the hard question; what percentage of system level (not just cpu level)
power consumption gain can you measure (pick your favorite workload)...

on x86 (even on the low power stuff) I expect this to be very far into the noise
(since we have per core power gates, and power transitions are pretty fast)

you have some numbers in the back of your mail, but it's hard for me to get a conclusion out of
that (they either measure only cpu power, or are just vague in general)




From arnd at arndb.de  Fri Apr 26 11:03:17 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 26 Apr 2013 17:03:17 +0200
Subject: [PATCH 0/2] Early printk support for virtio console devices.
In-Reply-To: <CALrVBkuyby_KY_M+yp0e=PLk=7_W_kSxxm62YYSwwp8rwLsCAQ@mail.gmail.com>
References: <1366974299-17877-1-git-send-email-pranavkumar@linaro.org>
 <1577576.O1Cm2pf5KD@wuerfel>
 <CALrVBkuyby_KY_M+yp0e=PLk=7_W_kSxxm62YYSwwp8rwLsCAQ@mail.gmail.com>
Message-ID: <201304261703.17798.arnd@arndb.de>

On Friday 26 April 2013, Anup Patel wrote:
> I am curious about how smh-based or hypercall-based early prints would
> be handled in following scenario:
> 
> "A board is running KVM ARM enabled kernel and linux console on serial
> port. Now a user remotely connects to the board via telnet/ssh and
> launches a VM with smh-based or hypercall-based earlyprintk."
> 
> In the above scenario, will smh-based or hypercall-based earlyprints
> appear to user on remote shell or not ?

The implementation of the console device would still be done by KVM,
as for any other virtual device, so it shows up whereever kvm is
configured to output the console data.

	Arnd


From linus.walleij at linaro.org  Fri Apr 26 11:04:23 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Fri, 26 Apr 2013 17:04:23 +0200
Subject: [PATCH 03/32 v4] dmaengine: ste_dma40: Use the BIT macro to
 replace ugly '(1 << x)'s
In-Reply-To: <20130426113947.GB31899@gmail.com>
References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org>
 <1366279934-30761-4-git-send-email-lee.jones@linaro.org>
 <20130426113947.GB31899@gmail.com>
Message-ID: <CACRpkdbK+GKMEekKk_bh5oK7NJHMMyQNbgac-D3RKYrg-unwQQ@mail.gmail.com>

On Fri, Apr 26, 2013 at 1:39 PM, Lee Jones <lee.jones at linaro.org> wrote:

> The aim is to make the code that little more readable.
>
> Acked-by: Vinod Koul <vnod.koul at intel.com>
> Acked-by: Arnd Bergmann <arnd at arndb.de>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>

Fine with me:
Reviewed-by: Linus Walleij <linus.walleij at linaro.org>

Yours,
Linus Walleij


From anup at brainfault.org  Fri Apr 26 11:06:12 2013
From: anup at brainfault.org (Anup Patel)
Date: Fri, 26 Apr 2013 20:36:12 +0530
Subject: [PATCH] arm64: KVM: Add kvm_target_timer_irq() for arch_timer
In-Reply-To: <517A85D5.1050704@arm.com>
References: <1366983136-11147-1-git-send-email-anup.patel@linaro.org>
 <517A85D5.1050704@arm.com>
Message-ID: <CAAhSdy26nCdt9X0iCEjfv+9EX2-HNCJNqHVUtSuL5mxJovtHWA@mail.gmail.com>

On Fri, Apr 26, 2013 at 7:19 PM, Marc Zyngier <marc.zyngier at arm.com> wrote:
> On 26/04/13 14:32, Anup Patel wrote:
>> This patch adds kvm_target_timer_irq() for KVM ARM64 which determines guest virtual timer ppi number based on vcpu target type.
>>
>> The patch also updates kvm_vcpu_reset() so that arch_timer is resetted on every vcpu reset.
>>
>> Signed-off-by: Anup Patel <anup.patel at linaro.org>
>> Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar at linaro.org>
>
> Same remarks as the 32bit version, plus...

Sure, I incorporate previous comments here too.

>
>> ---
>>  arch/arm64/include/asm/kvm_host.h |    1 +
>>  arch/arm64/kvm/guest.c            |   17 +++++++++++++++++
>>  arch/arm64/kvm/reset.c            |   13 +++++++++++++
>>  3 files changed, 31 insertions(+)
>>
>> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
>> index 77eec44..23e185d 100644
>> --- a/arch/arm64/include/asm/kvm_host.h
>> +++ b/arch/arm64/include/asm/kvm_host.h
>> @@ -43,6 +43,7 @@
>>
>>  struct kvm_vcpu;
>>  int kvm_target_cpu(void);
>> +struct kvm_irq_level *kvm_target_timer_irq(struct kvm_vcpu *vcpu);
>>  int kvm_reset_vcpu(struct kvm_vcpu *vcpu);
>>  int kvm_arch_dev_ioctl_check_extension(long ext);
>>
>> diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
>> index 8dc349b..ac9ec08 100644
>> --- a/arch/arm64/kvm/guest.c
>> +++ b/arch/arm64/kvm/guest.c
>> @@ -36,6 +36,11 @@ struct kvm_stats_debugfs_item debugfs_entries[] = {
>>       { NULL }
>>  };
>>
>> +static struct kvm_irq_level target_cortex_a57_timer_irq = {
>> +     .irq = 27,
>> +     .level = 1,
>> +};
>> +
>>  int kvm_arch_vcpu_setup(struct kvm_vcpu *vcpu)
>>  {
>>       vcpu->arch.hcr_el2 = HCR_GUEST_FLAGS;
>> @@ -224,6 +229,18 @@ int __attribute_const__ kvm_target_cpu(void)
>>       }
>>  }
>>
>> +struct kvm_irq_level *kvm_target_timer_irq(struct kvm_vcpu *vcpu)
>> +{
>> +     switch (vcpu->arch.target) {
>> +     case KVM_ARM_TARGET_AEM_V8:
>> +     case KVM_ARM_TARGET_FOUNDATION_V8:
>> +     case KVM_ARM_TARGET_CORTEX_A57:
>> +             return &target_cortex_a57_timer_irq;
>> +     default:
>> +             return NULL;
>> +     };
>> +}
>> +
>>  int kvm_vcpu_set_target(struct kvm_vcpu *vcpu,
>>                       const struct kvm_vcpu_init *init)
>>  {
>> diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
>> index 64e0740..45f1f10 100644
>> --- a/arch/arm64/kvm/reset.c
>> +++ b/arch/arm64/kvm/reset.c
>> @@ -28,6 +28,14 @@
>>  #include <asm/kvm_arm.h>
>>  #include <asm/kvm_coproc.h>
>>
>> +#ifdef CONFIG_KVM_ARM_TIMER
>
> arm64 mandates the architected timers, so no need to #ifdef anything.

Ok, will remove this #if

>
>> +/*
>> + * We cannont directly include arm/include/asm/kvm_arch_timer.h here so,
>
> What's wrong with arch/arm64/include/asm/kvm_arch_timer.h???
>

Actually, I was getting "undefined kvm_timer_vcpu_reset()" error by
including asm/kvm_arch_timer.h
I really thought asm/kvm_arch_timer.h is shared by KVM ARM32 and KVM ARM64.

I will again try including asm/kvm_arch_timer.h in reset.c

>> + * forward declaring required functions
>> + */
>> +extern int kvm_timer_vcpu_reset(struct kvm_vcpu *vcpu);
>> +#endif
>> +
>>  /*
>>   * ARMv8 Reset Values
>>   */
>> @@ -95,5 +103,10 @@ int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
>>       /* Reset system registers */
>>       kvm_reset_sys_regs(vcpu);
>>
>> +#ifdef CONFIG_KVM_ARM_TIMER
>> +     /* Reset arch_timer context */
>> +     return kvm_timer_vcpu_reset(vcpu);
>> +#else
>>       return 0;
>> +#endif
>>  }
>>
>
>
> --
> Jazz is not dead. It just smells funny...
>
>
> _______________________________________________
> kvmarm mailing list
> kvmarm at lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm

--Anup


From linux at roeck-us.net  Fri Apr 26 11:07:44 2013
From: linux at roeck-us.net (Guenter Roeck)
Date: Fri, 26 Apr 2013 08:07:44 -0700
Subject: [PATCH 09/23 v2] watchdog: coh901327: devicetree support
In-Reply-To: <1366986833-7158-1-git-send-email-linus.walleij@stericsson.com>
References: <1366986833-7158-1-git-send-email-linus.walleij@stericsson.com>
Message-ID: <20130426150744.GA26389@roeck-us.net>

On Fri, Apr 26, 2013 at 04:33:53PM +0200, Linus Walleij wrote:
> From: Linus Walleij <linus.walleij at linaro.org>
> 
> This adds support for probing the COH 901 327 watchdog from
> the device tree and also adds associated bindings.
> 
> Cc: Wim Van Sebroeck <wim at iguana.be>
> Signed-off-by: Linus Walleij <linus.walleij at linaro.org>

Reviewed-by: Guenter Roeck <linux at roeck-us.net>


From arnd at arndb.de  Fri Apr 26 11:07:57 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 26 Apr 2013 17:07:57 +0200
Subject: [PATCH 01/21] ARM: topology: export cpu_topology
In-Reply-To: <20130426085333.GA30284@mudshark.cambridge.arm.com>
References: <1366910944-3033663-1-git-send-email-arnd@arndb.de>
 <1366910944-3033663-2-git-send-email-arnd@arndb.de>
 <20130426085333.GA30284@mudshark.cambridge.arm.com>
Message-ID: <201304261707.57328.arnd@arndb.de>

On Friday 26 April 2013, Will Deacon wrote:
> On Thu, Apr 25, 2013 at 06:28:44PM +0100, Arnd Bergmann wrote:
> > The cpu_topology symbol is required by any driver using the topology
> > interfaces, which leads to a couple of build errors:
> > 
> > ERROR: "cpu_topology" [drivers/net/ethernet/sfc/sfc.ko] undefined!
> > ERROR: "cpu_topology" [drivers/cpufreq/arm_big_little.ko] undefined!
> 
> Are these first two in mainline?

I think they are both newly added in linux-next.

	Arnd


From linus.walleij at stericsson.com  Fri Apr 26 11:08:27 2013
From: linus.walleij at stericsson.com (Linus Walleij)
Date: Fri, 26 Apr 2013 17:08:27 +0200
Subject: [PATCH v3] pinctrl: move subsystem mutex to pinctrl_dev struct
Message-ID: <1366988907-13485-1-git-send-email-linus.walleij@stericsson.com>

From: Patrice Chotard <patrice.chotard at st.com>

This mutex avoids deadlock in case of use of multiple pin
controllers. Before this modification, by using a global
mutex, deadlock appeared when, for example, a call to
pinctrl_pins_show() locked the pinctrl_mutex, called the
ops->pin_dbg_show of a particular pin controller. If this
pin controller needs I2C access to retrieve configuration
information and I2C driver is using pinctrl to drive its
pins, a call to pinctrl_select_state() try to lock again
pinctrl_mutex which leads to a deadlock.

Notice that the mutex grab from the two direction functions
was moved into pinctrl_gpio_direction().

For several cases, we can't replace pinctrl_mutex by
pctldev->mutex, because at this stage, pctldev is
not accessible :
	- pinctrl_get()/pinctrl_put()
	- pinctrl_register_maps()

So add respectively pinctrl_list_mutex and
pinctrl_maps_mutex in order to protect
pinctrl_list and pinctrl_maps list instead.

Reintroduce pinctrldev_list_mutex in
find_pinctrl_by_of_node(),
pinctrl_find_and_add_gpio_range()
pinctrl_request_gpio(), pinctrl_free_gpio(),
pinctrl_gpio_direction(), pinctrl_devices_show(),
pinctrl_register() and pinctrl_unregister() to
protect pinctrldev_list.

Changes v2->v3:
- Fix a missing EXPORT_SYMBOL_GPL() for pinctrl_select_state().

Changes v1->v2:
- pinctrl_select_state_locked() is removed, all lock mechanism
  is located inside pinctrl_select_state(). When parsing
  the state->setting list, take the per-pin-controller driver
  lock. (Patrice).
- Introduce pinctrldev_list_mutex to protect pinctrldev_list
  in all functions which parse or modify pictrldev_list.
  (Patrice).
- move find_pinctrl_by_of_node() from pinctrl/devicetree.c to
  pinctrl/core.c in order to protect pinctrldev_list.
  (Patrice).
- Sink mutex:es into some functions and remove some _locked
  variants down to where the lists are actually accessed to
  make things simpler. (Linus)
- Drop *all* mutexes completely from pinctrl_lookup_state()
  and pinctrl_select_state() - no relevant mutex was taken
  and it was unclear what this was protecting against. (Linus)

Reported by : Seraphin Bonnaffe <seraphin.bonnaffe at stericsson.com>
Signed-off-by: Patrice Chotard <patrice.chotard at st.com>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 drivers/pinctrl/core.c       | 265 +++++++++++++++++++++++--------------------
 drivers/pinctrl/core.h       |   6 +-
 drivers/pinctrl/devicetree.c |  15 +--
 drivers/pinctrl/pinconf.c    |  46 ++++----
 drivers/pinctrl/pinmux.c     |   8 +-
 5 files changed, 176 insertions(+), 164 deletions(-)

diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
index 8b832ce..c3d222e 100644
--- a/drivers/pinctrl/core.c
+++ b/drivers/pinctrl/core.c
@@ -40,11 +40,17 @@
 
 static bool pinctrl_dummy_state;
 
-/* Mutex taken by all entry points */
-DEFINE_MUTEX(pinctrl_mutex);
+/* Mutex taken to protect pinctrl_list */
+DEFINE_MUTEX(pinctrl_list_mutex);
+
+/* Mutex taken to protect pinctrl_maps */
+DEFINE_MUTEX(pinctrl_maps_mutex);
+
+/* Mutex taken to protect pinctrldev_list */
+DEFINE_MUTEX(pinctrldev_list_mutex);
 
 /* Global list of pin control devices (struct pinctrl_dev) */
-LIST_HEAD(pinctrldev_list);
+static LIST_HEAD(pinctrldev_list);
 
 /* List of pin controller handles (struct pinctrl) */
 static LIST_HEAD(pinctrl_list);
@@ -111,6 +117,23 @@ struct pinctrl_dev *get_pinctrl_dev_from_devname(const char *devname)
 	return found ? pctldev : NULL;
 }
 
+struct pinctrl_dev *get_pinctrl_dev_from_of_node(struct device_node *np)
+{
+	struct pinctrl_dev *pctldev;
+
+	mutex_lock(&pinctrldev_list_mutex);
+
+	list_for_each_entry(pctldev, &pinctrldev_list, node)
+		if (pctldev->dev->of_node == np) {
+			mutex_unlock(&pinctrldev_list_mutex);
+			return pctldev;
+		}
+
+	mutex_lock(&pinctrldev_list_mutex);
+
+	return NULL;
+}
+
 /**
  * pin_get_from_name() - look up a pin number from a name
  * @pctldev: the pin control device to lookup the pin on
@@ -170,9 +193,9 @@ bool pin_is_valid(struct pinctrl_dev *pctldev, int pin)
 	if (pin < 0)
 		return false;
 
-	mutex_lock(&pinctrl_mutex);
+	mutex_lock(&pctldev->mutex);
 	pindesc = pin_desc_get(pctldev, pin);
-	mutex_unlock(&pinctrl_mutex);
+	mutex_unlock(&pctldev->mutex);
 
 	return pindesc != NULL;
 }
@@ -269,15 +292,17 @@ pinctrl_match_gpio_range(struct pinctrl_dev *pctldev, unsigned gpio)
 {
 	struct pinctrl_gpio_range *range = NULL;
 
+	mutex_lock(&pctldev->mutex);
 	/* Loop over the ranges */
 	list_for_each_entry(range, &pctldev->gpio_ranges, node) {
 		/* Check if we're in the valid range */
 		if (gpio >= range->base &&
 		    gpio < range->base + range->npins) {
+			mutex_unlock(&pctldev->mutex);
 			return range;
 		}
 	}
-
+	mutex_unlock(&pctldev->mutex);
 	return NULL;
 }
 
@@ -361,9 +386,9 @@ static int pinctrl_get_device_gpio_range(unsigned gpio,
 void pinctrl_add_gpio_range(struct pinctrl_dev *pctldev,
 			    struct pinctrl_gpio_range *range)
 {
-	mutex_lock(&pinctrl_mutex);
+	mutex_lock(&pctldev->mutex);
 	list_add_tail(&range->node, &pctldev->gpio_ranges);
-	mutex_unlock(&pinctrl_mutex);
+	mutex_unlock(&pctldev->mutex);
 }
 EXPORT_SYMBOL_GPL(pinctrl_add_gpio_range);
 
@@ -381,17 +406,25 @@ EXPORT_SYMBOL_GPL(pinctrl_add_gpio_ranges);
 struct pinctrl_dev *pinctrl_find_and_add_gpio_range(const char *devname,
 		struct pinctrl_gpio_range *range)
 {
-	struct pinctrl_dev *pctldev = get_pinctrl_dev_from_devname(devname);
+	struct pinctrl_dev *pctldev;
+
+	mutex_lock(&pinctrldev_list_mutex);
+
+	pctldev = get_pinctrl_dev_from_devname(devname);
 
 	/*
 	 * If we can't find this device, let's assume that is because
 	 * it has not probed yet, so the driver trying to register this
 	 * range need to defer probing.
 	 */
-	if (!pctldev)
+	if (!pctldev) {
+		mutex_unlock(&pinctrldev_list_mutex);
 		return ERR_PTR(-EPROBE_DEFER);
-
+	}
 	pinctrl_add_gpio_range(pctldev, range);
+
+	mutex_unlock(&pinctrldev_list_mutex);
+
 	return pctldev;
 }
 EXPORT_SYMBOL_GPL(pinctrl_find_and_add_gpio_range);
@@ -407,14 +440,17 @@ pinctrl_find_gpio_range_from_pin(struct pinctrl_dev *pctldev,
 {
 	struct pinctrl_gpio_range *range = NULL;
 
+	mutex_lock(&pctldev->mutex);
 	/* Loop over the ranges */
 	list_for_each_entry(range, &pctldev->gpio_ranges, node) {
 		/* Check if we're in the valid range */
 		if (pin >= range->pin_base &&
 		    pin < range->pin_base + range->npins) {
+			mutex_unlock(&pctldev->mutex);
 			return range;
 		}
 	}
+	mutex_unlock(&pctldev->mutex);
 
 	return NULL;
 }
@@ -428,9 +464,9 @@ EXPORT_SYMBOL_GPL(pinctrl_find_gpio_range_from_pin);
 void pinctrl_remove_gpio_range(struct pinctrl_dev *pctldev,
 			       struct pinctrl_gpio_range *range)
 {
-	mutex_lock(&pinctrl_mutex);
+	mutex_lock(&pctldev->mutex);
 	list_del(&range->node);
-	mutex_unlock(&pinctrl_mutex);
+	mutex_unlock(&pctldev->mutex);
 }
 EXPORT_SYMBOL_GPL(pinctrl_remove_gpio_range);
 
@@ -481,13 +517,13 @@ int pinctrl_request_gpio(unsigned gpio)
 	int ret;
 	int pin;
 
-	mutex_lock(&pinctrl_mutex);
+	mutex_lock(&pinctrldev_list_mutex);
 
 	ret = pinctrl_get_device_gpio_range(gpio, &pctldev, &range);
 	if (ret) {
 		if (pinctrl_ready_for_gpio_range(gpio))
 			ret = 0;
-		mutex_unlock(&pinctrl_mutex);
+		mutex_unlock(&pinctrldev_list_mutex);
 		return ret;
 	}
 
@@ -496,7 +532,7 @@ int pinctrl_request_gpio(unsigned gpio)
 
 	ret = pinmux_request_gpio(pctldev, range, pin, gpio);
 
-	mutex_unlock(&pinctrl_mutex);
+	mutex_unlock(&pinctrldev_list_mutex);
 	return ret;
 }
 EXPORT_SYMBOL_GPL(pinctrl_request_gpio);
@@ -516,20 +552,22 @@ void pinctrl_free_gpio(unsigned gpio)
 	int ret;
 	int pin;
 
-	mutex_lock(&pinctrl_mutex);
+	mutex_lock(&pinctrldev_list_mutex);
 
 	ret = pinctrl_get_device_gpio_range(gpio, &pctldev, &range);
 	if (ret) {
-		mutex_unlock(&pinctrl_mutex);
+		mutex_unlock(&pinctrldev_list_mutex);
 		return;
 	}
+	mutex_lock(&pctldev->mutex);
 
 	/* Convert to the pin controllers number space */
 	pin = gpio - range->base + range->pin_base;
 
 	pinmux_free_gpio(pctldev, pin, range);
 
-	mutex_unlock(&pinctrl_mutex);
+	mutex_unlock(&pctldev->mutex);
+	mutex_unlock(&pinctrldev_list_mutex);
 }
 EXPORT_SYMBOL_GPL(pinctrl_free_gpio);
 
@@ -540,14 +578,24 @@ static int pinctrl_gpio_direction(unsigned gpio, bool input)
 	int ret;
 	int pin;
 
+	mutex_lock(&pinctrldev_list_mutex);
+
 	ret = pinctrl_get_device_gpio_range(gpio, &pctldev, &range);
-	if (ret)
+	if (ret) {
+		mutex_unlock(&pinctrldev_list_mutex);
 		return ret;
+	}
+
+	mutex_lock(&pctldev->mutex);
 
 	/* Convert to the pin controllers number space */
 	pin = gpio - range->base + range->pin_base;
+	ret = pinmux_gpio_direction(pctldev, range, pin, input);
+
+	mutex_unlock(&pctldev->mutex);
+	mutex_unlock(&pinctrldev_list_mutex);
 
-	return pinmux_gpio_direction(pctldev, range, pin, input);
+	return ret;
 }
 
 /**
@@ -560,11 +608,7 @@ static int pinctrl_gpio_direction(unsigned gpio, bool input)
  */
 int pinctrl_gpio_direction_input(unsigned gpio)
 {
-	int ret;
-	mutex_lock(&pinctrl_mutex);
-	ret = pinctrl_gpio_direction(gpio, true);
-	mutex_unlock(&pinctrl_mutex);
-	return ret;
+	return pinctrl_gpio_direction(gpio, true);
 }
 EXPORT_SYMBOL_GPL(pinctrl_gpio_direction_input);
 
@@ -578,11 +622,7 @@ EXPORT_SYMBOL_GPL(pinctrl_gpio_direction_input);
  */
 int pinctrl_gpio_direction_output(unsigned gpio)
 {
-	int ret;
-	mutex_lock(&pinctrl_mutex);
-	ret = pinctrl_gpio_direction(gpio, false);
-	mutex_unlock(&pinctrl_mutex);
-	return ret;
+	return pinctrl_gpio_direction(gpio, false);
 }
 EXPORT_SYMBOL_GPL(pinctrl_gpio_direction_output);
 
@@ -685,14 +725,18 @@ static struct pinctrl *find_pinctrl(struct device *dev)
 {
 	struct pinctrl *p;
 
+	mutex_lock(&pinctrl_list_mutex);
 	list_for_each_entry(p, &pinctrl_list, node)
-		if (p->dev == dev)
+		if (p->dev == dev) {
+			mutex_unlock(&pinctrl_list_mutex);
 			return p;
+		}
 
+	mutex_unlock(&pinctrl_list_mutex);
 	return NULL;
 }
 
-static void pinctrl_put_locked(struct pinctrl *p, bool inlist);
+static void pinctrl_free(struct pinctrl *p, bool inlist);
 
 static struct pinctrl *create_pinctrl(struct device *dev)
 {
@@ -725,6 +769,7 @@ static struct pinctrl *create_pinctrl(struct device *dev)
 
 	devname = dev_name(dev);
 
+	mutex_lock(&pinctrl_maps_mutex);
 	/* Iterate over the pin control maps to locate the right ones */
 	for_each_maps(maps_node, i, map) {
 		/* Map must be for this device */
@@ -746,13 +791,16 @@ static struct pinctrl *create_pinctrl(struct device *dev)
 		 * an -EPROBE_DEFER later, as that is the worst case.
 		 */
 		if (ret == -EPROBE_DEFER) {
-			pinctrl_put_locked(p, false);
+			pinctrl_free(p, false);
+			mutex_unlock(&pinctrl_maps_mutex);
 			return ERR_PTR(ret);
 		}
 	}
+	mutex_unlock(&pinctrl_maps_mutex);
+
 	if (ret < 0) {
 		/* If some other error than deferral occured, return here */
-		pinctrl_put_locked(p, false);
+		pinctrl_free(p, false);
 		return ERR_PTR(ret);
 	}
 
@@ -764,7 +812,11 @@ static struct pinctrl *create_pinctrl(struct device *dev)
 	return p;
 }
 
-static struct pinctrl *pinctrl_get_locked(struct device *dev)
+/**
+ * pinctrl_get() - retrieves the pinctrl handle for a device
+ * @dev: the device to obtain the handle for
+ */
+struct pinctrl *pinctrl_get(struct device *dev)
 {
 	struct pinctrl *p;
 
@@ -785,21 +837,6 @@ static struct pinctrl *pinctrl_get_locked(struct device *dev)
 
 	return create_pinctrl(dev);
 }
-
-/**
- * pinctrl_get() - retrieves the pinctrl handle for a device
- * @dev: the device to obtain the handle for
- */
-struct pinctrl *pinctrl_get(struct device *dev)
-{
-	struct pinctrl *p;
-
-	mutex_lock(&pinctrl_mutex);
-	p = pinctrl_get_locked(dev);
-	mutex_unlock(&pinctrl_mutex);
-
-	return p;
-}
 EXPORT_SYMBOL_GPL(pinctrl_get);
 
 static void pinctrl_free_setting(bool disable_setting,
@@ -820,11 +857,12 @@ static void pinctrl_free_setting(bool disable_setting,
 	}
 }
 
-static void pinctrl_put_locked(struct pinctrl *p, bool inlist)
+static void pinctrl_free(struct pinctrl *p, bool inlist)
 {
 	struct pinctrl_state *state, *n1;
 	struct pinctrl_setting *setting, *n2;
 
+	mutex_lock(&pinctrl_list_mutex);
 	list_for_each_entry_safe(state, n1, &p->states, node) {
 		list_for_each_entry_safe(setting, n2, &state->settings, node) {
 			pinctrl_free_setting(state == p->state, setting);
@@ -840,6 +878,7 @@ static void pinctrl_put_locked(struct pinctrl *p, bool inlist)
 	if (inlist)
 		list_del(&p->node);
 	kfree(p);
+	mutex_unlock(&pinctrl_list_mutex);
 }
 
 /**
@@ -850,7 +889,7 @@ static void pinctrl_release(struct kref *kref)
 {
 	struct pinctrl *p = container_of(kref, struct pinctrl, users);
 
-	pinctrl_put_locked(p, true);
+	pinctrl_free(p, true);
 }
 
 /**
@@ -859,14 +898,17 @@ static void pinctrl_release(struct kref *kref)
  */
 void pinctrl_put(struct pinctrl *p)
 {
-	mutex_lock(&pinctrl_mutex);
 	kref_put(&p->users, pinctrl_release);
-	mutex_unlock(&pinctrl_mutex);
 }
 EXPORT_SYMBOL_GPL(pinctrl_put);
 
-static struct pinctrl_state *pinctrl_lookup_state_locked(struct pinctrl *p,
-							 const char *name)
+/**
+ * pinctrl_lookup_state() - retrieves a state handle from a pinctrl handle
+ * @p: the pinctrl handle to retrieve the state from
+ * @name: the state name to retrieve
+ */
+struct pinctrl_state *pinctrl_lookup_state(struct pinctrl *p,
+						 const char *name)
 {
 	struct pinctrl_state *state;
 
@@ -883,26 +925,14 @@ static struct pinctrl_state *pinctrl_lookup_state_locked(struct pinctrl *p,
 
 	return state;
 }
+EXPORT_SYMBOL_GPL(pinctrl_lookup_state);
 
 /**
- * pinctrl_lookup_state() - retrieves a state handle from a pinctrl handle
- * @p: the pinctrl handle to retrieve the state from
- * @name: the state name to retrieve
+ * pinctrl_select_state() - select/activate/program a pinctrl state to HW
+ * @p: the pinctrl handle for the device that requests configuration
+ * @state: the state handle to select/activate/program
  */
-struct pinctrl_state *pinctrl_lookup_state(struct pinctrl *p, const char *name)
-{
-	struct pinctrl_state *s;
-
-	mutex_lock(&pinctrl_mutex);
-	s = pinctrl_lookup_state_locked(p, name);
-	mutex_unlock(&pinctrl_mutex);
-
-	return s;
-}
-EXPORT_SYMBOL_GPL(pinctrl_lookup_state);
-
-static int pinctrl_select_state_locked(struct pinctrl *p,
-				       struct pinctrl_state *state)
+int pinctrl_select_state(struct pinctrl *p, struct pinctrl_state *state)
 {
 	struct pinctrl_setting *setting, *setting2;
 	struct pinctrl_state *old_state = p->state;
@@ -956,8 +986,9 @@ static int pinctrl_select_state_locked(struct pinctrl *p,
 			break;
 		}
 
-		if (ret < 0)
+		if (ret < 0) {
 			goto unapply_new_state;
+		}
 	}
 
 	p->state = state;
@@ -983,23 +1014,7 @@ unapply_new_state:
 
 	/* There's no infinite recursive loop here because p->state is NULL */
 	if (old_state)
-		pinctrl_select_state_locked(p, old_state);
-
-	return ret;
-}
-
-/**
- * pinctrl_select() - select/activate/program a pinctrl state to HW
- * @p: the pinctrl handle for the device that requests configuratio
- * @state: the state handle to select/activate/program
- */
-int pinctrl_select_state(struct pinctrl *p, struct pinctrl_state *state)
-{
-	int ret;
-
-	mutex_lock(&pinctrl_mutex);
-	ret = pinctrl_select_state_locked(p, state);
-	mutex_unlock(&pinctrl_mutex);
+		pinctrl_select_state(p, old_state);
 
 	return ret;
 }
@@ -1129,10 +1144,10 @@ int pinctrl_register_map(struct pinctrl_map const *maps, unsigned num_maps,
 	}
 
 	if (!locked)
-		mutex_lock(&pinctrl_mutex);
+		mutex_lock(&pinctrl_maps_mutex);
 	list_add_tail(&maps_node->node, &pinctrl_maps);
 	if (!locked)
-		mutex_unlock(&pinctrl_mutex);
+		mutex_unlock(&pinctrl_maps_mutex);
 
 	return 0;
 }
@@ -1154,12 +1169,15 @@ void pinctrl_unregister_map(struct pinctrl_map const *map)
 {
 	struct pinctrl_maps *maps_node;
 
+	mutex_lock(&pinctrl_maps_mutex);
 	list_for_each_entry(maps_node, &pinctrl_maps, node) {
 		if (maps_node->maps == map) {
 			list_del(&maps_node->node);
+			mutex_unlock(&pinctrl_maps_mutex);
 			return;
 		}
 	}
+	mutex_unlock(&pinctrl_maps_mutex);
 }
 
 /**
@@ -1196,7 +1214,7 @@ static int pinctrl_pins_show(struct seq_file *s, void *what)
 
 	seq_printf(s, "registered pins: %d\n", pctldev->desc->npins);
 
-	mutex_lock(&pinctrl_mutex);
+	mutex_lock(&pctldev->mutex);
 
 	/* The pin number can be retrived from the pin controller descriptor */
 	for (i = 0; i < pctldev->desc->npins; i++) {
@@ -1218,7 +1236,7 @@ static int pinctrl_pins_show(struct seq_file *s, void *what)
 		seq_puts(s, "\n");
 	}
 
-	mutex_unlock(&pinctrl_mutex);
+	mutex_unlock(&pctldev->mutex);
 
 	return 0;
 }
@@ -1229,8 +1247,9 @@ static int pinctrl_groups_show(struct seq_file *s, void *what)
 	const struct pinctrl_ops *ops = pctldev->desc->pctlops;
 	unsigned ngroups, selector = 0;
 
+	mutex_lock(&pctldev->mutex);
+
 	ngroups = ops->get_groups_count(pctldev);
-	mutex_lock(&pinctrl_mutex);
 
 	seq_puts(s, "registered pin groups:\n");
 	while (selector < ngroups) {
@@ -1251,7 +1270,7 @@ static int pinctrl_groups_show(struct seq_file *s, void *what)
 			for (i = 0; i < num_pins; i++) {
 				pname = pin_get_name(pctldev, pins[i]);
 				if (WARN_ON(!pname)) {
-					mutex_unlock(&pinctrl_mutex);
+					mutex_unlock(&pctldev->mutex);
 					return -EINVAL;
 				}
 				seq_printf(s, "pin %d (%s)\n", pins[i], pname);
@@ -1261,7 +1280,7 @@ static int pinctrl_groups_show(struct seq_file *s, void *what)
 		selector++;
 	}
 
-	mutex_unlock(&pinctrl_mutex);
+	mutex_unlock(&pctldev->mutex);
 
 	return 0;
 }
@@ -1273,7 +1292,7 @@ static int pinctrl_gpioranges_show(struct seq_file *s, void *what)
 
 	seq_puts(s, "GPIO ranges handled:\n");
 
-	mutex_lock(&pinctrl_mutex);
+	mutex_lock(&pctldev->mutex);
 
 	/* Loop over the ranges */
 	list_for_each_entry(range, &pctldev->gpio_ranges, node) {
@@ -1284,7 +1303,7 @@ static int pinctrl_gpioranges_show(struct seq_file *s, void *what)
 			   (range->pin_base + range->npins - 1));
 	}
 
-	mutex_unlock(&pinctrl_mutex);
+	mutex_unlock(&pctldev->mutex);
 
 	return 0;
 }
@@ -1295,7 +1314,7 @@ static int pinctrl_devices_show(struct seq_file *s, void *what)
 
 	seq_puts(s, "name [pinmux] [pinconf]\n");
 
-	mutex_lock(&pinctrl_mutex);
+	mutex_lock(&pinctrldev_list_mutex);
 
 	list_for_each_entry(pctldev, &pinctrldev_list, node) {
 		seq_printf(s, "%s ", pctldev->desc->name);
@@ -1310,7 +1329,7 @@ static int pinctrl_devices_show(struct seq_file *s, void *what)
 		seq_puts(s, "\n");
 	}
 
-	mutex_unlock(&pinctrl_mutex);
+	mutex_unlock(&pinctrldev_list_mutex);
 
 	return 0;
 }
@@ -1339,8 +1358,7 @@ static int pinctrl_maps_show(struct seq_file *s, void *what)
 
 	seq_puts(s, "Pinctrl maps:\n");
 
-	mutex_lock(&pinctrl_mutex);
-
+	mutex_lock(&pinctrl_maps_mutex);
 	for_each_maps(maps_node, i, map) {
 		seq_printf(s, "device %s\nstate %s\ntype %s (%d)\n",
 			   map->dev_name, map->name, map_type(map->type),
@@ -1364,8 +1382,7 @@ static int pinctrl_maps_show(struct seq_file *s, void *what)
 
 		seq_printf(s, "\n");
 	}
-
-	mutex_unlock(&pinctrl_mutex);
+	mutex_unlock(&pinctrl_maps_mutex);
 
 	return 0;
 }
@@ -1378,7 +1395,7 @@ static int pinctrl_show(struct seq_file *s, void *what)
 
 	seq_puts(s, "Requested pin control handlers their pinmux maps:\n");
 
-	mutex_lock(&pinctrl_mutex);
+	mutex_lock(&pinctrl_list_mutex);
 
 	list_for_each_entry(p, &pinctrl_list, node) {
 		seq_printf(s, "device: %s current state: %s\n",
@@ -1410,7 +1427,7 @@ static int pinctrl_show(struct seq_file *s, void *what)
 		}
 	}
 
-	mutex_unlock(&pinctrl_mutex);
+	mutex_unlock(&pinctrl_list_mutex);
 
 	return 0;
 }
@@ -1596,6 +1613,7 @@ struct pinctrl_dev *pinctrl_register(struct pinctrl_desc *pctldesc,
 	INIT_RADIX_TREE(&pctldev->pin_desc_tree, GFP_KERNEL);
 	INIT_LIST_HEAD(&pctldev->gpio_ranges);
 	pctldev->dev = dev;
+	mutex_init(&pctldev->mutex);
 
 	/* check core ops for sanity */
 	if (pinctrl_check_ops(pctldev)) {
@@ -1625,38 +1643,37 @@ struct pinctrl_dev *pinctrl_register(struct pinctrl_desc *pctldesc,
 		goto out_err;
 	}
 
-	mutex_lock(&pinctrl_mutex);
-
+	mutex_lock(&pinctrldev_list_mutex);
 	list_add_tail(&pctldev->node, &pinctrldev_list);
+	mutex_unlock(&pinctrldev_list_mutex);
+
+	pctldev->p = pinctrl_get(pctldev->dev);
 
-	pctldev->p = pinctrl_get_locked(pctldev->dev);
 	if (!IS_ERR(pctldev->p)) {
 		pctldev->hog_default =
-			pinctrl_lookup_state_locked(pctldev->p,
-						    PINCTRL_STATE_DEFAULT);
+			pinctrl_lookup_state(pctldev->p, PINCTRL_STATE_DEFAULT);
 		if (IS_ERR(pctldev->hog_default)) {
 			dev_dbg(dev, "failed to lookup the default state\n");
 		} else {
-			if (pinctrl_select_state_locked(pctldev->p,
+			if (pinctrl_select_state(pctldev->p,
 						pctldev->hog_default))
 				dev_err(dev,
 					"failed to select default state\n");
 		}
 
 		pctldev->hog_sleep =
-			pinctrl_lookup_state_locked(pctldev->p,
+			pinctrl_lookup_state(pctldev->p,
 						    PINCTRL_STATE_SLEEP);
 		if (IS_ERR(pctldev->hog_sleep))
 			dev_dbg(dev, "failed to lookup the sleep state\n");
 	}
 
-	mutex_unlock(&pinctrl_mutex);
-
 	pinctrl_init_device_debugfs(pctldev);
 
 	return pctldev;
 
 out_err:
+	mutex_destroy(&pctldev->mutex);
 	kfree(pctldev);
 	return NULL;
 }
@@ -1674,12 +1691,13 @@ void pinctrl_unregister(struct pinctrl_dev *pctldev)
 	if (pctldev == NULL)
 		return;
 
-	pinctrl_remove_device_debugfs(pctldev);
+	mutex_lock(&pinctrldev_list_mutex);
+	mutex_lock(&pctldev->mutex);
 
-	mutex_lock(&pinctrl_mutex);
+	pinctrl_remove_device_debugfs(pctldev);
 
 	if (!IS_ERR(pctldev->p))
-		pinctrl_put_locked(pctldev->p, true);
+		pinctrl_put(pctldev->p);
 
 	/* TODO: check that no pinmuxes are still active? */
 	list_del(&pctldev->node);
@@ -1690,9 +1708,10 @@ void pinctrl_unregister(struct pinctrl_dev *pctldev)
 	list_for_each_entry_safe(range, n, &pctldev->gpio_ranges, node)
 		list_del(&range->node);
 
+	mutex_unlock(&pctldev->mutex);
+	mutex_destroy(&pctldev->mutex);
 	kfree(pctldev);
-
-	mutex_unlock(&pinctrl_mutex);
+	mutex_unlock(&pinctrldev_list_mutex);
 }
 EXPORT_SYMBOL_GPL(pinctrl_unregister);
 
diff --git a/drivers/pinctrl/core.h b/drivers/pinctrl/core.h
index 6d3d400..75476b3 100644
--- a/drivers/pinctrl/core.h
+++ b/drivers/pinctrl/core.h
@@ -33,6 +33,7 @@ struct pinctrl_gpio_range;
  * @p: result of pinctrl_get() for this device
  * @hog_default: default state for pins hogged by this device
  * @hog_sleep: sleep state for pins hogged by this device
+ * @mutex: mutex taken on each pin controller specific action
  * @device_root: debugfs root for this device
  */
 struct pinctrl_dev {
@@ -46,6 +47,7 @@ struct pinctrl_dev {
 	struct pinctrl *p;
 	struct pinctrl_state *hog_default;
 	struct pinctrl_state *hog_sleep;
+	struct mutex mutex;
 #ifdef CONFIG_DEBUG_FS
 	struct dentry *device_root;
 #endif
@@ -168,6 +170,7 @@ struct pinctrl_maps {
 };
 
 struct pinctrl_dev *get_pinctrl_dev_from_devname(const char *dev_name);
+struct pinctrl_dev *get_pinctrl_dev_from_of_node(struct device_node *np);
 int pin_get_from_name(struct pinctrl_dev *pctldev, const char *name);
 const char *pin_get_name(struct pinctrl_dev *pctldev, const unsigned pin);
 int pinctrl_get_group_selector(struct pinctrl_dev *pctldev,
@@ -186,8 +189,7 @@ void pinctrl_unregister_map(struct pinctrl_map const *map);
 extern int pinctrl_force_sleep(struct pinctrl_dev *pctldev);
 extern int pinctrl_force_default(struct pinctrl_dev *pctldev);
 
-extern struct mutex pinctrl_mutex;
-extern struct list_head pinctrldev_list;
+extern struct mutex pinctrl_maps_mutex;
 extern struct list_head pinctrl_maps;
 
 #define for_each_maps(_maps_node_, _i_, _map_) \
diff --git a/drivers/pinctrl/devicetree.c b/drivers/pinctrl/devicetree.c
index c7b7cb4..340fb4e 100644
--- a/drivers/pinctrl/devicetree.c
+++ b/drivers/pinctrl/devicetree.c
@@ -95,22 +95,11 @@ static int dt_remember_or_free_map(struct pinctrl *p, const char *statename,
 	return pinctrl_register_map(map, num_maps, false, true);
 }
 
-static struct pinctrl_dev *find_pinctrl_by_of_node(struct device_node *np)
-{
-	struct pinctrl_dev *pctldev;
-
-	list_for_each_entry(pctldev, &pinctrldev_list, node)
-		if (pctldev->dev->of_node == np)
-			return pctldev;
-
-	return NULL;
-}
-
 struct pinctrl_dev *of_pinctrl_get(struct device_node *np)
 {
 	struct pinctrl_dev *pctldev;
 
-	pctldev = find_pinctrl_by_of_node(np);
+	pctldev = get_pinctrl_dev_from_of_node(np);
 	if (!pctldev)
 		return NULL;
 
@@ -138,7 +127,7 @@ static int dt_to_map_one_config(struct pinctrl *p, const char *statename,
 			/* OK let's just assume this will appear later then */
 			return -EPROBE_DEFER;
 		}
-		pctldev = find_pinctrl_by_of_node(np_pctldev);
+		pctldev = get_pinctrl_dev_from_of_node(np_pctldev);
 		if (pctldev)
 			break;
 		/* Do not defer probing of hogs (circular loop) */
diff --git a/drivers/pinctrl/pinconf.c b/drivers/pinctrl/pinconf.c
index 32f9680..c67c37e 100644
--- a/drivers/pinctrl/pinconf.c
+++ b/drivers/pinctrl/pinconf.c
@@ -89,14 +89,14 @@ int pin_config_get(const char *dev_name, const char *name,
 	struct pinctrl_dev *pctldev;
 	int pin;
 
-	mutex_lock(&pinctrl_mutex);
-
 	pctldev = get_pinctrl_dev_from_devname(dev_name);
 	if (!pctldev) {
 		pin = -EINVAL;
-		goto unlock;
+		return pin;
 	}
 
+	mutex_lock(&pctldev->mutex);
+
 	pin = pin_get_from_name(pctldev, name);
 	if (pin < 0)
 		goto unlock;
@@ -104,7 +104,7 @@ int pin_config_get(const char *dev_name, const char *name,
 	pin = pin_config_get_for_pin(pctldev, pin, config);
 
 unlock:
-	mutex_unlock(&pinctrl_mutex);
+	mutex_unlock(&pctldev->mutex);
 	return pin;
 }
 EXPORT_SYMBOL(pin_config_get);
@@ -145,14 +145,14 @@ int pin_config_set(const char *dev_name, const char *name,
 	struct pinctrl_dev *pctldev;
 	int pin, ret;
 
-	mutex_lock(&pinctrl_mutex);
-
 	pctldev = get_pinctrl_dev_from_devname(dev_name);
 	if (!pctldev) {
 		ret = -EINVAL;
-		goto unlock;
+		return ret;
 	}
 
+	mutex_lock(&pctldev->mutex);
+
 	pin = pin_get_from_name(pctldev, name);
 	if (pin < 0) {
 		ret = pin;
@@ -162,7 +162,7 @@ int pin_config_set(const char *dev_name, const char *name,
 	ret = pin_config_set_for_pin(pctldev, pin, config);
 
 unlock:
-	mutex_unlock(&pinctrl_mutex);
+	mutex_unlock(&pctldev->mutex);
 	return ret;
 }
 EXPORT_SYMBOL(pin_config_set);
@@ -174,13 +174,14 @@ int pin_config_group_get(const char *dev_name, const char *pin_group,
 	const struct pinconf_ops *ops;
 	int selector, ret;
 
-	mutex_lock(&pinctrl_mutex);
-
 	pctldev = get_pinctrl_dev_from_devname(dev_name);
 	if (!pctldev) {
 		ret = -EINVAL;
-		goto unlock;
+		return ret;
 	}
+
+	mutex_lock(&pctldev->mutex);
+
 	ops = pctldev->desc->confops;
 
 	if (!ops || !ops->pin_config_group_get) {
@@ -200,7 +201,7 @@ int pin_config_group_get(const char *dev_name, const char *pin_group,
 	ret = ops->pin_config_group_get(pctldev, selector, config);
 
 unlock:
-	mutex_unlock(&pinctrl_mutex);
+	mutex_unlock(&pctldev->mutex);
 	return ret;
 }
 EXPORT_SYMBOL(pin_config_group_get);
@@ -217,13 +218,14 @@ int pin_config_group_set(const char *dev_name, const char *pin_group,
 	int ret;
 	int i;
 
-	mutex_lock(&pinctrl_mutex);
-
 	pctldev = get_pinctrl_dev_from_devname(dev_name);
 	if (!pctldev) {
 		ret = -EINVAL;
-		goto unlock;
+		return ret;
 	}
+
+	mutex_lock(&pctldev->mutex);
+
 	ops = pctldev->desc->confops;
 	pctlops = pctldev->desc->pctlops;
 
@@ -279,7 +281,7 @@ int pin_config_group_set(const char *dev_name, const char *pin_group,
 	ret = 0;
 
 unlock:
-	mutex_unlock(&pinctrl_mutex);
+	mutex_unlock(&pctldev->mutex);
 
 	return ret;
 }
@@ -487,7 +489,7 @@ static int pinconf_pins_show(struct seq_file *s, void *what)
 	seq_puts(s, "Pin config settings per pin\n");
 	seq_puts(s, "Format: pin (name): configs\n");
 
-	mutex_lock(&pinctrl_mutex);
+	mutex_lock(&pctldev->mutex);
 
 	/* The pin number can be retrived from the pin controller descriptor */
 	for (i = 0; i < pctldev->desc->npins; i++) {
@@ -507,7 +509,7 @@ static int pinconf_pins_show(struct seq_file *s, void *what)
 		seq_printf(s, "\n");
 	}
 
-	mutex_unlock(&pinctrl_mutex);
+	mutex_unlock(&pctldev->mutex);
 
 	return 0;
 }
@@ -608,7 +610,7 @@ static int pinconf_dbg_config_print(struct seq_file *s, void *d)
 	bool found = false;
 	unsigned long config;
 
-	mutex_lock(&pinctrl_mutex);
+	mutex_lock(&pctldev->mutex);
 
 	/* Parse the pinctrl map and look for the elected pin/state */
 	for_each_maps(maps_node, i, map) {
@@ -657,7 +659,7 @@ static int pinconf_dbg_config_print(struct seq_file *s, void *d)
 		confops->pin_config_config_dbg_show(pctldev, s, config);
 
 exit:
-	mutex_unlock(&pinctrl_mutex);
+	mutex_unlock(&pctldev->mutex);
 
 	return 0;
 }
@@ -747,7 +749,7 @@ static int pinconf_dbg_config_write(struct file *file,
 		return -EINVAL;
 	strncpy(config, token, MAX_NAME_LEN);
 
-	mutex_lock(&pinctrl_mutex);
+	mutex_lock(&pinctrl_maps_mutex);
 
 	/* Parse the pinctrl map and look for the selected dev/state/pin */
 	for_each_maps(maps_node, i, map) {
@@ -785,7 +787,7 @@ static int pinconf_dbg_config_write(struct file *file,
 	}
 
 exit:
-	mutex_unlock(&pinctrl_mutex);
+	mutex_unlock(&pinctrl_maps_mutex);
 
 	return count;
 }
diff --git a/drivers/pinctrl/pinmux.c b/drivers/pinctrl/pinmux.c
index bd83c8b..88cc509 100644
--- a/drivers/pinctrl/pinmux.c
+++ b/drivers/pinctrl/pinmux.c
@@ -506,7 +506,7 @@ static int pinmux_functions_show(struct seq_file *s, void *what)
 	if (!pmxops)
 		return 0;
 
-	mutex_lock(&pinctrl_mutex);
+	mutex_lock(&pctldev->mutex);
 	nfuncs = pmxops->get_functions_count(pctldev);
 	while (func_selector < nfuncs) {
 		const char *func = pmxops->get_function_name(pctldev,
@@ -530,7 +530,7 @@ static int pinmux_functions_show(struct seq_file *s, void *what)
 		func_selector++;
 	}
 
-	mutex_unlock(&pinctrl_mutex);
+	mutex_unlock(&pctldev->mutex);
 
 	return 0;
 }
@@ -548,7 +548,7 @@ static int pinmux_pins_show(struct seq_file *s, void *what)
 	seq_puts(s, "Pinmux settings per pin\n");
 	seq_puts(s, "Format: pin (name): mux_owner gpio_owner hog?\n");
 
-	mutex_lock(&pinctrl_mutex);
+	mutex_lock(&pctldev->mutex);
 
 	/* The pin number can be retrived from the pin controller descriptor */
 	for (i = 0; i < pctldev->desc->npins; i++) {
@@ -583,7 +583,7 @@ static int pinmux_pins_show(struct seq_file *s, void *what)
 			seq_printf(s, "\n");
 	}
 
-	mutex_unlock(&pinctrl_mutex);
+	mutex_unlock(&pctldev->mutex);
 
 	return 0;
 }
-- 
1.7.11.3



From peter.maydell at linaro.org  Fri Apr 26 11:19:13 2013
From: peter.maydell at linaro.org (Peter Maydell)
Date: Fri, 26 Apr 2013 16:19:13 +0100
Subject: [PATCH 0/2] Early printk support for virtio console devices.
In-Reply-To: <1577576.O1Cm2pf5KD@wuerfel>
References: <1366974299-17877-1-git-send-email-pranavkumar@linaro.org>
 <CAFEAcA_xmrHTvR7FxUr3PCKBJY-hZnkeBcqyHksTB4-hqOZS0w@mail.gmail.com>
 <CALrVBkuOmu4u9egdzzfn1tU9B-CFe3w85HZQ9s2gpKvYnaSqvA@mail.gmail.com>
 <1577576.O1Cm2pf5KD@wuerfel>
Message-ID: <CAFEAcA9Vp0H9TMqHg+R+Kv0TzrQoCAt0Gr9c9DE94omp78XXig@mail.gmail.com>

On 26 April 2013 13:33, Arnd Bergmann <arnd at arndb.de> wrote:
> Couldn't kvmtool implement the interface used by smh_printch()
> for early output instead?
>
> Or if that's not a fitting inteface, maybe a psci call for writing
> a character to the console?

I suggested that earlier:
https://lists.cs.columbia.edu/pipermail/kvmarm/2013-April/005433.html

and Alex pointed out that s390-virtio experience with that
approach is that it's awkward for userspace.

-- PMM


From lee.jones at linaro.org  Fri Apr 26 11:19:48 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Fri, 26 Apr 2013 16:19:48 +0100
Subject: [PATCH 00/10] usb: musb: ux500: pathe the way for Device Tree
 enablement
In-Reply-To: <20130426134915.GA19558@balto.lan>
References: <1366729394-11406-1-git-send-email-lee.jones@linaro.org>
 <20130426134915.GA19558@balto.lan>
Message-ID: <20130426151948.GE31899@gmail.com>

On Fri, 26 Apr 2013, Fabio Baltieri wrote:

> Hi Lee,
> 
> On Tue, Apr 23, 2013 at 04:03:04PM +0100, Lee Jones wrote:
> > In this patch-set we firstly ease the burden on data being passed from
> > platform data, then start to build up support to finally enable Device
> > Tree.
> 
> The whole series looks good to me, nice job!!
> 
> Acked-by: Fabio Baltieri <fabio.baltieri at linaro.org>

Thanks for reviewing.

> I was not able to apply the patches though, as I can imagine that there
> are some dependencies with your other dma40 series.  If you can provide a
> tree I would be happy to run some test for both host and device mode.
> I still have a bunch of USB cables and adapters tangled together on my
> desk ready for that.

The most recent branch on my public tree contains the latest code.

Memcpy will probably fail though, as I haven't fixed up Linus'
comments pertaining them that yet.

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From vincent.guittot at linaro.org  Fri Apr 26 11:40:27 2013
From: vincent.guittot at linaro.org (Vincent Guittot)
Date: Fri, 26 Apr 2013 17:40:27 +0200
Subject: [RFC PATCH v4 00/14] sched: packing small tasks
In-Reply-To: <517A969B.5040606@linux.intel.com>
References: <1366910611-20048-1-git-send-email-vincent.guittot@linaro.org>
 <517A969B.5040606@linux.intel.com>
Message-ID: <CAKfTPtCwdw1mYpWRFbPo9zT=9vFANpJyubh1eX-0vJLqrqizgA@mail.gmail.com>

On 26 April 2013 17:00, Arjan van de Ven <arjan at linux.intel.com> wrote:
> On 4/25/2013 10:23 AM, Vincent Guittot wrote:
>>
>> Hi,
>>
>> This patchset takes advantage of the new per-task load tracking that is
>> available in the kernel for packing the tasks in as few as possible
>> CPU/Cluster/Core. It has got 2 packing modes:
>> -The 1st mode packs the small tasks when the system is not too busy. The
>> main
>> goal is to reduce the power consumption in the low system load use cases
>> by
>> minimizing the number of power domain that are enabled but it also keeps
>> the
>> default behavior which is performance oriented.
>> -The 2nd mode packs all tasks in as few as possible power domains in order
>> to
>> improve the power consumption of the system but at the cost of possible
>> performance decrease because of the increase of the rate of ressources
>> sharing
>> compared to the default mode.
>
>
>
> so I got to ask the hard question; what percentage of system level (not just
> cpu level)
> power consumption gain can you measure (pick your favorite workload)...
>

I haven't system level figures for my patches but only for the cpu
subsystem. If we use the MP3 results in the back of my mail, they show
an improvement of 37 % (113/178) for the CPU subsystem of the
platform. If we assume that the CPU subsystem contributes 25% of an
embedded system power consumption (this can vary across platform
depending of the use of HW accelerator but it should be a almost fair
percentage), the patch can impact the power consumption on up to 9%.

> on x86 (even on the low power stuff) I expect this to be very far into the
> noise
> (since we have per core power gates, and power transitions are pretty fast)
>
> you have some numbers in the back of your mail, but it's hard for me to get
> a conclusion out of
> that (they either measure only cpu power, or are just vague in general)
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/


From csd at broadcom.com  Fri Apr 26 11:41:55 2013
From: csd at broadcom.com (Christian Daudt)
Date: Fri, 26 Apr 2013 08:41:55 -0700
Subject: [PATCH] ARM: bcm: mark bcm_kona_smc_init as __init
In-Reply-To: <201304231744.40614.arnd@arndb.de>
References: <201304231744.40614.arnd@arndb.de>
Message-ID: <517AA043.30005@broadcom.com>

On 13-04-23 08:44 AM, Arnd Bergmann wrote:
> The bcm_kona_smc_init function references the bcm_kona_smc_ids variable
> that is marked __initconst, so the function itself has to be __init
> to avoid this build error:
>
> WARNING: arch/arm/mach-bcm/built-in.o(.text+0x12c): Section mismatch in reference from the function bcm_kona_smc_init() to the (unknown reference) .init.rodata:(unknown)
>
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Cc: Christian Daudt <csd at broadcom.com>
> ---
> I have applied this trivial fix to the next/firmware branch
>
> diff --git a/arch/arm/mach-bcm/bcm_kona_smc.c b/arch/arm/mach-bcm/bcm_kona_smc.c
> index 5f1d131..56d9d19 100644
> --- a/arch/arm/mach-bcm/bcm_kona_smc.c
> +++ b/arch/arm/mach-bcm/bcm_kona_smc.c
> @@ -41,7 +41,7 @@ static const struct of_device_id bcm_kona_smc_ids[] __initconst = {
>   };
>   
>   /* Map in the bounce area */
> -void bcm_kona_smc_init(void)
> +void __init bcm_kona_smc_init(void)
>   {
>   	struct device_node *node;
>   
>
acked-by: Christian Daudt <csd at broadcom.com>



From csd at broadcom.com  Fri Apr 26 11:42:58 2013
From: csd at broadcom.com (Christian Daudt)
Date: Fri, 26 Apr 2013 08:42:58 -0700
Subject: [PATCH] clocksource: kona: adapt to CLOCKSOURCE_OF_DECLARE change
In-Reply-To: <1366732475-479886-5-git-send-email-arnd@arndb.de>
References: <1366732475-479886-1-git-send-email-arnd@arndb.de>
 <1366732475-479886-5-git-send-email-arnd@arndb.de>
Message-ID: <517AA082.8070806@broadcom.com>

On 13-04-23 08:54 AM, Arnd Bergmann wrote:
> The CLOCKSOURCE_OF_DECLARE functions now take a device_node pointer
> as their argument, as of the clksrc/cleanup branch in arm-soc.
> This patch adapts the bcm_kona_timer driver to the new interface.
>
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Cc: Christian Daudt <csd at broadcom.com>
> Cc: John Stultz <john.stultz at linaro.org>
> ---
>   drivers/clocksource/bcm_kona_timer.c | 15 ++++-----------
>   1 file changed, 4 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/clocksource/bcm_kona_timer.c b/drivers/clocksource/bcm_kona_timer.c
> ...
>   
> -CLOCKSOURCE_OF_DECLARE(bcm_kona, "bcm,kona-timer",
> -	kona_timer_init);
> +CLOCKSOURCE_OF_DECLARE(bcm_kona, "bcm,kona-timer", kona_timer_init);
acked-by: Christian Daudt <csd at broadcom.com>
tested-by: Christian Daudt <csd at broadcom.com>

  thanks,
    csd




From arjan at linux.intel.com  Fri Apr 26 11:46:21 2013
From: arjan at linux.intel.com (Arjan van de Ven)
Date: Fri, 26 Apr 2013 08:46:21 -0700
Subject: [RFC PATCH v4 00/14] sched: packing small tasks
In-Reply-To: <CAKfTPtCwdw1mYpWRFbPo9zT=9vFANpJyubh1eX-0vJLqrqizgA@mail.gmail.com>
References: <1366910611-20048-1-git-send-email-vincent.guittot@linaro.org>
 <517A969B.5040606@linux.intel.com>
 <CAKfTPtCwdw1mYpWRFbPo9zT=9vFANpJyubh1eX-0vJLqrqizgA@mail.gmail.com>
Message-ID: <517AA14D.7060202@linux.intel.com>

>>
>>
>> so I got to ask the hard question; what percentage of system level (not just
>> cpu level)
>> power consumption gain can you measure (pick your favorite workload)...
>>
>
> I haven't system level figures for my patches but only for the cpu
> subsystem. If we use the MP3 results in the back of my mail, they show
> an improvement of 37 % (113/178) for the CPU subsystem of the
> platform. If we assume that the CPU subsystem contributes 25% of an
> embedded system power consumption (this can vary across platform
> depending of the use of HW accelerator but it should be a almost fair
> percentage), the patch can impact the power consumption on up to 9%.
>

sadly the math tends to not work quite that easy;
memory takes significantly more power when the system is not idle than when it is idle for example. [*]
so while reducing cpu power by making it run a bit longer (at lower frequency or
slower core or whatever) is a pure win if you only look at the cpu, but it may
(or may not) be a loss when looking at a whole system level.

I've learned the hard way that you cannot just look at the cpu numbers; you must look
at the whole-system power when playing with such tradeoffs.

That does not mean that your patch is not useful; it very well can be, but
without having looked at whole-system power that's a very dangerous conclusion to make.
So.. if you get a chance, I'd love to see data on a whole-system level... even for just one workload
and one system
(playing mp3 sounds like a quite reasonable workload for such things indeed)


[*] I assume that on your ARM systems, memory goes into self refresh during system idle just as it does on x86



From shc_work at mail.ru  Fri Apr 26 11:47:30 2013
From: shc_work at mail.ru (Alexander Shiyan)
Date: Fri, 26 Apr 2013 19:47:30 +0400
Subject: [PATCH v2 3/3] GPIO: clps711x: Add DT support
In-Reply-To: <1366991250-17130-1-git-send-email-shc_work@mail.ru>
References: <1366991250-17130-1-git-send-email-shc_work@mail.ru>
Message-ID: <1366991250-17130-3-git-send-email-shc_work@mail.ru>

Add DT support to the CLPS711X GPIO driver.

Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
---
 .../devicetree/bindings/gpio/gpio-clps711x.txt     | 28 ++++++++++++++++++++++
 drivers/gpio/gpio-clps711x.c                       | 14 ++++++++---
 2 files changed, 39 insertions(+), 3 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/gpio/gpio-clps711x.txt

diff --git a/Documentation/devicetree/bindings/gpio/gpio-clps711x.txt b/Documentation/devicetree/bindings/gpio/gpio-clps711x.txt
new file mode 100644
index 0000000..e0d0446
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-clps711x.txt
@@ -0,0 +1,28 @@
+Cirrus Logic CLPS711X GPIO controller
+
+Required properties:
+- compatible: Should be "cirrus,clps711x-gpio"
+- reg: Physical base GPIO controller registers location and length.
+  There should be two registers, first is DATA register, the second
+  is DIRECTION.
+- gpio-controller: Marks the device node as a gpio controller.
+- #gpio-cells: Should be two. The first cell is the pin number and
+  the second cell is used to specify the gpio polarity:
+    0 = active high
+    1 = active low
+
+Note: Each GPIO port should have an alias correctly numbered in "aliases"
+node.
+
+Example:
+
+aliases {
+	gpio0 = &porta;
+};
+
+porta: gpio at 80000000 {
+	compatible = "cirrus,clps711x-gpio";
+	reg = <0x80000000 0x1>, <0x80000040 0x1>;
+	gpio-controller;
+	#gpio-cells = <2>;
+};
diff --git a/drivers/gpio/gpio-clps711x.c b/drivers/gpio/gpio-clps711x.c
index 6ce8a8c..0edaf2c 100644
--- a/drivers/gpio/gpio-clps711x.c
+++ b/drivers/gpio/gpio-clps711x.c
@@ -17,10 +17,11 @@
 
 static int clps711x_gpio_probe(struct platform_device *pdev)
 {
+	struct device_node *np = pdev->dev.of_node;
 	void __iomem *dat, *dir;
 	struct bgpio_chip *bgc;
 	struct resource *res;
-	int err, id = pdev->id;
+	int err, id = np ? of_alias_get_id(np, "gpio") : pdev->id;
 
 	if ((id < 0) || (id > 4))
 		return -ENODEV;
@@ -76,10 +77,17 @@ static int clps711x_gpio_remove(struct platform_device *pdev)
 	return bgpio_remove(bgc);
 }
 
+static const struct of_device_id clps711x_gpio_ids[] = {
+	{ .compatible = "cirrus,clps711x-gpio" },
+	{ }
+};
+MODULE_DEVICE_TABLE(of, clps711x_gpio_ids);
+
 static struct platform_driver clps711x_gpio_driver = {
 	.driver	= {
-		.name	= "clps711x-gpio",
-		.owner	= THIS_MODULE,
+		.name		= "clps711x-gpio",
+		.owner		= THIS_MODULE,
+		.of_match_table	= of_match_ptr(clps711x_gpio_ids),
 	},
 	.probe	= clps711x_gpio_probe,
 	.remove	= clps711x_gpio_remove,
-- 
1.8.1.5



From shc_work at mail.ru  Fri Apr 26 11:47:28 2013
From: shc_work at mail.ru (Alexander Shiyan)
Date: Fri, 26 Apr 2013 19:47:28 +0400
Subject: [PATCH v2 1/3] GPIO: clps711x: Rewrite driver for using generic GPIO
 code
Message-ID: <1366991250-17130-1-git-send-email-shc_work@mail.ru>

This patch provides rewritten driver for CLPS711X GPIO which uses
generic GPIO code.

Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
---
 drivers/gpio/Kconfig         |   5 +-
 drivers/gpio/gpio-clps711x.c | 226 +++++++++++--------------------------------
 2 files changed, 63 insertions(+), 168 deletions(-)

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 6899afb..c6cea12 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -109,8 +109,11 @@ config GPIO_MAX730X
 comment "Memory mapped GPIO drivers:"
 
 config GPIO_CLPS711X
-	def_bool y
+	tristate "CLPS711X GPIO support"
 	depends on ARCH_CLPS711X
+	select GPIO_GENERIC
+	help
+	  Say yes here to support GPIO on CLPS711X SoCs.
 
 config GPIO_GENERIC_PLATFORM
 	tristate "Generic memory-mapped GPIO controller support (MMIO platform device)"
diff --git a/drivers/gpio/gpio-clps711x.c b/drivers/gpio/gpio-clps711x.c
index ce63b75..6ce8a8c 100644
--- a/drivers/gpio/gpio-clps711x.c
+++ b/drivers/gpio/gpio-clps711x.c
@@ -1,7 +1,7 @@
 /*
  *  CLPS711X GPIO driver
  *
- *  Copyright (C) 2012 Alexander Shiyan <shc_work at mail.ru>
+ *  Copyright (C) 2012,2013 Alexander Shiyan <shc_work at mail.ru>
  *
  * 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
@@ -9,191 +9,83 @@
  * (at your option) any later version.
  */
 
-#include <linux/io.h>
-#include <linux/slab.h>
+#include <linux/err.h>
 #include <linux/gpio.h>
 #include <linux/module.h>
-#include <linux/spinlock.h>
+#include <linux/basic_mmio_gpio.h>
 #include <linux/platform_device.h>
 
-#include <mach/hardware.h>
-
-#define CLPS711X_GPIO_PORTS	5
-#define CLPS711X_GPIO_NAME	"gpio-clps711x"
-
-struct clps711x_gpio {
-	struct gpio_chip	chip[CLPS711X_GPIO_PORTS];
-	spinlock_t		lock;
-};
-
-static void __iomem *clps711x_ports[] = {
-	CLPS711X_VIRT_BASE + PADR,
-	CLPS711X_VIRT_BASE + PBDR,
-	CLPS711X_VIRT_BASE + PCDR,
-	CLPS711X_VIRT_BASE + PDDR,
-	CLPS711X_VIRT_BASE + PEDR,
-};
-
-static void __iomem *clps711x_pdirs[] = {
-	CLPS711X_VIRT_BASE + PADDR,
-	CLPS711X_VIRT_BASE + PBDDR,
-	CLPS711X_VIRT_BASE + PCDDR,
-	CLPS711X_VIRT_BASE + PDDDR,
-	CLPS711X_VIRT_BASE + PEDDR,
-};
-
-#define clps711x_port(x)	clps711x_ports[x->base / 8]
-#define clps711x_pdir(x)	clps711x_pdirs[x->base / 8]
-
-static int gpio_clps711x_get(struct gpio_chip *chip, unsigned offset)
+static int clps711x_gpio_probe(struct platform_device *pdev)
 {
-	return !!(readb(clps711x_port(chip)) & (1 << offset));
-}
+	void __iomem *dat, *dir;
+	struct bgpio_chip *bgc;
+	struct resource *res;
+	int err, id = pdev->id;
 
-static void gpio_clps711x_set(struct gpio_chip *chip, unsigned offset,
-			      int value)
-{
-	int tmp;
-	unsigned long flags;
-	struct clps711x_gpio *gpio = dev_get_drvdata(chip->dev);
+	if ((id < 0) || (id > 4))
+		return -ENODEV;
 
-	spin_lock_irqsave(&gpio->lock, flags);
-	tmp = readb(clps711x_port(chip)) & ~(1 << offset);
-	if (value)
-		tmp |= 1 << offset;
-	writeb(tmp, clps711x_port(chip));
-	spin_unlock_irqrestore(&gpio->lock, flags);
-}
-
-static int gpio_clps711x_dir_in(struct gpio_chip *chip, unsigned offset)
-{
-	int tmp;
-	unsigned long flags;
-	struct clps711x_gpio *gpio = dev_get_drvdata(chip->dev);
-
-	spin_lock_irqsave(&gpio->lock, flags);
-	tmp = readb(clps711x_pdir(chip)) & ~(1 << offset);
-	writeb(tmp, clps711x_pdir(chip));
-	spin_unlock_irqrestore(&gpio->lock, flags);
-
-	return 0;
-}
+	bgc = devm_kzalloc(&pdev->dev, sizeof(*bgc), GFP_KERNEL);
+	if (!bgc)
+		return -ENOMEM;
 
-static int gpio_clps711x_dir_out(struct gpio_chip *chip, unsigned offset,
-				 int value)
-{
-	int tmp;
-	unsigned long flags;
-	struct clps711x_gpio *gpio = dev_get_drvdata(chip->dev);
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	dat = devm_ioremap_resource(&pdev->dev, res);
+	if (IS_ERR(dat))
+		return PTR_ERR(dat);
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+	dir = devm_ioremap_resource(&pdev->dev, res);
+	if (IS_ERR(dir))
+		return PTR_ERR(dir);
+
+	switch (id) {
+	case 3:
+		/* PORTD is inverted logic for direction register */
+		err = bgpio_init(bgc, &pdev->dev, 1, dat, NULL, NULL,
+				 NULL, dir, 0);
+		break;
+	default:
+		err = bgpio_init(bgc, &pdev->dev, 1, dat, NULL, NULL,
+				 dir, NULL, 0);
+		break;
+	}
 
-	spin_lock_irqsave(&gpio->lock, flags);
-	tmp = readb(clps711x_pdir(chip)) | (1 << offset);
-	writeb(tmp, clps711x_pdir(chip));
-	tmp = readb(clps711x_port(chip)) & ~(1 << offset);
-	if (value)
-		tmp |= 1 << offset;
-	writeb(tmp, clps711x_port(chip));
-	spin_unlock_irqrestore(&gpio->lock, flags);
+	if (err)
+		return err;
 
-	return 0;
-}
-
-static int gpio_clps711x_dir_in_inv(struct gpio_chip *chip, unsigned offset)
-{
-	int tmp;
-	unsigned long flags;
-	struct clps711x_gpio *gpio = dev_get_drvdata(chip->dev);
+	switch (id) {
+	case 4:
+		/* PORTE is 3 lines only */
+		bgc->gc.ngpio = 3;
+		break;
+	default:
+		break;
+	}
 
-	spin_lock_irqsave(&gpio->lock, flags);
-	tmp = readb(clps711x_pdir(chip)) | (1 << offset);
-	writeb(tmp, clps711x_pdir(chip));
-	spin_unlock_irqrestore(&gpio->lock, flags);
+	bgc->gc.base = id * 8;
+	platform_set_drvdata(pdev, bgc);
 
-	return 0;
+	return gpiochip_add(&bgc->gc);
 }
 
-static int gpio_clps711x_dir_out_inv(struct gpio_chip *chip, unsigned offset,
-				     int value)
+static int clps711x_gpio_remove(struct platform_device *pdev)
 {
-	int tmp;
-	unsigned long flags;
-	struct clps711x_gpio *gpio = dev_get_drvdata(chip->dev);
+	struct bgpio_chip *bgc = platform_get_drvdata(pdev);
 
-	spin_lock_irqsave(&gpio->lock, flags);
-	tmp = readb(clps711x_pdir(chip)) & ~(1 << offset);
-	writeb(tmp, clps711x_pdir(chip));
-	tmp = readb(clps711x_port(chip)) & ~(1 << offset);
-	if (value)
-		tmp |= 1 << offset;
-	writeb(tmp, clps711x_port(chip));
-	spin_unlock_irqrestore(&gpio->lock, flags);
-
-	return 0;
+	return bgpio_remove(bgc);
 }
 
-static struct {
-	char	*name;
-	int	nr;
-	int	inv_dir;
-} clps711x_gpio_ports[] __initconst = {
-	{ "PORTA", 8, 0, },
-	{ "PORTB", 8, 0, },
-	{ "PORTC", 8, 0, },
-	{ "PORTD", 8, 1, },
-	{ "PORTE", 3, 0, },
+static struct platform_driver clps711x_gpio_driver = {
+	.driver	= {
+		.name	= "clps711x-gpio",
+		.owner	= THIS_MODULE,
+	},
+	.probe	= clps711x_gpio_probe,
+	.remove	= clps711x_gpio_remove,
 };
+module_platform_driver(clps711x_gpio_driver);
 
-static int __init gpio_clps711x_init(void)
-{
-	int i;
-	struct platform_device *pdev;
-	struct clps711x_gpio *gpio;
-
-	pdev = platform_device_alloc(CLPS711X_GPIO_NAME, 0);
-	if (!pdev) {
-		pr_err("Cannot create platform device: %s\n",
-		       CLPS711X_GPIO_NAME);
-		return -ENOMEM;
-	}
-
-	platform_device_add(pdev);
-
-	gpio = devm_kzalloc(&pdev->dev, sizeof(struct clps711x_gpio),
-			    GFP_KERNEL);
-	if (!gpio) {
-		dev_err(&pdev->dev, "GPIO allocating memory error\n");
-		platform_device_unregister(pdev);
-		return -ENOMEM;
-	}
-
-	platform_set_drvdata(pdev, gpio);
-
-	spin_lock_init(&gpio->lock);
-
-	for (i = 0; i < CLPS711X_GPIO_PORTS; i++) {
-		gpio->chip[i].owner		= THIS_MODULE;
-		gpio->chip[i].dev		= &pdev->dev;
-		gpio->chip[i].label		= clps711x_gpio_ports[i].name;
-		gpio->chip[i].base		= i * 8;
-		gpio->chip[i].ngpio		= clps711x_gpio_ports[i].nr;
-		gpio->chip[i].get		= gpio_clps711x_get;
-		gpio->chip[i].set		= gpio_clps711x_set;
-		if (!clps711x_gpio_ports[i].inv_dir) {
-			gpio->chip[i].direction_input = gpio_clps711x_dir_in;
-			gpio->chip[i].direction_output = gpio_clps711x_dir_out;
-		} else {
-			gpio->chip[i].direction_input = gpio_clps711x_dir_in_inv;
-			gpio->chip[i].direction_output = gpio_clps711x_dir_out_inv;
-		}
-		WARN_ON(gpiochip_add(&gpio->chip[i]));
-	}
-
-	dev_info(&pdev->dev, "GPIO driver initialized\n");
-
-	return 0;
-}
-arch_initcall(gpio_clps711x_init);
-
-MODULE_LICENSE("GPL v2");
+MODULE_LICENSE("GPL");
 MODULE_AUTHOR("Alexander Shiyan <shc_work at mail.ru>");
 MODULE_DESCRIPTION("CLPS711X GPIO driver");
-- 
1.8.1.5



From shc_work at mail.ru  Fri Apr 26 11:47:29 2013
From: shc_work at mail.ru (Alexander Shiyan)
Date: Fri, 26 Apr 2013 19:47:29 +0400
Subject: [PATCH v2 2/3] ARM: clps711x: Re-add GPIO support
In-Reply-To: <1366991250-17130-1-git-send-email-shc_work@mail.ru>
References: <1366991250-17130-1-git-send-email-shc_work@mail.ru>
Message-ID: <1366991250-17130-2-git-send-email-shc_work@mail.ru>

arch_initcall was been removed from GPIO driver, so this patch
re-add support for GPIO into boards as platform_device.
Since some drivers (spi, nand, etc.) is not support deferred probe,
separate machine init calls is used in board code to make proper
loading sequence.

Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
---
 arch/arm/mach-clps711x/Makefile         |  5 +---
 arch/arm/mach-clps711x/board-autcpu12.c |  2 ++
 arch/arm/mach-clps711x/board-cdb89712.c |  2 ++
 arch/arm/mach-clps711x/board-edb7211.c  |  7 +++++
 arch/arm/mach-clps711x/board-p720t.c    | 10 ++++---
 arch/arm/mach-clps711x/devices.c        | 48 +++++++++++++++++++++++++++++++++
 arch/arm/mach-clps711x/devices.h        | 12 +++++++++
 7 files changed, 78 insertions(+), 8 deletions(-)
 create mode 100644 arch/arm/mach-clps711x/devices.c
 create mode 100644 arch/arm/mach-clps711x/devices.h

diff --git a/arch/arm/mach-clps711x/Makefile b/arch/arm/mach-clps711x/Makefile
index 992995a..f30ed2b 100644
--- a/arch/arm/mach-clps711x/Makefile
+++ b/arch/arm/mach-clps711x/Makefile
@@ -4,10 +4,7 @@
 
 # Object file lists.
 
-obj-y			:= common.o
-obj-m			:=
-obj-n			:=
-obj-			:=
+obj-y				:= common.o devices.o
 
 obj-$(CONFIG_ARCH_AUTCPU12)	+= board-autcpu12.o
 obj-$(CONFIG_ARCH_CDB89712)	+= board-cdb89712.o
diff --git a/arch/arm/mach-clps711x/board-autcpu12.c b/arch/arm/mach-clps711x/board-autcpu12.c
index f385847..1e22cb4 100644
--- a/arch/arm/mach-clps711x/board-autcpu12.c
+++ b/arch/arm/mach-clps711x/board-autcpu12.c
@@ -43,6 +43,7 @@
 #include <mach/autcpu12.h>
 
 #include "common.h"
+#include "devices.h"
 
 #define AUTCPU12_CS8900_BASE	(CS2_PHYS_BASE + 0x300)
 #define AUTCPU12_CS8900_IRQ	(IRQ_EINT3)
@@ -149,6 +150,7 @@ static struct platform_device autcpu12_mmgpio_pdev __initdata = {
 
 static void __init autcpu12_init(void)
 {
+	clps711x_devices_init();
 	platform_device_register_simple("video-clps711x", 0, NULL, 0);
 	platform_device_register_simple("cs89x0", 0, autcpu12_cs8900_resource,
 					ARRAY_SIZE(autcpu12_cs8900_resource));
diff --git a/arch/arm/mach-clps711x/board-cdb89712.c b/arch/arm/mach-clps711x/board-cdb89712.c
index baab7da..a80ae57 100644
--- a/arch/arm/mach-clps711x/board-cdb89712.c
+++ b/arch/arm/mach-clps711x/board-cdb89712.c
@@ -39,6 +39,7 @@
 #include <asm/mach/map.h>
 
 #include "common.h"
+#include "devices.h"
 
 #define CDB89712_CS8900_BASE	(CS2_PHYS_BASE + 0x300)
 #define CDB89712_CS8900_IRQ	(IRQ_EINT3)
@@ -127,6 +128,7 @@ static struct platform_device cdb89712_sram_pdev __initdata = {
 
 static void __init cdb89712_init(void)
 {
+	clps711x_devices_init();
 	platform_device_register(&cdb89712_flash_pdev);
 	platform_device_register(&cdb89712_bootrom_pdev);
 	platform_device_register(&cdb89712_sram_pdev);
diff --git a/arch/arm/mach-clps711x/board-edb7211.c b/arch/arm/mach-clps711x/board-edb7211.c
index 5f928e9..e1c5573 100644
--- a/arch/arm/mach-clps711x/board-edb7211.c
+++ b/arch/arm/mach-clps711x/board-edb7211.c
@@ -29,6 +29,7 @@
 #include <mach/hardware.h>
 
 #include "common.h"
+#include "devices.h"
 
 #define VIDEORAM_SIZE		SZ_128K
 
@@ -151,6 +152,11 @@ fixup_edb7211(struct tag *tags, char **cmdline, struct meminfo *mi)
 
 static void __init edb7211_init(void)
 {
+	clps711x_devices_init();
+}
+
+static void __init edb7211_init_late(void)
+{
 	gpio_request_array(edb7211_gpios, ARRAY_SIZE(edb7211_gpios));
 
 	platform_device_register(&edb7211_flash_pdev);
@@ -175,6 +181,7 @@ MACHINE_START(EDB7211, "CL-EDB7211 (EP7211 eval board)")
 	.init_irq	= clps711x_init_irq,
 	.init_time	= clps711x_timer_init,
 	.init_machine	= edb7211_init,
+	.init_late	= edb7211_init_late,
 	.handle_irq	= clps711x_handle_irq,
 	.restart	= clps711x_restart,
 MACHINE_END
diff --git a/arch/arm/mach-clps711x/board-p720t.c b/arch/arm/mach-clps711x/board-p720t.c
index 8d3ee67..48d0737 100644
--- a/arch/arm/mach-clps711x/board-p720t.c
+++ b/arch/arm/mach-clps711x/board-p720t.c
@@ -43,6 +43,7 @@
 #include <video/platform_lcd.h>
 
 #include "common.h"
+#include "devices.h"
 
 #define P720T_USERLED		CLPS711X_GPIO(3, 0)
 #define P720T_NAND_CLE		CLPS711X_GPIO(4, 0)
@@ -199,6 +200,11 @@ static struct gpio_led_platform_data p720t_gpio_led_pdata __initdata = {
 
 static void __init p720t_init(void)
 {
+	clps711x_devices_init();
+}
+
+static void __init p720t_init_late(void)
+{
 	platform_device_register(&p720t_nand_pdev);
 	platform_device_register_data(&platform_bus, "platform-lcd", 0,
 				      &p720t_lcd_power_pdata,
@@ -207,10 +213,6 @@ static void __init p720t_init(void)
 				      &p720t_lcd_backlight_pdata,
 				      sizeof(p720t_lcd_backlight_pdata));
 	platform_device_register_simple("video-clps711x", 0, NULL, 0);
-}
-
-static void __init p720t_init_late(void)
-{
 	platform_device_register_data(&platform_bus, "leds-gpio", 0,
 				      &p720t_gpio_led_pdata,
 				      sizeof(p720t_gpio_led_pdata));
diff --git a/arch/arm/mach-clps711x/devices.c b/arch/arm/mach-clps711x/devices.c
new file mode 100644
index 0000000..21161ed
--- /dev/null
+++ b/arch/arm/mach-clps711x/devices.c
@@ -0,0 +1,48 @@
+/*
+ *  CLPS711X common devices definitions
+ *
+ *  Author: Alexander Shiyan <shc_work at mail.ru>, 2013
+ *
+ * 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.
+ */
+
+#include <linux/platform_device.h>
+
+#include <mach/hardware.h>
+
+static const phys_addr_t clps711x_gpios[][2] __initconst = {
+	{ PADR, PADDR },
+	{ PBDR, PBDDR },
+	{ PCDR, PCDDR },
+	{ PDDR, PDDDR },
+	{ PEDR, PEDDR },
+};
+
+static void __init clps711x_add_gpio(void)
+{
+	unsigned i;
+	struct resource gpio_res[2];
+
+	memset(gpio_res, 0, sizeof(gpio_res));
+
+	gpio_res[0].flags = IORESOURCE_MEM;
+	gpio_res[1].flags = IORESOURCE_MEM;
+
+	for (i = 0; i < ARRAY_SIZE(clps711x_gpios); i++) {
+		gpio_res[0].start = CLPS711X_PHYS_BASE + clps711x_gpios[i][0];
+		gpio_res[0].end = gpio_res[0].start;
+		gpio_res[1].start = CLPS711X_PHYS_BASE + clps711x_gpios[i][1];
+		gpio_res[1].end = gpio_res[1].start;
+
+		platform_device_register_simple("clps711x-gpio", i,
+						gpio_res, ARRAY_SIZE(gpio_res));
+	}
+}
+
+void __init clps711x_devices_init(void)
+{
+	clps711x_add_gpio();
+}
diff --git a/arch/arm/mach-clps711x/devices.h b/arch/arm/mach-clps711x/devices.h
new file mode 100644
index 0000000..a5efc17
--- /dev/null
+++ b/arch/arm/mach-clps711x/devices.h
@@ -0,0 +1,12 @@
+/*
+ *  CLPS711X common devices definitions
+ *
+ *  Copyright (C) 2013 Alexander Shiyan <shc_work at mail.ru>
+ *
+ * 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.
+ */
+
+void clps711x_devices_init(void);
-- 
1.8.1.5



From tony at atomide.com  Fri Apr 26 11:51:38 2013
From: tony at atomide.com (Tony Lindgren)
Date: Fri, 26 Apr 2013 08:51:38 -0700
Subject: [PATCH 1/3] ARM: OMAP2+: Legacy support for wl12xx when booted
 with devicetree
In-Reply-To: <0104F687-1726-476D-B2DF-7E72223B127A@dominion.thruhere.net>
References: <20130426034858.26065.65118.stgit@muffinssi.local>
 <20130426035210.26065.39995.stgit@muffinssi.local>
 <0104F687-1726-476D-B2DF-7E72223B127A@dominion.thruhere.net>
Message-ID: <20130426155138.GB29360@atomide.com>

* Koen Kooi <koen at dominion.thruhere.net> [130426 02:39]:
> 
> Op 26 apr. 2013, om 05:52 heeft Tony Lindgren <tony at atomide.com> het volgende geschreven:
> 
> > Without WLAN we cannot switch omap4 to use device tree
> > only booting. This patch can be reverted when the
> > binding for wl12xx is added.
> 
> How much boards am I allowed to add to this? I need to get the wl12xx wifi expansionboards for beagleboard, beagleboard xM and beaglebone working with DT :)

As long as it's trivial changes, go for it. It will be
gone after we have the binding for wl12xx.

But let's not add the bluetooth serial port hack.. And
let's not churn the board-*.c files, at this point pretty
much the next step is to start dropping the board-*.c
files.

Regards,

Tony


From stefano.stabellini at eu.citrix.com  Fri Apr 26 11:36:37 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Fri, 26 Apr 2013 16:36:37 +0100
Subject: [PATCH v8 2/2] ARM: Enable selection of SMP operations at boot
 time
In-Reply-To: <alpine.LFD.2.03.1304251040430.1258@syhkavp.arg>
References: <alpine.DEB.2.02.1304241935010.4180@kaball.uk.xensource.com>
 <1366828819-10745-2-git-send-email-stefano.stabellini@eu.citrix.com>
 <20130425084933.GB12848@mudshark.cambridge.arm.com>
 <alpine.LFD.2.03.1304251040430.1258@syhkavp.arg>
Message-ID: <alpine.DEB.2.02.1304261629300.4180@kaball.uk.xensource.com>

On Thu, 25 Apr 2013, Nicolas Pitre wrote:
> On Thu, 25 Apr 2013, Will Deacon wrote:
> 
> > On Wed, Apr 24, 2013 at 07:40:19PM +0100, Stefano Stabellini wrote:
> > > From: Jon Medhurst <tixy at linaro.org>
> > > 
> > > Add a new 'smp_init' hook to machine_desc so platforms can specify a
> > > function to be used to setup smp ops instead of having a statically
> > > defined value.  The hook must return true when smp_ops are initialized.
> > > If false the static mdesc->smp_ops will be used by default.
> > > 
> > > Signed-off-by: Jon Medhurst <tixy at linaro.org>
> > > Signed-off-by: Nicolas Pitre <nicolas.pitre at linaro.org>
> > > Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
> > > Reviewed-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
> > > ---
> > >  arch/arm/include/asm/mach/arch.h |    4 ++++
> > >  arch/arm/kernel/setup.c          |   10 ++++++----
> > >  2 files changed, 10 insertions(+), 4 deletions(-)
> > 
> > [...]
> > 
> > >  	if (is_smp()) {
> > > -		if (psci_smp_available())
> > > -			smp_set_ops(&psci_smp_ops);
> > > -		else if (mdesc->smp)
> > > -			smp_set_ops(mdesc->smp);
> > > +		if (!mdesc->smp_init || !mdesc->smp_init()) {
> > 
> > Minor nit, but this feels backwards to me. We usually return 0 on success,
> > yet we're saying here that if mdesc->smp_init() returns 0, then we go and
> > override the smp ops.
> 
> It doesn't return 0, but true or false.  So, semantically, if ->smp_init 
> returns false, that means it didn't initialize anything.

In absence of other comments, I am going to leave as it is now.


From stefano.stabellini at eu.citrix.com  Fri Apr 26 11:36:26 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Fri, 26 Apr 2013 16:36:26 +0100
Subject: [PATCH v8 1/2] arm: introduce psci_smp_ops
In-Reply-To: <alpine.LFD.2.03.1304251054420.1258@syhkavp.arg>
References: <alpine.DEB.2.02.1304241935010.4180@kaball.uk.xensource.com>
 <1366828819-10745-1-git-send-email-stefano.stabellini@eu.citrix.com>
 <20130425084711.GA12848@mudshark.cambridge.arm.com>
 <alpine.DEB.2.02.1304251104090.4180@kaball.uk.xensource.com>
 <20130425104508.GG12848@mudshark.cambridge.arm.com>
 <alpine.LFD.2.03.1304251054420.1258@syhkavp.arg>
Message-ID: <alpine.DEB.2.02.1304261630110.4180@kaball.uk.xensource.com>

On Thu, 25 Apr 2013, Nicolas Pitre wrote:
> On Thu, 25 Apr 2013, Will Deacon wrote:
> 
> > On Thu, Apr 25, 2013 at 11:12:54AM +0100, Stefano Stabellini wrote:
> > > On Thu, 25 Apr 2013, Will Deacon wrote:
> > > > > +/*
> > > > > + * cpu_suspend   Suspend the execution on a CPU
> > > > > + * @state        we don't currently describe affinity levels, so just pass 0.
> > > > > + * @entry_point  the first instruction to be executed on return
> > > > > + * returns 0  success, < 0 on failure
> > > > > + *
> > > > > + * cpu_off       Power down a CPU
> > > > > + * @state        we don't currently describe affinity levels, so just pass 0.
> > > > > + * no return on successful call
> > > > > + *
> > > > > + * cpu_on        Power up a CPU
> > > > > + * @cpuid        cpuid of target CPU, as from MPIDR
> > > > > + * @entry_point  the first instruction to be executed on return
> > > > > + * returns 0  success, < 0 on failure
> > > > > + *
> > > > > + * migrate       Migrate the context to a different CPU
> > > > > + * @cpuid        cpuid of target CPU, as from MPIDR
> > > > > + * returns 0  success, < 0 on failure
> > > > > + *
> > > > > + */
> > > > 
> > > > Can you move these comments into psci-smp.c please? They're really specific
> > > > to the implementation there, and if we put them in a header we're lying to
> > > > ourselves about the parameters actually described by the PSCI specification.
> > > 
> > > You have a good point about the PSCI spec.
> > > 
> > > However from the Linux POV these comments should regard the functions
> > > exported by psci_operations, not the firmware interface, this is why I
> > > think it makes sense to keep them in psci.h.
> > > What we are saying is for example that psci_operations.cpu_on returns 0
> > > on success and < 0 on failure, and it takes a cpuid and an entry point
> > > as parameters. We are not saying anything about the firmware interface.
> > 
> > I disagree. You're explicitly stating that we pass the `cpuid of target CPU,
> > as from MPIDR'. That's simply not true -- the firmware could choose any
> > numbering scheme to identify the CPUs. For KVM and Xen, it *is* the mpidr,
> > which is why psci-smp.c works at all, but that's where the comment belongs,
> > not in this header file.
> 
> At some point, the _kernel_ API for interfacing with the firmware's PSCI 
> will have to ensure uniformity somehow.  The PSCI interface code could 
> translate the passed MPIDR into whatever the firmware decided to use for 
> identifying CPUs if needed, keeping this issue localized.

That is what I had in mind when I said to keep the comment in psci.h
before.
We have to draw the line somewhere to expose a uniform internal kernel
API. However it is a bit difficult to do now given that we have only one
user of the API.

I don't feel to strongly about this, please let me know what is the
final decision and I'll update the code accordingly. I remind you that
the merge window is approaching :-)



From marc.zyngier at arm.com  Fri Apr 26 11:54:01 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Fri, 26 Apr 2013 16:54:01 +0100
Subject: [PATCH 0/2] Early printk support for virtio console devices.
In-Reply-To: <201304261703.17798.arnd@arndb.de>
References: <1366974299-17877-1-git-send-email-pranavkumar@linaro.org>
 <1577576.O1Cm2pf5KD@wuerfel>
 <CALrVBkuyby_KY_M+yp0e=PLk=7_W_kSxxm62YYSwwp8rwLsCAQ@mail.gmail.com>
 <201304261703.17798.arnd@arndb.de>
Message-ID: <517AA319.5070709@arm.com>

On 26/04/13 16:03, Arnd Bergmann wrote:
> On Friday 26 April 2013, Anup Patel wrote:
>> I am curious about how smh-based or hypercall-based early prints would
>> be handled in following scenario:
>>
>> "A board is running KVM ARM enabled kernel and linux console on serial
>> port. Now a user remotely connects to the board via telnet/ssh and
>> launches a VM with smh-based or hypercall-based earlyprintk."
>>
>> In the above scenario, will smh-based or hypercall-based earlyprints
>> appear to user on remote shell or not ?
> 
> The implementation of the console device would still be done by KVM,
> as for any other virtual device, so it shows up whereever kvm is
> configured to output the console data.

Actually, at least in the case of smh-based earlyprintk, the output only
appears in the model console, and never reach the rest of the kernel.

And any other non-MMIO approach (like a hypercall) will be very hard to
feed back to the console, as KVM itself has no idea of what a "console"
is. You'd need another side channel to userspace, hoping that it will be
able to merge the multiple streams.

	M.
-- 
Jazz is not dead. It just smells funny...



From vincent.guittot at linaro.org  Fri Apr 26 11:56:32 2013
From: vincent.guittot at linaro.org (Vincent Guittot)
Date: Fri, 26 Apr 2013 17:56:32 +0200
Subject: [RFC PATCH v4 00/14] sched: packing small tasks
In-Reply-To: <517AA14D.7060202@linux.intel.com>
References: <1366910611-20048-1-git-send-email-vincent.guittot@linaro.org>
 <517A969B.5040606@linux.intel.com>
 <CAKfTPtCwdw1mYpWRFbPo9zT=9vFANpJyubh1eX-0vJLqrqizgA@mail.gmail.com>
 <517AA14D.7060202@linux.intel.com>
Message-ID: <CAKfTPtAx92rpuV2AsZ1n4CxeAMZPkv9TBR_058TVqYuiG0ejmA@mail.gmail.com>

On 26 April 2013 17:46, Arjan van de Ven <arjan at linux.intel.com> wrote:
>>>
>>>
>>> so I got to ask the hard question; what percentage of system level (not
>>> just
>>> cpu level)
>>> power consumption gain can you measure (pick your favorite workload)...
>>>
>>
>> I haven't system level figures for my patches but only for the cpu
>> subsystem. If we use the MP3 results in the back of my mail, they show
>> an improvement of 37 % (113/178) for the CPU subsystem of the
>> platform. If we assume that the CPU subsystem contributes 25% of an
>> embedded system power consumption (this can vary across platform
>> depending of the use of HW accelerator but it should be a almost fair
>> percentage), the patch can impact the power consumption on up to 9%.
>>
>
> sadly the math tends to not work quite that easy;
> memory takes significantly more power when the system is not idle than when
> it is idle for example. [*]
> so while reducing cpu power by making it run a bit longer (at lower
> frequency or
> slower core or whatever) is a pure win if you only look at the cpu, but it
> may
> (or may not) be a loss when looking at a whole system level.

I agree. That's why the default packing mode of the patches is trying
to not increase (too much) the scheduling latency of tasks but only to
force tasks to use the same cpu when ever possible in order to
minimize the number CPU/cluster that are used

>
> I've learned the hard way that you cannot just look at the cpu numbers; you
> must look
> at the whole-system power when playing with such tradeoffs.
>
> That does not mean that your patch is not useful; it very well can be, but
> without having looked at whole-system power that's a very dangerous
> conclusion to make.
> So.. if you get a chance, I'd love to see data on a whole-system level...
> even for just one workload
> and one system
> (playing mp3 sounds like a quite reasonable workload for such things indeed)

I will try to get such figures

Vincent
>
>
> [*] I assume that on your ARM systems, memory goes into self refresh during
> system idle just as it does on x86
>


From tony at atomide.com  Fri Apr 26 11:58:44 2013
From: tony at atomide.com (Tony Lindgren)
Date: Fri, 26 Apr 2013 08:58:44 -0700
Subject: [PATCH 2/3] ARM: dts: Add muxing for wl12xx on the SDIO bus
 for pandaboard
In-Reply-To: <1366982603.4029.42.camel@cumari.coelho.fi>
References: <20130426034858.26065.65118.stgit@muffinssi.local>
 <20130426035213.26065.63243.stgit@muffinssi.local>
 <1366982603.4029.42.camel@cumari.coelho.fi>
Message-ID: <20130426155844.GC29360@atomide.com>

* Luciano Coelho <coelho at ti.com> [130426 06:29]:
> On Thu, 2013-04-25 at 20:52 -0700, Tony Lindgren wrote:
> > This is needed to get wl12xx working with device tree based
> > booting.
> > 
> > Note that we claim the various GPIO inputs in the regulator
> > as the proper muxing is needed to enable and disable the
> > regulator.
> > 
> > Also, we want to use non-removable instead of ti,non-removable
> > as the ti,non-removable also sets no_regulator_off_init which
> > is really not what we want as then wl12xx won't get powered
> > up and down which is needed for resetting it.
> > 
> > Cc: Luciano Coelho <coelho at ti.com>
> > Cc: Benoit Cousson <b-cousson at ti.com>
> > Cc: Rajendra Nayak <rnayak at ti.com>
> > Cc: devicetree-discuss at lists.ozlabs.org
> > Signed-off-by: Tony Lindgren <tony at atomide.com>
> > ---
> 
> I tried this now and it seems to work fine too.  So:
> 
> Tested-by: Luciano Coelho <coelho at ti.com>
> 
> Except that with linux-next I'm getting some problems with the
> interrupts when trying to use wl12xx.  It's not related to this patch
> though, and I'm investigating it right now.

One thing I was worried is the early use of gpio_to_irq()
that's probably not safe always. We could fix that by moving the
gpio_to_irq() call to the driver if that's a problem.

But if the gpio_to_irq() is not the issue, can you please just
add a minimal binding to the wl12xx code so we can get rid of the
pdata init for the DT booting?

We can pass the clock reference the same way as we've discussed
already regarding the USB transceiver patch. Or you might be able
to find it out in the driver probe just by doing clk_get() and
clk_get_rate() on the source clock.

And the GPIO is just a standard resource that already has a
binding.
 
> Also, I found one small whitespace problem in this patch:
> 
> [...]
> > +	/* wl12xx GPIO inputs and SDIO pins */
> > +	wl12xx_pins: pinmux_wl12xx_pins {
> > +		pinctrl-single,pins = <
> > +			0x38 0x103	/* gpmc_ncs2.gpio_52 INPUT | MODE3 */
> > +			0x3a 0x103	/* gpmc_ncs3.gpio_53 INPUT | MODE3 */
> > +			0x108 0x118	/* sdmmc5_clk.sdmmc5_clk INPUT_PULLUP | MODE0 */
> > +			0x10a 0x118	/* sdmmc5_cmd.sdmmc5_cmd INPUT_PULLUP | MODE0 */
> > +			0x10c 0x118	/* sdmmc5_dat0.sdmmc5_dat0 INPUT_PULLUP | MODE0 */
> > +			0x10e 0x118	/* sdmmc5_dat1.sdmmc5_dat1 INPUT_PULLUP | MODE0 */
> > +			0x110 0x118	/* sdmmc5_dat2.sdmmc5_dat2 INPUT_PULLUP | MODE0 */
> > +			0x112 0x118	/* sdmmc5_dat3.sdmmc5_dat3 INPUT_PULLUP | MODE0 */
> > +      		>;
> 
> git am reports a "space before tab in indent" here.

OK thanks, will fix.

Regards,

Tony


From tony at atomide.com  Fri Apr 26 12:04:01 2013
From: tony at atomide.com (Tony Lindgren)
Date: Fri, 26 Apr 2013 09:04:01 -0700
Subject: [PATCH 0/3] WLAN support for omap4 when booted with devicetree
In-Reply-To: <1366957908.4029.15.camel@cumari.coelho.fi>
References: <20130426034858.26065.65118.stgit@muffinssi.local>
 <1366957908.4029.15.camel@cumari.coelho.fi>
Message-ID: <20130426160400.GD29360@atomide.com>

* Luciano Coelho <coelho at ti.com> [130425 23:38]:
> On Thu, 2013-04-25 at 20:52 -0700, Tony Lindgren wrote:
> > Hi all,
> 
> Hi Tony,
> 
> 
> > Here are some patches against linux next to make WLAN to work with
> > device tree. Note that we still are initializing wl12xx with pdata,
> > but so far it looks like only minimal binding for it is needed.
> 
> Thanks for doing this! I've been out on vacation for the past 3 weeks,
> so I didn't manage to finish the wl12xx DT stuff in time for 3.10. :(

OK I was wondering what happened.. 
 
> > There are various fixes pending posted recently, but at least the
> > fix "[PATCH] mmc: omap_hsmmc: Fix the DT pbias workaround for MMC
> > controllers 2 to 5" is needed.
> 
> I managed to apply the OMAP2+ and the blaze patches.  There were
> conflicts with the panda patch, so I skipped it for now.  I'll come back
> to it a bit later.

OK 
 
> > Please test on blaze/sdp if you have a chance, I don't have the
> > connectivity card on mine.
> 
> I tested this on Blaze and it seems to work fine! The driver gets probed
> and I can power the chip on and off (by putting the interface up and
> down) without any problems. :)

OK great thanks! It took me few hours of debugging to figure out that
it does not work on my blaze as I did not have the wl12xx card in it :)

Also can you fill in the missing GPIO lines for blaze from the schematics?
 
> BTW, did you (or anyone else) manage to get ethernet to work on Blaze
> (or Panda) with DT?

Yes that needs the two GPIO fixes posted by Jon Hunter last week.
One for patching in the GPIO trigger type to both omap4-sdp.dts, and
the other one is "gpio/omap: ensure gpio context is initialised".

Regards,

Tony


From will.deacon at arm.com  Fri Apr 26 12:10:12 2013
From: will.deacon at arm.com (Will Deacon)
Date: Fri, 26 Apr 2013 17:10:12 +0100
Subject: [PATCH v8 1/2] arm: introduce psci_smp_ops
In-Reply-To: <alpine.DEB.2.02.1304261630110.4180@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1304241935010.4180@kaball.uk.xensource.com>
 <1366828819-10745-1-git-send-email-stefano.stabellini@eu.citrix.com>
 <20130425084711.GA12848@mudshark.cambridge.arm.com>
 <alpine.DEB.2.02.1304251104090.4180@kaball.uk.xensource.com>
 <20130425104508.GG12848@mudshark.cambridge.arm.com>
 <alpine.LFD.2.03.1304251054420.1258@syhkavp.arg>
 <alpine.DEB.2.02.1304261630110.4180@kaball.uk.xensource.com>
Message-ID: <20130426161012.GH30858@mudshark.cambridge.arm.com>

On Fri, Apr 26, 2013 at 04:36:26PM +0100, Stefano Stabellini wrote:
> On Thu, 25 Apr 2013, Nicolas Pitre wrote:
> > On Thu, 25 Apr 2013, Will Deacon wrote:
> > > I disagree. You're explicitly stating that we pass the `cpuid of target CPU,
> > > as from MPIDR'. That's simply not true -- the firmware could choose any
> > > numbering scheme to identify the CPUs. For KVM and Xen, it *is* the mpidr,
> > > which is why psci-smp.c works at all, but that's where the comment belongs,
> > > not in this header file.
> > 
> > At some point, the _kernel_ API for interfacing with the firmware's PSCI 
> > will have to ensure uniformity somehow.  The PSCI interface code could 
> > translate the passed MPIDR into whatever the firmware decided to use for 
> > identifying CPUs if needed, keeping this issue localized.
> 
> That is what I had in mind when I said to keep the comment in psci.h
> before.
> We have to draw the line somewhere to expose a uniform internal kernel
> API. However it is a bit difficult to do now given that we have only one
> user of the API.

I see psci.h as representing the firmware interface, and psci-smp.c or
whatever sits on top as exposing the kernel `API'.

> I don't feel to strongly about this, please let me know what is the
> final decision and I'll update the code accordingly. I remind you that
> the merge window is approaching :-)

I'd still like the comment to be in psci-smp.c, or a header separate from
the firmware bits.

Will


From g.liakhovetski at gmx.de  Fri Apr 26 12:27:44 2013
From: g.liakhovetski at gmx.de (Guennadi Liakhovetski)
Date: Fri, 26 Apr 2013 18:27:44 +0200
Subject: [PATCH 3/6] ARM: shmobile: sh73a0: remove "0x" prefix from DT node
 names
In-Reply-To: <1366993667-23294-1-git-send-email-g.liakhovetski@gmx.de>
References: <1366993667-23294-1-git-send-email-g.liakhovetski@gmx.de>
Message-ID: <1366993667-23294-4-git-send-email-g.liakhovetski@gmx.de>

The convention for Device Tree node names is <device>@<hex-address>, where
the part after '@' shouldn't contain the "0x" prefix. Fix the sh73a0.dtsi
DT names.

Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas at gmail.com>
---
 arch/arm/boot/dts/sh73a0.dtsi |   18 +++++++++---------
 1 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/arch/arm/boot/dts/sh73a0.dtsi b/arch/arm/boot/dts/sh73a0.dtsi
index 039205c..eaa9171 100644
--- a/arch/arm/boot/dts/sh73a0.dtsi
+++ b/arch/arm/boot/dts/sh73a0.dtsi
@@ -155,7 +155,7 @@
 		dma-requests = <256>;
 	};
 
-	i2c0: i2c at 0xe6820000 {
+	i2c0: i2c at e6820000 {
 		#address-cells = <1>;
 		#size-cells = <0>;
 		compatible = "renesas,rmobile-iic";
@@ -167,7 +167,7 @@
 			      0 170 0x4>;
 	};
 
-	i2c1: i2c at 0xe6822000 {
+	i2c1: i2c at e6822000 {
 		#address-cells = <1>;
 		#size-cells = <0>;
 		compatible = "renesas,rmobile-iic";
@@ -179,7 +179,7 @@
 			      0 54 0x4>;
 	};
 
-	i2c2: i2c at 0xe6824000 {
+	i2c2: i2c at e6824000 {
 		#address-cells = <1>;
 		#size-cells = <0>;
 		compatible = "renesas,rmobile-iic";
@@ -191,7 +191,7 @@
 			      0 174 0x4>;
 	};
 
-	i2c3: i2c at 0xe6826000 {
+	i2c3: i2c at e6826000 {
 		#address-cells = <1>;
 		#size-cells = <0>;
 		compatible = "renesas,rmobile-iic";
@@ -203,7 +203,7 @@
 			      0 186 0x4>;
 	};
 
-	i2c4: i2c at 0xe6828000 {
+	i2c4: i2c at e6828000 {
 		#address-cells = <1>;
 		#size-cells = <0>;
 		compatible = "renesas,rmobile-iic";
@@ -226,7 +226,7 @@
 		renesas,event-quality = <3>;
 	};
 
-	mmcif: mmcif at 0x10010000 {
+	mmcif: mmcif at e6bd0000 {
 		compatible = "renesas,sh-mmcif";
 		reg = <0xe6bd0000 0x100>;
 		interrupt-parent = <&gic>;
@@ -236,7 +236,7 @@
 		status = "disabled";
 	};
 
-	sdhi0: sdhi at 0xee100000 {
+	sdhi0: sdhi at ee100000 {
 		compatible = "renesas,r8a7740-sdhi";
 		reg = <0xee100000 0x100>;
 		interrupt-parent = <&gic>;
@@ -248,7 +248,7 @@
 	};
 
 	/* SDHI1 and SDHI2 have no CD pins, no need for CD IRQ */
-	sdhi1: sdhi at 0xee120000 {
+	sdhi1: sdhi at ee120000 {
 		compatible = "renesas,r8a7740-sdhi";
 		reg = <0xee120000 0x100>;
 		interrupt-parent = <&gic>;
@@ -259,7 +259,7 @@
 		status = "disabled";
 	};
 
-	sdhi2: sdhi at 0xee140000 {
+	sdhi2: sdhi at ee140000 {
 		compatible = "renesas,r8a7740-sdhi";
 		reg = <0xee140000 0x100>;
 		interrupt-parent = <&gic>;
-- 
1.7.2.5



From g.liakhovetski at gmx.de  Fri Apr 26 12:27:43 2013
From: g.liakhovetski at gmx.de (Guennadi Liakhovetski)
Date: Fri, 26 Apr 2013 18:27:43 +0200
Subject: [PATCH 2/6] ARM: shmobile: add SDHI and MMCIF interfaces to
 armadillo800eva-reference
In-Reply-To: <1366993667-23294-1-git-send-email-g.liakhovetski@gmx.de>
References: <1366993667-23294-1-git-send-email-g.liakhovetski@gmx.de>
Message-ID: <1366993667-23294-3-git-send-email-g.liakhovetski@gmx.de>

Add SDHI0, SDHI1 and MMCIF interfaces to armadillo800eva-reference. With
no pinctrl DT support we cannot use GPIO card-detection and regulator
switching.

Signed-off-by: Guennadi Liakhovetski <g.liakhovetski at gmx.de>
---
 .../boot/dts/r8a7740-armadillo800eva-reference.dts |   21 +++++++++++-
 arch/arm/boot/dts/r8a7740.dtsi                     |   33 ++++++++++++++++++
 .../board-armadillo800eva-reference.c              |   36 +++++++++++++++++++-
 3 files changed, 88 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7740-armadillo800eva-reference.dts b/arch/arm/boot/dts/r8a7740-armadillo800eva-reference.dts
index 09ea22c..3752637 100644
--- a/arch/arm/boot/dts/r8a7740-armadillo800eva-reference.dts
+++ b/arch/arm/boot/dts/r8a7740-armadillo800eva-reference.dts
@@ -32,7 +32,6 @@
 		regulator-always-on;
 		regulator-boot-on;
 	};
-
 };
 
 &i2c0 {
@@ -43,3 +42,23 @@
 		interrupts = <2 0>; /* IRQ10: hwirq 2 on irqpin1 */
 	};
 };
+
+&mmcif0 {
+	vmmc-supply = <&reg_3p3v>;
+	bus-width = <8>;
+	non-removable;
+	status = "okay";
+};
+
+&sdhi0 {
+	vmmc-supply = <&reg_3p3v>;
+	bus-width = <4>;
+	broken-cd;
+	status = "okay";
+};
+
+&sdhi1 {
+	vmmc-supply = <&reg_3p3v>;
+	bus-width = <4>;
+	status = "okay";
+};
diff --git a/arch/arm/boot/dts/r8a7740.dtsi b/arch/arm/boot/dts/r8a7740.dtsi
index 25dc930..e9a90d8 100644
--- a/arch/arm/boot/dts/r8a7740.dtsi
+++ b/arch/arm/boot/dts/r8a7740.dtsi
@@ -135,4 +135,37 @@
 			      0 72 0x4
 			      0 73 0x4>;
 	};
+
+	mmcif0: mmcif at e6bd0000 {
+		compatible = "renesas,sh-mmcif", "renesas,sh7372-mmcif";
+		reg = <0xe6bd0000 0x100>;
+		interrupt-parent = <&gic>;
+		interrupts = <0 56 4
+				0 57 4>;
+		status = "disabled";
+	};
+
+	sdhi0: sdhi at e6850000 {
+		compatible = "renesas,r8a7740-sdhi";
+		reg = <0xe6850000 0x100>;
+		interrupt-parent = <&gic>;
+		interrupts = <0 117 4
+				0 118 4
+				0 119 4>;
+		cap-sd-highspeed;
+		cap-sdio-irq;
+		status = "disabled";
+	};
+
+	sdhi1: sdhi at e6860000 {
+		compatible = "renesas,r8a7740-sdhi";
+		reg = <0xe6860000 0x100>;
+		interrupt-parent = <&gic>;
+		interrupts = <0 121 4
+				0 122 4
+				0 123 4>;
+		cap-sd-highspeed;
+		cap-sdio-irq;
+		status = "disabled";
+	};
 };
diff --git a/arch/arm/mach-shmobile/board-armadillo800eva-reference.c b/arch/arm/mach-shmobile/board-armadillo800eva-reference.c
index 03b85fe..d26a9da 100644
--- a/arch/arm/mach-shmobile/board-armadillo800eva-reference.c
+++ b/arch/arm/mach-shmobile/board-armadillo800eva-reference.c
@@ -123,6 +123,27 @@ static const struct pinctrl_map eva_pinctrl_map[] = {
 	/* SCIFA1 */
 	PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.1", "pfc-r8a7740",
 				  "scifa1_data", "scifa1"),
+	/* MMCIF */
+	PIN_MAP_MUX_GROUP_DEFAULT("e6bd0000.sh-mmcif", "pfc-r8a7740",
+				  "mmc0_data8_1", "mmc0"),
+	PIN_MAP_MUX_GROUP_DEFAULT("e6bd0000.sh-mmcif", "pfc-r8a7740",
+				  "mmc0_ctrl_1", "mmc0"),
+	/* SDHI0 */
+	PIN_MAP_MUX_GROUP_DEFAULT("e6850000.sdhi", "pfc-r8a7740",
+				  "sdhi0_data4", "sdhi0"),
+	PIN_MAP_MUX_GROUP_DEFAULT("e6850000.sdhi", "pfc-r8a7740",
+				  "sdhi0_ctrl", "sdhi0"),
+	PIN_MAP_MUX_GROUP_DEFAULT("e6850000.sdhi", "pfc-r8a7740",
+				  "sdhi0_wp", "sdhi0"),
+	/* SDHI1 */
+	PIN_MAP_MUX_GROUP_DEFAULT("e6860000.sdhi", "pfc-r8a7740",
+				  "sdhi1_data4", "sdhi1"),
+	PIN_MAP_MUX_GROUP_DEFAULT("e6860000.sdhi", "pfc-r8a7740",
+				  "sdhi1_ctrl", "sdhi1"),
+	PIN_MAP_MUX_GROUP_DEFAULT("e6860000.sdhi", "pfc-r8a7740",
+				  "sdhi1_cd", "sdhi1"),
+	PIN_MAP_MUX_GROUP_DEFAULT("e6860000.sdhi", "pfc-r8a7740",
+				  "sdhi1_wp", "sdhi1"),
 };
 
 static void __init eva_clock_init(void)
@@ -165,7 +186,6 @@ clock_error:
  */
 static void __init eva_init(void)
 {
-
 	r8a7740_clock_init(MD_CK0 | MD_CK2);
 	eva_clock_init();
 
@@ -180,6 +200,20 @@ static void __init eva_init(void)
 	 */
 	gpio_request_one(166, GPIOF_OUT_INIT_HIGH, NULL); /* TP_RST_B */
 
+	/* SDHI0 */
+	gpio_request_one(17, GPIOF_OUT_INIT_LOW, NULL);  /* SDHI0_18/33_B */
+	gpio_request_one(74, GPIOF_OUT_INIT_HIGH, NULL); /* SDHI0_PON */
+	gpio_request_one(75, GPIOF_OUT_INIT_HIGH, NULL); /* SDSLOT1_PON */
+
+	/* We can switch CON8/CON14 by SW1.5, but only after DBGMD_SELECT_B */
+	gpio_request_one(6, GPIOF_IN, NULL);
+	if (!gpio_get_value(6)) {
+		/* CON14 disabled, CON8 (SDHI1) enabled */
+
+		/* SDSLOT2_PON */
+		gpio_request_one(16, GPIOF_OUT_INIT_HIGH, NULL);
+	}
+
 #ifdef CONFIG_CACHE_L2X0
 	/* Early BRESP enable, Shared attribute override enable, 32K*8way */
 	l2x0_init(IOMEM(0xf0002000), 0x40440000, 0x82000fff);
-- 
1.7.2.5



From g.liakhovetski at gmx.de  Fri Apr 26 12:27:41 2013
From: g.liakhovetski at gmx.de (Guennadi Liakhovetski)
Date: Fri, 26 Apr 2013 18:27:41 +0200
Subject: [PATCH 0/6] ARM: shmobile: r8a7740: add MMCIF and SDHI to DT
Message-ID: <1366993667-23294-1-git-send-email-g.liakhovetski@gmx.de>

These patches add DT support for MMCIF and SDHI including DMA on 
armadillo800eva-reference r8a7740 board. They require my previous 
SHDMA DT and SDHI and MMCIF DMA patches.

Cc: Guennadi Liakhovetski <g.liakhovetski+renesas at gmail.com>

Guennadi Liakhovetski (6):
  ARM: shmobile: armadillo800eva: remove left-overs
  ARM: shmobile: add SDHI and MMCIF interfaces to
    armadillo800eva-reference
  ARM: shmobile: sh73a0: remove "0x" prefix from DT node names
  ARM: shmobile: r8a7740: add MMCIF DMA definitions
  ARM: shmobile: r8a7740: add DT node for one DMAC instance
  ARM: shmobile: armadillo800eva-reference: add DMA support for MMCIF
    and SDHI

 .../boot/dts/r8a7740-armadillo800eva-reference.dts |   30 +++++++++++-
 arch/arm/boot/dts/r8a7740.dtsi                     |   53 ++++++++++++++++++++
 arch/arm/boot/dts/sh73a0.dtsi                      |   18 +++---
 .../board-armadillo800eva-reference.c              |   36 +++++++++++++-
 arch/arm/mach-shmobile/board-armadillo800eva.c     |    9 ---
 arch/arm/mach-shmobile/include/mach/r8a7740.h      |    2 +
 arch/arm/mach-shmobile/setup-r8a7740.c             |   12 +++++
 7 files changed, 140 insertions(+), 20 deletions(-)

-- 
1.7.2.5

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/


From g.liakhovetski at gmx.de  Fri Apr 26 12:27:46 2013
From: g.liakhovetski at gmx.de (Guennadi Liakhovetski)
Date: Fri, 26 Apr 2013 18:27:46 +0200
Subject: [PATCH 5/6] ARM: shmobile: r8a7740: add DT node for one DMAC instance
In-Reply-To: <1366993667-23294-1-git-send-email-g.liakhovetski@gmx.de>
References: <1366993667-23294-1-git-send-email-g.liakhovetski@gmx.de>
Message-ID: <1366993667-23294-6-git-send-email-g.liakhovetski@gmx.de>

This patch adds  Device Tree support for the first (#0) DMA controller
instance on r8a7740. We want to add further DMA controller DT nodes in
a DMA multiplexer node, which isn't implemented yet. Further DMAC
instances will be added after the DMA multiplexer support is done.

Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas at gmail.com>
---
 arch/arm/boot/dts/r8a7740.dtsi         |   20 ++++++++++++++++++++
 arch/arm/mach-shmobile/setup-r8a7740.c |    2 ++
 2 files changed, 22 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7740.dtsi b/arch/arm/boot/dts/r8a7740.dtsi
index e9a90d8..054bc1a 100644
--- a/arch/arm/boot/dts/r8a7740.dtsi
+++ b/arch/arm/boot/dts/r8a7740.dtsi
@@ -112,6 +112,26 @@
 			      0 149 0x4>;
 	};
 
+	dma0: shdma at fe008020 {
+		compatible = "renesas,shdma";
+		reg = <0xfe008020 0x270
+			0xfe009000 0xc>;
+		interrupt-parent = <&gic>;
+		interrupts = <0 34 4
+				0 28 4
+				0 29 4
+				0 30 4
+				0 31 4
+				0 32 4
+				0 33 4>;
+		interrupt-names = "error",
+				"ch0", "ch1", "ch2", "ch3",
+				"ch4", "ch5";
+		#dma-cells = <1>;
+		dma-channels = <6>;
+		dma-requests = <256>;
+	};
+
 	i2c0: i2c at fff20000 {
 		#address-cells = <1>;
 		#size-cells = <0>;
diff --git a/arch/arm/mach-shmobile/setup-r8a7740.c b/arch/arm/mach-shmobile/setup-r8a7740.c
index 6b3ed42..7781d3b 100644
--- a/arch/arm/mach-shmobile/setup-r8a7740.c
+++ b/arch/arm/mach-shmobile/setup-r8a7740.c
@@ -997,6 +997,8 @@ void __init r8a7740_add_early_devices(void)
 #ifdef CONFIG_USE_OF
 
 static const struct of_dev_auxdata r8a7740_auxdata_lookup[] __initconst = {
+	OF_DEV_AUXDATA("renesas,shdma", 0xfe008020, "sh-dma-engine.0",
+		       &r8a7740_dma_platform_data),
 	{ }
 };
 
-- 
1.7.2.5



From g.liakhovetski at gmx.de  Fri Apr 26 12:27:42 2013
From: g.liakhovetski at gmx.de (Guennadi Liakhovetski)
Date: Fri, 26 Apr 2013 18:27:42 +0200
Subject: [PATCH 1/6] ARM: shmobile: armadillo800eva: remove left-overs
In-Reply-To: <1366993667-23294-1-git-send-email-g.liakhovetski@gmx.de>
References: <1366993667-23294-1-git-send-email-g.liakhovetski@gmx.de>
Message-ID: <1366993667-23294-2-git-send-email-g.liakhovetski@gmx.de>

A comment and a #define in board-armadillo800eva.c have been left over
after recent changes and are no longer relevant or needed, remove them.

Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas at gmail.com>
---
 arch/arm/mach-shmobile/board-armadillo800eva.c |    9 ---------
 1 files changed, 0 insertions(+), 9 deletions(-)

diff --git a/arch/arm/mach-shmobile/board-armadillo800eva.c b/arch/arm/mach-shmobile/board-armadillo800eva.c
index ff04d1e..acfc267 100644
--- a/arch/arm/mach-shmobile/board-armadillo800eva.c
+++ b/arch/arm/mach-shmobile/board-armadillo800eva.c
@@ -673,15 +673,6 @@ static struct platform_device vcc_sdhi1 = {
 };
 
 /* SDHI0 */
-/*
- * FIXME
- *
- * It use polling mode here, since
- * CD (= Card Detect) pin is not connected to SDHI0_CD.
- * We can use IRQ31 as card detect irq,
- * but it needs chattering removal operation
- */
-#define IRQ31	irq_pin(31)
 static struct sh_mobile_sdhi_info sdhi0_info = {
 	.dma_slave_tx	= SHDMA_SLAVE_SDHI0_TX,
 	.dma_slave_rx	= SHDMA_SLAVE_SDHI0_RX,
-- 
1.7.2.5



From g.liakhovetski at gmx.de  Fri Apr 26 12:27:45 2013
From: g.liakhovetski at gmx.de (Guennadi Liakhovetski)
Date: Fri, 26 Apr 2013 18:27:45 +0200
Subject: [PATCH 4/6] ARM: shmobile: r8a7740: add MMCIF DMA definitions
In-Reply-To: <1366993667-23294-1-git-send-email-g.liakhovetski@gmx.de>
References: <1366993667-23294-1-git-send-email-g.liakhovetski@gmx.de>
Message-ID: <1366993667-23294-5-git-send-email-g.liakhovetski@gmx.de>

Add DMA channel slave IDs and configuration entries for the r8a7740
MMCIF controller.

Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas at gmail.com>
---
 arch/arm/mach-shmobile/include/mach/r8a7740.h |    2 ++
 arch/arm/mach-shmobile/setup-r8a7740.c        |   10 ++++++++++
 2 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-shmobile/include/mach/r8a7740.h b/arch/arm/mach-shmobile/include/mach/r8a7740.h
index 7b1138f..536c021 100644
--- a/arch/arm/mach-shmobile/include/mach/r8a7740.h
+++ b/arch/arm/mach-shmobile/include/mach/r8a7740.h
@@ -42,6 +42,8 @@ enum {
 	SHDMA_SLAVE_FSIB_TX,
 	SHDMA_SLAVE_USBHS_TX,
 	SHDMA_SLAVE_USBHS_RX,
+	SHDMA_SLAVE_MMCIF_TX,
+	SHDMA_SLAVE_MMCIF_RX,
 };
 
 extern void r8a7740_meram_workaround(void);
diff --git a/arch/arm/mach-shmobile/setup-r8a7740.c b/arch/arm/mach-shmobile/setup-r8a7740.c
index 00c5a70..6b3ed42 100644
--- a/arch/arm/mach-shmobile/setup-r8a7740.c
+++ b/arch/arm/mach-shmobile/setup-r8a7740.c
@@ -588,6 +588,16 @@ static const struct sh_dmae_slave_config r8a7740_dmae_slaves[] = {
 		.addr		= 0xfe1f0064,
 		.chcr		= CHCR_TX(XMIT_SZ_32BIT),
 		.mid_rid	= 0xb5,
+	}, {
+		.slave_id	= SHDMA_SLAVE_MMCIF_TX,
+		.addr		= 0xe6bd0034,
+		.chcr		= CHCR_TX(XMIT_SZ_32BIT),
+		.mid_rid	= 0xd1,
+	}, {
+		.slave_id	= SHDMA_SLAVE_MMCIF_RX,
+		.addr		= 0xe6bd0034,
+		.chcr		= CHCR_RX(XMIT_SZ_32BIT),
+		.mid_rid	= 0xd2,
 	},
 };
 
-- 
1.7.2.5



From g.liakhovetski at gmx.de  Fri Apr 26 12:27:47 2013
From: g.liakhovetski at gmx.de (Guennadi Liakhovetski)
Date: Fri, 26 Apr 2013 18:27:47 +0200
Subject: [PATCH 6/6] ARM: shmobile: armadillo800eva-reference: add DMA support
 for MMCIF and SDHI
In-Reply-To: <1366993667-23294-1-git-send-email-g.liakhovetski@gmx.de>
References: <1366993667-23294-1-git-send-email-g.liakhovetski@gmx.de>
Message-ID: <1366993667-23294-7-git-send-email-g.liakhovetski@gmx.de>

Add DMA bindings to SDHI and MMCIF DT nodes on armadillo800eva-reference.

Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas at gmail.com>
---
 .../boot/dts/r8a7740-armadillo800eva-reference.dts |    9 +++++++++
 1 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7740-armadillo800eva-reference.dts b/arch/arm/boot/dts/r8a7740-armadillo800eva-reference.dts
index 3752637..c201445 100644
--- a/arch/arm/boot/dts/r8a7740-armadillo800eva-reference.dts
+++ b/arch/arm/boot/dts/r8a7740-armadillo800eva-reference.dts
@@ -47,6 +47,9 @@
 	vmmc-supply = <&reg_3p3v>;
 	bus-width = <8>;
 	non-removable;
+	dmas = <&dma0 0xd1
+		&dma0 0xd2>;
+	dma-names = "tx", "rx";
 	status = "okay";
 };
 
@@ -54,11 +57,17 @@
 	vmmc-supply = <&reg_3p3v>;
 	bus-width = <4>;
 	broken-cd;
+	dmas = <&dma0 0xc1
+		&dma0 0xc2>;
+	dma-names = "tx", "rx";
 	status = "okay";
 };
 
 &sdhi1 {
 	vmmc-supply = <&reg_3p3v>;
 	bus-width = <4>;
+	dmas = <&dma0 0xc9
+		&dma0 0xca>;
+	dma-names = "tx", "rx";
 	status = "okay";
 };
-- 
1.7.2.5



From marc.zyngier at arm.com  Fri Apr 26 12:45:51 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Fri, 26 Apr 2013 17:45:51 +0100
Subject: [PATCH v4 5/7] ARM: KVM: rework HYP page table freeing
In-Reply-To: <20130426110558.GE5007@localhost.cambridge.arm.com>
References: <1365790327-2138-1-git-send-email-marc.zyngier@arm.com>
 <1365790327-2138-6-git-send-email-marc.zyngier@arm.com>
 <20130426110558.GE5007@localhost.cambridge.arm.com>
Message-ID: <517AAF3F.20500@arm.com>

On 26/04/13 12:05, Catalin Marinas wrote:
> On Fri, Apr 12, 2013 at 07:12:05PM +0100, Marc Zyngier wrote:
>> diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
>> index bfc5927..7464824 100644
>> --- a/arch/arm/kvm/mmu.c
>> +++ b/arch/arm/kvm/mmu.c
> ...
>> +static void clear_pmd_entry(pmd_t *pmd)
>> +{
>> +	pte_t *pte_table = pte_offset_kernel(pmd, 0);
>> +	pmd_clear(pmd);
>> +	pte_free_kernel(NULL, pte_table);
>> +	put_page(virt_to_page(pmd));
>> +}
> ...
>>  static void unmap_stage2_range(struct kvm *kvm, phys_addr_t start, u64 size)
> 
> Is there a chance that this function (or the other unmapping function
> for Hyp pages) is called on an active stage 2 table (VTTBR pointing to
> this pgd)? If yes, than you probably have to follow the mmu_gather
> mechanism of freeing page table pages to avoid speculative loads.
> Basically flushing the TLB between pmd_clear and pte_free_kernel.

Blah. You're right, we got it wrong.

We need to move our TLB invalidation out of kvm_unmap_hva_handler, and
put it in clear_pmd_entry. I'll cook a patch.

Thanks for reviewing.

	M.
-- 
Jazz is not dead. It just smells funny...



From khilman at linaro.org  Fri Apr 26 12:49:46 2013
From: khilman at linaro.org (Kevin Hilman)
Date: Fri, 26 Apr 2013 09:49:46 -0700
Subject: [V2 PATCH] cpuidle: add maintainer entry
In-Reply-To: <1366974344-26064-1-git-send-email-daniel.lezcano@linaro.org>
 (Daniel Lezcano's message of "Fri, 26 Apr 2013 13:05:44 +0200")
References: <1366974344-26064-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <87txmtz179.fsf@linaro.org>

Daniel Lezcano <daniel.lezcano at linaro.org> writes:

> Currently the cpuidle drivers are spread across the different archs.
>
> The patch submission for cpuidle are following different path: the cpuidle core
> code goes to linux-pm, the ARM drivers goes to arm-soc or the SoC specific
> tree, sh goes through sh arch tree, pseries goes through PowerPC and
> finally intel goes through Len's tree while acpi_idle goes under linux-pm.
>
> That makes difficult to consolidate the code and to propagate modifications
> from the cpuidle core to the different drivers.
>
> Hopefully, a movement has initiated to put the cpuidle drivers into the
> drivers/cpuidle directory like cpuidle-calxeda.c and cpuidle-kirkwood.c
>
> Add an explicit maintainer entry in the MAINTAINER to clarify the situation
> and prevent new cpuidle drivers to goes to an arch directory.
>
> The upstreaming process is unchanged: Rafael takes the patches to merge them
> into its tree but with the acked-by from the driver's maintainer. So the header
> must contains the name of the maintainer.
>
> This organization will be the same than cpufreq.
>
> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
> Acked-by: Linus Walleij <linus.walleij at linaro.org>
> Acked-by: Andrew Lunn <andrew at lunn.ch>  #for kirkwood
> Acked-by: Jason Cooper <jason at lakedaemon.net> #for kirkwood

Acked-by: Kevin Hilman <khilman at linaro.org>


From lauraa at codeaurora.org  Fri Apr 26 12:58:59 2013
From: lauraa at codeaurora.org (Laura Abbott)
Date: Fri, 26 Apr 2013 09:58:59 -0700
Subject: [PATCH] of: Set the DMA mask to 64 bits on ARM LPAE systems
In-Reply-To: <20130426100001.GB5007@localhost.cambridge.arm.com>
References: <1366764649-10342-1-git-send-email-lauraa@codeaurora.org>
 <20130425133315.GA7157@localhost.cambridge.arm.com>
 <51796365.5030405@codeaurora.org>
 <20130426100001.GB5007@localhost.cambridge.arm.com>
Message-ID: <517AB253.1090607@codeaurora.org>

On 4/26/2013 3:00 AM, Catalin Marinas wrote:
> On Thu, Apr 25, 2013 at 06:09:57PM +0100, Laura Abbott wrote:
>> On 4/25/2013 6:33 AM, Catalin Marinas wrote:
>>> On Wed, Apr 24, 2013 at 01:50:49AM +0100, Laura Abbott wrote:
>>>> By default on ARM systems, the coherent DMA mask (lowest
>>>> address) is set to ~0 or 0xFFFFFFFFFFFFFFFF. Currently,
>>>> of_platform_device_create_pdata sets the coherent DMA mask to
>>>> 32 bits. This prevents coherent dma allocations from working by default
>>>> without clients setting the DMA mask. Rather than make every client
>>>> on an LPAE system set the mask, set the mask to a 64 bit value on
>>>> ARM LPAE systems.
>>>>
>>>> Signed-off-by: Laura Abbott <lauraa at codeaurora.org>
>>>> ---
>>>>    drivers/of/platform.c |    4 ++++
>>>>    1 files changed, 4 insertions(+), 0 deletions(-)
>>>>
>>>> diff --git a/drivers/of/platform.c b/drivers/of/platform.c
>>>> index 0970505..18b69c1 100644
>>>> --- a/drivers/of/platform.c
>>>> +++ b/drivers/of/platform.c
>>>> @@ -214,7 +214,11 @@ struct platform_device *of_platform_device_create_pdata(
>>>>    #if defined(CONFIG_MICROBLAZE)
>>>>    	dev->archdata.dma_mask = 0xffffffffUL;
>>>>    #endif
>>>> +#ifdef CONFIG_ARM_LPAE
>>>> +	dev->dev.coherent_dma_mask = DMA_BIT_MASK(64);
>>>> +#else
>>>>    	dev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
>>>> +#endif
>>>
>>> I wouldn't add CONFIG_ARM_LPAE checks in here, you can use
>>> CONFIG_ARCH_DMA_ADDR_T_64BIT (types.h uses this for the dma_addr_t
>>> definition).
>>>
>>
>> I thought about this as well but in arch/arm/mm/mm.h:
>>
>> #ifdef CONFIG_ZONE_DMA
>> extern phys_addr_t arm_dma_limit;
>> #else
>> #define arm_dma_limit ((phys_addr_t)~0)
>> #endif
>
> Russell replied already on the meaning of this variable, so I don't
> think its type is relevant here. It is also used when calling
> dma_contiguous_reserve() which takes a phys_addr_t.
>
>> arm_dma_limit is explicitly cast to phys_addr_t, which means that
>> arm_dma_limit will be always be sizeof(phys_addr_t) regardless of
>> sizeof(dma_addr_t). Is it safe to assume that
>> CONFIG_ARCH_DMA_ADDR_T_64BIT will always be selected if
>> sizeof(phys_addr_t) == 8? If not, we've defeated the point of the patch.
>
> sizeof(dma_addr_t) <= sizeof(phys_addr_t). I had this discussion with
> Russell when upstreaming the LPAE patches and the conclusion was that
> while the phys_addr_t is 64-bit with LPAE, the dma_addr_t size is a
> feature of the SoC and must be selected independently. However, I think
> with multi-platform support and LPAE enabled, we should probably set the
> dma_addr_t to 64-bit.
>
>> Alternatively, should the type of arm_dma_limit be dma_addr_t instead of
>> phys_addr_t?
>
> arm_dma_limit should be phys_addr_t since this is an address as seen by
> the CPU. dma_addr_t OTOH is a bus address as seen by the device. You can
> in theory have a DMA buffer with physical address beyond 32-bit (from a
> CPU perspective) but with a bus address withing 32-bit as seen by the
> device.
>
> There is some confusion in the kernel (you can google for past
> discussions) around the meaning of the DMA mask. If your RAM starts at
> 0, it doesn't matter much and there are several such assumptions in the
> kernel.
>
> So I still consider that you should use #ifdef
> CONFIG_ARCH_DMA_ADDR_T_64BIT and select this option on your platform.
>

Thanks for the clarification on all this. It's non-obvious but I see why 
things are set up the way they are. I'll re-submit with 
CONFIG_ARCH_DMA_ADDR_T_64BIT.

Laura

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation


From catalin.marinas at arm.com  Fri Apr 26 13:01:52 2013
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Fri, 26 Apr 2013 18:01:52 +0100
Subject: [PATCH v3 02/32] arm64: KVM: define HYP and Stage-2
 translation page flags
In-Reply-To: <1365437854-30214-3-git-send-email-marc.zyngier@arm.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
 <1365437854-30214-3-git-send-email-marc.zyngier@arm.com>
Message-ID: <20130426170152.GD11311@arm.com>

On Mon, Apr 08, 2013 at 05:17:04PM +0100, Marc Zyngier wrote:
> diff --git a/arch/arm64/include/asm/pgtable-hwdef.h b/arch/arm64/include/asm/pgtable-hwdef.h
> index 75fd13d..acb4ee5 100644
> --- a/arch/arm64/include/asm/pgtable-hwdef.h
> +++ b/arch/arm64/include/asm/pgtable-hwdef.h
> @@ -68,6 +69,18 @@
>  #define PTE_ATTRINDX_MASK	(_AT(pteval_t, 7) << 2)
>  
>  /*
> + * 2nd stage PTE definitions
> + */
> +#define PTE_S2_RDONLY		 (_AT(pteval_t, 1) << 6)   /* HAP[1]   */
> +#define PTE_S2_RDWR		 (_AT(pteval_t, 2) << 6)   /* HAP[2:1] */

RDWR should be 3 here (already the case in arch/arm). BTW, I would use
HAP[2:1] comment in both cases since that's the attribute field.

> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
> index e333a24..7c84ab4 100644
> --- a/arch/arm64/include/asm/pgtable.h
> +++ b/arch/arm64/include/asm/pgtable.h
> @@ -76,6 +76,12 @@ extern pgprot_t pgprot_default;
>  #define PAGE_KERNEL		_MOD_PROT(pgprot_default, PTE_PXN | PTE_UXN | PTE_DIRTY)
>  #define PAGE_KERNEL_EXEC	_MOD_PROT(pgprot_default, PTE_UXN | PTE_DIRTY)
>  
> +#define PAGE_HYP		_MOD_PROT(pgprot_default, PTE_HYP)
> +#define PAGE_HYP_DEVICE		_MOD_PROT(__pgprot(PROT_DEVICE_nGnRE), PTE_HYP)
> +
> +#define PAGE_S2			_MOD_PROT(pgprot_default, PTE_USER | PTE_S2_RDONLY)

Why is this one read-only by default?

> +#define PAGE_S2_DEVICE		_MOD_PROT(__pgprot(PROT_DEVICE_nGnRE), PTE_USER | PTE_S2_RDWR)

You could write it directly as __pgprot(PROT_DEVICE_nGnRE | PTE_USER | PTE_S2_RDWR)

-- 
Catalin


From plagnioj at jcrosoft.com  Fri Apr 26 13:01:58 2013
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Fri, 26 Apr 2013 19:01:58 +0200
Subject: [V2 PATCH] cpuidle: add maintainer entry
In-Reply-To: <1366974344-26064-1-git-send-email-daniel.lezcano@linaro.org>
References: <1366974344-26064-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <20130426170158.GA24282@game.jcrosoft.org>

On 13:05 Fri 26 Apr     , Daniel Lezcano wrote:
> Currently the cpuidle drivers are spread across the different archs.
> 
> The patch submission for cpuidle are following different path: the cpuidle core
> code goes to linux-pm, the ARM drivers goes to arm-soc or the SoC specific
> tree, sh goes through sh arch tree, pseries goes through PowerPC and
> finally intel goes through Len's tree while acpi_idle goes under linux-pm.
> 
> That makes difficult to consolidate the code and to propagate modifications
> from the cpuidle core to the different drivers.
> 
> Hopefully, a movement has initiated to put the cpuidle drivers into the
> drivers/cpuidle directory like cpuidle-calxeda.c and cpuidle-kirkwood.c
> 
> Add an explicit maintainer entry in the MAINTAINER to clarify the situation
> and prevent new cpuidle drivers to goes to an arch directory.
> 
> The upstreaming process is unchanged: Rafael takes the patches to merge them
> into its tree but with the acked-by from the driver's maintainer. So the header
> must contains the name of the maintainer.
> 
> This organization will be the same than cpufreq.
> 
> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
> Acked-by: Linus Walleij <linus.walleij at linaro.org>
> Acked-by: Andrew Lunn <andrew at lunn.ch>  #for kirkwood
> Acked-by: Jason Cooper <jason at lakedaemon.net> #for kirkwood
> ---
>  MAINTAINERS                        |    9 +++++++++
>  drivers/cpuidle/cpuidle-calxeda.c  |    4 +++-
>  drivers/cpuidle/cpuidle-kirkwood.c |    5 +++--
>  3 files changed, 15 insertions(+), 3 deletions(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 61677c3..45ee6dc 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2217,6 +2217,15 @@ F:	drivers/cpufreq/arm_big_little.h
>  F:	drivers/cpufreq/arm_big_little.c
>  F:	drivers/cpufreq/arm_big_little_dt.c
>  
> +CPUIDLE DRIVERS
> +M:	Rafael J. Wysocki <rjw at sisk.pl>
> +M:	Daniel Lezcano <daniel.lezcano at linaro.org>
> +L:	linux-pm at vger.kernel.org
> +S:	Maintained
> +T:	git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git
> +F:	drivers/cpuidle/*
> +F:	include/linux/cpuidle.h
> +
>  CPUID/MSR DRIVER
>  M:	"H. Peter Anvin" <hpa at zytor.com>
>  S:	Maintained
> diff --git a/drivers/cpuidle/cpuidle-calxeda.c b/drivers/cpuidle/cpuidle-calxeda.c
> index e344b56..2233791 100644
> --- a/drivers/cpuidle/cpuidle-calxeda.c
> +++ b/drivers/cpuidle/cpuidle-calxeda.c
> @@ -1,7 +1,7 @@
>  /*
>   * Copyright 2012 Calxeda, Inc.
>   *
> - * Based on arch/arm/plat-mxc/cpuidle.c:
> + * Based on arch/arm/plat-mxc/cpuidle.c: #v3.7
>   * Copyright 2012 Freescale Semiconductor, Inc.
>   * Copyright 2012 Linaro Ltd.
>   *
> @@ -16,6 +16,8 @@
>   *
>   * You should have received a copy of the GNU General Public License along with
>   * this program.  If not, see <http://www.gnu.org/licenses/>.
> + *
> + * Maintainer: Rob Herring <rob.herring at calxeda.com>
this need to move to the MAINTAINER file

so we get the e-mail get get_maintainer.pl
>   */
>  
>  #include <linux/cpuidle.h>
> diff --git a/drivers/cpuidle/cpuidle-kirkwood.c b/drivers/cpuidle/cpuidle-kirkwood.c
> index 53290e1..521b0a7 100644
> --- a/drivers/cpuidle/cpuidle-kirkwood.c
> +++ b/drivers/cpuidle/cpuidle-kirkwood.c
> @@ -1,6 +1,4 @@
>  /*
> - * arch/arm/mach-kirkwood/cpuidle.c
> - *
>   * CPU idle Marvell Kirkwood SoCs
>   *
>   * This file is licensed under the terms of the GNU General Public
> @@ -11,6 +9,9 @@
>   * to implement two idle states -
>   * #1 wait-for-interrupt
>   * #2 wait-for-interrupt and DDR self refresh
> + *
> + * Maintainer: Jason Cooper <jason at lakedaemon.net>
> + * Maintainer: Andrew Lunn <andrew at lunn.ch>
ditto
>   */
>  
>  #include <linux/kernel.h>
> -- 
> 1.7.9.5
> 


From marc.zyngier at arm.com  Fri Apr 26 13:11:07 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Fri, 26 Apr 2013 18:11:07 +0100
Subject: [PATCH v3 02/32] arm64: KVM: define HYP and Stage-2 translation
 page flags
In-Reply-To: <20130426170152.GD11311@arm.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
 <1365437854-30214-3-git-send-email-marc.zyngier@arm.com>
 <20130426170152.GD11311@arm.com>
Message-ID: <517AB52B.7000006@arm.com>

On 26/04/13 18:01, Catalin Marinas wrote:
> On Mon, Apr 08, 2013 at 05:17:04PM +0100, Marc Zyngier wrote:
>> diff --git a/arch/arm64/include/asm/pgtable-hwdef.h b/arch/arm64/include/asm/pgtable-hwdef.h
>> index 75fd13d..acb4ee5 100644
>> --- a/arch/arm64/include/asm/pgtable-hwdef.h
>> +++ b/arch/arm64/include/asm/pgtable-hwdef.h
>> @@ -68,6 +69,18 @@
>>  #define PTE_ATTRINDX_MASK	(_AT(pteval_t, 7) << 2)
>>  
>>  /*
>> + * 2nd stage PTE definitions
>> + */
>> +#define PTE_S2_RDONLY		 (_AT(pteval_t, 1) << 6)   /* HAP[1]   */
>> +#define PTE_S2_RDWR		 (_AT(pteval_t, 2) << 6)   /* HAP[2:1] */
> 
> RDWR should be 3 here (already the case in arch/arm). BTW, I would use

Yes, Will spotted this one already, and it is now fixed in my tree.

> HAP[2:1] comment in both cases since that's the attribute field.

Indeed.

>> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
>> index e333a24..7c84ab4 100644
>> --- a/arch/arm64/include/asm/pgtable.h
>> +++ b/arch/arm64/include/asm/pgtable.h
>> @@ -76,6 +76,12 @@ extern pgprot_t pgprot_default;
>>  #define PAGE_KERNEL		_MOD_PROT(pgprot_default, PTE_PXN | PTE_UXN | PTE_DIRTY)
>>  #define PAGE_KERNEL_EXEC	_MOD_PROT(pgprot_default, PTE_UXN | PTE_DIRTY)
>>  
>> +#define PAGE_HYP		_MOD_PROT(pgprot_default, PTE_HYP)
>> +#define PAGE_HYP_DEVICE		_MOD_PROT(__pgprot(PROT_DEVICE_nGnRE), PTE_HYP)
>> +
>> +#define PAGE_S2			_MOD_PROT(pgprot_default, PTE_USER | PTE_S2_RDONLY)
> 
> Why is this one read-only by default?

Because the guest pages start their life mapped RO. Only on the first
write access they become writeable.

>> +#define PAGE_S2_DEVICE		_MOD_PROT(__pgprot(PROT_DEVICE_nGnRE), PTE_USER | PTE_S2_RDWR)
> 
> You could write it directly as __pgprot(PROT_DEVICE_nGnRE | PTE_USER | PTE_S2_RDWR)

Good point! This code as changed a bit anyway, as it contains some other
odd things... ;-)

Thanks for reviewing,

	M.
-- 
Jazz is not dead. It just smells funny...



From g.liakhovetski at gmx.de  Fri Apr 26 13:27:39 2013
From: g.liakhovetski at gmx.de (Guennadi Liakhovetski)
Date: Fri, 26 Apr 2013 19:27:39 +0200 (CEST)
Subject: [PATCH 2/6] ARM: shmobile: add SDHI and MMCIF interfaces to
 armadillo800eva-reference
In-Reply-To: <1366993667-23294-3-git-send-email-g.liakhovetski@gmx.de>
References: <1366993667-23294-1-git-send-email-g.liakhovetski@gmx.de>
 <1366993667-23294-3-git-send-email-g.liakhovetski@gmx.de>
Message-ID: <Pine.LNX.4.64.1304261926040.32752@axis700.grange>

Hi Simon

On Fri, 26 Apr 2013, Guennadi Liakhovetski wrote:

> Add SDHI0, SDHI1 and MMCIF interfaces to armadillo800eva-reference. With
> no pinctrl DT support we cannot use GPIO card-detection and regulator
> switching.
> 
> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski at gmx.de>

It should have been

Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas at gmail.com>

actually, just like in all other patches in this series.

Thanks
Guennadi

> ---
>  .../boot/dts/r8a7740-armadillo800eva-reference.dts |   21 +++++++++++-
>  arch/arm/boot/dts/r8a7740.dtsi                     |   33 ++++++++++++++++++
>  .../board-armadillo800eva-reference.c              |   36 +++++++++++++++++++-
>  3 files changed, 88 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/r8a7740-armadillo800eva-reference.dts b/arch/arm/boot/dts/r8a7740-armadillo800eva-reference.dts
> index 09ea22c..3752637 100644
> --- a/arch/arm/boot/dts/r8a7740-armadillo800eva-reference.dts
> +++ b/arch/arm/boot/dts/r8a7740-armadillo800eva-reference.dts
> @@ -32,7 +32,6 @@
>  		regulator-always-on;
>  		regulator-boot-on;
>  	};
> -
>  };
>  
>  &i2c0 {
> @@ -43,3 +42,23 @@
>  		interrupts = <2 0>; /* IRQ10: hwirq 2 on irqpin1 */
>  	};
>  };
> +
> +&mmcif0 {
> +	vmmc-supply = <&reg_3p3v>;
> +	bus-width = <8>;
> +	non-removable;
> +	status = "okay";
> +};
> +
> +&sdhi0 {
> +	vmmc-supply = <&reg_3p3v>;
> +	bus-width = <4>;
> +	broken-cd;
> +	status = "okay";
> +};
> +
> +&sdhi1 {
> +	vmmc-supply = <&reg_3p3v>;
> +	bus-width = <4>;
> +	status = "okay";
> +};
> diff --git a/arch/arm/boot/dts/r8a7740.dtsi b/arch/arm/boot/dts/r8a7740.dtsi
> index 25dc930..e9a90d8 100644
> --- a/arch/arm/boot/dts/r8a7740.dtsi
> +++ b/arch/arm/boot/dts/r8a7740.dtsi
> @@ -135,4 +135,37 @@
>  			      0 72 0x4
>  			      0 73 0x4>;
>  	};
> +
> +	mmcif0: mmcif at e6bd0000 {
> +		compatible = "renesas,sh-mmcif", "renesas,sh7372-mmcif";
> +		reg = <0xe6bd0000 0x100>;
> +		interrupt-parent = <&gic>;
> +		interrupts = <0 56 4
> +				0 57 4>;
> +		status = "disabled";
> +	};
> +
> +	sdhi0: sdhi at e6850000 {
> +		compatible = "renesas,r8a7740-sdhi";
> +		reg = <0xe6850000 0x100>;
> +		interrupt-parent = <&gic>;
> +		interrupts = <0 117 4
> +				0 118 4
> +				0 119 4>;
> +		cap-sd-highspeed;
> +		cap-sdio-irq;
> +		status = "disabled";
> +	};
> +
> +	sdhi1: sdhi at e6860000 {
> +		compatible = "renesas,r8a7740-sdhi";
> +		reg = <0xe6860000 0x100>;
> +		interrupt-parent = <&gic>;
> +		interrupts = <0 121 4
> +				0 122 4
> +				0 123 4>;
> +		cap-sd-highspeed;
> +		cap-sdio-irq;
> +		status = "disabled";
> +	};
>  };
> diff --git a/arch/arm/mach-shmobile/board-armadillo800eva-reference.c b/arch/arm/mach-shmobile/board-armadillo800eva-reference.c
> index 03b85fe..d26a9da 100644
> --- a/arch/arm/mach-shmobile/board-armadillo800eva-reference.c
> +++ b/arch/arm/mach-shmobile/board-armadillo800eva-reference.c
> @@ -123,6 +123,27 @@ static const struct pinctrl_map eva_pinctrl_map[] = {
>  	/* SCIFA1 */
>  	PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.1", "pfc-r8a7740",
>  				  "scifa1_data", "scifa1"),
> +	/* MMCIF */
> +	PIN_MAP_MUX_GROUP_DEFAULT("e6bd0000.sh-mmcif", "pfc-r8a7740",
> +				  "mmc0_data8_1", "mmc0"),
> +	PIN_MAP_MUX_GROUP_DEFAULT("e6bd0000.sh-mmcif", "pfc-r8a7740",
> +				  "mmc0_ctrl_1", "mmc0"),
> +	/* SDHI0 */
> +	PIN_MAP_MUX_GROUP_DEFAULT("e6850000.sdhi", "pfc-r8a7740",
> +				  "sdhi0_data4", "sdhi0"),
> +	PIN_MAP_MUX_GROUP_DEFAULT("e6850000.sdhi", "pfc-r8a7740",
> +				  "sdhi0_ctrl", "sdhi0"),
> +	PIN_MAP_MUX_GROUP_DEFAULT("e6850000.sdhi", "pfc-r8a7740",
> +				  "sdhi0_wp", "sdhi0"),
> +	/* SDHI1 */
> +	PIN_MAP_MUX_GROUP_DEFAULT("e6860000.sdhi", "pfc-r8a7740",
> +				  "sdhi1_data4", "sdhi1"),
> +	PIN_MAP_MUX_GROUP_DEFAULT("e6860000.sdhi", "pfc-r8a7740",
> +				  "sdhi1_ctrl", "sdhi1"),
> +	PIN_MAP_MUX_GROUP_DEFAULT("e6860000.sdhi", "pfc-r8a7740",
> +				  "sdhi1_cd", "sdhi1"),
> +	PIN_MAP_MUX_GROUP_DEFAULT("e6860000.sdhi", "pfc-r8a7740",
> +				  "sdhi1_wp", "sdhi1"),
>  };
>  
>  static void __init eva_clock_init(void)
> @@ -165,7 +186,6 @@ clock_error:
>   */
>  static void __init eva_init(void)
>  {
> -
>  	r8a7740_clock_init(MD_CK0 | MD_CK2);
>  	eva_clock_init();
>  
> @@ -180,6 +200,20 @@ static void __init eva_init(void)
>  	 */
>  	gpio_request_one(166, GPIOF_OUT_INIT_HIGH, NULL); /* TP_RST_B */
>  
> +	/* SDHI0 */
> +	gpio_request_one(17, GPIOF_OUT_INIT_LOW, NULL);  /* SDHI0_18/33_B */
> +	gpio_request_one(74, GPIOF_OUT_INIT_HIGH, NULL); /* SDHI0_PON */
> +	gpio_request_one(75, GPIOF_OUT_INIT_HIGH, NULL); /* SDSLOT1_PON */
> +
> +	/* We can switch CON8/CON14 by SW1.5, but only after DBGMD_SELECT_B */
> +	gpio_request_one(6, GPIOF_IN, NULL);
> +	if (!gpio_get_value(6)) {
> +		/* CON14 disabled, CON8 (SDHI1) enabled */
> +
> +		/* SDSLOT2_PON */
> +		gpio_request_one(16, GPIOF_OUT_INIT_HIGH, NULL);
> +	}
> +
>  #ifdef CONFIG_CACHE_L2X0
>  	/* Early BRESP enable, Shared attribute override enable, 32K*8way */
>  	l2x0_init(IOMEM(0xf0002000), 0x40440000, 0x82000fff);
> -- 
> 1.7.2.5
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/


From nm at ti.com  Fri Apr 26 13:39:32 2013
From: nm at ti.com (Nishanth Menon)
Date: Fri, 26 Apr 2013 12:39:32 -0500
Subject: [PATCH 1/2] ARM: dts: OMAP36xx: Fix CPU OPP voltages
In-Reply-To: <1366997973-19120-1-git-send-email-nm@ti.com>
References: <1366997973-19120-1-git-send-email-nm@ti.com>
Message-ID: <1366997973-19120-2-git-send-email-nm@ti.com>

commit 3027e26 (ARM: dts: OMAP36xx: Add CPU OPP table)
introduced wrong OPP voltages per OPP by mistake. Sync the OPP
tables with existing OMAP36xx OPP data in
arch/arm/mach-omap2/opp3xxx_data.c

Signed-off-by: Nishanth Menon <nm at ti.com>
---
 arch/arm/boot/dts/omap36xx.dtsi |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/omap36xx.dtsi b/arch/arm/boot/dts/omap36xx.dtsi
index b89233e..f3447bc 100644
--- a/arch/arm/boot/dts/omap36xx.dtsi
+++ b/arch/arm/boot/dts/omap36xx.dtsi
@@ -20,9 +20,9 @@
 		cpu at 0 {
 			operating-points = <
 				/* kHz    uV */
-				300000   975000
-				600000  1075000
-				800000  1200000
+				300000  1012500
+				600000  1200000
+				800000  1325000
 			>;
 			clock-latency = <300000>; /* From legacy driver */
 		};
-- 
1.7.9.5



From nm at ti.com  Fri Apr 26 13:39:31 2013
From: nm at ti.com (Nishanth Menon)
Date: Fri, 26 Apr 2013 12:39:31 -0500
Subject: [PATCH 0/2] ARM: dts: OMAP36xx/OMAP4460 Fix CPU OPP voltages
Message-ID: <1366997973-19120-1-git-send-email-nm@ti.com>

Hi,
It seems that I have not been paying close attention to
actual voltage value seen on scope to map it back to verify the validity
of the voltage value. Even though I did verify[1] that voltage did scale to
values in DT entries, the values in the case of 3630 and 4460 were lower than
what the spec voltage was as per opp_data files.

This series is based off Benoit's tree here:
http://git.kernel.org/cgit/linux/kernel/git/bcousson/linux-omap-dt.git/log/?h=for_3.10/dts

Commit ID's in the patches to indicate regressions are from there as well.
Would be good to have this fix merged to 3.10 dts entries.
I have cross verified that OMAP3430,3630,4430 and 4460 entries now match that
of corresponding opp*_data.c

My sincere apologies on the oversight.

Nishanth Menon (2):
  ARM: dts: OMAP36xx: Fix CPU OPP voltages
  ARM: dts: OMAP4460: Fix CPU OPP voltages

 arch/arm/boot/dts/omap36xx.dtsi |    6 +++---
 arch/arm/boot/dts/omap4460.dtsi |    6 +++---
 2 files changed, 6 insertions(+), 6 deletions(-)

[1] http://marc.info/?l=linux-arm-kernel&m=136580742724210&w=2
Regards,
Nishanth Menon
-- 
1.7.9.5



From nm at ti.com  Fri Apr 26 13:39:33 2013
From: nm at ti.com (Nishanth Menon)
Date: Fri, 26 Apr 2013 12:39:33 -0500
Subject: [PATCH 2/2] ARM: dts: OMAP4460: Fix CPU OPP voltages
In-Reply-To: <1366997973-19120-1-git-send-email-nm@ti.com>
References: <1366997973-19120-1-git-send-email-nm@ti.com>
Message-ID: <1366997973-19120-3-git-send-email-nm@ti.com>

commit d16fb25 (ARM: dts: OMAP4460: Add CPU OPP table)
introduced wrong OPP voltages per OPP by mistake. Sync the OPP
tables with existing OMAP4460 OPP data in
arch/arm/mach-omap2/opp4xxx_data.c

Signed-off-by: Nishanth Menon <nm at ti.com>
---
 arch/arm/boot/dts/omap4460.dtsi |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/omap4460.dtsi b/arch/arm/boot/dts/omap4460.dtsi
index 7c2c23c..2cf227c 100644
--- a/arch/arm/boot/dts/omap4460.dtsi
+++ b/arch/arm/boot/dts/omap4460.dtsi
@@ -15,9 +15,9 @@
 		cpu at 0 {
 			operating-points = <
 				/* kHz    uV */
-				350000   975000
-				700000  1075000
-				920000  1200000
+				350000  1025000
+				700000  1200000
+				920000  1313000
 			>;
 			clock-latency = <300000>; /* From legacy driver */
 		};
-- 
1.7.9.5



From robert.jarzmik at free.fr  Fri Apr 26 13:48:12 2013
From: robert.jarzmik at free.fr (Robert Jarzmik)
Date: Fri, 26 Apr 2013 19:48:12 +0200
Subject: gpio-pxa initcall level change and machine init breakage
In-Reply-To: <CACRpkdYEi7i_kSuUy4dBW-tE4BxifJY5wFdYVyLe6La5=HwEmg@mail.gmail.com>
 (Linus Walleij's message of "Thu, 25 Apr 2013 23:22:13 +0200")
References: <5172B398.7060706@newsguy.com>
 <CAD6h2NSRA9w7GZLQGgK-+TvEAsxwOHow5_26JyVUA6YQyj3OQg@mail.gmail.com>
 <517466F6.3000003@newsguy.com>
 <CAD6h2NSy0=3P-PHdCiJJQG_jvGaFnr7uex+Uxs=0F-VsUxtPWg@mail.gmail.com>
 <CACRpkdbk24kR75fanvXVAocnuozNq_=jWDSPHPCWhbZCOrN5_Q@mail.gmail.com>
 <5176E438.80800@newsguy.com>
 <CACRpkdYLCKKZZFi6Y-viPUvrwupJGzfxr3f20a1emp-9qE0YBg@mail.gmail.com>
 <87ppxiz9l5.fsf@free.fr>
 <CACRpkdYEi7i_kSuUy4dBW-tE4BxifJY5wFdYVyLe6La5=HwEmg@mail.gmail.com>
Message-ID: <87li85yyhv.fsf@free.fr>

Linus Walleij <linus.walleij at linaro.org> writes:

> On Thu, Apr 25, 2013 at 9:36 PM, Robert Jarzmik <robert.jarzmik at free.fr> wrote:
> This was done by pull request to Torvalds yesterday ...
Thanks, that's a relief.

>
>>  (b) inform board maintainers that they must fix their board code (for example
>>  give them 1 window)
>>  (c) put back the patch. Board maintainers who did not amend their board
>>  code cannot say anymore they didn't know it. Board maintainers will also have
>>  time to rise objections if they think they cannot change their board code
>>  (which I do not believe is possible, but who knows ...)
>
> So when it comes to the PXA there is maybe this list of things that
> would be nice to change, and this is likely on top of it ... moving the
> PXA machines over to device tree would be more important if people
> who like them want them so stay around, because non-device tree
> platforms will at some point become deprecated, and fixing the platforms
> to support device tree will inevitably lead to this problem being fixed
> as well.
Yeah, probably. That's a good long term goal too.
Now you reverted, I'm under pressure to fix mioa701 to get rid of gpio calls in
its board setup code :)

As for device tree conversion, well that's another story.
For my case for example I'll have to redevelop the bootloader (IPL+SPL) in order
for suspend to RAM to work ... no world is perfecgt.

Cheers.

-- 
Robert


From khilman at linaro.org  Fri Apr 26 14:05:24 2013
From: khilman at linaro.org (Kevin Hilman)
Date: Fri, 26 Apr 2013 11:05:24 -0700
Subject: [PATCH v2 4/6] SERIAL: OMAP: Remove the slave idle handling from
 the driver
In-Reply-To: <1366973695-2088-5-git-send-email-rnayak@ti.com> (Rajendra
 Nayak's message of "Fri, 26 Apr 2013 16:24:53 +0530")
References: <1366973695-2088-1-git-send-email-rnayak@ti.com>
 <1366973695-2088-5-git-send-email-rnayak@ti.com>
Message-ID: <8761z9yxp7.fsf@linaro.org>

Rajendra Nayak <rnayak at ti.com> writes:

> From: Santosh Shilimkar <santosh.shilimkar at ti.com>
>
> UART IP slave idle handling now taken care by runtime pm backend(hwmod layer)
> so remove the hackery from the driver.
>
> As discussed on the list, in future if dma mode needs to be brought
> back to this driver, UART sysc handling needs to be updated in
> framework such a way that no-idle/force idle profile can be supported.
> Given the broken dma mode for OMAP uarts, its very unlikely.
>
> Acked-by: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
> Tested-by: Vaibhav Bedia <vaibhav.bedia at ti.com>
> Tested-by: Sourav Poddar <sourav.poddar at ti.com>
> Signed-off-by: Rajendra nayak <rnayak at ti.com>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>

nit: the ordering of this patch with the following one will break
bisect.  

IOW, with this patch applied, but not the following one, compilation
will be broken because the func pointers are removed from the header,
but still used in omap-serial.c.

A simple fix is to just apply the other one first.

Kevin

> ---
>  drivers/tty/serial/omap-serial.c          |   23 -----------------------
>  include/linux/platform_data/serial-omap.h |    2 --
>  2 files changed, 25 deletions(-)
>
> diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
> index 4dc4140..08332f3 100644
> --- a/drivers/tty/serial/omap-serial.c
> +++ b/drivers/tty/serial/omap-serial.c
> @@ -202,26 +202,6 @@ static int serial_omap_get_context_loss_count(struct uart_omap_port *up)
>  	return pdata->get_context_loss_count(up->dev);
>  }
>  
> -static void serial_omap_set_forceidle(struct uart_omap_port *up)
> -{
> -	struct omap_uart_port_info *pdata = up->dev->platform_data;
> -
> -	if (!pdata || !pdata->set_forceidle)
> -		return;
> -
> -	pdata->set_forceidle(up->dev);
> -}
> -
> -static void serial_omap_set_noidle(struct uart_omap_port *up)
> -{
> -	struct omap_uart_port_info *pdata = up->dev->platform_data;
> -
> -	if (!pdata || !pdata->set_noidle)
> -		return;
> -
> -	pdata->set_noidle(up->dev);
> -}
> -
>  static void serial_omap_enable_wakeup(struct uart_omap_port *up, bool enable)
>  {
>  	struct omap_uart_port_info *pdata = up->dev->platform_data;
> @@ -298,8 +278,6 @@ static void serial_omap_stop_tx(struct uart_port *port)
>  		serial_out(up, UART_IER, up->ier);
>  	}
>  
> -	serial_omap_set_forceidle(up);
> -
>  	pm_runtime_mark_last_busy(up->dev);
>  	pm_runtime_put_autosuspend(up->dev);
>  }
> @@ -364,7 +342,6 @@ static void serial_omap_start_tx(struct uart_port *port)
>  
>  	pm_runtime_get_sync(up->dev);
>  	serial_omap_enable_ier_thri(up);
> -	serial_omap_set_noidle(up);
>  	pm_runtime_mark_last_busy(up->dev);
>  	pm_runtime_put_autosuspend(up->dev);
>  }
> diff --git a/include/linux/platform_data/serial-omap.h b/include/linux/platform_data/serial-omap.h
> index ff9b0aa..c860c1b 100644
> --- a/include/linux/platform_data/serial-omap.h
> +++ b/include/linux/platform_data/serial-omap.h
> @@ -43,8 +43,6 @@ struct omap_uart_port_info {
>  	int			DTR_present;
>  
>  	int (*get_context_loss_count)(struct device *);
> -	void (*set_forceidle)(struct device *);
> -	void (*set_noidle)(struct device *);
>  	void (*enable_wakeup)(struct device *, bool);
>  };


From lauraa at codeaurora.org  Fri Apr 26 14:06:05 2013
From: lauraa at codeaurora.org (Laura Abbott)
Date: Fri, 26 Apr 2013 11:06:05 -0700
Subject: [PATCH v2] of: Set the DMA mask to 64 bits when dma_addr_t is 64-bits
Message-ID: <1366999565-19498-1-git-send-email-lauraa@codeaurora.org>

Currently, of_platform_device_create_pdata always sets the
coherent DMA mask to 32 bits. On ARM systems without CONFIG_ZONE_DMA,
arm_dma_limit gets set to ~0 or 0xFFFFFFFFFFFFFFFF on LPAE based
systems. Since arm_dma_limit represents the smallest dma_mask
on the system, the default of 32 bits prevents any dma_coherent
allocation from succeeding unless clients manually set the
dma mask first. Rather than make every client on an LPAE system set
the mask, set the mask to a 64 bit value on systems with 64-bit
dma addresses.

Signed-off-by: Laura Abbott <lauraa at codeaurora.org>
---
 drivers/of/platform.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index 0970505..c669ab4 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -214,7 +214,11 @@ struct platform_device *of_platform_device_create_pdata(
 #if defined(CONFIG_MICROBLAZE)
 	dev->archdata.dma_mask = 0xffffffffUL;
 #endif
+#ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT
+	dev->dev.coherent_dma_mask = DMA_BIT_MASK(64);
+#else
 	dev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
+#endif
 	dev->dev.bus = &platform_bus_type;
 	dev->dev.platform_data = platform_data;
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From khilman at linaro.org  Fri Apr 26 14:09:33 2013
From: khilman at linaro.org (Kevin Hilman)
Date: Fri, 26 Apr 2013 11:09:33 -0700
Subject: [PATCH v2 0/6] ARM;
 OMAP2+: hwmod and SERIAL: Remove sysc handling from driver
In-Reply-To: <1366973695-2088-1-git-send-email-rnayak@ti.com> (Rajendra
 Nayak's message of "Fri, 26 Apr 2013 16:24:49 +0530")
References: <1366973695-2088-1-git-send-email-rnayak@ti.com>
Message-ID: <87ppxhxixu.fsf@linaro.org>

Rajendra Nayak <rnayak at ti.com> writes:

[...]

> OMAP UART IP needs manual idle modes based on functional state of the
> IP. Currently this is handled by the driver with function pointers
> implemented in platform code.
>
> This however breaks in case of device tree because of missing
> idle handling. 
>
> The series tries to address the issue and tries to remove complete
> sysc handling from serial driver.

Other than the minor nit about the order of the series for bisect, 

Reviewed-by: Kevin Hilman <khilman at linaro.org>

Also tested this on OMAP4/Panda where I was having the sluggish console
issues using DT boot, and and can confirm that this fixes the problem:

Tested-by: Kevin Hilman <khilman at linaro.org>  # OMAP4/Panda

Kevin


From olof at lixom.net  Fri Apr 26 14:15:23 2013
From: olof at lixom.net (Olof Johansson)
Date: Fri, 26 Apr 2013 11:15:23 -0700
Subject: [PATCH] ARM: dts: add pinctrl nodes for Exynos5250 SoC
In-Reply-To: <CAJuYYwTwbYhRO7z8J79g-GM-44Y6A6trkF_z72Kqp+MoBF==+w@mail.gmail.com>
References: <1355403978-388-1-git-send-email-thomas.abraham@linaro.org>
 <20130424233348.GA6603@quad.lixom.net>
 <CAJuYYwTwbYhRO7z8J79g-GM-44Y6A6trkF_z72Kqp+MoBF==+w@mail.gmail.com>
Message-ID: <CAOesGMhbKAynrCoMyOaOf2UG-H8XL=Uk6PKiW78XSWW+BV=VkQ@mail.gmail.com>

Hi,

On Thu, Apr 25, 2013 at 12:38 AM, Thomas Abraham
<thomas.abraham at linaro.org> wrote:
> On 25 April 2013 05:03, Olof Johansson <olof at lixom.net> wrote:
>> On Thu, Dec 13, 2012 at 06:36:18PM +0530, Thomas Abraham wrote:
>>> Add pinctrl device nodes for Exynos5250 SoC.
>>>
>>> Signed-off-by: Thomas Abraham <thomas.abraham at linaro.org>
>>
>> Replying to an old email of a patch that has been merged because it seems
>> horribly broken.
>>
>>
>>> diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi
>>> index 581e57a..eb8d610 100644
>>> --- a/arch/arm/boot/dts/exynos5250.dtsi
>>> +++ b/arch/arm/boot/dts/exynos5250.dtsi
>>> @@ -18,6 +18,7 @@
>>>  */
>>>
>>>  /include/ "skeleton.dtsi"
>>> +/include/ "exynos5250-pinctrl.dtsi"
>>>
>>>  / {
>>>       compatible = "samsung,exynos5250";
>>> @@ -48,6 +49,8 @@
>>>               mshc1 = &dwmmc_1;
>>>               mshc2 = &dwmmc_2;
>>>               mshc3 = &dwmmc_3;
>>> +             pinctrl0 = &pinctrl_0;
>>> +             pinctrl3 = &pinctrl_3;
>>>       };
>>>
>>>       gic:interrupt-controller at 10481000 {
>>> @@ -79,6 +82,24 @@
>>>               interrupts = <0 42 0>;
>>>       };
>>>
>>> +     pinctrl_0: pinctrl at 11400000 {
>>> +             compatible = "samsung,pinctrl-exynos5250";
>>> +             reg = <0x11400000 0x1000>;
>>> +             interrupts = <0 46 0>;
>>> +
>>> +             wakup_eint: wakeup-interrupt-controller {
>>> +                     compatible = "samsung,exynos4210-wakeup-eint";
>>> +                     interrupt-parent = <&gic>;
>>> +                     interrupts = <0 32 0>;
>>> +             };
>>
>> Typo, should be "wakeup_eint". And what happened to #interrupt-cells? And the
>> interrupt map?
>
> Hi Olof,
>
> With the pinctrl driver, there is change in the way the wakeup
> interrupts are handled. Each of the four wakeup banks (GPX0 to GPX3)
> are now individual interrupt controllers (introduced by Tomasz Figa).
> The wakeup interrupts generated by GPX2 and GPX3 are muxed into the <0
> 32 0> interrupt of GIC.
>
> So the interrupts-cells and interrupt map are not required in the
> above node. The label "wakup_eint" can actually to dropped and
> probably the node name "wakeup-interrupt-controller" should be renamed
> to avoid interpreting it as a interrupt controller node.

Yep, I was completely misled by the remaining existence of the
wakup_eint [sic] label. I'll submit a patch to remove those.

Seems that things are working as appropriate with the gpio/pinctrl
binding. It's a little trickier to find out which interrupt specifier
to use since it requires one more lookup in the user manual, but
that's alright.


>> Do you have an example of a tested user or a testcase for this? I'm
>> trying to get interrupts going on these pins, and it's not looking like
>> it's even close to working.
>
> The following is a rudimentary patch with which I have tested wakeup
> interrupts GPX0[0] and GPX3[7] on smdk5250 board. The gpio number in
> the dts file can be changed to test wakeup interrupt on pins other
> than EINT31 (GPX3[7]).

Thanks!

-Olof


From cdall at cs.columbia.edu  Fri Apr 26 14:27:05 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Fri, 26 Apr 2013 11:27:05 -0700
Subject: [PATCH V3] ARM: KVM: Allow host virtual timer irq number to be
 different from guest virtual timer irq number
In-Reply-To: <CAAhSdy3XVRVp62xeuPp6Dum1OwvgmF1UKqwTqABUp71WS7ronw@mail.gmail.com>
References: <1366982847-11028-1-git-send-email-anup.patel@linaro.org>
 <517A8560.6070005@arm.com>
 <CAAhSdy3XVRVp62xeuPp6Dum1OwvgmF1UKqwTqABUp71WS7ronw@mail.gmail.com>
Message-ID: <CAEDV+g+a7zVnGBKJT9c+B_tiO8PEy-J2CQBWOxznMMrY1bDSOw@mail.gmail.com>

>
> Sure, I incorporate all above comments and send revised patch.
>
Hi Anup,

Now when we're at it, your commit message is exessively long, both the
title and the actual content. Please try to keep the commit message
under 80 chars at least and the title of the patch even shorter if
possible: think doing a 'git log' on an 80 char terminal...

-Christoffer


From anup at brainfault.org  Fri Apr 26 15:11:11 2013
From: anup at brainfault.org (Anup Patel)
Date: Sat, 27 Apr 2013 00:41:11 +0530
Subject: [PATCH V3] ARM: KVM: Allow host virtual timer irq number to be
 different from guest virtual timer irq number
In-Reply-To: <CAEDV+g+a7zVnGBKJT9c+B_tiO8PEy-J2CQBWOxznMMrY1bDSOw@mail.gmail.com>
References: <1366982847-11028-1-git-send-email-anup.patel@linaro.org>
 <517A8560.6070005@arm.com>
 <CAAhSdy3XVRVp62xeuPp6Dum1OwvgmF1UKqwTqABUp71WS7ronw@mail.gmail.com>
 <CAEDV+g+a7zVnGBKJT9c+B_tiO8PEy-J2CQBWOxznMMrY1bDSOw@mail.gmail.com>
Message-ID: <CAAhSdy0ZoN_3gyVLLbK6bVr8OJMyO1r3uLYe4S1v9PV7nWvNDQ@mail.gmail.com>

On Fri, Apr 26, 2013 at 11:57 PM, Christoffer Dall
<cdall at cs.columbia.edu> wrote:
>>
>> Sure, I incorporate all above comments and send revised patch.
>>
> Hi Anup,
>
> Now when we're at it, your commit message is exessively long, both the
> title and the actual content. Please try to keep the commit message
> under 80 chars at least and the title of the patch even shorter if
> possible: think doing a 'git log' on an 80 char terminal...
>
> -Christoffer

Oke, I'll keep the commit message shorter.

-Anup


From akpm at linux-foundation.org  Fri Apr 26 15:26:01 2013
From: akpm at linux-foundation.org (Andrew Morton)
Date: Fri, 26 Apr 2013 12:26:01 -0700
Subject: [PATCH V3 2/3] ARM: net: bpf_jit: make code generation less
 dependent on struct sk_filter.
In-Reply-To: <3592414.M8kQZLCXlW@wuerfel>
References: <1366824429-26652-1-git-send-email-nschichan@freebox.fr>
 <1366824429-26652-3-git-send-email-nschichan@freebox.fr>
 <3592414.M8kQZLCXlW@wuerfel>
Message-ID: <20130426122601.10ec05fcb4860df1b0a5b409@linux-foundation.org>

On Fri, 26 Apr 2013 16:04:44 +0200 Arnd Bergmann <arnd at arndb.de> wrote:

> On Wednesday 24 April 2013 19:27:08 Nicolas Schichan wrote:
> > @@ -858,7 +858,7 @@ b_epilogue:
> >  }
> >  
> >  
> > -void bpf_jit_compile(struct sk_filter *fp)
> > +static void __bpf_jit_compile(struct jit_ctx *out_ctx)
> >  {
> >         struct jit_ctx ctx;
> >         unsigned tmp_idx;
> > @@ -867,11 +867,10 @@ void bpf_jit_compile(struct sk_filter *fp)
> >         if (!bpf_jit_enable)
> >                 return;
> >  
> > -       memset(&ctx, 0, sizeof(ctx));
> > -       ctx.skf         = fp;
> > +       ctx = *out_ctx;
> >         ctx.ret0_fp_idx = -1;
> >  
> > -       ctx.offsets = kzalloc(4 * (ctx.skf->len + 1), GFP_KERNEL);
> > +       ctx.offsets = kzalloc(4 * (ctx.prog_len + 1), GFP_KERNEL);
> >         if (ctx.offsets == NULL)
> >                 return;
> >  
> > @@ -921,13 +920,26 @@ void bpf_jit_compile(struct sk_filter *fp)
> >                 print_hex_dump(KERN_INFO, "BPF JIT code: ",
> >                                DUMP_PREFIX_ADDRESS, 16, 4, ctx.target,
> >                                alloc_size, false);
> > -
> > -       fp->bpf_func = (void *)ctx.target;
> >  out:
> >         kfree(ctx.offsets);
> > +
> > +       *out_ctx = ctx;
> >         return;
> 
> This part of the patch, in combination with 79617801e "filter: bpf_jit_comp:
> refactor and unify BPF JIT image dump output" is now causing build errors
> in linux-next:
> 
> arch/arm/net/bpf_jit_32.c: In function '__bpf_jit_compile':
> arch/arm/net/bpf_jit_32.c:930:16: error: 'fp' undeclared (first use in this function)
>    bpf_jit_dump(fp->len, alloc_size, 2, ctx.target);

Thanks, I did this.  There may be a smarter way...

--- a/arch/arm/net/bpf_jit_32.c~arm-net-bpf_jit-make-code-generation-less-dependent-on-struct-sk_filter-fix
+++ a/arch/arm/net/bpf_jit_32.c
@@ -858,7 +858,7 @@ b_epilogue:
 }
 
 
-static void __bpf_jit_compile(struct jit_ctx *out_ctx)
+static void __bpf_jit_compile(struct sk_filter *fp, struct jit_ctx *out_ctx)
 {
 	struct jit_ctx ctx;
 	unsigned tmp_idx;
@@ -934,7 +934,7 @@ void bpf_jit_compile(struct sk_filter *f
 	ctx.prog_len = fp->len;
 	ctx.prog_insns = fp->insns;
 
-	__bpf_jit_compile(&ctx);
+	__bpf_jit_compile(fp, &ctx);
 	if (ctx.target)
 		fp->bpf_func = (void *)ctx.target;
 }
_



From dborkman at redhat.com  Fri Apr 26 15:47:46 2013
From: dborkman at redhat.com (Daniel Borkmann)
Date: Fri, 26 Apr 2013 21:47:46 +0200
Subject: [PATCH V3 2/3] ARM: net: bpf_jit: make code generation less
 dependent on struct sk_filter.
In-Reply-To: <20130426122601.10ec05fcb4860df1b0a5b409@linux-foundation.org>
References: <1366824429-26652-1-git-send-email-nschichan@freebox.fr>
 <1366824429-26652-3-git-send-email-nschichan@freebox.fr>
 <3592414.M8kQZLCXlW@wuerfel>
 <20130426122601.10ec05fcb4860df1b0a5b409@linux-foundation.org>
Message-ID: <517AD9E2.2090704@redhat.com>

On 04/26/2013 09:26 PM, Andrew Morton wrote:
> On Fri, 26 Apr 2013 16:04:44 +0200 Arnd Bergmann <arnd at arndb.de> wrote:
>> On Wednesday 24 April 2013 19:27:08 Nicolas Schichan wrote:
>>> @@ -858,7 +858,7 @@ b_epilogue:
>>>   }
>>>
>>>
>>> -void bpf_jit_compile(struct sk_filter *fp)
>>> +static void __bpf_jit_compile(struct jit_ctx *out_ctx)
>>>   {
>>>          struct jit_ctx ctx;
>>>          unsigned tmp_idx;
>>> @@ -867,11 +867,10 @@ void bpf_jit_compile(struct sk_filter *fp)
>>>          if (!bpf_jit_enable)
>>>                  return;
>>>
>>> -       memset(&ctx, 0, sizeof(ctx));
>>> -       ctx.skf         = fp;
>>> +       ctx = *out_ctx;
>>>          ctx.ret0_fp_idx = -1;
>>>
>>> -       ctx.offsets = kzalloc(4 * (ctx.skf->len + 1), GFP_KERNEL);
>>> +       ctx.offsets = kzalloc(4 * (ctx.prog_len + 1), GFP_KERNEL);
>>>          if (ctx.offsets == NULL)
>>>                  return;
>>>
>>> @@ -921,13 +920,26 @@ void bpf_jit_compile(struct sk_filter *fp)
>>>                  print_hex_dump(KERN_INFO, "BPF JIT code: ",
>>>                                 DUMP_PREFIX_ADDRESS, 16, 4, ctx.target,
>>>                                 alloc_size, false);
>>> -
>>> -       fp->bpf_func = (void *)ctx.target;
>>>   out:
>>>          kfree(ctx.offsets);
>>> +
>>> +       *out_ctx = ctx;
>>>          return;
>>
>> This part of the patch, in combination with 79617801e "filter: bpf_jit_comp:
>> refactor and unify BPF JIT image dump output" is now causing build errors
>> in linux-next:
>>
>> arch/arm/net/bpf_jit_32.c: In function '__bpf_jit_compile':
>> arch/arm/net/bpf_jit_32.c:930:16: error: 'fp' undeclared (first use in this function)
>>     bpf_jit_dump(fp->len, alloc_size, 2, ctx.target);
>
> Thanks, I did this.  There may be a smarter way...

I think also seccomp_jit_compile() would need this change then, otherwise the build
with CONFIG_SECCOMP_FILTER_JIT might break.

I can fix this up for you if not already applied. I presume it's against
linux-next tree?

> --- a/arch/arm/net/bpf_jit_32.c~arm-net-bpf_jit-make-code-generation-less-dependent-on-struct-sk_filter-fix
> +++ a/arch/arm/net/bpf_jit_32.c
> @@ -858,7 +858,7 @@ b_epilogue:
>   }
>
>
> -static void __bpf_jit_compile(struct jit_ctx *out_ctx)
> +static void __bpf_jit_compile(struct sk_filter *fp, struct jit_ctx *out_ctx)
>   {
>   	struct jit_ctx ctx;
>   	unsigned tmp_idx;
> @@ -934,7 +934,7 @@ void bpf_jit_compile(struct sk_filter *f
>   	ctx.prog_len = fp->len;
>   	ctx.prog_insns = fp->insns;
>
> -	__bpf_jit_compile(&ctx);
> +	__bpf_jit_compile(fp, &ctx);
>   	if (ctx.target)
>   		fp->bpf_func = (void *)ctx.target;
>   }
> _
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>


From sylvester.nawrocki at gmail.com  Fri Apr 26 16:02:14 2013
From: sylvester.nawrocki at gmail.com (Sylwester Nawrocki)
Date: Fri, 26 Apr 2013 22:02:14 +0200
Subject: [PATCH 0/9] s3c24xx LCD controller driver cleanup
Message-ID: <1367006543-5458-1-git-send-email-sylvester.nawrocki@gmail.com>

This patch series moves the s3c2410fb driver header files from 
arch/arm/mach-s3c24xx to the driver specific directories. It 
also includes couple cleanups to the driver itself and a patch 
actually enabling the display during initialization, so it works
with FRAMEBUFFER_CONSOLE disabled.

Patches 6...9 have no dependencies on rest of the series.

The whole series is also available at:
git://github.com/snawrocki/linux.git cleanup/s3c2410fb

It has been tested on the Micro2440 board.

Sylwester Nawrocki (9):
  s3c2410fb: Move platform data declarations to
    include/linux/platform_data
  s3c2410fb: Make most of register definitions local
  ARM: S3C24XX: Remove include/mach/regs-lcd.h header file
  s3c2410fb: Register single platform driver
  s3c2410fb: Use dev_pm_ops
  s3c2410fb: Enable display by default
  s3c2410fb: Use devm_ioremap_resource()
  s3c2410fb: Remove redundant platform_set_drvdata()
  s3c2410fb: Use module parameter instead of a sysfs entry

 arch/arm/mach-s3c24xx/dma-s3c2410.c             |    1 -
 arch/arm/mach-s3c24xx/dma-s3c2412.c             |    1 -
 arch/arm/mach-s3c24xx/dma-s3c2440.c             |    1 -
 arch/arm/mach-s3c24xx/dma-s3c2443.c             |    1 -
 arch/arm/mach-s3c24xx/include/mach/fb.h         |    1 -
 arch/arm/mach-s3c24xx/include/mach/regs-lcd.h   |  162 ----------------------
 arch/arm/mach-s3c24xx/mach-anubis.c             |    1 -
 arch/arm/mach-s3c24xx/mach-at2440evb.c          |    3 +-
 arch/arm/mach-s3c24xx/mach-bast.c               |    3 +-
 arch/arm/mach-s3c24xx/mach-gta02.c              |    2 +-
 arch/arm/mach-s3c24xx/mach-h1940.c              |    3 +-
 arch/arm/mach-s3c24xx/mach-jive.c               |    3 +-
 arch/arm/mach-s3c24xx/mach-mini2440.c           |    3 +-
 arch/arm/mach-s3c24xx/mach-n30.c                |    3 +-
 arch/arm/mach-s3c24xx/mach-osiris.c             |    1 -
 arch/arm/mach-s3c24xx/mach-qt2410.c             |    3 +-
 arch/arm/mach-s3c24xx/mach-rx1950.c             |    3 +-
 arch/arm/mach-s3c24xx/mach-smdk2413.c           |    3 +-
 arch/arm/mach-s3c24xx/mach-smdk2416.c           |    1 -
 arch/arm/mach-s3c24xx/mach-smdk2440.c           |    3 +-
 arch/arm/mach-s3c24xx/mach-smdk2443.c           |    3 +-
 arch/arm/mach-s3c24xx/mach-vstms.c              |    4 +-
 arch/arm/plat-samsung/devs.c                    |    2 +-
 arch/arm/plat-samsung/include/plat/fb-s3c2410.h |   72 ----------
 drivers/video/s3c2410fb.c                       |  165 ++++++-----------------
 drivers/video/s3c2410fb.h                       |  114 +++++++++++++++-
 include/linux/platform_data/fb-s3c2410.h        |  106 +++++++++++++++
 27 files changed, 272 insertions(+), 396 deletions(-)
 delete mode 100644 arch/arm/mach-s3c24xx/include/mach/fb.h
 delete mode 100644 arch/arm/mach-s3c24xx/include/mach/regs-lcd.h
 delete mode 100644 arch/arm/plat-samsung/include/plat/fb-s3c2410.h
 create mode 100644 include/linux/platform_data/fb-s3c2410.h

-- 
1.7.4.1



From sylvester.nawrocki at gmail.com  Fri Apr 26 16:02:15 2013
From: sylvester.nawrocki at gmail.com (Sylwester Nawrocki)
Date: Fri, 26 Apr 2013 22:02:15 +0200
Subject: [PATCH 1/9] s3c2410fb: Move platform data declarations to
 include/linux/platform_data
In-Reply-To: <1367006543-5458-1-git-send-email-sylvester.nawrocki@gmail.com>
References: <1367006543-5458-1-git-send-email-sylvester.nawrocki@gmail.com>
Message-ID: <1367006543-5458-2-git-send-email-sylvester.nawrocki@gmail.com>

Move the platform data structure declarations to include/linux/platform_data
where it's supposed to be placed, rather than in platform specific directories.

Signed-off-by: Sylwester Nawrocki <sylvester.nawrocki at gmail.com>
---
 arch/arm/mach-s3c24xx/include/mach/fb.h         |    1 -
 arch/arm/mach-s3c24xx/mach-at2440evb.c          |    2 +-
 arch/arm/mach-s3c24xx/mach-bast.c               |    2 +-
 arch/arm/mach-s3c24xx/mach-gta02.c              |    2 +-
 arch/arm/mach-s3c24xx/mach-h1940.c              |    2 +-
 arch/arm/mach-s3c24xx/mach-jive.c               |    2 +-
 arch/arm/mach-s3c24xx/mach-mini2440.c           |    2 +-
 arch/arm/mach-s3c24xx/mach-n30.c                |    2 +-
 arch/arm/mach-s3c24xx/mach-qt2410.c             |    2 +-
 arch/arm/mach-s3c24xx/mach-rx1950.c             |    2 +-
 arch/arm/mach-s3c24xx/mach-smdk2413.c           |    2 +-
 arch/arm/mach-s3c24xx/mach-smdk2440.c           |    2 +-
 arch/arm/mach-s3c24xx/mach-smdk2443.c           |    2 +-
 arch/arm/mach-s3c24xx/mach-vstms.c              |    3 +-
 arch/arm/plat-samsung/devs.c                    |    2 +-
 arch/arm/plat-samsung/include/plat/fb-s3c2410.h |   72 -----------------------
 drivers/video/s3c2410fb.c                       |    2 +-
 include/linux/platform_data/fb-s3c2410.h        |   72 +++++++++++++++++++++++
 18 files changed, 87 insertions(+), 89 deletions(-)
 delete mode 100644 arch/arm/mach-s3c24xx/include/mach/fb.h
 delete mode 100644 arch/arm/plat-samsung/include/plat/fb-s3c2410.h
 create mode 100644 include/linux/platform_data/fb-s3c2410.h

diff --git a/arch/arm/mach-s3c24xx/include/mach/fb.h b/arch/arm/mach-s3c24xx/include/mach/fb.h
deleted file mode 100644
index a957bc8e..0000000
--- a/arch/arm/mach-s3c24xx/include/mach/fb.h
+++ /dev/null
@@ -1 +0,0 @@
-#include <plat/fb-s3c2410.h>
diff --git a/arch/arm/mach-s3c24xx/mach-at2440evb.c b/arch/arm/mach-s3c24xx/mach-at2440evb.c
index 6dfeeb7..e4d71d5 100644
--- a/arch/arm/mach-s3c24xx/mach-at2440evb.c
+++ b/arch/arm/mach-s3c24xx/mach-at2440evb.c
@@ -29,7 +29,7 @@
 #include <asm/mach/irq.h>
 
 #include <mach/hardware.h>
-#include <mach/fb.h>
+#include <linux/platform_data/fb-s3c2410.h>
 #include <asm/irq.h>
 #include <asm/mach-types.h>
 
diff --git a/arch/arm/mach-s3c24xx/mach-bast.c b/arch/arm/mach-s3c24xx/mach-bast.c
index 22d6ae9..4402741 100644
--- a/arch/arm/mach-s3c24xx/mach-bast.c
+++ b/arch/arm/mach-s3c24xx/mach-bast.c
@@ -44,7 +44,7 @@
 #include <asm/mach/irq.h>
 #include <asm/mach-types.h>
 
-#include <mach/fb.h>
+#include <linux/platform_data/fb-s3c2410.h>
 #include <mach/hardware.h>
 #include <mach/regs-gpio.h>
 #include <mach/regs-lcd.h>
diff --git a/arch/arm/mach-s3c24xx/mach-gta02.c b/arch/arm/mach-s3c24xx/mach-gta02.c
index 13d8d07..cdad542 100644
--- a/arch/arm/mach-s3c24xx/mach-gta02.c
+++ b/arch/arm/mach-s3c24xx/mach-gta02.c
@@ -71,7 +71,7 @@
 #include <linux/platform_data/usb-ohci-s3c2410.h>
 #include <linux/platform_data/usb-s3c2410_udc.h>
 
-#include <mach/fb.h>
+#include <linux/platform_data/fb-s3c2410.h>
 #include <mach/hardware.h>
 #include <mach/regs-gpio.h>
 #include <mach/regs-irq.h>
diff --git a/arch/arm/mach-s3c24xx/mach-h1940.c b/arch/arm/mach-s3c24xx/mach-h1940.c
index af4334d..39ce53a 100644
--- a/arch/arm/mach-s3c24xx/mach-h1940.c
+++ b/arch/arm/mach-s3c24xx/mach-h1940.c
@@ -49,7 +49,7 @@
 
 #include <sound/uda1380.h>
 
-#include <mach/fb.h>
+#include <linux/platform_data/fb-s3c2410.h>
 #include <mach/hardware.h>
 #include <mach/regs-clock.h>
 #include <mach/regs-gpio.h>
diff --git a/arch/arm/mach-s3c24xx/mach-jive.c b/arch/arm/mach-s3c24xx/mach-jive.c
index a45fcd8..81e8e8c 100644
--- a/arch/arm/mach-s3c24xx/mach-jive.c
+++ b/arch/arm/mach-s3c24xx/mach-jive.c
@@ -37,7 +37,7 @@
 
 #include <mach/regs-gpio.h>
 #include <mach/regs-lcd.h>
-#include <mach/fb.h>
+#include <linux/platform_data/fb-s3c2410.h>
 
 #include <asm/mach-types.h>
 
diff --git a/arch/arm/mach-s3c24xx/mach-mini2440.c b/arch/arm/mach-s3c24xx/mach-mini2440.c
index a83db46..aa59f48 100644
--- a/arch/arm/mach-s3c24xx/mach-mini2440.c
+++ b/arch/arm/mach-s3c24xx/mach-mini2440.c
@@ -34,7 +34,7 @@
 #include <asm/mach/map.h>
 
 #include <mach/hardware.h>
-#include <mach/fb.h>
+#include <linux/platform_data/fb-s3c2410.h>
 #include <asm/mach-types.h>
 
 #include <plat/regs-serial.h>
diff --git a/arch/arm/mach-s3c24xx/mach-n30.c b/arch/arm/mach-s3c24xx/mach-n30.c
index 2cb46c3..3a32a75 100644
--- a/arch/arm/mach-s3c24xx/mach-n30.c
+++ b/arch/arm/mach-s3c24xx/mach-n30.c
@@ -32,7 +32,7 @@
 #include <asm/irq.h>
 #include <asm/mach-types.h>
 
-#include <mach/fb.h>
+#include <linux/platform_data/fb-s3c2410.h>
 #include <linux/platform_data/leds-s3c24xx.h>
 #include <mach/regs-gpio.h>
 #include <mach/regs-lcd.h>
diff --git a/arch/arm/mach-s3c24xx/mach-qt2410.c b/arch/arm/mach-s3c24xx/mach-qt2410.c
index f8feaea..65be582 100644
--- a/arch/arm/mach-s3c24xx/mach-qt2410.c
+++ b/arch/arm/mach-s3c24xx/mach-qt2410.c
@@ -50,7 +50,7 @@
 #include <linux/platform_data/leds-s3c24xx.h>
 #include <mach/regs-lcd.h>
 #include <plat/regs-serial.h>
-#include <mach/fb.h>
+#include <linux/platform_data/fb-s3c2410.h>
 #include <linux/platform_data/mtd-nand-s3c2410.h>
 #include <linux/platform_data/usb-s3c2410_udc.h>
 #include <linux/platform_data/i2c-s3c2410.h>
diff --git a/arch/arm/mach-s3c24xx/mach-rx1950.c b/arch/arm/mach-s3c24xx/mach-rx1950.c
index e4d67a3..17fad4b 100644
--- a/arch/arm/mach-s3c24xx/mach-rx1950.c
+++ b/arch/arm/mach-s3c24xx/mach-rx1950.c
@@ -48,7 +48,7 @@
 
 #include <sound/uda1380.h>
 
-#include <mach/fb.h>
+#include <linux/platform_data/fb-s3c2410.h>
 #include <mach/regs-gpio.h>
 #include <mach/regs-lcd.h>
 
diff --git a/arch/arm/mach-s3c24xx/mach-smdk2413.c b/arch/arm/mach-s3c24xx/mach-smdk2413.c
index 8146e92..d504272 100644
--- a/arch/arm/mach-s3c24xx/mach-smdk2413.c
+++ b/arch/arm/mach-s3c24xx/mach-smdk2413.c
@@ -39,7 +39,7 @@
 
 #include <linux/platform_data/usb-s3c2410_udc.h>
 #include <linux/platform_data/i2c-s3c2410.h>
-#include <mach/fb.h>
+#include <linux/platform_data/fb-s3c2410.h>
 
 #include <plat/clock.h>
 #include <plat/devs.h>
diff --git a/arch/arm/mach-s3c24xx/mach-smdk2440.c b/arch/arm/mach-s3c24xx/mach-smdk2440.c
index de2e5d3..8546941 100644
--- a/arch/arm/mach-s3c24xx/mach-smdk2440.c
+++ b/arch/arm/mach-s3c24xx/mach-smdk2440.c
@@ -35,7 +35,7 @@
 #include <mach/regs-gpio.h>
 #include <mach/regs-lcd.h>
 
-#include <mach/fb.h>
+#include <linux/platform_data/fb-s3c2410.h>
 #include <linux/platform_data/i2c-s3c2410.h>
 
 #include <plat/clock.h>
diff --git a/arch/arm/mach-s3c24xx/mach-smdk2443.c b/arch/arm/mach-s3c24xx/mach-smdk2443.c
index 9435c3b..5baa2e2 100644
--- a/arch/arm/mach-s3c24xx/mach-smdk2443.c
+++ b/arch/arm/mach-s3c24xx/mach-smdk2443.c
@@ -35,7 +35,7 @@
 #include <mach/regs-gpio.h>
 #include <mach/regs-lcd.h>
 
-#include <mach/fb.h>
+#include <linux/platform_data/fb-s3c2410.h>
 #include <linux/platform_data/i2c-s3c2410.h>
 
 #include <plat/clock.h>
diff --git a/arch/arm/mach-s3c24xx/mach-vstms.c b/arch/arm/mach-s3c24xx/mach-vstms.c
index b665884..86c9199 100644
--- a/arch/arm/mach-s3c24xx/mach-vstms.c
+++ b/arch/arm/mach-s3c24xx/mach-vstms.c
@@ -36,8 +36,7 @@
 #include <mach/regs-gpio.h>
 #include <mach/regs-lcd.h>
 
-#include <mach/fb.h>
-
+#include <linux/platform_data/fb-s3c2410.h>
 #include <linux/platform_data/i2c-s3c2410.h>
 #include <linux/platform_data/mtd-nand-s3c2410.h>
 
diff --git a/arch/arm/plat-samsung/devs.c b/arch/arm/plat-samsung/devs.c
index e1124d9..33c39bb 100644
--- a/arch/arm/plat-samsung/devs.c
+++ b/arch/arm/plat-samsung/devs.c
@@ -50,7 +50,7 @@
 #include <linux/platform_data/ata-samsung_cf.h>
 #include <linux/platform_data/usb-ehci-s5p.h>
 #include <plat/fb.h>
-#include <plat/fb-s3c2410.h>
+#include <linux/platform_data/fb-s3c2410.h>
 #include <plat/hdmi.h>
 #include <linux/platform_data/hwmon-s3c.h>
 #include <linux/platform_data/i2c-s3c2410.h>
diff --git a/arch/arm/plat-samsung/include/plat/fb-s3c2410.h b/arch/arm/plat-samsung/include/plat/fb-s3c2410.h
deleted file mode 100644
index 4e5d958..0000000
--- a/arch/arm/plat-samsung/include/plat/fb-s3c2410.h
+++ /dev/null
@@ -1,72 +0,0 @@
-/* arch/arm/plat-samsung/include/plat/fb-s3c2410.h
- *
- * Copyright (c) 2004 Arnaud Patard <arnaud.patard at rtp-net.org>
- *
- * Inspired by pxafb.h
- *
- * 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.
-*/
-
-#ifndef __ASM_PLAT_FB_S3C2410_H
-#define __ASM_PLAT_FB_S3C2410_H __FILE__
-
-struct s3c2410fb_hw {
-	unsigned long	lcdcon1;
-	unsigned long	lcdcon2;
-	unsigned long	lcdcon3;
-	unsigned long	lcdcon4;
-	unsigned long	lcdcon5;
-};
-
-/* LCD description */
-struct s3c2410fb_display {
-	/* LCD type */
-	unsigned type;
-
-	/* Screen size */
-	unsigned short width;
-	unsigned short height;
-
-	/* Screen info */
-	unsigned short xres;
-	unsigned short yres;
-	unsigned short bpp;
-
-	unsigned pixclock;		/* pixclock in picoseconds */
-	unsigned short left_margin;  /* value in pixels (TFT) or HCLKs (STN) */
-	unsigned short right_margin; /* value in pixels (TFT) or HCLKs (STN) */
-	unsigned short hsync_len;    /* value in pixels (TFT) or HCLKs (STN) */
-	unsigned short upper_margin;	/* value in lines (TFT) or 0 (STN) */
-	unsigned short lower_margin;	/* value in lines (TFT) or 0 (STN) */
-	unsigned short vsync_len;	/* value in lines (TFT) or 0 (STN) */
-
-	/* lcd configuration registers */
-	unsigned long	lcdcon5;
-};
-
-struct s3c2410fb_mach_info {
-
-	struct s3c2410fb_display *displays;	/* attached diplays info */
-	unsigned num_displays;			/* number of defined displays */
-	unsigned default_display;
-
-	/* GPIOs */
-
-	unsigned long	gpcup;
-	unsigned long	gpcup_mask;
-	unsigned long	gpccon;
-	unsigned long	gpccon_mask;
-	unsigned long	gpdup;
-	unsigned long	gpdup_mask;
-	unsigned long	gpdcon;
-	unsigned long	gpdcon_mask;
-
-	/* lpc3600 control register */
-	unsigned long	lpcsel;
-};
-
-extern void __init s3c24xx_fb_set_platdata(struct s3c2410fb_mach_info *);
-
-#endif /* __ASM_PLAT_FB_S3C2410_H */
diff --git a/drivers/video/s3c2410fb.c b/drivers/video/s3c2410fb.c
index 76a0e7f..dc10dbe 100644
--- a/drivers/video/s3c2410fb.c
+++ b/drivers/video/s3c2410fb.c
@@ -32,10 +32,10 @@
 
 #include <asm/div64.h>
 
+#include <linux/platform_data/fb-s3c2410.h>
 #include <asm/mach/map.h>
 #include <mach/regs-lcd.h>
 #include <mach/regs-gpio.h>
-#include <mach/fb.h>
 
 #ifdef CONFIG_PM
 #include <linux/pm.h>
diff --git a/include/linux/platform_data/fb-s3c2410.h b/include/linux/platform_data/fb-s3c2410.h
new file mode 100644
index 0000000..dbebc62
--- /dev/null
+++ b/include/linux/platform_data/fb-s3c2410.h
@@ -0,0 +1,72 @@
+/* arch/arm/plat-samsung/include/plat/fb-s3c2410.h
+ *
+ * Copyright (c) 2004 Arnaud Patard <arnaud.patard at rtp-net.org>
+ *
+ * Inspired by pxafb.h
+ *
+ * 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.
+*/
+
+#ifndef __FB_S3C2410_H
+#define __FB_S3C2410_H __FILE__
+
+struct s3c2410fb_hw {
+	unsigned long	lcdcon1;
+	unsigned long	lcdcon2;
+	unsigned long	lcdcon3;
+	unsigned long	lcdcon4;
+	unsigned long	lcdcon5;
+};
+
+/* LCD description */
+struct s3c2410fb_display {
+	/* LCD type */
+	unsigned type;
+
+	/* Screen size */
+	unsigned short width;
+	unsigned short height;
+
+	/* Screen info */
+	unsigned short xres;
+	unsigned short yres;
+	unsigned short bpp;
+
+	unsigned pixclock;		/* pixclock in picoseconds */
+	unsigned short left_margin;  /* value in pixels (TFT) or HCLKs (STN) */
+	unsigned short right_margin; /* value in pixels (TFT) or HCLKs (STN) */
+	unsigned short hsync_len;    /* value in pixels (TFT) or HCLKs (STN) */
+	unsigned short upper_margin;	/* value in lines (TFT) or 0 (STN) */
+	unsigned short lower_margin;	/* value in lines (TFT) or 0 (STN) */
+	unsigned short vsync_len;	/* value in lines (TFT) or 0 (STN) */
+
+	/* lcd configuration registers */
+	unsigned long	lcdcon5;
+};
+
+struct s3c2410fb_mach_info {
+
+	struct s3c2410fb_display *displays;	/* attached diplays info */
+	unsigned num_displays;			/* number of defined displays */
+	unsigned default_display;
+
+	/* GPIOs */
+
+	unsigned long	gpcup;
+	unsigned long	gpcup_mask;
+	unsigned long	gpccon;
+	unsigned long	gpccon_mask;
+	unsigned long	gpdup;
+	unsigned long	gpdup_mask;
+	unsigned long	gpdcon;
+	unsigned long	gpdcon_mask;
+
+	/* lpc3600 control register */
+	unsigned long	lpcsel;
+};
+
+extern void __init s3c24xx_fb_set_platdata(struct s3c2410fb_mach_info *);
+
+#endif /* __FB_S3C2410_H */
-- 
1.7.4.1



From robherring2 at gmail.com  Fri Apr 26 16:03:53 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Fri, 26 Apr 2013 15:03:53 -0500
Subject: [PATCH v2] of: Set the DMA mask to 64 bits when dma_addr_t is
 64-bits
In-Reply-To: <1366999565-19498-1-git-send-email-lauraa@codeaurora.org>
References: <1366999565-19498-1-git-send-email-lauraa@codeaurora.org>
Message-ID: <517ADDA9.7020701@gmail.com>

On 04/26/2013 01:06 PM, Laura Abbott wrote:
> Currently, of_platform_device_create_pdata always sets the
> coherent DMA mask to 32 bits. On ARM systems without CONFIG_ZONE_DMA,
> arm_dma_limit gets set to ~0 or 0xFFFFFFFFFFFFFFFF on LPAE based
> systems. Since arm_dma_limit represents the smallest dma_mask
> on the system, the default of 32 bits prevents any dma_coherent
> allocation from succeeding unless clients manually set the
> dma mask first. Rather than make every client on an LPAE system set
> the mask, set the mask to a 64 bit value on systems with 64-bit
> dma addresses.
> 
> Signed-off-by: Laura Abbott <lauraa at codeaurora.org>
> ---
>  drivers/of/platform.c |    4 ++++
>  1 files changed, 4 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/of/platform.c b/drivers/of/platform.c
> index 0970505..c669ab4 100644
> --- a/drivers/of/platform.c
> +++ b/drivers/of/platform.c
> @@ -214,7 +214,11 @@ struct platform_device *of_platform_device_create_pdata(
>  #if defined(CONFIG_MICROBLAZE)
>  	dev->archdata.dma_mask = 0xffffffffUL;
>  #endif
> +#ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT
> +	dev->dev.coherent_dma_mask = DMA_BIT_MASK(64);
> +#else
>  	dev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
> +#endif

How about "DMA_BIT_MASK(sizeof(dma_addr_t) * 8))" and avoid the ifdef.

Rob



From sylvester.nawrocki at gmail.com  Fri Apr 26 16:02:16 2013
From: sylvester.nawrocki at gmail.com (Sylwester Nawrocki)
Date: Fri, 26 Apr 2013 22:02:16 +0200
Subject: [PATCH 2/9] s3c2410fb: Make most of register definitions local
In-Reply-To: <1367006543-5458-1-git-send-email-sylvester.nawrocki@gmail.com>
References: <1367006543-5458-1-git-send-email-sylvester.nawrocki@gmail.com>
Message-ID: <1367006543-5458-3-git-send-email-sylvester.nawrocki@gmail.com>

Move most of the register definitions to the driver's private header file.
Some of the register bit field definitions are used in the platform data
structure and will be moved to include/linux/platform_data/fb-s3c2410.h
in subsequent patch.

Signed-off-by: Sylwester Nawrocki <sylvester.nawrocki at gmail.com>
---
 arch/arm/mach-s3c24xx/include/mach/regs-lcd.h |  110 ------------------------
 drivers/video/s3c2410fb.h                     |  114 ++++++++++++++++++++++++-
 2 files changed, 112 insertions(+), 112 deletions(-)

diff --git a/arch/arm/mach-s3c24xx/include/mach/regs-lcd.h b/arch/arm/mach-s3c24xx/include/mach/regs-lcd.h
index ee8f040..369511f 100644
--- a/arch/arm/mach-s3c24xx/include/mach/regs-lcd.h
+++ b/arch/arm/mach-s3c24xx/include/mach/regs-lcd.h
@@ -12,16 +12,6 @@
 #ifndef ___ASM_ARCH_REGS_LCD_H
 #define ___ASM_ARCH_REGS_LCD_H
 
-#define S3C2410_LCDREG(x)	(x)
-
-/* LCD control registers */
-#define S3C2410_LCDCON1	    S3C2410_LCDREG(0x00)
-#define S3C2410_LCDCON2	    S3C2410_LCDREG(0x04)
-#define S3C2410_LCDCON3	    S3C2410_LCDREG(0x08)
-#define S3C2410_LCDCON4	    S3C2410_LCDREG(0x0C)
-#define S3C2410_LCDCON5	    S3C2410_LCDREG(0x10)
-
-#define S3C2410_LCDCON1_CLKVAL(x)  ((x) << 8)
 #define S3C2410_LCDCON1_MMODE	   (1<<7)
 #define S3C2410_LCDCON1_DSCAN4	   (0<<5)
 #define S3C2410_LCDCON1_STN4	   (1<<5)
@@ -45,32 +35,6 @@
 
 #define S3C2410_LCDCON1_MODEMASK    0x1E
 
-#define S3C2410_LCDCON2_VBPD(x)	    ((x) << 24)
-#define S3C2410_LCDCON2_LINEVAL(x)  ((x) << 14)
-#define S3C2410_LCDCON2_VFPD(x)	    ((x) << 6)
-#define S3C2410_LCDCON2_VSPW(x)	    ((x) << 0)
-
-#define S3C2410_LCDCON2_GET_VBPD(x) ( ((x) >> 24) & 0xFF)
-#define S3C2410_LCDCON2_GET_VFPD(x) ( ((x) >>  6) & 0xFF)
-#define S3C2410_LCDCON2_GET_VSPW(x) ( ((x) >>  0) & 0x3F)
-
-#define S3C2410_LCDCON3_HBPD(x)	    ((x) << 19)
-#define S3C2410_LCDCON3_WDLY(x)	    ((x) << 19)
-#define S3C2410_LCDCON3_HOZVAL(x)   ((x) << 8)
-#define S3C2410_LCDCON3_HFPD(x)	    ((x) << 0)
-#define S3C2410_LCDCON3_LINEBLANK(x)((x) << 0)
-
-#define S3C2410_LCDCON3_GET_HBPD(x) ( ((x) >> 19) & 0x7F)
-#define S3C2410_LCDCON3_GET_HFPD(x) ( ((x) >>  0) & 0xFF)
-
-/* LDCCON4 changes for STN mode on the S3C2412 */
-
-#define S3C2410_LCDCON4_MVAL(x)	    ((x) << 8)
-#define S3C2410_LCDCON4_HSPW(x)	    ((x) << 0)
-#define S3C2410_LCDCON4_WLH(x)	    ((x) << 0)
-
-#define S3C2410_LCDCON4_GET_HSPW(x) ( ((x) >>  0) & 0xFF)
-
 #define S3C2410_LCDCON5_BPP24BL	    (1<<12)
 #define S3C2410_LCDCON5_FRM565	    (1<<11)
 #define S3C2410_LCDCON5_INVVCLK	    (1<<10)
@@ -85,78 +49,4 @@
 #define S3C2410_LCDCON5_BSWP	    (1<<1)
 #define S3C2410_LCDCON5_HWSWP	    (1<<0)
 
-/* framebuffer start addressed */
-#define S3C2410_LCDSADDR1   S3C2410_LCDREG(0x14)
-#define S3C2410_LCDSADDR2   S3C2410_LCDREG(0x18)
-#define S3C2410_LCDSADDR3   S3C2410_LCDREG(0x1C)
-
-#define S3C2410_LCDBANK(x)	((x) << 21)
-#define S3C2410_LCDBASEU(x)	(x)
-
-#define S3C2410_OFFSIZE(x)	((x) << 11)
-#define S3C2410_PAGEWIDTH(x)	(x)
-
-/* colour lookup and miscellaneous controls */
-
-#define S3C2410_REDLUT	   S3C2410_LCDREG(0x20)
-#define S3C2410_GREENLUT   S3C2410_LCDREG(0x24)
-#define S3C2410_BLUELUT	   S3C2410_LCDREG(0x28)
-
-#define S3C2410_DITHMODE   S3C2410_LCDREG(0x4C)
-#define S3C2410_TPAL	   S3C2410_LCDREG(0x50)
-
-#define S3C2410_TPAL_EN		(1<<24)
-
-/* interrupt info */
-#define S3C2410_LCDINTPND  S3C2410_LCDREG(0x54)
-#define S3C2410_LCDSRCPND  S3C2410_LCDREG(0x58)
-#define S3C2410_LCDINTMSK  S3C2410_LCDREG(0x5C)
-#define S3C2410_LCDINT_FIWSEL	(1<<2)
-#define	S3C2410_LCDINT_FRSYNC	(1<<1)
-#define S3C2410_LCDINT_FICNT	(1<<0)
-
-/* s3c2442 extra stn registers */
-
-#define S3C2442_REDLUT		S3C2410_LCDREG(0x20)
-#define S3C2442_GREENLUT	S3C2410_LCDREG(0x24)
-#define S3C2442_BLUELUT		S3C2410_LCDREG(0x28)
-#define S3C2442_DITHMODE	S3C2410_LCDREG(0x20)
-
-#define S3C2410_LPCSEL	   S3C2410_LCDREG(0x60)
-
-#define S3C2410_TFTPAL(x)  S3C2410_LCDREG((0x400 + (x)*4))
-
-/* S3C2412 registers */
-
-#define S3C2412_TPAL		S3C2410_LCDREG(0x20)
-
-#define S3C2412_LCDINTPND	S3C2410_LCDREG(0x24)
-#define S3C2412_LCDSRCPND	S3C2410_LCDREG(0x28)
-#define S3C2412_LCDINTMSK	S3C2410_LCDREG(0x2C)
-
-#define S3C2412_TCONSEL		S3C2410_LCDREG(0x30)
-
-#define S3C2412_LCDCON6		S3C2410_LCDREG(0x34)
-#define S3C2412_LCDCON7		S3C2410_LCDREG(0x38)
-#define S3C2412_LCDCON8		S3C2410_LCDREG(0x3C)
-#define S3C2412_LCDCON9		S3C2410_LCDREG(0x40)
-
-#define S3C2412_REDLUT(x)	S3C2410_LCDREG(0x44 + ((x)*4))
-#define S3C2412_GREENLUT(x)	S3C2410_LCDREG(0x60 + ((x)*4))
-#define S3C2412_BLUELUT(x)	S3C2410_LCDREG(0x98 + ((x)*4))
-
-#define S3C2412_FRCPAT(x)	S3C2410_LCDREG(0xB4 + ((x)*4))
-
-/* general registers */
-
-/* base of the LCD registers, where INTPND, INTSRC and then INTMSK
- * are available. */
-
-#define S3C2410_LCDINTBASE	S3C2410_LCDREG(0x54)
-#define S3C2412_LCDINTBASE	S3C2410_LCDREG(0x24)
-
-#define S3C24XX_LCDINTPND	(0x00)
-#define S3C24XX_LCDSRCPND	(0x04)
-#define S3C24XX_LCDINTMSK	(0x08)
-
 #endif /* ___ASM_ARCH_REGS_LCD_H */
diff --git a/drivers/video/s3c2410fb.h b/drivers/video/s3c2410fb.h
index 47a17bd..4e56b77 100644
--- a/drivers/video/s3c2410fb.h
+++ b/drivers/video/s3c2410fb.h
@@ -7,12 +7,122 @@
  * This file is subject to the terms and conditions of the GNU General Public
  * License.  See the file COPYING in the main directory of this archive for
  * more details.
- *
-*/
+ */
 
 #ifndef __S3C2410FB_H
 #define __S3C2410FB_H
 
+/* LCD control registers */
+#define S3C2410_LCDCON1			0x00
+#define S3C2410_LCDCON1_CLKVAL(x)	((x) << 8)
+#define S3C2410_LCDCON1_ENVID		1
+#define S3C2410_LCDCON1_MODEMASK	0x1e
+#define S3C2410_LCDCON1_MMODE		(1 << 7)
+
+#define S3C2410_LCDCON2			0x04
+#define S3C2410_LCDCON2_VBPD(x)		((x) << 24)
+#define S3C2410_LCDCON2_LINEVAL(x)	((x) << 14)
+#define S3C2410_LCDCON2_VFPD(x)		((x) << 6)
+#define S3C2410_LCDCON2_VSPW(x)		((x) << 0)
+
+#define S3C2410_LCDCON2_GET_VBPD(x)	(((x) >> 24) & 0xff)
+#define S3C2410_LCDCON2_GET_VFPD(x)	(((x) >>  6) & 0xff)
+#define S3C2410_LCDCON2_GET_VSPW(x)	(((x) >>  0) & 0x3f)
+
+#define S3C2410_LCDCON3			0x08
+#define S3C2410_LCDCON3_HBPD(x)		((x) << 19)
+#define S3C2410_LCDCON3_WDLY(x)		((x) << 19)
+#define S3C2410_LCDCON3_HOZVAL(x)	((x) << 8)
+#define S3C2410_LCDCON3_HFPD(x)		((x) << 0)
+#define S3C2410_LCDCON3_LINEBLANK(x)	((x) << 0)
+
+#define S3C2410_LCDCON3_GET_HBPD(x)	(((x) >> 19) & 0x7f)
+#define S3C2410_LCDCON3_GET_HFPD(x)	(((x) >>  0) & 0xff)
+
+/* LDCCON4 changes for STN mode on the S3C2412 */
+
+#define S3C2410_LCDCON4			0x0c
+#define S3C2410_LCDCON4_MVAL(x)		((x) << 8)
+#define S3C2410_LCDCON4_HSPW(x)		((x) << 0)
+#define S3C2410_LCDCON4_WLH(x)		((x) << 0)
+#define S3C2410_LCDCON4_GET_HSPW(x)	(((x) >>  0) & 0xff)
+
+#define S3C2410_LCDCON5			0x10
+
+/* framebuffer start addressed */
+#define S3C2410_LCDSADDR1		0x14
+#define S3C2410_LCDSADDR2		0x18
+#define S3C2410_LCDSADDR3		0x1c
+
+#define S3C2410_LCDBANK(x)		((x) << 21)
+#define S3C2410_LCDBASEU(x)		(x)
+
+#define S3C2410_OFFSIZE(x)		((x) << 11)
+#define S3C2410_PAGEWIDTH(x)		(x)
+
+/* colour lookup and miscellaneous controls */
+
+#define S3C2410_REDLUT			0x20
+#define S3C2410_GREENLUT		0x24
+#define S3C2410_BLUELUT			0x28
+
+#define S3C2410_DITHMODE		0x4c
+#define S3C2410_TPAL			0x50
+
+#define S3C2410_TPAL_EN			(1 << 24)
+
+/* interrupt info */
+#define S3C2410_LCDINTPND		0x54
+#define S3C2410_LCDSRCPND		0x58
+#define S3C2410_LCDINTMSK		0x5c
+#define S3C2410_LCDINT_FIWSEL		(1 << 2)
+#define S3C2410_LCDINT_FRSYNC		(1 << 1)
+#define S3C2410_LCDINT_FICNT		(1 << 0)
+
+/* s3c2442 extra stn registers */
+
+#define S3C2442_REDLUT			0x20
+#define S3C2442_GREENLUT		0x24
+#define S3C2442_BLUELUT			0x28
+#define S3C2442_DITHMODE		0x20
+
+#define S3C2410_LPCSEL			0x60
+
+#define S3C2410_TFTPAL(x)		(0x400 + ((x) * 4))
+
+/* S3C2412 registers */
+
+#define S3C2412_TPAL			0x20
+
+#define S3C2412_LCDINTPND		0x24
+#define S3C2412_LCDSRCPND		0x28
+#define S3C2412_LCDINTMSK		0x2c
+#define S3C2412_TCONSEL			0x30
+#define S3C2412_LCDCON6			0x34
+#define S3C2412_LCDCON7			0x38
+#define S3C2412_LCDCON8			0x3c
+#define S3C2412_LCDCON9			0x40
+
+#define S3C2412_REDLUT(x)		(0x44 + ((x) * 4))
+#define S3C2412_GREENLUT(x)		(0x60 + ((x) * 4))
+#define S3C2412_BLUELUT(x)		(0x98 + ((x) * 4))
+
+#define S3C2412_FRCPAT(x)		(0xb4 + ((x)*4))
+
+/* General registers. */
+
+/*
+ * Base of the LCD registers, where INTPND, INTSRC and then INTMSK
+ * are available.
+ */
+#define S3C2410_LCDINTBASE		0x54
+#define S3C2412_LCDINTBASE		0x24
+
+#define S3C24XX_LCDINTPND		0x00
+#define S3C24XX_LCDSRCPND		0x04
+#define S3C24XX_LCDINTMSK		0x08
+
+
 enum s3c_drv_type {
 	DRV_S3C2410,
 	DRV_S3C2412,
-- 
1.7.4.1



From sylvester.nawrocki at gmail.com  Fri Apr 26 16:02:18 2013
From: sylvester.nawrocki at gmail.com (Sylwester Nawrocki)
Date: Fri, 26 Apr 2013 22:02:18 +0200
Subject: [PATCH 4/9] s3c2410fb: Register single platform driver
In-Reply-To: <1367006543-5458-1-git-send-email-sylvester.nawrocki@gmail.com>
References: <1367006543-5458-1-git-send-email-sylvester.nawrocki@gmail.com>
Message-ID: <1367006543-5458-5-git-send-email-sylvester.nawrocki@gmail.com>

Use the id_table instead of registering two separate platform drivers.
This allows then to declare the driver with module_platform_driver().

Signed-off-by: Sylwester Nawrocki <sylvester.nawrocki at gmail.com>
---
 drivers/video/s3c2410fb.c |   59 +++++++++++---------------------------------
 1 files changed, 15 insertions(+), 44 deletions(-)

diff --git a/drivers/video/s3c2410fb.c b/drivers/video/s3c2410fb.c
index 12ac94e..d6706f7 100644
--- a/drivers/video/s3c2410fb.c
+++ b/drivers/video/s3c2410fb.c
@@ -818,8 +818,7 @@ static inline void s3c2410fb_cpufreq_deregister(struct s3c2410fb_info *info)
 
 static const char driver_name[] = "s3c2410fb";
 
-static int s3c24xxfb_probe(struct platform_device *pdev,
-			   enum s3c_drv_type drv_type)
+static int s3c2410fb_probe(struct platform_device *pdev)
 {
 	struct s3c2410fb_info *info;
 	struct s3c2410fb_display *display;
@@ -861,7 +860,7 @@ static int s3c24xxfb_probe(struct platform_device *pdev,
 
 	info = fbinfo->par;
 	info->dev = &pdev->dev;
-	info->drv_type = drv_type;
+	info->drv_type = platform_get_device_id(pdev)->driver_data;
 
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 	if (res == NULL) {
@@ -885,7 +884,7 @@ static int s3c24xxfb_probe(struct platform_device *pdev,
 		goto release_mem;
 	}
 
-	if (drv_type == DRV_S3C2412)
+	if (info->drv_type == DRV_S3C2412)
 		info->irq_base = info->io + S3C2412_LCDINTBASE;
 	else
 		info->irq_base = info->io + S3C2410_LCDINTBASE;
@@ -1009,17 +1008,6 @@ dealloc_fb:
 	return ret;
 }
 
-static int s3c2410fb_probe(struct platform_device *pdev)
-{
-	return s3c24xxfb_probe(pdev, DRV_S3C2410);
-}
-
-static int s3c2412fb_probe(struct platform_device *pdev)
-{
-	return s3c24xxfb_probe(pdev, DRV_S3C2412);
-}
-
-
 /*
  *  Cleanup
  */
@@ -1098,46 +1086,29 @@ static int s3c2410fb_resume(struct platform_device *dev)
 #define s3c2410fb_resume  NULL
 #endif
 
-static struct platform_driver s3c2410fb_driver = {
-	.probe		= s3c2410fb_probe,
-	.remove		= s3c2410fb_remove,
-	.suspend	= s3c2410fb_suspend,
-	.resume		= s3c2410fb_resume,
-	.driver		= {
-		.name	= "s3c2410-lcd",
-		.owner	= THIS_MODULE,
+static struct platform_device_id s3c2410fb_driver_ids[] = {
+	{
+		.name = "s3c2410-lcd",
+		.driver_data = (unsigned long)DRV_S3C2410,
+	}, {
+		.name = "s3c2412-lcd",
+		.driver_data = (unsigned long)DRV_S3C2412,
 	},
 };
 
-static struct platform_driver s3c2412fb_driver = {
-	.probe		= s3c2412fb_probe,
+static struct platform_driver s3c2410fb_driver = {
+	.probe		= s3c2410fb_probe,
 	.remove		= s3c2410fb_remove,
 	.suspend	= s3c2410fb_suspend,
 	.resume		= s3c2410fb_resume,
+	.id_table	= s3c2410fb_driver_ids,
 	.driver		= {
-		.name	= "s3c2412-lcd",
+		.name	= "s3c2410-lcd",
 		.owner	= THIS_MODULE,
 	},
 };
 
-int __init s3c2410fb_init(void)
-{
-	int ret = platform_driver_register(&s3c2410fb_driver);
-
-	if (ret == 0)
-		ret = platform_driver_register(&s3c2412fb_driver);
-
-	return ret;
-}
-
-static void __exit s3c2410fb_cleanup(void)
-{
-	platform_driver_unregister(&s3c2410fb_driver);
-	platform_driver_unregister(&s3c2412fb_driver);
-}
-
-module_init(s3c2410fb_init);
-module_exit(s3c2410fb_cleanup);
+module_platform_driver(s3c2410fb_driver);
 
 MODULE_AUTHOR("Arnaud Patard <arnaud.patard at rtp-net.org>");
 MODULE_AUTHOR("Ben Dooks <ben-linux at fluff.org>");
-- 
1.7.4.1



From sylvester.nawrocki at gmail.com  Fri Apr 26 16:02:17 2013
From: sylvester.nawrocki at gmail.com (Sylwester Nawrocki)
Date: Fri, 26 Apr 2013 22:02:17 +0200
Subject: [PATCH 3/9] ARM: S3C24XX: Remove include/mach/regs-lcd.h header file
In-Reply-To: <1367006543-5458-1-git-send-email-sylvester.nawrocki@gmail.com>
References: <1367006543-5458-1-git-send-email-sylvester.nawrocki@gmail.com>
Message-ID: <1367006543-5458-4-git-send-email-sylvester.nawrocki@gmail.com>

Move remaining s3c2410 LCD controller register bit field definitions
to the platform data header. Now the regs-lcd.h header can be removed
and inclusion of the mach specific header dropped from the driver.
Next step could be to redefine platform data structure, so register
specific definitions are private to the driver. Another possibility
is to add DT support, however these platforms will likely use ATAGS
for some time yet.

Signed-off-by: Sylwester Nawrocki <sylvester.nawrocki at gmail.com>
---
 arch/arm/mach-s3c24xx/dma-s3c2410.c           |    1 -
 arch/arm/mach-s3c24xx/dma-s3c2412.c           |    1 -
 arch/arm/mach-s3c24xx/dma-s3c2440.c           |    1 -
 arch/arm/mach-s3c24xx/dma-s3c2443.c           |    1 -
 arch/arm/mach-s3c24xx/include/mach/regs-lcd.h |   52 -------------------------
 arch/arm/mach-s3c24xx/mach-anubis.c           |    1 -
 arch/arm/mach-s3c24xx/mach-at2440evb.c        |    1 -
 arch/arm/mach-s3c24xx/mach-bast.c             |    1 -
 arch/arm/mach-s3c24xx/mach-h1940.c            |    1 -
 arch/arm/mach-s3c24xx/mach-jive.c             |    1 -
 arch/arm/mach-s3c24xx/mach-mini2440.c         |    1 -
 arch/arm/mach-s3c24xx/mach-n30.c              |    1 -
 arch/arm/mach-s3c24xx/mach-osiris.c           |    1 -
 arch/arm/mach-s3c24xx/mach-qt2410.c           |    1 -
 arch/arm/mach-s3c24xx/mach-rx1950.c           |    1 -
 arch/arm/mach-s3c24xx/mach-smdk2413.c         |    1 -
 arch/arm/mach-s3c24xx/mach-smdk2416.c         |    1 -
 arch/arm/mach-s3c24xx/mach-smdk2440.c         |    1 -
 arch/arm/mach-s3c24xx/mach-smdk2443.c         |    1 -
 arch/arm/mach-s3c24xx/mach-vstms.c            |    1 -
 drivers/video/s3c2410fb.c                     |    1 -
 include/linux/platform_data/fb-s3c2410.h      |   34 ++++++++++++++++
 22 files changed, 34 insertions(+), 72 deletions(-)
 delete mode 100644 arch/arm/mach-s3c24xx/include/mach/regs-lcd.h

diff --git a/arch/arm/mach-s3c24xx/dma-s3c2410.c b/arch/arm/mach-s3c24xx/dma-s3c2410.c
index a6c94b8..764556a 100644
--- a/arch/arm/mach-s3c24xx/dma-s3c2410.c
+++ b/arch/arm/mach-s3c24xx/dma-s3c2410.c
@@ -27,7 +27,6 @@
 #include <mach/regs-gpio.h>
 #include <plat/regs-ac97.h>
 #include <plat/regs-dma.h>
-#include <mach/regs-lcd.h>
 #include <plat/regs-iis.h>
 #include <plat/regs-spi.h>
 
diff --git a/arch/arm/mach-s3c24xx/dma-s3c2412.c b/arch/arm/mach-s3c24xx/dma-s3c2412.c
index c0e8c3f..f02fc3c 100644
--- a/arch/arm/mach-s3c24xx/dma-s3c2412.c
+++ b/arch/arm/mach-s3c24xx/dma-s3c2412.c
@@ -27,7 +27,6 @@
 #include <mach/regs-gpio.h>
 #include <plat/regs-ac97.h>
 #include <plat/regs-dma.h>
-#include <mach/regs-lcd.h>
 #include <plat/regs-iis.h>
 #include <plat/regs-spi.h>
 
diff --git a/arch/arm/mach-s3c24xx/dma-s3c2440.c b/arch/arm/mach-s3c24xx/dma-s3c2440.c
index 1c08eccd..b621563 100644
--- a/arch/arm/mach-s3c24xx/dma-s3c2440.c
+++ b/arch/arm/mach-s3c24xx/dma-s3c2440.c
@@ -27,7 +27,6 @@
 #include <mach/regs-gpio.h>
 #include <plat/regs-ac97.h>
 #include <plat/regs-dma.h>
-#include <mach/regs-lcd.h>
 #include <plat/regs-iis.h>
 #include <plat/regs-spi.h>
 
diff --git a/arch/arm/mach-s3c24xx/dma-s3c2443.c b/arch/arm/mach-s3c24xx/dma-s3c2443.c
index 000e4c6..095e841 100644
--- a/arch/arm/mach-s3c24xx/dma-s3c2443.c
+++ b/arch/arm/mach-s3c24xx/dma-s3c2443.c
@@ -27,7 +27,6 @@
 #include <mach/regs-gpio.h>
 #include <plat/regs-ac97.h>
 #include <plat/regs-dma.h>
-#include <mach/regs-lcd.h>
 #include <plat/regs-iis.h>
 #include <plat/regs-spi.h>
 
diff --git a/arch/arm/mach-s3c24xx/include/mach/regs-lcd.h b/arch/arm/mach-s3c24xx/include/mach/regs-lcd.h
deleted file mode 100644
index 369511f..0000000
--- a/arch/arm/mach-s3c24xx/include/mach/regs-lcd.h
+++ /dev/null
@@ -1,52 +0,0 @@
-/* arch/arm/mach-s3c2410/include/mach/regs-lcd.h
- *
- * Copyright (c) 2003 Simtec Electronics <linux at simtec.co.uk>
- *		      http://www.simtec.co.uk/products/SWLINUX/
- *
- * 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.
-*/
-
-
-#ifndef ___ASM_ARCH_REGS_LCD_H
-#define ___ASM_ARCH_REGS_LCD_H
-
-#define S3C2410_LCDCON1_MMODE	   (1<<7)
-#define S3C2410_LCDCON1_DSCAN4	   (0<<5)
-#define S3C2410_LCDCON1_STN4	   (1<<5)
-#define S3C2410_LCDCON1_STN8	   (2<<5)
-#define S3C2410_LCDCON1_TFT	   (3<<5)
-
-#define S3C2410_LCDCON1_STN1BPP	   (0<<1)
-#define S3C2410_LCDCON1_STN2GREY   (1<<1)
-#define S3C2410_LCDCON1_STN4GREY   (2<<1)
-#define S3C2410_LCDCON1_STN8BPP	   (3<<1)
-#define S3C2410_LCDCON1_STN12BPP   (4<<1)
-
-#define S3C2410_LCDCON1_TFT1BPP	   (8<<1)
-#define S3C2410_LCDCON1_TFT2BPP	   (9<<1)
-#define S3C2410_LCDCON1_TFT4BPP	   (10<<1)
-#define S3C2410_LCDCON1_TFT8BPP	   (11<<1)
-#define S3C2410_LCDCON1_TFT16BPP   (12<<1)
-#define S3C2410_LCDCON1_TFT24BPP   (13<<1)
-
-#define S3C2410_LCDCON1_ENVID	   (1)
-
-#define S3C2410_LCDCON1_MODEMASK    0x1E
-
-#define S3C2410_LCDCON5_BPP24BL	    (1<<12)
-#define S3C2410_LCDCON5_FRM565	    (1<<11)
-#define S3C2410_LCDCON5_INVVCLK	    (1<<10)
-#define S3C2410_LCDCON5_INVVLINE    (1<<9)
-#define S3C2410_LCDCON5_INVVFRAME   (1<<8)
-#define S3C2410_LCDCON5_INVVD	    (1<<7)
-#define S3C2410_LCDCON5_INVVDEN	    (1<<6)
-#define S3C2410_LCDCON5_INVPWREN    (1<<5)
-#define S3C2410_LCDCON5_INVLEND	    (1<<4)
-#define S3C2410_LCDCON5_PWREN	    (1<<3)
-#define S3C2410_LCDCON5_ENLEND	    (1<<2)
-#define S3C2410_LCDCON5_BSWP	    (1<<1)
-#define S3C2410_LCDCON5_HWSWP	    (1<<0)
-
-#endif /* ___ASM_ARCH_REGS_LCD_H */
diff --git a/arch/arm/mach-s3c24xx/mach-anubis.c b/arch/arm/mach-s3c24xx/mach-anubis.c
index c1fb6c3..d5e8cad 100644
--- a/arch/arm/mach-s3c24xx/mach-anubis.c
+++ b/arch/arm/mach-s3c24xx/mach-anubis.c
@@ -34,7 +34,6 @@
 
 #include <plat/regs-serial.h>
 #include <mach/regs-gpio.h>
-#include <mach/regs-lcd.h>
 #include <linux/platform_data/mtd-nand-s3c2410.h>
 #include <linux/platform_data/i2c-s3c2410.h>
 
diff --git a/arch/arm/mach-s3c24xx/mach-at2440evb.c b/arch/arm/mach-s3c24xx/mach-at2440evb.c
index e4d71d5..f151bf7 100644
--- a/arch/arm/mach-s3c24xx/mach-at2440evb.c
+++ b/arch/arm/mach-s3c24xx/mach-at2440evb.c
@@ -35,7 +35,6 @@
 
 #include <plat/regs-serial.h>
 #include <mach/regs-gpio.h>
-#include <mach/regs-lcd.h>
 #include <linux/platform_data/mtd-nand-s3c2410.h>
 #include <linux/platform_data/i2c-s3c2410.h>
 
diff --git a/arch/arm/mach-s3c24xx/mach-bast.c b/arch/arm/mach-s3c24xx/mach-bast.c
index 4402741..a500b21 100644
--- a/arch/arm/mach-s3c24xx/mach-bast.c
+++ b/arch/arm/mach-s3c24xx/mach-bast.c
@@ -47,7 +47,6 @@
 #include <linux/platform_data/fb-s3c2410.h>
 #include <mach/hardware.h>
 #include <mach/regs-gpio.h>
-#include <mach/regs-lcd.h>
 
 #include <plat/clock.h>
 #include <plat/cpu.h>
diff --git a/arch/arm/mach-s3c24xx/mach-h1940.c b/arch/arm/mach-s3c24xx/mach-h1940.c
index 39ce53a..0236201 100644
--- a/arch/arm/mach-s3c24xx/mach-h1940.c
+++ b/arch/arm/mach-s3c24xx/mach-h1940.c
@@ -53,7 +53,6 @@
 #include <mach/hardware.h>
 #include <mach/regs-clock.h>
 #include <mach/regs-gpio.h>
-#include <mach/regs-lcd.h>
 
 #include <plat/clock.h>
 #include <plat/cpu.h>
diff --git a/arch/arm/mach-s3c24xx/mach-jive.c b/arch/arm/mach-s3c24xx/mach-jive.c
index 81e8e8c..d1347ec 100644
--- a/arch/arm/mach-s3c24xx/mach-jive.c
+++ b/arch/arm/mach-s3c24xx/mach-jive.c
@@ -36,7 +36,6 @@
 #include <linux/platform_data/i2c-s3c2410.h>
 
 #include <mach/regs-gpio.h>
-#include <mach/regs-lcd.h>
 #include <linux/platform_data/fb-s3c2410.h>
 
 #include <asm/mach-types.h>
diff --git a/arch/arm/mach-s3c24xx/mach-mini2440.c b/arch/arm/mach-s3c24xx/mach-mini2440.c
index aa59f48..d0f25a4 100644
--- a/arch/arm/mach-s3c24xx/mach-mini2440.c
+++ b/arch/arm/mach-s3c24xx/mach-mini2440.c
@@ -40,7 +40,6 @@
 #include <plat/regs-serial.h>
 #include <mach/regs-gpio.h>
 #include <linux/platform_data/leds-s3c24xx.h>
-#include <mach/regs-lcd.h>
 #include <mach/irqs.h>
 #include <linux/platform_data/mtd-nand-s3c2410.h>
 #include <linux/platform_data/i2c-s3c2410.h>
diff --git a/arch/arm/mach-s3c24xx/mach-n30.c b/arch/arm/mach-s3c24xx/mach-n30.c
index 3a32a75..8b956b7 100644
--- a/arch/arm/mach-s3c24xx/mach-n30.c
+++ b/arch/arm/mach-s3c24xx/mach-n30.c
@@ -35,7 +35,6 @@
 #include <linux/platform_data/fb-s3c2410.h>
 #include <linux/platform_data/leds-s3c24xx.h>
 #include <mach/regs-gpio.h>
-#include <mach/regs-lcd.h>
 
 #include <asm/mach/arch.h>
 #include <asm/mach/irq.h>
diff --git a/arch/arm/mach-s3c24xx/mach-osiris.c b/arch/arm/mach-s3c24xx/mach-osiris.c
index 58d6fbe..eeca631 100644
--- a/arch/arm/mach-s3c24xx/mach-osiris.c
+++ b/arch/arm/mach-s3c24xx/mach-osiris.c
@@ -49,7 +49,6 @@
 
 #include <mach/hardware.h>
 #include <mach/regs-gpio.h>
-#include <mach/regs-lcd.h>
 
 #include "common.h"
 #include "osiris.h"
diff --git a/arch/arm/mach-s3c24xx/mach-qt2410.c b/arch/arm/mach-s3c24xx/mach-qt2410.c
index 65be582..7e11373 100644
--- a/arch/arm/mach-s3c24xx/mach-qt2410.c
+++ b/arch/arm/mach-s3c24xx/mach-qt2410.c
@@ -48,7 +48,6 @@
 #include <asm/mach-types.h>
 
 #include <linux/platform_data/leds-s3c24xx.h>
-#include <mach/regs-lcd.h>
 #include <plat/regs-serial.h>
 #include <linux/platform_data/fb-s3c2410.h>
 #include <linux/platform_data/mtd-nand-s3c2410.h>
diff --git a/arch/arm/mach-s3c24xx/mach-rx1950.c b/arch/arm/mach-s3c24xx/mach-rx1950.c
index 17fad4b..1ea1ce8 100644
--- a/arch/arm/mach-s3c24xx/mach-rx1950.c
+++ b/arch/arm/mach-s3c24xx/mach-rx1950.c
@@ -50,7 +50,6 @@
 
 #include <linux/platform_data/fb-s3c2410.h>
 #include <mach/regs-gpio.h>
-#include <mach/regs-lcd.h>
 
 #include <plat/clock.h>
 #include <plat/cpu.h>
diff --git a/arch/arm/mach-s3c24xx/mach-smdk2413.c b/arch/arm/mach-s3c24xx/mach-smdk2413.c
index d504272..9b473cb 100644
--- a/arch/arm/mach-s3c24xx/mach-smdk2413.c
+++ b/arch/arm/mach-s3c24xx/mach-smdk2413.c
@@ -35,7 +35,6 @@
 //#include <asm/debug-ll.h>
 #include <plat/regs-serial.h>
 #include <mach/regs-gpio.h>
-#include <mach/regs-lcd.h>
 
 #include <linux/platform_data/usb-s3c2410_udc.h>
 #include <linux/platform_data/i2c-s3c2410.h>
diff --git a/arch/arm/mach-s3c24xx/mach-smdk2416.c b/arch/arm/mach-s3c24xx/mach-smdk2416.c
index cb46847..5630d51 100644
--- a/arch/arm/mach-s3c24xx/mach-smdk2416.c
+++ b/arch/arm/mach-s3c24xx/mach-smdk2416.c
@@ -36,7 +36,6 @@
 
 #include <plat/regs-serial.h>
 #include <mach/regs-gpio.h>
-#include <mach/regs-lcd.h>
 #include <mach/regs-s3c2443-clock.h>
 
 #include <linux/platform_data/leds-s3c24xx.h>
diff --git a/arch/arm/mach-s3c24xx/mach-smdk2440.c b/arch/arm/mach-s3c24xx/mach-smdk2440.c
index 8546941..040e39b 100644
--- a/arch/arm/mach-s3c24xx/mach-smdk2440.c
+++ b/arch/arm/mach-s3c24xx/mach-smdk2440.c
@@ -33,7 +33,6 @@
 
 #include <plat/regs-serial.h>
 #include <mach/regs-gpio.h>
-#include <mach/regs-lcd.h>
 
 #include <linux/platform_data/fb-s3c2410.h>
 #include <linux/platform_data/i2c-s3c2410.h>
diff --git a/arch/arm/mach-s3c24xx/mach-smdk2443.c b/arch/arm/mach-s3c24xx/mach-smdk2443.c
index 5baa2e2..99a5c34 100644
--- a/arch/arm/mach-s3c24xx/mach-smdk2443.c
+++ b/arch/arm/mach-s3c24xx/mach-smdk2443.c
@@ -33,7 +33,6 @@
 
 #include <plat/regs-serial.h>
 #include <mach/regs-gpio.h>
-#include <mach/regs-lcd.h>
 
 #include <linux/platform_data/fb-s3c2410.h>
 #include <linux/platform_data/i2c-s3c2410.h>
diff --git a/arch/arm/mach-s3c24xx/mach-vstms.c b/arch/arm/mach-s3c24xx/mach-vstms.c
index 86c9199..92cd9ec 100644
--- a/arch/arm/mach-s3c24xx/mach-vstms.c
+++ b/arch/arm/mach-s3c24xx/mach-vstms.c
@@ -34,7 +34,6 @@
 
 #include <plat/regs-serial.h>
 #include <mach/regs-gpio.h>
-#include <mach/regs-lcd.h>
 
 #include <linux/platform_data/fb-s3c2410.h>
 #include <linux/platform_data/i2c-s3c2410.h>
diff --git a/drivers/video/s3c2410fb.c b/drivers/video/s3c2410fb.c
index dc10dbe..12ac94e 100644
--- a/drivers/video/s3c2410fb.c
+++ b/drivers/video/s3c2410fb.c
@@ -34,7 +34,6 @@
 
 #include <linux/platform_data/fb-s3c2410.h>
 #include <asm/mach/map.h>
-#include <mach/regs-lcd.h>
 #include <mach/regs-gpio.h>
 
 #ifdef CONFIG_PM
diff --git a/include/linux/platform_data/fb-s3c2410.h b/include/linux/platform_data/fb-s3c2410.h
index dbebc62..8e04d49 100644
--- a/include/linux/platform_data/fb-s3c2410.h
+++ b/include/linux/platform_data/fb-s3c2410.h
@@ -12,6 +12,40 @@
 #ifndef __FB_S3C2410_H
 #define __FB_S3C2410_H __FILE__
 
+#define S3C2410_LCDCON1_DSCAN4		(0 << 5)
+#define S3C2410_LCDCON1_STN4		(1 << 5)
+#define S3C2410_LCDCON1_STN8		(2 << 5)
+#define S3C2410_LCDCON1_TFT		(3 << 5)
+
+#define S3C2410_LCDCON1_STN1BPP		(0 << 1)
+#define S3C2410_LCDCON1_STN2GREY	(1 << 1)
+#define S3C2410_LCDCON1_STN4GREY	(2 << 1)
+#define S3C2410_LCDCON1_STN8BPP		(3 << 1)
+#define S3C2410_LCDCON1_STN12BPP	(4 << 1)
+
+#define S3C2410_LCDCON1_TFT1BPP		(8 << 1)
+#define S3C2410_LCDCON1_TFT2BPP		(9 << 1)
+#define S3C2410_LCDCON1_TFT4BPP		(10 << 1)
+#define S3C2410_LCDCON1_TFT8BPP		(11 << 1)
+#define S3C2410_LCDCON1_TFT16BPP	(12 << 1)
+#define S3C2410_LCDCON1_TFT24BPP	(13 << 1)
+
+
+#define S3C2410_LCDCON5_BPP24BL		(1 << 12)
+#define S3C2410_LCDCON5_FRM565		(1 << 11)
+#define S3C2410_LCDCON5_INVVCLK		(1 << 10)
+#define S3C2410_LCDCON5_INVVLINE	(1 << 9)
+#define S3C2410_LCDCON5_INVVFRAME	(1 << 8)
+#define S3C2410_LCDCON5_INVVD		(1 << 7)
+#define S3C2410_LCDCON5_INVVDEN		(1 << 6)
+#define S3C2410_LCDCON5_INVPWREN	(1 << 5)
+#define S3C2410_LCDCON5_INVLEND		(1 << 4)
+#define S3C2410_LCDCON5_PWREN		(1 << 3)
+#define S3C2410_LCDCON5_ENLEND		(1 << 2)
+#define S3C2410_LCDCON5_BSWP		(1 << 1)
+#define S3C2410_LCDCON5_HWSWP		(1 << 0)
+
+
 struct s3c2410fb_hw {
 	unsigned long	lcdcon1;
 	unsigned long	lcdcon2;
-- 
1.7.4.1



From sylvester.nawrocki at gmail.com  Fri Apr 26 16:02:19 2013
From: sylvester.nawrocki at gmail.com (Sylwester Nawrocki)
Date: Fri, 26 Apr 2013 22:02:19 +0200
Subject: [PATCH 5/9] s3c2410fb: Use dev_pm_ops
In-Reply-To: <1367006543-5458-1-git-send-email-sylvester.nawrocki@gmail.com>
References: <1367006543-5458-1-git-send-email-sylvester.nawrocki@gmail.com>
Message-ID: <1367006543-5458-6-git-send-email-sylvester.nawrocki@gmail.com>

Use the driver PM ops rather than legacy suspend/resume callbacks.
Also use CONFIG_PM_SLEEP switch to compile in the system sleep
code instead of CONFIG_PM.

Signed-off-by: Sylwester Nawrocki <sylvester.nawrocki at gmail.com>
---
 drivers/video/s3c2410fb.c |   20 ++++++++++----------
 1 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/video/s3c2410fb.c b/drivers/video/s3c2410fb.c
index d6706f7..479ab45 100644
--- a/drivers/video/s3c2410fb.c
+++ b/drivers/video/s3c2410fb.c
@@ -26,6 +26,7 @@
 #include <linux/dma-mapping.h>
 #include <linux/interrupt.h>
 #include <linux/platform_device.h>
+#include <linux/pm.h>
 #include <linux/clk.h>
 #include <linux/cpufreq.h>
 #include <linux/io.h>
@@ -36,10 +37,6 @@
 #include <asm/mach/map.h>
 #include <mach/regs-gpio.h>
 
-#ifdef CONFIG_PM
-#include <linux/pm.h>
-#endif
-
 #include "s3c2410fb.h"
 
 /* Debugging stuff */
@@ -1044,8 +1041,7 @@ static int s3c2410fb_remove(struct platform_device *pdev)
 	return 0;
 }
 
-#ifdef CONFIG_PM
-
+#ifdef CONFIG_PM_SLEEP
 /* suspend and resume support for the lcd controller */
 static int s3c2410fb_suspend(struct platform_device *dev, pm_message_t state)
 {
@@ -1081,9 +1077,14 @@ static int s3c2410fb_resume(struct platform_device *dev)
 	return 0;
 }
 
+static const struct dev_pm_ops s3c2410fb_pm_ops = {
+	.resume = s3c2410fb_resume,
+	.suspend = s3c2410fb_suspend,
+};
+
+#define S3C2410FB_PM_OPS (&s3c2410fb_pm_ops)
 #else
-#define s3c2410fb_suspend NULL
-#define s3c2410fb_resume  NULL
+#define S3C2410FB_PM_OPS (NULL)
 #endif
 
 static struct platform_device_id s3c2410fb_driver_ids[] = {
@@ -1099,12 +1100,11 @@ static struct platform_device_id s3c2410fb_driver_ids[] = {
 static struct platform_driver s3c2410fb_driver = {
 	.probe		= s3c2410fb_probe,
 	.remove		= s3c2410fb_remove,
-	.suspend	= s3c2410fb_suspend,
-	.resume		= s3c2410fb_resume,
 	.id_table	= s3c2410fb_driver_ids,
 	.driver		= {
 		.name	= "s3c2410-lcd",
 		.owner	= THIS_MODULE,
+		.pm	= S3C2410FB_PM_OPS,
 	},
 };
 
-- 
1.7.4.1



From sylvester.nawrocki at gmail.com  Fri Apr 26 16:02:20 2013
From: sylvester.nawrocki at gmail.com (Sylwester Nawrocki)
Date: Fri, 26 Apr 2013 22:02:20 +0200
Subject: [PATCH 6/9] s3c2410fb: Enable display by default
In-Reply-To: <1367006543-5458-1-git-send-email-sylvester.nawrocki@gmail.com>
References: <1367006543-5458-1-git-send-email-sylvester.nawrocki@gmail.com>
Message-ID: <1367006543-5458-7-git-send-email-sylvester.nawrocki@gmail.com>

Enable the display with default configuration at system start up.
This ensures the display is activated also when FRAMBUFFER_CONSOLE
is not set.

Signed-off-by: Sylwester Nawrocki <sylvester.nawrocki at gmail.com>
---
 drivers/video/s3c2410fb.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/video/s3c2410fb.c b/drivers/video/s3c2410fb.c
index 479ab45..da8b6c2 100644
--- a/drivers/video/s3c2410fb.c
+++ b/drivers/video/s3c2410fb.c
@@ -969,6 +969,8 @@ static int s3c2410fb_probe(struct platform_device *pdev)
 		goto free_video_memory;
 	}
 
+	s3c2410fb_set_par(fbinfo);
+
 	ret = register_framebuffer(fbinfo);
 	if (ret < 0) {
 		dev_err(&pdev->dev, "Failed to register framebuffer device: %d\n",
-- 
1.7.4.1



From sylvester.nawrocki at gmail.com  Fri Apr 26 16:02:21 2013
From: sylvester.nawrocki at gmail.com (Sylwester Nawrocki)
Date: Fri, 26 Apr 2013 22:02:21 +0200
Subject: [PATCH 7/9] s3c2410fb: Use devm_ioremap_resource()
In-Reply-To: <1367006543-5458-1-git-send-email-sylvester.nawrocki@gmail.com>
References: <1367006543-5458-1-git-send-email-sylvester.nawrocki@gmail.com>
Message-ID: <1367006543-5458-8-git-send-email-sylvester.nawrocki@gmail.com>

Use devm_ioremap_resource instead of reques_mem_region()/ioremap().
This ensures more consistent error values and simplifies error paths.

Signed-off-by: Sylwester Nawrocki <sylvester.nawrocki at gmail.com>
---
 drivers/video/s3c2410fb.c |   32 ++++----------------------------
 1 files changed, 4 insertions(+), 28 deletions(-)

diff --git a/drivers/video/s3c2410fb.c b/drivers/video/s3c2410fb.c
index da8b6c2..11f98ca 100644
--- a/drivers/video/s3c2410fb.c
+++ b/drivers/video/s3c2410fb.c
@@ -825,7 +825,6 @@ static int s3c2410fb_probe(struct platform_device *pdev)
 	int ret;
 	int irq;
 	int i;
-	int size;
 	u32 lcdcon1;
 
 	mach_info = pdev->dev.platform_data;
@@ -860,27 +859,12 @@ static int s3c2410fb_probe(struct platform_device *pdev)
 	info->drv_type = platform_get_device_id(pdev)->driver_data;
 
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-	if (res == NULL) {
-		dev_err(&pdev->dev, "failed to get memory registers\n");
-		ret = -ENXIO;
+	info->io = devm_ioremap_resource(&pdev->dev, res);
+	if (IS_ERR(info->io)) {
+		ret = PTR_ERR(info->io);
 		goto dealloc_fb;
 	}
 
-	size = resource_size(res);
-	info->mem = request_mem_region(res->start, size, pdev->name);
-	if (info->mem == NULL) {
-		dev_err(&pdev->dev, "failed to get memory region\n");
-		ret = -ENOENT;
-		goto dealloc_fb;
-	}
-
-	info->io = ioremap(res->start, size);
-	if (info->io == NULL) {
-		dev_err(&pdev->dev, "ioremap() of registers failed\n");
-		ret = -ENXIO;
-		goto release_mem;
-	}
-
 	if (info->drv_type == DRV_S3C2412)
 		info->irq_base = info->io + S3C2412_LCDINTBASE;
 	else
@@ -917,7 +901,7 @@ static int s3c2410fb_probe(struct platform_device *pdev)
 	if (ret) {
 		dev_err(&pdev->dev, "cannot get irq %d - err %d\n", irq, ret);
 		ret = -EBUSY;
-		goto release_regs;
+		goto dealloc_fb;
 	}
 
 	info->clk = clk_get(NULL, "lcd");
@@ -997,10 +981,6 @@ release_clock:
 	clk_put(info->clk);
 release_irq:
 	free_irq(irq, info);
-release_regs:
-	iounmap(info->io);
-release_mem:
-	release_mem_region(res->start, size);
 dealloc_fb:
 	platform_set_drvdata(pdev, NULL);
 	framebuffer_release(fbinfo);
@@ -1033,10 +1013,6 @@ static int s3c2410fb_remove(struct platform_device *pdev)
 	irq = platform_get_irq(pdev, 0);
 	free_irq(irq, info);
 
-	iounmap(info->io);
-
-	release_mem_region(info->mem->start, resource_size(info->mem));
-
 	platform_set_drvdata(pdev, NULL);
 	framebuffer_release(fbinfo);
 
-- 
1.7.4.1



From sylvester.nawrocki at gmail.com  Fri Apr 26 16:02:22 2013
From: sylvester.nawrocki at gmail.com (Sylwester Nawrocki)
Date: Fri, 26 Apr 2013 22:02:22 +0200
Subject: [PATCH 8/9] s3c2410fb: Remove redundant platform_set_drvdata()
In-Reply-To: <1367006543-5458-1-git-send-email-sylvester.nawrocki@gmail.com>
References: <1367006543-5458-1-git-send-email-sylvester.nawrocki@gmail.com>
Message-ID: <1367006543-5458-9-git-send-email-sylvester.nawrocki@gmail.com>

driver_data field is being cleared by the driver core since
commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
device-core: Ensure drvdata = NULL when no driver is bound
hence there is no need to do it in the driver's remove() callback.

Signed-off-by: Sylwester Nawrocki <sylvester.nawrocki at gmail.com>
---
 drivers/video/s3c2410fb.c |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/drivers/video/s3c2410fb.c b/drivers/video/s3c2410fb.c
index 11f98ca..0439ed0 100644
--- a/drivers/video/s3c2410fb.c
+++ b/drivers/video/s3c2410fb.c
@@ -1013,7 +1013,6 @@ static int s3c2410fb_remove(struct platform_device *pdev)
 	irq = platform_get_irq(pdev, 0);
 	free_irq(irq, info);
 
-	platform_set_drvdata(pdev, NULL);
 	framebuffer_release(fbinfo);
 
 	return 0;
-- 
1.7.4.1



From sylvester.nawrocki at gmail.com  Fri Apr 26 16:02:23 2013
From: sylvester.nawrocki at gmail.com (Sylwester Nawrocki)
Date: Fri, 26 Apr 2013 22:02:23 +0200
Subject: [PATCH 9/9] s3c2410fb: Use module parameter instead of a sysfs entry
In-Reply-To: <1367006543-5458-1-git-send-email-sylvester.nawrocki@gmail.com>
References: <1367006543-5458-1-git-send-email-sylvester.nawrocki@gmail.com>
Message-ID: <1367006543-5458-10-git-send-email-sylvester.nawrocki@gmail.com>

Use module parameter to set debug level instead of a sysfs
entry. Replace pr_debug() with pr_info() so we can actually
control the debug traces without DYNAMIC_PRINTK. This fixes
a sort of regression introduced in commit 81c1655811e941af2
video: s3c2410: Use pr_* and dev_* instead of printk

Signed-off-by: Sylwester Nawrocki <sylvester.nawrocki at gmail.com>
---
 drivers/video/s3c2410fb.c |   48 +++++++-------------------------------------
 1 files changed, 8 insertions(+), 40 deletions(-)

diff --git a/drivers/video/s3c2410fb.c b/drivers/video/s3c2410fb.c
index 0439ed0..c2ee75a 100644
--- a/drivers/video/s3c2410fb.c
+++ b/drivers/video/s3c2410fb.c
@@ -46,10 +46,13 @@ static int debug	= 1;
 static int debug;
 #endif
 
-#define dprintk(msg...) \
-do { \
-	if (debug) \
-		pr_debug(msg); \
+module_param(debug, int, 0644);
+MODULE_PARM_DESC(debug, "Debug level (0-1)");
+
+#define dprintk(msg...)		\
+do { 				\
+	if (debug)		\
+		pr_info(msg);	\
 } while (0)
 
 /* useful functions */
@@ -584,36 +587,6 @@ static int s3c2410fb_blank(int blank_mode, struct fb_info *info)
 	return 0;
 }
 
-static int s3c2410fb_debug_show(struct device *dev,
-				struct device_attribute *attr, char *buf)
-{
-	return snprintf(buf, PAGE_SIZE, "%s\n", debug ? "on" : "off");
-}
-
-static int s3c2410fb_debug_store(struct device *dev,
-				 struct device_attribute *attr,
-				 const char *buf, size_t len)
-{
-	if (len < 1)
-		return -EINVAL;
-
-	if (strnicmp(buf, "on", 2) == 0 ||
-	    strnicmp(buf, "1", 1) == 0) {
-		debug = 1;
-		dev_dbg(dev, "s3c2410fb: Debug On");
-	} else if (strnicmp(buf, "off", 3) == 0 ||
-		   strnicmp(buf, "0", 1) == 0) {
-		debug = 0;
-		dev_dbg(dev, "s3c2410fb: Debug Off");
-	} else {
-		return -EINVAL;
-	}
-
-	return len;
-}
-
-static DEVICE_ATTR(debug, 0666, s3c2410fb_debug_show, s3c2410fb_debug_store);
-
 static struct fb_ops s3c2410fb_ops = {
 	.owner		= THIS_MODULE,
 	.fb_check_var	= s3c2410fb_check_var,
@@ -962,17 +935,12 @@ static int s3c2410fb_probe(struct platform_device *pdev)
 		goto free_cpufreq;
 	}
 
-	/* create device files */
-	ret = device_create_file(&pdev->dev, &dev_attr_debug);
-	if (ret)
-		dev_err(&pdev->dev, "failed to add debug attribute\n");
-
 	dev_info(&pdev->dev, "fb%d: %s frame buffer device\n",
 		fbinfo->node, fbinfo->fix.id);
 
 	return 0;
 
- free_cpufreq:
+free_cpufreq:
 	s3c2410fb_cpufreq_deregister(info);
 free_video_memory:
 	s3c2410fb_unmap_video_memory(fbinfo);
-- 
1.7.4.1



From akpm at linux-foundation.org  Fri Apr 26 16:09:48 2013
From: akpm at linux-foundation.org (Andrew Morton)
Date: Fri, 26 Apr 2013 13:09:48 -0700
Subject: [PATCH V3 2/3] ARM: net: bpf_jit: make code generation less
 dependent on struct sk_filter.
In-Reply-To: <517AD9E2.2090704@redhat.com>
References: <1366824429-26652-1-git-send-email-nschichan@freebox.fr>
 <1366824429-26652-3-git-send-email-nschichan@freebox.fr>
 <3592414.M8kQZLCXlW@wuerfel>
 <20130426122601.10ec05fcb4860df1b0a5b409@linux-foundation.org>
 <517AD9E2.2090704@redhat.com>
Message-ID: <20130426130948.cbfd2f6256afc0e3ee7abeed@linux-foundation.org>

On Fri, 26 Apr 2013 21:47:46 +0200 Daniel Borkmann <dborkman at redhat.com> wrote:

> On 04/26/2013 09:26 PM, Andrew Morton wrote:
> > On Fri, 26 Apr 2013 16:04:44 +0200 Arnd Bergmann <arnd at arndb.de> wrote:
> >> On Wednesday 24 April 2013 19:27:08 Nicolas Schichan wrote:
> >>> @@ -858,7 +858,7 @@ b_epilogue:
> >>>   }
> >>>
> >>>
> >>> -void bpf_jit_compile(struct sk_filter *fp)
> >>> +static void __bpf_jit_compile(struct jit_ctx *out_ctx)
> >>>   {
> >>>          struct jit_ctx ctx;
> >>>          unsigned tmp_idx;
> >>> @@ -867,11 +867,10 @@ void bpf_jit_compile(struct sk_filter *fp)
> >>>          if (!bpf_jit_enable)
> >>>                  return;
> >>>
> >>> -       memset(&ctx, 0, sizeof(ctx));
> >>> -       ctx.skf         = fp;
> >>> +       ctx = *out_ctx;
> >>>          ctx.ret0_fp_idx = -1;
> >>>
> >>> -       ctx.offsets = kzalloc(4 * (ctx.skf->len + 1), GFP_KERNEL);
> >>> +       ctx.offsets = kzalloc(4 * (ctx.prog_len + 1), GFP_KERNEL);
> >>>          if (ctx.offsets == NULL)
> >>>                  return;
> >>>
> >>> @@ -921,13 +920,26 @@ void bpf_jit_compile(struct sk_filter *fp)
> >>>                  print_hex_dump(KERN_INFO, "BPF JIT code: ",
> >>>                                 DUMP_PREFIX_ADDRESS, 16, 4, ctx.target,
> >>>                                 alloc_size, false);
> >>> -
> >>> -       fp->bpf_func = (void *)ctx.target;
> >>>   out:
> >>>          kfree(ctx.offsets);
> >>> +
> >>> +       *out_ctx = ctx;
> >>>          return;
> >>
> >> This part of the patch, in combination with 79617801e "filter: bpf_jit_comp:
> >> refactor and unify BPF JIT image dump output" is now causing build errors
> >> in linux-next:
> >>
> >> arch/arm/net/bpf_jit_32.c: In function '__bpf_jit_compile':
> >> arch/arm/net/bpf_jit_32.c:930:16: error: 'fp' undeclared (first use in this function)
> >>     bpf_jit_dump(fp->len, alloc_size, 2, ctx.target);
> >
> > Thanks, I did this.  There may be a smarter way...
> 
> I think also seccomp_jit_compile() would need this change then, otherwise the build
> with CONFIG_SECCOMP_FILTER_JIT might break.

urgh, that tears it.

> I can fix this up for you if not already applied. I presume it's against
> linux-next tree?

Yup, please send something.



From lauraa at codeaurora.org  Fri Apr 26 16:14:49 2013
From: lauraa at codeaurora.org (Laura Abbott)
Date: Fri, 26 Apr 2013 13:14:49 -0700
Subject: [PATCH v2] of: Set the DMA mask to 64 bits when dma_addr_t is
 64-bits
In-Reply-To: <517ADDA9.7020701@gmail.com>
References: <1366999565-19498-1-git-send-email-lauraa@codeaurora.org>
 <517ADDA9.7020701@gmail.com>
Message-ID: <517AE039.8070804@codeaurora.org>

On 4/26/2013 1:03 PM, Rob Herring wrote:
> On 04/26/2013 01:06 PM, Laura Abbott wrote:
>> Currently, of_platform_device_create_pdata always sets the
>> coherent DMA mask to 32 bits. On ARM systems without CONFIG_ZONE_DMA,
>> arm_dma_limit gets set to ~0 or 0xFFFFFFFFFFFFFFFF on LPAE based
>> systems. Since arm_dma_limit represents the smallest dma_mask
>> on the system, the default of 32 bits prevents any dma_coherent
>> allocation from succeeding unless clients manually set the
>> dma mask first. Rather than make every client on an LPAE system set
>> the mask, set the mask to a 64 bit value on systems with 64-bit
>> dma addresses.
>>
>> Signed-off-by: Laura Abbott <lauraa at codeaurora.org>
>> ---
>>   drivers/of/platform.c |    4 ++++
>>   1 files changed, 4 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/of/platform.c b/drivers/of/platform.c
>> index 0970505..c669ab4 100644
>> --- a/drivers/of/platform.c
>> +++ b/drivers/of/platform.c
>> @@ -214,7 +214,11 @@ struct platform_device *of_platform_device_create_pdata(
>>   #if defined(CONFIG_MICROBLAZE)
>>   	dev->archdata.dma_mask = 0xffffffffUL;
>>   #endif
>> +#ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT
>> +	dev->dev.coherent_dma_mask = DMA_BIT_MASK(64);
>> +#else
>>   	dev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
>> +#endif
>
> How about "DMA_BIT_MASK(sizeof(dma_addr_t) * 8))" and avoid the ifdef.
>

Sounds good.


> Rob
>

Thanks,
Laura

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation


From arnd at arndb.de  Fri Apr 26 16:26:26 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 26 Apr 2013 22:26:26 +0200
Subject: [PATCH v2 1/3] GPIO: clps711x: Rewrite driver for using generic
 GPIO code
In-Reply-To: <1366991250-17130-1-git-send-email-shc_work@mail.ru>
References: <1366991250-17130-1-git-send-email-shc_work@mail.ru>
Message-ID: <201304262226.26241.arnd@arndb.de>

On Friday 26 April 2013, Alexander Shiyan wrote:
> This patch provides rewritten driver for CLPS711X GPIO which uses
> generic GPIO code.
> 
> Signed-off-by: Alexander Shiyan <shc_work at mail.ru>

All three patches

Acked-by: Arnd Bergmann <arnd at arndb.de>


From lauraa at codeaurora.org  Fri Apr 26 16:31:06 2013
From: lauraa at codeaurora.org (Laura Abbott)
Date: Fri, 26 Apr 2013 13:31:06 -0700
Subject: [PATCH V3] of: Set the DMA mask to 64 bits when dma_addr_t is 64-bits
Message-ID: <1367008266-1431-1-git-send-email-lauraa@codeaurora.org>

Currently, of_platform_device_create_pdata always sets the
coherent DMA mask to 32 bits. On ARM systems without CONFIG_ZONE_DMA,
arm_dma_limit gets set to ~0 or 0xFFFFFFFFFFFFFFFF on LPAE based
systems. Since arm_dma_limit represents the smallest dma_mask
on the system, the default of 32 bits prevents any dma_coherent
allocation from succeeding unless clients manually set the
dma mask first. Rather than make every client on an LPAE system set
the mask manually, account for the size of dma_addr_t when setting
the coherent mask.

Signed-off-by: Laura Abbott <lauraa at codeaurora.org>
---
 drivers/of/platform.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index 0970505..5f0ba94 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -214,7 +214,7 @@ struct platform_device *of_platform_device_create_pdata(
 #if defined(CONFIG_MICROBLAZE)
 	dev->archdata.dma_mask = 0xffffffffUL;
 #endif
-	dev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
+	dev->dev.coherent_dma_mask = DMA_BIT_MASK(sizeof(dma_addr_t) * 8);
 	dev->dev.bus = &platform_bus_type;
 	dev->dev.platform_data = platform_data;
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From cdall at cs.columbia.edu  Fri Apr 26 16:39:09 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Fri, 26 Apr 2013 13:39:09 -0700
Subject: [PATCH V3] ARM: KVM: Allow host virtual timer irq number to be
 different from guest virtual timer irq number
In-Reply-To: <CAAhSdy0ZoN_3gyVLLbK6bVr8OJMyO1r3uLYe4S1v9PV7nWvNDQ@mail.gmail.com>
References: <1366982847-11028-1-git-send-email-anup.patel@linaro.org>
 <517A8560.6070005@arm.com>
 <CAAhSdy3XVRVp62xeuPp6Dum1OwvgmF1UKqwTqABUp71WS7ronw@mail.gmail.com>
 <CAEDV+g+a7zVnGBKJT9c+B_tiO8PEy-J2CQBWOxznMMrY1bDSOw@mail.gmail.com>
 <CAAhSdy0ZoN_3gyVLLbK6bVr8OJMyO1r3uLYe4S1v9PV7nWvNDQ@mail.gmail.com>
Message-ID: <CAEDV+gLfG9Yb8rexSbO9o9=Ef7wxCd7i2CSeFuspGiH4KpRwww@mail.gmail.com>

On Fri, Apr 26, 2013 at 12:11 PM, Anup Patel <anup at brainfault.org> wrote:
> On Fri, Apr 26, 2013 at 11:57 PM, Christoffer Dall
> <cdall at cs.columbia.edu> wrote:
>>>
>>> Sure, I incorporate all above comments and send revised patch.
>>>
>> Hi Anup,
>>
>> Now when we're at it, your commit message is exessively long, both the
>> title and the actual content. Please try to keep the commit message
>> under 80 chars at least and the title of the patch even shorter if
>> possible: think doing a 'git log' on an 80 char terminal...
>>
>> -Christoffer
>
> Oke, I'll keep the commit message shorter.
>
thanks, just to be clear, the body of the message can be as long as
appropriate, but the lines should be wrapped at 80 chars max.


From catalin.marinas at arm.com  Fri Apr 26 16:52:00 2013
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Fri, 26 Apr 2013 21:52:00 +0100
Subject: [PATCH V3] of: Set the DMA mask to 64 bits when dma_addr_t is
 64-bits
In-Reply-To: <1367008266-1431-1-git-send-email-lauraa@codeaurora.org>
References: <1367008266-1431-1-git-send-email-lauraa@codeaurora.org>
Message-ID: <20130426205159.GA48325@MacBook-Pro.local>

On Fri, Apr 26, 2013 at 09:31:06PM +0100, Laura Abbott wrote:
> Currently, of_platform_device_create_pdata always sets the
> coherent DMA mask to 32 bits. On ARM systems without CONFIG_ZONE_DMA,
> arm_dma_limit gets set to ~0 or 0xFFFFFFFFFFFFFFFF on LPAE based
> systems. Since arm_dma_limit represents the smallest dma_mask
> on the system, the default of 32 bits prevents any dma_coherent
> allocation from succeeding unless clients manually set the
> dma mask first. Rather than make every client on an LPAE system set
> the mask manually, account for the size of dma_addr_t when setting
> the coherent mask.
> 
> Signed-off-by: Laura Abbott <lauraa at codeaurora.org>

Looks good.

Acked-by: Catalin Marinas <catalin.marinas at arm.com>


From cdall at cs.columbia.edu  Fri Apr 26 17:07:02 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Fri, 26 Apr 2013 14:07:02 -0700
Subject: [PATCH v4 5/7] ARM: KVM: rework HYP page table freeing
In-Reply-To: <517AAF3F.20500@arm.com>
References: <1365790327-2138-1-git-send-email-marc.zyngier@arm.com>
 <1365790327-2138-6-git-send-email-marc.zyngier@arm.com>
 <20130426110558.GE5007@localhost.cambridge.arm.com>
 <517AAF3F.20500@arm.com>
Message-ID: <CAEDV+gKZezvHtRAySvGpOgTsPPtwUEYo9v086U=Hz4QPZXGVSg@mail.gmail.com>

On Fri, Apr 26, 2013 at 9:45 AM, Marc Zyngier <marc.zyngier at arm.com> wrote:
> On 26/04/13 12:05, Catalin Marinas wrote:
>> On Fri, Apr 12, 2013 at 07:12:05PM +0100, Marc Zyngier wrote:
>>> diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
>>> index bfc5927..7464824 100644
>>> --- a/arch/arm/kvm/mmu.c
>>> +++ b/arch/arm/kvm/mmu.c
>> ...
>>> +static void clear_pmd_entry(pmd_t *pmd)
>>> +{
>>> +    pte_t *pte_table = pte_offset_kernel(pmd, 0);
>>> +    pmd_clear(pmd);
>>> +    pte_free_kernel(NULL, pte_table);
>>> +    put_page(virt_to_page(pmd));
>>> +}
>> ...
>>>  static void unmap_stage2_range(struct kvm *kvm, phys_addr_t start, u64 size)
>>
>> Is there a chance that this function (or the other unmapping function
>> for Hyp pages) is called on an active stage 2 table (VTTBR pointing to
>> this pgd)? If yes, than you probably have to follow the mmu_gather
>> mechanism of freeing page table pages to avoid speculative loads.
>> Basically flushing the TLB between pmd_clear and pte_free_kernel.
>
> Blah. You're right, we got it wrong.
>
> We need to move our TLB invalidation out of kvm_unmap_hva_handler, and
> put it in clear_pmd_entry. I'll cook a patch.
>
> Thanks for reviewing.
>
Ah, because clean_pmd_entry doesn't  flush stage2 TLB, that's the issue?


From jon-hunter at ti.com  Fri Apr 26 17:25:21 2013
From: jon-hunter at ti.com (Jon Hunter)
Date: Fri, 26 Apr 2013 16:25:21 -0500
Subject: [PATCH 3/5] gpio/omap: Add DT support to GPIO driver
In-Reply-To: <CACRpkdaOOrooK7kff2Y-7gH6L6m-MsiU7PfHnqBkPpc=tk_iWA@mail.gmail.com>
References: <1329321854-24490-1-git-send-email-b-cousson@ti.com>
 <515319D5.20105@wwwdotorg.org>
 <CACRpkdYXVLgCz1Tyu-Ls2V2OTc4R3cGNJhfQJB6Hiz_K9dkZYQ@mail.gmail.com>
 <5155C902.7080207@wwwdotorg.org>
 <CACRpkdYbs4-uudpRUY8e+7icYYkZrfM0kReP3pLL5DMiURJ4dg@mail.gmail.com>
 <5165CB9D.1090202@wwwdotorg.org>
 <CACRpkdYirFNqmGhA4K9CL4ve4NYhs8Rd3SFt1iwW9vHBkrcz8g@mail.gmail.com>
 <51671D7B.5060303@wwwdotorg.org>
 <CACRpkdbf32Ef77GmXk9id9+RRjcDRTr7S+F4nznoeZU8y=BT_Q@mail.gmail.com>
 <51673D70.3010503@wwwdotorg.org>
 <CAAwP0s0e2x33jZQhFRY+Hoo61SFqYKRgWk=1mL2+DNxSDJHz+A@mail.gmail.com>
 <CACRpkda4h+qXTvsirPAS7E7sjXhMLE62q=VDy53W8UchsYjbNg@mail.gmail.com>
 <516C31C3.9040505@wwwdotorg.org> <516C7C43.3040105@wwwdotorg.org>
 <516C8760.2050500@ti.com> <516D9B05.1000501@wwwdotorg.org>
 <516DA60A.5070000@ti.com> <516DCCA8.3070108@wwwdotorg.org>
 <516DDB4D.9020500@ti.com> <516EC2AF.9090905@wwwdotorg.org>
 <CACRpkdaOOrooK7kff2Y-7gH6L6m-MsiU7PfHnqBkPpc=tk_iWA@mail.gmail.com>
Message-ID: <517AF0C1.60009@ti.com>


On 04/26/2013 02:27 AM, Linus Walleij wrote:
> On Wed, Apr 17, 2013 at 5:41 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
>> On 04/16/2013 05:14 PM, Jon Hunter wrote:
> 
>>>> c) I have the feeling that hooking the of_xlate function for this is a
>>>> bit of an abuse of the function.
>>>
>>> I was wondering about that. So I was grep'ing through the various xlate
>>> implementations and found this [1]. Also you may recall that in the
>>> of_dma_simple_xlate() we call the dma_request_channel() to allocate the
>>> channel, which is very similar. However, I don't wish to get a
>>> reputation as abusing APIs so would be good to know if this really is
>>> abuse or not ;-)
>>>
>>> Cheers
>>> Jon
>>>
>>> [1] http://permalink.gmane.org/gmane.linux.ports.arm.kernel/195124
>>
>> Interesting.
>>
>> This is really something that the core DT and GPIO and IRQ maintainers
>> should weigh in on. Hence, changing them from Cc: to To: in this message
>> and/or adding them.
> 
> So I guess it is OK for a driver or DT node to use a GPIO as IRQ
> *only*, and then have the GPIO requested implicitly through the
> xlate function in the irqdomain.
> 
> It's the use cases where one and the same driver tries to use the
> same GPIO line *also* by requesting it using gpio_request()
> that madness starts. In such cases the driver deserves to have
> an error thrown back at it, as it definately knows the GPIO pin
> and can be refactored to use gpio_to_irq() to translate it into
> an IRQ rather than having it implicitly done in the xlate function.
> 
> You will just have to give the xlate function information about which
> GPIOs are used as IRQs only, and only request the GPIO on these.

That should not be necessary. The xlate is only called in the case where
the gpio controller is declared as the interrupt controller in the
device tree source ...

eth at 0 {
	compatible = "ks8851";
	...
	interrupt-parent = <&gpio2>;
	interrupts = <2 8>; /* gpio line 34, low triggered */
	...
};

So in the case where you have a driver call gpio_request() and then
request_irq(), in the device tree source, the gpio controller will not
be declared as an interrupt controller. It will just list the gpios ...

sdhci at c8000200 {
	...
	cd-gpios = <&gpio 69 0>; /* gpio PI5 */
	wp-gpios = <&gpio 57 0>; /* gpio PH1 */
	...
};

> And I recently suggested a mechanism to do that, and that is
> what I called GPIO input-hogs, which means that you mark
> (e.g. from the device tree) at probe() of the gpiochip which GPIOs
> will only be used as inputs, so as to generate IRQs.
> 
> This is perfectly OS-neutral information about the how the
> hardware is set up in the system.
> 
> If you only allow these hogges inputs to be translated and
> requested in the xlate function, everything goes smooth.
> 
> It all comes back to this: keep all applicable knowledge in the
> system, so it can make proper decisions, don't try to create
> mechanisms that will half-guess things.

Agreed. However the xlate looks like a good place to request the gpio
without needing to add these "input-hogs" or any other platform code. So
if this is not considered abuse of the xlate, then it seems like an
ideal solution. I have been also implementing a generic xlate so that we
don't need to have a xlate for each platform as well.

Cheers
Jon


From jon-hunter at ti.com  Fri Apr 26 17:31:24 2013
From: jon-hunter at ti.com (Jon Hunter)
Date: Fri, 26 Apr 2013 16:31:24 -0500
Subject: [PATCH 3/5] gpio/omap: Add DT support to GPIO driver
In-Reply-To: <CACRpkdaA_7Feuui-S65m--2FfvpoUkfn6b9SoWavAstZUS23ag@mail.gmail.com>
References: <1329321854-24490-1-git-send-email-b-cousson@ti.com>
 <515319D5.20105@wwwdotorg.org>
 <CACRpkdYXVLgCz1Tyu-Ls2V2OTc4R3cGNJhfQJB6Hiz_K9dkZYQ@mail.gmail.com>
 <5155C902.7080207@wwwdotorg.org>
 <CACRpkdYbs4-uudpRUY8e+7icYYkZrfM0kReP3pLL5DMiURJ4dg@mail.gmail.com>
 <5165CB9D.1090202@wwwdotorg.org>
 <CACRpkdYirFNqmGhA4K9CL4ve4NYhs8Rd3SFt1iwW9vHBkrcz8g@mail.gmail.com>
 <51671D7B.5060303@wwwdotorg.org>
 <CACRpkdbf32Ef77GmXk9id9+RRjcDRTr7S+F4nznoeZU8y=BT_Q@mail.gmail.com>
 <51673D70.3010503@wwwdotorg.org>
 <CAAwP0s0e2x33jZQhFRY+Hoo61SFqYKRgWk=1mL2+DNxSDJHz+A@mail.gmail.com>
 <CACRpkda4h+qXTvsirPAS7E7sjXhMLE62q=VDy53W8UchsYjbNg@mail.gmail.com>
 <516C31C3.9040505@wwwdotorg.org> <516C7C43.3040105@wwwdotorg.org>
 <516C8760.2050500@ti.com> <516D9B05.1000501@wwwdotorg.org>
 <516DA60A.5070000@ti.com> <516DCCA8.3070108@wwwdotorg.org>
 <516DDB4D.9020500@ti.com>
 <CAAwP0s0-VNUoeSKaGbvoDeD7m7kZRdp5rCJ7iVpFoFAaQtXcmQ@mail.gmail.com>
 <CACRpkdaA_7Feuui-S65m--2FfvpoUkfn6b9SoWavAstZUS23ag@mail.gmail.com>
Message-ID: <517AF22C.9090901@ti.com>


On 04/26/2013 02:31 AM, Linus Walleij wrote:
> On Wed, Apr 17, 2013 at 2:41 AM, Javier Martinez Canillas
> <martinez.javier at gmail.com> wrote:
> 
> So:
> 
>> +static int omap_gpio_irq_domain_xlate(struct irq_domain *d,
>> +                                     struct device_node *ctrlr,
>> +                                     const u32 *intspec, unsigned int intsize,
>> +                                     irq_hw_number_t *out_hwirq,
>> +                                     unsigned int *out_type)
>> +{
>> +       int ret;
>> +       struct gpio_bank *bank = d->host_data;
>> +       int gpio = bank->chip.base + intspec[0];
>> +
>> +       if (WARN_ON(intsize < 2))
>> +               return -EINVAL;
>> +
>> +       ret = gpio_request_one(gpio, GPIOF_IN, ctrlr->full_name);
>> +       if (ret)
>> +               return ret;
> 
> So how to figure out if a device is already requesting this GPIO
> on some orthogonal axis?

I really don't think that is necessary. Hopefully, my other email [1]
elaborates on why. Let me know if this makes sense.

Cheers
Jon

[1] http://marc.info/?l=linux-arm-kernel&m=136701158117966&w=1


From robherring2 at gmail.com  Fri Apr 26 17:32:32 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Fri, 26 Apr 2013 16:32:32 -0500
Subject: [PATCH V3] of: Set the DMA mask to 64 bits when dma_addr_t is
 64-bits
In-Reply-To: <1367008266-1431-1-git-send-email-lauraa@codeaurora.org>
References: <1367008266-1431-1-git-send-email-lauraa@codeaurora.org>
Message-ID: <517AF270.8040106@gmail.com>

On 04/26/2013 03:31 PM, Laura Abbott wrote:
> Currently, of_platform_device_create_pdata always sets the
> coherent DMA mask to 32 bits. On ARM systems without CONFIG_ZONE_DMA,
> arm_dma_limit gets set to ~0 or 0xFFFFFFFFFFFFFFFF on LPAE based
> systems. Since arm_dma_limit represents the smallest dma_mask
> on the system, the default of 32 bits prevents any dma_coherent
> allocation from succeeding unless clients manually set the
> dma mask first. Rather than make every client on an LPAE system set
> the mask manually, account for the size of dma_addr_t when setting
> the coherent mask.
> 
> Signed-off-by: Laura Abbott <lauraa at codeaurora.org>
> ---
>  drivers/of/platform.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/of/platform.c b/drivers/of/platform.c
> index 0970505..5f0ba94 100644
> --- a/drivers/of/platform.c
> +++ b/drivers/of/platform.c
> @@ -214,7 +214,7 @@ struct platform_device *of_platform_device_create_pdata(
>  #if defined(CONFIG_MICROBLAZE)
>  	dev->archdata.dma_mask = 0xffffffffUL;
>  #endif
> -	dev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
> +	dev->dev.coherent_dma_mask = DMA_BIT_MASK(sizeof(dma_addr_t) * 8);

This is going to change the mask from 32 to 64 bits on 64-bit powerpc
and others possibly. Maybe it doesn't matter. I think it doesn't, but
I'm not sure enough to apply for 3.10. So I'll queue it for 3.11.

Rob


>  	dev->dev.bus = &platform_bus_type;
>  	dev->dev.platform_data = platform_data;
>  
> 



From pavel at denx.de  Fri Apr 26 17:37:23 2013
From: pavel at denx.de (Pavel Machek)
Date: Fri, 26 Apr 2013 23:37:23 +0200
Subject: dw_apb_timer_of.c: remove parts that were picoxcell-specific
In-Reply-To: <20130426124128.GB6946@page>
References: <20130426121433.GA16249@amd.pavel.ucw.cz>
 <20130426124128.GB6946@page>
Message-ID: <20130426213723.GA24891@amd.pavel.ucw.cz>

Hi!

> On Fri, Apr 26, 2013 at 02:14:34PM +0200, Pavel Machek wrote:
> > diff --git a/arch/arm/mach-picoxcell/common.c b/arch/arm/mach-picoxcell/common.c
> > index 70b441a..22759f5 100644
> > --- a/arch/arm/mach-picoxcell/common.c
> > +++ b/arch/arm/mach-picoxcell/common.c
> > @@ -84,11 +84,39 @@ static void picoxcell_wdt_restart(char mode, const char *cmd)
> >  	}
> >  }
> >  
> > +static const struct of_device_id picochip_rtc_ids[] __initconst = {
> > +        { .compatible = "picochip,pc3x2-rtc" },
> > +        { /* Sentinel */ },
> > +};
> > +
> > +static void __iomem *sched_io_base;
> > +
> > +static u32 read_sched_clock(void)
> > +{
> > +        return __raw_readl(sched_io_base);
> > +}
> > +
> > +static void __init timer_init(void)
> > +{
> > +	u32 rate;
> > +
> > +	dw_apb_timer_init(0);
> > +
> > +	sched_timer = of_find_matching_node(timer, osctimer_ids);
> > +	if (!sched_timer)
> > +		panic("No suitable timer for scheduler clock\n");
> > +
> > +	timer_get_base_and_rate(sched_timer, &sched_io_base, &rate);
> > +	of_node_put(sched_timer);
> 
> This doesn't work as osctimer_ids is private to the dw_apb_timer files 
> as is timer_get_base_and_rate.  The other timer is unused in picoxcell 
> though so dw_apb_timer_init(1), something like the patch below on top of 
> yours.

That would still not compile due to common.h. ... _but_ it allows
some very nice simplification, with this on top:

I'll post merged-up patch in next mail.

Thanks,
									Pavel

diff --git a/arch/arm/mach-picoxcell/common.c b/arch/arm/mach-picoxcell/common.c
index c027920..70b441a 100644
--- a/arch/arm/mach-picoxcell/common.c
+++ b/arch/arm/mach-picoxcell/common.c
@@ -84,16 +84,11 @@ static void picoxcell_wdt_restart(char mode, const char *cmd)
 	}
 }
 
-static void __init timer_init(void)
-{
-	dw_apb_timer_init(1);
-}
-
 DT_MACHINE_START(PICOXCELL, "Picochip picoXcell")
 	.map_io		= picoxcell_map_io,
 	.nr_irqs	= NR_IRQS_LEGACY,
 	.init_irq	= irqchip_init,
-	.init_time	= timer_init,
+	.init_time	= dw_apb_timer_init,
 	.init_machine	= picoxcell_init_machine,
 	.dt_compat	= picoxcell_dt_match,
 	.restart	= picoxcell_wdt_restart,
diff --git a/arch/arm/mach-picoxcell/common.h b/arch/arm/mach-picoxcell/common.h
index 481b42a..237fb3b 100644
--- a/arch/arm/mach-picoxcell/common.h
+++ b/arch/arm/mach-picoxcell/common.h
@@ -12,6 +12,4 @@
 
 #include <asm/mach/time.h>
 
-extern void dw_apb_timer_init(void);
-
 #endif /* __PICOXCELL_COMMON_H__ */
diff --git a/arch/arm/mach-socfpga/socfpga.c b/arch/arm/mach-socfpga/socfpga.c
index 6efbc12..81b8f1e 100644
--- a/arch/arm/mach-socfpga/socfpga.c
+++ b/arch/arm/mach-socfpga/socfpga.c
@@ -110,17 +110,11 @@ static const char *altera_dt_match[] = {
 	NULL
 };
 
-static void __init timer_init(void)
-{
-	dw_apb_timer_init(1);
-}
-
-
 DT_MACHINE_START(SOCFPGA, "Altera SOCFPGA")
 	.smp		= smp_ops(socfpga_smp_ops),
 	.map_io		= socfpga_map_io,
 	.init_irq	= socfpga_init_irq,
-	.init_time	= timer_init,
+	.init_time	= dw_apb_timer_init,
 	.init_machine	= socfpga_cyclone5_init,
 	.restart	= socfpga_cyclone5_restart,
 	.dt_compat	= altera_dt_match,
diff --git a/drivers/clocksource/dw_apb_timer_of.c b/drivers/clocksource/dw_apb_timer_of.c
index 872ce66..0fa3104 100644
--- a/drivers/clocksource/dw_apb_timer_of.c
+++ b/drivers/clocksource/dw_apb_timer_of.c
@@ -66,7 +66,7 @@ static u32 read_sched_clock_sptimer(void)
 	return ~__raw_readl(sched_io_base + APBTMR_N_CURRENT_VALUE);
 }
 
-static void add_clocksource(struct device_node *source_timer, int use_as_scheduler)
+static void add_clocksource(struct device_node *source_timer)
 {
 	void __iomem *iobase;
 	struct dw_apb_clocksource *cs;
@@ -81,10 +81,8 @@ static void add_clocksource(struct device_node *source_timer, int use_as_schedul
 	dw_apb_clocksource_start(cs);
 	dw_apb_clocksource_register(cs);
 
-	if (use_as_scheduler) {
-		sched_io_base = iobase;
-		setup_sched_clock(read_sched_clock_sptimer, 32, rate);
-	}
+	sched_io_base = iobase;
+	setup_sched_clock(read_sched_clock_sptimer, 32, rate);
 }
 
 static const struct of_device_id osctimer_ids[] __initconst = {
@@ -104,7 +102,7 @@ static const struct of_device_id osctimer_ids[] __initconst = {
 */
 
 
-void __init dw_apb_timer_init(int use_as_scheduler)
+void __init dw_apb_timer_init(void)
 {
 	struct device_node *event_timer, *source_timer;
 
@@ -116,7 +114,7 @@ void __init dw_apb_timer_init(int use_as_scheduler)
 	source_timer = of_find_matching_node(event_timer, osctimer_ids);
 	if (!source_timer)
 		panic("No timer for clocksource");
-	add_clocksource(source_timer, use_as_scheduler);
+	add_clocksource(source_timer);
 
 	of_node_put(event_timer);
 	of_node_put(source_timer);
diff --git a/include/linux/dw_apb_timer.h b/include/linux/dw_apb_timer.h
index d503245..a64c987 100644
--- a/include/linux/dw_apb_timer.h
+++ b/include/linux/dw_apb_timer.h
@@ -59,5 +59,5 @@ void dw_apb_clocksource_start(struct dw_apb_clocksource *dw_cs);
 cycle_t dw_apb_clocksource_read(struct dw_apb_clocksource *dw_cs);
 void dw_apb_clocksource_unregister(struct dw_apb_clocksource *dw_cs);
 
-extern void dw_apb_timer_init(int);
+extern void dw_apb_timer_init(void);
 #endif /* __DW_APB_TIMER_H__ */


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


From pavel at denx.de  Fri Apr 26 17:43:14 2013
From: pavel at denx.de (Pavel Machek)
Date: Fri, 26 Apr 2013 23:43:14 +0200
Subject: dw_apb_timer_of.c: remove parts that were picoxcell-specific
In-Reply-To: <20130426213723.GA24891@amd.pavel.ucw.cz>
References: <20130426121433.GA16249@amd.pavel.ucw.cz>
 <20130426124128.GB6946@page>
 <20130426213723.GA24891@amd.pavel.ucw.cz>
Message-ID: <20130426214313.GB24891@amd.pavel.ucw.cz>

It seems we made a mistake when creating dw_apb_timer_of.c:
picoxcell sched_clock had parts that were not related to
dw_apb_timer, yet we moved them to dw_apb_timer_of, and tried to
use them on socfpga.

This results in system where user/system time is not measured
properly, as demonstrated by
    
    time dd if=/dev/urandom of=/dev/zero bs=100000 count=100
    
So this patch switches sched_clock to hardware that exists on both
platforms, and adds missing of_node_put() in dw_apb_timer_init().
    
Signed-off-by: Pavel Machek <pavel at denx.de>

diff --git a/arch/arm/mach-picoxcell/common.h b/arch/arm/mach-picoxcell/common.h
index 481b42a..237fb3b 100644
--- a/arch/arm/mach-picoxcell/common.h
+++ b/arch/arm/mach-picoxcell/common.h
@@ -12,6 +12,4 @@
 
 #include <asm/mach/time.h>
 
-extern void dw_apb_timer_init(void);
-
 #endif /* __PICOXCELL_COMMON_H__ */
diff --git a/drivers/clocksource/dw_apb_timer.c b/drivers/clocksource/dw_apb_timer.c
index 8c2a35f..460ac99 100644
--- a/drivers/clocksource/dw_apb_timer.c
+++ b/drivers/clocksource/dw_apb_timer.c
@@ -21,12 +21,6 @@
 #define APBT_MIN_PERIOD			4
 #define APBT_MIN_DELTA_USEC		200
 
-#define APBTMR_N_LOAD_COUNT		0x00
-#define APBTMR_N_CURRENT_VALUE		0x04
-#define APBTMR_N_CONTROL		0x08
-#define APBTMR_N_EOI			0x0c
-#define APBTMR_N_INT_STATUS		0x10
-
 #define APBTMRS_INT_STATUS		0xa0
 #define APBTMRS_EOI			0xa4
 #define APBTMRS_RAW_INT_STATUS		0xa8
diff --git a/drivers/clocksource/dw_apb_timer_of.c b/drivers/clocksource/dw_apb_timer_of.c
index ab09ed3..0fa3104 100644
--- a/drivers/clocksource/dw_apb_timer_of.c
+++ b/drivers/clocksource/dw_apb_timer_of.c
@@ -57,6 +57,15 @@ static void add_clockevent(struct device_node *event_timer)
 	dw_apb_clockevent_register(ced);
 }
 
+static void __iomem *sched_io_base;
+
+/* This is actually same as __apbt_read_clocksource(), but with
+   different interface */
+static u32 read_sched_clock_sptimer(void)
+{
+	return ~__raw_readl(sched_io_base + APBTMR_N_CURRENT_VALUE);
+}
+
 static void add_clocksource(struct device_node *source_timer)
 {
 	void __iomem *iobase;
@@ -71,41 +80,27 @@ static void add_clocksource(struct device_node *source_timer)
 
 	dw_apb_clocksource_start(cs);
 	dw_apb_clocksource_register(cs);
-}
 
-static void __iomem *sched_io_base;
-
-static u32 read_sched_clock(void)
-{
-	return __raw_readl(sched_io_base);
+	sched_io_base = iobase;
+	setup_sched_clock(read_sched_clock_sptimer, 32, rate);
 }
 
-static const struct of_device_id sptimer_ids[] __initconst = {
-	{ .compatible = "picochip,pc3x2-rtc" },
+static const struct of_device_id osctimer_ids[] __initconst = {
+	{ .compatible = "picochip,pc3x2-timer" },
+	{ .compatible = "snps,dw-apb-timer-osc" },
 	{ .compatible = "snps,dw-apb-timer-sp" },
-	{ /* Sentinel */ },
+	{  /* Sentinel */ },
 };
 
-static void init_sched_clock(void)
-{
-	struct device_node *sched_timer;
-	u32 rate;
-
-	sched_timer = of_find_matching_node(NULL, sptimer_ids);
-	if (!sched_timer)
-		panic("No RTC for sched clock to use");
+/*
+   You don't have to use dw_apb_timer for scheduler clock,
+   this should also work fine on arm:
 
-	timer_get_base_and_rate(sched_timer, &sched_io_base, &rate);
-	of_node_put(sched_timer);
+  twd_local_timer_of_register();
+  arch_timer_of_register();                 
+  arch_timer_sched_clock_init();
+*/
 
-	setup_sched_clock(read_sched_clock, 32, rate);
-}
-
-static const struct of_device_id osctimer_ids[] __initconst = {
-	{ .compatible = "picochip,pc3x2-timer" },
-	{ .compatible = "snps,dw-apb-timer-osc" },
-	{},
-};
 
 void __init dw_apb_timer_init(void)
 {
@@ -121,7 +116,6 @@ void __init dw_apb_timer_init(void)
 		panic("No timer for clocksource");
 	add_clocksource(source_timer);
 
+	of_node_put(event_timer);
 	of_node_put(source_timer);
-
-	init_sched_clock();
 }
diff --git a/include/linux/dw_apb_timer.h b/include/linux/dw_apb_timer.h
index dd755ce..a64c987 100644
--- a/include/linux/dw_apb_timer.h
+++ b/include/linux/dw_apb_timer.h
@@ -17,6 +17,12 @@
 #include <linux/clocksource.h>
 #include <linux/interrupt.h>
 
+#define APBTMR_N_LOAD_COUNT		0x00
+#define APBTMR_N_CURRENT_VALUE		0x04
+#define APBTMR_N_CONTROL		0x08
+#define APBTMR_N_EOI			0x0c
+#define APBTMR_N_INT_STATUS		0x10
+
 #define APBTMRS_REG_SIZE       0x14
 
 struct dw_apb_timer {


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


From dborkman at redhat.com  Fri Apr 26 18:01:10 2013
From: dborkman at redhat.com (Daniel Borkmann)
Date: Sat, 27 Apr 2013 00:01:10 +0200
Subject: [PATCH V3 2/3] ARM: net: bpf_jit: make code generation less
 dependent on struct sk_filter.
In-Reply-To: <20130426130948.cbfd2f6256afc0e3ee7abeed@linux-foundation.org>
References: <1366824429-26652-1-git-send-email-nschichan@freebox.fr>
 <1366824429-26652-3-git-send-email-nschichan@freebox.fr>
 <3592414.M8kQZLCXlW@wuerfel>
 <20130426122601.10ec05fcb4860df1b0a5b409@linux-foundation.org>
 <517AD9E2.2090704@redhat.com>
 <20130426130948.cbfd2f6256afc0e3ee7abeed@linux-foundation.org>
Message-ID: <517AF926.3020302@redhat.com>

On 04/26/2013 10:09 PM, Andrew Morton wrote:
> On Fri, 26 Apr 2013 21:47:46 +0200 Daniel Borkmann <dborkman at redhat.com> wrote:
>> On 04/26/2013 09:26 PM, Andrew Morton wrote:
>>> On Fri, 26 Apr 2013 16:04:44 +0200 Arnd Bergmann <arnd at arndb.de> wrote:
>>>> On Wednesday 24 April 2013 19:27:08 Nicolas Schichan wrote:
>>>>> @@ -858,7 +858,7 @@ b_epilogue:
>>>>>    }
>>>>>
>>>>>
>>>>> -void bpf_jit_compile(struct sk_filter *fp)
>>>>> +static void __bpf_jit_compile(struct jit_ctx *out_ctx)
>>>>>    {
>>>>>           struct jit_ctx ctx;
>>>>>           unsigned tmp_idx;
>>>>> @@ -867,11 +867,10 @@ void bpf_jit_compile(struct sk_filter *fp)
>>>>>           if (!bpf_jit_enable)
>>>>>                   return;
>>>>>
>>>>> -       memset(&ctx, 0, sizeof(ctx));
>>>>> -       ctx.skf         = fp;
>>>>> +       ctx = *out_ctx;
>>>>>           ctx.ret0_fp_idx = -1;
>>>>>
>>>>> -       ctx.offsets = kzalloc(4 * (ctx.skf->len + 1), GFP_KERNEL);
>>>>> +       ctx.offsets = kzalloc(4 * (ctx.prog_len + 1), GFP_KERNEL);
>>>>>           if (ctx.offsets == NULL)
>>>>>                   return;
>>>>>
>>>>> @@ -921,13 +920,26 @@ void bpf_jit_compile(struct sk_filter *fp)
>>>>>                   print_hex_dump(KERN_INFO, "BPF JIT code: ",
>>>>>                                  DUMP_PREFIX_ADDRESS, 16, 4, ctx.target,
>>>>>                                  alloc_size, false);
>>>>> -
>>>>> -       fp->bpf_func = (void *)ctx.target;
>>>>>    out:
>>>>>           kfree(ctx.offsets);
>>>>> +
>>>>> +       *out_ctx = ctx;
>>>>>           return;
>>>>
>>>> This part of the patch, in combination with 79617801e "filter: bpf_jit_comp:
>>>> refactor and unify BPF JIT image dump output" is now causing build errors
>>>> in linux-next:
>>>>
>>>> arch/arm/net/bpf_jit_32.c: In function '__bpf_jit_compile':
>>>> arch/arm/net/bpf_jit_32.c:930:16: error: 'fp' undeclared (first use in this function)
>>>>      bpf_jit_dump(fp->len, alloc_size, 2, ctx.target);
>>>
>>> Thanks, I did this.  There may be a smarter way...
>>
>> I think also seccomp_jit_compile() would need this change then, otherwise the build
>> with CONFIG_SECCOMP_FILTER_JIT might break.
>
> urgh, that tears it.
>
>> I can fix this up for you if not already applied. I presume it's against
>> linux-next tree?
>
> Yup, please send something.

Patch is attached. However, I currently don't have an ARM toolchain at hand, so
uncompiled, untested.

@Nicolas, Xi (cc, ref: http://thread.gmane.org/gmane.linux.kernel/1481464):

If there is someday support for other archs as well, it would be nice if we
do not have each time duplicated seccomp_jit_compile() etc functions in each
JIT implementation, i.e. because they do basically the same. So follow-up
{fix,clean}up is appreciated.

Also, I find it a bit weird that seccomp_filter_get_len() and some other
_one-line_ functions from kernel/seccomp.c are not placed into the
corresponding header file as inlines.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-ARM-bpf_jit-seccomp-filtering-fixup-merge-conflict.patch
Type: text/x-patch
Size: 1668 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130427/0d0a4f93/attachment-0001.bin>

From syin at broadcom.com  Fri Apr 26 18:02:47 2013
From: syin at broadcom.com (Sherman Yin)
Date: Fri, 26 Apr 2013 22:02:47 +0000
Subject: [PATCH] ARM: Adds pin config API to set all configs in one
 function
In-Reply-To: <CACRpkdbT7f8ujCHZxKg26iMKcrAb+_yHW_2YsZwkoo892rkgTA@mail.gmail.com>
References: <1366841010-2823-1-git-send-email-syin@broadcom.com>
 <CACRpkdbT7f8ujCHZxKg26iMKcrAb+_yHW_2YsZwkoo892rkgTA@mail.gmail.com>
Message-ID: <051069C10411E24D9749790C498526FA1BCF5427@SJEXCHMB12.corp.ad.broadcom.com>

Hi Linus,

> We discussed this already at the creation of the pinctrl framework.
> 
> What you should do is to add an optional pin_config_set_complete()
> and pin_config_group_set_complete()
> callback that is called after the framework has iterated over all
> configs.

Perhaps I have misunderstood you previously, as I thought you are ok with letting
the driver take care of the loop.  The difference being instead of just moving the for 
loop inside the driver's pin_config_set(), I followed Stephen's suggestion due to
concern about drivers duplicating the loop:  
(quote again here since I didn't send to the mail list last time)

[quote]

>>>>> pin_config_set() is called for each element of the array, one at a time:
>>>>>
>>>>> 328int pinconf_apply_setting(struct pinctrl_setting const *setting)
>>>>> ...
>>>>> 345             for (i = 0; i < setting->data.configs.num_configs; i++) {
>>>>> 346                     ret = ops->pin_config_set(pctldev,
>>>>> 347                                     setting->data.configs.group_or_pin,
>>>>> 348                                     setting->data.configs.configs[i]);
>>>>>
>>>>> Wouldn't it be more flexible if the for loop is moved inside the custom
>>>>> pin_config_set() function, and the core code pass in the whole
>>>>> configs[] array and num_configs?  This allows the driver to possibly
>>>>> combine different configs and make less write() calls to the registers.
>>>>
>>>> What you are saying is making a lot of sense.
>>>>
>>>> And I even think I have that problem where the batch of writes
>>>> may cause spurious IRQs that can be suppressed by disabling
>>>> IRQs in the driver when processing a queue of configs.
>>>>
>>>> Stephen what do you think?
>>>>
>>>> Sherman, would you be interested in writing a patch for this?
>>>>
>>>> You would have to patch all current users of the interface in
>>>> the same patch.
>>>>
>>>> You could actually provide a static inline helper to iterate over
>>>> the array to make it hard to do mistakes.
>>>
>>> I can see that applying all the configs at once might be useful.
>>>
>>> However, I don't think it makes sense to force all the drivers to
>>> iterate over all the configs themselves; that would just be duplicating
>>> the for loop in many drivers without any purpose.
>>>
>>> Instead, perhaps add a new "set_configs" operation in the driver
>>> structure. The core can call set_configs once if exists, and if not, the
>>> core can loop over each individual config and call the existing
>>> set_config function. This is just like the set_function operation, which
>>> can either be called once on a group, or once per pin, by the core.
>>
>> I don't mind writing the patch, once we agree on the method.  I can't test 
>> the other platforms though.
>>
>> Stephen, I'm not quite sure about duplicating the for loop - I was thinking 
>> just to remove the for loop in pinconf_apply_setting() and add the loop in 
>> the driver-defined function, so in the end there is still only 1 for loop.   
>> Functionally it shouldn't affect existing drivers, but it gives new drivers 
>> an opportunity to optimize based on their register design.
>
>I understand, but this forces all drivers to implement the loop
>themselves, and hence causes duplication. By making the new feature
>optional, you avoid that except where it's useful.
>
>But I suppose the loop itself is pretty small either way.

[/quote]

> This way the responsibility to resolve the sequence of config
> calls and validate the validity of that sequence is pushed down
> to the driver, it may do this incrementally or at pin_config_set_complete()
> and then write the resulting config to the hardware as an
> effect of pin_config_set_complete().

Please correctly if I'm wrong, but I think with the functions in my patch, the 
driver still have full control of / responsibility to resolve config sequence 
and perform validation.  The difference is instead of feeding the driver one 
config at time and telling it to write when the complete() function is called, 
my patch just gives the driver all configs in one call and expects the driver 
to parse, validate and write accordingly. 

> The driver takes care of caching intermediate settings for the pin
> until the complete() callback is called.
> Can you devise a patch like this instead?

I do have some concerns about the driver caching all the configs until complete()
is called...  I'm ok either way as long as it provides a way to consolidate pin config register 
writes.  Just want to clarify things with you before I go ahead and modify
my patch and driver.

> I am also very hesitant to merge this if there is no code using
> it, i.e. if you don't have a corresponding driver to submit
> at the same time, it will not be merged, as I don't like to
> maintain dead code.

I do plan to upstream a pinctrl driver that makes use of the new function, so I can make
this patch (or one that implements the pin_config_set_complete()) part of that commit.

Regards,
Sherman



From xi.wang at gmail.com  Fri Apr 26 18:18:58 2013
From: xi.wang at gmail.com (Xi Wang)
Date: Fri, 26 Apr 2013 18:18:58 -0400
Subject: [PATCH V3 2/3] ARM: net: bpf_jit: make code generation less
 dependent on struct sk_filter.
In-Reply-To: <517AF926.3020302@redhat.com>
References: <1366824429-26652-1-git-send-email-nschichan@freebox.fr>
 <1366824429-26652-3-git-send-email-nschichan@freebox.fr>
 <3592414.M8kQZLCXlW@wuerfel>
 <20130426122601.10ec05fcb4860df1b0a5b409@linux-foundation.org>
 <517AD9E2.2090704@redhat.com>
 <20130426130948.cbfd2f6256afc0e3ee7abeed@linux-foundation.org>
 <517AF926.3020302@redhat.com>
Message-ID: <CAKU6vyYOZ-24TSyLa8t6Oipib37fE1gtvM8nWj2TDzVw-tv0jA@mail.gmail.com>

Thanks for CCing.  One way to clean up this would be to refactor the
bpf jit interface as:

  bpf_func_t bpf_jit_compile(struct sock_filter *filter, unsigned int flen);
  void bpf_jit_free(bpf_func_t bpf_func);

Then both packet and seccomp filters can share the unified interface.
Also, we don't need seccomp_filter_get_len() and other helpers.

Do you want me to rebase my patch against linux-next and see how that goes?

- xi

On Fri, Apr 26, 2013 at 6:01 PM, Daniel Borkmann <dborkman at redhat.com> wrote:
> On 04/26/2013 10:09 PM, Andrew Morton wrote:
>>
>> On Fri, 26 Apr 2013 21:47:46 +0200 Daniel Borkmann <dborkman at redhat.com>
>> wrote:
>>>
>>> On 04/26/2013 09:26 PM, Andrew Morton wrote:
>>>>
>>>> On Fri, 26 Apr 2013 16:04:44 +0200 Arnd Bergmann <arnd at arndb.de> wrote:
>>>>>
>>>>> On Wednesday 24 April 2013 19:27:08 Nicolas Schichan wrote:
>>>>>>
>>>>>> @@ -858,7 +858,7 @@ b_epilogue:
>>>>>>    }
>>>>>>
>>>>>>
>>>>>> -void bpf_jit_compile(struct sk_filter *fp)
>>>>>> +static void __bpf_jit_compile(struct jit_ctx *out_ctx)
>>>>>>    {
>>>>>>           struct jit_ctx ctx;
>>>>>>           unsigned tmp_idx;
>>>>>> @@ -867,11 +867,10 @@ void bpf_jit_compile(struct sk_filter *fp)
>>>>>>           if (!bpf_jit_enable)
>>>>>>                   return;
>>>>>>
>>>>>> -       memset(&ctx, 0, sizeof(ctx));
>>>>>> -       ctx.skf         = fp;
>>>>>> +       ctx = *out_ctx;
>>>>>>           ctx.ret0_fp_idx = -1;
>>>>>>
>>>>>> -       ctx.offsets = kzalloc(4 * (ctx.skf->len + 1), GFP_KERNEL);
>>>>>> +       ctx.offsets = kzalloc(4 * (ctx.prog_len + 1), GFP_KERNEL);
>>>>>>           if (ctx.offsets == NULL)
>>>>>>                   return;
>>>>>>
>>>>>> @@ -921,13 +920,26 @@ void bpf_jit_compile(struct sk_filter *fp)
>>>>>>                   print_hex_dump(KERN_INFO, "BPF JIT code: ",
>>>>>>                                  DUMP_PREFIX_ADDRESS, 16, 4,
>>>>>> ctx.target,
>>>>>>                                  alloc_size, false);
>>>>>> -
>>>>>> -       fp->bpf_func = (void *)ctx.target;
>>>>>>    out:
>>>>>>           kfree(ctx.offsets);
>>>>>> +
>>>>>> +       *out_ctx = ctx;
>>>>>>           return;
>>>>>
>>>>>
>>>>> This part of the patch, in combination with 79617801e "filter:
>>>>> bpf_jit_comp:
>>>>> refactor and unify BPF JIT image dump output" is now causing build
>>>>> errors
>>>>> in linux-next:
>>>>>
>>>>> arch/arm/net/bpf_jit_32.c: In function '__bpf_jit_compile':
>>>>> arch/arm/net/bpf_jit_32.c:930:16: error: 'fp' undeclared (first use in
>>>>> this function)
>>>>>      bpf_jit_dump(fp->len, alloc_size, 2, ctx.target);
>>>>
>>>>
>>>> Thanks, I did this.  There may be a smarter way...
>>>
>>>
>>> I think also seccomp_jit_compile() would need this change then, otherwise
>>> the build
>>> with CONFIG_SECCOMP_FILTER_JIT might break.
>>
>>
>> urgh, that tears it.
>>
>>> I can fix this up for you if not already applied. I presume it's against
>>> linux-next tree?
>>
>>
>> Yup, please send something.
>
>
> Patch is attached. However, I currently don't have an ARM toolchain at hand,
> so
> uncompiled, untested.
>
> @Nicolas, Xi (cc, ref: http://thread.gmane.org/gmane.linux.kernel/1481464):
>
> If there is someday support for other archs as well, it would be nice if we
> do not have each time duplicated seccomp_jit_compile() etc functions in each
> JIT implementation, i.e. because they do basically the same. So follow-up
> {fix,clean}up is appreciated.
>
> Also, I find it a bit weird that seccomp_filter_get_len() and some other
> _one-line_ functions from kernel/seccomp.c are not placed into the
> corresponding header file as inlines.


From dborkman at redhat.com  Fri Apr 26 18:30:19 2013
From: dborkman at redhat.com (Daniel Borkmann)
Date: Sat, 27 Apr 2013 00:30:19 +0200
Subject: [PATCH V3 2/3] ARM: net: bpf_jit: make code generation less
 dependent on struct sk_filter.
In-Reply-To: <CAKU6vyYOZ-24TSyLa8t6Oipib37fE1gtvM8nWj2TDzVw-tv0jA@mail.gmail.com>
References: <1366824429-26652-1-git-send-email-nschichan@freebox.fr>
 <1366824429-26652-3-git-send-email-nschichan@freebox.fr>
 <3592414.M8kQZLCXlW@wuerfel>
 <20130426122601.10ec05fcb4860df1b0a5b409@linux-foundation.org>
 <517AD9E2.2090704@redhat.com>
 <20130426130948.cbfd2f6256afc0e3ee7abeed@linux-foundation.org>
 <517AF926.3020302@redhat.com>
 <CAKU6vyYOZ-24TSyLa8t6Oipib37fE1gtvM8nWj2TDzVw-tv0jA@mail.gmail.com>
Message-ID: <517AFFFB.9090201@redhat.com>

On 04/27/2013 12:18 AM, Xi Wang wrote:
> Thanks for CCing.  One way to clean up this would be to refactor the
> bpf jit interface as:
>
>    bpf_func_t bpf_jit_compile(struct sock_filter *filter, unsigned int flen);
>    void bpf_jit_free(bpf_func_t bpf_func);
>
> Then both packet and seccomp filters can share the unified interface.
> Also, we don't need seccomp_filter_get_len() and other helpers.
>
> Do you want me to rebase my patch against linux-next and see how that goes?

Sure, whatever works for you. Not sure if it will still make it though.

Also, as Eric already mentioned earlier, please do not top-post your mails!
I think one reminder should be sufficient for that. ;-)


From sergei.shtylyov at cogentembedded.com  Fri Apr 26 19:00:10 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Sat, 27 Apr 2013 03:00:10 +0400
Subject: [PATCH v3 4/5] ARM: shmobile: BOCK-W: add VIN and ML86V7667
 support
In-Reply-To: <201304232132.52741.sergei.shtylyov@cogentembedded.com>
References: <201304232118.43686.sergei.shtylyov@cogentembedded.com>
 <201304232132.52741.sergei.shtylyov@cogentembedded.com>
Message-ID: <517B06FA.3000303@cogentembedded.com>

Hello.

On 04/23/2013 09:32 PM, Sergei Shtylyov wrote:

> From: Vladimir Barinov <vladimir.barinov at cogentembedded.com>
>
> Add ML86V7667 platform devices on BOCK-W board, configure VIN0/1 pins, and
> register VIN0/1 devices with the ML86V7667 specific platform data.
>
> Signed-off-by: Vladimir Barinov <vladimir.barinov at cogentembedded.com>
> [Sergei: some macro/comment cleanup; updated the copyrights, removed duplicate
> #include, annotated all platform data as '__initdata'.]
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
>
> ---
> Changes since version 2:
> - removed duplicate #include <linux/pinctrl/machine.h>;
> - annotated all platform data as '__initdata' since they're kmemdup()'ed while
>    registering the platform devices anyway;
> - resolved rejects, refreshed the patch.
>
>   arch/arm/mach-shmobile/board-bockw.c |   39 +++++++++++++++++++++++++++++++++++
>   1 file changed, 39 insertions(+)
>
> Index: renesas/arch/arm/mach-shmobile/board-bockw.c
> ===================================================================
> --- renesas.orig/arch/arm/mach-shmobile/board-bockw.c
> +++ renesas/arch/arm/mach-shmobile/board-bockw.c

[...]

> @@ -80,6 +101,16 @@ static const struct pinctrl_map bockw_pi
>   				  "sdhi0_data4", "sdhi0"),
>   	PIN_MAP_MUX_GROUP_DEFAULT("sh_mobile_sdhi.0", "pfc-r8a7778",
>   				  "sdhi0_wp", "sdhi0"),
> +	/* VIN0 */
> +	PIN_MAP_MUX_GROUP_DEFAULT("rcar_vin.0", "pfc-r8a7778",
> +				  "vin0_clk", "vin0"),
> +	PIN_MAP_MUX_GROUP_DEFAULT("rcar_vin.0", "pfc-r8a7778",
> +				  "vin0_data8", "vin0"),
> +	/* VIN1 */
> +	PIN_MAP_MUX_GROUP_DEFAULT("rcar_vin.1", "pfc-r8a7778",
> +				  "vin1_clk", "vin1"),
> +	PIN_MAP_MUX_GROUP_DEFAULT("rcar_vin.1", "pfc-r8a7778",
> +				  "vin1_data8", "vin1"),
>   };

     It turned out that VIN1 signal VI1_CLK conflicts with Ether signal 
ETH_REF_CLK.
So I'm a bit at a loss here: whether I should totally remove VIN1 device 
if I'm going
to add Ether device, or add a BOCK-W specific submenu to Kconfig, or add 
driver
specific #ifdef's in the code to disable VIN1 if sh_eth driver is 
enabled?...

WBR, Sergei



From davem at davemloft.net  Fri Apr 26 19:33:07 2013
From: davem at davemloft.net (David Miller)
Date: Fri, 26 Apr 2013 19:33:07 -0400 (EDT)
Subject: [PATCH V3 2/3] ARM: net: bpf_jit: make code generation less
 dependent on struct sk_filter.
In-Reply-To: <CAKU6vyYOZ-24TSyLa8t6Oipib37fE1gtvM8nWj2TDzVw-tv0jA@mail.gmail.com>
References: <20130426130948.cbfd2f6256afc0e3ee7abeed@linux-foundation.org>
 <517AF926.3020302@redhat.com>
 <CAKU6vyYOZ-24TSyLa8t6Oipib37fE1gtvM8nWj2TDzVw-tv0jA@mail.gmail.com>
Message-ID: <20130426.193307.1725881115728895413.davem@davemloft.net>


Please stop top-posting.

Thank you.


From olof at lixom.net  Fri Apr 26 19:39:51 2013
From: olof at lixom.net (Olof Johansson)
Date: Fri, 26 Apr 2013 16:39:51 -0700
Subject: [PATCH] clk: add option to keep boot clocks on
Message-ID: <1367019591-31685-1-git-send-email-olof@lixom.net>

This is primarily useful when there's a driver that doesn't claim clocks
properly, but the bootloader does. It's not expected to be used in normal
cases, but for bringup and debug it's very useful to have the option to
not gate unclaimed clocks that are still on.

Signed-off-by: Olof Johansson <olof at lixom.net>
---

Mike, this is a pretty trivial patch that I would love to see in 3.10
even though it's getting late. I'm definitely not picky about the naming
of the boot option, so feel free to change it.


-Olof

 drivers/clk/clk.c | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 20ce67f..b22551e 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -499,10 +499,24 @@ out:
 	return;
 }
 
+
+static bool keep_boot_clocks;
+static int __init clk_keep_boot_clocks(char *__unused)
+{
+	keep_boot_clocks = true;
+	return 1;
+}
+__setup("clk_keep_boot_clocks", clk_keep_boot_clocks);
+
 static int clk_disable_unused(void)
 {
 	struct clk *clk;
 
+	if (keep_boot_clocks) {
+		pr_warn("clk: Not disabling unused clocks\n");
+		return 0;
+	}
+
 	clk_prepare_lock();
 
 	hlist_for_each_entry(clk, &clk_root_list, child_node)
-- 
1.8.1.192.gc4361b8



From olof at lixom.net  Fri Apr 26 19:41:21 2013
From: olof at lixom.net (Olof Johansson)
Date: Fri, 26 Apr 2013 16:41:21 -0700
Subject: [PATCH] ARM: exynos: dts: cros5250: add cyapa trackpad
Message-ID: <1367019681-31775-1-git-send-email-olof@lixom.net>

Trivial patch, adding the i2c Cypress trackpad used on Snow.

Signed-off-by: Olof Johansson <olof at lixom.net>
---

Kukjin, if you don't mind I'll just add this to arm-soc?


-Olof

 arch/arm/boot/dts/cros5250-common.dtsi | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/cros5250-common.dtsi b/arch/arm/boot/dts/cros5250-common.dtsi
index ebfa805..a3330a9 100644
--- a/arch/arm/boot/dts/cros5250-common.dtsi
+++ b/arch/arm/boot/dts/cros5250-common.dtsi
@@ -175,6 +175,14 @@
 	i2c at 12C70000 {
 		samsung,i2c-sda-delay = <100>;
 		samsung,i2c-max-bus-freq = <378000>;
+
+		trackpad {
+			reg = <0x67>;
+			compatible = "cypress,cyapa";
+			interrupts = <2 0>;
+			interrupt-parent = <&gpx1>;
+			wakeup-source;
+		};
 	};
 
 	i2c at 12C80000 {
-- 
1.8.1.192.gc4361b8



From olof at lixom.net  Fri Apr 26 19:42:25 2013
From: olof at lixom.net (Olof Johansson)
Date: Fri, 26 Apr 2013 16:42:25 -0700
Subject: [PATCH] ARM: exynos: dts: cros5250: add EC device
Message-ID: <1367019745-31826-1-git-send-email-olof@lixom.net>

Add basic EC information to device tree, currently only describing the
keyboard and keymap.

Signed-off-by: Olof Johansson <olof at lixom.net>
Cc: Doug Anderson <dianders at chromium.org>
---

Kukjin, I'll apply this too directly if you don't mind.


-Olof

 arch/arm/boot/dts/cros5250-common.dtsi | 99 +++++++++++++++++++++++++++++++++-
 1 file changed, 98 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/cros5250-common.dtsi b/arch/arm/boot/dts/cros5250-common.dtsi
index 8a5b3a6..ebfa805 100644
--- a/arch/arm/boot/dts/cros5250-common.dtsi
+++ b/arch/arm/boot/dts/cros5250-common.dtsi
@@ -193,7 +193,104 @@
 	};
 
 	i2c at 12CA0000 {
-		status = "disabled";
+		samsung,i2c-sda-delay = <100>;
+		samsung,i2c-max-bus-freq = <66000>;
+
+		ec: embedded-controller {
+			compatible = "google,cros-ec-i2c";
+			reg = <0x1e>;
+			interrupts = <6 0>;
+			interrupt-parent = <&gpx1>;
+			wakeup-source;
+
+			cros-ec-keyb {
+			        compatible = "google,cros-ec-keyb";
+			        keypad,num-rows = <8>;
+			        keypad,num-columns = <13>;
+			        google,needs-ghost-filter;
+				linux,keymap = <0x0001003a	/* CAPSLK */
+						0x0002003b	/* F1 */
+						0x00030030	/* B */
+						0x00040044	/* F10 */
+						0x00060031	/* N */
+						0x0008000d	/* = */
+						0x000a0064	/* R_ALT */
+
+						0x01010001	/* ESC */
+						0x0102003e	/* F4 */
+						0x01030022	/* G */
+						0x01040041	/* F7 */
+						0x01060023	/* H */
+						0x01080028	/* ' */
+						0x01090043	/* F9 */
+						0x010b000e	/* BKSPACE */
+
+						0x0200001d	/* L_CTRL */
+						0x0201000f	/* TAB */
+						0x0202003d	/* F3 */
+						0x02030014	/* T */
+						0x02040040	/* F6 */
+						0x0205001b	/* ] */
+						0x02060015	/* Y */
+						0x02070056	/* 102ND */
+						0x0208001a	/* [ */
+						0x02090042	/* F8 */
+
+						0x03010029	/* GRAVE */
+						0x0302003c	/* F2 */
+						0x03030006	/* 5 */
+						0x0304003f	/* F5 */
+						0x03060007	/* 6 */
+						0x0308000c	/* - */
+						0x030b002b	/* \ */
+
+						0x04000061	/* R_CTRL */
+						0x0401001e	/* A */
+						0x04020020	/* D */
+						0x04030021	/* F */
+						0x0404001f	/* S */
+						0x04050025	/* K */
+						0x04060024	/* J */
+						0x04080027	/* ; */
+						0x04090026	/* L */
+						0x040b001c	/* ENTER */
+
+						0x0501002c	/* Z */
+						0x0502002e	/* C */
+						0x0503002f	/* V */
+						0x0504002d	/* X */
+						0x05050033	/* , */
+						0x05060032	/* M */
+						0x0507002a	/* L_SHIFT */
+						0x05080035	/* / */
+						0x05090034	/* . */
+						0x050B0039	/* SPACE */
+
+						0x06010002	/* 1 */
+						0x06020004	/* 3 */
+						0x06030005	/* 4 */
+						0x06040003	/* 2 */
+						0x06050009	/* 8 */
+						0x06060008	/* 7 */
+						0x0608000b	/* 0 */
+						0x0609000a	/* 9 */
+						0x060a0038	/* L_ALT */
+						0x060b006c	/* DOWN */
+						0x060c006a	/* RIGHT */
+
+						0x07010010	/* Q */
+						0x07020012	/* E */
+						0x07030013	/* R */
+						0x07040011	/* W */
+						0x07050017	/* I */
+						0x07060016	/* U */
+						0x07070036	/* R_SHIFT */
+						0x07080019	/* P */
+						0x07090018	/* O */
+						0x070b0067	/* UP */
+						0x070c0069>;	/* LEFT */
+			};
+		};
 	};
 
 	i2c at 12CB0000 {
-- 
1.8.1.192.gc4361b8



From dianders at chromium.org  Fri Apr 26 19:56:51 2013
From: dianders at chromium.org (Doug Anderson)
Date: Fri, 26 Apr 2013 16:56:51 -0700
Subject: [PATCH] ARM: exynos: dts: cros5250: add EC device
In-Reply-To: <1367019745-31826-1-git-send-email-olof@lixom.net>
References: <1367019745-31826-1-git-send-email-olof@lixom.net>
Message-ID: <CAD=FV=WhoGO8=5pt=VOCT_2j2CMkn8on=N=jK_2RwMOXWat57w@mail.gmail.com>

Olof,

On Fri, Apr 26, 2013 at 4:42 PM, Olof Johansson <olof at lixom.net> wrote:
> Add basic EC information to device tree, currently only describing the
> keyboard and keymap.
>
> Signed-off-by: Olof Johansson <olof at lixom.net>
> Cc: Doug Anderson <dianders at chromium.org>
> ---
>
> Kukjin, I'll apply this too directly if you don't mind.
>
>
> -Olof
>
>  arch/arm/boot/dts/cros5250-common.dtsi | 99 +++++++++++++++++++++++++++++++++-
>  1 file changed, 98 insertions(+), 1 deletion(-)

I'm not a huge fan of this change as I'd rather see my arbitration
changes land first and see this based atop those.  The arbitration
driver has landed so all that's left are the device tree bits.

That would be:

https://patchwork.kernel.org/patch/2449961/
https://patchwork.kernel.org/patch/2449941/

...but other than that this looks good.

-Doug


From olof at lixom.net  Fri Apr 26 20:08:02 2013
From: olof at lixom.net (Olof Johansson)
Date: Fri, 26 Apr 2013 17:08:02 -0700
Subject: [PATCH] ARM: u300: fix ages old copy/paste bug
In-Reply-To: <1366982995-10870-1-git-send-email-linus.walleij@stericsson.com>
References: <1366982995-10870-1-git-send-email-linus.walleij@stericsson.com>
Message-ID: <20130427000802.GA1285@quad.lixom.net>

On Fri, Apr 26, 2013 at 03:29:55PM +0200, Linus Walleij wrote:
> From: Linus Walleij <linus.walleij at linaro.org>
> 
> The UART1 is on the fast AHB bridge, not on the slow bus.
> 
> Cc: stable at vger.kernel.org
> Acked-by: Arnd Bergmann <arnd at arndb.de>
> Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
> ---
> Hi ARM SoC folks, as discussed with Arnd, please apply
> this patch directly for fixes.

Thanks, applied to next/fixes-non-critical.


-Olof



From dianders at chromium.org  Fri Apr 26 20:08:32 2013
From: dianders at chromium.org (Doug Anderson)
Date: Fri, 26 Apr 2013 17:08:32 -0700
Subject: [PATCH] ARM: exynos: dts: cros5250: add cyapa trackpad
In-Reply-To: <1367019681-31775-1-git-send-email-olof@lixom.net>
References: <1367019681-31775-1-git-send-email-olof@lixom.net>
Message-ID: <CAD=FV=Xrud-0DE3VH=Dqf5ZkYLkegCk0j16bzjiEb-GsvhT2MA@mail.gmail.com>

Olof,

On Fri, Apr 26, 2013 at 4:41 PM, Olof Johansson <olof at lixom.net> wrote:
> Trivial patch, adding the i2c Cypress trackpad used on Snow.
>
> Signed-off-by: Olof Johansson <olof at lixom.net>
> ---
>
> Kukjin, if you don't mind I'll just add this to arm-soc?
>
>
> -Olof
>
>  arch/arm/boot/dts/cros5250-common.dtsi | 8 ++++++++
>  1 file changed, 8 insertions(+)

Looks good.

Reviewed-by: Doug Anderson <dianders at chromium.org>


From rdunlap at infradead.org  Fri Apr 26 20:08:31 2013
From: rdunlap at infradead.org (Randy Dunlap)
Date: Fri, 26 Apr 2013 17:08:31 -0700
Subject: [PATCH] clk: add option to keep boot clocks on
In-Reply-To: <1367019591-31685-1-git-send-email-olof@lixom.net>
References: <1367019591-31685-1-git-send-email-olof@lixom.net>
Message-ID: <517B16FF.6070008@infradead.org>

On 04/26/13 16:39, Olof Johansson wrote:
> This is primarily useful when there's a driver that doesn't claim clocks
> properly, but the bootloader does. It's not expected to be used in normal
> cases, but for bringup and debug it's very useful to have the option to
> not gate unclaimed clocks that are still on.
> 
> Signed-off-by: Olof Johansson <olof at lixom.net>

add to Documentation/kernel-parameters.txt or somewhere else?

> ---
> 
> Mike, this is a pretty trivial patch that I would love to see in 3.10
> even though it's getting late. I'm definitely not picky about the naming
> of the boot option, so feel free to change it.
> 
> 
> -Olof
> 
>  drivers/clk/clk.c | 14 ++++++++++++++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index 20ce67f..b22551e 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -499,10 +499,24 @@ out:
>  	return;
>  }
>  
> +
> +static bool keep_boot_clocks;
> +static int __init clk_keep_boot_clocks(char *__unused)
> +{
> +	keep_boot_clocks = true;
> +	return 1;
> +}
> +__setup("clk_keep_boot_clocks", clk_keep_boot_clocks);
> +
>  static int clk_disable_unused(void)
>  {
>  	struct clk *clk;
>  
> +	if (keep_boot_clocks) {
> +		pr_warn("clk: Not disabling unused clocks\n");
> +		return 0;
> +	}
> +
>  	clk_prepare_lock();
>  
>  	hlist_for_each_entry(clk, &clk_root_list, child_node)
> 


-- 
~Randy


From olof at lixom.net  Fri Apr 26 20:12:10 2013
From: olof at lixom.net (Olof Johansson)
Date: Fri, 26 Apr 2013 17:12:10 -0700
Subject: [PATCH 1/4] clocksource: nomadik-mtu: fix up clocksource/timer
In-Reply-To: <CACRpkdYWSM0BK77qWbQWh0xsN+Ps95Q70zG-GE98MYvThrky2A@mail.gmail.com>
References: <1366463287-9922-1-git-send-email-linus.walleij@linaro.org>
 <CACRpkdYWSM0BK77qWbQWh0xsN+Ps95Q70zG-GE98MYvThrky2A@mail.gmail.com>
Message-ID: <20130427001210.GA1714@quad.lixom.net>

On Sat, Apr 20, 2013 at 03:19:43PM +0200, Linus Walleij wrote:
> ARM SoC folks:
> 
> On Sat, Apr 20, 2013 at 3:08 PM, Linus Walleij <linus.walleij at linaro.org> wrote:
> 
> > The Nomadik clocksource driver has had a bad define making it
> > impossible to use it for sched_clock() for a while. Fix this
> > and also enable it for the Nomadik.
> >
> > Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
> 
> This one should go to fixes ASAP, could you pick it to your fixes
> branch? It could be tagged stable if desired - this only affects the
> Nomadik which works just OK on jiffies so it's really no big regression.
> The Ux500 does not use the MTU for sched_clock().

Ok, applied on top of next/multiplatform, seems to be what it's based on.

Tagging as stable is up to you as platform owner. :) Since it won't directly
apply to older kernels you might be better of submitting it to Greg separately.


-Olof


From olof at lixom.net  Fri Apr 26 20:18:38 2013
From: olof at lixom.net (Olof Johansson)
Date: Fri, 26 Apr 2013 17:18:38 -0700
Subject: [PATCH/RESEND] ARM: arch_timer: Silence debug preempt warnings
In-Reply-To: <1366241178-16626-1-git-send-email-sboyd@codeaurora.org>
References: <1366241178-16626-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <20130427001838.GA2134@quad.lixom.net>

On Wed, Apr 17, 2013 at 04:26:18PM -0700, Stephen Boyd wrote:
> Hot-plugging with CONFIG_DEBUG_PREEMPT=y on a device with arm
> architected timers causes a slew of "using smp_processor_id() in
> preemptible" warnings:
> 
>   BUG: using smp_processor_id() in preemptible [00000000] code: sh/111
>   caller is arch_timer_cpu_notify+0x14/0xc8
> 
> This happens because sometimes the cpu notifier,
> arch_timer_cpu_notify(), is called in preemptible context and
> other times in non-preemptible context but we use this_cpu_ptr()
> to retrieve the clockevent in all cases. We're only going to
> actually use the pointer in non-preemptible context though, so
> push the this_cpu_ptr() access down into the cases to force the
> checks to occur only in non-preemptible contexts.
> 
> Cc: John Stultz <john.stultz at linaro.org>
> Cc: Thomas Gleixner <tglx at linutronix.de>
> Cc: Mark Rutland <mark.rutland at arm.com>
> Acked-by: Marc Zyngier <Marc.Zyngier at arm.com>
> Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
> ---
> 
> Resending to arm-soc maintainers instead of timekeeping maintainers. Who
> maintains this driver?

Subsystem is maintained by John and Thomas, but given the recent moves of ARM
drivers there (which mostly has been acked by them), we'll take the patch at
this time.

Applied on top of late/clksrc in arm-soc. Thanks.


-Olof


From olof at lixom.net  Fri Apr 26 20:22:03 2013
From: olof at lixom.net (Olof Johansson)
Date: Fri, 26 Apr 2013 17:22:03 -0700
Subject: [PATCH] clk: add option to keep boot clocks on
In-Reply-To: <517B16FF.6070008@infradead.org>
References: <1367019591-31685-1-git-send-email-olof@lixom.net>
 <517B16FF.6070008@infradead.org>
Message-ID: <CAOesGMg0_Awi_b--tuEDFU8tZUqTA46RWuiiBP7=ct00O7zcEw@mail.gmail.com>

On Fri, Apr 26, 2013 at 5:08 PM, Randy Dunlap <rdunlap at infradead.org> wrote:
> On 04/26/13 16:39, Olof Johansson wrote:
>> This is primarily useful when there's a driver that doesn't claim clocks
>> properly, but the bootloader does. It's not expected to be used in normal
>> cases, but for bringup and debug it's very useful to have the option to
>> not gate unclaimed clocks that are still on.
>>
>> Signed-off-by: Olof Johansson <olof at lixom.net>
>
> add to Documentation/kernel-parameters.txt or somewhere else?

Ah, yes, of course. I'll wait for Mike to provide input on the color
of the shed, since it might change location in the file if it's
renamed. And then repost with documentation update.


-Olof


From olof at lixom.net  Fri Apr 26 20:34:13 2013
From: olof at lixom.net (Olof Johansson)
Date: Fri, 26 Apr 2013 17:34:13 -0700
Subject: [PATCH v3 00/13] ARM: EXYNOS: Fix Universal C210 support
In-Reply-To: <201304251646.28026.arnd@arndb.de>
References: <1366731994-7478-1-git-send-email-t.figa@samsung.com>
 <201304251646.28026.arnd@arndb.de>
Message-ID: <20130427003413.GA2350@quad.lixom.net>

On Thu, Apr 25, 2013 at 04:46:27PM +0200, Arnd Bergmann wrote:
> On Tuesday 23 April 2013, Tomasz Figa wrote:
> > This series intends to fix support for Universal C210 board in mainline.
> > Main difference from other boards based on Exynos 4210 is that hardware
> > revision of the SoC used on Universal C210 does not support MCT timers
> > and legacy PWM timers must be used instead.
> > 
> > First (and the biggest) part of the series deals with cleaning up and
> > fixing the samsung_pwm_timer clocksource driver, that was posted
> > recently by Arnd. In addition the driver is prepared to share the
> > hardware with PWM driver that will be reworked later, since it is not
> > a component crucial for system operation.
> > 
> > Second part fixes ATAGS support of Exynos 4210 rev0 SoC, which needs
> > different timer initialization, using the new samsung_pwm_timer driver.
> > 
> > Third and last part adds Device Tree-based support for Universal C210
> > board by providing device tree sources for it.
> > 
> > On Universal C210 board, both with and without DT:
> > 
> > Tested-by: Tomasz Figa <t.figa at samsung.com>
> 
> Reviewed-by: Arnd Bergmann <arnd at arndb.de>
> 
> Olof, Kgene, I think we should have this one in 3.10 since it fixes
> a regression. It looks bigger than it really is because I asked Tomasz
> to do small patches rather than a single combined patch.

Ok. Kukjin, I don't mind collecting this in a late/* branch even though time is
running late, since it's a regression. Do you want to send it to me or should
I just pick up the patches?


-Olof


From olof at lixom.net  Fri Apr 26 20:35:51 2013
From: olof at lixom.net (Olof Johansson)
Date: Fri, 26 Apr 2013 17:35:51 -0700
Subject: [GIT PULL] musb regression on omap4 for v3.9
In-Reply-To: <20130423214544.GN10155@atomide.com>
References: <20130423214544.GN10155@atomide.com>
Message-ID: <20130427003551.GB2350@quad.lixom.net>

On Tue, Apr 23, 2013 at 02:45:45PM -0700, Tony Lindgren wrote:
> 
> The following changes since commit 31880c37c11e28cb81c70757e38392b42e695dc6:
> 
>   Linux 3.9-rc6 (2013-04-07 20:49:54 -0700)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.9-rc6/fixes-signed
> 
> for you to fetch changes up to f4d7a536faa43f30d87f701268db76b8433a2a8b:
> 
>   ARM: OMAP4: hwmod data: make 'ocp2scp_usb_phy_phy_48m" as the main clock (2013-04-10 13:26:07 -0700)
> 
> ----------------------------------------------------------------
> One MUSB regression fix that I forgot to send earlier. Without
> this MUSB no longer works on omap4 based devices.

Pulled into fixes. I'll send a pull request to Linus tonight, hopefully he
won't cut 3.9-final until later this weekend.


-Olof


From olof at lixom.net  Fri Apr 26 20:37:17 2013
From: olof at lixom.net (Olof Johansson)
Date: Fri, 26 Apr 2013 17:37:17 -0700
Subject: Exynos regressions w.r.t. config and debuggability due to
 multiplatform
In-Reply-To: <201304251931.25028.arnd@arndb.de>
References: <CAOesGMgRsa-AvbEZCc1=_ovaZMaG0S-CDok2MDp_zu5yderAYw@mail.gmail.com>
 <201304241703.49864.arnd@arndb.de> <51794CD3.4080807@samsung.com>
 <201304251931.25028.arnd@arndb.de>
Message-ID: <20130427003717.GC2350@quad.lixom.net>

On Thu, Apr 25, 2013 at 07:31:24PM +0200, Arnd Bergmann wrote:
> On Thursday 25 April 2013, Kukjin Kim wrote:
> > 
> > On 04/25/13 00:03, Arnd Bergmann wrote:
> > > On Wednesday 24 April 2013, Olof Johansson wrote:
> > >> I think we should hold off on multiplatform for exynos until it works
> > >> better, i.e. 3.11.
> > >>
> > I think, this would be better choice for now if it's not urgent...
> > 
> 
> I spent a lot of time on it because it's a priority for Linaro, but
> that means I'm biased in the question of whether to merge it or not.
> It should only get in if you and Olof think it's a good idea.

I've reverted the commit you pointed out as the problematic one now,
and with that I get a working setup. That means most of the base patches are
in, just not the final Kconfig shuffling. 3.11 seems more realistic for that.


-Olof


From syin at broadcom.com  Fri Apr 26 20:54:52 2013
From: syin at broadcom.com (Sherman Yin)
Date: Sat, 27 Apr 2013 00:54:52 +0000
Subject: Adding a void * to pinctrl_pin_desc
In-Reply-To: <CACRpkdYxJOWYMfwmrEGhqgjushVjWyc=FyKMaZNLnn=0jrTs9A@mail.gmail.com>
References: <051069C10411E24D9749790C498526FA1BCF4FC6@SJEXCHMB12.corp.ad.broadcom.com>
 <CACRpkdYxJOWYMfwmrEGhqgjushVjWyc=FyKMaZNLnn=0jrTs9A@mail.gmail.com>
Message-ID: <051069C10411E24D9749790C498526FA1BCF54B1@SJEXCHMB12.corp.ad.broadcom.com>

> >  What do you think about expanding the struct to something like this:
> >
> > struct pinctrl_pin_desc {
> >         unsigned number;
> >         const char *name;
> >         void * pin_data;
> > };
> >
> > so that drivers can optionally use pin_data to hold other pin-specific
> information?
> 
> No don't do this.
> 
> Instead:
> 
> struct foo_pin_desc {
>       struct pinctrl_pin_desc desc;
>       ....
>       /* Insert my pindata here */
> };
> 
> Then use container_of() to dereference a struct foo_pin_desc pointer from
> the
> pointer at &foodesc->desc;

Hmm, while it would be easy to create a macro to fill the static foo_pin_desc array 
in the driver, this array would not be suitable for use with pinctrl_register().  
I would have to, in the probe function, loop through the foo_pin_desc array and 
create another pinctrl_pin_desc array to use for pinctrl_desc.pins.

I think I'll just use a separate struct in the driver to keep track of other pin-specific data.

Thanks,
Sherman




From olof at lixom.net  Fri Apr 26 21:01:37 2013
From: olof at lixom.net (Olof Johansson)
Date: Fri, 26 Apr 2013 18:01:37 -0700
Subject: [GIT PULL] Samsung fixes-1 for v3.10
In-Reply-To: <51795C62.8070500@samsung.com>
References: <51795C62.8070500@samsung.com>
Message-ID: <20130427010137.GD2350@quad.lixom.net>

On Fri, Apr 26, 2013 at 01:40:02AM +0900, Kukjin Kim wrote:
> The following changes since commit 58a7bbf75442ea439a4d3b7993ad87023e406063:
> 
>   ARM: dts: add PDMA0 changes for exynos5440 (2013-04-09 01:39:27 +0900)

So these are fixes based on code that's already staged. We normally
don't do that -- if you have a fix for a specific branch that introduced
something, send a fresh pull request for that branch.

Looks like Doug's fix is for the common clock framework branch, so I'll apply
it to next/drivers. Thomas' is for the dt branch. I'll cherry-pick it onto
next/dt2.


-Olof


From olof at lixom.net  Fri Apr 26 21:04:06 2013
From: olof at lixom.net (Olof Johansson)
Date: Fri, 26 Apr 2013 18:04:06 -0700
Subject: [PATCH] ARM: exynos: dts: cros5250: add EC device
In-Reply-To: <CAD=FV=WhoGO8=5pt=VOCT_2j2CMkn8on=N=jK_2RwMOXWat57w@mail.gmail.com>
References: <1367019745-31826-1-git-send-email-olof@lixom.net>
 <CAD=FV=WhoGO8=5pt=VOCT_2j2CMkn8on=N=jK_2RwMOXWat57w@mail.gmail.com>
Message-ID: <20130427010406.GE2350@quad.lixom.net>

On Fri, Apr 26, 2013 at 04:56:51PM -0700, Doug Anderson wrote:
> Olof,
> 
> On Fri, Apr 26, 2013 at 4:42 PM, Olof Johansson <olof at lixom.net> wrote:
> > Add basic EC information to device tree, currently only describing the
> > keyboard and keymap.
> >
> > Signed-off-by: Olof Johansson <olof at lixom.net>
> > Cc: Doug Anderson <dianders at chromium.org>
> > ---
> >
> > Kukjin, I'll apply this too directly if you don't mind.
> >
> >
> > -Olof
> >
> >  arch/arm/boot/dts/cros5250-common.dtsi | 99 +++++++++++++++++++++++++++++++++-
> >  1 file changed, 98 insertions(+), 1 deletion(-)
> 
> I'm not a huge fan of this change as I'd rather see my arbitration
> changes land first and see this based atop those.  The arbitration
> driver has landed so all that's left are the device tree bits.
> 
> That would be:
> 
> https://patchwork.kernel.org/patch/2449961/
> https://patchwork.kernel.org/patch/2449941/
> 
> ...but other than that this looks good.

Ah, yes, of course. As discussed off-mail, I was mislead by some contents in
our local tree. :)

Kukjin, I'd really like to pick up these patches for 3.10, since they're
isolated to just dts changes and gets keyboard working on the Chromebook. Can
you ack them and I'll just collect them this time?

I'll repost a version that goes on top of Doug's patches.


-Olof


From s-anna at ti.com  Fri Apr 26 21:04:45 2013
From: s-anna at ti.com (Suman Anna)
Date: Fri, 26 Apr 2013 20:04:45 -0500
Subject: [PATCHv3 00/14] drivers: mailbox: framework creation
In-Reply-To: <CAJe_Zhf4miUm4yTyuwc56kpD8Mu4=vsmX4wdQkFDT96JbKR=MQ@mail.gmail.com>
References: <1363145021-14339-1-git-send-email-s-anna@ti.com>
 <CABb+yY0RYkVeo2Sb4WsDJY0jf17488FEz0d2CB994eQaSOEsVg@mail.gmail.com>
 <37C860A02101E749A747FA2D3C1E3C504A5DF7@DLEE11.ent.ti.com>
 <CABb+yY1x4x_A+QtGG9ohsLPgs8c3nEVnd_ExJBGOOR8=6YLPFA@mail.gmail.com>
 <37C860A02101E749A747FA2D3C1E3C504A63B4@DLEE11.ent.ti.com>
 <CAJe_ZhehnniZd730jjiOLrHozq8TOJZgFYLqUe4KqgBiQEu8PA@mail.gmail.com>
 <51779304.4040003@st.com>
 <CAJe_ZhdZv5LW6kdwyPtJe69mfW6t=WQ4OJnG2H4sUhibattN2A@mail.gmail.com>
 <517867E1.7050301@ti.com>
 <CAJe_ZhfDZzq+DzA9XDF3PWFUmwcZnDy-mhE4hLNHmf+V4GhOxw@mail.gmail.com>
 <5179AE2F.3040403@ti.com>
 <CAJe_Zhf4miUm4yTyuwc56kpD8Mu4=vsmX4wdQkFDT96JbKR=MQ@mail.gmail.com>
Message-ID: <517B242D.7040902@ti.com>

Hi Jassi,

On 04/25/2013 10:46 PM, Jassi Brar wrote:
> Hi Suman,
> 
> On 26 April 2013 03:59, Suman Anna <s-anna at ti.com> wrote:
>> On 04/25/2013 12:20 AM, Jassi Brar wrote:
>> tranmitting right away. OK, I thought you didn't want buffering, if that
>> is not the case, then the buffering should be within the main driver
>> code, like it is now, but configurable based on the controller or
>> mailbox properties. If it is present in individual controller drivers,
>> then we would be duplicating stuff. Are you envisioning that this be
>> left to the individual controllers?
>>
> Please don't accuse me of such bad visions :)
> I never said no-buffering and I never said buffering should be in
> controller drivers. In fact I don't remember ever objecting to how
> buffering is done in TI's framework.
> A controller could service only 1 request at a time so lets give it
> just 1 at a time. Let the API handle the complexity of buffering.
> 

Alright, guess this got lost in translation :). I interpreted based on
the fact that you wanted to get rid of the size field from the
mailbox_msg definition. Do you have a different mechanism in mind for
the buffering compared to the present one?

>>> I am afraid you are confusing the meaning of 'atomic context' here.
>>> atomic context doesn't mean instant transmission of data, but that the
>>> API calls could be made from even atomic context and that the client &
>>> controller can't sleep in callbacks from the API. So it's not moot.
>>
>> I understood the atomic context, and the question is about the behavior
>> of the '.tx_done' callback when sending from atomic context. Is there
>> such a usecase/need for you in that you want to send a response back
>> from an atomic context, yet get a callback?
>>
> Let me get in detail...
> The TX-Wheel has to tick. Someone has to tell the framework that the
> last TX was consumed by the remote and now it's time to submit the
> next TX (RX will always be driven by the controller's IRQ so it's
> straight).
> If the controller h/w gets some interrupt indicating
> Remote-RTR/TX-Done then the ticker is driven by controller's TX-IRQ
> handler. Otherwise, if the controller does sense RTR but not report
> (by reading status in some register but no irq), then API has to poll
> it periodically and move the ticker. If the controller can neither
> report nor sense RTR, the client/protocol driver must run the ticker
> (usually upon receiving some ACK packet on the RX channel).

OK, I didn't think of a no RTR interrupt-based controller. I would thing
that such a controller is very rudimentary. I wonder if there are any
controllers like this out there.

> This TX ticker should be callable from atomic context (controller's
> IRQ handler) and calls into callback of the client. It is desirable
> that the client be able to submit yet another TX request from the
> callback. That way the client can avoid having to schedule work from
> the callback if the TX doesn't involve any sleepable task. The scheme
> is working very well in DMA-Engine stack.
> 
> BTW, TI's RX mechanism too seems broken for common API. Receiving
> every few bytes via 'notify' mechanism is very inefficient. Imagine a
> platform with no shared memory between co-processors and the local
> wants to diagnose the remote by asking critical data at least KBs in
> size.

No shared memory between co-processors and a relatively slow wire
transport is a bad architecture design to begin with.

>  So when API has nothing to do with received packet and the controller
> has to get rid of it asap so as to be able to receive the next, IMHO
> there should be short-circuit from controller to client via the API.
> No delay, no buffering of RX.

The current TI design is based on the fact that we can get multiple
messages on a single interrupt due to the h/w fifo and the driver takes
care of the bottom-half. Leaving it to the client is putting a lot of
faith in the client and doesn't scale to multiple clients. The client
would have to perform mostly the same as the driver is doing - so this
goes back to the base discussion point that we have - which is the lack
of support for atomic_context receivers in the current code. I perceive
this as an attribute of the controller/mailbox device itself rather than
the client.

> 
> 
>>> It's the controller driver that actually puts the data on the bus. So
>>> only it should define the format in which it accepts data from the
>>> clients. Every client should simply populate the packet structure
>>> defined in  my_lovely_controller.h and pass on the struct pointer to
>>> the controller driver via API.
>>> No negotiations for the driver seat among passengers :)
>>
>> OK, I was trying to avoid including my_lovely_controller.h and only
>> include the standard .h file as a client user, the client would anyway
>> need to have the intrinsic knowledge of the packet structure.
>>
> Not including my_controller.h doesn't make things standard.
> As we know, the client anyway has to have intrinsic knowledge of the
> packet structure(which is dictated by the controller), so not
> including my_controller.h will only confuse people as to where the
> packet info came from?

OK, agreed.

> 
>>>>
>>> I think the mailbox should be exclusively held by a client. That makes
>>> many things simpler. Also remote firmwares won't be always robust
>>> enough to handle commands from different subsystems intermixed. The
>>> API only has to make sure the mailbox_get/put operations are very
>>> thin.
>>
>> This might be the case for specific remotes where we expect only one
>> client driver to be responsible for talking to it, but for generic
>> offloading, you do not want to have this restriction. You do not want
>> peer clients to go through a single main client, as the latencies or the
>> infrastructure imposed by the main client may not be suitable for the
>> other clients. The stricter usecase here would be the shareable mailbox,
>> and if it is exclusive, as dictated by a controller or device property,
>> then so be it and things would get simplified for that controller/device.
>>
> Shared Vs Exclusive had been the dilemma of DMAEngine too.
> If the controller has physical channels at least as many as clients,
> exclusivity is no problem.
> Sharing is desirable when the controller has to serve clients more
> than its physical channels. We solve that by having the controller
> declare exclusive virtual channels and internally scheduling the
> requests onto physical channels.
>  And as Andy pointed out, some remote-ends may not cope with requests
> coming from different subsystems intermixed.

Even though both the scenarios look very similar, I believe there are
some slight differences. All the devices belonging to a controller may
not be of the same type (meaning, intended towards the same remote or be
used interchangeably with one another). It is definitely possible if you
have a similar scenario to the DMA physical channels and your remote
rx interrupt can identify the device/channel to process. This would be
very much dependent on the architecture of a controller. The particular
example that I have in mind is s/w clients between the same set of
remote and host entities using the same device - the send part is anyway
arbitrated by the controller, and the same received message can be
delivered to the clients, with the clients making the decision whether
the packet belongs to them or not. I agree that all remote-ends will not
be able to cope up intermixed requests, but isn't this again a
controller architecture dependent?

regards
Suman


From laurent.pinchart at ideasonboard.com  Fri Apr 26 21:16:47 2013
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Sat, 27 Apr 2013 03:16:47 +0200
Subject: [PATCH] pinctrl: document the "GPIO mode" pitfall
In-Reply-To: <CACRpkdaMdU4DHWULnSB_dvGk8pTRbirL1HVTGqJ2rwqXR798uQ@mail.gmail.com>
References: <1363345636-2006-1-git-send-email-linus.walleij@stericsson.com>
 <1761651.lXztZzrj1S@avalon>
 <CACRpkdaMdU4DHWULnSB_dvGk8pTRbirL1HVTGqJ2rwqXR798uQ@mail.gmail.com>
Message-ID: <2359346.pRaN3J5Bl7@avalon>

Hi Linus,

On Friday 26 April 2013 10:49:12 Linus Walleij wrote:
> On Fri, Apr 26, 2013 at 1:15 AM, Laurent Pinchart wrote:
> > On Thursday 25 April 2013 23:39:18 Linus Walleij wrote:
> >> On Tue, Apr 23, 2013 at 3:33 PM, Laurent Pinchart wrote:
> >> > Could you clarify the exact scope of the two configuration parameters ?
> >> 
> >> PIN_CONFIG_OUTPUT is left a bit unspecified, but here the idea was a
> >> passive drive, like just connecting the pin to VDD or GND without any
> >> driver stage at all.
> > 
> > Isn't that a driver stage ? :-)
> 
> OK something that is not a totempole type drive ...
> push/pull surely implies a totempole type design.
> 
> > What is unclear to me is the interaction between OUTPUT and DRIVE_*.
> > That's the part I would like to see clarified.
> 
> I sent some patch now, check it ... hm reported-by still doesn't add
> you to CC :-/ better patch git-send-email...
> 
> > Does DRIVE_* imply that the pin is driven by the selected function, and
> > OUTPUT imply that the pin is driven to a fixed level ?
> 
> That is unclear, but I suggest DRIVE* implies that everything on the pin
> is driven according to that configuration. (Else it is getting ignored...)
> 
> OUTPUT would be used when you don't know the particulars or when
> the driving cannot be controlled in a fine-grained manner like with the
> DRIVE* configs.
> 
> Does this make sense?

Kinda, but it's still unclear to me. While the options are (briefly) 
documented, how they interact isn't.
 
> > If so, how do you configure the drive type of a pin that will be used
> > through the GPIO API ?
> 
> It is possible to use the pinctrl and GPIO APIs orthogonally.
> 
> For example the pinctrl can use hogs to reconfigure the pins during sleep
> without intervention from the GPIO API.
> 
> So they will be fingering on the same pins registers. Maybe even the same
> register (if access can be protected properly) from different APIs.
>
> > What about cases where I want to drive the pin to a fixed level in a non
> > low-power output mode (for instance because I need more current that what
> > the low-power output mode provides) ?
> 
> Just use pinconfig for that?

How would you do so ? Only OUTPUT allows setting the output level explictly, 
the other DRIVE_* options don't specify the output level.

> Is the usecase something like a power-supplying GPIO pin and then sometimes
> you want to provide more power from it?
> 
> Then use pinconfig to shunt in the driver stages, and GPIO API to
> enable/disable it.

-- 
Regards,

Laurent Pinchart



From andy.green at linaro.org  Fri Apr 26 21:48:05 2013
From: andy.green at linaro.org (Andy Green)
Date: Sat, 27 Apr 2013 09:48:05 +0800
Subject: [PATCHv3 00/14] drivers: mailbox: framework creation
In-Reply-To: <517B242D.7040902@ti.com>
References: <1363145021-14339-1-git-send-email-s-anna@ti.com>
 <CABb+yY0RYkVeo2Sb4WsDJY0jf17488FEz0d2CB994eQaSOEsVg@mail.gmail.com>
 <37C860A02101E749A747FA2D3C1E3C504A5DF7@DLEE11.ent.ti.com>
 <CABb+yY1x4x_A+QtGG9ohsLPgs8c3nEVnd_ExJBGOOR8=6YLPFA@mail.gmail.com>
 <37C860A02101E749A747FA2D3C1E3C504A63B4@DLEE11.ent.ti.com>
 <CAJe_ZhehnniZd730jjiOLrHozq8TOJZgFYLqUe4KqgBiQEu8PA@mail.gmail.com>
 <51779304.4040003@st.com>
 <CAJe_ZhdZv5LW6kdwyPtJe69mfW6t=WQ4OJnG2H4sUhibattN2A@mail.gmail.com>
 <517867E1.7050301@ti.com>
 <CAJe_ZhfDZzq+DzA9XDF3PWFUmwcZnDy-mhE4hLNHmf+V4GhOxw@mail.gmail.com>
 <5179AE2F.3040403@ti.com>
 <CAJe_Zhf4miUm4yTyuwc56kpD8Mu4=vsmX4wdQkFDT96JbKR=MQ@mail.gmail.com>
 <517B242D.7040902@ti.com>
Message-ID: <517B2E55.4070708@linaro.org>

On 27/04/13 09:04, the mail apparently from Suman Anna included:

Hi Suman -

> Even though both the scenarios look very similar, I believe there are
> some slight differences. All the devices belonging to a controller may
> not be of the same type (meaning, intended towards the same remote or be
> used interchangeably with one another). It is definitely possible if you
> have a similar scenario to the DMA physical channels and your remote
> rx interrupt can identify the device/channel to process. This would be
> very much dependent on the architecture of a controller. The particular
> example that I have in mind is s/w clients between the same set of
> remote and host entities using the same device - the send part is anyway
> arbitrated by the controller, and the same received message can be
> delivered to the clients, with the clients making the decision whether
> the packet belongs to them or not. I agree that all remote-ends will not
> be able to cope up intermixed requests, but isn't this again a
> controller architecture dependent?

Maybe it's helpful to describe our situation more concretely, because 
the problem is not coming from "the architecture of the [mailbox] 
controller".

In the SoC we work on clock and subsystem power control registers, a 
serial bus, and some other assets are not directly accessible from 
Linux.  We must ask a coprocessor to operate these for us, using the 
mailbox.

So at any one time, the clock driver or voltagedomain driver for the SoC 
may want to own the mailbox and perform one or more operations over it 
synchronously, in some cases on the remote side involving transactions 
on a serial bus.  We don't want other transactions to be occurring while 
we wait for the serial bus to complete what the driver who started that 
asked for, for example.

We can cope with this by having an outer driver mediate access to the 
mailbox.  But then there are multiple sync primitives like completions 
and notifiers per operation, because your core already does this.

In short the FIFO + sync operations approach your core implements 
doesn't fit our use case.  That can be our problem, in which case we'll 
live with the outer mediation driver on top of the mailbox, or it can be 
a sign the fixed choice of FIFO + sync operations in your core did not 
quite hit the nail on the head to really model all the facets of legit 
mailbox usage.

At least, this real scenario should be interesting to think about before 
rejecting ^^

-Andy

-- 
Andy Green | Fujitsu Landing Team Leader
Linaro.org ? Open source software for ARM SoCs | Follow Linaro
http://facebook.com/pages/Linaro/155974581091106  - 
http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog


From dianders at chromium.org  Sat Apr 27 00:04:56 2013
From: dianders at chromium.org (Doug Anderson)
Date: Fri, 26 Apr 2013 21:04:56 -0700
Subject: [PATCH] ARM: exynos: dts: cros5250: add EC device
In-Reply-To: <20130427010406.GE2350@quad.lixom.net>
References: <1367019745-31826-1-git-send-email-olof@lixom.net>
 <CAD=FV=WhoGO8=5pt=VOCT_2j2CMkn8on=N=jK_2RwMOXWat57w@mail.gmail.com>
 <20130427010406.GE2350@quad.lixom.net>
Message-ID: <CAD=FV=VQg=2R_x11xuGiA0kNj1NXHUM3TUzVJC-F0ZWO39JRdw@mail.gmail.com>

Olof,

On Fri, Apr 26, 2013 at 6:04 PM, Olof Johansson <olof at lixom.net> wrote:
> Ah, yes, of course. As discussed off-mail, I was mislead by some contents in
> our local tree. :)

Sorry about that--that was my fault.  Things have landed in a
different order in one of our local trees.


> Kukjin, I'd really like to pick up these patches for 3.10, since they're
> isolated to just dts changes and gets keyboard working on the Chromebook. Can
> you ack them and I'll just collect them this time?

I'm pretty sure that Kukjin is OK with them.  Kukjin responded earlier and said:

> I'm fine on 2nd and 3rd patches. Shall I take only two patches without 1st
> one in samsung tree?

At the time we were waiting for Wolfram to get patch 1 into his tree,
which is now done.

...but waiting for his official Ack is good, too.  ;)

-Doug


From jaswinder.singh at linaro.org  Sat Apr 27 00:51:48 2013
From: jaswinder.singh at linaro.org (Jassi Brar)
Date: Sat, 27 Apr 2013 10:21:48 +0530
Subject: [PATCHv3 00/14] drivers: mailbox: framework creation
In-Reply-To: <517B242D.7040902@ti.com>
References: <1363145021-14339-1-git-send-email-s-anna@ti.com>
 <CABb+yY0RYkVeo2Sb4WsDJY0jf17488FEz0d2CB994eQaSOEsVg@mail.gmail.com>
 <37C860A02101E749A747FA2D3C1E3C504A5DF7@DLEE11.ent.ti.com>
 <CABb+yY1x4x_A+QtGG9ohsLPgs8c3nEVnd_ExJBGOOR8=6YLPFA@mail.gmail.com>
 <37C860A02101E749A747FA2D3C1E3C504A63B4@DLEE11.ent.ti.com>
 <CAJe_ZhehnniZd730jjiOLrHozq8TOJZgFYLqUe4KqgBiQEu8PA@mail.gmail.com>
 <51779304.4040003@st.com>
 <CAJe_ZhdZv5LW6kdwyPtJe69mfW6t=WQ4OJnG2H4sUhibattN2A@mail.gmail.com>
 <517867E1.7050301@ti.com>
 <CAJe_ZhfDZzq+DzA9XDF3PWFUmwcZnDy-mhE4hLNHmf+V4GhOxw@mail.gmail.com>
 <5179AE2F.3040403@ti.com>
 <CAJe_Zhf4miUm4yTyuwc56kpD8Mu4=vsmX4wdQkFDT96JbKR=MQ@mail.gmail.com>
 <517B242D.7040902@ti.com>
Message-ID: <CAJe_ZhdH+SCs5crguXrm6y-6bu+eGnTqeJS6cOS5H5Yz=m15Cw@mail.gmail.com>

Hi Suman,

>> On 26 April 2013 03:59, Suman Anna <s-anna at ti.com> wrote:
>>> On 04/25/2013 12:20 AM, Jassi Brar wrote:

>> I never said no-buffering and I never said buffering should be in
>> controller drivers. In fact I don't remember ever objecting to how
>> buffering is done in TI's framework.
>> A controller could service only 1 request at a time so lets give it
>> just 1 at a time. Let the API handle the complexity of buffering.
>>
>
> Alright, guess this got lost in translation :). I interpreted based on
> the fact that you wanted to get rid of the size field from the
> mailbox_msg definition. Do you have a different mechanism in mind for
> the buffering compared to the present one?
>
Sure, a very simple but efficient one. I had started on pseudo code
implementation the day I first replied, but now I have real code with
the PL320 controller and the Highbank client converted to the API. All
that I say features in the new design. Polishing and documentation
will take just a few hours more. You could see end to end what I have
been talking about.


>
> OK, I didn't think of a no RTR interrupt-based controller. I would thing
> that such a controller is very rudimentary. I wonder if there are any
> controllers like this out there.
>
One of my controllers is like that :)

>>
>> BTW, TI's RX mechanism too seems broken for common API. Receiving
>> every few bytes via 'notify' mechanism is very inefficient. Imagine a
>> platform with no shared memory between co-processors and the local
>> wants to diagnose the remote by asking critical data at least KBs in
>> size.
>
> No shared memory between co-processors and a relatively slow wire
> transport is a bad architecture design to begin with.
>
IMHO it's only about private memory. Even if the controller transfers,
say, 10bytes/interrupt there could always be a requirement to read
some 1MB region of remote's private memory. And the same logic implies
that our TX too should be as fast as possible - the remote might need
its 1MB firmware over the link. So let us just try to serve all
designs rather than evaluate them :)


>>  So when API has nothing to do with received packet and the controller
>> has to get rid of it asap so as to be able to receive the next, IMHO
>> there should be short-circuit from controller to client via the API.
>> No delay, no buffering of RX.
>
> The current TI design is based on the fact that we can get multiple
> messages on a single interrupt due to the h/w fifo and the driver takes
> care of the bottom-half. Leaving it to the client is putting a lot of
> faith in the client and doesn't scale to multiple clients. The client
> would have to perform mostly the same as the driver is doing - so this
> goes back to the base discussion point that we have - which is the lack
> of support for atomic_context receivers in the current code. I perceive
> this as an attribute of the controller/mailbox device itself rather than
> the client.
>
Sorry, I don't understand the concern about faith.
If the controller h/w absolutely can not tell the remote(sender) of a
received packet (as seems to be your case), its driver shouldn't even
try to demux the received messages. The client driver must know which
remotes could send it a message and how to discern them on the
platform. Some 'server' RX client is needed here.
If the controller could indeed map received packet onto remotes, then
ideally the controller driver should declare one (RX only) channel for
each such remote and demux packets onto them.
In either case, 'notify' mechanism is not necessary.


> I agree that all remote-ends will not
> be able to cope up intermixed requests, but isn't this again a
> controller architecture dependent?
>
I think it's more about remote's protocol implementation than
controller's architecture.
If tomorrow TI's remote firmware introduces a new set of critical
commands that may arrive only in a particular sequence, you'll find
yourself sharing a ride on our dinghy :)
And Andy already explained where we come from.

Regards,
-Jassi


From shc_work at mail.ru  Sat Apr 27 01:06:38 2013
From: shc_work at mail.ru (Alexander Shiyan)
Date: Sat, 27 Apr 2013 09:06:38 +0400
Subject: [PATCH] media: coda: Fix compile breakage
Message-ID: <1367039198-28639-1-git-send-email-shc_work@mail.ru>

Patch adds GENERIC_ALLOCATOR, if "coda" is selected.

drivers/built-in.o: In function `coda_remove':
:(.text+0x110634): undefined reference to `gen_pool_free'
drivers/built-in.o: In function `coda_probe':
:(.text+0x1107d4): undefined reference to `of_get_named_gen_pool'
:(.text+0x1108b8): undefined reference to `gen_pool_alloc'
:(.text+0x1108d0): undefined reference to `gen_pool_virt_to_phys'
:(.text+0x110918): undefined reference to `dev_get_gen_pool'

Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
---
 drivers/media/platform/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 0cbe1ff..414a769 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -145,6 +145,7 @@ config VIDEO_CODA
 	depends on VIDEO_DEV && VIDEO_V4L2 && ARCH_MXC
 	select VIDEOBUF2_DMA_CONTIG
 	select V4L2_MEM2MEM_DEV
+	select GENERIC_ALLOCATOR
 	---help---
 	   Coda is a range of video codec IPs that supports
 	   H.264, MPEG-4, and other video formats.
-- 
1.8.1.5



From linux at prisktech.co.nz  Sat Apr 27 01:30:15 2013
From: linux at prisktech.co.nz (Tony Prisk)
Date: Sat, 27 Apr 2013 17:30:15 +1200
Subject: VIA velocity network driver
Message-ID: <517B6267.4070404@prisktech.co.nz>

I would like to add support to this driver for platform devices as found 
on VIA's APC8750 board. At the moment, I have a standalone platform 
version that works fine, but wanted to ask a few questions before 
sending a patch to merge this code into one driver.

The current driver is for PCI network cards, and uses pci dma functions. 
Most of the pci dma functions are wrappers around other functions which 
is what I have used for the platform version. For example:

rd_info->skb_dma = pci_map_single(vptr->pdev, rd_info->skb->data,
                     vptr->rx.buf_sz, PCI_DMA_FROMDEVICE);

is replaced with:
rd_info->skb_dma = dma_map_single(&vptr->plat_dev->dev, rd_info->skb->data,
                     vptr->rx.buf_sz, DMA_FROM_DEVICE);

Is it ok to use the non-pci versions (which are basically just the 
unwrapped pci versions) and pass the struct device *, or will I need to 
use the correct function for the correct instance.

Other than adding some new probe/remove functions, this is all that is 
needed to add platform driver support.

One bug/problem that arose is to do with the EEPROM code in 
velocity_init_registers(), in the case for VELOCITY_INIT_COLD:

         mac_eeprom_reload(regs);
         for (i = 0; i < 6; i++)
             writeb(vptr->dev->dev_addr[i], &(regs->PAR[i]));

I assume this is loading something from an EEPROM, but there is no 
EEPROM on the APC8750. Removing this code, the driver seems to work fine 
on the APC8750.
Could it be avoided with a vptr->has_no_eeprom that defaults to 0 to 
avoid breaking existing support?

Regards
Tony Prisk


From shc_work at mail.ru  Sat Apr 27 02:29:24 2013
From: shc_work at mail.ru (Alexander Shiyan)
Date: Sat, 27 Apr 2013 10:29:24 +0400
Subject: [PATCH v2 1/2] regulator: mc13xxx: Add warning of incorrect names of
 regulators
Message-ID: <1367044165-6373-1-git-send-email-shc_work@mail.ru>

This patch adds a warning about incorrect regulators instead of
printing the names of non-information message about the wrong amount.

Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
---
 drivers/regulator/mc13892-regulator.c      | 39 +++---------------------------
 drivers/regulator/mc13xxx-regulator-core.c | 17 +++++++++----
 drivers/regulator/mc13xxx.h                |  4 +--
 3 files changed, 17 insertions(+), 43 deletions(-)

diff --git a/drivers/regulator/mc13892-regulator.c b/drivers/regulator/mc13892-regulator.c
index 714377c..b716283 100644
--- a/drivers/regulator/mc13892-regulator.c
+++ b/drivers/regulator/mc13892-regulator.c
@@ -536,7 +536,7 @@ static int mc13892_regulator_probe(struct platform_device *pdev)
 	struct mc13xxx_regulator_init_data *mc13xxx_data;
 	struct regulator_config config = { };
 	int i, ret;
-	int num_regulators = 0, num_parsed;
+	int num_regulators = 0;
 	u32 val;
 
 	num_regulators = mc13xxx_get_num_regulators_dt(pdev);
@@ -546,8 +546,6 @@ static int mc13892_regulator_probe(struct platform_device *pdev)
 	if (num_regulators <= 0)
 		return -EINVAL;
 
-	num_parsed = num_regulators;
-
 	priv = devm_kzalloc(&pdev->dev, sizeof(*priv) +
 		num_regulators * sizeof(priv->regulators[0]),
 		GFP_KERNEL);
@@ -590,40 +588,9 @@ static int mc13892_regulator_probe(struct platform_device *pdev)
 		= mc13892_vcam_get_mode;
 
 	mc13xxx_data = mc13xxx_parse_regulators_dt(pdev, mc13892_regulators,
-					ARRAY_SIZE(mc13892_regulators),
-					&num_parsed);
-
-	/*
-	 * Perform a little sanity check on the regulator tree - if we found
-	 * a number of regulators from mc13xxx_get_num_regulators_dt and
-	 * then parsed a smaller number in mc13xxx_parse_regulators_dt then
-	 * there is a regulator defined in the regulators node which has
-	 * not matched any usable regulator in the driver. In this case,
-	 * there is one missing and what will happen is the first regulator
-	 * will get registered again.
-	 *
-	 * Fix this by basically making our number of registerable regulators
-	 * equal to the number of regulators we parsed. We are allocating
-	 * too much memory for priv, but this is unavoidable at this point.
-	 *
-	 * As an example of how this can happen, try making a typo in your
-	 * regulators node (vviohi {} instead of viohi {}) so that the name
-	 * does not match..
-	 *
-	 * The check will basically pass for platform data (non-DT) because
-	 * mc13xxx_parse_regulators_dt for !CONFIG_OF will not touch num_parsed.
-	 *
-	 */
-	if (num_parsed != num_regulators) {
-		dev_warn(&pdev->dev,
-		"parsed %d != regulators %d - check your device tree!\n",
-			num_parsed, num_regulators);
-
-		num_regulators = num_parsed;
-		priv->num_regulators = num_regulators;
-	}
+					ARRAY_SIZE(mc13892_regulators));
 
-	for (i = 0; i < num_regulators; i++) {
+	for (i = 0; i < priv->num_regulators; i++) {
 		struct regulator_init_data *init_data;
 		struct regulator_desc *desc;
 		struct device_node *node = NULL;
diff --git a/drivers/regulator/mc13xxx-regulator-core.c b/drivers/regulator/mc13xxx-regulator-core.c
index 23cf9f9..da48592 100644
--- a/drivers/regulator/mc13xxx-regulator-core.c
+++ b/drivers/regulator/mc13xxx-regulator-core.c
@@ -180,15 +180,13 @@ EXPORT_SYMBOL_GPL(mc13xxx_get_num_regulators_dt);
 
 struct mc13xxx_regulator_init_data *mc13xxx_parse_regulators_dt(
 	struct platform_device *pdev, struct mc13xxx_regulator *regulators,
-	int num_regulators, int *num_parsed)
+	int num_regulators)
 {
 	struct mc13xxx_regulator_priv *priv = platform_get_drvdata(pdev);
 	struct mc13xxx_regulator_init_data *data, *p;
 	struct device_node *parent, *child;
 	int i, parsed = 0;
 
-	*num_parsed = 0;
-
 	of_node_get(pdev->dev.parent->of_node);
 	parent = of_find_node_by_name(pdev->dev.parent->of_node, "regulators");
 	if (!parent)
@@ -204,10 +202,13 @@ struct mc13xxx_regulator_init_data *mc13xxx_parse_regulators_dt(
 	p = data;
 
 	for_each_child_of_node(parent, child) {
+		int found = 0;
+
 		for (i = 0; i < num_regulators; i++) {
+			if (!regulators[i].desc.name)
+				continue;
 			if (!of_node_cmp(child->name,
 					 regulators[i].desc.name)) {
-
 				p->id = i;
 				p->init_data = of_get_regulator_init_data(
 							&pdev->dev, child);
@@ -215,13 +216,19 @@ struct mc13xxx_regulator_init_data *mc13xxx_parse_regulators_dt(
 				p++;
 
 				parsed++;
+				found = 1;
 				break;
 			}
 		}
+
+		if (!found)
+			dev_warn(&pdev->dev,
+				 "Unknown regulator: %s\n", child->name);
 	}
 	of_node_put(parent);
 
-	*num_parsed = parsed;
+	priv->num_regulators = parsed;
+
 	return data;
 }
 EXPORT_SYMBOL_GPL(mc13xxx_parse_regulators_dt);
diff --git a/drivers/regulator/mc13xxx.h b/drivers/regulator/mc13xxx.h
index 007f833..06c8903 100644
--- a/drivers/regulator/mc13xxx.h
+++ b/drivers/regulator/mc13xxx.h
@@ -39,7 +39,7 @@ extern int mc13xxx_fixed_regulator_set_voltage(struct regulator_dev *rdev,
 extern int mc13xxx_get_num_regulators_dt(struct platform_device *pdev);
 extern struct mc13xxx_regulator_init_data *mc13xxx_parse_regulators_dt(
 	struct platform_device *pdev, struct mc13xxx_regulator *regulators,
-	int num_regulators, int *num_parsed);
+	int num_regulators);
 #else
 static inline int mc13xxx_get_num_regulators_dt(struct platform_device *pdev)
 {
@@ -48,7 +48,7 @@ static inline int mc13xxx_get_num_regulators_dt(struct platform_device *pdev)
 
 static inline struct mc13xxx_regulator_init_data *mc13xxx_parse_regulators_dt(
 	struct platform_device *pdev, struct mc13xxx_regulator *regulators,
-	int num_regulators, int *num_parsed)
+	int num_regulators)
 {
 	return NULL;
 }
-- 
1.8.1.5



From shc_work at mail.ru  Sat Apr 27 02:29:25 2013
From: shc_work at mail.ru (Alexander Shiyan)
Date: Sat, 27 Apr 2013 10:29:25 +0400
Subject: [PATCH v2 2/2] regulator: mc13783: Add device tree probe support
In-Reply-To: <1367044165-6373-1-git-send-email-shc_work@mail.ru>
References: <1367044165-6373-1-git-send-email-shc_work@mail.ru>
Message-ID: <1367044165-6373-2-git-send-email-shc_work@mail.ru>

Patch adds device tree probe support for mc13783-regulator driver.

Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
---
 Documentation/devicetree/bindings/mfd/mc13xxx.txt | 36 +++++++++++++++++--
 drivers/regulator/mc13783-regulator.c             | 44 +++++++++++++++--------
 2 files changed, 62 insertions(+), 18 deletions(-)

diff --git a/Documentation/devicetree/bindings/mfd/mc13xxx.txt b/Documentation/devicetree/bindings/mfd/mc13xxx.txt
index baf0798..abd9e3c 100644
--- a/Documentation/devicetree/bindings/mfd/mc13xxx.txt
+++ b/Documentation/devicetree/bindings/mfd/mc13xxx.txt
@@ -10,10 +10,40 @@ Optional properties:
 - fsl,mc13xxx-uses-touch : Indicate the touchscreen controller is being used
 
 Sub-nodes:
-- regulators : Contain the regulator nodes.  The MC13892 regulators are
-  bound using their names as listed below with their registers and bits
-  for enabling.
+- regulators : Contain the regulator nodes. The regulators are bound using
+  their names as listed below with their registers and bits for enabling.
 
+MC13783 regulators:
+    sw1a      : regulator SW1A      (register 24, bit 0)
+    sw1b      : regulator SW1B      (register 25, bit 0)
+    sw2a      : regulator SW2A      (register 26, bit 0)
+    sw2b      : regulator SW2B      (register 27, bit 0)
+    sw3       : regulator SW3       (register 29, bit 20)
+    vaudio    : regulator VAUDIO    (register 32, bit 0)
+    viohi     : regulator VIOHI     (register 32, bit 3)
+    violo     : regulator VIOLO     (register 32, bit 6)
+    vdig      : regulator VDIG      (register 32, bit 9)
+    vgen      : regulator VGEN      (register 32, bit 12)
+    vrfdig    : regulator VRFDIG    (register 32, bit 15)
+    vrfref    : regulator VRFREF    (register 32, bit 18)
+    vrfcp     : regulator VRFCP     (register 32, bit 21)
+    vsim      : regulator VSIM      (register 33, bit 0)
+    vesim     : regulator VESIM     (register 33, bit 3)
+    vcam      : regulator VCAM      (register 33, bit 6)
+    vrfbg     : regulator VRFBG     (register 33, bit 9)
+    vvib      : regulator VVIB      (register 33, bit 11)
+    vrf1      : regulator VRF1      (register 33, bit 12)
+    vrf2      : regulator VRF2      (register 33, bit 15)
+    vmmc1     : regulator VMMC1     (register 33, bit 18)
+    vmmc2     : regulator VMMC2     (register 33, bit 21)
+    gpo1      : regulator GPO1      (register 34, bit 6)
+    gpo2      : regulator GPO2      (register 34, bit 8)
+    gpo3      : regulator GPO3      (register 34, bit 10)
+    gpo4      : regulator GPO4      (register 34, bit 12)
+    pwgt1spi  : regulator PWGT1SPI  (register 34, bit 15)
+    pwgt2spi  : regulator PWGT2SPI  (register 34, bit 16)
+
+MC13892 regulators:
     vcoincell : regulator VCOINCELL (register 13, bit 23)
     sw1       : regulator SW1	    (register 24, bit 0)
     sw2       : regulator SW2	    (register 25, bit 0)
diff --git a/drivers/regulator/mc13783-regulator.c b/drivers/regulator/mc13783-regulator.c
index c46c670..fdf7f0a 100644
--- a/drivers/regulator/mc13783-regulator.c
+++ b/drivers/regulator/mc13783-regulator.c
@@ -398,33 +398,51 @@ static int mc13783_regulator_probe(struct platform_device *pdev)
 	struct mc13xxx *mc13783 = dev_get_drvdata(pdev->dev.parent);
 	struct mc13xxx_regulator_platform_data *pdata =
 		dev_get_platdata(&pdev->dev);
-	struct mc13xxx_regulator_init_data *init_data;
+	struct mc13xxx_regulator_init_data *mc13xxx_data;
 	struct regulator_config config = { };
-	int i, ret;
+	int i, ret, num_regulators;
 
-	dev_dbg(&pdev->dev, "%s id %d\n", __func__, pdev->id);
+	num_regulators = mc13xxx_get_num_regulators_dt(pdev);
 
-	if (!pdata)
+	if (num_regulators <= 0 && pdata)
+		num_regulators = pdata->num_regulators;
+	if (num_regulators <= 0)
 		return -EINVAL;
 
 	priv = devm_kzalloc(&pdev->dev, sizeof(*priv) +
-			pdata->num_regulators * sizeof(priv->regulators[0]),
+			num_regulators * sizeof(priv->regulators[0]),
 			GFP_KERNEL);
 	if (!priv)
 		return -ENOMEM;
 
+	priv->num_regulators = num_regulators;
 	priv->mc13xxx_regulators = mc13783_regulators;
 	priv->mc13xxx = mc13783;
+	platform_set_drvdata(pdev, priv);
 
-	for (i = 0; i < pdata->num_regulators; i++) {
-		struct regulator_desc *desc;
+	mc13xxx_data = mc13xxx_parse_regulators_dt(pdev, mc13783_regulators,
+					ARRAY_SIZE(mc13783_regulators));
 
-		init_data = &pdata->regulators[i];
-		desc = &mc13783_regulators[init_data->id].desc;
+	for (i = 0; i < priv->num_regulators; i++) {
+		struct regulator_init_data *init_data;
+		struct regulator_desc *desc;
+		struct device_node *node = NULL;
+		int id;
+
+		if (mc13xxx_data) {
+			id = mc13xxx_data[i].id;
+			init_data = mc13xxx_data[i].init_data;
+			node = mc13xxx_data[i].node;
+		} else {
+			id = pdata->regulators[i].id;
+			init_data = pdata->regulators[i].init_data;
+		}
+		desc = &mc13783_regulators[id].desc;
 
 		config.dev = &pdev->dev;
-		config.init_data = init_data->init_data;
+		config.init_data = init_data;
 		config.driver_data = priv;
+		config.of_node = node;
 
 		priv->regulators[i] = regulator_register(desc, &config);
 		if (IS_ERR(priv->regulators[i])) {
@@ -435,8 +453,6 @@ static int mc13783_regulator_probe(struct platform_device *pdev)
 		}
 	}
 
-	platform_set_drvdata(pdev, priv);
-
 	return 0;
 err:
 	while (--i >= 0)
@@ -448,13 +464,11 @@ err:
 static int mc13783_regulator_remove(struct platform_device *pdev)
 {
 	struct mc13xxx_regulator_priv *priv = platform_get_drvdata(pdev);
-	struct mc13xxx_regulator_platform_data *pdata =
-		dev_get_platdata(&pdev->dev);
 	int i;
 
 	platform_set_drvdata(pdev, NULL);
 
-	for (i = 0; i < pdata->num_regulators; i++)
+	for (i = 0; i < priv->num_regulators; i++)
 		regulator_unregister(priv->regulators[i]);
 
 	return 0;
-- 
1.8.1.5



From weiyj.lk at gmail.com  Sat Apr 27 03:45:30 2013
From: weiyj.lk at gmail.com (Wei Yongjun)
Date: Sat, 27 Apr 2013 15:45:30 +0800
Subject: [PATCH -next] xen/arm: remove duplicated include from enlighten.c
Message-ID: <CAPgLHd95AtzEDXUMHryWmmVAkBfkh42hgeLKdSLFYwkO_JB-ZA@mail.gmail.com>

From: Wei Yongjun <yongjun_wei at trendmicro.com.cn>

Remove duplicated include.

Signed-off-by: Wei Yongjun <yongjun_wei at trendmicro.com.cn>
---
 arch/arm/xen/enlighten.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 9a0a917..d30042e 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -10,7 +10,6 @@
 #include <xen/platform_pci.h>
 #include <xen/xenbus.h>
 #include <xen/page.h>
-#include <xen/xen.h>
 #include <xen/interface/sched.h>
 #include <xen/xen-ops.h>
 #include <asm/xen/hypervisor.h>



From anup.patel at linaro.org  Sat Apr 27 04:08:06 2013
From: anup.patel at linaro.org (Anup Patel)
Date: Sat, 27 Apr 2013 13:38:06 +0530
Subject: [PATCH] ARM: KVM: Allow host virt timer irq to be different from
 guest timer virt irq
Message-ID: <1367050086-2902-1-git-send-email-anup.patel@linaro.org>

The arch_timer irq numbers (or PPI numbers) are implementation dependent so, the host virtual timer irq number can be different from guest virtual timer irq number.

This patch ensures that host virtual timer irq number is read from DTB and guest virtual timer irq is determined based on vcpu target type.

Signed-off-by: Anup Patel <anup.patel at linaro.org>
Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar at linaro.org>
---
 arch/arm/include/asm/kvm_arch_timer.h |    9 +++++++++
 arch/arm/kvm/arch_timer.c             |   35 ++++++++++++++++++++++++++-------
 arch/arm/kvm/reset.c                  |   11 ++++++++++-
 3 files changed, 47 insertions(+), 8 deletions(-)

diff --git a/arch/arm/include/asm/kvm_arch_timer.h b/arch/arm/include/asm/kvm_arch_timer.h
index 68cb9e1..51b0316 100644
--- a/arch/arm/include/asm/kvm_arch_timer.h
+++ b/arch/arm/include/asm/kvm_arch_timer.h
@@ -61,6 +61,8 @@ struct arch_timer_cpu {
 #ifdef CONFIG_KVM_ARM_TIMER
 int kvm_timer_hyp_init(void);
 int kvm_timer_init(struct kvm *kvm);
+int kvm_timer_vcpu_reset(struct kvm_vcpu *vcpu, 
+			 const struct kvm_irq_level *irq);
 void kvm_timer_vcpu_init(struct kvm_vcpu *vcpu);
 void kvm_timer_flush_hwstate(struct kvm_vcpu *vcpu);
 void kvm_timer_sync_hwstate(struct kvm_vcpu *vcpu);
@@ -76,7 +78,14 @@ static inline int kvm_timer_init(struct kvm *kvm)
 	return 0;
 }
 
+int kvm_timer_vcpu_reset(struct kvm_vcpu *vcpu, 
+			 const struct kvm_irq_level *irq)
+{
+	return 0;
+}
+
 static inline void kvm_timer_vcpu_init(struct kvm_vcpu *vcpu) {}
+
 static inline void kvm_timer_flush_hwstate(struct kvm_vcpu *vcpu) {}
 static inline void kvm_timer_sync_hwstate(struct kvm_vcpu *vcpu) {}
 static inline void kvm_timer_vcpu_terminate(struct kvm_vcpu *vcpu) {}
diff --git a/arch/arm/kvm/arch_timer.c b/arch/arm/kvm/arch_timer.c
index 49a7516..c07b63c 100644
--- a/arch/arm/kvm/arch_timer.c
+++ b/arch/arm/kvm/arch_timer.c
@@ -30,7 +30,7 @@
 
 static struct timecounter *timecounter;
 static struct workqueue_struct *wqueue;
-static struct kvm_irq_level timer_irq = {
+static struct kvm_irq_level host_timer_irq = {
 	.level	= 1,
 };
 
@@ -67,8 +67,8 @@ static void kvm_timer_inject_irq(struct kvm_vcpu *vcpu)
 
 	timer->cntv_ctl |= ARCH_TIMER_CTRL_IT_MASK;
 	kvm_vgic_inject_irq(vcpu->kvm, vcpu->vcpu_id,
-			    vcpu->arch.timer_cpu.irq->irq,
-			    vcpu->arch.timer_cpu.irq->level);
+			    timer->irq->irq,
+			    timer->irq->level);
 }
 
 static irqreturn_t kvm_arch_timer_handler(int irq, void *dev_id)
@@ -156,6 +156,27 @@ void kvm_timer_sync_hwstate(struct kvm_vcpu *vcpu)
 	timer_arm(timer, ns);
 }
 
+int kvm_timer_vcpu_reset(struct kvm_vcpu *vcpu, 
+			 const struct kvm_irq_level *irq)
+{
+	struct arch_timer_cpu *timer = &vcpu->arch.timer_cpu;
+
+	/*
+	 * The vcpu timer irq number cannot be determined in 
+	 * kvm_timer_vcpu_init() because it is called much before
+	 * kvm_vcpu_set_target(). To handle this, we determine
+	 * vcpu timer irq number when the vcpu is resetted.
+	 */
+	timer->irq = irq;
+
+	/*
+	 * Make sure timer is disarmed.
+	 */
+	timer_disarm(timer);
+
+	return 0;
+}
+
 void kvm_timer_vcpu_init(struct kvm_vcpu *vcpu)
 {
 	struct arch_timer_cpu *timer = &vcpu->arch.timer_cpu;
@@ -163,12 +184,12 @@ void kvm_timer_vcpu_init(struct kvm_vcpu *vcpu)
 	INIT_WORK(&timer->expired, kvm_timer_inject_irq_work);
 	hrtimer_init(&timer->timer, CLOCK_MONOTONIC, HRTIMER_MODE_ABS);
 	timer->timer.function = kvm_timer_expire;
-	timer->irq = &timer_irq;
+	timer->irq = NULL;
 }
 
 static void kvm_timer_init_interrupt(void *info)
 {
-	enable_percpu_irq(timer_irq.irq, 0);
+	enable_percpu_irq(host_timer_irq.irq, 0);
 }
 
 
@@ -182,7 +203,7 @@ static int kvm_timer_cpu_notify(struct notifier_block *self,
 		break;
 	case CPU_DYING:
 	case CPU_DYING_FROZEN:
-		disable_percpu_irq(timer_irq.irq);
+		disable_percpu_irq(host_timer_irq.irq);
 		break;
 	}
 
@@ -230,7 +251,7 @@ int kvm_timer_hyp_init(void)
 		goto out;
 	}
 
-	timer_irq.irq = ppi;
+	host_timer_irq.irq = ppi;
 
 	err = register_cpu_notifier(&kvm_timer_cpu_nb);
 	if (err) {
diff --git a/arch/arm/kvm/reset.c b/arch/arm/kvm/reset.c
index b80256b..148397e 100644
--- a/arch/arm/kvm/reset.c
+++ b/arch/arm/kvm/reset.c
@@ -26,6 +26,7 @@
 #include <asm/cputype.h>
 #include <asm/kvm_arm.h>
 #include <asm/kvm_coproc.h>
+#include <asm/kvm_arch_timer.h>
 
 /******************************************************************************
  * Cortex-A15 Reset Values
@@ -37,6 +38,11 @@ static struct kvm_regs a15_regs_reset = {
 	.usr_regs.ARM_cpsr = SVC_MODE | PSR_A_BIT | PSR_I_BIT | PSR_F_BIT,
 };
 
+static struct kvm_irq_level a15_timer_irq = {
+	.irq = 27,
+	.level = 1,
+};
+
 
 /*******************************************************************************
  * Exported reset function
@@ -52,6 +58,7 @@ static struct kvm_regs a15_regs_reset = {
 int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
 {
 	struct kvm_regs *cpu_reset;
+	const struct kvm_irq_level *cpu_irq;
 
 	switch (vcpu->arch.target) {
 	case KVM_ARM_TARGET_CORTEX_A15:
@@ -59,6 +66,7 @@ int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
 			return -EINVAL;
 		cpu_reset = &a15_regs_reset;
 		vcpu->arch.midr = read_cpuid_id();
+		cpu_irq = &a15_timer_irq;
 		break;
 	default:
 		return -ENODEV;
@@ -70,5 +78,6 @@ int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
 	/* Reset CP15 registers */
 	kvm_reset_coprocs(vcpu);
 
-	return 0;
+	/* Reset arch_timer context */
+	return kvm_timer_vcpu_reset(vcpu, cpu_irq);
 }
-- 
1.7.9.5



From anup.patel at linaro.org  Sat Apr 27 04:09:55 2013
From: anup.patel at linaro.org (Anup Patel)
Date: Sat, 27 Apr 2013 13:39:55 +0530
Subject: [PATCH] arm64: KVM: Reset arch_timer upon vcpu reset
Message-ID: <1367050195-2953-1-git-send-email-anup.patel@linaro.org>

This patch does arch_timer reset (i.e. kvm_timer_vcpu_reset()) when a vcpu resetted by kvm_reset_vcpu().

The kvm_reset_vcpu() also informs guest timer irq number to arch_timer code via kvm_timer_vcpu_reset().

Signed-off-by: Anup Patel <anup.patel at linaro.org>
Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar at linaro.org>
---
 arch/arm64/include/asm/kvm_arch_timer.h |    2 ++
 arch/arm64/kvm/reset.c                  |   11 ++++++++++-
 2 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/include/asm/kvm_arch_timer.h b/arch/arm64/include/asm/kvm_arch_timer.h
index eb02273..04949c6 100644
--- a/arch/arm64/include/asm/kvm_arch_timer.h
+++ b/arch/arm64/include/asm/kvm_arch_timer.h
@@ -50,6 +50,8 @@ struct arch_timer_cpu {
 
 int kvm_timer_hyp_init(void);
 int kvm_timer_init(struct kvm *kvm);
+int kvm_timer_vcpu_reset(struct kvm_vcpu *vcpu, 
+			 const struct kvm_irq_level *irq);
 void kvm_timer_vcpu_init(struct kvm_vcpu *vcpu);
 void kvm_timer_flush_hwstate(struct kvm_vcpu *vcpu);
 void kvm_timer_sync_hwstate(struct kvm_vcpu *vcpu);
diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
index 64e0740..1e255a3 100644
--- a/arch/arm64/kvm/reset.c
+++ b/arch/arm64/kvm/reset.c
@@ -27,6 +27,7 @@
 #include <asm/ptrace.h>
 #include <asm/kvm_arm.h>
 #include <asm/kvm_coproc.h>
+#include <asm/kvm_arch_timer.h>
 
 /*
  * ARMv8 Reset Values
@@ -40,6 +41,11 @@ static struct kvm_regs default_regs_reset32 = {
 			COMPAT_PSR_I_BIT | COMPAT_PSR_F_BIT),
 };
 
+static struct kvm_irq_level default_timer_irq = {
+	.irq = 27,
+	.level = 1,
+};
+
 static bool cpu_has_32bit_el1(void)
 {
 	u64 pfr0;
@@ -75,6 +81,7 @@ int kvm_arch_dev_ioctl_check_extension(long ext)
 int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
 {
 	struct kvm_regs *cpu_reset;
+	const struct kvm_irq_level *cpu_irq;
 
 	switch (vcpu->arch.target) {
 	default:
@@ -86,6 +93,7 @@ int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
 		} else {
 			cpu_reset = &default_regs_reset;
 		}
+		cpu_irq = &default_timer_irq;
 		break;
 	}
 
@@ -95,5 +103,6 @@ int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
 	/* Reset system registers */
 	kvm_reset_sys_regs(vcpu);
 
-	return 0;
+	/* Reset arch_timer context */
+	return kvm_timer_vcpu_reset(vcpu, cpu_irq);
 }
-- 
1.7.9.5



From romieu at fr.zoreil.com  Sat Apr 27 04:53:06 2013
From: romieu at fr.zoreil.com (Francois Romieu)
Date: Sat, 27 Apr 2013 10:53:06 +0200
Subject: VIA velocity network driver
In-Reply-To: <517B6267.4070404@prisktech.co.nz>
References: <517B6267.4070404@prisktech.co.nz>
Message-ID: <20130427085306.GA24622@electric-eye.fr.zoreil.com>

Tony Prisk <linux at prisktech.co.nz> :
> I would like to add support to this driver for platform devices as
> found on VIA's APC8750 board. At the moment, I have a standalone
> platform version that works fine, but wanted to ask a few questions
> before sending a patch to merge this code into one driver.
> 
> The current driver is for PCI network cards, and uses pci dma
> functions. Most of the pci dma functions are wrappers around other
> functions which is what I have used for the platform version.

[...]
> Is it ok to use the non-pci versions (which are basically just the
> unwrapped pci versions) and pass the struct device *, or will I need
> to use the correct function for the correct instance.

It's ok.

A standalone patch to convert the pci dma functions and check the
returned status code of the new one would be welcome regardless of
any future change in the driver data struct.

[...]
> I assume this is loading something from an EEPROM, but there is no
> EEPROM on the APC8750. Removing this code, the driver seems to work
> fine on the APC8750.

I feel a "no documentation" disturbance in the force.

Via's people Cced.

> Could it be avoided with a vptr->has_no_eeprom that defaults to 0 to
> avoid breaking existing support?

Yes. No unnecessary module option please.

-- 
Ueimor


From marc.zyngier at arm.com  Sat Apr 27 05:19:45 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Sat, 27 Apr 2013 11:19:45 +0200
Subject: [PATCH] ARM: KVM: Allow host virt timer irq to be different from
 guest timer virt irq
In-Reply-To: <1367050086-2902-1-git-send-email-anup.patel@linaro.org>
References: <1367050086-2902-1-git-send-email-anup.patel@linaro.org>
Message-ID: <73b473edb8a9ea9a09f1df68345903d7@localhost>

On Sat, 27 Apr 2013 13:38:06 +0530, Anup Patel <anup.patel at linaro.org>
wrote:
> The arch_timer irq numbers (or PPI numbers) are implementation dependent
> so, the host virtual timer irq number can be different from guest
virtual
> timer irq number.
> 
> This patch ensures that host virtual timer irq number is read from DTB
and
> guest virtual timer irq is determined based on vcpu target type.

Christoffer already commented on the width of your commit message.
It doesn't show here as my stupid email client reformats it aumatically,
but you may want to check in the archive:

https://lists.cs.columbia.edu/pipermail/kvmarm/2013-April/005616.html

Please make sure you insert newlines around position 70. Or use a half
decent editor.

> Signed-off-by: Anup Patel <anup.patel at linaro.org>
> Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar at linaro.org>
> ---
>  arch/arm/include/asm/kvm_arch_timer.h |    9 +++++++++
>  arch/arm/kvm/arch_timer.c             |   35
>  ++++++++++++++++++++++++++-------
>  arch/arm/kvm/reset.c                  |   11 ++++++++++-
>  3 files changed, 47 insertions(+), 8 deletions(-)
> 
> diff --git a/arch/arm/include/asm/kvm_arch_timer.h
> b/arch/arm/include/asm/kvm_arch_timer.h
> index 68cb9e1..51b0316 100644
> --- a/arch/arm/include/asm/kvm_arch_timer.h
> +++ b/arch/arm/include/asm/kvm_arch_timer.h
> @@ -61,6 +61,8 @@ struct arch_timer_cpu {
>  #ifdef CONFIG_KVM_ARM_TIMER
>  int kvm_timer_hyp_init(void);
>  int kvm_timer_init(struct kvm *kvm);
> +int kvm_timer_vcpu_reset(struct kvm_vcpu *vcpu, 
> +			 const struct kvm_irq_level *irq);
>  void kvm_timer_vcpu_init(struct kvm_vcpu *vcpu);
>  void kvm_timer_flush_hwstate(struct kvm_vcpu *vcpu);
>  void kvm_timer_sync_hwstate(struct kvm_vcpu *vcpu);
> @@ -76,7 +78,14 @@ static inline int kvm_timer_init(struct kvm *kvm)
>  	return 0;
>  }
>  
> +int kvm_timer_vcpu_reset(struct kvm_vcpu *vcpu, 
> +			 const struct kvm_irq_level *irq)

static inline, please. This is an include file...

> +{
> +	return 0;
> +}
> +
>  static inline void kvm_timer_vcpu_init(struct kvm_vcpu *vcpu) {}
> +
>  static inline void kvm_timer_flush_hwstate(struct kvm_vcpu *vcpu) {}
>  static inline void kvm_timer_sync_hwstate(struct kvm_vcpu *vcpu) {}
>  static inline void kvm_timer_vcpu_terminate(struct kvm_vcpu *vcpu) {}
> diff --git a/arch/arm/kvm/arch_timer.c b/arch/arm/kvm/arch_timer.c
> index 49a7516..c07b63c 100644
> --- a/arch/arm/kvm/arch_timer.c
> +++ b/arch/arm/kvm/arch_timer.c
> @@ -30,7 +30,7 @@
>  
>  static struct timecounter *timecounter;
>  static struct workqueue_struct *wqueue;
> -static struct kvm_irq_level timer_irq = {
> +static struct kvm_irq_level host_timer_irq = {
>  	.level	= 1,
>  };
>  
> @@ -67,8 +67,8 @@ static void kvm_timer_inject_irq(struct kvm_vcpu
*vcpu)
>  
>  	timer->cntv_ctl |= ARCH_TIMER_CTRL_IT_MASK;
>  	kvm_vgic_inject_irq(vcpu->kvm, vcpu->vcpu_id,
> -			    vcpu->arch.timer_cpu.irq->irq,
> -			    vcpu->arch.timer_cpu.irq->level);
> +			    timer->irq->irq,
> +			    timer->irq->level);
>  }
>  
>  static irqreturn_t kvm_arch_timer_handler(int irq, void *dev_id)
> @@ -156,6 +156,27 @@ void kvm_timer_sync_hwstate(struct kvm_vcpu *vcpu)
>  	timer_arm(timer, ns);
>  }
>  
> +int kvm_timer_vcpu_reset(struct kvm_vcpu *vcpu, 
> +			 const struct kvm_irq_level *irq)
> +{
> +	struct arch_timer_cpu *timer = &vcpu->arch.timer_cpu;
> +
> +	/*
> +	 * The vcpu timer irq number cannot be determined in 
> +	 * kvm_timer_vcpu_init() because it is called much before
> +	 * kvm_vcpu_set_target(). To handle this, we determine
> +	 * vcpu timer irq number when the vcpu is resetted.
> +	 */
> +	timer->irq = irq;
> +
> +	/*
> +	 * Make sure timer is disarmed.
> +	 */
> +	timer_disarm(timer);

What is that for? Timer has not been started yet, for the lack of an IRQ.
Actually, the vcpu has never ran. Why would you need to disarm it?

> +	return 0;

If this function has no failure case, it can return void.

> +}
> +
>  void kvm_timer_vcpu_init(struct kvm_vcpu *vcpu)
>  {
>  	struct arch_timer_cpu *timer = &vcpu->arch.timer_cpu;
> @@ -163,12 +184,12 @@ void kvm_timer_vcpu_init(struct kvm_vcpu *vcpu)
>  	INIT_WORK(&timer->expired, kvm_timer_inject_irq_work);
>  	hrtimer_init(&timer->timer, CLOCK_MONOTONIC, HRTIMER_MODE_ABS);
>  	timer->timer.function = kvm_timer_expire;
> -	timer->irq = &timer_irq;
> +	timer->irq = NULL;

How useful is that? The vcpu has been kzalloc-ed anyway. Is there any case
where this makes sense?

>  }
>  
>  static void kvm_timer_init_interrupt(void *info)
>  {
> -	enable_percpu_irq(timer_irq.irq, 0);
> +	enable_percpu_irq(host_timer_irq.irq, 0);
>  }
>  
>  
> @@ -182,7 +203,7 @@ static int kvm_timer_cpu_notify(struct
notifier_block
> *self,
>  		break;
>  	case CPU_DYING:
>  	case CPU_DYING_FROZEN:
> -		disable_percpu_irq(timer_irq.irq);
> +		disable_percpu_irq(host_timer_irq.irq);
>  		break;
>  	}
>  
> @@ -230,7 +251,7 @@ int kvm_timer_hyp_init(void)
>  		goto out;
>  	}
>  
> -	timer_irq.irq = ppi;
> +	host_timer_irq.irq = ppi;
>  
>  	err = register_cpu_notifier(&kvm_timer_cpu_nb);
>  	if (err) {
> diff --git a/arch/arm/kvm/reset.c b/arch/arm/kvm/reset.c
> index b80256b..148397e 100644
> --- a/arch/arm/kvm/reset.c
> +++ b/arch/arm/kvm/reset.c
> @@ -26,6 +26,7 @@
>  #include <asm/cputype.h>
>  #include <asm/kvm_arm.h>
>  #include <asm/kvm_coproc.h>
> +#include <asm/kvm_arch_timer.h>
>  
> 
/******************************************************************************
>   * Cortex-A15 Reset Values
> @@ -37,6 +38,11 @@ static struct kvm_regs a15_regs_reset = {
>  	.usr_regs.ARM_cpsr = SVC_MODE | PSR_A_BIT | PSR_I_BIT | PSR_F_BIT,
>  };
>  
> +static struct kvm_irq_level a15_timer_irq = {

Please make this static const.

> +	.irq = 27,
> +	.level = 1,
> +};
> +
>  
> 
/*******************************************************************************
>   * Exported reset function
> @@ -52,6 +58,7 @@ static struct kvm_regs a15_regs_reset = {
>  int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
>  {
>  	struct kvm_regs *cpu_reset;
> +	const struct kvm_irq_level *cpu_irq;
>  
>  	switch (vcpu->arch.target) {
>  	case KVM_ARM_TARGET_CORTEX_A15:
> @@ -59,6 +66,7 @@ int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
>  			return -EINVAL;
>  		cpu_reset = &a15_regs_reset;
>  		vcpu->arch.midr = read_cpuid_id();
> +		cpu_irq = &a15_timer_irq;
>  		break;
>  	default:
>  		return -ENODEV;
> @@ -70,5 +78,6 @@ int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
>  	/* Reset CP15 registers */
>  	kvm_reset_coprocs(vcpu);
>  
> -	return 0;
> +	/* Reset arch_timer context */
> +	return kvm_timer_vcpu_reset(vcpu, cpu_irq);
>  }

Some of the above comments also apply to the arm64 you sent.

Thanks,

        M.
-- 
Fast, cheap, reliable. Pick two.


From anup at brainfault.org  Sat Apr 27 08:19:31 2013
From: anup at brainfault.org (Anup Patel)
Date: Sat, 27 Apr 2013 17:49:31 +0530
Subject: [PATCH] ARM: KVM: Allow host virt timer irq to be different from
 guest timer virt irq
In-Reply-To: <73b473edb8a9ea9a09f1df68345903d7@localhost>
References: <1367050086-2902-1-git-send-email-anup.patel@linaro.org>
 <73b473edb8a9ea9a09f1df68345903d7@localhost>
Message-ID: <CAAhSdy101B=4cK9nnLtQa7rG15D0CT_DsWD6k3FZ1EYz2nAfEw@mail.gmail.com>

On Sat, Apr 27, 2013 at 2:49 PM, Marc Zyngier <marc.zyngier at arm.com> wrote:
> On Sat, 27 Apr 2013 13:38:06 +0530, Anup Patel <anup.patel at linaro.org>
> wrote:
>> The arch_timer irq numbers (or PPI numbers) are implementation dependent
>> so, the host virtual timer irq number can be different from guest
> virtual
>> timer irq number.
>>
>> This patch ensures that host virtual timer irq number is read from DTB
> and
>> guest virtual timer irq is determined based on vcpu target type.
>
> Christoffer already commented on the width of your commit message.
> It doesn't show here as my stupid email client reformats it aumatically,
> but you may want to check in the archive:
>
> https://lists.cs.columbia.edu/pipermail/kvmarm/2013-April/005616.html
>
> Please make sure you insert newlines around position 70. Or use a half
> decent editor.

Ok, will do.

>
>> Signed-off-by: Anup Patel <anup.patel at linaro.org>
>> Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar at linaro.org>
>> ---
>>  arch/arm/include/asm/kvm_arch_timer.h |    9 +++++++++
>>  arch/arm/kvm/arch_timer.c             |   35
>>  ++++++++++++++++++++++++++-------
>>  arch/arm/kvm/reset.c                  |   11 ++++++++++-
>>  3 files changed, 47 insertions(+), 8 deletions(-)
>>
>> diff --git a/arch/arm/include/asm/kvm_arch_timer.h
>> b/arch/arm/include/asm/kvm_arch_timer.h
>> index 68cb9e1..51b0316 100644
>> --- a/arch/arm/include/asm/kvm_arch_timer.h
>> +++ b/arch/arm/include/asm/kvm_arch_timer.h
>> @@ -61,6 +61,8 @@ struct arch_timer_cpu {
>>  #ifdef CONFIG_KVM_ARM_TIMER
>>  int kvm_timer_hyp_init(void);
>>  int kvm_timer_init(struct kvm *kvm);
>> +int kvm_timer_vcpu_reset(struct kvm_vcpu *vcpu,
>> +                      const struct kvm_irq_level *irq);
>>  void kvm_timer_vcpu_init(struct kvm_vcpu *vcpu);
>>  void kvm_timer_flush_hwstate(struct kvm_vcpu *vcpu);
>>  void kvm_timer_sync_hwstate(struct kvm_vcpu *vcpu);
>> @@ -76,7 +78,14 @@ static inline int kvm_timer_init(struct kvm *kvm)
>>       return 0;
>>  }
>>
>> +int kvm_timer_vcpu_reset(struct kvm_vcpu *vcpu,
>> +                      const struct kvm_irq_level *irq)
>
> static inline, please. This is an include file...

This one is accidental. I had it static inlined.

>
>> +{
>> +     return 0;
>> +}
>> +
>>  static inline void kvm_timer_vcpu_init(struct kvm_vcpu *vcpu) {}
>> +
>>  static inline void kvm_timer_flush_hwstate(struct kvm_vcpu *vcpu) {}
>>  static inline void kvm_timer_sync_hwstate(struct kvm_vcpu *vcpu) {}
>>  static inline void kvm_timer_vcpu_terminate(struct kvm_vcpu *vcpu) {}
>> diff --git a/arch/arm/kvm/arch_timer.c b/arch/arm/kvm/arch_timer.c
>> index 49a7516..c07b63c 100644
>> --- a/arch/arm/kvm/arch_timer.c
>> +++ b/arch/arm/kvm/arch_timer.c
>> @@ -30,7 +30,7 @@
>>
>>  static struct timecounter *timecounter;
>>  static struct workqueue_struct *wqueue;
>> -static struct kvm_irq_level timer_irq = {
>> +static struct kvm_irq_level host_timer_irq = {
>>       .level  = 1,
>>  };
>>
>> @@ -67,8 +67,8 @@ static void kvm_timer_inject_irq(struct kvm_vcpu
> *vcpu)
>>
>>       timer->cntv_ctl |= ARCH_TIMER_CTRL_IT_MASK;
>>       kvm_vgic_inject_irq(vcpu->kvm, vcpu->vcpu_id,
>> -                         vcpu->arch.timer_cpu.irq->irq,
>> -                         vcpu->arch.timer_cpu.irq->level);
>> +                         timer->irq->irq,
>> +                         timer->irq->level);
>>  }
>>
>>  static irqreturn_t kvm_arch_timer_handler(int irq, void *dev_id)
>> @@ -156,6 +156,27 @@ void kvm_timer_sync_hwstate(struct kvm_vcpu *vcpu)
>>       timer_arm(timer, ns);
>>  }
>>
>> +int kvm_timer_vcpu_reset(struct kvm_vcpu *vcpu,
>> +                      const struct kvm_irq_level *irq)
>> +{
>> +     struct arch_timer_cpu *timer = &vcpu->arch.timer_cpu;
>> +
>> +     /*
>> +      * The vcpu timer irq number cannot be determined in
>> +      * kvm_timer_vcpu_init() because it is called much before
>> +      * kvm_vcpu_set_target(). To handle this, we determine
>> +      * vcpu timer irq number when the vcpu is resetted.
>> +      */
>> +     timer->irq = irq;
>> +
>> +     /*
>> +      * Make sure timer is disarmed.
>> +      */
>> +     timer_disarm(timer);
>
> What is that for? Timer has not been started yet, for the lack of an IRQ.
> Actually, the vcpu has never ran. Why would you need to disarm it?

This is in case a vcpu is resetted  at runtime from user space or psci.
Also, since we have named it timer_vcpu_reset(), it made sense to
atleast disarm the timer.

>
>> +     return 0;
>
> If this function has no failure case, it can return void.

Ok, will make it return void.

>
>> +}
>> +
>>  void kvm_timer_vcpu_init(struct kvm_vcpu *vcpu)
>>  {
>>       struct arch_timer_cpu *timer = &vcpu->arch.timer_cpu;
>> @@ -163,12 +184,12 @@ void kvm_timer_vcpu_init(struct kvm_vcpu *vcpu)
>>       INIT_WORK(&timer->expired, kvm_timer_inject_irq_work);
>>       hrtimer_init(&timer->timer, CLOCK_MONOTONIC, HRTIMER_MODE_ABS);
>>       timer->timer.function = kvm_timer_expire;
>> -     timer->irq = &timer_irq;
>> +     timer->irq = NULL;
>
> How useful is that? The vcpu has been kzalloc-ed anyway. Is there any case
> where this makes sense?

Ok, will remove this.

>
>>  }
>>
>>  static void kvm_timer_init_interrupt(void *info)
>>  {
>> -     enable_percpu_irq(timer_irq.irq, 0);
>> +     enable_percpu_irq(host_timer_irq.irq, 0);
>>  }
>>
>>
>> @@ -182,7 +203,7 @@ static int kvm_timer_cpu_notify(struct
> notifier_block
>> *self,
>>               break;
>>       case CPU_DYING:
>>       case CPU_DYING_FROZEN:
>> -             disable_percpu_irq(timer_irq.irq);
>> +             disable_percpu_irq(host_timer_irq.irq);
>>               break;
>>       }
>>
>> @@ -230,7 +251,7 @@ int kvm_timer_hyp_init(void)
>>               goto out;
>>       }
>>
>> -     timer_irq.irq = ppi;
>> +     host_timer_irq.irq = ppi;
>>
>>       err = register_cpu_notifier(&kvm_timer_cpu_nb);
>>       if (err) {
>> diff --git a/arch/arm/kvm/reset.c b/arch/arm/kvm/reset.c
>> index b80256b..148397e 100644
>> --- a/arch/arm/kvm/reset.c
>> +++ b/arch/arm/kvm/reset.c
>> @@ -26,6 +26,7 @@
>>  #include <asm/cputype.h>
>>  #include <asm/kvm_arm.h>
>>  #include <asm/kvm_coproc.h>
>> +#include <asm/kvm_arch_timer.h>
>>
>>
> /******************************************************************************
>>   * Cortex-A15 Reset Values
>> @@ -37,6 +38,11 @@ static struct kvm_regs a15_regs_reset = {
>>       .usr_regs.ARM_cpsr = SVC_MODE | PSR_A_BIT | PSR_I_BIT | PSR_F_BIT,
>>  };
>>
>> +static struct kvm_irq_level a15_timer_irq = {
>
> Please make this static const.

Ok, will make it static const.

>
>> +     .irq = 27,
>> +     .level = 1,
>> +};
>> +
>>
>>
> /*******************************************************************************
>>   * Exported reset function
>> @@ -52,6 +58,7 @@ static struct kvm_regs a15_regs_reset = {
>>  int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
>>  {
>>       struct kvm_regs *cpu_reset;
>> +     const struct kvm_irq_level *cpu_irq;
>>
>>       switch (vcpu->arch.target) {
>>       case KVM_ARM_TARGET_CORTEX_A15:
>> @@ -59,6 +66,7 @@ int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
>>                       return -EINVAL;
>>               cpu_reset = &a15_regs_reset;
>>               vcpu->arch.midr = read_cpuid_id();
>> +             cpu_irq = &a15_timer_irq;
>>               break;
>>       default:
>>               return -ENODEV;
>> @@ -70,5 +78,6 @@ int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
>>       /* Reset CP15 registers */
>>       kvm_reset_coprocs(vcpu);
>>
>> -     return 0;
>> +     /* Reset arch_timer context */
>> +     return kvm_timer_vcpu_reset(vcpu, cpu_irq);
>>  }
>
> Some of the above comments also apply to the arm64 you sent.

Sure, I will update that patch too.

>
> Thanks,
>
>         M.
> --
> Fast, cheap, reliable. Pick two.
> _______________________________________________
> kvmarm mailing list
> kvmarm at lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm

--Anup


From simon.guinot at sequanux.org  Sat Apr 27 10:03:31 2013
From: simon.guinot at sequanux.org (Simon Guinot)
Date: Sat, 27 Apr 2013 16:03:31 +0200
Subject: [PATCHv1 1/3] hwmon: Add support for GMT G762/G763 PWM fan
 controller
In-Reply-To: <63961d39aee9db94767f28fd441312bec2029473.1366753420.git.arno@natisbad.org>
References: <cover.1366753420.git.arno@natisbad.org>
 <63961d39aee9db94767f28fd441312bec2029473.1366753420.git.arno@natisbad.org>
Message-ID: <20130427140331.GL17771@kw.sim.vm.gnt>

On Wed, Apr 24, 2013 at 12:05:56AM +0200, Arnaud Ebalard wrote:
> +	/*
> +	 * Set default configuration values before passing the structure
> +	 * to OF helpers to overload them using those provided by .dts
> +	 * file (if any). Final config is then commited.
> +	 */
> +	g762_config_init(&conf);
> +	g762_config_of_overload(client, &conf);
> +	err = g762_config_commit(client, &conf);
> +	if (err)
> +		goto out;

One more comment... Sorry for the multiple replies :)

I am not sure that applying a configuration anyway is a good idea.
I think it could be best to stick with the bootloader configuration if
no platform data nor device tree data are given.

Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130427/d3d421c7/attachment.sig>

From khali at linux-fr.org  Sat Apr 27 10:12:04 2013
From: khali at linux-fr.org (Jean Delvare)
Date: Sat, 27 Apr 2013 16:12:04 +0200
Subject: [PATCHv1 1/3] hwmon: Add support for GMT G762/G763 PWM fan 
 controller
In-Reply-To: <20130427140331.GL17771@kw.sim.vm.gnt>
References: <cover.1366753420.git.arno@natisbad.org>
 <63961d39aee9db94767f28fd441312bec2029473.1366753420.git.arno@natisbad.org>
 <20130427140331.GL17771@kw.sim.vm.gnt>
Message-ID: <20130427161204.3957686c@endymion.delvare>

On Sat, 27 Apr 2013 16:03:31 +0200, Simon Guinot wrote:
> On Wed, Apr 24, 2013 at 12:05:56AM +0200, Arnaud Ebalard wrote:
> > +	/*
> > +	 * Set default configuration values before passing the structure
> > +	 * to OF helpers to overload them using those provided by .dts
> > +	 * file (if any). Final config is then commited.
> > +	 */
> > +	g762_config_init(&conf);
> > +	g762_config_of_overload(client, &conf);
> > +	err = g762_config_commit(client, &conf);
> > +	if (err)
> > +		goto out;
> 
> One more comment... Sorry for the multiple replies :)
> 
> I am not sure that applying a configuration anyway is a good idea.
> I think it could be best to stick with the bootloader configuration if
> no platform data nor device tree data are given.

FWIW, the common policy for hwmon drivers is actually to not change the
device configuration unless they really have to.

-- 
Jean Delvare


From stefano.stabellini at eu.citrix.com  Sat Apr 27 10:35:39 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Sat, 27 Apr 2013 15:35:39 +0100
Subject: [PATCH -next] xen/arm: remove duplicated include from enlighten.c
In-Reply-To: <CAPgLHd95AtzEDXUMHryWmmVAkBfkh42hgeLKdSLFYwkO_JB-ZA@mail.gmail.com>
References: <CAPgLHd95AtzEDXUMHryWmmVAkBfkh42hgeLKdSLFYwkO_JB-ZA@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1304271535210.4180@kaball.uk.xensource.com>

On Sat, 27 Apr 2013, Wei Yongjun wrote:
> From: Wei Yongjun <yongjun_wei at trendmicro.com.cn>
> 
> Remove duplicated include.
> 
> Signed-off-by: Wei Yongjun <yongjun_wei at trendmicro.com.cn>

Acked-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>


>  arch/arm/xen/enlighten.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> index 9a0a917..d30042e 100644
> --- a/arch/arm/xen/enlighten.c
> +++ b/arch/arm/xen/enlighten.c
> @@ -10,7 +10,6 @@
>  #include <xen/platform_pci.h>
>  #include <xen/xenbus.h>
>  #include <xen/page.h>
> -#include <xen/xen.h>
>  #include <xen/interface/sched.h>
>  #include <xen/xen-ops.h>
>  #include <asm/xen/hypervisor.h>
> 


From catalin.marinas at arm.com  Sat Apr 27 11:21:09 2013
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Sat, 27 Apr 2013 16:21:09 +0100
Subject: [PATCH v4 5/7] ARM: KVM: rework HYP page table freeing
In-Reply-To: <CAEDV+gKZezvHtRAySvGpOgTsPPtwUEYo9v086U=Hz4QPZXGVSg@mail.gmail.com>
References: <1365790327-2138-1-git-send-email-marc.zyngier@arm.com>
 <1365790327-2138-6-git-send-email-marc.zyngier@arm.com>
 <20130426110558.GE5007@localhost.cambridge.arm.com> <517AAF3F.20500@arm.com>
 <CAEDV+gKZezvHtRAySvGpOgTsPPtwUEYo9v086U=Hz4QPZXGVSg@mail.gmail.com>
Message-ID: <1DF9CE3B-C034-483E-BAF1-92E11D6F112F@arm.com>

On 26 Apr 2013, at 22:07, "Christoffer Dall" <cdall at cs.columbia.edu> wrote:

> On Fri, Apr 26, 2013 at 9:45 AM, Marc Zyngier <marc.zyngier at arm.com> wrote:
>> On 26/04/13 12:05, Catalin Marinas wrote:
>>> On Fri, Apr 12, 2013 at 07:12:05PM +0100, Marc Zyngier wrote:
>>>> diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
>>>> index bfc5927..7464824 100644
>>>> --- a/arch/arm/kvm/mmu.c
>>>> +++ b/arch/arm/kvm/mmu.c
>>> ...
>>>> +static void clear_pmd_entry(pmd_t *pmd)
>>>> +{
>>>> +    pte_t *pte_table = pte_offset_kernel(pmd, 0);
>>>> +    pmd_clear(pmd);
>>>> +    pte_free_kernel(NULL, pte_table);
>>>> +    put_page(virt_to_page(pmd));
>>>> +}
>>> ...
>>>> static void unmap_stage2_range(struct kvm *kvm, phys_addr_t start, u64 size)
>>> 
>>> Is there a chance that this function (or the other unmapping function
>>> for Hyp pages) is called on an active stage 2 table (VTTBR pointing to
>>> this pgd)? If yes, than you probably have to follow the mmu_gather
>>> mechanism of freeing page table pages to avoid speculative loads.
>>> Basically flushing the TLB between pmd_clear and pte_free_kernel.
>> 
>> Blah. You're right, we got it wrong.
>> 
>> We need to move our TLB invalidation out of kvm_unmap_hva_handler, and
>> put it in clear_pmd_entry. I'll cook a patch.
>> 
>> Thanks for reviewing.
> Ah, because clean_pmd_entry doesn't  flush stage2 TLB, that's the issue?

Yes. After clearing a pmd entry you need to flush the stage 2
TLB before freeing the pte page it was pointing to. Otherwise
you can get other CPUs loading the TLB with invalid data
(either because of intermediate level caching in the TLB or
simply because they haven't observed the actual pmd
clearing). 

Catalin

From arnd at arndb.de  Sat Apr 27 11:33:54 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Sat, 27 Apr 2013 17:33:54 +0200
Subject: [PATCH] media: coda: Fix compile breakage
In-Reply-To: <1367039198-28639-1-git-send-email-shc_work@mail.ru>
References: <1367039198-28639-1-git-send-email-shc_work@mail.ru>
Message-ID: <201304271733.54301.arnd@arndb.de>

On Saturday 27 April 2013, Alexander Shiyan wrote:
> Patch adds GENERIC_ALLOCATOR, if "coda" is selected.
> 
> drivers/built-in.o: In function `coda_remove':
> :(.text+0x110634): undefined reference to `gen_pool_free'
> drivers/built-in.o: In function `coda_probe':
> :(.text+0x1107d4): undefined reference to `of_get_named_gen_pool'
> :(.text+0x1108b8): undefined reference to `gen_pool_alloc'
> :(.text+0x1108d0): undefined reference to `gen_pool_virt_to_phys'
> :(.text+0x110918): undefined reference to `dev_get_gen_pool'
> 
> Signed-off-by: Alexander Shiyan <shc_work at mail.ru>

Acked-by: Arnd Bergmann <arnd at arndb.de>

I noticed the problem as well, but haven't gotten around to create
a patch. Thanks for taking care of this!

	Arnd


From linux at roeck-us.net  Sat Apr 27 12:56:51 2013
From: linux at roeck-us.net (Guenter Roeck)
Date: Sat, 27 Apr 2013 09:56:51 -0700
Subject: [PATCHv1 1/3] hwmon: Add support for GMT G762/G763 PWM fan
 controller
In-Reply-To: <20130427140331.GL17771@kw.sim.vm.gnt>
References: <cover.1366753420.git.arno@natisbad.org>
 <63961d39aee9db94767f28fd441312bec2029473.1366753420.git.arno@natisbad.org>
 <20130427140331.GL17771@kw.sim.vm.gnt>
Message-ID: <20130427165650.GA26415@roeck-us.net>

On Sat, Apr 27, 2013 at 04:03:31PM +0200, Simon Guinot wrote:
> On Wed, Apr 24, 2013 at 12:05:56AM +0200, Arnaud Ebalard wrote:
> > +	/*
> > +	 * Set default configuration values before passing the structure
> > +	 * to OF helpers to overload them using those provided by .dts
> > +	 * file (if any). Final config is then commited.
> > +	 */
> > +	g762_config_init(&conf);
> > +	g762_config_of_overload(client, &conf);
> > +	err = g762_config_commit(client, &conf);
> > +	if (err)
> > +		goto out;
> 
> One more comment... Sorry for the multiple replies :)
> 
> I am not sure that applying a configuration anyway is a good idea.
> I think it could be best to stick with the bootloader configuration if
> no platform data nor device tree data are given.
> 
Yes, good point. You are absolutely right.

Guenter


From festevam at gmail.com  Sat Apr 27 13:13:50 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Sat, 27 Apr 2013 14:13:50 -0300
Subject: [PATCH] media: coda: Fix compile breakage
In-Reply-To: <201304271733.54301.arnd@arndb.de>
References: <1367039198-28639-1-git-send-email-shc_work@mail.ru>
 <201304271733.54301.arnd@arndb.de>
Message-ID: <CAOMZO5CYZoe9Z_eAWZ5Wit2o-+9hq3xWjHPF_ZLszN7bbDJrBA@mail.gmail.com>

Alexander/Arnd,

On Sat, Apr 27, 2013 at 12:33 PM, Arnd Bergmann <arnd at arndb.de> wrote:
> On Saturday 27 April 2013, Alexander Shiyan wrote:
>> Patch adds GENERIC_ALLOCATOR, if "coda" is selected.
>>
>> drivers/built-in.o: In function `coda_remove':
>> :(.text+0x110634): undefined reference to `gen_pool_free'
>> drivers/built-in.o: In function `coda_probe':
>> :(.text+0x1107d4): undefined reference to `of_get_named_gen_pool'
>> :(.text+0x1108b8): undefined reference to `gen_pool_alloc'
>> :(.text+0x1108d0): undefined reference to `gen_pool_virt_to_phys'
>> :(.text+0x110918): undefined reference to `dev_get_gen_pool'
>>
>> Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
>
> Acked-by: Arnd Bergmann <arnd at arndb.de>
>
> I noticed the problem as well, but haven't gotten around to create
> a patch. Thanks for taking care of this!

I fixed this issue in a different way:
https://patchwork.kernel.org/patch/2432841/

And Shawn has already queued it.


From jaswinder.singh at linaro.org  Sat Apr 27 14:05:53 2013
From: jaswinder.singh at linaro.org (jaswinder.singh at linaro.org)
Date: Sat, 27 Apr 2013 23:35:53 +0530
Subject: [PATCH 1/3] mailbox: rename pl320-ipc specific mailbox.h
In-Reply-To: <CAJe_ZhdH+SCs5crguXrm6y-6bu+eGnTqeJS6cOS5H5Yz=m15Cw@mail.gmail.com>
References: <CAJe_ZhdH+SCs5crguXrm6y-6bu+eGnTqeJS6cOS5H5Yz=m15Cw@mail.gmail.com>
Message-ID: <1367085953-28270-1-git-send-email-jaswinder.singh@linaro.org>

From: Suman Anna <s-anna at ti.com>

The patch 30058677 "ARM / highbank: add support for pl320 IPC"
added a pl320 IPC specific header file as a generic mailbox.h.
This file has been renamed appropriately to allow the
introduction of the generic mailbox API framework.

Signed-off-by: Suman Anna <s-anna at ti.com>
Cc: Mark Langsdorf <mark.langsdorf at calxeda.com>
Cc: Rafael J. Wysocki <rafael.j.wysocki at intel.com>
---
 drivers/cpufreq/highbank-cpufreq.c       |    2 +-
 drivers/mailbox/pl320-ipc.c              |    2 +-
 include/linux/{mailbox.h => pl320-ipc.h} |    0
 3 files changed, 2 insertions(+), 2 deletions(-)
 rename include/linux/{mailbox.h => pl320-ipc.h} (100%)

diff --git a/drivers/cpufreq/highbank-cpufreq.c b/drivers/cpufreq/highbank-cpufreq.c
index b61b5a3..3118b87 100644
--- a/drivers/cpufreq/highbank-cpufreq.c
+++ b/drivers/cpufreq/highbank-cpufreq.c
@@ -19,7 +19,7 @@
 #include <linux/cpu.h>
 #include <linux/err.h>
 #include <linux/of.h>
-#include <linux/mailbox.h>
+#include <linux/pl320-ipc.h>
 #include <linux/platform_device.h>
 
 #define HB_CPUFREQ_CHANGE_NOTE	0x80000001
diff --git a/drivers/mailbox/pl320-ipc.c b/drivers/mailbox/pl320-ipc.c
index d873cba..f3755e0 100644
--- a/drivers/mailbox/pl320-ipc.c
+++ b/drivers/mailbox/pl320-ipc.c
@@ -26,7 +26,7 @@
 #include <linux/device.h>
 #include <linux/amba/bus.h>
 
-#include <linux/mailbox.h>
+#include <linux/pl320-ipc.h>
 
 #define IPCMxSOURCE(m)		((m) * 0x40)
 #define IPCMxDSET(m)		(((m) * 0x40) + 0x004)
diff --git a/include/linux/mailbox.h b/include/linux/pl320-ipc.h
similarity index 100%
rename from include/linux/mailbox.h
rename to include/linux/pl320-ipc.h
-- 
1.7.10.4



From mturquette at linaro.org  Sat Apr 27 14:17:13 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Sat, 27 Apr 2013 11:17:13 -0700
Subject: [PATCH] clk: add option to keep boot clocks on
In-Reply-To: <1367019591-31685-1-git-send-email-olof@lixom.net>
References: <1367019591-31685-1-git-send-email-olof@lixom.net>
Message-ID: <20130427181713.8923.62611@quantum>

Quoting Olof Johansson (2013-04-26 16:39:51)
> This is primarily useful when there's a driver that doesn't claim clocks
> properly, but the bootloader does. It's not expected to be used in normal
> cases, but for bringup and debug it's very useful to have the option to
> not gate unclaimed clocks that are still on.
> 
> Signed-off-by: Olof Johansson <olof at lixom.net>
> ---
> 
> Mike, this is a pretty trivial patch that I would love to see in 3.10
> even though it's getting late. I'm definitely not picky about the naming
> of the boot option, so feel free to change it.
> 

This bike shed could be improved with a different color of paint.
Opinions below:

> 
> -Olof
> 
>  drivers/clk/clk.c | 14 ++++++++++++++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index 20ce67f..b22551e 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -499,10 +499,24 @@ out:
>         return;
>  }
>  
> +

Remove extra whitespace.

> +static bool keep_boot_clocks;
> +static int __init clk_keep_boot_clocks(char *__unused)
> +{
> +       keep_boot_clocks = true;
> +       return 1;
> +}
> +__setup("clk_keep_boot_clocks", clk_keep_boot_clocks);

s/clk_keep_boot_clocks/clk_ignore_unused/

This matches nicely with the existing CLK_IGNORE_UNUSED flag in
include/linux/clk-provider.h

In addition to Randy's suggestion to update kernel-parameters.txt,
please also toss in a note somewhere in Documentation/clk.txt so that
others bringing up new platforms can more easily find out about this
boot option.  Don't worry about making it pretty since I plan to rework
the clock documentation for 3.11.

Otherwise patch looks good to me.  I did some testing and I would be
comfortable sneaking this in for 3.10.

Regards,
Mike

> +
>  static int clk_disable_unused(void)
>  {
>         struct clk *clk;
>  
> +       if (keep_boot_clocks) {
> +               pr_warn("clk: Not disabling unused clocks\n");
> +               return 0;
> +       }
> +
>         clk_prepare_lock();
>  
>         hlist_for_each_entry(clk, &clk_root_list, child_node)
> -- 
> 1.8.1.192.gc4361b8


From arno at natisbad.org  Sat Apr 27 14:55:50 2013
From: arno at natisbad.org (Arnaud Ebalard)
Date: Sat, 27 Apr 2013 20:55:50 +0200
Subject: [PATCHv1 1/3] hwmon: Add support for GMT G762/G763 PWM fan
 controller
In-Reply-To: <20130427165650.GA26415@roeck-us.net> (Guenter Roeck's message of
 "Sat, 27 Apr 2013 09:56:51 -0700")
References: <cover.1366753420.git.arno@natisbad.org>
 <63961d39aee9db94767f28fd441312bec2029473.1366753420.git.arno@natisbad.org>
 <20130427140331.GL17771@kw.sim.vm.gnt>
 <20130427165650.GA26415@roeck-us.net>
Message-ID: <87vc77247d.fsf@natisbad.org>

Hi Guenter, Jean, Simon,

Guenter Roeck <linux at roeck-us.net> writes:

> On Sat, Apr 27, 2013 at 04:03:31PM +0200, Simon Guinot wrote:
>> On Wed, Apr 24, 2013 at 12:05:56AM +0200, Arnaud Ebalard wrote:
>> > +	/*
>> > +	 * Set default configuration values before passing the structure
>> > +	 * to OF helpers to overload them using those provided by .dts
>> > +	 * file (if any). Final config is then commited.
>> > +	 */
>> > +	g762_config_init(&conf);
>> > +	g762_config_of_overload(client, &conf);
>> > +	err = g762_config_commit(client, &conf);
>> > +	if (err)
>> > +		goto out;
>> 
>> One more comment... Sorry for the multiple replies :)
>> 
>> I am not sure that applying a configuration anyway is a good idea.
>> I think it could be best to stick with the bootloader configuration if
>> no platform data nor device tree data are given.
>> 
> Yes, good point. You are absolutely right.

Thanks you all for your feedback. I will take all your comments into
account and work on a new version. I am somewhat unavailable next week
so may not be able to push something before next week end.

Cheers,

a+


From olof at lixom.net  Sat Apr 27 16:53:37 2013
From: olof at lixom.net (Olof Johansson)
Date: Sat, 27 Apr 2013 13:53:37 -0700
Subject: [GIT PULL] ARM: arm-soc: one more patch for 3.9
Message-ID: <20130427205337.GA27352@quad.lixom.net>

Hi Linus,

The following changes since commit 73053d973dd6f56472309cffa5a5d15a62dd6f96:

  ARM: highbank: fix cache flush ordering for cpu hotplug (2013-04-18 09:37:46 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/fixes-for-linus

for you to fetch changes up to d21be237ffa357e55005e2bf9ffef10b23c184d0:

  Merge tag 'omap-for-v3.9-rc6/fixes-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into fixes (2013-04-26 17:35:21 -0700)

----------------------------------------------------------------

ARM: arm-soc fixes for 3.9

A late-arriving fix for musb on OMAP4, resolving an issue where the musb
IP won't be clocked and thus not functional. Small in scope, most of the
lines changed is a longish comment.

----------------------------------------------------------------
Kishon Vijay Abraham I (1):
      ARM: OMAP4: hwmod data: make 'ocp2scp_usb_phy_phy_48m" as the main clock

Olof Johansson (1):
      Merge tag 'omap-for-v3.9-rc6/fixes-signed' of git://git.kernel.org/.../tmlind/linux-omap into fixes

 arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 18 +++++++++++-------
 1 file changed, 11 insertions(+), 7 deletions(-)


From arnd at arndb.de  Sat Apr 27 16:55:25 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Sat, 27 Apr 2013 22:55:25 +0200
Subject: [PATCH] media: coda: Fix compile breakage
In-Reply-To: <CAOMZO5CYZoe9Z_eAWZ5Wit2o-+9hq3xWjHPF_ZLszN7bbDJrBA@mail.gmail.com>
References: <1367039198-28639-1-git-send-email-shc_work@mail.ru>
 <201304271733.54301.arnd@arndb.de>
 <CAOMZO5CYZoe9Z_eAWZ5Wit2o-+9hq3xWjHPF_ZLszN7bbDJrBA@mail.gmail.com>
Message-ID: <201304272255.25953.arnd@arndb.de>

On Saturday 27 April 2013, Fabio Estevam wrote:
> I fixed this issue in a different way:
> https://patchwork.kernel.org/patch/2432841/
> 
> And Shawn has already queued it.

Ok, that's probably better.

	Arnd


From olof at lixom.net  Sat Apr 27 17:07:35 2013
From: olof at lixom.net (Olof Johansson)
Date: Sat, 27 Apr 2013 14:07:35 -0700
Subject: [PATCH] clk: add option to keep boot clocks on
In-Reply-To: <20130427181713.8923.62611@quantum>
References: <1367019591-31685-1-git-send-email-olof@lixom.net>
 <20130427181713.8923.62611@quantum>
Message-ID: <20130427210735.GA9308@quad.lixom.net>

On Sat, Apr 27, 2013 at 11:17:13AM -0700, Mike Turquette wrote:
> Quoting Olof Johansson (2013-04-26 16:39:51)
> > This is primarily useful when there's a driver that doesn't claim clocks
> > properly, but the bootloader does. It's not expected to be used in normal
> > cases, but for bringup and debug it's very useful to have the option to
> > not gate unclaimed clocks that are still on.
> > 
> > Signed-off-by: Olof Johansson <olof at lixom.net>
> > ---
> > 
> > Mike, this is a pretty trivial patch that I would love to see in 3.10
> > even though it's getting late. I'm definitely not picky about the naming
> > of the boot option, so feel free to change it.
> > 
> 
> This bike shed could be improved with a different color of paint.
> Opinions below:
> 
> > 
> > -Olof
> > 
> >  drivers/clk/clk.c | 14 ++++++++++++++
> >  1 file changed, 14 insertions(+)
> > 
> > diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> > index 20ce67f..b22551e 100644
> > --- a/drivers/clk/clk.c
> > +++ b/drivers/clk/clk.c
> > @@ -499,10 +499,24 @@ out:
> >         return;
> >  }
> >  
> > +
> 
> Remove extra whitespace.
> 
> > +static bool keep_boot_clocks;
> > +static int __init clk_keep_boot_clocks(char *__unused)
> > +{
> > +       keep_boot_clocks = true;
> > +       return 1;
> > +}
> > +__setup("clk_keep_boot_clocks", clk_keep_boot_clocks);
> 
> s/clk_keep_boot_clocks/clk_ignore_unused/
> 
> This matches nicely with the existing CLK_IGNORE_UNUSED flag in
> include/linux/clk-provider.h
> 
> In addition to Randy's suggestion to update kernel-parameters.txt,
> please also toss in a note somewhere in Documentation/clk.txt so that
> others bringing up new platforms can more easily find out about this
> boot option.  Don't worry about making it pretty since I plan to rework
> the clock documentation for 3.11.
> 
> Otherwise patch looks good to me.  I did some testing and I would be
> comfortable sneaking this in for 3.10.

Great, thanks. I'm happy to paint in any color requested. :)

V2 patch posted separately.


-Olof


From olof at lixom.net  Sat Apr 27 17:10:18 2013
From: olof at lixom.net (Olof Johansson)
Date: Sat, 27 Apr 2013 14:10:18 -0700
Subject: [PATCH v2] clk: add clk_ignore_unused option to keep boot clocks on
In-Reply-To: <1367019591-31685-1-git-send-email-olof@lixom.net>
References: <1367019591-31685-1-git-send-email-olof@lixom.net>
Message-ID: <20130427211018.GA9376@quad.lixom.net>

This is primarily useful when there's a driver that doesn't claim clocks
properly, but the bootloader leaves them on. It's not expected to be used
in normal cases, but for bringup and debug it's very useful to have the
option to not gate unclaimed clocks that are still on.

Signed-off-by: Olof Johansson <olof at lixom.net>
---
 Documentation/clk.txt               | 11 +++++++++++
 Documentation/kernel-parameters.txt |  8 ++++++++
 drivers/clk/clk.c                   | 13 +++++++++++++
 3 files changed, 32 insertions(+)

diff --git a/Documentation/clk.txt b/Documentation/clk.txt
index 4274a54..b9911c2 100644
--- a/Documentation/clk.txt
+++ b/Documentation/clk.txt
@@ -231,3 +231,14 @@ To better enforce this policy, always follow this simple rule: any
 statically initialized clock data MUST be defined in a separate file
 from the logic that implements its ops.  Basically separate the logic
 from the data and all is well.
+
+	Part 6 - Disabling clock gating of unused clocks
+
+Sometimes during development it can be useful to be able to bypass the
+default disabling of unused clocks. For example, if drivers aren't enabling
+clocks properly but rely on them being on from the bootloader, bypassing
+the disabling means that the driver will remain functional while the issues
+are sorted out.
+
+To bypass this disabling, include "clk_ignore_unused" in the bootargs to the
+kernel.
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index c4fa000..c3bfacb 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -44,6 +44,7 @@ parameter is applicable:
 	AVR32	AVR32 architecture is enabled.
 	AX25	Appropriate AX.25 support is enabled.
 	BLACKFIN Blackfin architecture is enabled.
+	CLK	Common clock infrastructure is enabled.
 	CMA	Contiguous Memory Area support is enabled.
 	DRM	Direct Rendering Management support is enabled.
 	DYNAMIC_DEBUG Build in debug messages and enable them at runtime
@@ -473,6 +474,13 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
 
 	cio_ignore=	[S390]
 			See Documentation/s390/CommonIO for details.
+	clk_ignore_unused
+			[CLK]
+			Keep all clocks already enabled by bootloader on,
+			even if no driver has claimed them. This is useful
+			for debug and development, but should not be
+			needed on a platform with proper driver support.
+			For more information, see Documentation/clk.txt.
 
 	clock=		[BUGS=X86-32, HW] gettimeofday clocksource override.
 			[Deprecated]
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 20ce67f..934cfd1 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -499,10 +499,23 @@ out:
 	return;
 }
 
+static bool clk_ignore_unused;
+static int __init clk_ignore_unused_setup(char *__unused)
+{
+	clk_ignore_unused = true;
+	return 1;
+}
+__setup("clk_ignore_unused", clk_ignore_unused_setup);
+
 static int clk_disable_unused(void)
 {
 	struct clk *clk;
 
+	if (clk_ignore_unused) {
+		pr_warn("clk: Not disabling unused clocks\n");
+		return 0;
+	}
+
 	clk_prepare_lock();
 
 	hlist_for_each_entry(clk, &clk_root_list, child_node)
-- 
1.8.1.192.gc4361b8



From olof at lixom.net  Sat Apr 27 18:12:31 2013
From: olof at lixom.net (Olof Johansson)
Date: Sat, 27 Apr 2013 15:12:31 -0700
Subject: [PATCH] ARM: exynos: dts: cros5250: add EC device
In-Reply-To: <CAD=FV=VQg=2R_x11xuGiA0kNj1NXHUM3TUzVJC-F0ZWO39JRdw@mail.gmail.com>
References: <1367019745-31826-1-git-send-email-olof@lixom.net>
 <CAD=FV=WhoGO8=5pt=VOCT_2j2CMkn8on=N=jK_2RwMOXWat57w@mail.gmail.com>
 <20130427010406.GE2350@quad.lixom.net>
 <CAD=FV=VQg=2R_x11xuGiA0kNj1NXHUM3TUzVJC-F0ZWO39JRdw@mail.gmail.com>
Message-ID: <20130427221231.GA10453@quad.lixom.net>

On Fri, Apr 26, 2013 at 09:04:56PM -0700, Doug Anderson wrote:
> Olof,
> 
> On Fri, Apr 26, 2013 at 6:04 PM, Olof Johansson <olof at lixom.net> wrote:
> > Ah, yes, of course. As discussed off-mail, I was mislead by some contents in
> > our local tree. :)
> 
> Sorry about that--that was my fault.  Things have landed in a
> different order in one of our local trees.

Yeah, no worries.

> > Kukjin, I'd really like to pick up these patches for 3.10, since they're
> > isolated to just dts changes and gets keyboard working on the Chromebook. Can
> > you ack them and I'll just collect them this time?
> 
> I'm pretty sure that Kukjin is OK with them.  Kukjin responded earlier and said:
> 
> > I'm fine on 2nd and 3rd patches. Shall I take only two patches without 1st
> > one in samsung tree?
> 
> At the time we were waiting for Wolfram to get patch 1 into his tree,
> which is now done.
> 
> ...but waiting for his official Ack is good, too.  ;)


Ah, yes, sounds good. I'll apply these to a late/* branch on arm-soc. It's only
touching cros5250 and snow device trees anyway.

v2 of the patch posted as separate comment.


-Olof


From olof at lixom.net  Sat Apr 27 18:14:10 2013
From: olof at lixom.net (Olof Johansson)
Date: Sat, 27 Apr 2013 15:14:10 -0700
Subject: [PATCH v2] ARM: exynos: dts: cros5250: add EC device
In-Reply-To: <1367019745-31826-1-git-send-email-olof@lixom.net>
References: <1367019745-31826-1-git-send-email-olof@lixom.net>
Message-ID: <20130427221410.GA10618@quad.lixom.net>

Add basic EC information to device tree, currently only describing the
keyboard and keymap.

Signed-off-by: Olof Johansson <olof at lixom.net>
---

This builds on the previous patch from Doug to add arbitration (and the
sbs-battery dts patch).

 arch/arm/boot/dts/exynos5250-snow.dts | 96 +++++++++++++++++++++++++++++++++++
 1 file changed, 96 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5250-snow.dts b/arch/arm/boot/dts/exynos5250-snow.dts
index c115143..ad25e66 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -72,6 +72,102 @@
 				reg = <0xb>;
 				sbs,poll-retry-count = <1>;
 			};
+
+			ec: embedded-controller {
+				compatible = "google,cros-ec-i2c";
+				reg = <0x1e>;
+				interrupts = <6 0>;
+				interrupt-parent = <&gpx1>;
+				wakeup-source;
+
+				keyboard-controller {
+				        compatible = "google,cros-ec-keyb";
+				        keypad,num-rows = <8>;
+				        keypad,num-columns = <13>;
+				        google,needs-ghost-filter;
+					linux,keymap = <0x0001003a	/* CAPSLK */
+							0x0002003b	/* F1 */
+							0x00030030	/* B */
+							0x00040044	/* F10 */
+							0x00060031	/* N */
+							0x0008000d	/* = */
+							0x000a0064	/* R_ALT */
+
+							0x01010001	/* ESC */
+							0x0102003e	/* F4 */
+							0x01030022	/* G */
+							0x01040041	/* F7 */
+							0x01060023	/* H */
+							0x01080028	/* ' */
+							0x01090043	/* F9 */
+							0x010b000e	/* BKSPACE */
+
+							0x0200001d	/* L_CTRL */
+							0x0201000f	/* TAB */
+							0x0202003d	/* F3 */
+							0x02030014	/* T */
+							0x02040040	/* F6 */
+							0x0205001b	/* ] */
+							0x02060015	/* Y */
+							0x02070056	/* 102ND */
+							0x0208001a	/* [ */
+							0x02090042	/* F8 */
+
+							0x03010029	/* GRAVE */
+							0x0302003c	/* F2 */
+							0x03030006	/* 5 */
+							0x0304003f	/* F5 */
+							0x03060007	/* 6 */
+							0x0308000c	/* - */
+							0x030b002b	/* \ */
+
+							0x04000061	/* R_CTRL */
+							0x0401001e	/* A */
+							0x04020020	/* D */
+							0x04030021	/* F */
+							0x0404001f	/* S */
+							0x04050025	/* K */
+							0x04060024	/* J */
+							0x04080027	/* ; */
+							0x04090026	/* L */
+							0x040b001c	/* ENTER */
+
+							0x0501002c	/* Z */
+							0x0502002e	/* C */
+							0x0503002f	/* V */
+							0x0504002d	/* X */
+							0x05050033	/* , */
+							0x05060032	/* M */
+							0x0507002a	/* L_SHIFT */
+							0x05080035	/* / */
+							0x05090034	/* . */
+							0x050B0039	/* SPACE */
+
+							0x06010002	/* 1 */
+							0x06020004	/* 3 */
+							0x06030005	/* 4 */
+							0x06040003	/* 2 */
+							0x06050009	/* 8 */
+							0x06060008	/* 7 */
+							0x0608000b	/* 0 */
+							0x0609000a	/* 9 */
+							0x060a0038	/* L_ALT */
+							0x060b006c	/* DOWN */
+							0x060c006a	/* RIGHT */
+
+							0x07010010	/* Q */
+							0x07020012	/* E */
+							0x07030013	/* R */
+							0x07040011	/* W */
+							0x07050017	/* I */
+							0x07060016	/* U */
+							0x07070036	/* R_SHIFT */
+							0x07080019	/* P */
+							0x07090018	/* O */
+							0x070b0067	/* UP */
+							0x070c0069>;	/* LEFT */
+				};
+			};
 		};
 	};
 
-- 
1.8.2.1



From dianders at chromium.org  Sat Apr 27 18:31:02 2013
From: dianders at chromium.org (Doug Anderson)
Date: Sat, 27 Apr 2013 15:31:02 -0700
Subject: [PATCH v2] ARM: exynos: dts: cros5250: add EC device
In-Reply-To: <20130427221410.GA10618@quad.lixom.net>
References: <1367019745-31826-1-git-send-email-olof@lixom.net>
 <20130427221410.GA10618@quad.lixom.net>
Message-ID: <CAD=FV=U8889MZVdSxxYtYfVF3bY67URG9anxR1aU2oyLOHwKNg@mail.gmail.com>

Olof,

On Sat, Apr 27, 2013 at 3:14 PM, Olof Johansson <olof at lixom.net> wrote:
> Add basic EC information to device tree, currently only describing the
> keyboard and keymap.
>
> Signed-off-by: Olof Johansson <olof at lixom.net>
> ---
>
> This builds on the previous patch from Doug to add arbitration (and the
> sbs-battery dts patch).
>
>  arch/arm/boot/dts/exynos5250-snow.dts | 96 +++++++++++++++++++++++++++++++++++
>  1 file changed, 96 insertions(+)

Looks good to me.  Thanks!

Reviewed-by: Doug Anderson <dianders at chromium.org>


From linux at prisktech.co.nz  Sat Apr 27 19:29:26 2013
From: linux at prisktech.co.nz (Tony Prisk)
Date: Sun, 28 Apr 2013 11:29:26 +1200
Subject: Array subscript above array bounds warning
Message-ID: <517C5F56.7040106@prisktech.co.nz>

Could someone clarify for me what I am missing here?


in drivers/net/ethernet/via/velocity.h is the following definition:

struct mac_regs {
volatile u8 PAR[6]; /* 0x00 */
...
}

I am trying to add the following function but it keeps giving array 
bounds warnings:

static void velocity_set_power_state(struct velocity_info *vptr, char state)
{
struct mac_regs __iomem *regs = vptr->mac_regs;

if (vptr->bustype == BUS_PCI) {
pci_set_power_state(vptr->pdev, state);
} else {
writeb(state, (&regs->PAR[0]) + 0x154);
}
}

gives:

/home/sentient/linux-git/server/arch/arm/include/asm/io.h:83:2: warning: 
array subscript is above array bounds [-Warray-bounds]


If I change the function to:

static void velocity_set_power_state(struct velocity_info *vptr, char state)
{
void __iomem *addr;
struct mac_regs __iomem *regs = vptr->mac_regs;

if (vptr->bustype == BUS_PCI)
pci_set_power_state(vptr->pdev, state);
else {
addr = &regs->PAR[0];
writeb(state, addr + 0x154);
}
}

I get the following warning:

drivers/net/ethernet/via/via-velocity.c:99:8: warning: assignment 
discards ?volatile? qualifier from pointer target type [enabled by default]


What is the correct way to go about this?

Regards
Tony Prisk


From emilio at elopez.com.ar  Sat Apr 27 19:54:35 2013
From: emilio at elopez.com.ar (=?windows-1252?Q?Emilio_L=F3pez?=)
Date: Sat, 27 Apr 2013 20:54:35 -0300
Subject: Array subscript above array bounds warning
In-Reply-To: <517C5F56.7040106@prisktech.co.nz>
References: <517C5F56.7040106@prisktech.co.nz>
Message-ID: <517C653B.7050908@elopez.com.ar>

El 27/04/13 20:29, Tony Prisk escribi?:
> Could someone clarify for me what I am missing here?
> 
> 
> in drivers/net/ethernet/via/velocity.h is the following definition:
> 
> struct mac_regs {
> volatile u8 PAR[6]; /* 0x00 */
> ...
> }
> 
> I am trying to add the following function but it keeps giving array
> bounds warnings:
> 
> static void velocity_set_power_state(struct velocity_info *vptr, char
> state)
> {
> struct mac_regs __iomem *regs = vptr->mac_regs;
> 
> if (vptr->bustype == BUS_PCI) {
> pci_set_power_state(vptr->pdev, state);
> } else {
> writeb(state, (&regs->PAR[0]) + 0x154);

This would be equivalent to

writeb(state, regs->PAR + 0x154);

or

writeb(state, &regs->PAR[340]);

Which would be out of bounds, right? As it's an u8 array with just 6
elements, not 341+


From broonie at kernel.org  Sat Apr 27 21:10:31 2013
From: broonie at kernel.org (Mark Brown)
Date: Sun, 28 Apr 2013 02:10:31 +0100
Subject: [PATCH v2 1/2] regulator: mc13xxx: Add warning of incorrect
 names of regulators
In-Reply-To: <1367044165-6373-1-git-send-email-shc_work@mail.ru>
References: <1367044165-6373-1-git-send-email-shc_work@mail.ru>
Message-ID: <20130428011031.GB20197@sirena.org.uk>

On Sat, Apr 27, 2013 at 10:29:24AM +0400, Alexander Shiyan wrote:
> This patch adds a warning about incorrect regulators instead of
> printing the names of non-information message about the wrong amount.

Applied both, thanks.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130428/f7f22f8e/attachment.sig>

From linux at prisktech.co.nz  Sat Apr 27 21:37:01 2013
From: linux at prisktech.co.nz (Tony Prisk)
Date: Sun, 28 Apr 2013 13:37:01 +1200
Subject: Array subscript above array bounds warning
In-Reply-To: <517C653B.7050908@elopez.com.ar>
References: <517C5F56.7040106@prisktech.co.nz> <517C653B.7050908@elopez.com.ar>
Message-ID: <517C7D3D.50207@prisktech.co.nz>

On 28/04/13 11:54, Emilio L?pez wrote:
> El 27/04/13 20:29, Tony Prisk escribi?:
>> Could someone clarify for me what I am missing here?
>>
>>
>> in drivers/net/ethernet/via/velocity.h is the following definition:
>>
>> struct mac_regs {
>> volatile u8 PAR[6]; /* 0x00 */
>> ...
>> }
>>
>> I am trying to add the following function but it keeps giving array
>> bounds warnings:
>>
>> static void velocity_set_power_state(struct velocity_info *vptr, char
>> state)
>> {
>> struct mac_regs __iomem *regs = vptr->mac_regs;
>>
>> if (vptr->bustype == BUS_PCI) {
>> pci_set_power_state(vptr->pdev, state);
>> } else {
>> writeb(state, (&regs->PAR[0]) + 0x154);
> This would be equivalent to
>
> writeb(state, regs->PAR + 0x154);
>
> or
>
> writeb(state, &regs->PAR[340]);
>
> Which would be out of bounds, right? As it's an u8 array with just 6
> elements, not 341+
Yeah sorry - stupid question.

I just thought about the code while out for a walk and realised I should 
have looked at what the original author was trying to do rather than 
copy it verbatim.I have solved the issue now.

Regards
Tony P


From linux at prisktech.co.nz  Sat Apr 27 23:16:42 2013
From: linux at prisktech.co.nz (Tony Prisk)
Date: Sun, 28 Apr 2013 15:16:42 +1200
Subject: [PATCH 0/4] Add support for velocity network driver on platform
 devices
Message-ID: <1367119006-31280-1-git-send-email-linux@prisktech.co.nz>

The first three patches are general tidyup.
Patch #1 just alphabetizes the #includes to make it easier to read.
Patch #2 replaces vptr->dev with vptr->netdev, again for clarity in the code.
Patch #3 replaces the pci dma functions with the generic versions.

I have build tested these patches but don't have a PCI velocity to run-test it.
I can't see that they should introduce any problems as it is all renames and
function swapping.

Patch #4 adds support for the velocity driver on devicetree platform devices.
Binding document included. This patch is compile-tested for PCI, and boot
tested on a VIA APC8750.

I think it would be pertinent to get some tested-by's for PCI users.

Regards
Tony Prisk


Tony Prisk (4):
  net: velocity: Alphabetize #includes
  net: velocity: Rename vptr->dev to vptr->netdev
  net: velocity: Convert to generic dma functions
  net: velocity: Add platform device support to VIA velocity driver

 .../devicetree/bindings/net/via-velocity.txt       |   20 +
 drivers/net/ethernet/via/Kconfig                   |    3 +-
 drivers/net/ethernet/via/via-velocity.c            |  612 ++++++++++++++------
 drivers/net/ethernet/via/via-velocity.h            |   35 +-
 4 files changed, 480 insertions(+), 190 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/net/via-velocity.txt

-- 
1.7.9.5



From linux at prisktech.co.nz  Sat Apr 27 23:16:43 2013
From: linux at prisktech.co.nz (Tony Prisk)
Date: Sun, 28 Apr 2013 15:16:43 +1200
Subject: [PATCH 1/4] net: velocity: Alphabetize #includes
In-Reply-To: <1367119006-31280-1-git-send-email-linux@prisktech.co.nz>
References: <1367119006-31280-1-git-send-email-linux@prisktech.co.nz>
Message-ID: <1367119006-31280-2-git-send-email-linux@prisktech.co.nz>

Due to number of #includes, alphabetize them to help avoid duplicates.

Signed-off-by: Tony Prisk <linux at prisktech.co.nz>
---
 drivers/net/ethernet/via/via-velocity.c |   48 +++++++++++++++----------------
 1 file changed, 24 insertions(+), 24 deletions(-)

diff --git a/drivers/net/ethernet/via/via-velocity.c b/drivers/net/ethernet/via/via-velocity.c
index 1bc7f9fd..eb2a023 100644
--- a/drivers/net/ethernet/via/via-velocity.c
+++ b/drivers/net/ethernet/via/via-velocity.c
@@ -42,40 +42,40 @@
  *
  */
 
-#include <linux/module.h>
-#include <linux/types.h>
 #include <linux/bitops.h>
-#include <linux/init.h>
-#include <linux/mm.h>
+#include <linux/crc-ccitt.h>
+#include <linux/crc32.h>
+#include <linux/delay.h>
 #include <linux/errno.h>
+#include <linux/etherdevice.h>
+#include <linux/ethtool.h>
+#include <linux/if.h>
+#include <linux/if_arp.h>
+#include <linux/if_vlan.h>
+#include <linux/in.h>
+#include <linux/inetdevice.h>
+#include <linux/init.h>
+#include <linux/interrupt.h>
+#include <linux/io.h>
 #include <linux/ioport.h>
-#include <linux/pci.h>
+#include <linux/ip.h>
 #include <linux/kernel.h>
+#include <linux/mii.h>
+#include <linux/mm.h>
+#include <linux/module.h>
 #include <linux/netdevice.h>
-#include <linux/etherdevice.h>
+#include <linux/pci.h>
+#include <linux/proc_fs.h>
+#include <linux/reboot.h>
 #include <linux/skbuff.h>
-#include <linux/delay.h>
-#include <linux/timer.h>
 #include <linux/slab.h>
-#include <linux/interrupt.h>
 #include <linux/string.h>
-#include <linux/wait.h>
-#include <linux/io.h>
-#include <linux/if.h>
-#include <linux/uaccess.h>
-#include <linux/proc_fs.h>
-#include <linux/inetdevice.h>
-#include <linux/reboot.h>
-#include <linux/ethtool.h>
-#include <linux/mii.h>
-#include <linux/in.h>
-#include <linux/if_arp.h>
-#include <linux/if_vlan.h>
-#include <linux/ip.h>
 #include <linux/tcp.h>
+#include <linux/timer.h>
+#include <linux/types.h>
+#include <linux/uaccess.h>
 #include <linux/udp.h>
-#include <linux/crc-ccitt.h>
-#include <linux/crc32.h>
+#include <linux/wait.h>
 
 #include "via-velocity.h"
 
-- 
1.7.9.5



From linux at prisktech.co.nz  Sat Apr 27 23:16:44 2013
From: linux at prisktech.co.nz (Tony Prisk)
Date: Sun, 28 Apr 2013 15:16:44 +1200
Subject: [PATCH 2/4] net: velocity: Rename vptr->dev to vptr->netdev
In-Reply-To: <1367119006-31280-1-git-send-email-linux@prisktech.co.nz>
References: <1367119006-31280-1-git-send-email-linux@prisktech.co.nz>
Message-ID: <1367119006-31280-3-git-send-email-linux@prisktech.co.nz>

Improve the clarity of the code in preparation for converting the
dma functions to generic versions, which require a struct device *.

This makes it possible to store a 'struct device *dev' in the
velocity_info structure.

Signed-off-by: Tony Prisk <linux at prisktech.co.nz>
---
 drivers/net/ethernet/via/via-velocity.c |   66 +++++++++++++++----------------
 drivers/net/ethernet/via/via-velocity.h |    4 +-
 2 files changed, 35 insertions(+), 35 deletions(-)

diff --git a/drivers/net/ethernet/via/via-velocity.c b/drivers/net/ethernet/via/via-velocity.c
index eb2a023..1168666 100644
--- a/drivers/net/ethernet/via/via-velocity.c
+++ b/drivers/net/ethernet/via/via-velocity.c
@@ -996,9 +996,9 @@ static void velocity_print_link_status(struct velocity_info *vptr)
 {
 
 	if (vptr->mii_status & VELOCITY_LINK_FAIL) {
-		VELOCITY_PRT(MSG_LEVEL_INFO, KERN_NOTICE "%s: failed to detect cable link\n", vptr->dev->name);
+		VELOCITY_PRT(MSG_LEVEL_INFO, KERN_NOTICE "%s: failed to detect cable link\n", vptr->netdev->name);
 	} else if (vptr->options.spd_dpx == SPD_DPX_AUTO) {
-		VELOCITY_PRT(MSG_LEVEL_INFO, KERN_NOTICE "%s: Link auto-negotiation", vptr->dev->name);
+		VELOCITY_PRT(MSG_LEVEL_INFO, KERN_NOTICE "%s: Link auto-negotiation", vptr->netdev->name);
 
 		if (vptr->mii_status & VELOCITY_SPEED_1000)
 			VELOCITY_PRT(MSG_LEVEL_INFO, " speed 1000M bps");
@@ -1012,7 +1012,7 @@ static void velocity_print_link_status(struct velocity_info *vptr)
 		else
 			VELOCITY_PRT(MSG_LEVEL_INFO, " half duplex\n");
 	} else {
-		VELOCITY_PRT(MSG_LEVEL_INFO, KERN_NOTICE "%s: Link forced", vptr->dev->name);
+		VELOCITY_PRT(MSG_LEVEL_INFO, KERN_NOTICE "%s: Link forced", vptr->netdev->name);
 		switch (vptr->options.spd_dpx) {
 		case SPD_DPX_1000_FULL:
 			VELOCITY_PRT(MSG_LEVEL_INFO, " speed 1000M bps full duplex\n");
@@ -1317,7 +1317,7 @@ static void velocity_init_registers(struct velocity_info *vptr,
 	case VELOCITY_INIT_RESET:
 	case VELOCITY_INIT_WOL:
 
-		netif_stop_queue(vptr->dev);
+		netif_stop_queue(vptr->netdev);
 
 		/*
 		 *	Reset RX to prevent RX pointer not on the 4X location
@@ -1330,7 +1330,7 @@ static void velocity_init_registers(struct velocity_info *vptr,
 		if (velocity_set_media_mode(vptr, mii_status) != VELOCITY_LINK_CHANGE) {
 			velocity_print_link_status(vptr);
 			if (!(vptr->mii_status & VELOCITY_LINK_FAIL))
-				netif_wake_queue(vptr->dev);
+				netif_wake_queue(vptr->netdev);
 		}
 
 		enable_flow_control_ability(vptr);
@@ -1352,7 +1352,7 @@ static void velocity_init_registers(struct velocity_info *vptr,
 
 		mac_eeprom_reload(regs);
 		for (i = 0; i < 6; i++)
-			writeb(vptr->dev->dev_addr[i], &(regs->PAR[i]));
+			writeb(vptr->netdev->dev_addr[i], &(regs->PAR[i]));
 
 		/*
 		 *	clear Pre_ACPI bit.
@@ -1375,7 +1375,7 @@ static void velocity_init_registers(struct velocity_info *vptr,
 		/*
 		 *	Set packet filter: Receive directed and broadcast address
 		 */
-		velocity_set_multi(vptr->dev);
+		velocity_set_multi(vptr->netdev);
 
 		/*
 		 *	Enable MII auto-polling
@@ -1402,14 +1402,14 @@ static void velocity_init_registers(struct velocity_info *vptr,
 		writel((CR0_DPOLL | CR0_TXON | CR0_RXON | CR0_STRT), &regs->CR0Set);
 
 		mii_status = velocity_get_opt_media_mode(vptr);
-		netif_stop_queue(vptr->dev);
+		netif_stop_queue(vptr->netdev);
 
 		mii_init(vptr, mii_status);
 
 		if (velocity_set_media_mode(vptr, mii_status) != VELOCITY_LINK_CHANGE) {
 			velocity_print_link_status(vptr);
 			if (!(vptr->mii_status & VELOCITY_LINK_FAIL))
-				netif_wake_queue(vptr->dev);
+				netif_wake_queue(vptr->netdev);
 		}
 
 		enable_flow_control_ability(vptr);
@@ -1472,7 +1472,7 @@ static int velocity_init_dma_rings(struct velocity_info *vptr)
 				    rx_ring_size, &pool_dma);
 	if (!pool) {
 		dev_err(&pdev->dev, "%s : DMA memory allocation failed.\n",
-			vptr->dev->name);
+			vptr->netdev->name);
 		return -ENOMEM;
 	}
 
@@ -1512,7 +1512,7 @@ static int velocity_alloc_rx_buf(struct velocity_info *vptr, int idx)
 	struct rx_desc *rd = &(vptr->rx.ring[idx]);
 	struct velocity_rd_info *rd_info = &(vptr->rx.info[idx]);
 
-	rd_info->skb = netdev_alloc_skb(vptr->dev, vptr->rx.buf_sz + 64);
+	rd_info->skb = netdev_alloc_skb(vptr->netdev, vptr->rx.buf_sz + 64);
 	if (rd_info->skb == NULL)
 		return -ENOMEM;
 
@@ -1618,7 +1618,7 @@ static int velocity_init_rd_ring(struct velocity_info *vptr)
 
 	if (velocity_rx_refill(vptr) != vptr->options.numrx) {
 		VELOCITY_PRT(MSG_LEVEL_ERR, KERN_ERR
-			"%s: failed to allocate RX buffer.\n", vptr->dev->name);
+			"%s: failed to allocate RX buffer.\n", vptr->netdev->name);
 		velocity_free_rd_ring(vptr);
 		goto out;
 	}
@@ -1807,7 +1807,7 @@ static void velocity_error(struct velocity_info *vptr, int status)
 		printk(KERN_ERR "TD structure error TDindex=%hx\n", readw(&regs->TDIdx[0]));
 		BYTE_REG_BITS_ON(TXESR_TDSTR, &regs->TXESR);
 		writew(TRDCSR_RUN, &regs->TDCSRClr);
-		netif_stop_queue(vptr->dev);
+		netif_stop_queue(vptr->netdev);
 
 		/* FIXME: port over the pci_device_failed code and use it
 		   here */
@@ -1848,10 +1848,10 @@ static void velocity_error(struct velocity_info *vptr, int status)
 
 		if (linked) {
 			vptr->mii_status &= ~VELOCITY_LINK_FAIL;
-			netif_carrier_on(vptr->dev);
+			netif_carrier_on(vptr->netdev);
 		} else {
 			vptr->mii_status |= VELOCITY_LINK_FAIL;
-			netif_carrier_off(vptr->dev);
+			netif_carrier_off(vptr->netdev);
 		}
 
 		velocity_print_link_status(vptr);
@@ -1865,9 +1865,9 @@ static void velocity_error(struct velocity_info *vptr, int status)
 		enable_mii_autopoll(regs);
 
 		if (vptr->mii_status & VELOCITY_LINK_FAIL)
-			netif_stop_queue(vptr->dev);
+			netif_stop_queue(vptr->netdev);
 		else
-			netif_wake_queue(vptr->dev);
+			netif_wake_queue(vptr->netdev);
 
 	}
 	if (status & ISR_MIBFI)
@@ -1892,7 +1892,7 @@ static int velocity_tx_srv(struct velocity_info *vptr)
 	int idx;
 	int works = 0;
 	struct velocity_td_info *tdinfo;
-	struct net_device_stats *stats = &vptr->dev->stats;
+	struct net_device_stats *stats = &vptr->netdev->stats;
 
 	for (qnum = 0; qnum < vptr->tx.numq; qnum++) {
 		for (idx = vptr->tx.tail[qnum]; vptr->tx.used[qnum] > 0;
@@ -1937,9 +1937,9 @@ static int velocity_tx_srv(struct velocity_info *vptr)
 	 *	Look to see if we should kick the transmit network
 	 *	layer for more work.
 	 */
-	if (netif_queue_stopped(vptr->dev) && (full == 0) &&
+	if (netif_queue_stopped(vptr->netdev) && (full == 0) &&
 	    (!(vptr->mii_status & VELOCITY_LINK_FAIL))) {
-		netif_wake_queue(vptr->dev);
+		netif_wake_queue(vptr->netdev);
 	}
 	return works;
 }
@@ -1987,7 +1987,7 @@ static int velocity_rx_copy(struct sk_buff **rx_skb, int pkt_size,
 	if (pkt_size < rx_copybreak) {
 		struct sk_buff *new_skb;
 
-		new_skb = netdev_alloc_skb_ip_align(vptr->dev, pkt_size);
+		new_skb = netdev_alloc_skb_ip_align(vptr->netdev, pkt_size);
 		if (new_skb) {
 			new_skb->ip_summed = rx_skb[0]->ip_summed;
 			skb_copy_from_linear_data(*rx_skb, new_skb->data, pkt_size);
@@ -2028,14 +2028,14 @@ static inline void velocity_iph_realign(struct velocity_info *vptr,
 static int velocity_receive_frame(struct velocity_info *vptr, int idx)
 {
 	void (*pci_action)(struct pci_dev *, dma_addr_t, size_t, int);
-	struct net_device_stats *stats = &vptr->dev->stats;
+	struct net_device_stats *stats = &vptr->netdev->stats;
 	struct velocity_rd_info *rd_info = &(vptr->rx.info[idx]);
 	struct rx_desc *rd = &(vptr->rx.ring[idx]);
 	int pkt_len = le16_to_cpu(rd->rdesc0.len) & 0x3fff;
 	struct sk_buff *skb;
 
 	if (rd->rdesc0.RSR & (RSR_STP | RSR_EDP)) {
-		VELOCITY_PRT(MSG_LEVEL_VERBOSE, KERN_ERR " %s : the received frame span multple RDs.\n", vptr->dev->name);
+		VELOCITY_PRT(MSG_LEVEL_VERBOSE, KERN_ERR " %s : the received frame span multple RDs.\n", vptr->netdev->name);
 		stats->rx_length_errors++;
 		return -EINVAL;
 	}
@@ -2073,7 +2073,7 @@ static int velocity_receive_frame(struct velocity_info *vptr, int idx)
 		   PCI_DMA_FROMDEVICE);
 
 	skb_put(skb, pkt_len - 4);
-	skb->protocol = eth_type_trans(skb, vptr->dev);
+	skb->protocol = eth_type_trans(skb, vptr->netdev);
 
 	if (rd->rdesc0.RSR & RSR_DETAG) {
 		u16 vid = swab16(le16_to_cpu(rd->rdesc1.PQTAG));
@@ -2098,7 +2098,7 @@ static int velocity_receive_frame(struct velocity_info *vptr, int idx)
  */
 static int velocity_rx_srv(struct velocity_info *vptr, int budget_left)
 {
-	struct net_device_stats *stats = &vptr->dev->stats;
+	struct net_device_stats *stats = &vptr->netdev->stats;
 	int rd_curr = vptr->rx.curr;
 	int works = 0;
 
@@ -2290,7 +2290,7 @@ static int velocity_change_mtu(struct net_device *dev, int new_mtu)
 
 	if ((new_mtu < VELOCITY_MIN_MTU) || new_mtu > (VELOCITY_MAX_MTU)) {
 		VELOCITY_PRT(MSG_LEVEL_ERR, KERN_NOTICE "%s: Invalid MTU.\n",
-				vptr->dev->name);
+				vptr->netdev->name);
 		ret = -EINVAL;
 		goto out_0;
 	}
@@ -2312,7 +2312,7 @@ static int velocity_change_mtu(struct net_device *dev, int new_mtu)
 			goto out_0;
 		}
 
-		tmp_vptr->dev = dev;
+		tmp_vptr->netdev = dev;
 		tmp_vptr->pdev = vptr->pdev;
 		tmp_vptr->options = vptr->options;
 		tmp_vptr->tx.numq = vptr->tx.numq;
@@ -2690,7 +2690,7 @@ static int velocity_get_pci_info(struct velocity_info *vptr,
  */
 static void velocity_print_info(struct velocity_info *vptr)
 {
-	struct net_device *dev = vptr->dev;
+	struct net_device *dev = vptr->netdev;
 
 	printk(KERN_INFO "%s: %s\n", dev->name, get_chip_name(vptr->chip_id));
 	printk(KERN_INFO "%s: Ethernet Address: %pM\n",
@@ -2753,7 +2753,7 @@ static int velocity_found1(struct pci_dev *pdev,
 
 	velocity_init_info(pdev, vptr, info);
 
-	vptr->dev = dev;
+	vptr->netdev = dev;
 
 	ret = pci_enable_device(pdev);
 	if (ret < 0)
@@ -3007,10 +3007,10 @@ static int velocity_suspend(struct pci_dev *pdev, pm_message_t state)
 	struct velocity_info *vptr = netdev_priv(dev);
 	unsigned long flags;
 
-	if (!netif_running(vptr->dev))
+	if (!netif_running(vptr->netdev))
 		return 0;
 
-	netif_device_detach(vptr->dev);
+	netif_device_detach(vptr->netdev);
 
 	spin_lock_irqsave(&vptr->lock, flags);
 	pci_save_state(pdev);
@@ -3075,7 +3075,7 @@ static int velocity_resume(struct pci_dev *pdev)
 	unsigned long flags;
 	int i;
 
-	if (!netif_running(vptr->dev))
+	if (!netif_running(vptr->netdev))
 		return 0;
 
 	pci_set_power_state(pdev, PCI_D0);
@@ -3098,7 +3098,7 @@ static int velocity_resume(struct pci_dev *pdev)
 
 	mac_enable_int(vptr->mac_regs);
 	spin_unlock_irqrestore(&vptr->lock, flags);
-	netif_device_attach(vptr->dev);
+	netif_device_attach(vptr->netdev);
 
 	return 0;
 }
diff --git a/drivers/net/ethernet/via/via-velocity.h b/drivers/net/ethernet/via/via-velocity.h
index 4cb9f13..ff8d7828 100644
--- a/drivers/net/ethernet/via/via-velocity.h
+++ b/drivers/net/ethernet/via/via-velocity.h
@@ -1435,7 +1435,7 @@ struct velocity_opt {
 
 struct velocity_info {
 	struct pci_dev *pdev;
-	struct net_device *dev;
+	struct net_device *netdev;
 
 	unsigned long active_vlans[BITS_TO_LONGS(VLAN_N_VID)];
 	u8 ip_addr[4];
@@ -1514,7 +1514,7 @@ static inline int velocity_get_ip(struct velocity_info *vptr)
 	int res = -ENOENT;
 
 	rcu_read_lock();
-	in_dev = __in_dev_get_rcu(vptr->dev);
+	in_dev = __in_dev_get_rcu(vptr->netdev);
 	if (in_dev != NULL) {
 		ifa = (struct in_ifaddr *) in_dev->ifa_list;
 		if (ifa != NULL) {
-- 
1.7.9.5



From linux at prisktech.co.nz  Sat Apr 27 23:16:45 2013
From: linux at prisktech.co.nz (Tony Prisk)
Date: Sun, 28 Apr 2013 15:16:45 +1200
Subject: [PATCH 3/4] net: velocity: Convert to generic dma functions
In-Reply-To: <1367119006-31280-1-git-send-email-linux@prisktech.co.nz>
References: <1367119006-31280-1-git-send-email-linux@prisktech.co.nz>
Message-ID: <1367119006-31280-4-git-send-email-linux@prisktech.co.nz>

Remove the pci_* dma functions and replace with the more generic
versions.

In preparation of adding platform support, a new struct device *dev
is added to struct velocity_info which can be used by both the pci
and platform code.

Signed-off-by: Tony Prisk <linux at prisktech.co.nz>
---
 drivers/net/ethernet/via/via-velocity.c |   51 +++++++++++++++----------------
 drivers/net/ethernet/via/via-velocity.h |    1 +
 2 files changed, 26 insertions(+), 26 deletions(-)

diff --git a/drivers/net/ethernet/via/via-velocity.c b/drivers/net/ethernet/via/via-velocity.c
index 1168666..a5fe892 100644
--- a/drivers/net/ethernet/via/via-velocity.c
+++ b/drivers/net/ethernet/via/via-velocity.c
@@ -46,6 +46,7 @@
 #include <linux/crc-ccitt.h>
 #include <linux/crc32.h>
 #include <linux/delay.h>
+#include <linux/dma-mapping.h>
 #include <linux/errno.h>
 #include <linux/etherdevice.h>
 #include <linux/ethtool.h>
@@ -1457,7 +1458,6 @@ static int velocity_init_dma_rings(struct velocity_info *vptr)
 	struct velocity_opt *opt = &vptr->options;
 	const unsigned int rx_ring_size = opt->numrx * sizeof(struct rx_desc);
 	const unsigned int tx_ring_size = opt->numtx * sizeof(struct tx_desc);
-	struct pci_dev *pdev = vptr->pdev;
 	dma_addr_t pool_dma;
 	void *pool;
 	unsigned int i;
@@ -1465,13 +1465,13 @@ static int velocity_init_dma_rings(struct velocity_info *vptr)
 	/*
 	 * Allocate all RD/TD rings a single pool.
 	 *
-	 * pci_alloc_consistent() fulfills the requirement for 64 bytes
+	 * dma_alloc_coherent() fulfills the requirement for 64 bytes
 	 * alignment
 	 */
-	pool = pci_alloc_consistent(pdev, tx_ring_size * vptr->tx.numq +
-				    rx_ring_size, &pool_dma);
+	pool = dma_alloc_coherent(vptr->dev, tx_ring_size * vptr->tx.numq +
+				    rx_ring_size, &pool_dma, GFP_ATOMIC);
 	if (!pool) {
-		dev_err(&pdev->dev, "%s : DMA memory allocation failed.\n",
+		dev_err(vptr->dev, "%s : DMA memory allocation failed.\n",
 			vptr->netdev->name);
 		return -ENOMEM;
 	}
@@ -1522,8 +1522,8 @@ static int velocity_alloc_rx_buf(struct velocity_info *vptr, int idx)
 	 */
 	skb_reserve(rd_info->skb,
 			64 - ((unsigned long) rd_info->skb->data & 63));
-	rd_info->skb_dma = pci_map_single(vptr->pdev, rd_info->skb->data,
-					vptr->rx.buf_sz, PCI_DMA_FROMDEVICE);
+	rd_info->skb_dma = dma_map_single(vptr->dev, rd_info->skb->data,
+					vptr->rx.buf_sz, DMA_FROM_DEVICE);
 
 	/*
 	 *	Fill in the descriptor to match
@@ -1586,8 +1586,8 @@ static void velocity_free_rd_ring(struct velocity_info *vptr)
 
 		if (!rd_info->skb)
 			continue;
-		pci_unmap_single(vptr->pdev, rd_info->skb_dma, vptr->rx.buf_sz,
-				 PCI_DMA_FROMDEVICE);
+		dma_unmap_single(vptr->dev, rd_info->skb_dma, vptr->rx.buf_sz,
+				 DMA_FROM_DEVICE);
 		rd_info->skb_dma = 0;
 
 		dev_kfree_skb(rd_info->skb);
@@ -1668,7 +1668,7 @@ static void velocity_free_dma_rings(struct velocity_info *vptr)
 	const int size = vptr->options.numrx * sizeof(struct rx_desc) +
 		vptr->options.numtx * sizeof(struct tx_desc) * vptr->tx.numq;
 
-	pci_free_consistent(vptr->pdev, size, vptr->rx.ring, vptr->rx.pool_dma);
+	dma_free_coherent(vptr->dev, size, vptr->rx.ring, vptr->rx.pool_dma);
 }
 
 static int velocity_init_rings(struct velocity_info *vptr, int mtu)
@@ -1725,8 +1725,8 @@ static void velocity_free_tx_buf(struct velocity_info *vptr,
 				pktlen = max_t(size_t, pktlen,
 						td->td_buf[i].size & ~TD_QUEUE);
 
-			pci_unmap_single(vptr->pdev, tdinfo->skb_dma[i],
-					le16_to_cpu(pktlen), PCI_DMA_TODEVICE);
+			dma_unmap_single(vptr->dev, tdinfo->skb_dma[i],
+					le16_to_cpu(pktlen), DMA_TO_DEVICE);
 		}
 	}
 	dev_kfree_skb_irq(skb);
@@ -1748,8 +1748,8 @@ static void velocity_free_td_ring_entry(struct velocity_info *vptr,
 	if (td_info->skb) {
 		for (i = 0; i < td_info->nskb_dma; i++) {
 			if (td_info->skb_dma[i]) {
-				pci_unmap_single(vptr->pdev, td_info->skb_dma[i],
-					td_info->skb->len, PCI_DMA_TODEVICE);
+				dma_unmap_single(vptr->dev, td_info->skb_dma[i],
+					td_info->skb->len, DMA_TO_DEVICE);
 				td_info->skb_dma[i] = 0;
 			}
 		}
@@ -2027,7 +2027,6 @@ static inline void velocity_iph_realign(struct velocity_info *vptr,
  */
 static int velocity_receive_frame(struct velocity_info *vptr, int idx)
 {
-	void (*pci_action)(struct pci_dev *, dma_addr_t, size_t, int);
 	struct net_device_stats *stats = &vptr->netdev->stats;
 	struct velocity_rd_info *rd_info = &(vptr->rx.info[idx]);
 	struct rx_desc *rd = &(vptr->rx.ring[idx]);
@@ -2045,8 +2044,8 @@ static int velocity_receive_frame(struct velocity_info *vptr, int idx)
 
 	skb = rd_info->skb;
 
-	pci_dma_sync_single_for_cpu(vptr->pdev, rd_info->skb_dma,
-				    vptr->rx.buf_sz, PCI_DMA_FROMDEVICE);
+	dma_sync_single_for_cpu(vptr->dev, rd_info->skb_dma,
+				    vptr->rx.buf_sz, DMA_FROM_DEVICE);
 
 	/*
 	 *	Drop frame not meeting IEEE 802.3
@@ -2059,19 +2058,18 @@ static int velocity_receive_frame(struct velocity_info *vptr, int idx)
 		}
 	}
 
-	pci_action = pci_dma_sync_single_for_device;
-
 	velocity_rx_csum(rd, skb);
 
 	if (velocity_rx_copy(&skb, pkt_len, vptr) < 0) {
 		velocity_iph_realign(vptr, skb, pkt_len);
-		pci_action = pci_unmap_single;
 		rd_info->skb = NULL;
+		dma_unmap_single(vptr->dev, rd_info->skb_dma, vptr->rx.buf_sz,
+				 DMA_FROM_DEVICE);
+	} else {
+		dma_sync_single_for_device(vptr->dev, rd_info->skb_dma,
+					   vptr->rx.buf_sz, DMA_FROM_DEVICE);
 	}
 
-	pci_action(vptr->pdev, rd_info->skb_dma, vptr->rx.buf_sz,
-		   PCI_DMA_FROMDEVICE);
-
 	skb_put(skb, pkt_len - 4);
 	skb->protocol = eth_type_trans(skb, vptr->netdev);
 
@@ -2548,7 +2546,8 @@ static netdev_tx_t velocity_xmit(struct sk_buff *skb,
 	 *	add it to the transmit ring.
 	 */
 	tdinfo->skb = skb;
-	tdinfo->skb_dma[0] = pci_map_single(vptr->pdev, skb->data, pktlen, PCI_DMA_TODEVICE);
+	tdinfo->skb_dma[0] = dma_map_single(vptr->dev, skb->data, pktlen,
+								DMA_TO_DEVICE);
 	td_ptr->tdesc0.len = cpu_to_le16(pktlen);
 	td_ptr->td_buf[0].pa_low = cpu_to_le32(tdinfo->skb_dma[0]);
 	td_ptr->td_buf[0].pa_high = 0;
@@ -2558,7 +2557,7 @@ static netdev_tx_t velocity_xmit(struct sk_buff *skb,
 	for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) {
 		const skb_frag_t *frag = &skb_shinfo(skb)->frags[i];
 
-		tdinfo->skb_dma[i + 1] = skb_frag_dma_map(&vptr->pdev->dev,
+		tdinfo->skb_dma[i + 1] = skb_frag_dma_map(vptr->dev,
 							  frag, 0,
 							  skb_frag_size(frag),
 							  DMA_TO_DEVICE);
@@ -2635,6 +2634,7 @@ static void velocity_init_info(struct pci_dev *pdev, struct velocity_info *vptr,
 {
 	memset(vptr, 0, sizeof(struct velocity_info));
 
+	vptr->dev = &pdev->dev;
 	vptr->pdev = pdev;
 	vptr->chip_id = info->chip_id;
 	vptr->tx.numq = info->txqueue;
@@ -2742,7 +2742,6 @@ static int velocity_found1(struct pci_dev *pdev,
 	SET_NETDEV_DEV(dev, &pdev->dev);
 	vptr = netdev_priv(dev);
 
-
 	if (first) {
 		printk(KERN_INFO "%s Ver. %s\n",
 			VELOCITY_FULL_DRV_NAM, VELOCITY_VERSION);
diff --git a/drivers/net/ethernet/via/via-velocity.h b/drivers/net/ethernet/via/via-velocity.h
index ff8d7828..c38bbae 100644
--- a/drivers/net/ethernet/via/via-velocity.h
+++ b/drivers/net/ethernet/via/via-velocity.h
@@ -1434,6 +1434,7 @@ struct velocity_opt {
 #define GET_RD_BY_IDX(vptr, idx)   (vptr->rd_ring[idx])
 
 struct velocity_info {
+	struct device *dev;
 	struct pci_dev *pdev;
 	struct net_device *netdev;
 
-- 
1.7.9.5



From linux at prisktech.co.nz  Sat Apr 27 23:16:46 2013
From: linux at prisktech.co.nz (Tony Prisk)
Date: Sun, 28 Apr 2013 15:16:46 +1200
Subject: [PATCH 4/4] net: velocity: Add platform device support to VIA
 velocity driver
In-Reply-To: <1367119006-31280-1-git-send-email-linux@prisktech.co.nz>
References: <1367119006-31280-1-git-send-email-linux@prisktech.co.nz>
Message-ID: <1367119006-31280-5-git-send-email-linux@prisktech.co.nz>

Add support for the VIA Velocity network driver to be bound to a
OF created platform device.

Signed-off-by: Tony Prisk <linux at prisktech.co.nz>
---
 .../devicetree/bindings/net/via-velocity.txt       |   20 +
 drivers/net/ethernet/via/Kconfig                   |    3 +-
 drivers/net/ethernet/via/via-velocity.c            |  453 +++++++++++++++-----
 drivers/net/ethernet/via/via-velocity.h            |   30 +-
 4 files changed, 398 insertions(+), 108 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/net/via-velocity.txt

diff --git a/Documentation/devicetree/bindings/net/via-velocity.txt b/Documentation/devicetree/bindings/net/via-velocity.txt
new file mode 100644
index 0000000..b3db469
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/via-velocity.txt
@@ -0,0 +1,20 @@
+* VIA Velocity 10/100/1000 Network Controller
+
+Required properties:
+- compatible : Should be "via,velocity-vt6110"
+- reg : Address and length of the io space
+- interrupts : Should contain the controller interrupt line
+
+Optional properties:
+- no-eeprom : PCI network cards use an external EEPROM to store data. Embedded
+	devices quite often set this data in uboot and do not provide an eeprom.
+	Specify this option if you have no external eeprom.
+
+Examples:
+
+eth0 at d8004000 {
+	compatible = "via,velocity-vt6110";
+	reg = <0xd8004000 0x400>;
+	interrupts = <10>;
+	no-eeprom;
+};
diff --git a/drivers/net/ethernet/via/Kconfig b/drivers/net/ethernet/via/Kconfig
index 68a9ba6..6a87097 100644
--- a/drivers/net/ethernet/via/Kconfig
+++ b/drivers/net/ethernet/via/Kconfig
@@ -5,7 +5,6 @@
 config NET_VENDOR_VIA
 	bool "VIA devices"
 	default y
-	depends on PCI
 	---help---
 	  If you have a network (Ethernet) card belonging to this class, say Y
 	  and read the Ethernet-HOWTO, available from
@@ -45,7 +44,7 @@ config VIA_RHINE_MMIO
 
 config VIA_VELOCITY
 	tristate "VIA Velocity support"
-	depends on PCI
+	depends on (PCI || USE_OF)
 	select CRC32
 	select CRC_CCITT
 	select NET_CORE
diff --git a/drivers/net/ethernet/via/via-velocity.c b/drivers/net/ethernet/via/via-velocity.c
index a5fe892..f4b5ff1 100644
--- a/drivers/net/ethernet/via/via-velocity.c
+++ b/drivers/net/ethernet/via/via-velocity.c
@@ -65,7 +65,11 @@
 #include <linux/mm.h>
 #include <linux/module.h>
 #include <linux/netdevice.h>
+#include <linux/of_address.h>
+#include <linux/of_device.h>
+#include <linux/of_irq.h>
 #include <linux/pci.h>
+#include <linux/platform_device.h>
 #include <linux/proc_fs.h>
 #include <linux/reboot.h>
 #include <linux/skbuff.h>
@@ -84,6 +88,16 @@
 static int velocity_nics;
 static int msglevel = MSG_LEVEL_INFO;
 
+static void velocity_set_power_state(struct velocity_info *vptr, char state)
+{
+	void *addr = vptr->mac_regs;
+
+	if (vptr->bustype == BUS_PCI)
+		pci_set_power_state(vptr->pdev, state);
+	else
+		writeb(state, addr + 0x154);
+}
+
 /**
  *	mac_get_cam_mask	-	Read a CAM mask
  *	@regs: register block for this velocity
@@ -362,12 +376,24 @@ static struct velocity_info_tbl chip_info_table[] = {
  *	Describe the PCI device identifiers that we support in this
  *	device driver. Used for hotplug autoloading.
  */
-static DEFINE_PCI_DEVICE_TABLE(velocity_id_table) = {
+#ifdef CONFIG_PCI
+static DEFINE_PCI_DEVICE_TABLE(velocity_pci_id_table) = {
 	{ PCI_DEVICE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_612X) },
 	{ }
 };
 
-MODULE_DEVICE_TABLE(pci, velocity_id_table);
+MODULE_DEVICE_TABLE(pci, velocity_pci_id_table);
+#endif
+
+/**
+ *	Describe the OF device identifiers that we support in this
+ *	device driver. Used for devicetree nodes.
+ */
+static struct of_device_id velocity_of_ids[] = {
+	{ .compatible = "via,velocity-vt6110", .data = &chip_info_table[0] },
+	{ /* Sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, velocity_of_ids);
 
 /**
  *	get_chip_name	- 	identifier to name
@@ -386,29 +412,6 @@ static const char *get_chip_name(enum chip_type chip_id)
 }
 
 /**
- *	velocity_remove1	-	device unplug
- *	@pdev: PCI device being removed
- *
- *	Device unload callback. Called on an unplug or on module
- *	unload for each active device that is present. Disconnects
- *	the device from the network layer and frees all the resources
- */
-static void velocity_remove1(struct pci_dev *pdev)
-{
-	struct net_device *dev = pci_get_drvdata(pdev);
-	struct velocity_info *vptr = netdev_priv(dev);
-
-	unregister_netdev(dev);
-	iounmap(vptr->mac_regs);
-	pci_release_regions(pdev);
-	pci_disable_device(pdev);
-	pci_set_drvdata(pdev, NULL);
-	free_netdev(dev);
-
-	velocity_nics--;
-}
-
-/**
  *	velocity_set_int_opt	-	parser for integer options
  *	@opt: pointer to option value
  *	@val: value the user requested (or -1 for default)
@@ -1179,6 +1182,14 @@ static void mii_init(struct velocity_info *vptr, u32 mii_status)
 	u16 BMCR;
 
 	switch (PHYID_GET_PHY_ID(vptr->phy_id)) {
+	case PHYID_ICPLUS_IP101A:
+		MII_REG_BITS_OFF((ADVERTISE_PAUSE_ASYM | ADVERTISE_PAUSE_CAP), MII_ADVERTISE, vptr->mac_regs);
+		if (vptr->mii_status & VELOCITY_DUPLEX_FULL)
+			MII_REG_BITS_ON(TCSR_ECHODIS, MII_SREVISION, vptr->mac_regs);
+		else
+			MII_REG_BITS_OFF(TCSR_ECHODIS, MII_SREVISION, vptr->mac_regs);
+		MII_REG_BITS_ON(PLED_LALBE, MII_TPISTATUS, vptr->mac_regs);
+		break;
 	case PHYID_CICADA_CS8201:
 		/*
 		 *	Reset to hardware default
@@ -1351,9 +1362,12 @@ static void velocity_init_registers(struct velocity_info *vptr,
 		velocity_soft_reset(vptr);
 		mdelay(5);
 
-		mac_eeprom_reload(regs);
-		for (i = 0; i < 6; i++)
-			writeb(vptr->netdev->dev_addr[i], &(regs->PAR[i]));
+		if (!vptr->no_eeprom) {
+			mac_eeprom_reload(regs);
+			for (i = 0; i < 6; i++)
+				writeb(vptr->netdev->dev_addr[i],
+							&(regs->PAR[i]));
+		}
 
 		/*
 		 *	clear Pre_ACPI bit.
@@ -2231,15 +2245,15 @@ static int velocity_open(struct net_device *dev)
 		goto out;
 
 	/* Ensure chip is running */
-	pci_set_power_state(vptr->pdev, PCI_D0);
+	velocity_set_power_state(vptr, PCI_D0);
 
 	velocity_init_registers(vptr, VELOCITY_INIT_COLD);
 
-	ret = request_irq(vptr->pdev->irq, velocity_intr, IRQF_SHARED,
+	ret = request_irq(dev->irq, velocity_intr, IRQF_SHARED,
 			  dev->name, dev);
 	if (ret < 0) {
 		/* Power down the chip */
-		pci_set_power_state(vptr->pdev, PCI_D3hot);
+		velocity_set_power_state(vptr, PCI_D3hot);
 		velocity_free_rings(vptr);
 		goto out;
 	}
@@ -2411,7 +2425,7 @@ static int velocity_ioctl(struct net_device *dev, struct ifreq *rq, int cmd)
 	   saving then we need to bring the device back up to talk to it */
 
 	if (!netif_running(dev))
-		pci_set_power_state(vptr->pdev, PCI_D0);
+		velocity_set_power_state(vptr, PCI_D0);
 
 	switch (cmd) {
 	case SIOCGMIIPHY:	/* Get address of MII PHY in use. */
@@ -2424,7 +2438,7 @@ static int velocity_ioctl(struct net_device *dev, struct ifreq *rq, int cmd)
 		ret = -EOPNOTSUPP;
 	}
 	if (!netif_running(dev))
-		pci_set_power_state(vptr->pdev, PCI_D3hot);
+		velocity_set_power_state(vptr, PCI_D3hot);
 
 
 	return ret;
@@ -2490,7 +2504,7 @@ static int velocity_close(struct net_device *dev)
 	if (vptr->flags & VELOCITY_FLAGS_WOL_ENABLED)
 		velocity_get_ip(vptr);
 
-	free_irq(vptr->pdev->irq, dev);
+	free_irq(dev->irq, dev);
 
 	velocity_free_rings(vptr);
 
@@ -2629,13 +2643,25 @@ static const struct net_device_ops velocity_netdev_ops = {
  *	Set up the initial velocity_info struct for the device that has been
  *	discovered.
  */
-static void velocity_init_info(struct pci_dev *pdev, struct velocity_info *vptr,
-			       const struct velocity_info_tbl *info)
+static void velocity_init_info(void *pdev,
+				struct velocity_info *vptr,
+				const struct velocity_info_tbl *info,
+				enum velocity_bus_type bustype)
 {
+	struct pci_dev *pci_dev;
+	struct platform_device *platform_dev;
+
 	memset(vptr, 0, sizeof(struct velocity_info));
 
-	vptr->dev = &pdev->dev;
-	vptr->pdev = pdev;
+	if (bustype == BUS_PCI) {
+		pci_dev = pdev;
+		vptr->pdev = pci_dev;
+		vptr->dev = &pci_dev->dev;
+	} else {
+		platform_dev = pdev;
+		vptr->dev = &platform_dev->dev;
+	}
+
 	vptr->chip_id = info->chip_id;
 	vptr->tx.numq = info->txqueue;
 	vptr->multicast_limit = MCAM_SIZE;
@@ -2653,8 +2679,6 @@ static void velocity_init_info(struct pci_dev *pdev, struct velocity_info *vptr,
 static int velocity_get_pci_info(struct velocity_info *vptr,
 				 struct pci_dev *pdev)
 {
-	vptr->rev_id = pdev->revision;
-
 	pci_set_master(pdev);
 
 	vptr->ioaddr = pci_resource_start(pdev, 0);
@@ -2676,12 +2700,45 @@ static int velocity_get_pci_info(struct velocity_info *vptr,
 		dev_err(&pdev->dev, "region #1 is too small.\n");
 		return -EINVAL;
 	}
+
 	vptr->pdev = pdev;
 
 	return 0;
 }
 
 /**
+ *	velocity_get_platform_info - retrieve platform info for device
+ *	@vptr: velocity device
+ *	@pdev: platform device it matches
+ *
+ *	Retrieve the Platform configuration data that interests us
+ */
+static int velocity_get_platform_info(struct velocity_info *vptr,
+					struct platform_device *pdev)
+{
+	int ret;
+	struct resource res;
+
+	if (of_get_property(pdev->dev.of_node, "no-eeprom", NULL))
+		vptr->no_eeprom = 1;
+
+	ret = of_address_to_resource(pdev->dev.of_node, 0, &res);
+	if (ret) {
+		dev_err(&pdev->dev, "unable to find memory address\n");
+		return ret;
+	}
+
+	vptr->memaddr = res.start;
+
+	if (resource_size(&res) < VELOCITY_IO_SIZE) {
+		dev_err(&pdev->dev, "memory region is too small.\n");
+		return -EINVAL;
+	}
+
+	return 0;
+}
+
+/**
  *	velocity_print_info	-	per driver data
  *	@vptr: velocity
  *
@@ -2705,42 +2762,59 @@ static u32 velocity_get_link(struct net_device *dev)
 }
 
 /**
- *	velocity_found1		-	set up discovered velocity card
+ *	velocity_probe - set up discovered velocity device
  *	@pdev: PCI device
  *	@ent: PCI device table entry that matched
+ *	@bustype: bus that device is connected to
  *
  *	Configure a discovered adapter from scratch. Return a negative
  *	errno error code on failure paths.
  */
-static int velocity_found1(struct pci_dev *pdev,
-			   const struct pci_device_id *ent)
+static int velocity_probe(void *pdev,
+			   const struct pci_device_id *ent,
+			   enum velocity_bus_type bustype)
 {
 	static int first = 1;
-	struct net_device *dev;
+	struct pci_dev *pci_dev = NULL;
+	struct platform_device *platform_dev = NULL;
+	struct net_device *netdev;
+	struct device *dev;
+	const struct of_device_id *of_id;
 	int i;
 	const char *drv_string;
-	const struct velocity_info_tbl *info = &chip_info_table[ent->driver_data];
+	const struct velocity_info_tbl *info;
 	struct velocity_info *vptr;
 	struct mac_regs __iomem *regs;
+	int pci = (bustype == BUS_PCI) ? 1 : 0;
 	int ret = -ENOMEM;
 
+	if (pci) {
+		pci_dev = pdev;
+		dev = &pci_dev->dev;
+		info = &chip_info_table[ent->driver_data];
+	} else {
+		platform_dev = pdev;
+		dev = &platform_dev->dev;
+		of_id = of_match_device(velocity_of_ids, dev);
+		info = of_id->data;
+	}
+
 	/* FIXME: this driver, like almost all other ethernet drivers,
 	 * can support more than MAX_UNITS.
 	 */
 	if (velocity_nics >= MAX_UNITS) {
-		dev_notice(&pdev->dev, "already found %d NICs.\n",
-			   velocity_nics);
+		dev_notice(dev, "already found %d NICs.\n", velocity_nics);
 		return -ENODEV;
 	}
 
-	dev = alloc_etherdev(sizeof(struct velocity_info));
-	if (!dev)
+	netdev = alloc_etherdev(sizeof(struct velocity_info));
+	if (!netdev)
 		goto out;
 
 	/* Chain it all together */
 
-	SET_NETDEV_DEV(dev, &pdev->dev);
-	vptr = netdev_priv(dev);
+	SET_NETDEV_DEV(netdev, dev);
+	vptr = netdev_priv(netdev);
 
 	if (first) {
 		printk(KERN_INFO "%s Ver. %s\n",
@@ -2750,26 +2824,42 @@ static int velocity_found1(struct pci_dev *pdev,
 		first = 0;
 	}
 
-	velocity_init_info(pdev, vptr, info);
+	velocity_init_info(pdev, vptr, info, bustype);
+	vptr->bustype = bustype;
+	vptr->netdev = netdev;
 
-	vptr->netdev = dev;
-
-	ret = pci_enable_device(pdev);
-	if (ret < 0)
-		goto err_free_dev;
+	if (pci) {
+		ret = pci_enable_device(pci_dev);
+		if (ret < 0)
+			goto err_free_dev;
+		netdev->irq = pci_dev->irq;
+	} else {
+		netdev->irq =
+			irq_of_parse_and_map(platform_dev->dev.of_node, 0);
 
-	ret = velocity_get_pci_info(vptr, pdev);
-	if (ret < 0) {
-		/* error message already printed */
-		goto err_disable;
+		if (!netdev->irq) {
+			ret = -EINVAL;
+			goto err_free_dev;
+		}
 	}
 
-	ret = pci_request_regions(pdev, VELOCITY_NAME);
-	if (ret < 0) {
-		dev_err(&pdev->dev, "No PCI resources.\n");
-		goto err_disable;
+	if (pci) {
+		ret = velocity_get_pci_info(vptr, pci_dev);
+		if (ret < 0)
+			goto err_disable;
+
+		ret = pci_request_regions(pci_dev, VELOCITY_NAME);
+		if (ret < 0) {
+			dev_err(dev, "No PCI resources.\n");
+			goto err_disable;
+		}
+	} else {
+		ret = velocity_get_platform_info(vptr, platform_dev);
+		if (ret < 0)
+			goto err_disable;
 	}
 
+
 	regs = ioremap(vptr->memaddr, VELOCITY_IO_SIZE);
 	if (regs == NULL) {
 		ret = -EIO;
@@ -2778,13 +2868,18 @@ static int velocity_found1(struct pci_dev *pdev,
 
 	vptr->mac_regs = regs;
 
+	if (pci)
+		vptr->rev_id = pci_dev->revision;
+	else
+		vptr->rev_id = readb(&regs->CR0Set);
+
 	mac_wol_reset(regs);
 
 	for (i = 0; i < 6; i++)
-		dev->dev_addr[i] = readb(&regs->PAR[i]);
+		netdev->dev_addr[i] = readb(&regs->PAR[i]);
 
 
-	drv_string = dev_driver_string(&pdev->dev);
+	drv_string = dev_driver_string(dev);
 
 	velocity_get_options(&vptr->options, velocity_nics, drv_string);
 
@@ -2805,29 +2900,32 @@ static int velocity_found1(struct pci_dev *pdev,
 
 	vptr->phy_id = MII_GET_PHY_ID(vptr->mac_regs);
 
-	dev->netdev_ops = &velocity_netdev_ops;
-	dev->ethtool_ops = &velocity_ethtool_ops;
-	netif_napi_add(dev, &vptr->napi, velocity_poll, VELOCITY_NAPI_WEIGHT);
+	netdev->netdev_ops = &velocity_netdev_ops;
+	netdev->ethtool_ops = &velocity_ethtool_ops;
+	netif_napi_add(netdev, &vptr->napi, velocity_poll, VELOCITY_NAPI_WEIGHT);
 
-	dev->hw_features = NETIF_F_IP_CSUM | NETIF_F_SG | NETIF_F_HW_VLAN_TX;
-	dev->features |= NETIF_F_HW_VLAN_TX | NETIF_F_HW_VLAN_FILTER |
+	netdev->hw_features = NETIF_F_IP_CSUM | NETIF_F_SG | NETIF_F_HW_VLAN_TX;
+	netdev->features |= NETIF_F_HW_VLAN_TX | NETIF_F_HW_VLAN_FILTER |
 		NETIF_F_HW_VLAN_RX | NETIF_F_IP_CSUM;
 
-	ret = register_netdev(dev);
+	ret = register_netdev(netdev);
 	if (ret < 0)
 		goto err_iounmap;
 
-	if (!velocity_get_link(dev)) {
-		netif_carrier_off(dev);
+	if (!velocity_get_link(netdev)) {
+		netif_carrier_off(netdev);
 		vptr->mii_status |= VELOCITY_LINK_FAIL;
 	}
 
 	velocity_print_info(vptr);
-	pci_set_drvdata(pdev, dev);
+	if (pci)
+		pci_set_drvdata(pci_dev, netdev);
+	else
+		platform_set_drvdata(platform_dev, netdev);
 
 	/* and leave the chip powered down */
 
-	pci_set_power_state(pdev, PCI_D3hot);
+	velocity_set_power_state(vptr, PCI_D3hot);
 	velocity_nics++;
 out:
 	return ret;
@@ -2835,14 +2933,79 @@ out:
 err_iounmap:
 	iounmap(regs);
 err_release_res:
-	pci_release_regions(pdev);
+	if (pci)
+		pci_release_regions(pci_dev);
 err_disable:
-	pci_disable_device(pdev);
+	if (pci)
+		pci_disable_device(pci_dev);
 err_free_dev:
-	free_netdev(dev);
+	free_netdev(netdev);
 	goto out;
 }
 
+/**
+ *	velocity_remove	- device unplug
+ *	@pdev: PCI device being removed
+ *	@bustype: bus that device is connected to
+ *
+ *	Device unload callback. Called on an unplug or on module
+ *	unload for each active device that is present. Disconnects
+ *	the device from the network layer and frees all the resources
+ */
+static int velocity_remove(void *pdev, enum velocity_bus_type bustype)
+{
+	struct net_device *netdev;
+	struct velocity_info *vptr;
+	int pci = (bustype == BUS_PCI) ? 1 : 0;
+
+	if (pci)
+		netdev = pci_get_drvdata(pdev);
+	else
+		netdev = platform_get_drvdata(pdev);
+
+	vptr = netdev_priv(netdev);
+
+	unregister_netdev(netdev);
+	iounmap(vptr->mac_regs);
+
+	if (pci) {
+		pci_release_regions(pdev);
+		pci_disable_device(pdev);
+		pci_set_drvdata(pdev, NULL);
+	} else {
+		platform_set_drvdata(pdev, NULL);
+	}
+
+	free_netdev(netdev);
+
+	velocity_nics--;
+
+	return 0;
+}
+
+#ifdef CONFIG_PCI
+static int velocity_pci_probe(struct pci_dev *pdev,
+			   const struct pci_device_id *ent)
+{
+	return velocity_probe(pdev, ent, BUS_PCI);
+}
+
+static void velocity_pci_remove(struct pci_dev *pdev)
+{
+	velocity_remove(pdev, BUS_PCI);
+}
+#endif
+
+static int velocity_platform_probe(struct platform_device *pdev)
+{
+	return velocity_probe(pdev, NULL, BUS_PLATFORM);
+}
+
+static int velocity_platform_remove(struct platform_device *pdev)
+{
+	return velocity_remove(pdev, BUS_PLATFORM);
+}
+
 #ifdef CONFIG_PM
 /**
  *	wol_calc_crc		-	WOL CRC
@@ -3000,11 +3163,20 @@ static void velocity_save_context(struct velocity_info *vptr, struct velocity_co
 
 }
 
-static int velocity_suspend(struct pci_dev *pdev, pm_message_t state)
+static int velocity_suspend(void *pdev, pm_message_t state,
+					enum velocity_bus_type bustype)
 {
-	struct net_device *dev = pci_get_drvdata(pdev);
-	struct velocity_info *vptr = netdev_priv(dev);
+	struct net_device *netdev;
+	struct velocity_info *vptr;
 	unsigned long flags;
+	int pci = (bustype == BUS_PCI) ? 1 : 0;
+
+	if (pci)
+		netdev = pci_get_drvdata(pdev)
+	else
+		netdev = platform_get_drvdata(pdev);
+
+	vptr = netdev_priv(netdev);
 
 	if (!netif_running(vptr->netdev))
 		return 0;
@@ -3012,20 +3184,24 @@ static int velocity_suspend(struct pci_dev *pdev, pm_message_t state)
 	netif_device_detach(vptr->netdev);
 
 	spin_lock_irqsave(&vptr->lock, flags);
-	pci_save_state(pdev);
+	if (pci)
+		pci_save_state(pdev);
 
 	if (vptr->flags & VELOCITY_FLAGS_WOL_ENABLED) {
 		velocity_get_ip(vptr);
 		velocity_save_context(vptr, &vptr->context);
 		velocity_shutdown(vptr);
 		velocity_set_wol(vptr);
-		pci_enable_wake(pdev, PCI_D3hot, 1);
-		pci_set_power_state(pdev, PCI_D3hot);
+		if (pci)
+			pci_enable_wake(pdev, PCI_D3hot, 1);
+		velocity_set_power_state(vptr, PCI_D3hot);
 	} else {
 		velocity_save_context(vptr, &vptr->context);
 		velocity_shutdown(vptr);
-		pci_disable_device(pdev);
-		pci_set_power_state(pdev, pci_choose_state(pdev, state));
+		if (pci)
+			pci_disable_device(pdev);
+		velocity_set_power_state(vptr,
+					 velocity_choose_state(pdev, state));
 	}
 
 	spin_unlock_irqrestore(&vptr->lock, flags);
@@ -3067,19 +3243,30 @@ static void velocity_restore_context(struct velocity_info *vptr, struct velocity
 		writeb(*((u8 *) (context->mac_reg + i)), ptr + i);
 }
 
-static int velocity_resume(struct pci_dev *pdev)
+static int velocity_resume(void *pdev, enum velocity_bus_type bustype)
 {
-	struct net_device *dev = pci_get_drvdata(pdev);
-	struct velocity_info *vptr = netdev_priv(dev);
+	struct net_device *netdev;
+	struct velocity_info *vptr;
 	unsigned long flags;
+	int pci = (bustype == BUS_PCI) ? 1 : 0;
 	int i;
 
+	if (pci)
+		netdev = pci_get_devdata(pdev);
+	else
+		netdev = platform_get_drvdata(pdev);
+
+	vptr = netdev_priv(netdev);
+
 	if (!netif_running(vptr->netdev))
 		return 0;
 
-	pci_set_power_state(pdev, PCI_D0);
-	pci_enable_wake(pdev, 0, 0);
-	pci_restore_state(pdev);
+	velocity_set_power_state(vptr, PCI_D0);
+
+	if (pci) {
+		pci_enable_wake(pdev, 0, 0);
+		pci_restore_state(pdev);
+	}
 
 	mac_wol_reset(vptr->mac_regs);
 
@@ -3101,23 +3288,66 @@ static int velocity_resume(struct pci_dev *pdev)
 
 	return 0;
 }
+
+#ifdef CONFIG_PCI
+static int velocity_pci_suspend(struct pci_dev *pdev, pm_message_t state)
+{
+	return velocity_suspend(pdev, state, BUS_PCI);
+};
+
+static int velocity_pci_resume(struct pci_dev *pdev)
+{
+	return velocity_resume(pdev, BUS_PCI);
+};
 #endif
 
+static int velocity_platform_suspend(struct platform_device *pdev)
+{
+	return velocity_suspend(pdev, state, BUS_PLATFORM);
+}
+
+static int velocity_platform_resume(struct platform_device *pdev)
+{
+	return velocity_resume(pdev, BUS_PLATFORM);
+}
+
+static const struct dev_pm_ops velocity_platform_pm = {
+	.suspend        = velocity_platform_suspend,
+	.resume         = velocity_platform_resume,
+};
+
+#endif	/* !CONFIG_PM */
+
 /*
  *	Definition for our device driver. The PCI layer interface
  *	uses this to handle all our card discover and plugging
  */
-static struct pci_driver velocity_driver = {
+#ifdef CONFIG_PCI
+static struct pci_driver velocity_pci_driver = {
 	.name		= VELOCITY_NAME,
-	.id_table	= velocity_id_table,
-	.probe		= velocity_found1,
-	.remove		= velocity_remove1,
+	.id_table	= velocity_pci_id_table,
+	.probe		= velocity_pci_probe,
+	.remove		= velocity_pci_remove,
 #ifdef CONFIG_PM
-	.suspend	= velocity_suspend,
-	.resume		= velocity_resume,
+	.suspend	= velocity_pci_suspend,
+	.resume		= velocity_pci_resume,
 #endif
 };
+#endif
 
+static struct platform_driver velocity_platform_driver = {
+	.probe		= velocity_platform_probe,
+	.remove		= velocity_platform_remove,
+#ifdef CONFIG_PM
+	.suspend	= velocity_platform_suspend,
+	.resume		= velocity_platform_resume,
+#endif
+	.driver = {
+		.name = "via-velocity",
+		.owner = THIS_MODULE,
+		.of_match_table = velocity_of_ids,
+	},
+};
 
 /**
  *	velocity_ethtool_up	-	pre hook for ethtool
@@ -3130,7 +3360,7 @@ static int velocity_ethtool_up(struct net_device *dev)
 {
 	struct velocity_info *vptr = netdev_priv(dev);
 	if (!netif_running(dev))
-		pci_set_power_state(vptr->pdev, PCI_D0);
+		velocity_set_power_state(vptr, PCI_D0);
 	return 0;
 }
 
@@ -3145,7 +3375,7 @@ static void velocity_ethtool_down(struct net_device *dev)
 {
 	struct velocity_info *vptr = netdev_priv(dev);
 	if (!netif_running(dev))
-		pci_set_power_state(vptr->pdev, PCI_D3hot);
+		velocity_set_power_state(vptr, PCI_D3hot);
 }
 
 static int velocity_get_settings(struct net_device *dev,
@@ -3267,7 +3497,11 @@ static void velocity_get_drvinfo(struct net_device *dev, struct ethtool_drvinfo
 	struct velocity_info *vptr = netdev_priv(dev);
 	strlcpy(info->driver, VELOCITY_NAME, sizeof(info->driver));
 	strlcpy(info->version, VELOCITY_VERSION, sizeof(info->version));
-	strlcpy(info->bus_info, pci_name(vptr->pdev), sizeof(info->bus_info));
+	if (vptr->bustype == BUS_PCI)
+		strlcpy(info->bus_info, pci_name(vptr->pdev),
+						sizeof(info->bus_info));
+	else
+		strlcpy(info->bus_info, "platform", sizeof(info->bus_info));
 }
 
 static void velocity_ethtool_get_wol(struct net_device *dev, struct ethtool_wolinfo *wol)
@@ -3560,9 +3794,15 @@ static int __init velocity_init_module(void)
 	int ret;
 
 	velocity_register_notifier();
-	ret = pci_register_driver(&velocity_driver);
+#ifdef CONFIG_PCI
+	ret = pci_register_driver(&velocity_pci_driver);
 	if (ret < 0)
 		velocity_unregister_notifier();
+#endif
+	ret = platform_driver_register(&velocity_platform_driver);
+	if (ret < 0)
+		velocity_unregister_notifier();
+
 	return ret;
 }
 
@@ -3577,7 +3817,10 @@ static int __init velocity_init_module(void)
 static void __exit velocity_cleanup_module(void)
 {
 	velocity_unregister_notifier();
-	pci_unregister_driver(&velocity_driver);
+#ifdef CONFIG_PCI
+	pci_unregister_driver(&velocity_pci_driver);
+#endif
+	platform_driver_unregister(&velocity_platform_driver);
 }
 
 module_init(velocity_init_module);
diff --git a/drivers/net/ethernet/via/via-velocity.h b/drivers/net/ethernet/via/via-velocity.h
index c38bbae..7468765 100644
--- a/drivers/net/ethernet/via/via-velocity.h
+++ b/drivers/net/ethernet/via/via-velocity.h
@@ -1265,7 +1265,7 @@ struct velocity_context {
 #define PHYID_VT3216_64BIT  0x000FC600UL
 #define PHYID_MARVELL_1000  0x01410C50UL
 #define PHYID_MARVELL_1000S 0x01410C40UL
-
+#define PHYID_ICPLUS_IP101A 0x02430C54UL
 #define PHYID_REV_ID_MASK   0x0000000FUL
 
 #define PHYID_GET_PHY_ID(i)         ((i) & ~PHYID_REV_ID_MASK)
@@ -1433,10 +1433,38 @@ struct velocity_opt {
 
 #define GET_RD_BY_IDX(vptr, idx)   (vptr->rd_ring[idx])
 
+static inline char velocity_choose_state(struct device *dev,
+					   pm_message_t state)
+
+{
+	switch (state.event) {
+	case PM_EVENT_ON:
+		return PCI_D0;
+	case PM_EVENT_FREEZE:
+	case PM_EVENT_PRETHAW:
+		/* REVISIT both freeze and pre-thaw "should" use D0 */
+	case PM_EVENT_SUSPEND:
+	case PM_EVENT_HIBERNATE:
+		return PCI_D3hot;
+	default:
+		dev_info(dev, "unrecognized suspend event %d\n", state.event);
+		BUG();
+	}
+
+	return PCI_D0;
+}
+
+enum velocity_bus_type {
+	BUS_PCI,
+	BUS_PLATFORM,
+};
+
 struct velocity_info {
 	struct device *dev;
 	struct pci_dev *pdev;
 	struct net_device *netdev;
+	enum velocity_bus_type bustype;
+	int no_eeprom;
 
 	unsigned long active_vlans[BITS_TO_LONGS(VLAN_N_VID)];
 	u8 ip_addr[4];
-- 
1.7.9.5



From linux at prisktech.co.nz  Sat Apr 27 23:31:37 2013
From: linux at prisktech.co.nz (Tony Prisk)
Date: Sun, 28 Apr 2013 15:31:37 +1200
Subject: [PATCH 3/4] net: velocity: Convert to generic dma functions
In-Reply-To: <1367119006-31280-4-git-send-email-linux@prisktech.co.nz>
References: <1367119006-31280-1-git-send-email-linux@prisktech.co.nz>
 <1367119006-31280-4-git-send-email-linux@prisktech.co.nz>
Message-ID: <517C9819.6050005@prisktech.co.nz>

On 28/04/13 15:16, Tony Prisk wrote:
> Remove the pci_* dma functions and replace with the more generic
> versions.
>
> In preparation of adding platform support, a new struct device *dev
> is added to struct velocity_info which can be used by both the pci
> and platform code.
>
> Signed-off-by: Tony Prisk <linux at prisktech.co.nz>
> ---
>   drivers/net/ethernet/via/via-velocity.c |   51 +++++++++++++++----------------
>   drivers/net/ethernet/via/via-velocity.h |    1 +
>   2 files changed, 26 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/net/ethernet/via/via-velocity.c b/drivers/net/ethernet/via/via-velocity.c
> index 1168666..a5fe892 100644
> --- a/drivers/net/ethernet/via/via-velocity.c
> +++ b/drivers/net/ethernet/via/via-velocity.c
> @@ -46,6 +46,7 @@
>   #include <linux/crc-ccitt.h>
>   #include <linux/crc32.h>
>   #include <linux/delay.h>
> +#include <linux/dma-mapping.h>
>   #include <linux/errno.h>
>   #include <linux/etherdevice.h>
>   #include <linux/ethtool.h>
> @@ -1457,7 +1458,6 @@ static int velocity_init_dma_rings(struct velocity_info *vptr)
>   	struct velocity_opt *opt = &vptr->options;
>   	const unsigned int rx_ring_size = opt->numrx * sizeof(struct rx_desc);
>   	const unsigned int tx_ring_size = opt->numtx * sizeof(struct tx_desc);
> -	struct pci_dev *pdev = vptr->pdev;
>   	dma_addr_t pool_dma;
>   	void *pool;
>   	unsigned int i;
> @@ -1465,13 +1465,13 @@ static int velocity_init_dma_rings(struct velocity_info *vptr)
>   	/*
>   	 * Allocate all RD/TD rings a single pool.
>   	 *
> -	 * pci_alloc_consistent() fulfills the requirement for 64 bytes
> +	 * dma_alloc_coherent() fulfills the requirement for 64 bytes
>   	 * alignment
>   	 */
> -	pool = pci_alloc_consistent(pdev, tx_ring_size * vptr->tx.numq +
> -				    rx_ring_size, &pool_dma);
> +	pool = dma_alloc_coherent(vptr->dev, tx_ring_size * vptr->tx.numq +
> +				    rx_ring_size, &pool_dma, GFP_ATOMIC);
>   	if (!pool) {
> -		dev_err(&pdev->dev, "%s : DMA memory allocation failed.\n",
> +		dev_err(vptr->dev, "%s : DMA memory allocation failed.\n",
>   			vptr->netdev->name);
>   		return -ENOMEM;
>   	}
> @@ -1522,8 +1522,8 @@ static int velocity_alloc_rx_buf(struct velocity_info *vptr, int idx)
>   	 */
>   	skb_reserve(rd_info->skb,
>   			64 - ((unsigned long) rd_info->skb->data & 63));
> -	rd_info->skb_dma = pci_map_single(vptr->pdev, rd_info->skb->data,
> -					vptr->rx.buf_sz, PCI_DMA_FROMDEVICE);
> +	rd_info->skb_dma = dma_map_single(vptr->dev, rd_info->skb->data,
> +					vptr->rx.buf_sz, DMA_FROM_DEVICE);
>   
>   	/*
>   	 *	Fill in the descriptor to match
> @@ -1586,8 +1586,8 @@ static void velocity_free_rd_ring(struct velocity_info *vptr)
>   
>   		if (!rd_info->skb)
>   			continue;
> -		pci_unmap_single(vptr->pdev, rd_info->skb_dma, vptr->rx.buf_sz,
> -				 PCI_DMA_FROMDEVICE);
> +		dma_unmap_single(vptr->dev, rd_info->skb_dma, vptr->rx.buf_sz,
> +				 DMA_FROM_DEVICE);
>   		rd_info->skb_dma = 0;
>   
>   		dev_kfree_skb(rd_info->skb);
> @@ -1668,7 +1668,7 @@ static void velocity_free_dma_rings(struct velocity_info *vptr)
>   	const int size = vptr->options.numrx * sizeof(struct rx_desc) +
>   		vptr->options.numtx * sizeof(struct tx_desc) * vptr->tx.numq;
>   
> -	pci_free_consistent(vptr->pdev, size, vptr->rx.ring, vptr->rx.pool_dma);
> +	dma_free_coherent(vptr->dev, size, vptr->rx.ring, vptr->rx.pool_dma);
>   }
>   
>   static int velocity_init_rings(struct velocity_info *vptr, int mtu)
> @@ -1725,8 +1725,8 @@ static void velocity_free_tx_buf(struct velocity_info *vptr,
>   				pktlen = max_t(size_t, pktlen,
>   						td->td_buf[i].size & ~TD_QUEUE);
>   
> -			pci_unmap_single(vptr->pdev, tdinfo->skb_dma[i],
> -					le16_to_cpu(pktlen), PCI_DMA_TODEVICE);
> +			dma_unmap_single(vptr->dev, tdinfo->skb_dma[i],
> +					le16_to_cpu(pktlen), DMA_TO_DEVICE);
>   		}
>   	}
>   	dev_kfree_skb_irq(skb);
> @@ -1748,8 +1748,8 @@ static void velocity_free_td_ring_entry(struct velocity_info *vptr,
>   	if (td_info->skb) {
>   		for (i = 0; i < td_info->nskb_dma; i++) {
>   			if (td_info->skb_dma[i]) {
> -				pci_unmap_single(vptr->pdev, td_info->skb_dma[i],
> -					td_info->skb->len, PCI_DMA_TODEVICE);
> +				dma_unmap_single(vptr->dev, td_info->skb_dma[i],
> +					td_info->skb->len, DMA_TO_DEVICE);
>   				td_info->skb_dma[i] = 0;
>   			}
>   		}
> @@ -2027,7 +2027,6 @@ static inline void velocity_iph_realign(struct velocity_info *vptr,
>    */
>   static int velocity_receive_frame(struct velocity_info *vptr, int idx)
>   {
> -	void (*pci_action)(struct pci_dev *, dma_addr_t, size_t, int);
>   	struct net_device_stats *stats = &vptr->netdev->stats;
>   	struct velocity_rd_info *rd_info = &(vptr->rx.info[idx]);
>   	struct rx_desc *rd = &(vptr->rx.ring[idx]);
> @@ -2045,8 +2044,8 @@ static int velocity_receive_frame(struct velocity_info *vptr, int idx)
>   
>   	skb = rd_info->skb;
>   
> -	pci_dma_sync_single_for_cpu(vptr->pdev, rd_info->skb_dma,
> -				    vptr->rx.buf_sz, PCI_DMA_FROMDEVICE);
> +	dma_sync_single_for_cpu(vptr->dev, rd_info->skb_dma,
> +				    vptr->rx.buf_sz, DMA_FROM_DEVICE);
>   
>   	/*
>   	 *	Drop frame not meeting IEEE 802.3
> @@ -2059,19 +2058,18 @@ static int velocity_receive_frame(struct velocity_info *vptr, int idx)
>   		}
>   	}
>   
> -	pci_action = pci_dma_sync_single_for_device;
> -
>   	velocity_rx_csum(rd, skb);
>   
>   	if (velocity_rx_copy(&skb, pkt_len, vptr) < 0) {
>   		velocity_iph_realign(vptr, skb, pkt_len);
> -		pci_action = pci_unmap_single;
>   		rd_info->skb = NULL;
> +		dma_unmap_single(vptr->dev, rd_info->skb_dma, vptr->rx.buf_sz,
> +				 DMA_FROM_DEVICE);
> +	} else {
> +		dma_sync_single_for_device(vptr->dev, rd_info->skb_dma,
> +					   vptr->rx.buf_sz, DMA_FROM_DEVICE);
>   	}
>   
> -	pci_action(vptr->pdev, rd_info->skb_dma, vptr->rx.buf_sz,
> -		   PCI_DMA_FROMDEVICE);
> -
>   	skb_put(skb, pkt_len - 4);
>   	skb->protocol = eth_type_trans(skb, vptr->netdev);
>   
> @@ -2548,7 +2546,8 @@ static netdev_tx_t velocity_xmit(struct sk_buff *skb,
>   	 *	add it to the transmit ring.
>   	 */
>   	tdinfo->skb = skb;
> -	tdinfo->skb_dma[0] = pci_map_single(vptr->pdev, skb->data, pktlen, PCI_DMA_TODEVICE);
> +	tdinfo->skb_dma[0] = dma_map_single(vptr->dev, skb->data, pktlen,
> +								DMA_TO_DEVICE);
>   	td_ptr->tdesc0.len = cpu_to_le16(pktlen);
>   	td_ptr->td_buf[0].pa_low = cpu_to_le32(tdinfo->skb_dma[0]);
>   	td_ptr->td_buf[0].pa_high = 0;
> @@ -2558,7 +2557,7 @@ static netdev_tx_t velocity_xmit(struct sk_buff *skb,
>   	for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) {
>   		const skb_frag_t *frag = &skb_shinfo(skb)->frags[i];
>   
> -		tdinfo->skb_dma[i + 1] = skb_frag_dma_map(&vptr->pdev->dev,
> +		tdinfo->skb_dma[i + 1] = skb_frag_dma_map(vptr->dev,
>   							  frag, 0,
>   							  skb_frag_size(frag),
>   							  DMA_TO_DEVICE);
> @@ -2635,6 +2634,7 @@ static void velocity_init_info(struct pci_dev *pdev, struct velocity_info *vptr,
>   {
>   	memset(vptr, 0, sizeof(struct velocity_info));
>   
> +	vptr->dev = &pdev->dev;
>   	vptr->pdev = pdev;
>   	vptr->chip_id = info->chip_id;
>   	vptr->tx.numq = info->txqueue;
> @@ -2742,7 +2742,6 @@ static int velocity_found1(struct pci_dev *pdev,
>   	SET_NETDEV_DEV(dev, &pdev->dev);
>   	vptr = netdev_priv(dev);
>   
> -
>   	if (first) {
>   		printk(KERN_INFO "%s Ver. %s\n",
>   			VELOCITY_FULL_DRV_NAM, VELOCITY_VERSION);
> diff --git a/drivers/net/ethernet/via/via-velocity.h b/drivers/net/ethernet/via/via-velocity.h
> index ff8d7828..c38bbae 100644
> --- a/drivers/net/ethernet/via/via-velocity.h
> +++ b/drivers/net/ethernet/via/via-velocity.h
> @@ -1434,6 +1434,7 @@ struct velocity_opt {
>   #define GET_RD_BY_IDX(vptr, idx)   (vptr->rd_ring[idx])
>   
>   struct velocity_info {
> +	struct device *dev;
>   	struct pci_dev *pdev;
>   	struct net_device *netdev;
>   
I noticed I forgot to add the return value checking for the new 
functions - will do for v2.

Regards
Tony Prisk


From davem at davemloft.net  Sun Apr 28 01:21:50 2013
From: davem at davemloft.net (David Miller)
Date: Sun, 28 Apr 2013 01:21:50 -0400 (EDT)
Subject: [PATCH 1/4] net: velocity: Alphabetize #includes
In-Reply-To: <1367119006-31280-2-git-send-email-linux@prisktech.co.nz>
References: <1367119006-31280-1-git-send-email-linux@prisktech.co.nz>
 <1367119006-31280-2-git-send-email-linux@prisktech.co.nz>
Message-ID: <20130428.012150.495653742777974914.davem@davemloft.net>

From: Tony Prisk <linux at prisktech.co.nz>
Date: Sun, 28 Apr 2013 15:16:43 +1200

> Due to number of #includes, alphabetize them to help avoid duplicates.
> 
> Signed-off-by: Tony Prisk <linux at prisktech.co.nz>

Needless churn, I refuse to apply this.


From mturquette at linaro.org  Sun Apr 28 02:06:57 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Sat, 27 Apr 2013 23:06:57 -0700
Subject: [PATCH v2] clk: add clk_ignore_unused option to keep boot clocks
 on
In-Reply-To: <20130427211018.GA9376@quad.lixom.net>
References: <1367019591-31685-1-git-send-email-olof@lixom.net>
 <20130427211018.GA9376@quad.lixom.net>
Message-ID: <20130428060657.8923.73952@quantum>

Quoting Olof Johansson (2013-04-27 14:10:18)
> This is primarily useful when there's a driver that doesn't claim clocks
> properly, but the bootloader leaves them on. It's not expected to be used
> in normal cases, but for bringup and debug it's very useful to have the
> option to not gate unclaimed clocks that are still on.
> 
> Signed-off-by: Olof Johansson <olof at lixom.net>

Thanks for the respin.  I had to fix up a trivial merge issue with
Documentation/kernel-parameters.txt, but no big deal.  Patch is merged
into clk-next.

Regards,
Mike

> ---
>  Documentation/clk.txt               | 11 +++++++++++
>  Documentation/kernel-parameters.txt |  8 ++++++++
>  drivers/clk/clk.c                   | 13 +++++++++++++
>  3 files changed, 32 insertions(+)
> 
> diff --git a/Documentation/clk.txt b/Documentation/clk.txt
> index 4274a54..b9911c2 100644
> --- a/Documentation/clk.txt
> +++ b/Documentation/clk.txt
> @@ -231,3 +231,14 @@ To better enforce this policy, always follow this simple rule: any
>  statically initialized clock data MUST be defined in a separate file
>  from the logic that implements its ops.  Basically separate the logic
>  from the data and all is well.
> +
> +       Part 6 - Disabling clock gating of unused clocks
> +
> +Sometimes during development it can be useful to be able to bypass the
> +default disabling of unused clocks. For example, if drivers aren't enabling
> +clocks properly but rely on them being on from the bootloader, bypassing
> +the disabling means that the driver will remain functional while the issues
> +are sorted out.
> +
> +To bypass this disabling, include "clk_ignore_unused" in the bootargs to the
> +kernel.
> diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
> index c4fa000..c3bfacb 100644
> --- a/Documentation/kernel-parameters.txt
> +++ b/Documentation/kernel-parameters.txt
> @@ -44,6 +44,7 @@ parameter is applicable:
>         AVR32   AVR32 architecture is enabled.
>         AX25    Appropriate AX.25 support is enabled.
>         BLACKFIN Blackfin architecture is enabled.
> +       CLK     Common clock infrastructure is enabled.
>         CMA     Contiguous Memory Area support is enabled.
>         DRM     Direct Rendering Management support is enabled.
>         DYNAMIC_DEBUG Build in debug messages and enable them at runtime
> @@ -473,6 +474,13 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
>  
>         cio_ignore=     [S390]
>                         See Documentation/s390/CommonIO for details.
> +       clk_ignore_unused
> +                       [CLK]
> +                       Keep all clocks already enabled by bootloader on,
> +                       even if no driver has claimed them. This is useful
> +                       for debug and development, but should not be
> +                       needed on a platform with proper driver support.
> +                       For more information, see Documentation/clk.txt.
>  
>         clock=          [BUGS=X86-32, HW] gettimeofday clocksource override.
>                         [Deprecated]
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index 20ce67f..934cfd1 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -499,10 +499,23 @@ out:
>         return;
>  }
>  
> +static bool clk_ignore_unused;
> +static int __init clk_ignore_unused_setup(char *__unused)
> +{
> +       clk_ignore_unused = true;
> +       return 1;
> +}
> +__setup("clk_ignore_unused", clk_ignore_unused_setup);
> +
>  static int clk_disable_unused(void)
>  {
>         struct clk *clk;
>  
> +       if (clk_ignore_unused) {
> +               pr_warn("clk: Not disabling unused clocks\n");
> +               return 0;
> +       }
> +
>         clk_prepare_lock();
>  
>         hlist_for_each_entry(clk, &clk_root_list, child_node)
> -- 
> 1.8.1.192.gc4361b8


From kgene.kim at samsung.com  Sun Apr 28 02:33:40 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Sun, 28 Apr 2013 15:33:40 +0900
Subject: [PATCH] ARM: exynos: dts: cros5250: add EC device
In-Reply-To: <CAD=FV=VQg=2R_x11xuGiA0kNj1NXHUM3TUzVJC-F0ZWO39JRdw@mail.gmail.com>
References: <1367019745-31826-1-git-send-email-olof@lixom.net>
 <CAD=FV=WhoGO8=5pt=VOCT_2j2CMkn8on=N=jK_2RwMOXWat57w@mail.gmail.com>
 <20130427010406.GE2350@quad.lixom.net>
 <CAD=FV=VQg=2R_x11xuGiA0kNj1NXHUM3TUzVJC-F0ZWO39JRdw@mail.gmail.com>
Message-ID: <517CC2C4.4010809@samsung.com>

On 04/27/13 13:04, Doug Anderson wrote:
> Olof,
>
> On Fri, Apr 26, 2013 at 6:04 PM, Olof Johansson<olof at lixom.net>  wrote:
>> Ah, yes, of course. As discussed off-mail, I was mislead by some contents in
>> our local tree. :)
>
> Sorry about that--that was my fault.  Things have landed in a
> different order in one of our local trees.
>
>
>> Kukjin, I'd really like to pick up these patches for 3.10, since they're
>> isolated to just dts changes and gets keyboard working on the Chromebook. Can
>> you ack them and I'll just collect them this time?
>
> I'm pretty sure that Kukjin is OK with them.  Kukjin responded earlier and said:
>
Yes, right.

Olof, sorry for late, please go ahead with my ack if you want.

Acked-by: Kukjin Kim <kgene.kim at samsung.com>

- Kukjin

>> I'm fine on 2nd and 3rd patches. Shall I take only two patches without 1st
>> one in samsung tree?
>
> At the time we were waiting for Wolfram to get patch 1 into his tree,
> which is now done.
>
> ...but waiting for his official Ack is good, too.  ;)


From kgene.kim at samsung.com  Sun Apr 28 02:34:46 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Sun, 28 Apr 2013 15:34:46 +0900
Subject: [GIT PULL] Samsung fixes-1 for v3.10
In-Reply-To: <20130427010137.GD2350@quad.lixom.net>
References: <51795C62.8070500@samsung.com>
 <20130427010137.GD2350@quad.lixom.net>
Message-ID: <517CC306.6030508@samsung.com>

On 04/27/13 10:01, Olof Johansson wrote:
> On Fri, Apr 26, 2013 at 01:40:02AM +0900, Kukjin Kim wrote:
>> The following changes since commit 58a7bbf75442ea439a4d3b7993ad87023e406063:
>>
>>    ARM: dts: add PDMA0 changes for exynos5440 (2013-04-09 01:39:27 +0900)
>
> So these are fixes based on code that's already staged. We normally
> don't do that -- if you have a fix for a specific branch that introduced
> something, send a fresh pull request for that branch.
>
OK.

> Looks like Doug's fix is for the common clock framework branch, so I'll apply
> it to next/drivers. Thomas' is for the dt branch. I'll cherry-pick it onto
> next/dt2.
>
I'm fine. Thanks.

- Kukjin


From kgene.kim at samsung.com  Sun Apr 28 02:52:33 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Sun, 28 Apr 2013 15:52:33 +0900
Subject: [PATCH v3 00/13] ARM: EXYNOS: Fix Universal C210 support
In-Reply-To: <20130427003413.GA2350@quad.lixom.net>
References: <1366731994-7478-1-git-send-email-t.figa@samsung.com>
 <201304251646.28026.arnd@arndb.de> <20130427003413.GA2350@quad.lixom.net>
Message-ID: <517CC731.2050401@samsung.com>

On 04/27/13 09:34, Olof Johansson wrote:

[...]

>>> On Universal C210 board, both with and without DT:
>>>
>>> Tested-by: Tomasz Figa<t.figa at samsung.com>
>>
>> Reviewed-by: Arnd Bergmann<arnd at arndb.de>
>>
>> Olof, Kgene, I think we should have this one in 3.10 since it fixes
>> a regression. It looks bigger than it really is because I asked Tomasz
>> to do small patches rather than a single combined patch.
>
> Ok. Kukjin, I don't mind collecting this in a late/* branch even though time is
> running late, since it's a regression. Do you want to send it to me or should
> I just pick up the patches?
>
Olof, since too late, would be better if you could pick up this series 
in the late/* branch with my ack:

Acked-by: Kukjin Kim <kgene.kim at samsung.com>

Thanks.

- Kukjin


From kgene.kim at samsung.com  Sun Apr 28 02:55:01 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Sun, 28 Apr 2013 15:55:01 +0900
Subject: [PATCH] ARM: exynos: dts: cros5250: add cyapa trackpad
In-Reply-To: <CAD=FV=Xrud-0DE3VH=Dqf5ZkYLkegCk0j16bzjiEb-GsvhT2MA@mail.gmail.com>
References: <1367019681-31775-1-git-send-email-olof@lixom.net>
 <CAD=FV=Xrud-0DE3VH=Dqf5ZkYLkegCk0j16bzjiEb-GsvhT2MA@mail.gmail.com>
Message-ID: <517CC7C5.3010203@samsung.com>

On 04/27/13 09:08, Doug Anderson wrote:
> Olof,
>
> On Fri, Apr 26, 2013 at 4:41 PM, Olof Johansson<olof at lixom.net>  wrote:
>> Trivial patch, adding the i2c Cypress trackpad used on Snow.
>>
>> Signed-off-by: Olof Johansson<olof at lixom.net>
>> ---
>>
>> Kukjin, if you don't mind I'll just add this to arm-soc?
>>

Please go ahead with my ack:

Acked-by: Kukjin Kim <kgene.kim at samsung.com>

Thanks.

- Kukjin

>>
>> -Olof
>>
>>   arch/arm/boot/dts/cros5250-common.dtsi | 8 ++++++++
>>   1 file changed, 8 insertions(+)
>
> Looks good.
>
> Reviewed-by: Doug Anderson<dianders at chromium.org>


From kgene.kim at samsung.com  Sun Apr 28 03:09:07 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Sun, 28 Apr 2013 16:09:07 +0900
Subject: [GIT PULL] Late Samsung stuff (v3) for v3.10
In-Reply-To: <51795CE8.2060105@samsung.com>
References: <51795CE8.2060105@samsung.com>
Message-ID: <517CCB13.8060909@samsung.com>

On 04/26/13 01:42, Kukjin Kim wrote:
> The following changes since commit
> 59a7bbf75442ea439a4d3b7993ad87023e406063:
>
> ARM: dts: add PDMA0 changes for exynos5440 (2013-04-09 01:39:27 +0900)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
> tags/late-exynos-v3-for-v3.10
>
> for you to fetch changes up to 096ee6adcfb79a13ae04150023725c8a67e00ae8:
>
> ARM: dts: Add chip-id controller node on Exynos4/5 SoC (2013-04-26
> 01:21:44 +0900)
>
> ----------------------------------------------------------------
> This allows that device tree enables platform to setup a runtime IO
> mapping for the chip id
>
> ----------------------------------------------------------------
> Thomas Abraham (2):
> ARM: EXYNOS: Create virtual I/O mapping for Chip-ID controller using
> device tree
> ARM: dts: Add chip-id controller node on Exynos4/5 SoC
>
> arch/arm/boot/dts/exynos4.dtsi | 5 ++++
> arch/arm/boot/dts/exynos5250.dtsi | 5 ++++
> arch/arm/mach-exynos/common.c | 53 +++++++++++++++++++--------------
> arch/arm/mach-exynos/include/mach/map.h | 1 -
> 4 files changed, 40 insertions(+), 24 deletions(-)

Olof, this chip-id dt support patches is needed for exynos multi 
platform patches from Arnd. See below in detail.

<http://www.mail-archive.com/linux-samsung-soc at vger.kernel.org/msg17693.html>

If any concerns, please kindly let me know.

Thanks.

- Kukjin


From francescolavra.fl at gmail.com  Sun Apr 28 04:20:43 2013
From: francescolavra.fl at gmail.com (Francesco Lavra)
Date: Sun, 28 Apr 2013 10:20:43 +0200
Subject: [PATCH 10/14] sched: update the buddy CPU
In-Reply-To: <1366910611-20048-11-git-send-email-vincent.guittot@linaro.org>
References: <1366910611-20048-1-git-send-email-vincent.guittot@linaro.org>
 <1366910611-20048-11-git-send-email-vincent.guittot@linaro.org>
Message-ID: <517CDBDB.1020608@gmail.com>

Hi,

On 04/25/2013 07:23 PM, Vincent Guittot wrote:
> Periodically updates the buddy of a CPU according to the current activity of
> the system. A CPU is its own buddy if it participates to the packing effort.
> Otherwise, it points to a CPU that participates to the packing effort.
> 
> Signed-off-by: Vincent Guittot <vincent.guittot at linaro.org>
> ---
>  kernel/sched/fair.c |   91 ++++++++++++++++++++++++++++++++++++++++++++++++---
>  1 file changed, 86 insertions(+), 5 deletions(-)
> 
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 234ecdd..28f8ea7 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -174,11 +174,17 @@ void sched_init_granularity(void)
>  
>  
>  #ifdef CONFIG_SMP
> +static unsigned long power_of(int cpu)
> +{
> +	return cpu_rq(cpu)->cpu_power;
> +}
> +
>  /*
>   * Save the id of the optimal CPU that should be used to pack small tasks
>   * The value -1 is used when no buddy has been found
>   */
>  DEFINE_PER_CPU(int, sd_pack_buddy);
> +DEFINE_PER_CPU(struct sched_domain *, sd_pack_domain);
>  
>  /*
>   * Look for the best buddy CPU that can be used to pack small tasks
> @@ -237,6 +243,68 @@ void update_packing_domain(int cpu)
>  	}
>  
>  	pr_debug("CPU%d packing on CPU%d\n", cpu, id);
> +	per_cpu(sd_pack_domain, cpu) = sd;
> +	per_cpu(sd_pack_buddy, cpu) = id;
> +}
> +
> +void update_packing_buddy(int cpu, int activity)
> +{
> +	struct sched_domain *sd = per_cpu(sd_pack_domain, cpu);
> +	struct sched_group *sg, *pack, *tmp;
> +	int id = cpu;
> +
> +	if (!sd)
> +		return;
> +
> +	/*
> +	 * The sched_domain of a CPU points on the local sched_group
> +	 * and this CPU of this local group is a good candidate
> +	 */
> +	pack = sg = sd->groups;
> +
> +	/* loop the sched groups to find the best one */
> +	for (tmp = sg->next; tmp != sg; tmp = tmp->next) {
> +		if ((tmp->sgp->power * pack->group_weight) >
> +			(pack->sgp->power_available * tmp->group_weight))

The power_available struct member is defined in a subsequent patch
(12/14), so this patch series would break git bisect.

--
Francesco


From shawn.guo at linaro.org  Sun Apr 28 04:52:49 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Sun, 28 Apr 2013 16:52:49 +0800
Subject: [PATCH 1/2] ARM: dts: i.MX6: configure L2 cache data and tag
 latency
In-Reply-To: <1366964036-17275-1-git-send-email-dirk.behme@de.bosch.com>
References: <1366964036-17275-1-git-send-email-dirk.behme@de.bosch.com>
Message-ID: <20130428085248.GC1943@S2101-09.ap.freescale.net>

On Fri, Apr 26, 2013 at 10:13:55AM +0200, Dirk Behme wrote:
> Configure the data and tag latency for the L2 cache. This improves the
> system performance.
> 
> This configuration is taken from Freescale's kernel patch
> 
> "ENGR00153601 [MX6]Adjust L2 cache parameter" [1]
> 
> which does
> 
> writel(0x132, IO_ADDRESS(L2_BASE_ADDR + L2X0_TAG_LATENCY_CTRL));
> writel(0x132, IO_ADDRESS(L2_BASE_ADDR + L2X0_DATA_LATENCY_CTRL));
> 
> In this patch we are doing the same via the device tree.
> 
> Signed-off-by: Dirk Behme <dirk.behme at de.bosch.com>

Both applied, thanks.



From sebastian.hesselbarth at gmail.com  Sun Apr 28 04:56:28 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Sun, 28 Apr 2013 10:56:28 +0200
Subject: [PATCH 1/2] clk: si5351: Fix clkout rate computation.
In-Reply-To: <1366698170-31346-1-git-send-email-marek.belisko@streamunlimited.com>
References: <1366698170-31346-1-git-send-email-marek.belisko@streamunlimited.com>
Message-ID: <517CE43C.3080003@gmail.com>

On 04/23/2013 08:22 AM, Marek Belisko wrote:
> Rate was incorrectly computed because we read from wrong divider register.
>
> Signed-off-by: Marek Belisko<marek.belisko at streamunlimited.com>

Marek,

sorry for the late reply and very good catch!

Acked-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>

> ---
>   drivers/clk/clk-si5351.c |    2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/clk/clk-si5351.c b/drivers/clk/clk-si5351.c
> index 8927284..cf39e53 100644
> --- a/drivers/clk/clk-si5351.c
> +++ b/drivers/clk/clk-si5351.c
> @@ -932,7 +932,7 @@ static unsigned long si5351_clkout_recalc_rate(struct clk_hw *hw,
>   	unsigned char reg;
>   	unsigned char rdiv;
>
> -	if (hwdata->num>  5)
> +	if (hwdata->num<= 5)
>   		reg = si5351_msynth_params_address(hwdata->num) + 2;
>   	else
>   		reg = SI5351_CLK6_7_OUTPUT_DIVIDER;



From sebastian.hesselbarth at gmail.com  Sun Apr 28 04:59:41 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Sun, 28 Apr 2013 10:59:41 +0200
Subject: [PATCH 2/2] clk: si5351: Apply rate when clock-frequency is
 defined in devicetree.
In-Reply-To: <1366698170-31346-2-git-send-email-marek.belisko@streamunlimited.com>
References: <1366698170-31346-1-git-send-email-marek.belisko@streamunlimited.com>
 <1366698170-31346-2-git-send-email-marek.belisko@streamunlimited.com>
Message-ID: <517CE4FD.9010406@gmail.com>

On 04/23/2013 08:22 AM, Marek Belisko wrote:
> clock-frequency property from devicetree was read but never used. Apply
> defined rate when clock is registered.
>
> Signed-off-by: Marek Belisko<marek.belisko at streamunlimited.com>
> ---
>   drivers/clk/clk-si5351.c |   10 ++++++++++
>   1 file changed, 10 insertions(+)
>
> diff --git a/drivers/clk/clk-si5351.c b/drivers/clk/clk-si5351.c
> index cf39e53..8323c31 100644
> --- a/drivers/clk/clk-si5351.c
> +++ b/drivers/clk/clk-si5351.c
> @@ -1477,6 +1477,16 @@ static int si5351_i2c_probe(struct i2c_client *client,
>   			return -EINVAL;
>   		}
>   		drvdata->onecell.clks[n] = clk;
> +
> +		/* set rate when defined in devicetree */

nit: We also set the rate when it is defined in platform_data
(which is disabled because there is still some CONFIG_OF dependency).

Anyway, the above comment and patch subject should refer to platform
data instead.

If you can send an updated version of this patch you get my
Acked-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>

> +		if (pdata->clkout[n].rate != 0) {
> +			int ret;
> +			ret = clk_set_rate(clk, pdata->clkout[n].rate);
> +			if (ret != 0) {
> +				dev_err(&client->dev, "Cannot set rate : %d\n",
> +					ret);
> +			}
> +		}
>   	}
>
>   	ret = of_clk_add_provider(client->dev.of_node, of_clk_src_onecell_get,



From marc.zyngier at arm.com  Sun Apr 28 05:35:10 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Sun, 28 Apr 2013 11:35:10 +0200
Subject: [PATCH] ARM: KVM: Allow host virt timer irq to be different from
 guest timer virt irq
In-Reply-To: <CAAhSdy101B=4cK9nnLtQa7rG15D0CT_DsWD6k3FZ1EYz2nAfEw@mail.gmail.com>
References: <1367050086-2902-1-git-send-email-anup.patel@linaro.org>
 <73b473edb8a9ea9a09f1df68345903d7@localhost>
 <CAAhSdy101B=4cK9nnLtQa7rG15D0CT_DsWD6k3FZ1EYz2nAfEw@mail.gmail.com>
Message-ID: <459ddcd84aa2644e21efbbca56ff6870@localhost>

On Sat, 27 Apr 2013 17:49:31 +0530, Anup Patel <anup at brainfault.org>
wrote:
> On Sat, Apr 27, 2013 at 2:49 PM, Marc Zyngier <marc.zyngier at arm.com>
wrote:
>> On Sat, 27 Apr 2013 13:38:06 +0530, Anup Patel <anup.patel at linaro.org>
>> wrote:
>>> The arch_timer irq numbers (or PPI numbers) are implementation
dependent
>>> so, the host virtual timer irq number can be different from guest
>> virtual
>>> timer irq number.
>>>
>>> This patch ensures that host virtual timer irq number is read from DTB
>> and
>>> guest virtual timer irq is determined based on vcpu target type.

[...]

>>>
>>> +int kvm_timer_vcpu_reset(struct kvm_vcpu *vcpu,
>>> +                      const struct kvm_irq_level *irq)
>>> +{
>>> +     struct arch_timer_cpu *timer = &vcpu->arch.timer_cpu;
>>> +
>>> +     /*
>>> +      * The vcpu timer irq number cannot be determined in
>>> +      * kvm_timer_vcpu_init() because it is called much before
>>> +      * kvm_vcpu_set_target(). To handle this, we determine
>>> +      * vcpu timer irq number when the vcpu is resetted.
>>> +      */
>>> +     timer->irq = irq;
>>> +
>>> +     /*
>>> +      * Make sure timer is disarmed.
>>> +      */
>>> +     timer_disarm(timer);
>>
>> What is that for? Timer has not been started yet, for the lack of an
IRQ.
>> Actually, the vcpu has never ran. Why would you need to disarm it?
> 
> This is in case a vcpu is resetted  at runtime from user space or psci.
> Also, since we have named it timer_vcpu_reset(), it made sense to
> atleast disarm the timer.

I would agree if the timer had a clearly defined reset state. The ARM ARM
says that the timer register reset values are UNKNOWN. So at CPU reset, the
timer is allowed to be in any possible state, including having a pending
interrupt.

This means the guest already has to deal with the situation, and I'd
rather not give additional guarantees. Please remove this call from your
next version of this patch.

Thanks,

        M.
-- 
Fast, cheap, reliable. Pick two.


From linux at prisktech.co.nz  Sun Apr 28 05:39:39 2013
From: linux at prisktech.co.nz (Tony Prisk)
Date: Sun, 28 Apr 2013 21:39:39 +1200
Subject: [PATCH 1/4] net: velocity: Alphabetize #includes
In-Reply-To: <20130428.012150.495653742777974914.davem@davemloft.net>
References: <1367119006-31280-1-git-send-email-linux@prisktech.co.nz>
 <1367119006-31280-2-git-send-email-linux@prisktech.co.nz>
 <20130428.012150.495653742777974914.davem@davemloft.net>
Message-ID: <517CEE5B.9080900@prisktech.co.nz>

On 28/04/13 17:21, David Miller wrote:
> From: Tony Prisk <linux at prisktech.co.nz>
> Date: Sun, 28 Apr 2013 15:16:43 +1200
>
>> Due to number of #includes, alphabetize them to help avoid duplicates.
>>
>> Signed-off-by: Tony Prisk <linux at prisktech.co.nz>
> Needless churn, I refuse to apply this.
No problem - I'll drop it.
Tony Prisk


From sebastian.hesselbarth at gmail.com  Sun Apr 28 06:24:41 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Sun, 28 Apr 2013 12:24:41 +0200
Subject: [PATCH] clk: si5351: Allow to build without CONFIG_OF
Message-ID: <1367144681-14248-1-git-send-email-sebastian.hesselbarth@gmail.com>

In clk-si5351 there was some dependency to CONFIG_OF that permitted the
use of the driver on !CONFIG_OF platforms. This patch adds proper #ifdef
around of_clk_add_provider and removes the dependency on CONFIG_OF.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
---
Note:
This patch is based upon v3.9-rc8 with clk-si5351 v8 plus two fixes by
Marek Belisko applied. It has been compile-tested on x86_64 allmodconfig.

Cc: Stephen Rothwell <sfr at canb.auug.org.au>
Cc: Grant Likely <grant.likely at secretlab.ca>
Cc: Rob Herring <rob.herring at calxeda.com>
Cc: Rob Landley <rob at landley.net>
Cc: Mike Turquette <mturquette at linaro.org>
Cc: Stephen Warren <swarren at nvidia.com>
Cc: Thierry Reding <thierry.reding at avionic-design.de>
Cc: Dom Cobley <popcornmix at gmail.com>
Cc: Linus Walleij <linus.walleij at linaro.org>
Cc: Arnd Bergmann <arnd at arndb.de>
Cc: Andrew Morton <akpm at linux-foundation.org>
Cc: Pawel Moll <pawel.moll at arm.com>
Cc: Mark Brown <broonie at opensource.wolfsonmicro.com>
Cc: Russell King - ARM Linux <linux at arm.linux.org.uk>
Cc: Rabeeh Khoury <rabeeh at solid-run.com>
Cc: Daniel Mack <zonque at gmail.com>
Cc: Jean-Francois Moine <moinejf at free.fr>
Cc: Lars-Peter Clausen <lars at metafoo.de>
Cc: Guenter Roeck <linux at roeck-us.net>
Cc: Michal Bachraty <michal.bachraty at streamunlimited.com>
Cc: Marek Belisko <marek.belisko at streamunlimited.com>
Cc: devicetree-discuss at lists.ozlabs.org
Cc: linux-doc at vger.kernel.org
Cc: linux-kernel at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
---
 drivers/clk/Kconfig      |    1 -
 drivers/clk/clk-si5351.c |    2 ++
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 6412f55..5039e41 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -58,7 +58,6 @@ config COMMON_CLK_MAX77686
 config COMMON_CLK_SI5351
 	tristate "Clock driver for SiLabs 5351A/B/C"
 	depends on I2C
-	depends on OF
 	select REGMAP_I2C
 	select RATIONAL
 	---help---
diff --git a/drivers/clk/clk-si5351.c b/drivers/clk/clk-si5351.c
index 8323c31..91c0f01 100644
--- a/drivers/clk/clk-si5351.c
+++ b/drivers/clk/clk-si5351.c
@@ -1489,12 +1489,14 @@ static int si5351_i2c_probe(struct i2c_client *client,
 		}
 	}
 
+#ifdef CONFIG_OF
 	ret = of_clk_add_provider(client->dev.of_node, of_clk_src_onecell_get,
 				  &drvdata->onecell);
 	if (ret) {
 		dev_err(&client->dev, "unable to add clk provider\n");
 		return ret;
 	}
+#endif
 
 	return 0;
 }
-- 
1.7.10.4



From plagnioj at jcrosoft.com  Sun Apr 28 06:48:48 2013
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Sun, 28 Apr 2013 12:48:48 +0200
Subject: [PATCH v5 2/2] video: imxfb: Add DT support
In-Reply-To: <1366810751-26860-3-git-send-email-mpa@pengutronix.de>
References: <1366810751-26860-1-git-send-email-mpa@pengutronix.de>
 <1366810751-26860-3-git-send-email-mpa@pengutronix.de>
Message-ID: <20130428104848.GB24282@game.jcrosoft.org>

On 15:39 Wed 24 Apr     , Markus Pargmann wrote:
> Add devicetree support for imx framebuffer driver. It uses the generic
> display bindings and helper functions.
> 
> Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
> Cc: Fabio Estevam <festevam at gmail.com>
> Cc: Mark Rutland <mark.rutland at arm.com>
Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>

Best Regards,
J.
> ---
> 
> Notes:
>     Changed in v5:
>     - Fix compatible property of the example
>     - Rename property fsl,bpp to bits-per-pixel
>     - Add selects for FB_MODE_HELPERS and VIDEOMODE_HELPERS to Kconfig FB_IMX
>     
>     Changes in v4:
>     - Remove eukrea specific dmacr property.
>     - Add optional dmacr property. If not present, the dmacr reset value is not
>       changed.
>     
>     Changes in v3:
>     - Fix returncodes of of_read_mode function and print error messages
>     - Introduce a lower bound check for bits per pixel
>     - Calculate correct bytes per pixel value before using it for the calculation of
>     	memory size
>     - Change DT property names
>     
>     Changes in v2:
>     - Removed pwmr register property
>     - Cleanup of devicetree binding documentation
>     - Use default values for pwmr and lscr1
> 
>  .../devicetree/bindings/video/fsl,imx-fb.txt       |  51 ++++++
>  drivers/video/Kconfig                              |   2 +
>  drivers/video/imxfb.c                              | 194 +++++++++++++++++----
>  3 files changed, 212 insertions(+), 35 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/video/fsl,imx-fb.txt
> 
> diff --git a/Documentation/devicetree/bindings/video/fsl,imx-fb.txt b/Documentation/devicetree/bindings/video/fsl,imx-fb.txt
> new file mode 100644
> index 0000000..46da08d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/fsl,imx-fb.txt
> @@ -0,0 +1,51 @@
> +Freescale imx21 Framebuffer
> +
> +This framebuffer driver supports devices imx1, imx21, imx25, and imx27.
> +
> +Required properties:
> +- compatible : "fsl,<chip>-fb", chip should be imx1 or imx21
> +- reg : Should contain 1 register ranges(address and length)
> +- interrupts : One interrupt of the fb dev
> +
> +Required nodes:
> +- display: Phandle to a display node as described in
> +	Documentation/devicetree/bindings/video/display-timing.txt
> +	Additional, the display node has to define properties:
> +	- bits-per-pixel: Bits per pixel
> +	- fsl,pcr: LCDC PCR value
> +
> +Optional properties:
> +- fsl,dmacr: DMA Control Register value. This is optional. By default, the
> +	register is not modified as recommended by the datasheet.
> +- fsl,lscr1: LCDC Sharp Configuration Register value.
> +
> +Example:
> +
> +	imxfb: fb at 10021000 {
> +		compatible = "fsl,imx21-fb";
> +		interrupts = <61>;
> +		reg = <0x10021000 0x1000>;
> +		display = <&display0>;
> +	};
> +
> +	...
> +
> +	display0: display0 {
> +		model = "Primeview-PD050VL1";
> +		native-mode = <&timing_disp0>;
> +		bits-per-pixel = <16>;
> +		fsl,pcr = <0xf0c88080>;	/* non-standard but required */
> +		display-timings {
> +			timing_disp0: 640x480 {
> +				hactive = <640>;
> +				vactive = <480>;
> +				hback-porch = <112>;
> +				hfront-porch = <36>;
> +				hsync-len = <32>;
> +				vback-porch = <33>;
> +				vfront-porch = <33>;
> +				vsync-len = <2>;
> +				clock-frequency = <25000000>;
> +			};
> +		};
> +	};
> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> index 4c1546f..44b1af4 100644
> --- a/drivers/video/Kconfig
> +++ b/drivers/video/Kconfig
> @@ -391,6 +391,8 @@ config FB_IMX
>  	select FB_CFB_FILLRECT
>  	select FB_CFB_COPYAREA
>  	select FB_CFB_IMAGEBLIT
> +	select FB_MODE_HELPERS
> +	select VIDEOMODE_HELPERS
>  
>  config FB_CYBER2000
>  	tristate "CyberPro 2000/2010/5000 support"
> diff --git a/drivers/video/imxfb.c b/drivers/video/imxfb.c
> index ef2b587..7bb3728 100644
> --- a/drivers/video/imxfb.c
> +++ b/drivers/video/imxfb.c
> @@ -32,6 +32,12 @@
>  #include <linux/io.h>
>  #include <linux/math64.h>
>  #include <linux/uaccess.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>
> +
> +#include <video/of_display_timing.h>
> +#include <video/of_videomode.h>
> +#include <video/videomode.h>
>  
>  #include <linux/platform_data/video-imxfb.h>
>  
> @@ -117,10 +123,11 @@
>  #define LGWCR_GWAV(alpha)	(((alpha) & 0xff) << 24)
>  #define LGWCR_GWE	(1 << 22)
>  
> +#define IMXFB_LSCR1_DEFAULT 0x00120300
> +
>  /* Used fb-mode. Can be set on kernel command line, therefore file-static. */
>  static const char *fb_mode;
>  
> -
>  /*
>   * These are the bitfields for each
>   * display depth that we support.
> @@ -192,6 +199,19 @@ static struct platform_device_id imxfb_devtype[] = {
>  };
>  MODULE_DEVICE_TABLE(platform, imxfb_devtype);
>  
> +static struct of_device_id imxfb_of_dev_id[] = {
> +	{
> +		.compatible = "fsl,imx1-fb",
> +		.data = &imxfb_devtype[IMX1_FB],
> +	}, {
> +		.compatible = "fsl,imx21-fb",
> +		.data = &imxfb_devtype[IMX21_FB],
> +	}, {
> +		/* sentinel */
> +	}
> +};
> +MODULE_DEVICE_TABLE(of, imxfb_of_dev_id);
> +
>  static inline int is_imx1_fb(struct imxfb_info *fbi)
>  {
>  	return fbi->devtype == IMX1_FB;
> @@ -324,6 +344,9 @@ static const struct imx_fb_videomode *imxfb_find_mode(struct imxfb_info *fbi)
>  	struct imx_fb_videomode *m;
>  	int i;
>  
> +	if (!fb_mode)
> +		return &fbi->mode[0];
> +
>  	for (i = 0, m = &fbi->mode[0]; i < fbi->num_modes; i++, m++) {
>  		if (!strcmp(m->mode.name, fb_mode))
>  			return m;
> @@ -479,6 +502,9 @@ static int imxfb_bl_update_status(struct backlight_device *bl)
>  	struct imxfb_info *fbi = bl_get_data(bl);
>  	int brightness = bl->props.brightness;
>  
> +	if (!fbi->pwmr)
> +		return 0;
> +
>  	if (bl->props.power != FB_BLANK_UNBLANK)
>  		brightness = 0;
>  	if (bl->props.fb_blank != FB_BLANK_UNBLANK)
> @@ -719,10 +745,14 @@ static int imxfb_activate_var(struct fb_var_screeninfo *var, struct fb_info *inf
>  
>  	writel(fbi->pcr, fbi->regs + LCDC_PCR);
>  #ifndef PWMR_BACKLIGHT_AVAILABLE
> -	writel(fbi->pwmr, fbi->regs + LCDC_PWMR);
> +	if (fbi->pwmr)
> +		writel(fbi->pwmr, fbi->regs + LCDC_PWMR);
>  #endif
>  	writel(fbi->lscr1, fbi->regs + LCDC_LSCR1);
> -	writel(fbi->dmacr, fbi->regs + LCDC_DMACR);
> +
> +	/* dmacr = 0 is no valid value, as we need DMA control marks. */
> +	if (fbi->dmacr)
> +		writel(fbi->dmacr, fbi->regs + LCDC_DMACR);
>  
>  	return 0;
>  }
> @@ -758,13 +788,12 @@ static int imxfb_resume(struct platform_device *dev)
>  #define imxfb_resume	NULL
>  #endif
>  
> -static int __init imxfb_init_fbinfo(struct platform_device *pdev)
> +static int imxfb_init_fbinfo(struct platform_device *pdev)
>  {
>  	struct imx_fb_platform_data *pdata = pdev->dev.platform_data;
>  	struct fb_info *info = dev_get_drvdata(&pdev->dev);
>  	struct imxfb_info *fbi = info->par;
> -	struct imx_fb_videomode *m;
> -	int i;
> +	struct device_node *np;
>  
>  	pr_debug("%s\n",__func__);
>  
> @@ -795,41 +824,95 @@ static int __init imxfb_init_fbinfo(struct platform_device *pdev)
>  	info->fbops			= &imxfb_ops;
>  	info->flags			= FBINFO_FLAG_DEFAULT |
>  					  FBINFO_READS_FAST;
> -	info->var.grayscale		= pdata->cmap_greyscale;
> -	fbi->cmap_inverse		= pdata->cmap_inverse;
> -	fbi->cmap_static		= pdata->cmap_static;
> -	fbi->lscr1			= pdata->lscr1;
> -	fbi->dmacr			= pdata->dmacr;
> -	fbi->pwmr			= pdata->pwmr;
> -	fbi->lcd_power			= pdata->lcd_power;
> -	fbi->backlight_power		= pdata->backlight_power;
> -
> -	for (i = 0, m = &pdata->mode[0]; i < pdata->num_modes; i++, m++)
> -		info->fix.smem_len = max_t(size_t, info->fix.smem_len,
> -				m->mode.xres * m->mode.yres * m->bpp / 8);
> +	if (pdata) {
> +		info->var.grayscale		= pdata->cmap_greyscale;
> +		fbi->cmap_inverse		= pdata->cmap_inverse;
> +		fbi->cmap_static		= pdata->cmap_static;
> +		fbi->lscr1			= pdata->lscr1;
> +		fbi->dmacr			= pdata->dmacr;
> +		fbi->pwmr			= pdata->pwmr;
> +		fbi->lcd_power			= pdata->lcd_power;
> +		fbi->backlight_power		= pdata->backlight_power;
> +	} else {
> +		np = pdev->dev.of_node;
> +		info->var.grayscale = of_property_read_bool(np,
> +						"cmap-greyscale");
> +		fbi->cmap_inverse = of_property_read_bool(np, "cmap-inverse");
> +		fbi->cmap_static = of_property_read_bool(np, "cmap-static");
> +
> +		fbi->lscr1 = IMXFB_LSCR1_DEFAULT;
> +		of_property_read_u32(np, "fsl,lscr1", &fbi->lscr1);
> +
> +		of_property_read_u32(np, "fsl,dmacr", &fbi->dmacr);
> +
> +		/* These two function pointers could be used by some specific
> +		 * platforms. */
> +		fbi->lcd_power = NULL;
> +		fbi->backlight_power = NULL;
> +	}
> +
> +	return 0;
> +}
> +
> +static int imxfb_of_read_mode(struct device *dev, struct device_node *np,
> +		struct imx_fb_videomode *imxfb_mode)
> +{
> +	int ret;
> +	struct fb_videomode *of_mode = &imxfb_mode->mode;
> +	u32 bpp;
> +	u32 pcr;
> +
> +	ret = of_property_read_string(np, "model", &of_mode->name);
> +	if (ret)
> +		of_mode->name = NULL;
> +
> +	ret = of_get_fb_videomode(np, of_mode, OF_USE_NATIVE_MODE);
> +	if (ret) {
> +		dev_err(dev, "Failed to get videomode from DT\n");
> +		return ret;
> +	}
> +
> +	ret = of_property_read_u32(np, "bits-per-pixel", &bpp);
> +	ret |= of_property_read_u32(np, "fsl,pcr", &pcr);
> +
> +	if (ret) {
> +		dev_err(dev, "Failed to read bpp and pcr from DT\n");
> +		return -EINVAL;
> +	}
> +
> +	if (bpp < 1 || bpp > 255) {
> +		dev_err(dev, "Bits per pixel have to be between 1 and 255\n");
> +		return -EINVAL;
> +	}
> +
> +	imxfb_mode->bpp = bpp;
> +	imxfb_mode->pcr = pcr;
>  
>  	return 0;
>  }
>  
> -static int __init imxfb_probe(struct platform_device *pdev)
> +static int imxfb_probe(struct platform_device *pdev)
>  {
>  	struct imxfb_info *fbi;
>  	struct fb_info *info;
>  	struct imx_fb_platform_data *pdata;
>  	struct resource *res;
> +	struct imx_fb_videomode *m;
> +	const struct of_device_id *of_id;
>  	int ret, i;
> +	int bytes_per_pixel;
>  
>  	dev_info(&pdev->dev, "i.MX Framebuffer driver\n");
>  
> +	of_id = of_match_device(imxfb_of_dev_id, &pdev->dev);
> +	if (of_id)
> +		pdev->id_entry = of_id->data;
> +
>  	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>  	if (!res)
>  		return -ENODEV;
>  
>  	pdata = pdev->dev.platform_data;
> -	if (!pdata) {
> -		dev_err(&pdev->dev,"No platform_data available\n");
> -		return -ENOMEM;
> -	}
>  
>  	info = framebuffer_alloc(sizeof(struct imxfb_info), &pdev->dev);
>  	if (!info)
> @@ -837,15 +920,55 @@ static int __init imxfb_probe(struct platform_device *pdev)
>  
>  	fbi = info->par;
>  
> -	if (!fb_mode)
> -		fb_mode = pdata->mode[0].mode.name;
> -
>  	platform_set_drvdata(pdev, info);
>  
>  	ret = imxfb_init_fbinfo(pdev);
>  	if (ret < 0)
>  		goto failed_init;
>  
> +	if (pdata) {
> +		if (!fb_mode)
> +			fb_mode = pdata->mode[0].mode.name;
> +
> +		fbi->mode = pdata->mode;
> +		fbi->num_modes = pdata->num_modes;
> +	} else {
> +		struct device_node *display_np;
> +		fb_mode = NULL;
> +
> +		display_np = of_parse_phandle(pdev->dev.of_node, "display", 0);
> +		if (!display_np) {
> +			dev_err(&pdev->dev, "No display defined in devicetree\n");
> +			ret = -EINVAL;
> +			goto failed_of_parse;
> +		}
> +
> +		/*
> +		 * imxfb does not support more modes, we choose only the native
> +		 * mode.
> +		 */
> +		fbi->num_modes = 1;
> +
> +		fbi->mode = devm_kzalloc(&pdev->dev,
> +				sizeof(struct imx_fb_videomode), GFP_KERNEL);
> +		if (!fbi->mode) {
> +			ret = -ENOMEM;
> +			goto failed_of_parse;
> +		}
> +
> +		ret = imxfb_of_read_mode(&pdev->dev, display_np, fbi->mode);
> +		if (ret)
> +			goto failed_of_parse;
> +	}
> +
> +	/* Calculate maximum bytes used per pixel. In most cases this should
> +	 * be the same as m->bpp/8 */
> +	m = &fbi->mode[0];
> +	bytes_per_pixel = (m->bpp + 7) / 8;
> +	for (i = 0; i < fbi->num_modes; i++, m++)
> +		info->fix.smem_len = max_t(size_t, info->fix.smem_len,
> +				m->mode.xres * m->mode.yres * bytes_per_pixel);
> +
>  	res = request_mem_region(res->start, resource_size(res),
>  				DRIVER_NAME);
>  	if (!res) {
> @@ -878,7 +1001,8 @@ static int __init imxfb_probe(struct platform_device *pdev)
>  		goto failed_ioremap;
>  	}
>  
> -	if (!pdata->fixed_screen_cpu) {
> +	/* Seems not being used by anyone, so no support for oftree */
> +	if (!pdata || !pdata->fixed_screen_cpu) {
>  		fbi->map_size = PAGE_ALIGN(info->fix.smem_len);
>  		fbi->map_cpu = dma_alloc_writecombine(&pdev->dev,
>  				fbi->map_size, &fbi->map_dma, GFP_KERNEL);
> @@ -903,18 +1027,16 @@ static int __init imxfb_probe(struct platform_device *pdev)
>  		info->fix.smem_start = fbi->screen_dma;
>  	}
>  
> -	if (pdata->init) {
> +	if (pdata && pdata->init) {
>  		ret = pdata->init(fbi->pdev);
>  		if (ret)
>  			goto failed_platform_init;
>  	}
>  
> -	fbi->mode = pdata->mode;
> -	fbi->num_modes = pdata->num_modes;
>  
>  	INIT_LIST_HEAD(&info->modelist);
> -	for (i = 0; i < pdata->num_modes; i++)
> -		fb_add_videomode(&pdata->mode[i].mode, &info->modelist);
> +	for (i = 0; i < fbi->num_modes; i++)
> +		fb_add_videomode(&fbi->mode[i].mode, &info->modelist);
>  
>  	/*
>  	 * This makes sure that our colour bitfield
> @@ -944,10 +1066,10 @@ static int __init imxfb_probe(struct platform_device *pdev)
>  failed_register:
>  	fb_dealloc_cmap(&info->cmap);
>  failed_cmap:
> -	if (pdata->exit)
> +	if (pdata && pdata->exit)
>  		pdata->exit(fbi->pdev);
>  failed_platform_init:
> -	if (!pdata->fixed_screen_cpu)
> +	if (pdata && !pdata->fixed_screen_cpu)
>  		dma_free_writecombine(&pdev->dev,fbi->map_size,fbi->map_cpu,
>  			fbi->map_dma);
>  failed_map:
> @@ -956,6 +1078,7 @@ failed_ioremap:
>  failed_getclock:
>  	release_mem_region(res->start, resource_size(res));
>  failed_req:
> +failed_of_parse:
>  	kfree(info->pseudo_palette);
>  failed_init:
>  	platform_set_drvdata(pdev, NULL);
> @@ -980,7 +1103,7 @@ static int imxfb_remove(struct platform_device *pdev)
>  	unregister_framebuffer(info);
>  
>  	pdata = pdev->dev.platform_data;
> -	if (pdata->exit)
> +	if (pdata && pdata->exit)
>  		pdata->exit(fbi->pdev);
>  
>  	fb_dealloc_cmap(&info->cmap);
> @@ -1009,6 +1132,7 @@ static struct platform_driver imxfb_driver = {
>  	.shutdown	= imxfb_shutdown,
>  	.driver		= {
>  		.name	= DRIVER_NAME,
> +		.of_match_table = imxfb_of_dev_id,
>  	},
>  	.id_table	= imxfb_devtype,
>  };
> -- 
> 1.8.1.5
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From anup at brainfault.org  Sun Apr 28 07:48:03 2013
From: anup at brainfault.org (Anup Patel)
Date: Sun, 28 Apr 2013 17:18:03 +0530
Subject: [PATCH] ARM: KVM: Allow host virt timer irq to be different from
 guest timer virt irq
In-Reply-To: <459ddcd84aa2644e21efbbca56ff6870@localhost>
References: <1367050086-2902-1-git-send-email-anup.patel@linaro.org>
 <73b473edb8a9ea9a09f1df68345903d7@localhost>
 <CAAhSdy101B=4cK9nnLtQa7rG15D0CT_DsWD6k3FZ1EYz2nAfEw@mail.gmail.com>
 <459ddcd84aa2644e21efbbca56ff6870@localhost>
Message-ID: <CAAhSdy2kRBExvCZgbgXfrgOE5cvU7-mwpe8g-sWUmiN7P717Qw@mail.gmail.com>

On Sun, Apr 28, 2013 at 3:05 PM, Marc Zyngier <marc.zyngier at arm.com> wrote:
> On Sat, 27 Apr 2013 17:49:31 +0530, Anup Patel <anup at brainfault.org>
> wrote:
>> On Sat, Apr 27, 2013 at 2:49 PM, Marc Zyngier <marc.zyngier at arm.com>
> wrote:
>>> On Sat, 27 Apr 2013 13:38:06 +0530, Anup Patel <anup.patel at linaro.org>
>>> wrote:
>>>> The arch_timer irq numbers (or PPI numbers) are implementation
> dependent
>>>> so, the host virtual timer irq number can be different from guest
>>> virtual
>>>> timer irq number.
>>>>
>>>> This patch ensures that host virtual timer irq number is read from DTB
>>> and
>>>> guest virtual timer irq is determined based on vcpu target type.
>
> [...]
>
>>>>
>>>> +int kvm_timer_vcpu_reset(struct kvm_vcpu *vcpu,
>>>> +                      const struct kvm_irq_level *irq)
>>>> +{
>>>> +     struct arch_timer_cpu *timer = &vcpu->arch.timer_cpu;
>>>> +
>>>> +     /*
>>>> +      * The vcpu timer irq number cannot be determined in
>>>> +      * kvm_timer_vcpu_init() because it is called much before
>>>> +      * kvm_vcpu_set_target(). To handle this, we determine
>>>> +      * vcpu timer irq number when the vcpu is resetted.
>>>> +      */
>>>> +     timer->irq = irq;
>>>> +
>>>> +     /*
>>>> +      * Make sure timer is disarmed.
>>>> +      */
>>>> +     timer_disarm(timer);
>>>
>>> What is that for? Timer has not been started yet, for the lack of an
> IRQ.
>>> Actually, the vcpu has never ran. Why would you need to disarm it?
>>
>> This is in case a vcpu is resetted  at runtime from user space or psci.
>> Also, since we have named it timer_vcpu_reset(), it made sense to
>> atleast disarm the timer.
>
> I would agree if the timer had a clearly defined reset state. The ARM ARM
> says that the timer register reset values are UNKNOWN. So at CPU reset, the
> timer is allowed to be in any possible state, including having a pending
> interrupt.
>
> This means the guest already has to deal with the situation, and I'd
> rather not give additional guarantees. Please remove this call from your
> next version of this patch.

Ok, I will remove it.

>
> Thanks,
>
>         M.
> --
> Fast, cheap, reliable. Pick two.

--Anup


From shawn.guo at linaro.org  Sun Apr 28 08:19:47 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Sun, 28 Apr 2013 20:19:47 +0800
Subject: [PATCH] Support fsl-dcp crypto coprocessor
In-Reply-To: <341422577.566569.1366721757554.open-xchange@email.1und1.de>
References: <1366710460-11637-1-git-send-email-cb@sgoc.de>
 <20130423123408.GB1366@pengutronix.de>
 <341422577.566569.1366721757554.open-xchange@email.1und1.de>
Message-ID: <20130428121944.GB15901@S2101-09.ap.freescale.net>

On Tue, Apr 23, 2013 at 02:55:57PM +0200, Christoph G. Baumann wrote:
> 
> > IMHO it doesn't make any sense to push this into staging. The Freescale
> > kernel is full of drivers which are not ready for mainline yet.
> 
> Indeed the Freescale kernel is a heap of <censored>.
> 
> 
> > Until now, it was a good strategy to wait until some code is needed,
> > then clean it up, adapt it to the right kernel APIs and push it into
> > non-staging mainline.
> 
> Well, that's what I'm trying to do. I picked a particular driver and
> adapted it to the current mainline.

Then why not put them into drivers/crypto/ rather than
drivers/staging/crypto/?

Shawn

> So if there are concrete proposals or criticism about this patch, please
> tell me. As I stated the code is from Freescale and I won't be offended.



From stefano.stabellini at eu.citrix.com  Sun Apr 28 10:50:20 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Sun, 28 Apr 2013 15:50:20 +0100
Subject: [PATCH 0/2 v9] arm: introduce psci_smp_ops
Message-ID: <alpine.DEB.2.02.1304281544240.5398@kaball.uk.xensource.com>

Hi all,
this is the nineth version of the patch series to move virt_smp_ops out
of mach-virt and make it a generic set of reusable PSCI based smp_ops.
psci_smp_ops are preferred over the platform smp_ops.  The last patch
introduces smp_init.

Only one change in this last iteration: the PSCI related comment has
been moved from psci.h to psci_smp.c.


Jon Medhurst (1):
      ARM: Enable selection of SMP operations at boot time

Stefano Stabellini (1):
      arm: introduce psci_smp_ops

 arch/arm/include/asm/mach/arch.h |    3 +
 arch/arm/include/asm/psci.h      |    9 ++++
 arch/arm/kernel/Makefile         |    5 ++-
 arch/arm/kernel/psci.c           |    7 +--
 arch/arm/kernel/psci_smp.c       |   90 ++++++++++++++++++++++++++++++++++++++
 arch/arm/kernel/setup.c          |    9 +++-
 arch/arm/mach-virt/Makefile      |    1 -
 arch/arm/mach-virt/platsmp.c     |   58 ------------------------
 arch/arm/mach-virt/virt.c        |    3 -
 9 files changed, 117 insertions(+), 68 deletions(-)

git://git.kernel.org/pub/scm/linux/kernel/git/sstabellini/xen.git 3.9-rc3-psci-ops-9-tag

Cheers,

Stefano


From stefano.stabellini at eu.citrix.com  Sun Apr 28 10:50:50 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Sun, 28 Apr 2013 15:50:50 +0100
Subject: [PATCH v9 2/2] ARM: Enable selection of SMP operations at boot time
In-Reply-To: <alpine.DEB.2.02.1304281544240.5398@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1304281544240.5398@kaball.uk.xensource.com>
Message-ID: <1367160650-4888-2-git-send-email-stefano.stabellini@eu.citrix.com>

From: Jon Medhurst <tixy at linaro.org>

Add a new 'smp_init' hook to machine_desc so platforms can specify a
function to be used to setup smp ops instead of having a statically
defined value.  The hook must return true when smp_ops are initialized.
If false the static mdesc->smp_ops will be used by default.

Signed-off-by: Jon Medhurst <tixy at linaro.org>
Signed-off-by: Nicolas Pitre <nicolas.pitre at linaro.org>
Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
Reviewed-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
---
 arch/arm/include/asm/mach/arch.h |    3 +++
 arch/arm/kernel/setup.c          |   10 ++++++----
 2 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/arch/arm/include/asm/mach/arch.h b/arch/arm/include/asm/mach/arch.h
index 308ad7d..af8c54c 100644
--- a/arch/arm/include/asm/mach/arch.h
+++ b/arch/arm/include/asm/mach/arch.h
@@ -16,8 +16,10 @@ struct pt_regs;
 struct smp_operations;
 #ifdef CONFIG_SMP
 #define smp_ops(ops) (&(ops))
+#define smp_init_ops(ops) (&(ops))
 #else
 #define smp_ops(ops) (struct smp_operations *)NULL
+#define smp_init_ops(ops) (bool (*)(void))NULL
 #endif
 
 struct machine_desc {
@@ -41,6 +43,7 @@ struct machine_desc {
 	unsigned char		reserve_lp2 :1;	/* never has lp2	*/
 	char			restart_mode;	/* default restart mode	*/
 	struct smp_operations	*smp;		/* SMP operations	*/
+	bool			(*smp_init)(void);
 	void			(*fixup)(struct tag *, char **,
 					 struct meminfo *);
 	void			(*reserve)(void);/* reserve mem blocks	*/
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index dad3048..22cc863 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -770,10 +770,12 @@ void __init setup_arch(char **cmdline_p)
 	psci_init();
 #ifdef CONFIG_SMP
 	if (is_smp()) {
-		if (psci_smp_available())
-			smp_set_ops(&psci_smp_ops);
-		else if (mdesc->smp)
-			smp_set_ops(mdesc->smp);
+		if (!mdesc->smp_init || !mdesc->smp_init()) {
+			if (psci_smp_available())
+				smp_set_ops(&psci_smp_ops);
+			else if (mdesc->smp)
+				smp_set_ops(mdesc->smp);
+		}
 		smp_init_cpus();
 	}
 #endif
-- 
1.7.2.5



From stefano.stabellini at eu.citrix.com  Sun Apr 28 10:50:49 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Sun, 28 Apr 2013 15:50:49 +0100
Subject: [PATCH v9 1/2] arm: introduce psci_smp_ops
In-Reply-To: <alpine.DEB.2.02.1304281544240.5398@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1304281544240.5398@kaball.uk.xensource.com>
Message-ID: <1367160650-4888-1-git-send-email-stefano.stabellini@eu.citrix.com>

Rename virt_smp_ops to psci_smp_ops and move them to arch/arm/kernel/psci_smp.c.
Remove mach-virt/platsmp.c, now unused.
Compile psci_smp if CONFIG_ARM_PSCI and CONFIG_SMP.

Add a cpu_die smp_op based on psci_ops.cpu_off.

Initialize PSCI before setting smp_ops in setup_arch.

If PSCI is available on the platform, prefer psci_smp_ops over the
platform smp_ops.

Changes in v9:
- move comment about PSCI interface from psci.h to psci_smp.c.

Changes in v8:
- merge "prefer psci_smp_ops over mdesc->smp" into this patch.

Changes in v6:
- fixed return values for psci_smp_available and psci_init ifndef
CONFIG_ARM_PSCI.

Changes in v5:
- document psci_operations;
- psci_init returns NULL.

Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
CC: Nicolas Pitre <nico at linaro.org>
CC: Rob Herring <rob.herring at calxeda.com>
CC: Will Deacon <will.deacon at arm.com>
CC: arnd at arndb.de
CC: marc.zyngier at arm.com
CC: linux at arm.linux.org.uk
---
 arch/arm/include/asm/psci.h  |    9 ++++
 arch/arm/kernel/Makefile     |    5 ++-
 arch/arm/kernel/psci.c       |    7 +--
 arch/arm/kernel/psci_smp.c   |   90 ++++++++++++++++++++++++++++++++++++++++++
 arch/arm/kernel/setup.c      |    7 +++-
 arch/arm/mach-virt/Makefile  |    1 -
 arch/arm/mach-virt/platsmp.c |   58 ---------------------------
 arch/arm/mach-virt/virt.c    |    3 -
 8 files changed, 112 insertions(+), 68 deletions(-)
 create mode 100644 arch/arm/kernel/psci_smp.c
 delete mode 100644 arch/arm/mach-virt/platsmp.c

diff --git a/arch/arm/include/asm/psci.h b/arch/arm/include/asm/psci.h
index ce0dbe7..c4ae171 100644
--- a/arch/arm/include/asm/psci.h
+++ b/arch/arm/include/asm/psci.h
@@ -32,5 +32,14 @@ struct psci_operations {
 };
 
 extern struct psci_operations psci_ops;
+extern struct smp_operations psci_smp_ops;
+
+#ifdef CONFIG_ARM_PSCI
+void psci_init(void);
+bool psci_smp_available(void);
+#else
+static inline void psci_init(void) { }
+static inline bool psci_smp_available(void) { return false; }
+#endif
 
 #endif /* __ASM_ARM_PSCI_H */
diff --git a/arch/arm/kernel/Makefile b/arch/arm/kernel/Makefile
index 5f3338e..dd9d90a 100644
--- a/arch/arm/kernel/Makefile
+++ b/arch/arm/kernel/Makefile
@@ -82,6 +82,9 @@ obj-$(CONFIG_DEBUG_LL)	+= debug.o
 obj-$(CONFIG_EARLY_PRINTK)	+= early_printk.o
 
 obj-$(CONFIG_ARM_VIRT_EXT)	+= hyp-stub.o
-obj-$(CONFIG_ARM_PSCI)		+= psci.o
+ifeq ($(CONFIG_ARM_PSCI),y)
+obj-y				+= psci.o
+obj-$(CONFIG_SMP)		+= psci_smp.o
+endif
 
 extra-y := $(head-y) vmlinux.lds
diff --git a/arch/arm/kernel/psci.c b/arch/arm/kernel/psci.c
index 3653164..4693188 100644
--- a/arch/arm/kernel/psci.c
+++ b/arch/arm/kernel/psci.c
@@ -158,7 +158,7 @@ static const struct of_device_id psci_of_match[] __initconst = {
 	{},
 };
 
-static int __init psci_init(void)
+void __init psci_init(void)
 {
 	struct device_node *np;
 	const char *method;
@@ -166,7 +166,7 @@ static int __init psci_init(void)
 
 	np = of_find_matching_node(NULL, psci_of_match);
 	if (!np)
-		return 0;
+		return;
 
 	pr_info("probing function IDs from device-tree\n");
 
@@ -206,6 +206,5 @@ static int __init psci_init(void)
 
 out_put_node:
 	of_node_put(np);
-	return 0;
+	return;
 }
-early_initcall(psci_init);
diff --git a/arch/arm/kernel/psci_smp.c b/arch/arm/kernel/psci_smp.c
new file mode 100644
index 0000000..6ef139d
--- /dev/null
+++ b/arch/arm/kernel/psci_smp.c
@@ -0,0 +1,90 @@
+/*
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Copyright (C) 2012 ARM Limited
+ *
+ * Author: Will Deacon <will.deacon at arm.com>
+ */
+
+#include <linux/init.h>
+#include <linux/irqchip/arm-gic.h>
+#include <linux/smp.h>
+#include <linux/of.h>
+
+#include <asm/psci.h>
+#include <asm/smp_plat.h>
+
+/*
+ * psci_smp assumes that the following is true about PSCI:
+ *
+ * cpu_suspend   Suspend the execution on a CPU
+ * @state        we don't currently describe affinity levels, so just pass 0.
+ * @entry_point  the first instruction to be executed on return
+ * returns 0  success, < 0 on failure
+ *
+ * cpu_off       Power down a CPU
+ * @state        we don't currently describe affinity levels, so just pass 0.
+ * no return on successful call
+ *
+ * cpu_on        Power up a CPU
+ * @cpuid        cpuid of target CPU, as from MPIDR
+ * @entry_point  the first instruction to be executed on return
+ * returns 0  success, < 0 on failure
+ *
+ * migrate       Migrate the context to a different CPU
+ * @cpuid        cpuid of target CPU, as from MPIDR
+ * returns 0  success, < 0 on failure
+ *
+ */
+
+extern void secondary_startup(void);
+
+static int __cpuinit psci_boot_secondary(unsigned int cpu,
+					 struct task_struct *idle)
+{
+	if (psci_ops.cpu_on)
+		return psci_ops.cpu_on(cpu_logical_map(cpu),
+				       __pa(secondary_startup));
+	return -ENODEV;
+}
+
+static void __cpuinit psci_secondary_init(unsigned int cpu)
+{
+	gic_secondary_init(0);
+}
+
+#ifdef CONFIG_HOTPLUG_CPU
+void __ref psci_cpu_die(unsigned int cpu)
+{
+       const struct psci_power_state ps = {
+               .type = PSCI_POWER_STATE_TYPE_POWER_DOWN,
+       };
+
+       if (psci_ops.cpu_off)
+               psci_ops.cpu_off(ps);
+
+       /* We should never return */
+       panic("psci: cpu %d failed to shutdown\n", cpu);
+}
+#else
+#define psci_cpu_die NULL
+#endif
+
+bool __init psci_smp_available(void)
+{
+	/* is cpu_on available at least? */
+	return (psci_ops.cpu_on != NULL);
+}
+
+struct smp_operations __initdata psci_smp_ops = {
+	.smp_secondary_init	= psci_secondary_init,
+	.smp_boot_secondary	= psci_boot_secondary,
+	.cpu_die		= psci_cpu_die,
+};
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 3f6cbb2..dad3048 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -36,6 +36,7 @@
 #include <asm/cputype.h>
 #include <asm/elf.h>
 #include <asm/procinfo.h>
+#include <asm/psci.h>
 #include <asm/sections.h>
 #include <asm/setup.h>
 #include <asm/smp_plat.h>
@@ -766,9 +767,13 @@ void __init setup_arch(char **cmdline_p)
 	unflatten_device_tree();
 
 	arm_dt_init_cpu_maps();
+	psci_init();
 #ifdef CONFIG_SMP
 	if (is_smp()) {
-		smp_set_ops(mdesc->smp);
+		if (psci_smp_available())
+			smp_set_ops(&psci_smp_ops);
+		else if (mdesc->smp)
+			smp_set_ops(mdesc->smp);
 		smp_init_cpus();
 	}
 #endif
diff --git a/arch/arm/mach-virt/Makefile b/arch/arm/mach-virt/Makefile
index 042afc1..7ddbfa6 100644
--- a/arch/arm/mach-virt/Makefile
+++ b/arch/arm/mach-virt/Makefile
@@ -3,4 +3,3 @@
 #
 
 obj-y					:= virt.o
-obj-$(CONFIG_SMP)			+= platsmp.o
diff --git a/arch/arm/mach-virt/platsmp.c b/arch/arm/mach-virt/platsmp.c
deleted file mode 100644
index 8badaab..0000000
--- a/arch/arm/mach-virt/platsmp.c
+++ /dev/null
@@ -1,58 +0,0 @@
-/*
- * Dummy Virtual Machine - does what it says on the tin.
- *
- * Copyright (C) 2012 ARM Ltd
- * Author: Will Deacon <will.deacon at arm.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.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program.  If not, see <http://www.gnu.org/licenses/>.
- */
-
-#include <linux/init.h>
-#include <linux/smp.h>
-#include <linux/of.h>
-
-#include <linux/irqchip/arm-gic.h>
-
-#include <asm/psci.h>
-#include <asm/smp_plat.h>
-
-extern void secondary_startup(void);
-
-static void __init virt_smp_init_cpus(void)
-{
-}
-
-static void __init virt_smp_prepare_cpus(unsigned int max_cpus)
-{
-}
-
-static int __cpuinit virt_boot_secondary(unsigned int cpu,
-					 struct task_struct *idle)
-{
-	if (psci_ops.cpu_on)
-		return psci_ops.cpu_on(cpu_logical_map(cpu),
-				       __pa(secondary_startup));
-	return -ENODEV;
-}
-
-static void __cpuinit virt_secondary_init(unsigned int cpu)
-{
-	gic_secondary_init(0);
-}
-
-struct smp_operations __initdata virt_smp_ops = {
-	.smp_init_cpus		= virt_smp_init_cpus,
-	.smp_prepare_cpus	= virt_smp_prepare_cpus,
-	.smp_secondary_init	= virt_secondary_init,
-	.smp_boot_secondary	= virt_boot_secondary,
-};
diff --git a/arch/arm/mach-virt/virt.c b/arch/arm/mach-virt/virt.c
index 31666f6..4438ed0 100644
--- a/arch/arm/mach-virt/virt.c
+++ b/arch/arm/mach-virt/virt.c
@@ -43,12 +43,9 @@ static const char *virt_dt_match[] = {
 	NULL
 };
 
-extern struct smp_operations virt_smp_ops;
-
 DT_MACHINE_START(VIRT, "Dummy Virtual Machine")
 	.init_irq	= irqchip_init,
 	.init_time	= virt_timer_init,
 	.init_machine	= virt_init,
-	.smp		= smp_ops(virt_smp_ops),
 	.dt_compat	= virt_dt_match,
 MACHINE_END
-- 
1.7.2.5



From shawn.guo at linaro.org  Sun Apr 28 11:30:14 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Sun, 28 Apr 2013 23:30:14 +0800
Subject: [PATCH] Support fsl-dcp crypto coprocessor
In-Reply-To: <1366710460-11637-1-git-send-email-cb@sgoc.de>
References: <1366710460-11637-1-git-send-email-cb@sgoc.de>
Message-ID: <CAAQ0ZWSYNJg4+rDNjO-JcwzbWfzh7sJXJFuUp3fCNguYC28p7Q@mail.gmail.com>

Hi Christoph,

You need to check MAINTAINERS to get the mailing list and maintainers
of crypto subsystem.

CRYPTO API
M:      Herbert Xu <herbert at gondor.apana.org.au>
M:      "David S. Miller" <davem at davemloft.net>
L:      linux-crypto at vger.kernel.org
T:      git git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git
S:      Maintained
F:      Documentation/crypto/
F:      arch/*/crypto/
F:      crypto/
F:      drivers/crypto/
F:      include/crypto/

It's nice to have linux-arm-kernel on Cc, but the patch should really be
sent to people and mailing list above.  After all, Herbert will
eventually pick up the patch after it gets reviewed on linux-crypto
list.

On Tue, Apr 23, 2013 at 11:47:40AM +0200, Christoph G. Baumann wrote:
> From: "Christoph G. Baumann" <cb at sgoc.de>
>
> The following patch is a port of the original driver from Freescale to
> the current mainline. The patch was tested under 3.7.

The patch should be developed and tested against the latest kernel
version, saying v3.9.

Will look into the patch in another day.

Shawn

>
> Signed-off-by: "Christoph G. Baumann" <cb at sgoc.de>
> ---
>  drivers/staging/crypto/Kconfig               |   15 +
>  drivers/staging/crypto/Makefile              |    1 +
>  drivers/staging/crypto/fsl-dcp.c             | 1817 ++++++++++++++++++++++++++
>  drivers/staging/crypto/fsl-dcp.h             |  739 +++++++++++
>  include/linux/fsl/fsl-dcp_bootstream_ioctl.h |   32 +
>  5 files changed, 2604 insertions(+)
>  create mode 100644 drivers/staging/crypto/Kconfig
>  create mode 100644 drivers/staging/crypto/Makefile
>  create mode 100644 drivers/staging/crypto/fsl-dcp.c
>  create mode 100644 drivers/staging/crypto/fsl-dcp.h
>  create mode 100644 include/linux/fsl/fsl-dcp_bootstream_ioctl.h


From arnd at arndb.de  Sun Apr 28 14:03:26 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Sun, 28 Apr 2013 20:03:26 +0200
Subject: [PATCH] clk: si5351: Allow to build without CONFIG_OF
In-Reply-To: <1367144681-14248-1-git-send-email-sebastian.hesselbarth@gmail.com>
References: <1367144681-14248-1-git-send-email-sebastian.hesselbarth@gmail.com>
Message-ID: <201304282003.26593.arnd@arndb.de>

On Sunday 28 April 2013, Sebastian Hesselbarth wrote:
> diff --git a/drivers/clk/clk-si5351.c b/drivers/clk/clk-si5351.c
> index 8323c31..91c0f01 100644
> --- a/drivers/clk/clk-si5351.c
> +++ b/drivers/clk/clk-si5351.c
> @@ -1489,12 +1489,14 @@ static int si5351_i2c_probe(struct i2c_client *client,
>                 }
>         }
>  
> +#ifdef CONFIG_OF
>         ret = of_clk_add_provider(client->dev.of_node, of_clk_src_onecell_get,
>                                   &drvdata->onecell);
>         if (ret) {
>                 dev_err(&client->dev, "unable to add clk provider\n");
>                 return ret;
>         }
> +#endif
>  

I think we should instead make of_clk_add_provider return 0 if CONFIG_OF
is disabled, adn we don't consider it an error condition to call it.
That is also what we return when CONFIG_OF is enabled and we boot without
a device tree.

	Arnd


From cdall at cs.columbia.edu  Sun Apr 28 14:09:57 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Sun, 28 Apr 2013 11:09:57 -0700
Subject: [PATCH] arm64: KVM: Reset arch_timer upon vcpu reset
In-Reply-To: <1367050195-2953-1-git-send-email-anup.patel@linaro.org>
References: <1367050195-2953-1-git-send-email-anup.patel@linaro.org>
Message-ID: <CAEDV+gK72LrsQMEmWJDcBQoKG4L38Ucj1sBReNpPDbovTivNBQ@mail.gmail.com>

On Sat, Apr 27, 2013 at 1:09 AM, Anup Patel <anup.patel at linaro.org> wrote:
> This patch does arch_timer reset (i.e. kvm_timer_vcpu_reset()) when a vcpu resetted by kvm_reset_vcpu().
>
> The kvm_reset_vcpu() also informs guest timer irq number to arch_timer code via kvm_timer_vcpu_reset().
>
> Signed-off-by: Anup Patel <anup.patel at linaro.org>
> Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar at linaro.org>
> ---
>  arch/arm64/include/asm/kvm_arch_timer.h |    2 ++
>  arch/arm64/kvm/reset.c                  |   11 ++++++++++-
>  2 files changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/include/asm/kvm_arch_timer.h b/arch/arm64/include/asm/kvm_arch_timer.h
> index eb02273..04949c6 100644
> --- a/arch/arm64/include/asm/kvm_arch_timer.h
> +++ b/arch/arm64/include/asm/kvm_arch_timer.h
> @@ -50,6 +50,8 @@ struct arch_timer_cpu {
>
>  int kvm_timer_hyp_init(void);
>  int kvm_timer_init(struct kvm *kvm);
> +int kvm_timer_vcpu_reset(struct kvm_vcpu *vcpu,
> +                        const struct kvm_irq_level *irq);
>  void kvm_timer_vcpu_init(struct kvm_vcpu *vcpu);
>  void kvm_timer_flush_hwstate(struct kvm_vcpu *vcpu);
>  void kvm_timer_sync_hwstate(struct kvm_vcpu *vcpu);
> diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
> index 64e0740..1e255a3 100644
> --- a/arch/arm64/kvm/reset.c
> +++ b/arch/arm64/kvm/reset.c
> @@ -27,6 +27,7 @@
>  #include <asm/ptrace.h>
>  #include <asm/kvm_arm.h>
>  #include <asm/kvm_coproc.h>
> +#include <asm/kvm_arch_timer.h>
>
>  /*
>   * ARMv8 Reset Values
> @@ -40,6 +41,11 @@ static struct kvm_regs default_regs_reset32 = {
>                         COMPAT_PSR_I_BIT | COMPAT_PSR_F_BIT),
>  };
>
> +static struct kvm_irq_level default_timer_irq = {
> +       .irq = 27,
> +       .level = 1,
> +};
> +
>  static bool cpu_has_32bit_el1(void)
>  {
>         u64 pfr0;
> @@ -75,6 +81,7 @@ int kvm_arch_dev_ioctl_check_extension(long ext)
>  int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
>  {
>         struct kvm_regs *cpu_reset;
> +       const struct kvm_irq_level *cpu_irq;
>
>         switch (vcpu->arch.target) {
>         default:
> @@ -86,6 +93,7 @@ int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
>                 } else {
>                         cpu_reset = &default_regs_reset;
>                 }
> +               cpu_irq = &default_timer_irq;

what's the reason for naming this cpu_irq?

seems to me it should be vtimer_irq or something to that affect...

>                 break;
>         }
>
> @@ -95,5 +103,6 @@ int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
>         /* Reset system registers */
>         kvm_reset_sys_regs(vcpu);
>
> -       return 0;
> +       /* Reset arch_timer context */
> +       return kvm_timer_vcpu_reset(vcpu, cpu_irq);
>  }
> --
> 1.7.9.5
>
> _______________________________________________
> kvmarm mailing list
> kvmarm at lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm


From anup at brainfault.org  Sun Apr 28 14:14:25 2013
From: anup at brainfault.org (Anup Patel)
Date: Sun, 28 Apr 2013 23:44:25 +0530
Subject: [PATCH] arm64: KVM: Reset arch_timer upon vcpu reset
In-Reply-To: <CAEDV+gK72LrsQMEmWJDcBQoKG4L38Ucj1sBReNpPDbovTivNBQ@mail.gmail.com>
References: <1367050195-2953-1-git-send-email-anup.patel@linaro.org>
 <CAEDV+gK72LrsQMEmWJDcBQoKG4L38Ucj1sBReNpPDbovTivNBQ@mail.gmail.com>
Message-ID: <CAAhSdy3kNJwb+pZ_ZwNPNbPE7nrzp5H-zgYyudHVJkqk2LBJSw@mail.gmail.com>

On Sun, Apr 28, 2013 at 11:39 PM, Christoffer Dall
<cdall at cs.columbia.edu> wrote:
> On Sat, Apr 27, 2013 at 1:09 AM, Anup Patel <anup.patel at linaro.org> wrote:
>> This patch does arch_timer reset (i.e. kvm_timer_vcpu_reset()) when a vcpu resetted by kvm_reset_vcpu().
>>
>> The kvm_reset_vcpu() also informs guest timer irq number to arch_timer code via kvm_timer_vcpu_reset().
>>
>> Signed-off-by: Anup Patel <anup.patel at linaro.org>
>> Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar at linaro.org>
>> ---
>>  arch/arm64/include/asm/kvm_arch_timer.h |    2 ++
>>  arch/arm64/kvm/reset.c                  |   11 ++++++++++-
>>  2 files changed, 12 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/include/asm/kvm_arch_timer.h b/arch/arm64/include/asm/kvm_arch_timer.h
>> index eb02273..04949c6 100644
>> --- a/arch/arm64/include/asm/kvm_arch_timer.h
>> +++ b/arch/arm64/include/asm/kvm_arch_timer.h
>> @@ -50,6 +50,8 @@ struct arch_timer_cpu {
>>
>>  int kvm_timer_hyp_init(void);
>>  int kvm_timer_init(struct kvm *kvm);
>> +int kvm_timer_vcpu_reset(struct kvm_vcpu *vcpu,
>> +                        const struct kvm_irq_level *irq);
>>  void kvm_timer_vcpu_init(struct kvm_vcpu *vcpu);
>>  void kvm_timer_flush_hwstate(struct kvm_vcpu *vcpu);
>>  void kvm_timer_sync_hwstate(struct kvm_vcpu *vcpu);
>> diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
>> index 64e0740..1e255a3 100644
>> --- a/arch/arm64/kvm/reset.c
>> +++ b/arch/arm64/kvm/reset.c
>> @@ -27,6 +27,7 @@
>>  #include <asm/ptrace.h>
>>  #include <asm/kvm_arm.h>
>>  #include <asm/kvm_coproc.h>
>> +#include <asm/kvm_arch_timer.h>
>>
>>  /*
>>   * ARMv8 Reset Values
>> @@ -40,6 +41,11 @@ static struct kvm_regs default_regs_reset32 = {
>>                         COMPAT_PSR_I_BIT | COMPAT_PSR_F_BIT),
>>  };
>>
>> +static struct kvm_irq_level default_timer_irq = {
>> +       .irq = 27,
>> +       .level = 1,
>> +};
>> +
>>  static bool cpu_has_32bit_el1(void)
>>  {
>>         u64 pfr0;
>> @@ -75,6 +81,7 @@ int kvm_arch_dev_ioctl_check_extension(long ext)
>>  int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
>>  {
>>         struct kvm_regs *cpu_reset;
>> +       const struct kvm_irq_level *cpu_irq;
>>
>>         switch (vcpu->arch.target) {
>>         default:
>> @@ -86,6 +93,7 @@ int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
>>                 } else {
>>                         cpu_reset = &default_regs_reset;
>>                 }
>> +               cpu_irq = &default_timer_irq;
>
> what's the reason for naming this cpu_irq?
>
> seems to me it should be vtimer_irq or something to that affect...

oke, i'll name it cpu_vtimer_irq.

>
>>                 break;
>>         }
>>
>> @@ -95,5 +103,6 @@ int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
>>         /* Reset system registers */
>>         kvm_reset_sys_regs(vcpu);
>>
>> -       return 0;
>> +       /* Reset arch_timer context */
>> +       return kvm_timer_vcpu_reset(vcpu, cpu_irq);
>>  }
>> --
>> 1.7.9.5
>>
>> _______________________________________________
>> kvmarm mailing list
>> kvmarm at lists.cs.columbia.edu
>> https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
> _______________________________________________
> kvmarm mailing list
> kvmarm at lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm

--Anup


From olof at lixom.net  Sun Apr 28 15:17:51 2013
From: olof at lixom.net (Olof Johansson)
Date: Sun, 28 Apr 2013 12:17:51 -0700
Subject: [PATCH v3 00/13] ARM: EXYNOS: Fix Universal C210 support
In-Reply-To: <517CC731.2050401@samsung.com>
References: <1366731994-7478-1-git-send-email-t.figa@samsung.com>
 <201304251646.28026.arnd@arndb.de>
 <20130427003413.GA2350@quad.lixom.net>
 <517CC731.2050401@samsung.com>
Message-ID: <20130428191751.GA22332@quad.lixom.net>

On Sun, Apr 28, 2013 at 03:52:33PM +0900, Kukjin Kim wrote:
> On 04/27/13 09:34, Olof Johansson wrote:
> 
> [...]
> 
> >>>On Universal C210 board, both with and without DT:
> >>>
> >>>Tested-by: Tomasz Figa<t.figa at samsung.com>
> >>
> >>Reviewed-by: Arnd Bergmann<arnd at arndb.de>
> >>
> >>Olof, Kgene, I think we should have this one in 3.10 since it fixes
> >>a regression. It looks bigger than it really is because I asked Tomasz
> >>to do small patches rather than a single combined patch.
> >
> >Ok. Kukjin, I don't mind collecting this in a late/* branch even though time is
> >running late, since it's a regression. Do you want to send it to me or should
> >I just pick up the patches?
> >
> Olof, since too late, would be better if you could pick up this
> series in the late/* branch with my ack:
> 
> Acked-by: Kukjin Kim <kgene.kim at samsung.com>

I have applied everything but 11/13 since it had heavy conflicts (I'll commment
on that patch separately).


-Olof


From olof at lixom.net  Sun Apr 28 15:22:31 2013
From: olof at lixom.net (Olof Johansson)
Date: Sun, 28 Apr 2013 12:22:31 -0700
Subject: [PATCH v3 11/13] ARM: EXYNOS: Fix support of Exynos4210 rev0 SoC
In-Reply-To: <1366731994-7478-12-git-send-email-t.figa@samsung.com>
References: <1366731994-7478-1-git-send-email-t.figa@samsung.com>
 <1366731994-7478-12-git-send-email-t.figa@samsung.com>
Message-ID: <20130428192231.GB22332@quad.lixom.net>

On Tue, Apr 23, 2013 at 05:46:32PM +0200, Tomasz Figa wrote:
> This patch extends exynos_init_time() function to handle Exynos4210 rev0
> SoC, which differs in availability of system timers and needs different
> clocksource initialization.
> 
> This makes it possible to use exynos_init_time() function as init_time
> callback for all Exynos-based boards, including Universal_C210, which
> originally had to use samsung_timer_init().
> 
> Signed-off-by: Tomasz Figa <t.figa at samsung.com>
> Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>

I didn't apply this one since I had massive conflicts caused by it. Can you
please resubmit on top of late/fixes?

Thanks,


-Olof


From olof at lixom.net  Sun Apr 28 15:26:24 2013
From: olof at lixom.net (Olof Johansson)
Date: Sun, 28 Apr 2013 12:26:24 -0700
Subject: [GIT PULL] Late Samsung stuff (v3) for v3.10
In-Reply-To: <51795CE8.2060105@samsung.com>
References: <51795CE8.2060105@samsung.com>
Message-ID: <20130428192624.GC22332@quad.lixom.net>

On Fri, Apr 26, 2013 at 01:42:16AM +0900, Kukjin Kim wrote:
> The following changes since commit 59a7bbf75442ea439a4d3b7993ad87023e406063:
> 
>   ARM: dts: add PDMA0 changes for exynos5440 (2013-04-09 01:39:27 +0900)
> 
> are available in the git repository at:
> 

> git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
> tags/late-exynos-v3-for-v3.10
> 
> for you to fetch changes up to 096ee6adcfb79a13ae04150023725c8a67e00ae8:
> 
>   ARM: dts: Add chip-id controller node on Exynos4/5 SoC (2013-04-26
> 01:21:44 +0900)
> 
> ----------------------------------------------------------------
> This allows that device tree enables platform to setup a runtime IO
> mapping for the chip id
> 

Thanks, pulled into late/dt.


-Olof


From tomasz.figa at gmail.com  Sun Apr 28 18:17:38 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Mon, 29 Apr 2013 00:17:38 +0200
Subject: [PATCH v3 11/13] ARM: EXYNOS: Fix support of Exynos4210 rev0 SoC
In-Reply-To: <20130428192231.GB22332@quad.lixom.net>
References: <1366731994-7478-1-git-send-email-t.figa@samsung.com>
 <1366731994-7478-12-git-send-email-t.figa@samsung.com>
 <20130428192231.GB22332@quad.lixom.net>
Message-ID: <1736061.BDRHr9MsyY@flatron>

On Sunday 28 of April 2013 12:22:31 Olof Johansson wrote:
> On Tue, Apr 23, 2013 at 05:46:32PM +0200, Tomasz Figa wrote:
> > This patch extends exynos_init_time() function to handle Exynos4210
> > rev0 SoC, which differs in availability of system timers and needs
> > different clocksource initialization.
> > 
> > This makes it possible to use exynos_init_time() function as init_time
> > callback for all Exynos-based boards, including Universal_C210, which
> > originally had to use samsung_timer_init().
> > 
> > Signed-off-by: Tomasz Figa <t.figa at samsung.com>
> > Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
> 
> I didn't apply this one since I had massive conflicts caused by it. Can
> you please resubmit on top of late/fixes?

As we discussed on IRC, since this patch has multiple dependencies, let's 
wait until everything settles and apply it then, as an rc fix to avoid 
further merge conflicts.

Best regards,
Tomasz



From rusty at rustcorp.com.au  Sun Apr 28 23:09:34 2013
From: rusty at rustcorp.com.au (Rusty Russell)
Date: Mon, 29 Apr 2013 12:39:34 +0930
Subject: [PATCH 0/2] Early printk support for virtio console devices.
In-Reply-To: <BA2076A6-0688-4E5C-85F9-A9CA8FD75782@suse.de>
References: <1366974299-17877-1-git-send-email-pranavkumar@linaro.org>
 <BA2076A6-0688-4E5C-85F9-A9CA8FD75782@suse.de>
Message-ID: <87obcyc9sh.fsf@rustcorp.com.au>

Alexander Graf <agraf at suse.de> writes:
> On 26.04.2013, at 13:04, Pranavkumar Sawargaonkar wrote:
>
>> This patch-set implements early printk support for virtio console devices without using any hypercalls.
>> 
>> The current virtio early printk code in kernel expects that hypervisor will provide some mechanism generally a hypercall to support early printk. This patch-set does not break existing hypercall based early print support.
>> 
>> This implementation adds:
>> 1. Early writeonly register named early_wr in virtio console's config space.
>> 2. Host feature flags namely VIRTIO_CONSOLE_F_EARLY_WRITE for telling guest about early-write capability in console device.
>> 
>> Early write mechanism:
>> 1. When a guest wants to out some character, it has to simply write the character to early_wr register in config space of virtio console device.
>
> I won't nack this patch set, but I'll definitely express that I'm not happy with it.
>
> MMIO registers are handled by a different layer than the virtio console itself. After the virtio refactoring in QEMU, they will be completely separate drivers. So we'll be in a similar mess with early printk as we are on the s390-virtio machine, where early printk is done through hypercalls and thus we can't directly link it to the console output.
>
> I still don't see what the issue is with just implementing a small irq-less virtio driver for early printk.

Well, this shouldn't be mmio-specific, but I kind of get what you mean.

I consider this misnamed: it's an emergency write facility.  Linux may
use it for an early console, but it's also useful for bringup and to
give a method of emitting errors like "the console ring is corrupt".

A valid implementation may well be to only offer it with some magic
qemu developer-only commandline and dump it to stdout.

So I think it has use, but less so if QEMU isn't ever going to implement
it.

Cheers,
Rusty.



From rusty at rustcorp.com.au  Sun Apr 28 23:10:23 2013
From: rusty at rustcorp.com.au (Rusty Russell)
Date: Mon, 29 Apr 2013 12:40:23 +0930
Subject: [PATCH 1/2] virtio: console: Add early writeonly register to
 config space
In-Reply-To: <1366974299-17877-2-git-send-email-pranavkumar@linaro.org>
References: <1366974299-17877-1-git-send-email-pranavkumar@linaro.org>
 <1366974299-17877-2-git-send-email-pranavkumar@linaro.org>
Message-ID: <87mwsic9r4.fsf@rustcorp.com.au>

Pranavkumar Sawargaonkar <pranavkumar at linaro.org> writes:
> This patch adds a early_wr register (writeonly) in config space of virtio console device which can be used for debugging.
>
> The patch also updates virtio-spec in Documentation to reflect this feature addition in virtio console.

Perhaps change the name to VIRTIO_CONSOLE_F_EMERGENCY_WRITE.  But let's
resolve the qemu discussion first...

Cheers,
Rusty.


From jaswinder.singh at linaro.org  Mon Apr 29 00:07:30 2013
From: jaswinder.singh at linaro.org (Jassi Brar)
Date: Mon, 29 Apr 2013 09:37:30 +0530
Subject: [GIT PULL] mailbox driver framework for v3.10 merge window
In-Reply-To: <201304091255.03020.arnd@arndb.de>
References: <37C860A02101E749A747FA2D3C1E3C504A1971@DLEE11.ent.ti.com>
 <201304091255.03020.arnd@arndb.de>
Message-ID: <CAJe_Zhf5QwQQU5aVtNhbDT3EK9Dof-ZK_boP9WaNghqO8xY7iA@mail.gmail.com>

Hello Arnd,

On 9 April 2013 16:25, Arnd Bergmann <arnd at arndb.de> wrote:
> On Thursday 04 April 2013, Anna, Suman wrote:
>> OMAP and ST-Ericsson platforms are both using mailbox to communicate with some coprocessors. This series creates a consolidated framework, living under drivers/mailbox.
>> The changes mainly contain:
>> - create a mailbox framework independent from OMAP h/w
>> - creates dbx500 mailbox driver for ST-Ericsson platforms
>> - move the omap mailbox out of plat-omap/mach-omapX  adapting to the new framework.
>> - minor bug fixes in mailbox code
>
> Pulled into a new next/mailbox branch, to keep it separate from the
> existing subsystems.
>
I am going to be a heavy user of the Mailbox API. And I have reviewed
this API quite in detail. I pointed out many aspects that might have
worked for TI's usage but are not going to be work on many platforms
(including one of mine).  Suman and Loic also acknowledged most (if
not all) from 'generic' POV.  Here is the thread ...
   http://www.spinics.net/lists/arm-kernel/msg239433.html

Not to mean only talk and no do, I prepared another proposal that
addressed all the concerns shared so far in the RFC
http://www.spinics.net/lists/kernel/msg1523873.html (its not ready for
primetime yet)  And also converted the PL320 driver to the new API,
unlike the pulled patchset which leaves that out in the cold.
http://www.spinics.net/lists/kernel/msg1523874.html

Now, we could either call it (effectively the TI's framework with
quirks for STE) as the "Common API" and then dismantle and convert it
patch by patch (authors and I seem to agree many things need to be
changed and implemented).
  OR we do it reasonably right the first time even if that means yet
another release. IMHO we should go for slow but steady thing.

Hi Suman, Hi Loic,
   Please feel free to object to anything you think I might have
misrepresented. I am OK if you are not sure about my implementation
either - we could co-work on a new one.

Regards,
-Jassi


From cdall at cs.columbia.edu  Mon Apr 29 01:29:07 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Sun, 28 Apr 2013 22:29:07 -0700
Subject: [GIT PULL] KVM/ARM Changes for 3.10
Message-ID: <CAEDV+gKXcCb11p5YCQRbQ1OwGefxYUr0sh8f4AOfxQSPPo2LMQ@mail.gmail.com>

Hi Marcelo and Gleb,

These are the changes for KVM/ARM for 3.10.

The patches depend on the cleanup branch, which you've already merged.

Main thing is the reworking of Hyp idmaps, which is now handled by KVM
instead of arm/mm and includes several nasty bug fixes from Marc in
the progress.

Thanks!

The following changes since commit 5a2892ce72e010e3cb96b438d7cdddce0c88e0e6:

  KVM: nVMX: Skip PF interception check when queuing during nested run
(2013-04-28 13:34:39 +0300)

are available in the git repository at:

  git://github.com/columbia/linux-kvm-arm.git kvm-arm-for-3.10

for you to fetch changes up to d4e071ce6acf8d5eddb7615a953193a8b0ad7c38:

  ARM: KVM: iterate over all CPUs for CPU compatibility check
(2013-04-28 22:23:23 -0700)

----------------------------------------------------------------
Andre Przywara (1):
      ARM: KVM: iterate over all CPUs for CPU compatibility check

Arnd Bergmann (1):
      ARM: KVM: define KVM_ARM_MAX_VCPUS unconditionally

Christoffer Dall (2):
      KVM: ARM: Fix API documentation for ONE_REG encoding
      KVM: ARM: Fix spelling in error message

Marc Zyngier (10):
      ARM: KVM: add support for minimal host vs guest profiling
      ARM: KVM: simplify HYP mapping population
      ARM: KVM: fix HYP mapping limitations around zero
      ARM: KVM: move to a KVM provided HYP idmap
      ARM: KVM: enforce maximum size for identity mapped code
      ARM: KVM: rework HYP page table freeing
      ARM: KVM: switch to a dual-step HYP init code
      ARM: KVM: perform HYP initilization for hotplugged CPUs
      ARM: KVM: add architecture specific hook for capabilities
      ARM: KVM: promote vfp_host pointer to generic host cpu context

Mark Rutland (1):
      ARM: KVM: arch_timer: use symbolic constants

 Documentation/virtual/kvm/api.txt |   12 +-
 arch/arm/include/asm/idmap.h      |    1 -
 arch/arm/include/asm/kvm_host.h   |   47 ++--
 arch/arm/include/asm/kvm_mmu.h    |   28 ++-
 arch/arm/kernel/asm-offsets.c     |    2 +-
 arch/arm/kernel/vmlinux.lds.S     |    7 +-
 arch/arm/kvm/Kconfig              |    6 +-
 arch/arm/kvm/Makefile             |    2 +-
 arch/arm/kvm/arch_timer.c         |    7 +-
 arch/arm/kvm/arm.c                |  111 +++++----
 arch/arm/kvm/handle_exit.c        |    2 +-
 arch/arm/kvm/init.S               |   78 +++++--
 arch/arm/kvm/mmu.c                |  455 +++++++++++++++++++++----------------
 arch/arm/kvm/perf.c               |   68 ++++++
 arch/arm/mm/idmap.c               |   32 +--
 15 files changed, 532 insertions(+), 326 deletions(-)
 create mode 100644 arch/arm/kvm/perf.c


From inki.dae at samsung.com  Mon Apr 29 01:32:01 2013
From: inki.dae at samsung.com (Inki Dae)
Date: Mon, 29 Apr 2013 14:32:01 +0900
Subject: [PATCH] module: fix mutiple defined issue
Message-ID: <1367213521-26795-1-git-send-email-inki.dae@samsung.com>

This patch fixes mutiple defined issue to MODULE_DEVICE_TABLE

The issue could be induced when some framework which includes two
more sub drivers, is built as one moudle because those sub drivers
could have their own MODULE_DEVICE_TABLE.

And 'struct of_device_id' isn't needed to be determined by type
argument because the definition of 'of_device_id' should be fixed.
So this patch makes 'of_devce_id' definition to be fixed and
only its instance name to be defined by type.

Signed-off-by: Inki Dae <inki.dae at samsung.com>
---
 include/linux/module.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/include/linux/module.h b/include/linux/module.h
index 46f1ea0..ac5d79f 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -84,7 +84,7 @@ void trim_init_extable(struct module *m);
 
 #ifdef MODULE
 #define MODULE_GENERIC_TABLE(gtype,name)			\
-extern const struct gtype##_id __mod_##gtype##_table		\
+extern const struct of_device_id __mod_##gtype##_table		\
   __attribute__ ((unused, alias(__stringify(name))))
 
 #else  /* !MODULE */
-- 
1.7.5.4



From anup.patel at linaro.org  Mon Apr 29 03:28:20 2013
From: anup.patel at linaro.org (Anup Patel)
Date: Mon, 29 Apr 2013 12:58:20 +0530
Subject: [PATCH V2] arm64: KVM: Reset arch_timer upon vcpu reset
Message-ID: <1367220500-5690-1-git-send-email-anup.patel@linaro.org>

This patch does arch_timer reset (i.e. kvm_timer_vcpu_reset()) when
a vcpu resetted by kvm_reset_vcpu().

The kvm_reset_vcpu() also informs guest timer irq number to arch_timer
code via kvm_timer_vcpu_reset().

Signed-off-by: Anup Patel <anup.patel at linaro.org>
Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar at linaro.org>
---
 arch/arm64/include/asm/kvm_arch_timer.h |    2 ++
 arch/arm64/kvm/reset.c                  |   11 +++++++++++
 2 files changed, 13 insertions(+)

diff --git a/arch/arm64/include/asm/kvm_arch_timer.h b/arch/arm64/include/asm/kvm_arch_timer.h
index eb02273..0f36603 100644
--- a/arch/arm64/include/asm/kvm_arch_timer.h
+++ b/arch/arm64/include/asm/kvm_arch_timer.h
@@ -50,6 +50,8 @@ struct arch_timer_cpu {
 
 int kvm_timer_hyp_init(void);
 int kvm_timer_init(struct kvm *kvm);
+void kvm_timer_vcpu_reset(struct kvm_vcpu *vcpu, 
+			  const struct kvm_irq_level *irq);
 void kvm_timer_vcpu_init(struct kvm_vcpu *vcpu);
 void kvm_timer_flush_hwstate(struct kvm_vcpu *vcpu);
 void kvm_timer_sync_hwstate(struct kvm_vcpu *vcpu);
diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
index 64e0740..7c9cebc 100644
--- a/arch/arm64/kvm/reset.c
+++ b/arch/arm64/kvm/reset.c
@@ -27,6 +27,7 @@
 #include <asm/ptrace.h>
 #include <asm/kvm_arm.h>
 #include <asm/kvm_coproc.h>
+#include <asm/kvm_arch_timer.h>
 
 /*
  * ARMv8 Reset Values
@@ -40,6 +41,11 @@ static struct kvm_regs default_regs_reset32 = {
 			COMPAT_PSR_I_BIT | COMPAT_PSR_F_BIT),
 };
 
+static const struct kvm_irq_level default_vtimer_irq = {
+	.irq = 27,
+	.level = 1,
+};
+
 static bool cpu_has_32bit_el1(void)
 {
 	u64 pfr0;
@@ -75,6 +81,7 @@ int kvm_arch_dev_ioctl_check_extension(long ext)
 int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
 {
 	struct kvm_regs *cpu_reset;
+	const struct kvm_irq_level *cpu_vtimer_irq;
 
 	switch (vcpu->arch.target) {
 	default:
@@ -86,6 +93,7 @@ int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
 		} else {
 			cpu_reset = &default_regs_reset;
 		}
+		cpu_vtimer_irq = &default_vtimer_irq;
 		break;
 	}
 
@@ -95,5 +103,8 @@ int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
 	/* Reset system registers */
 	kvm_reset_sys_regs(vcpu);
 
+	/* Reset arch_timer context */
+	kvm_timer_vcpu_reset(vcpu, cpu_vtimer_irq);
+
 	return 0;
 }
-- 
1.7.9.5



From vincent.guittot at linaro.org  Mon Apr 29 03:32:30 2013
From: vincent.guittot at linaro.org (Vincent Guittot)
Date: Mon, 29 Apr 2013 09:32:30 +0200
Subject: [PATCH 10/14] sched: update the buddy CPU
In-Reply-To: <517CDBDB.1020608@gmail.com>
References: <1366910611-20048-1-git-send-email-vincent.guittot@linaro.org>
 <1366910611-20048-11-git-send-email-vincent.guittot@linaro.org>
 <517CDBDB.1020608@gmail.com>
Message-ID: <CAKfTPtAJJc5kcn07HrwB6FQmX+qyGFgMCOYsd3f6SWZP=Rpa5Q@mail.gmail.com>

On 28 April 2013 10:20, Francesco Lavra <francescolavra.fl at gmail.com> wrote:
> Hi,
>
> On 04/25/2013 07:23 PM, Vincent Guittot wrote:
>> Periodically updates the buddy of a CPU according to the current activity of
>> the system. A CPU is its own buddy if it participates to the packing effort.
>> Otherwise, it points to a CPU that participates to the packing effort.
>>
>> Signed-off-by: Vincent Guittot <vincent.guittot at linaro.org>
>> ---
>>  kernel/sched/fair.c |   91 ++++++++++++++++++++++++++++++++++++++++++++++++---
>>  1 file changed, 86 insertions(+), 5 deletions(-)
>>
>> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
>> index 234ecdd..28f8ea7 100644
>> --- a/kernel/sched/fair.c
>> +++ b/kernel/sched/fair.c
>> @@ -174,11 +174,17 @@ void sched_init_granularity(void)
>>
>>
>>  #ifdef CONFIG_SMP
>> +static unsigned long power_of(int cpu)
>> +{
>> +     return cpu_rq(cpu)->cpu_power;
>> +}
>> +
>>  /*
>>   * Save the id of the optimal CPU that should be used to pack small tasks
>>   * The value -1 is used when no buddy has been found
>>   */
>>  DEFINE_PER_CPU(int, sd_pack_buddy);
>> +DEFINE_PER_CPU(struct sched_domain *, sd_pack_domain);
>>
>>  /*
>>   * Look for the best buddy CPU that can be used to pack small tasks
>> @@ -237,6 +243,68 @@ void update_packing_domain(int cpu)
>>       }
>>
>>       pr_debug("CPU%d packing on CPU%d\n", cpu, id);
>> +     per_cpu(sd_pack_domain, cpu) = sd;
>> +     per_cpu(sd_pack_buddy, cpu) = id;
>> +}
>> +
>> +void update_packing_buddy(int cpu, int activity)
>> +{
>> +     struct sched_domain *sd = per_cpu(sd_pack_domain, cpu);
>> +     struct sched_group *sg, *pack, *tmp;
>> +     int id = cpu;
>> +
>> +     if (!sd)
>> +             return;
>> +
>> +     /*
>> +      * The sched_domain of a CPU points on the local sched_group
>> +      * and this CPU of this local group is a good candidate
>> +      */
>> +     pack = sg = sd->groups;
>> +
>> +     /* loop the sched groups to find the best one */
>> +     for (tmp = sg->next; tmp != sg; tmp = tmp->next) {
>> +             if ((tmp->sgp->power * pack->group_weight) >
>> +                     (pack->sgp->power_available * tmp->group_weight))
>
> The power_available struct member is defined in a subsequent patch
> (12/14), so this patch series would break git bisect.

Hi Francesco,

yes, power_available should have been added in patch 13/14.
I will correct that

Thanks
Vincent

>
> --
> Francesco


From anup.patel at linaro.org  Mon Apr 29 03:25:47 2013
From: anup.patel at linaro.org (Anup Patel)
Date: Mon, 29 Apr 2013 12:55:47 +0530
Subject: [PATCH V2] ARM: KVM: Allow host virt timer irq to be different from
 guest timer virt irq
Message-ID: <1367220347-5625-1-git-send-email-anup.patel@linaro.org>

The arch_timer irq numbers (or PPI numbers) are implementation dependent
so, the host virtual timer irq number can be different from guest virtual
timer irq number.

This patch ensures that host virtual timer irq number is read from DTB and
guest virtual timer irq is determined based on vcpu target type.

Signed-off-by: Anup Patel <anup.patel at linaro.org>
Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar at linaro.org>
---
 arch/arm/include/asm/kvm_arch_timer.h |    4 ++++
 arch/arm/kvm/arch_timer.c             |   27 ++++++++++++++++++++-------
 arch/arm/kvm/reset.c                  |   11 +++++++++++
 3 files changed, 35 insertions(+), 7 deletions(-)

diff --git a/arch/arm/include/asm/kvm_arch_timer.h b/arch/arm/include/asm/kvm_arch_timer.h
index 68cb9e1..eeb2a3f 100644
--- a/arch/arm/include/asm/kvm_arch_timer.h
+++ b/arch/arm/include/asm/kvm_arch_timer.h
@@ -61,6 +61,8 @@ struct arch_timer_cpu {
 #ifdef CONFIG_KVM_ARM_TIMER
 int kvm_timer_hyp_init(void);
 int kvm_timer_init(struct kvm *kvm);
+void kvm_timer_vcpu_reset(struct kvm_vcpu *vcpu, 
+			  const struct kvm_irq_level *irq);
 void kvm_timer_vcpu_init(struct kvm_vcpu *vcpu);
 void kvm_timer_flush_hwstate(struct kvm_vcpu *vcpu);
 void kvm_timer_sync_hwstate(struct kvm_vcpu *vcpu);
@@ -76,6 +78,8 @@ static inline int kvm_timer_init(struct kvm *kvm)
 	return 0;
 }
 
+static inline void kvm_timer_vcpu_reset(struct kvm_vcpu *vcpu, 
+					const struct kvm_irq_level *irq) {}
 static inline void kvm_timer_vcpu_init(struct kvm_vcpu *vcpu) {}
 static inline void kvm_timer_flush_hwstate(struct kvm_vcpu *vcpu) {}
 static inline void kvm_timer_sync_hwstate(struct kvm_vcpu *vcpu) {}
diff --git a/arch/arm/kvm/arch_timer.c b/arch/arm/kvm/arch_timer.c
index 49a7516..c64b597 100644
--- a/arch/arm/kvm/arch_timer.c
+++ b/arch/arm/kvm/arch_timer.c
@@ -30,7 +30,7 @@
 
 static struct timecounter *timecounter;
 static struct workqueue_struct *wqueue;
-static struct kvm_irq_level timer_irq = {
+static struct kvm_irq_level host_timer_irq = {
 	.level	= 1,
 };
 
@@ -67,8 +67,8 @@ static void kvm_timer_inject_irq(struct kvm_vcpu *vcpu)
 
 	timer->cntv_ctl |= ARCH_TIMER_CTRL_IT_MASK;
 	kvm_vgic_inject_irq(vcpu->kvm, vcpu->vcpu_id,
-			    vcpu->arch.timer_cpu.irq->irq,
-			    vcpu->arch.timer_cpu.irq->level);
+			    timer->irq->irq,
+			    timer->irq->level);
 }
 
 static irqreturn_t kvm_arch_timer_handler(int irq, void *dev_id)
@@ -156,6 +156,20 @@ void kvm_timer_sync_hwstate(struct kvm_vcpu *vcpu)
 	timer_arm(timer, ns);
 }
 
+void kvm_timer_vcpu_reset(struct kvm_vcpu *vcpu, 
+			  const struct kvm_irq_level *irq)
+{
+	struct arch_timer_cpu *timer = &vcpu->arch.timer_cpu;
+
+	/*
+	 * The vcpu timer irq number cannot be determined in 
+	 * kvm_timer_vcpu_init() because it is called much before
+	 * kvm_vcpu_set_target(). To handle this, we determine
+	 * vcpu timer irq number when the vcpu is resetted.
+	 */
+	timer->irq = irq;
+}
+
 void kvm_timer_vcpu_init(struct kvm_vcpu *vcpu)
 {
 	struct arch_timer_cpu *timer = &vcpu->arch.timer_cpu;
@@ -163,12 +177,11 @@ void kvm_timer_vcpu_init(struct kvm_vcpu *vcpu)
 	INIT_WORK(&timer->expired, kvm_timer_inject_irq_work);
 	hrtimer_init(&timer->timer, CLOCK_MONOTONIC, HRTIMER_MODE_ABS);
 	timer->timer.function = kvm_timer_expire;
-	timer->irq = &timer_irq;
 }
 
 static void kvm_timer_init_interrupt(void *info)
 {
-	enable_percpu_irq(timer_irq.irq, 0);
+	enable_percpu_irq(host_timer_irq.irq, 0);
 }
 
 
@@ -182,7 +195,7 @@ static int kvm_timer_cpu_notify(struct notifier_block *self,
 		break;
 	case CPU_DYING:
 	case CPU_DYING_FROZEN:
-		disable_percpu_irq(timer_irq.irq);
+		disable_percpu_irq(host_timer_irq.irq);
 		break;
 	}
 
@@ -230,7 +243,7 @@ int kvm_timer_hyp_init(void)
 		goto out;
 	}
 
-	timer_irq.irq = ppi;
+	host_timer_irq.irq = ppi;
 
 	err = register_cpu_notifier(&kvm_timer_cpu_nb);
 	if (err) {
diff --git a/arch/arm/kvm/reset.c b/arch/arm/kvm/reset.c
index b80256b..0b49ad7 100644
--- a/arch/arm/kvm/reset.c
+++ b/arch/arm/kvm/reset.c
@@ -26,6 +26,7 @@
 #include <asm/cputype.h>
 #include <asm/kvm_arm.h>
 #include <asm/kvm_coproc.h>
+#include <asm/kvm_arch_timer.h>
 
 /******************************************************************************
  * Cortex-A15 Reset Values
@@ -37,6 +38,11 @@ static struct kvm_regs a15_regs_reset = {
 	.usr_regs.ARM_cpsr = SVC_MODE | PSR_A_BIT | PSR_I_BIT | PSR_F_BIT,
 };
 
+static const struct kvm_irq_level a15_vtimer_irq = {
+	.irq = 27,
+	.level = 1,
+};
+
 
 /*******************************************************************************
  * Exported reset function
@@ -52,6 +58,7 @@ static struct kvm_regs a15_regs_reset = {
 int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
 {
 	struct kvm_regs *cpu_reset;
+	const struct kvm_irq_level *cpu_vtimer_irq;
 
 	switch (vcpu->arch.target) {
 	case KVM_ARM_TARGET_CORTEX_A15:
@@ -59,6 +66,7 @@ int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
 			return -EINVAL;
 		cpu_reset = &a15_regs_reset;
 		vcpu->arch.midr = read_cpuid_id();
+		cpu_vtimer_irq = &a15_vtimer_irq;
 		break;
 	default:
 		return -ENODEV;
@@ -70,5 +78,8 @@ int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
 	/* Reset CP15 registers */
 	kvm_reset_coprocs(vcpu);
 
+	/* Reset arch_timer context */
+	kvm_timer_vcpu_reset(vcpu, cpu_vtimer_irq);
+
 	return 0;
 }
-- 
1.7.9.5



From u.kleine-koenig at pengutronix.de  Mon Apr 29 03:35:18 2013
From: u.kleine-koenig at pengutronix.de (Uwe =?iso-8859-1?Q?Kleine-K=F6nig?=)
Date: Mon, 29 Apr 2013 09:35:18 +0200
Subject: [PATCH] module: fix mutiple defined issue
In-Reply-To: <1367213521-26795-1-git-send-email-inki.dae@samsung.com>
References: <1367213521-26795-1-git-send-email-inki.dae@samsung.com>
Message-ID: <20130429073518.GZ15233@pengutronix.de>

On Mon, Apr 29, 2013 at 02:32:01PM +0900, Inki Dae wrote:
> This patch fixes mutiple defined issue to MODULE_DEVICE_TABLE
s/mutiple/multiple/, still this sentence doesn't sound right. What is
the error message you see?
 
> The issue could be induced when some framework which includes two
> more sub drivers, is built as one moudle because those sub drivers
s/moudle/module/

> could have their own MODULE_DEVICE_TABLE.
> 
> And 'struct of_device_id' isn't needed to be determined by type
> argument because the definition of 'of_device_id' should be fixed.
> So this patch makes 'of_devce_id' definition to be fixed and
> only its instance name to be defined by type.
include/linux/isapnp.h uses:
#define ISAPNP_CARD_TABLE(name) \
		MODULE_GENERIC_TABLE(isapnp_card, name)

and you changed the table's type with your patch. Ditto for all users of

	MODULE_DEVICE_TABLE(i2c, ...);
	MODULE_DEVICE_TABLE(acpi, ...);
	MODULE_DEVICE_TABLE(platform, ...);
	MODULE_DEVICE_TABLE(pci, ...);
	MODULE_DEVICE_TABLE(sdio, ...);

So I'm pretty sure your patch is wrong and I expect it makes most
defconfigs fail to compile.

Best regards
Uwe

> 
> Signed-off-by: Inki Dae <inki.dae at samsung.com>
> ---
>  include/linux/module.h |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/include/linux/module.h b/include/linux/module.h
> index 46f1ea0..ac5d79f 100644
> --- a/include/linux/module.h
> +++ b/include/linux/module.h
> @@ -84,7 +84,7 @@ void trim_init_extable(struct module *m);
>  
>  #ifdef MODULE
>  #define MODULE_GENERIC_TABLE(gtype,name)			\
> -extern const struct gtype##_id __mod_##gtype##_table		\
> +extern const struct of_device_id __mod_##gtype##_table		\
>    __attribute__ ((unused, alias(__stringify(name))))
>  
>  #else  /* !MODULE */
> -- 
> 1.7.5.4
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |


From linux at prisktech.co.nz  Mon Apr 29 03:50:38 2013
From: linux at prisktech.co.nz (Tony Prisk)
Date: Mon, 29 Apr 2013 19:50:38 +1200
Subject: [PATCHv2 0/3] Add support for velocity network driver on platform
 devices
Message-ID: <1367221841-14563-1-git-send-email-linux@prisktech.co.nz>

v2 changes:
Drop patch #1 as requested by David Miller.
Correct the PHYID_ICPLUS_IP101A MII bits - should be ON, rather than OFF.
Read the platform rev_id from the correct register [regs->rev_id]. It's possible
this would work for the PCI version as well and would remove the need for the
'if (pci)' test to set vptr->rev_id.

v1:
The first three patches are general tidyup.

[DROPPED] Patch ## just alphabetizes the #includes to make it easier to read.

Patch #1 replaces vptr->dev with vptr->netdev, in preparation of adding a
struct device *dev in Patch #3

Patch #2 replaces the pci dma functions with the generic versions.

I have build tested these patches but don't have a PCI velocity to run-test it.
I can't see that they should introduce any problems as it is all renames and
function swapping.

Patch #3 adds support for the velocity driver on devicetree platform devices.
Binding document included. This patch is compile-tested for PCI, and boot
tested on a VIA APC8750.

I think it would be pertinent to get some tested-by's for PCI users.

Regards
Tony Prisk

Tony Prisk (3):
  net: velocity: Rename vptr->dev to vptr->netdev
  net: velocity: Convert to generic dma functions
  net: velocity: Add platform device support to VIA velocity driver

 .../devicetree/bindings/net/via-velocity.txt       |   20 +
 drivers/net/ethernet/via/Kconfig                   |    3 +-
 drivers/net/ethernet/via/via-velocity.c            |  564 ++++++++++++++------
 drivers/net/ethernet/via/via-velocity.h            |   35 +-
 4 files changed, 456 insertions(+), 166 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/net/via-velocity.txt

-- 
1.7.9.5



From linux at prisktech.co.nz  Mon Apr 29 03:50:40 2013
From: linux at prisktech.co.nz (Tony Prisk)
Date: Mon, 29 Apr 2013 19:50:40 +1200
Subject: [PATCHv2 2/3] net: velocity: Convert to generic dma functions
In-Reply-To: <1367221841-14563-1-git-send-email-linux@prisktech.co.nz>
References: <1367221841-14563-1-git-send-email-linux@prisktech.co.nz>
Message-ID: <1367221841-14563-3-git-send-email-linux@prisktech.co.nz>

Remove the pci_* dma functions and replace with the more generic
versions.

In preparation of adding platform support, a new struct device *dev
is added to struct velocity_info which can be used by both the pci
and platform code.

Signed-off-by: Tony Prisk <linux at prisktech.co.nz>
---
 drivers/net/ethernet/via/via-velocity.c |   51 +++++++++++++++----------------
 drivers/net/ethernet/via/via-velocity.h |    1 +
 2 files changed, 26 insertions(+), 26 deletions(-)

diff --git a/drivers/net/ethernet/via/via-velocity.c b/drivers/net/ethernet/via/via-velocity.c
index 9a408b1..e2c4887 100644
--- a/drivers/net/ethernet/via/via-velocity.c
+++ b/drivers/net/ethernet/via/via-velocity.c
@@ -46,6 +46,7 @@
 #include <linux/types.h>
 #include <linux/bitops.h>
 #include <linux/init.h>
+#include <linux/dma-mapping.h>
 #include <linux/mm.h>
 #include <linux/errno.h>
 #include <linux/ioport.h>
@@ -1457,7 +1458,6 @@ static int velocity_init_dma_rings(struct velocity_info *vptr)
 	struct velocity_opt *opt = &vptr->options;
 	const unsigned int rx_ring_size = opt->numrx * sizeof(struct rx_desc);
 	const unsigned int tx_ring_size = opt->numtx * sizeof(struct tx_desc);
-	struct pci_dev *pdev = vptr->pdev;
 	dma_addr_t pool_dma;
 	void *pool;
 	unsigned int i;
@@ -1465,13 +1465,13 @@ static int velocity_init_dma_rings(struct velocity_info *vptr)
 	/*
 	 * Allocate all RD/TD rings a single pool.
 	 *
-	 * pci_alloc_consistent() fulfills the requirement for 64 bytes
+	 * dma_alloc_coherent() fulfills the requirement for 64 bytes
 	 * alignment
 	 */
-	pool = pci_alloc_consistent(pdev, tx_ring_size * vptr->tx.numq +
-				    rx_ring_size, &pool_dma);
+	pool = dma_alloc_coherent(vptr->dev, tx_ring_size * vptr->tx.numq +
+				    rx_ring_size, &pool_dma, GFP_ATOMIC);
 	if (!pool) {
-		dev_err(&pdev->dev, "%s : DMA memory allocation failed.\n",
+		dev_err(vptr->dev, "%s : DMA memory allocation failed.\n",
 			vptr->netdev->name);
 		return -ENOMEM;
 	}
@@ -1522,8 +1522,8 @@ static int velocity_alloc_rx_buf(struct velocity_info *vptr, int idx)
 	 */
 	skb_reserve(rd_info->skb,
 			64 - ((unsigned long) rd_info->skb->data & 63));
-	rd_info->skb_dma = pci_map_single(vptr->pdev, rd_info->skb->data,
-					vptr->rx.buf_sz, PCI_DMA_FROMDEVICE);
+	rd_info->skb_dma = dma_map_single(vptr->dev, rd_info->skb->data,
+					vptr->rx.buf_sz, DMA_FROM_DEVICE);
 
 	/*
 	 *	Fill in the descriptor to match
@@ -1586,8 +1586,8 @@ static void velocity_free_rd_ring(struct velocity_info *vptr)
 
 		if (!rd_info->skb)
 			continue;
-		pci_unmap_single(vptr->pdev, rd_info->skb_dma, vptr->rx.buf_sz,
-				 PCI_DMA_FROMDEVICE);
+		dma_unmap_single(vptr->dev, rd_info->skb_dma, vptr->rx.buf_sz,
+				 DMA_FROM_DEVICE);
 		rd_info->skb_dma = 0;
 
 		dev_kfree_skb(rd_info->skb);
@@ -1668,7 +1668,7 @@ static void velocity_free_dma_rings(struct velocity_info *vptr)
 	const int size = vptr->options.numrx * sizeof(struct rx_desc) +
 		vptr->options.numtx * sizeof(struct tx_desc) * vptr->tx.numq;
 
-	pci_free_consistent(vptr->pdev, size, vptr->rx.ring, vptr->rx.pool_dma);
+	dma_free_coherent(vptr->dev, size, vptr->rx.ring, vptr->rx.pool_dma);
 }
 
 static int velocity_init_rings(struct velocity_info *vptr, int mtu)
@@ -1725,8 +1725,8 @@ static void velocity_free_tx_buf(struct velocity_info *vptr,
 				pktlen = max_t(size_t, pktlen,
 						td->td_buf[i].size & ~TD_QUEUE);
 
-			pci_unmap_single(vptr->pdev, tdinfo->skb_dma[i],
-					le16_to_cpu(pktlen), PCI_DMA_TODEVICE);
+			dma_unmap_single(vptr->dev, tdinfo->skb_dma[i],
+					le16_to_cpu(pktlen), DMA_TO_DEVICE);
 		}
 	}
 	dev_kfree_skb_irq(skb);
@@ -1748,8 +1748,8 @@ static void velocity_free_td_ring_entry(struct velocity_info *vptr,
 	if (td_info->skb) {
 		for (i = 0; i < td_info->nskb_dma; i++) {
 			if (td_info->skb_dma[i]) {
-				pci_unmap_single(vptr->pdev, td_info->skb_dma[i],
-					td_info->skb->len, PCI_DMA_TODEVICE);
+				dma_unmap_single(vptr->dev, td_info->skb_dma[i],
+					td_info->skb->len, DMA_TO_DEVICE);
 				td_info->skb_dma[i] = 0;
 			}
 		}
@@ -2027,7 +2027,6 @@ static inline void velocity_iph_realign(struct velocity_info *vptr,
  */
 static int velocity_receive_frame(struct velocity_info *vptr, int idx)
 {
-	void (*pci_action)(struct pci_dev *, dma_addr_t, size_t, int);
 	struct net_device_stats *stats = &vptr->netdev->stats;
 	struct velocity_rd_info *rd_info = &(vptr->rx.info[idx]);
 	struct rx_desc *rd = &(vptr->rx.ring[idx]);
@@ -2045,8 +2044,8 @@ static int velocity_receive_frame(struct velocity_info *vptr, int idx)
 
 	skb = rd_info->skb;
 
-	pci_dma_sync_single_for_cpu(vptr->pdev, rd_info->skb_dma,
-				    vptr->rx.buf_sz, PCI_DMA_FROMDEVICE);
+	dma_sync_single_for_cpu(vptr->dev, rd_info->skb_dma,
+				    vptr->rx.buf_sz, DMA_FROM_DEVICE);
 
 	/*
 	 *	Drop frame not meeting IEEE 802.3
@@ -2059,19 +2058,18 @@ static int velocity_receive_frame(struct velocity_info *vptr, int idx)
 		}
 	}
 
-	pci_action = pci_dma_sync_single_for_device;
-
 	velocity_rx_csum(rd, skb);
 
 	if (velocity_rx_copy(&skb, pkt_len, vptr) < 0) {
 		velocity_iph_realign(vptr, skb, pkt_len);
-		pci_action = pci_unmap_single;
 		rd_info->skb = NULL;
+		dma_unmap_single(vptr->dev, rd_info->skb_dma, vptr->rx.buf_sz,
+				 DMA_FROM_DEVICE);
+	} else {
+		dma_sync_single_for_device(vptr->dev, rd_info->skb_dma,
+					   vptr->rx.buf_sz, DMA_FROM_DEVICE);
 	}
 
-	pci_action(vptr->pdev, rd_info->skb_dma, vptr->rx.buf_sz,
-		   PCI_DMA_FROMDEVICE);
-
 	skb_put(skb, pkt_len - 4);
 	skb->protocol = eth_type_trans(skb, vptr->netdev);
 
@@ -2548,7 +2546,8 @@ static netdev_tx_t velocity_xmit(struct sk_buff *skb,
 	 *	add it to the transmit ring.
 	 */
 	tdinfo->skb = skb;
-	tdinfo->skb_dma[0] = pci_map_single(vptr->pdev, skb->data, pktlen, PCI_DMA_TODEVICE);
+	tdinfo->skb_dma[0] = dma_map_single(vptr->dev, skb->data, pktlen,
+								DMA_TO_DEVICE);
 	td_ptr->tdesc0.len = cpu_to_le16(pktlen);
 	td_ptr->td_buf[0].pa_low = cpu_to_le32(tdinfo->skb_dma[0]);
 	td_ptr->td_buf[0].pa_high = 0;
@@ -2558,7 +2557,7 @@ static netdev_tx_t velocity_xmit(struct sk_buff *skb,
 	for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) {
 		const skb_frag_t *frag = &skb_shinfo(skb)->frags[i];
 
-		tdinfo->skb_dma[i + 1] = skb_frag_dma_map(&vptr->pdev->dev,
+		tdinfo->skb_dma[i + 1] = skb_frag_dma_map(vptr->dev,
 							  frag, 0,
 							  skb_frag_size(frag),
 							  DMA_TO_DEVICE);
@@ -2635,6 +2634,7 @@ static void velocity_init_info(struct pci_dev *pdev, struct velocity_info *vptr,
 {
 	memset(vptr, 0, sizeof(struct velocity_info));
 
+	vptr->dev = &pdev->dev;
 	vptr->pdev = pdev;
 	vptr->chip_id = info->chip_id;
 	vptr->tx.numq = info->txqueue;
@@ -2742,7 +2742,6 @@ static int velocity_found1(struct pci_dev *pdev,
 	SET_NETDEV_DEV(dev, &pdev->dev);
 	vptr = netdev_priv(dev);
 
-
 	if (first) {
 		printk(KERN_INFO "%s Ver. %s\n",
 			VELOCITY_FULL_DRV_NAM, VELOCITY_VERSION);
diff --git a/drivers/net/ethernet/via/via-velocity.h b/drivers/net/ethernet/via/via-velocity.h
index ff8d7828..c38bbae 100644
--- a/drivers/net/ethernet/via/via-velocity.h
+++ b/drivers/net/ethernet/via/via-velocity.h
@@ -1434,6 +1434,7 @@ struct velocity_opt {
 #define GET_RD_BY_IDX(vptr, idx)   (vptr->rd_ring[idx])
 
 struct velocity_info {
+	struct device *dev;
 	struct pci_dev *pdev;
 	struct net_device *netdev;
 
-- 
1.7.9.5



From linux at prisktech.co.nz  Mon Apr 29 03:50:39 2013
From: linux at prisktech.co.nz (Tony Prisk)
Date: Mon, 29 Apr 2013 19:50:39 +1200
Subject: [PATCHv2 1/3] net: velocity: Rename vptr->dev to vptr->netdev
In-Reply-To: <1367221841-14563-1-git-send-email-linux@prisktech.co.nz>
References: <1367221841-14563-1-git-send-email-linux@prisktech.co.nz>
Message-ID: <1367221841-14563-2-git-send-email-linux@prisktech.co.nz>

Improve the clarity of the code in preparation for converting the
dma functions to generic versions, which require a struct device *.

This makes it possible to store a 'struct device *dev' in the
velocity_info structure.

Signed-off-by: Tony Prisk <linux at prisktech.co.nz>
---
 drivers/net/ethernet/via/via-velocity.c |   66 +++++++++++++++----------------
 drivers/net/ethernet/via/via-velocity.h |    4 +-
 2 files changed, 35 insertions(+), 35 deletions(-)

diff --git a/drivers/net/ethernet/via/via-velocity.c b/drivers/net/ethernet/via/via-velocity.c
index 1bc7f9fd..9a408b1 100644
--- a/drivers/net/ethernet/via/via-velocity.c
+++ b/drivers/net/ethernet/via/via-velocity.c
@@ -996,9 +996,9 @@ static void velocity_print_link_status(struct velocity_info *vptr)
 {
 
 	if (vptr->mii_status & VELOCITY_LINK_FAIL) {
-		VELOCITY_PRT(MSG_LEVEL_INFO, KERN_NOTICE "%s: failed to detect cable link\n", vptr->dev->name);
+		VELOCITY_PRT(MSG_LEVEL_INFO, KERN_NOTICE "%s: failed to detect cable link\n", vptr->netdev->name);
 	} else if (vptr->options.spd_dpx == SPD_DPX_AUTO) {
-		VELOCITY_PRT(MSG_LEVEL_INFO, KERN_NOTICE "%s: Link auto-negotiation", vptr->dev->name);
+		VELOCITY_PRT(MSG_LEVEL_INFO, KERN_NOTICE "%s: Link auto-negotiation", vptr->netdev->name);
 
 		if (vptr->mii_status & VELOCITY_SPEED_1000)
 			VELOCITY_PRT(MSG_LEVEL_INFO, " speed 1000M bps");
@@ -1012,7 +1012,7 @@ static void velocity_print_link_status(struct velocity_info *vptr)
 		else
 			VELOCITY_PRT(MSG_LEVEL_INFO, " half duplex\n");
 	} else {
-		VELOCITY_PRT(MSG_LEVEL_INFO, KERN_NOTICE "%s: Link forced", vptr->dev->name);
+		VELOCITY_PRT(MSG_LEVEL_INFO, KERN_NOTICE "%s: Link forced", vptr->netdev->name);
 		switch (vptr->options.spd_dpx) {
 		case SPD_DPX_1000_FULL:
 			VELOCITY_PRT(MSG_LEVEL_INFO, " speed 1000M bps full duplex\n");
@@ -1317,7 +1317,7 @@ static void velocity_init_registers(struct velocity_info *vptr,
 	case VELOCITY_INIT_RESET:
 	case VELOCITY_INIT_WOL:
 
-		netif_stop_queue(vptr->dev);
+		netif_stop_queue(vptr->netdev);
 
 		/*
 		 *	Reset RX to prevent RX pointer not on the 4X location
@@ -1330,7 +1330,7 @@ static void velocity_init_registers(struct velocity_info *vptr,
 		if (velocity_set_media_mode(vptr, mii_status) != VELOCITY_LINK_CHANGE) {
 			velocity_print_link_status(vptr);
 			if (!(vptr->mii_status & VELOCITY_LINK_FAIL))
-				netif_wake_queue(vptr->dev);
+				netif_wake_queue(vptr->netdev);
 		}
 
 		enable_flow_control_ability(vptr);
@@ -1352,7 +1352,7 @@ static void velocity_init_registers(struct velocity_info *vptr,
 
 		mac_eeprom_reload(regs);
 		for (i = 0; i < 6; i++)
-			writeb(vptr->dev->dev_addr[i], &(regs->PAR[i]));
+			writeb(vptr->netdev->dev_addr[i], &(regs->PAR[i]));
 
 		/*
 		 *	clear Pre_ACPI bit.
@@ -1375,7 +1375,7 @@ static void velocity_init_registers(struct velocity_info *vptr,
 		/*
 		 *	Set packet filter: Receive directed and broadcast address
 		 */
-		velocity_set_multi(vptr->dev);
+		velocity_set_multi(vptr->netdev);
 
 		/*
 		 *	Enable MII auto-polling
@@ -1402,14 +1402,14 @@ static void velocity_init_registers(struct velocity_info *vptr,
 		writel((CR0_DPOLL | CR0_TXON | CR0_RXON | CR0_STRT), &regs->CR0Set);
 
 		mii_status = velocity_get_opt_media_mode(vptr);
-		netif_stop_queue(vptr->dev);
+		netif_stop_queue(vptr->netdev);
 
 		mii_init(vptr, mii_status);
 
 		if (velocity_set_media_mode(vptr, mii_status) != VELOCITY_LINK_CHANGE) {
 			velocity_print_link_status(vptr);
 			if (!(vptr->mii_status & VELOCITY_LINK_FAIL))
-				netif_wake_queue(vptr->dev);
+				netif_wake_queue(vptr->netdev);
 		}
 
 		enable_flow_control_ability(vptr);
@@ -1472,7 +1472,7 @@ static int velocity_init_dma_rings(struct velocity_info *vptr)
 				    rx_ring_size, &pool_dma);
 	if (!pool) {
 		dev_err(&pdev->dev, "%s : DMA memory allocation failed.\n",
-			vptr->dev->name);
+			vptr->netdev->name);
 		return -ENOMEM;
 	}
 
@@ -1512,7 +1512,7 @@ static int velocity_alloc_rx_buf(struct velocity_info *vptr, int idx)
 	struct rx_desc *rd = &(vptr->rx.ring[idx]);
 	struct velocity_rd_info *rd_info = &(vptr->rx.info[idx]);
 
-	rd_info->skb = netdev_alloc_skb(vptr->dev, vptr->rx.buf_sz + 64);
+	rd_info->skb = netdev_alloc_skb(vptr->netdev, vptr->rx.buf_sz + 64);
 	if (rd_info->skb == NULL)
 		return -ENOMEM;
 
@@ -1618,7 +1618,7 @@ static int velocity_init_rd_ring(struct velocity_info *vptr)
 
 	if (velocity_rx_refill(vptr) != vptr->options.numrx) {
 		VELOCITY_PRT(MSG_LEVEL_ERR, KERN_ERR
-			"%s: failed to allocate RX buffer.\n", vptr->dev->name);
+			"%s: failed to allocate RX buffer.\n", vptr->netdev->name);
 		velocity_free_rd_ring(vptr);
 		goto out;
 	}
@@ -1807,7 +1807,7 @@ static void velocity_error(struct velocity_info *vptr, int status)
 		printk(KERN_ERR "TD structure error TDindex=%hx\n", readw(&regs->TDIdx[0]));
 		BYTE_REG_BITS_ON(TXESR_TDSTR, &regs->TXESR);
 		writew(TRDCSR_RUN, &regs->TDCSRClr);
-		netif_stop_queue(vptr->dev);
+		netif_stop_queue(vptr->netdev);
 
 		/* FIXME: port over the pci_device_failed code and use it
 		   here */
@@ -1848,10 +1848,10 @@ static void velocity_error(struct velocity_info *vptr, int status)
 
 		if (linked) {
 			vptr->mii_status &= ~VELOCITY_LINK_FAIL;
-			netif_carrier_on(vptr->dev);
+			netif_carrier_on(vptr->netdev);
 		} else {
 			vptr->mii_status |= VELOCITY_LINK_FAIL;
-			netif_carrier_off(vptr->dev);
+			netif_carrier_off(vptr->netdev);
 		}
 
 		velocity_print_link_status(vptr);
@@ -1865,9 +1865,9 @@ static void velocity_error(struct velocity_info *vptr, int status)
 		enable_mii_autopoll(regs);
 
 		if (vptr->mii_status & VELOCITY_LINK_FAIL)
-			netif_stop_queue(vptr->dev);
+			netif_stop_queue(vptr->netdev);
 		else
-			netif_wake_queue(vptr->dev);
+			netif_wake_queue(vptr->netdev);
 
 	}
 	if (status & ISR_MIBFI)
@@ -1892,7 +1892,7 @@ static int velocity_tx_srv(struct velocity_info *vptr)
 	int idx;
 	int works = 0;
 	struct velocity_td_info *tdinfo;
-	struct net_device_stats *stats = &vptr->dev->stats;
+	struct net_device_stats *stats = &vptr->netdev->stats;
 
 	for (qnum = 0; qnum < vptr->tx.numq; qnum++) {
 		for (idx = vptr->tx.tail[qnum]; vptr->tx.used[qnum] > 0;
@@ -1937,9 +1937,9 @@ static int velocity_tx_srv(struct velocity_info *vptr)
 	 *	Look to see if we should kick the transmit network
 	 *	layer for more work.
 	 */
-	if (netif_queue_stopped(vptr->dev) && (full == 0) &&
+	if (netif_queue_stopped(vptr->netdev) && (full == 0) &&
 	    (!(vptr->mii_status & VELOCITY_LINK_FAIL))) {
-		netif_wake_queue(vptr->dev);
+		netif_wake_queue(vptr->netdev);
 	}
 	return works;
 }
@@ -1987,7 +1987,7 @@ static int velocity_rx_copy(struct sk_buff **rx_skb, int pkt_size,
 	if (pkt_size < rx_copybreak) {
 		struct sk_buff *new_skb;
 
-		new_skb = netdev_alloc_skb_ip_align(vptr->dev, pkt_size);
+		new_skb = netdev_alloc_skb_ip_align(vptr->netdev, pkt_size);
 		if (new_skb) {
 			new_skb->ip_summed = rx_skb[0]->ip_summed;
 			skb_copy_from_linear_data(*rx_skb, new_skb->data, pkt_size);
@@ -2028,14 +2028,14 @@ static inline void velocity_iph_realign(struct velocity_info *vptr,
 static int velocity_receive_frame(struct velocity_info *vptr, int idx)
 {
 	void (*pci_action)(struct pci_dev *, dma_addr_t, size_t, int);
-	struct net_device_stats *stats = &vptr->dev->stats;
+	struct net_device_stats *stats = &vptr->netdev->stats;
 	struct velocity_rd_info *rd_info = &(vptr->rx.info[idx]);
 	struct rx_desc *rd = &(vptr->rx.ring[idx]);
 	int pkt_len = le16_to_cpu(rd->rdesc0.len) & 0x3fff;
 	struct sk_buff *skb;
 
 	if (rd->rdesc0.RSR & (RSR_STP | RSR_EDP)) {
-		VELOCITY_PRT(MSG_LEVEL_VERBOSE, KERN_ERR " %s : the received frame span multple RDs.\n", vptr->dev->name);
+		VELOCITY_PRT(MSG_LEVEL_VERBOSE, KERN_ERR " %s : the received frame span multple RDs.\n", vptr->netdev->name);
 		stats->rx_length_errors++;
 		return -EINVAL;
 	}
@@ -2073,7 +2073,7 @@ static int velocity_receive_frame(struct velocity_info *vptr, int idx)
 		   PCI_DMA_FROMDEVICE);
 
 	skb_put(skb, pkt_len - 4);
-	skb->protocol = eth_type_trans(skb, vptr->dev);
+	skb->protocol = eth_type_trans(skb, vptr->netdev);
 
 	if (rd->rdesc0.RSR & RSR_DETAG) {
 		u16 vid = swab16(le16_to_cpu(rd->rdesc1.PQTAG));
@@ -2098,7 +2098,7 @@ static int velocity_receive_frame(struct velocity_info *vptr, int idx)
  */
 static int velocity_rx_srv(struct velocity_info *vptr, int budget_left)
 {
-	struct net_device_stats *stats = &vptr->dev->stats;
+	struct net_device_stats *stats = &vptr->netdev->stats;
 	int rd_curr = vptr->rx.curr;
 	int works = 0;
 
@@ -2290,7 +2290,7 @@ static int velocity_change_mtu(struct net_device *dev, int new_mtu)
 
 	if ((new_mtu < VELOCITY_MIN_MTU) || new_mtu > (VELOCITY_MAX_MTU)) {
 		VELOCITY_PRT(MSG_LEVEL_ERR, KERN_NOTICE "%s: Invalid MTU.\n",
-				vptr->dev->name);
+				vptr->netdev->name);
 		ret = -EINVAL;
 		goto out_0;
 	}
@@ -2312,7 +2312,7 @@ static int velocity_change_mtu(struct net_device *dev, int new_mtu)
 			goto out_0;
 		}
 
-		tmp_vptr->dev = dev;
+		tmp_vptr->netdev = dev;
 		tmp_vptr->pdev = vptr->pdev;
 		tmp_vptr->options = vptr->options;
 		tmp_vptr->tx.numq = vptr->tx.numq;
@@ -2690,7 +2690,7 @@ static int velocity_get_pci_info(struct velocity_info *vptr,
  */
 static void velocity_print_info(struct velocity_info *vptr)
 {
-	struct net_device *dev = vptr->dev;
+	struct net_device *dev = vptr->netdev;
 
 	printk(KERN_INFO "%s: %s\n", dev->name, get_chip_name(vptr->chip_id));
 	printk(KERN_INFO "%s: Ethernet Address: %pM\n",
@@ -2753,7 +2753,7 @@ static int velocity_found1(struct pci_dev *pdev,
 
 	velocity_init_info(pdev, vptr, info);
 
-	vptr->dev = dev;
+	vptr->netdev = dev;
 
 	ret = pci_enable_device(pdev);
 	if (ret < 0)
@@ -3007,10 +3007,10 @@ static int velocity_suspend(struct pci_dev *pdev, pm_message_t state)
 	struct velocity_info *vptr = netdev_priv(dev);
 	unsigned long flags;
 
-	if (!netif_running(vptr->dev))
+	if (!netif_running(vptr->netdev))
 		return 0;
 
-	netif_device_detach(vptr->dev);
+	netif_device_detach(vptr->netdev);
 
 	spin_lock_irqsave(&vptr->lock, flags);
 	pci_save_state(pdev);
@@ -3075,7 +3075,7 @@ static int velocity_resume(struct pci_dev *pdev)
 	unsigned long flags;
 	int i;
 
-	if (!netif_running(vptr->dev))
+	if (!netif_running(vptr->netdev))
 		return 0;
 
 	pci_set_power_state(pdev, PCI_D0);
@@ -3098,7 +3098,7 @@ static int velocity_resume(struct pci_dev *pdev)
 
 	mac_enable_int(vptr->mac_regs);
 	spin_unlock_irqrestore(&vptr->lock, flags);
-	netif_device_attach(vptr->dev);
+	netif_device_attach(vptr->netdev);
 
 	return 0;
 }
diff --git a/drivers/net/ethernet/via/via-velocity.h b/drivers/net/ethernet/via/via-velocity.h
index 4cb9f13..ff8d7828 100644
--- a/drivers/net/ethernet/via/via-velocity.h
+++ b/drivers/net/ethernet/via/via-velocity.h
@@ -1435,7 +1435,7 @@ struct velocity_opt {
 
 struct velocity_info {
 	struct pci_dev *pdev;
-	struct net_device *dev;
+	struct net_device *netdev;
 
 	unsigned long active_vlans[BITS_TO_LONGS(VLAN_N_VID)];
 	u8 ip_addr[4];
@@ -1514,7 +1514,7 @@ static inline int velocity_get_ip(struct velocity_info *vptr)
 	int res = -ENOENT;
 
 	rcu_read_lock();
-	in_dev = __in_dev_get_rcu(vptr->dev);
+	in_dev = __in_dev_get_rcu(vptr->netdev);
 	if (in_dev != NULL) {
 		ifa = (struct in_ifaddr *) in_dev->ifa_list;
 		if (ifa != NULL) {
-- 
1.7.9.5



From linux at prisktech.co.nz  Mon Apr 29 03:50:41 2013
From: linux at prisktech.co.nz (Tony Prisk)
Date: Mon, 29 Apr 2013 19:50:41 +1200
Subject: [PATCHv2 3/3] net: velocity: Add platform device support to VIA
 velocity driver
In-Reply-To: <1367221841-14563-1-git-send-email-linux@prisktech.co.nz>
References: <1367221841-14563-1-git-send-email-linux@prisktech.co.nz>
Message-ID: <1367221841-14563-4-git-send-email-linux@prisktech.co.nz>

Add support for the VIA Velocity network driver to be bound to a
OF created platform device.

Signed-off-by: Tony Prisk <linux at prisktech.co.nz>
---
 .../devicetree/bindings/net/via-velocity.txt       |   20 +
 drivers/net/ethernet/via/Kconfig                   |    3 +-
 drivers/net/ethernet/via/via-velocity.c            |  453 +++++++++++++++-----
 drivers/net/ethernet/via/via-velocity.h            |   30 +-
 4 files changed, 398 insertions(+), 108 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/net/via-velocity.txt

diff --git a/Documentation/devicetree/bindings/net/via-velocity.txt b/Documentation/devicetree/bindings/net/via-velocity.txt
new file mode 100644
index 0000000..b3db469
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/via-velocity.txt
@@ -0,0 +1,20 @@
+* VIA Velocity 10/100/1000 Network Controller
+
+Required properties:
+- compatible : Should be "via,velocity-vt6110"
+- reg : Address and length of the io space
+- interrupts : Should contain the controller interrupt line
+
+Optional properties:
+- no-eeprom : PCI network cards use an external EEPROM to store data. Embedded
+	devices quite often set this data in uboot and do not provide an eeprom.
+	Specify this option if you have no external eeprom.
+
+Examples:
+
+eth0 at d8004000 {
+	compatible = "via,velocity-vt6110";
+	reg = <0xd8004000 0x400>;
+	interrupts = <10>;
+	no-eeprom;
+};
diff --git a/drivers/net/ethernet/via/Kconfig b/drivers/net/ethernet/via/Kconfig
index 68a9ba6..6a87097 100644
--- a/drivers/net/ethernet/via/Kconfig
+++ b/drivers/net/ethernet/via/Kconfig
@@ -5,7 +5,6 @@
 config NET_VENDOR_VIA
 	bool "VIA devices"
 	default y
-	depends on PCI
 	---help---
 	  If you have a network (Ethernet) card belonging to this class, say Y
 	  and read the Ethernet-HOWTO, available from
@@ -45,7 +44,7 @@ config VIA_RHINE_MMIO
 
 config VIA_VELOCITY
 	tristate "VIA Velocity support"
-	depends on PCI
+	depends on (PCI || USE_OF)
 	select CRC32
 	select CRC_CCITT
 	select NET_CORE
diff --git a/drivers/net/ethernet/via/via-velocity.c b/drivers/net/ethernet/via/via-velocity.c
index e2c4887..03cc3ed 100644
--- a/drivers/net/ethernet/via/via-velocity.c
+++ b/drivers/net/ethernet/via/via-velocity.c
@@ -65,7 +65,11 @@
 #include <linux/if.h>
 #include <linux/uaccess.h>
 #include <linux/proc_fs.h>
+#include <linux/of_address.h>
+#include <linux/of_device.h>
+#include <linux/of_irq.h>
 #include <linux/inetdevice.h>
+#include <linux/platform_device.h>
 #include <linux/reboot.h>
 #include <linux/ethtool.h>
 #include <linux/mii.h>
@@ -84,6 +88,16 @@
 static int velocity_nics;
 static int msglevel = MSG_LEVEL_INFO;
 
+static void velocity_set_power_state(struct velocity_info *vptr, char state)
+{
+	void *addr = vptr->mac_regs;
+
+	if (vptr->bustype == BUS_PCI)
+		pci_set_power_state(vptr->pdev, state);
+	else
+		writeb(state, addr + 0x154);
+}
+
 /**
  *	mac_get_cam_mask	-	Read a CAM mask
  *	@regs: register block for this velocity
@@ -362,12 +376,24 @@ static struct velocity_info_tbl chip_info_table[] = {
  *	Describe the PCI device identifiers that we support in this
  *	device driver. Used for hotplug autoloading.
  */
-static DEFINE_PCI_DEVICE_TABLE(velocity_id_table) = {
+#ifdef CONFIG_PCI
+static DEFINE_PCI_DEVICE_TABLE(velocity_pci_id_table) = {
 	{ PCI_DEVICE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_612X) },
 	{ }
 };
 
-MODULE_DEVICE_TABLE(pci, velocity_id_table);
+MODULE_DEVICE_TABLE(pci, velocity_pci_id_table);
+#endif
+
+/**
+ *	Describe the OF device identifiers that we support in this
+ *	device driver. Used for devicetree nodes.
+ */
+static struct of_device_id velocity_of_ids[] = {
+	{ .compatible = "via,velocity-vt6110", .data = &chip_info_table[0] },
+	{ /* Sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, velocity_of_ids);
 
 /**
  *	get_chip_name	- 	identifier to name
@@ -386,29 +412,6 @@ static const char *get_chip_name(enum chip_type chip_id)
 }
 
 /**
- *	velocity_remove1	-	device unplug
- *	@pdev: PCI device being removed
- *
- *	Device unload callback. Called on an unplug or on module
- *	unload for each active device that is present. Disconnects
- *	the device from the network layer and frees all the resources
- */
-static void velocity_remove1(struct pci_dev *pdev)
-{
-	struct net_device *dev = pci_get_drvdata(pdev);
-	struct velocity_info *vptr = netdev_priv(dev);
-
-	unregister_netdev(dev);
-	iounmap(vptr->mac_regs);
-	pci_release_regions(pdev);
-	pci_disable_device(pdev);
-	pci_set_drvdata(pdev, NULL);
-	free_netdev(dev);
-
-	velocity_nics--;
-}
-
-/**
  *	velocity_set_int_opt	-	parser for integer options
  *	@opt: pointer to option value
  *	@val: value the user requested (or -1 for default)
@@ -1179,6 +1182,14 @@ static void mii_init(struct velocity_info *vptr, u32 mii_status)
 	u16 BMCR;
 
 	switch (PHYID_GET_PHY_ID(vptr->phy_id)) {
+	case PHYID_ICPLUS_IP101A:
+		MII_REG_BITS_ON((ADVERTISE_PAUSE_ASYM | ADVERTISE_PAUSE_CAP), MII_ADVERTISE, vptr->mac_regs);
+		if (vptr->mii_status & VELOCITY_DUPLEX_FULL)
+			MII_REG_BITS_ON(TCSR_ECHODIS, MII_SREVISION, vptr->mac_regs);
+		else
+			MII_REG_BITS_OFF(TCSR_ECHODIS, MII_SREVISION, vptr->mac_regs);
+		MII_REG_BITS_ON(PLED_LALBE, MII_TPISTATUS, vptr->mac_regs);
+		break;
 	case PHYID_CICADA_CS8201:
 		/*
 		 *	Reset to hardware default
@@ -1351,9 +1362,12 @@ static void velocity_init_registers(struct velocity_info *vptr,
 		velocity_soft_reset(vptr);
 		mdelay(5);
 
-		mac_eeprom_reload(regs);
-		for (i = 0; i < 6; i++)
-			writeb(vptr->netdev->dev_addr[i], &(regs->PAR[i]));
+		if (!vptr->no_eeprom) {
+			mac_eeprom_reload(regs);
+			for (i = 0; i < 6; i++)
+				writeb(vptr->netdev->dev_addr[i],
+							&(regs->PAR[i]));
+		}
 
 		/*
 		 *	clear Pre_ACPI bit.
@@ -2231,15 +2245,15 @@ static int velocity_open(struct net_device *dev)
 		goto out;
 
 	/* Ensure chip is running */
-	pci_set_power_state(vptr->pdev, PCI_D0);
+	velocity_set_power_state(vptr, PCI_D0);
 
 	velocity_init_registers(vptr, VELOCITY_INIT_COLD);
 
-	ret = request_irq(vptr->pdev->irq, velocity_intr, IRQF_SHARED,
+	ret = request_irq(dev->irq, velocity_intr, IRQF_SHARED,
 			  dev->name, dev);
 	if (ret < 0) {
 		/* Power down the chip */
-		pci_set_power_state(vptr->pdev, PCI_D3hot);
+		velocity_set_power_state(vptr, PCI_D3hot);
 		velocity_free_rings(vptr);
 		goto out;
 	}
@@ -2411,7 +2425,7 @@ static int velocity_ioctl(struct net_device *dev, struct ifreq *rq, int cmd)
 	   saving then we need to bring the device back up to talk to it */
 
 	if (!netif_running(dev))
-		pci_set_power_state(vptr->pdev, PCI_D0);
+		velocity_set_power_state(vptr, PCI_D0);
 
 	switch (cmd) {
 	case SIOCGMIIPHY:	/* Get address of MII PHY in use. */
@@ -2424,7 +2438,7 @@ static int velocity_ioctl(struct net_device *dev, struct ifreq *rq, int cmd)
 		ret = -EOPNOTSUPP;
 	}
 	if (!netif_running(dev))
-		pci_set_power_state(vptr->pdev, PCI_D3hot);
+		velocity_set_power_state(vptr, PCI_D3hot);
 
 
 	return ret;
@@ -2490,7 +2504,7 @@ static int velocity_close(struct net_device *dev)
 	if (vptr->flags & VELOCITY_FLAGS_WOL_ENABLED)
 		velocity_get_ip(vptr);
 
-	free_irq(vptr->pdev->irq, dev);
+	free_irq(dev->irq, dev);
 
 	velocity_free_rings(vptr);
 
@@ -2629,13 +2643,25 @@ static const struct net_device_ops velocity_netdev_ops = {
  *	Set up the initial velocity_info struct for the device that has been
  *	discovered.
  */
-static void velocity_init_info(struct pci_dev *pdev, struct velocity_info *vptr,
-			       const struct velocity_info_tbl *info)
+static void velocity_init_info(void *pdev,
+				struct velocity_info *vptr,
+				const struct velocity_info_tbl *info,
+				enum velocity_bus_type bustype)
 {
+	struct pci_dev *pci_dev;
+	struct platform_device *platform_dev;
+
 	memset(vptr, 0, sizeof(struct velocity_info));
 
-	vptr->dev = &pdev->dev;
-	vptr->pdev = pdev;
+	if (bustype == BUS_PCI) {
+		pci_dev = pdev;
+		vptr->pdev = pci_dev;
+		vptr->dev = &pci_dev->dev;
+	} else {
+		platform_dev = pdev;
+		vptr->dev = &platform_dev->dev;
+	}
+
 	vptr->chip_id = info->chip_id;
 	vptr->tx.numq = info->txqueue;
 	vptr->multicast_limit = MCAM_SIZE;
@@ -2653,8 +2679,6 @@ static void velocity_init_info(struct pci_dev *pdev, struct velocity_info *vptr,
 static int velocity_get_pci_info(struct velocity_info *vptr,
 				 struct pci_dev *pdev)
 {
-	vptr->rev_id = pdev->revision;
-
 	pci_set_master(pdev);
 
 	vptr->ioaddr = pci_resource_start(pdev, 0);
@@ -2676,12 +2700,45 @@ static int velocity_get_pci_info(struct velocity_info *vptr,
 		dev_err(&pdev->dev, "region #1 is too small.\n");
 		return -EINVAL;
 	}
+
 	vptr->pdev = pdev;
 
 	return 0;
 }
 
 /**
+ *	velocity_get_platform_info - retrieve platform info for device
+ *	@vptr: velocity device
+ *	@pdev: platform device it matches
+ *
+ *	Retrieve the Platform configuration data that interests us
+ */
+static int velocity_get_platform_info(struct velocity_info *vptr,
+					struct platform_device *pdev)
+{
+	int ret;
+	struct resource res;
+
+	if (of_get_property(pdev->dev.of_node, "no-eeprom", NULL))
+		vptr->no_eeprom = 1;
+
+	ret = of_address_to_resource(pdev->dev.of_node, 0, &res);
+	if (ret) {
+		dev_err(&pdev->dev, "unable to find memory address\n");
+		return ret;
+	}
+
+	vptr->memaddr = res.start;
+
+	if (resource_size(&res) < VELOCITY_IO_SIZE) {
+		dev_err(&pdev->dev, "memory region is too small.\n");
+		return -EINVAL;
+	}
+
+	return 0;
+}
+
+/**
  *	velocity_print_info	-	per driver data
  *	@vptr: velocity
  *
@@ -2705,42 +2762,59 @@ static u32 velocity_get_link(struct net_device *dev)
 }
 
 /**
- *	velocity_found1		-	set up discovered velocity card
+ *	velocity_probe - set up discovered velocity device
  *	@pdev: PCI device
  *	@ent: PCI device table entry that matched
+ *	@bustype: bus that device is connected to
  *
  *	Configure a discovered adapter from scratch. Return a negative
  *	errno error code on failure paths.
  */
-static int velocity_found1(struct pci_dev *pdev,
-			   const struct pci_device_id *ent)
+static int velocity_probe(void *pdev,
+			   const struct pci_device_id *ent,
+			   enum velocity_bus_type bustype)
 {
 	static int first = 1;
-	struct net_device *dev;
+	struct pci_dev *pci_dev = NULL;
+	struct platform_device *platform_dev = NULL;
+	struct net_device *netdev;
+	struct device *dev;
+	const struct of_device_id *of_id;
 	int i;
 	const char *drv_string;
-	const struct velocity_info_tbl *info = &chip_info_table[ent->driver_data];
+	const struct velocity_info_tbl *info;
 	struct velocity_info *vptr;
 	struct mac_regs __iomem *regs;
+	int pci = (bustype == BUS_PCI) ? 1 : 0;
 	int ret = -ENOMEM;
 
+	if (pci) {
+		pci_dev = pdev;
+		dev = &pci_dev->dev;
+		info = &chip_info_table[ent->driver_data];
+	} else {
+		platform_dev = pdev;
+		dev = &platform_dev->dev;
+		of_id = of_match_device(velocity_of_ids, dev);
+		info = of_id->data;
+	}
+
 	/* FIXME: this driver, like almost all other ethernet drivers,
 	 * can support more than MAX_UNITS.
 	 */
 	if (velocity_nics >= MAX_UNITS) {
-		dev_notice(&pdev->dev, "already found %d NICs.\n",
-			   velocity_nics);
+		dev_notice(dev, "already found %d NICs.\n", velocity_nics);
 		return -ENODEV;
 	}
 
-	dev = alloc_etherdev(sizeof(struct velocity_info));
-	if (!dev)
+	netdev = alloc_etherdev(sizeof(struct velocity_info));
+	if (!netdev)
 		goto out;
 
 	/* Chain it all together */
 
-	SET_NETDEV_DEV(dev, &pdev->dev);
-	vptr = netdev_priv(dev);
+	SET_NETDEV_DEV(netdev, dev);
+	vptr = netdev_priv(netdev);
 
 	if (first) {
 		printk(KERN_INFO "%s Ver. %s\n",
@@ -2750,26 +2824,42 @@ static int velocity_found1(struct pci_dev *pdev,
 		first = 0;
 	}
 
-	velocity_init_info(pdev, vptr, info);
+	velocity_init_info(pdev, vptr, info, bustype);
+	vptr->bustype = bustype;
+	vptr->netdev = netdev;
 
-	vptr->netdev = dev;
-
-	ret = pci_enable_device(pdev);
-	if (ret < 0)
-		goto err_free_dev;
+	if (pci) {
+		ret = pci_enable_device(pci_dev);
+		if (ret < 0)
+			goto err_free_dev;
+		netdev->irq = pci_dev->irq;
+	} else {
+		netdev->irq =
+			irq_of_parse_and_map(platform_dev->dev.of_node, 0);
 
-	ret = velocity_get_pci_info(vptr, pdev);
-	if (ret < 0) {
-		/* error message already printed */
-		goto err_disable;
+		if (!netdev->irq) {
+			ret = -EINVAL;
+			goto err_free_dev;
+		}
 	}
 
-	ret = pci_request_regions(pdev, VELOCITY_NAME);
-	if (ret < 0) {
-		dev_err(&pdev->dev, "No PCI resources.\n");
-		goto err_disable;
+	if (pci) {
+		ret = velocity_get_pci_info(vptr, pci_dev);
+		if (ret < 0)
+			goto err_disable;
+
+		ret = pci_request_regions(pci_dev, VELOCITY_NAME);
+		if (ret < 0) {
+			dev_err(dev, "No PCI resources.\n");
+			goto err_disable;
+		}
+	} else {
+		ret = velocity_get_platform_info(vptr, platform_dev);
+		if (ret < 0)
+			goto err_disable;
 	}
 
+
 	regs = ioremap(vptr->memaddr, VELOCITY_IO_SIZE);
 	if (regs == NULL) {
 		ret = -EIO;
@@ -2778,13 +2868,18 @@ static int velocity_found1(struct pci_dev *pdev,
 
 	vptr->mac_regs = regs;
 
+	if (pci)
+		vptr->rev_id = pci_dev->revision;
+	else
+		vptr->rev_id = readb(&regs->rev_id);
+
 	mac_wol_reset(regs);
 
 	for (i = 0; i < 6; i++)
-		dev->dev_addr[i] = readb(&regs->PAR[i]);
+		netdev->dev_addr[i] = readb(&regs->PAR[i]);
 
 
-	drv_string = dev_driver_string(&pdev->dev);
+	drv_string = dev_driver_string(dev);
 
 	velocity_get_options(&vptr->options, velocity_nics, drv_string);
 
@@ -2805,29 +2900,32 @@ static int velocity_found1(struct pci_dev *pdev,
 
 	vptr->phy_id = MII_GET_PHY_ID(vptr->mac_regs);
 
-	dev->netdev_ops = &velocity_netdev_ops;
-	dev->ethtool_ops = &velocity_ethtool_ops;
-	netif_napi_add(dev, &vptr->napi, velocity_poll, VELOCITY_NAPI_WEIGHT);
+	netdev->netdev_ops = &velocity_netdev_ops;
+	netdev->ethtool_ops = &velocity_ethtool_ops;
+	netif_napi_add(netdev, &vptr->napi, velocity_poll, VELOCITY_NAPI_WEIGHT);
 
-	dev->hw_features = NETIF_F_IP_CSUM | NETIF_F_SG | NETIF_F_HW_VLAN_TX;
-	dev->features |= NETIF_F_HW_VLAN_TX | NETIF_F_HW_VLAN_FILTER |
+	netdev->hw_features = NETIF_F_IP_CSUM | NETIF_F_SG | NETIF_F_HW_VLAN_TX;
+	netdev->features |= NETIF_F_HW_VLAN_TX | NETIF_F_HW_VLAN_FILTER |
 		NETIF_F_HW_VLAN_RX | NETIF_F_IP_CSUM;
 
-	ret = register_netdev(dev);
+	ret = register_netdev(netdev);
 	if (ret < 0)
 		goto err_iounmap;
 
-	if (!velocity_get_link(dev)) {
-		netif_carrier_off(dev);
+	if (!velocity_get_link(netdev)) {
+		netif_carrier_off(netdev);
 		vptr->mii_status |= VELOCITY_LINK_FAIL;
 	}
 
 	velocity_print_info(vptr);
-	pci_set_drvdata(pdev, dev);
+	if (pci)
+		pci_set_drvdata(pci_dev, netdev);
+	else
+		platform_set_drvdata(platform_dev, netdev);
 
 	/* and leave the chip powered down */
 
-	pci_set_power_state(pdev, PCI_D3hot);
+	velocity_set_power_state(vptr, PCI_D3hot);
 	velocity_nics++;
 out:
 	return ret;
@@ -2835,14 +2933,79 @@ out:
 err_iounmap:
 	iounmap(regs);
 err_release_res:
-	pci_release_regions(pdev);
+	if (pci)
+		pci_release_regions(pci_dev);
 err_disable:
-	pci_disable_device(pdev);
+	if (pci)
+		pci_disable_device(pci_dev);
 err_free_dev:
-	free_netdev(dev);
+	free_netdev(netdev);
 	goto out;
 }
 
+/**
+ *	velocity_remove	- device unplug
+ *	@pdev: PCI device being removed
+ *	@bustype: bus that device is connected to
+ *
+ *	Device unload callback. Called on an unplug or on module
+ *	unload for each active device that is present. Disconnects
+ *	the device from the network layer and frees all the resources
+ */
+static int velocity_remove(void *pdev, enum velocity_bus_type bustype)
+{
+	struct net_device *netdev;
+	struct velocity_info *vptr;
+	int pci = (bustype == BUS_PCI) ? 1 : 0;
+
+	if (pci)
+		netdev = pci_get_drvdata(pdev);
+	else
+		netdev = platform_get_drvdata(pdev);
+
+	vptr = netdev_priv(netdev);
+
+	unregister_netdev(netdev);
+	iounmap(vptr->mac_regs);
+
+	if (pci) {
+		pci_release_regions(pdev);
+		pci_disable_device(pdev);
+		pci_set_drvdata(pdev, NULL);
+	} else {
+		platform_set_drvdata(pdev, NULL);
+	}
+
+	free_netdev(netdev);
+
+	velocity_nics--;
+
+	return 0;
+}
+
+#ifdef CONFIG_PCI
+static int velocity_pci_probe(struct pci_dev *pdev,
+			   const struct pci_device_id *ent)
+{
+	return velocity_probe(pdev, ent, BUS_PCI);
+}
+
+static void velocity_pci_remove(struct pci_dev *pdev)
+{
+	velocity_remove(pdev, BUS_PCI);
+}
+#endif
+
+static int velocity_platform_probe(struct platform_device *pdev)
+{
+	return velocity_probe(pdev, NULL, BUS_PLATFORM);
+}
+
+static int velocity_platform_remove(struct platform_device *pdev)
+{
+	return velocity_remove(pdev, BUS_PLATFORM);
+}
+
 #ifdef CONFIG_PM
 /**
  *	wol_calc_crc		-	WOL CRC
@@ -3000,11 +3163,20 @@ static void velocity_save_context(struct velocity_info *vptr, struct velocity_co
 
 }
 
-static int velocity_suspend(struct pci_dev *pdev, pm_message_t state)
+static int velocity_suspend(void *pdev, pm_message_t state,
+					enum velocity_bus_type bustype)
 {
-	struct net_device *dev = pci_get_drvdata(pdev);
-	struct velocity_info *vptr = netdev_priv(dev);
+	struct net_device *netdev;
+	struct velocity_info *vptr;
 	unsigned long flags;
+	int pci = (bustype == BUS_PCI) ? 1 : 0;
+
+	if (pci)
+		netdev = pci_get_drvdata(pdev)
+	else
+		netdev = platform_get_drvdata(pdev);
+
+	vptr = netdev_priv(netdev);
 
 	if (!netif_running(vptr->netdev))
 		return 0;
@@ -3012,20 +3184,24 @@ static int velocity_suspend(struct pci_dev *pdev, pm_message_t state)
 	netif_device_detach(vptr->netdev);
 
 	spin_lock_irqsave(&vptr->lock, flags);
-	pci_save_state(pdev);
+	if (pci)
+		pci_save_state(pdev);
 
 	if (vptr->flags & VELOCITY_FLAGS_WOL_ENABLED) {
 		velocity_get_ip(vptr);
 		velocity_save_context(vptr, &vptr->context);
 		velocity_shutdown(vptr);
 		velocity_set_wol(vptr);
-		pci_enable_wake(pdev, PCI_D3hot, 1);
-		pci_set_power_state(pdev, PCI_D3hot);
+		if (pci)
+			pci_enable_wake(pdev, PCI_D3hot, 1);
+		velocity_set_power_state(vptr, PCI_D3hot);
 	} else {
 		velocity_save_context(vptr, &vptr->context);
 		velocity_shutdown(vptr);
-		pci_disable_device(pdev);
-		pci_set_power_state(pdev, pci_choose_state(pdev, state));
+		if (pci)
+			pci_disable_device(pdev);
+		velocity_set_power_state(vptr,
+					 velocity_choose_state(pdev, state));
 	}
 
 	spin_unlock_irqrestore(&vptr->lock, flags);
@@ -3067,19 +3243,30 @@ static void velocity_restore_context(struct velocity_info *vptr, struct velocity
 		writeb(*((u8 *) (context->mac_reg + i)), ptr + i);
 }
 
-static int velocity_resume(struct pci_dev *pdev)
+static int velocity_resume(void *pdev, enum velocity_bus_type bustype)
 {
-	struct net_device *dev = pci_get_drvdata(pdev);
-	struct velocity_info *vptr = netdev_priv(dev);
+	struct net_device *netdev;
+	struct velocity_info *vptr;
 	unsigned long flags;
+	int pci = (bustype == BUS_PCI) ? 1 : 0;
 	int i;
 
+	if (pci)
+		netdev = pci_get_devdata(pdev);
+	else
+		netdev = platform_get_drvdata(pdev);
+
+	vptr = netdev_priv(netdev);
+
 	if (!netif_running(vptr->netdev))
 		return 0;
 
-	pci_set_power_state(pdev, PCI_D0);
-	pci_enable_wake(pdev, 0, 0);
-	pci_restore_state(pdev);
+	velocity_set_power_state(vptr, PCI_D0);
+
+	if (pci) {
+		pci_enable_wake(pdev, 0, 0);
+		pci_restore_state(pdev);
+	}
 
 	mac_wol_reset(vptr->mac_regs);
 
@@ -3101,23 +3288,66 @@ static int velocity_resume(struct pci_dev *pdev)
 
 	return 0;
 }
+
+#ifdef CONFIG_PCI
+static int velocity_pci_suspend(struct pci_dev *pdev, pm_message_t state)
+{
+	return velocity_suspend(pdev, state, BUS_PCI);
+};
+
+static int velocity_pci_resume(struct pci_dev *pdev)
+{
+	return velocity_resume(pdev, BUS_PCI);
+};
 #endif
 
+static int velocity_platform_suspend(struct platform_device *pdev)
+{
+	return velocity_suspend(pdev, state, BUS_PLATFORM);
+}
+
+static int velocity_platform_resume(struct platform_device *pdev)
+{
+	return velocity_resume(pdev, BUS_PLATFORM);
+}
+
+static const struct dev_pm_ops velocity_platform_pm = {
+	.suspend        = velocity_platform_suspend,
+	.resume         = velocity_platform_resume,
+};
+
+#endif	/* !CONFIG_PM */
+
 /*
  *	Definition for our device driver. The PCI layer interface
  *	uses this to handle all our card discover and plugging
  */
-static struct pci_driver velocity_driver = {
+#ifdef CONFIG_PCI
+static struct pci_driver velocity_pci_driver = {
 	.name		= VELOCITY_NAME,
-	.id_table	= velocity_id_table,
-	.probe		= velocity_found1,
-	.remove		= velocity_remove1,
+	.id_table	= velocity_pci_id_table,
+	.probe		= velocity_pci_probe,
+	.remove		= velocity_pci_remove,
 #ifdef CONFIG_PM
-	.suspend	= velocity_suspend,
-	.resume		= velocity_resume,
+	.suspend	= velocity_pci_suspend,
+	.resume		= velocity_pci_resume,
 #endif
 };
+#endif
 
+static struct platform_driver velocity_platform_driver = {
+	.probe		= velocity_platform_probe,
+	.remove		= velocity_platform_remove,
+#ifdef CONFIG_PM
+	.suspend	= velocity_platform_suspend,
+	.resume		= velocity_platform_resume,
+#endif
+	.driver = {
+		.name = "via-velocity",
+		.owner = THIS_MODULE,
+		.of_match_table = velocity_of_ids,
+	},
+};
 
 /**
  *	velocity_ethtool_up	-	pre hook for ethtool
@@ -3130,7 +3360,7 @@ static int velocity_ethtool_up(struct net_device *dev)
 {
 	struct velocity_info *vptr = netdev_priv(dev);
 	if (!netif_running(dev))
-		pci_set_power_state(vptr->pdev, PCI_D0);
+		velocity_set_power_state(vptr, PCI_D0);
 	return 0;
 }
 
@@ -3145,7 +3375,7 @@ static void velocity_ethtool_down(struct net_device *dev)
 {
 	struct velocity_info *vptr = netdev_priv(dev);
 	if (!netif_running(dev))
-		pci_set_power_state(vptr->pdev, PCI_D3hot);
+		velocity_set_power_state(vptr, PCI_D3hot);
 }
 
 static int velocity_get_settings(struct net_device *dev,
@@ -3267,7 +3497,11 @@ static void velocity_get_drvinfo(struct net_device *dev, struct ethtool_drvinfo
 	struct velocity_info *vptr = netdev_priv(dev);
 	strlcpy(info->driver, VELOCITY_NAME, sizeof(info->driver));
 	strlcpy(info->version, VELOCITY_VERSION, sizeof(info->version));
-	strlcpy(info->bus_info, pci_name(vptr->pdev), sizeof(info->bus_info));
+	if (vptr->bustype == BUS_PCI)
+		strlcpy(info->bus_info, pci_name(vptr->pdev),
+						sizeof(info->bus_info));
+	else
+		strlcpy(info->bus_info, "platform", sizeof(info->bus_info));
 }
 
 static void velocity_ethtool_get_wol(struct net_device *dev, struct ethtool_wolinfo *wol)
@@ -3560,9 +3794,15 @@ static int __init velocity_init_module(void)
 	int ret;
 
 	velocity_register_notifier();
-	ret = pci_register_driver(&velocity_driver);
+#ifdef CONFIG_PCI
+	ret = pci_register_driver(&velocity_pci_driver);
 	if (ret < 0)
 		velocity_unregister_notifier();
+#endif
+	ret = platform_driver_register(&velocity_platform_driver);
+	if (ret < 0)
+		velocity_unregister_notifier();
+
 	return ret;
 }
 
@@ -3577,7 +3817,10 @@ static int __init velocity_init_module(void)
 static void __exit velocity_cleanup_module(void)
 {
 	velocity_unregister_notifier();
-	pci_unregister_driver(&velocity_driver);
+#ifdef CONFIG_PCI
+	pci_unregister_driver(&velocity_pci_driver);
+#endif
+	platform_driver_unregister(&velocity_platform_driver);
 }
 
 module_init(velocity_init_module);
diff --git a/drivers/net/ethernet/via/via-velocity.h b/drivers/net/ethernet/via/via-velocity.h
index c38bbae..7468765 100644
--- a/drivers/net/ethernet/via/via-velocity.h
+++ b/drivers/net/ethernet/via/via-velocity.h
@@ -1265,7 +1265,7 @@ struct velocity_context {
 #define PHYID_VT3216_64BIT  0x000FC600UL
 #define PHYID_MARVELL_1000  0x01410C50UL
 #define PHYID_MARVELL_1000S 0x01410C40UL
-
+#define PHYID_ICPLUS_IP101A 0x02430C54UL
 #define PHYID_REV_ID_MASK   0x0000000FUL
 
 #define PHYID_GET_PHY_ID(i)         ((i) & ~PHYID_REV_ID_MASK)
@@ -1433,10 +1433,38 @@ struct velocity_opt {
 
 #define GET_RD_BY_IDX(vptr, idx)   (vptr->rd_ring[idx])
 
+static inline char velocity_choose_state(struct device *dev,
+					   pm_message_t state)
+
+{
+	switch (state.event) {
+	case PM_EVENT_ON:
+		return PCI_D0;
+	case PM_EVENT_FREEZE:
+	case PM_EVENT_PRETHAW:
+		/* REVISIT both freeze and pre-thaw "should" use D0 */
+	case PM_EVENT_SUSPEND:
+	case PM_EVENT_HIBERNATE:
+		return PCI_D3hot;
+	default:
+		dev_info(dev, "unrecognized suspend event %d\n", state.event);
+		BUG();
+	}
+
+	return PCI_D0;
+}
+
+enum velocity_bus_type {
+	BUS_PCI,
+	BUS_PLATFORM,
+};
+
 struct velocity_info {
 	struct device *dev;
 	struct pci_dev *pdev;
 	struct net_device *netdev;
+	enum velocity_bus_type bustype;
+	int no_eeprom;
 
 	unsigned long active_vlans[BITS_TO_LONGS(VLAN_N_VID)];
 	u8 ip_addr[4];
-- 
1.7.9.5



From pekon at ti.com  Mon Apr 29 03:53:59 2013
From: pekon at ti.com (Gupta, Pekon)
Date: Mon, 29 Apr 2013 13:23:59 +0530
Subject: [v2,1/3] ARM: dts: AM33XX: Add ELM node
Message-ID: <7fa7438c9a7c5da575d762423815625d523c4689.1359007746.git.avinashphilip@ti.com>

From: avinash philip <avinashphilip at ti.com>

From: "Philip, Avinash" <avinashphilip at ti.com>

Add ELM data node to AM33XX device tree file.

Signed-off-by: Philip Avinash <avinashphilip at ti.com>
Acked-by: Peter Korsgaard <jacmet at sunsite.dk>
Tested-by: Pekon Gupta <pekon at ti.com>

---
Changes since v2:
	- Replace <xx> literals to 52
	- remove tab

 arch/arm/boot/dts/am33xx.dtsi |    8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index da79618..115bf28 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -389,5 +389,13 @@
 				mac-address = [ 00 00 00 00 00 00 ];
 			};
 		};
+
+		elm: elm at 48080000 {
+			compatible = "ti,am3352-elm";
+			reg = <0x48080000 0x2000>;
+			interrupts = <4>;
+			ti,hwmods = "elm";
+			status = "disabled";
+		};
 	};
 };


From sfr at canb.auug.org.au  Mon Apr 29 03:54:26 2013
From: sfr at canb.auug.org.au (Stephen Rothwell)
Date: Mon, 29 Apr 2013 17:54:26 +1000
Subject: linux-next: manual merge of the arm-soc tree with the xen-arm tree
Message-ID: <20130429175426.9423279609437a2d746cbb7b@canb.auug.org.au>

Hi all,

Today's linux-next merge of the arm-soc tree got a conflict in
arch/arm/mach-virt/platsmp.c between commit fe4bff02886b ("arm: introduce
psci_smp_ops") from the xen-arm tree and commit c0114709ed85 ("irqchip:
gic: Perform the gic_secondary_init() call via CPU notifier") from the
arm-soc tree.

The former renamed the file (and contents) so I applied the following
patch and can carry the fix as necessary (no action is required).

From: Stephen Rothwell <sfr at canb.auug.org.au>
Date: Mon, 29 Apr 2013 17:52:27 +1000
Subject: [PATCH] arm: fix for Perform the gic_secondary_init() call via CPU
 notifier

due to code movement.

Signed-off-by: Stephen Rothwell <sfr at canb.auug.org.au>
---
 arch/arm/kernel/psci_smp.c | 7 -------
 1 file changed, 7 deletions(-)

diff --git a/arch/arm/kernel/psci_smp.c b/arch/arm/kernel/psci_smp.c
index 6ef139d..cd9acc7 100644
--- a/arch/arm/kernel/psci_smp.c
+++ b/arch/arm/kernel/psci_smp.c
@@ -14,7 +14,6 @@
  */
 
 #include <linux/init.h>
-#include <linux/irqchip/arm-gic.h>
 #include <linux/smp.h>
 #include <linux/of.h>
 
@@ -55,11 +54,6 @@ static int __cpuinit psci_boot_secondary(unsigned int cpu,
 	return -ENODEV;
 }
 
-static void __cpuinit psci_secondary_init(unsigned int cpu)
-{
-	gic_secondary_init(0);
-}
-
 #ifdef CONFIG_HOTPLUG_CPU
 void __ref psci_cpu_die(unsigned int cpu)
 {
@@ -84,7 +78,6 @@ bool __init psci_smp_available(void)
 }
 
 struct smp_operations __initdata psci_smp_ops = {
-	.smp_secondary_init	= psci_secondary_init,
 	.smp_boot_secondary	= psci_boot_secondary,
 	.cpu_die		= psci_cpu_die,
 };
-- 
1.8.1


-- 
Stephen Rothwell <sfr at canb.auug.org.au>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130429/35842c75/attachment.sig>

From pekon at ti.com  Mon Apr 29 03:55:36 2013
From: pekon at ti.com (Gupta, Pekon)
Date: Mon, 29 Apr 2013 13:25:36 +0530
Subject: [v2,2/3] ARM: dts: AM33XX: Add GPMC node
Message-ID: <2645efefa3d36388ff1d4b64255d880b6587770f.1359007746.git.avinashphilip@ti.com>

From: avinash philip <avinashphilip at ti.com>

From: "Philip, Avinash" <avinashphilip at ti.com>

Add GPMC data node to AM33XX device tree file.

Signed-off-by: Philip Avinash <avinashphilip at ti.com>
Acked-by: Peter Korsgaard <jacmet at sunsite.dk>
Tested-by: Pekon Gupta <pekon at ti.com>

---
Changes since v2:
	- Change number of chip select to 7

 arch/arm/boot/dts/am33xx.dtsi |   12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 115bf28..fbcb90b 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -397,5 +397,17 @@
 			ti,hwmods = "elm";
 			status = "disabled";
 		};
+
+		gpmc: gpmc at 50000000 {
+			compatible = "ti,am3352-gpmc";
+			ti,hwmods = "gpmc";
+			reg = <0x50000000 0x2000>;
+			interrupts = <100>;
+			num-cs = <7>;
+			num-waitpins = <2>;
+			#address-cells = <2>;
+			#size-cells = <1>;
+			status = "disabled";
+		};
 	};
 };


From pekon at ti.com  Mon Apr 29 03:55:47 2013
From: pekon at ti.com (Gupta, Pekon)
Date: Mon, 29 Apr 2013 13:25:47 +0530
Subject: [v2,
 3/3] ARM: dts: AM33XX: Add NAND flash device tree data to am335x-evm
Message-ID: <ebfab3e9123b3e50b9a9678c1480191addd86d59.1359007746.git.avinashphilip@ti.com>

From: avinash philip <avinashphilip at ti.com>

NAND flash connected in am335x-evm on GPMC controller. This patch adds
device tree node in am3355-evm with GPMC contoller timing for NAND flash
interface, NAND partition table, ECC scheme, elm handle id.

Signed-off-by: Philip Avinash <avinashphilip at ti.com>
Tested-by: Pekon Gupta <pekon at ti.com>

---
arch/arm/boot/dts/am335x-evm.dts |   98 +++++++++++++++++++++++++++++++++++++-
 1 file changed, 97 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index 0423298..1c2fd89 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -26,7 +26,8 @@
 
 	am33xx_pinmux: pinmux at 44e10800 {
 		pinctrl-names = "default";
-		pinctrl-0 = <&matrix_keypad_s0 &volume_keys_s0>;
+		pinctrl-0 = <&matrix_keypad_s0 &volume_keys_s0
+			&nandflash_pins_s0>;
 
 		matrix_keypad_s0: matrix_keypad_s0 {
 			pinctrl-single,pins = <
@@ -44,6 +45,26 @@
 				0x154 0x27	/* spi0_d0.gpio0_3, INPUT | MODE7 */
 			>;
 		};
+
+		nandflash_pins_s0: nandflash_pins_s0 {
+			pinctrl-single,pins = <
+				0x0 0x30	/* gpmc_ad0.gpmc_ad0, INPUT | PULLUP | MODE0 */
+				0x4 0x30	/* gpmc_ad1.gpmc_ad1, INPUT | PULLUP | MODE0 */
+				0x8 0x30	/* gpmc_ad2.gpmc_ad2, INPUT | PULLUP | MODE0 */
+				0xc 0x30	/* gpmc_ad3.gpmc_ad3, INPUT | PULLUP | MODE0 */
+				0x10 0x30	/* gpmc_ad4.gpmc_ad4, INPUT | PULLUP | MODE0 */
+				0x14 0x30	/* gpmc_ad5.gpmc_ad5, INPUT | PULLUP | MODE0 */
+				0x18 0x30	/* gpmc_ad6.gpmc_ad6, INPUT | PULLUP | MODE0 */
+				0x1c 0x30	/* gpmc_ad7.gpmc_ad7, INPUT | PULLUP | MODE0 */
+				0x70 0x30	/* gpmc_wait0.gpmc_wait0, INPUT | PULLUP | MODE0 */
+				0x74 0x37	/* gpmc_wpn.gpio0_30, INPUT | PULLUP | MODE7 */
+				0x7c 0x8	/* gpmc_csn0.gpmc_csn0,  PULL DISA */
+				0x90 0x8	/* gpmc_advn_ale.gpmc_advn_ale, PULL DISA */
+				0x94 0x8	/* gpmc_oen_ren.gpmc_oen_ren, PULL DISA */
+				0x98 0x8	/* gpmc_wen.gpmc_wen, PULL DISA */
+				0x9c 0x8	/* gpmc_be0n_cle.gpmc_be0n_cle, PULL DISA */
+			>;
+		};
 	};
 
 	ocp {
@@ -102,6 +123,81 @@
 				reg = <0x48>;
 			};
 		};
+
+		elm: elm at 48080000 {
+			status = "okay";
+		};
+
+		gpmc: gpmc at 50000000 {
+			status = "okay";
+			ranges = <0 0 0x08000000 0x10000000>;	/* CS0: NAND */
+
+			nand at 0,0 {
+				reg = <0 0 0>; /* CS0, offset 0 */
+				nand-bus-width = <8>;
+				ti,nand-ecc-opt = "bch8";
+
+				gpmc,sync-clk = <0>;
+				gpmc,cs-on = <0>;
+				gpmc,cs-rd-off = <44>;
+				gpmc,cs-wr-off = <44>;
+				gpmc,adv-on = <6>;
+				gpmc,adv-rd-off = <34>;
+				gpmc,adv-wr-off = <44>;
+				gpmc,we-off = <40>;
+				gpmc,oe-off = <54>;
+				gpmc,access = <64>;
+				gpmc,rd-cycle = <82>;
+				gpmc,wr-cycle = <82>;
+				gpmc,wr-access = <40>;
+				gpmc,wr-data-mux-bus = <0>;
+
+				#address-cells = <1>;
+				#size-cells = <1>;
+				elm_id = <&elm>;
+
+				/* MTD partition table */
+				partition at 0 {
+					label = "SPL1";
+					reg = <0x00000000 0x000020000>;
+				};
+
+				partition at 1 {
+					label = "SPL2";
+					reg = <0x00020000 0x00020000>;
+				};
+
+				partition at 2 {
+					label = "SPL3";
+					reg = <0x00040000 0x00020000>;
+				};
+
+				partition at 3 {
+					label = "SPL4";
+					reg = <0x00060000 0x00020000>;
+				};
+
+				partition at 4 {
+					label = "U-boot";
+					reg = <0x00080000 0x001e0000>;
+				};
+
+				partition at 5 {
+					label = "environment";
+					reg = <0x00260000 0x00020000>;
+				};
+
+				partition at 6 {
+					label = "Kernel";
+					reg = <0x00280000 0x00500000>;
+				};
+
+				partition at 7 {
+					label = "File-System";
+					reg = <0x00780000 0x0F880000>;
+				};
+			};
+		};
 	};
 
 	vbat: fixedregulator at 0 {


From inki.dae at samsung.com  Mon Apr 29 03:56:10 2013
From: inki.dae at samsung.com (Inki Dae)
Date: Mon, 29 Apr 2013 16:56:10 +0900
Subject: [PATCH] module: fix mutiple defined issue
In-Reply-To: <20130429073518.GZ15233@pengutronix.de>
References: <1367213521-26795-1-git-send-email-inki.dae@samsung.com>
 <20130429073518.GZ15233@pengutronix.de>
Message-ID: <016501ce44af$03129c80$0937d580$%dae@samsung.com>

Hi,


> -----Original Message-----
> From: linux-kernel-owner at vger.kernel.org [mailto:linux-kernel-
> owner at vger.kernel.org] On Behalf Of Uwe Kleine-Konig
> Sent: Monday, April 29, 2013 4:35 PM
> To: Inki Dae
> Cc: gregkh at linuxfoundation.org; linux-kernel at vger.kernel.org; dri-
> devel at lists.freedesktop.org; linux-arm-kernel at lists.infradead.org
> Subject: Re: [PATCH] module: fix mutiple defined issue
> 
> On Mon, Apr 29, 2013 at 02:32:01PM +0900, Inki Dae wrote:
> > This patch fixes mutiple defined issue to MODULE_DEVICE_TABLE
> s/mutiple/multiple/, still this sentence doesn't sound right. What is
> the error message you see?
> 
> > The issue could be induced when some framework which includes two
> > more sub drivers, is built as one moudle because those sub drivers
> s/moudle/module/
> 
> > could have their own MODULE_DEVICE_TABLE.
> >
> > And 'struct of_device_id' isn't needed to be determined by type
> > argument because the definition of 'of_device_id' should be fixed.
> > So this patch makes 'of_devce_id' definition to be fixed and
> > only its instance name to be defined by type.
> include/linux/isapnp.h uses:
> #define ISAPNP_CARD_TABLE(name) \
> 		MODULE_GENERIC_TABLE(isapnp_card, name)
> 
> and you changed the table's type with your patch. Ditto for all users of
> 
> 	MODULE_DEVICE_TABLE(i2c, ...);
> 	MODULE_DEVICE_TABLE(acpi, ...);
> 	MODULE_DEVICE_TABLE(platform, ...);
> 	MODULE_DEVICE_TABLE(pci, ...);
> 	MODULE_DEVICE_TABLE(sdio, ...);
> 
> So I'm pretty sure your patch is wrong and I expect it makes most
> defconfigs fail to compile.
>

It might be my big mistake. Maybe xxx_device_id object was created device
tree internally. Right? Will check it out again. So please ignore it.

Thanks,
Inki Dae


> Best regards
> Uwe
> 
> >
> > Signed-off-by: Inki Dae <inki.dae at samsung.com>
> > ---
> >  include/linux/module.h |    2 +-
> >  1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/include/linux/module.h b/include/linux/module.h
> > index 46f1ea0..ac5d79f 100644
> > --- a/include/linux/module.h
> > +++ b/include/linux/module.h
> > @@ -84,7 +84,7 @@ void trim_init_extable(struct module *m);
> >
> >  #ifdef MODULE
> >  #define MODULE_GENERIC_TABLE(gtype,name)			\
> > -extern const struct gtype##_id __mod_##gtype##_table		\
> > +extern const struct of_device_id __mod_##gtype##_table		\
> >    __attribute__ ((unused, alias(__stringify(name))))
> >
> >  #else  /* !MODULE */
> > --
> > 1.7.5.4
> >
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> >
> 
> --
> Pengutronix e.K.                           | Uwe Kleine-K?nig            |
> Industrial Linux Solutions                 | http://www.pengutronix.de/  |
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/



From catalin.marinas at arm.com  Mon Apr 29 04:25:12 2013
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Mon, 29 Apr 2013 09:25:12 +0100
Subject: linux-next: manual merge of the arm-soc tree with the xen-arm tree
In-Reply-To: <20130429175426.9423279609437a2d746cbb7b@canb.auug.org.au>
References: <20130429175426.9423279609437a2d746cbb7b@canb.auug.org.au>
Message-ID: <20130429082511.GA539@arm.com>

Stephen,

On Mon, Apr 29, 2013 at 08:54:26AM +0100, Stephen Rothwell wrote:
> Today's linux-next merge of the arm-soc tree got a conflict in
> arch/arm/mach-virt/platsmp.c between commit fe4bff02886b ("arm: introduce
> psci_smp_ops") from the xen-arm tree and commit c0114709ed85 ("irqchip:
> gic: Perform the gic_secondary_init() call via CPU notifier") from the
> arm-soc tree.
> 
> The former renamed the file (and contents) so I applied the following
> patch and can carry the fix as necessary (no action is required).
> 
> From: Stephen Rothwell <sfr at canb.auug.org.au>
> Date: Mon, 29 Apr 2013 17:52:27 +1000
> Subject: [PATCH] arm: fix for Perform the gic_secondary_init() call via CPU
>  notifier
> 
> due to code movement.
> 
> Signed-off-by: Stephen Rothwell <sfr at canb.auug.org.au>
> ---
>  arch/arm/kernel/psci_smp.c | 7 -------
>  1 file changed, 7 deletions(-)
> 
> diff --git a/arch/arm/kernel/psci_smp.c b/arch/arm/kernel/psci_smp.c
> index 6ef139d..cd9acc7 100644
> --- a/arch/arm/kernel/psci_smp.c
> +++ b/arch/arm/kernel/psci_smp.c
> @@ -14,7 +14,6 @@
>   */
>  
>  #include <linux/init.h>
> -#include <linux/irqchip/arm-gic.h>
>  #include <linux/smp.h>
>  #include <linux/of.h>
>  
> @@ -55,11 +54,6 @@ static int __cpuinit psci_boot_secondary(unsigned int cpu,
>  	return -ENODEV;
>  }
>  
> -static void __cpuinit psci_secondary_init(unsigned int cpu)
> -{
> -	gic_secondary_init(0);
> -}
> -
>  #ifdef CONFIG_HOTPLUG_CPU
>  void __ref psci_cpu_die(unsigned int cpu)
>  {
> @@ -84,7 +78,6 @@ bool __init psci_smp_available(void)
>  }
>  
>  struct smp_operations __initdata psci_smp_ops = {
> -	.smp_secondary_init	= psci_secondary_init,
>  	.smp_boot_secondary	= psci_boot_secondary,
>  	.cpu_die		= psci_cpu_die,
>  };

The fix looks fine. Thanks.

-- 
Catalin


From will.deacon at arm.com  Mon Apr 29 04:59:16 2013
From: will.deacon at arm.com (Will Deacon)
Date: Mon, 29 Apr 2013 09:59:16 +0100
Subject: [PATCH v9 1/2] arm: introduce psci_smp_ops
In-Reply-To: <1367160650-4888-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1304281544240.5398@kaball.uk.xensource.com>
 <1367160650-4888-1-git-send-email-stefano.stabellini@eu.citrix.com>
Message-ID: <20130429085916.GB8805@mudshark.cambridge.arm.com>

On Sun, Apr 28, 2013 at 03:50:49PM +0100, Stefano Stabellini wrote:
> Rename virt_smp_ops to psci_smp_ops and move them to arch/arm/kernel/psci_smp.c.
> Remove mach-virt/platsmp.c, now unused.
> Compile psci_smp if CONFIG_ARM_PSCI and CONFIG_SMP.
> 
> Add a cpu_die smp_op based on psci_ops.cpu_off.
> 
> Initialize PSCI before setting smp_ops in setup_arch.
> 
> If PSCI is available on the platform, prefer psci_smp_ops over the
> platform smp_ops.
> 
> Changes in v9:
> - move comment about PSCI interface from psci.h to psci_smp.c.
> 
> Changes in v8:
> - merge "prefer psci_smp_ops over mdesc->smp" into this patch.
> 
> Changes in v6:
> - fixed return values for psci_smp_available and psci_init ifndef
> CONFIG_ARM_PSCI.
> 
> Changes in v5:
> - document psci_operations;
> - psci_init returns NULL.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
> CC: Nicolas Pitre <nico at linaro.org>
> CC: Rob Herring <rob.herring at calxeda.com>
> CC: Will Deacon <will.deacon at arm.com>
> CC: arnd at arndb.de
> CC: marc.zyngier at arm.com
> CC: linux at arm.linux.org.uk


Acked-by: Will Deacon <will.deacon at arm.com>

Will


From linus.walleij at linaro.org  Mon Apr 29 05:05:35 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Mon, 29 Apr 2013 11:05:35 +0200
Subject: [PATCH 1/4] clocksource: nomadik-mtu: fix up clocksource/timer
In-Reply-To: <20130427001210.GA1714@quad.lixom.net>
References: <1366463287-9922-1-git-send-email-linus.walleij@linaro.org>
 <CACRpkdYWSM0BK77qWbQWh0xsN+Ps95Q70zG-GE98MYvThrky2A@mail.gmail.com>
 <20130427001210.GA1714@quad.lixom.net>
Message-ID: <CACRpkdZ6hcNtRkAL6a2SWm-5qCoKDW1KepZeJMqVGE6YnVBUng@mail.gmail.com>

On Sat, Apr 27, 2013 at 2:12 AM, Olof Johansson <olof at lixom.net> wrote:
> On Sat, Apr 20, 2013 at 03:19:43PM +0200, Linus Walleij wrote:
>> On Sat, Apr 20, 2013 at 3:08 PM, Linus Walleij <linus.walleij at linaro.org> wrote:
>>
>> > The Nomadik clocksource driver has had a bad define making it
>> > impossible to use it for sched_clock() for a while. Fix this
>> > and also enable it for the Nomadik.
>> >
>> > Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
>>
>> This one should go to fixes ASAP, could you pick it to your fixes
>> branch? It could be tagged stable if desired - this only affects the
>> Nomadik which works just OK on jiffies so it's really no big regression.
>> The Ux500 does not use the MTU for sched_clock().
>
> Ok, applied on top of next/multiplatform, seems to be what it's based on.
>
> Tagging as stable is up to you as platform owner. :) Since it won't directly
> apply to older kernels you might be better of submitting it to Greg separately.

Oh it's not *that* critical. It is not regressing anything in a bad way,
jiffies work fine. But this is the proper way for the Nomadik long-term.

Yours,
Linus Walleij


From stefano.stabellini at eu.citrix.com  Mon Apr 29 05:50:22 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Mon, 29 Apr 2013 10:50:22 +0100
Subject: linux-next: manual merge of the arm-soc tree with the xen-arm tree
In-Reply-To: <20130429082511.GA539@arm.com>
References: <20130429175426.9423279609437a2d746cbb7b@canb.auug.org.au>
 <20130429082511.GA539@arm.com>
Message-ID: <alpine.DEB.2.02.1304291049060.5398@kaball.uk.xensource.com>

On Mon, 29 Apr 2013, Catalin Marinas wrote:
> Stephen,
> 
> On Mon, Apr 29, 2013 at 08:54:26AM +0100, Stephen Rothwell wrote:
> > Today's linux-next merge of the arm-soc tree got a conflict in
> > arch/arm/mach-virt/platsmp.c between commit fe4bff02886b ("arm: introduce
> > psci_smp_ops") from the xen-arm tree and commit c0114709ed85 ("irqchip:
> > gic: Perform the gic_secondary_init() call via CPU notifier") from the
> > arm-soc tree.
> > 
> > The former renamed the file (and contents) so I applied the following
> > patch and can carry the fix as necessary (no action is required).
> > 
> > From: Stephen Rothwell <sfr at canb.auug.org.au>
> > Date: Mon, 29 Apr 2013 17:52:27 +1000
> > Subject: [PATCH] arm: fix for Perform the gic_secondary_init() call via CPU
> >  notifier
> > 
> > due to code movement.
> > 
> > Signed-off-by: Stephen Rothwell <sfr at canb.auug.org.au>
> > ---
> >  arch/arm/kernel/psci_smp.c | 7 -------
> >  1 file changed, 7 deletions(-)
> > 
> > diff --git a/arch/arm/kernel/psci_smp.c b/arch/arm/kernel/psci_smp.c
> > index 6ef139d..cd9acc7 100644
> > --- a/arch/arm/kernel/psci_smp.c
> > +++ b/arch/arm/kernel/psci_smp.c
> > @@ -14,7 +14,6 @@
> >   */
> >  
> >  #include <linux/init.h>
> > -#include <linux/irqchip/arm-gic.h>
> >  #include <linux/smp.h>
> >  #include <linux/of.h>
> >  
> > @@ -55,11 +54,6 @@ static int __cpuinit psci_boot_secondary(unsigned int cpu,
> >  	return -ENODEV;
> >  }
> >  
> > -static void __cpuinit psci_secondary_init(unsigned int cpu)
> > -{
> > -	gic_secondary_init(0);
> > -}
> > -
> >  #ifdef CONFIG_HOTPLUG_CPU
> >  void __ref psci_cpu_die(unsigned int cpu)
> >  {
> > @@ -84,7 +78,6 @@ bool __init psci_smp_available(void)
> >  }
> >  
> >  struct smp_operations __initdata psci_smp_ops = {
> > -	.smp_secondary_init	= psci_secondary_init,
> >  	.smp_boot_secondary	= psci_boot_secondary,
> >  	.cpu_die		= psci_cpu_die,
> >  };
> 
> The fix looks fine. Thanks.

Indeed, thanks! I'll add to it to the tree.


From nicolas.ferre at atmel.com  Mon Apr 29 05:54:46 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Mon, 29 Apr 2013 11:54:46 +0200
Subject: [RFC PATCH v3 05/17] ARM: dts: at91: cpus/cpu node dts updates
In-Reply-To: <1366824502-19729-6-git-send-email-lorenzo.pieralisi@arm.com>
References: <1366824502-19729-1-git-send-email-lorenzo.pieralisi@arm.com>
 <1366824502-19729-6-git-send-email-lorenzo.pieralisi@arm.com>
Message-ID: <517E4366.4040209@atmel.com>

On 04/24/2013 07:28 PM, Lorenzo Pieralisi :
> This patch updates the in-kernel dts files according to the latest cpus
> and cpu bindings updates for ARM.
> 
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>

With changes in compatible string... ok then.

Acked-by: Nicolas Ferre <nicolas.ferre at atmel.com>

> ---
>  arch/arm/boot/dts/at91rm9200.dtsi  | 6 +++++-
>  arch/arm/boot/dts/at91sam9260.dtsi | 8 ++++++--
>  arch/arm/boot/dts/at91sam9263.dtsi | 8 ++++++--
>  arch/arm/boot/dts/at91sam9g45.dtsi | 8 ++++++--
>  arch/arm/boot/dts/at91sam9n12.dtsi | 8 ++++++--
>  arch/arm/boot/dts/at91sam9x5.dtsi  | 8 ++++++--
>  6 files changed, 35 insertions(+), 11 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/at91rm9200.dtsi b/arch/arm/boot/dts/at91rm9200.dtsi
> index b0268a5..f16b3d4 100644
> --- a/arch/arm/boot/dts/at91rm9200.dtsi
> +++ b/arch/arm/boot/dts/at91rm9200.dtsi
> @@ -34,8 +34,12 @@
>  		ssc2 = &ssc2;
>  	};
>  	cpus {
> -		cpu at 0 {
> +		#address-cells = <0>;
> +		#size-cells = <0>;
> +
> +		cpu {
>  			compatible = "arm,arm920t";
> +			device_type = "cpu";
>  		};
>  	};
>  
> diff --git a/arch/arm/boot/dts/at91sam9260.dtsi b/arch/arm/boot/dts/at91sam9260.dtsi
> index cb7bcc5..c4eeef7 100644
> --- a/arch/arm/boot/dts/at91sam9260.dtsi
> +++ b/arch/arm/boot/dts/at91sam9260.dtsi
> @@ -32,8 +32,12 @@
>  		ssc0 = &ssc0;
>  	};
>  	cpus {
> -		cpu at 0 {
> -			compatible = "arm,arm926ejs";
> +		#address-cells = <0>;
> +		#size-cells = <0>;
> +
> +		cpu {
> +			compatible = "arm,arm926ej-s";
> +			device_type = "cpu";
>  		};
>  	};
>  
> diff --git a/arch/arm/boot/dts/at91sam9263.dtsi b/arch/arm/boot/dts/at91sam9263.dtsi
> index 271d4de..f3b5c2a 100644
> --- a/arch/arm/boot/dts/at91sam9263.dtsi
> +++ b/arch/arm/boot/dts/at91sam9263.dtsi
> @@ -29,8 +29,12 @@
>  		ssc1 = &ssc1;
>  	};
>  	cpus {
> -		cpu at 0 {
> -			compatible = "arm,arm926ejs";
> +		#address-cells = <0>;
> +		#size-cells = <0>;
> +
> +		cpu {
> +			compatible = "arm,arm926ej-s";
> +			device_type = "cpu";
>  		};
>  	};
>  
> diff --git a/arch/arm/boot/dts/at91sam9g45.dtsi b/arch/arm/boot/dts/at91sam9g45.dtsi
> index 6b1d4ca..6c18bd3 100644
> --- a/arch/arm/boot/dts/at91sam9g45.dtsi
> +++ b/arch/arm/boot/dts/at91sam9g45.dtsi
> @@ -35,8 +35,12 @@
>  		ssc1 = &ssc1;
>  	};
>  	cpus {
> -		cpu at 0 {
> -			compatible = "arm,arm926ejs";
> +		#address-cells = <0>;
> +		#size-cells = <0>;
> +
> +		cpu {
> +			compatible = "arm,arm926ej-s";
> +			device_type = "cpu";
>  		};
>  	};
>  
> diff --git a/arch/arm/boot/dts/at91sam9n12.dtsi b/arch/arm/boot/dts/at91sam9n12.dtsi
> index 7750f98..c3b11af 100644
> --- a/arch/arm/boot/dts/at91sam9n12.dtsi
> +++ b/arch/arm/boot/dts/at91sam9n12.dtsi
> @@ -31,8 +31,12 @@
>  		ssc0 = &ssc0;
>  	};
>  	cpus {
> -		cpu at 0 {
> -			compatible = "arm,arm926ejs";
> +		#address-cells = <0>;
> +		#size-cells = <0>;
> +
> +		cpu {
> +			compatible = "arm,arm926ej-s";
> +			device_type = "cpu";
>  		};
>  	};
>  
> diff --git a/arch/arm/boot/dts/at91sam9x5.dtsi b/arch/arm/boot/dts/at91sam9x5.dtsi
> index aa98e64..6c39d0f 100644
> --- a/arch/arm/boot/dts/at91sam9x5.dtsi
> +++ b/arch/arm/boot/dts/at91sam9x5.dtsi
> @@ -33,8 +33,12 @@
>  		ssc0 = &ssc0;
>  	};
>  	cpus {
> -		cpu at 0 {
> -			compatible = "arm,arm926ejs";
> +		#address-cells = <0>;
> +		#size-cells = <0>;
> +
> +		cpu {
> +			compatible = "arm,arm926ej-s";
> +			device_type = "cpu";
>  		};
>  	};
>  
> 


-- 
Nicolas Ferre


From linux at arm.linux.org.uk  Mon Apr 29 05:51:39 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Mon, 29 Apr 2013 10:51:39 +0100
Subject: [PATCH] module: fix mutiple defined issue
In-Reply-To: <1367213521-26795-1-git-send-email-inki.dae@samsung.com>
References: <1367213521-26795-1-git-send-email-inki.dae@samsung.com>
Message-ID: <20130429095138.GJ14496@n2100.arm.linux.org.uk>

On Mon, Apr 29, 2013 at 02:32:01PM +0900, Inki Dae wrote:
> This patch fixes mutiple defined issue to MODULE_DEVICE_TABLE
> 
> The issue could be induced when some framework which includes two
> more sub drivers, is built as one moudle because those sub drivers
> could have their own MODULE_DEVICE_TABLE.
> 
> And 'struct of_device_id' isn't needed to be determined by type
> argument because the definition of 'of_device_id' should be fixed.
> So this patch makes 'of_devce_id' definition to be fixed and
> only its instance name to be defined by type.
> 
> Signed-off-by: Inki Dae <inki.dae at samsung.com>
> ---
>  include/linux/module.h |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/include/linux/module.h b/include/linux/module.h
> index 46f1ea0..ac5d79f 100644
> --- a/include/linux/module.h
> +++ b/include/linux/module.h
> @@ -84,7 +84,7 @@ void trim_init_extable(struct module *m);
>  
>  #ifdef MODULE
>  #define MODULE_GENERIC_TABLE(gtype,name)			\
> -extern const struct gtype##_id __mod_##gtype##_table		\
> +extern const struct of_device_id __mod_##gtype##_table		\
>    __attribute__ ((unused, alias(__stringify(name))))
>  
>  #else  /* !MODULE */

This patch (a) looks wrong (why would a generic device table be limited
to of_device_id when it could be ISAPNP or something else?) and (b) how
does changing the type fix the "multiple defined issue" ?  (c) include
the errors that you're fixing in the commit log.


From kishon at ti.com  Mon Apr 29 06:03:26 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Mon, 29 Apr 2013 15:33:26 +0530
Subject: [PATCH v6 3/9] usb: phy: twl4030: use the new generic PHY framework
In-Reply-To: <1367229812-30574-1-git-send-email-kishon@ti.com>
References: <1367229812-30574-1-git-send-email-kishon@ti.com>
Message-ID: <1367229812-30574-4-git-send-email-kishon@ti.com>

Used the generic PHY framework API to create the PHY. For powering on
and powering off the PHY, power_on and power_off ops are used. Once the
MUSB OMAP glue is adapted to the new framework, the suspend and resume
ops of usb phy library will be removed.

However using the old usb phy library cannot be completely removed
because otg is intertwined with phy and moving to the new
framework completely will break otg. Once we have a separate otg state machine,
we can get rid of the usb phy library.

Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
---
 drivers/usb/phy/phy-twl4030-usb.c |   44 +++++++++++++++++++++++++++++++++++++
 1 file changed, 44 insertions(+)

diff --git a/drivers/usb/phy/phy-twl4030-usb.c b/drivers/usb/phy/phy-twl4030-usb.c
index 8f78d2d..ef6eadf 100644
--- a/drivers/usb/phy/phy-twl4030-usb.c
+++ b/drivers/usb/phy/phy-twl4030-usb.c
@@ -33,6 +33,7 @@
 #include <linux/io.h>
 #include <linux/delay.h>
 #include <linux/usb/otg.h>
+#include <linux/phy/phy.h>
 #include <linux/usb/musb-omap.h>
 #include <linux/usb/ulpi.h>
 #include <linux/i2c/twl.h>
@@ -431,6 +432,14 @@ static void twl4030_phy_suspend(struct twl4030_usb *twl, int controller_off)
 	dev_dbg(twl->dev, "%s\n", __func__);
 }
 
+static int twl4030_phy_power_off(struct phy *phy)
+{
+	struct twl4030_usb *twl = dev_get_drvdata(&phy->dev);
+
+	twl4030_phy_suspend(twl, 0);
+	return 0;
+}
+
 static void __twl4030_phy_resume(struct twl4030_usb *twl)
 {
 	twl4030_phy_power(twl, 1);
@@ -459,6 +468,14 @@ static void twl4030_phy_resume(struct twl4030_usb *twl)
 	}
 }
 
+static int twl4030_phy_power_on(struct phy *phy)
+{
+	struct twl4030_usb *twl = dev_get_drvdata(&phy->dev);
+
+	twl4030_phy_resume(twl);
+	return 0;
+}
+
 static int twl4030_usb_ldo_init(struct twl4030_usb *twl)
 {
 	/* Enable writing to power configuration registers */
@@ -609,6 +626,13 @@ static int twl4030_usb_phy_init(struct usb_phy *phy)
 	return 0;
 }
 
+static int twl4030_phy_init(struct phy *phy)
+{
+	struct twl4030_usb *twl = dev_get_drvdata(&phy->dev);
+
+	return twl4030_usb_phy_init(&twl->phy);
+}
+
 static int twl4030_set_suspend(struct usb_phy *x, int suspend)
 {
 	struct twl4030_usb *twl = phy_to_twl(x);
@@ -646,13 +670,22 @@ static int twl4030_set_host(struct usb_otg *otg, struct usb_bus *host)
 	return 0;
 }
 
+static const struct phy_ops ops = {
+	.init		= twl4030_phy_init,
+	.power_on	= twl4030_phy_power_on,
+	.power_off	= twl4030_phy_power_off,
+	.owner		= THIS_MODULE,
+};
+
 static int twl4030_usb_probe(struct platform_device *pdev)
 {
 	struct twl4030_usb_data *pdata = pdev->dev.platform_data;
 	struct twl4030_usb	*twl;
+	struct phy		*phy;
 	int			status, err;
 	struct usb_otg		*otg;
 	struct device_node	*np = pdev->dev.of_node;
+	struct phy_provider	*phy_provider;
 
 	twl = devm_kzalloc(&pdev->dev, sizeof *twl, GFP_KERNEL);
 	if (!twl)
@@ -689,6 +722,17 @@ static int twl4030_usb_probe(struct platform_device *pdev)
 	otg->set_host		= twl4030_set_host;
 	otg->set_peripheral	= twl4030_set_peripheral;
 
+	phy_provider = devm_of_phy_provider_register(twl->dev, THIS_MODULE,
+		of_phy_simple_xlate);
+	if (IS_ERR(phy_provider))
+		return PTR_ERR(phy_provider);
+
+	phy = devm_phy_create(twl->dev, 0, &ops, twl);
+	if (IS_ERR(phy)) {
+		dev_dbg(&pdev->dev, "Failed to create PHY\n");
+		return PTR_ERR(phy);
+	}
+
 	/* init spinlock for workqueue */
 	spin_lock_init(&twl->lock);
 
-- 
1.7.10.4



From kishon at ti.com  Mon Apr 29 06:03:29 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Mon, 29 Apr 2013 15:33:29 +0530
Subject: [PATCH v6 6/9] ARM: dts: omap: update usb_otg_hs data
In-Reply-To: <1367229812-30574-1-git-send-email-kishon@ti.com>
References: <1367229812-30574-1-git-send-email-kishon@ti.com>
Message-ID: <1367229812-30574-7-git-send-email-kishon@ti.com>

Updated the usb_otg_hs dt data to include the *phy* and *phy-names*
binding in order for the driver to use the new generic PHY framework.
Also updated the Documentation to include the binding information.
The PHY binding information can be found at
Documentation/devicetree/bindings/phy/phy-bindings.txt

Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
---
 Documentation/devicetree/bindings/usb/omap-usb.txt |    5 +++++
 Documentation/devicetree/bindings/usb/usb-phy.txt  |    6 ++++++
 arch/arm/boot/dts/omap3.dtsi                       |    2 ++
 arch/arm/boot/dts/omap4.dtsi                       |    3 +++
 arch/arm/boot/dts/twl4030.dtsi                     |    1 +
 5 files changed, 17 insertions(+)

diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt b/Documentation/devicetree/bindings/usb/omap-usb.txt
index d4769f3..c0871a7 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -19,6 +19,9 @@ OMAP MUSB GLUE
  - power : Should be "50". This signifies the controller can supply upto
    100mA when operating in host mode.
  - usb-phy : the phandle for the PHY device
+ - phys : the phandle for the PHY device (used by generic PHY framework)
+ - phy-names : the names of the PHY corresponding to the PHYs present in the
+   *phy* phandle.
 
 Optional properties:
  - ctrl-module : phandle of the control module this glue uses to write to
@@ -33,6 +36,8 @@ usb_otg_hs: usb_otg_hs at 4a0ab000 {
 	num-eps = <16>;
 	ram-bits = <12>;
 	ctrl-module = <&omap_control_usb>;
+	phys = <&usb2_phy>;
+	phy-names = "usb2-phy";
 };
 
 Board specific device node entry
diff --git a/Documentation/devicetree/bindings/usb/usb-phy.txt b/Documentation/devicetree/bindings/usb/usb-phy.txt
index 61496f5..c0245c8 100644
--- a/Documentation/devicetree/bindings/usb/usb-phy.txt
+++ b/Documentation/devicetree/bindings/usb/usb-phy.txt
@@ -5,6 +5,8 @@ OMAP USB2 PHY
 Required properties:
  - compatible: Should be "ti,omap-usb2"
  - reg : Address and length of the register set for the device.
+ - #phy-cells: determine the number of cells that should be given in the
+   phandle while referencing this phy.
 
 Optional properties:
  - ctrl-module : phandle of the control module used by PHY driver to power on
@@ -16,6 +18,7 @@ usb2phy at 4a0ad080 {
 	compatible = "ti,omap-usb2";
 	reg = <0x4a0ad080 0x58>;
 	ctrl-module = <&omap_control_usb>;
+	#phy-cells = <0>;
 };
 
 OMAP USB3 PHY
@@ -25,6 +28,8 @@ Required properties:
  - reg : Address and length of the register set for the device.
  - reg-names: The names of the register addresses corresponding to the registers
    filled in "reg".
+ - #phy-cells: determine the number of cells that should be given in the
+   phandle while referencing this phy.
 
 Optional properties:
  - ctrl-module : phandle of the control module used by PHY driver to power on
@@ -39,4 +44,5 @@ usb3phy at 4a084400 {
 	      <0x4a084c00 0x40>;
 	reg-names = "phy_rx", "phy_tx", "pll_ctrl";
 	ctrl-module = <&omap_control_usb>;
+	#phy-cells = <0>;
 };
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 4ad03d9..51b4bee 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -520,6 +520,8 @@
 			interrupt-names = "mc", "dma";
 			ti,hwmods = "usb_otg_hs";
 			usb-phy = <&usb2_phy>;
+			phys = <&usb2_phy>;
+			phy-names = "usb2-phy";
 			multipoint = <1>;
 			num-eps = <16>;
 			ram-bits = <12>;
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 2a56428..dae620b 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -517,6 +517,7 @@
 				compatible = "ti,omap-usb2";
 				reg = <0x4a0ad080 0x58>;
 				ctrl-module = <&omap_control_usb>;
+				#phy-cells = <0>;
 			};
 		};
 
@@ -655,6 +656,8 @@
 			interrupt-names = "mc", "dma";
 			ti,hwmods = "usb_otg_hs";
 			usb-phy = <&usb2_phy>;
+			phys = <&usb2_phy>;
+			phy-names = "usb2-phy";
 			multipoint = <1>;
 			num-eps = <16>;
 			ram-bits = <12>;
diff --git a/arch/arm/boot/dts/twl4030.dtsi b/arch/arm/boot/dts/twl4030.dtsi
index b3034da..ce4cd6f 100644
--- a/arch/arm/boot/dts/twl4030.dtsi
+++ b/arch/arm/boot/dts/twl4030.dtsi
@@ -80,6 +80,7 @@
 		usb1v8-supply = <&vusb1v8>;
 		usb3v1-supply = <&vusb3v1>;
 		usb_mode = <1>;
+		#phy-cells = <0>;
 	};
 
 	twl_pwm: pwm {
-- 
1.7.10.4



From kishon at ti.com  Mon Apr 29 06:03:28 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Mon, 29 Apr 2013 15:33:28 +0530
Subject: [PATCH v6 5/9] ARM: OMAP: USB: Add phy binding information
In-Reply-To: <1367229812-30574-1-git-send-email-kishon@ti.com>
References: <1367229812-30574-1-git-send-email-kishon@ti.com>
Message-ID: <1367229812-30574-6-git-send-email-kishon@ti.com>

In order for controllers to get PHY in case of non dt boot, the phy
binding information (phy device name) should be added in the platform
data of the controller.

Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
---
 arch/arm/mach-omap2/usb-musb.c |    6 +++++-
 include/linux/usb/musb.h       |    3 +++
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
index 3242a55..228288a 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -85,8 +85,12 @@ void __init usb_musb_init(struct omap_musb_board_data *musb_board_data)
 	musb_plat.mode = board_data->mode;
 	musb_plat.extvbus = board_data->extvbus;
 
-	if (cpu_is_omap44xx())
+	if (cpu_is_omap44xx()) {
 		musb_plat.has_mailbox = true;
+		musb_plat.phy_dev_name = "omap-usb2.3.auto.0";
+	} else if (cpu_is_omap34xx()) {
+		musb_plat.phy_dev_name = "twl4030_usb.0";
+	}
 
 	if (soc_is_am35xx()) {
 		oh_name = "am35x_otg_hs";
diff --git a/include/linux/usb/musb.h b/include/linux/usb/musb.h
index 053c268..0b733a3 100644
--- a/include/linux/usb/musb.h
+++ b/include/linux/usb/musb.h
@@ -104,6 +104,9 @@ struct musb_hdrc_platform_data {
 	/* for clk_get() */
 	const char	*clock;
 
+	/* phy device name */
+	const char	*phy_dev_name;
+
 	/* (HOST or OTG) switch VBUS on/off */
 	int		(*set_vbus)(struct device *dev, int is_on);
 
-- 
1.7.10.4



From kishon at ti.com  Mon Apr 29 06:03:31 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Mon, 29 Apr 2013 15:33:31 +0530
Subject: [PATCH v6 8/9] usb: phy: omap-usb2: remove *set_suspend* callback
 from omap-usb2
In-Reply-To: <1367229812-30574-1-git-send-email-kishon@ti.com>
References: <1367229812-30574-1-git-send-email-kishon@ti.com>
Message-ID: <1367229812-30574-9-git-send-email-kishon@ti.com>

Now that omap-usb2 is adapted to the new generic PHY framework,
*set_suspend* ops can be removed from omap-usb2 driver.

Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
---
 drivers/usb/phy/phy-omap-usb2.c |   24 ------------------------
 1 file changed, 24 deletions(-)

diff --git a/drivers/usb/phy/phy-omap-usb2.c b/drivers/usb/phy/phy-omap-usb2.c
index f8291a7..e2523f4 100644
--- a/drivers/usb/phy/phy-omap-usb2.c
+++ b/drivers/usb/phy/phy-omap-usb2.c
@@ -97,29 +97,6 @@ static int omap_usb_set_peripheral(struct usb_otg *otg,
 	return 0;
 }
 
-static int omap_usb2_suspend(struct usb_phy *x, int suspend)
-{
-	u32 ret;
-	struct omap_usb *phy = phy_to_omapusb(x);
-
-	if (suspend && !phy->is_suspended) {
-		omap_control_usb_phy_power(phy->control_dev, 0);
-		pm_runtime_put_sync(phy->dev);
-		phy->is_suspended = 1;
-	} else if (!suspend && phy->is_suspended) {
-		ret = pm_runtime_get_sync(phy->dev);
-		if (ret < 0) {
-			dev_err(phy->dev, "get_sync failed with err %d\n",
-									ret);
-			return ret;
-		}
-		omap_control_usb_phy_power(phy->control_dev, 1);
-		phy->is_suspended = 0;
-	}
-
-	return 0;
-}
-
 static int omap_usb_power_off(struct phy *x)
 {
 	struct omap_usb *phy = dev_get_drvdata(&x->dev);
@@ -167,7 +144,6 @@ static int omap_usb2_probe(struct platform_device *pdev)
 
 	phy->phy.dev		= phy->dev;
 	phy->phy.label		= "omap-usb2";
-	phy->phy.set_suspend	= omap_usb2_suspend;
 	phy->phy.otg		= otg;
 	phy->phy.type		= USB_PHY_TYPE_USB2;
 
-- 
1.7.10.4



From kishon at ti.com  Mon Apr 29 06:03:32 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Mon, 29 Apr 2013 15:33:32 +0530
Subject: [PATCH v6 9/9] usb: phy: twl4030-usb: remove *set_suspend* and
 *phy_init* ops
In-Reply-To: <1367229812-30574-1-git-send-email-kishon@ti.com>
References: <1367229812-30574-1-git-send-email-kishon@ti.com>
Message-ID: <1367229812-30574-10-git-send-email-kishon@ti.com>

Now that twl4030-usb is adapted to the new generic PHY framework,
*set_suspend* and *phy_init* ops can be removed from twl4030-usb driver.

Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
---
 drivers/usb/phy/phy-twl4030-usb.c |   55 ++++++++-----------------------------
 1 file changed, 12 insertions(+), 43 deletions(-)

diff --git a/drivers/usb/phy/phy-twl4030-usb.c b/drivers/usb/phy/phy-twl4030-usb.c
index dacbeb1..c7a2e3b 100644
--- a/drivers/usb/phy/phy-twl4030-usb.c
+++ b/drivers/usb/phy/phy-twl4030-usb.c
@@ -422,25 +422,20 @@ static void twl4030_phy_power(struct twl4030_usb *twl, int on)
 	}
 }
 
-static void twl4030_phy_suspend(struct twl4030_usb *twl, int controller_off)
+static int twl4030_phy_power_off(struct phy *phy)
 {
+	struct twl4030_usb *twl = dev_get_drvdata(&phy->dev);
+
 	if (twl->asleep)
-		return;
+		return 0;
 
 	twl4030_phy_power(twl, 0);
 	twl->asleep = 1;
 	dev_dbg(twl->dev, "%s\n", __func__);
-}
-
-static int twl4030_phy_power_off(struct phy *phy)
-{
-	struct twl4030_usb *twl = dev_get_drvdata(&phy->dev);
-
-	twl4030_phy_suspend(twl, 0);
 	return 0;
 }
 
-static void __twl4030_phy_resume(struct twl4030_usb *twl)
+static void __twl4030_phy_power_on(struct twl4030_usb *twl)
 {
 	twl4030_phy_power(twl, 1);
 	twl4030_i2c_access(twl, 1);
@@ -449,11 +444,13 @@ static void __twl4030_phy_resume(struct twl4030_usb *twl)
 		twl4030_i2c_access(twl, 0);
 }
 
-static void twl4030_phy_resume(struct twl4030_usb *twl)
+static int twl4030_phy_power_on(struct phy *phy)
 {
+	struct twl4030_usb *twl = dev_get_drvdata(&phy->dev);
+
 	if (!twl->asleep)
-		return;
-	__twl4030_phy_resume(twl);
+		return 0;
+	__twl4030_phy_power_on(twl);
 	twl->asleep = 0;
 	dev_dbg(twl->dev, "%s\n", __func__);
 
@@ -466,13 +463,6 @@ static void twl4030_phy_resume(struct twl4030_usb *twl)
 		cancel_delayed_work(&twl->id_workaround_work);
 		schedule_delayed_work(&twl->id_workaround_work, HZ);
 	}
-}
-
-static int twl4030_phy_power_on(struct phy *phy)
-{
-	struct twl4030_usb *twl = dev_get_drvdata(&phy->dev);
-
-	twl4030_phy_resume(twl);
 	return 0;
 }
 
@@ -604,9 +594,9 @@ static void twl4030_id_workaround_work(struct work_struct *work)
 	}
 }
 
-static int twl4030_usb_phy_init(struct usb_phy *phy)
+static int twl4030_phy_init(struct phy *phy)
 {
-	struct twl4030_usb *twl = phy_to_twl(phy);
+	struct twl4030_usb *twl = dev_get_drvdata(&phy->dev);
 	enum omap_musb_vbus_id_status status;
 
 	/*
@@ -626,25 +616,6 @@ static int twl4030_usb_phy_init(struct usb_phy *phy)
 	return 0;
 }
 
-static int twl4030_phy_init(struct phy *phy)
-{
-	struct twl4030_usb *twl = dev_get_drvdata(&phy->dev);
-
-	return twl4030_usb_phy_init(&twl->phy);
-}
-
-static int twl4030_set_suspend(struct usb_phy *x, int suspend)
-{
-	struct twl4030_usb *twl = phy_to_twl(x);
-
-	if (suspend)
-		twl4030_phy_suspend(twl, 1);
-	else
-		twl4030_phy_resume(twl);
-
-	return 0;
-}
-
 static int twl4030_set_peripheral(struct usb_otg *otg,
 					struct usb_gadget *gadget)
 {
@@ -715,8 +686,6 @@ static int twl4030_usb_probe(struct platform_device *pdev)
 	twl->phy.label		= "twl4030";
 	twl->phy.otg		= otg;
 	twl->phy.type		= USB_PHY_TYPE_USB2;
-	twl->phy.set_suspend	= twl4030_set_suspend;
-	twl->phy.init		= twl4030_usb_phy_init;
 
 	otg->phy		= &twl->phy;
 	otg->set_host		= twl4030_set_host;
-- 
1.7.10.4



From kishon at ti.com  Mon Apr 29 06:03:30 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Mon, 29 Apr 2013 15:33:30 +0530
Subject: [PATCH v6 7/9] usb: musb: omap2430: use the new generic PHY framework
In-Reply-To: <1367229812-30574-1-git-send-email-kishon@ti.com>
References: <1367229812-30574-1-git-send-email-kishon@ti.com>
Message-ID: <1367229812-30574-8-git-send-email-kishon@ti.com>

Use the generic PHY framework API to get the PHY. The usb_phy_set_resume
and usb_phy_set_suspend is replaced with power_on/get_sync and
power_off/put_sync to align with the new PHY framework.

musb->xceiv can't be removed as of now because musb core uses xceiv.state and
xceiv.otg. Once there is a separate state machine to handle otg, these can be
moved out of xceiv and then we can start using the generic PHY framework.

Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
---
 drivers/usb/musb/musb_core.c |    1 +
 drivers/usb/musb/musb_core.h |    3 +++
 drivers/usb/musb/omap2430.c  |   29 +++++++++++++++++++++--------
 3 files changed, 25 insertions(+), 8 deletions(-)

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 37a261a..2162148 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1864,6 +1864,7 @@ musb_init_controller(struct device *dev, int nIrq, void __iomem *ctrl)
 	musb->board_set_power = plat->set_power;
 	musb->min_power = plat->min_power;
 	musb->ops = plat->platform_ops;
+	musb->phy_dev_name = plat->phy_dev_name;
 
 	/* The musb_platform_init() call:
 	 *   - adjusts musb->mregs
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 7fb4819..09ac74c 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -46,6 +46,7 @@
 #include <linux/usb.h>
 #include <linux/usb/otg.h>
 #include <linux/usb/musb.h>
+#include <linux/phy/phy.h>
 
 struct musb;
 struct musb_hw_ep;
@@ -357,6 +358,7 @@ struct musb {
 	u16			int_tx;
 
 	struct usb_phy		*xceiv;
+	struct phy		*phy;
 
 	int nIrq;
 	unsigned		irq_wake:1;
@@ -434,6 +436,7 @@ struct musb {
 	unsigned                double_buffer_not_ok:1;
 
 	struct musb_hdrc_config	*config;
+	const char		*phy_dev_name;
 
 #ifdef MUSB_CONFIG_PROC_FS
 	struct proc_dir_entry *proc_entry;
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 3551f1a..56ffe5f 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -348,14 +348,24 @@ static int omap2430_musb_init(struct musb *musb)
 	 * up through ULPI.  TWL4030-family PMICs include one,
 	 * which needs a driver, drivers aren't always needed.
 	 */
-	if (dev->parent->of_node)
+	if (dev->parent->of_node) {
+		musb->phy = devm_phy_get(dev->parent, "usb2-phy");
+
+		/* We can't totally remove musb->xceiv as of now because
+		 * musb core uses xceiv.state and xceiv.otg. Once we have
+		 * a separate state machine to handle otg, these can be moved
+		 * out of xceiv and then we can start using the generic PHY
+		 * framework
+		 */
 		musb->xceiv = devm_usb_get_phy_by_phandle(dev->parent,
 		    "usb-phy", 0);
-	else
+	} else {
 		musb->xceiv = devm_usb_get_phy_dev(dev, 0);
+		musb->phy = devm_phy_get(dev, musb->phy_dev_name);
+	}
 
-	if (IS_ERR(musb->xceiv)) {
-		status = PTR_ERR(musb->xceiv);
+	if (IS_ERR(musb->xceiv) || IS_ERR(musb->phy)) {
+		status = PTR_ERR(musb->xceiv) | PTR_ERR(musb->phy);
 
 		if (status == -ENXIO)
 			return status;
@@ -397,9 +407,10 @@ static int omap2430_musb_init(struct musb *musb)
 	if (glue->status != OMAP_MUSB_UNKNOWN)
 		omap_musb_set_mailbox(glue);
 
-	usb_phy_init(musb->xceiv);
+	phy_init(musb->phy);
 
 	pm_runtime_put_noidle(musb->controller);
+	phy_pm_runtime_put(musb->phy);
 	return 0;
 
 err1:
@@ -460,6 +471,7 @@ static int omap2430_musb_exit(struct musb *musb)
 	del_timer_sync(&musb_idle_timer);
 
 	omap2430_low_level_exit(musb);
+	phy_exit(musb->phy);
 
 	return 0;
 }
@@ -618,7 +630,8 @@ static int omap2430_runtime_suspend(struct device *dev)
 				OTG_INTERFSEL);
 
 		omap2430_low_level_exit(musb);
-		usb_phy_set_suspend(musb->xceiv, 1);
+		phy_power_off(musb->phy);
+		phy_pm_runtime_put(musb->phy);
 	}
 
 	return 0;
@@ -633,8 +646,8 @@ static int omap2430_runtime_resume(struct device *dev)
 		omap2430_low_level_init(musb);
 		musb_writel(musb->mregs, OTG_INTERFSEL,
 				musb->context.otg_interfsel);
-
-		usb_phy_set_suspend(musb->xceiv, 0);
+		phy_pm_runtime_get_sync(musb->phy);
+		phy_power_on(musb->phy);
 	}
 
 	return 0;
-- 
1.7.10.4



From kishon at ti.com  Mon Apr 29 06:03:27 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Mon, 29 Apr 2013 15:33:27 +0530
Subject: [PATCH v6 4/9] usb: phy: twl4030: twl4030 shouldn't be subsys_initcall
In-Reply-To: <1367229812-30574-1-git-send-email-kishon@ti.com>
References: <1367229812-30574-1-git-send-email-kishon@ti.com>
Message-ID: <1367229812-30574-5-git-send-email-kishon@ti.com>

Changed the inticall from subsys_initcall to module_init for
twl4030-usb.

Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
---
 drivers/usb/phy/phy-twl4030-usb.c |   12 +-----------
 1 file changed, 1 insertion(+), 11 deletions(-)

diff --git a/drivers/usb/phy/phy-twl4030-usb.c b/drivers/usb/phy/phy-twl4030-usb.c
index ef6eadf..dacbeb1 100644
--- a/drivers/usb/phy/phy-twl4030-usb.c
+++ b/drivers/usb/phy/phy-twl4030-usb.c
@@ -820,17 +820,7 @@ static struct platform_driver twl4030_usb_driver = {
 	},
 };
 
-static int __init twl4030_usb_init(void)
-{
-	return platform_driver_register(&twl4030_usb_driver);
-}
-subsys_initcall(twl4030_usb_init);
-
-static void __exit twl4030_usb_exit(void)
-{
-	platform_driver_unregister(&twl4030_usb_driver);
-}
-module_exit(twl4030_usb_exit);
+module_platform_driver(twl4030_usb_driver);
 
 MODULE_ALIAS("platform:twl4030_usb");
 MODULE_AUTHOR("Texas Instruments, Inc, Nokia Corporation");
-- 
1.7.10.4



From kishon at ti.com  Mon Apr 29 06:03:25 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Mon, 29 Apr 2013 15:33:25 +0530
Subject: [PATCH v6 2/9] usb: phy: omap-usb2: use the new generic PHY framework
In-Reply-To: <1367229812-30574-1-git-send-email-kishon@ti.com>
References: <1367229812-30574-1-git-send-email-kishon@ti.com>
Message-ID: <1367229812-30574-3-git-send-email-kishon@ti.com>

Used the generic PHY framework API to create the PHY. Now the power off and
power on are done in omap_usb_power_off and omap_usb_power_on respectively.

However using the old USB PHY library cannot be completely removed
because OTG is intertwined with PHY and moving to the new framework
will break OTG. Once we have a separate OTG state machine, we
can get rid of the USB PHY library.

Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
---
 drivers/usb/phy/phy-omap-usb2.c |   36 ++++++++++++++++++++++++++++++++++++
 1 file changed, 36 insertions(+)

diff --git a/drivers/usb/phy/phy-omap-usb2.c b/drivers/usb/phy/phy-omap-usb2.c
index 844ab68..f8291a7 100644
--- a/drivers/usb/phy/phy-omap-usb2.c
+++ b/drivers/usb/phy/phy-omap-usb2.c
@@ -28,6 +28,7 @@
 #include <linux/pm_runtime.h>
 #include <linux/delay.h>
 #include <linux/usb/omap_control_usb.h>
+#include <linux/phy/phy.h>
 
 /**
  * omap_usb2_set_comparator - links the comparator present in the sytem with
@@ -119,10 +120,36 @@ static int omap_usb2_suspend(struct usb_phy *x, int suspend)
 	return 0;
 }
 
+static int omap_usb_power_off(struct phy *x)
+{
+	struct omap_usb *phy = dev_get_drvdata(&x->dev);
+
+	omap_control_usb_phy_power(phy->control_dev, 0);
+
+	return 0;
+}
+
+static int omap_usb_power_on(struct phy *x)
+{
+	struct omap_usb *phy = dev_get_drvdata(&x->dev);
+
+	omap_control_usb_phy_power(phy->control_dev, 1);
+
+	return 0;
+}
+
+static struct phy_ops ops = {
+	.power_on	= omap_usb_power_on,
+	.power_off	= omap_usb_power_off,
+	.owner		= THIS_MODULE,
+};
+
 static int omap_usb2_probe(struct platform_device *pdev)
 {
 	struct omap_usb			*phy;
+	struct phy			*generic_phy;
 	struct usb_otg			*otg;
+	struct phy_provider		*phy_provider;
 
 	phy = devm_kzalloc(&pdev->dev, sizeof(*phy), GFP_KERNEL);
 	if (!phy) {
@@ -144,6 +171,15 @@ static int omap_usb2_probe(struct platform_device *pdev)
 	phy->phy.otg		= otg;
 	phy->phy.type		= USB_PHY_TYPE_USB2;
 
+	phy_provider = devm_of_phy_provider_register(phy->dev, THIS_MODULE,
+		of_phy_simple_xlate);
+	if (IS_ERR(phy_provider))
+		return PTR_ERR(phy_provider);
+
+	generic_phy = devm_phy_create(phy->dev, 0, &ops, phy);
+	if (IS_ERR(generic_phy))
+		return PTR_ERR(generic_phy);
+
 	phy->control_dev = omap_get_control_dev();
 	if (IS_ERR(phy->control_dev)) {
 		dev_dbg(&pdev->dev, "Failed to get control device\n");
-- 
1.7.10.4



From kishon at ti.com  Mon Apr 29 06:03:23 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Mon, 29 Apr 2013 15:33:23 +0530
Subject: [PATCH v6 0/9] Generic PHY Framework
Message-ID: <1367229812-30574-1-git-send-email-kishon@ti.com>

Added a generic PHY framework that provides a set of APIs for the PHY drivers
to create/destroy a PHY and APIs for the PHY users to obtain a reference to
the PHY with or without using phandle.

This framework will be of use only to devices that uses external PHY (PHY
functionality is not embedded within the controller).

The intention of creating this framework is to bring the phy drivers spread
all over the Linux kernel to drivers/phy to increase code re-use and to
increase code maintainability.

Comments to make PHY as bus wasn't done because PHY devices can be part of
other bus and making a same device attached to multiple bus leads to bad
design.

If the PHY driver has to send notification on connect/disconnect, the PHY
driver should make use of the extcon framework. Using this susbsystem 
to use extcon framwork will have to be analysed.

Making omap-usb2 and twl4030 to use this framework is provided as a sample.

This patch series is developed on linux-next tree.

Changes from v5:
* removed the new sysfs entries as it dint have any new information other than
  what is already there in /sys/devices/...
* removed a bunch of APIs added to get the PHY and now only phy_get and
  devm_phy_get are used.
* Added new APIs to register/unregister the PHY provider. This is needed for
  dt boot case.
* Enabled pm runtime and incorporated the comments given by Alan Stern in a
  different patch series by Gautam.
* Removed the *phy_bind* API. Now the phy binding information should be passed
  using the platform data to the controller devices.
* Fixed a few typos.

Changes from v4:
* removed of_phy_get_with_args/devm_of_phy_get_with_args. Now the *phy providers*
  should use their custom implementation of of_xlate or use of_phy_xlate to get
  *phy instance* from *phy providers*.
* Added of_phy_xlate to be used by *phy providers* if it provides only one PHY.
* changed phy_core from having subsys_initcall to module_init.
* other minor fixes.

Changes from v3:
* Changed the return value of PHY APIs to ENOSYS
* Added APIs of_phy_get_with_args/devm_of_phy_get_with_args to support getting
  PHYs if the same IP implements multiple PHYs.
* modified phy_bind API so that the binding information can now be _updated_.
  In effect of this removed the binding information added in board files and
  added only in usb-musb.c. If a particular board uses a different phy binding,
  it can update it in board file after usb_musb_init().
* Added Documentation/devicetree/bindings/phy/phy-bindings.txt for dt binding
  information.

Changes from v2:
* removed phy_descriptor structure completely so changed the APIs which were
  taking phy_descriptor as parameters
* Added 2 more APIs *of_phy_get_byname* and *devm_of_phy_get_byname* to be used
  by PHY user drivers which has *phy* and *phy-names* binding in the dt data
* Fixed a few typos
* Removed phy_list and we now use class_dev_iter_init, class_dev_iter_next and
  class_dev_iter_exit for traversing through the phy list. (Note we still need
  phy_bind list and phy_bind_mutex).
* Changed the sysfs entry name from *bind* to *phy_bind*.

Changes from v1:
* Added Documentation for the PHY framework
* Added few more APIs mostly w.r.t devres
* Modified omap-usb2 and twl4030 to make use of the new framework

Did USB enumeration testing in panda and beagle.

Kishon Vijay Abraham I (9):
  drivers: phy: add generic PHY framework
  usb: phy: omap-usb2: use the new generic PHY framework
  usb: phy: twl4030: use the new generic PHY framework
  usb: phy: twl4030: twl4030 shouldn't be subsys_initcall
  ARM: OMAP: USB: Add phy binding information
  ARM: dts: omap: update usb_otg_hs data
  usb: musb: omap2430: use the new generic PHY framework
  usb: phy: omap-usb2: remove *set_suspend* callback from omap-usb2
  usb: phy: twl4030-usb: remove *set_suspend* and *phy_init* ops

 .../devicetree/bindings/phy/phy-bindings.txt       |   66 +++
 Documentation/devicetree/bindings/usb/omap-usb.txt |    5 +
 Documentation/devicetree/bindings/usb/usb-phy.txt  |    6 +
 Documentation/phy.txt                              |  123 +++++
 MAINTAINERS                                        |    7 +
 arch/arm/boot/dts/omap3.dtsi                       |    2 +
 arch/arm/boot/dts/omap4.dtsi                       |    3 +
 arch/arm/boot/dts/twl4030.dtsi                     |    1 +
 arch/arm/mach-omap2/usb-musb.c                     |    6 +-
 drivers/Kconfig                                    |    2 +
 drivers/Makefile                                   |    2 +
 drivers/phy/Kconfig                                |   13 +
 drivers/phy/Makefile                               |    5 +
 drivers/phy/phy-core.c                             |  539 ++++++++++++++++++++
 drivers/usb/musb/musb_core.c                       |    1 +
 drivers/usb/musb/musb_core.h                       |    3 +
 drivers/usb/musb/omap2430.c                        |   29 +-
 drivers/usb/phy/phy-omap-usb2.c                    |   50 +-
 drivers/usb/phy/phy-twl4030-usb.c                  |   69 +--
 include/linux/phy/phy.h                            |  248 +++++++++
 include/linux/usb/musb.h                           |    3 +
 21 files changed, 1122 insertions(+), 61 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/phy/phy-bindings.txt
 create mode 100644 Documentation/phy.txt
 create mode 100644 drivers/phy/Kconfig
 create mode 100644 drivers/phy/Makefile
 create mode 100644 drivers/phy/phy-core.c
 create mode 100644 include/linux/phy/phy.h

-- 
1.7.10.4



From kishon at ti.com  Mon Apr 29 06:03:24 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Mon, 29 Apr 2013 15:33:24 +0530
Subject: [PATCH v6 1/9] drivers: phy: add generic PHY framework
In-Reply-To: <1367229812-30574-1-git-send-email-kishon@ti.com>
References: <1367229812-30574-1-git-send-email-kishon@ti.com>
Message-ID: <1367229812-30574-2-git-send-email-kishon@ti.com>

The PHY framework provides a set of APIs for the PHY drivers to
create/destroy a PHY and APIs for the PHY users to obtain a reference to the
PHY with or without using phandle. For dt-boot, the PHY drivers should
also register *PHY provider* with the framework.

PHY drivers should create the PHY by passing id and ops like init, exit,
power_on and power_off. This framework is also pm runtime enabled.

The documentation for the generic PHY framework is added in
Documentation/phy.txt and the documentation for dt binding can be found at
Documentation/devicetree/bindings/phy/phy-bindings.txt

Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
---
 .../devicetree/bindings/phy/phy-bindings.txt       |   66 +++
 Documentation/phy.txt                              |  123 +++++
 MAINTAINERS                                        |    7 +
 drivers/Kconfig                                    |    2 +
 drivers/Makefile                                   |    2 +
 drivers/phy/Kconfig                                |   13 +
 drivers/phy/Makefile                               |    5 +
 drivers/phy/phy-core.c                             |  539 ++++++++++++++++++++
 include/linux/phy/phy.h                            |  248 +++++++++
 9 files changed, 1005 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/phy-bindings.txt
 create mode 100644 Documentation/phy.txt
 create mode 100644 drivers/phy/Kconfig
 create mode 100644 drivers/phy/Makefile
 create mode 100644 drivers/phy/phy-core.c
 create mode 100644 include/linux/phy/phy.h

diff --git a/Documentation/devicetree/bindings/phy/phy-bindings.txt b/Documentation/devicetree/bindings/phy/phy-bindings.txt
new file mode 100644
index 0000000..8ae844f
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-bindings.txt
@@ -0,0 +1,66 @@
+This document explains only the device tree data binding. For general
+information about PHY subsystem refer to Documentation/phy.txt
+
+PHY device node
+===============
+
+Required Properties:
+#phy-cells:	Number of cells in a PHY specifier;  The meaning of all those
+		cells is defined by the binding for the phy node. The PHY
+		provider can use the values in cells to find the appropriate
+		PHY.
+
+For example:
+
+phys: phy {
+    compatible = "xxx";
+    reg = <...>;
+    .
+    .
+    #phy-cells = <1>;
+    .
+    .
+};
+
+That node describes an IP block (PHY provider) that implements 2 different PHYs.
+In order to differentiate between these 2 PHYs, an additonal specifier should be
+given while trying to get a reference to it.
+
+PHY user node
+=============
+
+Required Properties:
+phys : the phandle for the PHY device (used by the PHY subsystem)
+phy-names : the names of the PHY corresponding to the PHYs present in the
+	    *phys* phandle
+
+Example 1:
+usb1: usb_otg_ss at xxx {
+    compatible = "xxx";
+    reg = <xxx>;
+    .
+    .
+    phys = <&usb2_phy>, <&usb3_phy>;
+    phy-names = "usb2phy", "usb3phy";
+    .
+    .
+};
+
+This node represents a controller that uses two PHYs, one for usb2 and one for
+usb3.
+
+Example 2:
+usb2: usb_otg_ss at xxx {
+    compatible = "xxx";
+    reg = <xxx>;
+    .
+    .
+    phys = <&phys 1>;
+    phy-names = "usbphy";
+    .
+    .
+};
+
+This node represents a controller that uses one of the PHYs of the PHY provider
+device defined previously. Note that the phy handle has an additional specifier
+"1" to differentiate between the two PHYs.
diff --git a/Documentation/phy.txt b/Documentation/phy.txt
new file mode 100644
index 0000000..408d25f
--- /dev/null
+++ b/Documentation/phy.txt
@@ -0,0 +1,123 @@
+			    PHY SUBSYSTEM
+		  Kishon Vijay Abraham I <kishon at ti.com>
+
+This document explains the Generic PHY Framework along with the APIs provided,
+and how-to-use.
+
+1. Introduction
+
+*PHY* is the abbreviation for physical layer. It is used to connect a device
+to the physical medium e.g., the USB controller has a PHY to provide functions
+such as serialization, de-serialization, encoding, decoding and is responsible
+for obtaining the required data transmission rate. Note that some USB
+controller has PHY functionality embedded into it and others use an external
+PHY. Other peripherals that uses a PHY include Wireless LAN, Ethernet,
+SATA etc.
+
+The intention of creating this framework is to bring the phy drivers spread
+all over the Linux kernel to drivers/phy to increase code re-use and for
+better code maintainability.
+
+This framework will be of use only to devices that uses external PHY (PHY
+functionality is not embedded within the controller).
+
+2. Registering/UnRegistering the PHY provider
+
+PHY provider refers to an entity that implements one or more PHY instances.
+For the simple case where the PHY provider implements only a single instance of
+the PHY, the framework provides its own implementation of of_xlate in
+of_phy_simple_xlate. If the PHY provider implements multiple instances, it
+should provide it's own implementation of of_xlate. of_xlate is used only for
+dt boot case.
+
+struct phy_provider *of_phy_provider_register(struct device *dev,
+	struct module *owner, struct phy * (*of_xlate)(struct device *dev,
+	struct of_phandle_args *args));
+struct phy_provider *devm_of_phy_provider_register(struct device *dev,
+	struct module *owner, struct phy * (*of_xlate)(struct device *dev,
+	struct of_phandle_args *args))
+
+of_phy_provider_register and devm_of_phy_provider_register can be used to
+register the phy_provider and it takes device, owner and of_xlate as
+arguments. For the dt boot case, all PHY providers should use one of the above
+2 APIs to register the PHY provider.
+
+void devm_of_phy_provider_unregister(struct device *dev,
+	struct phy_provider *phy_provider);
+void of_phy_provider_unregister(struct phy_provider *phy_provider);
+
+devm_of_phy_provider_unregister and of_phy_provider_unregister can be used to
+unregister the PHY.
+
+3. Creating the PHY
+
+The PHY driver should create the PHY in order for other peripheral controllers
+to make use of it. The PHY framework provides 2 APIs to create the PHY.
+
+struct phy *phy_create(struct device *dev, int id, const struct phy_ops *ops,
+	void *priv);
+struct phy *devm_phy_create(struct device *dev, int id,
+	const struct phy_ops *ops, void *priv);
+
+The PHY drivers can use one of the above 2 APIs to create the PHY by passing
+the device pointer, id, phy ops and a driver data.
+phy_ops is a set of function pointers for performing PHY operations such as
+init, exit, power_on and power_off.
+
+4. Getting a reference to the PHY
+
+Before the controller can make use of the PHY, it has to get a reference to
+it. This framework provides the following APIs to get a reference to the PHY.
+
+struct phy *phy_get(struct device *dev, const char *string);
+struct phy *devm_phy_get(struct device *dev, const char *string);
+
+phy_get and devm_phy_get can be used to get the PHY. In the case of dt boot,
+the string arguments should contain the phy name as given in the dt data and
+in the case of non-dt boot, it should contain the device name of the PHY.
+The only difference between the two APIs is that devm_phy_get associates the
+device with the PHY using devres on successful PHY get. On driver detach,
+release function is invoked on the the devres data and devres data is freed.
+
+5. Releasing a reference to the PHY
+
+When the controller no longer needs the PHY, it has to release the reference
+to the PHY it has obtained using the APIs mentioned in the above section. The
+PHY framework provides 2 APIS to release a reference to the PHY.
+
+void phy_put(struct phy *phy);
+void devm_phy_put(struct device *dev, struct phy *phy);
+
+Both these APIs are used to release a reference to the PHY and devm_phy_put
+destroys the devres associated with this PHY.
+
+6. Destroying the PHY
+
+When the driver that created the PHY is unloaded, it should destroy the PHY it
+created using one of the following 2 APIs.
+
+void phy_destroy(struct phy *phy);
+void devm_phy_destroy(struct device *dev, struct phy *phy);
+
+Both these APIs destroys the PHY and devm_phy_destroy destroys the devres
+associated with this PHY.
+
+7. PM Runtime
+
+This subsystem is pm runtime enabled. So while creating the PHY,
+pm_runtime_enable of the phy device created by this subsystem is called and
+while destroying the PHY, pm_runtime_disable is called. Note that the phy
+device created by this subsystem will be a child of the device that calls
+phy_create (PHY provider device).
+
+During phy_init, the clocks are enabled by calling get_sync and the clocks are
+disable by calling put_sync during phy_exit. get_sync of the phy_device
+created by this susbsystem will invoke get_sync of PHY provider device because
+of parent-child relationship. For all other pm operations, there are exported
+APIs like phy_pm_runtime_get, phy_pm_runtime_get_sync, phy_pm_runtime_put,
+phy_pm_runtime_put_sync, phy_pm_runtime_allow and phy_pm_runtime_forbid.
+
+8. DeviceTree Binding
+
+The documentation for PHY dt binding can be found @
+Documentation/devicetree/bindings/phy/phy-bindings.txt
diff --git a/MAINTAINERS b/MAINTAINERS
index 68d376e..8584fdb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3515,6 +3515,13 @@ S:	Maintained
 F:	include/asm-generic
 F:	include/uapi/asm-generic
 
+GENERIC PHY FRAMEWORK
+M:	Kishon Vijay Abraham I <kishon at ti.com>
+L:	linux-kernel at vger.kernel.org
+S:	Supported
+F:	drivers/phy/
+F:	include/linux/phy/
+
 GENERIC UIO DRIVER FOR PCI DEVICES
 M:	"Michael S. Tsirkin" <mst at redhat.com>
 L:	kvm at vger.kernel.org
diff --git a/drivers/Kconfig b/drivers/Kconfig
index 9953a42..2943fb6 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -166,4 +166,6 @@ source "drivers/ipack/Kconfig"
 
 source "drivers/reset/Kconfig"
 
+source "drivers/phy/Kconfig"
+
 endmenu
diff --git a/drivers/Makefile b/drivers/Makefile
index 130abc1..ce9f0d2 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -8,6 +8,8 @@
 obj-y				+= irqchip/
 obj-y				+= bus/
 
+obj-y				+= phy/
+
 # GPIO must come after pinctrl as gpios may need to mux pins etc
 obj-y				+= pinctrl/
 obj-y				+= gpio/
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
new file mode 100644
index 0000000..5f85909
--- /dev/null
+++ b/drivers/phy/Kconfig
@@ -0,0 +1,13 @@
+#
+# PHY
+#
+
+menuconfig GENERIC_PHY
+	tristate "PHY Subsystem"
+	help
+	  Generic PHY support.
+
+	  This framework is designed to provide a generic interface for PHY
+	  devices present in the kernel. This layer will have the generic
+	  API by which phy drivers can create PHY using the phy framework and
+	  phy users can obtain reference to the PHY.
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
new file mode 100644
index 0000000..9e9560f
--- /dev/null
+++ b/drivers/phy/Makefile
@@ -0,0 +1,5 @@
+#
+# Makefile for the phy drivers.
+#
+
+obj-$(CONFIG_GENERIC_PHY)	+= phy-core.o
diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
new file mode 100644
index 0000000..4e9e1c5
--- /dev/null
+++ b/drivers/phy/phy-core.c
@@ -0,0 +1,539 @@
+/*
+ * phy-core.c  --  Generic Phy framework.
+ *
+ * Copyright (C) 2013 Texas Instruments
+ *
+ * Author: Kishon Vijay Abraham I <kishon at ti.com>
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <linux/kernel.h>
+#include <linux/export.h>
+#include <linux/module.h>
+#include <linux/err.h>
+#include <linux/device.h>
+#include <linux/slab.h>
+#include <linux/of.h>
+#include <linux/phy/phy.h>
+#include <linux/pm_runtime.h>
+
+static struct class *phy_class;
+static DEFINE_MUTEX(phy_provider_mutex);
+static LIST_HEAD(phy_provider_list);
+
+static void devm_phy_release(struct device *dev, void *res)
+{
+	struct phy *phy = *(struct phy **)res;
+
+	phy_put(phy);
+}
+
+static void devm_phy_provider_release(struct device *dev, void *res)
+{
+	struct phy_provider *phy_provider = *(struct phy_provider **)res;
+
+	of_phy_provider_unregister(phy_provider);
+}
+
+static void devm_phy_consume(struct device *dev, void *res)
+{
+	struct phy *phy = *(struct phy **)res;
+
+	phy_destroy(phy);
+}
+
+static int devm_phy_match(struct device *dev, void *res, void *match_data)
+{
+	return res == match_data;
+}
+
+static struct phy *phy_lookup(const char *phy_dev_name)
+{
+	struct phy *phy;
+	struct device *dev;
+	struct class_dev_iter iter;
+
+	class_dev_iter_init(&iter, phy_class, NULL, NULL);
+	while ((dev = class_dev_iter_next(&iter))) {
+		if (strcmp(dev_name(dev), phy_dev_name))
+			continue;
+
+		phy = container_of(dev, struct phy, dev);
+		class_dev_iter_exit(&iter);
+		return phy;
+	}
+
+	class_dev_iter_exit(&iter);
+	return ERR_PTR(-ENODEV);
+}
+
+static struct phy_provider *of_phy_provider_lookup(struct device_node *node)
+{
+	struct phy_provider *phy_provider;
+
+	list_for_each_entry(phy_provider, &phy_provider_list, list) {
+		if (phy_provider->dev->of_node == node)
+			return phy_provider;
+	}
+
+	return ERR_PTR(-EPROBE_DEFER);
+}
+
+/**
+ * of_phy_get() - lookup and obtain a reference to a phy by phandle
+ * @dev: device that requests this phy
+ * @index: the index of the phy
+ *
+ * Returns the phy associated with the given phandle value,
+ * after getting a refcount to it or -ENODEV if there is no such phy or
+ * -EPROBE_DEFER if there is a phandle to the phy, but the device is
+ * not yet loaded. This function uses of_xlate call back function provided
+ * while registering the phy_provider to find the phy instance.
+ */
+static struct phy *of_phy_get(struct device *dev, int index)
+{
+	int ret;
+	struct phy_provider *phy_provider;
+	struct phy *phy = NULL;
+	struct of_phandle_args args;
+
+	ret = of_parse_phandle_with_args(dev->of_node, "phys", "#phy-cells",
+		index, &args);
+	if (ret) {
+		dev_dbg(dev, "failed to get phy in %s node\n",
+			dev->of_node->full_name);
+		return ERR_PTR(-ENODEV);
+	}
+
+	mutex_lock(&phy_provider_mutex);
+	phy_provider = of_phy_provider_lookup(args.np);
+	if (IS_ERR(phy_provider) || !try_module_get(phy_provider->owner)) {
+		phy = ERR_PTR(-EPROBE_DEFER);
+		goto err0;
+	}
+
+	phy = phy_provider->of_xlate(phy_provider->dev, &args);
+	module_put(phy_provider->owner);
+
+err0:
+	mutex_unlock(&phy_provider_mutex);
+	of_node_put(args.np);
+
+	return phy;
+}
+
+/**
+ * phy_put() - release the PHY
+ * @phy: the phy returned by phy_get()
+ *
+ * Releases a refcount the caller received from phy_get().
+ */
+void phy_put(struct phy *phy)
+{
+	if (IS_ERR(phy))
+		return;
+
+	module_put(phy->ops->owner);
+	put_device(&phy->dev);
+}
+EXPORT_SYMBOL_GPL(phy_put);
+
+/**
+ * devm_phy_put() - release the PHY
+ * @dev: device that wants to release this phy
+ * @phy: the phy returned by devm_phy_get()
+ *
+ * destroys the devres associated with this phy and invokes phy_put
+ * to release the phy.
+ */
+void devm_phy_put(struct device *dev, struct phy *phy)
+{
+	int r;
+
+	r = devres_destroy(dev, devm_phy_release, devm_phy_match, phy);
+	dev_WARN_ONCE(dev, r, "couldn't find PHY resource\n");
+}
+EXPORT_SYMBOL_GPL(devm_phy_put);
+
+/**
+ * of_phy_simple_xlate() - returns the phy instance from phy provider
+ * @dev: the PHY provider device
+ * @args: of_phandle_args (not used here)
+ *
+ * Intended to be used by phy provider for the common case where #phy-cells is
+ * 0. For other cases where #phy-cells is greater than '0', the phy provider
+ * should provide a custom of_xlate function that reads the *args* and returns
+ * the appropriate phy.
+ */
+struct phy *of_phy_simple_xlate(struct device *dev, struct of_phandle_args
+	*args)
+{
+	struct phy *phy;
+	struct class_dev_iter iter;
+	struct device_node *node = dev->of_node;
+
+	class_dev_iter_init(&iter, phy_class, NULL, NULL);
+	while ((dev = class_dev_iter_next(&iter))) {
+		phy = container_of(dev, struct phy, dev);
+		if (node != phy->dev.of_node)
+			continue;
+
+		class_dev_iter_exit(&iter);
+		return phy;
+	}
+
+	class_dev_iter_exit(&iter);
+	return ERR_PTR(-ENODEV);
+}
+EXPORT_SYMBOL_GPL(of_phy_simple_xlate);
+
+/**
+ * phy_get() - lookup and obtain a reference to a phy.
+ * @dev: device that requests this phy
+ * @string: the phy name as given in the dt data or phy device name
+ * for non-dt case
+ *
+ * Returns the phy driver, after getting a refcount to it; or
+ * -ENODEV if there is no such phy.  The caller is responsible for
+ * calling phy_put() to release that count.
+ */
+struct phy *phy_get(struct device *dev, const char *string)
+{
+	int index = 0;
+	struct phy *phy = NULL;
+
+	if (string == NULL) {
+		dev_WARN(dev, "missing string\n");
+		return ERR_PTR(-EINVAL);
+	}
+
+	if (dev->of_node) {
+		index = of_property_match_string(dev->of_node, "phy-names",
+			string);
+		phy = of_phy_get(dev, index);
+		if (IS_ERR(phy)) {
+			dev_WARN(dev, "unable to find phy\n");
+			return phy;
+		}
+	} else {
+		phy = phy_lookup(string);
+		if (IS_ERR(phy)) {
+			dev_WARN(dev, "unable to find phy\n");
+			return phy;
+		}
+	}
+
+	if (!try_module_get(phy->ops->owner))
+		return ERR_PTR(-EPROBE_DEFER);
+
+	get_device(&phy->dev);
+
+	return phy;
+}
+EXPORT_SYMBOL_GPL(phy_get);
+
+/**
+ * devm_phy_get() - lookup and obtain a reference to a phy.
+ * @dev: device that requests this phy
+ * @string: the phy name as given in the dt data or phy device name
+ * for non-dt case
+ *
+ * Gets the phy using phy_get(), and associates a device with it using
+ * devres. On driver detach, release function is invoked on the devres data,
+ * then, devres data is freed.
+ */
+struct phy *devm_phy_get(struct device *dev, const char *string)
+{
+	struct phy **ptr, *phy;
+
+	ptr = devres_alloc(devm_phy_release, sizeof(*ptr), GFP_KERNEL);
+	if (!ptr)
+		return ERR_PTR(-ENOMEM);
+
+	phy = phy_get(dev, string);
+	if (!IS_ERR(phy)) {
+		*ptr = phy;
+		devres_add(dev, ptr);
+	} else {
+		devres_free(ptr);
+	}
+
+	return phy;
+}
+EXPORT_SYMBOL_GPL(devm_phy_get);
+
+/**
+ * phy_create() - create a new phy
+ * @dev: device that is creating the new phy
+ * @id: id of the phy
+ * @ops: function pointers for performing phy operations
+ * @priv: private data from phy driver
+ *
+ * Called to create a phy using phy framework.
+ */
+struct phy *phy_create(struct device *dev, u8 id, const struct phy_ops *ops,
+	void *priv)
+{
+	int ret;
+	struct phy *phy;
+
+	if (!dev) {
+		dev_WARN(dev, "no device provided for PHY\n");
+		ret = -EINVAL;
+		goto err0;
+	}
+
+	phy = kzalloc(sizeof(*phy), GFP_KERNEL);
+	if (!phy) {
+		ret = -ENOMEM;
+		goto err0;
+	}
+
+	device_initialize(&phy->dev);
+
+	phy->dev.class = phy_class;
+	phy->dev.parent = dev;
+	phy->dev.of_node = dev->of_node;
+	phy->id = id;
+	phy->ops = ops;
+
+	dev_set_drvdata(&phy->dev, priv);
+
+	ret = dev_set_name(&phy->dev, "%s.%d", dev_name(dev), id);
+	if (ret)
+		goto err1;
+
+	ret = device_add(&phy->dev);
+	if (ret)
+		goto err1;
+
+	pm_runtime_enable(&phy->dev);
+
+	return phy;
+
+err1:
+	put_device(&phy->dev);
+	kfree(phy);
+
+err0:
+	return ERR_PTR(ret);
+}
+EXPORT_SYMBOL_GPL(phy_create);
+
+/**
+ * devm_phy_create() - create a new phy
+ * @dev: device that is creating the new phy
+ * @id: id of the phy
+ * @ops: function pointers for performing phy operations
+ * @priv: private data from phy driver
+ *
+ * Creates a new PHY device adding it to the PHY class.
+ * While at that, it also associates the device with the phy using devres.
+ * On driver detach, release function is invoked on the devres data,
+ * then, devres data is freed.
+ */
+struct phy *devm_phy_create(struct device *dev, u8 id,
+	const struct phy_ops *ops, void *priv)
+{
+	struct phy **ptr, *phy;
+
+	ptr = devres_alloc(devm_phy_consume, sizeof(*ptr), GFP_KERNEL);
+	if (!ptr)
+		return ERR_PTR(-ENOMEM);
+
+	phy = phy_create(dev, id, ops, priv);
+	if (!IS_ERR(phy)) {
+		*ptr = phy;
+		devres_add(dev, ptr);
+	} else {
+		devres_free(ptr);
+	}
+
+	return phy;
+}
+EXPORT_SYMBOL_GPL(devm_phy_create);
+
+/**
+ * phy_destroy() - destroy the phy
+ * @phy: the phy to be destroyed
+ *
+ * Called to destroy the phy.
+ */
+void phy_destroy(struct phy *phy)
+{
+	pm_runtime_disable(&phy->dev);
+	device_unregister(&phy->dev);
+}
+EXPORT_SYMBOL_GPL(phy_destroy);
+
+/**
+ * devm_phy_destroy() - destroy the PHY
+ * @dev: device that wants to release this phy
+ * @phy: the phy returned by devm_phy_get()
+ *
+ * destroys the devres associated with this phy and invokes phy_destroy
+ * to destroy the phy.
+ */
+void devm_phy_destroy(struct device *dev, struct phy *phy)
+{
+	int r;
+
+	r = devres_destroy(dev, devm_phy_consume, devm_phy_match, phy);
+	dev_WARN_ONCE(dev, r, "couldn't find PHY resource\n");
+}
+EXPORT_SYMBOL_GPL(devm_phy_destroy);
+
+/**
+ * of_phy_provider_register() - create/register phy provider with the framework
+ * @dev: struct device of the phy provider
+ * @owner: the module owner containing of_xlate
+ * @of_xlate: function pointer to obtain phy instance from phy provider
+ *
+ * Creates struct phy_provider from dev and of_xlate function pointer.
+ * This is used in the case of dt boot for finding the phy instance from
+ * phy provider.
+ */
+struct phy_provider *of_phy_provider_register(struct device *dev,
+	struct module *owner, struct phy * (*of_xlate)(struct device *dev,
+	struct of_phandle_args *args))
+{
+	struct phy_provider *phy_provider;
+
+	phy_provider = kzalloc(sizeof(*phy_provider), GFP_KERNEL);
+	if (!phy_provider)
+		return ERR_PTR(-ENOMEM);
+
+	phy_provider->dev = dev;
+	phy_provider->owner = owner;
+	phy_provider->of_xlate = of_xlate;
+
+	mutex_lock(&phy_provider_mutex);
+	list_add_tail(&phy_provider->list, &phy_provider_list);
+	mutex_unlock(&phy_provider_mutex);
+
+	return phy_provider;
+}
+EXPORT_SYMBOL_GPL(of_phy_provider_register);
+
+/**
+ * devm_of_phy_provider_register() - create/register phy provider with the
+ * framework
+ * @dev: struct device of the phy provider
+ * @owner: the module owner containing of_xlate
+ * @of_xlate: function pointer to obtain phy instance from phy provider
+ *
+ * Creates struct phy_provider from dev and of_xlate function pointer.
+ * This is used in the case of dt boot for finding the phy instance from
+ * phy provider. While at that, it also associates the device with the
+ * phy provider using devres. On driver detach, release function is invoked
+ * on the devres data, then, devres data is freed.
+ */
+struct phy_provider *devm_of_phy_provider_register(struct device *dev,
+	struct module *owner, struct phy * (*of_xlate)(struct device *dev,
+	struct of_phandle_args *args))
+{
+	struct phy_provider **ptr, *phy_provider;
+
+	ptr = devres_alloc(devm_phy_provider_release, sizeof(*ptr), GFP_KERNEL);
+	if (!ptr)
+		return ERR_PTR(-ENOMEM);
+
+	phy_provider = of_phy_provider_register(dev, owner, of_xlate);
+	if (!IS_ERR(phy_provider)) {
+		*ptr = phy_provider;
+		devres_add(dev, ptr);
+	} else {
+		devres_free(ptr);
+	}
+
+	return phy_provider;
+}
+EXPORT_SYMBOL_GPL(devm_of_phy_provider_register);
+
+/**
+ * of_phy_provider_unregister() - unregister phy provider from the framework
+ * @phy_provider: phy provider returned by of_phy_provider_register()
+ *
+ * Removes the phy_provider created using of_phy_provider_register().
+ */
+void of_phy_provider_unregister(struct phy_provider *phy_provider)
+{
+	if (IS_ERR(phy_provider))
+		return;
+
+	mutex_lock(&phy_provider_mutex);
+	list_del(&phy_provider->list);
+	kfree(phy_provider);
+	mutex_unlock(&phy_provider_mutex);
+}
+EXPORT_SYMBOL_GPL(of_phy_provider_unregister);
+
+/**
+ * devm_of_phy_provider_unregister() - remove phy provider from the framework
+ * @dev: struct device of the phy provider
+ *
+ * destroys the devres associated with this phy provider and invokes
+ * of_phy_provider_unregister to unregister the phy provider.
+ */
+void devm_of_phy_provider_unregister(struct device *dev,
+	struct phy_provider *phy_provider) {
+	int r;
+
+	r = devres_destroy(dev, devm_phy_provider_release, devm_phy_match,
+		phy_provider);
+	dev_WARN_ONCE(dev, r, "couldn't find PHY provider device resource\n");
+}
+EXPORT_SYMBOL_GPL(devm_of_phy_provider_unregister);
+
+/**
+ * phy_release() - release the phy
+ * @dev: the dev member within phy
+ *
+ * when the last reference to the device is removed; it is called
+ * from the embedded kobject as release method.
+ */
+static void phy_release(struct device *dev)
+{
+	struct phy *phy;
+
+	phy = container_of(dev, struct phy, dev);
+	dev_dbg(dev, "releasing '%s'\n", dev_name(dev));
+	kfree(phy);
+}
+
+static int __init phy_core_init(void)
+{
+	phy_class = class_create(THIS_MODULE, "phy");
+	if (IS_ERR(phy_class)) {
+		pr_err("failed to create phy class --> %ld\n",
+			PTR_ERR(phy_class));
+		return PTR_ERR(phy_class);
+	}
+
+	phy_class->dev_release = phy_release;
+
+	return 0;
+}
+module_init(phy_core_init);
+
+static void __exit phy_core_exit(void)
+{
+	class_destroy(phy_class);
+}
+module_exit(phy_core_exit);
+
+MODULE_DESCRIPTION("Generic PHY Framework");
+MODULE_AUTHOR("Kishon Vijay Abraham I <kishon at ti.com>");
+MODULE_LICENSE("GPL v2");
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
new file mode 100644
index 0000000..e7a570a
--- /dev/null
+++ b/include/linux/phy/phy.h
@@ -0,0 +1,248 @@
+/*
+ * phy.h -- generic phy header file
+ *
+ * Copyright (C) 2013 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 as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * Author: Kishon Vijay Abraham I <kishon at ti.com>
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#ifndef __DRIVERS_PHY_H
+#define __DRIVERS_PHY_H
+
+#include <linux/err.h>
+#include <linux/of.h>
+#include <linux/device.h>
+#include <linux/pm_runtime.h>
+
+struct phy;
+
+/**
+ * struct phy_ops - set of function pointers for performing phy operations
+ * @init: operation to be performed for initializing phy
+ * @exit: operation to be performed while exiting
+ * @power_on: powering on the phy
+ * @power_off: powering off the phy
+ * @owner: the module owner containing the ops
+ */
+struct phy_ops {
+	int	(*init)(struct phy *phy);
+	int	(*exit)(struct phy *phy);
+	int	(*power_on)(struct phy *phy);
+	int	(*power_off)(struct phy *phy);
+	struct module *owner;
+};
+
+/**
+ * struct phy - represent the phy device
+ * @dev: phy device
+ * @id: id of the phy
+ * @ops: function pointers for performing phy operations
+ */
+struct phy {
+	struct device		dev;
+	int			id;
+	const struct phy_ops	*ops;
+};
+
+/**
+ * struct phy_provider - represent the phy provider
+ * @dev: phy provider device
+ * @owner: the module owner having of_xlate
+ * @of_xlate: function pointer to obtain phy instance from phy pointer
+ * @list: to maintain a linked list of PHY provider
+ */
+struct phy_provider {
+	struct device		*dev;
+	struct module		*owner;
+	struct list_head	list;
+	struct phy * (*of_xlate)(struct device *dev,
+		struct of_phandle_args *args);
+};
+
+#if IS_ENABLED(CONFIG_GENERIC_PHY)
+extern struct phy *phy_get(struct device *dev, const char *string);
+extern struct phy *devm_phy_get(struct device *dev, const char *string);
+extern void phy_put(struct phy *phy);
+extern void devm_phy_put(struct device *dev, struct phy *phy);
+extern struct phy *of_phy_simple_xlate(struct device *dev,
+	struct of_phandle_args *args);
+extern struct phy *phy_create(struct device *dev, u8 id,
+	const struct phy_ops *ops, void *priv);
+extern struct phy *devm_phy_create(struct device *dev, u8 id,
+	const struct phy_ops *ops, void *priv);
+extern void phy_destroy(struct phy *phy);
+extern void devm_phy_destroy(struct device *dev, struct phy *phy);
+extern struct phy_provider *of_phy_provider_register(struct device *dev,
+	struct module *owner, struct phy * (*of_xlate)(struct device *dev,
+	struct of_phandle_args *args));
+extern struct phy_provider *devm_of_phy_provider_register(struct device *dev,
+	struct module *owner, struct phy * (*of_xlate)(struct device *dev,
+	struct of_phandle_args *args));
+extern void of_phy_provider_unregister(struct phy_provider *phy_provider);
+extern void devm_of_phy_provider_unregister(struct device *dev,
+	struct phy_provider *phy_provider);
+#else
+static inline struct phy *phy_get(struct device *dev, const char *string)
+{
+	return ERR_PTR(-ENOSYS);
+}
+
+static inline struct phy *devm_phy_get(struct device *dev, const char *string)
+{
+	return ERR_PTR(-ENOSYS);
+}
+
+static inline void phy_put(struct phy *phy)
+{
+}
+
+static inline void devm_phy_put(struct device *dev, struct phy *phy)
+{
+}
+
+static inline struct phy *of_phy_simple_xlate(struct device *dev,
+	struct of_phandle_args *args)
+{
+	return ERR_PTR(-ENOSYS);
+}
+
+static inline struct phy *phy_create(struct device *dev, u8 id,
+	const struct phy_ops *ops, void *priv)
+{
+	return ERR_PTR(-ENOSYS);
+}
+
+static inline struct phy *devm_phy_create(struct device *dev, u8 id,
+	const struct phy_ops *ops, void *priv)
+{
+	return ERR_PTR(-ENOSYS);
+}
+
+static inline void phy_destroy(struct phy *phy)
+{
+}
+
+static inline void devm_phy_destroy(struct device *dev, struct phy *phy)
+{
+}
+
+static inline struct phy_provider *of_phy_provider_register(struct device *dev,
+	struct module *owner, struct phy * (*of_xlate)(struct device *dev,
+	struct of_phandle_args *args))
+{
+	return ERR_PTR(-ENOSYS);
+}
+
+static inline struct phy_provider *devm_of_phy_provider_register(struct device
+	*dev, struct module *owner, struct phy * (*of_xlate)(struct device *dev,
+	struct of_phandle_args *args))
+{
+	return ERR_PTR(-ENOSYS);
+}
+
+static inline void of_phy_provider_unregister(struct phy_provider *phy_provider)
+{
+}
+
+static inline void devm_of_phy_provider_unregister(struct device *dev,
+	struct phy_provider *phy_provider)
+{
+}
+#endif
+
+static inline int phy_init(struct phy *phy)
+{
+	pm_runtime_get_sync(&phy->dev);
+
+	if (phy->ops->init)
+		return phy->ops->init(phy);
+
+	return -EINVAL;
+}
+
+static inline int phy_exit(struct phy *phy)
+{
+	int ret = -EINVAL;
+
+	if (phy->ops->exit)
+		ret = phy->ops->exit(phy);
+
+	pm_runtime_put_sync(&phy->dev);
+
+	return ret;
+}
+
+static inline int phy_power_on(struct phy *phy)
+{
+	if (phy->ops->power_on)
+		return phy->ops->power_on(phy);
+
+	return -EINVAL;
+}
+
+static inline int phy_power_off(struct phy *phy)
+{
+	if (phy->ops->power_off)
+		return phy->ops->power_off(phy);
+
+	return -EINVAL;
+}
+
+static inline int phy_pm_runtime_get(struct phy *phy)
+{
+	if (WARN(IS_ERR(phy), "Invalid PHY reference\n"))
+		return -EINVAL;
+
+	return pm_runtime_get(&phy->dev);
+}
+
+static inline int phy_pm_runtime_get_sync(struct phy *phy)
+{
+	if (WARN(IS_ERR(phy), "Invalid PHY reference\n"))
+		return -EINVAL;
+
+	return pm_runtime_get_sync(&phy->dev);
+}
+
+static inline int phy_pm_runtime_put(struct phy *phy)
+{
+	if (WARN(IS_ERR(phy), "Invalid PHY reference\n"))
+		return -EINVAL;
+
+	return pm_runtime_put(&phy->dev);
+}
+
+static inline int phy_pm_runtime_put_sync(struct phy *phy)
+{
+	if (WARN(IS_ERR(phy), "Invalid PHY reference\n"))
+		return -EINVAL;
+
+	return pm_runtime_put_sync(&phy->dev);
+}
+
+static inline void phy_pm_runtime_allow(struct phy *phy)
+{
+	if (WARN(IS_ERR(phy), "Invalid PHY reference\n"))
+		return;
+
+	pm_runtime_allow(&phy->dev);
+}
+
+static inline void phy_pm_runtime_forbid(struct phy *phy)
+{
+	if (WARN(IS_ERR(phy), "Invalid PHY reference\n"))
+		return;
+
+	pm_runtime_forbid(&phy->dev);
+}
+#endif /* __DRIVERS_PHY_H */
-- 
1.7.10.4



From inki.dae at samsung.com  Mon Apr 29 06:06:23 2013
From: inki.dae at samsung.com (Inki Dae)
Date: Mon, 29 Apr 2013 19:06:23 +0900
Subject: [PATCH] module: fix mutiple defined issue
In-Reply-To: <20130429095138.GJ14496@n2100.arm.linux.org.uk>
References: <1367213521-26795-1-git-send-email-inki.dae@samsung.com>
 <20130429095138.GJ14496@n2100.arm.linux.org.uk>
Message-ID: <019801ce44c1$34326d60$9c974820$%dae@samsung.com>



> -----Original Message-----
> From: linux-kernel-owner at vger.kernel.org [mailto:linux-kernel-
> owner at vger.kernel.org] On Behalf Of Russell King - ARM Linux
> Sent: Monday, April 29, 2013 6:52 PM
> To: Inki Dae
> Cc: gregkh at linuxfoundation.org; linux-kernel at vger.kernel.org; dri-
> devel at lists.freedesktop.org; linux-arm-kernel at lists.infradead.org
> Subject: Re: [PATCH] module: fix mutiple defined issue
> 
> On Mon, Apr 29, 2013 at 02:32:01PM +0900, Inki Dae wrote:
> > This patch fixes mutiple defined issue to MODULE_DEVICE_TABLE
> >
> > The issue could be induced when some framework which includes two
> > more sub drivers, is built as one moudle because those sub drivers
> > could have their own MODULE_DEVICE_TABLE.
> >
> > And 'struct of_device_id' isn't needed to be determined by type
> > argument because the definition of 'of_device_id' should be fixed.
> > So this patch makes 'of_devce_id' definition to be fixed and
> > only its instance name to be defined by type.
> >
> > Signed-off-by: Inki Dae <inki.dae at samsung.com>
> > ---
> >  include/linux/module.h |    2 +-
> >  1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/include/linux/module.h b/include/linux/module.h
> > index 46f1ea0..ac5d79f 100644
> > --- a/include/linux/module.h
> > +++ b/include/linux/module.h
> > @@ -84,7 +84,7 @@ void trim_init_extable(struct module *m);
> >
> >  #ifdef MODULE
> >  #define MODULE_GENERIC_TABLE(gtype,name)			\
> > -extern const struct gtype##_id __mod_##gtype##_table		\
> > +extern const struct of_device_id __mod_##gtype##_table		\
> >    __attribute__ ((unused, alias(__stringify(name))))
> >
> >  #else  /* !MODULE */
> 
> This patch (a) looks wrong (why would a generic device table be limited
> to of_device_id when it could be ISAPNP or something else?) and (b) how
> does changing the type fix the "multiple defined issue" ?  (c) include
> the errors that you're fixing in the commit log.

There was my misunderstanding. So please ignore my patch. Some headers in
include/linux/ have some kind of device_id structure such as of_device_id,
platform_device_id, i2c_device_id, and so on. And these structures should be
used properly. This was my missing point.

Thanks,
Inki Dae


> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/



From stefano.stabellini at eu.citrix.com  Mon Apr 29 06:30:03 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Mon, 29 Apr 2013 11:30:03 +0100
Subject: [PATCH v9 1/2] arm: introduce psci_smp_ops
In-Reply-To: <20130429085916.GB8805@mudshark.cambridge.arm.com>
References: <alpine.DEB.2.02.1304281544240.5398@kaball.uk.xensource.com>
 <1367160650-4888-1-git-send-email-stefano.stabellini@eu.citrix.com>
 <20130429085916.GB8805@mudshark.cambridge.arm.com>
Message-ID: <alpine.DEB.2.02.1304291126210.5398@kaball.uk.xensource.com>

Russell,
are you OK with this series now?

Olof, Arnd,
when you merge this series don't forget to include this fix from Stephen
Rothwell:

http://marc.info/?l=linux-arm-kernel&m=136722292031420&w=2


On Mon, 29 Apr 2013, Will Deacon wrote:
> On Sun, Apr 28, 2013 at 03:50:49PM +0100, Stefano Stabellini wrote:
> > Rename virt_smp_ops to psci_smp_ops and move them to arch/arm/kernel/psci_smp.c.
> > Remove mach-virt/platsmp.c, now unused.
> > Compile psci_smp if CONFIG_ARM_PSCI and CONFIG_SMP.
> > 
> > Add a cpu_die smp_op based on psci_ops.cpu_off.
> > 
> > Initialize PSCI before setting smp_ops in setup_arch.
> > 
> > If PSCI is available on the platform, prefer psci_smp_ops over the
> > platform smp_ops.
> > 
> > Changes in v9:
> > - move comment about PSCI interface from psci.h to psci_smp.c.
> > 
> > Changes in v8:
> > - merge "prefer psci_smp_ops over mdesc->smp" into this patch.
> > 
> > Changes in v6:
> > - fixed return values for psci_smp_available and psci_init ifndef
> > CONFIG_ARM_PSCI.
> > 
> > Changes in v5:
> > - document psci_operations;
> > - psci_init returns NULL.
> > 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
> > CC: Nicolas Pitre <nico at linaro.org>
> > CC: Rob Herring <rob.herring at calxeda.com>
> > CC: Will Deacon <will.deacon at arm.com>
> > CC: arnd at arndb.de
> > CC: marc.zyngier at arm.com
> > CC: linux at arm.linux.org.uk
> 
> 
> Acked-by: Will Deacon <will.deacon at arm.com>


From inderpal.singh at linaro.org  Mon Apr 29 07:31:47 2013
From: inderpal.singh at linaro.org (Inderpal Singh)
Date: Mon, 29 Apr 2013 17:01:47 +0530
Subject: [PATCH] ARM: EXYNOS5: Fix kernel dump in AFTR idle mode
Message-ID: <1367235107-31328-1-git-send-email-inderpal.singh@linaro.org>

The kernel crashes while resuming from AFTR idle mode. It happens
because L2 cache was not going into retention state.

This patch configures the USE_RETENTION bit of ARM_L2_OPTION register
so that it does not depend on MANUAL_L2RSTDISABLE_CONTROL of
ARM_COMMON_OPTION register for L2RSTDISABLE signal.

Signed-off-by: Inderpal Singh <inderpal.singh at linaro.org>
---

Tested on arndale board on arm-soc next/soc branch.

 arch/arm/mach-exynos/include/mach/regs-pmu.h |    1 +
 arch/arm/mach-exynos/pmu.c                   |    5 ++---
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-exynos/include/mach/regs-pmu.h b/arch/arm/mach-exynos/include/mach/regs-pmu.h
index 3f30aa1..57344b7 100644
--- a/arch/arm/mach-exynos/include/mach/regs-pmu.h
+++ b/arch/arm/mach-exynos/include/mach/regs-pmu.h
@@ -344,6 +344,7 @@
 #define EXYNOS5_FSYS_ARM_OPTION					S5P_PMUREG(0x2208)
 #define EXYNOS5_ISP_ARM_OPTION					S5P_PMUREG(0x2288)
 #define EXYNOS5_ARM_COMMON_OPTION				S5P_PMUREG(0x2408)
+#define EXYNOS5_ARM_L2_OPTION					S5P_PMUREG(0x2608)
 #define EXYNOS5_TOP_PWR_OPTION					S5P_PMUREG(0x2C48)
 #define EXYNOS5_TOP_PWR_SYSMEM_OPTION				S5P_PMUREG(0x2CC8)
 #define EXYNOS5_JPEG_MEM_OPTION					S5P_PMUREG(0x2F48)
diff --git a/arch/arm/mach-exynos/pmu.c b/arch/arm/mach-exynos/pmu.c
index daebc1a..97d6885 100644
--- a/arch/arm/mach-exynos/pmu.c
+++ b/arch/arm/mach-exynos/pmu.c
@@ -228,6 +228,7 @@ static struct exynos_pmu_conf exynos5250_pmu_config[] = {
 	{ EXYNOS5_DIS_IRQ_ISP_ARM_CENTRAL_SYS_PWR_REG,	{ 0x0, 0x0, 0x0} },
 	{ EXYNOS5_ARM_COMMON_SYS_PWR_REG,		{ 0x0, 0x0, 0x2} },
 	{ EXYNOS5_ARM_L2_SYS_PWR_REG,			{ 0x3, 0x3, 0x3} },
+	{ EXYNOS5_ARM_L2_OPTION,			{ 0x10, 0x10, 0x0 } },
 	{ EXYNOS5_CMU_ACLKSTOP_SYS_PWR_REG,		{ 0x1, 0x0, 0x1} },
 	{ EXYNOS5_CMU_SCLKSTOP_SYS_PWR_REG,		{ 0x1, 0x0, 0x1} },
 	{ EXYNOS5_CMU_RESET_SYS_PWR_REG,		{ 0x1, 0x1, 0x0} },
@@ -353,11 +354,9 @@ static void exynos5_init_pmu(void)
 
 	/*
 	 * SKIP_DEACTIVATE_ACEACP_IN_PWDN_BITFIELD Enable
-	 * MANUAL_L2RSTDISABLE_CONTROL_BITFIELD Enable
 	 */
 	tmp = __raw_readl(EXYNOS5_ARM_COMMON_OPTION);
-	tmp |= (EXYNOS5_MANUAL_L2RSTDISABLE_CONTROL |
-		EXYNOS5_SKIP_DEACTIVATE_ACEACP_IN_PWDN);
+	tmp |= EXYNOS5_SKIP_DEACTIVATE_ACEACP_IN_PWDN;
 	__raw_writel(tmp, EXYNOS5_ARM_COMMON_OPTION);
 
 	/*
-- 
1.7.9.5



From chander.kashyap at linaro.org  Mon Apr 29 07:54:34 2013
From: chander.kashyap at linaro.org (Chander Kashyap)
Date: Mon, 29 Apr 2013 17:24:34 +0530
Subject: [PATCH] ARM: EXYNOS5: Fix kernel dump in AFTR idle mode
In-Reply-To: <1367235107-31328-1-git-send-email-inderpal.singh@linaro.org>
References: <1367235107-31328-1-git-send-email-inderpal.singh@linaro.org>
Message-ID: <CANuQgHEkbs1m+Q1XEy0_rZyd+qeTyGcXdq3sw0GBOLBDRaNKew@mail.gmail.com>

On 29 April 2013 17:01, Inderpal Singh <inderpal.singh at linaro.org> wrote:
>
> The kernel crashes while resuming from AFTR idle mode. It happens
> because L2 cache was not going into retention state.
>
> This patch configures the USE_RETENTION bit of ARM_L2_OPTION register
> so that it does not depend on MANUAL_L2RSTDISABLE_CONTROL of
> ARM_COMMON_OPTION register for L2RSTDISABLE signal.
>
> Signed-off-by: Inderpal Singh <inderpal.singh at linaro.org>
> ---
>
> Tested on arndale board on arm-soc next/soc branch.
>
>  arch/arm/mach-exynos/include/mach/regs-pmu.h |    1 +
>  arch/arm/mach-exynos/pmu.c                   |    5 ++---
>  2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-exynos/include/mach/regs-pmu.h b/arch/arm/mach-exynos/include/mach/regs-pmu.h
> index 3f30aa1..57344b7 100644
> --- a/arch/arm/mach-exynos/include/mach/regs-pmu.h
> +++ b/arch/arm/mach-exynos/include/mach/regs-pmu.h
> @@ -344,6 +344,7 @@
>  #define EXYNOS5_FSYS_ARM_OPTION                                        S5P_PMUREG(0x2208)
>  #define EXYNOS5_ISP_ARM_OPTION                                 S5P_PMUREG(0x2288)
>  #define EXYNOS5_ARM_COMMON_OPTION                              S5P_PMUREG(0x2408)
> +#define EXYNOS5_ARM_L2_OPTION                                  S5P_PMUREG(0x2608)
>  #define EXYNOS5_TOP_PWR_OPTION                                 S5P_PMUREG(0x2C48)
>  #define EXYNOS5_TOP_PWR_SYSMEM_OPTION                          S5P_PMUREG(0x2CC8)
>  #define EXYNOS5_JPEG_MEM_OPTION                                        S5P_PMUREG(0x2F48)
> diff --git a/arch/arm/mach-exynos/pmu.c b/arch/arm/mach-exynos/pmu.c
> index daebc1a..97d6885 100644
> --- a/arch/arm/mach-exynos/pmu.c
> +++ b/arch/arm/mach-exynos/pmu.c
> @@ -228,6 +228,7 @@ static struct exynos_pmu_conf exynos5250_pmu_config[] = {
>         { EXYNOS5_DIS_IRQ_ISP_ARM_CENTRAL_SYS_PWR_REG,  { 0x0, 0x0, 0x0} },
>         { EXYNOS5_ARM_COMMON_SYS_PWR_REG,               { 0x0, 0x0, 0x2} },
>         { EXYNOS5_ARM_L2_SYS_PWR_REG,                   { 0x3, 0x3, 0x3} },
> +       { EXYNOS5_ARM_L2_OPTION,                        { 0x10, 0x10, 0x0 } },
>         { EXYNOS5_CMU_ACLKSTOP_SYS_PWR_REG,             { 0x1, 0x0, 0x1} },
>         { EXYNOS5_CMU_SCLKSTOP_SYS_PWR_REG,             { 0x1, 0x0, 0x1} },
>         { EXYNOS5_CMU_RESET_SYS_PWR_REG,                { 0x1, 0x1, 0x0} },
> @@ -353,11 +354,9 @@ static void exynos5_init_pmu(void)
>
>         /*
>          * SKIP_DEACTIVATE_ACEACP_IN_PWDN_BITFIELD Enable
> -        * MANUAL_L2RSTDISABLE_CONTROL_BITFIELD Enable
>          */
>         tmp = __raw_readl(EXYNOS5_ARM_COMMON_OPTION);
> -       tmp |= (EXYNOS5_MANUAL_L2RSTDISABLE_CONTROL |
> -               EXYNOS5_SKIP_DEACTIVATE_ACEACP_IN_PWDN);
> +       tmp |= EXYNOS5_SKIP_DEACTIVATE_ACEACP_IN_PWDN;
>         __raw_writel(tmp, EXYNOS5_ARM_COMMON_OPTION);
>
>         /*
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

working fine.
Tested-by: Chander Kashyap <chander.kashyap at linaro.org>



--
with warm regards,
Chander Kashyap


From linus.walleij at linaro.org  Mon Apr 29 08:14:55 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Mon, 29 Apr 2013 14:14:55 +0200
Subject: [PATCH V2 03/12] PM / Domains: Add on-off notifiers
In-Reply-To: <51767DE2.7050203@stericsson.com>
References: <1364487098-10319-1-git-send-email-rickard.andersson@stericsson.com>
 <1364487098-10319-4-git-send-email-rickard.andersson@stericsson.com>
 <3261022.s2M99fPNjC@vostro.rjw.lan>
 <51767DE2.7050203@stericsson.com>
Message-ID: <CACRpkdb+JrnrQgzZ5xdtFDubexNRm2WsrLXv+5zfjN1wdowaNg@mail.gmail.com>

On Tue, Apr 23, 2013 at 2:26 PM, Rickard Andersson
<rickard.andersson at stericsson.com> wrote:
> On 03/31/2013 12:17 AM, Rafael J. Wysocki wrote:
>> On Thursday, March 28, 2013 05:11:29 PM Rickard Andersson wrote:

>>> I believe notifiers are the best solution to the problem of
>>> restoring context early when waking up after sleep.
>>
>> I don't.
>
> Some motivation would be good.
(...)
>> Well, quite frankly, it is hard to say what problem this is supposed to
>> address from your description.  Care to give some more details?
>
> The problem is that some hardware blocks needs to be restored as early as
> possible after leaving the U8500 CPU coupled sleep state ApSleep (APE power
> domain being off).

(APE = Application Processor Environment, on embedded)

I just have this vague feeling that this is one of those embedded SoC
vs desktop things where worlds collide.

Isn't it so that on common x86 (desktop, server, laptop) the context of
the system is saved by some BIOS/ACPI call, and then the ROM
takes you back up with all devices put back into context?

On embedded SoC's we don't have this, all states in the hardware
has to be saved and restored with kernel code.

Then there is a question about whether this shall be done centrally
(there is one piece of code that knows all volatile registers of all
hardware blocks in the system) which is close to what the desktop
BIOS may do, or whether you want to do this in a distributed manner,
so that each driver saves and restores the context of it's particular
hardware.

The suggested mechanism is useful for the latter design pattern,
where drivers know for themselves how to save and restore their
contexts.

Yours,
Linus Walleij


From linus.walleij at linaro.org  Mon Apr 29 08:21:15 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Mon, 29 Apr 2013 14:21:15 +0200
Subject: Adding a void * to pinctrl_pin_desc
In-Reply-To: <051069C10411E24D9749790C498526FA1BCF54B1@SJEXCHMB12.corp.ad.broadcom.com>
References: <051069C10411E24D9749790C498526FA1BCF4FC6@SJEXCHMB12.corp.ad.broadcom.com>
 <CACRpkdYxJOWYMfwmrEGhqgjushVjWyc=FyKMaZNLnn=0jrTs9A@mail.gmail.com>
 <051069C10411E24D9749790C498526FA1BCF54B1@SJEXCHMB12.corp.ad.broadcom.com>
Message-ID: <CACRpkdY2vWvvE_NToQ5rkxGC32hCJgMjNpkF+KEGJ+-o4My4-Q@mail.gmail.com>

On Sat, Apr 27, 2013 at 2:54 AM, Sherman Yin <syin at broadcom.com> wrote:
> [Me]
>> Then use container_of() to dereference a struct foo_pin_desc pointer from
>> the
>> pointer at &foodesc->desc;
>
> Hmm, while it would be easy to create a macro to fill the static foo_pin_desc array
> in the driver, this array would not be suitable for use with pinctrl_register().

Now I start to change opinion. You're right about this.

> I would have to, in the probe function, loop through the foo_pin_desc array and
> create another pinctrl_pin_desc array to use for pinctrl_desc.pins.

Yeah that sucks.

> I think I'll just use a separate struct in the driver to keep track of other pin-specific data.

No I think I have changed opinion. Can you send a patch adding a void * to
struct pinctrl_pin_desc  as patch [1/n] when you send your driver, and
I think I'll be happy with it.

Yours,
Linus Walleij


From agraf at suse.de  Mon Apr 29 08:22:46 2013
From: agraf at suse.de (Alexander Graf)
Date: Mon, 29 Apr 2013 14:22:46 +0200
Subject: [PATCH 0/2] Early printk support for virtio console devices.
In-Reply-To: <87obcyc9sh.fsf@rustcorp.com.au>
References: <1366974299-17877-1-git-send-email-pranavkumar@linaro.org>
 <BA2076A6-0688-4E5C-85F9-A9CA8FD75782@suse.de>
 <87obcyc9sh.fsf@rustcorp.com.au>
Message-ID: <336C59AA-D5D7-472E-A8DA-EEB413DD6C68@suse.de>



Am 29.04.2013 um 05:09 schrieb Rusty Russell <rusty at rustcorp.com.au>:

> Alexander Graf <agraf at suse.de> writes:
>> On 26.04.2013, at 13:04, Pranavkumar Sawargaonkar wrote:
>> 
>>> This patch-set implements early printk support for virtio console devices without using any hypercalls.
>>> 
>>> The current virtio early printk code in kernel expects that hypervisor will provide some mechanism generally a hypercall to support early printk. This patch-set does not break existing hypercall based early print support.
>>> 
>>> This implementation adds:
>>> 1. Early writeonly register named early_wr in virtio console's config space.
>>> 2. Host feature flags namely VIRTIO_CONSOLE_F_EARLY_WRITE for telling guest about early-write capability in console device.
>>> 
>>> Early write mechanism:
>>> 1. When a guest wants to out some character, it has to simply write the character to early_wr register in config space of virtio console device.
>> 
>> I won't nack this patch set, but I'll definitely express that I'm not happy with it.
>> 
>> MMIO registers are handled by a different layer than the virtio console itself. After the virtio refactoring in QEMU, they will be completely separate drivers. So we'll be in a similar mess with early printk as we are on the s390-virtio machine, where early printk is done through hypercalls and thus we can't directly link it to the console output.
>> 
>> I still don't see what the issue is with just implementing a small irq-less virtio driver for early printk.
> 
> Well, this shouldn't be mmio-specific, but I kind of get what you mean.
> 
> I consider this misnamed: it's an emergency write facility.  Linux may
> use it for an early console,

If Linux uses it for early console, you won't see any messages from before the virtio-console driver is initialized, because Linux thinks that it's all been printed out.

> but it's also useful for bringup and to
> give a method of emitting errors like "the console ring is corrupt".
> 
> A valid implementation may well be to only offer it with some magic
> qemu developer-only commandline and dump it to stdout.

Why implement it differently from other machines? There are facilities to call into firmware, so you could use that. There's the special Foundation model call that you could implement and reuse for this.

I don't see why anything like this has to live in virtio-mmio. Oh, and it should default to off.

Alex

> 
> So I think it has use, but less so if QEMU isn't ever going to implement
> it.
> 
> Cheers,
> Rusty.
> 


From mark.langsdorf at calxeda.com  Mon Apr 29 08:46:27 2013
From: mark.langsdorf at calxeda.com (Mark Langsdorf)
Date: Mon, 29 Apr 2013 07:46:27 -0500
Subject: [PATCH 1/3] mailbox: rename pl320-ipc specific mailbox.h
In-Reply-To: <1367085953-28270-1-git-send-email-jaswinder.singh@linaro.org>
References: <CAJe_ZhdH+SCs5crguXrm6y-6bu+eGnTqeJS6cOS5H5Yz=m15Cw@mail.gmail.com>
 <1367085953-28270-1-git-send-email-jaswinder.singh@linaro.org>
Message-ID: <517E6BA3.30008@calxeda.com>

On 04/27/2013 01:05 PM, jaswinder.singh at linaro.org wrote:
> From: Suman Anna <s-anna at ti.com>
> 
> The patch 30058677 "ARM / highbank: add support for pl320 IPC"
> added a pl320 IPC specific header file as a generic mailbox.h.
> This file has been renamed appropriately to allow the
> introduction of the generic mailbox API framework.
> 
> Signed-off-by: Suman Anna <s-anna at ti.com>
> Cc: Mark Langsdorf <mark.langsdorf at calxeda.com>
> Cc: Rafael J. Wysocki <rafael.j.wysocki at intel.com>
> ---
>  drivers/cpufreq/highbank-cpufreq.c       |    2 +-
>  drivers/mailbox/pl320-ipc.c              |    2 +-
>  include/linux/{mailbox.h => pl320-ipc.h} |    0
>  3 files changed, 2 insertions(+), 2 deletions(-)
>  rename include/linux/{mailbox.h => pl320-ipc.h} (100%)
> 
> diff --git a/drivers/cpufreq/highbank-cpufreq.c b/drivers/cpufreq/highbank-cpufreq.c
> index b61b5a3..3118b87 100644
> --- a/drivers/cpufreq/highbank-cpufreq.c
> +++ b/drivers/cpufreq/highbank-cpufreq.c
> @@ -19,7 +19,7 @@
>  #include <linux/cpu.h>
>  #include <linux/err.h>
>  #include <linux/of.h>
> -#include <linux/mailbox.h>
> +#include <linux/pl320-ipc.h>
>  #include <linux/platform_device.h>
>  
>  #define HB_CPUFREQ_CHANGE_NOTE	0x80000001
> diff --git a/drivers/mailbox/pl320-ipc.c b/drivers/mailbox/pl320-ipc.c
> index d873cba..f3755e0 100644
> --- a/drivers/mailbox/pl320-ipc.c
> +++ b/drivers/mailbox/pl320-ipc.c
> @@ -26,7 +26,7 @@
>  #include <linux/device.h>
>  #include <linux/amba/bus.h>
>  
> -#include <linux/mailbox.h>
> +#include <linux/pl320-ipc.h>
>  
>  #define IPCMxSOURCE(m)		((m) * 0x40)
>  #define IPCMxDSET(m)		(((m) * 0x40) + 0x004)
> diff --git a/include/linux/mailbox.h b/include/linux/pl320-ipc.h
> similarity index 100%
> rename from include/linux/mailbox.h
> rename to include/linux/pl320-ipc.h
> 

Acked-by: Mark Langsdorf <mark.langsdorf at calxeda.com>


From pranavkumar at linaro.org  Mon Apr 29 08:48:11 2013
From: pranavkumar at linaro.org (Pranavkumar Sawargaonkar)
Date: Mon, 29 Apr 2013 18:18:11 +0530
Subject: [PATCH 0/2] Early printk support for virtio console devices.
In-Reply-To: <336C59AA-D5D7-472E-A8DA-EEB413DD6C68@suse.de>
References: <1366974299-17877-1-git-send-email-pranavkumar@linaro.org>
 <BA2076A6-0688-4E5C-85F9-A9CA8FD75782@suse.de>
 <87obcyc9sh.fsf@rustcorp.com.au>
 <336C59AA-D5D7-472E-A8DA-EEB413DD6C68@suse.de>
Message-ID: <CAAHg+Hj0tySbzUGnoFE9ybVYP291B-i8-Ck1EkwD57t8yG5wwg@mail.gmail.com>

On 29 April 2013 17:52, Alexander Graf <agraf at suse.de> wrote:
>
>
> Am 29.04.2013 um 05:09 schrieb Rusty Russell <rusty at rustcorp.com.au>:
>
>> Alexander Graf <agraf at suse.de> writes:
>>> On 26.04.2013, at 13:04, Pranavkumar Sawargaonkar wrote:
>>>
>>>> This patch-set implements early printk support for virtio console devices without using any hypercalls.
>>>>
>>>> The current virtio early printk code in kernel expects that hypervisor will provide some mechanism generally a hypercall to support early printk. This patch-set does not break existing hypercall based early print support.
>>>>
>>>> This implementation adds:
>>>> 1. Early writeonly register named early_wr in virtio console's config space.
>>>> 2. Host feature flags namely VIRTIO_CONSOLE_F_EARLY_WRITE for telling guest about early-write capability in console device.
>>>>
>>>> Early write mechanism:
>>>> 1. When a guest wants to out some character, it has to simply write the character to early_wr register in config space of virtio console device.
>>>
>>> I won't nack this patch set, but I'll definitely express that I'm not happy with it.
>>>
>>> MMIO registers are handled by a different layer than the virtio console itself. After the virtio refactoring in QEMU, they will be completely separate drivers. So we'll be in a similar mess with early printk as we are on the s390-virtio machine, where early printk is done through hypercalls and thus we can't directly link it to the console output.
>>>
>>> I still don't see what the issue is with just implementing a small irq-less virtio driver for early printk.
>>
>> Well, this shouldn't be mmio-specific, but I kind of get what you mean.
>>
>> I consider this misnamed: it's an emergency write facility.  Linux may
>> use it for an early console,
>
> If Linux uses it for early console, you won't see any messages from before the virtio-console driver is initialized, because Linux thinks that it's all been printed out.

So far i have tried this on foundation model for armv8 and i never saw
any missed out prints.

>
>> but it's also useful for bringup and to
>> give a method of emitting errors like "the console ring is corrupt".
>>
>> A valid implementation may well be to only offer it with some magic
>> qemu developer-only commandline and dump it to stdout.
>
> Why implement it differently from other machines? There are facilities to call into firmware, so you could use that. There's the special Foundation model call that you could implement and reuse for this.
>
> I don't see why anything like this has to live in virtio-mmio. Oh, and it should default to off.

All the boards may not have firmware to do this. Foundation model call
is also not useful on real hardware for armv8.  This is very helpful
in debugging a guest on real hardware when guest crashes in early
stages before virtio drivers come in to the picture.
This is not a virtio-mmio change it is just an addition of device
specific register in virtio console.
>
> Alex
>
>>
>> So I think it has use, but less so if QEMU isn't ever going to implement
>> it.
>>
>> Cheers,
>> Rusty.
>>
Thanks,
Pranav


From peter.maydell at linaro.org  Mon Apr 29 08:50:07 2013
From: peter.maydell at linaro.org (Peter Maydell)
Date: Mon, 29 Apr 2013 13:50:07 +0100
Subject: [PATCH 0/2] Early printk support for virtio console devices.
In-Reply-To: <336C59AA-D5D7-472E-A8DA-EEB413DD6C68@suse.de>
References: <1366974299-17877-1-git-send-email-pranavkumar@linaro.org>
 <BA2076A6-0688-4E5C-85F9-A9CA8FD75782@suse.de>
 <87obcyc9sh.fsf@rustcorp.com.au>
 <336C59AA-D5D7-472E-A8DA-EEB413DD6C68@suse.de>
Message-ID: <CAFEAcA-qfbMWD4fxLSN5uiBzO4fjqpwnx5pZd2QY=6Q=+dMNPw@mail.gmail.com>

On 29 April 2013 13:22, Alexander Graf <agraf at suse.de> wrote:
> Oh, and it should default to off.

That would be a pretty unhelpful default. We should default
things so that console output from the kernel is available
as early as reasonably possible by default IMHO -- this
reduces the number of "nothing happens" user complaints
where you then have to explain how to enable early printk
so you can get some actual information about what happened.

-- PMM


From agraf at suse.de  Mon Apr 29 08:53:32 2013
From: agraf at suse.de (Alexander Graf)
Date: Mon, 29 Apr 2013 14:53:32 +0200
Subject: [PATCH 0/2] Early printk support for virtio console devices.
In-Reply-To: <CAAHg+Hj0tySbzUGnoFE9ybVYP291B-i8-Ck1EkwD57t8yG5wwg@mail.gmail.com>
References: <1366974299-17877-1-git-send-email-pranavkumar@linaro.org>
 <BA2076A6-0688-4E5C-85F9-A9CA8FD75782@suse.de>
 <87obcyc9sh.fsf@rustcorp.com.au>
 <336C59AA-D5D7-472E-A8DA-EEB413DD6C68@suse.de>
 <CAAHg+Hj0tySbzUGnoFE9ybVYP291B-i8-Ck1EkwD57t8yG5wwg@mail.gmail.com>
Message-ID: <C52CCDD4-D8FB-4AD6-B83D-3B5251A7A0F5@suse.de>


On 29.04.2013, at 14:48, Pranavkumar Sawargaonkar wrote:

> On 29 April 2013 17:52, Alexander Graf <agraf at suse.de> wrote:
>> 
>> 
>> Am 29.04.2013 um 05:09 schrieb Rusty Russell <rusty at rustcorp.com.au>:
>> 
>>> Alexander Graf <agraf at suse.de> writes:
>>>> On 26.04.2013, at 13:04, Pranavkumar Sawargaonkar wrote:
>>>> 
>>>>> This patch-set implements early printk support for virtio console devices without using any hypercalls.
>>>>> 
>>>>> The current virtio early printk code in kernel expects that hypervisor will provide some mechanism generally a hypercall to support early printk. This patch-set does not break existing hypercall based early print support.
>>>>> 
>>>>> This implementation adds:
>>>>> 1. Early writeonly register named early_wr in virtio console's config space.
>>>>> 2. Host feature flags namely VIRTIO_CONSOLE_F_EARLY_WRITE for telling guest about early-write capability in console device.
>>>>> 
>>>>> Early write mechanism:
>>>>> 1. When a guest wants to out some character, it has to simply write the character to early_wr register in config space of virtio console device.
>>>> 
>>>> I won't nack this patch set, but I'll definitely express that I'm not happy with it.
>>>> 
>>>> MMIO registers are handled by a different layer than the virtio console itself. After the virtio refactoring in QEMU, they will be completely separate drivers. So we'll be in a similar mess with early printk as we are on the s390-virtio machine, where early printk is done through hypercalls and thus we can't directly link it to the console output.
>>>> 
>>>> I still don't see what the issue is with just implementing a small irq-less virtio driver for early printk.
>>> 
>>> Well, this shouldn't be mmio-specific, but I kind of get what you mean.
>>> 
>>> I consider this misnamed: it's an emergency write facility.  Linux may
>>> use it for an early console,
>> 
>> If Linux uses it for early console, you won't see any messages from before the virtio-console driver is initialized, because Linux thinks that it's all been printed out.
> 
> So far i have tried this on foundation model for armv8 and i never saw
> any missed out prints.

It's what I got back on s390. If you run upstream QEMU, you'll simply lose half of your log messages. Because in upstream QEMU, the side channel used for early printk got nack'ed.

> 
>> 
>>> but it's also useful for bringup and to
>>> give a method of emitting errors like "the console ring is corrupt".
>>> 
>>> A valid implementation may well be to only offer it with some magic
>>> qemu developer-only commandline and dump it to stdout.
>> 
>> Why implement it differently from other machines? There are facilities to call into firmware, so you could use that. There's the special Foundation model call that you could implement and reuse for this.
>> 
>> I don't see why anything like this has to live in virtio-mmio. Oh, and it should default to off.
> 
> All the boards may not have firmware to do this. Foundation model call
> is also not useful on real hardware for armv8.  This is very helpful
> in debugging a guest on real hardware when guest crashes in early

Are you seriously considering to use virtio-console on real hardware?

> stages before virtio drivers come in to the picture.
> This is not a virtio-mmio change it is just an addition of device
> specific register in virtio console.

There are not device specific registers in virtio-console. Virtio-console lives behind a virtio bus which doesn't know what these registers are. Even if you shove it into config space, it'd be broken because config access happens without intercepts on some platforms.


Alex



From agraf at suse.de  Mon Apr 29 08:53:58 2013
From: agraf at suse.de (Alexander Graf)
Date: Mon, 29 Apr 2013 14:53:58 +0200
Subject: [PATCH 0/2] Early printk support for virtio console devices.
In-Reply-To: <CAFEAcA-qfbMWD4fxLSN5uiBzO4fjqpwnx5pZd2QY=6Q=+dMNPw@mail.gmail.com>
References: <1366974299-17877-1-git-send-email-pranavkumar@linaro.org>
 <BA2076A6-0688-4E5C-85F9-A9CA8FD75782@suse.de>
 <87obcyc9sh.fsf@rustcorp.com.au>
 <336C59AA-D5D7-472E-A8DA-EEB413DD6C68@suse.de>
 <CAFEAcA-qfbMWD4fxLSN5uiBzO4fjqpwnx5pZd2QY=6Q=+dMNPw@mail.gmail.com>
Message-ID: <9DCAE29E-A113-4E74-A663-1AB224AD97E0@suse.de>


On 29.04.2013, at 14:50, Peter Maydell wrote:

> On 29 April 2013 13:22, Alexander Graf <agraf at suse.de> wrote:
>> Oh, and it should default to off.
> 
> That would be a pretty unhelpful default. We should default
> things so that console output from the kernel is available
> as early as reasonably possible by default IMHO -- this
> reduces the number of "nothing happens" user complaints
> where you then have to explain how to enable early printk
> so you can get some actual information about what happened.

Users complaining that they only see half of their kernel log are even worse IMHO :)


Alex



From arnd at arndb.de  Mon Apr 29 08:58:16 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 29 Apr 2013 14:58:16 +0200
Subject: [PATCH 03/21] ARM: shmobile: don't call irqchip_init
 unconditionallyA
In-Reply-To: <CABYn4sxjpp3yPkjDM9XhX6fyT-g_OoCjcnD1u=5oyb+Y6y=Nmw@mail.gmail.com>
References: <1366910944-3033663-1-git-send-email-arnd@arndb.de>
 <20130426004835.GA20070@verge.net.au>
 <CABYn4sxjpp3yPkjDM9XhX6fyT-g_OoCjcnD1u=5oyb+Y6y=Nmw@mail.gmail.com>
Message-ID: <201304291458.16634.arnd@arndb.de>

On Friday 26 April 2013, Bastian Hecht wrote:
> > This one seems broken as the armadillo800eva board currently uses
> > it to initialise GIC even if CONFIG_ATAGS is not defined.
> >
> > I did test the above change on the armadillo800eva board
> > with the above change and CONFIG_ATAGS disabled, the result was
> > a boot failure. With the change reverted booting seems fine.
> 
> CONFIG_ATAGS and CONFIG_ARM_APPENDED_DTB are two ways to pass the
> device tree information, right?

No, the two are methods alternative methods for booting from a legacy
boot loader. CONFIG_ATAGS is the old boot method without a DT, using
a board file and a MACHINE_START() macro. ARM_APPENDED_DTB means you
have a DT linked into the kernel but pass ATAGS to the kernel which
uses the passed data to modify the DT.

> So we run into trouble when we use the later but disable the first.
> Is there a reason why you wanted to avoid using two times just "if
> (!IS_ENABLED(CONFIG_OF))", Arnd?

I incorrectly assumed that the second one was only used without DT,
since it uses hardcoded MMIO locations rather than using of_iomap().

	Arnd


From linus.walleij at linaro.org  Mon Apr 29 09:13:59 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Mon, 29 Apr 2013 15:13:59 +0200
Subject: [PATCH] ARM: Adds pin config API to set all configs in one
 function
In-Reply-To: <051069C10411E24D9749790C498526FA1BCF5427@SJEXCHMB12.corp.ad.broadcom.com>
References: <1366841010-2823-1-git-send-email-syin@broadcom.com>
 <CACRpkdbT7f8ujCHZxKg26iMKcrAb+_yHW_2YsZwkoo892rkgTA@mail.gmail.com>
 <051069C10411E24D9749790C498526FA1BCF5427@SJEXCHMB12.corp.ad.broadcom.com>
Message-ID: <CACRpkdZ6zQdivtq5wmizovWEGb-Q9xzA6EE8CafnuV13hzX_UA@mail.gmail.com>

On Sat, Apr 27, 2013 at 12:02 AM, Sherman Yin <syin at broadcom.com> wrote:

> Perhaps I have misunderstood you previously, as I thought you are ok with letting
> the driver take care of the loop.  The difference being instead of just moving the for
> loop inside the driver's pin_config_set(), I followed Stephen's suggestion due to
> concern about drivers duplicating the loop:
(...)
> Please correctly if I'm wrong, but I think with the functions in my patch, the
> driver still have full control of / responsibility to resolve config sequence
> and perform validation.  The difference is instead of feeding the driver one
> config at time and telling it to write when the complete() function is called,
> my patch just gives the driver all configs in one call and expects the driver
> to parse, validate and write accordingly.
(...)
>> The driver takes care of caching intermediate settings for the pin
>> until the complete() callback is called.
>> Can you devise a patch like this instead?
>
> I do have some concerns about the driver caching all the configs until complete()
> is called...  I'm ok either way as long as it provides a way to consolidate pin config register
> writes.  Just want to clarify things with you before I go ahead and modify
> my patch and driver.

OK I thought a bit about this too and I see the problem.

However I think it's cluttery to have both
pin_config_set() and pin_config_set_all().

If you want it to be done this way, I think you should modify
pin_config_set() like so instead:

-        int (*pin_config_set) (struct pinctrl_dev *pctldev,
-                               unsigned pin,
-                               unsigned long config);
+       int (*pin_config_set) (struct pinctrl_dev *pctldev,
+                                  const struct
pinctrl_setting_configs *configs, unsigned num_configs);

And then change all the drivers.

(And vice versa mutatis mutandis for the group function.)

Notice especially the added num_configs parameter that was
missing from pin_config_set_all() in your patch, please tell
me how else you deduct the size of the configs array.

To the drivers to iterate over the array of configs,
please introduce a static helper function:

for_each_config() in something like <linux/pinctrl/pinconf.h>
so it's easy for driver writers to get this right. (You'll be much
helped by this function when refactoring the existing drivers as well
I think.)

Doing the same thing with two different functions isn't
helpful, refactoring like this is much better, it's just more
work :-D

Yours,
Linus Walleij


From arnd at arndb.de  Mon Apr 29 09:13:26 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 29 Apr 2013 15:13:26 +0200
Subject: [PATCH v2 05/21] atm: he: use msleep instead of large udelay constants
In-Reply-To: <20130426091220.468cf59e@thirdoffive.cmf.nrl.navy.mil>
References: <1366910944-3033663-1-git-send-email-arnd@arndb.de>
 <AE90C24D6B3A694183C094C60CF0A2F6026B7203@saturn3.aculab.com>
 <20130426091220.468cf59e@thirdoffive.cmf.nrl.navy.mil>
Message-ID: <201304291513.27104.arnd@arndb.de>

From a0ddf082821b064cc2d6a9bb90861f9b81a559a5 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd at arndb.de>
Date: Thu, 14 Mar 2013 15:21:36 +0100
Subject: [PATCH] atm: he: use mdelay instead of large udelay constants

ARM cannot handle udelay for more than 2 miliseconds, and
it is rather bad style to block the cpu for 16ms anyway,
so let's use msleep instead.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Cc: Chas Williams <chas at cmf.nrl.navy.mil>
Cc: linux-atm-general at lists.sourceforge.net
Cc: netdev at vger.kernel.org
---
diff --git a/drivers/atm/he.c b/drivers/atm/he.c
index d689126..507362a 100644
--- a/drivers/atm/he.c
+++ b/drivers/atm/he.c
@@ -1055,7 +1055,7 @@ static int he_start(struct atm_dev *dev)
 	he_writel(he_dev, 0x0, RESET_CNTL);
 	he_writel(he_dev, 0xff, RESET_CNTL);
 
-	udelay(16*1000);	/* 16 ms */
+	msleep(16);	/* 16 ms */
 	status = he_readl(he_dev, RESET_CNTL);
 	if ((status & BOARD_RST_STATUS) == 0) {
 		hprintk("reset failed\n");


From arnd at arndb.de  Mon Apr 29 09:21:14 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 29 Apr 2013 15:21:14 +0200
Subject: [PATCH 10/21] [SCSI] nsp32: use mdelay instead of large udelay
 constants
In-Reply-To: <CALZLnaFeLcaGM7_McTZ=pKBRnpXk0AvqOTF=1YCqJv-53yk4XQ@mail.gmail.com>
References: <1366910944-3033663-1-git-send-email-arnd@arndb.de>
 <1366910944-3033663-11-git-send-email-arnd@arndb.de>
 <CALZLnaFeLcaGM7_McTZ=pKBRnpXk0AvqOTF=1YCqJv-53yk4XQ@mail.gmail.com>
Message-ID: <201304291521.14195.arnd@arndb.de>

On Friday 26 April 2013, Masanori Goto wrote:
> 2013/4/25 Arnd Bergmann <arnd at arndb.de>
> >
> > ARM cannot handle udelay for more than 2 miliseconds, so we
> > should use mdelay instead for those.
> >
> 
> Singed-off-by: GOTO Masanori <gotom at debian.or.jp>

Thanks. I assume you mean "Acked-by", not "Singed-off" as in "burnt"
or "Signed-off" as a notification that you have applied it to your
own git tree.

I'll keep the patch with an your "Acked-by" line in my tree unless
James wants to apply to the scsi tree.

	Arnd


From viresh.kumar at linaro.org  Mon Apr 29 09:24:43 2013
From: viresh.kumar at linaro.org (Viresh Kumar)
Date: Mon, 29 Apr 2013 18:54:43 +0530
Subject: [PATCH 0/5] CPUFreq: ARM big LITTLE Fixes
Message-ID: <cover.1367241503.git.viresh.kumar@linaro.org>

Hi Rafael,

I know I am late for this merge window and you have already closed the gates :)
If you can still take them, its good, otherwise we will push this for v3.10-rc2.

These are minor fixes for ARM big LITTLE cpufreq driver. It doesn't impact any
other driver or cpufreq core and are fairly independent.

Viresh Kumar (5):
  cpufreq: ARM big LITTLE: Select PM_OPP
  cpufreq: ARM big LITTLE DT: Return correct transition latency
  cpufreq: ARM big LITTLE DT: Return CPUFREQ_ETERNAL if clock-latency
    isn't found
  cpufreq: ARM big LITTLE: Move cpu_to_cluster() to arm_big_little.h
  cpufreq: ARM big LITTLE: Improve print message

 drivers/cpufreq/Kconfig.arm         | 1 +
 drivers/cpufreq/arm_big_little.c    | 7 +------
 drivers/cpufreq/arm_big_little.h    | 5 +++++
 drivers/cpufreq/arm_big_little_dt.c | 9 +++++----
 4 files changed, 12 insertions(+), 10 deletions(-)

-- 
1.7.12.rc2.18.g61b472e



From viresh.kumar at linaro.org  Mon Apr 29 09:24:44 2013
From: viresh.kumar at linaro.org (Viresh Kumar)
Date: Mon, 29 Apr 2013 18:54:44 +0530
Subject: [PATCH 1/5] cpufreq: ARM big LITTLE: Select PM_OPP
In-Reply-To: <cover.1367241503.git.viresh.kumar@linaro.org>
References: <cover.1367241503.git.viresh.kumar@linaro.org>
Message-ID: <5f331211da81501872e518a1dc70fbc6f9e45591.1367241503.git.viresh.kumar@linaro.org>

ARM big LITTLE cpufreq driver uses opp layer for its functionality. Select it
in Kconfig.

Signed-off-by: Viresh Kumar <viresh.kumar at linaro.org>
---
 drivers/cpufreq/Kconfig.arm | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index bce2195..797cbd2 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -5,6 +5,7 @@
 config ARM_BIG_LITTLE_CPUFREQ
 	tristate
 	depends on ARM_CPU_TOPOLOGY
+	select PM_OPP
 
 config ARM_DT_BL_CPUFREQ
 	tristate "Generic ARM big LITTLE CPUfreq driver probed via DT"
-- 
1.7.12.rc2.18.g61b472e



From viresh.kumar at linaro.org  Mon Apr 29 09:24:45 2013
From: viresh.kumar at linaro.org (Viresh Kumar)
Date: Mon, 29 Apr 2013 18:54:45 +0530
Subject: [PATCH 2/5] cpufreq: ARM big LITTLE DT: Return correct transition
 latency
In-Reply-To: <cover.1367241503.git.viresh.kumar@linaro.org>
References: <cover.1367241503.git.viresh.kumar@linaro.org>
Message-ID: <26f5713ba03a7d5ee590ce615d19578eb4395abe.1367241503.git.viresh.kumar@linaro.org>

By mistake we are returning zero for successful call to
dt_get_transition_latency(), whereas we should return transition_latency.

Fix it.

Signed-off-by: Viresh Kumar <viresh.kumar at linaro.org>
---
 drivers/cpufreq/arm_big_little_dt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/cpufreq/arm_big_little_dt.c b/drivers/cpufreq/arm_big_little_dt.c
index 44be311..d5ae4d2 100644
--- a/drivers/cpufreq/arm_big_little_dt.c
+++ b/drivers/cpufreq/arm_big_little_dt.c
@@ -78,7 +78,7 @@ static int dt_get_transition_latency(struct device *cpu_dev)
 		of_node_put(np);
 		of_node_put(parent);
 
-		return 0;
+		return transition_latency;
 	}
 
 	return -ENODEV;
-- 
1.7.12.rc2.18.g61b472e



From viresh.kumar at linaro.org  Mon Apr 29 09:24:46 2013
From: viresh.kumar at linaro.org (Viresh Kumar)
Date: Mon, 29 Apr 2013 18:54:46 +0530
Subject: [PATCH 3/5] cpufreq: ARM big LITTLE DT: Return CPUFREQ_ETERNAL if
 clock-latency isn't found
In-Reply-To: <cover.1367241503.git.viresh.kumar@linaro.org>
References: <cover.1367241503.git.viresh.kumar@linaro.org>
Message-ID: <7103baee30f84c26eb6080e407a9f91d219a54c0.1367241503.git.viresh.kumar@linaro.org>

If "/cpus" node isn't found or "clock-latency" isn't defined we are returning
error currently. Lets return CPUFREQ_ETERNAL instead, so that we don't fail.

Flag appropriate messages to user in such cases.

Signed-off-by: Viresh Kumar <viresh.kumar at linaro.org>
---
 drivers/cpufreq/arm_big_little_dt.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/cpufreq/arm_big_little_dt.c b/drivers/cpufreq/arm_big_little_dt.c
index d5ae4d2..173ed05 100644
--- a/drivers/cpufreq/arm_big_little_dt.c
+++ b/drivers/cpufreq/arm_big_little_dt.c
@@ -66,8 +66,8 @@ static int dt_get_transition_latency(struct device *cpu_dev)
 
 	parent = of_find_node_by_path("/cpus");
 	if (!parent) {
-		pr_err("failed to find OF /cpus\n");
-		return -ENOENT;
+		pr_info("Failed to find OF /cpus. Use CPUFREQ_ETERNAL transition latency\n");
+		return CPUFREQ_ETERNAL;
 	}
 
 	for_each_child_of_node(parent, np) {
@@ -81,7 +81,8 @@ static int dt_get_transition_latency(struct device *cpu_dev)
 		return transition_latency;
 	}
 
-	return -ENODEV;
+	pr_info("clock-latency isn't found, use CPUFREQ_ETERNAL transition latency\n");
+	return CPUFREQ_ETERNAL;
 }
 
 static struct cpufreq_arm_bL_ops dt_bL_ops = {
-- 
1.7.12.rc2.18.g61b472e



From viresh.kumar at linaro.org  Mon Apr 29 09:24:47 2013
From: viresh.kumar at linaro.org (Viresh Kumar)
Date: Mon, 29 Apr 2013 18:54:47 +0530
Subject: [PATCH 4/5] cpufreq: ARM big LITTLE: Move cpu_to_cluster() to
 arm_big_little.h
In-Reply-To: <cover.1367241503.git.viresh.kumar@linaro.org>
References: <cover.1367241503.git.viresh.kumar@linaro.org>
Message-ID: <8dd9ca3f1848c74e25d8279dfd6e113b0f537b24.1367241503.git.viresh.kumar@linaro.org>

This routine can be used by glue drivers and so better to keep it in
arm_big_little.h file.

Signed-off-by: Viresh Kumar <viresh.kumar at linaro.org>
---
 drivers/cpufreq/arm_big_little.c | 5 -----
 drivers/cpufreq/arm_big_little.h | 5 +++++
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/cpufreq/arm_big_little.c b/drivers/cpufreq/arm_big_little.c
index dbdf677..fd7beed 100644
--- a/drivers/cpufreq/arm_big_little.c
+++ b/drivers/cpufreq/arm_big_little.c
@@ -40,11 +40,6 @@ static struct clk *clk[MAX_CLUSTERS];
 static struct cpufreq_frequency_table *freq_table[MAX_CLUSTERS];
 static atomic_t cluster_usage[MAX_CLUSTERS] = {ATOMIC_INIT(0), ATOMIC_INIT(0)};
 
-static int cpu_to_cluster(int cpu)
-{
-	return topology_physical_package_id(cpu);
-}
-
 static unsigned int bL_cpufreq_get(unsigned int cpu)
 {
 	u32 cur_cluster = cpu_to_cluster(cpu);
diff --git a/drivers/cpufreq/arm_big_little.h b/drivers/cpufreq/arm_big_little.h
index 70f18fc..79b2ce1 100644
--- a/drivers/cpufreq/arm_big_little.h
+++ b/drivers/cpufreq/arm_big_little.h
@@ -34,6 +34,11 @@ struct cpufreq_arm_bL_ops {
 	int (*init_opp_table)(struct device *cpu_dev);
 };
 
+static inline int cpu_to_cluster(int cpu)
+{
+	return topology_physical_package_id(cpu);
+}
+
 int bL_cpufreq_register(struct cpufreq_arm_bL_ops *ops);
 void bL_cpufreq_unregister(struct cpufreq_arm_bL_ops *ops);
 
-- 
1.7.12.rc2.18.g61b472e



From viresh.kumar at linaro.org  Mon Apr 29 09:24:48 2013
From: viresh.kumar at linaro.org (Viresh Kumar)
Date: Mon, 29 Apr 2013 18:54:48 +0530
Subject: [PATCH 5/5] cpufreq: ARM big LITTLE: Improve print message
In-Reply-To: <cover.1367241503.git.viresh.kumar@linaro.org>
References: <cover.1367241503.git.viresh.kumar@linaro.org>
Message-ID: <61da22c0f40fb46dc31f0ad5183b4ea51dda518c.1367241503.git.viresh.kumar@linaro.org>

Print message at the end of driver->init() doesn't carry "cpufreq" string at all
and so is difficult to find in dmesg. Add function name in message to clearly
state where the message is coming from.

Signed-off-by: Viresh Kumar <viresh.kumar at linaro.org>
---
 drivers/cpufreq/arm_big_little.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/cpufreq/arm_big_little.c b/drivers/cpufreq/arm_big_little.c
index fd7beed..5d7f53f 100644
--- a/drivers/cpufreq/arm_big_little.c
+++ b/drivers/cpufreq/arm_big_little.c
@@ -187,7 +187,7 @@ static int bL_cpufreq_init(struct cpufreq_policy *policy)
 
 	cpumask_copy(policy->cpus, topology_core_cpumask(policy->cpu));
 
-	dev_info(cpu_dev, "CPU %d initialized\n", policy->cpu);
+	dev_info(cpu_dev, "%s: CPU %d initialized\n", __func__, policy->cpu);
 	return 0;
 }
 
-- 
1.7.12.rc2.18.g61b472e



From nicolas.ferre at atmel.com  Mon Apr 29 09:28:41 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Mon, 29 Apr 2013 15:28:41 +0200
Subject: [PATCH v3 1/6] at_hdmac: move to generic DMA binding
In-Reply-To: <20130423034407.GY24632@intel.com>
References: <1366362683-14496-1-git-send-email-ludovic.desroches@atmel.com>
 <1366362683-14496-2-git-send-email-ludovic.desroches@atmel.com>
 <51750F68.4040701@atmel.com> <20130423034407.GY24632@intel.com>
Message-ID: <517E7589.5030205@atmel.com>

On 04/23/2013 05:44 AM, Vinod Koul :
> On Mon, Apr 22, 2013 at 12:22:32PM +0200, Nicolas Ferre wrote:
>> On 04/19/2013 11:11 AM, ludovic.desroches at atmel.com :
>>> From: Ludovic Desroches <ludovic.desroches at atmel.com>
> 
>>> +#ifdef CONFIG_OF
>>> +static bool at_dma_filter(struct dma_chan *chan, void *slave)
> this is not defined for else case here. Also this could be CONFIG_DMA_OF...?

in fact, at_dma_filter() is only used in corresponding
dma_request_channel() in at_dma_xlate() function just below and only in
case of CONFIG_OF.
As the at_dma_xlate() is an empty function in !CONFIG_OF case, the
at_dma_filter() is not needed.

For the use of CONFIG_OF and not CONFIG_OF_DMA, it is simply because it
it the directive that we currently use in drivers when we have to put
the device tree condition around a piece of code. It is quite a common
pattern I think.
Moreover, it is what is used in dw_dmac.c and mv_xor.c...

>>> +{
>>> +	struct at_dma_slave *atslave = slave;
>>> +
>>> +	if (atslave->dma_dev == chan->device->dev) {
>>> +		chan->private = atslave;
>>> +		return true;
>>> +	} else {
>>> +		return false;
>>> +	}
>>> +}
> 
> --
> ~Vinod

Best regards,
-- 
Nicolas Ferre


From arnd at arndb.de  Mon Apr 29 09:34:10 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 29 Apr 2013 15:34:10 +0200
Subject: [PATCH 21/21] mtd: omap2: allow bulding as a module
In-Reply-To: <20980858CB6D3A4BAE95CA194937D5E73E9BCFAE@DBDE04.ent.ti.com>
References: <1366734653-488286-1-git-send-email-arnd@arndb.de>
 <20130423180320.GJ10155@atomide.com>
 <20980858CB6D3A4BAE95CA194937D5E73E9BCFAE@DBDE04.ent.ti.com>
Message-ID: <201304291534.10539.arnd@arndb.de>

On Wednesday 24 April 2013, Gupta, Pekon wrote:
> [Pekon]: 
> ELM module is required in for Hardware based ECC correction for 
> NAND devices. And this driver has a very small foot-print.
> 
> The only cases this drives would not be used are:
> (a) Using S/W based ECC scheme, which have vey high CPU utilization
> (b) Using single bit ECC scheme, which are becoming obsolete due to
>  increasing NAND densities.
> For most of the cases ELM module will be used with nand-driver. So
> there should be no harm in having this module as built-in, if not used
> in 10% of the use-cases.
> 
> Thus I think it's better to keep this module tied to GPMC module, 
> rather than independent control via KConfig.
> And user should just selects which ECC scheme he would like to
> use via DT, without worrying about KConfig options.

Sorry, I'm lost here and have no idea what you are actually suggesting
we do. Can you phrase that as a patch?

Unless you come up with a better solution, I would still like to queue
up my patch since it fixes an annoying bug and seems to have no downsides.
 
> I'm working in cleaning up omap2-nand driver to remove some 
> redundancies. So would like to know your feedback on same..

Sure, just Cc me on your patches.

	Arnd


From maxime.ripard at free-electrons.com  Mon Apr 29 09:58:37 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Mon, 29 Apr 2013 15:58:37 +0200
Subject: [PATCH] mxs: icoll: Add function to register an interrupt as FIQ
 source
Message-ID: <1367243917-5177-1-git-send-email-maxime.ripard@free-electrons.com>

MXS, unlike other ARM platforms, has no way to make a FIQ from an
interrupt from a driver, without poking directly into the icoll.

Add an exported function to do this.

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 arch/arm/mach-mxs/icoll.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/mach-mxs/icoll.c b/arch/arm/mach-mxs/icoll.c
index 8fb23af..1bb16da 100644
--- a/arch/arm/mach-mxs/icoll.c
+++ b/arch/arm/mach-mxs/icoll.c
@@ -16,6 +16,7 @@
  * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
  */
 
+#include <linux/export.h>
 #include <linux/kernel.h>
 #include <linux/init.h>
 #include <linux/irq.h>
@@ -34,6 +35,7 @@
 #define HW_ICOLL_INTERRUPTn_SET(n)		(0x0124 + (n) * 0x10)
 #define HW_ICOLL_INTERRUPTn_CLR(n)		(0x0128 + (n) * 0x10)
 #define BM_ICOLL_INTERRUPTn_ENABLE		0x00000004
+#define BM_ICOLL_INTERRUPTn_FIQ_ENABLE		0x00000010
 #define BV_ICOLL_LEVELACK_IRQLEVELACK__LEVEL0	0x1
 
 #define ICOLL_NUM_IRQS		128
@@ -41,6 +43,15 @@
 static void __iomem *icoll_base = MXS_IO_ADDRESS(MXS_ICOLL_BASE_ADDR);
 static struct irq_domain *icoll_domain;
 
+void mxs_icoll_set_irq_fiq(unsigned int irq)
+{
+	struct irq_data *d = irq_get_irq_data(irq);
+
+	__raw_writel(BM_ICOLL_INTERRUPTn_FIQ_ENABLE,
+		     icoll_base + HW_ICOLL_INTERRUPTn_SET(d->hwirq));
+}
+EXPORT_SYMBOL(mxs_icoll_set_irq_fiq);
+
 static void icoll_ack_irq(struct irq_data *d)
 {
 	/*
-- 
1.8.1.2



From maxime.ripard at free-electrons.com  Mon Apr 29 10:07:18 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Mon, 29 Apr 2013 16:07:18 +0200
Subject: [PATCH] gpio: mxs: Use set and clear capabilities of the gpio
 controller
Message-ID: <1367244438-5322-1-git-send-email-maxime.ripard@free-electrons.com>

The current driver doesn't use the set and clear registers found on the
mxs gpio controller.

This leads the generic gpio controller to be using some internal value
to avoid looking up the value stored in the registers, making it behave
pretty much like a cache.

This raises some coherency problem when a gpio is not modified by the
gpio controller, while it can easily be fixed by using the set and clear
registers.

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 drivers/gpio/gpio-mxs.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpio/gpio-mxs.c b/drivers/gpio/gpio-mxs.c
index 25000b0..f8e6af2 100644
--- a/drivers/gpio/gpio-mxs.c
+++ b/drivers/gpio/gpio-mxs.c
@@ -326,7 +326,8 @@ static int mxs_gpio_probe(struct platform_device *pdev)
 
 	err = bgpio_init(&port->bgc, &pdev->dev, 4,
 			 port->base + PINCTRL_DIN(port),
-			 port->base + PINCTRL_DOUT(port), NULL,
+			 port->base + PINCTRL_DOUT(port) + MXS_SET,
+			 port->base + PINCTRL_DOUT(port) + MXS_CLR,
 			 port->base + PINCTRL_DOE(port), NULL, 0);
 	if (err)
 		goto out_irqdesc_free;
-- 
1.8.1.2



From arnd at arndb.de  Mon Apr 29 10:49:07 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 29 Apr 2013 16:49:07 +0200
Subject: [PATCH 03/21] ARM: shmobile: don't call irqchip_init
 unconditionally
In-Reply-To: <20130426004835.GA20070@verge.net.au>
References: <1366910944-3033663-1-git-send-email-arnd@arndb.de>
 <1366910944-3033663-4-git-send-email-arnd@arndb.de>
 <20130426004835.GA20070@verge.net.au>
Message-ID: <201304291649.08084.arnd@arndb.de>

On Friday 26 April 2013, Simon Horman wrote:
> > diff --git a/arch/arm/mach-shmobile/intc-r8a7740.c b/arch/arm/mach-shmobile/intc-r8a7740.c
> > index 8871f77..5dc57f1 100644
> > --- a/arch/arm/mach-shmobile/intc-r8a7740.c
> > +++ b/arch/arm/mach-shmobile/intc-r8a7740.c
> > @@ -53,14 +53,23 @@ static void __init r8a7740_init_irq_common(void)
> >  
> >  void __init r8a7740_init_irq_of(void)
> >  {
> > +     if (!IS_ENABLED(CONFIG_OF))
> > +             return;
> > +
> 
> In other parts of the shmobile I believe that such code is
> guarded by #ifdef CONFIG_OF and I believe not guarding this code in
> some way was an oversight.
> 
> The above change seems fine to me.

Ok. The change that broke the code is only present in linux-next from
one of your trees, but is not in arm-soc. Could you include the change
in your tree, either by folding into one of your patches or adapting
my patch appropriately?

> > +
> > +     gic_dist_base = ioremap_nocache(0xc2800000, 0x1000);
> > +     gic_cpu_base = ioremap_nocache(0xc2000000, 0x1000);
> >  
> >       /* initialize the Generic Interrupt Controller PL390 r0p0 */
> >       gic_init(0, 29, gic_dist_base, gic_cpu_base);
> 
> This one seems broken as the armadillo800eva board currently uses
> it to initialise GIC even if CONFIG_ATAGS is not defined.
> 
> I did test the above change on the armadillo800eva board
> with the above change and CONFIG_ATAGS disabled, the result was
> a boot failure. With the change reverted booting seems fine.

Yes, I see my mistake now. The second change was clearly wrong
as this function is also used for DT boards, not for ATAGS boards.

	Arnd


From s-anna at ti.com  Mon Apr 29 11:32:20 2013
From: s-anna at ti.com (Suman Anna)
Date: Mon, 29 Apr 2013 10:32:20 -0500
Subject: [PATCHv3 00/14] drivers: mailbox: framework creation
In-Reply-To: <517B2E55.4070708@linaro.org>
References: <1363145021-14339-1-git-send-email-s-anna@ti.com>
 <CABb+yY0RYkVeo2Sb4WsDJY0jf17488FEz0d2CB994eQaSOEsVg@mail.gmail.com>
 <37C860A02101E749A747FA2D3C1E3C504A5DF7@DLEE11.ent.ti.com>
 <CABb+yY1x4x_A+QtGG9ohsLPgs8c3nEVnd_ExJBGOOR8=6YLPFA@mail.gmail.com>
 <37C860A02101E749A747FA2D3C1E3C504A63B4@DLEE11.ent.ti.com>
 <CAJe_ZhehnniZd730jjiOLrHozq8TOJZgFYLqUe4KqgBiQEu8PA@mail.gmail.com>
 <51779304.4040003@st.com>
 <CAJe_ZhdZv5LW6kdwyPtJe69mfW6t=WQ4OJnG2H4sUhibattN2A@mail.gmail.com>
 <517867E1.7050301@ti.com>
 <CAJe_ZhfDZzq+DzA9XDF3PWFUmwcZnDy-mhE4hLNHmf+V4GhOxw@mail.gmail.com>
 <5179AE2F.3040403@ti.com>
 <CAJe_Zhf4miUm4yTyuwc56kpD8Mu4=vsmX4wdQkFDT96JbKR=MQ@mail.gmail.com>
 <517B242D.7040902@ti.com> <517B2E55.4070708@linaro.org>
Message-ID: <517E9284.1010209@ti.com>

Hi Andy,

On 04/26/2013 08:48 PM, Andy Green wrote:
> On 27/04/13 09:04, the mail apparently from Suman Anna included:
> 
> Hi Suman -
> 
>> Even though both the scenarios look very similar, I believe there are
>> some slight differences. All the devices belonging to a controller may
>> not be of the same type (meaning, intended towards the same remote or be
>> used interchangeably with one another). It is definitely possible if you
>> have a similar scenario to the DMA physical channels and your remote
>> rx interrupt can identify the device/channel to process. This would be
>> very much dependent on the architecture of a controller. The particular
>> example that I have in mind is s/w clients between the same set of
>> remote and host entities using the same device - the send part is anyway
>> arbitrated by the controller, and the same received message can be
>> delivered to the clients, with the clients making the decision whether
>> the packet belongs to them or not. I agree that all remote-ends will not
>> be able to cope up intermixed requests, but isn't this again a
>> controller architecture dependent?
> 
> Maybe it's helpful to describe our situation more concretely, because
> the problem is not coming from "the architecture of the [mailbox]
> controller".

Thanks for explaining the usecase. I do think that similar approaches
will become more common (TI AM335 has something similar as well - though
it is related to suspend). The right word should have been "controller
functional integration", I said it as s/w architecture or usage model.
In your case, it is clear that you need time-shared exclusive access,
whereas I am talking about simultaneous-shared usecases.

> 
> In the SoC we work on clock and subsystem power control registers, a
> serial bus, and some other assets are not directly accessible from
> Linux.  We must ask a coprocessor to operate these for us, using the
> mailbox.
> 
> So at any one time, the clock driver or voltagedomain driver for the SoC
> may want to own the mailbox and perform one or more operations over it
> synchronously, in some cases on the remote side involving transactions
> on a serial bus.  We don't want other transactions to be occurring while
> we wait for the serial bus to complete what the driver who started that
> asked for, for example.
> 
> We can cope with this by having an outer driver mediate access to the
> mailbox.  But then there are multiple sync primitives like completions
> and notifiers per operation, because your core already does this.
> 
> In short the FIFO + sync operations approach your core implements
> doesn't fit our use case.  That can be our problem, in which case we'll
> live with the outer mediation driver on top of the mailbox, or it can be
> a sign the fixed choice of FIFO + sync operations in your core did not
> quite hit the nail on the head to really model all the facets of legit
> mailbox usage.

I agree that the current code doesn't address this usage. The changes
(should have them ready in the next couple of days) I am working on
actually makes this conditional.

> 
> At least, this real scenario should be interesting to think about before
> rejecting ^^

No, I didn't reject anything, we are dealing with two contrasting
usecases dependent on the functional integration, and we have to find a
middle ground.

regards
Suman



From james.hogan at imgtec.com  Mon Apr 29 12:00:13 2013
From: james.hogan at imgtec.com (James Hogan)
Date: Mon, 29 Apr 2013 17:00:13 +0100
Subject: [v8,01/12] gpio: add gpio offset in gpio range cells property
In-Reply-To: <1359825953-15663-2-git-send-email-haojian.zhuang@linaro.org>
References: <1359825953-15663-2-git-send-email-haojian.zhuang@linaro.org>
Message-ID: <517E990D.10101@imgtec.com>

On 02/02/13 17:25, Haojian Zhuang wrote:
> Add gpio offset into "gpio-range-cells" property. It's used to support
> sparse pinctrl range in gpio chip.
> 
> Signed-off-by: Haojian Zhuang <haojian.zhuang at linaro.org>
> Acked-by: Viresh Kumar <viresh.kumar at linaro.org>

This is an ABI breakage. I've been using the #gpio-range-cells = <2>
since around October. Please can we try and maintain backward
compatibility in future, even if it's only temporary.

Thanks
James



From s-anna at ti.com  Mon Apr 29 12:00:07 2013
From: s-anna at ti.com (Suman Anna)
Date: Mon, 29 Apr 2013 11:00:07 -0500
Subject: [PATCHv3 00/14] drivers: mailbox: framework creation
In-Reply-To: <CAJe_ZhdH+SCs5crguXrm6y-6bu+eGnTqeJS6cOS5H5Yz=m15Cw@mail.gmail.com>
References: <1363145021-14339-1-git-send-email-s-anna@ti.com>
 <CABb+yY0RYkVeo2Sb4WsDJY0jf17488FEz0d2CB994eQaSOEsVg@mail.gmail.com>
 <37C860A02101E749A747FA2D3C1E3C504A5DF7@DLEE11.ent.ti.com>
 <CABb+yY1x4x_A+QtGG9ohsLPgs8c3nEVnd_ExJBGOOR8=6YLPFA@mail.gmail.com>
 <37C860A02101E749A747FA2D3C1E3C504A63B4@DLEE11.ent.ti.com>
 <CAJe_ZhehnniZd730jjiOLrHozq8TOJZgFYLqUe4KqgBiQEu8PA@mail.gmail.com>
 <51779304.4040003@st.com>
 <CAJe_ZhdZv5LW6kdwyPtJe69mfW6t=WQ4OJnG2H4sUhibattN2A@mail.gmail.com>
 <517867E1.7050301@ti.com>
 <CAJe_ZhfDZzq+DzA9XDF3PWFUmwcZnDy-mhE4hLNHmf+V4GhOxw@mail.gmail.com>
 <5179AE2F.3040403@ti.com>
 <CAJe_Zhf4miUm4yTyuwc56kpD8Mu4=vsmX4wdQkFDT96JbKR=MQ@mail.gmail.com>
 <517B242D.7040902@ti.com>
 <CAJe_ZhdH+SCs5crguXrm6y-6bu+eGnTqeJS6cOS5H5Yz=m15Cw@mail.gmail.com>
Message-ID: <517E9907.4030106@ti.com>

Hi Jassi,

On 04/26/2013 11:51 PM, Jassi Brar wrote:
> Hi Suman,
> 
>>> On 26 April 2013 03:59, Suman Anna <s-anna at ti.com> wrote:
>>>> On 04/25/2013 12:20 AM, Jassi Brar wrote:
> 
>>> I never said no-buffering and I never said buffering should be in
>>> controller drivers. In fact I don't remember ever objecting to how
>>> buffering is done in TI's framework.
>>> A controller could service only 1 request at a time so lets give it
>>> just 1 at a time. Let the API handle the complexity of buffering.
>>>
>>
>> Alright, guess this got lost in translation :). I interpreted based on
>> the fact that you wanted to get rid of the size field from the
>> mailbox_msg definition. Do you have a different mechanism in mind for
>> the buffering compared to the present one?
>>
> Sure, a very simple but efficient one. I had started on pseudo code
> implementation the day I first replied, but now I have real code with
> the PL320 controller and the Highbank client converted to the API. All
> that I say features in the new design. Polishing and documentation
> will take just a few hours more. You could see end to end what I have
> been talking about.
>>
>> OK, I didn't think of a no RTR interrupt-based controller. I would thing
>> that such a controller is very rudimentary. I wonder if there are any
>> controllers like this out there.
>>
> One of my controllers is like that :)

I hope it does have a status register atleast, and not the "neither
report nor sense RTR" type.

> 
>>>
>>> BTW, TI's RX mechanism too seems broken for common API. Receiving
>>> every few bytes via 'notify' mechanism is very inefficient. Imagine a
>>> platform with no shared memory between co-processors and the local
>>> wants to diagnose the remote by asking critical data at least KBs in
>>> size.
>>
>> No shared memory between co-processors and a relatively slow wire
>> transport is a bad architecture design to begin with.
>>
> IMHO it's only about private memory. Even if the controller transfers,
> say, 10bytes/interrupt there could always be a requirement to read
> some 1MB region of remote's private memory. And the same logic implies
> that our TX too should be as fast as possible - the remote might need
> its 1MB firmware over the link. So let us just try to serve all
> designs rather than evaluate them :)
> 
> 
>>>  So when API has nothing to do with received packet and the controller
>>> has to get rid of it asap so as to be able to receive the next, IMHO
>>> there should be short-circuit from controller to client via the API.
>>> No delay, no buffering of RX.
>>
>> The current TI design is based on the fact that we can get multiple
>> messages on a single interrupt due to the h/w fifo and the driver takes
>> care of the bottom-half. Leaving it to the client is putting a lot of
>> faith in the client and doesn't scale to multiple clients. The client
>> would have to perform mostly the same as the driver is doing - so this
>> goes back to the base discussion point that we have - which is the lack
>> of support for atomic_context receivers in the current code. I perceive
>> this as an attribute of the controller/mailbox device itself rather than
>> the client.
>>
> Sorry, I don't understand the concern about faith.
> If the controller h/w absolutely can not tell the remote(sender) of a
> received packet (as seems to be your case), its driver shouldn't even
> try to demux the received messages. The client driver must know which
> remotes could send it a message and how to discern them on the
> platform. Some 'server' RX client is needed here.

No demuxing, deliver the message to the different clients. It is a
protocol agreement between the clients on what the message means. Think
of this scenario akin to shared interrupts.

> If the controller could indeed map received packet onto remotes, then
> ideally the controller driver should declare one (RX only) channel for
> each such remote and demux packets onto them.
> In either case, 'notify' mechanism is not necessary.

The notify mechanism was the top-half on the interrupt handling. The
faith part is coming from the fact that you expect all the clients to do
the equivalent of the bottom-half (which would mean some duplication in
the different clients), the OMAP scenario is such that all the different
link interrupts (both rx & tx) are mapped onto a single physical
interrupt. I think this may not be applicable to your usecase, wherein
you probably expect a response back before proceeding.

> 
> 
>> I agree that all remote-ends will not
>> be able to cope up intermixed requests, but isn't this again a
>> controller architecture dependent?
>>
> I think it's more about remote's protocol implementation than
> controller's architecture.

Right, I meant functional integration.

> If tomorrow TI's remote firmware introduces a new set of critical
> commands that may arrive only in a particular sequence, you'll find
> yourself sharing a ride on our dinghy :)
> And Andy already explained where we come from.

This is almost always true when your remote is for offloading some h/w
operations.

regards
Suman



From catalin.marinas at arm.com  Mon Apr 29 12:26:52 2013
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Mon, 29 Apr 2013 17:26:52 +0100
Subject: [PATCH v3 07/32] arm64: KVM: fault injection into a guest
In-Reply-To: <1365437854-30214-8-git-send-email-marc.zyngier@arm.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
 <1365437854-30214-8-git-send-email-marc.zyngier@arm.com>
Message-ID: <20130429162652.GA16544@arm.com>

On Mon, Apr 08, 2013 at 05:17:09PM +0100, Marc Zyngier wrote:
> +static void inject_abt64(struct kvm_vcpu *vcpu, bool is_iabt, unsigned long addr)
> +{
> +	unsigned long cpsr = *vcpu_cpsr(vcpu);
> +	int is_aarch32;
> +	u32 esr = 0;
> +
> +	is_aarch32 = vcpu_mode_is_32bit(vcpu);

Minor thing - use bool here to match the function definition?

-- 
Catalin


From cdall at cs.columbia.edu  Mon Apr 29 12:35:11 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Mon, 29 Apr 2013 09:35:11 -0700
Subject: [PATCH V2] ARM: KVM: Allow host virt timer irq to be different
 from guest timer virt irq
In-Reply-To: <1367220347-5625-1-git-send-email-anup.patel@linaro.org>
References: <1367220347-5625-1-git-send-email-anup.patel@linaro.org>
Message-ID: <CAEDV+gJi7+YGeAqT5xK0d+AzwMVO6LqO1so8NG7RpbV569y_rA@mail.gmail.com>

On Mon, Apr 29, 2013 at 12:25 AM, Anup Patel <anup.patel at linaro.org> wrote:
> The arch_timer irq numbers (or PPI numbers) are implementation dependent
> so, the host virtual timer irq number can be different from guest virtual
> timer irq number.

nit: move comma before 'so'

>
> This patch ensures that host virtual timer irq number is read from DTB and
> guest virtual timer irq is determined based on vcpu target type.
>
> Signed-off-by: Anup Patel <anup.patel at linaro.org>
> Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar at linaro.org>
> ---
>  arch/arm/include/asm/kvm_arch_timer.h |    4 ++++
>  arch/arm/kvm/arch_timer.c             |   27 ++++++++++++++++++++-------
>  arch/arm/kvm/reset.c                  |   11 +++++++++++
>  3 files changed, 35 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm/include/asm/kvm_arch_timer.h b/arch/arm/include/asm/kvm_arch_timer.h
> index 68cb9e1..eeb2a3f 100644
> --- a/arch/arm/include/asm/kvm_arch_timer.h
> +++ b/arch/arm/include/asm/kvm_arch_timer.h
> @@ -61,6 +61,8 @@ struct arch_timer_cpu {
>  #ifdef CONFIG_KVM_ARM_TIMER
>  int kvm_timer_hyp_init(void);
>  int kvm_timer_init(struct kvm *kvm);
> +void kvm_timer_vcpu_reset(struct kvm_vcpu *vcpu,
> +                         const struct kvm_irq_level *irq);
>  void kvm_timer_vcpu_init(struct kvm_vcpu *vcpu);
>  void kvm_timer_flush_hwstate(struct kvm_vcpu *vcpu);
>  void kvm_timer_sync_hwstate(struct kvm_vcpu *vcpu);
> @@ -76,6 +78,8 @@ static inline int kvm_timer_init(struct kvm *kvm)
>         return 0;
>  }
>
> +static inline void kvm_timer_vcpu_reset(struct kvm_vcpu *vcpu,
> +                                       const struct kvm_irq_level *irq) {}
>  static inline void kvm_timer_vcpu_init(struct kvm_vcpu *vcpu) {}
>  static inline void kvm_timer_flush_hwstate(struct kvm_vcpu *vcpu) {}
>  static inline void kvm_timer_sync_hwstate(struct kvm_vcpu *vcpu) {}
> diff --git a/arch/arm/kvm/arch_timer.c b/arch/arm/kvm/arch_timer.c
> index 49a7516..c64b597 100644
> --- a/arch/arm/kvm/arch_timer.c
> +++ b/arch/arm/kvm/arch_timer.c
> @@ -30,7 +30,7 @@
>
>  static struct timecounter *timecounter;
>  static struct workqueue_struct *wqueue;
> -static struct kvm_irq_level timer_irq = {
> +static struct kvm_irq_level host_timer_irq = {
>         .level  = 1,
>  };

there is no need for this to be a struct kvm_irq_level anymore, this
has nothing to do with a VM, it is just a number, so an unsigned int
would be more appropriate.

>
> @@ -67,8 +67,8 @@ static void kvm_timer_inject_irq(struct kvm_vcpu *vcpu)
>
>         timer->cntv_ctl |= ARCH_TIMER_CTRL_IT_MASK;
>         kvm_vgic_inject_irq(vcpu->kvm, vcpu->vcpu_id,
> -                           vcpu->arch.timer_cpu.irq->irq,
> -                           vcpu->arch.timer_cpu.irq->level);
> +                           timer->irq->irq,
> +                           timer->irq->level);
>  }
>
>  static irqreturn_t kvm_arch_timer_handler(int irq, void *dev_id)
> @@ -156,6 +156,20 @@ void kvm_timer_sync_hwstate(struct kvm_vcpu *vcpu)
>         timer_arm(timer, ns);
>  }
>
> +void kvm_timer_vcpu_reset(struct kvm_vcpu *vcpu,
> +                         const struct kvm_irq_level *irq)
> +{
> +       struct arch_timer_cpu *timer = &vcpu->arch.timer_cpu;
> +
> +       /*
> +        * The vcpu timer irq number cannot be determined in
> +        * kvm_timer_vcpu_init() because it is called much before
> +        * kvm_vcpu_set_target(). To handle this, we determine
> +        * vcpu timer irq number when the vcpu is resetted.

s/resetted/reset/

> +        */
> +       timer->irq = irq;
> +}
> +
>  void kvm_timer_vcpu_init(struct kvm_vcpu *vcpu)
>  {
>         struct arch_timer_cpu *timer = &vcpu->arch.timer_cpu;
> @@ -163,12 +177,11 @@ void kvm_timer_vcpu_init(struct kvm_vcpu *vcpu)
>         INIT_WORK(&timer->expired, kvm_timer_inject_irq_work);
>         hrtimer_init(&timer->timer, CLOCK_MONOTONIC, HRTIMER_MODE_ABS);
>         timer->timer.function = kvm_timer_expire;
> -       timer->irq = &timer_irq;
>  }
>
>  static void kvm_timer_init_interrupt(void *info)
>  {
> -       enable_percpu_irq(timer_irq.irq, 0);
> +       enable_percpu_irq(host_timer_irq.irq, 0);
>  }
>
>
> @@ -182,7 +195,7 @@ static int kvm_timer_cpu_notify(struct notifier_block *self,
>                 break;
>         case CPU_DYING:
>         case CPU_DYING_FROZEN:
> -               disable_percpu_irq(timer_irq.irq);
> +               disable_percpu_irq(host_timer_irq.irq);
>                 break;
>         }
>
> @@ -230,7 +243,7 @@ int kvm_timer_hyp_init(void)
>                 goto out;
>         }
>
> -       timer_irq.irq = ppi;
> +       host_timer_irq.irq = ppi;
>
>         err = register_cpu_notifier(&kvm_timer_cpu_nb);
>         if (err) {
> diff --git a/arch/arm/kvm/reset.c b/arch/arm/kvm/reset.c
> index b80256b..0b49ad7 100644
> --- a/arch/arm/kvm/reset.c
> +++ b/arch/arm/kvm/reset.c
> @@ -26,6 +26,7 @@
>  #include <asm/cputype.h>
>  #include <asm/kvm_arm.h>
>  #include <asm/kvm_coproc.h>
> +#include <asm/kvm_arch_timer.h>
>
>  /******************************************************************************
>   * Cortex-A15 Reset Values
> @@ -37,6 +38,11 @@ static struct kvm_regs a15_regs_reset = {
>         .usr_regs.ARM_cpsr = SVC_MODE | PSR_A_BIT | PSR_I_BIT | PSR_F_BIT,
>  };
>
> +static const struct kvm_irq_level a15_vtimer_irq = {
> +       .irq = 27,
> +       .level = 1,
> +};
> +
>
>  /*******************************************************************************
>   * Exported reset function
> @@ -52,6 +58,7 @@ static struct kvm_regs a15_regs_reset = {
>  int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
>  {
>         struct kvm_regs *cpu_reset;
> +       const struct kvm_irq_level *cpu_vtimer_irq;
>
>         switch (vcpu->arch.target) {
>         case KVM_ARM_TARGET_CORTEX_A15:
> @@ -59,6 +66,7 @@ int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
>                         return -EINVAL;
>                 cpu_reset = &a15_regs_reset;
>                 vcpu->arch.midr = read_cpuid_id();
> +               cpu_vtimer_irq = &a15_vtimer_irq;
>                 break;
>         default:
>                 return -ENODEV;
> @@ -70,5 +78,8 @@ int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
>         /* Reset CP15 registers */
>         kvm_reset_coprocs(vcpu);
>
> +       /* Reset arch_timer context */
> +       kvm_timer_vcpu_reset(vcpu, cpu_vtimer_irq);
> +
>         return 0;
>  }
> --
> 1.7.9.5
>
> _______________________________________________
> kvmarm mailing list
> kvmarm at lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm


From cdall at cs.columbia.edu  Mon Apr 29 12:40:38 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Mon, 29 Apr 2013 09:40:38 -0700
Subject: [PATCH V2] arm64: KVM: Reset arch_timer upon vcpu reset
In-Reply-To: <1367220500-5690-1-git-send-email-anup.patel@linaro.org>
References: <1367220500-5690-1-git-send-email-anup.patel@linaro.org>
Message-ID: <CAEDV+gJOMnoWVHU3bqUBUzciy7mx38a1wVWqTP1TMbvS8XXDCg@mail.gmail.com>

On Mon, Apr 29, 2013 at 12:28 AM, Anup Patel <anup.patel at linaro.org> wrote:
> This patch does arch_timer reset (i.e. kvm_timer_vcpu_reset()) when
> a vcpu resetted by kvm_reset_vcpu().
>
> The kvm_reset_vcpu() also informs guest timer irq number to arch_timer
> code via kvm_timer_vcpu_reset().

This commit text did not parse.

Might I suggest:

"Reset the arch_timer on cpu reset and configure guest virtual timer
irq in the process".

>
> Signed-off-by: Anup Patel <anup.patel at linaro.org>
> Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar at linaro.org>
> ---
>  arch/arm64/include/asm/kvm_arch_timer.h |    2 ++
>  arch/arm64/kvm/reset.c                  |   11 +++++++++++
>  2 files changed, 13 insertions(+)
>
> diff --git a/arch/arm64/include/asm/kvm_arch_timer.h b/arch/arm64/include/asm/kvm_arch_timer.h
> index eb02273..0f36603 100644
> --- a/arch/arm64/include/asm/kvm_arch_timer.h
> +++ b/arch/arm64/include/asm/kvm_arch_timer.h
> @@ -50,6 +50,8 @@ struct arch_timer_cpu {
>
>  int kvm_timer_hyp_init(void);
>  int kvm_timer_init(struct kvm *kvm);
> +void kvm_timer_vcpu_reset(struct kvm_vcpu *vcpu,
> +                         const struct kvm_irq_level *irq);
>  void kvm_timer_vcpu_init(struct kvm_vcpu *vcpu);
>  void kvm_timer_flush_hwstate(struct kvm_vcpu *vcpu);
>  void kvm_timer_sync_hwstate(struct kvm_vcpu *vcpu);
> diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
> index 64e0740..7c9cebc 100644
> --- a/arch/arm64/kvm/reset.c
> +++ b/arch/arm64/kvm/reset.c
> @@ -27,6 +27,7 @@
>  #include <asm/ptrace.h>
>  #include <asm/kvm_arm.h>
>  #include <asm/kvm_coproc.h>
> +#include <asm/kvm_arch_timer.h>
>
>  /*
>   * ARMv8 Reset Values
> @@ -40,6 +41,11 @@ static struct kvm_regs default_regs_reset32 = {
>                         COMPAT_PSR_I_BIT | COMPAT_PSR_F_BIT),
>  };
>
> +static const struct kvm_irq_level default_vtimer_irq = {
> +       .irq = 27,
> +       .level = 1,
> +};
> +
>  static bool cpu_has_32bit_el1(void)
>  {
>         u64 pfr0;
> @@ -75,6 +81,7 @@ int kvm_arch_dev_ioctl_check_extension(long ext)
>  int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
>  {
>         struct kvm_regs *cpu_reset;
> +       const struct kvm_irq_level *cpu_vtimer_irq;
>
>         switch (vcpu->arch.target) {
>         default:
> @@ -86,6 +93,7 @@ int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
>                 } else {
>                         cpu_reset = &default_regs_reset;
>                 }
> +               cpu_vtimer_irq = &default_vtimer_irq;
>                 break;
>         }
>
> @@ -95,5 +103,8 @@ int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
>         /* Reset system registers */
>         kvm_reset_sys_regs(vcpu);
>
> +       /* Reset arch_timer context */
> +       kvm_timer_vcpu_reset(vcpu, cpu_vtimer_irq);
> +
>         return 0;
>  }
> --
> 1.7.9.5
>
> _______________________________________________
> kvmarm mailing list
> kvmarm at lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm


From haojian.zhuang at linaro.org  Mon Apr 29 12:49:03 2013
From: haojian.zhuang at linaro.org (Haojian Zhuang)
Date: Tue, 30 Apr 2013 00:49:03 +0800
Subject: [v8,01/12] gpio: add gpio offset in gpio range cells property
In-Reply-To: <517E990D.10101@imgtec.com>
References: <1359825953-15663-2-git-send-email-haojian.zhuang@linaro.org>
 <517E990D.10101@imgtec.com>
Message-ID: <CAD6h2NTxmZqaYt6wQU3QrmUbPk9wjSSCy0JxhFp0_4MSdvEdDA@mail.gmail.com>

On 30 April 2013 00:00, James Hogan <james.hogan at imgtec.com> wrote:
> On 02/02/13 17:25, Haojian Zhuang wrote:
>> Add gpio offset into "gpio-range-cells" property. It's used to support
>> sparse pinctrl range in gpio chip.
>>
>> Signed-off-by: Haojian Zhuang <haojian.zhuang at linaro.org>
>> Acked-by: Viresh Kumar <viresh.kumar at linaro.org>
>
> This is an ABI breakage. I've been using the #gpio-range-cells = <2>
> since around October. Please can we try and maintain backward
> compatibility in future, even if it's only temporary.
>
> Thanks
> James
>

I've updated all code with #gpio-range-cells = <3> in kernel. If you change this
back to <2>, you'll break current pinctrl-single driver. I appended this because
there may be not 1-to-1 mapping between gpio pins & pinmux pins in some
SoC. So the new parameter is used to specify the gpio pin offset.

So it's not temporary.

Regards
Haojian


From jaswinder.singh at linaro.org  Mon Apr 29 12:49:08 2013
From: jaswinder.singh at linaro.org (Jassi Brar)
Date: Mon, 29 Apr 2013 22:19:08 +0530
Subject: [PATCHv3 00/14] drivers: mailbox: framework creation
In-Reply-To: <517E9907.4030106@ti.com>
References: <1363145021-14339-1-git-send-email-s-anna@ti.com>
 <CABb+yY0RYkVeo2Sb4WsDJY0jf17488FEz0d2CB994eQaSOEsVg@mail.gmail.com>
 <37C860A02101E749A747FA2D3C1E3C504A5DF7@DLEE11.ent.ti.com>
 <CABb+yY1x4x_A+QtGG9ohsLPgs8c3nEVnd_ExJBGOOR8=6YLPFA@mail.gmail.com>
 <37C860A02101E749A747FA2D3C1E3C504A63B4@DLEE11.ent.ti.com>
 <CAJe_ZhehnniZd730jjiOLrHozq8TOJZgFYLqUe4KqgBiQEu8PA@mail.gmail.com>
 <51779304.4040003@st.com>
 <CAJe_ZhdZv5LW6kdwyPtJe69mfW6t=WQ4OJnG2H4sUhibattN2A@mail.gmail.com>
 <517867E1.7050301@ti.com>
 <CAJe_ZhfDZzq+DzA9XDF3PWFUmwcZnDy-mhE4hLNHmf+V4GhOxw@mail.gmail.com>
 <5179AE2F.3040403@ti.com>
 <CAJe_Zhf4miUm4yTyuwc56kpD8Mu4=vsmX4wdQkFDT96JbKR=MQ@mail.gmail.com>
 <517B242D.7040902@ti.com>
 <CAJe_ZhdH+SCs5crguXrm6y-6bu+eGnTqeJS6cOS5H5Yz=m15Cw@mail.gmail.com>
 <517E9907.4030106@ti.com>
Message-ID: <CAJe_Zhcm_jO6g2GjMEkQ=rYmav80f9bjj3OtypnRfcrh9zMRuw@mail.gmail.com>

Hi

On 29 April 2013 21:30, Suman Anna <s-anna at ti.com> wrote:
> Hi Jassi,
>
> On 04/26/2013 11:51 PM, Jassi Brar wrote:

>>> OK, I didn't think of a no RTR interrupt-based controller. I would thing
>>> that such a controller is very rudimentary. I wonder if there are any
>>> controllers like this out there.
>>>
>> One of my controllers is like that :)
>
> I hope it does have a status register atleast, and not the "neither
> report nor sense RTR" type.
>
Actually the status is not set by the h/w, but the remote's firmware
implementation makes sure it sets a marker in the status register
after accepting data. So with some other firmware, we might not even
have the status read facility and the client will have to solely run
the TX ticker.

>> If the controller h/w absolutely can not tell the remote(sender) of a
>> received packet (as seems to be your case), its driver shouldn't even
>> try to demux the received messages. The client driver must know which
>> remotes could send it a message and how to discern them on the
>> platform. Some 'server' RX client is needed here.
>
> No demuxing, deliver the message to the different clients. It is a
> protocol agreement between the clients on what the message means. Think
> of this scenario akin to shared interrupts.
>
Please re-read. That's what I said - No demuxing by the controller driver :)

>
> The notify mechanism was the top-half on the interrupt handling. The
> faith part is coming from the fact that you expect all the clients to do
> the equivalent of the bottom-half (which would mean some duplication in
> the different clients), the OMAP scenario is such that all the different
> link interrupts (both rx & tx) are mapped onto a single physical
> interrupt. I think this may not be applicable to your usecase, wherein
> you probably expect a response back before proceeding.
>
Simply put - the RX by notifier method will fail should a client is
speed critical.
The api might provide it optionally, but direct handover should be the
default option.

Btw, I did put up an almost tested version of an API implementing most
of the features we agree upon
http://www.spinics.net/lists/kernel/msg1523873.html
http://www.spinics.net/lists/kernel/msg1523874.html

cheers.


From s-anna at ti.com  Mon Apr 29 12:44:30 2013
From: s-anna at ti.com (Suman Anna)
Date: Mon, 29 Apr 2013 11:44:30 -0500
Subject: [RFC 3/3] mailbox: pl320: Introduce common API driver
In-Reply-To: <1367086496-28647-1-git-send-email-jaswinder.singh@linaro.org>
References: <CAJe_ZhdH+SCs5crguXrm6y-6bu+eGnTqeJS6cOS5H5Yz=m15Cw@mail.gmail.com>
 <1367086496-28647-1-git-send-email-jaswinder.singh@linaro.org>
Message-ID: <517EA36E.2050106@ti.com>

On 04/27/2013 01:14 PM, jassisinghbrar at gmail.com wrote:
> From: Jassi Brar <jaswinder.singh at linaro.org>
> 
> Convert the PL320 controller driver to work with the common
> mailbox API. Also convert the only user of PL320, highbank-cpufreq.c
> to work with thee API. Drop the obsoleted driver pl320-ipc.c

I think the conversion is fine based on your API, but you have
eliminated the stand-alone Rx interrupt code in the conversion. I
searched for if anybody is registering these rx atomic notifiers in 3.9,
and didn't find any. Is this expected to stay like this or is it some
future functionality not yet added, but getting removed in this patch.

> 
> Signed-off-by: Jassi Brar <jaswinder.singh at linaro.org>
> ---
>  drivers/cpufreq/highbank-cpufreq.c       |   22 +++-
>  drivers/mailbox/Makefile                 |    2 +-
>  drivers/mailbox/{pl320-ipc.c => pl320.c} |  194 ++++++++++++++++--------------
>  include/linux/pl320-ipc.h                |   17 ---
>  4 files changed, 125 insertions(+), 110 deletions(-)
>  rename drivers/mailbox/{pl320-ipc.c => pl320.c} (51%)
>  delete mode 100644 include/linux/pl320-ipc.h
> 
> diff --git a/drivers/cpufreq/highbank-cpufreq.c b/drivers/cpufreq/highbank-cpufreq.c
> index 3118b87..5c057e0 100644
> --- a/drivers/cpufreq/highbank-cpufreq.c
> +++ b/drivers/cpufreq/highbank-cpufreq.c
> @@ -19,7 +19,7 @@
>  #include <linux/cpu.h>
>  #include <linux/err.h>
>  #include <linux/of.h>
> -#include <linux/pl320-ipc.h>
> +#include <linux/mailbox_client.h>
>  #include <linux/platform_device.h>
>  
>  #define HB_CPUFREQ_CHANGE_NOTE	0x80000001
> @@ -29,8 +29,26 @@
>  static int hb_voltage_change(unsigned int freq)
>  {
>  	u32 msg[HB_CPUFREQ_IPC_LEN] = {HB_CPUFREQ_CHANGE_NOTE, freq / 1000000};
> +	struct ipc_client cl;
> +	int ret = -ETIMEDOUT;
> +	void *chan;
>  
> -	return pl320_ipc_transmit(msg);
> +	cl.rxcb = NULL;
> +	cl.txcb = NULL;
> +	cl.tx_block = true;
> +	cl.tx_tout = 1000; /* 1 sec */
> +	cl.cntlr_data = NULL;
> +	cl.knows_txdone = false;
> +	cl.chan_name = "pl320:A9_to_M3";
> +
> +	chan = ipc_request_channel(&cl);
> +
> +	if (ipc_send_message(chan, (void *)msg))
> +		ret = msg[1]; /* PL320 updates buffer with FIFO after ACK */
> +
> +	ipc_free_channel(chan);

I think I understand why you have done this, but do you really want to
request and free every time in the highbank cpufreq driver?

regards
Suman


From jason at lakedaemon.net  Mon Apr 29 12:50:06 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Mon, 29 Apr 2013 12:50:06 -0400
Subject: [PATCH] ARM: dove: fix Dove cpu type from V7 to PJ4
In-Reply-To: <1364051211-24414-1-git-send-email-sebastian.hesselbarth@gmail.com>
References: <1364051211-24414-1-git-send-email-sebastian.hesselbarth@gmail.com>
Message-ID: <20130429165006.GR32497@titan.lakedaemon.net>

On Sat, Mar 23, 2013 at 04:06:51PM +0100, Sebastian Hesselbarth wrote:
> The CPU used in Marvell Dove SoCs is a PJ4 Sheeva core. Using
> CONFIG_CPU_PJ4 instead of CONFIG_CPU_V7 will also allow to enable
> iWMMXt extensions on Dove.
> 
> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
> ---
> Cc: Russell King <linux at arm.linux.org.uk>
> Cc: Jason Cooper <jason at lakedaemon.net>
> Cc: Andrew Lunn <andrew at lunn.ch>
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-kernel at vger.kernel.org
> ---
>  arch/arm/Kconfig |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Sebastian,

It looks as though Russell's fix for IWMMXT made it in.  Please place
this patch in Russell's patch tracker.  If you don't have the original
thread, Andrew Lunn gave this an Acked-by.  Now me as well:

Acked-by: Jason Cooper <jason at lakedaemon.net>

thx,

Jason.

> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 2c3bdce..4fc9bca 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -556,7 +556,7 @@ config ARCH_IXP4XX
>  config ARCH_DOVE
>  	bool "Marvell Dove"
>  	select ARCH_REQUIRE_GPIOLIB
> -	select CPU_V7
> +	select CPU_PJ4
>  	select GENERIC_CLOCKEVENTS
>  	select MIGHT_HAVE_PCI
>  	select PINCTRL
> -- 
> 1.7.10.4
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From jaswinder.singh at linaro.org  Mon Apr 29 12:57:41 2013
From: jaswinder.singh at linaro.org (Jassi Brar)
Date: Mon, 29 Apr 2013 22:27:41 +0530
Subject: [RFC 3/3] mailbox: pl320: Introduce common API driver
In-Reply-To: <517EA36E.2050106@ti.com>
References: <CAJe_ZhdH+SCs5crguXrm6y-6bu+eGnTqeJS6cOS5H5Yz=m15Cw@mail.gmail.com>
 <1367086496-28647-1-git-send-email-jaswinder.singh@linaro.org>
 <517EA36E.2050106@ti.com>
Message-ID: <CAJe_ZhcHVAQfPZJ-+upr-78B+MqLw36jTmS8geZpc2=_-gGzGQ@mail.gmail.com>

On 29 April 2013 22:14, Suman Anna <s-anna at ti.com> wrote:
> On 04/27/2013 01:14 PM, jassisinghbrar at gmail.com wrote:
>> From: Jassi Brar <jaswinder.singh at linaro.org>
>>
>> Convert the PL320 controller driver to work with the common
>> mailbox API. Also convert the only user of PL320, highbank-cpufreq.c
>> to work with thee API. Drop the obsoleted driver pl320-ipc.c
>
> I think the conversion is fine based on your API, but you have
> eliminated the stand-alone Rx interrupt code in the conversion. I
> searched for if anybody is registering these rx atomic notifiers in 3.9,
> and didn't find any. Is this expected to stay like this or is it some
> future functionality not yet added, but getting removed in this patch.
>
Yeah, probably only some out-of-tree code needed that but that made my
life simpler :)

>>
>> Signed-off-by: Jassi Brar <jaswinder.singh at linaro.org>
>> ---
>>  drivers/cpufreq/highbank-cpufreq.c       |   22 +++-
>>  drivers/mailbox/Makefile                 |    2 +-
>>  drivers/mailbox/{pl320-ipc.c => pl320.c} |  194 ++++++++++++++++--------------
>>  include/linux/pl320-ipc.h                |   17 ---
>>  4 files changed, 125 insertions(+), 110 deletions(-)
>>  rename drivers/mailbox/{pl320-ipc.c => pl320.c} (51%)
>>  delete mode 100644 include/linux/pl320-ipc.h
>>
>> diff --git a/drivers/cpufreq/highbank-cpufreq.c b/drivers/cpufreq/highbank-cpufreq.c
>> index 3118b87..5c057e0 100644
>> --- a/drivers/cpufreq/highbank-cpufreq.c
>> +++ b/drivers/cpufreq/highbank-cpufreq.c
>> @@ -19,7 +19,7 @@
>>  #include <linux/cpu.h>
>>  #include <linux/err.h>
>>  #include <linux/of.h>
>> -#include <linux/pl320-ipc.h>
>> +#include <linux/mailbox_client.h>
>>  #include <linux/platform_device.h>
>>
>>  #define HB_CPUFREQ_CHANGE_NOTE       0x80000001
>> @@ -29,8 +29,26 @@
>>  static int hb_voltage_change(unsigned int freq)
>>  {
>>       u32 msg[HB_CPUFREQ_IPC_LEN] = {HB_CPUFREQ_CHANGE_NOTE, freq / 1000000};
>> +     struct ipc_client cl;
>> +     int ret = -ETIMEDOUT;
>> +     void *chan;
>>
>> -     return pl320_ipc_transmit(msg);
>> +     cl.rxcb = NULL;
>> +     cl.txcb = NULL;
>> +     cl.tx_block = true;
>> +     cl.tx_tout = 1000; /* 1 sec */
>> +     cl.cntlr_data = NULL;
>> +     cl.knows_txdone = false;
>> +     cl.chan_name = "pl320:A9_to_M3";
>> +
>> +     chan = ipc_request_channel(&cl);
>> +
>> +     if (ipc_send_message(chan, (void *)msg))
>> +             ret = msg[1]; /* PL320 updates buffer with FIFO after ACK */
>> +
>> +     ipc_free_channel(chan);
>
> I think I understand why you have done this, but do you really want to
> request and free every time in the highbank cpufreq driver?
>
Exactly my aim - make the API light enough to enable the client to
use-and-throw. And also because the channel are exclusively assigned,
acquire a channel only for as long as you need it.

cheers.


From mark.langsdorf at calxeda.com  Mon Apr 29 13:06:03 2013
From: mark.langsdorf at calxeda.com (Mark Langsdorf)
Date: Mon, 29 Apr 2013 12:06:03 -0500
Subject: [RFC 3/3] mailbox: pl320: Introduce common API driver
In-Reply-To: <CAJe_ZhcHVAQfPZJ-+upr-78B+MqLw36jTmS8geZpc2=_-gGzGQ@mail.gmail.com>
References: <CAJe_ZhdH+SCs5crguXrm6y-6bu+eGnTqeJS6cOS5H5Yz=m15Cw@mail.gmail.com>
 <1367086496-28647-1-git-send-email-jaswinder.singh@linaro.org>
 <517EA36E.2050106@ti.com>
 <CAJe_ZhcHVAQfPZJ-+upr-78B+MqLw36jTmS8geZpc2=_-gGzGQ@mail.gmail.com>
Message-ID: <517EA87B.9090906@calxeda.com>

On 04/29/2013 11:57 AM, Jassi Brar wrote:
> On 29 April 2013 22:14, Suman Anna <s-anna at ti.com> wrote:
>> On 04/27/2013 01:14 PM, jassisinghbrar at gmail.com wrote:
>>> From: Jassi Brar <jaswinder.singh at linaro.org>
>>> Signed-off-by: Jassi Brar <jaswinder.singh at linaro.org>
>>> ---
>>>  drivers/cpufreq/highbank-cpufreq.c       |   22 +++-
>>>  drivers/mailbox/Makefile                 |    2 +-
>>>  drivers/mailbox/{pl320-ipc.c => pl320.c} |  194 ++++++++++++++++--------------
>>>  include/linux/pl320-ipc.h                |   17 ---
>>>  4 files changed, 125 insertions(+), 110 deletions(-)
>>>  rename drivers/mailbox/{pl320-ipc.c => pl320.c} (51%)
>>>  delete mode 100644 include/linux/pl320-ipc.h
>>>
>>> diff --git a/drivers/cpufreq/highbank-cpufreq.c b/drivers/cpufreq/highbank-cpufreq.c
>>> index 3118b87..5c057e0 100644
>>> --- a/drivers/cpufreq/highbank-cpufreq.c
>>> +++ b/drivers/cpufreq/highbank-cpufreq.c
>>> @@ -19,7 +19,7 @@
>>>  #include <linux/cpu.h>
>>>  #include <linux/err.h>
>>>  #include <linux/of.h>
>>> -#include <linux/pl320-ipc.h>
>>> +#include <linux/mailbox_client.h>
>>>  #include <linux/platform_device.h>
>>>
>>>  #define HB_CPUFREQ_CHANGE_NOTE       0x80000001
>>> @@ -29,8 +29,26 @@
>>>  static int hb_voltage_change(unsigned int freq)
>>>  {
>>>       u32 msg[HB_CPUFREQ_IPC_LEN] = {HB_CPUFREQ_CHANGE_NOTE, freq / 1000000};
>>> +     struct ipc_client cl;
>>> +     int ret = -ETIMEDOUT;
>>> +     void *chan;
>>>
>>> -     return pl320_ipc_transmit(msg);
>>> +     cl.rxcb = NULL;
>>> +     cl.txcb = NULL;
>>> +     cl.tx_block = true;
>>> +     cl.tx_tout = 1000; /* 1 sec */
>>> +     cl.cntlr_data = NULL;
>>> +     cl.knows_txdone = false;
>>> +     cl.chan_name = "pl320:A9_to_M3";
>>> +
>>> +     chan = ipc_request_channel(&cl);
>>> +
>>> +     if (ipc_send_message(chan, (void *)msg))
>>> +             ret = msg[1]; /* PL320 updates buffer with FIFO after ACK */
>>> +
>>> +     ipc_free_channel(chan);
>>
>> I think I understand why you have done this, but do you really want to
>> request and free every time in the highbank cpufreq driver?
>>
> Exactly my aim - make the API light enough to enable the client to
> use-and-throw. And also because the channel are exclusively assigned,
> acquire a channel only for as long as you need it.

Do you have any numbers on the performance impact? Our cpufreq
transition throughput is bad enough without adding additional delays.

--Mark Langsdorf
Calxeda, Inc.



From mturquette at linaro.org  Mon Apr 29 13:26:06 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Mon, 29 Apr 2013 10:26:06 -0700
Subject: [GIT PULL] clk: changes for 3.10
Message-ID: <20130429172606.8923.61396@quantum>

The following changes since commit a937536b868b8369b98967929045f1df54234323:

  Linux 3.9-rc3 (2013-03-17 15:59:32 -0700)

are available in the git repository at:

  git://git.linaro.org/people/mturquette/linux.git tags/clk-for-linus-3.10

for you to fetch changes up to 1e435256d625c203660f0105f1155cd2af283051:

  clk: add clk_ignore_unused option to keep boot clocks on (2013-04-27 23:03:43 -0700)

----------------------------------------------------------------
The common clock framework changes for 3.10 include many fixes for
existing platforms, as well as adoption of the framework by new
platforms and devices.  Some long-needed fixes to the core framework are
here as well as new features such as improved initialization of clocks
from DT as well as framework reentrancy for nested clock operations.

----------------------------------------------------------------
Axel Lin (1):
      clk: mvebu: Fix valid value range checking for cpu_freq_select

Eduardo Valentin (1):
      documentation: clk: fix couple of misspelling

Emilio L?pez (7):
      clk: arm: sunxi: Add a new clock driver for sunxi SOCs
      arm: sunxi: Add useful information about sunxi clocks
      clk: sunxi: rename compatible strings
      clk: sunxi: Add support for AXI, AHB, APB0 and APB1 gates
      clk: sunxi: drop CLK_IGNORE_UNUSED
      clk: sunxi: drop an unnecesary kmalloc
      clk: sunxi: Unify oscillator clock

Fabio Estevam (2):
      clk: mxs: Fix sparse warnings
      ARM: imx: adapt clk_busy_mux to new clk_mux struct

Gregory CLEMENT (1):
      clk: add device tree fixed-factor-clock binding support

James Hogan (1):
      clk: fix clk_mux::flags kerneldoc

Jean-Francois Moine (1):
      clk: mvebu: Use common of_clk_init() function

Lars-Peter Clausen (1):
      clk: Add axi-clkgen driver

Maxime Coquelin (1):
      clk: ux500: Fix prcmu clocks registration

Michal Simek (1):
      clk: zynq: Add missing zynq clk header

Mike Turquette (5):
      clk: abstract locking out into helper functions
      clk: allow reentrant calls into the clk framework
      clk: composite: rename 'div' references to 'rate'
      clk: composite: allow fixed rates & fixed dividers
      clk: ux500: fix mismatched types

Olof Johansson (1):
      clk: add clk_ignore_unused option to keep boot clocks on

Pawel Moll (1):
      clk: vexpress: Add separate SP810 driver

Peter De Schrijver (1):
      clk: add table lookup to mux

Prashant Gaikwad (1):
      clk: Add composite clock type

Sachin Kamat (1):
      clk: Fix incorrect return type in clk.c

Sebastian Hesselbarth (3):
      clk: add si5351 i2c common clock driver
      clk: export __clk_get_flags for modular clock providers
      clk: si5351: make clk-si5351 depend on CONFIG_OF

Soren Brinkmann (2):
      clk: divider: Introduce CLK_DIVIDER_ALLOW_ZERO flag
      clk: Properly handle notifier return values

Tony Prisk (1):
      clk: vt8500: Missing breaks in vtwm_pll_round_rate/_set_rate.

Ulf Hansson (9):
      clk: Introduce optional is_prepared callback
      clk: Unprepare the unused prepared slow clocks at late init
      clk: Introduce optional unprepare_unused callback
      clk: ux500: Support is_prepared callback for clk-prcmu
      clk: Restructure code for __clk_reparent
      clk: Fixup errorhandling for clk_set_parent
      clk: Fixup locking issues for clk_set_parent
      clk: ux500: Add support for sysctrl clocks
      clk: ux500: abx500: Define clock tree for ab850x

Vipul Kumar Samar (1):
      clk:SPEAr1340: Correct parent clock configuration

Wei Yongjun (1):
      clk: prima2: fix return value check in sirfsoc_of_clk_init()

 Documentation/arm/sunxi/clocks.txt                 |   56 +
 Documentation/clk.txt                              |   15 +-
 .../devicetree/bindings/clock/axi-clkgen.txt       |   22 +
 .../bindings/clock/fixed-factor-clock.txt          |   24 +
 .../devicetree/bindings/clock/silabs,si5351.txt    |  114 ++
 Documentation/devicetree/bindings/clock/sunxi.txt  |  151 ++
 .../devicetree/bindings/vendor-prefixes.txt        |    1 +
 Documentation/kernel-parameters.txt                |    8 +
 arch/arm/mach-imx/clk-busy.c                       |    2 +-
 arch/arm/mach-vexpress/v2m.c                       |    8 +-
 drivers/clk/Kconfig                                |   18 +
 drivers/clk/Makefile                               |    4 +
 drivers/clk/clk-axi-clkgen.c                       |  331 +++++
 drivers/clk/clk-composite.c                        |  210 +++
 drivers/clk/clk-divider.c                          |    5 +-
 drivers/clk/clk-fixed-factor.c                     |   36 +
 drivers/clk/clk-mux.c                              |   50 +-
 drivers/clk/clk-prima2.c                           |    2 +-
 drivers/clk/clk-si5351.c                           | 1510 ++++++++++++++++++++
 drivers/clk/clk-si5351.h                           |  155 ++
 drivers/clk/clk-vt8500.c                           |    2 +
 drivers/clk/clk-zynq.c                             |    1 +
 drivers/clk/clk.c                                  |  406 ++++--
 drivers/clk/mvebu/clk-core.c                       |    4 +-
 drivers/clk/mvebu/clk-cpu.c                        |   17 +-
 drivers/clk/mvebu/clk-cpu.h                        |   22 -
 drivers/clk/mvebu/clk.c                            |    6 +-
 drivers/clk/mxs/clk.c                              |    1 +
 drivers/clk/spear/spear1340_clock.c                |   18 +-
 drivers/clk/sunxi/Makefile                         |    5 +
 drivers/clk/sunxi/clk-factors.c                    |  180 +++
 drivers/clk/sunxi/clk-factors.h                    |   27 +
 drivers/clk/sunxi/clk-sunxi.c                      |  469 ++++++
 drivers/clk/tegra/clk.h                            |   27 +-
 drivers/clk/ux500/Makefile                         |    1 +
 drivers/clk/ux500/abx500-clk.c                     |   71 +-
 drivers/clk/ux500/clk-prcmu.c                      |  136 +-
 drivers/clk/ux500/clk-sysctrl.c                    |  221 +++
 drivers/clk/ux500/clk.h                            |   34 +-
 drivers/clk/versatile/Makefile                     |    2 +-
 drivers/clk/versatile/clk-sp810.c                  |  188 +++
 drivers/clk/versatile/clk-vexpress.c               |   49 -
 drivers/clocksource/sunxi_timer.c                  |    4 +-
 include/linux/clk-private.h                        |    2 +-
 include/linux/clk-provider.h                       |   63 +-
 include/linux/clk.h                                |    8 +-
 include/linux/clk/sunxi.h                          |   22 +
 include/linux/platform_data/si5351.h               |  114 ++
 48 files changed, 4518 insertions(+), 304 deletions(-)
 create mode 100644 Documentation/arm/sunxi/clocks.txt
 create mode 100644 Documentation/devicetree/bindings/clock/axi-clkgen.txt
 create mode 100644 Documentation/devicetree/bindings/clock/fixed-factor-clock.txt
 create mode 100644 Documentation/devicetree/bindings/clock/silabs,si5351.txt
 create mode 100644 Documentation/devicetree/bindings/clock/sunxi.txt
 create mode 100644 drivers/clk/clk-axi-clkgen.c
 create mode 100644 drivers/clk/clk-composite.c
 create mode 100644 drivers/clk/clk-si5351.c
 create mode 100644 drivers/clk/clk-si5351.h
 delete mode 100644 drivers/clk/mvebu/clk-cpu.h
 create mode 100644 drivers/clk/sunxi/Makefile
 create mode 100644 drivers/clk/sunxi/clk-factors.c
 create mode 100644 drivers/clk/sunxi/clk-factors.h
 create mode 100644 drivers/clk/sunxi/clk-sunxi.c
 create mode 100644 drivers/clk/ux500/clk-sysctrl.c
 create mode 100644 drivers/clk/versatile/clk-sp810.c
 create mode 100644 include/linux/clk/sunxi.h
 create mode 100644 include/linux/platform_data/si5351.h


From davem at davemloft.net  Mon Apr 29 13:27:08 2013
From: davem at davemloft.net (David Miller)
Date: Mon, 29 Apr 2013 13:27:08 -0400 (EDT)
Subject: [PATCH v2 05/21] atm: he: use msleep instead of large udelay
 constants
In-Reply-To: <201304291513.27104.arnd@arndb.de>
References: <AE90C24D6B3A694183C094C60CF0A2F6026B7203@saturn3.aculab.com>
 <20130426091220.468cf59e@thirdoffive.cmf.nrl.navy.mil>
 <201304291513.27104.arnd@arndb.de>
Message-ID: <20130429.132708.1188315001953129841.davem@davemloft.net>

From: Arnd Bergmann <arnd at arndb.de>
Date: Mon, 29 Apr 2013 15:13:26 +0200

> From a0ddf082821b064cc2d6a9bb90861f9b81a559a5 Mon Sep 17 00:00:00 2001
> From: Arnd Bergmann <arnd at arndb.de>
> Date: Thu, 14 Mar 2013 15:21:36 +0100
> Subject: [PATCH] atm: he: use mdelay instead of large udelay constants
> 
> ARM cannot handle udelay for more than 2 miliseconds, and
> it is rather bad style to block the cpu for 16ms anyway,
> so let's use msleep instead.
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>

Applied, thanks.


From jaswinder.singh at linaro.org  Mon Apr 29 13:28:23 2013
From: jaswinder.singh at linaro.org (Jassi Brar)
Date: Mon, 29 Apr 2013 22:58:23 +0530
Subject: [RFC 3/3] mailbox: pl320: Introduce common API driver
In-Reply-To: <517EA87B.9090906@calxeda.com>
References: <CAJe_ZhdH+SCs5crguXrm6y-6bu+eGnTqeJS6cOS5H5Yz=m15Cw@mail.gmail.com>
 <1367086496-28647-1-git-send-email-jaswinder.singh@linaro.org>
 <517EA36E.2050106@ti.com>
 <CAJe_ZhcHVAQfPZJ-+upr-78B+MqLw36jTmS8geZpc2=_-gGzGQ@mail.gmail.com>
 <517EA87B.9090906@calxeda.com>
Message-ID: <CAJe_Zhe6=8F=HPZPw1xkDbuyALHK6iwJ-uZKq50yE7vQ6Bp4BQ@mail.gmail.com>

On 29 April 2013 22:36, Mark Langsdorf <mark.langsdorf at calxeda.com> wrote:
> On 04/29/2013 11:57 AM, Jassi Brar wrote:
>> On 29 April 2013 22:14, Suman Anna <s-anna at ti.com> wrote:
>>> On 04/27/2013 01:14 PM, jassisinghbrar at gmail.com wrote:
>>>> From: Jassi Brar <jaswinder.singh at linaro.org>
>>>> Signed-off-by: Jassi Brar <jaswinder.singh at linaro.org>
>>>> ---
>>>>  drivers/cpufreq/highbank-cpufreq.c       |   22 +++-
>>>>  drivers/mailbox/Makefile                 |    2 +-
>>>>  drivers/mailbox/{pl320-ipc.c => pl320.c} |  194 ++++++++++++++++--------------
>>>>  include/linux/pl320-ipc.h                |   17 ---
>>>>  4 files changed, 125 insertions(+), 110 deletions(-)
>>>>  rename drivers/mailbox/{pl320-ipc.c => pl320.c} (51%)
>>>>  delete mode 100644 include/linux/pl320-ipc.h
>>>>
>>>> diff --git a/drivers/cpufreq/highbank-cpufreq.c b/drivers/cpufreq/highbank-cpufreq.c
>>>> index 3118b87..5c057e0 100644
>>>> --- a/drivers/cpufreq/highbank-cpufreq.c
>>>> +++ b/drivers/cpufreq/highbank-cpufreq.c
>>>> @@ -19,7 +19,7 @@
>>>>  #include <linux/cpu.h>
>>>>  #include <linux/err.h>
>>>>  #include <linux/of.h>
>>>> -#include <linux/pl320-ipc.h>
>>>> +#include <linux/mailbox_client.h>
>>>>  #include <linux/platform_device.h>
>>>>
>>>>  #define HB_CPUFREQ_CHANGE_NOTE       0x80000001
>>>> @@ -29,8 +29,26 @@
>>>>  static int hb_voltage_change(unsigned int freq)
>>>>  {
>>>>       u32 msg[HB_CPUFREQ_IPC_LEN] = {HB_CPUFREQ_CHANGE_NOTE, freq / 1000000};
>>>> +     struct ipc_client cl;
>>>> +     int ret = -ETIMEDOUT;
>>>> +     void *chan;
>>>>
>>>> -     return pl320_ipc_transmit(msg);
>>>> +     cl.rxcb = NULL;
>>>> +     cl.txcb = NULL;
>>>> +     cl.tx_block = true;
>>>> +     cl.tx_tout = 1000; /* 1 sec */
>>>> +     cl.cntlr_data = NULL;
>>>> +     cl.knows_txdone = false;
>>>> +     cl.chan_name = "pl320:A9_to_M3";
>>>> +
>>>> +     chan = ipc_request_channel(&cl);
>>>> +
>>>> +     if (ipc_send_message(chan, (void *)msg))
>>>> +             ret = msg[1]; /* PL320 updates buffer with FIFO after ACK */
>>>> +
>>>> +     ipc_free_channel(chan);
>>>
>>> I think I understand why you have done this, but do you really want to
>>> request and free every time in the highbank cpufreq driver?
>>>
>> Exactly my aim - make the API light enough to enable the client to
>> use-and-throw. And also because the channel are exclusively assigned,
>> acquire a channel only for as long as you need it.
>
> Do you have any numbers on the performance impact? Our cpufreq
> transition throughput is bad enough without adding additional delays.
>
Sorry no numbers.
However if you look closely you'll find for your usecase the message
directly reaches the controller and the reply from remote is directly
handed to your client driver. And since there is no context for
channel on your platform channel request/free shouldn't fail either
(or you could keep the channel allocated for the lifetime of the
client driver). So I would not expect any longer delays than the
original way.
 Compared with TI's framework of RX-via-notifier you should be better
off with this API, imho.

cheers.


From jason at lakedaemon.net  Mon Apr 29 13:30:22 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Mon, 29 Apr 2013 13:30:22 -0400
Subject: [PATCH] Kirkwood: Enable PCIe port 1 on QNAP TS-11x/TS-21x
In-Reply-To: <20130421161400.GD26943@jirafa.cyrius.com>
References: <20130421152802.GA1408@jirafa.cyrius.com>
 <20130421154704.GV2824@lunn.ch>
 <20130421161400.GD26943@jirafa.cyrius.com>
Message-ID: <20130429173022.GS32497@titan.lakedaemon.net>

On Sun, Apr 21, 2013 at 05:14:00PM +0100, Martin Michlmayr wrote:
> Enable KW_PCIE1 on QNAP TS-11x/TS-21x devices as newer revisions
> (rev 1.3) have a USB 3.0 chip from Etron on PCIe port 1.  Thanks
> to Marek Vasut for identifying this issue!
> 
> Cc: <stable at kernel.org>
> Signed-off-by: Martin Michlmayr <tbm at cyrius.com>
> Tested-by: Marek Vasut <marex at denx.de>

Applied to mvebu-next/fixes.  This branch will be rebased onto v3.10-rc1
once it drops.  I'll submit a pull request then.

fyi: looks like this can be applied to stable all the way back to
v2.6.36.x, updated stable tag accordingly.

thx,

Jason.


From catalin.marinas at arm.com  Mon Apr 29 13:35:21 2013
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Mon, 29 Apr 2013 18:35:21 +0100
Subject: [PATCH v3 08/32] arm64: KVM: architecture specific MMU backend
In-Reply-To: <1365437854-30214-9-git-send-email-marc.zyngier@arm.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
 <1365437854-30214-9-git-send-email-marc.zyngier@arm.com>
Message-ID: <20130429173521.GB16544@arm.com>

On Mon, Apr 08, 2013 at 05:17:10PM +0100, Marc Zyngier wrote:
> diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h
> new file mode 100644
> index 0000000..2eb2230
> --- /dev/null
> +++ b/arch/arm64/include/asm/kvm_mmu.h
...
> +/*
> + * Align KVM with the kernel's view of physical memory. Should be
> + * 40bit IPA, with PGD being 8kB aligned.
> + */
> +#define KVM_PHYS_SHIFT	PHYS_MASK_SHIFT

Just wondering - do we allow the IPA to be bigger than what qemu/kvmtool
can map?

> +#define KVM_PHYS_SIZE	(1UL << KVM_PHYS_SHIFT)
> +#define KVM_PHYS_MASK	(KVM_PHYS_SIZE - 1UL)
> +
> +#ifdef CONFIG_ARM64_64K_PAGES
> +#define PAGE_LEVELS	2
> +#define BITS_PER_LEVEL	13
> +#else  /* 4kB pages */
> +#define PAGE_LEVELS	3
> +#define BITS_PER_LEVEL	9

You could use (PAGE_SHIFT - 3) for BITS_PER_LEVEL if that's any clearer
but you can get rid of these entirely (see below).

> +#endif
> +
> +/* Make sure we get the right size, and thus the right alignment */
> +#define BITS_PER_S2_PGD (KVM_PHYS_SHIFT - (PAGE_LEVELS - 1) * BITS_PER_LEVEL - PAGE_SHIFT)
> +#define PTRS_PER_S2_PGD (1 << max(BITS_PER_LEVEL, BITS_PER_S2_PGD))
> +#define S2_PGD_ORDER	get_order(PTRS_PER_S2_PGD * sizeof(pgd_t))
> +#define S2_PGD_SIZE	(1 << S2_PGD_ORDER)

It looks like lots of calculations which I can't fully follow ;). So we
need to map KVM_PHYS_SHIFT (40-bit) with a number of stage 2 pgds. We
know that a pgd entry can map PGDIR_SHIFT bits. So the pointers you need
in S2 pgd:

#define PTRS_PER_S2_PGD		(1 << (KVM_PHYS_SHIFT - PGDIR_SHIFT))

(no need of PAGE_LEVELS)

With some more juggling you can probably get rid of get_order as well,
though it should be a compile-time constant. Basically KVM_PHYS_SHIFT -
PGDIR_SHIFT - PAGE_SHIFT + 3 (and cope with the negative value for the
64K pages).

> +static inline void coherent_icache_guest_page(struct kvm *kvm, gfn_t gfn)
> +{
> +	unsigned long hva = gfn_to_hva(kvm, gfn);
> +	flush_icache_range(hva, hva + PAGE_SIZE);

Even ARMv8 can have aliasing VIPT I-cache. Do we need to flush some more
here?

> +#define kvm_flush_dcache_to_poc(a,l)	__flush_dcache_area((a), (l))

I had a brief look at the other hyp reworking patches and this function
is used in two situations: (1) flush any data before the Hyp is
initialised and (2) page table creation. The first case looks fine but
the second is not needed on AArch64 (and SMP AArch32) nor entirely
optimal as it should flush to PoU for page table walks. Can we have
different functions, at least we can make one a no-op?

-- 
Catalin


From andrew at lunn.ch  Mon Apr 29 14:03:38 2013
From: andrew at lunn.ch (Andrew Lunn)
Date: Mon, 29 Apr 2013 20:03:38 +0200
Subject: [PATCH] Kirkwood: Enable PCIe port 1 on QNAP TS-11x/TS-21x
In-Reply-To: <20130429173022.GS32497@titan.lakedaemon.net>
References: <20130421152802.GA1408@jirafa.cyrius.com>
 <20130421154704.GV2824@lunn.ch>
 <20130421161400.GD26943@jirafa.cyrius.com>
 <20130429173022.GS32497@titan.lakedaemon.net>
Message-ID: <20130429180338.GE16725@lunn.ch>

On Mon, Apr 29, 2013 at 01:30:22PM -0400, Jason Cooper wrote:
> On Sun, Apr 21, 2013 at 05:14:00PM +0100, Martin Michlmayr wrote:
> > Enable KW_PCIE1 on QNAP TS-11x/TS-21x devices as newer revisions
> > (rev 1.3) have a USB 3.0 chip from Etron on PCIe port 1.  Thanks
> > to Marek Vasut for identifying this issue!
> > 
> > Cc: <stable at kernel.org>
> > Signed-off-by: Martin Michlmayr <tbm at cyrius.com>
> > Tested-by: Marek Vasut <marex at denx.de>
> 
> Applied to mvebu-next/fixes.  This branch will be rebased onto v3.10-rc1
> once it drops.  I'll submit a pull request then.
> 
> fyi: looks like this can be applied to stable all the way back to
> v2.6.36.x, updated stable tag accordingly.

Hi Jason

Once we have v3.10-rc1 with the DT PCI patches, i will also make an
update to them to enable both PCI ports where available.

We should also change the kirkwood_defconfig to enable the PCI USB
3.0. driver. I can do that as well.

       Andrew


From jason at lakedaemon.net  Mon Apr 29 14:24:07 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Mon, 29 Apr 2013 14:24:07 -0400
Subject: [PATCH] Kirkwood: Enable PCIe port 1 on QNAP TS-11x/TS-21x
In-Reply-To: <20130429180338.GE16725@lunn.ch>
References: <20130421152802.GA1408@jirafa.cyrius.com>
 <20130421154704.GV2824@lunn.ch>
 <20130421161400.GD26943@jirafa.cyrius.com>
 <20130429173022.GS32497@titan.lakedaemon.net>
 <20130429180338.GE16725@lunn.ch>
Message-ID: <20130429182407.GT32497@titan.lakedaemon.net>

On Mon, Apr 29, 2013 at 08:03:38PM +0200, Andrew Lunn wrote:
> On Mon, Apr 29, 2013 at 01:30:22PM -0400, Jason Cooper wrote:
> > On Sun, Apr 21, 2013 at 05:14:00PM +0100, Martin Michlmayr wrote:
> > > Enable KW_PCIE1 on QNAP TS-11x/TS-21x devices as newer revisions
> > > (rev 1.3) have a USB 3.0 chip from Etron on PCIe port 1.  Thanks
> > > to Marek Vasut for identifying this issue!
> > > 
> > > Cc: <stable at kernel.org>
> > > Signed-off-by: Martin Michlmayr <tbm at cyrius.com>
> > > Tested-by: Marek Vasut <marex at denx.de>
> > 
> > Applied to mvebu-next/fixes.  This branch will be rebased onto v3.10-rc1
> > once it drops.  I'll submit a pull request then.
> > 
> > fyi: looks like this can be applied to stable all the way back to
> > v2.6.36.x, updated stable tag accordingly.
> 
> Hi Jason
> 
> Once we have v3.10-rc1 with the DT PCI patches, i will also make an
> update to them to enable both PCI ports where available.
> 
> We should also change the kirkwood_defconfig to enable the PCI USB
> 3.0. driver. I can do that as well.

Great!  That'll wrap up the other half of the first version of this
patch.

thx,

Jason.


From balbi at ti.com  Mon Apr 29 14:24:41 2013
From: balbi at ti.com (Felipe Balbi)
Date: Mon, 29 Apr 2013 21:24:41 +0300
Subject: [V9 PATCH 01/12] usb: phy: protect phy init and shutdown for
 mutiple deivces
In-Reply-To: <1366784606-1813-2-git-send-email-chao.xie@marvell.com>
References: <1366784606-1813-1-git-send-email-chao.xie@marvell.com>
 <1366784606-1813-2-git-send-email-chao.xie@marvell.com>
Message-ID: <20130429182441.GA1632@arwen.pp.htv.fi>

On Wed, Apr 24, 2013 at 02:23:15AM -0400, Chao Xie wrote:
> diff --git a/include/linux/usb/phy.h b/include/linux/usb/phy.h
> index 6b5978f..98d7e60 100644
> --- a/include/linux/usb/phy.h
> +++ b/include/linux/usb/phy.h
> @@ -87,6 +87,14 @@ struct usb_phy {
>  	/* to support controllers that have multiple transceivers */
>  	struct list_head	head;
>  
> +	/*
> +	 * PHY may be shared by multiple devices.
> +	 * mutex and refcount are used to make sure PHY only initialize or
> +	 * shutdown once.

bad grammar in this sentence.

> +	 */
> +	struct mutex		phy_mutex;
> +	unsigned int		refcount;

why don't you use an atomic_t ?

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130429/810dec42/attachment.sig>

From davem at davemloft.net  Mon Apr 29 15:15:28 2013
From: davem at davemloft.net (David Miller)
Date: Mon, 29 Apr 2013 15:15:28 -0400 (EDT)
Subject: [PATCHv2 0/3] Add support for velocity network driver on
 platform devices
In-Reply-To: <1367221841-14563-1-git-send-email-linux@prisktech.co.nz>
References: <1367221841-14563-1-git-send-email-linux@prisktech.co.nz>
Message-ID: <20130429.151528.2251094691456287740.davem@davemloft.net>


You prepared these patches against a net-next tree which is at least
a week old, I know this because that's when the NETIF_F_* flags for
VLAN offloading changed their names which causes your third patch
to fail to apply.

Do not do this, net-next changes every day and rapidly, don't take
the chance that the driver you're touching is unpopular and thus
hasn't had changes to it recently.  Tree-wide interface changes
happen all the time.


From linux at prisktech.co.nz  Mon Apr 29 15:19:02 2013
From: linux at prisktech.co.nz (Tony Prisk)
Date: Tue, 30 Apr 2013 07:19:02 +1200
Subject: [PATCHv2 0/3] Add support for velocity network driver on platform
 devices
In-Reply-To: <20130429.151528.2251094691456287740.davem@davemloft.net>
References: <1367221841-14563-1-git-send-email-linux@prisktech.co.nz>
 <20130429.151528.2251094691456287740.davem@davemloft.net>
Message-ID: <517EC7A6.9030204@prisktech.co.nz>

On 30/04/13 07:15, David Miller wrote:
> You prepared these patches against a net-next tree which is at least
> a week old, I know this because that's when the NETIF_F_* flags for
> VLAN offloading changed their names which causes your third patch
> to fail to apply.
>
> Do not do this, net-next changes every day and rapidly, don't take
> the chance that the driver you're touching is unpopular and thus
> hasn't had changes to it recently.  Tree-wide interface changes
> happen all the time.
Apologies - I didn't realise. These patches are based against 3.8-rc8.
I will rebase against net-next and resend.

Regards
Tony P


From linux at arm.linux.org.uk  Mon Apr 29 15:26:04 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Mon, 29 Apr 2013 20:26:04 +0100
Subject: [V9 PATCH 01/12] usb: phy: protect phy init and shutdown for
 mutiple deivces
In-Reply-To: <20130429182441.GA1632@arwen.pp.htv.fi>
References: <1366784606-1813-1-git-send-email-chao.xie@marvell.com>
 <1366784606-1813-2-git-send-email-chao.xie@marvell.com>
 <20130429182441.GA1632@arwen.pp.htv.fi>
Message-ID: <20130429192604.GL14496@n2100.arm.linux.org.uk>

On Mon, Apr 29, 2013 at 09:24:41PM +0300, Felipe Balbi wrote:
> On Wed, Apr 24, 2013 at 02:23:15AM -0400, Chao Xie wrote:
> > diff --git a/include/linux/usb/phy.h b/include/linux/usb/phy.h
> > index 6b5978f..98d7e60 100644
> > --- a/include/linux/usb/phy.h
> > +++ b/include/linux/usb/phy.h
> > @@ -87,6 +87,14 @@ struct usb_phy {
> >  	/* to support controllers that have multiple transceivers */
> >  	struct list_head	head;
> >  
> > +	/*
> > +	 * PHY may be shared by multiple devices.
> > +	 * mutex and refcount are used to make sure PHY only initialize or
> > +	 * shutdown once.
> 
> bad grammar in this sentence.
> 
> > +	 */
> > +	struct mutex		phy_mutex;
> > +	unsigned int		refcount;
> 
> why don't you use an atomic_t ?

Possibly because of this:

+       mutex_lock(&x->phy_mutex);                                              
+       if (x->refcount++ == 0 && x->init)                                      
+               ret = x->init(x);                                               
+       mutex_unlock(&x->phy_mutex);                                            

This code structure has the effect that with two concurrent callers, one
will be blocked while the other calls the init function, and both will
not pass until the init function has completed.

Using an atomic type does not provide that guarantee.  Consider:

	if (atomic_inc_return(&x->atomic) == 1 && x->init)
		ret = x->init(x);

when two concurrent callers occur.  Or even consider one caller to the
shutdown function and another which comes into the init path while the
shutdown function is still running.

Atomic types are all well and good but they are also horrendously
dangerous when abused in ways like you're suggesting.


From sebastian.hesselbarth at gmail.com  Mon Apr 29 15:26:52 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Mon, 29 Apr 2013 21:26:52 +0200
Subject: [PATCH RESEND] ARM: dove: fix Dove cpu type from V7 to PJ4
In-Reply-To: <1364051211-24414-1-git-send-email-sebastian.hesselbarth@gmail.com>
References: <1364051211-24414-1-git-send-email-sebastian.hesselbarth@gmail.com>
Message-ID: <1367263612-17596-1-git-send-email-sebastian.hesselbarth@gmail.com>

The CPU used in Marvell Dove SoCs is a PJ4 Sheeva core. Using
CONFIG_CPU_PJ4 instead of CONFIG_CPU_V7 will enable iWMMXt
extensions on Dove.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
Acked-by: Jason Cooper <jason at lakedaemon.net>
Acked-by: Andrew Lunn <andrew at lunn.ch>
---
Note: This patch is rebased on v3.9 and patch message has been modified
to point out that iWMMXt is now enforced on CPU_PJ4.

Cc: Jason Cooper <jason at lakedaemon.net>
Cc: Andrew Lunn <andrew at lunn.ch>
Cc: Russell King <linux at arm.linux.org.uk>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
---
 arch/arm/Kconfig |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 1cacda4..3c5e4da 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -555,7 +555,7 @@ config ARCH_IXP4XX
 config ARCH_DOVE
 	bool "Marvell Dove"
 	select ARCH_REQUIRE_GPIOLIB
-	select CPU_V7
+	select CPU_PJ4
 	select GENERIC_CLOCKEVENTS
 	select MIGHT_HAVE_PCI
 	select PINCTRL
-- 
1.7.10.4



From maxime.ripard at free-electrons.com  Mon Apr 29 15:36:56 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Mon, 29 Apr 2013 21:36:56 +0200
Subject: [PATCH 4/6] ARM: sunxi: Add EMAC controller node to sun4i DTSI
In-Reply-To: <1367264218-15235-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1367264218-15235-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1367264218-15235-5-git-send-email-maxime.ripard@free-electrons.com>

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 arch/arm/boot/dts/sun4i-a10.dtsi | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/arch/arm/boot/dts/sun4i-a10.dtsi b/arch/arm/boot/dts/sun4i-a10.dtsi
index ff1f41f..983da33 100644
--- a/arch/arm/boot/dts/sun4i-a10.dtsi
+++ b/arch/arm/boot/dts/sun4i-a10.dtsi
@@ -163,6 +163,22 @@
 		reg = <0x01c20000 0x300000>;
 		ranges;
 
+		emac: ethernet at 01c0b000 {
+			compatible = "allwinner,sun4i-emac";
+			reg = <0x01c0b000 0x1000>;
+			interrupts = <55>;
+			clocks = <&ahb_gates 17>;
+			status = "disabled";
+		};
+
+		mdio at 01c0b080 {
+			compatible = "allwinner,sun4i-mdio";
+			reg = <0x01c0b080 0x14>;
+			status = "disabled";
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+
 		intc: interrupt-controller at 01c20400 {
 			compatible = "allwinner,sun4i-ic";
 			reg = <0x01c20400 0x400>;
-- 
1.8.1.2



From maxime.ripard at free-electrons.com  Mon Apr 29 15:36:55 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Mon, 29 Apr 2013 21:36:55 +0200
Subject: [PATCH 3/6] ARM: sun4i: Add muxing options for the ethernet controller
In-Reply-To: <1367264218-15235-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1367264218-15235-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1367264218-15235-4-git-send-email-maxime.ripard@free-electrons.com>

The EMAC only has one pinset available for muxing, so hopefully, we
cover all cases.

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 arch/arm/boot/dts/sun4i-a10.dtsi | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/boot/dts/sun4i-a10.dtsi b/arch/arm/boot/dts/sun4i-a10.dtsi
index e7ef619..ff1f41f 100644
--- a/arch/arm/boot/dts/sun4i-a10.dtsi
+++ b/arch/arm/boot/dts/sun4i-a10.dtsi
@@ -199,6 +199,17 @@
 				allwinner,drive = <0>;
 				allwinner,pull = <0>;
 			};
+
+			emac_pins_a: emac0 at 0 {
+				allwinner,pins = "PA0", "PA1", "PA2",
+						"PA3", "PA4", "PA5", "PA6",
+						"PA7", "PA8", "PA9", "PA10",
+						"PA11", "PA12", "PA13", "PA14",
+						"PA15", "PA16";
+				allwinner,function = "emac";
+				allwinner,drive = <0>;
+				allwinner,pull = <0>;
+			};
 		};
 
 		timer at 01c20c00 {
-- 
1.8.1.2



From maxime.ripard at free-electrons.com  Mon Apr 29 15:36:52 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Mon, 29 Apr 2013 21:36:52 +0200
Subject: [PATCHv3 0/6] ARM: sunxi: Add support for A10 Ethernet controller
Message-ID: <1367264218-15235-1-git-send-email-maxime.ripard@free-electrons.com>

Hi,

The Allwinner A10 SoC has an ethernet controller that seem to be specific to
Allwinner. This IP has no public documentation, so exact
details are quite sparse, and this code come from refactored Allwinner
code.

Since we don't have any clock support yet for the Allwinner SoCs, we
rely on the bootloader to enable and gate the EMAC clock.

The rework to use NAPI is taking more time than expected, I'm still working
on it, but it could probably be sent as a follow-up patch.

Thanks,
Maxime

Changes from v2:
  - Split the MDIO controller to a separate driver and make use of standards
    device tree bindings
  - Fixed various minor things as suggested by Florian Fainelli

Changes from v1:
  - Use phylib for the phy-related functions
  - Use an optional regulator to power up the phy
  - Rename the driver from Davicom Wemac to Allwinner EMAC, since it's the name
    mentionned in the datasheet, and we have no strong evidence of a
    relationship with Davicom
  - Fix various small things around the driver: add defines for undocumented
    values, fix documentation name and compatible example, etc.


Maxime Ripard (4):
  net: Add MDIO bus driver for the Allwinner EMAC
  ARM: sun4i: Add muxing options for the ethernet controller
  ARM: sunxi: Add EMAC controller node to sun4i DTSI
  ARM: sunxi: Add EMAC Controller to Hackberry dt

Stefan Roese (2):
  net: Add EMAC ethernet driver found on Allwinner A10 SoC's
  ARM: cubieboard: Enable ethernet (EMAC) support in dts

 .../bindings/net/allwinner,sun4i-emac.txt          |  22 +
 .../bindings/net/allwinner,sun4i-mdio.txt          |  26 +
 arch/arm/boot/dts/sun4i-a10-cubieboard.dts         |  15 +
 arch/arm/boot/dts/sun4i-a10-hackberry.dts          |  41 +
 arch/arm/boot/dts/sun4i-a10.dtsi                   |  27 +
 drivers/net/ethernet/Kconfig                       |   1 +
 drivers/net/ethernet/Makefile                      |   1 +
 drivers/net/ethernet/allwinner/Kconfig             |  44 +
 drivers/net/ethernet/allwinner/Makefile            |   6 +
 drivers/net/ethernet/allwinner/sun4i-emac.c        | 960 +++++++++++++++++++++
 drivers/net/ethernet/allwinner/sun4i-emac.h        | 108 +++
 drivers/net/ethernet/allwinner/sun4i-mdio.c        | 191 ++++
 12 files changed, 1442 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/net/allwinner,sun4i-emac.txt
 create mode 100644 Documentation/devicetree/bindings/net/allwinner,sun4i-mdio.txt
 create mode 100644 drivers/net/ethernet/allwinner/Kconfig
 create mode 100644 drivers/net/ethernet/allwinner/Makefile
 create mode 100644 drivers/net/ethernet/allwinner/sun4i-emac.c
 create mode 100644 drivers/net/ethernet/allwinner/sun4i-emac.h
 create mode 100644 drivers/net/ethernet/allwinner/sun4i-mdio.c

-- 
1.8.1.2



From maxime.ripard at free-electrons.com  Mon Apr 29 15:36:54 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Mon, 29 Apr 2013 21:36:54 +0200
Subject: [PATCH 2/6] net: Add MDIO bus driver for the Allwinner EMAC
In-Reply-To: <1367264218-15235-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1367264218-15235-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1367264218-15235-3-git-send-email-maxime.ripard@free-electrons.com>

This patch adds a separate driver for the MDIO interface of the
Allwinner ethernet controllers.

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 .../bindings/net/allwinner,sun4i-mdio.txt          |  26 +++
 drivers/net/ethernet/allwinner/Kconfig             |   8 +
 drivers/net/ethernet/allwinner/Makefile            |   1 +
 drivers/net/ethernet/allwinner/sun4i-mdio.c        | 191 +++++++++++++++++++++
 4 files changed, 226 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/net/allwinner,sun4i-mdio.txt
 create mode 100644 drivers/net/ethernet/allwinner/sun4i-mdio.c

diff --git a/Documentation/devicetree/bindings/net/allwinner,sun4i-mdio.txt b/Documentation/devicetree/bindings/net/allwinner,sun4i-mdio.txt
new file mode 100644
index 0000000..00b9f9a
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/allwinner,sun4i-mdio.txt
@@ -0,0 +1,26 @@
+* Allwinner A10 MDIO Ethernet Controller interface
+
+Required properties:
+- compatible: should be "allwinner,sun4i-mdio".
+- reg: address and length of the register set for the device.
+
+Optional properties:
+- phy-supply: phandle to a regulator if the PHY needs one
+
+Example at the SoC level:
+mdio at 01c0b080 {
+	compatible = "allwinner,sun4i-mdio";
+	reg = <0x01c0b080 0x14>;
+	#address-cells = <1>;
+	#size-cells = <0>;
+};
+
+And at the board level:
+
+mdio at 01c0b080 {
+	phy-supply = <&reg_emac_3v3>;
+
+	phy0: ethernet-phy at 0 {
+		reg = <0>;
+	};
+};
diff --git a/drivers/net/ethernet/allwinner/Kconfig b/drivers/net/ethernet/allwinner/Kconfig
index 5d20fb0..7bbd500 100644
--- a/drivers/net/ethernet/allwinner/Kconfig
+++ b/drivers/net/ethernet/allwinner/Kconfig
@@ -27,10 +27,18 @@ config SUN4I_EMAC
 	select NET_CORE
 	select MII
 	select REGULATOR_FIXED_VOLTAGE
+	select PHYLIB
         ---help---
           Support for Allwinner A10 EMAC ethernet driver.
 
           To compile this driver as a module, choose M here.  The module
           will be called sun4i-emac.
 
+config SUN4I_MDIO
+	tristate "Allwinner sun4i MDIO interface support"
+	---help---
+	  This driver supports the MDIO interface found in the network
+	  interface units of the Allwinner SoC that have an EMAC (A10,
+	  A12, A10s, etc.)
+
 endif # NET_VENDOR_ALLWINNER
diff --git a/drivers/net/ethernet/allwinner/Makefile b/drivers/net/ethernet/allwinner/Makefile
index 03129f7..95eaa31 100644
--- a/drivers/net/ethernet/allwinner/Makefile
+++ b/drivers/net/ethernet/allwinner/Makefile
@@ -3,3 +3,4 @@
 #
 
 obj-$(CONFIG_SUN4I_EMAC) += sun4i-emac.o
+obj-$(CONFIG_SUN4I_MDIO) += sun4i-mdio.o
\ No newline at end of file
diff --git a/drivers/net/ethernet/allwinner/sun4i-mdio.c b/drivers/net/ethernet/allwinner/sun4i-mdio.c
new file mode 100644
index 0000000..00e432c
--- /dev/null
+++ b/drivers/net/ethernet/allwinner/sun4i-mdio.c
@@ -0,0 +1,191 @@
+/*
+ * Allwinner EMAC MDIO interface driver
+ *
+ * Copyright 2012-2013 Stefan Roese <sr at denx.de>
+ * Copyright 2013 Maxime Ripard <maxime.ripard at free-electrons.com>
+ *
+ * Based on the Linux driver provided by Allwinner:
+ * Copyright (C) 1997  Sten Wang
+ *
+ * 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/delay.h>
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/of_address.h>
+#include <linux/of_mdio.h>
+#include <linux/phy.h>
+#include <linux/platform_device.h>
+#include <linux/regulator/consumer.h>
+
+#define EMAC_MAC_MCMD_REG	(0x00)
+#define EMAC_MAC_MADR_REG	(0x04)
+#define EMAC_MAC_MWTD_REG	(0x08)
+#define EMAC_MAC_MRDD_REG	(0x0c)
+#define EMAC_MAC_MIND_REG	(0x10)
+#define EMAC_MAC_SSRR_REG	(0x14)
+
+#define MDIO_TIMEOUT		(msecs_to_jiffies(100))
+
+struct sun4i_mdio_data {
+	void __iomem		*membase;
+	struct regulator	*regulator;
+};
+
+static int sun4i_mdio_read(struct mii_bus *bus, int mii_id, int regnum)
+{
+	struct sun4i_mdio_data *data = bus->priv;
+	unsigned long start_jiffies;
+	int value;
+
+	/* issue the phy address and reg */
+	writel((mii_id << 8) | regnum, data->membase + EMAC_MAC_MADR_REG);
+	/* pull up the phy io line */
+	writel(0x1, data->membase + EMAC_MAC_MCMD_REG);
+
+	/* Wait read complete */
+	start_jiffies = jiffies;
+	while (readl(data->membase + EMAC_MAC_MIND_REG) & 0x1) {
+		if (time_after(start_jiffies,
+			       start_jiffies + MDIO_TIMEOUT))
+			return -ETIMEDOUT;
+		msleep(1);
+	}
+
+	/* push down the phy io line */
+	writel(0x0, data->membase + EMAC_MAC_MCMD_REG);
+	/* and read data */
+	value = readl(data->membase + EMAC_MAC_MRDD_REG);
+
+	return value;
+}
+
+static int sun4i_mdio_write(struct mii_bus *bus, int mii_id, int regnum,
+			    u16 value)
+{
+	struct sun4i_mdio_data *data = bus->priv;
+	unsigned long start_jiffies;
+
+	/* issue the phy address and reg */
+	writel((mii_id << 8) | regnum, data->membase + EMAC_MAC_MADR_REG);
+	/* pull up the phy io line */
+	writel(0x1, data->membase + EMAC_MAC_MCMD_REG);
+
+	/* Wait read complete */
+	start_jiffies = jiffies;
+	while (readl(data->membase + EMAC_MAC_MIND_REG) & 0x1) {
+		if (time_after(start_jiffies,
+			       start_jiffies + MDIO_TIMEOUT))
+			return -ETIMEDOUT;
+		msleep(1);
+	}
+
+	/* push down the phy io line */
+	writel(0x0, data->membase + EMAC_MAC_MCMD_REG);
+	/* and write data */
+	writel(value, data->membase + EMAC_MAC_MWTD_REG);
+
+	return 0;
+}
+
+static int sun4i_mdio_reset(struct mii_bus *bus)
+{
+	return 0;
+}
+
+static int sun4i_mdio_probe(struct platform_device *pdev)
+{
+	struct device_node *np = pdev->dev.of_node;
+	struct mii_bus *bus;
+	struct sun4i_mdio_data *data;
+	int ret, i;
+
+	bus = mdiobus_alloc_size(sizeof(*data));
+	if (!bus)
+		return -ENOMEM;
+
+	bus->name = "sun4i_mii_bus";
+	bus->read = &sun4i_mdio_read;
+	bus->write = &sun4i_mdio_write;
+	bus->reset = &sun4i_mdio_reset;
+	snprintf(bus->id, MII_BUS_ID_SIZE, "%s-mii", dev_name(&pdev->dev));
+	bus->parent = &pdev->dev;
+
+	bus->irq = kmalloc(sizeof(int) * PHY_MAX_ADDR, GFP_KERNEL);
+	if (!bus->irq) {
+		ret = -ENOMEM;
+		goto err_out_free_mdiobus;
+	}
+
+	for (i = 0; i < PHY_MAX_ADDR; i++)
+		bus->irq[i] = PHY_POLL;
+
+	data = bus->priv;
+	data->membase = of_iomap(np, 0);
+	if (!data->membase) {
+		ret = -ENOMEM;
+		goto err_out_free_mdio_irq;
+	}
+
+	data->regulator = devm_regulator_get(&pdev->dev, "phy");
+	if (IS_ERR(data->regulator)) {
+		if (PTR_ERR(data->regulator) == -EPROBE_DEFER)
+			return -EPROBE_DEFER;
+
+		dev_info(&pdev->dev, "no regulator found\n");
+	} else
+		regulator_enable(data->regulator);
+
+	ret = of_mdiobus_register(bus, np);
+	if (ret < 0)
+		goto err_out_disable_regulator;
+
+	platform_set_drvdata(pdev, bus);
+
+	return 0;
+
+err_out_disable_regulator:
+	regulator_disable(data->regulator);
+err_out_free_mdio_irq:
+	kfree(bus->irq);
+err_out_free_mdiobus:
+	mdiobus_free(bus);
+	return ret;
+}
+
+static int sun4i_mdio_remove(struct platform_device *pdev)
+{
+	struct mii_bus *bus = platform_get_drvdata(pdev);
+
+	mdiobus_unregister(bus);
+	kfree(bus->irq);
+	mdiobus_free(bus);
+
+	return 0;
+}
+
+static const struct of_device_id sun4i_mdio_dt_ids[] = {
+	{ .compatible = "allwinner,sun4i-mdio" },
+	{ }
+};
+MODULE_DEVICE_TABLE(of, sun4i_mdio_dt_ids);
+
+static struct platform_driver sun4i_mdio_driver = {
+	.probe = sun4i_mdio_probe,
+	.remove = sun4i_mdio_remove,
+	.driver = {
+		.name = "sun4i-mdio",
+		.of_match_table = sun4i_mdio_dt_ids,
+	},
+};
+
+module_platform_driver(sun4i_mdio_driver);
+
+MODULE_DESCRIPTION("Allwinner EMAC MDIO interface driver");
+MODULE_AUTHOR("Maxime Ripard <maxime.ripard at free-electrons.com>");
+MODULE_LICENSE("GPL");
-- 
1.8.1.2



From maxime.ripard at free-electrons.com  Mon Apr 29 15:36:53 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Mon, 29 Apr 2013 21:36:53 +0200
Subject: [PATCH 1/6] net: Add EMAC ethernet driver found on Allwinner A10 SoC's
In-Reply-To: <1367264218-15235-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1367264218-15235-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1367264218-15235-2-git-send-email-maxime.ripard@free-electrons.com>

From: Stefan Roese <sr at denx.de>

The Allwinner A10 has an ethernet controller that seem to be developped
internally by them.

The exact feature set of this controller is unknown, since there is no
public documentation for this IP, and this driver is mostly the one
published by Allwinner that has been heavily cleaned up.

Signed-off-by: Stefan Roese <sr at denx.de>
Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 .../bindings/net/allwinner,sun4i-emac.txt          |  22 +
 drivers/net/ethernet/Kconfig                       |   1 +
 drivers/net/ethernet/Makefile                      |   1 +
 drivers/net/ethernet/allwinner/Kconfig             |  36 +
 drivers/net/ethernet/allwinner/Makefile            |   5 +
 drivers/net/ethernet/allwinner/sun4i-emac.c        | 960 +++++++++++++++++++++
 drivers/net/ethernet/allwinner/sun4i-emac.h        | 108 +++
 7 files changed, 1133 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/net/allwinner,sun4i-emac.txt
 create mode 100644 drivers/net/ethernet/allwinner/Kconfig
 create mode 100644 drivers/net/ethernet/allwinner/Makefile
 create mode 100644 drivers/net/ethernet/allwinner/sun4i-emac.c
 create mode 100644 drivers/net/ethernet/allwinner/sun4i-emac.h

diff --git a/Documentation/devicetree/bindings/net/allwinner,sun4i-emac.txt b/Documentation/devicetree/bindings/net/allwinner,sun4i-emac.txt
new file mode 100644
index 0000000..b90bfcd
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/allwinner,sun4i-emac.txt
@@ -0,0 +1,22 @@
+* Allwinner EMAC ethernet controller
+
+Required properties:
+- compatible: should be "allwinner,sun4i-emac".
+- reg: address and length of the register set for the device.
+- interrupts: interrupt for the device
+- phy: A phandle to a phy node defining the PHY address (as the reg
+  property, a single integer).
+- clocks: A phandle to the reference clock for this device
+
+Optional properties:
+- (local-)mac-address: mac address to be used by this driver
+
+Example:
+
+emac: ethernet at 01c0b000 {
+       compatible = "allwinner,sun4i-emac";
+       reg = <0x01c0b000 0x1000>;
+       interrupts = <55>;
+       clocks = <&ahb_gates 17>;
+       phy = <&phy0>;
+};
diff --git a/drivers/net/ethernet/Kconfig b/drivers/net/ethernet/Kconfig
index ed956e0..18fd6fb 100644
--- a/drivers/net/ethernet/Kconfig
+++ b/drivers/net/ethernet/Kconfig
@@ -20,6 +20,7 @@ config SUNGEM_PHY
 source "drivers/net/ethernet/3com/Kconfig"
 source "drivers/net/ethernet/adaptec/Kconfig"
 source "drivers/net/ethernet/aeroflex/Kconfig"
+source "drivers/net/ethernet/allwinner/Kconfig"
 source "drivers/net/ethernet/alteon/Kconfig"
 source "drivers/net/ethernet/amd/Kconfig"
 source "drivers/net/ethernet/apple/Kconfig"
diff --git a/drivers/net/ethernet/Makefile b/drivers/net/ethernet/Makefile
index 8268d85..009da27 100644
--- a/drivers/net/ethernet/Makefile
+++ b/drivers/net/ethernet/Makefile
@@ -6,6 +6,7 @@ obj-$(CONFIG_NET_VENDOR_3COM) += 3com/
 obj-$(CONFIG_NET_VENDOR_8390) += 8390/
 obj-$(CONFIG_NET_VENDOR_ADAPTEC) += adaptec/
 obj-$(CONFIG_GRETH) += aeroflex/
+obj-$(CONFIG_NET_VENDOR_ALLWINNER) += allwinner/
 obj-$(CONFIG_NET_VENDOR_ALTEON) += alteon/
 obj-$(CONFIG_NET_VENDOR_AMD) += amd/
 obj-$(CONFIG_NET_VENDOR_APPLE) += apple/
diff --git a/drivers/net/ethernet/allwinner/Kconfig b/drivers/net/ethernet/allwinner/Kconfig
new file mode 100644
index 0000000..5d20fb0
--- /dev/null
+++ b/drivers/net/ethernet/allwinner/Kconfig
@@ -0,0 +1,36 @@
+#
+# Allwinner device configuration
+#
+
+config NET_VENDOR_ALLWINNER
+       bool "Allwinner devices"
+       default y
+       depends on ARCH_SUNXI
+       ---help---
+         If you have a network (Ethernet) card belonging to this
+	 class, say Y and read the Ethernet-HOWTO, available from
+	 <http://www.tldp.org/docs.html#howto>.
+
+	 Note that the answer to this question doesn't directly
+	 affect the kernel: saying N will just cause the configurator
+	 to skip all the questions about Davicom cards. If you say Y,
+	 you will be asked for your specific card in the following
+	 questions.
+
+if NET_VENDOR_ALLWINNER
+
+config SUN4I_EMAC
+        tristate "Allwinner A10 EMAC support"
+	depends on ARCH_SUNXI
+	depends on OF
+	select CRC32
+	select NET_CORE
+	select MII
+	select REGULATOR_FIXED_VOLTAGE
+        ---help---
+          Support for Allwinner A10 EMAC ethernet driver.
+
+          To compile this driver as a module, choose M here.  The module
+          will be called sun4i-emac.
+
+endif # NET_VENDOR_ALLWINNER
diff --git a/drivers/net/ethernet/allwinner/Makefile b/drivers/net/ethernet/allwinner/Makefile
new file mode 100644
index 0000000..03129f7
--- /dev/null
+++ b/drivers/net/ethernet/allwinner/Makefile
@@ -0,0 +1,5 @@
+#
+# Makefile for the Allwinner device drivers.
+#
+
+obj-$(CONFIG_SUN4I_EMAC) += sun4i-emac.o
diff --git a/drivers/net/ethernet/allwinner/sun4i-emac.c b/drivers/net/ethernet/allwinner/sun4i-emac.c
new file mode 100644
index 0000000..b411344
--- /dev/null
+++ b/drivers/net/ethernet/allwinner/sun4i-emac.c
@@ -0,0 +1,960 @@
+/*
+ * Allwinner EMAC Fast Ethernet driver for Linux.
+ *
+ * Copyright 2012-2013 Stefan Roese <sr at denx.de>
+ * Copyright 2013 Maxime Ripard <maxime.ripard at free-electrons.com>
+ *
+ * Based on the Linux driver provided by Allwinner:
+ * Copyright (C) 1997  Sten Wang
+ *
+ * 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/clk.h>
+#include <linux/etherdevice.h>
+#include <linux/ethtool.h>
+#include <linux/gpio.h>
+#include <linux/init.h>
+#include <linux/interrupt.h>
+#include <linux/irq.h>
+#include <linux/mii.h>
+#include <linux/module.h>
+#include <linux/netdevice.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+#include <linux/of_mdio.h>
+#include <linux/of_net.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+#include <linux/phy.h>
+
+#include "sun4i-emac.h"
+
+#define DRV_NAME		"sun4i-emac"
+#define DRV_VERSION		"1.02"
+
+#define EMAC_MAX_FRAME_LEN	0x0600
+
+/* Transmit timeout, default 5 seconds. */
+static int watchdog = 5000;
+module_param(watchdog, int, 0400);
+MODULE_PARM_DESC(watchdog, "transmit timeout in milliseconds");
+
+/* EMAC register address locking.
+ *
+ * The EMAC uses an address register to control where data written
+ * to the data register goes. This means that the address register
+ * must be preserved over interrupts or similar calls.
+ *
+ * During interrupt and other critical calls, a spinlock is used to
+ * protect the system, but the calls themselves save the address
+ * in the address register in case they are interrupting another
+ * access to the device.
+ *
+ * For general accesses a lock is provided so that calls which are
+ * allowed to sleep are serialised so that the address register does
+ * not need to be saved. This lock also serves to serialise access
+ * to the EEPROM and PHY access registers which are shared between
+ * these two devices.
+ */
+
+/* The driver supports the original EMACE, and now the two newer
+ * devices, EMACA and EMACB.
+ */
+
+struct emac_board_info {
+	struct clk		*clk;
+	struct device		*dev;
+	struct platform_device	*pdev;
+	spinlock_t		lock;
+	void __iomem		*membase;
+	u32			msg_enable;
+	struct net_device	*ndev;
+	struct sk_buff		*skb_last;
+	u16			tx_fifo_stat;
+
+	int			emacrx_completed_flag;
+
+	struct phy_device	*phy_dev;
+	struct device_node	*phy_node;
+	unsigned int		link;
+	unsigned int		speed;
+	unsigned int		duplex;
+
+	phy_interface_t		phy_interface;
+};
+
+static void emac_update_speed(struct net_device *dev)
+{
+	struct emac_board_info *db = netdev_priv(dev);
+	unsigned int reg_val;
+
+	/* set EMAC SPEED, depend on PHY  */
+	reg_val = readl(db->membase + EMAC_MAC_SUPP_REG);
+	reg_val &= ~(0x1 << 8);
+	if (db->speed == SPEED_100)
+		reg_val |= 1 << 8;
+	writel(reg_val, db->membase + EMAC_MAC_SUPP_REG);
+}
+
+static void emac_update_duplex(struct net_device *dev)
+{
+	struct emac_board_info *db = netdev_priv(dev);
+	unsigned int reg_val;
+
+	/* set duplex depend on phy */
+	reg_val = readl(db->membase + EMAC_MAC_CTL1_REG);
+	reg_val &= ~EMAC_MAC_CTL1_DUPLEX_EN;
+	if (db->duplex)
+		reg_val |= EMAC_MAC_CTL1_DUPLEX_EN;
+	writel(reg_val, db->membase + EMAC_MAC_CTL1_REG);
+}
+
+static void emac_handle_link_change(struct net_device *dev)
+{
+	struct emac_board_info *db = netdev_priv(dev);
+	struct phy_device *phydev = db->phy_dev;
+	unsigned long flags;
+	int status_change = 0;
+
+	if (phydev->link) {
+		if (db->speed != phydev->speed) {
+			spin_lock_irqsave(&db->lock, flags);
+			db->speed = phydev->speed;
+			emac_update_speed(dev);
+			spin_unlock_irqrestore(&db->lock, flags);
+			status_change = 1;
+		}
+
+		if (db->duplex != phydev->duplex) {
+			spin_lock_irqsave(&db->lock, flags);
+			db->duplex = phydev->duplex;
+			emac_update_duplex(dev);
+			spin_unlock_irqrestore(&db->lock, flags);
+			status_change = 1;
+		}
+	}
+
+	if (phydev->link != db->link) {
+		if (!phydev->link) {
+			db->speed = 0;
+			db->duplex = -1;
+		}
+		db->link = phydev->link;
+
+		status_change = 1;
+	}
+
+	if (status_change)
+		phy_print_status(phydev);
+}
+
+static int emac_mdio_probe(struct net_device *dev)
+{
+	struct emac_board_info *db = netdev_priv(dev);
+
+	/* to-do: PHY interrupts are currently not supported */
+
+	/* attach the mac to the phy */
+	db->phy_dev = of_phy_connect(db->ndev, db->phy_node,
+				     &emac_handle_link_change, 0,
+				     db->phy_interface);
+	if (!db->phy_dev) {
+		netdev_err(db->ndev, "could not find the PHY\n");
+		return -ENODEV;
+	}
+
+	/* mask with MAC supported features */
+	db->phy_dev->supported &= PHY_BASIC_FEATURES;
+	db->phy_dev->advertising = db->phy_dev->supported;
+
+	db->link = 0;
+	db->speed = 0;
+	db->duplex = -1;
+
+	return 0;
+}
+
+static void emac_mdio_remove(struct net_device *dev)
+{
+	struct emac_board_info *db = netdev_priv(dev);
+
+	phy_disconnect(db->phy_dev);
+	db->phy_dev = NULL;
+}
+
+static void emac_reset(struct emac_board_info *db)
+{
+	dev_dbg(db->dev, "resetting device\n");
+
+	/* RESET device */
+	writel(0, db->membase + EMAC_CTL_REG);
+	udelay(200);
+	writel(EMAC_CTL_RESET, db->membase + EMAC_CTL_REG);
+	udelay(200);
+}
+
+static void emac_outblk_32bit(void __iomem *reg, void *data, int count)
+{
+	writesl(reg, data, round_up(count, 4) / 4);
+}
+
+static void emac_inblk_32bit(void __iomem *reg, void *data, int count)
+{
+	readsl(reg, data, round_up(count, 4) / 4);
+}
+
+static int emac_ioctl(struct net_device *dev, struct ifreq *rq, int cmd)
+{
+	struct emac_board_info *dm = netdev_priv(dev);
+	struct phy_device *phydev = dm->phy_dev;
+
+	if (!netif_running(dev))
+		return -EINVAL;
+
+	if (!phydev)
+		return -ENODEV;
+
+	return phy_mii_ioctl(phydev, rq, cmd);
+}
+
+/* ethtool ops */
+static void emac_get_drvinfo(struct net_device *dev,
+			      struct ethtool_drvinfo *info)
+{
+	strlcpy(info->driver, DRV_NAME, sizeof(DRV_NAME));
+	strlcpy(info->version, DRV_VERSION, sizeof(DRV_VERSION));
+	strlcpy(info->bus_info, dev_name(&dev->dev), sizeof(info->bus_info));
+}
+
+static int emac_get_settings(struct net_device *dev, struct ethtool_cmd *cmd)
+{
+	struct emac_board_info *dm = netdev_priv(dev);
+	struct phy_device *phydev = dm->phy_dev;
+
+	if (!phydev)
+		return -ENODEV;
+
+	return phy_ethtool_gset(phydev, cmd);
+}
+
+static int emac_set_settings(struct net_device *dev, struct ethtool_cmd *cmd)
+{
+	struct emac_board_info *dm = netdev_priv(dev);
+	struct phy_device *phydev = dm->phy_dev;
+
+	if (!phydev)
+		return -ENODEV;
+
+	return phy_ethtool_sset(phydev, cmd);
+}
+
+static const struct ethtool_ops emac_ethtool_ops = {
+	.get_drvinfo	= emac_get_drvinfo,
+	.get_settings	= emac_get_settings,
+	.set_settings	= emac_set_settings,
+	.get_link	= ethtool_op_get_link,
+};
+
+unsigned int emac_setup(struct net_device *ndev)
+{
+	struct emac_board_info *db = netdev_priv(ndev);
+	unsigned int reg_val;
+
+	/* set up TX */
+	reg_val = readl(db->membase + EMAC_TX_MODE_REG);
+
+	writel(reg_val | EMAC_TX_MODE_ABORTED_FRAME_EN,
+		db->membase + EMAC_TX_MODE_REG);
+
+	/* set up RX */
+	reg_val = readl(db->membase + EMAC_RX_CTL_REG);
+
+	writel(reg_val | EMAC_RX_CTL_PASS_LEN_OOR_EN |
+		EMAC_RX_CTL_ACCEPT_UNICAST_EN | EMAC_RX_CTL_DA_FILTER_EN |
+		EMAC_RX_CTL_ACCEPT_MULTICAST_EN |
+		EMAC_RX_CTL_ACCEPT_BROADCAST_EN,
+		db->membase + EMAC_RX_CTL_REG);
+
+	/* set MAC */
+	/* set MAC CTL0 */
+	reg_val = readl(db->membase + EMAC_MAC_CTL0_REG);
+	writel(reg_val | EMAC_MAC_CTL0_RX_FLOW_CTL_EN |
+		EMAC_MAC_CTL0_TX_FLOW_CTL_EN,
+		db->membase + EMAC_MAC_CTL0_REG);
+
+	/* set MAC CTL1 */
+	reg_val = readl(db->membase + EMAC_MAC_CTL1_REG);
+	reg_val |= EMAC_MAC_CTL1_LEN_CHECK_EN;
+	reg_val |= EMAC_MAC_CTL1_CRC_EN;
+	reg_val |= EMAC_MAC_CTL1_PAD_EN;
+	writel(reg_val, db->membase + EMAC_MAC_CTL1_REG);
+
+	/* set up IPGT */
+	writel(EMAC_MAC_IPGT_FULL_DUPLEX, db->membase + EMAC_MAC_IPGT_REG);
+
+	/* set up IPGR */
+	writel((EMAC_MAC_IPGR_IPG1 << 8) | EMAC_MAC_IPGR_IPG2,
+		db->membase + EMAC_MAC_IPGR_REG);
+
+	/* set up Collison window */
+	writel((EMAC_MAC_CLRT_COLLISION_WINDOW << 8) | EMAC_MAC_CLRT_RM,
+		db->membase + EMAC_MAC_CLRT_REG);
+
+	/* set up Max Frame Length */
+	writel(EMAC_MAX_FRAME_LEN,
+		db->membase + EMAC_MAC_MAXF_REG);
+
+	return 0;
+}
+
+unsigned int emac_powerup(struct net_device *ndev)
+{
+	struct emac_board_info *db = netdev_priv(ndev);
+	unsigned int reg_val;
+
+	/* initial EMAC */
+	/* flush RX FIFO */
+	reg_val = readl(db->membase + EMAC_RX_CTL_REG);
+	reg_val |= 0x8;
+	writel(reg_val, db->membase + EMAC_RX_CTL_REG);
+	udelay(1);
+
+	/* initial MAC */
+	/* soft reset MAC */
+	reg_val = readl(db->membase + EMAC_MAC_CTL0_REG);
+	reg_val &= ~EMAC_MAC_CTL0_SOFT_RESET;
+	writel(reg_val, db->membase + EMAC_MAC_CTL0_REG);
+
+	/* set MII clock */
+	reg_val = readl(db->membase + EMAC_MAC_MCFG_REG);
+	reg_val &= (~(0xf << 2));
+	reg_val |= (0xD << 2);
+	writel(reg_val, db->membase + EMAC_MAC_MCFG_REG);
+
+	/* clear RX counter */
+	writel(0x0, db->membase + EMAC_RX_FBC_REG);
+
+	/* disable all interrupt and clear interrupt status */
+	writel(0, db->membase + EMAC_INT_CTL_REG);
+	reg_val = readl(db->membase + EMAC_INT_STA_REG);
+	writel(reg_val, db->membase + EMAC_INT_STA_REG);
+
+	udelay(1);
+
+	/* set up EMAC */
+	emac_setup(ndev);
+
+	/* set mac_address to chip */
+	writel(ndev->dev_addr[0] << 16 | ndev->dev_addr[1] << 8 | ndev->
+	       dev_addr[2], db->membase + EMAC_MAC_A1_REG);
+	writel(ndev->dev_addr[3] << 16 | ndev->dev_addr[4] << 8 | ndev->
+	       dev_addr[5], db->membase + EMAC_MAC_A0_REG);
+
+	mdelay(1);
+
+	return 0;
+}
+
+static int emac_set_mac_address(struct net_device *dev, void *p)
+{
+	struct sockaddr *addr = p;
+	struct emac_board_info *db = netdev_priv(dev);
+
+	if (netif_running(dev))
+		return -EBUSY;
+
+	memcpy(dev->dev_addr, addr->sa_data, ETH_ALEN);
+
+	writel(dev->dev_addr[0] << 16 | dev->dev_addr[1] << 8 | dev->
+	       dev_addr[2], db->membase + EMAC_MAC_A1_REG);
+	writel(dev->dev_addr[3] << 16 | dev->dev_addr[4] << 8 | dev->
+	       dev_addr[5], db->membase + EMAC_MAC_A0_REG);
+
+	return 0;
+}
+
+/* Initialize emac board */
+static void emac_init_device(struct net_device *dev)
+{
+	struct emac_board_info *db = netdev_priv(dev);
+	unsigned long flags;
+	unsigned int reg_val;
+
+	spin_lock_irqsave(&db->lock, flags);
+
+	emac_update_speed(dev);
+	emac_update_duplex(dev);
+
+	/* enable RX/TX */
+	reg_val = readl(db->membase + EMAC_CTL_REG);
+	writel(reg_val | EMAC_CTL_RESET | EMAC_CTL_TX_EN | EMAC_CTL_RX_EN,
+		db->membase + EMAC_CTL_REG);
+
+	/* enable RX/TX0/RX Hlevel interrup */
+	reg_val = readl(db->membase + EMAC_INT_CTL_REG);
+	reg_val |= (0xf << 0) | (0x01 << 8);
+	writel(reg_val, db->membase + EMAC_INT_CTL_REG);
+
+	spin_unlock_irqrestore(&db->lock, flags);
+}
+
+/* Our watchdog timed out. Called by the networking layer */
+static void emac_timeout(struct net_device *dev)
+{
+	struct emac_board_info *db = netdev_priv(dev);
+	unsigned long flags;
+
+	if (netif_msg_timer(db))
+		dev_err(db->dev, "tx time out.\n");
+
+	/* Save previous register address */
+	spin_lock_irqsave(&db->lock, flags);
+
+	netif_stop_queue(dev);
+	emac_reset(db);
+	emac_init_device(dev);
+	/* We can accept TX packets again */
+	dev->trans_start = jiffies;
+	netif_wake_queue(dev);
+
+	/* Restore previous register address */
+	spin_unlock_irqrestore(&db->lock, flags);
+}
+
+/* Hardware start transmission.
+ * Send a packet to media from the upper layer.
+ */
+static int emac_start_xmit(struct sk_buff *skb, struct net_device *dev)
+{
+	struct emac_board_info *db = netdev_priv(dev);
+	unsigned long channel;
+	unsigned long flags;
+
+	channel = db->tx_fifo_stat & 3;
+	if (channel == 3)
+		return 1;
+
+	channel = (channel == 1 ? 1 : 0);
+
+	spin_lock_irqsave(&db->lock, flags);
+
+	writel(channel, db->membase + EMAC_TX_INS_REG);
+
+	emac_outblk_32bit(db->membase + EMAC_TX_IO_DATA_REG,
+			skb->data, skb->len);
+	dev->stats.tx_bytes += skb->len;
+
+	db->tx_fifo_stat |= 1 << channel;
+	/* TX control: First packet immediately send, second packet queue */
+	if (channel == 0) {
+		/* set TX len */
+		writel(skb->len, db->membase + EMAC_TX_PL0_REG);
+		/* start translate from fifo to phy */
+		writel(readl(db->membase + EMAC_TX_CTL0_REG) | 1,
+		       db->membase + EMAC_TX_CTL0_REG);
+
+		/* save the time stamp */
+		dev->trans_start = jiffies;
+	} else if (channel == 1) {
+		/* set TX len */
+		writel(skb->len, db->membase + EMAC_TX_PL1_REG);
+		/* start translate from fifo to phy */
+		writel(readl(db->membase + EMAC_TX_CTL1_REG) | 1,
+		       db->membase + EMAC_TX_CTL1_REG);
+
+		/* save the time stamp */
+		dev->trans_start = jiffies;
+	}
+
+	if ((db->tx_fifo_stat & 3) == 3) {
+		/* Second packet */
+		netif_stop_queue(dev);
+	}
+
+	spin_unlock_irqrestore(&db->lock, flags);
+
+	/* free this SKB */
+	dev_kfree_skb(skb);
+
+	return NETDEV_TX_OK;
+}
+
+/* EMAC interrupt handler
+ * receive the packet to upper layer, free the transmitted packet
+ */
+static void emac_tx_done(struct net_device *dev, struct emac_board_info *db,
+			  unsigned int tx_status)
+{
+	/* One packet sent complete */
+	db->tx_fifo_stat &= ~(tx_status & 3);
+	if (3 == (tx_status & 3))
+		dev->stats.tx_packets += 2;
+	else
+		dev->stats.tx_packets++;
+
+	if (netif_msg_tx_done(db))
+		dev_dbg(db->dev, "tx done, NSR %02x\n", tx_status);
+
+	netif_wake_queue(dev);
+}
+
+/* Received a packet and pass to upper layer
+ */
+static void emac_rx(struct net_device *dev)
+{
+	struct emac_board_info *db = netdev_priv(dev);
+	struct sk_buff *skb;
+	u8 *rdptr;
+	bool good_packet;
+	static int rxlen_last;
+	unsigned int reg_val;
+	u32 rxhdr, rxstatus, rxcount, rxlen;
+
+	/* Check packet ready or not */
+	while (1) {
+		/* race warning: the first packet might arrive with
+		 * the interrupts disabled, but the second will fix
+		 * it
+		 */
+		rxcount = readl(db->membase + EMAC_RX_FBC_REG);
+
+		if (netif_msg_rx_status(db))
+			dev_dbg(db->dev, "RXCount: %x\n", rxcount);
+
+		if ((db->skb_last != NULL) && (rxlen_last > 0)) {
+			dev->stats.rx_bytes += rxlen_last;
+
+			/* Pass to upper layer */
+			db->skb_last->protocol = eth_type_trans(db->skb_last,
+								dev);
+			netif_rx(db->skb_last);
+			dev->stats.rx_packets++;
+			db->skb_last = NULL;
+			rxlen_last = 0;
+
+			reg_val = readl(db->membase + EMAC_RX_CTL_REG);
+			reg_val &= ~EMAC_RX_CTL_DMA_EN;
+			writel(reg_val, db->membase + EMAC_RX_CTL_REG);
+		}
+
+		if (!rxcount) {
+			db->emacrx_completed_flag = 1;
+			reg_val = readl(db->membase + EMAC_INT_CTL_REG);
+			reg_val |= (0xf << 0) | (0x01 << 8);
+			writel(reg_val, db->membase + EMAC_INT_CTL_REG);
+
+			/* had one stuck? */
+			rxcount = readl(db->membase + EMAC_RX_FBC_REG);
+			if (!rxcount)
+				return;
+		}
+
+		reg_val = readl(db->membase + EMAC_RX_IO_DATA_REG);
+		if (netif_msg_rx_status(db))
+			dev_dbg(db->dev, "receive header: %x\n", reg_val);
+		if (reg_val != EMAC_UNDOCUMENTED_MAGIC) {
+			/* disable RX */
+			reg_val = readl(db->membase + EMAC_CTL_REG);
+			writel(reg_val & ~EMAC_CTL_RX_EN,
+			       db->membase + EMAC_CTL_REG);
+
+			/* Flush RX FIFO */
+			reg_val = readl(db->membase + EMAC_RX_CTL_REG);
+			writel(reg_val | (1 << 3),
+			       db->membase + EMAC_RX_CTL_REG);
+
+			do {
+				reg_val = readl(db->membase + EMAC_RX_CTL_REG);
+			} while (reg_val & (1 << 3));
+
+			/* enable RX */
+			reg_val = readl(db->membase + EMAC_CTL_REG);
+			writel(reg_val | EMAC_CTL_RX_EN,
+			       db->membase + EMAC_CTL_REG);
+			reg_val = readl(db->membase + EMAC_INT_CTL_REG);
+			reg_val |= (0xf << 0) | (0x01 << 8);
+			writel(reg_val, db->membase + EMAC_INT_CTL_REG);
+
+			db->emacrx_completed_flag = 1;
+
+			return;
+		}
+
+		/* A packet ready now  & Get status/length */
+		good_packet = true;
+
+		emac_inblk_32bit(db->membase + EMAC_RX_IO_DATA_REG,
+				&rxhdr, sizeof(rxhdr));
+
+		if (netif_msg_rx_status(db))
+			dev_dbg(db->dev, "rxhdr: %x\n", *((int *)(&rxhdr)));
+
+		rxlen = EMAC_RX_IO_DATA_LEN(rxhdr);
+		rxstatus = EMAC_RX_IO_DATA_STATUS(rxhdr);
+
+		if (netif_msg_rx_status(db))
+			dev_dbg(db->dev, "RX: status %02x, length %04x\n",
+				rxstatus, rxlen);
+
+		/* Packet Status check */
+		if (rxlen < 0x40) {
+			good_packet = false;
+			if (netif_msg_rx_err(db))
+				dev_dbg(db->dev, "RX: Bad Packet (runt)\n");
+		}
+
+		if (unlikely(!(rxstatus & EMAC_RX_IO_DATA_STATUS_OK))) {
+			good_packet = false;
+
+			if (rxstatus & EMAC_RX_IO_DATA_STATUS_CRC_ERR) {
+				if (netif_msg_rx_err(db))
+					dev_dbg(db->dev, "crc error\n");
+				dev->stats.rx_crc_errors++;
+			}
+
+			if (rxstatus & EMAC_RX_IO_DATA_STATUS_LEN_ERR) {
+				if (netif_msg_rx_err(db))
+					dev_dbg(db->dev, "length error\n");
+				dev->stats.rx_length_errors++;
+			}
+		}
+
+		/* Move data from EMAC */
+		skb = dev_alloc_skb(rxlen + 4);
+		if (good_packet && skb) {
+			skb_reserve(skb, 2);
+			rdptr = (u8 *) skb_put(skb, rxlen - 4);
+
+			/* Read received packet from RX SRAM */
+			if (netif_msg_rx_status(db))
+				dev_dbg(db->dev, "RxLen %x\n", rxlen);
+
+			emac_inblk_32bit(db->membase + EMAC_RX_IO_DATA_REG,
+					rdptr, rxlen);
+			dev->stats.rx_bytes += rxlen;
+
+			/* Pass to upper layer */
+			skb->protocol = eth_type_trans(skb, dev);
+			netif_rx(skb);
+			dev->stats.rx_packets++;
+		}
+	}
+}
+
+static irqreturn_t emac_interrupt(int irq, void *dev_id)
+{
+	struct net_device *dev = dev_id;
+	struct emac_board_info *db = netdev_priv(dev);
+	int int_status;
+	unsigned long flags;
+	unsigned int reg_val;
+
+	/* A real interrupt coming */
+
+	/* holders of db->lock must always block IRQs */
+	spin_lock_irqsave(&db->lock, flags);
+
+	/* Disable all interrupts */
+	writel(0, db->membase + EMAC_INT_CTL_REG);
+
+	/* Got EMAC interrupt status */
+	/* Got ISR */
+	int_status = readl(db->membase + EMAC_INT_STA_REG);
+	/* Clear ISR status */
+	writel(int_status, db->membase + EMAC_INT_STA_REG);
+
+	if (netif_msg_intr(db))
+		dev_dbg(db->dev, "emac interrupt %02x\n", int_status);
+
+	/* Received the coming packet */
+	if ((int_status & 0x100) && (db->emacrx_completed_flag == 1)) {
+		/* carrier lost */
+		db->emacrx_completed_flag = 0;
+		emac_rx(dev);
+	}
+
+	/* Transmit Interrupt check */
+	if (int_status & (0x01 | 0x02))
+		emac_tx_done(dev, db, int_status);
+
+	if (int_status & (0x04 | 0x08))
+		netdev_info(dev, " ab : %x\n", int_status);
+
+	/* Re-enable interrupt mask */
+	if (db->emacrx_completed_flag == 1) {
+		reg_val = readl(db->membase + EMAC_INT_CTL_REG);
+		reg_val |= (0xf << 0) | (0x01 << 8);
+		writel(reg_val, db->membase + EMAC_INT_CTL_REG);
+	}
+	spin_unlock_irqrestore(&db->lock, flags);
+
+	return IRQ_HANDLED;
+}
+
+#ifdef CONFIG_NET_POLL_CONTROLLER
+/*
+ * Used by netconsole
+ */
+static void emac_poll_controller(struct net_device *dev)
+{
+	disable_irq(dev->irq);
+	emac_interrupt(dev->irq, dev);
+	enable_irq(dev->irq);
+}
+#endif
+
+/*  Open the interface.
+ *  The interface is opened whenever "ifconfig" actives it.
+ */
+static int emac_open(struct net_device *dev)
+{
+	struct emac_board_info *db = netdev_priv(dev);
+	int ret;
+
+	if (netif_msg_ifup(db))
+		dev_dbg(db->dev, "enabling %s\n", dev->name);
+
+	if (devm_request_irq(db->dev, dev->irq, &emac_interrupt,
+			     0, dev->name, dev))
+		return -EAGAIN;
+
+	/* Initialize EMAC board */
+	emac_reset(db);
+	emac_init_device(dev);
+
+	ret = emac_mdio_probe(dev);
+	if (ret < 0) {
+		netdev_err(dev, "cannot probe MDIO bus\n");
+		return ret;
+	}
+
+	phy_start(db->phy_dev);
+	netif_start_queue(dev);
+
+	return 0;
+}
+
+static void emac_shutdown(struct net_device *dev)
+{
+	unsigned int reg_val;
+	struct emac_board_info *db = netdev_priv(dev);
+
+	/* Disable all interrupt */
+	writel(0, db->membase + EMAC_INT_CTL_REG);
+
+	/* clear interupt status */
+	reg_val = readl(db->membase + EMAC_INT_STA_REG);
+	writel(reg_val, db->membase + EMAC_INT_STA_REG);
+
+	/* Disable RX/TX */
+	reg_val = readl(db->membase + EMAC_CTL_REG);
+	reg_val &= ~(EMAC_CTL_TX_EN | EMAC_CTL_RX_EN | EMAC_CTL_RESET);
+	writel(reg_val, db->membase + EMAC_CTL_REG);
+}
+
+/* Stop the interface.
+ * The interface is stopped when it is brought.
+ */
+static int emac_stop(struct net_device *ndev)
+{
+	struct emac_board_info *db = netdev_priv(ndev);
+
+	if (netif_msg_ifdown(db))
+		dev_dbg(db->dev, "shutting down %s\n", ndev->name);
+
+	netif_stop_queue(ndev);
+	netif_carrier_off(ndev);
+
+	phy_stop(db->phy_dev);
+
+	emac_mdio_remove(ndev);
+
+	emac_shutdown(ndev);
+
+	return 0;
+}
+
+static const struct net_device_ops emac_netdev_ops = {
+	.ndo_open		= emac_open,
+	.ndo_stop		= emac_stop,
+	.ndo_start_xmit		= emac_start_xmit,
+	.ndo_tx_timeout		= emac_timeout,
+	.ndo_do_ioctl		= emac_ioctl,
+	.ndo_change_mtu		= eth_change_mtu,
+	.ndo_validate_addr	= eth_validate_addr,
+	.ndo_set_mac_address	= emac_set_mac_address,
+#ifdef CONFIG_NET_POLL_CONTROLLER
+	.ndo_poll_controller	= emac_poll_controller,
+#endif
+};
+
+/* Search EMAC board, allocate space and register it
+ */
+static int emac_probe(struct platform_device *pdev)
+{
+	struct device_node *np = pdev->dev.of_node;
+	struct emac_board_info *db;
+	struct net_device *ndev;
+	int ret = 0;
+	const char *mac_addr;
+
+	ndev = alloc_etherdev(sizeof(struct emac_board_info));
+	if (!ndev) {
+		dev_err(&pdev->dev, "could not allocate device.\n");
+		return -ENOMEM;
+	}
+
+	SET_NETDEV_DEV(ndev, &pdev->dev);
+
+	db = netdev_priv(ndev);
+	memset(db, 0, sizeof(*db));
+
+	db->dev = &pdev->dev;
+	db->ndev = ndev;
+	db->pdev = pdev;
+
+	spin_lock_init(&db->lock);
+
+	db->membase = of_iomap(np, 0);
+	if (!db->membase) {
+		dev_err(&pdev->dev, "failed to remap registers\n");
+		return -ENOMEM;
+		goto out;
+	}
+
+	/* fill in parameters for net-dev structure */
+	ndev->base_addr = (unsigned long)db->membase;
+	ndev->irq = irq_of_parse_and_map(np, 0);
+	if (ndev->irq == -ENXIO) {
+		netdev_err(ndev, "No irq resource\n");
+		ret = ndev->irq;
+		goto out;
+	}
+
+	db->clk = devm_clk_get(&pdev->dev, NULL);
+	if (IS_ERR(db->clk))
+		goto out;
+
+	clk_prepare_enable(db->clk);
+
+	db->phy_node = of_parse_phandle(np, "phy", 0);
+	if (!db->phy_node) {
+		dev_err(&pdev->dev, "no associated PHY\n");
+		ret = -ENODEV;
+		goto out;
+	}
+
+	/* Read MAC-address from DT */
+	mac_addr = of_get_mac_address(np);
+	if (mac_addr)
+		memcpy(ndev->dev_addr, mac_addr, ETH_ALEN);
+
+	/* Check if the MAC address is valid, if not get a random one */
+	if (!is_valid_ether_addr(ndev->dev_addr)) {
+		eth_hw_addr_random(ndev);
+		dev_warn(&pdev->dev, "using random MAC address %pM\n",
+			 ndev->dev_addr);
+	}
+
+	db->emacrx_completed_flag = 1;
+	emac_powerup(ndev);
+	emac_reset(db);
+
+	ether_setup(ndev);
+
+	ndev->netdev_ops = &emac_netdev_ops;
+	ndev->watchdog_timeo = msecs_to_jiffies(watchdog);
+	ndev->ethtool_ops = &emac_ethtool_ops;
+
+#ifdef CONFIG_NET_POLL_CONTROLLER
+	ndev->poll_controller = &emac_poll_controller;
+#endif
+
+	platform_set_drvdata(pdev, ndev);
+
+	/* Carrier starts down, phylib will bring it up */
+	netif_carrier_off(ndev);
+
+	ret = register_netdev(ndev);
+	if (ret) {
+		dev_err(&pdev->dev, "Registering netdev failed!\n");
+		ret = -ENODEV;
+		goto out;
+	}
+
+	dev_info(&pdev->dev, "%s: at %p, IRQ %d MAC: %pM\n",
+		 ndev->name, db->membase, ndev->irq, ndev->dev_addr);
+
+	return 0;
+
+out:
+	dev_err(db->dev, "not found (%d).\n", ret);
+
+	free_netdev(ndev);
+
+	return ret;
+}
+
+static int emac_remove(struct platform_device *pdev)
+{
+	struct net_device *ndev = platform_get_drvdata(pdev);
+
+	platform_set_drvdata(pdev, NULL);
+
+	unregister_netdev(ndev);
+	free_netdev(ndev);
+
+	dev_dbg(&pdev->dev, "released and freed device\n");
+	return 0;
+}
+
+static int emac_suspend(struct platform_device *dev, pm_message_t state)
+{
+	struct net_device *ndev = platform_get_drvdata(dev);
+
+	netif_carrier_off(ndev);
+	netif_device_detach(ndev);
+	emac_shutdown(ndev);
+
+	return 0;
+}
+
+static int emac_resume(struct platform_device *dev)
+{
+	struct net_device *ndev = platform_get_drvdata(dev);
+	struct emac_board_info *db = netdev_priv(ndev);
+
+	emac_reset(db);
+	emac_init_device(ndev);
+	netif_device_attach(ndev);
+
+	return 0;
+}
+
+static const struct of_device_id emac_of_match[] = {
+	{.compatible = "allwinner,sun4i-emac",},
+	{},
+};
+
+MODULE_DEVICE_TABLE(of, emac_of_match);
+
+static struct platform_driver emac_driver = {
+	.driver = {
+		.name = "sun4i-emac",
+		.of_match_table = emac_of_match,
+	},
+	.probe = emac_probe,
+	.remove = emac_remove,
+	.suspend = emac_suspend,
+	.resume = emac_resume,
+};
+
+module_platform_driver(emac_driver);
+
+MODULE_AUTHOR("Stefan Roese <sr at denx.de>");
+MODULE_AUTHOR("Maxime Ripard <maxime.ripard at free-electrons.com>");
+MODULE_DESCRIPTION("Allwinner A10 emac network driver");
+MODULE_LICENSE("GPL");
diff --git a/drivers/net/ethernet/allwinner/sun4i-emac.h b/drivers/net/ethernet/allwinner/sun4i-emac.h
new file mode 100644
index 0000000..38c72d9
--- /dev/null
+++ b/drivers/net/ethernet/allwinner/sun4i-emac.h
@@ -0,0 +1,108 @@
+/*
+ * Allwinner EMAC Fast Ethernet driver for Linux.
+ *
+ * Copyright 2012 Stefan Roese <sr at denx.de>
+ * Copyright 2013 Maxime Ripard <maxime.ripard at free-electrons.com>
+ *
+ * Based on the Linux driver provided by Allwinner:
+ * Copyright (C) 1997  Sten Wang
+ *
+ * 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.
+ */
+
+#ifndef _SUN4I_EMAC_H_
+#define _SUN4I_EMAC_H_
+
+#define EMAC_CTL_REG		(0x00)
+#define EMAC_CTL_RESET			(1 << 0)
+#define EMAC_CTL_TX_EN			(1 << 1)
+#define EMAC_CTL_RX_EN			(1 << 2)
+#define EMAC_TX_MODE_REG	(0x04)
+#define EMAC_TX_MODE_ABORTED_FRAME_EN	(1 << 0)
+#define EMAC_TX_MODE_DMA_EN		(1 << 1)
+#define EMAC_TX_FLOW_REG	(0x08)
+#define EMAC_TX_CTL0_REG	(0x0c)
+#define EMAC_TX_CTL1_REG	(0x10)
+#define EMAC_TX_INS_REG		(0x14)
+#define EMAC_TX_PL0_REG		(0x18)
+#define EMAC_TX_PL1_REG		(0x1c)
+#define EMAC_TX_STA_REG		(0x20)
+#define EMAC_TX_IO_DATA_REG	(0x24)
+#define EMAC_TX_IO_DATA1_REG	(0x28)
+#define EMAC_TX_TSVL0_REG	(0x2c)
+#define EMAC_TX_TSVH0_REG	(0x30)
+#define EMAC_TX_TSVL1_REG	(0x34)
+#define EMAC_TX_TSVH1_REG	(0x38)
+#define EMAC_RX_CTL_REG		(0x3c)
+#define EMAC_RX_CTL_AUTO_DRQ_EN		(1 << 1)
+#define EMAC_RX_CTL_DMA_EN		(1 << 2)
+#define EMAC_RX_CTL_PASS_ALL_EN		(1 << 4)
+#define EMAC_RX_CTL_PASS_CTL_EN		(1 << 5)
+#define EMAC_RX_CTL_PASS_CRC_ERR_EN	(1 << 6)
+#define EMAC_RX_CTL_PASS_LEN_ERR_EN	(1 << 7)
+#define EMAC_RX_CTL_PASS_LEN_OOR_EN	(1 << 8)
+#define EMAC_RX_CTL_ACCEPT_UNICAST_EN	(1 << 16)
+#define EMAC_RX_CTL_DA_FILTER_EN	(1 << 17)
+#define EMAC_RX_CTL_ACCEPT_MULTICAST_EN	(1 << 20)
+#define EMAC_RX_CTL_HASH_FILTER_EN	(1 << 21)
+#define EMAC_RX_CTL_ACCEPT_BROADCAST_EN	(1 << 22)
+#define EMAC_RX_CTL_SA_FILTER_EN	(1 << 24)
+#define EMAC_RX_CTL_SA_FILTER_INVERT_EN	(1 << 25)
+#define EMAC_RX_HASH0_REG	(0x40)
+#define EMAC_RX_HASH1_REG	(0x44)
+#define EMAC_RX_STA_REG		(0x48)
+#define EMAC_RX_IO_DATA_REG	(0x4c)
+#define EMAC_RX_IO_DATA_LEN(x)		(x & 0xffff)
+#define EMAC_RX_IO_DATA_STATUS(x)	((x >> 16) & 0xffff)
+#define EMAC_RX_IO_DATA_STATUS_CRC_ERR	(1 << 4)
+#define EMAC_RX_IO_DATA_STATUS_LEN_ERR	(3 << 5)
+#define EMAC_RX_IO_DATA_STATUS_OK	(1 << 7)
+#define EMAC_RX_FBC_REG		(0x50)
+#define EMAC_INT_CTL_REG	(0x54)
+#define EMAC_INT_STA_REG	(0x58)
+#define EMAC_MAC_CTL0_REG	(0x5c)
+#define EMAC_MAC_CTL0_RX_FLOW_CTL_EN	(1 << 2)
+#define EMAC_MAC_CTL0_TX_FLOW_CTL_EN	(1 << 3)
+#define EMAC_MAC_CTL0_SOFT_RESET	(1 << 15)
+#define EMAC_MAC_CTL1_REG	(0x60)
+#define EMAC_MAC_CTL1_DUPLEX_EN		(1 << 0)
+#define EMAC_MAC_CTL1_LEN_CHECK_EN	(1 << 1)
+#define EMAC_MAC_CTL1_HUGE_FRAME_EN	(1 << 2)
+#define EMAC_MAC_CTL1_DELAYED_CRC_EN	(1 << 3)
+#define EMAC_MAC_CTL1_CRC_EN		(1 << 4)
+#define EMAC_MAC_CTL1_PAD_EN		(1 << 5)
+#define EMAC_MAC_CTL1_PAD_CRC_EN	(1 << 6)
+#define EMAC_MAC_CTL1_AD_SHORT_FRAME_EN	(1 << 7)
+#define EMAC_MAC_CTL1_BACKOFF_DIS	(1 << 12)
+#define EMAC_MAC_IPGT_REG	(0x64)
+#define EMAC_MAC_IPGT_HALF_DUPLEX	(0x12)
+#define EMAC_MAC_IPGT_FULL_DUPLEX	(0x15)
+#define EMAC_MAC_IPGR_REG	(0x68)
+#define EMAC_MAC_IPGR_IPG1		(0x0c)
+#define EMAC_MAC_IPGR_IPG2		(0x12)
+#define EMAC_MAC_CLRT_REG	(0x6c)
+#define EMAC_MAC_CLRT_COLLISION_WINDOW	(0x37)
+#define EMAC_MAC_CLRT_RM		(0x0f)
+#define EMAC_MAC_MAXF_REG	(0x70)
+#define EMAC_MAC_SUPP_REG	(0x74)
+#define EMAC_MAC_TEST_REG	(0x78)
+#define EMAC_MAC_MCFG_REG	(0x7c)
+#define EMAC_MAC_A0_REG		(0x98)
+#define EMAC_MAC_A1_REG		(0x9c)
+#define EMAC_MAC_A2_REG		(0xa0)
+#define EMAC_SAFX_L_REG0	(0xa4)
+#define EMAC_SAFX_H_REG0	(0xa8)
+#define EMAC_SAFX_L_REG1	(0xac)
+#define EMAC_SAFX_H_REG1	(0xb0)
+#define EMAC_SAFX_L_REG2	(0xb4)
+#define EMAC_SAFX_H_REG2	(0xb8)
+#define EMAC_SAFX_L_REG3	(0xbc)
+#define EMAC_SAFX_H_REG3	(0xc0)
+
+#define EMAC_PHY_DUPLEX		(1 << 8)
+
+#define EMAC_EEPROM_MAGIC	(0x444d394b)
+#define EMAC_UNDOCUMENTED_MAGIC	(0x0143414d)
+#endif /* _SUN4I_EMAC_H_ */
-- 
1.8.1.2



From maxime.ripard at free-electrons.com  Mon Apr 29 15:36:57 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Mon, 29 Apr 2013 21:36:57 +0200
Subject: [PATCH 5/6] ARM: cubieboard: Enable ethernet (EMAC) support in dts
In-Reply-To: <1367264218-15235-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1367264218-15235-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1367264218-15235-6-git-send-email-maxime.ripard@free-electrons.com>

From: Stefan Roese <sr at denx.de>

Signed-off-by: Stefan Roese <sr at denx.de>
---
 arch/arm/boot/dts/sun4i-a10-cubieboard.dts | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/arch/arm/boot/dts/sun4i-a10-cubieboard.dts b/arch/arm/boot/dts/sun4i-a10-cubieboard.dts
index b70fe0d..32d9b18 100644
--- a/arch/arm/boot/dts/sun4i-a10-cubieboard.dts
+++ b/arch/arm/boot/dts/sun4i-a10-cubieboard.dts
@@ -27,6 +27,21 @@
 	};
 
 	soc at 01c20000 {
+		emac: ethernet at 01c0b000 {
+			pinctrl-names = "default";
+			pinctrl-0 = <&emac_pins_a>;
+			phy = <&phy0>;
+			status = "okay";
+		};
+
+		mdio at 01c0b080 {
+			status = "okay";
+
+			phy0: ethernet-phy at 0 {
+				reg = <0>;
+			};
+		};
+
 		pinctrl at 01c20800 {
 			led_pins_cubieboard: led_pins at 0 {
 				allwinner,pins = "PH20", "PH21";
-- 
1.8.1.2



From maxime.ripard at free-electrons.com  Mon Apr 29 15:36:58 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Mon, 29 Apr 2013 21:36:58 +0200
Subject: [PATCH 6/6] ARM: sunxi: Add EMAC Controller to Hackberry dt
In-Reply-To: <1367264218-15235-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1367264218-15235-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1367264218-15235-7-git-send-email-maxime.ripard@free-electrons.com>

The Hackberry has a PHY that needs to be powered up through a GPIO, so
we need to use a fixed regulator here.

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 arch/arm/boot/dts/sun4i-a10-hackberry.dts | 41 +++++++++++++++++++++++++++++++
 1 file changed, 41 insertions(+)

diff --git a/arch/arm/boot/dts/sun4i-a10-hackberry.dts b/arch/arm/boot/dts/sun4i-a10-hackberry.dts
index b9efac1..3514b37 100644
--- a/arch/arm/boot/dts/sun4i-a10-hackberry.dts
+++ b/arch/arm/boot/dts/sun4i-a10-hackberry.dts
@@ -23,10 +23,51 @@
 	};
 
 	soc at 01c20000 {
+		emac: ethernet at 01c0b000 {
+			pinctrl-names = "default";
+			pinctrl-0 = <&emac_pins_a>;
+			phy = <&phy0>;
+			status = "okay";
+		};
+
+		mdio at 01c0b080 {
+			phy-supply = <&reg_emac_3v3>;
+			status = "okay";
+
+			phy0: ethernet-phy at 0 {
+				reg = <0>;
+			};
+		};
+
+		pio: pinctrl at 01c20800 {
+			pinctrl-names = "default";
+			pinctrl-0 = <&hackberry_hogs>;
+
+			hackberry_hogs: hogs at 0 {
+				allwinner,pins = "PH19";
+				allwinner,function = "gpio_out";
+				allwinner,drive = <0>;
+				allwinner,pull = <0>;
+			};
+		};
+
 		uart0: serial at 01c28000 {
 			pinctrl-names = "default";
 			pinctrl-0 = <&uart0_pins_a>;
 			status = "okay";
 		};
 	};
+
+	regulators {
+		compatible = "simple-bus";
+
+		reg_emac_3v3: emac-3v3 {
+			compatible = "regulator-fixed";
+			regulator-name = "emac-3v3";
+			regulator-min-microvolt = <3300000>;
+			regulator-max-microvolt = <3300000>;
+			enable-active-high;
+			gpio = <&pio 7 19 0>;
+		};
+	};
 };
-- 
1.8.1.2



From linux at prisktech.co.nz  Mon Apr 29 15:46:11 2013
From: linux at prisktech.co.nz (Tony Prisk)
Date: Tue, 30 Apr 2013 07:46:11 +1200
Subject: [PATCHv3 2/3] net: velocity: Convert to generic dma functions
In-Reply-To: <1367264772-4557-1-git-send-email-linux@prisktech.co.nz>
References: <1367264772-4557-1-git-send-email-linux@prisktech.co.nz>
Message-ID: <1367264772-4557-3-git-send-email-linux@prisktech.co.nz>

Remove the pci_* dma functions and replace with the more generic
versions.

In preparation of adding platform support, a new struct device *dev
is added to struct velocity_info which can be used by both the pci
and platform code.

Signed-off-by: Tony Prisk <linux at prisktech.co.nz>
---
 drivers/net/ethernet/via/via-velocity.c |   51 +++++++++++++++----------------
 drivers/net/ethernet/via/via-velocity.h |    1 +
 2 files changed, 26 insertions(+), 26 deletions(-)

diff --git a/drivers/net/ethernet/via/via-velocity.c b/drivers/net/ethernet/via/via-velocity.c
index 187eef3..5996cee 100644
--- a/drivers/net/ethernet/via/via-velocity.c
+++ b/drivers/net/ethernet/via/via-velocity.c
@@ -46,6 +46,7 @@
 #include <linux/types.h>
 #include <linux/bitops.h>
 #include <linux/init.h>
+#include <linux/dma-mapping.h>
 #include <linux/mm.h>
 #include <linux/errno.h>
 #include <linux/ioport.h>
@@ -1459,7 +1460,6 @@ static int velocity_init_dma_rings(struct velocity_info *vptr)
 	struct velocity_opt *opt = &vptr->options;
 	const unsigned int rx_ring_size = opt->numrx * sizeof(struct rx_desc);
 	const unsigned int tx_ring_size = opt->numtx * sizeof(struct tx_desc);
-	struct pci_dev *pdev = vptr->pdev;
 	dma_addr_t pool_dma;
 	void *pool;
 	unsigned int i;
@@ -1467,13 +1467,13 @@ static int velocity_init_dma_rings(struct velocity_info *vptr)
 	/*
 	 * Allocate all RD/TD rings a single pool.
 	 *
-	 * pci_alloc_consistent() fulfills the requirement for 64 bytes
+	 * dma_alloc_coherent() fulfills the requirement for 64 bytes
 	 * alignment
 	 */
-	pool = pci_alloc_consistent(pdev, tx_ring_size * vptr->tx.numq +
-				    rx_ring_size, &pool_dma);
+	pool = dma_alloc_coherent(vptr->dev, tx_ring_size * vptr->tx.numq +
+				    rx_ring_size, &pool_dma, GFP_ATOMIC);
 	if (!pool) {
-		dev_err(&pdev->dev, "%s : DMA memory allocation failed.\n",
+		dev_err(vptr->dev, "%s : DMA memory allocation failed.\n",
 			vptr->netdev->name);
 		return -ENOMEM;
 	}
@@ -1524,8 +1524,8 @@ static int velocity_alloc_rx_buf(struct velocity_info *vptr, int idx)
 	 */
 	skb_reserve(rd_info->skb,
 			64 - ((unsigned long) rd_info->skb->data & 63));
-	rd_info->skb_dma = pci_map_single(vptr->pdev, rd_info->skb->data,
-					vptr->rx.buf_sz, PCI_DMA_FROMDEVICE);
+	rd_info->skb_dma = dma_map_single(vptr->dev, rd_info->skb->data,
+					vptr->rx.buf_sz, DMA_FROM_DEVICE);
 
 	/*
 	 *	Fill in the descriptor to match
@@ -1588,8 +1588,8 @@ static void velocity_free_rd_ring(struct velocity_info *vptr)
 
 		if (!rd_info->skb)
 			continue;
-		pci_unmap_single(vptr->pdev, rd_info->skb_dma, vptr->rx.buf_sz,
-				 PCI_DMA_FROMDEVICE);
+		dma_unmap_single(vptr->dev, rd_info->skb_dma, vptr->rx.buf_sz,
+				 DMA_FROM_DEVICE);
 		rd_info->skb_dma = 0;
 
 		dev_kfree_skb(rd_info->skb);
@@ -1670,7 +1670,7 @@ static void velocity_free_dma_rings(struct velocity_info *vptr)
 	const int size = vptr->options.numrx * sizeof(struct rx_desc) +
 		vptr->options.numtx * sizeof(struct tx_desc) * vptr->tx.numq;
 
-	pci_free_consistent(vptr->pdev, size, vptr->rx.ring, vptr->rx.pool_dma);
+	dma_free_coherent(vptr->dev, size, vptr->rx.ring, vptr->rx.pool_dma);
 }
 
 static int velocity_init_rings(struct velocity_info *vptr, int mtu)
@@ -1727,8 +1727,8 @@ static void velocity_free_tx_buf(struct velocity_info *vptr,
 				pktlen = max_t(size_t, pktlen,
 						td->td_buf[i].size & ~TD_QUEUE);
 
-			pci_unmap_single(vptr->pdev, tdinfo->skb_dma[i],
-					le16_to_cpu(pktlen), PCI_DMA_TODEVICE);
+			dma_unmap_single(vptr->dev, tdinfo->skb_dma[i],
+					le16_to_cpu(pktlen), DMA_TO_DEVICE);
 		}
 	}
 	dev_kfree_skb_irq(skb);
@@ -1750,8 +1750,8 @@ static void velocity_free_td_ring_entry(struct velocity_info *vptr,
 	if (td_info->skb) {
 		for (i = 0; i < td_info->nskb_dma; i++) {
 			if (td_info->skb_dma[i]) {
-				pci_unmap_single(vptr->pdev, td_info->skb_dma[i],
-					td_info->skb->len, PCI_DMA_TODEVICE);
+				dma_unmap_single(vptr->dev, td_info->skb_dma[i],
+					td_info->skb->len, DMA_TO_DEVICE);
 				td_info->skb_dma[i] = 0;
 			}
 		}
@@ -2029,7 +2029,6 @@ static inline void velocity_iph_realign(struct velocity_info *vptr,
  */
 static int velocity_receive_frame(struct velocity_info *vptr, int idx)
 {
-	void (*pci_action)(struct pci_dev *, dma_addr_t, size_t, int);
 	struct net_device_stats *stats = &vptr->netdev->stats;
 	struct velocity_rd_info *rd_info = &(vptr->rx.info[idx]);
 	struct rx_desc *rd = &(vptr->rx.ring[idx]);
@@ -2047,8 +2046,8 @@ static int velocity_receive_frame(struct velocity_info *vptr, int idx)
 
 	skb = rd_info->skb;
 
-	pci_dma_sync_single_for_cpu(vptr->pdev, rd_info->skb_dma,
-				    vptr->rx.buf_sz, PCI_DMA_FROMDEVICE);
+	dma_sync_single_for_cpu(vptr->dev, rd_info->skb_dma,
+				    vptr->rx.buf_sz, DMA_FROM_DEVICE);
 
 	/*
 	 *	Drop frame not meeting IEEE 802.3
@@ -2061,19 +2060,18 @@ static int velocity_receive_frame(struct velocity_info *vptr, int idx)
 		}
 	}
 
-	pci_action = pci_dma_sync_single_for_device;
-
 	velocity_rx_csum(rd, skb);
 
 	if (velocity_rx_copy(&skb, pkt_len, vptr) < 0) {
 		velocity_iph_realign(vptr, skb, pkt_len);
-		pci_action = pci_unmap_single;
 		rd_info->skb = NULL;
+		dma_unmap_single(vptr->dev, rd_info->skb_dma, vptr->rx.buf_sz,
+				 DMA_FROM_DEVICE);
+	} else {
+		dma_sync_single_for_device(vptr->dev, rd_info->skb_dma,
+					   vptr->rx.buf_sz, DMA_FROM_DEVICE);
 	}
 
-	pci_action(vptr->pdev, rd_info->skb_dma, vptr->rx.buf_sz,
-		   PCI_DMA_FROMDEVICE);
-
 	skb_put(skb, pkt_len - 4);
 	skb->protocol = eth_type_trans(skb, vptr->netdev);
 
@@ -2550,7 +2548,8 @@ static netdev_tx_t velocity_xmit(struct sk_buff *skb,
 	 *	add it to the transmit ring.
 	 */
 	tdinfo->skb = skb;
-	tdinfo->skb_dma[0] = pci_map_single(vptr->pdev, skb->data, pktlen, PCI_DMA_TODEVICE);
+	tdinfo->skb_dma[0] = dma_map_single(vptr->dev, skb->data, pktlen,
+								DMA_TO_DEVICE);
 	td_ptr->tdesc0.len = cpu_to_le16(pktlen);
 	td_ptr->td_buf[0].pa_low = cpu_to_le32(tdinfo->skb_dma[0]);
 	td_ptr->td_buf[0].pa_high = 0;
@@ -2560,7 +2559,7 @@ static netdev_tx_t velocity_xmit(struct sk_buff *skb,
 	for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) {
 		const skb_frag_t *frag = &skb_shinfo(skb)->frags[i];
 
-		tdinfo->skb_dma[i + 1] = skb_frag_dma_map(&vptr->pdev->dev,
+		tdinfo->skb_dma[i + 1] = skb_frag_dma_map(vptr->dev,
 							  frag, 0,
 							  skb_frag_size(frag),
 							  DMA_TO_DEVICE);
@@ -2637,6 +2636,7 @@ static void velocity_init_info(struct pci_dev *pdev, struct velocity_info *vptr,
 {
 	memset(vptr, 0, sizeof(struct velocity_info));
 
+	vptr->dev = &pdev->dev;
 	vptr->pdev = pdev;
 	vptr->chip_id = info->chip_id;
 	vptr->tx.numq = info->txqueue;
@@ -2744,7 +2744,6 @@ static int velocity_found1(struct pci_dev *pdev,
 	SET_NETDEV_DEV(dev, &pdev->dev);
 	vptr = netdev_priv(dev);
 
-
 	if (first) {
 		printk(KERN_INFO "%s Ver. %s\n",
 			VELOCITY_FULL_DRV_NAM, VELOCITY_VERSION);
diff --git a/drivers/net/ethernet/via/via-velocity.h b/drivers/net/ethernet/via/via-velocity.h
index ff8d7828..c38bbae 100644
--- a/drivers/net/ethernet/via/via-velocity.h
+++ b/drivers/net/ethernet/via/via-velocity.h
@@ -1434,6 +1434,7 @@ struct velocity_opt {
 #define GET_RD_BY_IDX(vptr, idx)   (vptr->rd_ring[idx])
 
 struct velocity_info {
+	struct device *dev;
 	struct pci_dev *pdev;
 	struct net_device *netdev;
 
-- 
1.7.9.5



From linux at prisktech.co.nz  Mon Apr 29 15:46:09 2013
From: linux at prisktech.co.nz (Tony Prisk)
Date: Tue, 30 Apr 2013 07:46:09 +1200
Subject: [PATCHv3 0/3] Add support for velocity network driver on platform
 devices
Message-ID: <1367264772-4557-1-git-send-email-linux@prisktech.co.nz>

v3 changes:
Rebased against net-next.
Fix errors in pm code.

v2 changes:
Drop patch #1 as requested by David Miller.
Correct the PHYID_ICPLUS_IP101A MII bits - should be ON, rather than OFF.
Read the platform rev_id from the correct register [regs->rev_id]. It's possible
this would work for the PCI version as well and would remove the need for the
'if (pci)' test to set vptr->rev_id.

v1:
The first three patches are general tidyup.

[DROPPED] Patch ## just alphabetizes the #includes to make it easier to read.

Patch #1 replaces vptr->dev with vptr->netdev, in preparation of adding a
struct device *dev in Patch #3

Patch #2 replaces the pci dma functions with the generic versions.

I have build tested these patches but don't have a PCI velocity to run-test it.
I can't see that they should introduce any problems as it is all renames and
function swapping.

Patch #3 adds support for the velocity driver on devicetree platform devices.
Binding document included. This patch is compile-tested for PCI, and boot
tested on a VIA APC8750.

I think it would be pertinent to get some tested-by's for PCI users.

Regards
Tony Prisk

Tony Prisk (3):
  net: velocity: Rename vptr->dev to vptr->netdev
  net: velocity: Convert to generic dma functions
  net: velocity: Add platform device support to VIA velocity driver

 .../devicetree/bindings/net/via-velocity.txt       |   20 +
 drivers/net/ethernet/via/Kconfig                   |    3 +-
 drivers/net/ethernet/via/via-velocity.c            |  563 ++++++++++++++------
 drivers/net/ethernet/via/via-velocity.h            |   35 +-
 4 files changed, 454 insertions(+), 167 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/net/via-velocity.txt

-- 
1.7.9.5



From linux at prisktech.co.nz  Mon Apr 29 15:46:10 2013
From: linux at prisktech.co.nz (Tony Prisk)
Date: Tue, 30 Apr 2013 07:46:10 +1200
Subject: [PATCHv3 1/3] net: velocity: Rename vptr->dev to vptr->netdev
In-Reply-To: <1367264772-4557-1-git-send-email-linux@prisktech.co.nz>
References: <1367264772-4557-1-git-send-email-linux@prisktech.co.nz>
Message-ID: <1367264772-4557-2-git-send-email-linux@prisktech.co.nz>

Improve the clarity of the code in preparation for converting the
dma functions to generic versions, which require a struct device *.

This makes it possible to store a 'struct device *dev' in the
velocity_info structure.

Signed-off-by: Tony Prisk <linux at prisktech.co.nz>
---
 drivers/net/ethernet/via/via-velocity.c |   66 +++++++++++++++----------------
 drivers/net/ethernet/via/via-velocity.h |    4 +-
 2 files changed, 35 insertions(+), 35 deletions(-)

diff --git a/drivers/net/ethernet/via/via-velocity.c b/drivers/net/ethernet/via/via-velocity.c
index fb62489..187eef3 100644
--- a/drivers/net/ethernet/via/via-velocity.c
+++ b/drivers/net/ethernet/via/via-velocity.c
@@ -998,9 +998,9 @@ static void velocity_print_link_status(struct velocity_info *vptr)
 {
 
 	if (vptr->mii_status & VELOCITY_LINK_FAIL) {
-		VELOCITY_PRT(MSG_LEVEL_INFO, KERN_NOTICE "%s: failed to detect cable link\n", vptr->dev->name);
+		VELOCITY_PRT(MSG_LEVEL_INFO, KERN_NOTICE "%s: failed to detect cable link\n", vptr->netdev->name);
 	} else if (vptr->options.spd_dpx == SPD_DPX_AUTO) {
-		VELOCITY_PRT(MSG_LEVEL_INFO, KERN_NOTICE "%s: Link auto-negotiation", vptr->dev->name);
+		VELOCITY_PRT(MSG_LEVEL_INFO, KERN_NOTICE "%s: Link auto-negotiation", vptr->netdev->name);
 
 		if (vptr->mii_status & VELOCITY_SPEED_1000)
 			VELOCITY_PRT(MSG_LEVEL_INFO, " speed 1000M bps");
@@ -1014,7 +1014,7 @@ static void velocity_print_link_status(struct velocity_info *vptr)
 		else
 			VELOCITY_PRT(MSG_LEVEL_INFO, " half duplex\n");
 	} else {
-		VELOCITY_PRT(MSG_LEVEL_INFO, KERN_NOTICE "%s: Link forced", vptr->dev->name);
+		VELOCITY_PRT(MSG_LEVEL_INFO, KERN_NOTICE "%s: Link forced", vptr->netdev->name);
 		switch (vptr->options.spd_dpx) {
 		case SPD_DPX_1000_FULL:
 			VELOCITY_PRT(MSG_LEVEL_INFO, " speed 1000M bps full duplex\n");
@@ -1319,7 +1319,7 @@ static void velocity_init_registers(struct velocity_info *vptr,
 	case VELOCITY_INIT_RESET:
 	case VELOCITY_INIT_WOL:
 
-		netif_stop_queue(vptr->dev);
+		netif_stop_queue(vptr->netdev);
 
 		/*
 		 *	Reset RX to prevent RX pointer not on the 4X location
@@ -1332,7 +1332,7 @@ static void velocity_init_registers(struct velocity_info *vptr,
 		if (velocity_set_media_mode(vptr, mii_status) != VELOCITY_LINK_CHANGE) {
 			velocity_print_link_status(vptr);
 			if (!(vptr->mii_status & VELOCITY_LINK_FAIL))
-				netif_wake_queue(vptr->dev);
+				netif_wake_queue(vptr->netdev);
 		}
 
 		enable_flow_control_ability(vptr);
@@ -1354,7 +1354,7 @@ static void velocity_init_registers(struct velocity_info *vptr,
 
 		mac_eeprom_reload(regs);
 		for (i = 0; i < 6; i++)
-			writeb(vptr->dev->dev_addr[i], &(regs->PAR[i]));
+			writeb(vptr->netdev->dev_addr[i], &(regs->PAR[i]));
 
 		/*
 		 *	clear Pre_ACPI bit.
@@ -1377,7 +1377,7 @@ static void velocity_init_registers(struct velocity_info *vptr,
 		/*
 		 *	Set packet filter: Receive directed and broadcast address
 		 */
-		velocity_set_multi(vptr->dev);
+		velocity_set_multi(vptr->netdev);
 
 		/*
 		 *	Enable MII auto-polling
@@ -1404,14 +1404,14 @@ static void velocity_init_registers(struct velocity_info *vptr,
 		writel((CR0_DPOLL | CR0_TXON | CR0_RXON | CR0_STRT), &regs->CR0Set);
 
 		mii_status = velocity_get_opt_media_mode(vptr);
-		netif_stop_queue(vptr->dev);
+		netif_stop_queue(vptr->netdev);
 
 		mii_init(vptr, mii_status);
 
 		if (velocity_set_media_mode(vptr, mii_status) != VELOCITY_LINK_CHANGE) {
 			velocity_print_link_status(vptr);
 			if (!(vptr->mii_status & VELOCITY_LINK_FAIL))
-				netif_wake_queue(vptr->dev);
+				netif_wake_queue(vptr->netdev);
 		}
 
 		enable_flow_control_ability(vptr);
@@ -1474,7 +1474,7 @@ static int velocity_init_dma_rings(struct velocity_info *vptr)
 				    rx_ring_size, &pool_dma);
 	if (!pool) {
 		dev_err(&pdev->dev, "%s : DMA memory allocation failed.\n",
-			vptr->dev->name);
+			vptr->netdev->name);
 		return -ENOMEM;
 	}
 
@@ -1514,7 +1514,7 @@ static int velocity_alloc_rx_buf(struct velocity_info *vptr, int idx)
 	struct rx_desc *rd = &(vptr->rx.ring[idx]);
 	struct velocity_rd_info *rd_info = &(vptr->rx.info[idx]);
 
-	rd_info->skb = netdev_alloc_skb(vptr->dev, vptr->rx.buf_sz + 64);
+	rd_info->skb = netdev_alloc_skb(vptr->netdev, vptr->rx.buf_sz + 64);
 	if (rd_info->skb == NULL)
 		return -ENOMEM;
 
@@ -1620,7 +1620,7 @@ static int velocity_init_rd_ring(struct velocity_info *vptr)
 
 	if (velocity_rx_refill(vptr) != vptr->options.numrx) {
 		VELOCITY_PRT(MSG_LEVEL_ERR, KERN_ERR
-			"%s: failed to allocate RX buffer.\n", vptr->dev->name);
+			"%s: failed to allocate RX buffer.\n", vptr->netdev->name);
 		velocity_free_rd_ring(vptr);
 		goto out;
 	}
@@ -1809,7 +1809,7 @@ static void velocity_error(struct velocity_info *vptr, int status)
 		printk(KERN_ERR "TD structure error TDindex=%hx\n", readw(&regs->TDIdx[0]));
 		BYTE_REG_BITS_ON(TXESR_TDSTR, &regs->TXESR);
 		writew(TRDCSR_RUN, &regs->TDCSRClr);
-		netif_stop_queue(vptr->dev);
+		netif_stop_queue(vptr->netdev);
 
 		/* FIXME: port over the pci_device_failed code and use it
 		   here */
@@ -1850,10 +1850,10 @@ static void velocity_error(struct velocity_info *vptr, int status)
 
 		if (linked) {
 			vptr->mii_status &= ~VELOCITY_LINK_FAIL;
-			netif_carrier_on(vptr->dev);
+			netif_carrier_on(vptr->netdev);
 		} else {
 			vptr->mii_status |= VELOCITY_LINK_FAIL;
-			netif_carrier_off(vptr->dev);
+			netif_carrier_off(vptr->netdev);
 		}
 
 		velocity_print_link_status(vptr);
@@ -1867,9 +1867,9 @@ static void velocity_error(struct velocity_info *vptr, int status)
 		enable_mii_autopoll(regs);
 
 		if (vptr->mii_status & VELOCITY_LINK_FAIL)
-			netif_stop_queue(vptr->dev);
+			netif_stop_queue(vptr->netdev);
 		else
-			netif_wake_queue(vptr->dev);
+			netif_wake_queue(vptr->netdev);
 
 	}
 	if (status & ISR_MIBFI)
@@ -1894,7 +1894,7 @@ static int velocity_tx_srv(struct velocity_info *vptr)
 	int idx;
 	int works = 0;
 	struct velocity_td_info *tdinfo;
-	struct net_device_stats *stats = &vptr->dev->stats;
+	struct net_device_stats *stats = &vptr->netdev->stats;
 
 	for (qnum = 0; qnum < vptr->tx.numq; qnum++) {
 		for (idx = vptr->tx.tail[qnum]; vptr->tx.used[qnum] > 0;
@@ -1939,9 +1939,9 @@ static int velocity_tx_srv(struct velocity_info *vptr)
 	 *	Look to see if we should kick the transmit network
 	 *	layer for more work.
 	 */
-	if (netif_queue_stopped(vptr->dev) && (full == 0) &&
+	if (netif_queue_stopped(vptr->netdev) && (full == 0) &&
 	    (!(vptr->mii_status & VELOCITY_LINK_FAIL))) {
-		netif_wake_queue(vptr->dev);
+		netif_wake_queue(vptr->netdev);
 	}
 	return works;
 }
@@ -1989,7 +1989,7 @@ static int velocity_rx_copy(struct sk_buff **rx_skb, int pkt_size,
 	if (pkt_size < rx_copybreak) {
 		struct sk_buff *new_skb;
 
-		new_skb = netdev_alloc_skb_ip_align(vptr->dev, pkt_size);
+		new_skb = netdev_alloc_skb_ip_align(vptr->netdev, pkt_size);
 		if (new_skb) {
 			new_skb->ip_summed = rx_skb[0]->ip_summed;
 			skb_copy_from_linear_data(*rx_skb, new_skb->data, pkt_size);
@@ -2030,14 +2030,14 @@ static inline void velocity_iph_realign(struct velocity_info *vptr,
 static int velocity_receive_frame(struct velocity_info *vptr, int idx)
 {
 	void (*pci_action)(struct pci_dev *, dma_addr_t, size_t, int);
-	struct net_device_stats *stats = &vptr->dev->stats;
+	struct net_device_stats *stats = &vptr->netdev->stats;
 	struct velocity_rd_info *rd_info = &(vptr->rx.info[idx]);
 	struct rx_desc *rd = &(vptr->rx.ring[idx]);
 	int pkt_len = le16_to_cpu(rd->rdesc0.len) & 0x3fff;
 	struct sk_buff *skb;
 
 	if (rd->rdesc0.RSR & (RSR_STP | RSR_EDP)) {
-		VELOCITY_PRT(MSG_LEVEL_VERBOSE, KERN_ERR " %s : the received frame span multple RDs.\n", vptr->dev->name);
+		VELOCITY_PRT(MSG_LEVEL_VERBOSE, KERN_ERR " %s : the received frame span multple RDs.\n", vptr->netdev->name);
 		stats->rx_length_errors++;
 		return -EINVAL;
 	}
@@ -2075,7 +2075,7 @@ static int velocity_receive_frame(struct velocity_info *vptr, int idx)
 		   PCI_DMA_FROMDEVICE);
 
 	skb_put(skb, pkt_len - 4);
-	skb->protocol = eth_type_trans(skb, vptr->dev);
+	skb->protocol = eth_type_trans(skb, vptr->netdev);
 
 	if (rd->rdesc0.RSR & RSR_DETAG) {
 		u16 vid = swab16(le16_to_cpu(rd->rdesc1.PQTAG));
@@ -2100,7 +2100,7 @@ static int velocity_receive_frame(struct velocity_info *vptr, int idx)
  */
 static int velocity_rx_srv(struct velocity_info *vptr, int budget_left)
 {
-	struct net_device_stats *stats = &vptr->dev->stats;
+	struct net_device_stats *stats = &vptr->netdev->stats;
 	int rd_curr = vptr->rx.curr;
 	int works = 0;
 
@@ -2292,7 +2292,7 @@ static int velocity_change_mtu(struct net_device *dev, int new_mtu)
 
 	if ((new_mtu < VELOCITY_MIN_MTU) || new_mtu > (VELOCITY_MAX_MTU)) {
 		VELOCITY_PRT(MSG_LEVEL_ERR, KERN_NOTICE "%s: Invalid MTU.\n",
-				vptr->dev->name);
+				vptr->netdev->name);
 		ret = -EINVAL;
 		goto out_0;
 	}
@@ -2314,7 +2314,7 @@ static int velocity_change_mtu(struct net_device *dev, int new_mtu)
 			goto out_0;
 		}
 
-		tmp_vptr->dev = dev;
+		tmp_vptr->netdev = dev;
 		tmp_vptr->pdev = vptr->pdev;
 		tmp_vptr->options = vptr->options;
 		tmp_vptr->tx.numq = vptr->tx.numq;
@@ -2692,7 +2692,7 @@ static int velocity_get_pci_info(struct velocity_info *vptr,
  */
 static void velocity_print_info(struct velocity_info *vptr)
 {
-	struct net_device *dev = vptr->dev;
+	struct net_device *dev = vptr->netdev;
 
 	printk(KERN_INFO "%s: %s\n", dev->name, get_chip_name(vptr->chip_id));
 	printk(KERN_INFO "%s: Ethernet Address: %pM\n",
@@ -2755,7 +2755,7 @@ static int velocity_found1(struct pci_dev *pdev,
 
 	velocity_init_info(pdev, vptr, info);
 
-	vptr->dev = dev;
+	vptr->netdev = dev;
 
 	ret = pci_enable_device(pdev);
 	if (ret < 0)
@@ -3010,10 +3010,10 @@ static int velocity_suspend(struct pci_dev *pdev, pm_message_t state)
 	struct velocity_info *vptr = netdev_priv(dev);
 	unsigned long flags;
 
-	if (!netif_running(vptr->dev))
+	if (!netif_running(vptr->netdev))
 		return 0;
 
-	netif_device_detach(vptr->dev);
+	netif_device_detach(vptr->netdev);
 
 	spin_lock_irqsave(&vptr->lock, flags);
 	pci_save_state(pdev);
@@ -3078,7 +3078,7 @@ static int velocity_resume(struct pci_dev *pdev)
 	unsigned long flags;
 	int i;
 
-	if (!netif_running(vptr->dev))
+	if (!netif_running(vptr->netdev))
 		return 0;
 
 	pci_set_power_state(pdev, PCI_D0);
@@ -3101,7 +3101,7 @@ static int velocity_resume(struct pci_dev *pdev)
 
 	mac_enable_int(vptr->mac_regs);
 	spin_unlock_irqrestore(&vptr->lock, flags);
-	netif_device_attach(vptr->dev);
+	netif_device_attach(vptr->netdev);
 
 	return 0;
 }
diff --git a/drivers/net/ethernet/via/via-velocity.h b/drivers/net/ethernet/via/via-velocity.h
index 4cb9f13..ff8d7828 100644
--- a/drivers/net/ethernet/via/via-velocity.h
+++ b/drivers/net/ethernet/via/via-velocity.h
@@ -1435,7 +1435,7 @@ struct velocity_opt {
 
 struct velocity_info {
 	struct pci_dev *pdev;
-	struct net_device *dev;
+	struct net_device *netdev;
 
 	unsigned long active_vlans[BITS_TO_LONGS(VLAN_N_VID)];
 	u8 ip_addr[4];
@@ -1514,7 +1514,7 @@ static inline int velocity_get_ip(struct velocity_info *vptr)
 	int res = -ENOENT;
 
 	rcu_read_lock();
-	in_dev = __in_dev_get_rcu(vptr->dev);
+	in_dev = __in_dev_get_rcu(vptr->netdev);
 	if (in_dev != NULL) {
 		ifa = (struct in_ifaddr *) in_dev->ifa_list;
 		if (ifa != NULL) {
-- 
1.7.9.5



From linux at prisktech.co.nz  Mon Apr 29 15:46:12 2013
From: linux at prisktech.co.nz (Tony Prisk)
Date: Tue, 30 Apr 2013 07:46:12 +1200
Subject: [PATCHv3 3/3] net: velocity: Add platform device support to VIA
 velocity driver
In-Reply-To: <1367264772-4557-1-git-send-email-linux@prisktech.co.nz>
References: <1367264772-4557-1-git-send-email-linux@prisktech.co.nz>
Message-ID: <1367264772-4557-4-git-send-email-linux@prisktech.co.nz>

Add support for the VIA Velocity network driver to be bound to a
OF created platform device.

Signed-off-by: Tony Prisk <linux at prisktech.co.nz>
---
 .../devicetree/bindings/net/via-velocity.txt       |   20 +
 drivers/net/ethernet/via/Kconfig                   |    3 +-
 drivers/net/ethernet/via/via-velocity.c            |  452 +++++++++++++++-----
 drivers/net/ethernet/via/via-velocity.h            |   30 +-
 4 files changed, 396 insertions(+), 109 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/net/via-velocity.txt

diff --git a/Documentation/devicetree/bindings/net/via-velocity.txt b/Documentation/devicetree/bindings/net/via-velocity.txt
new file mode 100644
index 0000000..b3db469
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/via-velocity.txt
@@ -0,0 +1,20 @@
+* VIA Velocity 10/100/1000 Network Controller
+
+Required properties:
+- compatible : Should be "via,velocity-vt6110"
+- reg : Address and length of the io space
+- interrupts : Should contain the controller interrupt line
+
+Optional properties:
+- no-eeprom : PCI network cards use an external EEPROM to store data. Embedded
+	devices quite often set this data in uboot and do not provide an eeprom.
+	Specify this option if you have no external eeprom.
+
+Examples:
+
+eth0 at d8004000 {
+	compatible = "via,velocity-vt6110";
+	reg = <0xd8004000 0x400>;
+	interrupts = <10>;
+	no-eeprom;
+};
diff --git a/drivers/net/ethernet/via/Kconfig b/drivers/net/ethernet/via/Kconfig
index 68a9ba6..6a87097 100644
--- a/drivers/net/ethernet/via/Kconfig
+++ b/drivers/net/ethernet/via/Kconfig
@@ -5,7 +5,6 @@
 config NET_VENDOR_VIA
 	bool "VIA devices"
 	default y
-	depends on PCI
 	---help---
 	  If you have a network (Ethernet) card belonging to this class, say Y
 	  and read the Ethernet-HOWTO, available from
@@ -45,7 +44,7 @@ config VIA_RHINE_MMIO
 
 config VIA_VELOCITY
 	tristate "VIA Velocity support"
-	depends on PCI
+	depends on (PCI || USE_OF)
 	select CRC32
 	select CRC_CCITT
 	select NET_CORE
diff --git a/drivers/net/ethernet/via/via-velocity.c b/drivers/net/ethernet/via/via-velocity.c
index 5996cee..3a87f13 100644
--- a/drivers/net/ethernet/via/via-velocity.c
+++ b/drivers/net/ethernet/via/via-velocity.c
@@ -65,7 +65,11 @@
 #include <linux/if.h>
 #include <linux/uaccess.h>
 #include <linux/proc_fs.h>
+#include <linux/of_address.h>
+#include <linux/of_device.h>
+#include <linux/of_irq.h>
 #include <linux/inetdevice.h>
+#include <linux/platform_device.h>
 #include <linux/reboot.h>
 #include <linux/ethtool.h>
 #include <linux/mii.h>
@@ -84,6 +88,16 @@
 static int velocity_nics;
 static int msglevel = MSG_LEVEL_INFO;
 
+static void velocity_set_power_state(struct velocity_info *vptr, char state)
+{
+	void *addr = vptr->mac_regs;
+
+	if (vptr->bustype == BUS_PCI)
+		pci_set_power_state(vptr->pdev, state);
+	else
+		writeb(state, addr + 0x154);
+}
+
 /**
  *	mac_get_cam_mask	-	Read a CAM mask
  *	@regs: register block for this velocity
@@ -362,12 +376,24 @@ static struct velocity_info_tbl chip_info_table[] = {
  *	Describe the PCI device identifiers that we support in this
  *	device driver. Used for hotplug autoloading.
  */
-static DEFINE_PCI_DEVICE_TABLE(velocity_id_table) = {
+#ifdef CONFIG_PCI
+static DEFINE_PCI_DEVICE_TABLE(velocity_pci_id_table) = {
 	{ PCI_DEVICE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_612X) },
 	{ }
 };
 
-MODULE_DEVICE_TABLE(pci, velocity_id_table);
+MODULE_DEVICE_TABLE(pci, velocity_pci_id_table);
+#endif
+
+/**
+ *	Describe the OF device identifiers that we support in this
+ *	device driver. Used for devicetree nodes.
+ */
+static struct of_device_id velocity_of_ids[] = {
+	{ .compatible = "via,velocity-vt6110", .data = &chip_info_table[0] },
+	{ /* Sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, velocity_of_ids);
 
 /**
  *	get_chip_name	- 	identifier to name
@@ -386,29 +412,6 @@ static const char *get_chip_name(enum chip_type chip_id)
 }
 
 /**
- *	velocity_remove1	-	device unplug
- *	@pdev: PCI device being removed
- *
- *	Device unload callback. Called on an unplug or on module
- *	unload for each active device that is present. Disconnects
- *	the device from the network layer and frees all the resources
- */
-static void velocity_remove1(struct pci_dev *pdev)
-{
-	struct net_device *dev = pci_get_drvdata(pdev);
-	struct velocity_info *vptr = netdev_priv(dev);
-
-	unregister_netdev(dev);
-	iounmap(vptr->mac_regs);
-	pci_release_regions(pdev);
-	pci_disable_device(pdev);
-	pci_set_drvdata(pdev, NULL);
-	free_netdev(dev);
-
-	velocity_nics--;
-}
-
-/**
  *	velocity_set_int_opt	-	parser for integer options
  *	@opt: pointer to option value
  *	@val: value the user requested (or -1 for default)
@@ -1181,6 +1184,14 @@ static void mii_init(struct velocity_info *vptr, u32 mii_status)
 	u16 BMCR;
 
 	switch (PHYID_GET_PHY_ID(vptr->phy_id)) {
+	case PHYID_ICPLUS_IP101A:
+		MII_REG_BITS_ON((ADVERTISE_PAUSE_ASYM | ADVERTISE_PAUSE_CAP), MII_ADVERTISE, vptr->mac_regs);
+		if (vptr->mii_status & VELOCITY_DUPLEX_FULL)
+			MII_REG_BITS_ON(TCSR_ECHODIS, MII_SREVISION, vptr->mac_regs);
+		else
+			MII_REG_BITS_OFF(TCSR_ECHODIS, MII_SREVISION, vptr->mac_regs);
+		MII_REG_BITS_ON(PLED_LALBE, MII_TPISTATUS, vptr->mac_regs);
+		break;
 	case PHYID_CICADA_CS8201:
 		/*
 		 *	Reset to hardware default
@@ -1353,9 +1364,12 @@ static void velocity_init_registers(struct velocity_info *vptr,
 		velocity_soft_reset(vptr);
 		mdelay(5);
 
-		mac_eeprom_reload(regs);
-		for (i = 0; i < 6; i++)
-			writeb(vptr->netdev->dev_addr[i], &(regs->PAR[i]));
+		if (!vptr->no_eeprom) {
+			mac_eeprom_reload(regs);
+			for (i = 0; i < 6; i++)
+				writeb(vptr->netdev->dev_addr[i],
+							&(regs->PAR[i]));
+		}
 
 		/*
 		 *	clear Pre_ACPI bit.
@@ -2233,15 +2247,15 @@ static int velocity_open(struct net_device *dev)
 		goto out;
 
 	/* Ensure chip is running */
-	pci_set_power_state(vptr->pdev, PCI_D0);
+	velocity_set_power_state(vptr, PCI_D0);
 
 	velocity_init_registers(vptr, VELOCITY_INIT_COLD);
 
-	ret = request_irq(vptr->pdev->irq, velocity_intr, IRQF_SHARED,
+	ret = request_irq(dev->irq, velocity_intr, IRQF_SHARED,
 			  dev->name, dev);
 	if (ret < 0) {
 		/* Power down the chip */
-		pci_set_power_state(vptr->pdev, PCI_D3hot);
+		velocity_set_power_state(vptr, PCI_D3hot);
 		velocity_free_rings(vptr);
 		goto out;
 	}
@@ -2413,7 +2427,7 @@ static int velocity_ioctl(struct net_device *dev, struct ifreq *rq, int cmd)
 	   saving then we need to bring the device back up to talk to it */
 
 	if (!netif_running(dev))
-		pci_set_power_state(vptr->pdev, PCI_D0);
+		velocity_set_power_state(vptr, PCI_D0);
 
 	switch (cmd) {
 	case SIOCGMIIPHY:	/* Get address of MII PHY in use. */
@@ -2426,7 +2440,7 @@ static int velocity_ioctl(struct net_device *dev, struct ifreq *rq, int cmd)
 		ret = -EOPNOTSUPP;
 	}
 	if (!netif_running(dev))
-		pci_set_power_state(vptr->pdev, PCI_D3hot);
+		velocity_set_power_state(vptr, PCI_D3hot);
 
 
 	return ret;
@@ -2492,7 +2506,7 @@ static int velocity_close(struct net_device *dev)
 	if (vptr->flags & VELOCITY_FLAGS_WOL_ENABLED)
 		velocity_get_ip(vptr);
 
-	free_irq(vptr->pdev->irq, dev);
+	free_irq(dev->irq, dev);
 
 	velocity_free_rings(vptr);
 
@@ -2631,13 +2645,25 @@ static const struct net_device_ops velocity_netdev_ops = {
  *	Set up the initial velocity_info struct for the device that has been
  *	discovered.
  */
-static void velocity_init_info(struct pci_dev *pdev, struct velocity_info *vptr,
-			       const struct velocity_info_tbl *info)
+static void velocity_init_info(void *pdev,
+				struct velocity_info *vptr,
+				const struct velocity_info_tbl *info,
+				enum velocity_bus_type bustype)
 {
+	struct pci_dev *pci_dev;
+	struct platform_device *platform_dev;
+
 	memset(vptr, 0, sizeof(struct velocity_info));
 
-	vptr->dev = &pdev->dev;
-	vptr->pdev = pdev;
+	if (bustype == BUS_PCI) {
+		pci_dev = pdev;
+		vptr->pdev = pci_dev;
+		vptr->dev = &pci_dev->dev;
+	} else {
+		platform_dev = pdev;
+		vptr->dev = &platform_dev->dev;
+	}
+
 	vptr->chip_id = info->chip_id;
 	vptr->tx.numq = info->txqueue;
 	vptr->multicast_limit = MCAM_SIZE;
@@ -2655,8 +2681,6 @@ static void velocity_init_info(struct pci_dev *pdev, struct velocity_info *vptr,
 static int velocity_get_pci_info(struct velocity_info *vptr,
 				 struct pci_dev *pdev)
 {
-	vptr->rev_id = pdev->revision;
-
 	pci_set_master(pdev);
 
 	vptr->ioaddr = pci_resource_start(pdev, 0);
@@ -2678,12 +2702,45 @@ static int velocity_get_pci_info(struct velocity_info *vptr,
 		dev_err(&pdev->dev, "region #1 is too small.\n");
 		return -EINVAL;
 	}
+
 	vptr->pdev = pdev;
 
 	return 0;
 }
 
 /**
+ *	velocity_get_platform_info - retrieve platform info for device
+ *	@vptr: velocity device
+ *	@pdev: platform device it matches
+ *
+ *	Retrieve the Platform configuration data that interests us
+ */
+static int velocity_get_platform_info(struct velocity_info *vptr,
+					struct platform_device *pdev)
+{
+	int ret;
+	struct resource res;
+
+	if (of_get_property(pdev->dev.of_node, "no-eeprom", NULL))
+		vptr->no_eeprom = 1;
+
+	ret = of_address_to_resource(pdev->dev.of_node, 0, &res);
+	if (ret) {
+		dev_err(&pdev->dev, "unable to find memory address\n");
+		return ret;
+	}
+
+	vptr->memaddr = res.start;
+
+	if (resource_size(&res) < VELOCITY_IO_SIZE) {
+		dev_err(&pdev->dev, "memory region is too small.\n");
+		return -EINVAL;
+	}
+
+	return 0;
+}
+
+/**
  *	velocity_print_info	-	per driver data
  *	@vptr: velocity
  *
@@ -2707,42 +2764,59 @@ static u32 velocity_get_link(struct net_device *dev)
 }
 
 /**
- *	velocity_found1		-	set up discovered velocity card
+ *	velocity_probe - set up discovered velocity device
  *	@pdev: PCI device
  *	@ent: PCI device table entry that matched
+ *	@bustype: bus that device is connected to
  *
  *	Configure a discovered adapter from scratch. Return a negative
  *	errno error code on failure paths.
  */
-static int velocity_found1(struct pci_dev *pdev,
-			   const struct pci_device_id *ent)
+static int velocity_probe(void *pdev,
+			   const struct pci_device_id *ent,
+			   enum velocity_bus_type bustype)
 {
 	static int first = 1;
-	struct net_device *dev;
+	struct pci_dev *pci_dev = NULL;
+	struct platform_device *platform_dev = NULL;
+	struct net_device *netdev;
+	struct device *dev;
+	const struct of_device_id *of_id;
 	int i;
 	const char *drv_string;
-	const struct velocity_info_tbl *info = &chip_info_table[ent->driver_data];
+	const struct velocity_info_tbl *info;
 	struct velocity_info *vptr;
 	struct mac_regs __iomem *regs;
+	int pci = (bustype == BUS_PCI) ? 1 : 0;
 	int ret = -ENOMEM;
 
+	if (pci) {
+		pci_dev = pdev;
+		dev = &pci_dev->dev;
+		info = &chip_info_table[ent->driver_data];
+	} else {
+		platform_dev = pdev;
+		dev = &platform_dev->dev;
+		of_id = of_match_device(velocity_of_ids, dev);
+		info = of_id->data;
+	}
+
 	/* FIXME: this driver, like almost all other ethernet drivers,
 	 * can support more than MAX_UNITS.
 	 */
 	if (velocity_nics >= MAX_UNITS) {
-		dev_notice(&pdev->dev, "already found %d NICs.\n",
-			   velocity_nics);
+		dev_notice(dev, "already found %d NICs.\n", velocity_nics);
 		return -ENODEV;
 	}
 
-	dev = alloc_etherdev(sizeof(struct velocity_info));
-	if (!dev)
+	netdev = alloc_etherdev(sizeof(struct velocity_info));
+	if (!netdev)
 		goto out;
 
 	/* Chain it all together */
 
-	SET_NETDEV_DEV(dev, &pdev->dev);
-	vptr = netdev_priv(dev);
+	SET_NETDEV_DEV(netdev, dev);
+	vptr = netdev_priv(netdev);
 
 	if (first) {
 		printk(KERN_INFO "%s Ver. %s\n",
@@ -2752,26 +2826,42 @@ static int velocity_found1(struct pci_dev *pdev,
 		first = 0;
 	}
 
-	velocity_init_info(pdev, vptr, info);
-
-	vptr->netdev = dev;
+	velocity_init_info(pdev, vptr, info, bustype);
+	vptr->bustype = bustype;
+	vptr->netdev = netdev;
 
-	ret = pci_enable_device(pdev);
-	if (ret < 0)
-		goto err_free_dev;
+	if (pci) {
+		ret = pci_enable_device(pci_dev);
+		if (ret < 0)
+			goto err_free_dev;
+		netdev->irq = pci_dev->irq;
+	} else {
+		netdev->irq =
+			irq_of_parse_and_map(platform_dev->dev.of_node, 0);
 
-	ret = velocity_get_pci_info(vptr, pdev);
-	if (ret < 0) {
-		/* error message already printed */
-		goto err_disable;
+		if (!netdev->irq) {
+			ret = -EINVAL;
+			goto err_free_dev;
+		}
 	}
 
-	ret = pci_request_regions(pdev, VELOCITY_NAME);
-	if (ret < 0) {
-		dev_err(&pdev->dev, "No PCI resources.\n");
-		goto err_disable;
+	if (pci) {
+		ret = velocity_get_pci_info(vptr, pci_dev);
+		if (ret < 0)
+			goto err_disable;
+
+		ret = pci_request_regions(pci_dev, VELOCITY_NAME);
+		if (ret < 0) {
+			dev_err(dev, "No PCI resources.\n");
+			goto err_disable;
+		}
+	} else {
+		ret = velocity_get_platform_info(vptr, platform_dev);
+		if (ret < 0)
+			goto err_disable;
 	}
 
+
 	regs = ioremap(vptr->memaddr, VELOCITY_IO_SIZE);
 	if (regs == NULL) {
 		ret = -EIO;
@@ -2780,13 +2870,18 @@ static int velocity_found1(struct pci_dev *pdev,
 
 	vptr->mac_regs = regs;
 
+	if (pci)
+		vptr->rev_id = pci_dev->revision;
+	else
+		vptr->rev_id = readb(&regs->rev_id);
+
 	mac_wol_reset(regs);
 
 	for (i = 0; i < 6; i++)
-		dev->dev_addr[i] = readb(&regs->PAR[i]);
+		netdev->dev_addr[i] = readb(&regs->PAR[i]);
 
 
-	drv_string = dev_driver_string(&pdev->dev);
+	drv_string = dev_driver_string(dev);
 
 	velocity_get_options(&vptr->options, velocity_nics, drv_string);
 
@@ -2807,30 +2902,34 @@ static int velocity_found1(struct pci_dev *pdev,
 
 	vptr->phy_id = MII_GET_PHY_ID(vptr->mac_regs);
 
-	dev->netdev_ops = &velocity_netdev_ops;
-	dev->ethtool_ops = &velocity_ethtool_ops;
-	netif_napi_add(dev, &vptr->napi, velocity_poll, VELOCITY_NAPI_WEIGHT);
+	netdev->netdev_ops = &velocity_netdev_ops;
+	netdev->ethtool_ops = &velocity_ethtool_ops;
+	netif_napi_add(netdev, &vptr->napi, velocity_poll, VELOCITY_NAPI_WEIGHT);
 
-	dev->hw_features = NETIF_F_IP_CSUM | NETIF_F_SG |
+	netdev->hw_features = NETIF_F_IP_CSUM | NETIF_F_SG |
 			   NETIF_F_HW_VLAN_CTAG_TX;
-	dev->features |= NETIF_F_HW_VLAN_CTAG_TX | NETIF_F_HW_VLAN_CTAG_FILTER |
-			 NETIF_F_HW_VLAN_CTAG_RX | NETIF_F_IP_CSUM;
+	netdev->features |= NETIF_F_HW_VLAN_CTAG_TX |
+			NETIF_F_HW_VLAN_CTAG_FILTER | NETIF_F_HW_VLAN_CTAG_RX |
+			NETIF_F_IP_CSUM;
 
-	ret = register_netdev(dev);
+	ret = register_netdev(netdev);
 	if (ret < 0)
 		goto err_iounmap;
 
-	if (!velocity_get_link(dev)) {
-		netif_carrier_off(dev);
+	if (!velocity_get_link(netdev)) {
+		netif_carrier_off(netdev);
 		vptr->mii_status |= VELOCITY_LINK_FAIL;
 	}
 
 	velocity_print_info(vptr);
-	pci_set_drvdata(pdev, dev);
+	if (pci)
+		pci_set_drvdata(pci_dev, netdev);
+	else
+		platform_set_drvdata(platform_dev, netdev);
 
 	/* and leave the chip powered down */
 
-	pci_set_power_state(pdev, PCI_D3hot);
+	velocity_set_power_state(vptr, PCI_D3hot);
 	velocity_nics++;
 out:
 	return ret;
@@ -2838,14 +2937,79 @@ out:
 err_iounmap:
 	iounmap(regs);
 err_release_res:
-	pci_release_regions(pdev);
+	if (pci)
+		pci_release_regions(pci_dev);
 err_disable:
-	pci_disable_device(pdev);
+	if (pci)
+		pci_disable_device(pci_dev);
 err_free_dev:
-	free_netdev(dev);
+	free_netdev(netdev);
 	goto out;
 }
 
+/**
+ *	velocity_remove	- device unplug
+ *	@pdev: PCI device being removed
+ *	@bustype: bus that device is connected to
+ *
+ *	Device unload callback. Called on an unplug or on module
+ *	unload for each active device that is present. Disconnects
+ *	the device from the network layer and frees all the resources
+ */
+static int velocity_remove(void *pdev, enum velocity_bus_type bustype)
+{
+	struct net_device *netdev;
+	struct velocity_info *vptr;
+	int pci = (bustype == BUS_PCI) ? 1 : 0;
+
+	if (pci)
+		netdev = pci_get_drvdata(pdev);
+	else
+		netdev = platform_get_drvdata(pdev);
+
+	vptr = netdev_priv(netdev);
+
+	unregister_netdev(netdev);
+	iounmap(vptr->mac_regs);
+
+	if (pci) {
+		pci_release_regions(pdev);
+		pci_disable_device(pdev);
+		pci_set_drvdata(pdev, NULL);
+	} else {
+		platform_set_drvdata(pdev, NULL);
+	}
+
+	free_netdev(netdev);
+
+	velocity_nics--;
+
+	return 0;
+}
+
+#ifdef CONFIG_PCI
+static int velocity_pci_probe(struct pci_dev *pdev,
+			   const struct pci_device_id *ent)
+{
+	return velocity_probe(pdev, ent, BUS_PCI);
+}
+
+static void velocity_pci_remove(struct pci_dev *pdev)
+{
+	velocity_remove(pdev, BUS_PCI);
+}
+#endif
+
+static int velocity_platform_probe(struct platform_device *pdev)
+{
+	return velocity_probe(pdev, NULL, BUS_PLATFORM);
+}
+
+static int velocity_platform_remove(struct platform_device *pdev)
+{
+	return velocity_remove(pdev, BUS_PLATFORM);
+}
+
 #ifdef CONFIG_PM
 /**
  *	wol_calc_crc		-	WOL CRC
@@ -3003,11 +3167,20 @@ static void velocity_save_context(struct velocity_info *vptr, struct velocity_co
 
 }
 
-static int velocity_suspend(struct pci_dev *pdev, pm_message_t state)
+static int velocity_suspend(void *pdev, pm_message_t state,
+					enum velocity_bus_type bustype)
 {
-	struct net_device *dev = pci_get_drvdata(pdev);
-	struct velocity_info *vptr = netdev_priv(dev);
+	struct net_device *netdev;
+	struct velocity_info *vptr;
 	unsigned long flags;
+	int pci = (bustype == BUS_PCI) ? 1 : 0;
+
+	if (pci)
+		netdev = pci_get_drvdata(pdev);
+	else
+		netdev = platform_get_drvdata(pdev);
+
+	vptr = netdev_priv(netdev);
 
 	if (!netif_running(vptr->netdev))
 		return 0;
@@ -3015,20 +3188,24 @@ static int velocity_suspend(struct pci_dev *pdev, pm_message_t state)
 	netif_device_detach(vptr->netdev);
 
 	spin_lock_irqsave(&vptr->lock, flags);
-	pci_save_state(pdev);
+	if (pci)
+		pci_save_state(pdev);
 
 	if (vptr->flags & VELOCITY_FLAGS_WOL_ENABLED) {
 		velocity_get_ip(vptr);
 		velocity_save_context(vptr, &vptr->context);
 		velocity_shutdown(vptr);
 		velocity_set_wol(vptr);
-		pci_enable_wake(pdev, PCI_D3hot, 1);
-		pci_set_power_state(pdev, PCI_D3hot);
+		if (pci)
+			pci_enable_wake(pdev, PCI_D3hot, 1);
+		velocity_set_power_state(vptr, PCI_D3hot);
 	} else {
 		velocity_save_context(vptr, &vptr->context);
 		velocity_shutdown(vptr);
-		pci_disable_device(pdev);
-		pci_set_power_state(pdev, pci_choose_state(pdev, state));
+		if (pci)
+			pci_disable_device(pdev);
+		velocity_set_power_state(vptr,
+					 velocity_choose_state(pdev, state));
 	}
 
 	spin_unlock_irqrestore(&vptr->lock, flags);
@@ -3070,19 +3247,30 @@ static void velocity_restore_context(struct velocity_info *vptr, struct velocity
 		writeb(*((u8 *) (context->mac_reg + i)), ptr + i);
 }
 
-static int velocity_resume(struct pci_dev *pdev)
+static int velocity_resume(void *pdev, enum velocity_bus_type bustype)
 {
-	struct net_device *dev = pci_get_drvdata(pdev);
-	struct velocity_info *vptr = netdev_priv(dev);
+	struct net_device *netdev;
+	struct velocity_info *vptr;
 	unsigned long flags;
+	int pci = (bustype == BUS_PCI) ? 1 : 0;
 	int i;
 
+	if (pci)
+		netdev = pci_get_drvdata(pdev);
+	else
+		netdev = platform_get_drvdata(pdev);
+
+	vptr = netdev_priv(netdev);
+
 	if (!netif_running(vptr->netdev))
 		return 0;
 
-	pci_set_power_state(pdev, PCI_D0);
-	pci_enable_wake(pdev, 0, 0);
-	pci_restore_state(pdev);
+	velocity_set_power_state(vptr, PCI_D0);
+
+	if (pci) {
+		pci_enable_wake(pdev, 0, 0);
+		pci_restore_state(pdev);
+	}
 
 	mac_wol_reset(vptr->mac_regs);
 
@@ -3104,23 +3292,62 @@ static int velocity_resume(struct pci_dev *pdev)
 
 	return 0;
 }
+
+#ifdef CONFIG_PCI
+static int velocity_pci_suspend(struct pci_dev *pdev, pm_message_t state)
+{
+	return velocity_suspend(pdev, state, BUS_PCI);
+}
+
+static int velocity_pci_resume(struct pci_dev *pdev)
+{
+	return velocity_resume(pdev, BUS_PCI);
+}
 #endif
 
+static int velocity_platform_suspend(struct platform_device *pdev,
+				      pm_message_t state)
+{
+	return velocity_suspend(pdev, state, BUS_PLATFORM);
+}
+
+static int velocity_platform_resume(struct platform_device *pdev)
+{
+	return velocity_resume(pdev, BUS_PLATFORM);
+}
+
+#endif	/* !CONFIG_PM */
+
 /*
  *	Definition for our device driver. The PCI layer interface
  *	uses this to handle all our card discover and plugging
  */
-static struct pci_driver velocity_driver = {
+#ifdef CONFIG_PCI
+static struct pci_driver velocity_pci_driver = {
 	.name		= VELOCITY_NAME,
-	.id_table	= velocity_id_table,
-	.probe		= velocity_found1,
-	.remove		= velocity_remove1,
+	.id_table	= velocity_pci_id_table,
+	.probe		= velocity_pci_probe,
+	.remove		= velocity_pci_remove,
 #ifdef CONFIG_PM
-	.suspend	= velocity_suspend,
-	.resume		= velocity_resume,
+	.suspend	= velocity_pci_suspend,
+	.resume		= velocity_pci_resume,
 #endif
 };
+#endif
 
+static struct platform_driver velocity_platform_driver = {
+	.probe		= velocity_platform_probe,
+	.remove		= velocity_platform_remove,
+#ifdef CONFIG_PM
+	.suspend	= velocity_platform_suspend,
+	.resume		= velocity_platform_resume,
+#endif
+	.driver = {
+		.name = "via-velocity",
+		.owner = THIS_MODULE,
+		.of_match_table = velocity_of_ids,
+	},
+};
 
 /**
  *	velocity_ethtool_up	-	pre hook for ethtool
@@ -3133,7 +3360,7 @@ static int velocity_ethtool_up(struct net_device *dev)
 {
 	struct velocity_info *vptr = netdev_priv(dev);
 	if (!netif_running(dev))
-		pci_set_power_state(vptr->pdev, PCI_D0);
+		velocity_set_power_state(vptr, PCI_D0);
 	return 0;
 }
 
@@ -3148,7 +3375,7 @@ static void velocity_ethtool_down(struct net_device *dev)
 {
 	struct velocity_info *vptr = netdev_priv(dev);
 	if (!netif_running(dev))
-		pci_set_power_state(vptr->pdev, PCI_D3hot);
+		velocity_set_power_state(vptr, PCI_D3hot);
 }
 
 static int velocity_get_settings(struct net_device *dev,
@@ -3270,7 +3497,11 @@ static void velocity_get_drvinfo(struct net_device *dev, struct ethtool_drvinfo
 	struct velocity_info *vptr = netdev_priv(dev);
 	strlcpy(info->driver, VELOCITY_NAME, sizeof(info->driver));
 	strlcpy(info->version, VELOCITY_VERSION, sizeof(info->version));
-	strlcpy(info->bus_info, pci_name(vptr->pdev), sizeof(info->bus_info));
+	if (vptr->bustype == BUS_PCI)
+		strlcpy(info->bus_info, pci_name(vptr->pdev),
+						sizeof(info->bus_info));
+	else
+		strlcpy(info->bus_info, "platform", sizeof(info->bus_info));
 }
 
 static void velocity_ethtool_get_wol(struct net_device *dev, struct ethtool_wolinfo *wol)
@@ -3563,9 +3794,15 @@ static int __init velocity_init_module(void)
 	int ret;
 
 	velocity_register_notifier();
-	ret = pci_register_driver(&velocity_driver);
+#ifdef CONFIG_PCI
+	ret = pci_register_driver(&velocity_pci_driver);
 	if (ret < 0)
 		velocity_unregister_notifier();
+#endif
+	ret = platform_driver_register(&velocity_platform_driver);
+	if (ret < 0)
+		velocity_unregister_notifier();
+
 	return ret;
 }
 
@@ -3580,7 +3817,10 @@ static int __init velocity_init_module(void)
 static void __exit velocity_cleanup_module(void)
 {
 	velocity_unregister_notifier();
-	pci_unregister_driver(&velocity_driver);
+#ifdef CONFIG_PCI
+	pci_unregister_driver(&velocity_pci_driver);
+#endif
+	platform_driver_unregister(&velocity_platform_driver);
 }
 
 module_init(velocity_init_module);
diff --git a/drivers/net/ethernet/via/via-velocity.h b/drivers/net/ethernet/via/via-velocity.h
index c38bbae..7468765 100644
--- a/drivers/net/ethernet/via/via-velocity.h
+++ b/drivers/net/ethernet/via/via-velocity.h
@@ -1265,7 +1265,7 @@ struct velocity_context {
 #define PHYID_VT3216_64BIT  0x000FC600UL
 #define PHYID_MARVELL_1000  0x01410C50UL
 #define PHYID_MARVELL_1000S 0x01410C40UL
-
+#define PHYID_ICPLUS_IP101A 0x02430C54UL
 #define PHYID_REV_ID_MASK   0x0000000FUL
 
 #define PHYID_GET_PHY_ID(i)         ((i) & ~PHYID_REV_ID_MASK)
@@ -1433,10 +1433,38 @@ struct velocity_opt {
 
 #define GET_RD_BY_IDX(vptr, idx)   (vptr->rd_ring[idx])
 
+static inline char velocity_choose_state(struct device *dev,
+					   pm_message_t state)
+
+{
+	switch (state.event) {
+	case PM_EVENT_ON:
+		return PCI_D0;
+	case PM_EVENT_FREEZE:
+	case PM_EVENT_PRETHAW:
+		/* REVISIT both freeze and pre-thaw "should" use D0 */
+	case PM_EVENT_SUSPEND:
+	case PM_EVENT_HIBERNATE:
+		return PCI_D3hot;
+	default:
+		dev_info(dev, "unrecognized suspend event %d\n", state.event);
+		BUG();
+	}
+
+	return PCI_D0;
+}
+
+enum velocity_bus_type {
+	BUS_PCI,
+	BUS_PLATFORM,
+};
+
 struct velocity_info {
 	struct device *dev;
 	struct pci_dev *pdev;
 	struct net_device *netdev;
+	enum velocity_bus_type bustype;
+	int no_eeprom;
 
 	unsigned long active_vlans[BITS_TO_LONGS(VLAN_N_VID)];
 	u8 ip_addr[4];
-- 
1.7.9.5



From swarren at wwwdotorg.org  Mon Apr 29 15:59:39 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Mon, 29 Apr 2013 13:59:39 -0600
Subject: Fwd: Tegra 30 System hangs because of commit "pinctrl: move
 subsystem mutex to pinctrl_dev struct"
In-Reply-To: <CAK5ve-KBDyvjNRVMcXgfnhYcajdcGsuAKaepzCBt+epiXoYvSw@mail.gmail.com>
References: <CAK5ve-KXdS8az=Gtja-mF=Z3_EeZVA7bLYSU0EE2mf5bHmSUKw@mail.gmail.com>
 <CAK5ve-KBDyvjNRVMcXgfnhYcajdcGsuAKaepzCBt+epiXoYvSw@mail.gmail.com>
Message-ID: <517ED12B.8080502@wwwdotorg.org>

On 04/29/13 12:41, Bryan Wu wrote:
> Forward to ARM and Tegra mail list.
>
> ---------- Forwarded message ----------
> From: Bryan Wu <cooloney at gmail.com>
> Date: Mon, Apr 29, 2013 at 11:15 AM
> Subject: Tegra 30 System hangs because of commit "pinctrl: move
> subsystem mutex to pinctrl_dev struct"
> To: patrice.chotard at st.com, Linus Walleij <linus.walleij at linaro.org>
> Cc: Stephen Warren <swarren at wwwdotorg.org>,
> "linux-next at vger.kernel.org" <linux-next at vger.kernel.org>
>
>
> Hi Patrice and Linus,
>
> I'm running linux-next on my Tegra 30 system everyday. But since
> next-20130426 release, the linux-next kernel will hang on my Tegra 30
> boards like Cardhu and Beaver.
>
> After some bisect and comparing to next-20130424, I found the commit
> "pinctrl: move subsystem mutex to pinctrl_dev struct" introduced this
> issue. If I simply revert this patch in next-20130429, system boots up
> as before.
>
> Could you please help to check this?

I would suggest simply dropping or reverting this patch; I had pointed 
out a long time ago that it was unlikely to be correct.

My guess/suspicion is a recursive lock attempt during processing hogs 
during pinctrl device registration, or perhaps during dt->map 
conversion. Bryan, are you able to confirm this?


From james.hogan at imgtec.com  Mon Apr 29 16:16:56 2013
From: james.hogan at imgtec.com (James Hogan)
Date: Mon, 29 Apr 2013 21:16:56 +0100
Subject: [v8,01/12] gpio: add gpio offset in gpio range cells property
In-Reply-To: <CAD6h2NTxmZqaYt6wQU3QrmUbPk9wjSSCy0JxhFp0_4MSdvEdDA@mail.gmail.com>
References: <1359825953-15663-2-git-send-email-haojian.zhuang@linaro.org>
 <517E990D.10101@imgtec.com>
 <CAD6h2NTxmZqaYt6wQU3QrmUbPk9wjSSCy0JxhFp0_4MSdvEdDA@mail.gmail.com>
Message-ID: <517ED538.1010002@imgtec.com>

On 29/04/13 17:49, Haojian Zhuang wrote:
> On 30 April 2013 00:00, James Hogan <james.hogan at imgtec.com> wrote:
>> On 02/02/13 17:25, Haojian Zhuang wrote:
>>> Add gpio offset into "gpio-range-cells" property. It's used to support
>>> sparse pinctrl range in gpio chip.
>>>
>>> Signed-off-by: Haojian Zhuang <haojian.zhuang at linaro.org>
>>> Acked-by: Viresh Kumar <viresh.kumar at linaro.org>
>>
>> This is an ABI breakage. I've been using the #gpio-range-cells = <2>
>> since around October. Please can we try and maintain backward
>> compatibility in future, even if it's only temporary.
>>
>> Thanks
>> James
>>
> 
> I've updated all code with #gpio-range-cells = <3> in kernel. If you change this
> back to <2>, you'll break current pinctrl-single driver. I appended this because
> there may be not 1-to-1 mapping between gpio pins & pinmux pins in some
> SoC. So the new parameter is used to specify the gpio pin offset.

Yes, I agree having 3 cells is useful, and I wasn't suggesting reverting
your patch, but it's an ABI now so the change should really be done in a
backwards compatible way so that device tree files that still have
#gpio-range-cells = <2> continue to work.

At the moment in -next, if you use an old device tree then the gpio
ranges are muddled up, with npins set apparently to a random (in my case
very large) number, I'm guessing this is just uninitialised data at the
end of the array. Even if you didn't have to maintain backwards
compatibility, it should at least check the number of cells matches what
it expects before reading all 3 entries.

> 
> So it's not temporary.

Sorry, what I meant was "even if maintaining the backwards compatibility
(supporting both <2> and <3>) is only temporary".

Cheers
James



From kosaki.motohiro at gmail.com  Mon Apr 29 16:46:17 2013
From: kosaki.motohiro at gmail.com (KOSAKI Motohiro)
Date: Mon, 29 Apr 2013 16:46:17 -0400
Subject: [PATCH] mm: add an option to disable bounce
In-Reply-To: <1366644180-6140-1-git-send-email-vinayakm.list@gmail.com>
References: <1366644180-6140-1-git-send-email-vinayakm.list@gmail.com>
Message-ID: <517EDC19.7020705@gmail.com>

(4/22/13 11:23 AM), vinayakm.list at gmail.com wrote:
> From: Vinayak Menon <vinayakm.list at gmail.com>
> 
> There are times when HIGHMEM is enabled, but
> we don't prefer CONFIG_BOUNCE to be enabled.
> CONFIG_BOUNCE can reduce the block device
> throughput, and this is not ideal for machines
> where we don't gain much by enabling it. So
> provide an option to deselect CONFIG_BOUNCE. The
> observation was made while measuring eMMC throughput
> using iozone on an ARM device with 1GB RAM.
> 
> Signed-off-by: Vinayak Menon <vinayakm.list at gmail.com>
> ---
>  mm/Kconfig |    6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/mm/Kconfig b/mm/Kconfig
> index 3bea74f..29f9736 100644
> --- a/mm/Kconfig
> +++ b/mm/Kconfig
> @@ -263,8 +263,14 @@ config ZONE_DMA_FLAG
>  	default "1"
>  
>  config BOUNCE
> +	bool "Enable bounce buffers"
>  	def_bool y
>  	depends on BLOCK && MMU && (ZONE_DMA || HIGHMEM)
> +	help
> +	  Enable bounce buffers for devices that cannot access
> +	  the full range of memory available to the CPU. Enabled
> +	  by default when ZONE_DMA or HIGMEM is selected, but you
> +	  may say n to override this.

This should depend on CONFIG_EXPERT. Because this makes typically worse result
on typical desktop machine.








From cooloney at gmail.com  Mon Apr 29 16:54:33 2013
From: cooloney at gmail.com (Bryan Wu)
Date: Mon, 29 Apr 2013 13:54:33 -0700
Subject: Fwd: Tegra 30 System hangs because of commit "pinctrl: move
 subsystem mutex to pinctrl_dev struct"
In-Reply-To: <517ED12B.8080502@wwwdotorg.org>
References: <CAK5ve-KXdS8az=Gtja-mF=Z3_EeZVA7bLYSU0EE2mf5bHmSUKw@mail.gmail.com>
 <CAK5ve-KBDyvjNRVMcXgfnhYcajdcGsuAKaepzCBt+epiXoYvSw@mail.gmail.com>
 <517ED12B.8080502@wwwdotorg.org>
Message-ID: <CAK5ve-LtQDvAC9nVvvfU3rvF8d=CYGp9T17FcdNEXBNV65ra2A@mail.gmail.com>

On Mon, Apr 29, 2013 at 12:59 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
> On 04/29/13 12:41, Bryan Wu wrote:
>>
>> Forward to ARM and Tegra mail list.
>>
>> ---------- Forwarded message ----------
>> From: Bryan Wu <cooloney at gmail.com>
>> Date: Mon, Apr 29, 2013 at 11:15 AM
>> Subject: Tegra 30 System hangs because of commit "pinctrl: move
>> subsystem mutex to pinctrl_dev struct"
>> To: patrice.chotard at st.com, Linus Walleij <linus.walleij at linaro.org>
>> Cc: Stephen Warren <swarren at wwwdotorg.org>,
>> "linux-next at vger.kernel.org" <linux-next at vger.kernel.org>
>>
>>
>> Hi Patrice and Linus,
>>
>> I'm running linux-next on my Tegra 30 system everyday. But since
>> next-20130426 release, the linux-next kernel will hang on my Tegra 30
>> boards like Cardhu and Beaver.
>>
>> After some bisect and comparing to next-20130424, I found the commit
>> "pinctrl: move subsystem mutex to pinctrl_dev struct" introduced this
>> issue. If I simply revert this patch in next-20130429, system boots up
>> as before.
>>
>> Could you please help to check this?
>
>
> I would suggest simply dropping or reverting this patch; I had pointed out a
> long time ago that it was unlikely to be correct.
>
> My guess/suspicion is a recursive lock attempt during processing hogs during
> pinctrl device registration, or perhaps during dt->map conversion. Bryan,
> are you able to confirm this?

Oh, no worries now. It was fixed in pinctrl for-next branch. I guess
linux-next will be update soon.

I will keep testing this when new linux-next is out.

-Bryan


From laurent.pinchart at ideasonboard.com  Mon Apr 29 16:56:56 2013
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Mon, 29 Apr 2013 22:56:56 +0200
Subject: [PATCH V2] video: implement a simple framebuffer driver
In-Reply-To: <51671F3D.5040501@wwwdotorg.org>
References: <1365043183-28905-1-git-send-email-swarren@wwwdotorg.org>
 <1828875.4dYa7WRt67@avalon> <51671F3D.5040501@wwwdotorg.org>
Message-ID: <1803841.rv79ElYKi3@avalon>

Hi Stephen,

Sorry for the late reply.

On Thursday 11 April 2013 14:38:21 Stephen Warren wrote:
> On 04/11/2013 02:06 PM, Laurent Pinchart wrote:
> > On Thursday 11 April 2013 10:06:49 Stephen Warren wrote:
> >> On 04/11/2013 03:56 AM, Laurent Pinchart wrote:
> >>> On Monday 08 April 2013 17:16:37 Andrew Morton wrote:
> >>>> On Wed,  3 Apr 2013 20:39:43 -0600 Stephen Warren wrote:
> >>>>> A simple frame-buffer describes a raw memory region that may be
> >>>>> rendered to, with the assumption that the display hardware has already
> >>>>> been set up to scan out from that buffer.
> >>>>> 
> >>>>> This is useful in cases where a bootloader exists and has set up the
> >>>>> display hardware, but a Linux driver doesn't yet exist for the display
> >>>>> hardware.
> >>>>> 
> >>>>> ...
> >>>>> 
> >>>>> +config FB_SIMPLE
> >>>>> +	bool "Simple framebuffer support"
> >>>>> +	depends on (FB = y) && OF
> >>>> 
> >>>> It's sad that this simple little thing requires Open Firmware.  Could
> >>>> it be generalised in some way so that the small amount of setup info
> >>>> could be provided by other means (eg, module_param) or does the
> >>>> dependency go deeper than that?
> >>> 
> >>> I second that request. I like the idea of a simple framebuffer driver if
> >>> it helps deprecating fbdev in the long term, but I don't want it to
> >>> offer an excuse not to implement a DRM/KMS driver. In particular adding
> >>> DT bindings would force us to keep supporting the ABI for a (too) long
> >>> time.
> >> 
> >> The platforms I intend to use this with only support device tree. Adding
> >> support for platform data right now would just be dead code. If somebody
> >> wants to use this driver with a board file based system rather than a DT
> >> based system, it would be trivial do modify the driver to add a platform
> >> data structure at that time.
> > 
> > What about using module parameters instead of DT bindings and platform
> > data ? As this is a hack designed to work around the lack of a proper
> > display driver the frame buffer address and size could just be passed by
> > the boot loader through the kernel command line, and the device would
> > then be instantiated by the driver.
> 
> I'm afraid I strongly dislike the idea of using module parameters. One
> of the things that I dislike the most about NVIDIA's downstream Android
> kernels is the huge number of random parameters that are required on the
> kernel command-line just to get it to boot.
> 
> I'd specifically prefer the configuration for this driver to be a device
> tree binding so that it /is/ an ABI. That way, arbitrary software that
> boots the Linux kernel will be able to target a common standard for how
> to pass this information to the kernel. If we move to module parameters
> instead, especially with the specific intent that the format of those
> parameters is no longer an ABI, we run in to issues where a new kernel
> requires a bootloader update in order to generate the new set of module
> parameters that are required by the driver. If we say the module
> parameters will never change except in a backwards-compatible fashion,
> and hence that issue won't arise, then why not just make it a DT binding?
> 
> Do module parameters handle the case of multiple device instances?

Not well. It can be handled manually by using parameter arrays, but that's a 
bit hackish.

> Also, I really don't see this driver as a hack. It's a perfectly reasonable
> situation to have some other SW set up the frame-buffer, and Linux simply
> continue to use it. Perhaps that other SW even ran on a difference CPU, or
> the parameters are hard-coded in HW design, and so there's no HW that Linux
> ever could drive, so it just isn't possible to create any more advanced
> driver.

I totally agree that this driver would be very useful during board bring-up. 
My concern is that it would also give an incentive to vendors not to develop a 
proper KMS driver (or rather remove an incentive to develop one).

-- 
Regards,

Laurent Pinchart



From laurent.pinchart at ideasonboard.com  Mon Apr 29 17:20:43 2013
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Mon, 29 Apr 2013 23:20:43 +0200
Subject: [PATCH V2] video: implement a simple framebuffer driver
In-Reply-To: <2863648.BDvrAG5uPk@flatron>
References: <1365043183-28905-1-git-send-email-swarren@wwwdotorg.org>
 <2569832.XQDrhUGNaI@avalon> <2863648.BDvrAG5uPk@flatron>
Message-ID: <1461633.kfcPFxva7x@avalon>

Hi Tomasz,

On Monday 29 April 2013 23:15:13 Tomasz Figa wrote:
> On Thursday 11 of April 2013 11:56:31 Laurent Pinchart wrote:
> > On Monday 08 April 2013 17:16:37 Andrew Morton wrote:
> > > On Wed,  3 Apr 2013 20:39:43 -0600 Stephen Warren wrote:
> > > > A simple frame-buffer describes a raw memory region that may be
> > > > rendered to, with the assumption that the display hardware has
> > > > already been set up to scan out from that buffer.
> > > > 
> > > > This is useful in cases where a bootloader exists and has set up the
> > > > display hardware, but a Linux driver doesn't yet exist for the
> > > > display hardware.
> > > > 
> > > > ...
> > > > 
> > > > +config FB_SIMPLE
> > > > +	bool "Simple framebuffer support"
> > > > +	depends on (FB = y) && OF
> > > 
> > > It's sad that this simple little thing requires Open Firmware.  Could
> > > it be generalised in some way so that the small amount of setup info
> > > could be provided by other means (eg, module_param) or does the
> > > dependency go deeper than that?
> > 
> > I second that request. I like the idea of a simple framebuffer driver if
> > it helps deprecating fbdev in the long term, but I don't want it to
> > offer an excuse not to implement a DRM/KMS driver. In particular adding
> > DT bindings would force us to keep supporting the ABI for a (too) long
> > time.
> 
> Well, there is also at least one legitimate use case for this driver.
> 
> I believe there exist embedded devices on which there is no need to
> dynamically control the framebuffer. It needs one time initialization,
> usually in bootloader, and then it is used as is, using constant
> parameters as long as the system is running.
> 
> I doubt there is a need for any KMS (or any other control) driver for such
> devices - dumb framebuffer driver would be everything needed in such case.

As we want to deprecate the fbdev API we would need to move to KMS at some 
point anyway, even if the device can't be controlled. I don't think writting 
such a KMS driver would be that difficult.

-- 
Regards,

Laurent Pinchart



From marc.ceeeee at gmail.com  Mon Apr 29 17:21:49 2013
From: marc.ceeeee at gmail.com (Marc C)
Date: Mon, 29 Apr 2013 14:21:49 -0700
Subject: [RFC/PATCH v2 2/2] drivers: dma-contiguous: add initialization
 from device tree
In-Reply-To: <1365679330-2514-3-git-send-email-m.szyprowski@samsung.com>
References: <1365679330-2514-1-git-send-email-m.szyprowski@samsung.com>
 <1365679330-2514-3-git-send-email-m.szyprowski@samsung.com>
Message-ID: <CAO1A-8DiZoMVGcjOqK6VYP5Qito55i=gsKApQM=LGbQVx3iCwg@mail.gmail.com>

>  /**
>   * dma_contiguous_reserve() - reserve area(s) for contiguous memory handling
>   * @limit: End address of the reserved memory (optional, 0 for any).
> @@ -149,6 +200,10 @@ void __init dma_contiguous_reserve(phys_addr_t limit)
>
>         pr_debug("%s(limit %08lx)\n", __func__, (unsigned long)limit);
>
> +#ifdef CONFIG_OF
> +       of_scan_flat_dt(cma_fdt_scan, NULL);
> +#endif
> +

What is your expectation with the contention between default region
setup via the kernel config (CONFIG_CMA_SIZE_SEL_*) and via the DT?
Could the call to 'of_scan_flat_dt()' be done before the setup of the
kernel config early regions, followed by a return code check
'fail-over' scheme, or were you intending for the default region
setups to be mutually-exclusive?

Thanks,
Marc


From tomasz.figa at gmail.com  Mon Apr 29 17:15:13 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Mon, 29 Apr 2013 23:15:13 +0200
Subject: [PATCH V2] video: implement a simple framebuffer driver
In-Reply-To: <2569832.XQDrhUGNaI@avalon>
References: <1365043183-28905-1-git-send-email-swarren@wwwdotorg.org>
 <20130408171637.98b5ad1f867bcbda883af68b@linux-foundation.org>
 <2569832.XQDrhUGNaI@avalon>
Message-ID: <2863648.BDvrAG5uPk@flatron>

Hi Laurent,

On Thursday 11 of April 2013 11:56:31 Laurent Pinchart wrote:
> On Monday 08 April 2013 17:16:37 Andrew Morton wrote:
> > On Wed,  3 Apr 2013 20:39:43 -0600 Stephen Warren wrote:
> > > A simple frame-buffer describes a raw memory region that may be
> > > rendered to, with the assumption that the display hardware has
> > > already been set up to scan out from that buffer.
> > > 
> > > This is useful in cases where a bootloader exists and has set up the
> > > display hardware, but a Linux driver doesn't yet exist for the
> > > display
> > > hardware.
> > > 
> > > ...
> > > 
> > > +config FB_SIMPLE
> > > +	bool "Simple framebuffer support"
> > > +	depends on (FB = y) && OF
> > 
> > It's sad that this simple little thing requires Open Firmware.  Could
> > it be generalised in some way so that the small amount of setup info
> > could be provided by other means (eg, module_param) or does the
> > dependency go deeper than that?
> 
> I second that request. I like the idea of a simple framebuffer driver if
> it helps deprecating fbdev in the long term, but I don't want it to
> offer an excuse not to implement a DRM/KMS driver. In particular adding
> DT bindings would force us to keep supporting the ABI for a (too) long
> time.

Well, there is also at least one legitimate use case for this driver.

I believe there exist embedded devices on which there is no need to 
dynamically control the framebuffer. It needs one time initialization, 
usually in bootloader, and then it is used as is, using constant 
parameters as long as the system is running.

I doubt there is a need for any KMS (or any other control) driver for such 
devices - dumb framebuffer driver would be everything needed in such case.

Best regards,
Tomasz



From tomasz.figa at gmail.com  Mon Apr 29 17:31:30 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Mon, 29 Apr 2013 23:31:30 +0200
Subject: [PATCH V2] video: implement a simple framebuffer driver
In-Reply-To: <1461633.kfcPFxva7x@avalon>
References: <1365043183-28905-1-git-send-email-swarren@wwwdotorg.org>
 <2863648.BDvrAG5uPk@flatron> <1461633.kfcPFxva7x@avalon>
Message-ID: <1556968.7tR6KuEIWb@flatron>

On Monday 29 of April 2013 23:20:43 Laurent Pinchart wrote:
> Hi Tomasz,
> 
> On Monday 29 April 2013 23:15:13 Tomasz Figa wrote:
> > On Thursday 11 of April 2013 11:56:31 Laurent Pinchart wrote:
> > > On Monday 08 April 2013 17:16:37 Andrew Morton wrote:
> > > > On Wed,  3 Apr 2013 20:39:43 -0600 Stephen Warren wrote:
> > > > > A simple frame-buffer describes a raw memory region that may be
> > > > > rendered to, with the assumption that the display hardware has
> > > > > already been set up to scan out from that buffer.
> > > > > 
> > > > > This is useful in cases where a bootloader exists and has set up
> > > > > the
> > > > > display hardware, but a Linux driver doesn't yet exist for the
> > > > > display hardware.
> > > > > 
> > > > > ...
> > > > > 
> > > > > +config FB_SIMPLE
> > > > > +	bool "Simple framebuffer support"
> > > > > +	depends on (FB = y) && OF
> > > > 
> > > > It's sad that this simple little thing requires Open Firmware. 
> > > > Could
> > > > it be generalised in some way so that the small amount of setup
> > > > info
> > > > could be provided by other means (eg, module_param) or does the
> > > > dependency go deeper than that?
> > > 
> > > I second that request. I like the idea of a simple framebuffer
> > > driver if it helps deprecating fbdev in the long term, but I don't
> > > want it to offer an excuse not to implement a DRM/KMS driver. In
> > > particular adding DT bindings would force us to keep supporting the
> > > ABI for a (too) long time.
> > 
> > Well, there is also at least one legitimate use case for this driver.
> > 
> > I believe there exist embedded devices on which there is no need to
> > dynamically control the framebuffer. It needs one time initialization,
> > usually in bootloader, and then it is used as is, using constant
> > parameters as long as the system is running.
> > 
> > I doubt there is a need for any KMS (or any other control) driver for
> > such devices - dumb framebuffer driver would be everything needed in
> > such case.
> As we want to deprecate the fbdev API we would need to move to KMS at
> some point anyway, even if the device can't be controlled. I don't
> think writting such a KMS driver would be that difficult.

Good point. Stephen, would it be a problem to make this a KMS driver 
instead? Old fbdev API could be emulated on top of it, until it goes out 
of use, couldn't it?

Best regards,
Tomasz



From laurent.pinchart at ideasonboard.com  Mon Apr 29 17:40:57 2013
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Mon, 29 Apr 2013 23:40:57 +0200
Subject: [PATCH V2] video: implement a simple framebuffer driver
In-Reply-To: <1556968.7tR6KuEIWb@flatron>
References: <1365043183-28905-1-git-send-email-swarren@wwwdotorg.org>
 <1461633.kfcPFxva7x@avalon> <1556968.7tR6KuEIWb@flatron>
Message-ID: <6607610.omg016OAvj@avalon>

On Monday 29 April 2013 23:31:30 Tomasz Figa wrote:
> On Monday 29 of April 2013 23:20:43 Laurent Pinchart wrote:
> > On Monday 29 April 2013 23:15:13 Tomasz Figa wrote:
> > > On Thursday 11 of April 2013 11:56:31 Laurent Pinchart wrote:
> > > > On Monday 08 April 2013 17:16:37 Andrew Morton wrote:
> > > > > On Wed,  3 Apr 2013 20:39:43 -0600 Stephen Warren wrote:
> > > > > > A simple frame-buffer describes a raw memory region that may be
> > > > > > rendered to, with the assumption that the display hardware has
> > > > > > already been set up to scan out from that buffer.
> > > > > > 
> > > > > > This is useful in cases where a bootloader exists and has set up
> > > > > > the display hardware, but a Linux driver doesn't yet exist for the
> > > > > > display hardware.
> > > > > > 
> > > > > > ...
> > > > > > 
> > > > > > +config FB_SIMPLE
> > > > > > +	bool "Simple framebuffer support"
> > > > > > +	depends on (FB = y) && OF
> > > > > 
> > > > > It's sad that this simple little thing requires Open Firmware.
> > > > > Could it be generalised in some way so that the small amount of
> > > > > setup info could be provided by other means (eg, module_param) or
> > > > > does the dependency go deeper than that?
> > > > 
> > > > I second that request. I like the idea of a simple framebuffer
> > > > driver if it helps deprecating fbdev in the long term, but I don't
> > > > want it to offer an excuse not to implement a DRM/KMS driver. In
> > > > particular adding DT bindings would force us to keep supporting the
> > > > ABI for a (too) long time.
> > > 
> > > Well, there is also at least one legitimate use case for this driver.
> > > 
> > > I believe there exist embedded devices on which there is no need to
> > > dynamically control the framebuffer. It needs one time initialization,
> > > usually in bootloader, and then it is used as is, using constant
> > > parameters as long as the system is running.
> > > 
> > > I doubt there is a need for any KMS (or any other control) driver for
> > > such devices - dumb framebuffer driver would be everything needed in
> > > such case.
> > 
> > As we want to deprecate the fbdev API we would need to move to KMS at
> > some point anyway, even if the device can't be controlled. I don't
> > think writting such a KMS driver would be that difficult.
> 
> Good point. Stephen, would it be a problem to make this a KMS driver
> instead? Old fbdev API could be emulated on top of it, until it goes out
> of use, couldn't it?

There's already an fbdev emulation layer in KMS, for such a simple use case it 
will work fine.

-- 
Regards,

Laurent Pinchart



From gotom at sanori.org  Mon Apr 29 17:41:38 2013
From: gotom at sanori.org (Masanori Goto)
Date: Tue, 30 Apr 2013 06:41:38 +0900
Subject: [PATCH 10/21] [SCSI] nsp32: use mdelay instead of large udelay
 constants
In-Reply-To: <201304291521.14195.arnd@arndb.de>
References: <1366910944-3033663-1-git-send-email-arnd@arndb.de>
 <1366910944-3033663-11-git-send-email-arnd@arndb.de>
 <CALZLnaFeLcaGM7_McTZ=pKBRnpXk0AvqOTF=1YCqJv-53yk4XQ@mail.gmail.com>
 <201304291521.14195.arnd@arndb.de>
Message-ID: <CALZLnaEbXRJY2qntWucm00mNq78CRD8Vhp7KoTw6Me0frxtaDw@mail.gmail.com>

Oops, you're absolutely correct.  Thanks for the follow up!  Please
change it as follow as you mentioned:

Acked-by: GOTO Masanori <gotom at debian.or.jp>

Best regrads,
-- gotom

2013/4/29 Arnd Bergmann <arnd at arndb.de>:
> On Friday 26 April 2013, Masanori Goto wrote:
>> 2013/4/25 Arnd Bergmann <arnd at arndb.de>
>> >
>> > ARM cannot handle udelay for more than 2 miliseconds, so we
>> > should use mdelay instead for those.
>> >
>>
>> Singed-off-by: GOTO Masanori <gotom at debian.or.jp>
>
> Thanks. I assume you mean "Acked-by", not "Singed-off" as in "burnt"
> or "Signed-off" as a notification that you have applied it to your
> own git tree.
>
> I'll keep the patch with an your "Acked-by" line in my tree unless
> James wants to apply to the scsi tree.
>
>         Arnd
>


From arnd at arndb.de  Mon Apr 29 18:04:20 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 30 Apr 2013 00:04:20 +0200
Subject: [PATCH V2] video: implement a simple framebuffer driver
In-Reply-To: <6607610.omg016OAvj@avalon>
References: <1365043183-28905-1-git-send-email-swarren@wwwdotorg.org>
 <1556968.7tR6KuEIWb@flatron> <6607610.omg016OAvj@avalon>
Message-ID: <201304300004.20320.arnd@arndb.de>

On Monday 29 April 2013, Laurent Pinchart wrote:
> On Monday 29 April 2013 23:31:30 Tomasz Figa wrote:
>
> > Good point. Stephen, would it be a problem to make this a KMS driver
> > instead? Old fbdev API could be emulated on top of it, until it goes out
> > of use, couldn't it?
> 
> There's already an fbdev emulation layer in KMS, for such a simple use case it 
> will work fine.

I suggested the same to Stephen when he first brought up this driver.
Unfortunately his attempt to create a simple KMS driver resulted in a
significantly larger driver than the one he did for the framebuffer
interface. This means that either Stephen did something really wrong
in his attempt, or the KMS interface isn't as good as it should be
if we want to move people away from frame buffer drivers.

	Arnd


From laurent.pinchart at ideasonboard.com  Mon Apr 29 18:23:31 2013
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Tue, 30 Apr 2013 00:23:31 +0200
Subject: [PATCH V2] video: implement a simple framebuffer driver
In-Reply-To: <201304300004.20320.arnd@arndb.de>
References: <1365043183-28905-1-git-send-email-swarren@wwwdotorg.org>
 <6607610.omg016OAvj@avalon> <201304300004.20320.arnd@arndb.de>
Message-ID: <2040099.REU8D4ds1g@avalon>

Hi Arnd,

On Tuesday 30 April 2013 00:04:20 Arnd Bergmann wrote:
> On Monday 29 April 2013, Laurent Pinchart wrote:
> > On Monday 29 April 2013 23:31:30 Tomasz Figa wrote:
> > > Good point. Stephen, would it be a problem to make this a KMS driver
> > > instead? Old fbdev API could be emulated on top of it, until it goes out
> > > of use, couldn't it?
> > 
> > There's already an fbdev emulation layer in KMS, for such a simple use
> > case it will work fine.
> 
> I suggested the same to Stephen when he first brought up this driver.
> Unfortunately his attempt to create a simple KMS driver resulted in a
> significantly larger driver than the one he did for the framebuffer
> interface. This means that either Stephen did something really wrong in his
> attempt, or the KMS interface isn't as good as it should be if we want to
> move people away from frame buffer drivers.

Implementing a KMS driver requires a fair amount of code. The DRM/KMS 
subsystem provides helpers that significantly reduce the driver size. Those 
helpers have been designed around common use cases found in existing KMS 
drivers.

I'm pretty sure we will be able to add useful helpers for existing fbdev 
drivers that will make porting them to KMS pretty easy, but that first 
requires starting to port drivers to find out what common code could be 
factored out.

-- 
Regards,

Laurent Pinchart



From sergei.shtylyov at cogentembedded.com  Mon Apr 29 18:37:50 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Tue, 30 Apr 2013 02:37:50 +0400
Subject: [PATCH] ARM: shmobile: BOCK-W: add Ether support
Message-ID: <201304300237.50896.sergei.shtylyov@cogentembedded.com>

Register Ether device from bockw_init(), passing the platform data to it, adding
only the RMII pin group to bockw_pinctrl_map[].  Although the LINK signal exists
on the board, it's connected to the link/activity LED  output of the PHY, thus
the link disappears and reappears after each packet. We'd be better off ignoring
such signal and getting the link state from the PHY indirectly.

Also, Ether has pin conflict with VIN1, so the latter is not registered when the
'sh_eth' driver is enabled now.

Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

---
The patch is atop of Simon Horman's 'renesas.git' repo, 'renesas-next-20130426'
tag and my recent yet unapplied patches.

Note that it's compile time dependent on the David Miller's 'net-next.git' repo,
so probably is not fit for immediate applying. One also needs my  yet unmerged
patch "sh_eth: use random MAC address if no valid one supplied" in order for the
driver to work:

http://marc.info/?l=linux-sh&m=136726502117160

 arch/arm/mach-shmobile/board-bockw.c |   22 +++++++++++++++++++++-
 1 file changed, 21 insertions(+), 1 deletion(-)

Index: renesas/arch/arm/mach-shmobile/board-bockw.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/board-bockw.c
+++ renesas/arch/arm/mach-shmobile/board-bockw.c
@@ -67,6 +67,20 @@ static struct sh_mobile_sdhi_info sdhi0_
 
 static struct rcar_phy_platform_data usb_phy_platform_data __initdata;
 
+static struct sh_eth_plat_data ether_platform_data __initdata = {
+	.phy		= 0x01,
+	.edmac_endian	= EDMAC_LITTLE_ENDIAN,
+	.register_type	= SH_ETH_REG_FAST_RCAR,
+	.phy_interface	= PHY_INTERFACE_MODE_RMII,
+	/*
+	 * Although the LINK signal is available on the board, it's connected to
+	 * the link/activity LED output of the PHY, thus the link disappears and
+	 * reappears after each packet.  We'd be better off ignoring such signal
+	 * and getting the link state from the PHY indirectly.
+	 */
+	.no_ether_link	= 1,
+};
+
 static struct rcar_vin_platform_data vin_platform_data __initdata = {
 	.flags	= RCAR_VIN_BT656,
 };
@@ -87,6 +101,9 @@ BOCKW_CAMERA(0);
 BOCKW_CAMERA(1);
 
 static const struct pinctrl_map bockw_pinctrl_map[] = {
+	/* Ether */
+	PIN_MAP_MUX_GROUP_DEFAULT("sh-eth", "pfc-r8a7778",
+				  "ether_rmii", "ether"),
 	/* SCIF0 */
 	PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.0", "pfc-r8a7778",
 				  "scif0_data_a", "scif0"),
@@ -125,8 +142,11 @@ static void __init bockw_init(void)
 	r8a7778_init_irq_extpin(1);
 	r8a7778_add_standard_devices();
 	r8a7778_add_usb_phy_device(&usb_phy_platform_data);
+	r8a7778_add_ether_device(&ether_platform_data);
 	r8a7778_add_vin_device(0, &vin_platform_data);
-	r8a7778_add_vin_device(1, &vin_platform_data);
+	/* VIN1 has a pin conflict with Ether */
+	if (!IS_ENABLED(CONFIG_SH_ETH))
+		r8a7778_add_vin_device(1, &vin_platform_data);
 	platform_device_register_data(&platform_bus, "soc-camera-pdrv", 0,
 				      &iclink0_ml86v7667,
 				      sizeof(iclink0_ml86v7667));


From olof at lixom.net  Mon Apr 29 18:40:44 2013
From: olof at lixom.net (Olof Johansson)
Date: Mon, 29 Apr 2013 15:40:44 -0700
Subject: [PATCH V2] video: implement a simple framebuffer driver
In-Reply-To: <2040099.REU8D4ds1g@avalon>
References: <1365043183-28905-1-git-send-email-swarren@wwwdotorg.org>
 <6607610.omg016OAvj@avalon> <201304300004.20320.arnd@arndb.de>
 <2040099.REU8D4ds1g@avalon>
Message-ID: <CAOesGMiCvBwck0Z6Nyo9zW=1=J=wjhJW68qNGMrN_8iim=8Srg@mail.gmail.com>

On Mon, Apr 29, 2013 at 3:23 PM, Laurent Pinchart
<laurent.pinchart at ideasonboard.com> wrote:
> Hi Arnd,
>
> On Tuesday 30 April 2013 00:04:20 Arnd Bergmann wrote:
>> On Monday 29 April 2013, Laurent Pinchart wrote:
>> > On Monday 29 April 2013 23:31:30 Tomasz Figa wrote:
>> > > Good point. Stephen, would it be a problem to make this a KMS driver
>> > > instead? Old fbdev API could be emulated on top of it, until it goes out
>> > > of use, couldn't it?
>> >
>> > There's already an fbdev emulation layer in KMS, for such a simple use
>> > case it will work fine.
>>
>> I suggested the same to Stephen when he first brought up this driver.
>> Unfortunately his attempt to create a simple KMS driver resulted in a
>> significantly larger driver than the one he did for the framebuffer
>> interface. This means that either Stephen did something really wrong in his
>> attempt, or the KMS interface isn't as good as it should be if we want to
>> move people away from frame buffer drivers.
>
> Implementing a KMS driver requires a fair amount of code. The DRM/KMS
> subsystem provides helpers that significantly reduce the driver size. Those
> helpers have been designed around common use cases found in existing KMS
> drivers.
>
> I'm pretty sure we will be able to add useful helpers for existing fbdev
> drivers that will make porting them to KMS pretty easy, but that first
> requires starting to port drivers to find out what common code could be
> factored out.

Meanwhile this tiny driver will allow us to use hardware that can't
otherwise be used (because the proper graphics drivers for said
hardware is _also_ stuck behind large reworks, i.e. common display
framework, which has uncertain progress at this time).

As Stephen mentioned in the original patch, this particular driver is
very useful for Raspberry Pi. But it is also the best way forward
(right now) for getting basic upstream usability out of the Samsung
ARM-based Chromebook. As a matter of fact, as of this weekend
linux-next boots on that platform with keyboard, trackpad, framebuffer
and USB2.0 without a single out-of-tree patch. Getting the same
functionality out of 3.10 would be very desirable.

So, I clearly understand the desire to move over to a more modern
framework. At the same time, there's definite value in merging this
small driver while that's happening. Holding useful code hostage isn't
always very productive.


-Olof


From romieu at fr.zoreil.com  Mon Apr 29 19:04:50 2013
From: romieu at fr.zoreil.com (Francois Romieu)
Date: Tue, 30 Apr 2013 01:04:50 +0200
Subject: [PATCHv3 3/3] net: velocity: Add platform device support to VIA
 velocity driver
In-Reply-To: <1367264772-4557-4-git-send-email-linux@prisktech.co.nz>
References: <1367264772-4557-1-git-send-email-linux@prisktech.co.nz>
 <1367264772-4557-4-git-send-email-linux@prisktech.co.nz>
Message-ID: <20130429230450.GA2620@electric-eye.fr.zoreil.com>

Tony Prisk <linux at prisktech.co.nz> :
[...]
> +static int velocity_remove(void *pdev, enum velocity_bus_type bustype)
> +{
> +	struct net_device *netdev;
> +	struct velocity_info *vptr;
> +	int pci = (bustype == BUS_PCI) ? 1 : 0;
> +
> +	if (pci)
> +		netdev = pci_get_drvdata(pdev);
> +	else
> +		netdev = platform_get_drvdata(pdev);

The caller knows how to retrieve the net_device pointer, whence
the struct velocity_info pointer, whence any bustype dependent
function pointer to alleviate the "if (pci)" and CONFIG stuff.

If you are not convinced, please consider turning the void *
into an union *.

-- 
Ueimor


From sfr at canb.auug.org.au  Mon Apr 29 19:18:45 2013
From: sfr at canb.auug.org.au (Stephen Rothwell)
Date: Tue, 30 Apr 2013 09:18:45 +1000
Subject: linux-next: manual merge of the arm-soc tree with the xen-arm tree
In-Reply-To: <alpine.DEB.2.02.1304291049060.5398@kaball.uk.xensource.com>
References: <20130429175426.9423279609437a2d746cbb7b@canb.auug.org.au>
 <20130429082511.GA539@arm.com>
 <alpine.DEB.2.02.1304291049060.5398@kaball.uk.xensource.com>
Message-ID: <20130430091845.27d8de4935bd33ddb4a3e8c0@canb.auug.org.au>

Hi Stefano,

On Mon, 29 Apr 2013 10:50:22 +0100 Stefano Stabellini <stefano.stabellini at eu.citrix.com> wrote:
>
> On Mon, 29 Apr 2013, Catalin Marinas wrote:
> > 
> > On Mon, Apr 29, 2013 at 08:54:26AM +0100, Stephen Rothwell wrote:
> > > Today's linux-next merge of the arm-soc tree got a conflict in
> > > arch/arm/mach-virt/platsmp.c between commit fe4bff02886b ("arm: introduce
> > > psci_smp_ops") from the xen-arm tree and commit c0114709ed85 ("irqchip:
> > > gic: Perform the gic_secondary_init() call via CPU notifier") from the
> > > arm-soc tree.
> > > 
> > > The former renamed the file (and contents) so I applied the following
> > > patch and can carry the fix as necessary (no action is required).
> > > 
> > > From: Stephen Rothwell <sfr at canb.auug.org.au>
> > > Date: Mon, 29 Apr 2013 17:52:27 +1000
> > > Subject: [PATCH] arm: fix for Perform the gic_secondary_init() call via CPU
> > >  notifier
> > > 
> > > due to code movement.
> > > 
> > > Signed-off-by: Stephen Rothwell <sfr at canb.auug.org.au>
> > > ---
> > >  arch/arm/kernel/psci_smp.c | 7 -------
> > >  1 file changed, 7 deletions(-)
> > > 
> > > diff --git a/arch/arm/kernel/psci_smp.c b/arch/arm/kernel/psci_smp.c
> > > index 6ef139d..cd9acc7 100644
> > > --- a/arch/arm/kernel/psci_smp.c
> > > +++ b/arch/arm/kernel/psci_smp.c
> > > @@ -14,7 +14,6 @@
> > >   */
> > >  
> > >  #include <linux/init.h>
> > > -#include <linux/irqchip/arm-gic.h>
> > >  #include <linux/smp.h>
> > >  #include <linux/of.h>
> > >  
> > > @@ -55,11 +54,6 @@ static int __cpuinit psci_boot_secondary(unsigned int cpu,
> > >  	return -ENODEV;
> > >  }
> > >  
> > > -static void __cpuinit psci_secondary_init(unsigned int cpu)
> > > -{
> > > -	gic_secondary_init(0);
> > > -}
> > > -
> > >  #ifdef CONFIG_HOTPLUG_CPU
> > >  void __ref psci_cpu_die(unsigned int cpu)
> > >  {
> > > @@ -84,7 +78,6 @@ bool __init psci_smp_available(void)
> > >  }
> > >  
> > >  struct smp_operations __initdata psci_smp_ops = {
> > > -	.smp_secondary_init	= psci_secondary_init,
> > >  	.smp_boot_secondary	= psci_boot_secondary,
> > >  	.cpu_die		= psci_cpu_die,
> > >  };
> > 
> > The fix looks fine. Thanks.
> 
> Indeed, thanks! I'll add to it to the tree.

You should not apply that to your tree as you don't have the rest of the
change from the arm-soc tree.  It needs to be applied to the merge of the
two trees i.e. when Linus merges the last of the two trees.

This is why I wrote "no action is required".

And you committed it to your tree without your Signed-off-by ...

-- 
Cheers,
Stephen Rothwell                    sfr at canb.auug.org.au
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130430/d69815ba/attachment.sig>

From khilman at linaro.org  Mon Apr 29 19:43:00 2013
From: khilman at linaro.org (Kevin Hilman)
Date: Mon, 29 Apr 2013 16:43:00 -0700
Subject: [PATCH] idle: fix hlt/nohlt command-line handling in new generic
 idle
In-Reply-To: <5178D049.9090303@linux.vnet.ibm.com> (Srivatsa S. Bhat's message
 of "Thu, 25 Apr 2013 12:12:17 +0530")
References: <1366849153-25564-1-git-send-email-khilman@linaro.org>
 <5178D049.9090303@linux.vnet.ibm.com>
Message-ID: <87haiovr7f.fsf@linaro.org>

"Srivatsa S. Bhat" <srivatsa.bhat at linux.vnet.ibm.com> writes:

> On 04/25/2013 05:49 AM, Kevin Hilman wrote:
>> commit d1669912 (idle: Implement generic idle function) added a new
>> generic idle along with support for hlt/nohlt command line options to
>> override default idle loop behavior.  However, the command-line
>> processing is never compiled.
>> 
>> The command-line handling is wrapped by CONFIG_GENERIC_IDLE_POLL_SETUP
>> and arches that use this feature select it in their Kconfigs.
>> However, no Kconfig definition was created for this option, so it is
>> never enabled, and therefore command-line override of the idle-loop
>> behavior is broken after migrating to the generic idle loop.
>> 
>> To fix, add a Kconfig definition for GENERIC_IDLE_POLL_SETUP.
>> 
>> Tested on ARM (OMAP4/Panda) which enables the command-line overrides
>> by default.
>> 
>> Cc: Thomas Gleixner <tglx at linutronix.de>
>> Cc: Linus Torvalds <torvalds at linux-foundation.org>
>> Cc: Rusty Russell <rusty at rustcorp.com.au>
>> Cc: Paul McKenney <paulmck at linux.vnet.ibm.com>
>> Cc: Peter Zijlstra <peterz at infradead.org>
>> Cc: Srivatsa S. Bhat <srivatsa.bhat at linux.vnet.ibm.com>
>> Cc: Magnus Damm <magnus.damm at gmail.com>
>> Signed-off-by: Kevin Hilman <khilman at linaro.org>
>> ---
>
> Reviewed-by: Srivatsa S. Bhat <srivatsa.bhat at linux.vnet.ibm.com>

Thanks for the review.

>> Applies on tip/smp/hotplug where generic idle feature is added

Thomas, can this get into tip/smp/hotplug so the command-line override
is not broken in v3.10?

Thanks,

Kevin

>>
>>  arch/Kconfig | 3 +++
>>  1 file changed, 3 insertions(+)
>> 
>> diff --git a/arch/Kconfig b/arch/Kconfig
>> index 1455579..e0ef57b 100644
>> --- a/arch/Kconfig
>> +++ b/arch/Kconfig
>> @@ -216,6 +216,9 @@ config USE_GENERIC_SMP_HELPERS
>>  config GENERIC_SMP_IDLE_THREAD
>>         bool
>> 
>> +config GENERIC_IDLE_POLL_SETUP
>> +       bool
>> +
>>  # Select if arch init_task initializer is different to init/init_task.c
>>  config ARCH_INIT_TASK
>>         bool
>> 


From syin at broadcom.com  Mon Apr 29 19:46:51 2013
From: syin at broadcom.com (Sherman Yin)
Date: Mon, 29 Apr 2013 23:46:51 +0000
Subject: Adding a void * to pinctrl_pin_desc
In-Reply-To: <CACRpkdY2vWvvE_NToQ5rkxGC32hCJgMjNpkF+KEGJ+-o4My4-Q@mail.gmail.com>
References: <051069C10411E24D9749790C498526FA1BCF4FC6@SJEXCHMB12.corp.ad.broadcom.com>
 <CACRpkdYxJOWYMfwmrEGhqgjushVjWyc=FyKMaZNLnn=0jrTs9A@mail.gmail.com>
 <051069C10411E24D9749790C498526FA1BCF54B1@SJEXCHMB12.corp.ad.broadcom.com>
 <CACRpkdY2vWvvE_NToQ5rkxGC32hCJgMjNpkF+KEGJ+-o4My4-Q@mail.gmail.com>
Message-ID: <051069C10411E24D9749790C498526FA1BCF58EB@SJEXCHMB12.corp.ad.broadcom.com>

>> Hmm, while it would be easy to create a macro to fill the static foo_pin_desc array
>> in the driver, this array would not be suitable for use with pinctrl_register().
> 
> Now I start to change opinion. You're right about this.
> 
>> I would have to, in the probe function, loop through the foo_pin_desc array and
>> create another pinctrl_pin_desc array to use for pinctrl_desc.pins.
> 
> Yeah that sucks.
> 
>> I think I'll just use a separate struct in the driver to keep track of other pin-specific data.
> 
> No I think I have changed opinion. Can you send a patch adding a void * to
> struct pinctrl_pin_desc  as patch [1/n] when you send your driver, and
> I think I'll be happy with it.

Great!  This will definitely work for my chip, and I can do it as the first of n patches 
for my driver later.  While we are considering a change to pinctrl_pin_desc, I just 
want to point out a more forward-thinking solution:

The void* method works well for my chip where each pin can be one of only 
3 types, such as:

=====
static const int std_pin = PIN_TYPE_STD;
static const int i2c_pin = PIN_TYPE_I2C;

#define FOO_PIN(a,b,c) {.number=a, .name=b, .drv_data=&c)

static const struct pinctrl_pin_desc foo_pins[] = {
  FOO_PIN(PIN_NUM_1, "pin name 1", std_pin),
  FOO_PIN(PIN_NUM_2, "pin name 2", i2c_pin),
  FOO_PIN(PIN_NUM_3, "pin name 3", i2c_pin),
  ...
};
=====

but this may not work well for drivers where the private data is unique for every 
pin.  drv_data is a void*, so the data has to be defined first (potentially, this is another 
long array) before the pinctrl_pin_desc MACRO can refer to the address like the 
code above.  

I think ultimately the most flexible solution would be to let each driver define their own 
pin_desc like pin groups and pin functions.  This would involve some changes 
to the core:
- instead of having a pinctrl_pin_desc array in pinctrl_desc, expand it to 2 arrays - 
unsigned pin_number array and const char pin_name array
- APIs such as pinctrl_register() and pinctrl_free_pindescs() will have to similarly 
expand pinctrl_pin_desc into its 2 components.

Right now, I don't think it is worth the effort to change all the drivers and core code for
this flexibility, since no driver currently uses it.  Just wanted to point this out for 
consideration.

Thanks,
Sherman




From horms at verge.net.au  Mon Apr 29 21:47:27 2013
From: horms at verge.net.au (Simon Horman)
Date: Tue, 30 Apr 2013 10:47:27 +0900
Subject: [PATCH 0/6] ARM: shmobile: r8a7740: add MMCIF and SDHI to DT
In-Reply-To: <1366993667-23294-1-git-send-email-g.liakhovetski@gmx.de>
References: <1366993667-23294-1-git-send-email-g.liakhovetski@gmx.de>
Message-ID: <20130430014727.GC22535@verge.net.au>

On Fri, Apr 26, 2013 at 06:27:41PM +0200, Guennadi Liakhovetski wrote:
> These patches add DT support for MMCIF and SDHI including DMA on 
> armadillo800eva-reference r8a7740 board. They require my previous 
> SHDMA DT and SDHI and MMCIF DMA patches.

Please repost once there is a branch or rc release that those patches
have been merged into which I can base a branch on.


From horms at verge.net.au  Mon Apr 29 21:58:40 2013
From: horms at verge.net.au (Simon Horman)
Date: Tue, 30 Apr 2013 10:58:40 +0900
Subject: [PATCH 03/21] ARM: shmobile: don't call irqchip_init
 unconditionally
In-Reply-To: <201304291649.08084.arnd@arndb.de>
References: <1366910944-3033663-1-git-send-email-arnd@arndb.de>
 <1366910944-3033663-4-git-send-email-arnd@arndb.de>
 <20130426004835.GA20070@verge.net.au>
 <201304291649.08084.arnd@arndb.de>
Message-ID: <20130430015840.GG22535@verge.net.au>

On Mon, Apr 29, 2013 at 04:49:07PM +0200, Arnd Bergmann wrote:
> On Friday 26 April 2013, Simon Horman wrote:
> > > diff --git a/arch/arm/mach-shmobile/intc-r8a7740.c b/arch/arm/mach-shmobile/intc-r8a7740.c
> > > index 8871f77..5dc57f1 100644
> > > --- a/arch/arm/mach-shmobile/intc-r8a7740.c
> > > +++ b/arch/arm/mach-shmobile/intc-r8a7740.c
> > > @@ -53,14 +53,23 @@ static void __init r8a7740_init_irq_common(void)
> > >  
> > >  void __init r8a7740_init_irq_of(void)
> > >  {
> > > +     if (!IS_ENABLED(CONFIG_OF))
> > > +             return;
> > > +
> > 
> > In other parts of the shmobile I believe that such code is
> > guarded by #ifdef CONFIG_OF and I believe not guarding this code in
> > some way was an oversight.
> > 
> > The above change seems fine to me.
> 
> Ok. The change that broke the code is only present in linux-next from
> one of your trees, but is not in arm-soc. Could you include the change
> in your tree, either by folding into one of your patches or adapting
> my patch appropriately?

Yes, or of course. I'll queue-up your patch with
the second hunk (below) removed.

> > > +
> > > +     gic_dist_base = ioremap_nocache(0xc2800000, 0x1000);
> > > +     gic_cpu_base = ioremap_nocache(0xc2000000, 0x1000);
> > >  
> > >       /* initialize the Generic Interrupt Controller PL390 r0p0 */
> > >       gic_init(0, 29, gic_dist_base, gic_cpu_base);
> > 
> > This one seems broken as the armadillo800eva board currently uses
> > it to initialise GIC even if CONFIG_ATAGS is not defined.
> > 
> > I did test the above change on the armadillo800eva board
> > with the above change and CONFIG_ATAGS disabled, the result was
> > a boot failure. With the change reverted booting seems fine.
> 
> Yes, I see my mistake now. The second change was clearly wrong
> as this function is also used for DT boards, not for ATAGS boards.
> 
> 	Arnd
> 


From horms at verge.net.au  Mon Apr 29 22:08:22 2013
From: horms at verge.net.au (Simon Horman)
Date: Tue, 30 Apr 2013 11:08:22 +0900
Subject: [PATCH] ARM: shmobile: sh73a0: Use DEFINE_RES_MEM*() everywhere
In-Reply-To: <1366684035-6882-1-git-send-email-horms+renesas@verge.net.au>
References: <1366684035-6882-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <20130430020822.GA5021@verge.net.au>

On Tue, Apr 23, 2013 at 11:27:15AM +0900, Simon Horman wrote:
> Convert code to use DEFINE_RES_MEM*() macros.
> These macros were already used in this file,
> this change makes their usage consistent throughout the file.
> 
> Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
> 
> ---
> 
> v2
> * As suggested by Sergei Shtylyov:
>   Correct change log to refer to DEFINE_RES_MEM* instead of
>   IORESOURCE_MEM_*.

Queued-up for v3.11 in the soc-sh73a0 branch.


From horms at verge.net.au  Mon Apr 29 22:10:04 2013
From: horms at verge.net.au (Simon Horman)
Date: Tue, 30 Apr 2013 11:10:04 +0900
Subject: [PATCH] ARM: shmobile: lager: Add GPIO LEDs
In-Reply-To: <1366684625-17256-1-git-send-email-horms+renesas@verge.net.au>
References: <1366684625-17256-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <20130430021002.GA5547@verge.net.au>

On Tue, Apr 23, 2013 at 11:37:05AM +0900, Simon Horman wrote:
> The board has 3 LEDs connected to GPIOs. Add a led-gpio device to
> support them.
> 
> Based on "ARM: shmobile: marzen: Add GPIO LEDs" by Laurent Pinchart.
> 
> Cc: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
> Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
> 
> ---
> 
> v2
> * As suggested by Sergei Shtylyov:
>   Use platform_device_register_data() instead of platform_add_devices()
> * As suggested by Laurent Pinchart:
>   Use -1 as device id as there is only one such device
> ---
>  arch/arm/mach-shmobile/board-lager.c | 27 +++++++++++++++++++++++++++
>  1 file changed, 27 insertions(+)

I have queued-up this patch for v3.11 in the boards-lager branch.


From horms at verge.net.au  Mon Apr 29 22:25:55 2013
From: horms at verge.net.au (Simon Horman)
Date: Tue, 30 Apr 2013 11:25:55 +0900
Subject: [PATCH 03/21] ARM: shmobile: don't call irqchip_init
 unconditionally
In-Reply-To: <20130430015840.GG22535@verge.net.au>
References: <1366910944-3033663-1-git-send-email-arnd@arndb.de>
 <1366910944-3033663-4-git-send-email-arnd@arndb.de>
 <20130426004835.GA20070@verge.net.au>
 <201304291649.08084.arnd@arndb.de>
 <20130430015840.GG22535@verge.net.au>
Message-ID: <20130430022555.GB24214@verge.net.au>

On Tue, Apr 30, 2013 at 10:58:40AM +0900, Simon Horman wrote:
> On Mon, Apr 29, 2013 at 04:49:07PM +0200, Arnd Bergmann wrote:
> > On Friday 26 April 2013, Simon Horman wrote:
> > > > diff --git a/arch/arm/mach-shmobile/intc-r8a7740.c b/arch/arm/mach-shmobile/intc-r8a7740.c
> > > > index 8871f77..5dc57f1 100644
> > > > --- a/arch/arm/mach-shmobile/intc-r8a7740.c
> > > > +++ b/arch/arm/mach-shmobile/intc-r8a7740.c
> > > > @@ -53,14 +53,23 @@ static void __init r8a7740_init_irq_common(void)
> > > >  
> > > >  void __init r8a7740_init_irq_of(void)
> > > >  {
> > > > +     if (!IS_ENABLED(CONFIG_OF))
> > > > +             return;
> > > > +
> > > 
> > > In other parts of the shmobile I believe that such code is
> > > guarded by #ifdef CONFIG_OF and I believe not guarding this code in
> > > some way was an oversight.
> > > 
> > > The above change seems fine to me.
> > 
> > Ok. The change that broke the code is only present in linux-next from
> > one of your trees, but is not in arm-soc. Could you include the change
> > in your tree, either by folding into one of your patches or adapting
> > my patch appropriately?
> 
> Yes, or of course. I'll queue-up your patch with
> the second hunk (below) removed.
> 
> > > > +
> > > > +     gic_dist_base = ioremap_nocache(0xc2800000, 0x1000);
> > > > +     gic_cpu_base = ioremap_nocache(0xc2000000, 0x1000);
> > > >  
> > > >       /* initialize the Generic Interrupt Controller PL390 r0p0 */
> > > >       gic_init(0, 29, gic_dist_base, gic_cpu_base);
> > > 
> > > This one seems broken as the armadillo800eva board currently uses
> > > it to initialise GIC even if CONFIG_ATAGS is not defined.
> > > 
> > > I did test the above change on the armadillo800eva board
> > > with the above change and CONFIG_ATAGS disabled, the result was
> > > a boot failure. With the change reverted booting seems fine.
> > 
> > Yes, I see my mistake now. The second change was clearly wrong
> > as this function is also used for DT boards, not for ATAGS boards.
> > 
> > 	Arnd

I have queued-up the following in the soc-r8a7740 branch of the
renesas tree and will push it shortly. It should subsequently arrive
in linux-next.

>From ea19ad39e1d2b095fe867103fdf7c8dd8240a832 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd at arndb.de>
Date: Thu, 25 Apr 2013 19:28:46 +0200
Subject: [PATCH] ARM: shmobile: don't call irqchip_init unconditionally

The irqchip_init function is only available when building
with CONFIG_OF enabled, which causes this build failure for
bonito_defconfig:

arch/arm/mach-shmobile/built-in.o: In function `r8a7740_init_irq_of':
:(.init.text+0x580): undefined reference to `irqchip_init'

This makes the OF portion of the driver conditional, which avoids
the build error and also results in smaller object code OF is disabled,
without the need for an #ifdef.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Cc: Bastian Hecht <hechtb+renesas at gmail.com>
Cc: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
[horms+renesas at verge.net.au: Remove ATAGS portion which causes boot failure]
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/intc-r8a7740.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/mach-shmobile/intc-r8a7740.c b/arch/arm/mach-shmobile/intc-r8a7740.c
index 8871f77..61e2a21 100644
--- a/arch/arm/mach-shmobile/intc-r8a7740.c
+++ b/arch/arm/mach-shmobile/intc-r8a7740.c
@@ -53,6 +53,9 @@ static void __init r8a7740_init_irq_common(void)
 
 void __init r8a7740_init_irq_of(void)
 {
+	if (!IS_ENABLED(CONFIG_OF))
+		return;
+
 	irqchip_init();
 	r8a7740_init_irq_common();
 }
-- 
1.8.2.1



From mtosatti at redhat.com  Mon Apr 29 22:11:36 2013
From: mtosatti at redhat.com (Marcelo Tosatti)
Date: Mon, 29 Apr 2013 23:11:36 -0300
Subject: [GIT PULL] KVM/ARM Changes for 3.10
In-Reply-To: <CAEDV+gKXcCb11p5YCQRbQ1OwGefxYUr0sh8f4AOfxQSPPo2LMQ@mail.gmail.com>
References: <CAEDV+gKXcCb11p5YCQRbQ1OwGefxYUr0sh8f4AOfxQSPPo2LMQ@mail.gmail.com>
Message-ID: <20130430021136.GB14088@amt.cnet>

On Sun, Apr 28, 2013 at 10:29:07PM -0700, Christoffer Dall wrote:
> Hi Marcelo and Gleb,
> 
> These are the changes for KVM/ARM for 3.10.
> 
> The patches depend on the cleanup branch, which you've already merged.
> 
> Main thing is the reworking of Hyp idmaps, which is now handled by KVM
> instead of arm/mm and includes several nasty bug fixes from Marc in
> the progress.
> 
> Thanks!
> 
> The following changes since commit 5a2892ce72e010e3cb96b438d7cdddce0c88e0e6:
> 
>   KVM: nVMX: Skip PF interception check when queuing during nested run
> (2013-04-28 13:34:39 +0300)
> 
> are available in the git repository at:
> 
>   git://github.com/columbia/linux-kvm-arm.git kvm-arm-for-3.10
> 
> for you to fetch changes up to d4e071ce6acf8d5eddb7615a953193a8b0ad7c38:
> 
>   ARM: KVM: iterate over all CPUs for CPU compatibility check
> (2013-04-28 22:23:23 -0700)

Christoffer,

Please email the patches to kvm at vger.




From cdall at cs.columbia.edu  Mon Apr 29 22:52:41 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Mon, 29 Apr 2013 19:52:41 -0700
Subject: [GIT PULL] KVM/ARM Changes for 3.10
In-Reply-To: <20130430021136.GB14088@amt.cnet>
References: <CAEDV+gKXcCb11p5YCQRbQ1OwGefxYUr0sh8f4AOfxQSPPo2LMQ@mail.gmail.com>
 <20130430021136.GB14088@amt.cnet>
Message-ID: <CAEDV+gLbqUgzkRoToYKSBTXKzUkY40fO80rcviu-EHcbxYjL4A@mail.gmail.com>

On Mon, Apr 29, 2013 at 7:11 PM, Marcelo Tosatti <mtosatti at redhat.com> wrote:
> On Sun, Apr 28, 2013 at 10:29:07PM -0700, Christoffer Dall wrote:
>> Hi Marcelo and Gleb,
>>
>> These are the changes for KVM/ARM for 3.10.
>>
>> The patches depend on the cleanup branch, which you've already merged.
>>
>> Main thing is the reworking of Hyp idmaps, which is now handled by KVM
>> instead of arm/mm and includes several nasty bug fixes from Marc in
>> the progress.
>>
>> Thanks!
>>
>> The following changes since commit 5a2892ce72e010e3cb96b438d7cdddce0c88e0e6:
>>
>>   KVM: nVMX: Skip PF interception check when queuing during nested run
>> (2013-04-28 13:34:39 +0300)
>>
>> are available in the git repository at:
>>
>>   git://github.com/columbia/linux-kvm-arm.git kvm-arm-for-3.10
>>
>> for you to fetch changes up to d4e071ce6acf8d5eddb7615a953193a8b0ad7c38:
>>
>>   ARM: KVM: iterate over all CPUs for CPU compatibility check
>> (2013-04-28 22:23:23 -0700)
>
> Christoffer,
>
> Please email the patches to kvm at vger.
>
>

each of them were already cc'ed on the kvm mailing list when they were
reviewed I believe, but would you like to have them re-sent as they
are not in this pull request even if it means re-sending them?

-Christoffer


From dhobsong at igel.co.jp  Mon Apr 29 23:01:39 2013
From: dhobsong at igel.co.jp (Damian Hobson-Garcia)
Date: Tue, 30 Apr 2013 12:01:39 +0900
Subject: [PATCH v2 0/4] dma-mapping: Define dma_{alloc,
 free}_attrs() for all archs
Message-ID: <1367290899-10410-1-git-send-email-dhobsong@igel.co.jp>

Most architectures that define CONFIG_HAVE_DMA=y, have implementations for
both dma_alloc_attrs() and dma_free_attrs().  All achitectures that do
not define CONFIG_HAVE_DMA also have both of these definitions provided by
dma-mapping-broken.h.

Provide a default definition for the archs that define CONFIG_HAVE_DMA=y,
but have no implementation for dma_{alloc,free}_attrs(). 

As I don't have hardware for any of these systems, the patches are only
compile-tested where I could (arm64, s390) and untested for the archs
where I couldn't find a readily available prebuilt cross-compiler (c6x, parisc).

Changes from v1
---------------

arm64, s390:
 * Since these archs are using dma_ops, pass appropirate value for attrs to 
   dma_ops->alloc().
 * Indicate that these patches are compile teseted only (I don't have hardware)


c6x, parisc:
 * Indicate that these patches are untested (I don't have cross compilers)

Cheers,
Damian 


Damian Hobson-Garcia (4):
  arm64: Provide default implementation for dma_{alloc,free}_attrs
  c6x: Provide default implementation for dma_{alloc,free}_attrs
  parisc: Provide default implementation for dma_{alloc,free}_attrs
  s390: Provide default implementation for dma_{alloc,free}_attrs

 arch/arm64/include/asm/dma-mapping.h  |   17 +++++++++++------
 arch/c6x/include/asm/dma-mapping.h    |    3 +++
 arch/parisc/include/asm/dma-mapping.h |    3 +++
 arch/s390/include/asm/dma-mapping.h   |   17 +++++++++++------
 4 files changed, 28 insertions(+), 12 deletions(-)

-- 
1.7.5.4



From dhobsong at igel.co.jp  Mon Apr 29 23:02:13 2013
From: dhobsong at igel.co.jp (Damian Hobson-Garcia)
Date: Tue, 30 Apr 2013 12:02:13 +0900
Subject: [PATCH v2 1/4] arm64: Provide default implementation for dma_{alloc,
 free}_attrs
Message-ID: <1367290933-10453-1-git-send-email-dhobsong@igel.co.jp>

Most architectures that define CONFIG_HAVE_DMA, have implementations for
both dma_alloc_attrs() and dma_free_attrs().  All achitectures that do
not define CONFIG_HAVE_DMA also have both of these definitions provided by
dma-mapping-broken.h.

Add default implementations for these functions on arm64.

Signed-off-by: Damian Hobson-Garcia <dhobsong at igel.co.jp>
---
 arch/arm64/include/asm/dma-mapping.h |   17 +++++++++++------
 1 files changed, 11 insertions(+), 6 deletions(-)

diff --git a/arch/arm64/include/asm/dma-mapping.h b/arch/arm64/include/asm/dma-mapping.h
index 9947768..6ff7b8d 100644
--- a/arch/arm64/include/asm/dma-mapping.h
+++ b/arch/arm64/include/asm/dma-mapping.h
@@ -81,8 +81,12 @@ static inline void dma_mark_clean(void *addr, size_t size)
 {
 }
 
-static inline void *dma_alloc_coherent(struct device *dev, size_t size,
-				       dma_addr_t *dma_handle, gfp_t flags)
+#define dma_alloc_coherent(d, s, h, f) dma_alloc_attrs(d, s, h, f, NULL)
+#define dma_free_coherent(d, s, h, f) dma_free_attrs(d, s, h, f, NULL)
+
+static inline void *dma_alloc_attrs(struct device *dev, size_t size,
+				       dma_addr_t *dma_handle, gfp_t flags,
+				       struct dma_attrs *attrs)
 {
 	struct dma_map_ops *ops = get_dma_ops(dev);
 	void *vaddr;
@@ -90,13 +94,14 @@ static inline void *dma_alloc_coherent(struct device *dev, size_t size,
 	if (dma_alloc_from_coherent(dev, size, dma_handle, &vaddr))
 		return vaddr;
 
-	vaddr = ops->alloc(dev, size, dma_handle, flags, NULL);
+	vaddr = ops->alloc(dev, size, dma_handle, flags, attrs);
 	debug_dma_alloc_coherent(dev, size, *dma_handle, vaddr);
 	return vaddr;
 }
 
-static inline void dma_free_coherent(struct device *dev, size_t size,
-				     void *vaddr, dma_addr_t dev_addr)
+static inline void dma_free_attrs(struct device *dev, size_t size,
+				     void *vaddr, dma_addr_t dev_addr,
+				     struct dma_attrs *attrs)
 {
 	struct dma_map_ops *ops = get_dma_ops(dev);
 
@@ -104,7 +109,7 @@ static inline void dma_free_coherent(struct device *dev, size_t size,
 		return;
 
 	debug_dma_free_coherent(dev, size, vaddr, dev_addr);
-	ops->free(dev, size, vaddr, dev_addr, NULL);
+	ops->free(dev, size, vaddr, dev_addr, attrs);
 }
 
 /*
-- 
1.7.5.4



From nsekhar at ti.com  Tue Apr 30 01:01:59 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Tue, 30 Apr 2013 10:31:59 +0530
Subject: [v2,1/3] ARM: dts: AM33XX: Add ELM node
In-Reply-To: <7fa7438c9a7c5da575d762423815625d523c4689.1359007746.git.avinashphilip@ti.com>
References: <7fa7438c9a7c5da575d762423815625d523c4689.1359007746.git.avinashphilip@ti.com>
Message-ID: <517F5047.5040507@ti.com>

On 4/29/2013 1:23 PM, Gupta, Pekon wrote:
> From: avinash philip <avinashphilip at ti.com>
> 
> From: "Philip, Avinash" <avinashphilip at ti.com>

From: line is repeated twice.

> 
> Add ELM data node to AM33XX device tree file.
> 
> Signed-off-by: Philip Avinash <avinashphilip at ti.com>
> Acked-by: Peter Korsgaard <jacmet at sunsite.dk>
> Tested-by: Pekon Gupta <pekon at ti.com>

You should add your sign-off (instead of tested-by) since you are now in
the submission path.

Thanks,
Sekhar


From nsekhar at ti.com  Tue Apr 30 01:05:42 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Tue, 30 Apr 2013 10:35:42 +0530
Subject: [v2, 3/3] ARM: dts: AM33XX: Add NAND flash device tree data to
 am335x-evm
In-Reply-To: <ebfab3e9123b3e50b9a9678c1480191addd86d59.1359007746.git.avinashphilip@ti.com>
References: <ebfab3e9123b3e50b9a9678c1480191addd86d59.1359007746.git.avinashphilip@ti.com>
Message-ID: <517F5126.5000509@ti.com>


On 4/29/2013 1:25 PM, Gupta, Pekon wrote:
> From: avinash philip <avinashphilip at ti.com>
> 
> NAND flash connected in am335x-evm on GPMC controller. This patch adds
> device tree node in am3355-evm with GPMC contoller timing for NAND flash
> interface, NAND partition table, ECC scheme, elm handle id.
> 
> Signed-off-by: Philip Avinash <avinashphilip at ti.com>
> Tested-by: Pekon Gupta <pekon at ti.com>
> 
> ---
> arch/arm/boot/dts/am335x-evm.dts |   98 +++++++++++++++++++++++++++++++++++++-
>  1 file changed, 97 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
> index 0423298..1c2fd89 100644
> --- a/arch/arm/boot/dts/am335x-evm.dts
> +++ b/arch/arm/boot/dts/am335x-evm.dts
> @@ -26,7 +26,8 @@
>  
>  	am33xx_pinmux: pinmux at 44e10800 {
>  		pinctrl-names = "default";
> -		pinctrl-0 = <&matrix_keypad_s0 &volume_keys_s0>;
> +		pinctrl-0 = <&matrix_keypad_s0 &volume_keys_s0
> +			&nandflash_pins_s0>;

Why add this to the board level fallback (called pinctrl hogs, I think)?
This can be part of nand node you added below so that the pinctrl will
take effect when nand gets probed instead of all the time.

Thanks,
Sekhar


From anup.patel at linaro.org  Tue Apr 30 01:27:31 2013
From: anup.patel at linaro.org (Anup Patel)
Date: Tue, 30 Apr 2013 10:57:31 +0530
Subject: [PATCH V2] ARM: KVM: Allow host virt timer irq to be different
 from guest timer virt irq
In-Reply-To: <CAEDV+gJi7+YGeAqT5xK0d+AzwMVO6LqO1so8NG7RpbV569y_rA@mail.gmail.com>
References: <1367220347-5625-1-git-send-email-anup.patel@linaro.org>
 <CAEDV+gJi7+YGeAqT5xK0d+AzwMVO6LqO1so8NG7RpbV569y_rA@mail.gmail.com>
Message-ID: <CALrVBkvrrGx9Lt=6PjCRJ7H=ajYgikimGKxqR2bJcF-yfezq1g@mail.gmail.com>

On 29 April 2013 22:05, Christoffer Dall <cdall at cs.columbia.edu> wrote:
> On Mon, Apr 29, 2013 at 12:25 AM, Anup Patel <anup.patel at linaro.org> wrote:
>> The arch_timer irq numbers (or PPI numbers) are implementation dependent
>> so, the host virtual timer irq number can be different from guest virtual
>> timer irq number.
>
> nit: move comma before 'so'

Ok.

>
>>
>> This patch ensures that host virtual timer irq number is read from DTB and
>> guest virtual timer irq is determined based on vcpu target type.
>>
>> Signed-off-by: Anup Patel <anup.patel at linaro.org>
>> Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar at linaro.org>
>> ---
>>  arch/arm/include/asm/kvm_arch_timer.h |    4 ++++
>>  arch/arm/kvm/arch_timer.c             |   27 ++++++++++++++++++++-------
>>  arch/arm/kvm/reset.c                  |   11 +++++++++++
>>  3 files changed, 35 insertions(+), 7 deletions(-)
>>
>> diff --git a/arch/arm/include/asm/kvm_arch_timer.h b/arch/arm/include/asm/kvm_arch_timer.h
>> index 68cb9e1..eeb2a3f 100644
>> --- a/arch/arm/include/asm/kvm_arch_timer.h
>> +++ b/arch/arm/include/asm/kvm_arch_timer.h
>> @@ -61,6 +61,8 @@ struct arch_timer_cpu {
>>  #ifdef CONFIG_KVM_ARM_TIMER
>>  int kvm_timer_hyp_init(void);
>>  int kvm_timer_init(struct kvm *kvm);
>> +void kvm_timer_vcpu_reset(struct kvm_vcpu *vcpu,
>> +                         const struct kvm_irq_level *irq);
>>  void kvm_timer_vcpu_init(struct kvm_vcpu *vcpu);
>>  void kvm_timer_flush_hwstate(struct kvm_vcpu *vcpu);
>>  void kvm_timer_sync_hwstate(struct kvm_vcpu *vcpu);
>> @@ -76,6 +78,8 @@ static inline int kvm_timer_init(struct kvm *kvm)
>>         return 0;
>>  }
>>
>> +static inline void kvm_timer_vcpu_reset(struct kvm_vcpu *vcpu,
>> +                                       const struct kvm_irq_level *irq) {}
>>  static inline void kvm_timer_vcpu_init(struct kvm_vcpu *vcpu) {}
>>  static inline void kvm_timer_flush_hwstate(struct kvm_vcpu *vcpu) {}
>>  static inline void kvm_timer_sync_hwstate(struct kvm_vcpu *vcpu) {}
>> diff --git a/arch/arm/kvm/arch_timer.c b/arch/arm/kvm/arch_timer.c
>> index 49a7516..c64b597 100644
>> --- a/arch/arm/kvm/arch_timer.c
>> +++ b/arch/arm/kvm/arch_timer.c
>> @@ -30,7 +30,7 @@
>>
>>  static struct timecounter *timecounter;
>>  static struct workqueue_struct *wqueue;
>> -static struct kvm_irq_level timer_irq = {
>> +static struct kvm_irq_level host_timer_irq = {
>>         .level  = 1,
>>  };
>
> there is no need for this to be a struct kvm_irq_level anymore, this
> has nothing to do with a VM, it is just a number, so an unsigned int
> would be more appropriate.

Oke, will make it unsigned int.

>
>>
>> @@ -67,8 +67,8 @@ static void kvm_timer_inject_irq(struct kvm_vcpu *vcpu)
>>
>>         timer->cntv_ctl |= ARCH_TIMER_CTRL_IT_MASK;
>>         kvm_vgic_inject_irq(vcpu->kvm, vcpu->vcpu_id,
>> -                           vcpu->arch.timer_cpu.irq->irq,
>> -                           vcpu->arch.timer_cpu.irq->level);
>> +                           timer->irq->irq,
>> +                           timer->irq->level);
>>  }
>>
>>  static irqreturn_t kvm_arch_timer_handler(int irq, void *dev_id)
>> @@ -156,6 +156,20 @@ void kvm_timer_sync_hwstate(struct kvm_vcpu *vcpu)
>>         timer_arm(timer, ns);
>>  }
>>
>> +void kvm_timer_vcpu_reset(struct kvm_vcpu *vcpu,
>> +                         const struct kvm_irq_level *irq)
>> +{
>> +       struct arch_timer_cpu *timer = &vcpu->arch.timer_cpu;
>> +
>> +       /*
>> +        * The vcpu timer irq number cannot be determined in
>> +        * kvm_timer_vcpu_init() because it is called much before
>> +        * kvm_vcpu_set_target(). To handle this, we determine
>> +        * vcpu timer irq number when the vcpu is resetted.
>
> s/resetted/reset/

Ok.

>
>> +        */
>> +       timer->irq = irq;
>> +}
>> +
>>  void kvm_timer_vcpu_init(struct kvm_vcpu *vcpu)
>>  {
>>         struct arch_timer_cpu *timer = &vcpu->arch.timer_cpu;
>> @@ -163,12 +177,11 @@ void kvm_timer_vcpu_init(struct kvm_vcpu *vcpu)
>>         INIT_WORK(&timer->expired, kvm_timer_inject_irq_work);
>>         hrtimer_init(&timer->timer, CLOCK_MONOTONIC, HRTIMER_MODE_ABS);
>>         timer->timer.function = kvm_timer_expire;
>> -       timer->irq = &timer_irq;
>>  }
>>
>>  static void kvm_timer_init_interrupt(void *info)
>>  {
>> -       enable_percpu_irq(timer_irq.irq, 0);
>> +       enable_percpu_irq(host_timer_irq.irq, 0);
>>  }
>>
>>
>> @@ -182,7 +195,7 @@ static int kvm_timer_cpu_notify(struct notifier_block *self,
>>                 break;
>>         case CPU_DYING:
>>         case CPU_DYING_FROZEN:
>> -               disable_percpu_irq(timer_irq.irq);
>> +               disable_percpu_irq(host_timer_irq.irq);
>>                 break;
>>         }
>>
>> @@ -230,7 +243,7 @@ int kvm_timer_hyp_init(void)
>>                 goto out;
>>         }
>>
>> -       timer_irq.irq = ppi;
>> +       host_timer_irq.irq = ppi;
>>
>>         err = register_cpu_notifier(&kvm_timer_cpu_nb);
>>         if (err) {
>> diff --git a/arch/arm/kvm/reset.c b/arch/arm/kvm/reset.c
>> index b80256b..0b49ad7 100644
>> --- a/arch/arm/kvm/reset.c
>> +++ b/arch/arm/kvm/reset.c
>> @@ -26,6 +26,7 @@
>>  #include <asm/cputype.h>
>>  #include <asm/kvm_arm.h>
>>  #include <asm/kvm_coproc.h>
>> +#include <asm/kvm_arch_timer.h>
>>
>>  /******************************************************************************
>>   * Cortex-A15 Reset Values
>> @@ -37,6 +38,11 @@ static struct kvm_regs a15_regs_reset = {
>>         .usr_regs.ARM_cpsr = SVC_MODE | PSR_A_BIT | PSR_I_BIT | PSR_F_BIT,
>>  };
>>
>> +static const struct kvm_irq_level a15_vtimer_irq = {
>> +       .irq = 27,
>> +       .level = 1,
>> +};
>> +
>>
>>  /*******************************************************************************
>>   * Exported reset function
>> @@ -52,6 +58,7 @@ static struct kvm_regs a15_regs_reset = {
>>  int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
>>  {
>>         struct kvm_regs *cpu_reset;
>> +       const struct kvm_irq_level *cpu_vtimer_irq;
>>
>>         switch (vcpu->arch.target) {
>>         case KVM_ARM_TARGET_CORTEX_A15:
>> @@ -59,6 +66,7 @@ int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
>>                         return -EINVAL;
>>                 cpu_reset = &a15_regs_reset;
>>                 vcpu->arch.midr = read_cpuid_id();
>> +               cpu_vtimer_irq = &a15_vtimer_irq;
>>                 break;
>>         default:
>>                 return -ENODEV;
>> @@ -70,5 +78,8 @@ int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
>>         /* Reset CP15 registers */
>>         kvm_reset_coprocs(vcpu);
>>
>> +       /* Reset arch_timer context */
>> +       kvm_timer_vcpu_reset(vcpu, cpu_vtimer_irq);
>> +
>>         return 0;
>>  }
>> --
>> 1.7.9.5
>>
>> _______________________________________________
>> kvmarm mailing list
>> kvmarm at lists.cs.columbia.edu
>> https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm

Regards,
Anup


From anup.patel at linaro.org  Tue Apr 30 01:28:14 2013
From: anup.patel at linaro.org (Anup Patel)
Date: Tue, 30 Apr 2013 10:58:14 +0530
Subject: [PATCH V2] arm64: KVM: Reset arch_timer upon vcpu reset
In-Reply-To: <CAEDV+gJOMnoWVHU3bqUBUzciy7mx38a1wVWqTP1TMbvS8XXDCg@mail.gmail.com>
References: <1367220500-5690-1-git-send-email-anup.patel@linaro.org>
 <CAEDV+gJOMnoWVHU3bqUBUzciy7mx38a1wVWqTP1TMbvS8XXDCg@mail.gmail.com>
Message-ID: <CALrVBks5Nq5ti9NeozALBxAmkkKE629Lqz0BAHeiKqU8pW9c1w@mail.gmail.com>

On 29 April 2013 22:10, Christoffer Dall <cdall at cs.columbia.edu> wrote:
> On Mon, Apr 29, 2013 at 12:28 AM, Anup Patel <anup.patel at linaro.org> wrote:
>> This patch does arch_timer reset (i.e. kvm_timer_vcpu_reset()) when
>> a vcpu resetted by kvm_reset_vcpu().
>>
>> The kvm_reset_vcpu() also informs guest timer irq number to arch_timer
>> code via kvm_timer_vcpu_reset().
>
> This commit text did not parse.
>
> Might I suggest:
>
> "Reset the arch_timer on cpu reset and configure guest virtual timer
> irq in the process".

Ok, will change commit description.

>
>>
>> Signed-off-by: Anup Patel <anup.patel at linaro.org>
>> Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar at linaro.org>
>> ---
>>  arch/arm64/include/asm/kvm_arch_timer.h |    2 ++
>>  arch/arm64/kvm/reset.c                  |   11 +++++++++++
>>  2 files changed, 13 insertions(+)
>>
>> diff --git a/arch/arm64/include/asm/kvm_arch_timer.h b/arch/arm64/include/asm/kvm_arch_timer.h
>> index eb02273..0f36603 100644
>> --- a/arch/arm64/include/asm/kvm_arch_timer.h
>> +++ b/arch/arm64/include/asm/kvm_arch_timer.h
>> @@ -50,6 +50,8 @@ struct arch_timer_cpu {
>>
>>  int kvm_timer_hyp_init(void);
>>  int kvm_timer_init(struct kvm *kvm);
>> +void kvm_timer_vcpu_reset(struct kvm_vcpu *vcpu,
>> +                         const struct kvm_irq_level *irq);
>>  void kvm_timer_vcpu_init(struct kvm_vcpu *vcpu);
>>  void kvm_timer_flush_hwstate(struct kvm_vcpu *vcpu);
>>  void kvm_timer_sync_hwstate(struct kvm_vcpu *vcpu);
>> diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
>> index 64e0740..7c9cebc 100644
>> --- a/arch/arm64/kvm/reset.c
>> +++ b/arch/arm64/kvm/reset.c
>> @@ -27,6 +27,7 @@
>>  #include <asm/ptrace.h>
>>  #include <asm/kvm_arm.h>
>>  #include <asm/kvm_coproc.h>
>> +#include <asm/kvm_arch_timer.h>
>>
>>  /*
>>   * ARMv8 Reset Values
>> @@ -40,6 +41,11 @@ static struct kvm_regs default_regs_reset32 = {
>>                         COMPAT_PSR_I_BIT | COMPAT_PSR_F_BIT),
>>  };
>>
>> +static const struct kvm_irq_level default_vtimer_irq = {
>> +       .irq = 27,
>> +       .level = 1,
>> +};
>> +
>>  static bool cpu_has_32bit_el1(void)
>>  {
>>         u64 pfr0;
>> @@ -75,6 +81,7 @@ int kvm_arch_dev_ioctl_check_extension(long ext)
>>  int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
>>  {
>>         struct kvm_regs *cpu_reset;
>> +       const struct kvm_irq_level *cpu_vtimer_irq;
>>
>>         switch (vcpu->arch.target) {
>>         default:
>> @@ -86,6 +93,7 @@ int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
>>                 } else {
>>                         cpu_reset = &default_regs_reset;
>>                 }
>> +               cpu_vtimer_irq = &default_vtimer_irq;
>>                 break;
>>         }
>>
>> @@ -95,5 +103,8 @@ int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
>>         /* Reset system registers */
>>         kvm_reset_sys_regs(vcpu);
>>
>> +       /* Reset arch_timer context */
>> +       kvm_timer_vcpu_reset(vcpu, cpu_vtimer_irq);
>> +
>>         return 0;
>>  }
>> --
>> 1.7.9.5
>>
>> _______________________________________________
>> kvmarm mailing list
>> kvmarm at lists.cs.columbia.edu
>> https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm

Regards,
Anup


From linux at prisktech.co.nz  Tue Apr 30 02:16:57 2013
From: linux at prisktech.co.nz (Tony Prisk)
Date: Tue, 30 Apr 2013 18:16:57 +1200
Subject: [PATCHv4 0/3] Add support for velocity network driver on platform
 devices
Message-ID: <1367302620-4620-1-git-send-email-linux@prisktech.co.nz>

v4 changes:
Code tidyup as requested by Francois Romieu
Removed '#ifdef PCI' around PCI code. Compile tested on (!)PCI and (!)PM.

v3 changes:
Rebased against net-next.
Fix errors in pm code.

v2 changes:
Drop patch #1 as requested by David Miller.
Correct the PHYID_ICPLUS_IP101A MII bits - should be ON, rather than OFF.
Read the platform rev_id from the correct register [regs->rev_id]. It's possible
this would work for the PCI version as well and would remove the need for the
'if (pci)' test to set vptr->rev_id.

v1:
The first three patches are general tidyup.

[DROPPED] Patch ## just alphabetizes the #includes to make it easier to read.

Patch #1 replaces vptr->dev with vptr->netdev, in preparation of adding a
struct device *dev in Patch #3

Patch #2 replaces the pci dma functions with the generic versions.

I have build tested these patches but don't have a PCI velocity to run-test it.
I can't see that they should introduce any problems as it is all renames and
function swapping.

Patch #3 adds support for the velocity driver on devicetree platform devices.
Binding document included. This patch is compile-tested for PCI, and boot
tested on a VIA APC8750.

I think it would be pertinent to get some tested-by's for PCI users.

Regards
Tony Prisk

Tony Prisk (3):
  net: velocity: Rename vptr->dev to vptr->netdev
  net: velocity: Convert to generic dma functions
  net: velocity: Add platform device support to VIA velocity driver

 .../devicetree/bindings/net/via-velocity.txt       |   20 +
 drivers/net/ethernet/via/Kconfig                   |    3 +-
 drivers/net/ethernet/via/via-velocity.c            |  546 ++++++++++++++------
 drivers/net/ethernet/via/via-velocity.h            |   40 +-
 4 files changed, 438 insertions(+), 171 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/net/via-velocity.txt

-- 
1.7.9.5



From linux at prisktech.co.nz  Tue Apr 30 02:16:59 2013
From: linux at prisktech.co.nz (Tony Prisk)
Date: Tue, 30 Apr 2013 18:16:59 +1200
Subject: [PATCHv4 2/3] net: velocity: Convert to generic dma functions
In-Reply-To: <1367302620-4620-1-git-send-email-linux@prisktech.co.nz>
References: <1367302620-4620-1-git-send-email-linux@prisktech.co.nz>
Message-ID: <1367302620-4620-3-git-send-email-linux@prisktech.co.nz>

Remove the pci_* dma functions and replace with the more generic
versions.

In preparation of adding platform support, a new struct device *dev
is added to struct velocity_info which can be used by both the pci
and platform code.

Signed-off-by: Tony Prisk <linux at prisktech.co.nz>
---
 drivers/net/ethernet/via/via-velocity.c |   51 +++++++++++++++----------------
 drivers/net/ethernet/via/via-velocity.h |    1 +
 2 files changed, 26 insertions(+), 26 deletions(-)

diff --git a/drivers/net/ethernet/via/via-velocity.c b/drivers/net/ethernet/via/via-velocity.c
index 187eef3..5996cee 100644
--- a/drivers/net/ethernet/via/via-velocity.c
+++ b/drivers/net/ethernet/via/via-velocity.c
@@ -46,6 +46,7 @@
 #include <linux/types.h>
 #include <linux/bitops.h>
 #include <linux/init.h>
+#include <linux/dma-mapping.h>
 #include <linux/mm.h>
 #include <linux/errno.h>
 #include <linux/ioport.h>
@@ -1459,7 +1460,6 @@ static int velocity_init_dma_rings(struct velocity_info *vptr)
 	struct velocity_opt *opt = &vptr->options;
 	const unsigned int rx_ring_size = opt->numrx * sizeof(struct rx_desc);
 	const unsigned int tx_ring_size = opt->numtx * sizeof(struct tx_desc);
-	struct pci_dev *pdev = vptr->pdev;
 	dma_addr_t pool_dma;
 	void *pool;
 	unsigned int i;
@@ -1467,13 +1467,13 @@ static int velocity_init_dma_rings(struct velocity_info *vptr)
 	/*
 	 * Allocate all RD/TD rings a single pool.
 	 *
-	 * pci_alloc_consistent() fulfills the requirement for 64 bytes
+	 * dma_alloc_coherent() fulfills the requirement for 64 bytes
 	 * alignment
 	 */
-	pool = pci_alloc_consistent(pdev, tx_ring_size * vptr->tx.numq +
-				    rx_ring_size, &pool_dma);
+	pool = dma_alloc_coherent(vptr->dev, tx_ring_size * vptr->tx.numq +
+				    rx_ring_size, &pool_dma, GFP_ATOMIC);
 	if (!pool) {
-		dev_err(&pdev->dev, "%s : DMA memory allocation failed.\n",
+		dev_err(vptr->dev, "%s : DMA memory allocation failed.\n",
 			vptr->netdev->name);
 		return -ENOMEM;
 	}
@@ -1524,8 +1524,8 @@ static int velocity_alloc_rx_buf(struct velocity_info *vptr, int idx)
 	 */
 	skb_reserve(rd_info->skb,
 			64 - ((unsigned long) rd_info->skb->data & 63));
-	rd_info->skb_dma = pci_map_single(vptr->pdev, rd_info->skb->data,
-					vptr->rx.buf_sz, PCI_DMA_FROMDEVICE);
+	rd_info->skb_dma = dma_map_single(vptr->dev, rd_info->skb->data,
+					vptr->rx.buf_sz, DMA_FROM_DEVICE);
 
 	/*
 	 *	Fill in the descriptor to match
@@ -1588,8 +1588,8 @@ static void velocity_free_rd_ring(struct velocity_info *vptr)
 
 		if (!rd_info->skb)
 			continue;
-		pci_unmap_single(vptr->pdev, rd_info->skb_dma, vptr->rx.buf_sz,
-				 PCI_DMA_FROMDEVICE);
+		dma_unmap_single(vptr->dev, rd_info->skb_dma, vptr->rx.buf_sz,
+				 DMA_FROM_DEVICE);
 		rd_info->skb_dma = 0;
 
 		dev_kfree_skb(rd_info->skb);
@@ -1670,7 +1670,7 @@ static void velocity_free_dma_rings(struct velocity_info *vptr)
 	const int size = vptr->options.numrx * sizeof(struct rx_desc) +
 		vptr->options.numtx * sizeof(struct tx_desc) * vptr->tx.numq;
 
-	pci_free_consistent(vptr->pdev, size, vptr->rx.ring, vptr->rx.pool_dma);
+	dma_free_coherent(vptr->dev, size, vptr->rx.ring, vptr->rx.pool_dma);
 }
 
 static int velocity_init_rings(struct velocity_info *vptr, int mtu)
@@ -1727,8 +1727,8 @@ static void velocity_free_tx_buf(struct velocity_info *vptr,
 				pktlen = max_t(size_t, pktlen,
 						td->td_buf[i].size & ~TD_QUEUE);
 
-			pci_unmap_single(vptr->pdev, tdinfo->skb_dma[i],
-					le16_to_cpu(pktlen), PCI_DMA_TODEVICE);
+			dma_unmap_single(vptr->dev, tdinfo->skb_dma[i],
+					le16_to_cpu(pktlen), DMA_TO_DEVICE);
 		}
 	}
 	dev_kfree_skb_irq(skb);
@@ -1750,8 +1750,8 @@ static void velocity_free_td_ring_entry(struct velocity_info *vptr,
 	if (td_info->skb) {
 		for (i = 0; i < td_info->nskb_dma; i++) {
 			if (td_info->skb_dma[i]) {
-				pci_unmap_single(vptr->pdev, td_info->skb_dma[i],
-					td_info->skb->len, PCI_DMA_TODEVICE);
+				dma_unmap_single(vptr->dev, td_info->skb_dma[i],
+					td_info->skb->len, DMA_TO_DEVICE);
 				td_info->skb_dma[i] = 0;
 			}
 		}
@@ -2029,7 +2029,6 @@ static inline void velocity_iph_realign(struct velocity_info *vptr,
  */
 static int velocity_receive_frame(struct velocity_info *vptr, int idx)
 {
-	void (*pci_action)(struct pci_dev *, dma_addr_t, size_t, int);
 	struct net_device_stats *stats = &vptr->netdev->stats;
 	struct velocity_rd_info *rd_info = &(vptr->rx.info[idx]);
 	struct rx_desc *rd = &(vptr->rx.ring[idx]);
@@ -2047,8 +2046,8 @@ static int velocity_receive_frame(struct velocity_info *vptr, int idx)
 
 	skb = rd_info->skb;
 
-	pci_dma_sync_single_for_cpu(vptr->pdev, rd_info->skb_dma,
-				    vptr->rx.buf_sz, PCI_DMA_FROMDEVICE);
+	dma_sync_single_for_cpu(vptr->dev, rd_info->skb_dma,
+				    vptr->rx.buf_sz, DMA_FROM_DEVICE);
 
 	/*
 	 *	Drop frame not meeting IEEE 802.3
@@ -2061,19 +2060,18 @@ static int velocity_receive_frame(struct velocity_info *vptr, int idx)
 		}
 	}
 
-	pci_action = pci_dma_sync_single_for_device;
-
 	velocity_rx_csum(rd, skb);
 
 	if (velocity_rx_copy(&skb, pkt_len, vptr) < 0) {
 		velocity_iph_realign(vptr, skb, pkt_len);
-		pci_action = pci_unmap_single;
 		rd_info->skb = NULL;
+		dma_unmap_single(vptr->dev, rd_info->skb_dma, vptr->rx.buf_sz,
+				 DMA_FROM_DEVICE);
+	} else {
+		dma_sync_single_for_device(vptr->dev, rd_info->skb_dma,
+					   vptr->rx.buf_sz, DMA_FROM_DEVICE);
 	}
 
-	pci_action(vptr->pdev, rd_info->skb_dma, vptr->rx.buf_sz,
-		   PCI_DMA_FROMDEVICE);
-
 	skb_put(skb, pkt_len - 4);
 	skb->protocol = eth_type_trans(skb, vptr->netdev);
 
@@ -2550,7 +2548,8 @@ static netdev_tx_t velocity_xmit(struct sk_buff *skb,
 	 *	add it to the transmit ring.
 	 */
 	tdinfo->skb = skb;
-	tdinfo->skb_dma[0] = pci_map_single(vptr->pdev, skb->data, pktlen, PCI_DMA_TODEVICE);
+	tdinfo->skb_dma[0] = dma_map_single(vptr->dev, skb->data, pktlen,
+								DMA_TO_DEVICE);
 	td_ptr->tdesc0.len = cpu_to_le16(pktlen);
 	td_ptr->td_buf[0].pa_low = cpu_to_le32(tdinfo->skb_dma[0]);
 	td_ptr->td_buf[0].pa_high = 0;
@@ -2560,7 +2559,7 @@ static netdev_tx_t velocity_xmit(struct sk_buff *skb,
 	for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) {
 		const skb_frag_t *frag = &skb_shinfo(skb)->frags[i];
 
-		tdinfo->skb_dma[i + 1] = skb_frag_dma_map(&vptr->pdev->dev,
+		tdinfo->skb_dma[i + 1] = skb_frag_dma_map(vptr->dev,
 							  frag, 0,
 							  skb_frag_size(frag),
 							  DMA_TO_DEVICE);
@@ -2637,6 +2636,7 @@ static void velocity_init_info(struct pci_dev *pdev, struct velocity_info *vptr,
 {
 	memset(vptr, 0, sizeof(struct velocity_info));
 
+	vptr->dev = &pdev->dev;
 	vptr->pdev = pdev;
 	vptr->chip_id = info->chip_id;
 	vptr->tx.numq = info->txqueue;
@@ -2744,7 +2744,6 @@ static int velocity_found1(struct pci_dev *pdev,
 	SET_NETDEV_DEV(dev, &pdev->dev);
 	vptr = netdev_priv(dev);
 
-
 	if (first) {
 		printk(KERN_INFO "%s Ver. %s\n",
 			VELOCITY_FULL_DRV_NAM, VELOCITY_VERSION);
diff --git a/drivers/net/ethernet/via/via-velocity.h b/drivers/net/ethernet/via/via-velocity.h
index ff8d7828..c38bbae 100644
--- a/drivers/net/ethernet/via/via-velocity.h
+++ b/drivers/net/ethernet/via/via-velocity.h
@@ -1434,6 +1434,7 @@ struct velocity_opt {
 #define GET_RD_BY_IDX(vptr, idx)   (vptr->rd_ring[idx])
 
 struct velocity_info {
+	struct device *dev;
 	struct pci_dev *pdev;
 	struct net_device *netdev;
 
-- 
1.7.9.5



From linux at prisktech.co.nz  Tue Apr 30 02:16:58 2013
From: linux at prisktech.co.nz (Tony Prisk)
Date: Tue, 30 Apr 2013 18:16:58 +1200
Subject: [PATCHv4 1/3] net: velocity: Rename vptr->dev to vptr->netdev
In-Reply-To: <1367302620-4620-1-git-send-email-linux@prisktech.co.nz>
References: <1367302620-4620-1-git-send-email-linux@prisktech.co.nz>
Message-ID: <1367302620-4620-2-git-send-email-linux@prisktech.co.nz>

Improve the clarity of the code in preparation for converting the
dma functions to generic versions, which require a struct device *.

This makes it possible to store a 'struct device *dev' in the
velocity_info structure.

Signed-off-by: Tony Prisk <linux at prisktech.co.nz>
---
 drivers/net/ethernet/via/via-velocity.c |   66 +++++++++++++++----------------
 drivers/net/ethernet/via/via-velocity.h |    4 +-
 2 files changed, 35 insertions(+), 35 deletions(-)

diff --git a/drivers/net/ethernet/via/via-velocity.c b/drivers/net/ethernet/via/via-velocity.c
index fb62489..187eef3 100644
--- a/drivers/net/ethernet/via/via-velocity.c
+++ b/drivers/net/ethernet/via/via-velocity.c
@@ -998,9 +998,9 @@ static void velocity_print_link_status(struct velocity_info *vptr)
 {
 
 	if (vptr->mii_status & VELOCITY_LINK_FAIL) {
-		VELOCITY_PRT(MSG_LEVEL_INFO, KERN_NOTICE "%s: failed to detect cable link\n", vptr->dev->name);
+		VELOCITY_PRT(MSG_LEVEL_INFO, KERN_NOTICE "%s: failed to detect cable link\n", vptr->netdev->name);
 	} else if (vptr->options.spd_dpx == SPD_DPX_AUTO) {
-		VELOCITY_PRT(MSG_LEVEL_INFO, KERN_NOTICE "%s: Link auto-negotiation", vptr->dev->name);
+		VELOCITY_PRT(MSG_LEVEL_INFO, KERN_NOTICE "%s: Link auto-negotiation", vptr->netdev->name);
 
 		if (vptr->mii_status & VELOCITY_SPEED_1000)
 			VELOCITY_PRT(MSG_LEVEL_INFO, " speed 1000M bps");
@@ -1014,7 +1014,7 @@ static void velocity_print_link_status(struct velocity_info *vptr)
 		else
 			VELOCITY_PRT(MSG_LEVEL_INFO, " half duplex\n");
 	} else {
-		VELOCITY_PRT(MSG_LEVEL_INFO, KERN_NOTICE "%s: Link forced", vptr->dev->name);
+		VELOCITY_PRT(MSG_LEVEL_INFO, KERN_NOTICE "%s: Link forced", vptr->netdev->name);
 		switch (vptr->options.spd_dpx) {
 		case SPD_DPX_1000_FULL:
 			VELOCITY_PRT(MSG_LEVEL_INFO, " speed 1000M bps full duplex\n");
@@ -1319,7 +1319,7 @@ static void velocity_init_registers(struct velocity_info *vptr,
 	case VELOCITY_INIT_RESET:
 	case VELOCITY_INIT_WOL:
 
-		netif_stop_queue(vptr->dev);
+		netif_stop_queue(vptr->netdev);
 
 		/*
 		 *	Reset RX to prevent RX pointer not on the 4X location
@@ -1332,7 +1332,7 @@ static void velocity_init_registers(struct velocity_info *vptr,
 		if (velocity_set_media_mode(vptr, mii_status) != VELOCITY_LINK_CHANGE) {
 			velocity_print_link_status(vptr);
 			if (!(vptr->mii_status & VELOCITY_LINK_FAIL))
-				netif_wake_queue(vptr->dev);
+				netif_wake_queue(vptr->netdev);
 		}
 
 		enable_flow_control_ability(vptr);
@@ -1354,7 +1354,7 @@ static void velocity_init_registers(struct velocity_info *vptr,
 
 		mac_eeprom_reload(regs);
 		for (i = 0; i < 6; i++)
-			writeb(vptr->dev->dev_addr[i], &(regs->PAR[i]));
+			writeb(vptr->netdev->dev_addr[i], &(regs->PAR[i]));
 
 		/*
 		 *	clear Pre_ACPI bit.
@@ -1377,7 +1377,7 @@ static void velocity_init_registers(struct velocity_info *vptr,
 		/*
 		 *	Set packet filter: Receive directed and broadcast address
 		 */
-		velocity_set_multi(vptr->dev);
+		velocity_set_multi(vptr->netdev);
 
 		/*
 		 *	Enable MII auto-polling
@@ -1404,14 +1404,14 @@ static void velocity_init_registers(struct velocity_info *vptr,
 		writel((CR0_DPOLL | CR0_TXON | CR0_RXON | CR0_STRT), &regs->CR0Set);
 
 		mii_status = velocity_get_opt_media_mode(vptr);
-		netif_stop_queue(vptr->dev);
+		netif_stop_queue(vptr->netdev);
 
 		mii_init(vptr, mii_status);
 
 		if (velocity_set_media_mode(vptr, mii_status) != VELOCITY_LINK_CHANGE) {
 			velocity_print_link_status(vptr);
 			if (!(vptr->mii_status & VELOCITY_LINK_FAIL))
-				netif_wake_queue(vptr->dev);
+				netif_wake_queue(vptr->netdev);
 		}
 
 		enable_flow_control_ability(vptr);
@@ -1474,7 +1474,7 @@ static int velocity_init_dma_rings(struct velocity_info *vptr)
 				    rx_ring_size, &pool_dma);
 	if (!pool) {
 		dev_err(&pdev->dev, "%s : DMA memory allocation failed.\n",
-			vptr->dev->name);
+			vptr->netdev->name);
 		return -ENOMEM;
 	}
 
@@ -1514,7 +1514,7 @@ static int velocity_alloc_rx_buf(struct velocity_info *vptr, int idx)
 	struct rx_desc *rd = &(vptr->rx.ring[idx]);
 	struct velocity_rd_info *rd_info = &(vptr->rx.info[idx]);
 
-	rd_info->skb = netdev_alloc_skb(vptr->dev, vptr->rx.buf_sz + 64);
+	rd_info->skb = netdev_alloc_skb(vptr->netdev, vptr->rx.buf_sz + 64);
 	if (rd_info->skb == NULL)
 		return -ENOMEM;
 
@@ -1620,7 +1620,7 @@ static int velocity_init_rd_ring(struct velocity_info *vptr)
 
 	if (velocity_rx_refill(vptr) != vptr->options.numrx) {
 		VELOCITY_PRT(MSG_LEVEL_ERR, KERN_ERR
-			"%s: failed to allocate RX buffer.\n", vptr->dev->name);
+			"%s: failed to allocate RX buffer.\n", vptr->netdev->name);
 		velocity_free_rd_ring(vptr);
 		goto out;
 	}
@@ -1809,7 +1809,7 @@ static void velocity_error(struct velocity_info *vptr, int status)
 		printk(KERN_ERR "TD structure error TDindex=%hx\n", readw(&regs->TDIdx[0]));
 		BYTE_REG_BITS_ON(TXESR_TDSTR, &regs->TXESR);
 		writew(TRDCSR_RUN, &regs->TDCSRClr);
-		netif_stop_queue(vptr->dev);
+		netif_stop_queue(vptr->netdev);
 
 		/* FIXME: port over the pci_device_failed code and use it
 		   here */
@@ -1850,10 +1850,10 @@ static void velocity_error(struct velocity_info *vptr, int status)
 
 		if (linked) {
 			vptr->mii_status &= ~VELOCITY_LINK_FAIL;
-			netif_carrier_on(vptr->dev);
+			netif_carrier_on(vptr->netdev);
 		} else {
 			vptr->mii_status |= VELOCITY_LINK_FAIL;
-			netif_carrier_off(vptr->dev);
+			netif_carrier_off(vptr->netdev);
 		}
 
 		velocity_print_link_status(vptr);
@@ -1867,9 +1867,9 @@ static void velocity_error(struct velocity_info *vptr, int status)
 		enable_mii_autopoll(regs);
 
 		if (vptr->mii_status & VELOCITY_LINK_FAIL)
-			netif_stop_queue(vptr->dev);
+			netif_stop_queue(vptr->netdev);
 		else
-			netif_wake_queue(vptr->dev);
+			netif_wake_queue(vptr->netdev);
 
 	}
 	if (status & ISR_MIBFI)
@@ -1894,7 +1894,7 @@ static int velocity_tx_srv(struct velocity_info *vptr)
 	int idx;
 	int works = 0;
 	struct velocity_td_info *tdinfo;
-	struct net_device_stats *stats = &vptr->dev->stats;
+	struct net_device_stats *stats = &vptr->netdev->stats;
 
 	for (qnum = 0; qnum < vptr->tx.numq; qnum++) {
 		for (idx = vptr->tx.tail[qnum]; vptr->tx.used[qnum] > 0;
@@ -1939,9 +1939,9 @@ static int velocity_tx_srv(struct velocity_info *vptr)
 	 *	Look to see if we should kick the transmit network
 	 *	layer for more work.
 	 */
-	if (netif_queue_stopped(vptr->dev) && (full == 0) &&
+	if (netif_queue_stopped(vptr->netdev) && (full == 0) &&
 	    (!(vptr->mii_status & VELOCITY_LINK_FAIL))) {
-		netif_wake_queue(vptr->dev);
+		netif_wake_queue(vptr->netdev);
 	}
 	return works;
 }
@@ -1989,7 +1989,7 @@ static int velocity_rx_copy(struct sk_buff **rx_skb, int pkt_size,
 	if (pkt_size < rx_copybreak) {
 		struct sk_buff *new_skb;
 
-		new_skb = netdev_alloc_skb_ip_align(vptr->dev, pkt_size);
+		new_skb = netdev_alloc_skb_ip_align(vptr->netdev, pkt_size);
 		if (new_skb) {
 			new_skb->ip_summed = rx_skb[0]->ip_summed;
 			skb_copy_from_linear_data(*rx_skb, new_skb->data, pkt_size);
@@ -2030,14 +2030,14 @@ static inline void velocity_iph_realign(struct velocity_info *vptr,
 static int velocity_receive_frame(struct velocity_info *vptr, int idx)
 {
 	void (*pci_action)(struct pci_dev *, dma_addr_t, size_t, int);
-	struct net_device_stats *stats = &vptr->dev->stats;
+	struct net_device_stats *stats = &vptr->netdev->stats;
 	struct velocity_rd_info *rd_info = &(vptr->rx.info[idx]);
 	struct rx_desc *rd = &(vptr->rx.ring[idx]);
 	int pkt_len = le16_to_cpu(rd->rdesc0.len) & 0x3fff;
 	struct sk_buff *skb;
 
 	if (rd->rdesc0.RSR & (RSR_STP | RSR_EDP)) {
-		VELOCITY_PRT(MSG_LEVEL_VERBOSE, KERN_ERR " %s : the received frame span multple RDs.\n", vptr->dev->name);
+		VELOCITY_PRT(MSG_LEVEL_VERBOSE, KERN_ERR " %s : the received frame span multple RDs.\n", vptr->netdev->name);
 		stats->rx_length_errors++;
 		return -EINVAL;
 	}
@@ -2075,7 +2075,7 @@ static int velocity_receive_frame(struct velocity_info *vptr, int idx)
 		   PCI_DMA_FROMDEVICE);
 
 	skb_put(skb, pkt_len - 4);
-	skb->protocol = eth_type_trans(skb, vptr->dev);
+	skb->protocol = eth_type_trans(skb, vptr->netdev);
 
 	if (rd->rdesc0.RSR & RSR_DETAG) {
 		u16 vid = swab16(le16_to_cpu(rd->rdesc1.PQTAG));
@@ -2100,7 +2100,7 @@ static int velocity_receive_frame(struct velocity_info *vptr, int idx)
  */
 static int velocity_rx_srv(struct velocity_info *vptr, int budget_left)
 {
-	struct net_device_stats *stats = &vptr->dev->stats;
+	struct net_device_stats *stats = &vptr->netdev->stats;
 	int rd_curr = vptr->rx.curr;
 	int works = 0;
 
@@ -2292,7 +2292,7 @@ static int velocity_change_mtu(struct net_device *dev, int new_mtu)
 
 	if ((new_mtu < VELOCITY_MIN_MTU) || new_mtu > (VELOCITY_MAX_MTU)) {
 		VELOCITY_PRT(MSG_LEVEL_ERR, KERN_NOTICE "%s: Invalid MTU.\n",
-				vptr->dev->name);
+				vptr->netdev->name);
 		ret = -EINVAL;
 		goto out_0;
 	}
@@ -2314,7 +2314,7 @@ static int velocity_change_mtu(struct net_device *dev, int new_mtu)
 			goto out_0;
 		}
 
-		tmp_vptr->dev = dev;
+		tmp_vptr->netdev = dev;
 		tmp_vptr->pdev = vptr->pdev;
 		tmp_vptr->options = vptr->options;
 		tmp_vptr->tx.numq = vptr->tx.numq;
@@ -2692,7 +2692,7 @@ static int velocity_get_pci_info(struct velocity_info *vptr,
  */
 static void velocity_print_info(struct velocity_info *vptr)
 {
-	struct net_device *dev = vptr->dev;
+	struct net_device *dev = vptr->netdev;
 
 	printk(KERN_INFO "%s: %s\n", dev->name, get_chip_name(vptr->chip_id));
 	printk(KERN_INFO "%s: Ethernet Address: %pM\n",
@@ -2755,7 +2755,7 @@ static int velocity_found1(struct pci_dev *pdev,
 
 	velocity_init_info(pdev, vptr, info);
 
-	vptr->dev = dev;
+	vptr->netdev = dev;
 
 	ret = pci_enable_device(pdev);
 	if (ret < 0)
@@ -3010,10 +3010,10 @@ static int velocity_suspend(struct pci_dev *pdev, pm_message_t state)
 	struct velocity_info *vptr = netdev_priv(dev);
 	unsigned long flags;
 
-	if (!netif_running(vptr->dev))
+	if (!netif_running(vptr->netdev))
 		return 0;
 
-	netif_device_detach(vptr->dev);
+	netif_device_detach(vptr->netdev);
 
 	spin_lock_irqsave(&vptr->lock, flags);
 	pci_save_state(pdev);
@@ -3078,7 +3078,7 @@ static int velocity_resume(struct pci_dev *pdev)
 	unsigned long flags;
 	int i;
 
-	if (!netif_running(vptr->dev))
+	if (!netif_running(vptr->netdev))
 		return 0;
 
 	pci_set_power_state(pdev, PCI_D0);
@@ -3101,7 +3101,7 @@ static int velocity_resume(struct pci_dev *pdev)
 
 	mac_enable_int(vptr->mac_regs);
 	spin_unlock_irqrestore(&vptr->lock, flags);
-	netif_device_attach(vptr->dev);
+	netif_device_attach(vptr->netdev);
 
 	return 0;
 }
diff --git a/drivers/net/ethernet/via/via-velocity.h b/drivers/net/ethernet/via/via-velocity.h
index 4cb9f13..ff8d7828 100644
--- a/drivers/net/ethernet/via/via-velocity.h
+++ b/drivers/net/ethernet/via/via-velocity.h
@@ -1435,7 +1435,7 @@ struct velocity_opt {
 
 struct velocity_info {
 	struct pci_dev *pdev;
-	struct net_device *dev;
+	struct net_device *netdev;
 
 	unsigned long active_vlans[BITS_TO_LONGS(VLAN_N_VID)];
 	u8 ip_addr[4];
@@ -1514,7 +1514,7 @@ static inline int velocity_get_ip(struct velocity_info *vptr)
 	int res = -ENOENT;
 
 	rcu_read_lock();
-	in_dev = __in_dev_get_rcu(vptr->dev);
+	in_dev = __in_dev_get_rcu(vptr->netdev);
 	if (in_dev != NULL) {
 		ifa = (struct in_ifaddr *) in_dev->ifa_list;
 		if (ifa != NULL) {
-- 
1.7.9.5



From linux at prisktech.co.nz  Tue Apr 30 02:17:00 2013
From: linux at prisktech.co.nz (Tony Prisk)
Date: Tue, 30 Apr 2013 18:17:00 +1200
Subject: [PATCHv4 3/3] net: velocity: Add platform device support to VIA
 velocity driver
In-Reply-To: <1367302620-4620-1-git-send-email-linux@prisktech.co.nz>
References: <1367302620-4620-1-git-send-email-linux@prisktech.co.nz>
Message-ID: <1367302620-4620-4-git-send-email-linux@prisktech.co.nz>

Add support for the VIA Velocity network driver to be bound to a
OF created platform device.

Signed-off-by: Tony Prisk <linux at prisktech.co.nz>
---
 .../devicetree/bindings/net/via-velocity.txt       |   20 +
 drivers/net/ethernet/via/Kconfig                   |    3 +-
 drivers/net/ethernet/via/via-velocity.c            |  435 +++++++++++++++-----
 drivers/net/ethernet/via/via-velocity.h            |   35 +-
 4 files changed, 380 insertions(+), 113 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/net/via-velocity.txt

diff --git a/Documentation/devicetree/bindings/net/via-velocity.txt b/Documentation/devicetree/bindings/net/via-velocity.txt
new file mode 100644
index 0000000..b3db469
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/via-velocity.txt
@@ -0,0 +1,20 @@
+* VIA Velocity 10/100/1000 Network Controller
+
+Required properties:
+- compatible : Should be "via,velocity-vt6110"
+- reg : Address and length of the io space
+- interrupts : Should contain the controller interrupt line
+
+Optional properties:
+- no-eeprom : PCI network cards use an external EEPROM to store data. Embedded
+	devices quite often set this data in uboot and do not provide an eeprom.
+	Specify this option if you have no external eeprom.
+
+Examples:
+
+eth0 at d8004000 {
+	compatible = "via,velocity-vt6110";
+	reg = <0xd8004000 0x400>;
+	interrupts = <10>;
+	no-eeprom;
+};
diff --git a/drivers/net/ethernet/via/Kconfig b/drivers/net/ethernet/via/Kconfig
index 68a9ba6..6a87097 100644
--- a/drivers/net/ethernet/via/Kconfig
+++ b/drivers/net/ethernet/via/Kconfig
@@ -5,7 +5,6 @@
 config NET_VENDOR_VIA
 	bool "VIA devices"
 	default y
-	depends on PCI
 	---help---
 	  If you have a network (Ethernet) card belonging to this class, say Y
 	  and read the Ethernet-HOWTO, available from
@@ -45,7 +44,7 @@ config VIA_RHINE_MMIO
 
 config VIA_VELOCITY
 	tristate "VIA Velocity support"
-	depends on PCI
+	depends on (PCI || USE_OF)
 	select CRC32
 	select CRC_CCITT
 	select NET_CORE
diff --git a/drivers/net/ethernet/via/via-velocity.c b/drivers/net/ethernet/via/via-velocity.c
index 5996cee..aa0789f 100644
--- a/drivers/net/ethernet/via/via-velocity.c
+++ b/drivers/net/ethernet/via/via-velocity.c
@@ -65,7 +65,11 @@
 #include <linux/if.h>
 #include <linux/uaccess.h>
 #include <linux/proc_fs.h>
+#include <linux/of_address.h>
+#include <linux/of_device.h>
+#include <linux/of_irq.h>
 #include <linux/inetdevice.h>
+#include <linux/platform_device.h>
 #include <linux/reboot.h>
 #include <linux/ethtool.h>
 #include <linux/mii.h>
@@ -84,6 +88,16 @@
 static int velocity_nics;
 static int msglevel = MSG_LEVEL_INFO;
 
+static void velocity_set_power_state(struct velocity_info *vptr, char state)
+{
+	void *addr = vptr->mac_regs;
+
+	if (vptr->bustype == BUS_PCI)
+		pci_set_power_state(vptr->pdev.pcidev, state);
+	else
+		writeb(state, addr + 0x154);
+}
+
 /**
  *	mac_get_cam_mask	-	Read a CAM mask
  *	@regs: register block for this velocity
@@ -362,12 +376,23 @@ static struct velocity_info_tbl chip_info_table[] = {
  *	Describe the PCI device identifiers that we support in this
  *	device driver. Used for hotplug autoloading.
  */
-static DEFINE_PCI_DEVICE_TABLE(velocity_id_table) = {
+
+static DEFINE_PCI_DEVICE_TABLE(velocity_pci_id_table) = {
 	{ PCI_DEVICE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_612X) },
 	{ }
 };
 
-MODULE_DEVICE_TABLE(pci, velocity_id_table);
+MODULE_DEVICE_TABLE(pci, velocity_pci_id_table);
+
+/**
+ *	Describe the OF device identifiers that we support in this
+ *	device driver. Used for devicetree nodes.
+ */
+static struct of_device_id velocity_of_ids[] = {
+	{ .compatible = "via,velocity-vt6110", .data = &chip_info_table[0] },
+	{ /* Sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, velocity_of_ids);
 
 /**
  *	get_chip_name	- 	identifier to name
@@ -386,29 +411,6 @@ static const char *get_chip_name(enum chip_type chip_id)
 }
 
 /**
- *	velocity_remove1	-	device unplug
- *	@pdev: PCI device being removed
- *
- *	Device unload callback. Called on an unplug or on module
- *	unload for each active device that is present. Disconnects
- *	the device from the network layer and frees all the resources
- */
-static void velocity_remove1(struct pci_dev *pdev)
-{
-	struct net_device *dev = pci_get_drvdata(pdev);
-	struct velocity_info *vptr = netdev_priv(dev);
-
-	unregister_netdev(dev);
-	iounmap(vptr->mac_regs);
-	pci_release_regions(pdev);
-	pci_disable_device(pdev);
-	pci_set_drvdata(pdev, NULL);
-	free_netdev(dev);
-
-	velocity_nics--;
-}
-
-/**
  *	velocity_set_int_opt	-	parser for integer options
  *	@opt: pointer to option value
  *	@val: value the user requested (or -1 for default)
@@ -1181,6 +1183,17 @@ static void mii_init(struct velocity_info *vptr, u32 mii_status)
 	u16 BMCR;
 
 	switch (PHYID_GET_PHY_ID(vptr->phy_id)) {
+	case PHYID_ICPLUS_IP101A:
+		MII_REG_BITS_ON((ADVERTISE_PAUSE_ASYM | ADVERTISE_PAUSE_CAP),
+						MII_ADVERTISE, vptr->mac_regs);
+		if (vptr->mii_status & VELOCITY_DUPLEX_FULL)
+			MII_REG_BITS_ON(TCSR_ECHODIS, MII_SREVISION,
+								vptr->mac_regs);
+		else
+			MII_REG_BITS_OFF(TCSR_ECHODIS, MII_SREVISION,
+								vptr->mac_regs);
+		MII_REG_BITS_ON(PLED_LALBE, MII_TPISTATUS, vptr->mac_regs);
+		break;
 	case PHYID_CICADA_CS8201:
 		/*
 		 *	Reset to hardware default
@@ -1353,9 +1366,12 @@ static void velocity_init_registers(struct velocity_info *vptr,
 		velocity_soft_reset(vptr);
 		mdelay(5);
 
-		mac_eeprom_reload(regs);
-		for (i = 0; i < 6; i++)
-			writeb(vptr->netdev->dev_addr[i], &(regs->PAR[i]));
+		if (!vptr->no_eeprom) {
+			mac_eeprom_reload(regs);
+			for (i = 0; i < 6; i++)
+				writeb(vptr->netdev->dev_addr[i],
+							&(regs->PAR[i]));
+		}
 
 		/*
 		 *	clear Pre_ACPI bit.
@@ -2233,15 +2249,15 @@ static int velocity_open(struct net_device *dev)
 		goto out;
 
 	/* Ensure chip is running */
-	pci_set_power_state(vptr->pdev, PCI_D0);
+	velocity_set_power_state(vptr, PCI_D0);
 
 	velocity_init_registers(vptr, VELOCITY_INIT_COLD);
 
-	ret = request_irq(vptr->pdev->irq, velocity_intr, IRQF_SHARED,
+	ret = request_irq(dev->irq, velocity_intr, IRQF_SHARED,
 			  dev->name, dev);
 	if (ret < 0) {
 		/* Power down the chip */
-		pci_set_power_state(vptr->pdev, PCI_D3hot);
+		velocity_set_power_state(vptr, PCI_D3hot);
 		velocity_free_rings(vptr);
 		goto out;
 	}
@@ -2413,7 +2429,7 @@ static int velocity_ioctl(struct net_device *dev, struct ifreq *rq, int cmd)
 	   saving then we need to bring the device back up to talk to it */
 
 	if (!netif_running(dev))
-		pci_set_power_state(vptr->pdev, PCI_D0);
+		velocity_set_power_state(vptr, PCI_D0);
 
 	switch (cmd) {
 	case SIOCGMIIPHY:	/* Get address of MII PHY in use. */
@@ -2426,7 +2442,7 @@ static int velocity_ioctl(struct net_device *dev, struct ifreq *rq, int cmd)
 		ret = -EOPNOTSUPP;
 	}
 	if (!netif_running(dev))
-		pci_set_power_state(vptr->pdev, PCI_D3hot);
+		velocity_set_power_state(vptr, PCI_D3hot);
 
 
 	return ret;
@@ -2492,7 +2508,7 @@ static int velocity_close(struct net_device *dev)
 	if (vptr->flags & VELOCITY_FLAGS_WOL_ENABLED)
 		velocity_get_ip(vptr);
 
-	free_irq(vptr->pdev->irq, dev);
+	free_irq(dev->irq, dev);
 
 	velocity_free_rings(vptr);
 
@@ -2631,13 +2647,18 @@ static const struct net_device_ops velocity_netdev_ops = {
  *	Set up the initial velocity_info struct for the device that has been
  *	discovered.
  */
-static void velocity_init_info(struct pci_dev *pdev, struct velocity_info *vptr,
-			       const struct velocity_info_tbl *info)
+static void velocity_init_info(void *pdev,
+				struct velocity_info *vptr,
+				const struct velocity_info_tbl *info)
 {
-	memset(vptr, 0, sizeof(struct velocity_info));
+	if (vptr->bustype == BUS_PCI) {
+		vptr->pdev.pcidev = pdev;
+		vptr->dev = &vptr->pdev.pcidev->dev;
+	} else {
+		vptr->pdev.platdev = pdev;
+		vptr->dev = &vptr->pdev.platdev->dev;
+	}
 
-	vptr->dev = &pdev->dev;
-	vptr->pdev = pdev;
 	vptr->chip_id = info->chip_id;
 	vptr->tx.numq = info->txqueue;
 	vptr->multicast_limit = MCAM_SIZE;
@@ -2652,10 +2673,9 @@ static void velocity_init_info(struct pci_dev *pdev, struct velocity_info *vptr,
  *	Retrieve the PCI configuration space data that interests us from
  *	the kernel PCI layer
  */
-static int velocity_get_pci_info(struct velocity_info *vptr,
-				 struct pci_dev *pdev)
+static int velocity_get_pci_info(struct velocity_info *vptr)
 {
-	vptr->rev_id = pdev->revision;
+	struct pci_dev *pdev = vptr->pdev.pcidev;
 
 	pci_set_master(pdev);
 
@@ -2678,7 +2698,38 @@ static int velocity_get_pci_info(struct velocity_info *vptr,
 		dev_err(&pdev->dev, "region #1 is too small.\n");
 		return -EINVAL;
 	}
-	vptr->pdev = pdev;
+
+	return 0;
+}
+
+/**
+ *	velocity_get_platform_info - retrieve platform info for device
+ *	@vptr: velocity device
+ *	@pdev: platform device it matches
+ *
+ *	Retrieve the Platform configuration data that interests us
+ */
+static int velocity_get_platform_info(struct velocity_info *vptr)
+{
+	struct platform_device *pdev = vptr->pdev.platdev;
+	int ret;
+	struct resource res;
+
+	if (of_get_property(pdev->dev.of_node, "no-eeprom", NULL))
+		vptr->no_eeprom = 1;
+
+	ret = of_address_to_resource(pdev->dev.of_node, 0, &res);
+	if (ret) {
+		dev_err(&pdev->dev, "unable to find memory address\n");
+		return ret;
+	}
+
+	vptr->memaddr = res.start;
+
+	if (resource_size(&res) < VELOCITY_IO_SIZE) {
+		dev_err(&pdev->dev, "memory region is too small.\n");
+		return -EINVAL;
+	}
 
 	return 0;
 }
@@ -2707,42 +2758,59 @@ static u32 velocity_get_link(struct net_device *dev)
 }
 
 /**
- *	velocity_found1		-	set up discovered velocity card
+ *	velocity_probe - set up discovered velocity device
  *	@pdev: PCI device
  *	@ent: PCI device table entry that matched
+ *	@bustype: bus that device is connected to
  *
  *	Configure a discovered adapter from scratch. Return a negative
  *	errno error code on failure paths.
  */
-static int velocity_found1(struct pci_dev *pdev,
-			   const struct pci_device_id *ent)
+static int velocity_probe(void *pdev,
+			   const struct pci_device_id *ent,
+			   enum velocity_bus_type bustype)
 {
 	static int first = 1;
-	struct net_device *dev;
+	struct pci_dev *pci_dev = NULL;
+	struct platform_device *platform_dev = NULL;
+	struct net_device *netdev;
+	struct device *dev;
+	const struct of_device_id *of_id;
 	int i;
 	const char *drv_string;
-	const struct velocity_info_tbl *info = &chip_info_table[ent->driver_data];
+	const struct velocity_info_tbl *info;
 	struct velocity_info *vptr;
 	struct mac_regs __iomem *regs;
 	int ret = -ENOMEM;
 
+	if (bustype == BUS_PCI) {
+		pci_dev = pdev;
+		dev = &pci_dev->dev;
+		info = &chip_info_table[ent->driver_data];
+	} else {
+		platform_dev = pdev;
+		dev = &platform_dev->dev;
+		of_id = of_match_device(velocity_of_ids, dev);
+		info = of_id->data;
+	}
+
 	/* FIXME: this driver, like almost all other ethernet drivers,
 	 * can support more than MAX_UNITS.
 	 */
 	if (velocity_nics >= MAX_UNITS) {
-		dev_notice(&pdev->dev, "already found %d NICs.\n",
-			   velocity_nics);
+		dev_notice(dev, "already found %d NICs.\n", velocity_nics);
 		return -ENODEV;
 	}
 
-	dev = alloc_etherdev(sizeof(struct velocity_info));
-	if (!dev)
+	netdev = alloc_etherdev(sizeof(struct velocity_info));
+	if (!netdev)
 		goto out;
 
 	/* Chain it all together */
 
-	SET_NETDEV_DEV(dev, &pdev->dev);
-	vptr = netdev_priv(dev);
+	SET_NETDEV_DEV(netdev, dev);
+	vptr = netdev_priv(netdev);
+	memset(vptr, 0, sizeof(struct velocity_info));
 
 	if (first) {
 		printk(KERN_INFO "%s Ver. %s\n",
@@ -2752,24 +2820,37 @@ static int velocity_found1(struct pci_dev *pdev,
 		first = 0;
 	}
 
+	vptr->bustype = bustype;
+	vptr->netdev = netdev;
 	velocity_init_info(pdev, vptr, info);
 
-	vptr->netdev = dev;
+	if (vptr->bustype == BUS_PCI) {
+		ret = pci_enable_device(vptr->pdev.pcidev);
+		if (ret < 0)
+			goto err_free_dev;
 
-	ret = pci_enable_device(pdev);
-	if (ret < 0)
-		goto err_free_dev;
+		netdev->irq = pci_dev->irq;
 
-	ret = velocity_get_pci_info(vptr, pdev);
-	if (ret < 0) {
-		/* error message already printed */
-		goto err_disable;
-	}
+		ret = velocity_get_pci_info(vptr);
+		if (ret < 0)
+			goto err_disable;
 
-	ret = pci_request_regions(pdev, VELOCITY_NAME);
-	if (ret < 0) {
-		dev_err(&pdev->dev, "No PCI resources.\n");
-		goto err_disable;
+		ret = pci_request_regions(pci_dev, VELOCITY_NAME);
+		if (ret < 0) {
+			dev_err(dev, "No PCI resources.\n");
+			goto err_disable;
+		}
+	} else {
+		netdev->irq =
+			irq_of_parse_and_map(platform_dev->dev.of_node, 0);
+		if (!netdev->irq) {
+			ret = -EINVAL;
+			goto err_free_dev;
+		}
+
+		ret = velocity_get_platform_info(vptr);
+		if (ret < 0)
+			goto err_disable;
 	}
 
 	regs = ioremap(vptr->memaddr, VELOCITY_IO_SIZE);
@@ -2780,13 +2861,18 @@ static int velocity_found1(struct pci_dev *pdev,
 
 	vptr->mac_regs = regs;
 
+	if (vptr->bustype == BUS_PCI)
+		vptr->rev_id = pci_dev->revision;
+	else
+		vptr->rev_id = readb(&regs->rev_id);
+
 	mac_wol_reset(regs);
 
 	for (i = 0; i < 6; i++)
-		dev->dev_addr[i] = readb(&regs->PAR[i]);
+		netdev->dev_addr[i] = readb(&regs->PAR[i]);
 
 
-	drv_string = dev_driver_string(&pdev->dev);
+	drv_string = dev_driver_string(dev);
 
 	velocity_get_options(&vptr->options, velocity_nics, drv_string);
 
@@ -2807,30 +2893,35 @@ static int velocity_found1(struct pci_dev *pdev,
 
 	vptr->phy_id = MII_GET_PHY_ID(vptr->mac_regs);
 
-	dev->netdev_ops = &velocity_netdev_ops;
-	dev->ethtool_ops = &velocity_ethtool_ops;
-	netif_napi_add(dev, &vptr->napi, velocity_poll, VELOCITY_NAPI_WEIGHT);
+	netdev->netdev_ops = &velocity_netdev_ops;
+	netdev->ethtool_ops = &velocity_ethtool_ops;
+	netif_napi_add(netdev, &vptr->napi, velocity_poll,
+							VELOCITY_NAPI_WEIGHT);
 
-	dev->hw_features = NETIF_F_IP_CSUM | NETIF_F_SG |
+	netdev->hw_features = NETIF_F_IP_CSUM | NETIF_F_SG |
 			   NETIF_F_HW_VLAN_CTAG_TX;
-	dev->features |= NETIF_F_HW_VLAN_CTAG_TX | NETIF_F_HW_VLAN_CTAG_FILTER |
-			 NETIF_F_HW_VLAN_CTAG_RX | NETIF_F_IP_CSUM;
+	netdev->features |= NETIF_F_HW_VLAN_CTAG_TX |
+			NETIF_F_HW_VLAN_CTAG_FILTER | NETIF_F_HW_VLAN_CTAG_RX |
+			NETIF_F_IP_CSUM;
 
-	ret = register_netdev(dev);
+	ret = register_netdev(netdev);
 	if (ret < 0)
 		goto err_iounmap;
 
-	if (!velocity_get_link(dev)) {
-		netif_carrier_off(dev);
+	if (!velocity_get_link(netdev)) {
+		netif_carrier_off(netdev);
 		vptr->mii_status |= VELOCITY_LINK_FAIL;
 	}
 
 	velocity_print_info(vptr);
-	pci_set_drvdata(pdev, dev);
+	if (vptr->bustype == BUS_PCI)
+		pci_set_drvdata(vptr->pdev.pcidev, netdev);
+	else
+		platform_set_drvdata(vptr->pdev.platdev, netdev);
 
 	/* and leave the chip powered down */
 
-	pci_set_power_state(pdev, PCI_D3hot);
+	velocity_set_power_state(vptr, PCI_D3hot);
 	velocity_nics++;
 out:
 	return ret;
@@ -2838,14 +2929,69 @@ out:
 err_iounmap:
 	iounmap(regs);
 err_release_res:
-	pci_release_regions(pdev);
+	if (vptr->bustype == BUS_PCI)
+		pci_release_regions(vptr->pdev.pcidev);
 err_disable:
-	pci_disable_device(pdev);
+	if (vptr->bustype == BUS_PCI)
+		pci_disable_device(vptr->pdev.pcidev);
 err_free_dev:
-	free_netdev(dev);
+	free_netdev(netdev);
 	goto out;
 }
 
+/**
+ *	velocity_remove	- device unplug
+ *	@pdev: PCI device being removed
+ *	@bustype: bus that device is connected to
+ *
+ *	Device unload callback. Called on an unplug or on module
+ *	unload for each active device that is present. Disconnects
+ *	the device from the network layer and frees all the resources
+ */
+static int velocity_remove(struct net_device *netdev)
+{
+	struct velocity_info *vptr = netdev_priv(netdev);
+
+	unregister_netdev(netdev);
+	iounmap(vptr->mac_regs);
+	free_netdev(netdev);
+	velocity_nics--;
+
+	return 0;
+}
+
+static int velocity_pci_probe(struct pci_dev *pdev,
+			   const struct pci_device_id *ent)
+{
+	return velocity_probe(pdev, ent, BUS_PCI);
+}
+
+static void velocity_pci_remove(struct pci_dev *pdev)
+{
+	struct net_device *netdev = pci_get_drvdata(pdev);
+
+	velocity_remove(netdev);
+
+	pci_release_regions(pdev);
+	pci_disable_device(pdev);
+	pci_set_drvdata(pdev, NULL);
+}
+
+static int velocity_platform_probe(struct platform_device *pdev)
+{
+	return velocity_probe(pdev, NULL, BUS_PLATFORM);
+}
+
+static int velocity_platform_remove(struct platform_device *pdev)
+{
+	struct net_device *netdev = platform_get_drvdata(pdev);
+
+	velocity_remove(netdev);
+	platform_set_drvdata(pdev, NULL);
+
+	return 0;
+}
+
 #ifdef CONFIG_PM
 /**
  *	wol_calc_crc		-	WOL CRC
@@ -3003,11 +3149,20 @@ static void velocity_save_context(struct velocity_info *vptr, struct velocity_co
 
 }
 
-static int velocity_suspend(struct pci_dev *pdev, pm_message_t state)
+static int velocity_suspend(void *pdev, pm_message_t state,
+					enum velocity_bus_type bustype)
 {
-	struct net_device *dev = pci_get_drvdata(pdev);
-	struct velocity_info *vptr = netdev_priv(dev);
+	struct net_device *netdev;
+	struct velocity_info *vptr;
 	unsigned long flags;
+	int pci = (bustype == BUS_PCI) ? 1 : 0;
+
+	if (pci)
+		netdev = pci_get_drvdata(pdev);
+	else
+		netdev = platform_get_drvdata(pdev);
+
+	vptr = netdev_priv(netdev);
 
 	if (!netif_running(vptr->netdev))
 		return 0;
@@ -3015,20 +3170,24 @@ static int velocity_suspend(struct pci_dev *pdev, pm_message_t state)
 	netif_device_detach(vptr->netdev);
 
 	spin_lock_irqsave(&vptr->lock, flags);
-	pci_save_state(pdev);
+	if (pci)
+		pci_save_state(pdev);
 
 	if (vptr->flags & VELOCITY_FLAGS_WOL_ENABLED) {
 		velocity_get_ip(vptr);
 		velocity_save_context(vptr, &vptr->context);
 		velocity_shutdown(vptr);
 		velocity_set_wol(vptr);
-		pci_enable_wake(pdev, PCI_D3hot, 1);
-		pci_set_power_state(pdev, PCI_D3hot);
+		if (pci)
+			pci_enable_wake(pdev, PCI_D3hot, 1);
+		velocity_set_power_state(vptr, PCI_D3hot);
 	} else {
 		velocity_save_context(vptr, &vptr->context);
 		velocity_shutdown(vptr);
-		pci_disable_device(pdev);
-		pci_set_power_state(pdev, pci_choose_state(pdev, state));
+		if (pci)
+			pci_disable_device(pdev);
+		velocity_set_power_state(vptr,
+					 velocity_choose_state(pdev, state));
 	}
 
 	spin_unlock_irqrestore(&vptr->lock, flags);
@@ -3070,19 +3229,30 @@ static void velocity_restore_context(struct velocity_info *vptr, struct velocity
 		writeb(*((u8 *) (context->mac_reg + i)), ptr + i);
 }
 
-static int velocity_resume(struct pci_dev *pdev)
+static int velocity_resume(void *pdev, enum velocity_bus_type bustype)
 {
-	struct net_device *dev = pci_get_drvdata(pdev);
-	struct velocity_info *vptr = netdev_priv(dev);
+	struct net_device *netdev;
+	struct velocity_info *vptr;
 	unsigned long flags;
+	int pci = (bustype == BUS_PCI) ? 1 : 0;
 	int i;
 
+	if (pci)
+		netdev = pci_get_drvdata(pdev);
+	else
+		netdev = platform_get_drvdata(pdev);
+
+	vptr = netdev_priv(netdev);
+
 	if (!netif_running(vptr->netdev))
 		return 0;
 
-	pci_set_power_state(pdev, PCI_D0);
-	pci_enable_wake(pdev, 0, 0);
-	pci_restore_state(pdev);
+	velocity_set_power_state(vptr, PCI_D0);
+
+	if (pci) {
+		pci_enable_wake(pdev, 0, 0);
+		pci_restore_state(pdev);
+	}
 
 	mac_wol_reset(vptr->mac_regs);
 
@@ -3104,23 +3274,58 @@ static int velocity_resume(struct pci_dev *pdev)
 
 	return 0;
 }
-#endif
+
+static int velocity_pci_suspend(struct pci_dev *pdev, pm_message_t state)
+{
+	return velocity_suspend(pdev, state, BUS_PCI);
+}
+
+static int velocity_pci_resume(struct pci_dev *pdev)
+{
+	return velocity_resume(pdev, BUS_PCI);
+}
+
+static int velocity_platform_suspend(struct platform_device *pdev,
+				      pm_message_t state)
+{
+	return velocity_suspend(pdev, state, BUS_PLATFORM);
+}
+
+static int velocity_platform_resume(struct platform_device *pdev)
+{
+	return velocity_resume(pdev, BUS_PLATFORM);
+}
+
+#endif	/* !CONFIG_PM */
 
 /*
  *	Definition for our device driver. The PCI layer interface
  *	uses this to handle all our card discover and plugging
  */
-static struct pci_driver velocity_driver = {
+static struct pci_driver velocity_pci_driver = {
 	.name		= VELOCITY_NAME,
-	.id_table	= velocity_id_table,
-	.probe		= velocity_found1,
-	.remove		= velocity_remove1,
+	.id_table	= velocity_pci_id_table,
+	.probe		= velocity_pci_probe,
+	.remove		= velocity_pci_remove,
 #ifdef CONFIG_PM
-	.suspend	= velocity_suspend,
-	.resume		= velocity_resume,
+	.suspend	= velocity_pci_suspend,
+	.resume		= velocity_pci_resume,
 #endif
 };
 
+static struct platform_driver velocity_platform_driver = {
+	.probe		= velocity_platform_probe,
+	.remove		= velocity_platform_remove,
+#ifdef CONFIG_PM
+	.suspend	= velocity_platform_suspend,
+	.resume		= velocity_platform_resume,
+#endif
+	.driver = {
+		.name = "via-velocity",
+		.owner = THIS_MODULE,
+		.of_match_table = velocity_of_ids,
+	},
+};
 
 /**
  *	velocity_ethtool_up	-	pre hook for ethtool
@@ -3133,7 +3338,7 @@ static int velocity_ethtool_up(struct net_device *dev)
 {
 	struct velocity_info *vptr = netdev_priv(dev);
 	if (!netif_running(dev))
-		pci_set_power_state(vptr->pdev, PCI_D0);
+		velocity_set_power_state(vptr, PCI_D0);
 	return 0;
 }
 
@@ -3148,7 +3353,7 @@ static void velocity_ethtool_down(struct net_device *dev)
 {
 	struct velocity_info *vptr = netdev_priv(dev);
 	if (!netif_running(dev))
-		pci_set_power_state(vptr->pdev, PCI_D3hot);
+		velocity_set_power_state(vptr, PCI_D3hot);
 }
 
 static int velocity_get_settings(struct net_device *dev,
@@ -3270,7 +3475,11 @@ static void velocity_get_drvinfo(struct net_device *dev, struct ethtool_drvinfo
 	struct velocity_info *vptr = netdev_priv(dev);
 	strlcpy(info->driver, VELOCITY_NAME, sizeof(info->driver));
 	strlcpy(info->version, VELOCITY_VERSION, sizeof(info->version));
-	strlcpy(info->bus_info, pci_name(vptr->pdev), sizeof(info->bus_info));
+	if (vptr->bustype == BUS_PCI)
+		strlcpy(info->bus_info, pci_name(vptr->pdev.pcidev),
+						sizeof(info->bus_info));
+	else
+		strlcpy(info->bus_info, "platform", sizeof(info->bus_info));
 }
 
 static void velocity_ethtool_get_wol(struct net_device *dev, struct ethtool_wolinfo *wol)
@@ -3563,9 +3772,15 @@ static int __init velocity_init_module(void)
 	int ret;
 
 	velocity_register_notifier();
-	ret = pci_register_driver(&velocity_driver);
+
+	ret = pci_register_driver(&velocity_pci_driver);
 	if (ret < 0)
 		velocity_unregister_notifier();
+
+	ret = platform_driver_register(&velocity_platform_driver);
+	if (ret < 0)
+		velocity_unregister_notifier();
+
 	return ret;
 }
 
@@ -3580,7 +3795,9 @@ static int __init velocity_init_module(void)
 static void __exit velocity_cleanup_module(void)
 {
 	velocity_unregister_notifier();
-	pci_unregister_driver(&velocity_driver);
+
+	pci_unregister_driver(&velocity_pci_driver);
+	platform_driver_unregister(&velocity_platform_driver);
 }
 
 module_init(velocity_init_module);
diff --git a/drivers/net/ethernet/via/via-velocity.h b/drivers/net/ethernet/via/via-velocity.h
index c38bbae..d5dc4c5 100644
--- a/drivers/net/ethernet/via/via-velocity.h
+++ b/drivers/net/ethernet/via/via-velocity.h
@@ -1265,7 +1265,7 @@ struct velocity_context {
 #define PHYID_VT3216_64BIT  0x000FC600UL
 #define PHYID_MARVELL_1000  0x01410C50UL
 #define PHYID_MARVELL_1000S 0x01410C40UL
-
+#define PHYID_ICPLUS_IP101A 0x02430C54UL
 #define PHYID_REV_ID_MASK   0x0000000FUL
 
 #define PHYID_GET_PHY_ID(i)         ((i) & ~PHYID_REV_ID_MASK)
@@ -1433,10 +1433,41 @@ struct velocity_opt {
 
 #define GET_RD_BY_IDX(vptr, idx)   (vptr->rd_ring[idx])
 
+static inline char velocity_choose_state(struct device *dev,
+					   pm_message_t state)
+
+{
+	switch (state.event) {
+	case PM_EVENT_ON:
+		return PCI_D0;
+	case PM_EVENT_FREEZE:
+	case PM_EVENT_PRETHAW:
+		/* REVISIT both freeze and pre-thaw "should" use D0 */
+	case PM_EVENT_SUSPEND:
+	case PM_EVENT_HIBERNATE:
+		return PCI_D3hot;
+	default:
+		dev_info(dev, "unrecognized suspend event %d\n", state.event);
+		BUG();
+	}
+
+	return PCI_D0;
+}
+
+enum velocity_bus_type {
+	BUS_PCI,
+	BUS_PLATFORM,
+};
+
 struct velocity_info {
+	union {
+		struct pci_dev *pcidev;
+		struct platform_device *platdev;
+	} pdev;
 	struct device *dev;
-	struct pci_dev *pdev;
 	struct net_device *netdev;
+	enum velocity_bus_type bustype;
+	int no_eeprom;
 
 	unsigned long active_vlans[BITS_TO_LONGS(VLAN_N_VID)];
 	u8 ip_addr[4];
-- 
1.7.9.5



From anup.patel at linaro.org  Tue Apr 30 02:32:15 2013
From: anup.patel at linaro.org (Anup Patel)
Date: Tue, 30 Apr 2013 12:02:15 +0530
Subject: [PATCH V3] ARM: KVM: Allow host virt timer irq to be different from
 guest timer virt irq
Message-ID: <1367303535-7982-1-git-send-email-anup.patel@linaro.org>

The arch_timer irq numbers (or PPI numbers) are implementation dependent,
so the host virtual timer irq number can be different from guest virtual
timer irq number.

This patch ensures that host virtual timer irq number is read from DTB and
guest virtual timer irq is determined based on vcpu target type.

Signed-off-by: Anup Patel <anup.patel at linaro.org>
Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar at linaro.org>
---
 arch/arm/include/asm/kvm_arch_timer.h |    4 ++++
 arch/arm/kvm/arch_timer.c             |   29 ++++++++++++++++++++---------
 arch/arm/kvm/reset.c                  |   11 +++++++++++
 3 files changed, 35 insertions(+), 9 deletions(-)

diff --git a/arch/arm/include/asm/kvm_arch_timer.h b/arch/arm/include/asm/kvm_arch_timer.h
index 68cb9e1..eeb2a3f 100644
--- a/arch/arm/include/asm/kvm_arch_timer.h
+++ b/arch/arm/include/asm/kvm_arch_timer.h
@@ -61,6 +61,8 @@ struct arch_timer_cpu {
 #ifdef CONFIG_KVM_ARM_TIMER
 int kvm_timer_hyp_init(void);
 int kvm_timer_init(struct kvm *kvm);
+void kvm_timer_vcpu_reset(struct kvm_vcpu *vcpu, 
+			  const struct kvm_irq_level *irq);
 void kvm_timer_vcpu_init(struct kvm_vcpu *vcpu);
 void kvm_timer_flush_hwstate(struct kvm_vcpu *vcpu);
 void kvm_timer_sync_hwstate(struct kvm_vcpu *vcpu);
@@ -76,6 +78,8 @@ static inline int kvm_timer_init(struct kvm *kvm)
 	return 0;
 }
 
+static inline void kvm_timer_vcpu_reset(struct kvm_vcpu *vcpu, 
+					const struct kvm_irq_level *irq) {}
 static inline void kvm_timer_vcpu_init(struct kvm_vcpu *vcpu) {}
 static inline void kvm_timer_flush_hwstate(struct kvm_vcpu *vcpu) {}
 static inline void kvm_timer_sync_hwstate(struct kvm_vcpu *vcpu) {}
diff --git a/arch/arm/kvm/arch_timer.c b/arch/arm/kvm/arch_timer.c
index 49a7516..5826437 100644
--- a/arch/arm/kvm/arch_timer.c
+++ b/arch/arm/kvm/arch_timer.c
@@ -30,9 +30,7 @@
 
 static struct timecounter *timecounter;
 static struct workqueue_struct *wqueue;
-static struct kvm_irq_level timer_irq = {
-	.level	= 1,
-};
+static unsigned int host_vtimer_irq;
 
 static cycle_t kvm_phys_timer_read(void)
 {
@@ -67,8 +65,8 @@ static void kvm_timer_inject_irq(struct kvm_vcpu *vcpu)
 
 	timer->cntv_ctl |= ARCH_TIMER_CTRL_IT_MASK;
 	kvm_vgic_inject_irq(vcpu->kvm, vcpu->vcpu_id,
-			    vcpu->arch.timer_cpu.irq->irq,
-			    vcpu->arch.timer_cpu.irq->level);
+			    timer->irq->irq,
+			    timer->irq->level);
 }
 
 static irqreturn_t kvm_arch_timer_handler(int irq, void *dev_id)
@@ -156,6 +154,20 @@ void kvm_timer_sync_hwstate(struct kvm_vcpu *vcpu)
 	timer_arm(timer, ns);
 }
 
+void kvm_timer_vcpu_reset(struct kvm_vcpu *vcpu, 
+			  const struct kvm_irq_level *irq)
+{
+	struct arch_timer_cpu *timer = &vcpu->arch.timer_cpu;
+
+	/*
+	 * The vcpu timer irq number cannot be determined in 
+	 * kvm_timer_vcpu_init() because it is called much before
+	 * kvm_vcpu_set_target(). To handle this, we determine
+	 * vcpu timer irq number when the vcpu is reset.
+	 */
+	timer->irq = irq;
+}
+
 void kvm_timer_vcpu_init(struct kvm_vcpu *vcpu)
 {
 	struct arch_timer_cpu *timer = &vcpu->arch.timer_cpu;
@@ -163,12 +175,11 @@ void kvm_timer_vcpu_init(struct kvm_vcpu *vcpu)
 	INIT_WORK(&timer->expired, kvm_timer_inject_irq_work);
 	hrtimer_init(&timer->timer, CLOCK_MONOTONIC, HRTIMER_MODE_ABS);
 	timer->timer.function = kvm_timer_expire;
-	timer->irq = &timer_irq;
 }
 
 static void kvm_timer_init_interrupt(void *info)
 {
-	enable_percpu_irq(timer_irq.irq, 0);
+	enable_percpu_irq(host_vtimer_irq, 0);
 }
 
 
@@ -182,7 +193,7 @@ static int kvm_timer_cpu_notify(struct notifier_block *self,
 		break;
 	case CPU_DYING:
 	case CPU_DYING_FROZEN:
-		disable_percpu_irq(timer_irq.irq);
+		disable_percpu_irq(host_vtimer_irq);
 		break;
 	}
 
@@ -230,7 +241,7 @@ int kvm_timer_hyp_init(void)
 		goto out;
 	}
 
-	timer_irq.irq = ppi;
+	host_vtimer_irq = ppi;
 
 	err = register_cpu_notifier(&kvm_timer_cpu_nb);
 	if (err) {
diff --git a/arch/arm/kvm/reset.c b/arch/arm/kvm/reset.c
index b80256b..0b49ad7 100644
--- a/arch/arm/kvm/reset.c
+++ b/arch/arm/kvm/reset.c
@@ -26,6 +26,7 @@
 #include <asm/cputype.h>
 #include <asm/kvm_arm.h>
 #include <asm/kvm_coproc.h>
+#include <asm/kvm_arch_timer.h>
 
 /******************************************************************************
  * Cortex-A15 Reset Values
@@ -37,6 +38,11 @@ static struct kvm_regs a15_regs_reset = {
 	.usr_regs.ARM_cpsr = SVC_MODE | PSR_A_BIT | PSR_I_BIT | PSR_F_BIT,
 };
 
+static const struct kvm_irq_level a15_vtimer_irq = {
+	.irq = 27,
+	.level = 1,
+};
+
 
 /*******************************************************************************
  * Exported reset function
@@ -52,6 +58,7 @@ static struct kvm_regs a15_regs_reset = {
 int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
 {
 	struct kvm_regs *cpu_reset;
+	const struct kvm_irq_level *cpu_vtimer_irq;
 
 	switch (vcpu->arch.target) {
 	case KVM_ARM_TARGET_CORTEX_A15:
@@ -59,6 +66,7 @@ int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
 			return -EINVAL;
 		cpu_reset = &a15_regs_reset;
 		vcpu->arch.midr = read_cpuid_id();
+		cpu_vtimer_irq = &a15_vtimer_irq;
 		break;
 	default:
 		return -ENODEV;
@@ -70,5 +78,8 @@ int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
 	/* Reset CP15 registers */
 	kvm_reset_coprocs(vcpu);
 
+	/* Reset arch_timer context */
+	kvm_timer_vcpu_reset(vcpu, cpu_vtimer_irq);
+
 	return 0;
 }
-- 
1.7.9.5



From anup.patel at linaro.org  Tue Apr 30 02:34:49 2013
From: anup.patel at linaro.org (Anup Patel)
Date: Tue, 30 Apr 2013 12:04:49 +0530
Subject: [PATCH V3] arm64: KVM: Reset arch_timer upon vcpu reset
Message-ID: <1367303689-8049-1-git-send-email-anup.patel@linaro.org>

Reset the arch_timer on vcpu reset and configure guest virtual timer
irq in the process.

Signed-off-by: Anup Patel <anup.patel at linaro.org>
Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar at linaro.org>
---
 arch/arm64/include/asm/kvm_arch_timer.h |    2 ++
 arch/arm64/kvm/reset.c                  |   11 +++++++++++
 2 files changed, 13 insertions(+)

diff --git a/arch/arm64/include/asm/kvm_arch_timer.h b/arch/arm64/include/asm/kvm_arch_timer.h
index eb02273..0f36603 100644
--- a/arch/arm64/include/asm/kvm_arch_timer.h
+++ b/arch/arm64/include/asm/kvm_arch_timer.h
@@ -50,6 +50,8 @@ struct arch_timer_cpu {
 
 int kvm_timer_hyp_init(void);
 int kvm_timer_init(struct kvm *kvm);
+void kvm_timer_vcpu_reset(struct kvm_vcpu *vcpu, 
+			  const struct kvm_irq_level *irq);
 void kvm_timer_vcpu_init(struct kvm_vcpu *vcpu);
 void kvm_timer_flush_hwstate(struct kvm_vcpu *vcpu);
 void kvm_timer_sync_hwstate(struct kvm_vcpu *vcpu);
diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
index 64e0740..7c9cebc 100644
--- a/arch/arm64/kvm/reset.c
+++ b/arch/arm64/kvm/reset.c
@@ -27,6 +27,7 @@
 #include <asm/ptrace.h>
 #include <asm/kvm_arm.h>
 #include <asm/kvm_coproc.h>
+#include <asm/kvm_arch_timer.h>
 
 /*
  * ARMv8 Reset Values
@@ -40,6 +41,11 @@ static struct kvm_regs default_regs_reset32 = {
 			COMPAT_PSR_I_BIT | COMPAT_PSR_F_BIT),
 };
 
+static const struct kvm_irq_level default_vtimer_irq = {
+	.irq = 27,
+	.level = 1,
+};
+
 static bool cpu_has_32bit_el1(void)
 {
 	u64 pfr0;
@@ -75,6 +81,7 @@ int kvm_arch_dev_ioctl_check_extension(long ext)
 int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
 {
 	struct kvm_regs *cpu_reset;
+	const struct kvm_irq_level *cpu_vtimer_irq;
 
 	switch (vcpu->arch.target) {
 	default:
@@ -86,6 +93,7 @@ int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
 		} else {
 			cpu_reset = &default_regs_reset;
 		}
+		cpu_vtimer_irq = &default_vtimer_irq;
 		break;
 	}
 
@@ -95,5 +103,8 @@ int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
 	/* Reset system registers */
 	kvm_reset_sys_regs(vcpu);
 
+	/* Reset arch_timer context */
+	kvm_timer_vcpu_reset(vcpu, cpu_vtimer_irq);
+
 	return 0;
 }
-- 
1.7.9.5



From tomi.valkeinen at iki.fi  Tue Apr 30 03:27:01 2013
From: tomi.valkeinen at iki.fi (Tomi Valkeinen)
Date: Tue, 30 Apr 2013 10:27:01 +0300
Subject: [PATCH V2] video: implement a simple framebuffer driver
In-Reply-To: <1365043183-28905-1-git-send-email-swarren@wwwdotorg.org>
References: <1365043183-28905-1-git-send-email-swarren@wwwdotorg.org>
Message-ID: <517F7245.2050606@iki.fi>

Hi,

On 04/04/2013 05:39 AM, Stephen Warren wrote:
> A simple frame-buffer describes a raw memory region that may be rendered
> to, with the assumption that the display hardware has already been set
> up to scan out from that buffer.
> 
> This is useful in cases where a bootloader exists and has set up the
> display hardware, but a Linux driver doesn't yet exist for the display
> hardware.

I had an idea related to this driver. There are two requirements that I
believe are (or will be) quite common:

On embedded devices quite often the bootloader initializes the display,
with the purpose of having a valid image on the screen for the whole
boot up process (company logo, or whatever).

With multi-arch kernels, we'll have display drivers for all platforms
and panels compiled with the kernel. If all these are built-in, they
will possibly increase the kernel size quite a bit, so it would be good
to have the display drivers as modules.

Now, if we have the display drivers as modules, the point when the
kernel/userspace can update the screen will be pretty late. Also,
there's no chance to get any early kernel boot messages on the screen.

So how about if we had this kind of simple fb, built-in to the kernel,
used only for the boot time until the proper driver is loaded. A "bootfb".

The bootloader would init the display hardware, the bootfb would give an
early /dev/fb0 for the kernel and userspace, and when the real display
driver is loaded, the bootfb would be unbound and the real driver would
take over.

 Tomi



From tomi.valkeinen at ti.com  Tue Apr 30 03:28:35 2013
From: tomi.valkeinen at ti.com (Tomi Valkeinen)
Date: Tue, 30 Apr 2013 10:28:35 +0300
Subject: [PATCH V2] video: implement a simple framebuffer driver
In-Reply-To: <2863648.BDvrAG5uPk@flatron>
References: <1365043183-28905-1-git-send-email-swarren@wwwdotorg.org>
 <20130408171637.98b5ad1f867bcbda883af68b@linux-foundation.org>
 <2569832.XQDrhUGNaI@avalon> <2863648.BDvrAG5uPk@flatron>
Message-ID: <517F72A3.6010009@ti.com>

On 04/30/2013 12:15 AM, Tomasz Figa wrote:

> Well, there is also at least one legitimate use case for this driver.
> 
> I believe there exist embedded devices on which there is no need to 
> dynamically control the framebuffer. It needs one time initialization, 
> usually in bootloader, and then it is used as is, using constant 
> parameters as long as the system is running.
> 
> I doubt there is a need for any KMS (or any other control) driver for such 
> devices - dumb framebuffer driver would be everything needed in such case.

Isn't there usually the need to power off the hardware when
blanking/suspending?

 Tomi


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130430/651fadab/attachment.sig>

From tomi.valkeinen at ti.com  Tue Apr 30 03:39:43 2013
From: tomi.valkeinen at ti.com (Tomi Valkeinen)
Date: Tue, 30 Apr 2013 10:39:43 +0300
Subject: [PATCH V2] video: implement a simple framebuffer driver
In-Reply-To: <1365043183-28905-1-git-send-email-swarren@wwwdotorg.org>
References: <1365043183-28905-1-git-send-email-swarren@wwwdotorg.org>
Message-ID: <517F753F.5090909@ti.com>

On 04/04/2013 05:39 AM, Stephen Warren wrote:
> A simple frame-buffer describes a raw memory region that may be rendered
> to, with the assumption that the display hardware has already been set
> up to scan out from that buffer.
> 
> This is useful in cases where a bootloader exists and has set up the
> display hardware, but a Linux driver doesn't yet exist for the display
> hardware.
> 
> Signed-off-by: Stephen Warren <swarren at wwwdotorg.org>
> ---
> v2: s/dumb/simple/ throughout. Provide more details on pixel format.
> 
> I ended up going with a separate FB driver:
> * DRM/KMS look much more complex, and don't provide any benefit that I can
>   tell for this simple driver.
> * Creating a separate driver rather than adjusting offb.c to work allows a
>   new clean binding to be defined, and doesn't require removing or ifdefing
>   PPC-isms in offb.c.
> ---
>  .../bindings/video/simple-framebuffer.txt          |   25 +++
>  drivers/video/Kconfig                              |   17 ++
>  drivers/video/Makefile                             |    1 +
>  drivers/video/simplefb.c                           |  234 ++++++++++++++++++++
>  4 files changed, 277 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/video/simple-framebuffer.txt
>  create mode 100644 drivers/video/simplefb.c
> 
> diff --git a/Documentation/devicetree/bindings/video/simple-framebuffer.txt b/Documentation/devicetree/bindings/video/simple-framebuffer.txt
> new file mode 100644
> index 0000000..3ea4605
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/simple-framebuffer.txt
> @@ -0,0 +1,25 @@
> +Simple Framebuffer
> +
> +A simple frame-buffer describes a raw memory region that may be rendered to,
> +with the assumption that the display hardware has already been set up to scan
> +out from that buffer.
> +
> +Required properties:
> +- compatible: "simple-framebuffer"
> +- reg: Should contain the location and size of the framebuffer memory.
> +- width: The width of the framebuffer in pixels.
> +- height: The height of the framebuffer in pixels.
> +- stride: The number of bytes in each line of the framebuffer.
> +- format: The format of the framebuffer surface. Valid values are:
> +  - r5g6b5 (16-bit pixels, d[15:11]=r, d[10:5]=g, d[4:0]=b).
> +
> +Example:
> +
> +	framebuffer {
> +		compatible = "simple-framebuffer";
> +		reg = <0x1d385000 (1600 * 1200 * 2)>;
> +		width = <1600>;
> +		height = <1200>;
> +		stride = <(1600 * 2)>;
> +		format = "r5g6b5";
> +	};

I'm not an expert on DT, but I think the point of DT is to describe the
hardware. This doesn't describe the hardware at all.

 Tomi


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130430/f0ef8507/attachment-0001.sig>

From nicolas.ferre at atmel.com  Tue Apr 30 04:06:07 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Tue, 30 Apr 2013 10:06:07 +0200
Subject: [PATCH v3 5/6] mci: at91: convert to
 dma_request_slave_channel_compat()
In-Reply-To: <1366362683-14496-6-git-send-email-ludovic.desroches@atmel.com>
References: <1366362683-14496-1-git-send-email-ludovic.desroches@atmel.com>
 <1366362683-14496-6-git-send-email-ludovic.desroches@atmel.com>
Message-ID: <517F7B6F.4070907@atmel.com>

On 04/19/2013 11:11 AM, ludovic.desroches at atmel.com :
> From: Ludovic Desroches <ludovic.desroches at atmel.com>
> 
> Use generic DMA DT helper. Platforms booting with or without DT populated are
> both supported.
> 
> Signed-off-by: Ludovic Desroches <ludovic.desroches at atmel.com>
> Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
> Acked-by: Nicolas Ferre <nicolas.ferre at atmel.com>

Hi Chris,

As you were not in copy of the patch, I send you a little reminder for
it. It is part of a series by Ludovic and is adding the generic slave
DMA request channel function, as we now have the support for DMA bindings.

Here is the only patch of the series that should go through your tree.
Other maintainers and ourselves have taken the other patches (no strong
synchronization needed between them).

Here is the Linux arm kernel patchwork reference:
https://patchwork.kernel.org/patch/2463641/

But for sure, Ludovic or myself can send it again to you if you need.

Thanks, best regards,

> ---
>  drivers/mmc/host/atmel-mci.c | 25 ++++++++++++-------------
>  1 file changed, 12 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/mmc/host/atmel-mci.c b/drivers/mmc/host/atmel-mci.c
> index 10f8b73..ffbd0d3 100644
> --- a/drivers/mmc/host/atmel-mci.c
> +++ b/drivers/mmc/host/atmel-mci.c
> @@ -2224,10 +2224,15 @@ static void __exit atmci_cleanup_slot(struct atmel_mci_slot *slot,
>  	mmc_free_host(slot->mmc);
>  }
>  
> -static bool atmci_filter(struct dma_chan *chan, void *slave)
> +static bool atmci_filter(struct dma_chan *chan, void *pdata)
>  {
> -	struct mci_dma_data	*sl = slave;
> +	struct mci_platform_data *sl_pdata = pdata;
> +	struct mci_dma_data *sl;
>  
> +	if (!sl_pdata)
> +		return false;
> +
> +	sl = sl_pdata->dma_slave;
>  	if (sl && find_slave_dev(sl) == chan->device->dev) {
>  		chan->private = slave_data_ptr(sl);
>  		return true;
> @@ -2239,24 +2244,18 @@ static bool atmci_filter(struct dma_chan *chan, void *slave)
>  static bool atmci_configure_dma(struct atmel_mci *host)
>  {
>  	struct mci_platform_data	*pdata;
> +	dma_cap_mask_t mask;
>  
>  	if (host == NULL)
>  		return false;
>  
>  	pdata = host->pdev->dev.platform_data;
>  
> -	if (!pdata)
> -		return false;
> +	dma_cap_zero(mask);
> +	dma_cap_set(DMA_SLAVE, mask);
>  
> -	if (pdata->dma_slave && find_slave_dev(pdata->dma_slave)) {
> -		dma_cap_mask_t mask;
> -
> -		/* Try to grab a DMA channel */
> -		dma_cap_zero(mask);
> -		dma_cap_set(DMA_SLAVE, mask);
> -		host->dma.chan =
> -			dma_request_channel(mask, atmci_filter, pdata->dma_slave);
> -	}
> +	host->dma.chan = dma_request_slave_channel_compat(mask, atmci_filter, pdata,
> +							  &host->pdev->dev, "rxtx");
>  	if (!host->dma.chan) {
>  		dev_warn(&host->pdev->dev, "no DMA channel available\n");
>  		return false;
> 


-- 
Nicolas Ferre


From tom.leiming at gmail.com  Tue Apr 30 04:16:16 2013
From: tom.leiming at gmail.com (Ming Lei)
Date: Tue, 30 Apr 2013 16:16:16 +0800
Subject: [Question] flush_dcache_page() need to flush icache?
Message-ID: <CACVXFVMz3jLEPDYFM-_S_t5TiqikVSRiKf9cBNocH3QhVexwZg@mail.gmail.com>

Hi,

Looks flush_dcache_page() need to deal with both dcache alias and I/D
cache coherency, but set_pte_at() has already run __sync_icache_dcache()
to make I/D cache coherency in the path of executable page fault.

So could the flushing icache be removed in flush_dcache_page()?

If it is yes for the above question, could the flushing dcache in case of
vipt nonaliasing be removed in flush_dcache_page() too?

Maybe they are stupid questions, sorry in advance.

Thanks,
-- 
Ming Lei


From linux at arm.linux.org.uk  Tue Apr 30 04:17:39 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Tue, 30 Apr 2013 09:17:39 +0100
Subject: Latest build results - errors/warnings - lots of them
Message-ID: <20130430081739.GP14496@n2100.arm.linux.org.uk>

Latest nightly build of 3.9+my for-next+arm-soc's for-next results in a
great load of new warnings and errors.  arch/arm/common/mcpm_head.S,
arch/arm/common/mcpm_platsmp.c, arch/arm/common/vlock.S are the biggest
source of errors.

OMAP stuff needs a serious look at too - much Kconfig madness there
caused by over-use of select, which then goes on to cause build errors
because it assumes some stuff is always enabled.

There's also warnings about of_device_id from include/linux/of_platform.h
via from arch/arm/kernel/setup.c which feature in all the non-OF builds
too which need addressing.

See todays http://www.arm.linux.org.uk/developer/build/ results for all
the details and configs.  Not pushing my tree until some of this stuff
gets fixed.


From m.szyprowski at samsung.com  Tue Apr 30 04:53:55 2013
From: m.szyprowski at samsung.com (Marek Szyprowski)
Date: Tue, 30 Apr 2013 10:53:55 +0200
Subject: [RFC/PATCH v2 2/2] drivers: dma-contiguous: add initialization
 from device tree
In-Reply-To: <CAO1A-8DiZoMVGcjOqK6VYP5Qito55i=gsKApQM=LGbQVx3iCwg@mail.gmail.com>
References: <1365679330-2514-1-git-send-email-m.szyprowski@samsung.com>
 <1365679330-2514-3-git-send-email-m.szyprowski@samsung.com>
 <CAO1A-8DiZoMVGcjOqK6VYP5Qito55i=gsKApQM=LGbQVx3iCwg@mail.gmail.com>
Message-ID: <517F86A3.6040104@samsung.com>

Hello,

On 4/29/2013 11:21 PM, Marc C wrote:
> >  /**
> >   * dma_contiguous_reserve() - reserve area(s) for contiguous memory handling
> >   * @limit: End address of the reserved memory (optional, 0 for any).
> > @@ -149,6 +200,10 @@ void __init dma_contiguous_reserve(phys_addr_t limit)
> >
> >         pr_debug("%s(limit %08lx)\n", __func__, (unsigned long)limit);
> >
> > +#ifdef CONFIG_OF
> > +       of_scan_flat_dt(cma_fdt_scan, NULL);
> > +#endif
> > +
>
> What is your expectation with the contention between default region
> setup via the kernel config (CONFIG_CMA_SIZE_SEL_*) and via the DT?
> Could the call to 'of_scan_flat_dt()' be done before the setup of the
> kernel config early regions, followed by a return code check
> 'fail-over' scheme, or were you intending for the default region
> setups to be mutually-exclusive?

In the proposed patch the default/global cma region setup from device tree
had higher priority than kernel command line parameter and .config saved 
values,
but now as I think of this, it looks that it would make more sense to 
have the
following priority for setting up the default cma region:

1. kernel cmd line - if not available, then use:
2. device tree - if not available, then use:
3. kernel compiled .config

I will update this in the next version of the CMA DT patches.

Best regards
-- 
Marek Szyprowski
Samsung Poland R&D Center




From catalin.marinas at arm.com  Tue Apr 30 05:05:02 2013
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Tue, 30 Apr 2013 10:05:02 +0100
Subject: [Question] flush_dcache_page() need to flush icache?
In-Reply-To: <CACVXFVMz3jLEPDYFM-_S_t5TiqikVSRiKf9cBNocH3QhVexwZg@mail.gmail.com>
References: <CACVXFVMz3jLEPDYFM-_S_t5TiqikVSRiKf9cBNocH3QhVexwZg@mail.gmail.com>
Message-ID: <20130430090502.GC29766@arm.com>

On Tue, Apr 30, 2013 at 09:16:16AM +0100, Ming Lei wrote:
> Looks flush_dcache_page() need to deal with both dcache alias and I/D
> cache coherency, but set_pte_at() has already run __sync_icache_dcache()
> to make I/D cache coherency in the path of executable page fault.
> 
> So could the flushing icache be removed in flush_dcache_page()?

That's the case for (mapping && mapping_mapped(mapping)) where the
kernel modifies a page cache page which is already mapped in user space
and we won't get a subsequent set_pte_at() call.

-- 
Catalin


From chander.kashyap at linaro.org  Tue Apr 30 05:16:55 2013
From: chander.kashyap at linaro.org (Chander Kashyap)
Date: Tue, 30 Apr 2013 14:46:55 +0530
Subject: [V4 patch 02/15] ARM: ux500: cpuidle: replace for_each_online_cpu
 by for_each_possible_cpu
In-Reply-To: <1366707285-12179-3-git-send-email-daniel.lezcano@linaro.org>
References: <1366707285-12179-1-git-send-email-daniel.lezcano@linaro.org>
 <1366707285-12179-3-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <CANuQgHF9x2g=nybwEKMwihd0M9ps9rOaGw_zJM6a46m5-GKT0w@mail.gmail.com>

On 23 April 2013 14:24, Daniel Lezcano <daniel.lezcano at linaro.org> wrote:
> All the drivers are using, in their initialization function, the
> for_each_possible_cpu macro.
>
> Using for_each_online_cpu means the driver must handle the initialization
> of the cpuidle device when a cpu is up which is not the case here.
>
> Change the macro to for_each_possible_cpu as that fix the hotplug
> initialization and make the initialization routine consistent with the
> rest of the code in the different drivers.
>
> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
> Acked-by: Linus Walleij <linus.walleij at linaro.org>
> ---
>  arch/arm/mach-ux500/cpuidle.c |    4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-ux500/cpuidle.c b/arch/arm/mach-ux500/cpuidle.c
> index c29c1bf..5657d4a 100644
> --- a/arch/arm/mach-ux500/cpuidle.c
> +++ b/arch/arm/mach-ux500/cpuidle.c
> @@ -125,7 +125,7 @@ int __init ux500_idle_init(void)
>                 return ret;
>         }
>
> -       for_each_online_cpu(cpu) {
> +       for_each_possible(cpu) {

for_each_possible(cpu) or for_each_possible_cpu(cpu) ?
>                 device = &per_cpu(ux500_cpuidle_device, cpu);
>                 device->cpu = cpu;
>                 ret = cpuidle_register_device(device);
> @@ -139,7 +139,7 @@ out:
>         return ret;
>
>  out_unregister:
> -       for_each_online_cpu(cpu) {
> +       for_each_possible_cpu(cpu) {
>                 device = &per_cpu(ux500_cpuidle_device, cpu);
>                 cpuidle_unregister_device(device);
>         }
> --
> 1.7.9.5
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel



--
with warm regards,
Chander Kashyap


From vinod.koul at intel.com  Tue Apr 30 04:48:25 2013
From: vinod.koul at intel.com (Vinod Koul)
Date: Tue, 30 Apr 2013 14:18:25 +0530
Subject: [PATCH v3 1/6] at_hdmac: move to generic DMA binding
In-Reply-To: <51750F68.4040701@atmel.com>
References: <1366362683-14496-1-git-send-email-ludovic.desroches@atmel.com>
 <1366362683-14496-2-git-send-email-ludovic.desroches@atmel.com>
 <51750F68.4040701@atmel.com>
Message-ID: <20130430084825.GA1960@intel.com>

On Mon, Apr 22, 2013 at 12:22:32PM +0200, Nicolas Ferre wrote:
> On 04/19/2013 11:11 AM, ludovic.desroches at atmel.com :
> > From: Ludovic Desroches <ludovic.desroches at atmel.com>
> > 
> > Update at_hdmac driver to support generic DMA device tree binding. Devices
> > can still request channel with dma_request_channel() then it doesn't break
> > DMA for non DT boards.
> > 
> > Signed-off-by: Ludovic Desroches <ludovic.desroches at atmel.com>
> > Acked-by: Nicolas Ferre <nicolas.ferre at atmel.com>
> > Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
> > Acked-by: Arnd Bergmann <arnd at arndb.de>
Applied now thanks

--
~Vinod


From nicolas.ferre at atmel.com  Tue Apr 30 05:33:40 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Tue, 30 Apr 2013 11:33:40 +0200
Subject: linux-next build error (at91) - use of bool in mach/arch.h
Message-ID: <517F8FF4.3050901@atmel.com>

Hi,

Today I discovered an issue while building linux-next for at91:

  CC      arch/arm/mach-at91/at91sam9260_devices.o
In file included from /home/nferre/dev/lnx_buid_test/arch/arm/mach-at91/at91sam9260_devices.c:12:0:
/home/nferre/dev/lnx_buid_test/arch/arm/include/asm/mach/arch.h:46:2: error: expected specifier-qualifier-list before ?bool?

It also applies to all non-DT at91 platforms (~ 6 machines).

It seems to be caused by inclusion of commmit
4dbfa9a25367cfa91aec0e56d75a6905d3242cd3 (ARM: Enable selection of 
SMP operations at boot time) and its use of the "bool" type.

In fact, we include asm/mach/arch.h file in our at91xxx_devices.c files and
we include it as the first include directive.

So, I am wondering if the best correction is to add the types.h header file
in the asm/mach/arch.h file, like this:

--- a/arch/arm/include/asm/mach/arch.h
+++ b/arch/arm/include/asm/mach/arch.h
@@ -8,6 +8,8 @@
  * published by the Free Software Foundation.
  */
 
+#include <linux/types.h>
+
 #ifndef __ASSEMBLY__
 
 struct tag;

or if a better option would be to re-arrange the include directives in
various at91xxx_devices.c files?

Thanks, bye,
-- 
Nicolas Ferre


From geert at linux-m68k.org  Tue Apr 30 05:39:05 2013
From: geert at linux-m68k.org (Geert Uytterhoeven)
Date: Tue, 30 Apr 2013 11:39:05 +0200
Subject: linux-next build error (at91) - use of bool in mach/arch.h
In-Reply-To: <517F8FF4.3050901@atmel.com>
References: <517F8FF4.3050901@atmel.com>
Message-ID: <CAMuHMdXYaDHYq7CG8ftP+yyF18pMx8qZrvM3AUTAXk+tUruNcA@mail.gmail.com>

On Tue, Apr 30, 2013 at 11:33 AM, Nicolas Ferre <nicolas.ferre at atmel.com> wrote:
> So, I am wondering if the best correction is to add the types.h header file
> in the asm/mach/arch.h file, like this:
>
> --- a/arch/arm/include/asm/mach/arch.h
> +++ b/arch/arm/include/asm/mach/arch.h
> @@ -8,6 +8,8 @@
>   * published by the Free Software Foundation.
>   */
>
> +#include <linux/types.h>
> +
>  #ifndef __ASSEMBLY__
>
>  struct tag;
>
> or if a better option would be to re-arrange the include directives in
> various at91xxx_devices.c files?

Include files should be self-contained, so asm/mach/arch.h is the right place.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds


From maxime.ripard at free-electrons.com  Tue Apr 30 05:45:33 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue, 30 Apr 2013 11:45:33 +0200
Subject: [PATCH] ARM: sunxi: Fix Mini X-plus device tree build
Message-ID: <1367315134-20977-1-git-send-email-maxime.ripard@free-electrons.com>

Commit b00adbe0 ("ARM: sunxi: Rename uart nodes to serial") changed the
node names in the DTSI, changes that were not accordingly made to the
Mini X-Plus device tree. This breakage slipped through because it was
not properly declared in the Makefile.

Fix both issues.

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 This is 3.10-rc* material.

 arch/arm/boot/dts/Makefile                 | 4 +++-
 arch/arm/boot/dts/sun4i-a10-mini-xplus.dts | 4 ++--
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 9c62558..6d774d0 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -147,7 +147,9 @@ dtb-$(CONFIG_ARCH_SPEAR3XX)+= spear300-evb.dtb \
 	spear320-evb.dtb \
 	spear320-hmi.dtb
 dtb-$(CONFIG_ARCH_SPEAR6XX)+= spear600-evb.dtb
-dtb-$(CONFIG_ARCH_SUNXI) += sun4i-a10-cubieboard.dtb \
+dtb-$(CONFIG_ARCH_SUNXI) += \
+	sun4i-a10-cubieboard.dtb \
+	sun4i-a10-mini-xplus.dtb \
 	sun4i-a10-hackberry.dtb \
 	sun5i-a13-olinuxino.dtb
 dtb-$(CONFIG_ARCH_TEGRA) += tegra20-harmony.dtb \
diff --git a/arch/arm/boot/dts/sun4i-a10-mini-xplus.dts b/arch/arm/boot/dts/sun4i-a10-mini-xplus.dts
index 4a7c35d..078ed7f 100644
--- a/arch/arm/boot/dts/sun4i-a10-mini-xplus.dts
+++ b/arch/arm/boot/dts/sun4i-a10-mini-xplus.dts
@@ -22,8 +22,8 @@
 		bootargs = "earlyprintk console=ttyS0,115200";
 	};
 
-	soc {
-		uart0: uart at 01c28000 {
+	soc at 01c20000 {
+		uart0: serial at 01c28000 {
 			pinctrl-names = "default";
 			pinctrl-0 = <&uart0_pins_a>;
 			status = "okay";
-- 
1.8.1.2



From laurent.pinchart at ideasonboard.com  Tue Apr 30 05:50:38 2013
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Tue, 30 Apr 2013 11:50:38 +0200
Subject: [PATCH V2] video: implement a simple framebuffer driver
In-Reply-To: <CAOesGMiCvBwck0Z6Nyo9zW=1=J=wjhJW68qNGMrN_8iim=8Srg@mail.gmail.com>
References: <1365043183-28905-1-git-send-email-swarren@wwwdotorg.org>
 <2040099.REU8D4ds1g@avalon>
 <CAOesGMiCvBwck0Z6Nyo9zW=1=J=wjhJW68qNGMrN_8iim=8Srg@mail.gmail.com>
Message-ID: <2567859.E04yremImW@avalon>

Hi Olof,

On Monday 29 April 2013 15:40:44 Olof Johansson wrote:
> On Mon, Apr 29, 2013 at 3:23 PM, Laurent Pinchart wrote:
> > On Tuesday 30 April 2013 00:04:20 Arnd Bergmann wrote:
> >> On Monday 29 April 2013, Laurent Pinchart wrote:
> >> > On Monday 29 April 2013 23:31:30 Tomasz Figa wrote:
> >> > > Good point. Stephen, would it be a problem to make this a KMS driver
> >> > > instead? Old fbdev API could be emulated on top of it, until it goes
> >> > > out of use, couldn't it?
> >> > 
> >> > There's already an fbdev emulation layer in KMS, for such a simple use
> >> > case it will work fine.
> >> 
> >> I suggested the same to Stephen when he first brought up this driver.
> >> Unfortunately his attempt to create a simple KMS driver resulted in a
> >> significantly larger driver than the one he did for the framebuffer
> >> interface. This means that either Stephen did something really wrong in
> >> his attempt, or the KMS interface isn't as good as it should be if we
> >> want to move people away from frame buffer drivers.
> > 
> > Implementing a KMS driver requires a fair amount of code. The DRM/KMS
> > subsystem provides helpers that significantly reduce the driver size.
> > Those helpers have been designed around common use cases found in existing
> > KMS drivers.
> > 
> > I'm pretty sure we will be able to add useful helpers for existing fbdev
> > drivers that will make porting them to KMS pretty easy, but that first
> > requires starting to port drivers to find out what common code could be
> > factored out.
> 
> Meanwhile this tiny driver will allow us to use hardware that can't
> otherwise be used (because the proper graphics drivers for said hardware is
> _also_ stuck behind large reworks, i.e. common display framework, which has
> uncertain progress at this time).

Point taken :-)

> As Stephen mentioned in the original patch, this particular driver is very
> useful for Raspberry Pi. But it is also the best way forward (right now) for
> getting basic upstream usability out of the Samsung ARM-based Chromebook. As
> a matter of fact, as of this weekend linux-next boots on that platform with
> keyboard, trackpad, framebuffer and USB2.0 without a single out-of-tree
> patch. Getting the same functionality out of 3.10 would be very desirable.
> 
> So, I clearly understand the desire to move over to a more modern framework.
> At the same time, there's definite value in merging this small driver while
> that's happening. Holding useful code hostage isn't always very productive.

I want to be clear about this, even though I believe we should put as much 
effort as possible behind KMS drivers, I won't nack this patch. It has real 
use cases and is useful, I'm just concerned it will get abused (but it's far 
from being the only piece of code that could be subject to abuse).

-- 
Regards,

Laurent Pinchart



From maxime.ripard at free-electrons.com  Tue Apr 30 05:56:21 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue, 30 Apr 2013 11:56:21 +0200
Subject: [PATCH 0/2] ARM: sunxi: Clock fixes for the Allwinner A13
Message-ID: <1367315783-21345-1-git-send-email-maxime.ripard@free-electrons.com>

Hi,

This is a patchset making the current clock code fit for the A13.
The A13 has less clock gates available, while the logic remains, so
we need to make very few changes to handle the A13.

Thanks,
Maxime 

Maxime Ripard (2):
  clk: sun5i: Add compatibles for Allwinner A13
  ARM: sun5i: Update the clock compatible strings

 Documentation/devicetree/bindings/clock/sunxi.txt  | 117 +++------------------
 .../bindings/clock/sunxi/sun4i-a10-gates.txt       |  93 ++++++++++++++++
 .../bindings/clock/sunxi/sun5i-a13-gates.txt       |  58 ++++++++++
 arch/arm/boot/dts/sun5i-a13.dtsi                   |  35 +++---
 drivers/clk/sunxi/clk-sunxi.c                      |  31 ++++--
 5 files changed, 199 insertions(+), 135 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/clock/sunxi/sun4i-a10-gates.txt
 create mode 100644 Documentation/devicetree/bindings/clock/sunxi/sun5i-a13-gates.txt

-- 
1.8.1.2



From maxime.ripard at free-electrons.com  Tue Apr 30 05:56:23 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue, 30 Apr 2013 11:56:23 +0200
Subject: [PATCH 2/2] ARM: sun5i: Update the clock compatible strings
In-Reply-To: <1367315783-21345-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1367315783-21345-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1367315783-21345-3-git-send-email-maxime.ripard@free-electrons.com>

The Allwinner A13 has a smaller clock set than the one found in the A10.
Fix the A13 device tree and documentation to reflect this.

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 arch/arm/boot/dts/sun5i-a13.dtsi | 35 ++++++++++++-----------------------
 1 file changed, 12 insertions(+), 23 deletions(-)

diff --git a/arch/arm/boot/dts/sun5i-a13.dtsi b/arch/arm/boot/dts/sun5i-a13.dtsi
index 31fa38f..8ba65c1 100644
--- a/arch/arm/boot/dts/sun5i-a13.dtsi
+++ b/arch/arm/boot/dts/sun5i-a13.dtsi
@@ -95,20 +95,15 @@
 
 		ahb_gates: ahb_gates at 01c20060 {
 			#clock-cells = <1>;
-			compatible = "allwinner,sun4i-ahb-gates-clk";
+			compatible = "allwinner,sun5i-a13-ahb-gates-clk";
 			reg = <0x01c20060 0x8>;
 			clocks = <&ahb>;
-			clock-output-names = "ahb_usb0", "ahb_ehci0",
-				"ahb_ohci0", "ahb_ehci1", "ahb_ohci1", "ahb_ss",
-				"ahb_dma", "ahb_bist", "ahb_mmc0", "ahb_mmc1",
-				"ahb_mmc2", "ahb_mmc3", "ahb_ms", "ahb_nand",
-				"ahb_sdram", "ahb_ace",	"ahb_emac", "ahb_ts",
-				"ahb_spi0", "ahb_spi1", "ahb_spi2", "ahb_spi3",
-				"ahb_pata", "ahb_sata", "ahb_gps", "ahb_ve",
-				"ahb_tvd", "ahb_tve0", "ahb_tve1", "ahb_lcd0",
-				"ahb_lcd1", "ahb_csi0", "ahb_csi1", "ahb_hdmi",
-				"ahb_de_be0", "ahb_de_be1", "ahb_de_fe0",
-				"ahb_de_fe1", "ahb_mp", "ahb_mali400";
+			clock-output-names = "ahb_usbotg", "ahb_ehci", "ahb_ohci",
+				"ahb_ss", "ahb_dma", "ahb_bist", "ahb_mmc0",
+				"ahb_mmc1", "ahb_mmc2", "ahb_nand", "ahb_sdram",
+				"ahb_spi0", "ahb_spi1", "ahb_spi2", "ahb_stimer",
+				"ahb_ve", "ahb_lcd", "ahb_csi", "ahb_de_be",
+				"ahb_de_fe", "ahb_iep", "ahb_mali400";
 		};
 
 		apb0: apb0 at 01c20054 {
@@ -120,15 +115,13 @@
 
 		apb0_gates: apb0_gates at 01c20068 {
 			#clock-cells = <1>;
-			compatible = "allwinner,sun4i-apb0-gates-clk";
+			compatible = "allwinner,sun5i-a13-apb0-gates-clk";
 			reg = <0x01c20068 0x4>;
 			clocks = <&apb0>;
-			clock-output-names = "apb0_codec", "apb0_spdif",
-				"apb0_ac97", "apb0_iis", "apb0_pio", "apb0_ir0",
-				"apb0_ir1", "apb0_keypad";
+			clock-output-names = "apb0_codec", "apb0_pio", "apb0_ir";
 		};
 
-		/* dummy is pll62 */
+		/* dummy is pll6 */
 		apb1_mux: apb1_mux at 01c20058 {
 			#clock-cells = <0>;
 			compatible = "allwinner,sun4i-apb1-mux-clk";
@@ -145,15 +138,11 @@
 
 		apb1_gates: apb1_gates at 01c2006c {
 			#clock-cells = <1>;
-			compatible = "allwinner,sun4i-apb1-gates-clk";
+			compatible = "allwinner,sun5i-a13-apb1-gates-clk";
 			reg = <0x01c2006c 0x4>;
 			clocks = <&apb1>;
 			clock-output-names = "apb1_i2c0", "apb1_i2c1",
-				"apb1_i2c2", "apb1_can", "apb1_scr",
-				"apb1_ps20", "apb1_ps21", "apb1_uart0",
-				"apb1_uart1", "apb1_uart2", "apb1_uart3",
-				"apb1_uart4", "apb1_uart5", "apb1_uart6",
-				"apb1_uart7";
+				"apb1_i2c2", "apb1_uart1", "apb1_uart3";
 		};
 	};
 
-- 
1.8.1.2



From maxime.ripard at free-electrons.com  Tue Apr 30 05:56:22 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue, 30 Apr 2013 11:56:22 +0200
Subject: [PATCH 1/2] clk: sun5i: Add compatibles for Allwinner A13
In-Reply-To: <1367315783-21345-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1367315783-21345-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1367315783-21345-2-git-send-email-maxime.ripard@free-electrons.com>

The A13 has a lot less clocks than the one found in the Allwinner A10.
Add these stripped down clocks to the clock driver and in the
documentation.

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 Documentation/devicetree/bindings/clock/sunxi.txt  | 117 +++------------------
 .../bindings/clock/sunxi/sun4i-a10-gates.txt       |  93 ++++++++++++++++
 .../bindings/clock/sunxi/sun5i-a13-gates.txt       |  58 ++++++++++
 drivers/clk/sunxi/clk-sunxi.c                      |  31 ++++--
 4 files changed, 187 insertions(+), 112 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/clock/sunxi/sun4i-a10-gates.txt
 create mode 100644 Documentation/devicetree/bindings/clock/sunxi/sun5i-a13-gates.txt

diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt b/Documentation/devicetree/bindings/clock/sunxi.txt
index 729f524..d495521 100644
--- a/Documentation/devicetree/bindings/clock/sunxi.txt
+++ b/Documentation/devicetree/bindings/clock/sunxi.txt
@@ -12,22 +12,30 @@ Required properties:
 	"allwinner,sun4i-axi-clk" - for the AXI clock
 	"allwinner,sun4i-axi-gates-clk" - for the AXI gates
 	"allwinner,sun4i-ahb-clk" - for the AHB clock
-	"allwinner,sun4i-ahb-gates-clk" - for the AHB gates
+	"allwinner,sun4i-ahb-gates-clk" - for the AHB gates on A10
+	"allwinner,sun5i-a13-ahb-gates-clk" - for the AHB gates on A13
 	"allwinner,sun4i-apb0-clk" - for the APB0 clock
-	"allwinner,sun4i-apb0-gates-clk" - for the APB0 gates
+	"allwinner,sun4i-apb0-gates-clk" - for the APB0 gates on A10
+	"allwinner,sun5i-a13-apb0-gates-clk" - for the APB0 gates on A13
 	"allwinner,sun4i-apb1-clk" - for the APB1 clock
 	"allwinner,sun4i-apb1-mux-clk" - for the APB1 clock muxing
-	"allwinner,sun4i-apb1-gates-clk" - for the APB1 gates
+	"allwinner,sun4i-apb1-gates-clk" - for the APB1 gates on A10
+	"allwinner,sun5i-a13-apb1-gates-clk" - for the APB1 gates on A13
 
 Required properties for all clocks:
 - reg : shall be the control register address for the clock.
 - clocks : shall be the input parent clock(s) phandle for the clock
 - #clock-cells : from common clock binding; shall be set to 0 except for
-	"allwinner,sun4i-*-gates-clk" where it shall be set to 1
+	"allwinner,*-gates-clk" where it shall be set to 1
 
-Additionally, "allwinner,sun4i-*-gates-clk" clocks require:
+Additionally, "allwinner,*-gates-clk" clocks require:
 - clock-output-names : the corresponding gate names that the clock controls
 
+Clock consumers should specify the desired clocks they use with a
+"clocks" phandle cell. Consumers that are using a gated clock should
+provide an additional ID in their clock property. The values of this
+ID are documented in sunxi/<soc>-gates.txt.
+
 For example:
 
 osc24M: osc24M at 01c20050 {
@@ -50,102 +58,3 @@ cpu: cpu at 01c20054 {
 	reg = <0x01c20054 0x4>;
 	clocks = <&osc32k>, <&osc24M>, <&pll1>;
 };
-
-
-
-Gate clock outputs
-
-The "allwinner,sun4i-*-gates-clk" clocks provide several gatable outputs;
-their corresponding offsets as present on sun4i are listed below. Note that
-some of these gates are not present on sun5i.
-
-  * AXI gates ("allwinner,sun4i-axi-gates-clk")
-
-    DRAM                                                                0
-
-  * AHB gates ("allwinner,sun4i-ahb-gates-clk")
-
-    USB0                                                                0
-    EHCI0                                                               1
-    OHCI0                                                               2*
-    EHCI1                                                               3
-    OHCI1                                                               4*
-    SS                                                                  5
-    DMA                                                                 6
-    BIST                                                                7
-    MMC0                                                                8
-    MMC1                                                                9
-    MMC2                                                                10
-    MMC3                                                                11
-    MS                                                                  12**
-    NAND                                                                13
-    SDRAM                                                               14
-
-    ACE                                                                 16
-    EMAC                                                                17
-    TS                                                                  18
-
-    SPI0                                                                20
-    SPI1                                                                21
-    SPI2                                                                22
-    SPI3                                                                23
-    PATA                                                                24
-    SATA                                                                25**
-    GPS                                                                 26*
-
-    VE                                                                  32
-    TVD                                                                 33
-    TVE0                                                                34
-    TVE1                                                                35
-    LCD0                                                                36
-    LCD1                                                                37
-
-    CSI0                                                                40
-    CSI1                                                                41
-
-    HDMI                                                                43
-    DE_BE0                                                              44
-    DE_BE1                                                              45
-    DE_FE0                                                              46
-    DE_FE1                                                              47
-
-    MP                                                                  50
-
-    MALI400                                                             52
-
-  * APB0 gates ("allwinner,sun4i-apb0-gates-clk")
-
-    CODEC                                                               0
-    SPDIF                                                               1*
-    AC97                                                                2
-    IIS                                                                 3
-
-    PIO                                                                 5
-    IR0                                                                 6
-    IR1                                                                 7
-
-    KEYPAD                                                              10
-
-  * APB1 gates ("allwinner,sun4i-apb1-gates-clk")
-
-    I2C0                                                                0
-    I2C1                                                                1
-    I2C2                                                                2
-
-    CAN                                                                 4
-    SCR                                                                 5
-    PS20                                                                6
-    PS21                                                                7
-
-    UART0                                                               16
-    UART1                                                               17
-    UART2                                                               18
-    UART3                                                               19
-    UART4                                                               20
-    UART5                                                               21
-    UART6                                                               22
-    UART7                                                               23
-
-Notation:
- [*]:  The datasheet didn't mention these, but they are present on AW code
- [**]: The datasheet had this marked as "NC" but they are used on AW code
diff --git a/Documentation/devicetree/bindings/clock/sunxi/sun4i-a10-gates.txt b/Documentation/devicetree/bindings/clock/sunxi/sun4i-a10-gates.txt
new file mode 100644
index 0000000..6a03475
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/sunxi/sun4i-a10-gates.txt
@@ -0,0 +1,93 @@
+Gate clock outputs
+------------------
+
+  * AXI gates ("allwinner,sun4i-axi-gates-clk")
+
+    DRAM					0
+
+  * AHB gates ("allwinner,sun4i-ahb-gates-clk")
+
+    USB0					0
+    EHCI0					1
+    OHCI0					2*
+    EHCI1					3
+    OHCI1					4*
+    SS						5
+    DMA						6
+    BIST					7
+    MMC0					8
+    MMC1					9
+    MMC2					10
+    MMC3					11
+    MS						12**
+    NAND					13
+    SDRAM					14
+
+    ACE						16
+    EMAC					17
+    TS						18
+
+    SPI0					20
+    SPI1					21
+    SPI2					22
+    SPI3					23
+    PATA					24
+    SATA					25**
+    GPS						26*
+
+    VE						32
+    TVD						33
+    TVE0					34
+    TVE1					35
+    LCD0					36
+    LCD1					37
+
+    CSI0					40
+    CSI1					41
+
+    HDMI					43
+    DE_BE0					44
+    DE_BE1					45
+    DE_FE1					46
+    DE_FE1					47
+
+    MP						50
+
+    MALI400					52
+
+  * APB0 gates ("allwinner,sun4i-apb0-gates-clk")
+
+    CODEC					0
+    SPDIF					1*
+    AC97					2
+    IIS						3
+
+    PIO						5
+    IR0						6
+    IR1						7
+
+    KEYPAD					10
+
+  * APB1 gates ("allwinner,sun4i-apb1-gates-clk")
+
+    I2C0					0
+    I2C1					1
+    I2C2					2
+
+    CAN						4
+    SCR						5
+    PS20					6
+    PS21					7
+
+    UART0					16
+    UART1					17
+    UART2					18
+    UART3					19
+    UART4					20
+    UART5					21
+    UART6					22
+    UART7					23
+
+Notation:
+ [*]:  The datasheet didn't mention these, but they are present on AW code
+ [**]: The datasheet had this marked as "NC" but they are used on AW code
diff --git a/Documentation/devicetree/bindings/clock/sunxi/sun5i-a13-gates.txt b/Documentation/devicetree/bindings/clock/sunxi/sun5i-a13-gates.txt
new file mode 100644
index 0000000..006b6df
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/sunxi/sun5i-a13-gates.txt
@@ -0,0 +1,58 @@
+Gate clock outputs
+------------------
+
+  * AXI gates ("allwinner,sun4i-axi-gates-clk")
+
+    DRAM					0
+
+  * AHB gates ("allwinner,sun5i-a13-ahb-gates-clk")
+
+    USBOTG					0
+    EHCI					1
+    OHCI					2
+
+    SS						5
+    DMA						6
+    BIST					7
+    MMC0					8
+    MMC1					9
+    MMC2					10
+
+    NAND					13
+    SDRAM					14
+
+    SPI0					20
+    SPI1					21
+    SPI2					22
+
+    STIMER					28
+
+    VE						32
+
+    LCD						36
+
+    CSI						40
+
+    DE_BE					44
+
+    DE_FE					46
+
+    IEP						51
+    MALI400					52
+
+  * APB0 gates ("allwinner,sun5i-a13-apb0-gates-clk")
+
+    CODEC					0
+
+    PIO						5
+    IR						6
+
+  * APB1 gates ("allwinner,sun5i-a13-apb1-gates-clk")
+
+    I2C0					0
+    I2C1					1
+    I2C2					2
+
+    UART1					17
+
+    UART3					19
diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
index 8492ad1..930d36f 100644
--- a/drivers/clk/sunxi/clk-sunxi.c
+++ b/drivers/clk/sunxi/clk-sunxi.c
@@ -333,22 +333,34 @@ struct gates_data {
 	DECLARE_BITMAP(mask, SUNXI_GATES_MAX_SIZE);
 };
 
-static const __initconst struct gates_data axi_gates_data = {
+static const __initconst struct gates_data sun4i_axi_gates_data = {
 	.mask = {1},
 };
 
-static const __initconst struct gates_data ahb_gates_data = {
+static const __initconst struct gates_data sun4i_ahb_gates_data = {
 	.mask = {0x7F77FFF, 0x14FB3F},
 };
 
-static const __initconst struct gates_data apb0_gates_data = {
+static const __initconst struct gates_data sun5i_a13_ahb_gates_data = {
+	.mask = {0x107067e7, 0x185111},
+};
+
+static const __initconst struct gates_data sun4i_apb0_gates_data = {
 	.mask = {0x4EF},
 };
 
-static const __initconst struct gates_data apb1_gates_data = {
+static const __initconst struct gates_data sun5i_a13_apb0_gates_data = {
+	.mask = {0x61},
+};
+
+static const __initconst struct gates_data sun4i_apb1_gates_data = {
 	.mask = {0xFF00F7},
 };
 
+static const __initconst struct gates_data sun5i_a13_apb1_gates_data = {
+	.mask = {0xa0007},
+};
+
 static void __init sunxi_gates_clk_setup(struct device_node *node,
 					 struct gates_data *data)
 {
@@ -428,10 +440,13 @@ static const __initconst struct of_device_id clk_mux_match[] = {
 
 /* Matches for gate clocks */
 static const __initconst struct of_device_id clk_gates_match[] = {
-	{.compatible = "allwinner,sun4i-axi-gates-clk", .data = &axi_gates_data,},
-	{.compatible = "allwinner,sun4i-ahb-gates-clk", .data = &ahb_gates_data,},
-	{.compatible = "allwinner,sun4i-apb0-gates-clk", .data = &apb0_gates_data,},
-	{.compatible = "allwinner,sun4i-apb1-gates-clk", .data = &apb1_gates_data,},
+	{.compatible = "allwinner,sun4i-axi-gates-clk", .data = &sun4i_axi_gates_data,},
+	{.compatible = "allwinner,sun4i-ahb-gates-clk", .data = &sun4i_ahb_gates_data,},
+	{.compatible = "allwinner,sun5i-a13-ahb-gates-clk", .data = &sun5i_a13_ahb_gates_data,},
+	{.compatible = "allwinner,sun4i-apb0-gates-clk", .data = &sun4i_apb0_gates_data,},
+	{.compatible = "allwinner,sun5i-a13-apb0-gates-clk", .data = &sun5i_a13_apb0_gates_data,},
+	{.compatible = "allwinner,sun4i-apb1-gates-clk", .data = &sun4i_apb1_gates_data,},
+	{.compatible = "allwinner,sun5i-a13-apb1-gates-clk", .data = &sun5i_a13_apb1_gates_data,},
 	{}
 };
 
-- 
1.8.1.2



From tom.leiming at gmail.com  Tue Apr 30 06:02:36 2013
From: tom.leiming at gmail.com (Ming Lei)
Date: Tue, 30 Apr 2013 18:02:36 +0800
Subject: [Question] flush_dcache_page() need to flush icache?
In-Reply-To: <20130430090502.GC29766@arm.com>
References: <CACVXFVMz3jLEPDYFM-_S_t5TiqikVSRiKf9cBNocH3QhVexwZg@mail.gmail.com>
 <20130430090502.GC29766@arm.com>
Message-ID: <CACVXFVPz-rMiPyW2EE==v58LF6uTD1M1fKTNcF5a5+Z6-5u+Gg@mail.gmail.com>

On Tue, Apr 30, 2013 at 5:05 PM, Catalin Marinas
<catalin.marinas at arm.com> wrote:
> On Tue, Apr 30, 2013 at 09:16:16AM +0100, Ming Lei wrote:
>> Looks flush_dcache_page() need to deal with both dcache alias and I/D
>> cache coherency, but set_pte_at() has already run __sync_icache_dcache()
>> to make I/D cache coherency in the path of executable page fault.
>>
>> So could the flushing icache be removed in flush_dcache_page()?
>
> That's the case for (mapping && mapping_mapped(mapping)) where the
> kernel modifies a page cache page which is already mapped in user space
> and we won't get a subsequent set_pte_at() call.

OK, I got it, so looks it is only needed in self-modifying-code case, but I am
wondering why it is always done for all cases of (mapping &&
mapping_mapped(mapping))......

Thanks,
-- 
Ming Lei


From marc.zyngier at arm.com  Tue Apr 30 06:23:45 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Tue, 30 Apr 2013 11:23:45 +0100
Subject: [PATCH v3 08/32] arm64: KVM: architecture specific MMU backend
In-Reply-To: <20130429173521.GB16544@arm.com>
References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com>
 <1365437854-30214-9-git-send-email-marc.zyngier@arm.com>
 <20130429173521.GB16544@arm.com>
Message-ID: <517F9BB1.4090906@arm.com>

On 29/04/13 18:35, Catalin Marinas wrote:
> On Mon, Apr 08, 2013 at 05:17:10PM +0100, Marc Zyngier wrote:
>> diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h
>> new file mode 100644
>> index 0000000..2eb2230
>> --- /dev/null
>> +++ b/arch/arm64/include/asm/kvm_mmu.h
> ...
>> +/*
>> + * Align KVM with the kernel's view of physical memory. Should be
>> + * 40bit IPA, with PGD being 8kB aligned.
>> + */
>> +#define KVM_PHYS_SHIFT	PHYS_MASK_SHIFT
> 
> Just wondering - do we allow the IPA to be bigger than what qemu/kvmtool
> can map?
> 
>> +#define KVM_PHYS_SIZE	(1UL << KVM_PHYS_SHIFT)
>> +#define KVM_PHYS_MASK	(KVM_PHYS_SIZE - 1UL)
>> +
>> +#ifdef CONFIG_ARM64_64K_PAGES
>> +#define PAGE_LEVELS	2
>> +#define BITS_PER_LEVEL	13
>> +#else  /* 4kB pages */
>> +#define PAGE_LEVELS	3
>> +#define BITS_PER_LEVEL	9
> 
> You could use (PAGE_SHIFT - 3) for BITS_PER_LEVEL if that's any clearer
> but you can get rid of these entirely (see below).
> 
>> +#endif
>> +
>> +/* Make sure we get the right size, and thus the right alignment */
>> +#define BITS_PER_S2_PGD (KVM_PHYS_SHIFT - (PAGE_LEVELS - 1) * BITS_PER_LEVEL - PAGE_SHIFT)
>> +#define PTRS_PER_S2_PGD (1 << max(BITS_PER_LEVEL, BITS_PER_S2_PGD))
>> +#define S2_PGD_ORDER	get_order(PTRS_PER_S2_PGD * sizeof(pgd_t))
>> +#define S2_PGD_SIZE	(1 << S2_PGD_ORDER)
> 
> It looks like lots of calculations which I can't fully follow ;). So we
> need to map KVM_PHYS_SHIFT (40-bit) with a number of stage 2 pgds. We
> know that a pgd entry can map PGDIR_SHIFT bits. So the pointers you need
> in S2 pgd:
> 
> #define PTRS_PER_S2_PGD		(1 << (KVM_PHYS_SHIFT - PGDIR_SHIFT))
> 
> (no need of PAGE_LEVELS)

Now you're ruining all the fun! ;-) You make it look simple and elegant,
which sucks in a major way!

> With some more juggling you can probably get rid of get_order as well,
> though it should be a compile-time constant. Basically KVM_PHYS_SHIFT -
> PGDIR_SHIFT - PAGE_SHIFT + 3 (and cope with the negative value for the
> 64K pages).

get_order seems to do the right thing, and I'm now almost convinced I
can loose the max. Almost. Hmmm.

>> +static inline void coherent_icache_guest_page(struct kvm *kvm, gfn_t gfn)
>> +{
>> +	unsigned long hva = gfn_to_hva(kvm, gfn);
>> +	flush_icache_range(hva, hva + PAGE_SIZE);
> 
> Even ARMv8 can have aliasing VIPT I-cache. Do we need to flush some more
> here?

Definitely. We should have something similar to what we have for ARMv7.

>> +#define kvm_flush_dcache_to_poc(a,l)	__flush_dcache_area((a), (l))
> 
> I had a brief look at the other hyp reworking patches and this function
> is used in two situations: (1) flush any data before the Hyp is
> initialised and (2) page table creation. The first case looks fine but
> the second is not needed on AArch64 (and SMP AArch32) nor entirely
> optimal as it should flush to PoU for page table walks. Can we have
> different functions, at least we can make one a no-op?

Certainly. I think Will has some patches that we could reuse (at least
in principle) for AArch32, and have a no-op backend for AArch64.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...



From arnd at arndb.de  Tue Apr 30 06:28:42 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 30 Apr 2013 12:28:42 +0200
Subject: [PATCH V2] video: implement a simple framebuffer driver
In-Reply-To: <517F7245.2050606@iki.fi>
References: <1365043183-28905-1-git-send-email-swarren@wwwdotorg.org>
 <517F7245.2050606@iki.fi>
Message-ID: <201304301228.42245.arnd@arndb.de>

On Tuesday 30 April 2013, Tomi Valkeinen wrote:

> The bootloader would init the display hardware, the bootfb would give an
> early /dev/fb0 for the kernel and userspace, and when the real display
> driver is loaded, the bootfb would be unbound and the real driver would
> take over.

I think that's a great idea. What I'm not sure about is how that
infrastructure for switching frame buffers would work and how hard
it's to write.

	Arnd


From arnd at arndb.de  Tue Apr 30 06:34:16 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 30 Apr 2013 12:34:16 +0200
Subject: [PATCH V2] video: implement a simple framebuffer driver
In-Reply-To: <517F753F.5090909@ti.com>
References: <1365043183-28905-1-git-send-email-swarren@wwwdotorg.org>
 <517F753F.5090909@ti.com>
Message-ID: <201304301234.16992.arnd@arndb.de>

On Tuesday 30 April 2013, Tomi Valkeinen wrote:
> > +     framebuffer {
> > +             compatible = "simple-framebuffer";
> > +             reg = <0x1d385000 (1600 * 1200 * 2)>;
> > +             width = <1600>;
> > +             height = <1200>;
> > +             stride = <(1600 * 2)>;
> > +             format = "r5g6b5";
> > +     };
> 
> I'm not an expert on DT, but I think the point of DT is to describe the
> hardware. This doesn't describe the hardware at all.

That's ok.

It's not uncommon to have settings in the device tree that describe how
hardware is set up. Other similar properties would be the line rate
of a serial port, or a keymap describing what each button is labeled.
They are not physical properties, but they are necessary platform specific
pieces of information that are not available otherwise.

	Arnd


From vinod.koul at intel.com  Tue Apr 30 06:08:37 2013
From: vinod.koul at intel.com (Vinod Koul)
Date: Tue, 30 Apr 2013 15:38:37 +0530
Subject: [PATCH 6/9] crypto: ux500/cryp - Set DMA configuration though
 dma_slave_config()
In-Reply-To: <20130426094123.GG14496@n2100.arm.linux.org.uk>
References: <1366280825-31136-1-git-send-email-lee.jones@linaro.org>
 <CACRpkdbFgW6bGYt59WtN4r2izuN09AJw4J1cqir82uzFsuMmWQ@mail.gmail.com>
 <20130425134402.GN4623@gmail.com>
 <201304251611.39667.arnd@arndb.de>
 <CACRpkdaBf++gy3sghC-t33uio2+eHp1MrQ2FM0XXBazZTtm3kA@mail.gmail.com>
 <20130426081646.GD24632@intel.com>
 <20130426094123.GG14496@n2100.arm.linux.org.uk>
Message-ID: <20130430100837.GB1960@intel.com>

On Fri, Apr 26, 2013 at 10:41:23AM +0100, Russell King - ARM Linux wrote:
> On Fri, Apr 26, 2013 at 01:46:46PM +0530, Vinod Koul wrote:
> > On Fri, Apr 26, 2013 at 10:28:39AM +0200, Linus Walleij wrote:
> > > On Thu, Apr 25, 2013 at 4:11 PM, Arnd Bergmann <arnd at arndb.de> wrote:
> > > 
> > > > The dma engine driver must know the address in its dma space, while the
> > > > slave driver has it available in physical space. These two are often the
> > > > same, but there is no generic way to convert between the two, especially
> > > > if the dma engine resides behind an IOMMU.
> > > >
> > > > The best assumption we can make is that the dma engine driver knows
> > > > how to convert between the two. Interestingly the documentation for
> > > > dma_slave_config talks about "physical address", while the structure
> > > > itself uses a dma_addr_t. Linus Walleij introduced the structure in
> > > > c156d0a5b0 "DMAENGINE: generic slave channel control v3", so I assume
> > > > he can shed some light on what he was thinking. I assume the documentation
> > > > is right but the structure is not and should be converted to use
> > > > phys_add_t or resource_size_t.
> > > 
> > > OK I could cook a patch for that, but I think I need some input from
> > > Vinod and/or Russell on this.
> > the dma_slave_config is physical address that should be passed directly to the
> > controller. Obviosuly it should phys_addr_t :)
> 
> What you've just said is actually confusing.
> 
> "physical address" is normally the term used to describe the addresses
> seen to the RAM.  phys_addr_t describes this.  This is not necessarily
> what needs to be programmed into the DMA controller.
Yes that would be true when you have MMU
> 
> For RAM addresses, they must be mapped via the DMA API - and this gives
> you a dma_addr_t.
> 
> "DMA address" is the address to be programmed into a DMA controller to
> access a particular address in RAM or device, and has type dma_addr_t.
> When you're programming a DMA controller to access a device, you are
> clearly telling it the address on the _DMA controller's bus_ to access
> that register, which may or may not be the same as the physical address.
> 
> There are platforms in existence where phys_addr_t can be 32-bit but
> dma_addr_t can be 64-bit.  Getting this stuff wrong can cause problems.
Sure, thanks for pointing, so we wont do this change.

--
~Vinod


From mtosatti at redhat.com  Tue Apr 30 06:29:53 2013
From: mtosatti at redhat.com (Marcelo Tosatti)
Date: Tue, 30 Apr 2013 07:29:53 -0300
Subject: [GIT PULL] KVM/ARM Changes for 3.10
In-Reply-To: <CAEDV+gLbqUgzkRoToYKSBTXKzUkY40fO80rcviu-EHcbxYjL4A@mail.gmail.com>
References: <CAEDV+gKXcCb11p5YCQRbQ1OwGefxYUr0sh8f4AOfxQSPPo2LMQ@mail.gmail.com>
 <20130430021136.GB14088@amt.cnet>
 <CAEDV+gLbqUgzkRoToYKSBTXKzUkY40fO80rcviu-EHcbxYjL4A@mail.gmail.com>
Message-ID: <20130430102953.GA29684@amt.cnet>

On Mon, Apr 29, 2013 at 07:52:41PM -0700, Christoffer Dall wrote:
> On Mon, Apr 29, 2013 at 7:11 PM, Marcelo Tosatti <mtosatti at redhat.com> wrote:
> > On Sun, Apr 28, 2013 at 10:29:07PM -0700, Christoffer Dall wrote:
> >> Hi Marcelo and Gleb,
> >>
> >> These are the changes for KVM/ARM for 3.10.
> >>
> >> The patches depend on the cleanup branch, which you've already merged.
> >>
> >> Main thing is the reworking of Hyp idmaps, which is now handled by KVM
> >> instead of arm/mm and includes several nasty bug fixes from Marc in
> >> the progress.
> >>
> >> Thanks!
> >>
> >> The following changes since commit 5a2892ce72e010e3cb96b438d7cdddce0c88e0e6:
> >>
> >>   KVM: nVMX: Skip PF interception check when queuing during nested run
> >> (2013-04-28 13:34:39 +0300)
> >>
> >> are available in the git repository at:
> >>
> >>   git://github.com/columbia/linux-kvm-arm.git kvm-arm-for-3.10
> >>
> >> for you to fetch changes up to d4e071ce6acf8d5eddb7615a953193a8b0ad7c38:
> >>
> >>   ARM: KVM: iterate over all CPUs for CPU compatibility check
> >> (2013-04-28 22:23:23 -0700)
> >
> > Christoffer,
> >
> > Please email the patches to kvm at vger.
> >
> >
> 
> each of them were already cc'ed on the kvm mailing list when they were
> reviewed I believe, but would you like to have them re-sent as they
> are not in this pull request even if it means re-sending them?
> 
> -Christoffer

Yes please, send the patches along with the pull request.



From arnd at arndb.de  Tue Apr 30 07:04:20 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 30 Apr 2013 13:04:20 +0200
Subject: Latest build results - errors/warnings - lots of them
In-Reply-To: <20130430081739.GP14496@n2100.arm.linux.org.uk>
References: <20130430081739.GP14496@n2100.arm.linux.org.uk>
Message-ID: <201304301304.20650.arnd@arndb.de>

On Tuesday 30 April 2013, Russell King - ARM Linux wrote:
> Latest nightly build of 3.9+my for-next+arm-soc's for-next results in a
> great load of new warnings and errors.  arch/arm/common/mcpm_head.S,
> arch/arm/common/mcpm_platsmp.c, arch/arm/common/vlock.S are the biggest
> source of errors.

Yes, I noticed this but haven't gotten around to prepare a patch. I'll comment
below.

> OMAP stuff needs a serious look at too - much Kconfig madness there
> caused by over-use of select, which then goes on to cause build errors
> because it assumes some stuff is always enabled.

Ack. I have not looked much at randconfig output, but this has certianly
grown worse after CONFIG_ARCH_OMAP has gotten included in ARCH_MULTIPLATFORM

> There's also warnings about of_device_id from include/linux/of_platform.h
> via from arch/arm/kernel/setup.c which feature in all the non-OF builds
> too which need addressing.

Hmm, I did not get that one, but I think that's from arm-soc and I'll
try to fix it up.

>arch/arm/common/mcpm_head.S:39: Error: selected processor does not support ARM mode `ubfx r9,r0,#0,#8'
>arch/arm/common/mcpm_head.S:40: Error: selected processor does not support ARM mode `ubfx r10,r0,#8,#8'
>arch/arm/common/mcpm_head.S:100: Error: selected processor does not support ARM mode `dmb'
>arch/arm/common/mcpm_head.S:115: Error: selected processor does not support ARM mode `dmb'
>arch/arm/common/mcpm_head.S:127: Error: selected processor does not support ARM mode `dmb'
>arch/arm/common/mcpm_head.S:131: Error: selected processor does not support ARM mode `dmb'
>arch/arm/common/mcpm_head.S:138: Error: selected processor does not support ARM mode `dsb'
>arch/arm/common/mcpm_head.S:152: Error: selected processor does not support ARM mode `dmb'
>arch/arm/common/mcpm_head.S:161: Error: selected processor does not support ARM mode `dmb'
>arch/arm/common/mcpm_head.S:175: Error: selected processor does not support ARM mode `dmb'
>arch/arm/common/vlock.S:62: Error: selected processor does not support ARM mode `dmb'
>arch/arm/common/vlock.S:72: Error: selected processor does not support ARM mode `dmb'
>arch/arm/common/vlock.S:72: Error: selected processor does not support ARM mode `dsb'
>arch/arm/common/vlock.S:89: Error: selected processor does not support ARM mode `dmb'
>arch/arm/common/vlock.S:95: Error: selected processor does not support ARM mode `dmb'
>arch/arm/common/vlock.S:95: Error: selected processor does not support ARM mode `dsb'
>arch/arm/common/vlock.S:102: Error: selected processor does not support ARM mode `dmb'
>arch/arm/common/vlock.S:105: Error: selected processor does not support ARM mode `dsb'

Right, the problem here is that the code was never tested with an ARMv6+ARMv7 config.
We can either fix it up by adding

	.arch	armv7-a

in the assembly files, or by doing the same in the Makefile:

AFLAGS_vlock.S += -march=armv7-a
AFLAGS_mcpm_head.S += -march=armv7-a

If you have a preference one way or another I can send you a proper patch,
or you just fix it up in your tree.

>arch/arm/common/mcpm_platsmp.c: In function 'mcpm_secondary_init':
>arch/arm/common/mcpm_platsmp.c:52:2: error: implicit declaration of function 'gic_secondary_init'

This is from a conflict between Nico's patch and Catalin's removal of the
gic_secondary_init function as part of c0114709ed "irqchip: gic: Perform
the gic_secondary_init() call via CPU notifier". I think we can just remove
the call here, but I'm not completely sure if I understand the patch
right.

>arch/arm/mach-imx/hotplug.c: In function 'imx_cpu_die':
>arch/arm/mach-imx/hotplug.c:53:2: error: implicit declaration of function 'cpu_do_idle'
>arch/arm/mach-imx/hotplug.c: In function 'imx_cpu_kill':
>arch/arm/mach-imx/hotplug.c:58:26: error: 'jiffies' undeclared (first use in this function)
>arch/arm/mach-imx/hotplug.c:58:2: error: implicit declaration of function 'msecs_to_jiffies'
>arch/arm/mach-imx/hotplug.c:61:3: error: implicit declaration of function 'time_after'

I've not seen this one before. There are many randconfig problems remaining I fear.

>In file included from arch/arm/include/asm/kvm_host.h:41:0,
>                 from include/linux/kvm_host.h:33,
>                 from kernel/context_tracking.c:18:
>arch/arm/include/asm/kvm_vgic.h:59:11: error: 'CONFIG_KVM_ARM_MAX_VCPUS' undeclared here (not in a function)

I sent a patch last week for this one, and the patch was applied in the
KVM tree.

>drivers/gpu/drm/tilcdc/tilcdc_slave.o:(.data+0x54): multiple definition of `__mod_of_device_table'
>drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54): first defined here
>drivers/gpu/drm/tilcdc/tilcdc_panel.o:(.data+0x54): multiple definition of `__mod_of_device_table'
>drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54): first defined here
>drivers/gpu/drm/tilcdc/tilcdc_drv.o:(.data+0x184): multiple definition of `__mod_of_device_table'
>drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54): first defined here

My patch for this one was applied to the DRM tree.

>drivers/tty/serial/omap-serial.c: In function 'serial_omap_console_write':
>drivers/tty/serial/omap-serial.c:1224:14: error: 'struct uart_port' has no member named 'sysrq'

I haven't seen this one.

>Warnings
>
>warning: (BPCTL) selects NET_CORE which has unmet direct dependencies (NETDEVICES)

I'm not that worried about staging drivers, although I sent a couple of fixes for
other staging bugs I found.

>warning: (UX500_SOC_COMMON) selects PINCTRL_ABX500 which has unmet direct dependencies (PINCTRL && AB8500_CORE)

This seems to be newly introduced and should definitely be fixed soon.

>warning: (VIRTIO_PCI && VIRTIO_MMIO && REMOTEPROC && RPMSG) selects VIRTIO which has unmet direct dependencies (VIRTUALIZATION)

This one has been around forever. I had a patch before but it was never urgent enough, since it's
only a harmless warning in randconfig.


>In file included from arch/arm/mach-imx/hotplug.c:16:0:
>arch/arm/mach-imx/common.h:100:29: warning: 'struct pt_regs' declared inside parameter list
>arch/arm/mach-imx/common.h:100:29: warning: its scope is only this definition or declaration, which is probably not what you want
>arch/arm/mach-imx/common.h:101:29: warning: 'struct pt_regs' declared inside parameter list

I don't know this one.

>kernel/time/tick-sched.c:89:16: warning: 'tick_init_jiffy_update' defined but not used
>kernel/time/tick-sched.c:103:13: warning: 'tick_sched_do_timer' defined but not used
>kernel/time/tick-sched.c:124:13: warning: 'tick_sched_handle' defined but not used
>kernel/profile.c:247:13: warning: 'profile_flip_buffers' defined but not used
>kernel/profile.c:270:13: warning: 'profile_discard_flip_buffers' defined but not used
>kernel/profile.c:334:125: warning: 'profile_cpu_callback' defined but not used
>drivers/staging/csr/io.c:80:12: warning: 'uf_read_proc' used but never defined
>drivers/video/aty/radeon_pm.c:1718:13: warning: 'radeon_reinitialize_M10' defined but not used

I think I made a fix for these before but gave up for now with too many other randconfig
warnings without CONFIG_PROC_FS. Same thing for CONFIG_BUG: I ended up just hard enabling
those.

>crypto/wp512.c: In function 'wp512_process_buffer':
>crypto/wp512.c:987:1: warning: the frame size of 1296 bytes is larger than 1024 bytes

My solution to this one was to slightly enlarge the stack size limit on ARM. There are a couple
of functions that have a stack that is just over 1KB on ARM but just under 1KB on other
architectures.

>drivers/mfd/wm8994-core.c: In function 'wm8994_device_init.clone.1':
>drivers/mfd/wm8994-core.c:408:14: warning: 'patch_regs' may be used uninitialized in this function
>drivers/pinctrl/pinctrl-nomadik.c: In function 'nmk_pmx_enable':
>drivers/pinctrl/pinctrl-nomadik.c:1810:16: warning: 'flags' may be used uninitialized in this function
>drivers/gpu/drm/radeon/r100.c: In function 'r100_bandwidth_update':
>drivers/gpu/drm/radeon/r100.c:3153:50: warning: 'disp_drain_rate.full' may be used uninitialized in this function
>drivers/gpu/drm/radeon/r100.c:3099:63: warning: 'crit_point_ff.full' may be used uninitialized in this function
>drivers/gpu/drm/tegra/dc.c: In function 'tegra_dc_setup_window':
>drivers/gpu/drm/tegra/dc.c:420:12: warning: 'planar' may be used uninitialized in this function
>drivers/gpu/drm/drm_irq.c: In function 'drm_calc_vbltimestamp_from_scanoutpos':
>drivers/gpu/drm/drm_irq.c:587:24: warning: 'mono_time_offset.tv64' may be used uninitialized in this function
>net/wireless/reg.c: In function 'reg_device_uevent':
>net/wireless/reg.c:2271:5: warning: 'alpha2[0]' may be used uninitialized in this function
>net/wireless/reg.c:2271:5: warning: 'alpha2[1]' may be used uninitialized in this function
>net/wireless/nl80211.c: In function '__cfg80211_wdev_from_attrs.clone.61':
>net/wireless/nl80211.c:58:6: warning: 'wdev_id' may be used uninitialized in this function

I have now queued up my patch that removes the bogus "used uninitialized" warnings
we get with gcc-4.7 or later and -Os.

>
>Section mismatch errors
>
>WARNING: arch/arm/mach-tegra/built-in.o(.text+0xb4c): Section mismatch in reference from the function tegra_pmc_parse_dt() to the (unknown reference) .init.rodata:(unknown)
>The function tegra_pmc_parse_dt() references
>the (unknown reference) __initconst (unknown).
>This is often because tegra_pmc_parse_dt lacks a __initconst 
>annotation or the annotation of (unknown) is wrong.

Stupid gcc optimization. I thought this was fixed in gcc. Which version are you using?

	Arnd


From jason at lakedaemon.net  Tue Apr 30 07:10:21 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Tue, 30 Apr 2013 07:10:21 -0400
Subject: Need help to measure and tune the latency in Linux RT
In-Reply-To: <CALJd4cbfqRFiGHshv8A+0A8kFo_qW=rvREsdgj3jQ=-0Rix0-g@mail.gmail.com>
References: <CALJd4cbfqRFiGHshv8A+0A8kFo_qW=rvREsdgj3jQ=-0Rix0-g@mail.gmail.com>
Message-ID: <20130430111021.GC31290@titan.lakedaemon.net>

Ashoka,

linux-embedded is pretty quiet.  I'm not even sure why I'm still
subscribed to it.  You'll have better luck with your question by asking
on linux-arm-kernel (added to the cc).  I believe there is also a
linux-rt-users mailinglist [1].  A few comments below:

On Tue, Apr 30, 2013 at 01:57:21PM +0530, Ashoka K wrote:
> Hi,
> 
> I have an embedded system running 2.6.33 cross compiled for ARM OMAP
> with 1 GHZ uni-processor system.

Wow, this is ancient.  Is this a vanilla kernel?  If it's a vendor
kernel, you'll need to ask the vendor.

> The application has many threads and processes (around 15 total). In
> that 1 thread is time critical and must run every interval confiurable
> as 2, 4 or 8 milli sec etc. There is another thread which transfers
> Images to a FTP or to HMI etc, whoever requested the image.
> With this image transfer enabled my critical process misses the
> deadline and timesout. This critical thread is at RR priority 50. I
> used a HR timer thread with RR pri 55 to wakeup the critical thread
> every 1 milli sec to do the job.
> If image transfer is enabled i see that real time thread misses deadlines.
> 
> All traffic is flowing on common ethernet connection. Does it affect
> in any way ?
> 
> How to find out where the kernel is waiting or delaying to schedule
> the critical thread even though it is at higher RR priority. How to
> measure the latency ?
> 
> I am trying to use Oprofile tool, but got some error in cross
> compiling. Doesn't these tools add their own latency to the original
> problem ?
> 
> Any tools ? which one is better. Please provide your input on this.

I'm not the guy to answer this ;-)  I'll just forward to the appropriate
lists.

hth,

Jason.

[1] http://vger.kernel.org/vger-lists.html#linux-rt-users


From marek.belisko at gmail.com  Tue Apr 30 07:16:47 2013
From: marek.belisko at gmail.com (Marek Belisko)
Date: Tue, 30 Apr 2013 13:16:47 +0200
Subject: [PATCH] clk: si5351: Allow user to define disabled state for every
 clock output.
Message-ID: <1367320607-25657-1-git-send-email-marek.belisko@streamunlimited.com>

Add platform data and dt bindings to allow user override disabled state.

Signed-off-by: Marek Belisko <marek.belisko at streamunlimited.com>
---
 .../devicetree/bindings/clock/silabs,si5351.txt    |    5 +++
 drivers/clk/clk-si5351.c                           |   36 +++++++++++++++++---
 include/linux/platform_data/si5351.h               |   16 +++++++++
 3 files changed, 53 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/clock/silabs,si5351.txt b/Documentation/devicetree/bindings/clock/silabs,si5351.txt
index cc37465..2f24c12 100644
--- a/Documentation/devicetree/bindings/clock/silabs,si5351.txt
+++ b/Documentation/devicetree/bindings/clock/silabs,si5351.txt
@@ -44,6 +44,11 @@ Optional child node properties:
 - silabs,multisynth-source: source pll A(0) or B(1) of corresponding multisynth
   divider.
 - silabs,pll-master: boolean, multisynth can change pll frequency.
+- silabs,disable-state : clock disable state (default 0) shall be
+  0 = CLKx is set to a LOW state when disabled
+  1 = CLKx is set to a HIGH state when disabled
+  2 = CLKx is set to a HIGH IMPEDANCE state when disabled
+  3 = CLKx is NEVER DISABLED
 
 ==Example==
 
diff --git a/drivers/clk/clk-si5351.c b/drivers/clk/clk-si5351.c
index 8323c31..bfe92b8 100644
--- a/drivers/clk/clk-si5351.c
+++ b/drivers/clk/clk-si5351.c
@@ -1230,6 +1230,21 @@ static int si5351_dt_parse(struct i2c_client *client)
 
 		pdata->clkout[num].pll_master =
 			of_property_read_bool(child, "silabs,pll-master");
+
+		if (!of_property_read_u32(child, "silabs,disable-state",
+					  &val)) {
+			switch (val) {
+			case SI5351_DISABLE_LOW:
+			case SI5351_DISABLE_HIGH:
+			case SI5351_DISABLE_HIGH_IMPEDANCE:
+			case SI5351_NEVER_DISABLED:
+				pdata->clkout[num].disable_state = val;
+				break;
+			default:
+				pdata->clkout[num].disable_state = 0;
+			}
+		}
+
 	}
 	client->dev.platform_data = pdata;
 
@@ -1250,7 +1265,7 @@ static int si5351_i2c_probe(struct i2c_client *client,
 	struct clk_init_data init;
 	struct clk *clk;
 	const char *parent_names[4];
-	u8 num_parents, num_clocks;
+	u8 num_parents, num_clocks, disabled;
 	int ret, n;
 
 	ret = si5351_dt_parse(client);
@@ -1281,9 +1296,22 @@ static int si5351_i2c_probe(struct i2c_client *client,
 
 	/* Disable interrupts */
 	si5351_reg_write(drvdata, SI5351_INTERRUPT_MASK, 0xf0);
-	/* Set disabled output drivers to drive low */
-	si5351_reg_write(drvdata, SI5351_CLK3_0_DISABLE_STATE, 0x00);
-	si5351_reg_write(drvdata, SI5351_CLK7_4_DISABLE_STATE, 0x00);
+
+	/* Set disabled output states */
+	disabled = (pdata->clkout[0].disable_state & 0x03) |
+		((pdata->clkout[1].disable_state << 2) & 0x0C) |
+		((pdata->clkout[2].disable_state << 4) & 0x30) |
+		((pdata->clkout[3].disable_state << 6) & 0xC0);
+
+	si5351_reg_write(drvdata, SI5351_CLK3_0_DISABLE_STATE, disabled);
+
+	disabled = (pdata->clkout[4].disable_state & 0x03) |
+		((pdata->clkout[5].disable_state << 2) & 0x0C) |
+		((pdata->clkout[6].disable_state << 4) & 0x30) |
+		((pdata->clkout[7].disable_state << 6) & 0xC0);
+
+	si5351_reg_write(drvdata, SI5351_CLK7_4_DISABLE_STATE, disabled);
+
 	/* Ensure pll select is on XTAL for Si5351A/B */
 	if (drvdata->variant != SI5351_VARIANT_C)
 		si5351_set_bits(drvdata, SI5351_PLL_INPUT_SOURCE,
diff --git a/include/linux/platform_data/si5351.h b/include/linux/platform_data/si5351.h
index 92dabca..6702991 100644
--- a/include/linux/platform_data/si5351.h
+++ b/include/linux/platform_data/si5351.h
@@ -79,6 +79,21 @@ enum si5351_drive_strength {
 };
 
 /**
+ * enum si5351_disable_state - Si5351 clock output disable state
+ * @SI5351_DISABLE_LOW: CLKx is set to a LOW state when disabled
+ * @SI5351_DISABLE_HIGH: CLKx is set to a HIGH state when disabled
+ * @SI5351_DISABLE_HIGH_IMPEDANCE: CLKx is set to a HIGH IMPEDANCE state
+ *				   when disabled
+ * @SI5351_NEVER_DISABLED: CLKx is NEVER DISABLED
+ */
+enum si5351_disable_state {
+	SI5351_DISABLE_LOW = 0,
+	SI5351_DISABLE_HIGH,
+	SI5351_DISABLE_HIGH_IMPEDANCE,
+	SI5351_NEVER_DISABLED,
+};
+
+/**
  * struct si5351_clkout_config - Si5351 clock output configuration
  * @clkout: clkout number
  * @multisynth_src: multisynth source clock
@@ -93,6 +108,7 @@ struct si5351_clkout_config {
 	enum si5351_drive_strength drive;
 	bool pll_master;
 	unsigned long rate;
+	enum si5351_disable_state disable_state;
 };
 
 /**
-- 
1.7.9.5



From emilio at elopez.com.ar  Tue Apr 30 07:20:23 2013
From: emilio at elopez.com.ar (=?ISO-8859-1?Q?Emilio_L=F3pez?=)
Date: Tue, 30 Apr 2013 08:20:23 -0300
Subject: [PATCH 1/2] clk: sun5i: Add compatibles for Allwinner A13
In-Reply-To: <1367315783-21345-2-git-send-email-maxime.ripard@free-electrons.com>
References: <1367315783-21345-1-git-send-email-maxime.ripard@free-electrons.com>
 <1367315783-21345-2-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <517FA8F7.1080609@elopez.com.ar>

Hi Maxime,

El 30/04/13 06:56, Maxime Ripard escribi?:
> The A13 has a lot less clocks than the one found in the Allwinner A10.
> Add these stripped down clocks to the clock driver and in the
> documentation.
> 
> Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>

This patch looks good to me.

Acked-by: Emilio L?pez <emilio at elopez.com.ar>

> ---
>  Documentation/devicetree/bindings/clock/sunxi.txt  | 117 +++------------------
>  .../bindings/clock/sunxi/sun4i-a10-gates.txt       |  93 ++++++++++++++++
>  .../bindings/clock/sunxi/sun5i-a13-gates.txt       |  58 ++++++++++
>  drivers/clk/sunxi/clk-sunxi.c                      |  31 ++++--
>  4 files changed, 187 insertions(+), 112 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/clock/sunxi/sun4i-a10-gates.txt
>  create mode 100644 Documentation/devicetree/bindings/clock/sunxi/sun5i-a13-gates.txt
> 
> diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt b/Documentation/devicetree/bindings/clock/sunxi.txt
> index 729f524..d495521 100644
> --- a/Documentation/devicetree/bindings/clock/sunxi.txt
> +++ b/Documentation/devicetree/bindings/clock/sunxi.txt
> @@ -12,22 +12,30 @@ Required properties:
>  	"allwinner,sun4i-axi-clk" - for the AXI clock
>  	"allwinner,sun4i-axi-gates-clk" - for the AXI gates
>  	"allwinner,sun4i-ahb-clk" - for the AHB clock
> -	"allwinner,sun4i-ahb-gates-clk" - for the AHB gates
> +	"allwinner,sun4i-ahb-gates-clk" - for the AHB gates on A10
> +	"allwinner,sun5i-a13-ahb-gates-clk" - for the AHB gates on A13
>  	"allwinner,sun4i-apb0-clk" - for the APB0 clock
> -	"allwinner,sun4i-apb0-gates-clk" - for the APB0 gates
> +	"allwinner,sun4i-apb0-gates-clk" - for the APB0 gates on A10
> +	"allwinner,sun5i-a13-apb0-gates-clk" - for the APB0 gates on A13
>  	"allwinner,sun4i-apb1-clk" - for the APB1 clock
>  	"allwinner,sun4i-apb1-mux-clk" - for the APB1 clock muxing
> -	"allwinner,sun4i-apb1-gates-clk" - for the APB1 gates
> +	"allwinner,sun4i-apb1-gates-clk" - for the APB1 gates on A10
> +	"allwinner,sun5i-a13-apb1-gates-clk" - for the APB1 gates on A13
>  
>  Required properties for all clocks:
>  - reg : shall be the control register address for the clock.
>  - clocks : shall be the input parent clock(s) phandle for the clock
>  - #clock-cells : from common clock binding; shall be set to 0 except for
> -	"allwinner,sun4i-*-gates-clk" where it shall be set to 1
> +	"allwinner,*-gates-clk" where it shall be set to 1
>  
> -Additionally, "allwinner,sun4i-*-gates-clk" clocks require:
> +Additionally, "allwinner,*-gates-clk" clocks require:
>  - clock-output-names : the corresponding gate names that the clock controls
>  
> +Clock consumers should specify the desired clocks they use with a
> +"clocks" phandle cell. Consumers that are using a gated clock should
> +provide an additional ID in their clock property. The values of this
> +ID are documented in sunxi/<soc>-gates.txt.
> +
>  For example:
>  
>  osc24M: osc24M at 01c20050 {
> @@ -50,102 +58,3 @@ cpu: cpu at 01c20054 {
>  	reg = <0x01c20054 0x4>;
>  	clocks = <&osc32k>, <&osc24M>, <&pll1>;
>  };
> -
> -
> -
> -Gate clock outputs
> -
> -The "allwinner,sun4i-*-gates-clk" clocks provide several gatable outputs;
> -their corresponding offsets as present on sun4i are listed below. Note that
> -some of these gates are not present on sun5i.
> -
> -  * AXI gates ("allwinner,sun4i-axi-gates-clk")
> -
> -    DRAM                                                                0
> -
> -  * AHB gates ("allwinner,sun4i-ahb-gates-clk")
> -
> -    USB0                                                                0
> -    EHCI0                                                               1
> -    OHCI0                                                               2*
> -    EHCI1                                                               3
> -    OHCI1                                                               4*
> -    SS                                                                  5
> -    DMA                                                                 6
> -    BIST                                                                7
> -    MMC0                                                                8
> -    MMC1                                                                9
> -    MMC2                                                                10
> -    MMC3                                                                11
> -    MS                                                                  12**
> -    NAND                                                                13
> -    SDRAM                                                               14
> -
> -    ACE                                                                 16
> -    EMAC                                                                17
> -    TS                                                                  18
> -
> -    SPI0                                                                20
> -    SPI1                                                                21
> -    SPI2                                                                22
> -    SPI3                                                                23
> -    PATA                                                                24
> -    SATA                                                                25**
> -    GPS                                                                 26*
> -
> -    VE                                                                  32
> -    TVD                                                                 33
> -    TVE0                                                                34
> -    TVE1                                                                35
> -    LCD0                                                                36
> -    LCD1                                                                37
> -
> -    CSI0                                                                40
> -    CSI1                                                                41
> -
> -    HDMI                                                                43
> -    DE_BE0                                                              44
> -    DE_BE1                                                              45
> -    DE_FE0                                                              46
> -    DE_FE1                                                              47
> -
> -    MP                                                                  50
> -
> -    MALI400                                                             52
> -
> -  * APB0 gates ("allwinner,sun4i-apb0-gates-clk")
> -
> -    CODEC                                                               0
> -    SPDIF                                                               1*
> -    AC97                                                                2
> -    IIS                                                                 3
> -
> -    PIO                                                                 5
> -    IR0                                                                 6
> -    IR1                                                                 7
> -
> -    KEYPAD                                                              10
> -
> -  * APB1 gates ("allwinner,sun4i-apb1-gates-clk")
> -
> -    I2C0                                                                0
> -    I2C1                                                                1
> -    I2C2                                                                2
> -
> -    CAN                                                                 4
> -    SCR                                                                 5
> -    PS20                                                                6
> -    PS21                                                                7
> -
> -    UART0                                                               16
> -    UART1                                                               17
> -    UART2                                                               18
> -    UART3                                                               19
> -    UART4                                                               20
> -    UART5                                                               21
> -    UART6                                                               22
> -    UART7                                                               23
> -
> -Notation:
> - [*]:  The datasheet didn't mention these, but they are present on AW code
> - [**]: The datasheet had this marked as "NC" but they are used on AW code
> diff --git a/Documentation/devicetree/bindings/clock/sunxi/sun4i-a10-gates.txt b/Documentation/devicetree/bindings/clock/sunxi/sun4i-a10-gates.txt
> new file mode 100644
> index 0000000..6a03475
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/sunxi/sun4i-a10-gates.txt
> @@ -0,0 +1,93 @@
> +Gate clock outputs
> +------------------
> +
> +  * AXI gates ("allwinner,sun4i-axi-gates-clk")
> +
> +    DRAM					0
> +
> +  * AHB gates ("allwinner,sun4i-ahb-gates-clk")
> +
> +    USB0					0
> +    EHCI0					1
> +    OHCI0					2*
> +    EHCI1					3
> +    OHCI1					4*
> +    SS						5
> +    DMA						6
> +    BIST					7
> +    MMC0					8
> +    MMC1					9
> +    MMC2					10
> +    MMC3					11
> +    MS						12**
> +    NAND					13
> +    SDRAM					14
> +
> +    ACE						16
> +    EMAC					17
> +    TS						18
> +
> +    SPI0					20
> +    SPI1					21
> +    SPI2					22
> +    SPI3					23
> +    PATA					24
> +    SATA					25**
> +    GPS						26*
> +
> +    VE						32
> +    TVD						33
> +    TVE0					34
> +    TVE1					35
> +    LCD0					36
> +    LCD1					37
> +
> +    CSI0					40
> +    CSI1					41
> +
> +    HDMI					43
> +    DE_BE0					44
> +    DE_BE1					45
> +    DE_FE1					46
> +    DE_FE1					47
> +
> +    MP						50
> +
> +    MALI400					52
> +
> +  * APB0 gates ("allwinner,sun4i-apb0-gates-clk")
> +
> +    CODEC					0
> +    SPDIF					1*
> +    AC97					2
> +    IIS						3
> +
> +    PIO						5
> +    IR0						6
> +    IR1						7
> +
> +    KEYPAD					10
> +
> +  * APB1 gates ("allwinner,sun4i-apb1-gates-clk")
> +
> +    I2C0					0
> +    I2C1					1
> +    I2C2					2
> +
> +    CAN						4
> +    SCR						5
> +    PS20					6
> +    PS21					7
> +
> +    UART0					16
> +    UART1					17
> +    UART2					18
> +    UART3					19
> +    UART4					20
> +    UART5					21
> +    UART6					22
> +    UART7					23
> +
> +Notation:
> + [*]:  The datasheet didn't mention these, but they are present on AW code
> + [**]: The datasheet had this marked as "NC" but they are used on AW code
> diff --git a/Documentation/devicetree/bindings/clock/sunxi/sun5i-a13-gates.txt b/Documentation/devicetree/bindings/clock/sunxi/sun5i-a13-gates.txt
> new file mode 100644
> index 0000000..006b6df
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/sunxi/sun5i-a13-gates.txt
> @@ -0,0 +1,58 @@
> +Gate clock outputs
> +------------------
> +
> +  * AXI gates ("allwinner,sun4i-axi-gates-clk")
> +
> +    DRAM					0
> +
> +  * AHB gates ("allwinner,sun5i-a13-ahb-gates-clk")
> +
> +    USBOTG					0
> +    EHCI					1
> +    OHCI					2
> +
> +    SS						5
> +    DMA						6
> +    BIST					7
> +    MMC0					8
> +    MMC1					9
> +    MMC2					10
> +
> +    NAND					13
> +    SDRAM					14
> +
> +    SPI0					20
> +    SPI1					21
> +    SPI2					22
> +
> +    STIMER					28
> +
> +    VE						32
> +
> +    LCD						36
> +
> +    CSI						40
> +
> +    DE_BE					44
> +
> +    DE_FE					46
> +
> +    IEP						51
> +    MALI400					52
> +
> +  * APB0 gates ("allwinner,sun5i-a13-apb0-gates-clk")
> +
> +    CODEC					0
> +
> +    PIO						5
> +    IR						6
> +
> +  * APB1 gates ("allwinner,sun5i-a13-apb1-gates-clk")
> +
> +    I2C0					0
> +    I2C1					1
> +    I2C2					2
> +
> +    UART1					17
> +
> +    UART3					19
> diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
> index 8492ad1..930d36f 100644
> --- a/drivers/clk/sunxi/clk-sunxi.c
> +++ b/drivers/clk/sunxi/clk-sunxi.c
> @@ -333,22 +333,34 @@ struct gates_data {
>  	DECLARE_BITMAP(mask, SUNXI_GATES_MAX_SIZE);
>  };
>  
> -static const __initconst struct gates_data axi_gates_data = {
> +static const __initconst struct gates_data sun4i_axi_gates_data = {
>  	.mask = {1},
>  };
>  
> -static const __initconst struct gates_data ahb_gates_data = {
> +static const __initconst struct gates_data sun4i_ahb_gates_data = {
>  	.mask = {0x7F77FFF, 0x14FB3F},
>  };
>  
> -static const __initconst struct gates_data apb0_gates_data = {
> +static const __initconst struct gates_data sun5i_a13_ahb_gates_data = {
> +	.mask = {0x107067e7, 0x185111},

If you send a v2 please use uppercase e and a below for consistency.

> +};
> +
> +static const __initconst struct gates_data sun4i_apb0_gates_data = {
>  	.mask = {0x4EF},
>  };
>  
> -static const __initconst struct gates_data apb1_gates_data = {
> +static const __initconst struct gates_data sun5i_a13_apb0_gates_data = {
> +	.mask = {0x61},
> +};
> +
> +static const __initconst struct gates_data sun4i_apb1_gates_data = {
>  	.mask = {0xFF00F7},
>  };
>  
> +static const __initconst struct gates_data sun5i_a13_apb1_gates_data = {
> +	.mask = {0xa0007},

> +};
> +
>  static void __init sunxi_gates_clk_setup(struct device_node *node,
>  					 struct gates_data *data)
>  {
> @@ -428,10 +440,13 @@ static const __initconst struct of_device_id clk_mux_match[] = {
>  
>  /* Matches for gate clocks */
>  static const __initconst struct of_device_id clk_gates_match[] = {
> -	{.compatible = "allwinner,sun4i-axi-gates-clk", .data = &axi_gates_data,},
> -	{.compatible = "allwinner,sun4i-ahb-gates-clk", .data = &ahb_gates_data,},
> -	{.compatible = "allwinner,sun4i-apb0-gates-clk", .data = &apb0_gates_data,},
> -	{.compatible = "allwinner,sun4i-apb1-gates-clk", .data = &apb1_gates_data,},
> +	{.compatible = "allwinner,sun4i-axi-gates-clk", .data = &sun4i_axi_gates_data,},
> +	{.compatible = "allwinner,sun4i-ahb-gates-clk", .data = &sun4i_ahb_gates_data,},
> +	{.compatible = "allwinner,sun5i-a13-ahb-gates-clk", .data = &sun5i_a13_ahb_gates_data,},
> +	{.compatible = "allwinner,sun4i-apb0-gates-clk", .data = &sun4i_apb0_gates_data,},
> +	{.compatible = "allwinner,sun5i-a13-apb0-gates-clk", .data = &sun5i_a13_apb0_gates_data,},
> +	{.compatible = "allwinner,sun4i-apb1-gates-clk", .data = &sun4i_apb1_gates_data,},
> +	{.compatible = "allwinner,sun5i-a13-apb1-gates-clk", .data = &sun5i_a13_apb1_gates_data,},
>  	{}
>  };
>  
> 

Thanks!

Emilio


From catalin.marinas at arm.com  Tue Apr 30 07:22:25 2013
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Tue, 30 Apr 2013 12:22:25 +0100
Subject: [PATCH V3 2/2] ARM: Handle user space mapped pages in
 flush_kernel_dcache_page
In-Reply-To: <20130421220629.GA25571@schnuecks.de>
References: <20121008174428.GB3204@arm.com>
 <20121008200216.GA14167@schnuecks.de>
 <20121008202040.GC4625@n2100.arm.linux.org.uk>
 <20121008230733.GA17819@schnuecks.de>
 <20121118211005.GW22106@titan.lakedaemon.net>
 <20130418111608.GF27197@titan.lakedaemon.net>
 <20130418112201.GQ14496@n2100.arm.linux.org.uk>
 <20130418114016.GG27197@titan.lakedaemon.net>
 <20130418135104.GA18616@arm.com>
 <20130421220629.GA25571@schnuecks.de>
Message-ID: <20130430112225.GD29766@arm.com>

On Sun, Apr 21, 2013 at 11:06:30PM +0100, Simon Baatz wrote:
> On Thu, Apr 18, 2013 at 02:51:04PM +0100, Catalin Marinas wrote:
> > On Thu, Apr 18, 2013 at 12:40:16PM +0100, Jason Cooper wrote:
> > > Ok, got it.  I should have been more explicit.  LVM doesn't work on ARM.
> > > iirc, Simon had a demo of dm-crypt also faulting on ARM.  This patch was
> > > not the correct approach.  Is there an interest (particularly Simon) in
> > > fixing the problem?
> > 
> > I think fixing this for ARM is useful but I don't have any time to
> > allocate. I think I acked the first patch in the series but I don't
> > fully remember the details behind the second one.
> > 
> > As Russell said, flush_kernel_dcache_page() is not the right API.
> 
> It is not the driver itself which is using the API, it is the
> generic scatterlist memory iterator. And I don't think that this is
> wrong, as I have tried to explain in [1].

Trying to remember what we've discussed over the past months on this
topic. It looks like sg_miter_stop() does the right thing in calling
flush_kernel_dcache_page(). Commit f8b63c1 (ARM: 6382/1: Remove
superfluous flush_kernel_dcache_page()) removed this function entirely.
The code previously had this comment - /* highmem pages are always
flushed upon kunmap already */ which I think it wasn't fully correct
either. The kunmap_atomic() flushes the caches but kunmap() doesn't, so
I suspect we only get the flushing if SG_MITER_ATOMIC.

So it looks to me like flush_kernel_dcache_page() should be implemented
even for highmem pages (with VIVT or aliasing VIPT, at least for non
kmap_atomic addresses by checking for FIXADDR_START). If highmem is
disabled, I suspect we still need this function since the calling code
doesn't care whether kmap/kunmap was a no-op. But can we keep it as a
simple call to __cpuc_flush_dcache_area(page_address(page), PAGE_SIZE)?

-- 
Catalin


From vinod.koul at intel.com  Tue Apr 30 06:51:05 2013
From: vinod.koul at intel.com (Vinod Koul)
Date: Tue, 30 Apr 2013 16:21:05 +0530
Subject: [PATCH v2 2/2] dma: imx-sdma: move to generic device tree bindings
In-Reply-To: <1366901008-7593-3-git-send-email-shawn.guo@linaro.org>
References: <1366901008-7593-1-git-send-email-shawn.guo@linaro.org>
 <1366901008-7593-3-git-send-email-shawn.guo@linaro.org>
Message-ID: <20130430105105.GG1960@intel.com>

On Thu, Apr 25, 2013 at 10:43:28PM +0800, Shawn Guo wrote:
> Update imx-sdma driver to adopt generic DMA device tree bindings.  It
> calls of_dma_controller_register() with imx-sdma specific of_dma_xlate
> to get the generic DMA device tree helper support.  The #dma-cells for
> imx-sdma must be 3, which includes request ID, peripheral type and
> priority.
> 
> The definitions of peripheral type and priority get moved into
> include/dt-bindings/dma/imx.h, so that the macros can also be used in
> dts files.
> 
> The existing way of requesting channel, clients directly call
> dma_request_channel(), still work there, and will be removed after
> all imx-sdma clients get converted to generic DMA device tree helper.
> 
> Signed-off-by: Shawn Guo <shawn.guo at linaro.org>
Looks fine to me, Arnd?

--
~Vinod
> ---
>  .../devicetree/bindings/dma/fsl-imx-sdma.txt       |   22 +++++++++++
>  drivers/dma/imx-sdma.c                             |   40 ++++++++++++++++++++
>  include/dt-bindings/dma/imx.h                      |   29 ++++++++++++++
>  include/linux/platform_data/dma-imx.h              |   31 +--------------
>  4 files changed, 92 insertions(+), 30 deletions(-)
>  create mode 100644 include/dt-bindings/dma/imx.h
> 
> diff --git a/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt b/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt
> index d1e3f44..8bd8d35 100644
> --- a/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt
> +++ b/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt
> @@ -4,6 +4,11 @@ Required properties:
>  - compatible : Should be "fsl,<chip>-sdma"
>  - reg : Should contain SDMA registers location and length
>  - interrupts : Should contain SDMA interrupt
> +- #dma-cells : Must be <3>.
> +  The first cell specifies the DMA request/event ID.  The second and
> +  third cell specifies the peripheral type and priority of DMA transfer
> +  respectively.  Refer to include/dt-bindings/dma/imx.h for available
> +  peripheral types and priorities.
>  - fsl,sdma-ram-script-name : Should contain the full path of SDMA RAM
>    scripts firmware
>  
> @@ -13,5 +18,22 @@ sdma at 83fb0000 {
>  	compatible = "fsl,imx51-sdma", "fsl,imx35-sdma";
>  	reg = <0x83fb0000 0x4000>;
>  	interrupts = <6>;
> +	#dma-cells = <3>;
>  	fsl,sdma-ram-script-name = "sdma-imx51.bin";
>  };
> +
> +DMA clients connected to the i.MX SDMA controller must use the format
> +described in the dma.txt file.
> +
> +Examples:
> +
> +ssi2: ssi at 70014000 {
> +	compatible = "fsl,imx51-ssi", "fsl,imx21-ssi";
> +	reg = <0x70014000 0x4000>;
> +	interrupts = <30>;
> +	clocks = <&clks 49>;
> +	dmas = <&sdma 24 IMX_DMATYPE_SSI_SP DMA_PRIO_HIGH>,
> +	       <&sdma 25 IMX_DMATYPE_SSI_SP DMA_PRIO_HIGH>;
> +	dma-names = "rx", "tx";
> +	fsl,fifo-depth = <15>;
> +};
> diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
> index e57a0c6..f1324da 100644
> --- a/drivers/dma/imx-sdma.c
> +++ b/drivers/dma/imx-sdma.c
> @@ -36,6 +36,7 @@
>  #include <linux/dmaengine.h>
>  #include <linux/of.h>
>  #include <linux/of_device.h>
> +#include <linux/of_dma.h>
>  
>  #include <asm/irq.h>
>  #include <linux/platform_data/dma-imx-sdma.h>
> @@ -1296,6 +1297,35 @@ err_dma_alloc:
>  	return ret;
>  }
>  
> +static bool sdma_filter_fn(struct dma_chan *chan, void *fn_param)
> +{
> +	struct imx_dma_data *data = fn_param;
> +
> +	if (!imx_dma_is_general_purpose(chan))
> +		return false;
> +
> +	chan->private = data;
> +
> +	return true;
> +}
> +
> +struct dma_chan *sdma_xlate(struct of_phandle_args *dma_spec,
> +			    struct of_dma *ofdma)
> +{
> +	struct sdma_engine *sdma = ofdma->of_dma_data;
> +	dma_cap_mask_t mask = sdma->dma_device.cap_mask;
> +	struct imx_dma_data data;
> +
> +	if (dma_spec->args_count != 3)
> +		return NULL;
> +
> +	data.dma_request = dma_spec->args[0];
> +	data.peripheral_type = dma_spec->args[1];
> +	data.priority = dma_spec->args[2];
> +
> +	return dma_request_channel(mask, sdma_filter_fn, &data);
> +}
> +
>  static int __init sdma_probe(struct platform_device *pdev)
>  {
>  	const struct of_device_id *of_id =
> @@ -1443,10 +1473,20 @@ static int __init sdma_probe(struct platform_device *pdev)
>  		goto err_init;
>  	}
>  
> +	if (np) {
> +		ret = of_dma_controller_register(np, sdma_xlate, sdma);
> +		if (ret) {
> +			dev_err(&pdev->dev, "failed to register controller\n");
> +			goto err_register;
> +		}
> +	}
> +
>  	dev_info(sdma->dev, "initialized\n");
>  
>  	return 0;
>  
> +err_register:
> +	dma_async_device_unregister(&sdma->dma_device);
>  err_init:
>  	kfree(sdma->script_addrs);
>  err_alloc:
> diff --git a/include/dt-bindings/dma/imx.h b/include/dt-bindings/dma/imx.h
> new file mode 100644
> index 0000000..d5de68c
> --- /dev/null
> +++ b/include/dt-bindings/dma/imx.h
> @@ -0,0 +1,29 @@
> +/*
> + * This enumerates peripheral types. Used for SDMA.
> + */
> +#define IMX_DMATYPE_SSI		0  /* MCU domain SSI */
> +#define IMX_DMATYPE_SSI_SP	1  /* Shared SSI */
> +#define IMX_DMATYPE_MMC		2  /* MMC */
> +#define IMX_DMATYPE_SDHC	3  /* SDHC */
> +#define IMX_DMATYPE_UART	4  /* MCU domain UART */
> +#define IMX_DMATYPE_UART_SP	5  /* Shared UART */
> +#define IMX_DMATYPE_FIRI	6  /* FIRI */
> +#define IMX_DMATYPE_CSPI	7  /* MCU domain CSPI */
> +#define IMX_DMATYPE_CSPI_SP	8  /* Shared CSPI */
> +#define IMX_DMATYPE_SIM		9  /* SIM */
> +#define IMX_DMATYPE_ATA		10 /* ATA */
> +#define IMX_DMATYPE_CCM		11 /* CCM */
> +#define IMX_DMATYPE_EXT		12 /* External peripheral */
> +#define IMX_DMATYPE_MSHC	13 /* Memory Stick Host Controller */
> +#define IMX_DMATYPE_MSHC_SP	14 /* Shared Memory Stick Host Controller */
> +#define IMX_DMATYPE_DSP		15 /* DSP */
> +#define IMX_DMATYPE_MEMORY	16 /* Memory */
> +#define IMX_DMATYPE_FIFO_MEMORY	17 /* FIFO type Memory */
> +#define IMX_DMATYPE_SPDIF	18 /* SPDIF */
> +#define IMX_DMATYPE_IPU_MEMORY	19 /* IPU Memory */
> +#define IMX_DMATYPE_ASRC	20 /* ASRC */
> +#define IMX_DMATYPE_ESAI	21 /* ESAI */
> +
> +#define DMA_PRIO_HIGH		0
> +#define DMA_PRIO_MEDIUM		1
> +#define DMA_PRIO_LOW		2
> diff --git a/include/linux/platform_data/dma-imx.h b/include/linux/platform_data/dma-imx.h
> index 8a8a684..33f7eda 100644
> --- a/include/linux/platform_data/dma-imx.h
> +++ b/include/linux/platform_data/dma-imx.h
> @@ -12,36 +12,7 @@
>  #include <linux/scatterlist.h>
>  #include <linux/device.h>
>  #include <linux/dmaengine.h>
> -
> -/*
> - * This enumerates peripheral types. Used for SDMA.
> - */
> -#define IMX_DMATYPE_SSI		0  /* MCU domain SSI */
> -#define IMX_DMATYPE_SSI_SP	1  /* Shared SSI */
> -#define IMX_DMATYPE_MMC		2  /* MMC */
> -#define IMX_DMATYPE_SDHC	3  /* SDHC */
> -#define IMX_DMATYPE_UART	4  /* MCU domain UART */
> -#define IMX_DMATYPE_UART_SP	5  /* Shared UART */
> -#define IMX_DMATYPE_FIRI	6  /* FIRI */
> -#define IMX_DMATYPE_CSPI	7  /* MCU domain CSPI */
> -#define IMX_DMATYPE_CSPI_SP	8  /* Shared CSPI */
> -#define IMX_DMATYPE_SIM		9  /* SIM */
> -#define IMX_DMATYPE_ATA		10 /* ATA */
> -#define IMX_DMATYPE_CCM		11 /* CCM */
> -#define IMX_DMATYPE_EXT		12 /* External peripheral */
> -#define IMX_DMATYPE_MSHC	13 /* Memory Stick Host Controller */
> -#define IMX_DMATYPE_MSHC_SP	14 /* Shared Memory Stick Host Controller */
> -#define IMX_DMATYPE_DSP		15 /* DSP */
> -#define IMX_DMATYPE_MEMORY	16 /* Memory */
> -#define IMX_DMATYPE_FIFO_MEMORY	17 /* FIFO type Memory */
> -#define IMX_DMATYPE_SPDIF	18 /* SPDIF */
> -#define IMX_DMATYPE_IPU_MEMORY	19 /* IPU Memory */
> -#define IMX_DMATYPE_ASRC	20 /* ASRC */
> -#define IMX_DMATYPE_ESAI	21 /* ESAI */
> -
> -#define DMA_PRIO_HIGH		0
> -#define DMA_PRIO_MEDIUM		1
> -#define DMA_PRIO_LOW		2
> +#include <dt-bindings/dma/imx.h>
>  
>  struct imx_dma_data {
>  	int dma_request; /* DMA request line */
> -- 
> 1.7.9.5
> 
> 


From emilio at elopez.com.ar  Tue Apr 30 07:32:10 2013
From: emilio at elopez.com.ar (=?ISO-8859-1?Q?Emilio_L=F3pez?=)
Date: Tue, 30 Apr 2013 08:32:10 -0300
Subject: [PATCH 2/2] ARM: sun5i: Update the clock compatible strings
In-Reply-To: <1367315783-21345-3-git-send-email-maxime.ripard@free-electrons.com>
References: <1367315783-21345-1-git-send-email-maxime.ripard@free-electrons.com>
 <1367315783-21345-3-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <517FABBA.5060902@elopez.com.ar>

Hi Maxime,

El 30/04/13 06:56, Maxime Ripard escribi?:
> The Allwinner A13 has a smaller clock set than the one found in the A10.
> Fix the A13 device tree and documentation to reflect this.
> 
> Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>

The patch looks fine to me.

Acked-by: Emilio L?pez <emilio at elopez.com.ar>

> ---
>  arch/arm/boot/dts/sun5i-a13.dtsi | 35 ++++++++++++-----------------------
>  1 file changed, 12 insertions(+), 23 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/sun5i-a13.dtsi b/arch/arm/boot/dts/sun5i-a13.dtsi
> index 31fa38f..8ba65c1 100644
> --- a/arch/arm/boot/dts/sun5i-a13.dtsi
> +++ b/arch/arm/boot/dts/sun5i-a13.dtsi
> @@ -95,20 +95,15 @@
>  
>  		ahb_gates: ahb_gates at 01c20060 {
>  			#clock-cells = <1>;
> -			compatible = "allwinner,sun4i-ahb-gates-clk";
> +			compatible = "allwinner,sun5i-a13-ahb-gates-clk";
>  			reg = <0x01c20060 0x8>;
>  			clocks = <&ahb>;
> -			clock-output-names = "ahb_usb0", "ahb_ehci0",
> -				"ahb_ohci0", "ahb_ehci1", "ahb_ohci1", "ahb_ss",
> -				"ahb_dma", "ahb_bist", "ahb_mmc0", "ahb_mmc1",
> -				"ahb_mmc2", "ahb_mmc3", "ahb_ms", "ahb_nand",
> -				"ahb_sdram", "ahb_ace",	"ahb_emac", "ahb_ts",
> -				"ahb_spi0", "ahb_spi1", "ahb_spi2", "ahb_spi3",
> -				"ahb_pata", "ahb_sata", "ahb_gps", "ahb_ve",
> -				"ahb_tvd", "ahb_tve0", "ahb_tve1", "ahb_lcd0",
> -				"ahb_lcd1", "ahb_csi0", "ahb_csi1", "ahb_hdmi",
> -				"ahb_de_be0", "ahb_de_be1", "ahb_de_fe0",
> -				"ahb_de_fe1", "ahb_mp", "ahb_mali400";
> +			clock-output-names = "ahb_usbotg", "ahb_ehci", "ahb_ohci",

Should we keep the USB and DE names consistent between sun4i and sun5i?
Nobody should be referencing them by name, however, so it wouldn't cause
any issues on the long run.

> +				"ahb_ss", "ahb_dma", "ahb_bist", "ahb_mmc0",
> +				"ahb_mmc1", "ahb_mmc2", "ahb_nand", "ahb_sdram",
> +				"ahb_spi0", "ahb_spi1", "ahb_spi2", "ahb_stimer",
> +				"ahb_ve", "ahb_lcd", "ahb_csi", "ahb_de_be",
> +				"ahb_de_fe", "ahb_iep", "ahb_mali400";
>  		};
>  
>  		apb0: apb0 at 01c20054 {
> @@ -120,15 +115,13 @@
>  
>  		apb0_gates: apb0_gates at 01c20068 {
>  			#clock-cells = <1>;
> -			compatible = "allwinner,sun4i-apb0-gates-clk";
> +			compatible = "allwinner,sun5i-a13-apb0-gates-clk";
>  			reg = <0x01c20068 0x4>;
>  			clocks = <&apb0>;
> -			clock-output-names = "apb0_codec", "apb0_spdif",
> -				"apb0_ac97", "apb0_iis", "apb0_pio", "apb0_ir0",
> -				"apb0_ir1", "apb0_keypad";
> +			clock-output-names = "apb0_codec", "apb0_pio", "apb0_ir";
>  		};
>  
> -		/* dummy is pll62 */
> +		/* dummy is pll6 */
>  		apb1_mux: apb1_mux at 01c20058 {
>  			#clock-cells = <0>;
>  			compatible = "allwinner,sun4i-apb1-mux-clk";
> @@ -145,15 +138,11 @@
>  
>  		apb1_gates: apb1_gates at 01c2006c {
>  			#clock-cells = <1>;
> -			compatible = "allwinner,sun4i-apb1-gates-clk";
> +			compatible = "allwinner,sun5i-a13-apb1-gates-clk";
>  			reg = <0x01c2006c 0x4>;
>  			clocks = <&apb1>;
>  			clock-output-names = "apb1_i2c0", "apb1_i2c1",
> -				"apb1_i2c2", "apb1_can", "apb1_scr",
> -				"apb1_ps20", "apb1_ps21", "apb1_uart0",
> -				"apb1_uart1", "apb1_uart2", "apb1_uart3",
> -				"apb1_uart4", "apb1_uart5", "apb1_uart6",
> -				"apb1_uart7";
> +				"apb1_i2c2", "apb1_uart1", "apb1_uart3";
>  		};
>  	};
>  
> 

Thanks,

Emilio


From laurent.pinchart at ideasonboard.com  Tue Apr 30 07:42:50 2013
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Tue, 30 Apr 2013 13:42:50 +0200
Subject: [PATCH V2] video: implement a simple framebuffer driver
In-Reply-To: <201304301228.42245.arnd@arndb.de>
References: <1365043183-28905-1-git-send-email-swarren@wwwdotorg.org>
 <517F7245.2050606@iki.fi> <201304301228.42245.arnd@arndb.de>
Message-ID: <1547536.Us4pVspuI2@avalon>

On Tuesday 30 April 2013 12:28:42 Arnd Bergmann wrote:
> On Tuesday 30 April 2013, Tomi Valkeinen wrote:
> > The bootloader would init the display hardware, the bootfb would give an
> > early /dev/fb0 for the kernel and userspace, and when the real display
> > driver is loaded, the bootfb would be unbound and the real driver would
> > take over.

This could be done with a KMS driver as well ;-)

> I think that's a great idea. What I'm not sure about is how that
> infrastructure for switching frame buffers would work and how hard it's to
> write.

-- 
Regards,

Laurent Pinchart



From dave.martin at linaro.org  Tue Apr 30 07:43:11 2013
From: dave.martin at linaro.org (Dave Martin)
Date: Tue, 30 Apr 2013 12:43:11 +0100
Subject: Latest build results - errors/warnings - lots of them
In-Reply-To: <201304301304.20650.arnd@arndb.de>
References: <20130430081739.GP14496@n2100.arm.linux.org.uk>
 <201304301304.20650.arnd@arndb.de>
Message-ID: <20130430114229.GA2439@linaro.org>

On Tue, Apr 30, 2013 at 01:04:20PM +0200, Arnd Bergmann wrote:
> On Tuesday 30 April 2013, Russell King - ARM Linux wrote:
> > Latest nightly build of 3.9+my for-next+arm-soc's for-next results in a
> > great load of new warnings and errors.  arch/arm/common/mcpm_head.S,
> > arch/arm/common/mcpm_platsmp.c, arch/arm/common/vlock.S are the biggest
> > source of errors.

[...]
 
> >arch/arm/common/mcpm_head.S:39: Error: selected processor does not support ARM mode `ubfx r9,r0,#0,#8'
> >arch/arm/common/mcpm_head.S:40: Error: selected processor does not support ARM mode `ubfx r10,r0,#8,#8'
> >arch/arm/common/mcpm_head.S:100: Error: selected processor does not support ARM mode `dmb'
> >arch/arm/common/mcpm_head.S:115: Error: selected processor does not support ARM mode `dmb'
> >arch/arm/common/mcpm_head.S:127: Error: selected processor does not support ARM mode `dmb'
> >arch/arm/common/mcpm_head.S:131: Error: selected processor does not support ARM mode `dmb'
> >arch/arm/common/mcpm_head.S:138: Error: selected processor does not support ARM mode `dsb'
> >arch/arm/common/mcpm_head.S:152: Error: selected processor does not support ARM mode `dmb'
> >arch/arm/common/mcpm_head.S:161: Error: selected processor does not support ARM mode `dmb'
> >arch/arm/common/mcpm_head.S:175: Error: selected processor does not support ARM mode `dmb'
> >arch/arm/common/vlock.S:62: Error: selected processor does not support ARM mode `dmb'
> >arch/arm/common/vlock.S:72: Error: selected processor does not support ARM mode `dmb'
> >arch/arm/common/vlock.S:72: Error: selected processor does not support ARM mode `dsb'
> >arch/arm/common/vlock.S:89: Error: selected processor does not support ARM mode `dmb'
> >arch/arm/common/vlock.S:95: Error: selected processor does not support ARM mode `dmb'
> >arch/arm/common/vlock.S:95: Error: selected processor does not support ARM mode `dsb'
> >arch/arm/common/vlock.S:102: Error: selected processor does not support ARM mode `dmb'
> >arch/arm/common/vlock.S:105: Error: selected processor does not support ARM mode `dsb'
> 
> Right, the problem here is that the code was never tested with an ARMv6+ARMv7 config.
> We can either fix it up by adding
> 
> 	.arch	armv7-a
> 
> in the assembly files, or by doing the same in the Makefile:
> 
> AFLAGS_vlock.S += -march=armv7-a
> AFLAGS_mcpm_head.S += -march=armv7-a


Hmmm, this code was tested with ARCH_MULTIPLATFORM, but it looks like
no v6 boards were configured in when testing that...


Assuming people are OK with the Makefile route, here's a patch for that,
build-tested with a v6+v7 ARCH_MULTIPLATFORM config.

Cheers
---Dave


>From 193f254689beaa1612d29bcc5ba004a933b37d95 Mon Sep 17 00:00:00 2001
From: Dave Martin <dave.martin at linaro.org>
Date: Tue, 30 Apr 2013 12:25:04 +0100
Subject: [PATCH 1/3] ARM: mcpm: Add explicit AFLAGS to support v6/v7
 multiplatform kernels

The full mcpm layer is not likely to be relevant to v6 based platforms,
so a multiplatform kernel won't use that code if booted on v6 hardware.

This patch modifies the AFLAGS for affected mcpm .S files to specify
armv7-a explicitly for that code.

Signed-off-by: Dave Martin <dave.martin at linaro.org>
---
 arch/arm/common/Makefile |    2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/common/Makefile b/arch/arm/common/Makefile
index 546a932..d65a0a8 100644
--- a/arch/arm/common/Makefile
+++ b/arch/arm/common/Makefile
@@ -12,6 +12,8 @@ obj-$(CONFIG_SHARP_SCOOP)	+= scoop.o
 obj-$(CONFIG_PCI_HOST_ITE8152)  += it8152.o
 obj-$(CONFIG_ARM_TIMER_SP804)	+= timer-sp.o
 obj-$(CONFIG_MCPM)		+= mcpm_head.o mcpm_entry.o mcpm_platsmp.o vlock.o
+AFLAGS_mcpm_head.o		:= -march=armv7-a
+AFLAGS_vlock.o			:= -march=armv7-a
 CFLAGS_REMOVE_mcpm_entry.o	= -pg
 obj-$(CONFIG_FIQ_GLUE)		+= fiq_glue.o fiq_glue_setup.o
 obj-$(CONFIG_FIQ_DEBUGGER)	+= fiq_debugger.o
-- 
1.7.9.5



From tomi.valkeinen at ti.com  Tue Apr 30 07:46:20 2013
From: tomi.valkeinen at ti.com (Tomi Valkeinen)
Date: Tue, 30 Apr 2013 14:46:20 +0300
Subject: [PATCH V2] video: implement a simple framebuffer driver
In-Reply-To: <201304301228.42245.arnd@arndb.de>
References: <1365043183-28905-1-git-send-email-swarren@wwwdotorg.org>
 <517F7245.2050606@iki.fi> <201304301228.42245.arnd@arndb.de>
Message-ID: <517FAF0C.1060901@ti.com>

On 04/30/2013 01:28 PM, Arnd Bergmann wrote:
> On Tuesday 30 April 2013, Tomi Valkeinen wrote:
> 
>> The bootloader would init the display hardware, the bootfb would give an
>> early /dev/fb0 for the kernel and userspace, and when the real display
>> driver is loaded, the bootfb would be unbound and the real driver would
>> take over.
> 
> I think that's a great idea. What I'm not sure about is how that
> infrastructure for switching frame buffers would work and how hard
> it's to write.

I don't have any clear ideas either, just some vague ones:

I think the simplest option would be for the userspace to just unbind
the fbcon, then the bootfb device/driver, and then load the real driver.
I don't see why that would not work, but it's far from optimal. The fb
memory would become unallocated for a while, and the user could see
garbage on the display.

A proper hand-over would be more complex. So, I don't know... Maybe the
bootfb driver could have custom API for this. When the real driver is
loaded, it'd call the bootfb to get the fb memory, and to unbind the bootfb.

Would there be issues with passing the fb memory? If one uses dma_alloc,
the device is linked to the allocated memory, so I presume you can't
just pass that around and remove the original device.

Then again, dma_alloc would not be used here, as bootfb needs the fb
memory from a particular location, so I guess bootmem is needed here.

I think it would be reasonable to have a restriction of only a single
bootfb instance, so one could just use static global variables/funcs to
manage the hand-over.

All this, of course, presumes that nobody else than fbcon is using the
fb. But I think it's also a reasonable restriction that the fb device is
not used (mmapped) by anyone.

 Tomi


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130430/e4dd2bce/attachment-0001.sig>

From tomi.valkeinen at ti.com  Tue Apr 30 07:48:08 2013
From: tomi.valkeinen at ti.com (Tomi Valkeinen)
Date: Tue, 30 Apr 2013 14:48:08 +0300
Subject: [PATCH V2] video: implement a simple framebuffer driver
In-Reply-To: <1547536.Us4pVspuI2@avalon>
References: <1365043183-28905-1-git-send-email-swarren@wwwdotorg.org>
 <517F7245.2050606@iki.fi> <201304301228.42245.arnd@arndb.de>
 <1547536.Us4pVspuI2@avalon>
Message-ID: <517FAF78.1010306@ti.com>

On 04/30/2013 02:42 PM, Laurent Pinchart wrote:
> On Tuesday 30 April 2013 12:28:42 Arnd Bergmann wrote:
>> On Tuesday 30 April 2013, Tomi Valkeinen wrote:
>>> The bootloader would init the display hardware, the bootfb would give an
>>> early /dev/fb0 for the kernel and userspace, and when the real display
>>> driver is loaded, the bootfb would be unbound and the real driver would
>>> take over.
> 
> This could be done with a KMS driver as well ;-)

Right, I forgot to mention that. I had it in mind also =).

DRM has the same problem as fbdev with multi-arch and lots of display
and panel drivers.

Probably the same bootfb could be used for DRM also. Or do you see any
benefit of having a "bootkms" driver, or such?

 Tomi


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130430/8b4c0b7f/attachment.sig>

From laurent.pinchart at ideasonboard.com  Tue Apr 30 07:49:28 2013
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Tue, 30 Apr 2013 13:49:28 +0200
Subject: [PATCH V2] video: implement a simple framebuffer driver
In-Reply-To: <517FAF78.1010306@ti.com>
References: <1365043183-28905-1-git-send-email-swarren@wwwdotorg.org>
 <1547536.Us4pVspuI2@avalon> <517FAF78.1010306@ti.com>
Message-ID: <124304591.tbnLlR41q2@avalon>

On Tuesday 30 April 2013 14:48:08 Tomi Valkeinen wrote:
> On 04/30/2013 02:42 PM, Laurent Pinchart wrote:
> > On Tuesday 30 April 2013 12:28:42 Arnd Bergmann wrote:
> >> On Tuesday 30 April 2013, Tomi Valkeinen wrote:
> >>> The bootloader would init the display hardware, the bootfb would give an
> >>> early /dev/fb0 for the kernel and userspace, and when the real display
> >>> driver is loaded, the bootfb would be unbound and the real driver would
> >>> take over.
> > 
> > This could be done with a KMS driver as well ;-)
> 
> Right, I forgot to mention that. I had it in mind also =).
> 
> DRM has the same problem as fbdev with multi-arch and lots of display
> and panel drivers.
> 
> Probably the same bootfb could be used for DRM also. Or do you see any
> benefit of having a "bootkms" driver, or such?

As part of the (long term) effort to deprecate fbdev I would of course prefer 
a bootkms driver. The KMS fbdev emulation layer would provide fbdev 
compatibility for free during the transition.

-- 
Regards,

Laurent Pinchart
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130430/297e1336/attachment.sig>

From arnd at arndb.de  Tue Apr 30 07:54:50 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 30 Apr 2013 13:54:50 +0200
Subject: Latest build results - errors/warnings - lots of them
In-Reply-To: <20130430114229.GA2439@linaro.org>
References: <20130430081739.GP14496@n2100.arm.linux.org.uk>
 <201304301304.20650.arnd@arndb.de> <20130430114229.GA2439@linaro.org>
Message-ID: <201304301354.50210.arnd@arndb.de>

On Tuesday 30 April 2013, Dave Martin wrote:
> From 193f254689beaa1612d29bcc5ba004a933b37d95 Mon Sep 17 00:00:00 2001
> From: Dave Martin <dave.martin at linaro.org>
> Date: Tue, 30 Apr 2013 12:25:04 +0100
> Subject: [PATCH 1/3] ARM: mcpm: Add explicit AFLAGS to support v6/v7
>  multiplatform kernels
> 
> The full mcpm layer is not likely to be relevant to v6 based platforms,
> so a multiplatform kernel won't use that code if booted on v6 hardware.
> 
> This patch modifies the AFLAGS for affected mcpm .S files to specify
> armv7-a explicitly for that code.
> 
> Signed-off-by: Dave Martin <dave.martin at linaro.org>

Acked-by: Arnd Bergmann <arnd at arndb.de>


From stefano.stabellini at eu.citrix.com  Tue Apr 30 07:58:40 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Tue, 30 Apr 2013 12:58:40 +0100
Subject: linux-next build error (at91) - use of bool in mach/arch.h
In-Reply-To: <CAMuHMdXYaDHYq7CG8ftP+yyF18pMx8qZrvM3AUTAXk+tUruNcA@mail.gmail.com>
References: <517F8FF4.3050901@atmel.com>
 <CAMuHMdXYaDHYq7CG8ftP+yyF18pMx8qZrvM3AUTAXk+tUruNcA@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1304301257200.5398@kaball.uk.xensource.com>

On Tue, 30 Apr 2013, Geert Uytterhoeven wrote:
> On Tue, Apr 30, 2013 at 11:33 AM, Nicolas Ferre <nicolas.ferre at atmel.com> wrote:
> > So, I am wondering if the best correction is to add the types.h header file
> > in the asm/mach/arch.h file, like this:
> >
> > --- a/arch/arm/include/asm/mach/arch.h
> > +++ b/arch/arm/include/asm/mach/arch.h
> > @@ -8,6 +8,8 @@
> >   * published by the Free Software Foundation.
> >   */
> >
> > +#include <linux/types.h>
> > +
> >  #ifndef __ASSEMBLY__
> >
> >  struct tag;
> >
> > or if a better option would be to re-arrange the include directives in
> > various at91xxx_devices.c files?
> 
> Include files should be self-contained, so asm/mach/arch.h is the right place.

Nicolas,
are you happy to come up with a proper patch to fix the issue?


From stano at meduna.org  Tue Apr 30 08:13:07 2013
From: stano at meduna.org (Stanislav Meduna)
Date: Tue, 30 Apr 2013 14:13:07 +0200
Subject: Need help to measure and tune the latency in Linux RT
In-Reply-To: <20130430111021.GC31290@titan.lakedaemon.net>
References: <CALJd4cbfqRFiGHshv8A+0A8kFo_qW=rvREsdgj3jQ=-0Rix0-g@mail.gmail.com>
 <20130430111021.GC31290@titan.lakedaemon.net>
Message-ID: <517FB553.3000001@meduna.org>

>> This critical thread is at RR priority 50.

Try to put it higher than the irq thread handling your HD hardware.
I've even encountered hardware where I had to put the ATA thread
in the SHED_OTHER domain - see [1] for the thread.

>> I used a HR timer thread with RR pri 55 to wakeup the critical thread
>> every 1 milli sec to do the job.

Which prio is the ksoftirqd running at? The HRTIMER interrupts are
routed through it so it also has to be high enough.

I got burned with this myself [2]

Regards
                                     Stano

[1] http://www.spinics.net/lists/linux-rt-users/msg08711.html
[2] http://www.spinics.net/lists/linux-rt-users/msg08745.html



From nicolas.ferre at atmel.com  Tue Apr 30 08:38:07 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Tue, 30 Apr 2013 14:38:07 +0200
Subject: [PATCH] ARM: add the "bool" type definition to asm/mach/arch.h
In-Reply-To: <517F8FF4.3050901@atmel.com>
References: <517F8FF4.3050901@atmel.com>
Message-ID: <1367325487-8366-1-git-send-email-nicolas.ferre@atmel.com>

Addition of boolean field to machine_desc structure in commit
4dbfa9a25367cfa91aec0e56d75a6905d3242cd3 (ARM: Enable selection of
SMP operations at boot time) was triggering compilation errors like:

  CC      arch/arm/mach-at91/at91sam9260_devices.o
In file included from arch/arm/mach-at91/at91sam9260_devices.c:12:0:
arch/arm/include/asm/mach/arch.h:46:2: error: expected specifier-qualifier-list before "bool"

So, we add the definition of "bool" by including the linux/types.h
file to asm/mach/arch.h and make it self-contained.

Signed-off-by: Nicolas Ferre <nicolas.ferre at atmel.com>
---
 arch/arm/include/asm/mach/arch.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/include/asm/mach/arch.h b/arch/arm/include/asm/mach/arch.h
index af8c54c..75bf079 100644
--- a/arch/arm/include/asm/mach/arch.h
+++ b/arch/arm/include/asm/mach/arch.h
@@ -8,6 +8,8 @@
  * published by the Free Software Foundation.
  */
 
+#include <linux/types.h>
+
 #ifndef __ASSEMBLY__
 
 struct tag;
-- 
1.8.0



From nicolas.ferre at atmel.com  Tue Apr 30 08:40:27 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Tue, 30 Apr 2013 14:40:27 +0200
Subject: linux-next build error (at91) - use of bool in mach/arch.h
In-Reply-To: <alpine.DEB.2.02.1304301257200.5398@kaball.uk.xensource.com>
References: <517F8FF4.3050901@atmel.com>
 <CAMuHMdXYaDHYq7CG8ftP+yyF18pMx8qZrvM3AUTAXk+tUruNcA@mail.gmail.com>
 <alpine.DEB.2.02.1304301257200.5398@kaball.uk.xensource.com>
Message-ID: <517FBBBB.6060003@atmel.com>

On 04/30/2013 01:58 PM, Stefano Stabellini :
> On Tue, 30 Apr 2013, Geert Uytterhoeven wrote:
>> On Tue, Apr 30, 2013 at 11:33 AM, Nicolas Ferre <nicolas.ferre at atmel.com> wrote:
>>> So, I am wondering if the best correction is to add the types.h header file
>>> in the asm/mach/arch.h file, like this:
>>>
>>> --- a/arch/arm/include/asm/mach/arch.h
>>> +++ b/arch/arm/include/asm/mach/arch.h
>>> @@ -8,6 +8,8 @@
>>>   * published by the Free Software Foundation.
>>>   */
>>>
>>> +#include <linux/types.h>
>>> +
>>>  #ifndef __ASSEMBLY__
>>>
>>>  struct tag;
>>>
>>> or if a better option would be to re-arrange the include directives in
>>> various at91xxx_devices.c files?
>>
>> Include files should be self-contained, so asm/mach/arch.h is the right place.
> 
> Nicolas,
> are you happy to come up with a proper patch to fix the issue?

Yep, sent now.

Bye,
-- 
Nicolas Ferre


From fabio.baltieri at linaro.org  Tue Apr 30 08:45:06 2013
From: fabio.baltieri at linaro.org (Fabio Baltieri)
Date: Tue, 30 Apr 2013 14:45:06 +0200
Subject: [PATCH] clk: ux500: clk-sysctrl: handle clocks with no parents
Message-ID: <1367325906-23045-1-git-send-email-fabio.baltieri@linaro.org>

Fix clk_reg_sysctrl() to set main clock registers of new struct
clk_sysctrl even if the registered clock has no parents.

This fixes an issue where "ulpclk" was registered with all clk->reg_*
fields uninitialized, causing a -EINVAL error from clk_prepare().

Cc: Ulf Hansson <ulf.hansson at linaro.org>
Signed-off-by: Fabio Baltieri <fabio.baltieri at linaro.org>
---
 drivers/clk/ux500/clk-sysctrl.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/ux500/clk-sysctrl.c b/drivers/clk/ux500/clk-sysctrl.c
index bc7e9bd..e364c9d 100644
--- a/drivers/clk/ux500/clk-sysctrl.c
+++ b/drivers/clk/ux500/clk-sysctrl.c
@@ -145,7 +145,13 @@ static struct clk *clk_reg_sysctrl(struct device *dev,
 		return ERR_PTR(-ENOMEM);
 	}
 
-	for (i = 0; i < num_parents; i++) {
+	/* set main clock registers */
+	clk->reg_sel[0] = reg_sel[0];
+	clk->reg_bits[0] = reg_bits[0];
+	clk->reg_mask[0] = reg_mask[0];
+
+	/* handle clocks with more than one parent */
+	for (i = 1; i < num_parents; i++) {
 		clk->reg_sel[i] = reg_sel[i];
 		clk->reg_bits[i] = reg_bits[i];
 		clk->reg_mask[i] = reg_mask[i];
-- 
1.8.2



From rickard.andersson at stericsson.com  Tue Apr 30 08:55:40 2013
From: rickard.andersson at stericsson.com (Rickard Andersson)
Date: Tue, 30 Apr 2013 14:55:40 +0200
Subject: [PATCH V2 03/12] PM / Domains: Add on-off notifiers
In-Reply-To: <CACRpkdb+JrnrQgzZ5xdtFDubexNRm2WsrLXv+5zfjN1wdowaNg@mail.gmail.com>
References: <1364487098-10319-1-git-send-email-rickard.andersson@stericsson.com>	<1364487098-10319-4-git-send-email-rickard.andersson@stericsson.com>	<3261022.s2M99fPNjC@vostro.rjw.lan>	<51767DE2.7050203@stericsson.com>
 <CACRpkdb+JrnrQgzZ5xdtFDubexNRm2WsrLXv+5zfjN1wdowaNg@mail.gmail.com>
Message-ID: <517FBF4C.6090806@stericsson.com>

On 04/29/2013 02:14 PM, Linus Walleij wrote:
> On Tue, Apr 23, 2013 at 2:26 PM, Rickard Andersson
> <rickard.andersson at stericsson.com>  wrote:
>> On 03/31/2013 12:17 AM, Rafael J. Wysocki wrote:
>>> On Thursday, March 28, 2013 05:11:29 PM Rickard Andersson wrote:
>>>> I believe notifiers are the best solution to the problem of
>>>> restoring context early when waking up after sleep.
>>> I don't.
>> Some motivation would be good.
> (...)
>>> Well, quite frankly, it is hard to say what problem this is supposed to
>>> address from your description.  Care to give some more details?
>> The problem is that some hardware blocks needs to be restored as early as
>> possible after leaving the U8500 CPU coupled sleep state ApSleep (APE power
>> domain being off).
> (APE = Application Processor Environment, on embedded)
>
> I just have this vague feeling that this is one of those embedded SoC
> vs desktop things where worlds collide.
>
> Isn't it so that on common x86 (desktop, server, laptop) the context of
> the system is saved by some BIOS/ACPI call, and then the ROM
> takes you back up with all devices put back into context?
>
> On embedded SoC's we don't have this, all states in the hardware
> has to be saved and restored with kernel code.
>
> Then there is a question about whether this shall be done centrally
> (there is one piece of code that knows all volatile registers of all
> hardware blocks in the system) which is close to what the desktop
> BIOS may do, or whether you want to do this in a distributed manner,
> so that each driver saves and restores the context of it's particular
> hardware.
>
The advantage with using the distributed approach is that all knowledge 
of a certain hardware block can be handled in one place, the driver. 
Having all knowledge in one place is a standard software design pattern.

Most drivers in the APE domain will be fine using runtime pm, but a few 
needs their context (i.e. registers) to be restored directly when 
leaving a sleep state where the APE power domain has been off. For 
example the following hardware blocks: APE clocks, ICN (main 
interconnect bus) and TPIU (Trace Port Interface Unit).
Using the TPIU block as an example: tracing with debugger (using TPIU 
block) needs to be active (context restored) directly after sleep in 
order to be able to record the execution also after waking up from 
sleep. If the TPIU context is not restored after waking up from sleep 
then the debuggers recording of the execution will also stop after 
waking up from sleep which is not a good thing when looking for 
difficult errors using a debugger.

Rafael: Can you please share your view?

Thanks in advance!
/Rickard



From linus.walleij at linaro.org  Tue Apr 30 09:01:56 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Tue, 30 Apr 2013 15:01:56 +0200
Subject: [PATCH] mmc: mmci: Allow MMCI to request channels with
 information acquired from DT
In-Reply-To: <1366801122-13302-1-git-send-email-lee.jones@linaro.org>
References: <1366801122-13302-1-git-send-email-lee.jones@linaro.org>
Message-ID: <CACRpkdY+WtjnJGhVOCk3OZW+Z1maO0ru+Fc2wPR7OzWe+RMuJg@mail.gmail.com>

On Wed, Apr 24, 2013 at 12:58 PM, Lee Jones <lee.jones at linaro.org> wrote:

> Currently, if DMA information isn't passed from platform data, then DMA
> will not be used. This patch allows DMA information obtained though Device
> Tree to be used as well.
>
> Cc: Russell King <linux at arm.linux.org.uk>
> Cc: Chris Ball <cjb at laptop.org>
> Cc: linux-mmc at vger.kernel.org
> Signed-off-by: Lee Jones <lee.jones at linaro.org>
(...)

I tried to test this patch, but:
  CC      drivers/mmc/host/mmci.o
/drivers/mmc/host/mmci.c: In function 'mmci_dma_setup':
/drivers/mmc/host/mmci.c:307:51: error: 'dev' undeclared (first use in
this function)
/drivers/mmc/host/mmci.c:307:51: note: each undeclared identifier is
reported only once for each function it appears in
make[5]: *** [drivers/mmc/host/mmci.o] Error 1
make[4]: *** [drivers/mmc/host] Error 2
make[3]: *** [drivers/mmc] Error 2

Due to:

> @@ -304,10 +304,8 @@ static void mmci_dma_setup(struct mmci_host *host)
>         const char *rxname, *txname;
>         dma_cap_mask_t mask;
>
> -       if (!plat || !plat->dma_filter) {
> -               dev_info(mmc_dev(host->mmc), "no DMA platform data\n");
> -               return;
> -       }
> +       host->dma_rx_channel = dma_request_slave_channel(dev, "rx");
> +       host->dma_tx_channel = dma_request_slave_channel(dev, "tx");

There is no "dev" here.

Yours,
Linus Walleij


From cb at sgoc.de  Tue Apr 30 09:06:03 2013
From: cb at sgoc.de (Christoph G. Baumann)
Date: Tue, 30 Apr 2013 15:06:03 +0200 (CEST)
Subject: Driver for OCOTP with write support for i.MX23/28
Message-ID: <179156480.94949.1367327163761.open-xchange@email.1und1.de>

Hello,

currently I'm porting the OCOTP driver from Freescale for the i.MX23/28 to
mainline.
I removed the code for i.MX50 as this platform is AFAIK currently not supported
and I can't test it anyway.
So far checkpatch.pl is pleased with it. Write support also works.
But there is one flaw: the creation of the sysfs nodes triggers some error logs
(see attachment).

So I have two questions:
1. How can I fix these error/bug messages?
2. Is this the right list to post the patch?


Regards
Christoph
-------------- next part --------------
[    2.140000] BUG: key c7a3a80c not in .data!
[    2.150000] ------------[ cut here ]------------
[    2.150000] WARNING: at kernel/lockdep.c:2986 sysfs_add_file_mode+0x84/0xe4()
[    2.160000] [<c0013708>] (unwind_backtrace+0x0/0xf0) from [<c001c0bc>] (warn_slowpath_common+0x48/0x60)
[    2.170000] [<c001c0bc>] (warn_slowpath_common+0x48/0x60) from [<c001c19c>] (warn_slowpath_null+0x1c/0x24)
[    2.180000] [<c001c19c>] (warn_slowpath_null+0x1c/0x24) from [<c0130114>] (sysfs_add_file_mode+0x84/0xe4)
[    2.190000] [<c0130114>] (sysfs_add_file_mode+0x84/0xe4) from [<c0132d34>] (create_files+0x74/0xc4)
[    2.200000] [<c0132d34>] (create_files+0x74/0xc4) from [<c0132e2c>] (internal_create_group+0xa8/0x170)
[    2.210000] [<c0132e2c>] (internal_create_group+0xa8/0x170) from [<c03366a8>] (fsl_otp_probe+0x4c/0x9c)
[    2.220000] [<c03366a8>] (fsl_otp_probe+0x4c/0x9c) from [<c028da3c>] (platform_drv_probe+0x14/0x18)
[    2.220000] [<c028da3c>] (platform_drv_probe+0x14/0x18) from [<c028cb40>] (really_probe+0x68/0x1fc)
[    2.230000] [<c028cb40>] (really_probe+0x68/0x1fc) from [<c028cd8c>] (__driver_attach+0x94/0x98)
[    2.240000] [<c028cd8c>] (__driver_attach+0x94/0x98) from [<c028b2bc>] (bus_for_each_dev+0x54/0x7c)
[    2.250000] [<c028b2bc>] (bus_for_each_dev+0x54/0x7c) from [<c028baf0>] (bus_add_driver+0x174/0x244)
[    2.260000] [<c028baf0>] (bus_add_driver+0x174/0x244) from [<c028d138>] (driver_register+0x78/0x144)
[    2.270000] [<c028d138>] (driver_register+0x78/0x144) from [<c0520838>] (do_one_initcall+0x94/0x170)
[    2.280000] [<c0520838>] (do_one_initcall+0x94/0x170) from [<c05209ac>] (do_basic_setup+0x98/0xcc)
[    2.290000] [<c05209ac>] (do_basic_setup+0x98/0xcc) from [<c0520a8c>] (kernel_init_freeable+0xac/0x144)
[    2.300000] [<c0520a8c>] (kernel_init_freeable+0xac/0x144) from [<c03dc6c8>] (kernel_init+0x8/0x104)
[    2.310000] [<c03dc6c8>] (kernel_init+0x8/0x104) from [<c000e868>] (ret_from_fork+0x14/0x2c)
[    2.320000] ---[ end trace e4af0d3a4a3a4b51 ]---
[    2.320000] BUG: key c7a3a828 not in .data!
[    2.330000] BUG: key c7a3a844 not in .data!
[    2.330000] BUG: key c7a3a860 not in .data!
[    2.330000] BUG: key c7a3a87c not in .data!
[    2.340000] BUG: key c7a3a898 not in .data!
[    2.340000] BUG: key c7a3a8b4 not in .data!
[    2.350000] BUG: key c7a3a8d0 not in .data!
[    2.350000] BUG: key c7a3a8ec not in .data!
[    2.360000] BUG: key c7a3a908 not in .data!
[    2.360000] BUG: key c7a3a924 not in .data!
[    2.360000] BUG: key c7a3a940 not in .data!
[    2.370000] BUG: key c7a3a95c not in .data!
[    2.370000] BUG: key c7a3a978 not in .data!
[    2.380000] BUG: key c7a3a994 not in .data!
[    2.380000] BUG: key c7a3a9b0 not in .data!
[    2.390000] BUG: key c7a3a9cc not in .data!
[    2.390000] BUG: key c7a3a9e8 not in .data!
[    2.390000] BUG: key c7a3aa04 not in .data!
[    2.400000] BUG: key c7a3aa20 not in .data!
[    2.400000] BUG: key c7a3aa3c not in .data!
[    2.410000] BUG: key c7a3aa58 not in .data!
[    2.410000] BUG: key c7a3aa74 not in .data!
[    2.420000] BUG: key c7a3aa90 not in .data!
[    2.420000] BUG: key c7a3aaac not in .data!
[    2.420000] BUG: key c7a3aac8 not in .data!
[    2.430000] BUG: key c7a3aae4 not in .data!
[    2.430000] BUG: key c7a3ab00 not in .data!
[    2.440000] BUG: key c7a3ab1c not in .data!
[    2.440000] BUG: key c7a3ab38 not in .data!
[    2.450000] BUG: key c7a3ab54 not in .data!
[    2.450000] BUG: key c7a3ab70 not in .data!
[    2.450000] BUG: key c7a3ab8c not in .data!
[    2.460000] BUG: key c7a3aba8 not in .data!
[    2.460000] BUG: key c7a3abc4 not in .data!
[    2.470000] BUG: key c7a3abe0 not in .data!
[    2.470000] BUG: key c7a3abfc not in .data!
[    2.480000] BUG: key c7a3ac18 not in .data!
[    2.480000] BUG: key c7a3ac34 not in .data!
[    2.480000] BUG: key c7a3ac50 not in .data!

From lee.jones at linaro.org  Tue Apr 30 09:12:15 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Tue, 30 Apr 2013 14:12:15 +0100
Subject: [PATCH] mmc: mmci: Allow MMCI to request channels with
 information acquired from DT
In-Reply-To: <CACRpkdY+WtjnJGhVOCk3OZW+Z1maO0ru+Fc2wPR7OzWe+RMuJg@mail.gmail.com>
References: <1366801122-13302-1-git-send-email-lee.jones@linaro.org>
 <CACRpkdY+WtjnJGhVOCk3OZW+Z1maO0ru+Fc2wPR7OzWe+RMuJg@mail.gmail.com>
Message-ID: <20130430131215.GA25256@gmail.com>

On Tue, 30 Apr 2013, Linus Walleij wrote:

> On Wed, Apr 24, 2013 at 12:58 PM, Lee Jones <lee.jones at linaro.org> wrote:
> 
> > Currently, if DMA information isn't passed from platform data, then DMA
> > will not be used. This patch allows DMA information obtained though Device
> > Tree to be used as well.
> >
> > Cc: Russell King <linux at arm.linux.org.uk>
> > Cc: Chris Ball <cjb at laptop.org>
> > Cc: linux-mmc at vger.kernel.org
> > Signed-off-by: Lee Jones <lee.jones at linaro.org>
> (...)
> 
> I tried to test this patch, but:
>   CC      drivers/mmc/host/mmci.o
> /drivers/mmc/host/mmci.c: In function 'mmci_dma_setup':
> /drivers/mmc/host/mmci.c:307:51: error: 'dev' undeclared (first use in
> this function)
> /drivers/mmc/host/mmci.c:307:51: note: each undeclared identifier is
> reported only once for each function it appears in
> make[5]: *** [drivers/mmc/host/mmci.o] Error 1
> make[4]: *** [drivers/mmc/host] Error 2
> make[3]: *** [drivers/mmc] Error 2
> 
> Due to:
> 
> > @@ -304,10 +304,8 @@ static void mmci_dma_setup(struct mmci_host *host)
> >         const char *rxname, *txname;
> >         dma_cap_mask_t mask;
> >
> > -       if (!plat || !plat->dma_filter) {
> > -               dev_info(mmc_dev(host->mmc), "no DMA platform data\n");
> > -               return;
> > -       }
> > +       host->dma_rx_channel = dma_request_slave_channel(dev, "rx");
> > +       host->dma_tx_channel = dma_request_slave_channel(dev, "tx");
> 
> There is no "dev" here.

You've missed v2 again dude.

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From ashok.vinu at gmail.com  Tue Apr 30 09:17:05 2013
From: ashok.vinu at gmail.com (Ashoka K)
Date: Tue, 30 Apr 2013 18:47:05 +0530
Subject: Need help to measure and tune the latency in Linux RT
In-Reply-To: <517FB553.3000001@meduna.org>
References: <CALJd4cbfqRFiGHshv8A+0A8kFo_qW=rvREsdgj3jQ=-0Rix0-g@mail.gmail.com>
 <20130430111021.GC31290@titan.lakedaemon.net>
 <517FB553.3000001@meduna.org>
Message-ID: <CALJd4cbEUMpLhjbFMELbGbXZ6WuAzaychjtt2uyv8Mvwi74xHQ@mail.gmail.com>

Thanks for all the replies.
I am stuck with this issue for more tan a month. Explained this in
more detail at:

http://stackoverflow.com/questions/15805231/need-to-improve-the-linux-performance-for-embedded-system

But with no response from anyone.

I use PREEMPT patch for 2.6.33 vanilla kernel.

I have pasted all the processes running on my system:

  PID USER       VSZ STAT COMMAND
    1 root      3192 S    init
    2 root         0 SW   [kthreadd]
    3 root         0 SW   [ksoftirqd/0]
    4 root         0 SW   [events/0]
    5 root         0 SW   [khelper]
    8 root         0 SW   [async/mgr]
   84 root         0 SW   [sync_supers]
   86 root         0 SW   [bdi-default]
   88 root         0 SW   [kblockd/0]
   91 root         0 SW   [omap2_mcspi]
  116 root         0 SW   [rpciod/0]
  123 root         0 SW   [kswapd0]
  124 root         0 SW   [aio/0]
  125 root         0 SW   [nfsiod]
  126 root         0 SW<  [kslowd001]
  127 root         0 SW<  [kslowd000]
  128 root         0 SW   [crypto/0]
  267 root         0 SW   [mtdblockd]
  351 root         0 SWN  [jffs2_gcd_mtd8]
  359 root      3192 S    /sbin/syslogd
  361 root      3192 S    /usr/sbin/telnetd
  364 root      1996 S    vsftpd
  410 root     43844 S   my_appl
  416 root     56412 S <  my_appl
  417 root     84804 S    my_appl
  418 root     43844 S    my_appl
  419 root     84824 S    my_appl
  430 root     46552 S <  my_appl

The process my_appl is my application processes.

the ksoftirq is running with SCHED_OTHER.

$ chrt -p 3
pid 3's current scheduling policy: SCHED_OTHER
pid 3's current scheduling priority: 0

I will test by changing ksoftirq priority to see how it works.

Regards
Ashoka.  K


On Tue, Apr 30, 2013 at 5:43 PM, Stanislav Meduna <stano at meduna.org> wrote:
>>> This critical thread is at RR priority 50.
>
> Try to put it higher than the irq thread handling your HD hardware.
> I've even encountered hardware where I had to put the ATA thread
> in the SHED_OTHER domain - see [1] for the thread.
>
>>> I used a HR timer thread with RR pri 55 to wakeup the critical thread
>>> every 1 milli sec to do the job.
>
> Which prio is the ksoftirqd running at? The HRTIMER interrupts are
> routed through it so it also has to be high enough.
>
> I got burned with this myself [2]
>
> Regards
>                                      Stano
>
> [1] http://www.spinics.net/lists/linux-rt-users/msg08711.html
> [2] http://www.spinics.net/lists/linux-rt-users/msg08745.html
>


From jon-hunter at ti.com  Tue Apr 30 09:53:52 2013
From: jon-hunter at ti.com (Jon Hunter)
Date: Tue, 30 Apr 2013 08:53:52 -0500
Subject: [GIT PULL] ARM: OMAP2+: GPMC fixes for v3.10
Message-ID: <517FCCF0.1030105@ti.com>

The following changes since commit aecb65a34a780cd07fbaa652cc5d640f13f3ed5f:

  Merge branch 'omap-gpmc-for-v3.10-take2' of git://github.com/jonhunter/linux into omap-for-v3.10/gpmc (2013-04-04 11:22:33 -0700)

are available in the git repository at:

  git://github.com/jonhunter/linux.git omap-gpmc-fixes-for-v3.10

for you to fetch changes up to b327b3627bb428eb7d98f25224532425a673d89e:

  ARM: OMAP2+: only WARN if a GPMC child probe function fail (2013-04-30 08:43:05 -0500)

----------------------------------------------------------------
GPMC fixes for v3.10. Main fix is to only search the GPMC node
for GPMC child devices and not the entire device-tree (which was
breaking ethernet support on some boards where the GPMC does not
interface with the ethernet chip). This branch is based upon
Tony's omap-for-v3.10/gpmc branch.
----------------------------------------------------------------
Javier Martinez Canillas (3):
      Documentation: dt: update TI GPMC ethernet binding properties
      ARM: OMAP2+: only search for GPMC DT child nodes on probe
      ARM: OMAP2+: only WARN if a GPMC child probe function fail

Jon Hunter (1):
      Documentation: dt: update properties in TI GPMC NAND example

 .../devicetree/bindings/mtd/gpmc-nand.txt          |   28 +++++-----
 Documentation/devicetree/bindings/net/gpmc-eth.txt |   56 ++++++++++----------
 arch/arm/mach-omap2/gpmc.c                         |   38 +++++--------
 3 files changed, 54 insertions(+), 68 deletions(-)


From stefano.stabellini at eu.citrix.com  Tue Apr 30 09:54:38 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Tue, 30 Apr 2013 14:54:38 +0100
Subject: linux-next: manual merge of the arm-soc tree with the xen-arm tree
In-Reply-To: <20130430091845.27d8de4935bd33ddb4a3e8c0@canb.auug.org.au>
References: <20130429175426.9423279609437a2d746cbb7b@canb.auug.org.au>
 <20130429082511.GA539@arm.com>
 <alpine.DEB.2.02.1304291049060.5398@kaball.uk.xensource.com>
 <20130430091845.27d8de4935bd33ddb4a3e8c0@canb.auug.org.au>
Message-ID: <alpine.DEB.2.02.1304301438330.5398@kaball.uk.xensource.com>

On Tue, 30 Apr 2013, Stephen Rothwell wrote:
> Hi Stefano,
> 
> On Mon, 29 Apr 2013 10:50:22 +0100 Stefano Stabellini <stefano.stabellini at eu.citrix.com> wrote:
> >
> > On Mon, 29 Apr 2013, Catalin Marinas wrote:
> > > 
> > > On Mon, Apr 29, 2013 at 08:54:26AM +0100, Stephen Rothwell wrote:
> > > > Today's linux-next merge of the arm-soc tree got a conflict in
> > > > arch/arm/mach-virt/platsmp.c between commit fe4bff02886b ("arm: introduce
> > > > psci_smp_ops") from the xen-arm tree and commit c0114709ed85 ("irqchip:
> > > > gic: Perform the gic_secondary_init() call via CPU notifier") from the
> > > > arm-soc tree.
> > > > 
> > > > The former renamed the file (and contents) so I applied the following
> > > > patch and can carry the fix as necessary (no action is required).
> > > > 
> > > > From: Stephen Rothwell <sfr at canb.auug.org.au>
> > > > Date: Mon, 29 Apr 2013 17:52:27 +1000
> > > > Subject: [PATCH] arm: fix for Perform the gic_secondary_init() call via CPU
> > > >  notifier
> > > > 
> > > > due to code movement.
> > > > 
> > > > Signed-off-by: Stephen Rothwell <sfr at canb.auug.org.au>
> > > > ---
> > > >  arch/arm/kernel/psci_smp.c | 7 -------
> > > >  1 file changed, 7 deletions(-)
> > > > 
> > > > diff --git a/arch/arm/kernel/psci_smp.c b/arch/arm/kernel/psci_smp.c
> > > > index 6ef139d..cd9acc7 100644
> > > > --- a/arch/arm/kernel/psci_smp.c
> > > > +++ b/arch/arm/kernel/psci_smp.c
> > > > @@ -14,7 +14,6 @@
> > > >   */
> > > >  
> > > >  #include <linux/init.h>
> > > > -#include <linux/irqchip/arm-gic.h>
> > > >  #include <linux/smp.h>
> > > >  #include <linux/of.h>
> > > >  
> > > > @@ -55,11 +54,6 @@ static int __cpuinit psci_boot_secondary(unsigned int cpu,
> > > >  	return -ENODEV;
> > > >  }
> > > >  
> > > > -static void __cpuinit psci_secondary_init(unsigned int cpu)
> > > > -{
> > > > -	gic_secondary_init(0);
> > > > -}
> > > > -
> > > >  #ifdef CONFIG_HOTPLUG_CPU
> > > >  void __ref psci_cpu_die(unsigned int cpu)
> > > >  {
> > > > @@ -84,7 +78,6 @@ bool __init psci_smp_available(void)
> > > >  }
> > > >  
> > > >  struct smp_operations __initdata psci_smp_ops = {
> > > > -	.smp_secondary_init	= psci_secondary_init,
> > > >  	.smp_boot_secondary	= psci_boot_secondary,
> > > >  	.cpu_die		= psci_cpu_die,
> > > >  };
> > > 
> > > The fix looks fine. Thanks.
> > 
> > Indeed, thanks! I'll add to it to the tree.
> 
> You should not apply that to your tree as you don't have the rest of the
> change from the arm-soc tree.  It needs to be applied to the merge of the
> two trees i.e. when Linus merges the last of the two trees.
> 
> This is why I wrote "no action is required".

I added the patch because it is very small and only affects psci_smp.c,
so it is not a problem for me to carry it in the xen-arm tree.
But I see your point, I'll remove it.

As a side note for the arm-soc maintainers in CC, even though I
proactively added the PSCI and the smp_init patches
(http://marc.info/?l=linux-kernel&m=136716063717467&w=2) to linux-next
to make sure they get enough exposure for this merge window, I would
appreciate if you could pick them up in your tree. I think they should
to Linus via arm-soc.


From stefano.stabellini at eu.citrix.com  Tue Apr 30 10:05:04 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Tue, 30 Apr 2013 15:05:04 +0100
Subject: [PATCH] ARM: add the "bool" type definition to asm/mach/arch.h
In-Reply-To: <1367325487-8366-1-git-send-email-nicolas.ferre@atmel.com>
References: <517F8FF4.3050901@atmel.com>
 <1367325487-8366-1-git-send-email-nicolas.ferre@atmel.com>
Message-ID: <alpine.DEB.2.02.1304301504530.5398@kaball.uk.xensource.com>

On Tue, 30 Apr 2013, Nicolas Ferre wrote:
> Addition of boolean field to machine_desc structure in commit
> 4dbfa9a25367cfa91aec0e56d75a6905d3242cd3 (ARM: Enable selection of
> SMP operations at boot time) was triggering compilation errors like:
> 
>   CC      arch/arm/mach-at91/at91sam9260_devices.o
> In file included from arch/arm/mach-at91/at91sam9260_devices.c:12:0:
> arch/arm/include/asm/mach/arch.h:46:2: error: expected specifier-qualifier-list before "bool"
> 
> So, we add the definition of "bool" by including the linux/types.h
> file to asm/mach/arch.h and make it self-contained.
> 
> Signed-off-by: Nicolas Ferre <nicolas.ferre at atmel.com>

Acked-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>


>  arch/arm/include/asm/mach/arch.h | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/arch/arm/include/asm/mach/arch.h b/arch/arm/include/asm/mach/arch.h
> index af8c54c..75bf079 100644
> --- a/arch/arm/include/asm/mach/arch.h
> +++ b/arch/arm/include/asm/mach/arch.h
> @@ -8,6 +8,8 @@
>   * published by the Free Software Foundation.
>   */
>  
> +#include <linux/types.h>
> +
>  #ifndef __ASSEMBLY__
>  
>  struct tag;
> -- 
> 1.8.0
> 


From jon-hunter at ti.com  Tue Apr 30 10:11:22 2013
From: jon-hunter at ti.com (Jon Hunter)
Date: Tue, 30 Apr 2013 09:11:22 -0500
Subject: [PATCH] ARM: dts: OMAP2+: Simplify NAND support
Message-ID: <1367331082-27944-1-git-send-email-jon-hunter@ti.com>

Commit 8c8a777 (ARM: OMAP2+: Add function to read GPMC settings from
device-tree) added a device-tree property "gpmc,device-nand" to indicate
is the GPMC child device is NAND. This commit should have updated the
GPMC NAND documentation (Documentation/devicetree/bindings/mtd/gpmc-nand.txt)
to list the property "gpmc,device-nand" as a required property and also
updated the example. However, this property is redundant and not needed
because the GPMC child device node for NAND is called "nand". Therefore,
remove this property.

Signed-off-by: Jon Hunter <jon-hunter at ti.com>
---
 Documentation/devicetree/bindings/bus/ti-gpmc.txt |    1 -
 arch/arm/boot/dts/omap3430-sdp.dts                |    1 -
 arch/arm/mach-omap2/gpmc-nand.c                   |    4 ++--
 arch/arm/mach-omap2/gpmc.c                        |    1 -
 4 files changed, 2 insertions(+), 5 deletions(-)

diff --git a/Documentation/devicetree/bindings/bus/ti-gpmc.txt b/Documentation/devicetree/bindings/bus/ti-gpmc.txt
index 4b87ea1..704be93 100644
--- a/Documentation/devicetree/bindings/bus/ti-gpmc.txt
+++ b/Documentation/devicetree/bindings/bus/ti-gpmc.txt
@@ -95,7 +95,6 @@ GPMC chip-select settings properties for child nodes. All are optional.
 - gpmc,burst-wrap	Enables wrap bursting
 - gpmc,burst-read	Enables read page/burst mode
 - gpmc,burst-write	Enables write page/burst mode
-- gpmc,device-nand	Device is NAND
 - gpmc,device-width	Total width of device(s) connected to a GPMC
 			chip-select in bytes. The GPMC supports 8-bit
 			and 16-bit devices and so this property must be
diff --git a/arch/arm/boot/dts/omap3430-sdp.dts b/arch/arm/boot/dts/omap3430-sdp.dts
index 144ae43..6076d01 100644
--- a/arch/arm/boot/dts/omap3430-sdp.dts
+++ b/arch/arm/boot/dts/omap3430-sdp.dts
@@ -105,7 +105,6 @@
 		nand-bus-width = <8>;
 
 		ti,nand-ecc-opt = "sw";
-		gpmc,device-nand;
 		gpmc,cs-on-ns = <0>;
 		gpmc,cs-rd-off-ns = <36>;
 		gpmc,cs-wr-off-ns = <36>;
diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
index c8044b0..662c7fd 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -102,8 +102,6 @@ int gpmc_nand_init(struct omap_nand_platform_data *gpmc_nand_data,
 		if (gpmc_nand_data->of_node) {
 			gpmc_read_settings_dt(gpmc_nand_data->of_node, &s);
 		} else {
-			s.device_nand = true;
-
 			/* Enable RD PIN Monitoring Reg */
 			if (gpmc_nand_data->dev_ready) {
 				s.wait_on_read = true;
@@ -111,6 +109,8 @@ int gpmc_nand_init(struct omap_nand_platform_data *gpmc_nand_data,
 			}
 		}
 
+		s.device_nand = true;
+
 		if (gpmc_nand_data->devsize == NAND_BUSWIDTH_16)
 			s.device_width = GPMC_DEVWIDTH_16BIT;
 		else
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 6c4da12..6f1beb4 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -1245,7 +1245,6 @@ void gpmc_read_settings_dt(struct device_node *np, struct gpmc_settings *p)
 
 	p->sync_read = of_property_read_bool(np, "gpmc,sync-read");
 	p->sync_write = of_property_read_bool(np, "gpmc,sync-write");
-	p->device_nand = of_property_read_bool(np, "gpmc,device-nand");
 	of_property_read_u32(np, "gpmc,device-width", &p->device_width);
 	of_property_read_u32(np, "gpmc,mux-add-data", &p->mux_add_data);
 
-- 
1.7.10.4



From marc.zyngier at arm.com  Tue Apr 30 10:17:26 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Tue, 30 Apr 2013 15:17:26 +0100
Subject: [PATCH 4/4] ARM: KVM: fix use of S2_PGD_SIZE
In-Reply-To: <1367331446-28030-1-git-send-email-marc.zyngier@arm.com>
References: <1367331446-28030-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1367331446-28030-5-git-send-email-marc.zyngier@arm.com>

S2_PGD_SIZE describe the number of pages a used by a stage-2 PGD,
not the size of the PGD.

Fix the VM_BUG_ON() call that doesn't check much when S2_PGD_SIZE
is equal to 1.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm/kvm/mmu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
index b978ebe..09ece5c 100644
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@ -377,7 +377,7 @@ int kvm_alloc_stage2_pgd(struct kvm *kvm)
 		return -ENOMEM;
 
 	/* stage-2 pgd must be aligned to its size */
-	VM_BUG_ON((unsigned long)pgd & (S2_PGD_SIZE - 1));
+	VM_BUG_ON((unsigned long)pgd & (PAGE_SIZE * S2_PGD_SIZE - 1));
 
 	memset(pgd, 0, PTRS_PER_S2_PGD * sizeof(pgd_t));
 	kvm_clean_pgd(pgd);
-- 
1.8.2.1




From marc.zyngier at arm.com  Tue Apr 30 10:17:25 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Tue, 30 Apr 2013 15:17:25 +0100
Subject: [PATCH 3/4] ARM: KVM: relax cache maintainance when building page
 pables
In-Reply-To: <1367331446-28030-1-git-send-email-marc.zyngier@arm.com>
References: <1367331446-28030-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1367331446-28030-4-git-send-email-marc.zyngier@arm.com>

Patch 5a677ce044f1 (ARM: KVM: switch to a dual-step HYP init code)
introduced code that flushes page tables to the point of coherency.
This is overkill (point of unification is enough), and actually
not required if running on a SMP capable platform.

Change this code to use clean_dcache_area(), which is updated by
ae8a8b9553bd (ARM: 7691/1: mm: kill unused TLB_CAN_READ_FROM_L1_CACHE
and use ALT_SMP instead) to behave as a no-op on SMP ARMv7.

Reported-by: Catalin Marinas <catalin.marinas at arm.com>
Cc: Will Deacon <will.deacon at arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm/include/asm/kvm_mmu.h | 1 +
 arch/arm/kvm/mmu.c             | 6 +++---
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/arm/include/asm/kvm_mmu.h b/arch/arm/include/asm/kvm_mmu.h
index 472ac70..2459821 100644
--- a/arch/arm/include/asm/kvm_mmu.h
+++ b/arch/arm/include/asm/kvm_mmu.h
@@ -129,6 +129,7 @@ static inline void coherent_icache_guest_page(struct kvm *kvm, gfn_t gfn)
 }
 
 #define kvm_flush_dcache_to_poc(a,l)	__cpuc_flush_dcache_area((a), (l))
+#define kvm_clean_dcache_to_pou(a,l)	clean_dcache_area((a), (l))
 
 #endif	/* !__ASSEMBLY__ */
 
diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
index 71f2a57..b978ebe 100644
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@ -228,7 +228,7 @@ static void create_hyp_pte_mappings(pmd_t *pmd, unsigned long start,
 		pte = pte_offset_kernel(pmd, addr);
 		kvm_set_pte(pte, pfn_pte(pfn, prot));
 		get_page(virt_to_page(pte));
-		kvm_flush_dcache_to_poc(pte, sizeof(*pte));
+		kvm_clean_dcache_to_pou(pte, sizeof(*pte));
 		pfn++;
 	} while (addr += PAGE_SIZE, addr != end);
 }
@@ -255,7 +255,7 @@ static int create_hyp_pmd_mappings(pud_t *pud, unsigned long start,
 			}
 			pmd_populate_kernel(NULL, pmd, pte);
 			get_page(virt_to_page(pmd));
-			kvm_flush_dcache_to_poc(pmd, sizeof(*pmd));
+			kvm_clean_dcache_to_pou(pmd, sizeof(*pmd));
 		}
 
 		next = pmd_addr_end(addr, end);
@@ -293,7 +293,7 @@ static int __create_hyp_mappings(pgd_t *pgdp,
 			}
 			pud_populate(NULL, pud, pmd);
 			get_page(virt_to_page(pud));
-			kvm_flush_dcache_to_poc(pud, sizeof(*pud));
+			kvm_clean_dcache_to_pou(pud, sizeof(*pud));
 		}
 
 		next = pgd_addr_end(addr, end);
-- 
1.8.2.1




From marc.zyngier at arm.com  Tue Apr 30 10:17:22 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Tue, 30 Apr 2013 15:17:22 +0100
Subject: [PATCH 0/4] ARM: KVM: random mmu related fixes for 3.10
Message-ID: <1367331446-28030-1-git-send-email-marc.zyngier@arm.com>

This patch series fixes a number of of KVM/ARM issues that have either
been spotted during the review of the arm64 code, or while reworking
related code.

Only the first patch fixes a potential (if unlikely) problem, the
others are either cosmetic or performance related.

Tested on TC-2.

Marc Zyngier (4):
  ARM: KVM: be more thorough when invalidating TLBs
  ARM: KVM: remove dead prototype for __kvm_tlb_flush_vmid
  ARM: KVM: relax cache maintainance when building page pables
  ARM: KVM: fix use of S2_PGD_SIZE

 arch/arm/include/asm/kvm_asm.h |  2 --
 arch/arm/include/asm/kvm_mmu.h |  1 +
 arch/arm/kvm/interrupts.S      |  2 ++
 arch/arm/kvm/mmu.c             | 44 ++++++++++++++++++++++++------------------
 4 files changed, 28 insertions(+), 21 deletions(-)

-- 
1.8.2.1




From marc.zyngier at arm.com  Tue Apr 30 10:17:24 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Tue, 30 Apr 2013 15:17:24 +0100
Subject: [PATCH 2/4] ARM: KVM: remove dead prototype for __kvm_tlb_flush_vmid
In-Reply-To: <1367331446-28030-1-git-send-email-marc.zyngier@arm.com>
References: <1367331446-28030-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1367331446-28030-3-git-send-email-marc.zyngier@arm.com>

__kvm_tlb_flush_vmid has been renamed to __kvm_tlb_flush_vmid_ipa,
and the old prototype should have been removed when the code was
modified.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm/include/asm/kvm_asm.h | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/arm/include/asm/kvm_asm.h b/arch/arm/include/asm/kvm_asm.h
index 18d5032..6ae3d2a 100644
--- a/arch/arm/include/asm/kvm_asm.h
+++ b/arch/arm/include/asm/kvm_asm.h
@@ -72,8 +72,6 @@ extern char __kvm_hyp_vector[];
 extern char __kvm_hyp_code_start[];
 extern char __kvm_hyp_code_end[];
 
-extern void __kvm_tlb_flush_vmid(struct kvm *kvm);
-
 extern void __kvm_flush_vm_context(void);
 extern void __kvm_tlb_flush_vmid_ipa(struct kvm *kvm, phys_addr_t ipa);
 
-- 
1.8.2.1




From marc.zyngier at arm.com  Tue Apr 30 10:17:23 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Tue, 30 Apr 2013 15:17:23 +0100
Subject: [PATCH 1/4] ARM: KVM: be more thorough when invalidating TLBs
In-Reply-To: <1367331446-28030-1-git-send-email-marc.zyngier@arm.com>
References: <1367331446-28030-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1367331446-28030-2-git-send-email-marc.zyngier@arm.com>

The KVM/ARM MMU code doesn't take care of invalidating TLBs before
freeing a {pte,pmd} table. This could cause problems if the page
is reallocated and then speculated into by another CPU.

Reported-by: Catalin Marinas <catalin.marinas at arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm/kvm/interrupts.S |  2 ++
 arch/arm/kvm/mmu.c        | 36 +++++++++++++++++++++---------------
 2 files changed, 23 insertions(+), 15 deletions(-)

diff --git a/arch/arm/kvm/interrupts.S b/arch/arm/kvm/interrupts.S
index f7793df..9e2d906c 100644
--- a/arch/arm/kvm/interrupts.S
+++ b/arch/arm/kvm/interrupts.S
@@ -37,6 +37,8 @@ __kvm_hyp_code_start:
  *
  * void __kvm_tlb_flush_vmid_ipa(struct kvm *kvm, phys_addr_t ipa);
  *
+ * Invalidate TLB for the given IPA, or invalidate all if ipa is zero.
+ *
  * We rely on the hardware to broadcast the TLB invalidation to all CPUs
  * inside the inner-shareable domain (which is the case for all v7
  * implementations).  If we come across a non-IS SMP implementation, we'll
diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
index 9657065..71f2a57 100644
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@ -43,7 +43,8 @@ static phys_addr_t hyp_idmap_vector;
 
 static void kvm_tlb_flush_vmid_ipa(struct kvm *kvm, phys_addr_t ipa)
 {
-	kvm_call_hyp(__kvm_tlb_flush_vmid_ipa, kvm, ipa);
+	if (kvm)
+		kvm_call_hyp(__kvm_tlb_flush_vmid_ipa, kvm, ipa);
 }
 
 static int mmu_topup_memory_cache(struct kvm_mmu_memory_cache *cache,
@@ -78,18 +79,20 @@ static void *mmu_memory_cache_alloc(struct kvm_mmu_memory_cache *mc)
 	return p;
 }
 
-static void clear_pud_entry(pud_t *pud)
+static void clear_pud_entry(struct kvm *kvm, pud_t *pud, phys_addr_t addr)
 {
 	pmd_t *pmd_table = pmd_offset(pud, 0);
 	pud_clear(pud);
+	kvm_tlb_flush_vmid_ipa(kvm, addr);
 	pmd_free(NULL, pmd_table);
 	put_page(virt_to_page(pud));
 }
 
-static void clear_pmd_entry(pmd_t *pmd)
+static void clear_pmd_entry(struct kvm *kvm, pmd_t *pmd, phys_addr_t addr)
 {
 	pte_t *pte_table = pte_offset_kernel(pmd, 0);
 	pmd_clear(pmd);
+	kvm_tlb_flush_vmid_ipa(kvm, addr);
 	pte_free_kernel(NULL, pte_table);
 	put_page(virt_to_page(pmd));
 }
@@ -100,11 +103,12 @@ static bool pmd_empty(pmd_t *pmd)
 	return page_count(pmd_page) == 1;
 }
 
-static void clear_pte_entry(pte_t *pte)
+static void clear_pte_entry(struct kvm *kvm, pte_t *pte, phys_addr_t addr)
 {
 	if (pte_present(*pte)) {
 		kvm_set_pte(pte, __pte(0));
 		put_page(virt_to_page(pte));
+		kvm_tlb_flush_vmid_ipa(kvm, addr);
 	}
 }
 
@@ -114,7 +118,8 @@ static bool pte_empty(pte_t *pte)
 	return page_count(pte_page) == 1;
 }
 
-static void unmap_range(pgd_t *pgdp, unsigned long long start, u64 size)
+static void unmap_range(struct kvm *kvm, pgd_t *pgdp,
+			unsigned long long start, u64 size)
 {
 	pgd_t *pgd;
 	pud_t *pud;
@@ -138,15 +143,15 @@ static void unmap_range(pgd_t *pgdp, unsigned long long start, u64 size)
 		}
 
 		pte = pte_offset_kernel(pmd, addr);
-		clear_pte_entry(pte);
+		clear_pte_entry(kvm, pte, addr);
 		range = PAGE_SIZE;
 
 		/* If we emptied the pte, walk back up the ladder */
 		if (pte_empty(pte)) {
-			clear_pmd_entry(pmd);
+			clear_pmd_entry(kvm, pmd, addr);
 			range = PMD_SIZE;
 			if (pmd_empty(pmd)) {
-				clear_pud_entry(pud);
+				clear_pud_entry(kvm, pud, addr);
 				range = PUD_SIZE;
 			}
 		}
@@ -165,14 +170,14 @@ void free_boot_hyp_pgd(void)
 	mutex_lock(&kvm_hyp_pgd_mutex);
 
 	if (boot_hyp_pgd) {
-		unmap_range(boot_hyp_pgd, hyp_idmap_start, PAGE_SIZE);
-		unmap_range(boot_hyp_pgd, TRAMPOLINE_VA, PAGE_SIZE);
+		unmap_range(NULL, boot_hyp_pgd, hyp_idmap_start, PAGE_SIZE);
+		unmap_range(NULL, boot_hyp_pgd, TRAMPOLINE_VA, PAGE_SIZE);
 		kfree(boot_hyp_pgd);
 		boot_hyp_pgd = NULL;
 	}
 
 	if (hyp_pgd)
-		unmap_range(hyp_pgd, TRAMPOLINE_VA, PAGE_SIZE);
+		unmap_range(NULL, hyp_pgd, TRAMPOLINE_VA, PAGE_SIZE);
 
 	kfree(init_bounce_page);
 	init_bounce_page = NULL;
@@ -200,9 +205,10 @@ void free_hyp_pgds(void)
 
 	if (hyp_pgd) {
 		for (addr = PAGE_OFFSET; virt_addr_valid(addr); addr += PGDIR_SIZE)
-			unmap_range(hyp_pgd, KERN_TO_HYP(addr), PGDIR_SIZE);
+			unmap_range(NULL, hyp_pgd, KERN_TO_HYP(addr), PGDIR_SIZE);
 		for (addr = VMALLOC_START; is_vmalloc_addr((void*)addr); addr += PGDIR_SIZE)
-			unmap_range(hyp_pgd, KERN_TO_HYP(addr), PGDIR_SIZE);
+			unmap_range(NULL, hyp_pgd, KERN_TO_HYP(addr), PGDIR_SIZE);
+
 		kfree(hyp_pgd);
 		hyp_pgd = NULL;
 	}
@@ -393,7 +399,7 @@ int kvm_alloc_stage2_pgd(struct kvm *kvm)
  */
 static void unmap_stage2_range(struct kvm *kvm, phys_addr_t start, u64 size)
 {
-	unmap_range(kvm->arch.pgd, start, size);
+	unmap_range(kvm, kvm->arch.pgd, start, size);
 }
 
 /**
@@ -413,6 +419,7 @@ void kvm_free_stage2_pgd(struct kvm *kvm)
 		return;
 
 	unmap_stage2_range(kvm, 0, KVM_PHYS_SIZE);
+	kvm_tlb_flush_vmid_ipa(kvm, 0);	/* Invalidate TLB ALL */
 	free_pages((unsigned long)kvm->arch.pgd, S2_PGD_ORDER);
 	kvm->arch.pgd = NULL;
 }
@@ -675,7 +682,6 @@ static void handle_hva_to_gpa(struct kvm *kvm,
 static void kvm_unmap_hva_handler(struct kvm *kvm, gpa_t gpa, void *data)
 {
 	unmap_stage2_range(kvm, gpa, PAGE_SIZE);
-	kvm_tlb_flush_vmid_ipa(kvm, gpa);
 }
 
 int kvm_unmap_hva(struct kvm *kvm, unsigned long hva)
-- 
1.8.2.1




From will.deacon at arm.com  Tue Apr 30 10:30:01 2013
From: will.deacon at arm.com (Will Deacon)
Date: Tue, 30 Apr 2013 15:30:01 +0100
Subject: [PATCH 3/4] ARM: KVM: relax cache maintainance when building
 page pables
In-Reply-To: <1367331446-28030-4-git-send-email-marc.zyngier@arm.com>
References: <1367331446-28030-1-git-send-email-marc.zyngier@arm.com>
 <1367331446-28030-4-git-send-email-marc.zyngier@arm.com>
Message-ID: <20130430143001.GA6001@mudshark.cambridge.arm.com>

On Tue, Apr 30, 2013 at 03:17:25PM +0100, Marc Zyngier wrote:
> Patch 5a677ce044f1 (ARM: KVM: switch to a dual-step HYP init code)
> introduced code that flushes page tables to the point of coherency.
> This is overkill (point of unification is enough), and actually
> not required if running on a SMP capable platform.
> 
> Change this code to use clean_dcache_area(), which is updated by
> ae8a8b9553bd (ARM: 7691/1: mm: kill unused TLB_CAN_READ_FROM_L1_CACHE
> and use ALT_SMP instead) to behave as a no-op on SMP ARMv7.
> 
> Reported-by: Catalin Marinas <catalin.marinas at arm.com>
> Cc: Will Deacon <will.deacon at arm.com>
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> ---
>  arch/arm/include/asm/kvm_mmu.h | 1 +
>  arch/arm/kvm/mmu.c             | 6 +++---
>  2 files changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/include/asm/kvm_mmu.h b/arch/arm/include/asm/kvm_mmu.h
> index 472ac70..2459821 100644
> --- a/arch/arm/include/asm/kvm_mmu.h
> +++ b/arch/arm/include/asm/kvm_mmu.h
> @@ -129,6 +129,7 @@ static inline void coherent_icache_guest_page(struct kvm *kvm, gfn_t gfn)
>  }
>  
>  #define kvm_flush_dcache_to_poc(a,l)	__cpuc_flush_dcache_area((a), (l))
> +#define kvm_clean_dcache_to_pou(a,l)	clean_dcache_area((a), (l))

I don't think the name helps, since this sounds like it could be used for
things other than flushing page tables (for example, writing instructions)
but apart from that:

  Reviewed-by: Will Deacon <will.deacon at arm.com>

Will


From shc_work at mail.ru  Tue Apr 30 10:38:05 2013
From: shc_work at mail.ru (=?UTF-8?B?QWxleGFuZGVyIFNoaXlhbg==?=)
Date: Tue, 30 Apr 2013 18:38:05 +0400
Subject: =?UTF-8?B?UmVbMl06IFtQQVRDSCBWMl0gdmlkZW86IGltcGxlbWVudCBhIHNpbXBsZSBm?=
 =?UTF-8?B?cmFtZWJ1ZmZlciBkcml2ZXI=?=
In-Reply-To: <517F753F.5090909@ti.com>
References: <1365043183-28905-1-git-send-email-swarren@wwwdotorg.org>
 <517F753F.5090909@ti.com>
Message-ID: <1367332685.945287573@f287.mail.ru>

> On 04/04/2013 05:39 AM, Stephen Warren wrote:
> > A simple frame-buffer describes a raw memory region that may be rendered
> > to, with the assumption that the display hardware has already been set
> > up to scan out from that buffer.
> > 
> > This is useful in cases where a bootloader exists and has set up the
> > display hardware, but a Linux driver doesn't yet exist for the display
> > hardware.
> > 
> > Signed-off-by: Stephen Warren <swarren at wwwdotorg.org>
...
> > +	framebuffer {
> > +		compatible = "simple-framebuffer";
> > +		reg = <0x1d385000 (1600 * 1200 * 2)>;
> > +		width = <1600>;
> > +		height = <1200>;
> > +		stride = <(1600 * 2)>;
> > +		format = "r5g6b5";
> > +	};
> 
> I'm not an expert on DT, but I think the point of DT is to describe the
> hardware. This doesn't describe the hardware at all.

On my incompetent opinion, "bpp" parameter can replace size of
framebuffer and "stride". Is not it?

---

From cdall at cs.columbia.edu  Tue Apr 30 10:49:21 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Tue, 30 Apr 2013 07:49:21 -0700
Subject: [GIT PULL v2] KVM/ARM Changes for 3.10
Message-ID: <1367333376-30983-1-git-send-email-cdall@cs.columbia.edu>

Hi Marcelo and Gleb,

These are the changes for KVM/ARM for 3.10.

The patches depend on the cleanup branch, which you've already merged.

Main thing is the reworking of Hyp idmaps, which is now handled by KVM
instead of arm/mm and includes several nasty bug fixes from Marc in
the progress.

 [v2] No changes since v1, except sending patch series with this one.

Thanks!

Andre Przywara (1):
  ARM: KVM: iterate over all CPUs for CPU compatibility check

Arnd Bergmann (1):
  ARM: KVM: define KVM_ARM_MAX_VCPUS unconditionally

Christoffer Dall (2):
  KVM: ARM: Fix API documentation for ONE_REG encoding
  KVM: ARM: Fix spelling in error message

Marc Zyngier (10):
  ARM: KVM: add support for minimal host vs guest profiling
  ARM: KVM: simplify HYP mapping population
  ARM: KVM: fix HYP mapping limitations around zero
  ARM: KVM: move to a KVM provided HYP idmap
  ARM: KVM: enforce maximum size for identity mapped code
  ARM: KVM: rework HYP page table freeing
  ARM: KVM: switch to a dual-step HYP init code
  ARM: KVM: perform HYP initilization for hotplugged CPUs
  ARM: KVM: add architecture specific hook for capabilities
  ARM: KVM: promote vfp_host pointer to generic host cpu context

Mark Rutland (1):
  ARM: KVM: arch_timer: use symbolic constants

 Documentation/virtual/kvm/api.txt |   12 +-
 arch/arm/include/asm/idmap.h      |    1 -
 arch/arm/include/asm/kvm_host.h   |   47 ++--
 arch/arm/include/asm/kvm_mmu.h    |   28 ++-
 arch/arm/kernel/asm-offsets.c     |    2 +-
 arch/arm/kernel/vmlinux.lds.S     |    7 +-
 arch/arm/kvm/Kconfig              |    6 +-
 arch/arm/kvm/Makefile             |    2 +-
 arch/arm/kvm/arch_timer.c         |    7 +-
 arch/arm/kvm/arm.c                |  111 +++++----
 arch/arm/kvm/handle_exit.c        |    2 +-
 arch/arm/kvm/init.S               |   78 +++++--
 arch/arm/kvm/mmu.c                |  455 +++++++++++++++++++++----------------
 arch/arm/kvm/perf.c               |   68 ++++++
 arch/arm/mm/idmap.c               |   32 +--
 15 files changed, 532 insertions(+), 326 deletions(-)
 create mode 100644 arch/arm/kvm/perf.c

-- 
1.7.9.5



From cdall at cs.columbia.edu  Tue Apr 30 10:49:22 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Tue, 30 Apr 2013 07:49:22 -0700
Subject: [PATCH 01/15] ARM: KVM: add support for minimal host vs guest
 profiling
In-Reply-To: <1367333376-30983-1-git-send-email-cdall@cs.columbia.edu>
References: <1367333376-30983-1-git-send-email-cdall@cs.columbia.edu>
Message-ID: <1367333376-30983-2-git-send-email-cdall@cs.columbia.edu>

From: Marc Zyngier <marc.zyngier at arm.com>

In order to be able to correctly profile what is happening on the
host, we need to be able to identify when we're running on the guest,
and log these events differently.

Perf offers a simple way to register callbacks into KVM. Mimic what
x86 does and enjoy being able to profile your KVM host.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
Signed-off-by: Christoffer Dall <cdall at cs.columbia.edu>
---
 arch/arm/include/asm/kvm_host.h |    3 ++
 arch/arm/kvm/Makefile           |    2 +-
 arch/arm/kvm/arm.c              |    4 +++
 arch/arm/kvm/perf.c             |   68 +++++++++++++++++++++++++++++++++++++++
 4 files changed, 76 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/kvm/perf.c

diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
index 0c4e643..78813b8 100644
--- a/arch/arm/include/asm/kvm_host.h
+++ b/arch/arm/include/asm/kvm_host.h
@@ -207,4 +207,7 @@ static inline void __cpu_init_hyp_mode(unsigned long long pgd_ptr,
 	kvm_call_hyp((void *)pgd_low, pgd_high, hyp_stack_ptr, vector_ptr);
 }
 
+int kvm_perf_init(void);
+int kvm_perf_teardown(void);
+
 #endif /* __ARM_KVM_HOST_H__ */
diff --git a/arch/arm/kvm/Makefile b/arch/arm/kvm/Makefile
index 8dc5e76..53c5ed8 100644
--- a/arch/arm/kvm/Makefile
+++ b/arch/arm/kvm/Makefile
@@ -18,6 +18,6 @@ kvm-arm-y = $(addprefix ../../../virt/kvm/, kvm_main.o coalesced_mmio.o)
 
 obj-y += kvm-arm.o init.o interrupts.o
 obj-y += arm.o handle_exit.o guest.o mmu.o emulate.o reset.o
-obj-y += coproc.o coproc_a15.o mmio.o psci.o
+obj-y += coproc.o coproc_a15.o mmio.o psci.o perf.o
 obj-$(CONFIG_KVM_ARM_VGIC) += vgic.o
 obj-$(CONFIG_KVM_ARM_TIMER) += arch_timer.o
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index 1497e18..7403f88 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -920,7 +920,10 @@ static int init_hyp_mode(void)
 	if (err)
 		goto out_free_mappings;
 
+	kvm_perf_init();
+
 	kvm_info("Hyp mode initialized successfully\n");
+
 	return 0;
 out_free_vfp:
 	free_percpu(kvm_host_vfp_state);
@@ -964,6 +967,7 @@ out_err:
 /* NOP: Compiling as a module not supported */
 void kvm_arch_exit(void)
 {
+	kvm_perf_teardown();
 }
 
 static int arm_init(void)
diff --git a/arch/arm/kvm/perf.c b/arch/arm/kvm/perf.c
new file mode 100644
index 0000000..1a3849d
--- /dev/null
+++ b/arch/arm/kvm/perf.c
@@ -0,0 +1,68 @@
+/*
+ * Based on the x86 implementation.
+ *
+ * Copyright (C) 2012 ARM Ltd.
+ * Author: Marc Zyngier <marc.zyngier at arm.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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <linux/perf_event.h>
+#include <linux/kvm_host.h>
+
+#include <asm/kvm_emulate.h>
+
+static int kvm_is_in_guest(void)
+{
+        return kvm_arm_get_running_vcpu() != NULL;
+}
+
+static int kvm_is_user_mode(void)
+{
+	struct kvm_vcpu *vcpu;
+
+	vcpu = kvm_arm_get_running_vcpu();
+
+	if (vcpu)
+		return !vcpu_mode_priv(vcpu);
+
+	return 0;
+}
+
+static unsigned long kvm_get_guest_ip(void)
+{
+	struct kvm_vcpu *vcpu;
+
+	vcpu = kvm_arm_get_running_vcpu();
+
+	if (vcpu)
+		return *vcpu_pc(vcpu);
+
+	return 0;
+}
+
+static struct perf_guest_info_callbacks kvm_guest_cbs = {
+	.is_in_guest	= kvm_is_in_guest,
+	.is_user_mode	= kvm_is_user_mode,
+	.get_guest_ip	= kvm_get_guest_ip,
+};
+
+int kvm_perf_init(void)
+{
+	return perf_register_guest_info_callbacks(&kvm_guest_cbs);
+}
+
+int kvm_perf_teardown(void)
+{
+	return perf_unregister_guest_info_callbacks(&kvm_guest_cbs);
+}
-- 
1.7.9.5



From cdall at cs.columbia.edu  Tue Apr 30 10:49:23 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Tue, 30 Apr 2013 07:49:23 -0700
Subject: [PATCH 02/15] ARM: KVM: arch_timer: use symbolic constants
In-Reply-To: <1367333376-30983-1-git-send-email-cdall@cs.columbia.edu>
References: <1367333376-30983-1-git-send-email-cdall@cs.columbia.edu>
Message-ID: <1367333376-30983-3-git-send-email-cdall@cs.columbia.edu>

From: Mark Rutland <mark.rutland at arm.com>

In clocksource/arm_arch_timer.h we define useful symbolic constants.
Let's use them to make the KVM arch_timer code clearer.

Signed-off-by: Mark Rutland <mark.rutland at arm.com>
Acked-by: Marc Zyngier <marc.zyngier at arm.com>
Cc: Christoffer Dall <cdall at cs.columbia.edu>
Signed-off-by: Christoffer Dall <cdall at cs.columbia.edu>
---
 arch/arm/kvm/arch_timer.c |    7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/arm/kvm/arch_timer.c b/arch/arm/kvm/arch_timer.c
index 6ac938d..c55b608 100644
--- a/arch/arm/kvm/arch_timer.c
+++ b/arch/arm/kvm/arch_timer.c
@@ -22,6 +22,7 @@
 #include <linux/kvm_host.h>
 #include <linux/interrupt.h>
 
+#include <clocksource/arm_arch_timer.h>
 #include <asm/arch_timer.h>
 
 #include <asm/kvm_vgic.h>
@@ -64,7 +65,7 @@ static void kvm_timer_inject_irq(struct kvm_vcpu *vcpu)
 {
 	struct arch_timer_cpu *timer = &vcpu->arch.timer_cpu;
 
-	timer->cntv_ctl |= 1 << 1; /* Mask the interrupt in the guest */
+	timer->cntv_ctl |= ARCH_TIMER_CTRL_IT_MASK;
 	kvm_vgic_inject_irq(vcpu->kvm, vcpu->vcpu_id,
 			    vcpu->arch.timer_cpu.irq->irq,
 			    vcpu->arch.timer_cpu.irq->level);
@@ -133,8 +134,8 @@ void kvm_timer_sync_hwstate(struct kvm_vcpu *vcpu)
 	cycle_t cval, now;
 	u64 ns;
 
-	/* Check if the timer is enabled and unmasked first */
-	if ((timer->cntv_ctl & 3) != 1)
+	if ((timer->cntv_ctl & ARCH_TIMER_CTRL_IT_MASK) ||
+		!(timer->cntv_ctl & ARCH_TIMER_CTRL_ENABLE))
 		return;
 
 	cval = timer->cntv_cval;
-- 
1.7.9.5



From cdall at cs.columbia.edu  Tue Apr 30 10:49:25 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Tue, 30 Apr 2013 07:49:25 -0700
Subject: [PATCH 04/15] ARM: KVM: fix HYP mapping limitations around zero
In-Reply-To: <1367333376-30983-1-git-send-email-cdall@cs.columbia.edu>
References: <1367333376-30983-1-git-send-email-cdall@cs.columbia.edu>
Message-ID: <1367333376-30983-5-git-send-email-cdall@cs.columbia.edu>

From: Marc Zyngier <marc.zyngier at arm.com>

The current code for creating HYP mapping doesn't like to wrap
around zero, which prevents from mapping anything into the last
page of the virtual address space.

It doesn't take much effort to remove this limitation, making
the code more consistent with the rest of the kernel in the process.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
Signed-off-by: Christoffer Dall <cdall at cs.columbia.edu>
---
 arch/arm/kvm/mmu.c |   21 ++++++++++-----------
 1 file changed, 10 insertions(+), 11 deletions(-)

diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
index 3003321..96d61da 100644
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@ -131,11 +131,12 @@ static void create_hyp_pte_mappings(pmd_t *pmd, unsigned long start,
 	pte_t *pte;
 	unsigned long addr;
 
-	for (addr = start; addr < end; addr += PAGE_SIZE) {
+	addr = start;
+	do {
 		pte = pte_offset_kernel(pmd, addr);
 		kvm_set_pte(pte, pfn_pte(pfn, prot));
 		pfn++;
-	}
+	} while (addr += PAGE_SIZE, addr != end);
 }
 
 static int create_hyp_pmd_mappings(pud_t *pud, unsigned long start,
@@ -146,7 +147,8 @@ static int create_hyp_pmd_mappings(pud_t *pud, unsigned long start,
 	pte_t *pte;
 	unsigned long addr, next;
 
-	for (addr = start; addr < end; addr = next) {
+	addr = start;
+	do {
 		pmd = pmd_offset(pud, addr);
 
 		BUG_ON(pmd_sect(*pmd));
@@ -164,7 +166,7 @@ static int create_hyp_pmd_mappings(pud_t *pud, unsigned long start,
 
 		create_hyp_pte_mappings(pmd, addr, next, pfn, prot);
 		pfn += (next - addr) >> PAGE_SHIFT;
-	}
+	} while (addr = next, addr != end);
 
 	return 0;
 }
@@ -179,11 +181,10 @@ static int __create_hyp_mappings(pgd_t *pgdp,
 	unsigned long addr, next;
 	int err = 0;
 
-	if (start >= end)
-		return -EINVAL;
-
 	mutex_lock(&kvm_hyp_pgd_mutex);
-	for (addr = start & PAGE_MASK; addr < end; addr = next) {
+	addr = start & PAGE_MASK;
+	end = PAGE_ALIGN(end);
+	do {
 		pgd = pgdp + pgd_index(addr);
 		pud = pud_offset(pgd, addr);
 
@@ -202,7 +203,7 @@ static int __create_hyp_mappings(pgd_t *pgdp,
 		if (err)
 			goto out;
 		pfn += (next - addr) >> PAGE_SHIFT;
-	}
+	} while (addr = next, addr != end);
 out:
 	mutex_unlock(&kvm_hyp_pgd_mutex);
 	return err;
@@ -216,8 +217,6 @@ out:
  * The same virtual address as the kernel virtual address is also used
  * in Hyp-mode mapping (modulo HYP_PAGE_OFFSET) to the same underlying
  * physical pages.
- *
- * Note: Wrapping around zero in the "to" address is not supported.
  */
 int create_hyp_mappings(void *from, void *to)
 {
-- 
1.7.9.5



From cdall at cs.columbia.edu  Tue Apr 30 10:49:24 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Tue, 30 Apr 2013 07:49:24 -0700
Subject: [PATCH 03/15] ARM: KVM: simplify HYP mapping population
In-Reply-To: <1367333376-30983-1-git-send-email-cdall@cs.columbia.edu>
References: <1367333376-30983-1-git-send-email-cdall@cs.columbia.edu>
Message-ID: <1367333376-30983-4-git-send-email-cdall@cs.columbia.edu>

From: Marc Zyngier <marc.zyngier at arm.com>

The way we populate HYP mappings is a bit convoluted, to say the least.
Passing a pointer around to keep track of the current PFN is quite
odd, and we end-up having two different PTE accessors for no good
reason.

Simplify the whole thing by unifying the two PTE accessors, passing
a pgprot_t around, and moving the various validity checks to the
upper layers.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
Signed-off-by: Christoffer Dall <cdall at cs.columbia.edu>
---
 arch/arm/kvm/mmu.c |  102 ++++++++++++++++++++++------------------------------
 1 file changed, 42 insertions(+), 60 deletions(-)

diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
index 2f12e40..3003321 100644
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@ -125,54 +125,34 @@ void free_hyp_pmds(void)
 }
 
 static void create_hyp_pte_mappings(pmd_t *pmd, unsigned long start,
-				    unsigned long end)
+				    unsigned long end, unsigned long pfn,
+				    pgprot_t prot)
 {
 	pte_t *pte;
 	unsigned long addr;
-	struct page *page;
 
-	for (addr = start & PAGE_MASK; addr < end; addr += PAGE_SIZE) {
-		unsigned long hyp_addr = KERN_TO_HYP(addr);
-
-		pte = pte_offset_kernel(pmd, hyp_addr);
-		BUG_ON(!virt_addr_valid(addr));
-		page = virt_to_page(addr);
-		kvm_set_pte(pte, mk_pte(page, PAGE_HYP));
-	}
-}
-
-static void create_hyp_io_pte_mappings(pmd_t *pmd, unsigned long start,
-				       unsigned long end,
-				       unsigned long *pfn_base)
-{
-	pte_t *pte;
-	unsigned long addr;
-
-	for (addr = start & PAGE_MASK; addr < end; addr += PAGE_SIZE) {
-		unsigned long hyp_addr = KERN_TO_HYP(addr);
-
-		pte = pte_offset_kernel(pmd, hyp_addr);
-		BUG_ON(pfn_valid(*pfn_base));
-		kvm_set_pte(pte, pfn_pte(*pfn_base, PAGE_HYP_DEVICE));
-		(*pfn_base)++;
+	for (addr = start; addr < end; addr += PAGE_SIZE) {
+		pte = pte_offset_kernel(pmd, addr);
+		kvm_set_pte(pte, pfn_pte(pfn, prot));
+		pfn++;
 	}
 }
 
 static int create_hyp_pmd_mappings(pud_t *pud, unsigned long start,
-				   unsigned long end, unsigned long *pfn_base)
+				   unsigned long end, unsigned long pfn,
+				   pgprot_t prot)
 {
 	pmd_t *pmd;
 	pte_t *pte;
 	unsigned long addr, next;
 
 	for (addr = start; addr < end; addr = next) {
-		unsigned long hyp_addr = KERN_TO_HYP(addr);
-		pmd = pmd_offset(pud, hyp_addr);
+		pmd = pmd_offset(pud, addr);
 
 		BUG_ON(pmd_sect(*pmd));
 
 		if (pmd_none(*pmd)) {
-			pte = pte_alloc_one_kernel(NULL, hyp_addr);
+			pte = pte_alloc_one_kernel(NULL, addr);
 			if (!pte) {
 				kvm_err("Cannot allocate Hyp pte\n");
 				return -ENOMEM;
@@ -182,25 +162,17 @@ static int create_hyp_pmd_mappings(pud_t *pud, unsigned long start,
 
 		next = pmd_addr_end(addr, end);
 
-		/*
-		 * If pfn_base is NULL, we map kernel pages into HYP with the
-		 * virtual address. Otherwise, this is considered an I/O
-		 * mapping and we map the physical region starting at
-		 * *pfn_base to [start, end[.
-		 */
-		if (!pfn_base)
-			create_hyp_pte_mappings(pmd, addr, next);
-		else
-			create_hyp_io_pte_mappings(pmd, addr, next, pfn_base);
+		create_hyp_pte_mappings(pmd, addr, next, pfn, prot);
+		pfn += (next - addr) >> PAGE_SHIFT;
 	}
 
 	return 0;
 }
 
-static int __create_hyp_mappings(void *from, void *to, unsigned long *pfn_base)
+static int __create_hyp_mappings(pgd_t *pgdp,
+				 unsigned long start, unsigned long end,
+				 unsigned long pfn, pgprot_t prot)
 {
-	unsigned long start = (unsigned long)from;
-	unsigned long end = (unsigned long)to;
 	pgd_t *pgd;
 	pud_t *pud;
 	pmd_t *pmd;
@@ -209,21 +181,14 @@ static int __create_hyp_mappings(void *from, void *to, unsigned long *pfn_base)
 
 	if (start >= end)
 		return -EINVAL;
-	/* Check for a valid kernel memory mapping */
-	if (!pfn_base && (!virt_addr_valid(from) || !virt_addr_valid(to - 1)))
-		return -EINVAL;
-	/* Check for a valid kernel IO mapping */
-	if (pfn_base && (!is_vmalloc_addr(from) || !is_vmalloc_addr(to - 1)))
-		return -EINVAL;
 
 	mutex_lock(&kvm_hyp_pgd_mutex);
-	for (addr = start; addr < end; addr = next) {
-		unsigned long hyp_addr = KERN_TO_HYP(addr);
-		pgd = hyp_pgd + pgd_index(hyp_addr);
-		pud = pud_offset(pgd, hyp_addr);
+	for (addr = start & PAGE_MASK; addr < end; addr = next) {
+		pgd = pgdp + pgd_index(addr);
+		pud = pud_offset(pgd, addr);
 
 		if (pud_none_or_clear_bad(pud)) {
-			pmd = pmd_alloc_one(NULL, hyp_addr);
+			pmd = pmd_alloc_one(NULL, addr);
 			if (!pmd) {
 				kvm_err("Cannot allocate Hyp pmd\n");
 				err = -ENOMEM;
@@ -233,9 +198,10 @@ static int __create_hyp_mappings(void *from, void *to, unsigned long *pfn_base)
 		}
 
 		next = pgd_addr_end(addr, end);
-		err = create_hyp_pmd_mappings(pud, addr, next, pfn_base);
+		err = create_hyp_pmd_mappings(pud, addr, next, pfn, prot);
 		if (err)
 			goto out;
+		pfn += (next - addr) >> PAGE_SHIFT;
 	}
 out:
 	mutex_unlock(&kvm_hyp_pgd_mutex);
@@ -255,22 +221,38 @@ out:
  */
 int create_hyp_mappings(void *from, void *to)
 {
-	return __create_hyp_mappings(from, to, NULL);
+	unsigned long phys_addr = virt_to_phys(from);
+	unsigned long start = KERN_TO_HYP((unsigned long)from);
+	unsigned long end = KERN_TO_HYP((unsigned long)to);
+
+	/* Check for a valid kernel memory mapping */
+	if (!virt_addr_valid(from) || !virt_addr_valid(to - 1))
+		return -EINVAL;
+
+	return __create_hyp_mappings(hyp_pgd, start, end,
+				     __phys_to_pfn(phys_addr), PAGE_HYP);
 }
 
 /**
  * create_hyp_io_mappings - duplicate a kernel IO mapping into Hyp mode
  * @from:	The kernel start VA of the range
  * @to:		The kernel end VA of the range (exclusive)
- * @addr:	The physical start address which gets mapped
+ * @phys_addr:	The physical start address which gets mapped
  *
  * The resulting HYP VA is the same as the kernel VA, modulo
  * HYP_PAGE_OFFSET.
  */
-int create_hyp_io_mappings(void *from, void *to, phys_addr_t addr)
+int create_hyp_io_mappings(void *from, void *to, phys_addr_t phys_addr)
 {
-	unsigned long pfn = __phys_to_pfn(addr);
-	return __create_hyp_mappings(from, to, &pfn);
+	unsigned long start = KERN_TO_HYP((unsigned long)from);
+	unsigned long end = KERN_TO_HYP((unsigned long)to);
+
+	/* Check for a valid kernel IO mapping */
+	if (!is_vmalloc_addr(from) || !is_vmalloc_addr(to - 1))
+		return -EINVAL;
+
+	return __create_hyp_mappings(hyp_pgd, start, end,
+				     __phys_to_pfn(phys_addr), PAGE_HYP_DEVICE);
 }
 
 /**
-- 
1.7.9.5



From cdall at cs.columbia.edu  Tue Apr 30 10:49:26 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Tue, 30 Apr 2013 07:49:26 -0700
Subject: [PATCH 05/15] ARM: KVM: move to a KVM provided HYP idmap
In-Reply-To: <1367333376-30983-1-git-send-email-cdall@cs.columbia.edu>
References: <1367333376-30983-1-git-send-email-cdall@cs.columbia.edu>
Message-ID: <1367333376-30983-6-git-send-email-cdall@cs.columbia.edu>

From: Marc Zyngier <marc.zyngier at arm.com>

After the HYP page table rework, it is pretty easy to let the KVM
code provide its own idmap, rather than expecting the kernel to
provide it. It takes actually less code to do so.

Acked-by: Will Deacon <will.deacon at arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
Signed-off-by: Christoffer Dall <cdall at cs.columbia.edu>
---
 arch/arm/include/asm/idmap.h   |    1 -
 arch/arm/include/asm/kvm_mmu.h |    1 -
 arch/arm/kvm/mmu.c             |   24 +++++++++++++++++++++++-
 arch/arm/mm/idmap.c            |   32 +-------------------------------
 4 files changed, 24 insertions(+), 34 deletions(-)

diff --git a/arch/arm/include/asm/idmap.h b/arch/arm/include/asm/idmap.h
index 1a66f907..bf863ed 100644
--- a/arch/arm/include/asm/idmap.h
+++ b/arch/arm/include/asm/idmap.h
@@ -8,7 +8,6 @@
 #define __idmap __section(.idmap.text) noinline notrace
 
 extern pgd_t *idmap_pgd;
-extern pgd_t *hyp_pgd;
 
 void setup_mm_for_reboot(void);
 
diff --git a/arch/arm/include/asm/kvm_mmu.h b/arch/arm/include/asm/kvm_mmu.h
index 970f3b5..3c71a1d 100644
--- a/arch/arm/include/asm/kvm_mmu.h
+++ b/arch/arm/include/asm/kvm_mmu.h
@@ -21,7 +21,6 @@
 
 #include <asm/cacheflush.h>
 #include <asm/pgalloc.h>
-#include <asm/idmap.h>
 
 /*
  * We directly use the kernel VA for the HYP, as we can directly share
diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
index 96d61da..bfc5927 100644
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@ -32,6 +32,7 @@
 
 extern char  __hyp_idmap_text_start[], __hyp_idmap_text_end[];
 
+static pgd_t *hyp_pgd;
 static DEFINE_MUTEX(kvm_hyp_pgd_mutex);
 
 static void kvm_tlb_flush_vmid_ipa(struct kvm *kvm, phys_addr_t ipa)
@@ -715,12 +716,33 @@ phys_addr_t kvm_mmu_get_httbr(void)
 
 int kvm_mmu_init(void)
 {
+	unsigned long hyp_idmap_start = virt_to_phys(__hyp_idmap_text_start);
+	unsigned long hyp_idmap_end = virt_to_phys(__hyp_idmap_text_end);
+	int err;
+
+	hyp_pgd = kzalloc(PTRS_PER_PGD * sizeof(pgd_t), GFP_KERNEL);
 	if (!hyp_pgd) {
 		kvm_err("Hyp mode PGD not allocated\n");
-		return -ENOMEM;
+		err = -ENOMEM;
+		goto out;
+	}
+
+	/* Create the idmap in the boot page tables */
+	err = 	__create_hyp_mappings(boot_hyp_pgd,
+				      hyp_idmap_start, hyp_idmap_end,
+				      __phys_to_pfn(hyp_idmap_start),
+				      PAGE_HYP);
+
+	if (err) {
+		kvm_err("Failed to idmap %lx-%lx\n",
+			hyp_idmap_start, hyp_idmap_end);
+		goto out;
 	}
 
 	return 0;
+out:
+	kfree(hyp_pgd);
+	return err;
 }
 
 /**
diff --git a/arch/arm/mm/idmap.c b/arch/arm/mm/idmap.c
index 5ee505c..83cb3ac 100644
--- a/arch/arm/mm/idmap.c
+++ b/arch/arm/mm/idmap.c
@@ -8,7 +8,6 @@
 #include <asm/pgtable.h>
 #include <asm/sections.h>
 #include <asm/system_info.h>
-#include <asm/virt.h>
 
 pgd_t *idmap_pgd;
 
@@ -83,37 +82,10 @@ static void identity_mapping_add(pgd_t *pgd, const char *text_start,
 	} while (pgd++, addr = next, addr != end);
 }
 
-#if defined(CONFIG_ARM_VIRT_EXT) && defined(CONFIG_ARM_LPAE)
-pgd_t *hyp_pgd;
-
-extern char  __hyp_idmap_text_start[], __hyp_idmap_text_end[];
-
-static int __init init_static_idmap_hyp(void)
-{
-	hyp_pgd = kzalloc(PTRS_PER_PGD * sizeof(pgd_t), GFP_KERNEL);
-	if (!hyp_pgd)
-		return -ENOMEM;
-
-	pr_info("Setting up static HYP identity map for 0x%p - 0x%p\n",
-		__hyp_idmap_text_start, __hyp_idmap_text_end);
-	identity_mapping_add(hyp_pgd, __hyp_idmap_text_start,
-			     __hyp_idmap_text_end, PMD_SECT_AP1);
-
-	return 0;
-}
-#else
-static int __init init_static_idmap_hyp(void)
-{
-	return 0;
-}
-#endif
-
 extern char  __idmap_text_start[], __idmap_text_end[];
 
 static int __init init_static_idmap(void)
 {
-	int ret;
-
 	idmap_pgd = pgd_alloc(&init_mm);
 	if (!idmap_pgd)
 		return -ENOMEM;
@@ -123,12 +95,10 @@ static int __init init_static_idmap(void)
 	identity_mapping_add(idmap_pgd, __idmap_text_start,
 			     __idmap_text_end, 0);
 
-	ret = init_static_idmap_hyp();
-
 	/* Flush L1 for the hardware to see this page table content */
 	flush_cache_louis();
 
-	return ret;
+	return 0;
 }
 early_initcall(init_static_idmap);
 
-- 
1.7.9.5



From cdall at cs.columbia.edu  Tue Apr 30 10:49:27 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Tue, 30 Apr 2013 07:49:27 -0700
Subject: [PATCH 06/15] ARM: KVM: enforce maximum size for identity mapped code
In-Reply-To: <1367333376-30983-1-git-send-email-cdall@cs.columbia.edu>
References: <1367333376-30983-1-git-send-email-cdall@cs.columbia.edu>
Message-ID: <1367333376-30983-7-git-send-email-cdall@cs.columbia.edu>

From: Marc Zyngier <marc.zyngier at arm.com>

We're about to move to an init procedure where we rely on the
fact that the init code fits in a single page. Make sure we
align the idmap text on a vector alignment, and that the code is
not bigger than a single page.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
Signed-off-by: Christoffer Dall <cdall at cs.columbia.edu>
---
 arch/arm/kernel/vmlinux.lds.S |    7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
index b571484..a871b8e 100644
--- a/arch/arm/kernel/vmlinux.lds.S
+++ b/arch/arm/kernel/vmlinux.lds.S
@@ -20,7 +20,7 @@
 	VMLINUX_SYMBOL(__idmap_text_start) = .;				\
 	*(.idmap.text)							\
 	VMLINUX_SYMBOL(__idmap_text_end) = .;				\
-	ALIGN_FUNCTION();						\
+	. = ALIGN(32);							\
 	VMLINUX_SYMBOL(__hyp_idmap_text_start) = .;			\
 	*(.hyp.idmap.text)						\
 	VMLINUX_SYMBOL(__hyp_idmap_text_end) = .;
@@ -315,3 +315,8 @@ SECTIONS
  */
 ASSERT((__proc_info_end - __proc_info_begin), "missing CPU support")
 ASSERT((__arch_info_end - __arch_info_begin), "no machine record defined")
+/*
+ * The HYP init code can't be more than a page long.
+ * The above comment applies as well.
+ */
+ASSERT(((__hyp_idmap_text_end - __hyp_idmap_text_start) <= PAGE_SIZE), "HYP init code too big")
-- 
1.7.9.5



From cdall at cs.columbia.edu  Tue Apr 30 10:49:28 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Tue, 30 Apr 2013 07:49:28 -0700
Subject: [PATCH 07/15] ARM: KVM: rework HYP page table freeing
In-Reply-To: <1367333376-30983-1-git-send-email-cdall@cs.columbia.edu>
References: <1367333376-30983-1-git-send-email-cdall@cs.columbia.edu>
Message-ID: <1367333376-30983-8-git-send-email-cdall@cs.columbia.edu>

From: Marc Zyngier <marc.zyngier at arm.com>

There is no point in freeing HYP page tables differently from Stage-2.
They now have the same requirements, and should be dealt with the same way.

Promote unmap_stage2_range to be The One True Way, and get rid of a number
of nasty bugs in the process (good thing we never actually called free_hyp_pmds
before...).

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
Signed-off-by: Christoffer Dall <cdall at cs.columbia.edu>
---
 arch/arm/include/asm/kvm_mmu.h |    2 +-
 arch/arm/kvm/arm.c             |    2 +-
 arch/arm/kvm/mmu.c             |  181 ++++++++++++++++++----------------------
 3 files changed, 82 insertions(+), 103 deletions(-)

diff --git a/arch/arm/include/asm/kvm_mmu.h b/arch/arm/include/asm/kvm_mmu.h
index 3c71a1d..92eb20d 100644
--- a/arch/arm/include/asm/kvm_mmu.h
+++ b/arch/arm/include/asm/kvm_mmu.h
@@ -32,7 +32,7 @@
 
 int create_hyp_mappings(void *from, void *to);
 int create_hyp_io_mappings(void *from, void *to, phys_addr_t);
-void free_hyp_pmds(void);
+void free_hyp_pgds(void);
 
 int kvm_alloc_stage2_pgd(struct kvm *kvm);
 void kvm_free_stage2_pgd(struct kvm *kvm);
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index 7403f88..16f164a 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -928,7 +928,7 @@ static int init_hyp_mode(void)
 out_free_vfp:
 	free_percpu(kvm_host_vfp_state);
 out_free_mappings:
-	free_hyp_pmds();
+	free_hyp_pgds();
 out_free_stack_pages:
 	for_each_possible_cpu(cpu)
 		free_page(per_cpu(kvm_arm_hyp_stack_page, cpu));
diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
index bfc5927..7464824 100644
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@ -72,56 +72,104 @@ static void *mmu_memory_cache_alloc(struct kvm_mmu_memory_cache *mc)
 	return p;
 }
 
-static void free_ptes(pmd_t *pmd, unsigned long addr)
+static void clear_pud_entry(pud_t *pud)
 {
-	pte_t *pte;
-	unsigned int i;
+	pmd_t *pmd_table = pmd_offset(pud, 0);
+	pud_clear(pud);
+	pmd_free(NULL, pmd_table);
+	put_page(virt_to_page(pud));
+}
 
-	for (i = 0; i < PTRS_PER_PMD; i++, addr += PMD_SIZE) {
-		if (!pmd_none(*pmd) && pmd_table(*pmd)) {
-			pte = pte_offset_kernel(pmd, addr);
-			pte_free_kernel(NULL, pte);
-		}
-		pmd++;
+static void clear_pmd_entry(pmd_t *pmd)
+{
+	pte_t *pte_table = pte_offset_kernel(pmd, 0);
+	pmd_clear(pmd);
+	pte_free_kernel(NULL, pte_table);
+	put_page(virt_to_page(pmd));
+}
+
+static bool pmd_empty(pmd_t *pmd)
+{
+	struct page *pmd_page = virt_to_page(pmd);
+	return page_count(pmd_page) == 1;
+}
+
+static void clear_pte_entry(pte_t *pte)
+{
+	if (pte_present(*pte)) {
+		kvm_set_pte(pte, __pte(0));
+		put_page(virt_to_page(pte));
 	}
 }
 
-static void free_hyp_pgd_entry(unsigned long addr)
+static bool pte_empty(pte_t *pte)
+{
+	struct page *pte_page = virt_to_page(pte);
+	return page_count(pte_page) == 1;
+}
+
+static void unmap_range(pgd_t *pgdp, unsigned long long start, u64 size)
 {
 	pgd_t *pgd;
 	pud_t *pud;
 	pmd_t *pmd;
-	unsigned long hyp_addr = KERN_TO_HYP(addr);
+	pte_t *pte;
+	unsigned long long addr = start, end = start + size;
+	u64 range;
 
-	pgd = hyp_pgd + pgd_index(hyp_addr);
-	pud = pud_offset(pgd, hyp_addr);
+	while (addr < end) {
+		pgd = pgdp + pgd_index(addr);
+		pud = pud_offset(pgd, addr);
+		if (pud_none(*pud)) {
+			addr += PUD_SIZE;
+			continue;
+		}
 
-	if (pud_none(*pud))
-		return;
-	BUG_ON(pud_bad(*pud));
+		pmd = pmd_offset(pud, addr);
+		if (pmd_none(*pmd)) {
+			addr += PMD_SIZE;
+			continue;
+		}
 
-	pmd = pmd_offset(pud, hyp_addr);
-	free_ptes(pmd, addr);
-	pmd_free(NULL, pmd);
-	pud_clear(pud);
+		pte = pte_offset_kernel(pmd, addr);
+		clear_pte_entry(pte);
+		range = PAGE_SIZE;
+
+		/* If we emptied the pte, walk back up the ladder */
+		if (pte_empty(pte)) {
+			clear_pmd_entry(pmd);
+			range = PMD_SIZE;
+			if (pmd_empty(pmd)) {
+				clear_pud_entry(pud);
+				range = PUD_SIZE;
+			}
+		}
+
+		addr += range;
+	}
 }
 
 /**
- * free_hyp_pmds - free a Hyp-mode level-2 tables and child level-3 tables
+ * free_hyp_pgds - free Hyp-mode page tables
  *
- * Assumes this is a page table used strictly in Hyp-mode and therefore contains
+ * Assumes hyp_pgd is a page table used strictly in Hyp-mode and therefore contains
  * either mappings in the kernel memory area (above PAGE_OFFSET), or
  * device mappings in the vmalloc range (from VMALLOC_START to VMALLOC_END).
  */
-void free_hyp_pmds(void)
+void free_hyp_pgds(void)
 {
 	unsigned long addr;
 
 	mutex_lock(&kvm_hyp_pgd_mutex);
-	for (addr = PAGE_OFFSET; virt_addr_valid(addr); addr += PGDIR_SIZE)
-		free_hyp_pgd_entry(addr);
-	for (addr = VMALLOC_START; is_vmalloc_addr((void*)addr); addr += PGDIR_SIZE)
-		free_hyp_pgd_entry(addr);
+
+	if (hyp_pgd) {
+		for (addr = PAGE_OFFSET; virt_addr_valid(addr); addr += PGDIR_SIZE)
+			unmap_range(hyp_pgd, KERN_TO_HYP(addr), PGDIR_SIZE);
+		for (addr = VMALLOC_START; is_vmalloc_addr((void*)addr); addr += PGDIR_SIZE)
+			unmap_range(hyp_pgd, KERN_TO_HYP(addr), PGDIR_SIZE);
+		kfree(hyp_pgd);
+	}
+
 	mutex_unlock(&kvm_hyp_pgd_mutex);
 }
 
@@ -136,6 +184,7 @@ static void create_hyp_pte_mappings(pmd_t *pmd, unsigned long start,
 	do {
 		pte = pte_offset_kernel(pmd, addr);
 		kvm_set_pte(pte, pfn_pte(pfn, prot));
+		get_page(virt_to_page(pte));
 		pfn++;
 	} while (addr += PAGE_SIZE, addr != end);
 }
@@ -161,6 +210,7 @@ static int create_hyp_pmd_mappings(pud_t *pud, unsigned long start,
 				return -ENOMEM;
 			}
 			pmd_populate_kernel(NULL, pmd, pte);
+			get_page(virt_to_page(pmd));
 		}
 
 		next = pmd_addr_end(addr, end);
@@ -197,6 +247,7 @@ static int __create_hyp_mappings(pgd_t *pgdp,
 				goto out;
 			}
 			pud_populate(NULL, pud, pmd);
+			get_page(virt_to_page(pud));
 		}
 
 		next = pgd_addr_end(addr, end);
@@ -289,42 +340,6 @@ int kvm_alloc_stage2_pgd(struct kvm *kvm)
 	return 0;
 }
 
-static void clear_pud_entry(pud_t *pud)
-{
-	pmd_t *pmd_table = pmd_offset(pud, 0);
-	pud_clear(pud);
-	pmd_free(NULL, pmd_table);
-	put_page(virt_to_page(pud));
-}
-
-static void clear_pmd_entry(pmd_t *pmd)
-{
-	pte_t *pte_table = pte_offset_kernel(pmd, 0);
-	pmd_clear(pmd);
-	pte_free_kernel(NULL, pte_table);
-	put_page(virt_to_page(pmd));
-}
-
-static bool pmd_empty(pmd_t *pmd)
-{
-	struct page *pmd_page = virt_to_page(pmd);
-	return page_count(pmd_page) == 1;
-}
-
-static void clear_pte_entry(pte_t *pte)
-{
-	if (pte_present(*pte)) {
-		kvm_set_pte(pte, __pte(0));
-		put_page(virt_to_page(pte));
-	}
-}
-
-static bool pte_empty(pte_t *pte)
-{
-	struct page *pte_page = virt_to_page(pte);
-	return page_count(pte_page) == 1;
-}
-
 /**
  * unmap_stage2_range -- Clear stage2 page table entries to unmap a range
  * @kvm:   The VM pointer
@@ -338,43 +353,7 @@ static bool pte_empty(pte_t *pte)
  */
 static void unmap_stage2_range(struct kvm *kvm, phys_addr_t start, u64 size)
 {
-	pgd_t *pgd;
-	pud_t *pud;
-	pmd_t *pmd;
-	pte_t *pte;
-	phys_addr_t addr = start, end = start + size;
-	u64 range;
-
-	while (addr < end) {
-		pgd = kvm->arch.pgd + pgd_index(addr);
-		pud = pud_offset(pgd, addr);
-		if (pud_none(*pud)) {
-			addr += PUD_SIZE;
-			continue;
-		}
-
-		pmd = pmd_offset(pud, addr);
-		if (pmd_none(*pmd)) {
-			addr += PMD_SIZE;
-			continue;
-		}
-
-		pte = pte_offset_kernel(pmd, addr);
-		clear_pte_entry(pte);
-		range = PAGE_SIZE;
-
-		/* If we emptied the pte, walk back up the ladder */
-		if (pte_empty(pte)) {
-			clear_pmd_entry(pmd);
-			range = PMD_SIZE;
-			if (pmd_empty(pmd)) {
-				clear_pud_entry(pud);
-				range = PUD_SIZE;
-			}
-		}
-
-		addr += range;
-	}
+	unmap_range(kvm->arch.pgd, start, size);
 }
 
 /**
@@ -741,7 +720,7 @@ int kvm_mmu_init(void)
 
 	return 0;
 out:
-	kfree(hyp_pgd);
+	free_hyp_pgds();
 	return err;
 }
 
-- 
1.7.9.5



From cdall at cs.columbia.edu  Tue Apr 30 10:49:31 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Tue, 30 Apr 2013 07:49:31 -0700
Subject: [PATCH 10/15] ARM: KVM: add architecture specific hook for
 capabilities
In-Reply-To: <1367333376-30983-1-git-send-email-cdall@cs.columbia.edu>
References: <1367333376-30983-1-git-send-email-cdall@cs.columbia.edu>
Message-ID: <1367333376-30983-11-git-send-email-cdall@cs.columbia.edu>

From: Marc Zyngier <marc.zyngier at arm.com>

Most of the capabilities are common to both arm and arm64, but
we still need to handle the exceptions.

Introduce kvm_arch_dev_ioctl_check_extension, which both architectures
implement (in the 32bit case, it just returns 0).

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
Signed-off-by: Christoffer Dall <cdall at cs.columbia.edu>
---
 arch/arm/include/asm/kvm_host.h |    5 +++++
 arch/arm/kvm/arm.c              |    2 +-
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
index 6c2a35d..dcfcbf5 100644
--- a/arch/arm/include/asm/kvm_host.h
+++ b/arch/arm/include/asm/kvm_host.h
@@ -214,6 +214,11 @@ static inline void __cpu_init_hyp_mode(unsigned long long boot_pgd_ptr,
 	kvm_call_hyp((void*)hyp_stack_ptr, vector_ptr, pgd_ptr);
 }
 
+static inline int kvm_arch_dev_ioctl_check_extension(long ext)
+{
+	return 0;
+}
+
 int kvm_perf_init(void);
 int kvm_perf_teardown(void);
 
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index 6ea2aed..cc67caf 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -206,7 +206,7 @@ int kvm_dev_ioctl_check_extension(long ext)
 		r = KVM_MAX_VCPUS;
 		break;
 	default:
-		r = 0;
+		r = kvm_arch_dev_ioctl_check_extension(ext);
 		break;
 	}
 	return r;
-- 
1.7.9.5



From cdall at cs.columbia.edu  Tue Apr 30 10:49:35 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Tue, 30 Apr 2013 07:49:35 -0700
Subject: [PATCH 14/15] KVM: ARM: Fix spelling in error message
In-Reply-To: <1367333376-30983-1-git-send-email-cdall@cs.columbia.edu>
References: <1367333376-30983-1-git-send-email-cdall@cs.columbia.edu>
Message-ID: <1367333376-30983-15-git-send-email-cdall@cs.columbia.edu>

s/unkown/unknown/

Signed-off-by: Christoffer Dall <cdall at cs.columbia.edu>
---
 arch/arm/kvm/handle_exit.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/kvm/handle_exit.c b/arch/arm/kvm/handle_exit.c
index 26ad173..3d74a0b 100644
--- a/arch/arm/kvm/handle_exit.c
+++ b/arch/arm/kvm/handle_exit.c
@@ -115,7 +115,7 @@ static exit_handle_fn kvm_get_exit_handler(struct kvm_vcpu *vcpu)
 
 	if (hsr_ec >= ARRAY_SIZE(arm_exit_handlers) ||
 	    !arm_exit_handlers[hsr_ec]) {
-		kvm_err("Unkown exception class: hsr: %#08x\n",
+		kvm_err("Unknown exception class: hsr: %#08x\n",
 			(unsigned int)kvm_vcpu_get_hsr(vcpu));
 		BUG();
 	}
-- 
1.7.9.5



From cdall at cs.columbia.edu  Tue Apr 30 10:49:32 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Tue, 30 Apr 2013 07:49:32 -0700
Subject: [PATCH 11/15] ARM: KVM: promote vfp_host pointer to generic host cpu
 context
In-Reply-To: <1367333376-30983-1-git-send-email-cdall@cs.columbia.edu>
References: <1367333376-30983-1-git-send-email-cdall@cs.columbia.edu>
Message-ID: <1367333376-30983-12-git-send-email-cdall@cs.columbia.edu>

From: Marc Zyngier <marc.zyngier at arm.com>

We use the vfp_host pointer to store the host VFP context, should
the guest start using VFP itself.

Actually, we can use this pointer in a more generic way to store
CPU speficic data, and arm64 is using it to dump the whole host
state before switching to the guest.

Simply rename the vfp_host field to host_cpu_context, and the
corresponding type to kvm_cpu_context_t. No change in functionnality.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
Signed-off-by: Christoffer Dall <cdall at cs.columbia.edu>
---
 arch/arm/include/asm/kvm_host.h |    8 +++++---
 arch/arm/kernel/asm-offsets.c   |    2 +-
 arch/arm/kvm/arm.c              |   28 ++++++++++++++--------------
 3 files changed, 20 insertions(+), 18 deletions(-)

diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
index dcfcbf5..57cb786 100644
--- a/arch/arm/include/asm/kvm_host.h
+++ b/arch/arm/include/asm/kvm_host.h
@@ -87,7 +87,7 @@ struct kvm_vcpu_fault_info {
 	u32 hyp_pc;		/* PC when exception was taken from Hyp mode */
 };
 
-typedef struct vfp_hard_struct kvm_kernel_vfp_t;
+typedef struct vfp_hard_struct kvm_cpu_context_t;
 
 struct kvm_vcpu_arch {
 	struct kvm_regs regs;
@@ -105,8 +105,10 @@ struct kvm_vcpu_arch {
 	struct kvm_vcpu_fault_info fault;
 
 	/* Floating point registers (VFP and Advanced SIMD/NEON) */
-	kvm_kernel_vfp_t vfp_guest;
-	kvm_kernel_vfp_t *vfp_host;
+	struct vfp_hard_struct vfp_guest;
+
+	/* Host FP context */
+	kvm_cpu_context_t *host_cpu_context;
 
 	/* VGIC state */
 	struct vgic_cpu vgic_cpu;
diff --git a/arch/arm/kernel/asm-offsets.c b/arch/arm/kernel/asm-offsets.c
index ee1ac39..92562a2 100644
--- a/arch/arm/kernel/asm-offsets.c
+++ b/arch/arm/kernel/asm-offsets.c
@@ -154,7 +154,7 @@ int main(void)
   DEFINE(VCPU_MIDR,		offsetof(struct kvm_vcpu, arch.midr));
   DEFINE(VCPU_CP15,		offsetof(struct kvm_vcpu, arch.cp15));
   DEFINE(VCPU_VFP_GUEST,	offsetof(struct kvm_vcpu, arch.vfp_guest));
-  DEFINE(VCPU_VFP_HOST,		offsetof(struct kvm_vcpu, arch.vfp_host));
+  DEFINE(VCPU_VFP_HOST,		offsetof(struct kvm_vcpu, arch.host_cpu_context));
   DEFINE(VCPU_REGS,		offsetof(struct kvm_vcpu, arch.regs));
   DEFINE(VCPU_USR_REGS,		offsetof(struct kvm_vcpu, arch.regs.usr_regs));
   DEFINE(VCPU_SVC_REGS,		offsetof(struct kvm_vcpu, arch.regs.svc_regs));
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index cc67caf..089c0a4 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -49,7 +49,7 @@ __asm__(".arch_extension	virt");
 #endif
 
 static DEFINE_PER_CPU(unsigned long, kvm_arm_hyp_stack_page);
-static kvm_kernel_vfp_t __percpu *kvm_host_vfp_state;
+static kvm_cpu_context_t __percpu *kvm_host_cpu_state;
 static unsigned long hyp_default_vectors;
 
 /* Per-CPU variable containing the currently running vcpu. */
@@ -317,7 +317,7 @@ void kvm_arch_vcpu_uninit(struct kvm_vcpu *vcpu)
 void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
 {
 	vcpu->cpu = cpu;
-	vcpu->arch.vfp_host = this_cpu_ptr(kvm_host_vfp_state);
+	vcpu->arch.host_cpu_context = this_cpu_ptr(kvm_host_cpu_state);
 
 	/*
 	 * Check whether this vcpu requires the cache to be flushed on
@@ -882,24 +882,24 @@ static int init_hyp_mode(void)
 	}
 
 	/*
-	 * Map the host VFP structures
+	 * Map the host CPU structures
 	 */
-	kvm_host_vfp_state = alloc_percpu(kvm_kernel_vfp_t);
-	if (!kvm_host_vfp_state) {
+	kvm_host_cpu_state = alloc_percpu(kvm_cpu_context_t);
+	if (!kvm_host_cpu_state) {
 		err = -ENOMEM;
-		kvm_err("Cannot allocate host VFP state\n");
+		kvm_err("Cannot allocate host CPU state\n");
 		goto out_free_mappings;
 	}
 
 	for_each_possible_cpu(cpu) {
-		kvm_kernel_vfp_t *vfp;
+		kvm_cpu_context_t *cpu_ctxt;
 
-		vfp = per_cpu_ptr(kvm_host_vfp_state, cpu);
-		err = create_hyp_mappings(vfp, vfp + 1);
+		cpu_ctxt = per_cpu_ptr(kvm_host_cpu_state, cpu);
+		err = create_hyp_mappings(cpu_ctxt, cpu_ctxt + 1);
 
 		if (err) {
-			kvm_err("Cannot map host VFP state: %d\n", err);
-			goto out_free_vfp;
+			kvm_err("Cannot map host CPU state: %d\n", err);
+			goto out_free_context;
 		}
 	}
 
@@ -913,7 +913,7 @@ static int init_hyp_mode(void)
 	 */
 	err = kvm_vgic_hyp_init();
 	if (err)
-		goto out_free_vfp;
+		goto out_free_context;
 
 #ifdef CONFIG_KVM_ARM_VGIC
 		vgic_present = true;
@@ -935,8 +935,8 @@ static int init_hyp_mode(void)
 	kvm_info("Hyp mode initialized successfully\n");
 
 	return 0;
-out_free_vfp:
-	free_percpu(kvm_host_vfp_state);
+out_free_context:
+	free_percpu(kvm_host_cpu_state);
 out_free_mappings:
 	free_hyp_pgds();
 out_free_stack_pages:
-- 
1.7.9.5



From cdall at cs.columbia.edu  Tue Apr 30 10:49:30 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Tue, 30 Apr 2013 07:49:30 -0700
Subject: [PATCH 09/15] ARM: KVM: perform HYP initilization for hotplugged CPUs
In-Reply-To: <1367333376-30983-1-git-send-email-cdall@cs.columbia.edu>
References: <1367333376-30983-1-git-send-email-cdall@cs.columbia.edu>
Message-ID: <1367333376-30983-10-git-send-email-cdall@cs.columbia.edu>

From: Marc Zyngier <marc.zyngier at arm.com>

Now that we have the necessary infrastructure to boot a hotplugged CPU
at any point in time, wire a CPU notifier that will perform the HYP
init for the incoming CPU.

Note that this depends on the platform code and/or firmware to boot the
incoming CPU with HYP mode enabled and return to the kernel by following
the normal boot path (HYP stub installed).

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
Signed-off-by: Christoffer Dall <cdall at cs.columbia.edu>
---
 arch/arm/include/asm/kvm_mmu.h |    1 +
 arch/arm/kvm/arm.c             |   49 ++++++++++++++++++++++++++++------------
 arch/arm/kvm/mmu.c             |   35 ++++++++++++++++++++++------
 3 files changed, 63 insertions(+), 22 deletions(-)

diff --git a/arch/arm/include/asm/kvm_mmu.h b/arch/arm/include/asm/kvm_mmu.h
index 24b767a..472ac70 100644
--- a/arch/arm/include/asm/kvm_mmu.h
+++ b/arch/arm/include/asm/kvm_mmu.h
@@ -44,6 +44,7 @@
 
 int create_hyp_mappings(void *from, void *to);
 int create_hyp_io_mappings(void *from, void *to, phys_addr_t);
+void free_boot_hyp_pgd(void);
 void free_hyp_pgds(void);
 
 int kvm_alloc_stage2_pgd(struct kvm *kvm);
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index fc47bd7..6ea2aed 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -16,6 +16,7 @@
  * Foundation, 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.
  */
 
+#include <linux/cpu.h>
 #include <linux/errno.h>
 #include <linux/err.h>
 #include <linux/kvm_host.h>
@@ -785,7 +786,7 @@ long kvm_arch_vm_ioctl(struct file *filp,
 	}
 }
 
-static void cpu_init_hyp_mode(void *vector)
+static void cpu_init_hyp_mode(void *dummy)
 {
 	unsigned long long boot_pgd_ptr;
 	unsigned long long pgd_ptr;
@@ -805,12 +806,28 @@ static void cpu_init_hyp_mode(void *vector)
 	__cpu_init_hyp_mode(boot_pgd_ptr, pgd_ptr, hyp_stack_ptr, vector_ptr);
 }
 
+static int hyp_init_cpu_notify(struct notifier_block *self,
+			       unsigned long action, void *cpu)
+{
+	switch (action) {
+	case CPU_STARTING:
+	case CPU_STARTING_FROZEN:
+		cpu_init_hyp_mode(NULL);
+		break;
+	}
+
+	return NOTIFY_OK;
+}
+
+static struct notifier_block hyp_init_cpu_nb = {
+	.notifier_call = hyp_init_cpu_notify,
+};
+
 /**
  * Inits Hyp-mode on all online CPUs
  */
 static int init_hyp_mode(void)
 {
-	phys_addr_t init_phys_addr;
 	int cpu;
 	int err = 0;
 
@@ -843,19 +860,6 @@ static int init_hyp_mode(void)
 	}
 
 	/*
-	 * Execute the init code on each CPU.
-	 *
-	 * Note: The stack is not mapped yet, so don't do anything else than
-	 * initializing the hypervisor mode on each CPU using a local stack
-	 * space for temporary storage.
-	 */
-	init_phys_addr = virt_to_phys(__kvm_hyp_init);
-	for_each_online_cpu(cpu) {
-		smp_call_function_single(cpu, cpu_init_hyp_mode,
-					 (void *)(long)init_phys_addr, 1);
-	}
-
-	/*
 	 * Map the Hyp-code called directly from the host
 	 */
 	err = create_hyp_mappings(__kvm_hyp_code_start, __kvm_hyp_code_end);
@@ -900,6 +904,11 @@ static int init_hyp_mode(void)
 	}
 
 	/*
+	 * Execute the init code on each CPU.
+	 */
+	on_each_cpu(cpu_init_hyp_mode, NULL, 1);
+
+	/*
 	 * Init HYP view of VGIC
 	 */
 	err = kvm_vgic_hyp_init();
@@ -917,6 +926,10 @@ static int init_hyp_mode(void)
 	if (err)
 		goto out_free_mappings;
 
+#ifndef CONFIG_HOTPLUG_CPU
+	free_boot_hyp_pgd();
+#endif
+
 	kvm_perf_init();
 
 	kvm_info("Hyp mode initialized successfully\n");
@@ -955,6 +968,12 @@ int kvm_arch_init(void *opaque)
 	if (err)
 		goto out_err;
 
+	err = register_cpu_notifier(&hyp_init_cpu_nb);
+	if (err) {
+		kvm_err("Cannot register HYP init CPU notifier (%d)\n", err);
+		goto out_err;
+	}
+
 	kvm_coproc_table_init();
 	return 0;
 out_err:
diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
index 4646c17..9657065 100644
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@ -156,6 +156,31 @@ static void unmap_range(pgd_t *pgdp, unsigned long long start, u64 size)
 }
 
 /**
+ * free_boot_hyp_pgd - free HYP boot page tables
+ *
+ * Free the HYP boot page tables. The bounce page is also freed.
+ */
+void free_boot_hyp_pgd(void)
+{
+	mutex_lock(&kvm_hyp_pgd_mutex);
+
+	if (boot_hyp_pgd) {
+		unmap_range(boot_hyp_pgd, hyp_idmap_start, PAGE_SIZE);
+		unmap_range(boot_hyp_pgd, TRAMPOLINE_VA, PAGE_SIZE);
+		kfree(boot_hyp_pgd);
+		boot_hyp_pgd = NULL;
+	}
+
+	if (hyp_pgd)
+		unmap_range(hyp_pgd, TRAMPOLINE_VA, PAGE_SIZE);
+
+	kfree(init_bounce_page);
+	init_bounce_page = NULL;
+
+	mutex_unlock(&kvm_hyp_pgd_mutex);
+}
+
+/**
  * free_hyp_pgds - free Hyp-mode page tables
  *
  * Assumes hyp_pgd is a page table used strictly in Hyp-mode and
@@ -169,13 +194,9 @@ void free_hyp_pgds(void)
 {
 	unsigned long addr;
 
-	mutex_lock(&kvm_hyp_pgd_mutex);
+	free_boot_hyp_pgd();
 
-	if (boot_hyp_pgd) {
-		unmap_range(boot_hyp_pgd, hyp_idmap_start, PAGE_SIZE);
-		unmap_range(boot_hyp_pgd, TRAMPOLINE_VA, PAGE_SIZE);
-		kfree(boot_hyp_pgd);
-	}
+	mutex_lock(&kvm_hyp_pgd_mutex);
 
 	if (hyp_pgd) {
 		for (addr = PAGE_OFFSET; virt_addr_valid(addr); addr += PGDIR_SIZE)
@@ -183,9 +204,9 @@ void free_hyp_pgds(void)
 		for (addr = VMALLOC_START; is_vmalloc_addr((void*)addr); addr += PGDIR_SIZE)
 			unmap_range(hyp_pgd, KERN_TO_HYP(addr), PGDIR_SIZE);
 		kfree(hyp_pgd);
+		hyp_pgd = NULL;
 	}
 
-	kfree(init_bounce_page);
 	mutex_unlock(&kvm_hyp_pgd_mutex);
 }
 
-- 
1.7.9.5



From cdall at cs.columbia.edu  Tue Apr 30 10:49:29 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Tue, 30 Apr 2013 07:49:29 -0700
Subject: [PATCH 08/15] ARM: KVM: switch to a dual-step HYP init code
In-Reply-To: <1367333376-30983-1-git-send-email-cdall@cs.columbia.edu>
References: <1367333376-30983-1-git-send-email-cdall@cs.columbia.edu>
Message-ID: <1367333376-30983-9-git-send-email-cdall@cs.columbia.edu>

From: Marc Zyngier <marc.zyngier at arm.com>

Our HYP init code suffers from two major design issues:
- it cannot support CPU hotplug, as we tear down the idmap very early
- it cannot perform a TLB invalidation when switching from init to
  runtime mappings, as pages are manipulated from PL1 exclusively

The hotplug problem mandates that we keep two sets of page tables
(boot and runtime). The TLB problem mandates that we're able to
transition from one PGD to another while in HYP, invalidating the TLBs
in the process.

To be able to do this, we need to share a page between the two page
tables. A page that will have the same VA in both configurations. All we
need is a VA that has the following properties:
- This VA can't be used to represent a kernel mapping.
- This VA will not conflict with the physical address of the kernel text

The vectors page seems to satisfy this requirement:
- The kernel never maps anything else there
- The kernel text being copied at the beginning of the physical memory,
  it is unlikely to use the last 64kB (I doubt we'll ever support KVM
  on a system with something like 4MB of RAM, but patches are very
  welcome).

Let's call this VA the trampoline VA.

Now, we map our init page at 3 locations:
- idmap in the boot pgd
- trampoline VA in the boot pgd
- trampoline VA in the runtime pgd

The init scenario is now the following:
- We jump in HYP with four parameters: boot HYP pgd, runtime HYP pgd,
  runtime stack, runtime vectors
- Enable the MMU with the boot pgd
- Jump to a target into the trampoline page (remember, this is the same
  physical page!)
- Now switch to the runtime pgd (same VA, and still the same physical
  page!)
- Invalidate TLBs
- Set stack and vectors
- Profit! (or eret, if you only care about the code).

Note that we keep the boot mapping permanently (it is not strictly an
idmap anymore) to allow for CPU hotplug in later patches.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
Signed-off-by: Christoffer Dall <cdall at cs.columbia.edu>
---
 arch/arm/include/asm/kvm_host.h |   31 +++++----
 arch/arm/include/asm/kvm_mmu.h  |   24 ++++++-
 arch/arm/kvm/arm.c              |   11 ++--
 arch/arm/kvm/init.S             |   78 +++++++++++++++++------
 arch/arm/kvm/mmu.c              |  132 ++++++++++++++++++++++++++++-----------
 5 files changed, 197 insertions(+), 79 deletions(-)

diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
index 78813b8..6c2a35d 100644
--- a/arch/arm/include/asm/kvm_host.h
+++ b/arch/arm/include/asm/kvm_host.h
@@ -188,23 +188,30 @@ int kvm_arm_coproc_set_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *);
 int handle_exit(struct kvm_vcpu *vcpu, struct kvm_run *run,
 		int exception_index);
 
-static inline void __cpu_init_hyp_mode(unsigned long long pgd_ptr,
+static inline void __cpu_init_hyp_mode(unsigned long long boot_pgd_ptr,
+				       unsigned long long pgd_ptr,
 				       unsigned long hyp_stack_ptr,
 				       unsigned long vector_ptr)
 {
-	unsigned long pgd_low, pgd_high;
-
-	pgd_low = (pgd_ptr & ((1ULL << 32) - 1));
-	pgd_high = (pgd_ptr >> 32ULL);
-
 	/*
-	 * Call initialization code, and switch to the full blown
-	 * HYP code. The init code doesn't need to preserve these registers as
-	 * r1-r3 and r12 are already callee save according to the AAPCS.
-	 * Note that we slightly misuse the prototype by casing the pgd_low to
-	 * a void *.
+	 * Call initialization code, and switch to the full blown HYP
+	 * code. The init code doesn't need to preserve these
+	 * registers as r0-r3 are already callee saved according to
+	 * the AAPCS.
+	 * Note that we slightly misuse the prototype by casing the
+	 * stack pointer to a void *.
+	 *
+	 * We don't have enough registers to perform the full init in
+	 * one go.  Install the boot PGD first, and then install the
+	 * runtime PGD, stack pointer and vectors. The PGDs are always
+	 * passed as the third argument, in order to be passed into
+	 * r2-r3 to the init code (yes, this is compliant with the
+	 * PCS!).
 	 */
-	kvm_call_hyp((void *)pgd_low, pgd_high, hyp_stack_ptr, vector_ptr);
+
+	kvm_call_hyp(NULL, 0, boot_pgd_ptr);
+
+	kvm_call_hyp((void*)hyp_stack_ptr, vector_ptr, pgd_ptr);
 }
 
 int kvm_perf_init(void);
diff --git a/arch/arm/include/asm/kvm_mmu.h b/arch/arm/include/asm/kvm_mmu.h
index 92eb20d..24b767a 100644
--- a/arch/arm/include/asm/kvm_mmu.h
+++ b/arch/arm/include/asm/kvm_mmu.h
@@ -19,17 +19,29 @@
 #ifndef __ARM_KVM_MMU_H__
 #define __ARM_KVM_MMU_H__
 
-#include <asm/cacheflush.h>
-#include <asm/pgalloc.h>
+#include <asm/memory.h>
+#include <asm/page.h>
 
 /*
  * We directly use the kernel VA for the HYP, as we can directly share
  * the mapping (HTTBR "covers" TTBR1).
  */
-#define HYP_PAGE_OFFSET_MASK	(~0UL)
+#define HYP_PAGE_OFFSET_MASK	UL(~0)
 #define HYP_PAGE_OFFSET		PAGE_OFFSET
 #define KERN_TO_HYP(kva)	(kva)
 
+/*
+ * Our virtual mapping for the boot-time MMU-enable code. Must be
+ * shared across all the page-tables. Conveniently, we use the vectors
+ * page, where no kernel data will ever be shared with HYP.
+ */
+#define TRAMPOLINE_VA		UL(CONFIG_VECTORS_BASE)
+
+#ifndef __ASSEMBLY__
+
+#include <asm/cacheflush.h>
+#include <asm/pgalloc.h>
+
 int create_hyp_mappings(void *from, void *to);
 int create_hyp_io_mappings(void *from, void *to, phys_addr_t);
 void free_hyp_pgds(void);
@@ -44,6 +56,8 @@ int kvm_handle_guest_abort(struct kvm_vcpu *vcpu, struct kvm_run *run);
 void kvm_mmu_free_memory_caches(struct kvm_vcpu *vcpu);
 
 phys_addr_t kvm_mmu_get_httbr(void);
+phys_addr_t kvm_mmu_get_boot_httbr(void);
+phys_addr_t kvm_get_idmap_vector(void);
 int kvm_mmu_init(void);
 void kvm_clear_hyp_idmap(void);
 
@@ -113,4 +127,8 @@ static inline void coherent_icache_guest_page(struct kvm *kvm, gfn_t gfn)
 	}
 }
 
+#define kvm_flush_dcache_to_poc(a,l)	__cpuc_flush_dcache_area((a), (l))
+
+#endif	/* !__ASSEMBLY__ */
+
 #endif /* __ARM_KVM_MMU_H__ */
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index 16f164a..fc47bd7 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -787,20 +787,22 @@ long kvm_arch_vm_ioctl(struct file *filp,
 
 static void cpu_init_hyp_mode(void *vector)
 {
+	unsigned long long boot_pgd_ptr;
 	unsigned long long pgd_ptr;
 	unsigned long hyp_stack_ptr;
 	unsigned long stack_page;
 	unsigned long vector_ptr;
 
 	/* Switch from the HYP stub to our own HYP init vector */
-	__hyp_set_vectors((unsigned long)vector);
+	__hyp_set_vectors(kvm_get_idmap_vector());
 
+	boot_pgd_ptr = (unsigned long long)kvm_mmu_get_boot_httbr();
 	pgd_ptr = (unsigned long long)kvm_mmu_get_httbr();
 	stack_page = __get_cpu_var(kvm_arm_hyp_stack_page);
 	hyp_stack_ptr = stack_page + PAGE_SIZE;
 	vector_ptr = (unsigned long)__kvm_hyp_vector;
 
-	__cpu_init_hyp_mode(pgd_ptr, hyp_stack_ptr, vector_ptr);
+	__cpu_init_hyp_mode(boot_pgd_ptr, pgd_ptr, hyp_stack_ptr, vector_ptr);
 }
 
 /**
@@ -854,11 +856,6 @@ static int init_hyp_mode(void)
 	}
 
 	/*
-	 * Unmap the identity mapping
-	 */
-	kvm_clear_hyp_idmap();
-
-	/*
 	 * Map the Hyp-code called directly from the host
 	 */
 	err = create_hyp_mappings(__kvm_hyp_code_start, __kvm_hyp_code_end);
diff --git a/arch/arm/kvm/init.S b/arch/arm/kvm/init.S
index 9f37a79..f048338 100644
--- a/arch/arm/kvm/init.S
+++ b/arch/arm/kvm/init.S
@@ -21,13 +21,33 @@
 #include <asm/asm-offsets.h>
 #include <asm/kvm_asm.h>
 #include <asm/kvm_arm.h>
+#include <asm/kvm_mmu.h>
 
 /********************************************************************
  * Hypervisor initialization
  *   - should be called with:
- *       r0,r1 = Hypervisor pgd pointer
- *       r2 = top of Hyp stack (kernel VA)
- *       r3 = pointer to hyp vectors
+ *       r0 = top of Hyp stack (kernel VA)
+ *       r1 = pointer to hyp vectors
+ *       r2,r3 = Hypervisor pgd pointer
+ *
+ * The init scenario is:
+ * - We jump in HYP with four parameters: boot HYP pgd, runtime HYP pgd,
+ *   runtime stack, runtime vectors
+ * - Enable the MMU with the boot pgd
+ * - Jump to a target into the trampoline page (remember, this is the same
+ *   physical page!)
+ * - Now switch to the runtime pgd (same VA, and still the same physical
+ *   page!)
+ * - Invalidate TLBs
+ * - Set stack and vectors
+ * - Profit! (or eret, if you only care about the code).
+ *
+ * As we only have four registers available to pass parameters (and we
+ * need six), we split the init in two phases:
+ * - Phase 1: r0 = 0, r1 = 0, r2,r3 contain the boot PGD.
+ *   Provides the basic HYP init, and enable the MMU.
+ * - Phase 2: r0 = ToS, r1 = vectors, r2,r3 contain the runtime PGD.
+ *   Switches to the runtime PGD, set stack and vectors.
  */
 
 	.text
@@ -47,22 +67,25 @@ __kvm_hyp_init:
 	W(b)	.
 
 __do_hyp_init:
+	cmp	r0, #0			@ We have a SP?
+	bne	phase2			@ Yes, second stage init
+
 	@ Set the HTTBR to point to the hypervisor PGD pointer passed
-	mcrr	p15, 4, r0, r1, c2
+	mcrr	p15, 4, r2, r3, c2
 
 	@ Set the HTCR and VTCR to the same shareability and cacheability
 	@ settings as the non-secure TTBCR and with T0SZ == 0.
 	mrc	p15, 4, r0, c2, c0, 2	@ HTCR
-	ldr	r12, =HTCR_MASK
-	bic	r0, r0, r12
+	ldr	r2, =HTCR_MASK
+	bic	r0, r0, r2
 	mrc	p15, 0, r1, c2, c0, 2	@ TTBCR
 	and	r1, r1, #(HTCR_MASK & ~TTBCR_T0SZ)
 	orr	r0, r0, r1
 	mcr	p15, 4, r0, c2, c0, 2	@ HTCR
 
 	mrc	p15, 4, r1, c2, c1, 2	@ VTCR
-	ldr	r12, =VTCR_MASK
-	bic	r1, r1, r12
+	ldr	r2, =VTCR_MASK
+	bic	r1, r1, r2
 	bic	r0, r0, #(~VTCR_HTCR_SH)	@ clear non-reusable HTCR bits
 	orr	r1, r0, r1
 	orr	r1, r1, #(KVM_VTCR_SL0 | KVM_VTCR_T0SZ | KVM_VTCR_S)
@@ -85,24 +108,41 @@ __do_hyp_init:
 	@  - Memory alignment checks: enabled
 	@  - MMU: enabled (this code must be run from an identity mapping)
 	mrc	p15, 4, r0, c1, c0, 0	@ HSCR
-	ldr	r12, =HSCTLR_MASK
-	bic	r0, r0, r12
+	ldr	r2, =HSCTLR_MASK
+	bic	r0, r0, r2
 	mrc	p15, 0, r1, c1, c0, 0	@ SCTLR
-	ldr	r12, =(HSCTLR_EE | HSCTLR_FI | HSCTLR_I | HSCTLR_C)
-	and	r1, r1, r12
- ARM(	ldr	r12, =(HSCTLR_M | HSCTLR_A)			)
- THUMB(	ldr	r12, =(HSCTLR_M | HSCTLR_A | HSCTLR_TE)		)
-	orr	r1, r1, r12
+	ldr	r2, =(HSCTLR_EE | HSCTLR_FI | HSCTLR_I | HSCTLR_C)
+	and	r1, r1, r2
+ ARM(	ldr	r2, =(HSCTLR_M | HSCTLR_A)			)
+ THUMB(	ldr	r2, =(HSCTLR_M | HSCTLR_A | HSCTLR_TE)		)
+	orr	r1, r1, r2
 	orr	r0, r0, r1
 	isb
 	mcr	p15, 4, r0, c1, c0, 0	@ HSCR
-	isb
 
-	@ Set stack pointer and return to the kernel
-	mov	sp, r2
+	@ End of init phase-1
+	eret
+
+phase2:
+	@ Set stack pointer
+	mov	sp, r0
 
 	@ Set HVBAR to point to the HYP vectors
-	mcr	p15, 4, r3, c12, c0, 0	@ HVBAR
+	mcr	p15, 4, r1, c12, c0, 0	@ HVBAR
+
+	@ Jump to the trampoline page
+	ldr	r0, =TRAMPOLINE_VA
+	adr	r1, target
+	bfi	r0, r1, #0, #PAGE_SHIFT
+	mov	pc, r0
+
+target:	@ We're now in the trampoline code, switch page tables
+	mcrr	p15, 4, r2, r3, c2
+	isb
+
+	@ Invalidate the old TLBs
+	mcr	p15, 4, r0, c8, c7, 0	@ TLBIALLH
+	dsb
 
 	eret
 
diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
index 7464824..4646c17 100644
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@ -32,9 +32,15 @@
 
 extern char  __hyp_idmap_text_start[], __hyp_idmap_text_end[];
 
+static pgd_t *boot_hyp_pgd;
 static pgd_t *hyp_pgd;
 static DEFINE_MUTEX(kvm_hyp_pgd_mutex);
 
+static void *init_bounce_page;
+static unsigned long hyp_idmap_start;
+static unsigned long hyp_idmap_end;
+static phys_addr_t hyp_idmap_vector;
+
 static void kvm_tlb_flush_vmid_ipa(struct kvm *kvm, phys_addr_t ipa)
 {
 	kvm_call_hyp(__kvm_tlb_flush_vmid_ipa, kvm, ipa);
@@ -152,9 +158,12 @@ static void unmap_range(pgd_t *pgdp, unsigned long long start, u64 size)
 /**
  * free_hyp_pgds - free Hyp-mode page tables
  *
- * Assumes hyp_pgd is a page table used strictly in Hyp-mode and therefore contains
- * either mappings in the kernel memory area (above PAGE_OFFSET), or
- * device mappings in the vmalloc range (from VMALLOC_START to VMALLOC_END).
+ * Assumes hyp_pgd is a page table used strictly in Hyp-mode and
+ * therefore contains either mappings in the kernel memory area (above
+ * PAGE_OFFSET), or device mappings in the vmalloc range (from
+ * VMALLOC_START to VMALLOC_END).
+ *
+ * boot_hyp_pgd should only map two pages for the init code.
  */
 void free_hyp_pgds(void)
 {
@@ -162,6 +171,12 @@ void free_hyp_pgds(void)
 
 	mutex_lock(&kvm_hyp_pgd_mutex);
 
+	if (boot_hyp_pgd) {
+		unmap_range(boot_hyp_pgd, hyp_idmap_start, PAGE_SIZE);
+		unmap_range(boot_hyp_pgd, TRAMPOLINE_VA, PAGE_SIZE);
+		kfree(boot_hyp_pgd);
+	}
+
 	if (hyp_pgd) {
 		for (addr = PAGE_OFFSET; virt_addr_valid(addr); addr += PGDIR_SIZE)
 			unmap_range(hyp_pgd, KERN_TO_HYP(addr), PGDIR_SIZE);
@@ -170,6 +185,7 @@ void free_hyp_pgds(void)
 		kfree(hyp_pgd);
 	}
 
+	kfree(init_bounce_page);
 	mutex_unlock(&kvm_hyp_pgd_mutex);
 }
 
@@ -185,6 +201,7 @@ static void create_hyp_pte_mappings(pmd_t *pmd, unsigned long start,
 		pte = pte_offset_kernel(pmd, addr);
 		kvm_set_pte(pte, pfn_pte(pfn, prot));
 		get_page(virt_to_page(pte));
+		kvm_flush_dcache_to_poc(pte, sizeof(*pte));
 		pfn++;
 	} while (addr += PAGE_SIZE, addr != end);
 }
@@ -211,6 +228,7 @@ static int create_hyp_pmd_mappings(pud_t *pud, unsigned long start,
 			}
 			pmd_populate_kernel(NULL, pmd, pte);
 			get_page(virt_to_page(pmd));
+			kvm_flush_dcache_to_poc(pmd, sizeof(*pmd));
 		}
 
 		next = pmd_addr_end(addr, end);
@@ -248,6 +266,7 @@ static int __create_hyp_mappings(pgd_t *pgdp,
 			}
 			pud_populate(NULL, pud, pmd);
 			get_page(virt_to_page(pud));
+			kvm_flush_dcache_to_poc(pud, sizeof(*pud));
 		}
 
 		next = pgd_addr_end(addr, end);
@@ -689,18 +708,64 @@ void kvm_mmu_free_memory_caches(struct kvm_vcpu *vcpu)
 
 phys_addr_t kvm_mmu_get_httbr(void)
 {
-	VM_BUG_ON(!virt_addr_valid(hyp_pgd));
 	return virt_to_phys(hyp_pgd);
 }
 
+phys_addr_t kvm_mmu_get_boot_httbr(void)
+{
+	return virt_to_phys(boot_hyp_pgd);
+}
+
+phys_addr_t kvm_get_idmap_vector(void)
+{
+	return hyp_idmap_vector;
+}
+
 int kvm_mmu_init(void)
 {
-	unsigned long hyp_idmap_start = virt_to_phys(__hyp_idmap_text_start);
-	unsigned long hyp_idmap_end = virt_to_phys(__hyp_idmap_text_end);
 	int err;
 
+	hyp_idmap_start = virt_to_phys(__hyp_idmap_text_start);
+	hyp_idmap_end = virt_to_phys(__hyp_idmap_text_end);
+	hyp_idmap_vector = virt_to_phys(__kvm_hyp_init);
+
+	if ((hyp_idmap_start ^ hyp_idmap_end) & PAGE_MASK) {
+		/*
+		 * Our init code is crossing a page boundary. Allocate
+		 * a bounce page, copy the code over and use that.
+		 */
+		size_t len = __hyp_idmap_text_end - __hyp_idmap_text_start;
+		phys_addr_t phys_base;
+
+		init_bounce_page = kmalloc(PAGE_SIZE, GFP_KERNEL);
+		if (!init_bounce_page) {
+			kvm_err("Couldn't allocate HYP init bounce page\n");
+			err = -ENOMEM;
+			goto out;
+		}
+
+		memcpy(init_bounce_page, __hyp_idmap_text_start, len);
+		/*
+		 * Warning: the code we just copied to the bounce page
+		 * must be flushed to the point of coherency.
+		 * Otherwise, the data may be sitting in L2, and HYP
+		 * mode won't be able to observe it as it runs with
+		 * caches off at that point.
+		 */
+		kvm_flush_dcache_to_poc(init_bounce_page, len);
+
+		phys_base = virt_to_phys(init_bounce_page);
+		hyp_idmap_vector += phys_base - hyp_idmap_start;
+		hyp_idmap_start = phys_base;
+		hyp_idmap_end = phys_base + len;
+
+		kvm_info("Using HYP init bounce page @%lx\n",
+			 (unsigned long)phys_base);
+	}
+
 	hyp_pgd = kzalloc(PTRS_PER_PGD * sizeof(pgd_t), GFP_KERNEL);
-	if (!hyp_pgd) {
+	boot_hyp_pgd = kzalloc(PTRS_PER_PGD * sizeof(pgd_t), GFP_KERNEL);
+	if (!hyp_pgd || !boot_hyp_pgd) {
 		kvm_err("Hyp mode PGD not allocated\n");
 		err = -ENOMEM;
 		goto out;
@@ -718,39 +783,30 @@ int kvm_mmu_init(void)
 		goto out;
 	}
 
+	/* Map the very same page at the trampoline VA */
+	err = 	__create_hyp_mappings(boot_hyp_pgd,
+				      TRAMPOLINE_VA, TRAMPOLINE_VA + PAGE_SIZE,
+				      __phys_to_pfn(hyp_idmap_start),
+				      PAGE_HYP);
+	if (err) {
+		kvm_err("Failed to map trampoline @%lx into boot HYP pgd\n",
+			TRAMPOLINE_VA);
+		goto out;
+	}
+
+	/* Map the same page again into the runtime page tables */
+	err = 	__create_hyp_mappings(hyp_pgd,
+				      TRAMPOLINE_VA, TRAMPOLINE_VA + PAGE_SIZE,
+				      __phys_to_pfn(hyp_idmap_start),
+				      PAGE_HYP);
+	if (err) {
+		kvm_err("Failed to map trampoline @%lx into runtime HYP pgd\n",
+			TRAMPOLINE_VA);
+		goto out;
+	}
+
 	return 0;
 out:
 	free_hyp_pgds();
 	return err;
 }
-
-/**
- * kvm_clear_idmap - remove all idmaps from the hyp pgd
- *
- * Free the underlying pmds for all pgds in range and clear the pgds (but
- * don't free them) afterwards.
- */
-void kvm_clear_hyp_idmap(void)
-{
-	unsigned long addr, end;
-	unsigned long next;
-	pgd_t *pgd = hyp_pgd;
-	pud_t *pud;
-	pmd_t *pmd;
-
-	addr = virt_to_phys(__hyp_idmap_text_start);
-	end = virt_to_phys(__hyp_idmap_text_end);
-
-	pgd += pgd_index(addr);
-	do {
-		next = pgd_addr_end(addr, end);
-		if (pgd_none_or_clear_bad(pgd))
-			continue;
-		pud = pud_offset(pgd, addr);
-		pmd = pmd_offset(pud, addr);
-
-		pud_clear(pud);
-		kvm_clean_pmd_entry(pmd);
-		pmd_free(NULL, (pmd_t *)((unsigned long)pmd & PAGE_MASK));
-	} while (pgd++, addr = next, addr < end);
-}
-- 
1.7.9.5



From cdall at cs.columbia.edu  Tue Apr 30 10:49:33 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Tue, 30 Apr 2013 07:49:33 -0700
Subject: [PATCH 12/15] KVM: ARM: Fix API documentation for ONE_REG encoding
In-Reply-To: <1367333376-30983-1-git-send-email-cdall@cs.columbia.edu>
References: <1367333376-30983-1-git-send-email-cdall@cs.columbia.edu>
Message-ID: <1367333376-30983-13-git-send-email-cdall@cs.columbia.edu>

Unless I'm mistaken, the size field was encoded 4 bits off and a wrong
value was used for 64-bit FP registers.

Signed-off-by: Christoffer Dall <cdall at cs.columbia.edu>
---
 Documentation/virtual/kvm/api.txt |   12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
index c09d183..59fd9e6 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -1814,22 +1814,22 @@ ARM registers are mapped using the lower 32 bits.  The upper 16 of that
 is the register group type, or coprocessor number:
 
 ARM core registers have the following id bit patterns:
-  0x4002 0000 0010 <index into the kvm_regs struct:16>
+  0x4020 0000 0010 <index into the kvm_regs struct:16>
 
 ARM 32-bit CP15 registers have the following id bit patterns:
-  0x4002 0000 000F <zero:1> <crn:4> <crm:4> <opc1:4> <opc2:3>
+  0x4020 0000 000F <zero:1> <crn:4> <crm:4> <opc1:4> <opc2:3>
 
 ARM 64-bit CP15 registers have the following id bit patterns:
-  0x4003 0000 000F <zero:1> <zero:4> <crm:4> <opc1:4> <zero:3>
+  0x4030 0000 000F <zero:1> <zero:4> <crm:4> <opc1:4> <zero:3>
 
 ARM CCSIDR registers are demultiplexed by CSSELR value:
-  0x4002 0000 0011 00 <csselr:8>
+  0x4020 0000 0011 00 <csselr:8>
 
 ARM 32-bit VFP control registers have the following id bit patterns:
-  0x4002 0000 0012 1 <regno:12>
+  0x4020 0000 0012 1 <regno:12>
 
 ARM 64-bit FP registers have the following id bit patterns:
-  0x4002 0000 0012 0 <regno:12>
+  0x4030 0000 0012 0 <regno:12>
 
 4.69 KVM_GET_ONE_REG
 
-- 
1.7.9.5



From cdall at cs.columbia.edu  Tue Apr 30 10:49:34 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Tue, 30 Apr 2013 07:49:34 -0700
Subject: [PATCH 13/15] ARM: KVM: define KVM_ARM_MAX_VCPUS unconditionally
In-Reply-To: <1367333376-30983-1-git-send-email-cdall@cs.columbia.edu>
References: <1367333376-30983-1-git-send-email-cdall@cs.columbia.edu>
Message-ID: <1367333376-30983-14-git-send-email-cdall@cs.columbia.edu>

From: Arnd Bergmann <arnd at arndb.de>

The CONFIG_KVM_ARM_MAX_VCPUS symbol is needed in order to build the
kernel/context_tracking.c code, which includes the vgic data structures
implictly through the kvm headers. Definining the symbol to zero
on builds without KVM resolves this build error:

In file included from include/linux/kvm_host.h:33:0,
                 from kernel/context_tracking.c:18:
arch/arm/include/asm/kvm_host.h:28:23: warning: "CONFIG_KVM_ARM_MAX_VCPUS" is not defined [-Wundef]
 #define KVM_MAX_VCPUS CONFIG_KVM_ARM_MAX_VCPUS
                       ^
arch/arm/include/asm/kvm_vgic.h:34:24: note: in expansion of macro 'KVM_MAX_VCPUS'
 #define VGIC_MAX_CPUS  KVM_MAX_VCPUS
                        ^
arch/arm/include/asm/kvm_vgic.h:38:6: note: in expansion of macro 'VGIC_MAX_CPUS'
 #if (VGIC_MAX_CPUS > 8)
      ^
In file included from arch/arm/include/asm/kvm_host.h:41:0,
                 from include/linux/kvm_host.h:33,
                 from kernel/context_tracking.c:18:
arch/arm/include/asm/kvm_vgic.h:59:11: error: 'CONFIG_KVM_ARM_MAX_VCPUS' undeclared here (not in a function)
  } percpu[VGIC_MAX_CPUS];
           ^

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Cc: Marc Zyngier <marc.zyngier at arm.com>
Cc: Christoffer Dall <cdall at cs.columbia.edu>
Cc: Will Deacon <will.deacon at arm.com>
Signed-off-by: Christoffer Dall <cdall at cs.columbia.edu>
---
 arch/arm/kvm/Kconfig |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/kvm/Kconfig b/arch/arm/kvm/Kconfig
index 49dd64e..370e1a8 100644
--- a/arch/arm/kvm/Kconfig
+++ b/arch/arm/kvm/Kconfig
@@ -41,9 +41,9 @@ config KVM_ARM_HOST
 	  Provides host support for ARM processors.
 
 config KVM_ARM_MAX_VCPUS
-	int "Number maximum supported virtual CPUs per VM"
-	depends on KVM_ARM_HOST
-	default 4
+	int "Number maximum supported virtual CPUs per VM" if KVM_ARM_HOST
+	default 4 if KVM_ARM_HOST
+	default 0
 	help
 	  Static number of max supported virtual CPUs per VM.
 
-- 
1.7.9.5



From cdall at cs.columbia.edu  Tue Apr 30 10:49:36 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Tue, 30 Apr 2013 07:49:36 -0700
Subject: [PATCH 15/15] ARM: KVM: iterate over all CPUs for CPU compatibility
 check
In-Reply-To: <1367333376-30983-1-git-send-email-cdall@cs.columbia.edu>
References: <1367333376-30983-1-git-send-email-cdall@cs.columbia.edu>
Message-ID: <1367333376-30983-16-git-send-email-cdall@cs.columbia.edu>

From: Andre Przywara <andre.przywara at linaro.org>

kvm_target_cpus() checks the compatibility of the used CPU with
KVM, which is currently limited to ARM Cortex-A15 cores.
However by calling it only once on any random CPU it assumes that
all cores are the same, which is not necessarily the case (for example
in Big.Little).

[ I cut some of the commit message and changed the formatting of the
  code slightly to pass checkpatch and look more like the rest of the
  kvm/arm init code - Christoffer ]

Signed-off-by: Andre Przywara <andre.przywara at linaro.org>
Signed-off-by: Christoffer Dall <cdall at cs.columbia.edu>
---
 arch/arm/kvm/arm.c |   15 ++++++++++++---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index 089c0a4..5bc99b4 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -947,21 +947,30 @@ out_err:
 	return err;
 }
 
+static void check_kvm_target_cpu(void *ret)
+{
+	*(int *)ret = kvm_target_cpu();
+}
+
 /**
  * Initialize Hyp-mode and memory mappings on all CPUs.
  */
 int kvm_arch_init(void *opaque)
 {
 	int err;
+	int ret, cpu;
 
 	if (!is_hyp_mode_available()) {
 		kvm_err("HYP mode not available\n");
 		return -ENODEV;
 	}
 
-	if (kvm_target_cpu() < 0) {
-		kvm_err("Target CPU not supported!\n");
-		return -ENODEV;
+	for_each_online_cpu(cpu) {
+		smp_call_function_single(cpu, check_kvm_target_cpu, &ret, 1);
+		if (ret < 0) {
+			kvm_err("Error, CPU %d not supported!\n", cpu);
+			return -ENODEV;
+		}
 	}
 
 	err = init_hyp_mode();
-- 
1.7.9.5



From stefano.stabellini at eu.citrix.com  Tue Apr 30 10:51:33 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Tue, 30 Apr 2013 15:51:33 +0100
Subject: [GIT PULL] (arm/xen) 3.9-rc3-smp-6-tag
Message-ID: <alpine.DEB.2.02.1304301515490.5398@kaball.uk.xensource.com>

Hi Linus,
this is my first pull request to you, Konrad decided to let me deal
with the Xen/ARM stuff myself recently.
Please pull the following tag (based on 3.9-rc3):

git://git.kernel.org/pub/scm/linux/kernel/git/sstabellini/xen.git 3.9-rc3-smp-6-tag

It contains a bunch of Xen/ARM specific changes, including some fixes,
SMP support for Xen on ARM, and moving the xenvm machine from
mach-vexpress to mach-virt.

The non-Xen files that are touched are arch/arm/Kconfig, to select
ARM_PSCI on XEN, and arch/arm/boot/dts/Makefile, to build the xenvm DTB
if CONFIG_ARCH_VIRT.


Stefano Stabellini (7):
      xen/arm: actually pass a non-NULL percpu pointer to request_percpu_irq
      xen/arm: implement HYPERVISOR_vcpu_op
      xen/arm: SMP support
      xen: move the xenvm machine to mach-virt
      xen/arm: XEN selects ARM_PSCI
      xenvm: add a simple PSCI node and a second cpu
      xen/arm: use sched_op hypercalls for machine reboot and power off

Wei Yongjun (1):
      xen/arm: remove duplicated include from enlighten.c

 arch/arm/Kconfig                     |    1 +
 arch/arm/boot/dts/Makefile           |    4 +-
 arch/arm/boot/dts/xenvm-4.2.dts      |   13 ++++++
 arch/arm/include/asm/xen/hypercall.h |    1 +
 arch/arm/mach-vexpress/v2m.c         |    1 -
 arch/arm/mach-virt/virt.c            |    1 +
 arch/arm/xen/enlighten.c             |   74 ++++++++++++++++++++++++++++++---
 arch/arm/xen/hypercall.S             |    1 +
 8 files changed, 86 insertions(+), 10 deletions(-)


Cheers,
Stefano


From arnd at arndb.de  Tue Apr 30 11:07:57 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 30 Apr 2013 17:07:57 +0200
Subject: [PATCH V2] video: implement a simple framebuffer driver
In-Reply-To: <1367332685.945287573@f287.mail.ru>
References: <1365043183-28905-1-git-send-email-swarren@wwwdotorg.org>
 <517F753F.5090909@ti.com> <1367332685.945287573@f287.mail.ru>
Message-ID: <201304301707.57197.arnd@arndb.de>

On Tuesday 30 April 2013, Alexander Shiyan wrote:
> > On 04/04/2013 05:39 AM, Stephen Warren wrote:
> > > A simple frame-buffer describes a raw memory region that may be rendered
> > > to, with the assumption that the display hardware has already been set
> > > up to scan out from that buffer.
> > > 
> > > This is useful in cases where a bootloader exists and has set up the
> > > display hardware, but a Linux driver doesn't yet exist for the display
> > > hardware.
> > > 
> > > Signed-off-by: Stephen Warren <swarren at wwwdotorg.org>
> ...
> > > +   framebuffer {
> > > +           compatible = "simple-framebuffer";
> > > +           reg = <0x1d385000 (1600 * 1200 * 2)>;
> > > +           width = <1600>;
> > > +           height = <1200>;
> > > +           stride = <(1600 * 2)>;
> > > +           format = "r5g6b5";
> > > +   };
> > 
> > I'm not an expert on DT, but I think the point of DT is to describe the
> > hardware. This doesn't describe the hardware at all.
> 
> On my incompetent opinion, "bpp" parameter can replace size of
> framebuffer and "stride". Is not it?

Not necessarily: you could have a stride that is larger than a line.

	Arnd


From nicolas.pitre at linaro.org  Tue Apr 30 11:12:12 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Tue, 30 Apr 2013 11:12:12 -0400 (EDT)
Subject: Latest build results - errors/warnings - lots of them
In-Reply-To: <20130430114229.GA2439@linaro.org>
References: <20130430081739.GP14496@n2100.arm.linux.org.uk>
 <201304301304.20650.arnd@arndb.de> <20130430114229.GA2439@linaro.org>
Message-ID: <alpine.LFD.2.03.1304301110030.17372@syhkavp.arg>

On Tue, 30 Apr 2013, Dave Martin wrote:

> On Tue, Apr 30, 2013 at 01:04:20PM +0200, Arnd Bergmann wrote:
> > On Tuesday 30 April 2013, Russell King - ARM Linux wrote:
> > > Latest nightly build of 3.9+my for-next+arm-soc's for-next results in a
> > > great load of new warnings and errors.  arch/arm/common/mcpm_head.S,
> > > arch/arm/common/mcpm_platsmp.c, arch/arm/common/vlock.S are the biggest
> > > source of errors.
> 
> [...]
>  
> > >arch/arm/common/mcpm_head.S:39: Error: selected processor does not support ARM mode `ubfx r9,r0,#0,#8'
> > >arch/arm/common/mcpm_head.S:40: Error: selected processor does not support ARM mode `ubfx r10,r0,#8,#8'
> > >arch/arm/common/mcpm_head.S:100: Error: selected processor does not support ARM mode `dmb'
> > >arch/arm/common/mcpm_head.S:115: Error: selected processor does not support ARM mode `dmb'
> > >arch/arm/common/mcpm_head.S:127: Error: selected processor does not support ARM mode `dmb'
> > >arch/arm/common/mcpm_head.S:131: Error: selected processor does not support ARM mode `dmb'
> > >arch/arm/common/mcpm_head.S:138: Error: selected processor does not support ARM mode `dsb'
> > >arch/arm/common/mcpm_head.S:152: Error: selected processor does not support ARM mode `dmb'
> > >arch/arm/common/mcpm_head.S:161: Error: selected processor does not support ARM mode `dmb'
> > >arch/arm/common/mcpm_head.S:175: Error: selected processor does not support ARM mode `dmb'
> > >arch/arm/common/vlock.S:62: Error: selected processor does not support ARM mode `dmb'
> > >arch/arm/common/vlock.S:72: Error: selected processor does not support ARM mode `dmb'
> > >arch/arm/common/vlock.S:72: Error: selected processor does not support ARM mode `dsb'
> > >arch/arm/common/vlock.S:89: Error: selected processor does not support ARM mode `dmb'
> > >arch/arm/common/vlock.S:95: Error: selected processor does not support ARM mode `dmb'
> > >arch/arm/common/vlock.S:95: Error: selected processor does not support ARM mode `dsb'
> > >arch/arm/common/vlock.S:102: Error: selected processor does not support ARM mode `dmb'
> > >arch/arm/common/vlock.S:105: Error: selected processor does not support ARM mode `dsb'
> > 
> > Right, the problem here is that the code was never tested with an ARMv6+ARMv7 config.
> > We can either fix it up by adding
> > 
> > 	.arch	armv7-a
> > 
> > in the assembly files, or by doing the same in the Makefile:
> > 
> > AFLAGS_vlock.S += -march=armv7-a
> > AFLAGS_mcpm_head.S += -march=armv7-a
> 
> 
> Hmmm, this code was tested with ARCH_MULTIPLATFORM, but it looks like
> no v6 boards were configured in when testing that...
> 
> 
> Assuming people are OK with the Makefile route, here's a patch for that,
> build-tested with a v6+v7 ARCH_MULTIPLATFORM config.

Isn't the .arch armv7-a route a bit cleaner?  That would have been my 
choice, although I don't feel strongly about it.


Nicolas


From nicolas.pitre at linaro.org  Tue Apr 30 11:15:25 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Tue, 30 Apr 2013 11:15:25 -0400 (EDT)
Subject: linux-next build error (at91) - use of bool in mach/arch.h
In-Reply-To: <alpine.DEB.2.02.1304301257200.5398@kaball.uk.xensource.com>
References: <517F8FF4.3050901@atmel.com>
 <CAMuHMdXYaDHYq7CG8ftP+yyF18pMx8qZrvM3AUTAXk+tUruNcA@mail.gmail.com>
 <alpine.DEB.2.02.1304301257200.5398@kaball.uk.xensource.com>
Message-ID: <alpine.LFD.2.03.1304301114140.17372@syhkavp.arg>

On Tue, 30 Apr 2013, Stefano Stabellini wrote:

> On Tue, 30 Apr 2013, Geert Uytterhoeven wrote:
> > On Tue, Apr 30, 2013 at 11:33 AM, Nicolas Ferre <nicolas.ferre at atmel.com> wrote:
> > > So, I am wondering if the best correction is to add the types.h header file
> > > in the asm/mach/arch.h file, like this:
> > >
> > > --- a/arch/arm/include/asm/mach/arch.h
> > > +++ b/arch/arm/include/asm/mach/arch.h
> > > @@ -8,6 +8,8 @@
> > >   * published by the Free Software Foundation.
> > >   */
> > >
> > > +#include <linux/types.h>
> > > +
> > >  #ifndef __ASSEMBLY__
> > >
> > >  struct tag;
> > >
> > > or if a better option would be to re-arrange the include directives in
> > > various at91xxx_devices.c files?
> > 
> > Include files should be self-contained, so asm/mach/arch.h is the right place.
> 
> Nicolas,
> are you happy to come up with a proper patch to fix the issue?

I'd prefer if you just folded the above include into the original patch, 
unless this has been pulled already.


Nicolas


From catalin.marinas at arm.com  Tue Apr 30 11:26:35 2013
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Tue, 30 Apr 2013 16:26:35 +0100
Subject: [Question] flush_dcache_page() need to flush icache?
In-Reply-To: <CACVXFVPz-rMiPyW2EE==v58LF6uTD1M1fKTNcF5a5+Z6-5u+Gg@mail.gmail.com>
References: <CACVXFVMz3jLEPDYFM-_S_t5TiqikVSRiKf9cBNocH3QhVexwZg@mail.gmail.com>
 <20130430090502.GC29766@arm.com>
 <CACVXFVPz-rMiPyW2EE==v58LF6uTD1M1fKTNcF5a5+Z6-5u+Gg@mail.gmail.com>
Message-ID: <20130430152635.GH29766@arm.com>

On Tue, Apr 30, 2013 at 11:02:36AM +0100, Ming Lei wrote:
> On Tue, Apr 30, 2013 at 5:05 PM, Catalin Marinas
> <catalin.marinas at arm.com> wrote:
> > On Tue, Apr 30, 2013 at 09:16:16AM +0100, Ming Lei wrote:
> >> Looks flush_dcache_page() need to deal with both dcache alias and I/D
> >> cache coherency, but set_pte_at() has already run __sync_icache_dcache()
> >> to make I/D cache coherency in the path of executable page fault.
> >>
> >> So could the flushing icache be removed in flush_dcache_page()?
> >
> > That's the case for (mapping && mapping_mapped(mapping)) where the
> > kernel modifies a page cache page which is already mapped in user space
> > and we won't get a subsequent set_pte_at() call.
> 
> OK, I got it, so looks it is only needed in self-modifying-code case,
> but I am wondering why it is always done for all cases of (mapping &&
> mapping_mapped(mapping))......

It's not self-modifying code, this would be code running in user space
which modifies some other code and it would invoke the ARM-specific
syscall for flushing.

Here it is about kernel modifying a page which is already mapped in user
space, hence the check for mapping && mapping_mapped.

-- 
Catalin


From konrad.wilk at oracle.com  Tue Apr 30 11:28:03 2013
From: konrad.wilk at oracle.com (Konrad Rzeszutek Wilk)
Date: Tue, 30 Apr 2013 11:28:03 -0400
Subject: [PATCH v5 0/7] xen/arm: move to mach-virt and support SMP
In-Reply-To: <alpine.DEB.2.02.1304261134330.4180@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1304251750160.4180@kaball.uk.xensource.com>
 <alpine.DEB.2.02.1304261134330.4180@kaball.uk.xensource.com>
Message-ID: <20130430152803.GB21639@phenom.dumpdata.com>

On Fri, Apr 26, 2013 at 11:41:32AM +0100, Stefano Stabellini wrote:
> Arnd, Olof,
> during the last few merge windows Konrad has always sent the Xen ARM
> patches to Linus via his tree, but this time (3.10 merge window), after
> consulting with Konrad I am thinking of sending to Linus the pull
> request myself.

<nods> They look good to me. If there are cross-platform patches
(say in drivers/xen) they would still need my Ack (or Jeremy's).

> 
> Arnd, are you OK with this patch series?
> 
> It's all very Xen specific and it is already in linux-next.
> The only non-Xen files that are touched are arch/arm/Kconfig, to select
> ARM_PSCI on XEN, and arch/arm/boot/dts/Makefile, to build the xenvm DTB
> if CONFIG_ARCH_VIRT.

I don't have much knowledge in the 'dts' Makefile but the rest looks
OK to me.
> 
> Cheers,
> 
> Stefano
> 
> 
> On Thu, 25 Apr 2013, Stefano Stabellini wrote:
> > Hi all,
> > this patch series, based on 3.9-rc3, moves xenvm to mach-virt,
> > introduces SMP support in Xen on ARM and implements machine reboot and
> > power off via Xen sched_op hypercalls.
> > 
> > Each patch comes with a detailed changelog.
> > 
> > 
> > The merge window is approaching, this patch series only contains Xen
> > specific changes for ARM, if anybody has any objections speak now
> > please.
> > 
> > I would like an ack from an ARM maintainer on patch #4 and #5 since they
> > touch generic ARM Makefiles.
> > 
> > 
> > Changes in v5:
> > - allocate xen_vcpu_info dynamically, aligning it to the size of the
> > struct;
> > - use VCPUOP_register_vcpu_info on cpu0 too;
> > - set pm_power_off and arm_pm_restart from the Xen specific
> > intialization code.
> > 
> > 
> > 
> > Stefano Stabellini (7):
> >       xen/arm: actually pass a non-NULL percpu pointer to request_percpu_irq
> >       xen/arm: implement HYPERVISOR_vcpu_op
> >       xen/arm: SMP support
> >       xen: move the xenvm machine to mach-virt
> >       xen/arm: XEN selects ARM_PSCI
> >       xenvm: add a simple PSCI node and a second cpu
> >       xen/arm: use sched_op hypercalls for machine reboot and power off
> > 
> >  arch/arm/Kconfig                     |    1 +
> >  arch/arm/boot/dts/Makefile           |    4 +-
> >  arch/arm/boot/dts/xenvm-4.2.dts      |   13 ++++++
> >  arch/arm/include/asm/xen/hypercall.h |    1 +
> >  arch/arm/mach-vexpress/v2m.c         |    1 -
> >  arch/arm/mach-virt/virt.c            |    1 +
> >  arch/arm/xen/enlighten.c             |   75 ++++++++++++++++++++++++++++++---
> >  arch/arm/xen/hypercall.S             |    1 +
> >  8 files changed, 87 insertions(+), 10 deletions(-)
> > 
> > 
> > git://git.kernel.org/pub/scm/linux/kernel/git/sstabellini/xen.git 3.9-rc3-smp-5-tag
> > 
> > Cheers,
> > 
> > Stefano
> > 


From lee.jones at linaro.org  Tue Apr 30 11:41:34 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Tue, 30 Apr 2013 16:41:34 +0100
Subject: [PATCH 2/5] ARM: ux500: Pass DMA memcpy channels though Device Tree
In-Reply-To: <1367336497-10650-1-git-send-email-lee.jones@linaro.org>
References: <1367336497-10650-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1367336497-10650-2-git-send-email-lee.jones@linaro.org>

It's not possible to configure memcpy channels dynamically with DT.
We're providing them despite the fact that they're the same as the
hard-coded channels, as they will be removed once the u8500 platform
goes DT-only.

Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/boot/dts/dbx5x0.dtsi |    2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/dbx5x0.dtsi b/arch/arm/boot/dts/dbx5x0.dtsi
index 838214c..8e80ef7 100644
--- a/arch/arm/boot/dts/dbx5x0.dtsi
+++ b/arch/arm/boot/dts/dbx5x0.dtsi
@@ -218,6 +218,8 @@
 			interrupts = <0 25 0x4>;
 
 			#dma-cells = <3>;
+			memcpy-channels = <56 57 58 59 60>;
+			memcpy-num-chans = <5>;
 		};
 
 		prcmu: prcmu at 80157000 {
-- 
1.7.10.4



From lee.jones at linaro.org  Tue Apr 30 11:41:33 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Tue, 30 Apr 2013 16:41:33 +0100
Subject: [PATCH 1/5] dmaengine: ste_dma40: Allow memcpy channels to be
 configured from DT
Message-ID: <1367336497-10650-1-git-send-email-lee.jones@linaro.org>

At this moment in time the memcpy channels which can be used by the D40
are fixed, as each supported platform in Mainline uses the same ones.
However, platforms do exist which don't follow this convention, so
these will need to be tailored. Fortunately, these platforms will be DT
only, so this change has very little impact on platform data.

Cc: Vinod Koul <vinod.koul at intel.com>
Cc: Dan Williams <djbw at fb.com>
Cc: Per Forlin <per.forlin at stericsson.com>
Cc: Rabin Vincent <rabin at rab.in>
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 .../devicetree/bindings/dma/ste-dma40.txt          |    4 ++
 drivers/dma/ste_dma40.c                            |   40 +++++++++++++++-----
 include/linux/platform_data/dma-ste-dma40.h        |    2 +
 3 files changed, 37 insertions(+), 9 deletions(-)

diff --git a/Documentation/devicetree/bindings/dma/ste-dma40.txt b/Documentation/devicetree/bindings/dma/ste-dma40.txt
index 2679a87..02e87e7 100644
--- a/Documentation/devicetree/bindings/dma/ste-dma40.txt
+++ b/Documentation/devicetree/bindings/dma/ste-dma40.txt
@@ -6,6 +6,8 @@ Required properties:
 - reg-names: Names of the above areas to use during resource look-up
 - interrupt: Should contain the DMAC interrupt number
 - #dma-cells: must be <3>
+- memcpy-channels: Channels to be used for memcpy
+- memcpy-num-chans: Number of channels to be used for memcpy
 
 Optional properties:
 - dma-channels: Number of channels supported by hardware - if not present
@@ -21,6 +23,8 @@ Example:
 		interrupts = <0 25 0x4>;
 
 		#dma-cells = <2>;
+		memcpy-channels  = <56, 57, 58, 59, 60>;
+		memcpy-num-chans = <5>;
 		dma-channels = <8>;
 	};
 
diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index d5c39e4..4769141 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -58,8 +58,10 @@
 #define D40_ALLOC_PHY		BIT(30)
 #define D40_ALLOC_LOG_FREE	0
 
+#define D40_MEMCPY_MAX_CHANS	8
+
 /* Reserved event lines for memcpy only. */
-static int dma40_memcpy_channels[] = { 56, 57, 58, 59, 60 };
+static int dma40_memcpy_channels[D40_MEMCPY_MAX_CHANS] = { 56, 57, 58, 59, 60 };
 
 /* Default configuration for physcial memcpy */
 struct stedma40_chan_cfg dma40_memcpy_conf_phy = {
@@ -508,6 +510,8 @@ struct d40_gen_dmac {
  * @phy_start: Physical memory start of the DMA registers.
  * @phy_size: Size of the DMA register map.
  * @irq: The IRQ number.
+ * @num_memcpy_chans: The number of channels used for memcpy (mem-to-mem
+ * transfers).
  * @num_phy_chans: The number of physical channels. Read from HW. This
  * is the number of available channels for this driver, not counting "Secure
  * mode" allocated physical channels.
@@ -551,6 +555,7 @@ struct d40_base {
 	phys_addr_t			  phy_start;
 	resource_size_t			  phy_size;
 	int				  irq;
+	int				  num_memcpy_chans;
 	int				  num_phy_chans;
 	int				  num_log_chans;
 	struct device_dma_parameters	  dma_parms;
@@ -2920,7 +2925,7 @@ static int __init d40_dmaengine_init(struct d40_base *base,
 	}
 
 	d40_chan_init(base, &base->dma_memcpy, base->log_chans,
-		      base->num_log_chans, ARRAY_SIZE(dma40_memcpy_channels));
+		      base->num_log_chans, base->num_memcpy_chans);
 
 	dma_cap_zero(base->dma_memcpy.cap_mask);
 	dma_cap_set(DMA_MEMCPY, base->dma_memcpy.cap_mask);
@@ -3121,6 +3126,7 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
 	struct d40_base *base = NULL;
 	int num_log_chans = 0;
 	int num_phy_chans;
+	int num_memcpy_chans;
 	int clk_ret = -EINVAL;
 	int i;
 	u32 pid;
@@ -3191,6 +3197,12 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
 	else
 		num_phy_chans = 4 * (readl(virtbase + D40_DREG_ICFG) & 0x7) + 4;
 
+	/* The number of channels used for memcpy */
+	if (plat_data->num_of_memcpy_chans)
+		num_memcpy_chans = plat_data->num_of_memcpy_chans;
+	else
+		num_memcpy_chans = ARRAY_SIZE(dma40_memcpy_channels);
+
 	num_log_chans = num_phy_chans * D40_MAX_LOG_CHAN_PER_PHY;
 
 	dev_info(&pdev->dev,
@@ -3198,7 +3210,7 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
 		 rev, res->start, num_phy_chans, num_log_chans);
 
 	base = kzalloc(ALIGN(sizeof(struct d40_base), 4) +
-		       (num_phy_chans + num_log_chans + ARRAY_SIZE(dma40_memcpy_channels)) *
+		       (num_phy_chans + num_log_chans + num_memcpy_chans) *
 		       sizeof(struct d40_chan), GFP_KERNEL);
 
 	if (base == NULL) {
@@ -3208,6 +3220,7 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
 
 	base->rev = rev;
 	base->clk = clk;
+	base->num_memcpy_chans = num_memcpy_chans;
 	base->num_phy_chans = num_phy_chans;
 	base->num_log_chans = num_log_chans;
 	base->phy_start = res->start;
@@ -3451,12 +3464,7 @@ static int __init d40_of_probe(struct platform_device *pdev,
 			       struct device_node *np)
 {
 	struct stedma40_platform_data *pdata;
- 
-	/*
-	 * FIXME: Fill in this routine as more support is added.
-	 * First platform enabled (u8500) doens't need any extra
-	 * properties to run, so this is fairly sparce currently.
-	 */
+	int num_memcpy = 0;
 
 	pdata = devm_kzalloc(&pdev->dev,
 			     sizeof(struct stedma40_platform_data),
@@ -3464,6 +3472,20 @@ static int __init d40_of_probe(struct platform_device *pdev,
 	if (!pdata)
 		return -ENOMEM;
 
+	of_property_read_u32(np, "memcpy-num-chans", &num_memcpy);
+
+	if (num_memcpy > D40_MEMCPY_MAX_CHANS || num_memcpy <= 0) {
+		d40_err(&pdev->dev,
+			"Invalid number of memcpy channels specified (%d)\n",
+			num_memcpy);
+		return -EINVAL;
+	}
+	pdata->num_of_memcpy_chans = num_memcpy;
+
+	of_property_read_u32_array(np, "memcpy-channels",
+				   dma40_memcpy_channels,
+				   num_memcpy);
+
 	pdev->dev.platform_data = pdata;
 
 	return 0;
diff --git a/include/linux/platform_data/dma-ste-dma40.h b/include/linux/platform_data/dma-ste-dma40.h
index ceba6dc..1bb9b18 100644
--- a/include/linux/platform_data/dma-ste-dma40.h
+++ b/include/linux/platform_data/dma-ste-dma40.h
@@ -132,6 +132,7 @@ struct stedma40_chan_cfg {
  * @num_of_soft_lli_chans: The number of channels that needs to be configured
  * to use SoftLLI.
  * @use_esram_lcla: flag for mapping the lcla into esram region
+ * @num_of_memcpy_chans: The number of channels reserved for memcpy.
  * @num_of_phy_chans: The number of physical channels implemented in HW.
  * 0 means reading the number of channels from DMA HW but this is only valid
  * for 'multiple of 4' channels, like 8.
@@ -141,6 +142,7 @@ struct stedma40_platform_data {
 	int				*soft_lli_chans;
 	int				 num_of_soft_lli_chans;
 	bool				 use_esram_lcla;
+	int				 num_of_memcpy_chans;
 	int				 num_of_phy_chans;
 };
 
-- 
1.7.10.4



From lee.jones at linaro.org  Tue Apr 30 11:41:35 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Tue, 30 Apr 2013 16:41:35 +0100
Subject: [PATCH 3/5] ARM: ux500: Stop passing DMA platform data though AUXDATA
In-Reply-To: <1367336497-10650-1-git-send-email-lee.jones@linaro.org>
References: <1367336497-10650-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1367336497-10650-3-git-send-email-lee.jones@linaro.org>

The DMA platform data is now empty due to some recent refactoring,
so there is no longer a requirement to pass it though.

Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/mach-ux500/cpu-db8500.c |    3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm/mach-ux500/cpu-db8500.c b/arch/arm/mach-ux500/cpu-db8500.c
index a2c83c2..2b6cbde 100644
--- a/arch/arm/mach-ux500/cpu-db8500.c
+++ b/arch/arm/mach-ux500/cpu-db8500.c
@@ -264,8 +264,7 @@ static struct of_dev_auxdata u8500_auxdata_lookup[] __initdata = {
 	OF_DEV_AUXDATA("stericsson,ux500-msp-i2s", 0x80125000,
 		"ux500-msp-i2s.3", &msp3_platform_data),
 	/* Requires clock name bindings and channel address lookup table. */
-	OF_DEV_AUXDATA("stericsson,db8500-dma40", 0x801C0000,
-		       "dma40.0", &dma40_plat_data),
+	OF_DEV_AUXDATA("stericsson,db8500-dma40", 0x801C0000, "dma40.0", NULL),
 	{},
 };
 
-- 
1.7.10.4



From lee.jones at linaro.org  Tue Apr 30 11:41:36 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Tue, 30 Apr 2013 16:41:36 +0100
Subject: [PATCH 4/5] dmaengine: ste_dma40: Fetch the number of physical
 channels from DT
In-Reply-To: <1367336497-10650-1-git-send-email-lee.jones@linaro.org>
References: <1367336497-10650-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1367336497-10650-4-git-send-email-lee.jones@linaro.org>

Some platforms insist on obscure physical channel availability. This
information is currently passed though platform data in internal BSP
kernels. Once those platforms land, they'll need to configure them
appropriately, so we may as well add the infrastructure.

Cc: Vinod Koul <vinod.koul at intel.com>
Cc: Dan Williams <djbw at fb.com>
Cc: Per Forlin <per.forlin at stericsson.com>
Cc: Rabin Vincent <rabin at rab.in>
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 drivers/dma/ste_dma40.c |    7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index 4769141..dbdd67b 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -3464,7 +3464,7 @@ static int __init d40_of_probe(struct platform_device *pdev,
 			       struct device_node *np)
 {
 	struct stedma40_platform_data *pdata;
-	int num_memcpy = 0;
+	int num_phy = 0, num_memcpy = 0;
 
 	pdata = devm_kzalloc(&pdev->dev,
 			     sizeof(struct stedma40_platform_data),
@@ -3472,6 +3472,11 @@ static int __init d40_of_probe(struct platform_device *pdev,
 	if (!pdata)
 		return -ENOMEM;
 
+	/* If absent this value will be obtained from h/w. */
+	of_property_read_u32(np, "dma-channels", &num_phy);
+	if (num_phy > 0)
+		pdata->num_of_phy_chans = num_phy;
+
 	of_property_read_u32(np, "memcpy-num-chans", &num_memcpy);
 
 	if (num_memcpy > D40_MEMCPY_MAX_CHANS || num_memcpy <= 0) {
-- 
1.7.10.4



From lee.jones at linaro.org  Tue Apr 30 11:41:37 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Tue, 30 Apr 2013 16:41:37 +0100
Subject: [PATCH 5/5] dmaengine: ste_dma40: Fetch disabled channels from DT
In-Reply-To: <1367336497-10650-1-git-send-email-lee.jones@linaro.org>
References: <1367336497-10650-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1367336497-10650-5-git-send-email-lee.jones@linaro.org>

Some platforms have channels which are not available for normal use.
This information is currently passed though platform data in internal
BSP kernels. Once those platforms land, they'll need to configure them
appropriately, so we may as well add the infrastructure.

Cc: Vinod Koul <vinod.koul at intel.com>
Cc: Dan Williams <djbw at fb.com>
Cc: Per Forlin <per.forlin at stericsson.com>
Cc: Rabin Vincent <rabin at rab.in>
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 Documentation/devicetree/bindings/dma/ste-dma40.txt |    4 ++++
 drivers/dma/ste_dma40.c                             |   16 +++++++++++++++-
 2 files changed, 19 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/dma/ste-dma40.txt b/Documentation/devicetree/bindings/dma/ste-dma40.txt
index 02e87e7..f234c75 100644
--- a/Documentation/devicetree/bindings/dma/ste-dma40.txt
+++ b/Documentation/devicetree/bindings/dma/ste-dma40.txt
@@ -12,6 +12,8 @@ Required properties:
 Optional properties:
 - dma-channels: Number of channels supported by hardware - if not present
 		the driver will attempt to obtain the information from H/W
+- disabled-channels: Channels which can not be used
+- disabled-num-chans: Number of channels which can not be used
 
 Example:
 
@@ -25,6 +27,8 @@ Example:
 		#dma-cells = <2>;
 		memcpy-channels  = <56, 57, 58, 59, 60>;
 		memcpy-num-chans = <5>;
+		disabled-channels  = <12>;
+		disabled-num-chans = <1>;
 		dma-channels = <8>;
 	};
 
diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index dbdd67b..b045eb2 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -3464,7 +3464,7 @@ static int __init d40_of_probe(struct platform_device *pdev,
 			       struct device_node *np)
 {
 	struct stedma40_platform_data *pdata;
-	int num_phy = 0, num_memcpy = 0;
+	int num_phy = 0, num_memcpy = 0, num_disabled = 0;
 
 	pdata = devm_kzalloc(&pdev->dev,
 			     sizeof(struct stedma40_platform_data),
@@ -3493,6 +3493,20 @@ static int __init d40_of_probe(struct platform_device *pdev,
 
 	pdev->dev.platform_data = pdata;
 
+	of_property_read_u32(np, "disabled-num-chans", &num_disabled);
+
+	if (num_disabled > STEDMA40_MAX_PHYS || num_disabled < 0) {
+		d40_err(&pdev->dev,
+			"Invalid number of disabled channels specified (%d)\n",
+			num_disabled);
+		return -EINVAL;
+	}
+
+	of_property_read_u32_array(np, "disabled-channels",
+				   pdata->disabled_channels,
+				   num_disabled);
+	pdata->disabled_channels[num_disabled] = -1;
+
 	return 0;
 }
 
-- 
1.7.10.4



From stefano.stabellini at eu.citrix.com  Tue Apr 30 11:59:26 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Tue, 30 Apr 2013 16:59:26 +0100
Subject: linux-next build error (at91) - use of bool in mach/arch.h
In-Reply-To: <alpine.LFD.2.03.1304301114140.17372@syhkavp.arg>
References: <517F8FF4.3050901@atmel.com>
 <CAMuHMdXYaDHYq7CG8ftP+yyF18pMx8qZrvM3AUTAXk+tUruNcA@mail.gmail.com>
 <alpine.DEB.2.02.1304301257200.5398@kaball.uk.xensource.com>
 <alpine.LFD.2.03.1304301114140.17372@syhkavp.arg>
Message-ID: <alpine.DEB.2.02.1304301659010.5398@kaball.uk.xensource.com>

On Tue, 30 Apr 2013, Nicolas Pitre wrote:
> On Tue, 30 Apr 2013, Stefano Stabellini wrote:
> 
> > On Tue, 30 Apr 2013, Geert Uytterhoeven wrote:
> > > On Tue, Apr 30, 2013 at 11:33 AM, Nicolas Ferre <nicolas.ferre at atmel.com> wrote:
> > > > So, I am wondering if the best correction is to add the types.h header file
> > > > in the asm/mach/arch.h file, like this:
> > > >
> > > > --- a/arch/arm/include/asm/mach/arch.h
> > > > +++ b/arch/arm/include/asm/mach/arch.h
> > > > @@ -8,6 +8,8 @@
> > > >   * published by the Free Software Foundation.
> > > >   */
> > > >
> > > > +#include <linux/types.h>
> > > > +
> > > >  #ifndef __ASSEMBLY__
> > > >
> > > >  struct tag;
> > > >
> > > > or if a better option would be to re-arrange the include directives in
> > > > various at91xxx_devices.c files?
> > > 
> > > Include files should be self-contained, so asm/mach/arch.h is the right place.
> > 
> > Nicolas,
> > are you happy to come up with a proper patch to fix the issue?
> 
> I'd prefer if you just folded the above include into the original patch, 
> unless this has been pulled already.

No, I'll exploit the opportunity to resend the patch series and issue a
PULL request for the arm-soc tree.


From tony at atomide.com  Tue Apr 30 12:11:04 2013
From: tony at atomide.com (Tony Lindgren)
Date: Tue, 30 Apr 2013 09:11:04 -0700
Subject: Latest build results - errors/warnings - lots of them
In-Reply-To: <201304301304.20650.arnd@arndb.de>
References: <20130430081739.GP14496@n2100.arm.linux.org.uk>
 <201304301304.20650.arnd@arndb.de>
Message-ID: <20130430161104.GB26257@atomide.com>

* Arnd Bergmann <arnd at arndb.de> [130430 04:10]:
> On Tuesday 30 April 2013, Russell King - ARM Linux wrote:
> > Latest nightly build of 3.9+my for-next+arm-soc's for-next results in a
> > great load of new warnings and errors.  arch/arm/common/mcpm_head.S,
> > arch/arm/common/mcpm_platsmp.c, arch/arm/common/vlock.S are the biggest
> > source of errors.
> 
> Yes, I noticed this but haven't gotten around to prepare a patch. I'll comment
> below.
> 
> > OMAP stuff needs a serious look at too - much Kconfig madness there
> > caused by over-use of select, which then goes on to cause build errors
> > because it assumes some stuff is always enabled.

I have posted a few randconfig fixes in "[PATCH 0/3] few omap randconfig
fixes for v3.10" that also remove the select of SERIAL_OMAP that I missed
while fixing the 8250 issue. I was planning to send a pull request after
the merge window, but can do it now too if people prefer that.
 
> Ack. I have not looked much at randconfig output, but this has certianly
> grown worse after CONFIG_ARCH_OMAP has gotten included in ARCH_MULTIPLATFORM

I have a patch coming for the "no SoC selected" randconfig issue as
discussed in the "linux-next ARM multi-platform randconfig errors"
thread. I suggest we do the minimal fix I already posted for now,
then reorganize more of the Makefile as Arnd suggested for v3.11.

Regards,

Tony


From stefano.stabellini at eu.citrix.com  Tue Apr 30 12:17:32 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Tue, 30 Apr 2013 17:17:32 +0100
Subject: [PATCH v10 0/2] (arm-soc for v3.10) arm: introduce psci_smp_ops
Message-ID: <alpine.DEB.2.02.1304301707290.5398@kaball.uk.xensource.com>

Hi all,
this is the tenth version of the patch series to move virt_smp_ops out
of mach-virt and make it a generic set of reusable PSCI based smp_ops.
psci_smp_ops are preferred over the platform smp_ops.  The last patch
introduces smp_init.

Changes in v10:
- add include <linux/types.h> to mach/arch.h.



Jon Medhurst (1):
      ARM: Enable selection of SMP operations at boot time

Stefano Stabellini (1):
      arm: introduce psci_smp_ops

 arch/arm/include/asm/mach/arch.h |    5 ++
 arch/arm/include/asm/psci.h      |    9 ++++
 arch/arm/kernel/Makefile         |    5 ++-
 arch/arm/kernel/psci.c           |    7 +--
 arch/arm/kernel/psci_smp.c       |   90 ++++++++++++++++++++++++++++++++++++++
 arch/arm/kernel/setup.c          |    9 +++-
 arch/arm/mach-virt/Makefile      |    1 -
 arch/arm/mach-virt/platsmp.c     |   58 ------------------------
 arch/arm/mach-virt/virt.c        |    3 -
 9 files changed, 119 insertions(+), 68 deletions(-)
 create mode 100644 arch/arm/kernel/psci_smp.c
 delete mode 100644 arch/arm/mach-virt/platsmp.c


git://git.kernel.org/pub/scm/linux/kernel/git/sstabellini/xen.git 3.9-rc3-psci-ops-10-tag

Cheers,

Stefano


From stefano.stabellini at eu.citrix.com  Tue Apr 30 12:18:40 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Tue, 30 Apr 2013 17:18:40 +0100
Subject: [PATCH v10 2/2] ARM: Enable selection of SMP operations at boot time
In-Reply-To: <alpine.DEB.2.02.1304301707290.5398@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1304301707290.5398@kaball.uk.xensource.com>
Message-ID: <1367338721-29152-2-git-send-email-stefano.stabellini@eu.citrix.com>

From: Jon Medhurst <tixy at linaro.org>

Add a new 'smp_init' hook to machine_desc so platforms can specify a
function to be used to setup smp ops instead of having a statically
defined value.  The hook must return true when smp_ops are initialized.
If false the static mdesc->smp_ops will be used by default.

Add the definition of "bool" by including the linux/types.h file to
asm/mach/arch.h and make it self-contained.

Signed-off-by: Jon Medhurst <tixy at linaro.org>
Signed-off-by: Nicolas Pitre <nicolas.pitre at linaro.org>
Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre at atmel.com>
Reviewed-by: Santosh Shilimkar <santosh.shilimkar at ti.com>

Changes in v10:
- add include <linux/types.h> to mach/arch.h.

---
 arch/arm/include/asm/mach/arch.h |    5 +++++
 arch/arm/kernel/setup.c          |   10 ++++++----
 2 files changed, 11 insertions(+), 4 deletions(-)

diff --git a/arch/arm/include/asm/mach/arch.h b/arch/arm/include/asm/mach/arch.h
index 308ad7d..75bf079 100644
--- a/arch/arm/include/asm/mach/arch.h
+++ b/arch/arm/include/asm/mach/arch.h
@@ -8,6 +8,8 @@
  * published by the Free Software Foundation.
  */
 
+#include <linux/types.h>
+
 #ifndef __ASSEMBLY__
 
 struct tag;
@@ -16,8 +18,10 @@ struct pt_regs;
 struct smp_operations;
 #ifdef CONFIG_SMP
 #define smp_ops(ops) (&(ops))
+#define smp_init_ops(ops) (&(ops))
 #else
 #define smp_ops(ops) (struct smp_operations *)NULL
+#define smp_init_ops(ops) (bool (*)(void))NULL
 #endif
 
 struct machine_desc {
@@ -41,6 +45,7 @@ struct machine_desc {
 	unsigned char		reserve_lp2 :1;	/* never has lp2	*/
 	char			restart_mode;	/* default restart mode	*/
 	struct smp_operations	*smp;		/* SMP operations	*/
+	bool			(*smp_init)(void);
 	void			(*fixup)(struct tag *, char **,
 					 struct meminfo *);
 	void			(*reserve)(void);/* reserve mem blocks	*/
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index dad3048..22cc863 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -770,10 +770,12 @@ void __init setup_arch(char **cmdline_p)
 	psci_init();
 #ifdef CONFIG_SMP
 	if (is_smp()) {
-		if (psci_smp_available())
-			smp_set_ops(&psci_smp_ops);
-		else if (mdesc->smp)
-			smp_set_ops(mdesc->smp);
+		if (!mdesc->smp_init || !mdesc->smp_init()) {
+			if (psci_smp_available())
+				smp_set_ops(&psci_smp_ops);
+			else if (mdesc->smp)
+				smp_set_ops(mdesc->smp);
+		}
 		smp_init_cpus();
 	}
 #endif
-- 
1.7.2.5



From stefano.stabellini at eu.citrix.com  Tue Apr 30 12:18:39 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Tue, 30 Apr 2013 17:18:39 +0100
Subject: [PATCH v10 1/2] arm: introduce psci_smp_ops
In-Reply-To: <alpine.DEB.2.02.1304301707290.5398@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1304301707290.5398@kaball.uk.xensource.com>
Message-ID: <1367338721-29152-1-git-send-email-stefano.stabellini@eu.citrix.com>

Rename virt_smp_ops to psci_smp_ops and move them to arch/arm/kernel/psci_smp.c.
Remove mach-virt/platsmp.c, now unused.
Compile psci_smp if CONFIG_ARM_PSCI and CONFIG_SMP.

Add a cpu_die smp_op based on psci_ops.cpu_off.

Initialize PSCI before setting smp_ops in setup_arch.

If PSCI is available on the platform, prefer psci_smp_ops over the
platform smp_ops.

Changes in v9:
- move comment about PSCI interface from psci.h to psci_smp.c.

Changes in v8:
- merge "prefer psci_smp_ops over mdesc->smp" into this patch.

Changes in v6:
- fixed return values for psci_smp_available and psci_init ifndef
CONFIG_ARM_PSCI.

Changes in v5:
- document psci_operations;
- psci_init returns NULL.

Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
Acked-by: Will Deacon <will.deacon at arm.com>
CC: arnd at arndb.de
CC: marc.zyngier at arm.com
CC: linux at arm.linux.org.uk
CC: nico at linaro.org
CC: rob.herring at calxeda.com
---
 arch/arm/include/asm/psci.h  |    9 ++++
 arch/arm/kernel/Makefile     |    5 ++-
 arch/arm/kernel/psci.c       |    7 +--
 arch/arm/kernel/psci_smp.c   |   90 ++++++++++++++++++++++++++++++++++++++++++
 arch/arm/kernel/setup.c      |    7 +++-
 arch/arm/mach-virt/Makefile  |    1 -
 arch/arm/mach-virt/platsmp.c |   58 ---------------------------
 arch/arm/mach-virt/virt.c    |    3 -
 8 files changed, 112 insertions(+), 68 deletions(-)
 create mode 100644 arch/arm/kernel/psci_smp.c
 delete mode 100644 arch/arm/mach-virt/platsmp.c

diff --git a/arch/arm/include/asm/psci.h b/arch/arm/include/asm/psci.h
index ce0dbe7..c4ae171 100644
--- a/arch/arm/include/asm/psci.h
+++ b/arch/arm/include/asm/psci.h
@@ -32,5 +32,14 @@ struct psci_operations {
 };
 
 extern struct psci_operations psci_ops;
+extern struct smp_operations psci_smp_ops;
+
+#ifdef CONFIG_ARM_PSCI
+void psci_init(void);
+bool psci_smp_available(void);
+#else
+static inline void psci_init(void) { }
+static inline bool psci_smp_available(void) { return false; }
+#endif
 
 #endif /* __ASM_ARM_PSCI_H */
diff --git a/arch/arm/kernel/Makefile b/arch/arm/kernel/Makefile
index 5f3338e..dd9d90a 100644
--- a/arch/arm/kernel/Makefile
+++ b/arch/arm/kernel/Makefile
@@ -82,6 +82,9 @@ obj-$(CONFIG_DEBUG_LL)	+= debug.o
 obj-$(CONFIG_EARLY_PRINTK)	+= early_printk.o
 
 obj-$(CONFIG_ARM_VIRT_EXT)	+= hyp-stub.o
-obj-$(CONFIG_ARM_PSCI)		+= psci.o
+ifeq ($(CONFIG_ARM_PSCI),y)
+obj-y				+= psci.o
+obj-$(CONFIG_SMP)		+= psci_smp.o
+endif
 
 extra-y := $(head-y) vmlinux.lds
diff --git a/arch/arm/kernel/psci.c b/arch/arm/kernel/psci.c
index 3653164..4693188 100644
--- a/arch/arm/kernel/psci.c
+++ b/arch/arm/kernel/psci.c
@@ -158,7 +158,7 @@ static const struct of_device_id psci_of_match[] __initconst = {
 	{},
 };
 
-static int __init psci_init(void)
+void __init psci_init(void)
 {
 	struct device_node *np;
 	const char *method;
@@ -166,7 +166,7 @@ static int __init psci_init(void)
 
 	np = of_find_matching_node(NULL, psci_of_match);
 	if (!np)
-		return 0;
+		return;
 
 	pr_info("probing function IDs from device-tree\n");
 
@@ -206,6 +206,5 @@ static int __init psci_init(void)
 
 out_put_node:
 	of_node_put(np);
-	return 0;
+	return;
 }
-early_initcall(psci_init);
diff --git a/arch/arm/kernel/psci_smp.c b/arch/arm/kernel/psci_smp.c
new file mode 100644
index 0000000..6ef139d
--- /dev/null
+++ b/arch/arm/kernel/psci_smp.c
@@ -0,0 +1,90 @@
+/*
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Copyright (C) 2012 ARM Limited
+ *
+ * Author: Will Deacon <will.deacon at arm.com>
+ */
+
+#include <linux/init.h>
+#include <linux/irqchip/arm-gic.h>
+#include <linux/smp.h>
+#include <linux/of.h>
+
+#include <asm/psci.h>
+#include <asm/smp_plat.h>
+
+/*
+ * psci_smp assumes that the following is true about PSCI:
+ *
+ * cpu_suspend   Suspend the execution on a CPU
+ * @state        we don't currently describe affinity levels, so just pass 0.
+ * @entry_point  the first instruction to be executed on return
+ * returns 0  success, < 0 on failure
+ *
+ * cpu_off       Power down a CPU
+ * @state        we don't currently describe affinity levels, so just pass 0.
+ * no return on successful call
+ *
+ * cpu_on        Power up a CPU
+ * @cpuid        cpuid of target CPU, as from MPIDR
+ * @entry_point  the first instruction to be executed on return
+ * returns 0  success, < 0 on failure
+ *
+ * migrate       Migrate the context to a different CPU
+ * @cpuid        cpuid of target CPU, as from MPIDR
+ * returns 0  success, < 0 on failure
+ *
+ */
+
+extern void secondary_startup(void);
+
+static int __cpuinit psci_boot_secondary(unsigned int cpu,
+					 struct task_struct *idle)
+{
+	if (psci_ops.cpu_on)
+		return psci_ops.cpu_on(cpu_logical_map(cpu),
+				       __pa(secondary_startup));
+	return -ENODEV;
+}
+
+static void __cpuinit psci_secondary_init(unsigned int cpu)
+{
+	gic_secondary_init(0);
+}
+
+#ifdef CONFIG_HOTPLUG_CPU
+void __ref psci_cpu_die(unsigned int cpu)
+{
+       const struct psci_power_state ps = {
+               .type = PSCI_POWER_STATE_TYPE_POWER_DOWN,
+       };
+
+       if (psci_ops.cpu_off)
+               psci_ops.cpu_off(ps);
+
+       /* We should never return */
+       panic("psci: cpu %d failed to shutdown\n", cpu);
+}
+#else
+#define psci_cpu_die NULL
+#endif
+
+bool __init psci_smp_available(void)
+{
+	/* is cpu_on available at least? */
+	return (psci_ops.cpu_on != NULL);
+}
+
+struct smp_operations __initdata psci_smp_ops = {
+	.smp_secondary_init	= psci_secondary_init,
+	.smp_boot_secondary	= psci_boot_secondary,
+	.cpu_die		= psci_cpu_die,
+};
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 3f6cbb2..dad3048 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -36,6 +36,7 @@
 #include <asm/cputype.h>
 #include <asm/elf.h>
 #include <asm/procinfo.h>
+#include <asm/psci.h>
 #include <asm/sections.h>
 #include <asm/setup.h>
 #include <asm/smp_plat.h>
@@ -766,9 +767,13 @@ void __init setup_arch(char **cmdline_p)
 	unflatten_device_tree();
 
 	arm_dt_init_cpu_maps();
+	psci_init();
 #ifdef CONFIG_SMP
 	if (is_smp()) {
-		smp_set_ops(mdesc->smp);
+		if (psci_smp_available())
+			smp_set_ops(&psci_smp_ops);
+		else if (mdesc->smp)
+			smp_set_ops(mdesc->smp);
 		smp_init_cpus();
 	}
 #endif
diff --git a/arch/arm/mach-virt/Makefile b/arch/arm/mach-virt/Makefile
index 042afc1..7ddbfa6 100644
--- a/arch/arm/mach-virt/Makefile
+++ b/arch/arm/mach-virt/Makefile
@@ -3,4 +3,3 @@
 #
 
 obj-y					:= virt.o
-obj-$(CONFIG_SMP)			+= platsmp.o
diff --git a/arch/arm/mach-virt/platsmp.c b/arch/arm/mach-virt/platsmp.c
deleted file mode 100644
index 8badaab..0000000
--- a/arch/arm/mach-virt/platsmp.c
+++ /dev/null
@@ -1,58 +0,0 @@
-/*
- * Dummy Virtual Machine - does what it says on the tin.
- *
- * Copyright (C) 2012 ARM Ltd
- * Author: Will Deacon <will.deacon at arm.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.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program.  If not, see <http://www.gnu.org/licenses/>.
- */
-
-#include <linux/init.h>
-#include <linux/smp.h>
-#include <linux/of.h>
-
-#include <linux/irqchip/arm-gic.h>
-
-#include <asm/psci.h>
-#include <asm/smp_plat.h>
-
-extern void secondary_startup(void);
-
-static void __init virt_smp_init_cpus(void)
-{
-}
-
-static void __init virt_smp_prepare_cpus(unsigned int max_cpus)
-{
-}
-
-static int __cpuinit virt_boot_secondary(unsigned int cpu,
-					 struct task_struct *idle)
-{
-	if (psci_ops.cpu_on)
-		return psci_ops.cpu_on(cpu_logical_map(cpu),
-				       __pa(secondary_startup));
-	return -ENODEV;
-}
-
-static void __cpuinit virt_secondary_init(unsigned int cpu)
-{
-	gic_secondary_init(0);
-}
-
-struct smp_operations __initdata virt_smp_ops = {
-	.smp_init_cpus		= virt_smp_init_cpus,
-	.smp_prepare_cpus	= virt_smp_prepare_cpus,
-	.smp_secondary_init	= virt_secondary_init,
-	.smp_boot_secondary	= virt_boot_secondary,
-};
diff --git a/arch/arm/mach-virt/virt.c b/arch/arm/mach-virt/virt.c
index 31666f6..4438ed0 100644
--- a/arch/arm/mach-virt/virt.c
+++ b/arch/arm/mach-virt/virt.c
@@ -43,12 +43,9 @@ static const char *virt_dt_match[] = {
 	NULL
 };
 
-extern struct smp_operations virt_smp_ops;
-
 DT_MACHINE_START(VIRT, "Dummy Virtual Machine")
 	.init_irq	= irqchip_init,
 	.init_time	= virt_timer_init,
 	.init_machine	= virt_init,
-	.smp		= smp_ops(virt_smp_ops),
 	.dt_compat	= virt_dt_match,
 MACHINE_END
-- 
1.7.2.5



From steve.capper at linaro.org  Tue Apr 30 12:30:39 2013
From: steve.capper at linaro.org (Steve Capper)
Date: Tue, 30 Apr 2013 17:30:39 +0100
Subject: [RFC PATCH 0/9] HugeTLB and THP support for ARM64.
Message-ID: <1367339448-21727-1-git-send-email-steve.capper@linaro.org>

This series brings huge pages and transparent huge pages to ARM64.
The functionality is very similar to x86, and a lot of code that can
be used by both ARM64 and x86 is brought into mm to avoid the need
for code duplication.

One notable difference from x86 is that ARM64 supports normal pages
that are 64KB. When 64KB pages are enabled, huge page and
transparent huge pages are 512MB only, otherwise the sizes match
x86.

This series applies to 3.9, and requires one additional patch
ARM64: mm: Correct show_pte behaviour
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-April/164157.html

I've tested this under the ARMv8 models (Fast and Foundation) and
the x86 code has been tested in a KVM guest. libhugetlbfs was used
for testing under both architectures.

Any comments would be greatly appreciated.

Steve Capper (9):
  mm: hugetlb: Copy huge_pmd_share from x86 to mm.
  x86: mm: Remove x86 version of huge_pmd_share.
  mm: hugetlb: Copy general hugetlb code from x86 to mm.
  x86: mm: Remove general hugetlb code from x86.
  ARM64: mm: Add support for flushing huge pages.
  ARM64: mm: Restore memblock limit when map_mem finished.
  ARM64: mm: HugeTLB support.
  ARM64: mm: Introduce MAX_ZONE_ORDER for 64K and THP.
  ARM64: mm: THP support.

 arch/arm64/Kconfig                     |  29 +++++
 arch/arm64/include/asm/hugetlb.h       | 121 ++++++++++++++++++
 arch/arm64/include/asm/pgtable-hwdef.h |   2 +
 arch/arm64/include/asm/pgtable.h       |  56 +++++++++
 arch/arm64/include/asm/tlb.h           |   6 +
 arch/arm64/include/asm/tlbflush.h      |   2 +
 arch/arm64/mm/Makefile                 |   1 +
 arch/arm64/mm/fault.c                  |  19 +--
 arch/arm64/mm/flush.c                  |   3 +-
 arch/arm64/mm/hugetlbpage.c            |  70 +++++++++++
 arch/arm64/mm/mmu.c                    |  19 ++-
 arch/x86/Kconfig                       |   6 +
 arch/x86/mm/hugetlbpage.c              | 187 ----------------------------
 include/linux/hugetlb.h                |   4 +
 mm/hugetlb.c                           | 219 +++++++++++++++++++++++++++++++--
 15 files changed, 526 insertions(+), 218 deletions(-)
 create mode 100644 arch/arm64/include/asm/hugetlb.h
 create mode 100644 arch/arm64/mm/hugetlbpage.c

-- 
1.8.1.4



From steve.capper at linaro.org  Tue Apr 30 12:30:40 2013
From: steve.capper at linaro.org (Steve Capper)
Date: Tue, 30 Apr 2013 17:30:40 +0100
Subject: [RFC PATCH 1/9] mm: hugetlb: Copy huge_pmd_share from x86 to mm.
In-Reply-To: <1367339448-21727-1-git-send-email-steve.capper@linaro.org>
References: <1367339448-21727-1-git-send-email-steve.capper@linaro.org>
Message-ID: <1367339448-21727-2-git-send-email-steve.capper@linaro.org>

Under x86, multiple puds can be made to reference the same bank of
huge pmds provided that they represent a full PUD_SIZE of shared
huge memory that is aligned to a PUD_SIZE boundary.

The code to share pmds does not require any architecture specific
knowledge other than the fact that pmds can be indexed, thus can
be beneficial to some other architectures.

This patch copies the huge pmd sharing (and unsharing) logic from
x86/ to mm/ and introduces a new config option to activate it:
CONFIG_ARCH_WANTS_HUGE_PMD_SHARE

Signed-off-by: Steve Capper <steve.capper at linaro.org>
---
 include/linux/hugetlb.h |   4 ++
 mm/hugetlb.c            | 122 ++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 126 insertions(+)

diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index 16e4e9a..795c32d 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -68,6 +68,10 @@ void hugetlb_unreserve_pages(struct inode *inode, long offset, long freed);
 int dequeue_hwpoisoned_huge_page(struct page *page);
 void copy_huge_page(struct page *dst, struct page *src);
 
+#ifdef CONFIG_ARCH_WANT_HUGE_PMD_SHARE
+pte_t *huge_pmd_share(struct mm_struct *mm, unsigned long addr, pud_t *pud);
+#endif
+
 extern unsigned long hugepages_treat_as_movable;
 extern const unsigned long hugetlb_zero, hugetlb_infinity;
 extern int sysctl_hugetlb_shm_group;
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index ca9a7c6..41179b0 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -3142,6 +3142,128 @@ void hugetlb_unreserve_pages(struct inode *inode, long offset, long freed)
 	hugetlb_acct_memory(h, -(chg - freed));
 }
 
+#ifdef CONFIG_ARCH_WANT_HUGE_PMD_SHARE
+static unsigned long page_table_shareable(struct vm_area_struct *svma,
+				struct vm_area_struct *vma,
+				unsigned long addr, pgoff_t idx)
+{
+	unsigned long saddr = ((idx - svma->vm_pgoff) << PAGE_SHIFT) +
+				svma->vm_start;
+	unsigned long sbase = saddr & PUD_MASK;
+	unsigned long s_end = sbase + PUD_SIZE;
+
+	/* Allow segments to share if only one is marked locked */
+	unsigned long vm_flags = vma->vm_flags & ~VM_LOCKED;
+	unsigned long svm_flags = svma->vm_flags & ~VM_LOCKED;
+
+	/*
+	 * match the virtual addresses, permission and the alignment of the
+	 * page table page.
+	 */
+	if (pmd_index(addr) != pmd_index(saddr) ||
+	    vm_flags != svm_flags ||
+	    sbase < svma->vm_start || svma->vm_end < s_end)
+		return 0;
+
+	return saddr;
+}
+
+static int vma_shareable(struct vm_area_struct *vma, unsigned long addr)
+{
+	unsigned long base = addr & PUD_MASK;
+	unsigned long end = base + PUD_SIZE;
+
+	/*
+	 * check on proper vm_flags and page table alignment
+	 */
+	if (vma->vm_flags & VM_MAYSHARE &&
+	    vma->vm_start <= base && end <= vma->vm_end)
+		return 1;
+	return 0;
+}
+
+/*
+ * Search for a shareable pmd page for hugetlb. In any case calls pmd_alloc()
+ * and returns the corresponding pte. While this is not necessary for the
+ * !shared pmd case because we can allocate the pmd later as well, it makes the
+ * code much cleaner. pmd allocation is essential for the shared case because
+ * pud has to be populated inside the same i_mmap_mutex section - otherwise
+ * racing tasks could either miss the sharing (see huge_pte_offset) or select a
+ * bad pmd for sharing.
+ */
+pte_t *huge_pmd_share(struct mm_struct *mm, unsigned long addr, pud_t *pud)
+{
+	struct vm_area_struct *vma = find_vma(mm, addr);
+	struct address_space *mapping = vma->vm_file->f_mapping;
+	pgoff_t idx = ((addr - vma->vm_start) >> PAGE_SHIFT) +
+			vma->vm_pgoff;
+	struct vm_area_struct *svma;
+	unsigned long saddr;
+	pte_t *spte = NULL;
+	pte_t *pte;
+
+	if (!vma_shareable(vma, addr))
+		return (pte_t *)pmd_alloc(mm, pud, addr);
+
+	mutex_lock(&mapping->i_mmap_mutex);
+	vma_interval_tree_foreach(svma, &mapping->i_mmap, idx, idx) {
+		if (svma == vma)
+			continue;
+
+		saddr = page_table_shareable(svma, vma, addr, idx);
+		if (saddr) {
+			spte = huge_pte_offset(svma->vm_mm, saddr);
+			if (spte) {
+				get_page(virt_to_page(spte));
+				break;
+			}
+		}
+	}
+
+	if (!spte)
+		goto out;
+
+	spin_lock(&mm->page_table_lock);
+	if (pud_none(*pud))
+		pud_populate(mm, pud,
+				(pmd_t *)((unsigned long)spte & PAGE_MASK));
+	else
+		put_page(virt_to_page(spte));
+	spin_unlock(&mm->page_table_lock);
+out:
+	pte = (pte_t *)pmd_alloc(mm, pud, addr);
+	mutex_unlock(&mapping->i_mmap_mutex);
+	return pte;
+}
+
+/*
+ * unmap huge page backed by shared pte.
+ *
+ * Hugetlb pte page is ref counted at the time of mapping.  If pte is shared
+ * indicated by page_count > 1, unmap is achieved by clearing pud and
+ * decrementing the ref count. If count == 1, the pte page is not shared.
+ *
+ * called with vma->vm_mm->page_table_lock held.
+ *
+ * returns: 1 successfully unmapped a shared pte page
+ *	    0 the underlying pte page is not shared, or it is the last user
+ */
+int huge_pmd_unshare(struct mm_struct *mm, unsigned long *addr, pte_t *ptep)
+{
+	pgd_t *pgd = pgd_offset(mm, *addr);
+	pud_t *pud = pud_offset(pgd, *addr);
+
+	BUG_ON(page_count(virt_to_page(ptep)) == 0);
+	if (page_count(virt_to_page(ptep)) == 1)
+		return 0;
+
+	pud_clear(pud);
+	put_page(virt_to_page(ptep));
+	*addr = ALIGN(*addr, HPAGE_SIZE * PTRS_PER_PTE) - HPAGE_SIZE;
+	return 1;
+}
+#endif /* CONFIG_ARCH_WANT_HUGE_PMD_SHARE */
+
 #ifdef CONFIG_MEMORY_FAILURE
 
 /* Should be called in hugetlb_lock */
-- 
1.8.1.4



From steve.capper at linaro.org  Tue Apr 30 12:30:43 2013
From: steve.capper at linaro.org (Steve Capper)
Date: Tue, 30 Apr 2013 17:30:43 +0100
Subject: [RFC PATCH 4/9] x86: mm: Remove general hugetlb code from x86.
In-Reply-To: <1367339448-21727-1-git-send-email-steve.capper@linaro.org>
References: <1367339448-21727-1-git-send-email-steve.capper@linaro.org>
Message-ID: <1367339448-21727-5-git-send-email-steve.capper@linaro.org>

huge_pte_alloc, huge_pte_offset and follow_huge_p[mu]d have
already been copied over to mm.

This patch removes the x86 copies of these functions and activates
the general ones by enabling:
CONFIG_ARCH_WANT_GENERAL_HUGETLB

Signed-off-by: Steve Capper <steve.capper at linaro.org>
---
 arch/x86/Kconfig          |  3 +++
 arch/x86/mm/hugetlbpage.c | 67 -----------------------------------------------
 2 files changed, 3 insertions(+), 67 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 60e3c402..db1ff87 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -215,6 +215,9 @@ config ARCH_SUSPEND_POSSIBLE
 config ARCH_WANT_HUGE_PMD_SHARE
 	def_bool y
 
+config ARCH_WANT_GENERAL_HUGETLB
+	def_bool y
+
 config ZONE_DMA32
 	bool
 	default X86_64
diff --git a/arch/x86/mm/hugetlbpage.c b/arch/x86/mm/hugetlbpage.c
index 7e522a3..7e73e8c 100644
--- a/arch/x86/mm/hugetlbpage.c
+++ b/arch/x86/mm/hugetlbpage.c
@@ -16,49 +16,6 @@
 #include <asm/tlbflush.h>
 #include <asm/pgalloc.h>
 
-pte_t *huge_pte_alloc(struct mm_struct *mm,
-			unsigned long addr, unsigned long sz)
-{
-	pgd_t *pgd;
-	pud_t *pud;
-	pte_t *pte = NULL;
-
-	pgd = pgd_offset(mm, addr);
-	pud = pud_alloc(mm, pgd, addr);
-	if (pud) {
-		if (sz == PUD_SIZE) {
-			pte = (pte_t *)pud;
-		} else {
-			BUG_ON(sz != PMD_SIZE);
-			if (pud_none(*pud))
-				pte = huge_pmd_share(mm, addr, pud);
-			else
-				pte = (pte_t *)pmd_alloc(mm, pud, addr);
-		}
-	}
-	BUG_ON(pte && !pte_none(*pte) && !pte_huge(*pte));
-
-	return pte;
-}
-
-pte_t *huge_pte_offset(struct mm_struct *mm, unsigned long addr)
-{
-	pgd_t *pgd;
-	pud_t *pud;
-	pmd_t *pmd = NULL;
-
-	pgd = pgd_offset(mm, addr);
-	if (pgd_present(*pgd)) {
-		pud = pud_offset(pgd, addr);
-		if (pud_present(*pud)) {
-			if (pud_large(*pud))
-				return (pte_t *)pud;
-			pmd = pmd_offset(pud, addr);
-		}
-	}
-	return (pte_t *) pmd;
-}
-
 #if 0	/* This is just for testing */
 struct page *
 follow_huge_addr(struct mm_struct *mm, unsigned long address, int write)
@@ -120,30 +77,6 @@ int pud_huge(pud_t pud)
 	return !!(pud_val(pud) & _PAGE_PSE);
 }
 
-struct page *
-follow_huge_pmd(struct mm_struct *mm, unsigned long address,
-		pmd_t *pmd, int write)
-{
-	struct page *page;
-
-	page = pte_page(*(pte_t *)pmd);
-	if (page)
-		page += ((address & ~PMD_MASK) >> PAGE_SHIFT);
-	return page;
-}
-
-struct page *
-follow_huge_pud(struct mm_struct *mm, unsigned long address,
-		pud_t *pud, int write)
-{
-	struct page *page;
-
-	page = pte_page(*(pte_t *)pud);
-	if (page)
-		page += ((address & ~PUD_MASK) >> PAGE_SHIFT);
-	return page;
-}
-
 #endif
 
 /* x86_64 also uses this file */
-- 
1.8.1.4



From steve.capper at linaro.org  Tue Apr 30 12:30:41 2013
From: steve.capper at linaro.org (Steve Capper)
Date: Tue, 30 Apr 2013 17:30:41 +0100
Subject: [RFC PATCH 2/9] x86: mm: Remove x86 version of huge_pmd_share.
In-Reply-To: <1367339448-21727-1-git-send-email-steve.capper@linaro.org>
References: <1367339448-21727-1-git-send-email-steve.capper@linaro.org>
Message-ID: <1367339448-21727-3-git-send-email-steve.capper@linaro.org>

The huge_pmd_share code has been copied over to mm/hugetlb.c to
make it accessible to other architectures.

Remove the x86 copy of the huge_pmd_share code and enable the
ARCH_WANT_HUGE_PMD_SHARE config flag. That way we reference the
general one.

Signed-off-by: Steve Capper <steve.capper at linaro.org>
---
 arch/x86/Kconfig          |   3 ++
 arch/x86/mm/hugetlbpage.c | 120 ----------------------------------------------
 2 files changed, 3 insertions(+), 120 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 70c0f3d..60e3c402 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -212,6 +212,9 @@ config ARCH_HIBERNATION_POSSIBLE
 config ARCH_SUSPEND_POSSIBLE
 	def_bool y
 
+config ARCH_WANT_HUGE_PMD_SHARE
+	def_bool y
+
 config ZONE_DMA32
 	bool
 	default X86_64
diff --git a/arch/x86/mm/hugetlbpage.c b/arch/x86/mm/hugetlbpage.c
index ae1aa71..7e522a3 100644
--- a/arch/x86/mm/hugetlbpage.c
+++ b/arch/x86/mm/hugetlbpage.c
@@ -16,126 +16,6 @@
 #include <asm/tlbflush.h>
 #include <asm/pgalloc.h>
 
-static unsigned long page_table_shareable(struct vm_area_struct *svma,
-				struct vm_area_struct *vma,
-				unsigned long addr, pgoff_t idx)
-{
-	unsigned long saddr = ((idx - svma->vm_pgoff) << PAGE_SHIFT) +
-				svma->vm_start;
-	unsigned long sbase = saddr & PUD_MASK;
-	unsigned long s_end = sbase + PUD_SIZE;
-
-	/* Allow segments to share if only one is marked locked */
-	unsigned long vm_flags = vma->vm_flags & ~VM_LOCKED;
-	unsigned long svm_flags = svma->vm_flags & ~VM_LOCKED;
-
-	/*
-	 * match the virtual addresses, permission and the alignment of the
-	 * page table page.
-	 */
-	if (pmd_index(addr) != pmd_index(saddr) ||
-	    vm_flags != svm_flags ||
-	    sbase < svma->vm_start || svma->vm_end < s_end)
-		return 0;
-
-	return saddr;
-}
-
-static int vma_shareable(struct vm_area_struct *vma, unsigned long addr)
-{
-	unsigned long base = addr & PUD_MASK;
-	unsigned long end = base + PUD_SIZE;
-
-	/*
-	 * check on proper vm_flags and page table alignment
-	 */
-	if (vma->vm_flags & VM_MAYSHARE &&
-	    vma->vm_start <= base && end <= vma->vm_end)
-		return 1;
-	return 0;
-}
-
-/*
- * Search for a shareable pmd page for hugetlb. In any case calls pmd_alloc()
- * and returns the corresponding pte. While this is not necessary for the
- * !shared pmd case because we can allocate the pmd later as well, it makes the
- * code much cleaner. pmd allocation is essential for the shared case because
- * pud has to be populated inside the same i_mmap_mutex section - otherwise
- * racing tasks could either miss the sharing (see huge_pte_offset) or select a
- * bad pmd for sharing.
- */
-static pte_t *
-huge_pmd_share(struct mm_struct *mm, unsigned long addr, pud_t *pud)
-{
-	struct vm_area_struct *vma = find_vma(mm, addr);
-	struct address_space *mapping = vma->vm_file->f_mapping;
-	pgoff_t idx = ((addr - vma->vm_start) >> PAGE_SHIFT) +
-			vma->vm_pgoff;
-	struct vm_area_struct *svma;
-	unsigned long saddr;
-	pte_t *spte = NULL;
-	pte_t *pte;
-
-	if (!vma_shareable(vma, addr))
-		return (pte_t *)pmd_alloc(mm, pud, addr);
-
-	mutex_lock(&mapping->i_mmap_mutex);
-	vma_interval_tree_foreach(svma, &mapping->i_mmap, idx, idx) {
-		if (svma == vma)
-			continue;
-
-		saddr = page_table_shareable(svma, vma, addr, idx);
-		if (saddr) {
-			spte = huge_pte_offset(svma->vm_mm, saddr);
-			if (spte) {
-				get_page(virt_to_page(spte));
-				break;
-			}
-		}
-	}
-
-	if (!spte)
-		goto out;
-
-	spin_lock(&mm->page_table_lock);
-	if (pud_none(*pud))
-		pud_populate(mm, pud, (pmd_t *)((unsigned long)spte & PAGE_MASK));
-	else
-		put_page(virt_to_page(spte));
-	spin_unlock(&mm->page_table_lock);
-out:
-	pte = (pte_t *)pmd_alloc(mm, pud, addr);
-	mutex_unlock(&mapping->i_mmap_mutex);
-	return pte;
-}
-
-/*
- * unmap huge page backed by shared pte.
- *
- * Hugetlb pte page is ref counted at the time of mapping.  If pte is shared
- * indicated by page_count > 1, unmap is achieved by clearing pud and
- * decrementing the ref count. If count == 1, the pte page is not shared.
- *
- * called with vma->vm_mm->page_table_lock held.
- *
- * returns: 1 successfully unmapped a shared pte page
- *	    0 the underlying pte page is not shared, or it is the last user
- */
-int huge_pmd_unshare(struct mm_struct *mm, unsigned long *addr, pte_t *ptep)
-{
-	pgd_t *pgd = pgd_offset(mm, *addr);
-	pud_t *pud = pud_offset(pgd, *addr);
-
-	BUG_ON(page_count(virt_to_page(ptep)) == 0);
-	if (page_count(virt_to_page(ptep)) == 1)
-		return 0;
-
-	pud_clear(pud);
-	put_page(virt_to_page(ptep));
-	*addr = ALIGN(*addr, HPAGE_SIZE * PTRS_PER_PTE) - HPAGE_SIZE;
-	return 1;
-}
-
 pte_t *huge_pte_alloc(struct mm_struct *mm,
 			unsigned long addr, unsigned long sz)
 {
-- 
1.8.1.4



From steve.capper at linaro.org  Tue Apr 30 12:30:42 2013
From: steve.capper at linaro.org (Steve Capper)
Date: Tue, 30 Apr 2013 17:30:42 +0100
Subject: [RFC PATCH 3/9] mm: hugetlb: Copy general hugetlb code from x86 to mm.
In-Reply-To: <1367339448-21727-1-git-send-email-steve.capper@linaro.org>
References: <1367339448-21727-1-git-send-email-steve.capper@linaro.org>
Message-ID: <1367339448-21727-4-git-send-email-steve.capper@linaro.org>

The huge_pte_alloc, huge_pte_offset and follow_huge_p[mu]d
functions in x86/mm/hugetlbpage.c do not rely on any architecture
specific knowledge other than the fact that pmds and puds can be
treated as huge ptes.

To allow other architectures to use this code (and reduce the need
for code duplication), this patch copies these functions into mm
and provides a config flag to activate them:
CONFIG_ARCH_WANT_GENERAL_HUGETLB

If CONFIG_ARCH_WANT_HUGE_PMD_SHARE is also active then the
huge_pmd_share code will be called by huge_pte_alloc (othewise we
call pmd_alloc and skip the sharing code).

Signed-off-by: Steve Capper <steve.capper at linaro.org>
---
 mm/hugetlb.c | 97 ++++++++++++++++++++++++++++++++++++++++++++++++++++++------
 1 file changed, 88 insertions(+), 9 deletions(-)

diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 41179b0..e1dc5ae 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -2915,15 +2915,6 @@ out_mutex:
 	return ret;
 }
 
-/* Can be overriden by architectures */
-__attribute__((weak)) struct page *
-follow_huge_pud(struct mm_struct *mm, unsigned long address,
-	       pud_t *pud, int write)
-{
-	BUG();
-	return NULL;
-}
-
 long follow_hugetlb_page(struct mm_struct *mm, struct vm_area_struct *vma,
 			 struct page **pages, struct vm_area_struct **vmas,
 			 unsigned long *position, unsigned long *nr_pages,
@@ -3262,8 +3253,96 @@ int huge_pmd_unshare(struct mm_struct *mm, unsigned long *addr, pte_t *ptep)
 	*addr = ALIGN(*addr, HPAGE_SIZE * PTRS_PER_PTE) - HPAGE_SIZE;
 	return 1;
 }
+#define want_pmd_share()	(1)
+#else /* !CONFIG_ARCH_WANT_HUGE_PMD_SHARE */
+pte_t *huge_pmd_share(struct mm_struct *mm, unsigned long addr, pud_t *pud)
+{
+	return NULL;
+}
+#define want_pmd_share()	(0)
 #endif /* CONFIG_ARCH_WANT_HUGE_PMD_SHARE */
 
+#ifdef CONFIG_ARCH_WANT_GENERAL_HUGETLB
+pte_t *huge_pte_alloc(struct mm_struct *mm,
+			unsigned long addr, unsigned long sz)
+{
+	pgd_t *pgd;
+	pud_t *pud;
+	pte_t *pte = NULL;
+
+	pgd = pgd_offset(mm, addr);
+	pud = pud_alloc(mm, pgd, addr);
+	if (pud) {
+		if (sz == PUD_SIZE) {
+			pte = (pte_t *)pud;
+		} else {
+			BUG_ON(sz != PMD_SIZE);
+			if (want_pmd_share() && pud_none(*pud))
+				pte = huge_pmd_share(mm, addr, pud);
+			else
+				pte = (pte_t *)pmd_alloc(mm, pud, addr);
+		}
+	}
+	BUG_ON(pte && !pte_none(*pte) && !pte_huge(*pte));
+
+	return pte;
+}
+
+pte_t *huge_pte_offset(struct mm_struct *mm, unsigned long addr)
+{
+	pgd_t *pgd;
+	pud_t *pud;
+	pmd_t *pmd = NULL;
+
+	pgd = pgd_offset(mm, addr);
+	if (pgd_present(*pgd)) {
+		pud = pud_offset(pgd, addr);
+		if (pud_present(*pud)) {
+			if (pud_large(*pud))
+				return (pte_t *)pud;
+			pmd = pmd_offset(pud, addr);
+		}
+	}
+	return (pte_t *) pmd;
+}
+
+struct page *
+follow_huge_pmd(struct mm_struct *mm, unsigned long address,
+		pmd_t *pmd, int write)
+{
+	struct page *page;
+
+	page = pte_page(*(pte_t *)pmd);
+	if (page)
+		page += ((address & ~PMD_MASK) >> PAGE_SHIFT);
+	return page;
+}
+
+struct page *
+follow_huge_pud(struct mm_struct *mm, unsigned long address,
+		pud_t *pud, int write)
+{
+	struct page *page;
+
+	page = pte_page(*(pte_t *)pud);
+	if (page)
+		page += ((address & ~PUD_MASK) >> PAGE_SHIFT);
+	return page;
+}
+
+#else /* !CONFIG_ARCH_WANT_GENERAL_HUGETLB */
+
+/* Can be overriden by architectures */
+__attribute__((weak)) struct page *
+follow_huge_pud(struct mm_struct *mm, unsigned long address,
+	       pud_t *pud, int write)
+{
+	BUG();
+	return NULL;
+}
+
+#endif /* CONFIG_ARCH_WANT_GENERAL_HUGETLB */
+
 #ifdef CONFIG_MEMORY_FAILURE
 
 /* Should be called in hugetlb_lock */
-- 
1.8.1.4



From steve.capper at linaro.org  Tue Apr 30 12:30:44 2013
From: steve.capper at linaro.org (Steve Capper)
Date: Tue, 30 Apr 2013 17:30:44 +0100
Subject: [RFC PATCH 5/9] ARM64: mm: Add support for flushing huge pages.
In-Reply-To: <1367339448-21727-1-git-send-email-steve.capper@linaro.org>
References: <1367339448-21727-1-git-send-email-steve.capper@linaro.org>
Message-ID: <1367339448-21727-6-git-send-email-steve.capper@linaro.org>

The code to flush the dcache of a dirty page, __flush_dcache_page,
will only flush the head of a HugeTLB/THP page.

This patch adjusts __flush_dcache_page such that the order of the
compound page is used to determine the size of area to flush.

Signed-off-by: Steve Capper <steve.capper at linaro.org>
---
 arch/arm64/mm/flush.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/mm/flush.c b/arch/arm64/mm/flush.c
index 88611c3..71c182d 100644
--- a/arch/arm64/mm/flush.c
+++ b/arch/arm64/mm/flush.c
@@ -72,7 +72,8 @@ void copy_to_user_page(struct vm_area_struct *vma, struct page *page,
 
 void __flush_dcache_page(struct page *page)
 {
-	__flush_dcache_area(page_address(page), PAGE_SIZE);
+	size_t page_size = PAGE_SIZE << compound_order(page);
+	__flush_dcache_area(page_address(page), page_size);
 }
 
 void __sync_icache_dcache(pte_t pte, unsigned long addr)
-- 
1.8.1.4



From steve.capper at linaro.org  Tue Apr 30 12:30:45 2013
From: steve.capper at linaro.org (Steve Capper)
Date: Tue, 30 Apr 2013 17:30:45 +0100
Subject: [RFC PATCH 6/9] ARM64: mm: Restore memblock limit when map_mem
 finished.
In-Reply-To: <1367339448-21727-1-git-send-email-steve.capper@linaro.org>
References: <1367339448-21727-1-git-send-email-steve.capper@linaro.org>
Message-ID: <1367339448-21727-7-git-send-email-steve.capper@linaro.org>

In paging_init the memblock limit is set to restrict any addresses
returned by early_alloc to fit within the initial direct kernel
mapping in swapper_pg_dir. This allows map_mem to allocate puds,
pmds and ptes from the initial direct kernel mapping.

The limit stays low after paging_init() though, meaning any
bootmem allocations will be from a restricted subset of memory.
Gigabyte huge pages, for instance, are normally allocated from
bootmem as their order (18) is too large for the default buddy
allocator (MAX_ORDER = 11).

This patch restores the memblock limit when map_mem has finished,
allowing gigabyte huge pages (and other objects) to be allocated
from all of bootmem.

Signed-off-by: Steve Capper <steve.capper at linaro.org>
---
 arch/arm64/mm/mmu.c | 19 +++++++++++++------
 1 file changed, 13 insertions(+), 6 deletions(-)

diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 70b8cd4..d23188c 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -297,6 +297,16 @@ static void __init map_mem(void)
 {
 	struct memblock_region *reg;
 
+	/*
+	 * Temporarily limit the memblock range. We need to do this as
+	 * create_mapping requires puds, pmds and ptes to be allocated from
+	 * memory addressable from the initial direct kernel mapping.
+	 *
+	 * The initial direct kernel mapping, located at swapper_pg_dir,
+	 * gives us PGDIR_SIZE memory starting from PHYS_OFFSET (aligned).
+	 */
+	memblock_set_current_limit((PHYS_OFFSET & PGDIR_MASK) + PGDIR_SIZE);
+
 	/* map all the memory banks */
 	for_each_memblock(memory, reg) {
 		phys_addr_t start = reg->base;
@@ -307,6 +317,9 @@ static void __init map_mem(void)
 
 		create_mapping(start, __phys_to_virt(start), end - start);
 	}
+
+	/* Limit no longer required. */
+	memblock_set_current_limit(MEMBLOCK_ALLOC_ANYWHERE);
 }
 
 /*
@@ -317,12 +330,6 @@ void __init paging_init(void)
 {
 	void *zero_page;
 
-	/*
-	 * Maximum PGDIR_SIZE addressable via the initial direct kernel
-	 * mapping in swapper_pg_dir.
-	 */
-	memblock_set_current_limit((PHYS_OFFSET & PGDIR_MASK) + PGDIR_SIZE);
-
 	init_mem_pgprot();
 	map_mem();
 
-- 
1.8.1.4



From steve.capper at linaro.org  Tue Apr 30 12:30:47 2013
From: steve.capper at linaro.org (Steve Capper)
Date: Tue, 30 Apr 2013 17:30:47 +0100
Subject: [RFC PATCH 8/9] ARM64: mm: Introduce MAX_ZONE_ORDER for 64K and THP.
In-Reply-To: <1367339448-21727-1-git-send-email-steve.capper@linaro.org>
References: <1367339448-21727-1-git-send-email-steve.capper@linaro.org>
Message-ID: <1367339448-21727-9-git-send-email-steve.capper@linaro.org>

The buddy allocator has a default order of 11, which is too low to
allocate enough memory for 512MB Transparent HugePages if our base
page size is 64K. For any order less than 13, the combination of
THP with 64K pages will cause a compile error.

This patch introduces the MAX_ZONE_ORDER config option that allows
one to explicitly override the order of the buddy allocator. If
64K pages and THP are enabled the minimum value is set to 13.

Signed-off-by: Steve Capper <steve.capper at linaro.org>
---
 arch/arm64/Kconfig | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 16aa780..908fd95 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -196,6 +196,23 @@ config ARCH_WANT_HUGE_PMD_SHARE
 
 source "mm/Kconfig"
 
+config FORCE_MAX_ZONEORDER
+	int "Maximum zone order"
+	range 11 64 if !(ARM64_64K_PAGES && TRANSPARENT_HUGEPAGE)
+	range 13 64 if ARM64_64K_PAGES && TRANSPARENT_HUGEPAGE
+	default "11" if !(ARM64_64K_PAGES && TRANSPARENT_HUGEPAGE)
+	default "13" if (ARM64_64K_PAGES && TRANSPARENT_HUGEPAGE)
+	help
+	  The kernel memory allocator divides physically contiguous memory
+	  blocks into "zones", where each zone is a power of two number of
+	  pages.  This option selects the largest power of two that the kernel
+	  keeps in the memory allocator.  If you need to allocate very large
+	  blocks of physically contiguous memory, then you may need to
+	  increase this value.
+
+	  This config option is actually maximum order plus one. For example,
+	  a value of 11 means that the largest free memory block is 2^10 pages.
+
 endmenu
 
 menu "Boot options"
-- 
1.8.1.4



From steve.capper at linaro.org  Tue Apr 30 12:30:46 2013
From: steve.capper at linaro.org (Steve Capper)
Date: Tue, 30 Apr 2013 17:30:46 +0100
Subject: [RFC PATCH 7/9] ARM64: mm: HugeTLB support.
In-Reply-To: <1367339448-21727-1-git-send-email-steve.capper@linaro.org>
References: <1367339448-21727-1-git-send-email-steve.capper@linaro.org>
Message-ID: <1367339448-21727-8-git-send-email-steve.capper@linaro.org>

Add huge page support to ARM64, different huge page sizes are
supported depending on the size of normal pages:

PAGE_SIZE is 4K:
   2MB - (pmds) these can be allocated at any time.
1024MB - (puds) usually allocated on bootup with the command line
         with something like: hugepagesz=1G hugepages=6

PAGE_SIZE is 64K:
 512MB - (pmds), usually allocated on bootup via command line.

Signed-off-by: Steve Capper <steve.capper at linaro.org>
---
 arch/arm64/Kconfig                     |   9 +++
 arch/arm64/include/asm/hugetlb.h       | 121 +++++++++++++++++++++++++++++++++
 arch/arm64/include/asm/pgtable-hwdef.h |   1 +
 arch/arm64/include/asm/pgtable.h       |   9 +++
 arch/arm64/mm/Makefile                 |   1 +
 arch/arm64/mm/fault.c                  |  19 ++----
 arch/arm64/mm/hugetlbpage.c            |  70 +++++++++++++++++++
 7 files changed, 215 insertions(+), 15 deletions(-)
 create mode 100644 arch/arm64/include/asm/hugetlb.h
 create mode 100644 arch/arm64/mm/hugetlbpage.c

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 43b0e9f..16aa780 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -185,6 +185,15 @@ config HW_PERF_EVENTS
 	  Enable hardware performance counter support for perf events. If
 	  disabled, perf events will use software events only.
 
+config SYS_SUPPORTS_HUGETLBFS
+	def_bool y if MMU
+
+config ARCH_WANT_GENERAL_HUGETLB
+	def_bool y if MMU
+
+config ARCH_WANT_HUGE_PMD_SHARE
+	def_bool y if !ARM64_64K_PAGES
+
 source "mm/Kconfig"
 
 endmenu
diff --git a/arch/arm64/include/asm/hugetlb.h b/arch/arm64/include/asm/hugetlb.h
new file mode 100644
index 0000000..d00d72a
--- /dev/null
+++ b/arch/arm64/include/asm/hugetlb.h
@@ -0,0 +1,121 @@
+/*
+ * arch/arm64/include/asm/hugetlb.h
+ *
+ * Copyright (C) 2013 Linaro Ltd.
+ *
+ * Based on arch/x86/include/asm/hugetlb.h
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#ifndef __ASM_HUGETLB_H
+#define __ASM_HUGETLB_H
+
+#include <asm/page.h>
+
+static inline pte_t huge_ptep_get(pte_t *ptep)
+{
+	return *ptep;
+}
+
+static inline void set_huge_pte_at(struct mm_struct *mm, unsigned long addr,
+				   pte_t *ptep, pte_t pte)
+{
+	set_pte_at(mm, addr, ptep, pte);
+}
+
+static inline void huge_ptep_clear_flush(struct vm_area_struct *vma,
+					 unsigned long addr, pte_t *ptep)
+{
+	ptep_clear_flush(vma, addr, ptep);
+}
+
+static inline void huge_ptep_set_wrprotect(struct mm_struct *mm,
+					   unsigned long addr, pte_t *ptep)
+{
+	ptep_set_wrprotect(mm, addr, ptep);
+}
+
+static inline pte_t huge_ptep_get_and_clear(struct mm_struct *mm,
+					    unsigned long addr, pte_t *ptep)
+{
+	return ptep_get_and_clear(mm, addr, ptep);
+}
+
+static inline int huge_ptep_set_access_flags(struct vm_area_struct *vma,
+					     unsigned long addr, pte_t *ptep,
+					     pte_t pte, int dirty)
+{
+	return ptep_set_access_flags(vma, addr, ptep, pte, dirty);
+}
+
+static inline void hugetlb_free_pgd_range(struct mmu_gather *tlb,
+					  unsigned long addr, unsigned long end,
+					  unsigned long floor,
+					  unsigned long ceiling)
+{
+	free_pgd_range(tlb, addr, end, floor, ceiling);
+}
+
+static inline int is_hugepage_only_range(struct mm_struct *mm,
+					 unsigned long addr, unsigned long len)
+{
+	return 0;
+}
+
+static inline int prepare_hugepage_range(struct file *file,
+					 unsigned long addr, unsigned long len)
+{
+	struct hstate *h = hstate_file(file);
+	if (len & ~huge_page_mask(h))
+		return -EINVAL;
+	if (addr & ~huge_page_mask(h))
+		return -EINVAL;
+	return 0;
+}
+
+static inline void hugetlb_prefault_arch_hook(struct mm_struct *mm)
+{
+}
+
+static inline int huge_pte_none(pte_t pte)
+{
+	return pte_none(pte);
+}
+
+static inline pte_t huge_pte_wrprotect(pte_t pte)
+{
+	return pte_wrprotect(pte);
+}
+
+static inline int arch_prepare_hugepage(struct page *page)
+{
+	return 0;
+}
+
+static inline void arch_release_hugepage(struct page *page)
+{
+}
+
+static inline void arch_clear_hugepage_flags(struct page *page)
+{
+	clear_bit(PG_dcache_clean, &page->flags);
+}
+
+static inline int pud_large(pud_t pud)
+{
+	return ((pud_val(pud) & PMD_TYPE_MASK) == PMD_TYPE_SECT);
+}
+
+#endif /* __ASM_HUGETLB_H */
diff --git a/arch/arm64/include/asm/pgtable-hwdef.h b/arch/arm64/include/asm/pgtable-hwdef.h
index 75fd13d..c3cac68 100644
--- a/arch/arm64/include/asm/pgtable-hwdef.h
+++ b/arch/arm64/include/asm/pgtable-hwdef.h
@@ -53,6 +53,7 @@
 #define PTE_TYPE_MASK		(_AT(pteval_t, 3) << 0)
 #define PTE_TYPE_FAULT		(_AT(pteval_t, 0) << 0)
 #define PTE_TYPE_PAGE		(_AT(pteval_t, 3) << 0)
+#define PTE_TYPE_HUGEPAGE	(_AT(pmdval_t, 1) << 0)
 #define PTE_USER		(_AT(pteval_t, 1) << 6)		/* AP[1] */
 #define PTE_RDONLY		(_AT(pteval_t, 1) << 7)		/* AP[2] */
 #define PTE_SHARED		(_AT(pteval_t, 3) << 8)		/* SH[1:0], inner shareable */
diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index e333a24..4b7a058 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -176,6 +176,15 @@ static inline void set_pte_at(struct mm_struct *mm, unsigned long addr,
 #define pte_huge(pte)		((pte_val(pte) & PTE_TYPE_MASK) == PTE_TYPE_HUGEPAGE)
 #define pte_mkhuge(pte)		(__pte((pte_val(pte) & ~PTE_TYPE_MASK) | PTE_TYPE_HUGEPAGE))
 
+/*
+ * Hugetlb definitions.
+ */
+#define HUGE_MAX_HSTATE		2
+#define HPAGE_SHIFT		PMD_SHIFT
+#define HPAGE_SIZE		(_AC(1, UL) << HPAGE_SHIFT)
+#define HPAGE_MASK		(~(HPAGE_SIZE - 1))
+#define HUGETLB_PAGE_ORDER	(HPAGE_SHIFT - PAGE_SHIFT)
+
 #define __HAVE_ARCH_PTE_SPECIAL
 
 /*
diff --git a/arch/arm64/mm/Makefile b/arch/arm64/mm/Makefile
index 3140a2a..b51d364 100644
--- a/arch/arm64/mm/Makefile
+++ b/arch/arm64/mm/Makefile
@@ -2,3 +2,4 @@ obj-y				:= dma-mapping.o extable.o fault.o init.o \
 				   cache.o copypage.o flush.o \
 				   ioremap.o mmap.o pgd.o mmu.o \
 				   context.o tlb.o proc.o
+obj-$(CONFIG_HUGETLB_PAGE)	+= hugetlbpage.o
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index 5263817..36e3080 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -363,17 +363,6 @@ static int __kprobes do_translation_fault(unsigned long addr,
 }
 
 /*
- * Some section permission faults need to be handled gracefully.  They can
- * happen due to a __{get,put}_user during an oops.
- */
-static int do_sect_fault(unsigned long addr, unsigned int esr,
-			 struct pt_regs *regs)
-{
-	do_bad_area(addr, esr, regs);
-	return 0;
-}
-
-/*
  * This abort handler always returns "fault".
  */
 static int do_bad(unsigned long addr, unsigned int esr, struct pt_regs *regs)
@@ -396,12 +385,12 @@ static struct fault_info {
 	{ do_translation_fault,	SIGSEGV, SEGV_MAPERR,	"level 2 translation fault"	},
 	{ do_page_fault,	SIGSEGV, SEGV_MAPERR,	"level 3 translation fault"	},
 	{ do_bad,		SIGBUS,  0,		"reserved access flag fault"	},
-	{ do_bad,		SIGSEGV, SEGV_ACCERR,	"level 1 access flag fault"	},
-	{ do_bad,		SIGSEGV, SEGV_ACCERR,	"level 2 access flag fault"	},
+	{ do_page_fault,	SIGSEGV, SEGV_ACCERR,	"level 1 access flag fault"	},
+	{ do_page_fault,	SIGSEGV, SEGV_ACCERR,	"level 2 access flag fault"	},
 	{ do_page_fault,	SIGSEGV, SEGV_ACCERR,	"level 3 access flag fault"	},
 	{ do_bad,		SIGBUS,  0,		"reserved permission fault"	},
-	{ do_bad,		SIGSEGV, SEGV_ACCERR,	"level 1 permission fault"	},
-	{ do_sect_fault,	SIGSEGV, SEGV_ACCERR,	"level 2 permission fault"	},
+	{ do_page_fault,	SIGSEGV, SEGV_ACCERR,	"level 1 permission fault"	},
+	{ do_page_fault,	SIGSEGV, SEGV_ACCERR,	"level 2 permission fault"	},
 	{ do_page_fault,	SIGSEGV, SEGV_ACCERR,	"level 3 permission fault"	},
 	{ do_bad,		SIGBUS,  0,		"synchronous external abort"	},
 	{ do_bad,		SIGBUS,  0,		"asynchronous external abort"	},
diff --git a/arch/arm64/mm/hugetlbpage.c b/arch/arm64/mm/hugetlbpage.c
new file mode 100644
index 0000000..06c74e8
--- /dev/null
+++ b/arch/arm64/mm/hugetlbpage.c
@@ -0,0 +1,70 @@
+/*
+ * arch/arm64/mm/hugetlbpage.c
+ *
+ * Copyright (C) 2013 Linaro Ltd.
+ *
+ * Based on arch/x86/mm/hugetlbpage.c.
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include <linux/init.h>
+#include <linux/fs.h>
+#include <linux/mm.h>
+#include <linux/hugetlb.h>
+#include <linux/pagemap.h>
+#include <linux/err.h>
+#include <linux/sysctl.h>
+#include <asm/mman.h>
+#include <asm/tlb.h>
+#include <asm/tlbflush.h>
+#include <asm/pgalloc.h>
+
+#ifndef CONFIG_ARCH_WANT_HUGE_PMD_SHARE
+int huge_pmd_unshare(struct mm_struct *mm, unsigned long *addr, pte_t *ptep)
+{
+	return 0;
+}
+#endif
+
+struct page *follow_huge_addr(struct mm_struct *mm, unsigned long address,
+			      int write)
+{
+	return ERR_PTR(-EINVAL);
+}
+
+int pmd_huge(pmd_t pmd)
+{
+	return (pmd_val(pmd) & PMD_TYPE_MASK) == PMD_TYPE_SECT;
+}
+
+int pud_huge(pud_t pud)
+{
+	return (pud_val(pud) & PMD_TYPE_MASK) == PMD_TYPE_SECT;
+}
+
+static __init int setup_hugepagesz(char *opt)
+{
+	unsigned long ps = memparse(opt, &opt);
+	if (ps == PMD_SIZE) {
+		hugetlb_add_hstate(PMD_SHIFT - PAGE_SHIFT);
+	} else if (ps == PUD_SIZE) {
+		hugetlb_add_hstate(PUD_SHIFT - PAGE_SHIFT);
+	} else {
+		pr_err("hugepagesz: Unsupported page size %lu M\n", ps >> 20);
+		return 0;
+	}
+	return 1;
+}
+__setup("hugepagesz=", setup_hugepagesz);
-- 
1.8.1.4



From steve.capper at linaro.org  Tue Apr 30 12:30:48 2013
From: steve.capper at linaro.org (Steve Capper)
Date: Tue, 30 Apr 2013 17:30:48 +0100
Subject: [RFC PATCH 9/9] ARM64: mm: THP support.
In-Reply-To: <1367339448-21727-1-git-send-email-steve.capper@linaro.org>
References: <1367339448-21727-1-git-send-email-steve.capper@linaro.org>
Message-ID: <1367339448-21727-10-git-send-email-steve.capper@linaro.org>

Bring Transparent HugePage support to ARM. The size of a
transparent huge page depends on the normal page size. A
transparent huge page is always represented as a pmd.

If PAGE_SIZE is 4K, THPs are 2MB.
If PAGE_SIZE is 64K, THPs are 512MB.

Signed-off-by: Steve Capper <steve.capper at linaro.org>
---
 arch/arm64/Kconfig                     |  3 +++
 arch/arm64/include/asm/pgtable-hwdef.h |  1 +
 arch/arm64/include/asm/pgtable.h       | 47 ++++++++++++++++++++++++++++++++++
 arch/arm64/include/asm/tlb.h           |  6 +++++
 arch/arm64/include/asm/tlbflush.h      |  2 ++
 5 files changed, 59 insertions(+)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 908fd95..9356802 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -194,6 +194,9 @@ config ARCH_WANT_GENERAL_HUGETLB
 config ARCH_WANT_HUGE_PMD_SHARE
 	def_bool y if !ARM64_64K_PAGES
 
+config HAVE_ARCH_TRANSPARENT_HUGEPAGE
+	def_bool y if MMU
+
 source "mm/Kconfig"
 
 config FORCE_MAX_ZONEORDER
diff --git a/arch/arm64/include/asm/pgtable-hwdef.h b/arch/arm64/include/asm/pgtable-hwdef.h
index c3cac68..862acf7 100644
--- a/arch/arm64/include/asm/pgtable-hwdef.h
+++ b/arch/arm64/include/asm/pgtable-hwdef.h
@@ -35,6 +35,7 @@
 /*
  * Section
  */
+#define PMD_SECT_RDONLY		(_AT(pmdval_t, 1) << 7)		/* AP[2] */
 #define PMD_SECT_S		(_AT(pmdval_t, 3) << 8)
 #define PMD_SECT_AF		(_AT(pmdval_t, 1) << 10)
 #define PMD_SECT_NG		(_AT(pmdval_t, 1) << 11)
diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index 4b7a058..06bfbd6 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -188,6 +188,53 @@ static inline void set_pte_at(struct mm_struct *mm, unsigned long addr,
 #define __HAVE_ARCH_PTE_SPECIAL
 
 /*
+ * Software PMD bits for THP
+ */
+
+#define PMD_SECT_DIRTY		(_AT(pmdval_t, 1) << 55)
+#define PMD_SECT_SPLITTING	(_AT(pmdval_t, 1) << 57)
+
+/*
+ * THP definitions.
+ */
+#define pmd_young(pmd)		(pmd_val(pmd) & PMD_SECT_AF)
+
+#define __HAVE_ARCH_PMD_WRITE
+#define pmd_write(pmd)		(!(pmd_val(pmd) & PMD_SECT_RDONLY))
+
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
+#define pmd_trans_huge(pmd)	((pmd_val(pmd) & PMD_TYPE_MASK) == PMD_TYPE_SECT)
+#define pmd_trans_splitting(pmd) (pmd_val(pmd) & PMD_SECT_SPLITTING)
+#endif
+
+#define PMD_BIT_FUNC(fn,op) \
+static inline pmd_t pmd_##fn(pmd_t pmd) { pmd_val(pmd) op; return pmd; }
+
+PMD_BIT_FUNC(wrprotect,	|= PMD_SECT_RDONLY);
+PMD_BIT_FUNC(mkold,	&= ~PMD_SECT_AF);
+PMD_BIT_FUNC(mksplitting, |= PMD_SECT_SPLITTING);
+PMD_BIT_FUNC(mkwrite,   &= ~PMD_SECT_RDONLY);
+PMD_BIT_FUNC(mkdirty,   |= PMD_SECT_DIRTY);
+PMD_BIT_FUNC(mkyoung,   |= PMD_SECT_AF);
+PMD_BIT_FUNC(mknotpresent, &= ~PMD_TYPE_MASK);
+
+#define pmd_mkhuge(pmd)		(__pmd((pmd_val(pmd) & ~PMD_TYPE_MASK) | PMD_TYPE_SECT))
+
+#define pmd_pfn(pmd)		(((pmd_val(pmd) & PMD_MASK) & PHYS_MASK) >> PAGE_SHIFT)
+#define pfn_pmd(pfn,prot)	(__pmd(((phys_addr_t)(pfn) << PAGE_SHIFT) | pgprot_val(prot)))
+#define mk_pmd(page,prot)	pfn_pmd(page_to_pfn(page),prot)
+
+#define pmd_page(pmd)           pfn_to_page(__phys_to_pfn(pmd_val(pmd) & PHYS_MASK))
+
+#define pmd_modify(pmd,newprot)	(__pmd(pmd_val(pmd) | pgprot_val(newprot)))
+#define set_pmd_at(mm, addr, pmdp, pmd)	set_pmd(pmdp, pmd)
+
+static inline int has_transparent_hugepage(void)
+{
+	return 1;
+}
+
+/*
  * Mark the prot value as uncacheable and unbufferable.
  */
 #define pgprot_noncached(prot) \
diff --git a/arch/arm64/include/asm/tlb.h b/arch/arm64/include/asm/tlb.h
index 654f096..46b3beb 100644
--- a/arch/arm64/include/asm/tlb.h
+++ b/arch/arm64/include/asm/tlb.h
@@ -187,4 +187,10 @@ static inline void __pmd_free_tlb(struct mmu_gather *tlb, pmd_t *pmdp,
 
 #define tlb_migrate_finish(mm)		do { } while (0)
 
+static inline void
+tlb_remove_pmd_tlb_entry(struct mmu_gather *tlb, pmd_t *pmdp, unsigned long addr)
+{
+	tlb_add_flush(tlb, addr);
+}
+
 #endif
diff --git a/arch/arm64/include/asm/tlbflush.h b/arch/arm64/include/asm/tlbflush.h
index 122d632..8b48203 100644
--- a/arch/arm64/include/asm/tlbflush.h
+++ b/arch/arm64/include/asm/tlbflush.h
@@ -117,6 +117,8 @@ static inline void update_mmu_cache(struct vm_area_struct *vma,
 	dsb();
 }
 
+#define update_mmu_cache_pmd(vma, address, pmd) do { } while (0)
+
 #endif
 
 #endif
-- 
1.8.1.4



From catalin.marinas at arm.com  Tue Apr 30 12:48:14 2013
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Tue, 30 Apr 2013 17:48:14 +0100
Subject: [RFC PATCH 3/9] mm: hugetlb: Copy general hugetlb code from
 x86 to mm.
In-Reply-To: <1367339448-21727-4-git-send-email-steve.capper@linaro.org>
References: <1367339448-21727-1-git-send-email-steve.capper@linaro.org>
 <1367339448-21727-4-git-send-email-steve.capper@linaro.org>
Message-ID: <20130430164814.GK29766@arm.com>

On Tue, Apr 30, 2013 at 05:30:42PM +0100, Steve Capper wrote:
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index 41179b0..e1dc5ae 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
...
> +pte_t *huge_pte_offset(struct mm_struct *mm, unsigned long addr)
> +{
> +	pgd_t *pgd;
> +	pud_t *pud;
> +	pmd_t *pmd = NULL;
> +
> +	pgd = pgd_offset(mm, addr);
> +	if (pgd_present(*pgd)) {
> +		pud = pud_offset(pgd, addr);
> +		if (pud_present(*pud)) {
> +			if (pud_large(*pud))

That's more of a question for the x86 guys - can we replace pud_large()
here with pud_huge()? It looks like the former simply checks for present
and huge, so pud_huge() would be enough. This saves an additional
definition.

-- 
Catalin


From cdall at cs.columbia.edu  Tue Apr 30 13:17:17 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Tue, 30 Apr 2013 10:17:17 -0700
Subject: [PATCH 1/4] ARM: KVM: be more thorough when invalidating TLBs
In-Reply-To: <1367331446-28030-2-git-send-email-marc.zyngier@arm.com>
References: <1367331446-28030-1-git-send-email-marc.zyngier@arm.com>
 <1367331446-28030-2-git-send-email-marc.zyngier@arm.com>
Message-ID: <CAEDV+g+LKEj_XdeLvMwxJhVQ9FG9=U6eqO7dPU340xX2oMkS0A@mail.gmail.com>

On Tue, Apr 30, 2013 at 7:17 AM, Marc Zyngier <marc.zyngier at arm.com> wrote:
> The KVM/ARM MMU code doesn't take care of invalidating TLBs before
> freeing a {pte,pmd} table. This could cause problems if the page
> is reallocated and then speculated into by another CPU.
>
> Reported-by: Catalin Marinas <catalin.marinas at arm.com>
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> ---
>  arch/arm/kvm/interrupts.S |  2 ++
>  arch/arm/kvm/mmu.c        | 36 +++++++++++++++++++++---------------
>  2 files changed, 23 insertions(+), 15 deletions(-)
>
> diff --git a/arch/arm/kvm/interrupts.S b/arch/arm/kvm/interrupts.S
> index f7793df..9e2d906c 100644
> --- a/arch/arm/kvm/interrupts.S
> +++ b/arch/arm/kvm/interrupts.S
> @@ -37,6 +37,8 @@ __kvm_hyp_code_start:
>   *
>   * void __kvm_tlb_flush_vmid_ipa(struct kvm *kvm, phys_addr_t ipa);
>   *
> + * Invalidate TLB for the given IPA, or invalidate all if ipa is zero.
> + *
>   * We rely on the hardware to broadcast the TLB invalidation to all CPUs
>   * inside the inner-shareable domain (which is the case for all v7
>   * implementations).  If we come across a non-IS SMP implementation, we'll
> diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
> index 9657065..71f2a57 100644
> --- a/arch/arm/kvm/mmu.c
> +++ b/arch/arm/kvm/mmu.c
> @@ -43,7 +43,8 @@ static phys_addr_t hyp_idmap_vector;
>
>  static void kvm_tlb_flush_vmid_ipa(struct kvm *kvm, phys_addr_t ipa)
>  {
> -       kvm_call_hyp(__kvm_tlb_flush_vmid_ipa, kvm, ipa);
> +       if (kvm)
> +               kvm_call_hyp(__kvm_tlb_flush_vmid_ipa, kvm, ipa);

this feels slightly abusive? could we add a comment that hyp page
table freeing don't need tlb flushing from these functions and don't
have a struct kvm?

alternatively it may be more clear to have something like:

if (kvm) /* Check if Hyp or Stage-2 page table */
    kvm_tlb_flush_vmid_ipa(kvm, addr);

in the callers, but, eh, maybe I'm over thinking this.

>  }
>
>  static int mmu_topup_memory_cache(struct kvm_mmu_memory_cache *cache,
> @@ -78,18 +79,20 @@ static void *mmu_memory_cache_alloc(struct kvm_mmu_memory_cache *mc)
>         return p;
>  }
>
> -static void clear_pud_entry(pud_t *pud)
> +static void clear_pud_entry(struct kvm *kvm, pud_t *pud, phys_addr_t addr)
>  {
>         pmd_t *pmd_table = pmd_offset(pud, 0);
>         pud_clear(pud);
> +       kvm_tlb_flush_vmid_ipa(kvm, addr);
>         pmd_free(NULL, pmd_table);
>         put_page(virt_to_page(pud));
>  }
>
> -static void clear_pmd_entry(pmd_t *pmd)
> +static void clear_pmd_entry(struct kvm *kvm, pmd_t *pmd, phys_addr_t addr)
>  {
>         pte_t *pte_table = pte_offset_kernel(pmd, 0);
>         pmd_clear(pmd);
> +       kvm_tlb_flush_vmid_ipa(kvm, addr);
>         pte_free_kernel(NULL, pte_table);
>         put_page(virt_to_page(pmd));
>  }
> @@ -100,11 +103,12 @@ static bool pmd_empty(pmd_t *pmd)
>         return page_count(pmd_page) == 1;
>  }
>
> -static void clear_pte_entry(pte_t *pte)
> +static void clear_pte_entry(struct kvm *kvm, pte_t *pte, phys_addr_t addr)
>  {
>         if (pte_present(*pte)) {
>                 kvm_set_pte(pte, __pte(0));
>                 put_page(virt_to_page(pte));
> +               kvm_tlb_flush_vmid_ipa(kvm, addr);

I enjoyed the fact that it's perfectly correct to have this flush
after the put_page.

>         }
>  }
>
> @@ -114,7 +118,8 @@ static bool pte_empty(pte_t *pte)
>         return page_count(pte_page) == 1;
>  }
>
> -static void unmap_range(pgd_t *pgdp, unsigned long long start, u64 size)
> +static void unmap_range(struct kvm *kvm, pgd_t *pgdp,
> +                       unsigned long long start, u64 size)
>  {
>         pgd_t *pgd;
>         pud_t *pud;
> @@ -138,15 +143,15 @@ static void unmap_range(pgd_t *pgdp, unsigned long long start, u64 size)
>                 }
>
>                 pte = pte_offset_kernel(pmd, addr);
> -               clear_pte_entry(pte);
> +               clear_pte_entry(kvm, pte, addr);
>                 range = PAGE_SIZE;
>
>                 /* If we emptied the pte, walk back up the ladder */
>                 if (pte_empty(pte)) {
> -                       clear_pmd_entry(pmd);
> +                       clear_pmd_entry(kvm, pmd, addr);
>                         range = PMD_SIZE;
>                         if (pmd_empty(pmd)) {
> -                               clear_pud_entry(pud);
> +                               clear_pud_entry(kvm, pud, addr);
>                                 range = PUD_SIZE;
>                         }
>                 }
> @@ -165,14 +170,14 @@ void free_boot_hyp_pgd(void)
>         mutex_lock(&kvm_hyp_pgd_mutex);
>
>         if (boot_hyp_pgd) {
> -               unmap_range(boot_hyp_pgd, hyp_idmap_start, PAGE_SIZE);
> -               unmap_range(boot_hyp_pgd, TRAMPOLINE_VA, PAGE_SIZE);
> +               unmap_range(NULL, boot_hyp_pgd, hyp_idmap_start, PAGE_SIZE);
> +               unmap_range(NULL, boot_hyp_pgd, TRAMPOLINE_VA, PAGE_SIZE);
>                 kfree(boot_hyp_pgd);
>                 boot_hyp_pgd = NULL;
>         }
>
>         if (hyp_pgd)
> -               unmap_range(hyp_pgd, TRAMPOLINE_VA, PAGE_SIZE);
> +               unmap_range(NULL, hyp_pgd, TRAMPOLINE_VA, PAGE_SIZE);
>
>         kfree(init_bounce_page);
>         init_bounce_page = NULL;
> @@ -200,9 +205,10 @@ void free_hyp_pgds(void)
>
>         if (hyp_pgd) {
>                 for (addr = PAGE_OFFSET; virt_addr_valid(addr); addr += PGDIR_SIZE)
> -                       unmap_range(hyp_pgd, KERN_TO_HYP(addr), PGDIR_SIZE);
> +                       unmap_range(NULL, hyp_pgd, KERN_TO_HYP(addr), PGDIR_SIZE);
>                 for (addr = VMALLOC_START; is_vmalloc_addr((void*)addr); addr += PGDIR_SIZE)
> -                       unmap_range(hyp_pgd, KERN_TO_HYP(addr), PGDIR_SIZE);
> +                       unmap_range(NULL, hyp_pgd, KERN_TO_HYP(addr), PGDIR_SIZE);
> +
>                 kfree(hyp_pgd);
>                 hyp_pgd = NULL;
>         }
> @@ -393,7 +399,7 @@ int kvm_alloc_stage2_pgd(struct kvm *kvm)
>   */
>  static void unmap_stage2_range(struct kvm *kvm, phys_addr_t start, u64 size)
>  {
> -       unmap_range(kvm->arch.pgd, start, size);
> +       unmap_range(kvm, kvm->arch.pgd, start, size);
>  }
>
>  /**
> @@ -413,6 +419,7 @@ void kvm_free_stage2_pgd(struct kvm *kvm)
>                 return;
>
>         unmap_stage2_range(kvm, 0, KVM_PHYS_SIZE);
> +       kvm_tlb_flush_vmid_ipa(kvm, 0); /* Invalidate TLB ALL */
>         free_pages((unsigned long)kvm->arch.pgd, S2_PGD_ORDER);
>         kvm->arch.pgd = NULL;
>  }
> @@ -675,7 +682,6 @@ static void handle_hva_to_gpa(struct kvm *kvm,
>  static void kvm_unmap_hva_handler(struct kvm *kvm, gpa_t gpa, void *data)
>  {
>         unmap_stage2_range(kvm, gpa, PAGE_SIZE);
> -       kvm_tlb_flush_vmid_ipa(kvm, gpa);
>  }
>
>  int kvm_unmap_hva(struct kvm *kvm, unsigned long hva)
> --
> 1.8.2.1
>
>
looks good to me,

-Christoffer


From cov at codeaurora.org  Tue Apr 30 13:22:11 2013
From: cov at codeaurora.org (Christopher Covington)
Date: Tue, 30 Apr 2013 13:22:11 -0400
Subject: [PATCH v3 1/4] arm: Move the set_handle_irq and handle_arch_irq
 declarations to asm/irq.h
In-Reply-To: <1363714703-9629-2-git-send-email-catalin.marinas@arm.com>
References: <1363714703-9629-1-git-send-email-catalin.marinas@arm.com>
 <1363714703-9629-2-git-send-email-catalin.marinas@arm.com>
Message-ID: <517FFDC3.5030803@codeaurora.org>

Hi Catalin,

On 03/19/2013 01:38 PM, Catalin Marinas wrote:
> This patch prepares the removal of <asm/mach/irq.h> include in the
> GIC and VIC irqchip drivers.

[...]

> diff --git a/drivers/irqchip/irq-vic.c b/drivers/irqchip/irq-vic.c
> index 3cf97aa..e38cb00 100644
> --- a/drivers/irqchip/irq-vic.c
> +++ b/drivers/irqchip/irq-vic.c
> @@ -33,7 +33,7 @@
>  #include <linux/irqchip/arm-vic.h>
>  
>  #include <asm/exception.h>
> -#include <asm/mach/irq.h>
> +#include <asm/irq.h>
>  
>  #include "irqchip.h"

I'm seeing implicit declaration of function issues using your soc-armv8-model
branch that seem to be caused by this change.

drivers/irqchip/irq-vic.c: In function ?vic_irqdomain_map?:
drivers/irqchip/irq-vic.c:200:2: error: implicit declaration of function
?irq_set_chip_and_handler? [-Werror=implicit-function-declaration]
drivers/irqchip/irq-vic.c:200:43: error: ?handle_level_irq? undeclared (first
use in this function)

etc.

Explicitly including linux/irq.h fixed the issue for me.

Regards,
Christopher

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by the Linux Foundation.


From sebastian.hesselbarth at gmail.com  Tue Apr 30 13:24:35 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Tue, 30 Apr 2013 19:24:35 +0200
Subject: [PATCH] ARM: dove: add si5351 clock driver to CuBox DT
Message-ID: <1367342675-15312-1-git-send-email-sebastian.hesselbarth@gmail.com>

This patch adds the device tree node for si5351 clock generator
and the corresponding oscillator connected to it. It also limits
i2c frequency to 100kHz as there are bus locks reported on higher
frequencies.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
---
Cc: Russell King <linux at arm.linux.org.uk>
Cc: Jason Cooper <jason at lakedaemon.net>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
---
 arch/arm/boot/dts/dove-cubox.dts |   51 +++++++++++++++++++++++++++++++++++++-
 1 files changed, 50 insertions(+), 1 deletions(-)

diff --git a/arch/arm/boot/dts/dove-cubox.dts b/arch/arm/boot/dts/dove-cubox.dts
index 7e3065a..5cae2ab 100644
--- a/arch/arm/boot/dts/dove-cubox.dts
+++ b/arch/arm/boot/dts/dove-cubox.dts
@@ -44,11 +44,60 @@
 			gpio = <&gpio0 1 0>;
 		};
 	};
+
+	clocks {
+		/* 25MHz reference crystal */
+		ref25: oscillator {
+			compatible = "fixed-clock";
+			#clock-cells = <0>;
+			clock-frequency = <25000000>;
+		};
+	};
 };
 
 &uart0 { status = "okay"; };
 &sata0 { status = "okay"; };
-&i2c0 { status = "okay"; };
+
+&i2c0 {
+	status = "okay";
+	clock-frequency = <100000>;
+
+	si5351: clock-generator {
+		compatible = "silabs,si5351a-msop";
+		reg = <0x60>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		#clock-cells = <1>;
+
+		/* connect xtal input to 25MHz reference */
+		clocks = <&ref25>;
+
+		/* connect xtal input as source of pll0 and pll1 */
+		silabs,pll-source = <0 0>, <1 0>;
+
+		clkout0 {
+			reg = <0>;
+			silabs,drive-strength = <8>;
+			silabs,multisynth-source = <0>;
+			silabs,clock-source = <0>;
+			silabs,pll-master;
+		};
+
+		clkout1 {
+			reg = <1>;
+			silabs,drive-strength = <8>;
+			silabs,multisynth-source = <1>;
+			silabs,clock-source = <0>;
+			silabs,pll-master;
+		};
+
+		clkout2 {
+			reg = <2>;
+			silabs,multisynth-source = <1>;
+			silabs,clock-source = <0>;
+		};
+	};
+};
 
 &sdio0 {
 	status = "okay";
-- 
1.7.2.5



From dave.martin at linaro.org  Tue Apr 30 13:28:50 2013
From: dave.martin at linaro.org (Dave Martin)
Date: Tue, 30 Apr 2013 18:28:50 +0100
Subject: Latest build results - errors/warnings - lots of them
In-Reply-To: <alpine.LFD.2.03.1304301110030.17372@syhkavp.arg>
References: <20130430081739.GP14496@n2100.arm.linux.org.uk>
 <201304301304.20650.arnd@arndb.de>
 <20130430114229.GA2439@linaro.org>
 <alpine.LFD.2.03.1304301110030.17372@syhkavp.arg>
Message-ID: <20130430172816.GA31101@linaro.org>

On Tue, Apr 30, 2013 at 11:12:12AM -0400, Nicolas Pitre wrote:
> On Tue, 30 Apr 2013, Dave Martin wrote:
> 
> > On Tue, Apr 30, 2013 at 01:04:20PM +0200, Arnd Bergmann wrote:
> > > On Tuesday 30 April 2013, Russell King - ARM Linux wrote:
> > > > Latest nightly build of 3.9+my for-next+arm-soc's for-next results in a
> > > > great load of new warnings and errors.  arch/arm/common/mcpm_head.S,
> > > > arch/arm/common/mcpm_platsmp.c, arch/arm/common/vlock.S are the biggest
> > > > source of errors.
> > 
> > [...]
> >  
> > > >arch/arm/common/mcpm_head.S:39: Error: selected processor does not support ARM mode `ubfx r9,r0,#0,#8'
> > > >arch/arm/common/mcpm_head.S:40: Error: selected processor does not support ARM mode `ubfx r10,r0,#8,#8'
> > > >arch/arm/common/mcpm_head.S:100: Error: selected processor does not support ARM mode `dmb'
> > > >arch/arm/common/mcpm_head.S:115: Error: selected processor does not support ARM mode `dmb'
> > > >arch/arm/common/mcpm_head.S:127: Error: selected processor does not support ARM mode `dmb'
> > > >arch/arm/common/mcpm_head.S:131: Error: selected processor does not support ARM mode `dmb'
> > > >arch/arm/common/mcpm_head.S:138: Error: selected processor does not support ARM mode `dsb'
> > > >arch/arm/common/mcpm_head.S:152: Error: selected processor does not support ARM mode `dmb'
> > > >arch/arm/common/mcpm_head.S:161: Error: selected processor does not support ARM mode `dmb'
> > > >arch/arm/common/mcpm_head.S:175: Error: selected processor does not support ARM mode `dmb'
> > > >arch/arm/common/vlock.S:62: Error: selected processor does not support ARM mode `dmb'
> > > >arch/arm/common/vlock.S:72: Error: selected processor does not support ARM mode `dmb'
> > > >arch/arm/common/vlock.S:72: Error: selected processor does not support ARM mode `dsb'
> > > >arch/arm/common/vlock.S:89: Error: selected processor does not support ARM mode `dmb'
> > > >arch/arm/common/vlock.S:95: Error: selected processor does not support ARM mode `dmb'
> > > >arch/arm/common/vlock.S:95: Error: selected processor does not support ARM mode `dsb'
> > > >arch/arm/common/vlock.S:102: Error: selected processor does not support ARM mode `dmb'
> > > >arch/arm/common/vlock.S:105: Error: selected processor does not support ARM mode `dsb'
> > > 
> > > Right, the problem here is that the code was never tested with an ARMv6+ARMv7 config.
> > > We can either fix it up by adding
> > > 
> > > 	.arch	armv7-a
> > > 
> > > in the assembly files, or by doing the same in the Makefile:
> > > 
> > > AFLAGS_vlock.S += -march=armv7-a
> > > AFLAGS_mcpm_head.S += -march=armv7-a
> > 
> > 
> > Hmmm, this code was tested with ARCH_MULTIPLATFORM, but it looks like
> > no v6 boards were configured in when testing that...
> > 
> > 
> > Assuming people are OK with the Makefile route, here's a patch for that,
> > build-tested with a v6+v7 ARCH_MULTIPLATFORM config.
> 
> Isn't the .arch armv7-a route a bit cleaner?  That would have been my 
> choice, although I don't feel strongly about it.

I don't feel strongly either.  We already have the CFLAGS_DISABLE stuff,
so it didn't feel that unnatural to add this in the Makefile; but .arch
would work equally well.

If somebody wants to change it, it's not a problem for me, but I didn't
want to create extra disruption by proposing a different patch...

Cheers
---Dave


From cdall at cs.columbia.edu  Tue Apr 30 13:40:59 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Tue, 30 Apr 2013 10:40:59 -0700
Subject: [PATCH 4/4] ARM: KVM: fix use of S2_PGD_SIZE
In-Reply-To: <1367331446-28030-5-git-send-email-marc.zyngier@arm.com>
References: <1367331446-28030-1-git-send-email-marc.zyngier@arm.com>
 <1367331446-28030-5-git-send-email-marc.zyngier@arm.com>
Message-ID: <CAEDV+gK5ifY0atTZqku=Y4J=1pfWY4XAz-ayXJ61Sf7MtjOG4A@mail.gmail.com>

On Tue, Apr 30, 2013 at 7:17 AM, Marc Zyngier <marc.zyngier at arm.com> wrote:
> S2_PGD_SIZE describe the number of pages a used by a stage-2 PGD,
> not the size of the PGD.
>
> Fix the VM_BUG_ON() call that doesn't check much when S2_PGD_SIZE
> is equal to 1.
>
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> ---
>  arch/arm/kvm/mmu.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
> index b978ebe..09ece5c 100644
> --- a/arch/arm/kvm/mmu.c
> +++ b/arch/arm/kvm/mmu.c
> @@ -377,7 +377,7 @@ int kvm_alloc_stage2_pgd(struct kvm *kvm)
>                 return -ENOMEM;
>
>         /* stage-2 pgd must be aligned to its size */
> -       VM_BUG_ON((unsigned long)pgd & (S2_PGD_SIZE - 1));
> +       VM_BUG_ON((unsigned long)pgd & (PAGE_SIZE * S2_PGD_SIZE - 1));

I think the define is broken and should be fixed and/or renamed instead.

>
>         memset(pgd, 0, PTRS_PER_S2_PGD * sizeof(pgd_t));
>         kvm_clean_pgd(pgd);
> --
> 1.8.2.1
>
>
>
> _______________________________________________
> kvmarm mailing list
> kvmarm at lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm


From cdall at cs.columbia.edu  Tue Apr 30 13:48:45 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Tue, 30 Apr 2013 10:48:45 -0700
Subject: [PATCH V3] ARM: KVM: Allow host virt timer irq to be different
 from guest timer virt irq
In-Reply-To: <1367303535-7982-1-git-send-email-anup.patel@linaro.org>
References: <1367303535-7982-1-git-send-email-anup.patel@linaro.org>
Message-ID: <CAEDV+gLs5TxWnXbsxmHz+k5HMS8q2S3odaBO-BsZx0W95wSPww@mail.gmail.com>

On Mon, Apr 29, 2013 at 11:32 PM, Anup Patel <anup.patel at linaro.org> wrote:
> The arch_timer irq numbers (or PPI numbers) are implementation dependent,
> so the host virtual timer irq number can be different from guest virtual
> timer irq number.
>
> This patch ensures that host virtual timer irq number is read from DTB and
> guest virtual timer irq is determined based on vcpu target type.
>
> Signed-off-by: Anup Patel <anup.patel at linaro.org>
> Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar at linaro.org>
> ---
>  arch/arm/include/asm/kvm_arch_timer.h |    4 ++++
>  arch/arm/kvm/arch_timer.c             |   29 ++++++++++++++++++++---------
>  arch/arm/kvm/reset.c                  |   11 +++++++++++
>  3 files changed, 35 insertions(+), 9 deletions(-)
>
> diff --git a/arch/arm/include/asm/kvm_arch_timer.h b/arch/arm/include/asm/kvm_arch_timer.h
> index 68cb9e1..eeb2a3f 100644
> --- a/arch/arm/include/asm/kvm_arch_timer.h
> +++ b/arch/arm/include/asm/kvm_arch_timer.h
> @@ -61,6 +61,8 @@ struct arch_timer_cpu {
>  #ifdef CONFIG_KVM_ARM_TIMER
>  int kvm_timer_hyp_init(void);
>  int kvm_timer_init(struct kvm *kvm);
> +void kvm_timer_vcpu_reset(struct kvm_vcpu *vcpu,
> +                         const struct kvm_irq_level *irq);
>  void kvm_timer_vcpu_init(struct kvm_vcpu *vcpu);
>  void kvm_timer_flush_hwstate(struct kvm_vcpu *vcpu);
>  void kvm_timer_sync_hwstate(struct kvm_vcpu *vcpu);
> @@ -76,6 +78,8 @@ static inline int kvm_timer_init(struct kvm *kvm)
>         return 0;
>  }
>
> +static inline void kvm_timer_vcpu_reset(struct kvm_vcpu *vcpu,
> +                                       const struct kvm_irq_level *irq) {}
>  static inline void kvm_timer_vcpu_init(struct kvm_vcpu *vcpu) {}
>  static inline void kvm_timer_flush_hwstate(struct kvm_vcpu *vcpu) {}
>  static inline void kvm_timer_sync_hwstate(struct kvm_vcpu *vcpu) {}
> diff --git a/arch/arm/kvm/arch_timer.c b/arch/arm/kvm/arch_timer.c
> index 49a7516..5826437 100644
> --- a/arch/arm/kvm/arch_timer.c
> +++ b/arch/arm/kvm/arch_timer.c
> @@ -30,9 +30,7 @@
>
>  static struct timecounter *timecounter;
>  static struct workqueue_struct *wqueue;
> -static struct kvm_irq_level timer_irq = {
> -       .level  = 1,
> -};
> +static unsigned int host_vtimer_irq;
>
>  static cycle_t kvm_phys_timer_read(void)
>  {
> @@ -67,8 +65,8 @@ static void kvm_timer_inject_irq(struct kvm_vcpu *vcpu)
>
>         timer->cntv_ctl |= ARCH_TIMER_CTRL_IT_MASK;
>         kvm_vgic_inject_irq(vcpu->kvm, vcpu->vcpu_id,
> -                           vcpu->arch.timer_cpu.irq->irq,
> -                           vcpu->arch.timer_cpu.irq->level);
> +                           timer->irq->irq,
> +                           timer->irq->level);
>  }
>
>  static irqreturn_t kvm_arch_timer_handler(int irq, void *dev_id)
> @@ -156,6 +154,20 @@ void kvm_timer_sync_hwstate(struct kvm_vcpu *vcpu)
>         timer_arm(timer, ns);
>  }
>
> +void kvm_timer_vcpu_reset(struct kvm_vcpu *vcpu,
> +                         const struct kvm_irq_level *irq)
> +{
> +       struct arch_timer_cpu *timer = &vcpu->arch.timer_cpu;
> +
> +       /*
> +        * The vcpu timer irq number cannot be determined in
> +        * kvm_timer_vcpu_init() because it is called much before
> +        * kvm_vcpu_set_target(). To handle this, we determine
> +        * vcpu timer irq number when the vcpu is reset.
> +        */
> +       timer->irq = irq;
> +}
> +
>  void kvm_timer_vcpu_init(struct kvm_vcpu *vcpu)
>  {
>         struct arch_timer_cpu *timer = &vcpu->arch.timer_cpu;
> @@ -163,12 +175,11 @@ void kvm_timer_vcpu_init(struct kvm_vcpu *vcpu)
>         INIT_WORK(&timer->expired, kvm_timer_inject_irq_work);
>         hrtimer_init(&timer->timer, CLOCK_MONOTONIC, HRTIMER_MODE_ABS);
>         timer->timer.function = kvm_timer_expire;
> -       timer->irq = &timer_irq;
>  }
>
>  static void kvm_timer_init_interrupt(void *info)
>  {
> -       enable_percpu_irq(timer_irq.irq, 0);
> +       enable_percpu_irq(host_vtimer_irq, 0);
>  }
>
>
> @@ -182,7 +193,7 @@ static int kvm_timer_cpu_notify(struct notifier_block *self,
>                 break;
>         case CPU_DYING:
>         case CPU_DYING_FROZEN:
> -               disable_percpu_irq(timer_irq.irq);
> +               disable_percpu_irq(host_vtimer_irq);
>                 break;
>         }
>
> @@ -230,7 +241,7 @@ int kvm_timer_hyp_init(void)
>                 goto out;
>         }
>
> -       timer_irq.irq = ppi;
> +       host_vtimer_irq = ppi;
>
>         err = register_cpu_notifier(&kvm_timer_cpu_nb);
>         if (err) {
> diff --git a/arch/arm/kvm/reset.c b/arch/arm/kvm/reset.c
> index b80256b..0b49ad7 100644
> --- a/arch/arm/kvm/reset.c
> +++ b/arch/arm/kvm/reset.c
> @@ -26,6 +26,7 @@
>  #include <asm/cputype.h>
>  #include <asm/kvm_arm.h>
>  #include <asm/kvm_coproc.h>
> +#include <asm/kvm_arch_timer.h>
>
>  /******************************************************************************
>   * Cortex-A15 Reset Values
> @@ -37,6 +38,11 @@ static struct kvm_regs a15_regs_reset = {
>         .usr_regs.ARM_cpsr = SVC_MODE | PSR_A_BIT | PSR_I_BIT | PSR_F_BIT,
>  };
>
> +static const struct kvm_irq_level a15_vtimer_irq = {
> +       .irq = 27,
> +       .level = 1,
> +};
> +
>
>  /*******************************************************************************
>   * Exported reset function
> @@ -52,6 +58,7 @@ static struct kvm_regs a15_regs_reset = {
>  int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
>  {
>         struct kvm_regs *cpu_reset;
> +       const struct kvm_irq_level *cpu_vtimer_irq;
>
>         switch (vcpu->arch.target) {
>         case KVM_ARM_TARGET_CORTEX_A15:
> @@ -59,6 +66,7 @@ int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
>                         return -EINVAL;
>                 cpu_reset = &a15_regs_reset;
>                 vcpu->arch.midr = read_cpuid_id();
> +               cpu_vtimer_irq = &a15_vtimer_irq;
>                 break;
>         default:
>                 return -ENODEV;
> @@ -70,5 +78,8 @@ int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
>         /* Reset CP15 registers */
>         kvm_reset_coprocs(vcpu);
>
> +       /* Reset arch_timer context */
> +       kvm_timer_vcpu_reset(vcpu, cpu_vtimer_irq);
> +
>         return 0;
>  }
> --
> 1.7.9.5
>
applied (minus the trailing white space - please adjust your editor or
run checkpatch), thanks

-Christoffer


From marc.zyngier at arm.com  Tue Apr 30 13:52:24 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Tue, 30 Apr 2013 18:52:24 +0100
Subject: [PATCH 4/4] ARM: KVM: fix use of S2_PGD_SIZE
In-Reply-To: <CAEDV+gK5ifY0atTZqku=Y4J=1pfWY4XAz-ayXJ61Sf7MtjOG4A@mail.gmail.com>
References: <1367331446-28030-1-git-send-email-marc.zyngier@arm.com>
 <1367331446-28030-5-git-send-email-marc.zyngier@arm.com>
 <CAEDV+gK5ifY0atTZqku=Y4J=1pfWY4XAz-ayXJ61Sf7MtjOG4A@mail.gmail.com>
Message-ID: <518004D8.80801@arm.com>

On 30/04/13 18:40, Christoffer Dall wrote:
> On Tue, Apr 30, 2013 at 7:17 AM, Marc Zyngier <marc.zyngier at arm.com> wrote:
>> S2_PGD_SIZE describe the number of pages a used by a stage-2 PGD,
>> not the size of the PGD.
>>
>> Fix the VM_BUG_ON() call that doesn't check much when S2_PGD_SIZE
>> is equal to 1.
>>
>> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
>> ---
>>  arch/arm/kvm/mmu.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
>> index b978ebe..09ece5c 100644
>> --- a/arch/arm/kvm/mmu.c
>> +++ b/arch/arm/kvm/mmu.c
>> @@ -377,7 +377,7 @@ int kvm_alloc_stage2_pgd(struct kvm *kvm)
>>                 return -ENOMEM;
>>
>>         /* stage-2 pgd must be aligned to its size */
>> -       VM_BUG_ON((unsigned long)pgd & (S2_PGD_SIZE - 1));
>> +       VM_BUG_ON((unsigned long)pgd & (PAGE_SIZE * S2_PGD_SIZE - 1));
> 
> I think the define is broken and should be fixed and/or renamed instead.

To be fair, I wouldn't mind the whole check to be dropped altogether. If
__get_free_pages doesn't give you an aligned allocation, the whole
kernel is going the way of the dodo, and we shouldn't really care...

Your call, really.

	M.
-- 
Jazz is not dead. It just smells funny...



From cdall at cs.columbia.edu  Tue Apr 30 13:56:39 2013
From: cdall at cs.columbia.edu (Christoffer Dall)
Date: Tue, 30 Apr 2013 10:56:39 -0700
Subject: [PATCH 4/4] ARM: KVM: fix use of S2_PGD_SIZE
In-Reply-To: <518004D8.80801@arm.com>
References: <1367331446-28030-1-git-send-email-marc.zyngier@arm.com>
 <1367331446-28030-5-git-send-email-marc.zyngier@arm.com>
 <CAEDV+gK5ifY0atTZqku=Y4J=1pfWY4XAz-ayXJ61Sf7MtjOG4A@mail.gmail.com>
 <518004D8.80801@arm.com>
Message-ID: <20130430175639.GA6266@gmail.com>

On Tue, Apr 30, 2013 at 06:52:24PM +0100, Marc Zyngier wrote:
> On 30/04/13 18:40, Christoffer Dall wrote:
> > On Tue, Apr 30, 2013 at 7:17 AM, Marc Zyngier <marc.zyngier at arm.com> wrote:
> >> S2_PGD_SIZE describe the number of pages a used by a stage-2 PGD,
> >> not the size of the PGD.
> >>
> >> Fix the VM_BUG_ON() call that doesn't check much when S2_PGD_SIZE
> >> is equal to 1.
> >>
> >> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> >> ---
> >>  arch/arm/kvm/mmu.c | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
> >> index b978ebe..09ece5c 100644
> >> --- a/arch/arm/kvm/mmu.c
> >> +++ b/arch/arm/kvm/mmu.c
> >> @@ -377,7 +377,7 @@ int kvm_alloc_stage2_pgd(struct kvm *kvm)
> >>                 return -ENOMEM;
> >>
> >>         /* stage-2 pgd must be aligned to its size */
> >> -       VM_BUG_ON((unsigned long)pgd & (S2_PGD_SIZE - 1));
> >> +       VM_BUG_ON((unsigned long)pgd & (PAGE_SIZE * S2_PGD_SIZE - 1));
> > 
> > I think the define is broken and should be fixed and/or renamed instead.
> 
> To be fair, I wouldn't mind the whole check to be dropped altogether. If
> __get_free_pages doesn't give you an aligned allocation, the whole
> kernel is going the way of the dodo, and we shouldn't really care...
> 
> Your call, really.
> 
Yeah, this is from way back when, where the whole thing was different
and we were debugging all sorts of issues, so we can get rid of both the
check and the define in stead.  Want to take care of it as part of your
series?

Thanks,
-Christoffer


From marc.zyngier at arm.com  Tue Apr 30 13:59:50 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Tue, 30 Apr 2013 18:59:50 +0100
Subject: [PATCH 4/4] ARM: KVM: fix use of S2_PGD_SIZE
In-Reply-To: <20130430175639.GA6266@gmail.com>
References: <1367331446-28030-1-git-send-email-marc.zyngier@arm.com>
 <1367331446-28030-5-git-send-email-marc.zyngier@arm.com>
 <CAEDV+gK5ifY0atTZqku=Y4J=1pfWY4XAz-ayXJ61Sf7MtjOG4A@mail.gmail.com>
 <518004D8.80801@arm.com> <20130430175639.GA6266@gmail.com>
Message-ID: <51800696.9060105@arm.com>

On 30/04/13 18:56, Christoffer Dall wrote:
> On Tue, Apr 30, 2013 at 06:52:24PM +0100, Marc Zyngier wrote:
>> On 30/04/13 18:40, Christoffer Dall wrote:
>>> On Tue, Apr 30, 2013 at 7:17 AM, Marc Zyngier <marc.zyngier at arm.com> wrote:
>>>> S2_PGD_SIZE describe the number of pages a used by a stage-2 PGD,
>>>> not the size of the PGD.
>>>>
>>>> Fix the VM_BUG_ON() call that doesn't check much when S2_PGD_SIZE
>>>> is equal to 1.
>>>>
>>>> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
>>>> ---
>>>>  arch/arm/kvm/mmu.c | 2 +-
>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
>>>> index b978ebe..09ece5c 100644
>>>> --- a/arch/arm/kvm/mmu.c
>>>> +++ b/arch/arm/kvm/mmu.c
>>>> @@ -377,7 +377,7 @@ int kvm_alloc_stage2_pgd(struct kvm *kvm)
>>>>                 return -ENOMEM;
>>>>
>>>>         /* stage-2 pgd must be aligned to its size */
>>>> -       VM_BUG_ON((unsigned long)pgd & (S2_PGD_SIZE - 1));
>>>> +       VM_BUG_ON((unsigned long)pgd & (PAGE_SIZE * S2_PGD_SIZE - 1));
>>>
>>> I think the define is broken and should be fixed and/or renamed instead.
>>
>> To be fair, I wouldn't mind the whole check to be dropped altogether. If
>> __get_free_pages doesn't give you an aligned allocation, the whole
>> kernel is going the way of the dodo, and we shouldn't really care...
>>
>> Your call, really.
>>
> Yeah, this is from way back when, where the whole thing was different
> and we were debugging all sorts of issues, so we can get rid of both the
> check and the define in stead.  Want to take care of it as part of your
> series?

Sure. I'll kill it when I repost the series.

	M.
-- 
Jazz is not dead. It just smells funny...



From marc.zyngier at arm.com  Tue Apr 30 14:02:16 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Tue, 30 Apr 2013 19:02:16 +0100
Subject: [PATCH 1/4] ARM: KVM: be more thorough when invalidating TLBs
In-Reply-To: <CAEDV+g+LKEj_XdeLvMwxJhVQ9FG9=U6eqO7dPU340xX2oMkS0A@mail.gmail.com>
References: <1367331446-28030-1-git-send-email-marc.zyngier@arm.com>
 <1367331446-28030-2-git-send-email-marc.zyngier@arm.com>
 <CAEDV+g+LKEj_XdeLvMwxJhVQ9FG9=U6eqO7dPU340xX2oMkS0A@mail.gmail.com>
Message-ID: <51800728.9050306@arm.com>

On 30/04/13 18:17, Christoffer Dall wrote:
> On Tue, Apr 30, 2013 at 7:17 AM, Marc Zyngier <marc.zyngier at arm.com> wrote:
>> The KVM/ARM MMU code doesn't take care of invalidating TLBs before
>> freeing a {pte,pmd} table. This could cause problems if the page
>> is reallocated and then speculated into by another CPU.
>>
>> Reported-by: Catalin Marinas <catalin.marinas at arm.com>
>> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
>> ---
>>  arch/arm/kvm/interrupts.S |  2 ++
>>  arch/arm/kvm/mmu.c        | 36 +++++++++++++++++++++---------------
>>  2 files changed, 23 insertions(+), 15 deletions(-)
>>
>> diff --git a/arch/arm/kvm/interrupts.S b/arch/arm/kvm/interrupts.S
>> index f7793df..9e2d906c 100644
>> --- a/arch/arm/kvm/interrupts.S
>> +++ b/arch/arm/kvm/interrupts.S
>> @@ -37,6 +37,8 @@ __kvm_hyp_code_start:
>>   *
>>   * void __kvm_tlb_flush_vmid_ipa(struct kvm *kvm, phys_addr_t ipa);
>>   *
>> + * Invalidate TLB for the given IPA, or invalidate all if ipa is zero.
>> + *
>>   * We rely on the hardware to broadcast the TLB invalidation to all CPUs
>>   * inside the inner-shareable domain (which is the case for all v7
>>   * implementations).  If we come across a non-IS SMP implementation, we'll
>> diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
>> index 9657065..71f2a57 100644
>> --- a/arch/arm/kvm/mmu.c
>> +++ b/arch/arm/kvm/mmu.c
>> @@ -43,7 +43,8 @@ static phys_addr_t hyp_idmap_vector;
>>
>>  static void kvm_tlb_flush_vmid_ipa(struct kvm *kvm, phys_addr_t ipa)
>>  {
>> -       kvm_call_hyp(__kvm_tlb_flush_vmid_ipa, kvm, ipa);
>> +       if (kvm)
>> +               kvm_call_hyp(__kvm_tlb_flush_vmid_ipa, kvm, ipa);
> 
> this feels slightly abusive? could we add a comment that hyp page
> table freeing don't need tlb flushing from these functions and don't
> have a struct kvm?
> 
> alternatively it may be more clear to have something like:
> 
> if (kvm) /* Check if Hyp or Stage-2 page table */
>     kvm_tlb_flush_vmid_ipa(kvm, addr);
> 
> in the callers, but, eh, maybe I'm over thinking this.

That code would be repeated three times, which feels a bit overkill.
I'll add a comment to the function so it is crystal clear.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...



From broonie at kernel.org  Tue Apr 30 09:27:55 2013
From: broonie at kernel.org (Mark Brown)
Date: Tue, 30 Apr 2013 14:27:55 +0100
Subject: [alsa-devel] [PATCH] MAINTAINERS: Add linux-samsung-soc list to
 all related entries
In-Reply-To: <CAH9JG2U7Qdq_xQbuqHu6PXzURS2fWwBC=HJmyrXT5n3n_pAa0w@mail.gmail.com>
References: <1366572050-626-1-git-send-email-tomasz.figa@gmail.com>
 <CAH9JG2U7Qdq_xQbuqHu6PXzURS2fWwBC=HJmyrXT5n3n_pAa0w@mail.gmail.com>
Message-ID: <20130430132755.GB1023@sirena.org.uk>

On Mon, Apr 22, 2013 at 03:23:29PM +0900, Kyungmin Park wrote:

> I don't think it's not required, each tree has each own mailing list. don't
> need to post all patches to samsung-soc list.

It can be useful to get system level input on some stuff, I guess it
mostly depends if the people on the generic list mind the extra traffic
or if they find it useful.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130430/a80c3d75/attachment.sig>

From nicolas.pitre at linaro.org  Tue Apr 30 14:18:42 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Tue, 30 Apr 2013 14:18:42 -0400 (EDT)
Subject: Latest build results - errors/warnings - lots of them
In-Reply-To: <20130430172816.GA31101@linaro.org>
References: <20130430081739.GP14496@n2100.arm.linux.org.uk>
 <201304301304.20650.arnd@arndb.de> <20130430114229.GA2439@linaro.org>
 <alpine.LFD.2.03.1304301110030.17372@syhkavp.arg>
 <20130430172816.GA31101@linaro.org>
Message-ID: <alpine.LFD.2.03.1304301418100.17372@syhkavp.arg>

On Tue, 30 Apr 2013, Dave Martin wrote:

> On Tue, Apr 30, 2013 at 11:12:12AM -0400, Nicolas Pitre wrote:
> > On Tue, 30 Apr 2013, Dave Martin wrote:
> > 
> > > On Tue, Apr 30, 2013 at 01:04:20PM +0200, Arnd Bergmann wrote:
> > > > On Tuesday 30 April 2013, Russell King - ARM Linux wrote:
> > > > > Latest nightly build of 3.9+my for-next+arm-soc's for-next results in a
> > > > > great load of new warnings and errors.  arch/arm/common/mcpm_head.S,
> > > > > arch/arm/common/mcpm_platsmp.c, arch/arm/common/vlock.S are the biggest
> > > > > source of errors.
> > > 
> > > [...]
> > >  
> > > > >arch/arm/common/mcpm_head.S:39: Error: selected processor does not support ARM mode `ubfx r9,r0,#0,#8'
> > > > >arch/arm/common/mcpm_head.S:40: Error: selected processor does not support ARM mode `ubfx r10,r0,#8,#8'
> > > > >arch/arm/common/mcpm_head.S:100: Error: selected processor does not support ARM mode `dmb'
> > > > >arch/arm/common/mcpm_head.S:115: Error: selected processor does not support ARM mode `dmb'
> > > > >arch/arm/common/mcpm_head.S:127: Error: selected processor does not support ARM mode `dmb'
> > > > >arch/arm/common/mcpm_head.S:131: Error: selected processor does not support ARM mode `dmb'
> > > > >arch/arm/common/mcpm_head.S:138: Error: selected processor does not support ARM mode `dsb'
> > > > >arch/arm/common/mcpm_head.S:152: Error: selected processor does not support ARM mode `dmb'
> > > > >arch/arm/common/mcpm_head.S:161: Error: selected processor does not support ARM mode `dmb'
> > > > >arch/arm/common/mcpm_head.S:175: Error: selected processor does not support ARM mode `dmb'
> > > > >arch/arm/common/vlock.S:62: Error: selected processor does not support ARM mode `dmb'
> > > > >arch/arm/common/vlock.S:72: Error: selected processor does not support ARM mode `dmb'
> > > > >arch/arm/common/vlock.S:72: Error: selected processor does not support ARM mode `dsb'
> > > > >arch/arm/common/vlock.S:89: Error: selected processor does not support ARM mode `dmb'
> > > > >arch/arm/common/vlock.S:95: Error: selected processor does not support ARM mode `dmb'
> > > > >arch/arm/common/vlock.S:95: Error: selected processor does not support ARM mode `dsb'
> > > > >arch/arm/common/vlock.S:102: Error: selected processor does not support ARM mode `dmb'
> > > > >arch/arm/common/vlock.S:105: Error: selected processor does not support ARM mode `dsb'
> > > > 
> > > > Right, the problem here is that the code was never tested with an ARMv6+ARMv7 config.
> > > > We can either fix it up by adding
> > > > 
> > > > 	.arch	armv7-a
> > > > 
> > > > in the assembly files, or by doing the same in the Makefile:
> > > > 
> > > > AFLAGS_vlock.S += -march=armv7-a
> > > > AFLAGS_mcpm_head.S += -march=armv7-a
> > > 
> > > 
> > > Hmmm, this code was tested with ARCH_MULTIPLATFORM, but it looks like
> > > no v6 boards were configured in when testing that...
> > > 
> > > 
> > > Assuming people are OK with the Makefile route, here's a patch for that,
> > > build-tested with a v6+v7 ARCH_MULTIPLATFORM config.
> > 
> > Isn't the .arch armv7-a route a bit cleaner?  That would have been my 
> > choice, although I don't feel strongly about it.
> 
> I don't feel strongly either.  We already have the CFLAGS_DISABLE stuff,
> so it didn't feel that unnatural to add this in the Makefile; but .arch
> would work equally well.
> 
> If somebody wants to change it, it's not a problem for me, but I didn't
> want to create extra disruption by proposing a different patch...

Fair enough.

Acked-by: Nicolas Pitre <nico at linaro.org>



> 
> Cheers
> ---Dave
> 


From csd at broadcom.com  Tue Apr 30 14:38:09 2013
From: csd at broadcom.com (Christian Daudt)
Date: Tue, 30 Apr 2013 11:38:09 -0700
Subject: [PATCH] ARM: bcm281xx: Add L2 support for Rev A2 chips
Message-ID: <1367347089-23788-1-git-send-email-csd@broadcom.com>

Rev A2 SoCs have an unorthodox memory re-mapping and this needs
to be reflected in the cache operations.
This patch adds new outer cache functions for the l2x0 driver
to support this SoC revision. It also adds a new compatible
value for the cache to enable this functionality.

Signed-off-by: Christian Daudt <csd at broadcom.com>

diff --git a/Documentation/devicetree/bindings/arm/l2cc.txt b/Documentation/devicetree/bindings/arm/l2cc.txt
index cbef09b..69ddf9f 100644
--- a/Documentation/devicetree/bindings/arm/l2cc.txt
+++ b/Documentation/devicetree/bindings/arm/l2cc.txt
@@ -16,6 +16,9 @@ Required properties:
      performs the same operation).
 	"marvell,"aurora-outer-cache: Marvell Controller designed to be
 	 compatible with the ARM one with outer cache mode.
+	"bcm,bcm11351-a2-pl310-cache": For Broadcom bcm11351 chipset where an
+	offset needs to be added to the address before passing down to the L2
+	cache controller
 - cache-unified : Specifies the cache is a unified cache.
 - cache-level : Should be set to 2 for a level 2 cache.
 - reg : Physical base address and size of cache controller's memory mapped
diff --git a/arch/arm/boot/dts/bcm11351.dtsi b/arch/arm/boot/dts/bcm11351.dtsi
index 41b2c6c..5e48c85 100644
--- a/arch/arm/boot/dts/bcm11351.dtsi
+++ b/arch/arm/boot/dts/bcm11351.dtsi
@@ -47,10 +47,10 @@
 	};
 
 	L2: l2-cache {
-		    compatible = "arm,pl310-cache";
-		    reg = <0x3ff20000 0x1000>;
-		    cache-unified;
-		    cache-level = <2>;
+		compatible = "bcm,bcm11351-a2-pl310-cache";
+		reg = <0x3ff20000 0x1000>;
+		cache-unified;
+		cache-level = <2>;
 	};
 
 	timer at 35006000 {
diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index c465fac..6edba13 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -523,6 +523,162 @@ static void aurora_flush_range(unsigned long start, unsigned long end)
 	}
 }
 
+/*
+ * For certain Broadcom SoCs, depending on the address range, different offsets
+ * need to be added to the address before passing it to L2 for
+ * invalidation/clean/flush
+ *
+ * Section Address Range              Offset        EMI
+ *   1     0x00000000 - 0x3FFFFFFF    0x80000000    VC
+ *   2     0x40000000 - 0xBFFFFFFF    0x40000000    SYS
+ *   3     0xC0000000 - 0xFFFFFFFF    0x80000000    VC
+ *
+ * When the start and end addresses have crossed two different sections, we
+ * need to break the L2 operation into two, each within its own section.
+ * For example, if we need to invalidate addresses starts at 0xBFFF0000 and
+ * ends at 0xC0001000, we need do invalidate 1) 0xBFFF0000 - 0xBFFFFFFF and 2)
+ * 0xC0000000 - 0xC0001000
+ *
+ * Note 1:
+ * By breaking a single L2 operation into two, we may potentially suffer some
+ * performance hit, but keep in mind the cross section case is very rare
+ *
+ * Note 2:
+ * We do not need to handle the case when the start address is in
+ * Section 1 and the end address is in Section 3, since it is not a valid use
+ * case
+ */
+
+#define BCM_VC_EMI_SEC1_START_ADDR    0x00000000UL
+#define BCM_VC_EMI_SEC1_END_ADDR      0x3FFFFFFFUL
+#define BCM_SYS_EMI_START_ADDR        0x40000000UL
+#define BCM_SYS_EMI_END_ADDR          0xBFFFFFFFUL
+#define BCM_VC_EMI_SEC3_START_ADDR    0xC0000000UL
+#define BCM_VC_EMI_SEC3_END_ADDR      0xFFFFFFFFUL
+
+#define BCM_SYS_EMI_OFFSET            0x40000000UL
+#define BCM_VC_EMI_OFFSET             0x80000000UL
+
+static inline int bcm_addr_is_sys_emi(unsigned long addr)
+{
+	return (addr >= BCM_SYS_EMI_START_ADDR) &&
+		(addr <= BCM_SYS_EMI_END_ADDR);
+}
+
+static inline unsigned long bcm_l2_phys_addr(unsigned long addr)
+{
+	if (bcm_addr_is_sys_emi(addr))
+		return addr + BCM_SYS_EMI_OFFSET;
+	else
+		return addr + BCM_VC_EMI_OFFSET;
+}
+
+static void bcm_inv_range(unsigned long start, unsigned long end)
+{
+	unsigned long new_start, new_end;
+
+	if (unlikely(end <= start))
+		return;
+
+	new_start = bcm_l2_phys_addr(start);
+	new_end = bcm_l2_phys_addr(end);
+
+	/* normal case, no cross section between start and end */
+	if (likely((bcm_addr_is_sys_emi(start) && bcm_addr_is_sys_emi(end)) ||
+		(!bcm_addr_is_sys_emi(start) && !bcm_addr_is_sys_emi(end)))) {
+		l2x0_inv_range(new_start, new_end);
+		return;
+	}
+
+	if (bcm_addr_is_sys_emi(start)) {
+		/* start address in Section 2. end address in Section 3 */
+		l2x0_inv_range(new_start,
+				bcm_l2_phys_addr(BCM_SYS_EMI_END_ADDR));
+		l2x0_inv_range(bcm_l2_phys_addr(BCM_VC_EMI_SEC3_START_ADDR),
+				new_end);
+	} else {
+		/* start address in Section 1. end address in Section 2 */
+		l2x0_inv_range(new_start,
+				bcm_l2_phys_addr(BCM_VC_EMI_SEC1_END_ADDR));
+		l2x0_inv_range(bcm_l2_phys_addr(BCM_SYS_EMI_START_ADDR),
+				new_end);
+	}
+}
+
+static void bcm_clean_range(unsigned long start, unsigned long end)
+{
+	unsigned long new_start, new_end;
+
+	if (unlikely(end <= start))
+		return;
+
+	if ((end - start) >= l2x0_size) {
+		l2x0_clean_all();
+		return;
+	}
+
+	new_start = bcm_l2_phys_addr(start);
+	new_end = bcm_l2_phys_addr(end);
+
+	/* normal case, no cross section between start and end */
+	if (likely((bcm_addr_is_sys_emi(start) && bcm_addr_is_sys_emi(end)) ||
+		(!bcm_addr_is_sys_emi(start) && !bcm_addr_is_sys_emi(end)))) {
+		l2x0_clean_range(new_start, new_end);
+		return;
+	}
+
+	if (bcm_addr_is_sys_emi(start)) {
+		/* start address in Section 2. end address in Section 3 */
+		l2x0_clean_range(new_start,
+				bcm_l2_phys_addr(BCM_SYS_EMI_END_ADDR));
+		l2x0_clean_range(bcm_l2_phys_addr(BCM_VC_EMI_SEC3_START_ADDR),
+				new_end);
+	} else {
+		/* start address in Section 1. end address in Section 2 */
+		l2x0_clean_range(new_start,
+				bcm_l2_phys_addr(BCM_VC_EMI_SEC1_END_ADDR));
+		l2x0_clean_range(bcm_l2_phys_addr(BCM_SYS_EMI_START_ADDR),
+				new_end);
+	}
+}
+
+static void bcm_flush_range(unsigned long start, unsigned long end)
+{
+	unsigned long new_start, new_end;
+
+	if (unlikely(end <= start))
+		return;
+
+	if ((end - start) >= l2x0_size) {
+		l2x0_flush_all();
+		return;
+	}
+
+	new_start = bcm_l2_phys_addr(start);
+	new_end = bcm_l2_phys_addr(end);
+
+	/* normal case, no cross section between start and end */
+	if (likely((bcm_addr_is_sys_emi(start) && bcm_addr_is_sys_emi(end)) ||
+		(!bcm_addr_is_sys_emi(start) && !bcm_addr_is_sys_emi(end)))) {
+		l2x0_flush_range(new_start, new_end);
+		return;
+	}
+
+	if (bcm_addr_is_sys_emi(start)) {
+		/* start address in Section 2. end address in Section 3 */
+		l2x0_flush_range(new_start,
+				bcm_l2_phys_addr(BCM_SYS_EMI_END_ADDR));
+		l2x0_flush_range(bcm_l2_phys_addr(BCM_VC_EMI_SEC3_START_ADDR),
+				new_end);
+	} else {
+		/* start address in Section 1. end address in Section 2 */
+		l2x0_flush_range(new_start,
+				bcm_l2_phys_addr(BCM_VC_EMI_SEC1_END_ADDR));
+		l2x0_flush_range(bcm_l2_phys_addr(BCM_SYS_EMI_START_ADDR),
+				new_end);
+	}
+}
+
 static void __init l2x0_of_setup(const struct device_node *np,
 				 u32 *aux_val, u32 *aux_mask)
 {
@@ -765,6 +921,21 @@ static const struct l2x0_of_data aurora_no_outer_data = {
 	},
 };
 
+static const struct l2x0_of_data bcm_l2x0_data = {
+	.setup = pl310_of_setup,
+	.save  = pl310_save,
+	.outer_cache = {
+		.resume      = pl310_resume,
+		.inv_range   = bcm_inv_range,
+		.clean_range = bcm_clean_range,
+		.flush_range = bcm_flush_range,
+		.sync        = l2x0_cache_sync,
+		.flush_all   = l2x0_flush_all,
+		.inv_all     = l2x0_inv_all,
+		.disable     = l2x0_disable,
+	},
+};
+
 static const struct of_device_id l2x0_ids[] __initconst = {
 	{ .compatible = "arm,pl310-cache", .data = (void *)&pl310_data },
 	{ .compatible = "arm,l220-cache", .data = (void *)&l2x0_data },
@@ -773,6 +944,8 @@ static const struct of_device_id l2x0_ids[] __initconst = {
 	  .data = (void *)&aurora_no_outer_data},
 	{ .compatible = "marvell,aurora-outer-cache",
 	  .data = (void *)&aurora_with_outer_data},
+	{ .compatible = "bcm,bcm11351-a2-pl310-cache",
+	  .data = (void *)&bcm_l2x0_data},
 	{}
 };
 
-- 
1.7.10.4




From arnd at arndb.de  Tue Apr 30 16:42:23 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 30 Apr 2013 22:42:23 +0200
Subject: [PATCH 1/5] dmaengine: ste_dma40: Allow memcpy channels to be
 configured from DT
In-Reply-To: <1367336497-10650-1-git-send-email-lee.jones@linaro.org>
References: <1367336497-10650-1-git-send-email-lee.jones@linaro.org>
Message-ID: <201304302242.24002.arnd@arndb.de>

On Tuesday 30 April 2013, Lee Jones wrote:
> @@ -6,6 +6,8 @@ Required properties:
>  - reg-names: Names of the above areas to use during resource look-up
>  - interrupt: Should contain the DMAC interrupt number
>  - #dma-cells: must be <3>
> +- memcpy-channels: Channels to be used for memcpy
> +- memcpy-num-chans: Number of channels to be used for memcpy
>  
>  Optional properties:
>  - dma-channels: Number of channels supported by hardware - if not present
> @@ -21,6 +23,8 @@ Example:
>                 interrupts = <0 25 0x4>;
>  
>                 #dma-cells = <2>;
> +               memcpy-channels  = <56, 57, 58, 59, 60>;
> +               memcpy-num-chans = <5>;
>                 dma-channels = <8>;
>         };
>  

I think you should remove the memcpy-num-chans property and instead evaluate the
length of the memcpy-channels property. Aside from this, it looks fine.

	Arnd


From arnd at arndb.de  Tue Apr 30 16:43:01 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 30 Apr 2013 22:43:01 +0200
Subject: [PATCH 3/5] ARM: ux500: Stop passing DMA platform data though
 AUXDATA
In-Reply-To: <1367336497-10650-3-git-send-email-lee.jones@linaro.org>
References: <1367336497-10650-1-git-send-email-lee.jones@linaro.org>
 <1367336497-10650-3-git-send-email-lee.jones@linaro.org>
Message-ID: <201304302243.02145.arnd@arndb.de>

On Tuesday 30 April 2013, Lee Jones wrote:
> The DMA platform data is now empty due to some recent refactoring,
> so there is no longer a requirement to pass it though.
> 
> Signed-off-by: Lee Jones <lee.jones at linaro.org>

Acked-by: Arnd Bergmann <arnd at arndb.de>


From akpm at linux-foundation.org  Tue Apr 30 16:56:02 2013
From: akpm at linux-foundation.org (Andrew Morton)
Date: Tue, 30 Apr 2013 13:56:02 -0700
Subject: [PATCH v3 -next 3/5] arm: Add support for LZ4-compressed kernel
In-Reply-To: <1362484056-9778-4-git-send-email-kyungsik.lee@lge.com>
References: <1362484056-9778-1-git-send-email-kyungsik.lee@lge.com>
 <1362484056-9778-4-git-send-email-kyungsik.lee@lge.com>
Message-ID: <20130430135602.2aa0d3b4ec392bf83a9b64d0@linux-foundation.org>

On Tue,  5 Mar 2013 20:47:34 +0900 Kyungsik Lee <kyungsik.lee at lge.com> wrote:

> This patch integrates the LZ4 decompression code to the arm pre-boot code.
> And it depends on two patchs below
> 
> lib: Add support for LZ4-compressed kernel
> decompressor: Add LZ4 decompressor module
> 
> ...
>
> - Apply CFLAGS, -Os to decompress.o to improve decompress
>   performance during boot-up process
>
> ...
>
> --- a/arch/arm/boot/compressed/Makefile
> +++ b/arch/arm/boot/compressed/Makefile
> @@ -24,6 +24,9 @@ endif
>  AFLAGS_head.o += -DTEXT_OFFSET=$(TEXT_OFFSET)
>  HEAD	= head.o
>  OBJS	+= misc.o decompress.o
> +ifeq ($(CONFIG_KERNEL_LZ4),y)
> +CFLAGS_decompress.o := -Os
> +endif

Surprised.  You found that -Os produces faster code than -O2?  Details,
please?



From gmbnomis at gmail.com  Tue Apr 30 17:04:03 2013
From: gmbnomis at gmail.com (Simon Baatz)
Date: Tue, 30 Apr 2013 23:04:03 +0200
Subject: [PATCH V3 2/2] ARM: Handle user space mapped pages in
 flush_kernel_dcache_page
In-Reply-To: <20130430112225.GD29766@arm.com>
References: <20121008200216.GA14167@schnuecks.de>
 <20121008202040.GC4625@n2100.arm.linux.org.uk>
 <20121008230733.GA17819@schnuecks.de>
 <20121118211005.GW22106@titan.lakedaemon.net>
 <20130418111608.GF27197@titan.lakedaemon.net>
 <20130418112201.GQ14496@n2100.arm.linux.org.uk>
 <20130418114016.GG27197@titan.lakedaemon.net>
 <20130418135104.GA18616@arm.com>
 <20130421220629.GA25571@schnuecks.de>
 <20130430112225.GD29766@arm.com>
Message-ID: <20130430210403.GA18076@schnuecks.de>

Hi Catalin,

On Tue, Apr 30, 2013 at 12:22:25PM +0100, Catalin Marinas wrote:
> On Sun, Apr 21, 2013 at 11:06:30PM +0100, Simon Baatz wrote:
> > On Thu, Apr 18, 2013 at 02:51:04PM +0100, Catalin Marinas wrote:
> > > On Thu, Apr 18, 2013 at 12:40:16PM +0100, Jason Cooper wrote:
...
> > 
> > It is not the driver itself which is using the API, it is the
> > generic scatterlist memory iterator. And I don't think that this is
> > wrong, as I have tried to explain in [1].
> 
> Trying to remember what we've discussed over the past months on this
> topic. It looks like sg_miter_stop() does the right thing in calling
> flush_kernel_dcache_page(). Commit f8b63c1 (ARM: 6382/1: Remove
> superfluous flush_kernel_dcache_page()) removed this function entirely.
> The code previously had this comment - /* highmem pages are always
> flushed upon kunmap already */ which I think it wasn't fully correct
> either. The kunmap_atomic() flushes the caches but kunmap() doesn't, so
> I suspect we only get the flushing if SG_MITER_ATOMIC.
> 
> So it looks to me like flush_kernel_dcache_page() should be implemented
> even for highmem pages (with VIVT or aliasing VIPT, at least for non
> kmap_atomic addresses by checking for FIXADDR_START). If highmem is
> disabled, I suspect we still need this function since the calling code
> doesn't care whether kmap/kunmap was a no-op. But can we keep it as a
> simple call to __cpuc_flush_dcache_area(page_address(page), PAGE_SIZE)?

My first version ([1]) had:

	if ((cache_is_vivt() || cache_is_vipt_aliasing()) && !PageHighMem(page))
		__flush_kernel_dcache_page(page);

If I understand this correctly, you are proposing to remove the
highmem exclusion.

And then in __flush_kernel_dcache_page():

	mapping = page_mapping(page);

	if (!mapping || mapping_mapped(mapping))
		__cpuc_flush_dcache_area(page_address(page), PAGE_SIZE);

I still prefer to have this condition here to avoid the flush when
there is no user mapping at all.  This is handled by lazy flushing
and is probably the most common case anyway (given how many people
seem to be affected by this problem).

Additionally, although we can assume that the page is kmapped,
page_address(page) can still be NULL for a highmem page, right?

- Simon

[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2012-May/101794.html


From tony at atomide.com  Tue Apr 30 17:49:39 2013
From: tony at atomide.com (Tony Lindgren)
Date: Tue, 30 Apr 2013 14:49:39 -0700
Subject: Latest build results - errors/warnings - lots of them
In-Reply-To: <20130430161104.GB26257@atomide.com>
References: <20130430081739.GP14496@n2100.arm.linux.org.uk>
 <201304301304.20650.arnd@arndb.de>
 <20130430161104.GB26257@atomide.com>
Message-ID: <20130430214939.GD28721@atomide.com>

* Tony Lindgren <tony at atomide.com> [130430 09:19]:
> * Arnd Bergmann <arnd at arndb.de> [130430 04:10]:
> > On Tuesday 30 April 2013, Russell King - ARM Linux wrote:
> > > Latest nightly build of 3.9+my for-next+arm-soc's for-next results in a
> > > great load of new warnings and errors.  arch/arm/common/mcpm_head.S,
> > > arch/arm/common/mcpm_platsmp.c, arch/arm/common/vlock.S are the biggest
> > > source of errors.
> > 
> > Yes, I noticed this but haven't gotten around to prepare a patch. I'll comment
> > below.
> > 
> > > OMAP stuff needs a serious look at too - much Kconfig madness there
> > > caused by over-use of select, which then goes on to cause build errors
> > > because it assumes some stuff is always enabled.
> 
> I have posted a few randconfig fixes in "[PATCH 0/3] few omap randconfig
> fixes for v3.10" that also remove the select of SERIAL_OMAP that I missed
> while fixing the 8250 issue. I was planning to send a pull request after
> the merge window, but can do it now too if people prefer that.

I'll apply only the SERIAL_OMAP fix into omap-for-v3.10/fixes-randconfig
against v3.9-rc7 as the two other warning fixes depend on other branches
and can be merged after -rc1.
  
> > Ack. I have not looked much at randconfig output, but this has certianly
> > grown worse after CONFIG_ARCH_OMAP has gotten included in ARCH_MULTIPLATFORM
> 
> I have a patch coming for the "no SoC selected" randconfig issue as
> discussed in the "linux-next ARM multi-platform randconfig errors"
> thread. I suggest we do the minimal fix I already posted for now,
> then reorganize more of the Makefile as Arnd suggested for v3.11.

Got the fix for "no SoC selected" boiled down to a minimal Makefile only
fix as Arnd suggested, will post shortly.

Regards,

Tony


From tony at atomide.com  Tue Apr 30 18:04:13 2013
From: tony at atomide.com (Tony Lindgren)
Date: Tue, 30 Apr 2013 15:04:13 -0700
Subject: [PATCH] ARM: OMAP2+: Fix multiple make randconfig errors if no SoC
 is selected
Message-ID: <20130430220413.GE28721@atomide.com>

If no SoC is selected, we should build in only minimal code
to bring up a new SoC as none of the SoC specific features are
implemented. Otherwise we will get multiple randconfig errors
when no SoC is selected.

Fix this by tagging the SoC dependant code with soc-y in the omap2+
related makefiles as suggested by Arnd Bergmann <arnd at arndb.de>.
Note that we could improve some of the dependencies further by adding
a silent Kconfig entry for SOC_OMAP. But let's do that separately
as that's not needed for the minimal fix.

Without this patch the build errors are something like:

arch/arm/mach-omap2/built-in.o: In function `_add_initiator_dep':
arch/arm/mach-omap2/omap_hwmod.c:691: undefined reference to `clkdm_add_sleepdep'
arch/arm/mach-omap2/built-in.o: In function `_deassert_hardreset':
arch/arm/mach-omap2/omap_hwmod.c:1677: undefined reference to `clkdm_in_hwsup'
arch/arm/mach-omap2/omap_hwmod.c:1678: undefined reference to `clkdm_hwmod_enable'
arch/arm/mach-omap2/omap_hwmod.c:1705: undefined reference to `clkdm_allow_idle'
arch/arm/mach-omap2/omap_hwmod.c:1708: undefined reference to `clkdm_hwmod_disable'
arch/arm/mach-omap2/built-in.o: In function `_enable':
arch/arm/mach-omap2/built-in.o: In function `_enable':
arch/arm/mach-omap2/omap_hwmod.c:2145: undefined reference to `clkdm_in_hwsup'
arch/arm/mach-omap2/omap_hwmod.c:2147: undefined reference to `clkdm_hwmod_enable'
arch/arm/mach-omap2/omap_hwmod.c:2145: undefined reference to `clkdm_missing_idle_reporting'
arch/arm/mach-omap2/omap_hwmod.c:2191: undefined reference to `clkdm_hwmod_disable'
arch/arm/mach-omap2/omap_hwmod.c:2172: undefined reference to `clkdm_allow_idle'
arch/arm/mach-omap2/built-in.o: In function `_del_initiator_dep':
arch/arm/mach-omap2/omap_hwmod.c:720: undefined reference to `clkdm_del_sleepdep'
arch/arm/mach-omap2/built-in.o: In function `_idle':
arch/arm/mach-omap2/omap_hwmod.c:2235: undefined reference to `clkdm_hwmod_disable'
arch/arm/mach-omap2/built-in.o: In function `_shutdown':
arch/arm/mach-omap2/omap_hwmod.c:2338: undefined reference to `clkdm_hwmod_disable'
arch/arm/mach-omap2/built-in.o: In function `omap_hwmod_get_context_loss_count':
arch/arm/mach-omap2/omap_hwmod.c:4071: undefined reference to `pwrdm_get_context_loss_count'
arch/arm/mach-omap2/built-in.o: In function `pm_dbg_show_timers':
arch/arm/mach-omap2/pm-debug.c:155: undefined reference to `pwrdm_for_each'
arch/arm/mach-omap2/built-in.o: In function `pwrdm_dbg_show_timer':
arch/arm/mach-omap2/pm-debug.c:132: undefined reference to `pwrdm_state_switch'
arch/arm/mach-omap2/built-in.o: In function `pm_dbg_show_counters':
arch/arm/mach-omap2/pm-debug.c:147: undefined reference to `pwrdm_for_each'
arch/arm/mach-omap2/pm-debug.c:148: undefined reference to `clkdm_for_each'
arch/arm/mach-omap2/built-in.o: In function `pwrdm_dbg_show_counter':
arch/arm/mach-omap2/pm-debug.c:102: undefined reference to `pwrdm_read_pwrst'
arch/arm/mach-omap2/pm-debug.c:103: undefined reference to `pwrdm_read_pwrst'
arch/arm/mach-omap2/built-in.o: In function `omap2_common_pm_late_init':
arch/arm/mach-omap2/pm.c:294: undefined reference to `omap_voltage_late_init'
arch/arm/mach-omap2/built-in.o: In function `omap_pm_clkdms_setup':
arch/arm/mach-omap2/pm.c:117: undefined reference to `clkdm_sleep'
arch/arm/mach-omap2/pm.c:114: undefined reference to `clkdm_allow_idle'
arch/arm/mach-omap2/built-in.o: In function `omap2_gpio_dev_init':
arch/arm/mach-omap2/gpio.c:133: undefined reference to `pwrdm_can_ever_lose_context'
arch/arm/mach-omap2/built-in.o: In function `omap4_smp_prepare_cpus':
arch/arm/mach-omap2/omap-smp.c:204: undefined reference to `omap_get_wakeupgen_base'
arch/arm/mach-omap2/omap-smp.c:224: undefined reference to `omap_secure_apis_support'
arch/arm/mach-omap2/omap-smp.c:225: undefined reference to `omap_auxcoreboot_addr'
arch/arm/mach-omap2/built-in.o: In function `pm_dbg_init':
arch/arm/mach-omap2/pm-debug.c:272: undefined reference to `pwrdm_for_each'
arch/arm/mach-omap2/built-in.o: In function `omap4_boot_secondary':
arch/arm/mach-omap2/omap-smp.c:80: undefined reference to `omap_get_wakeupgen_base'
arch/arm/mach-omap2/omap-smp.c:94: undefined reference to `omap_secure_apis_support'
arch/arm/mach-omap2/omap-smp.c:140: undefined reference to `clkdm_wakeup'
arch/arm/mach-omap2/omap-smp.c:141: undefined reference to `omap_set_pwrdm_state'
arch/arm/mach-omap2/omap-smp.c:142: undefined reference to `clkdm_allow_idle'
arch/arm/mach-omap2/omap-smp.c:95: undefined reference to `omap_modify_auxcoreboot0'
arch/arm/mach-omap2/omap-smp.c:100: undefined reference to `clkdm_lookup'
arch/arm/mach-omap2/omap-smp.c:101: undefined reference to `pwrdm_lookup'
arch/arm/mach-omap2/built-in.o: In function `omap4_cpu_die':
arch/arm/mach-omap2/omap-hotplug.c:33: undefined reference to `omap_get_wakeupgen_base'
arch/arm/mach-omap2/omap-hotplug.c:38: undefined reference to `omap_secure_apis_support'
arch/arm/mach-omap2/omap-hotplug.c:50: undefined reference to `omap4_hotplug_cpu'
arch/arm/mach-omap2/omap-hotplug.c:52: undefined reference to `omap_secure_apis_support'
arch/arm/mach-omap2/omap-hotplug.c:53: undefined reference to `omap_read_auxcoreboot0'
arch/arm/mach-omap2/omap-hotplug.c:39: undefined reference to `omap_modify_auxcoreboot0'

Signed-off-by: Tony Lindgren <tony at atomide.com>

--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -5,8 +5,11 @@
 ccflags-$(CONFIG_ARCH_MULTIPLATFORM) := -I$(srctree)/$(src)/include \
 	-I$(srctree)/arch/arm/plat-omap/include
 
-# Common support
-obj-y := id.o io.o control.o mux.o devices.o fb.o serial.o gpmc.o timer.o pm.o \
+# Always built even if no SoC is selected
+obj-y := id.o control.o
+
+# Built when at least one SoC is selected
+soc-y := io.o mux.o devices.o fb.o serial.o gpmc.o timer.o pm.o \
 	 common.o gpio.o dma.o wd_timer.o display.o i2c.o hdq1w.o omap_hwmod.o \
 	 omap_device.o sram.o
 
@@ -24,7 +27,7 @@ obj-$(CONFIG_SOC_AM33XX) += irq.o $(hwmod-common)
 obj-$(CONFIG_SOC_OMAP5)	 += prm44xx.o $(hwmod-common) $(secure-common)
 
 ifneq ($(CONFIG_SND_OMAP_SOC_MCBSP),)
-obj-y += mcbsp.o
+soc-y += mcbsp.o
 endif
 
 obj-$(CONFIG_TWL4030_CORE) += omap_twl.o
@@ -32,8 +35,8 @@ obj-$(CONFIG_SOC_HAS_OMAP2_SDRC)	+= sdrc.o
 
 # SMP support ONLY available for OMAP4
 
-obj-$(CONFIG_SMP)			+= omap-smp.o omap-headsmp.o
-obj-$(CONFIG_HOTPLUG_CPU)		+= omap-hotplug.o
+soc-$(CONFIG_SMP)			+= omap-smp.o omap-headsmp.o
+soc-$(CONFIG_HOTPLUG_CPU)		+= omap-hotplug.o
 omap-4-5-common				=  omap4-common.o omap-wakeupgen.o \
 					   sleep44xx.o
 obj-$(CONFIG_ARCH_OMAP4)		+= $(omap-4-5-common)
@@ -77,7 +80,7 @@ obj-$(CONFIG_ARCH_OMAP4)		+= opp4xxx_data.o
 endif
 
 # Power Management
-obj-$(CONFIG_OMAP_PM_NOOP)		+= omap-pm-noop.o
+soc-$(CONFIG_OMAP_PM_NOOP)		+= omap-pm-noop.o
 
 ifeq ($(CONFIG_PM),y)
 obj-$(CONFIG_ARCH_OMAP2)		+= pm24xx.o
@@ -85,7 +88,7 @@ obj-$(CONFIG_ARCH_OMAP2)		+= sleep24xx.o
 obj-$(CONFIG_ARCH_OMAP3)		+= pm34xx.o sleep34xx.o
 obj-$(CONFIG_ARCH_OMAP4)		+= pm44xx.o omap-mpuss-lowpower.o
 obj-$(CONFIG_SOC_OMAP5)			+= omap-mpuss-lowpower.o
-obj-$(CONFIG_PM_DEBUG)			+= pm-debug.o
+soc-$(CONFIG_PM_DEBUG)			+= pm-debug.o
 
 obj-$(CONFIG_POWER_AVS_OMAP)		+= sr_device.o
 obj-$(CONFIG_POWER_AVS_OMAP_CLASS3)    += smartreflex-class3.o
@@ -201,7 +204,7 @@ obj-$(CONFIG_ARCH_OMAP4)		+= omap_hwmod_44xx_data.o
 
 # EMU peripherals
 obj-$(CONFIG_OMAP3_EMU)			+= emu.o
-obj-$(CONFIG_HW_PERF_EVENTS)		+= pmu.o
+soc-$(CONFIG_HW_PERF_EVENTS)		+= pmu.o
 
 obj-$(CONFIG_OMAP_MBOX_FWK)		+= mailbox_mach.o
 mailbox_mach-objs			:= mailbox.o
@@ -269,33 +272,40 @@ obj-$(CONFIG_MACH_TI8148EVM)		+= board-ti8168evm.o
 
 omap-flash-$(CONFIG_MTD_NAND_OMAP2)	:= board-flash.o
 omap-flash-$(CONFIG_MTD_ONENAND_OMAP2)	:= board-flash.o
-obj-y					+= $(omap-flash-y) $(omap-flash-m)
+soc-y					+= $(omap-flash-y) $(omap-flash-m)
 
 omap-hsmmc-$(CONFIG_MMC_OMAP_HS)	:= hsmmc.o
 obj-y					+= $(omap-hsmmc-m) $(omap-hsmmc-y)
 
-obj-y					+= usb-musb.o
-obj-y					+= omap_phy_internal.o
+soc-y					+= usb-musb.o
+soc-y					+= omap_phy_internal.o
 
-obj-$(CONFIG_MACH_OMAP2_TUSB6010)	+= usb-tusb6010.o
+soc-$(CONFIG_MACH_OMAP2_TUSB6010)	+= usb-tusb6010.o
 obj-y					+= usb-host.o
 
 onenand-$(CONFIG_MTD_ONENAND_OMAP2)	:= gpmc-onenand.o
-obj-y					+= $(onenand-m) $(onenand-y)
+soc-y					+= $(onenand-m) $(onenand-y)
 
 nand-$(CONFIG_MTD_NAND_OMAP2)		:= gpmc-nand.o
-obj-y					+= $(nand-m) $(nand-y)
+soc-y					+= $(nand-m) $(nand-y)
 
 smc91x-$(CONFIG_SMC91X)			:= gpmc-smc91x.o
-obj-y					+= $(smc91x-m) $(smc91x-y)
+soc-y					+= $(smc91x-m) $(smc91x-y)
 
 smsc911x-$(CONFIG_SMSC911X)		:= gpmc-smsc911x.o
-obj-y					+= $(smsc911x-m) $(smsc911x-y)
+soc-y					+= $(smsc911x-m) $(smsc911x-y)
 ifneq ($(CONFIG_HWSPINLOCK_OMAP),)
-obj-y					+= hwspinlock.o
+soc-y					+= hwspinlock.o
 endif
 
 emac-$(CONFIG_TI_DAVINCI_EMAC)		:= am35xx-emac.o
-obj-y					+= $(emac-m) $(emac-y)
+soc-y					+= $(emac-m) $(emac-y)
+
+soc-y					+= common-board-devices.o twl-common.o dss-common.o
 
-obj-y					+= common-board-devices.o twl-common.o dss-common.o
+# SoC dependant objects
+obj-$(CONFIG_ARCH_OMAP2)		+= $(soc-y)
+obj-$(CONFIG_ARCH_OMAP3)		+= $(soc-y)
+obj-$(CONFIG_ARCH_OMAP4)		+= $(soc-y)
+obj-$(CONFIG_SOC_AM33XX)		+= $(soc-y)
+obj-$(CONFIG_SOC_OMAP5)			+= $(soc-y)
--- a/arch/arm/plat-omap/Makefile
+++ b/arch/arm/plat-omap/Makefile
@@ -4,19 +4,23 @@
 
 ccflags-$(CONFIG_ARCH_MULTIPLATFORM) := -I$(srctree)/arch/arm/plat-omap/include
 
-# Common support
-obj-y := sram.o dma.o counter_32k.o
-obj-m :=
-obj-n :=
-obj-  :=
+# Always built even if no SoC is selected
+obj-y := dma.o
+# Built when at least one SoC is selected
+soc-y := sram.o counter_32k.o
 
-# omap_device support (OMAP2+ only at the moment)
-
-obj-$(CONFIG_OMAP_DM_TIMER) += dmtimer.o
-obj-$(CONFIG_OMAP_DEBUG_LEDS) += debug-leds.o
+soc-$(CONFIG_OMAP_DM_TIMER) += dmtimer.o
+soc-$(CONFIG_OMAP_DEBUG_LEDS) += debug-leds.o
 i2c-omap-$(CONFIG_I2C_OMAP) := i2c.o
-obj-y += $(i2c-omap-m) $(i2c-omap-y)
+soc-y += $(i2c-omap-m) $(i2c-omap-y)
 
 # OMAP mailbox framework
 obj-$(CONFIG_OMAP_MBOX_FWK) += mailbox.o
 
+# SoC dependant objects
+obj-$(CONFIG_ARCH_OMAP1)	+= $(soc-y)
+obj-$(CONFIG_ARCH_OMAP2)	+= $(soc-y)
+obj-$(CONFIG_ARCH_OMAP3)	+= $(soc-y)
+obj-$(CONFIG_ARCH_OMAP4)	+= $(soc-y)
+obj-$(CONFIG_SOC_AM33XX)	+= $(soc-y)
+obj-$(CONFIG_SOC_OMAP5)		+= $(soc-y)


From sergei.shtylyov at cogentembedded.com  Tue Apr 30 18:42:36 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Wed, 1 May 2013 02:42:36 +0400
Subject: [PATCH v7 0/9] Reorganize R8A7779/Marzen USB code
Message-ID: <201305010242.37483.sergei.shtylyov@cogentembedded.com>

Hello.

   Here's the set of 9 patches against the Simon Horman's 'renesas.git' repo,
'renesas-next-20130426' tag.  It was created to fix the shortcomings in the
R8A7779/Marzen USB platform code and R8A7779 USB common PHY driver, and so
spans both arch/arm/mach-shmobile/ and drivers/usb/ subtrees (some patches have
to touch both subtrees). The patches were conceived with the complete
bisectability goal in mind.

[1/9] ARM: shmobile: Marzen: move USB EHCI, OHCI, and PHY devices to R8A7779 code
[2/9] ehci-platform: add pre_setup() method to platform data
[3/9] ARM: shmobile: r8a7779: setup EHCI internal buffer
[4/9] rcar-phy: remove EHCI internal buffer setup
[5/9] ARM: shmobile: r8a7779: remove USB PHY 2nd memory resource
[6/9] rcar-phy: correct base address
[7/9] rcar-phy: add platform data
[8/9] ARM: shmobile: Marzen: pass platform data to USB PHY device
[9/9] rcar-phy: handle platform data

WBR, Sergei


From sergei.shtylyov at cogentembedded.com  Tue Apr 30 18:45:54 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Wed, 1 May 2013 02:45:54 +0400
Subject: [PATCH v7 1/9] ARM: shmobile: Marzen: move USB EHCI, OHCI,
 and PHY devices to R8A7779 code
In-Reply-To: <201305010242.37483.sergei.shtylyov@cogentembedded.com>
References: <201305010242.37483.sergei.shtylyov@cogentembedded.com>
Message-ID: <201305010245.55413.sergei.shtylyov@cogentembedded.com>

USB EHCI, OHCI, and common PHY are the SoC devices but are wrongly defined and
registered in the Marzen board file.  Move the data and code to their proper
place in setup-r8a7779.c; while at it, we have to rename r8a7779_late_devices[]
to r8a7779_standard_devices[] -- this seems legitimate since they are registered
from r8a7779_add_standard_devices() anyway.

Note that I'm deliberately changing the USB PHY platform device's 'id' field
from (previously just omitted) 0 to -1 as the device is a single of its kind.

Note also that the board and SoC code have to be in one patch to keep the code
bisectable...

The patch has been tested on the Marzen board.

Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Acked-by: Simon Horman <horms+renesas at verge.net.au>

---
Changes since version 5:
- fixed typos in the changelog.

Changes since version 4:
- resolved reject in the 'board-marzen.c' file, refreshed the patch.

Changes since version 3:
- refreshed the 'board-marzen.c' file.

Changes since version 2:
- added a note about testing to the changelog;
- added ACKs from Simon Horman and Kuninori Morimoto.

Changes since the original posting:
- added a note about bisectability to the changelog.

 arch/arm/mach-shmobile/board-marzen.c         |  178 -------------------------
 arch/arm/mach-shmobile/include/mach/r8a7779.h |    1 
 arch/arm/mach-shmobile/setup-r8a7779.c        |  185 +++++++++++++++++++++++++-
 3 files changed, 184 insertions(+), 180 deletions(-)

Index: renesas/arch/arm/mach-shmobile/board-marzen.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/board-marzen.c
+++ renesas/arch/arm/mach-shmobile/board-marzen.c
@@ -37,10 +37,6 @@
 #include <linux/mmc/host.h>
 #include <linux/mmc/sh_mobile_sdhi.h>
 #include <linux/mfd/tmio.h>
-#include <linux/usb/otg.h>
-#include <linux/usb/ehci_pdriver.h>
-#include <linux/usb/ohci_pdriver.h>
-#include <linux/pm_runtime.h>
 #include <mach/hardware.h>
 #include <mach/r8a7779.h>
 #include <mach/common.h>
@@ -150,26 +146,6 @@ static struct platform_device hspi_devic
 	.num_resources	= ARRAY_SIZE(hspi_resources),
 };
 
-/* USB PHY */
-static struct resource usb_phy_resources[] = {
-	[0] = {
-		.start		= 0xffe70000,
-		.end		= 0xffe70900 - 1,
-		.flags		= IORESOURCE_MEM,
-	},
-	[1] = {
-		.start		= 0xfff70000,
-		.end		= 0xfff70900 - 1,
-		.flags		= IORESOURCE_MEM,
-	},
-};
-
-static struct platform_device usb_phy_device = {
-	.name		= "rcar_usb_phy",
-	.resource	= usb_phy_resources,
-	.num_resources	= ARRAY_SIZE(usb_phy_resources),
-};
-
 /* LEDS */
 static struct gpio_led marzen_leds[] = {
 	{
@@ -205,161 +181,9 @@ static struct platform_device *marzen_de
 	&sdhi0_device,
 	&thermal_device,
 	&hspi_device,
-	&usb_phy_device,
 	&leds_device,
 };
 
-/* USB */
-static struct usb_phy *phy;
-static int usb_power_on(struct platform_device *pdev)
-{
-	if (!phy)
-		return -EIO;
-
-	pm_runtime_enable(&pdev->dev);
-	pm_runtime_get_sync(&pdev->dev);
-
-	usb_phy_init(phy);
-
-	return 0;
-}
-
-static void usb_power_off(struct platform_device *pdev)
-{
-	if (!phy)
-		return;
-
-	usb_phy_shutdown(phy);
-
-	pm_runtime_put_sync(&pdev->dev);
-	pm_runtime_disable(&pdev->dev);
-}
-
-static struct usb_ehci_pdata ehcix_pdata = {
-	.power_on	= usb_power_on,
-	.power_off	= usb_power_off,
-	.power_suspend	= usb_power_off,
-};
-
-static struct resource ehci0_resources[] = {
-	[0] = {
-		.start	= 0xffe70000,
-		.end	= 0xffe70400 - 1,
-		.flags	= IORESOURCE_MEM,
-	},
-	[1] = {
-		.start	= gic_iid(0x4c),
-		.flags	= IORESOURCE_IRQ,
-	},
-};
-
-static struct platform_device ehci0_device = {
-	.name	= "ehci-platform",
-	.id	= 0,
-	.dev	= {
-		.dma_mask		= &ehci0_device.dev.coherent_dma_mask,
-		.coherent_dma_mask	= 0xffffffff,
-		.platform_data		= &ehcix_pdata,
-	},
-	.num_resources	= ARRAY_SIZE(ehci0_resources),
-	.resource	= ehci0_resources,
-};
-
-static struct resource ehci1_resources[] = {
-	[0] = {
-		.start	= 0xfff70000,
-		.end	= 0xfff70400 - 1,
-		.flags	= IORESOURCE_MEM,
-	},
-	[1] = {
-		.start	= gic_iid(0x4d),
-		.flags	= IORESOURCE_IRQ,
-	},
-};
-
-static struct platform_device ehci1_device = {
-	.name	= "ehci-platform",
-	.id	= 1,
-	.dev	= {
-		.dma_mask		= &ehci1_device.dev.coherent_dma_mask,
-		.coherent_dma_mask	= 0xffffffff,
-		.platform_data		= &ehcix_pdata,
-	},
-	.num_resources	= ARRAY_SIZE(ehci1_resources),
-	.resource	= ehci1_resources,
-};
-
-static struct usb_ohci_pdata ohcix_pdata = {
-	.power_on	= usb_power_on,
-	.power_off	= usb_power_off,
-	.power_suspend	= usb_power_off,
-};
-
-static struct resource ohci0_resources[] = {
-	[0] = {
-		.start	= 0xffe70400,
-		.end	= 0xffe70800 - 1,
-		.flags	= IORESOURCE_MEM,
-	},
-	[1] = {
-		.start	= gic_iid(0x4c),
-		.flags	= IORESOURCE_IRQ,
-	},
-};
-
-static struct platform_device ohci0_device = {
-	.name	= "ohci-platform",
-	.id	= 0,
-	.dev	= {
-		.dma_mask		= &ohci0_device.dev.coherent_dma_mask,
-		.coherent_dma_mask	= 0xffffffff,
-		.platform_data		= &ohcix_pdata,
-	},
-	.num_resources	= ARRAY_SIZE(ohci0_resources),
-	.resource	= ohci0_resources,
-};
-
-static struct resource ohci1_resources[] = {
-	[0] = {
-		.start	= 0xfff70400,
-		.end	= 0xfff70800 - 1,
-		.flags	= IORESOURCE_MEM,
-	},
-	[1] = {
-		.start	= gic_iid(0x4d),
-		.flags	= IORESOURCE_IRQ,
-	},
-};
-
-static struct platform_device ohci1_device = {
-	.name	= "ohci-platform",
-	.id	= 1,
-	.dev	= {
-		.dma_mask		= &ohci1_device.dev.coherent_dma_mask,
-		.coherent_dma_mask	= 0xffffffff,
-		.platform_data		= &ohcix_pdata,
-	},
-	.num_resources	= ARRAY_SIZE(ohci1_resources),
-	.resource	= ohci1_resources,
-};
-
-static struct platform_device *marzen_late_devices[] __initdata = {
-	&ehci0_device,
-	&ehci1_device,
-	&ohci0_device,
-	&ohci1_device,
-};
-
-static void __init marzen_init_late(void)
-{
-	/* get usb phy */
-	phy = usb_get_phy(USB_PHY_TYPE_USB2);
-
-	shmobile_init_late();
-	platform_add_devices(marzen_late_devices,
-			     ARRAY_SIZE(marzen_late_devices));
-}
-
 static const struct pinctrl_map marzen_pinctrl_map[] = {
 	/* HSPI0 */
 	PIN_MAP_MUX_GROUP_DEFAULT("sh-hspi.0", "pfc-r8a7779",
@@ -418,6 +242,6 @@ MACHINE_START(MARZEN, "marzen")
 	.nr_irqs	= NR_IRQS_LEGACY,
 	.init_irq	= r8a7779_init_irq,
 	.init_machine	= marzen_init,
-	.init_late	= marzen_init_late,
+	.init_late	= r8a7779_init_late,
 	.init_time	= r8a7779_earlytimer_init,
 MACHINE_END
Index: renesas/arch/arm/mach-shmobile/include/mach/r8a7779.h
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/include/mach/r8a7779.h
+++ renesas/arch/arm/mach-shmobile/include/mach/r8a7779.h
@@ -33,6 +33,7 @@ extern void r8a7779_add_early_devices(vo
 extern void r8a7779_add_standard_devices(void);
 extern void r8a7779_add_standard_devices_dt(void);
 extern void r8a7779_add_ether_device(struct sh_eth_plat_data *pdata);
+extern void r8a7779_init_late(void);
 extern void r8a7779_clock_init(void);
 extern void r8a7779_pinmux_init(void);
 extern void r8a7779_pm_init(void);
Index: renesas/arch/arm/mach-shmobile/setup-r8a7779.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/setup-r8a7779.c
+++ renesas/arch/arm/mach-shmobile/setup-r8a7779.c
@@ -32,6 +32,10 @@
 #include <linux/sh_intc.h>
 #include <linux/sh_timer.h>
 #include <linux/dma-mapping.h>
+#include <linux/usb/otg.h>
+#include <linux/usb/ehci_pdriver.h>
+#include <linux/usb/ohci_pdriver.h>
+#include <linux/pm_runtime.h>
 #include <mach/hardware.h>
 #include <mach/irqs.h>
 #include <mach/r8a7779.h>
@@ -383,6 +387,162 @@ static struct platform_device sata_devic
 	},
 };
 
+/* USB PHY */
+static struct resource usb_phy_resources[] = {
+	[0] = {
+		.start		= 0xffe70000,
+		.end		= 0xffe70900 - 1,
+		.flags		= IORESOURCE_MEM,
+	},
+	[1] = {
+		.start		= 0xfff70000,
+		.end		= 0xfff70900 - 1,
+		.flags		= IORESOURCE_MEM,
+	},
+};
+
+static struct platform_device usb_phy_device = {
+	.name		= "rcar_usb_phy",
+	.id		= -1,
+	.resource	= usb_phy_resources,
+	.num_resources	= ARRAY_SIZE(usb_phy_resources),
+};
+
+/* USB */
+static struct usb_phy *phy;
+
+static int usb_power_on(struct platform_device *pdev)
+{
+	if (!phy)
+		return -EIO;
+
+	pm_runtime_enable(&pdev->dev);
+	pm_runtime_get_sync(&pdev->dev);
+
+	usb_phy_init(phy);
+
+	return 0;
+}
+
+static void usb_power_off(struct platform_device *pdev)
+{
+	if (!phy)
+		return;
+
+	usb_phy_shutdown(phy);
+
+	pm_runtime_put_sync(&pdev->dev);
+	pm_runtime_disable(&pdev->dev);
+}
+
+static struct usb_ehci_pdata ehcix_pdata = {
+	.power_on	= usb_power_on,
+	.power_off	= usb_power_off,
+	.power_suspend	= usb_power_off,
+};
+
+static struct resource ehci0_resources[] = {
+	[0] = {
+		.start	= 0xffe70000,
+		.end	= 0xffe70400 - 1,
+		.flags	= IORESOURCE_MEM,
+	},
+	[1] = {
+		.start	= gic_iid(0x4c),
+		.flags	= IORESOURCE_IRQ,
+	},
+};
+
+static struct platform_device ehci0_device = {
+	.name	= "ehci-platform",
+	.id	= 0,
+	.dev	= {
+		.dma_mask		= &ehci0_device.dev.coherent_dma_mask,
+		.coherent_dma_mask	= 0xffffffff,
+		.platform_data		= &ehcix_pdata,
+	},
+	.num_resources	= ARRAY_SIZE(ehci0_resources),
+	.resource	= ehci0_resources,
+};
+
+static struct resource ehci1_resources[] = {
+	[0] = {
+		.start	= 0xfff70000,
+		.end	= 0xfff70400 - 1,
+		.flags	= IORESOURCE_MEM,
+	},
+	[1] = {
+		.start	= gic_iid(0x4d),
+		.flags	= IORESOURCE_IRQ,
+	},
+};
+
+static struct platform_device ehci1_device = {
+	.name	= "ehci-platform",
+	.id	= 1,
+	.dev	= {
+		.dma_mask		= &ehci1_device.dev.coherent_dma_mask,
+		.coherent_dma_mask	= 0xffffffff,
+		.platform_data		= &ehcix_pdata,
+	},
+	.num_resources	= ARRAY_SIZE(ehci1_resources),
+	.resource	= ehci1_resources,
+};
+
+static struct usb_ohci_pdata ohcix_pdata = {
+	.power_on	= usb_power_on,
+	.power_off	= usb_power_off,
+	.power_suspend	= usb_power_off,
+};
+
+static struct resource ohci0_resources[] = {
+	[0] = {
+		.start	= 0xffe70400,
+		.end	= 0xffe70800 - 1,
+		.flags	= IORESOURCE_MEM,
+	},
+	[1] = {
+		.start	= gic_iid(0x4c),
+		.flags	= IORESOURCE_IRQ,
+	},
+};
+
+static struct platform_device ohci0_device = {
+	.name	= "ohci-platform",
+	.id	= 0,
+	.dev	= {
+		.dma_mask		= &ohci0_device.dev.coherent_dma_mask,
+		.coherent_dma_mask	= 0xffffffff,
+		.platform_data		= &ohcix_pdata,
+	},
+	.num_resources	= ARRAY_SIZE(ohci0_resources),
+	.resource	= ohci0_resources,
+};
+
+static struct resource ohci1_resources[] = {
+	[0] = {
+		.start	= 0xfff70400,
+		.end	= 0xfff70800 - 1,
+		.flags	= IORESOURCE_MEM,
+	},
+	[1] = {
+		.start	= gic_iid(0x4d),
+		.flags	= IORESOURCE_IRQ,
+	},
+};
+
+static struct platform_device ohci1_device = {
+	.name	= "ohci-platform",
+	.id	= 1,
+	.dev	= {
+		.dma_mask		= &ohci1_device.dev.coherent_dma_mask,
+		.coherent_dma_mask	= 0xffffffff,
+		.platform_data		= &ohcix_pdata,
+	},
+	.num_resources	= ARRAY_SIZE(ohci1_resources),
+	.resource	= ohci1_resources,
+};
+
 /* Ether */
 static struct resource ether_resources[] = {
 	{
@@ -404,9 +564,10 @@ static struct platform_device *r8a7779_d
 	&scif5_device,
 	&tmu00_device,
 	&tmu01_device,
+	&usb_phy_device,
 };
 
-static struct platform_device *r8a7779_late_devices[] __initdata = {
+static struct platform_device *r8a7779_standard_devices[] __initdata = {
 	&i2c0_device,
 	&i2c1_device,
 	&i2c2_device,
@@ -426,8 +587,8 @@ void __init r8a7779_add_standard_devices
 
 	platform_add_devices(r8a7779_devices_dt,
 			    ARRAY_SIZE(r8a7779_devices_dt));
-	platform_add_devices(r8a7779_late_devices,
-			    ARRAY_SIZE(r8a7779_late_devices));
+	platform_add_devices(r8a7779_standard_devices,
+			    ARRAY_SIZE(r8a7779_standard_devices));
 }
 
 void __init r8a7779_add_ether_device(struct sh_eth_plat_data *pdata)
@@ -470,6 +631,23 @@ void __init r8a7779_add_early_devices(vo
 	 */
 }
 
+static struct platform_device *r8a7779_late_devices[] __initdata = {
+	&ehci0_device,
+	&ehci1_device,
+	&ohci0_device,
+	&ohci1_device,
+};
+
+void __init r8a7779_init_late(void)
+{
+	/* get USB PHY */
+	phy = usb_get_phy(USB_PHY_TYPE_USB2);
+
+	shmobile_init_late();
+	platform_add_devices(r8a7779_late_devices,
+			     ARRAY_SIZE(r8a7779_late_devices));
+}
+
 #ifdef CONFIG_USE_OF
 void __init r8a7779_init_delay(void)
 {
@@ -503,6 +681,7 @@ DT_MACHINE_START(R8A7779_DT, "Generic R8
 	.init_irq	= r8a7779_init_irq_dt,
 	.init_machine	= r8a7779_add_standard_devices_dt,
 	.init_time	= shmobile_timer_init,
+	.init_late	= r8a7779_init_late,
 	.dt_compat	= r8a7779_compat_dt,
 MACHINE_END
 #endif /* CONFIG_USE_OF */


From sergei.shtylyov at cogentembedded.com  Tue Apr 30 18:51:27 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Wed, 1 May 2013 02:51:27 +0400
Subject: [PATCH v7 3/9] ARM: shmobile: r8a7779: setup EHCI internal buffer
In-Reply-To: <201305010242.37483.sergei.shtylyov@cogentembedded.com>
References: <201305010242.37483.sergei.shtylyov@cogentembedded.com>
Message-ID: <201305010251.28029.sergei.shtylyov@cogentembedded.com>

Setup the EHCI internal buffer (before EHCI driver has a chance to touch the
registers) using the pre_setup() method in 'struct usb_ehci_pdata'.

The patch has been tested on the Marzen board.

Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Acked-by: Simon Horman <horms+renesas at verge.net.au>

---
Changes since version 4:
- refreshed the patch.

Changes since version 3:
- lowercased the SoC name in the subject.

Changes since version 2:
- added #include <linux/usb/hcd.h>;
- added a note about testing to the changelog;
- added ACKs from Simon Horman and Kuninori Morimoto.

Changes since the original posting:
- changed from init() platform device method to pre_setup() as per the previous
  patch.

 arch/arm/mach-shmobile/setup-r8a7779.c |   16 ++++++++++++++++
 1 file changed, 16 insertions(+)

Index: renesas/arch/arm/mach-shmobile/setup-r8a7779.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/setup-r8a7779.c
+++ renesas/arch/arm/mach-shmobile/setup-r8a7779.c
@@ -33,6 +33,7 @@
 #include <linux/sh_timer.h>
 #include <linux/dma-mapping.h>
 #include <linux/usb/otg.h>
+#include <linux/usb/hcd.h>
 #include <linux/usb/ehci_pdriver.h>
 #include <linux/usb/ohci_pdriver.h>
 #include <linux/pm_runtime.h>
@@ -435,10 +436,25 @@ static void usb_power_off(struct platfor
 	pm_runtime_disable(&pdev->dev);
 }
 
+static int ehci_init_internal_buffer(struct usb_hcd *hcd)
+{
+	/*
+	 * Below are recommended values from the datasheet;
+	 * see [USB :: Setting of EHCI Internal Buffer].
+	 */
+	/* EHCI IP internal buffer setting */
+	iowrite32(0x00ff0040, hcd->regs + 0x0094);
+	/* EHCI IP internal buffer enable */
+	iowrite32(0x00000001, hcd->regs + 0x009C);
+
+	return 0;
+}
+
 static struct usb_ehci_pdata ehcix_pdata = {
 	.power_on	= usb_power_on,
 	.power_off	= usb_power_off,
 	.power_suspend	= usb_power_off,
+	.pre_setup	= ehci_init_internal_buffer,
 };
 
 static struct resource ehci0_resources[] = {


From sergei.shtylyov at cogentembedded.com  Tue Apr 30 18:56:05 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Wed, 1 May 2013 02:56:05 +0400
Subject: [PATCH v7 5/9] ARM: shmobile: r8a7779: remove USB PHY 2nd memory
 resource
In-Reply-To: <201305010242.37483.sergei.shtylyov@cogentembedded.com>
References: <201305010242.37483.sergei.shtylyov@cogentembedded.com>
Message-ID: <201305010256.06379.sergei.shtylyov@cogentembedded.com>

Now that 'drivers/usb/phy/rcar-phy.c' doesn't require the second memory resource
anymore, we can remove it from the R8A7779's USB PHY platform device.

Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Acked-by: Simon Horman <horms+renesas at verge.net.au>

---
Changes since version 4:
- refreshed the patch.

Changes since version 3:
- lowercased the SoC name in the subject.

Changes since version 2:
- refreshed atop of the prior patches;
- added a note about testing to the changelog;
- added ACKs from Simon Horman and Kuninori Morimoto.

Changes since the original posting:
- new patch in this version, split from the previous one.

 arch/arm/mach-shmobile/setup-r8a7779.c |    5 -----
 1 file changed, 5 deletions(-)

Index: renesas/arch/arm/mach-shmobile/setup-r8a7779.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/setup-r8a7779.c
+++ renesas/arch/arm/mach-shmobile/setup-r8a7779.c
@@ -395,11 +395,6 @@ static struct resource usb_phy_resources
 		.end		= 0xffe70900 - 1,
 		.flags		= IORESOURCE_MEM,
 	},
-	[1] = {
-		.start		= 0xfff70000,
-		.end		= 0xfff70900 - 1,
-		.flags		= IORESOURCE_MEM,
-	},
 };
 
 static struct platform_device usb_phy_device = {


From sergei.shtylyov at cogentembedded.com  Tue Apr 30 19:02:20 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Wed, 1 May 2013 03:02:20 +0400
Subject: [PATCH v7 8/9] ARM: shmobile: Marzen: pass platform data to USB PHY
 device
In-Reply-To: <201305010242.37483.sergei.shtylyov@cogentembedded.com>
References: <201305010242.37483.sergei.shtylyov@cogentembedded.com>
Message-ID: <201305010302.20726.sergei.shtylyov@cogentembedded.com>

Since we're now going to setup the USBPCTRL0 register using the USB PHY device's
platform data, we now need a way to pass those platform data from the board file
to the device which is situated in setup-r8a7779.c -- and what I'm suggesting is
r8a7779_add_usb_phy_device() that will register USB PHY platform device with the
passed platform data using platform_device_register_resndata() call; creating
this function involves deletion of 'usb_phy_device' from r8a7779_devices_dt[],
so that it will no longer be registered for the generic R8A7779 machine (where
we can't provide the platform data anyway), hence EHCI/OHCI drivers will fail
to load as well.

For the Marzen board, this new function will be called from marzen_init() to
register the USB PHY device early enough.

Note that the board and the SoC code have to be in one patch to keep the code
bisectable...

The patch has been tested on the Marzen board.

Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Acked-by: Simon Horman <horms+renesas at verge.net.au>

---
Changes since version 6:
- renamed the R-Car PHY driver header file in #include.

Changes since version 5:
- annotated USB PHY resources and platform data as '__initdata' since they're
  kmemdup()'ed while registering the platform device anyway;
- fixed typo in the changelog.

Changes since version 4:
- refreshed the patch.

Changes since version 3:
- removed the initializer for 'usb_phy_platform_data';
- refreshed the 'board-marzen.c' file.

Changes since version 2:
- refreshed atop of the prior patches;
- added a note about testing to the changelog;
- added ACKs from Simon Horman and Kuninori Morimoto.

Changes since the original posting:
- added a note about bisectability to the changelog.

 arch/arm/mach-shmobile/board-marzen.c         |    3 +++
 arch/arm/mach-shmobile/include/mach/r8a7779.h |    2 ++
 arch/arm/mach-shmobile/setup-r8a7779.c        |   18 +++++++++---------
 3 files changed, 14 insertions(+), 9 deletions(-)

Index: renesas/arch/arm/mach-shmobile/board-marzen.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/board-marzen.c
+++ renesas/arch/arm/mach-shmobile/board-marzen.c
@@ -57,6 +57,8 @@ static struct regulator_consumer_supply 
 	REGULATOR_SUPPLY("vdd33a", "smsc911x"),
 };
 
+static struct rcar_phy_platform_data usb_phy_platform_data __initdata;
+
 /* SMSC LAN89218 */
 static struct resource smsc911x_resources[] = {
 	[0] = {
@@ -232,6 +234,7 @@ static void __init marzen_init(void)
 	r8a7779_init_irq_extpin(1); /* IRQ1 as individual interrupt */
 
 	r8a7779_add_standard_devices();
+	r8a7779_add_usb_phy_device(&usb_phy_platform_data);
 	platform_add_devices(marzen_devices, ARRAY_SIZE(marzen_devices));
 }
 
Index: renesas/arch/arm/mach-shmobile/include/mach/r8a7779.h
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/include/mach/r8a7779.h
+++ renesas/arch/arm/mach-shmobile/include/mach/r8a7779.h
@@ -4,6 +4,7 @@
 #include <linux/sh_clk.h>
 #include <linux/pm_domain.h>
 #include <linux/sh_eth.h>
+#include <linux/platform_data/usb-rcar-phy.h>
 
 struct platform_device;
 
@@ -33,6 +34,7 @@ extern void r8a7779_add_early_devices(vo
 extern void r8a7779_add_standard_devices(void);
 extern void r8a7779_add_standard_devices_dt(void);
 extern void r8a7779_add_ether_device(struct sh_eth_plat_data *pdata);
+extern void r8a7779_add_usb_phy_device(struct rcar_phy_platform_data *pdata);
 extern void r8a7779_init_late(void);
 extern void r8a7779_clock_init(void);
 extern void r8a7779_pinmux_init(void);
Index: renesas/arch/arm/mach-shmobile/setup-r8a7779.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/setup-r8a7779.c
+++ renesas/arch/arm/mach-shmobile/setup-r8a7779.c
@@ -389,7 +389,7 @@ static struct platform_device sata_devic
 };
 
 /* USB PHY */
-static struct resource usb_phy_resources[] = {
+static struct resource usb_phy_resources[] __initdata = {
 	[0] = {
 		.start		= 0xffe70800,
 		.end		= 0xffe70900 - 1,
@@ -397,13 +397,6 @@ static struct resource usb_phy_resources
 	},
 };
 
-static struct platform_device usb_phy_device = {
-	.name		= "rcar_usb_phy",
-	.id		= -1,
-	.resource	= usb_phy_resources,
-	.num_resources	= ARRAY_SIZE(usb_phy_resources),
-};
-
 /* USB */
 static struct usb_phy *phy;
 
@@ -575,7 +568,6 @@ static struct platform_device *r8a7779_d
 	&scif5_device,
 	&tmu00_device,
 	&tmu01_device,
-	&usb_phy_device,
 };
 
 static struct platform_device *r8a7779_standard_devices[] __initdata = {
@@ -610,6 +602,14 @@ void __init r8a7779_add_ether_device(str
 					  pdata, sizeof(*pdata));
 }
 
+void __init r8a7779_add_usb_phy_device(struct rcar_phy_platform_data *pdata)
+{
+	platform_device_register_resndata(&platform_bus, "rcar_usb_phy", -1,
+					  usb_phy_resources,
+					  ARRAY_SIZE(usb_phy_resources),
+					  pdata, sizeof(*pdata));
+}
+
 /* do nothing for !CONFIG_SMP or !CONFIG_HAVE_TWD */
 void __init __weak r8a7779_register_twd(void) { }
 


From sergei.shtylyov at cogentembedded.com  Tue Apr 30 19:09:07 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Wed, 1 May 2013 03:09:07 +0400
Subject: [PATCH v6 0/3] Add USB support to R8A7778/BOCK-W
Message-ID: <201305010309.07744.sergei.shtylyov@cogentembedded.com>

Hello.

   Here's the set of 3 patches against the Simon Horman's 'renesas.git' repo,
'renesas-next-20130426' tag and the R8A7779/Marzen patchset I've posted.
 It was created to add support of R8A7778/BOCK-W USB to the platform code and
the USB common PHY driver, and so spans both arch/arm/mach-shmobile/ and
drivers/usb/phy/ subtrees.

[1/3] rcar-phy: add R8A7778 support
[2/3] ARM: shmobile: r8a7778: add USB support
[3/3] ARM: shmobile: BOCK-W: add USB support

The patch #4 (ARM: shmobile: BOCK-W: enable USB in defconfig) that has been
already merged, is not reposted.

WBR, Sergei


From arnd at arndb.de  Tue Apr 30 19:11:14 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed, 1 May 2013 01:11:14 +0200
Subject: Latest build results - errors/warnings - lots of them
In-Reply-To: <20130430081739.GP14496@n2100.arm.linux.org.uk>
References: <20130430081739.GP14496@n2100.arm.linux.org.uk>
Message-ID: <201305010111.14247.arnd@arndb.de>

On Tuesday 30 April 2013, Russell King - ARM Linux wrote:
> Latest nightly build of 3.9+my for-next+arm-soc's for-next results in a
> great load of new warnings and errors.  arch/arm/common/mcpm_head.S,
> arch/arm/common/mcpm_platsmp.c, arch/arm/common/vlock.S are the biggest
> source of errors.
> 
> OMAP stuff needs a serious look at too - much Kconfig madness there
> caused by over-use of select, which then goes on to cause build errors
> because it assumes some stuff is always enabled.
> 
> There's also warnings about of_device_id from include/linux/of_platform.h
> via from arch/arm/kernel/setup.c which feature in all the non-OF builds
> too which need addressing.
> 
> See todays http://www.arm.linux.org.uk/developer/build/ results for all
> the details and configs.  Not pushing my tree until some of this stuff
> gets fixed.

A couple hundred kernel builds and 50 patches later, I actually managed to
get a reliably building randconfig.  There are no proper changeset
comments yet, and no Signed-off-by.

I've uploaded this to the test-merge-20130430 branch in the arm-soc
tree if anyone is curious. I suppose we should get all the changes
in arch/arm included in the merge window and then work with the
subsystem maintainers on the other bugs.

	Arnd

---
 arch/Kconfig                                  |   1 +
 arch/arm/Kconfig                              |   4 +-
 arch/arm/boot/compressed/Makefile             |   2 +-
 arch/arm/boot/compressed/head-sa1100.S        |   1 +
 arch/arm/boot/compressed/head-shark.S         |   1 +
 arch/arm/boot/compressed/head.S               |  13 +--
 arch/arm/configs/omap2plus_defconfig          |   6 +-
 arch/arm/kernel/psci_smp.c                    |   4 +-
 arch/arm/kvm/Kconfig                          |  26 ++---
 arch/arm/mach-imx/headsmp.S                   |   2 +-
 arch/arm/mach-imx/src.c                       |   3 +-
 arch/arm/mach-omap2/Kconfig                   | 133 +++++++++++++-------------
 arch/arm/mach-omap2/Makefile                  |   8 +-
 arch/arm/mach-prima2/Kconfig                  |   2 +-
 arch/arm/mach-spear/Makefile                  |   6 +-
 arch/arm/mach-spear/spear13xx.c               |   2 +
 arch/arm/mach-tegra/Kconfig                   |   5 +-
 arch/arm/mach-ux500/Kconfig                   |   2 +
 crypto/Kconfig                                |   2 +
 drivers/cpufreq/Kconfig.arm                   |   1 +
 drivers/cpuidle/Kconfig                       |   1 +
 drivers/gpu/drm/tilcdc/Kconfig                |   1 +
 drivers/gpu/host1x/drm/Kconfig                |   1 +
 drivers/media/platform/Kconfig                |   1 +
 drivers/media/platform/davinci/Kconfig        |   3 +
 drivers/media/radio/Kconfig                   |   1 +
 drivers/mfd/Kconfig                           |   2 +-
 drivers/net/can/Kconfig                       |   6 +-
 drivers/net/ethernet/mellanox/mlx4/en_clock.c |   2 +-
 drivers/net/wireless/iwlegacy/common.h        |   2 +-
 drivers/staging/android/logger.c              |   4 +-
 drivers/staging/android/logger.h              |   2 +-
 drivers/staging/imx-drm/Kconfig               |   4 +
 drivers/staging/media/solo6x10/Kconfig        |   1 +
 drivers/usb/host/Kconfig                      |  76 ++++++++++++---
 drivers/usb/host/Makefile                     |   4 +-
 drivers/usb/host/ehci-hcd.c                   |  17 ----
 drivers/usb/host/ohci-hcd.c                   |  19 ----
 drivers/usb/host/uhci-hcd.c                   |   4 +-
 drivers/usb/storage/realtek_cr.c              |   3 -
 drivers/video/console/Makefile                |   2 +
 drivers/video/omap2/dss/Kconfig               |   1 +
 drivers/xen/Kconfig                           |   2 +-
 include/drm/drmP.h                            |   3 +-
 include/linux/cpu_cooling.h                   |   2 +-
 45 files changed, 207 insertions(+), 181 deletions(-)


From sergei.shtylyov at cogentembedded.com  Tue Apr 30 19:13:02 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Wed, 1 May 2013 03:13:02 +0400
Subject: [PATCH v6 2/3] ARM: shmobile: r8a7778: add USB support
In-Reply-To: <201305010309.07744.sergei.shtylyov@cogentembedded.com>
References: <201305010309.07744.sergei.shtylyov@cogentembedded.com>
Message-ID: <201305010313.02992.sergei.shtylyov@cogentembedded.com>

Add USB clock and EHCI, OHCI, and USB PHY platform devices for R8A7778 SoC;  add
a function to register PHY device with board-specific platform data and register
EHCI and OHCI platfrom devices from the init_late() board method.

Also,  don't forget to enable CONFIG_ARCH_HAS_[EO]HCI options for R8A7778 SoC in
Kconfig...

The patch has been tested on the BOCK-W board.

Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

---
Changes since version 5:
- renamed the R-Car PHY driver header file in #include.

Changes since version 4:
- annotated USB resources and '[eo]hci_info' as '__initdata' since they're
  kmemdup()'ed while registering the platform devices anyway;
- refreshed the patch.

Changes since version 3:
- resolved reject in the 'clock-r8a7778.c' file, refreshed the patch.

Changes since version 2:
- refreshed the patch.

Changes since the original posting:
- resolved rejects in the 'clock-r8a7778.c' file;
- lowercased the SoC name in the subject.

 arch/arm/mach-shmobile/Kconfig                |    2 
 arch/arm/mach-shmobile/clock-r8a7778.c        |    4 
 arch/arm/mach-shmobile/include/mach/r8a7778.h |    3 
 arch/arm/mach-shmobile/setup-r8a7778.c        |  108 ++++++++++++++++++++++++++
 4 files changed, 117 insertions(+)

Index: renesas/arch/arm/mach-shmobile/Kconfig
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/Kconfig
+++ renesas/arch/arm/mach-shmobile/Kconfig
@@ -41,6 +41,8 @@ config ARCH_R8A7778
 	select CPU_V7
 	select SH_CLK_CPG
 	select ARM_GIC
+	select USB_ARCH_HAS_EHCI
+	select USB_ARCH_HAS_OHCI
 
 config ARCH_R8A7779
 	bool "R-Car H1 (R8A77790)"
Index: renesas/arch/arm/mach-shmobile/clock-r8a7778.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/clock-r8a7778.c
+++ renesas/arch/arm/mach-shmobile/clock-r8a7778.c
@@ -105,6 +105,7 @@ static struct clk *main_clks[] = {
 enum {
 	MSTP323, MSTP322, MSTP321,
 	MSTP114,
+	MSTP100,
 	MSTP026, MSTP025, MSTP024, MSTP023, MSTP022, MSTP021,
 	MSTP016, MSTP015,
 	MSTP_NR };
@@ -114,6 +115,7 @@ static struct clk mstp_clks[MSTP_NR] = {
 	[MSTP322] = SH_CLK_MSTP32(&p_clk, MSTPCR3, 22, 0), /* SDHI1 */
 	[MSTP321] = SH_CLK_MSTP32(&p_clk, MSTPCR3, 21, 0), /* SDHI2 */
 	[MSTP114] = SH_CLK_MSTP32(&p_clk, MSTPCR1, 14, 0), /* Ether */
+	[MSTP100] = SH_CLK_MSTP32(&p_clk, MSTPCR1,  0, 0), /* USB0/1 */
 	[MSTP026] = SH_CLK_MSTP32(&p_clk, MSTPCR0, 26, 0), /* SCIF0 */
 	[MSTP025] = SH_CLK_MSTP32(&p_clk, MSTPCR0, 25, 0), /* SCIF1 */
 	[MSTP024] = SH_CLK_MSTP32(&p_clk, MSTPCR0, 24, 0), /* SCIF2 */
@@ -130,6 +132,8 @@ static struct clk_lookup lookups[] = {
 	CLKDEV_DEV_ID("sh_mobile_sdhi.1", &mstp_clks[MSTP322]), /* SDHI1 */
 	CLKDEV_DEV_ID("sh_mobile_sdhi.2", &mstp_clks[MSTP321]), /* SDHI2 */
 	CLKDEV_DEV_ID("sh-eth",	&mstp_clks[MSTP114]), /* Ether */
+	CLKDEV_DEV_ID("ehci-platform", &mstp_clks[MSTP100]), /* USB EHCI port0/1 */
+	CLKDEV_DEV_ID("ohci-platform", &mstp_clks[MSTP100]), /* USB OHCI port0/1 */
 	CLKDEV_DEV_ID("sh-sci.0", &mstp_clks[MSTP026]), /* SCIF0 */
 	CLKDEV_DEV_ID("sh-sci.1", &mstp_clks[MSTP025]), /* SCIF1 */
 	CLKDEV_DEV_ID("sh-sci.2", &mstp_clks[MSTP024]), /* SCIF2 */
Index: renesas/arch/arm/mach-shmobile/include/mach/r8a7778.h
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/include/mach/r8a7778.h
+++ renesas/arch/arm/mach-shmobile/include/mach/r8a7778.h
@@ -20,10 +20,13 @@
 
 #include <linux/mmc/sh_mobile_sdhi.h>
 #include <linux/sh_eth.h>
+#include <linux/platform_data/usb-rcar-phy.h>
 
 extern void r8a7778_add_standard_devices(void);
 extern void r8a7778_add_standard_devices_dt(void);
 extern void r8a7778_add_ether_device(struct sh_eth_plat_data *pdata);
+extern void r8a7778_add_usb_phy_device(struct rcar_phy_platform_data *pdata);
+extern void r8a7778_init_late(void);
 extern void r8a7778_init_delay(void);
 extern void r8a7778_init_irq(void);
 extern void r8a7778_init_irq_dt(void);
Index: renesas/arch/arm/mach-shmobile/setup-r8a7778.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/setup-r8a7778.c
+++ renesas/arch/arm/mach-shmobile/setup-r8a7778.c
@@ -30,6 +30,12 @@
 #include <linux/irqchip.h>
 #include <linux/serial_sci.h>
 #include <linux/sh_timer.h>
+#include <linux/pm_runtime.h>
+#include <linux/usb/phy.h>
+#include <linux/usb/hcd.h>
+#include <linux/usb/ehci_pdriver.h>
+#include <linux/usb/ohci_pdriver.h>
+#include <linux/dma-mapping.h>
 #include <mach/irqs.h>
 #include <mach/r8a7778.h>
 #include <mach/common.h>
@@ -89,6 +95,99 @@ static struct sh_timer_config sh_tmu1_pl
 		&sh_tmu##idx##_platform_data,		\
 		sizeof(sh_tmu##idx##_platform_data))
 
+/* USB PHY */
+static struct resource usb_phy_resources[] __initdata = {
+	DEFINE_RES_MEM(0xffe70800, 0x100),
+	DEFINE_RES_MEM(0xffe76000, 0x100),
+};
+
+void __init r8a7778_add_usb_phy_device(struct rcar_phy_platform_data *pdata)
+{
+	platform_device_register_resndata(&platform_bus, "rcar_usb_phy", -1,
+					  usb_phy_resources,
+					  ARRAY_SIZE(usb_phy_resources),
+					  pdata, sizeof(*pdata));
+}
+
+/* USB */
+static struct usb_phy *phy;
+
+static int usb_power_on(struct platform_device *pdev)
+{
+	if (!phy)
+		return -EIO;
+
+	pm_runtime_enable(&pdev->dev);
+	pm_runtime_get_sync(&pdev->dev);
+
+	usb_phy_init(phy);
+
+	return 0;
+}
+
+static void usb_power_off(struct platform_device *pdev)
+{
+	if (!phy)
+		return;
+
+	usb_phy_shutdown(phy);
+
+	pm_runtime_put_sync(&pdev->dev);
+	pm_runtime_disable(&pdev->dev);
+}
+
+static int ehci_init_internal_buffer(struct usb_hcd *hcd)
+{
+	/*
+	 * Below are recommended values from the datasheet;
+	 * see [USB :: Setting of EHCI Internal Buffer].
+	 */
+	/* EHCI IP internal buffer setting */
+	iowrite32(0x00ff0040, hcd->regs + 0x0094);
+	/* EHCI IP internal buffer enable */
+	iowrite32(0x00000001, hcd->regs + 0x009C);
+
+	return 0;
+}
+
+static struct usb_ehci_pdata ehci_pdata __initdata = {
+	.power_on	= usb_power_on,
+	.power_off	= usb_power_off,
+	.power_suspend	= usb_power_off,
+	.pre_setup	= ehci_init_internal_buffer,
+};
+
+static struct resource ehci_resources[] __initdata = {
+	DEFINE_RES_MEM(0xffe70000, 0x400),
+	DEFINE_RES_IRQ(gic_iid(0x4c)),
+};
+
+static struct usb_ohci_pdata ohci_pdata __initdata = {
+	.power_on	= usb_power_on,
+	.power_off	= usb_power_off,
+	.power_suspend	= usb_power_off,
+};
+
+static struct resource ohci_resources[] __initdata = {
+	DEFINE_RES_MEM(0xffe70400, 0x400),
+	DEFINE_RES_IRQ(gic_iid(0x4c)),
+};
+
+#define USB_PLATFORM_INFO(hci)					\
+static struct platform_device_info hci##_info __initdata = {	\
+	.parent		= &platform_bus,			\
+	.name		= #hci "-platform",			\
+	.id		= -1,					\
+	.res		= hci##_resources,			\
+	.num_res	= ARRAY_SIZE(hci##_resources),		\
+	.data		= &hci##_pdata,				\
+	.size_data	= sizeof(hci##_pdata),			\
+	.dma_mask	= DMA_BIT_MASK(32),			\
+}
+
+USB_PLATFORM_INFO(ehci);
+USB_PLATFORM_INFO(ohci);
+
 /* Ether */
 static struct resource ether_resources[] = {
 	DEFINE_RES_MEM(0xfde00000, 0x400),
@@ -197,6 +296,14 @@ void __init r8a7778_add_standard_devices
 	r8a7778_register_tmu(1);
 }
 
+void __init r8a7778_init_late(void)
+{
+	phy = usb_get_phy(USB_PHY_TYPE_USB2);
+
+	platform_device_register_full(&ehci_info);
+	platform_device_register_full(&ohci_info);
+}
+
 static struct renesas_intc_irqpin_config irqpin_platform_data = {
 	.irq_base = irq_pin(0), /* IRQ0 -> IRQ3 */
 	.sense_bitfield_width = 2,
@@ -310,6 +417,7 @@ DT_MACHINE_START(R8A7778_DT, "Generic R8
 	.init_machine	= r8a7778_add_standard_devices_dt,
 	.init_time	= shmobile_timer_init,
 	.dt_compat	= r8a7778_compat_dt,
+	.init_late      = r8a7778_init_late,
 MACHINE_END
 
 #endif /* CONFIG_USE_OF */



From sergei.shtylyov at cogentembedded.com  Tue Apr 30 19:14:31 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Wed, 1 May 2013 03:14:31 +0400
Subject: [PATCH v6 3/3] ARM: shmobile: BOCK-W: add USB support
In-Reply-To: <201305010309.07744.sergei.shtylyov@cogentembedded.com>
References: <201305010309.07744.sergei.shtylyov@cogentembedded.com>
Message-ID: <201305010314.32153.sergei.shtylyov@cogentembedded.com>

Register the USB PHY device from bockw_init(), passing the platform  data to it.
Set machine's init_late() method to r8a7778_init_late() in order for [EO]HCI to
get registered too...

The patch has been tested on the BOCK-W board.

Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

---
Changes since version 4:
- annotated 'usb_phy_platform_data' as '__initdata' since it's kmemdup()'ed
  while registering the platform device anyway;
- refreshed the patch.

Changes since version 3:
- removed initializer for 'usb_phy_platform_data' letting it be set to all 0s;
- refreshed the patch.

Changes since version 2:
- refreshed the patch.

Changes since the original posting:
- removed initializer for no longer existing field in 'usb_phy_platform_data',
  modified the comment to the 'ferrite_bead' field initializer.

 arch/arm/mach-shmobile/board-bockw.c |    4 ++++
 1 file changed, 4 insertions(+)

Index: renesas/arch/arm/mach-shmobile/board-bockw.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/board-bockw.c
+++ renesas/arch/arm/mach-shmobile/board-bockw.c
@@ -63,6 +63,8 @@ static struct sh_mobile_sdhi_info sdhi0_
 	.tmio_flags	= TMIO_MMC_HAS_IDLE_WAIT,
 };
 
+static struct rcar_phy_platform_data usb_phy_platform_data __initdata;
+
 static const struct pinctrl_map bockw_pinctrl_map[] = {
 	/* SCIF0 */
 	PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.0", "pfc-r8a7778",
@@ -91,6 +93,7 @@ static void __init bockw_init(void)
 	r8a7778_clock_init();
 	r8a7778_init_irq_extpin(1);
 	r8a7778_add_standard_devices();
+	r8a7778_add_usb_phy_device(&usb_phy_platform_data);
 
 	pinctrl_register_mappings(bockw_pinctrl_map,
 				  ARRAY_SIZE(bockw_pinctrl_map));
@@ -146,4 +149,5 @@ DT_MACHINE_START(BOCKW_DT, "bockw")
 	.init_machine	= bockw_init,
 	.init_time	= shmobile_timer_init,
 	.dt_compat	= bockw_boards_compat_dt,
+	.init_late      = r8a7778_init_late,
 MACHINE_END



From tony at atomide.com  Tue Apr 30 19:51:48 2013
From: tony at atomide.com (Tony Lindgren)
Date: Tue, 30 Apr 2013 16:51:48 -0700
Subject: Latest build results - errors/warnings - lots of them
In-Reply-To: <201305010111.14247.arnd@arndb.de>
References: <20130430081739.GP14496@n2100.arm.linux.org.uk>
 <201305010111.14247.arnd@arndb.de>
Message-ID: <20130430235147.GG28721@atomide.com>

* Arnd Bergmann <arnd at arndb.de> [130430 16:16]:
> 
> I've uploaded this to the test-merge-20130430 branch in the arm-soc
> tree if anyone is curious. I suppose we should get all the changes
> in arch/arm included in the merge window and then work with the
> subsystem maintainers on the other bugs.

>  arch/arm/mach-omap2/Kconfig                   | 133 +++++++++++++-------------
>  arch/arm/mach-omap2/Makefile                  |   8 +-

Nice, I like your changes to flip ARCH_OMAP2PLUS to be selected
by the SoC. That's a better way to fix things than just tinkering
with the Makefile like I posted earlier today.

Now you have SOC_OMAP5 selected twice in omap2plus_defconfig though,
which causes:

.config:283:warning: override: reassigning to symbol SOC_OMAP5

For the SERIAL_OMAP change, let's just use my earlier patch
"ARM: OMAP2+: Fix unmet direct dependencies for SERIAL_OMAP".
We should not select optional drivers at all in Kconfig.

Regards,

Tony


From soren.brinkmann at xilinx.com  Tue Apr 30 19:57:57 2013
From: soren.brinkmann at xilinx.com (Soren Brinkmann)
Date: Tue, 30 Apr 2013 16:57:57 -0700
Subject: [PATCH 0/7] Zynq: revised CCF code
Message-ID: <1367366284-28304-1-git-send-email-soren.brinkmann@xilinx.com>

This is a first shot a revised version of Zynq's CCF code.
This should model the whole clock tree and support clock gating for all
relevant clocks.

This follows Tegra and other ARM SOCs in containing the clock tree
within a single block, which in this case is simply named clock
controller.

The patch is based on the current Linus tree + armsoc/zynq/smp. A
branch for testing is available on github:
https://github.com/sorenb-xlnx/linux-xlnx/tree/zynq/clkc

ps: I hope this thread comes through fine. Corporate email is unwilling
to cooperate and I have to jump through some hoops. My testmail went
through fine though.

	S?ren

Soren Brinkmann (7):
  tty: xuartps: Sort #includes alphabetically
  tty: xuartps: Remove suspend/resume functions
  clocksource/cadence_ttc: Sort #includes alphabetically
  clk: zynq: Factor out PLL driver
  clk: zynq: Add clock controller driver
  arm: zynq: Migrate platform to clock controller
  clk: zynq: Remove deprecated clock code

 .../devicetree/bindings/clock/zynq-7000.txt        | 127 +++--
 arch/arm/boot/dts/zynq-7000.dtsi                   |  71 +--
 arch/arm/boot/dts/zynq-zc702.dts                   |   4 -
 arch/arm/mach-zynq/slcr.c                          |   2 +-
 drivers/clk/Makefile                               |   2 +-
 drivers/clk/clk-zynq.c                             | 378 ---------------
 drivers/clk/zynq/Makefile                          |   3 +
 drivers/clk/zynq/clkc.c                            | 533 +++++++++++++++++++++
 drivers/clk/zynq/pll.c                             | 235 +++++++++
 drivers/clocksource/cadence_ttc_timer.c            |  27 +-
 drivers/tty/serial/xilinx_uartps.c                 | 127 ++---
 include/linux/clk/zynq.h                           |   8 +-
 12 files changed, 982 insertions(+), 535 deletions(-)
 delete mode 100644 drivers/clk/clk-zynq.c
 create mode 100644 drivers/clk/zynq/Makefile
 create mode 100644 drivers/clk/zynq/clkc.c
 create mode 100644 drivers/clk/zynq/pll.c

-- 
1.8.2.2



From soren.brinkmann at xilinx.com  Tue Apr 30 19:57:58 2013
From: soren.brinkmann at xilinx.com (Soren Brinkmann)
Date: Tue, 30 Apr 2013 16:57:58 -0700
Subject: [PATCH 1/7] tty: xuartps: Sort #includes alphabetically
In-Reply-To: <1367366284-28304-1-git-send-email-soren.brinkmann@xilinx.com>
References: <1367366284-28304-1-git-send-email-soren.brinkmann@xilinx.com>
Message-ID: <1367366284-28304-2-git-send-email-soren.brinkmann@xilinx.com>

Signed-off-by: Soren Brinkmann <soren.brinkmann at xilinx.com>
CC: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
CC: Jiri Slaby <jslaby at suse.cz>
CC: linux-serial at vger.kernel.org
---
 drivers/tty/serial/xilinx_uartps.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/tty/serial/xilinx_uartps.c b/drivers/tty/serial/xilinx_uartps.c
index 4e5c778..773732b 100644
--- a/drivers/tty/serial/xilinx_uartps.c
+++ b/drivers/tty/serial/xilinx_uartps.c
@@ -11,17 +11,17 @@
  *
  */
 
+#include <linux/clk.h>
+#include <linux/console.h>
+#include <linux/io.h>
+#include <linux/irq.h>
+#include <linux/module.h>
+#include <linux/of.h>
 #include <linux/platform_device.h>
 #include <linux/serial.h>
 #include <linux/serial_core.h>
 #include <linux/tty.h>
 #include <linux/tty_flip.h>
-#include <linux/console.h>
-#include <linux/clk.h>
-#include <linux/irq.h>
-#include <linux/io.h>
-#include <linux/of.h>
-#include <linux/module.h>
 
 #define XUARTPS_TTY_NAME	"ttyPS"
 #define XUARTPS_NAME		"xuartps"
-- 
1.8.2.2



From soren.brinkmann at xilinx.com  Tue Apr 30 19:57:59 2013
From: soren.brinkmann at xilinx.com (Soren Brinkmann)
Date: Tue, 30 Apr 2013 16:57:59 -0700
Subject: [PATCH 2/7] tty: xuartps: Remove suspend/resume functions
In-Reply-To: <1367366284-28304-1-git-send-email-soren.brinkmann@xilinx.com>
References: <1367366284-28304-1-git-send-email-soren.brinkmann@xilinx.com>
Message-ID: <1367366284-28304-3-git-send-email-soren.brinkmann@xilinx.com>

Currently Zynq does not support suspend/resume.
The driver callbacks are never used or tested, broken and using the old
PM interface.

Signed-off-by: Soren Brinkmann <soren.brinkmann at xilinx.com>
Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
Cc: Jiri Slaby <jslaby at suse.cz>
Cc: linux-serial at vger.kernel.org
---
 drivers/tty/serial/xilinx_uartps.c | 30 ------------------------------
 1 file changed, 30 deletions(-)

diff --git a/drivers/tty/serial/xilinx_uartps.c b/drivers/tty/serial/xilinx_uartps.c
index 773732b..04a1f8f 100644
--- a/drivers/tty/serial/xilinx_uartps.c
+++ b/drivers/tty/serial/xilinx_uartps.c
@@ -1006,34 +1006,6 @@ static int xuartps_remove(struct platform_device *pdev)
 	return rc;
 }
 
-/**
- * xuartps_suspend - suspend event
- * @pdev: Pointer to the platform device structure
- * @state: State of the device
- *
- * Returns 0
- **/
-static int xuartps_suspend(struct platform_device *pdev, pm_message_t state)
-{
-	/* Call the API provided in serial_core.c file which handles
-	 * the suspend.
-	 */
-	uart_suspend_port(&xuartps_uart_driver, &xuartps_port[pdev->id]);
-	return 0;
-}
-
-/**
- * xuartps_resume - Resume after a previous suspend
- * @pdev: Pointer to the platform device structure
- *
- * Returns 0
- **/
-static int xuartps_resume(struct platform_device *pdev)
-{
-	uart_resume_port(&xuartps_uart_driver, &xuartps_port[pdev->id]);
-	return 0;
-}
-
 /* Match table for of_platform binding */
 static struct of_device_id xuartps_of_match[] = {
 	{ .compatible = "xlnx,xuartps", },
@@ -1044,8 +1016,6 @@ MODULE_DEVICE_TABLE(of, xuartps_of_match);
 static struct platform_driver xuartps_platform_driver = {
 	.probe   = xuartps_probe,		/* Probe method */
 	.remove  = xuartps_remove,		/* Detach method */
-	.suspend = xuartps_suspend,		/* Suspend */
-	.resume  = xuartps_resume,		/* Resume after a suspend */
 	.driver  = {
 		.owner = THIS_MODULE,
 		.name = XUARTPS_NAME,		/* Driver name */
-- 
1.8.2.2



From soren.brinkmann at xilinx.com  Tue Apr 30 19:58:01 2013
From: soren.brinkmann at xilinx.com (Soren Brinkmann)
Date: Tue, 30 Apr 2013 16:58:01 -0700
Subject: [PATCH 4/7] clk: zynq: Factor out PLL driver
In-Reply-To: <1367366284-28304-1-git-send-email-soren.brinkmann@xilinx.com>
References: <1367366284-28304-1-git-send-email-soren.brinkmann@xilinx.com>
Message-ID: <1367366284-28304-5-git-send-email-soren.brinkmann@xilinx.com>

Refactor the PLL driver so it works with the clock controller driver.

Signed-off-by: Soren Brinkmann <soren.brinkmann at xilinx.com>
---
 drivers/clk/zynq/pll.c | 235 +++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 235 insertions(+)
 create mode 100644 drivers/clk/zynq/pll.c

diff --git a/drivers/clk/zynq/pll.c b/drivers/clk/zynq/pll.c
new file mode 100644
index 0000000..47e307c
--- /dev/null
+++ b/drivers/clk/zynq/pll.c
@@ -0,0 +1,235 @@
+/*
+ * Zynq PLL driver
+ *
+ *  Copyright (C) 2013 Xilinx
+ *
+ *  S?ren Brinkmann <soren.brinkmann at xilinx.com>
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License v2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
+ *
+ */
+#include <linux/clk/zynq.h>
+#include <linux/clk-provider.h>
+#include <linux/slab.h>
+#include <linux/io.h>
+
+/**
+ * struct zynq_pll
+ * @hw:		Handle between common and hardware-specific interfaces
+ * @pll_ctrl:	PLL control register
+ * @pll_status:	PLL status register
+ * @lock:	Register lock
+ * @lockbit:	Indicates the associated PLL_LOCKED bit in the PLL status
+ *		register.
+ */
+struct zynq_pll {
+	struct clk_hw	hw;
+	void __iomem	*pll_ctrl;
+	void __iomem	*pll_status;
+	spinlock_t	*lock;
+	u8		lockbit;
+};
+#define to_zynq_pll(_hw)	container_of(_hw, struct zynq_pll, hw)
+
+/* Register bitfield defines */
+#define PLLCTRL_FBDIV_MASK	0x7f000
+#define PLLCTRL_FBDIV_SHIFT	12
+#define PLLCTRL_BPQUAL_MASK	(1 << 3)
+#define PLLCTRL_PWRDWN_MASK	2
+#define PLLCTRL_PWRDWN_SHIFT	1
+#define PLLCTRL_RESET_MASK	1
+#define PLLCTRL_RESET_SHIFT	0
+
+/**
+ * zynq_pll_round_rate() - Round a clock frequency
+ * @hw:		Handle between common and hardware-specific interfaces
+ * @rate:	Desired clock frequency
+ * @prate:	Clock frequency of parent clock
+ * Returns frequency closest to @rate the hardware can generate.
+ */
+static long zynq_pll_round_rate(struct clk_hw *hw, unsigned long rate,
+		unsigned long *prate)
+{
+	u32 fbdiv;
+
+	fbdiv = DIV_ROUND_CLOSEST(rate, *prate);
+	if (fbdiv < 13)
+		fbdiv = 13;
+	else if (fbdiv > 66)
+		fbdiv = 66;
+
+	return *prate * fbdiv;
+}
+
+/**
+ * zynq_pll_recalc_rate() - Recalculate clock frequency
+ * @hw:			Handle between common and hardware-specific interfaces
+ * @parent_rate:	Clock frequency of parent clock
+ * Returns current clock frequency.
+ */
+static unsigned long zynq_pll_recalc_rate(struct clk_hw *hw,
+		unsigned long parent_rate)
+{
+	struct zynq_pll *clk = to_zynq_pll(hw);
+	u32 fbdiv;
+
+	/*
+	 * makes probably sense to redundantly save fbdiv in the struct
+	 * zynq_pll to save the IO access.
+	 */
+	fbdiv = (readl(clk->pll_ctrl) & PLLCTRL_FBDIV_MASK) >>
+			PLLCTRL_FBDIV_SHIFT;
+
+	return parent_rate * fbdiv;
+}
+
+/**
+ * zynq_pll_is_enabled - Check if a clock is enabled
+ * @hw:		Handle between common and hardware-specific interfaces
+ * Returns 1 if the clock is enabled, 0 otherwise.
+ *
+ * Not sure this is a good idea, but since disabled means bypassed for
+ * this clock implementation we say we are always enabled.
+ */
+static int zynq_pll_is_enabled(struct clk_hw *hw)
+{
+	unsigned long flags = 0;
+	u32 reg;
+	struct zynq_pll *clk = to_zynq_pll(hw);
+
+	spin_lock_irqsave(clk->lock, flags);
+
+	reg = readl(clk->pll_ctrl);
+
+	spin_unlock_irqrestore(clk->lock, flags);
+
+	return !(reg & (PLLCTRL_RESET_MASK | PLLCTRL_PWRDWN_MASK));
+}
+
+/**
+ * zynq_pll_enable - Enable clock
+ * @hw:		Handle between common and hardware-specific interfaces
+ * Returns 0 on success
+ */
+static int zynq_pll_enable(struct clk_hw *hw)
+{
+	unsigned long flags = 0;
+	u32 reg;
+	struct zynq_pll *clk = to_zynq_pll(hw);
+
+	if (zynq_pll_is_enabled(hw))
+		return 0;
+
+	pr_info("PLL: enable\n");
+
+	/* Power up PLL and wait for lock */
+	spin_lock_irqsave(clk->lock, flags);
+
+	reg = readl(clk->pll_ctrl);
+	reg &= ~(PLLCTRL_RESET_MASK | PLLCTRL_PWRDWN_MASK);
+	writel(reg, clk->pll_ctrl);
+	while (!(readl(clk->pll_status) & (1 << clk->lockbit)))
+		;
+
+	spin_unlock_irqrestore(clk->lock, flags);
+
+	return 0;
+}
+
+/**
+ * zynq_pll_disable - Disable clock
+ * @hw:		Handle between common and hardware-specific interfaces
+ * Returns 0 on success
+ */
+static void zynq_pll_disable(struct clk_hw *hw)
+{
+	unsigned long flags = 0;
+	u32 reg;
+	struct zynq_pll *clk = to_zynq_pll(hw);
+
+	if (!zynq_pll_is_enabled(hw))
+		return;
+
+	pr_info("PLL: shutdown\n");
+
+	/* shut down PLL */
+	spin_lock_irqsave(clk->lock, flags);
+
+	reg = readl(clk->pll_ctrl);
+	reg |= PLLCTRL_RESET_MASK | PLLCTRL_PWRDWN_MASK;
+	writel(reg, clk->pll_ctrl);
+
+	spin_unlock_irqrestore(clk->lock, flags);
+}
+
+static const struct clk_ops zynq_pll_ops = {
+	.enable = zynq_pll_enable,
+	.disable = zynq_pll_disable,
+	.is_enabled = zynq_pll_is_enabled,
+	.round_rate = zynq_pll_round_rate,
+	.recalc_rate = zynq_pll_recalc_rate
+};
+
+/**
+ * clk_register_zynq_pll() - Register PLL with the clock framework
+ * @np	Pointer to the DT device node
+ */
+struct clk *clk_register_zynq_pll(const char *name, const char *parent,
+		void __iomem *pll_ctrl, void __iomem *pll_status, u8 lock_index,
+		spinlock_t *lock)
+{
+	struct zynq_pll *pll;
+	struct clk *clk;
+	u32 reg;
+	const char *parent_arr[1] = {parent};
+	unsigned long flags = 0;
+	struct clk_init_data initd = {
+		.name = name,
+		.parent_names = parent_arr,
+		.ops = &zynq_pll_ops,
+		.num_parents = 1,
+		.flags = 0
+	};
+
+	pll = kmalloc(sizeof(*pll), GFP_KERNEL);
+	if (!pll) {
+		pr_err("%s: Could not allocate Zynq PLL clk.\n", __func__);
+		return ERR_PTR(-ENOMEM);
+	}
+
+	/* Populate the struct */
+	pll->hw.init = &initd;
+	pll->pll_ctrl = pll_ctrl;
+	pll->pll_status = pll_status;
+	pll->lockbit = lock_index;
+	pll->lock = lock;
+
+	spin_lock_irqsave(pll->lock, flags);
+
+	reg = readl(pll->pll_ctrl);
+	reg &= ~PLLCTRL_BPQUAL_MASK;
+	writel(reg, pll->pll_ctrl);
+
+	spin_unlock_irqrestore(pll->lock, flags);
+
+	clk = clk_register(NULL, &pll->hw);
+	if (WARN_ON(IS_ERR(clk)))
+		goto free_pll;
+
+	return clk;
+
+free_pll:
+	kfree(pll);
+
+	return clk;
+}
-- 
1.8.2.2



From soren.brinkmann at xilinx.com  Tue Apr 30 19:58:00 2013
From: soren.brinkmann at xilinx.com (Soren Brinkmann)
Date: Tue, 30 Apr 2013 16:58:00 -0700
Subject: [PATCH 3/7] clocksource/cadence_ttc: Sort #includes alphabetically
In-Reply-To: <1367366284-28304-1-git-send-email-soren.brinkmann@xilinx.com>
References: <1367366284-28304-1-git-send-email-soren.brinkmann@xilinx.com>
Message-ID: <1367366284-28304-4-git-send-email-soren.brinkmann@xilinx.com>

Signed-off-by: Soren Brinkmann <soren.brinkmann at xilinx.com>
Cc: John Stultz <john.stultz at linaro.org>
Cc: Thomas Gleixner <tglx at linutronix.de>
---
 drivers/clocksource/cadence_ttc_timer.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/clocksource/cadence_ttc_timer.c b/drivers/clocksource/cadence_ttc_timer.c
index 685bc60..ab8fc2c 100644
--- a/drivers/clocksource/cadence_ttc_timer.c
+++ b/drivers/clocksource/cadence_ttc_timer.c
@@ -16,12 +16,12 @@
  */
 
 #include <linux/clk.h>
-#include <linux/interrupt.h>
+#include <linux/clk-provider.h>
 #include <linux/clockchips.h>
+#include <linux/interrupt.h>
 #include <linux/of_address.h>
 #include <linux/of_irq.h>
 #include <linux/slab.h>
-#include <linux/clk-provider.h>
 
 /*
  * This driver configures the 2 16-bit count-up timers as follows:
-- 
1.8.2.2



From soren.brinkmann at xilinx.com  Tue Apr 30 19:58:03 2013
From: soren.brinkmann at xilinx.com (Soren Brinkmann)
Date: Tue, 30 Apr 2013 16:58:03 -0700
Subject: [PATCH 6/7] arm: zynq: Migrate platform to clock controller
In-Reply-To: <1367366284-28304-1-git-send-email-soren.brinkmann@xilinx.com>
References: <1367366284-28304-1-git-send-email-soren.brinkmann@xilinx.com>
Message-ID: <1367366284-28304-7-git-send-email-soren.brinkmann@xilinx.com>

Migrate the Zynq platform and its drivers to use the new clock
controller driver.

Signed-off-by: Soren Brinkmann <soren.brinkmann at xilinx.com>
Cc: John Stultz <john.stultz at linaro.org>
Cc: Thomas Gleixner <tglx at linutronix.de>
Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
Cc: Jiri Slaby <jslaby at suse.cz>
Cc: linux-serial at vger.kernel.org
---
 arch/arm/boot/dts/zynq-7000.dtsi        | 71 ++++++++-------------------
 arch/arm/boot/dts/zynq-zc702.dts        |  4 --
 arch/arm/mach-zynq/slcr.c               |  2 +-
 drivers/clk/Makefile                    |  2 +-
 drivers/clk/zynq/Makefile               |  3 ++
 drivers/clocksource/cadence_ttc_timer.c | 23 +++++++--
 drivers/tty/serial/xilinx_uartps.c      | 85 ++++++++++++++++++++++++++-------
 include/linux/clk/zynq.h                |  8 +++-
 8 files changed, 118 insertions(+), 80 deletions(-)
 create mode 100644 drivers/clk/zynq/Makefile

diff --git a/arch/arm/boot/dts/zynq-7000.dtsi b/arch/arm/boot/dts/zynq-7000.dtsi
index 2a1df1b..5337554 100644
--- a/arch/arm/boot/dts/zynq-7000.dtsi
+++ b/arch/arm/boot/dts/zynq-7000.dtsi
@@ -42,16 +42,18 @@
 
 		uart0: uart at e0000000 {
 			compatible = "xlnx,xuartps";
+			clocks = <&clkc 23>, <&clkc 40>;
+			clock-names = "ref_clk", "aper_clk";
 			reg = <0xE0000000 0x1000>;
 			interrupts = <0 27 4>;
-			clocks = <&uart_clk 0>;
 		};
 
 		uart1: uart at e0001000 {
 			compatible = "xlnx,xuartps";
+			clocks = <&clkc 24>, <&clkc 41>;
+			clock-names = "ref_clk", "aper_clk";
 			reg = <0xE0001000 0x1000>;
 			interrupts = <0 50 4>;
-			clocks = <&uart_clk 1>;
 		};
 
 		slcr: slcr at f8000000 {
@@ -62,50 +64,21 @@
 				#address-cells = <1>;
 				#size-cells = <0>;
 
-				ps_clk: ps_clk {
-					#clock-cells = <0>;
-					compatible = "fixed-clock";
-					/* clock-frequency set in board-specific file */
-					clock-output-names = "ps_clk";
-				};
-				armpll: armpll {
-					#clock-cells = <0>;
-					compatible = "xlnx,zynq-pll";
-					clocks = <&ps_clk>;
-					reg = <0x100 0x110>;
-					clock-output-names = "armpll";
-				};
-				ddrpll: ddrpll {
-					#clock-cells = <0>;
-					compatible = "xlnx,zynq-pll";
-					clocks = <&ps_clk>;
-					reg = <0x104 0x114>;
-					clock-output-names = "ddrpll";
-				};
-				iopll: iopll {
-					#clock-cells = <0>;
-					compatible = "xlnx,zynq-pll";
-					clocks = <&ps_clk>;
-					reg = <0x108 0x118>;
-					clock-output-names = "iopll";
-				};
-				uart_clk: uart_clk {
-					#clock-cells = <1>;
-					compatible = "xlnx,zynq-periph-clock";
-					clocks = <&iopll &armpll &ddrpll>;
-					reg = <0x154>;
-					clock-output-names = "uart0_ref_clk",
-							     "uart1_ref_clk";
-				};
-				cpu_clk: cpu_clk {
+				clkc: clkc {
 					#clock-cells = <1>;
-					compatible = "xlnx,zynq-cpu-clock";
-					clocks = <&iopll &armpll &ddrpll>;
-					reg = <0x120 0x1C4>;
-					clock-output-names = "cpu_6x4x",
-							     "cpu_3x2x",
-							     "cpu_2x",
-							     "cpu_1x";
+					compatible = "xlnx,ps7-clkc";
+					ps-clk-frequency = <33333333>;
+					clock-output-names = "armpll", "ddrpll", "iopll", "cpu_6or4x",
+							"cpu_3or2x", "cpu_2x", "cpu_1x", "ddr2x", "ddr3x",
+							"dci", "lqspi", "smc", "pcap", "gem0", "gem1",
+							"fclk0", "fclk1", "fclk2", "fclk3", "can0", "can1",
+							"sdio0", "sdio1", "uart0", "uart1", "spi0", "spi1",
+							"dma", "usb0_aper", "usb1_aper", "gem0_aper",
+							"gem1_aper", "sdio0_aper", "sdio1_aper",
+							"spi0_aper", "spi1_aper", "can0_aper", "can1_aper",
+							"i2c0_aper", "i2c1_aper", "uart0_aper", "uart1_aper",
+							"gpio_aper", "lqspi_aper", "smc_aper", "swdt",
+							"dbg_trc", "dbg_apb";
 				};
 			};
 		};
@@ -114,9 +87,8 @@
 			interrupt-parent = <&intc>;
 			interrupts = < 0 10 4 0 11 4 0 12 4 >;
 			compatible = "cdns,ttc";
+			clocks = <&clkc 6>;
 			reg = <0xF8001000 0x1000>;
-			clocks = <&cpu_clk 3>;
-			clock-names = "cpu_1x";
 			clock-ranges;
 		};
 
@@ -124,9 +96,8 @@
 			interrupt-parent = <&intc>;
 			interrupts = < 0 37 4 0 38 4 0 39 4 >;
 			compatible = "cdns,ttc";
+			clocks = <&clkc 6>;
 			reg = <0xF8002000 0x1000>;
-			clocks = <&cpu_clk 3>;
-			clock-names = "cpu_1x";
 			clock-ranges;
 		};
 		scutimer: scutimer at f8f00600 {
@@ -134,7 +105,7 @@
 			interrupts = < 1 13 0x301 >;
 			compatible = "arm,cortex-a9-twd-timer";
 			reg = < 0xf8f00600 0x20 >;
-			clocks = <&cpu_clk 1>;
+			clocks = <&clkc 4>;
 		} ;
 	};
 };
diff --git a/arch/arm/boot/dts/zynq-zc702.dts b/arch/arm/boot/dts/zynq-zc702.dts
index 86f44d5..e25a307 100644
--- a/arch/arm/boot/dts/zynq-zc702.dts
+++ b/arch/arm/boot/dts/zynq-zc702.dts
@@ -28,7 +28,3 @@
 	};
 
 };
-
-&ps_clk {
-	clock-frequency = <33333330>;
-};
diff --git a/arch/arm/mach-zynq/slcr.c b/arch/arm/mach-zynq/slcr.c
index c70969b..50d008d 100644
--- a/arch/arm/mach-zynq/slcr.c
+++ b/arch/arm/mach-zynq/slcr.c
@@ -117,7 +117,7 @@ int __init zynq_slcr_init(void)
 
 	pr_info("%s mapped to %p\n", np->name, zynq_slcr_base);
 
-	xilinx_zynq_clocks_init(zynq_slcr_base);
+	zynq_clock_init(zynq_slcr_base);
 
 	of_node_put(np);
 
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index e7f7fe9..addfd02 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -27,7 +27,7 @@ obj-$(CONFIG_MACH_LOONGSON1)	+= clk-ls1x.o
 obj-$(CONFIG_ARCH_SUNXI)	+= sunxi/
 obj-$(CONFIG_ARCH_U8500)	+= ux500/
 obj-$(CONFIG_ARCH_VT8500)	+= clk-vt8500.o
-obj-$(CONFIG_ARCH_ZYNQ)		+= clk-zynq.o
+obj-$(CONFIG_ARCH_ZYNQ)		+= zynq/
 obj-$(CONFIG_ARCH_TEGRA)	+= tegra/
 
 obj-$(CONFIG_X86)		+= x86/
diff --git a/drivers/clk/zynq/Makefile b/drivers/clk/zynq/Makefile
new file mode 100644
index 0000000..156d923
--- /dev/null
+++ b/drivers/clk/zynq/Makefile
@@ -0,0 +1,3 @@
+# Zynq clock specific Makefile
+
+obj-$(CONFIG_ARCH_ZYNQ)	+= clkc.o pll.o
diff --git a/drivers/clocksource/cadence_ttc_timer.c b/drivers/clocksource/cadence_ttc_timer.c
index ab8fc2c..6d961ad 100644
--- a/drivers/clocksource/cadence_ttc_timer.c
+++ b/drivers/clocksource/cadence_ttc_timer.c
@@ -51,6 +51,8 @@
 
 #define TTC_CNT_CNTRL_DISABLE_MASK	0x1
 
+#define TTC_CLK_CNTRL_CSRC_MASK		(1 << 5)	/* clock source */
+
 /*
  * Setup the timers to use pre-scaling, using a fixed value for now that will
  * work across most input frequency, but it may need to be more dynamic
@@ -396,8 +398,9 @@ static void __init ttc_timer_init(struct device_node *timer)
 {
 	unsigned int irq;
 	void __iomem *timer_baseaddr;
-	struct clk *clk;
+	struct clk *clk_cs, *clk_ce;
 	static int initialized;
+	int clksel;
 
 	if (initialized)
 		return;
@@ -421,14 +424,24 @@ static void __init ttc_timer_init(struct device_node *timer)
 		BUG();
 	}
 
-	clk = of_clk_get_by_name(timer, "cpu_1x");
-	if (IS_ERR(clk)) {
+	clksel = __raw_readl(timer_baseaddr + TTC_CLK_CNTRL_OFFSET);
+	clksel = !!(clksel & TTC_CLK_CNTRL_CSRC_MASK);
+	clk_cs = of_clk_get(timer, clksel);
+	if (IS_ERR(clk_cs)) {
+		pr_err("ERROR: timer input clock not found\n");
+		BUG();
+	}
+
+	clksel = __raw_readl(timer_baseaddr + 4 + TTC_CLK_CNTRL_OFFSET);
+	clksel = !!(clksel & TTC_CLK_CNTRL_CSRC_MASK);
+	clk_ce = of_clk_get(timer, clksel);
+	if (IS_ERR(clk_ce)) {
 		pr_err("ERROR: timer input clock not found\n");
 		BUG();
 	}
 
-	ttc_setup_clocksource(clk, timer_baseaddr);
-	ttc_setup_clockevent(clk, timer_baseaddr + 4, irq);
+	ttc_setup_clocksource(clk_cs, timer_baseaddr);
+	ttc_setup_clockevent(clk_ce, timer_baseaddr + 4, irq);
 
 	pr_info("%s #0 at %p, irq=%d\n", timer->name, timer_baseaddr, irq);
 }
diff --git a/drivers/tty/serial/xilinx_uartps.c b/drivers/tty/serial/xilinx_uartps.c
index 04a1f8f..d3fa947 100644
--- a/drivers/tty/serial/xilinx_uartps.c
+++ b/drivers/tty/serial/xilinx_uartps.c
@@ -20,6 +20,7 @@
 #include <linux/platform_device.h>
 #include <linux/serial.h>
 #include <linux/serial_core.h>
+#include <linux/slab.h>
 #include <linux/tty.h>
 #include <linux/tty_flip.h>
 
@@ -139,6 +140,16 @@
 #define XUARTPS_SR_RXTRIG	0x00000001 /* Rx Trigger */
 
 /**
+ * struct xuartps - device data
+ * @refclk	Reference clock
+ * @aperclk	APB clock
+ */
+struct xuartps {
+	struct clk		*refclk;
+	struct clk		*aperclk;
+};
+
+/**
  * xuartps_isr - Interrupt handler
  * @irq: Irq number
  * @dev_id: Id of the port
@@ -936,34 +947,55 @@ static int xuartps_probe(struct platform_device *pdev)
 	int rc;
 	struct uart_port *port;
 	struct resource *res, *res2;
-	struct clk *clk;
+	struct xuartps *xuartps_data;
 
-	clk = of_clk_get(pdev->dev.of_node, 0);
-	if (IS_ERR(clk)) {
-		dev_err(&pdev->dev, "no clock specified\n");
-		return PTR_ERR(clk);
+	xuartps_data = kzalloc(sizeof(*xuartps_data), GFP_KERNEL);
+	if (!xuartps_data)
+		return -ENOMEM;
+
+	xuartps_data->aperclk = clk_get(&pdev->dev, "aper_clk");
+	if (IS_ERR(xuartps_data->aperclk)) {
+		dev_err(&pdev->dev, "aper_clk clock not found.\n");
+		rc = PTR_ERR(xuartps_data->aperclk);
+		goto err_out_free;
+	}
+	xuartps_data->refclk = clk_get(&pdev->dev, "ref_clk");
+	if (IS_ERR(xuartps_data->refclk)) {
+		dev_err(&pdev->dev, "ref_clk clock not found.\n");
+		rc = PTR_ERR(xuartps_data->refclk);
+		goto err_out_clk_put_aper;
 	}
 
-	rc = clk_prepare_enable(clk);
+	rc = clk_prepare_enable(xuartps_data->aperclk);
+	if (rc) {
+		dev_err(&pdev->dev, "Unable to enable APER clock.\n");
+		goto err_out_clk_put;
+	}
+	rc = clk_prepare_enable(xuartps_data->refclk);
 	if (rc) {
-		dev_err(&pdev->dev, "could not enable clock\n");
-		return -EBUSY;
+		dev_err(&pdev->dev, "Unable to enable device clock.\n");
+		goto err_out_clk_dis_aper;
 	}
 
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-	if (!res)
-		return -ENODEV;
+	if (!res) {
+		rc = -ENODEV;
+		goto err_out_clk_disable;
+	}
 
 	res2 = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
-	if (!res2)
-		return -ENODEV;
+	if (!res2) {
+		rc = -ENODEV;
+		goto err_out_clk_disable;
+	}
 
 	/* Initialize the port structure */
 	port = xuartps_get_port();
 
 	if (!port) {
 		dev_err(&pdev->dev, "Cannot get uart_port structure\n");
-		return -ENODEV;
+		rc = -ENODEV;
+		goto err_out_clk_disable;
 	} else {
 		/* Register the port.
 		 * This function also registers this device with the tty layer
@@ -972,18 +1004,31 @@ static int xuartps_probe(struct platform_device *pdev)
 		port->mapbase = res->start;
 		port->irq = res2->start;
 		port->dev = &pdev->dev;
-		port->uartclk = clk_get_rate(clk);
-		port->private_data = clk;
+		port->uartclk = clk_get_rate(xuartps_data->refclk);
+		port->private_data = xuartps_data;
 		dev_set_drvdata(&pdev->dev, port);
 		rc = uart_add_one_port(&xuartps_uart_driver, port);
 		if (rc) {
 			dev_err(&pdev->dev,
 				"uart_add_one_port() failed; err=%i\n", rc);
 			dev_set_drvdata(&pdev->dev, NULL);
-			return rc;
+			goto err_out_clk_disable;
 		}
 		return 0;
 	}
+
+err_out_clk_disable:
+	clk_disable_unprepare(xuartps_data->refclk);
+err_out_clk_dis_aper:
+	clk_disable_unprepare(xuartps_data->aperclk);
+err_out_clk_put:
+	clk_put(xuartps_data->refclk);
+err_out_clk_put_aper:
+	clk_put(xuartps_data->aperclk);
+err_out_free:
+	kfree(xuartps_data);
+
+	return rc;
 }
 
 /**
@@ -995,14 +1040,18 @@ static int xuartps_probe(struct platform_device *pdev)
 static int xuartps_remove(struct platform_device *pdev)
 {
 	struct uart_port *port = dev_get_drvdata(&pdev->dev);
-	struct clk *clk = port->private_data;
+	struct xuartps *xuartps_data = port->private_data;
 	int rc;
 
 	/* Remove the xuartps port from the serial core */
 	rc = uart_remove_one_port(&xuartps_uart_driver, port);
 	dev_set_drvdata(&pdev->dev, NULL);
 	port->mapbase = 0;
-	clk_disable_unprepare(clk);
+	clk_disable_unprepare(xuartps_data->refclk);
+	clk_disable_unprepare(xuartps_data->aperclk);
+	clk_put(xuartps_data->refclk);
+	clk_put(xuartps_data->aperclk);
+	kfree(xuartps_data);
 	return rc;
 }
 
diff --git a/include/linux/clk/zynq.h b/include/linux/clk/zynq.h
index 56be7cd..e062d31 100644
--- a/include/linux/clk/zynq.h
+++ b/include/linux/clk/zynq.h
@@ -1,4 +1,5 @@
 /*
+ * Copyright (C) 2013 Xilinx Inc.
  * Copyright (C) 2012 National Instruments
  *
  * This program is free software; you can redistribute it and/or modify
@@ -19,6 +20,11 @@
 #ifndef __LINUX_CLK_ZYNQ_H_
 #define __LINUX_CLK_ZYNQ_H_
 
-void __init xilinx_zynq_clocks_init(void __iomem *slcr);
+#include <linux/spinlock.h>
 
+void zynq_clock_init(void __iomem *slcr);
+
+struct clk *clk_register_zynq_pll(const char *name, const char *parent,
+		void __iomem *pll_ctrl, void __iomem *pll_status, u8 lock_index,
+		spinlock_t *lock);
 #endif
-- 
1.8.2.2



From soren.brinkmann at xilinx.com  Tue Apr 30 19:58:02 2013
From: soren.brinkmann at xilinx.com (Soren Brinkmann)
Date: Tue, 30 Apr 2013 16:58:02 -0700
Subject: [PATCH 5/7] clk: zynq: Add clock controller driver
In-Reply-To: <1367366284-28304-1-git-send-email-soren.brinkmann@xilinx.com>
References: <1367366284-28304-1-git-send-email-soren.brinkmann@xilinx.com>
Message-ID: <1367366284-28304-6-git-send-email-soren.brinkmann@xilinx.com>

Add a clock controller driver and documentation.

Signed-off-by: Soren Brinkmann <soren.brinkmann at xilinx.com>
Cc: Grant Likely <grant.likely at linaro.org>
Cc: Rob Herring <rob.herring at calxeda.com>
Cc: Rob Landley <rob at landley.net>
Cc: devicetree-discuss at lists.ozlabs.org
Cc: linux-doc at vger.kernel.org
---
 .../devicetree/bindings/clock/zynq-7000.txt        |  98 ++++
 drivers/clk/zynq/clkc.c                            | 533 +++++++++++++++++++++
 2 files changed, 631 insertions(+)
 create mode 100644 drivers/clk/zynq/clkc.c

diff --git a/Documentation/devicetree/bindings/clock/zynq-7000.txt b/Documentation/devicetree/bindings/clock/zynq-7000.txt
index 23ae1db..30bfca9 100644
--- a/Documentation/devicetree/bindings/clock/zynq-7000.txt
+++ b/Documentation/devicetree/bindings/clock/zynq-7000.txt
@@ -6,6 +6,104 @@ The purpose of this document is to document their usage.
 See clock_bindings.txt for more information on the generic clock bindings.
 See Chapter 25 of Zynq TRM for more information about Zynq clocks.
 
+== Clock Controller ==
+The clock controller is a logical abstration of Zynq's clock tree. It reads
+required input clock frequencies from the devictree and acts as clock provider
+for all clock consumers of PS clocks.
+
+Required properties:
+ - #clock-cells : Must be 1
+ - compatible : "xlnx,ps7-clkc"
+ - ps-clk-frequency : Frequency of the oscillator providing ps_clk in HZ
+		      (usually 33 MHz oscillators are used for Zynq platforms)
+ - clock-output-names : List of strings used to name the clock outputs. Shall be
+			a list of the outputs given below.
+
+Optional properties:
+ - clocks : as described in the clock bindings
+ - clock-names : as described in the clock bindings
+
+Clock inputs:
+The following strings are optional parameters to the 'clock-names' property in
+order to provide an optional (E)MIO clock source.
+ - swdt_ext_clk
+ - gem0_emio_clk
+ - gem1_emio_clk
+ - mio_clk_XX		# with XX = 00..53
+...
+
+Clock outputs:
+ 0:  armpll
+ 1:  ddrpll
+ 2:  iopll
+ 3:  cpu_6or4x
+ 4:  cpu_3or2x
+ 5:  cpu_2x
+ 6:  cpu_1x
+ 7:  ddr2x
+ 8:  ddr3x
+ 9:  dci
+ 10: lqspi
+ 11: smc
+ 12: pcap
+ 13: gem0
+ 14: gem1
+ 15: fclk0
+ 16: fclk1
+ 17: fclk2
+ 18: fclk3
+ 19: can0
+ 20: can1
+ 21: sdio0
+ 22: sdio1
+ 23: uart0
+ 24: uart1
+ 25: spi0
+ 26: spi1
+ 27: dma
+ 28: usb0_aper
+ 29: usb1_aper
+ 30: gem0_aper
+ 31: gem1_aper
+ 32: sdio0_aper
+ 33: sdio1_aper
+ 34: spi0_aper
+ 35: spi1_aper
+ 36: can0_aper
+ 37: can1_aper
+ 38: i2c0_aper
+ 39: i2c1_aper
+ 40: uart0_aper
+ 41: uart1_aper
+ 42: gpio_aper
+ 43: lqspi_aper
+ 44: smc_aper
+ 45: swdt
+ 46: dbg_trc
+ 47: dbg_apb
+
+Example:
+	clkc: clkc {
+                #clock-cells = <1>;
+                compatible = "xlnx,ps7-clkc";
+                ps-clk-frequency = <33333333>;
+		clock-output-names = "armpll", "ddrpll", "iopll", "cpu_6or4x",
+				"cpu_3or2x", "cpu_2x", "cpu_1x", "ddr2x", "ddr3x",
+				"dci", "lqspi", "smc", "pcap", "gem0", "gem1",
+				"fclk0", "fclk1", "fclk2", "fclk3", "can0", "can1",
+				"sdio0", "sdio1", "uart0", "uart1", "spi0", "spi1",
+				"dma", "usb0_aper", "usb1_aper", "gem0_aper",
+				"gem1_aper", "sdio0_aper", "sdio1_aper",
+				"spi0_aper", "spi1_aper", "can0_aper", "can1_aper",
+				"i2c0_aper", "i2c1_aper", "uart0_aper", "uart1_aper",
+				"gpio_aper", "lqspi_aper", "smc_aper", "swdt",
+				"dbg_trc", "dbg_apb";
+                # optional props
+		clocks = <&clkc 16>, <&clk_foo>;
+		clock-names = "gem1_emio_clk", "can_mio_clk_23";
+        };
+
+
 == PLLs ==
 
 Used to describe the ARM_PLL, DDR_PLL, and IO_PLL.
diff --git a/drivers/clk/zynq/clkc.c b/drivers/clk/zynq/clkc.c
new file mode 100644
index 0000000..5c205b6
--- /dev/null
+++ b/drivers/clk/zynq/clkc.c
@@ -0,0 +1,533 @@
+/*
+ * Zynq clock controller
+ *
+ *  Copyright (C) 2012 - 2013 Xilinx
+ *
+ *  S?ren Brinkmann <soren.brinkmann at xilinx.com>
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License v2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <linux/clk/zynq.h>
+#include <linux/clk-provider.h>
+#include <linux/of.h>
+#include <linux/slab.h>
+#include <linux/string.h>
+#include <linux/io.h>
+
+static void __iomem *zynq_slcr_base_priv;
+
+#define SLCR_ARMPLL_CTRL		(zynq_slcr_base_priv + 0x100)
+#define SLCR_DDRPLL_CTRL		(zynq_slcr_base_priv + 0x104)
+#define SLCR_IOPLL_CTRL			(zynq_slcr_base_priv + 0x108)
+#define SLCR_PLL_STATUS			(zynq_slcr_base_priv + 0x10c)
+#define SLCR_ARM_CLK_CTRL		(zynq_slcr_base_priv + 0x120)
+#define SLCR_DDR_CLK_CTRL		(zynq_slcr_base_priv + 0x124)
+#define SLCR_DCI_CLK_CTRL		(zynq_slcr_base_priv + 0x128)
+#define SLCR_APER_CLK_CTRL		(zynq_slcr_base_priv + 0x12c)
+#define SLCR_GEM0_CLK_CTRL		(zynq_slcr_base_priv + 0x140)
+#define SLCR_GEM1_CLK_CTRL		(zynq_slcr_base_priv + 0x144)
+#define SLCR_SMC_CLK_CTRL		(zynq_slcr_base_priv + 0x148)
+#define SLCR_LQSPI_CLK_CTRL		(zynq_slcr_base_priv + 0x14c)
+#define SLCR_SDIO_CLK_CTRL		(zynq_slcr_base_priv + 0x150)
+#define SLCR_UART_CLK_CTRL		(zynq_slcr_base_priv + 0x154)
+#define SLCR_SPI_CLK_CTRL		(zynq_slcr_base_priv + 0x158)
+#define SLCR_CAN_CLK_CTRL		(zynq_slcr_base_priv + 0x15c)
+#define SLCR_CAN_MIOCLK_CTRL		(zynq_slcr_base_priv + 0x160)
+#define SLCR_DBG_CLK_CTRL		(zynq_slcr_base_priv + 0x164)
+#define SLCR_PCAP_CLK_CTRL		(zynq_slcr_base_priv + 0x168)
+#define SLCR_FPGA0_CLK_CTRL		(zynq_slcr_base_priv + 0x170)
+#define SLCR_621_TRUE			(zynq_slcr_base_priv + 0x1c4)
+#define SLCR_SWDT_CLK_SEL		(zynq_slcr_base_priv + 0x304)
+
+#define NUM_MIO_PINS	54
+
+enum zynq_clk {
+	armpll, ddrpll, iopll,
+	cpu_6or4x, cpu_3or2x, cpu_2x, cpu_1x,
+	ddr2x, ddr3x, dci,
+	lqspi, smc, pcap, gem0, gem1, fclk0, fclk1, fclk2, fclk3, can0, can1,
+	sdio0, sdio1, uart0, uart1, spi0, spi1, dma,
+	usb0_aper, usb1_aper, gem0_aper, gem1_aper,
+	sdio0_aper, sdio1_aper, spi0_aper, spi1_aper, can0_aper, can1_aper,
+	i2c0_aper, i2c1_aper, uart0_aper, uart1_aper, gpio_aper, lqspi_aper,
+	smc_aper, swdt, dbg_trc, dbg_apb, clk_max};
+
+static struct clk *ps_clk;
+static struct clk *clks[clk_max];
+static struct clk_onecell_data clk_data;
+
+static DEFINE_SPINLOCK(armpll_lock);
+static DEFINE_SPINLOCK(ddrpll_lock);
+static DEFINE_SPINLOCK(iopll_lock);
+static DEFINE_SPINLOCK(armclk_lock);
+static DEFINE_SPINLOCK(ddrclk_lock);
+static DEFINE_SPINLOCK(dciclk_lock);
+static DEFINE_SPINLOCK(gem0clk_lock);
+static DEFINE_SPINLOCK(gem1clk_lock);
+static DEFINE_SPINLOCK(canclk_lock);
+static DEFINE_SPINLOCK(canmioclk_lock);
+static DEFINE_SPINLOCK(dbgclk_lock);
+static DEFINE_SPINLOCK(aperclk_lock);
+
+static const char dummy_nm[] __initconst = "dummy_name";
+
+static const char *armpll_parents[] __initdata = {"armpll_int", "ps_clk"};
+static const char *ddrpll_parents[] __initdata = {"ddrpll_int", "ps_clk"};
+static const char *iopll_parents[] __initdata = {"iopll_int", "ps_clk"};
+static const char *gem0_mux_parents[] __initdata = {"gem0_div1", dummy_nm};
+static const char *gem1_mux_parents[] __initdata = {"gem1_div1", dummy_nm};
+static const char *can0_mio_mux2_parents[] __initdata = {"can0_gate",
+	"can0_mio_mux"};
+static const char *can1_mio_mux2_parents[] __initdata = {"can1_gate",
+	"can1_mio_mux"};
+static const char *dbg_emio_mux_parents[] __initdata = {"dbg_div",
+	dummy_nm};
+
+static const char *dbgtrc_emio_input_names[] __initdata = {"trace_emio_clk"};
+static const char *gem0_emio_input_names[] __initdata = {"gem0_emio_clk"};
+static const char *gem1_emio_input_names[] __initdata = {"gem1_emio_clk"};
+static const char *swdt_ext_clk_input_names[] __initdata = {"swdt_ext_clk"};
+
+static void __init zynq_clk_register_fclk(enum zynq_clk fclk,
+		const char *clk_name, void __iomem *fclk_ctrl_reg,
+		const char **parents)
+{
+	struct clk *clk;
+	char *mux_name;
+	char *div0_name;
+	char *div1_name;
+	spinlock_t *fclk_lock;
+	spinlock_t *fclk_gate_lock;
+	void __iomem *fclk_gate_reg = fclk_ctrl_reg + 8;
+
+	fclk_lock = kmalloc(sizeof(*fclk_lock), GFP_KERNEL);
+	if (!fclk_lock)
+		goto err;
+	fclk_gate_lock = kmalloc(sizeof(*fclk_gate_lock), GFP_KERNEL);
+	if (!fclk_gate_lock)
+		goto err;
+	spin_lock_init(fclk_lock);
+	spin_lock_init(fclk_gate_lock);
+
+	mux_name = kasprintf(GFP_KERNEL, "%s_mux", clk_name);
+	div0_name = kasprintf(GFP_KERNEL, "%s_div0", clk_name);
+	div1_name = kasprintf(GFP_KERNEL, "%s_div1", clk_name);
+
+	clk = clk_register_mux(NULL, mux_name, parents, 4, 0,
+			fclk_ctrl_reg, 4, 2, 0, fclk_lock);
+
+	clk = clk_register_divider(NULL, div0_name, mux_name,
+			0, fclk_ctrl_reg, 8, 6, CLK_DIVIDER_ONE_BASED |
+			CLK_DIVIDER_ALLOW_ZERO, fclk_lock);
+
+	clk = clk_register_divider(NULL, div1_name, div0_name,
+			CLK_SET_RATE_PARENT, fclk_ctrl_reg, 20, 6,
+			CLK_DIVIDER_ONE_BASED | CLK_DIVIDER_ALLOW_ZERO,
+			fclk_lock);
+
+	clks[fclk] = clk_register_gate(NULL, clk_name,
+			div1_name, CLK_SET_RATE_PARENT, fclk_gate_reg,
+			0, CLK_GATE_SET_TO_DISABLE, fclk_gate_lock);
+	kfree(mux_name);
+	kfree(div0_name);
+	kfree(div1_name);
+
+	return;
+
+err:
+	clks[fclk] = ERR_PTR(-ENOMEM);
+}
+
+static void __init zynq_clk_register_periph_clk(enum zynq_clk clk0,
+		enum zynq_clk clk1, const char *clk_name0,
+		const char *clk_name1, void __iomem *clk_ctrl,
+		const char **parents, unsigned int two_gates)
+{
+	struct clk *clk;
+	char *mux_name;
+	char *div_name;
+	spinlock_t *lock;
+
+	lock = kmalloc(sizeof(*lock), GFP_KERNEL);
+	if (!lock)
+		goto err;
+	spin_lock_init(lock);
+
+	mux_name = kasprintf(GFP_KERNEL, "%s_mux", clk_name0);
+	div_name = kasprintf(GFP_KERNEL, "%s_div", clk_name0);
+
+	clk = clk_register_mux(NULL, mux_name, parents, 4, 0,
+			clk_ctrl, 4, 2, 0, lock);
+
+	clk = clk_register_divider(NULL, div_name, mux_name, 0, clk_ctrl, 8, 6,
+			CLK_DIVIDER_ONE_BASED | CLK_DIVIDER_ALLOW_ZERO, lock);
+
+	clks[clk0] = clk_register_gate(NULL, clk_name0, div_name,
+			CLK_SET_RATE_PARENT, clk_ctrl, 0, 0, lock);
+	if (two_gates)
+		clks[clk1] = clk_register_gate(NULL, clk_name1, div_name,
+				CLK_SET_RATE_PARENT, clk_ctrl, 1, 0, lock);
+
+	kfree(mux_name);
+	kfree(div_name);
+
+	return;
+
+err:
+	clks[clk0] = ERR_PTR(-ENOMEM);
+	if (two_gates)
+		clks[clk1] = ERR_PTR(-ENOMEM);
+}
+
+static void __init zynq_clk_setup(struct device_node *np)
+{
+	int i;
+	u32 tmp;
+	int ret;
+	struct clk *clk;
+	char *clk_name;
+	const char *clk_output_name[clk_max];
+	const char *cpu_parents[4];
+	const char *periph_parents[4];
+	const char *swdt_ext_clk_mux_parents[2];
+	const char *can_mio_mux_parents[NUM_MIO_PINS];
+
+	pr_info("Zynq clock init\n");
+
+	/* get clock output names from DT */
+	for (i = 0; i < clk_max; i++) {
+		if (of_property_read_string_index(np, "clock-output-names",
+				  i, &clk_output_name[i])) {
+			pr_err("%s: clock output name not in DT\n", __func__);
+			BUG();
+		}
+	}
+	cpu_parents[0] = clk_output_name[armpll];
+	cpu_parents[1] = clk_output_name[armpll];
+	cpu_parents[2] = clk_output_name[ddrpll];
+	cpu_parents[3] = clk_output_name[iopll];
+	periph_parents[0] = clk_output_name[iopll];
+	periph_parents[1] = clk_output_name[iopll];
+	periph_parents[2] = clk_output_name[armpll];
+	periph_parents[3] = clk_output_name[ddrpll];
+
+	/* ps_clk */
+	ret = of_property_read_u32(np, "ps-clk-frequency", &tmp);
+	if (ret) {
+		pr_warn("ps_clk frequency not specified, using 33 MHz.\n");
+		tmp = 33333333;
+	}
+	ps_clk = clk_register_fixed_rate(NULL, "ps_clk", NULL, CLK_IS_ROOT,
+			tmp);
+
+	/* PLLs */
+	clk = clk_register_zynq_pll("armpll_int", "ps_clk", SLCR_ARMPLL_CTRL,
+			SLCR_PLL_STATUS, 0, &armpll_lock);
+	clks[armpll] = clk_register_mux(NULL, clk_output_name[armpll],
+			armpll_parents, 2, 0, SLCR_ARMPLL_CTRL, 4, 1, 0,
+			&armpll_lock);
+
+	clk = clk_register_zynq_pll("ddrpll_int", "ps_clk", SLCR_DDRPLL_CTRL,
+			SLCR_PLL_STATUS, 1, &ddrpll_lock);
+	clks[ddrpll] = clk_register_mux(NULL, clk_output_name[ddrpll],
+			ddrpll_parents, 2, 0, SLCR_DDRPLL_CTRL, 4, 1, 0,
+			&ddrpll_lock);
+
+	clk = clk_register_zynq_pll("iopll_int", "ps_clk", SLCR_IOPLL_CTRL,
+			SLCR_PLL_STATUS, 2, &iopll_lock);
+	clks[iopll] = clk_register_mux(NULL, clk_output_name[iopll],
+			iopll_parents, 2, 0, SLCR_IOPLL_CTRL, 4, 1, 0,
+			&iopll_lock);
+
+	/* CPU clocks */
+	tmp = readl(SLCR_621_TRUE) & 1;
+	clk = clk_register_mux(NULL, "cpu_mux", cpu_parents, 4, 0,
+			SLCR_ARM_CLK_CTRL, 4, 2, 0, &armclk_lock);
+	clk = clk_register_divider(NULL, "cpu_div", "cpu_mux", 0,
+			SLCR_ARM_CLK_CTRL, 8, 6, CLK_DIVIDER_ONE_BASED |
+			CLK_DIVIDER_ALLOW_ZERO, &armclk_lock);
+
+	clks[cpu_6or4x] = clk_register_gate(NULL, clk_output_name[cpu_6or4x],
+			"cpu_div", CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED,
+			SLCR_ARM_CLK_CTRL, 24, 0, &armclk_lock);
+
+	clk = clk_register_fixed_factor(NULL, "cpu_3or2x_div", "cpu_div", 0,
+			1, 2);
+	clks[cpu_3or2x] = clk_register_gate(NULL, clk_output_name[cpu_3or2x],
+			"cpu_3or2x_div", CLK_IGNORE_UNUSED,
+			SLCR_ARM_CLK_CTRL, 25, 0, &armclk_lock);
+
+	clk = clk_register_fixed_factor(NULL, "cpu_2x_div", "cpu_div", 0, 1,
+			2 + tmp);
+	clks[cpu_2x] = clk_register_gate(NULL, clk_output_name[cpu_2x],
+			"cpu_2x_div", CLK_IGNORE_UNUSED, SLCR_ARM_CLK_CTRL,
+			26, 0, &armclk_lock);
+
+	clk = clk_register_fixed_factor(NULL, "cpu_1x_div", "cpu_div", 0, 1,
+			4 + 2 * tmp);
+	clks[cpu_1x] = clk_register_gate(NULL, clk_output_name[cpu_1x],
+			"cpu_1x_div", CLK_IGNORE_UNUSED, SLCR_ARM_CLK_CTRL, 27,
+			0, &armclk_lock);
+
+	/* Timers */
+	swdt_ext_clk_mux_parents[0] = clk_output_name[cpu_1x];
+	for (i = 0; i < ARRAY_SIZE(swdt_ext_clk_input_names); i++) {
+		int idx = of_property_match_string(np, "clock-names",
+				swdt_ext_clk_input_names[i]);
+		if (idx >= 0)
+			swdt_ext_clk_mux_parents[i + 1] =
+				of_clk_get_parent_name(np, idx);
+		else
+			swdt_ext_clk_mux_parents[i + 1] = dummy_nm;
+	}
+	clks[swdt] = clk_register_mux(NULL, clk_output_name[swdt],
+			swdt_ext_clk_mux_parents, 2, CLK_SET_RATE_PARENT,
+			SLCR_SWDT_CLK_SEL, 0, 1, 0, &gem0clk_lock);
+
+	/* DDR clocks */
+	clk = clk_register_divider(NULL, "ddr2x_div", "ddrpll", 0,
+			SLCR_DDR_CLK_CTRL, 26, 6, CLK_DIVIDER_ONE_BASED |
+			CLK_DIVIDER_ALLOW_ZERO, &ddrclk_lock);
+	clks[ddr2x] = clk_register_gate(NULL, clk_output_name[ddr2x],
+			"ddr2x_div", 0, SLCR_DDR_CLK_CTRL, 1, 0, &ddrclk_lock);
+	clk_prepare_enable(clks[ddr2x]);
+	clk = clk_register_divider(NULL, "ddr3x_div", "ddrpll", 0,
+			SLCR_DDR_CLK_CTRL, 20, 6, CLK_DIVIDER_ONE_BASED |
+			CLK_DIVIDER_ALLOW_ZERO, &ddrclk_lock);
+	clks[ddr3x] = clk_register_gate(NULL, clk_output_name[ddr3x],
+			"ddr3x_div", 0, SLCR_DDR_CLK_CTRL, 0, 0, &ddrclk_lock);
+	clk_prepare_enable(clks[ddr3x]);
+
+	clk = clk_register_divider(NULL, "dci_div0", "ddrpll", 0,
+			SLCR_DCI_CLK_CTRL, 8, 6, CLK_DIVIDER_ONE_BASED |
+			CLK_DIVIDER_ALLOW_ZERO, &dciclk_lock);
+	clk = clk_register_divider(NULL, "dci_div1", "dci_div0",
+			CLK_SET_RATE_PARENT, SLCR_DCI_CLK_CTRL, 20, 6,
+			CLK_DIVIDER_ONE_BASED | CLK_DIVIDER_ALLOW_ZERO,
+			&dciclk_lock);
+	clks[dci] = clk_register_gate(NULL, clk_output_name[dci], "dci_div1",
+			CLK_SET_RATE_PARENT, SLCR_DCI_CLK_CTRL, 0, 0,
+			&dciclk_lock);
+	clk_prepare_enable(clks[dci]);
+
+	/* Peripheral clocks */
+	for (i = fclk0; i <= fclk3; i++)
+		zynq_clk_register_fclk(i, clk_output_name[i],
+				SLCR_FPGA0_CLK_CTRL + 0x10 * (i - fclk0),
+				periph_parents);
+
+	zynq_clk_register_periph_clk(lqspi, 0, clk_output_name[lqspi], NULL,
+			SLCR_LQSPI_CLK_CTRL, periph_parents, 0);
+
+	zynq_clk_register_periph_clk(smc, 0, clk_output_name[smc], NULL,
+			SLCR_SMC_CLK_CTRL, periph_parents, 0);
+
+	zynq_clk_register_periph_clk(pcap, 0, clk_output_name[pcap], NULL,
+			SLCR_PCAP_CLK_CTRL, periph_parents, 0);
+
+	zynq_clk_register_periph_clk(sdio0, sdio1, clk_output_name[sdio0],
+			clk_output_name[sdio1], SLCR_SDIO_CLK_CTRL,
+			periph_parents, 1);
+
+	zynq_clk_register_periph_clk(uart0, uart1, clk_output_name[uart0],
+			clk_output_name[uart1], SLCR_UART_CLK_CTRL,
+			periph_parents, 1);
+
+	zynq_clk_register_periph_clk(spi0, spi1, clk_output_name[spi0],
+			clk_output_name[spi1], SLCR_SPI_CLK_CTRL,
+			periph_parents, 1);
+
+	for (i = 0; i < ARRAY_SIZE(gem0_emio_input_names); i++) {
+		int idx = of_property_match_string(np, "clock-names",
+				gem0_emio_input_names[i]);
+		if (idx >= 0)
+			gem0_mux_parents[i + 1] = of_clk_get_parent_name(np,
+					idx);
+	}
+	clk = clk_register_mux(NULL, "gem0_mux", periph_parents, 4, 0,
+			SLCR_GEM0_CLK_CTRL, 4, 2, 0, &gem0clk_lock);
+	clk = clk_register_divider(NULL, "gem0_div0", "gem0_mux", 0,
+			SLCR_GEM0_CLK_CTRL, 8, 6, CLK_DIVIDER_ONE_BASED |
+			CLK_DIVIDER_ALLOW_ZERO, &gem0clk_lock);
+	clk = clk_register_divider(NULL, "gem0_div1", "gem0_div0",
+			CLK_SET_RATE_PARENT, SLCR_GEM0_CLK_CTRL, 20, 6,
+			CLK_DIVIDER_ONE_BASED | CLK_DIVIDER_ALLOW_ZERO,
+			&gem0clk_lock);
+	clk = clk_register_mux(NULL, "gem0_emio_mux", gem0_mux_parents, 2, 0,
+			SLCR_GEM0_CLK_CTRL, 6, 1, 0, &gem0clk_lock);
+	clks[gem0] = clk_register_gate(NULL, clk_output_name[gem0],
+			"gem0_emio_mux", CLK_SET_RATE_PARENT,
+			SLCR_GEM0_CLK_CTRL, 0, 0, &gem0clk_lock);
+
+	for (i = 0; i < ARRAY_SIZE(gem1_emio_input_names); i++) {
+		int idx = of_property_match_string(np, "clock-names",
+				gem1_emio_input_names[i]);
+		if (idx >= 0)
+			gem1_mux_parents[i + 1] = of_clk_get_parent_name(np,
+					idx);
+	}
+	clk = clk_register_mux(NULL, "gem1_mux", periph_parents, 4, 0,
+			SLCR_GEM1_CLK_CTRL, 4, 2, 0, &gem1clk_lock);
+	clk = clk_register_divider(NULL, "gem1_div0", "gem1_mux", 0,
+			SLCR_GEM1_CLK_CTRL, 8, 6, CLK_DIVIDER_ONE_BASED |
+			CLK_DIVIDER_ALLOW_ZERO, &gem1clk_lock);
+	clk = clk_register_divider(NULL, "gem1_div1", "gem1_div0",
+			CLK_SET_RATE_PARENT, SLCR_GEM1_CLK_CTRL, 20, 6,
+			CLK_DIVIDER_ONE_BASED | CLK_DIVIDER_ALLOW_ZERO,
+			&gem1clk_lock);
+	clk = clk_register_mux(NULL, "gem1_emio_mux", gem1_mux_parents, 2, 0,
+			SLCR_GEM1_CLK_CTRL, 6, 1, 0, &gem1clk_lock);
+	clks[gem1] = clk_register_gate(NULL, clk_output_name[gem1],
+			"gem1_emio_mux", CLK_SET_RATE_PARENT,
+			SLCR_GEM1_CLK_CTRL, 0, 0, &gem1clk_lock);
+
+	tmp = strlen("mio_clk_00x");
+	clk_name = kmalloc(tmp, GFP_KERNEL);
+	for (i = 0; i < NUM_MIO_PINS; i++) {
+		int idx;
+
+		snprintf(clk_name, tmp, "mio_clk_%2.2d", i);
+		idx = of_property_match_string(np, "clock-names", clk_name);
+		if (idx >= 0)
+			can_mio_mux_parents[i] = of_clk_get_parent_name(np,
+						idx);
+		else
+			can_mio_mux_parents[i] = dummy_nm;
+	}
+	kfree(clk_name);
+	clk = clk_register_mux(NULL, "can_mux", periph_parents, 4, 0,
+			SLCR_CAN_CLK_CTRL, 4, 2, 0, &canclk_lock);
+	clk = clk_register_divider(NULL, "can_div0", "can_mux", 0,
+			SLCR_CAN_CLK_CTRL, 8, 6, CLK_DIVIDER_ONE_BASED |
+			CLK_DIVIDER_ALLOW_ZERO, &canclk_lock);
+	clk = clk_register_divider(NULL, "can_div1", "can_div0",
+			CLK_SET_RATE_PARENT, SLCR_CAN_CLK_CTRL, 20, 6,
+			CLK_DIVIDER_ONE_BASED | CLK_DIVIDER_ALLOW_ZERO,
+			&canclk_lock);
+	clk = clk_register_gate(NULL, "can0_gate", "can_div1",
+			CLK_SET_RATE_PARENT, SLCR_CAN_CLK_CTRL, 0, 0,
+			&canclk_lock);
+	clk = clk_register_gate(NULL, "can1_gate", "can_div1",
+			CLK_SET_RATE_PARENT, SLCR_CAN_CLK_CTRL, 1, 0,
+			&canclk_lock);
+	clk = clk_register_mux(NULL, "can0_mio_mux",
+			can_mio_mux_parents, 54, CLK_SET_RATE_PARENT,
+			SLCR_CAN_MIOCLK_CTRL, 0, 6, 0, &canmioclk_lock);
+	clk = clk_register_mux(NULL, "can1_mio_mux",
+			can_mio_mux_parents, 54, CLK_SET_RATE_PARENT,
+			SLCR_CAN_MIOCLK_CTRL, 16, 6, 0, &canmioclk_lock);
+	clks[can0] = clk_register_mux(NULL, clk_output_name[can0],
+			can0_mio_mux2_parents, 2, CLK_SET_RATE_PARENT,
+			SLCR_CAN_MIOCLK_CTRL, 6, 1, 0, &canmioclk_lock);
+	clks[can1] = clk_register_mux(NULL, clk_output_name[can1],
+			can1_mio_mux2_parents, 2, CLK_SET_RATE_PARENT,
+			SLCR_CAN_MIOCLK_CTRL, 22, 1, 0, &canmioclk_lock);
+
+	for (i = 0; i < ARRAY_SIZE(dbgtrc_emio_input_names); i++) {
+		int idx = of_property_match_string(np, "clock-names",
+				dbgtrc_emio_input_names[i]);
+		if (idx >= 0)
+			dbg_emio_mux_parents[i + 1] = of_clk_get_parent_name(np,
+					idx);
+	}
+	clk = clk_register_mux(NULL, "dbg_mux", periph_parents, 4, 0,
+			SLCR_DBG_CLK_CTRL, 4, 2, 0, &dbgclk_lock);
+	clk = clk_register_divider(NULL, "dbg_div", "dbg_mux", 0,
+			SLCR_DBG_CLK_CTRL, 8, 6, CLK_DIVIDER_ONE_BASED |
+			CLK_DIVIDER_ALLOW_ZERO, &dbgclk_lock);
+	clk = clk_register_mux(NULL, "dbg_emio_mux", dbg_emio_mux_parents, 2, 0,
+			SLCR_DBG_CLK_CTRL, 6, 1, 0, &dbgclk_lock);
+	clks[dbg_trc] = clk_register_gate(NULL, clk_output_name[dbg_trc],
+			"dbg_emio_mux", CLK_SET_RATE_PARENT, SLCR_DBG_CLK_CTRL,
+			0, 0, &dbgclk_lock);
+	clks[dbg_apb] = clk_register_gate(NULL, clk_output_name[dbg_apb],
+			clk_output_name[cpu_1x], 0, SLCR_DBG_CLK_CTRL, 1, 0,
+			&dbgclk_lock);
+
+	/* One gated clock for all APER clocks. */
+	clks[dma] = clk_register_gate(NULL, clk_output_name[dma],
+			clk_output_name[cpu_2x], 0, SLCR_APER_CLK_CTRL, 0, 0,
+			&aperclk_lock);
+	clks[usb0_aper] = clk_register_gate(NULL, clk_output_name[usb0_aper],
+			clk_output_name[cpu_1x], 0, SLCR_APER_CLK_CTRL, 2, 0,
+			&aperclk_lock);
+	clks[usb1_aper] = clk_register_gate(NULL, clk_output_name[usb1_aper],
+			clk_output_name[cpu_1x], 0, SLCR_APER_CLK_CTRL, 3, 0,
+			&aperclk_lock);
+	clks[gem0_aper] = clk_register_gate(NULL, clk_output_name[gem0_aper],
+			clk_output_name[cpu_1x], 0, SLCR_APER_CLK_CTRL, 6, 0,
+			&aperclk_lock);
+	clks[gem1_aper] = clk_register_gate(NULL, clk_output_name[gem1_aper],
+			clk_output_name[cpu_1x], 0, SLCR_APER_CLK_CTRL, 7, 0,
+			&aperclk_lock);
+	clks[sdio0_aper] = clk_register_gate(NULL, clk_output_name[sdio0_aper],
+			clk_output_name[cpu_1x], 0, SLCR_APER_CLK_CTRL, 10, 0,
+			&aperclk_lock);
+	clks[sdio1_aper] = clk_register_gate(NULL, clk_output_name[sdio1_aper],
+			clk_output_name[cpu_1x], 0, SLCR_APER_CLK_CTRL, 11, 0,
+			&aperclk_lock);
+	clks[spi0_aper] = clk_register_gate(NULL, clk_output_name[spi0_aper],
+			clk_output_name[cpu_1x], 0, SLCR_APER_CLK_CTRL, 14, 0,
+			&aperclk_lock);
+	clks[spi1_aper] = clk_register_gate(NULL, clk_output_name[spi1_aper],
+			clk_output_name[cpu_1x], 0, SLCR_APER_CLK_CTRL, 15, 0,
+			&aperclk_lock);
+	clks[can0_aper] = clk_register_gate(NULL, clk_output_name[can0_aper],
+			clk_output_name[cpu_1x], 0, SLCR_APER_CLK_CTRL, 16, 0,
+			&aperclk_lock);
+	clks[can1_aper] = clk_register_gate(NULL, clk_output_name[can1_aper],
+			clk_output_name[cpu_1x], 0, SLCR_APER_CLK_CTRL, 17, 0,
+			&aperclk_lock);
+	clks[i2c0_aper] = clk_register_gate(NULL, clk_output_name[i2c0_aper],
+			clk_output_name[cpu_1x], 0, SLCR_APER_CLK_CTRL, 18, 0,
+			&aperclk_lock);
+	clks[i2c1_aper] = clk_register_gate(NULL, clk_output_name[i2c1_aper],
+			clk_output_name[cpu_1x], 0, SLCR_APER_CLK_CTRL, 19, 0,
+			&aperclk_lock);
+	clks[uart0_aper] = clk_register_gate(NULL, clk_output_name[uart0_aper],
+			clk_output_name[cpu_1x], 0, SLCR_APER_CLK_CTRL, 20, 0,
+			&aperclk_lock);
+	clks[uart1_aper] = clk_register_gate(NULL, clk_output_name[uart1_aper],
+			clk_output_name[cpu_1x], 0, SLCR_APER_CLK_CTRL, 21, 0,
+			&aperclk_lock);
+	clks[gpio_aper] = clk_register_gate(NULL, clk_output_name[gpio_aper],
+			clk_output_name[cpu_1x], 0, SLCR_APER_CLK_CTRL, 22, 0,
+			&aperclk_lock);
+	clks[lqspi_aper] = clk_register_gate(NULL, clk_output_name[lqspi_aper],
+			clk_output_name[cpu_1x], 0, SLCR_APER_CLK_CTRL, 23, 0,
+			&aperclk_lock);
+	clks[smc_aper] = clk_register_gate(NULL, clk_output_name[smc_aper],
+			clk_output_name[cpu_1x], 0, SLCR_APER_CLK_CTRL, 24, 0,
+			&aperclk_lock);
+
+	for (i = 0; i < ARRAY_SIZE(clks); i++) {
+		if (IS_ERR(clks[i])) {
+			pr_err("Zynq clk %d: register failed with %ld\n",
+			       i, PTR_ERR(clks[i]));
+			BUG();
+		}
+	}
+
+	clk_data.clks = clks;
+	clk_data.clk_num = ARRAY_SIZE(clks);
+	of_clk_add_provider(np, of_clk_src_onecell_get, &clk_data);
+}
+
+CLK_OF_DECLARE(zynq_clkc, "xlnx,ps7-clkc", zynq_clk_setup);
+
+void __init zynq_clock_init(void __iomem *slcr_base)
+{
+	zynq_slcr_base_priv = slcr_base;
+	of_clk_init(NULL);
+}
-- 
1.8.2.2



From soren.brinkmann at xilinx.com  Tue Apr 30 19:58:04 2013
From: soren.brinkmann at xilinx.com (Soren Brinkmann)
Date: Tue, 30 Apr 2013 16:58:04 -0700
Subject: [PATCH 7/7] clk: zynq: Remove deprecated clock code
In-Reply-To: <1367366284-28304-1-git-send-email-soren.brinkmann@xilinx.com>
References: <1367366284-28304-1-git-send-email-soren.brinkmann@xilinx.com>
Message-ID: <1367366284-28304-8-git-send-email-soren.brinkmann@xilinx.com>

Signed-off-by: Soren Brinkmann <soren.brinkmann at xilinx.com>
Cc: Grant Likely <grant.likely at linaro.org>
Cc: Rob Herring <rob.herring at calxeda.com>
Cc: Rob Landley <rob at landley.net>
Cc: devicetree-discuss at lists.ozlabs.org (moderated list:OPEN FIRMWARE AND...)
Cc: linux-doc at vger.kernel.org (open list:DOCUMENTATION)
---
 .../devicetree/bindings/clock/zynq-7000.txt        |  49 ---
 drivers/clk/clk-zynq.c                             | 378 ---------------------
 2 files changed, 427 deletions(-)
 delete mode 100644 drivers/clk/clk-zynq.c

diff --git a/Documentation/devicetree/bindings/clock/zynq-7000.txt b/Documentation/devicetree/bindings/clock/zynq-7000.txt
index 30bfca9..b013ec6 100644
--- a/Documentation/devicetree/bindings/clock/zynq-7000.txt
+++ b/Documentation/devicetree/bindings/clock/zynq-7000.txt
@@ -102,52 +102,3 @@ Example:
 		clocks = <&clkc 16>, <&clk_foo>;
 		clock-names = "gem1_emio_clk", "can_mio_clk_23";
         };
-
-
-== PLLs ==
-
-Used to describe the ARM_PLL, DDR_PLL, and IO_PLL.
-
-Required properties:
-- #clock-cells : shall be 0 (only one clock is output from this node)
-- compatible : "xlnx,zynq-pll"
-- reg : pair of u32 values, which are the address offsets within the SLCR
-        of the relevant PLL_CTRL register and PLL_CFG register respectively
-- clocks : phandle for parent clock.  should be the phandle for ps_clk
-
-Optional properties:
-- clock-output-names : name of the output clock
-
-Example:
-	armpll: armpll {
-		#clock-cells = <0>;
-		compatible = "xlnx,zynq-pll";
-		clocks = <&ps_clk>;
-		reg = <0x100 0x110>;
-		clock-output-names = "armpll";
-	};
-
-== Peripheral clocks ==
-
-Describes clock node for the SDIO, SMC, SPI, QSPI, and UART clocks.
-
-Required properties:
-- #clock-cells : shall be 1
-- compatible : "xlnx,zynq-periph-clock"
-- reg : a single u32 value, describing the offset within the SLCR where
-        the CLK_CTRL register is found for this peripheral
-- clocks : phandle for parent clocks.  should hold phandles for
-           the IO_PLL, ARM_PLL, and DDR_PLL in order
-- clock-output-names : names of the output clock(s).  For peripherals that have
-                       two output clocks (for example, the UART), two clocks
-                       should be listed.
-
-Example:
-	uart_clk: uart_clk {
-		#clock-cells = <1>;
-		compatible = "xlnx,zynq-periph-clock";
-		clocks = <&iopll &armpll &ddrpll>;
-		reg = <0x154>;
-		clock-output-names = "uart0_ref_clk",
-				     "uart1_ref_clk";
-	};
diff --git a/drivers/clk/clk-zynq.c b/drivers/clk/clk-zynq.c
deleted file mode 100644
index 3206297..0000000
--- a/drivers/clk/clk-zynq.c
+++ /dev/null
@@ -1,378 +0,0 @@
-/*
- * Copyright (c) 2012 National Instruments
- *
- * Josh Cartwright <josh.cartwright at ni.com>
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms and conditions of the GNU General Public License,
- * version 2, as published by the Free Software Foundation.
- *
- * This program is distributed in the hope it will be useful, but WITHOUT
- * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
- * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
- * more details.
- *
- * You should have received a copy of the GNU General Public License along with
- * this program.  If not, see <http://www.gnu.org/licenses/>.
- */
-#include <linux/io.h>
-#include <linux/of.h>
-#include <linux/slab.h>
-#include <linux/kernel.h>
-#include <linux/clk-provider.h>
-#include <linux/clk/zynq.h>
-
-static void __iomem *slcr_base;
-
-struct zynq_pll_clk {
-	struct clk_hw	hw;
-	void __iomem	*pll_ctrl;
-	void __iomem	*pll_cfg;
-};
-
-#define to_zynq_pll_clk(hw)	container_of(hw, struct zynq_pll_clk, hw)
-
-#define CTRL_PLL_FDIV(x)	((x) >> 12)
-
-static unsigned long zynq_pll_recalc_rate(struct clk_hw *hw,
-					  unsigned long parent_rate)
-{
-	struct zynq_pll_clk *pll = to_zynq_pll_clk(hw);
-	return parent_rate * CTRL_PLL_FDIV(ioread32(pll->pll_ctrl));
-}
-
-static const struct clk_ops zynq_pll_clk_ops = {
-	.recalc_rate	= zynq_pll_recalc_rate,
-};
-
-static void __init zynq_pll_clk_setup(struct device_node *np)
-{
-	struct clk_init_data init;
-	struct zynq_pll_clk *pll;
-	const char *parent_name;
-	struct clk *clk;
-	u32 regs[2];
-	int ret;
-
-	ret = of_property_read_u32_array(np, "reg", regs, ARRAY_SIZE(regs));
-	if (WARN_ON(ret))
-		return;
-
-	pll = kzalloc(sizeof(*pll), GFP_KERNEL);
-	if (WARN_ON(!pll))
-		return;
-
-	pll->pll_ctrl = slcr_base + regs[0];
-	pll->pll_cfg  = slcr_base + regs[1];
-
-	of_property_read_string(np, "clock-output-names", &init.name);
-
-	init.ops = &zynq_pll_clk_ops;
-	parent_name = of_clk_get_parent_name(np, 0);
-	init.parent_names = &parent_name;
-	init.num_parents = 1;
-
-	pll->hw.init = &init;
-
-	clk = clk_register(NULL, &pll->hw);
-	if (WARN_ON(IS_ERR(clk)))
-		return;
-
-	ret = of_clk_add_provider(np, of_clk_src_simple_get, clk);
-	if (WARN_ON(ret))
-		return;
-}
-CLK_OF_DECLARE(zynq_pll, "xlnx,zynq-pll", zynq_pll_clk_setup);
-
-struct zynq_periph_clk {
-	struct clk_hw		hw;
-	struct clk_onecell_data	onecell_data;
-	struct clk		*gates[2];
-	void __iomem		*clk_ctrl;
-	spinlock_t		clkact_lock;
-};
-
-#define to_zynq_periph_clk(hw)	container_of(hw, struct zynq_periph_clk, hw)
-
-static const u8 periph_clk_parent_map[] = {
-	0, 0, 1, 2
-};
-#define PERIPH_CLK_CTRL_SRC(x)	(periph_clk_parent_map[((x) & 0x30) >> 4])
-#define PERIPH_CLK_CTRL_DIV(x)	(((x) & 0x3F00) >> 8)
-
-static unsigned long zynq_periph_recalc_rate(struct clk_hw *hw,
-					     unsigned long parent_rate)
-{
-	struct zynq_periph_clk *periph = to_zynq_periph_clk(hw);
-	return parent_rate / PERIPH_CLK_CTRL_DIV(ioread32(periph->clk_ctrl));
-}
-
-static u8 zynq_periph_get_parent(struct clk_hw *hw)
-{
-	struct zynq_periph_clk *periph = to_zynq_periph_clk(hw);
-	return PERIPH_CLK_CTRL_SRC(ioread32(periph->clk_ctrl));
-}
-
-static const struct clk_ops zynq_periph_clk_ops = {
-	.recalc_rate	= zynq_periph_recalc_rate,
-	.get_parent	= zynq_periph_get_parent,
-};
-
-static void __init zynq_periph_clk_setup(struct device_node *np)
-{
-	struct zynq_periph_clk *periph;
-	const char *parent_names[3];
-	struct clk_init_data init;
-	int clk_num = 0, err;
-	const char *name;
-	struct clk *clk;
-	u32 reg;
-	int i;
-
-	err = of_property_read_u32(np, "reg", &reg);
-	if (WARN_ON(err))
-		return;
-
-	periph = kzalloc(sizeof(*periph), GFP_KERNEL);
-	if (WARN_ON(!periph))
-		return;
-
-	periph->clk_ctrl = slcr_base + reg;
-	spin_lock_init(&periph->clkact_lock);
-
-	init.name = np->name;
-	init.ops = &zynq_periph_clk_ops;
-	for (i = 0; i < ARRAY_SIZE(parent_names); i++)
-		parent_names[i] = of_clk_get_parent_name(np, i);
-	init.parent_names = parent_names;
-	init.num_parents = ARRAY_SIZE(parent_names);
-
-	periph->hw.init = &init;
-
-	clk = clk_register(NULL, &periph->hw);
-	if (WARN_ON(IS_ERR(clk)))
-		return;
-
-	err = of_clk_add_provider(np, of_clk_src_simple_get, clk);
-	if (WARN_ON(err))
-		return;
-
-	err = of_property_read_string_index(np, "clock-output-names", 0,
-					    &name);
-	if (WARN_ON(err))
-		return;
-
-	periph->gates[0] = clk_register_gate(NULL, name, np->name, 0,
-					     periph->clk_ctrl, 0, 0,
-					     &periph->clkact_lock);
-	if (WARN_ON(IS_ERR(periph->gates[0])))
-		return;
-	clk_num++;
-
-	/* some periph clks have 2 downstream gates */
-	err = of_property_read_string_index(np, "clock-output-names", 1,
-					    &name);
-	if (err != -ENODATA) {
-		periph->gates[1] = clk_register_gate(NULL, name, np->name, 0,
-						     periph->clk_ctrl, 1, 0,
-						     &periph->clkact_lock);
-		if (WARN_ON(IS_ERR(periph->gates[1])))
-			return;
-		clk_num++;
-	}
-
-	periph->onecell_data.clks = periph->gates;
-	periph->onecell_data.clk_num = clk_num;
-
-	err = of_clk_add_provider(np, of_clk_src_onecell_get,
-				  &periph->onecell_data);
-	if (WARN_ON(err))
-		return;
-}
-CLK_OF_DECLARE(zynq_periph, "xlnx,zynq-periph-clock", zynq_periph_clk_setup);
-
-/* CPU Clock domain is modelled as a mux with 4 children subclks, whose
- * derivative rates depend on CLK_621_TRUE
- */
-
-struct zynq_cpu_clk {
-	struct clk_hw		hw;
-	struct clk_onecell_data	onecell_data;
-	struct clk		*subclks[4];
-	void __iomem		*clk_ctrl;
-	spinlock_t		clkact_lock;
-};
-
-#define to_zynq_cpu_clk(hw)	container_of(hw, struct zynq_cpu_clk, hw)
-
-static const u8 zynq_cpu_clk_parent_map[] = {
-	1, 1, 2, 0
-};
-#define CPU_CLK_SRCSEL(x)	(zynq_cpu_clk_parent_map[(((x) & 0x30) >> 4)])
-#define CPU_CLK_CTRL_DIV(x)	(((x) & 0x3F00) >> 8)
-
-static u8 zynq_cpu_clk_get_parent(struct clk_hw *hw)
-{
-	struct zynq_cpu_clk *cpuclk = to_zynq_cpu_clk(hw);
-	return CPU_CLK_SRCSEL(ioread32(cpuclk->clk_ctrl));
-}
-
-static unsigned long zynq_cpu_clk_recalc_rate(struct clk_hw *hw,
-					      unsigned long parent_rate)
-{
-	struct zynq_cpu_clk *cpuclk = to_zynq_cpu_clk(hw);
-	return parent_rate / CPU_CLK_CTRL_DIV(ioread32(cpuclk->clk_ctrl));
-}
-
-static const struct clk_ops zynq_cpu_clk_ops = {
-	.get_parent	= zynq_cpu_clk_get_parent,
-	.recalc_rate	= zynq_cpu_clk_recalc_rate,
-};
-
-struct zynq_cpu_subclk {
-	struct clk_hw	hw;
-	void __iomem	*clk_621;
-	enum {
-		CPU_SUBCLK_6X4X,
-		CPU_SUBCLK_3X2X,
-		CPU_SUBCLK_2X,
-		CPU_SUBCLK_1X,
-	} which;
-};
-
-#define CLK_621_TRUE(x)	((x) & 1)
-
-#define to_zynq_cpu_subclk(hw)	container_of(hw, struct zynq_cpu_subclk, hw);
-
-static unsigned long zynq_cpu_subclk_recalc_rate(struct clk_hw *hw,
-						 unsigned long parent_rate)
-{
-	unsigned long uninitialized_var(rate);
-	struct zynq_cpu_subclk *subclk;
-	bool is_621;
-
-	subclk = to_zynq_cpu_subclk(hw)
-	is_621 = CLK_621_TRUE(ioread32(subclk->clk_621));
-
-	switch (subclk->which) {
-	case CPU_SUBCLK_6X4X:
-		rate = parent_rate;
-		break;
-	case CPU_SUBCLK_3X2X:
-		rate = parent_rate / 2;
-		break;
-	case CPU_SUBCLK_2X:
-		rate = parent_rate / (is_621 ? 3 : 2);
-		break;
-	case CPU_SUBCLK_1X:
-		rate = parent_rate / (is_621 ? 6 : 4);
-		break;
-	};
-
-	return rate;
-}
-
-static const struct clk_ops zynq_cpu_subclk_ops = {
-	.recalc_rate	= zynq_cpu_subclk_recalc_rate,
-};
-
-static struct clk *zynq_cpu_subclk_setup(struct device_node *np, u8 which,
-					 void __iomem *clk_621)
-{
-	struct zynq_cpu_subclk *subclk;
-	struct clk_init_data init;
-	struct clk *clk;
-	int err;
-
-	err = of_property_read_string_index(np, "clock-output-names",
-					    which, &init.name);
-	if (WARN_ON(err))
-		goto err_read_output_name;
-
-	subclk = kzalloc(sizeof(*subclk), GFP_KERNEL);
-	if (!subclk)
-		goto err_subclk_alloc;
-
-	subclk->clk_621 = clk_621;
-	subclk->which = which;
-
-	init.ops = &zynq_cpu_subclk_ops;
-	init.parent_names = &np->name;
-	init.num_parents = 1;
-
-	subclk->hw.init = &init;
-
-	clk = clk_register(NULL, &subclk->hw);
-	if (WARN_ON(IS_ERR(clk)))
-		goto err_clk_register;
-
-	return clk;
-
-err_clk_register:
-	kfree(subclk);
-err_subclk_alloc:
-err_read_output_name:
-	return ERR_PTR(-EINVAL);
-}
-
-static void __init zynq_cpu_clk_setup(struct device_node *np)
-{
-	struct zynq_cpu_clk *cpuclk;
-	const char *parent_names[3];
-	struct clk_init_data init;
-	void __iomem *clk_621;
-	struct clk *clk;
-	u32 reg[2];
-	int err;
-	int i;
-
-	err = of_property_read_u32_array(np, "reg", reg, ARRAY_SIZE(reg));
-	if (WARN_ON(err))
-		return;
-
-	cpuclk = kzalloc(sizeof(*cpuclk), GFP_KERNEL);
-	if (WARN_ON(!cpuclk))
-		return;
-
-	cpuclk->clk_ctrl = slcr_base + reg[0];
-	clk_621 = slcr_base + reg[1];
-	spin_lock_init(&cpuclk->clkact_lock);
-
-	init.name = np->name;
-	init.ops = &zynq_cpu_clk_ops;
-	for (i = 0; i < ARRAY_SIZE(parent_names); i++)
-		parent_names[i] = of_clk_get_parent_name(np, i);
-	init.parent_names = parent_names;
-	init.num_parents = ARRAY_SIZE(parent_names);
-
-	cpuclk->hw.init = &init;
-
-	clk = clk_register(NULL, &cpuclk->hw);
-	if (WARN_ON(IS_ERR(clk)))
-		return;
-
-	err = of_clk_add_provider(np, of_clk_src_simple_get, clk);
-	if (WARN_ON(err))
-		return;
-
-	for (i = 0; i < 4; i++) {
-		cpuclk->subclks[i] = zynq_cpu_subclk_setup(np, i, clk_621);
-		if (WARN_ON(IS_ERR(cpuclk->subclks[i])))
-			return;
-	}
-
-	cpuclk->onecell_data.clks = cpuclk->subclks;
-	cpuclk->onecell_data.clk_num = i;
-
-	err = of_clk_add_provider(np, of_clk_src_onecell_get,
-				  &cpuclk->onecell_data);
-	if (WARN_ON(err))
-		return;
-}
-CLK_OF_DECLARE(zynq_cpu, "xlnx,zynq-cpu-clock", zynq_cpu_clk_setup);
-
-void __init xilinx_zynq_clocks_init(void __iomem *slcr)
-{
-	slcr_base = slcr;
-	of_clk_init(NULL);
-}
-- 
1.8.2.2



From rusty at rustcorp.com.au  Mon Apr 29 20:32:15 2013
From: rusty at rustcorp.com.au (Rusty Russell)
Date: Tue, 30 Apr 2013 10:02:15 +0930
Subject: [PATCH 0/2] Early printk support for virtio console devices.
In-Reply-To: <336C59AA-D5D7-472E-A8DA-EEB413DD6C68@suse.de>
References: <1366974299-17877-1-git-send-email-pranavkumar@linaro.org>
 <BA2076A6-0688-4E5C-85F9-A9CA8FD75782@suse.de>
 <87obcyc9sh.fsf@rustcorp.com.au>
 <336C59AA-D5D7-472E-A8DA-EEB413DD6C68@suse.de>
Message-ID: <87r4hsameo.fsf@rustcorp.com.au>

Alexander Graf <agraf at suse.de> writes:
> Am 29.04.2013 um 05:09 schrieb Rusty Russell <rusty at rustcorp.com.au>:
>
>> Alexander Graf <agraf at suse.de> writes:
>>> On 26.04.2013, at 13:04, Pranavkumar Sawargaonkar wrote:
>>> 
>>>> This patch-set implements early printk support for virtio console devices without using any hypercalls.
>>>> 
>>>> The current virtio early printk code in kernel expects that hypervisor will provide some mechanism generally a hypercall to support early printk. This patch-set does not break existing hypercall based early print support.
>>>> 
>>>> This implementation adds:
>>>> 1. Early writeonly register named early_wr in virtio console's config space.
>>>> 2. Host feature flags namely VIRTIO_CONSOLE_F_EARLY_WRITE for telling guest about early-write capability in console device.
>>>> 
>>>> Early write mechanism:
>>>> 1. When a guest wants to out some character, it has to simply write the character to early_wr register in config space of virtio console device.
>>> 
>>> I won't nack this patch set, but I'll definitely express that I'm not happy with it.
>>> 
>>> MMIO registers are handled by a different layer than the virtio console itself. After the virtio refactoring in QEMU, they will be completely separate drivers. So we'll be in a similar mess with early printk as we are on the s390-virtio machine, where early printk is done through hypercalls and thus we can't directly link it to the console output.
>>> 
>>> I still don't see what the issue is with just implementing a small irq-less virtio driver for early printk.
>> 
>> Well, this shouldn't be mmio-specific, but I kind of get what you mean.
>> 
>> I consider this misnamed: it's an emergency write facility.  Linux may
>> use it for an early console,
>
> If Linux uses it for early console, you won't see any messages from before the virtio-console driver is initialized, because Linux thinks that it's all been printed out.

If you can't support it, don't offer the feature.

>> but it's also useful for bringup and to
>> give a method of emitting errors like "the console ring is corrupt".
>> 
>> A valid implementation may well be to only offer it with some magic
>> qemu developer-only commandline and dump it to stdout.
>
> Why implement it differently from other machines? There are facilities to call into firmware, so you could use that. There's the special Foundation model call that you could implement and reuse for this.

Sure, for ARM.  We *have* a console device.  It's the logical place to
provide a simple write mechanism.  eg. consider bhyve on FreeBSD.

> I don't see why anything like this has to live in virtio-mmio. Oh, and it should default to off.

virtio-console, not virtio-mmio.

Cheers,
Rusty.


From gregkh at linuxfoundation.org  Tue Apr 30 20:00:48 2013
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Tue, 30 Apr 2013 17:00:48 -0700
Subject: [PATCH 1/7] tty: xuartps: Sort #includes alphabetically
In-Reply-To: <1367366284-28304-2-git-send-email-soren.brinkmann@xilinx.com>
References: <1367366284-28304-1-git-send-email-soren.brinkmann@xilinx.com>
 <1367366284-28304-2-git-send-email-soren.brinkmann@xilinx.com>
Message-ID: <20130501000048.GA1840@kroah.com>

On Tue, Apr 30, 2013 at 04:57:58PM -0700, Soren Brinkmann wrote:
> Signed-off-by: Soren Brinkmann <soren.brinkmann at xilinx.com>
> CC: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
> CC: Jiri Slaby <jslaby at suse.cz>
> CC: linux-serial at vger.kernel.org

Why would you need/want to do this?

greg k-h


From soren.brinkmann at xilinx.com  Tue Apr 30 20:05:40 2013
From: soren.brinkmann at xilinx.com (=?utf-8?B?U8O2cmVu?= Brinkmann)
Date: Tue, 30 Apr 2013 17:05:40 -0700
Subject: [PATCH 1/7] tty: xuartps: Sort #includes alphabetically
In-Reply-To: <20130501000048.GA1840@kroah.com>
References: <1367366284-28304-1-git-send-email-soren.brinkmann@xilinx.com>
 <1367366284-28304-2-git-send-email-soren.brinkmann@xilinx.com>
 <20130501000048.GA1840@kroah.com>
Message-ID: <cbd8c55c-066b-4396-9a4b-97d58a93b573@DB8EHSMHS005.ehs.local>

On Tue, Apr 30, 2013 at 05:00:48PM -0700, Greg Kroah-Hartman wrote:
> On Tue, Apr 30, 2013 at 04:57:58PM -0700, Soren Brinkmann wrote:
> > Signed-off-by: Soren Brinkmann <soren.brinkmann at xilinx.com>
> > CC: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
> > CC: Jiri Slaby <jslaby at suse.cz>
> > CC: linux-serial at vger.kernel.org
> 
> Why would you need/want to do this?
I often come across duplicated includes. Having some kind of order helps
avoiding that, imho.

	S?ren




From tony at atomide.com  Tue Apr 30 20:22:57 2013
From: tony at atomide.com (Tony Lindgren)
Date: Tue, 30 Apr 2013 17:22:57 -0700
Subject: Latest build results - errors/warnings - lots of them
In-Reply-To: <20130430235147.GG28721@atomide.com>
References: <20130430081739.GP14496@n2100.arm.linux.org.uk>
 <201305010111.14247.arnd@arndb.de>
 <20130430235147.GG28721@atomide.com>
Message-ID: <20130501002257.GH28721@atomide.com>

* Tony Lindgren <tony at atomide.com> [130430 16:57]:
> * Arnd Bergmann <arnd at arndb.de> [130430 16:16]:
> > 
> > I've uploaded this to the test-merge-20130430 branch in the arm-soc
> > tree if anyone is curious. I suppose we should get all the changes
> > in arch/arm included in the merge window and then work with the
> > subsystem maintainers on the other bugs.
> 
> >  arch/arm/mach-omap2/Kconfig                   | 133 +++++++++++++-------------
> >  arch/arm/mach-omap2/Makefile                  |   8 +-
> 
> Nice, I like your changes to flip ARCH_OMAP2PLUS to be selected
> by the SoC. That's a better way to fix things than just tinkering
> with the Makefile like I posted earlier today.
> 
> Now you have SOC_OMAP5 selected twice in omap2plus_defconfig though,
> which causes:
> 
> .config:283:warning: override: reassigning to symbol SOC_OMAP5
> 
> For the SERIAL_OMAP change, let's just use my earlier patch
> "ARM: OMAP2+: Fix unmet direct dependencies for SERIAL_OMAP".
> We should not select optional drivers at all in Kconfig.

And looks like also the following should be folded in to allow building
ARCH_OMAP2. Other than that your branch seems to build & boot
fine on omaps.

Regards,

Tony


--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -21,6 +21,7 @@ CONFIG_MODVERSIONS=y
 CONFIG_MODULE_SRCVERSION_ALL=y
 # CONFIG_BLK_DEV_BSG is not set
 CONFIG_ARCH_OMAP2=y
+CONFIG_ARCH_MULTI_V6=y
 CONFIG_ARCH_OMAP3=y
 CONFIG_ARCH_OMAP4=y
 CONFIG_SOC_OMAP5=y


From gregkh at linuxfoundation.org  Tue Apr 30 20:23:21 2013
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Tue, 30 Apr 2013 17:23:21 -0700
Subject: [PATCH 1/7] tty: xuartps: Sort #includes alphabetically
In-Reply-To: <cbd8c55c-066b-4396-9a4b-97d58a93b573@DB8EHSMHS005.ehs.local>
References: <1367366284-28304-1-git-send-email-soren.brinkmann@xilinx.com>
 <1367366284-28304-2-git-send-email-soren.brinkmann@xilinx.com>
 <20130501000048.GA1840@kroah.com>
 <cbd8c55c-066b-4396-9a4b-97d58a93b573@DB8EHSMHS005.ehs.local>
Message-ID: <20130501002321.GB7435@kroah.com>

On Tue, Apr 30, 2013 at 05:05:40PM -0700, S?ren Brinkmann wrote:
> On Tue, Apr 30, 2013 at 05:00:48PM -0700, Greg Kroah-Hartman wrote:
> > On Tue, Apr 30, 2013 at 04:57:58PM -0700, Soren Brinkmann wrote:
> > > Signed-off-by: Soren Brinkmann <soren.brinkmann at xilinx.com>
> > > CC: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
> > > CC: Jiri Slaby <jslaby at suse.cz>
> > > CC: linux-serial at vger.kernel.org
> > 
> > Why would you need/want to do this?
> I often come across duplicated includes. Having some kind of order helps
> avoiding that, imho.

We have a tool to handle duplicated includes, no need to put them in
sorted order for them to be detected.

thanks,

greg k-h


From agraf at suse.de  Tue Apr 30 20:26:33 2013
From: agraf at suse.de (Alexander Graf)
Date: Wed, 1 May 2013 02:26:33 +0200
Subject: [PATCH 0/2] Early printk support for virtio console devices.
In-Reply-To: <87r4hsameo.fsf@rustcorp.com.au>
References: <1366974299-17877-1-git-send-email-pranavkumar@linaro.org>
 <BA2076A6-0688-4E5C-85F9-A9CA8FD75782@suse.de>
 <87obcyc9sh.fsf@rustcorp.com.au>
 <336C59AA-D5D7-472E-A8DA-EEB413DD6C68@suse.de>
 <87r4hsameo.fsf@rustcorp.com.au>
Message-ID: <2A4B3F6B-55DA-44F3-87DB-064DB4A8D8F8@suse.de>


On 30.04.2013, at 02:32, Rusty Russell wrote:

> Alexander Graf <agraf at suse.de> writes:
>> Am 29.04.2013 um 05:09 schrieb Rusty Russell <rusty at rustcorp.com.au>:
>> 
>>> Alexander Graf <agraf at suse.de> writes:
>>>> On 26.04.2013, at 13:04, Pranavkumar Sawargaonkar wrote:
>>>> 
>>>>> This patch-set implements early printk support for virtio console devices without using any hypercalls.
>>>>> 
>>>>> The current virtio early printk code in kernel expects that hypervisor will provide some mechanism generally a hypercall to support early printk. This patch-set does not break existing hypercall based early print support.
>>>>> 
>>>>> This implementation adds:
>>>>> 1. Early writeonly register named early_wr in virtio console's config space.
>>>>> 2. Host feature flags namely VIRTIO_CONSOLE_F_EARLY_WRITE for telling guest about early-write capability in console device.
>>>>> 
>>>>> Early write mechanism:
>>>>> 1. When a guest wants to out some character, it has to simply write the character to early_wr register in config space of virtio console device.
>>>> 
>>>> I won't nack this patch set, but I'll definitely express that I'm not happy with it.
>>>> 
>>>> MMIO registers are handled by a different layer than the virtio console itself. After the virtio refactoring in QEMU, they will be completely separate drivers. So we'll be in a similar mess with early printk as we are on the s390-virtio machine, where early printk is done through hypercalls and thus we can't directly link it to the console output.
>>>> 
>>>> I still don't see what the issue is with just implementing a small irq-less virtio driver for early printk.
>>> 
>>> Well, this shouldn't be mmio-specific, but I kind of get what you mean.
>>> 
>>> I consider this misnamed: it's an emergency write facility.  Linux may
>>> use it for an early console,
>> 
>> If Linux uses it for early console, you won't see any messages from before the virtio-console driver is initialized, because Linux thinks that it's all been printed out.
> 
> If you can't support it, don't offer the feature.

Fair enough.

> 
>>> but it's also useful for bringup and to
>>> give a method of emitting errors like "the console ring is corrupt".
>>> 
>>> A valid implementation may well be to only offer it with some magic
>>> qemu developer-only commandline and dump it to stdout.
>> 
>> Why implement it differently from other machines? There are facilities to call into firmware, so you could use that. There's the special Foundation model call that you could implement and reuse for this.
> 
> Sure, for ARM.  We *have* a console device.  It's the logical place to
> provide a simple write mechanism.  eg. consider bhyve on FreeBSD.

I don't quite see the point. The reason early printk works so well for x86 is that you have a UART at a predefined place.

> 
>> I don't see why anything like this has to live in virtio-mmio. Oh, and it should default to off.
> 
> virtio-console, not virtio-mmio.

How will it live in virtio-console? Virtio-console speaks virtio, not register values. If you put this into the config space you break the s390 virtio model.


Alex



From sboyd at codeaurora.org  Tue Apr 30 20:54:34 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Tue, 30 Apr 2013 17:54:34 -0700
Subject: [PATCH 5/4] sched: Make ARM's sched_clock generic for all
 architectures
In-Reply-To: <1366417746-24990-1-git-send-email-sboyd@codeaurora.org>
References: <1366417746-24990-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1367369675-13535-1-git-send-email-sboyd@codeaurora.org>

Here's the patch to make sched_clock generic. I didn't know
where to put it so I just made a new file in kernel/sched
for now.

Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---

 arch/arm/Kconfig                                      | 1 +
 arch/arm/common/timer-sp.c                            | 2 +-
 arch/arm/kernel/Makefile                              | 2 +-
 arch/arm/kernel/arch_timer.c                          | 2 +-
 arch/arm/kernel/time.c                                | 4 +---
 arch/arm/mach-davinci/time.c                          | 2 +-
 arch/arm/mach-imx/time.c                              | 2 +-
 arch/arm/mach-integrator/integrator_ap.c              | 2 +-
 arch/arm/mach-ixp4xx/common.c                         | 2 +-
 arch/arm/mach-mmp/time.c                              | 2 +-
 arch/arm/mach-msm/timer.c                             | 2 +-
 arch/arm/mach-omap1/time.c                            | 2 +-
 arch/arm/mach-omap2/timer.c                           | 2 +-
 arch/arm/mach-pxa/time.c                              | 2 +-
 arch/arm/mach-sa1100/time.c                           | 2 +-
 arch/arm/mach-u300/timer.c                            | 2 +-
 arch/arm/plat-iop/time.c                              | 2 +-
 arch/arm/plat-omap/counter_32k.c                      | 2 +-
 arch/arm/plat-orion/time.c                            | 2 +-
 arch/arm/plat-samsung/samsung-time.c                  | 2 +-
 arch/arm/plat-versatile/sched-clock.c                 | 2 +-
 drivers/clocksource/bcm2835_timer.c                   | 2 +-
 drivers/clocksource/clksrc-dbx500-prcmu.c             | 3 +--
 drivers/clocksource/dw_apb_timer_of.c                 | 2 +-
 drivers/clocksource/mxs_timer.c                       | 2 +-
 drivers/clocksource/nomadik-mtu.c                     | 2 +-
 drivers/clocksource/tegra20_timer.c                   | 2 +-
 drivers/clocksource/time-armada-370-xp.c              | 2 +-
 drivers/clocksource/timer-marco.c                     | 2 +-
 drivers/clocksource/timer-prima2.c                    | 2 +-
 {arch/arm/include/asm => include/linux}/sched_clock.h | 9 +++++++--
 init/Kconfig                                          | 3 +++
 init/main.c                                           | 2 ++
 kernel/sched/Makefile                                 | 1 +
 {arch/arm/kernel => kernel/sched}/sched_clock.c       | 3 +--
 35 files changed, 44 insertions(+), 36 deletions(-)
 rename {arch/arm/include/asm => include/linux}/sched_clock.h (76%)
 rename {arch/arm/kernel => kernel/sched}/sched_clock.c (99%)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 10c3466..ce1a020 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -14,6 +14,7 @@ config ARM
 	select GENERIC_IRQ_PROBE
 	select GENERIC_IRQ_SHOW
 	select GENERIC_PCI_IOMAP
+	select GENERIC_SCHED_CLOCK
 	select GENERIC_SMP_IDLE_THREAD
 	select GENERIC_IDLE_LOOP
 	select GENERIC_IDLE_POLL_SETUP
diff --git a/arch/arm/common/timer-sp.c b/arch/arm/common/timer-sp.c
index ddc7407..023ee63 100644
--- a/arch/arm/common/timer-sp.c
+++ b/arch/arm/common/timer-sp.c
@@ -28,8 +28,8 @@
 #include <linux/of.h>
 #include <linux/of_address.h>
 #include <linux/of_irq.h>
+#include <linux/sched_clock.h>
 
-#include <asm/sched_clock.h>
 #include <asm/hardware/arm_timer.h>
 #include <asm/hardware/timer-sp.h>
 
diff --git a/arch/arm/kernel/Makefile b/arch/arm/kernel/Makefile
index 00d703c..44ea2de 100644
--- a/arch/arm/kernel/Makefile
+++ b/arch/arm/kernel/Makefile
@@ -16,7 +16,7 @@ CFLAGS_REMOVE_return_address.o = -pg
 # Object file lists.
 
 obj-y		:= elf.o entry-common.o irq.o opcodes.o \
-		   process.o ptrace.o return_address.o sched_clock.o \
+		   process.o ptrace.o return_address.o \
 		   setup.o signal.o stacktrace.o sys_arm.o time.o traps.o
 
 obj-$(CONFIG_ATAGS)		+= atags_parse.o
diff --git a/arch/arm/kernel/arch_timer.c b/arch/arm/kernel/arch_timer.c
index b45250b..e1ea2bf 100644
--- a/arch/arm/kernel/arch_timer.c
+++ b/arch/arm/kernel/arch_timer.c
@@ -11,9 +11,9 @@
 #include <linux/init.h>
 #include <linux/types.h>
 #include <linux/errno.h>
+#include <linux/sched_clock.h>
 
 #include <asm/delay.h>
-#include <asm/sched_clock.h>
 
 #include <clocksource/arm_arch_timer.h>
 
diff --git a/arch/arm/kernel/time.c b/arch/arm/kernel/time.c
index abff4e9..98aee32 100644
--- a/arch/arm/kernel/time.c
+++ b/arch/arm/kernel/time.c
@@ -24,9 +24,9 @@
 #include <linux/timer.h>
 #include <linux/clocksource.h>
 #include <linux/irq.h>
+#include <linux/sched_clock.h>
 
 #include <asm/thread_info.h>
-#include <asm/sched_clock.h>
 #include <asm/stacktrace.h>
 #include <asm/mach/arch.h>
 #include <asm/mach/time.h>
@@ -120,6 +120,4 @@ void __init time_init(void)
 		machine_desc->init_time();
 	else
 		clocksource_of_init();
-
-	sched_clock_postinit();
 }
diff --git a/arch/arm/mach-davinci/time.c b/arch/arm/mach-davinci/time.c
index bad361e..7a55b5c 100644
--- a/arch/arm/mach-davinci/time.c
+++ b/arch/arm/mach-davinci/time.c
@@ -18,8 +18,8 @@
 #include <linux/clk.h>
 #include <linux/err.h>
 #include <linux/platform_device.h>
+#include <linux/sched_clock.h>
 
-#include <asm/sched_clock.h>
 #include <asm/mach/irq.h>
 #include <asm/mach/time.h>
 
diff --git a/arch/arm/mach-imx/time.c b/arch/arm/mach-imx/time.c
index fea9131..cd46529 100644
--- a/arch/arm/mach-imx/time.c
+++ b/arch/arm/mach-imx/time.c
@@ -26,8 +26,8 @@
 #include <linux/clockchips.h>
 #include <linux/clk.h>
 #include <linux/err.h>
+#include <linux/sched_clock.h>
 
-#include <asm/sched_clock.h>
 #include <asm/mach/time.h>
 
 #include "common.h"
diff --git a/arch/arm/mach-integrator/integrator_ap.c b/arch/arm/mach-integrator/integrator_ap.c
index b23c8e4..aa43462 100644
--- a/arch/arm/mach-integrator/integrator_ap.c
+++ b/arch/arm/mach-integrator/integrator_ap.c
@@ -41,6 +41,7 @@
 #include <linux/stat.h>
 #include <linux/sys_soc.h>
 #include <linux/termios.h>
+#include <linux/sched_clock.h>
 #include <video/vga.h>
 
 #include <mach/hardware.h>
@@ -49,7 +50,6 @@
 #include <asm/setup.h>
 #include <asm/param.h>		/* HZ */
 #include <asm/mach-types.h>
-#include <asm/sched_clock.h>
 
 #include <mach/lm.h>
 #include <mach/irqs.h>
diff --git a/arch/arm/mach-ixp4xx/common.c b/arch/arm/mach-ixp4xx/common.c
index 6600cff..58307cf 100644
--- a/arch/arm/mach-ixp4xx/common.c
+++ b/arch/arm/mach-ixp4xx/common.c
@@ -30,6 +30,7 @@
 #include <linux/export.h>
 #include <linux/gpio.h>
 #include <linux/cpu.h>
+#include <linux/sched_clock.h>
 
 #include <mach/udc.h>
 #include <mach/hardware.h>
@@ -38,7 +39,6 @@
 #include <asm/pgtable.h>
 #include <asm/page.h>
 #include <asm/irq.h>
-#include <asm/sched_clock.h>
 #include <asm/system_misc.h>
 
 #include <asm/mach/map.h>
diff --git a/arch/arm/mach-mmp/time.c b/arch/arm/mach-mmp/time.c
index 86a18b3..7ac41e8 100644
--- a/arch/arm/mach-mmp/time.c
+++ b/arch/arm/mach-mmp/time.c
@@ -28,8 +28,8 @@
 #include <linux/of.h>
 #include <linux/of_address.h>
 #include <linux/of_irq.h>
+#include <linux/sched_clock.h>
 
-#include <asm/sched_clock.h>
 #include <mach/addr-map.h>
 #include <mach/regs-timers.h>
 #include <mach/regs-apbc.h>
diff --git a/arch/arm/mach-msm/timer.c b/arch/arm/mach-msm/timer.c
index 284313f..b6418fd 100644
--- a/arch/arm/mach-msm/timer.c
+++ b/arch/arm/mach-msm/timer.c
@@ -23,10 +23,10 @@
 #include <linux/of.h>
 #include <linux/of_address.h>
 #include <linux/of_irq.h>
+#include <linux/sched_clock.h>
 
 #include <asm/mach/time.h>
 #include <asm/localtimer.h>
-#include <asm/sched_clock.h>
 
 #include "common.h"
 
diff --git a/arch/arm/mach-omap1/time.c b/arch/arm/mach-omap1/time.c
index 726ec23..80603d2 100644
--- a/arch/arm/mach-omap1/time.c
+++ b/arch/arm/mach-omap1/time.c
@@ -43,9 +43,9 @@
 #include <linux/clocksource.h>
 #include <linux/clockchips.h>
 #include <linux/io.h>
+#include <linux/sched_clock.h>
 
 #include <asm/irq.h>
-#include <asm/sched_clock.h>
 
 #include <mach/hardware.h>
 #include <asm/mach/irq.h>
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index ce57228..6e7885e 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -41,10 +41,10 @@
 #include <linux/of_irq.h>
 #include <linux/platform_device.h>
 #include <linux/platform_data/dmtimer-omap.h>
+#include <linux/sched_clock.h>
 
 #include <asm/mach/time.h>
 #include <asm/smp_twd.h>
-#include <asm/sched_clock.h>
 
 #include "omap_hwmod.h"
 #include "omap_device.h"
diff --git a/arch/arm/mach-pxa/time.c b/arch/arm/mach-pxa/time.c
index 8f1ee92..9aa852a 100644
--- a/arch/arm/mach-pxa/time.c
+++ b/arch/arm/mach-pxa/time.c
@@ -16,11 +16,11 @@
 #include <linux/init.h>
 #include <linux/interrupt.h>
 #include <linux/clockchips.h>
+#include <linux/sched_clock.h>
 
 #include <asm/div64.h>
 #include <asm/mach/irq.h>
 #include <asm/mach/time.h>
-#include <asm/sched_clock.h>
 #include <mach/regs-ost.h>
 #include <mach/irqs.h>
 
diff --git a/arch/arm/mach-sa1100/time.c b/arch/arm/mach-sa1100/time.c
index a59a13a..713c86c 100644
--- a/arch/arm/mach-sa1100/time.c
+++ b/arch/arm/mach-sa1100/time.c
@@ -14,9 +14,9 @@
 #include <linux/irq.h>
 #include <linux/timex.h>
 #include <linux/clockchips.h>
+#include <linux/sched_clock.h>
 
 #include <asm/mach/time.h>
-#include <asm/sched_clock.h>
 #include <mach/hardware.h>
 #include <mach/irqs.h>
 
diff --git a/arch/arm/mach-u300/timer.c b/arch/arm/mach-u300/timer.c
index d9e7320..af771b7 100644
--- a/arch/arm/mach-u300/timer.c
+++ b/arch/arm/mach-u300/timer.c
@@ -18,12 +18,12 @@
 #include <linux/clk.h>
 #include <linux/err.h>
 #include <linux/irq.h>
+#include <linux/sched_clock.h>
 
 #include <mach/hardware.h>
 #include <mach/irqs.h>
 
 /* Generic stuff */
-#include <asm/sched_clock.h>
 #include <asm/mach/map.h>
 #include <asm/mach/time.h>
 
diff --git a/arch/arm/plat-iop/time.c b/arch/arm/plat-iop/time.c
index 837a2d5..29606bd7 100644
--- a/arch/arm/plat-iop/time.c
+++ b/arch/arm/plat-iop/time.c
@@ -22,9 +22,9 @@
 #include <linux/clocksource.h>
 #include <linux/clockchips.h>
 #include <linux/export.h>
+#include <linux/sched_clock.h>
 #include <mach/hardware.h>
 #include <asm/irq.h>
-#include <asm/sched_clock.h>
 #include <asm/uaccess.h>
 #include <asm/mach/irq.h>
 #include <asm/mach/time.h>
diff --git a/arch/arm/plat-omap/counter_32k.c b/arch/arm/plat-omap/counter_32k.c
index 5b0b86b..d9bc98e 100644
--- a/arch/arm/plat-omap/counter_32k.c
+++ b/arch/arm/plat-omap/counter_32k.c
@@ -18,9 +18,9 @@
 #include <linux/err.h>
 #include <linux/io.h>
 #include <linux/clocksource.h>
+#include <linux/sched_clock.h>
 
 #include <asm/mach/time.h>
-#include <asm/sched_clock.h>
 
 #include <plat/counter-32k.h>
 
diff --git a/arch/arm/plat-orion/time.c b/arch/arm/plat-orion/time.c
index 5d5ac0f..9d2b2ac 100644
--- a/arch/arm/plat-orion/time.c
+++ b/arch/arm/plat-orion/time.c
@@ -16,7 +16,7 @@
 #include <linux/clockchips.h>
 #include <linux/interrupt.h>
 #include <linux/irq.h>
-#include <asm/sched_clock.h>
+#include <linux/sched_clock.h>
 
 /*
  * MBus bridge block registers.
diff --git a/arch/arm/plat-samsung/samsung-time.c b/arch/arm/plat-samsung/samsung-time.c
index f899cbc..2957075 100644
--- a/arch/arm/plat-samsung/samsung-time.c
+++ b/arch/arm/plat-samsung/samsung-time.c
@@ -15,12 +15,12 @@
 #include <linux/clk.h>
 #include <linux/clockchips.h>
 #include <linux/platform_device.h>
+#include <linux/sched_clock.h>
 
 #include <asm/smp_twd.h>
 #include <asm/mach/time.h>
 #include <asm/mach/arch.h>
 #include <asm/mach/map.h>
-#include <asm/sched_clock.h>
 
 #include <mach/map.h>
 #include <plat/devs.h>
diff --git a/arch/arm/plat-versatile/sched-clock.c b/arch/arm/plat-versatile/sched-clock.c
index b33b74c..51b109e 100644
--- a/arch/arm/plat-versatile/sched-clock.c
+++ b/arch/arm/plat-versatile/sched-clock.c
@@ -20,8 +20,8 @@
  */
 #include <linux/kernel.h>
 #include <linux/io.h>
+#include <linux/sched_clock.h>
 
-#include <asm/sched_clock.h>
 #include <plat/sched_clock.h>
 
 static void __iomem *ctr;
diff --git a/drivers/clocksource/bcm2835_timer.c b/drivers/clocksource/bcm2835_timer.c
index 766611d..07ea7ce 100644
--- a/drivers/clocksource/bcm2835_timer.c
+++ b/drivers/clocksource/bcm2835_timer.c
@@ -28,8 +28,8 @@
 #include <linux/of_platform.h>
 #include <linux/slab.h>
 #include <linux/string.h>
+#include <linux/sched_clock.h>
 
-#include <asm/sched_clock.h>
 #include <asm/irq.h>
 
 #define REG_CONTROL	0x00
diff --git a/drivers/clocksource/clksrc-dbx500-prcmu.c b/drivers/clocksource/clksrc-dbx500-prcmu.c
index 54f3d11..0a7fb24 100644
--- a/drivers/clocksource/clksrc-dbx500-prcmu.c
+++ b/drivers/clocksource/clksrc-dbx500-prcmu.c
@@ -14,8 +14,7 @@
  */
 #include <linux/clockchips.h>
 #include <linux/clksrc-dbx500-prcmu.h>
-
-#include <asm/sched_clock.h>
+#include <linux/sched_clock.h>
 
 #define RATE_32K		32768
 
diff --git a/drivers/clocksource/dw_apb_timer_of.c b/drivers/clocksource/dw_apb_timer_of.c
index ab09ed3..f417e50 100644
--- a/drivers/clocksource/dw_apb_timer_of.c
+++ b/drivers/clocksource/dw_apb_timer_of.c
@@ -20,9 +20,9 @@
 #include <linux/of.h>
 #include <linux/of_address.h>
 #include <linux/of_irq.h>
+#include <linux/sched_clock.h>
 
 #include <asm/mach/time.h>
-#include <asm/sched_clock.h>
 
 static void timer_get_base_and_rate(struct device_node *np,
 				    void __iomem **base, u32 *rate)
diff --git a/drivers/clocksource/mxs_timer.c b/drivers/clocksource/mxs_timer.c
index 02af420..0f5e65f 100644
--- a/drivers/clocksource/mxs_timer.c
+++ b/drivers/clocksource/mxs_timer.c
@@ -29,9 +29,9 @@
 #include <linux/of_address.h>
 #include <linux/of_irq.h>
 #include <linux/stmp_device.h>
+#include <linux/sched_clock.h>
 
 #include <asm/mach/time.h>
-#include <asm/sched_clock.h>
 
 /*
  * There are 2 versions of the timrot on Freescale MXS-based SoCs.
diff --git a/drivers/clocksource/nomadik-mtu.c b/drivers/clocksource/nomadik-mtu.c
index 071f6ea..e747fb1 100644
--- a/drivers/clocksource/nomadik-mtu.c
+++ b/drivers/clocksource/nomadik-mtu.c
@@ -18,8 +18,8 @@
 #include <linux/delay.h>
 #include <linux/err.h>
 #include <linux/platform_data/clocksource-nomadik-mtu.h>
+#include <linux/sched_clock.h>
 #include <asm/mach/time.h>
-#include <asm/sched_clock.h>
 
 /*
  * The MTU device hosts four different counters, with 4 set of
diff --git a/drivers/clocksource/tegra20_timer.c b/drivers/clocksource/tegra20_timer.c
index ae877b0..9396170 100644
--- a/drivers/clocksource/tegra20_timer.c
+++ b/drivers/clocksource/tegra20_timer.c
@@ -26,10 +26,10 @@
 #include <linux/io.h>
 #include <linux/of_address.h>
 #include <linux/of_irq.h>
+#include <linux/sched_clock.h>
 
 #include <asm/mach/time.h>
 #include <asm/smp_twd.h>
-#include <asm/sched_clock.h>
 
 #define RTC_SECONDS            0x08
 #define RTC_SHADOW_SECONDS     0x0c
diff --git a/drivers/clocksource/time-armada-370-xp.c b/drivers/clocksource/time-armada-370-xp.c
index 47a6730..efdca32 100644
--- a/drivers/clocksource/time-armada-370-xp.c
+++ b/drivers/clocksource/time-armada-370-xp.c
@@ -27,8 +27,8 @@
 #include <linux/of_address.h>
 #include <linux/irq.h>
 #include <linux/module.h>
+#include <linux/sched_clock.h>
 
-#include <asm/sched_clock.h>
 #include <asm/localtimer.h>
 #include <linux/percpu.h>
 /*
diff --git a/drivers/clocksource/timer-marco.c b/drivers/clocksource/timer-marco.c
index 97738db..e5dc912 100644
--- a/drivers/clocksource/timer-marco.c
+++ b/drivers/clocksource/timer-marco.c
@@ -17,7 +17,7 @@
 #include <linux/of.h>
 #include <linux/of_irq.h>
 #include <linux/of_address.h>
-#include <asm/sched_clock.h>
+#include <linux/sched_clock.h>
 #include <asm/localtimer.h>
 #include <asm/mach/time.h>
 
diff --git a/drivers/clocksource/timer-prima2.c b/drivers/clocksource/timer-prima2.c
index 7608826..ef3cfb2 100644
--- a/drivers/clocksource/timer-prima2.c
+++ b/drivers/clocksource/timer-prima2.c
@@ -18,7 +18,7 @@
 #include <linux/of.h>
 #include <linux/of_irq.h>
 #include <linux/of_address.h>
-#include <asm/sched_clock.h>
+#include <linux/sched_clock.h>
 #include <asm/mach/time.h>
 
 #define SIRFSOC_TIMER_COUNTER_LO	0x0000
diff --git a/arch/arm/include/asm/sched_clock.h b/include/linux/sched_clock.h
similarity index 76%
rename from arch/arm/include/asm/sched_clock.h
rename to include/linux/sched_clock.h
index e6f765a..495d4c6 100644
--- a/arch/arm/include/asm/sched_clock.h
+++ b/include/linux/sched_clock.h
@@ -5,10 +5,15 @@
  * it under the terms of the GNU General Public License version 2 as
  * published by the Free Software Foundation.
  */
-#ifndef ASM_SCHED_CLOCK
-#define ASM_SCHED_CLOCK
+#ifndef LINUX_SCHED_CLOCK
+#define LINUX_SCHED_CLOCK
 
+#ifdef CONFIG_GENERIC_SCHED_CLOCK
 extern void sched_clock_postinit(void);
+#else
+static inline void sched_clock_postinit(void) { }
+#endif
+
 extern void setup_sched_clock(u32 (*read)(void), int bits, unsigned long rate);
 extern void setup_sched_clock_64(u64 (*read)(void), int bits,
 				 unsigned long rate);
diff --git a/init/Kconfig b/init/Kconfig
index 346cd1b..19237b6 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -772,6 +772,9 @@ config LOG_BUF_SHIFT
 config HAVE_UNSTABLE_SCHED_CLOCK
 	bool
 
+config GENERIC_SCHED_CLOCK
+	bool
+
 #
 # For architectures that want to enable the support for NUMA-affine scheduler
 # balancing logic:
diff --git a/init/main.c b/init/main.c
index b3bc3c9..0e5504e 100644
--- a/init/main.c
+++ b/init/main.c
@@ -72,6 +72,7 @@
 #include <linux/ptrace.h>
 #include <linux/blkdev.h>
 #include <linux/elevator.h>
+#include <linux/sched_clock.h>
 
 #include <asm/io.h>
 #include <asm/bugs.h>
@@ -552,6 +553,7 @@ asmlinkage void __init start_kernel(void)
 	softirq_init();
 	timekeeping_init();
 	time_init();
+	sched_clock_postinit();
 	profile_init();
 	call_function_init();
 	WARN(!irqs_disabled(), "Interrupts were enabled early\n");
diff --git a/kernel/sched/Makefile b/kernel/sched/Makefile
index deaf90e..35abe4a 100644
--- a/kernel/sched/Makefile
+++ b/kernel/sched/Makefile
@@ -17,3 +17,4 @@ obj-$(CONFIG_SCHED_AUTOGROUP) += auto_group.o
 obj-$(CONFIG_SCHEDSTATS) += stats.o
 obj-$(CONFIG_SCHED_DEBUG) += debug.o
 obj-$(CONFIG_CGROUP_CPUACCT) += cpuacct.o
+obj-$(CONFIG_GENERIC_SCHED_CLOCK) += sched_clock.o
diff --git a/arch/arm/kernel/sched_clock.c b/kernel/sched/sched_clock.c
similarity index 99%
rename from arch/arm/kernel/sched_clock.c
rename to kernel/sched/sched_clock.c
index b6067d8..7556349 100644
--- a/arch/arm/kernel/sched_clock.c
+++ b/kernel/sched/sched_clock.c
@@ -13,8 +13,7 @@
 #include <linux/sched.h>
 #include <linux/syscore_ops.h>
 #include <linux/timer.h>
-
-#include <asm/sched_clock.h>
+#include <linux/sched_clock.h>
 
 struct clock_data {
 	u64 epoch_ns;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Tue Apr 30 20:54:35 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Tue, 30 Apr 2013 17:54:35 -0700
Subject: [PATCH 6/4] arm64: Move to generic sched_clock infrastructure
In-Reply-To: <1367369675-13535-1-git-send-email-sboyd@codeaurora.org>
References: <1366417746-24990-1-git-send-email-sboyd@codeaurora.org>
 <1367369675-13535-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1367369675-13535-2-git-send-email-sboyd@codeaurora.org>

Use the generic sched_clock infrastructure instead of rolling our
own. This has the added benefit of fixing suspend/resume as
outlined in 6a4dae5 (ARM: 7565/1: sched: stop sched_clock()
during suspend, 2012-10-23) and correcting the timestamps when
the hardware returns a value instead of 0 upon the first read.

Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 arch/arm64/Kconfig       |  1 +
 arch/arm64/kernel/time.c | 11 ++---------
 2 files changed, 3 insertions(+), 9 deletions(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 4f4c418..b941cca 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -13,6 +13,7 @@ config ARM64
 	select GENERIC_IOMAP
 	select GENERIC_IRQ_PROBE
 	select GENERIC_IRQ_SHOW
+	select GENERIC_SCHED_CLOCK
 	select GENERIC_SMP_IDLE_THREAD
 	select GENERIC_TIME_VSYSCALL
 	select HARDIRQS_SW_RESEND
diff --git a/arch/arm64/kernel/time.c b/arch/arm64/kernel/time.c
index a551f88..fd07ef9 100644
--- a/arch/arm64/kernel/time.c
+++ b/arch/arm64/kernel/time.c
@@ -33,6 +33,7 @@
 #include <linux/irq.h>
 #include <linux/delay.h>
 #include <linux/clocksource.h>
+#include <linux/sched_clock.h>
 
 #include <clocksource/arm_arch_timer.h>
 
@@ -61,13 +62,6 @@ unsigned long profile_pc(struct pt_regs *regs)
 EXPORT_SYMBOL(profile_pc);
 #endif
 
-static u64 sched_clock_mult __read_mostly;
-
-unsigned long long notrace sched_clock(void)
-{
-	return arch_timer_read_counter() * sched_clock_mult;
-}
-
 int read_current_timer(unsigned long *timer_value)
 {
 	*timer_value = arch_timer_read_counter();
@@ -84,8 +78,7 @@ void __init time_init(void)
 	if (!arch_timer_rate)
 		panic("Unable to initialise architected timer.\n");
 
-	/* Cache the sched_clock multiplier to save a divide in the hot path. */
-	sched_clock_mult = NSEC_PER_SEC / arch_timer_rate;
+	setup_sched_clock_64(arch_timer_read_counter, 56, arch_timer_rate);
 
 	/* Calibrate the delay loop directly */
 	lpj_fine = arch_timer_rate / HZ;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sebastian.hesselbarth at gmail.com  Tue Apr 30 20:58:27 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Wed,  1 May 2013 02:58:27 +0200
Subject: [PATCH 0/2] clk: add of_clk_provider stubs to enable clk-si5351 on
 non OF
Message-ID: <1367369910-20402-1-git-send-email-sebastian.hesselbarth@gmail.com>

Enabling drivers that provide clocks on DT on platforms that don't have
CONFIG_OF set fails due to compilation errors. This patch set first adds
some stubs for of_clk_provider functions if CONFIG_OF is not set. Second
it allows those platforms to build and use clk-si5351 i2c clock driver
by removing the dependency on CONFIG_OF.

The above approach has been suggested by Arnd Bergmann and replaces the
corresponding Kconfig patch for clk-si5351 posted earlier. It has been
compile tested with allmodconfig on x86_64 for post v3.9.

Sebastian Hesselbarth (2):
  clk: add non CONFIG_OF routines for clk-provider
  clk: si5351: Allow to build without CONFIG_OF

 drivers/clk/Kconfig          |    1 -
 include/linux/clk-provider.h |   47 +++++++++++++++++++++++++++++++++++-------
 2 files changed, 39 insertions(+), 9 deletions(-)
---
Cc: Mike Turquette <mturquette at linaro.org>
Cc: Linus Walleij <linus.walleij at linaro.org>
Cc: Andrew Morton <akpm at linux-foundation.org>
Cc: Peter Ujfalusi <peter.ujfalusi at ti.com>
Cc: Arnd Bergmann <arnd at arndb.de>
Cc: Stephen Warren <swarren at nvidia.com>
Cc: Daniel Mack <zonque at gmail.com>
Cc: Lars-Peter Clausen <lars at metafoo.de>
Cc: Guenter Roeck <linux at roeck-us.net>
Cc: Marek Belisko <marek.belisko at streamunlimited.com>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
-- 
1.7.10.4



From sebastian.hesselbarth at gmail.com  Tue Apr 30 20:58:28 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Wed,  1 May 2013 02:58:28 +0200
Subject: [PATCH 1/2] clk: add non CONFIG_OF routines for clk-provider
In-Reply-To: <1367369910-20402-1-git-send-email-sebastian.hesselbarth@gmail.com>
References: <1367369910-20402-1-git-send-email-sebastian.hesselbarth@gmail.com>
Message-ID: <1367369910-20402-2-git-send-email-sebastian.hesselbarth@gmail.com>

Some drivers that are shared between architectures have HAVE_CLK selected
but don't have OF. To remove compilation errors for drivers that provide
clocks on DT with of_clk_add_provider we would have to enclose these calls
within #ifdef CONFIG_OF, #endif.

This patch adds some stubs for OF related clk-provider functions that
either do nothing or return appropriate values if CONFIG_OF is not set.
So, definition of these routines will always be available.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
Suggested-by: Arnd Bergmann <arnd at arndb.de>
---
Cc: Mike Turquette <mturquette at linaro.org>
Cc: Linus Walleij <linus.walleij at linaro.org>
Cc: Andrew Morton <akpm at linux-foundation.org>
Cc: Peter Ujfalusi <peter.ujfalusi at ti.com>
Cc: Arnd Bergmann <arnd at arndb.de>
Cc: Stephen Warren <swarren at nvidia.com>
Cc: Daniel Mack <zonque at gmail.com>
Cc: Lars-Peter Clausen <lars at metafoo.de>
Cc: Guenter Roeck <linux at roeck-us.net>
Cc: Marek Belisko <marek.belisko at streamunlimited.com>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
---
 include/linux/clk-provider.h |   47 +++++++++++++++++++++++++++++++++++-------
 1 file changed, 39 insertions(+), 8 deletions(-)

diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 1186098..265f384 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -423,6 +423,17 @@ struct of_device_id;
 
 typedef void (*of_clk_init_cb_t)(struct device_node *);
 
+struct clk_onecell_data {
+	struct clk **clks;
+	unsigned int clk_num;
+};
+
+#define CLK_OF_DECLARE(name, compat, fn)			\
+	static const struct of_device_id __clk_of_table_##name	\
+		__used __section(__clk_of_table)		\
+		= { .compatible = compat, .data = fn };
+
+#ifdef CONFIG_OF
 int of_clk_add_provider(struct device_node *np,
 			struct clk *(*clk_src_get)(struct of_phandle_args *args,
 						   void *data),
@@ -430,19 +441,39 @@ int of_clk_add_provider(struct device_node *np,
 void of_clk_del_provider(struct device_node *np);
 struct clk *of_clk_src_simple_get(struct of_phandle_args *clkspec,
 				  void *data);
-struct clk_onecell_data {
-	struct clk **clks;
-	unsigned int clk_num;
-};
 struct clk *of_clk_src_onecell_get(struct of_phandle_args *clkspec, void *data);
 const char *of_clk_get_parent_name(struct device_node *np, int index);
 
 void of_clk_init(const struct of_device_id *matches);
 
-#define CLK_OF_DECLARE(name, compat, fn)			\
-	static const struct of_device_id __clk_of_table_##name	\
-		__used __section(__clk_of_table)		\
-		= { .compatible = compat, .data = fn };
+#else /* !CONFIG_OF */
 
+static inline int of_clk_add_provider(struct device_node *np,
+			struct clk *(*clk_src_get)(struct of_phandle_args *args,
+						   void *data),
+			void *data)
+{
+	return 0;
+}
+#define of_clk_del_provider(np) \
+	{ while (0); }
+static inline struct clk *of_clk_src_simple_get(
+	struct of_phandle_args *clkspec, void *data)
+{
+	return ERR_PTR(-ENOENT);
+}
+static inline struct clk *of_clk_src_onecell_get(
+	struct of_phandle_args *clkspec, void *data)
+{
+	return ERR_PTR(-ENOENT);
+}
+static inline const char *of_clk_get_parent_name(struct device_node *np,
+						 int index)
+{
+	return NULL;
+}
+#define of_clk_init(matches) \
+	{ while (0); }
+#endif /* CONFIG_OF */
 #endif /* CONFIG_COMMON_CLK */
 #endif /* CLK_PROVIDER_H */
-- 
1.7.10.4



From sebastian.hesselbarth at gmail.com  Tue Apr 30 20:58:29 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Wed,  1 May 2013 02:58:29 +0200
Subject: [PATCH 2/2] clk: si5351: Allow to build without CONFIG_OF
In-Reply-To: <1367369910-20402-1-git-send-email-sebastian.hesselbarth@gmail.com>
References: <1367369910-20402-1-git-send-email-sebastian.hesselbarth@gmail.com>
Message-ID: <1367369910-20402-3-git-send-email-sebastian.hesselbarth@gmail.com>

With of_clk_provider stubs for CONFIG_OF not set, we can now also enable
clk-si5351 on those architectures.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
---
Cc: Mike Turquette <mturquette at linaro.org>
Cc: Linus Walleij <linus.walleij at linaro.org>
Cc: Andrew Morton <akpm at linux-foundation.org>
Cc: Peter Ujfalusi <peter.ujfalusi at ti.com>
Cc: Arnd Bergmann <arnd at arndb.de>
Cc: Stephen Warren <swarren at nvidia.com>
Cc: Daniel Mack <zonque at gmail.com>
Cc: Lars-Peter Clausen <lars at metafoo.de>
Cc: Guenter Roeck <linux at roeck-us.net>
Cc: Marek Belisko <marek.belisko at streamunlimited.com>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
---
 drivers/clk/Kconfig |    1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 0357ac4..186dd0e 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -58,7 +58,6 @@ config COMMON_CLK_MAX77686
 config COMMON_CLK_SI5351
 	tristate "Clock driver for SiLabs 5351A/B/C"
 	depends on I2C
-	depends on OF
 	select REGMAP_I2C
 	select RATIONAL
 	---help---
-- 
1.7.10.4



From rusty at rustcorp.com.au  Tue Apr 30 22:07:36 2013
From: rusty at rustcorp.com.au (Rusty Russell)
Date: Wed, 01 May 2013 11:37:36 +0930
Subject: [PATCH 0/2] Early printk support for virtio console devices.
In-Reply-To: <C52CCDD4-D8FB-4AD6-B83D-3B5251A7A0F5@suse.de>
References: <1366974299-17877-1-git-send-email-pranavkumar@linaro.org>
 <BA2076A6-0688-4E5C-85F9-A9CA8FD75782@suse.de>
 <87obcyc9sh.fsf@rustcorp.com.au>
 <336C59AA-D5D7-472E-A8DA-EEB413DD6C68@suse.de>
 <CAAHg+Hj0tySbzUGnoFE9ybVYP291B-i8-Ck1EkwD57t8yG5wwg@mail.gmail.com>
 <C52CCDD4-D8FB-4AD6-B83D-3B5251A7A0F5@suse.de>
Message-ID: <87sj27xxjr.fsf@rustcorp.com.au>

Alexander Graf <agraf at suse.de> writes:
> There are not device specific registers in
> virtio-console. Virtio-console lives behind a virtio bus which doesn't
> know what these registers are.

You're not going to make coherent arguments without reading that actual
patch we're discussing.  And you're going to just waste everyone else's
time.

> Even if you shove it into config space,

Which is what the patch does...

> it'd be broken because config access happens without intercepts on
> some platforms.

But people keep assuming it, which is one reason virtio_ccw switched
from passive lguest-style config to active.  Only lguest and the old kvm
virtio use it, and lguest can change.

An emergency output is a reasonable idea, and this is a reasonable
implementation.  The question is practical: will it be used?  Because we
don't implement reasonable ideas which aren't going to be used.

Cheers,
Rusty.


